02_03_01_JakartaFaces: Einleitung - BjoernWitt/JavaTutorial GitHub Wiki

JakartaFaces: Einleitung

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.

Komponenten basierte Eigenschaft - Komponenten Baumstruktur

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.

Übersicht Model-View-Controller

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.

image

Lebenszyklus Komponenten Baumstruktur

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

1. Phase: Restore View

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.

2. Phase: Apply Request Values

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.

3. Phase: Process Validation

4. Phase: Update Model Values

5. Phase: Invoke Application

6. Phase: Render Response

https://jakarta.ee/specifications/faces/

⚠️ **GitHub.com Fallback** ⚠️