Язык шаблонов против обычного PHP

Языки шаблонов для PHP являются примером анти-шаблона под названием «эффект внутренней платформы». " Smarty является примером структуры шаблонов для PHP, но даже Хасин Хейдер, автор книги о Smarty, говорит, что Smarty мертв, и его больше не нужно использовать.

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

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

Не пишите функции PHP для инкапсуляции блоков вывода HTML. Вместо этого используйте include() для извлечения фрагментов HTML. Эту технику иногда называют «частичными».

Вы также можете использовать инфраструктуру MVC, такую ​​как Symfony, Kohana, Solar, CodeIgniter или Zend Framework, чтобы помочь вам соблюдать дисциплину при отделении кода шаблона PHP от остальной части кода вашего приложения.

Я долгое время был очень счастливым пользователем Smarty, больше не верю в специализированные языки шаблонов.

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

Довольно тривиально создать собственную маленькую систему шаблонов, которая использует php в шаблонах. Затем создайте различных помощников, чтобы ваш код шаблона оставался чистым (например, функция "navigation ()").

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

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

Изобретать колесо - в большинстве случаев плохая идея.

PHP уже является языком шаблонов. Вам не нужно реализовывать свои собственные.

Что касается Smarty, это наиболее полная система шаблонов для php, и это все еще плохая идея.

Пара статей по теме:

• Жил-был Smarty! Хасина Хайдера. На самом деле он написал книгу о smarty и не рекомендует ее.

• Php и шаблоны Гарри Фуэкса (автора 1-го издания антологии php)

Если вы хотите посмотреть на шаблоны, сделанные лучше, посмотрите:

• phpSavant использует код php и по-прежнему способствует разделению проблем.

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

Вы можете изучить Smarty - http://smarty.php.net Smarty - очень мощный механизм шаблонов это дает вам лучшее из обоих миров. Он имеет обширную поддержку пользовательских модулей и плагинов.

Я создал собственную CMS с помощью Smarty и PHP и могу сказать о ней только хорошее.

PHP-код для использования Smarty выглядит так

<?php
// my cms

$smarty = new Smarty();
.
.
$smarty->display('home.tpl');

?>

Код шаблона выглядит примерно так

<h1>{$pagetitle}</h1>

{insert tag="navigation"}

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

Здесь или там легко забыть htmlspecialchars (), поэтому язык шаблонов, который предоставляет директивы, такие как {$ name}, должен гарантировать, что $ name автоматически передается через htmlspecialchars, с соответствующей кодировкой и всем остальным.

Конечно, это также означает, что вы можете указать другой «контекст» для вывода переменных, например, alert ('Привет, {$ name | context = singlequotes}!'); где интерпретатор шаблона будет экранировать содержимое $ name, чтобы невозможно было выйти из одинарных кавычек, вместо экранирования XML (что должно быть по умолчанию).

Такие контексты также могут включать такие вещи, как int (для принудительного ввода числа), и он также может быть расширен, чтобы принимать дополнительные параметры для форматирования вывода и т. Д.

Мои 2 цента. Не уверен, что есть решение с открытым исходным кодом, которое позволяет это (было бы интересно услышать об этом!), Я использовал свой собственный интерпретатор для этого на работе. Поскольку результирующий «промежуточный код» является чистым PHP, его также можно очень легко «кэшировать» (как это делают Smarty и другие системы tpl).

Мне очень нравится Smarty, и я также считаю, что контроллеры должны быть написаны исключительно на XML, а модели - на YAML. Это единственный способ обеспечить соблюдение MVC.

Если вопрос производительности возникает только тогда, компиляция на php может рассматриваться как возможность (хотя и удаленная) с условием sine qua non, что это делается запутанным образом, чтобы помешать нетерпеливым разработчикам прочитать ее.