Das universelle Design

(Auszug aus "Java und XSLT" von Eric M. Burke)

Zwar wächst die Vielzahl von APIs, Frameworks und Template-Engines ständig, aber den meisten Entwürfen scheint der Model-View-Controller-(MVC)-Ansatz gemeinsam zu sein. Eine klare Trennung zwischen Daten, Darstellung und Anwendungslogik ist das erklärte Ziel dieses Designs. Die meisten Web-Frameworks implementieren dieses Muster, und auch der Hybrid-Ansatz von JSP und Servlets folgt ihm. XSLT-Implementierungen verwenden dieses Muster ebenfalls, woraus sich schließen läßt, daß der Model-View-Controller-Ansatz für die Entwicklung in der Webschicht wirklich universell ist.

Web-Frameworks

Ein Framework ist eine Klassenbibliothek mit speziellen Eigenschaften, die die Entwicklung bestimmter Anwendungen erleichtert. So könnte ein Bildbearbeitungs-Framework APIs zum Lesen, Schreiben und Anzeigen verschiedener Bildformate enthalten. Das macht die Erstellung von Anwendungen wesentlich einfacher, weil sich bereits jemand Gedanken über die Struktur Ihrer Anwendung gemacht hat.

Servlet-Frameworks sind in keinster Weise anders. Da Servlets, JSP und Hybrid-Ansätze nun seit einigen Jahren verfügbar sind, kristallisieren sich wiederkehrende Archtikturmuster als »optimal« heraus. Dazu zählt die Trennung von Java-Code und HTML-Erzeugung, die Verwendung von Servlets in Verbindung mit JSP und andere Variationen. Wenn grundlegende Muster und Anordnungen einmal verstanden wurden, drängt sich der Wunsch auf, allgemeine Frameworks zu schreiben, die die niederen Aufgaben in der Erstellung von Webanwendungen automatisieren.

Der wichtigste Nachteil, der Ihnen durch die Verwendung eines Frameworks entsteht, ist, daß Sie sich zu Ungunsten offener Standards auf einen Anbieter festlegen. Im Moment gibt es keine offenen Standards für Frameworks. Obwohl es zahlreiche Open Source-Frameworks gibt, wird keins davon durch eine Standardisierungsorganisation oder Suns Java Community Process gestützt. Die Low-Level-Servlet- und JSP-APIs sind sehr gut definierte und verbreitet implementierte Standard-Java-Erweiterungen. Aber ein Framework kann wesentlich höher entwickelte Möglichkeiten, wie verbesserte Fehlerprüfung, Datenbank-Verbindungs-Pooling, benutzerdefinierte Tag-Bibliotheken und andere Mehrwerte, bieten. Je mehr framework-spezifische Funktionalitäten Sie Ihrer Anwendung hinzufügen, desto geringer werden ihre Möglichkeiten, auf ein anderes Framework oder gar einen anderen Anbieter umzusteigen.

Ein typisches Framewerk ist Turbine, eins von vielen durch Apache unterstützten Frameworks. Turbine ist ein großes Framework, gespickt mit Mehrwertfunktionen wie:

  • Datenbank-Verbindungs-Pooling, Zusammenarbeit mit Tools zur Abbildung von Objekten auf relationale Strukturen und abstraktere Interaktion mit relationalen Datenbanken
  • Zusammenarbeit mit zahlreichen Template-Engines
  • Rollenbasierte Sicherheit und Zugriffskontrolle
  • Webbrowser-Erkennung
  • Arbeitet mit JavaMail zusammen

Dies ist nur eine kurze Liste der Funktionen von Turbine. Im Kern ist der einzig zwingende Grund, ein Framework wie Turbine zu verwenden, das zugrundeliegende Objektmodell. Der Grundsatz von Turbine ist die klare Aufteilung von Validierungslogik, dem Servlet selbst und der Seitenerzeugung auf verschiedene Module. Tatsächlich verwendet Turbine ein einzelnes Servlet, weswegen Ihre Validierungslogik und Seitenerzeugung woandershin müssen. Dies geschieht am besten über Hilfsklassen, sogenannte Actions, die für die Validierung eingehender Anfragen zuständig sind. Hat eine Action eine eingehende Anfrage einmal validiert, sind andere Klassen, wie Layout, Page und Navigation zuständig, die Darstellung an den Browser zurückzuschicken.

