RE: Reset and insert actions

Doesn't duplicate handle the case for remembering a saved set point?

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Wednesday, October 25, 2006 11:18 AM
To: Klotz, Leigh; Aaron Reed
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: RE: Reset and insert actions



Hi Leigh and Aaron, 

Well, Leigh's example doesn't sound like the most prevalent usage pattern by any means because it seems to assume replace none, and because it relies on the processor taking a snapshot of instance data on startup.  We ended up with a whole pile of errata to XForms 1.0 to dig our way out of the problems this caused for insert.  Basically, it assumes that the form data will never be saved and reloaded, i.e. that the form will never be saved in-progress only to have the data reloaded when the user wants to continue the work.  It's hard to imagine adding yet another attribute to submission to optimize the expression of this case. 

Nonetheless, it does so happen that we have future requirements  to determine common usage patterns and make more direct ways of getting at those features.  I think you have described the following pattern:: 

model 
   instance 
   prototypical instance 
   submission replace=none 
        on xforms-submit-done, insert prototypical instance into instance 

and that you would want to optimize this with some kind of boolean reset-when-done attribute on submission.  The implementation would consist of having the processor remember some initial instance data on model construct and then use that to replace an instance when submission is done.  Assume source instance, not target since assume replace=none. 

Finally, in Aaron's case it is hard to imagine how the new feature could put the model in a state unachievable by use of an insert action given the claim that reseting the instance to some initial state is indeed equivalent to having an extra instance with that initial data and then inserting it into the instance for which reset is desired.   It's just two different ways of spelling the same operation, so at least the semantics should be identical. 

Cheers, 
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: www-forms-request@w3.org 

10/25/2006 10:13 AM 

To
<www-forms@w3.org> 
cc
Subject
RE: Reset and insert actions

	





For some example of this use case, if you use the same submission to reset the instance data to the initial state when you post the filled-out info then it should happen automagically. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Aaron Reed
Sent: Tuesday, October 24, 2006 4:31 PM
To: www-forms@w3.org
Subject: Re: Reset and insert actions


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
>