FYI, [events] in the sandbox is/was an attempt to create a set of decorators
for collections that call listeners when objects are added/removed/updated
etc.
The project began life in [collections] but was factored out as not ready
(and to reduce the size of [collections] at the time of 3.0). There
ails]. 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 genera
Hi.
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
> >
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.
>
>
> Event
On Mon, 2004-10-04 at 15:47, Mario Ivankovits wrote:
> Mike Stanley wrote:
>
> >Thought about the Hash approach too. That won't suffice.
> >
> Havent looked at [event] now, but the first thing about how to handle
> results which comes into my mind was a ResultHandler - what if you just
> prov
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
> Su
Mike Stanley wrote:
Thought about the Hash approach too. That won't suffice.
Havent looked at [event] now, but the first thing about how to handle
results which comes into my mind was a ResultHandler - what if you just
provide a way to set a ResultHandler - a interface with a method like
Result
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 prob
rs 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 (n
eturn 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"
he
> > "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
> >
&g
I see. Good point. So how about the original array (or List) idea instead?
Do you see any problems with that?
-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
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:
>
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
> 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 wan
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,
sents a return
value?
-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 migh
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 wit
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
19 matches
Mail list logo
