Switch and "using", was Re: Pretty cool talk today; how about switch *inside* select1/select

Hi Erik,

The use of an attribute like @using was what I originally proposed, only I 
called it @case.

The working group felt this solution was inferior, and I agree with them, 
because the attribute is acting like a UI binding but it is not a UI 
binding attribute.  Leigh raised the very interesting and correct point 
that we have faced this issue before with the upload control, which has 
filename and mediatype child elements that can take a UI binding.  I 
believe the child element named "using" is the superior practice. 
Moreover, it seems the bulk of your objection is not with the child 
element, but with allowing the child element to contain form controls.

The disadvantage of letting "using" contain controls is that we have 
another group-like/case-like element to specify the relevance inheritance 
for.  Maybe it is too big a leap for XForms 1.2, as the "using" element 
containing ref but no children does at least get at the main requirement I 
originally raised.

The advantage of putting form controls inside "using" was that it allows 
the form author to actually express the relationship between a switch and 
another control that may be controlling the switch's behavior by 
manipulating the same data node.  I like it, but I could live without it. 

It is interesting to note that we have a similar requirement for repeat, 
to come up with a better authoring capability that declaratively binds 
together all the elements that contribute to a "table".  Interesting 
because the triage done so far has landed that requirement into XForms 
2.0.  It may be a good idea to defer the notion of child content inside 
"using" because we may come up with a more general mechanism that could 
work for both switch and repeat.

What does everyone think about just doing this part for now:

<switch>
   <using ref="some/node" />
   <case>...</case>
   <case>...</case>
   <case>...</case>
</switch>

Finally, before closing, I should point out that your final claim that 
this requirement could be met with just an xforms-select handler and an 
xforms-ready handler is not correct.  The problem is that someone can 
write a setvalue or a UI binding that, at any time, modifies the data node 
that supposedly reflects the switch case selection.  However, there is *no 
way* to listen for data changes to that node, so it is quite possible for 
the data node to get out of synch and not reflect the selected case. Then, 
if you save and reload, the case selected by the xforms-ready handler does 
not reflect the last case shown to the user before the save/reload.  So, 
it is quite hard to write a switch case tracker that works poorly, and 
impossible to write one that is guaranteed to be correct.  This is why we 
need the UI binding offered by the "using" element.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
02/01/2008 08:00 PM

To
"public-forms (new)" <public-forms@w3.org>
cc

Subject
Re: Pretty cool talk today; how about switch *inside* select1/select







Argh. The nesting of <select1> within <switch> in particular is 
Frankensteinesque, really. I would much prefer something like this then:

<switch ref="/path/to/cart" *using="@phase"*>
   <case ref="quantity">
     <label>Place your order</label>
     *<value>order</value>*
     <range>
       <label>How many of our fine widgets do you need?</label>
     </range>
   </case>
   <case ref="shipping">
     <label>Shipping choices</label>
     <input ref="name"><label>Name</label></input>
     <input ref="address"><label>Address</label></input>
     <input ref="zone"><label>Zone</label></input>
     <input ref="sector"><label>Sector</label></input>
   </case>
   <case ref="credit">
      <label>Pay, Pay, Pay</label>
      <input ref="card"><label>Card Number</label></input>
      <input ref="date"><label>Expiration Date</label></input>
      <input ref="cvv">
        <label>CVV Code</label>
                   <hint>A three-digit number they put on the back of the 
card to
make 99.9% sure you really have the card
              and didn't steal the data from someone whom was previously
told that number.</hint>
      </input>
   </case>
</switch>

May I remind us that how this started was a requirement to save/ 
restore a switch state. As shown above, a single attribute on <switch> 
and a new <value> child element in <case> would do the job.

I will even argue that my proposal for adding context information 
about the selected case in the xforms-select event is enough to 
satisfy the requirement and should seriously be considered:

<switch ref="/path/to/cart">
   <xf:setvalue ev:event="xforms-select" ref="@phase" 
value="event('case')"/>
   ...

