1. В целом, согласен, что применение XSLT — это шаг вперед.

2. Слова же о невозможности отчуждения проектов, в которых использован Smarty, видятся мне спорными. Здесь как кто напишет. Есть культура программирования в фирме — напишут нормально. Нет культуры программирования — и бизнес-логику с представлением смешают, и кучу врапперов к врапперам врапперов напридумывают :) С другой стороны, XSLT дисциплинирует и способствует снятию большого количества геморроя для директора студии в будущем, когда штат программеров, работавших над каким-то давним сайтом, ротируется, а исправления или дополнения в таком проекте приведут к потерям оплачиваемого рабочего времени на разборки с кодом и бакгфиксы к багфиксам.

3. Наконец-то стали говорить о производительности XSLT и адекватности применяемых решений. Давно ждал, кто же ответит Сергею Рыжикову на его слова ( ага, кто бы говорил :-) ) про "низкую производительность" и "требования к отдельному серверу".

хм, а я вот склонна согласиться с Сергеем Котыревым относительно Смарти. Допустим, сайт делает не студия со штатом разработчиков, а фрилансер. Потом нам сайт надо модернизировать, приукрасить, в общем, заняться тюнингом проекта. Далеко не всегда есть возможность обратиться к "отцу" сайта - первому разработчику. А пригласите Вы другого, он скажет: "Э, нет, друг! Тут все нафиг надо переписывать, переделывать и вообще - все не по уму". Имхо, внушительный счет на N-ное количество килобаксов заставить помянуть Смарти не слишком добрым словом. К сожалению, таких историй море, так что вопрос целесообразности использования ХСЛТ актуален. Только где вот программеров XSLT-шных брать - вот в чем вопрос?

На мой взгляд забыли упомянуть, что XSLT давольно расширяемый язык, и тем кого не устраивают стандартные возможности - могут подключить дополнительные расширения для языка, написанные сторонними разработчиками (яркий пример расширения проекта http://exslt.org/).

Когда речь заходит о выборе той или иной технологии нужно абсолютно точно понимать что в любом случае тебе придется платить. Вопрос лишь в том - сколько? и за что? Любой инструмент призван решать конкретную задачу - отвертка закручивает винты, а молоток забивает гвозди.
У XSLT есть только одно слабое место, за которое так любят цеплятся его противники - производительность; и речь, зачастую, идет даже не о времени самой трансформации, а о лишнем шаге преобразования данных в xml, поскольку XSLT работает только с xml. Но я не слышал ни одного аргумента против XSLT с архитектурной точки зрения, потому что их нет. И я могу абсолютно точно сказать, не вдаваясь в детали, что в этом плане XSLT делает любой шаблонизатор, и тот, кто его использует, прекрасно знает за что он платит!
CMS, на мой взгляд, является универсальным средством создания сайтов, а значит должна позволять решать самые разные задачи, и для каждой конкретной задачи должна предоставлять необходимый инструмент, иными словами не только гвозди забивать, но и винты закручивать...
P.S. А еще есть чисто субъективные моменты, XSLT - красив!

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

P.S. Для нас оказался ближе Смарти.

А почему не рассматривается вопрос о том, что XML/XSLT шаблоны в коде весит намного больше, чем какой-то специализированный шаблонный движок, что приводит в конечном счете к увеличению количества и размера файлов проекта, увеличению времени на разработку и тестирование.

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

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

- а как же дебаггеры XSLT, которые есть и в Visual Studio, и для Eclipse?

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

Приходилось учавствовать в разработке довольно известных CMS, одна работала с XSL, другая с обычными шаблонами. Как одна фирма, так и другая занимаются, помимо разработки CMS, еще и разработкой сайтов на своих системах.
Так вот подход, применяемый в фирме, где система с XSL такой, что имеется законченная коробочная версия продукта, и на базе неё уже делается сайт. Все фичти реализуются "легальными способами", т.е. код системы (ядро, модули) не меняется, меняются только XSL шаблоны и специальные скрипты.
Во второй же системе, постоянно, под каждый проект, приходилось дорабатывать модули, а то и ядро, т.к. многие вещи обычными шаблонами просто не реализуешь, нужно было дописывать методы, исправлять существующие.
XSL же позволяет вынести часть логики непосредсвенно в шаблон.

Почему большенство наших производителей CMS против XSL - яснее ясного. Кому хочется ломать и строить заново уже устоявшийся механизм, который стабильно приносит $?

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

Отмечу, что, расписывая недостатки Smarty, автор статьи не упомянул о реализованной в нём возможности запрета напрямую обращаться к PHP. Детский сад, имхо: "а в Smarty можно запрос к БД в шаблоне прописать", "а в XML можно каталог товаров запихнуть и всё затормозит"... Так сдуру-то можно и сами знаете что сломать :) На мой взгляд, тема в статье раскрыта чересчур однобоко.

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

