Re: repeats

Well, many of the implementers did not implement the idea of taking a 
snapshot of initial instance data.
They would take the prototype from the running data, then clear the text 
out.
This was being done because of difficulties with identifying the initial 
data in the case of nested repeats
and especially because the initial instance data idea does not work in the 
prepolulation case.

With XForms 1.1, you have a number of options.

1) you can use the non-relevant last row method for 1.0
2) you could store the instance and matching prototype
3) if your application is designed to have the prototype in the initial 
instance, then you can write a handler for xforms-model-construct-done or 
xforms-ready to take your own snapshot.

There are even more choices but this list is sufficient because #2 is 
clearly a trivial task, and avoids the pitfalls of #3 (which is just 
saying that you can, with little effort, reimplement the original idea if 
your use case is constrained the ones that the original idea solved).
 
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





Jason <jeacott@hardlight.com.au> 
Sent by: www-forms-request@w3.org
11/03/2006 04:36 AM
Please respond to
jeacott@hardlight.com.au


To
www-forms <www-forms@w3.org>
cc

Subject
Re: repeats







ok - so with the new draft and xforms 1.0
I now have to load an instance and a matching prototype instead of the 
original idea of using the initial instance as the prototype.

in every practical xform I have made I have always ended up setting my 
instance as an empty prototype anyway, then I either remove all the 
offending elements in the xforms-ready event handler, or load new data 
from somewhere.
why is the 1.1 notion any better than this? and if there is a froced 
prototype (and there is) then why not label it as such, then you could 
re-automate activity like the original insert idea without the xform 
author needing to specify the default behaviour?

I was hoping that xforms was moving more toward a more free idea with 
respect to managing the xml model, with the bind  elements representing 
the effective interface between model and view. more and more I find 
myself required to use xpath instead of bind in many view attributes 
just because they dont accept a bind or because I cant include the xpath 
functions to get things working in combination with binds.    I was 
hoping to be able to effectively traverse unknown xml structures and 
create trees dynamically etc. unfortunately this seems not to be the 
current direction.

where would be the harm in restoring the older notion of the original 
instance data operating as the default prototype? the new context and 
origin options would not be effected and could be left in place for 
those that choose to use them when they are actually needed

Jason.