Rails Nested Resource Issues

Jason Guiditta jguiditt at redhat.com
Fri Sep 21 18:26:50 UTC 2012


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



More information about the aeolus-devel mailing list