Re: Switch case construct

Francisco,

Ok, I have had a go at reproducing your demo using just XForms 1.0  
(see attached form) and I now appreciate that at the very least it  
isn't clear how to reproduce it exactly (I couldn't anyway, though  
someone cleverer than me might manage it).

For those who haven't looked, Francisco's form allows a user to  
select four pre-defined subsets of cases inside a switch, which can  
then be navigated through as tabs.

So there is 1 switch with four cases. Setting a value from a select1  
makes a different predefined subset of the cases relevant and sets  
focus to the first of that subset.

The key thing I couldn't manage was using the select1 to both  
restrict the cases that a user could select _and_ toggle to the first  
case of that selection.

The first part is easy, I just used ref on a set of triggers with  
toggle actions. However, this could leave a toggle selected that is  
now outside the current set of valid cases. So I needed to toggle to  
the first of the valid set of cases, and without the ability to  
dynamically assign the case to toggle to I couldn't see how to  
achieve this from a select1.

Consequently I had to use four triggers, which I have taken the  
bother to style loosely like a select1 (I could have made it look  
more convincing if I could have been bothered).

A previous thread indicates that XForms will support dynamic  
selection of a case to toggle to which might solve the problem.

Apart from that problem I think I was able to reproduce the  
functionality of your test form. I am using the latest Firefox build  
to test and that does fire the events in each case somewhat  
erratically, which I will put down to the fact that it isn't finished  
(to be fair your form also gets events confused eventually and  
freezes Firefox). Firefox also paints the border of each case whether  
or not it is selected, which creates an interesting visual effect :-)

Have I missed anything? I didn't bother to change the default styling  
of non-relevant triggers to be visible with a greyed out appearance.

All the best

Mark

On 18 Aug 2006, at 12:09, Francisco Monteiro wrote:

> Mark
>
> My experience shows that given the tab approach the client will use  
> it 101X, as I mentioned before I do not see why case control should  
> not be treated just as any other single node bind control. Perhaps  
> the design of the switch/case was not thorough enough?
>
> "Is it definitely the case that the content of non-relevant groups  
> have to be in memory?" says who, it is up to the implementers to  
> decide this.
>

Apologies, I didn't read the word "parse" in your posting. Doesn't  
something have to parse an entire form to ensure that it is well- 
formed XML before an XForms processor can get to work on it?

> Francisco
>
>
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On  
> Behalf Of Mark Seaborne
> Sent: 18 August 2006 11:53
> To: www-forms
> Subject: Re: Switch case construct
>
> Francisco,
>
> But case doesn't take single node binding, and it isn't a form  
> control. The only benefit I can see that giving case single node  
> binding, etc is that you can set the relevance of a case rather  
> than the relevance of a trigger with a toggle action pointing at  
> the case. Logically your form still consists of a set of cases with  
> triggers used to toggle between them.
>
> Is it definitely the case that the content of non-relevant groups  
> have to be in memory? It might be worth asking for clarification on  
> that from the working group.
>
> John Boyer pointed out (http://lists.w3.org/Archives/Public/www- 
> forms/2006Aug/0059.html) that the working group has discussed this  
> and come to a resolution about the implications of a case not being  
> selected. Is this likely to satisfy your own requirement only to  
> have to load into memory as much of the form as is in active cases  
> (I know of at least 1 implementation that already does this)? If it  
> does then I see no reason why you couldn't just use:
>
> <xf:trigger ref="instance('dojo')/wf1">
> <xf:label>Section-I</xf:label>
> <xforms:action ev:event="DOMActivate">
> <xf:message level="modal">case 1 select event</xf:message>
> <xf:toggle case="Section-I"/>
> </xforms:action>
> </xf:trigger>
>
> <xf:switch>
> <xf:case id="Section-I">
>
> etc
>
> with CSS to style your triggers as the trigger portion of tabs.
>
> All the best
>
> Mark
>
> On 18 Aug 2006, at 10:43, Francisco Monteiro wrote:
>
>> 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
>>> 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
>>
>