Hey Matt, I did some thinkng about this and I'm not sure if the simpler use cases are actually simpler with attr_accessible, or if they're just different? For any given model I generally only have one resource controller, so in that case I'd simply be moving the attribute list from the model to the controller. And when a model is represented by more than one resource controller, it's probably because of an entirely different context with different permissions. And of course there are easy ways to DRY up a list of attributes that are commonly used without needing official API support.
Do you have any examples where this would be a bad idea? Perhaps I'm missing something obvious here. But yes, I split #2705 into a separate ticket because it's more about opinion than functionality. On May 23, 10:05 pm, Matt Jones <al2o...@gmail.com> wrote: > The second one seems like a really, really bad idea. Specifying the > allowed attributes at the call is great, but what about the simpler > use cases? Sometimes you just want to prohibit (or allow) mass > assignment, and requiring users to specify the list every time is the > opposite of DRY. Not to mention the maintenance headache when adding a > new field... > > --Matt Jones > > On May 24, 2009, at 12:16 AM, cainlevy wrote: > > > > > Ok, primary ticket: > >https://rails.lighthouseapp.com/projects/8994/tickets/2704-allow-call... > > > And the bonus round: > >https://rails.lighthouseapp.com/projects/8994/tickets/2705-deprecate-... > > --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
