| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章では、ADF FacesコンポーネントおよびADFデータバインディングを使用してデータバインドされたフォームを作成するための、「データ・コントロール」パネルの使用方法を説明します。
この章の内容は次のとおりです。
ビジネス・サービス用に作成されたデータ・コントロールを使用して情報の表示および収集を実行するための、UIページを作成できます。たとえば、「データ・コントロール」パネルを使用して、項目の属性をドラッグし、読取り専用テキストまたはラベル付き入力テキスト・フィールドとして、値を表示できます。関連データの表示および更新に必要なすべてのJSFタグとバインディング・コードがJDeveloperによって作成されます。「データ・コントロール」パネルおよび宣言的なバインディング機能の詳細は、第12章「Fusion WebアプリケーションでのADFモデルの使用」を参照してください。
JDeveloperでは、属性を個別にドロップする必要はなく、オブジェクトのすべての属性をフォームとして一度にドロップできます。フォームを構成する実際のUIコンポーネントは、ドロップしたフォームのタイプによって異なります。値を表示するフォーム、ユーザーが値を編集できるフォームおよび値を収集するフォーム(入力フォーム)を作成できます。
たとえば、図22-1に示すように、StoreFrontモジュールにはユーザー自身の情報を登録できるページがあります。このフォームは、「データ・コントロール」パネルからCustomerRegistrationコレクションをドラッグ・アンド・ドロップして作成されました。
UIコンポーネントをドロップすると、コレクション内のレコード間を移動できるようにしたり、ユーザーがデータを操作(レコードのコミット、削除、作成など)できるようにする組込み操作をコマンドUIコンポーネントとしてドロップできます。たとえば、フォームに表示されたデータ・オブジェクトをユーザーが削除できるようにするためのボタンを作成できます。また、必要に応じてデフォルトのコンポーネントを変更することもできます。
JDeveloperでは、テキスト・フィールドを宣言的に作成可能な、JSFページ用の完全なWYSIWYG開発環境が用意されているため、ページのほとんどの内容をコードを見ずに設計できます。「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップすると、属性バインディングを使用してADF FacesテキストUIコンポーネントはデータ・コントロールの属性に宣言的にバインドされます。
属性を表示または更新できるテキスト・フィールドを作成するには、「データ・コントロール」パネルからコレクションの属性をドラッグ・アンド・ドロップします。
バインドされたテキスト・フィールドを作成するには:
「データ・コントロール」パネルから、コレクションの属性を選択します。属性およびその他のオブジェクトを表す「データ・コントロール」パネルのアイコンの説明は、12.3項「「データ・コントロール」パネルの使用」を参照してください。
たとえば、図22-2は、StoreFrontモジュールのStoreServiceAMDataControlデータ・コントロールの、CustomerRegistrationコレクションの下にあるFirstName属性を示しています。この属性は、顧客の名を表示または入力する場合にドロップします。
ページに属性をドラッグし、ポップアップ・メニューから、属性値を表示または収集するウィジェットのタイプを選択します。各属性について、次の選択肢があります。
テキスト:
ラベル付ADF入力テキスト: ネストされたvalidatorコンポーネントを伴うADF Faces inputTextコンポーネントが作成されます。label属性が移入されます。
|
ヒント:
|
ADF入力テキスト: ネストされたvalidatorコンポーネントを伴うADF Faces inputTextコンポーネントが作成されます。label属性は移入されません。
ラベル付ADF出力テキスト: ADF Faces outputTextコンポーネントを保持するpanelLabelAndMessageコンポーネントを作成します。panelLabelAndMessageコンポーネントのlabel属性が移入されます。
ADF出力テキスト: ADF Faces outputTextコンポーネントを作成します。ラベルは作成されません。
ラベル付ADF出力フォーマット済: 「ラベル付ADF出力テキスト」と同様ですが、outputTextコンポーネントのかわりにoutputFormattedコンポーネントを使用します。outputFormattedコンポーネントでは、制限された分量のHTML書式設定を追加できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド 』の出力テキストおよびフォーマット済の出力テキストの表示に関する項を参照してください。
ADF出力フォーマット済: 「ラベル付ADF出力フォーマット済」と同様ですが、ラベルはありません。
ADFラベル: ADF Faces outputLabelコンポーネント。
値リスト: ADF LOVリストを作成します。これらのリストでの作業方法は、5.12項「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。これらのリストのJSFページでの使用方法は、25.3項「選択リストの作成」を参照してください。
単一選択: 単一選択リストを作成します。JSFページでのリストの作成に関する詳細は、25.3項「選択リストの作成」を参照してください。
|
注意: これらの選択は、デフォルトではユーザーが選択します。ただし、属性で使用可能なコンポーネントのリストは、関連するエンティティまたはビュー・オブジェクトのコントロール・ヒントとして構成できます。詳細は、4.6項「エンティティ・オブジェクトの属性のコントロール・ヒントの定義」および5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照してください。 |
この章の目的にあわせて、ここではテキスト・コンポーネントのみ(リストは除く)について説明します。
JSFページに属性をドラッグしてUIコンポーネントとしてドロップすると、そのページのページ定義ファイル(すでに存在する場合を除く)などが作成されます。属性をページにドラッグすると行われるすべての処理の説明は、12.3.2項「「データ・コントロール」パネルの使用時の処理」を参照してください。イテレータと属性のバインディングが作成され、ページ定義ファイルに追加されます。また、UIコンポーネントに必要なJSPXページ・コードがJSFページに追加されます。
「データ・コントロール」パネルからコレクションの一部である項目をドロップして(またはコレクション全体をフォームまたは表としてドロップして)ページ上にUIコンポーネントを作成するたびに、イテレータ・バインディングが自動的に作成されます(すでに存在する場合を除く)。イテレータ・バインディングは、データ・コレクションのイテレータを参照し、この機能によりそのデータ・オブジェクトを反復処理します。また、コレクション内のデータ・オブジェクトの現在行および状態を管理します。イテレータ・バインディングは実際にはデータにアクセスしません。かわりに、データにアクセスできるオブジェクトを単純に公開し、コレクション内の現在のデータ・オブジェクトを指定します。その後、現在のオブジェクトのデータを戻したり、オブジェクトのデータに対してアクションを実行するために、他のバインディングがこのイテレータ・バインディングを参照します。イテレータ・バインディングはイテレータではないことに注意してください。これはイテレータへのバインディングです。ADFビジネス・コンポーネントの場合、実際のイテレータは、アプリケーション・モジュールのデータ・モデル内のビュー・オブジェクト・インスタンスのデフォルト行セットに対するデフォルト行セット・イテレータです。
たとえば、CustomerRegistrationコレクションの下にFirstName属性をドロップした場合、
CustomerRegistration
|
ヒント: 各コレクションに対して1つのイテレータ・バインディングが作成されます。つまり、同じコレクションから2つの属性をドロップした場合(もしくは同じコレクションを2回ドロップした場合)は、同じバインディングが使用されます。コンポーネントごとに動作の異なるバインディングが必要な場合を除き、同じバインディングが使用されても問題はありません。その場合は、別個のイテレータ・バインディングを手動で作成する必要があります。 |
イテレータ・バインディングのrangeSize属性は、イテレータ・バインディングへのアクセスが行われるたびにデータ・コントロールからフェッチされるデータ行数を決定します。この属性により、行セット全体の中でいくつかの絶対開始位置に対して1-n行の相対セットが置かれます。デフォルトでは、属性は25に設定されています。この属性の使用に関する詳細は、22.4.2.2項「イテレータのRangeSize属性」を参照してください。 例22-1に、CustomerRegistrationコレクションから属性をドロップした場合に作成されるイテレータ・バインディングを示します。
例22-1 コレクションからドロップされた属性用のイテレータ・バインディングのページ定義コード
<executables>
<iterator Binds="CustomerRegistration" RangeSize="25"
DataControl="StoreServiceAMDataControl"
id="CustomerRegistrationIterator"/>
</executables>
イテレータ・バインディング要素の属性の詳細は、付録B「Oracle ADFバインディング・プロパティ」を参照してください。
このメタデータにより、ADFバインディング・コンテナは属性値にアクセスできます。実行可能ファイルであるイテレータ・バインディングは、デフォルトでページのロード時に起動されるため、これによってイテレータがCustomerRegistrationコレクションにアクセスし、反復処理を実行できます。これは、イテレータによって、コレクション内のすべてのCustomerRegistrationオブジェクトの管理(現在のCustomerRegistrationオブジェクトまたはCustomerRegistrationオブジェクト・レンジの判別など)が行われることを意味します。
「データ・コントロール」パネルから属性をドロップすると、UIコンポーネントを属性の値にバインドするための属性バインディングが作成されます。このタイプのバインディングは、コレクション内の現在行のシングル・オブジェクトに対する属性の値を提示します。値バインディングは、属性値の表示と収集の両方に使用できます。
たとえば、CustomerRegistrationコレクションの下にあるPrincipalName属性を「ラベル付ADF出力テキスト」ウィジェットとしてページにドロップすると、JDeveloperによって、PrincipalName属性の属性バインディングが作成されます。これにより、バインディングが現在のレコードの属性値にアクセスできるようになります。例22-2に、CustomerRegistrationコレクションから属性をドロップすると作成されるPrincipalNameに対する属性バインディングを示します。この属性値は、CustomerRegistrationIteratorという名前のイテレータを参照します。
例22-2 属性バインディングのページ定義コード
<bindings>
...
<attributeValues IterBinding="CustomerRegistrationIterator"
id="PrincipalName">
<AttrNames>
<Item Value="PrincipalName"/>
</AttrNames>
</attributeValues>
</bindings>
属性バインディング要素のプロパティの詳細は、付録B「Oracle ADFバインディング・プロパティ」を参照してください。
「データ・コントロール」パネルから属性をドロップしてテキスト・フィールドを作成すると、対応するタグがJSFページに記述され、ドロップしたウィジェットに関連付けられているUIコンポーネントが作成されます。
たとえば、PrincipalName属性を「ラベル付き出力テキスト」ウィジェットとしてドロップすると、JDeveloperによってpanelLabelAndMessageコンポーネントとoutputTextコンポーネントのタグが挿入されます。また、panelLabelAndMessageコンポーネントのlabel属性を、PrincipalNameのバインディングのために作成されたヒントのlabelプロパティにバインドするEL式が作成されます。この式は、ビュー・オブジェクトに設定されたラベル・ヒントを評価します(ヒントの詳細は、5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照)。また、現在の行のPrincipalName属性の値に評価される、outputTextコンポーネントのvalue属性をPrincipalNameバインディングのinputValueプロパティにバインドする、別の式が作成されます。両方のコンポーネントに対してIDも自動的に生成されます。
|
ヒント: JDeveloperでは、すべてのADF FacesコンポーネントのIDが自動的に生成されます。これらの値を必要に応じてオーバーライドできます。 |
例22-3に、PrincipalName属性を「ラベル付き出力テキスト」ウィジェットとしてドロップしたときにJSFページで生成されるコードを示します。
例22-3 「ラベル付き出力テキスト」としてドロップされた属性のJSFページ・コード
<af:panelLabelAndMessage label="#{bindings.PrincipalName.hints.label}" id="plam1">
<af:outputText value="#{bindings.PrincipalName.inputValue}" id="ot1"/>
</af:panelLabelAndMessage>
かわりにPrincipalName属性を「ラベル付き入力テキスト」ウィジェットとしてドロップすると、JDeveloperによってinputTextコンポーネントが作成されます。例22-4で示すように、出力テキスト・コンポーネントと同様に、値はPrincipalNameバインディングのinputValueプロパティにバインドされます。さらに、次のプロパティも設定されます。
label: オプジェクトに設定されたコントロール・ヒントのlabelプロパティにバインドされます。
required: コントロール・ヒントのmandatoryプロパティにバインドされます。
columns: コントロール・ヒントのdisplayWidthプロパティにバインドされます。このコントロール・ヒント・プロパティは、テキスト・ボックスの幅を決定します。
maximumLength: コントロール・ヒントのprecisionプロパティにバインドされます。このコントロール・ヒント・プロパティは、フィールドに入力できる1行当たりの最大文字数を決定します。
さらに、JDeveloperはバリデータ・コンポーネントを追加します。
例22-4 「ラベル付き入力テキスト」としてドロップされた属性のJSFページ・コード
<af:inputText value="#{bindings.PrincipalName.inputValue}"
label="#{bindings.PrincipalName.hints.label}"
required="#{bindings.PrincipalName.hints.mandatory}"
columns="#{bindings.PrincipalName.hints.displayWidth}"
maximumLength="#{bindings.PrincipalName.hints.precision}">
shortDesc="#{bindings.PrincipalName.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.PrincipalName.validator}"/>
</af:inputText>
これらの値は必要に応じて変更できます。たとえば、ビュー・オブジェクトのmandatoryコントロール・ヒントはデフォルトでfalseに設定されており、これは、コンポーネントの必須属性もfalseと評価されることを意味します。コンポーネントのrequired属性をtrueに設定すると、この値を上書きできます。属性のすべてのインスタンスを必須にする場合は、ビュー・オブジェクト内のコントロール・ヒントを変更して、すべてのインスタンスを必須にすることができます。これらのプロパティの詳細は、付録B「Oracle ADFバインディング・プロパティ」を参照してください。
コレクションの各属性を個別にドロップしてフォームを作成するかわりに、オブジェクトのすべての属性のデータを表示または収集する、完全なフォームをドロップできます。
たとえば、StoreFrontモジュールでは、CustomerInfoVO1コレクションをドラッグ・アンド・ドロップして登録済ユーザーの基本情報を表示するページを作成できます。
また、コレクションからデータを表示するだけでなく、多くの機能を提供するフォームの作成もできます。ユーザーがデータを更新できるフォームの作成に関する詳細は、22.5項「既存レコードを編集するフォームの作成」を参照してください。 ユーザーがコレクションの新規オブジェクトを作成できるフォームの作成に関する詳細は、22.6項「入力フォームの作成」を参照してください。また、検索フォームも作成できます。詳細は、第27章「ADFによるデータバインドされた検索フォームの作成」を参照してください。
データ・コントロールを使用してフォームを作成するには、UIコンポーネントをデータ・コントロールの対応するオブジェクトの属性にバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションまたは構造化属性をドラッグ・アンド・ドロップして、これを宣言的に処理できます。
基本的なフォームを作成するには:
「データ・コントロール」パネルから、表示するデータを表すコレクションを選択します。図22-3に、StoreServiceAMDataControlデータ・コントロールのCustomerInfoVO1コレクションを示します。
ページにコレクションをドラッグし、ポップアップ・メニューから、オブジェクトのデータの表示または収集に使用するフォームのタイプを選択します。各フォームについて、次の選択肢があります。
ADFフォーム: 「フォーム・フィールドの編集」ダイアログが起動し、デフォルトですべての属性に対して1つのフィールドが作成されるのではなく、属性を個別に選択できます。また、各属性に使用するラベルおよびUIコンポーネントを選択できます。デフォルトでは、ADF inputTextコンポーネントはほとんどの属性で使用されます。inputTextコンポーネントごとにlabel属性が移入されます。
日付である属性ではInputDateコンポーネントが使用されます。さらに、属性にコントロール・タイプのコントロール・ヒントが作成されている場合、または属性がリストとして構成されている場合、ヒントにより設定されたコンポーネントが使用されます。InputTextコンポーネントには、属性の検証を設定するためのバリデータ・タグが含まれます。属性が数値または日付の場合、コンバータも含まれます。
|
ヒント:
|
ADF読取り専用フォーム: 「ADFフォーム」と同じですが、読取り専用outputTextコンポーネントのみが使用されます。このフォームはデータの表示を目的としているため、validatorタグは追加されません(コンバータは含まれます)。タイプDateの属性は、読取り専用フォームではoutputTextコンポーネントを使用します。すべてのコンポーネントは、label属性を含むpanelLabelAndMessageコンポーネント内に配置され、panelFormLayoutコンポーネントに格納されます。
ADF検索フォーム: Query-by-Example (QBE)検索の実行に使用できるフォームを作成します。詳細は、第27章「ADFでデータバインドされた検索フォームの作成」を参照してください。
「フォーム・フィールドの編集」ダイアログで、フォームを構成します。
ユーザーがコレクション内の全データ・オブジェクト間を移動できるようにする、ナビゲーション・コントロールを含めることもできます。詳細は、22.4項「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。 また、フォームの送信に使用する「送信」ボタンを含めることもできます。このボタンはHTMLフォームを発行し、フォームのデータをJSF/ADFページ・ライフサイクルの一部としてバインディングに適用します。このダイアログの使用方法に関する追加のヘルプを表示するには、「ヘルプ」をクリックします。すべてのUIコンポーネントは、panelFormLayoutコンポーネントの中に配置されます。
ユーザーがデータを更新できるようにするためのフォームを作成する場合は、ここで、更新を実行する操作をドラッグ・アンド・ドロップする必要があります。詳細は、22.5項「既存レコードを編集するフォームの作成」を参照してください。
「データ・コントロール」パネルからオブジェクトをフォームとしてドロップすることは、単一の属性をドロップするのと同じ効果があります。ただし、複数の属性バインディングおよび関連するUIコンポーネントが作成される点が異なります。UIコンポーネントの属性(valueなど)は、その属性のバインディング・オブジェクト(inputValueなど)のプロパティ、または対応するビジネス・オブジェクトで設定されるコントロール・ヒントの値にバインドされます。例22-5に、CustomerInfoVO1コレクションをデフォルトADFフォームとしてドロップした場合にJSFページで生成されるコードの一部を示します。
|
注意: 関連するビューまたはエンティティ・オブジェクトで属性が非表示としてマークされている場合、対応するUIは作成されません。 |
例22-5 入力フォームのJSFページのコード
<af:panelFormLayout id="pfl1">
<af:inputText value="#{bindings.PersonId.inputValue}"
label="#{bindings.PersonId.hints.label}"
required="#{bindings.PersonId.hints.mandatory}"
columns="#{bindings.PersonId.hints.displayWidth}"
maximumLength="#{bindings.PersonId.hints.precision}"
shortDesc="#{bindings.PersonId.hints.tooltip}" id="it2">
<f:validator binding="#{bindings.PersonId.validator}"/>
</af:inputText>
<af:inputText value="#{bindings.FirstName.inputValue}"
label="#{bindings.FirstName.hints.label}"
required="#{bindings.FirstName.hints.mandatory}"
columns="#{bindings.FirstName.hints.displayWidth}"
maximumLength="#{bindings.FirstName.hints.precision}"
shortDesc="#{bindings.FirstName.hints.tooltip}"
id="it1">
<f:validator binding="#{bindings.FirstName.validator}"/>
</af:inputText>
<af:inputText value="#{bindings.LastName.inputValue}"
label="#{bindings.LastName.hints.label}"
required="#{bindings.LastName.hints.mandatory}"
columns="#{bindings.LastName.hints.displayWidth}"
maximumLength="#{bindings.LastName.hints.precision}"
shortDesc="#{bindings.LastName.hints.tooltip}" id="it7">
<f:validator binding="#{bindings.LastName.validator}"/>
</af:inputText>
. . .
</af:panelFormLayout>
|
注意: バリデータ・タグとコンバータ・タグの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「入力の検証および変換」を参照してください。 |
定義済の値リスト(LOV)を含むオブジェクトを使用して入力フォームを作成する場合、inputTextコンポーネントのかわりにselectOneChoiceコンポーネントが作成されます。たとえば、PersonsVOビュー・オブジェクトには、Title、Gender、MaritalStatusCodeおよびPersonTypeCode属性の定義済LOVが含まれます。Personsデータ・コントロール・オブジェクトをADFフォームとしてドロップすると、空の入力テキスト・フィールドのかわりに、すべての値を表示するドロップダウン・リストが作成されます。これらのリストでの作業方法は、5.12項「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。これらのリストのJSFページでの使用方法は、25.3項「選択リストの作成」を参照してください。
|
注意: オブジェクトに構造化属性(Javaのプリミティブ・タイプまたはコレクションのいずれでもない属性)が含まれる場合、その属性はダイアログには表示されず、また、フォームに対応するコンポーネントもありません。これらのフィールドは手動で作成する必要があります。 |
ADFフォームを作成する際、ナビゲーション・コントロールの組込みを選択すると、データ・コントロールの既存のナビゲーション・ロジックにバインドされているADF Facesコマンド・コンポーネントが組み込まれます。この組込みロジックによって、ユーザーは、コレクション内のすべてのデータ・オブジェクトを移動できるようになります。図22-4の例は、CustomerInfoVO1コレクションをドラッグし、ナビゲーションを使用するADFフォームとしてドロップした場合に作成されるフォームを示しています。
デフォルトでは、「データ・コントロール」パネルを使用してフォームを作成する際にナビゲーションの組込みを選択すると、「先頭へ」、「最後へ」、「前へ」および「次へ」の各ボタンが作成され、ユーザーがコレクション内を移動できるようになります。
また、既存のフォームにナビゲーション・ボタンを手動で追加できます。
ナビゲーション・ボタンを手動で追加するには:
操作の実行対象となるオブジェクトのコレクションに関連付けられている操作を「データ・コントロール」パネルから選択し、JSFページ上にドラッグします。
たとえば、個人のコレクション全体を移動できるようにする場合は、Personsコレクションに関連付けられている「次へ」操作をドラッグします。図22-5に、CustomerInfoVO1コレクションに関連付けられている操作を示します。
次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。
|
ヒント: 「先頭へ」、「最後へ」、「前へ」および「次へ」のすべてのボタンを一度にドロップすることもできます。一度にドロップするには、対応するコレクションをドラッグし、ポップアップ・メニューから「移動」→「ADFナビゲーション・ボタン」を選択します。 |
任意の操作をコマンド・コンポーネントとしてドロップすると、JDeveloperによって次の処理が行われます。
関連付けられている操作について、ページ定義ファイルでアクション・バインディングが定義されます。
コレクションに部分ページ・レンダリングを使用するように、イテレータ・バインディングが構成されます。
コマンド・コンポーネント用のコードがJSFページに挿入されます。
アクション・バインディングは、ビジネス・ロジックを実行します。たとえば、アクション・バインディング・オブジェクト上で組込みメソッドを起動できます。このような組込みメソッドは、イテレータやデータ・コントロール自体に対して作用し、「データ・コントロール」パネルに操作として表示されます。ユーザーは、JDeveloperによって提供されるナビゲーション操作を使用して、コレクション内の前後のオブジェクトに移動したり、最後または最初のオブジェクトに移動できます。
アクション・バインディングがNextまたはPreviousなどのイテレータレベル・アクションにバインドされている場合、操作のアクション・バインディングには、値バインディングと同様にイテレータ・バインディングへの参照が含まれます。これらのタイプのアクションはイテレータによって実行されますが、イテレータが現在のオブジェクトを判別することで、ナビゲーション・ボタンのクリック時に表示されるオブジェクトが正しく判別されます。イテレータ・レベルのアクション以外へのアクション・バインディング(たとえば、アプリケーション・モジュールのカスタム・メソッド、またはコミット操作やロールバック操作の場合)には、この参照は含まれません。
アクション・バインディングはRequiresUpdateModelプロパティを使用して、アクションを実行する前にモデルを更新する必要があるかどうかを判別します。ナビゲーション操作の場合、デフォルトではこのプロパティはtrueに設定されています。つまり、ビュー・レイヤーでのすべての変更は、ナビゲーションを実行する前にモデルに移動する必要があります。例22-6に、ナビゲーション操作のアクション・バインディングを示します。
例22-6 操作アクション・バインディングのページ定義コード
<action IterBinding="CustomerInfoVO1Iterator" id="First"
RequiresUpdateModel="true" Action="first"/>
<action IterBinding="CustomerInfoVO1Iterator" id="Previous"
RequiresUpdateModel="true" Action="previous"/>
<action IterBinding="CustomerInfoVO1Iterator" id="Next"
RequiresUpdateModel="true" Action="next"/>
<action IterBinding="CustomerInfoVO1Iterator" id="Last"
RequiresUpdateModel="true" Action="last"/>
イテレータ・バインディングにはrangeSize属性が含まれ、バインディングではこの属性を使用して、反復ごとにページで使用できるようにするデータ・オブジェクト数が決定されます。この属性は、データソース内のオブジェクト数がきわめて多い場合に役立ちます。イテレータ・バインディングは、すべてのオブジェクトではなく、1つのセット番号のみを戻すため、他のバインディングでアクセスできるようになります。イテレータはレンジの最後に到達すると、次のセットにアクセスします。例22-7に、CustomerInfoVOイテレータのデフォルトのレンジ・サイズを示します。
例22-7 イテレータのRangeSize属性
<iterator Binds="CustomerInfoVO" RangeSize="25"
DataControl="StoreServiceAMDataControl"
id="CustomerInfoVO1Iterator"
ChangeEventPolicy="ppr"/>
デフォルトでは、rangeSize属性は25に設定されています。つまり、ユーザーは、データソースにアクセスせずに、前後に移動しながら25個のオブジェクトを表示できます。イテレータは、現在のオブジェクトを追跡します。ユーザーが新しいレンジが要求されるボタンをクリックすると(たとえば、オブジェクト番号25で「次へ」ボタンをクリックすると)、バインディング・オブジェクトによってイテレータに対して関連するメソッドが実行され、イテレータによって別の25個のレコードのセットが取得されます。その後、取得されたセットがバインディングによって使用されます。この設定は、必要に応じて変更できます。完全なレコード・セットを戻すには、-1に設定します。
|
注意: 「データ・コントロール」パネルを使用してナビゲーション可能なフォームを作成する場合、関連するイテレータの |
表22-1に、データ・コントロールで提供される組込みナビゲーション操作と、操作の起動または操作にバインドされたイベントの実行の結果を示します。アクション・イベントの詳細は、22.4.4項「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。
表22-1 組込みナビゲーション操作
| 操作 | 関連イテレータ・バインディングによる起動時の処理 |
|---|---|
|
最初へ |
現在のポインタを結果セットの最初に移動します。 |
|
最後へ |
現在のポインタを結果セットの最後に移動します。 |
|
前 |
現在のポインタを結果セットの前のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが戻るようにスクロールされます。 |
|
次 |
現在のポインタを結果セットの次のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが進むようにスクロールされます。 |
|
Previous Set |
レンジ・サイズ属性と同じオブジェクト数だけ、レンジを戻すように移動します。 |
|
Next Set |
レンジ・サイズ属性と同じオブジェクト数だけ、レンジを進めるように移動します。 |
ナビゲーション操作を使用してコマンド・コンポーネントを作成すると、コマンド・コンポーネントはpanelGroupLayoutコンポーネント内に配置されます。JDeveloperにより、ナビゲーション・コマンド・ボタンのactionListener属性を、指定された操作のアクション・バインディングのexecuteプロパティにバインドするEL式が作成されます。
実行時、アクション・バインディングは、コアのJUCtrlActionBinding実装クラスを拡張するFacesCtrlActionBindingクラスのインスタンスです。FacesCtrlActionBindingクラスにより、次のメソッドが追加されます。
public void execute(ActionEvent event): actionListenerプロパティで参照されるメソッドです(例: #{bindings.First.execute})。
ユーザーがボタンをクリックすると、この式によって、イテレータに対してバインディングの操作が起動されます。たとえば、Firstコマンド・ボタンのactionListener属性は、Firstアクション・バインディングのexecuteメソッドにバインドされます。
public String outcome(): Actionプロパティで参照できます(例: #{bindings.Next.outcome})。
移動先となる次のページを決定するJSFナビゲーションの結果として、メソッド・アクション・バインディングの結果(Stringに変換後)に使用できます。
|
注意: アクション・バインディングでoutcomeメソッドを使用すると、ビューおよびコントローラのレイヤーとモデルが過度に緊密に結ばれるため、ほとんど使用されません。 |
操作の各アクション・バインディングには、enabledブール型プロパティが含まれます。このプロパティは、操作を起動しない場合には、Oracle ADFによってfalseに設定されます。デフォルトでは、JDeveloperがこの値にUIコンポーネントのdisabled属性をバインドして、コンポーネントを有効化するかどうかを指定します。たとえば、「先頭へ」ボタンのUIコンポーネントのdisabled属性の値は、次のとおりです。
#{!bindings.First.enabled}
この式は、バインディングが有効でない場合、つまり操作を起動しない場合は常にtrueに評価され、ボタンが無効になります。この例では、最初のレコードが表示されている場合はいつでも、フレームワークがバインディングのenabledプロパティをfalseに設定するため、「先頭へ」ボタンが自動的に無効になります。これは、enabledがFalseの場合は、常にdisabled属性がtrueに設定されるためです。enabledプロパティの詳細は、付録B「Oracle ADFバインディング・プロパティ」を参照してください。
例22-8に、ナビゲーション操作ボタンに対してJSFページで生成されたコードを示します。ボタンのpartialSubmit属性の詳細は、22.4.3項「自動部分ページ・レンダリングについて」を参照してください。
例22-8 ADF操作にバインドされているナビゲーション・ボタンのJSFコード
<f:facet name="footer">
<af:panelGroupLayout>
<af:commandButton actionListener="#{bindings.First.execute}"
text="First"
disabled="#{!bindings.First.enabled}"
partialSubmit="true" id="cb1"/>
<af:commandButton actionListener="#{bindings.Previous.execute}"
text="Previous"
disabled="#{!bindings.Previous.enabled}"
partialSubmit="true" id="cb2"/>
<af:commandButton actionListener="#{bindings.Next.execute}"
text="Next"
disabled="#{!bindings.Next.enabled}"
partialSubmit="true" id="cb3"/>
<af:commandButton actionListener="#{bindings.Last.execute}"
text="Last"
disabled="#{!bindings.Last.enabled}"
partialSubmit="true" id="cb4"/>
</af:panelGroupLayoutr>
</f:facet>
ナビゲーション・コントロールを使用してフォームを作成すると、部分ページ・レンダリング(PPR)を自動的に使用するようにイテレータ・バインディングが構成されます。PPRを使用すると、ページ全体をリフレッシュせずにページ上の特定のコンポーネントのみをレンダリングできます。たとえば、コマンド・リンクまたはボタンにより、ページ全体をリフレッシュせずにページ上の別のコンポーネントがレンダリングされるようにできます。PPRを使用するようにコンポーネントを構成するには、あるコンポーネントを別のコンポーネントのイベント(値変更イベントやアクション・イベントなど)のターゲットとして設定します。部分ページ・レンダリングの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「部分ページ・コンテンツのレンダリング」を参照してください。
フォームの作成時に、フォーム内のすべてのコンポーネントに対して機能するようにPPRを設定すると、時間の浪費やエラーが発生する可能性があります。これを軽減するために、値バインディングでchangeEventPolicy属性をpprに設定できます。この設定により、バックエンド・ビジネス・ロジックの結果として関連付けられたコンポーネントの値が変化するたびに、コンポーネントは自動的にレンダリングされます。また、イテレータ・バインディングのchangeEventPolicyをpprに設定することもできます。このように設定すると、イテレータに関連付けられたアクション・バインディングまたは値バインディングはすべて、changeEventPolicyがPPRに設定されているかのように機能します。これにより、各コンポーネントを個別に構成しなくても、フォーム全体でPPRを使用できるようになります。
フォームをドロップしてナビゲーション・コントロールの組込みを選択すると、関連付けられたイテレータのchangeEventPolicy属性がpprに自動的に設定されます。また、各ナビゲーション・ボタンのpartialSubmit属性がtrueに設定されます。これは、コマンド・コンポーネントがフレームワークにPPRが発生することを通知する方法を示します。ナビゲーション・コマンド・コンポーネントのpartialSubmit属性をtrueに設定し、イテレータのchangeEventPolicyをpprに設定すると、ナビゲーション・ボタンがクリックされるたびに、フォーム内のイテレータ・バインディングを使用するコンポーネントはすべてレンダリングされます。例22-9に、「データ・コントロール」パネルからCustomerInfoVOコレクションをナビゲーション付きのフォームとしてドロップすると作成されるイテレータのページ定義コードを示します。
アクション・イベントは、コマンド・コンポーネントがアクティブになっているときに発生します。たとえば、ユーザーが「発行」ボタンをクリックすると、フォームが送信され、続いてアクション・イベントが起動します。アクション・イベントは、ユーザー・インタフェースのみに影響する場合(たとえば、異なるフィールド・プロンプトを表示させる、ロケールを変更するためのリンク)と、なんらかのロジック処理を伴う場合(たとえば、次のレコードに移動するためのボタン)があります。
アクション・リスナーは、コマンド・コンポーネントによってアクション・イベントが起動されたときに通知を受けるクラスです。アクション・リスナーには、コマンド・コンポーネントによって渡されるアクション・イベント・オブジェクトを処理する、アクション・リスナー・メソッドが含まれます。
ナビゲーション操作の場合、ユーザーがたとえば「次へ」ボタンをクリックすると、アクション・イベントが起動します。このイベント・オブジェクトは、イテレータから取得した現在のデータ・オブジェクトの現在行位置情報を格納します。コンポーネントのactionListener属性がNextアクション・バインディングのexecuteメソッドにバインドされているため、イベントが起動されるとNext操作が起動します。このメソッドは、イベント・オブジェクトで渡された現在行位置情報を使用して、次のデータ・オブジェクトを判別します。
また、ユーザーがナビゲーション・ボタンをクリックすると、ボタンのアクション・バインディングと同じイテレータに関連付けられたコンポーネントのみがライフサイクルを通して処理されます。これは、ナビゲーション・コマンド・ボタンのpartialSubmit属性がtrueに設定され、関連付けられたイテレータがPPRを使用するように構成されているためです。
フォームに表示されるレコード間でのナビゲートには、ナビゲーション・ボタンを使用する必要があり、ブラウザの「戻る」または「進む」ボタンは使用できません。ナビゲーション・フォームでは自動的にPPRが使用されるため、ライフサイクルを通過するのはページの一部のみです(つまり、ユーザーがナビゲーション・ボタンをクリックすると、データを表示するコンポーネントがリフレッシュされて新しいデータが表示されますが、ユーザーは実際には同じページにとどまっています)。したがって、ブラウザの「戻る」ボタンをクリックすると、そのフォームに表示された前のレコードではなく、そのフォームを使用したページの前にレンダリングされたページに戻ります。
たとえば、現在の注文をすべて表示するためのリンクを含むページが表示されているとします。このリンクをクリックすると、フォームを使用したページに移動し、最初の注文であるOrder #101が表示されます。次に「次へ」をクリックすると、Order #102が表示されます。再び「次へ」をクリックすると、Order #103が表示されます。ブラウザの「戻る」ボタンをクリックした場合、Order #102は表示されません。かわりに、現在のすべての注文を表示するためのリンクを含むページに戻ります。
ユーザーが現在のデータを編集し、その変更をデータソースにコミットするためのフォームを作成できます。フォームを作成するには、コレクションまたはデータ・コントロール自身に関連付けられたデータ・レコードを変更するための操作を使用して、コマンド・ボタンを作成します。たとえば、Delete操作を使用して、ユーザーが現在のレンジからレコードを削除できるボタンを作成できます。または、組込みの「発行」ボタンを使用して、変更を送信できます。
|
ヒント: フォーム上で ADF組込み操作の1つを使用するかわりに、カスタム・メソッドを使用してフォーム内のデータを操作する場合は、28.2項「メソッドを実行するためのコマンド・コンポーネントの作成」を参照してください。 |
重要なのは、これらの操作がADFキャッシュのオブジェクトに対してのみ実行されるという点です。ルート・データ・コントロール上でCommit操作を使用して、任意の変更をデータソースに実際にコミットする必要があります。データ・コントロールのRollback操作を使用して、キャッシュされたオブジェクトに対する任意の変更をロールバックします。ページが、バインド・タスク・フロー内のトランザクションの一部である場合、通常、タスク・フロー・リターン・アクティビティのトランザクションを解決するためにこの操作を使用します。詳細は、18.4項「トランザクションの管理」を参照してください。
フォームで操作を使用するには、ナビゲーション操作と同じ手順を実行します。
編集フォームの作成方法:
「データ・コントロール」パネルから、フォームを作成するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。
これにより、inputTextコンポーネントを使用し、フィールドのデータを編集可能なフォームが作成されます。
「フォーム・フィールドの編集」ダイアログで、「送信ボタンを含める」を選択し、「OK」をクリックします。
含める操作のために新しいボタンを作成するか、別の操作を起動する「発行」ボタンを再バインドすることができます。「発行」ボタンをそのまま保持し、操作のために新しいボタンを作成するには、この手順を続行します。「発行」ボタンを再バインドする方法は、手順5を参照してください。
操作の実行対象となるオブジェクトのコレクションに関連付けられている操作を「データ・コントロール」パネルから選択し、JSFページ上にドラッグします。単にデータの編集を可能にする場合、必要なのは「発行」ボタンのみです。
たとえば、顧客レコードを削除できるようにする場合は、CustomerInfoVO1コレクションに関連付けられているDelete操作をドラッグします。図22-6に、コレクションに関連付けられている操作を示します。
次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。
「発行」ボタンを再バインドするには、構造ウィンドウでボタンを右クリックし、「ADFコントロールにバインド」を選択します。「ADFコントロールにバインド」ダイアログで、ボタンをバインドする操作を選択します。選択した操作が、フォームの基になるコレクションと関連していることを確認してください。
たとえば、顧客レコードを削除できるようにする場合は、CustomerInfoVO1コレクションに関連付けられているDelete操作を選択します。図22-6に、コレクションに関連付けられている操作を示します。
ページが、バインド・タスク・フロー内のトランザクションの一部でない場合、ユーザーが変更をコミットまたはロールバックできるようにするためのボタンを作成する必要があります。「データ・コントロール」パネルから、ルートレベル・データ・コントロールに関連付けられたCommit操作とRollback操作をドラッグし、コマンド・ボタンまたはコマンド・リンクのいずれかとしてドロップします。図22-7に、StoreServiceAMDataControlデータ・コントロールのCommit操作およびRollback操作を示します(この図では、わかりやすくするために、各ビュー・オブジェクトに表示されるツリー内の詳細は省略されています)。
ページが、バインド・タスク・フロー内のトランザクションの一部である場合、タスク・フロー・リターン・アクティビティを作成する際のトランザクションを解決する値としてCommitまたはRollbackを入力します。詳細は、18.4項「トランザクションの管理」を参照してください。
コマンド・ボタンとして任意のデータ・コントロール操作をドロップすると、ナビゲーション操作のドロップと同じイベントが発生します。詳細は、22.4.2項「コマンド・ボタンの作成時の処理」を参照してください。
イテレータとは異なり、Commit操作とRollback操作はアプリケーション・モジュール(データ・コントロール自身)でメソッドを実行するため、これらの操作のアクション・バインディングがイテレータへの参照を必要としないことが、唯一の相違点です。RollbackアクションのRequiresUpdateModelプロパティはfalseに設定されています。これは、すべての変更は破棄する必要があるので、操作の実行前にモデルは更新されないためです。例22-10に、これらの操作に対するページ定義ファイルに生成されたアクション・バインディングを示します。
例22-10 Commit操作とRollback操作のアクション・バインディング
<action id="Commit" RequiresUpdateModel="true" Action="commitTransaction"
DataControl="StoreServiceAMDataControl"/>
<action id="Rollback" RequiresUpdateModel="false"
Action="rollbackTransaction"
DataControl="StoreServiceAMDataControl"/>
表22-2に、データ・コントロールおよびデータ・コントロール・オブジェクトで提供されるナビゲーション以外の組込み操作と、操作の起動または操作にバインドされたイベントの実行の結果を示します。アクション・イベントの詳細は、22.4.4項「実行時に行われる処理: アクション・イベントおよびアクション・リスナーの動作方法」を参照してください。
表22-2 追加の組込み操作
| 操作 | 関連イテレータ・バインディングによる起動時の処理 |
|---|---|
|
|
現在の行の直前に行を作成し、行セットに新しいレコードを挿入して、現在行ポインタを新しい行に移動します。レンジは移動しないため、レンジの最後の行が結果的にレンジから除外される可能性があります。 |
|
|
現在の行の直前に行を作成し、現在行ポインタを新しい行に移動します。レンジは移動しないため、レンジの最後の行が結果的にレンジから除外される可能性があります。また、ユーザーが実際にデータを作成することなく移動した場合の空白行を避けるため、行セットにレコードは挿入されません。新しい行は、ユーザーがデータを送信すると作成されます。詳細は、23.4.5項「CreateおよびCreateInsertについて」を参照してください。 |
|
|
|
|
|
|
|
|
現在の行をキャッシュから削除し、現在行ポインタを結果セットの次の行に移動します。レンジは移動しないため、レンジの最後に行が追加される可能性があります。最後の行が削除された場合、現在行ポインタはその前の行に移動します。コレクション内の行がなくなると、有効な属性が |
|
|
入力フィールドによって指定された値から変換された |
|
|
行キーを、入力フィールドで指定された値から変換された |
|
|
キーの値を使用して、イテレータの現在のオブジェクトを設定します。詳細は、23.2.3項「表での現在行の設定について」を参照してください。 |
|
|
パラメータとして渡された名前付きのバインド変数に新しい値を割り当てた後で、ビュー・オブジェクトの問合せを(再)実行することにより、データ・コレクションをリフレッシュします。この操作は、 この操作は、設計時に1つ以上の名前付きバインド変数が定義されているビュー・オブジェクトの場合のみ表示されます。詳細は、5.10項「バインド変数の使用」を参照してください。バインド変数および |
|
|
現在キャッシュ内にあるすべての項目をデータベースにコミットします。 |
|
|
キャッシュをクリアして、トランザクションおよびイテレータを初期状態に戻します。 |
|
|
これらの操作は、検索フォームでのみ使用されます。詳細は、第27章「ADFによるデータバインドされた検索フォームの作成」を参照してください。 |
ユーザーが新規レコードの情報を入力し、そのレコードをデータソースにコミットするためのフォームを作成できます。入力フォームを含むページが表示される前にCreateInsert操作をコールするメソッド・アクティビティを含むタスク・フローを使用する必要があります。このメソッド・アクティビティによって空白行が行セットに挿入されます。その後、ユーザーはフォームを使用して空白行にデータを移入できます。
たとえば、StoreFrontモジュールのcustomer-registration-task-flowタスク・フローにはcreateAddressメソッド・アクティビティがあり、CustomerAddressビュー・オブジェクトでCreateInsert操作をコールします。その後、制御がaddressDetailsビュー・アクティビティに渡され、図22-8に示すような、ユーザーが新しい住所を入力できるフォームが表示されます。
|
注意: アプリケーションでタスク・フローを使用しない場合は、タスク・フローのメソッド・アクティビティと同様の方法で、コール元のページで |
入力フォームを作成する前に、フォームとCreateInsert操作を実行するメソッド・アクティビティの両方を含むバインド・タスク・フローを作成する必要があります。
入力フォームを作成するには:
バインド・タスク・フローにメソッド・アクティビティを追加します。このアクティビティに、フォームを作成するコレクションに関連付けられているCreateInsert操作を実行させます。メソッド・アクティビティの使用手順は、15.5項「メソッド・コール・アクティビティの使用」を参照してください。
プロパティ・インスペクタで、fixed-outcomeプロパティに文字列を入力します。たとえば、customer-registration-task-flowタスク・フローのcreateAddressメソッド・アクティビティには、fixed-outcome値としてeditAddressが指定されています。
入力フォームのページを表すビュー・アクティビティを追加します。ビュー・アクティビティの追加の詳細は、15.2項「ビュー・アクティビティの使用」を参照してください。
制御フロー・ケースをメソッド・アクティビティからビュー・アクティビティに追加します。プロパティ・インスペクタで、手順2で設定したメソッド・アクティビティのfixed-outcomeプロパティの値を、制御フロー・ケースのfrom-outcomeの値として入力します。
設計エディタでビュー・アクティビティのページを開き、「データ・コントロール」パネルから、新しいレコードの作成にフォームを使用するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。
|
ヒント: データベースにコミットする前に、ユーザーが複数のエントリを作成できるようにする場合、次のようにします。
|
新しいデータをコミットする必要があるため、アプリケーションでデータ・コントロールのcommit操作を実行する必要があります。そのために、commit操作をコールするリターン・アクティビティに移動するボタンを追加できます。リターン・アクティビティの使用手順は、15.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。
|
ベスト・プラクティス: 複数のデータ・コントロールで管理されるデータがタスク・フローに含まれる場合、およびフローの終了前にデータをコミットする必要がある場合を除いて、リターン・アクティビティを使用します。これらの場合には、コミット・ボタンにバインドされているページにボタンを追加できます。 ページにコミット・ボタンを追加する必要がある場合は、次のようにします。
|
ADFフォームを使用して入力フォームを作成すると、JDeveloperによって次の処理が行われます。
メソッド・アクティビティのページ定義でコレクションのイテレータ・バインディングおよびCreateInsert操作のアクション・バインディングが作成されます。CreateInsert操作は、行を行セットに作成し、データソースに入力されたデータを移入します。その他のフォームに関しては、ページのページ定義で、コレクションのイテレータ・バインディングと、コレクション内のオブジェクトの各属性について属性バインディングが作成されます。Commit操作およびRollback操作を使用してコマンド・ボタンまたはリンクを作成した場合、JDeveloperではこれらの操作のアクション・バインディングも作成されます。
ADF Faces inputTextコンポーネント、および操作の場合はcommandButtonコンポーネントを使用して、JSFページにフォームのコードが挿入されます。
たとえば、StoreFrontモジュールには、顧客の住所をすべて表に表示するページがあります。表には、新しい住所のデータを入力できるフォームに移動する「追加」ボタンがあります。住所が作成されると、表があるページに戻り、新しい住所が表示されます。図22-9に、createAddressメソッド・アクティビティが指定されたcustomer-registration-task-flowタスク・フローを示します。
例22-11に、メソッド・アクティビティのページ定義ファイルを示します。
例22-11 Creationメソッド・アクティビティのページ定義コード
<executables>
<iterator id="CustomerAddressIterator" RangeSize="25"
Binds="CustomerAddress" DataControl="StoreServiceAMDataControl"/>
</executables>
<bindings>
<action id="CreateInsert" IterBinding="CustomerAddressIterator"
InstanceName="StoreServiceAMDataControl.CustomerAddress"
DataControl="StoreServiceAMDataControl" RequiresUpdateModel="true"
Action="createInsertRow"/>
</bindings>
createMethodCallアクティビティにアクセスすると、CreateInsertアクション・バインディングが起動され、CreateInsertRow操作が実行されてコレクション用に空白の新規インスタンスが作成されます。メソッド・アクティビティからビュー・アクティビティへのルーティング中、メソッド・アクティビティのバインディング・コンテナは必須属性の検証をスキップするため、空白のインスタンスがページ上のフォームに表示できます。
ページが表示される前にCreateアクションが実行されるため、順序を使用して主キーを移入する場合は、空である他のフィールドとは異なり、次の順序番号が入力テキスト・フィールドに表示されます。順序番号が表示されるのは、関連するエンティティ・クラスに、Eagerフェッチを使用して主キー属性の番号の順序を生成するメソッドが含まれるためです。Eagerフェッチにより、行が作成される際に値が移入されます。そのため、順序を使用すると想定どおりに入力フォームが動作します。
ただし、かわりに属性のタイプをDBSequence(データベース・トリガーを使用して順序を生成する)に構成した場合、オブジェクトがデータベースにコミットされるまで番号は移入されません。この場合は、プレースホルダとして負の数が表示されます。この状態を回避するには、入力テキスト・フィールドのRendered属性に次のEL式を使用できます。
#{bindings.EmployeeId.inputValue.value > 0}
この式では、値がゼロより大きい場合のみコンポーネントが表示されますが、これはコミット前には発生しません。同様に、Rendered属性を単純にfalseに設定することもできます。ただし、その場合は主キーの入力テキスト・フィールドのコンポーネントがページに表示されることはありません。
ADF Facesで提供されている動的コンポーネントのライブラリには、「データ・コントロール」パネルからドロップできる動的フォームと動的表ウィジェットが格納されています。動的コンポーネントは、すべてのバインディング・メタデータが実行時に作成される点が標準コンポーネントと異なります。バインディングのこの動的作成により、コントロールをページにドロップする際に「フォーム・フィールドの編集」ダイアログで情報を構成するのではなく、ビュー・オブジェクトのコントロール・ヒントを使用して表示情報を設定できます。その結果、データの表示方法を変更する場合に、ビュー・オブジェクトで表示方法を変更するだけで、そのビュー・オブジェクトにバインドされているすべての動的コンポーネントの表示はそれに従って変更されます。標準コンポーネントでは、表示属性(順序、属性のグループ化など)を変更する場合、データが表示されるページごとに変更する必要があります。
たとえば、StoreFrontモジュールでは、FirstName属性とLastName属性をフォームの上部(または表の左端の列)にグループ化し、ConfirmedEmailとMobilePhoneNumberをフォームの下部(または表の右端の列)にグループ化し、MembershipIDとMembershipTypeをフォームまたは表の中央にグループ化するCustomerInfoVOビュー・オブジェクトに対して、「カテゴリ」および「フィールド順」属性ヒントを設定できます。PersonIdをまったく表示しないようにすることもできます。ビュー・オブジェクトにコントロール・ヒントを設定する方法の詳細は、5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照してください。
図22-10に、前述のようにコントロール・ヒントが設定されたCustomerInfoVOビュー・オブジェクトを動的フォームとしてドラッグ・アンド・ドロップして、実行時に作成される動的フォームを示します。入力フィールドは、ビュー・オブジェクトが更新可能ではないためグレー表示されています。
動的フォームを使用するには、まず対応するすべてのビュー・オブジェクトにコントロール・ヒントを設定する必要があります(特に順序ヒントとグループ化ヒント)。次に、動的コンポーネントのライブラリをインポートします。その後、動的フォームまたは動的表ウィジェットをページにドロップできます。
動的コンポーネントを使用するには:
対応するビュー・オブジェクトにUIヒントを設定します。「カテゴリ」ヒントの場合、属性のグループ化に使用できる文字列を入力します。たとえば、CustomerInfoVOヒントでは、FirstName属性とLastName属性のいずれも「カテゴリ」UIヒントの値としてnameが指定されています。「フィールド順」ヒントは、カテゴリ内に表示される属性の順序を決定します。たとえば、CustomerInfoVOヒントでは、FirstName属性の「フィールド順」値は1、LastName属性の「フィールド順」値は2です。
UIヒントの作成手順は、5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照してください。
まだ組み込まれていない場合は、動的コンポーネント・ライブラリをインポートします。
アプリケーション・ナビゲータで、動的コンポーネントが使用されるビュー・プロジェクトを右クリックし、ポップアップ・メニューから「プロジェクト・プロパティ」を選択します。
ツリーで「JSPタグ・ライブラリ」を選択します。
「JSPタグ・ライブラリ」ページで「追加」をクリックします。
「タグ・ライブラリの選択」ダイアログで、ADF動的コンポーネントを選択し、「OK」をクリックします。
「JSPタグ・ライブラリ」ページで「OK」をクリックします。
「データ・コントロール」パネルから、ビュー・オブジェクトを表すコレクションを選択します。
コレクションをページにドラッグし、ポップアップ・メニューから「フォーム」→「ADF動的フォーム」を選択します。
プロパティ・インスペクタで「カテゴリ」フィールドに次のように入力します。
「カテゴリ」: フォームに表示する最初のグループに対する「カテゴリ」UIヒントの値として使用される文字列を入力します。たとえば、図22-10では、「カテゴリ」値はnameです。
編集可能: データを編集可能にする(デフォルト)場合、trueと入力します。データを読取り専用にする場合、falseと入力します。
フォームに表示するグループごとに、手順7および8を繰り返します。たとえば、図22-10のフォームは、実際にはカテゴリname用、カテゴリmembership用、カテゴリcontact用の3つの異なるフォームで構成されています。
動的フォームをドロップすると、イテレータへのバインディングのみが作成されます。例22-12に、CustomerInfoVOコレクションをドロップすると作成される1つの動的フォーム・コンポーネントを含むページのページ定義を示します。属性バインディングは作成されません。
例22-12 動的フォームのページ定義コード
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.53.2" id="DynamicFormPageDef"
Package="package.pageDefs">
<parameters/>
<executables>
<iterator Binds="CustomerInfoVO1" RangeSize="25"
DataControl="StoreServiceAMDataControl"
id="CustomerInfoVO1Iterator"/>
</executables>
<bindings/>
</pageDefinition>
ドロップしたフォームごとに、動的フォーム・タグを含むformタグが自動的に挿入されます。例22-13に示すように、formタグの値はイテレータ・バインディングにバインドされます。このバインディングにより、フォーム全体がイテレータから戻されたデータにバインドされます。各属性の表示プロパティは個別に設定できません。また、JSFページで属性を直接並び替えることもできません。
例22-13 動的フォームのJSFページ・コード
<af:document>
<af:messages/>
<af:form>
<dynamic:form value="#{bindings.CustomerInfoVO1Iterator}"
category="name"/>
<dynamic:form value="#{bindings.CustomerInfoVO1Iterator}"
category="member"/>
<dynamic:form value="#{bindings.CustomerInfoVO1Iterator}"
category="contact"/> </af:form>
</af:document>
|
ヒント: フォームの機能に影響する特定のプロパティを設定できます。たとえば、フォームのアップロード、レンダリングされたプロパティの設定、部分トリガーの設定などを可能にします。これらを実行するには、構造ウィンドウの |
動的コンポーネントを含むページがレンダリングされると、設計時に「データ・コントロール」パネルから項目をドロップしたときと同様に、バインディングが作成されます。ただし、バインディングは実行時に作成されます。詳細は、22.3.2項「フォームの作成時の処理」を参照してください。
|
ヒント: バインディングは実行時に作成される必要があるため、多少のパフォーマンス・ヒットがありますが、ビュー・オブジェクトの構造が変更されてもJSFページを再生成および再コンパイルする必要がないため、パフォーマンス・ゲインもあります。 |
デフォルトでは、動的フォームを作成すると必要なコンバータがすべて動的に作成され、コンバータのパターン文字列はビュー・オブジェクトの属性定義に関するフォーマット・ヒントに設定されます。
特定のJava型の属性に対するコンバータに対して別のフォーマット文字列を使用する場合は、カスタム・コンバータを作成し、その型の属性で使用されるfaces-config.xmlファイルに登録します。例22-14に、java.sql.Date属性用のコンバータに対するfaces-config.xmlエントリを示します。
例22-14 カスタム・コンバータに対するfaces-config.xml
<converter> <display-name>Date Time Converter</display-name> <converter-for-class>java.sql.Date</converter-for-class> <converter-class>sample.apps.view.DateTimeConverter</converter-class> </converter>
作成するカスタム・コンバータはADF FacesまたはTrinidadコンバータ・クラス(org.apache.myfaces.trinidadinternal.convert.DateTimeConverter)などを拡張し、getPattern()メソッドを実装する必要があります。カスタム・コンバータの作成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のカスタムJSFコンバータの作成に関する項を参照してください。
動的フォームは、faces-config.xmlエントリに指定されているJava型に基づいてコンバータを検索します。ビュー・オブジェクト内の属性定義にフォーマット・ヒントが指定されている場合、そのヒントがコンバータに対するパターンとして使用されます。ヒントが指定されていない場合は、パターンは変更されず、コンバータのgetPattern()メソッドの戻りからのデフォルト・パターンが使用されます。
「データ・コントロール」パネルを使用してフォーム(動的フォームを除く)を作成すると、属性の削除、表示順序の変更、データの表示に使用するコンポーネントの変更、およびコンポーネントのバインド先の属性の変更を実行できます。
|
注意: 次の手順では、動的フォームの表示方法は変更できません。表示情報は、ビュー・オブジェクトまたはエンティティ・オブジェクトで変更する必要があります。 |
「データ・コントロール」パネルからドロップしたデフォルト・コンポーネントについて、一部の内容を変更できます。構造ウィンドウを使用して、コンポーネントの表示順序の変更、新規コンポーネントの追加や既存のコンポーネントの変更、またはコンポーネントの削除を行えます。プロパティ・インスペクタを使用すると、バインディングの変更や削除、またはコンポーネントに対して表示されるラベルの変更を行えます。
デフォルト・コンポーネントおよびバインディングを変更するには:
構造ウィンドウを使用して、次の処理を行います。
UIコンポーネントをツリー内で上下にドラッグして、順序を変更します。黒線の矢印は、UIコンポーネントの配置先を示します。
UIコンポーネントの追加。構造ウィンドウで既存のUIコンポーネントを右クリックし、新規コンポーネントの配置場所として、選択したコンポーネントの前、後ろ、内部のいずれかを選択します。その後、リストからUIコンポーネントを選択します。
UIコンポーネントのバインド。構造ウィンドウで既存のUIコンポーネントを右クリックし、「ADFコントロールにバインド」を選択します。その後、コンポーネントをバインドするオブジェクトを選択できます。
UIコンポーネントの再バインド。構造ウィンドウで既存のUIコンポーネントを右クリックし、「別のADFコントロールに再バインド」を選択します。その後、コンポーネントをバインドする新しいコントロール・オブジェクトを選択できます。
UIコンポーネントの削除。コンポーネントを右クリックして、「削除」を選択します。コンポーネントを残してバインディングを削除する場合は、プロパティ・インスペクタを使用する必要があります。手順2の2番目の箇条書きを参照してください。
構造ウィンドウでUIコンポーネントを選択した後、プロパティ・インスペクタで次の処理を行えます。
UIコンポーネントのADF以外のバインディングの追加。「値」フィールドにEL式を入力するか、ドロップダウン・メニューを使用して「編集」を選択します。
UIコンポーネントのバインディングの削除。EL式を削除します。
UIコンポーネントのラベルの変更。デフォルトでは、ラベルはバインディングのヒントのlabelプロパティにバインドされます。このプロパティにより、エンティティ・オブジェクト属性またはビュー・オブジェクト属性に対して定義したラベルのUIコントロール・ヒントをページで使用できるようになります。UIヒントを使用すると、値の一度の変更で、ラベルを表示するすべてのページに同じ値を表示できます。
現在のページのラベルのみを変更できます。その場合は、label属性を選択します。ラベル値を別のもの(たとえば、プロパティ・ファイルやリソース・ファイルのキー)にバインドするために、テキストまたはEL式を入力します。
たとえば、製品名の表示に使用するinputTextコンポーネントでは、Label属性に対して次のようなコードが含まれます。
#{bindings.ProductName.hints.label}
この式を変更して、プロパティ・ファイルのキーにバインドすることもできます。例:
#{properties['productName']}
この例のpropertiesは、プロパティ・ファイルのロードに使用する、JSFページで定義された変数です。
