Шаблонизатор (XSLT / SMARTY / XTEN / SimplePHP)

Материал из AOW

Перейти к: навигация, поиск

Содержание

XSLT

10 аргументов в пользу XSLT

1) XSLT — это давно появившийся индустриальный стандарт, поддерживаемый W3C. Он разрабатывается многочисленной командой профессиональных разработчиков. Технология постоянно улучшается и обновляется за счет качественной поддержки. Во всем мире XSLT уже давно воспринимается как стандарт верстки, в России он используется на таких крупных проектах как Яндекс, Мой Круг и других.

Безопасность

2) Жесткое разделение бизнес-логики и модели представления данных ни при каких обстоятельствах не позволит верстальщику "убить" всю систему, если он имеет доступ только к шаблонам.

Гибкость

3) XSLT позволяет повторно использовать результаты уже произведенной работы. Единожды сверстанный на XSLT шаблон не держит на себе функциональность бизнес-логики и ее отработки, поэтому он свободно масштабируется и переносится на другие проекты.

4) Для типовых операций достаточно создать шаблон только один раз и использовать его из проекта в проект. Пример из практики: студия-партнер получила заказ на разработку 3-х сайтов автосалона под различные марки автомобилей. На создание первого сайта у нее ушло около 2-х месяцев, второй сайт с учетом новых доработок был разработан за 1 месяц, третий сайт был поднят за 2 недели. Благодаря тому, что собственно технология уже сделана, сайты остается только "разукрасить" (т.е. сменить дизайн). Единожды решенная задача, в следующий раз требует в 2-3 раза меньше времени даже с внедрением новых функций.

Доступность, понятность, невысокая стоимость разработки

5) По нашему опыту, верстальщику, знакомому только с HTML и CSS, время разработки проекта на XSLT с нуля составит в среднем около месяца-полутора. При этом если он занимается изучением XSLT в отрыве от других задач по проектам, то может освоить его за полторы недели. Для сравнения - освоить tpl-шаблонизатор конкретной CMS такой же верстальщик сможет в среднем за неделю, а освоение в процессе работы над проектом займет у него тот же месяц. Но XSLT верстальщику нужно освоить только один раз, а каждый отдельный tpl-шаблонизатор тянет за собой отдельное изучение. Поэтому уже после разработки первого проекта на XSLT можно говорить об экономии на этапе внедрения.

Отчуждаемость

6) Переработать чужой XSLT-шаблон может любой XSLT-верстальщик. Технология является стандартной, переход от одного разработчика к другому не представляет проблемы, что обеспечивает отчуждаемость проекта и существенную экономию на стоимости владения проектом.

Расширяемость

7) Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty. Поэтому, например, изменения в бизнес-логике не приведет к обрушению других шаблонов. В этом уже заложены возможности для последовательного расширения, так как все связи структурированы и поддаются модификации. Расширяемость при таком подходе становится гораздо менее трудозатратной, и снова снижается стоимость владения проектом.

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

8) Некоторые задачи, решаемые в XML+XSLT просто и эффективно, представляются как минимум нетривиальными без XSLT.

Например, с помощью XSLT можно строить децентрализованные сервисы (в частности, популярный в контексте Веб 2.0 mash-up), можно использовать для построения кластерных систем (конечно же, это не касается CMS). Обмен контентом с другими ресурсами на основе XML-формата позволяет использовать чужие сервисы на собственном сайте. При этом если этот сторонний сервис "ляжет", то с сайтом ничего не произойдет - данные могут браться из КЭШа какое-то время, а потом может перестать отображаться именно этот сервис при остальной работоспособности сайта в целом. Описанный выше подход Smarty благодаря развитым и неструктурированным связям с великой долей вероятности поспособствует тому, чтобы вместе с тем самым сторонним сервисом "лег" и весь сайт целиком.

Нативная поддержка XML

9) Изобилие данных в формате XML, которые часто нужно использовать в проекте, - это наша реальность. XSLT- шаблонизатор является "родным" парсером для XML, а все остальные решения - "велосипед".

Производительность и скорость работы

10) Один из "недостатков", которые ставятся некоторыми разработчиками в "вину" XSLT — то, что он не может решить задачи бизнес-логики. Сложно представить себе более абсурдное утверждение. В этом смысле накладывать базу данных на XSLT и требовать высокой скорости работы — такой же абсурд, как воспроизводить диск с поддержкой 5.1 через динамик обычного телевизора и требовать при этом Dolby Surround. XSLT по определению не должен этим заниматься, он создан только для того, чтобы реализовывать представление. А вот бизнес-логика должна подготовить те данные, которые ему нужны, чтобы отобразить страницу. И если она их подготовит, то о скорости работы XSLT вопросов возникнуть не может, потому что передавать нужно только то, что будет отображаться на странице (в большинстве случаев 10-50 товаров). Если делать полное преобразование базы на 10 тыс. товаров в XML, а потом на это накладывать XSLT-трансформацию, то результаты производительности будут весьма печальны. При этом будет полностью изнасилована концепция разделения бизнес-логики и представления, на которой основан XSLT. Неудивительно, что при подходе, описанном у Сергея Рыжикова, он не покажет чудес производительности и скорости.

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

