Как стать автором
Обновить

Комментарии 99

не часто, но один раз использовал

данные хранились в xml: удобно быстро редактировать и заливать обновления

при импорте xml разбивается на куски и помещается в базу: для того что бы делать постраничный вывод записей

при отображении rowset преобразовывался обратно в xml методом asXml: получаем часть большого xml файла, то есть срез, и работаем с ним xslt преобразованием

из этого xml делалась локализованная часть веб отображения (html) а также rss экспорт

резюмирую:
- исходник xml (ориентировочно "немаленький")
- в базе он разбивается на записи, но с расчётом на то что можно будет получить его срез
- срезы с помощью xslt преобразовываются в разные представления, а именно несколько html представлений и rss
Не я сам, а наши разработчики. Очень удобно — сделал преобразование, получил веб-страницу, сделал другое — вот тебе PDF для скачивания и т.п.
для PDF они используют XSL-FO, XSLT- это все таки преобразования из одного xml в другой (например xhtml)
На выходе XSLT может быть и не XML.
А чё заминусовали? Правду человек сказал.
ага. Я сама лично постила сюда перевод статьи о том, как микроформат hCard при помощи XSLT пропарсить до обычного vCard-файла :)
Использовал для построения документации в PDF. XML + XSL-FO + FOP = PDF.
использовал для шаблонов отображения, удобно. Но можно еще много гдеюзать
Мы в нашей системе используем xslt в качестве шаблонизатора. Опыт исключительно позитивный.
А какой язык (+фреймворк?) вы используете на стороне сервера (если не секрет)?
В UMI.CMS (umi-cms.ru)
использую в качестве шиблонизатора. доволен.
_шаблонизатора, всё-таки :)
А какой язык (+фреймворк?) вы используете на стороне сервера (если не секрет)?
не секрет. php.
Не секрет. C.
Делали проект в рамках университетской практики :)
Поскольку контора работает на большом количестве языков, то контентщики пишут контент в xml, дальше мы (верстальщики) эти xml при помощи xslt перекидываем на output в нужном нам виде в xhtml, а там уже с css наводим красоту. Парсится всё при помощи php. Вот.
хотите сесоса :) ? отдавайте все парсица браузеру :)))
ну я-то там верстальщик :) не мне такие вещи решать :) а вообще, что вы имели ввиду под "сесоса"?
секоса. Просто у разных браузеров всплывают различные глюки когда они трансформируют документ :)
НЛО прилетело и опубликовало эту надпись здесь
использовался для формирования emailов по шаблонам заказчика
Использовал для шаблонизации xml-лога. Опыт позитивный, как написали выше.
НЛО прилетело и опубликовало эту надпись здесь
Ну "реальные" переменные там определять все же можно, а что нужно было?
использую подобным образом. только преобразовывается в xHTML. все данные после выборки из базы преобразуются в xml, а дальше с помощью php применяются xsl-шаблоны. а клиенту передается только xHTML + js + css.
никаких сложностей. разве-что, из-за js, т.к. все работает через ajax.
... и как заметил denver, переменные определять можно, и передавать в templates(только в именованый) как параметры, а вот возвращать - по-моему нельзя.
Разрабатывал систему управления для WebMoney. Там часто нужно было получать список транзакций мессаг и прочего. WM имеет неплохой XML интерфейс. И часть таких админских интерфесов естественно легло под xslt.
а почему вообщем-то спрашиваете? :)
думаю, стоит ли уделять ему внимание. Почитал комменты, решил, что стоит.
Ну уделить внимание стоит, конечно. Но вот брать книжку и читать очень внимательно не думаю, что стоит... Я пытался изучить на будущее, но в результате все забыл. Просто напрочь.
Стоит почитать, что делает технология XML/XSLT/xPath, но пытаться запомнить синтаксис не стоит. Точнее не стоит уделять этому особое внимание.
Итог: стоит прочитать быстренько. Страниц 200 за выходной бахнуть, чтобы понимать "мощность" технологии, но сильно в подробности не стоит вдаваться до тех пор, пока нет на чем попрактиковаться.
НЛО прилетело и опубликовало эту надпись здесь
Как универсальный шаблонизатор. Ещё доводилось на лету создавать SVG из координат в XML.
CMS просто передает данные в формате XML, а обработка идет при помощи XSLT-преобразований
Отчёты формируются в xml, а xslt их приводит в разные божеские виды, включая docx :)
Как один из разработчиков HostCMS, могу сказать что xslt вещь весьма и весьма универсальная.

