RE: Switch case construct

Mark,
I am using  "conventional" model-based switching , if you look at the xforms
source you will see that the xf:case is used just as a normal single node
binding control.
 
When I set about writing the XForms processor I looked at what was
available, looked at design patterns currently used by my clients and
BPEL/Workflow and then set about creating these composite controls, nobody
does creating of composite controls better then Dojo and Yahoo!UI.
 
The inner details of why I used tabswitch case is that for very large forms
we only need to parse what workflow the client wants, with group I would
have to parse the whole forms!
 
Look at the XForms source and it answers many of your other questions.
 
I have a "pattern" documentation and some clients use it for Templating and
writing special composite controls.
 
Thanks
Francisco

  _____  

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Seaborne
Sent: 18 August 2006 10:14
To: www-forms
Subject: Re: Switch case construct


Francisco, 

Surely the effect you achieve in your form, of using model based relevance
to determine which cases are potentially viewable by the user, is already
achievable using "conventional" model-based switching? You could use group
instead of switch/case, or, if you were using switch/case as currently
defined (rather than your own tabswitch/case) you would just bind triggers
styled to look like tabs to you model. Either way the same effect is
achieved.

The thing that stands out about your tabswitch element is that it manages
case selection directly without the need for some other mechanism, such as
triggers. That is rather neat. So if switch was to be changed to allow this
kind of @appearance="tabbed" (for example) then each case would
automatically get its own trigger, that would need to behave just like a
normal trigger, I guess with a default action of toggle to its parent case,
triggered by DOMActivate. 

I think that this might fall under the category of making common design
patterns easy for authors and could be considered by the WG. 

The simplest pattern achievable like this is to say all cases would be
relevant. If you wanted the mechanism to support relevance then you would
either need ref/bind on case.

But then where would the auto-generated trigger get its label, etc from? 

If you have to add to case single node binding, label, help, hint and action
it is arguable that you might as easily wrap them in a trigger element as
described above, which would give more flexibility with styling, etc.

So maybe switch/case is alright after all? I'm not sure.

All the best

Mark


On 18 Aug 2006, at 08:22, Francisco Monteiro wrote:


My take on the whole switch-case construct is that it is too restrictive.
The case element is a control so all rules about Xforms control should apply
by this I mean enabled, disabled etc. When you are doing workflow and have
tabbed switch, the case element is viewed as a "section" just as paper forms
are written today.

I have a small example here which demonstrates what I am implying and it can
be viewed here
http://showoff2.awardspace.biz/pack/pack/examples/tabswitch2.html
<BLOCKED::http://showoff2.awardspace.biz/pack/pack/examples/tabswitch2.html>


Most clients I have like it this way, they see up front what is enabled or
disabled. Xforms must be viewed in terms of workflow, anything which helps
users have a easy experience should be encouraged.

Regards
Francisco