Ajax Failure Idiom

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

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

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.)

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs