Craig, Cool. I'll look into these and begin extracting the library for contribution. Perhaps [delegate] as an alternate name but if [event] is not active, i think that would be more ideal. I'll look at that more closely. Maybe they can be combined.
I'd also like to talk more about pipeline, chain, and struts-chain. I had an opportunity over the weekend to look through chain and struts-chain and like what I see. I have some suggestions and ideas, and also would like to pick your brain more about your plans. This may not be the right forum for that however. I'll ping you later to discuss more. Just so you are aware, I started putting together an article "Introducing Commons Chain" and plan on touching on how it is being used as an alternative approach to the current Request Processor model. I'd love to have an opportunity to speak with you more about your thoughts on future direction. I have noticed you mention tidbits of cocoon's site-map and of course there were the Turbine 3 pipeline efforts as well. Not sure how these relate to the pipeline package you mentioned above. I will jump back on the Struts development list as well ( i have something else unrelated to contribute too ;-) Talk to you soon - Mike On Mon, 2004-10-04 at 12:38, Craig McClanahan wrote: > 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]
