[
https://issues.apache.org/jira/browse/TAP5-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade updated TAP5-953:
--------------------------------
Attachment: nodetest.zip
Simple test application.
The test page contains
<ul id="list">
<li id="node1">node 1</li>
<li id="node2">node 2</li>
<li id="node3">node 3</li>
<li id="node4">node 4</li>
</ul>
<ul id="list2">
</ul>
In the afterRenderMethod I do node1.moveToBottom(list2). I'd expect only node1
to be moved there, but, as node1's nextSibling is not reset, nodes 2-4 are
rendered there too.
This becomes even worse by replacing the invocation by
node1.moveToBottom(list2). Then we're caught in an endless loop, as the
renderer will never cease to find a next sibling. Node4's next sibling will be
node1 (which is fine), and node1's nextSibling will still be node2, so it will
try to render list, node2, node3, node4, node1, node2, node3 and so on.
> org.apache.tapestry5.dom.Node.remove() should set nextSibling to null
> ---------------------------------------------------------------------
>
> Key: TAP5-953
> URL: https://issues.apache.org/jira/browse/TAP5-953
> Project: Tapestry 5
> Issue Type: Wish
> Components: tapestry-core
> Affects Versions: 5.1.0.6
> Reporter: Jochen Kemnade
> Attachments: Node.java.patch, nodetest.zip
>
>
> When removing a node from the DOM, its next sibling node should be reset.
> This is especially important for the
> moveToBottom(org.apache.tapestry5.dom.Element element) method. The current
> behavior of n.moveToBottom(e) results in n's following siblings being
> rendered twice, once in their original position and once after the moved
> node. Only the latter seems correct to me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
