Какой шаблонизатор посоветуете для OpenSource проекта на Yii2?

Question

[Влад Волынец]

Собрался писать свою CMS ради опыта и использования в дальнейшей работе. Она будет OpenSource, будет расширяемость под специфические задачи модулями, некая популярность будет точно. Стоит вопрос в выборе шаблонизатора. Конструкции Yii в вьюхах не сильно дизайнер-френдли, думаю юзать шаблонизатор. Выбор между Smarty и Twig, наведите плюсы и минусы шаблонизаторов.
Юзал поиск на тостере, хабре, Google, всё что нашел посты 5-летний давности.
Так же волнует вопрос, что более легче для верстальщика.

Answer 1

[Александр Вульф]

Twig, естественно.

Comments

[Влад Волынец]

Спасибо, приму к сведению, пока не закрываю тему. Еще волнует вопрос что более предпочтительно верстальщику?

Answer 2

[Alexander Litvinenko]

один я до сих пор, спустя много лет, так и не понял зачем шаблонизатор в пхп?

Comments

[Антон Натаров]

У вас интернет магазин. предположим на одной странице отображается 50 товаров. Не важно как к вам приходит массив с данными.
Вы будете по старинке через циклы вытаскивать все данные из ассоциативных массивов и расставлять их по шаблону? Это займет очень много времени и еще больше строк кода. Когда в шаблонизаторе будет 2-3 строчки.

{% for result in result %}
{{'result.goodsTitle'| trans}}
{{result.goods}}
{% endfor %}

Таким образом я могу отобразить сколько угодно товаров. а trans - указывает на то, что существует отдельный документ с переводами. Я уже молчу о создании таблиц и ячеек, автоматом через {% if %}{% endif %}

Php и сам является шаблонизатором, но с ним много возни.

[Alexander Litvinenko]

Антон Натаров: вы только что написали те же три строчки что и "по старинке через циклы"

<? foreach( result as result): ?>
vs
{% for result in result %}

<? endforeach; ?>
vs
{% endfor %}

[Влад Волынец]

Alexander Litvinenko: А о
{{'result.goodsTitle'| trans}}
{{result.goods}}
Вы забыли ? Наведите аналогию с php и сравните.

[MegaMufa]

Антон Натаров: Да что вы говорите?

<?php foreach ($results as $result) { ?>
    <?= \Yii::t('trans', $result->getTitle()); ?>
    <?= $result->getGoods(); ?>
<?php } ?>

То же самое, только без необходимости учить еще один язык разметки. Плюс перевод надо делать в модели, а во вьюху отдавать уже переведенный текст.

А если программист использует массивы вместо объектов (читай не использует ORM), то шаблоны ему не мало погоды сыграют.

[MegaMufa]

Антон Натаров: Частичное применение шаблонов тоже есть, наследование тоже можно сделать. Единственный плюс шаблонизаторов - автоматическое экранирование текста. Но во-первых это надо в небольшом количестве мест (там, где мы выводим данные введенные пользователем). Во-вторых экранировать лучше при внесении и в бд держать уже нормальный текст.

[Влад Волынец]

HaruAtari: Хорошо, а "песочница" в некоторых шаблонизаторах играет роль, как думаете ? "ограниченный набор тэгов, фильтров и методов объектов" документация твига.

[Alexander Litvinenko]

Влад Волынец: полностью не расписывал, в виду понятности остальных строк по аналогии, но спасибо HaruAtari за доп. разъяснения.

[MegaMufa]

Влад Волынец: Не совсем понял о чем вы, не могли бы поянить подробней. Если вы о возможности вывода только некоторых html тегов, то, как я уже писал выше, я считаю, что это надо обрабатывать при внесении в бд. Там обрезаем или экранируем лишнее, а выводим как обычный текст.

[Alexander Litvinenko]

HaruAtari: скорее даже при выводе, в бд практичней хранить оригинальный ввод.

[Влад Волынец]

HaruAtari: "Сверхбезопасный режим «песочницы» (список допустимых тегов, фильтров и методов которые разрешены в шаблоне)", грубо говоря. Программист определяет, какие возможности может использовать разработчик шаблона. В итоге даём верстальщику доступ к фтп именно папки шаблонов и работает, и не трогает код, даже толком не знает его структуры. По-моему неплохое преимущество.

[Alexander Litvinenko]

Влад Волынец: "Сверхбезопасный режим «песочницы»", Программист, разработчик шаблона.
Мне кажется здесь подменяют понятия.

разработчик шаблона - верстальшик?
Программист - человек интегрирующий шаблон в среду?

Верстальщик создает шаблон исходя из макета, сам ресурс ему ненужен, у вас разве не так?

[MegaMufa]

