Re: EventTarget and EventListenerGroup

On Fri, 2003-02-21 at 23:11, Christian Parpart wrote:
> yet another issue on my list I can't solve belong the the DOM Level 3 
> Events Module.
> 
> What phase is entered first? I guess 1.) AT_TARGET, 2.) BUBBLING_PHASE, 
> and 3.) CAPTURING_PHASE. But I didn't find any pharagraph that mentioned 
> this.

I know that we don't put enough of the "WG knowledge" into the
specification but I have to say that you're stretching the event model a
lot here. I thought about that one already but Section 1.2.1 enumerates
the phases with a _numbered_ list, so I concluded that was enough. I'll
"clarify" this in the specification.

> Can a EventListenerGroup contain EventListeners for different EventTargets?

EventListeners that are attached to different EventTargets can be linked
to the same group. The same event listener can be linked to more than
one group.

> This is an important issue since this would heavily change the implementation 
> part.

Not sure why. DOM Events don't give you the possibility to list the
event listeners that are part of a group. The implementation does not
even need to list them, all it needs is to list them for a specific
event target. It is true that you need to store the association between
an event listener and an event target but it should not be that heavy.
In fact, all DOM implementations that are linked to a user interface are
already doing so underneath anyway, in order to separate their system
event listeners from the user event listeners.

> the EventListenerGroup.isSameEventListenerGroup(grp) function returns true if 
> this is really the same event listener group. but would this be even possible 
> to test by comparing their pointers like in C++ as follows?
> 
> EventListenerGroup *evg1 = myDocument->createEventListenerGroup();
> EventListenerGroup *evg2 = myDocument->createEventListenerGroup();
> /* ... */
> if (evg1 == evg2) ; /* pointer comparison: are they the very same thing? */
> if (evg1->isSameEventListenerGroup(evg2)) ; /* your method: like above? */
> /* the end */

I believe that this is correct, however this implies that we will never
extend groups and will not provide more methods to access them like we
did with Nodes. Or, if we do, we will have to guarantee that the object
is always the same (unlike Nodes).

to address an other of your concern:
> For the non-profit organization case (as this would apply to) 
> is twice as much as I get a year(!).

I really hope this is not your case even if this is correct that
$5750/year to join an organization is not something affordable by
"regular people".

Philippe

Received on Saturday, 22 February 2003 22:46:04 UTC