As I noted in bug 289534, there's still issues with binds using index(). There are two: 1) it does not work at initialization (ie. needs a rebuild) ProcessBind() is run before the repeat elements are constructed (same problem fixed in bug 291797 for the rest of the controls). 2) changes to repeat-index are not reflected Bind is not a XForms (UI control) element and does not register as an index listener as the UI controls (see bug 289534). There are bigger issues with the bind element though, as it might change the MIPs for instance nodes. The easy solution (which is also hidden as a suggestion in the spec. somewhere) is to do a full rebuild, recalc, etc. We might be able to pull it off by removing the bind MIPs from the MDG, applying them again, and rebuilding the MDG graph... but I haven't thought too much about it.

Here's a testcase showing the bug. It does not work 100% correct before bug 292089 is landed though.

(In reply to comment #0) > 1) it does not work at initialization (ie. needs a rebuild) > > ProcessBind() is run before the repeat elements are constructed (same problem > fixed in bug 291797 for the rest of the controls). > > 2) changes to repeat-index are not reflected > > Bind is not a XForms (UI control) element and does not register as an index > listener as the UI controls (see bug 289534). There are bigger issues with the > bind element though, as it might change the MIPs for instance nodes. > > The easy solution (which is also hidden as a suggestion in the spec. somewhere) > is to do a full rebuild, recalc, etc. We might be able to pull it off by > removing the bind MIPs from the MDG, applying them again, and rebuilding the MDG > graph... but I haven't thought too much about it. Well, issue 2) is not an issue since binds are static, so they actually only need to update on rebuild (bug 307421).

(In reply to comment #0) > As I noted in bug 289534, there's still issues with binds using index(). There > are two: > 1) it does not work at initialization (ie. needs a rebuild) > > ProcessBind() is run before the repeat elements are constructed (same problem > fixed in bug 291797 for the rest of the controls). This is still an issue, and it is a bit of a pain: If a bind is using the index() function in either @nodeset or any of the MIPs, what should the behaviour be on form load? Is it illegal and result in an xforms-compute-exception? Or should index() at that point return 0 or NaN? The problem is that binds are processed during xforms-model-construct, but UI is constructed during xforms-model-construct-done. [http://www.w3.org/TR/2006/REC-xforms-20060314/slice4.html#evt-modelConstruct] Just finding the repeat, and grabbing the @startindex does not work. Because the startindex might be higher than the actual size of the nodeset the repeat is bound to, and 1) it has not been bound yet, and 2) it might be bound using a @bind using an index() function ... ouch. [http://lists.w3.org/Archives/Public/www-forms/2006May/0177.html]

We'll definitely need to hold off on xforms-model-construct until the form is loaded (like in the handler for DOMContentLoaded in nsxformsmodelelement). As long as we do xforms-model-construct before xforms-model-construct-done, this shouldn't cause any grief I don't think. But probably more to it than that to fix this bug. I think that this is an important enough bug to fix before we ship 1.0. Adding it to the 0.9 bug list.

RIP xforms