Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Знающие люди подтвердят, что xTemplate — это почти классика model из аббревиатуры MVC. Да, не так шустро, зато все просто и очевидно. Да, и конечно же никакой логики в шаблоне
Я понимаю, что уже поздно ;), но на всякий случай, посмотрите на досуге Blitz, мне в свое время показался весьма замечательным.
Его автор тоже, по-моему, появлялся на хабре.
Его автор тоже, по-моему, появлялся на хабре.
Я смотрел, думаю стоило бы включить его в тестирование, но было мало времени =(
Всё-таки основное чем вышеописанный шаблонизатор отличается от остальных в том числе и Blitz — это то что переменная ассигнится $tpl->var='wow'; а не $tpl->set('var','wow'); Насколько перспективен такой подход?
Всё-таки основное чем вышеописанный шаблонизатор отличается от остальных в том числе и Blitz — это то что переменная ассигнится $tpl->var='wow'; а не $tpl->set('var','wow'); Насколько перспективен такой подход?
ваш подход медленнее и менее гибкий.
1) быстрее будет присваивать переменные внутреннему массиву private $vars, например. работа с переменными объекта всегда медленнее, и в данном случае непонятно почему вы остановились именно на таком варианте.
2) правильнее работать через функцию set, так как получается единая точка обработки переменных, и там всегда можно добавить дополнительные проверки, преобразования или что еще понадобится в дальнейшем. например в функцию можно передать массив-масивов и разложить автоматом переменные из внутреннего массива по отдельным переменным. а в вашем случае для этого придется переопределять методы __get и __set. это магия. и она тоже скоростью не блещет…
1) быстрее будет присваивать переменные внутреннему массиву private $vars, например. работа с переменными объекта всегда медленнее, и в данном случае непонятно почему вы остановились именно на таком варианте.
2) правильнее работать через функцию set, так как получается единая точка обработки переменных, и там всегда можно добавить дополнительные проверки, преобразования или что еще понадобится в дальнейшем. например в функцию можно передать массив-масивов и разложить автоматом переменные из внутреннего массива по отдельным переменным. а в вашем случае для этого придется переопределять методы __get и __set. это магия. и она тоже скоростью не блещет…
1) С чего вы это взяли? На всякий случай ещё раз протестировал и получил 3.8 сек против 5, предложенный мной способ работы с переменными работает с серьёзным выигрышем по времени, не верите — протестируйте сами!!!
2) Мне кажется, что это очень редко нужно, и совсем редко кто-то будет лезть в функцию set, а значит магия в таком случае не так уж и плохо, тем более с предопределением этого метода будет 4.8, а не 5! То есть всё равно быстрее!
2) Мне кажется, что это очень редко нужно, и совсем редко кто-то будет лезть в функцию set, а значит магия в таком случае не так уж и плохо, тем более с предопределением этого метода будет 4.8, а не 5! То есть всё равно быстрее!
скорость работы с массивами больше чем с объектами. я подобные эксперименты делал сам и видел обзоры других исследователей. так что у вас гдето погрешность есть)
помимо этого. замерьте еще потребление памяти, в простейшем случае функцией memory_get_usage();
это вам покажет, что одни и те же данные, занимают больше памяти если лежат внутри объекта и меньше если в виде простой переменной или как элемент массива. это вполне логично кстати.
поверьте. я не хочу переубеждать вас.
если вы считаете что вы придумали чтото выдающееся, то продолжайте дальше )
мы все через это прошли
помимо этого. замерьте еще потребление памяти, в простейшем случае функцией memory_get_usage();
это вам покажет, что одни и те же данные, занимают больше памяти если лежат внутри объекта и меньше если в виде простой переменной или как элемент массива. это вполне логично кстати.
поверьте. я не хочу переубеждать вас.
если вы считаете что вы придумали чтото выдающееся, то продолжайте дальше )
мы все через это прошли
Вы снова неправы, предложенный мной способ оказался более экономичным, 1324 у меня, против 1820! Кстати если в случае со скоростью могут быть какие-то незначительные погрешности, то здесь их нет! И я не считаю что открыл что-то новое, я уже очень давно пользуюсь таким подходом, и разумеется не я его придумал, просто я хочу донести что он действительно лучше, покрайней мере все тесты подтверждают это с запасом!
Гистограммы-то некорректные ;) Вы бы не обрубки столбиков на ней отображали, а целиком. А то при первом взгляде можно подумать, что native раз в 7 шустрее Smarty, а как посмотришь на цифры, то оказывается, что относительный прирост процентов 30.
на самом деле прирост немного не такой, дело в том что аналогичный тест с пустой страницей проходил за 26 сек… дело в том что тестировал я используя time в баше и курл для вызова страницы, вот скрипт которым тестировал:
#!/bin/bash
cd ./$*
for i in `seq 1 1000`;
do
curl tester/$*/ -o /dev/null
done
поэтому и обрезал столбики так!
#!/bin/bash
cd ./$*
for i in `seq 1 1000`;
do
curl tester/$*/ -o /dev/null
done
поэтому и обрезал столбики так!
Был бы благодарен переносом в блог «php»! Или кармой для переноса=)
хотите критики? )
просто сразу появились вопросы. часть проблем сразу всплывает из за выбранной вами архитектуры решения.
1) как удалить все переменные шаблонизатора? например для того чтобы повторно его использовать для отрисовки другого блока данных.
2) как получить отрендеренный блок или страницу в переменную? это часто бывает нужно. для формирования рассылки пользователям например…
3) кеширования нет! кешировать данные хорошо, но иногда и готовые блоки кешировать бывает очень полезно.
4) несогласен насчет полного отсутствия логики. Просто нужно понимать. есть логика приложения, а есть логика отображения. хотябы в минимальном объеме она должна быть доступна. на одних блоках далеко не уедешь.
просто сразу появились вопросы. часть проблем сразу всплывает из за выбранной вами архитектуры решения.
1) как удалить все переменные шаблонизатора? например для того чтобы повторно его использовать для отрисовки другого блока данных.
2) как получить отрендеренный блок или страницу в переменную? это часто бывает нужно. для формирования рассылки пользователям например…
3) кеширования нет! кешировать данные хорошо, но иногда и готовые блоки кешировать бывает очень полезно.
4) несогласен насчет полного отсутствия логики. Просто нужно понимать. есть логика приложения, а есть логика отображения. хотябы в минимальном объеме она должна быть доступна. на одних блоках далеко не уедешь.
1) Вот так:
Но я подумаю как сделать чтобы было так:
2) Над этим я думал, но руки ещё не дошли, обязательно это сделаю
3) Да я с этим абсолютно согласен!
4) Ну тут можно долго спорить…
- foreach ($tpl as $k=>$v) if ($k!='tplDir' && $k!='tmpDir') unset($v);
Но я подумаю как сделать чтобы было так:
- foreach ($tpl as $k=>$v) unset($v);
2) Над этим я думал, но руки ещё не дошли, обязательно это сделаю
3) Да я с этим абсолютно согласен!
4) Ну тут можно долго спорить…
1) ужас
2,3,4 — удачи.
приведу пример моего простейшего шаблонизатора
для нативных шаблонов большего и не надо)
кеширование добавить и уже можно пользоваться)
2,3,4 — удачи.
приведу пример моего простейшего шаблонизатора
class myView {
protected $_path;
public $_var = array();
public function __construct($path) {
$this->_path = $path;
}
public function assign($name, $value='') {
if (is_array($name)) foreach($name as $k=>$v) $this->_var[$k] = $v;
else $this->_var[$name] = $value;
}
public function fetch($template, $params=array()) {
if (is_array($params) && sizeof($params)>0) {
$this->assign($params);
}
$this->_template = $this->_path . $template;
if (!file_exists($this->_template)) {
return 'Template not found: ' . $this->_template.'<br />';
}
else {
ob_start();
extract($this->_var);
include($this->_template);
return ob_get_clean();
}
}
public function display($template,$p=array() ) {
echo $this->fetch($template, $p);
}
}
для нативных шаблонов большего и не надо)
кеширование добавить и уже можно пользоваться)
Вы изобрели не велосипед, а даже на самокат не тянет :). Уж извините. Даже с монтсроподобным и неповоротливым Smarty ваша поделка так себе выглядит. Кэширование и прочие радости smarty включали в тест?
Зарание оговорюсь, что PHP не совсем моя стихия.
Когда описывают PHP шаблонизаторы, обычно говорорят о циклах, функциях, вставках и т.д.
А есть ли в каком либо из этих шаблонизаторов наследование шаблонов? Есть ли возможность декларативно описать вхождения некоторых элементов с возможностью переопределить в потомках?
Для java есть Tiles. Если же вы используете JSF, то можно еще более облегчить себе жизнь использованием facelets.
Пока шаблонизаторы координально не улучшатся, предоставив намного более продвинутый функционал, то говорить о том, что «у нас прорыв» рано.
Когда описывают PHP шаблонизаторы, обычно говорорят о циклах, функциях, вставках и т.д.
А есть ли в каком либо из этих шаблонизаторов наследование шаблонов? Есть ли возможность декларативно описать вхождения некоторых элементов с возможностью переопределить в потомках?
Для java есть Tiles. Если же вы используете JSF, то можно еще более облегчить себе жизнь использованием facelets.
Пока шаблонизаторы координально не улучшатся, предоставив намного более продвинутый функционал, то говорить о том, что «у нас прорыв» рано.
Мне кажется, Вы слегка отклонились в сторону фреймворков.
По просьбе обчитавшихся верстальщиков, мы сделали наследование шаблонов в смарти-подобном ШД под php.
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
Работал я как-то с прорвой блоков — это такое кол-во include, что волосы дыбом становятся.
Как вы сделаете простейший пример: сделать чередование цветов в строках таблицы? Без логики в шаблоне — никак. Добавите спец. тег? Привет Smarty!
З.Ы. Сам работаю с plain php шаблонами, чем доволен и никому не навязываю. Знакомые тоже так-же работают и никто не пытается сделать своё или поставить Smart/Blitz/etc.
Как вы сделаете простейший пример: сделать чередование цветов в строках таблицы? Без логики в шаблоне — никак. Добавите спец. тег? Привет Smarty!
З.Ы. Сам работаю с plain php шаблонами, чем доволен и никому не навязываю. Знакомые тоже так-же работают и никто не пытается сделать своё или поставить Smart/Blitz/etc.
поддерживаю, в топку логику в шаблонизаторах, если у нас и так есть ПХП, который изначально для этого и расчитан)
плюс, имеем полный набор функций ПХП и не имеем многоэтажных пирамид ;)
плюс, имеем полный набор функций ПХП и не имеем многоэтажных пирамид ;)
Вот какраз использовать все возможности не нужно — нужен самый минимум — циклы, простые if, возможно отдельные специфичные вызовы каких-то функций/методов, которые генерируют сложный HTML по условиям. Всё остальное на уровень бизнес-логики, иначе рублю пальцы топором :)
Забыл добавить — такие элементы как постраничный вывод я вообще генерирую отдельным вызовом в приложении и передаю уже готовый кусок HTML кода в шаблон. Ну невозможно такую кашу держать в шаблоне, слишком много условий, вставок PHP будет в шаблоне — трудно будет читатся, так что вынес в функцию.
Согласен с вами, я тоже очень давно и много использовал нативный шаблонизатор, но в определённый момент захотелось эстетики, и простого аккуратного синтаксиса, я кажется забыл добавить в статье, что шаблонизатор никак не вырезает PHP код, и им можно пользоваться на своё здоровье…
Надо просто учиться «культурному» программированию и не строить заборы, что нужно, а что нет в шаблонах. Многие используют шаблонизаторы только из-за ощущения изолированности от бизнес логики, чего не нужно будет в системах (cms-ки там всякие) с прозрачной архитектурой. Жаль что таких ещё нет((
Кто-нибудь может дать весомые аргументы в пользу использования мета языка шаблонов вместо самого php??
подобный мета-язык позволяет скрыть особенности реализации самого шаблона. и верстальщику не нужно знать на чем написан сайт.
ну и некоторые конструкции выглядет меньше.
ИМХО, на этом польза заканчивается.
ну и некоторые конструкции выглядет меньше.
ИМХО, на этом польза заканчивается.
Но верстальщику надо сначала выучить метаязык.
Согласен
это уже пошли Минусы ))
это уже пошли Минусы ))
От чего сразу минусы?
Сначала мы говорим о том, что порог вхождения в PHP низок, поэтому… блабла.
А как дело доходит до верстальщиков — сразу минусы.
Хотя я о другом, PHP, как отметили выше — лучшее средство шаблонизации. Зачем городить огороды, гораздо проще верстальщиков научить циклам на PHP — единому стандарту опять же, а не забивать голову людям надуманными вещами.
CSS3 похлеще PHP будет ;)
Сначала мы говорим о том, что порог вхождения в PHP низок, поэтому… блабла.
А как дело доходит до верстальщиков — сразу минусы.
Хотя я о другом, PHP, как отметили выше — лучшее средство шаблонизации. Зачем городить огороды, гораздо проще верстальщиков научить циклам на PHP — единому стандарту опять же, а не забивать голову людям надуманными вещами.
CSS3 похлеще PHP будет ;)
Повторюсь. Кто не знает — советую почитать про модель MVC. PHP выполняет роль контроллера, шаблонизатор — модели, браузер — отображение. И именно поэтому имеет смысл использовать шаблонизатор
речь идет о том — зачем городить собственный синтаксис, когда можно использовать нативный PHP код, слава богу пока тут не звучали лозунги: «В топку MVC, если у нас есть PHP» =)
Ну так зачем ты тогда городил свой синтаксис?:)
Напомню, именно ты пробудил во мне эстетическое начало, которое побудило меня тянуться к удобному читаемому синтаксису, а ещё такой подход стимулирует разделение логики, ведь очень часто когда шаблонизатор нативный — рука тянется распарсить или получить какую-нибудь мелочь прямо в шаблоне, а не лезть искать контроллер
Шаблонизатор == модель — это что-то новенькое…
Нафига козе баян, если есть MVC?
У вас логика отображения перенесена в контроллер. Что не есть гуд.
ну а сравнение со смарти вообще некорректное (циклы). Ибо всё что вы написали — пишется непосредственно в шаблоне смарти на его синтаксисе. так как написали вы — не делает никто.
ну а сравнение со смарти вообще некорректное (циклы). Ибо всё что вы написали — пишется непосредственно в шаблоне смарти на его синтаксисе. так как написали вы — не делает никто.
быстрее трактора Беларусь хрен сыщешь
Оффтопик: неужели проще вручную форматировать сорцы Highlighterом и выкладывать в статью, чем залить код куда-нибудь на гитхаб и предоставить читателю самому вытянуть его, открыть в любимом редакторе и курить на здоровье? Его ж с этими номерами строк и не откопипастишь нормально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё один php шаблонизатор