第Ⅰ編 例題

１．例題１

１．１ 概要

例題１は単純なwebアプリです。

処理のシーケンスは図１．１－１の通りです。

図１．１－１ 例題１のシーケンス図

（１） クライアントから要求１を送ります。

（２） その応答が戻ります。(応答１)

（３） 応答１の画面の入力項目を入力して要求２を送ります。

（４） 応答２が戻ります。

１．２ プログラムの構造

図１．２－１に処理の流れと関係するオブジェクトを示します。

図１．２－１ 処理の流れと関係するオブジェクト

図１．２－１の説明をします。なお、［］で囲んだ数字／記号は図中の四角で囲んだ数字記号に対応します。

［１］クライアントPCから要求１がAction1に入ります(四角に囲まれた１)。

要求１に付随する入力データはActionForm1が保持します。

Action1は必要な処理をし、その後、表示に必要なデータをDto1に設定します。

さらに、Dto1をHttpRequestに保存します。そのキーはtheDataです。

［２］Jsp1に移ります。

Jsp1はHttpRequestからDto1を取り出します。

Dto1に設定されているデータを画面に反映します。

［３］クライアントPCに戻ります。

［４］入力項目にデータを入れて、それを要求２としてサーバに送ります。それはAction2に入ります。

この後の処理の流れは要求１と同じです。ActionForm1、Dto1の代わりにそれぞれActionForm2、Dto2が対応します。

［５］Jsp2に移ります。

Jsp1はHttpRequestからDto2を取り出します。

Dto2に設定されているデータを画面に反映します。

［６］クライアントPCに戻ります。

実際のアプリでは、目的にする処理が完了するまで、(要求，応答)が繰り返されます。例題ではここから、（１）に戻るようにしています。

２．例題２

２．１ 概要

例題２は例題１を拡張します。Actionの処理をその中で閉じないでServiceに委託します。

「いいプログラム」であるためには、適切にクラスを分ける必要があります。この解説はクラスの分け方については触れません。分けた結果できるクラスへの制御の渡し方について説明します。

ActionがServiceに処理を委託するのがその第１段階です。

２．２ プログラムの構造

図２．２－１に処理の流れと関係するオブジェクトを示します。

図２．２－１ 処理の流れと関係するオブジェクト

例題１と違う点は、Serviceが追加された点です。これに伴って例題１と違う点だけ説明します。

［１ａ］ Action1からServiceを呼び出します。

例題２ではServiceで実質的な処理はしていません。渡された引数を戻り値として戻すだけです。

［４ａ］ Action2からServiceを呼び出します。

Action1の場合と同様、渡された引数を戻り値として戻すだけです。

ここで留意することは、Serviceの参照の取り方です。

例題では、ServiceのstaticなメソッドgetInstanceを使って取り出しています。この方法を使うと、Service を「どこでいつ具現化するか」という課題に悩まされません。その代わりにServiceとActionの結合が固定されます。別の方法については他の例題で説明します。

３．例題３

３．１ 概要

例題２を拡張します。

例題２のServiceの処理をDBアクセスを含む処理にします。例題では、そのうちの特殊な場合としてDBアクセスだけからなる処理です。これはあくまで例題で、実際のServiceはDBアクセスを含む処理になります。

DBアクセスを受け持つクラスとしてＤａｏクラスを追加します。Daoが処理を委託するクラスがありますが、これについては次の節で説明します。

３．２ クラスの構造

図３．２－１に処理の流れと関係するオブジェクトを示します。

図３．２－１クラス図

Actionの周辺は例題２と同じです。

DaoからDbAccessorに処理が委託され、さらにDataBaseに委託されます。

特徴は、各クラスは直列上に関連するだけで、飛び越して関連しないということです。このような構造は層構造と言われます。Webアプリでは、Service以降を層構造にすることが肝心です。

通常、DaoとDbAccessorの(インスタンスの関係ではなく)クラスの関係は１：１です。DbAccessorはDataSourceのクラスの関係は１：１です。したがって、DaoとDbAccessorの関係は委託でなく継承でもこなせます。DbAccessorとDataSourceの関係も同じです。

ただ、できる限り継承より委託が推奨されていますので、例題では委託を使っています。

例題３とこの後説明する例題４及び例題５は機能は同じです。異なる点は委託するために必要なクラスの参照の取り方です。

例題3では次の方法を使っています。

（１）Action：ServiceのstaticなメソッドgetInstanceを使います。

（２）Service：Daoを(Serviceの)コンストラクタの中で具現化します。

（３）Dao：DbAccessorを(Ｄａｏの)コンストラクタの中で具現化します。

（４）DbAccessor：DataSourceを(Ｄbａccessorの)コンストラクタの中で具現化します。

DbAccessorの中でDBのドライバ名、url、ユーザID、パスワードが必要です。この情報をDaoの中で固定的に設定し(ハードコーディングし)、Daoのコンストラクタの中でＤｂＡｃｃｅｓｓｏｒに設定しています。ＤｂＡｃｃｅｓｓｏｒはこのためのsetterを持っています。

３．３ 機能

（１）要求１の応答として、データを追加する入力フォームを表示します。参考にDBのテーブルのデータすべてを表示します。

（２）入力フォームにデータを入れて送信します。(要求２)

（３）要求２の応答としてDBのテーブルのデータすべてを表示します。

要求１の応答として表示される入力フォームを図３．３－１に示します。

図３．３－１ 例題の入力画面

この部分は、指定したプロパティによって変わります。この例は、プロパティがprefecture、pop1995、pop2000、pop2005、ratio、densityであることを意味しています。この例題では、各プロパティとDBのテーブルの列が対応する前提になっています。

例題のテーブルの列名は表３．３－１からなっています。

これと先に述べたプロパティを対応付けます。たとえば、ratioで入力したデータが人口性比の列の値になります。

入力データチェックはしていませんので、入力データの内容次第でデータは追加されないで終了する場合があります。エラーの内容はサーバ(tomcat)のコンソールをご覧下さい。

４．例題４

４．１ 概説

例題３と違う点は、図３．２－１に示したクラスからクラスへの委託の方法だけです。

４．２ Factoryパターンの利用

例題４は、委託に必要なオブジェクトの参照を得るためにFactoryを使います。

FactoryはJNDIのデータを参照します。JNDIは各オブジェクトに対応するクラスと必要なパラメタを設定してあります。

リスト４．２－１ JNDIを使ったオブジェクトの定義

DbAccessorを除くクラスは、Factoryのstaticなメソッドを使って必要なオブジェクトの参照を得ます。Factoryはそれらの参照をstaticブロックで設定します。

DbAccessorは直接JNDIを使います。技術的には他のクラスと同じようにFactoryを使えます。ただ、Factoeyは例題４に固有のクラスです。そのため、Factoryを使うとDbAccessorが例題４でしか使えないものになってしまいます。このため、DbAccessorは直接JNDIを使ってDataSourceの参照を取得する方式にしました。

この問題は一般のwebアプリでも起きます。DbAccessorは汎用的な機能を持っていますので、JNDIが使える環境に限定するのは得策ではないからです。もしくはすでに開発されているDbAccessor(相当のクラス)が利用できるかもしれません。このような場合は、Adapterパターンで解決する策があります。この例題でいえば、例題３で使ったDbAccessorをそのまま使うことにします。ただ、例題で使っているDbAccessorは小さいクラスですのでAdapterを作らないで、DbAccessorをJNDI用に書き換えました。一般のwebアプリではAdapterパターンを使う選択肢もあります。

JNDIでは、クラス名だけでなく、そのインスタンスに設定するプロパティ値も指定できます。DbAccessorのプロパティのDBのドライバ名、url、ユーザID、パスワードがそれに相当します。こうすることの具体的な得は、ソースを変更しないでDBMSを変更できるということです(*1)。

注 *1: 一般のアプリではSQLのDBMSベンダの方言に対応する必要があります。

５．例題５

５．１ 概要

例題３、例題４と違う点は、図３．２－１に示したクラスからクラスへの委託の方法だけです。

５．２ DI

例題５は、委託に必要なオブジェクトの参照を得るためにDIを使います。

ＤＩをサポートしたソフトウェア(例：Spring)を使うと簡単ですが、DIの学習を兼ねていますので、DIの処理も作ります。

Initializerで、図３．２－１に示したクラスのうちActionを除くクラスを具現化します。さらに、そのクラスを使うクラスに参照を設定します。

