Interview mit Spec Lead Ed Burns (Oracle) über JSF 2.2

Spielregeln vs. Spielräume

Ed Burns ist technischer Berater bei Oracle. Seit 1994 war er an diversen client- und serverseitigen Webtechnologien beteiligt, darunter NCSA Mosaic, Mozilla, das Sun-Java-Plug-in, Jakarta Tomcat und erst seit Neuestem JavaServer Faces. Er ist der derzeitige Spec Lead von JavaServer Faces und Koautor eines kürzlich bei McGraw erschienenen Buchs zu diesem Thema. Ed ist ein erfahrener und beliebter Konferenzsprecher, u. a. auf der JavaOne, JAOO, JAX, W-JAX, bei No Fluff Just Stuff, The Ajax Experience und Java- und Linux-Usergruppen.

Java Magazin

Das Interview „Spielregeln vs. Spielräume“ mit Ed Burns ist erstmalig erschienen im Java Magazin 6.2012.

Java Magazin: Um JavaServer Faces 2.2 ist es sehr still geworden, seit dessen neue Features im November 2011 präsentiert wurden. Wie sieht die aktuelle Roadmap aus?

Ed Burns: Ich habe versucht, das Projektmanagement dieses Mal disziplinierter anzugehen. Die aktuelle Roadmap steht auf der folgenden Webseite zur Verfügung [1]. Wegen der Transparenzregeln des JCP, denen JSF schon seit Jahren folgt, sind das öffentliche Informationen. Nach unserem aktuellen Zeitplan werden wir nach der ersten Jahreshälfte 2012 fertig sein. (Stand: Anfang April, Anm. d. Red.)

JM: Ein wichtiger Aspekt für Applikationen in der Cloud ist die Multitenancy-Fähigkeit von Anwendungen. In JPA 2.1 soll es eine Unterstützung hierfür geben. Wie sieht es damit in JSF 2.2 aus? Wird es z. B. so etwas wie einen Tenant Scope für Managed Beans geben, um mandantenspezifische Daten separat zu speichern?

Burns: JSF war 2004 die erste JCP-Spezifikation, die Inversion of Control basierend auf Plain Old Java Objects (POJO) in Enterprise Java eingeführt hat – inklusive der Scopes, wie wir sie heute kennen. Seit dieser Zeit hat Java EE einiges an dringend notwendigem Refactoring erfahren, und das Konzept der Scopes fällt jetzt in den Bereich der CDI-(Contexts-and-Dependency-Injection-)Spezifikation. Wir werden uns weiterhin eng an die CDI-Spezifikation halten, die auch Bestandteil von Java EE 7 ist, und somit auch jene Features unterstützen, die Multitenancy ermöglichen.

JM: Multi-Templating ist ein wirklich interessantes Feature. Ein Template besteht in der Regel aus mehreren Dateien. Müssen die Templates auf dem Applikationsserver selbst zur Verfügung stehen oder ist eine Referenz auf eine Webadresse möglich?

Burns: Multi-Templating, so wie es auf JSF angewandt wird, wurde erstmalig von Mamadou Lamine Ba vorgestellt und ist in der Expert Group bereits einige Iterationen weiter. Im Moment können Templates als jars verpackt und in einem Maven Repository gehostet werden, um zur Build-Zeit als Dependencies deklariert zu werden. Ein Feature, das sich „Remote Components“ nennt, wurde von der Portlet-Community vorgeschlagen. Für 2.2 haben wir es allerdings noch nicht auf dem Radar.

JM: Welche Restriktionen muss ein JSF-Entwickler hinnehmen, wenn er Templates verwenden will?

Burns: Was ein Template im Kern ausmacht, sind die Konventionen, die es für die zu ersetzenden Bereiche spezifiziert. Hier besteht kein großer Unterschied zur Verwendung eines regulären Facelet-Templates. Das Multi-Templating-Feature ist eine Formalisierung dessen, die dazu da ist, eine exaktere Spezifikation der Metadaten einzubinden. Das eigentlich Restriktive sind die Spielregeln, die der Template-Autor vorgibt. Bei JSF 2.2 liegt die Herausforderung darin, einerseits so nah an den Metadaten zu bleiben, dass die Vereinbarungen eingehalten werden, andererseits aber Designern den Spielraum zu gewähren, den sie brauchen.

