Chat about the current JSF roadmap

Interview with JSF Spec Lead, Ed Burns

Chris Mayer

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.

It has become pretty quiet around JSF 2.2 since its new
features were presented in November 2011. What is the current

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.

As you may know, HTML 5 is a huge specification and it
addresses many different

categories of content
. We will certainly not be exploiting all of it,
and it doesn’t make sense for us to do so. That doesn’t mean that
you can’t build an app that uses JSF and leverages all of HTML 5,
you certainly can. You have to keep in mind JSF ‘s position in the
stack. JSF is a server side UI aggregation technology. HTML5 is a
client side UI aggregation technology. The UI generated by a JSF
app can just as well support HTML5 at the component or application
level, and there are several features in JSF 2.2 with respect to
resources and JavaScript that make this easier. That said, we plan
to address HTML5 elements in the following content


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.


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

Form based applications are the reason for most
web applications and it is this category that most of the HTML5
related work in JSF 2.2 will happen. For example, HTML5 now has
native slider and calendar controls, which only used to be
implemented using server side processing and delivering JavaScript
and images.

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,
e prefer to wait a bit
before introducing a dependency on that one.


This interview originally appeared in our
sister publication, Java Magazin in Germany.

comments powered by Disqus