On the controller front, JSF offers a simple way to define page flows and state management. And the event-based programming of Web UIs helped the further adoption of JSF by developers familiar with the concept from their work with tools such as Visual Basic, PowerBuilder, and Oracle Forms. Developers who pick up JSF quickly realize that it does a great job of clearly separating the View and Controller layers — especially when developers use the XML-based JSPX format.

Another key advantage of JSF compared to other Java frameworks is the extensive tooling support offered by all the major players in the Java IDE space. Most of the IDEs offer visual page layout editors, property inspectors, and component palettes, in addition to page flow diagrams for the controller part.

The result of these benefits is a development experience that is much more productive than the old JSP way — even when you take into account the popular Struts/JSP combination. However, as good as it is right now, there's always room for improvement. So here's a wish list for the future of JSF.

Standardize AJAX Integration into JSF
One of the key benefits of JSF is its component-based approach to UI development. Instead of spending time writing markup languages, developers just pick components and arrange them on a page to construct user interfaces. This becomes an even bigger benefit when you bring AJAX into the picture. Component sets from Oracle, Backbase, ICEFaces, and others are already offering built-in AJAX functionality, which means that developers don't have to worry about JavaScript, DOM manipulation, XMLHttpRequest coding, or issues with their application being portable across browsers. By relying on the AJAX behavior that's built into the components, developers can speed up AJAX-based application development considerably.

However, one problem starts to rear its ugly head once you try to use AJAX-based components from different vendors in the same application. Integration between "regular" JSF components usually works out of the box with basic components, and you can mix and match component sets, but with AJAX-enabled JSF components, the situation is different.

Since the JSF specification doesn't include a definition of how AJAX should be incorporated into the JSF lifecycle, each vendor/framework has its own approach to handling AJAX events, usually involving extending the JSF lifecycle. The result is that developers end up with one set of components that collides with the architecture of another set because they have different lifecycles. This must be addressed in the next release of JSF.

While it's likely that the back-end JSF lifecycle aspect of AJAX integration can be standardized, standardizing the DOM manipulation or client side might prove to be a bit more challenging. Still I think that it's also an area worth the attention of the JSF community to prevent the accidental overwriting of client-side events by components from various sources.

Simplify JSF Component Construction
Most JSF component sets offer basic functionality that ranges from simple input components to more complex components such as shuttles and trees. But in many cases users want to define higher-level components that include subcomponents with specific functionality and behavior. For example, an address component would have several input components, a couple of select lists for state and country, and additional AJAX functionality that defines the dependency between country and state. The address component could then be packaged and used in multiple pages and applications.

I'd like to see JSF include an easy, standard way to define aggregated components so they could be reused, not just in a specific project, but by the members of the JSF community. One possible approach to simplifying aggregated component constructions is found in Oracle's ADF Faces Rich Client framework. You can define a component out of other components, define parameters that will be passed to the component, and define facets in the composite component's layout that let consumers of the component change its behavior at runtime. You can see an example in this demo, http://tinyurl.com/29smsu.

Add More States
JSF uses POJO-based managed beans to maintain values across pages in an application. These managed beans have scopes that can be defined as none, request, session, and application. The JSF engine automatically saves the information for the requested duration, making state management easy.

But developers need at least one additional scope in many applications - a task scope, which lies between the request and session scopes. Data in the task scope would last for the duration of a specific task, which might span several pages — but not throughout the full session. This is such a common requirement that implementations of such a scope have appeared in many of the JSF-based frameworks; for example, Shale's dialog scope, SEAM's conversation scope, and ADF Faces's process scope. Since this is such a common requirement, I fully expect to see this scope included in the next JSF iteration.

Developers might also benefit from a view scope, which would be active while a specific JSF page is being used. The need for this scope is likely to grow because AJAX components enable a new type of user interaction model — the single page model. In this model, users complete multi-step tasks by interacting with a single Web page instead of switching between different pages for each step. It's easy to see how this new interaction model would make the view scope an important addition to JSF, simplifying inter-component communication inside a page.

Introduce a New Component in the JSF Flow
JSF provides a controller layer that takes care of navigation rules between pages in an application and handles controller logic. Additional controller logic can be written in POJO classes that you define as "managed beans". This structure provides a very clear separation between view logic (located in the actual JSF pages) and the controller logic, which is in a separate physical file.

However, the JSF controller doesn't provide a very good way to represent or invoke logic as part of the flow between pages. Usually, developers invoke logic as part of the code behind a JSF component as part of a backing bean. For example, suppose that between the navigation from page A to page B you need to manipulate some data. Most developers will just write this code in the backing bean for the button that executes the navigation from A to B. This of course is not a great idea since it ties the logic to a specific button on a specific page. Although this can be resolved to some degree by refactoring the code into a separate managed bean, only few developers actually bother to do this.