Rails core - Apr 2006 - :id handling in render_component

The current implementation of render_component handles :id as a  
special parameter (newlines edited for email):

   # after r3563
   (options[:params] || {}).with_indifferent_access.regular_update(
     "controller" => controller_name, "action" =>
options[:action],
     "id" => options[:id])

I noticed this because if you put :id in :params instead, after r3563  
(thanks to Jean-François for debugging this) :id ends up being nil in  
the controller, an application broke because of this. Before  
r3563 :id was still being handled specially but as an implementation  
side-effect the one in :params won:

   # before r3563
   (options[:params] || {}).merge({ "controller" => options 
[:controller],
    "action" => options[:action], "id" => options 
[:id] }).with_indifferent_access)

This looks like a bug, but before I send a ticket I want to know how  
would you handle this.

1. As a user I''d expect from the docs that all parameters have to go  
in :params. Does :id need indeed special handling? If that''s right,  
would you just remove options[:id] from that snippet?

2. If it does need special handling because of some rationale I am  
not aware of, should we document :id has to go necessarily into  
options and not into :params?

-- fxn

> 2. If it does need special handling because of some rationale I am
> not aware of, should we document :id has to go necessarily into
> options and not into :params?
:id is special, just like :action and :controller is. Routing is built
around these three parameters getting special treatment. So let''s
document that :id should not be named in params, but on its own.
--
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

On Apr 17, 2006, at 17:50, David Heinemeier Hansson wrote:
>> 2. If it does need special handling because of some rationale I am
>> not aware of, should we document :id has to go necessarily into
>> options and not into :params?
>
> :id is special, just like :action and :controller is. Routing is built
> around these three parameters getting special treatment. So let''s
> document that :id should not be named in params, but on its own.
In url_for we start with options, then update options with options 
[:params], if any, and then we pass the resulting hash to routing:

       def rewrite_path(options)
         options = options.symbolize_keys
         options.update(options[:params].symbolize_keys) if options 
[:params]
         if (overwrite = options.delete(:overwrite_params))
           options.update(@parameters.symbolize_keys)
           options.update(overwrite)
         end
         RESERVED_OPTIONS.each {|k| options.delete k}
         path, extra_keys = Routing::Routes.generate(options.dup,  
@request)

         path << build_query_string(options, extra_keys) unless  
extra_keys.empty?

         path
       end

So if a programmer sees :id as one among other request parameters in  
some particular call, only default routing rules beautifies it, he  
still gets a valid URL, instead of a hard-coded nil for :id. Wouldn''t  
it be natural to replicate that behaviour in render_component?

-- fxn