Interview with JSF Spec Lead, Ed Burns
We chat to Oracle’s JSF Spec Lead Ed Burns about the latest work going towards JavaServer Faces 2.2, which should arrive in June.
Ed Burns is a Consulting Member of the Technical Staff at Oracle America, Inc. and has worked on a wide variety of client and server side web technologies since 1994, including NCSA Mosaic, Mozilla, the Sun Java Plugin, Jakarta Tomcat and, most recently JavaServer Faces. Ed is currently the spec lead for JavaServer Faces, a topic on which Ed recently co-authored a book for McGraw Hill. Ed is an experienced international conference speaker, with consistently high attendance numbers and ratings at JavaOne, JAOO, JAX, W-JAX, No Fluff Just Stuff, JA-SIG, The Ajax Experience, and Java and Linux User Groups.
It has become pretty quiet around JSF 2.2 since its new features were presented in November 2011. What is the current roadmap?
I’ve been trying to be disciplined about project management this time around and the current roadmap is always available. Because of the transparency rules of the JCP, which JSF has been practicing for years already, this is public information. Our current schedule has us finishing up around the first half of CY2012.
JPA 2.1. will supposedly provide support for multitenancy, which is key to cloud-based applications. Will JSF 2.2 also provide this kind of support, e. g. will there be a Tenant Scope for Managed Beans or anything equivalent that allows for separate storage of tenant-specific data?
In 2004, JSF was the first JCP spec to bring Plain Ole’ Java Objects [POJO] based inversion of control (and with it the notion of scopes as we know them today) to Enterprise Java. Since that time, Java EE has done some much needed refactoring and the concept of scope is now the domain of the Contexts and Dependency Injection (CDI) specification. We will continue to work closely with CDI spec, which is also a part of Java EE 7, and support their multi-tenant enabling features.
Multi-Templating is quite an interesting feature. As a rule, a template consists of several files. Do these templates have to be made available on the application server itself? Or is it OK to provide a reference to a web address?
The concept of multi-templating as it applies to JSF was initially suggested by Mamadou Lamine Ba and since then it has gone through some iterations on the EG. My current thinking on the topic is that templates can be packaged as jars and hosted in a maven repo and declared as dependencies at build time. A feature called “remote components” has been suggested by the portlet community, but this one is not on the radar for 2.2.
What restrictions do JSF developers have to accept when applying templates?
The essence of a template is the contract it specifies for the replacement zones. This is really no different from using a regular Facelet template. The multi-templating feature is a formalization of that to include a more rigorous specification of the metadata. Therefore, the main restriction is to play by the rules defined by the template author. Our challenge with JSF 2.2 is to be tight enough with the metadata to make the contract meaningful, while being flexible enough to let template designers be as creative as they need to be.
In Lamine Ba’s blog, the idea of a template gallery for JSF 2.2 was presented, and since then, a number of templates have been submitted to a provisional gallery. Is there a way to distinguish between different types of templates, e. g. if one template places a menu on the left side and another one places it on the right side?
Wouldn’t it make sense to distinguish between different template galleries in JSF based on their respective degree of restriction or freedom?
Yes, you’re hitting the centrality of the contract issue right on the head. While the gallery concept itself will not be a part of the spec, the necessary metadata to present a gallery including telling the user where the various page elements go (left, right, center, etc) is what we will provide.
- JSF applications already have large amounts of metadata available to them. We need to find the best way to allow that data to naturally express itself via the corresponding capability in HTML5.
- Sectioning and Heading
- Just as the lightweight ontology of section values in HTML5 was obtained by searching Google for how people were using their div tags, the same idea can be applied to how people are using their facelet templates.
- Form associated elements
Are there any plans to use the new WebSocket API permitting bidirectional exchange of data between server and client (rather than classical Ajax requests)? Or to make Managed Beans methods consumable via WebSockets, so that JSF applications can be consumed from a pure HTML/JS environment?
Those and many other ideas have been discussed in the past for inclusion in JSF, but as WebSocket is just now starting its way through the JCP process, we prefer to wait a bit before introducing a dependency on that one.
This interview originally appeared in our sister publication, Java Magazin in Germany.