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

RE: xforms:choose within xforms:repeat

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 17 Aug 2005 15:49:13 +0100
Message-ID: <8280BA3A-9B88-4B76-B22E-85CB4FE41F92@S009>
To: "'John Boyer'" <JBoyer@PureEdge.com>
Cc: <w3c-forms@w3.org>, <www-forms@w3.org>

Hi John,

> Yeah, I rather remember this issue being around for a very 
> long time.  It seems odd to me that switch in repeat would be 
> singled out as not working when there is the long standing 
> belief that setfocus should work when it refers to an element 
> in a repeat.

Now you mention it, I think that implementing xf:setfocus all those moons
ago was actually why we ended up implementing xf:switch/xf:case/xf:toggle.
I'd forgotten about that!

> Anyway, I think the ideas we now share are very similar and 
> would therefore behave much the same.  As far as I can tell, 
> the only difference is that I propose to uniformly 
> dereference a repeated element using the indices of its 
> ancestor repeats whereas you propose that the dereference 
> should behave that way unless the element containing the ID 
> and the one containing the IDREF have a common ancestor repeat.
> All I've heard in the past is about what happens when the 
> id-based action and the identified element are in the same repeat row.
> But the generalization of that appears to be that for all 
> repeat ancestors in common, the common repeat row is used and 
> repeat indices are used for ancestor repeats of the 
> identified element that are not ancestors of the id-based action.
> The use case for this appears to be something along the lines of:
> 1) An instance data node is changed.
> 2) The node is referenced in a calculate by a set of nodes 
> that are bound to a UI element in each row of a repeat.
> 3) The UI elements have xforms-value-changed action handlers
> 4) The xforms-valued-changed handlers contain id-based actions.
> It's a little odd when the action is setfocus, but not 
> unpalatable because it is an edge case.
> Other actions like toggle and setindex make more sense as 
> does use of index().
> Still, the whole thing looks like a bit of an edge case, 
> leaving a certain want for a behavior that might reasonably 
> be gleaned from the XForms spec, which is that an IDREF 
> should be dereferenced based only on properties of the 
> identified element, specifically what is its id and what are 
> the indices of its ancestor repeats.
> It would be good to see a strong use case for the more 
> complicated analysis of common ancestors.

I'm not totally clear whether I'm getting you correctly, but I think what
you're saying is, "is there much to be gained from not adopting an approach
of *always* use the index() value to find the element with @id of 'x'?" If
that's not correct I apologise, and please put me right.

But if I am understanding the issue, then first if I can clarify the fP

If you dispatch an event to an element with an @id, and that element is in a
xf:repeat, then:

  (a) if the event is dispatched from outside of the repeat, the target
      is in the 'current row' of that xf:repeat;

  (b) if the event is dispatched from inside the repeat, the target is
      in the 'same row' as from where it is dispatched from.

In most common forms this will amount to the same thing--as you said--since
if you have a xf:trigger in a row, the focus changes to the row which
contains the referenced control *before* the event is dispatched.

However, the reason for using the notion of 'local' is that xf:triggers are
not the only way of dispatching events. I would suggest that there are many
situations where you want each 'row' in a xf:repeat to render slightly
differently based on the value or state of the data. For example, if there
is an error in a field, you could show some further fields that need
completing. These could be controlled with relevance, but they could also be
controlled with xf:switch/xf:case/xf:toggle.

In other words, it's not just xforms-value-changed that might be used, but
xforms-invalid, xforms-readonly, or whatever.

So I don't think this is an edge case, at all.

>  I'm especially 
> concerned about what will eventually happen when event 
> handlers can target shadow tree nodes.  Do we then unravel 
> the IDREFs based on location of the event target rather than 
> where the id-based action is located?  If we don't, then we 
> wouldn't have behavioral consistency among event handlers, 
> but if we do the result is patently bizarre and, I would 
> think, relatively hard to implement.

I'm not quite sure what you mean here. I apologise for being dim, but
perhaps if I say a few things about how shadow trees are conceptualised I
might in the process (albeit accidentally) help clarify this :).

In many ways they can be treated like little DOMs. This means that each
shadow tree must have unique IDs, and when you refer to an ID in a shadow
tree it's therefore obvious which one you mean. However, these DOMs are also
connected to a parent DOM, and the relationship between the two is pretty
clearly defined.

Actually...let me qualify that...it's in the process of being clearly
defined! But whatever the outcome (and I'm thinking sXBL here) the general
principles will be that there is a high level of encapsulation, which
clearly defined interfaces between the 'nested' DOMs and their parent.

For example, it is generally agreed that a call to getElementByID() in the
parent DOM would not discover nodes in a shadow tree. Similarly, a call in
the shadow tree would not necessarily discover nodes in the parent. However,
circumstances under which they would discover nodes in each other can be
defined, and your use of index() in xf:repeat is one; in effect you are
saying that one (and only one) shadow tree from a xf:repeat (which may be
controlling umpteen shadow trees) is to be treated as if it was part of the
parent DOM. Then functions like getElementByID() would be allowed to find an
element that was in a xf:repeat, but it would only ever find the 'current'

But this leaves untouched the fact that a call to getElementByID() 'inside'
one of the many shadow trees controlled by a xf:repeat would resolve

Note that in the main I am describing vanilla XBL behaviour, only slightly
modified by the presence of XForms and in particular xf:repeat. I point this
out because many of the issues we are discussing concern XBL generally, and
are not specific to xf:repeat. But I think it would be odd to implement and
define xf:repeat in a way that is not consistent with XBL priniples, given
the work that the W3C is putting into it.

I doubt that clears up the matter, but I hope it shows that it is possible
to be consistent with this. True, we are actually going slightly beyond sXBL
territory, but I think we are building on their principles, rather than
breaking them.

All the best,


Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Wednesday, 17 August 2005 14:49:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:15 UTC