This did get me thinking, though – and let me preemptively clarify that “Yahoo is evil” is definitely not what I’m about to get at. And I truly appreciate this offering as a noble intention and a community-friendly move, rather than any sleek public image stunt. Nevertheless, if we look at it in the whole bigger picture of “where F/OSS is going today”, this is yet another instance of a big corporation leveraging its muscle to support an F/OSS project. Regardless of Yahoo’s intention, in reality, there is still the feeling of a lesser leveling playground for those other projects without any backing.

uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]” nsresult: “0×80070057 (NS_ERROR_ILLEGAL_VALUE)” location: “JS frame :: http://localhost:8080/myapp/foo.do :: anonymous :: line 0″ data: no]

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.

The messed up layout was easy to fix – I accidentally set omit-xml-declaration to true for that jspx page, so the page rendered starts with the xml declaration line before the xhtml doctype, which, of course, kicked IE into the quirks mode. (It kind of makes some hell of sense, though. After all, a page starting with xml declaration cannot possibly be an XML document, can it?)

Now, the tricky part. The YUI example page worked fine in IE, so that made me feel better because for a moment there I was panicking thinking how I wasted all the time building the page with some wrong tool. After some reducing, diffing, and turning every stone over, well, it turned out that, according to the YUI Panel document, for panels that are not dynamically created by javascript, we only need to call panel.render() without passing a parent node, but that actually only works when the panel is a direct child of document.body, which happens not to be the case in my page – once sitemesh has applied the page template, what used to be the body becomes wrapped in a div. The fix itself is quite simple though. Instead of calling render(), always call render(document.body).

Evidently, this,

will not put a 15px wide "moat" between an image and its border in IE 6 (works well in Firefox). The workaround is to add a 'div' around the image, and set the above properties to the div.