Вся Правда О Шаблонизаторах

Статья старая, но думаю она по-прежнему актуальна В последнее время я слишком часто слышу слово «шаблонатор».

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

Одни говорят, что логика в шаблонах — это хорошо, другие считают, что это зло.

Даже сейчас очень часто встречаются проекты, написанные вообще без использования какого-либо шаблонизатора.

Но в этой статье я не буду пытаться занять чью-либо сторону.

Я не буду вам доказывать преимущества какого-либо из подходов.

Я просто попытаюсь рассказать обо всех из них с теоретической точки зрения.

Эта статья не о конкретных программных продуктах, а о способах выделения логики представления в ваших приложениях.

Условия В этой статье используется ряд терминов, которые могут быть вам незнакомы.

Я попытаюсь дать определение некоторым из них.

Презентация – логика приложения, отвечающая за отображение данных.

Для WEB-приложений это логика, генерирующая HTML-страницу.

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

Выражения «бизнес-логика» и «предметная логика» по сути являются синонимами.

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

Шаблон, Стандартное решение – решение часто встречающихся проблем.

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

Более того, это жаргонный термин.

На самом деле все гораздо сложнее и требует глубокого и вдумчивого понимания предметной области.

Мы вернемся к этому позже, а пока давайте посмотрим на суть проблемы.

Дело в том, что слово «шаблонатор» часто считают синонимом слова «презентация».

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

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

Так что это все миф.

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

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

И наоборот, можно использовать Smarty, но при этом полностью всё запутать и переплести.

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

Разделение HTML и PHP Вот тут-то все и началось.

Любой из вас помнит те незапамятные времена, когда все вокруг восхищались способностью PHP проникать в HTML-код, становясь его частью.

Благодаря этому понимание языка значительно упростилось.

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

Даже те, кто понимал, что PHP на самом деле ничего не знает о HTML (как и HTML о PHP), а только отображает текст, были рады, что им не пришлось писать кучу печатного текста.

Это так просто! И эта простота создала проблему.

Борщ Борщ только на первый взгляд кажется хаосом.

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

А если добавить еще немного капусты, еще соли и немного воды.

Будет невкусно.

В борще главное не переборщить (простите за каламбур).

На самом деле никто не хотел зла.

Просто новый язык, конечно, привлек новых программистов.

Это новички, которым польщена простота, удобство и мощь PHP. Тогда мы еще не знали ни о каком MVC. Мы не думали о проблемах сопровождения кода, читаемости и стабильности.

Это сработало, и мы были этому искренне рады.

Но вскоре мы поняли, что борщ становится невкусным.

Сбивающие с толку чередования PHP и HTML поначалу стало слишком сложно понять.

Изменение дизайна вообще обернулось кошмаром.

Мысль о том, что мы когда-то это уже написали, стала навязчивой, но место, где этот код уже был написан, найти было крайне сложно.

Еще сложнее было его вытащить оттуда и вставить в новый проект. Но хватит лирики.

Разными путями мы пришли к пониманию того, что нам нужно отделить HTML-код от PHP-кода.

И здесь мы узнали слово «шаблонатор».

Что такое шаблонизатор? Это программа, предназначенная для отделения кода PHP от кода HTML. Бытует мнение, что это необходимо дизайнерам.

На самом деле, я ни разу не встречал дизайнеров (извините, верстальщиков), которые бы сразу выкладывали шаблоны.

Но дело не в этом.

На самом деле программистам было плевать на верстальщиков.

Сами уже устали удовлетворять новые изыски дизайнеров, перелопачивая при этом весь код. К этому моменту программисту уже надоел любой код, смешанный с PHP. По крайней мере, я полностью отказался от какой-либо логики в HTML. Мой шаблонизатор мог повторять куски кода (блоки), включать другие файлы, но ни о какой логике речи не шло.

Я потратил все выходные на написание своего шаблонизатора.

Я был горд и считал себя самым правильным программистом.

Но вскоре проекты стали более сложными.

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

Бизнес-логика и логика представления Наконец мы дошли до сути.

На самом деле мы немного переборщили с извлечением логики из HTML-кода.

Стараясь писать правильно, что похвально, программисты взяли курс на полное отделение PHP от HTML. Как будто в мире существуют только эти 2 языка.

Но на самом деле PHP и HTML — это всего лишь инструменты.

Более того, инструменты дополняют друг друга.

Вы, вероятно, не станете утверждать, что HTML определяет внешний вид вашего сайта.

А PHP отвечает за создание этого представления на основе данных.

Но можно ли четко разделить PHP и HTML? Конечно, нет! PHP по-прежнему определяет, как будет выглядеть ваша страница[[*1]].

Получается, что HTML — это только презентация, а PHP занимается не только получением данных, но и определяет, как, где и в каком объеме их показывать.

