Jakarta Faces

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Jakarta Faces

Basisdaten

Entwickler Eclipse Foundation[1]
Aktuelle Version 4.0
Betriebssystem plattformunabhängig
Programmier­sprache Java
Kategorie Framework
Lizenz Eclipse Public License 2.0, GPL linking exception
jakarta.ee/specifications/faces/

Jakarta Faces (JSF; früher Jakarta Server Faces, davor JavaServer Faces) ist ein Framework-Standard zur Entwicklung von grafischen Benutzeroberflächen für Webanwendungen. Basierend auf Servlets und JSP-Technik, gehört JSF zu den Webtechnologien der Jakarta EE. Mit Hilfe von JSF kann der Entwickler auf einfache Art und Weise Komponenten für Benutzerschnittstellen in Webseiten einbinden und die Navigation definieren. Voraussetzungen für die Entwicklung von JSF-Content sind das JDK, ein Servlet-Container (z. B. Apache Tomcat) und Grundlagenverständnis von HTTP und der Programmiersprache Java. Zur Vereinfachung der Entwicklung kann eine Integrierte Entwicklungsumgebung verwendet werden.

Komponenten

[Bearbeiten | Quelltext bearbeiten]

Um Redundanzen im Code zu vermindern und die Wiederverwendbarkeit des UI Codes über mehrere Projekte zu verbessern, können Komponenten erstellt und verwendet werden. JSF-Komponenten unterliegen einer hierarchischen Struktur. Ähnlich der Java-Swing-API gibt es in JSF Container-Komponenten, die Komponenten enthalten können. Um die Anwendung besser zu strukturieren, wird strikt zwischen Modell, Präsentation und Steuerung getrennt, wie es das Model-View-Controller-Konzept vorsieht.

Ein zentrales Konzept von Jakarta Server Faces ist die View. Dabei handelt es sich um eine Baumstruktur aus JSF-Komponenten. Eine solche Struktur kommt genau einmal pro Aufruf vor, bei Verwendung von JavaServer Pages (JSP) also einmal pro Seite. Die View wird am Anfang des JSF-Lebenszyklus aufgebaut, direkt nach Eintreffen der Anforderung vom Client. In der letzten Phase des Lebenszyklus werden die Komponenten der Views mit der Wurzel beginnend rekursiv aufgerufen, um die Antwort, beispielsweise eine HTML-Seite, zu erzeugen. Die Controller-Komponente, welche Benutzereingaben steuert, kann in JSF über eigene Komponenten oder mit einem sogenannten Handler implementiert werden. Diese sind meist mit Java geschrieben. Die eigentliche Logik der Applikation findet im Model statt. Bei JSF sind die Model-Komponenten sogenannte JavaBeans (Java-Klassen), die vom Container verwaltet werden. JSF-Web-Anwendungen besitzen in der Regel keinen nennenswerten HTML-Code. Der HTML-Code wird erst im Quellcode der generierten Seite sichtbar. JSF-Komponenten besitzen eigene Renderer. Diese Renderer wandeln die mit JSF geschriebenen Seiten in HTML-Code um, so dass jeder HTML-Web-Browser die Seite darstellen kann. Eigene Renderer können für andere Ausgabeformate geschrieben werden.

Lebenszyklus

[Bearbeiten | Quelltext bearbeiten]
Diagramm des Lebenszyklus von Jakarta Server Faces

Die Spezifikation der Jakarta Server Faces definiert einen sogenannten Lebenszyklus, den eine JSF-Anwendung mit jedem Aufruf erneut durchläuft. Dieser Lebenszyklus ist in sechs Phasen aufgeteilt.

  1. Restore View („Sicht wiederherstellen“) wählt anhand der eingehenden Anforderung eine Sicht (View) aus und baut den dazu passenden Komponentenbaum auf.
  2. Apply Request Values („Anforderungsparameter anwenden“) extrahiert Parameter aus der Anforderung (üblicherweise ein HTTP-Post-Request) und weist sie den passenden JSF-Komponenten zu, beispielsweise Eingabefeldern.
  3. Process Validations („Validierung ausführen“) überprüft die Gültigkeit der zuvor ermittelten Eingaben. Dazu werden eigene Konverter- und Validator-Objekte verwendet, die den Komponenten in der View-Definition zugewiesen wurden.
  4. Update Model Values („Modell aktualisieren“) weist den Modellobjekten die zuvor ermittelten Werte zu.
  5. Invoke Application („Anwendung aufrufen“) ruft durch die Anwendung definierte Methoden auf, beispielsweise wenn ein Button betätigt wurde.
  6. Render Response („Antwort wiedergeben“) erzeugt schließlich die Antwort auf die ursprüngliche Anfrage, beispielsweise eine HTML-Seite. Hierzu werden sogenannte Renderer aufgerufen, die den View-Komponenten zugeordnet sind.

