Searched around this forum, but didn''t find an answer for this
question.
Can you help this newbie understand any overlap and/or difference
between request.xhr? and respond_to?
If request.xhr? is true, should I expect it wants.js below?
respond_to do |wants|
wants.html { redirect_to(person_list_url) }
wants.js
wants.xml { render :xml => @person.to_xml(:include => @company) }
end
Is it fair to say the functionality of respond_to a super set of
request.xhr?
TIA!
--
Posted via http://www.ruby-forum.com/.
short answer: no, not equivalent
longer answer:
-- request.xhr? --
check the following header in the request:
''X-Requested-With'' =
''XMLHttpRequest'',
this is set automatically by the prototype library
see line 699 in version 1.5.0_rc0
-- response_to --
check the ''Accept'' header. this is set not only by prototype
but also
by browser, spiders, etc.
looks something like ''Accept'', ''text/html,
application/xml,
text/xml, */*'']
check
Doug Dupory schrieb:> Searched around this forum, but didn''t find an answer for this
question.
>
> Can you help this newbie understand any overlap and/or difference
> between request.xhr? and respond_to?
>
> If request.xhr? is true, should I expect it wants.js below?
> respond_to do |wants|
> wants.html { redirect_to(person_list_url) }
> wants.js
> wants.xml { render :xml => @person.to_xml(:include =>
@company) }
> end
>
> Is it fair to say the functionality of respond_to a super set of
> request.xhr?
>
> TIA!
>
>
Thank you, Pete, for the explanation of where they come from! To implement graceful *RJS* degradation, does it mean request.xhr? is sufficient? Or need both? Is it possible that a broswer doesn''t set the Accept header accordingly? See http://www.ruby-forum.com/topic/65059#74833 For *JS* (in general) degradation, however, respond_to is the way to go? Doug (quite ignorant about Web UI) Pete wrote:> short answer: no, not equivalent > > longer answer: > > -- request.xhr? -- > > check the following header in the request: > > ''X-Requested-With'' = ''XMLHttpRequest'', > > this is set automatically by the prototype library > > see line 699 in version 1.5.0_rc0 > > > -- response_to -- > > check the ''Accept'' header. this is set not only by prototype but also > by browser, spiders, etc. > > looks something like ''Accept'', ''text/html, application/xml, > text/xml, */*''] > > > > > > check > > Doug Dupory schrieb:-- Posted via http://www.ruby-forum.com/.
my understanding is that request.xhr? indicates the controller has received an ajax request, while respond_to indicates that the browser can accept specific mime types. non? Jodi On 24-Jun-06, at 12:24 PM, Doug Dupory wrote:> Thank you, Pete, for the explanation of where they come from! > > To implement graceful *RJS* degradation, does it mean request.xhr? is > sufficient? Or need both? Is it possible that a broswer doesn''t set > the > Accept header accordingly? See > http://www.ruby-forum.com/topic/65059#74833 > > For *JS* (in general) degradation, however, respond_to is the way > to go? > > Doug (quite ignorant about Web UI) > > Pete wrote: >> short answer: no, not equivalent >> >> longer answer: >> >> -- request.xhr? -- >> >> check the following header in the request: >> >> ''X-Requested-With'' = ''XMLHttpRequest'', >> >> this is set automatically by the prototype library >> >> see line 699 in version 1.5.0_rc0 >> >> >> -- response_to -- >> >> check the ''Accept'' header. this is set not only by prototype but >> also >> by browser, spiders, etc. >> >> looks something like ''Accept'', ''text/html, application/xml, >> text/xml, */*''] >> >> >> >> >> >> check >> >> Doug Dupory schrieb: > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Yes. Thank you, Jodi! Here is my confusion: Doesn''t this mean that if we get request.xhr? true, RJS will be stuffed back regardless whether the browser accepts JS? That''s because the request comes from the prototype library. But, I see JS degradation is implemented with respond_to: http://www.ruby-forum.com/topic/64357#72054. But again, another fellow had some trouble: http://www.ruby-forum.com/topic/65059#74833 Which one or both should be used to determine what the browser is able to or want to handle? Perhaps, we should respect just the latter? Jodi Showers wrote:> my understanding is that request.xhr? indicates the controller has > received an ajax request, while respond_to indicates that the browser > can accept specific mime types. > > non? > > Jodi-- Posted via http://www.ruby-forum.com/.
I''m not sure I can speak specifically to degradation...Alas I''m building for a defined Intranet userbase, so I have more predictability than the average cat. I use request.xhr? to target particular responses to the browser - a partial for ajax, a partial for ''non-ajax''. ..having said that it makes a certain amount of sense that accepts (respond_to) would is the appropriate question you want answered : ''can the browser understand an ajax response''. so yes, I agree - the latter seems to be the appropriate approach... though others more experience than me may add to the argument. good luck Adam. Jodi On 24-Jun-06, at 12:56 PM, Doug Dupory wrote:> Yes. Thank you, Jodi! > > Here is my confusion: Doesn''t this mean that if we get request.xhr? > true, RJS will be stuffed back regardless whether the browser accepts > JS? That''s because the request comes from the prototype library. > But, I > see JS degradation is implemented with respond_to: > http://www.ruby-forum.com/topic/64357#72054. But again, another fellow > had some trouble: http://www.ruby-forum.com/topic/65059#74833 > > Which one or both should be used to determine what the browser is able > to or want to handle? Perhaps, we should respect just the latter? > > Jodi Showers wrote: >> my understanding is that request.xhr? indicates the controller has >> received an ajax request, while respond_to indicates that the browser >> can accept specific mime types. >> >> non? >> >> Jodi > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails