Fehlerbehebung
(Nutzer-sichtbar)
Sei eine tl:TreeComponent so konfiguriert, dass ihr Wurzelknoten nicht angezeigt wird.
Erhält der Wurzelknoten ein Update, indem bspw. die Struktur durch Umordnung der Kinder geändert wird, so wird ein tl:SubtreeUpdate mit einem Bereich von Control ID's erstellt, dass später durch den tl:TreeRenderer benutzt wird, um mit Hilfe eines tl:RangeReplacement die (DOM-) Knoten in diesem Bereich zu aktualisieren.
Um den Bereich der Control ID's des SubtreeUpdates, die aktualisiert werden sollen, zu bestimmen, werden die Kinder des Wurzelknotens benötigt, die durch das Update nicht neu hinzugefügt wurden. Die Control ID des ersten sichtbaren Knoten dieser Kinder ist die linke und die Control ID des letzten sichtbaren Knoten die rechte Grenze des zu bestimmenden Bereichs.
Es wird nicht der Zustand des Baums auf dem Client berücksichtigt, sondern der auf dem Server. Das heißt, der "erste" und "letzte" sichtbare Knoten kann sich in den verschiedenen Updates, die durch eine Benutzeraktion erstellt werden, unterscheiden.
Werden bspw. in einem ersten Update die Kinder umgeordnet, dann bezieht sich das darauf folgende Update auf den Zustand nach dieser Umordnung. Insbesondere ist dann der erste zu aktualisierende Knoten der, der sich nach dieser Umordnung am Anfang befindet. Dadurch kann der zu Bereich von Control ID's, die aktualisiert werden sollen, im zweiten Update "echt kleiner" sein als der im ersten Update.
Das ist ein Problem, da bei mehreren Teilbaumupdates auf den Wurzelknoten ausschließlich das letzte Update berücksichtigt und zum Client geschickt. Die restlichen Updates werden verworfen.
Beispiel
Angenommen ein Wurzelknoten hat 3 Kinder A` (ID: 1), `B (ID: 2) und C` (ID: 3). Mit Hilfe eines Drag'n'Drop kann `A hinter C` geschoben werden. Das ist eine Benutzeraktion, aber de facto passieren zwei Updates. Der Server kennt nur den Stand vor und nach der Operation. Die gewünschte Reihenfolge ist `B, C, A und diese versucht er nun zu erreichen. Aufgrund einer fehlenden "klugen Heuristik" um möglichst wenige Operationen dafür zu benutzen, werden zwei benötigt. In der gewünschten Reihenfolge werden die Elemente nun an die richtige Stelle "gemoved".
Zuerst wird B` an die richtige Stelle "gemoved", also `A und B` getauscht, anschließend wird `C an die richtige Stelle gebracht, also A` und `C getauscht. Insgesamt finden so zwei Vertauschungen bzw. "Moves" statt.
Für das erste Update, also die erste Vertauschung, erhält man den Bereich 1-3 von ID's, die aktualisiert werden müssen auf dem Client. Das ist ok, da der Stand der Kinder des Wurzelknotens auf dem Server dem des Clients entspricht (A`, `B, C).
Für das zweite Update hingegen, also die zweite Vertauschung, erhält man den Bereich 2-3 von ID's, die aktualisiert werden müssen auf dem Client. Die zugrunde liegenden Kinder des Wurzelknotens auf dem Server sind nach der ersten Vertauschung nämlich B`, `A, C.
Da jetzt nur das letzte Update zum Client übertragen wird, hat der Benutzer ein Problem. Ein zu "kleiner" Teilbaum wird aktualisiert.
Test
PDX starten und in Produkte > Stückliste drei neue top-level Bibliothekselemente anlegen. Anschließend das erste Kind des Wurzelknotens hinter das letzte Kind ziehen und fallen lassen. Wie im erlärten Beispiel sollten weiterhin nur 3 Kinder des Wurzelknotens dargestellt werden.