Шаблонизаторы vs быстродействие, удобство, гибкость

#php #шаблонизаторы

Надеюсь, что не подниму сейчас холивар) В общем-то всегда удивлялся фанатам шаблонизаторов
и хочется послушать аргументы в их пользу. Не понимаю, какой смысл в написании псевдокода
на псевдоязыке, который либо компилируется, либо (омфг) транслируется во время запроса
к странице, который к тому же реально сложнее для восприятия. Скомпилированный код
того же smarty, по сравнению с нативным шаблоном, захламлен чем-то явно лишним, сам
код намного менее гибок, чем php, малопонятные конструкции циклов, пляски с бубном
на банальном разделении контента в 3 столбика, etc etc...
Но при этом даже здесь от "старожилов" и явно не глупых людей слышу постоянно "используйте
шаблонизаторы типа Смарти". Итак, вопрос: а, собственно, зачем?
ЗЫ: Я не против шаблонизаторов в принципе(только извращений типа псевдокода с "компиляцией").
То, с чем я работаю, работает по такому принипу (минимальный код):
function assignTemplate($file, $tmpl, $params = array()) {
  ob_start();
  if (!is_file($file)) {
    echo 'No file';
    } elseif(!is_file($tmpl)) {
    echo 'No template';
    } else {
    require $file ;
    ob_end_clean();
    ob_start();
    require $tmpl ;
    }
  $result = ob_get_contents();
  ob_end_clean();
  return $result;
  }
    

Ответы

Ответ 1

Суть шаблонов, - абстрагировать верстку от кода на PHP, облегчить верстальщикам (а
не программистам) работу. По чему не стоит писать свой шаблон координально синтаксически
отличающийся от сматри и иже с ним? Дело в том, что верстальщику легче привыкнуть к
одному языку шаблонов (или использовать его подмножество), чем под каждый проект изучать
свой (особенно если он на жизнь зарабатывает фрилансом).

Мощные шаблонизаторы по типу смарти, благополучно транслируют свой код в пхп и кэшируют
его (поэтому замедление будет заметно только при трансляции нового шаблона в код, дальше
все будет работать из кэша). Да, он не читаемый, но он и не должен быть читаем человеком,
для человека есть текст шаблона, который он должен изменять. 
P.S. Могу поспорить каждый писал свой шаблонизатор, еще и потому что это легче чем
изучать чужой и пользоваться им (прошу не обижаться, я сам такой :) ).


Ответ 2

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


Ответ 3

Шаблоны предназначены для:
 1. разделения логики и представления;
 2. упрощения написания и последующего чтения кода.
Шаблон — это domain-specific language. Smarty, в этом плане, это не особо интересен
— разницы между «» и «{{ if $foo }}» не очень много, хотя она есть
— и не только синтаксическая. Посмотрите, например, на Jade (реализация для PHP) —
это более интересный и наглядный пример, как DSL упрощает жизнь.


Ответ 4

Мне очень полюбился процессор XSLT. Работает быстро, без нареканий, кое-где есть
тонкости, но уж очень подкупает своей простотой. Кроме того, использование дополнительной
обработки результатов именно в шаблоне тоже удобная "фича". Под-шаблоны и т.п. мелочи,
которые делают все немного приятнее.
Кроме того, легко можно привинтить ко многим интерпретаторам, лично я работал с ним
на PHP и VB.
Думаю, что и к фрейм-воркам легко его можно прикрутить, одной функцией в десять строк
он встраивается в Codeigniter.
Не претендую на панацею, но как вариант, возможно кому-то тоже приглянется.


Ответ 5

Только программист пишет, например, на php, а верстальщик на языке шаблонов. Ну и
зачем два   языка, если PHP сам по себе шаблонизатор?
В чем преимущество {$msg} над  <?=$msg?>?  Как  ни  крути, а  некие  скриплеты
 втыкать надо. 
Мне очень полюбился процессор XSLT. Работает быстро, без нареканий, кое-где есть
тонкости.  Тонкость одна: ему  надо скармливать XML. То есть делать разметку, которую
XSLT превратит  в другую разметку.