Ein Ausblick auf die spannendsten Neuerungen

JSF 2.2 – Quo vadis?

Benjamin Schmeling und Steffen Heinzl

Eine neue Version des Java-Standards für komponentenbasierte Webentwicklung, JavaServer Faces (JSF), steht kurz vor der Veröffentlichung. Es handelt sich hierbei im Gegensatz zur Vorgängerversion 2.1 um ein volles JSR-Release und nicht nur um eine Minor Revision. Deshalb wartet JSF 2.2 nicht nur mit etlichen Bugfixes sondern auch mit jeder Menge interessanter neuer Features auf. Es lohnt sich also schon jetzt, einen genaueren Blick zu wagen.

Die neue Java Enterprise Edition 7 (JSR 342) hat sich zum Ziel gesetzt, das Ausführen von JEE-Applikationen in Cloud-Infrastrukturen zu vereinfachen. Der neue Standard ist für die zweite Hälfte dieses Jahres geplant. Dabei wird es einige größere Versionsupdates bei den jeweils angegliederten Spezifikationen geben. Im Folgenden seien Servlets 3.1 (u. a. Multi-Tenancy für Sicherheitsaspekte, Sessions und Ressourcen), EJB 3.2 (Architekturanpassungen für Platform as a Service, PaaS), JPA 2.1 (u. a. Multi-Tenancy Support), und JSF 2.3 (JSR 344) genannt. Über die Neuerungen in JSF 2.3 ist bislang wenig bekannt. Das Release von JSF 2.2 hingegen rückt immer näher, weswegen sich jetzt schon ein Blick auf die neuen Features lohnt. Natürlich ist, da Version 2.2 planmäßig auch erst Mitte dieses Jahres fertig gestellt werden wird, zum jetzigen Zeitpunkt noch nicht hundertprozentig klar, welche der hier vorgestellten Features letztendlich wirklich Teil der Spezifikation werden. Dennoch zeichnen sich schon einige spannende Neurungen ab, über die wir in diesem Artikel berichten möchten.

View Actions

Ein neues Feature, das sich zuvor als JSF Enhancement im Seam Framework durchgesetzt hat, ist die so genannte View Action. Es handelt sich hierbei um eine Action, die nicht wie sonst über einen commandLink oder commandButton ausgeführt wird, sondern an die View (die Wurzel eines JSF-Komponentenbaums) der JSF-Seite gebunden wird. Dies hat zur Folge, dass die View Action ausgeführt wird, bevor die Seite angezeigt und damit der Komponentenbaum aufgebaut wird. Damit ist es möglich, einerseits zusätzliche Logik vor dem Anzeigen einer Seite auszuführen (was vorher auch schon mit dem <f:event type=“preRenderView“> möglich war), andererseits kann man aber auch, basierend auf einer logischen Bedingung, eine andere als die angeforderte Seite anzeigen. Dies ist zum Beispiel äußerst hilfreich, wenn man eine Zugangsberechtigungsprüfung für einen Nutzer durchführen möchte, um ihn auf eine alternative Seite weiterzuleiten, falls keine Berechtigung vorliegt. Die View Action wird wie gewohnt an eine Methode aus einer ManagedBean gebunden, wobei auch Navigation Rules verwendet werden dürfen. Wie in Listing 1 zu sehen, wird die View Action im <f:metadata>-Tag platziert und ein zusätzlicher viewParam für die User ID verwendet. Der onPostback-Parameter spezifiziert, ob die Action bei jedem Request ausgeführt werden soll (true) oder nur bei Requests, die nicht über JSF gesendet wurden.

Listing 1: Definition einer View Action, die Zugangsberechtigungen prüft

1]. Tabelle 1 zeigt eine Übersicht über JSF-Komponenten, in die andere Komponenten injiziert werden können.

Tabelle 1: Komponenten in JSF 2, in die andere CDI-Komponenten injiziert werden können [2]
Schutz gegen Cross Site Request Forgery

In der neuen JSF-Version gibt es einen zusätzlichen Mechanismus, um eine Seite gegen Cross Site Request Forgery (CSRF/XSRF) zu schützen. Das ist eine Sicherheitslücke, die die Zustandslosigkeit des HTTP-Protokolls ausnutzt, welche es erforderlich macht, Cookies bei jedem HTTP Request mitzuschicken. Ein Angreifer kann sich dies zu Nutze machen, indem er einen HTTP Request in eine fremde Webseite einschleust, z. B. über einen Foreneintrag. Wenn das Opfer nun diese Seite aufruft, wird der Request des Angreifers durch den Browser des Opfers ausgeführt. Dabei schickt der Browser das Cookie automatisch mit dem getätigten Request mit. Der Angreifer könnte also mit fremden Benutzerberechtigungen seinen gewünschten Request ausführen, um beispielsweise einen Foreneintrag im Namen des Opfers zu erstellen. JSF 2.2 schützt vor solchen Attacken, indem es ein Token im ViewState speichert und dieses verschlüsselt in einem hidden-Feld auf Clientseite ablegt. Wird exakt der gleiche Request noch einmal getätigt, wird der mitgeschickte ViewState als abgelaufen gewertet und resultiert damit in einem Fehler.

FaceletFacory im JSF API
Die Integration der Facelets-Templating-Technologie wird in JSF 2.2 weiter vorangetrieben. Die FaceletFactory, die den programmatischen Zugriff auf Facelets ermöglicht und bislang eine interne Komponente war, wird nun über den FactoryFinder wie folgt zugreifbar:

javax.faces.FactoryFinder.getFactory(javax.faces.FactoryFinder. FACELET_FACTORY)

Die FaceletFactory stellt wiederum eine Methode getFacelet() bereit, über die der Zugriff auf eine Facelet-Instanz erlangt werden kann.

Tag Libraries

Eine weitere Neuerung gibt es bei der Erstellung von Komponentenbibliotheken mittels Tag Libraries. Diese Bibliotheken sammeln JSF-Komponenten unter einem gemeinsamen Namensraum. Ein Eintrag in einer Tag Library definiert u. a. den Namen und die Attribute für einen Tag einer JSF-Komponente und bindet die implementierende Java-Klasse daran. Mit der Integration von Facelets in JSF 2 ist es seither auch möglich neue JSF-Komponenten durch die Komposition von vorhandenen Komponenten über XHTML zu definieren. Es war jedoch bislang nicht möglich beide Ansätze in einer Bibliothek unter einem gemeinsamen Namensraum zu publizieren.

Weitere Annotationen

Seit JSF 2 werden Java-Annotationen eingesetzt, um u. a. ManagedBeans zu konfigurieren. Über die Jahre kamen immer mehr Annotationen hinzu, um XML-Konfigurationseinträge in der faces-config.xml bzw. web.xml überflüssig zu machen. In JSF 2.2 kommen weitere Annotationen hinzu, bzw. gibt es Verbesserungen hinsichtlich bereitgestellter sinnvoller Standardwerte. Im Falle der Tag Libraries können Komponenten nun auch per Annotation deklariert werden, was einen Eintrag in der Tag Library überflüssig macht. Dazu wird einfach die @FacesComponent-Annotation für eine Java-Klasse definiert. Die Annotation besitzt drei Attribute: tagName definiert den Namen des Tags, namespace den Namespace des Tags und createTag definiert, ob es sich um einen Tag handelt oder lediglich um eine Komponente. Das Registrieren einer eigenen Resource-Resolver-Klasse, die für das Auffinden von Facelet Templates verantwortlich ist, konnte bislang nur über den Parameter javax.faces.FACELETS_RESOURCE_RESOLVER in der web.xml bewerkstelligt werden. Mit der neuen @FaceletsResourceResolver-Annotation, kann man sich diesen Parameter zukünftig sparen. In JSF 2 gilt das Convention-over-Configuration-Prinzip, d. h. es werden bei Konfigurationen sinnvolle Standardwerte per Konvention zugewiesen. Zum Beispiel erhält eine ManagedBean ohne explizit definiertes name-Attribut automatisch den Klassennamen, wobei der erste Buchstabe klein geschrieben wird. Dieses Prinzip gilt nun auch für Validatoren, Komponenten und Konverter, sodass die Definition des name-Attributs für diese Elemente optional wird.

Multi-Templating

Für JSF 2.2 ist zurzeit geplant, Templates nach dem Vorbild von Joomla zu unterstützen [3]. Zwischen diesen Templates soll live, ohne Neustart des Application Servers, umgeschaltet werden können. JSF-Entwickler können dann z. B. Templates, die von Dritten zur Verfügung gestellt werden, für ihre Anwendung verwenden. Templates könnten so zentral in einer Cloud angeboten werden, damit JSF-Entwickler diese einfach finden können und Template-Entwickler diese einfach für freie sowie kommerzielle Nutzung zur Verfügung stellen können. Eine prototypische Implementierung des Multi-Templating steht unter [4] bereit. Um die Idee des Multi-Templating umzusetzen, müssen einige Konventionen eingehalten werden. Nach momentanem Stand muss eine JSF-Applikation bspw. über einen templates-Ordner verfügen, der die Struktur in Abbildung 1 beinhaltet, wenn sie Multi-Templating unterstützen soll.

Abb. 1: Aufbau eines Templates (aus [3])

Ein Template verfügt dementsprechend über CSS-Dateien, Bilder und eine template.xhtml-Datei, die den Seitenaufbau beschreibt. Die verschiedenen bisher zur Verfügung stehenden Templates haben zumindest zwei ui:inserts, und gemein. D. h. ohne Anpassung der Templates werden auf jeden Fall das Menü und die Inhaltssektion der Seite beim dynamischen Umschalten der Templates berücksichtigt. Andere Templates stellen zusätzlich noch jeweils eine Sektion für header und footer bereit. Neben der template.xhtml wird template.png verwendet, um eine Vorschaugallerie für verschiedene Templates zu ermöglichen, sowie template.xml, um Metadaten über das Template wie Name, Beschreibung, Autor etc. anzugeben.

Um die Auswahl des Templates dynamisch einstellbar zu machen, kann die Variable template in beispielsweise über ui:param gesetzt werden. Die Auswahl des Start-Templates (mit dem Namen rockstar; siehe folgendes Listing) erfolgt über einen Eintrag in der web.xml:

javax.faces.view.TEMPLATErockstar

Über eine weitere Konvention wird für das Menü nachgedacht. Während der Inhaltsbereich weiterhin frei definierbar ist, soll der Menübereich stärker eingeschränkt und damit vereinheitlicht werden:

Der Menübereich bindet also direkt die Datei menu.xhtml ein, die wiederum durch eine Liste – mithilfe von <ul>- und <li>-Elementen – definiert sein muss (Listing 2). Das bedeutet, dass der Inhalt des Menüs natürlich nicht festgelegt wird, wohl aber die Struktur, deren Aussehen nachher über CSS definiert werden kann.

Listing 2: Konvention für den Aufbau des Menübereichs

Geschrieben von
Benjamin Schmeling und Steffen Heinzl
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.