XSLT-Templates nutzen: Wiederverwendbare Bausteine für dein Wetter-Dashboard

Im ersten Teil meiner Beitragsreihe habe ich gezeigt, wie man Wetterdaten mithilfe von XSLT und Apache FOP in ein ansprechendes PNG-Bild umwandelt.
Dabei ging es um den grundlegenden Aufbau des Projekts – von der Datenabfrage über das Shell-Skript bis zur Anzeige auf dem ePaper-Display.

XSLT-Templates nutzen: Wiederverwendbare Bausteine für dein Wetter-Dashboard

Dieses Video auf YouTube ansehen.

In diesem zweiten Teil widmen wir uns nun dem Herzstück der Darstellung: dem XSL-Template.
Denn je umfangreicher das Layout wird, desto wichtiger wird saubere und strukturierte XSLT-Arbeit.
Mit wiederverwendbaren Templates lässt sich der Code nicht nur deutlich vereinfachen, sondern auch viel Schreibarbeit sparen – bei besserer Lesbarkeit und Wartbarkeit.

Ich zeige dir anhand konkreter Beispiele aus meinem Projekt:

• wie du sich wiederholende Codeblöcke auslagerst,
• wie du Parameter verwendest, um flexible Inhalte einzubinden,
• und wie dein FOP-Dokument dadurch deutlich übersichtlicher wird.

Inhaltsverzeichnis

• GitHub-Ordner templating mit Beispieldateien
• Warum sich XSLT-Templates lohnen
• XSLT-Templates für Wetterwerte: Praktischer Einsatz mit Parametern
  • Zugriff auf Parameter in XSLT: Unterschiede bei Text und Attributen
    • Innerhalb eines select-Ausdrucks:
    • Innerhalb eines Attributwerts:
  • Wichtiger Hinweis zur Parameterübergabe
• Templates auslagern – saubere Struktur & weniger Merge-Konflikte
  • Externe XSL-Dateien laden – Fehler und Lösung
    • Lösung
    • Danach

GitHub-Ordner templating mit Beispieldateien

Alle Ressourcen zu diesem zweiten Teil findest du im bestehenden GitHub-Repository unter dem neu hinzugefügten Ordner templating. Dort habe ich dir Beispiel-Dateien zur besseren Strukturierung mit XSL-Templates hinterlegt, inklusive der optimierten XSL-Datei sowie zugehöriger Wetterdaten im XML-Format. Schau gerne rein – und wenn du Fragen hast oder Feedback geben möchtest, nutze die Kommentarfunktion oder schreib mir direkt!

Warum sich XSLT-Templates lohnen

Beim Arbeiten mit XSL-Dateien kann der Code schnell unübersichtlich und redundant werden – besonders, wenn ähnliche Blöcke an mehreren Stellen benötigt werden. Genau hier kommen XSLT-Templates ins Spiel. Sie ermöglichen es, wiederkehrende Strukturen auszulagern und gezielt über Parameter zu steuern.

Vorteile der Template-Nutzung:

• Kein doppelter Code: Gemeinsame Strukturen werden nur einmal geschrieben.
• Einfach erweiterbar: Änderungen wirken sich sofort auf alle Stellen aus, an denen das Template verwendet wird.
• Weniger Fehlerquellen: Anpassungen müssen nur an einer zentralen Stelle vorgenommen werden – das reduziert versehentliche Inkonsistenzen und spart Korrekturschleifen.

Mögliche Nachteile:

• Schlechte Lesbarkeit bei schlechter Namenswahl: Wenn Templates nicht klar benannt sind, wird das Wiederfinden schwieriger.
• Nicht immer flexibel: Wenn ein Template plötzlich nicht mehr an allen Stellen passt, muss es erweitert oder neu angelegt werden. Das erfordert manchmal zusätzliche Parameter oder eine Umstrukturierung.

Insgesamt überwiegen die Vorteile jedoch deutlich – vor allem in größeren Projekten oder bei sich ändernden Anforderungen.

XSLT-Templates für Wetterwerte: Praktischer Einsatz mit Parametern

In diesem Abschnitt zeige ich dir anhand eines praktischen Beispiels, wie man ein Template in XSL anlegt und verwendet. Ziel ist es, die Anzeige von Temperatur, Luftfeuchtigkeit und Luftdruck einheitlich und wartbar umzusetzen – ohne dreimal denselben Blockcode zu schreiben.

Die XML-Datei enthält sowohl die aktuellen Wetterdaten als auch Vorhersagen für die kommenden drei Tage. Diese Werte lassen sich durch einen Index gezielt ansprechen, z. B.:

<value date="2025-06-16T12:00:00Z">20.3</value> <!-- Index 1: aktuell -->
<value date="2025-06-17T12:00:00Z">23.8</value> <!-- Index 2: morgen -->

Statt nun dreimal die gleiche Formatierung für Temperatur, Luftfeuchtigkeit und Luftdruck zu wiederholen, wird ein zentrales Template definiert:

