W3C home > Mailing lists > Public > www-forms@w3.org > August 2005

RE: xforms:choose within xforms:repeat

From: John Boyer <JBoyer@PureEdge.com>
Date: Tue, 16 Aug 2005 17:52:59 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B52750918@tigger.pureedge.com>
To: "Peter Nunn" <peter.nunn@vistic-sw.com>, <www-forms@w3.org>
Cc: <w3c-forms@w3.org>

This is very similar in behavior to what I described and is based on some
earlier discussions of the working group, which Mark's team implemented.

In fact, I think in all practical purposes, it would act exactly the same,
so there is only a slight different that would be primarily of interest
in the conformance sense (going forward of course).

The main difference is that what I described was that the repeat index
would uniformly be used to help determine what thing has truly been
identified (e.g. which switch case to toggle).

What the working group discussed some time ago was a two stage operation
wherein toggles within a repeat row would operate in that row and toggles
outside the repeat would use the index as described.

However, when you activate a trigger in a row, for example, the trigger is 
first depressed.  It therefore gets the focus, causing the repeat index to 
be set to the row containing the trigger just pressed.  Then you let up on
the trigger, which activates it, resulting in its DOMActivate actions being
run, such as toggle or setfocus.  

So, almost always, there would be no difference of behavior between the two
approaches, but it is a cleaner design to not be required to distinguish 
where the action is to determine what will happen.  This is cleaner when 
you start to think about nested repeats but also, going forward when you
think about the problem of determining what to do if the action is not 
physically in the content of the repeat but it is part of an event handler 
that is listening on for an event on something that IS in the repeat.

Cheers,
John Boyer

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
Behalf Of Peter Nunn
Sent: Tuesday, August 16, 2005 5:20 PM
To: www-forms@w3.org
Subject: Re: xforms:choose within xforms:repeat



Erik Bruchez wrote:

>
> All,
>
> From the 1.0 spec, section 9.3.10:
>
> "A necessary consequence of this is that XForms 1.0 does not specify 
> the behavior of construct switch within element repeat. Future 
> versions of XForms may specify the behavior of switch inside repeat 
> based on implementation experience and user feedback."
>
> Any thoughts about what possible behaviors could be? I see two:
>
> 1. All the repeated switches show the same case element and switch at 
> the same time.
>
> 2. Somehow, a particular switch only switches, maybe based on the 
> source of the initial event causing the toggle action.
>
> I don't think #1 is very satisfying, and I am not too sure about the 
> consequences of #2. Any other thoughts on the subject? Should the 
> toggle action take one or more repeat ids / indexes as parameters?
>
> Actual users are likely to hit this snag. See for example this initial 
> post on ops-users:
>
>   http://mail-archive.objectweb.org/ops-users/2005-08/msg00069.html
>
> -Erik
>
>
>
>

Have used the behaviour of the formsplayer implementation which works really well in real-world applications, and have implemented it in a javascript xforms implementation.
The switch..case is local to the context which the toggle is contained within.
 The first switch with the id equal to the toggle case statement is used.  If the toggle is fired outside a repeat action then the code should toggle the prototype case statement and any new rows added to the repeat should then copy the prototype repeat row and toggle/case settings.

So it goes like this:
Each prototype row has the case id cloned.
A toggle activated on a row bubles up to the first case statement so that if it is inside a repeat it will find the cloned repeat, if not inside the repeat it will bubble to the root document.
If the toggle case was not handled the toggle will then search the dom down till it finds a case matching the toggle ID.  This will of course find the prototype repeat element and the case will be processed at that level.
The next row inserted into the repeat will then take on the toggle value.

This will work for all possible toggle cases.

regards
Received on Wednesday, 17 August 2005 00:53:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:01 GMT