Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.2.0) E82918-03 |
|
![]() 前 |
![]() 次 |
この章の内容は次のとおりです。
JDeveloperでは、特定の要件に基づいてADF Facesコンポーネントの属性を保存できます。
特定のADF Facesコンポーネントには、特定のユーザーのために保存できる属性があります。たとえば、panelBox
コンポーネントのdisclosed
属性の値を、現在のセッションの間、特定のユーザーのために保存できます。アプリケーションのmyOrders
ページには、オーダー情報を示す4つのpanelBox
コンポーネントがあります。デフォルトでは、これらは図52-1に示すように開いています。
図52-1 デフォルトで開いているpanelBoxコンポーネント
図52-2のように、1つのボックスを折りたたむとします。
図52-2 panelBoxコンポーネントを折りたたむ場合
このアプリケーションはユーザー・カスタマイズを許可するように構成されているため、ユーザーのセッション中にユーザーがこのページに戻ると、支払情報ボックスは折りたたまれたままです。これらの変更内容をユーザーのセッションに永続させるには、プロジェクトに対してユーザー・カスタマイズを有効にするだけで済みます。
注意:
ユーザー・セッションは、ユーザーがアプリケーションにログインすると開始され、ユーザーがアプリケーションを終了すると終了します。アプリケーションの使用中、ユーザーはアプリケーションの境界を越えて(ピア・アプリケーションなどに)移動し、そこでアプリケーションを終了する場合がありますが、ユーザー・セッションはその時点で終了します。
表52-1に、ユーザー・カスタマイズを許可するようにアプリケーションを構成した後に、ADF Facesアプリケーションによって永続される属性値の変更を示します。
表52-1 暗黙的に永続する属性値
コンポーネント | 属性 | 実行時の効果 |
---|---|---|
|
|
ユーザーは、ヘッダーのアイコンを使用してコンテンツを表示または非表示にできます。ユーザーの直近のアクションに基づいて、詳細コンテンツが表示または非表示になります。 |
|
|
複数の |
|
|
ユーザーはパネルのサイズを変更でき、そのサイズは保持されます。 |
|
|
ユーザーはスプリッタのいずれかの面を閉じることができます。閉じられた状態は、ユーザーによる最終の構成として保持されます。 |
|
|
パネルのスプリッタの位置が、ユーザーによって最後に移動された位置のままになります。 |
|
|
エディタは、ユーザーが最後に選択したモード(WYSIWYGまたはソース)で表示されます。 |
|
|
現在の表示でアクティブとみなされる日は、アクティブな日のままになります。 |
|
|
現在アクティビティを表示しているビュー(日、週、月またはリスト)が保持されます。 |
|
|
ユーザーは |
|
|
ユーザーは |
|
|
ユーザーが |
|
|
ユーザーが |
|
|
ADF Facesの列は、ユーザーが実行時に並べ替えることができます。 |
|
|
ADF Facesの列は、スクロールされないように固定できます。列の |
|
|
列のコンテンツを折り返すかどうかを指定します。ユーザーがこの属性値を変更できるようにするコードを作成する必要があります。たとえば、ユーザーが値を |
|
|
選択された列は、ユーザーが最後に選択した列に基づきます。 |
|
|
ユーザーの直近のアクションに基づいて、列が表示または非表示になります。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、ユーザーが値を |
|
|
列の幅が、ユーザーが最後に設定したサイズのままになります。 |
|
|
ADF Facesの表には、ユーザーが属性値で表の行をフィルタ処理できるコンポーネントを含めることができます。フィルタを使用するよう構成されている表では、ユーザーの直近のアクションに基づいて、フィルタは表示または非表示になります。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、ユーザーが値を |
|
|
グラフの時間軸上に表示されるデータの時間範囲は、すべてのデータ視覚化グラフ・コンポーネントに指定できます。デフォルトでは、すべてのデータが表示されます。時間範囲は、最後または最初のデータ・ポイントからの相対的時間範囲、または明示的時間範囲にも設定できます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。たとえば、グラフの時間範囲を選択するためのドロップダウン・リストを作成できます。 |
|
|
データ視覚化プロジェクトの凡例、リソース使用率およびスケジュール・ガント・チャート・コンポーネントは、情報パネル内で表示されるかされないかのいずれかです。ユーザーがこの属性値を変更できるように(汎用を表示するための非表示および表示のボタン)コードを記述することが必要になります。 |
|
|
データ視覚化階層ビューア・コンポーネントでは、上から下への垂直、ツリー、円、放射など、9つの階層レイアウト・オプションをサポートしています。ユーザーは、マップ・コントロール・パネルでレイアウトを変更でき、最後に選択されたレイアウトが保持されます。 |
|
|
このデータ視覚化地理マップ・コンポーネント属性では、マップの初期ズーム・レベルを指定します。ズーム・レベルは、ベース・マップの一部としてマップ・キャッシュ・インスタンスで定義されます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。 |
|
|
このデータ視覚化地理マップ・コンポーネント属性では、startingXおよびstartingYによって定義されるマップの中心位置や、点テーマのすべての点を含む、マップの全座標のsrid(空間参照ID)を指定します。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。 |
|
|
このデータ視覚化地理マップ・コンポーネント属性では、マップの中心位置のXおよびY座標を指定します。座標のsridはsrid属性で指定します。srid属性が指定されていない場合、その値はマップの中心位置の経度であると想定されます。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。 |
|
|
パネルのスプリッタの位置が、ユーザーによって最後に移動された位置のままになります。 |
|
|
プロジェクト、リソース使用率およびスケジュールのガント・チャートのデータ視覚化コンポーネントでは、ガント・チャートの主時間軸および副時間軸の指定にこのファセットを使用します。タイム・スケール( |
|
|
データ視覚化の面、棒、コンボ、折れ線、散布およびバブルの各グラフ・コンポーネントでは、この子タグ属性を使用して、タイム・セレクタの開始および終了日付を明示的に指定します。この属性では、値バインディングのみがサポートされています。ユーザーがこの属性値を変更できるようにするコードを記述する必要があります。 |
MDSリポジトリを使用して表52-1にリストした属性の値をセッション間で永続できるように、アプリケーションを構成できます。たとえば、アプリケーションでMDSリポジトリへの永続化が許可されている場合、図52-2に示すように支払情報ボックスを折りたたむことができ、次回アプリケーションを開いたときに折りたたまれた状態になります。
注意:
リポジトリへの永続化を有効にするには、事前に『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項に説明されているすべてのMDS構成手順を実行する必要があります。
ADF Facesで使用できる自動永続性のほかに、次のタイプの変更に対する独自のカスタム・ユーザー・カスタマイズ機能を作成できます。
属性値の変更
ファセットの追加または削除
子コンポーネントの追加または削除
子コンポーネントの並替え
子コンポーネントの別の親への移動
これらのタイプのカスタム・ユーザー・カスタマイズを作成する場合、永続性を処理するAPIを呼び出すコードを追加する必要があります(たとえば、イベント・ハンドラで)。
アプリケーションで変更永続性フレームワークを使用できるようにするには、まずアプリケーションでユーザー・カスタマイズを許可できるようにする必要があります。このプロセスには、変更内容をセッションまたはMDSリポジトリのどちらに永続させるかの決定が含まれます。
変更内容をセッションに永続させる場合、デフォルトでは、表52-1に示すすべての値がユーザーのセッションに保存されます。ただし、リポジトリに永続させる場合は、これらの属性値のうちどれをリポジトリに永続させるかを明示的に構成する必要があります。これらのすべての属性値を永続させるのではなく、コンポーネントの特定属性値の変更のみが永続されるように、またはコンポーネントの特定インスタンスのみが変更を永続させるように、変更を制限できます。
注意:
addComponentChange()
メソッドを使用して、af:forEach
タグまたはaf:iterator
タグの(サブツリーの)内部に含まれるコンポーネントの変更は、永続できません。この構造では表示ツリーに1つのコンポーネントの複数のコピーが表示されますが、JSPドキュメントには各コンポーネントは1回しか表示されないためです。ただし、addDocumentChange()
メソッドでは、このようなコンポーネントの永続性を許可します。「変更永続性フレームワークAPIに関する必知事項」のDocumentChange
クラスとComponentChange
クラスの説明を参照してください。
変更内容をMDSリポジトリに永続させるアプリケーションをデプロイする際には、アプリケーションのEARアセンブリにメタデータ・アーカイブ(MAR)プロファイルを作成する必要があります。「デプロイメント・プロファイルの作成方法」を参照してください。
ユーザー・カスタマイズを使用し始める前に、他の機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。
MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。
MDSフレームワークを使用すると、顧客がカスタマイズしてからデプロイできる、カスタマイズ可能なアプリケーションを作成できます。「MDSによるアプリケーションのカスタマイズ」を参照してください。
Oracle WebCenter Portalの機能により、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。実行時のカスタマイズの詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のOracle WebCenter Portalの開発の概要に関する項を参照してください。
アプリケーションで変更永続性フレームワークを使用できるようにするには、web.xml
およびadf-config.xml
ファイルを編集する必要があります。
アプリケーションでユーザー・カスタマイズを許可できるようにするには(一部のADF Facesコンポーネントが提供するデフォルトの変更に対して、またはユーザーが作成するカスタム機能に対して)、変更永続性フレームワークを使用するようにアプリケーションを構成し、変更内容を永続させる場所(セッションまたはMDSリポジトリ)を決定する必要があります。
注意:
変更内容をMDSリポジトリに永続させる場合は、変更永続性を使用するようにADF Facesアプリケーションを構成する前に、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項に説明されているすべてのMDS構成手順を実行する必要があります。
アプリケーションで変更永続性フレームワークを使用できるようにするには、web.xml
ファイルとadf-config.xml
ファイルを編集します。
始める前に:
実行時ユーザー・カスタマイズの機能に関する知識が役立つ場合があります。詳細は、「Fusion Webアプリケーションの実行時ユーザー・カスタマイズの有効化」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、実行時ユーザー・カスタマイズを有効化するアプリケーションを開く(または作成する)必要があります。
ユーザー・カスタマイズを有効にするには:
変更内容をセッションにのみ保存するよう選択すると、JDeveloperによりCHANGE_PERSISTENCE
コンテキスト・パラメータがweb.xml
ファイルに追加され、値がsession
に設定されます。このコンテキスト・パラメータでは、永続性の処理に使用されるChangeManager
クラスが登録されます。かわりに、変更内容をMDSリポジトリに保存するよう選択すると、次の例に示すように値はoracle.adf.view.rich.change.FilteredPersistenceChangeManager
に設定されます。
<context-param> <param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name> <param-value> oracle.adf.view.rich.change.FilteredPersistenceChangeManager </param-value> </context-param>
ヒント:
adf-config.xml
ファイルの構成または個々のJSFページに基づいてカスタマイズを制限せずに、常に変更内容をセッションではなくMDSリポジトリに永続させる場合は、必要に応じて、この値を手動でoracle.adf.view.rich.change.MDSDocumentChangeManager
に設定できます。
リポジトリへの永続化を選択すると、JDeveloperにより次の処理も行われます。
次のJARがクラス・パスに追加されます(ない場合)。
javatools-nodep.jar
facesconfigmodel.jar
taglib.jar
別のコンテキスト・パラメータをweb.xml
に追加して、MDSJSPProviderHelper
クラスを登録し、MDSカスタマイズ・ドキュメントとベースJSPドキュメントのマージを処理します(次の例を参照)。
<context-param> <param-name>oracle.adf.jsp.provider.0</param-name> <param-value>oracle.mds.jsp.MDSJSPProviderHelper</param-value> </context-param>
ADF Faces Change Managerランタイム11ライブラリをプロジェクトに追加します。
adf-config.xml
ディスクリプタ・ファイルで、persistent-change-manager
要素をMDSDocumentChangeManager
に設定します。これは、変更内容の永続化に使用するクラスです。次の例は、MDSリポジトリに対して永続化するための構成を示しています。
<persistent-change-manager> <persistent-change-manager-class> oracle.adf.view.rich.change.MDSDocumentChangeManager </persistent-change-manager-class> </persistent-change-manager>
JSF JSPページをXMLドキュメントとして作成します。「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。
また、変更内容をMDSリポジトリに保存し、Faceletをアプリケーションに含めることを選択した場合、JDeveloperによって、faceletCache
コンテキスト・パラメータがweb.xml
ファイルに追加されます。このパラメータの値は、次の例に示すように、oracle.adfinternal.view.faces.facelets.rich.MDSFaceletCache
に設定されます。
<context-param> <param-name>com.sun.faces.faceletCache</param-name>
<param-value>oracle.adfinternal.view.faces.facelets.rich.MDSFaceletCache</param-value>
</context-param>
Faceletキャッシュはアプリケーションのパフォーマンスを向上し、キャッシュ容量はサーバーのMDSで構成できます。『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。
任意のタイプの変更永続性(セッションまたはリポジトリ)を使用するようにアプリケーションを構成できます。デフォルトでは、属性値はユーザーのセッションに永続化されます。リポジトリに変更を永続化することを選択する場合は、属性値を宣言する必要があります。
変更内容をMDSリポジトリに永続させる場合、デフォルトでセッションに永続させる属性値のうち(表52-1を参照)、リポジトリにも永続させる属性値を決定する必要があります。または、永続させない変更を構成することもできます。
ヒント:
多くの場合、構成はシステム管理者がadf-config.xml
で設定します。コンポーネントのpersist
およびdontPersist
属性により、ページ作成者は必要に応じてこの設定をオーバーライドできます。
たとえば、列のwidth
属性の値はリポジトリに永続させないが、列の他のデフォルト属性の変更はすべて永続させるとします。この場合、永続させる他のデフォルトの列値を明示的に設定し、またwidth
属性を永続させないようにアプリケーションを明示的に構成する必要があります。
注意:
「カスタム・ユーザー・カスタマイズの実装」の説明に従ってカスタム・ユーザー・カスタマイズ機能を作成した場合は、これらの属性値または操作も明示的に宣言する必要があります。
これらの値は、adf-config.xml
ファイルの概要エディタを使用して設定(または設定解除)します。図52-3に、column
コンポーネントの特定の属性値のみを永続させる概要エディタを示します。
図52-3 adf-config.xmlファイルの概要エディタ
設定後、ページ上の特定コンポーネントの永続性をオーバーライドできます。たとえば、1つの表の列に対してのみ、width
属性の変更を許可しないとします。アプリケーションの他の表では、その属性の変更を永続させます。この場合、width
属性の変更をグローバルに永続させるように列を構成し、その後その1つの表に対して、JSFページで直接グローバル構成をオーバーライドします。詳細は、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。
注意:
セッションの永続性のみを有効にした場合、表52-1のすべての属性値がセッションに永続されます。これをグローバルにまたはインスタンスでオーバーライドする方法はありません。
デフォルトでは、いずれかのタイプの変更永続性(セッションまたはリポジトリへの)を使用するようにアプリケーションを構成する際、表52-1に示すすべての属性の値が、常にユーザーのセッションに永続化されます。変更内容をリポジトリに永続させるように構成した場合は、値をそのリポジトリに永続させる属性を宣言する必要があります。永続させない値がある場合は、それらの値も構成する必要があります。
始める前に:
実行時ユーザー・カスタマイズが永続される方法に関する知識が役立つ場合があります。詳細は、「ユーザー・カスタマイズの構成」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、実行時ユーザー・カスタマイズを有効化するアプリケーションを開く(または作成する)必要があります。
属性値のリポジトリへの永続性を宣言するには:
注意:
カスタム・ユーザー・カスタマイズを実装する場合は(「カスタム・ユーザー・カスタマイズの実装」を参照)、adf-config.xml
を手動で編集して構成を追加する必要があります。ユーザー・カスタマイズの構成方法の例は、「変更永続性の構成時の処理」を参照してください。
adf-config.xml
ファイルでコンポーネント・タグと永続させる属性値を選択すると、JDeveloperによってコンポーネントのタグ・ライブラリ情報と永続させる属性が入力されます。次の例は、panelBox
コンポーネントのdisclosed
属性の値を永続化するエントリを示しています。
<taglib-config> <taglib uri="http://xmlns.oracle.com/adf/faces/rich"> <tag name="panelBox"> <attribute name="disclosed"> <persist-changes> true </persist-changes> </attribute> ... </tag> </taglib> </taglib-config>
コンポーネントのpersist
およびdontPersist
属性を使用して、コンポーネントにグローバルに設定されているすべての永続性構成をオーバーライドできます。
アプリケーションでユーザー・カスタマイズを使用できるようにしたら、ページ上の特定コンポーネントのユーザー・カスタマイズを制御できます。
デフォルトでは、このフレームワークはすべてのコンポーネント・インスタンスの変更内容を、adf-config.xml
ファイルの構成に基づいて永続させます。persist
およびdontPersist
属性を使用して、コンポーネント・インスタンスごとに何を永続させるかおよび何を永続させないかを明示的に設定することで、このデフォルト動作をオーバーライドできます。
注意:
persist
およびdontPersist
属性を使用して指定されているフィルタ・ルールは、MDSリポジトリに対して永続化する場合にのみ適用されます(「ユーザー・カスタマイズを有効にする方法」を参照)。これらのルールは、セッション・スコープ内の永続性には適用されません。
なんらかの理由で永続性が失敗した場合、(たとえば、いずれかのフィルタ・ルールが失敗した場合またはMDSリポジトリ・エラーがある場合)、値はセッション・スコープ内にのみ保存されます。
persist
およびdontPersist
属性をサポートするコンポーネントを次に示します。
panelBox
showDetail
showDetailHeader
showDetailItem
column
tree
treeTable
panelSplitter
calendar
dvt:projectGantt
dvt:resourceUtilizationGantt
dvt:schedulingGantt
dvt:ganttLegend
dvt:hierarchyViewer
dvt:timeAxis
persist
属性およびdontPersist
属性を使用して、コンポーネントにグローバルに設定されているすべての永続性構成をオーバーライドできます。
ヒント:
多くの場合、構成はシステム管理者がadf-config.xml
で設定します。persist
およびdontPersist
属性により、ページ作成者は必要に応じてこの設定をオーバーライドできます。
始める前に:
実行時ユーザー・カスタマイズが個別ページで制限される方法に関する知識が役立つ場合があります。詳細は、「個々のJSFページでのユーザー・カスタマイズの制御」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開き、ユーザー・カスタマイズの動作を変更するページを開きます。
JSFページでユーザー・カスタマイズを実装するには:
「アプリケーション」ウィンドウで、変更を永続化させるコンポーネントを含むページをダブルクリックします。
コンポーネントの永続可能なすべての属性を永続させる場合:
「プロパティ」ウィンドウで、「拡張」セクションを開きます。
「永続」フィールドのドロップダウン・リストから、「すべて使用可能」を選択します。
属性を永続させない場合は、永続させないフィールドに対して手順2を繰り返します。
コンポーネントの複数の属性を永続できるが、それらすべては永続させない場合:
「プロパティ」ウィンドウで、「永続」フィールドの右側のドロップダウン・メニューから、「編集」を選択します。
「プロパティの編集」ダイアログで、永続させる属性を「選択可能」から「選択済」に移動します。
属性値を永続させない場合は、永続させないフィールドに対して手順4を繰り返します。
注意:
persist
およびdontPersist
属性を使用して指定されているフィルタ・ルールは、グローバルなコンポーネント・レベルの制限を設定するadf-config.xml
構成より優先されます。
dontPersist
属性に指定された値は、persist
属性に指定された値より優先されます。たとえば、panelBox
コンポーネントでpersist
属性とdontPersist
属性の両方の値としてdisclosed
を設定した場合、disclosed
属性の値は永続されません。
またはpersist
属性またはdontPersist
属性の値をAll Available
に設定した場合、「編集」ダイアログを使用して選択肢として入力された値および移動は無視され、使用可能なすべての属性値が永続されるか、または永続されません。
変更内容をセッションに永続させるようアプリケーションを構成している場合、セッション中に行われた変更はすべてデータ構造内のセッション変数に記録されます。これは、ビューIDとコンポーネントのID属性値によって索引付けされます。後続のビューの作成またはビューのリストア・フェーズでページがリクエストされるたびに、すべての変更内容が追加されたときと同じ順序で適用されます。つまり、セッションの間に登録された変更は、同じセッションの後続のリクエストでのみ適用されます。
変更内容をMDSリポジトリに永続させるようにアプリケーションを構成している場合、ビューの背後のJSPドキュメントに対してMDSで保持するDocument Object Modelを変異させることで、セッション中に行われた変更が記録されます。ADFコントローラによって登録されたJSFフェーズ・リスナーが、適切なライフサイクル・フェーズでMDSセッションに対するコミットをトリガーすることで、変更ドキュメントがMDSストアに永続されます。ページがリクエストされるたびに、格納された変更をベース・ドキュメントにマージした後、フラット化されたドキュメントを提供するMDS JSPプロバイダから、OracleのJSPエンジンでJSPドキュメントが検索されます。MDSでは、コンポーネントのID属性の一意の値に対して変更が記録されます。
ヒント:
ページの部分送信に応えて変更が適用される場合(partialSubmit
属性をtrue
に設定したbutton
など)、変更が適用されるコンポーネントをpartialTarget
属性の値として設定する必要があります。
さらに、登録WebLogic ServerでJDeveloperからアプリケーションを実行する場合は、MDSによりメタデータ・カスタマイズを永続させるためのローカル・ファイルベースのリポジトリが作成されます。逆に、アプリケーションがテスト環境または本番環境にデプロイされる場合、カスタマイズは構成済のMDSリポジトリに永続されます。MDSリポジトリ構成の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。アプリケーションのデプロイの詳細は、「アプリケーションのデプロイ」を参照してください。
変更内容がテンプレートまたはリージョンのコンポーネントに永続される際の処理方法は、変更がセッションに永続されるか、MDSリポジトリに永続されるかによって異なります。セッション永続性では、指定されたセッションのviewId
に対して変更内容が記録およびリストアされます。その結果、リージョンまたはページ・テンプレートに属するコンポーネントで変更が適用される場合、その変更は、リージョンまたはテンプレートを使用するページの範囲でのみ適用可能です。リージョンまたはテンプレートを使用するページすべてには適用されません。たとえば、pageOne.jspx
とpageTwo.jspx
があり、両方にregion.jsff
で定義されているリージョンが含まれ、これにはshowDetail
コンポーネントが含まれるとします。pageOne.jspx
がレンダリングされ、showDetail
コンポーネントのdisclosed
属性が変更されると、暗黙的に属性の変更が記録され、pageOne.jspx
にのみ適用されます。ユーザーがpageTwo.jspx
に移動すると、属性の変更は適用されません。
変更内容をMDSリポジトリに対して永続化する場合、JSPページ・パスとカスタマイズ・クラスで設定されたカスタマイズ名/値構成設定の組合せによって識別されたドキュメントのカスタマイズが、MDSにより記録されリストアされます(詳細は、「カスタマイズ・クラス」を参照)。この結果、レンダリングされた特定ページについて、MDSによりリージョンまたはテンプレート内のコンポーネントに変更が適用される際、ソース・ページと同じカスタマイズ名および値を持つ、リージョンまたはテンプレートを使用するページすべてに変更を適用できます。
前述の例で、showDetail
コンポーネントがmyShowDetail
のIDを使用するとします。pageOne.jspx
がレンダリングされ、showDetail
コンポーネントのdisclosed
属性が変更されると、属性の変更はregion.jsff
に記録されます(これを使用するページではなく)。この変更は、IDが同じであるかぎり、リージョンを含むページがレンダリングされるときに適用されます。
特定のADF Facesコンポーネントに存在する組込みユーザー・カスタマイズ機能のほかに、変更永続性フレームワークでは独自のカスタム・ユーザー・カスタマイズ機能を作成できます。
特定のADF Facesコンポーネントに組み込まれているユーザー・カスタマイズ機能のほかに、独自のカスタム・ユーザー・カスタマイズ機能を作成できます。変更永続性フレームワークは、次のタイプのユーザー・カスタマイズをサポートします。
属性値の変更
ファセットの追加または削除
子コンポーネントの追加または削除
子コンポーネントの並替え
子コンポーネントの別の親への移動
カスタム・ユーザー・カスタマイズを作成するには、ユーザー・カスタマイズのタイプごとにカスタマイズ・クラスを作成し、作成したクラスを使用するようにアプリケーションを構成する必要があります。アプリケーションのカスタマイズ・レイヤーも設定する必要があります。これらの手順の詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。
これらの前提条件を満たしたら、セッションまたはMDSリポジトリへの変更の永続化を処理するADF Facesクラスでメソッドを呼び出すロジックを追加します。変更を処理するには、いずれかのADF Faces専用コンポーネント変更クラスのAPIを使用するコードを作成します。多くの場合、このコードを、永続させるコンポーネントが配置されているページに関連付けられているマネージドBean上のイベント・ハンドラ・メソッドに追加します。コンポーネントのすべてのインスタンスで同じ変更内容を永続させる場合、コンポーネントが表示されるページごとにこのコードを追加する必要があります。
カスタム・コンポーネントを作成する場合は、コードをカスタム・コンポーネント・クラスに直接追加することで、コンポーネントにユーザー・カスタマイズを実装できます。この場合、コードをそのコンポーネント・クラスにのみ追加する必要があります(コンポーネントのインスタンスごとに1回ではなく)。「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。
カスタム・ユーザー・カスタマイズを作成するために必要な作業について理解するには、変更永続性とMDSフレームワークについて十分に理解していることが必要です。変更内容をMDSリポジトリに永続させる場合、変更永続性フレームワークがMDSフレームワークと連携して機能します。カスタマイズを保存する場所および方法は、MDSリポジトリ、カスタマイズ・レイヤー、カスタマイズ・クラスの設定によって異なります。MDSフレームワークとリポジトリ、およびその使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。
変更永続性フレームワークでは、Apache MyFaces Trinidadからの基になる変更マネージャ・クラス(org.apache.myfaces.trinidad.change
パッケージ)といくつかのADF Faces固有のクラス(oracle.adf.view.rich.change
パッケージ)を使用します。登録済のChangeManager
クラスのインスタンスには、RequestContext
オブジェクトからアクセスできます。リクエストで変更が作成および追加されときに、これらを収集して永続させます。SessionChangeManager
クラスはセッション内でのみ永続性を処理するChangeManager
の実装で、MDSDocumentChangeManager
クラスはMDSリポジトリのみに永続させる実装です。FilteredPersistenceChangeManager
クラスは、登録済の永続性変更マネージャを使用してフィルタ・ルールをリポジトリに渡す変更を格納するChangeManager
の実装です。FilteredPersistenceChangeManager
が使用されている場合、リポジトリに永続されない変更はセッションに永続されます。
コンポーネントの変更を記述するために、追加のクラスが使用されます。これらのAPIを使用して、ADF Facesフレームワークで提供される暗黙的な値変更以外のコンポーネントへの変更の永続化を処理します(表52-1を参照)。ComponentChange
は、ファセットや子コンポーネントの追加または削除など、JSFコンポーネント階層で行われる固有の変更を実装するための、すべてのクラスのベース・クラスです。これらの変更は、後続のビューの作成時に、変更が追加された順序で自動的に適用されます。ComponentChange
クラスを拡張し、DocumentChange
インタフェースを実装するクラスは、変更内容を直接MDSリポジトリに永続できます。DocumentChange
インタフェースを実装しないクラスは、変更内容をセッションにのみ永続できます。
表52-2に、特定のカスタマイズを処理する専用クラスを示します。「リポジトリ」列に「可」と表示されている場合、そのクラスはDocumentChange
インタフェースを実装し、変更内容をMDSリポジトリに永続できます。
表52-2 変更永続性の処理に使用するクラス
クラス名 | リポジトリ | 説明 |
---|---|---|
|
はい はい |
ドキュメント・マークアップを使用して、子コンポーネントまたは複雑な子( |
|
はい |
複雑な子( |
|
いいえ はい |
属性の値を変更します。 |
|
はい はい |
ファセット属性の値を変更します。 |
|
はい |
子をあるコンテナから別のコンテナへ移動します。 |
|
はい |
子コンポーネントを削除します。 |
|
はい はい |
複雑な子( |
|
いいえ |
ドキュメント・マークアップを使用して子コンポーネントをファセットに追加します。この変更の適用時に、マークアップがドキュメントに追加されます。 |
|
はい |
子コンポーネントをファセットに追加します。この変更の適用時に、子コンポーネントに対応するDOM要素がドキュメントに追加されます。ファセットが存在しない場合は作成されます。ファセットが存在する場合は、そのコンテンツがすべて削除され、新たにコンテンツが追加されます。 |
|
はい |
ファセットを削除します。 |
|
はい |
コンポーネントの子を並べ替えます。 |
ChangeManagerクラスとは別に、DocumentChangeFactory
インタフェースを実装してChangeManager
クラスに登録する必要がある場合があります。DocumentChangeFactory
の実装でComponentChange
に相当するDocumentChange
を提供できる場合、ChangeManager
はこれを使用してDocumentChange
をリポジトリに永続させます。
作成する明示的な変更を処理するコードを追加し、JSFページ上のコンポーネントを構成してカスタマイズを処理する必要があります。また、デフォルトのユーザー・カスタマイズと同様に、カスタムの変更をadf-config.xml
ファイルに登録する必要があります。
注意:
変更内容を複数の形式で表すことができる場合、最も優先順位の高い形式で記録する必要があります。次に例を示します。
コンポーネントの属性の変更: 属性はコンポーネント・タグで指定するか、<f:attribute>
タグを使用して表すことができます。JSF JSPドキュメントでは、コンポーネント・タグで指定された属性が<f:attribute>
よりも優先されます。このため、コンポーネント・タグでの属性の変更がカスタマイズに記録されます。
列コンポーネントの列ヘッダー・テキスト: 列のヘッダー・テキストは、headerText
属性を使用して、またはヘッダー・ファセットを使用して指定できます。この場合は、ファセット・コンポーネントが優先されます。
始める前に:
カスタムの実行時ユーザー・カスタマイズの機能に関する知識が役立つ場合があります。詳細は、「カスタム・ユーザー・カスタマイズの実装」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開き、ユーザー・カスタマイズの動作を変更するページを開きます。
カスタム・ユーザー・カスタマイズを作成するには:
変更は、セッションのコンポーネント変更として永続化されます。属性変更は、ADF Facesランタイム・コードによって処理されます。暗黙的な変更永続性は、コンポーネント固有の属性リストに適用されます。
カスタム・コンポーネントを作成する際、アプリケーションで変更永続性が使用可能な場合に、そのコンポーネントの特定の属性値を永続させるように指定できます。カスタム・コンポーネントでの暗黙的な変更の設定は、既存のコンポーネントでの明示的な変更永続性の設定と似ています。実際の永続化を実行するコードを追加しますが、そのコードをマネージドbeanに置くかわりに、コンポーネント・クラスで直接そのコードを処理することができます。イベントを使用してコンポーネントの属性値とサーバーが同期されている場合、ブロードキャスト・メソッドを使用して変更を永続させることができます。永続させる属性値がイベントを使用しない場合、レンダラとコンポーネント・クラスにコードを追加する必要があります。
属性値がイベントを使用する場合、コンポーネント・クラスにコードを追加する必要があります。
始める前に:
カスタム・コンポーネントでの永続性の実装方法に関する知識が役立つ場合があります。詳細は、「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開く必要があります。
イベントを使用する属性値に暗黙的な変更永続性を設定するには:
属性がイベントを使用しない場合、コードをコンポーネントのレンダラ・クラスに配置する必要があります。
始める前に:
カスタム・コンポーネントでの永続性の実装方法に関する知識が役立つ場合があります。詳細は、「カスタム・コンポーネントでの暗黙的な変更永続性の作成」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「実行時ユーザー・カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開く必要があります。
他の属性値に暗黙的な変更永続性を設定するには: