Re: Mutation events replacement

On 20/07/11 21:34, David Flanagan wrote:
> On 7/19/11 4:01 PM, Jonas Sicking wrote:
>> 'listener' above would be a function which receives a single argument
>> when notifications fire. The value of this argument would be an Array
>> which could look something like this:
>>
>> [ { target: node1, type: "childlist", added: [a, b, c, d], removed: 
>> [x, y] },
>>    { target: node1, type: "attributes", changed: ["class", "bgcolor", 
>> "href"] },
>>    { target: node2, type: "characterdata" },
>>    { target: node3, type: "childlist", added: [r, s, t, x], removed: 
>> [z] } ]
>>
>>
> Given that childlist and attribute changes are merged together into 
> arrays, there is, in general, no way to reconstruct the ordering of 
> mutations.  In the example above, I'd assume that the first change to 
> node1 occurred before the change to node 2.  But there are 8 other 
> changes to node1 and we know nothing about their ordering relative to 
> the others.
>
> So, if mutation order is not preserved, is an array the right data 
> structure for this unordered set of mutations?  There is a Map type 
> proposed for ES.next that allows objects as keys: 
> http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets  
> Would it be helpful to use that as the basis of this data structure?  
> Or could DOMCore define a NodeMap type (to go along with NodeList?)
>
> I don't have a specific use-case in mind, but I wanted to bring this 
> up since I imagine it would be nice to be able to quickly find all 
> mutations for a given target node without having to do a linear search 
> with Array.filter() or similar.
>
>     David
>
>

For the distributed editing use case, preserving the order of mutations 
is critical as is being able to identity the nodes involved. In my 
editing application I serialize changes to the DOM as JSON as an array 
of changes where each change is an object with properties that name the 
node (via a tumbler notation), the operation (e.g. insert, remove, 
move), and additional operation specific properties. Each mutation event 
is added to a temporary queue of sets of reversible changes. The changes 
are periodically serialized and transmitted via websockets.  The queue 
of reversible changes includes the DOM nodes and this is exploited to 
permit undo/redo operations. The tumbler references are computed during 
the mutation event handler since they may well change before the 
mutation is serialized and transmitted to the server.

I listen to mutation events for a div element with the content editable 
flag. I don't use the execCommand API as it currently varies too much 
from one browser to the next. However, I do have to deal with how 
browsers change the DOM in response to keystrokes, especially, enter, 
backspace and delete. Inserting a node is expensive as I have to 
serialize all of its content nodes. This is why a move operation is 
valuable.

The local undo/redo queue of changes has to be updated to reflect 
changes by other editing clients, but that is another story!

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Thursday, 21 July 2011 09:48:24 UTC