Here's my current simple solution:
Monkey with Hash: http://gist.github.com/32279
Then I explicitly specify which fields I want to save in my controller
action:
def update(id)
@person = Person.get(id)
@person.attributes = params[:person].choose(:name, :email)
if @person.save
redirect resource(@person)
else
render :edit
end
end
I use this technique in both Rails and Merb. I personally think direct
mass assignment with params is pure craziness. You should always
specify the fields you want to save. But it makes no sense to do it at
the model level since then it screws up the times you want to pass in
your own hashes and have your data save. So attr_protected and
attr_accessible end up being really terrible workaround. I'm glad they
haven't made the jump to DataMapper.
Here's an earlier more complicated attempt at solving this problem for
ActiveRecord specifically, that didnt turn out so great:
http://github.com/jcnetdev/acts_as_applyable
On Dec 4, 6:41 am, Jon Hancock <[EMAIL PROTECTED]> wrote:
> In using both action-args and param-protection, I find each lacking
> and feel what is missing needs to pull both into one declaration.
> Here's hoping I can start a discussion to find a more complete
> solution.
>
> First, I'll state a misgiving about each:
>
> I can use action-args to have something like:
>
> def activate_post(user, _submit_activate, _submit_cancel)
> ...
> ..
> end
>
> The first param is user which maps nicely to my view's use of form_for
> @user and to my other action, activate_get which also uses the same
> view.
> The second and third params in this case are submit buttons.
> Sometimes I do have more than one button on a form. ;)
> Unfortunately, this use of action-args, while works well with form_for
> and such, doesn't give me any protection as to what attributes of the
> user it allows.
> If I instead write the above as:
> def activate_post(email_confirmation_code, display_name, password,
> password_confirm,, _submit_activate, _submit_cancel)
> I get better protection but lose my form helper benefits.
>
> Now on to param-protection. This seems to be only controller-wide.
> I've tried to use it at an action level and get errors. So maybe I'm
> using it wrong. Even if I did have action level param-protection, I
> think I would be repeating myself from my specs in action-args.
>
> So is there a way to join them together and also have neat add-ons
> like output filtering as well?
>
> How about something like this:
>
> def activate_post
> guards Proc { [:user =>
> [:email_uncomfirmed, :display_name, :password, :password_confirmed],
> :_submit_activate, :_submit_cancel ] }
>
> end
>
> The results of the above is:
> 1 - wrapper the call to guards in something like a Proc so we can be
> "lazy" and only the first time the action is run do we do the magic to
> figure things out and do some meta-magic. I'm sure my sketch above is
> not the best way to write this ;).
> 2 - :user implies we want a local var in this method called user. We
> will also have local vars _submit_activate and _submit_cancel. Access
> to the other params would be by user[:email_unconfirmed], etc...
> 3 - the default is that anything passed in that doesn't fit is tossed.
>
> How about something more challenging:
>
> def activate_post
> guards Proc { [:user => [email_uncomfirmed, display_name, password
> => :in_only, password_confirmed
> => :in_only], :_submit_activate, :_submit_cancel ] }
>
> end
>
> In this case, we mark the two password attribs as something we do not
> want to be redisplayed if we re-render the page.
>
> We should be able to come up with a pretty readable, dare I say it,
> DSL to add more behavior, like overriding the default behavior if
> something doesn't match. Default would be just to throw away
> unmatched info. Additional features could be to do param
> transformations like specing a param gets converted to a Time or
> Integer.
>
> I've seen various message here and on the DM forum about mass
> assignment issues. I think the right place to protect your params is
> at the front door of each action, not by playing tricks with public
> and private Model attributes.
>
> Can someone build on these ideas with me?
> This is one of the key areas of "this type of framework" that bugs
> me.
>
> I did something like this to great effect but it was in erlang and a
> JSON app. But the results were very readable and DRY.
> To be certain, I like this idea so much, I'm willing to try to "own
> it" and publish an experimental gem but I am out of my depth in
> several areas, including finding the correct DSL. I would need
> help. ;)
>
> thanks, Jonhttp://shellshadow.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
