As Published In July/August 2004

Making Faces
By John Kirkley

JavaServer Faces (JSF) provides a powerful new framework for creating Web GUIs.

With the millions of Web applications that have been developed over the years, it seems logical that the industry would have found a standards-based way to deal with the many graphical user interface (GUI) and presentation issues associated with them.

Unfortunately, as most of us know, that GUI Nirvana hasn't arrived yet. Although existing specifications (such as Struts and Java Server Pages [JSP]) attempt to solve some problems related to Web GUIs, in reality they solve only part of the problem. As a result, writing a complex Web GUI can be a time-consuming job, with developers writing special-purpose code to handle tasks such as applying style and behavioral changes to GUI elements or reusing HTML form components. Over time, the maintenance associated with this specialized code can take on a life of its own.

Clearly, a better solution is needed. Adam Winer, an architect at Oracle on the Application Developer Framework (ADF) View Technologies team, explains why: "Existing standards do not define how GUI elements get moved around in a common, standard way. When using JSP or Struts, developers wind up inventing a lot of code—either writing it themselves or duplicating something someone else has written. And everyone does it his or her own way."

Kind Faces

But help is on the way. Developed under the auspices of the Java Community Process (JCP) as JSR 127, JavaServer Faces (JSF) provides a standards-based user interface framework for server-side Java applications deployed over the Web.

Several other choices exist for developers looking to develop Web-based user interfaces. However, technologies such as Velocity, Tapestry, and Cocoon are not JCP-based, nor have they attracted a large enough following to be considered de facto standards. By contrast, JSF was developed through the JCP standards body with strong vendor support.

Developers may wonder how JSF will work with other Java frameworks such as Struts. Although not directly competitive, Struts (the popular Jakarta Open Source framework) does have several features that overlap with JSF. Interestingly enough, Craig McClanahan, who was the lead architect for Struts, is also a specification colead for JSF. According to McClanahan, Struts will cleanly integrate with JSF, allowing developers to use JSF components for the user interface while continuing to use Struts to implement the controller, Action classes, and associated business logic. It will be possible, he says, to transition applications from using Struts HTML tags to using JSF component tags—with minimal changes to Struts components, in most cases. An integration library for Struts is in development to ease the transition between the two technologies.

One of the most compelling aspects of JSF is that it is markup-language-, protocol-, and client-device-agnostic. As a result, developers can use the standard to leverage existing GUI and Web-tier concepts without being stuck with a particular Web technology. In other words, developers don't have to build their own framework or turn to existing and often excellent—but incompatible—frameworks such as Tapestry and Cocoon.

Looking at Faces

In a nutshell, the main parts of JSF are a GUI component framework and a flexible model for rendering components across various markup languages or client devices.

The JSF GUI component framework lets developers create the user interface of a JSF application. JSF GUI components can include standard HTML form controls (such as buttons), layout components, and more-complex components such as data tables. Furthermore, third parties can extend the base classes defined in the specification to develop additional GUI components.

The JSF rendering model defines how GUI components are rendered on different clients. In JSF, functionality associated with a GUI component is defined separately from the way it is rendered. This flexible rendering approach makes it possible to define multiple ways to render a component to support various clients while retaining the behavior of the GUI component in a single definition. A render kit defines how GUI component functionality maps to the way it is rendered for a particular client.

In addition to the JSF rendering model, the JSF specification also provides a standard RenderKit class for generating HTML 4.01-based markup. This standard RenderKit provides a JSP custom tag library that defines JSF interactions within a JSP page.

JSF also provides capabilities that help developers manage the application logic and data associated with GUI components. JSF applications typically contain additional objects such as model objects and backing beans, which encapsulate the application logic and data associated with GUI objects. The JSF Managed Bean Creation facility lets developers create these objects used in JSF applications declaratively through parameters in an application configuration file. Using the Managed Bean Creation facility, developers can customize these beans with initial properties (from within the configuration file) and specify the automatic connection of these beans to other objects.

JSF also provides other capabilities associated with a rich GUI framework. They include:

• Input validation: JSF provides a mechanism for server-side validation of user input. A set of Validator classes (and JSP custom tags) is provided for basic validations. Developers can also add custom Validator implementations.
• Event handling: JSF provides a mechanism whereby applications can handle events generated by JSF GUI components. This mechanism is similar to the event model in the JavaBeans architecture.
• Data conversion: JSF lets developers automatically convert data from its presentation view format, such as strings in a text field, and its model view format, typically a native Java type.
• Page navigation configuration: The JSF page navigation model lets developers, in most cases, define navigation across pages within a JSF application in an application configuration file.

According to Oracle's Winer, "Specific aspects of Faces are designed to solve problems typically encountered by beginning developers, such as dealing with the stateless nature of HTTP. Faces makes Web applications appear highly stateful without making the developer manually build all sorts of code. It sets properties on components, and those properties will still be around the next time you get a request. Developers do not need to know in detail how the HTTP response cycle works. Instead, they simply create a page and process events from that page without needing to look at, convert, or parse query parameters. Values just move in and out of the model without human intervention."

Shining Faces

So why should the launch of JSF bring joy to the hearts of the developer community? For one thing, JSF is easy to use—it provides a clean separation between logic and presentation. As a result, everybody from Web page designers to component developers can use it in a way that promotes a clean division of labor and shorter development cycles. Also, JSF is versatile—it handles the complexities of managing the user interface on the server, freeing application developers to concentrate on coding application specifics rather than UI plumbing.

The benefits of JSF extend to a wide array of potential users, including Web page authors, Java developers, and tool vendors. Web page authors will use JSF component tags to create GUIs from within Web pages such as JSP pages. Web application developers will connect data and business logic to JSF components. Component developers will construct reusable JSF components, by taking advantage of JSF's extensibility. And last but not least, tool vendors will unveil products that make building user interfaces even easier.

Tooling Up for Faces

"At Oracle we're trying to figure out how Faces will work best in the real world of our enterprise customers," says Ted Farrell, chief architect, Application Development at Oracle. "Changes made to JSF that support enterprise development groups allow Oracle and other vendors to build better technology around Faces and help the standard be stronger right out of the box."

Next Steps READ more about JSF jcp.org/en/jsr/detail?id=127 java.sun.com/j2ee/javaserverfaces more about JSF and Oracle JDeveloper "Developing Faces"

Oracle JDeveloper 10g supports various view technologies in Oracle ADF, including ADF UIX, an open user interface framework for building J2EE-compliant Web applications. Winer and his ADF UIX colleagues are incorporating JSF into both ADF UIX and the JDeveloper product. Winer's view is that although the initial release of JSF will provide a rich architecture for UI developers, it will be limited in functionality and will provide only a small set of UI components. To more fully address the requirements of enterprise applications, developers will have to create libraries of reusable user interface components, component libraries, and render kits.

In the next release of Oracle JDeveloper, ADF UIX technology will leverage and extend the specific capabilities of JSF to provide a sophisticated, rich set of user interface components that implement the JSF standards. In addition, applications built by use of ADF UIX with Oracle JDeveloper 10g will be automatically upgraded to the JSF architecture without any loss of functionality.

"With the rich set of components and the development environment Oracle will provide around JSF, companies will have the opportunity to figure out how to use this technology right away," Farrell says. "They won't have to wait for the standard to mature, as they did in the past. They'll be able to evaluate their current and planned applications and projects that will require new GUIs. Frankly, all of us who have worked on this specification over the years feel that it will be a no-brainer for enterprises to choose a JSF-enabled development environment to create their Web applications."