Monday, April 13, 2009

A Tough Lesson in AJAX, JSF and Client-Side State

Last week I learned a tough lesson in AJAX, JSF and client-side component state. This one had me fooled for the better part of a day, in part due to the complexity of debugging multiple related AJAX requests, intermittent symptoms, and the opaque nature of JSF component state. Here's what happened:

The page that was problematic has multiple tabs (rich:tab), some combo boxes (h:selectOneMenu), and at least one suggest control (rich:suggestionbox). The tabs are server-side AJAX tabs. The suggest control also uses AJAX.

To reproduce the problem, the user takes the following steps:

  1. Use a suggest control to select a value on the first tab of a
    multi-tab form
  2. Switch tabs to a different part of the form
  3. Press a button on the form in the 2nd tab

At this point the application complains with validation errors on the first tab. The experience is very confusing to the user: after switching tabs successfully with no errors, pressing a button on the second tab causes validation errors on the first tab. This should never happen in the application: validation is designed to occur only for components that are submitted. When the button is pressed on the second tab, validation should not occur for components in the first tab. So what's going on?

Here's what I expected to happen:

  1. The AJAX suggest control sends requests and renders itself
  2. The tab sends requests and renders its contents
  3. The button submits the form to make a request

Here's what really happened, depending on timing of the requests:


  1. The AJAX suggest control sends a request
  2. The tab sends a request
  3. The browser receives the response from the tab click and re-renders the tab and its form controls
  4. The browser receives the response from the suggest control

After receiving every response the DOM is updated to contain the new JSF component state (remember: we're using client-side component state, so all JSF component state is stored in a hidden form parameter in the browser).

Due to out-of-order responses, the component state was being set to that of the first tab by the suggest control -- thus the application thinks that the current tab is the first, not the second as we would expect. Pressing the button on the second tab results in the application interpreting the submitted form as submitting values for components on the first tab. This is problematic for HTML <select> controls, since HTTP parameters are not submitted for <select> controls where no value is selected.

So how do we fix this problem? Have all AJAX controls use the same request queue. This is achieved by setting the attribute eventsQueue="myApplicationEventQueue" on all of the richfaces AJAX controls. By doing so we end up with the following sequence:


Lesson learned: AJAX requests update JSF component state on the client, and thus must all complete in sequence. Otherwise component state on the client can get out of sync with what we expect it to be.

2 comments:

Casper Bang said...

In general I find JSF troublesome for a variety of reasons, most of them relating to the client-server state mixture.

István said...

hi,

please try to make ChangeValueListener, and either inside a form, with onChange="this.form.submit();" or with (if JSF2) you could have the values in backing bean
the problem is, the JSF-framework itself in my opinion is not assigned for the web so well. You could achieve FAR better results with default CSS,javasript and servlets (which GWT and the others do)