ugnagブログ

次にやったのは、受け入れの制御。

つまり、「このノードにはこのノードをドロップしていい」とかいけないとかの制御。


共通の制御として位置関係もある。
フォルダーをドラッグして、その下位へドロップはできないようにするとか。
複数のノードをドロップされたとき、その内のひとつがドロップ先と同じだったとか。

そういった制御をうまくクリアした。


で、実際に移動の処理をしようと思ったところでちょっと困った。

移動処理だから、
１．移動元をツリーから切り離す
２．移動先に追加する
という手順になるが、別のフォルダーへの移動はまだしも、同一フォルダー内での移動、つまり順序の変更になるわけだが、これの時に困ったことが起きる。

移動元のノードを切り離したときにインデックスがその分ずれてくる。

だったら、インデックスをその分加減すればいいかというと、そうもいかない。
移動元が移動先より前にあればずれてくるが、後ろにあったときはずれてこない。

しかも、移動元はひとつとは限らない。
さらに連続している保証もない。
こっちのフォルダーの子ノードをひとつと、あっちのフォルダー内のノードをひとつ、なんてこともあるわけだ。

そうなってくると、インデックスの加減は非常にややこしくなる。


だったら、追加した後に削除したらどうか、と考えた。
それなら、インデックスは変らないので追加できる。

しかし、今度は削除するときに問題になる。

追加をした時点で、ひとつのツリーの中に、同じノードIDを持つノードが複数存在することになる。

削除する際にノードIDで区別をされるが、同一のIDが複数あれば間違いなく誤作動する。

これには結構困った。


なんとか見つけた解決策は、
・追加、削除の順に行うこととする
・追加する前に、追加するノードのノードIDを変更する。

もともと、転送されてきたオブジェクトは転送として送り出したオブジェクトのコピーだ。

従って、ノードIDを変更しても、元のノードには影響ない。
また、ノードIDが重複したりしないかということも、ノードIDはオブジェクトのハッシュ値を使っていて、このハッシュ値というのはオブジェクトのアドレスを用いているらしい。
そのため、本来のハッシュ値を使うだけなので問題はない。


試行錯誤を経てやっと実際の転送までができあがった。

なんか、先がおもいやられる。