Вернемся к тому, что мы оставили.

Получается, что PHP от HTML невозможно отделить? Я скажу больше.

И это не обязательно! Реальный вопрос не в том, отделять ли PHP от HTML, а в том, где их отделить.

Логика представления Логику любой программы можно разделить на две составляющие — логику, которая получает и обрабатывает данные[[*2]] и логику, которая отображает их пользователю.

Первая называется бизнес-логикой, а вторая — логикой представления.

Важно уметь четко разделять эти 2 типа логики, чтобы они не перепутались.

Применительно к веб-программированию можно с абсолютной уверенностью сказать, что HTML относится к логике представления, а база данных — к части бизнес-логики.

Но между ними еще много PHP-кода.

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

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

Этот стереотип появился не просто так.

Помните, что когда-то мы смешали код PHP и HTML. Потом мы узнали, что не стоит этого делать, а следует использовать шаблонизаторы.

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

Я не пытаюсь сейчас сказать, что нужно смешивать.

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

Важно понимать, что вопрос о том, смешивать PHP и HTML-код или нет, не имеет ничего общего с разделением двух логик.

Можно их смешивать, а можно четко разделять, и при этом говорить, что в программе эти логики хорошо разделены.

Понимание этого очень важно.

Если вы четко разделяете PHP и логику представления, то вы глубоко заблуждаетесь.

Например, Smarty, самый популярный шаблонизатор, не использует в своих шаблонах чистый PHP. Но тем не менее он компилирует свои шаблоны и в результате получается смесь PHP и HTML. Два типа презентации Спор о том, использовать логику в шаблонах или нет, вечен.

Ведь даже Мартин Фаулер говорит о двух типах уровня представления: представление по шаблону и представление с преобразованием[[*3]].

Представление шаблона Например, всем известен Smarty. Данные передаются в шаблоны Smarty, а шаблон сам определяет, как отображать эти данные.

Но представьте, что эта возможность уже встроена в PHP! На самом деле скажи мне, что

Отличается ли PHP от шаблона Smarty? Чем теги Smarty ({}) отличаются от тегов PHP ()? Да, по сути то же самое! Помните, как более опытные коллеги говорили вам, что смешивать PHP и HTML-код — это нехорошо? Итак, вас обманули[[*4]].

Возможно, те, кто вам об этом рассказал и сам не понял, что PHP-код и код Smarty — братья-близнецы, возможно, они просто предостерегали вас от больших ошибок.

PHP против Smarty Фактически, PHP в руках неопытного программиста действительно становится неуправляемым.

Помните о борще.

Если не знать, как его приготовить, оно становится невкусным.

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

Например, никто не помешает вам выполнять запросы в SQL-коде.

Умник, в этом плане безопаснее.

Конечно, даже в Smarty можно все умело испортить.

Например, напишите функцию, выполняющую SQL-запросы[[*5]].

Но все же это требует гораздо больше усилий.

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

Мы уже договорились не рассматривать здесь проблемы верстальщиков.

На самом деле, {$var} читается лучше, чем или, точнее, .

Другая проблема — отсутствие кэширования.

Но это аргумент только для высоконагруженных проектов.

Конечно, в этом случае проще использовать готовый Smarty, чем придумывать что-то свое.

Все, что я сказал выше, не направлено на то, чтобы побудить вас отказаться от Smarty и срочно перейти на простой PHP. Просто надо четко понимать, что код на HTML не значит плохой.

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

Сам пользуюсь Smarty, потому что мне удобно.

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

Пример Самый простой способ передать переменные в шаблон PHP — просто объявить их перед включением шаблона в свой код.

$var = 'Hello, world!' include 'template.php';

Но этот метод имеет ряд неудобств.

Во-первых, такой тип передачи переменных непрозрачен (иногда сложно найти место объявления переменной).

Во-вторых, если переменная не объявлена, но используется в шаблоне, PHP выдаст ошибку уровня уведомления, а это не всегда удобно (например, Smarty не выдает уведомления).

В-третьих, те, кто пользовался Smarty, привыкли работать с объектом привычными методами Assign и Fetch. Все эти недостатки легко обойти.

Посмотрите на код ниже и сравните его с кодом Smarty. Конечно, здесь реализованы не все методы класса Smarty, но дело не в этом.

Дело в том, что 90% необходимого функционала Smarty реализовано в двух десятках строк кода.

Шаблонизатор в 20 строк! Не считая самого PHP-кода :)

