Re: [web-devel] real Models in Yesod

Personally, I think we should only provide a single function instead of allowing the definition of multiple functions. If users need multiple functions, they can define a "wrapper" function in normal Haskell. The reasoning here is to avoid "magic" in the TH code whenever possible. As for different types of triggers, how about attributes like "onSave", "onUpdate", "onCreate" and "onDelete"? onSave could be called for both onUpdate and onCreate (with some explicit rules about what happens when *both* of those are defined). Michael On Wed, Jul 13, 2011 at 6:09 PM, Greg Weber wrote:

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). 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: [| Person triggers=beforeCreate, CREATE, afterCreate | verifySex, trigger2, trigger3 SAVE, afterSave, | beforeDestroy, DESTROY, afterDestroy   age Int   sex String Maybe |] A multi-line alternative: [| Person   age Int   sex String Maybe   BeforeCreate=beforeCreate   AfterCreate=afterCreate   BeforeSave=verifySex, trigger2, trigger3   AfterSave =afterSave   BeforeDestroy = beforeDestroy   AfterDestroy=afterDestroy |]

On Wed, Jul 13, 2011 at 5:48 AM, Nubis wrote:

...

On Wed, Jul 13, 2011 at 7:53 AM, Vladimir Zlatanov wrote:

...

The key, IMHO, will be the order of execution of the callbacks. In most, if not all, systems I've used so far, based around such architecture this was their Achilles heel. Drupal hooks are one high-profile examples.

The problem stems from the weird abstractions - you either don't know enough what else is out there, or you know too much. both of which are bad. Subject-observer while good, has its downsides :(

The other option is to enforce separation of the results of the callbacks, so that the output is always deterministic.

Cheers, Vlado

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.

...

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel