RE: xforms:choose within xforms:repeat

Hi Mark, 

Actually what you said on the technical 'how to' side was quite clear
(the getElementById() discussion below).
It makes it clear why we've been thinking about these things a little
differently.  In my case, I still have been looking at ID and IDREF
from the pure XML document sense and then tacking on some post-processing
to get from an element in a repeat template to an element in a shadow tree.

The approach you described was more along the lines of treating the shadow
trees as whole documents in and of themselves.

The only problem I see, which I think is easily fixable, is that it 
doesn't seem to allow a shadow tree to IDREF back outside of itself into
the parent document.  It is an important use case, esp. once we have 
conditional execution of setfocus (e.g. by attribute value template in
the control attribute) to be able to allow an action coming from 
within the repeat to act over an identified element that is not in
the repeat.  For example, if I have a delete button on every row of
a table, and I press delete on the last row, the table becomes empty,
so I'd like to send the focus someplace else.

I think that my prior description of what you've done was a touch more
powerful in that it accounted for this.  I described it, though, from
the standpoint of resolving IDs on the whole document level.  So, if you 
look at it from a whole document level, the steps are:

1) Resolve the ID in the classical XML sense to element E
2) Get the set S of ancestor repeats for the resolved elements
3) Get the set T of ancestor repeats of the dispatching action A
4) For each common repeat in S and T, use the row that both elements 
	currently reside in.
5) For repeats in S but not T, use the repeat index to find the
	instance of E on which the action A should be performed.

No matter what, though, your description of why we should think of this 
as more than an edge case was convincing (to me, anyway), so while I did
previously feel it was likely the better behavior, I now also agree
that it is likely worth the effort for more than just purity's sake.

Cheers,
John Boyer


-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net]
Sent: Wednesday, August 17, 2005 7:49 AM
To: John Boyer
Cc: w3c-forms@w3.org; www-forms@w3.org
Subject: RE: xforms:choose within xforms:repeat


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
approach:

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'
one.

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
locally.

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


Mark Birbeck
CEO
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
http://www.formsPlayer.com/

Received on Wednesday, 17 August 2005 16:28:15 UTC