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