Влад Волынец: Мне кажется это смутное преимущество. Как замечали выше, шаблонами чеще пользуется не верстальщик, а программист. А у него и так полный доступ к коду. Мне кажется бузсмысленно ограничивать его в этом.

[MegaMufa]

Alexander Litvinenko: Зачем каждый раз при выводе обрабатывать текст, если можно сделать это один раз при вводе? Если вы предполагаете, что в будущем может, например, измениться список допустимых тегов, то можно держать еще и оригнальный текст.

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

[Влад Волынец]

HaruAtari: разве не безопасней будет давать верстальщику доступ только к шаблону, без доступа к коду? Кеширование само собой. А разработчик шаблона употребил вместо верстальщика.

[MegaMufa]

Влад Волынец: Шаблон подразумевает под собой логику. Верстальщику надо будет знать, какие объекты передаеются в шаблон, какие у нах есть поля и методы. Плюс в Yii вьюхи (они же шаблоны) не лежат в webroot, а раскиданы по внутреним директориям: у каждого контроллера/виджета своя вьюха. Если вы хотите, ограничить верстальщика только директориями с шаблоном, то вам придется изгаляться чтобы это сделать.

Проще программиста заставить это делать. У нас тоже есть отдельный верстальщик, фронтенд и бэкенд разработчики. ФРонтенд разработчик пишет код и складывает его в assets директорию (или вообще отдельно, если это sibglepage приложение). Его можно ограничить. А верстальщик просто делает html файлы и стили к ним с рыбными данными. Отдает нам на бэкенд и мы его уже на куски режем, разносим по вьюхам и добавляем логику.

Учитывайте что логика отображения, которая есть во вьюхе, может быть сложнее чем обычные циклы. Например вы показываете список постов и автору надо показать кнопочку редактирования. Вы можете передать в шаблон id текущего пользователя и сравнить его с id автора. Но по уму это делается в отдельном методе, чтобы скрыть реализацию проверки. А есть составные сложные условия.

Мы на своем опыте убедились, что допускать верстальщика до хоть какой-нибудь логики себе дороже.

[MegaMufa]

Денис Иванов: >> "Плюс перевод надо делать в модели, а во вьюху отдавать уже переведенный текст." А можно пруф линк на это? Или аргументы, почему этим должна заниматься модель, если мы говорим об обычном i18n

Пруфов не приведу, но аргументировать могу. Замечу сразу, это касается перевода полей модели, а не перевода статичных текстов из вьюхи. Просто тексты, конечно же надо переводить во вьюхе.
- Перевод в модели позволяет делать это в одном месте. Если вы выводите название товара в разных местах, зачем везде лепить перевод?
- Перевод в модели скрывает реализацию. Если вы решите перенести эту фразу в другой словарь, вам не надо будет бегать по всему коду и менять это.
- Все-таки это не логика отображения, а логика самого приложения. Ведь мы меняем не просто внешний вид названия, а фактически само название.

[MegaMufa]

Денис Иванов: Это во вьхи надо переводить, вы правы. Просто в примере показаны обращения к полям, вот я про них и написал.

[Влад Волынец]

HaruAtari: никто не запрещает написать комментарий "для вывода имени пользователя используйте {{ user }}". И можете думать что он знает что приходит имя пользователя и надо её так выводить. Все вьющихся сдержаться в своей папке, и никто не мешает переопределить структуру, если что. Я предпочитаю что бы каждый занимался своим делом. Дать дизайнеру доступ к папке views, не сложно, и ничем не грозит, хотя можно файлы шаблона в отдельную директорию, обрабатывать въехали, и выходить

[Влад Волынец]

Ещё безопасней получится, вообще, вопрос стоял "посоветуйте шаблонизатор", а не, "использовать шаблонизатор или нет? ", так что я думаю прекратить флуд.
P.S. Грамматика страдает, потому что с телефона пишу, извините.

[MegaMufa]

Влад Волынец: И не говорю, что использовать шаблонизатор нельзя. Просто, как по мне, гемороя это создает больше, чем пользы.
- Надо выеживаться, чтобы дать доступ только к папкам вьюх. Переопределять их не можно, но не стоит, если этот код потом поддерживать кому-то. Тем более вы же не через ftp организовываете взамидействие, а через git?
- Плюс структура может постоянно менять: добавляются контроллеры, экшены, выносятся общие части в partial вьюха, модули.
- Верстальщику надо объяснить, как yii со вьюхами работает, какая вьюха куда относится.
- Коментарыи о доступных переменных и для php надо будет оставлять типа /** @var User[] $users */. Но для php IDE по ним еще и автокомплит сделает (не в курсе шаблонизатор подерживает автокомплит?), а ненадо будет поля объекта описывать и потом следить за актуальностью.

Опять таки, сложные проверки прав через checkAccess() вы тоже из шаблонизатора будете делать?

