| Oracle® Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発 12c (12.2.1.1.0) E77398-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
Ajax(非同期のJavaScriptおよびXML)は、対話型Webアプリケーションを作成するためのWeb開発手法であり、Ajaxを使用したアプリケーションでは、Webページ全体を再レンダリングせずに少量のデータを内部的にサーバーと交換するため、Webページのレスポンスが向上します。その結果、Webページの対話性、速度および使い勝手が向上します。
ADF Facesでは、Ajaxの部分ページ・レンダリング動作を実現する機能を部分ページ・レンダリング(PPR)と呼びます。PPRでは、JSFページ・リクエスト・ライフサイクル(変換と検証を含む)がページ上の特定のコンポーネントについてのみ実行されます。一部のADF Facesコンポーネントはイベント・ルート・コンポーネントとみなされ、この最適化されたライフサイクルが実行される境界を決定します。
イベント・ルート・コンポーネントは、2通りの方法で決定できます。
イベント: 特定のイベントはルートであるコンポーネントを示します。たとえば、showDetailコンポーネントを展開または縮小する(「コンテンツの動的な表示および非表示」を参照)と送信される表示イベントは、showDetailコンポーネントがルートであることを示します。showDetailコンポーネントが展開または縮小されると、そのコンポーネントおよびその子コンポーネントでのみライフサイクルが実行されます。ルート・コンポーネントを識別するその他のイベントの例は、ツリーのノードの展開時の表示イベント、または表でのソート・イベントです。対応するイベント・ルート・コンポーネントを持つイベントの完全なリストは、「イベントおよび部分ページ・レンダリング」を参照してください。
コンポーネント: 一部のコンポーネントは暗黙の境界として認識されるため、ルート・コンポーネントです。たとえば、フレームワークはポップアップ・ダイアログが境界であることを認識します。ダイアログ内でトリガーされたイベントに関係なく、ダイアログ外のコンポーネントでライフサイクルは実行されません。ポップアップでのみ実行されます。
イベント・ルート・コンポーネントとみなされるコンポーネントは、次のとおりです。
popup
region
panelCollection
calendar
editableValueHolderコンポーネント(inputTextなど)
この組込みPPR機能で対応できないケースとして、境界の外にあるコンポーネントを最適化されたライフサイクルに含める必要が生じる場合があります。これは、部分トリガー属性を使用して、1つのコンポーネントがトリガーとして機能し、別のコンポーネントがリスナーとして機能するように依存関係を設定することにより、宣言的に構成できます。トリガー・コンポーネントでイベントが発生すると、トリガー・コンポーネントとトリガーの子コンポーネントでライフサイクルが実行され(前述のように)、その後、リスナーが存在する場合はリスナー・コンポーネントとリスナーの子コンポーネントでもライフサイクルが実行されます。
たとえば、必須属性がtrueに設定されたinputTextコンポーネントがページにあるとします。同じページにラジオ・ボタンがあり、選択すると、図8-1に示すようにoutputTextコンポーネントのテキストをページに表示または非表示します。
図8-1 必須フィールドと自動送信のブール
また、必要なテキストをフィールドに入力する前にユーザーがラジオ・ボタンを選択できるようにするとします。送信アクションを自動的にトリガーするようにラジオ・ボタン・コンポーネントを設定し、そのimmediate属性をtrueに設定してinputTextコンポーネントより前に処理されるようにすることもできますが、valueChangeEventリスナーを追加し、その中でレスポンスのレンダリング・フェーズに移って、ラジオ・ボタンが処理されるときに入力テキスト・コンポーネントに対して検証が実行されないようにする必要もあります。
このコードをリスナーに書き込むかわりに、partialTriggersを使用して、ラジオ・ボタンおよび出力テキスト・コンポーネントのみでライフサイクルが実行されるように設定することができます。例5-4に示すように、ラジオ・ボタンをトリガーとし、出力テキストを含むpanelGroupLayoutコンポーネントをターゲットとして設定します。
ヒント:
出力テキストは、非表示として構成されている場合にレンダリングされないため、ターゲットにすることができません。したがって、panelGroupLayoutコンポーネントに配置され、これがターゲットとして構成されます。
<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コンポーネントは表示ラジオ・ボタンの選択時にのみレンダリングされるよう構成されているため、ユーザーは、ラジオ・ボタンの上の必須入力フィールドにテキストを入力しなくても、ラジオ・ボタンを選択して出力テキストを表示できます。
ただし、部分トリガー属性を使用してコンポーネント間の依存関係を設定した場合は、トリガー・コンポーネントからのあらゆるイベントにより、ターゲット・コンポーネントとその子コンポーネントの実行とレンダリングが引き起こされます。その結果、検証エラーが発生する場合があります。
たとえば、次の例に示すように、panelGroupLayout内にoutputTextコンポーネントのかわりにinputTextコンポーネントを使用し、このrequired属性をtrueに設定するとします。
<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タグを使用します。
<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アプリケーションには「検索」パネルに検索結果を表示する表が含まれています。検索ボタンを使用すると、この表(この表のみ)がレンダリングされます。検索ボタンがトリガーとして構成され、表がターゲットとして構成されています。このボタンからイベントが起動されると、表とそのコンポーネントでライフサイクルが実行されます(ボタンと同様に)。
図8-2 検索ボタンで再レンダリングされる表
注意:
トリガー・コンポーネントに関連付けられているすべてのイベントではなく、特定のイベントが発生したときにのみ、コンポーネントを実行またはレンダリングすることが必要になる場合があります。このような場合には、targetタグを使用する必要があります。詳細は、「targetタグを使用したPPRの実行」を参照してください。コンポーネントが実行またはレンダリングされるかどうかをロジックで決定する場合、プログラムによりPPRを有効化できます。詳細は、「部分ページ・レンダリングのプログラムによる有効化」を参照してください。
トリガー・コンポーネントで、PPRリクエストが発生したことをフレームワークに通知する必要があります。コマンド・コンポーネントでは、partialSubmit属性をtrueに設定することでこれを行えます。これを行うと、コマンド・コンポーネントがクリックされるたびに部分ページ・リクエストが発生します。
たとえば、ページにinputTextコンポーネント、buttonコンポーネントおよびoutputTextコンポーネントが含まれているとします。ユーザーがinputTextコンポーネントに値を入力してbuttonコンポーネントをクリックすると、入力値がoutputTextコンポーネントに反映されます。このbuttonコンポーネントのpartialSubmit属性をtrueに設定できます。
ただし、コマンド・コンポーネント以外のコンポーネントでPPRをトリガーできます。ADF Facesの入力コンポーネントと選択コンポーネントには、値が変更されると部分ページ・リクエストを自動的にトリガーする機能があります。この機能を使用するには、入力または選択コンポーネントのautoSubmit属性を使用して、値が入力されて送信されると、valueChangeEventイベントが発生するようにします。ターゲット・コンポーネントが設定されているかぎり、フレームワークにPPRを実行するよう通知するのはこのイベントです。前述の例で、buttonコンポーネントを削除し、かわりにinputTextコンポーネントのautoSubmit属性をtrueに設定することもできます。値が変更されるたびに、PPRリクエストが起動されます。
ヒント:
入力コンポーネントのautoSubmit属性とコマンド・コンポーネントのpartialSubmit属性は同じものではありません。partialSubmitがtrueに設定されている場合、partialTriggers属性に値を持つコンポーネントのみでライフサイクルが実行されます。
autoSubmit属性は、入力コンポーネントと選択コンポーネントで使用され、値が変更されると自動的にフォームを送信するようフレームワークに指示します。autoSubmit属性がtrueに設定されている場合にフォームが送信されると、valueChangeEventイベントが起動され、ライフサイクルはそのイベントのルートとされているコンポーネントとその子でのみ実行されます。詳細は、「最適化されたライフサイクルの使用」を参照してください。
PPRがトリガーされると、ターゲットとして構成されているすべてのコンポーネントでライフサイクルが実行されます。コンポーネントは、partialTriggers属性をトリガー・コンポーネントの相対IDに設定することで、ターゲットとして構成します。相対IDの詳細は、「ページでのクライアント・コンポーネントの検索」を参照してください。
たとえば、inputTextコンポーネントに対する変更を受けてoutputTextを更新するには、partialTriggers属性をinputTextコンポーネントの相対IDに設定します。
コンポーネントのイベントには、たとえばshowDetailコンポーネントのdisclosureイベントや表のsortイベントのように、デフォルトでPPRをトリガーするものがあるため、注意が必要です。これは、partialTriggers属性をそのコンポーネントのIDに設定することでターゲットに対して構成された任意のコンポーネントが、これらのタイプのイベントの発生時に再レンダリングすることを意味します。PPRをトリガーするイベントを限定するには、partialTriggers属性を使用するかわりに、targetタグを使用する必要があります。このタグを使用すれば、どのイベントがPPRを引き起こすかを明示的に設定できます。
partialTriggers属性のかわりにtargetタグを使用する必要があるもう1つの例として、トリガー・コンポーネントがinputLovまたはinputComboBoxLovで、ターゲット・コンポーネントがrequiredに設定された依存入力コンポーネントであるケースがあげられます。このケースでは、LOVポップアップが表示されたときに、入力コンポーネントに対して検証エラーがスローされます。かわりにtargetタグを使用すると、どのコンポーネントを実行するかと(LOV)、どのコンポーネントをレンダリングするかを(入力コンポーネント)、明示的に設定できます。詳細は、「targetタグを使用したPPRの実行」を参照してください。
別のコンポーネントで発生したイベントに基づいてコンポーネントをレンダリングするには、どのコンポーネントがトリガーかを宣言する必要があります。
ベスト・プラクティス
同じページに対して部分トリガーとtargetタグの両方を使用しないでください。判断がつかないときには、targetタグのみを使用します。詳細は、「targetタグを使用したPPRの実行」を参照してください。
始める前に:
宣言的な部分ページ・レンダリングに関する知識が役立つ場合があります。詳細は、「部分トリガーの使用」を参照してください。
部分トリガーを使用するには:
ヒント:
selectBooleanRadioコンポーネントは、部分ページ・レンダリングで1つのコンポーネントのように動作しますが、実際は複数コンポーネントです。したがって、グループ内の異なるselectBooleanRadioの選択に基づいて他のコンポーネント(inputTextコンポーネントなど)を変更する場合、親コンポーネント内にまとめ、親コンポーネントのpartialTriggers属性がすべてのSelectBooleanRadioコンポーネントを指すように設定する必要があります。
次の例で、PPRを実行するよう構成されたlinkコンポーネントを示します。
<af:link id="deleteFromCart" partialSubmit="true" actionListener="#{homeBean...}" text="Delete From Cart">
前述の例に示したIDがdeleteFromCartのリンクがクリックされると再レンダリングされるoutputTextコンポーネントを、次の例に示します。
<af:outputText id="estimatedTotalInPopup"
partialTriggers="deleteFromCart"
value="#{shoppingCartBean...}"/>
ヒント:
PPRの最中にページ上のコンポーネントが検証されないようにするには、targetタグを使用する必要があります。詳細は、「targetタグを使用したPPRの実行」を参照してください。
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」ボタンを含むフォームがあるとします。
図8-3 「Cancel」ボタンがクリックされると処理される必須フィールド
通常の状況では、「Cancel」ボタンがクリックされるとフォーム内のすべてのフィールドが処理されます。入力テキストフィールドは必須であるため、その検証は失敗します。
この失敗を回避するには、targetタグを「Cancel」ボタンの子として使用します。targetタグを使用すると、特定のイベント(1つまたは複数)がコンポーネントによって起動されたときに、どのターゲットを実行およびレンダリングするかを記述できます。この例では、次の例に示すように、「Cancel」ボタンの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-4 値が必須であるため検証エラーがスローされる
かわりに、次の例に示すようにtargetタグをinputListOfValuesコンポーネントの子として使用して、inputListOfValuesコンポーネントのみが実行され、入力テキスト・コンポーネントが新しく選択された値でレンダリングされるように構成することができます。
<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に含めるイベントとコンポーネントを明示的に指定します。
ベスト・プラクティス
同じページに対して部分トリガーとtargetタグの両方を使用しないでください。判断がつかないときには、targetタグのみを使用します。
始める前に:
formコンポーネントに関する知識が役立つ場合があります。詳細は、「targetタグを使用したPPRの実行」を参照してください。
targetタグを使用するには:
従来のページ全体の遷移のかわりに、PPRリクエストを使用してナビゲーションがトリガーされるように、ADF Facesアプリケーションを構成できます。新しいページは、PPRを使用してクライアントに送信されます。部分ページ・ナビゲーションは、デフォルトでは無効になっています。
部分ページ・ナビゲーションが使用される場合、位置を把握しておく(ブックマーク用、リフレッシュが行われたとき用など)ために、フレームワークでURLのハッシュ部分を使用します。URLのこの部分には、ブラウザに表示される実際のページが含まれます。
また、JavaScriptおよびCSSは各ページにロードされません。resourceタグを使用して、現在のページに固有のJavaScriptおよびCSSコンテンツを含める必要があります。<f:verbatim>または<trh:stylesheet>タグは機能しません。詳細は、「JavaScriptのページへの追加」を参照してください。
アプリケーションで部分ページ・ナビゲーションが有効になっている場合、getリクエストはボタンおよびリンク・コンポーネントに対してサポートされます。
注意:
PPR getリクエストは、Internet Explorerでサポートされません。このブラウザを使用する場合、URLは標準の取得リクエストを使用してロードされます。
他のブラウザの場合、これらのコンポーネントのgetリクエストはアプリケーション内のページに対してのみサポートされます。
部分ページ・ナビゲーションは、web.xmlファイルのoracle.adf.view.rich.pprNavigation.OPTIONSコンテキスト・パラメータをonに設定することで有効にできます。
始める前に:
部分ページ・ナビゲーションに関する知識が役立つ場合があります。詳細は、「部分ページ・ナビゲーションの使用」を参照してください。
部分ページ・ナビゲーションを使用する手順:
PPRナビゲーションを使用する前に、次の点に注意します。
PPRナビゲーションを使用する場合、このナビゲーションに関連するすべてのページで同じCSSスキンを使用する必要があります。
resourceタグを使用して、現在のページに固有のJavaScriptおよびCSSコンテンツを含める必要があります。
標準のページ・ナビゲーションとは異なり、部分ナビゲーションではJavaScriptグローバル(グローバル・スコープに定義されている変数および関数)はアンロードされません。これが発生するのは、ウィンドウ・オブジェクトが部分ページの遷移でも残るためです。ページ固有のグローバル変数および関数を使用するアプリケーションでは、AdfPage.getPageProperty()メソッドおよびAdfPage.setPageProperty()メソッドを使用して、それらのオブジェクトを格納する必要があります。
