Dealing with parameter validation in Phoenix controllers is a rather tedious task, especially when dealing with multiple parameters, types, default values and additional validations one may need. Therefore having a library handle all of this automatically is basically a necessity - which is where paramus comes in handy.
Repository: https://github.com/satom99/paramus
Contributions are more than welcome, as always!
I’m curious on when would I use this when ecto schema have type and validation no?
I’m also coming from php and old school MVC framework where the idea is fat model and skinny controller.
Is there any benefit over ecto schema and changeset validation?
Thanks for the contribution
Sure thing! It is now available on hex here 
.
I presume we’re discussing a case where you’d put the params directly through an ecto schema’s changeset before insterting or updating a specific resource - say per example creating a user.
If that’s the case, you could go without paramus just fine. However, in the event that a changeset validation fails, if you are using the bangified functions (i.e. Repo.insert/1) an error will be raised, then picked up by Phoenix and turned into a response code of 422 - which is fine for most cases. But if you wanted to return a message explaining what was wrong, you’d use the non-bangified functions and typically match in a case statement whether the operation failed and then traverse the changeset’s errors manually and whatnot - and this clearly results in repeated code if needed on multiple places.
So as a tldr I would add that paramus comes in handy (when acting against ecto schemas) “only” if you want to be able to display changeset errors without having to handle the logic yourself.
All of this being said; I myself also use paramus on non-ecto-schema-related handlers. Per example, say I have an endpoint that interacts with a running GenServer and that I want the received data to be in a specific format. Lets consider this example, I could have a server “storing” fruits and very easily call that consume endpoint with a name, quantity and possibly a cut? value and pass all of these directly to the server without having to care about validating the data manually.
Also I haven’t really specified this before but, paramus refers to the project’s ErrorView to handle the changeset errors - have a look here. So if, as mentioned, you wanted to display changeset errors, because the changeset is passed down as a parameter to the error view, you could traverse it there.
© Copyright Elixir Forum | Terms | Privacy & Cookies
