Agreed (sorry for the long wait here). Anyway, after getting feedback (both negative and positive) i thought this one over.
1. The extra method bothers me because it seems to be a piece of code in a defined structure that changes only by context. In my opinion, just like many other rails macros / solutions - code repetitions should be contained and narrowed down, in here it's not the case. 2. I redesigned the gem to have an even easier DSL imo. now you can simply use params. I am not sure that the way that I chose here (reconstructing the params hash and filtering it in runtime is a good idea, but i think that's a start. and hi, you can keep on using "params" and not some funky "user_params" or "create_params". (reference, now method - https://github.com/ShinobiDevs/better_strong_params/blob/master/lib/better_strong_params.rb#L21) 3. Inheritance, i actually didn't think about it at all - so i'll guess it's back to the drawing board for now on this one. I appreciate the feedback. On Thursday, August 28, 2014 5:16:08 AM UTC+3, Nicholas Firth-McCoy wrote: > > Looks interesting, but more often than not I use the same parameter > whitelisting across all actions in a controller. This means I'll define a > private method like `user_params` in the controller, and use it in every > action. > > In terms of param whitelisting reuse, for the case where several > controllers can create the same type of model, I just add private methods > to ApplicationController. > > On Thursday, August 28, 2014 4:30:27 AM UTC+10, Jason FB wrote: >> >> >> Elad- >> >> This gem looks great to me. I think it could very well reduce code >> duplication (and make those strong parameter definitions look a little >> cleaner). >> >> One thing I think about a lot is how a Rails 4 app could be built with >> many, many controllers that share the definition of the strong parameters >> across controllers (or don't share them, as the case need be) --- without >> repeating code, of course. I could brainstorm different ways (inherited >> controller classes, with the strong parameters defined in base classes, >> using modules to mix-in the strong parameters, etc) >> >> In general I find this syntax (yours) to be very clean, very terse, and >> easy to read. >> >> filter_parameters all: {user: [:name, :age]} >> >> >> -Jason >> >> >> On Aug 27, 2014, at 2:21 PM, Amiel Martin <[email protected]> wrote: >> >> Could you explain why the extra method in the controller bothers you? >> >> Thanks, >> >> -Amiel >> >> >> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
