W3C home > Mailing lists > Public > public-forms@w3.org > May 2009

Re: XForms 1.1 - target of the xforms-delete event

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 27 May 2009 10:59:55 -0700
Cc: xforms <www-forms@w3.org>, www-forms-editor@w3.org
Message-Id: <1FCDE717-2481-43DD-83E0-C9D911DA8A23@orbeon.com>
To: Forms WG <public-forms@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

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