ドキュメントに反映しました。

バリデーションコピーはgetRules()を使う方法だとフェーズごとのバリデーションをうまく表現できないので、DefaultValidationrules#addAll(ValidationRules)を追加して、#getRules()はdeprecatedに指定しました。

あとはドキュメントに反映させる

cubby r882
cubby-examples r883
で対応しました。
URIに埋め込まれたパラメータなどは、バリデーションの成否に関わらずフォームオブジェクトにバインドされていて欲しいです。(JSPの表示や画面遷移で使う場合があります)
なので、シーケンスは1.0と変えずに

• リクエストパラメータのバインド
• フェーズごとのバリデーション
• アクションメソッドの実行
  としました。

サンプルとして、cubby-examplesのtodo/action/LoginActionを参照してください。

フェーズごとのバリデーション
ValidationRule登録時に指定されたフェーズ(ValidationPhaseのインスタンス)ごとにバリデーションを順次実行し、そのフェーズ内でエラーがあった場合は次のフェーズのバリデーションは実行せずにエラーページへと遷移します。

定義済みのフェーズとして、以下の2つを DefaultValidationRules に追加しました。

• データ型を検証するフェーズ (DATA_TYPE)
• データ上の制約を検証するフェーズ (DATA_CONSTRAINT)
  RequiredValidatorなどは DATA_TYPE、ユーザーが定義する相関チェックやテーブルを参照するようなバリデーションは DATA_CONSTRAINT を想定しています。

フェーズはValidationRules#getValidationPhases() をオーバーライドすることでカスタマイズできます。

また、ValidationExceptionを追加しました。
アクションメソッド中でこの例外がスローされるとエラーページへ遷移します。

>これ素朴な疑問なんですが、バインドの動きをオーバーライドしたい場面ってありますかね？
バインドのとことRequestParserでパースしてるところ、そのあたりをオーバーライドできるとRESTでapplication/atom+xmlみたいなブラウザ以外からのリクエストに対応しやすくなるかもなー、っていうくらいですね。
RESTについて詳しくないんでなんとも言えないんですが、どうなんでしょうか？

それと、バリデーションを途中でやめたい場合もあると思うので、ある例外が投げられたらバリデーションを中断してエラーページへ遷移する、っていう動きもつけたいですね。

検証の2回に分けてやるのは賛成です。本来そういう動きが正しいと思いますので。

>1.のほうが、Actionのサブクラスでバインドの動きをオーバーライドできたりするのでよいかなー

2が普通ありそうな実装方法ですよねー。
これ素朴な疑問なんですが、バインドの動きをオーバーライドしたい場面ってありますかね？

実装する方法は２つを考えました。

1. リクエストパラメータからフォームオブジェクトへバインドする部分をAction抽象クラスに移動してメソッドを作成し、そこをValidationInterceptorでフックしてバインドメソッド実行の前後でバリデーションを実行する。
2. Interceptorを増やす
   • アクションの初期化Interceptor
   • バインド前バリデーションInterceptor
   • リクエストパラメータをフォームオブジェクトにバインドするInterceptor
   • バインド後バリデーションInterceptor
   • アクションメソッドを実行するInterceptor

2.のほうはフレームワークとしては柔軟な気がしますが、1.のほうが、Actionのサブクラスでバインドの動きをオーバーライドできたりするのでよいかなー、と思ってます。

みなさん、ご意見をください。