Re: LC: Issue with repeat index and rebuild (PR#24)

Hi John,

We acknowledge the problem, but we have decided to defer this to a future
version.

Regards,

Nick Van den Bleeken 

> 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
> 
>

Received on Wednesday, 12 September 2007 08:39:24 UTC