OpenFaces is an open-source library of AJAX-powered JSF components, an Ajax framework and a client-side validation framework. OpenFaces is based on the set of JSF components formerly known as QuipuKit. OpenFaces is contributed and administered by TeamDev Ltd. OpenFaces is one of the dozen component libraries that are developed in the last 5 years to enhance the JSF core component library.

Ajax  is a group of interrelated web development techniques used on the client-side to create interactive web applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. The use of Ajax techniques has led to an increase in interactive or dynamic interfaces on web pages.

Almost all OpenFaces components have built-in ajax functionality by using an optional attribute “render”, Example: o:commandLink; render attribute specifies what components should be reloaded after the ajax request is complete.
OpenFaces 2.0 also introduces an Ajax framework which allows adding Ajax-based interactions in cases when components’ built-in ajax capabilities are not enough. Open Faces Ajax framework addresses a common scenario where the whole page has to be submitted to perform some application-specific action and reload certain components of the page with the results. o:ajax is a non-visual component that can be used to ajaxify any JSF (or even html) component.

Here’s a simple example which demonstrates the usage of the o:ajax component:

<h:inputText id=”in” value=”#{}”/>
<h:commandButton value=”Update”>
<o:ajax execute=”in” render=”out”/>
</h:commandButton>
<h:outputText id=”out” value=”#{}”/>

Some Gotchas using o:ajax:

1. The method binding for the action that need to be executed when the event is trigger will have to implement an action listener using ActionEvent as the parameter. Frameworks such as a4j use action attributes without action listeners to achieve the same.
2. OpenFaces implementation of Ajax is strictly for in-page transitions; meaning you should use Ajax for rendering/reloading components in the same page. Other frameworks allow page transitions from the action event triggered by ajax requests; OpenFaces doesn’t. Example: if your action method returns a navigation cue for faces-config to go to another page, OpenFaces ajax request completion will not honor that. This is true for all ajax-enabled OpenFaces components as well.
3. When o:ajax is used to trigger an action on the server side (managed bean), all the components that are part of the execute attribute (explicit submission of certain components), the component that’s triggering the ajax call, and the components that are part of the render attribute (the components that need to be redrawn) get submitted to the managed bean as part of the ajax life cycle. This causes issues for a very common use case where possible values for a component are dynamically returned from the server using ajax. This use case will not work with o:ajax implementation as the target component value will also be submitted to the life cycle, and they may fail validation (if the component is subjected to a validation), and basically the action will never happen. A big shout out to the OpenFaces developers! They quickly responded to our request and added an attribute declaration for o:ajax to handle this very common use case; executeRenderedComponents, that you can use to turn off value submission of the rendered components during ajax request.
4. All components involved such as the ones triggering the ajax request, the ones specified in execute attribute, and the components specified in render attribute should be located in the same form!
5. Use of o:ajax with components from other frameworks such as RichFaces is unpredictable.

o:ajax plays well with all the other JSF components and o:defaultProgressMessage (please wait message that you may want to use to convey the user that the ajax request is in progress).

We still think that there will be use cases where the ajax request action have to result in a transition conditionally. Example, ajax request is invoked with specification of what component to be rerendered after the request is complete. The request is binded with an action method which based on a certain condition will result in a navigation to a different page. In most cases, the behavior will be to render the component(s) specified in the request. If o:ajax can support that use case, I think you can pretty much implement all variations of ajaxification using o:ajax.