‘Iacta alea est’
In yesterday’s post I showed how to define and run validations in Hanami. I later learned that Hanami’s approach of mixing in modules rather than using inheritance is a core tenet of the framework.
What I didn’t uncover was where in the greater whole validations are defined, and how the error messages are returned to the HTML form.
What is fascinating about Hanami validations is that they mirror the popular use of schemas and changesets in Phoenix at the web or controller layer. Although this is not the ‘blessed’ approach in the Phoenix framework, with schemas and validations being run far closer to the models and business logic, it has two notable proponents; Saša Jurić and Aaron Renner both consider casting, filtering and validation essential at the controller level, next to the form, and Hanami agrees.
Hanami controllers, or rather actions have a DSL to apply type casting, filtering and validation with a built-in DSL:
module Web::Controllers::Signup class Create include Web::Action params do required(:email).filled required(:password).filled required(:address).schema do required(:country).filled end end def call(params) … end end end
The params hash, which will contain the values submitted via a form can be validated in the controller.
If validation fails then the template is rendered again with the current params hash and validation error messages can be fetched on that object:
<% unless params.valid? %> <div class="errors"> <h3>There was a problem with your submission</h3> <ul> <% params.error_messages.each do |message| %> <li><%= message %></li> <% end %> </ul> </div> <% end %>
It should be possible to then extend this to an
error helper for any given attribute so that validation messages can be co-located with the form control.
Interesting to note that Hanami continues to keep the “form object” distinct from these concerns, choosing instead to handle everything on the
params hash. Or, looking from a different perspective, the params hash is the form object and this is decoupled from the model.
On a slightly unrelated note I quite like this division in the grander scheme of application architecture. It pushes validation concerns to the boundary of the application (receiving form data from the outside world at the controller layer) allowing the internal business logic to work with valid and type-cast data.
—Friday 11th June 2021.