Rails Nested Resource Issues
Martyn Taylor
mtaylor at redhat.com
Mon Sep 24 10:06:43 UTC 2012
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
More information about the aeolus-devel
mailing list