Verglichen mit einem reinen XML/XSLT-Ansatz haben Frameworks den Vorteil ihrer Mehrwertfunktionen. Wenn Sie sich alle Nicht-Webfunktionen, wie Datenbank-Verbindungs-Pooling und Tools zur Abbildung von Objekten auf relationale Strukturen, wegdenken, werden Sie feststellen, daß die zugrundeliegende Model-View-Controller-Architektur sehr leicht zu implementieren ist. Sie sollten sich vor jedem Framework hüten, das zu viele dieser nicht im Bezug zum Web stehenden Funktionen bietet, weil viele dieser Funktionen statt auf dem Webserver auf einem Anwendungsserver plaziert werden sollten. Der Rest dieses Kapitels ist der Aufgabe gewidmet, Ihnen zu zeigen, wie man eine komplexe Webanwendung strukturiert, ohne sich einem spezifischen Framework zu unterwerfen.

Model-View-Controller

Die klare Trennung von Daten und der Darstellungslogik ist wichtig. Worin liegen dabei aber die konkreten Vorteile? Erster und wichtigster Vorteil ist die Tatsache, daß bei komplett von der Nutzerschnittstelle getrennten Daten Änderungen am optischen Erscheinungsbild einer Webanwendung ohne Beeinflussung der zugrundeliegenden Daten gemacht werden können. Das ist besonders wichtig bei Webanwendungen, die mehrere inkompatible Browser oder sogar WML, XHTML Basic und/oder HTML unterstützen müssen. Wenn Daten und Darstellung vermischt sind, gestaltet sich die Anpassung der Anwendung an neue Anforderungen der Nutzerschnittstelle wesentlich schwieriger.

Die Anwendungslogik sollte ebenfalls von den Daten und der Darstellungslogik getrennt sein. Zu einem gewissen Ausmaß muß die Anwendungslogik teilweise von Daten und Darstellungslogik abhängen. Generell kann man aber die Anwendungslogik, die von den Daten abhängt, und die Darstellungslogik, die von der Benutzerschnittstelle abhängt, voneinander trennen. Die folgende Abbildung stellt diese Abhängigkeiten dar.

Abbildung: Abhängigkeiten

Abbildung: Abhängigkeiten

Die Pfeile zeigen die Abhängigkeiten an. Wenn sich beispielsweise die zugrundeliegenden Daten ändern, muß mit großer Wahrscheinlichkeit auch die Anwendungslogik geändert werden. Das muß jedoch nicht immer auch die Darstellungslogik beeinträchtigen. Wenn die Änderungen genereller Natur sind, wird es sich schwer vermeiden lassen, auch die höheren Ebenen anzupassen, aber kleine Änderungen können fast immer gekapselt werden. Wenn die Implementierung Ihrer Anwendungslogik sich ändert, ist es sicher nicht nötig, die zugrundeliegenden Daten zu ändern. Ebenso sollten Sie in der Lage sein, Änderungen an der Darstellungslogik vorzunehmen, ohne die Anwendungslogik unbrauchbar zu machen. Weiter unten in diesem Kapitel werden wir sehen, wie man Java, XML und XSLT einsetzen kann, um diese Abhängigkeiten zu erfüllen.

Das vorherrschende Muster skalierbarer Websites heißt Model-View-Controller. Das MVC-Muster hatte seinen Ursprung in Smalltalk-80 als Möglichkeit, graphische Benutzerschnittstellen objektorientiert zu entwickeln. Die Grundlagen sind simpel. GUI-Komponenten repräsentieren das View und sind zuständig für die Anzeige von Informationen für den Nutzer. Das Model enthält die Anwendungsdaten. Der Controller ist zuständig für die Koordination zwischen Model und View. Er fängt Ereignisse von den View-Komponenten ab, fragt das Model nach seinem aktuellen Status, macht Modifikationen am Model und benachrichtigt das View über Änderungen am Model. Die folgende Abbildung zeigt das Zusammenspiel dieser drei Komponenten.

Abbildung: Model-View-Controller

Abbildung: Model-View-Controller

