ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発
12c (12.1.2)
E48099-02
  目次へ移動
目次
前
前 		 次
次		  

27 Fusionページ・ライフサイクルの理解

この章では、ADFページ・ライフサイクルとそのフェーズ、Fusion Webアプリケーション内でのライフサイクルの最適な使用方法について説明します。

この章には次の項が含まれます:

27.1 Fusionページ・ライフサイクルについて

JSFページが送信され、新しいページがリクエストされると、JSFページ・リクエスト・ライフサイクルが起動されます。このライフサイクルでは、ページの値の送信、現在のページのコンポーネントの検証、コンポーネントのナビゲーションと結果ページへの表示および状態の保存とリストアが処理されます。JSFライフサイクル・フェーズでは、UIコンポーネント・ツリーを使用してコンポーネントの表示を管理します。このツリーはJSFページのランタイム表現で、ページ内の各UIコンポーネント・タグがツリーのUIコンポーネント・インスタンスに対応します。

FacesServletオブジェクトで、JSFアプリケーションのページ・リクエスト・ライフサイクルが管理されます。FacesServletオブジェクトで、リクエスト処理に必要な情報を含み、ライフサイクルを実行するオブジェクトを起動するFacesContextと呼ばれるオブジェクトが作成されます。

JSFライフサイクルのほかに、ADF FacesおよびADFページ・ライフサイクルも実行されます。ADF FacesライフサイクルではJSFライフサイクルが拡張され、クライアント側の値のライフサイクル、1つのページに複数のフォームを使用する弊害(ユーザーの編集内容の消失など)なしに独立して送信可能なセクションをページに作成できるサブフォーム・コンポーネント、追加スコープなどの追加機能を提供します。アプリケーションのライフサイクルで実行できる機能を含む、JSFライフサイクルとADF Facesライフサイクル両方の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ADF FacesでのJSFライフサイクルの使用」の章を参照してください。

ADFページ・ライフサイクルは、データ・モデルの準備と更新、モデル・レイヤーでのデータの検証、ビジネス・レイヤーでのメソッドの実行を処理します。ADFページ・ライフサイクルでは、バインディング・コンテナを使用して、現在のページ・リクエスト時にページによる簡単なデータ参照を可能にします。

組み合せたJSFページ・ライフサイクルとADFページ・ライフサイクルは、アプリケーション・サーバーにHTTPリクエストが届いたときに始まってページがクライアントに戻されるまで続く、より大規模なイベント・シーケンスに含まれる1つのシーケンスにすぎません。このイベント・シーケンス全体をWebページ・ライフサイクルと呼びます。このライフサイクルは、MVCアーキテクチャで定義されているようにモデル、ビュー、コントローラのレイヤーを通して処理をたどっていきます。ページ・ライフサイクルは厳格に定義されたイベント・セットではなく、一般的なユースケースで使用されるイベント・セットです。図27-1に、JSFとOracle ADFを併用した場合のWebページ・リクエストのライフサイクルのシーケンス図を示します。

図27-1 JSFおよびOracle ADFを使用したWebページ・リクエストのライフサイクル

ADFアプリケーションでの制御フロー

