Callback methods [Was: createPermId in DataContext]

From: Andrus (andru..bjectstyle.org)
Date: Sat Nov 16 2002 - 14:32:36 EST

  • Next message: Craig Miskell: "Re: Suggestion for lookupObjEntity()"

    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.

    Now delegate vs. listener.

    There is no "built in" listener concept in Java. But there is a general
    approach used by many Java library classes, like Swing. So it is more like
    a design pattern rather than a built in implementation.

    If we implement listeners, all the notification code must be written in
    Cayenne, so it is up to us how to implement the order of notification, etc.
    Listener pattern is basically the same as delegate in most cases, but
    allows multiple "delegates" per event source.

    There is also a pathetic attempt to automate notifications a bit - an
    Observable/Observer pair (Nothing like NSNotificationCenter):

    http://java.sun.com/j2se/1.4/docs/api/java/util/Observable.html

    So basically it all comes down to specing the listener interface, adding
    "addXYZListener" and "removeXYZListener" in DataContext, and invoking
    appropriate interface method on each registered listener when a particular
    event occurs (creating "fireXYZEvent" in DataContext).

    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);
        .....
    }

    At 03:41 PM 11/16/2002 +0100, Holger Hoffstätte wrote:
    > > This method could be defined in an interface which the DataObjects would
    > > have to implement. Alternatively we could poke around with reflection
    > (hmm).
    >
    >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.

    Andrus

    This archive was generated by hypermail 2.0.0 : Sat Nov 16 2002 - 14:31:47 EST