W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2003

Re: DOM Level 3 Events (and XPath)

From: Christian Parpart <cparpart@surakware.net>
Date: Wed, 30 Jul 2003 00:14:53 +0200
To: Philippe Le Hegaret <plh@w3.org>
Message-Id: <200307300012.22425.cparpart@surakware.net>
Cc: www-dom@w3.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 24 July 2003 8:28 pm, Philippe Le Hegaret wrote:
> On Mon, 2003-07-21 at 10:21, Christian Parpart wrote:
> > 1.  Event.preventDefault() vs. preventImmediateDefault()
> >
> > Where exactly is the difference between Event.preventDefault()
> > and Event.preventImmediateDefault()? Sorry, I did not understand
> > it - and even why :( some examples would really help, probbably :o)
>
> The Event interface never had a preventImmediateDefault. You should
> compare stopImmediatePropagation and stopPropagation. Let me know if
> you're still having problems understanding the diferences. I do believe
> it is clear enough in the current draft.

Yeah, sorry, I meant stop[Intermediate]Propagation. It must have been very
very late while writing this mail ;)
Well, okay, I got some private help by a nearly native speaker ;) *NOW* I
believe to understand....

> The draft is at
>  http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/
>
> > 3. DISPATCH_REQUEST_ERR
> >
> > I do not understand why and when this can happen. the spec says "If the
> > Event object is already dispatched in the tree."
> > While this may happen in the dispatchEvent method I really have no case
> > for this to be thown. Could you give me an example what exactly is meant
> > by the spec?
>
> An event listener could certainly try to dispatch the event object it
> just received:
> function myListener(e)
> {
>  myOtherTarget.dispatchEvent(e);
> }
>
> While the event model is reentrant (see section 1.2.2.5), the DOM Event
> API does not allow the same event object to dispatch in the tree twice
> at the same time. So the event listener above will always raise a
> DISPATCH_REQUEST_ERR exception.

Ah, thanks, now I know what's meant ;)
If really someone wanna redispatch an event he shall clone this event and
dispatch the clone instead of of above case.

function ilovejs(e) {
    myOtherTarget.dispatchEvent(e.clone());
}

Yet another thing: Event.eventPhase() vs. Event.type()

I feel really not very happy about both Event properties. I'd either propose
to name both as:

Event.eventPhase() and
Event.eventType()

or

Event.phase() and
Event.type().

But having:

Event.eventPhase() and
Event.type()

looks very inconsistent to me :(

> > 5. XPath result sets
> >
> > Why the hell did you change the return type of all all the query
> > methods from XPathResult to DOMObject?
>
> XPath 2.0 is the reason. The idea is to be able to return XPathResult2
> (for XPath 2.0 result objects).

Since no implementation will provide XPath 1.0 *and* XPath 2.0 inclusivily.
I'd propose to keep that name XPathResult and just extend/modify this
interface. I really has no need to be backward compatible since we're talking
about a big version move (vom 1.0 to 2.0 ;)

> > Well, this may be straight forward compatible, but I always need
> > to dynamic_casrt here to test whether the result is *really* of
> > type XPathResult. This is really everything but performance friendly :(
>
> Noted. Not sure if we will do something about it but this is exactly the
> kind of comments we'd like to hear during the Candidate Recommendation
> period.

I suggest to provide generic XPathResult interface that provides some kind of
read-only property telling me what kind of result I have.
You may compare this to Node.nodeType() that can be implemented very fast by
just returning a member variable inline (in case of C++).

Greets,
Christian Parpart.

p.s.: now it looks like I've Events module completed before Core... *heh*

- --
 21:16:26 up 70 days, 12:22,  0 users,  load average: 0.02, 0.03, 0.05
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/JvHePpa2GmDVhK0RAnSpAJ0ROOIZQe4EX7ummAxORf83nRzt2wCfTx7W
0M2yPAWK7eTQ/vPdstVFpSg=
=tgZ9
-----END PGP SIGNATURE-----
Received on Tuesday, 29 July 2003 18:10:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT