cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <lachlan.d...@gmail.com>
Subject Re: weird problems with context
Date Tue, 05 Jun 2007 13:47:29 GMT
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



Mime
View raw message