[xml] Стоит ли XSLT?



14 Answers

Столько негатива!

Я использую XSLT в течение нескольких лет и искренне люблю его. Главное, что вы должны понять, это то, что это не язык программирования, это язык шаблонов (и в этом отношении я считаю его неописуемо превосходящим asp.net / spit).

XML - это фактический формат данных веб-разработки сегодня, будь то файлы конфигурации, исходные данные или репрезентация памяти. XSLT и XPath предоставляют вам чрезвычайно мощный и очень эффективный способ преобразования этих данных в любой выходной формат, который вам может понравиться, мгновенно предоставляя вам этот MVC-аспект разделения презентации на данные.

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

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

Случай использования в реальном мире: я просто написал приложение, которое обрабатывает XML-документы в памяти во всей системе и преобразуется в JSON, HTML или XML по просьбе конечного пользователя. У меня был случайный запрос предоставить данные Excel. Бывший коллега сделал что-то подобное программно, но ему нужен модуль из нескольких файлов классов и что на сервере установлен MS Office! Оказывается, в Excel есть XSD: новая функциональность с минимальным эффектом базового кода за 3 часа.

Лично я считаю, что это одна из самых чистых вещей, с которыми я столкнулся в своей карьере, и я считаю, что все очевидные проблемы (отладка, манипуляции с строками, структуры программирования) сводятся к некорректному пониманию инструмента.

Очевидно, я твердо верю, что это «стоит того».

Question

Некоторое время назад я начал проект, где я разработал XML-схему html-esque, чтобы авторы могли писать свой контент (учебный материал курса) в упрощенном формате, который затем был бы преобразован в HTML через XSLT. Я некоторое время играл с ним (боролся) и получил его на очень базовом уровне, но потом был слишком раздражен ограничениями, с которыми я сталкивался (что вполне могло быть ограничением моих знаний), и когда я читал блог, предлагающий канаву XSLT и просто напишите свой собственный XML-to-whatever парсер на выбранном вами языке, я с готовностью подскочил на него, и это получилось блестяще.

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

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




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

Возможно, вам стоит взглянуть на некоторые другие доступные языки разметки. Я считаю, что Джефф сделал статью об этой самой теме, касающейся переполнения стека.

Является ли HTML гуманным языком разметки?

Я бы посмотрел, что он написал. Вероятно, вы можете найти программный пакет, который делает то, что вы хотите «из коробки», или, по крайней мере, очень близко, вместо того, чтобы писать свои собственные вещи с нуля.




Мне нравится использовать XSLT только для изменения древовидной структуры XML-документов. Я считаю громоздким сделать что-либо, связанное с обработкой текста, и отменить его на собственный скрипт, который я могу выполнить до или после применения XSLT в XML-документе.

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




Я по-прежнему считаю, что XSLT может быть полезен, но это уродливый язык и может привести к ужасному нечитаемому, неудержимому беспорядку. Отчасти потому, что XML недостаточно читабельен для того, чтобы составлять «язык», а отчасти потому, что XSLT где-то застрял между декларативными и процедурными. Сказав это, и я думаю, что сравнение может быть проведено с помощью регулярных выражений, оно использует его, когда дело касается простых четко определенных проблем.

Использование альтернативного подхода и анализ XML в коде могут быть одинаково неприятными, и вы действительно хотите использовать какую-либо технологию XML-маршаллинга / привязки (например, JiBX в Java), которая преобразует ваш XML прямо в объект.




Я использую XSLT (из-за отсутствия лучшей альтернативы), но не для презентации, просто для преобразования:

  1. Я пишу короткие преобразования XSLT, чтобы делать массовые изменения в наших файлах maven pom.xml.

  2. Я написал конвейер преобразований для создания XML-схем из XMI (UML Diagram). Он работал некоторое время, но он, наконец, стал слишком сложным, и нам пришлось вытащить его за сарай.

  3. Я использовал преобразования для реорганизации XML-схем.

  4. Я работал над некоторыми ограничениями в XSLT, используя его для генерации XSLT для выполнения реальной работы. (Когда-либо пытались написать XSLT, который производит вывод с использованием пространств имен, которые неизвестны до выполнения?)

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

Тем не менее, я изучаю использование Clojure (lisp) для выполнения преобразований XML, но я еще недостаточно далеко, чтобы узнать, принесет ли мне этот подход.




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

Возможно, вы просто хотите предложить своим авторам простой интерфейс Wiki или Markdown. Для этого есть библиотеки, и если XSLT не работает для вас, возможно, XML тоже не работает для них.




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




Раньше я думал, что XSLT - отличная идея. Я имею в виду, что это отличная идея.

Там, где это не удается, это исполнение.

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

Хорошо, вы могли бы «использовать» его - я думаю, что это отчасти было связано с его дизайном, но это вторая неудача: все инструменты XSLT на рынке - это просто ... дерьмо!




Мы широко используем XSLT для таких вещей, как документация, и сделаем некоторые сложные параметры конфигурации доступными для пользователя.

Для документации мы используем много DocBook, который представляет собой формат на основе XML. Это позволяет нам хранить и управлять нашей документацией со всем исходным кодом, так как файлы являются простым текстом. С XSLT мы можем легко создавать собственные форматы документации, позволяя нам как автогенерировать контент в общем виде, так и делать контент более читаемым. Например, когда мы публикуем заметки о выпуске, мы можем создать XML, который выглядит примерно так:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