<xsl:template name="weatherValueBlock">
    <xsl:param name="label"/>
    <xsl:param name="value"/>
    <xsl:param name="unit"/>
    ...
</xsl:template>

Das Template kann anschließend beliebig oft aufgerufen werden – jeweils mit anderen Parametern. So bleibt dein XSL-Code übersichtlich und flexibel erweiterbar.

Zugriff auf Parameter in XSLT: Unterschiede bei Text und Attributen

Beim Arbeiten mit Templates in XSLT werden Parameter per <xsl:param> definiert und über <xsl:with-param> übergeben. Der Zugriff darauf hängt vom Kontext ab:

Innerhalb eines select-Ausdrucks:

Du kannst direkt mit einem Dollarzeichen ($) auf den Parameter zugreifen:

<xsl:value-of select="$unit"/>

Dieser Ausdruck gibt den Wert des Parameters unit als Textinhalt zurück.

Innerhalb eines Attributwerts:

Wenn du den Parameter innerhalb eines XML-Attributs nutzen möchtest (z. B. src bei einem Bild), muss der Ausdruck mit geschweiften Klammern {} umschlossen werden:

<fo:external-graphic src="url('../images/{$icon}')" content-width="30px"/>

Hier wird der Parameter icon direkt in den Attributwert eingefügt. Die geschweiften Klammern sorgen dafür, dass XSL den Ausdruck evaluiert und ersetzt, statt ihn als statischen Text zu behandeln.

Kurzform:

• Text oder select-Attribute → $parameterName
• Innerhalb von Attributwerten (z. B. src, href) → {$parameterName}

Dieser Unterschied ist wichtig, da es sonst schnell zu Fehlern wie einer leeren Bild-URL oder fehlenden Werten kommen kann.

Wichtiger Hinweis zur Parameterübergabe

Wenn du eine Zeichenkette (String) als Parameter übergibst, muss diese in einzelne Anführungszeichen eingeschlossen werden – sonst interpretiert XSLT den Wert als XPath-Ausdruck:

Richtig:

<xsl:call-template name="myTemplate">
  <xsl:with-param name="name" select="'Stefan'"/>
</xsl:call-template>

Falsch (führt zu Fehler oder leerem Wert):

<xsl:with-param name="name" select="Stefan"/>

Das wäre eine XPath-Abfrage nach einem Knoten namens Stefan, nicht der Text „Stefan“.

Templates auslagern – saubere Struktur & weniger Merge-Konflikte

Warum das hilfreich ist – gerade im Team:

Vorteil	Erklärung
Klarere Struktur	Jeder Themen­bereich (z. B. Werte-Blöcke, Vorschau, Footer) bekommt sein eigenes Stylesheet.
Paralleles Arbeiten	Mehrere Entwickler können gleichzeitig an unter­schiedlichen Dateien arbeiten, ohne sich gegenseitig zu blockieren.
Weniger Merge-Konflikte	Beim Zusammenführen in Git sind Konflikte meist auf einzelne Template-Dateien beschränkt statt auf eine riesige Monolith-Datei.
Gezielte Updates	Änderungen an einem Template betreffen nur die importierte Datei – die Haupt-XSL bleibt schlank und übersichtlich.

Praxis­beispiel

<!-- main.xsl -->
<xsl:import href="templates/values.xsl"/>
<xsl:import href="templates/forecast.xsl"/>
<xsl:import href="templates/footer.xsl"/>

So kann ein Kollege an values.xsl feilen, während du dich um forecast.xsl kümmerst – und der nächste git merge bleibt entspannt.

Externe XSL-Dateien laden – Fehler und Lösung

Beim Modularisieren des XSL-Codes über xsl:import oder xsl:include kann es bei der Transformation mit Apache FOP zu folgender Fehlermeldung kommen:

javax.xml.transform.TransformerConfigurationException: 
Could not read stylesheet target 'sample-content.xsl', 
because 'file' access is not allowed due to restriction set by the accessExternalStylesheet property.

Diese Meldung weist darauf hin, dass Apache FOP aus Sicherheitsgründen standardmäßig keine externen Stylesheets von der lokalen Festplatte lädt.

Lösung

Damit xsl:import und xsl:include korrekt funktionieren, musst du Apache FOP explizit erlauben, auf lokale Dateien zuzugreifen.

Öffne dazu die Datei fop (meist unter fop/fop) und finde die Zeile, in der fop_exec_command definiert ist (ca. Zeile 254). Ergänze dort den folgenden Java-Parameter:

-Djavax.xml.accessExternalStylesheet=file

Die komplette Zeile sieht dann z. B. so aus:

fop_exec_command="exec \"$JAVACMD\" -Djavax.xml.accessExternalStylesheet=file $LOGCHOICE $LOGLEVEL -classpath \"$LOCALCLASSPATH\" $FOP_OPTS org.apache.fop.cli.Main $fop_exec_args"

Danach

Speichern, ausführbar machen (falls nötig) und die Transformation erneut starten – nun können auch ausgelagerte XSL-Dateien korrekt eingebunden werden.