class PlainPHPView { public $template_dir = TEMPLATES_DIR; protected $Vars = array(); public function __construct($template_dir = '') { $this->template_dir = $template_dir ? $template_dir : $this->template_dir; } public function Assign($var_name, $var_value) { $this->Vars[$var_name] = $var_value; } public function Fetch($template) { $reporting = error_reporting(E_ALL & ~E_NOTICE); extract($this->Vars); ob_start(); include $this->template_dir.'/'.

$template; ini_set('error_reporting', $reporting); return ob_get_clean(); } public function get_template_vars($var) { return isset($this->Vars[$var]) ? $this->Vars[$var] : false; } }

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

Но к этому очень легко привыкнуть.

$var = 'Hello, world!' $view = new PlainPHPView('.

/'); $view->Assign('var', $var); print $view->Fetch('template.php');

Преобразование представления Помимо спора о том, стоит ли мешать PHP и HTML или использовать Smarty, есть еще один не менее принципиальный, но не менее бесполезный спор.

Спор идет о том, стоит ли вообще помещать какую-либо логику в шаблоны.

В шаблонах, основанных на паттерне «Представление с преобразованием», нет явной логики[[*6]].

Это почти чистый HTML. Но перед выводом этот HTML преобразуется с помощью некоторой логики и только после этого передается клиенту.

То есть представление определяется не только самим шаблоном, но и специальным кодом, обрабатывающим этот шаблон.

Мартин Фаулер приводит пример XSLT-преобразования XML-данных.

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

Сам шаблон содержит только HTML и специальные маркеры, отмечающие области шаблона, требующие обработки.

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

И это неплохое решение.

Фактически, и шаблон, и «преобразователь» работают вместе и находятся вместе на уровне представления.

Но при использовании этого узора еще важнее уметь правильно разделить слои, чтобы они не смешивались.

Например, было бы неплохо обозначить «конвертер» как класс, тем самым абстрагируя его от остального кода.

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

Например, генерация ссылок или элементов формы.

В любом случае удобнее всего вынести этот код из шаблона и отформатировать его как функцию или класс, или его метод. Например, система плагинов Smarty. Такие функции называются «помощниками» или Helpers. Действительно, попробуйте написать в шаблоне код, генерирующий календарь.

Я уверен, что ты сможешь это сделать.

А что, если календарь нужен в другом шаблоне или даже проекте? Копировать+Вставить — это, конечно, решение, но не решение.

Гораздо проще форматировать такой код как метод класса.

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

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

Так что же такое шаблонизатор? Как я уже сказал, шаблонизатор — это миф.

Миф не сам по себе.

Это миф в том контексте, в котором часто используется это слово.

На собеседовании перед приемом на работу вас, вероятно, спрашивали о том, какой шаблонизатор вы используете.

Ответ «нет» значительно снижает ваши шансы получить работу.

На самом деле работодатель имел в виду нечто иное.

Он хотел вас спросить, как, а не с помощью чего вы делите логику приложения на слои.

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

Попробуйте ответить, что вы не используете шаблонизаторы, а используете смесь PHP и HTML. 5 к 1, что вас не возьмут :) Заключение Помните, как кто-то мудрый заметил, что история имеет свойство двигаться по спирали, часто повторяясь, но на более высоком уровне? Раньше мы смешивали PHP и HTML-код, потом поняли, что это плохо, а теперь оказывается, что это не так уж и плохо.

Когда-то я думал, что логика в шаблонах — это зло, но сейчас пишу статью о том, что это лишь один из подходов.

Моей целью в этой статье было не изменить ваши взгляды.

Если вам нравится Smarty, не отказывайтесь от него.

Если вы любите FastTemplate и подобные движки, это тоже ваше право.

У каждого выбора есть свои плюсы и минусы.

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

Руководствуясь навязанными стереотипами, вы лишаете себя права сделать такой выбор.

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

— [[#1]] Например, сколько раз показывать тот или иной блок, отображать текст в 2 столбца, отображать таблицу, в которой строки имеют разные цвета.

с помощью обычного HTML таких эффектов будет сложно добиться .

[[#2]] Приложение обычно делится на 3 слоя, но в этой статье мы разделим приложение на 2 слоя, логику представления и все остальное.

[[#3]] Фаулер говорит о трех типичных решениях, но третье представляет собой комбинацию первых двух.

Для буквалистов поясню, что Smarty относится именно к третьему типу, объединяющему стандартные решения «Представление по шаблону» и «Представление с трансформацией».

[[#4]] Smarty делает именно это, компилируя свои шаблоны в смесь кода PHP и HTML. [[#5]] Кстати, не дай бог я вам навязываю еще один стереотип.

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

Такие шаблоны еще называют активными.

Не решение определяет архитектуру, а архитектура требует решений :) [[#6]] Логика еще есть.

Но это неявная логика.

Community.livejournal.com/ru_php/789059.html **Диаграммы взяты с сайта Мартина Фаулера** www.martinfowler.com Теги: #php #smarty #design #движок шаблонов #php