- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Fri, 1 Feb 2008 17:00:12 -0800
- To: "public-forms (new)" <public-forms@w3.org>
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/
Received on Saturday, 2 February 2008 01:00:27 UTC