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 ◯
おお、よっしゃ、適当なの見つけた。大変な作業であった。もうコレで行こう。こんなことにカマってばかりいられない。
しかし、打ちひしがれるタビに、解決への糸口発見が上手になってマスけど。うれしいか？＞自分
「注文書を自動でＦＡＸ送信出来ないか？」とのご要望を頂きまして、過去サラリーマン時代の基幹システム(NEC ACOS-2)で実際に運用動作していたし、「っま可能ですよ。」と、ご回答しておきました。
で、具体的な案件はまだ決まっていないのですが、コレは他にも応用が利くので、実際に実装を意識しての調査やらテストやらを開始したワケです。
まず、要件として「基幹系システム（サーバー）は、対象となる注文データを、直接ＦＡＸを送ることはしないで、CSV形式でエクスポートするダケで、あとはソッチで何とかしてチョ。」となれば、サーバーを新規に建てずに、クライアントＰＣのwindowsアプリで行けそうだ・・・となり、エクスポートされるデータがマスタデータなどに依存しなければ、単純にデータを注文書（レポート）に整形し、各業者さん毎にＦＡＸ送信といったシンプルな処理で行けそうです。
で、最初にFaxModem（安価な中国製のclass1）を入手し、windows添付のFAXユーティリティーで送信テスト（懐かしいなぁ。こんなのCanBeでやったなぁ）。あっさり成功。
# 事務所には電話回線ないのですが、自宅にはISDN時代のナゴリで、局番の違う２回線があり、テスト環境は「偶然バッチリ」でした。
ＰＣはmodemに繋がったし、次はアプリを何で作るか？
最新はすっかりtomcatやらspringやらでjavaを使ってwebアプリ開発にイソしんでいたので「久しぶりにswing使ってjavaのクライアントアプリにしようか」と調査をしておりました。RS232C（これまた懐かしい）っまシリアル通信をjava.Communicationsでホホイと監視・制御することでmodemとやり取りし、そこら辺は意外と何とかなりそうだ・・・との感じ。しかし、肝心のＦＡＸ送信文書（イメージデータ）は、自力で白黒のドットの連続を作らねばならない模様・・・ああああ、面倒そうです。
ならば、これまた久しぶりのvisualBasicでwindowsアプリを作ったら・・・と、調査してみると、結構、簡単そうな感じ。早速、倉庫に眠っていたインストールディスクでＰＣに開発環境をセッティングし、サンプルを参考にホンの数行をコーディングし、テストしたところアッサリ成功。しかも予め作成しておいたPDFファイルを指定しただけで、イメージデータも特別な処理いらない。さらに例のwindowsのＦＡＸユーティリティーで送信関連の管理がメーラー感覚で出来るので、送信状況のモニタや、再送信や印刷への処理転換などの正常外処理もいらない。おおおお！！！！天国ですね。
この案件、意外と難航するカモ？と、今朝、仏壇のご先祖様に拝んでおいたのですが、すっかり目処が立ちました。戻ったらお線香をあげる心算です。