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
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core