| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.1.0) E77397-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.1.0) E77397-02 |
|
|
前 |
次 |
この章の内容は次のとおりです。
開発者は、オブジェクトの既知の属性に基づいてユーザーが検索基準を入力フィールドに入力することのできる検索フォームを作成できます。検索基準は入力テキスト・フィールドに入力するか、ポップアップ・リスト・ピッカーまたはドロップダウン・リスト・ボックスの値リストから選択できます。入力した基準は実行する問合せに組み込まれます。問合せの実行時に、名前付きバインド変数を使用して属性値を指定できます。問合せの結果は、表、フォームまたは別のUIコンポーネントとして表示できます。
Oracle ADFは、問合せおよびクイック問合せの2つのタイプの検索フォームをサポートしています。問合せ検索フォームは完全な機能を備えた検索フォームです。クイック問合せ検索フォームは、検索基準が1つしかない簡略化されたフォームです。それぞれの検索フォームはフィルタ処理された表と組み合せて結果を表示できるため、検索機能を追加できます。スタンドアロンのフィルタ処理された表も作成でき、問合せ検索パネルまたはクイック問合せ検索パネルを使用せずに検索を実行できます。
検索フォームは、ビュー・オブジェクトで定義したビュー基準またはJDeveloperで定義した暗黙的ビュー基準に基づいています。検索フォームは、再利用およびパーソナライズが可能なリージョン・ベースのコンポーネントです。また、問合せの実行に必要な多くのアクションおよびイテレータ管理操作をカプセル化および自動化します。イテレータの変更および新しいイテレータの作成を行わずに、同一ページに複数の検索フォームを作成できます。
フィルタ処理された表は、それぞれの検索可能列の上に追加のQuery-by-Example (QBE)検索基準フィールドを持つ表です。表のフィルタ処理オプションが有効になっている場合、各列にQBEスタイルの検索基準を入力し問合せ結果をフィルタ処理できます。表の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。
個別の問合せコンポーネントおよび表コンポーネントの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」および「表、ツリー、およびその他のコレクションベースのコンポーネントの使用」を参照してください。
データ・コントロールの作成時に、すべてのデータ・コレクションには「すべての問合せ可能な属性」基準を含む「名前付き基準」ノードが自動的に含まれます。これは、データ・コレクションの検索可能なすべての属性または列を含むデフォルトのビュー基準です。このビュー基準は編集または変更できません。暗黙的ビュー基準は、問合せ検索フォームまたはクイック問合せ検索フォームの作成時に宣言的に作成した(または、名前付き)ビュー基準と同様に使用できます。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。
そのビュー・オブジェクトまたはコレクションに対して名前付きビュー基準を追加する場合、新しいビュー基準は「名前付き基準」ノードに追加されます。
注意:
問合せ検索フォームには、ビュー基準がネストしている式を扱う場合の制約事項がいくつかあり、一部の種類のネストした式では動作しない可能性があります。検索フォームでサポートされるネストされた式の詳細は、「ネストされたビュー基準の式に関する必知事項」を参照してください。
「データ・コントロール」パネルでは、データ・コレクションの「名前付き基準」ノードに、名前付きビュー基準が定義されているかどうかに関係なく、必ず暗黙的ビュー基準が含まれます。暗黙的ビュー基準は常に、すべてのデータ・コレクションで使用できます。
値リスト(LOV)コンポーネントは、問合せにより生成されたリストからユーザーが値を選択して入力できる、入力コンポーネントです。ADF Facesには、af:inputListOfValuesおよびaf:inputComboboxListOfValuesコンポーネントが用意されています。検索フォームの一部に依存LOVを使用する場合は、必ず、af:queryコンポーネントとともに使用してください。LOVコンポーネントの詳細は、「値リスト(LOV)のコンポーネントの作成」を参照してください。
ある属性がLOVとして定義されている場合、そのビュー基準で「複数の値の選択をサポート」コントロールのヒントを設定し、ユーザーが検索基準フィールドで複数選択できるようにすることができます。LOV属性で複数選択が有効になっているときに、Equal toまたはNot equal to演算子を選択した場合、selectManyChoiceコンポーネントが問合せパネルにレンダリングされます。ユーザーは検索基準として複数の項目を選択できます。
LOVが問合せコンポーネントに含まれているときに、「複数の値の選択をサポート」ヒントが設定されておらず、Equal toまたはNot equal to演算子が選択されている場合、この問合せコンポーネントは、ビュー・オブジェクト内の対応する属性に対する「デフォルトのリスト・タイプ」コントロール・ヒントに従って検索基準コンポーネントをレンダリングします。
クイック問合せコンポーネントでは、複数選択はサポートされていません。これは常に、「デフォルトのリスト・タイプ」コントロール・ヒントで指定されたコンポーネントをレンダリングします。表36-1に、コントロール・ヒントの選択肢とデフォルトのリスト・コンポーネントを示します。
表36-1 問合せおよびクイック問合せの検索基準フィールド入力コンポーネント
| デフォルトのリスト・タイプのコントロール・ヒント | コンポーネント |
|---|---|
値リストのある入力テキスト |
|
値リストを持つコンボ・ボックス |
|
選択リスト、コンボ・ボックス、リスト・ボックス、ラジオ・グループ |
|
ビュー基準オプションの詳細は、「名前付きビュー基準を宣言的に作成する方法」および「ビュー基準のバインド変数に関する必知事項」を参照してください。
検索フォームは、モデルドリブンのaf:queryおよびaf:quickQueryコンポーネントに基づいています。これらの基礎となるコンポーネントはモデルドリブンであるため、検索フォームはモデルの変更を反映するよう自動的に変更されます。ビュー・レイヤーは変更する必要がありません。たとえば、ビュー・オブジェクトまたはエンティティ・オブジェクトの属性に値リスト(LOV)を定義すると、LOVは検索フォームにLOVコンポーネントとして自動的に表示されます。あるいは、ビュー基準を変更してWHERE句用に新しい属性を挿入すると、このビュー基準を使用する検索パネルは、その属性用の検索フィールドを追加してその変更を自動的に反映します。
図36-1に、クイック問合せコンポーネントを示します。
図36-1 クイック問合せ
製品名、価格帯および可用性などの基準を組み合せたより複雑な検索には、問合せコンポーネントが使用されます。図36-2に示すように、様々なモードで問合せコンポーネントを作成し、ユーザーに各種機能を提供できます。ユーザーは、「フィールドの追加」ボタンを使用して、独自の基準を作成できます。今後の使用を目的として作成した検索を保存できます。
図36-2 問合せコンポーネント
簡易検索では、図36-3に示すように、フィルタ処理された表を使用して例示問合せ(QBE)検索を実行できます。
図36-3 フィルタ処理された表の検索
ADFモデル・レイヤーを構成または使用する前に、他のADF機能を理解しておくと役立つ場合があります。また、モデル・レイヤーの構成によって可能になることについても、確認しておくことをお薦めします。次に、関連する他の機能へのリンクを示します。
問合せコンポーネントとクイック問合せコンポーネントはどちらも、ビュー・オブジェクトに定義されたビュー基準に基づいています。ビュー基準を使用して初期の検索フィールドと検索基準を設定します。コントロール・ヒントを使用して問合せコンポーネントをさらに定義します。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。
フィルタ処理された表には検索機能も備わっているので、簡易検索機能と見なす必要があります。表の詳細は、「ADFによるデータバインドされた表の作成」を参照してください。
値リスト・コンポーネントでは、LOV選択リストを作成する際に、検索パネルで問合せコンポーネントを使用します。LOVコンポーネントの詳細は、「値リスト(LOV)のコンポーネントの作成」を参照してください。
アプリケーションがメタデータ・ストレージ(MDS)と組み合せて設定されている場合は、保存済の検索をトランザクション全体で維持し、検索をパーソナライズできます。MDSの使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。
問合せ検索フォームは、複雑なトランザクション検索を行うための標準フォームです。それぞれに組込み演算子のドロップダウン・リストを保持する複数の検索基準フィールドがある複雑な検索フォームを作成できます。また、カスタム演算子を追加してリストをカスタマイズすることもできます。問合せ検索フォームでは、値リスト、AND結合とOR結合、および将来使用するための検索の保存がサポートされています。
問合せは、問合せ操作で使用するビュー・オブジェクトに関連付けられています。特に、問合せコンポーネントは、ビュー・オブジェクトに定義されたビュー基準を図示したものです。ビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。ビュー基準で定義されたビュー基準アイテムは、問合せコンポーネントの検索パネルの検索基準のソースとなります。ビュー基準エディタの「表示されたモード」オプションにより、表示される検索基準を制御します。
検索基準は、属性の論理的なグループを指定するために、グループ化できます。たとえば、アドレスの属性を1つにグループ化できます。
問合せ検索フォームには基本モードと詳細モードがあります。ユーザーは「基本」ボタンまたは「詳細」ボタンを使用して、2つのモードを切り替えることができます。設計時にフォーム・プロパティを宣言的に指定(デフォルトの状態を設定するなど)して、基本または詳細のいずれかにすることができます。図36-4に、3つの検索基準を含む詳細モードの問合せ検索フォームを示します。
図36-4 詳細モードの問合せ検索フォーム
詳細モードの問合せフォームに含まれる機能は次のとおりです。
ドロップダウン・リストからの検索基準演算子の選択
カスタム演算子の追加と標準演算子の削除
WHERE句の結合におけるANDまたはOR(すべてに一致またはいずれかに一致)の選択
実行時の検索基準フィールドの動的な追加および削除
将来使用するための検索の保存
保存済の検索のパーソナライズ
通常、問合せ検索フォームはいずれかのモードで、関連付けられた結果表またはツリー表とともに使用します。Oracle ADFのSummitサンプル・アプリケーションでは、問合せパネルと結果表が図36-5のように表示されます。
図36-5 問合せ検索の結果表
基本モードには、ユーザーによる動的な検索基準フィールドの追加以外の詳細モードのすべての機能が含まれます。図36-6に、3つの検索基準フィールドを含む基本モードの問合せ検索フォームを示します。詳細モードで検索基準フィールドの追加に使用される、「保存」ボタンの隣のドロップダウン・リストがないことに注意してください。
図36-6 3つの検索基準フィールドを含む基本モードの問合せフォーム
どちらのモードでも、Greater ThanおよびEqual Toなどの演算子をドロップダウン・リストから選択して各検索基準フィールドを変更できます。また、「すべてに一致」または「いずれかに一致」ラジオ・ボタンを使用して検索パネル全体を変更できます。検索フォームでは、ほとんどすべての状況下で部分ページ・レンダリングもサポートされています。たとえば、「Between」演算子を選択した場合、別の入力フィールドが表示され、範囲の上限を選択できるようになります。
「すべてに一致」を選択すると、問合せのWHERE句の検索基準において暗黙的にAND結合が使用されます。「いずれかに一致」を選択すると、問合せのWHERE句において暗黙的にOR結合が使用されます。これは、図36-4に示した検索基準で「すべてに一致」が選択された場合の簡略化されたWHERE句です(ビュー基準の実際のWHERE句は異なります)。
WHERE (Id < 4) AND (InStock > 20) AND (Name="Shoes")
これは、図36-4に示した検索基準で「いずれかに一致」が選択された場合の簡略化されたWHERE句です。
WHERE (Id < 4) OR (InStock > 20) OR (Name="Shoes")
問合せのビュー基準の基準アイテム間でAND結合およびOR結合が混在している場合、コンポーネントが最初にレンダリングされるときには「すべてに一致」および「いずれかに一致」のいずれも選択されません。しかし、「すべてに一致」または「いずれかに一致」を選択して、ビュー基準に初期状態として定義された結合をオーバーライドできます。
詳細モードの問合せフォームでは、より複雑な問合せを実行するために、ユーザーは問合せパネルに検索基準フィールドを動的に追加できます。ユーザーが作成した検索基準フィールドは削除できますが、ユーザーは既存のフィールドを削除できません。「フィールドの追加」ドロップダウン・リストを使用すると、1つの検索基準フィールドまたはグループに含まれるすべてのフィールドを追加できます。
図36-7に、問合せ検索フォームと、「フィールドの追加」ドロップダウン・リストを選択して、検索フォームに基準フィールドを追加する方法を示します。
図36-7 実行時の検索基準フィールドの動的な追加
図36-8に、新しいユーザー追加の検索基準がある問合せ検索フォームを示します。その右側には削除アイコンがあります。削除アイコンをクリックすると条件を削除できます。
図36-8 削除アイコンがあるユーザー追加の検索基準
図36-9に示すように、「並替え」ボタンを使用して、「検索フィールドの並替え」ダイアログを開き、検索パネルの検索フィールドを並べ替えることができます。
図36-9 「検索フィールドの並替え」ダイアログ
「すべてに一致」または「いずれかに一致」が選択されている場合に、ユーザーが検索基準の2つ目のインスタンスを動的に追加すると、「すべてに一致」と「いずれかに一致」はともに選択解除されます。ユーザーは、「検索」ボタンをクリックする前に、「すべてに一致」または「いずれかに一致」を再度選択する必要があります。
問合せ検索フォームに基本モードおよび詳細モードの両方を使用する場合、各検索基準フィールドは、基本モードのみでの表示、詳細モードのみでの表示、両方での表示のいずれかに定義できます。ユーザーがあるモードから別のモードに切り替えると、そのモードに定義された検索基準フィールドのみが表示されます。たとえば、基本モード用にA、B、Cの3つの検索フィールドを、詳細モード用にA、B、Dの3つの検索フィールドを問合せに定義したとします。問合せ検索フォームが基本モードの場合、検索基準フィールドA、B、Cが表示されます。問合せ検索フォームが詳細モードの場合、検索基準フィールドA、B、Dが表示されます。その検索フィールドに入力されたすべての検索データは、フォームがそのモードに戻ったときも保持されています。基本モードにおいてユーザーが検索フィールドCに35と入力し、詳細モードに切り替えた後に再度基本モードに戻ると、フィールドCには値35が入力された状態で再表示されます。
基本または詳細モードを使用するとともに、検索フォームをどの程度表示するかを決定することもできます。デフォルト設定では、フォーム全体が表示されます。圧縮モードまたはシンプル・モードで表示するように、問合せコンポーネントを構成することもできます。圧縮モードでは、ヘッダーや境界線がなく、「保存済の検索」ドロップダウン・リストは開く/閉じるアイコンの横に移動しています。また、「基本」ボタンがフォームの下部に移動され、「検索」ラベルが省略されています。図36-10に、圧縮モードに設定された問合せ検索フォームを示します。
図36-10 コンパクト・モードのqueryコンポーネント
シンプル・モードでは、ヘッダーおよびフッターがなく、通常その領域に表示されるボタンもないコンポーネントが表示されます。図36-11に、単純モードに設定された同じ問合せ検索フォームを示します。
図36-11 簡易モードのqueryコンポーネント
ビュー基準が複数定義されている場合、各ビュー基準は「保存済の検索」ドロップダウン・リストから選択できます。これら保存済の検索は設計時に作成され、システム検索と呼ばれます。たとえば、ビュー・オブジェクトに2つのビュー基準を定義している場合は、図36-12に示すように、問合せ検索フォームで「保存済の検索」ドロップダウン・リストから両方のビュー基準が選択できるようになります。
注意:
問合せパネルの開閉アイコンをクリックしてパネルを開閉しても、適用されたビュー基準はリセットされないことに注意してください。適用されているビュー基準をリセットするには、「リセット」ボタンをクリックします。
図36-12 問合せフォームの「保存済の検索」ドロップダウン・リスト
ビュー・オブジェクトに明示的に定義されたビュー基準が存在しない場合、デフォルトの暗黙的ビュー基準を使用できます。
ユーザーは、検索の状態を将来使用するために、実行時に保存済の検索を作成することもできます。図36-13に示すように、「保存」ボタンをクリックして「検索の保存」ダイアログを開き、入力された検索基準値、基本モードまたは詳細モードの状態、結果の表またはコンポーネントのレイアウトを保存できます。保存済の検索は、「保存済の検索」ドロップダウン・リストにアルファベット順で表示されます。ユーザーが作成した保存済の検索はセッション内で保持されます。保存済の検索を、セッションを超えて使用できるようにするには、保存済の検索を格納するための永続データ・ストアを構成する必要があります。Oracle ADFでは、アクセス制御の対象となるデータソース(MDSなど)を使用できます。MDSの使用方法の詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。
保存済の検索を実行する際には、結果コンポーネントのレイアウトも保存するかどうかを指定できます。保存済の検索を作成し、結果コンポーネントのレイアウトを保存するには、MDSが構成されている必要があります。問合せコンポーネントのsaveResultsLayout属性をalwaysに設定すると、結果コンポーネントのレイアウトが保存されます。saveResultsLayoutをneverに設定すると、レイアウトは保存されません。
<context-param>
<description>Saving results layout</description>
<param-name>oracle.adf.view.rich.query.SAVE_RESULTS_LAYOUT</param-name>
<param-value>true</param-value>
</context-param>
saveResultsLayoutが定義されていない場合は、レイアウトの保存には、web.xmlファイルのアプリケーションレベルのプロパティoracle.adf.view.rich.query.SAVE_RESULTS_LAYOUTがデフォルトで使用されます。oracle.adf.view.rich.query.SAVE_RESULTS_LAYOUTのデフォルト値はtrueです。
ユーザーが保存済の検索のレイアウトに変更を加え、保存せずに続行すると、保存するようにユーザーを促す警告メッセージが表示されます。保存しないと変更は失われます。また、ユーザーが検索フィールドを追加または削除した後、保存せずに続行した場合も、警告メッセージが表示されます。
表36-2に、saveResultsLayoutとSAVE_RESULTS_LAYOUTの値およびそれらの結果実行される処理を示します。レイアウトを保存するには、MDSが構成されている必要があります。
表36-2 結果コンポーネントのレイアウト保存属性
| web.xmlSAVE_RESULT_LAYOUT | 問合せコンポーネントsaveResultsLayout | 結果として生じるアクション |
|---|---|---|
true |
常時 |
レイアウトが保存される |
true |
なし |
保存されない |
true |
未定義 |
レイアウトが保存される |
false |
常時 |
レイアウトが保存される |
false |
なし |
保存されない |
false |
未定義 |
保存されない |
図36-13に、保存済の検索の名前の入力フィールドと、「デフォルトとして設定」および「自動的に実行」のチェックボックス選択がある「保存済の検索の作成」ダイアログを示します。
図36-13 実行時の「保存済の検索」ダイアログ・ウィンドウ
表36-1に、保存済の検索、その作成方式および可用性のシナリオを作成者別に示します。
表36-3 設計時および実行時の保存済の検索
| 作成者 | 設計時にビュー基準として作成 | 実行時に「保存」ボタンを使用して作成 |
|---|---|---|
開発者 |
開発者による保存済の検索(システム検索)は、アプリケーション開発時に作成され、通常はソフトウェア・リリースの一部に含まれます。これらの検索は、設計時にビュー基準として作成されます。通常、アプリケーションのすべてのユーザーが利用可能であり、「保存済の検索」ドロップダウン・リストの下部に表示されます。 |
|
管理者 |
管理者による保存済の検索は、デプロイ前にサイト管理者が作成します。これらの検索は、サイトを一般のエンド・ユーザーが利用可能になる前に作成されます。管理者は、設計時に適切なロールでログインしてJDeveloperを使用し、保存済の検索(またはビュー基準)を作成できます。これらの保存済の検索(またはビュー基準)は、「保存済の検索」ドロップダウン・リストの下部に表示されます。 |
|
エンド・ユーザー |
エンド・ユーザーによる保存済の検索は、実行時に問合せフォームの「保存」ボタンを使用して作成します。これらの検索は、作成したユーザーのみが利用可能です。エンド・ユーザーの保存済の検索は、「保存済の検索」ドロップダウン・リストの最上部に表示されます。 |
プロパティ・インスペクタに記載されているとおりにrunQueryAutomaticallyプロパティを使用して、保存済の検索により問合せが自動的に実行されるかどうかを指定できます。このプロパティをallSavedSearchesに設定すると、すべてのシステムおよびユーザー作成の保存済の検索が、問合せコンポーネントが最初にロードされたとき、保存済の検索に変更が加えられたとき、またはリセット・ボタンが押されたときに自動的に実行されます。runQueryAutomaticallyプロパティをsearchDependentに設定すると、設計時にその特定の問合せを自動的に実行するかどうかを指定できます。searchDependentがデフォルト値です。
runQueryAutomaticallyプロパティがsearchDependentに設定されたユーザー作成の新しい保存済の検索については、図36-13に示すように、「保存済の検索の作成」ダイアログは「自動的に実行」オプションがデフォルトで設定された状態で表示されます。runQueryAutomaticallyプロパティがallSavedSearchesに設定されたユーザー作成の新しい保存済の検索については、「保存済の検索の作成」ダイアログには「自動的に実行」オプションは表示されず、暗黙的に設定されます。
図36-14に示すように、エンド・ユーザーは「保存済の検索」ドロップダウン・リストの「パーソナライズ」機能を使用して「保存済の検索のパーソナライズ」ダイアログを表示し、保存済の検索を管理できます。
エンド・ユーザーは、「パーソナライズ」機能を使用して次の操作を実行できます。
保存済検索の更新。
ユーザーは、検索基準の追加や削除、演算子の更新、値の更新、論理積の修正、および既存の保存済検索名を使用した検索基準の保存(既存の保存済検索をオーバーライドする)を実行できます。
保存済検索の削除(現在アクティブな保存済検索を含む)
ユーザーは、デフォルトの保存済検索を削除できます。この場合、次のUSERレベルの保存済検索がデフォルトになります。
既存の保存済検索の複製
保存済の検索のデフォルトとしての設定
保存済の検索の自動実行の設定
「保存済の検索」ドロップダウン・リストでの保存済の検索の表示または非表示の設定
図36-14 「保存済の検索のパーソナライズ」ダイアログ
注意:
ビュー基準アイテムの値をプログラム的に変更している場合は、ViewCriteria.saveState()メソッドを呼び出して、searchRegionバインディングにより、ビュー基準アイテムの値が設計時に指定された値にリセットされないようにする必要があります。
問合せ検索フォームは、名前付きビュー基準項目を「データ・コントロール」パネルからページにドロップして作成します。ドロップするものとして、検索パネルのみ、検索パネルと結果表、検索パネルとツリー表のいずれかを選択できます。
検索パネルを表とともにドロップすることにした場合、ダイアログでフィルタ処理オプションを選択し、表をフィルタ処理された表にすることができます。
通常は、問合せ検索パネルとともに結果表またはツリー表をドロップします。JDeveloperでは、結果表またはツリー表が自動的に作成され、問合せパネルと関連付けられます。
問合せパネルのみをドロップし、結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、問合せパネルのResultsComponentIdと結果コンポーネントのIdを一致させる必要があります。
注意:
名前付きビュー基準をページにドロップすると、そのビュー基準は最初の検索フォームのベースとなります。そのデータ・コレクションに定義された他のすべてのビュー基準も「保存済の検索」ドロップダウン・リストに表示されます。その後、ユーザーは、任意のビュー基準検索フォームとエンド・ユーザーが作成した任意の保存済の検索を選択できます。
検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「問合せ検索フォームの作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクトを作成します。ビュー・オブジェクトの詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」および「結合問合せ結果での複数表の使用」を参照してください。
ビュー基準に基づいて検索フォームを作成する場合は、ビュー基準を作成します。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。ビュー基準の詳細は、「名前付きビュー基準の処理」を参照してください。
検索フォームのデフォルトのプロパティを設定します。検索フォームのデフォルト状態の設定の詳細は、「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、「名前付きビュー基準の処理」を参照してください。
結果表またはツリー表付きの問合せ検索フォームを作成するには:
図36-15 「データ・コントロール」パネルの「問合せ」ポップアップ・メニュー
フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。これを行う方法の詳細は、「検索フォーム・プロパティの設定」を参照してください。
検索フォームを作成するには、ビュー基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップします。結果表付きとするか、問合せパネルのみとするかを選択できます。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「問合せ検索フォームの作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクトを作成します。
ビュー基準に基づいて検索フォームを作成する場合は、ビュー基準を作成します。コレクションに問合せ可能なすべての属性を含む暗黙的ビュー基準を使用することもできます。
検索フォームのデフォルトのプロパティを設定します。検索フォームのデフォルト状態の設定の詳細は、「ビュー基準に検索フォーム・プロパティを設定する方法」を参照してください。ビュー基準の作成方法の詳細は、「名前付きビュー基準の処理」を参照してください。
問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加するには:
検索フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。詳細は、「検索フォーム・プロパティの設定」を参照してください。
保存済の検索をMDSに保存するには、adf-config.xmlファイルに/persdefネームスペースを定義する必要があります。また、metadatapathの指定など、通常のMDS構成を行うことも必要です。次の例は、/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の設定の詳細は、「カスタマイズ・クラスの作成方法」を参照してください。
結果コンポーネントのレイアウトも保存する場合は、アプリケーションにADF PageFlow RuntimeライブラリとADF Controller Runtimeライブラリをインストールしておく必要があります。プロジェクトのテクノロジ・スコープにADFページ・フローが含まれるように設定するか、ADF Page Flowアプリケーションのアプリケーション・テンプレートを使用して、これらのライブラリを自動的にインクルードします。
検索フォームで使用されるビュー基準でリテラル・オペランドを指定するかわりに、名前付きバインド変数を指定できます。名前付きバインド変数は、実行時に値が変化するパラメータのような動作をします。SQL文を変更する必要はありません。この変数をビュー基準で使用するには、まず、ビュー・オブジェクトで定義する必要があります。
ビュー基準でリテラル・オペランドを指定したときに、この値を空白のままにしておくと、SQLプレビューには表示されません。実行時に検索フォームとしてビュー基準を適用すると、その属性は空の入力検索フィールドとしてレンダリングされます。このリテラル・オペランドに対する値を指定した場合、SQLプレビューにより、このオペランドに対応したSQL句が生成されます。実行時に検索フォームとしてビュー基準が適用されたとき、ビュー基準で指定した値が入力検索フィールドに表示されたとしても、SQL文は自動的に適用されません。ユーザーが「検索」をクリックするまで(または、auto-executeがtrueに設定されるまで)、このSQL文は適用されません。
ビュー基準で定義された問合せで名前付きバインド変数が使用された場合、SQLプレビューには、バインド変数とともにWHERE句が表示されます。実行時に検索フォームとしてビュー基準が適用された場合、バインド変数名ではなく、属性名に基づいて、バインド変数がプロンプトおよび入力検索フィールドとともにレンダリングされます。名前付きバインド変数の入力フィールドは、NULL値、デフォルト値、別のページから受け取った値など以前の処理でロードされた値のいずれかの状態となります。ユーザーは他の検索基準と同様に、名前付きバインド変数の値を入力できます。検索を実行すると、名前付きバインド変数の値は、SQL問合せ文で定義したように他の基準で評価されます。
注意:
リテラル値での検索フォームのSQLインジェクションの可能性を回避するために、adf-config.xmlファイルのuseBindVarsForViewCriteriaLiteralsプロパティをtrueに設定して、すべての入力検索フィールドでバインド変数を強制的に使用できます。デフォルト値はtrue。trueに設定されている場合、アプリケーションの入力検索フィールドは、問合せコンポーネントの関連ビュー基準に基づいてリテラル・オペランドによって定義されたデフォルト値を表示します。
adf-config.xmlファイルの詳細は、「adf-config.xml」を参照してください。
概要エディタを使用して、このプロパティを編集することもできます。adf-config.xmlの概要エディタで、「モデル」タブをクリックするか、「ViewCriteriaリテラルにバインド変数を使用」チェックボックスを選択または選択解除します。
バインド変数が同じビュー基準で複数回使用されている場合、バインド変数は出現するたびに、1つの入力フィールドとしてレンダリングされます。すべての入力フィールドの背後にはバインド変数が1つしかありませんから、すべてのフィールドの値が同期されます。たとえば、同じバインド変数を3回使用するビュー基準を指定した場合、3つの入力フィールドがレンダリングされます。ユーザーが1つの入力フィールドに値を入力すると、その他2つの入力フィールドにも同じ値が入ります。このようにバインド変数を使用すると、ユーザーは同じ値を何回も入力する必要がなくなります。
バインド変数は、ベース行からLOV検索フォームの検索に値を渡すためにも使用できます。
また、たとえば、顧客IDを別のページに渡して、さらに詳細な処理をする場合など、あるページから別のページにパラメータ値を渡すときにもバインド変数を使用できます。さらに、SQL文の構成によっては、名前付きバインド変数を使用すると、新しい文を準備する必要が少なくなる、つまりデータベースを再解析する必要がなくなるため、問合せの速度が向上する可能性があります。名前付きバインド変数の作成および使用の詳細は、「バインド変数の使用」を参照してください。
たとえば、listCustomerAddressesビュー基準のWHERE句は、AssociatedOwnerIdがparamCustomerId名前付きバインド変数の値と同じであるかどうかを確認します。このビュー基準は、AddressesLookupVOビュー・オブジェクト内にあります。図36-16に、「ビュー基準の編集」で定義したlistCustomerAddressesビュー基準を示します。
図36-16 名前付きバインド変数のあるビュー基準
名前付きバインド変数のあるビュー基準の問合せ検索フォームは、inputTextコンポーネントを使用してその変数の検索フィールド付きでレンダリングされます。図36-17は、inputTextコンポーネントとして表示されているAssociatedOwnerId検索フィールドを示しています。
図36-17 名前付きバインド変数がある問合せ検索フォーム
検索バインディングは、実行時、検索フォームに対してモデルドリブンの動作を提供します。検索バインディングは、特定のイテレータ、およびそのイテレータのビュー基準に関連付けられていて、その実行時デフォルトはそれぞれ、検索バインディングの「バインド」プロパティと「基準」プロパティで指定されます。検索バインディングの動作は、「自動的に問合せ」コントロールのヒントによって異なります。名前付きビュー基準の作成の詳細は、「名前付きビュー基準の処理」を参照してください。
タスク・フローで初めて検索フォームがレンダリングされたときの検索バインディングの実行時の動作(初期の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に変更できます。詳細は、「問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。
ページ定義ファイルのexecutablesセクションに、iteratorおよびsearchRegionエントリが作成されます。次の例は、ページ定義ファイルのサンプル・コードを示しています。このコードは、BackOfficeAppModuleDataControlのCustomersコレクションから、CustomerViewCriteriaをページにドロップしたときに作成されます。
ページ定義ファイルのexecutableセクションでは、プロパティが次のように設定されます。
イテレータbindsプロパティはデータ・コレクション名に設定します。この例では、この値にCustomersを設定します。
イテレータidプロパティはデータ・コレクション・イテレータに設定します。この例では、この値にCustomersIteratorを設定します。
そのデータ・コレクションについて、複数のビュー基準が定義されている場合、searchRegion Criteriaプロパティは、ドロップされたビュー基準の名前に設定されます。この例では、この値にCustomerViewCriteriaを設定します。定義されているビュー基準が1つのみの場合、Criteriaプロパティはありません。
searchRegionのBindsプロパティは、iterator idプロパティと同じ値に設定されます。この例では、この値にCustomersIteratorを設定します。
searchRegionのidプロパティには、ビュー基準とQueryを連結した名前が設定されます。この例では、この値にCustomerViewCriteriaを設定します。
問合せを表またはツリーとともにページにドロップした場合は、ページ定義ファイルのbindingsセクションにtree要素が追加され、Iterbindingプロパティが検索イテレータに設定されます。この例では、この値にCustomersIteratorを設定します。これは、executableセクションで定義されたイテレータと同じものでなければなりません。
<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel" version="12.1.2.66.41" id="searchPageDef"
Package="oracle.summit.view.pageDefs">
<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="Customers" RangeSize="25"
DataControl="BackOfficeAppModuleDataControl" id="CustomersIterator"/>
<searchRegion Criteria="CustomerViewCriteria"
Customizer="oracle.jbo.uicli.binding.JUSearchBindingCustomizer"
Binds="CustomersIterator" id="CustomerViewCriteriaQuery"/>
</executables>
<bindings>
<tree IterBinding="CustomersIterator" id="Customers">
<nodeDefinition DefName="oracle.summit.model.views.CustomerVO"
Name="Customers0">
<AttrNames>
<Item Value="Id"/>
<Item Value="Name"/>
<Item Value="City"/>
<Item Value="State"/>
<Item Value="CountryId"/>
<Item Value="LastName"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>
</pageDefinition>
実行時には、検索フォームはページ上の検索パネルとして表示されます。検索パネルは、対応するビュー基準が作成されたときのモードのコントロール・ヒントに応じて、基本モードまたは詳細モードのいずれかで表示されます。「保存済の検索」ドロップダウン・リストには、有効(「リストに表示」コントロール・ヒントが有効)なビュー基準がすべて含まれます。「すべてに一致」または「いずれかに一致」結合ラジオ・ボタンが有効化されることがあります。
検索基準フィールドは、ビュー基準に定義された検索基準ごとにレンダリングされます。ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは表36-1に示すようになります。
ユーザーが検索基準を入力して「検索」をクリックすると、ビュー基準に対する問合せが実行され、関連付けられた表、ツリー表またはコンポーネントに結果が表示されます。
問合せ検索フォームは、ビュー・オブジェクトで定義されたビュー基準に基づいています。ビュー基準の作成時には、検索フォーム・プロパティの一部も指定します。後で名前付き基準をページにドロップして問合せコンポーネントを作成する場合、その他の検索フォーム・プロパティも指定できます。
ビュー・オブジェクトに対して設定可能な検索フォームのプロパティには、問合せパネルでの関連フィールドと依存フィールドのグループ化も含まれています。ビュー・オブジェクトでのヒント設定の詳細は、「UIカテゴリ・ヒントを定義する方法」を参照してください。
ビュー基準の作成時に設定可能な検索フォーム・プロパティは、次のとおりです。
基本モードまたは詳細モードのデフォルトのモード
ページのロード時の自動問合せ実行
検索基準フィールドのレンダリング
LOVとして定義された属性の複数選択を有効化
問合せコンポーネントがJSFページに追加された後に設定可能な検索フォーム・プロパティは、次のとおりです。
結果表または結果コンポーネントのid
「基本」ボタンまたは「詳細」ボタンの表示または非表示
モード・ボタンの位置
デフォルト、シンプルまたは圧縮の表示モード
ビュー・オブジェクトの作成時に設定可能な検索フォーム属性プロパティは、次のとおりです。
timestamp属性に対するtimezoneコントロール・ヒント
ビュー基準の作成時に、複数のプロパティの初期状態を宣言的に設定できます。図36-18に、デフォルト・オプションの設定に使用する「ビュー基準の編集」ダイアログを示します。ビュー基準の詳細は、「名前付きビュー基準の処理」を参照してください。
図36-18 「ビュー基準の作成」ダイアログ
問合せ検索フォームのデフォルト・モードとして「基本」または「詳細」のいずれかを選択する必要があります。デフォルトは「基本」です。
また、個々の検索基準フィールドが使用できるのは、基本モードのみ、詳細モードのみ、両方のモードのいずれか、あるいは表示しないかを宣言する必要があります。検索基準フィールドが「基本」モードのみで宣言されている場合、ユーザーが「詳細」モードに切り替えた場合は表示されず、逆も同様です。フィールドが両方のモードに対して宣言されている場合、両方のモードで表示されます。検索基準フィールドのレンダリングのデフォルトは、すべてのモードです。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
次のタスクを完了する必要があります。
デフォルト・モードと検索基準フィールドの表示オプションを設定するには:
問合せ検索フォームをページにドロップした後に、「プロパティ」ウィンドウで他のフォーム・プロパティを編集できます(図36-19を参照)。次のような共通プロパティを設定できます。
「基本」または「詳細」モード・ボタンの有効化または無効化
問合せ検索フォームのIDの設定
結果表などの結果コンポーネントのIDの設定
デフォルト、シンプルまたは圧縮の表示モードの選択
criterionFeaturesの設定。すべての文字列ベースの検索基準で大/小文字を区別するにはmatchCaseDisplayedに、すべての基準を表示するにはrequiredDisplayedに設定します。
図36-19 「問合せ」コンポーネントの「プロパティ」ウィンドウ
一般的なオプションの1つに、「基本」または「詳細」ボタンの表示または非表示があります。その他のいくつかのプロパティの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の問合せコンポーネントの追加方法に関する項を参照してください
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
問合せフォームで「基本」または「詳細」ボタンを有効化または非表示にするには:
問合せにDate属性が含まれる場合、その属性が定義されているビュー・オブジェクトまたはエンティティ・オブジェクトのコントロール・ヒントを使用してそのtimezoneを設定できます。たとえば、従業員のHiredateに対して、従業員が勤める支社に応じた適切なtimezoneを設定できます。
始める前に:
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。
コントロール・ヒントを使用してビュー・オブジェクトのtimestamp属性をカスタマイズするには:
ビュー・オブジェクトXMLファイルにコードを追加すると、各ビュー基準項目にカスタム演算子を作成できます。たとえば、日付属性を処理するmore than a year(現在の日から365日後)という演算子を新規に作成できます。
ビュー・オブジェクトの属性に応じたカスタム演算子を追加するには、その属性用のコードをビュー・オブジェクトのXMLファイルに追加します。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
カスタム演算子を追加するには:
例36-1 ビュー・オブジェクト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>
例36-2 メッセージ・バンドルへのLastUpdateDateのカスタム演算子のエントリの追加
public class AvailLangImplMsgBundle extends JboResourceBundle {
static final Object[][] sMessageStrings =
{
{ "LastUpdateDate_custOp_grt_year", "more than a year old"
},
ビュー基準アイテムから、標準演算子を削除できます。たとえば、標準演算子であるbeforeをリストから削除できます。
標準演算子のリストは、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。
ビュー・オブジェクトの属性に応じた標準演算子を削除するには、その属性用のコードをビュー・オブジェクトのXMLファイルに追加します。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「検索フォーム・プロパティの設定」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
標準演算子を削除するには:
クイック問合せ検索フォームは、単一検索で十分な場合、またはフル問合せ検索を行うための起点とする場合に使用します。問合せ検索フォームおよびクイック問合せ検索フォームはどちらもADF Facesコンポーネントです。クイック問合せ検索フォームには、関連するデータ・コレクションから利用可能な検索可能属性のドロップダウン・リストとともに検索基準フィールドが1つ含まれます。通常は、関連するビュー・オブジェクトのすべての属性が検索可能属性となります。「属性の編集」ダイアログの「コントロール・ヒント」ページで、属性の「ヒントの表示」プロパティを「非表示」に設定して、属性を除外できます。ユーザーは、選択された属性または表示されるすべての属性に対して検索を実行できます。検索基準フィールド・タイプは対応する属性タイプに自動的に一致します。フォームに組み込まれた「詳細」リンクを使用すると、開発者はクイック問合せ検索フォームから詳細モードの問合せ検索フォームへの切替えを制御するマネージドBeanを作成できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。
図36-20に示すように、フォームが水平方向レイアウトとなるように構成できます。
図36-20 水平方向レイアウトのクイック問合せ検索フォーム
図36-21に示すように、垂直方向レイアウトも選択できます。
図36-21 垂直方向レイアウトのクイック問合せ検索フォーム
クイック問合せ検索フォームを使用すると、ユーザーによるコレクションの単一属性の検索が可能になります。クイック問合せ検索フォームのレイアウトは、水平または垂直に設定できます。クイック問合せ検索フォームは小さい領域のみを使用するため、ページの様々な領域に配置できます。ユーザーによるクイック問合せ検索からフル問合せ検索への切替えを可能にするマネージドBeanを作成できます。クイック問合せからマネージドBeanを使用した問合せに切り替える方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。
「結果表またはツリー表付きのクイック問合せ検索フォームの作成方法」で説明しているように、結果表またはツリー付きのクイック問合せパネルをドロップした場合、結果表が自動的に作成されます。「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」で説明しているように、クイック問合せパネルのみをドロップした後に結果表または結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、クイック問合せのIdと結果コンポーネントのpartialTrigger値を一致させる必要があります。
注意:
クイック問合せ検索は、基礎となるビュー・オブジェクトで定義されたすべての検索可能な属性のドロップダウン・リストを作成します。それらの属性の一部のみを表示する場合は、除外する属性の「表示」コントロール・ヒントを「非表示」に設定できます。ビュー・オブジェクトのコントロール・ヒントの設定の詳細は、「ビュー・オブジェクトを使用したSQL問合せの定義」を参照してください。
検索可能な属性の完全セットを使用してクイック問合せ検索を作成すると同時に、表またはツリー表を結果コンポーネントとして追加できます。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
次のタスクを完了する必要があります。
結果表付きのクイック問合せ検索フォームを作成するには:
図36-22 「データ・コントロール・パネル」パネルの「クイック問合せ」ポップアップ・メニュー
検索可能な属性の完全セットを使用してクイック問合せ検索を作成した後で、表またはツリー表を結果コンポーネントとして追加できます。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
次のタスクを完了する必要があります。
クイック問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加するには:
デフォルトのレイアウト書式は垂直方向です。レイアウト・オプションは、「プロパティ」ウィンドウで変更できます。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「クイック問合せ検索フォームの作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
レイアウトを設定するには:
クイック問合せ検索フォームをページにドロップすると、JDeveloperはaf:quickQueryタグを作成します。クイック問合せと表またはツリー表をドロップした場合、af:tableタグまたはaf:treeTableタグも追加されます。
af:quickQueryタグの下にはクイック問合せのプロパティを定義する複数の属性およびファセットがあります。タグの一部は次のとおりです。
クイック問合せを一意に識別するid属性。この値は結果表または結果コンポーネントのpartialTriggers値に一致するように設定する必要があります。クイック問合せと表またはツリー表をドロップすると、JDeveloperはこれらの値を自動的に割り当てます。別の結果コンポーネントに変更する方法は、「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。
クイック問合せのレイアウトをデフォルト、水平または垂直に指定するlayout属性。
「詳細」リンク(クイック問合せから問合せにモードを変更)の表示に使用するコンポーネントを指定するendファセット。この機能の作成の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。
実行時に、クイック問合せ検索フォームには、単一の検索基準フィールドが選択可能な検索基準アイテムのドロップダウン・リストとともに表示されます。検索可能な基準アイテムが1つしかない場合、ドロップダウン・リスト・ボックスはレンダリングされません。表36-4に示すように、選択した検索基準タイプと互換性のある入力コンポーネントが表示されます。たとえば、検索基準タイプがDATEの場合、inputDateがレンダリングされます。
表36-4 クイック問合せ検索基準フィールド・コンポーネント
| 属性タイプ | レンダリングされるコンポーネント |
|---|---|
|
|
|
|
|
|
ビュー・オブジェクトの「デフォルトのリスト・タイプ」コントロール・ヒントがLOVまたは選択リスト・コンポーネントとして宣言されている場合、検索基準フィールド・コンポーネントは「値リスト(LOV)入力フィールド」の表36-1に示すようになります。
また、「検索」ボタンが入力フィールドの右側にレンダリングされます。endファセットを指定すると、endファセットのコンポーネントはすべて表示されます。デフォルトでは、endファセットには「詳細」リンクが含まれます。
フィルタ処理された表はスタンドアロンとして作成することも、問合せ検索フォームまたはクイック問合せ検索フォームの結果表として作成することもできます。フィルタ処理された表の検索はQuery-by-Exampleに基づいており、QBEテキストまたは日付入力フィールド書式を使用します。検索基準の変更では>および<=などの文字を入力できるようにするため、入力バリデータは無効になっています。たとえば、数値列の検索基準として、>1500と入力できます。ワイルドカード文字もサポートされます。列がQBEをサポートしていない場合、検索基準入力フィールドはその列に対してレンダリングを行いません。レンダリングされる入力フィールドは属性のデータ型により決まります。たとえば、日付列には日付ピッカー・コンポーネントがレンダリングされ、値リストとして定義されている属性に対する列には対応する値リスト・コンポーネントがレンダリングされます。
フィルタ処理された表の検索基準入力値は、問合せのWHERE句を作成するためにAND演算子とともに使用されます。フィルタ処理された表が問合せ検索パネルまたはクイック問合せ検索パネルと関連付けられている場合、複合検索基準値も組み合せてWHERE句を作成します。
注意:
フィルタ処理された表を問合せコンポーネントとともに検索フォームで使用し、検索リージョンで既存の名前付き基準を使用している場合、問合せの結果はすべてのビュー基準行によって繰り返しフィルタ処理されます。たとえば、あるフィルタ処理済の表にPersonIdとDeptIdの2つのビュー基準行があるとします。最初のビュー基準行にはPersonId > 1が含まれています。ユーザーがフィルタ・フィールドに「> 100」と入力すると、2つ目のビュー基準行DeptIdを使用して、入力値の受け入れと、その後の結果のフィルタ処理が行われます。この処理は、最終的な問合せ結果に達するまですべてのビュー基準行に対して繰り返されます。
図36-23に、フィルタ処理された表を示します。ユーザーが、Idフィールドに>10などのQBE検索基準を入力すると、問合せの結果は、問合せ検索基準とフィルタ処理された表の検索基準のAND結合となります。
図36-23 フィルタ処理された表
表36-5に、検索値を変更するために使用可能なQBE検索演算子を示します。
表36-5 Query-by-Example検索基準演算子
| 演算子 | 説明 |
|---|---|
|
次より大きい |
|
次より小さい |
|
以上 |
|
以下 |
|
および |
|
または |
|
次と等しい |
|
次を含まない |
|
次を含まない |
複雑な検索では問合せ検索フォームを使用しますが、フィルタ処理された表を使用して単純なQBE検索を実行することもできます。関連付けられた検索パネルのないスタンドアロンのADFのフィルタ処理された表を作成し、QBE形式の検索基準入力フィールドを使用して検索を実行できます。フィルタ処理された表の詳細は、「フィルタ処理された表と例示問合せ検索の作成方法」を参照してください。
af:tableコンポーネントのaf:columnのfilterFeature属性を使用すると、フィルタ処理可能な各列のQBE検索基準において、大文字と小文字を区別するかどうかを設定できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表でのフィルタ処理の有効化に関する項を参照してください。
表の作成時に、フィルタ処理オプションが有効な場合にそのオプションを選択すると、ほとんどすべての表をフィルタ処理された表にできます。スタンドアロンのフィルタ処理された表を作成するには、次の3つの方法があります。
「コンポーネント」ウィンドウからページに表をドロップして、その表をデータ・コレクションにバインドしてから、フィルタ処理オプションを設定できます。詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「問合せコンポーネントの使用方法」を参照してください。
データ・コレクションをページにドラッグ・アンド・ドロップしてフィルタ処理オプションを設定すると、フィルタ処理された表を作成できます。詳細は、「基本表の作成方法」を参照してください。
名前付き基準をページにドロップし、フィルタ処理された表または読取り専用のフィルタ処理された表を作成することもできます。暗黙的に作成された名前付き基準のAll Queriable Attributes、または宣言的に作成された名前付きビュー基準のどちらも使用できます。作成されるフィルタ処理された表には、検索可能属性のそれぞれに対応する列があり、各列の上に入力検索フィールドがあります。
始める前に:
問合せ検索フォームの作成時には使用可能なオプションに関する知識が役立つ場合があります。詳細は、「スタンドアロンのフィルタ処理された検索表を名前付きビュー基準から作成」を参照してください。
問合せ検索フォームと併用可能な機能についても理解しておくと役立ちます。詳細は、「検索フォームの追加機能」を参照してください。
名前付きビュー基準を使用してフィルタ処理された表を作成するには:
図36-24 フィルタ処理された表の「表の列の編集」ダイアログ