JM: Im Blog von Lamine Ba wurde die Idee einer Template-Galerie für JSF 2.2 vorgestellt. Bisher liegt dort in einer provisorischen Galerie eine Anzahl von Templates, die dynamisch in einer JSF-2.2-Anwendung durchgeschaltet werden können. Aber wie unterscheidet man verschiedene Arten von Templates? Was passiert zum Beispiel, wenn ein Template das Menü auf der linken Seite, ein anderes das Menü oben auf einer Seite platziert? Bei JSF wäre es doch dementsprechend auch denkbar, verschiedene Template-Galerien zu unterscheiden, je nach Einschränkungs- oder Freiheitsgrad des Templates.

Burns: Sie treffen den Nagel auf den Kopf. Während das Galerie-Konzept selbst nicht Teil der Spezifikation sein wird, werden wir die notwendigen Metadaten zur Verfügung stellen, die es dafür braucht. Das schließt auch ein, dass dem User darüber Auskunft erteilt wird, wo die verschiedenen Seitenelemente platziert werden, ob links, rechts, mittig etc.

JM: In einem Interview mit dem JAXenter hat Kito Mann bereits im Juni 2011 angekündigt, dass JSF 2.2 HTML5 offiziell unterstützen wird. Es gibt einige neue Elemente wie z. B. <nav> und neue Input-Felder mit autocomplete, Eingabefelder speziell für numerische Typen, E-Mail oder Datum, um nur einige zu nennen. Werden all diese Neuerungen vollständig durch JSF unterstützt?

Burns: HTML5 ist sicher wichtig. Wie Sie wahrscheinlich wissen, ist HTML5 eine riesige Spezifikation, die verschiedene Content-Kategorien adressiert. Wir werden sicher nicht alles davon ausnutzen, was auch gar nicht sinnvoll wäre. Das heißt aber nicht, dass man keine App bauen kann, die JSF verwendet und HTML5 vollständig unterstützt. Man muss berücksichtigen, an welcher Stelle JSF zum Einsatz kommt. JSF ist eine serverseitige UI-Aggregationstechnologie, HTML5 eine clientseitige. Die UI, die von einer JSF-App generiert wird, kann HTML5 auch auf der Komponenten- oder Applikationsebene unterstützen, und mit Blick auf Ressourcen und JavaScript gibt es in JSF 2.2 einige Features, die das einfacher machen. Deswegen wollen wir HTML5-Elemente in einer der folgenden Content-Kategorien adressieren.

Metadaten: JSF-Anwendungen stehen bereits eine große Anzahl an Metadaten zur Verfügung. Wir müssen nun einen Weg finden, die Daten mit den verfügbaren Mitteln möglichst optimal in HTML5 darzustellen.

Sectioning und Heading: Die leichtgewichtige Ontologie der Section Values in HTML5 kam dadurch zustande, dass man googelte, wie die Leute ihre Div-Tags verwenden. Nach demselben Prinzip lässt sich herausfinden, wie Leute ihre Facelet-Templates verwenden.

Form-associated Elements: Die meisten Webanwendungen sind formularbasiert. Solche Anwendungen stehen bei der Arbeit an der HTML5-Umsetzung für JSF 2.2 im Fokus. Zum Beispiel hat HTML5 jetzt einen nativen Slider und Kalender-Controls, die zuvor nur durch serverseitige Verarbeitung und Übertragung von JavaScript und Bildern implementiert wurden.

JM: Gibt es Pläne, das neue WebSocket API zum bidirektionalen Austausch von Daten zwischen Server und Client statt der klassischen Ajax-Aufrufe zu verwenden bzw. gibt es Überlegungen, Methoden von ManagedBeans über WebSockets konsumierbar zu machen? Dies würde es ermöglichen JSF-Anwendungen aus einem reinen HTML/JS-Umfeld zu konsumieren.

Burns: Darüber und über viele andere Ideen, die in JSF aufgenommen werden sollten, wurde bereits diskutiert. Aber da WebSocket gerade am Anfang des JCP steht, den es erst noch durchlaufen muss [2], möchten wir noch etwas warten, bevor wir uns diesbezüglich auf eine Abhängigkeit einlassen.

Vielen Dank an Benjamin Schmeling und Steffen Heinzl für die Unterstützung beim Interview.

Kommentare

Schreibe einen Kommentar

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