На Deep-CMS «напал»:

Typical Programmer

Нужны ли нам шаблонизаторы?

В настоящий момент в интернете можно найти огромное количество споров на эту тему. И чем больше мы вчитываемся в эти споры на форумах, тем более становится понятным, что тема настолько остра, насколько это только можно предположить. Если бы мы жили во времена Трои или Александра Македонского — основной причиной войн между государствами были бы споры о шаблонизаторах.

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

Достоинства:

  • Полное разделение вывода от логики приложения;
  • Режим «песочницы»;
  • Аккуратный внешний вид блоков логики или операторов вывода;
  • Переносимость между платформами (языками) — т.е. парсер шаблонов можно написать на чем угодно;
  • Язык шаблона понятен «верстальщику»;

Недостатки:

  • Увеличение времени работы приложения (генерации конечной страницы);
  • Увеличение расходуемых ресурсов приложения;
  • Невозможность писать непосредственно в шаблоне любой исполняемый код;
  • Шаблон возможно применить только на той платформе, в контексте которой он был написан;
  • Язык шаблона понятен не всякому «верстальщику»;

О достоинствах

Рассматривая вопрос разделения логики приложения от вывода, можно сказать что отделение логики от вывода применяется в разработке web-приложений в основной своей массе только при использовании паттерна MVC. Посмотрите сами, так и есть, все примеры использования разделения шаблонов и логики показаны в контексте MVC.

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

Нельзя не согласиться, что, действительно удобно использовать конструкции внутренней изолированной логики шаблона вне зависимости от платформы (php, ROR, java), которая будет разбирать эти шаблоны и заполненняя их данными, выводить пользователю. Кроме того это гарантирует, что разработчики не станут использовать в шаблоне логику приложения или вовсе SQL-запросы.

Режим «песочницы» бывает очень кстати, когда необходимо дать пользователю, редактору шаблонов, ограниченные возможности синтаксиса. Например это актуально для сервиса блогов, где пользователи самостоятельно размещают материалы используя html-разметку и спецефичные конструкции используемого сервиса.

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

А Вы задумывались почему? Да все потому, что такие шаблоны могут предоставить только ограниченный набор возможностей. Например это всего-лишь условный оператор, оператор цикла, оператор непосредственного вывода значения переменной и оператор подключения другого шаблона.

По сути этого набора вполне достаточно для отрисовки страниц. Но когда Вам понадобится что-то более сложное — тут же начинаются «танцы с бубном». Читая ваши мысли, вот пример:

<?php
function colorer($k) {
  $k+=2;
  return $k%5==0?'blue':($k%4==0?'red':($k%3==0?'purp':'green'));
}
?>

<php foreach ($items as $k => $item) { ?>
  <div class="<?=colorer($k)?>"><?$item?></div>
<?php } ?>

Данный код выводит в цикле различные четыре CSS-класса для цветового оформления блоков. Можно легко изменить логику на большее или меньшее число цветов, если того потребует задача. Это самый простой пример. А могут быть ситуации куда более сложные, чем эта. Ни один шаблонизатор не предоставляет возможности создания логики вывода «на лету».

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

О недостатках

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

Исходя их этого, использование шаблонизатора — непростительное расточительство. А если вспомнить времена не очень отдаленные, то при написании программ дорожили каждым байтом занимаемым в памяти. Для этого было даже специальное слово — «Бамминг». Когда программисту удавалось сократить использование памяти на 2-3 байта, он с удовольствием сообщал об успехе коллегам, как он красиво «Баммнул» свой код.

О шаблонизаторах в целом

Существует огромное количество тестов производительности различных шаблонизаторов. Повторять их, и в очередной раз выкладывать результаты нет никакого смысла. К настоящему моменту я уже потерял хорошую страничку с сравнительными тестами десятка шаблонизаторов, в которых лидирует шаблонизатор Twig. Найдя её повторно, я обязательно дам на неё ссылку.

Если быть честным — Twig мне самому очень нравится. Нравится не с той стороны что его синтаксис сильно отличается в лучшую сторону от остальных шаблонизаторов, а с той, что он интересно сделан внутри. И именно из-за нестандартного для php подхода проектирования шаблонизатора, он и занимает лидирующую позицию.

Так чем же он так отличается от остальных шаблонизаторов? Да хотя-бы тем, что вместо обычного нативного php-кода он компилирует свои шаблоны в классы вида:

class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template
{
  public function display($context)
  {
    $this->env->initRuntime();

    // line 1
    echo "Hello";
    echo (isset($context['name']) ? $context['name'] : null);
  }
}

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

Кроме того, очень важным моментом является повторное использование кода. Так если другой шаблонизатор будет повторно подключать шаблон и исполнять его еще раз, то Twig просто выполнит ранее подключенный автолоадером класс. А это уже порядочное увеличение производительности.

Резюме

В настоящий момент в Deep-CMS действует концепция отсутствия каких-либо шаблонизаторов. Однако, исходя из внутренней структуры, шаблонизатор Twig пойдет ей только на пользу. Правда он будет немного модифицирован чтобы можно было вызывать в шаблоне те компоненты, которые можно вызывать сейчас. В любом случае, использование шаблонизатора Twig нисколько не повредит делу, более того, только улучшит общую ситуацию.

На самом деле на вопрос «Нужны ли нам шаблонизаторы?» можно было ответить очень просто: «Да, нужны, но только в том случае, если это оправдано».

 

Deep: 2013-11-12 04:09:06 (обновлено 2014-01-26 15:30:48)

Оставить комментарий

Комментарии:

protection