RE: binds

Thank you, John, for the explanation. I can imagine a behaviour that would
handle dynamic dependencies properly, but I agree that leaving them out will
make thinks much easier.

I think that a more clear explanation of what is meant by "dynamic
dependence" is needed in the specification.

	Martin.


-----Původní zpráva-----
Od: John Boyer [mailto:JBoyer@PureEdge.com]
Odesláno: 22. března 2002 23:56
Komu: Micah Dubinko; Plechąmíd Martin; XForms
Předmět: RE: binds


Hi all,

<martin>
3) Why predicates are restricted in 6.4.2? How would you do e.g. something
like "Copy the value from "a/b" if "a/c" is 1":

	calculate="a/b[../c=1]"

when dynamic predicates are not allowed?
</martin>

<micah>
> 3) Dynamic predicates introduce the possibility
> of various kinds of loops in
> the dependency tree. We don't want recalculations
> to take very long (including infinite!) amounts
> of time. Thus, dynamic predicates are never
> allowed.
</micah>

<martin>
So, instead of writing 
	calculate="a/b[../c=1]"
you would allow only
	calculate="if(a/c=1, a/b, '')"
correct? What's the difference?
And if you allow neither the second version, what code would you use to
provide the same functionality?
</martin>

<micah>
I'm referring your dynamic bind question over to John Boyer, our calculation
expert.
</micah>

<john>
To assuage your concerns right away, I'll begin by saying that the second
calculate which uses the 'if' function is permissible and operates in the
manner you require.

Regarding the question of what is the difference:

The first calculate sets up a 'dynamic' computational dependency.  The
node(s) to which it is bound is(are) dependent on a/b only if a/c is equal
to 1.  The second calculate sets up static computational dependencies.  The
node(s) to which it is(are) bound are always dependent on a/b and a/c.  If
either a/b or a/c are changed, we know we need to rerun the 'if' function to
find out what the result will be.

The calculation engine builds a 'computational dependency digraph' that
represents how to change computationally related instance elements based on
an initiating change (e.g. user input).  We do not want this graph to
change, esp. not during a recalculation.  Suppose for example that you have
an an instance in which a/c starts out not being equal to 1.  Suppose that
your example calculate="a/b[../c=1]" were bound to some node X.  Well, when
we start, the result of the calculate is an empty nodeset, so X is dependent
only on a/c.  Now suppose the user enters some input that causes a/c to
become equal to 1.  The calculation engine would see that X needs to be
recalculated, so everything behaves as you would like so far.  Now suppose
the user enters some data that changes a/b.  You would expect X to be
changed, but X is only dependent on a/c, so it does not get updated.

In this tiny example, one could easily see the system updating the
dependencies for X when it is reevaluated, but in anything except trivial
examples like this it quickly becomes very difficult to manage because
changes of value during a recalculation would actually change the
calculation order, so doing things like computing the pertinent dependency
subgraph are non-starters because the pertinent subgraph is changing
dynamically.  So instead of this big headache, we have the 'if' function
that allows you to do what you want while simultaneously imposing a style of
expression that creates static dependencies.

Best regards,
John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.
</john>

Received on Monday, 25 March 2002 03:16:37 UTC