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

John,
 
I think the BPEL structured Switch/Case construct is an ideal example to
specify conditional behaviour.
The BPEL specification for Switch is
 
The switch activity makes it possible to specify conditional behavior. This
activity consists out of an ordered list of conditional branches. Every
branch is specified by a case element followed by one optional otherwise
element. The case elements in a switch are looked at in the order in which
they are placed. The activities specified in the case are executed when the
condition of the case is true. When none of the cases are true, the
activities in the otherwise element are executed. The switch activity is
done when all the activities of one of the branches are completed.
 <switch>
   <case condition="bool-expr">
     activity
   </case>
   <otherwise>
     activity
   </otherwise>
</switch>
 
My experience shows that developers are more then capable of learning this
structure then all the MIPs and Group blah blah
 
BTW this and the WHILE construct are implemented as part of our XForms
implementation thru the BPEL namespace. I will shortly be releasing some
forms based on "business state machine" this form will contain many
namespaces and we can have a debate on how XForms should be evolving and
what is meant by web applications or as I coin "Weblications"
 
 
Kind Regards
Francisco
 
facileXForms - Really AJAX at heart
 

  _____  

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of John Boyer
Sent: 19 September 2006 22:46
To: Erik Bruchez
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: 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/