02_03_01_JakartaFaces: Einleitung - BjoernWitt/JavaTutorial GitHub Wiki
Jakarta Faces ist ein Model-View-Controller Framework. Der Zweck von Jakarta Faces ist es, auf einfache Art und Weise, wieder verwertbare Komponenten für Benutzerschnittstellen (User Interfaces) in Webseiten oder Webanwendungen bereit zu stellen. Zielführend sind hierfür nachfolgende Framework Features:
- User Interface Komponenten
- State Management
- Event Handling
- Eingabevalidierungen
- Web-Seiten Navigation und
- Unterstützung für I18N und Zugriffssteuerung.
Die Historie der Jakarta Faces geht bis 2001 zurück. Seit dem wurde es kontinuierlich weiter entwickelt und ist seit vielen Jahren hoch stabil und weit verbreitet.
Im Prinzip parst Jakarta Faces die für eine Webanwendung entworfenen User Interface Definitionen und erstellt daraus in Java eine Komponenten basierte Baumstruktur. Üblicherweise werden diese UI-Definitionen durch sogenannte Facelets mit Jakarta Tags in Dateien mit XHTML+XML Notation erstellt. Diese Komponenten Baustruktur kann aber auch direkt durch Java angesprochen (und ggf. erstellt) werden, was aber aus Entwicklersicht schnell unübersichtlich werden kann und deshalb nicht zu empfehlen ist.
Im Faces Framework agieren die Java-Servlets als Controller. Über die komponentenbasierte Baustruktur (Component Tree) kommunizieren die Controller mit der View (Facelet). Backing Beans werden von den Controllern aufgerufen, um die Businesslogik auf die Daten im Model anzuwenden. Darüber hinaus ermöglichen die Backing Beans den Zugriff auf die Daten des Models für die View Komponente zur Anzeige und Aktualisierung.
Der Verarbeitungsvorgang eines HTTP-Request an den Server teilt sich für die Jakarta Faces in 6 Phasen auf:
- Restore View
- Apply Request Values
- Process Validation
- Update Model Values
- Invoke Application
- Render Response
Nachfolgende Aufgaben erledigt die Phase Restore View:
- Sicherstellen korrektes Character Encoding
- Sicherstellen Spracheinstellung (Request-Locale)
- Festlegung (bzw. Herleiten/Validieren) der
viewId
- Existiert bereits ein Komponentenbaum im Faces Kontext, wird dieser prinzipiell angewendet. Es wird angenommen, dass dieser Komponentenbaum dem aktuellen Status der Anwendung entspricht.
- Der Komponentenbaum wird jedoch immer (basierend auf den Facelets -> View Definitionen) neu erstellt, wenn:
- ein initialer Request beim Server eingeht (Es existiert kein Komponentenbaum im Faces Kontext),
- ein Postback-Request (Ausnahme: servlet error page) beim Server eingeht, oder
- wenn innerhalb einer View <f:metadata> Information enthalten sind.
- Sicherstellen, dass für jeden Knoten in dem Komponentenbaum die Aktion
PostRestoreStateEvent
ausgeführt wird. - Existiert am Ende der Phase ein leerer Komponentenbaum, dann werden alle Phasen übersprungen und die Phase 6 wird direkt ausgeführt.
Der Zweck dieser Phase ist es, jeder Komponente im Komponentenbaum, die Möglichkeit zur Aktualisierung ihres Zustandes, in Bezug auf die Information (parameters, headers, cookies, etc.) aus dem aktuellen Request, zu geben. Wird eine Komponente aktualisiert, so wird dieser neue Zustand "lokaler Wert" genannt.
Die Methode UIComponent#processDecodes()
wird im UIViewRoot
aufgerufen. Diese Methode ruft zuerst für alle child und facet die Methode processDecode()
auf und anschließend die eigene Methode UIComponent#decode()
. Abschließend wird die wird die Methode UIViewRoot#broadcastEvents()
ausgeführt, durch die alle zu dieser Phase vorgesehenen Aktionen in der FacesEvent
Queue auslöst/getriggert werden.