Web 2.0 with Oracle ADF Faces - Ajax Without Ajax

Written by Frank Nimphius, Oracle Corporation
January, 2007

Introduction

Hard to believe that once there was a life without the Web. Today the Internet is the first stop for communication, information retrieval, and business activities. For many, the Internet has become equally important as electricity. Web 2.0 is the latest paradigm shift in the development of web-based applications. Web 2.0, in comparison to Ajax (Asynchronous JavaScript and XML), does not describe a technical implementation but stands for a new generation of web technology that puts unprecedented levels of interaction into the browser. This new technology extends the user's ability to collaborate and to assemble content to mash-up sites. Ultimately, Web 2.0 makes possible rich, desktop-like user interfaces on the Web.

Ajax is one of the possible technologies that can be used to implement the Web 2.0 vision, and probably the most prominent. This does not imply that Web 2.0 is dependent on Ajax. However, today, analogous to how Web Services represent the main implementation technology for Service Oriented Architecture (SOA), Ajax is the de-facto implementation standard for Web 2.0 applications. But, what exactly is Ajax?

What is Ajax?

By definition, Ajax as a technology consists of asynchronous JavaScript and XML. Yet in practice there is more to it than that. The following is a list of technologies that I will refer to as Ajax-associated technologies: XmlHttpRequest object, JavaScript, Stylesheet (CSS), XML, JSON, and IFrame. All of these technologies are commonly used when building Ajax applications.

The browser side XmlHttpRequest object is used by Ajax applications to asynchronously fetch new content from a remote server. The asynchronous nature of the Ajax request, in combination with clientside JavaScript DOM (Document Object Model) manipulations, allows developers to build highly responsive web UIs that refresh without requiring the page to reload.

Ajax is not only about technology. Like other areas of engineering, Ajax technologies are of no value if used improperly. Several published Ajax programming and architectural patterns help to describe the behavioral aspect of Ajax. Ajax in fact consists of two parts: basic technology and a desired behavior. Within the Ajax development community, behavior is often referred to as ajaxian, where ajaxian behavior is achieved through Ajax-associated technologies. For example, an Ajax pattern that describes the creation of unambiguous URLs for CRUD (create, read, update and delete) operations is REST (Representational State Transfer). While the pattern for unambiguous URLs is not a pure Ajax pattern (it is also found when working with SOA services), it is a pattern that applies to Ajax.

Another example is the use of IFrames for client to server interaction. IFrames are HTML elements that define embedded areas within an HTML page. Each of these areas has a src attribute pointing to a remote server address. In Ajax, IFrames are used for example to upload binary data like images from the client to the server, which cannot be handled in XmlHttpObject requests directly.

Building Ajax Applications with ADF Faces

Oracle ADF Faces provides a rich set of more than one hundred JavaServer Faces UI components that go beyond what is available in the JavaServer Faces reference implementation today. Just one example of the additional functionality provided by ADF Faces and MyFaces Trinidad, the open source branch of ADF Faces, is Partial Page Refresh (PPR).

Partial page rendering (PPR) allows small areas of a page to be refreshed without the need to redraw the entire page. In ADF Faces components, the ajaxian behavior is implemented by a hidden IFrame, which is automatically added to a web page when one of the following ADF Faces elements is used: af:document, afh:body or af:panelPartialRoot.

Two main Ajax patterns are implemented with PPR: cross-component refresh and single component refresh. Cross-component refresh is implemented declaratively or programatically by the application developer, who will define ADF Faces UI components to act either as a partial listener or as a trigger. Many ADF Faces components have partial refresh functionality implemented natively. For example, the ADF Faces table component comes with built-in "Ajax" functionality that lets you scroll through the table, sort the table by clicking on a column header, mark a line or several lines for selection, and even expand specific rows in the table -- all through declarative property settings with no coding needed.

The following are three main component attributes used in partial page rendering:

• autoSubmit
  When the autoSubmit attribute of an input component (such as inputText and selectManyListbox) or a table select component (such as tableSelectMany) is set to true, and an appropriate action takes place (such as a value change), the component automatically submits the enclosing form. For PPR, you might use this in conjunction with a listener attribute bound to a method that will perform some logic when an event that is based on the submit is launched.
  
• partialSubmit
  When the partialSubmit attribute of a command component is set to true, the page partially submits when the button or link is clicked. You might use this in conjunction with an actionListener method that performs some logic when the button or link is clicked.
  
• partialTriggers
  The value of this attribute is the ID or IDs of other components. Use a space between multiple IDs. When those components are updated (for example through an autoSubmit), this component will also be updated. All rendered components support the partialTriggers attribute.

Figure 1: Native PPR behavior in table detail stamp and range navigation

An example use case for cross-component ADF Faces partial page refresh is a master drop down list triggering the content refresh of a detail drop down list. With each value change in the master list, the detail list gets refreshed too and no page reloading is required. Like pure Ajax applications, PPR in ADF Faces leverages clientside JavaScript to achieve the partial content refresh.

And unlike raw Ajax development, ADF Faces applications leverage the benefits of the JavaServer Faces framework--such as the server-side event model that may notify interested parties of value changes, or automatic page state saving. With ADF Faces, the benefits inherited from the JavaServer Faces framework shield the developer from having to code a manual implementation.

Example: Building Ajaxian Behavior with ADF Faces

As an example, a vacation planner uses two list boxes to show departments and employees. Upon application startup (1) both lists are populated with default selections through the JavaServer Faces value binding, which is an ExpressionLanguage reference to either a managed bean or, if you work with Oracle ADF, the bindings object. When the user selects a new department from the master list (2), a partial submit is sent to the server to issue the request. The page does not reload when this happens. In JavaServer Faces, the detail list is updated to reflect the change in the master list. The new content is then uploaded to the client (3) and replaces the existing detail list with the updated values. The page still does not reload.

Figure 2: Ajaxian inter-component communication in ADF Faces

To make the above example work, the application developer needs to do two things:

1. Specify the master poplist as a partial trigger by assigning a value to its ID property and setting the AutoSubmit property to true. The partial submit raises a ValueChange event on the ADF Faces component that is handled in a managed bean.

2: Setting the ADF Faces component Partial Trigger property to the value of the ID of the partial trigger component. This second declarative programming task identifies the second list as a partial target. A partial target listens for a specific event being raised from a registered component. This registration is done by the developer.

Figure 3: Declarative inter-component PPR programming

This is all that needs to be done to build Ajax like behavior in ADF Faces. No cumbersome JavaScript coding is required.

In the next version of ADF Faces, PPR will leverage the XmlHttpRequest object for the Ajax client to server communication. Some functionality, such as file uploads, will still require the use of IFrames in the underlying implementation. This however is nothing that the developer needs to be concerned about as it will all be handled automatically by ADF Faces. From an application developer point of view, ADF Faces is Ajax for everyone!

Building Web 2.0 Applications with ADF Faces

As stated earlier, Web 2.0 isn't about technology. Using ADF Faces with PPR and Oracle Web Center in JDeveloper 10.1.3.2, application developers build state of the art Web 2.0 applications and mash-ups. Using the free Oracle JDeveloper IDE, Web 2.0 applications developers build and assemble within a single environment that supports declarative, visual, and code-centric development. The advantage of using ADF Faces when developing Web 2.0 applications is that the application developer can focus on the business application to build and not on how Ajax patterns are implemented. This way ADF Faces shields developers from ajaxian implementation details increasing developer productivity and performance.