Wicket und JSF2 im Vergleich

Steuerung von Abläufen

Jede Webanwendung, die aus mehr als einer Ansicht besteht, muss es dem Benutzer ermöglichen, zwischen diesen Ansichten zu navigieren. Hier ist absichtlich von Ansichten und nicht von Seiten die Rede, da sich in vielen Fällen nur ein Ausschnitt der Seite ändert, während andere Teile konstant bleiben. Dabei können die Anforderungen an die Navigation sehr unterschiedlich sein. Im einfachsten Fall steht das Navigationsziel zur Entwicklungszeit fest und kann daher statisch definiert werden. Anders sieht es bei einem Wizard aus, der dynamisch die nächste Ansicht anhand fachlicher Regellogik ermitteln muss. Ein Webframework sollte in beiden Einsatzszenarien unterstützen.

JSF bot zur Beschreibung der Navigationsregeln schon vor Version 2.0 die faces-config.xml. Damit lässt sich die Folgeseite auf Basis der Ausgangsseite und des Rückgabewerts des Event Handlers bestimmen. Leider musste bisher auch das statische Navigationsziel aufwändig konfiguriert werden. Deshalb wurden mit JSF 2.0 nun die Implicit Navigations eingeführt. Damit kann das Navigationsziel direkt im Action-Attribut des Links oder CommandButtons definiert werden, ohne die faces-config.xml anpassen zu müssen. Durch die ebenfalls eingeführte Conditional Navigation können nun per Expression Language beliebige Kontextvariablen geprüft werden, um die nächste View zu bestimmen. Wie viele Kernbestanteile von JSF lässt sich auch der Navigation Handler durch eine eigene Implementierung austauschen. Ausgefeiltere Navigationsverfahren bieten z. B. die Erweiterungen von Spring Webflow oder Seam.

Wicket zentralisiert Navigationsregeln von Haus aus nicht. Das Standardvorgehen ist der implizite Verweis zwischen WebPages bzw. der Austausch von Seitenfragmenten. Jedoch hindert es einen Wicket nicht, ein eigenes Navigationskonzept mit überschaubarem Aufwand zu implementieren. Anstatt des direkten statischen Verweises kann ein Navigation Handler auf Basis des aktuellen Kontexts die Folgeseite bestimmen. So können Wizard-Lösungen, Prozess-Engines oder eigene Regelwerke angebunden werden. Wicket beschränkt sich hier bewusst auf die Kernkompetenzen und lässt Raum zur Erweiterung. In vielen Wicket-Projekten spielen Seiten eine untergeordnete Rolle. Die Navigation innerhalb eines Prozesses übernimmt ein Wizard oder sie wird individuell als Aufsatz zu einer Prozesssteuerung implementiert. Auch wenn Webanwendungen klassischerweise ablauforientert sind, so gibt es immer mehr Anwendungen, die eher den Charakter einer Desktop- oder Dashboard-Anwendung haben (siehe GMail oder iGoogle). In diesen Fällen ist die ablauforientierte Beschreibung einer Anwendung ungeeignet. Wenn die Webanwendung jedoch dem ablauforientierten Ansatz folgt, und komplexe Navigationsregeln beinhaltet, greift JSF hier etwas mehr unter die Arme.

Testunterstützung

Eine gute Testunterstützung ist wichtig für die Softwarequalität und darf auch in einem Webframework nicht fehlen. Beim Test von Webanwendungen wird zwischen Blackbox-Tests und Whitebox-Tests unterschieden. Bei ersterem setzt der Test auf Ebene des Browsers auf, hat also die gleichen Interaktionsmöglichkeiten wie der Anwender. Der Test interagiert mit dem Browser und prüft dessen Ausgabe im DOM. Whitebox-Tests schauen auch „unter die Haube“ und testen die Schnittstellen einzelner Artefakte (Validatoren, Models etc.) oder Widgets.

Um Blackbox-Tests zu ermöglichen, muss das Webframework stabile IDs in die HTML-Tags generieren, über die die Elemente dann im Test referenziert werden können. Testframeworks wie HTML-Unit, Selenium oder WebDriver bieten sich sowohl bei Wicket als auch bei JSF für Blackbox-Tests an. Der Nachteil beim Blackbox-Test: Er erfordert eine Containerumgebung. Durch die Dauer des Containerstarts eignen sich Blackbox-Tests daher weniger für kurze Testzyklen und somit zu einer testgetriebenen Entwicklung.

