Ajax Failure Idiom

Rails
1

Folks,

Curious what the current state of the union is with regard to ‘failure’
idioms for an AJAX call in 2.0 land.

For example, let’s say I have a simple form_remote_for that posts to
session_controller.rb that validates user credentials and, upon
successful validation, redirects that use to some landing page. That’s
the happy path - now wondering what to do if the validation fails:

  • Return some sort of internal xml that indicates things have failed
    using respond_to? and parse the XML/update the page accordingly?

  • Set the http response code to something in the 4XX range - invoke a
    failure callback?

  • Something else I’m not thinking of entirely?

Haven’t been near this in a while and was wondering what the current
practice du jour is…

Thanks for any help/insight,
CW

2

On 26 Oct 2008, at 12:33, Cory W. wrote:

the happy path - now wondering what to do if the validation fails:

  • Return some sort of internal xml that indicates things have failed
    using respond_to? and parse the XML/update the page accordingly?

Well in a case like this i don’t think you need anything smart. In the
successful case you page.redirect_to somewhere, in the failure case
you page.replace_html or page.insert to add an appropriate error
message somewhere.

In the case where the client side code has more smarts things are a
little different.
Personally I use the X-JSON header quite a lot to convey meta data to
the client and use RJS very little, ie the body of the response is
nearly always a chunk of HTML or JSON, the json contain in the X-JSON
header lets the client side code know what to do with it.

  • Set the http response code to something in the 4XX range - invoke a
    failure callback?

That can also be appropriate, although I would save that for actual
errors (eg I couldn’t talk to some server) rather than for something
like a failed validation. You can use Ajax reponders if you just want
a generic something bad action (eg show a message to the user).

Fred

3

I dont know of a commonly used pattern for this, all of your suggestions
seem okay. Of course you don’t need to parse xml and then update an
element, in a lot of situations just returning an html fragment and
update some element directly will suffice. In an application I developed
recently, which excessively uses the ExtJs framework, I use JSON
responses like Frederick suggests. (Be aware of Javascript Hijacking if
you use JSON for exchanging data, though it’s not neccesarily a problem
when it only contains error messages.)

4

Sjoerd A. wrote:

I dont know of a commonly used pattern for this, all of your suggestions
seem okay. Of course you don’t need to parse xml and then update an
element, in a lot of situations just returning an html fragment and
update some element directly will suffice. In an application I developed
recently, which excessively uses the ExtJs framework, I use JSON
responses like Frederick suggests. (Be aware of Javascript Hijacking if
you use JSON for exchanging data, though it’s not neccesarily a problem
when it only contains error messages.)

To make this a little more tangible; this is similar to my approach:

rescue_from Exception do |e|
respond_to do |format|
#…handle different formats
format.js { render :json => {:error => e.to_s}.to_json, :status =>
500 }
end
end

Then in my Ajax callback method when a 500 is returned I know there’s an
‘error’ property on the returned JSON object, of which the value can
then be inserted into an element, or whatever else you want to do with
it.