具現化するクラスとそれを使うクラスの具体的な名前は外部のpropertiesファイルで与えます。具体的なクラスの名前は外部から可変です。しかし、どの役割のクラスかはInitializerで固定されています。具体的には、ServiceとDao、DbAccessor、DataSourceです。前述のSpringを使うとこれらも含めて可変です。

Initializerはクラスを具現化して、その参照を必要なクラスに設定するだけでなく、プロパティも設定できます。この効用はJNDIの場合と同じです。

５．３ Initializer処理

INitializerの処理で特徴的な処理を二つ紹介します。

５．３．１ クラスの動的具現化

クラス名をソースに固定しないで、変数(文字列)で与えて具現化する方法です。

リスト５．３－１にそのコードを示します。

リスト５．３－１ クラスの動的具現化

注 必要な例外の処理は略しています。

このインスタンスを具体的に使うには、これはクラスではキャストできませんから(*1)、interfaceを使います。

注 *1:具体的なクラス名が分かっていれば、newで具現化します。

５．３．１ プロパティの設定

これもソース上でクラス名が明示されていないときの問題です。該当するクラスにプロパティを設定する必要がある場合に生じることがあります。

該当のプロパティのsetterがinterfaceに含まれていれば、クラスのインスタンスをinterfaceでキャストするとsetterが使えます。

該当のプロパティのsetterがinterfaceに含まれていない場合はキャストする方法は使えません。この場合は、JavaのReflection機能を使います。

リスト５．３－２ プロパティの設定

注 必要な例外の処理は略しています。

JavaのReflection機能は最小限にすべきですが、これは許される場合です。

６．例題６

６．１ 概要

例題６は例題５をベースにして、範囲を指定して検索する機能を付けます。これはtemplateGenLiteを使って、実際にwebアプリを作る簡単な例です。

これまでの例題１～例題５は第Ⅱ編 操作書に記述に従ってツールを使うと自動的に生成されます。自動生成されたものは実際のアプリにそのままでは使えません。しかし、自動生成されたものを母体にして開発すると、最初から作るより短時間で開発が出来ます。

この例題の目的は、これまでの例題を目的の仕様になるように変更する手順と、その手順が簡潔であることを示すことです。

例題６の仕様を説明します。

要求１に対して、図６．１－１に示す入力フォームが表示されます。テーブルの全データも表示します。これは参考のためのデータです。体裁についてはここでは考慮していません。

図６．１－１ 例題６の入力データフォーム

これに対応するプロパティとテーブルの列名の対応を表６．１－１に示します。

注 *1 －記号は該当する列又はプロパティがない意味です。プロパティがないということはアプリの中で処理の対象でないことを意味します。

   *2 複数選択できる

たとえば入力として1995年人口とその下の～のフィールドにデータが入力されると、それらはそれぞれプロパティpop1995Lとpop1995Hに設定されます。

６．２ 処理の流れ

具体的な処理の内容は例題５と異なりますが、構造と処理の流れは例題５と変わりません。次の5項目を変更すると目的の処理ができるようになります。この変更が定型的な手順であることが実際の開発で役立つ理由です。

（１） 画面 JSP1のform要素

（２） ActionForm2 入力項目を保持できるプロパティを持つbean

（３） Dto2 入力の内容をServiceに渡すbean

（４） Action2 入力を処理して、Serviceにさらなる処理を委託する。

（５） Dao 入力に応じてDBアクセスする

具体的なコードについて詳しく見ていきます。

６．２．１ 入力フォーム

リスト６．２－１は図６．１－１に対応する入力フォームのコードです。例題5の該当部分と入れ替わります。入力の型は、都道府県以外はtextです。都道府県はselectです。複数選択できるようにmultiple="multiple"を指定しています。

リスト６．３－１

６．３．２ ActionForm

表６．１－１のプロパティに対応するActionForm bean(抜粋)です。prefecturesは複数組のデータが入るのでStringの配列です。その他は文字型です。ActionForm2と入れ替わります。

リスト６．３－２ ActionForm2

ActionFormは入力フィールドに対応するプロパティを含むbeanです。

６．３．３ Dto2

Dto2はAction2の処理結果をServiceに渡すためのクラスです。次の項で説明するように、この例題ではAction2での実質的な処理はないので、Dto2の内容はActionForm2と変わりません。だからといって、Dto2の代わりにActionForm2を使う発想はよくありません。Dto2はwebアプリのコンテナやMVCフレームワークの影響を除く重要な役割があります。

