Closed
Bug 362308
Opened 18 years ago
Closed 17 years ago
repeat doesn't update on value changes
Categories
(Core Graveyard :: XForms, defect)
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)
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.
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.
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
Attachment #255733 -
Flags: review?(Olli.Pettay)
Attachment #255733 -
Flags: review?(surkov.alexander)
Comment 8•17 years ago
|
||
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 10•17 years ago
|
||
Comment on attachment 255733 [details] [diff] [review] patch please update guid
Attachment #255733 -
Flags: review?(surkov.alexander) → review+
Assignee | ||
Comment 11•17 years ago
|
||
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.
Assignee | ||
Comment 12•17 years ago
|
||
changed guid
Attachment #255733 -
Attachment is obsolete: true
Attachment #255958 -
Flags: review?(Olli.Pettay)
Attachment #255733 -
Flags: review?(Olli.Pettay)
Comment 13•17 years ago
|
||
Comment on attachment 255958 [details] [diff] [review] patch2 I thought I had reviewed this already. How strange :)
Attachment #255958 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 14•17 years ago
|
||
checked into trunk
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
Assignee | ||
Comment 15•17 years ago
|
||
checked into 1.8 branch on 2007-04-12 checked into 1.8.0 branch on 2007-04-16
Keywords: fixed1.8.0.12,
fixed1.8.1.4
Whiteboard: xf-to-branch
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•