The PEXA Client - 画面作成(Swing)チュートリアル

PEXA Clientについて

チュートリアル

定義パターン

定義ファイル

リファレンス

はじめに

Step1:画面パネルを作成する

使用できる部品セット

作成方法

Step2：画面を起動できるようにする

Area定義ファイルを作成する

Page定義ファイルを作成する

ビルドを行う（その１）

ランチャから起動してみる

Step3：画面遷移できるようにする

Page定義ファイルに遷移情報を追加する

Area定義ファイルにコンポーネント定義とコマンド定義を追加する

ビルドを行う（その２）

ランチャから起動して画面を操作してみる

Step4：Contentを定義する

Contentを導出しステレオタイプで分類する

Content定義ファイルを作成する

Step5：AreaにContentをプラグインする

コンテントに対するリンクを宣言

コンテントを参照するコンポーネントの制御タグを追加

コマンド定義にアクション実行命令を追加

ビルドを行う（その３）

Step6：接続テストを行う

まとめ

はじめに

このドキュメントは、リッチクライアントの画面開発のチュートリアルです。
簡単な画面をサンプルとして、開発の流れ及び基本的な定義ファイルの内容について一通り流していきます。
各定義ファイル毎の詳細な仕様については別に資料を用意しますのでそちらを参照してください。

このチュートリアルでとりあげるサンプル画面として、システムにログインするためのログイン画面を使用します。
画面上に入力フィールドが３つとボタンが２つあり、ログインサービスを呼び出した後にメニュー画面に遷移するという動きが出来るようにします。

なお、この画面は実際には３つの画面パネルから構成されており、後述する一つのPage定義から三つの Area定義が1Window内に配置されています。このうち画面上部のヘッダ部分と画面下部のフッタ部分については説明を割愛し、中央のログインパネルを中心に話を進めていきます。

このチュートリアルでは、以下のステップで話を進めていきます。

Step1:画面パネルを作成する

Step2：画面を起動できるようにする

Step3：画面遷移できるようにする

Step4：Contentを定義する

Step5：AreaにContentをプラグインする

Step6：接続テストを行う

Step1:画面パネルを作成する

リッチクライアントの画面を開発する場合、まず開発対象の画面のデザインを決定し、それをJavaの画面パネルとして作成します。

画面として表示する際のWindowの生成及び制御はフレームワーク側で行うので、開発者は Window内に表示される内容を画面パネルとしてデザインすることになります。

ここで作成する画面パネルは、処理の実装は行われずに部品の配置が行われているだけの物となるので、この作業は画面デザイン的な作業となります。

使用できる部品セット

PEXAクライアントフレームワークは、標準でSwingに対応しています。

フレームワーク自体は特定のGUIの部品セットに対して依存していないので、対応するレイアウト制御および仮想コンポーネントを追加で用意すれば任意の部品セットを使用することができます。

Swing以外の部品セットを使用する場合は、追加でレイアウト制御および仮想コンポーネントを開発する必要があります。

作成方法

Swingを使用する場合、javax.swing.JPanelをextendsしたクラスを作成し、そこに各種部品を貼り付けて作成してください。

その際の開発ツールについては特に指定はありません。テキストエディタ、各種IDE(Eclipse, NetBeans, JBuilder)等、自由に選択してください。

ただし、ボタン押下時の処理といった内部処理は一切実装しないでください。あくまで部品を配置して画面をデザインする作業として行います。

このサンプルでは以下のような画面パネルの作成を行います。

Step2：画面を起動できるようにする

画面パネルが作成できたら、Page定義およびArea定義のXMLファイルを作成することで対象の画面を起動することが出来ます。以下のような手順で作業してください。

Area定義ファイルを作成する

Page定義ファイルを作成する

ビルドを行う（その１）

ランチャから起動してみる

Area定義ファイルを作成する

Area定義ファイルは、Window内に配置される画面パネルに対応する定義ファイルです。
この定義ファイルはMVCモデルにおけるV(View)に相当します。
また、C(Controller)に対してプラグインする制御情報も含みます。
定義中には実際に表示する画面パネルのクラス名が記述され、それをフレームワークが読み込んでパネルのインスタンスを生成します。

画面の起動のみに必要な情報は以下の物となります。

エリア識別情報(identityタグ)

レイアウト情報(layoutタグ)

その他は空欄で構いません。
identityタグ
<identity id="CA_WKFL_000_01_Login"
          name="一般申請ログインエリア"/>
エリアの識別情報(IDや名称)を定義するタグです。
identityタグで指定できる属性値は以下の物になります。

属性値名意味

id エリアに付与する、システム内でユニークなIDを記述します。

name エリアを表す日本語名称を記述します。
layoutタグ
<layout ref="PanelLayout">
    <gui implement="imeg.client.view.rich.area.share.LoginPanel"/>
</layout>
Window中の区画に表示する画面パネルおよび制御レイアウトを指定するタグです。
layoutタグで指定できる属性値は以下の物になります。

属性値名意味

ref AreaLayoutのIDを指定します。AreaLayoutはPEXAが標準で提供している物を指定します。
この例のように単純に１枚の画面パネルを１エリアとして扱う場合は"PanelLayout"を指定して下さい。

implement 制御レイアウトの実装クラスを指定します。プロジェクトで標準で提供される制御レイアウト以外の特殊な制御レイアウトを使用したい場合はこの属性値でカスタムの制御レイアウトクラスを指定してください。標準の制御レイアウトを使用する場合はこの属性値を指定せずにname属性で指定してください。

layoutタグの子タグとして、guiタグを記述します。
このタグでは、Window内に表示する画面パネルクラスを指定します。
guiタグで指定できる属性値は以下の物になります。

属性値名意味

implement 表示させる画面パネルのクラス名を指定します。
Area定義サンプル
画面を起動するだけの場合に必要な記述がされたArea定義のサンプルを以下に示します。
<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE client-area SYSTEM "../doctype/client-area.dtd">

