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.

Erik Bruchez writes:
 > 
 > I understand the rationale behind John's proposal, but I do share some  
 > of Uli's feelings. To me, <switch> within <select1> feels a little,  
 > uh, bastardized. And I don't like the fact that both the <select1>  
 > element and the nested <switch> element could carry a @ref attribute.
 > 
 > Also, if we go down that path, you start wondering what other controls  
 > you could nest within a <select1>.
 > 
 > Maybe something better would be to allow <item> to act like a <group>?  
 > But even that looks funny to me.
 > 
 > Maybe we are better off with something like this:
 > 
 > 1. Adding context information to xforms-select so that you can  
 > manually store the selected case to your instance.
 > 2. Upon xforms-ready you can restore cases using <toggle>.
 > 
 > This would look clean to me in the absence of a more convincing  
 > alternative.
 > 
 > -Erik
 > 
 > On Feb 1, 2008, at 5:37 AM, John Boyer wrote:
 > 
 > > Hi Uli,
 > >
 > > It is far less quirky than putting arbitrary markup in a label,  
 > > help, hint
 > > or alert element, or using a message as a dialog.  I believe that  
 > > those
 > > bits of quirkiness cross the line.
 > >
 > > But people are saying that they want select/select1 to select things  
 > > that
 > > get put in the data model, and I'm saying that switch is the control
 > > designed to contain UI cases.  Now we have a need to store the  
 > > selected
 > > case (or cases) in the data model.  That calls for a select/select1  
 > > and a
 > > switch at the same time.  It is interesting to note that right now I  
 > > can
 > > actually use the two together, as long as I don't put one inside the
 > > other?!?  Seems a very odd restriction to me.  Also worth noting  
 > > that case
 > > receives the same xforms-select/xforms-deselect events that an item  
 > > does.
 > > Seems we're already part way down the path.  This is a very natural  
 > > fit to
 > > me.
 > >
 > > Regarding your point about setvalue being enough to switch the  
 > > cases, yes
 > > I absolutely agree.  That's how my implementation works today.  For
 > > documents (like ODF and XFDL), we need to be able to save the state  
 > > of the
 > > switch.  At the time, I saw this as an extension feature of switch,  
 > > not as
 > > an opportunity to put switch inside select/select1.  I like the latter
 > > better now that we've had the discussion because the UI binding of the
 > > select/select1 actually is a UI binding, rather than having an  
 > > attribute
 > > of switch *act* like a UI binding.  But otherwise, yes you could  
 > > toggle a
 > > switch with toggle, but you could also change the data node with  
 > > setvalue,
 > > and both switch to a new case.
 > >
 > > To your point about repeat index, note that the new language in the  
 > > repeat
 > > section talks about handling the repeat index as if it were implicit
 > > instance data.  We could come up with a way to make it explicit.  It's
 > > worth looking at further, but to be honest I have not been pushing  
 > > as much
 > > for storing the repeat index because I haven't yet come across a  
 > > really
 > > good reason to store that piece of information.  Users just don't  
 > > expect
 > > you to remember which row of a table you were on when the document is
 > > saved and closed.  This is because you can still see the whole  
 > > table.  But
 > > with switch, the demand is much more prevalent because you cannot see
 > > anything but the selected case.
 > >
 > > Finally, regarding the general idea of being able to store data on  
 > > behalf
 > > of controls, I agree we could use that, and in fact it is on the  
 > > list of
 > > XForms 2.0 features.  I just don't want to wait until XForms 2.0 to  
 > > fix
 > > this problem with switch because it is fairly unique to switch.  The
 > > problem is that our language is actively encouraging through its  
 > > current
 > > design the use of something other than a switch to do UI switching,  
 > > and we
 > > need to find *some way* to fix that.  Right now, people are advocating
 > > using a pile of groups with model relevance as a way of switching  
 > > based on
 > > data.  But this is a horrible idea because you have a pile of groups  
 > > that
 > > nobody can tell are working together without deep analysis of the
 > > document.  We have a declarative mechanism for getting a pile of  
 > > groups to
 > > work together, and it's called switch, but there is really no  
 > > effective
 > > way of letting data drive the switching.
 > >
 > > Finally, finally, please don't read anything into how this note  
 > > might be
 > > worded, I realize it might sound terse, but I don't mean it.  I'm just
 > > typing as fast as I can to get this out before the virtual day call  
 > > starts
 > > (I still have to go to my worksite and find my room).
 > >
 > > 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
 > >
 > >
 > >
 > >
 > >
 > > Ulrich Nicolas Lissé <unl@dreamlab.net>
 > > Sent by: public-forms-request@w3.org
 > > 02/01/2008 08:01 AM
 > >
 > > To
 > > John Boyer/CanWest/IBM@IBMCA
 > > cc
 > > "Forms WG (new)" <public-forms@w3.org>
 > > Subject
 > > Re: Pretty cool talk today; how about switch *inside* select1/select
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 > > All,
 > >
 > > I followed the discussion yesterday with great pleasure. However, I  
 > > have
 > > strong feelings against mixing switch/case and select1/select, both in
 > > syntax and semantics. Especially I don't like the idea of making  
 > > switch
 > > a child of select1 or select. What's select1/select supposed to be  
 > > then?
 > > A core control capable of holding a container control? A hybrid? This
 > > seems quirky to me.
 > >
 > > First of all, we should clearly separate the issues we're trying to  
 > > solve:
 > >
 > > - keeping UI state during serialization
 > > - multi-case switches
 > > - variable number of cases
 > >
 > > I see demand for all of these use cases.
 > >
 > > * Keeping UI state during serialization
 > >
 > > As Mark pointed out in the discussion, we should have a general
 > > mechanism to keep UI state rather than having a switch/case-specific
 > > solution. We need to serialize repeat indexes too.
 > >
 > > While I'm perfectly comfortable with an xforms-ready handler restoring
 > > repeat indexes and case selections (provided that we add a case()
 > > function), I do understand the need for another solution in terms of
 > > digital signatures.
 > >
 > > Adding @case to switch seems useful, but only for /reading/ state.  
 > > Like
 > > Mark I have objections against making a container like switch
 > > essentially an input control. To toggle a case of such a switch a
 > > setvalue should be enough.
 > >
 > > For repeats, we could make @startindex an XPath expression then.
 > >
 > > * Multi-case switches
 > >
 > > I don't know if really want a switch with multiple cases being
 > > /selected/. In this case I wouldn't call it a switch anymore, because
 > > that's misleading. The common conception of a switch does not allow
 > > multiple cases. I would rather go with group/@ref=self:node()[...] for
 > > that use case.
 > >
 > > But having multiple cases /visible/ seems to be achievable: Like  
 > > Raman I
 > > regard case as syntactic sugar, just mimicking a group. However, we
 > > still have the issue with a non-selected case being handled the same
 > > like a non-relevant group. While a non-selected case must not be  
 > > visible
 > > per spec, a non-relevant group might be visible (depending on  
 > > rendering
 > > of non-relevance). So, if we solve this issue by relaxing the
 > > non-visibility requirement of non-selected cases, we could have
 > > non-selected case visible.
 > >
 > > * Variable number of cases
 > >
 > > I like Raman's proposal of <caseset>, even if the element name might  
 > > not
 > > be - uhm, well - capable of winning a majority. This would be
 > > straight-forward, the processing model and the in-scope evaluation
 > > context language could be adopted from itemset.
 > >
 > > Just my 0.02[$|Ì]
 > >
 > > Regards,
 > > Uli.
 > >
 > > John Boyer wrote:
 > >>
 > >> I'm sure you are all pretty much the same on this point, but I found
 > >> today's telecon pretty cool and stimulating.
 > >>
 > >> For my own part I had previously recognized the similarity between
 > >> <switch ... @case> and <select1 ref...>, but it was something I
 > >> previously put into the "coincidental parallelism" bucket because I
 > >> select1 is a basic form control, not a container control.
 > >>
 > >> That being said, I have really never liked <switch ref="..." @case>  
 > >> as a
 > >
 > >> design because @case is essentially acting like a UI binding.
 > >>
 > >> After today's discussion, I sat trying to rationalize in my mind  
 > >> all the
 > >
 > >> view points, and an idea came up that seems pretty cool to me, so I  
 > >> hope
 > >
 > >> you like it too.
 > >>
 > >> Wouldn't it be cool to put <switch> inside of <select1>?  It would  
 > >> look
 > >> like this:
 > >>
 > >> <select1 ref="payment/methods/@method">
 > >>   <label>Choose your payment method:</label>
 > >>   <switch ref="..">
 > >>       <case id="VISA"> <label>Visa</label> ...
 > >>       <case id="MC"> <label>Mastercard</label> ...
 > >>       <case id="COD"> <label>Cash on delivery</label> ...
 > >>   </switch>
 > >> </select1>
 > >>
 > >> There seem to be several benefits
 > >>
 > >> 1) We would have an actual UI binding from the select1 as the way to
 > >> automatically drive the switch case selection
 > >> 2) We would retain switch as the *container* form control for UI
 > > selection.
 > >> 3) The switch ref is still able to reset the context relative to  
 > >> where
 > >> the data is stored.
 > >> 4) We haven't yet even added any new vocabulary; just a new possible
 > >> content model for select1
 > >> 5) We seem to get multicase switches seemingly for free by using  
 > >> select
 > >> rather than select1, again with no new vocabulary
 > >>
 > >> A <toggle case="X"/> would make the selection in the switch, which  
 > >> would
 > >
 > >> in turn notify the select1 of the value change needed for its UI  
 > >> binding
 > >> Setting the value of the node referenced by the select1 would push a
 > >> case choice from the select1 to the contained switch automatically
 > >>
 > >> The only issue to settle, then, would be whether it is worth the  
 > >> effort
 > >> to use a value space, rather than an id space, for case selection.   
 > >> We
 > >> discussed doing this via a value attribute, though I had thought for
 > >> consistency with the <item> element that it should be a child  
 > >> element of
 > >
 > >> case instead.  Regardless of that choice, the above makes it clearer
 > >> that having the value space method for selecting cases would be
 > >> preferable.  So it might look like this instead:
 > >>
 > >> <select1 ref="payment/methods/@method">
 > >>   <label>Choose your payment method:</label>
 > >>   <switch ref="..">
 > >>       <case>
 > >>            <label>Visa</label>
 > >>            <value>VISA</value>
 > >>            ...
 > >>       </case>
 > >>       <case>
 > >>            <label>Mastercard</label>
 > >>            <value>MC</value>
 > >>            ...
 > >>       </case>
 > >>       <case>
 > >>            <label>Cash on delivery</label>
 > >>            <value>COD</value>
 > >>            ...
 > >>       </case>
 > >>   </switch>
 > >> </select1>
 > >>
 > >> This looks really cool because it is quite analogous to using <item>
 > >> with label and value children, except we are declaratively indicating
 > >> that the selection is being associated with switching among set of  
 > >> form
 > >> controls.  It even becomes easy to see how to extend this to the
 > >> "itemset" version by using repeat inside switch!  This would  
 > >> generate a
 > >> variable number of cases according to how much data there is.
 > >>
 > >> Maybe we could consider whether all of this is good to go or some  
 > >> of it
 > >> should be deferred, but great fun in any *case*!  (sorry)
 > >>
 > >> What do people think about this approach?
 > >>
 > >> 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
 > >>
 > >
 > > -- 
 > > Ulrich Nicolas Lissé
 > >
 > >
 > >
 > 
 > --
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
 > http://www.orbeon.com/
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Friday, 1 February 2008 22:52:03 UTC