Практически весь html код сайта, начиная то меню сайта и заканчивая новостными лентами. Генерируется распарсиванием xml`а средствами xslt.
Понятно, т.е. всё таки реальное применение в коммерческих проектах есть. Спасибо, пойду читать про XSLT дальше.
Как один из разработчиков HostCMS, могу сказать что xslt вещь весьма и весьма универсальная.

Практически весь html код сайта, начиная то меню сайта и заканчивая новостными лентами. Генерируется распарсиванием xml`а средствами xslt.
Использую в качестве "продвинутого" шаблонизатора: xml - от элементарного до несортированных списков и пр. и пр. Доволен как черт.
А какой язык (+фреймворк?) вы используете на стороне сервера (если не секрет)?
Не секрет. PHP + самописная cms.
Движок выдаёт XML, точнее JDOM дерево, которое трансформируется либо в HTML, либо в WML, либо в iHTML (i-mode), либо в другой XML, который уже хавают flash или win32 клиенты.
А кто как всётаки - парсить XSLT шаблонами используюя скрипты, или отдавать это дело браузеру? Думаю если парсить скриптами, то будет напряжнее на сервер чем при использовании шаблонизаторов типа Mako/Smarty.

В случае если выдавать на парсинг браузеру, то не совсем понятно как на это посмотрят поисковики.
Имхо, если уж совсем правильно: перекидывать парсинг на клиента только если он это поддерживает. Как определить - не думал, а хоть и бы по user agent для начала. Перекидывать для IE55+ и FF. В таком случае непродвинутые браузеры и поисковики получат HTML.

По нагрузке: если страницы можно кэшировать - вшистко едно. Если же при каждом показе трансформировать - то при большой нагрузке будет заметно медленней чем шаблонизатор попроще. Хотя если перекидывать избирательно на клиента, то быть может XSLT даже выгодней будет (ведь IE + FF это львиная доля).

Мне кажется что серверные XSLT-парсеры пока не особо оптимизированы (что, тем не менее, не фатально и можно использовать то что есть). Имхо со временем чаша производительности должна измениться в сторону XSLT. Так что я думаю привыкать можно смело.
Вот XML то генерить тоже надо. А это накладная штука.
За разный контент разным посетителям сайта можно по шапке получить от гугла.
Общем пока что мое мнение такое, что для веб программинга не стоит юзать XSLT. Нет смысла генерить XML потом XSLT преобразует в HTML. Мне кажется XSLT придуман и подходит для обработки данных из XML где нибудь на сервере для каких то второстепенных нужд. Типа лежит файлик с данными, совсем несложно написать XSLT шаблон чтобы превратить во что то другое.
Поставил бы +, но не имею возможности :(
Хотел немного добавить. Согласен, что генерить XML, а потом его обрабатывать XSLT неправильно. Использовать XSLT стоит, когда у тебя уже есть сгенерированных XML - например, ты получил его от другого сайта. Тогда другое дело. Но самому генерировать XML, забирая контент, например, из базы, а потом его преобразовывать XSLT глупо.
Сейчас есть всякие RSS и т.п. - вот место для XSLT (тут ты не знаешь, когда будет сгенерирована новая версия XML, поэтому и не можешь ее хранить в базе).

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

Возможно имеет смысл хранить постоянную информацию в виде XML, а потом ее преобразовывать в XHTML с помощью XSLT, когда у тебя объем XML файлов очень большой, а используется каждый в отдельности очень редко. Иначе тогда выгоднее хранить инфу в базе - ведь из нее быстрее вытянуть, чем из файловой системы.
я за тебя поставил.
спасибо :))
:)
вообще - смысл есть, даже если нужная инфа хранится в базе. Как насчёт того, чтобы генерировать контент в разных форматах? По умолчанию - HTML, по спецзапросу - PDF или docx, или ещё какой-нибудь изврат... делать это программно - ну его нафиг, геморроя много, да и порождает необходимость лезть в программный код при необходимости добавить поддержку нового формата. А так - всё просто... написал шаблон, закинул в папку - и юзай в случае надобности :)
Как часто вы видели страницы, на которых есть возможность скачать эту страницу в PDF? Как часто вы качали страницы в PDF если и находили такое? Суть не только в PDF.
Ну а генерировать контент в разных форматах чем вам мешает использование обычных шаблонизаторов? Покрайней мере гемора будет намного меньше. Попробуйте нагенерить на XSLT что нить посложнее... голова лопнет

