Entscheidungshilfe zur Frameworkauswahl

Wicket und JSF im Vergleich

Alexander Elsholz, Kai Weingärtner und Elena Stoll

Der Vergleich zwischen Wicket und JSF führte in der Vergangenheit häufig zu folgendem überspitzten Fazit: „JSF ist schwergewichtig, komplex und benötigt für einfachste Anforderungen Erweiterungen, viel zu viel Code und viel zu viele Ressourcen – aber Standard. Wicket hingegen ist komplett, leichtgewichtig, schlank und einfach zu erlernen – aber proprietär.“ Ein wenig erinnerten die Vergleiche an Spring und EJB 2.0. So übertrieben dieses Fazit ist, Wicket hat sich inzwischen als ernsthafte Konkurrenz zu JSF etabliert. Beide Frameworks haben sich weiterentwickelt. In JSF 2.0 wurden nun viele Schwächen der Vorgängerversion angegangen. Zeit also, beide Frameworks erneut gegenüberzustellen.

JSF und Wicket gehören zu den komponentenbasierten Webframeworks. Vor der Spezifikation von JSF bestimmten Action-basierte Frameworks wie Struts den Webframeworkmarkt. Doch was macht ein komponentenbasiertes Framework aus und was ist der Unterschied zu den Action-basierten Alternativen? Action- oder auch Request-basierte Frameworks stellen den Ablauf in den Vordergrund: Request, Ausführen von Geschäftslogik, Rendern des Ergebnisses, Response. Entlang dieses linearen Ablaufs erstellt der Entwickler seine Artefakte. Komponentenbasierte Frameworks verstecken diesen Aspekt vor dem Entwickler. Er reagiert nicht mehr direkt auf Requests, sondern auf Events, die das Framework aus der Anfrage extrahiert. Zunächst wird die betroffene Komponente identifiziert, dann die Daten der Komponente wiederhergestellt und ein passendes UI-Event ausgelöst. Als Reaktion darauf werden Datenmodell oder Komponenten aktualisiert. Das Framework baut aus den aktualisierten Komponenten dann den passenden Response zusammen. Die Komponentisierung des Frontends verbessert Wartbarkeit, Testbarkeit und Wiederverwendbarkeit. Dafür muss man die Überführung von Request in den Komponentenbaum und wieder zurück in Kauf nehmen, was mit einem erhöhten Ressourcenverbrauch verbunden ist.

Die Kernkonzepte im Überblick

Um die unterschiedlichen Herangehensweisen von Wicket und JSF zu verstehen, ist es hilfreich, deren Designziele und Kernkonzepte zu verstehen. Wicket wurde nach dem Grundsatz „Just Java, just HTML and meaningful Abstractions“ entwickelt. Die klare Trennung zwischen Layout und Logik, ergänzt um einfach anzuwendende Abstraktionen, unterstützt den Fachentwickler dabei, sich auf seine Kernaufgabe – die Umsetzung der Fachlichkeit – zu konzentrieren. Der Entwickler definiert das statische Layout (HTML) auf der einen Seite und entwickelt die Dynamik objektorientiert in Java auf der anderen. Wicket übernimmt dabei die Zusammenführung beider Artefakte (Abb. 1).

Abb.1: Zusammenführung von statistischem Layout und Dynamik

Wicket nutzt weitestgehend Java und OO-Konzepte zur Umsetzung einer komponentenorienterten Webanwendung: Über Listener werden Event Handler an Events der UI-Komponente gebunden und über Vererbung von Seiten wird das Basislayout von individuellen Inhalten getrennt. Die Designziele von JSF sind detailliert im JSR 127 beschrieben. Hier seien nur zwei Ziele hervorgehoben:

  • Nutzen des JavaBeans-Modells für die Verknüpfung (Binding) von UI Events und Anwendungslogik
  • Automatische Erzeugung von passenden Ausgabeformaten für die Zielumgebung

Aus dem ersten Ziel leiten sich die Managed Beans ab. Dies sind von JSF verwaltete JavaBeans, in denen auf UI Events reagiert wird und das Model verwaltet wird. Über die Expression Language (EL) werden Event Handler und Model im View Markup an UI-Komponenten gebunden (Abb. 2). In JSF wird der UI-Komponentenbaum im Gegensatz zu Wicket im View Markup definiert. Seit JSF 2.0 ist dies standardmäßig ein Facelet Template, also xhtml mit JSF-spezifischen Tags. Im View Markup können ebenfalls Konverter und Validatoren an den UI-Komponenten registriert werden. Aus dem zweiten Ziel folgte die strikte Trennung der UI-Komponente von deren Darstellung. Deshalb wird bei JSF zwischen UIComponent und Renderer unterschieden. Dabei enthält die UIComponent den Zustand der Komponente (z. B. den Wert einer Textbox) und der Renderer kümmert sich um deren Darstellung.

Worauf kommt es an?

Es gibt nicht „das“ richtige Webframework, nur das zum Projekt besser passende. Deswegen müssen im Kontext des Projekts die Anforderungen gewichtet werden [1]. Da im Rahmen eines Artikels nicht alle Aspekte beider Webframeworks betrachtet werden können, beschränken wir uns hier auf Themen, die ein komponentenorientiertes Framework unterstützen muss. Außerdem werden Aspekte betrachtet, die JSF und Wicket unterschiedlich gut oder auch nur auf unterschiedliche Weise umsetzen. Ein wichtiges Kriterium für ein komponentenorientiertes Webframework ist, einfach und flexibel technische Basiskomponenten zur Wiederverwendung erstellen zu können. Außerdem sollen mit der Komponentisierung Teillösungen entwickelt werden können, die Fachlichkeit kapseln und eine lose Kopplung zu anderen fachlichen Komponenten ermöglichen. Hier stellen wir die Ansätze von JSF und Wicket nebeneinander.

Es gibt Anwendungen, die vom Bedienkonzept überwiegend ablauforientiert sind – also solche, bei denen der Ablauf zustandsbehaftet und die Navigation vorbestimmt ist. Andere Anwendungen hingegen erlauben eine völlig freie Navigation. Daher betrachten wir, wie gut beide Frameworks diese Ansätze unterstützen [2]. Ein Vorteil von komponentenorientierten Webframeworks ist die Entwicklung von autarken UI-Komponenten, die losgelöst voneinander gewartet werden können. Es lohnt sich daher, auch einen Blick auf die Testunterstützung des Frameworks zu werfen. Im Punkt Web-Patterns gehen wir schließlich darauf ein, wie gut JSF und Wicket mit den Rahmenbedingungen von HTTP und der Browserbedienung umgehen.

Geschrieben von
Alexander Elsholz, Kai Weingärtner und Elena Stoll
Kommentare

Schreibe einen Kommentar

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