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

Reply via email to