Comments 137
По скорости замеры делали?
Да, конечно были замеры, но сейчас у меня данных этих нет. Собственно изначально именно скорость работы была аргументом в пользу Twig.
почему не Blitz? для критичных к времени наполнения шаблона участках мы используем его.
>>почему не Blitz?
По правде говоря я точно не помню. Blitz тоже рассматривался, но Twig почему-то победил. Может быть он оказался удобнее?
По правде говоря я точно не помню. Blitz тоже рассматривался, но Twig почему-то победил. Может быть он оказался удобнее?
Blitz требует куда большего участия программиста для верстки, нежели Smarty, что актуально только для больших нагрузок. В свое время отказался от него из-за больших временных затрат на крошечные изменения.
На выходе каждого шаблона twig — обычный php класс, содержащий метод
render(), определяющий строчки типа echo "".$yourVar.""; внутри. В некоторых местах он даже быстрее привычной в остальных фреймворках ?php шаблонизации, ибо не использует подавление вывода.
вот почему все пользуются конкатенацией строк
вместо перечисления:
нафига делать совершенно ненужные ёмкие операции
echo "".$yourVar."";вместо перечисления:
echo "",$yourVar,"";нафига делать совершенно ненужные ёмкие операции
Потому что конкатенация строк в php —
.. Если я захочу эту строку записать в переменную вместо вывода в буфер, я просто поменяю echo на $echo = , а вам придется менять все запятые.если крипт дебажите, то можно выводить отдельно всё что угодно и менять запятые на точки, но на продакшене зачем?
Назовите мне хоть одну вменяемую причину использования `,` вместо `.`.
время, занимаемое конкатенацией строк + съедаемая при этом память
сотни записей
совершенно бесполезное использование конкатенации
for(...)
{
echo "<tr><td>".$data[$i]['cell1']."</td><td>".$data[$i]['cell2']. {...} ."</td></tr>";
}совершенно бесполезное использование конкатенации
Взял twig поле прочтения данного поста. Понравилось. Благодаря наследованию стал шаблоны использовать по образу master page из ASP.NET.
По указанной ссылке также есть замеры производительности разных шаблонизаторов.
Да, я когда переходом озаботился — тоже опирался на ту статью. Но статья статьей, а для себя замеры все равно надо было делать.
Вообще странно, что про Twig так мало пишут.
Вообще странно, что про Twig так мало пишут.
>Вообще странно, что про Twig так мало пишут.
Поиск Хабра рассказал мне о том, что статей предостаточно. Гугл говорит, что о нем пишут столько же сколько и о других. Даже на википедии есть статья.
Поиск Хабра рассказал мне о том, что статей предостаточно. Гугл говорит, что о нем пишут столько же сколько и о других. Даже на википедии есть статья.
Может мне мне так показалось из-за сравнения со Smarty.
www.google.com.ua/#hl=ru&sugexp=gsis%2Ci18n%3Dtrue&cp=4&gs_id=b&xhr=t&q=twig&pf=p&sclient=psy&site=&source=hp&pbx=1&oq=twig&aq=0&aqi=g3g-s1g1&aql=&gs_sm=&gs_upl=&fp=2b4891f86c5023c0&biw=1280&bih=789
www.google.com.ua/#hl=ru&sugexp=gsis%2Ci18n%3Dtrue&cp=6&gs_id=j&xhr=t&q=smarty&pf=p&sclient=psy&site=&source=hp&pbx=1&oq=smarty&aq=0&aqi=g5&aql=&gs_sm=&gs_upl=&fp=2b4891f86c5023c0&biw=1280&bih=789
и
habrahabr.ru/search/?q=twig
habrahabr.ru/search/?q=smarty
Разница все же есть и довольно существенная.
www.google.com.ua/#hl=ru&sugexp=gsis%2Ci18n%3Dtrue&cp=4&gs_id=b&xhr=t&q=twig&pf=p&sclient=psy&site=&source=hp&pbx=1&oq=twig&aq=0&aqi=g3g-s1g1&aql=&gs_sm=&gs_upl=&fp=2b4891f86c5023c0&biw=1280&bih=789
www.google.com.ua/#hl=ru&sugexp=gsis%2Ci18n%3Dtrue&cp=6&gs_id=j&xhr=t&q=smarty&pf=p&sclient=psy&site=&source=hp&pbx=1&oq=smarty&aq=0&aqi=g5&aql=&gs_sm=&gs_upl=&fp=2b4891f86c5023c0&biw=1280&bih=789
и
habrahabr.ru/search/?q=twig
habrahabr.ru/search/?q=smarty
Разница все же есть и довольно существенная.
Я тоже когда-то читал эту статью, и думал, что Twig действительно самый быстрый. Однако, ещё тогда меня смутило, почему при использовании шаблонизаторов в реальных условиях (без принудительной компиляции) цифры по производительности предоставлены не были. Наверное, вот почему: habrahabr.ru/blogs/webdev/127906/#comment_4226462
Ни тем ни тем не пользовался, но судя по коду — Twig похож на встроенный в Django шаблонизатор, а со Smarty нужно писать кучу лишнего кода. Не совсем тогда понятно почему Smarty такой популярный, если есть такие замечательные альтернативы.
inlanger, дело не столько в лишнем коде, сколько вообще в логике работы.
Smarty популярный из-за того, что появился давно, применялся в некоторых популярных движках и соответственно довольно много народу им пользовались, синтаксис стал привычным.
Smarty популярный из-за того, что появился давно, применялся в некоторых популярных движках и соответственно довольно много народу им пользовались, синтаксис стал привычным.
Twig похож на встроенный в Django шаблонизатор
jinja2 еще.
Разработчики и не скрывают факта похожести.
PHP сам по себе отличный шаблонизатор, Smarty и прочие велосипеды лучше использовать только если верстальщик по другому не может.
Мне сложно себе представить, как можно без костылей устроить наследование шаблонов. Все равно ведь выйдет шаблонизатор в итоге. А наследование это удобно и очень здорово.
Я часто сам себе верстальщик и ценю свое время и нервы.
Я часто сам себе верстальщик и ценю свое время и нервы.
Не спорю, верстальщикам тот же Smarty очень облегчает работу, но сервер у приходится парсить шаблон, компилировать в кривой код и выполнять его. Хорошо, когда это все дело кэшируется, а если нет?
Что будет работать быстрее, или {$var}?
Что будет работать быстрее, или {$var}?
Одно из самых больших заблуждений web-программистов. Не важно как быстро работают отдельные инструкции. Важно насколько они читабельны, насколько итоговый код расширяем и масштабируем! Остальное — синдром «гипероптимизации», который обычно приводит к отсутствию как читабельности, так и масштабируемости.
не важно как быстро работают отдельные конструкции? А ведь автор именно по причине скорости отказался от Смарти. Так что я бы не был так уж сильно уверен.
>>о сервер у приходится парсить шаблон, компилировать в кривой код и выполнять его.
О том какой код компилит Twig наверное можно отдельную статейку написать. Совсем он там не кривой.
>>Что будет работать быстрее, или {$var}?
Да много всяких вещей работают быстрее. Должен быть разумный компромисс между скоростью работы и простотой поддержки. Не быстротой единой, в общем.
О том какой код компилит Twig наверное можно отдельную статейку написать. Совсем он там не кривой.
>>Что будет работать быстрее, или {$var}?
Да много всяких вещей работают быстрее. Должен быть разумный компромисс между скоростью работы и простотой поддержки. Не быстротой единой, в общем.
twig компилирует шаблон один раз, после чего он не отличается от интерпретируемого скрипта php. Полученный скрипт потом лежит в кеше и если в шаблоне что-то изменилось кеш надо почистить.
>> Мне сложно себе представить, как можно без костылей устроить наследование шаблонов. Все равно ведь выйдет шаблонизатор в итоге. А наследование это удобно и очень здорово.
Наследование шаблона делается очень просто, даже без использования реальных классов. Можно использовать эту технику в «нативных» шаблонах, если скорость и объем кода критичны.
pyha.ru/forum/topic/4342.0
Наследование шаблона делается очень просто, даже без использования реальных классов. Можно использовать эту технику в «нативных» шаблонах, если скорость и объем кода критичны.
pyha.ru/forum/topic/4342.0
PHP как шаблонизатор не справляется с основной своей задачей — отделить логику от представления. Фабиен эту тему достаточно широко раскрыл в своем блоге 2 года назад (когда начал контрибутить в twig):
fabien.potencier.org/article/34/templating-engines-in-php
fabien.potencier.org/article/35/templating-engines-in-php-follow-up
fabien.potencier.org/article/34/templating-engines-in-php
fabien.potencier.org/article/35/templating-engines-in-php-follow-up
Да он там лукавит до невозможности. Например, не использует короткие теги php, мотивируя это тем, что могут быть проблемы с xml. Про pascal-синтаксис тоже молчит. Необъективно.
Ну короткие теги для РНР действительно имеют проблемы с XML и есть негласная рекомендация их не использовать из-за этого. Они могут быть как включены так и выключены на продакшне (по той же причине), а потому после нескольких деплоев, где «всё упало» я сам отвык от пратики использовать их. Но сами понимаете, это как раз малосущественно.
А вот момент, когда я почувствовал, что шаблонизаторы нужны. Считается, что шаблонизаторы ограничивают разработчика, чтобы он не натворил всяких гадостей, но ведь и чистый РНР имеет одно важное ограничение: если вы используете helper'ы в виде функций, то они будут вгружены в глобальный контекст, а с этого и проблемы, они становятся доступны там где не должны быть, а самое важное, их становится трудно доопределять и переопределять под конкретные шаблоны. Если ваш код рендерит 3 шаблона и собирает их, то везде будут доступны одни и те же хелперы! Если вы меняете порядок рендеринга, то некоторые просто хелперы отвалятся. Альтернатива — использование хелперов из переменных ($routing->url_to) мне не нравится стилистически. Да и с точки зрения логики этот вариант не очень.
Вообщем, Фабиен, конечно молодец, пацан слово дал, пацан слово забрал. То он сам говорил, что РНР лучший шаблонизатор, а через пару лет, понял, что был не прав.
А вот момент, когда я почувствовал, что шаблонизаторы нужны. Считается, что шаблонизаторы ограничивают разработчика, чтобы он не натворил всяких гадостей, но ведь и чистый РНР имеет одно важное ограничение: если вы используете helper'ы в виде функций, то они будут вгружены в глобальный контекст, а с этого и проблемы, они становятся доступны там где не должны быть, а самое важное, их становится трудно доопределять и переопределять под конкретные шаблоны. Если ваш код рендерит 3 шаблона и собирает их, то везде будут доступны одни и те же хелперы! Если вы меняете порядок рендеринга, то некоторые просто хелперы отвалятся. Альтернатива — использование хелперов из переменных ($routing->url_to) мне не нравится стилистически. Да и с точки зрения логики этот вариант не очень.
Вообщем, Фабиен, конечно молодец, пацан слово дал, пацан слово забрал. То он сам говорил, что РНР лучший шаблонизатор, а через пару лет, понял, что был не прав.
Хэлперы в глобальном контексте? А зачем? Можно же рендерить шаблон в контексте метода и пользоваться $this для доступа к хэлперам, ну или любым другим предопределенным объектом.
Да, согласен, но $this подходит мало, ведь хедперы нужно разделять по группам, доопределять (с учетом множественного необходмисоти вгружать туда методы из многих классов), короче, получится костыль над множественным наследованием.
Можно передавать классы helper'ов в переменных и впринципе, это самый правильный вариант. Юзать $routing->url(). Проблема может быть только в случае, если вы хотите передать в шаблон переменную $routing… Короче, опять таки получается проблема отделения данных от представления.
Можно передавать классы helper'ов в переменных и впринципе, это самый правильный вариант. Юзать $routing->url(). Проблема может быть только в случае, если вы хотите передать в шаблон переменную $routing… Короче, опять таки получается проблема отделения данных от представления.
Да где уж там негласная-то? Вот, прямо в доке и прописано:
ru.php.net/manual/en/language.basic-syntax.phpmode.php
Using short tags should be avoided when developing applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control, because short tags may not be supported on the target server. For portable, redistributable code, be sure not to use short tags.
ru.php.net/manual/en/language.basic-syntax.phpmode.php
Ну а для всех остальных случаев — негласная :)
Простите, но это выглядит как фанатизм.
В документации указано ограничение основанное на возможности отключить шорт теги на сервере. Причины делать это там не указаны. Потому даже если ты не пишешь «applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control» стоит всё равно не стоит их использовать ибо их возможно придется отключить (даже на своем сервере) из-за проблем с XML.
Зачем их отключать на «своих» серверах? Писать <?=чтото?> приходится часто, а писать <?='<?xml.....'?> — нет. Вы же не станете в «своих» разработках использовать fsockopen вместо curl (или file_get_contents ) ) под предлогом того, что он может быть (и где-то так и есть) отключен.
Вот поэтому подобные «негласные» правила и кажутся фанатизмом.
Вот поэтому подобные «негласные» правила и кажутся фанатизмом.
>PHP как шаблонизатор не справляется с основной своей задачей — отделить логику от представления.
А смарти и твиг капец как отделяют ее? Или циклы в шаблонах это есть отделение логики? По-моему наоборот. Мне лично проще внутри php-цикла наложить данные на кешированный где душе угодно шаблон элемента списка. При этом ни в одном шаблоне вообще нет никакой логики — только чистое представление
А смарти и твиг капец как отделяют ее? Или циклы в шаблонах это есть отделение логики? По-моему наоборот. Мне лично проще внутри php-цикла наложить данные на кешированный где душе угодно шаблон элемента списка. При этом ни в одном шаблоне вообще нет никакой логики — только чистое представление
Не знаю как смарти, но твиг логику представления от бизнес логики отделяет на ура. В отличие от чистого PHP. На то есть объективные причины:
habrahabr.ru/blogs/webdev/127906/#comment_4224465
habrahabr.ru/blogs/webdev/127906/#comment_4224465
Ну так ведь это совершенно разные логики :-)
Хотя все равно — я сторонник «академического» отделения как логики представления, так и бизнес логики от собственно самого оформления. Мухи к мухам, котлеты к котлетам. Зато у нас верстальщик может натворить шаблон зная только html, и понятия не имея о программировании, циклах, наследовании (скажите зачем вообще верстальщику это знание?) и других страшных словах.
Хотя все равно — я сторонник «академического» отделения как логики представления, так и бизнес логики от собственно самого оформления. Мухи к мухам, котлеты к котлетам. Зато у нас верстальщик может натворить шаблон зная только html, и понятия не имея о программировании, циклах, наследовании (скажите зачем вообще верстальщику это знание?) и других страшных словах.
Угу, скоро появятся шаблонизаторы для Smarty и Twig. Но пост не о том использовать шаблонизаторы для PHP или нет. Пост для тех, кто уже сделал выбор.
Увы, PHP как язык сильно расхолаживает, а использование его в качестве шаблонизатора расхолаживает ещё больше. Нужно иметь очень сильную самодисциплину, чтобы не поддаваться искушению вынести часть бизнес-логики в шаблон, а то и вообще забить на всякое разделение.
Я правильно понял, что автор переходил со Смарти 2 на Твиг?
Смарти 3 весьма не плох, так же поддерживает большинство «плюшек» твига (вроде иерархичных блоков, циклов for, вызовов методов, etc) + имеет много своих интересных и удобных вещей.
Поэтому было бы здорово почитать про сравнение Твига именно с третьей версией Смарти
Смарти 3 весьма не плох, так же поддерживает большинство «плюшек» твига (вроде иерархичных блоков, циклов for, вызовов методов, etc) + имеет много своих интересных и удобных вещей.
Поэтому было бы здорово почитать про сравнение Твига именно с третьей версией Смарти
>>Я правильно понял, что автор переходил со Смарти 2 на Твиг?
Да, скорее всего это был Smarty2
>>Смарти 3 весьма не плох
Я как-то пытался на него пересесть, но у меня не получилось это быстро сделать. Надо было что-то переделывать и чуть ли не шаблоны переписывать. Может быть я просто недостаточно разобрался.
В общем когда я пытался перейти со Smarty 2 на 3 — быстро не вышло и я забил.
>>имеет много своих интересных и удобных вещей.
А скорость работы?
Да, скорее всего это был Smarty2
>>Смарти 3 весьма не плох
Я как-то пытался на него пересесть, но у меня не получилось это быстро сделать. Надо было что-то переделывать и чуть ли не шаблоны переписывать. Может быть я просто недостаточно разобрался.
В общем когда я пытался перейти со Smarty 2 на 3 — быстро не вышло и я забил.
>>имеет много своих интересных и удобных вещей.
А скорость работы?
ghbvths c ,kjrfvb
www.smarty.net/docs/en/language.function.block.tpl#id3003118
пример с блоками
пример с блоками
до финальной версии Смарти 3, с совместимостью шаблонов действительно были проблемы. они практически решились к 3-му релиз кандидату и полностью были решены к финальной версии.
хотя, в силу ряда улучшений синтаксиса и функциональности, даже бета иногда оправдывала использование тройки.
с момента релиза тройки было сделано много работы над увеличением производительности. субъективно, 3.0.8 не медленнее двойки (вероятно быстрее) но увеличивает скорость разработки.
3.1 так же звучит многообещающе, но ждем финала.
хотя, в силу ряда улучшений синтаксиса и функциональности, даже бета иногда оправдывала использование тройки.
с момента релиза тройки было сделано много работы над увеличением производительности. субъективно, 3.0.8 не медленнее двойки (вероятно быстрее) но увеличивает скорость разработки.
3.1 так же звучит многообещающе, но ждем финала.
{for category in category_tree}
{$category.name}
{endfor}
Вместо
{foreach from=$category_tree item=category}
{$category.name}
{/foreach}
А чем это лучше обычного php?
<? foreach($category_tree as &$category): ?>
<?= $category->name ?>
<? endforeach; ?>
php не нужно отдельно парсить.
php кешируется в apc/xcache/etc.
Для шаблонов на php не нужна отдельная большая библиотека, подгружаемая каждый раз. Шаблонизатор для такого подхода пишется за 10 минут и занимает 20-30 строк.
Какие есть причины использовать smarty и другие шаблонизаторы вместо php?
Ну в данном конкретном примере оно может и не слишком различается, хотя на мой взгляд одна фигурная скобка гораздо читабельнее, чем <?..
>>php не нужно отдельно парсить.
php кешируется в apc/xcache/etc.
Также как и компилируемые шаблонизатором скрипты.
>>Какие есть причины использовать smarty и другие шаблонизаторы вместо php?
Наследование шаблонов как будем реализовывать? Шаблонизатор это не только замена переменных.
>>php не нужно отдельно парсить.
php кешируется в apc/xcache/etc.
Также как и компилируемые шаблонизатором скрипты.
>>Какие есть причины использовать smarty и другие шаблонизаторы вместо php?
Наследование шаблонов как будем реализовывать? Шаблонизатор это не только замена переменных.
Наследование шаблонов — очень просто.
Код контроллера:
Код подшаблона «partial»:
Код шаблона index:
Схематично, но должно быть понятно.
function render($template, $attributes = array()) {
extract($attributes);
ob_start();
ob_implicit_flush(0);
require "/dir/with/templates/" . $template . ".php";
ob_end_clean();
return ob_get_clean();
}
Код контроллера:
...
render("index", array("var1" => 1, "var2" => 2));
Код подшаблона «partial»:
<?= $var2 ?>
Код шаблона index:
<?= $var1 ?>
Подгружаем подшаблон <?= render("partial", array("var2" => $var2)) ?>
Схематично, но должно быть понятно.
>>extract($attributes);
У меня на extract чего-то нервный тик. :(
В итоге то что изменилось? Ну еще прилепим модификаторы потом, потом добавим песочницу, потом еще немного и в итоге все равно получится шаблонизатор. Нет разницы. Все равно шаблон компилируется один раз и дальше работает точно так же, как и написанный руками код. Но шаблоны писать проще, поддерживать проще и вообще в целом приятнее.
У меня на extract чего-то нервный тик. :(
В итоге то что изменилось? Ну еще прилепим модификаторы потом, потом добавим песочницу, потом еще немного и в итоге все равно получится шаблонизатор. Нет разницы. Все равно шаблон компилируется один раз и дальше работает точно так же, как и написанный руками код. Но шаблоны писать проще, поддерживать проще и вообще в целом приятнее.
Уважаемый, это не наследование, а инъекция. Давайте приведу понятный вам пример. У вас есть список новостей, который находится в лэйауте внутренних страниц сайта, который находится в главном лэйауте сайта. То есть, вы генерируете шаблон списка новостей, а тот сам уже себя заворачивает в специфичный лэйаут, который в свою очередь может завернуть себя в другой лэйаут и так далее. При этом, ваш шаблон списка страниц может переопределить блок (слот) в любом шаблоне (лэйауте), находящемся выше уровнем. Крайне логично, не правда ли? А теперь попробуйте мне привести пример подобного шаблона на чистом php.
С одной стороны согласен, чистое наследование (как тут) кода нужно больше.
Но в большинстве случаев хватает одного лейаута + возможности его переопределить. Т.е. при выводе из контроллера мы генерим шаблон, который вставляется в общий лейаут, либо передаём специфичный лейаут (например страница для печати).
Понятно, что это не сферический шаблонизатор в вакууме, но для многих задач этого вполне достаточно и прекрасно работает без особых проблем.
Если программисты не просыпаются ночью от кошмарного понимания того, что из шаблона нельзя переопределить лейаут, то я считаю нормальным такой подход.
Но в большинстве случаев хватает одного лейаута + возможности его переопределить. Т.е. при выводе из контроллера мы генерим шаблон, который вставляется в общий лейаут, либо передаём специфичный лейаут (например страница для печати).
Понятно, что это не сферический шаблонизатор в вакууме, но для многих задач этого вполне достаточно и прекрасно работает без особых проблем.
Если программисты не просыпаются ночью от кошмарного понимания того, что из шаблона нельзя переопределить лейаут, то я считаю нормальным такой подход.
Ну а собственно при чем тут Twig? Речь идет об управлении шаблонами, а не о том, почему нельзя использовать в них PHP.
Берем
components.symfony-project.org/templating/documentation
и всё будет )
Имхо, мне кажется, изначальный пример слишком упрощен. На уровне простых циклов и условий шаблонизатор действительно не дает никаких преимуществ.
Берем
components.symfony-project.org/templating/documentation
и всё будет )
Имхо, мне кажется, изначальный пример слишком упрощен. На уровне простых циклов и условий шаблонизатор действительно не дает никаких преимуществ.
Как относится Templating component к шаблонному наследованию, на котором построен Twig?
Давай ты мне через 30 минут покажешь готовый рабочий пример того, что я описал выше на чистом php через
Прежде чем безапелляционно заявлять что-либо, попробуй для начала сам почитать линки, которые приводишь ;-)
Давай ты мне через 30 минут покажешь готовый рабочий пример того, что я описал выше на чистом php через
Symfony\Component\Templating ;-)Прежде чем безапелляционно заявлять что-либо, попробуй для начала сам почитать линки, которые приводишь ;-)
<?php $this->extend('layout') ?>
Hello <?php echo $name ?>
Что не так? «The template engine also support multiple inheritance as explained later on.»
Это не наследование, а декорация. Фабиен попытался сделать его похожим на наследование в твиге, отсюда и неверное применение термина «наследование». Наследование вот: twig.sensiolabs.org/doc/templates.html#template-inheritance. Опять повторюсь — Twig построен вокруг идеи наследования — это основа шаблонизатора. Разница в том, что в декораторе из Templating component тебе всегда нужно рендерить содержимого дочерний слота, даже если тот переопределяет совсем другой блок. Рендеринг словно идет сверху вниз, когда как Twig обрабатывает шаблоны снизу вверх. Отсюда куча неучтенных мелочей типа
{% block title %}
{{ parent() }}
— News
{% endblock %}
UFO just landed and posted this here
Учитывая популярность шаблонизаторов, это не религия, а массовое религиозное движение
Рискну предположить, что шаблонизаторы хорошо ложатся в паттерн MVC.
UFO just landed and posted this here
Это распихивание данных в нужные места и вычисление позиции элементов относительно друг друга. Предлагаете строить списки с html, стилями и расчетом позиции блоков в контроллере? Это чистая работ для представления, на уровне которого и работает шаблонизатор. В представление отдается чисто информация нужная для вывода на конкретной странице, а представление подстраивается (исчезают какие-то блоки, меняется меню и прочее). Так что управление представление данных — это не смешивание данных и оформления.
fabien.potencier.org/article/34/templating-engines-in-php
fabien.potencier.org/article/35/templating-engines-in-php-follow-up
PHP уже давно перестал быть шаблонизатором домашних страничек. Со своей современной целью (отделение представления от логики) php в качестве шаблонизатора справляется плохо. Самые явственные минусы:
P.S.: «шорт»-тэги — зло. Об этом тысячи статей по всему интернету, так что ваш шаблон должен выглядеть вообще вот так:
fabien.potencier.org/article/35/templating-engines-in-php-follow-up
PHP уже давно перестал быть шаблонизатором домашних страничек. Со своей современной целью (отделение представления от логики) php в качестве шаблонизатора справляется плохо. Самые явственные минусы:
- Отсутствие песочницы. Все функции, описанные в глобальном скопе доступны из всех php «шаблонов».
- Отсутствие наследования. Сборка шаблона сверху вниз является нелогичной для современного дизайна и контента. Сегодня на любом проекте вы верстаете сверху вниз, но выводите контент снизу вверх, что в случае с чистым php — невозможно.
- Расширяемость. Вы можете сколько угодно доказывать, что
<? foreach($category_tree as $category): ?> <?= $category->name ?> <? endforeach; ?>
То же самое, что и
{% for category in category_tree %} {{ category.name }} {% endfor %}
Но вы никогда не сможете доказать, что
<? if (count($category_tree)): ?> <? foreach($category_tree as $category): ?> <?= $category->name ?> <? endforeach; ?> <? else: ?> No items in tree <? endif; ?>
Хотя бы близко столь же читаем, сколько
{% for category in category_tree %} {{ category.name }} {% else %} No items in tree {% endfor %}
P.S.: «шорт»-тэги — зло. Об этом тысячи статей по всему интернету, так что ваш шаблон должен выглядеть вообще вот так:
<?php if (count($category_tree)): ?>
<?php foreach($category_tree as $category): ?>
<?php echo $category->name ?>
<?php endforeach; ?>
<?php else: ?>
No items in tree
<?php endif; ?>
Цикл foreach необязательно вкладывать в условие, можно написать так:
Получается ненамного длиннее.
<?php foreach($category_tree as $category): ?>
<?php echo $category->name ?>
<?php endforeach; ?>
<?php if (empty($category_tree)): ?>
No items in tree
<?php endif; ?>
Получается ненамного длиннее.
Количество логического мусора на экране все-равно зашкаливает.
А при попытке обойти пустой массив warning не вывалится?
И да, это таки невозможно читать и поддерживать. И это при том, что строк то всего ничего!
И да, это таки невозможно читать и поддерживать. И это при том, что строк то всего ничего!
Нет, это как при
По поводу чтения — по-моему достаточно терпимо, пример довольно синтетический, при более больших блоках выглядит читабельнее, хотя кому как конечно :).
while(false) {}, цикл просто не выполнится.По поводу чтения — по-моему достаточно терпимо, пример довольно синтетический, при более больших блоках выглядит читабельнее, хотя кому как конечно :).
>>Нет, это как при while(false) {}, цикл просто не выполнится.
Только что попробовал — Warning: Invalid argument supplied for foreach() in
Только что попробовал — Warning: Invalid argument supplied for foreach() in
Я имел в виду пустой массив или объект, который можно итерировать:
Остальные аргументы дадут ошибку, конечно.
conf@conf ~ $ php -d error_reporting=-1 -d display_errors=1 -r ' echo "before\n"; foreach(array() as $item) { echo $item; } echo "after\n";'
before
after
conf@conf ~ $
Остальные аргументы дадут ошибку, конечно.
Это если передать null и т.п., а правильнее в такой ситуации передавать пустой массив.
«шорт»-тэги — зло. Об этом тысячи статей по всему интернету
Единственная разумная мысль по этому поводу: «трудности с деплойментом на shared-хостингах».
Но даже эта проблема надуманная, т.к. PHP уже давно восновном ставится в качестве модуля к апачу
Я не понимаю, почему я не должен использовать короткие теги в шаблонах?
Имхо причина одна — запретить использование php в шаблонах. Скажем есть cms для, которой сообщество пишет шаблоны, куда надежней будет не давать писать в них php код, а ограничить их возможности. Хотя особо дотошные XSS напихают, но сервер будет целей.
Дык наследование и в Smarty есть.
www.smarty.net/docs/en/language.function.block.tpl
www.smarty.net/docs/en/language.function.block.tpl
Работая со Smarty, я привык к тому, что надо передавать все переменные в шаблон и уже там их выводить, вся обработка была в коде.
{$user->free_space()}Не?
Я не утверждаю, что использовал все возможности Smarty, нет. Наверняка много можно было реализовать и там тоже. Но с Twig у меня получилось как-то проще и прозрачнее. А главное быстрее.
{$user->free_space()} и {$user.free_space} в Smarty для методов и полей соответственно, верно?
И {$user.free_space} и {$user.free_space} в Twig. Вот захочется мне потом результаты работы этого метода кэшировать в поле класса. В Smarty мне придется править шаблон (или шаблоны), а в Twig — нет. Это конечно слабенький аргумент как для определяющего при выборе шаблонизатора :).
{$user->free_space()} и {$user.free_space} в Smarty для методов и полей соответственно, верно?
И {$user.free_space} и {$user.free_space} в Twig. Вот захочется мне потом результаты работы этого метода кэшировать в поле класса. В Smarty мне придется править шаблон (или шаблоны), а в Twig — нет. Это конечно слабенький аргумент как для определяющего при выборе шаблонизатора :).
Если Twig определяет к методу он обращается или к свойству на этапе компиляции шаблона, то вам всё равно придётся либо очистить кэш, либо подправить шаблон чтобы изменилась его дата и он скомпилировался заново.
Если же он определяет это на этапе выполнения, то это минус производительности (что было вашим ключевым критерием выбора).
Соответственно вы потеряли либо в производительности, либо совершая такие правки вам надо помнить о необходимости перекомпиляции шаблонов, использующих этот метод или свойство. А если шаблоны писали не вы, то вы можете и не знать что он где-то там используется.
Так что действительно очень слабенький аргумент.
Если же он определяет это на этапе выполнения, то это минус производительности (что было вашим ключевым критерием выбора).
Соответственно вы потеряли либо в производительности, либо совершая такие правки вам надо помнить о необходимости перекомпиляции шаблонов, использующих этот метод или свойство. А если шаблоны писали не вы, то вы можете и не знать что он где-то там используется.
Так что действительно очень слабенький аргумент.
>>Соответственно вы потеряли либо в производительности, либо совершая такие правки вам надо помнить о необходимости перекомпиляции шаблонов
Производительность радует, помнить ни о чем не надо, просто пользуюсь и все. Как там что под капотом — меня не очень волнует. Не то, чтобы мне совсем не интересно, но все что я знаю — Twig выполняет свою работу и выполняет качественно. Разве еще что-то нужно? Мне — нет. Хватает и других проблем которыми приходится забивать голову.
>>Так что действительно очень слабенький аргумент.
Да они все не очень сильные. Каждый в отдельности. А всех вместе — вполне достаточно оказалось.
Производительность радует, помнить ни о чем не надо, просто пользуюсь и все. Как там что под капотом — меня не очень волнует. Не то, чтобы мне совсем не интересно, но все что я знаю — Twig выполняет свою работу и выполняет качественно. Разве еще что-то нужно? Мне — нет. Хватает и других проблем которыми приходится забивать голову.
>>Так что действительно очень слабенький аргумент.
Да они все не очень сильные. Каждый в отдельности. А всех вместе — вполне достаточно оказалось.
И часто приходится метод делать свойством и наоборот? :)
А по производительности всё же было бы неплохо увидеть какие-то цифры.
Мне на самом деле вообще сложно представить условия в которых шаблонизатор становится узким местом и его производительность столь критична.
А по производительности всё же было бы неплохо увидеть какие-то цифры.
Мне на самом деле вообще сложно представить условия в которых шаблонизатор становится узким местом и его производительность столь критична.
>>И часто приходится метод делать свойством и наоборот? :)
Да нет, это из раздела приятных мелочей.
По производительности я не возьмусь что-то оценивать. Не предвзятая и полная оценка это дело не одного дня, да и сомневаюсь я, что под силу это мне. А какие-то цифры с потолка и за уши притянутые никому не нужны и толку от них нет.
Выше есть ссылка на сравнение шаблонизаторов, там есть цифры. Позволяют понять порядок.
Да нет, это из раздела приятных мелочей.
По производительности я не возьмусь что-то оценивать. Не предвзятая и полная оценка это дело не одного дня, да и сомневаюсь я, что под силу это мне. А какие-то цифры с потолка и за уши притянутые никому не нужны и толку от них нет.
Выше есть ссылка на сравнение шаблонизаторов, там есть цифры. Позволяют понять порядок.
И третье это написание собственных расширений. Часто бывают нужны какие-то функции, не реализованные в шаблонизаторе. Расширяется twig крайне просто
С точки зрения простоты Smarty расширяется еще проще. Да, не ООП-стайл, но читаемости и функциональности это не мешает.
Не перевелись ещё люди считающие, что php == веб разработка.
Сложно разве подсветить код в топике?
Раньше я был ярым поклонником Smarty. У Smarty достаточно много достоинств, он распространен, с ним просто, он привычен и так далее. Но так вышло, что для одного из проектов Smarty оказался слишком уж тяжелым и слегка тормозным.и тогда я перешел на blitz
статей про блиц на Хабре предостаточно, но если есть пожелания Хабровчан, могу по подробнее рассказать про этот шаблонизатор
Лично мне было бы интересно сравнение с тем же Smarty. Распространенный и понятных многим шаблонизатор. Наверняка есть отличия в работе.
блица или твига?
Основное отличие — это исполняемый модуль, по этому производительность выше раз в 10.
Отличие по синтаксису: — нет плагинов, но есть кэлбэки.
В целом там немного другой подход к шаблонизации
Основное отличие — это исполняемый модуль, по этому производительность выше раз в 10.
Отличие по синтаксису: — нет плагинов, но есть кэлбэки.
В целом там немного другой подход к шаблонизации
Сравнение blitz и Smarty.
Что-то не видно там примеров применения и сравнения подходов, синтаксиса или еще чего-то подобного. А нужно как раз это. Один график — не сравнение.
вот еще более подробнее habrahabr.ru/blogs/hi/93720/
В Blitz очень много логики вывода перекладывается на контроллер. Конечно он быстрее всего чего можно (так как на C), но он почти ничего не умеет делать. С горем пополам мне удалось реализовать на нём подобие наследования с одним уровнем вложенности, это хотя бы немного упростило процесс разработки…
В общем, сейчас я считаю использование Blitz неорпавданным даже для высоконагруженных проектов. Не представляю себе систему, в которой работа с БД происходла бы быстрее генерации страницы из скомпилированного шаблона.
В общем, сейчас я считаю использование Blitz неорпавданным даже для высоконагруженных проектов. Не представляю себе систему, в которой работа с БД происходла бы быстрее генерации страницы из скомпилированного шаблона.
Когда после python (связка cherrypy+sqlalchemy+jinja2) пришлось писать проект на пыхе, я решил таки в нем воспользоваться каким нибудь шаблонизатором. В очередной раз взглянув на синтаксис шаблонов Smarty испытал рвотный рефлекс. Случайно наткнулся та Twig, и радости моей не было предела.
Слава Богу в свое время я перешел на Питон.
Чтобы не вводить читателей в заблуждение, я думаю стоит указать в статье, что вы сравниваете устаревшую версию Smarty с современным Twig, а так же о том, что в Smarty 3 (которому, к слову, уже больше года) описанные вами синтаксические недостатки всё-таки были исправлены.
Готово. Написал, что Smarty второй версии. Что там в третьей писать не буду — не знаю.
Да и не очень хочу.
Да и не очень хочу.
Это по крайней мере странно. Вы постарались сделать из Twig «почти» Smarty, чтобы вам было удобнее. Однако игнорируете факты, что описанные вами проблемы не касаются Smarty 3, для которого привычный вам синтаксис — родной.
Ничего странного в этом нет. Когда осуществлялся переход — я работал со Smarty2. Я к нему привык, работал с ним долго и он мне как родной стал. Синтаксис Smarty мне был привычен и я естественно пытался минимизировать проблемы по адаптации для себя. Пытался использовать Smarty3, но мне это не удалось. Может быть из-за того, что в то время он был еще не стабилен. Не вчера это было, а весьма давненько. Соответственно и тесты я проводил на второй версии, опирался на результаты вот того топика что выше (по второй версии результаты были вполне сопоставимы с моими) и выбрал Twig, Мне понравилось и возвращаться к Smarty у меня желания уже нет.
Провёл небольшое сравнение производительности Smarty 3.0, 3.1 RC1 и последней версии Twig. Тестировал базовые возможности: вставка значений переменных и циклы. В шаблоне вставляется значение 1000 переменных, а так же в цикле выводится содержимое массива из 1000 элементов. Результаты очень интересны.
Компиляция шаблона:
Да, медленно. Во время разработки придётся потерпеть. Но например меня больше всего интересует производительность в бою, когда сайт не в разработке, а уже работает. Очень важно, чтобы компилятор шаблона сделал свою работу качественно, и скомпилированный шаблон работал максимально быстро.
Итак, скорость работы скомпилированного шаблона:
То есть Smarty 3.0.8 в 6 раз быстрее, чем Twig. Smarty 3.1 RC1 — в 9!
Может быть я в чём-то ошибся, поэтому выкладываю архив с тестами: smarty_vs_twig.7z (169 кб., всё включено).
Прошу более компетентных в Twig проверить мой код — где я мог допустить ошибку?
Компиляция шаблона:
Twig: 0.17 секунд
Smarty 3.0.8: 1.86 секунд
Smarty 3.1 RC1: 1.83 секундыДа, медленно. Во время разработки придётся потерпеть. Но например меня больше всего интересует производительность в бою, когда сайт не в разработке, а уже работает. Очень важно, чтобы компилятор шаблона сделал свою работу качественно, и скомпилированный шаблон работал максимально быстро.
Итак, скорость работы скомпилированного шаблона:
Twig: 0.132 секунды
Smarty 3.0.8: 0.021 секунда
Smarty 3.1 RC1: 0.014 секундТо есть Smarty 3.0.8 в 6 раз быстрее, чем Twig. Smarty 3.1 RC1 — в 9!
Может быть я в чём-то ошибся, поэтому выкладываю архив с тестами: smarty_vs_twig.7z (169 кб., всё включено).
Прошу более компетентных в Twig проверить мой код — где я мог допустить ошибку?
Изучил скомпилированные версии шаблонов, и обнаружил, что Twig по умолчанию экранирует данные, на что он конечно же тратит время. Отключил экранирование ('autoescape' => false), получил 0.071 секунду в предыдущем тесте. То есть всё равно в 4-5 раз медленнее, чем Smarty.
Ещё интересным показалось то, что Smarty 3 объединяет всю цепочку из наследуемых шаблонов в один большой и затем компилирует, будто изначально и не было никакого наследования. То есть в результате при использовании наследования вообще не будет потерь производительности! К слову, при возможности Smarty 3 так же поступает с инклюдами.
Twig же старательно создал для каждого шаблона по красивому классу и файлу. И при каждой генерации страницы загружает всё это добро.
Ещё интересным показалось то, что Smarty 3 объединяет всю цепочку из наследуемых шаблонов в один большой и затем компилирует, будто изначально и не было никакого наследования. То есть в результате при использовании наследования вообще не будет потерь производительности! К слову, при возможности Smarty 3 так же поступает с инклюдами.
Twig же старательно создал для каждого шаблона по красивому классу и файлу. И при каждой генерации страницы загружает всё это добро.
Какие-то уж больно синтетические тесты. Сложно по ним реально что-то оценивать. Надо очень пристально на это дело смотреть.
кстати, в смарти можно писать более привычно {foreach $ololo as $key=>$value}{/foreach}
Sign up to leave a comment.
Как я перешел со Smarty на Twig