<client-area>

    <identity id="CA_WKFL_000_01_Login"
              name="一般申請ログインエリア"/>

    <description>
        一般申請アプリケーションにログインを行うためのエリア
    </description>

    <reference-list>
    </reference-list>

    <layout ref="PanelLayout">
        <gui implement="imeg.client.view.rich.area.share.LoginPanel"/>
    </layout>

    <component-mapping>
    </component-mapping>

    <statechart>
    </statechart>

    <command-list>
    </command-list>

    <error-handling>
    </error-handling>

    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-area>

Page定義ファイルを作成する

Page定義ファイルは、Window内に表示される内容全体を表す定義ファイルです。
この定義ファイルは、MVCモデルにおけるV(View)に相当します。
ほぼWindowと一対一になっていると考えてもらってかまいません。
このPage定義内で宣言されている領域に対して、特定のエリアインスタンスをはめ込むことで実際の画面として表示されます。

画面の起動のみに必要な情報は以下の物となります。

ページ識別情報(identityタグ)

レイアウト情報(layoutタグ)

その他は空欄で構いません。
identityタグ
<identity id="CP_WKFL_Login"
          name="一般申請ログイン"
          stereotype="ログイン"/>
ページの識別情報(IDや名称)を定義するタグです。
identityタグで指定できる属性値は以下の物になります。

属性値名意味

id ページに対して付与する、システム内でユニークなIDを記述します。

name ページの日本語名称を記述します。
必須ではありませんが、タイトル表示等で使用される情報となります。

stereotype 画面展開パターンにおけるページのタイプを記述します。
必須ではありませんが、タイトル表示等で使用される情報になる場合があります。

context 画面を起動する際の、実行処理コンテキスト名を指定します。
必須ではありませんが、コンポーネントの制御等で使用される情報になる場合があります。
layoutタグ
    <layout ref="BorderLayout">
        <gui width="1024" height="733"/>
        <area-mapping>
            <area location="NORTH" ref="CA_COMM_000_01_Header"/>
            <area location="CENTER" ref="CA_WKFL_000_01_Login"/>
            <area location="SOUTH" ref="CA_COMM_000_02_Footer"/>
        </area-mapping>
    </layout>
Page上にエリアをどのように配置するかを定義するタグです。

ここに含まれる情報としては以下の物があります。

画面パターンに応じた制御レイアウトの指定

Windowのサイズ

画面パターン毎に決められた領域名と領域に埋め込まれるArea

layoutタグでは、Page内のArea配置を制御する制御レイアウトを指定します。
layoutタグで指定できる属性値は以下の物になります。

属性値名意味

ref PageLayoutのIDを指定します。PageLayoutはフレームワークが提供する汎用レイアウトと、プロジェクト毎に作成する専用レイアウトがあります。
この例では、PEXAが標準で提供する汎用レイアウトであるBorderLayoutを指定しています。

implement 制御レイアウトの実装クラスを指定します。プロジェクトで標準で提供される制御レイアウト以外の特殊な制御レイアウトを使用したい場合はこの属性値でカスタムの制御レイアウトクラスを指定してください。標準の制御レイアウトを使用する場合はこの属性値を指定せずにname属性で指定してください。

guiタグはオプション設定で、記述するとウィンドウのサイズを任意に調整することが出来ます。
guiタグで指定できる属性値は以下の物になります。

属性値名意味

width ウィンドウの幅をピクセル数で指定します。

heigth ウィンドウの高さをピクセル数で指定します。

area-mappingタグ配下のareaタグでは、どの領域にどのエリアインスタンスをはめ込むかを定義します。
areaタグのname属性は、ページ上の配置領域名称を記述します。これは制御レイアウトの種類毎によって決められていますのでそれぞれに従ってください。
areaタグで指定できる属性値は以下の物になります。

属性値名意味

location ページ上の配置領域名称を記述します
これは制御レイアウトの種類毎に決められているので、それぞれに従って指定して下さい。

ref name属性で指定した領域にはめ込むエリアのIDを指定します

サンプルで使用しているPageLayout"BorderLayout"では、５つの領域を持っていますが、ここではそのうちの３つを使用しています。

NORTH：ウィンドウ内の上部の領域

CENTER：ウィンドウ内の中央部の領域

SOUTH：ウィンドウ内の下部の領域

このうち、CENTERに対して前節で作成したエリアをはめ込むように定義しています。
ヘッダー及びフッター領域に関しては説明は割愛します。
Page定義サンプル
画面を起動するだけの場合に必要な記述がされたPage定義のサンプルを以下に示します。
このサンプルではレイアウトとして、ヘッダ、画面パネル、フッタによって構成されるログイン画面レイアウトを指定しています。
<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE client-page SYSTEM "../doctype/client-page.dtd">

<client-page>

    <identity id="CP_WKFL_Login"
              name="一般申請ログイン"
              stereotype="ログイン"/>

    <description>
        一般申請アプリケーションのログイン画面となるページ定義
    </description>

    <layout ref="BorderLayout">
        <gui width="1024" height="733"/>
        <area-mapping>
            <area location="NORTH" ref="CA_COMM_000_01_Header"/>
            <area location="CENTER" ref="CA_WKFL_000_01_Login"/>
            <area location="SOUTH" ref="CA_COMM_000_02_Footer"/>
        </area-mapping>
    </layout>

    <transition-list>
    </transition-list>

    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-page>

ビルドを行う（その１）

上記に従って作成した定義ファイルを所定の位置に格納し、ビルドを行います。
ビルドを行うことによって、画面パネルのJavaクラスのコンパイル、DTDによるXMLファイルの内容の簡易チェック、IDと対応定義ファイルの一覧ファイル自動生成が行われます。

ファイルの格納場所

以下の場所に、それぞれのファイルを格納してください。

Area定義ファイル：src/client/area
Page定義ファイル：src/client/page

ビルドの実行方法

プロジェクトのトップのbuild.xmlを使用して、まず以下のようにantを実行して下さい。

ant src meta

これにより、javaクラス、プロパティファイル、各種定義ファイル等のビルドが一通り行われます。また、以下のターゲットが使用できますので、特定の箇所のみビルドしたい場合は使用してください。

antターゲット名ビルド内容

src カタログからのJavaソース自動生成、コンパイル、プロパティ／トランスレータ定義の変換

meta 全てのメタデータのビルド(ptype.txt, model, service, client)を実行

ptype.txt PhenomenonType.txtを生成

model データモデルのメタデータ(.modelファイル)をビルド

service サービスのメタデータ(.serviceファイル)をビルド

client クライアントのメタデータ(Page定義、Area定義、Content定義)をビルド

native2ascii プロパティ／トランスレータ定義の変換

ランチャから起動してみる

ここまで作業して、必要なPage定義及びArea定義を作成し、ビルドが成功したら画面を起動してみましょう。
画面を起動するには、PEXAで用意しているClientLauncherを使用します。以下のクラスです。

pexa.client.std.platform.launcher.GuiRichClientLauncherV2

上記のクラスにmainメソッドが含まれていますので、コマンドラインもしくはEclipse等からJavaアプリケーションとして起動します。
ClientLauncherの使用方法については、別途チュートリアルがありますので詳細は以下を参照してください。

Step1:ClientLauncherの起動

Step2:画面実行設定の作成

Step3:画面遷移テストの実行

上記に従って画面遷移テストを実行してみると、定義ファイルが読み込まれて画面が起動します。
何かエラーが発生した場合は、コンソールにログが出力されているので詳細はそちらを確認してください。

Step3：画面遷移できるようにする

画面を表示できることが確認できたら、Page定義およびArea定義に対して情報を追加し、画面遷移が出来るようにしてみましょう。以下の手順で作業してください。

Page定義ファイルに遷移情報を追加する

Area定義ファイルにコンポーネント定義とコマンド定義を追加する

遷移先画面の画面パネル、Page定義、Area定義を用意する

ビルドを行う（その２）

ランチャから起動して画面を操作してみる

Page定義ファイルに遷移情報を追加する

まず、Page定義ファイルに画面遷移情報を追加します。
複数の画面間での遷移についての情報は、すべてPage定義ファイルに記述されます。これは、Windowとして表示される一画面を表すのがPage定義ファイルであるためです。

記述する情報は以下の物になります。

画面遷移情報(transition-listブロック)
transition-listブロック
<transition-list>
    <transition id="ドメインポータルメニューへ遷移">
       <transit-page next="CP_WKFL_DomainPortal"/>
    </transition>
</transition-list>
ページ間の遷移情報を記述するタグです。
対象の画面(Page)から発生する全ての画面遷移について、 transition-listタグ内にリストアップするような形になります。

transition-listの子タグとして、transitionタグを複数個記述できます。
transitionタグおよびその子タグには、以下の情報が含まれます。

遷移を表すID

遷移先の画面のページID

遷移の種別(Window内切り替えなのか、別Windowポップアップなのか)

transitionタグの属性値は以下の物があります。

属性値名意味

id Page内でユニークになる遷移IDを記述します

transitionタグの子タグとしては、以下のタグが指定できます。

<transit-page next="遷移先PageID">
　　→Windowはそのままで遷移を行う。属性値は以下の通り。

属性値名意味

next 遷移先となるページのID

<popup-page next="遷移先PageID">
　　→別Windowを立ち上げて新しい画面を表示する。属性値は以下の通り。

属性値名意味

next 遷移先となるページのID

modal ポップアップする画面をモーダルにするかをtrue,falseで指定します。
trueにした場合、その画面を閉じるまで元の画面の操作はブロックされます。
省略可で、省略時はfalse指定となります。

<change-area location="切替領域名" next="切替AreaID">
　　→Window内の特定の領域のみを入れ替える。属性値は以下の通り。

属性値名意味

location 切り替え対象となるPage上での領域名

next 切替先となるエリアのID

<add-area location="追加領域名" add="追加AreaID">
　　→Window内の特定の領域にエリアを追加する。属性値は以下の通り。

属性値名意味

location エリア追加する対象となるPage上での領域名

add 追加するエリアのID

このサンプルの場合はtransit-pageを選択しているので同じWindow内での遷移となり、 next属性に遷移先ページのIDを記述しています。
Page定義サンプル
遷移情報を追加したPage定義ファイルのサンプルです。
この場合、遷移先ページのIDはCP_WKFL_DomainPortalで、同じWindow内の遷移となります。
<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE client-page SYSTEM "../doctype/client-page.dtd">

<client-page>

    <identity id="CP_WKFL_Login"
              name="一般申請ログイン"
              stereotype="ログイン"/>

    <description>
        一般申請アプリケーションのログイン画面となるページ定義
    </description>

    <layout ref="BorderLayout">
    	<gui width="1024" height="733"/>
        <area-mapping>
            <area location="NORTH" ref="CA_COMM_000_01_Header"/>
            <area location="CENTER" ref="CA_WKFL_000_01_Login"/>
            <area location="SOUTH" ref="CA_COMM_000_02_Footer"/>
        </area-mapping>
    </layout>

    <transition-list>
        <transition id="ドメインポータルメニューへ遷移">
           <transit-page next="CP_WKFL_DomainPortal"/>
        </transition>
    </transition-list>

    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-page>

Area定義ファイルにコンポーネント定義とコマンド定義を追加する

