エンタープライズ:特集 2003/11/28 15:30:00 更新


特集:第2回 実用サンプルコードで理解する「Struts」の基礎 (2/15)

掲示板書き込みを担う4つの要素を押さえる

 掲示板への書き込みでは、次の4つの要素を扱う。後々までこのファイル名が出てくるため、働きを理解しておいてほしい。

1. 「KeijiWrite.jsp」ファイル

 「KeijiWrite.jsp」ファイルは、掲示板投稿の入力フォームとなるJSPページだ。Fig.2に示すレイアウトで作り込む。

fig02.gif

Fig.2■掲示板投稿の入力フォーム(KeijiWrite.jspで生成するページ)


2. 「KeijiWriteForm」クラス

 「KeijiWriteForm」クラスは、「ActionForm」のサブクラスとして定義したものだ。ここでは、入力フォームに入力されたデータを保持する機能を持たせる。

3. 「KeijiWriteAction」クラス

 「KeijiWriteAction」クラスは、Actionのサブクラスとして定義したものであり、「2」が実体化された「KeijiWriteForm」オブジェクトが保持するデータを読み取り、データベースに掲示板投稿データそのものを書き込む処理を担う。

4. 「KeijiWriteSuccess.jsp」ファイル

 結果を表示出力するJSPページコードファイルだ。Fig.3のように、「投稿「●●」を書き込みました。」と結果を表示する。ただし、データベースへの書き込みにエラーがあった場合には、その旨のエラーメッセージを表示する仕組みも作り込む。

fig03.gif

Fig.3■投稿結果の出力(KeijiWriteSuccess.jspで生成するページ)


掲示板からの読み込みには入力フォームが必要ない

 掲示板からの読み込みでは、入力フォームを利用しない。そのため、入力フォームとなるJSPファイルと、ActionFormは不要であり、処理をするActionサブクラスと結果を出力するJSPページのみで構成する。

1. 「KeijiReadAction」クラス

 このクラスは、Actionサブクラスとして構成する。データベースから掲示板のデータを読み込み、コレクションとしてデータを保持、そして結果表示の「KeijiReadSuccess.jsp」ファイルへと渡す。このクラスは、URLとして、「/Read.do」で呼び出せるよう、struts-config.xmlファイルで構成することにする。

2. 「KeijiReadSuccess.jsp」ファイル

 ページ出力表示を行うJSPソースコードファイル。上の「1」から受け取ったコレクションデータを読み取り、ユーザーに掲示板データをFig.4のよう一覧表示させる役目を担う。ただし、データベースからの読み込みにエラーがあった際、その旨のエラーメッセージを表示するものとする。

fig04.gif

Fig.4■掲示板の一覧表示(KeijiReadSuccess.jspで生成するページ)


ファイルの配置場所と遷移は最初に考慮しておいた方がよい

 これ以降、上記で挙げた仕様でアプリケーションを作っていく。コード自体に触れる前に、ファイル自体を保存するフォルダ(場所)について確認しておこう。

 今回は、「/home/struts-keiji/」というディレクトリにWebアプリケーションを構築していく。このディレクトリには、Strutsに含まれる「struts-blank.war」ファイルをあらかじめ展開しておく。この基礎手順については、前回説明した通りだ。/home/struts-keiji/ディレクトリ下には、Fig.5のようにファイルを構成するものとする。

 Fig.5には、struts-blank.warファイルを展開すると得られるフォルダ(ディレクトリ)構造、およびファイルのうち、この記事で新規作成するものをリスト内で黄色に(図Fig.5内では赤色)、すでに存在するが編集必要なものについてを緑色で示していく。

fig05.gif

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要素を含めていないため、「誰もアクセスできない」ことを示す。


web.xmlファイルの定義によれば、auth-constraint要素自身を省略することもできる。しかしTomcat 4の場合には、auth-constraint要素自身を省略すると、正しく機能しない。

前のページ | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 次のページ

[大澤文孝,ITmedia]



Special

- PR -

Special

- PR -