On Mon, 04 Oct 2004 15:06:51 -0400, Mike Stanley <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-10-04 at 13:40, Craig McClanahan wrote:
>
> > Perhaps the EventResult instance that encapsulates the result and any
> > exception could also encapsulate the Method instance that was actually
> > called? That way, an array or List of EventResults would still be
> > understandable. And, if you only cared about the last one, it's easy
> > to find.
>
>
> I agree. EventResult seems to be the most encompassing.
>
>
> > On the other hand, there will probably be use cases for several
> > different execution patterns:
> > - Proceed until a method says "we're done" (i.e. what [chain] does)
> > - Proceed unless an exception was thrown, until all methods are called
> > - Proceed even if an exception is thrown, until all methods are called.
>
>
> Yup yup. This is currently how I implemented "when execution should
> stop". However, I did not provide a way for a delegate method to short
> circuit ("we're done") the invocation process. I believe chain does
> this based on the return type of execute. Since the delegate methods
> can have any return type (or even void), we would need to do this a
> little differently. The best thing I can think of would be to add an
> interface StopCondition (that could be set as an optional property for
> an event), that has the following simple signature
>
> public StopCondition
> {
> public boolean stopProcessing(EventResult)
> }
Just to throw another option into the mix, you might want to take a
look at the Predicate interface in Commons Collections. It looks a lot
like your StopCondition idea.
--
Martin Cooper
>
> so the (very psuedoe) fireEvent() would behave something like
>
> public EventResult fireEvent(args)
> eventResult = new EventResult
> foreach registeredMethod
> {
> Object result = nextMethod.invoke(args)
> eventResult.add(nextMehod, nextMethodIndex, result)
> if (stopCondition.stop(eventResult))
> break
> }
> return eventResult
>
>
> - Mike
>
>
>
>
> >
> > Craig
> >
> >
> > On Mon, 04 Oct 2004 13:35:39 -0400, Mike Stanley <[EMAIL PROTECTED]> wrote:
> > > 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]
