293571 - output not refreshed due to xpath dependency problem?

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect, P2)

Description

[aaronr]

Well, I THINK that the summary is right.  I guess Allan will have to tell us if
I've gotten on the wrong track.  If I 'bind' an output to instance data element
using @value="/values/value[1]", the output control won't be refreshed if we do
a xf:setvalue with value="/values/value[1]".  However, if we change both
expressions to be "/values/value", then it will refresh fine.

Output elements don't end up with a mBoundNode since it calls ResetBoundNode
with type = nsIDOMXPathResult::STRING_TYPE instead of evaluating for a node when
it detects @value w/o other binding attributes.  So the output control will
depend on the xpath dependencies that come back during the call to
nsXFormsXPathAnalyzer::Analyze() (called during node binding) to detect when to
rebind and refresh when nsXFormsModelElement::Revalidate is called.  A
dependency node is found when "/values/value" is evaluated, but not when
"/values/value[1]" is called.  So that output control won't detect that it needs
to be refreshed after set value changes the instance node.

I think that I remember problems with output not refreshing correctly if bound
solely with @value but I couldn't find an open bug that seemed to match this.

Comment 1

[aaronr]

Attachment: testcase

clicking on the trigger should update the output value from 10 to 20000

Comment 2

[Allan Beaufour]

Attachment: Patch

Problem is that a @value expression has no bound node (because it is STRING_TYPE), so the normal logic of mBoundNode keeping a "reference" to the "single node result" of the XPath expression does not work.

This patch fixes this by letting the XPath Analyzer include the result, if the result type is of STRING_TYPE. This means that for output @value, the single node result is included in the dependencies list, and thus refreshed (rebound) correctly.

(it's been a while since I've ventured down in these files. Oh, are they undocumented, etc... ouch ouch)

Comment 3

[Doron Rosenberg (IBM)]

Comment on attachment 216410 [details] [diff] [review]
Patch

fixed the problem

Comment 4

[Allan Beaufour]

Checked into trunk