Rails Nested Resource Issues

Jiří Stránský jstransk at redhat.com
Fri Sep 21 14:40:16 UTC 2012


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.



More information about the aeolus-devel mailing list