演習 2.3: クライアント・サイド・データの作成と構成

この演習を始める前に、演習 2.2: サーバー・サイド・データの追加を完了する必要があります。

この演習ではクライアント・サイド・データを追加する方法を学びます。その中には、以前に作成したサーバー・サイド Bean に基づいて、あるページにクライアント・サイド・データ・オブジェクトを作成したり、また必要に応じてクライアント・サイド・データ・オブジェクトを構成することも含まれます。

クライアント・サイド・データ・オブジェクトの作成

ページ・データ・ビューで Bean を作成したように、同等の Client Data オブジェクトを作成します。

  1. tutorial.jsp ファイルが開いていることを確認します。
  2. クライアント・データ・ビュー (ページ・データ・タブの近く) の空スペースで右クリックし、「新規 (New-)」 > 「クライアント・データ (Client Data)」を選択します。
  3. サーバー・データ・モデル (Server Data Model)」セクションから root Bean を選択し、「了解 (OK)」をクリックします。

この時点で、クライアント・データ・ビューに root Bean 表示されます。クライアント・データ Bean とページ・データ Bean との実質的な違いは、Users/Portfolios/Positions セクションの PurchaseDate フィールドに関連したものだけです。クライアント・サイド・データでは、日付はストリングによく似た基本型として扱われます。

: モデルのプロパティーが BigDecimal 型の場合、クライアント・サイドでは任意精度の 10 進数がサポートされず、倍精度にダウン・キャストされることに注意してください。これは、BigDecimal 値を使用した場合、データの精度が失われる可能性があることを意味します。

クライアント・サイド・データ・オブジェクトを作成すると、ツールはプロジェクト内に多数のファイルとクラスを生成します。 root ソース・パッケージに、「OdysseyBrowserFramework.properties」という名前のプロパティー・ファイルが作成されます (既存のものがない場合)。com.ibm.dynwdo4jsmediators パッケージに 2 つのファイルが作成され、プロパティー・ファイルはこれら 2 つのファイルをプロジェクトに登録するために変更されます。

com.ibm.dynwdo4jsmediators.root パッケージには特別に作成されたメディエーターと diffhandler ファイルが含まれています。

Bean のあるクライアント・データ・ビュー

クライアント・サイド・データ・オブジェクトの構成

このセクションでは、次のことを行うためのクライアント・サイド・データの構成方法を学習します。

この演習でこれから最後まで使用することになる「クライアント・データの構成 (Configure Client Data)」ツールを起動するには、クライアント・データ・ビューを見付けてください。 ルート・ノードを右マウス・ボタンでクリックし、「構成 (Configure)」を選択します。 すると「クライアント・データの構成 (Configure Client Data)」ツールが現れます。

クライアント・ツールの構成

モデル名について

デフォルトでは、Bean を作成するとその Bean の名前が内部で使用されて、ブラウザーにエクスポートされるモデルの名前になります。 しかし、これは Web アプリケーションにとって常に好ましいわけではありません。 特にポータル環境では、一般に知られている名前を指定し、複数のポートレットがブラウザー上で実際にそのモデル・データを共用できるようにしたい場合があります。 その逆に、モデルを確実に自分の ポートレット専用としたい場合もあり、その場合は自分のポートレットのみに特定の名前を指定したいと考えます。

いずれの状態でも、モデル名があまり一般的なものにならないよう注意してください。 例えば Root という名前をつけるのは、他の開発者も同じ名前を使用する可能性があるので、トラブルの原因なります。 ブラウザー上では名前空間はフラットなため、同じ名前をもった 2 つのモデルは衝突します。 この理由から、Java のクラス名を反映する複雑な名前を使用するのが一般的に適切です。 例えば com_ibm_myApp_myModel などです。

このチュートリアルでは、モデル名はデフォルトのままにしておくことができます。

クライアント・サイド・データ構造の枝取り

場合によってはサーバーからのデータが多すぎ、クライアントに送信する必要のないクラスや属性が含まれていることがあります。 クライアント・データ・オブジェクトは、不要なクラスや属性を除去して構成することができます。

  1. 「基本 (Basic)」タブで、「クライアント・データ・モデル (Client Data Model)」ウィンドウの ルート (Root) を展開します。
  2. root ノードの下の stocks (Stock[]) および placeHolderStock (Stock) ノードの前にあるチェック・ボックスをクリアします。
  3. root/users/portfolio/positions ノードの下の portfolio (Portfolio) および user (User) ノードの前にあるチェック・ボックスをクリアします。 これらのバック・ポインターは、複雑なデータ構造でプログラミングする場合、パフォーマンス向上のために必要なことがよくあります。しかし、実際には、再帰的構造を生成してクライアント・データ・ビューの最終的なデータ表示を複雑にするため、このチュートリアルの目的からすれば邪魔になります。

注:: 特定のデータ構造に同じクラスが複数回使用されている場合、どこかでそのクラスのフィールドをカスタマイズすると、そのクラスが使用されるすべての場所でその変更が反映されます。これを試してみるために、root.users.portfolios.user プロパティーを使用可能にし、いくつかのチェック・ボックスを選択します。 それらと同じフィールドは、Root の下の User クラスの参照でも自動的に更新されることがわかります。

主属性の定義

オブジェクトの識別がどのように認識されるかを構成することができます。 クラスの通常のプロパティー、例えばルートの name プロパティーをクリックすると、「主 (Primary)」というチェック・ボックスがチェックされます。

同じクラスの 2 つのインスタンスがある場合には、それらが同じか異なるかをどのようにして判断できるのでしょうか ? 2 つのユーザーがある場合には、それらが同じか異なるかをどのようにして判断できるのでしょうか ? ユーザーのどの部分がインスタンスを固有のものにしているかを知らなければ、区別することはできません。それが主キー です。 主キーの設定についてさらに学習したい方に.

  1. user ノードを展開すると、4 つのプロパティー (refNum、lastName、id、portfolios) が表示されます。 このクラスの定義方法から、refNum フィールドは 2 つの異なるユーザーに対して固有であることが保証されているため、これが「主キー (Primary)」にマークする必要のある唯一のフィールドとなります。 他のフィールドを見ると、refNum、lastName、ID もすべて「主キー (Primary)」にマークされています。 デフォルトでは、リストまたは配列以外のすべてのフィールドは自動的に主キーとしてマークされます。 システムには、どのフィールドが主キーでどのフィールドがそうでないかを判断する方法はありません。
  2. ユーザーが、どのフィールドが主キーでどのフィールドがそうでないかを指示する必要があります。 これは本質的に必要な事項ではありませんが (デフォルト設定でも動作しますが)、ご使用のモデルで主キー・フィールドが適切に定義されているかどうかの確認については、厳しく考えるべきです。 データ構造全体を調べ、このチュートリアルで主キーにマークされているフィールドは下記リストのフィールドのみであることを確認してください。
    クラス フィールド
    Root Name
    Users refNum
    Portfolio user, porfolioName
    Position refNum
    Stock Symbol

クライアント属性の追加

データ・グリッドを使用して、任意のポートフォリオのコンテンツ (そのポジション) を表示します。 データ構造によると、Position クラスには次の 8 つの属性があります: price (購入価格)、quantity (数量)、refNum (参照番号)、symbol (シンボル)、purchaseDate (購入日付)、stock (購入株式)、portfolio (そのポジションを所有しているポートフォリオ )、user (そのポジションの所有者)。

