[FutureFeatures] Data-drive switch element

In and amongst the modularization efforts, we also made progress on 
discussing some new features for future versions of XForms.
Some of those threads of discussion are coming back up now that we are 
getting through the backlog of work that was needed to finish XForms 1.1.

One that I have an action item to work on is a data-driven switch.
Although one can use group relevance to achieve the effect, it is not very 
directly expressive because nothing in the markup really declares the 
relationship among the groups of controls.
The switch with case elements declaratively binds together a collection of 
groups of controls (cases) and directly expresses that they are working 
together toward a single purpose.

The limitation right now is that it is very hard to store the state of a 
switch in data so that it can be persisted across application interaction 
sessions.
One can store selected case on each xforms-select event and one can push 
the selected case to the UI on xforms-ready, but this is a lot of effort 
compared to a directly expressed two-binding to a node of data that 
selects the switch case.  Furthermore, the capturing of these events is 
insufficient because it is non-reponsive to changes made to the underlying 
data node where the selected case is stored.

In the past, I advocated for this feature as it was really the main 
shortcoming I could find in the application of XForms to documents like 
ODF and to XForms applications that also involve digital signatures, where 
it might be important to know which switch case is being presented to the 
user.

Today, though, I hit yet another customer, this one very large, where the 
efficiency of their forms has been substantially impacted by the use of 
multiple toggle actions during xforms-ready. 

The forms at play are fairly large, and use xforms-ready "works", but it 
is too slow in practice.  The problem is that the run-time objects for the 
UI of the default case of a dozen switches are created during default 
xforms-model-construct-done default processing, and then the xforms-ready 
happens.  This toggles all the switches, which destroys the first set of 
cases and creates the second set of cases according to the settings in 
data.

Our product has an extension feature for data-driven switches using a 
foreign-namespaced attribute.  Using a data-driven switch, the form load 
time was reduced from 22 seconds to 4 seconds, or better than a 5-fold 
increase of performance.

At the time the action item was assigned to me, we had decided to use a 
child element of switch called "using" with a single node binding, like 
this:

<switch>
  <using ref="my/case"/>
  <case id="A"> ...</case>
  <case id="B"> ...</case>
  <case id="C"> ...</case>
  <case id="D"> ...</case>
</switch>

Whenever the node my/case is changed, the switch will change cases, and if 
a toggle changes the switch case, then the data value is changed by an 
implicit setvalue action.
There are edge cases to consider, of course, like what to do if my/node is 
assigned a value that doesn't match any of the case ID's, but these are 
similar to edges that we already have to handle for switch, and I'm not 
trying to write the spec in this email.

Rather, I'm just trying to renew awareness of this particular technical 
issue, in part for its own sake, and in part to point out how it is 
related to some of our emerging themes for the future:
1) incremental refinement that eases authoring or optimizes performance of 
a specific use case or pattern
2) better alignment with XForms in documents
3) better alignment with XForms across interaction sessions of a larger 
application 

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
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
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw