Angular XSLT module

[@VasilioRuzanni]

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

но с модулем XSLT, view логику Angular можно вообще отдать XSLT

И зачем нам тогда тут Angular? Он кроме view-логики тут ничего особенного и не дает.

[@anjiJa]

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

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

[@k12th]

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

При всей любви к моему первому FP-языку — сейчас у нас есть не менее мощные и более человечные шаблонизаторы.

[@grobitto]

xslt 2.0 появился почти 10 лет назад, по крайней мере на сервере

[@k12th]

В одной-единственной, закрытой (и недешевой, ЕМНИП) имплементации. На практике все пользовались libxslt или биндингами к ней для своего языка. И не 10 лет назад, в 2009 еще не было (спека W3C была, имплементации не было).

[@grobitto]

Saxon опенсорсный, пользуемся им с 2007

[@grobitto]

Самое забавное в том, что бесплатная ветка 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

[@k12th]

Насчет мощности, я, пожалуй, соглашусь, это я погорячился. Насчет дат спорить не буду, память уже не та, но в 2008 в яндексе и в 2009 в РИАНе мы почему-то не имели возможности использовать XSLT2.

[@asave]

На клиенте XSLT убитый. До ума его так и не довели. К сожалению. А так все было красиво по-началу.

[@grobitto]

А мы никогда на клиенте и не пытались это делать, на сервере намного удобнее. Опять же, низкая производительность XSLT — это миф, по крайней мере на Java

[@asave]

Если на сервере тогда совсем непонятно зачем в Angular совать XSLT. Кроме как из-за любви к XSLT :)

В тексте вообще говоря неточность.
«С чего бы использовать устаревшую технологию XSLT, ведь ее используют только с Java, да к тому же, только для Enterprise»?
По крайней мере я сталкивался с проектами и на .NET. и на php. И в своих проектах до сих пор использую.
В отечественных «коробочных» CMS на php до сих пор используется в UMI и HostCMS. В 2008 здесь много обсуждался неудачный опыт Битрикса (там кстати тиражировалась легенда о тормознутости)

[@Razaz]

На .Net сам в 2007 году использовал. В связке с Infopath ;) Правда после этого не очень хочется опять с этим связываться:)

[@zolotyh]

Я так ни одной причины не увидел, чтобы использовать AngularJS совместно с XSLT. Зато вижу много недостатков:

1. Громоздкий синтаксис
2. Проблемы с производительностью
3. Слабая поддержка XSLT разработчиками
4. Трудно найти специалистов

Убежден, что чем меньше разных технологий используется в проекте, тем лучше и спокойнее. В AngularJS для повторного использования кода есть директивы. Оптимальнее пользоваться ими, так как они уже есть из коробки.

[@anjiJa]

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

[@Razaz]

Можно пример таких задач?

[@anjiJa]

Вот как раз и пример задачи:

www.fl.ru/projects/2489348/frontend-verstka-formyi-raspisaniya-po-konkretnoy-date.html

Ну и примерное решение, в конце данного топика, видео из вк.

[@lair]

А с чем вы сравнивали, что утверждаете, что XSLT справляется лучше всего?

[@anjiJa]

Мне кажется, что древовидные итерации легче делать на XSLT.
Ну а там где программно что-то решать, и все такое — тогда да, XSLT не мастак.
Наверное мне надо было сказать, что сравнение как между декларативными и процедурными языками?

[@lair]

Мне кажется, что древовидные итерации легче делать на XSLT.

По сравнению с чем?

[@anjiJa]

По сравнению с процедурными языками.
Может вы попробуете вести беседу более развернуто, а не вопросами наскоками?

[@lair]

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

[@anjiJa]

Ничего не мешает. Кто во что горазд!
Функциональные языки тоже круто.

[@lair]

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

[@anjiJa]

Надеюсь вы не обидитесь, если скажу, что кроме xml, xslt еще может преобразовывать в html?
Что тоже, по сути является XML.

[@lair]

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

(и нет, html — это не xml, html (как и xml) — это sgml)

[@asave]

Не знаю какие проблемы с валидностью HTML на выходе XSLT, но дефолтные ангуляровские директивы сами по себе невалидны.

[@mx2000]

А еще XSLT умеет делать xml -> text или, например, xml -> pdf и вообще, если упороться, xslt удобен в преобразовании xml -> что-угодно. А еще xslt полон по Тьюрингу, что какбэ намекает ;)

[@lair]

Одно дело умеет, другое дело — «справляется лучше всех».

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

[@dannyzubarev]

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