ajax処理でDWRはとても便利ですが、よくハマルので「身が引き締まる思い(?)」です。
さて、今回はパラメータに配列を使った場合にチョイとヤラカシました。
以前にやったのは、ちゃんと上手く動作したのですよ。
hogeMng.hoge(param, function(result) { ….hoge…});
ここで、paramは受け側のjavaでlong[]で、問題なかった。
で、今度は同様な感じで、paramを受け側javaでString[]でやったら、「Input parameter probably is not an object. (Missing: {).」と、怒られちゃいます。
どうやらDWR君は配列がプリミティブ型であれば通るのに、オブジェクト型だとダメな感じです。
※ もちろん連想配列にして「クラス」としてパラメータ渡しするのはバッチリですが、たかだか文字列配列がダメ。
で、悩んで試して、落ちついた対処が、受け側のパラメータをString[]ではなくList<String>にすることで動作しました。
もっと、カッチョ良い方法もあるカモですが、「javascript側の配列は、javaではListで受ける」ってのでとりあえず許してね。
CRUDってヤツですよね。Create,Read,Update,Delete・登録、読込、修正、削除。
これの処理の集結にヤッキになっておるのですよ。「同じような処理をコピペなどせずに一箇所にまとめる」、非常に良いことですよね。
なので、CommonManagerで型パラメーター付きで実装し、各Managerで継承すれば、何のコーディングもなく実装できちゃいました。パチパチパチ・・・・。
で、このRestructを進めてまいりました。・・・・が、
単純なEntityのManagerでは、何の記述も不要ですが、別のEntityを包含しているようなヤツでは、登録やら修正の際には内容の必須検査や整合性検査などのチョコッと前処理（下ごしらえ）してから、共通のヤツをヤリたいってコトになりまして、「そんなことは任せなさい！メソッドをオーバーライトして最後にsuper.hogehoge()でイイじゃん。
ですよねぇ～。ホラ出来ちゃった。
で、ブラウザからDWRを使ってソレ・・・・あら？エラー。
ＤＷＲはオーバーロードのあるメソッドはダメってのは分かっていたので、避けていましたが、オーバーライトもダメなのね。
っま、対処法は実装する各Managerが別名のメソッドで、super.hogehoge()と一筆入れるだけなんですが、かなりトホホな感じが否めないデスね。
以前にもDWR君の予約語でハマったことがありましたが、おそらく今度もそのようです。確信持てないけど。
色々なEntityで、開始と終了といった要素のあるもの（例えば、人物の「誕生日・死亡日」、組織の「設立日・解散日」）を「staDate,endDate」と言うメンバーとしてgetter,setterで処理しておりました。そりゃあ、順調に動いチョリましたよ。
ところがendDateの更新処理が出来なくなりました。エラーは一切ありませぬ。よくよく調べてみると、クライアント側のjavascriptでは、ちゃんと更新データはセットされチョリますが、ajaxを介しての、サーバー側で受け取ると、更新内容が無くなっちゃう。ウーム、困った。
試しにsetter,getterのメソッド名をgetDumm,setDummに変更したら、動いた！！！！
やや、マタシテモ予約語にブチ当たったらしい。心当たりはファイルのドラッグ＆ドロップへの対応のために行ったspringのバージョンアップが怪しい。ググッて見てもそれらしいコトは引っかからないが、上記の検証でgetEndDate,setEndDateのメソッド名がダメなことはわかったので、深くは気にせず、実装にdummってのも何だから、フランス映画のように「finDate」としてみたら、これもダメ！！！！
もはや闇の中をサマヨウ子羊状態。
よし、頭にキタ。ゲリラ調査じゃ！
staDate ◯： endDate ☓ / finDate ☓
opnDate ◯： clsDate ☓ / closeDate ☓
birthDate ☓： deathDate ◯
startDate ◯ ： finishDate ◯
おお、よっしゃ、適当なの見つけた。大変な作業であった。もうコレで行こう。こんなことにカマってばかりいられない。
しかし、打ちひしがれるタビに、解決への糸口発見が上手になってマスけど。うれしいか？＞自分