[web-devel] Chris Done on a new pure Haskell pgsql binding and MVC

Greg Weber greg at gregweber.info
Mon Jun 20 17:34:25 CEST 2011

Hi Chris,

I like the new url generator package, which should also be useful in
focusing an application around the models.

In Yesod one would currently check a form for errors and if there aren't any
then insert the model, and this is all done from the controller. This puts
model logic into the form. We did have techniques (not sure what the state
of it is at the moment) to declare fields as required in the schema, and to
have that automatically reflected in a form for a model. But a model may
have more complex logic than that- a field may be required based on the
value of another. This could be handled by indicating a validation function
in the schema rather than just a boolean as to whether it should be
required. This would also help handle more complex validations than whether
just a field is required. One idea behind putting this in the schema, is
that the logic is separate from a form. However, the normal way of creating
a new model is just a simple insert.

insert User { name = "Chris", email = "e", requiredCheckbox = False }

So if that is done, but not first from a form (an API perhaps), we have
nothing to validate our model.

In Rails, in my model file, I can declare validations of arbitrary
complexity. To save a model, I have to call model.save, which will run
any validations and any callbacks in general (There could be a before_create
callback that automatically sends an e-mail). So we could start in Yesod by
having a convention of calling

save User { name = "Chris", email = "e", requiredCheckbox = False }

which would run validations and return a boolean. However, we wouldn't have
our list of errors from that. In Rails, calling save would return a boolean,
but also have the side effect of either setting the model id or creating an
errors variable containing a list of errors that you can inspect and that
the form can use. We could return instead return an Either, with the
alternative result of the key (id) or the errors for the model. And ideally
those errors could be propagated back to a form. Rails also has save! which
will throw an exception if the model is not saved- this gets around having
to check for errors if you believe there won't be any.

There is a data storage library on hackage that supports triggers.

One can emulate trigger callback behavior by writing their own save
function, however the problem is that this allows multiple possible entries
into saving a model because they can write multiple different save
functions. Real enforcement of a single entry point with triggers is
possible in something like TCache where triggers are tied into the
persistence layer.

More information about the web-devel mailing list