具体的にいうと、Dto2はstrutsのActionFormを継承していないということです。一般のwebアプリではDto2の存在意義は他にもあるでしょうが、本例題では、この点だけです。

リスト６．３－３にDto2のコードを示します。

リスト６．３－３ Dto2のコード

６．３．４ Action2

ActionForm2でAction2に運ばれた入力データに必要な処理をします。さらなる処理をServiceに委託するため、その結果を別のbean(クラス)に設定します。Action2でする処理の主なものを次にあげます。

（１） MVCのフレームワーク(*1)に依存しないようにする。

ActionFormはstrutsのActionFormを継承していますのでstrutsの影響下にあります。一方ServiceとDaoはwebアプリ用の特定のコンテナやフレームワークに影響を受けてはいけません。仮にバッチ環境であってもServiceとDaoは使えなければなりません。

（２） データのチェックをする。

strutsが支援する入力データのチェックは、それを使うように設定すればアクションに入る前に行われます。アクションの中での入力データのチェックは、strutsが支援する入力データのチェックを使わないか、それで対応できない場合にするチェックです。

（３） データの型の変換をする。

ActionFormのデータは文字列型もしくはその配列です。これは、本来の型に一致しているとは限りませんので、bean(クラス)に移すときに変換します。

注 全体の構造を把握しやすくするため、この例題では入力に対応するデータは文字型で扱って処理を簡潔にしています。

（４） MVCのフレームワーク(*1)の中で済ませるべき処理をする。

ServiceとDaoではwebアプリ用の特定のコンテナやフレームワークを意識する処理は出来ません。それが必要ならServiceを呼び出す前にしておく必要があります。

注 *1: ここではservletコンテナ(TOMCAT)とstrutsを指します。

この例題ではMVCのフレームワークに依存しないようにする以外に処理はありません。したがって、形式的にはActionForm2のデータを別のbean(Dto2)に複写するだけです。

前の項にも書きました通り、Dto2はstrutsのActionFormを継承しないbeanであることが大切なことです。

リスト６．３－３にAction２(抜粋)のコードを示します。

リスト６．３－４ Action2のコード(抜粋)

６．３．５ Dao

DaoのfindPrefecturesByCondメソッドを変更します。

都道府県については複数の都道府県を指定できるようにします。その他の列については、値の範囲を指定できるようにします。ただし、簡略のため本来、数値として扱うべき列を文字型で扱っていますので、大小関係が数値の大小関係と一致しない恐れがあります。

例えば次のようなwhere句が作られます。

このためのコードをリスト６．３－５に示します。

リスト６．３－５ Daoのコード(変更部分)

buildWhereInとbuildWhereBtwはwhere句のinとbetween演算の句を作るユーティリティです。これは、ダウンロード物の中に含まれているDbUtilクラスのメソッドです。

第Ⅱ編 操作書

７． 付録Ａ template生成ツール

７．１ 概要

本文で説明した例題１から例題５を簡単に生成できるツールです。

学習の目的には生成したソースを本文の参考に使って下さい。

学習だけではなく、効率よくwebアプリ作る道具としても利用できます。構造を整えて中身は空にしていますので、必要なことは業務アプリをそこに書き込むことです。

７．２ 前提条件

strutsが使える環境があるとします。

７．３ ダウンロード

次のアドレスからダウンロードして下さい。

TODO ダウンロードアドレス

これを解凍します。解凍した後のディレクトリ構造をリスト７．３－１に示します。

リスト７．３－１ ディレクトリ構造

注 *1:[]はJavaのパッケージに対応するディレクトリの構造を略記したものです。

   *2:libは空です。例題を動かすには次節で説明するライブラリが必要です。

７．４ 必要なライブラリ

ダウンロードしたファイル中のlibディレクトリは空です。例題を動かすには表７．４－１のライブラリが必要です。

例題はStruts1.3.8で確認しています。表７．４－１の#１～#８はStruts1.3.8に付いてくるjarファイルです。しかし。#９と#１０は、Struts1.3.8に付いてくるjarファイルは旧いので、次のサイトからダウンロードして使って下さい。

http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi

1.1.2.zip

７．４ eclipaseの登録

eclipseに登録します。eclipseのプロジェクトのディレクトリはtemplateGenLite0です。

templateGenLite0は別の名前に変更しても構いません。templateGenLite0以下のディレクトリ名とファイル名は変更してはいけません。

ソースのディレクトリはsrcにして下さい。Javaのコンパイル結果の出力先はWEB-INFの下のclassesにして下さい。

StrutsではソースのディレクトリをWEB-INFの下のsrcディレクトリにするいのがデフォルトです。Strutsのdefaultに従っても問題ありません。templateGenLIteを使うときにソースディレクトリを指定します。それについては次の節で説明します。

eclipseに登録が完了すると、コンパイルエラーが表示されます。これは、servletのライブラリがないためです。servlet用のjarファイルはTOMCATのインストールディレクトリにありますので、それを外部のjarファイルとして追加します(*1)。

TOMCAT5.5.xの場合、servlet用jarファイルは次のファイルです。

（TOMCATインストールディレクトリ）\common\lib\servlet-api.jar

注 *1: プロジェクトを選択して、ファイル／プロパティをクリックします。ダイアログのタブライブラリをクリックして、外部jarファイル追加をクリックして追加します。

７．５ ツールの起動と実行時パラメータの設定

templateGenLite0\dev\templateGenLite.xlsを起動します。

rtシートをアクティブにします。

ここで次のパラメターを入力します。

あらかじめ値が入っていますが、これは実行環境に依存しますので実際の環境に合わせて値を変更して下さい。

説明

#１:projectBaseDir プロジェクトのディレクトリ。ダウンロードしたままの場合はtemplateGenLite0です。パスも含めて指定します。

#2: webBaseDir webのドキュメントベースに相当するディレクトリです。TODO 固定した方がいい

#3:srcBaseDir ソースディレクトリ。projectBaseDirを基準にしてパスを含めて指定できます。ダウンロードしたままの場合はsrcです。WEB-INF下のsrcの場合、web/WEB-INF/srcです

#４: dbBaseDir テストに使うＤＢです。

TODO 確認のツール

７．６ webアプリ生成用パラメータ

生成のパラメータを設定します。例を表７．６－１に示します。webアプリ１件について１シート必要です。例題のシートをコピーして使って下さい。

説明

第Ⅰ編 第１章の図１．２－１のクラスを参考にして下さい。

（１）name プロジェクトの名前、 詳細は本節の後半で説明します。

（２）package パッケージ名

（３）page.ext 画面用ファイルの拡張子。jspしか使えません。

（４）request1 要求１のパス名(urlの一部)

（５）action1 Action1のクラス名

（６）dto1 データを保存するためのbeanのクラス名（二つのうちの第1のもの）

（７）view1 応答１の画面のファイル名(拡張子は含まず)

（８）form1 ActionForm１、入力データを保持します

（９）request2 要求2のパス名(urlの一部)

（１０）action2 Action2のクラス名

（１１）dto2 データを保存するためのbeanのクラス名（二つのうちの第2のもの）

（１２）view2 応答2の画面のファイル名(拡張子は含まず)

（１３）form2 ActionForm2、入力データを保持します

プロジェクト名nameの用途

プロジェクト名は次に列挙する部分で使われます。クラス名の一部としても使いますので、先頭が英字で、後続の文字は英数字でなければなりません。使われる箇所によっては、Javaの通則に従って先頭文字を大文字又は小文字に変えて使います。

（a）クラスのdefault名の一部

表７．６－１の#４～#13はnameがn01Exampleの場合の各クラス又はリクエストのパス名のデフォルト値です。デフォルトボタンを押すとこれらが生成されます。

（b）次のクラス(interface)の名前

注 jsName、uJsNameはそれぞれ指定されたnameの先頭文字を小文字又は大文字にしたもの

（c）struts-config.xmlに挿入する場合のマーカ

struts-config.xmlに自動的に必要なフォームbeanとアクションマッピングの設定を追加します。その際、追加(挿入)する場所を示すマーカの一部として使います。同じプロジェクト名の場合はすでにその名前に由来するマーカがあればそれを置き換えます。form bean用とaction用のマーカの使われ方をそれぞれリスト７．６－１とリスト７．６－２に示します。

リスト７．６－１ struts-config.xml のform beanの定義

リスト７．６－2 struts-config.xml のactionの定義

（d）JNDIのキー

JNDIに登録するクラスのキーの一部に使います。表７．６－３に示します。

７．７ 生成できるプログラム

