Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Шаблоны можно использовать только, если их может редактировать конечный пользователь. В других случаях это бесполезная трата ресурсов.
{% for item in navigation %}
{% call procedurename(item) %}
{% endfor %}
<?php foreach($navigation as $item): ?>
<?= procedurename($item) ?>
<?php endforeach ?>
Само собой. Не усмотрел, где это утверждение противоречит тому, что я написал.
Я так понял два куска кода это пример, что эти вещи можно сделать без шаблонизатора?
Я так понял два куска кода это пример, что эти вещи можно сделать без шаблонизатора?
А теперь давайте пример с наследованием, автоматическим экранированием и сандбоксом. Шаблоны компилируются в нативный php, так что оверхед не такой большой, как вам кажется. Если же в вашем приложении шаблоны действительно являются узким местом, попробуйте Си расширение.
Кстати да. Когда начинал им пользоваться — его еще не было. Пару-тройку месяцев назад наткнулся на сайте на информацию о нативном расширении, был приятно удивлен.
Ну, строго говоря, сандбокс — это очень ограниченная область применения (которую, собственно, и имел в виду первый комментатор), а остальное делается просто.
Пока из реальных проблем нейтива я столкнулся только с одной — автоискейпинг для свойств объектов. В то время как для скаляров и массивов он реализуется элементарно, для объектов это действительно — головная боль.
Пока из реальных проблем нейтива я столкнулся только с одной — автоискейпинг для свойств объектов. В то время как для скаляров и массивов он реализуется элементарно, для объектов это действительно — головная боль.
Шаблонизатор прямо как от Django.
Я встречал еще другие шаблонизаторы(для php и nodejs) которые оч похожи на джанговские.
Вообще оч люблю Django шаблоны, хотя чаще пользуюсь Jinja2(он похож на джанговский но быстрее и еще некоторые различия).
Раз уж вам так нравится Twig, советую обратить свое внимание на Django или Flask)
Я встречал еще другие шаблонизаторы(для php и nodejs) которые оч похожи на джанговские.
Вообще оч люблю Django шаблоны, хотя чаще пользуюсь Jinja2(он похож на джанговский но быстрее и еще некоторые различия).
Раз уж вам так нравится Twig, советую обратить свое внимание на Django или Flask)
Упс, хотел написать в общую.
Представьте себе, я как раз этому очень обрадовался, начав обхаживать Python и Django. Сейчас на фриланс полностью уйду и буду шевелить это дело — Python в первом приближении нравится, Django тоже.
Автор Twig, Fabien Potencier, в общем-то и не скрывал, где черпал вдохновение. Да, это порт шаблонизатора Django. С некоторыми изменениями, конечно. Например, в Twig теги комментария {# #} работают на группу строк, а в Django только на одну. Полагаю, что и других изменения полно, так как Twig развивается весьма активно.
Ну в Django если надо на много строк то
мне так кажется даже лучше и нагляднее.
Я стараюсь и блоки тоже более наглядно закрывать. Например, такой блок
Я чаще пользую Jinja2 и с Django и c Flask. Там тоже
У меня один из любимых шаблонизаторов это у Tumblr =)
{% comment %}многабукаф и строк{% endcomment %}мне так кажется даже лучше и нагляднее.
Я стараюсь и блоки тоже более наглядно закрывать. Например, такой блок
{% block content %} проще закрывать так {% endblock %}, а я же закрываю так {% endblock content %} чтобы нагляднее было какой именно блок закрывается.Я чаще пользую Jinja2 и с Django и c Flask. Там тоже
{# тут много строк и можно {%%} #}У меня один из любимых шаблонизаторов это у Tumblr =)
Ваше заявление касается только случая, когда шаблоны обрабатываются в runtime, однако если шаблоны компилируемые (как в Smarty или как в Twig), то с большой вероятностью Вы не сможете вручную сделать исполняемый код быстрее, чем код скомпилированного шаблона. Я уже не говорю о кэшировании, которое в случае шаблонизатора добавляется буквально двумя строками кода и сводит на нет «преимущества» приведённого Вами лапшекода.
Раз мы говорим о Yii то там кеширование добавляется буквально двумя строчками кода в любом случае. Да и работа с php шаблонами там достаточно сильная.
sdevalex имел ввиду шаблоны вообще, если я правильно понял… А в Yii кэширование куска шаблона тоже можно сделать двумя строчками кода?
Там есть кеширование страницы, куска шаблона, sql запроса, и данных. Конкретно кусок шаблона кешируется так
К слову в Yii встроен шаблонизатор Prado и соответственно есть сильная его поддержка. К примеру аналог кеширования фрагмента будет таким.
<?php if($this->beginCache('cacheKey')) { ?>
<?php $this->endCache(); } ?>К слову в Yii встроен шаблонизатор Prado и соответственно есть сильная его поддержка. К примеру аналог кеширования фрагмента будет таким.
<cache:cacheKey>
</cache:profile >Вы просто отчаянную ерунду написали. Умудрились наделать ошибок практически в каждой строчке.
1. Шаблоны нужны не для редактирования пользователем, а для разделения бизнес-логики и логики отображения. Чтобы одни и те же данные можно было выводить в разном виде, не трогая код приложения. Пример: один и тот же движок стоит на разных сайтах. Если используется шаблонизация, то обновление движка сводится к простой заливке кода. Если шаблонизация не используется — под каждый сайт движок надо редактировать отдельно. ещё пример: одно и то же приложение может возвращать как HTML, так и JSON. Если для первого использовался шаблонизатор, то добавить второе можно не трогая код. В противном случае код придется переписывать (и дублировать).
2. В случае с Twig никакой бесполезной траты ресурсов нету — шаблон транслируется в тот же самый РНР код.
3. Приведённый пример РНР кода тоже вполне может быть шаблоном (что повсеместно и используется)
4. Мог бы быть, точнее. Но не является, из-за непонятной функции procedurename(), которая, если что-то выводит и реализована в коде приложения, убивает идею шаблонизации на корню.
5. Пост был совсем не об этом.
1. Шаблоны нужны не для редактирования пользователем, а для разделения бизнес-логики и логики отображения. Чтобы одни и те же данные можно было выводить в разном виде, не трогая код приложения. Пример: один и тот же движок стоит на разных сайтах. Если используется шаблонизация, то обновление движка сводится к простой заливке кода. Если шаблонизация не используется — под каждый сайт движок надо редактировать отдельно. ещё пример: одно и то же приложение может возвращать как HTML, так и JSON. Если для первого использовался шаблонизатор, то добавить второе можно не трогая код. В противном случае код придется переписывать (и дублировать).
2. В случае с Twig никакой бесполезной траты ресурсов нету — шаблон транслируется в тот же самый РНР код.
3. Приведённый пример РНР кода тоже вполне может быть шаблоном (что повсеместно и используется)
4. Мог бы быть, точнее. Но не является, из-за непонятной функции procedurename(), которая, если что-то выводит и реализована в коде приложения, убивает идею шаблонизации на корню.
5. Пост был совсем не об этом.
Ссылка на использованный twig-extension для Yii некорректная.
А вообще было круто написать свой экстеншен для Twig который бы делал {% css 'url' %}
Там дело пяти минут — могу сделать. Зачем только? Yii.app.clientScript.registerCssFile долго писать?
Да ;)
может вы и автолоадом в пхп не пользуетесь? =: О только инклуды! только хардкор!
Пользуюсь-пользуюсь :) Просто уровень лени, толкающий на автоматизацию, у всех разный. У меня он таков, что конструкции, описанные в примере, меня не раздражают — мне удобно их писать, удобно их читать.
А {% css 'url' %} я для вас обязательно напишу — мне не сложно. Могу даже вдогонку и {% js 'url' %} написать
А {% css 'url' %} я для вас обязательно напишу — мне не сложно. Могу даже вдогонку и {% js 'url' %} написать
Если устроит {{ css('url') }}, можно обойтись и макросом.
Не силён в Yii, объясните, чем не подходит такой вариант:
layout.html.twig
page.html.twig
layout.html.twig
{% block javascripts %}
<!-- global js files -->
{% endblock %}
page.html.twig
{% extends "layout.html.twig" %}
{% block javascripts %}
{{ parent() }}
<!-- page js files -->
{% endblock %}
Конечно, можно сделать и так.
У использования clientScript есть некоторые преимущества, такие как возможность организовать обработку подключенных файлов перед их выводом (навскидку приходит на ум склеивание js и css в единые файлы), выбор места подключения js-файла — в head, в начало body, в конец body. Также можно определить именованные пакеты файлов и подключать их одним вызовом.
Я привык пользоваться clientScript, мне удобно.
У использования clientScript есть некоторые преимущества, такие как возможность организовать обработку подключенных файлов перед их выводом (навскидку приходит на ум склеивание js и css в единые файлы), выбор места подключения js-файла — в head, в начало body, в конец body. Также можно определить именованные пакеты файлов и подключать их одним вызовом.
Я привык пользоваться clientScript, мне удобно.
В очередной раз так и не понял зачем в Yii нужен twig, все что описано и так довольно легко реализуется, в yii в начале выполняется шаблон страницы(в этот момент можно поменять layout), а после — layout, оба выполняются из контроллера и имеют к нему доступ, тот же заголовок можно задавать и выводить через $this->title, блоки реализованы в виде CBaseController::beginClip, вложенные layout присутствуют.
Сложность php шаблонов, имхо, надуманная проблема, переносимость шаблонов между системами крайне редко нужна, а если и понадобится — подобный фукционал можно легко реализовать.
Сложность php шаблонов, имхо, надуманная проблема, переносимость шаблонов между системами крайне редко нужна, а если и понадобится — подобный фукционал можно легко реализовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
За что я люблю Yii+Twig: динамическое подключение нужных скриптов