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

Thanks for the markup as it can be slightly modified to highlight my 
point.

The first repeat does not generate any focusable controls, so it is 
unclear how the index of the first repeat ever changes.  But adjust the 
first repeat (below) to be an input instead so that the user can focus a 
control in any repeat item.

By focusing the control in one of the repeat items, the index changes in 
the first repeat.  But there is no instance node dependency to suggest 
that the second repeat's nodeset must be re-evaluated.  In other words, 
there is no xforms-refresh; indeed there is no[rebuild] recalculate 
revalidate *refresh*.  And if there were, there is nothing that changes in 
the instance data that would cause the refresh to conclude that the second 
repeat should be regenerated. 

So the first conclusion is that I don't think the markup in this email 
substantiates the limitation of index() to just xforms actions because I 
think it already doesn't work in any cases.

Moreover, making it work seems like it might be hard because it seems like 
there might be problems that arise based on the order in which refresh 
chooses to update repeats.  For example, 

<repeat id="X" nodeset="some/nodes"> 
   ...
</repeat>
<repeat id="Y" nodeset="some[index('X')]/other[index('Z')]/nodes"> 
   ...
</repeat>
<repeat id="Z" nodeset="still/more[index('X')]/nodes"> 
   ...
</repeat>

If the index changes in the first repeat, the second and third repeats 
would need to be regenerated, but clearly the order should be to update Z 
first then update Y.

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-editor-request@w3.org
04/17/2007 08:16 PM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org, www-forms-editor@w3.org
cc

Subject
[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/


----- Message from John Boyer <boyerj@ca.ibm.com> on Mon, 16 Apr 2007 
16:55:00 -0700 -----
To:
public-forms@w3.org, www-forms-editor@w3.org
Subject:
LC: Issue with repeat index and rebuild

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