Re: A few more ideas on delete and iterate

Personally I don't like us to have two versions of the delete action (remove from instance and destroy). It will make things so complicated for form authors. To me it kinda feels like going back to older languages where you have to do the memory management yourself.

I was starting to think of no longer arguing on this specific delete issue. But I also strongly believe we shouldn't special case iterate. And consequently, if we skip nodes deleted from an instance in iterate,  we should also (like John is doing) don't execute actions from which its context node is deleted from an instance. But this  has some side effects that I don't like:

<xf:action iterate="item">
  <xf:delete if="@selected"/>
  [action that requires a context isn't executed after that the delete (e.g.: insert, delete, any action with an AVT on it, ..)]
</xf:action>

Actions are imperative and the iterate is a loop construct, in other programming languages when you  loop you don't expect the loop to skip instructions when you use the local iteration variable when you removed the node to which it points from a document (it is perfectly legal to use the node that is deleted from the document aka instance in C++, Java,  ...).

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 06 Dec 2011, at 01:20, Leigh L Klotz Jr wrote:

I don't think we're going to be able to agree on whether delete makes the node unusable in XForms 1.1 or not, and I don't think it's productive to argue it.

I think John has shown compelling use cases for the concept of removing a node from an instance and marking it to be skipped in actions and XPath functions that operate on instance data.  If you think about it, it's akin to a relevance MIP but extending to actions, just as setvalue obeys readonly.

So one way to look at this is to say it's a 'readable' MIP, and we might be able to decouple it from the way it gets set.

If that works out, we can then have an XForms 2.0 action to detach nodes from their parents, and leave them readable, and another to detach them and mark them readable=false.  Then we have firm semantics under control of XForms spec, and don't depend on one interpretation or another of how we have bolted on mutability to the XPath data model.  It fits well with John's implementation (a mark on a node is very much like the way some implementations store MIPs), and it lets us satisfy both sets of use cases in XForms 2.0.

Leigh.

On 12/02/2011 11:57 AM, Nick Van den Bleeken wrote:

So the good news is that we only have to agree on if delete only deletes nodes from instance data or also destroys the nodes and behaves as if they are removed from all other sequences that contain that node. I (and Erik I think) would go for the first option (only delete only deletes nodes from instance data), and you would go for the later I believe. We should try to come to a consensus on this.

Maybe we could try to compile a list of the advantages and disadvantages of both approaches?

1. Delete only deletes node from the instance
+ Behaves like remove works on DOM
+ No extra marking on the complete subtree of the deleted node
- Need for an extra function to test if a node is part of an instance

2. Delete destroys node (behaves as if  all references to the node are destroyed)
+- When a node is deleted from the instance it disappears everywhere
- Extra marking on the complete subtree of the deleted node
- Requires extra checking in all iterate loops
- Should all child actions of an action that no longer has a context stop?
- Hard to implement if the node was retrieved before deleting it with our DOM interface

Kind regards,

Nick Van den Bleeken
R&D Manager

 think everybody agrees on 3) too


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer