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

Re: repeats

From: Jason <jeacott@hardlight.com.au>
Date: Mon, 06 Nov 2006 10:49:53 +1030
Message-ID: <454E7FA9.3080805@hardlight.com.au>
To: www-forms <www-forms@w3.org>

ok - but this is clearly a hack and turns out to be more complex than
you describe. What in fact you are doing is always leaving a node and
starting at the second row in the repeat. but when I submit this data
somewhere I'll have an extra row in my XML where I dont want it right?
So now I have to actually "clean" this up by deleting all the nodes
where there is only 1 left before submission for each node that might
require a repeat. - but when we reload this same data what then? I dont
have anything left to start with. If your argument is that I should be
happy to submit data with "fake" rows and let whatever application I am
submitting to take care of it then I would consider that very
unsatisfactory. I am saving unrepresentative data - should I guess which
elements have fake first nodes, assume every node's first node is fake?,
I may not actually have control over the XML format I need to represent
and submit, nor the source of any loaded data. So how in Xforms 1.0 can
I achieve this? I don't think its possible. But it was all fine with the
previous paradigm in use, and insert that didnt do nothing with an empty

I'd like to change perspective on this issue for a moment. As a user of
a form containing repeats. If I remove the last visible row, shouldnt I
expect to be able to recreate another one? In practice I definitely want
to. I cant think of a single other grid/spreadsheet/application that
allows you add/remove rows that also has the caveat that if you remove
all the rows then you must restart the program. Its just weird and
completely counterintuitive for both the user and the developer. I dont
  think it should require a special case with Xforms, and I certainly
dont think it should require that the effective data structure and
subsequent data handling all need to alter in order to facilitate this.

> Thanks for starting the sample.  You have two distinct data sets.  Did 
> you mean that either could be used as the prototype for the *same* 
> repeat or two different repeats?  If two different repeats, then I still 
> don't see how you're generating a problem.  If the same repeat, then I 
> still don't see why it isn't the same and likely *worse* to take a 
> snapshot of data on startup to use for insertions.

Yes I have 2 distinct datasets, but Its quite possible to use the same
view to handle them both (as long as the view isn't actually interested
in the extra attibute - which may well be the case for all kinds of real
world scenarios). Xforms is pretty cool in that once you get one working
you can be very sure it will keep working without unexpected side
effects or holes. This option whilst very useful provides some measure
of potential runtime hole. This option in 1.0 is NOT possible at all so
in many ways this possibility is better just because it exists. I'm just
offering up something that developers might need to be aware of should
they use this.

Please don't get me wrong - I love that the OPTION now exists to source
from another instance for prototypical data. I just dont think it needs
to be mandatory. And I really do think that the resultant change to
insert renders it hopeless. As for the previous complexity argument, is
it reasonable that any Xforms designer that uses repeat should need to
know your trick just to enable it in case they also need a zero option?
how scary is <xf:repeat nodeset="item[position()!=last()]"
id="repeat-cart"> for a newbie?
and how on earth can anyone leverage a bind doing this?

surely <xf:repeat bind="mynode" id="repeat-cart"> combined with
    <xf:insert bind="item" at="index('repeat-cart')" position="before"/>
is much simpler and used to achieve exactly the same result, also
without the need to remember to delete the extra nodes on submission,
and then try to find some external way to recreate them before reload.

Received on Monday, 6 November 2006 00:20:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:19 UTC