Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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.)