XSL-T / Die XSLT - Struktur / xsl:for-each select / xsl:for-each vs. xsl:apply-templates

xsl:for-each vs. xsl:apply-templates

➪ Grundsätzlich gibt es verschiedene Wege, XML-Dokumente mithilfe von XSL abzuarbeiten. Mit Blick auf eine effiziente Wartbarkeit des Programmcodes empfiehlt sich, die Entscheidung wesentlich von der Struktur des XML-Input Dokuments abhängig zu machen. xsl:for-each, xsl:call-template und xsl:apply-templates bieten jeweils Vor- und Nachteile für unterschiedliche Aufgabenstellungen, mit unterschiedlichen Konsequenzen für den Maintenance-Aufwand.

Siehe

• xsl:for-each
• xsl:apply-templates
• xsl:apply-templates bei Referenzierungen

• Stellen die XML-Dokumente im Kern stark strukturierte Datensätze dar, so empfiehlt sich die konsequente Arbeit mit xsl:for-each. Das erleichtert in der Regel auch die Wartbarkeit. Bei internen Referenzierungen kann die Arbeit mit Variablen sinnvoll sein.
• Bei XML-Dokumenten mit gemischten Strukturen (mixed Content) (sowohl Text- als auch Elementknoten, deren Abfolge nicht von vornherein festgelegt werden kann), aber auch bei verschachtelten Referenzierungen bietet der Aufruf von xsl:template match in Verbindung mit xsl:apply-templates die notwendige hohe Flexibilität.
• Bei häufiger Verwendung identischer Codeteile (Redundanz) empfiehlt sich eine Auslagerung in separate xsl:template name bzw. xsl:function.

In der Praxis werden sämtliche Ansätze parallel verwendet. Auch bei stark strukturierten, datensatz#ähnlichen Dokumentstrukturen, bei denen xsl:for-each eindeutig die bessere Wahl wäre, kommen tief verschachtelte xsl:apply-templates zum Einsatz, die die Wartung keineswegs erleichtern. Und bei mixed content arbeitet sich mancher Developer mit xsl:for-each ab.

Die drei Ansätze treiben im unkontrollierten Mix mitunter erstaunliche Blüten. Die Anzahl der Templates/Functions, die sich gegenseitig aufrufen, gehen in die Tausende. In XSL 1.0 kommt es obendrein vor, dass die Auswahl der Code-Aufrufe nicht im Quelltext festgelegt ist, sondern erst zur Laufzeit erfolgt (Beispiel: <xsl:call-template name="{$vaufgerufenestemplate}">). Diese Art late binding erfordert zeitaufwendige Recherchen über die interne Funktionsweise.

Die unkritische Verwendung von xsl:apply-templates zieht häufig eine schrittweise Auslagerung der Logik in diverse Templates nach sich, die sich gegenseitig aufrufen. Oft befinden sich die Teillogiken in anderen Dateien, die in die aktuelle Logik eingebunden werden müssen. Das Ergebnis ist häufig ein Spaghetti-Code, der mit fortschreitender Komplexität immer schwerer wartbar wird.

Mit zunehmenden gegenseitigen Abhängigkeiten der Subroutinen geht der Überblick verloren. Dadurch erhöht sich der Zeit- und Kostenaufwand an Wartung, Tests und Einarbeitung neuer Mitarbeiter. Der Aufwand steigt:

• wenn nicht direkt aus der Dokumentation oder aus dem Quelltext eines Templates erkennbar ist, wie es intern tickt.
• wenn die Suche nach dem passenden Code langwierig und zeitraubend wird.
• wenn der Zeitaufwand, den Programmablauf detailliert nachzuvollziehen und ggf. zu verändern, unverhältnismäßig hoch wird.
• wenn die gegenseitigen Abhängigkeiten schlecht oder gar nicht dokumentiert sind.
• wenn jene Programmierer, die die gegenseitigen Abhängigkeiten ursprünglich implementiert oder letztmalig gewartet haben, nicht mehr im Team sind und sich niemand für die kritische Pflege des bestehendes Codes verantwortlich fühlt.
• wenn mögliche Fehler in einem ausgelagerten Programmteil Kettenreaktionen hervorrufen.
• wenn aktuelle Standardlösungen oder zugekaufte externe Programme sich in das bestehende System nicht oder nur sehr eingeschränkt integrieren lassen (z.B. Upgrade auf XSLT 2.0 oder XSLT 3.0).
• wenn die XML-Dokumentstruktur (Input) sich aus irgendeinem Grund ändert und die XSL-Stylesheets aktualisiert werden müssen, um einen Informationsverlust zu vermeiden.

wg / 24. September 2020

---

---

Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.

---