Все согласны с этим утверждением?

В последнее время меня очень сильно интересует XSLT Эта технология стремительно завоёвывает популярность.
Однако меня смущает вопрос производительности. Позволю себе процитировать блог господина Рыжикова.

Цитата:

1. Иллюзия простоты XSLT шаблонов.

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

2. Иллюзия управляемости и гибкости.

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

3. Иллюзия производительности, дешевого размещения и масштабируемости.

Как не стараются разработчики, производительность XML+XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей архитектуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных получая на выходе опять же текст, который занимает память.

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

Лично я согласен на 100% с первым пунктом и частично со вторым. Очень хочется услышать мнение опытных программистов, имеющих реальный опыт работы. Особенно интересует пункт 3.

Насчет 3 пункта - ну таким подходом будет действительно медленнее. Но ни кто же не запрещает отдать пользователю xml+xslt и проводить преобразование на стороне клиента.
К тому же xpath это самый медленный способ обработки xml. Есть же еще DOM и SAX (самый быстрый).
Но в любом случае у вас появляется лишнее звено ... -> xml -> ...

Цитата ("mx-media"):

Эта технология стремительно завоёвывает популярность.

Здрасте. Вообще то популярность завоевана давно.

По выложенным пунктам я бы сказал так.

1. Ерунда. Фраза насчет специалиста "очень высокой квалификации" помоему нужна только чтобы набить цену. Конечно, шаблоны бывают сложные, но с большинством шаблонов вполне можно разобраться самостоятельно.

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

3. Смотря как делать. Если делать с умом, то производительности хватает. Либо, как уже сказали, отдавать их на клиента, либо использовать парсер, максимально подходящий для требуемых задач.

Работаю с XSLT уже много лет, чуть ли не с момента его появления. Мое мнение по пунктам:

1. Согласен частично. "Подправить" может любой, даже вообще не программист. Например, изменить контент, сделать что-то с разметкой по мелочи. Но факт, что создать XSLT шаблон раз в 10 сложнее, чем HTML страницу. То есть, делать новые шаблоны, особенно сложные, без серьезного технического бакграунда - малореально. Слишком уж много деталей и ограничений спецификации. Также тут ряд других технологий задействовано, которыми нужно вдалеть (взять тот же XPath). Но оно стоит затраченных усилий.

2. Не согласен, точнее этот пункт вообще не в тему. XSLT шаблоны по своей сути не предназначены для серьезной бизнес логики. Сравнивать XSLT (основная цель которого - преобразования одних документов в другие) с языками программирования так же нелепо, как и сравнивать с ними HTML (язык разметки).

3. Частично согласен. Производительностью тут и не пахнет. Более того, мало что можно найти более тормозное, чем XSLT преобразование. Но тут правильно упомянуто про кеширование, именно связка XSLT + кеш дает нужный эффект. По сути, XSLT ни в коем случае нельзя использовать для постоянного формирования налету документов, или, например, HTML страниц. Даже самый мощный хост при более-менее нормальной нагрузке при этом умрет. XSLT имеет смысл использовать для разового преобразования, например при изменении набора данных, и это вообще желательно делать оффлайн (хотя и не обязательно).

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

Самое эффективное применение - это именно оффлайновое преобразование входного XML в любой другой вид. Смысл использования прост до гениальности: XML + = . Вот как раз эти - это и реализуются XSLT.

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

В общем, с господином Рыжиковым я не могу согласиться по теме XSLT в целом.

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

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

3)Выжать просто: писать грамотно. Например, вынос определения переменной из цикла иногда сокращает время работы скрипта в несколько раз. Поэтому главное тщательно продумывать свои скрипты и все будет нормально.

mx-media, а это не тот ли, случайно, Рыжиков который Битрикс?

Это он - ссылка

Цитата ("bewhite"):

mx-media, а это не тот ли, случайно, Рыжиков который Битрикс?

Он самый.

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

Чудес не бывает, XSLT не делает всего-всего, это лишь мощнейший универсальный инструмент для преобразования документов. А вот расплата за мощь и универсальность - низкая производительность. С этим приходится мириться. Но прогресс не стоит на месте, XSLT процессоры становятся все более и более быстрыми, железо тоже не отстает, так что рано или поздно настанет время, когда незнание XSLT будет считаться таким же плохим тоном для веб программистов, как сейчас - незнание HTML.

tvv, Как Вы относитесь к использованию XSLT в цмс для магазина?

mx-media, отлично отношусь, целиком и полностью. Но - только для разовых преобразования в статику после изменения данных в этой CMS, то есть не для динамической генерации страниц, документов, или RSS лент.

Что может заменить XSLT? Только лишь код на каком-либо языке программирования, например на Java или PHP (к сожалению, в 99% случаев это так и делается, так как большинство программистов XSLT не владеют, к их стыду), но при этом такой код неизбежно будет содержать хардкодинг.

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

tvv, А если XSLT используется для генерации шаблонов? те грубо говоря результат выборки из базы преобразутся в xml, а дальше вывод парсится XSLT

