- From: Aaron Reed <aaronr@us.ibm.com>
- Date: Tue, 24 Oct 2006 18:31:25 -0500
- To: www-forms@w3.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 UTC