この章では、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()
メソッドを使用して、それらのオブジェクトを格納する必要があります。