Xplate ist ein nahe an den XML-Standards implementierter XML-Prozessor. Hauptzweck ist das Verarbeiten von Web-Requests und Generieren von dynamischen Web-Inhalten, wobei Xplate nicht darauf eingeschränkt ist.
Hintergrund#
Aktueller Stand der Technik#
Es gibt eine Vielzahl von Frameworks für den Aufbau von Web-Seiten, selbst wenn man nur Java-basierte Systeme betrachtet. Allen gemeinsam ist, dass ein neues System erfunden wurde, das sehr spezielles und tiefes Know-How verlangt. Dabei unterscheiden sich die Frameworks untereinander so stark, das ein Umstieg fast einem Neueinstieg gleicht.Das historisch erste XML-basierte System war wohl XSLT, das heute nur noch in speziellen Fällen eine Rolle spielt. Die Anwendung für Web-Seiten und HTML hat bis fast vollständig an Bedeutung verloren. Es wurde hauptsächlich durch JSP und deren Nachfolgersysteme, sowie rein Java-basierte Systeme verdrängt.
Diese Frameworks weisen inzwischen eine enorme Komplexität auf und sind selbst für langjährige Experten schwerlich einsehbar. Die Systeme sind gewachsen, mit der Anforderung auf Abwärtskompatibilität. Einige Teile, wie zum Beispiel die Tag-Unit ist in JSF derart tief verbaut, das auf dieser Ebene der Eingriff so gut wie nicht mehr möglich ist.
Das Verständnis, wann ein Tag aufgebaut wird, in welchen Phasen welche Variablen zur Verfügung stehen, wie weit andere Tags instantiiert sind, ist kaum mehr nachvollziehbar. Ein Effekt ist, dass das Verhalten von <c:forEach>, <ui:repeat> oder anderen dynamischen Elementen gerade in komplizierten Situationen nicht verstanden wird. Kleine Änderungen können ein unvoraussagbares Verhalten der Anwendung bewirken.
Auch andere Neuerungen, die vom Ansatz her eigentlich sehr nützlich sind, gestalten sich in der praktischen Anwendung als seht kompliziert. Als Beispiel seien hier Behaviors erwähnt, die nur bei speziellen Attributen wirken und explizit unterstützt werden müssen. Wenn dann auch noch sogenannte Composite Components im Spiel sind, bekommen selbst Hersteller großer Komponentenbibliotheken Probleme.
Auch das Einsatzgebiet ist stark eingeschränkt. Factories und viele statische Elemente sind so mit dem Web-Request verbunden, dass selbst das einfache Laden oder Rendern einer XHTML-Datei außerhalb des vorgesehenen Servlets zum Verhängnis wird.
Der Umgang mit EL-Expressions ist momentan eine Herausforderung für die wirklichen Profis. Die Kontexte sind mit der Tag-Erzeugung (Facelet-Context), Include-Anweisungen und Composite-Tags verbunden. Wobei Composite-Tags höchst ineffizient sind, da viele Tags durch den Speicher- und CPU-Intensiven Tag-Mechanismus geleitet werden müssen.
Der Umgang mit sogenannten View-States ist ein überladenes Thema, da die Komponentenbäume unmittelbar mit den gespeicherten Daten verbunden sind. Dadurch muss bei jedem Request der komplette Komponentenbaum rekonstruiert werden, auch wenn beispielsweise nur ein einziges Häkchen geändert wird.
Idee#
XML ist eine recht ausgereifte Sprache, die sowohl von Computer und Maschine gut verstanden wird. Vor allem gibt es für XML-Dateien die Möglichkeit ein Schema zu definieren (oder mehrere), die beschreiben, welche Tags auftauchen können und welche Attribute diese enthalten können. Diese Schema-Dateien haben die Endung .xsd und werden direkt von den XML-Editoren der Entwicklungsumgebungen unterstützt, wie zum Beispiel von Eclipse.Für eine Tag-Library inklusive Content-Assist und Hilfe-Texte ist nichts weiter nötig, als eine XSD-Datei zu generieren. Die Frameworks zum Einlesen von XML-Dateien liegen auch bereits lange vor, diese prüfen sogar auf Verstöße gegen diese Schema-Dateien.
Entsprechende Java-Klassen können anhand des XML-Namespace gefunden werden, dies können durch Konfiguration oder Annotationen zur Verfügung gestellt werden. Für das Abwickeln von Web-Requests ist dann nur noch ein kleines System erforderlich, das einen Kontext bereit hält, mit dem eine derart gestaltete XHTML-Seite abgearbeitet und das Ergebnis ausgegeben werden kann.
Die Komponentenbäume werden zustandsfrei gespeichert, der aktuelle Zustand in einfachen Kontekten gespeichert. Die Komponentenbäume können daher Request-, Session- und Applikationsübergreifend wiederverwerdet werden. Es fällt keinerlei Berechnungsaufwand für das Erzeugen, Serialisieren und Wiederherstellen an. Der Zustand wird durche den XplateContext transportiert und braucht sehr wenig Speicher.
Design-Criterien#
Die Liste ist im Moment noch etwas unsortiert:- Keine gehideten Methoden, Private Constructors und Package Classes, die volle Funktionalität von Xplate ist nutzbar.
- Einfacher straight-forward Ansatz. Die Aufrufe gehen alle durch die gleichen Methoden, alle Attribute und Elemente werden gleich behandelt. Im Zweifelsfall wird eine Exception geworfen, der Entwickler kann den Fehler beheben.
- Tags werden zu einem statischen Komponenten-Baum compiliert. Es gibt keine komplizierten Restore State oder State Saving.
- EL-Expressions werden statisch compiliert, die Werte werden ausschließlich durch Resolver ermittelt. Es gibt keine komplizierten dynamischen Kontexte für verschiedene Arten von Komponenten.
- EL-Expressions werden beim Abrufen durch den Tag erzeugt und auch am Tag gespeichert. Es gibt keinen komplizierten Evaluation-Mechanismus für Attribute auswerten.
- XML-Tags, für die keine Java-Klasse vorhanden ist, wird 1:1 in den Response Stream kopiert. Es wird keine komplizierte Interpretation jedes HTML-Attributs vorgenommen, noch die Auswahl möglicher Tags eingeschränkt. Xplate beschränkt sich auf Tags, für die eine Definition in Form einer @XmlNamespace annotierter Java-Klasse vorliegt.
Geplanter Umfang#
Folgende Features sind geplant, dass sie in Xplate eingebaut werden:- Java-Tags: Die Möglichkeit, Tags auf einfache Weise in Java zu implementieren.
- XML-Tags: Die Möglichkeit Tags ohne Java-Code zu implementieren. Statt dessen werden andere Tags zu einem neuen Tag kombiniert.
- Statischer Pages: Pages, und damit auch Composite Tags, sind XML- bzw. XHTML-Dokumente, die aus hierarchisch angeordneten Tags bestehen. Dieser Tree wird nur einmal eingelesen und bleibt dann erhalten. Die Dynamik der Seiten erfolgt ausschließlich durch den Kontext (Xplate-Context), unter dem ein Tag oder eine ganze Page aufgerufen wird.
- AJAX: In Xplate wird es Tags und eine Java-API geben, mit der vom Browser Teile einer Web-Seite abgeschickt und neu gerendert werden können.
- EL-Expressions: Die Sprache für Expressions in Xplate sind EL-Expressions, wie diese von JSP, JSF und anderen Frameworks bekannt sind. Wie bei den Tags und Pages selbst, werden Expressions statisch compiliert. Das Auswerten erfolgt über den Xplate-Context.
