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/

Received on Friday, 20 April 2007 04:27:34 UTC