One other weird feature of this is it does not allow you to listen to a given instance of a class, instead you're listening for events across all objects which raise that event.
So for example, if you only wanted to observe changes to a class only when the user entered some sort of editing mode on it you can't just add a listener to that instance. You'd register a listener with the ArgoEventPump and you'll receive all events of that type from every object which raises it, so you have to filter them in your listener based on the source. So to try and sum this up - it does not allow you to observe a given object, it only allows you to observe a given event, fired from any object. On Tue, Jul 8, 2008 at 3:52 PM, Brian Hudson <[EMAIL PROTECTED]> wrote: > Just like EventListener, ArgoEventListener (which extends EventListener) is > just a tagging/marker interface. > > I don't see any advantage in extending EventListener. If ArgoEventPump used > an EventListenerList I could see the need to extend EventListener, but it > doesn't it uses a List<Pair>. I believe that EventListener/EventObject were > created to add a little type safety to event handling before generics were > added. > > I just checked in some changes to my branch which fire events when diagrams > are added/removed from a project. Having dealt with these classes now I > still don't see the advantage in having the central event registry. > > What really surprised me when adding in this functionality was that I had > to modify ArgoEventPump to handle the firing of my specific events. So in > ProjectImpl, I fire off a diagram added event, but then in ArgoEventPump I > needed to detect it was a ArgoProjectEvent, then figure out again that it > was a diagram added event (opposed to a remove) so I could then call the > correct method on the ArgoProjectListener... The only thing I think all of > this saved me from doing is adding addListener/removeListener methods to the > class/interface I was trying to observe - but I'm not sure I'd consider that > an advantage because I find it more intuitive to add the listeners to the > object I am actually trying to observe. > > > > > On Tue, Jul 8, 2008 at 2:55 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > >> This conversation doesn't seem to have gone on any further. >> >> Can anyone explain to me what the advantages are of extending >> ArgoEventListener etc rather than just extending EventListener, >> EventObject? >> >> Bob. >> >> >> 2008/6/30 Bob Tarling <[EMAIL PROTECTED]>: >> >> As you've discovered, we've got a few conventions. :-) Some things >> >> extend ArgoEventListener in an event-specific manner and others >> >> implement PropertyChangeListener directly. Generally I prefer the >> >> former style, but I'm not really thrilled with the central event types >> >> registry in ArgoEventTypes since this seems to introduce more coupling >> >> than is desirable. Having said that, I think extending >> >> ArgoEventListener is the right way to go for this since it will keep >> >> things consistent. What do others think? >> > >> > I really don't like the way we've used PropertyChangedEvent, I think >> > that was not the best decision for listening to changes from the model >> > subsystem. It makes a class that's listening poorly self-documenting >> > as it's not actually clear what it is interested in listening to. It >> > can also result in bloated methods dealing with too events from >> > different subsystems. >> > >> > I'm don't know what advantage there is of having our own base events >> > and listeners or a central registry. Just extending EventListener and >> > EventObject I would have thought would be fine. But then we have a >> > third way. >> > >> > Bob. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > On Tue, Jul 8, 2008 at 2:55 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > >> This conversation doesn't seem to have gone on any further. >> >> Can anyone explain to me what the advantages are of extending >> ArgoEventListener etc rather than just extending EventListener, >> EventObject? >> >> Bob. >> >> >> 2008/6/30 Bob Tarling <[EMAIL PROTECTED]>: >> >> As you've discovered, we've got a few conventions. :-) Some things >> >> extend ArgoEventListener in an event-specific manner and others >> >> implement PropertyChangeListener directly. Generally I prefer the >> >> former style, but I'm not really thrilled with the central event types >> >> registry in ArgoEventTypes since this seems to introduce more coupling >> >> than is desirable. Having said that, I think extending >> >> ArgoEventListener is the right way to go for this since it will keep >> >> things consistent. What do others think? >> > >> > I really don't like the way we've used PropertyChangedEvent, I think >> > that was not the best decision for listening to changes from the model >> > subsystem. It makes a class that's listening poorly self-documenting >> > as it's not actually clear what it is interested in listening to. It >> > can also result in bloated methods dealing with too events from >> > different subsystems. >> > >> > I'm don't know what advantage there is of having our own base events >> > and listeners or a central registry. Just extending EventListener and >> > EventObject I would have thought would be fine. But then we have a >> > third way. >> > >> > Bob. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
