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

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/

Received on Friday, 1 February 2008 19:39:28 UTC