К сожалению, идеальных людей/продуктов/технологий не бывает. XSLT не исключение.

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

Другим ограничением по массовому использованию XSLT в России многие называют существенно более высокий уровень заработной платы XSLT-верстальщика по сравнению с HTML-верстальщиком. Отчасти это так, но во многом ситуация нагнетена искусственно. В свое время, верстка на дивах была такой же экзотикой, как сейчас многим представляется XSLT. Но это не помешало ей получить широкое распространение благодаря реальным преимуществам перед табличной версткой. И дефицит специалистов по дивной верстке достаточно быстро восполнился на рынке. Поэтому появление XSLT-верстальщиков - вопрос при времени при очевидном превосходстве XSLT над другими существующими шаблонизаторами.

Выводы

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

Взгляд со стороны на статью

1) XSLT - это давно появившийся индустриальный стандарт...

Пустые слова. По этой логике, CGI, написанные на ANSI C (стандарт), гораздо приемлемее, чем PHP и, тем более, Perl.

2) ...не позволит верстальщику "убить" всю систему...

О да, конечно. http://xml.apache.org...ql/XConnection.html

3) XSLT позволяет повторно использовать результаты уже произведенной работы.

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

4) Для типовых операций достаточно создать шаблон только один раз и использовать его из проекта в проект.

То же самое. (Накрутка счётчика до 10).

Для крупного авторитейлера, кстати, характерно раз в подгода-год менять под корень не только дизайн, но и логику.

5) ... Но XSLT верстальщику нужно освоить только один раз, а каждый отдельный tpl-шаблонизатор тянет за собой отдельное изучение.

XSLT — это *тоже* отдельный шаблонизатор. Как все, только самый раздутый и неудобный.

6) Переработать чужой XSLT-шаблон может любой XSLT-верстальщик.

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

Если вести речь о прозрачности XSLT-кода, то её нет. Если вызов функции (call-template) с 3 аргументами в норме занимает 5 строк, такой код не может быть читаемым.

Насчёт "стандартности" см. п. 1.

7) ...изменения в бизнес-логике не приведет к обрушению других шаблонов.

Изменения бывают разными. Если они касаются состава и значений параметров, передаваемых через теги A и INPUT, менять шаблоны придётся.

На самом деле, поскольку в HTML гиперссылка одновременно и элемент дизайна и RPC-вызов, "отделение бизнес-логики" недостижимо в принципе.

все связи структурированы и поддаются модификации.

Ага, и не поддаются обнаружению. xsl:apply-templates "на кого бог пошлёт" при большом количестве инклюдов — это как раз то, что превращает поддержку в ад.

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

Расширение (за некоторую критическую черту) при таком подходе приводит к коллапсу, и стоимость владения проектом становится неопределённой.

XSLT - это сейчас наилучший стандарт

Снова пустые слова.

8) Некоторые задачи, решаемые в XML+XSLT просто и эффективно, представляются как минимум нетривиальными без XSLT.

Подтасовка. Кэшрование кусочков чужого контента НЕ является встроенной функцией XSLT, а разбирать RSS на дату, заголовок и тело можно очень много чем.

9) Изобилие данных в формате XML, которые часто нужно использовать в проекте, - это наша реальность. XSLT- шаблонизатор является "родным" парсером для XML, а все остальные решения - "велосипед".

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

В действительности XML по-серьёзному НЕ применяется даже в AJAX-проектах (хотя и фигурирует в названии). Снифферните Google Maps — и увидите, что конкретно для передачи слабостуктурированных данных JSON гораздо удобнее XML.

10) Один из "недостатков", которые ставятся некоторыми разработчиками в "вину" XSLT - то, что он не может решить задачи бизнес-логики. Сложно представить себе более абсурдное утверждение.

Уж да, абсурд. По сравнению с остальными недостатками этот практически незаметен.

требовать высокой скорости работы - такой же абсурд

Ну разумеется. Это ж индустриальный стандарт. Зачем же быстро, когда можно серьёзно? (Я сейчас о скорости собственно трансформации).

передавать нужно только то, что будет отображаться на странице (в большинстве случаев 10-50 товаров).

Вот! Карточки товаров с 1 фоткой и списочки по 10-50 наименований —— это и есть предел допустимой применения XSLT.

