🧭 はじめに
前回（Vol.9.3）では、XMLによるバリデーション定義と input 遷移の基本パターンを紹介しました。
今回はもう一歩踏み込んで、以下のようなケースに対応する方法を解説します：
-
条件付きバリデーション（例：チェックボックスONのときだけ必須）
-
複数フィールドの連携チェック（例：パスワードと確認用パスワードの一致）
これらのチェックは、Struts2の Javaコード側（validate()メソッド） を活用することで柔軟に実現可能です！
✅ よくある実務シナリオとその実装方法
1. 条件付きバリデーション（例：ある項目がONのときだけ他を必須）
@Override
public void validate() {
if ("1".equals(isReceiveMail) && (email == null || email.isEmpty())) {
addFieldError("email", "メールアドレスは必須です（受信希望の場合）");
}
}
-
状況に応じて入力必須かどうかを制御できます。
-
XMLではこうした「動的判定」が難しいため、
validate()側が最適。
2. 複数フィールドの連動チェック（例：パスワード確認）
@Override
public void validate() {
if (password != null && !password.equals(confirmPassword)) {
addFieldError("confirmPassword", "パスワードが一致しません");
}
}
-
こちらもXMLでは不可能な処理です。
-
「単一項目ではなく、複数項目をまたぐチェック」は Java 側で対応しましょう。
💡 実際のプロジェクトでの活用例（GitHub）
🔗 LoginAction.java（GitHub） の validate 実装（57〜76行目）
ここでは、正規表現を含む複雑な条件を validate() 内で実装しています。
✅ XMLで対応できない条件は、Javaの validate() に柔軟に分担させる
＝ いわゆる “ハイブリッド運用” が実務的でおすすめです！
📝 補足Tips：共通化はすべき？
-
validate()は画面ごとに個別実装されることが一般的です。 -
BaseAction などで共通化しようとしても、画面によって項目名・ルールが異なるため難しいケースが多いです。
-
逆に「共通チェック」だけを別メソッド化して呼び出すスタイルはアリ。
📚 まとめ
| チェック種別 | XMLで可能 | Javaで可能 | 備考 |
|---|---|---|---|
| 単純な必須チェック | ◎ | ◎ | XMLがシンプル |
| 正規表現チェック | △（一部不可） | ◎ | regexパターンによっては不可 |
| 条件付きチェック | × | ◎ | Java一択 |
| 複数フィールド連携 | × | ◎ | Java一択 |
🧭 次回予告：Vol.9.5
次回は、入力チェックエラーの表示デザインや
ユーザ体験を高めるための <s:fielderror> カスタマイズ について紹介予定です！
🔗 関連リンク
🔎 Vol.9系で扱うトピック
| 回 | テーマ | 内容の一部紹介 |
|---|---|---|
| 9.1 |
validate()メソッドの基本 |
Struts2標準の入力チェック基礎 |
| 9.2 |
@Validations アノテーション活用 |
宣言的バリデーション設計 |
| 9.3 |
validation.xml 外部定義でのバリデーション |
大規模PJでのメンテナンス性 |
| 9.4 |
conversion.properties と型変換 |
日付/数値/Enum変換の実務対応 |
| 9.5 | 入力エラー時のメッセージ制御 |
addFieldError() / メッセージキー運用 |
| 9.6 | バリデーション共通化 | 共通部品によるDRY設計 |
| 9.7 | サーバサイドとクライアントサイドの協調 | jQueryやHTML5との併用戦略 |
| 9.8 | 実務シナリオでのバリデーション総仕上げ | 会員登録/投稿処理などの実例適用 |
| 9.9 | バリデーション処理の単体テスト編 | validate()／独自バリデータ／input遷移の検証を網羅的に |
| 9.10 | エラー表示のUIデザイン編 | 視認性・操作性を高める実践テクニック |
| 9.11 | Ajax×バリデーション連携編 | クライアント×サーバーで UX＆保守性を両立するハイブリッド構成 |