© Copyright International Business Machines Corporation 2006. All rights reserved.
以下のものは非推奨となりました。 使用は推奨できません。
- クライアント・データおよび関連ツール (「クライアント・データ」ビューなど)
- Faces Client コンポーネント
<odc:dataGrid>
(データ・グリッド)<odc:webService>
(Web サービス)<odc:clientData>
<odc:clientBinder>
ツリー
<odc:tree>
および図表<odc:graphDraw>
は、サーバー・データを使用するために使用可能になっています。
JSF JARS をマイグレーションしないで V7 より前の JSF アプリケーションをインポートし、アプリケーションの開発を続行する場合、V7 での新しいタグはプロジェクト JAR 内にインクルードされず、実行時に使用可能になりません。 必ず V7 より前の JARS をマイグレーションしてください。
ツリー・コントロール
<odc:treeNodeAttr>
タグは、 SDO データにバインドされる場合と WDO データにバインドされる場合とでは、その className 属性に使用される値が異なります。 WDO を使用するサーバー (WebSphere® Application Server 5.1 など) から SDO を使用するサーバー (WebSphere Application Server 6.1 など) へプロジェクトをマイグレーションした後に、 これを修正する最も簡単な方法は、すべてのツリー・コントロールを除去して再作成することです。
v6.0 では、
<hx:commandExButton>
のタイプが「発行」に設定され、ラベルと単一の背景イメージのみがあった場合 (例えばvalue="submit" image="button.gif"
) には、 イメージとラベルではなく、イメージのみがレンダリングされました。 v7.0 ではこの問題が修正されています。つまり、v7.0 を使用する場合には、 ラベルと単一の背景イメージの両方を持つボタンが v6.0 の場合とは異なる方法でレンダリングされるように修正されています。同様に、
<hx:commandExButton>
のタイプが「リセット
」に設定され、単一の背景イメージ (または背景イメージとラベル) があった場合には、 イメージのみがレンダリングされ、ボタンは発行ボタンとして扱われました (ボタンのタイプは無視されていました)。 v7.0 ではこの問題が修正されています。つまり、タイプが「リセット
」に設定されているというマークが付いたボタンが、ページを発行する代わりに、そのページをリセットするように修正されています。
<jspPanel>
タグ属性style
およびstyleClass
は、使用できなくなりました。これらの属性は、JSP パネル・コンポーネントのレンダリングには使用されません。この製品の前のバージョンで作成された JSF アプリケーションをインポートする場合、
<jspPanel>
タグはエラーを表示します。このエラーを解決するには、 「ソース」ビュー内の JSP ソースを編集して、style
およびstyleClass
属性をプロジェクト内のすべての<jspPanel>
タグから除去します。
前のバージョンの製品を使用して作成されたワークスペースにプロジェクトをインポートすると、 Faces サポートがインストールされても、プロジェクトのターゲット・ランタイムが選択されなかったことを示すダイアログ・ポップアップが表示されます。この警告は正確でないことがあり、ランタイムは、マイグレーション・プロセスの完了後に正しく定義されます。ランタイムが設定されているかどうかを確認するには、 「プロジェクト」>「プロパティー」と右クリックして、 「ターゲット・ランタイム」を選択します。定義したサーバーの隣にチェック・ボックスが表示された場合、その後のアクションは不要です。表示されない場合は、サーバーのうち 1 つを選択します。
注: この回避方法は、 クライアント・データ・モデルが同じページ・データ・ノードまたは同じ名前のページ・データ・ノードから作成される場合は必要ありません。
v7.0 では、ページ上に同じ Bean クラスから作成されたクライアント・データ・モデルが複数ある場合、生成 (または再生成) 時に、2 番目のモデル用に 2 番目の ecore または emap ファイルが誤って作成されます。マイグレーション・ガイドに従って、クライアント・データ・プロジェクトをマイグレーションする場合は、 クライアント・データ・モデルを再生成し、複数のクライアント・データ・モデルを含むマイグレーション済みのページを持つプロジェクトが、 その影響を受けるようにする必要があります。以下に、単純なシナリオを示します。
- java.util.Date Bean に基づいて 2 つのページ・データ (例えば myDate1 および myDate2) を作成します。
- それぞれのページ・データごとに、 myDate1 の次に myDate2 という順序で同じ名前のクライアント・データ・モデルを作成します。
回避方法: 両方のモデルでページが機能するようにするには、 com.ibm.dynwdo4jsmediators パッケージと OdysseyBrowserFramework.properties ファイル内の対応するエントリーから myDate2.ecore と myDate2.emap を削除します。
クライアント・データは、大量の JavaScript™ をページに出力します。前のリリースでは、JavaScript はエンコードされませんでした。 これは、同じページ・データ・ソースを使用して複数のポートレットでクライアント・データを使用した場合、ページへの JavaScript 出力がすべてのポートレットについて同じになることを意味していました。
この振る舞いは、2 つのポートレットがクライアント・データにバインドされている場合、同じクライアント・データ・オブジェクトにバインドされているように見えます (これは、 JavaScript の 2 番目のセクションによって最初のセクションが上書きされるためです)。 また、これによって 2 つのポートレットの相互作用が可能になり、一方が変更されるとそれが両方に反映されるようになります。
これは、ページ上で、クライアント・データを使用し、相互に独立して機能する複数のポートレットが必要な場合に問題になります。異なるページ・データ・ソースを持つ同一のページに、クライアント・データを使用する 2 つのポートレットがあると、 JavaScript エラーが発生します。これは、ポートレットがレンダリングしなくなる原因にもなります。
これらの問題を修正し、クライアント・データ・ポートレットが WSRP を介して稼働するようにするには、 各ポートレットに対して固有になるように、クライアント・データ JavaScript 変数をエンコードする必要があります。これにより、クライアント・データ JavaScript セクションが相互に独立して機能するようになります。
V7.0 では、すべてのクライアント・データがエンコードされます。
ページ上のポートレット間でクライアント・データを共用する場合は、 以下のコンテキスト・パラメーターで web.xml を更新する必要があります。
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>false</param-value>
<description></description>
</context-param><param-value> を false に設定することにより、クライアント・データ・エンコードを除去します。
Encode_Data パラメーターの使用と、ページ・データを使用する図表およびデータ・ツリー・コンポーネントに対するその効果
図表およびデータ・ツリーは、ページ上に XML データ・オブジェクトを配置することにより、ページ・データを使用します。図表およびデータ・ツリーのページ・データは、それらのコンポーネントのクライアント・データに極めて密接にリンクされています。デフォルトでは、このデータがエンコードされます。以下に示す <context-param> (通常、クライアント・データ・エンコードを除去するために使用されます) を web.xml ファイルに設定すると、 図表およびデータ・ツリーのページ・データ・エンコードも除去されます。ページ・データを使用する他のコンポーネントは影響を受けません。 ページ・データをエンコードせずにそのままにする、 つまり、ページ上に、ともに図表またはデータ・ツリーが含まれている 2 つのポートレットがあると、 問題が発生する場合があります。これらのエラーには、JavaScript エラーおよび/またはいずれかのポートレットが正しく表示されないというエラーが含まれます。
このデータをエンコードするクライアント・データの場合と同様に、 ページ上で 2 つのポートレットがそれぞれ独立して稼働できるようにして、 WSRP サポートを使用可能にするためには、web.xml から次の <context-param> を除去するか、 <param-value> を true に設定する必要があります。
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
これは、ページの上部に表示されます。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
これにより、Web ブラウザーが標準モードになります。標準モードでは、
HTML
およびbody
要素がそのコンテンツにスナップされます。互換モード (デフォルトの HTML モード) の場合のようにウィンドウを埋めることはありません。高さをパーセントで表すタブ・パネルがページ上に単独で表示された場合、ペインの高さに関連した表示の問題が発生します。
これを修正するには、そのタブ・パネルを高さが設定されているコンテナーに入れるか、ページ上部の文書タイプを以下に変更します。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
文書タイプを以下に設定すると、標準モードのタブに関連した表示の問題が発生します。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
これは、文書タイプを以下に変更することにより修正されます。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
カレンダー・タイプがアラビア語に設定されている場合、
<hx:convertDateTime>
タグは正しい JavaScript を生成しません。 その結果、クライアント・サイドの妥当性検査、入力プロンプト、日付ピッカー・ヘルパー、 および小型カレンダーが正しく動作しません。 生成された JavaScript が初期化されると、エラーが表示されます (あるいはコンポーネントが正しく動作しません)。回避方法: クライアント・サイドの妥当性検査やプロンプトをオンにしないようにします。コンバーターを介してアラビア語カレンダーを使用する場合は、日付ピッカー・ヘルパーをオンにしないでください。
WebSphere® サーバー・ランタイムをターゲットとする場合は、 WebSphere Web (共存) プロジェクト・ファセットがご使用の Web プロジェクト用に選択されていることを確認してください。
回避方法: プロジェクトの作成時に「動的 Web プロジェクト」ウィザードの 2 番目のページでファセットを選択します。または、プロジェクトがすでに存在している場合は、「プロパティー」ダイアログの「プロジェクト・ファセット」ページを使用してファセットを選択します。 WebSphere サーバーをターゲットとする Web プロジェクトを作成する場合、プロジェクト・ウィザードの先頭ページの「構成」ドロップダウン・リストから「Faces プロジェクト」または「XDoclet 付き動的 Web プロジェクト」を選択すると、 WebSphere Web (共存) ファセットは自動的に選択されなくなります。ウィザードの次のページに進み、このファセットを選択します。「構成」リストから「<custom>」を選択すると、WebSphere ランタイムをターゲットとした場合にファセットが適宜選択されます。
<hx:dataTableEx>
内で<hx:columnEx>
を使用し、垂直スクロールが使用可能になっている (scrollSize が設定されている) 場合に、 テーブルの 1 つ以上の列幅がパーセンテージ・ベースの幅に設定されていると、 レンダリングされたテーブルでは、ページの文書タイプがブラウザーによって (W3C 遷移に対して) W3C 標準であると解釈された場合、列見出しと列コンテンツが相互に位置合わせされないことがあります。これは、例えば、文書タイプにloose.dtd
宣言が含まれている場合に起こります。
回避方法: 列幅を固定する (パーセンテージ・ベースにしない) か、文書タイプが必ずtransitional
文章タイプに解決されるようにします (例えば、loose.dtd 宣言を除去します)。
<hx:panelDialog>
では、 位置決め (水平または垂直) がrelative
に設定され、位置決めのベースとして使用するタグ (ダイアログの位置決めの基準となるタグ) がスクロールするページ内にあり、 タグが表示され、ページが上部にスクロールしない場合、ダイアログが表示されたときに、そのダイアログの位置が正しく表示されないことがあります (通常、 先頭からかなり離れた場所、またはかなり左寄りに表示されます)。回避方法: 相対的位置決めが必要な場合は、 ベース・タグがページの上部付近にあることを確認してください。 別の方法として、他のいずれかのタイプの位置決めを使用します。
データ・テーブル (
<h:dataTable>
または<hx:dataTableEx>
) が、AJAX が使用可能なパネル内にあり、 行選択が使用可能になっている (テーブルに<hx:inputRowSelect>
が含まれている) 場合に、 AJAX を介してテーブルを再フェッチすると、選択列内のチェック・ボックスは正しく機能しません。 これは、初めてレンダリングされた場合に (のみ) 正しく機能します。回避方法: 現在のところ、この問題の回避方法はありません。 AJAX が使用可能になっているパネルにテーブルを入れないでください。
ソース属性を使用してターゲット・ページで検索するパネルの ID を指定する際に、 それが
<hx:ajaxExternalRequest>
が付加されているソース・ページのパネルの ID と異なっている場合、 Internet Explorer (IE) で<hx:ajaxExternalRequest>
が正しく機能しないことがあります。以下に、例を示します。<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
。 この問題は、IE でのみ発生し、ターゲット・パネルがターゲット・パネルがグリッド、ボックス、 またはレイアウト (HTML テーブルとしてレンダリングされパネル) の場合にのみ発生します。回避方法: ID が同じであることを確認するか、ターゲット・パネルを panelGroup 内にラップします。
<hx:ajaxRefreshRequest>
、<hx:ajaxRefreshSubmit>
、<hx:ajaxExternalRequest>
、および<hx:inputHelperTypeahead>
のinProgresss
属性は正しく機能しません。 この属性の値を設定しても効果はありません。 将来のリリースとの互換性を確実にするために、この値は設定しないでください。
入力フィールドに
<hx:inputHelperTypeahead>
が付加されている場合に、 そのフィールドにスペース文字および/または句読文字 (アンパーサンドやパーセントなど) を入力すると、 構成される候補のリストにこれらの文字を含む「個の一致」が含まれなくなります。例えば、ユーザーが % と入力した場合、使用する「辞書」に % で始まるワードがあっても、個の一致は戻されません。
Firefox バージョン 1.5.0.8 からは一部の HTML DOM 属性の振る舞いが変化したため、 Firefox でレンダリングされた場合に
panelDialog
が正しく位置決めされなくなりました。 この問題は通常、ダイアログが相対的に位置決めされた場合に発生しますが、 その他に、本文コンテンツのサイズがブラウザー・ウィンドウの高さ「未満」である場合 (つまり、ページが垂直にスクロールしない場合) にも発生する可能性があります。回避方法: 本文にコンテンツを追加して (高さが設定されている <div> などの空白の場合であっても)、 ページの垂直スクロール・バーが常にオンであるようにすると、この問題が解決されることがあります (これは、 ブラウザー・ウィンドウの正確な大きさとコンテンツによっても異なります)。
styleClass がデフォルト・クラス
pagerDeluxe
以外のものに設定されている場合、<hx:pagerDeluxe>
は正しい HTML マークアップをレンダリングしません。 ページャーのボタンは、常にその名前にデフォルト・クラス名を使用するクラス名によってレンダリングされます。回避方法:
- クラス名は、pagerDeluxe 以外のものに変更しないでください。
- 異なるクラス名を使用する場合は、ボタンにレンダリングされるクラス名の説明に使用する CSS を調整してください。