03.Struts2の設計と設定のルール

概要

Struts2に限らず、フレームワークを使用するということは、使用するフレームワークの流儀に従わなければなりません。

Struts2にも全体を通した設定の考え方やルールがあります。

それを知っておくことで、設定に関してやりたいことがあるときに助けになるかもしれません。

ここでは、全体を通したルールを見ていこうと思います。

設定のルール

WEB構成の設定にはどのような方法があるのか

Struts2では、URLのパスと画面処理(Action)と結びつけるWEBの構成のような設定はいくつか方法があります。

以下、箇条書きにしてみようと思います。

・struts.xmlファイルに記述することができます(Struts1での設定ファイルに近いものです)

・設定ファイルに記述せずに、パッケージの構成をURLのパスの構成と合わせる方法があります。(ゼロコンフィギュレーション)

・Actionクラスのメソッドの前に、アノテーションでURLのパスを記述することができます。

全てを混ぜて使用することもできます。

設定の自由度はかなり高くなっています。

そういう意味では、上記のいずれか、もしくはいくつかを選択して設定方法を考えることがルールですが、あまりルールがありません。

節操なくまぜこぜに使用すると後で動作を追うのが大変になりますので気をつけなければなりません。

WEB構成以外の設定について

WEBの構成以外の設定については以下のようなものがあります。

・妥当性チェックの設定 (XXX-validation.xml、もしくはアノテーション)

・パラメタからPOJOへの変換の設定 (XXX-conversion.properties、もしくはアノテーション)

・メッセージリソースの設定 (messages_ja.properties、もしくはアノテーション)

設定の構成の共通したルール

上記で、どのような設定ファイルやアノテーションがあるのかを見ました。

そして、全てに適用されるわけではありませんが、おおよその共通ルールがあります。

以下のようなものです。

共通ルール1:

設定には、グローバルとローカルがあり、グローバルの値をローカルの値で上書きできる。

共通ルール2:

グローバルの設定ファイルはクラスパスのルートに置き、ローカルの設定ファイルは関係するクラスと同じpackage階層に置く。

(struts.xmlはこのルールの対象外です。)

これらのルールを知っていれば、もっと個別の設定はできないのか?と思ったときに、ローカルの設定をする方法があるのでは?

と考えることができます。

そうすると、その方向性で調査することができます。

軽く頭の片すみに置いておいてもらえばと思います。

このあと、サンプルを見て行きます。

全体的な設定のサンプル

ここでは、設定ファイルで設定をするときの共通ルールを具体的に見て行きます。

ですので、他の方法では例えば、アノテーションによる方法に置き換わるイメージで見てもらえればと思います。

ただし、グローバルな設定はどれでも設定ファイルになります。アノテーションなどで置き換えられません。

【構成サンプル】

<srcの構成の説明>

<WebContentの構成の説明>

※themeは、指定のHTMLへ変換できるテンプレートのようなものです

設計のルール

Struts2では、なるべく設定量を少なくなるように考えられています。

ですが、そのためにルール(convention)があり、ある程度やり方が制限されることもあります。

最初の内に設計のルールを知っておくと、割と楽にStruts2を導入できるかと思います。

ここでは、大まかにそのルールを見ていきます。

画面と画面処理(Action)の関係

画面からパラメタがsubmitされると、基本的には、Actionクラスがパラメタ値を受け取って、

Actionクラスのうちの1つのメソッドが呼び出されます。

画面と画面処理の関係については、以下のような設計が可能です。

<複数の画面に1つのActionを結びつけるパターン>

複数画面に対して、画面処理(Action)を1つに対応させることができます。

<1つの画面に1つのActionで、複数submitボタンから呼び出しするパターン>

画面1つに、submitボタン毎にメソッドを対応させることができます。

<画面とActionを1対1にするパターン>

1画面に対して、画面処理(Action)を1つ対応させることができます。

<画面とJSPを1対1にするパターン>

1画面に対して、Actionを介さずに直接1つのJSPに対応させることができます。

上記を混ぜて同時に使用することもできます。

具体的にこれらをどのように設定すれば実現できるかは、次の記事で記述しますので、ご確認いただければと思います。

ここでは概念だけ触れるにとどめます。

妥当性チェックとの関係

上記のように、割と自由に画面とActionの処理メソッドを結び付けられますが、妥当性チェックについてはそうはいきません。

妥当性チェックの設定の最小単位は、Actionになります。

ですので、Action1つに対して、妥当性チェックの設定は1つしか用意できまません

1つのActionで複数の画面を処理できるので、場合によっては、処理メソッド毎に別の妥当性チェックを使用したいこともあると思います。

しかし、それはできないのです。

ただし、処理メソッド毎に妥当性チェックをon/offすることはできます

以上のことからルールは以下のようになります。

妥当性チェックの内容が違う画面は、Actionを分ける必要がある。

(ただし、妥当性チェックを実行するかどうかだけの違いであれば分ける必要はない)

【補足】

実はアノテーションによる妥当性チェックでは、1つのAction内でも、処理メソッド毎に妥当性チェックをかけることもできるようです。

ドキュメントを読んだだけで試していませんが、ValidationInterceptorのvalidateAnnotatedMethodOnlyをtrueにするようです。

http://struts.apache.org/2.3.1/docs/validations-annotation.html

しかし、そうすると、ファイルによる妥当性チェックやActionクラスのvalidate()メソッドが呼ばれないそうです。

とりあえず、上記のルールを把握していれば、割とすんなり導入できるかと思います。

Created Date: 2012/01/21