W3C home > Mailing lists > Public > public-forms@w3.org > June 2009

Re: [FutureFeatures] Data-drive switch element

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 9 Jun 2009 14:47:08 -0700
Message-Id: <4CB5B660-3DEA-4563-B11B-4BB7DA9E05D4@orbeon.com>
To: Forms WG <public-forms@w3.org>
All,

John's mention of the data-driven switch reminds me that not long ago,  
I used XBL to implement a simple (maybe naive) version of such a  
control. It took just a few lines:

<xbl:xbl>
     <xbl:binding id="bound-switch-component" element="fr|databound- 
switch">
         <xbl:template>

             <xforms:switch xbl:attr="ref" id="my-switch">
                 <!-- Toggle visible case upon initial display or  
value change -->
                 <!-- Here we assume that the case id matches the node  
value -->
                 <xforms:toggle ev:event="xforms-value-changed xforms- 
enabled" ev:target="my-switch" case="{.}"/>

                 <!-- Include nested cases -->
                 <xbl:content includes="fr|databound-switch > xforms| 
case"/>
             </xforms:switch>
         </xbl:template>
     </xbl:binding>
</xbl:xbl>

You use it as follows:

<fr:databound-switch ref=".">
     <xforms:case id="case1">
         Case 1
     </xforms:case>
     <xforms:case id="case2">
         Case 2
     </xforms:case>
</fr:databound-switch>

This implementation has at least one drawback, which is that the  
switch first defaults to showing the first case, and on xforms-enabled  
only switch to the selected case, which might not satisfy John's  
specific need.

But it is a data-driven switch and the point here is mainly to  
illustrate the power of a decent extension mechanism for XForms, in  
this case XBL. There is real potential for building extremely powerful  
controls on top of a fairly simple XForms core.

Note that there are lots of interesting questions arising from the mix  
of XBL and XForms (in particular issues of scoping and resource  
resolution and event handling), and we should probably give some space  
to the topic on one of the upcoming calls. Also, whatever extension  
mechanism we work on for XForms Next, if we do (and I hope we do),  
these questions will arise. The group had a taste of this kind of  
issues when the topic of external model sourcing was briefly tackled a  
couple of weeks ago.

-Erik

On Jun 9, 2009, at 9:48 AM, John Boyer wrote:

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

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Tuesday, 9 June 2009 21:47:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:51 UTC