> I have some server-side code that responds to certain ajax requests by
> returning the html of new rows to insert into an existing table. This
> works really well, but I've been thinking about ways to handle
> "errors" on the server side. By "errors" I mean both actual bugs, and
> business rule violations that mean you can't save a record (for
> instance).
>
> Prior ajax apps I've done have returned xml data that gets rendered by
> the client, not html. Each response has both data and status sections,
> and status does nicely for passing back errorCode, errorText, and
> errorDetails.
>
> In my current case, the expected ajax response is pretty specific dom
> content -- a set of table rows, as html. It can't just suddenly be the
> html of a failure alert, or an xml or json data structure, at least
> not with establishing some conventions about how the client can know
> that that's what it is.
>
> If we want to stay in the html-response domain, I was thinking of
> having two classes of non-dom-insert response, indicated by containing
> the response in a div with an agreed-upon css class. So if the
> response starts with <div class="ajaxMsg">, the client should present
> it as an unobtrusive msg to the user (jGrowl etc), instead of doing
> whatever it usually does with these responses. Similarly, if it starts
> with <div class="ajaxError">, it should be presented as a blocking,
> in-your-face "dialog".
>
> An alternative would be for the server no to return html in these
> cases, but instead return xml or json with some agreed-upon structure,
> which the client would then package visually. That would standardize
> the structure and appearance of these msgs, instead of relying on
> server-side code to always return similar-looking content (you could
> standardize that on the server side instead), at the cost of encoding
> the info on the server and decoding it on the client, and some
> restriction on the structure of what you could return.
>
> A third alternative, similar to the xml/json strategy, would be for
> the server to deliver error/msg content as http headers, a "parallel
> channel" alongside the expected html. That's super easy to do on the
> server (ColdFusion back end), but so far, I haven't figure out how to
> access the http headers in a jQuery ajax response. (There's a separate
> thread here about this, no responses yet.)
>
> How do you folks generally handle this? Any best practices to follow,
> minefields not to fall into? Anything at all standard in jQuery, or
> the jQuery community?
>
> Thanks.
All of those options are perfectly valid, and of course the best
choice depends on your specific situation. You can access content
headers directly on the XMLHttpRequest object in your "complete" or
"error" callback methods and it is also available in the global ajax
triggers (ajaxSuccess, ajaxComplete, ajaxError). For example:
$().ajaxComplete(function(event, xhr, opts) {
alert(xhr.getResponseHeader("content-type"));
});
I'll throw out one more choice as well, Taconite. Taconite is a
communication model that effectively allows multiple responses to a
single request. More info here:
http://www.malsup.com/jquery/taconite/Mike