StrutsのXML地獄から開発者を解放するSAStruts：Java初心者が超俊敏にWebアプリを作る方法（2）（3/3 ページ）

» 2008年11月27日 00時00分公開

[新田智啓，株式会社パワーエッジ]

【2】Actionのクラスの定義（利用するFormの設定）

　これもSAStrutsでは定義文を書く必要はありません。Formと同様に「action」パッケージの配下に「XxxxAction」という命名規約のクラスを作っているだけで自動的にActionで使用するものとして定義されます。

●実行するURLを設定実行するURLを設定

　Strutsのstruts-config.xmlでは、「path」属性（実行するURL）を設定していますが、SAStrutsはで、これをどのように参照しているのでしょうか。WebからURLでの実行対象にするのは、以下の2つで、この情報からURLを組み立てます。

クラス名は「XxxxAction」とする
実行されるメソッドに@Executeアノテーションを付加する

@Execute(validator = false)

          public String list() { 

          

          …【略】… 

          

          }

　@Executeアノテーションの属性として、Formをバリデーションしない場合は、「validator=false」とする必要があります。バリデーションについての詳しい解説は次回行います。

　まず、JSPが格納されるフォルダ名は「XxxxAction」のクラス名から「Action」を除いて小文字にした名前です。ここでは「DeptAction」なので「/dept」です。次に、メソッド名が付加した名前を併せてURLになります。DeptActionクラスの「list」メソッドが実行されるときのURLは「/dept/list」です。

　組み立て条件をまとめると、以下のようになります。

　actionパッケージ配下にある「パッケージ名」

          ＋「Actionのクラス名から"Action"を除いて小文字」

          ＋「@Executeアノテーションの付いたメソッド名」

　もし、actionパッケージ下に「test」というパッケージを作ってその中にDeptActionクラスを入れたとすると、URLは「http://localhost:8080/【プロジェクト名】/test/dept/list」となります。

　しかし、前回の一覧ページ参照では、URLの「/dept」の後には何も付けませんでした。これでは、実行メソッドが指定されていません。そのようなときは、URLから判別できるActionクラスが存在し、その中に「index」メソッドが宣言されて、@Executeアノテーションが付いていれば、自動的にindexメソッドが呼ばれます。そのindexメソッドが内部的にlistメソッドを呼んでいたので、「/dept/list」と指定することなく「/dept」でデータ一覧が表示できました。

●利用するFormを設定

　Actionクラスでは、もう1つ定義しているものがあります。利用するFormクラスの設定です。SAStrutsでは、DeptActionクラスのメンバ変数に以下のように宣言され、アノテーションで「@ActionForm」を付加すると、このActionで使用するFormを指定できます。

@ActionForm

          protected DeptForm deptForm;

　これで、このActionクラスはDeptFormを利用するという設定がされます。実際に利用する変数から利用するFormを自動的に定義してくれるのです。

　このときFormのメンバ変数名は、XxxxFormの先頭を小文字にした名前にする必要があります。つまり、DeptFormでは、「deptForm」という名前で変数を宣言する必要があります。

【3】Actionから画面の遷移先の定義

図5　JSPのルートフォルダの中身

　この設定も特に定義は必要ありません。先に指定した@Executeアノテーションを付加したメソッドでの戻り値で表示したいJSPののURLをStringで返してあげると、自動でマッピングしてくれます。選択されるJSPは「/」でURLを開始する形で指定すると、絶対パスで指定できます。JSPのルートフォルダは「view」フォルダです。

　Deptの一覧を指定しようとした場合、「/dept/list.jsp」と指定できます。Doltengで作成したDeptActionでは、相対パスでJSPへのURLを指定しています。相対パスでは、「list.jsp」とするだけでactionパッケージ配下にある「パッケージ名」＋「Actionのクラス名から“Action”を除いて小文字」の部分がURLとして付加されます。

　ここではパッケージがないため、DeptActionを変換してdeptをURL付加文字列として判断し、最終的に「/dept/list.jsp」となります。

リクエストからの値セット対象にしないようにする@Resourceアノテーション

　1つ使用していないアノテーションが残ってしまいました。@Resourceアノテーションです。

　@ActionFormが宣言されていない場合、Actionクラス自体のpublicなメンバにリクエストのパラメータがセットされます。しかし、そのままでは業務処理ロジックを利用するために、宣言したServiceなどのメンバに対してリクエストパラメータを登録しようとしてしまい、不正な動きをしてしまいます。

　今回のケースでは、もし「public DeptService deptService;」と宣言すると、リクエストパラメータに「deptService=1」というデータが来た場合、deptServiceに1をセットしようとしてしまいます。

　これを回避して、リクエストにServiceクラスなどDIされるものがリクエストパラメータに上書きされないようにするためには、protectedでメンバ変数を宣言します。リクエストパラメータのマッピング対象にならないようにしたうえで、@Resourceアノテーションを付加してSeasarからのDI対象にしています。

@Resource

          protected DeptService deptService; 

          @ActionForm

          @Resource

          protected DeptForm deptForm;

　ここで@Resourceアノテーションを使用している理由は、DIされるメンバ変数とリクエストからマッピング対象となり得るメンバ変数を正しく処理するためです。

SAStrutsならStrutsの経験を十二分に生かせる

　今回は、SAStrutsのプロジェクトの構成とStrutsのアクションやフォームの設定方法の比較を紹介しましたが、いかがでしたでしょうか。Strutsで仕方なく書いていた設定ファイルをまったく書かずに動作するSAStrutsを理解していただけたかと思います。

　ActionクラスやFormクラスがたくさんあって、設定ファイル地獄だったStrutsプロジェクトはありませんか。ファイル管理で上書してしまったり、ファイルバージョン管理していても競合がたびたび起こったりしていませんか。

　そういった場合にSAStrutsを使うと、これらの問題をすべて解決して、少量のコードを書くだけで柔軟に対応できます。アノテーションを使うようなコードを書いますが、Strutsの“流れ”はくんでいるため、Strutsの経験を十二分に生かせるはずです。また、Strutsは開発経験者が多いため開発メンバーも集めやすく、プロジェクトマネージャの方々にとっても安心なプロダクトだと思います。一度利用を検討してみてはいかがでしょうか。

　次回は最後に残った設定ファイルの中のバリデーションについて、SAStrutsとStrutsの比較をメインに解説したいと思います。

参考資料
▼Seasarプロジェクト
▼SeasarプロジェクトEclipse Plugin
▼SAStruts