mx-media, это тоже возможно, так часто делается, обычно при изменениях данных (если это не нужно делать постоянно, по реквесту любого пользователя). То есть, с помощью XSLT можно сделать из входящего XML документа чуть ли не вообще что угодно, в зависимости от задаваемых Вами правил. А как сформировать этот входящий XML документ - это уже детали, хоть и из БД брать данные и формировать XML, хоть откуда-то скачивать - это по задаче.

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

Цитата:

1. Иллюзия простоты XSLT шаблонов.

Частично, все зависит от шаблона. Кроме этого нужно знать XPath для выборки данных (требуется разобраться с осями например ).
НО если не требуется переделка логики, то разобраться можно.

Еще один минус: из-за похожести читать смесь HTML и XSLT(XML) очень не просто...

Кроме этого, еще несколько причин неудобности использования XSLT:
1) Отсутствие возможность подключения стилей в зависимоти от условий
Да, есть xsl:import и xsl:include, НО они должны быть элементами верхнего уровня, поэтому для генерации любой страницы необходимо подключение ВСЕХ стилей, большинство из которых может и не понадобится. Отсюда еще большая медлительность. Хотя решить эту проблему можно...

2) Проблемы с выводом сущностей (  и тд)
Все HTML сущности надо объявлять перед использованием, но даже после этого в конечном документе они будут представлены в виде юникода...

В некоторых слуаях проблема решаема, но добавление disable-output-escaping читабельности не повышает...

3) Использование функций
В PHP сделано отвратительно:

php:function('название функции', 'param 1', ...) 

+проблемы передачи параметров таким функциям.

Мне лично эта технология совсем не нравится!

Слишком награможенная и специфичная! Да вообще, зачем создават фактический конкурентный аналог тому же PHP??!
Это скорее чистая коммерция, чем реальный прорыв в технологии! Пример тому соперничество JavaScript и JavaScript2... чистая коммерция и мистификация развития технологиии!

RossVic, PHP и XSLT это абсолютно разные вещи. Сравнивать их между собой некорректно.

Я не сравнивал. Я привел пример того как тоже самое происходило между Java и PHP. Кто "у руля" видно теперь без линз.
Прочтите топ снова...не торопясь пожалуйста!

Цитата ("RossVic"):

Я не сравнивал. Я привел пример того как тоже самое происходило между Java и PHP. Кто "у руля" видно теперь без линз.
Прочтите топ снова...не торопясь пожалуйста!

RossVic, а что происходило между Java и PHP, напомните пожалуйста? И что теперь видно без линз?

На PHP примерно раз в 20 больше проектов. Но суммарный бюджет этих проектов меньше, чем на Java (обычный Java/J2EE проект, измеряемый человеко-годами - это норма, и рейты джавистов обычно самые высокие среди всех технологий). Так что тут нельзя сказать кто "у руля". Это все равно, что утверждать кто победит, боксер или шахматист, забыв указать, в чем победит, по каким критериям оценивать противостояние.

Вот Вы сами между прочим ответили на свой вопрос и даже не заметили этого!

Конкурентное соревнование между Java и PHP возникло когда до PHP на сцене, как противовес убогоуправляемому Java, появился Perl!
За короткий промежуток времени (сравнительно 4-5 лет!) Перл сменил PHP и JAVA осталась на позициях аплетостроительства!

Назовите хоть одну популярную СМS на основе JAVA технологии?! ...только не говорите что это две разные технологии...это излишне! У них по сути одни и теже задачи. Мы же рассматриваем вопрос технологичности...и суть начального топика заключалась как раз таки в сравнении нескольких технологий на производительность и технологичность! Примеры с Java и PHP были лишь иллюстративными примерами какая технология "выжила" и развивается после конкурентного соперничества! Поэтому спор бессмысленен изначально!

Вот прочтите топик LastDragon... в этом была суть данной темы, а вовсе не о технологиях Java и PHP.

Господин Рыжиков, по-видимому, не особо разбирается в терминологии, поскольку XSLT - это не язык, а преобразование Язык называется XSL
Использую сиё средство для:
1) написания шаблонов к некоторым CMS. Хотя как шаблонизатор связка XML + XSL действительно добавляет ненужную прослойку, да и ресурсов на преобразование требует прилично Не вижу особых плюсов для использования XSL в данных задачах, на мой взгляд, подключаемые библиотеки тегов для JSP не только не хуже, а даже лучше. Для Perl, конечно, шаблонизаторы попроще, но они тоже есть
2)для преобразования XML -> XML. Иногда требуется преобразовывать форматы файлов на лету, так вот мне лениво делать разбор документа, гораздо проще это сделать с помощью XSL-преобразования Вот для таких целей - просто конфетка :-*


2RossVic
"Назовите хоть одну популярную СМS на основе JAVA технологии?!"
А что Вы называете популярностью? Вот, к примеру, неплохая и бесплатная: OpenCMS
Со своими минусами конечно (за код внутри JSP шаблона надо по рукам ))))
Но вот список внедрений за рубежом: ссылка
А вот список внедрений в РФ: ссылка
Скорее всего она уступает joomla или drupal по популярности, но внедрений (успешных) больше 1000 уже есть

P.S. А Вы можете, RossVic, назвать сайт хотя бы одного банка, или оператора сотовой связи, который работает на joomla или drupal? ;-)