Re: Switch case construct

Francisco

I think we shall have to agree to differ. Apart from my form losing  
the select1 you have to choose the subset of cases, which is  
something I think we will get back once you can toggle dynamically,  
the only big difference between our forms is that mine explicitly  
declares the triggers that toggle, whilst your infers them from each  
case.

Personally I prefer to see the markup and to have control of the  
label, help and hint values as well as any other actions I might want  
to perform other than the default toggle. As I said before, I can see  
a value to something akin to appearance="tabbed" that gives you the  
triggers automatically, but I don't think it a good idea to get the  
labels from the id attribute (I am guessing that is what you do), so  
I would at least want a label element (similarly help and hint). But  
that seems ambiguous: does the label go on the tab/trigger, or inside  
the case? So on the whole I think that sticking with explicit  
separation of trigger with toggle from switch/case is actually the  
simplest to use.

But then I'm so used to XForms I am not really one to judge. I  
certainly think that declaring actions inside trigger could be less  
verbose. It wouldn't be so bad just to assume that the triggering  
event is DOMActivate unless explicitly stated otherwise, for example.

I think the XForms WG is already considering how to make doing grids  
and paging easier with repeat, so you should definitely feed your  
ideas into that discussion.

Have a good weekend

Mark

On 18 Aug 2006, at 15:37, Francisco Monteiro wrote:

> Mark,
>
> Nein Danke to your XForm :-), too complicated.
>
> Having the case element as a normal single node binding makes it  
> easier to design and explain clients. It is hairy enough with all  
> this MIP's.
> Next target is repeat control, some serious shortcomings what we  
> have seen so far to make it page and or virtual grid.
>
> There is a small design change to be made to map Dojo event  
> handling to the XML event handler that is why sometimes FireFox  
> freezes!
>
> Regards
> Francisco
>
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On  
> Behalf Of Mark Seaborne
> Sent: 18 August 2006 15:10
> To: www-forms
> Subject: 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 :-)