- From: T.V Raman <raman@google.com>
- Date: Fri, 1 Feb 2008 14:51:40 -0800
- To: ebruchez@orbeon.com
- Cc: public-forms@w3.org
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