I seem to recall some years-old discussions about the effect of a repeat
index change on the XForms processor.
I seem to recall a face to face discussion in which it was suggested that
a repeat index change should correspond to an automatic rebuild because
bind nodesets or MIP expressions may contain invocations of the index()
function. I also recall the conversation indicating that implementations
could do something more optimized that a full rebuild, such as focusing on
binds that actually invoke index() on the affected repeat since those that
don't would be unaffected.
However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8)
that changing the focus to a control in a repeat item (row) other than the
indexed repeat item does cause the repeat index to implicitly change. In
combination with the statement above, this would mean an implicit
rebuild-recalculate-revalidate-refresh based. Moreover, changing focus
may change the index of multiple repeats that are nested, so one's spidey
sense gets the tingle of another optimization.
But the problem is that I cannot find any language in the XForms spec that
even implies a connection between repeat index changes and automatic
rebuilding. For the record, I think the connection between repeat index
and rebuild is wrong, and I was going to write a last call comment to
suggest its removal. But alas I have been foiled by the fact that it
already doesn't seem to exist in the spec. If someone can find this,
please let me know; otherwise I will proceed on the assumption that the
spec does not follow a repeat index change with an automatic rebuild.
I believe that the original discussion about automatically rebuilding on
index change was held, at least in part, from a desire to correct for the
fact that index() *could be* invoked from the XPaths within an XForms bind
(i.e. from model binding expressions).
However, since such automatic rebuild is ultimately doomed to failure
(because of automatic index changes on focus change in 9.3.8), it seems
better to consider restricting the index() function to only being used in
certain cases. Clearly, the index() function was designed for use in the
XPaths of XForms actions. When index() is used in a UI binding, it is
possible though somewhat difficult to create problems due to the staleness
of the result. More significant problems are easier to produce when
index() is used in a model binding expression.
In the past, this would have been hard, but XForms now requires different
exception behavior based on where an XPath is located. For example, in
Section 7.1, the choice of a binding exception versus a compute exception
is based on where the XPath is located. An invocation of index()
appearing in any XPath other than those used in XForms actions should
either produce NaN or preferrably an appropriate exception.
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer