Шаблонизатор (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 делает за него грязную работу.
- Никакой лишней обработки шаблонов, они компилируются только один раз.
- Перекомпилируются только те шаблоны, которые изменились.
- Можно создавать пользовательские функции и модификаторы, что делает язык шаблонов чрезвычайно расширяемым.
- Допустимо неограниченное вложение секций, условий и т. д.
- Встроенный механизм кеширования.
- Произвольные источники шаблонов.
- Компонентная архитектура.
