Здравствуйте.
Много слышал про такой шаблонизатор как Smarty. Выпало немного свободного времени, решил по изучать, но возник вопрос. А насколько он широко используется и актуален ли сейчас? Или это уже устаревшие вещи?
Заранее спасибо всем отозвавшимся.
Alexander Litvinenko: верно. за исключением что "противоположное мнение" обычно популярно только у тех, кто залип в php, не знает/использует ничего другого и занимается мизерными проектами в одиночку.
DevMan: хм.. но тогда что со мной? Почему я признаю пользу шаблонизаторов в других языках, в частности еще хорошо владею Node.js и на начальном уровне RoR и Python, занимаюсь различными проектами, от простых сайтов до соц сетей, включая работу в команде, но считаю бесполезным шаблонизатор имено в PHP.
я сказал "зря", ваше право согласиться или нет.
объяснять почему "зря", тем более человеку, использующему шаблонизаторы на других стеках, не вижу смысла, от слова вообще. особенно после того как вам это обьясняли уже не раз.
Alexander Litvinenko: у меня просто не было желания повторять то, что вам было сказано не раз.
но если у вас короткая память, то хороший шаблонизатор предоставит:
- автоэскейпинг
- наследование
- высокая или абсолютная независимость от платформы
- всякие полезняшки в виде фильтров (что избавляет от необходимости городить городушки в шаблонах или лезть в код) и дополнительные ништяки для циклов
- невозможность выполнения кода в шаблоне, соответственно меньше пространства для выстрела в яйцо и прочие косяки
- чистый синтаксис, вместо кучи открывающих/закрывающих php-тэгов (особенно для управляющих конструкций)
наверняка что-то упустил, но даже перечисленного мне достаточно для выбора в пользу шаблонизатора.
DevMan: вы уже злитесь, не потомули что не углублялись в контр аргументы? напомню.
- автоэскейпинг
Это одна команда, что в шаблонизаторе, что в PHP
- наследование
Это одна команда, что в шаблонизаторе, что в PHP
- высокая или абсолютная независимость от платформы
Аргумент, но часто ли сохраняют старый дизайн, когда проект переписывают в нуля, на другом языке? Недумаю что это когдалибо используется.
- всякие полезняшки в виде фильтров (что избавляет от необходимости городить городушки в шаблонах или лезть в код) и дополнительные ништяки для циклов.
Та самая логика, от которой пытаетесь избавится, только другими буквами написана.
- невозможность выполнения кода в шаблоне, соответственно меньше пространства для выстрела в яйцо и прочие косяки
Пункт выше говорит что это нетак.
- чистый синтаксис, вместо кучи открывающих/закрывающих php-тэгов (особенно для управляющих конструкций)
Вместо `<?= ..... ?>` ставить `{{ ..... }}` ? Большое преимущество.
У меня всего один агрумент против
Зачем подключать библиотеку, для того чтобы вместо `<?= ..... ?>` ставить `{{ ..... }}` ?
Так как мы наконец аргументировали свое мнение, далее думаю каждый рещит для себя какие преимущества существенны
> автоэскейпинг
> Это одна команда, что в шаблонизаторе, что в PHP
да ну? в шаблонизаторе автоматически эскейпятся все переменные, мне вообще об этом думать не нужно.
> наследование
> Это одна команда, что в шаблонизаторе, что в PHP
покажите как одной командой в готовый php-шаблон подключить другой шаблон и заменить в нем часть верстки с информацией или добавить ее.
а может вы поклонник спагетти-кода? тогда вопросов больше не будет.
> высокая или абсолютная независимость от платформы
> Аргумент, но часто ли сохраняют старый дизайн, когда проект переписывают в нуля, на другом языке? Недумаю что это когдалибо используется.
"не знаю" не означает "не существует". я неоднократно сталкивался как с миграцией целых проектов на новый стек, так и их отдельных частей. дизайн разумеется оставался прежним либо полностью, либо практически полностью.
может откроете страшную тайну как дизайн связан со стеком?
> - всякие полезняшки в виде фильтров (что избавляет от необходимости городить городушки в шаблонах или лезть в код) и дополнительные ништяки для циклов.
> Та самая логика, от которой пытаетесь избавится, только другими буквами написана.
от какой логики и кто пытается избавиться?
> - невозможность выполнения кода в шаблоне, соответственно меньше пространства для выстрела в яйцо и прочие косяки
> Пункт выше говорит что это нетак.
это именно так.
> - чистый синтаксис, вместо кучи открывающих/закрывающих php-тэгов (особенно для управляющих конструкций)
> Вместо `<?= ..... ?>` ставить `{{ ..... }}` ? Большое преимущество.
сам шучу - сам смеюсь?
код
<?php if ($a == 5): ?>
A равно 5
<?php elseif ($a == 6): ?>
A равно 6
<?php else: ?>
А не равно ни 5 ни 6
<?php endif; ?>
выглядит гораздо лучше, чем
{% if a == 5 %}
A равно 5
{% elseif a == 6 %}
A равно 6
{% else %}
А не равно ни 5 ни 6
{% endif %}
да? а код
<ul>
{% for user in users if user.active %}
<li>{{ user.username }}</li>
{% else %}
<li><em>no active user found</em></li>
{% endfor %}
</ul>
можете переписать на php сами и порадоваться.
> У меня всего один агрумент против
> Зачем подключать библиотеку, для того чтобы вместо `<?= ..... ?>` ставить `{{ ..... }}` ?
если вы шаблонизатор используете только для этого, то действительно незачем.
> автоэскейпинг
> > Это одна команда, что в шаблонизаторе, что в PHP
> > > да ну? в шаблонизаторе автоматически эскейпятся все переменные, мне вообще об этом думать не > > > > нужно.
да ну? в шаблонизаторе вам ненадо никак указывать, если переменную эскейпить ненадо? одинаково пишется когда надо и ненадо экскейпить?
> наследование
> > Это одна команда, что в шаблонизаторе, что в PHP
> > > покажите как одной командой в готовый php-шаблон подключить другой шаблон и заменить в
> > > нем часть верстки с информацией или добавить ее.
> > > а может вы поклонник спагетти-кода? тогда вопросов больше не будет.
К примеру в Yii это `beginContent` и схожие команды, которые есть в подавляющем числе фреймворков. В чистом пхп это require\include, но думаю вы всеже имели ввиду случай с фреймворками.
> высокая или абсолютная независимость от платформы
> > Аргумент, но часто ли сохраняют старый дизайн, когда проект переписывают в нуля, на другом
> > языке? Недумаю что это когдалибо используется.
> > > "не знаю" не означает "не существует". я неоднократно сталкивался как с миграцией целых
> > > проектов на новый стек, так и их отдельных частей. дизайн разумеется оставался прежним либо
> > > полностью, либо практически полностью.
> > > может откроете страшную тайну как дизайн связан со стеком?
Могу только поздравить что вам это пригодилось, на связь дизайна со стеком, в контексте вопроса, думаю вы сами ответите.
> - всякие полезняшки в виде фильтров (что избавляет от необходимости городить городушки в шаблонах или лезть в код) и дополнительные ништяки для циклов.
> > -Та самая логика, от которой пытаетесь избавится, только другими буквами написана.
> > > -от какой логики и кто пытается избавиться?
думаю объяснять что цикл в шаблоне или фильтр в шаблоне - это логика, не нужно.
> У меня всего один агрумент против
> Зачем подключать библиотеку, для того чтобы вместо `<?= ..... ?>` ставить `{{ ..... }}` ?
> > если вы шаблонизатор используете только для этого, то действительно незачем.
Пример с кодом выше.
Alexander Litvinenko: > одинаково пишется когда надо и ненадо экскейпить?
по дефолту эскейпятся все переменные.
если не нужно эскейпить какую-либо переменную, можно отключить эскейпинг для нее.
теперь сравните какой подход требует меньших телодвижений.
> В чистом пхп это require\include, но думаю вы всеже имели ввиду случай с фреймворками.
у вас нормально с прочтением и пониманием написанного?
вы точно владеете рельсами и питоновскими фреймворками?
какой шаблонизатор используете для ноды?
сравнивать require/include с наследованием может только человек, который не понимает о чем речь.
если не в курсе, то хоть поинтересуйтесь что такое template inheritance.
> на связь дизайна со стеком, в контексте вопроса, думаю вы сами ответите.
погодите, вы же сами пишете что со сменой стека меняется и дизайн. связь то какая?
> думаю объяснять что цикл в шаблоне или фильтр в шаблоне - это логика, не нужно.
нужно объяснить фразу "Та самая логика, от которой пытаетесь избавится".
кто пытается избавиться и, главное, зачем?
или вы можете предемонстрировать шаблон, не имеющий логики отображения?
> Пример с кодом выше.
никакого примера вашего кода не наблюдаю.
DevMan:
> одинаково пишется когда надо и ненадо экскейпить?
> > по дефолту эскейпятся все переменные.
> > если не нужно эскейпить какую-либо переменную, можно отключить эскейпинг для нее.
> > теперь сравните какой подход требует меньших телодвижений.
Безусловно ескейпить переменные надо чаще, но изучать ради этого еще один язык? пускай каждый решает для себя.
> В чистом пхп это require\include, но думаю вы всеже имели ввиду случай с фреймворками.
> > у вас нормально с прочтением и пониманием написанного?
> > вы точно владеете рельсами и питоновскими фреймворками?
> > какой шаблонизатор используете для ноды?
> > сравнивать require/include с наследованием может только человек, который не понимает о чем > > > > речь.
Вам удобно выделять пару слов, опуская остальную фразу? про require\include было написано в весьма понятном контексте. В ноде Jade/EJS. Сами то как?
если не в курсе, то хоть поинтересуйтесь что такое template inheritance.
> думаю объяснять что цикл в шаблоне или фильтр в шаблоне - это логика, не нужно.
> > нужно объяснить фразу "Та самая логика, от которой пытаетесь избавится".
> > кто пытается избавиться и, главное, зачем?
> > или вы можете предемонстрировать шаблон, не имеющий логики отображения?
аплодирую стоя, нить разговора соблюдена чудесно.
> Пример с кодом выше.
> > никакого примера вашего кода не наблюдаю.
Ваш код, ваш собственный код который вы написали выше.
Alexander Litvinenko: > Безусловно ескейпить переменные надо чаще, но изучать ради этого еще один язык?
какой язык? какой изучать?
любой шаблонизатор осиливается за несколько часов. да и эскейпинг - не единственная плюшка.
> про require\include было написано в весьма понятном контексте.
контекст был весьма понятен: "покажите как одной командой в готовый php-шаблон подключить другой шаблон и заменить в нем часть верстки с информацией или добавить ее".
require\include это не решает.
> В ноде Jade/EJS
в jade есть наследование шаблонов. и я тем более не понимаю как человек, знающий это, может тулить require\include как альтернативу.
> аплодирую стоя, нить разговора соблюдена чудесно.
да хоть лежа в гамаке. про логику и избавление от нее здесь гутарите только вы.
> Ваш код, ваш собственный код который вы написали выше.
ну если код вида
<ul>
<?php if(count($users)):
foreach($users as $user):
if($user['active']): ?>
<li><?= $user['username'] ?></li>
<?php endif;
endforeach;
else: ?>
<li><em>no active user found</em></li>
<?php endif; ?>
</ul>
для вас выглядит более лучше, чем
<ul>
{% for user in users if user.active %}
<li>{{ user.username }}</li>
{% else %}
<li><em>no active user found</em></li>
{% endfor %}
</ul>
и готовы терпеть даже такой банальный пример ради того, чтоб не "подключать библиотеку" (наверное микроволновки программируете), то шаблонизаторы реально вам не нужны.
кактус же вкусный, и не требует библиотек.
DevMan: лучше не будет, наш код ничем не отличаетстя, у вас в коде просто {% ... %}, у меня <? ... ?>. Вы написали три оператора в одну строку, я разнес на три абзаца, оба плохо читаются неподготовленным человеком.
Alexander Litvinenko: любой код плохо читается неподготовленным человеком.
если для человека шаблонизатор состоит только и исключительно в "{% ... %} вместо <? ... ?>", то он ему действительно не нужен.