Почему я должен использовать систему шаблонов в PHP?
Почему я должен использовать систему шаблонов в PHP?
Причина моего вопроса заключается в следующем: PHP сам по себе является системой шаблонов с богатым набором функций, зачем мне устанавливать другой механизм шаблонов?
Единственные два преимущества, которые я нашел до сих пор:
- Немного более чистый синтаксис (иногда)
- Механизм шаблонов обычно недостаточно мощный для реализации бизнес-логики, поэтому он заставляет вас разделять проблемы. Создание шаблонов с помощью PHP может соблазнить вас пройтись по принципам шаблонов и снова начать писать суп кода.
... и оба они весьма незначительны по сравнению с минусами.
Небольшой пример:
PHP
<h1><?=$title?></h1>
<ul>
<? foreach ($items as $item) {?>
<li><?=$item?></li>
<? } ?>
</ul>
Умный
<h1>{$title}</h1>
<ul>
{foreach item=item from=$items}
<li>{$item}</li>
{/foreach}
</ul>
Я действительно не вижу никакой разницы.
Во-первых, вы используете короткие теги php, что, я согласен, делает вещи приятными, но за это вы подвергнетесь остракизму со стороны сообщества PHP. Сравните <?php echo $foo ?> с {$foo} для честного сравнения, и тогда smarty явно выигрывает по удобочитаемости.
@DGM вы будете подвергнуты остракизму со стороны PHP-сообщества за это - Во-первых, я сильно сомневаюсь в этом аккаунте (многие известные разработчики выступают за короткие теги). Во-вторых, ... [страшным академическим] сообществом PHP? Разве мы не кучка босоногих детей, любящих веселье, грязь, играющих в песочнице? :) Отказ от ответственности: я провел 6-8 лет, копаясь в PHP, игнорируя настоящие красивые и мощные языки программирования, и теперь мне 32 года, и я очень сожалею об этом ! Нарушайте PEP8 - вот где вы подвергнетесь остракизму, и это действительно имеет значение. PS. Осмелюсь предположить, что настоящей целью PHP вначале была система шаблонов. Нет?
Ответы 25
В основном я думаю, чтобы избежать применения в шаблонах «небезопасной» бэкэнд-логики. Поскольку в большинстве случаев шаблоны передаются дизайнерам, мы хотим дать им лишь ограниченный набор вещей, которые они могут делать.
Хорошо, это будет пункт 2 в моих плюсах. Вы всегда можете (по крайней мере, в Smarty) внедрить в шаблонизатор небезопасные вещи. Это только немного сложнее :-)
Тогда не используйте Smarty :)
Да, как вы сказали, если вы не заставляете себя использовать механизм шаблонов внутри PHP (механизм шаблонов), становится легко ускользнуть и перестать разделять проблемы.
тем не мение, те же люди, у которых есть проблемы с разделением проблем, в конечном итоге генерируют HTML и скармливают его smarty или выполняют PHP-код в Smarty, поэтому Smarty вряд ли решит вашу проблему разделения проблем.
Смотрите также:
Да, это именно тот случай, когда у нас возникла проблема со Smarty. Подача html-кода в переменные smarty и использование тегов {php} {/ php}.
Об этом я тоже немного подумал. Не могли бы вы привести несколько примеров того, что вы могли бы делать в «представлении» (контексте MVC) на чистом PHP? например. обрезка текста, использование заглавных букв, циклы. Где проходит черта для других «проблем»?
@sanchothefat: Я считаю, что все языки шаблонов - отстой и не разделяются полностью ни в одной реализации, вам просто нужно нарисовать свою собственную линию для каждого проекта. Я работаю над тем, чтобы в моем шаблоне был код нет, но это еще не все.
Логика отображения - всегда скользкая дорожка. В какой момент «зебра» или форматирование текста становятся «настоящей» логикой? Я считаю, что если вы вообще задаете себе этот вопрос, а не просто говорите «черт возьми», то вы на правильном пути.
@sanchothefat: Кто-то указал, что вы никогда не должны изменять какие-либо значения внутри шаблона. Это очень разумный минимум. Лично я пошел бы дальше, ограничив PHP только простыми функциями. Не так много связанных команд.
Отличный ответ. Системы шаблонов - одна из тех вещей, за которые вы еще не заплатили, если вы не написали ее сами, а потом выбросите ее. Это действительно сводится к тому, что вы можете сделать последовательно, которое поддерживает те, с кем вы работаете ... и вы сами.
Это поддерживаемый код, который вы будете писать с умным ... серьезно ... Я проверил виноват, и что-то вроде этого было написано на прошлой неделе ... ::: {foreach from = $ array | @array_keys item = 'key'} {foreach from = $ array | @array_values item = 'value'} {if $ smarty.post.var == $ key} {$ value | escape: 'html'} {else} {$ key | esc ape: ' html '} {/ if} {/ fo достичь} {/ foreach}
Первая ссылка не работает.
@xpy Страница все еще существует, но контент был удален, поэтому ее могут просматривать только люди с высоким уровнем репутации. Учитывая, что удаление произошло через 6 лет с тех пор, как я написал этот комментарий, я не уверен, как решить эту проблему, потому что вы не можете просто заменить конкретное мнение: p
Ваш анализ разумен. Я предполагаю:
- Дизайнеры шаблонов и внутренние программисты не могут быть одним и тем же, поэтому это способствует разделению.
- Он в некоторой степени защищает вас от самого себя, поскольку вы не можете использовать «слишком много» PHP в своих шаблонах.
- Может быть проще оптимизировать / прекомпилировать шаблоны в некоторых сценариях? (Это предположение)
Лично я считаю, что они доставляют больше хлопот, чем они того стоят. В частности, они не работают, если вы хотите подать шаблоны для «дизайнеров», поскольку инструменты WYSIWYG не знают, что с ними делать.
Основная причина, по которой люди используют системы шаблонов, - это отделение логики от представления. Это дает несколько преимуществ.
Во-первых, вы можете передать шаблон веб-дизайнеру, который может перемещать вещи по своему усмотрению, не беспокоясь о сохранении потока кода. Им не нужно понимать PHP, просто чтобы не трогать специальные теги. Возможно, им придется изучить простую семантику для нескольких тегов, но это намного проще, чем изучение всего языка.
Кроме того, разделив страницу на отдельные файлы, и программист, и дизайнер могут работать над одной и той же «страницей» одновременно, проверяя систему управления версиями по мере необходимости, без конфликтов. Дизайнеры могут тестировать визуальные эффекты своих шаблонов относительно стабильной версии кода, в то время как программист вносит другие, потенциально критические изменения, в свою собственную копию. Но если эти люди редактировали один и тот же файл и им приходилось объединять разные изменения, вы можете столкнуться с проблемами.
Это также обеспечивает соблюдение хорошей практики программирования, позволяющей отделить бизнес-логику от логики представления. Если вы смешиваете бизнес-логику с презентацией, вам будет труднее извлечь ее, если позже вам нужно будет представить ее по-другому. В наши дни все более популярными становятся различные способы представления в веб-приложениях: каналы RSS / ATOM, ответы JSON или AJAX, WML для портативных устройств и т. д. С помощью системы шаблонов это часто можно сделать полностью с помощью шаблона и без каких-либо изменений или внесения небольших изменений. еще.
Однако не все будут нуждаться в этих преимуществах или оценивать их по достоинству. Преимущество PHP перед Java / Python / Ruby / и т. д. Состоит в том, что вы можете быстро взламывать веб-страницы с некоторой логикой в них, и это все хорошо.
Отличный ответ. Разделение логики и представления - самое большое преимущество. Возможность изменять дизайн, не беспокоясь о коде, существенно увеличивает производительность.
Все это, конечно, правда, но для этого не нужен отдельный шаблонизатор. Сам PHP можно использовать так, как вы описываете. Может быть, это моя плохая формулировка. Я имею в виду систему шаблонов как продукт, а не как подход.
Преимущества использования готового программного обеспечения здесь такие же, как и в любом другом месте: вы получаете преимущества предварительного тестирования сообществом, готовой документации и почти бесплатного обслуживания в будущем.
ВЫ можете реализовать разделение проблем самостоятельно на чистом php, если вы дисциплинированы, но по мере того, как проект растет и имеет больше разработчиков, становится все более и более сложной задачей убедиться, что ваша дисциплина применима и к другим разработчикам / дизайнерам. .
Мне нравится возможность тривиально отображать любой шаблон из любого файла PHP (и включать фрагменты шаблонов друг в друга для общих элементов, таких как панели навигации). Например, предположим, что у вас есть страница, которая обычно выводит некоторую информацию, если вы вошли в систему, или ошибку, если нет. С PHP вы бы написали что-то вроде:
if (loggedIn)
{
// print lots of HTML here
}
else
{
// print error message
}
В Smarty это могло быть что-то вроде этого (простите за неправильный синтаксис, это было давно):
if (loggedIn)
{
$smarty->bind("info", someObject);
$smarty->display("info.template");
}
else
$smarty->display("error.template");
Если бы вы были действительно умны, вы могли бы даже отобразить шаблон страницы входа в систему вместо шаблона ошибки, при желании с сообщением, объясняющим, почему пользователь оказался там. И если вы применили технику, которую я написал, а затем решили, что хотите переключиться на отображение окна входа в систему, это всего лишь изменение одной строки! Для меня это не просто разделение представления и логики, но и возможность повторно использовать общие элементы представления из многих мест.
Это также можно сделать в PHP с помощью include, но я думаю, что Smarty может сделать это проще.
Мне нравится использовать фреймворк MVC, такой как воспламенитель кода. Я считаю, что в «представлениях» я склоняюсь к PHP-коду, который касается только того, как отображаются значения. У меня есть библиотека функций форматирования, которые я могу использовать в представлениях с этой целью. Одна из предпосылок воспламенителя кода - избегать использования языка шаблонов, поскольку он может ограничивать вас и замедлять работу.
Я считаю, что дизайнерам лучше изучить PHP, чтобы они могли достичь того, что им нужно, например. чередование имен классов. Это также сделает их более полезными в долгосрочной перспективе, и это не будет большим скачком от одного синтаксиса к другому.
Я не думаю, что вам следует использовать шаблонизатор. Вместо этого вы должны использовать что-то вроде Zend_View, которое побуждает вас делать логику отдельно от представления, но позволяет вам создавать уровень представления на PHP.
Zend_View - это шаблонизатор
Сейчас я начинаю новый проект с Zend Framework, и мне кажется, вау, как я мог сделать это без этого раньше? :-)
Держу пари, что если бы язык шаблонов PHP был настолько принудительным, что заставлял бы вас использовать его, вы бы вообще не использовали его. Способность «выпрыгивать» и действовать по-своему, когда в беде, - одна из привлекательных сторон PHP.
Я не говорю, что это хорошо, или что код будет поддерживаемым, просто в первоначальных соображениях я бы не выбрал язык шаблонов, который полностью меня заблокировал.
В противном случае я согласен с тем, что системы шаблонов помогают разделить работу между кодированием и дизайном и, возможно, позволяют дизайнерам проектировать и писать нам.
Одним из преимуществ шаблонизатора, которого я не видел, была возможность динамических элементов html - что-то вроде элементов управления asp.net. Например, с помощью HTML Template Flexy от PEAR вы можете иметь элементы динамической формы, которые автоматически поддерживают состояние. Обычный элемент выбора html может быть заполнен и иметь выбранный элемент, установленный в коде позади, без циклов или условных выражений в шаблоне.
Я думаю, что более чистый синтаксис - это большая победа. Хотя может показаться, что это всего несколько символов, но когда вы делаете это каждый день, тогда каждый персонаж начинает считаться.
И {$myvar|escape} ИМХО совсем немного короче <?php echo htmlspecialchars($myvar); ?>. (Имея в виду, что синтаксис <?=$foo?> доступен только тогда, когда он специально включен в PHP conf.)
Хорошо, но каждый раз, когда я хочу что-то написать в Smarty, я обращаюсь к шпаргалке Smarty, что не экономит много времени :-)
@JS, как только вы начнете использовать его каждый день, вам не нужно видеть лист
Мне все еще нужна шпаргалка после года ее использования, потому что я сталкиваюсь с нелепыми случаями, когда это [] вместо. Решайся по-умному! Что он?!?
PHP является в значительной степени является системой шаблонов. Ключ в том, чтобы заставить себя самостоятельно отделить логику от презентации. Использование Smarty или чего-то в этом роде только немного затрудняет совмещение логики и представления. Если вы не можете заставить себя разделить их самостоятельно, использование системы шаблонов не поможет. Все, что ему нужно, - это потреблять дополнительную вычислительную мощность.
Главное - не изменять никаких значений в коде презентации. Я считаю, что для этого PHP так же эффективен, как и Smarty, если вы используете синтаксис if / endif:
<?php if ($some_test): ?>
<em>Some text!</em>
<?php endif; ?>
На самом деле именно с экранированием переменных php не справляется с многословием, поэтому вам нужно писать действительно очень сжатые функции-оболочки, которые и общую удобочитаемость с помощью только концевых блоков <? Php}?>, Которые вас обескураживают.
- Вы хотите использовать файл с PHP-кодом в качестве шаблона? Отлично.
- Вы хотите использовать свои переменные в указанном шаблоне? Отлично.
Только не забудьте разделить логику и конечный результат (презентацию). Это лучше сделать с помощью шаблонов. Но вам не нужно учиться чему-то вроде Smarty.
- Если вы используете Zend_View или аналогичный, вы можете использовать PHP-код полностью.
Здесь у многих есть правильный ответ. Smarty не создает шаблоны на PHP. Отнюдь не. Smarty предназначен в основном для тех, кому приходится использовать дизайнеров (т.е. непрограммистов) для редактирования и настройки отображения страниц. Если каждый, кто собирается изменить макет ваших страниц, может программировать, вы можете использовать систему шаблонов, более ориентированную на PHP-код. Но вам действительно нужно подготовить все выходные данные и отправить их в шаблон. Если вы позволите каждой странице получать, обрабатывать и отображать контент, вам придется реорганизовать ее раньше, чем позже.
Когда вы пишете код для кого-то другого. Например, однажды я участвовал в создании жесткой структуры веб-приложений, которую следует настраивать для наших клиентов. Одна из важных просьб заключалась в том, чтобы заказчик мог нанять дизайнера для изменения шаблонов без, чтобы иметь возможность программировать. Что еще более важно, он может не быть уполномоченный, чтобы изменить код.
Smarty, например, позволяет вводить довольно жесткие ограничения на то, что может делать шаблон. По сути, наше приложение отключило все, кроме самых основных конструкций кода и выбранный набор функций-модификаторов. Итак, у нас было две цели, которым хорошо справлялся механизм шаблонов: простота и безопасность.
Использование не-PHP шаблонов под предлогом разделения логики - это нонсенс. Если разработчик не понимает, что такое разделение логики бизнес-представления и как это должно быть сделано, проблема должна быть решена соответствующим образом. В противном случае вы получите HTML в бизнес-логике или бизнес-логику в шаблонах - никакой шаблонизатор вас не спасет. Вы должны научить разработчика основам.
И если разработчик делает это понимает, система шаблонов - это только ограничение. Он не добавляет любое значение в процесс разработки, только накладные расходы на изучение нового синтаксиса, поддержание другой библиотеки в актуальном состоянии и более медленное выполнение. Хотя последнее можно решить с помощью кеширования и прочего, это только решает проблему, которая иначе не существовала бы. Итак, системы шаблонов не предлагают никакой ценности, никаких преимуществ.
Однако есть одно исключение, когда я считаю разумным использование системы шаблонов, отличной от PHP: когда программисты логики представления должны иметь ограниченный доступ к шаблонам. Например, если вы являетесь поставщиком системы хостинга блогов и хотите разрешить своим пользователям персонализировать и кодировать свои шаблоны, не позволяя им выполнять произвольный код. Однако этот аргумент нет применим к случаям, когда дизайнер готов изучить небольшой код, чтобы помочь при программировании пользовательского интерфейса. Если он может выучить Smarty, он сможет выучить конечно PHP.
Вы дважды забыли htmlspecialchars(). Вот почему вам нужна система шаблонов.
Смарти плохой. Не судите системы шаблонов на основании этого.
Оглядываясь назад, это лучший ответ во всей цепочке. Спасибо!
Для меня одной из главных особенностей движков шаблонов является то, что слой кеша прозрачен для вас. Я уже давно пользуюсь smarty, и кеширование облегчает жизнь. Кроме того, продуманный дизайн позволяет использовать собственную функцию кеширования. В моем случае я выбираю, следует ли для какой-либо страницы использовать кэш памяти или диск для хранения вывода шаблона.
с другой стороны, если у вашего сайта большой трафик, и вы не знаете, как управлять умностью и хорошо его настраивать, этот любой шаблонизатор может стать убийцей сайта. но даже не используя smarty, ваш сайт тоже может умереть.
flickr в настоящее время использует smarty. это не должно быть так плохо, не так ли?
И давайте не будем забывать о будущем. Веб-сайты устаревают почти в момент публикации. В какой-то момент вам нужно будет обновить внешний вид. Если вы сохраняете разделение, часто дизайнер в одиночку может завершить совершенно новый веб-сайт с тем же программированием на бэкэнде. Это позволяет ускорить и удешевить редизайн, позволяя привлекать программиста только в том случае, если требуются новые функции.
но дизайнер мог бы это сделать без смартов, но и с php тоже. просто несколько слов: P a foreach или echo, верно?
По-прежнему есть веская причина для использования системы шаблонов, но не Smarty, а PHPTAL. Шаблоны PHPTAL - это допустимые файлы XML (и, следовательно, XHTML). В дальнейшем вы можете использовать фиктивный контент в PHPTAL и, таким образом, получить действительный файл XHTML с окончательным внешним видом, который можно обработать и протестировать с помощью стандартных инструментов. Вот небольшой пример:
<table>
<thead>
<tr>
<th>First Name</th>
<th>Last Name</th>
<th>Age</th>
</tr>
</thead>
<tbody>
<tr tal:repeat = "users user">
<td tal:content = "user/first_name">Max</td>
<td tal:content = "user/last_name">Mustermann</td>
<td tal:content = "user/age">29</td>
</tr>
</tbody>
</table>
Механизм шаблонов PHPTAL автоматически вставит все значения из массива пользователей и заменит наши фиктивные значения. Тем не менее, таблица уже является допустимым XHTML, который может отображаться в любом браузере по вашему выбору.
Лично я всегда использую движки шаблонов на php, python и т. д.
Первая очевидная причина, уже упомянутая другими:
It's forces you to not use any business logic in your templates.
Да, конечно, дисциплина вполне подойдет, когда она у вас есть.
Но это лишь крошечный аспект того, почему вы должны использовать движок шаблонов. Большинство из них - больше, чем просто движок, и их можно рассматривать как фреймворки для создания шаблонов, нравится вам это или нет.
Например, Smarty также имеет расширенные функции кэширования, такие как частичное кэширование. Действительно полезные вещи, вещи, которые вам придется делать самостоятельно, если использовать только php в качестве языка шаблонов.
И, пожалуйста, не забывайте, что все эти действительно полезные вспомогательные функции можно быстро найти в документации. Большинство из них также предоставляют простой способ добавления собственных функций и / или инструментов.
Так что да, это вопрос выбора. Если вам нужен действительно простой шаблон, подумайте о том, чтобы проявить некоторую дисциплину и не допускать попадания логики в шаблоны. Но когда вы ожидаете, что ваше приложение будет расти, вам в конечном итоге понадобятся функции фреймворка шаблонов. И к тому времени вы, надеюсь, не изобретаете велосипед, кодируя все это для себя.
И последнее, но не менее важное: для меня в некоторых фреймворках шаблонов есть одна потрясающая функция.
Template Inheritance
Я узнал об этом по Джанго и теперь использую его в последней версии Умный 3. У ребят из фреймворка Symphony тоже есть Веточка, который можно считать портом с синтаксисом Django.
Сначала это выглядит немного странно, но очень мощно. Вы строите свой скелет и определяете различные блоки. Вы можете расширить такой каркас и заполнить (переопределить) блоки своим содержимым.
Для меня это хранитель!
система управления шаблонами, мы можем управлять файлами шаблонов отдельно. время выполнения системы будет быстрее, чем у обычного проекта PHP. поэтому здесь файлы PHP и файлы шаблонов обслуживаются отдельно.
после запуска файлов код будет сохранен в template_c. поэтому он не компилируется много раз.
Я несколько раз использовал крошечный, который имеет довольно аккуратный и простой синтаксис. Никаких циклов или псевдокода в шаблоне html.
Со своей домашней страницы:
TinyButStrong is a library that enables you to dynamically create XML/HTML pages and any other files based on text source. It's a Template Engine for the PHP language. It enables you to easily display information from your database, but also to seriously harmonize and simplify your PHP programming.
TinyButStrong is oriented to HTML but not specialized to Html. This means it can work as well with Text files, XML, RSS, RTF, WML, Excel (xml), ... The OpenTBS plug-in enables your to merge OpenOffice and Ms Office documents.
Кто-то может возразить, что Smarty делает то, что уже умеет PHP: отделяет представление от бизнес-логики. Язык программирования PHP отлично подходит для разработки кода, но при смешивании с HTML синтаксис операторов PHP может вызвать затруднения. Smarty компенсирует это, изолируя PHP от презентации с помощью гораздо более простого синтаксиса на основе тегов. Теги раскрывают содержимое приложения, обеспечивая четкое отделение от кода PHP (приложения). Для управления шаблонами Smarty не требуется никаких знаний PHP.
Важность этого разделения ситуативна. Обычно это более важно для веб-дизайнеров, чем для разработчиков PHP. Таким образом, Smarty обычно хорошо подходит, когда роли разработчиков и дизайнеров разделены. Нет правильного или неправильного ответа: у каждой команды разработчиков есть свои предпочтения в отношении управления кодом и шаблонами. Помимо чистого синтаксиса на основе тегов, Smarty также предлагает широкий спектр инструментов для управления представлением: детальное кэширование данных, наследование шаблонов и функциональную песочницу, и это лишь некоторые из них. Бизнес-требования и PHP-код, с которым используется Smarty, будут играть большую роль в определении того, подходит ли Smarty.
Разработчики, которые будут активно использовать концепции ООП, такие как люди JAVA / Spring / Oracle PL-SQL, говорят, что сам язык PHP используется для логики представления / просмотра / отображения в проектах уровня Enterprise. В этих БОЛЬШИХ проектах серверной частью является Oracle, база данных извлекается с помощью pl-slq / java, а презентация - php. Лучшим примером является facebook.http://en.wikipedia.org/wiki/Facebook facebook использует php для презентации, java / C++ в качестве внутреннего интерфейса.
Единственная причина, по которой php используется в качестве презентации, потому что он тесно работает с HTML, но java / C++ в большей степени основан на ООП и не может напрямую соответствовать HTML. Назовите мне одну CMS (joomla / drupal / wordpress) или фреймворк (zend / symfony / Yii), который использует Smarty? Так ПОЧЕМУ нужен smarty?
Мне нравится использовать шаблоны по нескольким причинам:
1) Улучшает читабельность кода PHP. Мои файлы PHP становятся раздутыми и некрасивыми, когда везде есть операторы печати ("") с фрагментами HTML. Кроме того, возникают проблемы, например, как передать переменные в текст HTML? Вы везде используете теги? Вы используете print ("") и избегаете кавычек HTML и объединяете свои переменные? Используете ли вы печать ("") и одинарные кавычки в HTML, противоречащие стандарту, и вставляете ли переменные напрямую?
2) Очищает представление HTML-кода. Может стать трудно поддерживать сгенерированный HTML-код в хорошем состоянии, если он будет разрезан и разбит на части в нескольких файлах. Например, отступы могут отсутствовать.
3) Он позволяет вам создавать несколько шаблонов, а затем вошедший в систему пользователь может выбрать, какой шаблон / скин он хочет отображать при просмотре вашего веб-сайта, и вы также можете быстро и без усилий изменить шаблон по умолчанию на что-то другое, если вы так склонен.
В целом, это просто лучший способ все организовать. Есть небольшой компромисс в том, чтобы изучать и вводить команды класса шаблонов, открывать несколько файлов и т. д. Но, на мой взгляд, оно того стоит, потому что читаемость и организация кода улучшаются.
Подводя итог, добавлю несколько своих мыслей. Мы должны использовать систему шаблонов, если она дает возможность:
- кеш и сжатие кода
- обеспечить некоторый уровень безопасности (как отображаются переменные)
- наследование шаблона и репродукция кода html (позволяет избежать дублирования кода)
- возможность писать собственные плагины / модули для улучшения написания представлений
- "забота" переводит проблему и перемещает эту проблему на уровень просмотра (в Smarty нет встроенного модуля, но для этого есть хорошие решения сообщества)
Спасибо за каждый оставленный вами комментарий. Это помогло мне разобраться в своих мыслях. Теперь я использую Zend Framework и всем рекомендую то же самое. Теперь я рассматриваю Smarty и ему подобных как шаг в гораздо более сложный, продуктивный, сложный и увлекательный мир разработки фреймворков. Больше никаких mysql_queries и include_onces :-)