Treten Fehler auf oder soll als Antwort beispielsweise eine HTML-Seite aufgerufen werden, die keine JSF-Komponenten enthält, so können einzelne Phasen übersprungen werden.

Implementierungen

[Bearbeiten | Quelltext bearbeiten]

Die JSF-Spezifikation wird von einer Reihe Frameworks implementiert. Diese werden meist in JEE-Containern mitgeliefert und lassen sich oft nur unter Schwierigkeiten austauschen. Dazu gehören beispielsweise:

Komponentenframeworks

[Bearbeiten | Quelltext bearbeiten]

Komponentenframeworks erweitern JSF-Implementierungen. Mit ihnen können beispielsweise JavaScript und Ajax einfacher generiert werden.

Verschiedene Unternehmen bieten auch grafische Entwicklungswerkzeuge für JSF an.

Standardisierung

[Bearbeiten | Quelltext bearbeiten]

Die JSF-Spezifikation wurde im Rahmen des Java Community Process (JSR 127) von einer Reihe bekannter Unternehmen entwickelt und am 27. Mai 2004 in der Version 1.1 verabschiedet. Am 11. Mai 2006 wurde die Version 1.2 (JSR 252) veröffentlicht. Die aktuelle Version der Referenzimplementierung Mojarra 1.2_15 erschien am 24. September 2010.[5]

Die Version 2.0 (JSR 314) brachte insbesondere Ajax-Unterstützung mit sich. Sie ist seit Dezember 2009 erhältlich und kann auf der Oracle-Homepage heruntergeladen werden. Eine Implementierung sowie ein Tutorial und weitere Dokumentation stehen im Mojarra Project zur Ansicht und zum Download bereit, die derzeitige Version der Mojarra Referenzimplementierung lautet 2.0.8.[6] Bei JSF 2.1 handelt es sich um einen Wartungsrelease von Version 2.0, freigegeben wurde die Spezifikation am 21. November 2010[7], die aktuelle Version der Mojarra Referenzimplementierung lautet 2.1.6.[6] Die Version JSF 2.2 wurde am 15. April 2013 freigegeben.[8] Sie enthält insbesondere folgende Neuerungen: Unterstützungen für HTML5 wie beispielsweise das Durchreichen von neuen HTML5 Attributen beziehungsweise Custom Data Attributen, Erweiterte Flow Unterstützung durch einen eigenen Contexts and Dependency Injection Scope (@FlowScoped) ergänzend zum bereits existierenden ConversationScope (@ConversationScoped), Zustandslose Views durch Setzen des Attributes transient="true", sowie Resource Library Contracts, ein erster Ansatz um Ressourcen für wählbares Aussehen zur Verfügung zu stellen.[9]

Jakarta Server Faces umfasst

Der Hauptunterschied zur JSP-EL liegt nicht nur an dem vorangestellten #, sondern auch in der Sprache selbst. Die JavaServer Pages-Expression Language ist dynamischer als die JSF-Expression Language (JSF-EL). Die JSF-EL ist zustandsbehafteter (statischer), vergleichbar mit den Java-Swing-Komponenten. Die Expression Language von JSF hat eine bidirektionale Wertebindung, d. h., sie kann Properties (Eigenschaften einer Bean) lesen (z. B. Initialisierung) und schreiben (z. B. Werte an Property binden). Folgende Tabelle zeigt Ausdrucksarten der Expression Language von JSF:

Expression Language Ausdruck Beispiel
Wertebindung #{handler.name} – name ist eine Eigenschaft der handler-Bean
Methodenbindung #{handler.actionMethode} – actionMethode ist eine Methode der handler-Bean
Arithmetisch / Logisch #{5+8}, #{65/5}, #{99>90}, #{!(5>6)||(8<4)}

Bei der Entwicklung von JSF-Seiten sollte auf die Kombination von JSP- und JSF-Ausdrücken verzichtet werden, da das zu Problemen führen kann.

Managed Bean Mechanismus

[Bearbeiten | Quelltext bearbeiten]

Der Managed Bean Mechanismus erlaubt es, POJOs mit einem bestimmten Gültigkeitsbereich (englisch scope) und Initialwerten für sogenannte Managed Properties (auch im Spezialfall, dass das Bean vom Typ java.util.List oder java.util.Map ist), zu versehen. Dies kann entweder in der XML-Konfiguration der JSF-Applikation oder ab JSF 2.0 (min. Java Version 1.5) als zusätzliche Option mit Annotations direkt im Bean konfiguriert werden. Managed Beans können mit der Hilfe von EL-Ausdrücken direkt (z. B. in Facelets) verwendet werden.