В любом случае надо добавлять в скрипты возможность парсить документ нужным шаблоном.

MySQL -> XML -> HTML|PDF|etc. Зачем это лишнее звено (XML) если можно сразу генерить
HTML?. Если сделаете бенчмарк, то увидите как медленно генерится XML. Потом посмотрите как долго происходит XSL трансформация. И сравните с тем, если бы этого звена небыло.

Тут есть смысл юзать его если необходимо на выходе иметь XML (Например RSS либо API), или XML по каким то другим причинам замешан в этом деле. Например feedburner отдает XML и дает на парсинг браузеру ещё и XSL шаблон. Тогда RSS выглядит на странице как им это надо а не как сделано в браузере.

Для обычных вебсайтов мне кажется это неосознанный ход как минимум из соображений производительности (в крайнем случае пока не все браузеры могут распознавать). Ну а если уже и отдаешь браузеру эту работу, то с поисковиками непонятно как дело обстоит.
я, как ни странно, такие "разноформатные" страницы видела - там, где выложены материалы более значимые, чем последние новости и личные дневники. Техническая документация, электронные библиотеки - да мало ли применений! Обычные шаблонизаторы типа Smarty зубы сломают о подобное, а генерировать напрямую из PHP, питона, руби или ещ чего-нибудь - каждый раз неудобно как-то новое выписывать. Вот быстродействие - да, может пострадать ввиду введения лишнего звена... но тут уже, что называется, надо решать, какое зло будет меньшим в каждом конкретном случае.
А вы посмотрите на XSL как на часть front-end'a. Или как на инструмент верстальщика. И все встанет на свои места.
Да я не против XSL. Я за то что его надо использовать где действительно он будет полезен. Но раз уж мы говорим о веб разработках, то тут хорошо подумать надо. Ну а верстальщику проще сверстать на шаблонах смарти чем ломать голову над XSLT. Я 2 года с ним проработал и знаю что это такое когда надо на нем сверстать довольно сложную страницу, да и с довольно сложным JS на этой странице.
Тут спорить с вами не буду, уже два года верстаю XML/XSLT - очень удобно и расширяет возможности верстки. Со Smarty знаком только по наслышке.
JS либо вставляется через CDATA, либо < / > и тд, конвертируются в entities.
мое мнение такое, что для веб программинга не стоит юзать XSLT. Нет смысла генерить XML потом XSLT преобразует в HTML.

Я пожалуй добавлю ваш коммент в избранное и поставлю ремайндер на "через 1 год". Там посмотрим :)
У вас предубеждения, а я делал сравнение темплейт систем. Не смотря на то что нужно генерировать XML нельзя сказаь что весь процесс был медленней на порядок. Всего-то раза в два. И то, бОльшая часть была из-за медленного парсера Sablotron. Так что не стоит так брезгливо смотреть на это, некоторые уже используют.
А вот обрабатывать большой XML файл (однажды сгенерированный из базы) с помощью XSLT это точно перебор. Просто очень медленно по сравнению с SQL->XML->XSLT->HTML.
Sablotron + cache = ♥
Думаю лучше всё таки отдавать xhtml.
А на сервере сфантазировать что-нибудь, кеширование там какое или ещё что.
Пользовал XLST в качестве шаблонизатора для своих проектов в течение 3-4 лет на технологии Parser 3 (www.parser.ru).
Только вот гемморно это. Вот весь мой OnRails, сколько из-за трудоемкости разработки xslt, которая в большинстве случаев не оправдывает полученной универсальности. Плюс обязательное преобразование в xhtml, сложности с обработкой пользовательского ввода и сущностей   и   и прочих.

