RE: xforms:choose within xforms:repeat

Hi John,

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

Sure. You are exactly right, but I was describing XBL rather than XForms to
try and show how we have most of the pieces of the jigsaw that we need. And
since we obviously need the functionality that you describe, we (the XForms
community) can go to the XBL team and request that if it doesn't support
this feature, it should. (There is discussion on this, and it may be that it
does already support this.)


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

And I definitely agree with you. I think where we (the XForms world) are
different to normal XBL is that we want a notion of a shadow tree that is to
all intents and purposes part of the parent DOM. So if I have a document
with a repeat in it, and there are five rows in that repeat, then there are
five shadow trees. But we want one of them (the current row) to always
appear as if it is in the parent. That way getElementByID() works exactly as
you have described it.

Another way of looking at it might be that the repeat template (which is
still sitting in the main DOM) is an interface to the currently selected
shadow tree. Any reference to an element in the template is resolved to an
instance in the current shadow tree. (This makes implementation little more
than forwarding events, which is something that XBL also defines.)


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

I'm not sure we need to do that; if we can say that one shadow tree per
repeat is in the scope of the containing DOM then things should 'just work'.

Regards,

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:52:06 UTC