Page定義に画面遷移情報を追加したら、次にArea定義に情報を追加します。
画面遷移は、ボタン押下やメニュー選択といった画面上のコンポーネントに対する操作がトリガーとなって発生します。そこで、画面遷移を発生させるコンポーネントの情報および実行命令をArea定義に追加していきます。

記述する情報は以下の物になります。

GUI部品マッピング情報(component-mappingブロック)

画面制御命令(command-listブロック)
component-mappingブロック
<component-mapping>
    <Button id="ログインボタン" text="Login" onClick="COMMAND[ログイン]"/>
    <Button id="閉じるボタン" text="キャンセル" onClick="終了"/>
</component-mapping>
画面上に配置されているコンポーネントの定義情報を記述するタグです。
component-mappingタグの子タグとして、コンポーネント名に即したタグが用意されていて、それぞれに固有の属性値や子タグがあります。

この例では、Buttonタグで画面上のログインボタンに対する定義情報を記述しています。
Buttonタグの属性値の意味は以下のようになります。

属性値名意味

id 画面パネル上のボタンコンポーネントのname属性に設定されている値

text ボタン上に表示させる文字列の指定

onClick ボタンがクリックされた時に発行するイベント名の指定
イベント名はあらかじめフレームワーク側で予約されているものと、任意に定義できるものがあります。
後述の状態遷移定義を記述しない場合は次の予約されたイベント名を指定してください。

CLOSE：画面を終了します。

COMMAND：Area定義内に定義した任意のコマンド定義の内容を実行します。
このイベントを指定する場合は、記述形式としては

COMMAND[実行コマンド名]

としてください。前半の「COMMAND」は固定、後半の実行コマンド名はコマンド定義のIDです。

このように、画面パネル上に配置されただけのJButtonオブジェクトに対して、 Area定義中のButtonタグでパラメータを与えることによってフレームワークが動作を決定することができます。
テキストフィールドやテーブルなど、他のコンポーネントも同様にタグを記述すれば値の入力や表示ができるようになります。コンポーネントタグの一覧と詳細については、別途用意されるリファレンスを参照してください。
command-listブロック
<command-list>
    <command id="ログイン">
        <doTransition transit="ドメインポータルメニューへ遷移"/>
    </command>
</command-list>
画面操作により実行される命令群を記述するコマンド定義タグです。
command-listタグの子タグとして、実行命令群を表すcommandタグを複数個定義できます。
commandタグの属性値は以下の通りです。

属性値名意味

id Area定義内でユニークなコマンドのIDを指定します。
各コンポーネントや状態遷移定義(後述)での実行コマンドの指定とリンクします。

基本的にcommandのidは任意の文字列を割り振れますが、フレームワーク側で予約されているものがいくつかあり、これらはフレームワーク側が特定のタイミングで自動的に呼び出します。
これらのidを使用してコマンド定義を行うと、それぞれのタイミングで行われる処理をオーバライドできます。

予約済みコマンドID 説明

INIT エリアのインスタンスが開始されるタイミングで呼び出されます。
個別の初期化処理を入れたい場合などに使用します。

CLOSE エリアのインスタンスが破棄されるタイミングで呼び出されます。
個別の終了処理を入れたい場合などに使用します。

commandタグの子タグとして、実行する命令内容をスクリプト的にタグで記述できます。

この例では、画面遷移を実行する命令のdoTransitionタグのみを記述しています。
doTransitionタグの属性値は以下の通りです。

属性値名意味

transit 実行する遷移のIDを指定します。
これはPage定義のtransitionタグのIDとリンクします。

他にもifやswitchなどの判定文、後述するコンテントアクションの実行命令、
メッセージダイアログや確認ダイアログの表示命令などいくつかの命令が用意されています。
この命令群の一覧と詳細については、別途用意されるリファレンスを参照して下さい。
Area定義サンプル
コンポーネント定義およびコマンド定義を加えたArea定義のサンプルです。
この場合、ログインボタンをクリックするとログインコマンドが実行され、Page定義上で定義されているドメインポータルメニューへ遷移 というIDの画面遷移が実行されます。
<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE client-area SYSTEM "../doctype/client-area.dtd">

<client-area>

    <identity id="CA_WKFL_000_01_Login"
              name="一般申請ログインエリア"/>

    <description>
        一般申請アプリケーションにログインを行うためのエリア
    </description>

    <reference-list>
    </reference-list>

    <layout ref="PanelLayout">
        <gui implement="imeg.client.view.rich.area.share.LoginPanel"/>
    </layout>

    <component-mapping>
        <Button id="ログインボタン" text="Login" onClick="COMMAND[ログイン]"/>
        <Button id="閉じるボタン" text="キャンセル" onClick="終了"/>
    </component-mapping>

    <statechart>
    </statechart>

    <command-list>
        <command id="ログイン">
            <doTransition transit="ドメインポータルメニューへ遷移"/>
        </command>
    </command-list>

    <error-handling>
    </error-handling>

    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-area>

遷移先画面の画面パネル、Page定義、Area定義を用意する

遷移先となる画面について、 Step1:画面パネルを作成する、 Step2:画面を起動できるようにするに従って画面パネル及びPage定義ファイル,Area定義ファイルを作成してください。

ビルドを行う（その２）

ここまで作業したら、ビルドを行って変更を反映します。
Step2:画面を起動できるようにするのビルドを行う（その１）を参考にしてantでビルドを行ってください。

もしPage定義ファイルやArea定義ファイルのみを反映したい場合は、clientターゲットを指定すればビルド対象が定義ファイルのみとなります。 ant client

これにより、Page定義とArea定義の変更が反映されます。

ランチャから起動して画面を操作してみる

ランチャから画面を起動して動かしてみましょう。
Step2:画面を起動できるようにするのランチャから起動してみるに従ってランチャを起動し、画面を立ち上げてください。

表示された画面の該当のボタンをクリックして、定義した内容通りに画面遷移が発生するか確認してください。

