サーバー上でバインドされていない Faces Client コンポーネントを含む Faces JSP ファイルを実行できません。Faces Client コンポーネントをクライアント・データ・オブジェクトにバインドして、サーバーで実行できるようにする必要があります。
この問題は、内部 WDO コードの NullPointerExceptions が原因です。この問題を回避するには、データベース内の NULL 値をデフォルト値に置き換えるか、サーバーを WAS 6.0 にアップグレードします。アップグレードする場合、マイグレーション・ガイドの『Faces Client コンポーネントを含む JavaServer Faces リソースのマイグレーション (Migrating JavaServer Faces resources with Faces Client Components)』というセクションに必ず従ってください。
注: 空の関連レコードから作成されたクライアント・データを含む Faces JSP も、同じ理由で WAS 5.1 では実行されません。 この問題の簡単な次善策はありません。
イベント・ハンドラーの断片が作成された後で「ターゲット・コンポーネントで選択されたオブジェクトをルートとして設定 (Set selected object as root in target component)」イベント・ハンドラーのターゲット・コンポーネントを名前変更すると、JavaScript が誤りになります。 この問題の次善策として、断片を削除して、再作成します。
ファイルのアップロードおよびダウンロードの機能を実装する Faces コンポーネントがポートレットでサポートされません。 次の Faces コンポーネントが該当します。
- ファイルのアップロード
- BLOB (または byte[]) データ・ソースにバインド済みのイメージ、リンク、およびメディア・プレイヤー
データグラフで 2 レベル以上の深さの関連レコード・リストにバインドされたデータ・グリッドに行を追加した後で Faces JSP ファイルをサブミットするとき、java.lang.IllegalArgumentException「'CUSTOMERS' の機能 'CUSTOMERS_ORDERS' が含まれていません (The feature 'CUSTOMERS_ORDERS' of 'CUSTOMERS' isn't a containment)」を受け取ります。
これは、Faces Client の更新の処理方法での制限です。SDO では、すべての関係が「DatagraphRoot」内に含まれ (containment=true)、それぞれの関係はルート内に含まれる他の関係を参照 (containment=false) します。Faces Client の DiffHandlers は常に、新規オブジェクトを「コンテナー」ではなく、「親」に追加しようと試みます。
この問題を回避するには、新規の行をレベル 1 の関係として更新する関係レコード・リストを作成します。例えば、CUSTOMER が所有する ORDERS 表に 1 行追加する場合、CUSTOMER -> ORDERS の関係を作成した後で ORDERS に 1 行追加するのではなく、関係レコード・リスト ORDERS を作成し、ORDERS に 1 行追加します。
dataTable 内でネストされた dataTable (例えば、行のプロパティーがコレクションであるなど) の列に入力コンポーネントがある場合、データ・モデルは正しく更新されません。
ページ・テンプレートから派生した Faces JSP ファイルにデータをドロップするとき生成されるタグの位置が正しくない場合があります。ページ本体内でテンプレートに複数のコンテンツ領域がある場合、ページ・データ・ビューから、またはパレットのデータ・ドロワーからデータをドロップすると、常に最初のコンテンツ領域に新規タグが生成されます。 要求したターゲットがそのコンテンツ領域になかった場合は、ソース・モードに切り替えてください。 次に、生成されたソースを正しい位置に切り貼りしてください。h:form タグに囲まれている場合はそれも含めて、新規タグをすべて選択してください。また、貼り付け位置が、要求したコンテンツ領域の hx:scriptCollector タグの内側になるようにしてください。
WSAD 5.1.2 を使用して開発されたプロジェクトを処理する際、プロジェクトの Faces リソースのマイグレーションを促すプロンプトがユーザーに出されることがあります。ユーザーが YES で応答すると、Faces ランタイムが最新レベルに自動更新されます。ただし、データ・アクセスに WDO を使用していた場合は、手動による追加構成が必要です。
- 元のプロジェクト内に一時 Faces JSP ファイルを新規作成します。 (「ファイル」>「新規」>「Faces JSP ファイル」をクリックします。 オンライン・ヘルプの支援を参照してください。)
- パレットのデータ・ドロワーからページへ、関連レコード・コンポーネントをドラッグします。 既存メタデータの再使用を選択し、リストされた既存 WDO XML ファイルをすべて選択します。 このプロセスにより、WDO をこのプロジェクトで継続して使用するために必要な構成がすべて生成されます。
- 一時 JSP ファイルを削除します。
詳しくは製品のマイグレーション・ガイドを参照してください。
1 ページに複数の inputText フィールドがあると、inputText フィールドの検証ページが正しく更新されません。 この問題は、inputText フィールドに複数の異なるコンバーター・サブタグがある場合に発生します。例えば、1 つの inputText フィールドで convertNumber コンバーターを使用し、別のフィールドで convertDateTime コンバーターを使用している場合、タグ間の切り替えの際に検証ページが正しく更新されません。2 つの次善策が考えられます。1 つは、ソース・モードに切り替えて、子の検証またはヘルパー・タグをクリックすることです (この時点でページが更新されます)。 もう 1 つは、JSP を閉じて、再び開くことです。
EGL クライアント・データ用に生成された DiffHandler で、ネストされた型を参照するための構文に誤りがあります。 この問題を回避するには、クライアント・データ・メディエーター・クラスを編集して正しい構文を使用するようにします。ドル記号 ($) ではなく、ピリオド (.) を使用します。例えば、次のようなコードがある場合は、
if (_Root instanceof pagehandlers.overdueaccounts$COMPANYNAME)
以下のように変更します。if (_Root instanceof pagehandlers.overdueaccounts.COMPANYNAME)
既存の SDO/WDO クライアント・データを再使用するクライアント・データを作成する際、必ず WDO/SDO メタデータ・ファイルとモデル名を再使用してください。ページ・データ・ビューから WDO/SDO を作成する際、「既存レコードまたはレコード・リストからメタデータ定義を再使用 (Reuse metadata definition from an existing record or record list)」を選択します。次に、再使用する SDO 用のメタデータ・ファイルを参照して選択します。
この問題を修正するには、同じポータル・ページで使用されるすべてのポートレットで、JSF および JSF クライアント・コントロールがすべて固有の ID を持つようにしてください。重複 ID のある不明なポートレットをポータル・ページが使用する場合は、競合が起こる可能性があります。JSP 名を ID の一部に組み込んで、ID を固有にすることをお勧めします。
この問題には既知の次善策がありません。 ラベルの使用を最小にして、整理してください。
次善策はありません。ポータルのツリー・ビューではカスタムの「開く」アイコンおよび「閉じる」アイコンを使用しないでください。
y 軸上に近似する一連の値をプロットする場合、デフォルトのフォーマットを指定すると精度が低下する可能性があります。この精度の低下によって、値が重複する可能性があります。この問題を回避するために、適切なカスタム数字フォーマットを選択し、デフォルトを使用しないでください。
この問題を回避するには、グラフのサイズを大きくしてください。
データ・グリッドのヘッダーとフッターは、以下のシナリオでは表示されません。
- データ・グリッドが空の関連リストにバインドされている場合
- 方針に基づいてデータ・グリッドに項目を追加し、項目数がデータ・グリッドの高さを超えた場合
2 つの異なるサーバー・マシンで Web サービスとクライアントのホスティングを行う場合に、Web サービス呼び出しが失敗します。既知の回避方法はありませんが、Macromedia の Web サイトにはこのクロスドメイン問題のある種の解決策が掲載されています。Web サービス・サーバーとクライアントを同じサーバーでホスティングすることを提案します。
プロジェクトからこれらの警告を除去するには、警告の表示された Java ソース・フォルダー、プロジェクト、またはパッケージを右クリックします。次に、コンテキスト・メニューから「ソース」>「インポートの編成 (Organize imports)」 を選択します。
このエラーを受け取る可能性があるのは、同じページに複数のクライアント・データを含むページに Faces Client コンポーネントをドロップする場合です。この問題の次善策として、JSP の「ソース」ビューに切り替えて、<h:form> タグのすぐ下にある <odc:clientData> タグをすべて移動します。
ツリー・コンポーネントをページにドロップするか、ツリー・コンポーネントのソースをページに切り貼りすると、<p> タグが <odc:tree> タグの親になってしまうことがあります。その結果、HTML ページ上のツリー・コンポーネントのレンダリングが誤りになります。 この問題の次善策として、<odc:tree> タグの周囲の <p></p> タグを削除します。
サムネール・ビューまたはプロジェクト・エクスプローラー・ビューからタブ・パネルにイメージ・ファイルをドロップすることはできません。 イメージ・ファイルをパネル内に置くためには、パレット・ビューの HTML タグ・ドロワーからイメージをドラッグ・アンド・ドロップしてから、ドロップする必要のあるイメージ・ファイルを選択します。
Faces Client コンポーネントを含むプロジェクトに対して、(WebSphere Application Server V5.1 から V6.0 へ) サーバーをターゲット変更するマイグレーション・ガイドのステップを実行した後、リンク切れの警告が表示されることがあります。これらの警告を受け取った場合、または WebSphere Application Server V6.0 で実行するときにページが正しく表示されない場合は、Web プロジェクトを閉じてから再び開いてください。
Rich Text Editor は、内部ブラウザーを使用してサーバー上で実行される場合に、読み取り専用であるかのように動作します。この問題が発生するのは、ページが最初にロードされる場合か、サーバーにページをサブミットした後にロードされる場合です。この問題を回避するには、外部ブラウザーを使用してください。
この問題は、Faces ページに URL の Faces 接頭部を、ページ・リソース (CSS およびイメージ) に相対パスを使用すると発生します。この問題は 2 つの方法で回避できます。
1) ページ・リソースに完全修飾パス名を使用する。
2) 拡張子が .faces であり、接頭部は faces/ でない Faces ページの URL を使用する。Faces ページは、 Faces サーブレットから操作する必要があります。プロジェクト web.xml ファイルでは、この Faces サーブレットに 2 つのマッピングがデフォルトで追加されます。
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping><servlet-mapping>
Faces フォルダーも Faces 拡張子を持つファイルも実際には存在しません。これらを Faces ページ URL の一部にする必要があるだけです。 page1.jsp をアドレス指定するために、/faces/page1.jsp または /page1.faces を使用できます。いずれの形式でも構成可能です (例えば、拡張子として .page を使用できます)。
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
データ・グリッドが、列が 1 つのみの関連レコード・リストから作成されたクライアント・データにバインドされている場合、生成されるバインディングは不正になります。例えば、正しいバインディングの {pc_Index1.surveys} ではなく、#{pc_Index1.surveys[0].NAME} が生成されます。回避策は、JSP ソースを手作業で編集し、(上の例のような) 余分なインデックスと列名を除去します。
この問題は、ワークスペースのビルド操作が完了していないために発生します。すべてのエラーを除去するには、「プロジェクト」メニューに移動して「クリーン... (Clean...)」を選択します。次に、FacesClientTutorial プロジェクトのクリーンを選択します。クリーンが完了して再ビルド操作が終了すると、エラーがすべてなくなります。
ヘルプ・トピック「Faces Client コンポーネントのある JavaServer Faces リソースのマイグレーション (Migrating JavaServer Faces resources with Faces Client Components)」の一部のバージョンで、以下の項目の情報が欠落していることがあります。
この情報が欠落している場合、最初の CD のルート、または電子イメージの disk1/migrate.html の下にある HTML バージョンのマイグレーション・ガイドを参照してください。
- Faces Client コンポーネントを含むプロジェクトのターゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に変更する際に、2 つの問題が発生する可能性があります。
- 既に生成済みのクライアント・データ・メディエーター・クラスはコンパイルされません。
- プロジェクトのターゲット・サーバーを WebSphere Application Server V6.0 に変更した後、WDO にバインドされたツリー・ビューの Faces Client コンポーネントがサーバー上で実行できなくなります。
- Linux プラットフォームまたは英語以外のロケールでの動作に関する情報。
JavaServer Face (JSF) ページが表示される際にサブミットのコンテンツが欠落するという問題があります。これは、ページの状態の保持方法と、相対パス (例えば、theme/stylesheet.css) で指定されたページ・リソース (CSS やイメージ・ファイルなど) に対する要求の処理方法に関係する可能性があります。この問題を回避するには、JSF ページへの URL で .faces 拡張子のオプションを使用します。例えば、JSF ページ myPage.jsp の URL は、/MyWebApp/myPage.faces となります。この拡張子は、プロジェクトの web.xml ファイルで定義します。別のオプションとして、状態をクライアントに保存することも選択できます。