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", the output control won't be refreshed if we do a xf:setvalue with value="/values/value". 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" 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.
Created attachment 183127 [details] testcase clicking on the trigger should update the output value from 10 to 20000
Created attachment 216410 [details] [diff] [review] 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)
Assignee: aaronr → allan
Attachment #216410 - Flags: review?(doronr)
Comment on attachment 216410 [details] [diff] [review] Patch fixed the problem
Checked into trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.