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

John,

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

No, I really meant refresh on focus change ;-) We were talking about
the user-triggered focus change causing an index change. But I think
we understand each other.

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

I started writing "I agree", then figured that I was not sure I grasped
the necessity of the dependency mechanism.

Currently, XForms does not specify a dependency mechanism for UI
controls. This why the spec for "refresh" is the way it is. It
specifies in section "4.6.7 Sequence: Value Change":

   "3. xforms-refresh performs reevaluation of UI binding expressions
    [...]"

This means all UI bindings. A well-functioning dependency mechanism
would allow getting rid of this point, because only the UI bindings
that need updating would be updated. (Possibly in that case
xforms:rebuild would force all bindings to be recomputed.)  But this
dependency mechanism would be mainly a performance optimization.

So to get back to my example: the form user indirectly causes an index
to change. When that happens, the "flag" for refresh is set. Upon the
next refresh, the UI correctly reflects the data, including all
current values of the indexes. So there is no problem, right?

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

I don't think the above is correct, because:

1. There is currently no dependency mechanism for UI controls.

2. All UI bindings are re-evaluated upon refresh anyway. So you don't
    need to know which binding changed, the UI behaves as if all of
    them did.

Even so, referring to "implicit instance data" would be an
implementation detail. Currently, XForms does not specify a dependency
system between controls and instance data. So I think that if we
defined a dependency mechanism, we wouldn't necessarily need to
introduce "implicit instance data". This would be a way of looking at
it, but you could as well consider repeat indexes as first-class
objects in the dependency system.

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

I understand the rationale in theory, but I don't think you are right
saying that it doesn't do what the author wants as I show above.

If we don't allow index() in the bindings, then we force form authors
who want to have a binding depending on index() to use @calculate or
xforms:setvalue to store the value of the index in instance data, and
then to bind their controls using an XPath expression referring to
that instance data.

This introduce a dynamic dependency which is in fact no different from
directly using index(), except that it causes way more work for the
form author.

-Erik

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

Received on Tuesday, 1 May 2007 11:48:43 UTC