Step4：Contentを定義する

画面遷移ができるようになったら、次はContent定義を作成していきます。
Content定義とは、画面の内容(構成ブロック)を抽象的に表す定義ファイルで、 MVCモデルにおけるM(Model)の役割を果たします。

Contentを定義してArea定義にプラグインすることにより、画面からの業務項目の取り扱いとサービスの呼び出しができるようになります。

Contentの定義は以下のように作業してください。

Contentを導出しステレオタイプで分類する

Content定義ファイルを作成する

Contentを導出しステレオタイプで分類する

Contentは、画面上における役割からステレオタイプで分類されます。
たとえば、検索条件を入力して検索サービスを呼び出すならconfigであり、検索結果を一覧表示し、ユーザに選択させるならeditlistであり、ユーザに値を入力させてデータモデルを編集するならeditというスレテオタイプが割り振られます。

一画面内に現れるContentは、スレテオタイプ毎に組み合わせがある程度決まってきます。
一覧検索画面であれば「config + editlist」、単純なデータモデルを編集する画面なら「edit」のみ、複雑なデータモデルを編集する画面なら「edit + editlist + edit」といった形です。

また、SVOステートメントアクティビティからもある程度Contentは導出されます。
「XXXを新規登録する」とか「XXXを更新する」といったSVOステートメントであれば最低限editのContentがあるはずであり、「XXXを検索する」といったSVOステートメントならconfigやlist,editlistがあるはずといった形です。

このように、SVOステートメント及び画面デザインの両方の観点からContentを導出します。
Contentの定義パターン及び定義例については、別途解説がありますのでこちらを参照してください。

Content定義ファイルを作成する

Content定義ファイルでは、主に以下の４点を定義します。

識別情報(identityタグ)

関連するSVOステートメント(reference-listブロック)

Contentで扱う画面項目(item-listブロック)

Contentで実行できるアクション(action-listブロック)
identityタグ
<identity id="CC_WKFL_01_Login"
          name="一般申請ログイン"
          stereotype="login"/>
コンテントの識別情報(ID,名前,ステレオタイプ)を定義するタグです。
identityタグで指定できる属性値は以下の物になります。

属性値名意味

id コンテントに付与する、システム内でユニークなIDを記述します。

name コンテントを表す日本語名を記述します。

stereotype コンテントのステレオタイプを記述します。指定できるのは以下の値となります。

login:ユーザのログイン処理を行うコンテント

logout:ユーザのログアウト処理を行うコンテント

menu:選択メニューを提供するコンテント

config:設定値を入力してサービスを実行するコンテント

editlist:ユーザが選択操作できる一覧表示コンテント

list:ユーザが選択操作できない一覧表示コンテント

edit:データモデルに対する入力を行うコンテント

status:更新される情報の表示を行うコンテント

info:固定的な情報の表示を行うコンテント
reference-listブロック
<reference-list>
    <statement ref="WKFL001" process="AAAを新規作成する"/>
    <statement ref="WKFL002" process="BBBを修正する"/>
</reference-list>
コンテントが結びつくSVOステートメントのID及びアクティビティ中の対応プロセスを列挙します。
statement-listの子タグとしてstatementタグを複数個記述できます。
特に結びつくSVOステートメントの無いコンテントの場合はstatementタグの記述は必要ありません。
statementタグで指定できる属性値は以下の物になります。

属性値名意味

ref Contentが対応するSVOステートメントのIDを記述します

process Pアクティビティ中の対応するプロセスを記述します
item-listブロック
<item-list>
    
    <item id="会社一覧" access="output" type="models" scope="local">
        <description>マスタ検索して取得した会社の一覧</description>
    </item>
    <item id="ログイン情報" access="hidden" type="model" scope="global">
        <description>サービスから取得したログイン情報</description>
    </item>
    
    <item id="利用者コード" access="input" type="value" scope="local">
        <description>画面から入力したログインユーザID</description>
    </item>
    <item id="認証情報" access="input" type="value" scope="local">
        <description>画面から入力したログインパスワード</description>
    </item>
    <item id="所属会社コード" access="input" type="value" scope="local">
        <description>画面から選択したログインユーザの所属会社</description>
    </item>
</item-list>
コンテントが取り扱う画面項目の定義です。
item-listの子タグとして、itemタグを複数個記述できます。
itemタグ１つが、１つの画面項目を表します。この画面項目は以下の物を指します。

画面から入力される項目

画面に出力(表示)される項目

画面で取り扱うデータモデル

画面で取り扱うデータモデルのリスト

内部処理で使用する隠し項目

これらの項目は画面のGUI部品およびサービスで参照されます。
itemタグで指定できる属性値は以下の物になります。

属性値名意味

id コンテント内でユニークになる項目ID。
口述するvaluetypeタグが省略された場合、このIDがそのまま現象型名として解釈される。

access この項目が入力値か出力値か隠し項目かを指定します。
指定できるのは以下の４つです。

input:画面上から入力される項目を表す

output:画面上に出力する項目を表す

inout:入出力両方となる項目を表す

hidden:コンポーネントからはアクセスできない隠し項目

type 項目の種別。値なのかモデルなのか、単値か複値かをあらわす。
指定できるのは以下の４つです。

value:単数の値を表す。

values:複数の値を表す。配列かList。

model:単数のモデルを表す。

models:複数のモデルを表す。配列かList

scope 項目の有効範囲を指定します。
指定できるのは以下の３つです。

local:このコンテント内部でのみ有効。

group:画面遷移上関連のあるコンテント間で有効。

global:全てのコンテント間で有効。

画面項目に関するオプション設定として、
valuetypeタグ,loadタグ,triggerタグ,procedureタグ,descriptionタグが記述できます。
これらのタグは省略可能です。
記述例 : 現象型名とは違うIDを持ち、初期値が今日で、入力と同時に検索アクションを実行する場合

<item id="基準日_開始日" access="inout" type="value">
    <valuetype ptype="基準日"/>
    <load from="calendar:TODAY"/>
    <trigger action="検索"/>
    <description>検索条件で指定する基準日の開始側です</description>
</item>
valuetypeタグは、値の型に関する設定を記述するタグです。
このタグが記述されていない場合、itemタグのid属性で指定された名前が現象型名として認識されます。
属性値は以下の通り。

属性値名意味

ptype 項目の現象型を指定します。項目名と現象型を区別して扱いたい場合に指定します。
この指定がない場合は、itemタグのid属性が現象型名として処理される。

implement 項目の型をクラス名として直接指定します。
この属性値が指定されている場合は現象型に結びついていない項目と判断されて、指定された型で変換されます。ptype属性が指定されていると無効。

loadタグは、値の読み込み元を指定するタグです。
このタグは複数個列挙して記述できます。複数個記述された場合は、上から優先的に読み込みを試みます。
属性値は以下の通り。

属性値名意味

from 項目の取得元の指定。固定値、データモデル中の値などを 参照記法という記述方法で指定できます。

triggerタグは、値の入力を契機として実行したい処理を指定するタグです。
画面から入力されたコードを元にマスタを検索して、その結果を入力後すぐに画面に反映したいというような場合に記述します。
属性値は以下の通り。

属性値名意味

action 値の入力時に実行したいコンテントアクションを指定します。

procedureタグは、値の取得をHelperクラス"ContentProcedure"を通して行いたい場合に使用するタグです。
値の取得になんらかのルールが存在する場合に、そのルールを実装するHelperクラスを作成して、implement属性でそのクラス名を指定します。
属性値は以下の通り。

属性値名意味

implement 値の導出ルールを実装したHelperクラスのクラス名を指定します。

descriptionタグは、項目の説明を記述するタグです。属性値はありません。
項目に関するコメントをタグで挟んで記述してください。
action-listブロック
<action-list>
    
    <action id="INIT">
        <doService service="会社マスタを検索する">
            <outputServiceSession>
                <outputValue item="会社一覧"/>
            </outputServiceSession>
        </doService>
    </action>
    
    <action id="ログイン">
        <doService service="ログインする">
            <inputServiceSession>
                <inputValue item="利用者コード"/>
                <inputValue item="認証情報"/>
                <inputValue item="所属会社コード"/>
            </inputServiceSession>
            <outputServiceSession>
                <outputValue item="ログイン情報"/>
            </outputServiceSession>
        </doService>
    </action>
</action-list>
Contentが実行できるアクションの定義リストです。 action-listの子タグとして、actionタグを複数個記述できます。
actionタグの内部はスクリプト的に実行命令が記述できます。基本的にはサービス呼び出しを記述することになります。

actionタグで指定できる属性値は以下の通りです。

属性値名意味

id コンテント内でユニークになるアクションID

statement このアクションが結びつくSVOステートメントのID。なければ省略可。

process このアクションが結びつくSVOステートメント内のプロセス。なければ省略可。

基本的にactionのidは任意の文字列を割り振れますが、以下のアクションIDはフレームワーク側で予約されており、特定のタイミングでフレームワーク側から自動で呼び出されます。これらのidを使用してアクション定義を行うと、それぞれのタイミングで行われる処理をオーバライドできます。

予約済みアクションID 意味

INIT コンテント起動時に実行されます。
あらかじめマスタ検索をしておきたい場合などに指定します。

CLOSE コンテント破棄時に実行されます。
コンテント終了と同時にサービスを実行したり、値のクリアを行う場合などに指定します。

actionタグの子タグとして、アクション内で行える処理の実行命令を記述できます。
基本的にはサービス呼び出しおよびサービスから取得した値の操作が主な物となります。

この例では、doServiceタグを使用して、初期化アクション内でマスタ検索のサービス呼び出しを行い、ログインアクション内でログインサービスの呼び出しを行っています。
アクションの実行命令の一覧及び詳細については、別途用意されるリファレンスを参照してください。

doServiceタグの属性値は以下の通り。

属性値名意味

service 実行するサービスのIDを指定します

doService子タグとして、inputServiceSessionタグおよびoutputServiceSessionタグを記述できます。
これらはサービスに対する入出力の定義となります。

inputServiceSessionタグは子タグとして、inputValueタグを持ちます。
このタグの属性値は以下の通り。

属性値名意味

key サービスに渡す入力パラメータのキーを指定します。
省略された場合、item属性で指定されたコンテント項目IDがキーとして使用されます。

item サービスに対する入力値としたい値をコンテント項目IDで指定します。

outputServiceSessionタグは子タグとして、outputValueタグを持ちます。
このタグの属性値は以下の通り。

属性値名意味

key サービスから受け取る出力パラメータのキーを指定します。
省略された場合、item属性で指定されたコンテント項目IDがキーとして使用されます。

item コンテントがサービスから受け取りたい値をコンテント項目IDで指定します。
コンテント定義サンプル
コンテント定義のサンプルを以下に挙げます。
ここでは、コンテントのスレテオタイプがloginであり、ログインサービスを呼び出す為の入出力項目がコンテント項目として定義されていて、コンテント起動時アクションおよびログイン実行アクションが定義されています。
<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE client-content SYSTEM "../doctype/client-content.dtd">

