- From: John Boyer <JBoyer@PureEdge.com>
- Date: Tue, 16 Aug 2005 16:57:00 -0700
- To: "Erik Bruchez" <erik@bruchez.org>, <www-forms@w3.org>
- Cc: <w3c-forms@w3.org>
Hi Eric, We've actually given this a lot of thought in the group, and when you get right down to it, it is an error of oversight that switch in repeat should not be defined because of some id problem. The question arises, for example, how should setfocus behave when the identified control is in a repeat. Of course it should set the focus to the identified item *in the currently indexed row* of the repeat. Switch should behave the same way, and we're working on defining that for 1.1. Moreover, the language about expecting implementer feedback means that you can make your 1.0 implementation do this, but just don't expect everyone to catch up on an aggressive schedule (our implementation works, for example). So, to be clearer, when you use *any* construct of XForms that is based on id, it is best to obtain the identified element, then drill up through its ancestral chain to find all repeats in which it may be nested. Then, for each ancestor repeat starting with the outermost one, use the current index of that repeat to select a row. Then, if another repeat was in the ancestral chain, choose the one in that row, use its index and keep going until you've resolved the row in the repeat containing the identified element. Note that this should have an affect not just for toggling a case of a repeat, but setting or getting the index of an inner repeat, setting focus to a repeated control, etc. Best regards, John Boyer -----Original Message----- From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On Behalf Of Erik Bruchez Sent: Tuesday, August 16, 2005 3:36 PM To: www-forms@w3.org Subject: xforms:choose within xforms:repeat 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
Received on Tuesday, 16 August 2005 23:59:34 UTC