- 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