Re: repeats

Jason wrote:
 >
 > 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
 > node.

Your analysis is correct. John's solution is good and deserves being
exposed, but as you point out it has some drawbacks as well.

However we are beating a dead horse here. The XForms Working Group has
recognized a long time ago that XForms 1.0's handling of repeats was
not optimal.

In my opinion an excellent solution is provided by XForms 1.1 with the
@origin attribute on xforms:insert. With that attribute:

o You create insertion templates in separate instances.

o You don't have a discrepancy between your instance at runtime in the
   form and your instance as it is submitted or restored.

o You always deal with perfectly clean instances that validate as you
   expect with schemas and don't need to contain extra content.

o You have code that is easier to write and understand.

I am convinced that the 1.1 solution not only cover the requirements
for repetition but it leads to elegant code and architecture. I don't
find any fault with it. It certainly does not lead to the confusion of
the original XForms 1.0 behavior, or to the remaining drawbacks (that
you exposed) of the XForms 1.0 Second Edition behavior. There is do
doubt in my mind that the worse thing we could do would be to go back
to the original XForms 1.0 behavior.

So let's get over this and get implementors to implement the 1.1
@origin attribute. We have implemented it in Orbeon Forms ever since
this feature appeared in a 1.1 draft, and we have built numerous
applications with it to our satisfaction.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 6 November 2006 16:45:42 UTC