> > 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
> 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. And its fully backwards compatible since before
this you weren't even able to have view files of the same name and
diff
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
___
Rails-c
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
> 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 irrespe
> 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
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_