Wie gezeigt, sind Model, View und Controller entweder abstrakte Klassen oder Interfaces. Die konkreten Klassen sind anwendungsspezifisch, und die geöffneten Pfeile geben die Richtung der Verbindung zwischen den verschiedenen Klassen an. So sendet beispielsweise das abstrakte Model Benachrichtigungen nur an das abstrakte View, während KonkretesView auch KonkretesModel kennt. Das macht Sinn, wenn Sie sich vor Augen führen, wie schwer es wäre, ein spezifisches View, wie eine Eingabemaske für Kunden, zu erstellen, ohne ein spezifisches Datenmodell, wie Kunde, zu kennen. Da das Model aber nur auf abstrakte Weise von View-Instanzen weiß, kann es generelle Benachrichtigungen senden, wenn es sich verändert, so daß neue Views später angebunden werden können.

Es ist wichtig, im Hinterkopf zu behalten, daß dies nur ein Muster ist; spezifische Implementierungen können variieren und andere Klassennamen verwenden. Eine Variation ist die Eliminierung der expliziten Referenzen von KonkretesView auf KonkretesModel und von Model zu View. Bei dieser Methode hätte der Controller eine bedeutsamere Rolle. Ein geläufiges Thema in Java ist die Entfernung des expliziten Controllers mittels Datenmodellen und Darstellungskomponenten, die Benachrichtigungen an Event-Listener senden. Obwohl meistens im Zusammenhang mit GUI-Anwendungen erwähnt, ist die MVC-Architektur nicht auf diesen Bereich beschränkt. Bei Webanwendungen wird sie normalerweise verwendet in:

  • dem Hybrid-Ansatz mit Servlets + JSPs
  • den meisten Servlet-Frameworks
  • dem XSLT-Ansatz

Im Hybrid-Ansatz ist das Servlet der Controller und die JSP-Seite das View. Es wird angenommen, daß die Daten aus einer Datenbank entnommen werden oder aus Enterprise JavaBeans (EJB)-Komponenten, die als Model agieren. Ein gutes Framework könnte expliziter zwischen Model, View und Controller unterscheiden. Anstatt das Servlet als Controller einzusetzen, wird häufig auch ein einzelnes Servlet verwendet, das Arbeit an Hilfsklassen delegiert, die dann als Controller agieren. Jede dieser Klassen ist äquivalent zu KonkreterController in der Abbildung Model-View-Controller und verfügt über Wissen zu den spezifischen Webseiten und Daten.

Obwohl MVC ursprünglich für Smalltalk-GUIs gedacht war, ist es schon immer eins der am häufigsten verwendeten Muster für alle Arten von GUIs gewesen, von Motif bis Java. Im Web überwiegt MVC ebenfalls, obwohl einige wenige Mechanismen geringfügig abweichen. In einer Webumgebung sind wir auf das zustandslose HTTP-Protokoll beschränkt. Mit jedem Klick auf einen Hyperlink muß der Browser eine neue Verbindung zum Webserver aufbauen. Ist die Seite einmal ausgeliefert, wird die Verbindung unterbrochen. Es ist für den Server unmöglich, eine Konversation mit dem Client zu beginnen, weswegen der Server lediglich auf die Ankunft der nächsten Anfrage wartet.

Die Implementierung von MVC in dieser statuslosen Architektur resultiert in einer lockeren Verbindung zwischen Controller und View. In einer GUI-Umgebung benachrichtigt der Controller das View unmittelbar über Änderungen am zugrundeliegenden Model. In einer Webumgebung muß der Controller Statusinformationen verwalten, während er darauf wartet, daß der Browser eine weitere Anfrage macht. Wenn eine Anfrage ankommt, ist es die Aufgabe des Controllers, die Anfrage zu validieren und Befehle an das Model weiterzuleiten. Dann sendet der Controller die Ergebnisse zurück an das View.

Das mag an dieser Stelle alles sehr akademisch und auch vage klingen. Die nächsten Abschnitte werden aber wesentlich detailliertere Diagramme präsentieren, die exakt zeigen, wie MVC für eine XSLT-betriebene Website implementiert wird.

XSLT-Implementierungen

Alle bis hierher gezeigten Ansätze führen natürlich hin zum XSLT-Ansatz. In vielerlei Hinsicht ist der XSLT-Ansatz gleichzeitig der leistungsstärkste und leichtverständlichste. Für eine einzelne Webseite ist der XSLT-Ansatz sicherlich schwieriger zu konfigurieren als ein Servlet oder eine JSP-Seite. Die Konfiguration des XML-Parsers und des XSLT-Prozessors können sehr schwierig ausfallen, hauptsächlich bedingt durch Probleme mit dem CLASSPATH. (Das kann eine frustrierende Erfahrung sein, wenn beim Servlet-Container ein alter XML-Parser mit DOM- oder SAX-Version 1 dabei ist. Die meisten XSLT-Prozessoren brauchen Parser ab Version 2.) Mit wachsender Komplexität einer Webanwendung werden die Vorteile von XSLT jedoch offensichtlich. Das eigentliche Ziel dieses Kapitels ist es, herauszufinden, wie diese komplexen Webanwendungen bewältigt werden können.

Der XSLT-Ansatz läßt sich ziemlich direkt auf das MVC-Muster abbilden. Die XML-Daten stellen das Model dar, das Servlet den Controller und XSLT produziert das HTML, das das View darstellt. Das XSLT-Stylesheet kann eine minimale Menge an Logik enthalten, was die Grenze zwischen View und Controller verwischt. Die folgende Abbildung zeigt eine konzeptionelle Ansicht, wie der XSLT-Ansatz sich auf MVC abbilden läßt.

Abbildung: Konzeptionelles XSLT-Model

Abbildung: Konzeptionelles XSLT-Model

Eine Schwäche, die alle Methoden außer XSLT gemeinsam haben, ist die HTML-zentrierte Sichtweise. In jedem bis hierher gezeigten Beispiel wurde angenommen, daß wir HTML erzeugen. Was geschieht, wenn auf einmal die Anforderung besteht, Handys zu unterstützen? Es liegt auf der Hand, daß diese Geräte kein HTML verwenden werden. Stattdessen werden Sie WML, XHTML Basic oder eine bisher noch nicht erfundene Technologie einsetzen. Nun bedenken Sie, daß Sie komplett neue Servlets schreiben müßten, wenn Sie die traditionellen Ansätze verwenden würden. Jede Programmlogik, die in JSP-Seiten eingebettet ist, müßte dupliziert oder in Hilfsklassen ausgelagert werden. Bei einem reinen Servlet-Ansatz müßte die hart-kodierte Logik zur HTML-Erzeugung komplett neu geschrieben werden.

XSLT bietet eine elegante Lösung – erzeugen Sie einfach ein zweites Stylesheet. Anstatt XML nach HTML zu transformieren, wandelt dieses Stylesheet nun XML in WML. So können Sie sogar unterschiedliche Webbrowser unterstützen. Wiederum muß nur ein anderes Stylesheet für browserspezifische Funktionen geschrieben werden. Da XSLT-Stylesheets Funktionalität aus anderen Stylesheets importieren oder einbinden können, kann ein Großteil des Codes in einem Projekt gemeinsam genutzt und wiederverwendet werden.

Egal was ihr XSLT produziert, beginnen Sie mit der Erstellung der XML-Daten. Für die Webanwendung mit der TV-Programmübersicht sind die XML-Daten dynamisch und müssen programmgesteuert erzeugt werden. Der JDOM-Code im folgenden Beispiel übernimmt diese Aufgabe und erzeugt die XML-Daten für die TV-Programmübersicht.

Beispiel: ProgrammuebersichtJDOM.java

package kapitel4;

import java.text.SimpleDateFormat;
import org.jdom.*;
import org.jdom.output.*;

/**
 * Erzeugt ein JDOM-Dokument für die TV-Programmübersicht.
 */
public class ProgrammuebersichtJDOM {
  private SimpleDateFormat datumFmt = new SimpleDateFormat("HH:mm");
  
  /**
   * Einfache main( )-Methode zur Ausgabe des XML-Dokuments an System.out,
   * was für Tests nützlich ist.
   */
  public static void main(String[] args) throws Exception {
    Document doc = new ProgrammuebersichtJDOM().getHeutigeSendungen( );
    new XMLOutputter(" ", true, "ISO-8859-1").output(doc, System.out);
  }
  
  /**
   * @return ein neues JDOM-Dokument mit allen heutigen TV-Shows.
   */
  public Document getHeutigeSendungen( ) {
    Programmuebersicht progr = Programmuebersicht.getInstance( );
    Sendung[] sendungen = progr.getHeutigeSendungen( );
    
    Element wurzelElem = new Element("programmuebersicht");
    
    for (int i=0; i<sendungen.length; i++) {
      wurzelElem.addContent(erzeugeSendungElement(sendungen[i]));
    }
    return new Document(wurzelElem);
  }

