Hello Xavier,
:action=>“supervisory_commissions_widget”})
The “id” goes from 25 in the view to nil in the controller. Does
anybody know why?
Indeed, I froze 1.0 under vendor and everything is working again.
I would like to understand what has changed in render_component
anyway if anyone knows it. My guess is that something happens with
parameters called “id”, the rest seems to travel just fine.
Well, it seems it’s due to r3563 when bitsweat committed performances
patches from Stefan K. :
in trunk/actionpack/lib/action_controller/components.rb
module method #request_for_component was modified,
especially these lines, from :
(options[:params] || {}).merge({ “controller” => options[:controller],
“action” => options[:action], “id” => options[:id]
}).with_indifferent_access
to :
(options[:params] || {}).with_indifferent_access.regular_update(
“controller” => controller_name, “action” => options[:action], “id”
=> options[:id])
In your situation, you’ve got in options hash :
:params=> {:center_id=>10, :id=>25},
:id => nil
so after the merge, you’ve got this temporary hash :
{:center_id=>10, :id=>25, “controller” =>“employee”,
:action"=>“supervisory_commissions_widget”, “id” => nil }
since option[:id] is nil.
When a HashWithIndifferentAccess object is created from
a Hash, if there’s collision between :foo and ‘foo’, I can’t figure
out how it works, but in your case the (:id, 25) pair wins.
So ‘id’ => 25 is fine in the request.
After r3563, the HashWithIndifferentAccess object is created first
so you’ve got :
{ ‘center_id’ =>10, ‘id’ =>25 }
Then the (id, 25) pair is overwritten by (id, nil) by the
#regular_update
call. so you’ve got ‘id’ => nil in the request.
As Edward wrote, pass :id directly and it should work.
-- Jean-François.