Алгоритм отображения XSLT - PullRequest
       16

Алгоритм отображения XSLT

2 голосов
/ 24 февраля 2009

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

Есть ли способ легко отобразить в удобочитаемом формате именно то, что делает гигантский XSLT? каждый возможный вход -> каждый возможный выход. Мы не можем создать всеобъемлющий входной документ, так как адаптер имеет разное поведение для разных входных данных (мы предполагаем, что потребуется 100+ входных документов, чтобы охватить все возможные выходные данные)

Любое предложение будет приветствоваться.

Ответы [ 4 ]

1 голос
/ 24 февраля 2009

Как правило, это невыполнимая задача - для любого языка программирования!

Это следует из неразрешимости проблемы остановки .

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

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

1 голос
/ 24 февраля 2009

Break it up - переместите операторы выполнения xsl в шаблоны xsl внутри документа. Делая это, вы добьетесь более разумного понимания документа сверху вниз.

И если он настолько невероятно гигантский, что мешает вам его понять, это звучит так, как будто у вас впереди ре-факторинговое решение: настолько ли важен этот документ, что нам нужно знать, что он делает (и понимать, как он работает - что требует некоторой переделки), или мы можем жить с этим как есть?

1 голос
/ 24 февраля 2009

Вы понимаете свои входные документы?

Если Да, пропустите следующее предложение, иначе Нет: -

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

Вы понимаете свои выходные документы?

Если Да, пропустите следующее предложение, иначе Нет: -

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

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

0 голосов
/ 24 февраля 2009

Это не поможет вам по всей вероятности. Но я поделюсь своим опытом.

Я относился к XSLT только вчера, когда у меня возникла та же проблема, пытаясь выяснить, что в спецификации XSLT говорится w.r.t. разбор. Чтобы помочь себе, я добавил пару функций (xsl: template's, чтобы быть педантичными) в исходный XSL. Затем я запустил его через браузер, и вот, у меня была четкая картина DFS.

Я создал следующее:

<xsl:template name="print">
<xsl:param name="message"/>
<xsl:param name="elem"/>
<div class="ArticleBody">
  <br/>
  <xsl:value-of select="$message"/>: <xsl:value-of select="$elem"/> ... <br/>
</div>

Шаблон print является рабочим, а пролог и эпилог просто вызывают print с пользовательскими строками.

И я помещаю изменения в исходный файл XSL из:

<xsl:template match="db:para">
 <xsl:apply-templates/>
</xsl:template>

до:

<xsl:template match="db:para">
 <xsl:call-template name="prologue">
   <xsl:with-param name="item" select="'para'"/>
 </xsl:call-template>
 <xsl:apply-templates/>
 <xsl:call-template name="epilogue">
  <xsl:with-param name="item" select="'para'"/>
 </xsl:call-template>

Теперь я получу вывод при обработке каждого узла:

start-processing: article ... 

и когда он завершится

end-processing: article ...

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

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