а на счёт Kreker так это я просто извратился, с присвоениями, врятли в жизни такое может понадобится делать в шаблонах
Mr.M.I.T. Кеширование на уровне шаблонизатора не то, что реально требуется там, где что-то сложнее чем обычный информационный сайт или блог. Взять хотя-бы любой форум - там кеширование делать можно только на уровне запросов, т.к. каждый пользователь видет свой вариант страницы в зависимости от настроек аккаунта и выледенных ему ролей. Лично я сталкивался с частичным кешированием блоков, когда отдельные блоки сайта кешируются а остальное идёт Live. Так же при этом мне нужно было использовать memcache не только как кеш шаблонов/запросов, а ещё и как временное хранилище информации для снятия нагрузки с базы (не кеширование запросов, а именно накопление и хранение информации до сброса в базу), хранить всякие флаги состояний. Поетому я считаю что выделять API кеширования шаблонов в шаблонизатор не рационально и может привести к проблемам + не даёт той гибкости. Вот пара примеров на вскидку, когда кеширование нужно, но на уровне шаблонизатора его фиг сделаешь: * Блок состоит из последовательности нескольких шаблонов, т.е. модуль в себе собирает несколько шаблонов и потом всё разом отправляет на вывод. * Подключается какой-то глобальный шаблон, который нельзя кешировать на уровне шаблонизатора. Конкретный пример: шаблон блока (т.е. рамочки для блоков) - любая информация выводится в таком блоке и он используется постоянно в разных модулях. Так что что-бы закешировать данные в каком-то конкретном месте нужно делать кеширование уровнем выше, на уровне модуля. * Кеширование разных данных выводимых разными методами модуля, но с помощью одного шаблона. У меня есть модуль делающий вывод 6 разных типов данных через один шаблон. Решение кеширования на уровне шаблоназатора уже не годится. Да, при желании можно сделать такое API у шаблонизатора, что всё это можно будет сделать. Однако у вас будет куча вызовов методов шаблонизатора, установка ключей, времени кеширования, получение данных на вывод. Т.е. у вас всёравно будет логика обработки выводить кеш или пересоздать его. В этом случае куда лучше иметь API кеша и работать с ним. В итоге у вас универсальное API для всего кеширования, а не отдельное для шаблонизатора и прочего. А какая будет каша если в одном методе понадобится как кеш шаблонизатора, так и API общего назначения? Каша, трудно будет осмыслить нафига такой огород. Посмотрите на Zend Cache - единый API который потом просто используется везде.
Psih Когда функциональность кеша внедряется в шаблон, предлагаю делать методы работы с кешом статические и все тогда отлично выходит...
kostyl В шаблоне не должно быть вообще никакого управления кроме тупого вывода данных, простейших условий вывода того или иного куска HTML и циклов вывода данных из массивов. Не надо думать, что раз PHP - можно всё, мол ничего не станет если я тут вставлю Cache::get('something'). Шаблон он шаблон и точка. get(), is_set(), if, foreach/for/while - это всё, что разрешено в шаблонах. Всё остальное на уровне приложения.
Psih Ну я так писал Template::ClearCache(User::GetCacheKey()); и все нормально было, просто я в шаблон добавил функционал который ты хочешь добавить в глобальное пространство... Какая разница? Шаблонизатор от этого медленнее не стал работать...(хотя я и не мерил)
{postcache}{/postcache} setCacherHandler В шаблонизаторе у меня только кеш скомпилированных шаблонов, вот он имхо должен быть в шаблонизаторе и на файлах, накрайняк, для него тоже можно написать какую-нибудь callback пользовательскую[/quote]
извращенец? мож плетку кожанную? не? шаблонизатор нужен чисто для разделения БИЗНЕС логики и шаблона // быстро накидал. возможно не работает но мысль передать function template($file, $arr=array()){ global $config; if(file_exists($tpl=$config['template_path'].'/'.$file.'.html')) {extract($arr);include($tpl);} else die('шаблон $file не найден на сервере'); } и все больше никуя не надо. а маразм. ничем не легче. а делать обертку для базовых функций пхп (if, for и пр) верх дибилизма. я не говорю что в данном моем примере идеальный код но как идея считаю оправдывает себя на все 100%.
эм, дык а кто спорит что натив неьзя? у меня там же 2 драйвера, натив и этот, а улучшенный всёравно компилит шаблончики в натив приемущество этого во всестроннем кешировании, ну и мне удобнее он кажется удобнее, потому что короче <?=$var;?> vs {$var} Удобнее, потому что логика виднее <?if(){?><?}?> vs {if()}{/if} (не в счёт <?if():?><?endif;?>) Удобнее, потому что печатать быстрее, эти <? задолбаешься каждый раз набирать ну и удобнее, потому что на смарти похож
NATIVE PHP и точка. Какие нахрен шаблонизаторы? PHP: <?php if ($a > b):?> ... <?php endif; ?> И не надо выпендриваться, ё моё. Смарти сакс, шаблонизаторы сакс
Ну да ну да, создатели CodeIgniter, Django (не пых, но шаблонизатор там бомба-яд), ... дураки. Одни вы умные
NATIVE PHP выглядит более-менее читабельным с логикой в две строчки (чем все его фаны и пользуются, мол смотрите как читабельно). если бы надо было отобразить какую-то расширенную модель с несколькими уровнями вложенности - нейтив был бы вообще ужастен. Я использую native только когда мне лень подключать нормальный верстальщик-френдли шаблонизатор. и да. меня удивляет, почему все кричат про скорость работы native-шаблонизатора, если все нормальные шаблонизаторы компилируют свой код в тот самый native-код, потому скорости у них практически одинаковые.. Или вы так: отключили кеширование в шаблонизаторе и после этого его проверяете?
Элементарно, два объекта, один возвращает в другой кэшированный блок данных: PHP: <?php //накидал public function Parse() { foreach($this->_Vars as $Var) { if ($Var instanceof Template) { include($Var->GetData()); } } }
kostyl задолбаешься каждый блок в шаблончик выносить например у меня есть блок авторизация, там чего-то бла-бла-бла одинакого для всех юзверей, можно скешировать, а чего-то индивидуально для каждого, это пропустить
В точку. Пример в студию. В таком случае смысл шаблонизатора? Упрощение работы? Для кого? Зачем? Кому как.
конечно конечно, хорошо когда много, запутаться легче зачем пых, давайте на сях писать Кому как Код (Text): {if($var)} {for($i=0,$c=count($var);$i<$c;$i++)} {if($var[$i]==0)} {$mz=array("do1"=>"href1","do2"=>"href2","do3"=>"href3")} {foreach($mz as $key=>$val)} <a href="{$val}">{$key}</a><br> {/foreach} {elseif($var==1)} <a href="main">Main</a> {else} Error. {/if} {/for} {else} {header("location:/")} {exit()} {/if} Код (Text): <?if($var){?> <?for($i=0,$c=count($var);$i<$c;$i++){?> <?if($var[$i]==0){?> <?$mz=array("do1"=>"href1","do2"=>"href2","do3"=>"href3");?> <?foreach($mz as $key=>$val){?> <a href="<?echo $val;?>"><?echo $key;?></a><br> <?}?> <?}elseif($var==1){?> <a href="main">Main</a> <?}else{?> Error. <?}?> <?}?> <?}else{?> <?header("location:/");?> <?exit();?> <?}?> Как по мне дык, может они выглядят и схоже, но вот писанины в примере 2 на порядок больше а вообще я шаблончики википедии видел...
PHP написан специально под веб. Можно писать на С#. JSP. Python. Perl. RoR. Но не на С++. Шаблонизатор - НЕ язык. Следовательно... Имхо, одно и то же. Только я бы отказался от коротких тегов + делал бы отступы, чтобы красивее смотрелось. Плюс там где не надо не выходил бы из РНР. Ну и вместо { } юзать endif; - логичнее для шаблонов.