Not to say that decorators (or any other single pattern) is a
panacea. Often it is hard to achieve what you want simply by
intercepting public methods, but I've always ran into problems when
designing and coding delegate extension points...
Andrus
On Jun 5, 2007, at 5:57 PM, Andrus Adamchik wrote:
> [taking to dev]
>
> Delegation model hardcodes a preset number of extension points and
> adds a fair amount of internal code registering delegates and
> integrating them into the flow. I saw it falling apart many times
> when trying to extend/change things in the stack.
>
> An alternative is to define all main stack components as
> interfaces, and allow both end-users and Cayenne developers to
> write decorators (as in "decorator pattern") to build loosely-
> coupled functionality layers. Decorators (or interceptors, or
> wrappers) follow the natural structure of the stack interfaces, do
> not require special hardcoded flow, and generally do not increase
> internal code complexity (allowing for better modularity). Think of
> that as a cheap version of AOP or Objective C categories.
>
> BTW, JPA callback API itself is an example of the delegation model,
> which is fine - I think this is an example of its appropriate use.
> While for instance DataContextDelegate is questionably less
> flexible than an ObjectContext decorator.
>
> Andrus
>
>
> On Jun 5, 2007, at 4:47 PM, Lachlan Deck wrote:
>> 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 - 11:02:16 EDT