Шаблоны получаются слишком избыточными xslt кодом.
Скорее всего вы прийдете к такому же мнению.
Обязательный xhtml (а если быть точным, то well-formed html) - это ведь в целом неплохо. И не трудно приучить себя писать на нем. Пользовательский-же HTML обрабатывать не обязательно, а вставлять в результат как есть (disable-output-escaping). Т.е. ничего лишнего делать не надо кроме как тэги правильно закрывать в СВОЕМ коде.

А насчет вида шаблона. Избыточный плохое слово, код-то достаточный. А вот непривычно что так много - это да. Но разве у остальных шаблонизаторов будет меньше? Да, у тех что и по функционалу попроще (и соответственно с отделением представления от бизнес логики). И потом, кому это мешает если есть специалисты верстальщики которые понимают XSLT? Если же их у вас нет, то тогда, конечно, неприятно.
спасибо за пояснения.
Поддерживаю
в качестве шаблонизатора
Один раз использовал в качестве ознакомления. Долго искал доступную документацию, не нашел и приходилось все делать долго и мучительно по примерам. В итоге я бросил эту затею и сейчас вспоминаю, как страшный сон
В качестве мастера шаблонов для веб сайтов. К сведению бОльшая часть сайта Microsoft именно так и реализована.
Вы имеете ввиду microsoft.com?
Да, большая часть http://www.microsoft.com/rus написана путем XSLT преобразований.
Тоже мне пример для подражания...)
microsoft.com - это ведь не совсем "сайт", а скорее web-вершина какого-то data-айсберга!
В такой ситуации видимо xml+xslt - единственный выход.
Для обычных же сайтов (как верно замечено выше) - все это довольно избыточно. Шаблонизацию можно устроить намного проще.
Да, я использую xslt как шаблонизатор в своем php-фреймворке. На мой взгляд очень удобно. Одна из причин использования такого подхода - возможность максимально отвязать код от дизайна.
да. юзаю его в xaraya-framework.
"возможность максимально отвязать код от дизайна" :)) смешно,
думаю ЭТО никогда нельзя будет "отвызать" ... либо кодерам хоть чучуть верстать уметь, либо верстальщикам чучуть додить, т.к. комнтрукции , , , и т.п. все-таки юзать приходится :)
Как и многие, использую xslt для построения шаблонов.
У меня CMS-ка выдает все в XML-формате а перед выдачей всей страницы пользователю она парситься XSL-шаблоном.

Насчет геммороя - не соглашусь. Раньше делал шаблоны в коде, т.к. было лень использовать XML. Однако, потратив пару месяцев на освоение xslt полностью на него перешел и возвращаться обратно не собираюсь.

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

