Re: Mutation Events

On Mon, 2002-04-22 at 04:12, Michael B. Allen wrote:
> 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?

I believe your interpretation is correct.

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

This is correct.

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

The description that the DOMSubtreeModified event is dispatched after
the modification. You'll get:
1- DOMNodeRemoved event
2- {the node is removed from the tree}
3- DOMSubtreeModified event

> 3) For DOMNodeInserted and DOMNodeRemoved can relatedNode and
> target->parentNode ever differ?

from the description, I believe not.

>  If not, why is relatedNode necessary?

I guess it is not. I suspect the clarification *after the insertion* and
*before the removal* where done after the relatedNode description, and
we did realize that relatedNode was no longer necessary for those 2
event types.


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

I believe the description should read:
"[...] The value of MutationEvent.attrChange indicates whether the Attr
was modified, added, or removed. If the Attr node is being added,
MutationEvent.newValue is in use. If the Attr node is being removed,
MutationEvent.prevValue is in value. If the Attr node is being modified,
MutationEvent.newValue and MutationEvent.prevValue are in use."

Philippe
(digging some old events issues)

Received on Wednesday, 29 January 2003 14:57:45 UTC