生成できるプログラムのタイプは5種類です。これは例題1～例題５に対応しています。一つの例題が1シートに対応しています。

例題とシート名の対応を表７．７－１に示します。

７．８ プロパティ名の定義

例題３と例題４、例題５の場合は、マクロの実行に先立ってプロパティ名をシート上の領域に記入しておく必要があります。場所は任意です。例を表７．８－１に示します。[prpoerty]の部分は見やすくするための書き込みで、生成には使われません。

７．９ DBのテーブルの情報

例題３と例題４、例題５の場合は、マクロの実行に先立ってDBのテーブルの情報も必要です。

templateGenLiteでは、この情報をtextファイルを使ったＤＢから読み取る方式にしています。

これは、実行時パラメータで指定したdbディレクトリになければなりません。次の二つのファイルからなります。

（１）schema.ini --- テーブルに関する情報。ファイル名は固定

（２）テーブルファイル --- データ。ファイル名はschema.iniの中に記述

ダウンロードしたファイルに含まれるschema.iniをリスト７．９－１に示します。

リスト７．９－１ schema.ini

[table7.txt]
Format=TabDelimited
ColNameHeader=TRUE
Col1=都道府県 char width 16
Col2=1995年 integer width 16
Col3=2000年 integer width 16
Col4=2005年 integer width 16
Col5=人口性比 double width 16
Col6=人口密度 integer width 16

先頭の[ ]の中がテーブル名です。それは、そのデータを保持するファイルの名前に一致しています。

Formatはcsv形式の区切り文字です。

ColNameHeaderはテーブルの先頭が列名であることを示しています。

Col1～Col6は各列の列名と型を示す情報です。Col1～Col6があるので、ColNameHeader=FALSEにして、テーブルのデータの第１行を列名にしない選択肢もできます。管理がしやすいのでColNameHeader=TRUEにしています。

処理を簡単にするため、ActionFormとDtoのプロパティはすべてを文字型にしています。そのため、それらとDB上のデータの型とを整合する処理がDaoに入っています。このため、Daoはやや読みづらいコードになっています。プロパティはすべてを文字型にしているのは、型を正確に処理すると例題の狙いでないところが複雑になるからです。結果として例題の狙いであるプログラムの構造化が見えにくくなるためです。実際のアプリでは正しく扱う必要があります。

注
schema.iniのテーブル名と列の情報をプログラムの生成時に使います。
生成したプログラムを実行するのにtext DBを使う場合はテーブルファイルも必要です。実行時に使うDBMSは生成したプログラムと設定(ファイル)を変更してtext DB以外のＤＢも使えます。text DB以外にEXCEL、MS ACCESS、HSQLDBで確認しています。

テーブルのデータを保持したファイルをリスト７．９－２に示します。

リスト７．９－２ テーブル

templateGenLiteはDBデータのうちテーブル名とそのテーブルに書かれている列名を読み取って利用しています。

テーブルの列と、前の節で説明したプロパティは、その順序で対応を付けます。そのため、個数は一致していなければなりません。

表７．８－１のプロパティとリスト７．９－２のテーブルは表７．９－１に示すの対応付けがされます。

生成されたプログラムは、そのままであればこのDBを使ってテストできます。また、生成されたプログラムはプログラム又は設定パラメータを変更すると、別のＤＢＭＳを使って実行できます。

７．１０ 生成物

生成されるものの出力先は表７．１０－１に示す通りです。ただし、gen1の場合は結果はファイルに出力されません。シート名がgenCodeのシートに出力されます。

注*1：変更されたものは2世代までバックアップファイルに保存されます。

７．１０ マクロの実行

マクロの実行に先立って次の設定されていることを確認して下さい。

（１）実行時パラメータ

（２）webアプリ生成用パラメータ

（３）プロパティ

（４）text ＤＢの設定

マクロの実行は、VBAマクロの一般的な形で出来ます。しかし、例題のシートをコピーして使うことをお勧めします。シート上に入りつけている実行ボタンを押すとマクロが実行されます。

例題３と例題４、例題５用のマクロを実行すると、プロパティ名を入力するプロンプトが出ます。シートに記入したパラメタ名の領域(例：表７．８－１の２行目)を選択します。

７．１１ Resourceの定義