<xf:toggle ev:event="xforms-ready" case="{path/to/cart/@phase}"/>

Problem solved.

Please let's not create a monstrosity.

-Erik

On Feb 1, 2008, at 4:08 PM, Klotz, Leigh wrote:

>
> Raman,
> John Boyer has an action to write up the morning's discussion in
> spec-ready text, but I'm writing an explanation here.
> There's about a dozen bullet points followed by a markup example.
>
> - a new first optional child element of switch called (for now) 
> "using,"
> which takes single-node binding attributes and has a content model 
> same
> as group (optionally empty).
> - a new pair of label and value child elements for switch/case that 
> let
> it use values other than ID for case control; these are copied from
> select.
> - optionally using explicit values reduces model/ui mixing by 
> keeping UI
> element IDs out of the instance data.
> - the new element "using" specifies location path of the current state
> of the switch; you can toggle the switch by changing that node, and 
> vice
> versa.
> - you can put a select1 or input inside "using" and it can directly
> control and reflect the switch's current case
> - if we decide that @ref='.' is the default on controls (can't 
> remember)
> then it makes that a little simpler.
> - I think we decided to allow ref on case same as ref on switch to set
> context but I'm not sure.
> - toggle still works; the model reflects the current value at the node
> specified by using/@ref
> - someday we may make a switchMany that has the same content model but
> its using/@ref binds to a list and allows multiple cases to be 
> active at
> the same time
> - a author would mark it up as switchMany/using/select instead of
> switch/using/select1.
> - perhaps we should have named switch "switch1" instead ;-)
> - the name "using" is up for grabs at the moment but it's in for 
> XForms
> 1.2
> - switchMany is likely a 2.0 rather than a 1.2 construct
>
> Here's an example of a shopping cart wizard with three phases.  CSS or
> XBL governs how the switch and the select1 and their associated labels
> and and control parts are presented.  This could easily represent a
> tabbed view page on a desktop visual browser and then provide voice as
> well, as the whole thing is done with existing abstract XForms 
> controls
> and only one new element name, which itself is just a container.  I
> don't know that this 100% right but it gives the idea.
>
> <switch ref="/path/to/cart">
>  <using ref="@phase">
>    <select1>
>      <label>Stage: </lavel>
>      <item>
>       <label>Order</label>
>       <value>order</value>
>      </item>
>      <item>
>       <label>Ship</label>
>       <value>ship</value>
>      </item>
>      <item>
>       <label>Pay</label>
>       <value>pay</value>
>    </select1>
>   </using>
>   <case ref="quantity">
>     <label>Place your order</label>
>     <value>order</value>
>     <range>
>       <label>How many of our fine widgets do you need?</label>
>     </range>
>   </case>
>   <case ref="shipping">
>     <label>Shipping choices</label>
>     <input ref="name"><label>Name</label></input>
>     <input ref="address"><label>Address</label></input>
>     <input ref="zone"><label>Zone</label></input>
>     <input ref="sector"><label>Sector</label></input>
>   </case>
>   <case ref="credit">
>      <label>Pay, Pay, Pay</label>
>      <input ref="card"><label>Card Number</label></input>
>      <input ref="date"><label>Expiration Date</label></input>
>      <input ref="cvv">
>        <label>CVV Code</label>
>                  <hint>A three-digit number they put on the back of the 
card to
> make 99.9% sure you really have the card
>              and didn't steal the data from someone whom was 
> previously
> told that number.</hint>
>      </input>
>   </case>
> </switch>
>
> That's it.
>
> Leigh.
>
> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of T.V Raman
> Sent: Friday, February 01, 2008 2:52 PM
> To: ebruchez@orbeon.com
> Cc: public-forms@w3.org
> Subject: Re: Pretty cool talk today; how about switch *inside*
> select1/select
>
>
> Did you see the <switch><caseset>...</caseset></switch>
> design I sent out?
>
> This would better reflect how we upgraded the original statically
> oriented select1 that was inspired by HTML to one that was
> capable of getting a dynamic list of choices from the model.
>
> ...
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/