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

Re: repeats

From: Jason <jeacott@hardlight.com.au>
Date: Sat, 04 Nov 2006 20:33:51 +1030
Message-ID: <454C6587.80304@hardlight.com.au>
To: John Boyer <boyerj@ca.ibm.com>
CC: www-forms <www-forms@w3.org>



John Boyer wrote:
> 
> Hi Jason,
> 
> Sorry, but the stuff you are writing is really hard to respond to.  It's 
> just a stream of thoughts that makes huge assumptions every few 
> sentences that I understand certain things you haven't said.

sorry.

> For example, you say that great care would needed to be taken when 
> dealing with newly loaded data sets that might be subtly different than 
> prior ones in the form.  It escapes me how this point manages to 
> substantiate the complaint about the processor not taking a snapshot of 
> instance data on initialization. In fact, you are exactly describing 
> one of the things that was broken about the old method.  

this is just because suddenly you need 2 matching instances. 1 acting as 
prototype, and 1 containing working data. This was never a problem 
previously because it wasn't possible. My issue here is that in many 
cases the new regime is not required, so why not allow both options to 
coexist. that way simple forms stay really simple.
if for example you had 2 distinct sets of data like this
set 1
-----------
<data>
	<somenodeA/>
	<somenodeB someatt="true"/>
</data>
-----------
set 2
-----------
<data>
	<somenodeA/>
	<somenodeB/>
</data>
-----------

these could both conceivably be managed by the same xform, including 
repeats. but in the new 1.1 scenario I'll need 2 distinct prototype 
instances.
this is a simple fictitious example but there could easily be real 
reasons for doing this sort of thing. So when I load set1 I'd really 
need to be loading its matching prototype too, and then saving them 
together etc, and inventing ways to ensure they were matching pairs. 
Thats why I suggested that it might be difficult to manage. And as I 
said, I havent thought about it much, it was just something I thought 
could cause problems.

> In XForms 1.0, the <instance> element contains or references the initial 
> instance data, and the snapshot was taken during model-construct.  If an 
> instance replacement submission brought in new data over which a 
> repeat/insert should operate, but there was no matching data in the 
> initial instance data, then insert would just fail.

thats true.

> This conversation would therefore really benefit from some exact use 
> cases with example markup because your claim that XForms repeats are now 
> just for toy forms is not just hyperbole, it's just plain wrong.

I claimed this for 1.0 - I acknowledged that its fixed with 1.1

> The new design even of XForms 1.0 allows one to actually create arbitrarily 
> deeply nested repeats, not just one level, and it allows one to do so in 
> a way that survives a save/reload (e.g. submit data to server and come 
> back tomorrow to finish purchase order).

I'm not sure how this works - maybe I'm reading the wrong docs.
xforms 1.0?
http://www.w3.org/TR/2006/REC-xforms-20060314/slice9.html#action-insert

only has 'position' & 'at'
so if our user removes all her items from the shopping list - how do you 
start over? This is where my issue lies, so now all the forms I have 
that use this scenario (pretty much all of them) are broken and cannot 
be repaired as far as I can tell with 1.0 alone. If you have a way I'd 
dearly love to hear it.

I could always create nested repeats without problem. I think I tried to 
indicate that I still dont think its possible to produce arbitrarily 
deep on-the-fly child nodes and track them automagically with the view 
to create dynamic trees. I also dont think its possible to create one 
view that can display arbitrary data without that view requiring 
modification each time.

> And I still don't understand why you believe that insert on empty 
> nodeset should do something.  Even if you did have a prototype available 
> (i.e. pretend the above language faults did not exist), when the nodeset 
> resolves to empty, where should the node be inserted?

The processor knows where to look to determine that the nodesetcount is 
zero, so wouldn't it add the insert where it finds the zero count? or 
where a bind states it should be? If that parent is also missing THEN 
you could reasonably decide to do nothing. This seems like sensible and 
predictable behaviour - you could even put a switch on the insert to 
allow chasing back to the first recognisable ancestor, even if its the 
root node and then rebuild the node to be inserted and all the 
intervening ones. I dont know if that would be useful or not, but I dont 
see that its not possible.

In the interests of keeping this short - I accept your points re switch 
etc - I was just suggesting some things that I found awkward that seem 
only to make creating forms more cumbersome I wasn't suggesting any 
priorities at all.

I do truly appreciate your efforts, especially in responding to my 
previous stream of consciousness response.

Cheers
Jason.
Received on Saturday, 4 November 2006 10:04:15 GMT

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