エンタープライズ:特集 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]



Special

- PR -

Special

- PR -