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
>
> 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