Вообщем, всем советую.
CMS-ка собственная, написана на Parser.
спасибо за пояснения
Сферическая шаблонизация в вакууме! ))))
Использовали для построения шаблонов в одном проекте, на стороне клиента обработка идет на ajaxslt (http://goog-ajaxslt.sourceforge.net/), на стороне сервера используя libxslt в PHP(--with-xsl). При этом в конфиге и в ajax запросе передается параметр типа вывода. Таким образом можно решать где обрабатывать xslt, на клиенте или на сервере, что делает механизм очень гибким.

Идея использования XSLT, показавшаяся вначале сумасшедшей, оказалась идеальным решением, отделив данные с которыми работает PHP+MySQL от их графического представления.
НЛО прилетело и опубликовало эту надпись здесь
можно использовать и нативную поддержку XSLT в браузерах, но весь проект работает на AJAX без перегрузки страницы. Использовать несколько библиотек не хотелось, а ajaxslt активно используется google и, соответственно, обновляется. Опять же, работает во всех браузерах, готовые костыли лучше самодельных в данном случае.

Несколько ограничений было замечено, но все обошли малой кровью.

Самое важное - оставить возможность обработки на сервере, ибо некоторые действия с XSLT подвешивают IE и подобные трансформации лучше делать на сервере, передавая готовый HTML
НЛО прилетело и опубликовало эту надпись здесь
Последнее обновление было 4 дня назад, до этого 16.11.2007 (http://code.google.com/p/ajaxslt/downloads/list)
на sf.net проект больше не обновляется
НЛО прилетело и опубликовало эту надпись здесь
в .net использовал для написания голосований и опросов
Работаю с xslt почти четыре года. Поначалу было сложно, но разобравшись... мощный интрумент!

Конечно, лучший шаблонизатор...
Первый опыт был с формой контракта. Пользователь заполнял поля, данные, по мере набора, в xml отправлялись на сервер, где лежали 2 шаблона (html + xslt). Трансформация подхватывала данные и расставляла их "по местам" в html-шаблон (доступ к которому имели дизайнеры, не разбиравшиеся в xslt, но этого им было и не нужно). Результирующий html возвращался пользователю в качестве preview контракта... удобно всем — и разработчикам (нас никто не трогает — изменения в форме контракта не требуют изменения кода, поменяли html-шаблон и делов) и дизайнерам (не нужно ничего кодить) и менеджменту...

Продолжением стала работа с формами InfoPath из комплекта MS Office. Там xslt используется как основополагающий инструмент построения отображения. Идея проста, как три копейки — данные (xml-файл) могут быть представлены разными видами (xslt) плюс иметь бизнес-логику в codebehind (C#, JScript) и отображаться встроенным компонентом InternetExplorer. При этом визуальный редактор позволяет накидать дизайн этих видов очень быстро...
Сейчас формы InfoPath с помощью OfficeServer адаптируются для тонких клиентов - перекочёвывают в веб. И здесь мы столкнулись с одной небольшой проблемой. Десктопное приложение поддерживает dataset'овы дифграммы, а web-версия не хочет. Так вот, спомощью xslt на сервере преобразуем получаемые от клиента данные в diffgram, и dataset их "кушает" за милую душу!

Ну и напоследок хочу сказать о производительности. Был у меня один проект... xml-слепок таблиц базы данных, собираемый из нескольких источников, список литературы, с кучей атрибутов... xml файл весил чуть больше 8 мегабайт. Требовалось выдавать пользователю постраничный вид, отсортированный и отфильтрованый по любым из атрибутов. Проблема была в том, что данные были несколько неоднородны. Решили попробовать xslt. И не прогадали — построение вида было довольно быстрым — трансформация перелопачивала весь файл за считанные секунды (особенно, когда его в кэш загнали :)... так и работает до сих пор :-)

Поскольку пишем под ASP.NET то парсером является msxml.
Кстати, в 2005 студии появилась возможность дебагать xslt прямо из C#-кода, а msxml позволяет включать в трансформацию скрипты JavaScript, C# и VB, что очень помогает для реализации, например, таких вещей, как хранение переменных. В упомянутом diffgam-преобразователе замечательно используются Generic коллекция :-)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Использую XSLT 4 года. В последние месяцы прихожу к выводу: это слишком универсальная технология. Для узкоспециальной задачи - веба - есть более функциональные и удобные решения.

Плюсы следующие:
1. Это стандарт. Значит, можно менять и расширять штат верстальщиков, не заботясь об известных им форматах хранения шаблонов - читай "языков программирования". Ситуация, когда приходится править вёрстку, вернее, вносить изменения внутри запрограммированного шаблона - довольно частая.
2. Поддержка именованных и параметризованных блоков в шаблонах. Smarty и erb заставляют эти блоки держать в отдельных файлах.
3. Генерация валидного (X)HTML.

Минусы:
1. Не слишком удобный декларативный синтаксис. Скажем, если генерируется список option'ов, конструкция, прописывающая аттрибут "selected" на XSLT выглядит гораздо длиннее, чем на erb.
2. В XSLT 1.0 мало функций. Вывод русской даты стандартными средствами - целый геморрой, хотя, конкретно в PHP можно вызвать внешнюю PHP-функцию. Тут и проявляются "прелести" синтаксиса.
3. Оверхед:
- Нужно прописывать DTD, заголовки, подгружать описания HTML-сущностей и
так далее.
- Данные приходится преобразовывать из формата языка программирования в
XML: эта операция создаёт избыточность внутри конкретного скрипта - одни
и те же данные приходится держать в переменных скрипта (выборка из базы)
и в XML.
4. Отсутствие конечных циклов (изменить $i от 1 до 3). Требуется, скажем, для генерации номеров страниц в постраничной навигации.
5. Не особенно удобно делать шаблоны текстовых писем (xml:space="preserve"): за переносами следить сложнее чем в случае шаблона на PHP. Аннонят конструкции вроде: " Здравствуйте! ... (тут перенос)... ".
6. XPath не позволяет делать некоторые типы выборок. К сожалению, не могу привести конкретный пример, но я с этим время от времени сталкиваюсь.
7. Что спорно и решаемо - скорость работы.
со многим не согласен:

минусы:
1. что тут сложного и долгого?
<xsl:template match="input" mode="form">
<xsl:element name="{name()}">
<xsl:if test="@selected = true">
<xsl:attribute name="selected">selected</xsl:attribute>
</xsl:if>
<xsl:value-of select="." />
</xsl:element>
</xsl:template>

2. так вроде совсем просто
<my-date year="2007" month="2" day="12" />
<xml-months>
<month>января</month>
<month>февреля</month>
<month>марта</month>
...
</xml-months>
<xsl:value-of select="//xml-months/*[position() = //my-date/@month]/text()" />

3. все тривиально
а) один раз прописать
б) делайте хоть echo(), а в ob() вызовите обработчик
4. может я не понял, но чем вам рекурсивный вызов шаблонов с параметрами
не нравится? в них и проводите инкремент

