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

Re: repeats

From: Jason <jeacott@hardlight.com.au>
Date: Wed, 08 Nov 2006 11:08:02 +1030
Message-ID: <455126EA.7090806@hardlight.com.au>
To: John Boyer <boyerj@ca.ibm.com>, www-forms <www-forms@w3.org>

Hi John,
	you really dont seem to appreciate the problem with your solution with 
1.0se here.
You seem to accept this solution as viable:
> <bind nodeset="item[last()]" relevant="false()"/>
which it absolutely is not! There is no way I could use this. It's a 
neat trick and cudos for that but its useless i the real world. I need 
to submit data that makes sense - that means no "extra" nodes. And I 
need to reload that data again, so your solution cannot work. Can you 
imagine trying to explain to a client - or a colleague - why you are 
submitting data with rows that you just have to know shouldn't be there, 
so every other system that data comes into contact with must also be 
aware of the bogus nodes. Its crazy, if it was your suggestion that this 
change in 1.0se is ok because this solution is viable, then all I can 
say is that your political and persuasive skills are dazzling.

> XForms 1.0 SE gives you *the option* to do this deletion, whereas XForms 
> 1.0 forced it
> on you.  The option is better because there is a downside to the 
> deletion, which is that
> if the collected data is ever returned to the client-side for further 
> amendment, then the
> server-side of the web application must reinsert the prototypical data 
> as the last node.

This is just not true - the only place this stays true is if you are 
using jsp or something to directly amend your form - in which case its 
actually a different form!
I'm not saying that the source option shouldn't exist for insert - it 
definitely should, its a good change, but it shouldn't need to be mandatory.

> And of course, this didn't work out so well for those who support file: 
> URIs.

I dont follow this: file uri's should work just fine, as long as your 
actual form already contained the prototypical data, which I think we've 
already established it always needed anyway - and you don't get away 
from that with v1.1 either, its just all in another instance.
And there is/was always the option of defining your prototype as a set 
of binds instead of explicitly in the instance too.

I 'd probably be happier about the 2 instances representing 1 thing if 
it actually were more explicit -perhaps something like this:

<xforms:instance id="employees" defaultprototypeid="employee-template">

  <xforms:instance id="employee-template">

this way:
-you dont need all the extra binds and ref's
-your intention is clear
-you cant make errors by inserting "wrong" data (unless you want to by 
using insert option from somewhere else)
-you can still use insert/option if you choose
-maybe its easier for implementors, but I really dont see the difference 
between this and just copying the initial instance data.
-and you can effectively restore the insert before/after functionality 
including the zero case without any option attribute required and 
without any dodgy hacks (ok dodgy hack not reqd for 1.1 anyway, but not 
workable in 1.0se either).

> Given that the whole thing has been made more sensible by the addition 
> in XForms 1.1
> of the origin and context attributes, the persistence of your debate is 
> a little mystifying.
> To wit, you still have not indicated where you think that insert should 
> insert its prototype
> node when the nodeset becomes empty.

I did - I wrote a whole paragraph. I pointed out that the processor 
knows where to find the zero count nodeset so it ought to know where to 
insert them again. I even suggested potential strategies for dealing 
with missing ancestor nodes too. This isnt magic, because I use an 
xforms processor everyday that implements this behaviour just fine.

Received on Wednesday, 8 November 2006 00:38:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:54 UTC