Я не говорю, что шаблонизатор не нужен, но на мой взгляд, для Yii он мало пользы принесет. Может для клиентских sibglepage приложенй, где все в одном месте лежит, он и подойдет.

[Алексей Скобкин]

HaruAtari:

не в курсе шаблонизатор подерживает автокомплит?

PhpStorm автодополняет в Twig и функции, и методы, и свойства объектов. И подсказывает пути файлов при наследовании других шаблонов.

[Влад Волынец]

HaruAtari: 1. Продукт будет использоваться среднестатистическими админами сайтов и мной, git только для себя, так то)
2. Согласен. А что это меняет ?
3. С названия вьюхи видно, и никто кастомные имена не отменял. По-моему толком ничего не надо, всё нужное ему видно и так.
4.Допустим, в чём сложности ?
5. Автокомплит есть, как минимум у твигл. А зачем там проверки прав ?

[MegaMufa]

>> 3. С названия вьюхи видно, и никто кастомные имена не отменял. По-моему толком ничего не надо, всё нужное ему видно и так.
То, что это очевидно вам, не значит, что это будет очевидно человеку, не работавшему с yii

>> А зачем там проверки прав ?
Я выше пример приводил уже.

[Alexander Litvinenko]

HaruAtari: сохранять оригинал ввода в бд на всякий случай, завтра заказчик может потребовать другие параметры вывода.

[Alexander Litvinenko]

Денис Иванов: о моделях, MVC подразумевает не только модели доступа к таблицам бд, моделью есть любое средство доступа к данным. Если мы говорим о каком либо компоненте i18n, то у него тоже есть внутренний контроллер и есть свои средства доступа к данным, в любом случае это не отменяет что вам понадобятся дополнительные телодвижения, для интеграции любого компонента в шаблонизатор.

[Alexander Litvinenko]

Денис Иванов: средства получения данных а не сами данные. Разве вы не нарушите собственное правило, использовать шаблонизатор, если обратитесь к компоненту i18n через синглетон например, а не через средства шаблонизатора?

[Alexander Litvinenko]

Денис Иванов: но ведь именно про это я и говорю, много комментов, можно запутаться кто какую сторону защищает. Вообще можно еще много насчет второстепенных факторов поспорить, но давайте это уже в другой теме, в пределе этой темы так понимаю у защищающей стороны не нашлось актуальных аргументов в пользу шаблонизатора.

Answer 3

[Антон Натаров]

Используйте Твиг, он не только более функциональный чем Smarty 2/3, но и быстрее в три раза, кушает меньше памяти при компиляции и использует меньше памяти при скомпилированных шаблонах.

Comments

[Влад Волынец]

Спасибо, приму к сведению, пока не закрываю тему. Еще волнует вопрос что более предпочтительно верстальщику?

[Антон Натаров]

Влад Волынец: ИМХО конечно. Но верстальщики нынче занимаются только разметкой страницы. html5+css3+Js+Bootstrap. Шаблонизаторы прерогативы Back-end разработчиков, поскольку в них есть иногда и наследования и ООП, циклы и многое другое, о чем верстальщик может знать мало или не знать вовсе. Менять шаблон под свои нужды будет менять человек, который работает в бек энде. Я уже молчу про Ангуляр или другой синтаксический сахар.

Проще говоря, очень повезет, если вы найдете верстальщика, который будет знать это все и грамотно этим пользоваться. чаще будут джуны на php, которые будут это верстать =)

[Влад Волынец]

Антон Натаров: {{ var }} или echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8'); есть разница ? Один из многих пример. Шаблонизатор не необходимость, а просто желательная возможность.

[Антон Натаров]

Влад Волынец: Вы правы.

[Антон Натаров]

Влад Волынец: Но внимательно изучите возможность Yii2. Суть в том, что в Yii2 шаблоны сильно интегрированы в фреймворк: лайауты, виджеты, регистрация метатегов, ассеты, кэширование и прочее. По этому Твиг скорее излишество =)

[Влад Волынец]

Антон Натаров: я знаю. Но настолько сильно. Сам Yii предлагает использовать Twig или Smarty. Так что сомневаюсь что излишества.
Yii сложноват для дизайнера, пример:
NavBar::begin([
'brandLabel' => 'My Company',
'brandUrl' => Yii::$app->homeUrl,
'options' => [
'class' => 'navbar-inverse navbar-fixed-top',
],
]);
В Twig синтаксис получше)

[Виталий Хоменко]

Влад Волынец: Вы думаете подключив Twig это все сразу пропадет? Нет :)

[Влад Волынец]

Виталий IIIFX Хоменко: Я думаю, оно будет более верстальщик-френдли

Answer 4

[Алексей Скобкин]

Twig. У него даже есть расширение PHP для ускорения работы.