同じことを考える人はいるものだなぁ - しんさんの出張所はてなブログ編

http://d.hatena.ne.jp/itoasuka/20090325/1237975683

おいらが以前に独自のフレームワークに組み込んだりT2やCubbyにも導入したいいったのはこれとにったようなやつのことです。

値のセット時に例外を出せばそれでバリデーションの完成。ただし、そこのサンプルにあるようなたんなる実装クラスではなく、Generics使ってStringだったりIntegerだったりBigDecimalだったりを格納していました。

そしてString以外で重要な、String以外を入れたので入力ミスですよ、といって戻す場合に必要なStringとしての入力項目もそのまま保持しています。分かりやすくいえばコンバート前とコンバート後をもってるんですね。

また、このコンポーネント自体にバリデーションの結果も保持していてエラーがあった場合のメッセージ等もここからすぐに取得することが出来ます。実際の業務ではまとめて上のほうにエラーを並べて表示ということも確かにありますが、入力ミスがある箇所の隣などに適切にメッセージを出すことも非常に多いために、ここにメッセージをすぐに出せると良いと思ったためでした。

例えばInputFieldみたいな感じで、textプロパティが入力に使ったテキストそのものを保持して、valueが型パラメータでうけとったIntegerを保持、変換に失敗すればvalidプロパティがfalseを返す、messageプロパティが検証エラーがあった場合のメッセージを保持するといった感じです。独自の検証ロジックが必要な場合はオーバーライドすればよいと。

JSPで使う場所はこんな感じですね。

<input type="text" name="hoge" value="${hoge.escapeText}">${hoge.escapeMessage}

エスケープさせるのもだるいのでエスケープ後のメッセージや書式も用意してみたりとか。

とにかく文字列で保持して、それが数値に変換できるかどうかとかの検証を設定するというのが個人的にだるいんですね。数値型ならば数値型で最初から保持していればいいじゃないかと。ただし、変換の失敗や検査の失敗もあるから変換前等の入力した文字列そのものも用意しておく。

まぁ頭の悪いおいらはこの程度しか考え付きませんでした。軽く触ってみた感じでは特に問題はなく、動作が分かりやすかったです。複数の値をみて検証する場合にそこではじめてそれぞれのフレームワークのバリデーションを使えばよいという感じで。Cubbyはわりかし差し込めるポイントがあったと思いました。Strutsはアクションフォームへの値のセットの動作の差し替え方法がわからなかったので（調べてすらいないというだけかも）単純にアダプタかましたほうがよいという感じでした。

でも一番楽なのは画面遷移自体が起こらないAjaxで処理してしまうことだったりするのに気がついてからちょっとだけやる気がなくなったというか。ICEFacesはコンポーネント化もすすんでいますしあれはほんとすごい。後軽く触った感じではCubbyはAjaxと思ったより相性よさげですね。@OnSubmitが通常のフォーム送信だとイマイチだと思いましたがURLがどうにでもなるAjaxだと気にならないというか、むしろこっちを推奨というか。