Re: xforms:choose within xforms:repeat

I don't have much to contribute here at this point, but thanks for an 
informative and interesting discussion. Looking forward to implement 
something along those lines in OPS!

-Erik

Mark Birbeck wrote:
> 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 Saturday, 20 August 2005 00:46:59 UTC