<client-content>

    <identity id="CC_WKFL_01_Login"
              name="一般申請ログイン"
              stereotype="login"/>

    <description>
        一般申請アプリケーションにログインするためのコンテントです。
    </description>

    <reference-list>
        <statement ref="COMM_001" process="システムにログインする"/>
    </reference-list>

    <item-list>
        
        <item id="会社一覧" access="output" type="models" scope="local">
            <description>マスタ検索して取得した会社の一覧。
            所属会社コードの選択肢となる</description>
        </item>
        <item id="ログイン情報" access="hidden" type="model" scope="global">
            <description>サービスから取得したログイン情報</description>
        </item>
        
        <item id="利用者コード" access="input" type="value" scope="local">
            <description>画面から入力したログインユーザID</description>
        </item>
        <item id="認証情報" access="input" type="value" scope="local">
            <description>画面から入力したログインパスワード</description>
        </item>
        <item id="所属会社コード" access="input" type="value" scope="local">
            <description>画面から選択したログインユーザの所属会社</description>
        </item>
    </item-list>

    <action-list>
    　　　　
        <action id="INIT">
            <doService service="会社マスタを検索する">
                <outputServiceSession>
                    <outputValue item="会社一覧"/>
                </outputServiceSession>
            </doService>
        </action>
        
        <action id="ログイン">
            <doService service="ログインする">
                <inputServiceSession>
                    <inputValue item="利用者コード"/>
                    <inputValue item="認証情報"/>
                    <inputValue item="所属会社コード"/>
                </inputServiceSession>
                <outputServiceSession>
                    <outputValue item="ログイン情報"/>
                </outputServiceSession>
            </doService>
        </action>
    </action-list>

    <transition-list>
        <transition next="CC_WKFL_05">
            <description>ログイン完了後の遷移先です</description>
        </transition>
    </transition-list>

    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-content>

Step5：AreaにContentをプラグインする

Content定義を作成したら、最後にArea定義に対してContentをプラグインします。
この作業を行うことにより、AreaとContentが連携するようになり、画面で業務項目の取扱およびサービス呼び出しが出来るようになって一通りの動作を行えるようになります。

AreaにContentをプラグインするには、以下の作業をArea定義に対して行います。

コンテントに対するリンクを宣言

 コンテントを参照するコンポーネントの制御タグを追加

 コマンド定義にアクション実行命令を追加

コンテントに対するリンクを宣言

まず、AreaがContentを参照していることを宣言します。この宣言を入れることで、AreaからContent項目の取扱及びContentアクションの実行が可能になります。
これは、Area定義のreference-listブロックにcontentタグを記述することで行います。
<reference-list>
    <content ref="CC_WKFL_01_Login"/>
</reference-list>
contentタグの属性値は以下の通り。

属性値名意味

ref Areaが参照するContentのIDを指定します。

コンテントを参照するコンポーネントの制御タグを追加

次に、Content定義で宣言されている業務項目を参照するGUIコンポーネントに対して、コンポーネントタグの記述を行います。これにより、Content項目と画面上のコンポーネントをリンクさせます。
サンプルとなっているログイン画面では、

ユーザーＩＤ、パスワードの入力テキストフィールド

所属会社の選択コンボボックス

がありますので、それらに対して制御タグを記述します。

参照記法について

コンポーネントに対してコンテント項目を指定するための記述の方法として、参照記法というURI的な記述方法を使用します。
この参照記法は定義ファイル内のあちこちで使用することができる記述方法で、今回のコンテント項目の指定に限らず様々なリソースにリンクするためのものが用意されています。また、必要に応じてプロジェクト毎にカスタマイズした参照を用意することも可能です。

参照記法の詳細については、別途用意されるリファレンスを参照してください。
ユーザーＩＤ、パスワードの入力テキストフィールド
<TextField id="ユーザ名テキストフィールド" text="content:CC_WKFL_01_Login/利用者コード"/>
<TextField id="パスワードテキストフィールド" text="content:CC_WKFL_01_Login/認証情報"/>
TextFieldの制御タグです。
text属性値の指定で使用している形式が、参照記法です。
URI的な記述形式となり、ここではContentで宣言されている項目を参照するために、

content:{ContentのID}/{Content項目のID}

という形式で指定しています。コロンの前がスキーマ(リンク先)を表し、コロンの後がプロトコル毎に決められている固有スキーマです。

TextFieldタグに指定してる属性値は以下の通り。

属性値名意味

id テキストフィールドの識別子。
リッチクライアントでは、GUIコンポーネントのname属性に設定されている名前と同じ値を指定します。

text テキストフィールドで取り扱う項目の指定。
ここでは参照記法を使用して、コンテント"CC_WKFL_01_Login"の項目 "利用者コード"および"認証情報"を指定しています。
所属会社の選択コンボボックス
<ComboBox id="会社コンボボックス" selectedItem="content:CC_WKFL_01_Login/所属会社コード">
    <ComboBoxModel>
        <ObservableComboValue items="content:CC_WKFL_01_Login/会社一覧"
                        value="会社No" text="会社名"/>
    </ComboBoxModel>
</ComboBox>
ComboBoxの制御タグです。
ここでもselectedItem属性および、Observableタグのitems属性に参照記法を使ってコンテント項目を指定しています。

ComboBoxタグの属性値は以下の通り。

属性値名意味

id コンボボックスの識別子。
リッチクライアントでは、GUIコンポーネントのname属性に設定されている名前と同じ値を指定します。

selectedItem コンボボックス選択値の入力先の指定
ここでは参照記法を使用して、コンテント"CC_WKFL_01_Login"の項目 "所属会社コード"を指定しています。

また、ComboBoxの子タグとしてComboBoxModelタグが指定されています。これは、コンボボックスの内容についての設定で、どこから選択肢一覧を取得してくるかで内容が異なります。
この例では、マスタデータモデルの検索結果をコンボの内容に使用しているので、Observableタグ を指定しています。

Observableタグの属性値は以下の通り。

属性値名意味

items コンボの内容一覧の取得元を指定します。
ここでは参照記法を使用して、コンテント"CC_WKFL_01_Login"の項目 "所属会社コード"を指定しています。

selectedItem コンボボックス選択値の入力先の指定
ここでは参照記法を使用して、コンテント"CC_WKFL_01_Login"の項目 "会社一覧"を指定しています。

