[web-devel] real Models in Yesod

[Greg Weber]

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 <nubis at woobiz.com.ar> wrote:

> On Wed, Jul 13, 2011 at 7:53 AM, Vladimir Zlatanov <vlado at dikini.net>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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110713/3a5aa7a8/attachment.htm>