Однако, не со всеми аргументами могу согласиться.

Разделение логики и представления, вообще-то, зависит не только от технологии, но и от просветленности кодера. Умный кодер сделает все как надо хоть на смарти, хоть на шаблонах от phpBB. Глупый кодер и в XSLT такой лес нагородит, что проще будет застрелиться, чем понять полет мысли. Хотя, так уж исторически сложилось, что у нас люди, овладевшие XSLT, в среднем по больнице имеют более высокую квалификацию. Но это - не преимущество технологии. А часть приведенных пунктов, как мне кажется, выдают преимущества подхода "отделяй и влавствуй" за преимущества самого XSLT.

"Безопасность" - притянута за уши, ИМХО. В первую очередь, не следует допускать идиотов до кода, вне зависимости от технологии идиот накосячит. А если вдруг верстальщик действует не по глупости, а из вредительских побуждений - тем более не проблема все испортить - матерное слово в шаблон вставить, например :)

"Нативная поддержка XML" - не совсем в тему. Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - разумеется, XSLT будет оптимальным вариантом, он для этого и сделан. (При этом XSLT-процессор НЕ является "родным парсером XML", как сказано в статье. XSLT делает из одного XML другой XML, и все. Например, распарсить конфиг и передать данные в приложение XSLT не может). В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.

Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.

Вообще, не сказано о главном. XSLT сложно сравнивать с другими шаблонизаторами (ну, кроме его самописных модификаций). Сила XSLT - в его декларативности, это принципиально иной подход. Пока кодер мыслит категориями императивного программирования, он не поймет всей прелести XSLT, будет городить for-each'и, ругаясь на синтаксис. Чтоб писать лаконичные, не повторяющиеся, параметризуемые и гибкие шаблоны, нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.

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

Есть еще пара важных моментов, про которые в статье не сказано.
Во-первых, XML-документ является для верстальщика гораздо более наглядным представлением данных, с которыми он должен работать. Согласитесь, XML можно распечатать, изучить, разобраться в деталях. ИМХО, это гораздо лучше, чем убогая консоль smarty ;) При этом верстальщик понятия не имеет о внутреннем устройстве объектов в приложении. Он видит ТОЛЬКО данные.

Во-вторых, связка XML/XSLT _действительно_ кроссплатформенна. Можно переписать весь проект на другом языке программирования, не трогая при этом ни строчки в шаблонах. А можно отдать трансформацию целиком на клиент. Пока это не слишком реалистично, но перспективы есть.

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

Холивар.
В каментах почему-то все исходят из противопоставления XSLT - Smarty. В то время как и то и другое - крайности, и оба решения имеют массу недостатков. XSLT жутко сырой без примочек типа EXSLT, кроме того требует определенного стиля мышления, и иногда тривиальные задачи там решаются очень нетривиальным способом. Использовать XSLT сложнее чем просто прописать {$var} внутри html (отсюда и зарплата выше), кроме того он требует начальных данных в XML, то есть этот XML еще нужно составить.
А Smarty наборот перегружен ненужными фичами, из-за чего многие соблазняются писать на нем бизнес-логику.
Если уж говорить про php, мой выбор - Blitz или native php.

А что, МойКруг переписали под XSLT? Там же, вроде, Smarty раньше был.

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

Большинство описанных в этом абзаце проблем решается вменямым девелопером с хорошим инструментом разработки на раз.

отличная статья!

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

По поводу производительности. Имел опыт создания тестов возможности внедрения Smarty в CMS написанный с использованием XML+XSLT и при этом суть XSLT была реализована процентов на 80%-90%. Т.е. можно и лучше - но уже почти то что надо))
Пришел к выводу, что производительность у XSLT и Smarty практически равна.
НО при совершенно различных подходах.
Если использовать подход Smarty в XSLT - тормозит (о чем говорилось в статье)
Но если использовать наоборот - подход XSLT используя Smarty - тормозит еще больше. :)

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

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

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

