RE: xforms:choose within xforms:repeat

I think Mark's model of the XForms DOM holding a pointer into the
shadow tree, and that pointer reference getting updated to point
at the "node" in the repeat set that is "current" is exactly correct.

>>>>> "Mark" == Mark Birbeck <mark.birbeck@x-port.net> writes:
    Mark> Hi John,
    Mark> 
    >> 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.
    Mark> 
    Mark> Sure. You are exactly right, but I was describing XBL
    Mark> rather than XForms to try and show how we have most of
    Mark> the pieces of the jigsaw that we need. And since we
    Mark> obviously need the functionality that you describe, we
    Mark> (the XForms community) can go to the XBL team and
    Mark> request that if it doesn't support this feature, it
    Mark> should. (There is discussion on this, and it may be
    Mark> that it does already support this.)
    Mark> 
    Mark> 
    >> 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.
    Mark> 
    Mark> And I definitely agree with you. I think where we (the
    Mark> XForms world) are different to normal XBL is that we
    Mark> want a notion of a shadow tree that is to all intents
    Mark> and purposes part of the parent DOM. So if I have a
    Mark> document with a repeat in it, and there are five rows
    Mark> in that repeat, then there are five shadow trees. But
    Mark> we want one of them (the current row) to always appear
    Mark> as if it is in the parent. That way getElementByID()
    Mark> works exactly as you have described it.
    Mark> 
    Mark> Another way of looking at it might be that the repeat
    Mark> template (which is still sitting in the main DOM) is an
    Mark> interface to the currently selected shadow tree. Any
    Mark> reference to an element in the template is resolved to
    Mark> an instance in the current shadow tree. (This makes
    Mark> implementation little more than forwarding events,
    Mark> which is something that XBL also defines.)
    Mark> 
    Mark> 
    >> 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.
    Mark> 
    Mark> I'm not sure we need to do that; if we can say that one
    Mark> shadow tree per repeat is in the scope of the
    Mark> containing DOM then things should 'just work'.
    Mark> 
    Mark> Regards,
    Mark> 
    Mark> Mark
    Mark> 
    Mark> 
    Mark> Mark Birbeck CEO x-port.net Ltd.
    Mark> 
    Mark> e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w:
    Mark> http://www.formsPlayer.com/ b:
    Mark> http://internet-apps.blogspot.com/
    Mark> 
    Mark> Download our XForms processor from
    Mark> http://www.formsPlayer.com/
    Mark> 
    Mark> 

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    RDC --- Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://almaden.ibm.com/u/tvraman      (google:tv raman 
AIM:      emacspeak
GPG:          http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Wednesday, 17 August 2005 17:26:27 UTC