Re: Problems with xf:copy and xf:delete

I still say this is not consistent with the rest of the spec.  You are 
saying that a select1 with a value WILL write over the all of the values 
(text nodes) of the bound node but that a select1 with a xf:copy WON'T 
write over all of the values (element nodes) in the bound node.  So a 
select1 with a value CAN become 'in range' if extraneous values are 
listed and if the user selects an item from the list but a select1 with 
copy can NEVER become 'in range' if extraneous values are listed and if 
the user selects an item from the list.  Leaving it, as far as I can 
tell, the only type of single value, single bound control with this 
behavior.  In my opinion it shouldn't matter what type of value is 
getting selected, a select1 should always behave the same.  An XML 
element inside a bound node can be left over, out of range junk just as 
well as an out of range text node and there should be a means to get rid 
of it w/o script.

I have less of a problem with xf:select behaving as you now describe 
since it will be equally consistent whether the data values are text 
nodes (xf:select using xf:value) or elements (xf:select using xf:copy) 
and that in either case an 'out of range' value can never be brought 'in 
range' (which I don't necessarily like, but it is a consistent logic 
across the widget).

Philip, please open a bug on our behavior and attach a testcase. 
Hopefully someone will have time to get to it.

Thanks for listening,
--Aaron

Leigh L. Klotz, Jr. wrote:
> In
> http://lists.w3.org/Archives/Public/public-forms/2008Dec/0003.html
> I was assigned action Action 2008-12-3.2
> 
> * Problem with xf:copy and xf:delete
> http://lists.w3.org/Archives/Public/www-forms/2008Nov/0006.html
> - analyst needed
> 
> As Phulip Fennel points out, the spec here says:
> http://www.w3.org/TR/xforms11/#ui-selection-commonelems-copy
> 
> The target node, selected by the binding attributes on the list form
> control, must be an element node...
> 
> The element node associated with the item, selected by the binding
> attributes on copy, is deep copied as a child of the target node as if an
> insert action had occurred.
> 
> For de-select it says:
> The child element node associated with the item, selected by the binding
> attributes on copy, is deleted as if a delete action had occurred.
> 
> Philip Fennell seemed to think existing content would be left alone, and
> only the contributions of the select itself altered.  Aaron Reed has
> implemented the notion that the select controls the entire contents of the
> target node.
> 
> The WG consensus is that Philip is correct; the document text was
> specifically written to make sure that select leaves alone any existing
> content.   select/itemset/value should so the same as well, so if Mozilla
> XForms doesn't do that, it also should.
> 
> Leigh.
> 
> 
>

Received on Wednesday, 11 February 2009 02:27:33 UTC