Re: Mutation events replacement

2009/6/4 Jonas Sicking <jonas@sicking.cc>:
> On Thu, Jun 4, 2009 at 6:33 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> 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.
>
> Why would it be easier to keep track of the opaque identifier than to
> keep track of the callback. In fact, couldn't you use the callback as
> a opac identifier?

Actually, you're right.

>> 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.
>
> I'm not quite following you here. Can you provide an example of a use
> case and code pattern that would be problematic?

Just compare your list of methods and mine, then consider that yours
is incomplete:you need a new operation if you want to keep track of a
new modification, let it be a new node type in XML2/DOM4Core or a new
modification like EntityReferenceLocationChanged
(EntityReference.systemId) or ElementTypeInfoRedefined
(Element.schemaTypeInfo), mine instead is complete. In particular, you
need 4 new entries in the property table for every extension (add
current, add subtree, remove current, remove subtree), I need just one
integer value.
Adding specific methods, that may be overridden at JS level, is way
more burdensome than adding just two generic.

On the author side, I don't find it very different to write
el.addElementSubtreeChangedListener(function() {})
than
el.addModificationListener(el.ElementListChanged,function() {},true)
or even
el.addModListener(el.SubElementMod,function() { },true);
(using compact names)

and personally, I prefer the latter option

>> 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.
>
> I think we want the notifications to fire by the time that the
> function that caused the DOM mutation returned. So in code like
>
> myNode.innerHTML = "<b>hello world!</b>";
> doStuff();
>
> by the time doStuff is called all the notifactions have fired and
> updated whatever state that they need to update.

So actually modification handler are syncronous.
In that case, we may need something like .startTransaction() and
.endTransaction()
1) to batch modifications for author code
2) to lock author code from unexpected modifications

In my first interpretation, I was confused by this sentence:
> The only undesirable feature is that code that mutates the DOM from
> inside a callback, say by calling setAttribute, can't rely on that by
> the time that setAttribute returns, all callbacks have been notified.
> This is unfortunately required if we want the second desirable
> property listed above.
and I don't see why we need a global callback list, rather than one
local to the "modification batch list"

> / Jonas
>

Giovanni

Received on Friday, 5 June 2009 16:04:23 UTC