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 Adamch
[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
[taking to dev]
There was an old QueryUtils class that was used for some internal
obscure queries. It's long gone (don't even remember which version
dumped it). So now we can reuse the name for the user-friendly
utility class (if we decide to go this way).
Andrus
On Jun 5, 2007, at 4:54
I just skimmed over my e-mails and that appears to be the highlights.
/dev/mrg
On 6/3/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
Just posted the first draft of the board report:
http://cwiki.apache.org/confluence/display/CAY/Board+Report+June+2007
Admittedly it's been a slow quarter for
Great.
On 05/06/2007, at 6:39 PM, Andrus Adamchik wrote:
Yeah, I am leaning towards merging the callback code into the base
context... The ability to proxy an ObjectContext is very nice, but
it changes a few standard Cayenne assumptions about the object
context. I guess for such fundamenta
Yeah, I am leaning towards merging the callback code into the base
context... The ability to proxy an ObjectContext is very nice, but it
changes a few standard Cayenne assumptions about the object context.
I guess for such fundamental functionality like callbacks, we
shouldn't be doing that
Lifecycle callbacks *CallbackInterceptor concept introduces problems for
testing equality of contexts
-
Key: CAY-797
URL: https://issues.apache.org/cayenne/browse/