Gültigkeitsbereiche von Managed Beans (engl. scope)

[Bearbeiten | Quelltext bearbeiten]

Der Gültigkeitsbereich einer Bean legt fest, wie lange eine Bean existiert und unter welchen Umständen sie als existent angesehen wird. Wie bereits erwähnt, können Managed Beans mit Managed Properties in andere Managed Beans injiziert werden. Dabei ist zu beachten, dass die injizierte Bean einen größeren Gültigkeitsbereich hat als die Bean, in die sie injiziert wird. Der Grund dafür ist, dass die injizierte Bean andernfalls potenziell kurzlebiger ist als die Bean, in welche sie injiziert wird.

Folgende Tabelle zeigt alle Gültigkeitsbereiche in der aktuellen JSF-Version (2.1) sortiert nach der Größe des Gültigkeitsbereichs mit dem kurzlebigsten Scope zu oberst.

Wert XML <managed-bean-scope> Annotation Gültigkeitsbereich
request @RequestScoped gültig, solange der aktuelle Request behandelt wird
view @ViewScoped gültig, solange die aktuelle View gültig ist
session @SessionScoped gültig für eine Session
application @ApplicationScoped gültig für die Applikation
none @NoneScoped gültig wie die Bean, in welche sie injiziert wurde

JSF-Standard Tags (nicht vollständig)

[Bearbeiten | Quelltext bearbeiten]
Tag-Name Beschreibung
<f:view> Erzeugt Instanz der Klasse javax.faces.component.UIViewRoot. Alle enthaltenen Komponenten werden Child-Komponenten der View.
<h:form> Bindet Eingabekomponenten in ein Formular. Sendet POST-Request per HTTP.
<h:panelGrid> In HTML <table>-Tag. Anzahl der Spalten bestimmt das columns-Attribut
<f:facet> Definiert eine Facette als Kindelement eines Containers (z. B. Überschrift für eine Tabelle)
<h:outputText> Normaler HTML-Text
<h:outputLabel> In HTML <label>-Tag. Kennzeichnung eines Eingabefeldes
<h:panelGroup> Container, der mehrere JSF-Tags zu einem Tag zusammenfügt
<h:inputText> In HTML <input>-Tag mit type="text", value-Attribut bezieht sich auf die Komponenten (z. B. EL-Ausdruck)
<h:inputSecret> In HTML <input>-Tag mit type="password"
<h:commandButton> Button in HTML. <input>-Tag mit type-Attribut (submit, reset, image). Standardmäßig: submit. Sendet Formular ab und löst ActionEvent aus (über Bean-Methode).
<h:message> Gibt die erste Fehlermeldung für die im for-Attribut angegebenen Komponenten aus. ErrorStyle-Attribut kann als CSS-Fehler-Darstellung genutzt werden.

Literatur

[Bearbeiten | Quelltext bearbeiten]
  • Michael Goll: JavaServer Faces: JSF verstehen und praktisch einsetzen. 3. überarbeitete Auflage, Springer Vieweg, 2020, ISBN 978-3-658-31802-4
  • Martin Marinschek u. a.: JavaServer Faces 2.0: Grundlagen und erweiterte Konzepte. dpunkt.verlag, 2009, ISBN 978-3-89864-606-2
  • Bernd Müller: JavaServer Faces 2.0: Ein Arbeitsbuch für die Praxis. Hanser, 2010, ISBN 978-3-446-41992-6
  • Bernd Müller: JavaServer Faces und Jakarta Server Faces 2.3: Ein Arbeitsbuch für die Praxis. Hanser, 2021, ISBN 978-3-446-45670-9
  • Marcel Urbanek: JavaServer Faces: JSF verstehen und praktisch einsetzen. w3l, 2010, ISBN 978-3-86834-003-7
[Bearbeiten | Quelltext bearbeiten]
Commons: Jakarta Faces – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ projects.eclipse.org.
  2. ↑ primefaces.org
  3. ↑ bootsfaces.net
  4. ↑ jboss.org RichFaces, abgerufen am 18. Januar 2011.
  5. ↑ javaserverfaces.java.net Oracle Mojarra JSF Download, abgerufen am 18. Januar 2011.
  6. ↑ a b Oracle Mojarra JavaServer Faces. Abgerufen am 19. Januar 2012.
  7. ↑ Andy Bosch: Was ist neu in JSF 2.1. Abgerufen am 9. Oktober 2011.
  8. ↑ JSR #344 JavaServerTM Faces 2.2 Final Approval Ballot
  9. ↑ What’s new in JSF 2.2?
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Jakarta_Faces&oldid=247539769“