  /**
   * Eine Hilfsmethode zur Konvertierung eines Sendung-Objekts in ein JDOM-Element.
   */
  public Element erzeugeSendungElement(Sendung sendung) {
    Element e = new Element("sendung");
    e.addContent(new Element("kanal").setText(
      Integer.toString(sendung.getKanal( ))));
    e.addContent(new Element("von").setText(
      this.datumFmt.format(sendung.getAnfangUhrzeit( ))));
    e.addContent(new Element("bis").setText(
      this.datumFmt.format(sendung.getEndeUhrzeit( ))));
    e.addContent(new Element("titel").setText(sendung.getTitel( )));
    return e;
  }
}

Vielleicht fragen Sie sich, warum dieser JDOM-Code soviel besser ist als der Servlet-Code, der ja auch Java verwendet hat, um programmgesteuert eine Ausgabe zu erzeugen. Der Unterschied ist fundamental und wichtig. In diesem JDOM-Beispiel werden keine println( )-Statements verwendet. Statt dessen wird eine Datenstruktur erzeugt, die die TV-Programmübersicht darstellt. Durch die JDOM-API produziert die Datenstruktur garantiert wohlgeformtes XML. Wir könnten ganz einfach eine DTD hinzufügen und einen Modultest schreiben, der die Integrität der erzeugten Datenstruktur überprüft.

Zusätzlich zur Sicherstellung der Datenintegrität wird der JDOM-Code typischerweise wesentlich kleiner, als der Servlet- oder JSP-Code. Bei dieser einfachen Webseite waren sowohl das Servlet als auch die JSP-Seite sehr klein, weil das HTML keine bedeutenden Formatierungen und kein besonderes Layout enthielt. Bei einer realistischen Webseite würden Servlet und JSP-Seite mit höher entwickeltem HTML-Layout an Komplexität zunehmen, während der JDOM-Code sich nicht verändern würde.

Obwohl das XSLT-Stylesheet mit zunehmender Komplexität des HTML an Größe zunimmt, ist dies ein geringeres Problem, da die Darstellungslogik komplett von den zugrundeliegenden XML-Daten getrennt ist. Einmal vollständig getestet, kann das XSLT auf dem Webserver eingesetzt werden, ohne den Java-Code neu kompilieren zu müssen oder das Servlet neu zu starten. Die von JDOM erzeugten XML-Daten sehen Sie im folgenden Beispiel.

Beispiel: XML für die TV-Programmübersicht-Webseite

<?xml version="1.0" encoding="ISO-8859-1"?>
<programmuebersicht>
    <sendung>
        <kanal>2</kanal>
        <von>06:00</von>
        <bis>06:30</bis>
        <titel>Morgenmagazin</titel>
    </sendung>
    <sendung>
        <kanal>3</kanal>
        <von>06:00</von>
        <bis>08:00</bis>
        <titel>Leichtathletik</titel>
    </sendung>
    ...der Rest der XML-Daten wird ausgelassen
</programmuebersicht>

Das Stylesheet, das exakt dieselbe Ausgabe produziert wie die JSP-Seite und das Servlet, sehen Sie im folgenden Beispiel.

Beispiel: TVProgrammuebersicht.xslt

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html"/>
    <!-- ========== Ab hier wird das HTML-Dokument erzeugt ========== -->
    <xsl:template match="/">
        <html>
            <head><title>Die heutigen Sendungen</title></head>
            <body>
                <h1>Die heutigen Sendungen</h1>
                <table cellpadding="3" border="1" cellspacing="0">
                    <tr>
                        <th>Kanal</th>
                        <th>Von</th>
                        <th>Bis</th>
                        <th>Titel</th>
                    </tr>
                    <!-- ===== hier werden die Sendungen ausgewählt ===== -->
                    <xsl:apply-templates select="programmuebersicht/sendung"/>
                </table>
            </body>
        </html>
    </xsl:template>
    <!-- ======== Jede Sendung wird als eine Tabellenzeile angezeigt ======== -->
    <xsl:template match="sendung">
        <tr>
            <td><xsl:value-of select="kanal"/></td>
            <td><xsl:value-of select="von"/></td>
            <td><xsl:value-of select="bis"/></td>
            <td><xsl:value-of select="titel"/></td>
        </tr>
    </xsl:template>
</xsl:stylesheet>

