Forum: Ruby on Rails Ajax Failure Idiom

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ee7be48e775d357de69db2754a377160?d=identicon&s=25 Cory Wilkerson (corywilkerson)
on 2008-10-26 13:33
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
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2008-10-26 13:45
(Received via mailing list)
On 26 Oct 2008, at 12:33, Cory Wilkerson 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
5acba71393125496e93b9e434d8b63c9?d=identicon&s=25 Sjoerd Andringa (s-andringa)
on 2008-10-27 21:25
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.)
5acba71393125496e93b9e434d8b63c9?d=identicon&s=25 Sjoerd Andringa (s-andringa)
on 2008-10-27 21:35
Sjoerd Andringa 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 topic is locked and can not be replied to.