Design Considerations Using JavaServer Faces

Subbu Ramanathan

03/27/2004

Java Server Faces (JSF) is a standardized framework for building user interfaces for web applications. It is positioned to be the "Swing for server-side applications". This paper is an attempt to identify the appropriate use of this technology. Some of the specific issues discussed in here are related to Sun's implementation of the JSF specification only.

Elements of JSF

The core features of JSF are its standard user interface (UI) components, provision for custom UI components, provision for custom UI rendering of UI controls, and the event driven UI programming model.These features have long been a standard for developing rich client applications. JSF brings them into the web world.

The standard JSF UI components are a wrapper around the common HTML form elements. Custom UI components developed for JSF adhere to the JSF standard while providing more feature rich UI.The same UI component defined on a form can be rendered differently for, a standard platform independent web UI; a platform specific UI; or application context specific UI.This rendering is done through custom tag libraries.

JSF forms are built using JSF tags to represent UI controls in a JSP page. Each control identifies the managed bean and that managed bean's property they are tied to. Managed beans represent the "Model" part of the JSF MVC architecture. The faces-config.xml file defines the various managed beans used by a JSF application, and the navigation rules for each action source on a form. Action target can either be another web resource like a jsp/html file or a managed bean method

Built in data converters and custom data converters are provided by the JSF framework to migrate string data on web forms to their appropriate types in the associated business model.

The standard data validators provided by JSF support form data validation.

JSF and the Struts Framework

The Struts framework already possesses a large customer base. JSF does not have the equivalent of Struts' powerful controller architecture. This makes the marriage more meaningful. It will also provide a cleaner migration path for a good size of the Java community. The struts-faces library currently being created by Craig McClanahan addresses the need to integrate these two.

JSF for Enterprise Applications

Java Server Faces architecture is based on loose coupling between UI definition, UI rendering and model. This provides for clean separation of work effort in a web development project. The web form coding and configuration wiring currently required by this design is not too appealing at this point. The true benefit of this framework will come to light when tools become available to paint JSF forms and attach event handlers to them. IBM's WebSphere Studio V5.1.1 has recently added support for JSF.

JSF does not dictate anything as far as the design of your non user interface components/classes. Any new JSF application can integrate easily with existing server components. This loose coupling of Java Server Faces also allows for gradual migration of existing applications to JSF as long as they are written using a clean separation of UI from the business model layer.

The proliferation of tools supporting JSF and advertising of JSF to be the perfect way to speed up web application development can have serious ramifications on application performance. Applications that are easier to code must also be easier to use. Wiring of event handlers for every single control on the web form can be easy with JSF. It might even make the user interface more coordinated - changing the zip code immediately verifies the validity of the city and state and updates the county field. The fact to remember is that JSF does not intelligently eliminate any round trip to the server in a distributed environment. The more the round trips, the more the possibility of delay. If your target audience is not equipped with high speed connection to the server, frequent round trips to the server will just kill your application. This does not mean that JSF is not appropriate for dial-up connections. JSF can still provide the ease of coding in such applications. Care must be taken to design the UI to make fewer round trips. It is okay to have a JSF application submit to the server after all the data on a web form is entered.

The JSF engine maintains a web form layout as a component tree on the server for each page visited. This is used for all server side work related to user interface processing. The purpose of this cache is to provide faster access for subsequent hits to the same page. The impact of this needs to benchmarked for large applications. Since JSF as a specification has more than one implementation, this impact may vary by implementation.

The current standard UI controls and validators shipped with JSF are pretty basic. So, any immediate adopters of JSF will not gain much in the way of fancy controls or validators until some custom components are released. The current mechanism for building custom validators is based on validating only one UI component data at a given time. The workaround here could be to read other related data from values committed to corresponding business objects. This is not really perfect when you want to validate all data first and commit only valid data to business objects.

The conversion rules provided by standard JSF data converters are very strict. This makes them not very suitable for all practical scenarios. For example, if a user enters 2,500, without a leading $ sign, for the currency field, the currency formatter will report that the input is an invalid currency value. So, custom data converters might have to be written to handle data conversions that are not simple.

As the case is with any new technology, the debugging/troubleshooting support for JSF is very minimal. Looking through web server logs is an option. A better option will be to use some kind of application level logging that is usually a good idea with any web application. The simplest solution here would be to use the log method of the ServletContext class.

Despite the fact that a lot has been written about JSF, it is still in its infancy stage and has time to mature.The technology is a step in the right direction with a lot of potentials. Just like any other technology, proper application is more important.

Resources for Further Exploration

The struts-faces integration library

Troubleshooting JSF applications

---

© 2003-2004