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<d...@w3.org> http://www.w3.org/People/Raggett
