Wicket und JSF2 im Vergleich - JAXenter

Wicket und JSF2 im Vergleich

UI Controls und Widgets

Im weiteren Verlauf unterscheiden wir zwei Formen von UI-Komponenten: UI Controls und Widgets. Diese Begriffe bedürfen einer kurzen Definition (Abb. 2): UI Controls sind Eingabe- oder Darstellungselemente wie Labels, Textfelder und Links, aber auch Composite Controls wie Trees oder Tabellen. UI Controls sind die wiederverwendbaren, technischen Bausteine, die zur Visualisierung und Interaktion benötigt werden. Widgets sind Kompositionen aus UI Controls und Frontend-Logik, die einen fachlichen Aspekt kapseln und eine auf die Fachlichkeit reduzierte Schnittstelle nach außen bieten. Diese können dabei neben Event Bindings auch Validatoren und Konverter und ggf. auch die Datenanbindung kapseln. Damit soll vor allem die Komplexität der Fachlichkeit reduziert werden. Beispiele für Widgets sind etwa eine Artikeleingabe oder PLZ-Suche. Des Weiteren sind UI-Fachkomponenten aufzuführen, die mehrere Widgets einer Fachdomäne zusammenfassen. Sie sind meist das Pendant zu den Komponenten der Businessschicht.

Abb. 2: UI-Komponenten
Technische Wiederverwendung

Ein ausgereiftes Set an UI Controls kann dem Entwickler viel Eigenentwicklung bzw. technischen Code ersparen. Für JSF gibt es eine große Anzahl kostenfreier und kommerzieller Component Libraries. In Wicket beschränkt sich der UI-Control-Markt auf einige Open-Source-Projekte. Dafür wird die Integration von JavaScript-Bibliotheken wie JQuery durch Integrationsbibliotheken erleichtert [3]. Trotzdem wird man im Projekt früher oder später auf Anforderungen stoßen, die nicht vom Framework abgedeckt werden. In beiden Frameworks bieten sich Möglichkeiten, bestehende UI-Komponenten zu erweitern:

  • Die Funktionalität erweitern durch Vererbung
  • Das Kombinieren von vorhandenen UI-Elementen zu Composite Controls
  • Das Modularisieren von Querschnittsaspekten durch Behaviours, die an existierende UI Controls geknüpft werden können

Da in Wicket UI Controls lediglich Java-Klassen sind, kann das Basisverhalten durch Vererbung erweitert werden. Neben dem Überschreiben aller Bestandteile der Component (Abb. 1) kann auch das damit verknüpfte HTML-Snippet in einer Ableitung ersetzt oder ergänzt werden. Als Basis für die Entwicklung von Composite Controls bietet Wicket die Panel-Klasse, in der beliebige UI Controls genutzt werden können.

Mit JSF 2.0 gibt es mehrere Möglichkeiten, Basiskomponenten zu erweitern, die unterschiedlich viele Detailkenntnisse des Frameworks voraussetzen. Mit den Composite Components ist es mit JSF 2.0 sehr einfach geworden, die genannten Composite Controls zu erstellen. Dazu erstellt der Entwickler lediglich eine xhtml-Datei, die das gewünschte Markup enthält, und definiert die nach außen sichtbaren Tag-Attribute. Die zweite Variante ist eine Facelet Markup Component, die ähnlich gestaltet ist, aber über ein Facelets Taglib (XML) die Vergabe eigener Namespaces ermöglicht. Soll ein UI-Control erweitert werden, muss sich der Entwickler entscheiden, ob er das Verhalten oder lediglich das Aussehen der Komponente ändern will. Im ersten Fall erweitert er die UIComponent, im zweiten Fall tauscht er den Renderer aus. Beides wird dann über ein Facelets Taglib als Tag veröffentlicht.

Behaviours können in Wicket einer UI-Control-Instanz oder zentral mehreren (über ComponentInstantiationListener) hinzugefügt werden. Über Callbacks kann damit in den Lifecycle von UI Controls eingegriffen werden und so z. B. der HTML-Output angepasst oder JavaScript und damit z. B. Ajax-Verhalten hinzugefügt werden. Mit Version 2.0 erhielt JSF ebenfalls eine Behaviour API. Alle JSF-2.0-Basis-Controls implementieren nun ClientBehaviourHolder und unterstützen damit das nachträgliche Anbinden von JavaScript. Die aktuell einzige Implementierung in JSF selbst ist das neue f:ajax-Tag, mit dem Ajax-Verhalten an ein UI Control gebunden werden kann. In der Core Library gibt es von der Basisklasse Behaviour bisher keine weiteren Implementierungen, diese soll aber künftig auch als Ausgangspunkt für andere Behaviour-Arten genutzt werden.

Die Beschränkung auf Java und OO-Konzepte zur Erweiterung von UI Controls macht es in Wicket sehr einfach, vorhandene Basisfunktionalität um domänenspezifische oder architekturrrelevante Eigenschaften zu erweitern. In JSF ist die Komposition von UI Controls zwar stark vereinfacht worden, das Erweitern einzelner UI Controls erfordert durch das Zusammenspiel von UIComponent, Renderer und Taglib aber mehr Arbeitsschritte.

Fachliche Komponentisierung

Bei der fachlichen Komponentisierung, also dem Herausbilden von Widgets, geht es weniger um die Erstellung wiederverwendbarer Komponenten. Da ein Widget eine fachliche Teillösung darstellt, muss es möglich sein, Fachlichkeit wie Validierung, Konvertierung und View-Logik (Feld wird aktiviert, wenn Checkbox gedrückt wurde) darin als Implementierungsdetail zu kapseln. Mit der Trennung von öffentlicher Schnittstelle und Innensicht bildet man autarke und wartbare Artefakte.

In Wicket kann die Klasse Panel als Basis für ein Widget genutzt werden. Frontend-Logik, Validierung und Datenbindung lässt sich hinter einem Java-Interface kapseln. So werden Controls inklusive Logik, Validierung und zum Teil auch Backend-Anbindung zu einem fachlich abgeschlossenen Widget zusammengefasst. Dabei können alle Ressourcen in einer Jar-Datei gebündelt und anderen Entwicklern zur Verfügung gestellt werden. Neben dem Controller, den Layoutartefakten (Bilder, CSS, HTML) und den Properties-Dateien für die Internationalisierung wird eine fachliche Schnittstelle definiert, die die von anderen Komponenten nutzbaren Funktionalitäten beschreibt. Dabei findet die Kommunikation nur über die definierte öffentliche Java-Schnittstelle statt.

JSF 2.0 ermöglicht mit den Composite Components die Kapselung von Validierungs- und Konvertierungslogik. Bei den Composite Components kann die Schnittstelle nach außen über die zulässigen Tag-Attribute definiert werden. View-Logik lässt sich über eine spezialisierte Backing Bean umsetzen. Diese Bean kann als Teil des Widgets ausgeliefert werden und muss somit nicht außen bekannt sein. Einzig bei der Namensgebung der Beans muss mangels Namespaces mit Konventionen verhindert werden, dass Namen mehrfach vergeben werden. Composite Components können wie normale UI Components im View Markup verwendet werden, oder sogar in andere Composite Components eingebunden werden. Auch bei JSF lassen sich die genannten Artefakte (Backing Bean, Composite Component, Validatoren und Konverter) in einer Jar-Datei zusammenfassen.

Kommentare

Schreibe einen Kommentar

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