- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Wed, 27 May 2009 10:59:55 -0700
- To: Forms WG <public-forms@w3.org>
- Cc: xforms <www-forms@w3.org>, www-forms-editor@w3.org
> Another possible fix is to have xforms delete ignore nodes which are > not in the same instances as the first node, or to no-op entirely. This would make the xforms-delete event much less useful. > Insert can only insert nodes into one instance, so it is reasonable > to have consistency with delete. When delete was changed from one > node to many nodes, the most urgent requirement we had in mind to > satisfy was deletion of a set of children of a given node. This can > reasonably expand to nodes having a common ancestor, but crossing > DOMs just seems a little much, esp. without the analogous insert > ability. I don't buy the consistency argument here. We have to look at events from the perspective of form authors, not XForms implementors. If xforms-delete is an event you can listen to to figure out that nodes were inserted into a given instance, then it needs to be dispatched to an instance when nodes are removed from it. If xforms:delete is able to delete events from more than one instance, then it follows that xforms-delete must be dispatched to all instances from which nodes were removed. If we can't rely on an event to be accurately dispatched, then we should think about removing that event altogether. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
Received on Wednesday, 27 May 2009 18:00:34 UTC