value コンボボックスの選択値となる値の指定。データモデル中の現象型名で指定する。

text コンボボックスの表示文字列となる値の指定。データモデル中の現象型名で指定する。

コマンド定義にアクション実行命令を追加

<command-list>
    <command id="ログイン">
        <doAction content="CC_WKFL_01_Login" action="ログイン"/>
        <doTransition transit="ドメインポータルメニューへ遷移"/>
    </command>
</command-list>

コンポーネントタグを追加したら、後はコマンド定義からContentアクションを実行するように実行命令を追加します。
これにより、画面上でのボタン押下時などにContentアクションを実行してサービスの呼び出しができるようになります。

Contentアクションの実行命令タグはdoActionタグとなります。
doActionタグの属性値は以下の通り。

属性値名	意味
content	CotentのIDを指定します。
action	実行するアクションのIDを指定します。

ContentをプラグインしたArea定義のサンプル

ここまでの作業内容を反映したArea定義のサンプルです。
reference-listブロック、component-mappingブロック、command-listブロックに変更が入っています。

<?xml version="1.0" encoding="Windows-31J"?>
<!--
 - Copyright
 -->
<!DOCTYPE client-area SYSTEM "../doctype/client-area.dtd">
<!--==============================================================
 == Current-Module:
 == Release-Date:
 == Release-Version:
 == First-Created-On:
 == First-Created-By:
 == Copy-Right-Owner:
 ==============================================================-->
<client-area>
<!--==============================================================
==  エリアの識別情報
==============================================================-->
    <identity id="CA_WKFL_000_01_Login"
              name="ワークフローログインエリア"/>
<!--==============================================================
==  エリアの詳細説明
==============================================================-->
    <description>
        ワークフローログイン用の認証情報入力エリア
    </description>
<!--==============================================================
==  参照するコンテンツの宣言
==============================================================-->
    <reference-list>
        <content ref="CC_WKFL_01_Login"/>
    </reference-list>
<!--==============================================================
==  表示レイアウト情報
==============================================================-->
    <layout ref="PanelLayout">
        <gui implement="imeg.client.view.rich.area.share.LoginPanel"/>
    </layout>
<!--==============================================================
==  コンポーネントマッピング
==============================================================-->
    <component-mapping>
        <TextField id="ユーザ名テキストフィールド"
	           text="content:CC_WKFL_01_Login/利用者コード"/>
        <TextField id="パスワードテキストフィールド"
	           text="content:CC_WKFL_01_Login/認証情報"/>
        <ComboBox id="会社コンボボックス"
	          selectedItem="content:CC_WKFL_01_Login/所属会社コード">
            <ComboBoxModel>
                <ObservableComboValue items="content:CC_WKFL_01_Login/会社一覧"
	                    value="会社No" text="会社名"/>
            </ComboBoxModel>
        </ComboBox>
        <Button id="ログインボタン" text="ＯＫ" onClick="COMMAND[ログイン]"/>
        <Button id="閉じるボタン" text="キャンセル" onClick="終了"/>
    </component-mapping>
<!--==============================================================
　==  状態遷移表定義
　==============================================================-->
    <statechart>
    </statechart>
<!--==============================================================
==  コマンド定義
==============================================================-->
    <command-list>
        <command id="ログイン">
            <doAction content="CC_WKFL_01_Login" action="ログイン"/>
            <doTransition transit="ドメインポータルメニューへ遷移"/>
        </command>
    </command-list>
<!--==============================================================
　==  エラーハンドリング情報
　==============================================================-->
    <error-handling>
    </error-handling>
<!--==============================================================
==  ファイル編集情報
==============================================================-->
    <status>
        <author></author>
        <datetime></datetime>
        <version></version>
    </status>
</client-area>

ビルドを行う（その３）

ここまで作業したら、定義ファイルの作成はひとまず終了です。
他にもエラーハンドリングについての定義や入力値Validationの定義などがありますが、ここまで記述すれば正常ルートの処理に関してはサービスやモデルと接続して動かすことが出来るようになります。

実際に動かす前に、一度ビルドを行いましょう。Area定義の修正及びContent定義の新規作成が行われているので、 antでclientターゲットを実行するとクライアント定義ファイルのビルドが実行されます。

ビルドの詳細については Step2：画面を起動できるようにするのビルドを行う（その１）を参照してください。

Step6：接続テストを行う

ここまできたら、実際にサービスやデータモデルを使用しての接続テストを行ってみましょう。
サービス及びデータモデルのセットアップに関してはそれぞれのフレームワークのドキュメントを参照してください。
ここではそれらは完了していて呼び出せる状態にあると仮定して話を進めます。

接続テストモードで動かす方法は、ClientLauncherのチュートリアルを参照してください。

Step4:接続テストの実行

テスト対象の画面が起動できたら、実際にその画面を操作してテストを行ってください。

まとめ

単純なログイン画面を元ネタとして、画面実装の流れを大まかに追ってみました。
実際に開発対象となる画面は、GUI部品の数も多く挙動も複雑になると思われますが、作業の流れそのものはここで説明した物と同じです。

画面パネルを作成

Page定義, Area定義を作成して画面起動と画面遷移を確認

Content定義を作成してサーバーサイドと接続して動作を確認

という作業の繰り返しとなります。

ComponentやCommand命令などについては別途詳細情報としてリファレンスが用意されており、各定義ファイルについてもそれぞれ詳細説明があります。
左のメニューの[定義ファイル]、[リファレンス]からリンクをたどって参照してください。

また、画面のパターン毎にどのような実装になるかのサンプルが[定義パターン]として用意されているので、そちらも参考にしてください。

更新情報

最終更新者 : $Author: morishita $

最終更新日時 : $Date:: 2009-01-09 22:28:52 #$

バージョン : $Revision: 3037 $