[Fwd: LC: Issue with repeat index and rebuild]

All,

Just one comment on the LC comment attached for the record.

One issue with preventing the use of index() in UI bindings is that it
prevents a very useful use case, that of a master-detail type of view.
An example of this:

<!-- Show list of departments for selection -->
<xforms:repeat nodeset="department" id="department-repeat">
      <xforms:output ref="name"/>
</xforms:repeat>
<!-- Show list of employees for current department -->
<xforms:repeat nodeset="department[index('department-repeat')]/employee">
      <xforms:output ref="name"/>
</xforms:repeat>

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Forwarded message 1

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, 18 April 2007 03:17:13 UTC