Closed Bug 362308 Opened 18 years ago Closed 17 years ago

repeat doesn't update on value changes

Categories

(Core Graveyard :: XForms, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aaronr, Assigned: aaronr)

References

Details

(Keywords: fixed1.8.0.12, fixed1.8.1.4)

Attachments

(4 files, 1 obsolete file)

2.01 KB, application/xhtml+xml
Details
2.53 KB, application/xhtml+xml
Details
2.37 KB, application/xhtml+xml
Details
8.31 KB, patch
smaug
: review+
Details | Diff | Splinter Review
If the value of a node is changed (for example, via a xf:input) and that node is one of the nodes in a repeat's nodeset, the repeat doesn't reflect this change.
Attached file testcase
Looks like the problem is related to using @bind on the repeat element.  If we use @nodeset, then it works.  The issue is that if a repeat uses @bind, then mUsesModelBinding is PR_TRUE.  Yet it won't have a boundNode (since it is potentially bound to more than one node, really).  Thus nsXFormsModelElement::RefreshSubTree won't navigate down inside the nsXFormsRepeatElement's controlListItem looking for any children that might possibly need refreshed.  Instead we go on to the next sibling in the model's control list.  But when repeat uses @nodeset, then mUsesModelBinding is PR_FALSE so we don't enter into that test.  Now I need to sit and figure out what the proper behavior should be.
Attached file testcase2
please verify that this testcase works, too, when the fix is eventually tested.  I think it fails due to the same core problem that this bug addresses.  Testcase comes from Leigh (simplified version of Martin's testcase).
Thanks to a wonderful explanation of a section of RefreshSubTree by Allan, I think I'm on the right track.  I think that we are preventing ourselves from refreshing children of the repeat because we think that in cases where an element has a @bind (mUsesModelBinding) but doesn't have a bound node, then the parent will be hidden and thus so will all the children so no reason to refresh them.  And since it is a @bind instead of a @ref on the element, we don't have to worry about possibly having to rebind the element (if a dependency is dirty) since @bind nodesets are only refreshed on construction and during rebuilds.  Normal node value changing won't cause any kind of a rebind opportunity.
Heck, I'll assign it to myself to fix.  I've already done this much debugging on it... :-)
Assignee: xforms → aaronr
Blocks: 353738
Attached file testcase3
also affects xf:itemset's for the same reason as repeats.
Attached patch patch (obsolete) — Splinter Review
Attachment #255733 - Flags: review?(Olli.Pettay)
Attachment #255733 - Flags: review?(surkov.alexander)
I guess usesSingleNodeBinding should depend on xpath expression result type rather than tagname of control. In futrue when xforms is allowed to bind to element of foreign namespaces then it will be needed thing. Can we use type of binding to instance node instead?
(In reply to comment #8)
> I guess usesSingleNodeBinding should depend on xpath expression result type
> rather than tagname of control. In futrue when xforms is allowed to bind to
> element of foreign namespaces then it will be needed thing. Can we use type of
> binding to instance node instead?
> 

no, because @bind exists in both single node binding and node set binding.  I'd say that we'd have to wait to see how a foreign-namespaced element will determine whether it is using a single node binding or a node-set binding.  Probably a question for the CDF WG, though I'll also ask the XForms working group.
Comment on attachment 255733 [details] [diff] [review]
patch

please update guid
Attachment #255733 - Flags: review?(surkov.alexander) → review+
link for W3C post on the subject of how a processor is supposed to know if @bind is a node-set bind or a single-node bind on foreign namespaces elements: http://lists.w3.org/Archives/Public/www-forms/2007Feb/0101.html.  Hopefully this will generate some discussion.
Attached patch patch2Splinter Review
changed guid
Attachment #255733 - Attachment is obsolete: true
Attachment #255958 - Flags: review?(Olli.Pettay)
Attachment #255733 - Flags: review?(Olli.Pettay)
Comment on attachment 255958 [details] [diff] [review]
patch2

I thought I had reviewed this already. How strange :)
Attachment #255958 - Flags: review?(Olli.Pettay) → review+
checked into trunk
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: