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

Hi Erik,

By refresh on focus change, I did assume you mean refresh on repeat index 
change.

I had thought that I might be getting too detailed in my prior email, so I 
did not include language to explain why adding language for a refresh on 
index change wouldn't work (by itself).  This was because it already 
seemed clear from the three repeat example that a system of dependencies 
would be needed to work out refresh order.  A corollary to that is that a 
dependency system would have to be worked out even for the simpler case 
you presented.

The problem with saying that a refresh will occur if a repeat index 
changes is that the refresh has no way of knowing that a particular 
repeat's nodeset is stale if the only different thing is the result that 
index() would return if it were invoked again.  In other words, we would 
have to say that every repeat index creates some *implicit* instance data, 
and that the invocation of index('X') creates a dependency between the 
invoking XPath expression and the implicit instance data representing the 
index of repeat X.

The above probably would solve the two repeat case you gave, but further 
work would then be required to handle the three repeat case (and higher).

If all of this were worked out properly, then there probably wouldn't be a 
need to restrict use of index anywhere.  So it is an alternate proposed 
fix to the underlying problem that I was raising, which is that when 
index() is used in model bindings or even UI bindings, the spec does not 
support it working as the form author might expect.  An easy fix is to 
make it easier for the form author to know that he or she has used the 
function in a way that is not currently supported by the XForms processing 
model.  Harder fixes would involve extending the processing model to fix a 
part of the problem or the whole problem. 

Finally, I noticed you questioned why index() could not be invoked from a 
UI binding if the spec didn't support refreshment of the containing XPath 
expression when the referenced index changes. I believe the answer is 
simply because the function invocation in a UI binding does not do what 
the form author expects.  When you first proposed your two repeat example, 
I believe you gave it as something that *should* work, and the problem is 
that it doesn't..  So, unless the problem is fixed, we should at least 
create a binding or compute exception when index() is misused (depending 
where it appears) so that a form author can at least find out that he or 
she is doing something unsupported.  Basically, we want to reduce the 
number of places where a form author sits for hours trying to figure out 
what they must have done wrong to cause the form not to update properly. 
This is done by either patching or repairing the hole in the spec.

Best regards,
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: public-forms-request@w3.org
04/19/2007 09:27 PM
Please respond to
ebruchez@orbeon.com


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

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







John Boyer wrote:
 >
 > 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.

I am not sure XForms prevents an implementation to allow the user to
select a repeated section and therefore change a repeat index in the
absence of focusable controls. But yes, you can as well use focusable
controls.

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

I agree that the current XForms spec does not specify that there
should be a refresh.

Then in that case, I *really* don't see a reason why index() could not
be used in a UI binding. It would seem to be an arbitrary restriction.

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

An implementation would probably need a system of dependency to
determine the best update order.

Now to get back to the original case: what if you did perform a
refresh upon a focus change in the first repeat? Then it seems that
the spec allows implementing my use case at the cost of an explicit
refresh.

-Erik

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