No subject
Thu Feb 24 17:58:36 CET 2011
attaches to the models, that really define the business logic of the model,
(lets ignore for now how one deals with relationships to other models). Much
of the rest of putting code into models is about having a nicer way to
share, organize, and test code.
Greg Weber
On Mon, Jun 20, 2011 at 4:07 AM, Christopher Done
<chrisdone at googlemail.com>wrote:
> On 10 June 2011 16:12, Greg Weber <greg at gregweber.info> wrote:
> > I would like to come up with a good system for
> > maintaining invariants and propagating violations to forms, and other
> useful
> > systems for doing more than just taking the query out of the controller.
> > Let us know if there is anything stopping you from separating out code
> into
> > a Models directory right now.
>
> An example of managing invariants and propagating violations to forms?
>
--90e6ba6e8cf88de64104a62679da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Chris,<div><br></div><div>I like the new url generator package, which sh=
ould also be useful in focusing an application around the models.</div><div=
><br></div><div>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 (no=
t 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 mo=
del. But a model may have more complex logic than that- a field may be requ=
ired based on the value of another. This could be handled by indicating a v=
alidation function in the schema rather than just a boolean as to whether i=
t 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.</div>
<div><br></div><div>insert User { name =3D "Chris", email =3D &qu=
ot;e", requiredCheckbox =3D False }</div><div><br></div><div>So if tha=
t is done, but not first from a form (an API perhaps), we have nothing to v=
alidate our model.</div>
<div><br></div><div>In Rails, in my model file, I can declare validations o=
f arbitrary complexity. To save a model, I have to call model.save, which w=
ill run any=A0validations=A0and any callbacks in general (There could be a =
before_create callback that automatically sends an e-mail). So we could sta=
rt in Yesod by having a convention of calling=A0</div>
<div><br></div><div>save=A0User { name =3D "Chris", email =3D &qu=
ot;e", requiredCheckbox =3D False }</div><div><br></div><div>which wou=
ld 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, bu=
t also have the side effect of either setting the model id or creating an e=
rrors variable containing a list of errors that you can inspect and that th=
e form can use. We could return instead return an Either, with the alternat=
ive result of the key (id) or the errors for the model.=A0And ideally those=
errors could be=A0propagated=A0back 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.</div>
<div><br></div><div>There is a data storage library on hackage that support=
s triggers.</div><div><a href=3D"http://hackage.haskell.org/packages/archiv=
e/TCache/0.8.0.2/doc/html/Data-TCache-Triggers.html">http://hackage.haskell=
.org/packages/archive/TCache/0.8.0.2/doc/html/Data-TCache-Triggers.html</a>=
</div>
<div><br></div><div>One can emulate trigger callback behavior by writing th=
eir own save function, however the problem is that this allows multiple pos=
sible 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 persiste=
nce layer.</div>
<div><br></div><div>From my limited Ruby experience, it is the triggers and=
validations that one attaches to the models, that really define the busine=
ss logic of the model, (lets ignore for now how one deals with relationship=
s to other models). Much of the rest of putting code into models is about h=
aving a nicer way to share, organize, and test code.</div>
<div><br></div><div>Greg Weber</div><div><br><div class=3D"gmail_quote">On =
Mon, Jun 20, 2011 at 4:07 AM, Christopher Done <span dir=3D"ltr"><<a hre=
f=3D"mailto:chrisdone at googlemail.com">chrisdone at googlemail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 10 June 2011 16:12, Gr=
eg Weber <<a href=3D"mailto:greg at gregweber.info">greg at gregweber.info</a>=
> wrote:<br>
> I would like to come up with a good system for<br>
> maintaining invariants and propagating violations to forms, and other =
useful<br>
> systems for doing more than just taking the query out of the controlle=
r.<br>
> Let us know if there is anything stopping you from separating out code=
into<br>
> a Models directory right now.<br>
<br>
</div>An example of managing invariants and propagating violations to forms=
?<br>
</blockquote></div><br></div>
--90e6ba6e8cf88de64104a62679da--
More information about the web-devel
mailing list