Для справки: в своё время моим заданием было написать набор XSLT, реализующий интерфейс Outlook. Допустим бизнес-логика отработала чётко, и вам приехали задачи на текущий месяц. А теперь нарисуйте-ка календарик :-}}

Поэтому XSLT требует от разработчика особой тщательности, аккуратности и внимательности к деталям.

И что же вы такое говорите? Требует-таки тщательности, да не простой, а особой?! А вдруг кто-то возьмёт, да и ошибётся? Стоимость владения может... не снизиться? Как же так?


SMARTY

Smarty — компилирующий обработчик шаблонов для PHP, один из инструментов, позволяющих отделить прикладную логику и данные от представления в духе концепции Model-view-controller.

Например, вы создаёте страницу, которая показывает газетную статью. Название статьи, автор и сама статья — элементы, которые не содержат никакой информации о том, как они будут представлены. Их передают в Smarty из приложения, а верстальщик шаблона редактирует шаблоны и использует комбинацию тегов HTML и тегов шаблона, чтобы отформатировать представление этих элементов (таблицы HTML, фоновые цвета, размеры шрифта, стиля и т. д.). Однажды программист захочет изменить способ хранения статьи (сделать изменения в логике приложения). Это изменение не вызовет изменений в шаблонах. Содержание будет все еще передаваться в шаблон таким же самым способом. Аналогично, если верстальщик захочет полностью перепроектировать шаблоны, это не потребует никаких изменений в прикладной логике.

Одно из предназначений Smarty — это отделение логики приложения от представления. Конечно же, шаблоны могут содержать в себе логику, но лишь при условии, что эта логика необходима для правильного представления данных. Такие задачи, как подключение других шаблонов, чередующаяся окраска строчек в таблице, приведение букв к верхнему регистру, циклический проход по массиву для его отображения и т. д. — всё это является примером логики представления. Не следует думать, что Smarty заставляет вас разделять логику приложения и представление. Smarty не видит разницы между этими вещами, так что помещать или не помещать логику приложения в шаблоны — решать вам. Если же вы считаете, что в шаблоне вообще не должно быть логики, вы можете ограничиться использованием чистого текста и переменных.

Одна из уникальных возможностей Smarty —— компилирование шаблонов. Это означает, что Smarty читает файлы шаблонов и создаёт PHP-код на их основе. Код создаётся один раз и потом только выполняется. Поэтому нет необходимости обрабатывать файл шаблона для каждого запроса и каждый шаблон может пользоваться всеми преимуществами таких кешируюших решений, как eAccelerator или PHP Accelerator.

Некоторые особенности Smarty:

  • Он очень быстр.
  • Он эффективен, так как обработчик PHP делает за него грязную работу.
  • Никакой лишней обработки шаблонов, они компилируются только один раз.
  • Перекомпилируются только те шаблоны, которые изменились.
  • Можно создавать пользовательские функции и модификаторы, что делает язык шаблонов чрезвычайно расширяемым.
  • Настраиваемые разделители тегов шаблона, то есть вы можете использовать {}, {{}}, и т. д.
  • Конструкции if/elseif/else/endif передаются обработчику PHP, так что синтаксис выражения {if …} может быть настолько простым или сложным, насколько вам угодно.
  • Допустимо неограниченное вложение секций, условий и т. д.
  • Существует возможность включения PHP-кода прямо в ваш шаблон, однако обычно в этом нет необходимости (и это не рекомендуется), так как движок весьма гибок и расширяем.
  • Встроенный механизм кеширования.
  • Произвольные источники шаблонов.
  • Пользовательские функции кеширования.
  • Компонентная архитектура.


XTEN

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

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

  • Шаблонизатор должен быть запущен в PHP5.
  • PHP должен быть скомпилирован с поддержкой SimpleXML и DOMDocument.


SIMPLEPHP

( http://belall.host.sk/simplePHP/simplephp.zip )

Шаблонизатор структурой похожий на Smarty, но в шаблонах использующий язык PHP.

Некоторые особенности SimplePHP:

  • Он очень быстр.
  • Он эффективен, так как обработчик PHP делает за него грязную работу.
  • Никакой лишней обработки шаблонов, они компилируются только один раз.
  • Перекомпилируются только те шаблоны, которые изменились.
  • Можно создавать пользовательские функции и модификаторы, что делает язык шаблонов чрезвычайно расширяемым.
  • Допустимо неограниченное вложение секций, условий и т. д.
  • Встроенный механизм кеширования.
  • Произвольные источники шаблонов.
  • Компонентная архитектура.
Личные инструменты

Разработка веб-сайтов, автоматизация.
По всем вопросам обращайтесь по телефонам:

+7 495 640 29 90
http://artofweb.ru