RE: [FutureFeatures] Data-drive switch element

All,

Lately I've been having a closer look at using XBL together with XForms to implement reusable custom controls. The more I look at it the more I get the feeling that this is a nice way to support reusable custom controls using a mechanism that can be supported by multiple XForms implementations. As Erik mentions "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". I completely agree with him on this, and if the group finds this road also interesting, we can maybe decide to write a WG note or even an XForms module about How to use XBL in XForms to define reusable components. (I know I said that I think we haven't enough resources to modularize the complete XForms spec, but writing a separate module for some of the new feature is a good start if you ask me)

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
Nick_Van_den_Bleeken@inventivegroup.com
http://www.inventivegroup.com

> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of Erik Bruchez
> Sent: dinsdag 9 juni 2009 23:47
> To: Forms WG
> Subject: Re: [FutureFeatures] Data-drive switch element
>
> 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/
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--

Received on Wednesday, 10 June 2009 07:01:34 UTC