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

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

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

но с модулем XSLT, view логику Angular можно вообще отдать XSLT
И зачем нам тогда тут Angular? Он кроме view-логики тут ничего особенного и не дает.
>И зачем нам тогда тут Angular?
Он меняет параметры XSLT фильтра на лету, а именно делает свою работу data-binding-га как фреймворк.
То есть, для XSLT — он заменяет сервер.

> те же задачи сегодня решаются массой более элегантных способов.
на вкус и цвет, элегантнее XSLT пока еще нет; ))
А, собсно, зачем? XSLT, конечно, это прикольно, здорово поворачивает мозги и во время о́но позволяло не давать бэкендерам устраивать вакханалию в шаблонах, а фронтендерам — в бизнес-логике. Но до прихода XSLT2 (который так и не пришел) многие вещи было сделать очень трудно, а без поддержки eXSLT приходилось еще и велосипедить.

При всей любви к моему первому FP-языку — сейчас у нас есть не менее мощные и более человечные шаблонизаторы.
xslt 2.0 появился почти 10 лет назад, по крайней мере на сервере
В одной-единственной, закрытой (и недешевой, ЕМНИП) имплементации. На практике все пользовались libxslt или биндингами к ней для своего языка. И не 10 лет назад, в 2009 еще не было (спека W3C была, имплементации не было).
Saxon опенсорсный, пользуемся им с 2007
Самое забавное в том, что бесплатная ветка 9.1 поддерживает практически все enterprise-фишки, которые в 9.2 стали платными, ее мы и используем в продакшне уже 8 лет — полная поддержка XSLT 2.0, Java-биндинги и т. д. Если на вход подавать саксоновскую же tinytree — то она еще и супер-быстрая, 10-15 мс на трансформацию типичной странички.

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

sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8
Насчет мощности, я, пожалуй, соглашусь, это я погорячился. Насчет дат спорить не буду, память уже не та, но в 2008 в яндексе и в 2009 в РИАНе мы почему-то не имели возможности использовать XSLT2.
На клиенте XSLT убитый. До ума его так и не довели. К сожалению. А так все было красиво по-началу.
А мы никогда на клиенте и не пытались это делать, на сервере намного удобнее. Опять же, низкая производительность XSLT — это миф, по крайней мере на Java
Если на сервере тогда совсем непонятно зачем в Angular совать XSLT. Кроме как из-за любви к XSLT :)

В тексте вообще говоря неточность.
«С чего бы использовать устаревшую технологию XSLT, ведь ее используют только с Java, да к тому же, только для Enterprise»?
По крайней мере я сталкивался с проектами и на .NET. и на php. И в своих проектах до сих пор использую.
В отечественных «коробочных» CMS на php до сих пор используется в UMI и HostCMS. В 2008 здесь много обсуждался неудачный опыт Битрикса (там кстати тиражировалась легенда о тормознутости)
На .Net сам в 2007 году использовал. В связке с Infopath ;) Правда после этого не очень хочется опять с этим связываться:)
Я так ни одной причины не увидел, чтобы использовать AngularJS совместно с XSLT. Зато вижу много недостатков:
  1. Громоздкий синтаксис
  2. Проблемы с производительностью
  3. Слабая поддержка XSLT разработчиками
  4. Трудно найти специалистов

Убежден, что чем меньше разных технологий используется в проекте, тем лучше и спокойнее. В AngularJS для повторного использования кода есть директивы. Оптимальнее пользоваться ими, так как они уже есть из коробки.
Данный фильтр используется только тогда, когда есть спец задание для XSLT, то есть задачи, где XSLT справляется лучше всего.
Иногда такие задачки случаются, и я был несказанно рад, когда увидел этот фильтр. Вот и решил поделится некоторыми решениями против «подводных каменей» при использовании этого фильтра.
Можно пример таких задач?
А с чем вы сравнивали, что утверждаете, что XSLT справляется лучше всего?
Мне кажется, что древовидные итерации легче делать на XSLT.
Ну а там где программно что-то решать, и все такое — тогда да, XSLT не мастак.
Наверное мне надо было сказать, что сравнение как между декларативными и процедурными языками?
Мне кажется, что древовидные итерации легче делать на XSLT.

По сравнению с чем?
По сравнению с процедурными языками.
Может вы попробуете вести беседу более развернуто, а не вопросами наскоками?
Ну так процедурными языками жизнь не ограничивается. Что мешает взять функциональные (или писать на гибридных в функциональном стиле)?
Ничего не мешает. Кто во что горазд!
Функциональные языки тоже круто.
Вот поэтому я и спрашиваю — почему вы так легко утверждаете, что XSLT справляется с каким-то классом задач лучше всех. Я такой класс задач знаю один, и это — преобразование xml-xml.
Надеюсь вы не обидитесь, если скажу, что кроме xml, xslt еще может преобразовывать в html?
Что тоже, по сути является XML.
Только результат похуже получается, и с валидацией иногда проблемы.

(и нет, html — это не xml, html (как и xml) — это sgml)
Не знаю какие проблемы с валидностью HTML на выходе XSLT, но дефолтные ангуляровские директивы сами по себе невалидны.
А еще XSLT умеет делать xml -> text или, например, xml -> pdf и вообще, если упороться, xslt удобен в преобразовании xml -> что-угодно. А еще xslt полон по Тьюрингу, что какбэ намекает ;)
Одно дело умеет, другое дело — «справляется лучше всех».

И да, если упороться, то можно применить его к любому преобразованию из XML, только удобным это не назовешь.
Дело в том, что данный модуль изначально был сделан для других целей, поэтому и доступен только в виде фильтра. Возможно, если у кого-то есть возможность и желание, то я с радостью приму ваши pull requests с поддержкой директив. :)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории