Reviving this one because I’m really excited about @arjan’s decorator lib, and yet @josevalim @OvermindDL1 and @benwilson512 all expressing discontent over this pattern.
We want to use decorators to perform validation on controller actions and channel functions; we are using elixir/phoenix strictly as a realtime data api that has a mixed surface of both REST and websockets (no forms, js, templates, assets, etc). We need to validate passed-in params for data integrity, example: an AuthController has register action that passes in name, username, password. We need to make sure all are non-null strings, username is unique, and password is 8 chars or more.
As recommended in What’s New in Ecto 2.0, a good way to validate incoming data is with Ecto.Schema with embedded_schema. We’re using @vic’s excellent vic/params to reduce boilerplate, but there is still the matter of invoking the changeset, checking if it is valid, then returning error responses that are properly structured per our requirements. Why make this call in every action? Isn’t it cleaner to have a decorator:
defparams register_params %{ name!: :string, username!: :string, password!: :string }
@validate register_params
def register(conn, payload) do
...
Our first inclination was do something like plug :validate which is invoked before every action, but it’s harder (and less explicit) to associate the right schema+changeset with corresponding action.
Like others, the consensus of negativity from the core team tends to preclude others from using this pattern, even though otherwise it seems like a great fit. So I ask, what exactly are you recommending for something like our scenario, if not decorators?
