Re: Level 3 Events

>You should be able to manipulate the ungrouped event listeners through the
>EventTargetGroup interface.

Agreed. I'd slightly prefer null to indicate the default group, but calling
it a standard pre-generated group works too. (The implementation's
virtually the same either way.)

>Also, is there a specific reason why EventTargetGroup does not have a
>dispatchEvent method?

That wasn't a requirement; we were concerned with the problem of event
cancellation being too global rather than with distributiong being global.
I don't have a real-world usecase for dispatch-to-specific-group, and it
would require additional code in the event distribution engine... so while
I agree it's interesting, I think it needs to be more strongly motivated
before we decide to put it in.


Name overlap on the methods: Names are scoped to an object.Consider just
how many Java objects use add(), for example. Since you have to say what
you're adding _to_, I don't see reuse of the add method's name as a problem
-- if anything, I think I prefer consistancy.

>I would assume that dispatchEvent's return value would be false if any
>listener in any group called preventDefault?

Makes sense to me.

>You could potentially add the same listener to the same event target on
>multiple groups.  Should the Event or EventListener interface be extended
so >that you could detect which group is active?

That depends on whether a listener gets called once if it's in any group
which is still active, or once per group. I don't remember what we decided
on that front. If it's only once, you don't need to know which group it
was. If it's multiple... I think that's like adding the same listener
multiple times to L2 events; probably not a good idea to begin with.

______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 3 August 2001 14:38:39 UTC