Why Web Developers Need JavaServer Faces

There's been a plethora of articles written recently on one of the Java Specification Requests (JSR) currently making its way through the Java Community Process (JCP). JSR 127 describes a new technology called JavaServer Faces that, if delivered as promised, will help to further deliver on the Java promise of Write Once, Run Anywhere.

If you've been building Java web applications for a couple of years, then you should be astutely aware of how the technology has been evolving to make it easier to write and deploy applications. It started off with Servlets, and then JavaServer Pages were introduced, and we started talking about Model 1 and Model 2 approaches and thinking about how to use these two technologies together to best leverage the advantages of each. Taking a snapshot of where we are today, commercial and open source projects have been formed to put features and functionality around these technologies. Frameworks like Struts and other web frameworks are getting their due.

Arguably, building web applications is becoming easier, but it's still cumbersome and frustrating for newcomers. First of all, there's still not a complete separation of UI from the model. UI designers still have to have some programming knowledge, and the separation of roles is blurry. Of course, using components like JSP tags help to focus the responsibilities, but it's still not perfect. Even if you do use some of the newer technologies like Java Standard Tag Library (JSTL) and JSP Expression Language, you still end up with a UI that's dedicated to a specific client or channel. What about support for other clients such as wireless devices? Many Struts applications are built using JSPs that assume the markup language is HTML. There's no standard approach that's accepted by the entire industry for supporting multiple clients or channels.

Another limitation is the lack of event handling. In a true MVC model, the view is able to generate events that can then be handled. For example, when a value changes in a UI component, the model needs to be updated. How about the ability for the view to query the model? All of these things are present in rich clients; just because my application runs in a browser, does this necessarily mean that I shouldn't have this functionality?

JavaServer Faces attempts to solve some of these issues, and a few others not mentioned here. JSF prescribes an architecture for projecting the UI to a client and allowing different rendering kits to render the UI for the specific client. The state of the components and their values can be maintained on the server and the UI components can generate events that are handled by the server. JSF also defines functionality for data conversion, validation, and localization. JSF promises a bright future for Java web developers -- a future that should allow for much richer support than what's currently available. If you haven't started looking at JSF yet, it's time to do so. There's even a Struts/JSF library that's been added to Struts by Craig McClanahan.

The second version of the public draft has just been released and can be found here: java.sun.com/j2ee/javaserverfaces.

You can also download the Early Access 4 version of JSF, which is included in the Java Web Services Developer Pack 1.2 (http://java.sun.com/webservices/webservicespack.html).

There's an online tutorial that provides a nice walkthrough of the technology: java.sun.com/j2ee/javaserverfaces/docs/tutorial.html.

Chuck Cavaness is a graduate from Georgia Tech with degrees in computer engineering and computer science. He has built Java-based enterprise systems in the healthcare, banking, and B2B sectors. He is also the author of two O'Reilly books, Programming Jakarta Struts and Jakarta Struts Pocket Reference.

Read more Java Q&A columns.

Return to the ONJava.com.