Написание эффективного XSLT - PullRequest
13 голосов
/ 12 апреля 2009

Какие принципы и закономерности используются при написании эффективного XSLT?

Когда я говорю «эффективный», я имею в виду, что это

  1. Хорошо структурированный и читаемый
  2. Простой, лаконичный
  3. Эффективный (т.е. имеет хорошую производительность)

Короче говоря, я ищу лучшие практики для XSLT.

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

Ответы [ 5 ]

10 голосов
/ 12 апреля 2009

I. Элегантный код XSLT


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

Примеры см. в этой статье в FXSL 2.0 - библиотека функционального программирования для XSLT 2.0.

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

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

Вот небольшой пример .

Это выражение XPath 2.0 определяет" Максимум Главный фактор натурального числа ":

if(f:isPrime($pNum))
  then $pNum
  else
    for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
        $vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
        $vDiv2 in $pNum idiv $vDiv1
      return
        max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))

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

Как мы используем это для фактического вычисления Максимального простого множителя в XSLT? Мы просто обернем определение выше в <xsl:function> и ... получим результат!

 <xsl:function name="f:maxPrimeFactor" as="xs:integer">
  <xsl:param name="pNum" as="xs:integer"/>

  <xsl:sequence select=
   "if(f:isPrime($pNum))
      then $pNum
      else
        for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
            $vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
            $vDiv2 in $pNum idiv $vDiv1
          return
            max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))
   "/>
 </xsl:function>

Затем можно вычислить MPF для любого натурального числа , например:

f:maxPrimeFactor(600851475143) = 6857

Что касается эффективности, ну, это преобразование занимает всего 0,109 сек .

Другие примеры элегантного и эффективного кода XSLT :

II. Некоторые правила


Вот некоторые правила написания «качественного XSLT-кода», взятые из блога Мукула Ганди .

Их можно проверить / применить с помощью инструмента , разработанного Mukul :

  1. DontUseDoubleSlashOperatorNearRoot: Избегайте использования оператора // около корня большого дерева.

  2. DontUseDoubleSlashOperator: Избегайте использования оператора // в выражениях XPath.

  3. SettingValueOfVariableIncorrectly: присваивать значение переменной с использованием синтаксиса select при назначении строкового значения.

  4. EmptyContentInInstructions: Не используйте пустой контент для таких инструкций, как 'xsl: for-each' 'xsl: if' 'xsl: when' и т. Д.

  5. DontUseNodeSetExtension: Не использовать функцию расширения набора узлов при использовании XSLT 2.0.

  6. RedundantNamespaceDeclarations: В элементе xsl: stylesheet есть избыточные объявления пространства имен.

  7. UnusedFunction: функции таблицы стилей не используются.

  8. UnusedNamedTemplate: именованные шаблоны в таблице стилей не используются.

  9. UnusedVariable: переменная не используется в таблице стилей.

  10. UnusedFunctionTemplateParameter: параметр функции или шаблона не используется в теле функции / шаблона.

  11. TooManySmallTemplates: слишком много шаблонов с низким уровнем детализации в таблице стилей (10 или более).

  12. MonolithicDesign: Использование одного шаблона / функции в таблице стилей. Вы можете модулировать код.

  13. OutputMethodXml: использование метода вывода «xml» при генерации кода HTML.

  14. NotUsingSchemaTypes: таблица стилей не использует встроенные типы схем (xs: string и т. Д.) При работе в режиме XSLT 2.0.

  15. UsingNameOrLocalNameFunction: использование функции name (), когда возможно использование local-name () (и наоборот).

  16. FunctionTemplateComplexity: Размер / сложность функции или шаблона высоки. Необходим рефакторинг кода.

  17. NullOutputFromStylesheet: таблица стилей не генерирует никакого полезного вывода. Пожалуйста, ознакомьтесь с логикой таблицы стилей.

  18. UsingNamespaceAxis: использование устаревшей оси пространства имен при работе в режиме XSLT 2.0.

  19. CanUseAbbreviatedAxisSpecifier: Использование спецификаторов длинной оси, таких как child ::, attribute :: или parent :: node ().

  20. UsingDisableOutputEscaping: для атрибута disable-output-escaping установлено значение 'yes'. Пожалуйста, посмотрите на логику таблицы стилей.

  21. NotCreatingElementCorrectly: Создание узла элемента с использованием инструкции xsl: element, когда это было возможно напрямую.

  22. AreYouConfusingVariableAndNode: Возможно, вы путаете ссылку на переменную со ссылкой на узел. (предоставлено Аленом Бенедетти)

  23. IncorrectUseOfBooleanConstants: неправильно использовать логические константы как «true» или «false». (предоставлено Тони Лавинио)

  24. ShortNames: использование имени одного символа для переменной / функции / шаблона. Используйте значимые имена для этих функций.

  25. NameStartsWithNumeric: имя переменной / функции / шаблона начинается с цифры

8 голосов
/ 12 апреля 2009

Лучшая практика 1 : используйте шаблоны вместо всякий раз, когда можете (что составляет 99% случаев)

(могу ли я добавить ОБСЛУЖИВАНИЕ в качестве дополнительного ингредиента в лучшие практики, даже самый важный)

Для понимания xsl вам действительно нужно немного потренироваться.
Не понимая, что такое делает очень относительный, конечно.

Для XSLT это не имеет смысла, так как конструкция xsl: for-each имеет тенденцию быть

  • более читабельно

для новичка, но на самом деле

  • менее структурированный,
  • менее просто,
  • менее лаконично и
  • намного менее ремонтопригоден

чем шаблоны, и только

  • одинаково читаемый (в лучшем случае !!) для так. с минимальным опытом работы с шаблонами.

НИКОГДА, НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЭЛЕМЕНТ !

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

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

Либо вы это знаете, либо вы должны: и почти всегда путь Если вы XSL-IN, и вы не полностью понимаю эти теги, прекрати свою работу сейчас, изучи их, получи ага-эрлебнис, и продолжай свою работу как возрожденный (wo) человек.

5 голосов
/ 16 апреля 2009

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

Некоторые вещи, которые я видел, приводят к неэффективному XSLT:

  1. Злоупотребление for-each. Все это сказали; Я говорю это снова. Я считаю, что for-each часто является признаком того, что разработчик пытается использовать традиционные методы программирования на декларативном языке.

  2. Недостаточное использование XPath. Множество плохих XSLT, которые я видел, существует только потому, что разработчик не понимает предикаты, спецификаторы осей, position() и current(), и поэтому он реализована логика с использованием конструкций XSLT.

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

  4. Недостаточное использование предварительной обработки. Если, например, XML-документ содержит данные, которые необходимо проанализировать с помощью манипуляции строк XSLT, часто гораздо проще выполнить весь анализ вне XSLT. и либо добавьте проанализированные результаты в XML, либо передайте проанализированные результаты в качестве аргумента преобразования. Я видел удивительно не поддерживаемый XSLT, реализующий бизнес-логику, который было бы тривиально реализовать в C # или Python.

Самая большая проблема, с которой я сталкиваюсь в своем собственном мире XSLT (у меня есть несколько 3000 преобразований строк, которые я поддерживаю), это мертвый код. Я уверен, что в моих преобразованиях есть шаблоны, которые никогда не будут использоваться снова, потому что условия, для которых они проверяются, больше никогда не возникнут. Невозможно программно определить, является ли что-то вроде <xsl:template match="SomeField[contains(., "some value")]> живым или мертвым, потому что оно зависит от того, что метаданные не могут вам сказать.

4 голосов
/ 12 апреля 2009

Проблемы с файлами

1. Множество маленьких файлов лучше, чем несколько больших.

Разделите ваш hamburger.xsl на i-bread.xsl и i-beef.xsl.

2. Префикс включенных / импортированных файлов с помощью «i -».

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

3. Никогда не включайте / не импортируйте файл без префикса.

Если вы хотите сделать cheeseburger.xsl, не включайте hamburger.xsl. Вместо этого включите i-bread.xsl, i-beef.xsl и недавно созданный i-cheese.xsl.

1 голос
/ 12 апреля 2009

Для удобства чтения я использую тег xsl:template. Это очень лаконично и просто в использовании. Просто передать параметры в шаблон. Эта техника называется инкапсуляцией и является одной из основ хорошего программирования.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...