Re: DOM Level 3 Events (and XPath)

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.
The draft is at
 http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/

> 2. interface CustomEvent
> 
> I do not believe that CustomEvent is needed since I even just implemented it 
> after have the main stuff working from the events stuff.
> AFAIK CustomEvent gives just access to some members for at least the 
> EventTarget's dispatching methods. While I do not know whether Java does 
> support friend classes to access private members I still propose to remove 
> this interface since it is very implementation specific and there is really 
> no need for the application writer to have access to these private members of 
> the Event interface - or give me some reasonable examples :o)

[skipping since Johnny already replied]

> 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.

> 4. EventFOO.initFOO[NS](...)
> 
> Letting all these methods returning the Event that they are (this) would be 
> very helpful for the application programmer since it sometimes makes sense to 
> combine several functionis together.
> 
> There's my C++ use case:
> 
> dispatchEvent(document->createEvent("Foo")->initFoo("bar"));
> 
> Although while C++ does not have any GC I assume that the 
> EventTarget.dispatchEvent() method may take ownerchip of its
> passed event object. does this violate the spec to be conform?

[skipping since Johnny already replied]


> 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).

> 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.

Philippe

Received on Thursday, 24 July 2003 14:41:28 UTC