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
