Jsf

This article is meant to acquaint the reader with JavaServer Faces, commonly known as JSF. JSF technology simplifies building the user interface for web applications. It does this by providing a higher-level framework for working with your web app, representing the page as event-aware components rather than raw markup. At this time, there are two JSF variants: JSF early access 4 (which is included in the Java Web Services Developer Pack 1.3), and JSF 1.0 Beta. It's important to remember that JSF is a specification, much like J2EE. And like J2EE, there is a reference implementation from Sun, along with other implementations of the interface, such as the open source MyFaces. This article is concerned with the distinctive features of the JSF specification and its ideas, not with a particular implementation. After all, since JSF is not yet final, the specifics might yet change. We assume the reader is already somewhat familiar with Java programming, servlets, JavaServer Pages (JSPs) and custom tag technologies. The reader should be experienced with servlet/JSP containers such as Tomcat, and design patterns such as model-view-controller (MVC).

Roles in Web-Application Development In developing web applications, we often deal with the same problems. First off, the interface is the most frequently updated part of the application, so we want to simplify modification of the interface as much as possible. Secondly, those developing the application have significantly different skill sets — server-side programmers, HTML coders, graphic designers, etc. — and we want their work to be as independent as possible. This leads to a model-viewcontroller design to separate the roles. In many organizations, the development of a web application works in a familiar manner. The designer creates a prototype, the HTML coder does everything in HTML, and the server-side programmer achieves his or her needed functionality in Java. This approach often fails badly. The designer, when creating the prototype, is limited only by his or her imagination, inadvertently causing problems for the other participants, often forcing them to start from scratch when developing a new application.

Reusable Components Even if the problem of role division can be solved in existing frameworks (for example, by using custom tags or XML/XSL transformations), there can still be a problem with code reuse. So what's so different between creating the GUI for a Swing application and a web application? It's obvious: in Swing, there is a set of standard GUI components and an entire infrastructure for tweaking and extending the functionality. A Swing developer works with the concept of a Component — an element of the user interface, such as a panel, button, list, or table — and can either set values to use the default behavior or extend the component to provide new behavior. Some of these components, specifically Containers allow combinations of components, such as a panel with a table that contains buttons in some of its cells. As an added bonus, the developer gets to work with high-level concepts: when the button is clicked, an event is generated. Meanwhile, for the web developer to know the button has been pressed, he has to analyze the HTTP request and try to determine what has happened. This is not ideal. The programmer shouldn't have to work so hard to figure out if a button, image, or hyperlink was clicked, or how these pieces were implemented in HTML. Ideally, the developer just wants to know that an event occurred. In other words, the developer needs to be able to see the web interface in terms of familiar high-level concepts.

This is the problem JSF aims to solve.

The JSF Approach The following presentation of JSF concepts is based on the most recent specification (dated Dec. 18, 2003). The core JSF architecture is designed to be independent of communication protocols or markup language specifics. However, it's also meant to solve the problems experienced working with HTML clients communicating via HTTP with a Java application server that supports Servlet/JSP applications. JSF aims to provide the following features to simplify application development:

• • • • • • •

Handling of UI components between requests. Consideration of markup features supported by the client/browser. Support for processing forms. Strictly-typed event model. Transformation of data on the page (Strings) into the models' corresponding data types. User-friendly exception handling. Navigation between pages based on UI events and interaction with data models.

Of course, when developing web applications today, everyone has to deal with these problems, and everyone solves them in their own way, increasing development time and hurting maintainability. JSF tries to offer a unified way to deal with these issues. The specification understands the importance of dividing software development roles and assigns responsibilities to these roles. Page Authors Page authors are responsible for the appearance of the application. They should understand client-side markup (HTML and JavaScript) and also page structure during development (such as JSP). Page authors usually create pages from ready-made components delivered by component developers, modifying them to achieve the desired appearance. Component Writers Component writers (a.k.a. Component Developers) are responsible for creating reusable UI components. They are thus responsible for:

• • •

Making components "understandable" to the final client (e.g., providing HTML to a browser). This process involves encoding information from the application. Making the application understand the request form, by decoding the information in a request. Reacting to events received by a component and understanding when such an even has occurred.

Application Developers Application developers are responsible for the server-side tasks, such as creating an application's business logic, its persistence layer, etc. They should develop appropriate Java

objects to represent the desired functionality, and make these objects accessible from servlets. Tool Providers Tool providers supply tools like IDEs that facilitate creating JSF-based applications, or even higher-level frameworks that might use JSF to create their user interface. JSF Implementors JSF implementors are responsible for implementing all the required specifications of JSF. For example, they might provide a JSF implementation within their J2EE server. Note that most developers will not perform either of the latter two roles. But they indicate the seriousness of Sun's intentions with respect to role-division: for JSF to succeed, it's necessary to follow the role-division guidelines.

