Почему стоит выбрать XSL-преобразование?

Question

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

Меня будут интересовать аргументы за или против XSL-подхода. Я понимаю, что в тех случаях, когда вам необходимо поддерживать много разных макетов, XSL-решение имеет много преимуществ, но почему вы выбираете его в тех случаях, когда вам нужно поддерживать только один целевой макет?

Редактировать: Мы говорим о Java здесь.

Answer 1

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

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

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

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

Answer 2

Я создал пользовательский интерфейс на основе XML / XSLT для корпоративного продукта около 5 лет назад. Мы все еще используем его, и теперь я могу оглянуться на свой опыт и увидеть много плюсов и минусов:

Плюсы:

• XSL - это мощный декларативный язык, полезный и увлекательный для опытных разработчиков, и преобразования могут сделать довольно удивительные вещи в нескольких строках кода
• XSL предназначен для использования с XML, поэтому, если ваши данные уже являются XML, это имеет большой смысл
• Разделение задач (рендеринг и данные) лучше, чем многие языки шаблонов
• Рендеринг на основе XSL может быть легко "разделен на подклассы". Под этим я подразумеваю: допустим, у вас есть класс данных A со связанным шаблоном A.xslt. Для класса B, производного от A, вы можете легко создать B.xslt только с небольшими отличиями и включить A.xslt для унаследованных поведений. Это делает его менее подверженным взлому из-за изменений в A.xslt.
• Вышеуказанный пункт также дает вам возможность делать переопределения. Для класса A со связанным A.xslt мы можем легко переключить связанный шаблон на A-custom.xslt, который представляет собой несколько небольших изменений плюс наследование A.xslt. Мы можем сделать это на лету в поле, и опять же, преимущество в том, что A-custom.xslt - это всего несколько строк, а не полная измененная копия исходного A.xslt. Небольшая площадь означает, что он более вероятно будет работать с несколькими версиями A.xslt.
• В .NET 2.0 XSLT компилируется и становится очень быстрым. Там может быть похожая технология для Java. (Большинство языков шаблонов делают это и сейчас.)
• В .NET можно создать «Навигатор объектов XPath», который позволяет преобразовывать объекты данных без преобразования их в объект XML. Снова может быть похожая технология в Java
• XSLT хорошо разбирается в HTML и обрабатывает экранирование, проблемы с пробелами и т. Д.

Минусы:

• XSL является мощным декларативным языком, сбивающим с толку новых программистов - и меньше людей хорошо знают XSLT
• XSL многословен. XML также часто многословен.
• XSL-преобразования, вероятно, медленнее, чем "родные" шаблоны. Даже при компиляции в XSL все еще больше накладных расходов, чем в большинстве языков шаблонов
• Трудно передать параметры в XSL, вам нужно либо отправить их в соответствии с вашими данными (вынуждая создавать дополнительный XML), либо с помощью системных методов (которые могут также включать создание данных XML)
• Если у вас нет ObjectXPathNavigator или его эквивалента, вы будете подвергаться значительным накладным расходам при преобразовании объектов данных в XML для преобразования
• В зависимости от возможностей вашего преобразователя, вы также можете понести накладные расходы на буферизацию при преобразовании в строковый буфер и последующей отправке этой строки на устройство вывода
• Чем более продвинуто ваше использование XSLT, тем меньше вероятность того, что ваши инструменты поддержат вас (особенно когда вы начнете использовать встроенные или более быстрые способы передачи данных XML)

Я постараюсь обновить, как я думаю о других проблемах. Я думаю, что оглядываясь назад, мой вердикт будет придерживаться общего языка шаблонов. То, что когда-то было большими проблемами, когда я выбирал XML / XSLT, теперь решается с помощью более новых и более зрелых версий основных шаблонизаторов. Мы по-прежнему получаем большую выгоду от возможности наследовать файлы .xslt, что большинство движков шаблонов не очень хорошо выполняет. Но, в конце концов, ценность наличия множества разработчиков, предоставляющих примеры, намного выше (например, сравните ответы ASP.NET с ответами XSLT в StackOverflow.)

Надеюсь, это поможет!

Answer 3

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

Несколько мыслей перед выводом:

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

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

• XSLT также существует уже некоторое время, реализации являются зрелыми, я уверен, что это относится к долго работающим шаблонным двигателям (таким как Velocity), но более новые двигатели могут быть менее надежными.

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

• Поддержка инструментов, как правило, очень хорошая ... если у вас есть бюджет. XMLSpy и Stylus Studio оба были очень полезны для меня в прошлом.

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

• XSLT-преобразования могут быть медленными и занимать много памяти. У вас могут возникнуть проблемы, если у вас есть таблица стилей с большим вводом XML.

Мне нравится XSLT, но нужно ли вам его использовать или нет, зависит от нескольких моментов:

Вы привержены XSLT? У вас есть серьезный внутренний опыт в XSLT? Вы готовы получить немного?

Ваши данные в XML? Имеет ли это смысл в XML? У вас есть кто-то, кто любит ваши данные достаточно, чтобы убедиться, что они хорошо структурированы и всегда есть подходящая схема?

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

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

Answer 4

Путь XSL будет вашим будущим приложением. Это означает, что если вы в будущем решите добавить больше шаблонов с различными макетами, вы сможете воспользоваться этими преимуществами. В моем текущем проекте мы сохраняем используемый XML (в XMLType или CLOB) и позволяем другим приложениям получать доступ к данным и шаблонам XSL для генерации документов через веб-сервис. Это была запоздалая мысль об оригинальном дизайне, который было очень легко реализовать из-за нашего решения использовать XML / XSL.

Answer 5

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

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

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

Answer 6

XSLT обладает тем преимуществом, что может также выводить данные в других типах документов (например, в формате pdf), и в настоящее время очень вероятно вывод в формате PDF. XML / XSLT также отделяет данные от представления.

Answer 7

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

Answer 8

http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/

Answer 9

Будьте проще. Это принцип, который можно ценить все больше и больше.

Velocity или Freemarker невероятно гибки и универсальны. Ваша кодовая база будет понятна, легко понятна и будет работать намного (намного) быстрее, чем X чудовищ.

Answer 10

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

XPATH и XSLT имеют высокую кривую обучения, и функциональное программирование может быть сложным, чтобы обнять вас. Со временем это может быть неправильным выбором.

Для внешней работы JSON имеет меньшую полезную нагрузку и легко поддерживается jQuery и другими библиотеками Javascript. Возможно, вы захотите рассматривать JSON в качестве протокола данных, поскольку библиотека jQuery гораздо более доступна для разработчиков, а время для продуктивности с каркасом намного меньше, чем с XSLT, встроенным Javascript в тегах, ужасным синтаксисом и всеми другими мелочами, которые идут с XML / XPATH / XSLT на внешнем интерфейсе.