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


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

結果出力ページの処理

　それでは最後に、クライアントへの出力を返す方法を解説しよう。

　List 7に示したKeijiWriteActionクラスでは、エラーが発生した際の処理を次のように構成している。

40： catch (SQLException e)
41： {
42： // エラー
43： getServlet().log("DB Error", e);
44： ActionErrors errors = new ActionErrors();
45： errors.add("dberror.msg",
46： new ActionError("dberror.msg", e.toString()));
47： saveErrors(request, errors);
48： }

　Strutsを使ってエラーをユーザーに伝える方法には幾つかがあるが、上記のようにActionErrorsオブジェクトとActionErrorオブジェクトを利用することが多い。ActionErrorsオブジェクトは、ActionErrorオブジェクトを含むコレクションだ。エラーメッセージを作る場合には、44行目にあるようにActionErrorsオブジェクトを作る。

44： ActionErrors errors = new ActionErrors();

　そして、ActionErrorsオブジェクトのaddメソッドを利用してオブジェクトを必要なだけ追加すればよい。

45： errors.add("dberrormsg",
46： new ActionError("dberror.msg", e.toString()));

　addメソッドの第1引数は、フォワード先のJSPページから参照できるエラー定義名となる。これはどのような文字列でも構わない。さらに第2引数へは、ActionErrorオブジェクトを渡す。ActionErrorオブジェクトのコンストラクタの第1引数は、エラーメッセージを示すリソース名だ。このリソースは、「application.properties」ファイルに記述する。

　ここでは、「dberror.msg」を指定しているので、application.propertiesファイルにdberror.msgという定義をあらかじめ設定しておく必要がある。


どこにリソースが書かれるのかは、struts-config.xmlファイルのmessage-resources要素で決定される（第1回目を参照）。

　注意したいのは、struts-blank.warファイルを展開した際の構造では、application.propertiesファイルが、WEB-INF/src/java/resources/ディレクトリと、WEB-INF/classes/resources/ディレクトリの両方にあるという点だ。実際に実行時に利用されるのは、WEB-INF/classes/resources/ディレクトリに置かれているほうだ。

　しかし開発時には、WEB-INF/src/java/resources/ディレクトリに置かれたapplication.propertiesファイルを編集する。その理由は、application.propertiesファイルがUnicodeで記述する必要性があるためだ。そこで、開発時には、WEB-INF/src/java/resources/ディレクトリに置かれたapplication.propertiesファイルをEUCなどのコードで記述し、コンパイル時に、Unicode変換したものをWEB-INF/classes/resources/ディレクトリにコピーする、という方法を採る。

　そのため、WEB-INF/src/java/resources/ディレクトリに置かれたapplication.proiertiesファイルには、List 8の定義を加えておく必要がある。

List 8■application.propertiesファイル
1： # 下記の行は、どこに書いても構わない
2： dberror.msg = データベースエラーです。処理を継続できません：{0}

　上記、2行目最後の「{0}」は、実行時に埋め込むメッセージ位置を示すプレースホルダだ。46行目では、次のように「SQLExceptionオブジェクト」を文字列化したものを指定している。

45： errors.add("dberrormsg",
46： new ActionError("dberror.msg", e.toString()));

　そこで、「dberrormsg」という名前が付けられたエラーメッセージは、「データベースエラーです。処理を継続できません：実際のエラーの文字列」のように構成されるのだ。


ここでは、例のため、e.toString()を埋め込み、例外の文字列を埋め込んでいるが、セキュリティ上の理由から、ユーザーに見せるエラーメッセージには、例外のメッセージは含めないほうがよい。

「{0}」表記のプレースホルダーは、{0}、{1}、{2}、{3}、と最大4つまで指定できる。これらは、それぞれ「ActionError」オブジェクトコンストラクタの、第2引数、第3引数、…に対応する。

　ここでは、ActionErrorsオブジェクトにひとつしかActionErrorオブジェクトを追加していないが、必要があれば複数回「addメソッド」を呼び出し、複数のActionErrorオブジェクト――すなわちエラーメッセージ――を構成することもできる。ActionErrorsオブジェクトを構成した場合、最後にsaveErrorsメソッドを使ってエラー保存をする。この際、第1引数に渡すのは第3引数として受け取った「HttpServletRequestオブジェクト」だ。

47： saveErrors(request, errors);

　これにより、フォワード先のJSPページで設定したActionErrorsオブジェクトを参照できるようになる。

　ちなみにActionErrorsオブジェクトと似たものに、「ActionMessagesオブジェクト」がある。使い方は同じだが、ActionMessagesオブジェクトは、クライアントに返したい、エラーではなくメッセージ群を設定したい場合に用いるものだ。

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

[大澤文孝，ITmedia]