JSFおよびOracle ADFを使用したWebページ・リクエストの処理の基本的なフローは、次のようになります。

  1. http://yourserver/yourapp/faces/some.jspに対するWebリクエストが、クライアントからアプリケーション・サーバーに到着します。

  2. ADFBindingFilterオブジェクトが、HTTPセッション内でADFバインディング・コンテキストを検索し、それがまだ存在しない場合はその初期化を初めて実行します。ADFBindingFilterの機能には、バインディング・コンテキスト・メタデータ・ファイルの名前の検索、各データ・コントロールの検索と構築などがあります。

  3. ADFBindingFilterオブジェクトが、該当するリクエストに関与する各データ・コントロールに対してbeginRequest()メソッドを起動します。このメソッドにより、データ・コントロールは各リクエストの開始時に通知を受けるため、必要な設定を実行できるようになります。

  4. JSF Lifecycleオブジェクト(各リクエストの標準的な処理フェーズの調整を行う)が、ライフサイクルの各フェーズでADFPhaseListenerクラスに通知し、JSFライフサイクルとADFモデル・データ・バインディング・レイヤーを調整するためのカスタムな処理が実行できるようにします。JSFページ・ライフサイクルとADFページ・ライフサイクルのフェーズの詳細は、27.2項「JSFページ・ライフサイクルとADFページ・ライフサイクルについて」を参照してください。


    注意:

    FacesServletクラス(javax.faces.webapp内)は、JSFアプリケーションのweb.xmlファイル内で構成され、各リクエストを処理するためのJSF Lifecycleクラス(javax.faces.lifecycle内)を最初に作成します。ただし、FacesServletクラスは、該当する処理をすべて実行するLifecycleクラスであるため、図に示していません。

  5. ADFPhaseListenerオブジェクトが、各リクエストを処理するためのADF PageLifecycleオブジェクトを作成し、該当するフェーズ前後のメソッドをADF PageLifecycleクラス内の対応メソッドに委譲します。ページのバインディング・コンテナは、ユーザーのセッション中、以前に使用されていない場合は作成されます。

  6. アプリケーション・モジュール・データ・コントロールが、リクエスト時に初めて参照されると、アプリケーション・モジュール・プールからアプリケーション・モジュールのインスタンスを取得します。

  7. JSF Lifecycleオブジェクトが、レンダリング対象のページにコントロールを移動します。

  8. 該当するページ上の一連のUIコンポーネントが、該当ページのバインディング・コンテナ内の値バインディングおよびイテレータ・バインディングにアクセスし、フォーマット設定された出力をレンダリングしてブラウザに表示します。

  9. ADFBindingFilterオブジェクトが、該当するリクエストに関与する各データ・コントロールに対してendRequest()メソッドを起動します。このメソッドにより、データ・コントロールは各リクエストの終了時に通知を受けるため、必要なリソースのクリーンアップを実行できるようになります。

  10. アプリケーション・モジュール・データ・コントロールがendRequestの通知を使用して、アプリケーション・モジュール・プールにアプリケーション・モジュールのインスタンスを解放して戻します。

  11. 得られたページが、ユーザーのブラウザに表示されます。

ADFページ・ライフサイクルには、対応するJSFフェーズの実行前後にADFページ・ライフサイクル・リスナーに通知するためのみに定義されたフェーズも含まれています(これらのフェーズは実装されていません)。これらのフェーズにより、カスタム・リスナーを作成してJSFページ・ライフサイクルとADFページ・ライフサイクルの両方のフェーズに登録できるため、必要に応じてグローバルに、またはページ・レベルでADFページ・ライフサイクルをカスタマイズできるようになります。

27.2 JSFページ・ライフサイクルとADFページ・ライフサイクルについて

図27-2は、JSFページ・ライフサイクルとADFページ・ライフサイクルを組み合せた概要を示します。

図27-2 JSFページ・ライフサイクルとADFページ・ライフサイクル

JSFページ・ライフサイクルとADFページ・ライフサイクル

たとえば、テキストが表示された入力テキスト・コンポーネントおよびボタンからなるページがあるとします。このページが初めてレンダリングされるとき、ビューのリストア・フェーズ中にコンポーネント・ツリーが構築され、コンポーネントのレンダリング中、ライフサイクルはレスポンスのレンダリング・フェーズまで進みますユーザーがボタンをクリックすると、完全なライフサイクルが起動されます。リクエスト値の適用フェーズおよび検証処理フェーズ中、コンポーネント・ツリーが再構築され、入力テキスト・コンポーネントではすべての新規値が抽出されます。エラーが発生した場合は(検証によるエラーなど)、ライフサイクルはレスポンスのレンダリング・フェーズにまで進みます。それ以外の場合は、モデルの更新フェーズ中にモデルが新規値によって更新され、アプリケーションの起動フェーズ中、ボタンに関連付けられたすべてのアプリケーション処理(ナビゲーションなど)が実行されます。

図27-3は、JSF、ADF Faces、ADFモデル・フェーズがページ・リクエストのライフサイクルの中で統合されるしくみの詳細を示しています。

図27-3 Fusion Webアプリケーションでのページ・リクエストのライフサイクル

ADFおよびJSFのフェーズの連携

ADFモデルを使用するJSFアプリケーションでは、ページ・ライフサイクルのフェーズは次のようになります。

27.2.1 部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項

ADF Facesには、ページ上の特定のコンポーネント(通常は値が変更されたコンポーネント)にのみページ・リクエスト・ライフサイクル(変換と検証を含む)を実行する場合に使用できる、最適化されたライフサイクルが用意されています。

最適化されたライフサイクルを使用する方法の1つは、一方のコンポーネントのイベントが、もう一方のコンポーネント(ターゲット)のトリガーとして機能するように、依存性を手動で設定する方法です。トリガー・コンポーネントでイベントが発生すると、ターゲット・コンポーネントと、トリガーおよびターゲットの両方の子コンポーネントでライフサイクルが実行され、これらのコンポーネントのみがレンダリングされます。これは、部分ページ・レンダリング(PPR)とみなされます。

例27-1は、トリガーの役割を果たすラジオ・ボタンと、ターゲットとなる出力テキストを保持するpanelGroupLayoutコンポーネントを示します(outputTextコンポーネントは常時レンダリングされるわけではないため、panelGroupLayoutコンポーネントをターゲットとする必要があります)。

例27-1 部分ページ・レンダリングの例

<af:form>
  <af:inputText label="Required Field" required="true"/>
  <af:selectBooleanRadio id="show" autoSubmit="true" text="Show"                                      
                        value="#{validate.show}"/>
  <af:selectBooleanRadio id="hide" autoSubmit="true" text="Hide" 
                         value="#{validate.hide}"/>
  <af:panelGroupLayout partialTriggers="show hide" id="panel">
    <af:outputText value="You can see me!" rendered="#{validate.show}"/>
  </af:panelGroupLayout>
</af:form>

ラジオ・ボタンのautoSubmit属性がtrueに設定されているため、選択されると、SelectionEventが起動されます。panelGroupLayoutコンポーネントが両方のラジオ・コンポーネントのターゲットとして設定されているため、このイベントが起動されると、selectOneRadio(トリガー)、panelGroupLayoutコンポーネント(トリガーのターゲット)とその子コンポーネント(outputTextコンポーネント)のみ、ライフサイクルの処理が行われます。outputTextコンポーネントは表示ラジオ・ボタンの選択時にのみレンダリングされるよう構成されているため、ユーザーは、ラジオ・ボタンの上の必須入力フィールドにテキストを入力しなくても、ラジオ・ボタンを選択して出力テキストを表示できます。

部分トリガーとターゲットをコード内で手動で設定するかわりに、ADF Facesフレームワークには自動PPRが用意されています。自動PPRは、イベントに対応するイベント・ルート・コンポーネントが存在する場合、またはコンポーネント自体がイベント・ルートである場合に実行されます。イベント・ルート・コンポーネントにより、PPRの境界が決定されます。たとえば、attributeChangeEventはイベントを起動させるinputTextコンポーネントを、そのイベント・ルートであるとみなします。したがって、前述の例では、inputTextコンポーネントの値が変更されると、これがPPRの最初の境界であるため、inputTextコンポーネントとそのすべての子コンポーネント上のみでライフサイクルが実行されます。

イベント・ルートのほか、Fusion Webアプリケーションではデフォルトで、同一のイテレータ・バインディングに関連付けられたすべてのUIコンポーネントに対しても自動PPRが実行されます。関連付けられたすべてのコンポーネントは、そのいずれかで値変更イベントが発生するたびに、すべてリフレッシュされます。この機能は、イテレータのchangeEventPolicy属性をpprに設定することで制御します。デフォルトでは、これはグローバルに設定されています。

たとえば、「データ・コントロール」パネルを使用して多数のinputTextコンポーネントを作成するとします(フォームを作成する場合など)。これらのinputTextコンポーネントのいずれかでattributeChangeEventが発生すると、他のinputTextコンポーネントも同一のイテレータに関連付けられているため、これらすべてのinputTextコンポーネントがリフレッシュされます。

もう1つの例として、panelSplitterコンポーネントを含むページがあるとします。スプリッタの左側は新規顧客を作成するためのフォーム(Customerコレクションを使用してフォームをドロップして作成)であり、スプリッタの右側にはフォームの用法の説明文が表示されています。フォームを構成する各inputTextコンポーネントのバインディングは、すべてCustomerイテレータに関連付けられているため、フォームが送信され、いずれかのinputTextコンポーネントの値が変更されるたびに、Customerに関連付けられているinputTextコンポーネントのみがライフサイクル処理されます。スプリッタ右側の説明文を含め、ページの残りの部分はリフレッシュされません。


注意:

