The Path to Zen

X-JSON header useful in AJAX dialog submission flow

One AJAX page I’ve been playing with has this UI flow that emulates a desktop form dialog - the user clicks on a link, a modal dialog shows up with a usual form, which the user fills out and submits to the server. Now, a successful response from the server can be one of these: if there are any form validation errors, the response is the same form annotated with the error message(s), in this case the response should be used to refresh the dialog. If there are no errors, the dialog is closed, and the response from the server should contain some content to update the area above the original link the user clicked on.

The tricky part - at least trickier than I thought - in implementing this whole thing turned out to be how to establish a consistent and non-hacking way to distinguish between a response with form validation errors and one without. Even though most AJAX toolkits today provide nice wrappers around raw HttpXMLRequest calls, and will invoke appropriate callback in the case of success or failure, they can’t help in this case, because whether there are validation errors or not the response would always appear successful to the wrappers. So I’m pretty much on my own to figure out a way to tell.

The simplest and most obvious way is to search for some magic word, e.g., some particular id in the response text that only appears in one of the responses. But somehow that sounds a bit hacking to me. And it’s not a very generic theme. I wouldn’t want to hand pick some magic word for each scenario like this.

Next I ruled out wrapping entire responses in JSON on the ground of scary escaping pitfalls.

So how about wrapping the responses in an XML element called, say, AjaxResponse? Then on client, I can parse this into an XML DOM element, take a look at its ’status’ attribute, and if it’s success, close the dialog, and update the div with whatever is wrapped? That actually worked - but only in Firefox, not in IE. IE appears to have some problem inserting a node into the current DOM, if the node was not created in the current window itself. In other words, the seemingly legitimate XHTML ‘div’ element wrapped in AjaxResponse cannot be inserted into the current DOM tree using someElement.appendChild(myDiv). It would return some mysterious “No such interface supported” error message. Even specifically adding xmlns:xhtml="http://www.w3.org/1999/xhtml" to the ‘div’ element wouldn’t make IE know any better.

At last, I came to the solution the prototype javascript library uses in its connection manager package - an X-JSON reaponse header. It works like an out-of-band channel between the server and client. A piece of JSON data is set into the header by the server code (in either the form controller or the jsp page), and evaluated in the client javascript. Due to the limitation on how many characters can be sent in any http header, it’s not ideal for sending along large amount of data, but perfect for all other cases, such as mine. All I have to do is putting a status variable in there. The client would evaluate the JSON and decide accordingly whether to close the form and use the response body to populate a div in the main page, or to keep the form open and use the response body to show the form again. Even though I use Yahoo UI Library instead of prototype to handle ajax calls, this is very easy to implement, and generic to be reused in all the form handling scenarios. The best part is, of course, that it’s separated from the response body, which can remain simply whatever content xhtml the client can use to fill out a div area. Another bonus from this approach is that, since all the data particular to the AJAX call are separated into the X-JSON header, the same jsp form page is AJAX-agnostic, and can be reused in other non-Ajax pages.