- From: Aaron Reed <aaronr@us.ibm.com>
- Date: Wed, 24 Oct 2007 11:26:02 -0500
- To: www-forms@w3.org
Man, I don't like this either for the same reason Nick gave...there is
no way for the select to become 'in range' once it is out of range
without another control intervening. I may be using a remembered
instance document that has values that no longer applies to the business
process that I'm trying to modify. For example, inventory flavors or
styles that are no longer available -> there will be no way to get rid
of them. And now I'll have to change my styles for selects to not
reflect out of range-edness so that I don't confuse my users. I'd
rather have a new @selection flag to make it non-destructive. If this
new rule truly applies only to xf:select and not to the other controls,
then that means that we feel that the destructive behavior as a default
is a fine and desirable behavior in EVERY circumstance other than when
xf:select is used. I'd rather the default behavior be predictable and
consistent across all the controls but can be tweaked via an attribute
should the author desire it. Almost every XForms processor has had this
behavior for 3-5 years so I assume that authors and users have found
that 99% of the time this is just dandy. That is what a default
behavior should be -> what works in most cases. And it is hard for me
to get around the fact that the whole idea in the spec is that when a
control changes the value in its bound node, it is just like doing a
setvalue. But in this case it is a control setting a value that it
can't even accurately represent. The value being submitted to the
server, if there is no other control bound to that node, will be a value
that the user has no way to know it is even there. I guess ignorance is
bliss because the poor visually impaired user with an accessible
processor will probably have the value echoed back to him and will be
wondering how that value even got in there and how the heck to get rid
of it. Just seems wrong to me.
As John pointed out, there is nothing in the spec that precludes a
control from doing this. So if this change actually comes to fruition,
I hope the new wording will clearly define when an author can expect
destructive behavior and when he can't.
--Aaron
Erik Bruchez wrote:
>
> Rob,
>
> That's exactly it! And the discussion on the topic we are having in
> todays Forms WG teleconference seems to confirm that we would like
> xforms:copy to behave like this. If everything goes well, we will
> clarify the spec on this as well.
>
> -Erik
>
> Robert Walpole wrote:
>> Erik, John, Aaron,
>>
>> Many thanks for your considered responses.
>>
>> If I understand correctly, if should be possible to implement
>> xforms:copy (and xforms:value for that matter) in such a way that any
>> elements (or text) from another select control already in the target
>> node are not lost when switching controls - and that this would meet
>> the XForms standard (albeit with a warning to be handled by the
>> implementation)
>>
>> I take it that it should also be possible when initiating an XForm
>> pre-populated with data from a database to make these same controls
>> show the appropriate selections based on the nodes that match the
>> items they contain (while ignoring the ones they don't).
>>
>> Assuming I have this straight then I will discuss this with my
>> colleague to see if we can acheive this behaviour in Chiba. If so I
>> think my problem is resolved :-)
>>
>> Thanks again.
>> Rob Walpole
>> Devon Portal Developer
>> Email robert.walpole@devon.gov.uk <mailto:robert.walpole@devon.gov.uk>
>> Web http://www.devonline.gov.uk
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* www-forms-request@w3.org on behalf of Erik Bruchez
>> *Sent:* Wed 24/10/2007 00:24
>> *To:* www-forms@w3.org
>> *Subject:* Re: xforms:copy binding query
>>
>>
>> All,
>>
>> We had a related discussion during one of the last Forms WG calls
>> (John, in case this doesn't ring a bell, this was the rare meeting
>> which you did not attend).
>>
>> This discussion was not directly related to xforms:copy but to
>> xforms:select with xforms:value. Here are the relevant issues for
>> XForms 1.1:
>>
>> http://tinyurl.com/2bgvot
>> http://tinyurl.com/2bf4zv
>>
>> What we decided during that call was that:
>>
>> 1. xforms:select should be non-destructive
>> 2. xforms:select should show an out-of-bound condition
>>
>> I think that the same behavior should apply to xforms:copy. If so, and
>> if I understand your initial issue well, what you want to do should be
>> possible if/once implementations follow this non-destructive logic.
>>
>> -Erik
>>
>> Robert Walpole wrote:
>> > Hi John,
>> >
>> > Thanks for your reply. To avoid any further confusion I will stick to
>> > the real world example of what I am trying to do.
>> >
>> > Basically, I have a target XML node which is a <metadata/> element. On
>> > my form I want to have 2 select controls. One with accessibility
>> options
>> > and one with clientgroup options. Each of these controls is populated
>> > with a different itemset. When the user selects options from the
>> > controls I want the selected items to be placed in the same metadata
>> > target node.
>> >
>> > In other words, if the user selects 2 options from the accessibiliy
>> list
>> > and 2 options from the clientgroup list I want the resulting XML to
>> look
>> > like something like this.
>> >
>> > <metadata>
>> > <accessibility>1</accessibility>
>> > <accessibility>2</accessibility>
>> > <clientgroup>a</clientgroup>
>> > <clientgroup>b</clientgroup>
>> > </metadata>
>> >
>> > Previously I have attempted to handle this using xforms:select1 within
>> > an xforms:repeat and an associated trigger to add additional form
>> > controls and therefore multiple elements of the same name. However the
>> > more complex the data model the more cumbersome this becomes and so
>> I am
>> > trying to use xforms:copy as a more elegant solution. The problem I am
>> > having with this is that the bindings to the target node appear to be
>> > mutually exclusive and in the implementation I am using (Chiba) I am
>> > physically unable to select items from both lists. I can select
>> multiple
>> > items in one list and then as soon as I start selecting items in the
>> > second list the items in the first list are deselected and do not show
>> > in the submitted data.
>> >
>> > I am not sure what you mean by an "out of range event". I assume that
>> > this is something handled by the implementation? In any event a
>> > colleague of mine has added the xforms:copy functionality to Chiba
>> so it
>> > is possible we may be able to modify the behaviour, if appropriate.
>> >
>> > It may be that the only answer is to change my model so that each
>> select
>> > control has a different target node. The problem with this is that
>> I am
>> > working with a existing dataset and this kind of restructuring is not
>> > desirable.
>> >
>> > Thanks again.
>> > Rob Walpole
>> > Devon Portal Developer
>> > Email robert.walpole@devon.gov.uk
>> > Web http://www.devonline.gov.uk
>> >
>> >
>> > -----Original Message-----
>> > From: John Boyer [mailto:boyerj@ca.ibm.com]
>> > Sent: 23 October 2007 15:31
>> > To: Robert Walpole
>> > Cc: Aaron Reed; www-forms@w3.org; www-forms-request@w3.org
>> > Subject: RE: xforms:copy binding query
>> >
>> >
>> >
>> > Hi Robert,
>> >
>> > It's not clear enough from your first message what you are actually
>> > trying to do. This latest post involving use of insert surely seems to
>> > be going in the wrong direction, though, as the point of copy is that
>> > you don't need generalized insertion capabilities.
>> >
>> > I understood that you wanted two different controls to be able to
>> > contribute to a test data result.
>> >
>> > OK, so that means the ref of the two controls points at the same node
>> > "/test/data"
>> >
>> > But what is the itemset nodeset supposed to point at in the two
>> > different controls?
>> >
>> > Are you thinking to have the two itemsets be different?
>> >
>> > If so, I think it is only slightly problematic. However, it should be
>> > possible to make it work, and in particular to do so without use of
>> > insert, but there will be a minor hiccup in the fact that each of the
>> > select controls will receive out of range error events for the
>> subtrees
>> > placed in "/test/data" that do not correspond to items in the union of
>> > the item sets but not the complement of their intersection.
>> >
>> > In other words, if you have an item generated by control S1 but not
>> S2,
>> > and you select that item, the subtree will be copied into the node
>> > referenced by S1, but S2 should then receive an out of range event
>> > because it has no item to match that copied node. But this is a
>> > notification event, which could be ignored or cancelled.
>> >
>> > Finally, perhaps let us know what you really want to do at a higher
>> > level, since a solution other than having two selects with
>> non-identical
>> > item sets might present itself. But if it is exactly what you
>> need, it
>> > should in principle work, modulo the out of range notifications.
>> >
>> > Cheers,
>> > John M. Boyer, Ph.D.
>> > STSM: Lotus Forms Architect and Researcher
>> > Chair, W3C Forms Working Group
>> > Workplace, Portal and Collaboration Software
>> > IBM Victoria Software Lab
>> > E-Mail: boyerj@ca.ibm.com
>> >
>> > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>> >
>> >
>> >
>> >
>> > "Robert Walpole" <robert.walpole@devon.gov.uk>
>> > Sent by: www-forms-request@w3.org
>> > 10/23/2007 04:01 AM To"Aaron Reed" <aaronr@us.ibm.com>,
>> <www-forms@w3.org>
>> > cc
>> > SubjectRE: xforms:copy binding query
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Hi Aaron,
>> >
>> > Thanks for your reply. I understand what you are saying about the
>> > bindings although this does seem a bit of a limitation.
>> >
>> > I am interested in your suggestion of using the xforms-select event
>> but
>> > I am struggling to see how this would work.
>> >
>> > At present I am just trying to get it to work with one select control
>> > and I have something like the following:
>> >
>> > <xforms:model>
>> > <xforms:instance>
>> > <communitygroup>
>> > <data/>
>> > <metadata/>
>> > </communitygroup>
>> > </xforms:instance>
>> > <xforms:bind id="data"
>> nodeset="/communitygroup/data"/>
>> > <xforms:bind id="metadata" nodeset="/communitygroup/metadata"/>
>> > <xforms:instance id="accessibility-instance"
>> > src="accessibility.xml"/>
>> > </xforms:model>
>> >
>> > <xforms:select bind="data">
>> > <xforms:label>Metadata</xforms:label>
>> > <xforms:itemset
>> > nodeset="instance('accessibility-instance')/accesstype">
>> > <xforms:label ref="accessterm"/>
>> > <xforms:copy ref="accessibility"/>
>> > <xforms:action ev:event="xforms-select">
>> > <xforms:insert bind="metadata" at="last()"
>> > position="after"/>
>> > <xforms:setvalue ref="."/>
>> > </xforms:action>
>> > </xforms:itemset>
>> > </xforms:select>
>> >
>> > However this produces some pretty mangled results and I'm not at all
>> > sure what the bindings should really look like in this case.
>> >
>> > Any pointers you (or anyone else) can offer would be much appreciated.
>> >
>> > P.S. accessibility.xml attached in case required.
>> >
>> > Many Thanks
>> > Rob Walpole
>> > Devon Portal Developer
>> > Email robert.walpole@devon.gov.uk
>> > Web http://www.devonline.gov.uk
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: www-forms-request@w3.org
>> > > [mailto:www-forms-request@w3.org] On Behalf Of Aaron Reed
>> > > Sent: 19 October 2007 21:53
>> > > To: www-forms@w3.org
>> > > Subject: Re: xforms:copy binding query
>> > >
>> > >
>> > >
>> > > Hi Rob,
>> > >
>> > > You can certainly bind two selects/select1s to the same node,
>> > > but when
>> > > you select items in a select/select1, it will replace the values
>> > > underneath it. The only way you could mix and mingle them
>> > > are if both
>> > > selects had the same items and you use ctrl+<click> when
>> > > selecting items
>> > > (assuming your process uses a html:select type of control) but then
>> > > there isn't much reason to have both. You could always try
>> > > to manage it
>> > > yourself with binding the two selects to different nodes and then
>> > > handling the xforms-select and xforms-deselect events and
>> > > inserting/deleting the nodes under the 'real' target node yourself.
>> > >
>> > > --Aaron
>> > >
>> > > Robert Walpole wrote:
>> > > > Hi,
>> > > >
>> > > > I am seeking some clarification about how the XForms copy element
>> > > > (http://www.w3.org/TR/2007/WD-xforms11-20070222/#ui-adv-copy)
>> should
>> > > > work.
>> > > >
>> > > > My question is whether it should be possible to use
>> xforms:copy on
>> > > > different xforms:select controls to copy different element
>> > > nodes into
>> > > > the same target node?
>> > > >
>> > > > For example, say I want to have 2 select controls that use use
>> > > > xforms:copy to populate the data node in the following...
>> > > >
>> > > > <test>
>> > > > <data/>
>> > > > </test>
>> > > >
>> > > > In this case I would bind both of my select controls to the
>> > > data nodeset
>> > > > and by selecting two values from both controls I would hope to
>> get
>> > > > something like the following result...
>> > > >
>> > > > <test>
>> > > > <data>
>> > > > <abc>123</abc>
>> > > > <abc>456</abc>
>> > > > <def>321</def>
>> > > > <def>654</def>
>> > > > </data>
>> > > > </test>
>> > > >
>> > > > Is this allowable? It may be that I cannot bind two
>> > > different controls
>> > > > to the same target node. Any clarification of this would be much
>> > > > appreciated.
>> > > >
>> > > > Many Thanks
>> > > > Rob Walpole
>> > > > Devon Portal Developer
>> > > > Email robert.walpole@devon.gov.uk
>> > > > Web http://www.devonline.gov.uk
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
>
Received on Wednesday, 24 October 2007 16:45:13 UTC