Requirement : We need an easy authoring method for tracking the selected case of a switch using a node of data.
It is possible to use an xforms-ready handler and a pile of xforms-select handlers to track the selected case of a switch, except it is not guaranteed to work correctly. For example, if a setvalue or UI binding modifies the data node, there is no way to set a listener for changes to a data node, so the data and the switch case will be out of synch, a difference that is obvious across a save/reload. Therefore, the requirement cannot be met with correctness with XForms today.
To achieve data model drive switching, form authors are therefore strongly inhibited from using switch. Since that is the XForms container control for UI switching, it is a language flaw that must be fixed.
The working group discussed the issue and the following is the result of that initial discussion:
- a new first optional child element of switch called "selected", which takes single-node UI binding attributes.
- when "selected" is present, the bound data node selects the first case on startup if the bound data node exists and its content matches a case.
- the usual edge cases are to be worked out in the strawman proposal for spec-ready text
- there was expressed desire not to mix the ID space from the UI (the cases) with the data model; it was suggested that "case" element could have a "value" child element, much like the item element in a select/select1 uses both label and value. I understood this to mean that perhaps the "selected" mechanism would only work with value-bearing cases, not ID bearing cases.
- The toggle action would continue to be able to toggle cases, except that the content of the case attribute would be used to match case values in a switch/selected construct.
- The toggle would change the case, which would cause the "selected" UI binding to push the new selection into data using a setvalue action (same as a normal UI binding).
- Because "selected" has a UI binding, any change of the bound data node would cause a switch case selection.
Here is a simple markup example based on the ideas expressed so far:
<select1 ref="/path/to/cart/@phase">
<label>Stage: </label>
<item>
<label>Order</label>
<value>order</value>
</item>
<item>
<label>Ship</label>
<value>ship</value>
</item>
<item>
<label>Pay</label>
<value>pay</value>
</item>
</select1>
<switch ref="/path/to/cart" selected="@phase">
<!-- child element alternative: <selected ref="@phase"/> -->
<case id="order">
<label>Order Information</label>
<group ref="orderDetails">
<input ref="product">
<label>Which of our fine edges do you need?</label>
</input>
<range ref="quantity">
<label>How many of our fine widgets do you need?</label>
</range>
</group>
</case>
<case id="ship">
<label>Shipping Information</label>
<group ref="shippingDetails">
<input ref="name"><label>Name</label></input>
<input ref="address"><label>Address</label></input>
<input ref="zone"><label>Zone</label></input>
<input ref="sector"><label>Sector</label></input>
</group>
</case>
<case id="pay">
<label>Payment Information</label>
<group ref="paymentDetails">
<input ref="card"><label>Card Number</label></input>
<input ref="date"><label>Expiration Date</label></input>
<input ref="cvv">
<label>CVV Code</label>
<hint>A three-digit number they put on the back of the card to make 99.9% sure you really have the card and didn't steal the data from someone whom was previously told that number.</hint>
</input>
</group>
</case>
</switch>
The working group also considered the fact that the UI control that drives the case selection is separate from the switch, so the relationship between the two controls is not well-established by the declared UI.
The working group considered the following:
- Let "selected" have a content model same as group (optionally empty).
- you could then put a select1 or input inside "selected" element and it could directly control and reflect the switch's current case
However, there has been some pushback on this part. Also, it seems to go beyond dealing with the immediate requirement. Moreover, in XForms 2.0 there is a requirement for repeat to do a better job of being able to relate other controls that are working with the repeat to accomplish something. Perhaps the same mechanism would be used for switch.
There was also some discussion about the extensibility of this feature to switches that can select multiple cases at the same time. It was agreed that a multi-selection switch might be done with a separate control, but more importantly that it was an XForms 2.0 feature. However, this formulation of "selected" does not conflict with eventually being able to offer multi-case switches.