Blitz Templates: научите идиота

Develar

Новичок
>> хотя и черезчур заморочено как по мне
смысл в том, что управляет и просит о header&footer&etc не контроллер, который отвечает исключительно за установку данных полученных путем вызова API в свой шаблон, а шаблон (то есть контроллера может вообще не быть) - идет раскрутка со стартового контентообразующего шаблона (то есть для /catalog это будет Catalog.tpl) к обвязке (наследник blitz дает функциональность передачи параметров по стеку, макетирование и подключение view=template+controller). разумеется, при использовании blitz в узкоспециализированном проекте эта гибкая схема излишне сложна и неудобна - ядро просто использует df::Template который обходится без flyti::view::View.
 

Spear

почемучка
Хм, основы-то я понял. Самые-самые.
Теперь думаю - как правильно парсить контент, специфический для каждой страницы?
Ну, допустим, - страницы авторизации, страницы восстановления пароля.

Сейчас пока сделал просто вывод основного шаблона, + хедер (со всеми нужными данными, кстати без использования инклуда), и футер.

А как дальше делать, так чтоб правильно?

То есть варианты такие:
1. Сделать под каждую страницу свой небольшой шаблон.
То есть это не шаблоны типа user.tpl а, например:
user_settings.tpl
user_remind_pass.tpl
useR_auth.tpl
и так далее. Получается будет около 50 мелких шаблонов. Хотя, возможно, и больше

2. Сделать большие шаблоны. Это будутв се те же мелкие шаблоны только объединенные в 1 файл и разделенные блоками.
Например для register.tpl
{{ begin step_1 }}.. {{end}} {{begin avtivate }} .. {{end}} {{begin manual_activate}} {{begin resend_validation}}

Подскажите, пожалуйста, кто как делает? (в двух словах, чтоб я схему понял).

Просто в первом варианте пугает огромное количество файлов шаблонов. Во втором варианте - я не уверен насколько вобще разумно будет парсить файл на 10 кб для того, чтобы выдрать от туда чатсь шаблона которая выведет миниатюрную формочку для восстановления пароля.
 

Develar

Новичок
>> пугает огромное количество файлов шаблонов
из-за скорости или управления этим? я предпочитаю бить на файлы исходя из логического разделения - оно и проще в понимании и сопровождении - scm. а в случае восстановления пароля и вопрос скорости не стоит - форма одна на страницу. впрочем, ria я реализую используя другую технологию.
 

Spear

почемучка
У меня был 1 файл-фраппер. вроде
<html>...
<body>...
%%HEADER%%
%%CONTENT%%
%%FOOTER%%

и по 1 РНР файлу с шаблонами на каждый модуль,
например

template_register.php
там
PHP:
class template_blabla
{
 
 function show_reg_form($data)
 { 
      $returnHTML = "<div>......<form></form><div></div>....</div>";
      return $returnHTML;
  }
}
Класс собирал все нужное, делал str_replace для враппера. Но сложную структуру страниц сделать очень проблематично (не то что бы сложно, просто слишком много лишней логики будет для тривиальных вещей)

-~{}~ 11.02.08 17:19:

по-тихоньку рзабираюсь. Сделал класс-наследник Блитза, в нем функции хедера и футера.

Теперь встал вопрос о том, как правильно расставлять блоки, то есть не основной контент а инфо-блоки - облако тегов и прочее.

Буду благодарен за совет,
хотя это уже относится не столько к блитзу сколько в общем к работе с шаблонизаторами.
 

fisher

накатила суть
>>"In current version include doesn't support context iteration"
блин, это устарело. поддерживаются контексты в инклюдах, довольно давно.

fisher@devel2:~/blitz> cat 1.tpl
{{ BEGIN some }} {{ $val; }} {{ END }}
fisher@devel2:~/blitz> cat test.php
<?

dl('blitz.so');

$T = new Blitz();
$T->load('{{ include("1.tpl") }}');
$T->set(array('some' => array('val' => 'preved!')));
echo $T->parse();

?>
fisher@devel2:~/blitz> phpb test.php
preved!

там только есть тонкость что если вы зовете методы block или iterate и указываете контекст, которого нет в шаблоне основном, но он есть в шаблоне подключаемом, то по умолчанию движок такой контекст проигнорирует (потому что на этапе итерации он не будет парсить подключаемый шаблон). чтобы этого не происходило, нужно явно указать дополнительный параметр iterate_non_existant
 
Сверху