As you might imagine, I spend a great deal of time thinking about ways to
improve JSF. I don’t always have the time to actually implement things,
but I have a very good understanding of what needs to be done. I’m looking
forward to working on JSF 2.0, and I think I speak for most people in the expert
group when I say that this must be the killer release. So, in order to add my
$0.02 to the endless list of possible new features and changes in JSF 2.0, I
thought I’d list them all here.
If you have your own ideas about JSF 2.0, or you're curious about what the final JSR will
include, check out Ed Burns' blog entry, which includes a draft of the JSF 2.0 JSR. The expert group would
love to get your feedback, so please comment on the blog or comment on the JSF 2.0 scratch pad.
Many of my suggestons are somewhat obvious or have
been mentioned elsewhere (such as in Ed's JSR draft), but I feel compelled to repeat them here
anyway. So, without further ado, here is the list.
Hard Failure
One of the best and worse things about web development is the way web applications
“fail silently.” What this means to the average developer is that
they can spend hours pulling out their hair, merely because they mistyped something
and all of a sudden they saw a useless error like a blank page. While this dynamic
behavior has all sorts of other benefits—such as allowing integration
of disparate applications and permitting several extensions to be built on top
of the Servlet API—I still have to wonder: why does everything have to
fail silently?
After teaching so many JSF courses and observing the students during the labs,
it’s clear that expressions and navigation rules are by far the biggest
offenders in JSF applications. If an expression doesn’t resolve to an
object, nothing is displayed. If you mistype a navigation rule, simply redisplayed.. I’d like to see
a configurable “fail hard” context parameter that will cause JSF
to throw a FacesException in these cases. That way, developers won’t waste
so much time hunting down these minor errors.
Navigation Rules API
One of the best things about JSF is that it’s extremely pluggable. But
that pluggability falls short if you have any interest in accessing the navigation
rules. I’d like to see an object model representing the navigation rules.
That way, developers could easily add features based on navigation rules that have
been loaded in the default manner. I think this could open up a whole range
of possibilities for expanding the power of the navigation subsystem.
Startup attribute for managed beans
I’m a big fan of dependency injection, and I like JSF’s managed
beans. I think we definitely need the ability to create managed beans at application
startup. Right now, the only way to do it is to write a ServletContextListener,
which is overkill for something that should just be an attribute on the <managed-bean>
node:
<managed-bean startup=”true”>
...
</managed-bean>
Seam has handled this nicely with the @Startup attribute.
Backing bean lifecycle methods
Quite a few developers feel the need for methods that are called at certain
points during the request processing lifecycle, but are associated with a particular
backing bean. This is usually used for initializing and releasing resources
associated with the bean. Shale and Java Studio Creator handle this with methods
such as init() and preprocess(), and Seam provides a couple of annotations for
this purpose. I’d like to adopt Shale’s approach with and without
annotations, but with better method names :-).
Enhanced support for GET requests
Currently, JSF can handle GET requests, but the Command components
(HtmlCommandButton and HtmlCommandLink) don’t generate GET requests, and
it’s not completely obvious how to support them in your backing beans
(the current solution is simply to bind up properties to your backing beans
using the “param” implicit variable in your expression). So, in
addition to a standard way to access JSF pages via GET requests, and a standard
way to generate those requests (via either a new component or an attribute on
one of the existing Command components), I’d like to see the ability to
execute a backing bean method that determines which page should be displayed
(or responds directly). Moreover, I’d like more control over the mappings
between a URL and a backing bean method or a JSF view.
This is a cross between Seam and Shale Remoting, with the added ability to
define mappings between URLs and views (as well as backing bean methods).
Ability to invalidate the session via the FacesContext
Right now, if you want to invalidate the session, you have to do something
like this:
HttpSession session = (HttpSession)facesContext.getExternalContext().getSession();
session.invalidate();
I’d like to see something simpler:
facesContext.getExternalContext().logout();
The real question is how this behaves in a portlet environment...
Support for the EL in navigation rules
This is a simple affair – the EL should simply “work” in
validation rules. Seam has addressed this problem.
Use of Annotations
Even though JSF 1.2 requires JDK 1.5, it doesn’t make full use of annotations.
I’d like to see full support for annotations, building on the annotations
provided in Shale and Seam.
Simplified component/renderer development
One of JSF’s biggest barriers is the complexity of UI component development.
This is part of the reason Facelets has done so well – you can create
certain classes of lightweight components with ease. Tapestry has always had
JSF beat hands-down when it comes to component development as well (I can’t
say much about other component frameworks such as Wicket or Echo2, since I haven’t
studied them in detail).
Here are the primary problems:
- Renderers by default are pure Java classes with no templating mechanism.
People have used things like Velocity instead, but that requires
a custom solution. You should be able to declare the decoding output using a
standard Facelet-style template, with the component instance automatically injected
under a default name, such as “component.” In the simplest case,
you should be able to create this template and ignore a UI component class altogether
(again, a-la Facelets).
- Configuration. After you’ve defined the component, you have to register
it with JSF and with the ViewHandler (JSP or Facelets). In the case of JSP,
this is unnecessarily tedious. Even with Facelets, someone has to declare the
component. A combination of template location and annotations should cover most
use cases and avoid this grunt work altogether.
More to come
I’ve got a few other suggestions in my list that I’ll enumerate
in Part 2.
About the Author
Kito D. Mann is editor-in-chief of JSF Central (www.jsfcentral.com) and the
author of JavaServer Faces in Action (Manning). He is a member of several Java
Community Process expert groups (including JSF, WebBeans, and Portlets), and
an internationally recognized speaker. Kito is also the Principal Consultant
at Virtua, Inc., specializing in enterprise application architecture, training,
development, mentoring, and JSF product strategy. He holds a BA in Computer
Science from Johns Hopkins University.
