Faces Client コンポーネントを持つ JavaServer Faces リソースのマイグレーション

JavaServer Faces JavaServer Page (JSP) に Faces Client コンポーネントを含む WebSphere® Studio V5.1.x でプロジェクトを作成した場合は、 Faces Client コンポーネントのランタイム・リソースを最新レベルにマイグレーションする必要があります。

WebSphere Studio V5.1.x で作成された Faces Client コンポーネントを持つ JavaServer Faces JSP を含む プロジェクトを V6.0 で開いた後、Faces Client コンポーネントのランタイム・リソースをマイグレーションするために、以下のことを実行する必要があります。
  1. 新規 JSP ファイルを作成し、モデルに対して「基本 (クライアント・サイド・データ・キャッシュを使用)」 を選択する。この JSP は Rational® Web Developer で すべてのシステム Java™ アーカイブ (JAR) ファイルを最新レベルに マイグレーションするために、一時的にのみ必要です。
  2. プロジェクトのランタイム・リソースを最新レベルにマイグレーションできることを 伝えるプロンプトが表示されます。マイグレーションを完了するには、「はい」 をクリックしてください。重要:いいえ」を選択したり、ダイアログ・ボックス を取り消すと、プロジェクトの Faces Client コンポーネントは最新レベルに マイグレーションされず、プロンプトは再び表示されません。そのために、 新規ツールと古いランタイム JAR ファイルの間でいくつかの重大な問題が発生します。
  3. 新規 JSP ファイルを作成した後は、プロジェクトから削除することができます。
  4. クライアント・データ領域でデータ・オブジェクトを選択し、 右ボタンをクリックして、「構成」を選択する。「拡張」 タブで「すべて再生成」を選択します。これによりすべての仲介が再生成されます。
    注: サーバー・サイド・データから再生成」ボタンは使用しないでください。「すべて再生成」 を使用する必要があります。
  5. バージョン 5.12 には WebSphere Data Objects (WDO) スキーマ・エレメントがありますが、 これはバージョン 6.0 ではもう使用されていません。これらのエレメントの仲介クラスは 再生成されず、コンパイル・エラーが継続して発生します。これらの仲介は *_DataGraphSchema_wdo4js_*.java という命名規則を持ちます。これらのコンパイル・エラーを回避するためには、プロジェクトからこれらの仲介クラスを 削除してください。
Linux™ プラットフォームで作業している場合、または英語以外のロケールを使用している場合: 前述のステップに従って JavaServer Faces JSP に Faces Client コンポーネントを含む WebSphere Studio V5.1.x で作成されたプロジェクトをマイグレーションする前に、 プロジェクトが V6.0 にロードされたときに次のエラー・メッセージを受け取ることが あります。
<class_name>.java を読み取れなかったため、プロジェクトを構築できません。
V5.1.x プロジェクト のクライアント・データ仲介クラスにエンコードされなかった特殊文字が含まれている可能性がありますが、 Rational Web Developer V6.0 の仲介クラスはこれらの文字をエンコードするため、ファイルを読み取れませんでした。これらの エラー・メッセージは、前述のステップに従ってクライアント・データを 再生成すると表示されなくなります。ただし、Faces Client コンポーネントを 含むプロジェクトをマイグレーションするステップに従う前に、ワークスペースを構築できるように、 まず V6.0 にロードされたプロジェクトからクライアント・データ仲介ファイルを 削除する必要があります。クライアント・データ仲介ファイルを削除するには、 以下のようにします。
  1. プロジェクトから命名規則 com.ibm.dynwdo4jsmediators.<client-data- name> を持っている すべてのクライアント・データ仲介クラス・パッケージを削除する。
  2. com.ibm.dynwdo4jsmediators という名前のパッケージは削除しない。このパッケージには、 仲介の再生成に使用されるプロジェクト内のクライアント・データのメタデータ (ecore および emap ファイル) が含まれています。
  3. 仲介パッケージを削除した後、プロジェクトが構築される。 これで、前述のマイグレーション・ステップを完了することができます。

