Re: [FutureFeatures] Data-drive switch element

Hi John,

<using> is a little vague, since all controls are 'using' lots of
instance data for all sorts of things. :)

I realise that you are talking more about the functionality, rather
than naming issues, and I agree with your analysis of how it should
behave.

So on the naming question, why not riff on @selected?

I'm wondering if we could do what we've been doing increasingly in
other places , where we replicate an attribute as an element, and then
give it the whole @ref/@value/@bind treatment.

In this case we don't quite have the attribute to replicate, but that
would be an easy first step, and I think it would be quite useful in
it's own right (it's easier to read than the whole "true" thing):

  <switch selected="A">
    <case id="A"> ...</case>
    <case id="B"> ...</case>
    <case id="C"> ...</case>
    <case id="D"> ...</case>
  </switch>

>From here, we replicate the attribute behaviour with an element;
first, using @value:

  <switch>
    <selected value="if(name='John', 'B', 'A')" />
    <case id="A"> ...</case>
    <case id="B"> ...</case>
    <case id="C"> ...</case>
    <case id="D"> ...</case>
  </switch>

then with @ref, as in your example:

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

and of course with @bind:

  <switch>
    <selected bind="bindMyCase" />
    <case id="A"> ...</case>
    <case id="B"> ...</case>
    <case id="C"> ...</case>
    <case id="D"> ...</case>
  </switch>

Other than that, I think the behaviour is pretty much as you describe it.

Regards,

Mark

On Tue, Jun 9, 2009 at 5:48 PM, John Boyer<boyerj@ca.ibm.com> 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
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 9 June 2009 22:21:25 UTC