Какой шаблонизатор взять для нового проекта на php?

Question

[casey]

Многие по-инерции используют Smarty, кто-то пробует Twig, кто-то — экзотический Blitz, вот хочется узнать мнение общественности.


Blitz на мой взгляд имеет существенный недостаток — высокие трудозатраты на разработку, так как требуется плотное взаимодействие дизайнера и программиста для изменений и для быстрой разработки/прототипирования, на мой взгляд, не очень подходит.


Из Smarty-подобных систем мне же известен только Twig, быть может есть еще хорошие варианты? От шаблонизатора хочется объектности и расширяемости.

Answer 1

[Владимир Чернышев]

Хороший шаблонизатор, идеально интегрирующийся с PHP называется… PHP :) В шаблонах удобно использование альтернативного синтаксиса.

Comments

[Сергей]

Основная проблема — нет автоматического экранирования, так что повышается вероятность словить XSS уязвимость.
Ну и стандартное — «если из шаблона можно делать SQL запросы, то это уже подозрительно»

[Владимир Чернышев]

С экранированием да, проблема. А вот вторая, кажется, частично решена. Недавно был пост о phpdaemon, с помощью которого как-то (так и не вник ещё) реализуются песочница.

[Сергей]

песочница с помощью php runkit sandbox www.php.net/manual/en/runkit.sandbox.php реализуется, но я тоже не пробовал это.

[Александр Токмаков]

Сергей, public function xss($data)

public function xss($data)
    {
        if (is_array($data)) {
            $escaped = array();
            foreach ($data as $key => $value) {
                $escaped[$key] = $this->xss($value);
            }
            return $escaped;
        }
        return htmlspecialchars($data, ENT_QUOTES);
    }

Answer 2

[Сергей]

XSLT советую. Для него можно XML-ку собрать каким нить SimpleXML — очень удобно. Каждый модуль проекта может в один и тот же объект SimpleXML вставлять свои данные а потом XSLT уже выбирает то, что ему нужно.

Из плюсов — хорошо переносится между языками (если вдруг понадобится), можно с помощью тех — же XSLT попробовать реализовать REST API. Да просто довольно правильный стиль навязывает при создании шаблонов. Опять же, для NGINX есть модули для XSL трансформации внутри него (хотя смысла делать шаблонизацию внутри легкого асинхронного веб-сервера я лично не вижу)

Если умудриться распарсенные шаблоны каким-то образом сохранять в памяти между запросами (на PHP трудно реализуемо пожалуй) то вообще летать будет.

Comments

[Сергей]

А! Насчет объектности не совсем понял, XSLT все-таки функциональный язык программирования… Но наследовать шаблоны можно, изменять поведение наследованием (overwrite шаблонов) тоже можно.

Расширяемость пожалуй не очень хорошая, зависит от XSLT процессора, но в любом случае если что — существует EXSLT

Кстати! В большинстве IDE есть подсветка и автоподстановка кода!

[Сергей]

Насчет расширяемости еще вспомнил — можно регистрировать в XSLT процессоре собственные PHP функции и использовать их из шаблона. Иногда очень полезно бывает если например с датами приходится работать или какие-то сложные преобразования с данными.

Еще момент — фактически встроенная защита от XSS уязвимостей (фактически надо сильно постараться чтобы допустить XSS уязвимость)

Еще момент — XSLT можно использовать как фильтр пользовательского ввода если в нем разрешены html теги (такие теги можно, такие нельзя, у таких можно только такие атрибуты с такими значениями, такие теги заменяем на вот такие и т.п.)

[DevMan]

Ещё момент — найти грамотного специалиста по XSLT весьма непросто. Проходили год назад.

[Thomas]

Ещё момент — найти грамотного специалиста по XSLT весьма непросто. Проходили год назад.

Я когда-то верстальщика с нуля за месяц научил XSLT шаблоны делать. ;)

[DevMan]

Научить можно и за неделю-две-четыре, но такого человека я не смогу назвать грамотным специалистом.

[DevMan]

который сможет создавать сложные шаблоны.

[Владимир Чернышев]

XSLT интересный вариант, но сколько раз не пытался освоить на живых проектах, всё как-то не идёт, видимо потому, что приходится решать две задачи одновременно — представление объектов/массивов в виде XML (например решать, должен ли контроллер выдавать один XML файл, где есть всё для формирования страницы, или допустить вызов других контроллеров из шаблона (да ещё непонятно как это лучше сделать), то есть распределить ответственность между котнроллерами, представлять значения полей в виде атрибутов или вложенных элементов и т. д. и т. п.) и преобразование его в HTML (вроде сделал удобно читаемый человеком XML, но начинаешь вытягивать из него данные и ужасаешься на XPath).

А распарсенные шаблоны можно, наверное, хранить в кэше типа memcache или xcache/eaccelerator.

[Искандер Гиниятуллин]

мы на своем проекте некоторые редко изменяющиеся места страниц (баннерные места, «популярное за месяц» и т.д.) парсим отдельно и сохраняем в memcache, и отдаем в шаблон уже готовый html код

[impass]

есть XSL Cache для кэширования XSL шаблонов

[Искандер Гиниятуллин]

xsl cache не работает на windows-машинах
У нас все разработчики работают под windows, с ходу потестировать не получится, но спасибо за наводку

[Сергей]

Кстати да! XSL Cache для PHP работает. Не замерял разность в скорости, но на реальном проекте использовал его.
(а в Memcache распарсенный шаблон хранить плохой вариант, т.к. в мемкеше PHP объекты сериализованными в виде строки хранятся, насчет xcache/eaccelerator не знаю)

Answer 3

[Mikhail Davydov]

Twig — наследование шаблонов, компиляция шаблонов в читабильный вид (класс), все лучшее от Smarty, sandbox, авто экранирование строк, есть готовые классы для интеграции практически во всех фрэймворках. Blitz — очень не удобно работать с шаблонами, мне показался очень тугим для разработки. Скорость Blitz… это сомнительное преимущество, — компилированные шаблоны твига + eAccelerator не будут уступать Blitzу.

Answer 4

[Rodion Gashe]

всё время удивляло почему в PHP люди ищут какие-то шаблонизаторы.
сам язык — мощнейший шаблонизатор.

всё остальное, кроме XSLT+XML — от лукавого.

Answer 5

[KooL]

Smarty

Comments

[zt50]

а можно расшифровать кратко, и существенно, почему минусуют?

[casey]

Smarty — банально и старо. Вопрос был в новых подходах.

Answer 6

[Thomas]

Может посмотрите в сторону XSLT? Очень высокая отделяемость кода от представления. По скорости помедленней наверно будет чем вышеописанные. Но удобство работы с ним часто перечеркивает все минусы.

Comments

[Искандер Гиниятуллин]

по скорости у него все ок если с шаблонами не перемудривать

Answer 7

[Dmitry Dedukhin]

CTPP2

Плюсы:
— высокая скорость работы
— расширяемость (можно добавлять свои функции)
— один набор данных для шаблонизации на сервере и на клиенте (JSON)
— недавно появился модуль для шаблонизации силами nginx, он пока не production-ready, но думаю быстро станет таковым

Comments

[casey]

Спасибо, первый раз сталкиваюсь!

[AGvin]

Шаблонизатор, действительно хороший, но, забыли упомянуть минусы:
— Минимальный набор функций «из коробки». Заменить определенный символ в строке, попросту нету возможности.
— (для php-программистов) строгая типизация типов данных
— (если не ошибаюсь) проект держится на энтузиазме нескольких разработчиков. Я на их месте, выложил бы проект в github.

Answer 8

[s5656]

никакой, использовать нативные шаблоны

Answer 9

[mayhem]

никак не пойму чем шаблонизаторы на пыхе лучше и удобнее самого пыха.

Comments

[DevMan]

Тем, что мухи отдельно, котлеты отдельно.

[casey]

• Дают возможность развязать код предоставления данных (например запрос из БД) и код их отображения (например группировка по первым буквам)
• предоставляют готовые инструменты для рутинных задач — например определение первого/последнего/четного элемента в перебираемомсписке
• позволяют работать вместе программисту и верстальщику, не мешая друг другу

[Сергей]

• если шаблонизатор сделан правильно, в нем не нужно писать htmlspecialchars(blabla)

[mayhem]

возможно я не правильно выразился, постараюсь уточнить: чем шаблонизаторы на пыхе, не использующие нативного синтаксиса пыха, лучше и удобнее использующих его. Это я в огород Smarty, Quicky, Blitz и им подобным камень бросаю. Как по мне количество букв для вывода переменной не является аргументом, я быстро печатаю. Иногда еще приводят в аргумент то что дизайнер не должен учить php, но при этом его заставляют учить синтаксис шаблонизатора. Хотя может я давно не в теме, я Zend'ом пользуюсь

Answer 10

[developer]

Quicky:
habrahabr.ru/blogs/php/45337/
code.google.com/p/quicky/wiki/Manual
у меня в опубликованных есть еще обзоры квики. я пользуюсь уже 2 года

Answer 11

[akzhan]

Сейчас очень многие смотрят в сторону HAML + SASS.

Эти языки пришли из мира Ruby и сейчас есть их адаптации практически для всех значимых языков.

Например, для PHP можно смотреть phphaml.sourceforge.net/, www.yiiframework.com/extension/haml-and-sass/ и так далее.

Comments

[m_z]

многие это кто?) выглядит ужасно, зачем так HTML то портить

[akzhan]

Это вы просто не привыкли еще. На самом деле очень удобно.
На основной странице языка видно разницу: haml-lang.com/ (также можно посмотреть blog.digimonkey.com/2010/02/why-use-haml-and-sass-i-already-know-html/).

Кстати, для Коханы тоже есть, — forum.kohanaframework.org/discussion/6097/releasing-phamlp-module-for-kohana-use-haml-and-sass-with-kohana-3.0/p1

Answer 12

[Vertex]

Еще один плюс в сторону Smarty: Eclipse + Smarty Plugin = фришная и удобная связка. После перехода на Mac это единственное комфортное IDE для пыха.

Общее отвечу для тех кто отписывает что «PHP сам хороший шаблонизатор»:
Вы или не работали с крупными проектами, или я сочувствую тем кто их поддерживает. Разделение логики и представления по дефолту должно быть. XSLT+XML — подходит; Smarty, Twig — тоже. А вот КОД в HTML — это реально от лукавъго.

Comments

[casey]

Хороший ответ, спасибо!