Wicket bietet mit dem Wicket-Tester eine gute Grundlage für Whitebox-Tests, da dieser die Containerumgebung mockt und so den Test einzelner Widgets außerhalb eines Webcontainers ermöglicht. So lassen sich z. B. Interaktionen, der Zustand des Komponentenbaums oder Serviceinteraktionen einfach testen.

Im JSF-Standard selbst ist kein Testframework für Whitebox-Tests enthalten. Nichtsdestotrotz gibt es auch hier verfügbare Lösungen. JSFUnit [6] ermöglicht sowohl Whitebox- als auch Blackbox-Tests. Allerdings muss es für JSFUnit-Tests auch eine Containerumgebung geben, was die Testzyklen wiederum verlängert. Da JSFUnit von JBoss entwickelt wird, lassen sich Richfaces-Anwendungen gut testen. Nutzt man andere Component Libraries, können die über den Standard hinausgehenden Features möglicherweise nicht getestet werden.

Unterstützung von Web-Patterns

In Webanwendungen haben sich Patterns etabliert, um mit den Eigenschaften des HTTP-Protokolls und den Freiheiten, die der Browser bietet, sinnvoll umzugehen. Auch hier lohnt es sich, zu vergleichen, wie JSF und Wicket diese Patterns unterstützen.

Redirect-After-Post

Mit Redirect-After-Post [4] können Webanwendungen verhindern, dass Formulare ungewollt mehrfach übermittelt werden. Bei Wicket ist dies das Standardverfahren, auch wenn über die Änderung der Render Strategy ein einfacher POST durchgeführt werden kann. JSF führt standardmäßig keinen Redirect-After-Post durch. Jedoch kann man dieses Verfahren durch die Kombination faces-redirect=true (als URL-Parameter) und dem neuen Flash Scope herstellen. Statt des Flash Scopes können die Formularwerte auch per View-Parameter übergeben werden [5]. Eine fertige Lösung für Redirect-After-Post bieten das Seam Framework, Spring WebFlow oder PrettyFaces [7].

Tabbed Browsing

Eine Websession bezieht sich üblicherweise auf alle Fenster und Tabs, die für eine Anwendung geöffnet werden. Dies kann zu Problemen führen, wenn in verschiedenen Fenstern unterschiedliche Arbeitsabläufe einer Webanwendung durchgeführt werden sollen. Damit diese sich nicht ungewollt gegenseitig beeinflussen, muss das Webframework die Fenster unterscheiden können und für jedes Fenster eigene Speicherbereiche verwalten. Wicket erkennt einzelne Fenster an einem JavaScript Flag und hält für jedes Fenster eine eigene PageMap, in der der Seitenzustand verwaltet wird. JSF bietet auch in der neuen Version keine fertige Lösung für Tabbed-Browsing. Ein spezieller Scope (oder Zustandsspeicher) könnte durch den in JSF 2.0 neu hinzugekommenen Custom Scope erstellt werden. Allerdings gibt es auch hierfür bereits fertige Lösungen in Aufsatz-Libraries wie MyFaces Orchestra, Spring WebFlow oder Seam.

GET-Requests

Hält man sich an die Semantik von HTTP, sollte ein POST-Request nur für bestandsändernde Operationen genutzt werden und GET-Requests für lesende Operationen. JSF führt beide Operationen standardmäßig über POST-Requests durch und machte es in Version 1.x schwer, mit GET-Requests zu arbeiten. Auch der Einstieg in die Anwendung über einen parametrisierten GET-Request erforderte Aufsatz-Libraries wie PrettyFaces. Mit den in Version 2.0 eingeführten ViewParams ist die Nutzung von GET-Requests nun vereinfacht worden, Standard ist aber nach wie vor der POST-Request. Legt man Wert auf lesbare URLs, empfiehlt es sich auch weiterhin, einen Blick auf PrettyFaces zu werfen. In Wicket kann über verschiedene Linkkomponenten per GET-Request navigiert werden. Um lesbare URLs zu erhalten, können WebPages als bookmarkable gekennzeichnet werden. Diese werden bei der Anwendungsinitialisierung auf URLs „gemountet“.

Fazit

