| エンタープライズ：特集 | 2003/11/28 15:30:00 更新 |
特集：第2回 実用サンプルコードで理解する「Struts」の基礎 (2/15)
掲示板書き込みを担う4つの要素を押さえる
掲示板への書き込みでは、次の4つの要素を扱う。後々までこのファイル名が出てくるため、働きを理解しておいてほしい。
1. 「KeijiWrite.jsp」ファイル
「KeijiWrite.jsp」ファイルは、掲示板投稿の入力フォームとなるJSPページだ。Fig.2に示すレイアウトで作り込む。
2. 「KeijiWriteForm」クラス
「KeijiWriteForm」クラスは、「ActionForm」のサブクラスとして定義したものだ。ここでは、入力フォームに入力されたデータを保持する機能を持たせる。
3. 「KeijiWriteAction」クラス
「KeijiWriteAction」クラスは、Actionのサブクラスとして定義したものであり、「2」が実体化された「KeijiWriteForm」オブジェクトが保持するデータを読み取り、データベースに掲示板投稿データそのものを書き込む処理を担う。
4. 「KeijiWriteSuccess.jsp」ファイル
結果を表示出力するJSPページコードファイルだ。Fig.3のように、「投稿「●●」を書き込みました。」と結果を表示する。ただし、データベースへの書き込みにエラーがあった場合には、その旨のエラーメッセージを表示する仕組みも作り込む。
掲示板からの読み込みには入力フォームが必要ない
掲示板からの読み込みでは、入力フォームを利用しない。そのため、入力フォームとなるJSPファイルと、ActionFormは不要であり、処理をするActionサブクラスと結果を出力するJSPページのみで構成する。
1. 「KeijiReadAction」クラス
このクラスは、Actionサブクラスとして構成する。データベースから掲示板のデータを読み込み、コレクションとしてデータを保持、そして結果表示の「KeijiReadSuccess.jsp」ファイルへと渡す。このクラスは、URLとして、「/Read.do」で呼び出せるよう、struts-config.xmlファイルで構成することにする。
2. 「KeijiReadSuccess.jsp」ファイル
ページ出力表示を行うJSPソースコードファイル。上の「1」から受け取ったコレクションデータを読み取り、ユーザーに掲示板データをFig.4のよう一覧表示させる役目を担う。ただし、データベースからの読み込みにエラーがあった際、その旨のエラーメッセージを表示するものとする。
ファイルの配置場所と遷移は最初に考慮しておいた方がよい
これ以降、上記で挙げた仕様でアプリケーションを作っていく。コード自体に触れる前に、ファイル自体を保存するフォルダ（場所）について確認しておこう。
今回は、「/home/struts-keiji/」というディレクトリにWebアプリケーションを構築していく。このディレクトリには、Strutsに含まれる「struts-blank.war」ファイルをあらかじめ展開しておく。この基礎手順については、前回説明した通りだ。/home/struts-keiji/ディレクトリ下には、Fig.5のようにファイルを構成するものとする。
Fig.5には、struts-blank.warファイルを展開すると得られるフォルダ（ディレクトリ）構造、およびファイルのうち、この記事で新規作成するものをリスト内で黄色に（図Fig.5内では赤色）、すでに存在するが編集必要なものについてを緑色で示していく。
上図、Fig.5内で示したように、ポイントとなるのは次の通りだ。
- Javaソースコードファイルの配置場所
Strutsによって（というよりも、Tomcat4によって）実際に実行されるJavaクラスファイルは、WEB-INF/classes/ディレクトリやWEB-INF/classes/lib/ディレクトリに置かれたファイル群だ。そのため、動作の原理的には開発中のJavaソースファイルをどこに配置しても構わない。しかし、Strutsで開発する場合には、JavaのソースファイルをWEB-INF/src/java/ディレクトリに置くのが望ましい。その理由は、次の通りだ。
Struts開発の雛形となるstruts-blank.warファイルを展開すると、WEB-INF/src/ディレクトリに「build.xml」という名でファイルが作成される。このbuild.xmlファイルは、後述する「Ant」ツールを使いビルドするための設定ファイルとなる。
このbuild.xmlファイルには、WEB-INF/src/java/ディレクトリに置かれたソースファイルをビルドし、WEB-INF/classes/ディレクトリに配置するという設定内容が含まれる。そのため、ソースファイルをWEB-INF/src/java/ディレクトリに置けば、ツール「Ant」を使うことでコンパイルの手間を大幅に省けるのだ。
- 結果出力するJSPファイルの位置
ActionサブクラスからフォワードされるJSPページは、特定のディレクトリにまとめておくのが望ましい。ここでは、pages/ディレクトリ下に、KeijiWriteSuccess.jsp、KeijiReadSuccess.jspファイルとして配置している。その理由は、Actionサブクラスからのフォワードではなく、ユーザーによって直接これらのJSPファイルを呼び出されてしまう問題を避けるためだ。
例えば、Fig.1に示したように、KeijiReadSuccess.jspファイルは、KeijiReadActionサブクラスからフォワードされる。しかしユーザーが、「/pages/KeijiReadSuccess.jsp」宛のURL要求をしてきた際、KeijiReadActionサブクラスを介すことなく直接KeijiReadSuccess.jspファイルが実行されてしまう。その結果、予想外のエラーが発生したり、セキュリティ上の問題となる可能性が否めないのだ。
そこで、フォワードされるJSPページは特定のディレクトリに配置し、ユーザーが直接アクセスできないよう制限すべきだ。ここでは「pages/」ディレクトリに置いていることから、この階層をユーザーがURL指定要求できないよう設定しよう。特定のディレクトリを見せない具体的な手法は、「web.xml」ファイルでsecurity-constraint要素を編集すればよい。web.xmlファイルをList 1のように編集すると「/pages/」下を隠すことが可能だ。
List 1■pages以下のディレクトリを見せないようにするためのweb.xmlファイル設定|
1： 〜略〜 2： <web-app> 3： 〜略〜 4： <security-constraint> 5： <web-resource-collection> 6： <web-resource-name>disableaccess</web-resource-name> 7： <url-pattern>/pages/*</url-pattern> 8： </web-resource-collection> 9： <auth-constraint> 10： </auth-constraint> 11： </security-constraint> 12： 〜略〜 13： </web-app> |
上に挙げた「security-constraint」要素は、特定パスに対してアクセス認証を設定するためのものだ。制限するパスは、「urlpattern」要素で指定する。List 1では、次に抜粋する7行目にあるように、「/pages/*」というパス指定をしている。
| 7： <url-pattern>/pages/*</url-pattern> |
そしてアクセス可能なユーザーは、auth-constraint要素のなかに、role-name要素を利用して指定する。List 1では、auth-constraint要素にひとつもrole-name要素を含めていないため、「誰もアクセスできない」ことを示す。
|
前のページ | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 次のページ
[大澤文孝，ITmedia]
