Enhancement
Major
Detail
Major
Detail
Let a tl:TreeComponent be configured so that its root node is not displayed.
If the root node receives an update, for example by changing the structure by reordering the children, a tl:SubtreeUpdate is created with a range of Control ID's that is later used by the tl:TreeRenderer to update the (DOM) nodes in that range using a tl:RangeReplacement.
To determine the range of Control ID's of the SubtreeUpdate that should be updated, the children of the root node that were not newly added by the update are needed. The Control ID of the first visible node of these children is the left boundary and the Control ID of the last visible node is the right boundary of the range to be determined.
It is not the state of the tree on the client that is considered, but the state on the server. That is, the "first" and "last" visible nodes may differ in the various updates created by a user action.
For example, if the children are reordered in a first update, then the subsequent update refers to the state after this reordering. In particular, the first node to be updated is then the one that is at the beginning after this reordering. As a result, the range of Control ID's to be updated can be "really smaller" in the second update than the one in the first update.
This is a problem because if there are several subtree updates to the root node, only the last update is taken into account and sent to the client. The remaining updates are discarded.
Example
Suppose a root node has 3 children A` (ID: 1), `B (ID: 2) and C` (ID: 3). With the help of a drag'n'drop `A can be moved behind C`. This is a user action, but de facto two updates happen. The server only knows the state before and after the operation. The desired order is `B, C, A and this is what it is trying to achieve now. Due to a missing "smart heuristic" to use as few operations as possible for this, two are needed. In the desired order the elements are now "moved" to the right place.
First B` is "moved " to the right place, so `A and B` are swapped, then `C is moved to the right place, so A` and ` C are swapped. In total, two swaps or "moves" take place.
For the first update, i.e. the first swap, you get the range 1-3 of ID's that have to be updated on the client. This is ok, because the state of the children of the root node on the server corresponds to that of the client(A`, `B, C).
For the second update, however, i.e. the second swap, you get the range 2-3 of ID's that need to be updated on the client. The underlying children of the root node on the server after the first swap are namely B`, `A, C.
Since now only the last update is transferred to the client, the user has a problem. A too "small" subtree is updated.
Test
Start PDX and create three new top-level library elements in Products > BOM. Then drag and drop the first child of the root node behind the last child. As in the explained example, only 3 children of the root node should still be displayed.