Java Server Faces (JSF) is an important, new Java Web technology that offers great benefits for Web application development. This article provides a first look at the basic concepts of JSF and where they may pay off in your applications. More in-depth information will be covered in future JSF articles that show examples of different types of JSF development in IBM's WDSC toolset. While not supported in the current version of WebSphere Development Studio Client (WDSC 22.214.171.124), JSF will be supported in a future version.
JSF versions and providers
JSF's design is based on a Java Specification Request (JSR 127) managed by The Java Community Process (JCP) that sets Java standards. Today, a variety of JSF implementations are available. The current standard is now version 1.1.
JSF support is available from several sources. Sun Microsystems offers JSF support in the Java Web Services Developer Pack version 1.3 that can be downloaded from www.javasoft.com. You can also download the JSF reference implementation from Sun at http://java.sun.com/j2ee/javaserverfaces/. And IBM offers a preview of JSF in WSAD version 5.1.1. There are open-source implementations available as well. Check out www.myfaces.org.
JSF definition from Sun
The Sun Java Server Web Services Developer Pack documentation for version 1.3 provides a basic definition of what JSF does nicely:
"JSF is a server-side, user interface framework for building Java Web applications. . . . The main components of JavaServer Faces technology are
- An API and reference implementation for representing User Interface (UI) components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all of these features.
- A JavaServer Pages (JSP) custom tag library for expressing UI components within a JSP page.
This well-defined programming model and UI component tag library significantly ease the burden of building and maintaining Web applications with server-side UIs. With minimal effort, you can do the following:
- Wire client-generated events to server-side application code
- Map UI components on a page to server-side data
- Construct a UI with reusable and extensible components
- Save and restore UI state beyond the life of server requests"
These are big benefits that go beyond the scope of any current Java Web framework available in IBM's WDSC tools today.
JSF User Interface controls and events for Web pages
Model objects available across a Web application
JSF supports Managed Beans. A Managed Bean is a Java bean defined in the faces-config.xml file. By defining it there, it can be available across the application as needed to any Web page that needs reference to it. The properties for a Managed Bean are set (or bound to a UI control) using the valueRef elements and accessed using the getValue method for the element. You might have a Customer bean that has customerNbr, Name and phoneNbr properties that could all be accessed this way from a Web page. The Managed Beans can automatically be created as needed when referenced on a JSP using the ValueBinding definition (naming the Managed Bean in an expression). You can also define arrays or collections of objects for reference (for example, a list of items on an order).
The impact is it now takes much less work to create Java objects for your Web application, as well as to populate Web pages and objects with values.
A Web page as Java objects, not HTML
In addition, there is full event support for the UI controls, so you can wire application behavior to a UI event. When a command button is clicked, for instance, the Web page can be submitted to the server specifying a given action to run. The UI controls are based on common application event patterns. For example, with a list or table you may want one of the following actions supported: SelectBoolean (something was selected), SelectOne (a single selection) or SelectMany (multiple items have been selected in a list or table).
The JSF tag libraries fall into two categories:
1. Core tags that cover basic events, page definition, data validators and so on.
2. HTML tags that define JSF UI Control objects on a Web page. (For example, a command_button tag can define a button to open a JSP to view an Item catalog.)
The JSF tag generates the HTML code for the JSP along with a UI Control object definition for the application for a button). UIInput and UIOutput components support different data types and default conversions between the Web page and the data value for the UIControl, eliminating the need to manually convert the data most of the time!
Binding UI component classes to Model objects
You can easily create or generate Java beans to represent business data (a Customer class, an Item class and so on). With JSF, you decide which UI controls are bound to properties of Managed Beans defined in the JSF application. This makes data validations easy and allows custom processing where needed. There are standard data converters for the normal data types. You can also supply your own by implementing a converter interface.
Separate rendering from presentation: One application with many clients
With JSF, specific rendering toolkits are provided for different types of clients. Usually an HTML rendering kit is provided in most implementations. You can also buy, find or create other rendering toolkits for different client environments.
What's the impact of this? With JSF you can design one version of an application that can work in MANY application contexts: Web pages, WML, Web services, GUI applications and so on. No more coding for a specific type of client required.
Web control events and the config file define your application workflow
You're used to writing event-handling logic already. You've been handling conditions such as 'Customer not found' in the iSeries database for years in RPG or COBOL using indicators. The same concept applies on Web pages now. The UI controls (input_text or command_button) support one or more of the two event types in JSF: Action events (such as button clicked) or Value changed event (such as ZIP code entered). Your application can request to be notified when one of those events occurs so you can handle it (just like you handle events in RPG or COBOL) by registering an ActionListener for the event on a specific UI Control (a command_button for instance). The Action object has an invoke method that is called. The invoke method returns a condition name such as "success" or "orderShipped".
Sure, that sounds great, but where's the mainline for my application workflow? In RPG or COBOL there is a usually a main subroutine or procedure for the application mainline. Here, the mainline workflow is defined in the faces-config.xml file. It has all the navigation definitions defined. For applications that aren't too large, you can read the workflow well from the XML file. Conditional events for navigation are represented by a three-part navigation definition that shows: the current JSP Web page, the named condition ("success", "orderShipped" and so on) and the target page to transfer control to. The default NavigationHandler will match the current page and the condition name to the navigation definitions in the faces-config.xml file to find the next page to transfer control to in the application.
Here's a sample navigation rule defined in the faces-config.xml file for a logon application:
<navigation-rule> <from-tree-id>logon.jsp</from-tree-id> <navigation-case> <from-action-ref>LogonForm.logon</from-action-ref> <from-outcome>success</from-outcome> <to-tree-id>/storefront.jsp</to-tree-id> </navigation-case> <navigation-case> <from-action-ref>LogonForm.logon</from-action-ref> <from-outcome>failure</from-outcome> <to-tree-id>/logon.jsp</to-tree-id> </navigation-case> </navigation-rule>
The rule shows if the logon is successful, the user is transferred to the storefront.jsp Web page. If the logon fails, he's returned to the logon page to retry the logon again.
How is JSF different than Struts?
JSF encompasses most of what is useful in Struts and goes far beyond it in scope. Here's a quick list of some differences I see:
- Naming conventions are different
- JSP:UseBean tag defines beans IN Web pages. JSF Managed Beans are defined IN an application.
- Rendering as a separate phase supports multiple client types nicely
- The UI Control tree to represent a Web page is more refined than the basic ActionForm model in Struts.
When can I use JSF?
The negative to JSF is it's a newly published Java standard and not all tools support it fully yet. The next version of WDSC (v 5.1.2) will support JSF. Sun has a new toolset, Java Studio Creator, in beta now that supports JSF 1.1. You can also set up open-source implementations of JSF frameworks in the Eclipse-based IDE. I haven't tried (and therefore don't recommend) trying to add a JSF implementation into the existing WDSC version. The new version of WDSC should begin shipping in July, and it should include some of the JSF support that's available now in WSAD 5.1.1.
What does JSF mean to your e-business plans?
If you are ready to deploy a project now, use the existing WDSC frameworks such as Struts. Maybe for the next major application update or version, you could look at migrating to JSF.
If you are about to build an application and have the lead time, consider bringing in an iSeries JSF consultant to evaluate what you are doing and make some recommendations. In most cases, good architectures followed some JSF principles, so adapting a good design to JSF shouldn't be too difficult.
Understand that while JSF version 1.1 is released in final version, many of the tools and vendors that are using JSF are just getting their products out the door.
---------------------------------------About the author: Jim Mason, president of ebt-now (www.ebt-now.com), is an iSeries WebSphere architect, trainer and developer. ebt-now provides iSeries WebSphere, WebFacing engineering, development and training services. Jim has developed the VDM method for Visual Development of Web applications in WDSC. He's producing a course book and offering Web-based training on VDM development for iSeries developers. You can reach Jim at firstname.lastname@example.org or 508-888-0344.
This was first published in June 2004