commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Stanley <>
Subject RE: sandbox proposal. Events
Date Mon, 04 Oct 2004 22:50:39 GMT

On Mon, 2004-10-04 at 18:16, Michael Heuer wrote:

> On Mon, 4 Oct 2004, Mike Stanley wrote:
> > On Mon, 2004-10-04 at 15:14, Jung, Eric wrote:
> >
> > > You might also consider using java.util.EventListener,
> > > java.util.EventListenerProxy, and java.util.TooManyListenersException as
> > > appropriate. All of these were introduced in JSDK 1.3.
> >
> >
> > Events have been around a while in JDK (since 1.1).  My implementation
> > takes a different approach to events than the JDK.  Where the JDK uses
> > Class signatures, interfaces, and event objects, I utilize reflection
> > and method invocation.  Allowing more arbitrary invocation of methods.
> > Using this delegateMethod/event registry approach, any existing
> > class/method can be invoked when an event is fired/raised.  Without
> > requiring classes to implement an interface or signature.  Look at
> > .NET's events and delegates.  They do something similar to this.
> >
> > Let me package everything up and then contribute it.  Then it may be
> > easier for me to demonstrate what I'm trying to accomplish.
> >
> > - Mike
> >
> > p.s.  I'm not advocating that this is a better way of handling events,
> > just a different approach.  (I do believe it is more convenient and
> > flexible to utilize.  especially when adding events and event handlers
> > to existing components.)  I also think this fits nicely with frameworks,
> > and other patterns such as the chain of responsibility.
> For what it's worth, my approach has been to adapt the event pattern in
> Swing for other purposes.  I've documented that pattern and provided
> velocity source code generation templates in

The event pattern used in Swing is the Java Event pattern discussed
above.  It involves creating a specific Event Listener interface, event
listener concrete classes (typically this is done inline), and an Event
Object (or Event Source) which is sent from the class that fires the
event to all the event listeners that have been registered.

Like I said, there is nothing wrong with that approach.  It is core

The code I will be contributing provides an alternative that utilizes
reflection, dynamic invocation, and method invocation.  This really is
more of a "MultiCastDelegate", but if you are familiar with .NET, you
see that they use "MultiCastDelegates" as the basis of their event
model.  The dynamic delegate can be used in eventing, but really its
about invoking an ordered list of methods on various target objects.  

- Mike

> >
>    michael
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message