Das letzte Puzzlestück ist ein Servlet, das alle diese Einzelteile kombiniert und das Ergebnis der XSLT-Transformation an den Client zurückliefert (siehe Servlet-Grundlagen und XSLT). Zusammengefaßt handelt das Servlet als Controller zwischen verschiedenen Komponenten und macht sehr wenig von der eigentlichen Arbeit. Die Anfrage des Clients wird vom Servlet abgefangen, das wiederum ProgrammuebersichtJDOM anweist, die XML-Daten zu erzeugen. Diese XML-Daten werden dann zusammen mit TVProgrammuebersicht.xslt an einen XSLT-Prozessor wie Xalan weitergegeben. Zuletzt wird dann die Ausgabe als HTML, XHTML, WML oder irgendein anderes Format an den Browser zurückgeschickt.

Hinweis:
Als eine interessante Option, die einem diese Architektur eröffnet, kann der Client das rohe XML ohne XSLT-Transformation anfordern. So können auch Nicht-Browserclients unterstützt werden, die die Rohdaten zur eigenen Weiterverarbeitung benötigen.

Da wir die Schwächen der anderen Ansätze ausführlich beleuchtet haben, ist es nur fair, auch einen kritischen Blick auf den XSLT-Ansatz zu werfen. Zunächst ist XSLT eine Sprache, die Entwickler oder Online-Redakteure erst lernen müssen. Obwohl die Syntax seltsam anmutet, kann man argumentieren, daß XSLT leichter zu lernen ist als eine Hochsprache wie Java. Es gibt aber, wie bei jeder neuen und ungewohnten Technologie, auch an dieser Front Widerstand.

Die zweite potentielle Schwäche des XSLT-Ansatzes ist seine Laufzeit-Performance. Mit der XSLT-Transformation sind immer auch Performance-Einbußen verbunden. Glücklicherweise gibt es zahlreiche anwendbare Optimierungen. Die gängigste schließt die Zwischenspeicherung von Stylesheets ein, so daß diese nicht mit jeder Anfrage erneut geparst werden müssen. Diese und andere Optimierungstechniken werden in späteren Kapiteln behandelt.

Da XSLT-Stylesheets eigentlich XML-Dokumente sind, ist jeder verfügbare XML-Editor für XSLT geeignet. Eventuell nimmt aber auch die Verfügbarkeit von speziell auf XSLT ausgerichteten Editoren zu, die Teile der Implementierungsdetails vor Nicht-Programmierern verbergen. Wie auch die ersten Tools zur Java-GUI-Erzeugung, werden diese Editoren vielleicht nicht so saubere Stylesheets erzeugen, wie es in Handarbeit geschieht.

Vorteile durch XSLT in Entwicklung und Wartung

Wie schon früher erwähnt, kann das Testen von JSPs schwierig sein. Da sie nur innerhalb eines JSP-Containers ausgeführt werden können, müssen automatisierte Modultests einen Webserver starten und dann die JSP-Seiten via HTTP-Requests aufrufen, um deren Ausgaben zu prüfen. Der XSLT-basierte Web-Ansatz leidet nicht unter diesem Problem.

Zurückblickend auf die Abbildung Konzeptionelles XSLT-Model können Sie sehen, daß das Datenmodell in einer XSLT-Webanwendung in XML dargestellt wird. Dieses XML wird unabhängig vom Servlet-Container generiert, so daß ein Modultest das XML einfach erzeugen und gegen eine DTD oder ein XML-Schema validieren kann. Tools wie XMLSpy machen es leicht, XSLT-Stylesheets zu erzeugen und sie, lange bevor sie in einem Servlet-Container eingesetzt werden, gegen XML-Beispieldateien interaktiv zu testen.

Der XSLT-Prozessor ist ein weiteres Puzzlestück, das in keiner Weise an das Servlet gebunden ist. Da der Prozessor eine unabhängige Komponente darstellt, können zusätzliche Modultests Transformationen durchführen, indem sie das XSLT-Stylesheet auf die XML-Daten anwenden, auch hier wieder ohne Störungen durch einen Webserver oder Servlet-Container. Wenn Ihre Stylesheets XHTML anstelle von HTML erzeugen, kann die Ausgabe einfach gegen eine der W3C-DTDs für XHTML validiert werden. JUnit ist ein Open Source Modultest-Tool und kann für alle diese Tests verwendet werden. Es kann bei junit.org heruntergeladen werden.

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Java & XSLT bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2002 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Java und XSLT" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de