Given that I've had little response from the Rails community regarding
this issue. I will go ahead and implement the work around.
I will not be using the private methods in the implementation, I will
use a before filter and a helper method. This is the best approach for
how the code is structured at this moment in time. It should be trivial
to add this in the extra "strong params" methods; should we decide to
follow this pattern in in Rails 4.
I will continue to chase up the matter with the rails community. I'm
hoping by Rails 4 we'll have proper support for this.
Regards
Martyn
On 09/21/2012 07:26 PM, Jason Guiditta wrote:
On 21/09/12 16:40 +0200, Jiří Stránský wrote:
Ok here's a follow up that could use some opinions/consensus. Thanks
to pblaho for pointing out the idea of strong_parameters and mtaylor
for discussing the whole following thing with me in depth. Here it
comes:
There is a Rails pattern emerging called "strong parameters". With
Rails 3 it can be used via the strong_parameters gem, for Rails 4 it
should be included with Rails. From my perspective it looks like it
should replace attr_accessible as means of mass assignment
protection. It is well described in this article, please read it
before reading the rest of the e-mail:
http://weblog.rubyonrails.org/2012/3/21/strong-parameters/
The idea that emerged is that we shouldn't use before_filter to
transform the params Hash we got from parsing XML (change hash keys
like `addresses` to hash keys like `addresses_attributes`). We should
rather use an approach similar to strong parameters. This means
defining private methods on controllers (e.g. method `user_params`)
that would return params tweaked to our liking.
In controllers, we would then do:
User.create(user_params)
instead of
User.create(params[:user])
We can even us it together with the actual strong_parameters, then
the `user_params` method would provide us with both:
1. transformation of parameters as necessary (`addresses` -->
`addresses_attributes`)
2. mass assignment protection.
Methods like `user_params` is already how it's meant for Rails 4 to
perform (2.), so why not use it for (1.) as well. The two purposes of
these private methods should play together nicely (can anyone see a
possible conflict?) and for (1.) it's a lot cleaner solution than
rewriting `params` in place.
Any feedback is welcome.
Have a nice weekend everyone,
J.
As we discussed in irc, I think this seems like the best approach, and
will help get us compatible in anticipation of rails 4, at least in
this particular area.
-j
