Page 1 of 2   next page »

In our last article - "JSF and AJAX" (JDJ, Vol. 11, issue 1) - we discussed how JavaServer Faces component writers can take advantage of the new Weblets Open Source project (http://weblets.dev.java.net) to serve resources such as JavaScript libraries, icons, and CSS files directly from a Java Archive (JAR) without impacting the application developer.

In this article we'll address the need to fetch data using AJAX with JavaServer Faces (JSF) components. The most common use cases for fetching data with AJAX are to populate dropdown lists and add type-ahead functionality in text fields. In contrast to using AJAX postbacks for events, fetching data shouldn't affect the surrounding components on the page. And if fetching data isn't affecting other parts of the DOM tree, then you don't have to go through the full JSF lifecycle just to get the data, right?

This article introduces for the first time a new Open Source project called Mabon hosted on the Java.net Web site (http://mabon.dev.java.net). Mabon stands for Managed Bean Object Notation and its goal is to provide component writers of AJAX-enabled JSF components to access JSF managed beans outside the scope of the standard JSF lifecycle by using a JSON-syntax communication channel.

In essence, Mabon provides application developers with a standard and easy way to provide data to AJAX-enabled components using the managed bean facility provided by the JSF specification.

Fetching Data with AJAX
Fetching data the conventional way versus using AJAX follows the same basic concept - it shouldn't have the side effect of changing the state of surrounding components.

Figure 1 shows an AJAX sequence diagram using the HTTP GET method. The W3C recommends that you use the HTTP GET method to fetch data when there are no side effects requested by the user (for example, Google Suggest).

Different JSF AJAX Approaches
If you get no side effects, then there's no change to the JSF component hierarchy; so there's no need to go through the JSF lifecycle. But, if you want to reuse a managed bean method, the easiest way to get to it is via the JSF MethodBinding facility. Three solutions exist to support this - adding functionality to the Renderer, using a PhaseListener, and providing a new JSF Lifecycle.

The Renderer Approach
The Renderer approach adds functionality to the Renderer to detect the AJAX request. The JSF default lifecycle first restores the component hierarchy during the Restore View phase and the Renderer takes control during the Apply Request Values phase. After the AJAX request has been processed, the Renderer calls responseComplete() on the FacesContext to terminate processing of remaining phases of the Lifecycle. On the surface this may seem like the preferred approach, but it has some severe drawbacks.

A component hierarchy is required, which can incur additional overhead for each request, especially when client-side state saving is used. Calling the response-Complete() method will take effect only after this phase is done processing. The Apply Request Values phase calls the decode() method on all Renderers in the view, which can cause undesired side effects that are out of your control, such as a <h:commandButton> set to immediate="true" by the application developer. This causes the application logic to be called before the Apply Request Values phase is complete.

This approach also usually requires HTTP POST to send the state string back to the server.

The PhaseListener Approach
The PhaseListener approach adds a PhaseListener (PhaseId.RESTORE_VIEW) that short-circuits the Lifecycle and does all the processing in the PhaseListener itself. When it's done, it calls responseComplete() on the FacesContext.

For this approach to work, it has to render a reference containing information about the managed bean used in the initial request. The PhaseListener uses this information during postback to create a MethodBinding that can then be used to invoke a method on the managed bean and return data to the client. Since no component hierarchy is created, and thus no Renderers, there's no risk that command components with immediate set to true will cause any side effects.

But this approach has one issue; there's no way to prevent application developers from attaching additional PhaseListeners at the same phase, which can cause undesirable side effects. You also have no way of knowing in which order these PhaseListeners will be executed.

The Lifecycle Approach
This Lifecycle approach adds a new Lifecycle that's mapped to an AJAX request and contains only the lifecycle phases needed to process the request, invokes the application logic defined by a MethodBinding, and renders the response. This eliminates the overhead of creating and restoring the component tree, and so no Renderers are required. You also won't encounter any issues with immediate="true".

Another positive side effect of using a custom Lifecycle is that any PhaseListener added by the application developer will have no impact on this solution; application developers can even add PhaseListeners to this custom Lifecycle. However, if a custom PhaseListener is used to put additional managed beans on the request, you can run into issues, unless they're registered for the custom Lifecycle as well.

Select a JSF AJAX Approach
Here we use the Lifecycle approach, since it has no application logic side effects and low overhead. It's here that the Mabon Open Source project can help you focus on the design of your AJAX-enabled component.

Let us explain in a little about what Mabon is and what it can provide component writers interested in AJAX data fetch (Figure 2).

What Is Mabon?
Mabon offers a convenient way to hook in a specially designed lifecycle that's ideal for AJAX-enabled components that have to fetch data directly from a backing bean, without the overhead of a full JSF lifecycle. It also provides a Mabon protocol - mabon:/ - used to reference the backing bean and a JavaScript convenience function used to send the target URL and any arguments needed and then get data asynchronously from the managed bean.

Mabon and JSON
As you know, the XMLHttpRequest provides two response types - responseText and responseXML - that can be used to fetch data. The question to ask is; when should I use which? Answers to this question can differ depending on whom you ask, but we can recommend one guideline. Ask yourself if you control the syntax of the response.

The responseXML type returns a complete DOM object (which gives you ample ways of walking the DOM tree), letting you find the information needed and apply changes to the current document. This is useful when your component will impact surrounding elements and you don't control the response (for example, when you're communicating with a Web Service).

The MabonLifecycle Class
The MabonLifecycle consists of three phases - ApplyRequestValuesPhase, InvokeApplicationPhase, and RenderResponsePhase. The MabonLifecycle is responsible for executing these three phases. It's also responsible for handling any PhaseListeners attached to the MabonLifecycle.

The LifecyclePhase Class
The Mabon LifecyclePhase is the base class for all lifecycle phases.

• The ApplyRequestValuesPhase, InvokeApplicationPhase, and RenderResponsePhase Classes - Since you're only fetching data and not modifying the component hierarchy or the underlying model in any way, you don't need to include the Restore View, Process Validations, and Update Model phases. The Mabon phases are performing similar operations to the default lifecycle equivalents, such as decoding an incoming request, invoking application logic, and rendering the response.
• The FacesLifecycleServlet Class - This is a reusable servlet that will initialize the FacesContextFactory and look up the MabonLifecycle in its first request. It will create the FacesContext then invoke the three lifecycle phases that are part of the MabonLifecycle. The servlet mapping defined by the Web application will direct Mabon requests to this FacesLifecycleServlet.
• The LifecycleFactoryImpl Class - The only purpose of this class is to add a second lifecycle - the MabonLifecycle.
• The MabonViewHandler Class - During the initial rendering, a custom Renderer has to provide a path to the backing bean that can be intercepted by the FacesLifecycleServlet and used during InvokeApplicationPhase to call the referenced backing bean. By using the Mabon protocol, a component author can get a unique path from the MabonViewHandler that can be rendered to the client. If the component writer passes the string shown in Code Sample 1 with the path argument of the ViewHandler.getResourceURL() method, the MabonViewHandler will return the string shown in Code Sample 2 that can be written to the client.

Page 1 of 2   next page »