Konzept

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

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.

Die Daten für die Visualisierung in JSF werden in Model Beans gehalten. Hierfür wird nicht auf den durch JSF zur Verfügung gestellten Mechanismus der Managed Beans zurückgegriffen. Das Datenmodell wird über Spring Web Flow direkt aus Model Beans verfügbar gemacht. Damit ist die Verwaltung des Models unter Kontrolle des Dialogflusses, der über Spring Web Flow gesteuert wird. Die einem Flow zugeordneten Model Beans werden durch den Flow instanziiert und unterliegen somit dem Flow-Lebenszyklus.

Mit den Facelets werden das visuelle Layout und die Controls für die Ansicht im Browser definiert. Durch die Nähe zu HTML sind schnell die notwendigen Ansichten designt und können getestet werden. Das Mapping der Controls auf die Daten geschieht über die in JSF verwendete Expression Language (EL). Mit der EL werden direkt die Attribute des zugehörigen Beans genutzt.

Ein weiterer Vorteil von Facelets ist die Verwendung von Templates. Durch diese ist es möglich, bereits einen zum Bedienkonzept konformen Rahmen zur Verfügung zu stellen, in welchen die Applikation lediglich durch definierte Einfügungen ihre Inhalte einbetten.

Durch den Einsatz von Facelets ist die direkte Einbettung von Tag Libraries nicht möglich. Vielmehr müssen diese noch separat mit einer Deskription versehen werden, aus welcher die einzelnen Tags ersichtlich sind und ihr Mapping auf die zugehörigen Klassen definiert ist.

Für den Einsatz der myFaces Tomahawk Library wird eine entsprechende Konfiguration zur Verfügung gestellt. Der Einsatz dieser Library unterliegt für den Einsatz in der IsyFact der allgemeinen Einschränkung bei der Verwendung von JavaScript (siehe auch Benötigte Bibliotheken in den Nutzungsvorgaben).

Ein Flow kann wahlweise als XML-Datei oder mittels der Java-API realisiert werden. Ein Flow besteht in der Regel aus mehreren Zuständen (innerhalb von Web Flow als States bezeichnet), die nacheinander und in Abhängigkeit von der jeweiligen Benutzerinteraktion durchlaufen werden.

Auch die Modularisierung von Flows in kleine Einheiten ist durch sogenannte Subflows bzw. Inline-Flows ohne weiteres möglich. Ein Subflow wird wie jede andere Flow-Definition erstellt. Der Unterschied zu einem normalen Flow liegt lediglich darin, dass der Subflow innerhalb eines Flows aufgerufen wird. Eine Flow-Definition kann beliebig viele Subflows enthalten, welche wiederum weitere Subflows aufrufen können.

Während der Ausführung von Flows werden die Variablen mit einer Zwischenspeicherung in das Repository geschrieben. Hierbei wird immer, wenn ein Flow durch eine User-Interaktion unterbrochen wird, der aktuelle Status gespeichert. Das Repository liefert diesen bei der Fortsetzung des Flows zurück. Der dafür notwendige „Flow-Execution-Key“, der Schlüssel, der zur Identifikation des aktuellen Flow-Status dient, wird hierbei von Spring Web Flow erzeugt.

Dieses Speichern des Status von vorhergehenden Schritten im Flow unterstützt so in Kombination mit einem „Post Redirect Get“ Mechanismus (PRG-Pattern) die Nutzung des Back-Buttons im Browser. Da jeder Request im Flow einen eindeutigen Execution Key an den Server sendet, kann, wenn man im Flow zurückgeht, auch der alte Status zum Zeitpunkt dieses Request angezeigt werden, selbst wenn der Server von dem Click auf den Back-Button selbst nichts mitbekommt.

Jede GUI-Komponente wird durch einen Flow beschrieben. Dieser definiert das Zustandsmodell der Komponente und hat die Funktion des zentralen Controllers für diese Komponente. Er erfüllt die folgenden Aufgaben:

Der Flow-Aufbau wird so gestaltet, dass im Flow alle Zustände, Zustandsübergänge sowie Aufrufe von Verarbeitungslogik zentral gebündelt werden und Ablauf und Verhalten des Flows für den Entwickler klar nachvollziehbar sind.

Der Flow wird als XML-Datei im Ordner der Komponente hinterlegt.

Das Controller-Bean ist ein vom Komponenten-Flow aufzurufendes zustandsloses Spring Bean, welches Änderungen an den Daten des Models vornimmt oder diese aufbereitet bzw. Services des Anwendungskern-Wrappers aufruft. Das Model Bean wird dem Controller mit jedem Aufruf übergeben.

