If you have a rhtml and a rjs template for the same action, my
understanding is that the action code will have to look at least like
this:
respond_to do |type|
type.html
type.js
end
I''d suggest that for this simplest case the following syntax be
possible:
respond_to(:html, :js)
Even more, we could have a reasonable default type preference order,
so that calling respond_to is not needed at all, for these simple
cases where there''s no custom code needed for each type.
Am I making sense? Did I get this stuff right? Let me know what you
think about it and I''ll see if I can get a patch going.
> I''d suggest that for this simplest case the following syntax be > possible: > > respond_to(:html, :js)I''ll buy a patch to do that.> Even more, we could have a reasonable default type preference order, > so that calling respond_to is not needed at all, for these simple > cases where there''s no custom code needed for each type.Please expand on this. How would this look? Often times you don''t have an js option for something, so if we just expect you to an error would occur. Instead of now, where we just do a 406. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> Please expand on this. How would this look? Often times you don''t have > an js option for something, so if we just expect you to an error would > occur. Instead of now, where we just do a 406.Also, we don''t want to break existing apps where perhaps people are always responding with XML irrespective of what the Accept header contains. I don''t know that it''ll be possible to make a backwards compatible option where respond_to doesn''t get called at all. -- Cheers Koz
On 2006-03-16, at 17:10 , David Heinemeier Hansson wrote:> >> Even more, we could have a reasonable default type preference order, >> so that calling respond_to is not needed at all, for these simple >> cases where there''s no custom code needed for each type. > > Please expand on this. How would this look? Often times you don''t have > an js option for something, so if we just expect you to an error would > occur. Instead of now, where we just do a 406.Basically, we decide upon a default type order and intersect that with the available view files. Let''s say the default response order is :html, :xml, :js If we have an action foo with the view files foo.rhtml and foo.rjs, we''ll get this: respond_to(:html, :js) Notice that xml is out, because we don''t have a view file for it. Following this reasoning, for action bar which only has the standard bar.rhtml file, things will work exactly as they do now. (as if you had only respond_to(:html)) Makes sense?
On 2006-03-16, at 17:10 , David Heinemeier Hansson wrote:>> I''d suggest that for this simplest case the following syntax be >> possible: >> >> respond_to(:html, :js) > > I''ll buy a patch to do that.Here: http://dev.rubyonrails.org/ticket/4277
> Basically, we decide upon a default type order and intersect that > with the available view files. Let''s say the default response order > is :html, :xml, :jsI like that a lot. And its fully backwards compatible since before this you weren''t even able to have view files of the same name and different extensions be useful together. I even think the default order you propose is reasonable (prototype will always get js anyway if its available and someone just sending */* should get html first, then xml if only that''s available). Please do draw up a patch for this. Any objections from anyone else on this? -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> > Basically, we decide upon a default type order and intersect that > > with the available view files. Let''s say the default response order > > is :html, :xml, :js > > I like that a lot.Actually, allow me to retract that. I like this idea, but we don''t have enough usage data from respond_to to decide whether its worth it. And I''d like to keep all this Accept-header munging restricted to the respond_to call for Rails 1.1. We may well desire this for Rails 1.2, but let''s skip it for now. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework