On Sat, 16 Nov 2002, Andrus wrote:
> I like the delegate or listener approach better. I don't want DataObject
> interface to grow bigger, rather I'd like to make it smaller in the future.
+100. If my vote can count that much :-)
> Now delegate vs. listener.
<snip>
Listeners are good for notifications that don't need a response
(willCommit/didCommit), and as such are fine for the currently mooted
changes. In fact, when there is no concept of the client actually
responding, then this is much better because there's not even a reasonable
mechanism to do so (unless, say, the DataContext doing the notifying is
passed as a parameter to the listener method). This would be a step up
over EOF where half the delegate methods are for notification, the other
half for true "delegation" (decision making by another related object
which might know better). Makes for a big pain trying to figure out what
you can/should do in the delegate methods :-(
Let alone the "multiple subscriber" advantages of listeners.
However, I'd suggest that if we ever implement a "shouldCommit" type hook,
that it be done as a true delegate. Seems more "right" to me (only one
potential objector to the commit occuring, and fits the "Delegate" pattern
well).
> I suggest a new package for that : org.objectstyle.cayenne.access.event
> (we may also have map.event in the future?). We should start with the
> listener interface that defines all interesting callback methods:
>
> public class DataContextEvent extends EventObject
>
> public interface DataContextListener {
> somethingHappened(DataContextEvent);
> somethingElseHappened(DataContextEvent);
> .....
> }
+1. Would a generic DataContextEvent be sufficient for all such
events, or would we possibly need to have specific subclasses for some?
I suppose that could be determined as it gets implemented.. just wondering
out loud I guess :-)
> >My first idea as well: invoking optional 'class methods' (grr) implemented
> >in the DataObject as static methods might work, but is probably not such a
> >good idea since it cannot be formalized properly - interfaces cannot
> >contain statics, you can't properly subclass/override them etc. Nothing
> >but Java trouble :(
>
> We can think about this later. When CayenneModeler starts supporting class
> reflection, we can allow *arbitrary* static methods mapped to be called on
> particular object lifecycle events. We can even generate those methods when
> doing automatic class generation. This is more work, but has a benefit over
> listeners in that it becomes a part of mapping thus simplifying the code.
An interesting idea.... what sort of methods would you be thinking of
here? What would they be doing (creation, deletion?)
Craig
This archive was generated by hypermail 2.0.0 : Sat Nov 16 2002 - 21:19:37 EST