Re: Mutation events replacement

2009/6/4 Jonas Sicking <jonas@sicking.cc>:
> On Thu, Jun 4, 2009 at 4:46 AM, mozer <xmlizer@gmail.com> wrote:
>>
>>
>> On Thu, Jun 4, 2009 at 1:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> On Thu, Jun 4, 2009 at 4:37 AM, mozer <xmlizer@gmail.com> wrote:
>>> >
>>> >
>>> > On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> >>
>>> >> Here's an API that might work:
>>> >>
>>> >> The following methods are added to the Document, Element and
>>> >> DocumentFragment interfaces:
>>> >>
>>> >>  addAttributeChangedListener(NodeDataCallback);
>>> >>  addSubtreeAttributeChangedListener(NodeDataCallback);
>>> >>  addChildlistChangedListener(NodeDataCallback);
>>> >>  addSubtreeChangedListener(NodeDataCallback);
>>> >
>>> > I would go for
>>> > addSubtreeElementChangedListener for this one since a modification to an
>>> > attribute in the subtree does not trigger it
>>>
>>> the 'SubtreeAttributeChanged' callbacks are called whenever an
>>> attribute is the subtree below the node where the callback is
>>> registered is changed. Is that not what you need? I.e. in a DOM like
>>>
>>> <body>
>>>  <div>
>>>    <p>
>>>      here's some text
>>>    </p>
>>>  </div>
>>> </body>
>>>
>>> If I call  div.addSubtreeAttributeChangedListener(doStuff);
>>>
>>> then doStuff is called if someone sets an attribute on the <p> element.
>>
>> We're in agreement here !
>> That's why I would go for a name stating explicitly that it is about ELEMENT
>> in the subtree and not Whatever in the subtree
>
> Ah, now I understand what you're suggesting. I think "ElementChanged"
> could mean more than attribute changes though, such as children added
> or removed.
>
> I'll leave debates for things like names for later though, until
> there's agreement that this is the general API we want to go for.
>
> / Jonas
>
>

What about the simpler:
void addModificationListener(in DOMString type,in NodeDataCallback
handler, in boolean subtree);
void removeModificationListener(in DOMString type,in NodeDataCallback
handler, in boolean subtree);

with a string for the modification type (ElementAdded,
ChildListChanged, ElementRemoved, AnyNodeAdded, etc.), the handler as
a NodeDataCallback and a boolean indicating if we want to track all
the subtree or only the current node.

Possibly, the first argument may be an integer (an enumeration), the
first function may return an opaque identifier to be used in
removeModificationListener instead of those three arguments, because
handler may be lost between addML and removeML, and NodeDataCallback
may be extended to include a NodeList of nodes involved in the
modification.

This way we don't have to create a function for every node type (any,
attribute, element, chardata), multiplied by every node operation
(add, remove, change), multiplied by 2 (current node only or all
subtree) and again by 2 (add and remove handler) and thus we
disambiguate between different dom operations in fast native code,
rather than in the slow JS interpreter.

Lastly, you could use the event queue mechanism used by HTML5 for
asynchronous events (modifications callbacks are just events that are
not captured and neither bubble), instead of defining your own.

Giovanni

Received on Thursday, 4 June 2009 13:34:21 UTC