Re: Pretty cool talk today; how about switch *inside* select1/select

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é