JavaServer Faces, redux

An update on JSF's features and functions

By David Geary, JavaWorld.com, 11/14/03

Shortly after the first JavaServer Faces (JSF) early access (EA) release was introduced in September 2002, I wrote two JavaWorld articles detailing JSF (see Resources). Since then, JSF has matured considerably over four EA releases, and today, with a beta release in the wings, is poised to take the stage as the preeminent Java Web application framework. Furthermore, as the standard framework for developing Web applications, JSF will enjoy strong tool support from vendors like Sun Microsystems and its Project Rave development tool—a direct competitor to Microsoft's Visual Studio.

The underlying concepts from my first two JSF articles are still valid, but a multitude of changes to JSF has resulted in a different approach to implementing JSF applications. If you are unfamiliar with JSF, I suggest you review those articles; I will not repeat introductory material here.

These are the major additions to JSF since EA1:

Application configuration resources
Navigation handling
Actions
JavaBeans event model
Managed Bean Creation facility
Portlet compatibility
Framework extensions

In this article, I begin with an overview of each of these JSF additions. Once you have a solid theoretical understanding, I'll look at an updated version of the simple login application discussed in my first JavaWorld JSF article. That discussion will make the theoretical more concrete.

Read the previous "A First Look at JavaServer Faces" series:

Part 1: Learn how to implement Web-based user interfaces with JSF (November 2002)
Part 2: Explore JavaServer Faces components (December 2002)

Note: The code discussed in this article is based on the Early Access 4 release, which you can get by downloading the Java Web Services Developer Pack (JWSDP). See Resources for a link to the JWSDP download page.

Application configuration resources

Application configuration resources are resources you specify in an XML configuration file (typically /WEB-INF/faces-config.xml) instead of Java code; for example, you can specify navigation and managed beans (meaning beans created and managed by JSF) in faces-config.xml. Otherwise known as declarative programming, this is a feature Java 2 Platform, Enterprise Edition (J2EE) developers have learned to appreciate. Specifying things in XML is easier than writing code, and this XML is accessible to page authors with no Java experience. Plus, you can change resources without recompiling. Many JSF resources are now specified in configuration files; here's a partial list:

Navigation rules
Managed beans
Custom components
Converters
Validators
Render kits

Application configuration resources are closely tied to two other features listed above: navigation handling and the Managed Bean Creation facility. Both of those features are specified in the JSF configuration file and are discussed below.

Note: Although /WEB-INF/faces-config.xml is the default JSF configuration file, you can specify an alternate file, or a list of files, that serve as the application configuration file(s).

Actions and navigation handling

In JSF EA1, developers were forced to write an application handler that handled all of an application's action (application-specific) events. That application handler didn't scale well because it was essentially a switch statement that handled all action events. JSF EA4, like Struts, lets developers use the Command pattern to represent actions as objects instead of cases in a switch statement. (See "Take Command of Your Software" (JavaWorld, June 2002) for more about the Command pattern.)

Actions have a processAction() method that returns a string representing the action's outcome. The JSF framework uses that outcome to forward the request to some destination. Navigation, in terms of outcomes and forwarding destinations, among other things, are specified in—you guessed it—a faces configuration file.

A combination of actions and declarative navigation handling accomplishes two things: it moves developers from switch statements to the Command pattern and allows navigation rules, in terms of things like outcomes and JSP pages, to be specified in a faces configuration file. That's a strong one-two combination for maintainability and extensibility.

JavaBeans event model

Event models are an integral part of component frameworks because they let you react to component events, such as when a button is clicked or a value is changed. JSF EA4 offers two types of events and associated listeners: action events, fired when a button or link is activated, and value-changed events, fired when an input component's value is changed. If you use JSF with JavaServer Pages (JSP), you can register event handlers for components like this:

<h:input_text valueRef='someBean.someProperty'>
   <f:valuechanged_listener type='SomeListenerClass'/>
</h:input_text>
...
<h:command_button key='submit.button.prompt' bundle='messages'>
   <f:action_listener type='AnotherListenerClass'/>
</h:command_button>

A full-fledged event-handling example is discussed at the end of this article.

Managed Bean Creation facility

JSF lets you directly wire components to bean properties; for example:

  <h:input_secret valueRef='loginForm.password'/>

The preceding tag represents an input component whose value is wired to the password property of a bean named loginForm. Early JSF versions supported wiring components to bean properties (valueRef has replaced the modelReference attribute), but the developer had to instantiate the bean, typically with <jsp:useBean>. With EA4, the JSF framework takes care of instantiating those beans; all you need to do is declare them in a faces configuration file. The configuration file also lets you specify bean properties and runtime relationships between those beans. Those configuration files sure are handy!

Portlet compatibility

JSF EA4 provides portlet compatibility by eliminating references to the servlet API. For instance, in EA1, you could obtain a reference to the servlet context by calling FacesContext.getServletContext(), but that code won't work in a portlet; instead, you would need a reference to the portlet context. JSF EA4 no longer has a FacesContext.getServletContext() method; instead, you call FacesContext.getExternalContext(). The ExternalContext class is a wrapper around some type of context (servlet or portlet, typically). You can use the external context to access container contexts in a neutral fashion. For example, ExternalContext.getRequest() returns an Object reference that either points to a ServletRequest instance or an instance of PortletRequest; you cast the Object reference to whatever is appropriate. If you must have a reference to either the ServletContext or PortletContext, you can call ExternalContext.getContext(), which also returns an Object reference that you must cast.

1 | 2 | 3 | Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject	Replies	Last post
VIPPIE Dialer 4 VOIPSWITCH Only by Solution4VOIP By solution4voip_net	1	05/05/08 06:55 AM by Businescares
VOIPSWITCH+all Modules with Live Demo +support24/7 By apnavoip	1	04/22/08 09:08 AM by voipswitch
Free VoIP SoftPhone By skysiptel	0	03/20/08 03:27 PM by skysiptel
Free VoIP SoftPhone By skysiptel	0	03/20/08 03:27 PM by skysiptel
JSF versus Oracle UIX By Anonymous	3	10/05/06 07:35 AM by Anonymous
JSF versus Struts By S Ross	15	10/04/06 06:07 AM by Anonymous
Object Creation doubt By moc	0	09/29/06 06:03 AM by moc
sybase guide for 510-022 By rejeth	0	09/27/06 08:46 AM by rejeth
TreeControls and Accessibility By Anonymous	1	03/02/06 03:31 PM by Anonymous
It is appears that JSF unnecessary over-designed By Jack Su	2	03/02/06 11:41 AM by Anonymous
Problem in Paint method By udhayakumar	2	03/02/06 11:38 AM by udhayakumar
JSF and Tapestry By Anonymous	1	03/02/06 11:10 AM by Anonymous
Using JSF/JSP By PAFlyFisherman05	3	03/01/06 09:20 PM by kirti_java
What is the point REALLY? By why-JSF?	12	12/03/03 08:25 AM by Anonymous
J2EE 1.4 By Anonymous	0	11/14/03 08:30 PM by Anonymous