[gdome]Mutation Events (fwd)

[Luca Padovani <padovani scl csd uwo ca>]

Incidentally, the following email about Mutation Events and the
DOMSubtreeModified event has been posted today on the www-dom w3 org
mailing list. Point 2) below, in particular, is the problem I raised in my
previous email.

Let's see what happens,
luca

---------- Forwarded message ----------
Date: Mon, 22 Apr 2002 04:12:52 -0400
From: Michael B. Allen <mballen erols com>
To: www-dom w3 org
Subject: Mutation Events
Resent-Date: Mon, 22 Apr 2002 04:07:46 -0400 (EDT)
Resent-From: www-dom w3 org

I just implemented mutation events and I'm trying to grasp the zen of the
event model. For example, to test my implementation I created a copy of
a document driven entirely by mutation events triggered by the builder
loading a document (like SAX the hard way :). It works but it is not
what I would call elegant. I created an event handler object with two
Node member vars (say 'orig' and 'copy') and then registered that object
to recieve DOMNodeInserted and DOMAttrModified events. The stange part is
that it appears as though you cannot listen to just changes to an elements
immediate children. So to know what event targets to copy and add to the
'copy' node I had to check the event target's parentNode (or relatedNode)
with 'orig'. If they matched it was an immediate child. Otherwise I
would recieve bubbling mutation events from all decendants. In the event
DOMNodeInserted event handler I would then create another object with
'orig' and 'copy' Node members and register that (so it's recursive). Am I
interpreting this correctly or is there an elegant technique to using this
event model? Or is the task I have chosen just a bad example of practical
Mutation event usage?

Also, a little more on topic;

1) If one DOMSubtreeModified event occurs in response to a single child
node operation (say appendChild), the target of the event would be
the *parent* of the child inserted yes? The expression "lowest common
parent" is clear enough but I just want to assert that this is indeed
intentionally different from the behavior of "the more specific events"
DOMNodeInserted and DOMNodeRemoved which are dispatched on the children
themselves and not their parents.

2) May DOMSubtreeModified events for something like removeChild() be
dispatch *before* the child is removed like DOMNodeRemoved requires or
alternatively, because these events may be deferred, for the sake of
consistency, should they be dispatched *after* the child is removed?

3) For DOMNodeInserted and DOMNodeRemoved can relatedNode and
target->parentNode ever differ? If not, why is relatedNode necessary?

4) Can you expand on the context info for DOMAttrMopdified? For example,
if an attribute is being removed, what are the values of prevValue and
newValue (I guessed the current value and null)?

Thanks
Mike

-- 
May The Source be with you.