Java Server Faces

Mit dem Java Server Faces API sollen die folgenden Ziele erreicht werden:

• Definieren eines Standards für GUI Frameworks, für den (graphische) Entwicklungswerkzeuge geschaffen werden können.
• Der Standard soll leichtgewichtige Java Klassen für die GUI Komponenten, deren Zustand und Events festlegen.
• Es sollen Klassen bereitgestellt werden, die die gängigen GUI Komponenten, inclusive der HTML Eingabekomponenten, repräsentieren.
• Es soll ein auf Java Beans basierendes Modell für das Weiterleiten von GUI Events an die serverseitige Businesslogik definiert werden.
• Es sollen APIs für die Eingabevalidierung (auch auf der Clientseite) enthalten sein.
• Internationalisierung und Lokalisierung soll unterstützt werden.
• Die an den Client zu sendenden Ausgaben sollen automatisch generiert werden, dabei sollen die Möglichkeiten des Clients berücksichtigt werden.


Java Server Faces basieren auf den grundlegenderen Technologien Java Server Pages Standard Tag Library, Java Server Pages, Java Servlet und Java Beans.

Der zentrale Ansatz der Java Server Faces besteht darin, das User Interface aus wiederverwendbaren GUI Komponenten aufzubauen. Unter anderem sind folgende Komponententypen verfügbar:

• UIData (Tabelle),
• UIColumn (Spalte einer Tabelle),
• UIOutput (Ausgabefeld),
• UIGraphic (Grafikausgabe),
• UIForm (Formular),
• UIInput (Eingabefeld),
• UISelectBoolean (Checkbox),
• UISelectOne (Dropdown),
• UISelectMany (Listbox),
• UISelectItem (Eintrag in einer Listbox oder einem Dropdown),
• UICommand (Button oder Link).


Den Java Server Faces liegt ein Request-Response basiertes Verarbeitungsmodell mit mehreren Verarbeitungsphasen zugrunde. Die Datenfluss zwischen den Phasen wird durch einen FacesContext erreicht. Für jeden Request gibt es ein derartiges Objekt.

Nach dem Eintreffen eines Requests beginnt die Verarbeitung mit der Phase Restore View. Diese Phase bestimmt den View und speichert ihn im FacesContext ab. Der View ist eine hierarchische Struktur aus GUI Komponenten.

Anschließend gibt die Apply Request Values Phase den Komponenten aus dem View die Möglichkeit, ihren Zustand (Wert) anhand der Argumente aus dem Request zu ändern. Das Ändern eines Werts kann dazu führen, dass Events erzeugt und für die spätere Verarbeitung gespeichert werden.

Die folgende Process Validations Phase führt Validierungen aus, die nicht bereits in der Apply Request Values Phase durchgeführt wurden. Gegebenenfalls werden Fehlermeldungen im FacesContext gespeichert.

Die Update Model Values Phase sorgt dafür, dass Zustandsänderungen der Komponenten an das Datenmodell weitergegeben werden.

Die Invoke Application Phase führt Business Logik aus. Zum Beispiel kann in dieser Phase der NavigationHandler mit der Methode ViewHandler.createView einen neuen View erzeugen, dessen Zustand setzen und den View dann im FacesContext speichern.

Die Render Response Phase sorgt dafür, dass die Response für den Client erzeugt wird. Zusätzlich wird Struktur und Zustand des Views gespeichert, damit er bei nachfolgende Requests in der selben Session in der Phase Restore View wiederhergestellt werden kann.

In diversen Phasen der Verarbeitung können Events erzeugt werden, diese werden zunächst zwischengespeichert. Events können für die Verarbeitung in einer spezifischen Phase markiert werden. Nachdem die oben beschriebenen Regeltätigkeiten einer Phase abgeschlossen sind, werden die für diese Phase vorgemerkten Events in der Reihenfolge der Zwischenspeicherung den Listenern zugestellt. Die Verarbeitung der Events nach den Regeltätigkeiten einer Phase hat den Zweck, dass die Listener auf einen konsistenten Zustand des Views zugreifen können.

Die Listener können die Methode renderResponse des FacesContexts aufrufen. Das führt dazu, dass sich nach dem Abschluss der aktuellen Phase auf jeden Fall die Phase Render Response anschließt. Ein Aufruf von responseComplete bricht die Verarbeitung ab, ohne dass Ausgaben vom Java Server Faces Framework erzeugt werden.


Quelle

http://www.jcp.org/en/jsr/detail?id=127