JSF Central - JSF 2.0 Wish List Part 1
JSF Central

 Articles & Books 
From the Editor's Desk
JSF 2.0 Wish List Part 1
by Kito D. Mann
02 Apr 2007 11:30 EDT

JSFCentral Editor-in-Chief Kito Mann offers his suggestions for JSF 2.0, including hard failure, enhanced support for GET requests, and simplified component development.

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”>

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();

I’d like to see something simpler:


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:

  1. 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).
  2. 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 JSFCentral (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.

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.