In an effort to provide developers with a productive environment, Oracle has been working on a very rich UI component framework for several years. This framework - ADF Faces - has now been donated to the open source community. More precisely, it has been donated to the Apache Software Foundation and is currently hosted in the Apache Incubator - http://incubator.apache.org/projects/adffaces.html. Craig McClanahan is mentoring the project during the Apache incubation. The Apache MyFaces community is also involved in the project to assist with graduation from the incubator, into the Apache MyFaces "ADF Faces" subproject.

What is ADF Faces? ADF Faces is a comprehensive, free JSF component library. This library contains 12 helper objects such as converters and validators, and 93 components ranging from simple input components to complete page components with built-in menu model support. In addition, ADF Faces provides a set of extended services such as a dialog framework and a skinning framework.

In a series of articles we will be deep diving into various aspects of this donation and give developers insight into its internal functionality and how to use and extend ADF Faces. In this first article we discuss the HTML AJAX RenderKit provided by this JSF component library.

The ADF Faces HTML AJAX RenderKit
As most of you probably know by now, AJAX is a new phenomenon, but the technologies that make up AJAX are not. AJAX, for those who don't know, is a technique that uses native browser technologies to provide highly interactive user interfaces and to asynchronously communicate with server-side logic.

Since the technologies backing AJAX have been around for quite some time, there have been AJAX solutions available long before the term was coined. One of those is the ADF Faces "AJAX" RenderKit. This solution has been called partial page rendering (PPR) and has been used by Oracle and its customers for several years. Instead of re-rendering the entire page on a postback, PPR will only update a portion of the page.

With AJAX, or PPR, application developers can then provide a rich and interactive, desktop-like user interface on the Web.

Practical Benefits of ADF Faces AJAX RenderKit
To fully appreciate the benefits that the ADF Faces AJAX RenderKit provides, we first need to look at some of the common problems end users are facing with a traditional Web application.

Problems with Full Page Refresh
End users normally spend time waiting for a server response without being able to do anything else, and, if they do, it might actually cause problems, like double-submit. The scroll position and focus in the page are usually lost even when the same page is redisplayed after a user interaction such as expanding a tree node. Validation is usually delayed until the user explicitly presses submit, and then he or she has to wait for the response and scroll back to the input field with the error message to fix the problem.

With an AJAX JSF solution, all of this can be addressed with little or no effort from the application developer and a great outcome for the end user. The ADF Faces AJAX RenderKit addresses these issues by asynchronously updating only portions of the page, and by keeping track of the form post (basically controlling whether a form post has occurred). The partial update of the page keeps the scrollbar position and the focus, and provides instant validation of user input.

Using the ADF Faces AJAX RenderKit
Creating an application using the HTML AJAX RenderKit provided by the Apache "ADF Faces" Incubator project is easy. There are two ways of achieving a partial update - declaratively and programmatically. Let's first look at the declarative approach.

Figure 1 illustrates the application we are going to build in this article. It contains a dropdown component that lists a set of JDJ articles and a graphic component that shows the featured images for each article. When an end user accesses this application and selects an article to read, only the image is updated, not the entire page. As shown in Figure 1 this adds the benefit of a kept scrollbar position when the end user changes from one article to another. Furthermore, focus is still set on the dropdown list, allowing the end user to continue to use the dropdown list without the need to reselect it.

The JSP source for the page displayed in Figure 1 in shown in Listing 1. Using the declarative approach, the application developer needs only to ensure that there is a unique identifier for the "triggering' component - <af:selectOneChoice> - in this example selectArticle, and that the component targeted for partial update includes this identifier in the partialTriggers attribute. That's it!

Programmatically Adding a Partial Target
In response to a partial event, only components registered as partial targets are re-rendered. With ADF Faces, application developers can also dynamically add components to the list of partial targets by calling the addPartialTarget method from the AdfFacesContext as shown in the following code.

AdfFacesContext adfContext = AdfFacesContext.getCurrentInstance();
adfContext.addPartialTarget(target);

Let's expand our page with an <af:outputText> component. This component will show an excerpt of each selected article. This time we won't use the declarative approach, instead we'll dynamically add the component to the list of partial targets for the <af:selectOneChoice> component.

In Listing 2, a valueChangeListener has been added to the <af:selectOneChoice>, and a <af:outputText> component has been added underneath <af:selectOneChoice> to provide the excerpt of the selected article. In this case the <af:outputText> component does not include the partialTrigger attribute.

