バリデーションを XML でやりたいって言う人が居るけど、何故 XML を使う必要があるのか良く分からない。メリットが分からない。
- カバレッジを取得する必要が無くテストを省略出来る。………これは特殊な条件下で使える屁理屈的な言い訳みたいな物でしかない。客にカバレッジを求められていて、XML だと無理だからって後工程にテストを委ねられるっていう糞みたいな理由。そんな理由が通るんだったら java でバリデーションを書いたとしても後テスト工程に回しても良いだろうが。大体カバレッジを取れないというのは普通に考えると欠点でしかない。
- XML は書き易い。XML は読み易い。XML は java よりも機能が制限されているから、色んな事が出来ないから読み易い。………これは微妙だ。本当にそうなのか。俺はそうは思わない。先ず文法を覚える必要がある。それに制約が多い故に柔軟に書けないというのが欠点になる。バリデーションを行う XML の文法によっては、はっきりと読み辛く書き辛いと言える物も存在する。コンパイルエラーも出ないし、javadoc のツールチップも出ないし、入力補完も出来ない。
- XML は javascript のバリデーションを生成する事も出来る。………これは割と大きなメリットではある。だけど javascript を色々と自前で書いてると、生成された javascript と連携が上手く行かなかったりする。それに XML によっては javascript 生成機能がそもそも無かったりする。
- XML は色々とバリデーションに関する機能を持っている。………これはメリットではあるのだけど、普通に java のライブラリを使えば済む事。大したメリットでは無い。
- XML は java に依存しない。………それはメリットかも知れないが、バリデーションだけ移植性を高める事に大した意味は無いだろう。
俺がお奨めするバリデーションの書き方は、やっぱりエクセルから java ソースを自動生成する事だね。それが一番良いと思うなあ。書き易く読み易い。javadoc 連携や入力補完連携は出来ないけど、それを補って余りある書き易さがある。コンパイルエラーも検出可能。カバレッジも取れる。差分は生成された java ソースもリポジトリにコミットする事によって検出可能。エクセル用の差分検出ツールを使っても良い。リポジトリのコンフリクト対策には必ずロックを取得する運用で対応する。java ソースを書き変える事によって簡単に機能追加が可能。自動生成ツールをカスタマイズする事によって、どんなエラー処理パターンにも対応が可能。エクセルで自動生成する範囲からは、バリデーションライブラリは対象外とする。バリデーションライブラリはサードパーティが作った物か自前で作った物を使い、エクセルの自動生成ツールはそれらを利用する様に作る。Grep や一括置換が出来ないかもなのはネックだけど、バリデーションに関してはそういうケースは殆ど無いと思ってる。生成された java ソースを検索して、修正は個々のエクセルファイルにやれば良いだろう。使い易いエクセル Grep ツールや一括置換ツールを探したり作るのもアリだろう。
違う話になるけど XML から Java の定数を参照し辛いって欠点もあるな。また違う話になるけどセッションフォームに対してバリデーションを行うと、純粋なリクエストパラメータ群に対してのバリデーションが出来ないんだよな、これは XML に限らない話。
