強引に解決覚え書き

DWRのsortableを使って、従属オブジェクト(例えば組織に対する拠点)の順位付けのメンテナンスがカッコ良く出来ていました。で、実際のD/Bテーブルに反映するには、ブラウザ上で表示されている順序で該当する従属オブジェクトの識別子(id)を配列として作成し、それを受け取ったmanagerクラスが、配列を順番通りにループしながら、そのカウンター(概ね「i」ですよね)をそのまま、データ項目の「表示順(私の場合はdisp_order)」に投げ込む。・・・という、「スバラシイ」ロジックで実装していました。

で、困った点

今度は同じ従属オブジェクトでも再帰的な要素(今回は「部署」・・・部・課・係)を同様に処理しようとして、階層の深さの表現(横の位置とか「┣」「┃」「┗」こういうの)をシコシコ作り込んで実装し、いよいよsortableで、ビジュアルにメンテナンス・・・・。ところが今度は上記のように、ザックリと大胆にやるわけにはイカヌ。

sortable処理後に順番が変わるのは移動させたelementだけではなく、抜けたり、割り込まれたりしてシフト(+1 or -1)された連中。もちろん処理対象はツママレタelementなので、上下の順列の規則性から判断しようとしたが、良く吟味すると隣接する2行が入れ替わった結果からは、どちらがツママレタ本人であるのか判断できない。(だって変更は本人だけなんだもの)

で、実際の更新のトリガーになるonUdateとは別にonChangeとかで、ツママレタ(つまりdragされた)行番号なりidなりが取得出来ないか?・・・・と、調べ回ってオオハマリ。

で、逃げた(工夫した)方法

sortableの対象がtableのtrだったので、trにonmousedownイベントで、dragLineという変数に処理前の位置を特定できる(行番号とか)を予めセット。sortableでのonUdate処理で、対象の上から下へループを回し、dragLine(本人)を発見した行がdropLine(安置された場所)ってことで、結構回りくどい処理になっちゃったケド。・・・・っま、悪くもないか?

Categories: Mighty構想 Tags:
  1. No comments yet.