Re: DOM Events

Jean-Yves Bitterlich <Jean-Yves.Bitterlich@Sun.COM> wrote:

> Bjoern,
> Thanx very much for the prompt reply.
> here tackling the EventTarget.dispatchEvent point:
> (see inline)
> 
> Bjoern Hoehrmann wrote:
> > * Jean-Yves Bitterlich wrote:
> >   
> >> Method: EventTarget.dispatchEvent(Event evt)
> >> It is unclear how to notify an application about incorrect event
target,
> >> when correct event is being dispatched to incorrect eventTarget by
> >> EventTarget.dispatchEvent(Event evt).
> >>     
> >
> > Thank you for your comments. The DOM Event Model does not have a notion
> > of correct event types for an event target, and there is consequently no
> > way to inform applications of semantic errors it might have made. It is
> > in fact difficult to see how such a notion might be defined. For example
> > the DOMAttrModified event is currently defined only for Element nodes in
> > the DOM Event Flow, but future specifications might re-use it to inform
> > applications of changes of pseudo-attributes on processing instructions
> > like xml-stylesheet. Applications might then use dispatchEvent to simu-
> > late this in legacy implementations.
> >   
> The feedback from our developer:
> 
> List of event types is declared in the section  "1.4.2 Complete list of 
> event types" of "Document Object Model (DOM) Level 3 Events 
> Specification" 
>
(http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-EventTypes-complete).

> Let's examine the DOMActivate UIEvent. According to this section: "Some 
> events will only be dispatched to a specific set of possible targets, 
> specified using node types.". The possible target for DOMActivate event 
> is an Element only (according to the table in this section). I will be 
> using JAVA syntax.
> 
> First step, I created an intstance of UIEvent with type DOMActivate by 
> DocumentEvent.createEvent("UIEvent") and UIEvent.initUIEvent(..) with 
> appropriate parameters.
> 
> Second step, I tried to dispatch this instance of UIEvent to Comment by 
> ((EventTarget)someComment).dispatchEvent(.....)
> 
> Specification doesn't explain, what a DOM implementation SHOULD DO in 
> this case.

The DOM implementation MUST carry out the standard DOM event dispatch.
Nothing more, nothing less.  Your example of dispatching events to Comment
is perfectly allowable, as Comment implements EventTarget (via CharacterData
and Node).


Where the DOM Level 3 Events document is lacking, in my opinion, is that it
does not say enough about dispatch of events to objects that implement
EventTarget but do not implement Node.  In my DOM implementation, my
XMLHttpRequest objects implement EventTarget.  Quite how this fits with
capturing, at-target and bubbling phases or default event handlers isn't
100% clear to me - although in this case, I think it is obvious that you
just get an at-target phase. But what about other non-Node objects that are
arranged in a tree hierarchy? Also, *I* think it's obvious, but somebody
else might think that some other behaviour is equally obvious.



> I mean, that event target is incorrect (not suitable) in this 
> case (see column "Target node types" in the table of "information on the 
> event types" in the section 1.4.2). Also  I can't find any appropriate 
> notifications in specification for applications. Such notifications may 
> be useful for application development.
> 
> I can suggest three possible use cases for such situations:
> 
> 1) Dispatch event to the "incorrect" (not suitable) event target and add 
> appropriate description to specification.
> Cases when "event targets able to restrict the types of events which can 
> be dispatched to them"
> 2) Add new Exception to the section "Exceptions" of 
> EventTarget.dispatchEvent, throw it and add appropriate description to 
> specification.
> 3) Do nothing and add appropriate description to specification.
> 
> I guess that second case is more preferable for application developer.

The second option would be incredibly difficult for DOM implementations - it
would likely introduce browser incompatibilities left, right & centre as
different versions of different browsers had different lists of which events
can be dispatched to which objects.

As far as I am concerned, as an implementor of a DOM framework, it is
imperative that EventTarget.dispatchEvent() always be permitted to dispatch
the specified event, so that listeners registered with addEventListener are
invoked when the event types in the event and the listener match.


> > > Method: DocumentEvent.canDispatch() The documentation of canDispatch
> > > says: "Tests if the implementation can generate events of a specified
> > > type." while the return value description is: "true if the
> > > implementation can generate and dispatch this event type, false
> > > otherwise" Note there is "and dispatch" part of the assertion. If we
> > > remove this part, then there will be no reason for confusion with an
> > > application events. Now it sounds like the implementation cannot
> > > dispatch application specific events.
> >>     
> >
> > I think simply removing the offending phrase is not the best course of
> > action, at least not until the draft defines what it means if an imple-
> > mentation is able to generate an event type. I will try to come up with
> > better text for this.

To be honest, I do not understand fully under what conditions canDispatch()
can return FALSE other than either the namespaceURI or type is invalid
according to the naming rules for those strings.  But if that is all that it
can do, then perhaps it would better to remove it completely and rely on
dispatchEvent raising INVALID_CHARACTER_ERR exceptions as appropriate.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Thursday, 29 March 2007 15:21:10 UTC