W3C home > Mailing lists > Public > public-forms@w3.org > December 2011

A few more ideas on delete and iterate

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 1 Dec 2011 14:44:40 -0800
Message-ID: <CAAc0PEX+8jRpi+pbDeu_ZppnF2HiQzkSr99XXAtX2z5+nbsTVQ@mail.gmail.com>
To: public-forms@w3.org
All,

Some more food for thoughts on this topic.

1. An argument of familiarity using DOM's removeChild function

The first thing I wanted to point out is the behavior of removeChild in DOM [1].

(And yes I know that it's called "remove" not "delete" ;)

The interesting bit is this: "The removed child node still exists in
memory, but is no longer part of the DOM. You may reuse the removed
node later in your code, via the oldChild object reference."

In other words, mutations functions that remove nodes from the DOM in
browsers don't obliterate the removed nodes. This is also the case
with various DOM libraries (not necessarily W3C DOM) for Java that I
know of. The system assumes that references to DOM nodes might exist
independently of whether that node belongs to the actual HTML
(typically) DOM. This is not only possible using e.g. JavaScript
variables pointing to those nodes, but the removeChild function itself
returns the removed subtree.

Right now in XForms 1.1, since there are no variables, it's harder to
get into the situation of keeping references to nodes. However it is
possible as we have discussed, via the context node/item and related
function, for example.

XForms 2, with variables, only makes this much easier, and mirrors
what is possible to do in general-purpose languages like JavaScript or
Java.

I think the principle of least surprise for programmers here pushes
more towards behaving like the DOM.

2. Lazy @iterate

I suggested during last call that, independently from xforms:delete,
we could make @iterate lazy. The idea was that future iterations would
reflect node deletions that have occurred during past iterations.

DOM has a similar concept e.g. with
https://developer.mozilla.org/en/DOM/element.getElementsByTagName [2].

The interesting bit is this: "The returned list is live, meaning that
it updates itself with the DOM tree automatically."

Now thinking a bit more about this, it doesn't seem easy to implement
at all. The live list in DOM is based on tag names, to it is pretty
easy to maintain the live list (naively, for example using a linked
list, and checking removed subtrees upon remove/delete).

Now in our case, we are using XPath. Nobody wants to rewrite a new
XPath engine from scratch, so that causes problem. The simplest thing
to do would be to evaluate the whole list of items eagerly, and then
checks whether the results have been detached (deleted) using a
marking algorithm during delete. However, new data inserted into the
DOM would never appear in the @iterate, and it wouldn't be "live": it
would just not included deleted nodes, which conceptually is a bit
inconsistent.

So I am backing down on this idea that a lazy @iterate could help much here.

-Erik

[1] https://developer.mozilla.org/en/DOM/Node.removeChild
[2] https://developer.mozilla.org/en/DOM/element.getElementsByTagName
Received on Thursday, 1 December 2011 22:45:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:56 UTC