自動PPRを実行するには、イベントおよびイベント・ルート・コンポーネントが『Oracle ADF FacesによるWebユーザー・インタフェースの開発』のイベントおよび部分ページ・レンダリングに関する項の表5-1にリストされている必要があります。リストされていない場合は、同ガイドの、部分トリガーの使用に関する項を参照して、PPRを手動で設定する必要があります。

たとえば、同一のデータ・コントロール・コレクションに基づきフォームと表を作成するとします。フォームにはデータ行の詳細が表示され、表にはコレクション内のすべての行が表示されます。フォーム内で現在表示されている行は、表内でも選択された状態で表示されます。フォームの「次へ」ボタンがクリックされたときに、新たな行が選択された状態に表を更新させる必要があります。選択イベントは自動PPRによってサポートされないため、表とフォームは同一のイテレータを使用しているにもかかわらず、表はリフレッシュされません。ターゲットの表に対するPPRのトリガーとして、「次へ」および「前へ」ボタンを設定する必要があります。


注意:

構成済イテレータに関連付けられたページ定義ファイル内でコントロール・バインディングが定義されているUIコンポーネントのみが、リフレッシュされます。

マネージドBeanからイテレータに直接アクセスし、このBeanを介してイテレータの値をUIコンポーネントに公開する場合は、これらのUIコンポーネントに対して自動PPRは実行されません。この場合は、PPRを手動で構成する必要があります。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の部分トリガーの使用に関する項を参照してください。


注意:

ADF Facesの問合せコンポーネント(queryおよびquickQuery)は、自動PPRをサポートしません。changeEventPolicyをグローバルにpprとなるように設定した場合、これらのコンポーネントのバインディング、またはPPRに参加しないコンポーネントまたはタグ(動作タグなど)に関連付けられているイテレータは、changeEventPolicy属性を実行時にnoneに設定します。

デフォルトでは、すべての新規アプリケーションではグローバルPPRが使用されます。設定する必要はありません。ただし、ページに対するページ定義ファイル内で、この設定をオーバーライドできます。

始める前に:

部分ページ・レンダリングに関する知識が役立つ場合があります。詳細は、27.2.1項「部分ページ・レンダリングおよびイテレータ・バインディングに関する必知事項」を参照してください。

PPRを使用するようにイテレータ・バインディングを設定するには:

  1. 特定のイテレータ・バインディングに対し、PPRを使用するように、または使用しないように設定するには、関連付けられたページ定義ファイルを開き、イテレータを選択して、「プロパティ」ウィンドウ内でChangeEventPolicyを設定します。

  2. すべてのイテレータ・バインディングがPPRを使用するように設定するには:

    1. 「アプリケーション・リソース」パネルで、「ディスクリプタ」および「ADF META-INF」ノードを開き、「adf-config.xml」をダブルクリックします。

    2. 概要エディタで「モデル」ナビゲーション・タブをクリックし、「デフォルトの変更イベント・ポリシーはPPRです」を選択します。

ADF FacesフレームワークでのPPRの使用方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「部分ページ・コンテンツの再レンダリング」の章を参照してください。

27.2.2 タスク・フローとライフサイクルに関する必知事項

タスク・フローは、(ページに関連付けられている)親バインディング・コンテナのリフレッシュ時に初めてリフレッシュされます。これはモデルの準備フェーズで発生します。後続のリクエストでは、レンダリングの準備フェーズにおいて、refreshおよびrefreshCondition属性とそのパラメータ値に基づいてタスク・フローがリフレッシュされます。


注意:

子ページ・フラグメントのページ定義は、引き続き子ページ・フラグメントのバインディングのリフレッシュを処理します。


ヒント:

最初は公開されないリージョン(ポップアップ・ダイアログなど)がページ上にある場合、リージョンが表示されなくても、親ページのレンダリング時にパラメータは使用可能である必要があります。リージョンにパラメータが必要であるにもかかわらず、これらのパラメータ値を親ページのレンダリング時に使用できない場合は、動的リージョンを使用する必要があります。パラメータがNULLの場合、リージョンのパラメータの準備が完了してリージョンを表示できるようになるまで、空のタスク・フローを使用できます。空のタスク・フローに切り替えるには、動的リージョンのtaskFlowId属性を空の文字列に設定します。

