Re: weird problems with context

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Tue Jun 05 2007 - 09:47:29 EDT

  • Next message: Michael Gentry: "Re: performing count"

    On 05/06/2007, at 10:31 PM, Andrus Adamchik wrote:

    > On Jun 5, 2007, at 3:22 PM, Lachlan Deck wrote:
    >
    >> Perhaps it'd make sense to be able to register a delegate... then
    >> you can still separate concerns ;-)
    >
    > Could you elaborate some more?
    >
    > Most often than not I find the EOF-like delegate approach to be
    > rather inflexible

    In what sense? I find it's a good fit when you need to insert some
    shared logic within the call logic. However...

    > , and certainly not suitable for the framework internal needs.

    The other option presented in EOF which is also useful is that of
    notifications. The difference between the two is usually that the
    delegate can abort an operation or provide custom shared behaviour
    whereas numerous objects can register as notification observers to
    run their own logic based on the transpired events. So perhaps
    notifications could be a good choice as any object can register
    themselves as an observer of a notification, registering the method
    to call when the notification is fired, and whether to limit the
    notification to those fired from a particular object or for any for
    that key. This seems to me to suit the lifecycle events nicely.

    Not only do individual PersistentObjects need to be notified of
    prePersist/postPersist etc but I find it useful (in the EOF space) of
    receiving a notification, when an editing context has been saved,
    that provides with the notification the list of objects deleted,
    inserted, and updated so as to deal with them as a group (which could
    handle fulfilling the former by interating through the objects can
    calling pre*/post*). But being able to register any object against
    these various lifecycle events ought to provide for additional
    flexibility.

    Btw, I'm thinking that PrePersist ought to be run just prior to
    persisting an object (as the name suggests) and that another
    postCreate lifecycle event ought to take its place. What do you
    think? That seems to be the missing piece in the puzzle between
    validateFor* and committing a new object.

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Tue Jun 05 2007 - 09:48:12 EDT