例題6の場合は、context.xmlにResourceを定義しなければなりません。これはJNDIで参照される情報です。設定の例をリスト７．１１－１に示します。

リスト７．１１ Resourceの定義

説明

①context.xmlのxml指令文 TODO

②Context要素

③Resource要素 Serviceの定義

    name属性は、プロジェクト名/service。生成したプログラムからこの名前で参照しています。プロジェクト名/serviceに従わない場合は、プログラム(Factoryクラス)も変更します。

    type属性は、Serviceの完全クラス名を指定します。

    auth属性とfactory属性は例の通り指定します。

④Resource要素 Daoの定義

    name属性は、プロジェクト名/dao。生成したプログラムからこの名前で参照しています。プロジェクト名/daoに従わない場合は、プログラム(Factoryクラス)も変更します。

    type属性は、Daoの完全クラス名を指定します。

    auth属性とfactory属性は例の通り指定します。

⑤Resource要素 DbAccessorの定義

    name属性は、プロジェクト名/dbAccessor。生成したプログラムからこの名前で参照しています。プロジェクト名/dbAccessorに従わない場合は、プログラム(Factoryクラス)も変更します。

    type属性は、DbAccessorの完全クラス名を指定します。

    auth属性とfactory属性は例の通り指定します。

⑥Resource要素 DataSourceの定義

    name属性は、allExample/dataSource。生成したプログラムからこの名前で参照しています。プロジェクト名/serviceに従わない場合は、プログラム(DbAccessorJndiクラス)も変更します。

    type属性は、Serviceの完全クラス名を指定します。

    driverClassName属性,url属性,username属性,password属性はDBMSに従って指定します。

    auth属性とfactory属性は例の通り指定します。

７．１１ 生成したプログラムの実行

gen6６で生成した場合は、context.xmlにResourceを正しく設定していることを確認して下さい。

TOMCATを立ち上げます。

urlを入れます。urlは例えば次の形をしています。

http://localhost:8080/templateGenLite/r1_n01Example.do

r1_n01Exampleはwebアプリ生成用パラメータのrequest1の値です。最後に「.do」が必要です。

前もって必要なクラス

import jp.co.nsp_ltd.data.xxxxxxxxxx

import jp.co.nsp_ltd.data.impl.DbAccessor;

import jp.co.nsp_ltd.util.DbUtil;

gen1TemplateLite MVコード作成(シート出力)

gen2TemplateLite MVコード作成(ファイル出力)

Example1Action.java

Example1ActionForm.java プロパティnameだけ

Example1Dto.java

Example2Action.java

Example2ActionForm.java

Example2Dto.java

gen3TemplateLite MVBコード作成(ファイル出力)

N03Example1Action.java service.findData1

N03Example1ActionForm.java

N03Example1Dto.java

N03Example2Action.java service.findData2

N03Example2ActionForm.java

N03Example2Dto.java

N03ExampleService.java

N03ExampleServiceImpl.java 2メソッド 引数をそのまま戻す

gen5TemplateLite MVBDコード作成

DBを定義したシートも同時に必要になる。(列名だけでいい)

N04Example1Action.java service.findRecordsByCond(Dto2=空)を呼び出す。引数に値が設定されていないとすべてのレコードを読む仕様

N04Example1ActionForm.java 指定したプロパティを持つ

N04Example1Dto.java Form1と同じプロパティ

N04Example2Action.java service.addRecord(dto1); dto1にform1のプロパティから移される。

N04Example2ActionForm.java Form1と同じ

N04Example2Dto.java Form1と同じ

N04ExampleBaseAction.java 実質的な処理は含まない

N04ExampleDao.java

N04ExampleDaoImpl.java

次のメソッドを実装している。

    public List findAllRecords();

    public N04Example1Dto findRecordByPrefecture(String prefecture);

    public List findRecordsByCond(N04Example2Dto dto);

    public void addRecord(N04Example1Dto dto);

    public void updateRecordByPrefecture(N04Example1Dto dto);

    public void deleteRecordByPrefecture(String prefecture);

N04ExampleService.java

N04ExampleServiceImpl.java 同名のDaoのメソッドを呼び出す。

ERROR genSqlTagJsp SqlTag JSPコード作成---マクロがない。

createHtmlForm FORM作成

html formの作成 gen5TemplateLiteで作成されるhtml formはDBの列にのみ依存する。これは実際のformと差が大きいのでそれを補正する内容を作る。

