Unless I'm mistaken, I think that both of the methods discussed in this thread satisfy your requirements? The only approach that tries to define the filter completely in the model is attr_protected/ attr_accessible, which seems to fall short for just the reason you name -- the logic is placed in the wrong layer.
On May 26, 6:12 pm, John Trupiano <[email protected]> wrote: > I've chimed in previously regarding my preference to see the equivalent of > attr_accessible [] be the default for AR::Base...in other words, you have to > explicitly define those attributes that you want to expose to mass > assignment. > > As such, by placing this logic in the model, I think you're polluting the > model in such a way that the model now only has relevance to the business > rules of your specific application. The model is no longer a generic object > abstraction of a database table but now also encapsulates business rules. > > I firmly believe this logic should be applied at the controller level. In > fact, what I think we're really looking at here is the other side of the > MVPC layer (where P = presenter). Basically, we're looking for the inverse > of a presenter, something that sits between the controller layer and the > model lay to properly apply the business rules for this application. > > Really, I do not want my models to know anything about session or > authorization (unless I'm implementing an ACL, in which case authorization > is stored in the database). > > -John > > > > On Tue, May 26, 2009 at 8:57 PM, cainlevy <[email protected]> wrote: > > > After playing with a reimagined version of attr_accessible/ > > attr_protected in my plugin, I'm much happier with the model-side > > filtering approach. I think it allows for more interesting and useful > > defaults. > > > Since this API is to live only as a plugin for a bit, I'm unsure > > whether this thread is the place to continue discussion? I think that > > Xavier's improved documentation is probably all that can/should be > > done to core at this time. Anyone interested in playing with the mass > > assignment API is welcome to contact me directly or through GitHub. > > > On May 26, 1:47 pm, Xavier Noria <[email protected]> wrote: > > > On Tue, May 26, 2009 at 10:30 PM, Matt Jones <[email protected]> wrote: > > > > One other thought - going back to the original example (admin user can > > > > mass-assign fields that are normally protected), what about an extra > > > > parameter to update_attributes (and possibly create)? ie: > > > > > @model.update_attributes(params[:whatever], > > > > [:stuff_non_admins_cant_change]) > > > > > So essentially a, "no, really, you can mass-assign these attributes > > > > just this once" parameter. That would still allow regular code to work > > > > correctly while permitting the context-sensitive stuff you're looking > > > > for. > > > > Certainly the Hash#except idiom requires you whitelist (or > > > not-blacklist) sensitive data, because attr_(accessible|protected) are > > > of course applied to whatever sanitized hash you pass. So in > > > particular you can only narrow accessible aattributes (or extend > > > protected attributes) > > > > Going the other way around sounds better to me, not sure about the API > > > though. I think it requires the same amount of configuration and > > > exceptions, but looks like a safer default. > > -- > John Trupiano > President > SmartLogic Solutionshttp://www.smartlogicsolutions.com > @jtrupiano --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
