Почему (не)стоит использовать шаблонизатор?

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

Собственно сабж. Часто попадаю в конфликтные ситуации по этому поводу, которые часто
заканчиваются совокуплением с мамой чьей-либо стороны.

Многие "выбирают" шаблонизаторы из-за того, что php отдельно, html отдельно... Но
чем плох такой вариант:

PHP:

$title = "Some Title";
$text = "Some Text";
$images = array(
                  0 => "img1",
                  1 => "img2",
                  2 => "img3"
                );

require "template.html";


HTML:




   



По сути же: шаблонизатор — это php, написанный на php... Или я что-то упускаю?

Ссылаться на популярность Smarty среди верстальщиков не катит

Ответ аля это стандарт де-факто меня тоже не устраивает
    

Ответы

Ответ 1

Однозначного ответа тут нет.
Самый главные вопросы:
Как вам удобнее с ним или без?
Вы делаете для себя или для людей?
Мне удобнее работать со Smarty.

{$aaa}


   


{foreach $images AS $img}
   
{/foreach}

Только не стоит забывать о том, что помимо тупой передачи чего-то в шаблон, шаблонизатор
имеет массу других полезных фич.
Если делаете для себя, то делайте как удобнее. Если для других, то возможно шаблонизатор
будет удобнее.


Ответ 2

Само использование стиля написания кода в виде , тоесть без явного указания
PHP () не всегда является удачным. На некоторых серверах такой вариант записи
запрещается. Подробней об этом сказано здесь » short-open-tag


Бесмысленный закрывающий тег PHP приводит к неудачным и непредвиденным последствиям
во всем проекте, что в последствии заберет много времени на поиски проблемы. Если уж
не говорить, что весь проект придется таки действительно переписать на MVC с использованием
шаблонизатора.


Удобство, время. Один из факторов почему стоит применять шаблонизатор в практике
- быстрое изменение или переписания шаблона, не задевая програмной части. Почему стоит
использовать шаблонизатор, читайте » здесь


Какой из шаблонизаторов в быстродействии лучше?

шаблонизатор Fenom
Smarty против XSLT


Ответ 3

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


Ответ 4

потому что заблонизатор - это не только вывод переменных, это еще и ряд очень полезных
механизмов, например самый важный это - наследование шаблонов http://twig.sensiolabs.org/doc/templates.html#template-inheritance


Ответ 5

По-моему, шаблонизатор нужен для безопасности
Т.к. шаблоны могут писать разные люди, надо запретить им возможность вставлять в
шаблон код


Ответ 6

Долго программировал на перле, с тех времен, когда CGI был королем. Привык к отделению
шаблона еще с тех времен. И для меня лучший шаблонизатор — свой.

Задаем в шаблоне место вывода переменной, например [var1], место включений [incl#file.ext],
модуль — [mod#LineNav], условия — {if logged=['superadmin','admin']}{/if} — дальше
простая обработка регулярками и полный контроль (надо условия — запросто, передать
параметр в модуль — пожалуйста).


Ответ 7

Шаблонизатор упрощает жизнь верстальщикам.
А этого достаточно, ( я так понимаю только для этого он и делался ).


Ответ 8

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

Избыточный синтаксис
При попытке вывода сложных структур данных, шаблон на нативном пшп
   превращается в ад if-ов, isset(), и
   им подобных тестов. Да, можно глушить
   все и вся с помощью собаки(@), но мы
   автоматически резко теряем в
   производительности.

Да-да, минусаторы, вы просто ничего слаще редьки не пробовали) А по сложности ничего
сложнее персональных бложеков не делали)
Изначально шаблонизатор PHP был написан на perl, но его создатель, решил переписать
его на си, ибо производительности перла не хватало. Да будет вам известно, что изначально
PHP следовало понимать, как Personal Home Page Tools, ну, из названия уже ясно, что
это набор утилит для создания простых персональных страничек-визиток. Далее PHP стали
называть Personal Home Page/Form Interpreter(PHP/FI). Ну, а потом чуваки из израиля
обнаружили фатальный недостаток в этом творении и если верить вики, полностью. переписали
код персональных домашних страниц. С тех пор, PHP следовало понимать как PHP: Hypertext
Preprocessor, и он оброс дополнительным функционалом, и появилась возможность засерать
глобальное пространство имен ядра все новым функционалом. 
Вот таким вот образом, шаблонизатор стал уметь подключаться к БД, понимать всякие
xml, и уметь расширяться. 
И все-бы ничего, но проблемы, которые Я описал выше сводят на нет простоту этого
шаблонизатора, как шаблонизатора. Конечно, можно настроить этот шаблонизатор так, чтобы
он не кидал нотисы при обращении к несуществующим переменным, или атрибутов объектов
при выводе на печать, но от этого случается баттхерт у правильных крутых программистов,
которые яро считают, что любого рода ошибки и сообщения нужно не игнорировать, а обрабатывать.
Собственно, таким образом шаблоны и разрастаются кучами if-ов.
Далее, более грамотные ребята поняли, что дальше так жить нельзя, и шаблонизатор
должен работать именно как шаблонизатор, т.е., тупо выводить наборы данных используя
шаблоны, но поскольку php к тому времени становился все популярнее, они решили запиливать
свои собственные версии шаблонизаторов на языке php. Так вот и появился парадокс того,
что шаблонизаторы пишут на шаблонизаторах.
Забавно, но в других Я.П. такой проблемы нет) Например, python используется чисто
для написания логики приложения, в то время, как для вывода результатов данных используются
специально написанные для этого шаблонизаторы(jinja2, mako, etc...). Причем, шаблоны
получаются весьма простыми и понятными. В них нету этого ада, присущего шаблонам на php.