genCodeシートに出力するので、jspの該当部分(formタグで挟まれている部分)を置き換える。

createActionForm ActionForm作成

createHtmlFormに対応するActionFormを生成します。

genCodeシートに出力するので、actionFormの該当部分(classの{...}で挟まれている部分)を置き換える。

genCodeシートには、該当するActionFormを処理するのに必要なActionの処理も同時に出力する。ActionFormからデータを取り出して、それをDto2に設定する処理です。Actionの該当部分をこれで置き換えます。

createDao_COND Dao変更分作成

createHtmlFormに対応するDao(一部)を生成します。where句を作ります。form captionに～(全角)があると、その直前のフィールドと対になって範囲を表すと解釈します。

createHtmlForm, createActionForm, createDao_CONDを使うために次のテーブルを作成しておく必要があります。

form captionに付随するフィールドの値がprop pnameのプロパティに保存されます。form-captionに対応するprop nameは必ずしも必要ありません。対応するprop nameを持たないフィールドのデータはActionFormに含まれません。

col nameはform captionに対応する、DBの列名です。form captionが～の場合は、直前のフィールドと対になって範囲を表すと解釈します。

wiring

gen5TemplateLiteまでは

Serviceは自ら具現化する。コンストラクタの中でDaoを具現化する。Daoの中でDbAccessorを具現化する。

gen1TemplateLite、gen2TemplateLite、gen3TemplateLiteはBaseActionがない。

gen1TemplateLiteはServiceクラスがない。

gen2TemplateLiteとgen3TemplateLiteとgen5TemplateLiteはstaticなメソッドgetInstanceでServiceクラスのインスタンスを取得する。gen5TemplateLiteはBaseActionがあるが実質何もしていない。

gen2TemplateLite

gen6TemplateLite

FactoryでService、Dao、DbAccessor、DataSourceを具現化する。この部分はstaticブロックで実行されます。

JNDIを使う。

Factoryクラスに、Service、Dao、DbAccessor、DataSource それぞれのインスタンスを取り出すためのstaticなメソッドがある。

Service、Dao、DbAccessorは参照するインスタンスを取り出す方法が違うのでgen5TemplateLiteまでのものとは違う。

BaseActionでserviceを取り出し、子のActionはgetServiceでserviceを取り出す。

gen7TemplateLite

InitializerクラスでService、Dao、DbAccessor、DataSourceを具現化する。この部分はBaseActionでserviceがnullのときに呼び出す仕掛けである(実際のアプリでどうするかは別の問題)

Initializerの入力として.propertiesファイルを作る。

直説法

  DaoImplの

    private String dbq="C:/@/projEclipse/pub/templateGenLite/db/xlTestDb.xls";

    private String dbTableName = "table7"; //"[table7$]";

JNDI

  context.xml のJNDI DBのdbqを変更する

DI

  .properties

TODO gen6Factory

DataSourceもfactoryで面倒見ているが、これを削除する。

DataSourceを参照するDbAccessorJndiの中でDataSourceの参照を取り出す。

理由：Factoryが特定の例題に依存しているので、DbAccessorJndiも特定の例題に依存してしまう。DbAccessorJndiはDbAccessorと同じように特定の例題に依存しないようにするため(Jndiを使うかDiを使うかの手法に依存するのはやむをえない。名前もそれに依存する名前にしている)

gen1とgen2の違い

内容は同じ。gen1は生成したソースをファイルに出さない。gen2は生成したソースをファイルに出す。

gen2とgen3の違い

gen2はServiceはない。gen3はServiceがある。Serviceでは実質的な処理をしていないので、処理という観点では同じ。しかし、Serviceの参照の取り方を示す意味でgen2とgen3は異なる。

gen3とgen5の違い

gen3はServiceまでしかない。gen5はService以降Daoをつけて実際にDBアクセスする処理を含む。Daoはその機能を実現するため、DbAccessorクラスDataSourceクラスが後に続く

gen5とgen6、gen7の違い

インスタンスの参照の取り方が違う。

gen5はnewを使って直接具現化してインスタンスを取得する。gen6はFactoryを使う。FactoryからJNDIでインスタンスの参照を取得する。gen7はINitializerを使いDI方式で参照を設定する。Initializerのパラメータを供給する.propertiesファイルを作る。まとめると次の通り。