欠落しているものがあります: value プロパティーは、数量に株式の現在の価格を乗算したものに等しくなります。 この情報を提供する 1 つの方法は、Java Bean を変更して、プロダクトにそこで計算させるものです。 しかし計算された値は一時のスナップショットになるため問題があります。ブラウザー上で quantity が変化した場合、計算された値はその変更を反映しません。この処理を回避するため、クライアント属性を使用します。それは、作成されたオブジェクトのコンテキスト内で実行される任意の JavaScript 式です。

  1. 「クライアント・データの構成 (Configure Client Data)」ダイアログ・ボックスで、users および portfolios の下にある positions ノードを選択します。
  2. クライアント属性の追加 (Add client attribute)」をクリックします。 クラス position の属性リストに、新しいエントリーが作成されます。
  3. タイプに float を選択し、フィールドの名前を value とします。そこにはドルの値を保管するためです。
  4. 式 (Expression)」テキスト領域に、次の式を入力します。
    this.eGet('quantity')*this.eGet('stock').eGet('currentPrice')
    属性を追加する正しいフィールド

    この式はブラウザー上で SDO オブジェクトを使用し、取得する属性を指示するストリングを使用してメソッド eGet をコールすることができます。 属性がサーバー・サイド・データでリストまたは配列の場合には、eGet はブラウザーで JavaScript 配列を戻します。 そのため、この position オブジェクトの quantity フィールドは、この position オブジェクトが指している stock オブジェクトの currentPrice フィールドと乗算されます。 ブラウザーでは、新規属性が要求されるごとにこの式が評価されるため、quantity および currentPrice の値と同期化されます。

    式 (Expression)」テキスト領域には、任意の有効な JavaScript を入力することができます。 例えば、2 つの値のパーセンテージを戻す関数を使用できます。 また、各 position を反復計算して総計を累算し、ポートフォリオ全体の合計値を示すフィールドを組み込むこともできます。 自分で書いたカスタム JavaScript 関数をはじめとして、もっているすべてをコールできます。 ただし、守らなければならない規則が 2 つだけあります。
    1. this ポインターは、属性が作成されたクラスのインスタンスを参照します。 式が戻す値は、属性に指定されたタイプと互換性のあるものでなければなりません。
    2. 属性が整数に設定され、式が整数に変換できないストリングを戻すと、実行時例外が発生します。
    : 式が、この属性に依存する式をもつ別のクライアント属性に依存しないよう、注意してください。 このような相互の依存があると無限ループが発生し、ブラウザーでスタック・オーバーフロー例外が発生します。 これは、Java コードを書いている時に適用する必要がある予防措置と同じものです。

拡張 (Advanced) タブについて

このチュートリアルでは「拡張 (Advanced)」タブを使用しませんが、このタブには理解しておくと役立ついくつかのボタンがあります。 最初のボタンは「EMap ソースのロード (Load EMap source)」で、これを使用すると、サーバー・サイド・データがどのようにブラウザーに送信され、Diff 処理用に戻されるかを構成する、システム内のキー・ファイルにアクセスすることができます。 コンフィギュレーターは、そのファイ内の情報を構成するためのインターフェースを提供しています。 このファイルを変更するのは、上級者のみに限ってください。

2 番目のボタン「サーバー・サイド・データからの再生成 (Regenerate from server-side data)」を使用すると、サーバー・データが変化した場合にクライアント・データ情報を更新することができます。この時点では、クライアント・データ・オブジェクトはサーバーのデータ・ソースで発生したかもしれない変更については何も知りません。そのため、例えば新規フィールドを取り出すために内部資産を再生成する必要があります。

3 番目のボタン、「プロジェクトからの除去 (Remove from project)」を使用すると、プロジェクトからすべてのクライアント・データ成果物を除去することができます。 これは、ページとそのデータがファイナライズされていない、テストや開発の初期段階で有用です。 クライアント・データ・ビューで削除のためにノードを選択すると、そのページのエントリーのみを削除することになり、そのクライアント・データ・エレメントを最初に作成した時点で生成された成果物はすべてプロジェクトに残されたままになります。 それらをすべて除去したい場合は、個々に除去しなければなりません。

これで、演習 2.4: データのバインドと表示のカスタマイズを開始する準備ができました。

ご利用条件 | フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved. (C) Copyright IBM Japan 2004