commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Stanley <mstan...@mstanley.net>
Subject Re: sandbox proposal. Events
Date Mon, 04 Oct 2004 19:06:51 GMT
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)
}

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 <mstanley@mstanley.net> 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:mstanley@mstanley.net]
> > > 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:craigmcc@gmail.com]
> > > > Sent: Monday, October 04, 2004 12:39 PM
> > > > To: Jakarta Commons Developers List; mstanley@mstanley.net
> > > > 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 <mstanley@mstanley.net>
> > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

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