[web-devel] real Models in Yesod

[Michael Snoyman]

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 <greg at gregweber.info> 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 <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
>>
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>