EL式をrefreshCondition属性の値として設定した場合、ライフサイクルのレンダリングの準備フェーズ中に評価されます。式がtrueに評価されると、タスク・フローは再度リフレッシュされます。refreshConditionがfalseに評価されると、refreshConditionが指定されていない場合と動作は同じです。


注意:

EL式でbindings変数が使用されていると、リージョン内に表示されるページ・フラグメントではなく、親ページのバインディング・コンテナが参照されます。

タスク・フロー実行可能ファイルのrefreshプロパティの有効な値は次のとおりです。

  • default: 親ページが最初に表示されるときに、リージョンは1回のみリフレッシュされます。

  • ifNeeded: taskFlowバインディングのパラメータ値に変更があった場合のみ、リージョンがリフレッシュされます。taskFlowバインディングにパラメータがない場合、ifNeededはデフォルトと同じです。ifNeededを使用した場合、refreshCondition属性は考慮されません。


    注意:

    refresh属性をifNeededに設定した場合は、refreshCondition属性のいずれの値よりも優先されます。また、動的パラメータMapを使用してtaskFlowバインディングにパラメータを渡す場合、ifNeededはサポートされません。その場合は、refreshCondition="#{EL.Expression}"を使用します。

taskFlowバインディングによる唯一の処理はそのパラメータのリフレッシュであり、Refreshをalwaysに設定する意味はありません。taskFlowバインディングのパラメータが変更されないかぎり、ADFリージョンをリフレッシュする理由はありません。

子ページ・フラグメントのページ定義は、引き続き子ページ・フラグメントのバインディングのリフレッシュを処理します。

27.3 オブジェクト・スコープ・ライフサイクルについて

実行時には、バインディング・コンテナおよびマネージドBeanなどのADFオブジェクトはインスタンス化されています。これらのオブジェクトにはそれぞれ、そのスコープ属性により設定された存続期間が定義されています。RequestContext APIからjava.util.Mapとしてスコープにアクセスできます。たとえば、リクエスト・スコープのfooというオブジェクトにアクセスするには、式#{requestScope.foo}を使用します。

オブジェクト・スコープは、プログラミング言語におけるグローバル変数スコープおよびローカル変数スコープに類似しています。スコープが広いほど、オブジェクトの可用性が高くなります。オブジェクトの存続期間中、これらのオブジェクトによってあるインタフェースが公開され、情報が保持され、あるいは変数およびパラメータが他のオブジェクトに渡されます。たとえば、セッション・スコープで定義されたマネージドBeanは、ページ・リクエストが複数存在する場合に使用できます。ただし、リクエスト・スコープで定義されたマネージドBeanは、1つのページ・リクエストが継続する間のみ使用できます。

Fusion Webアプリケーションには次の6種類のスコープがあります。

デフォルトでは、バインディング・コンテナおよびそれに含まれるバインディング・オブジェクトは、セッション・スコープで定義されます。ただし、値バインディングおよびイテレータ・バインディングによって参照される値はリクエスト間で定義されず、スケーラビリティ上の理由により、セッション・スコープに残りません。このため、バインディング・オブジェクトが参照する値は、そのバインディング・コンテナがADFライフサイクルによって準備されているリクエストの間のみ有効です。セッション・スコープには、バインディング・コンテナおよびバインディング・オブジェクト自体のみ残されます。

図27-4に、各タイプのスコープが有効な期間を示します。

図27-4 スコープとページ・フローの関係

ADFライフサイクルでのスコープ

マネージドBeanをどのスコープに登録するかを決定するときは常に、できるかぎり狭いスコープを使用するようにします。セッション・スコープは、セッション全体に関連する情報(ユーザー情報やコンテキスト情報など)にのみ使用します。タスク・フロー間で値を渡すためにセッション・スコープを使用しないでください。ページ・フラグメントまたは宣言コンポーネントのマネージドBeanを作成するときは、バッキングBeanスコープを使用する必要があります。

マネージドBeanは、adfc-config.xmlまたは特定のタスク・フローの構成ファイルに登録できます。FusionアプリケーションでのマネージドBeanの使用に関する詳細は、26.4項「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。


注意:

Fusion Webアプリケーションでは、faces-config.xmlでマネージドBeanを登録しないでください。

27.3.1 オブジェクト・スコープとタスク・フローに関する必知事項

