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
>