On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: > Not sure what EventResult is (I was referring to a generic return object, > not mentioning any specific class or interface for a return type),
As am I. EventResults is simply a container for generic return objects. More specific than a List or Array, since there are convenience methods for retrieving more details (such as what exact DelegateMethod returned this object, and was it the first,second... last method executed, did it throw an exception, what was the stack trace, etc...) Same as the list/array idea, just more details. > but while > we're on the subject, have you considered java.util.EventObject as the > elements in the list/array? This is what I use in my "event chain" > implementation. EventObject is passed to the invoked object. This is a different style to handling events. I explain more below... My concept of EventResults is more a container (like a list) for collecting Delegate Method invocation results. Where you are advocating a List of generic objects, I'm saying Great, but I want a more specialized container that implements List and adds methods for managing Delegate Method invocation results. > > 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. > > -Eric Jung > > -----Original Message----- > From: Mike Stanley [mailto:[EMAIL PROTECTED] > Sent: Monday, October 04, 2004 3:09 PM > To: Jakarta Commons Developers List > Subject: RE: sandbox proposal. Events > > > On Mon, 2004-10-04 at 13:40, Jung, Eric wrote: > > > I see. Good point. So how about the original array (or List) idea instead? > > Do you see any problems with that? > > > EventResult will probably be the best. It would have an List of single > results (delegate method, when it was executed, return value, exception > if thrown, etc) but can implement the basic List interface so it can be > iterated or accessed by index. etc > > - Mike > > > > > > -----Original Message----- > > From: Mike Stanley [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 04, 2004 1:36 PM > > To: Jakarta Commons Developers List > > Subject: RE: sandbox proposal. Events > > > > > > Thought about the Hash approach too. That won't suffice. I don't want > > to limit the number of times a method can be added to an "event chain". > > Take for example, the ability to manipulate an image (not the best > > example - but it adequately demonstrates what I'm talking about): It > > would be possible to create event chains to do specific tasks by > > combining methods in order: > > > > - blur(Graphic) > > - blur(Graphic) > > - rotate(Graphic) > > - flip(Graphic) > > > > All these can manipulate the parameter. By allowing delegate methods to > > be added any number of times you can create functional chains. > > > > It would be possible to provide both (where the hash code would return > > the last one executed). > > > > - Mike > > > > On Mon, 2004-10-04 at 13:23, Jung, Eric wrote: > > > > > I use an "event handler chain" (my term for the pattern you describe) in > > an > > > application right now that requires the handler(s) which failed be > > > identified after the event handler chain completes. [The chain may or > may > > > not continue processing if one handler fails]. The best way I thought to > > do > > > this was to use an array of return values. Order is derived via the > means > > > you describe below (element indices coupled with a return value from the > > > "register delegate" method). However, a more general approach might be > to > > > return a hash from the "register delegate" method and use a Map of > return > > > values, instead of an array or list. > > > > > > My two cents, > > > Eric Jung > > > > > > -----Original Message----- > > > From: Mike Stanley [mailto:[EMAIL PROTECTED] > > > Sent: Monday, October 04, 2004 1:05 PM > > > To: Jakarta Commons Developers List > > > Subject: RE: sandbox proposal. Events > > > > > > > > > > > > On Mon, 2004-10-04 at 12:42, Jung, Eric wrote: > > > > > > > >If the delegate methods return a value, > > > > >the last value would be returned (this is the > > > > > behavior of the .NET approach. I'm open to other suggestions). > > > > > > > > How about the option of either (1) receiveing the last value or (2) > > > > receiving an array of values, where each array element represents a > > return > > > > value? > > > > > > > > > It currently returns the last value. The problem with returning an > > > array of values is the problem with matching up methods to return > > > values. Since order is retained this can be done by keeping track of > > > when something was added (return index on registration to ensure > > > syncrhonized index etc.) I didn't add this though because (1) at the > > > time I wrote it I didn't need this capability and (2) I questioned if I > > > ever would need this. > > > > > > if other's can think of a situation that calls for (2), I'm thinking the > > > best way to handle it would be to return an EventResult. That allowed > > > you to obtain return values / stack traces, and other invocation info > > > for each method based on the registration index of the method. > > > > > > - Mike > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, October 04, 2004 12:39 PM > > > > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > > > > Subject: Re: sandbox proposal. Events > > > > > > > > > > > > Mike, > > > > > > > > This pattern does indeed sound interesting. You might also want to > > > > take a look at the [pipeline] sandbox package (contributed by Kris > > > > Nuttycombe) that I checked in over the weekend. It offers a different > > > > tack on handling asynchronous events, and is also investigating how an > > > > interaction with [chain] might be beneficial. > > > > > > > > >From a practical perspective, there exists already a sandbox package > > > > named [events], originally extracted from [collections]. I haven't > > > > been tracking whether this is actually active or not; if so, we'd need > > > > to use some different top level name for the package itself. > > > > > > > > Craig > > > > > > > > > > > > > > > > On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley > <[EMAIL PROTECTED]> > > > > wrote: > > > > > I've implemented a pattern, somewhat based off the .NET event and > > > > > delegate pattern, however the pattern is also commonly seen in > > > > > frameworks (to some extent). > > > > > > > > > > At a high level, the pattern is made up of two objects: > > > > > - Event > > > > > - DelegateMethod > > > > > > > > > > The Event is a container for DelegateMethods. Delegate Methods are > > > > > registered with the Event (added to the container). The first > > delegate > > > > > method added to the container determines the contract for that > event. > > > > > I.e. each method added must have similar signatures (take the same > > > > > number and types of parameters and return the same type). At any > time > > > > > the event can be fired. When an event is fired it invokes the > > delegate > > > > > methods in the order they were added. The event can be configured > to > > > > > fail on first exception, or continue without failing. If the > delegate > > > > > methods return a value, the last value would be returned (this is > the > > > > > behavior of the .NET approach. I'm open to other suggestions). > > > > > > > > > > A Delegate Method gets created with an instance of an object and the > > > > > name of the method (optionally when instantiating the Delegate > Method > > > > > you may specify the signature - or actual Method, in the case that > > there > > > > > are multiple methods with the same name but different signatures). > > This > > > > > method will be invoked using reflection > (delegateMethod.invoke(args)) > > > > > when the event is fired. > > > > > > > > > > At it's core this is the basic idea. Above this, there are > (*plans*) > > to > > > > > create Asynchronous Delegate Methods and events, providing simple > > > > > support for multi-threaded events. This will use the same concepts > > from > > > > > .NET (callbacks, begin invokes, end invokes, async results, etc). > > > > > > > > > > I'm also investigating migrating the pattern to utilize > > "commons-chain". > > > > > > > > > > Currently this does not exist as a stand-alone library. However, if > > > > > there is interest, I will begin to pull it out and contribute it to > > the > > > > > commons-sandbox. > > > > > > > > > > - Mike > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