いくつかのインスタンスでは、「仲介の生成に失敗しました」 というメッセージを受け取ることがあります。 この問題を訂正するには、OdysseyBrowserFramework.properties ファイルを編集して、 EMAP_FILES and ECORE_FILES プロパティーの項目を削除してから、もう一度実行してください。

注: Faces Client コンポーネントを含むプロジェクトの ターゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に変更したときに問題が発生する可能性があります。
Faces Client コンポーネントを 含むプロジェクトのターゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に変更したときに発生する可能性のある問題が 2 つあります。
  • すでに生成されているクライアント・データの仲介クラスが コンパイルされなくなる。一度に 1 つずつ JSP を再生成する必要があります。これは、 以下のように実行します。
    1. ルートの Java ソース・フォルダー で検出される OdysseyBrowserFramework.properties ファイルを開く。将来の利用のために内容を保管します。
    2. OdysseyBrowserFramework.properties ファイルで、プロジェクトの Faces クライアント・データ を含む JSP ごとに、プロパティー EMAP_FILES および ECORE_FILES に対する <client-data-name>.ecore と <client-data-name>.emap 項目を見付ける。
    3. JSP 上のクライアント・データの一致する項目のみを保持し、 他のすべての項目を削除する。
      例えば、現行ページに ACCOUNT というクライアント・データ があり、プロパティー・ファイルに次のような項目がある場合:
      EMAP_FILES=com¥¥ibm¥¥dynwdo4jsmediators/account.emap com¥¥ibm¥¥dynwdo4jsmediators/orders.emap
      項目から com¥¥ibm¥¥dynwdo4jsmediators/orders.emap を削除します。すると、 この項目は次のように表示されます。
      EMAP_FILES=com¥¥ibm¥¥dynwdo4jsmediators/account.emap
    4. プロパティー・ファイルを保管する。
    5. JSP 内のクライアント・データを右クリックし、「構成」を選択する。
    6. 拡張」タブを選択する。「すべて再生成」 ボタンをクリックします。これにより現行の JSP のすべてのクライアント・データに必要なすべての成果物が再生成されます。
    7. プロジェクト内でクライアント・データを含む JSP ごとにこれらのステップを繰り返す。

    プロジェクト内の JSP のクライアント・データ仲介クラスを再生成した後、コンパイルされない仲介クラスがまだいくつか残ります。V6.0 の Service Data Object (SDO) では使用されなくなったスキーマ・エレメントの仲介があります。これらの仲介は命名規則 * DataGraphSchema_wdo4js_*.java および *_RootDataObject_wdo4js_*.java を持ちます。これらのコンパイル・エラーを回避するためには、プロジェクトからこれらの仲介クラスを 削除してください。

    マイグレーションが正常に完了した後、 OdysseyBrowserFramework.properties ファイルのオリジナルの内容を復元します。

  • WDO に結合されたツリー・ビューの Faces Client コンポーネントが、 プロジェクトのターゲット・サーバーを WebSphere Application Server V6.0 に変更した後、サーバーでの実行に失敗する。
    この問題の予備手段はすべての className タグが WDO DataObject クラスではなく SDO DataObject クラスを使用するように、 JSP のソース・ビューを変更することです。例えば、account という名前の WDO については次のようにします。
    1. ルート・オブジェクトについて、className タグを className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" から className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)" に変更する。
    2. すべての下位ノードについて、className タグを className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" から className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)" に変更する。 ここで、ACCOUNT はデータ・ノードの名前です。
