JSF für Portlets

Die JavaServer-Faces-Spezifikation schreibt seit der Version 1.0 die Unterstützung von Portlets als Anwendungsfall für eine JSF-Anwendung vor – allerdings nicht sehr detailliert.

Die Benutzung von JSF als Framework für die Entwicklung von Portlets ist eigentlich ein alter Hut. Das Zusammenspiel sollte funktionieren, sagt doch die JSF-Spezifikation bereits seit der Version 1.0, dass Portlets unterstützt werden. Ein einfacher Blick in die JavaDoc der Klasse ExternalContext belegt dies [1]. Entsprechend ist auch der JSF-Lifecycle unterteilt. Die Methode execute() führt die Phasen eins bis fünf aus und das finale Rendering, die Phase 6, wird durch die render()-Methode realisiert. Allerdings ist die Kombination JSF/Portlets immer wieder eine Quelle für zahlreiche Fehler und damit auch ein Garant für Überstunden. Doch warum? Das eigentliche Problem liegt darin, dass die Unterstützung oder die Integration von Portlet und JSF nicht detailliert genug und vollständig beschrieben ist. Das führt dann zu etlichen Problemen und Inkompatibilitäten zwischen den verschiedenen, notwendigen „Brücken“ und Portlet-Containern. Auf dem Markt gibt eszahlreiche Implementierungen einer solchen JSF-Portal-Bridge.

Neuer Standard! Neues Glück?

Aufgrund dieser Problematik wurde von Oracle bereits 2006 der „Portlet Bridge Specification for JSF“-Standard ins Leben gerufen. Innerhalb des JSR 301 sollte nun eine Spezifikation erstellt werden, die die JavaServer-Faces-Version 1.2 mit den aktuellen Portlet-Versionen 1.0 und 2.0 verbindet. Die ursprüngliche Spezifikation selbst ist sehr dünn, wenn man da an JSF 1.2 mit seinen mehr als 400 Seiten denkt. Die erste Version der Referenzimplementierung (RI) wurde von Oracle an das Apache-MyFaces-Projekt übergeben, um so einen offenen Implementierungsprozess zuermöglichen – soweit die ursprüngliche Idee.

Die Unterstützung von zwei verschiedenen Portlet-Spezifikationen stellte das JSR-301-Gremium allerdings vor ein Problem: Die Spezifikation benötigt in der ersten Version zwei verschiedene Releases für Portlet 1.0 und Portlet 2.0. Das ist aber nach den Regeln des JCP (Java Community Process) nicht möglich. Daher gibt es nun einen weiteren JSR, um auch das Thema Portlet 2.0 und JSF 1.2 zu verbinden. Der bisher lediglich eingereichte aber noch nicht offiziell akzeptierte JSR 329 wird durch Apache und auch seitens Oracles unterstützt, sodass zum Zeitpunkt der Erstellung dieser Kolumne davon ausgegangen werden darf, dass dieser JSR in Zukunft offiziell werden wird. Die RI dieses neuen JSR wird ebenfalls innerhalb von Apache MyFaces (myfacesBridge) vorgenommen. Nun mag der Eindruck entstanden sein, dass man mit den beiden JSF Portlet Bridge JSRs derzeit noch nicht viel anfangen kann. Das ist jedoch falsch. Für die RI des JSR 301, also JSF 1.2 und Portlet 1.0, gibt es bereits einen Betarelease, und auch für die neue Spezifikation gibt es innerhalb von MyFaces bereits einen Alpharelease.

JSF-Anwendung als Portlet

Mit JSF ist die Entwicklung von Portlets schon heute sehr angenehm, hat man sich für einen Container entschieden. Ein einheitlicher Standard für alle Container und Versionen der Spezifikationen baut diese Möglichkeit jedoch weiter aus. Vereinfacht gesagt ist die Idee hinter der „Brücke“, dass eine bestehende JSF-Anwendung mithilfe einer speziellen XML-Datei (portlet.xml) ausgestattet wird, um sie innerhalb eines Portlets zu installieren. Das Portal selbst bietet neue Möglichkeiten, um diese Anwendung weiter auszubauen. Ein Beispiel wären spezielle Views für die Unterschiedlichen Modi (VIEW, EDIT und HELP) des Portlets, innerhalb der portlet.xml:

<init-param> <name>javax.portlet.faces.defaultViewId.view</name> <value>/index.jspx</value> </init-param> <init-param> <name>javax.portlet.faces.defaltViewId.edit</name> <value>/edit.jspx</value> </init-param> 

Diese beiden JSPX-Dateien stellen ganz gewöhnliche JSF-Views dar. Keine dieser Dateien benötigt spezielle Behandlung für die Bereitstellung als Portlet. Die interessante Eigenschaft ist hier, dass die Portlet Modes für die defaultView, so wie die Startseite der Applikation ebenfalls mit JSF-Komponenten beschrieben werden kann. Es besteht also kein Grund mehr, Portlets im Stil von Java Servlets zu erstellen.

Ausblick

Innerhalb von Apache MyFaces gibt es bereits eine simple Beispielanwendung, die die Standardkomponenten unterstütz. Die Apache-Trinidad-Bibliothek 1.2.x funktioniert derzeit noch nicht zu 100 %, aber daran wird seitens der Trinidad-Entwickler gearbeitet. Generell muss jede JSF-Bibliothek ein wenig an Arbeit leisten, um diesen neuen Standard zu unterstützen.

Kommentare

Schreibe einen Kommentar

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