5. странно
<xsl:text>&#xA;</xsl:text>

6. ???

7. поспорю
updated
<xsl:if test="@selected = 'true'">, конечно же
Я не писал о том что эти задачи нерешаемы. Я писал о том что XSLT не всегда удобен. XSLT - прекрасный инструмент, но для шаблонизации веб-страниц часто можно использовать что-то попроще.

Скажем, вместо конструкции из пункта 1 мне удобнее написать:

<select name="..."><?= generate_options($options, $selected); ?></select>

Это короче, понятнее и быстрее работает.

То же с конечными циклами: вряд ли кто-то согласится заменить конструкцию for на рекурсивную функцию в C++. В XSLT рекурсивные шаблоны - не удобное, а вынужденное решение, workaround.
Никто не запрещает в xslt вписать JavaScript и вызвать его таким образом:

<xsl:value-of select="myfunctions:generate_options($options, $selected)/>

Ещё проще и понятнее :-)
Не совсем.
<select name="..."><?= generate_options($options, $selected); ?></select>

против

<select name="..."><xsl:value-of select="php:generate_options($options, $selected)/></select>

:)

Я не против XSLT, использую его почти во всех проектах. Лишь попытался описать минусы. Читаемость и писаемость :) всё же оставляют желать лушего. Я слышал что-то про краткий синтаксис, но не копал глубоко.
Правильно будет <select><xsl:apply-tempaltes select="$options"/></select>
И написать шаблон по обработке данных, что в $options, и не нужно городить тут функции пользователя для работы, с которой XSLT справится лучше.
Если привести полностью, то будет что-то в духе:

<xsl:variable name="options" select="/root/options"/>
<xsl:apply-templates select="$options">
<xsl:with-param name="selected" value="/root/currentOption"/>
</xsl:apply-templates>

<xsl:template match="options/row">
<option value="{id}"><xsl:if test="$selected=current()/id">
<xsl:attribute name="selected">yes</xsl:attribute>
<xsl:value-of select="value"/>
</option>
</xsl:template>


Запись достаточно громоздкая. Я ещё раз повторяю, XSLT - эффективный инструмент, но его синтаксис в приложении к языку шаблонов сайта мог бы быть проще.
Вы здесь показали реализацию <xsl:template match="options/row"> и не показываете реализацию php:generate_options(). Так что сравнение однобокое получается.

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

Результатами голосования опечален. Я думал, что хабра-пипл - более продвинутый контингент. А 40% просто не знакомы с этой технологией. (Те 33% которые ответили строго "НЕТ" видимо знакомы поверхностно.) Весьма печально.



Использую xml/xsl повсеместно. Результатом работы практически любого моего php-скрипта/java-сервлета является xml-документ. xml/xsl - отличный инструмент расслоения системы на layer'ы document/view.



По фразе "я использую xml/xsl в качестве шаблонизатора", можно понять, что человек уже знаком как минимум с одним php/java/python/...-шаблонизатором и ошибочно употребляет слово шаблонизатор в этом контексте.



Я принципиально против использования любых шаблонизаторов (не xslt-процессоров). Есть стандартизованый протокол документа и стандартизованый протокол преобразования. Незачем изголяться и придумывать каждый раз что-то новое.

Ой... Видимо зря я сам отформатировал коммент.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории