- From: John Boyer <JBoyer@PureEdge.com>
- Date: Wed, 17 Aug 2005 09:25:30 -0700
- To: "Mark Birbeck" <mark.birbeck@x-port.net>
- Cc: <w3c-forms@w3.org>, <www-forms@w3.org>
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