И затем, используя XSLT (который преобразует вышеуказанное в DocBook), мы получаем замечательные примечания к выпуску (обычно PDF или HTML), где идентификаторы ошибок автоматически связаны с нашим трекером ошибок, ошибки группируются по компонентам, а формат всего абсолютно согласован , И вышеупомянутый XML может быть сгенерирован автоматически, запросив наш трекер ошибок для того, что изменилось между версиями.

Другое место, где мы нашли XSLT полезным, действительно находится в нашем основном продукте. Иногда при взаимодействии с сторонними системами нам нужно как-то обрабатывать данные на сложной HTML-странице. Анализ HTML является уродливым, поэтому мы передаем данные через нечто вроде TagSoup (который генерирует надлежащие события SAX XML, по сути, позволяя нам иметь дело с HTML, как если бы он был правильно написан XML), а затем мы можем запустить некоторый XSLT против него, чтобы включить данных в «известный стабильный» формат, с которым мы можем работать. Разделив это преобразование на XSLT-файл, это означает, что если и когда формат HTML изменяется, само приложение не нуждается в обновлении, вместо этого конечный пользователь может просто отредактировать сам файл XSLT, или мы можем отправить по электронной почте им обновлен XSLT-файл без всей системы, нуждающейся в обновлении.

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




Я помню всю шумиху вокруг XSLT, когда стандарт был недавно выпущен. Все волнение вокруг возможности создания всего HTML-интерфейса с «простым» преобразованием.

Посмотрим правде в глаза, это трудно использовать, почти невозможно отлаживать, часто невыносимо медленно. Конечный результат почти всегда причудливый и менее идеальный.

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




Я поддерживаю систему онлайн-документации для своей компании. Авторы создают документацию в SGML (язык, подобный xml). SGML затем объединяется с XSLT и преобразуется в HTML.

Это позволяет нам легко вносить изменения в макет документации без какого-либо кодирования. Это просто вопрос об изменении XSLT.

Это хорошо работает для нас. В нашем случае это документ только для чтения. Пользователь не взаимодействует с документацией.

Кроме того, с помощью XSLT вы работаете ближе к своей проблемной области (HTML). Я всегда считаю, что это хорошая идея.

Наконец, если ваша текущая система РАБОТАЕТ, оставьте ее в покое. Я бы никогда не предложил уничтожить существующий код. Если бы я начинал с нуля, я бы использовал XSLT, но в вашем случае я бы использовал то, что у вас есть.




Раньше я использовал XSLT. Группа из 6 файлов .xslt (реорганизована из одного большого) составляла около 2750 строк, прежде чем я переписал ее на C #. В настоящее время код C # содержит 4000 строк, содержащих много логики; Я даже не хочу думать о том, что было бы написано в XSLT.

То, что я сдался, - это когда я понял, что XPATH 2.0 существенно не мешает моему прогрессу.




Да, я использую это много. Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких HTML-файлов polyglot (X) (представляющих одни и те же данные по-разному), RSS-фида, фида Atom, файла дескриптора RDF и фрагмента карты сайта ,

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




Я нашел XSLT довольно сложно работать.

У меня был опыт работы над системой, несколько подобной той, которую вы описываете. Моя компания отметила, что данные, которые мы возвращали из «среднего уровня», были в XML и что страницы должны отображаться в HTML, что также может быть XHTML, и они слышали, что XSL является стандартом для преобразования между XML форматы. Таким образом, «архитекторы» (под которыми я имею в виду людей, которые думают о глубоких дизайнерских мыслях, но, по-видимому, никогда не кодируют), решили, что наш передний уровень будет реализован путем написания сценариев XSLT, которые преобразуют данные в XHTML для отображения.

Выбор оказался катастрофическим. XSLT, оказывается, это боль, чтобы писать. И поэтому все наши страницы трудно писать и поддерживать. Мы бы намного лучше использовали JSP (это было на Java) или какой-то подобный подход, который использовал один вид разметки (угловые скобки) для формата вывода (HTML) и другой вид разметки (например, <% ... %>) для метаданных. Самая запутанная вещь в XSLT заключается в том, что она написана в XML, и она переводится с XML на XML ... довольно сложно держать все 3 разных XML-документа прямо в уме.

Ваша ситуация немного отличается: вместо написания каждой страницы в XSLT, как и я, вам нужно всего лишь написать один бит кода в XSLT (код для преобразования из шаблонов для отображения). Но похоже, что вы столкнулись с теми же трудностями, что и я. Я бы сказал, что попытка интерпретировать простой XML-язык DSL (специфичный для домена язык), как вы делаете, НЕ является одной из сильных сторон XSLT. (Хотя он МОЖЕТ выполнить эту работу ... ведь это Тьюринг завершен!)

Однако, если то, что у вас было, было проще: у вас есть данные в одном формате XML и вы хотите сделать для него простые изменения - не полное описание DSL-страниц, а некоторые простые простые изменения, тогда XSLT - отличный инструмент для этой цели. Это декларативный (не процедурный) характер на самом деле является преимуществом для этой цели.

- Майкл Чермсайд




Я использую XSLT широко, для пользовательского внешнего интерфейса MVC. Модель «сериализована» в xml (не через xml serializaiton), а затем преобразуется в html через xslt. Преимущество над ASP.NET заключается в естественной интеграции с XPath и более строгих требованиях корректности (гораздо проще рассуждать о структуре документа в xslt, чем в большинстве других языков).

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

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




Related



Tags

xml   xslt