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

John & all,

If an attribute is not acceptable, a simple nested <using/> element
would be a reasonable way to go.

Still, 1.2 is meant to be about simplification and ease of authoring,
and I think that attributes are easier to write than nested
elements. And in several places in XForms 1.1, we have nested elements
which can be used in place of attributes, e.g. the <resource/>
element.

To answer your example of <upload/>, maybe what we should do for 1.2
is go the other way around and allow to write:

   <xforms:upload ref="foo" filename="bar" .../>

In 1.1 we have introduced nested elements mainly to allow specifying
values dynamically, but I still think that a better way to go about
this is introcucing Attribute Value Templates.

The conclusion of the above is that I think that there is nothing
wrong with using attributes. But I know that this is often just a
matter of personal preference in the design of data formats and
languages, rather than a very rational decision.

But you are right to say that it's mainly the rest of the proposal
that I don't like. I will repeat myself, but it seems like the
requirement of being able to serialize <switch/> status is one that
can be satisfied with simple constructs, and therefore I don't think
we should end up with a huge-looking feature in response.

At the moment we have container controls, <group/>, <case/>, and
<repeat/>, and those can recursively contain any possible control
without limitations. The existence of these elements is perfectly
justified. I don't feel that this is the case with the newly proposed
<using/> element, especially since it looks like it cannot contain
arbitrary nested controls.

 > 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.

I agree that this is not ideal and that a binding would be better, but
you could consider that a bug in the form. Not everybody needs to
serialize case state, and whoever wants to do so can take the
necessary care to implement it safely. I am only proposing this
because I don't see the requirement of serializing case state as a
huge one, but it may be just a personal bias ;-)

-Erik


On Feb 3, 2008, at 6:57 PM, John Boyer wrote:

>
> 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/
>
>
>

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

Received on Monday, 4 February 2008 06:27:27 UTC