Das Controller-Bean wird im Spring IoC-Container mit Singleton Scope erzeugt und konfiguriert.

Das Controller-Bean wird vom Flow per Expression-Language aufgerufen. In bestimmten Fällen (siehe Abschnitt Views) wird ein Controller-Bean auch in einer Action (oder ActionListener) des Komponenten-View aufgerufen.

Das Model Bean ist ein Datenobjekt (einfaches POJO) und hält die Daten einer GUI-Komponente. Es hat keine Abhängigkeiten zu View, Controller oder Anwendungskern und enthält im Regelfall keine Logik. Das Model Bean wird durch den Flow erzeugt (durch Definition einer Web-Flow-Variablen) und ist somit automatisch im View sichtbar.

Der View liest die Daten zur Präsentation der Webseite aus dem Model Bean. Dies können Informationen zur Ansicht aber auch änderbare Formularinhalte sein. Werden Formularinhalte in Form eines Post-Requests auf den Server gesendet, so sorgt JSF eigenständig dafür, dass die Formularinhalte in das Model Bean rückübertragen werden.

Da das Model Bean durch den Flow erzeugt wird und Flow Scope besitzt, wird es automatisch mit in die Session-Persistierung einbezogen. Dazu muss das Model das Interface Serializable implementieren. Die Daten des Models werden bei den Dialogschritten eines Flows zwischen Client (Browser) und Server transparent für den Entwickler abgeglichen.

Das Model Bean ist nicht mit den JPA-Datenobjekten verbunden. Das Schreiben in das Model bewirkt also zunächst keine Änderung in der Datenbank. Die Persistenz fachlicher Datenobjekte wird über das Controller-Bean ausgelöst, welches über Methodenaufrufe des Anwendungskern-Wrappers fachliche Daten persistiert.

Der Abgleich von Model Beans mit einer View und das Abspeichern der Daten einer Model Bean wird im Kapitel "Erstellung der Models" in Nutzungsvorgaben JSF genauer beschrieben.

Der Komponenten-View präsentiert die Daten der Anwendung in Form von generierten HTML-Seiten. Dazu werden ein oder mehrere Facelets verwendet, die mittels JSF-HTML-Tags auf das Model Bean der Komponente zugreifen, um die Daten in den View einzubinden. Da das Model Bean seine Datenzugriffsmethoden nach dem Bean-Standard (get/set/is) anbietet, kann mittels Value-Expressions (z.B. #{teilnehmenModel.terminfindung.tage}) direkt auf Eigenschaften des Model Beans und enthaltener Objekte zugegriffen werden. Ein View kann auch auf mehrere zum Flow gehörende Model Beans zugreifen.

Im View können Actions definiert sein (z.B. Submit durch einen Command-Button). Dabei werden nur Action-Tokens (String, der die Aktion benennt) übergeben, die dann im Flow entgegengenommen werden und dann Methodenaufrufe auf dem Controller auslösen.

Die View-Erstellung wird im Kapitel "Erstellung der Views" in Nutzungsvorgaben JSF genauer beschrieben.

Wie in Aufbau der GUI-Komponente beschrieben, müssen die Dialog-Komponenten voneinander gekapselt sein. Wenn zwei Dialog-Komponenten Informationen austauschen müssen, darf dies nicht über ein gemeinsam genutztes UI-Model geschehen. Der Austausch von Informationen erfolgt stattdessen über Input/Output-Elemente im Flow, die aus dem Model einer Dialog-Komponente gelesen oder geschrieben werden.

Ist ein Subflow B mit Daten aus dem aufrufenden Flow A zu versorgen, so bekommt dieser nicht das Model A, sondern eine Kopie eines einzelnen Objekts aus Model A übergeben. Dies kann auch eine Datenstruktur, darf aber niemals das gesamte Model A sein. Es ist wichtig, dass eine Kopie übergeben wird, damit Flow B nicht Teile des Models A absichtlich oder versehentlich ändert.

Besteht Bedarf, dass ein Subflow B an den aufrufenden Flow A Daten zurückgibt, so erfolgt dies über ein Output-Element. Hier gilt analog, dass nicht das gesamte Model B, sondern lediglich Kopien eines Teils des Models übergeben werden.

Das folgende Beispiel zeigt wie ein Flow an einen Subflow Parameter übergibt und von diesem einen Ausgabewert empfängt.

Innerhalb des Subflows werden übergebene Parameter entgegengenommen und verarbeitet. Im Endzustand wird ein Rückgabewert zurückgegeben.

Zur Datenübergabe können auch mehrere Input- und mehrere Output-Elemente verwendet werden.

Für die Steuerung des Vorgabelayouts (z.B. Menüleiste, Linksnavigation, Hilfezugriff) sowie der Nutzung von vorgegebenen Funktionen (z.B. Validierung) werden querschnittliche Controller mit zugehörigen Models verwendet. Die Instanziierung übernimmt dabei ein übergeordneter Parent-Flow. So kann z.B. die Seitentoolbar konfiguriert oder ein Quicklink hinzugefügt werden.

Der Aufruf dieser Controller ist generell erlaubt. Die Controller sind als Spring Beans global verfügbar. Welche Controller im Detail (LinksnavigationController, QuicklinksController, ValidierungsController, …​) für das Vorgabelayout verfügbar sind, wird im Dokument Nutzungsvorgaben JSF beschrieben.

Für die Arbeit mit JSF werden gemäß dem Bedienkonzept sowohl Seitenelemente als auch Bedienelemente bereitgestellt. Seitenelemente helfen, den Seitenrahmen aufzubauen und erleichtern so einen zum Bedienkonzept konformen Aufbau der Masken. Bedienelemente helfen, die Masken selbst zu strukturieren und bieten vorgefertigte Widgets zur Anzeige und Eingabe von Daten. Daneben gibt es noch einige spezielle Komponenten, z.B. um den Fokus beim Laden der Maske zu setzen oder eine Druckansicht bereitzustellen.

Die Bedienelemente sind alle als JSF Composite Components realisiert. Dadurch ist eine einfachere Wartung möglich, da die Komponenten vollständig in XHTML definiert sind und ein Grundverständnis von JSF genügt, um Anpassungen vorzunehmen. Spezielle Renderer oder Java-Klassen werden nicht benötigt.

Die Nutzung der durch das Bedienkonzept definierten Elemente und durch den Baustein bereitgestellten JSF-Komponenten ist ein zentrales Thema der Nutzungsvorgaben JSF.

Die Absicherung von Masken erfolgt auf Ebene des Dialogablaufs über Spring Web Flow. Die Berechtigungsprüfung verwendet dabei den Baustein Security.

Für die Anbindung von Spring Web Flow an den Baustein Security wird das Spring Security-Interface AccessDecisionManager durch die Klasse WebDelegatingAccessDecisionManager implementiert. In der Implementierung wird mittels einer Abfrage an Berechtigungsmanager aus dem Security-Baustein geprüft, ob ein Anwender die notwendigen Berechtigungen besitzt (siehe dazu Nutzungsvorgaben Security).

Bei einem Cross-Site Request Forgery (CSRF) Angriff versuchen die Angreifer einem angemeldeten Benutzer einen HTTP-basierten Request unterzuschieben. Mithilfe der Session des Benutzers kann der Angreifer so Änderungen am System ausführen.

Weitere Details zur Konfiguration des CSRF-Schutzes stehen in Nutzungsvorgaben JSF.

JSF bietet mehrere Möglichkeiten, einen Parameter in Abhängigkeit eines geklickten Buttons oder Links an die Web-Anwendung zu übergeben. Dies ist beispielsweise dann notwendig, wenn auf einer Maske mehrere Elemente angezeigt werden, zu denen jeweils ein eigener Button zum Bearbeiten existiert. In diesem Fall muss es möglich sein zu erkennen, welcher Button zu welchem Element geklickt worden ist.

Die hierfür in JSF 2.x vorgesehenen Lösung mit f:param erfordert den Einsatz von JavaScript und kann daher Probleme in der Abwärtskompatibilität hervorbringen (z.B. wenn kein JavaScript aktiviert ist). Die Umsetzung sollte daher in der Regel mit einem Action Listener stattfinden (siehe Verwendung eines Action Listeners (View)):

Dabei kann in der Methode waehleSachverhalt der Wert des Attributs aus der RequestParameterMap des FacesContext gelesen werden (siehe Auswertung von Request Attributen).

Als Alternative zum Einsatz eines Action Listeners kann die ID des Buttons/Links parametrisiert und im Controller ausgewertet werden. Die Parametrisierung der ID wird ebenfalls in Verwendung eines Action Listeners (View) dargestellt. Die Auswertung ist in diesem Fall aufwendiger, da alle Attribute der RequestParameterMap durchlaufen werden müssen, bis ein Parameter gefunden wurde, dessen ID mit bearbeite_SV_ beginnt. Vorteil der Lösung ist jedoch, dass Probleme mit dem Einsatz von Action Listenern damit umgangen werden.

Aufgrund einer Eigenart von JSF in Zusammenhang mit dem Partial-State-Saving muss unbedingt darauf geachtet werden, dass die Komponente (Button/Link), an die der Action Listener gebunden ist, nicht durch den Klick ausgeblendet wird. Andernfalls führt dies zu Problemen mit dem Loadbalancing. Hintergrund ist, dass JSF durch das Partial-State-Saving den Zustand der Maske teilweise in der Session ablegt. Werden die Anfragen an die Web-Anwendung durch den Loadbalancer an verschiedene Server verteilt, kann dies daher dazu führen, dass JSF einen Fehler anzeigt, weil der Action Listener der ausgeblendeten Komponente nicht gefunden werden konnte.

JSF-Konverter dürfen sowohl zur Konvertierung aus dem Model zur View (Darstellung) als auch aus der View zum Model (Eingabe) verwendet werden. Standard-JSF-Konverter bieten sich jedoch nur bedingt an, da diese bei der Konvertierung „freier Eingaben“ nicht mit Fehleingaben umgehen können.

Wenn die Validierung in einem Standard-JSF-Konverter stattfindet, werden die Daten in einem Fehlerfall nicht ins Modell geschrieben. Dies führt dazu, dass das Formular zurückgesetzt wird, weil die Seite wegen des Post/Redirect/Get-Patterns mit einem GET-Request mit dem alten Modell neu geladen wird. Die ungültigen Eingaben gehen also zusammen mit allen anderen Änderungen im Modell verloren. Standard-JSF-Konverter sind in diesen Fällen faktisch nicht nutzbar.

JSF-Konverter müssen, um geeignet zu sein, auch ungültige Daten ins Model schreiben können. Wenn dies aufgrund der Nutzung spezieller Datentypen (wie z.B. Datums- und Zeittypen) nicht möglich ist, muss im Model der Datentyp der Eingabe (in der Regel Zeichenketten) verwendet werden. Die Konvertierung findet in diesem Fall nicht durch einen Konverter statt, sondern erst während oder nach der Validierung an der Schnittstelle zum Anwendungskern.

Die Validierung und Prüfung der in der GUI erfassten Daten soll entweder vollständig durch die GUI oder aber vollständig im Anwendungskern durchgeführt werden. Die Validierung in der GUI ist dabei bevorzugt. In diesem Falle wird der Validierungsmechanismus von Spring Web Flow verwendet (s. Abschnitt 5.10 in der Dokumentation des JavaServer Faces, Spring Web Flows). Standard-JSF-Validatoren oder -Konverter sollten für die Validierung aus den im Abschnitt Konvertierung von Daten zur Darstellung und Eingabe genannten Gründen nicht verwendet werden.

Clientseitige Validierung ist erlaubt und darf zur Verbesserung der Benutzbarkeit verwendet werden. Da JavaScript deaktivierbar und manipulierbar ist, müssen grundsätzlich alle clientseitigen Validierungen auf dem Server erneut erfolgen.

Ist JavaScript in einem Browser aktiviert, eröffnet dies gewisse Risiken bei der Verarbeitung schützenswerter Informationen. Folgende Maßnahmen reduzieren jedoch das Risiko möglicher Attacken für Cross-site-Scripting (XSS):

Für die Arbeit mit Spring Web Flow ist es notwendig, die in der Session notwendigen Daten der Conversation für jeden Schritt bereitzustellen und nach jedem Schritt abzulegen. Hierfür werden die Daten in der Datenbank persistiert.

Dies erfolgt über einen eigenen Session-Manager. Als Session-Manager wird die Bibliothek isy-session verwendet, die eine vereinfachte Konfiguration von Spring Session (der eigentlichen Implementierung des Session-Managers) ermöglicht. isy-session kapselt und vereinfacht die Nutzung von Spring-Session.

Weitere Erläuterungen zum Session-Manager finden sich im dazugehörigen Konzept Session Management. Die Einbindung des Session-Managements ist in den Nutzungsvorgaben isy-session beschrieben. Konkrete Anweisungen zum Aufbau des Session-Speichers finden sich in den Nutzungsvorgaben Redis.

Wenn isy-session als Erweiterung der IsyFact nicht eingesetzt wird, muss die Session-Persistierung auf andere Weise durchgeführt werden, wobei sicherzustellen ist, dass die Requests eines Benutzers immer auf die gleiche Instanz gehen (Sticky Sessions). Die Session-Daten müssen dabei möglichst klein gehalten werden, um die Performance der Anwendung nicht zu verschlechtern.

Die Größe der Session wird maßgeblich durch die „im Webflow“ gespeicherten Model-Daten bestimmt. Daher muss darauf geachtet werden, nur unbedingt notwendige Daten im Model zu halten.