В своём опыте разработки web - проектов, повидал многое.
Начиная от смеси php+html - как в битриксе например :(, заканчивая своими шаблонами и изобретением велосипеда.

Но пришёл всётаки к xslt.
Скорость работы, говорят некоторые? Честно скажу отличная.
Поддержка? Без проблем.
Разобраться в чужих шаблонах? Поверьте легче, чем к примеру в смарти.
При этом не надо знать php или другие языки, и бояться, что из-за чужого говнакода, вы потрёте глобальную переменную.

Минусы таковы. Всё что есть в интернете и в книгах по xslt, очень тяжело перенести в web.
Там рассказываются о возможностях, абстрактные примеры, спецификации.
А вот с примерами для web проблема.
Проблема и с php. Многие хостеры не любят обновляться. А вот php и libxml - если старые, там есть траблы.

Короче XSLT вещь. И всем советую. Одна проблема, чтобы научится его использовать и учесть многие нюансы, нужно много терпения и времени :( - Поэтому наверное xslt - верстальщики и стоят дорого.

Да совсем забыл. Есть люди увлекающийся типа всё в ООП, всё в функциях, и всё в XML и т.п. Я не фанат такого подхода. И призываю использовать XSLT - там где это нужно.

Небольшой вопросик от новичка в XSLT.

А разве сейчас уже три основных браузера не умеют сами, получая связку XML+XSLT, его трансформировать? Потому что я когда я себе тесты делал - именно так и было: был xml с данными и подключенным темплейтом XSLT. XML напрямую отдавался браузерам - а они показывали все так, будто он уже в HTML. То бишь генерация контента отдана клиенту и не тормозит сервер - ибо шаблон статичен, а XML если и динамичен, то уж точно не медленнее, чем если отдавать те же данные в виде HTML.

В общем вопрос тупой - если клиент может рендерить XML+XSLT, нафиг какие-то серверные преобразователи?

Вот, кстати, только что наткнулся:

Протоколы UData, UPage, UObject, UFS
Данные протоколы используются xslt-шаблоном для получения данных из БД
на сервере.

Это из мануала по использованию XSLT в UMI.CMS.

Мне кажется, это отличный пример порочной практики. Когда, вместо использования стандартных средств, разработчики придумывают что-то космическое. Заставляя вникать в то, как устроена их система изнутря, и при том нарушая стройность архитектуры. Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить. Я с UMI плотно не работал, может это и удобно в некоторых случаях. Но идеологически выглядит не правильно.

Чего XSLT действительно не хватает - так это функций форматирования даты / времени, и, местами, регулярок. И то, и другое реализовано в exslt, и, кажется, заложено в стандарт 2.0.

А нагружать шаблоны средствами для работы с бизнес-логикой, как это делают UMI (например, в шаблон передаются GET-параметры - ну нафига они там?) - ИМХО, не нужно.

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

С другой стороны, если речь идет о крупном проекте, над которым работают хорошие профессионалы с золотыми руками - такой подход будет только бонусным.

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

Еще пару слов в пользу XSLT. Долгое время работал с системой, использующей для отображения XSLT. Не стоит бояться о скорости ее работы. Все работало с хорошим быстродействием – а это была сотни 2 магазинов на одной обычной машинке (P4, 1Gb, IDE), по посещаемости весьма приблизительно – по 200 хостов на сайт в день.

Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.

Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.

При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).

Имхо, XSLT - отличная вещь, но чтоб внедрять ее в реальные проекты для реальных заказчиков за реальные $$$ надо 3-4 проекта сделать некоммерчиских, чисто для изучения технологии. А это зачастую слишком долго.

При упоминании XSLT у меня в горле встает комок примерно того же размера, что при упоминании о регулярках. И то и то хорошо, но ты в этом либо спец с опытом, либо ничего.

При разработке проектов для клиентов компании и для самой компании мы в свое время столкнулись с тем, что использовать "шаблоны" APS.NET опасно для психики и для проектов.
Идею использовать XML+XSLT в качестве движка шаблонов подсказал небольшой проектик, надо было прилепить еще старое Google Search API, которое было в виде SOAP Web Service.
Получить XML от веб-сервиса, сделать трансформацию и на выходе получить красивую страниу с результатами поиска.
Разобравшись с технологией, оказалось, что MS SQL замечательно возвращает результаты запросов в виде XML, C# получает XML, делает трансформацию. В итоге весь код занимает пару строчек. Для AJAXa можно использовать трансформацию на клиенской стороне. Встроеный набор функий XSLT можно раширять за счет написания функций на C# - ms-xslt это поддерживает.
Все очень красиво, элегантно, читабельно.
Автору спасибо за тему - я думала мы одиноки в использовании этой технологии.

когда я над сайтами МТС работал, то там всё висело под парсером и на XSL шаблонах.
не люблю XSLT, но должен признать - лучшего шаблонизатора я ещё не встречал в просторах всемирной...

Непонятно как вообще битрукс может наезжать по xml/xslt, их тварение чудовищно, оно убыточно и место ему на серверах типа Народ.ру. Если бы не туролобость и глупость менеджеров то битрукс никода бы не стал "лидером".

Что касаемо XML/XSLT то здесь не может быть проблем, надо признать что для применения его в промышленных маштабах нужно в цепочку програмист верстальщик вклинить еще одного человека js xml xslt програмиста, тогда дело пойдет совсем по другому, обычный пхп програмист не всегда способен воспринять логику xml есму проще поставить 20 проверок чем думать об базе глобально так же как и верстальщик недостаточно развит как правило до xml.

php активно работает над парсером и с каждым выпуском дело идет к лучшему.