The valueChangeListener in Listing 3 ties it all together by adding the outputText component as the partial target to the selectOneChoice component.

The updated page will now contain a description field that will be part of the partial update when the end user selects an article from the dropdown list.

In Figure 2, note that the scrollbar maintains the same position after the partial postback and that the description has been updated.

The Internal Implementation Design
When a page containing ADF Faces components is accessed for the first time, the initial page render includes a hidden iframe element. This hidden iframe is used to manage the partial update of the page. When a commandButton is clicked, the form is still submitted but targets the hidden iframe instead, and additional information is included in the request to let the AJAX RenderKit detect that a partial response is expected.

During the ApplyRequestValues phase in the Faces Lifecycle, the AJAX RenderKit determines that this is a partial request and decorates the ResponseWriter with a PPRResponseWriter implementation (see Figure 3). The purpose of this is to "clip" the rendered markup to produce only the markup fragments for those components that should be included in the partial response back to the iframe.

Each markup fragment is identified by HTML ID, which is used to find the original section of the HTML DOM that needs to be replaced. Figure 4 shows a DOM inspector and the iframe structure of the partial response for the page created in Listing 2. Note the ID match of each fragment e.g., _id5:selDesc and _id5:selImg.

Challenges Addressed by Choosing <iframe> over XmlHttpRequest
Much of the success of AJAX has come from the widespread availability of XMLHttpRequest (XHR), and many people believe that XHR is a required strategy for AJAX. However, AJAX is simply defined as using native browser technologies (no browser plug-ins) and asynchronous communication with the server. This is also possible to achieve using a hidden iframe, which provides some additional capabilities but with some additional issues as well.

The main functionality that is much more easily supported by the hidden iframe communication channel is file upload. For security reasons, JavaScript executing at the browser is not permitted to read the contents of the local file system. So, when using a plug-in free browser environment, uploading a file from the local file system must leverage the <input type="file" ... > native browser support, which requires the form to be submitted so that the file contents will be sent to the server. Using a hidden iframe allows ADF Faces to target the form submission at the iframe instead of the main document, so that the response from the server is received by the hidden iframe. Of course, the same approach works for any type of form submission, not just file upload input elements.

One of the difficulties introduced by using the hidden iframe communication channel is the problem of knowing when the response is complete. Fortunately, since the PPR response is managed by the AJAX RenderKit, it is straightforward to include an additional script block at the end of the response received by the hidden iframe that will inform the main HTML document when the response is complete. In the rendered response a callback function is added (see Listing 4).

Compatibility with Non-ADF Faces Components
How generic is this functionality? Does it only work with ADF Faces components? What happens when you try to use other components, such as the Apache MyFaces Tomahawk or Tobago component libraries?

Fortunately, the implementation of PPR makes no extra assumptions about the child components of any partial target. If an ADF Faces component is added as a partial target, all of its child components are also re-rendered in the partial response, no matter what component library is used.

Conveniently, any JavaServer Faces component can be added as a partial target using the programmatic API. The PPRResponseWriter will detect when this component is being rendered and ensure that the markup is included in the partial response.

Finally, adding declarative support for any JavaServer Faces component, by adding a partialTriggers attribute, requires only minor modifications to the component API and JSP Tag to expose the attribute and a call to AdfFacesContext.addPartialTriggerListeners in the Renderer.

Conclusion
This is the first successful implementation of AJAX in JSF and, as discussed in this article, is currently used by the ADF Faces component library. This type of architecture relies on a regular form submit. The response is in fragments that contain the information about what is needed for the change. The PPR handler will then figure out where to slot in these changes. This approach is straightforward to use, allowing the application developer to control what components are involved in each partial update. In this architecture, the unit of update is a UIComponent subtree, so the markup for each UIComponent subtree is replaced for each partial target. PPR is also relying on iframes, not XMLHttpRequest, to provide asynchronous communication, which has the benefit of supporting older versions of browsers.

What is interesting is that Oracle announced intentions to donate a new generation of ADF Faces components to the open source community at JavaOne 2006. In contrast to the components discussed in this article, these new components leverage the XMLHttpRequest object to provide AJAX JSF components.

Finally, we believe that MyFaces "ADF Faces" will become the most dominant open source JavaServer Faces component library on the planet. The question is: How will you contribute?