| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1(11.1.1.6.0) B52028-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1(11.1.1.6.0) B52028-04 |
|
前 |
次 |
この章では、ADF FacesコンポーネントおよびADFデータ・バインディングを使用して、複数の属性に対する複雑な検索および単一属性への検索を行う検索フォームを作成する方法について説明します。複雑な問合せ検索フォームについては、問合せ検索フォーム・モードの設定方法、結果表、保存済みの検索リスト、およびパーソナライズについて説明します。単一属性検索フォームについては、フォーム・レイアウトの構成方法を説明します。また、名前付きバインド変数およびQuery-by-Example(QBE)フィルタ処理された表の検索の使用についての情報も含まれます。
この章の内容は次のとおりです。
開発者は、オブジェクトの既知の属性に基づいてユーザーが検索基準を入力フィールドに入力することのできる検索フォームを作成できます。検索基準は入力テキスト・フィールドに入力するか、ポップアップ・リスト・ピッカーまたはドロップダウン・リスト・ボックスの値リストから選択できます。入力した基準は実行する問合せに組み込まれます。問合せの実行時に、名前付きバインド変数を使用して属性値を指定できます。問合せの結果は、表、フォームまたは別のUIコンポーネントとして表示できます。
検索フォームは、ビュー・オブジェクトで定義したビュー基準またはJDeveloperで定義した暗黙的ビュー基準に基づいています。検索フォームは、再利用およびパーソナライズが可能なリージョン・ベースのコンポーネントです。また、問合せの実行に必要な多くのアクションおよびイテレータ管理操作をカプセル化および自動化します。イテレータの変更および新しいイテレータの作成を行わずに、同一ページに複数の検索フォームを作成できます。
検索フォームは、モデルドリブンのaf:queryおよびaf:quickQueryコンポーネントに基づいています。これらの基礎となるコンポーネントはモデルドリブンであるため、検索フォームはモデルの変更を反映するよう自動的に変更されます。ビュー・レイヤーは変更する必要がありません。たとえば、ビュー・オブジェクトまたはエンティティ・オブジェクトの属性に値リスト(LOV)を定義すると、LOVは検索フォームにLOVコンポーネントとして自動的に表示されます。あるいは、ビュー基準を変更してWHERE句用に新しい属性を挿入すると、このビュー基準を使用する検索パネルは、その属性用の検索フィールドを追加してその変更を自動的に反映します。
Oracle ADFは、問合せおよびクイック問合せの2つのタイプの検索フォームをサポートしています。問合せ検索フォームは完全な機能を備えた検索フォームです。クイック問合せ検索フォームは、検索基準が1つしかない簡略化されたフォームです。それぞれの検索フォームはフィルタ処理された表と組み合せて結果を表示できるため、検索機能を追加できます。スタンドアロンのフィルタ処理された表も作成でき、問合せ検索パネルまたはクイック問合せ検索パネルを使用せずに検索を実行できます。
フィルタ処理された表は、それぞれの検索可能列の上に追加のQuery-by-Example(QBE)検索基準フィールドを持つ表です。表のフィルタ処理オプションが有効になっている場合、各列にQBEスタイルの検索基準を入力し問合せ結果をフィルタ処理できます。表の詳細は、第23章「ADFによるデータバインドされた表の作成」を参照してください。
個々の問合せコンポーネントおよび表コンポーネントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」および「表およびツリーの使用」を参照してください。
問合せ検索フォームは、複雑なトランザクション検索を行うための標準フォームです。それぞれに組込み演算子のドロップダウン・リストを保持する複数の検索基準フィールドがある複雑な検索フォームを作成できます。また、カスタム演算子を追加してリストをカスタマイズすることもできます。問合せ検索フォームでは、値リスト、AND結合とOR結合、および将来使用するための検索の保存がサポートされています。
問合せ検索フォームには基本モードと詳細モードがあります。ユーザーは「基本」ボタンまたは「詳細」ボタンを使用して、2つのモードを切り替えることができます。設計時にフォーム・プロパティを宣言的に指定(デフォルトの状態を設定するなど)して、基本または詳細のいずれかにすることができます。図27-1に、3つの検索基準を含む詳細モードの問合せ検索フォームを示します。
詳細モードの問合せフォームに含まれる機能は次のとおりです。
ドロップダウン・リストからの検索基準演算子の選択
カスタム演算子の追加と標準演算子の削除
WHERE句の結合におけるANDまたはOR(すべてに一致またはいずれかに一致)の選択
実行時の検索基準フィールドの動的な追加および削除
将来使用するための検索の保存
保存済の検索のパーソナライズ
通常、問合せ検索フォームはいずれかのモードで、関連付けられた結果表またはツリー表とともに使用します。たとえば、図27-1の検索フォームの問合せ結果は、図27-2に示すように、表に表示されます。
基本モードには、ユーザーによる動的な検索基準フィールドの追加以外の詳細モードのすべての機能が含まれます。図27-3に、1つの検索基準フィールドを含む基本モードの問合せ検索フォームを示します。詳細モードで検索基準フィールドの追加に使用される、「保存」ボタンの隣のドロップダウン・リストがないことに注意してください。
どちらのモードでも、Greater ThanおよびEqual Toなどの演算子をドロップダウン・リストから選択して各検索基準フィールドを変更できます。また、「すべてに一致」または「いずれかに一致」ラジオ・ボタンを使用して検索パネル全体を変更できます。検索フォームでは、ほとんどすべての状況下で部分ページ・レンダリングもサポートされています。たとえば、「Between」演算子を選択した場合、別の入力フィールドが表示され、範囲の上限を選択できるようになります。
「すべてに一致」を選択すると、問合せのWHERE句の検索基準において暗黙的にAND結合が使用されます。「いずれかに一致」を選択すると、問合せのWHERE句において暗黙的にOR結合が使用されます。例27-1に、図27-1に示した検索基準において「すべてに一致」を選択した場合、簡略化されたWHERE句がどのように表示されるかを示します(ビュー基準の実際のWHERE句は異なります)。
例27-2に、図27-3に示した検索基準において「いずれかに一致」を選択した場合、簡略化されたWHERE句がどのように表示されるかを示します。
問合せのビュー基準の基準アイテム間でAND結合およびOR結合が混在している場合、コンポーネントが最初にレンダリングされるときには「すべてに一致」および「いずれかに一致」のいずれも選択されません。しかし、「すべてに一致」または「いずれかに一致」を選択して、ビュー基準に初期状態として定義された結合を上書きできます。
詳細モードの問合せフォームでは、より複雑な問合せを実行するために、ユーザーは問合せパネルに検索基準フィールドを動的に追加できます。ユーザーが作成した検索基準フィールドは削除できますが、ユーザーは既存のフィールドを削除できません。図27-4に、CategoryId基準フィールドを検索フォームに追加するために、「フィールドの追加」ドロップダウン・リストをどのように使用するかを示します。
図27-5に、ユーザー追加の検索基準を示します。その右側には削除アイコンがあります。削除アイコンをクリックすると条件を削除できます。
「すべてに一致」または「いずれかに一致」が選択されている場合に、ユーザーが検索基準の2つ目のインスタンスを動的に追加すると、「すべてに一致」と「いずれかに一致」はともに選択解除されます。ユーザーは、「検索」ボタンをクリックする前に、「すべてに一致」または「いずれかに一致」を再度選択する必要があります。
問合せ検索フォームに基本モードおよび詳細モードの両方を使用する場合、各検索基準フィールドは、基本モードのみでの表示、詳細モードのみでの表示、両方での表示のいずれかに定義できます。ユーザーがあるモードから別のモードに切り替えると、そのモードに定義された検索基準フィールドのみが表示されます。たとえば、基本モード用にA、B、Cの3つの検索フィールドを、詳細モード用にA、B、Dの3つの検索フィールドを問合せに定義したとします。問合せ検索フォームが基本モードの場合、検索基準フィールドA、B、Cが表示されます。問合せ検索フォームが詳細モードの場合、検索基準フィールドA、B、Dが表示されます。その検索フィールドに入力されたすべての検索データは、フォームがそのモードに戻ったときも保持されています。基本モードにおいてユーザーが検索フィールドCに35と入力し、詳細モードに切り替えた後に再度基本モードに戻ると、フィールドCには値35が入力された状態で再表示されます。
基本または詳細モードを使用するとともに、検索フォームをどの程度表示するかを決定することもできます。デフォルト設定では、フォーム全体が表示されます。圧縮モードまたはシンプル・モードで表示するように、問合せコンポーネントを構成することもできます。圧縮モードでは、ヘッダーや境界線がなく、「保存済の検索」ドロップダウン・リストは開く/閉じるアイコンの横に移動しています。図27-6に、圧縮モードに設定された問合せコンポーネントを示します。
シンプル・モードでは、ヘッダーおよびフッターがなく、通常その領域に表示されるボタンもないコンポーネントが表示されます。図27-7に、シンプル・モードに設定された同じ問合せコンポーネントを示します。
問合せは、問合せ操作で使用するビュー・オブジェクトに関連付けられています。特に、問合せコンポーネントは、ビュー・オブジェクトに定義されたビュー基準を図示したものです。ビュー基準が複数定義されている場合、各ビュー基準は「保存済の検索」ドロップダウン・リストから選択できます。これら保存済の検索は設計時に作成され、システム検索と呼ばれます。たとえば、Fusion Order DemoアプリケーションのStoreFrontモジュールでは、ProductsVOビュー・オブジェクトに2つのビュー基準が定義されています。ビュー基準に関連付けられている問合せを実行すると、図27-8に示すように、両方のビュー基準が選択可能となります。
ビュー・オブジェクトに明示的に定義されたビュー基準が存在しない場合、デフォルトの暗黙的ビュー基準を使用できます。
ユーザーは、検索の状態を将来使用するために、実行時に保存済の検索を作成することもできます。図27-9に示すように、「保存」ボタンをクリックして「検索の保存」ダイアログを開き、入力された検索基準値、基本モードまたは詳細モードの状態、結果の表またはコンポーネントのレイアウトを保存できます。ユーザーが作成した保存済の検索はセッション内で保持されます。保存済の検索を、セッションを超えて使用できるようにするには、保存済の検索を格納するための永続データ・ストアを構成する必要があります。Oracle ADFでは、アクセス制御の対象となるデータソース(MDSなど)を使用できます。MDSの使用に関する詳細は、第34章「MDSによるアプリケーションのカスタマイズ」を参照してください。ユーザー・カスタマイズの詳細は、第35章「実行時でのユーザー・カスタマイズの許可」を参照してください。
表27-1に、保存済の検索、その作成方式および可用性のシナリオを作成者別に示します。
表27-1 設計時および実行時の保存済の検索
| 作成者 | 設計時にビュー基準として作成 | 実行時に「保存」ボタンを使用して作成 |
|---|---|---|
|
開発者 |
開発者による保存済の検索(システム検索)は、アプリケーション開発時に作成され、通常はソフトウェア・リリースの一部に含まれます。これらの検索は、設計時にビュー基準として作成されます。通常、アプリケーションのすべてのユーザーが利用可能であり、「保存済の検索」ドロップダウン・リストの下部に表示されます。 |
|
|
管理者 |
管理者による保存済の検索は、デプロイ前にサイト管理者が作成します。これらの検索は、サイトを一般のエンド・ユーザーが利用可能になる前に作成されます。管理者は、設計時に適切なロールでログインしてJDeveloperを使用し、保存済の検索(またはビュー基準)を作成できます。これらの保存済の検索(またはビュー基準)は、「保存済の検索」ドロップダウン・リストの下部に表示されます。 |
|
|
エンド・ユーザー |
エンド・ユーザーによる保存済の検索は、実行時に問合せフォームの「保存」ボタンを使用して作成します。これらの検索は、作成したユーザーのみが利用可能です。エンド・ユーザーの保存済の検索は、「保存済の検索」ドロップダウン・リストの最上部に表示されます。 |
図27-10に示すように、エンド・ユーザーは「保存済の検索」ドロップダウン・リストの「パーソナライズ」機能を使用して「保存済の検索のパーソナライズ」ダイアログを表示し、保存済の検索を管理できます。
エンド・ユーザーは、「パーソナライズ」機能を使用して次の操作を実行できます。
ユーザー作成の保存済の検索の更新
ユーザー作成の保存済の検索の削除
保存済の検索のデフォルトとしての設定
保存済の検索の自動実行の設定
「保存済の検索」ドロップダウン・リストでの保存済の検索の表示または非表示の設定
|
注意: ビュー基準アイテムの値をプログラム的に変更している場合は、ViewCriteria.saveState()メソッドを呼び出して、searchRegionバインディングにより、ビュー基準アイテムの値が設計時に指定された値にリセットされないようにする必要があります。 |
クイック問合せ検索フォームは、単一検索で十分な場合、またはフル問合せ検索を行うための起点とする場合に使用します。問合せ検索フォームおよびクイック問合せ検索フォームはどちらもADF Facesコンポーネントです。クイック問合せ検索フォームには、関連するデータ・コレクションから利用可能な検索可能属性のドロップダウン・リストとともに検索基準フィールドが1つ含まれます。通常は、関連するビュー・オブジェクトのすべての属性が検索可能属性となります。「属性の編集」ダイアログの「コントロール・ヒント」ページで、属性の「ヒントの表示」プロパティを「非表示」に設定して、属性を除外できます。ユーザーは、選択された属性または表示されるすべての属性に対して検索を実行できます。検索基準フィールド・タイプは対応する属性タイプに自動的に一致します。フォームに組み込まれた「詳細」リンクを使用すると、開発者はクイック問合せ検索フォームから詳細モードの問合せ検索フォームへの切替えを制御するマネージドBeanを作成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。
図27-11に示すように、フォームが水平方向レイアウトとなるように構成できます。
図27-12に示すように、垂直方向レイアウトも選択できます。
検索フォームで使用されるビュー基準でリテラル・オペランドを指定する代わりに、名前付きバインド変数を指定することもできます。名前付きバインド変数は、実行時に値が変化するパラメータのような動作をします。SQL文を変更する必要はありません。この変数をビュー基準で使用するには、まず、ビュー・オブジェクトで定義する必要があります。
ビュー基準でリテラル・オペランドを指定したときに、この値を空白のままにしておくと、SQLプレビューには表示されません。実行時に検索フォームとしてビュー基準を適用すると、その属性は空の入力検索フィールドとしてレンダリングされます。このリテラル・オペランドに対する値を指定した場合、SQLプレビューにより、このオペランドに対応したSQL句が生成されます。実行時に検索フォームとしてビュー基準が適用されたとき、ビュー基準で指定した値が入力検索フィールドに表示されたとしても、SQL文は自動的に適用されません。ユーザーが「検索」をクリックするまで(または、auto-executeがtrueに設定されるまで)、このSQL文は適用されません。
ビュー基準で定義された問合せで名前付きバインド変数が使用された場合、SQLプレビューには、バインド変数とともにWHERE句が表示されます。実行時に検索フォームとしてビュー基準が適用された場合、バインド変数名ではなく、属性名に基づいて、バインド変数がプロンプトおよび入力検索フィールドとともにレンダリングされます。名前付きバインド変数の入力フィールドは、NULL値、デフォルト値、別のページから受け取った値など以前の処理でロードされた値のいずれかの状態となります。ユーザーは他の検索基準と同様に、名前付きバインド変数の値を入力できます。検索を実行すると、名前付きバインド変数の値は、SQL問合せ文で定義したように他の基準で評価されます。
バインド変数が同じビュー基準で複数回使用されている場合、バインド変数は出現するたびに、1つの入力フィールドとしてレンダリングされます。すべての入力フィールドの背後にはバインド変数が1つしかありませんから、すべてのフィールドの値が同期されます。たとえば、同じバインド変数を3回使用するビュー基準を指定した場合、3つの入力フィールドがレンダリングされます。ユーザーが1つの入力フィールドに値を入力すると、その他2つの入力フィールドにも同じ値が入ります。このようにバインド変数を使用すると、ユーザーは同じ値を何回も入力する必要がなくなります。
バインド変数は、ベース行からLOV検索フォームの検索に値を渡すためにも使用できます。
また、たとえば、顧客IDを別のページに渡して、さらに詳細な処理をする場合など、あるページから別のページにパラメータ値を渡すときにもバインド変数を使用できます。さらに、SQL文の構成によっては、名前付きバインド変数を使用すると、新しい文を準備する必要が少なくなる、つまりデータベースを再解析する必要がなくなるため、問合せの速度が向上する可能性があります。名前付きバインド変数の作成および使用の詳細は、5.10項「バインド変数の使用」を参照してください。
たとえば、Fusion Order DemoアプリケーションのStoreFrontモジュールでは、listCustomerAddressesビュー基準のWHERE句は、AssociatedOwnerIdがparamCustomerId名前付きバインド変数の値と同じであるかどうかを確認します。このビュー基準は、AddressesLookupVOビュー・オブジェクト内にあります。図27-13に、「ビュー基準の編集」で定義したlistCustomerAddressesビュー基準を示します。
名前付きバインド変数のあるビュー基準の問合せ検索フォームは、inputTextコンポーネントを使用してその変数の検索フィールド付きでレンダリングされます。図27-14は、inputTextコンポーネントとして表示されているAssociatedOwnerId検索フィールドを示しています。
フィルタ処理された表はスタンドアロンとして作成することも、問合せ検索フォームまたはクイック問合せ検索フォームの結果表として作成することもできます。フィルタ処理された表の検索はQuery-by-Exampleに基づいており、QBEテキストまたは日付入力フィールド書式を使用します。検索基準の変更では>および<=などの文字を入力できるようにするため、入力バリデータは無効になっています。たとえば、数値列の検索基準として>1500と入力できます。ワイルドカード文字もサポートされます。列がQBEをサポートしていない場合、検索基準入力フィールドはその列に対してレンダリングを行いません。
フィルタ処理された表の検索基準入力値は、問合せのWHERE句を作成するためにAND演算子とともに使用されます。フィルタ処理された表が問合せ検索パネルまたはクイック問合せ検索パネルと関連付けられている場合、複合検索基準値も組み合せてWHERE句を作成します。
|
注意: フィルタ処理された表を問合せコンポーネントとともに検索フォームで使用し、検索リージョンで既存の名前付き基準を使用している場合、問合せの結果はすべてのビュー基準行によって繰り返しフィルタ処理されます。たとえば、あるフィルタ処理済の表にPersonIdとDeptIdの2つのビュー基準行があるとします。最初のビュー基準行にはPersonId > 1が含まれています。ユーザーがフィルタ・フィールドに「> 100」と入力すると、2つ目のビュー基準行DeptIdを使用して、入力値の受け入れと、その後の結果のフィルタ処理が行われます。この処理は、最終的な問合せ結果に達するまですべてのビュー基準行に対して繰り返されます。 |
図27-15に、フィルタ処理された結果表を含む問合せ検索フォームを示します。PersonIdフィールドに>100など、ユーザーがQBE検索基準を入力すると、問合せの結果は、問合せ検索基準とフィルタ処理された表の検索基準のAND結合となります。
表27-2に、検索値を変更するために使用可能なQBE検索演算子を示します。
データ・コントロールの作成時に、すべてのデータ・コレクションには「すべての問合せ可能な属性」基準を含む「名前付き基準」ノードが自動的に含まれます。これは、データ・コレクションの検索可能なすべての属性または列を含むデフォルトのビュー基準です。このビュー基準は編集または変更できません。暗黙的ビュー基準は、問合せ検索フォームまたはクイック問合せ検索フォームの作成時に宣言的に作成した(または、名前付き)ビュー基準と同様に使用できます。名前付きビュー基準の作成の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
そのビュー・オブジェクトまたはコレクションに対して名前付きビュー基準を追加する場合、新しいビュー基準は「名前付き基準」ノードに追加されます。
|
注意: 問合せ検索フォームには、ビュー基準がネストしている式を扱う場合の制約事項がいくつかあり、一部の種類のネストした式では動作しない可能性があります。検索フォームでサポートされているネストされた式の詳細は、5.11.4項「ネストされた式について」を参照してください。 |
「データ・コントロール」パネルでは、データ・コレクションの「名前付き基準」ノードに、名前付きビュー基準が定義されているかどうかに関係なく、必ず暗黙的ビュー基準が含まれます。暗黙的ビュー基準は常に、すべてのデータ・コレクションで使用できます。
値リスト(LOV)コンポーネントは、問合せにより生成されたリストからユーザーが選択して値を入力できるようにする入力コンポーネントです。ADF Facesには、af:inputListOfValuesおよびaf:inputComboboxListOfValuesコンポーネントが用意されています。検索フォームの一部に依存LOVを使用する場合は、必ず、af:queryコンポーネントとともに使用してください。LOVコンポーネントの詳細は、25.2項「値リスト(LOV)の作成」を参照してください。
ある属性がLOVとして定義されている場合、そのビュー基準で「複数の値の選択をサポート」コントロールのヒントを設定し、ユーザーが検索基準フィールドで複数選択できるようにすることができます。LOV属性で複数選択が有効になっているときに、Equal toまたはNot equal to演算子を選択した場合、selectManyChoiceコンポーネントが問合せパネルにレンダリングされます。ユーザーは検索基準として複数の項目を選択できます。
LOVが問合せコンポーネントに含まれているときに、「複数の値の選択をサポート」ヒントが設定されておらず、Equal toまたはNot equal to演算子が選択されている場合、この問合せコンポーネントは、ビュー・オブジェクト内の対応する属性に対する「デフォルトのリスト・タイプ」コントロール・ヒントに従って検索基準コンポーネントをレンダリングします。
クイック問合せコンポーネントでは、複数選択はサポートされていません。これは常に、「デフォルトのリスト・タイプ」コントロール・ヒントで指定されたコンポーネントをレンダリングします。表27-3に、コントロール・ヒントの選択肢とデフォルトのリスト・コンポーネントを示します。
表27-3 問合せおよびクイック問合せの検索基準フィールド入力コンポーネント
| デフォルトのリスト・タイプのコントロール・ヒント | コンポーネント |
|---|---|
|
値リストのある入力テキスト |
|
|
値リストを持つコンボ・ボックス |
|
|
選択リスト、コンボ・ボックス、リスト・ボックス、ラジオ・グループ |
|
ビュー基準オプションの詳細は、5.11.1項「名前付きビュー基準を宣言的に作成する方法」および5.11.3項「バインド変数オプションについて」を参照してください。
問合せ検索フォームは、名前付きビュー基準項目を「データ・コントロール」パネルからページにドロップして作成します。ドロップするものとして、検索パネルのみ、検索パネルと結果表、検索パネルとツリー表のいずれかを選択できます。
検索パネルを表とともにドロップすることにした場合、ダイアログでフィルタ処理オプションを選択し、表をフィルタ処理された表にすることができます。
通常は、問合せ検索パネルとともに結果表またはツリー表をドロップします。Jdeveloperでは、結果表またはツリー表が自動的に作成され、問合せパネルと関連付けられます。
問合せパネルのみをドロップし、結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、問合せパネルのResultsComponentIdと結果コンポーネントのIdを一致させる必要があります。
|
注意: 名前付きビュー基準をページにドロップすると、そのビュー基準は最初の検索フォームのベースとなります。そのデータ・コレクションに定義された他のすべてのビュー基準も「保存済の検索」ドロップダウン・リストに表示されます。その後、ユーザーは、任意のビュー基準検索フォームとエンド・ユーザーが作成した任意の保存済の検索を選択できます。 |
検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。
作業を始める前に、次のようにします。
検索フォームのベースとなるビュー・オブジェクトを作成しておく必要があります。明示的に作成したビュー基準を使用して検索を作成する場合、そのビュー基準をまだ作成していなければ、作成する必要があります。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。
ビュー基準の作成時には、検索フォームのデフォルト・プロパティの一部も設定する必要があります。検索フォームのデフォルト状態の設定の詳細は、27.3.1項「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
また、入力フィールドの一部またはすべてをLOVにする場合、ビュー・オブジェクトでその属性をLOVとして宣言している必要があります。
結果表またはツリー表付きの問合せ検索フォームを作成する手順:
「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。
名前付きビュー基準項目をドラッグし、ページまたは構造ウィンドウにドロップします。
図27-16に示すように、ポップアップ・メニューから、「作成」→「問合せ」→「表付きADF問合せパネル」または「作成」→「問合せ」→「ツリー表付きADF問合せパネル」を選択します。
「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。
フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。これを行う方法の詳細は、27.3項「検索フォーム・プロパティの設定」を参照してください。
検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。
作業を始める前に、次のようにします。
検索フォームのベースとなるビュー・オブジェクトを作成しておく必要があります。ユーザー独自のビュー基準を使用して検索を作成する場合、そのビュー基準をまだ作成していなければ、作成する必要があります。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。
ビュー基準の作成時には、検索フォームのデフォルト・プロパティの一部も設定する必要があります。検索フォームのデフォルト状態の設定の詳細は、27.3.1項「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
また、入力フィールドの一部またはすべてをLOVにする場合、ビュー・オブジェクトでその属性をLOVとして宣言している必要があります。
問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加する手順:
「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。
名前付きビュー基準項目をドラッグし、ページまたは構造ウィンドウにドロップします。
図27-16に示すように、ポップアップ・メニューから「作成」→「問合せ」→「ADF問合せパネル」を選択します。
まだ結果コンポーネントがない場合、ビュー基準に関連付けられているデータ・コレクションをコンポーネントとしてドロップします。
表のプロパティ・インスペクタで、「ID」フィールドの値をコピーします。
問合せパネルのプロパティ・インスペクタで、表のIDの値を問合せのResultsComponentIdフィールドに貼り付けます。
検索フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。詳細は、27.3項「検索フォーム・プロパティの設定」を参照してください。
保存済の検索をMDSに保存するには、adf-config.xmlファイルに/persdefネームスペースを定義する必要があります。また、metadatapathの指定など、通常のMDS構成を行うことも必要です。例27-3に、/persdefネームスペースを定義したadf-config.xmlファイルを示します。
例27-3 /persdefネームスペースを定義したadf-config.xmlの例
<persistence-config>
<metadata-namespaces>
<namespace path="/persdef" metadata-store-usage="mdsstore"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="mdsstore" deploy-target="true"
default-cust-store="true">
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
追加した保存済の検索をユーザーが次にログインしたときに使用できるようにするには、cust-configをMDS構成の一部として定義する必要があります。cust-configおよびMDSの設定の詳細は、34.2.7項「adf-config.xmlファイルの構成方法」を参照してください。
結果コンポーネントのレイアウトも保存する場合は、アプリケーションにADF PageFlow RuntimeライブラリとADF Controller Runtimeライブラリをインストールしておく必要があります。プロジェクトのテクノロジ・スコープにADF Page Flowがインクルードされるように設定するか、またはFusion Webアプリケーション(ADF)のアプリケーション・テンプレートを使用して、これらのライブラリを自動的にインクルードします。
検索バインディングは、実行時、検索フォームに対してモデルドリブンの動作を提供します。検索バインディングは、特定のイテレータ、およびそのイテレータのビュー基準に関連付けられていて、その実行時デフォルトはそれぞれ、検索バインディングの「バインド」プロパティと「基準」プロパティで指定されます。検索バインディングの動作は、「自動的に問合せ」コントロールのヒントによって異なります。名前付きビュー基準の作成の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
タスク・フローで初めて検索フォームがレンダリングされたときの検索バインディングの実行時の動作(初期のAutoQuery-or-ClearRowSet動作)は次のようになります。
「自動的に問合せ」がtrueに設定されている場合: タスク・フローで検索バインディングが初期化されたときに、検索バインディングにより、自動的にイテレータが実行されます。ユーザーには、ビュー基準に基づいた検索結果が提示されます。
「自動的に問合せ」がfalseに設定されている場合: 検索バインディングにより、イテレータに関係する行セットがクリアされます。ユーザーには空の検索結果コンポーネントが提示されます。ユーザーはここから検索基準を入力し、「検索」ボタンをクリックして、検索を実行できます。
「自動的に問合せ」コントロールのヒントは、名前付きビュー基準に対してのみ、宣言的に使用できます。「すべての問合せ可能な属性」ビュー基準に対して、このビュー基準のAPIインタフェースでsetProperty()メソッドを使用し、実行時にヒントを構成することができます。また、このメソッドを使用して、名前付きビュー基準にヒントを設定することもできます。このメソッドで、ViewCriteriaHints.CRITERIA_AUTO_EXECUTEプロパティをtrueに設定します。
ユーザーが「保存済の検索」ドロップダウン・リストから別のビュー基準を選択して、検索フォームを変更した場合の実行時の動作は次のようになります。
「自動的に問合せ」がtrueに設定されている場合: 検索バインディングにより、新しいビュー基準の適用後、自動的にイテレータが実行されます。ユーザーには、新たに選択された保存済の検索結果が提示されます。
「自動的に問合せ」がfalseに設定されている場合: 検索バインディングにより、新しいビュー基準のみが適用され、既存の検索結果はすべてそのまま残されます。ユーザーには、以前の検索結果が提示されます。
自動的に、またはユーザーが「検索」ボタンをクリックしたことにより、検索バインディングが問合せを実行した場合、検索バインディングのqueryPerformedプロパティはtrueに評価されます。検索フォームで「リセット」ボタンをクリックすると、ビュー基準がリセットされ、queryPerformedプロパティがfalseに設定されます。
ユーザーが検索バインディングのデフォルト動作をカスタマイズできるようにするために、TrackQueryPerformedおよびInitialQueryOverriddenという2つのプロパティが用意されています。TrackQueryPerformedプロパティおよびInitialQueryOverriddenプロパティはプロパティ・インスペクタで設定できます。
検索バインディングのTrackQueryPerformedプロパティは、検索バインディングが実行時のqueryPerformedプロパティをページ・フロー・レベル、個々のページ・レベル、ページ・フラグメント・レベルのいずれで管理するかを制御します。TrackQueryPerformedに有効な値はpageFlowとpageで、デフォルトはpageFlowです。検索バインディングは次のように動作します。
TrackQueryPerformedがpageFlowに設定されている場合、queryPerformedはページ・フロー1回につき一度初期化され、ページ・フロー・レベルで追跡されます。ユーザーは検索フォーム・ページ以外の場所に移動し、ページ・フローの有効期限が切れる前にこのページに戻りますが、queryPerformedフラグの値は変わりません。
TrackQueryPerformedがpageに設定されている場合、queryPerformedはユーザーがこのページ、またはページ・フラグメントに移動するたびに初期化されます。これは、そのページに初めてナビゲートされたとき、およびページ・フロー内の別のページから返されたときに発生します。
検索バインディングのTrackQueryPerformedがpageFlowに設定されている場合、最初のAutoQuery-or-ClearRowSet動作は、ページ・フロー中に一度、実行されます。対照的に、TrackQueryPerformedがpageに設定されている場合、最初のAutoQuery-or-ClearRowSet動作はユーザーがページまたはページ・フラグメントにアクセスするたびに実行されます。
検索バインディングのInitialQueryOverriddenプロパティは、ページ・フローで検索バインディングが初めて使用されたときに、最初のAutoQuery-or-ClearRowSet動作を抑制すべきかどうかを制御します。InitialQueryOverriddenがtrueの場合、true、false、ブール値のEL式を含む、すべての有効な値が抑制されます。デフォルト値はfalseです。
InitialQueryOverriddenプロパティをtrueに設定した場合、問合せを実行するためのカスタム・アプリケーション・ロジックを記述しなければなりません。通常、この問合せは、コードが何らかのビュー基準を適用、バインド変数を設定、またはプログラムで問合せの設定を実行した後で行う必要があります。カスタム・コードが、InitialQueryOverriddenがtrueに設定されているときに期待されているとおりの問合せを実行できなかった場合、「自動的に問合せ」がfalseに設定されていない限り、フレームワークは、イテレータ・バインディング参照のあるユーザー・セッション中に初めて暗黙的な問合せを実行します。これは「自動的に問合せ」がfalseに設定されていない場合、イテレータ・バインディングのデフォルトexecuteQueryIfNeeded動作が有効になり、問合せが実行されるために起こります。
InitialQueryOverriddenがtrue、またはブール値のtrueに評価されるとき、ページ・フローで初めて検索バインディングが使用されると、最初のAutoQuery-or-ClearRowSet動作は抑制されます。TrackQueryPerformedがpageFlowに設定されている場合、この検索バインディングについて発生する最初のAutoQuery-or-ClearRowsSet動作のみ抑制されます。
対照的に、検索バインディングのTrackQueryPerformedプロパティがpageに設定されている場合、最初のAutoQuery-or-ClearRowSet動作のみが抑制されます。その後、ユーザーが同じページ(またはページ・フラグメント)に戻ったため発生した最初のAutoQuery-or-ClearRowSet動作は、InitialQueryOverriddenプロパティによる影響を受けません。
検索バインディングによる、最初のAutoQuery-or-ClearRowSet動作の実行を回避する必要がある場合は、TrackQueryPerformedをpageFlowに設定したまま、InitialQueryOverriddenをtrueに設定します。
検索バインディングのqueryPerformedプロパティの参照に、イテレータのRefreshConditionプロパティを使用してはいけません。これにより、検索バインディングの問合せが実行される前に、このイテレータの行セットに誤って新しい行が作成されるのを防ぐことができます。
ある検索基準が別の基準の値に依存しているという状況があります。たとえば、あるバグ・データベースに、ComponentおよびSubomponent検索基準を持つ検索フォームがあり、これらの検索基準は両方ともLOVとして定義されているとします。ユーザーがComponent検索基準から値を選択したときに、Subomponentをフィルタし、ユーザーの選択肢となる適切な検索リストを移入できるように、この値はモデルに送信されなければなりません。
依存関係を持つ検索基準を使用している場合、ルートと依存基準の基礎となるビュー属性のAuto Submitコントロールのヒントをtrueに設定する必要があります。カスタム・リスナーを作成し、部分的送信をトリガーしてモデルを更新し、問合せコンポーネントがルート基準の値の変更を検知したときに、検索パネルをリフレッシュします。標準のQueryOperationListenerはこのイベント・タイプに対応できないため、カスタム・リスナーを作成する必要があります。QueryOperationListenerインタフェースを使用して、カスタムQueryOperationListenerクラスを作成することができます。その後、このクラスをマネージドBeanに実装するか、またはJSFページに直接設定して登録します。
問合せ検索フォームをページにドロップすると、ページにaf:queryタグが作成されます。問合せと表またはツリー表をドロップした場合、af:queryタグの後にaf:tableタグまたはaf:treeTableタグが続きます。
af:queryタグの下には問合せのプロパティを定義する複数の属性があります。属性には、次のものが含まれます。
問合せを一意に識別するid属性。
問合せ結果が表示されるコンポーネントを識別するresultsComponentId属性。通常、これは問合せとともにページにドロップされた表またはツリー表です。この値は、別の結果コンポーネントのidに変更できます。詳細は、27.2.2項「問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。
ページ定義ファイルのexecutablesセクションに、iteratorおよびsearchRegionエントリが作成されます。例27-4に、ページ定義ファイルのサンプル・コードを示します。
ページ定義ファイルのexecutableセクションでは、プロパティが次のように設定されます。
イテレータbindsプロパティはデータ・コレクション名に設定します。この例では、値がProductsに設定されています。
イテレータidプロパティはデータ・コレクション・イテレータに設定します。この例では、値がSearchProductsIteratorに設定されています。
そのデータ・コレクションについて、複数のビュー基準が定義されている場合、searchRegion Criteriaプロパティは、ドロップされたビュー基準の名前に設定されます。この例では、値がFindByProductNameCriteriaに設定されています。定義されているビュー基準が1つのみの場合、Criteriaプロパティはありません。
searchRegionのBindsプロパティは、iterator idプロパティと同じ値に設定されます。この例では、値がSearchProductsIteratorに設定されています。
searchRegionのidプロパティには、ビュー基準とQueryを連結した名前が設定されます。この例では、値がFindByProductNameCriteriaQueryに設定されています。
問合せを表またはツリーとともにページにドロップした場合は、ページ定義ファイルのbindingsセクションにtree要素が追加され、Iterbindingプロパティが検索イテレータに設定されます。この例では、値がSearchProductsIteratorに設定されています。これは、executableセクションで定義されたイテレータと同じものでなければなりません。
例 27-4 ページ定義ファイルの検索フォーム・コード
<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="11.1.1.52.34" id="homePageDef"
Package="oracle.fodemo.storefront.pageDefs"
EnableTokenValidation="false">
<parameters/>
<executables>
...
<iterator Binds="Products" RangeSize="25"
DataControl="StoreServiceAMDataControl"
id="SearchProductsIterator"/>
...
<searchRegion Criteria="FindByProductNameCriteria"
Customizer="oracle.jbo.uicli.binding.JUSearchBindingCustomizer"
Binds="SearchProductsIterator"
id="FindByProductNameCriteriaQuery"/>
...
</executables>
<bindings>
<tree IterBinding="SearchProductsIterator"
id="SearchProducts">
<nodeDefinition DefName="oracle.fodemo.storefront.store.queries.ProductsVO"
Name="SearchProducts">
<AttrNames>
<Item Value="ProductId"/>
<Item Value="ProductName"/>
<Item Value="ListPrice"/>
<Item Value="MinPrice"/>
,,,
</AttrNames>
</nodeDefinition>
</tree>
...
</bindings>
実行時には、検索フォームはページ上の検索パネルとして表示されます。検索パネルは、対応するビュー基準が作成されたときのモードのコントロール・ヒントに応じて、基本モードまたは詳細モードのいずれかで表示されます。「保存済の検索」ドロップダウン・リストには、有効(「リストに表示」コントロール・ヒントが有効)なビュー基準がすべて含まれます。「すべてに一致」または「いずれかに一致」結合ラジオ・ボタンが有効化されることがあります。
検索基準フィールドは、ビュー基準に定義された検索基準ごとにレンダリングされます。ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは表27-3に示すようになります。
ユーザーが検索基準を入力して「検索」をクリックすると、ビュー基準に対する問合せが実行され、関連付けられた表、ツリー表またはコンポーネントに結果が表示されます。
問合せ検索フォームは、ビュー・オブジェクトで定義されたビュー基準に基づいています。ビュー基準の作成時には、検索フォーム・プロパティの一部も指定します。後で名前付き基準をページにドロップして問合せコンポーネントを作成する場合、その他の検索フォーム・プロパティも指定できます。
ビュー基準の作成時に設定可能な検索フォーム・プロパティは、次のとおりです。
基本モードまたは詳細モードのデフォルトのモード
ページのロード時の自動問合せ実行
検索基準フィールドのレンダリング
LOVとして定義された属性の複数選択を有効化
問合せコンポーネントがJSFページに追加された後に設定可能な検索フォーム・プロパティは、次のとおりです。
結果表または結果コンポーネントのid
「基本」ボタンまたは「詳細」ボタンの表示または非表示
モード・ボタンの位置
デフォルト、シンプルまたは圧縮の表示モード
ビュー基準の作成時に、複数のプロパティの初期状態を宣言的に設定できます。図27-17に、デフォルト・オプションの設定に使用する「ビュー基準の編集」ダイアログを示します。ビュー基準の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
問合せ検索フォームのデフォルト・モードとして「基本」または「詳細」のいずれかを選択する必要があります。デフォルトは「基本」モードです。
また、個々の検索基準フィールドが使用できるのは、基本モードのみ、詳細モードのみ、両方のモードのいずれか、あるいは表示しないかを宣言する必要があります。検索基準フィールドが「基本」モードのみで宣言されている場合、ユーザーが「詳細」モードに切り替えた場合は表示されず、逆も同様です。フィールドが両方のモードに対して宣言されている場合、両方のモードで表示されます。検索基準フィールドのレンダリングのデフォルトは、すべてのモードです。
デフォルト・モードと検索基準フィールドの表示オプションを設定する手順:
ビュー基準の作成時に、「ビュー基準の編集」ダイアログで「UIヒント」をクリックします。
「検索リージョン・モード」ドロップダウン・リストから、「基本」または「詳細」を選択します。
「基準アイテムUIのヒント」セクションで、設定する基準アイテムを選択します。
「表示されたモード」ドロップダウン・リストで、「すべて」、「基本」、「詳細」または「なし」を選択します。
図27-18に示すように、問合せ検索フォームをページにドロップした後に、プロパティ・インスペクタで他のフォーム・プロパティを編集できます。次のような共通プロパティを設定できます。
「基本」または「詳細」モード・ボタンの有効化または無効化
問合せ検索フォームのIDの設定
結果表などの結果コンポーネントのIDの設定
デフォルト、シンプルまたは圧縮の表示モードの選択
一般的なオプションの1つに、「基本」または「詳細」ボタンの表示または非表示があります。
問合せフォームで「基本」または「詳細」ボタンを有効化または非表示にする手順:
構造ウィンドウで「af:query」をダブルクリックします。
プロパティ・インスペクタで「外観」タブをクリックします。
「基本」または「詳細」モード・ボタンを有効化するには、ModeChangeVisibleフィールドで「True」を選択します。「基本」または「詳細」モード・ボタンを非表示するには、ModeChangeVisibleフィールドで「False」を選択します。
ビュー・オブジェクトXMLファイルにコードを追加すると、各ビュー基準項目にカスタム演算子を作成できます。たとえば、日付属性を処理するmore than a year(現在の日から365日後)という演算子を新規に作成できます。
また、ビュー基準項目から標準演算子を削除することもできます。たとえば、標準演算子であるbeforeをリストから削除できます。
標準演算子のリストは、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。
カスタム演算子を追加する手順:
アプリケーション・ナビゲータで、カスタム演算子を追加するビュー基準のビュー・オブジェクトを選択します。
エディタ・ウィンドウで「ソース」タブをクリックします。
XMLエディタで、ビュー基準属性のコードを特定し、ViewCriteriaItemグループの最後の項目の後にCompOperコード文を追加します。
例27-5では、CompOperコード文を太字で表示しています。
例27-5 ビュー・オブジェクトXMLへのカスタム演算子コードの追加
<ViewCriteriaRow
Name="vcrow50"
UpperColumns="1">
<ViewCriteriaItem
Name="LastUpdateDate"
ViewAttribute="LastUpdateDate"
Operator="="
Conjunction="AND"
Required="Optional">
<CompOper
Name="LastUpdateDate"
ToDo="1"
OperDescStrCode="LastUpdateDate_custOp_grt_year"
Oper=">Y"
MinCardinality="0"
MaxCardinality="0" >
<TransientExpression><![CDATA[ return " < SYSDATE - 365"
]]></TransientExpression>
</CompOper>
</ViewCriteriaItem>
CompOperプロパティは次のとおりです。
Name: 操作のidを指定します。
ToDo: このカスタム演算子を追加するには1に設定します。演算子を削除するには-1に設定します。
OperDescStrCode: 手順4で説明しているように、説明の文字列にマップするために、メッセージ・バンドルで使用したidを指定します。
Oper: SQL文でこの操作を示すために、プログラム的に使用される値に設定します。例27-5では、Operは>Y(1年より長いことを示す)に設定されています。
MinCardinality: 入力範囲がある場合、範囲の最小値を設定します。たとえば、範囲が月である場合、この値を1に設定する必要があります。範囲がない場合、0に設定します。
MaxCardinality: 入力範囲がある場合、範囲の最大値を設定します。たとえば、範囲が月である場合、この値を12に設定する必要があります。範囲がない場合、0に設定します。
TransientExpression: カスタム演算を実行するための式を設定します。例27-5では、この式は![CDATA[return " > SYSDATE -365"]]です。これは文字列" > SYSDATE -365"を戻します。
ビュー・オブジェクトのメッセージ・バンドル・ファイルを開き、手順3でビュー・オブジェクトXMLに定義したOperDescStrCode識別子を使用してカスタム演算子のエントリを追加します。
標準演算子を削除する手順:
アプリケーション・ナビゲータで、標準演算子を削除するビュー基準のビュー・オブジェクトを選択します。
|
注意: 標準演算子の削除を試みる前に、ビュー基準アイテムのデフォルト演算子を削除してないかどうかを確認してください。 |
エディタ・ウィンドウで「ソース」タブをクリックします。
XMLエディタで、ビュー基準属性のコードを特定し、ViewCriteriaItemグループの最後の項目の後にCompOperコード文を追加します。
例27-7では、CompOperコード文を太字で表示しています。この例のコードは、BEFORE演算子をLastUpdateDate属性の演算子のリストから削除します。
例27-7 ビュー・オブジェクトXMLからの標準演算子コードの削除
<ViewCriteriaRow
Name="vcrow50"
UpperColumns="1">
<ViewCriteriaItem
Name="LastUpdateDate"
ViewAttribute="LastUpdateDate"
Operator="="
Conjunction="AND"
Required="Optional">
<CompOper
Name="LastUpdateDate"
ToDo="-1"
Oper="BEFORE"
</CompOper>
</ViewCriteriaItem>
CompOperプロパティは次のとおりです。
Name: 操作のidを指定します。
ToDo: 演算子を削除するには-1に設定します。演算子を追加するには1に設定します。
ToDoを2に設定しないでください。すべての演算子が削除されます。
Oper: リストから削除する標準演算子に設定します。
クイック問合せ検索フォームを使用すると、ユーザーによるコレクションの単一属性の検索が可能になります。クイック問合せ検索フォームのレイアウトは、水平または垂直に設定できます。クイック問合せ検索フォームは小さい領域のみを使用するため、ページの様々な領域に配置できます。ユーザーによるクイック問合せ検索からフル問合せ検索への切替えを可能にするマネージドBeanを作成できます。マネージドBeanを使用したクイック問合せから問合せへの切替えの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。
結果表またはツリーとともにクイック問合せパネルをドロップした場合、27.4.1項「結果表またはツリー表付きのクイック問合せ検索フォームの作成方法」で説明されているとおり、JDeveloperにより自動的に結果表が作成されます。クイック問合せパネルのみをドロップした後に結果表または結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、27.4.2項「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」で説明されているとおり、クイック問合せのIdと結果コンポーネントのpartialTrigger値を一致させる必要があります。
|
注意: クイック問合せ検索は、基礎となるビュー・オブジェクトで定義されたすべての検索可能な属性のドロップダウン・リストを作成します。それらの属性の一部のみを表示する場合は、除外する属性の「表示」コントロール・ヒントを「非表示」に設定できます。ビュー・オブジェクトのコントロール・ヒントの設定の詳細は、第5章「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。 |
検索可能な属性の完全セットを使用してクイック問合せ検索を作成すると同時に、表またはツリー表を結果コンポーネントとして追加できます。
作業を始める前に、次のようにします。
検索フォームのベースとなるビュー・オブジェクトを作成します。
結果表付きのクイック問合せ検索フォームを作成する手順:
「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。
All Queriable Attributes項目をドラッグし、ページまたは構造ウィンドウにドロップします。
図27-19に示すように、ポップアップ・メニューから、「作成」→「クイック問合せ」→「表付きADFクイック問合せ」または「作成」→「クイック問合せ」→「ツリー表付きADFクイック問合せ」を選択します。
「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。
検索可能な属性の完全セットを使用してクイック問合せ検索を作成した後で、表またはツリー表を結果コンポーネントとして追加できます。
作業を始める前に、次のようにします。
検索フォームのベースとなるビュー・オブジェクトを作成します。
クイック問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加する手順:
「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。
All Queriable Attributes項目をドラッグし、ページまたは構造ウィンドウにドロップします。
ポップアップ・メニューから、「作成」→「クイック問合せ」→「ADFクイック問合せパネル」を選択します。
まだ結果コンポーネントがない場合、ビュー基準に関連付けられているデータ・コレクションをコンポーネントとしてドロップします。
クイック問合せパネルのプロパティ・インスペクタで、「ID」フィールドの値をコピーします。
結果コンポーネント(表など)のプロパティ・インスペクタで、値をPartialTriggersフィールドに貼り付けるか入力します。
デフォルトのレイアウト書式は垂直方向です。プロパティ・インスペクタを使用して、レイアウト・オプションを変更できます。
レイアウトを設定する手順:
構造ウィンドウで「af:quickQuery」をダブルクリックします。
プロパティ・インスペクタの「共通」ページで、ドロップダウン・リストから「レイアウト」プロパティを選択して、「デフォルト」、「水平方向」、「垂直」のいずれかを指定します。
クイック問合せ検索フォームをページにドロップすると、JDeveloperはaf:quickQueryタグを作成します。クイック問合せと表またはツリー表をドロップした場合、af:tableタグまたはaf:treeTableタグも追加されます。
af:quickQueryタグの下にはクイック問合せのプロパティを定義する複数の属性およびファセットがあります。タグの一部は次のとおりです。
クイック問合せを一意に識別するid属性。この値は結果表または結果コンポーネントのpartialTriggers値に一致するように設定する必要があります。クイック問合せと表またはツリー表をドロップすると、JDeveloperはこれらの値を自動的に割り当てます。別の結果コンポーネントに変更する方法は、27.4.2項「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。
クイック問合せのレイアウトをデフォルト、水平または垂直に指定するlayout属性。
「詳細」リンク(クイック問合せから問合せにモードを変更)の表示に使用するコンポーネントを指定するendファセット。この機能の作成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。
実行時に、クイック問合せ検索フォームには、単一の検索基準フィールドが選択可能な検索基準アイテムのドロップダウン・リストとともに表示されます。検索可能な基準アイテムが1つしかない場合、ドロップダウン・リスト・ボックスはレンダリングされません。表27-4に示すように、選択した検索基準タイプと互換性のある入力コンポーネントが表示されます。たとえば、検索基準タイプがDATEの場合、inputDateがレンダリングされます。
表27-4 クイック問合せ検索基準フィールド・コンポーネント
| 属性タイプ | レンダリングされたコンポーネント |
|---|---|
|
|
|
|
|
|
|
|
|
ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは27.1.6項「値リスト(LOV)入力フィールド」の表27-3に示すようになります。
また、「検索」ボタンが入力フィールドの右側にレンダリングされます。endファセットを指定すると、endファセットのコンポーネントはすべて表示されます。デフォルトでは、endファセットには「詳細」リンクが含まれます。
複雑な検索では問合せ検索フォームを使用しますが、フィルタ処理された表を使用して単純なQBE検索を実行することもできます。関連付けられた検索パネルのないスタンドアロンのADFのフィルタ処理された表を作成し、QBE形式の検索基準入力フィールドを使用して検索を実行できます。フィルタ処理された表の詳細は、27.1.4項「フィルタ処理された表とQuery-by-Example検索」を参照してください。
表の作成時に、フィルタ処理オプションが有効な場合にそのオプションを選択すると、ほとんどすべての表をフィルタ処理された表にできます。スタンドアロンのフィルタ処理された表を作成するには、次の3つの方法があります。
コンポーネント・パレットからページに表をドロップし、データ・コレクションにバインドしてフィルタ処理オプションを設定できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。
データ・コレクションをページにドラッグ・アンド・ドロップしてフィルタ処理オプションを設定すると、フィルタ処理された表を作成できます。詳細は、23.2.1項「基本表の作成方法」を参照してください。
名前付き基準をページにドロップし、フィルタ処理された表または読取り専用のフィルタ処理された表を作成することもできます。暗黙的に作成された名前付き基準のAll Queriable Attributes、または宣言的に作成された名前付きビュー基準のどちらも使用できます。作成されるフィルタ処理された表には、検索可能属性のそれぞれに対応する列があり、各列の上に入力検索フィールドがあります。
af:tableコンポーネントのaf:columnのfilterFeature属性を使用すると、フィルタ処理可能な各列のQBE検索基準において、大文字と小文字を区別するかどうかを設定できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表でのフィルタ処理の有効化に関する項を参照してください。
作業を始める前に、次のようにします。
表のベースとなるビュー・オブジェクトを作成します。
名前付きビュー基準を使用してフィルタ処理された表を作成する手順:
「データ・コントロール」パネルから、データ・コレクションを選択し、「名前付き基準」ノードを展開して名前付きビュー基準のリストを表示します。
名前付きビュー基準項目をドラッグし、ページまたは構造ウィンドウにドロップします。
ポップアップ・メニューから、「作成」→「表」→「ADFフィルタリング済表」または「作成」→「表」→「ADF読取り専用フィルタリング済表」を選択します。
「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。表はクイック問合せの作成時に自動的に作成されるため、図27-20に示すように、フィルタ処理オプションは自動的に有効になり、ユーザーは選択できません。
