<div>Ordering was a concern I had also, and the plan was as Nubis suggested- callbacks are executed in the order given (so very explicitly defined by the user).</div><div>One aspect that can make ordering more confusing is having different triggers for different life cycles of the model. It is often enough the case that you want a trigger to operate on a create but not on an update. This also points out that I forgot to pass a Maybe Key to the trigger function. But there are more subtle life cycles for triggers- before or after create, save, or destroy. A first implementation of triggers will probably avoid this and just operate before a save, but I would like to think about an extensible design. I have though of 2 possible apis to support life cycles:</div>
<div><br></div><div>[|</div><div>Person triggers=beforeCreate, CREATE, afterCreate | verifySex, trigger2, trigger3 SAVE, afterSave, | beforeDestroy, DESTROY, afterDestroy</div><div> age Int</div><div> sex String Maybe</div>
<div>|]</div><div><br></div><div>A multi-line alternative:</div><div><br></div><div>[|</div><div>Person</div><div> age Int</div><div> sex String Maybe</div><div><br></div><div> BeforeCreate=beforeCreate</div><div> AfterCreate=afterCreate</div>
<div> BeforeSave=verifySex, trigger2, trigger3</div><div> AfterSave =afterSave</div><div> BeforeDestroy = beforeDestroy</div><div> AfterDestroy=afterDestroy</div><div>|]</div><div><br></div><br><div class="gmail_quote">
On Wed, Jul 13, 2011 at 5:48 AM, Nubis <span dir="ltr"><<a href="mailto:nubis@woobiz.com.ar">nubis@woobiz.com.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Jul 13, 2011 at 7:53 AM, Vladimir Zlatanov <span dir="ltr"><<a href="mailto:vlado@dikini.net" target="_blank">vlado@dikini.net</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The key, IMHO, will be the order of execution of the callbacks. In<br>
most, if not all, systems I've used so far, based around such<br>
architecture this was their Achilles heel. Drupal hooks are one<br>
high-profile examples.<br>
<br>
The problem stems from the weird abstractions - you either don't know<br>
enough what else is out there, or you know too much. both of which are<br>
bad. Subject-observer while good, has its downsides :(<br>
<br>
The other option is to enforce separation of the results of the<br>
callbacks, so that the output is always deterministic.<br>
<br>
Cheers,<br>
Vlado<br>
<br></blockquote></div><div><br>I like the idea, and I think the callbacks can be executed in the order they are defined in the model. Even if it only saves you from writing all the validation boilerplate code seems worth giving a try.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org" target="_blank">web-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</blockquote></div><br>
</blockquote></div><br>