JSF in Detail Let's look in detail at what JSF provides us. As noted above, the highlight of JSF is the availability of reusable server components for creating GUI's. From JSF's point of view, all components should inherit from javax.faces.component.UIComponent (note that in the EA4 release this was an interface). Any page or screen of the application will consist of a set of such components. A set of hierarchically ordered components is called the JSF Tree (EA4's term) or the View (1.0 beta's term). This tree of components represents the structure of the onscreen page. Each element of a tree is UIComponent, with some components being composites and thus having child components. In JSF there is a set of standard components. The UML diagram shows the notation structure of these standard components. The developer can create new components based on existing components (for example, by inheriting from UIOutput), or by a completely new subclass of UIComponent. To make creating components easier, it's possible to inherit from UIComponentBase, which contains default implementations for the methods in UIComponent along with some convenience methods. If a hypothetical page will contain a form with an input field and a button, then the JSF components' structure will be of the form UIViewRoot → UINamingContainer → UIForm → (UIInput, UICommand, where the "→" character is understood to show a parent-child relationship. This means the UIViewRoot has a single child, a UINamingContainer (used by JSF for automatic assignment of unique identifiers), which has a UIForm child, which in turn has two children: a UIInput and a UICommand. Each component can find its parent with getParent() and its children with getChildren(). Figure 1 shows the relationship of the JSF component classes.

Figure 1. Standard JSF components. The most interesting methods of UIComponent are the following:

• • • •

decode(javax.faces.context.FacesContext context) encodeBegin(javax.faces.context.FacesContext context) encodeChildren(javax.faces.context.FacesContext context) encodeEnd(javax.faces.context.FacesContext context)

These methods are responsible for the translation of data from a request to a component and from forming a reply based on the state of a component. Naturally, implementations of these methods should be coordinated — if the encode() stores the condition of a component, then decode() should have an opportunity to read it. Despite the fact that these methods are in

the components themselves, the responsibility for encoding and decoding is usually relegate to special classes inherited from javax.faces.renderer.Renderer. These renderer classes bear the responsibility for how a given component will be presented to the user. For example, UICommand might be displayed as either a button or a link. This arrangement allows the UICommand class to remain fairly constant, while its presentation varies with the associated Renderer. Related Renderer functionality can be united in a RenderKit. For example, if you know that the client will be rendering HTML you can use the HTMLRenderKit. In fact, there are multiple kits, including SimpleHTMLRenderKit for browsers that don't fully support HTML 4.0, and AdvancedHTMLRenderKit for modern browsers. Of course, this means a given page may look different in different browsers, but the page structure (the View) does not need to be modified. It's only necessary to define a rule to determine which RenderKit to use. However, this may not be enough in some cases. The important part is the component model, which encapsulates the data with which the component works. As an example, we'll consider the javax.faces.model.DataModel that appeared in JSF 1.0 Beta. This abstract class is a wrapper for data representing Strings, accessed by index. If, for example, we needed to represent records in a database table, we could use JSF's javax.faces.model.ResultSetDataModel, an implementation of DataModel. This arrangement of a component in terms of a DataModel, its Renderer and its UIComponent represent the model, view, and controller from the familiar MVC pattern. A component can generate events and notify all interested listeners. All event classes need to inherit from javax.faces.event.FacesEvent, while all listeners implement javax.faces.event.FacesListener. So, to track the change in a component's value, we have javax.faces.event.ValueChangeEvent, which is handled by a javax.faces.event.ValueChangeListener. A concrete UIComponent provides an opportunity to register listeners on this type of event. For example, javax.faces.component.UIInput contains the method addValueChangeListener, which takes a ValueChangeListener. JSF also provides the concepts of a Validator and a Converter. The former is used to check the status of a component (for UIInput), and in the case of an error it provides a message to be shown to the user, such as "invalid phone number" or "username should only contain letters and numbers." A Converter is used to transform data from a String to some kind of object and back. For example, a model may store a date as a java.util.Date, but the Renderer changes it to a String at some stage of encoding, and at decoding time it's necessary to convert the String back into a Date. For this common purpose, JSF provides the standard converter javax.faces.convert.DateTimeConverter. JSF defines not only the possible actions involving components, but also the order of these actions. At the moment a request is received by FacesServlet, the entry-point to JSF, a lifecycle of JSF request processing begins, which consists of a set of phases, each with its own specialization:

1. 2. 3.

Restore View (previously "Restore Component Tree") -- restores a tree of components. Apply Request Values -- applies data from the request. Process Validations -- executes any validations.

4. 5. 6.

Update Model Values -- updates values of model. Invoke Application -- executes application. Render Response -- generates a response to the user.

For additional information about the JSF actions at each phase of the cycle, consult the details of the JSF specification.

A JSF Example Currently, JSP is used as the basic mechanism for formatting a page. With special JSF custom tags, we can create the structure, the component tree, and the parameterization of each component. Here's what a basic JSF page looks like:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

Enter number

/>

This page consists of a form in which we have a graphic image, an input field, and a submit button. We've also added a validator to the input field. Note that the form does not have an ACTION attribute. This is because JSF has its own navigation system. The target where the form will be submitted is defined by the button, with help from a configuration file, facesconfig.xml, which specifies that if a page transition is successful (i.e., the action = "success"), then we'll be redirected to a certain URL. Notice that this arrangement is similar to the Struts framework; developers already familiar with Struts will see the analogy between the JSF configuration file and struts-config.xml.

Conclusions JSF was developed to handle everything required for developing web-oriented applications. It's meant to be an all-encompassing solution. But it's interesting to compare the technology to existing alternatives. Struts is a well-known web framework that is something of a standard for similar projects. Much like JSF, it is based on MVC principles. However, Struts itself doesn't provide a View construction mechanism. But to its credit, Struts has a nicely implemented concept of controllers. Thus, Struts is often used in combination with other frameworks that deal with the presentation. Also, there are many frameworks available that are similar to JSF, such as UIX from Oracle. In fact, this particular framework is very similar to JSF and probably reflects Oracle's interest in web GUIs. The Oracle JDeveloper IDE supports UIX, but reportedly plans to add JSF support.

IBM's WebSphere Application Developer also supports JSF. One other framework, similar in spirit to JSF, is Tapestry, in which we can see the concepts of a lifecycle, reusable components, and rigid division of roles. In conclusion, my own opinion about JSF is that while it has incorporated the advantages of many custom tag libraries and frameworks, it has also inherited the difficulties of adjusting to a new way of coding. Granted, Struts arguably has the same problem. But since JSF isn't yet final, it's possible that it will be further improved before it's done.