タスク・フロー内の変数にどのスコープを使用するかを決定するときは、アプリケーション・スコープまたはセッション・スコープ以外のスコープ・オプションを使用する必要があります。これら2つのスコープは、タスク・フローの存続期間を超えてオブジェクトをメモリーに保存するため、タスク・フローのカプセル化および再利用で障害が発生します。さらに、アプリケーション・スコープおよびセッション・スコープでは、オブジェクトがメモリーに必要以上に長い時間保持されるため、不要なオーバーヘッドが発生します。

タスク・フロー内のアクティビティ間でデータ値を渡す必要がある場合は、ページ・フロー・スコープを使用する必要があります。現在のビュー・アクティビティ内でのみ必要とされ、ビュー・アクティビティ間にまたがっていない変数の場合、ビュー・スコープを使用する必要があります。現在のリクエストより長い期間スコープが存続する必要がない場合には、リクエスト・スコープを使用する必要があります。これは、UIコンポーネント情報の格納に使用する唯一のスコープです。最後に、タスク・フローが同じページの2つのリージョン・コンポーネントまたは宣言コンポーネントに表示される可能性があり、リージョン・インスタンスを分離する場合、タスク・フロー内のマネージドBeanには、バッキングBeanスコープを使用する必要があります。

27.4 ADFページ・ライフサイクルのカスタマイズ

ADFライフサイクルには明確に定義されたフェーズが含まれており、このフェーズによって対応するJSFフェーズの実行前後にADFライフサイクル・リスナーに通知が行われます。このライフサイクルは、必要なコードを起動するカスタム・フェーズ・リスナーを作成した後、これらのフェーズのいずれかで実行されるようにライフサイクルに登録することによってカスタマイズできます。

たとえば、アプリケーション・モジュールでデフォルトの管理状態解放レベルを使用しない場合は、カスタムADFページ・フェーズ・リスナー・クラスを使用してADFライフサイクルのafter-prepareRenderフェーズから解放レベルを設定できます(詳細は49.4.5項「ADF PagePhaseListenerでの解放レベルの設定方法」を参照)。


注意:

1つのアプリケーションでは、複数のフェーズ・リスナー・インスタンスを保持できません。デフォルトでは、最初のADFPhaseListenerインスタンスがMETA-INF/faces-config.xml構成ファイルに登録されます。たとえば、ADFPhaseListenerのカスタマイズされたサブクラスを登録すると、2つ目のインスタンスが作成されます。この場合、直近に登録されたインスタンスのみが使用されます。

警告メッセージ「ADFc: ADFページ・ライフサイクル実装を''新しいリスナーのクラス名''と置換しています。」により、インスタンスがより新しいものに置き換えられたことが通知されます。

27.4.1 カスタム・フェーズ・リスナーの作成方法

カスタム・フェーズ・リスナーを作成するには、PagePhaseListenerインタフェースを実装するリスナー・クラスを作成する必要があります。次に、コードの実行が必要なフェーズの前または後にコードを実行するメソッドを追加します。

例27-2に、カスタム・フェーズ・リスナーを作成するために変更できるテンプレートを示します。JDeveloperでクラスを作成する方法の詳細は、4.13.1項「カスタム・クラスの生成方法」を参照してください。

例27-2 カスタム・フェーズ・リスナーの例

public class MyPagePhaseListener implements PagePhaseListener
{
   public void afterPhase(PagePhaseEvent event)
   {
      System.out.println("In afterPhase " + event.getPhaseId());
   }
 
 
   public void beforePhase(PagePhaseEvent event)
   {
      System.out.println("In beforePhase " + event.getPhaseId());
   }
}

カスタム・リスナー・クラスを作成したら、クラスを起動する必要があるフェーズに登録する必要があります。アプリケーション全体で使用できるようにグローバルに登録するか、1つのページに対してのみ登録することができます。

27.4.2 リスナーをグローバルに登録する方法

ADFライフサイクルをグローバルにカスタマイズするには、adf-settings.xml構成ファイルを編集してカスタム・フェーズ・リスナーを登録します。adf-settings.xmlファイルは、ADFコントローラなど複数のADFコンポーネントにより共有され、構成情報を格納します。

adf-settings.xmlにリスナーを登録するには:

  1. 「アプリケーション」ウィンドウで、「META-INF」ノードの下にある「adf-settings.xml」ファイルをダブルクリックします。

  2. エディタ・ウィンドウで「ソース」タブをクリックします。

  3. ソース・エディタで、
    <adfc-controller-config xmlns=
    "http://xmlns.oracle.com/adf/controller/config">    まで下にスクロールします。

    このエントリが存在しない場合は、これをファイルに追加します。

  4. イタリックで示されている残りの要素を入力します。

     <?xml version="1.0" encoding="US-ASCII" ?> <adf-config xmlns="http://xmlns.oracle.com/adf/config">
  .
  .
  .
    <adfc-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
       <lifecycle>
         <phase-listener>
            <listener-id>MyPagePhaseListener</listener-id>
            <class>mypackage.MyPagePhaseListener</class>        
         </phase-listener>
      </lifecycle>
   </adfc-controller-config> 
  .
  .
  .
</adf-config>

  5. 次の要素の値を入力します。

    • <listener-id>: リスナーの一意の識別子(完全修飾クラス名を使用可能)

    • <class>: リスナーのクラス名

27.4.3 リスナーの順序に関する必知事項

adf-settings.xmlでは複数のフェーズ・リスナーを指定できるほか、これらの相対的なコール順序も任意で指定できます。このファイルに新しいリスナーを登録する際には、次の2つのパラメータを使用して、リスナー・リストでの配置を指定します。

  • beforeIdSet: そのリスナーが、beforeIdSetで指定されているリスナーよりも先にコールされます。

  • afterIdSet: そのリスナーが、afterIdSetで指定されているリスナーよりも後にコールされます。

例27-3に、アプリケーション用に複数のリスナーが登録された構成ファイルの例を示します。

例27-3 複数のリスナー登録のあるadf-settings.xml構成ファイル

<lifecycle>
   <phase-listener>
      <listener-id>MyPhaseListener</listener-id>
      <class>view.myPhaseListener</class>
      <after-id-set>
         <listener-id>ListenerA</listener-id>
         <listener-id>ListenerC</listener-id>
      </after-id-set>
      <before-id-set>
         <listener-id>ListenerB</listener-id>
         <listener-id>ListenerM</listener-id>
         <listener-id>ListenerY</listener-id>
      </before-id-set>
   </phase-listener>
</lifecycle>

例では、MyPhaseListenerは登録されたリスナーであり、リスナーAおよびCの後かつ、リスナーB、MおよびYより先に実行されます。リスナーBの後にMyPhaseListenerを実行するには、リスナーBの<listener-id>要素を<after-id-set>要素の下に移動します。

27.4.4 単一ページのライフサイクル・リスナーの登録方法

単一ページのライフサイクルをカスタマイズするには、ページ定義ファイルでControllerClass属性を設定します。このリスナーが有効なのは、ページ定義によって記述された特定ページのライフサイクルに対してのみです。ページ定義ファイルとFusion Webアプリケーションにおけるその役割の詳細は、17.7項「ページ定義ファイルでの作業」を参照してください。

標準JSFページまたはページ・フラグメントのどちらに対するものかに応じて、異なるコントローラ・クラスを指定します。

単一ページまたはページ・フラグメント用にADFライフサイクルをカスタマイズするには:

  1. 「アプリケーション」ウィンドウで、ページまたはページ・フラグメントを右クリックし、「ページ定義に移動」を選択します。

  2. 「構造」ウィンドウで、ページ定義ノードを選択します。

  3. 「プロパティ」ウィンドウで、「ControllerClass」フィールドにカーソルを置いたときに表示されるアイコンをクリックして、「編集」を選択します。

  4. 「階層」タブをクリックし、ページまたはページ・フラグメントの目的のコントローラ・クラスに移動します。各種ページに使用するコントローラ・クラスを次に示します。

    • 標準JSFページの場合 - oracle.adf.controller.v2.lifecycle.PageControllerを指定

      afterPhase/beforePhaseイベントを受信する必要がある場合は、oracle.adf.controller.v2.lifecycle.PagePhaseListenerを指定します。

    • ページ・フラグメント - 次を指定します。
      oracle.adf.model.RegionController


    ヒント:

    完全修飾クラス名としてページ定義のControllerClass属性の値を指定するか、ControllerClassフィールドに、クラスに直接解決されるEL式を入力できます。

    ControllerClass属性の値にEL式を使用すると、#{YourExpression}が有効なクラスではないことを示す警告が「構造」ウィンドウに表示される場合があります。この警告は無視しても問題ありません。

  前
前 		 次
次
  目次へ移動
目次