Re: Feedback on 1.1: Case element content model and attributes

Hi Erik and Rafael,

Well, I can certainly relate to leaving 'case' alone for now :-)

However, for the record, I believe that doing model-based switching using 
group was not really the best idea.

Aside from the collateral damage of having made a mess of our notion of 
form control by having to sometimes include group and switch and sometimes 
not include them, the more direct problem is just that using groups to do 
switching is not declarative.  The form author's meaning is derived 
indirectly through semantics.

The point is that you either want several groups of controls to be related 
into a UI switching construct or you don't, and whether or not you choose 
to control that from the data model is orthogonal.  The great weakness of 
switch right now is exactly that there is no easy way to control it from 
the model, so we are left with having to use a pile of groups that, by 
happenstance, only allow one group to be relevant at a time.

It would be cool to have a switch that could declare itself as behaving 
somewhat like a select1, with the cases in it being like items.  So the 
single-node binding on the switch would resolve to a node whose value 
would be used to select a case by ID, and a toggle action would then 
behave much like the user selecting a new and different item in a select1, 
such that the ID of the newly selected case would be placed in the data 
model at the node indicated by the switch ref.

Just to avoid confusion, of course, I am obviously not talking about 1.1 
here.

My original suggestion was just about better aligning case with group.  I 
don't happen to think it's confusing for a selected case to be bound to a 
non-relevant node.  The selection of a case is orthogonal to its 
relevance.  It's just as if, as Erik suggested, you were to put a group 
inside the case.  You select the case, but the group binds to a 
non-relevant node, so nothing in the group is available to the user.

Frankly, this only came up because I just had finished an action item to 
write an erratum to XForms 1.0 saying that you should be able to put 
XForms actions in a case, which we would not have had to do if case had 
contained UICommon* as group does.  And as I said at the beginning, it can 
wait :-)

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-request@w3.org
09/18/2006 06:15 AM

To
www-forms@w3.org
cc

Subject
Re: Feedback on 1.1: Case element content model and attributes







Rafael Benito wrote:
> In this case, we should define the behaviour in cases such as having the 

> ref pointing to a non-existant node or a non-relevant node. Then, if the 

> user toggles to that case or selected is "true", what is the behaviour?

That's a good point. If I understand well, xforms:case was introduced to 
provide an alternative to model-based switching. If we introduce 
xforms:case/@ref, then xforms:case starts having a hybrid and possibly 
quite confusing behavior. For this reason I think that it would be best 
to leave xforms:case as it is, without @ref attribute. You can always 
nest xforms:group within xforms:case if needed.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/