XML | XML-Schema | XPath | XSL-T | XSL-FO | XQuery | XProc | SVG |
XSL-T / Die XSLT - Struktur / xsl:evaluate
![]() |
![]() |
➪ xsl:evaluate bietet die Möglichkeit, zur Laufzeit generierte XPath-Statements auszuführen.
Siehe evaluate
Was ursprünglich nur unter XSLT 1.0/XPath 1.0 prozessorabhängig möglich war, dann unter XSLT 2.0 und XPath 2.0 aus Sicherheitsbedenken wieder abgeschafft wurde, findet sich in XSLT 3.0/XPath 3.0 nunmehr als Standard wieder.
<xsl:template name="evaluatedemo">
<xsl:param name="myxpath" as="xs:string" />
<xsl:variable name="mysequence">
<xsl:evaluate
xpath="$myxpath"
as="xs:string+"
context-item="." />
</xsl:variable>
<erg>
<xsl:for-each select="$mysequence">
<xsl:value-of select="." />
</xsl:for-each>
</erg>
</xsl:template>
Aufrufbar wird dieses "Meisterwerk" durch die automatische Generierung des XPath-Statements "/Orte/Ort[position() < 3]/name" durch die concat-Funktion und dessen Parameter-Übergabe an das ausführende Template.
<xsl:call-template name="evaluatedemo">
<xsl:with-param name="myxpath"
select="concat('/Orte/Ort', '[position() < 3]','/name')"/>
</xsl:call-template>
Das Ergebnis des Aufrufes sehen Sie hier:
<erg>Neustadt Darmstadt</erg>
Diese Konstruktion mag sinnvoll sein bei der Auslagerung der Logik in zahlreiche (Hunderte, Tausende!) Templates etc., die durch eine Haupt-Anwendung gestartet werden oder sich gegenseitig aufrufen. Meine Begeisterung hält sich in Grenzen, weil dieser Ansatz zwar die Flexibilität erhöht, ein kurzfristiges Maintenance jedoch erschwert. Um herauszufinden, welches XPath-Statement jeweils bei einem konkreten Template zum Einsatz kommt, kann ein sehr hoher Rechercheaufwand erforderlich sein.
Aus diesem Grunde sehe ich einen sinnvollen Einsatz von xsl:evaluate nur dann, wenn aufgrund schwach oder mäßig strukturierter XML-Dokumente (mixed content) eine erhöhte Flexibilität notwendig ist. Bei stark strukturierten oder gar scharf Schema-validierten Dokumenten könnte der Einsatz eine kurzfristige Wartbarkeit der Implementierung gefährden.
In XSL 1.0 unterstützt zumindest ein XSL-Prozessor das Konzept generischer Template-Aufrufe. Sehen Sie sich den folgenden Code an. Sie finden ein xsl:template name="TUWAS", das an anderer Stelle durch <xsl:call-template name="TUWAS"/> aufgerufen werden kann.
Nun wird ein Parameter vtemplatename definiert, der auch zur Laufzeit übergeben werden kann. Darin wird der Templatename TUWAS übergeben. Eine entsprechende Variable, die durch irgendeine Entscheidungslogik zu demselben Inhalt führt, hätte denselben Effekt. Nun wird das Kommando <xsl:call-template name='{$vtemplatename}' saxon:allow-avt='yes'/> aufgerufen, das den Namen des Template (TUWAS) erst zur Laufzeit erfährt und ausführt.
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:saxon="http://icl.com/saxon"
exclude-result-prefixes="saxon">
<xsl:param
name="vtemplatename">TUWAS</xsl:param>
<xsl:template name="TUWAS">
<p>Hallo aus TUWAS</p>
</xsl:template>
<xsl:template match="/">
<xsl:call-template
name="{$vtemplatename}"
saxon:allow-avt="yes"/>
</xsl:template>
</xsl:stylesheet>
Der Aufruf funktioniert in XSL 1.0 mit dem Saxon-Prozessor 6.5, für den die sogenannten saxon-functions als zusätzliche Features zur Verfügung stehen, die über den Namespace xmlns:saxon='http://icl.com/saxon' eingebunden werden können.
wg / 24. September 2020
Fragen? Anmerkungen? Tipps?
Bitte nehmen Sie Kontakt zu mir auf.
V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn
☎ 0151. 750 360 61 * eMail: info10@wilfried-grupe.de