Die Grundlagen von XSL-Transformationen sind einfach: Ein oder mehr XSLT-Stylesheetes enthalten Anweisungen, die beschreiben, wie XML-Daten von einem Format in ein anderes zu transformieren sind. XSLT-Prozessoren übernehmen die eigentlichen Transformationen. Die Java API for XML Processing (JAXP) von Sun Microsystems bietet eine Standard-Java-Schnittstelle für verschiedene Prozessoren an. Nachfolgend sehen Sie Beispielcode, der eine XSL-Transformation mit Hilfe der JAXP-API durchführt:
- Bei jeder Möglichkeit zwischenspeichern
Die Durchführung von Transformationen mittels XSLT ist CPU- und Speicher-intensiv. Optimierungen in dieser Richtung sind also immer sinnvoll. Unterschiedliche Caching-Techniken bilden eine der besten Möglichkeiten, die Performance XSLT-gesteuerter Webanwendungen zu erhöhen.
Abbildung 1 veranschaulicht eine typische XSL-Transformation für eine Datenbank-gesteuerte Webanwendung:
Abbildung 1: Typische XSL-Transformation
Im Gegensatz zu dynamisch generiertem XML werden XSLT-Stylesheets generell in statischen Dateien abgelegt. Weil sich diese Dateien selten ändern, können sie mit Hilfe der javax.xml.transform.Templates-Schnittstelle von JAXP im Speicher "geparst" und zwischengespeichert werden. Das nachfolgende Codefragment zeigt, wie man das macht:
Source xsltSource = new StreamSource(xsltFile);
TransformerFactory transFact = TransformerFactory.newInstance();
Templates cachedXSLT = transFact.newTemplates(xsltSource);
Transformer trans = cachedXSLT.newTransformer();
Nachdem das XSLT-Stylesheet nun mit Hilfe der Templates-Schnittstelle im Speicher abgelegt wurde, kann es für viele verschiedene Transformationen wiederverwendet werden. Der wichtigste Punkt ist die Tatsache, daß damit ein wiederholtes Parsen des XSLT-Quellcodes in den Speicher vermieden wird. Man gibt XSLT-Prozessoren damit aber auch die Möglichkeit, die Transformationsanweisungen zu optimieren (in ähnlicher Weise wie Compiler Software optimieren).
Man könnte sich fragen, ob die XML-Daten ebenfalls im Speicher zwischengespeichert werden können. Bei hochgradig dynamischen oder personalisierten Anwendungen wird der XML-Code bei jedem Client-Request dynamisch generiert und ändert sich daher laufend. Bei dieser Art von Anwendungen ist das Caching nicht praktikabel. Bei vielen anderen Arten von Anwendungen ändern sich die XML-Daten hingegen nicht allzu häufig.
Wenn sich die XML-Daten nicht oft ändern, ist es sinnvoller, das Ergebnis der Transformation zwischenzuspeichern, nicht die XML-Daten. Das ist der einfachste Weg, ihn sollte man, wann immer möglich, wählen.
- Testen Sie vor dem Einsatz
Die klare Trennung von Daten, Programmierlogik und Darstellung ist ein Hauptgrund für die Verwendung von XML und XSLT bei der Entwicklung von Webanwendungen. Java-Code interagiert mit Backends für Datenquellen und erzeugt XML-Daten, XSLT-Stylesheets wandeln diese XML-Daten in XHTML (oder WML, oder was auch immer) um, und der Browser stellt das Ergebnis dar.
Ein einzigartiger (und manchmal übersehener) Vorteil dieser Architektur ist ihre Fähigkeit, automatisierte Tests von Teilsystemen zu unterstützen. Tools wie JUnit ermöglichen es Programmierern, Suites mit automatisierten Tests für Teilsysteme zu entwickeln. Diese Tests reduzieren das Risiko neuer Bugs bei der Einbettung neuer Features ganz erheblich. Betrachten Sie die Komponenten einer typischen Java+XML+XSLT-Website:
- Implementieren der Logik mittels Java. Weil der Java-Code nicht mit der Darstellungslogik vermischt ist, kann er wie jeder andere Java-Code getestet werden.
- Konvertierung von Anwendungsdaten nach XML. Dieser Schritt ist besonders einfach zu testen - erzeugen Sie einfach den XML-Code und validieren Sie ihn dann mit Hilfe eines DTD- oder eines XML-Schemas.
- Transformation der XML-Daten nach XHTML. Erneut kann der generierte XHTML-Code automatisch gegen eine der XHTML-DTDs validiert werden. Auch wenn das nicht sicherstellt, daß die Informationen korrekt sind, so stellt es doch sicher, daß der XHTML-Code wohlgeformt und gültig ist.
Im Gegensatz zu vielen anderen Webentwicklungstechniken verlangt keiner dieser Tests den Einsatz eines Webservers. Das macht es wesentlich einfacher, automatisierte Tests von Teilsystemen zu implementieren, die eine Schlüsselkomponente der Extreme Programming (XP)-Techniken sind.
- Halten Sie XSLT-Stylesheets einfach
Es gibt mindestens zwei Gründe, XSLT-Stylesheets einfach zu halten. Erstens ist XSLT keine reiche Programmiersprache wie Java. Während XSLT bei Transformationen gute Arbeit leistet, wird es kompliziert, wenn man versucht, zu viel der Anwendungslogik in Stylesheets unterzubringen. Aus diesem Grund ist es sinnvoll, die eigentliche Programmlogik so weit es geht in Java zu implementieren, bevor Sie Ihren XML-Code erzeugen. Dieser XML-Code sollte dann mit Hilfe von XSLT wesentlich einfacher zu transformieren sein.
Der zweite Grund, warum man Stylesheets einfach halten sollte, ist die Tatsache, daß die XSLT-Syntax schwer zu lesen ist. XML-Tags ermöglichen ein einfaches Parsen und programmtechnisches Manipulieren von XSLT, aber die vielen XML-Tags können Stylesheets sehr schwer lesbar machen. Es gibt eine Reihe von Dingen, die Programmierer tun können, um XSLT-Stylesheets lesbarer und pflegeleichter zu machen:
Verwenden Sie Editoren, die die Syntax hervorheben, wie Altovas XML Spy.
Fügen Sie auffällige Kommentarblöcke vor jedem XSLT-Template ein. Damit lockern Sie die Monotonie etwas auf, die sich einschleicht, wenn man es mit seitenweise '<'- und '>'-Zeichen zu tun hat.
Verwenden Sie Namenskonventionen für Top-Level-Variablen und Stylesheet-Parameter.
Lagern Sie gängige Funktionen in separate Stylesheets aus, die Sie dann mit <xsl:import> wiederverwenden können.
Verwenden Sie CSS mit XSLT
Dieser Tip geht mit dem vorigen Hand in Hand, da er die Komplexität von XSLT-Stylesheets stark verringern kann.
XSLT und CSS übernehmen unterschiedliche Aufgaben, die einander gegenseitig ergänzen. XSLT wandelt XML in andere Formate wie XHTML oder WML um, während CSS nur die Präsentation definiert. Die Zeilen sind manchmal etwas überladen, weil XSLT Style-Elemente als Teil des generierten XHTML-Codes erzeugen kann.
Statt eine Vielzahl von Schriftarten, Farben und weiterer Style-Elemente in XSLT-Stylesheets einzubetten, sollten Sie eigenständige CSS-Dateien entwickeln. Die XSL-Transformation erzeugt XHTML-Dateien, die einfach die separaten CSS-Dateien einbinden. Das macht den XHTML-Code kleiner, vereinfacht den XSLT-Code und ermöglicht Browsern ein schnelleres Herunterladen der Seiten.
Die gleiche Technik gilt auch für JavaScript-Code, der in eigenständigen Dateien untergebracht werden sollte, anstatt in die Transformationen eingebettet zu werden.
Vorsicht bei nicht umbrechenden Leerzeichen
Hinweis des Autors: Als Reaktion auf Kommentare von Lesern habe ich diesen Tip so umgeschrieben, daß er das wiedergibt, was ich jüngst über nicht umbrechende Leerzeichen gelernt habe. Dank an die Leser für das Feedback.
Ein nicht umbrechendes Leerzeichen ist ein nützliches Feature von XHTML, das Browser daran hindert, Zeilenumbrüche zwischen Wörtern einzufügen. Gleichzeitig ermöglicht es zwei oder mehr aufeinanderfolgende Leerzeichen. Browser fassen aufeinanderfolgende Leerzeichen (und andere Whitespace-Zeichen) üblicherweise zu einem Leerzeichen zusammen. Hier ein XHTML-Code, der ein nicht umbrechendes Leerzeichen enthält:
Aidan Burke
Wenn die Leute XHTML-basierte Webseiten entwickeln, fügen sie üblicherweise wie oben zu sehen " " in ihren Quellcode ein. Alle Browser sollten diese Zeichenfolge als nicht umbrechendes Leerzeichen interpretieren und die Seite entsprechend korrekt ausgeben. Wird nun XSLT zur Generierung des XHTML-Codes verwendet, müssen die Dinge anders gehandhabt werden.
XSLT-Stylesheets müssen aus sauberem XML-Code bestehen. Weil " " keines der fünf vordefinierten XML-Entities darstellt, kann es im Stylesheet nicht direkt aufgenommen werden. So funktioniert beispielsweise das folgende XSLT-Fragment nicht:
<!-- funktioniert nicht... -->
<xsl:text>Aidan Burke</xsl:text>
Das führt üblicherweise dazu, daß XSLT-Programmierer die Sache ein wenig abwandeln:
<xsl:text>Aidan Burke</xsl:text>
Wie sich zeigt, funktioniert das in nahezu allen Fällen. Ist "html" die vom Stylesheet definierte Ausgabemethode, wandeln Prozessoren wie Xalan das Zeichen-Entity " " automatisch in die Zeichenfolge " " um. Aus Sicht des Browsers ist das ein nicht umbrechendes Leerzeichen wie jedes andere auch.
Hier ein vollständiges XSLT-Stylesheet, das genau das macht:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<strong><xsl:output method="html" encoding="UTF-8"/></strong>
<xsl:template match="/">
<strong><xsl:text>Aidan Burke</xsl:text></strong>
</xsl:template>
</xsl:stylesheet>
Wenn Sie Xalan verwenden, sieht die Ausgabe dieser Transformation wie folgt aus:
Aidan Burke
Das ist sehr schön, weil Browser wissen, wie man " " darstellt. Leider verlangt die XSLT-Spezifikation von XSLT-Prozessoren nicht, daß " " in " " umgewandelt werden müssen. Sie sollten dieses Verhalten mit dem von Ihnen verwendeten XSLT-Prozessor erst einmal überprüfen, bevor Sie sich darauf verlassen.
Einige Programmierer wollen sich nicht ständig daran erinnern müssen, daß " " für ein nicht umbrechendes Leerzeichen steht. Sie definieren daher mit Hilfe einer internen DTD-Untermenge ein Entity in ihrem XSLT-Stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
<xsl:stylesheet version="1.0" ...
Nun kann " " anstelle von " " verwendet werden. Dabei handelt es sich primär um eine Annehmlichkeit für den Stylesheet-Autor, weil der XML-Parser dieses Entity in " " umwandelt, bevor der XSLT-Prozessor es überhaupt sieht. Doch Vorsicht: Einige XML-Werkzeuge werden versuchen, das XSLT-Stylesheet zu validieren, sobald sie den DOCTYPE-Tag erkennen. Weil die DTD-Teilmenge nicht die Definitionen aller XSLT-Elemente enthält, werden entsprechende Validierungsfehler gemeldet.
Wenn populäre XSLT-Prozessoren " " automatisch in " " umwandeln, wo ist dann das Problem? Nun, die Probleme treten auf, wenn die Ausgabemethode des Stylesheets nicht mehr "html" sondern "xml" lautet.
Wenn die XSLT-Ausgabemethode "html" lautet, modifizieren die meisten XSLT-Prozessoren ihre Ausgaben so, daß sie den Browsern entgegenkommen. Beispielsweise können Tags wie "<br />", bei denen es sich um gültiges XML handelt, in "<br>" umgewandelt werden. Das kommt älteren Browsern entgegen, ist aber kein korrektes XML.
XHTML ist die aktuelle Empfehlung des Worldwide Web Consortiums für die Entwicklung von Webseiten. Weil XHTML-Dokumente aus sauberem XML-Code bestehen müssen, könnten Autoren von XSLT-Stylesheets bei der Erzeugung von XHTML die Ausgabemethode "xml" anstelle "html" verwenden wollen. Hier der erste Teil eines XHTML generierenden XSLT-Stylesheets:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<strong><xsl:output method="xml" </strong>
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
encoding="UTF-8"/>
<xsl:template match="/">
<html xmlns="http://www.w3.org/1999/xhtml">
...Rest weggelassen
Ist "xml" die gewählte Ausgabemethode, wandelt Xalan " " nicht in " " um, sondern fügt ein einzelnes Zeichen mit dem Code 160 ein. Das führt in manchen Fällen zu Problemen. Abbildung 2 ist beispielsweise ein Screenshot des Microsoft Internet Explorers 5.5 unter Windows 2000. Beachten Sie das seltsame "A" mit dem Symbol darüber:
Laden Sie das Beispiel herunter, um es auszuprobieren.
Die untere Hälfte von Abbildung 2 zeigt eine alternative Technik, die in den meisten Fällen funktioniert. So geht's:
<xsl:text disable-output-escaping="yes">&nbsp;</xsl:text>
disable-output-escaping="yes" hält den XSLT-Prozessor davon ab, " " in den Zeichencode 160 umzuwandeln. Statt dessen wird die exakte Zeichensequenz " " erhalten. Der Browser gibt das nicht umbrechende Leerzeichen dann korrekt aus.
Es sei darauf hingewiesen, daß die XSLT-Spezifikation von XSLT-Prozessoren keine Unterstützung für disable-output-escaping verlangt, weshalb diese Technik mit den von Ihnen verwendeten Tools getestet werden sollte.
Abbildung 2: Ergebnisse der Ausgabemethode "xml" (oben), verglichen mit disable-output-escaping (unten)
Hier eine Zusammenfassung der vorgestellten Techniken:
- Verwenden Sie das Zeichen-Entity " " zur Darstellung nicht-umbrechender Leerzeichen. Das funktioniert für die Ausgabemethode "html", weil die meisten XSLT-Prozessoren dieses Entity in die literalen Zeichen " " umwandeln. Die XSLT-Spezifikation schreibt dieses Verhalten nicht vor, aber Xalan funktioniert auf diese Weise.
- Definieren Sie ein Entity für " " und benutzen Sie es. Das entspricht letztlich dem ersten Ansatz, sieht für Stylesheet-Autoren aber besser aus. Es kann aber auch zu Problemen kommen, wenn bestimmte Tools versehentlich versuchen, das Stylesheet gegen die nicht existierende DTD zu validieren.
Verwenden Sie
<xsl:text disable-output-escaping="yes">&nbsp;</xsl:text> als Alternative zu " ". Das ist insbesondere nützlich, wenn die Ausgabemethode "xml" lautet. Die XSLT-Spezifikation schreibt nicht vor, daß Prozessoren disable-output-escaping unterstützen müssen.
- Schreiben Sie XML-Producer-Klassen
Um XSL-Transformationen anwenden zu können, müssen Java-Objekte irgendwie in XML-Daten umgewandelt werden. Das kann auf verschiedene Arten geschehen:
- Erweitern Sie jede Klasse um eine getXML()-Methode.
- Schreiben Sie XML-Producer-Klassen, die wissen, wie man bestimmte Java-Objekte in XML umwandelt.
- Verwenden Sie eine Java-nach-XML-API, die die Konvertierung nach XML automatisiert.
Der erste Ansatz könnte etwa so aussehen:
public class Customer {
public Element getXML(Document doc) {
// Verwenden Sie die DOM-API, um ein Element
// zu erzeugen, das dieses Objekt repräsentiert.
...
}
...
}
Dieser Ansatz ist einfach zu erläutern und zu verstehen, weist aber einen entscheidenden Nachteil im Entwurf auf. Das primäre Problem besteht darin, daß die jeweilige XML-Repräsentation nun stark mit jeder Klasse verknüpft ist. Wenn neue XML-Repräsentationen notwendig werden, müssen auch neue Methoden entwickelt werden. Das bedeutet, daß die Klassen größer und größer werden, je mehr "XML-Views" existieren.
Es ist nicht schwer, sich Szenarien vorzustellen, bei denen mehr als eine XML-Repräsentation eines Objekts wünschenswert ist. Bei einem zusammenfassenden Bericht zu Hunderten von Kunden werden nur einige wenige Schlüsselelemente jedes Kunden in den XML-Daten dargestellt. Bei der detaillierten Ansicht eines Kunden sollte der XML-Code hingegen alle mit diesem Kunden in Beziehung stehenden Daten enthalten.
Der zweite Ansatz verlagert die Generierung von XML in separate Utility-Klassen. Ein XML-Producer für einen Kunden könnte wie folgt aussehen:
public class KundeDOMProducer {
public static Element toXML(Kunde cust, Document doc) {
... verwenden Sie die DOM-API zur Generierung eines XML-Fragments
}
}
Diese einfache Änderung entkoppelt die XML-Produktion von der Klasse Kunde. Neue XML-Repräsentationen können einfach hinzugefügt werden, indem man zusätzliche XXXDOMProducer-Klassen entwickelt. Der Wechsel auf Nicht-DOM-APIs wie JDOM ist möglich, ohne irgendwelche Änderungen am Kunde-Code vornehmen zu müssen.
Weitere Informationen zu JDOM finden Sie in der jüngst veröffentlichten 2. Auflage von Java & XML von Brett McLaughlin.
Der dritte Ansatz, bei dem ein Produkt zur automatischen Umwandlung von Java-Objekten in XML-Code verwendet wird, soll nicht unerwähnt bleiben. Auch wenn diese Art von Tools Persistenz schaffen und für den Austausch von Daten mit anderen Anwendungen geeignet ist, ist sie für XSL-Transformationen möglicherweise nicht ideal. Das liegt daran, daß der generierte XML-Code komplexer sein kann als eine von Hand kodierte Lösung, was möglicherweise auch zu komplexeren XSLT-Stylesheets führt.
- Gehen Sie davon aus, daß Cookies deaktivert sind
Die Servlet-API unterstützt das Session-Tracking mit Hilfe der Klasse HttpSession. Das macht Technologien wie Shopping-Carts möglich. Das Standardverhalten dieser Klasse verläßt sich auf Browser-Cookies, um jeden Benutzer identifizieren zu können. Diese Cookies können von den Benutzern aber deaktiviert werden.
Sind Browser-Cookies deaktiviert, müssen Webanwendungen einen anderen Mechanismus zur Identifizierung von Benutzern verwenden. URL-Rewriting ist die von der Servlet-API verwendete Technik. Aus verschiedenen Gründen erfolgt das URL-Rewriting nicht automatisch. Um das Session-Tracking bei deaktivierten Cookies zu unterstützen, müssen Programmierer daran denken, jede von Anwendungen ausgegebene URL zu kodieren. Das geschieht durch Anhängen von jsessionid=nnnnn an jeden Hyperlink, jedes Formular und jeden Redirect-URL. Die folgende Tabelle verdeutlicht URLs mit und ohne Identifier.
| Normaler URL |
Kodierter URL |
<a href="mylink"> |
<a href="mylink;jsessionid=129j2fjs87l156"> |
<form action="mylink"> |
<form action="mylink;jsessionid=129j2fjs871156">
|
Klickt der Benutzer einen kodierten Hyperlink an, oder überträgt er ein Formular mit einer kodierten Aktion, kann der Servlet-Container seine oder ihre Identität bestimmen, indem er den Wert von jsessionid betrachtet.
Wird XSLT zur Generierung von XHTML verwendet, muß der Session-Identifier irgendwie in jeder Seite eingebettet werden. Weil der Identifier dynamisch erzeugt wird und für jeden Benutzer unterschiedlich ist, sollte er als Stylesheet-Parameter übergeben werden. Wie dieser Parameter am Anfang jedes XSLT-Stylesheets deklariert wird, sehen Sie hier:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!--
**********************************************************
** global.sessionID : Für das Session-Tracking per URL-
** Rewriting bei deaktivierten Cookies.
**********************************************************-->
<xsl:param name="global.sessionID"/>
...
Auf der Servlet-Seite der Anwendung gibt der Java-Code den Session-Identifier an den XSLT-Prozessor mit Hilfe der JAXP-Klasse Transformer weiter. Diese ist schlau genug, das nur zu tun, wenn keine Cookies verwendet werden:
protected void doGet(
HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
Transformer trans = ... // Transformer von JAXP beschaffen
HttpSession session = req.getSession(true);
// Session-Tracking ohne Cookies ermöglichen
if (!req.isRequestedSessionIdFromCookie()) {
String sessionID = session.getId();
trans.setParameter("global.sessionID",
";jsessionid=" + sessionID);
}
Auf der XSLT-Seite der Anwendung kann der Parameter global.sessionID an alle Hyperlinks und Formulare angehängt werden, während die Seiten generiert werden. Diese Technik wird umfassend in Kapitel 8, "Additional Techniques," von Java and XSLT erläutert.
- Verwenden Sie XSLT als Code-Generator
Auch wenn XSLT üblicherweise für webbasierte Transformationen eingesetzt wird, ist es nicht auf XHTML-Ausgaben beschränkt. XSLT kann XML in jedes andere Textformat übersetzen, was es zum idealen Kandidaten für viele Arten von Codegeneratoren und anderen Entwicklungswerkzeugen macht.
Wenn Sie XSLT als rudimentären Codegenerator verwenden, sollten Sie sich auf Anwendungen konzentrieren, die sich wiederholen und hochgradig strukturiert sind. Viele mit den Enterprise JavaBeans in Beziehung stehende Klassen sind hochgradig strukturiert und repetitiv, was Sie zu idealen Kandidaten zur Codegenerierung macht.
Im September ist übrigens die dritte Auflage von O'Reillys Enterprise Java Beans erschienen.
- Verwenden Sie <xsl:import> für i18n
Abbildung 3 zeigt, wie XSLT-Stylesheets zur Unterstützung der Internationalsierung modularisiert werden können:
Abbildung 3: XSLT-Internationalisierung
Hierbei handelt es sich um einen interessanten Trick, der auf dem <xsl:import>-Feature von XSLT aufsetzt. Mit <xsl:import> kann ein Stylesheet ein oder mehrere andere Stylesheets importieren. Wenn Stylesheet "A" Stylesheet "B" importiert, haben Templates und Variablendefinitionen in Stylesheet "A" Vorrang vor denen in Stylesheet "B".
Das sprachspezifische Stylesheet könnte etwa so aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href="common.xslt"/>
<xsl:variable name="lang.pageTitle">Welcome to
XSLT!</xsl:variable>
</xsl:stylesheet>
Und das generische Stylesheet etwa so:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" encoding="UTF-8"/>
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of
select="$lang.pageTitle"/></title>
</head>
...etc
Wie hier zu sehen ist, kodiert das generische Stylesheet den auszugebenden Text (den Seitentitel) nicht fest. Vielmehr verläßt es sich auf die im sprachspezifischen Stylesheet enthaltenen Variablendefinitionen. Auf diese Weise ist die Unterstützung einer neuen Sprache nur noch eine Frage der Generierung sprachspezifischer Stylesheets. Das ähnelt sehr stark der "normalen Java-Internationalisierung", bei der verschiedene Property-Dateien sprachspezifischen Text definieren.
- Richten Sie StreamSource ein, um relative URLs aufzulösen
Betrachten Sie den folgenden JAXP-Code (die Problemzeilen sind hervorgehoben):
// XML-Daten enthaltender Stream
InputStream xmlStream = ...
// XSLT-Stylesheet enthaltender Stream
InputStream xsltStream = ...
Source xmlSource = new StreamSource(xmlStream);
Source xsltSource = new StreamSource(xsltStream);
TransformerFactory transFact =
TransformerFactory.newInstance();
Transformer trans = transFact.newTransformer(xsltSource);
trans.transform(xmlSource, new StreamResult(System.out));
Und nehmen wir nun an, das XSLT-Stylesheet importiert ein weiteres Stylesheet:
<xsl:import href="formatName.xslt"/>
Das führt zu Problemen, weil der XSLT-Prozessor nicht weiß, wo er formatName.xslt finden kann. Das gleiche Problem taucht auf, wenn die XML-Daten Referenzen auf andere Dateien enthalten. Der Code wird korrigiert, indem man die Art und Weise ändert, in der StreamSource-Objekte konstruiert werden:
Source xmlSource = new StreamSource(xmlStream,
"file:///C:/data/xml/");
Source xsltSource = new StreamSource(xsltStream,
"file:///C:/data/xslt/");
Der zweite Parameter enthält den URI auf die Verzeichnisse, in denen sich die XML- und XSLT-Dateien befinden. Nun weiß der XSLT-Prozessor, wo er zu suchen hat, wenn er URI-Referenzen in XML-Daten und XSLT-Stylesheets auflöst.
XSLT ist keine schwierige Sprache, auch wenn sie völlig anders funktioniert als Java. Wenn Sie XSLT lernen wollen, ist es wohl am besten, einfach loszulegen, und selbst Stylesheets zu entwickeln. Hier finden Sie einige zusätzliche Informationsquellen zu XSLT:
Eric besitzt einen Bachelor of Science in Informatik der Southern
Illinois University at Carbondale und ist momentan einer der leitenden
Software-Ingenieure bei Object Computing, Inc. (OCI) in St. Louis,
Missouri. Den Großteil seiner Tage verbringt er mit
Consulting-Tätigkeiten und dem Abhalten von mehreren Kursen jeden Monat. Er
hat auch zahlreiche Vorträge zu Themen wie objektorientierte Konzepte,
Java-Servlets, JSPs und JavaBeans gehalten. Wenn er nicht am Computer
arbeitet, beschäftigt er sich gern mit Holzbearbeitung und der
Umgestaltung seines Hauses.
Die Top Ten der Java- und XSLT-Tips 