Abridged summary of rubyonrails-core@googlegroups.com - 1 update in 1 topic

rubyonrails-core
1

Hi All,

Since strong parameters came out I was struggling with the thought that I need to keep an extra method around in the controller for parameter whitelisting. It was absolutely right to move the responsibility to whitelist end user submissions from the ActiveModel to ActionController - but the extra method in the controller was bothering me still.

So i did this thing: https://github.com/ShinobiDevs/better_strong_params/blob/master/lib/better_strong_params.rb

(Not as sharp as i would expect, consider this a WIP)

Does this look like a good direction to go? good enough for a core PR when i’m done or should i leave it as a gem?

2

How do you configure per-controller which params to permit?

3

Could you explain why the extra method in the controller bothers you?

Thanks,

-Amiel

4

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

5

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.

6

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 - better_strong_params/better_strong_params.rb at master · ShinobiDevs/better_strong_params · GitHub)

  1. 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.