Re: xforms:copy binding query

 > 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.

Well you can also use actions to clear or adjust the values.

One could argue that document migration is a valid use case, but in
general such migration is likely to entail much more than changing
values in selects and you may have to resort to something like an XSLT
transform to migrate your documents anyway.

So I understand your point, but there are use cases for the
destructive approach as well as the non-destructive approach. At some
point we have to make a decision, and so far the WG thinks that there
are not many disadvantages to follow the non-destructive approach.

At least by going the non-destructive way, you leave open the door to
handling the destructive use cases, albeit with a little more work,
while if you go the other way around, you can't: the control will
destroy your data, and you can't implement use cases such as having
multiple selection controls bound to the same node. For example, a use
case given recently:

   <xforms:select ref="my-data" appearance="full">
     <xforms:label/>
     <xforms:item>
       <xforms:label>Blue</xforms:label>
       <xforms:value>blue</xforms:value>
     </xforms:item>
   </xforms:select>

   and somewhere else in the page:

   <xforms:select ref="my-data" appearance="full">
     <xforms:label/>
     <xforms:item>
       <xforms:label>Red</xforms:label>
       <xforms:value>red</xforms:value>
     </xforms:item>
   </xforms:select>

 > 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 can't see how other controls cannot be destructive. xforms:select is
the only control dealing with lists of values, which makes being
non-destructive a possible behavior for this control only.

 > I assume that authors and users have found that 99% of the time this
 > is just dandy.

That sounds like a, uh, wild assumption to me ;-)

 > But in this case it is a control setting a value that it can't even
 > accurately represent.

XForms had since the beginning the notion that a control could be out
of range. xforms:range is the best example, but xforms:select had this
feature since the beginning as well.

Also, XForms has a quite strong separation between the data model and
the controls, and this separation has even increased in XForms 1.1,
witness the work done to separate xforms:insert/xforms:delete from
xforms:repeat, for example. So it is probably not unacceptable to
think that there can be a disconnect between data in the data model
and what controls can show.

 > 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.

Well, one could argue that the validity of the document should be
handled via a bind constraint or schema definition, not by assuming the
control sets the right value. You will have the same problem with an
out of range xforms:range.

And you can tell the user, since the control is supposed to indicate
the out of range condition.

 > 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.

It sure will ;-)

(The above is just my opinion, not that of the Forms Working Group.)

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 24 October 2007 23:46:47 UTC