В эту неделю довольно много писали про шаблонизаторы, преимущественно Smarty и XSLT. В то же самое время ваш покорный слуга усиленно думал над тем, какой бы шаблонизатор использовать на своих проектах, и пришел к неутешительному выводу что ему ничего не нравиться. Далее будет рассмотрены основные методы написания шаблонов, расписано что в них нехорошего и предложен свой взгляд на проблему.
Итак, шаблоны, как известно, призваны разделить код и представление, и соответственно разделить работу верстальщика и программиста. Из этой потрясающей своей новизной информации, можно сделать вывод, что идеальный шаблон должен состоять из чистого html, так как верстальщик должен работать только с html и css (что при существующем зоопарке браузеров уже подвиг), а программист, так как он существо ленивое и дорогое в содержании, толжен заниматься бизнес логикой.
Кроме того, как правило, задача верстальщика состоит в том, чтобы сделать код, который в браузере выглядит идентично макету, поэтому желательно, чтобы шаблон можно было просмотреть в браузере или в визуальном редакторе— верстать в блокноте, конечно кошерно, но разработчики dreamviewer, тоже не зря хлеб едят.
Итак рассмотрим следующие распространенные шаблонизаторы.
Самый распространенный шаблонизатор, гибкий вкусный и мощный, позволяет делать все что можно придумать. Но с другой стороны, надо программировать, да и синтаксис, из-за своей мощности избыточен, для его использования в шаблоне. Для того, чтобы просто вывести переменную в php или jsp, надо сделать слишком много телодвижений. Кроме того это требует от верстальщика знания языка и такой шаблон не портируется между языками (не знаю насколько это актуально, для проектов меньше Яндекса).
http://www.smarty.net/
Один из самых популярных шаблонизаторов, поэтому для примера рассмотрим его. Позволяет использовать функции, циклы, условия, но в итоге мы имеем тот же самый язык программирования, только проще, что, впрочем, не избавляет от необходимости его учить. Опять же при просмотре шаблона в браузере вылезают разные неприятные рудименты от циклов условий и т.д. Кроме того для выполнения какой-либо тривиальной задачи, вроде вывода картинок в таблице по три в ряду, необходимо «программировать», что, по моему мнению, для такой детской задачи слишком. Можно, конечно, написать функцию, но туда придется запихивать куски html кода, а это еще то извращение.
Величайшее, после колеса, изобретение человечества, как мы успели убедиться на этой неделе. Но основная загвоздка в том, что XSLT— идеальное средство, для того чтобы перегнать один документ для роботов в другой столь же нечибельный документ (то есть XML конечно может быть прочитан человеком, но удовольствие это сомнительное).
Соответственно и шаблон, представляет из себя мешанину тегов, требующую дополнительного пристального изучения. Наш сферический верстальщик, напомню, должен хорошо знать HTML, а самосовершенствоваться в свободное от работы время.
Кроме того, как правило, сначала страница верстается из макета, смотрится в браузерах (показывается заказчику), а потом его придется перегонять в XSLT, т.е. делать одну и ту же работу два раза.
И, как я уже написал выше, XSLT— средство для перевода одного или нескольких XML файлов в другой, и использовать его следует все-таки по назначению.
http://alexeyrybak.com/blitz/blitz_ru.html
Шаблонизатор всем замечательный, но только теперь логика шаблона отдается на откуп программиста. Вместо того, чтобы сформировать данные и отправить в шаблон и забыть, теперь нашему контроллеру (и как следствие— программисту) придется повертеть циклы и позаниматься другими малоинтересными задачами.
Применяется в asp.net, и позволяет, указав элементу, атрибут «исполнять на сервере» менять из бэкэнда его свойства и содержимое, аналогично windows forms. Метод интересный, но с точки зрения производительности сомнительный, хотя конечно все кэшируется и оптимизируется. Кроме того реализаций такого подхода нигде кроме asp.net я не встречал (правда меня занимал большей частью php), HTML_MetaForm Котерова, все-таки, немного из другой оперы.
Кроме того программисту приходиться опять заниматься разными малоинтересными вещами, вроде изменения атрибутов src у изображений.
Собственно, это даже скорее не шаблонизатор, а препроцессор для шаблонов. Логика шаблонов не блещет разнообразием, по большому счету это условие, цикл и кое-какие рутинные операции с формами. Таким образом, нам просто надо указать какой кусок html, за что отвечает, и сделать это можно при помощи html комментариев, которые собственно для этого и придуманы.
Таким образом, рассмотренная ранее, задача с выводом картинок по три в ряд (я знаю, что это можно сделать div'ами, но это не так наглядно), сводиться к расстановке комментариев:
Выглядит несколько избыточно, но в реальной ситуации, html кода будет значительно больше, а комментировать верстку все равно надо.
Каждая инструкция обрабатывается отдельным классом (в данном случае optemplate_tag_each), который имеет доступ к подузлам и аттрибутам, и на их основании формирует итоговый код (php, jsp, smarty— какой вам удобнее).
При этом есть еще волшебный узел «по умолчанию» не ограниченный никакими «подтегами», что в простых случаях позволяет уменьшить количество инструкций. Т.е. записть можно и так:
<pВ итоге, как только у вас появляется новая рутинная задача для вывода чего-нибудь, вы просто пишете новый класс, который, например, может работать с формами, подставляя в инпуты id и значения. При этом вы не зависите от CMS так как можете переписать тег в зависимости от того как передаются данные в шаблон.
Таким образом, мы имеем расширяемый шаблонизатор, который позволяет каждому заниматься своим делом, и, теоретически, имеет возможность использование тегов сторонних поставщиков.
Реализация есть, но довольно убогая— сделана скорее для того, чтобы проверить удобства подхода, в частности не поддерживаются вложенные теги одного типа. Если подход вызовет интерес и на практике метод окажется удобным— я напишу нормальную версию, дело не хитрое.
Итак, шаблоны, как известно, призваны разделить код и представление, и соответственно разделить работу верстальщика и программиста. Из этой потрясающей своей новизной информации, можно сделать вывод, что идеальный шаблон должен состоять из чистого html, так как верстальщик должен работать только с html и css (что при существующем зоопарке браузеров уже подвиг), а программист, так как он существо ленивое и дорогое в содержании, толжен заниматься бизнес логикой.
Кроме того, как правило, задача верстальщика состоит в том, чтобы сделать код, который в браузере выглядит идентично макету, поэтому желательно, чтобы шаблон можно было просмотреть в браузере или в визуальном редакторе— верстать в блокноте, конечно кошерно, но разработчики dreamviewer, тоже не зря хлеб едят.
Итак рассмотрим следующие распространенные шаблонизаторы.
Язык программирования
Самый распространенный шаблонизатор, гибкий вкусный и мощный, позволяет делать все что можно придумать. Но с другой стороны, надо программировать, да и синтаксис, из-за своей мощности избыточен, для его использования в шаблоне. Для того, чтобы просто вывести переменную в php или jsp, надо сделать слишком много телодвижений. Кроме того это требует от верстальщика знания языка и такой шаблон не портируется между языками (не знаю насколько это актуально, для проектов меньше Яндекса).
Smarty
http://www.smarty.net/
Один из самых популярных шаблонизаторов, поэтому для примера рассмотрим его. Позволяет использовать функции, циклы, условия, но в итоге мы имеем тот же самый язык программирования, только проще, что, впрочем, не избавляет от необходимости его учить. Опять же при просмотре шаблона в браузере вылезают разные неприятные рудименты от циклов условий и т.д. Кроме того для выполнения какой-либо тривиальной задачи, вроде вывода картинок в таблице по три в ряду, необходимо «программировать», что, по моему мнению, для такой детской задачи слишком. Можно, конечно, написать функцию, но туда придется запихивать куски html кода, а это еще то извращение.
XSLT
Величайшее, после колеса, изобретение человечества, как мы успели убедиться на этой неделе. Но основная загвоздка в том, что XSLT— идеальное средство, для того чтобы перегнать один документ для роботов в другой столь же нечибельный документ (то есть XML конечно может быть прочитан человеком, но удовольствие это сомнительное).
Соответственно и шаблон, представляет из себя мешанину тегов, требующую дополнительного пристального изучения. Наш сферический верстальщик, напомню, должен хорошо знать HTML, а самосовершенствоваться в свободное от работы время.
Кроме того, как правило, сначала страница верстается из макета, смотрится в браузерах (показывается заказчику), а потом его придется перегонять в XSLT, т.е. делать одну и ту же работу два раза.
И, как я уже написал выше, XSLT— средство для перевода одного или нескольких XML файлов в другой, и использовать его следует все-таки по назначению.
Blitz templates
http://alexeyrybak.com/blitz/blitz_ru.html
Шаблонизатор всем замечательный, но только теперь логика шаблона отдается на откуп программиста. Вместо того, чтобы сформировать данные и отправить в шаблон и забыть, теперь нашему контроллеру (и как следствие— программисту) придется повертеть циклы и позаниматься другими малоинтересными задачами.
Form like шаблонизатор.
Применяется в asp.net, и позволяет, указав элементу, атрибут «исполнять на сервере» менять из бэкэнда его свойства и содержимое, аналогично windows forms. Метод интересный, но с точки зрения производительности сомнительный, хотя конечно все кэшируется и оптимизируется. Кроме того реализаций такого подхода нигде кроме asp.net я не встречал (правда меня занимал большей частью php), HTML_MetaForm Котерова, все-таки, немного из другой оперы.
Кроме того программисту приходиться опять заниматься разными малоинтересными вещами, вроде изменения атрибутов src у изображений.
Авторский велосипед
Собственно, это даже скорее не шаблонизатор, а препроцессор для шаблонов. Логика шаблонов не блещет разнообразием, по большому счету это условие, цикл и кое-какие рутинные операции с формами. Таким образом, нам просто надо указать какой кусок html, за что отвечает, и сделать это можно при помощи html комментариев, которые собственно для этого и придуманы.
Таким образом, рассмотренная ранее, задача с выводом картинок по три в ряд (я знаю, что это можно сделать div'ами, но это не так наглядно), сводиться к расстановке комментариев:
<code>
<!--op:each src="$images" split="3"-->
<!--each:header-->
<table>
<!--/each:header-->
<!--each:splittop-->
<tr>
<!--/each:splittop-->
<!--each:row-->
<td><a href="{link}"><img src="{$src}" alt="{$title}" width="100" height="100"/></a></td>
<!--/each:row-->
<!--each:splitbot-->
</tr>
<!--/each:splitbot-->
<!--each:footer-->
</table>
<!--each:footer-->
<!--each:else-->
Ничего нет :(
<!--/each:else-->
<!--/op:each-->
</code>Выглядит несколько избыточно, но в реальной ситуации, html кода будет значительно больше, а комментировать верстку все равно надо.
Каждая инструкция обрабатывается отдельным классом (в данном случае optemplate_tag_each), который имеет доступ к подузлам и аттрибутам, и на их основании формирует итоговый код (php, jsp, smarty— какой вам удобнее).
При этом есть еще волшебный узел «по умолчанию» не ограниченный никакими «подтегами», что в простых случаях позволяет уменьшить количество инструкций. Т.е. записть можно и так:
<code>
<!--op:each src="$folders"-->
<h3>{$Title}</h3>
<div>{$Text}</div>
<!--/op:each-->
</code><pВ итоге, как только у вас появляется новая рутинная задача для вывода чего-нибудь, вы просто пишете новый класс, который, например, может работать с формами, подставляя в инпуты id и значения. При этом вы не зависите от CMS так как можете переписать тег в зависимости от того как передаются данные в шаблон.
Таким образом, мы имеем расширяемый шаблонизатор, который позволяет каждому заниматься своим делом, и, теоретически, имеет возможность использование тегов сторонних поставщиков.
Реализация
Реализация есть, но довольно убогая— сделана скорее для того, чтобы проверить удобства подхода, в частности не поддерживаются вложенные теги одного типа. Если подход вызовет интерес и на практике метод окажется удобным— я напишу нормальную версию, дело не хитрое.
