Re: [FutureFeatures] Data-drive switch element

Hi Mark,

I didn't like the name "using" myself either, though it was better than 
other options that came up at the time.

However, I think the whole idea of using a child element for this is 
problematic, too, in part because it creates the temptation to use the 
value attribute. The value attribute can't implement a bidirectional 
single node binding, so if someone does use a toggle on a switch that 
contains <selected value="such and such"/>, then what should the behavior 
be?

I feel the cleanest solution here is to use an xpath-bearing attribute on 
the switch itself.  Other elements (e.g. submission) have xpath attributes 
beyond the single node binding.

The attribute itself could certainly be called "selected".  I like that 
suggestion the best so far, but it would be nice if it were an XPath.

Something like this:

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

Other good names would be "caseref" or perhaps "state" (as in what state 
is the switch in?)

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





From:
Mark Birbeck <mark.birbeck@webbackplane.com>
To:
John Boyer/CanWest/IBM@IBMCA
Cc:
public-forms@w3.org
Date:
06/09/2009 03:21 PM
Subject:
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)