В заметке CMS для разработчиков я пообещал, что рассмотрю более подробно выбор CMS для подхода «Инструменты для удобства разработки». Пока я обдумывал, что написать по этому вопросу, пришел к выводу, что не смогу вести разговор без единого понятийного аппарата, иными словами без «системы координат». Кроме того, вопрос показался мне слишком сложным для одной заметки.
Продолжая эти мысль, я решил не писать сразу о выборе такого многопланового инструмента, как CMS, а остановиться, для начала, на конкретных компонентах. Сегодня таким компонентом станет шаблонная система.

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

PHP, как шаблонная система

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

Этот позорный факт часто ставят в укор PHP-разработчикам, которых итак не особо жалуют в «продвинутом» IT собществе. Но об этом поговорим как-нибудь в другой раз. Сегодня нас интересует другое. А именно то мнение, что раз этот язык изначально задумывался, как шаблонная система, то зачем «городить огород» из разных технолгий. Давайте писать шаблоны, вставляя «php-врезки» в верстку сайта.

Такого метода придерживаются многие популярные CMS системы — WordPress, 1C-Bitrix, NetCat (частично) и другие.

Что в этом методе хорошего?

• Не надо обучать разработчиков отдельно шаблонной системе. Они уже знают php и смогут быстро включится в проект.
• Разработчик всегда может найти в коде конкретную переменную или функцию и посмотреть откуда она берется или что делает.
• Это быстрее работает, т.к. нет лишнего звена между интерпретатором языка и шаблоном.

Что тут не так?

• Велик соблазн вставить кусок логики в шаблон. Такие действия не пресекаются на уровне системы.
• Больше мусора. Как минимум открывающий и закрывающий теги его создают.
• Вывод в шаблон привязан к особенностям системы. Если мы поменяем функцию, то нам придется менять её и в шаблоне. Мы открываем свой «внутренний мир» тому, кто привязывает шаблон к бекэнду.
• Если ошибка произойдет прямо в шаблоне то нам сложно будет её найти и разобрать. Это связано с тем, что часть страницы на тот момент уже выведется и мы можем на понять, что ошибка произошла перед каким-нибудь закрывающим тегом из-за чего у нас полная каша.

Отдельная шаблонная система

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

%title%

до блоков типа:

{foreach from=$myArray item=foo}
{$foo}
{/foreach}

При определенном идет таких договоренностей верстальщик может сразу сделать из HTML-верстки нужный шаблон для внедрения. Ну или по крайней мере подготовить его к этому. Это экономически целесообразно, хотя на практике целиком такое получается крайне редко. Такого подхода придерживатся: Umi.cms , Drupal(опционально), Symfony framework и многие другие проекты.

Что в этом методе хорошего?

• Пропадает необходимость контролировать разработчиков по разделению логики представления от бизнес-логики. Используя «шаблонизатор» мы точно уверены, что никакая часть бизнес-логики не «просочится» в шаблон.
• Шаблон в итоге выглядит чище. Это не абсолютное правило, но тенденция.
• Мы можем разделить права. К примеру дать кому-то права изменять только шаблоны и мы будем уверены, что он не «докопается» до базы данных, например.

Что тут не так?

• Меньше скорость работы. Однако, при использовании кеширования этот минут сходит на нет.
• Требует отдельного изучения. Правда, как правило, структура шаблона достаточно простая для понимания разработчиками.

Вывод

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