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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 26 Oct 2008, at 12:33, Cory Wilkerson wrote:> > 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? >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> * 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 > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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.) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---