| Oracle® Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発 12c (12.1.2) E48096-02 |
|
 前 |
 次 |
この章では、ADF Facesコンポーネントに用意されている部分ページ・レンダリング機能を使用して、ページ全体ではなく、ページの一部をレンダリングする方法について説明します。
この章では、次の項目について説明します。
Ajax(非同期のJavaScriptおよびXML)は、対話型Webアプリケーションを作成するためのWeb開発手法であり、Ajaxを使用したアプリケーションでは、Webページ全体を再レンダリングせずに少量のデータを内部的にサーバーと交換するため、Webページのレスポンスが向上します。その結果、Webページの対話性、速度および使い勝手が向上します。
ADF Facesでは、Ajaxの部分ページ・レンダリング動作を実現する機能を部分ページ・レンダリング(PPR)と呼びます。PPRでは、JSFページ・リクエスト・ライフサイクル(変換と検証を含む)がページ上の特定のコンポーネントについてのみ実行されます。一部のADF Facesコンポーネントはイベント・ルート・コンポーネントとみなされ、この最適化されたライフサイクルが実行される境界を決定します。
イベント・ルート・コンポーネントは、2通りの方法で決定できます。
イベント: 特定のイベントはルートであるコンポーネントを示します。たとえば、showDetailコンポーネントを展開または縮小する(9.9項「コンテンツの動的な表示および非表示」を参照)と送信される表示イベントは、showDetailコンポーネントがルートであることを示します。showDetailコンポーネントが展開または縮小されると、そのコンポーネントおよびその子コンポーネントでのみライフサイクルが実行されます。ルート・コンポーネントを識別するその他のイベントの例は、ツリーのノードの展開時の表示イベント、または表でのソート・イベントです。対応するイベント・ルート・コンポーネントを持つイベントの完全なリストは、6.1.1項「イベントおよび部分ページ・レンダリング」の表6-1を参照してください。
コンポーネント: 一部のコンポーネントは暗黙の境界として認識されるため、ルート・コンポーネントです。たとえば、フレームワークはポップアップ・ダイアログが境界であることを認識します。ダイアログ内でトリガーされたイベントに関係なく、ダイアログ外のコンポーネントでライフサイクルは実行されません。ポップアップでのみ実行されます。
イベント・ルート・コンポーネントとみなされるコンポーネントは、次のとおりです。
popup
region
panelCollection
calendar
editableValueHolderコンポーネント(inputTextなど)
この組込みPPR機能で対応できないケースとして、境界の外にあるコンポーネントを最適化されたライフサイクルに含める必要が生じる場合があります。これは、部分トリガー属性を使用して、1つのコンポーネントがトリガーとして機能し、別のコンポーネントがリスナーとして機能するように依存関係を設定することにより、宣言的に構成できます。トリガー・コンポーネントでイベントが発生すると、トリガー・コンポーネントとトリガーの子コンポーネントでライフサイクルが実行され(前述のように)、その後、リスナーが存在する場合はリスナー・コンポーネントとリスナーの子コンポーネントでもライフサイクルが実行されます。
たとえば、必須属性がtrueに設定されたinputTextコンポーネントがページにあるとします。同じページにラジオ・ボタンがあり、選択すると、図8-1に示すようにoutputTextコンポーネントのテキストをページに表示または非表示します。
また、必要なテキストをフィールドに入力する前にユーザーがラジオ・ボタンを選択できるようにするとします。送信アクションを自動的にトリガーするようにラジオ・ボタン・コンポーネントを設定し、そのimmediate属性をtrueに設定してinputTextコンポーネントより前に処理されるようにすることもできますが、valueChangeEventリスナーを追加し、その中でレスポンスのレンダリング・フェーズに移って、ラジオ・ボタンが処理されるときに入力テキスト・コンポーネントに対して検証が実行されないようにする必要もあります。
このコードをリスナーに書き込むかわりに、partialTriggersを使用して、ラジオ・ボタンおよび出力テキスト・コンポーネントのみでライフサイクルが実行されるように設定することができます。例5-4に示すように、ラジオ・ボタンをトリガーとし、出力テキストを含むpanelGroupLayoutコンポーネントをターゲットとして設定します。
|
ヒント: 出力テキストは、非表示として構成されている場合にレンダリングされないため、ターゲットにすることができません。したがって、 |
例8-1 宣言的なPPRの例
<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コンポーネントが両方のラジオ・コンポーネントのターゲットとして設定されているため、イベントが起動されると、selectBooleanRadio(ルート)、panelGroupLayoutコンポーネント(ルートのターゲット)とその子コンポーネント(outputTextコンポーネント)のみライフサイクルの処理が行われます。outputTextコンポーネントは表示ラジオ・ボタンの選択時にのみレンダリングされるよう構成されているため、ユーザーは、ラジオ・ボタンの上の必須入力フィールドにテキストを入力しなくても、ラジオ・ボタンを選択して出力テキストを表示できます。
ただし、部分トリガー属性を使用してコンポーネント間の依存関係を設定した場合は、トリガー・コンポーネントからのあらゆるイベントにより、ターゲット・コンポーネントとその子コンポーネントの実行とレンダリングが引き起こされます。その結果、検証エラーが発生する場合があります。
たとえば、例8-2に示すように、panelGroupLayout内にoutputTextコンポーネントのかわりにinputTextコンポーネントを使用し、このrequired属性をtrueに設定するとします。
例8-2 PPRで検証されるpanelGroupコンポーネント内のinputTextコンポーネント
<af:form>
<af:selectBooleanRadio id="show1" autoSubmit="true" text="Show"
value="#{validate.show1}"/>
<af:selectBooleanRadio id="hide1" autoSubmit="true" text="Hide"
value="#{validate.hide1}"/>
<af:panelGroupLayout partialTriggers="show1 hide1">
<af:inputText label="Required Field" required="true"
rendered="#{validate.show1}"/>
</af:panelGroupLayout>
</af:form>
この例では、ライフサイクルはルート(selectBooleanRadioコンポーネント)、ターゲット(panelGroupLayoutコンポーネント)およびターゲットの子(inputTextコンポーネント)で実行されるため、inputTextコンポーネントは検証されます。inputTextコンポーネントが必須としてマークされているため、値がないと、検証が失敗し、エラーがスローされます。エラーのため、ライフサイクルはレスポンスのレンダリング・フェーズに移り、ラジオ・ボタンにバインドされているモデル値は更新されません。このため、ラジオ・ボタンの値が更新されず、panelGroupLayoutコンポーネントは表示または非表示にできません。
このようなケースに対しては、コンポーネントによって特定のイベント(1つまたは複数)が起動されたときに、どのターゲットを実行し、どのターゲットをレンダリングするかを明示的に構成することができます。この新しい例では、selectBooleanRadioボタンで発生したvalueChangeイベントによってPPRをトリガーしますが、panelGroupLayoutコンポーネントとその子コンポーネントでライフサイクルを実行するかわりに、ラジオ・ボタンでのみ実行します。ただし、フォーム全体をレンダリングする必要があります。そのレンダリングの実行時に、inputTextコンポーネントをレンダリングするかどうかを決定できます。PPRを引き起こすイベントと、実行およびレンダリングの対象にするコンポーネントを明示的に決定する必要がある場合は、targetタグを使用します。例8-3に、これを行うJSFコードを示します。
例8-3 PPRに含めるイベントとコンポーネントを決定するtargetタグ
<af:panelFormLayout id="pfl1"> <af:selectBooleanRadio id="show2" autoSubmit="true" text="Show" value="#{validate.show2}"/> <af:target events="valueChange" execute="show2 hide2" render="pfl1"/> <af:selectBooleanRadio id="hide2" autoSubmit="true" text="Hide" value="#{validate.hide2}"/> <af:target events="valueChange" execute="hide2 show2" render="pfl1"/> <af:panelGroupLayout id="pgl1"> <af:inputText label="Required Field" required="true" rendered="#{validate.show2}"/> </af:panelGroupLayout> </af:panelFormLayout>
この例では、どちらかのselectBooleanRadioコンポーネントからvalueChangeイベントが起動された場合に、selectBooleanRadioコンポーネントのみでライフサイクルが実行される一方で、panelFormLayoutコンポーネント全体がレンダリングされます。
|
ヒント: アプリケーションでFusionテクノロジ・スタックを使用する場合、任意のページで自動部分ページ・レンダリング機能を有効にできます。これによって、バックエンド・ビジネス・ロジックの結果として値が変更されるコンポーネントが自動的に再レンダリングされます。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の部分ページ・レンダリングとイテレータ・バインディングに関する必知事項を参照してください。 |
また、ADF FacesアプリケーションはナビゲーションにPPRを使用できます。標準JSFアプリケーションでは、あるページから次のページへのナビゲーションには新しいページのレンダリングが必要です。Ajaxのようなコンポーネントを使用する場合、様々なJavaScriptライブラリおよびスタイル・シートのダウンロードに必要な時間により、これがオーバーヘッドの原因になることがあります。このコストの高いオーバーヘッドを回避するために、ADF Facesアーキテクチャは、実際には単一ページに残ったままオプションで完全ページ遷移をシミュレートすることで、JavaScriptコードおよびスキン・スタイルの再ロードの必要性を回避できます。
|
注意: PPRが機能するためには、ブラウザでJavaScriptが有効になっている必要があります。 |
部分トリガーを使用した場合、トリガー・コンポーネントと呼ばれるコンポーネントでイベントが発生すると、ターゲット・コンポーネントと呼ばれるコンポーネントが再レンダリングされます。
たとえば、図8-2に示すように、File Explorerアプリケーションには「検索」パネルに検索結果を表示する表が含まれています。検索ボタンを使用すると、この表(この表のみ)がレンダリングされます。検索ボタンがトリガーとして構成され、表がターゲットとして構成されています。このボタンからイベントが起動されると、表とそのコンポーネントでライフサイクルが実行されます(ボタンと同様に)。
|
注意: トリガー・コンポーネントに関連付けられているすべてのイベントではなく、特定のイベントが発生したときにのみ、コンポーネントを実行またはレンダリングすることが必要になる場合があります。このような場合には、targetタグを使用する必要があります。詳細は、8.3項「targetタグを使用したPPRの実行」を参照してください。コンポーネントを実行またはレンダリングするかどうかをなんらかのロジックによって決める必要がある場合は、プログラムによってPPRを有効にすることができます。詳細は、8.4項「部分ページ・レンダリングのプログラムによる有効化」を参照してください。 |
トリガー・コンポーネントで、PPRリクエストが発生したことをフレームワークに通知する必要があります。コマンド・コンポーネントでは、partialSubmit属性をtrueに設定することでこれを行えます。これを行うと、コマンド・コンポーネントがクリックされるたびに部分ページ・リクエストが発生します。
たとえば、ページにinputTextコンポーネント、buttonコンポーネントおよびoutputTextコンポーネントが含まれているとします。ユーザーがinputTextコンポーネントに値を入力してbuttonコンポーネントをクリックすると、入力値がoutputTextコンポーネントに反映されます。このbuttonコンポーネントのpartialSubmit属性をtrueに設定できます。
ただし、コマンド・コンポーネント以外のコンポーネントでPPRをトリガーできます。ADF Facesの入力コンポーネントと選択コンポーネントには、値が変更されると部分ページ・リクエストを自動的にトリガーする機能があります。この機能を使用するには、入力または選択コンポーネントのautoSubmit属性を使用して、値が入力されて送信されると、valueChangeEventイベントが発生するようにします。ターゲット・コンポーネントが設定されているかぎり、フレームワークにPPRを実行するよう通知するのはこのイベントです。前述の例で、buttonコンポーネントを削除し、かわりにinputTextコンポーネントのautoSubmit属性をtrueに設定することもできます。値が変更されるたびに、PPRリクエストが起動されます。
|
ヒント: 入力コンポーネントの
|
PPRがトリガーされると、ターゲットとして構成されているすべてのコンポーネントでライフサイクルが実行されます。コンポーネントは、partialTriggers属性をトリガー・コンポーネントの相対IDに設定することで、ターゲットとして構成します。相対IDの詳細は、4.8項「ページでのクライアント・コンポーネントの検索」を参照してください。
たとえば、inputTextコンポーネントに対する変更を受けてoutputTextを更新するには、partialTriggers属性をinputTextコンポーネントの相対IDに設定します。
コンポーネントのイベントには、たとえばshowDetailコンポーネントのdisclosureイベントや表のsortイベントのように、デフォルトでPPRをトリガーするものがあるため、注意が必要です。これは、partialTriggers属性をそのコンポーネントのIDに設定することでターゲットに対して構成された任意のコンポーネントが、これらのタイプのイベントの発生時に再レンダリングすることを意味します。PPRをトリガーするイベントを限定するには、partialTriggers属性を使用するかわりに、targetタグを使用する必要があります。このタグを使用すれば、どのイベントがPPRを引き起こすかを明示的に設定できます。
partialTriggers属性のかわりにtargetタグを使用する必要があるもう1つの例として、トリガー・コンポーネントがinputLovまたはinputComboBoxLovで、ターゲット・コンポーネントがrequiredに設定された依存入力コンポーネントであるケースがあげられます。このケースでは、LOVポップアップが表示されたときに、入力コンポーネントに対して検証エラーがスローされます。かわりにtargetタグを使用すると、どのコンポーネントを実行するかと(LOV)、どのコンポーネントをレンダリングするかを(入力コンポーネント)、明示的に設定できます。詳細は、8.3項「targetタグを使用したPPRの実行」を参照してください。
別のコンポーネントで発生したイベントに基づいてコンポーネントをレンダリングするには、どのコンポーネントがトリガーかを宣言する必要があります。
|
ベスト・プラクティス: 同じページに対して部分トリガーと |
始める前に:
宣言的な部分ページ・レンダリングに関する知識が役立つ場合があります。詳細は、8.2項「部分トリガーの使用」を参照してください。
部分トリガーを使用するには:
構造ウィンドウで、トリガー・コンポーネント(そのアクションによってPPRが起こるコンポーネント)を選択します。
「プロパティ」ウィンドウの「共通」セクションを開き、id属性が設定されていない場合は設定します。値はそのコンポーネントのネーミング・コンテナ内で一意である必要があります。コンポーネントがネーミング・コンテナ内に含まれていない場合、IDはページで一意である必要があります。ネーミング・コンテナの詳細は、4.8項「ページでのクライアント・コンポーネントの検索」を参照してください。
|
ヒント: JDeveloperは、コンポーネントIDを自動的に割り当てます。この値を安全に変更できます。コンポーネントのIDは、有効なXML名であることが必要です。つまり、名前の先頭に数字を使用したり、IDにスペースを使用することはできません。JSFではIDでのコロン(:)も禁止されています。 |
トリガー・コンポーネントがコマンド・コンポーネントの場合、「プロパティ」ウィンドウで「動作」セクションを開き、partialSubmit属性をtrueに設定します。
トリガー・コンポーネントがフォーム内の入力または選択コンポーネントで、値を送信する場合は、「プロパティ」ウィンドウの「動作」セクションを開き、コンポーネントのautoSubmit属性をtrueに設定します。
|
注意: コンポーネントで値を送信する場合のみ、 |
構造ウィンドウで、PPRのトリガー元イベントが発生したときに再レンダリングするターゲット・コンポーネントを選択します。
「プロパティ」ウィンドウの「動作」セクションを開き、partialTriggers属性にカーソルを合わせたときに表示されるアイコンをクリックして「編集」を選択します。
「属性の編集」ダイアログで、トリガー・コンポーネントを選択済パネルに移動し、「OK」をクリックします。トリガー・コンポーネントがネーミング・コンテナ内にある場合、JDeveloperで相対パスが自動的に作成されます。
|
ヒント:
|
例8-4に、PPRを実行するよう構成されたlinkコンポーネントを示します。
例8-4 部分送信を介して部分ページ・レンダリングを有効化するためのコード
<af:link id="deleteFromCart" partialSubmit="true" actionListener="#{homeBean...}" text="Delete From Cart">
例8-4に示したIDがdeleteFromCartのリンクがクリックされると再レンダリングされるoutputTextコンポーネントを、例8-5に示します。
例8-5 他のコンポーネントによってトリガーされる部分ページ・レンダリングのコード
<af:outputText id="estimatedTotalInPopup"
partialTriggers="deleteFromCart"
value="#{shoppingCartBean...}"/>
ADF Facesアプリケーションでは、一部のコンポーネントで(暗黙的に、あるいは部分トリガーをリスニングするよう構成されていて)PPRが使用されるため、ユーザーがブラウザの戻るボタンをクリックしたときの動作は、単にJSFコンポーネントを使用するアプリケーションとは多少異なります。
単純なJSFコンポーネントを使用するアプリケーションでは、ユーザーがブラウザの戻るボタンをクリックすると、最後にレンダリングされたときのDocument Object Model (DOM)の状態にページがブラウザによって戻されます。しかし、JavaScriptの状態は、ユーザーが最初にページにアクセスしたときの状態です。
たとえば、ユーザーがPageAにアクセスしたとします。ユーザーがページ上のコンポーネントと対話した後で、PPRイベントがJavaScriptを使用して発生したとします。この新しいバージョンのページをPageA1と呼びます。次に、ユーザーがPageBにナビゲートし、ブラウザの戻るボタンをクリックしてPageAに戻るとします。PageA1上にはDOMがあったためユーザーにはDOMが表示されますが、JavaScriptは実行されないため、ページの一部はPageAの場合と同様になります。これは、ページに対する変更が失われることを意味する場合があります。ページをリフレッシュするとJavaScriptが実行されるため、ユーザーはPageA1を表示していたときの状態に戻ります。ADF Facesを使用するアプリケーションでは、リフレッシュは不要ですが、フレームワークは組込みサポートを提供するため、戻るボタンがクリックされるとJavaScriptが実行されます。
多くのイベントが関連付けられている表などのコンポーネントでは、イベントがトリガーされるたびにPPRが発生し、その表の子コンポーネントや、その表を部分トリガーとするコンポーネントが実行およびレンダリングされます。特定のイベントが発生した場合にのみコンポーネントがレンダリングまたは実行されるようにする場合や、特定のコンポーネントのみが実行またはレンダリングされるようにする場合は、targetタグを使用します。
特定の状況でコンポーネントの検証をスキップする必要がある場合には、targetタグが特に役立ちます。たとえば、図8-3に示すような、必須フィールドと「Submit」ボタンおよび「Cancel」ボタンを含むフォームがあるとします。
通常の状況では、「Cancel」ボタンがクリックされるとフォーム内のすべてのフィールドが処理されます。入力テキストフィールドは必須であるため、その検証は失敗します。
この失敗を回避するには、targetタグを「Cancel」ボタンの子として使用します。targetタグを使用すると、特定のイベント(1つまたは複数)がコンポーネントによって起動されたときに、どのターゲットを実行およびレンダリングするかを記述できます。この例では、例8-6に示すように、「Cancel」ボタンのtargetタグをそのボタンのみが実行されるように構成しています。
例8-6 どのコンポーネントを実行およびレンダリングするかを決定するボタンのtargetタグ
<af:panelFormLayout id="pfl1" labelAlignment="top">
. . .
<af:panelLabelAndMessage id="plam12" for="it3">
<af:inputText label="Required Field" required="true"
rendered="#{validate.show3}" id="it3"/>
</af:panelLabelAndMessage>
<af:panelGroupLayout layout="horizontal" id="pgl9">
<af:button text="submit" partialSubmit="true" id="cb2"
<af:target execute="@this it3" render="pfl1"/>
</af:button>
<af:button actionListener="#{validate.handleCancel}"
partialSubmit="true" text="cancel" id="cb1">
<af:target execute="@this"/>
</af:button>
</af:panelGroupLayout>
</af:panelFormLayout>
この例では、「Submit」ボタンがクリックされると、そのボタンとinputTextコンポーネントが実行され、panelFormLayoutコンポーネントのコンテンツがレンダリングされます。ただし、「Cancel」ボタンがクリックされた場合は、「Cancel」ボタンのみが実行されます。そのクリックの結果としてレンダリングされるものは何もありません。
LOVコンポーネントと依存入力テキスト・コンポーネントを使用する場合には、検証に関する別の一般的な問題が生じることがあります。たとえば、ユーザーが従業員名を選択するためのinputListOfValuesコンポーネントがあるとします。ユーザーがLOVから名前を選択したときに従業員番号入力テキストフィールドにその従業員の番号が自動的に移入されるようにするとともに、そのフィールドを必須フィールドにします。
LOVをトリガーとして設定して部分トリガーを使用し、入力テキスト・コンポーネントをターゲットとして使用すると、その入力テキスト・コンポーネントはポップアップが閉じたときに検証に失敗します。ユーザーが検索アイコンをクリックすると、ライフサイクルがルート(inputListOfValuesコンポーネント)とターゲット(inputTextコンポーネント)の両方で実行されるため、inputTextコンポーネントが検証されます。図8-4に示すように、inputTextコンポーネントが必須としてマークされているのに値がないため、検証が失敗します。
かわりに、例8-7に示すようにtargetタグをinputListOfValuesコンポーネントの子として使用して、inputListOfValuesコンポーネントのみが実行され、入力テキスト・コンポーネントが新しく選択された値でレンダリングされるように構成することができます。
例8-7 LOVコンポーネントでのtargetタグの使用
<af:panelFormLayout id="pfl2">
<af:inputListOfValues label="Ename" id="lov21" required="true"
value="#{validateLOV.ename}" autoSubmit="true"
popupTitle="Search and Select: Ename" searchDesc="Choose a name"
model="#{validateLOV.listOfValuesModel}"
validator="#{validateLOV.validate}">
<af:target execute="@this" render="it1"/>
</af:inputListOfValues>
<af:inputText label="Empno" value="#{validateLOV.empno}" required="true"
id="it1"/>
</af:panelFormLayout>
targetタグは、PPRを引き起こすイベントの発生元となるコンポーネントの子として配置します。たとえば、図8-3のフォームの場合は、targetタグを「Cancel」ボタンの子として配置します。その後、PPRに含めるイベントとコンポーネントを明示的に指定します。
|
ベスト・プラクティス: 同じページに対して部分トリガーと |
始める前に:
formコンポーネントに関する知識が役立つ場合があります。詳細は、8.3項「targetタグを使用したPPRの実行」を参照してください。
targetタグを使用するには:
「コンポーネント」ウィンドウで、「操作」パネルから「ターゲット」をドラッグし、PPRを制御するイベントをトリガーするコンポーネントの子としてドロップします。
「プロパティ」ウィンドウで、次を設定します。
Events: そのコンポーネントでtargetタグによって処理するイベントの空白区切りリストを入力します。次のイベントがサポートされています。
action
calendar
calendarActivity
calendarActivity
durationChange
calendarDisplayChange
carouselSpin
contextInfo
dialog
disclosure
focus
item
launch
launchPopup
poll
popupCanceled
popupFetch
query
queryOperation
rangeChange
regionNavigation
return
returnPopupData
returnPopup
rowDisclosure
selection
sort
valueChange
コンポーネントが実行するイベントのうち、このリストに含めなかったものは、フレームワークによって通常どおりに処理されます。
コンポーネントのすべてのイベントをtargetタグで制御する場合は、@allキーワードを使用します。
デフォルトは@allです。
Execute: event属性で指定されたリストに含まれるイベント(1つまたは複数)が発生したときに実行するコンポーネントのコンポーネントIDの空白区切りリストを入力します。コンポーネントIDのかわりに、次のキーワードを使用できます。
@this: ターゲットの親コンポーネントのみが実行されます。
@all: 同じaf:formタグ内のすべてのコンポーネントが実行されます。これを使用すると、すべてのコンポーネントが通常のページ・ライフサイクルの中で実行されるため、実際にはPPRが行われません。
@default: イベント・ルート・コンポーネントまたは部分トリガーを使用して(つまりtargetタグが使用されていないかのように)コンポーネントの実行が処理されます。この値がデフォルトです。
|
注意: JSFタグ |
Render: event属性で指定されたリストに含まれるイベント(1つまたは複数)が発生したときにレンダリングするコンポーネントのコンポーネントIDの空白区切りリストを入力します。コンポーネントIDのかわりに、次のキーワードを使用できます。
@this: ターゲットの親コンポーネントのみがレンダリングされます。
@all: 同じaf:formタグ内のすべてのコンポーネントがレンダリングされます。
@default: コンポーネントのレンダリングはフレームワークによって決定されます。この値がデフォルトです。
図8-3に示されているラジオ・ボタンと必須フィールドを備えたフォームのコードを、例8-8に示します。最初のtargetタグは、show3ラジオ・ボタンの子であり、show3およびhide3ラジオ・ボタンを実行してpanelFormLayoutをレンダリングするように構成されているため、そのボタンが選択されると、2つのラジオ・ボタンのみでライフサイクルが実行され、フォーム全体がレンダリングされます。inputTextコンポーネントは、executeリストに含まれていないため実行されませんが、フォームに含まれているためレンダリングされます。
targetタグは、「Submit」ボタンと「Cancel」ボタンでも使用されています。「Submit」ボタンの場合、入力テキスト・コンポーネントでライフサイクルを実行する必要があるため、そのターゲットのexecute属性に対する値のリストに、「Submit」ボタンとともに入力テキスト・コンポーネントも指定されています。ただし、「Cancel」ボタンの場合は、入力テキスト・コンポーネントを処理しないため、そのターゲットのexecute属性に対する値のリストに入力テキスト・コンポーネントは含まれていません。したがって、検証エラーがスローされることはありません。
例8-8 targetタグの使用による検証の問題の回避
<af:panelFormLayout id="pfl1"> <af:panelLabelAndMessage label="Show/Hide Field" id="plam11"> <af:selectBooleanRadio id="show3" autoSubmit="true" text="Show" group="group3" value="#{validate.show3}"> <af:target execute="show3 hide3" render="pfl1"/> </af:selectBooleanRadio> <af:selectBooleanRadio id="hide3" autoSubmit="true" text="Hide" group="group3" value="#{validate.hide3}"> <af:target execute="hide3 show3" render="pfl1"/> </af:selectBooleanRadio> </af:panelLabelAndMessage> <af:panelLabelAndMessage label="Required Field" id="plam12" showRequired="true"> <af:inputText label="Required Field" required="true" simple="true" rendered="#{validate.show3}" id="it3"/> </af:panelLabelAndMessage> <af:panelGroupLayout layout="horizontal" id="pgl9"> <f:facet name="separator"> <af:spacer width="2px" id="s7"/> </f:facet> <af:commandButton text="submit" partialSubmit="true" disabled="#{validate.hide3}" id="cb2"> <af:target execute="@this it3" render="pfl1"/> </af:commandButton> <af:commandButton actionListener="#{validate.handleCancel}" partialSubmit="true" text="cancel" id="cb1"> <af:target execute="@this" render="ot10"/> </af:commandButton> <af:outputText clientComponent="true" value="Cancel Click: #{validate.clickCount}" id="ot10"/> </af:panelGroupLayout>
特定のロジックに基づいてターゲットをレンダリングする必要がある場合は、プログラムによって部分ページ・レンダリングを有効にすることができます。
部分ページ・レンダリングを有効にするにはaddPartialTargetメソッドを使用します。
PPRをプログラムによって有効にする手順:
ターゲット・コンポーネントがレンダリングされる原因となるイベントのリスナー・メソッドを作成します。
addPartialTarget()メソッドを使用して、イベントがトリガーされると部分ターゲット・コンポーネントが再レンダリングされるよう、そのイベントの部分ターゲットとしてコンポーネントを追加します(そのIDを使用)。このメソッドを使用して、再レンダリングするコンポーネントと再レンダリングをトリガーするイベントを関連付けます。
たとえば、File ExplorerアプリケーションにはNavigatorManager.refresh()メソッドが含まれています。起動されると、ナビゲータ・アコーディオンが再レンダリングされます。
JSFページで、ターゲット・コンポーネントを選択します。「プロパティ」ウィンドウで、コンポーネントIDを入力してClientComponentをtrueに設定します。
|
注意:
|
「プロパティ」ウィンドウで、リフレッシュおよび手順1で作成したリスナー・メソッドへのバインドを引き起こすイベントのリスナーを見つけます。
従来のページ全体の遷移のかわりに、PPRリクエストを使用してナビゲーションがトリガーされるように、ADF Facesアプリケーションを構成できます。新しいページは、PPRを使用してクライアントに送信されます。部分ページ・ナビゲーションは、デフォルトでは無効になっています。
部分ページ・ナビゲーションが使用される場合、位置を把握しておく(ブックマーク用、リフレッシュが行われたとき用など)ために、フレームワークでURLのハッシュ部分を使用します。URLのこの部分には、ブラウザに表示される実際のページが含まれます。
また、JavaScriptおよびCSSは各ページにロードされません。resourceタグを使用して、現在のページに固有のJavaScriptおよびCSSコンテンツを含める必要があります。<f:verbatim>または<trh:stylesheet>タグは機能しません。詳細は、4.2項「JavaScriptのページへの追加」を参照してください。
アプリケーションで部分ページ・ナビゲーションが有効になっている場合、getリクエストはボタンおよびリンク・コンポーネントに対してサポートされます。
|
注意: PPR 他のブラウザの場合、これらのコンポーネントの |
部分ページ・ナビゲーションは、web.xmlファイルのoracle.adf.view.rich.pprNavigation.OPTIONSコンテキスト・パラメータをonに設定することで有効にできます。
始める前に:
部分ページ・ナビゲーションに関する知識が役立つ場合があります。詳細は、8.5項「部分ページ・ナビゲーションの使用」を参照してください。
部分ページ・ナビゲーションを使用する手順:
web.xmlファイルをダブルクリックします。
ソース・エディタで、oracle.adf.view.rich.pprNavigation.OPTIONSパラメータを次のいずれかに変更します。
on: 部分ページ・ナビゲーションを有効にします。
|
注意: パラメータを |
onWithForcePPR: 部分ページ・ナビゲーションを有効にし、すべてのアクション・イベント(ナビゲーションが行われないアクション・イベントも含む)でPPRチャネルを使用するためのフレームワークを通知します。部分ページ・ナビゲーションでは、PPRチャネルを介してアクション・イベントを送信する必要があるため、このオプションを使用して部分ページ・ナビゲーションを簡単に有効化できます。
部分ページ・ナビゲーションを使用している場合、通常はページのビジュアル・コンテンツのみ再レンダリングされます(ヘッダー・コンテンツはすべてのページで一定のままです)。ただし、ページのアクションがフル・ページ送信を使用するように定義されている場合、およびアクションでナビゲーションが行われない場合も、ドキュメント全体が再レンダリングされます。
PPRナビゲーションを使用する前に、次の点に注意します。
PPRナビゲーションを使用する場合、このナビゲーションに関連するすべてのページで同じCSSスキンを使用する必要があります。
resourceタグを使用して、現在のページに固有のJavaScriptおよびCSSコンテンツを含める必要があります。
標準のページ・ナビゲーションとは異なり、部分ナビゲーションではJavaScriptグローバル(グローバル・スコープに定義されている変数および関数)はアンロードされません。これが発生するのは、ウィンドウ・オブジェクトが部分ページの遷移でも残るためです。ページ固有のグローバル変数および関数を使用するアプリケーションでは、AdfPage.getPageProperty()メソッドおよびAdfPage.setPageProperty()メソッドを使用して、それらのオブジェクトを格納する必要があります。