Das endgültige Urteil, ob nun Wicket oder JSF 2.0 besser passt, muss der Leser im Kontext des Projekts fällen [1]. Zu unterschiedlich sind die Anforderungen, als das man eines der beiden Frameworks von vornherein als die Lösung für alle Anwendungsbereiche küren kann. Beide Frameworks ermöglichen die technische Wiederverwendung, auch wenn Wicket hier mit weniger Varianten und der Beschränkung auf Java-Standardmittel auskommt. Durch Composite Components und Facelets als Standard ist die Entwicklung von UI Controls in JSF 2.0 um einiges vereinfacht worden. Auch das Erstellen von Widgets, also das Kapseln von Fachlichkeit in der UI, ist in beiden Technologien möglich. Für JSF existiert eine große Auswahl ausgereifter Component Libraries, die oft auch bereits Ajax-Funktionalität bieten. Durch die (ziemlich verspätete) Aufnahme von Ajax in den Standard, kann künftig mit einer besseren Kompatibilität zwischen den einzelnen Component Libraries gerechnet werden. Aktuell befinden sich die meisten 2.0 kompatiblen Libraries noch im Betastadium.

Wicket hingegen bietet viele sehr gute Grundlagen, wie die Berücksichtigung von Web-Patterns und eine Testunterstützung für Whitebox-Tests. Bei JSF muss man dafür bereits Zusatz-Libraries einsetzen. Nichtsdestotrotz ist der Initialaufwand zur Erstellung anspruchsvoller Geschäftsanwendungen in Wicket höher. Freiheitsgrade, die vom Framework bewusst gelassen werden, sollte man durch projektspezifische Erweiterungen oder Anwendungsmuster konkretisieren. Will man aber das Layouting einem Webdesigner überlassen, bietet Wickets Trennung von HTML und Logik dafür eine gute Grundlage.

Durch die Beschränkung auf HTML und Java muss der Entwickler sich nicht mit einem Potpourri an Technologien und Frameworks arrangieren. Zudem kann er ohne spezifischen Support in seiner IDE arbeiten. Bei der Arbeit mit JSF sollte hingegen eine Toolunterstützung für Facelets vorhanden sein. Ein wichtiger Aspekt für die Entscheidung sind die Vorkenntnisse der Anwendungsentwickler. Existieren beispielsweise Kenntnisse in Swing, werden die Abstraktionen von Wicket bekannt vorkommen. Sind Entwickler das Arbeiten mit Template Views gewöhnt, werden ihnen die Facelet Templates in JSF vertrauter sein. Schaut man sich die Entwicklung der Frontend-Technologien an, erkennt man, wie schnell sich diese Technologien überleben. Daher ist eine grundlegende Empfehlung, sich nicht zu sehr von einer Frontend-Technologie abhängig zu machen. Es liegt am Architekten, eine Strategie zur Frontend-Komponentisierung, auch über Technologiegrenzen hinweg, zu etablieren.

Alexander Elsholz arbeitet als Senior Consultant bei der WidasConcepts GmbH, einer IT-Unternehmensberatung mit dem Fokus auf den IT-Architekturen und Anwendungsentwicklung. Zu seinen Schwerpunkten gehören die Entwicklung von serviceorientierten JEE-Architekturen sowie die Konzeption und die Realisierung von Standardsoftware. Darüber hinaus ist er Autor verschiedener Fachartikel sowie Sprecher auf einschlägigen Fachveranstaltungen. Sie erreichen ihn unter alexander.elsholz[at]widas.de.

Kai Weingärtner arbeitet ebenfalls als Senior Consultant bei der WidasConcepts GmbH. Seine Tätigkeitsschwerpunkte liegen in Web-2.0-Themen sowie der Konzeption und Umsetzung von webbasierten Java-EE-Anwendungen. Hierzu hat er bereits verschiedene Fachbeiträge veröffentlicht und Vorträge auf bekannten Fachkonferenzen gehalten. Sie erreichen ihn unter kai.weingaertner[at]widas.de.

Elena Stoll ist Diplommathematikerin und arbeitet als Anwendungsentwicklerin bei der WidasConcepts GmbH. Sie beschäftigt sich in erster Linie mit der Konzeption und Entwicklung von modernen Weboberflächen mit Ajax sowie dem Design und der Umsetzung von webbasierten Java-EE-Anwendungen. Sie erreichen sie unter elena.stoll[at]widas.de.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.