XSLT хороший выбор для веб-платформы?

Популярность существующих систем управления веб-контентом на основе XSLT, таких как Umbraco и Symphony (SharePoint уже упоминался здесь), служит хорошим доказательством пригодности XSLT для веб-основы.

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

Рекомендация W3C XSLT-3.0 была опубликована в июне 2017 года, демонстрируя постоянный интерес и инвестиции в будущее XSLT.

Существует также несколько новых полезных расширений XSLT (и XQuery) на основе открытых стандартов, например, проект EXPath, библиотеки функций которого включают обширные возможности HTTP и Zip.

[Обновление] С запуском Saxon-CE (теперь с открытым исходным кодом), обработка XSLT 2.0 теперь может выполняться как на стороне сервера, так и на стороне клиента. Это также потенциально дает возможности 2.0 фреймворкам, ранее ограниченным XSLT 1.0.

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

Я использовал внутренний фреймворк, который полагался на XSLT для создания всего HTML (и, что ужасно, RTF и других форматов), и это оставило меня с некоторыми довольно сильными мнениями по этому вопросу.

XSLT - это отличный язык для преобразования одного формата XML в другой, когда оба формата хорошо определены.

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

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

В этом нет ничего плохого ...

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

Интересно, что SharePoint 2010 полностью поддерживает XSLT. У XSLT есть ноги ... не бойтесь.

Если вас беспокоит то, что ваши клиенты сопротивляются / не хотят поддерживать XSLT (даже если XSLT является стандартом и широко распространенной технологией преобразования XML) , вам нужно связать свой продукт именно с XSLT для задач преобразования XML? Если возможно (и безболезненно) абстрагироваться от соответствующих частей преобразования / преобразования XML в вашей структуре (т.е. XML in → XML out), возможно, вы могли бы позволить различным реализациям выполнять одни и те же задачи; не только XSLT, но и XQuery, Java (SAX + DOM), что угодно ...

Такой дизайн может даже оказаться полезным, если вы когда-нибудь решите отказаться от «дьявольского формата» и принять что-то еще; -)

РЕДАКТИРОВАТЬ : В сторону, но знаете ли вы о XProc ?

XSLT - это набор правил для преобразования дерева в другое дерево. Чтобы использовать его эффективно, вы должны думать об этом именно так.

Некоторые преимущества XSLT для меня:

1. Каждый кодировщик HTML, на который я могу положиться, может писать преобразования XSLT (я легко могу передать кодирование HTML на аутсорсинг), но немногие из них могут легко справиться с ASP. .Net элементы управления, шаблоны Mako, шаблоны Django, JSP, Smarty и другие движки одновременно.
2. При правильном использовании XSLT самодостаточен. Я могу предоставить кодировщику HTML входной XML, обсудить процессор XSLT и разработать преобразования XSLT отдельно от самого приложения.
3. XSLT-среда изолирована, HTML-кодировщик почти не может самостоятельно открыть брешь в безопасности.
4. XSLT не привязан к XML: вы можете написать свой собственный адаптер для доставки данных в XSLT и зарегистрировать собственный обработчик вывода. Однако это не вариант для решений, основанных на libxslt (php, python).

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

UPD : Некоторые из моих лучших практик:

Главное, как я уже сказал, - это разделять XSLT-преобразование. Для преобразования должно быть достаточно libxslt + exslt, msxsl + собственных расширений и т. Д.Если в XSLT отсутствуют некоторые мощные инструменты, я предпочитаю делать это в вызывающем коде и переходить к преобразованию во входном дереве.

Приложение должно построить XML (или дерево) предсказуемой (документированной) структуры. Для каждой интересующей меня страницы:

1. я генерирую XML (или пишу его вручную, если его еще не легко получить);
2. подготавливаю итоговый HTML, который я собираюсь получить в виде отдельного статического файла;
3. ] определяют преобразование XSLT (на нескольких страницах это может быть одно и то же).

Затем я помещаю все в VCS и создаю командный файл, чтобы применить к каждому XML соответствующий XSL, чтобы результат перезаписал статические файлы HTML.

Теперь при запуске svn diff html-folder (или аналогичном) мне будет показано, нарушило ли какое-либо преобразование HTML и где именно. Я вношу изменения в XSL и снова запускаю пакет. Как только HTML останется прежним, я совершаю коммит.

Каждое изменение в структуре XML-документа должно приводить к обновлению соответствующих XML и XSLT, чтобы HTML оставался прежним. Каждое запрошенное изменение в HTML должно приводить к соответствующему изменению в XSLT. HTML-кодер может работать изолированно, и я вижу, что что-то пошло не так.

Страницы в приложении, где я использую XSLT, обычно принимают параметр GET, например showinput = 1, чтобы вернуть пустое дерево ввода без примененного преобразования, чтобы я мог сохранить его и добавить в VCS в качестве другого особого случая.

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