自動化された Diff ハンドラーおよびプロセッサーにアップグレードする: これにより Diff プロセッサーとハンドラーが自動的に生成されます。Faces Client コンポーネントの Diff ハンドラーとプロセッサーを WebSphere Studio V5.1.x で作成した場合は、そのコードを廃棄し、自動的に生成されるプロセッサーとハンドラー を使用することをお勧めします。そのためには、以下のステップを実行する必要があります。
  1. 新規 Diff ハンドラーとプロセッサーを生成する。そのためには、プロジェクト内の クライアント・データ・オブジェクトごとに、以下を実行します。
    1. クライアント・データ・オブジェクトを選択し、右マウスをクリックして、 「構成」を選択する。
    2. 拡張」タブで「すべて再生成」を選択する。
  2. 生成されたプロセッサーとハンドラーは自動的に起動されるため、 Diff プロセッサーとハンドラーを起動するために作成したコードを除去する。このコードが使用された場所の典型的な例は、「コマンド・ボタン」コンポーネントの「コマンド」イベントです。以下は、このコードがどのように見えるかを示した例です。
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. 作成した古いカスタム・ハンドラーおよびプロセッサーに対応するファイルを プロジェクトから除去する。
V5.1.x 用に作成されたカスタム Diff ハンドラーとプロセッサーを保持する: これは推奨されませんが、V5.1.x からのカスタム Diff ハンドラーとプロセッサーを 保持する必要があると判断した場合は、それらを V6.0 で機能させるためには変更が必要になります。その理由は、DiffHandler インターフェースと DiffInfo クラスが変更されているためです。
  • DiffHandler インターフェースは以下のように変更されました。
    • ハンドル・メソッドは DiffException に加え、Exception を throw するようになった。
    • フレームワークはオブジェクトを検索するために新しい find メソッドを使用する。
    • デバッグに新規 getId メソッドが使用され、フレームワークが オブジェクトの値を印刷することができる。

    生成された DiffHandler により find および getId メソッドが内部で使用される。カスタム DiffHandler については、このインターフェースに準拠させるためだけに空のメソッドをインプリメントすることができます。それらのメソッドは、 フレームワークによって呼び出されません。

    DiffHandler インターフェースは、 以下のようになりました。
    public interface DiffHandler
     {
       public void   handle(DiffInfo Diff) throws DiffException, Exception;
       public Object find  (DiffInfo Diff) throws DiffException, Exception;
       public String getId (DiffInfo Diff, boolean Original);
     }
  • DiffInfo クラスが以下のように変更されました。
    • ArrayList getAncestors() メソッドは DiffInfo getParent() メソッドに置換されました。このメソッドは再帰的方法で祖先ツリーの各オブジェクトの情報に容易にアクセスする方法を提供します。
    • getCurrent() および getOriginal() メソッドは、EObject オブジェクトではなく DataObject オブジェクトを戻すようになりました。DataObject オブジェクトを使用するように コードを変更することは必須ではありません。しかし、DataObject インターフェースの方が EObject よりもより簡単で直感的に使用できます。レガシー・コードに対して、 容易に DataObject オブジェクトを EObject オブジェクトに cast することができます。
    • このオブジェクトが適用されるプロパティー名を識別するために、 新規メソッド String getPropertyName() が追加されました。これは、例えば特定のクラスに 同じ型の 2 つのプロパティーがある場合に重要です。以前の DiffInfo クラスでは、 コードは 2 つのプロパティー間を区別することができませんでした。
    DiffInfo クラスは以下のように変更されました。
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    注: DiffInfo クラスは公用の使用ではサポートされなくなりました。 その理由は Diff プロセッサーとハンドラーが自動的に生成されるようになったためです。古い ハンドラーを保持するのは一時的なソリューションでしかなく、自動化されたハンドラーを使用するよう強くお勧めします。
V6.0 での Faces Client コンポーネントへの変更:
  • WebSphere Application Server V6.0 へのサポート。
  • WebSphere Application Server V6.0 での Service Data Object (SDO) のサポート。
  • EGL データがクライアント・データとしてサポートされるようになりました。
  • Diff プロセッサーとハンドラーが自動生成されます。
  • 次のクライアント・コンポーネントに対する新規イベントがあります。
    • TabbedPanel: onInitialPageShow
    • Tree: onNodeExpand、onNodeCollapse、onExpand、onCollapse
    • DataGrid: onPage、onSort、onFilter
関連タスク
ポートレット・プロジェクトでの Faces リソースのマイグレーション
ご利用条 件 | フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.
(C) Copyright IBM Japan 2005.