W3C home > Mailing lists > Public > www-forms@w3.org > October 2006

Re: Reset and insert actions

From: Aaron Reed <aaronr@us.ibm.com>
Date: Tue, 24 Oct 2006 18:31:25 -0500
To: www-forms@w3.org
Message-ID: <ehm7qr$kdf$1@sea.gmane.org>

The only reason I can think of is that data in separate models are 
absolutely independent but data that is in the same model could very 
well be dependent on each other.  So if you reset some instances and not 
others, you could get the model in a state that it could not get in by 
any other means.  Like you might have computed nodes that aren't reset 
even though the nodes they depend on are reset.  So keeping this on a 
model basis it saves the form author from himself.

Another inconsistency to using @instance is that it would force the form 
author to give the default instance document an id whereas most other 
things in XForms defaults to the first instance document in a model if 
instance isn't specifically used.

But I see your point.  It could be useful if used carefully.

--Aaron

Rafael Benito wrote:
> 
> 
> Hi all,
> 
> the reset action accepts a single attribute for the model to reset. It 
> would be useful for authors to add a second optional attribute @instance 
> to reset a single instance rather than the whole model. The same effect 
> could be accomplished using a sequence of setvalue, insert and delete 
> actions; but anyway it would be simpler to add @instance. In data entry 
> applications it is a common case to enter some general info and, then, 
> run through a loop entering data, sending them and then starting again 
> the loop but keeping the general info introduced at the begining of the 
> form execution. For this kind of applications, it would be useful, as 
> you can store general info in ino instance and the rest of the data in a 
> different one which is reset for every iteration.
> 
> In any case, the reset implemetation requires that the processor 
> "remembers" the initial state of the model. This fact draws me to some 
> other thoughts: in Xforms 1.0 there was a problem with the insert action 
> when the last node of an homogenous collection is deleted. This was 
> solved in 1.1 through the use of conditional actions and changes to the 
> insert action. Nevertheless, it would be simpler for authors to let the 
> processor  "remember" the "structure" of the homogenous collection 
> (rather than the initial state, because it could contain several rows 
> and that is not what we want) and let the insert action work correctly, 
> even if nodeset is empty but this was not the case for the initial data. 
> In case the author wants to insert nodes with a different structure, he 
> can still do it using the @origin attribute of the insert.
> 
> Regards,
> 
> *Rafael Benito Ruíz de Villa*
> Director Area e-business
> *Móvil* (+34) 617 314 293
> rbenito@satec.es <mailto:rbenito@satec.es>
> 
> MADRID <http://www.satec.es>
> Avda. Europa, 34 A
> 28023 Aravaca
> Telf.: (+34) 91 708 90 00 / 91 211 03 00
> Fax: (+34) 91 708 90 90 / 91 211 03 90
> 
Received on Wednesday, 25 October 2006 17:05:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:07 GMT