- From: Michael B. Allen <mballen@erols.com>
- Date: Mon, 22 Apr 2002 04:12:52 -0400
- To: 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.
Received on Monday, 22 April 2002 04:07:22 UTC