| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
|
前 |
次 |
この章の内容は次のとおりです。
Oracle ADFビュー・オブジェクトを使用して、SQL問合せのカプセル化およびADFアプリケーション・モジュールのデータ・モデルを構築します。
ビュー・オブジェクトは、SQL問合せをカプセル化しその結果の作業を簡略化するOracle Application Development Framework (Oracle ADF)コンポーネントです。データ・モデル・プロジェクトで作成できるビュー・オブジェクトにはいくつかのタイプがあります。
データの更新を実行またはデータの読取りのみを行う場合のエンティティ・ベースのビュー・オブジェクト
エンティティ・オブジェクトによるサポートがない場合の、エンティティに基づかないビュー・オブジェクト(エンティティ・オブジェクトの慣用名が定義されていないビュー・オブジェクトは常に読取り専用です)
ビュー・オブジェクト自体によって定義されるデータに対する静的データ・ビュー・オブジェクト
プログラムで移入されたビュー・オブジェクト(「代替データソースに対するプログラムでのビュー・オブジェクトの使用」を参照)
エンティティ・ベースのビュー・オブジェクトでは、その属性が1つ以上の既存エンティティ・オブジェクトの属性とマップされるビュー・オブジェクトを作成する際に、更新可能な行をサポートするように構成できます。マッピングされたエンティティ・オブジェクトは、ビュー・オブジェクト定義にエンティティ・オブジェクトの慣用名として保存されます。このように、エンティティ・ベースのビュー・オブジェクトでは、エンティティ・オブジェクトと自動的に連携することにより、完全に更新可能なデータ・モデルが実現します。エンティティ・ベースのビュー・オブジェクトの慣用名では、クライアント側のタスクに必要なデータのみを問い合せ、マップされたエンティティ・オブジェクトとその行のエンティティ・キャッシュを活用してビュー行に対する変更を自動的に検証および保存します。エンティティ・ベースのビュー・オブジェクトは、SQL問合せをカプセル化し、マスター/ディテール階層にリンクしたり、アプリケーション・モジュールのデータ・モデルで使用できます。問い合せたデータに対する更新は、基礎となるエンティティ・キャッシュによって管理されます。これにより、同じエンティティ・オブジェクトに基づく各ビュー・オブジェクトの慣用名は、重複データをその慣用名に格納するのではなく、行のエンティティ・キャッシュをポイントするようになります。
エンティティ・ベースのビュー・オブジェクトとは異なり、エンティティのないビュー・オブジェクトでは、SQL問合せ言語を使用して問合せを記述する必要があります。エンティティを基礎としないビュー・オブジェクトにはエンティティから導出されたデフォルト値は使用されず、保留中の変更および更新された参照情報は反映されません。一方、エンティティ・ベースのビュー・オブジェクトでは、「ビュー・オブジェクトの作成」ウィザードおよび概要エディタを使用してSQL問合せを宣言的に構成できるため、問合せの記述が容易です。さらに、エンティティ・ベースのビュー・オブジェクトは、エンティティ・キャッシュを使用して問い合せたデータを管理するため、ビュー・オブジェクトの行キャッシュに対する更新に特別なランタイム処理を必要とする、エンティティ・オブジェクトの慣用名を持たないビュー・オブジェクトよりも、パフォーマンスが高くなります。そのため、ほとんどの場合は、データの読取りにのみ使用するビュー・オブジェクトを作成するときでも、エンティティにマップされたビュー・オブジェクトを作成することをお薦めします。
ただし、状況によっては、SQLベースの検証、UNION、GROUP BY問合せなど、エンティティにマップされていないビュー・オブジェクトを作成してデータの読取りに使用する方が適切な場合もあります。この場合、エンティティ・オブジェクトの慣用名が定義されていないビュー・オブジェクトは常に読取り専用であることに注意してください。
設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、SQL文を含まないエンティティ・ベースのビュー・オブジェクトを作成することもできます。ADFビジネス・コンポーネントの設計時および実行時のこの機能は、宣言SQLモードと呼ばれます。ビュー・オブジェクト用のウィザードやエディタを宣言SQLモードで使用する場合、ビジネス・コンポーネント開発者にSQLの知識は必要ありません。宣言SQLモードでは、ランタイムの問合せ文はデータバインドされたUIコンポーネント内の属性の使用方法のみに基づいたものになります。
ビュー・オブジェクトに基礎となるエンティティ・オブジェクトの慣用名が1つ以上ある場合、新しい行の作成や、問合せ結果の行の変更または削除が可能です。エンティティ・ベースのビュー・オブジェクトは基礎となるエンティティ・オブジェクトと連携して、ビジネス・ルールを適用し、データベースに対する変更を永続的に保存します。また、エンティティ・ベースのビュー・オブジェクトは、エンティティのないビュー・オブジェクトにはない次のような機能を備えています。
エンティティで管理されるキャッシュ内の変更(更新、挿入、削除)は、ビュー・オブジェクトの実行後も保持されます。
同じトランザクションの他のビュー・オブジェクトを介して行われた、関連するエンティティ・オブジェクト属性に対する変更は即時に反映されます。
新しい行の属性値は、基礎となるエンティティ・オブジェクト属性の値で初期化されます。
外部キー属性値が変更されると、参照情報が更新されます。
行(エンティティ)レベルの検証がサポートされています。
検証、ロック、順序付けられた更新などのコンポジット機能がサポートされています。
有効日指定、更新識別子およびビジネス・イベントがサポートされています。
この章では、図5-1に示すようなビュー・オブジェクトの概念についてわかりやすく説明します。
SQL問合せを作成する(明示的または宣言的に定義する)ことによりビュー・オブジェクトを定義します。
ビュー・オブジェクト・インスタンスは、問合せのデータベース・トランザクションを提供するアプリケーション・モジュールと関連して使用します。
ビュー・オブジェクトを1つ以上の他のビュー・オブジェクトにリンクして、マスター/ディテール階層を作成できます。
実行時には、ビュー・オブジェクトにより問合せが実行され、(RowSetオブジェクトで表される)行セットが生成されます。
各行は、対応する行キーによって識別されます。
行セット・イテレータを使用して、行セットの行を反復します。
一連のQuery-By-Example基準行を適用すると、ビュー・オブジェクトにより生成される行セットをフィルタリングできます。
この章では、アプリケーション・モジュールのデータ・モデルでエンティティ・ベースのビュー・オブジェクトのインスタンスを使用して、再使用可能なビジネス・ドメイン・オブジェクトが持つ明確なオブジェクト指向カプセル化能力にSQLの完全なデータ形成能力を組み合せることにより、クライアントがビジネス・サービス・レイヤー情報を検索、更新、挿入および削除できるようにする方法について説明します。また、これらすべての作業についてコード行は必要ありません。この章では、図5-2に示すように、エンティティ・ベースのビュー・オブジェクトの概念についてわかりやすく説明します。
更新可能なビュー・オブジェクトは、1つ以上のエンティティ・オブジェクトの属性を参照して定義します。
関連付けられた複数のエンティティ・オブジェクトを使用することにより、参照情報の操作を簡略化できます。
基礎となるエンティティ・アソシエーションに基づいてビュー・リンクを定義できます。
エンティティ・ベースのビュー・オブジェクトは、トランザクションを提供するアプリケーション・モジュールとの関連で使用します。
実行時に、ビュー行は、属性の格納および検証を基礎となるエンティティ・オブジェクトに委譲します。
図5-2 ビュー・オブジェクトとエンティティ・オブジェクトの連携による更新可能なデータ・モデルの有効化
ビュー・オブジェクトで作業を開始する前に、その他のOracle ADF機能を理解しておくと役に立つ場合があります。次に、関連する他の機能へのリンクを示します。
ビュー・オブジェクト定義で式がサポートされている場所でGroovyスクリプトを使用する方法の詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。
対話型のOracle ADFモデル・テスターを使用して、ビュー・オブジェクトの問合せ結果を検証する方法の詳細は、「ビュー・インスタンスの問合せのテスト」を参照してください。
エンティティ・ベースのビュー・オブジェクトを含むトランザクションでエンティティ・キャッシュが果たす役割の詳細は、「実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理」を参照してください。
ビュー・オブジェクト・インスタンスで構成されるデータ・モデルを作成する方法の詳細は、「アプリケーション・モジュールによるビジネス・サービスの実装」を参照してください。
通常、カスタム・ビュー・オブジェクト・クラスで記述、使用およびオーバーライドする一般的なコードのクイック・リファレンスは、「ADFビジネス・コンポーネントのよく使用されるメソッド」を参照してください。
oracle.jboパッケージに関連するAPIのドキュメントについては、次のJavadocリファレンス・ドキュメントを参照してください。
Oracle ADFモデルJava APIリファレンス
ADFビジネス・コンポーネントのビュー・オブジェクトは、SQL問合せを使用してデータベース表などのデータソースからデータを取得するのに使用されます。
ビュー・オブジェクトは、データソースからデータを取得する手段を備えています。ほとんどの場合、データベースがデータソースとなり、データの取得にはSQL問合せが使用されます。ADFビジネス・コンポーネントでは、JDBCと連携することによってこの問合せをデータベースに渡し、結果を取得できます。
ビュー・オブジェクトでSQL問合せが使用される場合、問合せ列がそのビュー・オブジェクトのビュー・オブジェクト属性にマップされます。これらの属性の定義は、ビュー・オブジェクトのXML定義ファイルに保存され、データ型および精度とスケールの指定など、これらの列の様々なプロパティを反映しています。
パフォーマンスのヒント:
ビュー・オブジェクトに関連付けられた問合せに、実行ごとに値が変更される問合せパラメータが含まれる場合は、バインド変数を使用します。問合せでバインド変数を使用すると、データベースで問合せを再解析する必要なく、問合せを再実行できます。バインド変数は、ビュー・オブジェクトの概要エディタの「問合せ」ページでビュー・オブジェクトに追加できます。詳細は、「バインド変数の使用」を参照してください。
「ビュー・オブジェクトの作成」ウィザードでは、既存のエンティティ・オブジェクトの属性にマップされるビュー・オブジェクトもマップされないビュー・オブジェクトも作成できます。エンティティ・ベースのビュー・オブジェクトのみが、マップされたエンティティ・オブジェクトと自動的に連携し、ビジネス・ルールの適用とデータ・モデルの変更の永続的な保存が可能です。また、エンティティ・ベースのビュー・オブジェクトの「更新可能」機能を無効にし、読取り専用データの問合せを完全に宣言的に実行できます。ウィザードまたはエディタのカスタムSQLモードを使用してSQL問合せ言語を直接使用することもできますが、この場合、作成したビュー・オブジェクトでは、エンティティ・ベースのビュー・オブジェクトのトランザクション機能はサポートされません。
エンティティ・ベースのビュー・オブジェクトを作成する場合は、ビュー・オブジェクト定義全体を宣言的にしながらも、カスタマイズ可能なビュー・オブジェクトを維持できます。また、カスタムSQL問合せ編集に切り替えて、エンティティ・オブジェクトのみでは表現できない、ユニオンやグループ化などの問合せを作成することもできます。さらに、カスタムSQLビュー・オブジェクトは、ビュー・オブジェクト・ベースのキー存在バリデータによって使用されるSQLベースの検証問合せでも便利です。定義によると、カスタムSQLモードを使用してSQL問合せを定義すると、ビュー・オブジェクトは取り専用になります。
エンティティ・ベースのビュー・オブジェクトとエンティティのないビュー・オブジェクトの違いの詳細は、「ビュー・オブジェクトについて」を参照してください。
ビュー・オブジェクトの作成では、エンティティ・ベースのビュー・オブジェクトの作成が最も簡単な方法です。これは作成時にSQL文を自分で入力する必要がないため、カスタムSQLビュー・オブジェクトより簡単に作成できます。また、エンティティ・ベースのビュー・オブジェクトの方が、カスタムSQLビュー・オブジェクトより非常に多くの実行時機能が用意されています。
エンティティ・ベースのビュー・オブジェクトでは、ビュー・オブジェクトとエンティティ・オブジェクトが果す役割が明確に区別されています。
ビュー・オブジェクトは、データ・ソースで、SQLを使用してデータを取得します。
エンティティ・オブジェクトは、データ・シンクで、データの変更を検証および保存します。
ビュー・オブジェクトとエンティティ・オブジェクトの役割は明確に区別されているため、再使用可能なエンティティ・オブジェクトを変更せずに、異なるビュー・オブジェクトを複数作成でき、アプリケーションごとのユーザー・インタフェースで求められる方法で、データを計画、フィルタ、結合およびソートできます。実際、エンティティ・オブジェクトのコア・ビジネス・サービス・レイヤーを担当する開発チームを、エンド・ユーザー環境のサポートに必要な特定のアプリケーション・モジュールおよびビュー・オブジェクトを担当するチームから完全に独立させることができます。このような関係は、エンティティ・ベースのビュー・オブジェクトによってカプセル化されるメタデータによって実現されます。このメタデータでは、基礎となる1つ以上のエンティティ・オブジェクトの属性に対してSELECTリストの列がどのように関連付けられるかが指定されます。
使用するエンティティ・ベースのビュー・オブジェクトは、複数のデータベース表を基にできます。データベース結合を使用して複数の表をビュー・オブジェクトに追加するには、「結合問合せ結果での複数表の使用」を参照してください。
基礎となるエンティティ・オブジェクトのすべての属性をクライアントが操作できるようにする場合は、「デフォルト・ビュー・オブジェクトの作成」ダイアログを使用すると、「アプリケーション」ウィンドウで選択したエンティティ・オブジェクトからすばやくビュー・オブジェクトを作成できます。デフォルト・ビュー・オブジェクトを作成するには、エンティティ・オブジェクトを選択して右クリックし、新規デフォルト・ビュー・オブジェクトを選択します。ビュー・オブジェクトにすべての属性を含めない場合は、「単一表からのエンティティ・ベースのビュー・オブジェクトの作成」で説明するように、ビュー・オブジェクトの作成ウィザードを使用して必要な属性のみを選択できます。
始める前に:
エンティティ・ベースのビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
デフォルトのエンティティ・ベースのビュー・オブジェクトを作成する手順:
図5-3 エンティティ・オブジェクトのデフォルト・ビュー・オブジェクトの簡単な作成方法
作成される新しいエンティティ・ベースのビュー・オブジェクトは、「ビュー・オブジェクトの作成」ウィザードで作成できるものと同一のものです。これには、デフォルトで、「アプリケーション」ウィンドウで選択したエンティティ・オブジェクトを参照する単一のエンティティ・オブジェクトの慣用名があり、そのすべての属性が含まれます。最初は、このビュー・オブジェクトにはWHERE句もORDER BY句もないため、次のビュー・オブジェクトの操作には概要エディタを使用する必要があります。
不要な属性の削除
WHERE句を使用した選択内容の限定
ORDER BY句による結果の順序付け
ビュー・オブジェクトのプロパティのカスタマイズ
エンティティ・ベースのビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。
始める前に:
エンティティ・ベースのビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
単一表からエンティティ・ベースのビュー・オブジェクトを作成する手順:
このリストのエントリは、ビュー・オブジェクトが使用するエンティティ・オブジェクトを記録するため、エンティティ・オブジェクトの慣用名と呼ばれます。また、ビュー・オブジェクトがこのエンティティの属性を参照するため、各エントリはエンティティ参照とも呼ばれます。表結合を使用してエンティティ・オブジェクトの慣用名を追加で作成する方法の詳細は、「結合問合せ結果での複数表の使用」を参照してください。
たとえば、図5-4は、ProductEOエンティティ・オブジェクトを「選択済」リストに移動した結果を示しています。
たとえば、図5-5は、ProductEOから属性が選択されたことを示しています。
WHEREおよびORDER BY句を追加して、必要に応じてデータのフィルタ処理と並替えを行います。選択したエンティティ属性に基づいて、SELECT文が自動的に生成されます。 「WHERE」フィールドおよび「ORDER BY」フィールドの値には、WHEREキーワードやORDER BYキーワードを含めないでください。これらのキーワードは、実行時に問合せを実行する際に追加されます。
たとえば、図5-6では、名前と希望小売価格を基準にしてデータを順序付けるたために、ORDER BY句が指定されています。
ビュー・オブジェクトを作成する際、JDeveloperでビュー・オブジェクトの宣言的設定を表すXMLドキュメント・ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、viewsパッケージに追加されたビュー・オブジェクトProductVOには、プロジェクトのソース・パスにXMLファイル./views/ProductVO.xmlが作成されます。
ビュー・オブジェクト設定を表示するには、「アプリケーション」ウィンドウで目的のビューを選択して、「構造」ウィンドウを開きます。「構造」ウィンドウは、SQL問合せ、エンティティ・オブジェクトの慣用名および各属性のプロパティなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースに移動」を選択します。
注意:
ADFビジネス・コンポーネントに対してデフォルトのJavaクラスを生成するようにJDeveloperの設定を構成すると、ウィザードにより、オプションのカスタム・ビュー・オブジェクト・クラス(ProductVOImpl.javaなど)またはカスタム・ビュー行クラス(ProductVORowImpl.javaなど)あるいはその両方も作成されます。設定の詳細は、「ADFビジネス・コンポーネントのモデル・プロジェクト・プロパティのカスタマイズ方法」を参照してください。
図5-7は、エンティティ・ベースのビュー・オブジェクトProductVOと、この問合せ文で参照される1つのエンティティの慣用名を示しています。点線は、問合せのSELECTリストの列を、ビュー・オブジェクトで使用されるエンティティ・オブジェクトの属性にマップする、エンティティ・ベースのビュー・オブジェクトのXMLドキュメントで取得されるメタデータを表します。
図5-7 SQL問合せとエンティティ属性マッピング・メタデータをカプセル化するビュー・オブジェクト
「ビュー・オブジェクトの作成」ウィザードを使用してエンティティ・ベースのビュー・オブジェクトを作成する場合、ビュー・オブジェクトの属性はデフォルトで更新可能になります。ビュー・オブジェクトのすべての属性を読取り専用にする場合は、ウィザードでエンティティ・オブジェクトを追加するときに「更新可能」の選択を解除できます。作成した後に、SQLにマップされた表の列を更新できるようにビュー・オブジェクトを変換できます。ただし、属性の「更新可能」プロパティを変更するのみでは、この目的は達成できません。読取り専用のビュー・オブジェクトを削除してから、目的の属性が更新可能になるようにエンティティ・ベースのビュー・オブジェクトを再作成する必要があります。
ビュー・オブジェクトを作成した後、ビュー・オブジェクトの概要エディタでその設定を編集できます。
パフォーマンスのヒント:
データをフェッチするためにビュー・オブジェクトをどのように構成するかは、ビュー・オブジェクトの実行時パフォーマンスにおいて重要な役割を果します。パフォーマンスを最適化するために編集可能なチューニング・パラメータの詳細は、「ビュー・オブジェクトの実行時パフォーマンスの最適化に関する必知事項」を参照してください。
始める前に:
ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
ビュー・オブジェクト定義を編集するには:
エンティティ・ベースのビュー・オブジェクトに関して興味深い特徴の1つは、基礎となるエンティティ・オブジェクト属性に関連する各属性がその属性のプロパティを継承することです。図5-8は、継承された属性が選択されている状態でビュー・オブジェクト・エディタの「属性」ページの「詳細」セクションを示しています。ここでは、Javaの属性タイプや問合せ列のタイプなどのフィールドは無効になっており、これらの値は、このビュー・オブジェクトが関連付けられている基礎となるエンティティ・オブジェクトの関連属性から継承されています。属性のデータ型などの一部のプロパティは継承され、ビュー・オブジェクト・レベルでは変更できません。
QueryableおよびUpdatableなどの他のプロパティは継承されますが、オーバーライド後の設定の方が継承された設定より制限が大きい場合、これらのプロパティをオーバーライドできます。たとえば、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定は、「常に」です。図5-8のように、ビュー・オブジェクトの概要エディタで「属性」ページの「詳細」セクションにより、対応するビュー・オブジェクト属性を、制限がより大きい「新規の間」または「なし」などに設定できます。ただし、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定が「なし」である場合、エディタでは、ビュー・オブジェクトの関連属性をより制限の小さい「常に」などに設定できません。
図5-8 基礎となるエンティティ・オブジェクトから継承されたビュー・オブジェクト属性のプロパティ
概要エディタでビュー・オブジェクトを編集するときに、概要エディタの「属性」ページをカスタマイズし、表示されるビュー・オブジェクトの属性表を有効活用することができます。
属性表でカスタマイズできるのは、属性表に列として表示する属性プロパティのリスト、属性表に表示される列の順序(左から右)、列のソート順、列の幅などです。表示可能な列の全リストは、属性で編集できるプロパティに対応します。
たとえば、ビュー・オブジェクトのどの属性が更新可能かを即座に把握する必要がある場合は、属性表に表示する列として「更新可能」プロパティを追加できます。また、属性の「ラベル」プロパティを列として追加し、エンド・ユーザーに表示されるものと同じ説明を表示できます。また、エンティティ・オブジェクトの慣用名に基づいて属性のリストを表示する必要があるとします。その場合は、「エンティティ・オブジェクトの慣用名」列を表示して、この列に基づいて属性表全体をソートできます。
最も有益な列のリストを含めるように属性表を設定した後、属性表を右クリックして「すべてのビュー・オブジェクトに適用」を選択すると、他のビュー・オブジェクトに表示される属性表にも同じ列セットを適用することができます。
始める前に:
ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
属性表の表示をカスタマイズするには:
「アプリケーション」ウィンドウで、属性表の表示をカスタマイズするビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、属性列ヘッダー右(属性表のボタン・バー下)のドロップダウン・メニュー・アイコンをクリックし、「列の選択」を選択します。
図5-9 概要エディタに表示する属性列の変更
「列の選択」ダイアログで、次のアクションを実行します。
概要エディタの属性表に表示される列のリストを変更するには、左/右シャトル・ボタンをクリックします。概要エディタには、「選択されたもの」リストに表示される属性プロパティに対応する列のみが表示されます。
概要エディタの属性表の列の位置を変更するには、選択項目を移動のボタンの1つをクリックします。概要エディタの属性プロパティは、「選択されたもの」リストの上位にあるプロパティから、左から右に配置されて表示されます。
「OK」をクリックします。
概要エディタの「属性」ページで、次のアクションを実行します。
概要エディタの属性表の列の位置を変更するには、列ヘッダーを選択してドラッグします。
選択した列を基準として属性表のすべての列をソートするには、列ヘッダーをクリックします。
この機能は、特定の列に注目する必要がある場合に特に有益です。たとえば、エンティティ・ベースのビュー・オブジェクトの場合、「エンティティ・オブジェクトの慣用名」列ヘッダーをクリックして、基礎となるエンティティ・オブジェクトごとに属性表の属性をグループ化できます。
属性表の列の幅を調節するには、列ヘッダーの境界線をクリックしてドラッグします。
現在の属性表に表示されている列を変更するには、列ヘッダー右のドロップダウン・リストをクリックし、表示されている列のリストから選択します。
現在のビュー・オブジェクトの概要エディタの属性表表示を簡易化する場合に、この機能によって容易に列を非表示にできます。
列の変更(列のリスト、列の順序、列のソート、列幅を含む)をすべての他のビュー・オブジェクトの概要エディタに拡張する場合は、列ヘッダー右のドロップダウン・メニューをクリックし、「すべてのビュー・オブジェクトに適用」をクリックします。
この機能により、ビュー・オブジェクト全体で同じ属性を容易に比較できます。概要エディタにより、「列の選択」ダイアログで選択した列(および順序)、および現在の属性表の列ソートと列幅が、ユーザーが編集するすべてのビュー・オブジェクトに適用されます。開いている概要エディタに現在表示中のビュー・オブジェクトは、これらの設定によって更新されないため、ビュー・オブジェクトの概要エディタを閉じてからもう一度開き、このビュー・オブジェクトをもう一度開いて設定が適用されたことを確認してください。
ビュー・オブジェクト定義を作成した後、ビュー・オブジェクトが問い合せる属性の順序を変更できます。このビュー・オブジェクト編集機能により、ビュー・オブジェクトの概要エディタの「属性」ページに表示される属性表の属性の順序を容易に変更できます。この機能は、特定の属性に対して作用し、現在のビュー・オブジェクトのXML定義を変更するため、ユーザーが編集する別のビュー・オブジェクトには適用されません。または、概要エディタの属性表の列ヘッダーをクリックして、ソース・ファイルに影響を与えずに、ビュー・オブジェクトの概要エディタの「属性」ページの属性表示をソートする方法もあります。
始める前に:
ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
ビュー・オブジェクトのソース・ファイルの属性の順序を変更する手順:
JDeveloperのUMLダイアグラムを使用すると、ビジネス・コンポーネント・ダイアグラムを作成してビジネス・サービス・レイヤーを視覚化できます。JDeveloperのUMLダイアグラムでは、エンティティ・オブジェクトのサポートのみならず、ビュー・オブジェクトをダイアグラムにドロップして、その構造とエンティティ・オブジェクトの慣用名を視覚化できます。たとえば、oracle.summit.modelパッケージに新しいビジネス・コンポーネント・ダイアグラムを作成し、CustomerAddressVOビュー・オブジェクトを「アプリケーション」ウィンドウからダイアグラムにドラッグすると、図5-10に示すように、そのエンティティ・オブジェクトの慣用名が表示されます。ノードを拡張して表示すると、ダイアグラムには、ビュー・オブジェクトのエンティティ・オブジェクトの慣用名を含む部分が表示されます。
図5-10 ビジネス・コンポーネント・ダイアグラム内のビュー・オブジェクトおよびそのエンティティ・オブジェクトの慣用名
始める前に:
ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
エンティティ・ダイアグラムの作成方法を理解しておくと役立つ場合があります。「ビジネス・レイヤーのエンティティ・オブジェクトの図の作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
既存のビュー・オブジェクトをモデル化するビジネス・コンポーネント・ダイアグラムを作成する手順:
SQL以外の代替方法としてエンティティ・ベースのビュー・オブジェクトを作成し、ADFビジネス・コンポーネントの宣言SQLモードを設計時および実行時に使用します。
実行時に、ADFビジネス・コンポーネントとJDBCが連携して問合せをデータベースに渡し、その結果を取得する場合、データの取得にはSQL問合せが使用されます。設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、SQL文を含まないエンティティ・ベースのビュー・オブジェクトを作成することもできます。ADFビジネス・コンポーネントの設計時および実行時のこの機能は、宣言SQLモードと呼ばれます。データ・モデルの開発者がビュー・オブジェクト用のウィザードやエディタを宣言SQLモードで使用する場合は、SQLの知識は必要ありません。宣言SQLモードでは、ビュー・オブジェクトに定義する必要のあるメタデータに基づいて、ADFビジネス・コンポーネント・ランタイムによって次のようにSQL問合せ文が生成されます。
レンダリング済WebページのデータバインドされたUIコンポーネントに、エンティティ・オブジェクトの属性が1つ以上使用されていることに基づいて、SELECTリストおよびFROMリストを生成します。
実行時問合せ文を最適化するには、ビュー・オブジェクトの属性ごとに制御できるIsSelectedプロパティ設定を変更し、データバインドされたUIコンポーネントが使用する属性のみに基づくように指定します。デフォルトでは、宣言SQLモードでビュー・オブジェクトに追加した属性ごとに、このプロパティはIsSelected=trueに設定されています。このデフォルト設定では、データバインドされたコンポーネントによってUIに公開されるかどうかにかかわらず、追加された属性はSQL文で選択されます。実行時問合せ文を最適化するためにプロパティ設定を変更する方法の詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。
ADF RESTfulウェブ・サービスの場合、URL問合せパラメータ・フィールドを使用して指定された属性のリストに基づいて、SELECT句を生成します。
ADF RESTリソースのバッキング・ビュー・オブジェクトで実行されるSQL SELECT文は、実行時に、ビュー・オブジェクトがどのように作成されるかに基づきます。宣言SQLモードを有効にして作成するビュー・オブジェクトのみが、問合せパラメータfieldsにより命名された属性のリストのみを使用して作成した最適化されたSQL SELECT文をサポートします。非宣言ビュー・オブジェクトで実行されるSELECT文は、ビュー・オブジェクト定義のすべての属性を含みます。実行時の最適化を実現するには、ADF Business Componentsデベロッパで、宣言SQLモードのみを使用してADF RESTリソースに対するビュー・オブジェクトを作成することをお薦めします。
ビュー・オブジェクト定義に追加するビュー基準に基づいて、WHERE句を生成します。
ビュー・オブジェクト定義に追加するソート基準に基づいて、ORDER BY句を生成します。
ビュー・オブジェクト定義に追加する名前付きビュー基準に基づいて、表の結合がサポートされるようにWHERE句を拡張します。
ビュー・リンク定義のリンク元またはリンク先に追加するビュー基準に基づいて、マスター/ディテール・ビュー・フィルタリングがサポートされるようにWHERE句を拡張します。
また、宣言SQLモードのビュー・オブジェクトによって実行時に生成されるSQL文は、「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページで指定されるSQLプラットフォームによって決まります。
注意:
現在、ランタイムSQL生成用にサポートされているプラットフォームには、SQL92 (ANSI)およびOracleスタイルがあります。SQLプラットフォームをプロジェクト用に設定する方法の詳細は、「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」を参照してください。
宣言SQLモードの選択は、JDeveloperで、「ビュー・オブジェクトの作成」ウィザードで作成するすべてのビュー・オブジェクトのデフォルト設定としてサポートされます。ウィザードでは、設計時にカスタムSQLを作成するときに作成したビュー・オブジェクトについて、宣言SQLモードの設定をオーバーライドできます。
カスタムSQLを操作する場合、設計時に作成するビュー・オブジェクト定義には、常にアプリケーション・モジュールの定義済データベース接続に必要なSQLプラットフォームに基づいたSQL文全体が含まれます。そのため、SQLに依存しない機能は、カスタムSQLモードで作成したビュー・オブジェクトには適用されません。設計時にSQLが必要な場合にビュー・オブジェクトをカスタマイズするためのウィザードおよびエディタの使用の詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
JDeveloperで作成するビュー・オブジェクトはすべて、同一の設計時ウィザードおよびエディタに依存します。ただし、宣言SQLモードを有効にした場合、このウィザードおよびエディタでは、SQLの表示や入力を行うことなくビュー・オブジェクト定義をカスタマイズできるようになります。たとえば、「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページでは、宣言SQLモードが有効になると、標準モードでは表示された生成されたSQLフィールドが表示されません。
さらに、宣言SQLモードの場合、ウィザードやエディタではWHERE句およびORDER BY句を入力できないため、それぞれビュー基準とソート基準を定義し、これらの句と同等の機能を用意します。宣言SQLモードでは、これらの基準は、ビュー・オブジェクトのメタデータ定義内に記述され、実行時に対応するSQL句に変換されます。データバインドされたUIコンポーネントで、フィルタリングされたデータやソートされたデータを表示する必要がない場合は、ビュー・オブジェクト定義でビュー基準やソート基準を省略できます。
このようなデータを表示する必要がある場合は、宣言SQLモードを有効にした後、基本的にはエンティティ・ベースのビュー・オブジェクトの作成と同じ手順に従って、SQLに依存しないビュー・オブジェクトを作成します。たとえば、ビュー・オブジェクトでは、目的の実行時問合せをサポートするために必要なエンティティ・オブジェクト・メタデータのカプセル化が必要です。また、エンティティ・ベースのビュー・オブジェクトを使用する場合と同様、実行時に生成されるFROMリストの列は、ビュー・オブジェクトの基礎となる1つ以上のエンティティ・オブジェクトの属性に関連付けられている必要があります。宣言SQLモードでは、ビュー・オブジェクト定義におけるエンティティ・オブジェクトの属性を追加または削除する際にウィザードまたはエディタを使用することによって、この要件は自動的に満たされます。
宣言SQL問合せを最適化し、ビュー・オブジェクトに追加する属性がデータバインドされたUIコンポーネントによって実行時にレンダリングされるかどうかのみに基づいてSQL問合せ文のSELECT句とFROM句を生成する場合には、追加したすべての属性の「問合せで選択済」チェックボックスの選択を解除する(ビュー・オブジェクト定義でIsSelected=falseに設定する)必要があります。デフォルトでは、IsSelected=trueプロパティは、宣言SQLモードでビュー・オブジェクトに追加した各属性に対してtrueに設定されています。このデフォルト設定は、属性がデータバインドされたUIコンポーネントによって公開されるかどうかにかかわらず、追加された属性がSQL文で選択されることを意味します。宣言SQLモードで新しいビュー・オブジェクトを作成する場合、「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページを使用して各属性の設定を変更できます。ビュー・オブジェクトを作成した後にこの設定を変更する必要がある場合は、「プロパティ」ウィンドウを使用して、ビュー・オブジェクト・エディタの「属性」ページで選択した1つ以上の属性の「問合せで選択済」設定を変更できます。
パフォーマンスのヒント:
SQL文を動的に生成するように構成されたビュー・オブジェクト・インスタンスは、同じキー・エンティティ・オブジェクトのリストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合、ページ・ナビゲーション中にデータベースに再問合せを実行します。このため、必要なすべての属性のスーパーセットをアクティブ化して後続の問合せ実行を排除すると、パフォーマンスを向上できます。
始める前に:
宣言SQLモードに関する知識が役立つ場合があります。詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
宣言SQLベースのビュー・オブジェクトを作成する手順:
「WHERE」フィールドの横にある「編集」をクリックし、データのフィルタリングに使用するビュー基準を定義します。入力したビュー基準は、実行時にWHERE句に変換された上で問合せ文に適用されます。ビュー基準の指定の詳細は、「名前付きビュー基準の処理」を参照してください。
「ORDER BY」フィールドで、「使用可能」リストから目的の属性を選択し、「選択」リストに移動します。選択しなかった属性は、実行時に生成されるSQLのORDER BY句には使用されません。結果を複数の列でソートする場合は、さらに他の属性を「選択済」リストに追加します。ソートの優先順位に従って、選択した属性をリスト内で並べ替えます。次に、それぞれのソート属性に対して、ソートを昇順で実行するか降順で実行するかを指定します。それぞれの属性にソート順序を指定すると、UIコンポーネントでは無視される属性に対して必要なソート順序が適用されます。
たとえば、図5-11に示すように、CustomerCardStatusビュー・オブジェクトに対して、CUSTOMERS表の行のうち特定のクレジット・カード・コードを持つ顧客の行のみが表示されるように制限するには、「WHERE」フィールドのビュー基準によって、CardTypeCode属性を実行時に決定される値に制限します。顧客IDおよび顧客のカードの有効期限を基準にデータを並べ替えるには、「ORDER BY」フィールドで、それらの属性を「選択済」リストに指定します。
エンティティ・ベースのビュー・オブジェクトを作成する場合、ビュー・オブジェクト定義では複数のエンティティ・オブジェクトを参照できます。宣言SQLモードで作成するビュー・オブジェクトの場合、ベース・エンティティ・オブジェクトがビュー・オブジェクト定義からアクティブ化されるかどうかは、実行時におけるデータバインドされたUIコンポーネントの要件によって決まります。UIコンポーネントに複数のエンティティ・オブジェクトの属性値が表示される場合、実行時に生成されたSQLには、目的の表に対して問合せを行うためのJOIN演算子が含まれます。
作成する他のビュー・オブジェクトと同様に、名前付きビュー基準を適用すると、表結合から得られる結果をフィルタリングできます。標準モードのビュー・オブジェクトの場合、すべてのエンティティ・オブジェクトおよびその属性は、ビュー・オブジェクト定義により参照され、ビュー・オブジェクトのSQL文に自動的に取り込まれます。ただし、宣言SQLモードを使用する場合、実行時までSQLは生成されないため、ビュー基準が適用されるかどうかは判断できません。
注意:
宣言SQLモードでは、ビュー・オブジェクト定義を作成する際に、WHERE句を指定するためのビュー基準を定義できます(オプション)。このタイプのビュー基準が存在する場合は、デフォルトで実行時に適用されます。このようなビュー基準の使用方法の詳細は、「宣言的SQLビュー・オブジェクトを作成する方法」を参照してください。
UIコンポーネントには、宣言SQLモードで定義された複数のエンティティ・オブジェクトを持つビュー・オブジェクトのSQL JOINを実行できるだけの十分な属性が表示されない場合があるため、問合せ結果をフィルタリングするために定義した名前付きビュー基準を実行時に条件付きで適用する必要があります。つまり、宣言SQLベースのビュー・オブジェクトに対して作成した名前付きビュー基準は、自動フィルタとして必ず適用する必要はありません。宣言SQLモードをサポートするため、宣言SQLモードで作成されたビュー・オブジェクトに対する名前付きビュー基準の適用は、そのビュー基準が参照する属性にUIコンポーネントがバインドされる場合に限定するよう設定できます。ただし、名前付きビュー基準が、一度適用されると、フィルタリングされた結果セットを表示するというUIコンポーネントの要件がサポートされます。
始める前に:
実行時におけるSQL非依存性に関する知識が役立つ場合があります。詳細は、「宣言SQLモードでのビュー・オブジェクトの使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「宣言的SQLビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードを有効にしてビュー・オブジェクトを作成します。
「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成し、表結合の結果をフィルタリングします。
名前付きビュー基準を作成するには、「ビュー基準の編集」ダイアログを使用して、結合されたエンティティ・オブジェクトから1つ以上の属性を選択します。その後、「プロパティ」ウィンドウでAppliedIfJoinSatisfiedを設定して条件付きの使用を可能にします。
結合が要件を満たしている場合にのみフィルタリングするビュー基準を定義するには:
標準モードのビュー・オブジェクトを使用する場合と同様に、宣言SQLモードで作成したビュー・オブジェクトを他のビュー・オブジェクトにリンクし、任意の複雑さでマスター/ディテール階層を構成できます。ビュー・リンクの作成手順は、「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」で説明した他のエンティティ・ベースのビュー・オブジェクトの作成手順と同じです。ただし、宣言SQLモードで作成するビュー・オブジェクトの場合、ビュー・リンクの作成ウィザードまたはビュー・リンク用の概要エディタで事前に定義されたビュー基準を選択すると、ビュー・リンクの「関連元SQL」ダイアログまたは「関連先SQL」ダイアログでビュー・オブジェクトの結果をさらに絞り込めます。
始める前に:
実行時におけるSQL非依存性に関する知識が役立つ場合があります。詳細は、「宣言SQLモードでのビュー・オブジェクトの使用」を参照してください。
他のビュー・オブジェクト機能を使用して追加できる機能に関する知識が役立つ場合もあります。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「宣言的SQLビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードを有効にしてマスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトを作成します。
リンク元(マスター)・ビュー・オブジェクトまたはリンク先(ディテール)ビュー・オブジェクトに対して、目的のビュー基準を定義します(「表結合が適用された場合に宣言SQLベースのビュー・オブジェクトをフィルタリングする方法」を参照)。
「エンティティ・アソシエーションに基づくマスター/ディテール階層の作成方法」の説明に従って、ビュー・リンクを作成します。
ビュー・リンクのリンク元またはリンク先をフィルタリングするには:
宣言SQLモードのビュー・オブジェクトを定義する場合、実行時に問合せが行われる属性は、通常、データバインドされたUIコンポーネントがWebページにレンダリングされる際の要件によって決まります。この実行時生成機能により、ビュー・オブジェクトを、設計時のデータベースのSQLプラットフォームに依存しないようにできます。ただし、このようなビュー・オブジェクトは、UIのADFバインディングに公開せず、プログラムによって実行が必要となる場合もあります。この場合、「すべての属性を実行時生成問合せに含めます」オプションを有効にすると、プログラムによって実行されたビュー・オブジェクトからすべてのエンティティ・オブジェクトへのアクセスを可能にできます。図5-12に、有効に設定されているグローバル・プリファレンス「すべての属性を実行時生成問合せに含めます」を示します。
図5-12 宣言SQLモードが有効になっている場合の「プリファレンス」ダイアログ
注意:
「すべての属性を実行時生成問合せに含めます」オプションは、プログラムによって実行されるビュー・オブジェクトに対してのみ使用します。この設定を有効にしたビュー・オブジェクトをデータバインドされたUIコンポーネントに公開した場合、ランタイム問合せにはすべての属性が取り込まれます。
「すべての属性を実行時生成問合せに含めます」オプションは、グローバル設定として指定することも、個々のビュー・オブジェクトに対する設定とすることもできます。この2つの設定は、次のように組み合せて使用できます。
作成する各ビュー・オブジェクトですべての属性がランタイム問合せ文に取り込まれるようにグローバル設定を有効にします。
グローバル設定を有効にする一方で、プログラムにより実行されず、そのため一部の属性がランタイム問合せ文に取り込まれないビュー・オブジェクトに対しては設定を無効にします。
グローバル設定を無効(デフォルト)にする一方で、プログラムによって実行され、そのためすべての属性がランタイム問合せ文に取り込まれるビュー・オブジェクトに対しては設定を有効にします。
グローバル設定を有効化して宣言SQLモードのすべてのビュー・オブジェクトに属性問合せをデフォルト・モードとして強制実行することも、このオプションを無効にしたまま特定ビュー・オブジェクトの概要エディタでオプションを直接選択することもできます。
始める前に:
「すべての属性を実行時生成問合せに含めます」オプションで宣言SQLモードのビュー・オブジェクトのプログラム実行をサポートする方法に関する知識が役立つ場合があります。詳細は、「宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
グローバル設定を有効にして問合せにすべての属性が取り込まれるようにする手順:
特定のビュー・オブジェクトのすべての属性がビュー・オブジェクトの問合せに強制的に取り込まれるようにする場合は、概要エディタの「一般」ページの「チューニング」セクションでその指定ができます。すでにビュー・オブジェクトを宣言SQLモードで作成している場合、概要エディタには、「すべての属性を実行時生成問合せに含めます」オプションのみが表示されます。
始める前に:
「すべての属性を実行時生成問合せに含めます」オプションで宣言SQLモードのビュー・オブジェクトのプログラム実行をサポートする方法に関する知識が役立つ場合があります。詳細は、「宣言SQLモードのビュー・オブジェクトにおけるプログラム実行をサポートする方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクト固有の設定によってすべての属性が問合せに取り込まれるようにする手順:
宣言SQLモードでビュー・オブジェクトを作成する場合、SelectListFlags、FromListFlagsおよびWhereFlagsの3つのプロパティがビュー・オブジェクトのメタデータに追加されます。宣言SQLモードに含まれないプロパティは、標準モードのビュー・オブジェクトのプロパティSelectList、FromListおよびWhere(または、カスタムSQLモードの場合はSQLQuery要素)で、これらには実際のSQL文が指定されます。次の例は、宣言SQLモードで有効にされるビュー・オブジェクトのメタデータの3つのフラグを示したもので、これによりSQLは、ビュー・オブジェクト定義内のメタデータとして指定されるのではなく、実行時に生成されます。
<ViewObject xmlns="http://xmlns.oracle.com/bc4j" Name="CustomerCardStatus" SelectListFlags="1" FromListFlags="1" WhereFlags="1" ...
標準モードまたはカスタムSQLモードで作成するビュー・オブジェクトと同様、このビュー・オブジェクトのメタデータには、「ビュー・オブジェクトの作成」ウィザードの「属性」ページで選択した各属性に対するViewAttribute要素も含まれます。ただし、宣言SQLモードでは、ウィザードで属性を選択する場合(または概要エディタで属性を追加する場合)、設計時にはFROMリストまたはSELECTリストを作成しません。ビュー・オブジェクトのメタデータに含まれる属性定義では、実行時に生成される文に取り込まれる可能性のあるエンティティおよび属性のリストのみが決定されます。このようなADFビジネス・コンポーネントでのSQLリストの生成の詳細は、「実行時に行われる処理: 宣言SQLモードでのSQL」を参照してください。
次の例は、オプションの宣言WHERE句(DeclarativeWhereClause要素)およびオプションの宣言ORDERBY句(SortCriteria要素)を含む宣言SQLモードのビュー・オブジェクトの追加機能を示しています。
<DeclarativeWhereClause> <ViewCriteria Name="CustomerStatusWhereCriteria" ViewObjectName="oracle.summit.model.views.CustomerCardStatus" Conjunction="AND" Mode="3" AppliedIfJoinSatisfied="false"> <ViewCriteriaRow Name="vcrow60"> <ViewCriteriaItem Name="CardTypeCode" ViewAttribute="CardTypeCode" Operator="STARTSWITH" Conjunction="AND" Required="Optional"> <ViewCriteriaItemValue Value=":cardtype" IsBindVarValue="true"/> </ViewCriteriaItem> </ViewCriteriaRow> </ViewCriteria> </DeclarativeWhereClause> <SortCriteria> <Sort Attribute="CustomerId"/> <Sort Attribute="CardTypeCode"/> </SortCriteria>
実行時に宣言SQLモードの問合せが生成されると、メタデータのViewCriteria要素およびSortCriteria要素から定義されている属性が、ADFビジネス・コンポーネントによって特定されます。次に、これらの属性を使用してWHERE句およびORDER BY句が生成されます。次に、メタデータのViewAttribute要素によって定義されたエンティティ・オブジェクトの慣用名に対応する表に基づいて、ランタイムによりFROMリストが生成されます。最後に、エンド・ユーザーがUIを使用してどの属性を選択したかに基づいて、ランタイムによりSELECT文が作成されます。このように、宣言SQLモードのビュー・オブジェクトにより、実行時にすべてのSQL句が完全な形で生成されます。実行時に生成されるSQL文は、プロジェクト・プロパティの設定に含まれるSQLプラットフォームに基づいています。現在、ランタイムでサポートされているSQLスタイルは、SQL92 (ANSI)およびOracleスタイルのプラットフォームです。
SQL問合せのバインディング・スタイルは、アプリケーションに対して選択されているSQLスタイルによって決まります。実際には、すべての問合せが同じバインディング・スタイル(名前指定または位置指定)を使用する必要があり、そうしないとSQL検証エラーが発生することがあります。この問題を回避するために、アプリケーション開発者は、同じ管理対象サーバーにデプロイするADFアプリケーションすべてが、選択したSQLプラットフォームに単一値を使用することを確認する必要があります。詳細は、「データベース接続を使用してデータ・モデル・プロジェクトを初期化する方法」を参照してください。
開発者の便宜を考慮して、個々の属性の選択および選択解除は、ビュー・オブジェクト実装のAPIを介してプログラムにより実行できるようになっています。このAPIは、宣言SQLモードで作成してプログラムにより実行するビュー・オブジェクトと組み合せると有用な場合があります。次の例は、SQLモードを有効にして構成済の属性に属性のサブセットを追加する場合に、ビュー・オブジェクトでselectAttributeDefs()をコールする方法を示しています。
ApplicationModule am = Configuration.createRootApplicationModule(amDef, config);
ViewObjectImpl vo = (ViewObjectImpl) am.findViewObject("CustomerVO");
vo.resetSelectedAttributeDefs(false);
vo.selectAttributeDefs(new String[] {"FirstName, "LastName"});
vo.executeQuery();
selectAttributeDefs()をコールすると、配列内の属性がViewObjectImplのプライベート・メンバー変数に追加されます。プライベート・メンバー変数の属性は、executeQuery()をコールすると実際の選択リストに転送されます。これらのViewObjectImpl属性コールはクライアント・レイヤーには適用されず、中間層のビュー・オブジェクトのImplクラス内でしかアクセスできないことを理解しおくことが重要です。
また、「すべての属性を実行時生成問合せに含めます」 オプションを有効にした後、一部の属性のサブセットの選択を解除する場合は、ビュー・オブジェクト上でunselectAttributeDefs()をコールします。または、「すべての属性を実行時生成問合せに含めます」 オプションを無効にした後、一部の属性のサブセットを選択する場合は、ビュー・オブジェクト上でselectAttributeDefs()をコールします。
注意:
「すべての属性を実行時生成問合せに含めます」オプションの値以外に使用される値はないため、このAPIで実行される宣言SQLモードのビュー・オブジェクトは、UIに対して公開しないように注意してください。
ADFビジネス・コンポーネントの静的データ・ビュー・オブジェクトを作成して静的データの小規模なセットにアクセスし、不要なデータベースの問合せを回避します。
ADFビジネス・コンポーネントでは、設計時に移入した行を使用して、各自のデータ・モデル・プロジェクトでビュー・オブジェクトを作成できます。通常、保持するデータ量が少なく、それらのデータを変更する頻度が低いと予想される場合は、静的データ・ビュー・オブジェクトを作成します。データベースの参照表を使用するか、ハードコードされた値のリストに基づいて静的データ・ビュー・オブジェクトを使用するかは、データのサイズおよび性質に基づいて決定します。リストのエントリ数が100未満の場合は、静的データ・ビュー・オブジェクトの方が便利です。行が相当数ある場合は、従来の表ベースのビュー・オブジェクトを使用してデータベースから読み取る必要があります。静的データ・ビュー・オブジェクトには、属性値がリソース・バンドルに格納されているので簡単に変換できるという利点があります。ただし、静的データ・ビュー・オブジェクトの行はすべて一括で取得されるため、使用するエントリ数が100未満であれば最適なパフォーマンスが得られます。
ベスト・プラクティス:
データ量が少ない静的データのリストにアクセスするためにビュー・オブジェクトを作成する必要がある場合は、データベースに問い合せるよりも静的データ・ビュー・オブジェクトを使用することをお薦めします。静的データ・ビュー・オブジェクトは、データの行数が100を超えないリストで使用することが理想的です。「ビュー・オブジェクトの作成」ウィザードでは、データはリソース・メッセージ・ファイルに保存されるため、これらのデータの変換は簡単です。
データベースに対する問合せによって値のリストを取得することが適切でない場合は、静的データ・ビュー・オブジェクトをLOVデータソースとして使用できます。たとえば、注文に対して未処理、処理済、保留中というステータスがあるとします。これらの値を使用して静的データ・ビュー・オブジェクトを作成し、その静的データ・ビュー・オブジェクトのステータス属性に基づいてLOVを定義できます。ウィザードではステータス・ビュー・オブジェクトの値が変換可能なリソース・ファイルに格納されるため、アプリケーションの現在のロケールに対応したリソース・ファイルを使用して、UIにステータス値が表示されます。
静的データ・ビュー・オブジェクトの作成には、「ビュー・オブジェクトの作成」ウィザードを使用します。このウィザードでは、目的の属性(列)を定義し、必要な数の行を入力できます。このウィザードには、作成したとおりに静的データ表が表示されます。
注意:
静的データ・ビュー・オブジェクトは、その中のデータがデータベース表からのものではないため、読取り専用です。
「ビュー・オブジェクトの作成」ウィザードでは、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づいて属性を作成することもできます。
始める前に:
静的データ・ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「静的データが移入されたビュー・オブジェクトの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
静的データ・ビュー・オブジェクトの属性を手動で作成するには:
「ビュー・オブジェクトの作成」ウィザードの「インポート」機能を使用すると、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づく属性によって、静的データ・ビュー・オブジェクトを作成できます。このウィザードでは、属性の識別にはCSVフラット・ファイルの先頭行が使用され、それぞれの属性のデータに対してはCSVファイルの後続行が使用されます。たとえば、アプリケーションで国際通貨を表示する必要がある場合は、図5-13のように、最初の行にSymbol、Country、Descriptionの列を定義し、行を追加して各通貨タイプのデータを定義します。
図5-13 CSVフラット・ファイルからインポートして用意したサンプル・データ
始める前に:
静的データ・ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「静的データが移入されたビュー・オブジェクトの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
フラット・ファイルに基づいて静的データ・ビュー・オブジェクトの属性を作成するには:
静的データ・ビュー・オブジェクトを作成すると、ウィザードで定義したデータの行がビュー・オブジェクトの概要エディタに表示されます。エディタを使用すると、図5-14に示すように追加データを定義できます。
静的データ・ビュー・オブジェクトの生成済XML定義には、データの列ごとに一時属性が1つずつ格納されます。たとえば、国際通貨のデータが格納されたCSVファイルをインポートすると、静的データ・ビュー・オブジェクトには、次の例のように、Symbol、CountryおよびDescriptionの一時属性が格納されます。
<ViewObject
...
<!-- Transient attribute for first column -->
<ViewAttribute
Name="Symbol"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR2"
AliasName="Symbol"
SQLType="VARCHAR"/>
<!-- Transient attribute for second column -->
<ViewAttribute
Name="Country"
IsUpdateable="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR"
AliasName="Country"
SQLType="VARCHAR"/>
<!-- Transient attribute for third column -->
<ViewAttribute
Name="Description"
IsUpdateable="false"
IsPersistent="false"
PrecisionRule="true"
Precision="255"
Type="java.lang.String"
ColumnType="VARCHAR"
AliasName="Description"
SQLType="VARCHAR"/>
<StaticList
Rows="4"
Columns="3"/>
<!-- Reference to file that contains static data -->
<ResourceBundle>
<PropertiesBundle
PropertiesFile="model.ModelBundle"/>
</ResourceBundle>
</ViewObject>
データは静的であるため、概要エディタには「問合せ」ページは表示されず、静的データ・ビュー・オブジェクトの生成済XML定義に問合せ文は含まれません。かわりに、XML定義の<ResourceBundle>要素がリソース・バンドル・ファイルを参照します。次の例では、ファイルの参照がPropertiesFile="model.ModelBundle"として示されています。リソース・バンドル・ファイルには、データの行が記述されるため、データのローカライズも可能です。デフォルトのリソース・バンドル・タイプが使用されている場合は、次の例のように、データ・モデル・プロジェクトにModelBundle.propertiesファイルが表示されます。
model.ViewObj.SL_0_0=USD model.ViewObj.SL_0_1=United States of America model.ViewObj.SL_0_2=Dollars model.ViewObj.SL_1_0=CNY model.ViewObj.SL_1_1=P.R. China model.ViewObj.SL_1_2=Yuan Renminbi model.ViewObj.SL_2_0=EUR model.ViewObj.SL_2_1=Europe model.ViewObj.SL_2_2=Euro model.ViewObj.SL_3_0=JPY model.ViewObj.SL_3_1=Japan model.ViewObj.SL_3_2=Yen
静的リスト表に対して変更を加える必要がある場合は、「アプリケーション」ウィンドウでビュー・オブジェクトをダブルクリックし、そのビュー・オブジェクトの概要エディタを開きます。この概要エディタを使用すると、属性(静的リスト表の列)の追加および削除、行(静的リスト表のデータ)の追加または削除、個別行のソート、個々の属性値の変更を実行できます。またこのエディタでは、ビュー・オブジェクト定義ファイルが更新され、変更された属性値がメッセージ・バンドル・ファイルに保存されます。メッセージ・バンドルのローカライズの詳細は、「リソース・バンドルの使用」を参照してください。
ADFビジネス・コンポーネントのビュー・オブジェクトには、エンティティ・オブジェクト属性にマップされないSQL計算属性および一時属性を組み込むことができます。
ビュー・オブジェクトには、基礎となるエンティティ・オブジェクトにマップされた属性以外にも、エンティティ・オブジェクトの属性値にマップされない計算属性を組み込むこともできます。計算属性としては、次の2種類があります。
SQL計算属性(値がSQL問合せのSELECTリスト内の式として取得される場合)
一時属性(値が問合せの一部として取得されない場合)
ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。
SQL計算属性を追加するには、ビュー・オブジェクトの概要エディタを使用します。
始める前に:
計算属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
SQL計算属性をビュー・オブジェクトに追加するには:
たとえば、名前と姓の順序を変更するには、図5-15に示すように、LAST_NAME||', '||FIRST_NAMEと式を記述します。
ビュー・オブジェクトの概要エディタでSQL計算属性を追加すると、ビュー・オブジェクトのXMLドキュメントが更新され、新しい属性が反映されます。エンティティにマップされた属性の<ViewAttribute>タグは、次の例に示すサンプルのようになります。エンティティにマップされた属性のプロパティの大部分は、基礎となるエンティティの属性からマップ先に継承されます。
<ViewAttribute Name="LastName" IsNotNull="true" EntityAttrName="LastName" EntityUsage="EmpEO" AliasName="LAST_NAME" > </ViewAttribute>
これに対し、SQL計算属性の<ViewAttribute>タグは、次の例に示すサンプルのようになります。想定どおり、このタグにはEntityUsageまたはEntityAttrNameプロパティはなく、次のようにデータ型情報とともにSQL式が含まれます。
<ViewAttribute Name="LastCommaFirst" IsUpdatable="false" IsPersistent="false" PrecisionRule="true" Type="java.lang.String" ColumnType="VARCHAR2" AliasName="FULL_NAME" SQLType="VARCHAR" > Precision="62" Expression="LAST_NAME||', '||FIRST_NAME"> </ViewAttribute>
ビュー・オブジェクトには、実行時に問合せのSELECTリストにSQL計算属性のSQL式が含まれます。この式はデータベースが評価し、結果を問合せ内のその列の値として戻します。この値は、問合せを実行するたびに再評価されます。
一時属性は通常、データベースに格納されない小計などの計算式を使用可能にする場合に使用されます。
始める前に:
一時属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
定義する一時属性は、Groovy式言語を使用して評価できます。Groovyを使用すると、式や変数を文字列に挿入できます。この式は、ビュー・オブジェクト定義の一部として保存されます。詳細は、「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照してください。
一時属性を使用する場合の制限を理解しておく必要があります。詳細は、「一時属性によって定義された主キーによるビュー・オブジェクト問合せに関する必知事項」を参照してください。
次のタスクを完了する必要があります。
一時属性をビュー・オブジェクトに追加するには:
「アプリケーション」ウィンドウで、一時属性を定義するビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。
「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力し、「タイプ」ドロップダウンからJava属性タイプを選択し、「OK」をクリックします。
概要エディタの「属性」ページで、「詳細」タブをクリックし、「一時」オプションを選択します。
一時属性のデフォルト値が式で計算される場合は、「デフォルト値」の下の「式」チェック・ボックスを選択し、横にあるアイコンをクリックして「式エディタの編集」ダイアログを開きます。
「式エディタの編集」ダイアログで、属性のデフォルト値を計算するデフォルト値式を入力します。
一時属性の式では、ビュー・オブジェクトで定義された永続的属性から値を導出できます。エンティティ属性を参照する必要がある場合は、その属性をビュー・オブジェクト定義に追加しておく必要があります。
この属性が依存する属性を指定します。これらの属性を「使用可能」から「選択済」に移動します。
「OK」をクリックして、「式エディタの編集」ダイアログに入力した式を保存します。
必要に応じて、式の再計算をいつ実行するかの条件を「式値のリフレッシュ」フィールドで指定できます。再計算式を定義する手順は、デフォルト値式を定義するのと同じです。再計算式がtrueに評価された場合、デフォルト値式の再計算が行われます。
Country属性またはRegionId属性が変更されたときに属性が再計算されます。return (adf.object.isAttributeChanged("Country") || adf.object.isAttributeChanged("RegionId"));
注意:
定義した値式またはオプションの再計算式がベース・エンティティ・オブジェクトの属性を参照する場合は、「式エディタの編集」ダイアログでこれを依存性として定義する必要があります。「使用可能」リストでそれぞれの属性を特定し、それを「選択済」リストに移動します。ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。
始める前に:
一時属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
エンティティ・ベースのビュー・オブジェクトにエンティティ・オブジェクトの一時属性を追加するには:
特定のビュー・オブジェクト一時属性に対する属性レベルの検証規則は、エンド・ユーザーまたはプログラム・コードによる属性値の変更が試行されるとトリガーされます。属性を設定する順序は指定できないため、属性レベルの検証規則は、規則の成否がその属性の候補値のみに依存する場合にのみ使用する必要があります。
ビュー・オブジェクト一時属性に検証規則を追加する手順は、宣言的検証規則の作成方法と同じで、「検証ルールの追加」ダイアログを使用します。このダイアログを開くには、ビュー・オブジェクトの概要エディタで、「属性」ページの「検証ルール」セクションの「検証ルールの追加」ボタンをクリックします。まず、属性リストから一時属性を選択し、一時属性を更新可能として定義する必要があります。検証規則は、読取り専用の一時属性で定義できません。
始める前に:
属性UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。
また、異なるタイプの定義可能な検証規則を理解していると役立ちます。詳細は、「組込みの宣言的な検証規則の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
一時属性に検証規則を追加するには:
ビュー・オブジェクトの概要エディタで一時属性を追加すると、ビュー・オブジェクトのXMLドキュメントが更新され、新しい属性が反映されます。XMLでは、一時属性の<ViewAttribute>タグは、SQL計算属性の場合と類似していますが、Expressionプロパティがありません。
一時属性がGroovy式に準拠している場合は、適切な属性内に<TransientExpression>タグが作成されます。次の例は、Groovy式のXMLコードを示しています。Groovy式がOrdVOビュー・オブジェクトのSalesRepName属性に追加されています。このXML定義は、このGroovy式スクリプトが含まれている.bcsファイルがこのXML定義の一部であることを示しています(CodeSourceName=”OrdVORow”)。そのため、.bcsのファイル名はOrdVORow.bcsです。operations.xmlファイルもあり、この例ではOrdVOOperations.xmlという名前です。このoperations.xmlファイルには.bcsファイルを指し示すURIが含まれています。
<ViewAttribute
Name="SalesRepName"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="CHAR"
AliasName="VIEW_ATTR"
SQLType="VARCHAR">
<TransientExpression
Name="ExpressionScript"
trustMode="untrusted"
CodeSourceName="OrdVORow"/>
</ViewAttribute>
一時属性は、データ値のプレースホルダです。一時属性の「更新可能」プロパティを「常に」に変更すると、エンド・ユーザーは属性値を入力できるようになります。一時属性に計算値を表示する場合は、通常、「更新可能」プロパティを「なし」に設定し、ビュー・オブジェクトの概要エディタの「属性」ページにGroovy言語式を記述します。
また、一時属性を計算するためのJavaコードを記述する場合は、ビュー・オブジェクトの概要エディタにある「Java」ページの「編集」アイコンをクリックして開く「Java」ダイアログで、カスタム・ビュー行クラスを有効にし、アクセッサ・メソッドの生成を選択する必要があります。次に、一時属性のアクセッサ・メソッドの内部で、計算済値を戻すJavaコードを記述します。次の例に示すCustomerVORowImpl.javaビュー行クラスには、getFirstDotLast()メソッドの計算値を戻すJavaコードが含まれています。
// In CustomerVORowImpl.java
public String getFirstDotLast() {
// Commented out this original line since we're not storing the value
// return (String) getAttributeInternal(FIRSTDOTLAST);
return getFirstName().substring(0,1)+". "+getLastName();
}
一般に、一時属性ではアクセスのたびに主キー属性の再評価が強制されるため、一時属性による主キーの定義が適していないユースケースもあります。特に、複数の問合せが生成される可能性のあるADF Facesコンポーネント(ADFツリー・コンポーネントなど)にバインドされるビュー・オブジェクトでは、一時属性を使用した主キーの定義は避けることをお薦めします。このような状況では、主キーである一時属性の再評価が必要となるため、アプリケーションのパフォーマンスが低下します。
また、プログラムによるビュー・オブジェクトの問合せで主キーが一時属性に依存する場合、ユーザーがビュー・オブジェクトのキャッシュ行の外にUIをスクロールすると、NULLポインタ例外を受け取る可能性があることにも注意してください。この場合、ビュー・オブジェクト問合せがデータベース表から生成されないため、ビュー・オブジェクト実装は、ViewObjectImplクラスのretrieveByKey()メソッドをオーバーライドし、行を返す(または、行がない場合には空の配列を返す)必要があります。
このメソッドをオーバーライドすると、ADFビジネス・コンポーネントでfindByKey()を実行し、キャッシュからリクエストされた行を最初に検索できます。(主キーが一時属性であるために)これに失敗した場合、ADFビジネス・コンポーネントは、retrieveByKey()オーバーライドを実行し、入力されるキーと一致する行を取得するように定義した操作を実行します。このメソッドのデフォルトの実装は、データベース問合せを発行し、データベースから行を取得しようとします。
protected Row[] retrieveByKey(ViewRowSetImpl rs, Key key,
int maxNumOfRows, boolean skipWhere)
このメソッドには次の引数があります。
maxNumOfRowsは、findByKey()の呼出しに渡したmaxNumOfRowsです。これは、1 .. nまたは-1です。nは、渡されたキーと一致するキーを持つ行をn行検索していることを意味します。-1はすべての行が一致することを意味します。キーが部分キーでビュー・オブジェクトが複数のエンティティ・オブジェクトに基づいている場合、ビュー・オブジェクトの複数の行がキーと一致する可能性があります。
skipWhereは、findByKey()が基本ビュー・オブジェクトとして同じWHERE句を適用する必要があるかどうかを制御します。基本ビュー・オブジェクトにWHERE句DEPTNO = 10があり、skipWhereがfalseの場合、バッキング・ストアから行を検索しているときに同じWHERE句を適用することを想定されます。skipWhereがtrueの場合、基本ビュー・オブジェクトからのWHERE句は関係ありません。
ADFビュー・オブジェクトを定義して特定の日付範囲内のデータを問い合せ、その日付範囲に入るビュー行に制限できます。
特定の日付範囲を通してデータの問合せを行う必要があるアプリケーションでは、有効日が指定された行セットを生成できます。有効日が指定されたビュー・オブジェクトを定義するには、有効日が指定されたエンティティ・オブジェクトに基づくエンティティ・ベースのビュー・オブジェクトを作成する必要があります。ビュー・オブジェクトの有効日をどのように使用するかについては、設計時にビュー・オブジェクトに関するメタデータを使用してユーザーが制御できます。実行時には、ADFビジネス・コンポーネントにより、有効日に基づいてビュー行を制限するための問合せフィルタが生成されます。
有効日に関する問合せフィルタが生成されるかどうかは、ビュー・オブジェクトの「プロパティ」ウィンドウに表示される「有効日指定」プロパティの値によって決まります(このプロパティを表示するには、ビュー・オブジェクトの概要エディタの「一般」タブをクリックして、「プロパティ」ウィンドウの「名前」セクションを開きます)。
ビュー・オブジェクトの概要エディタでは、WHERE句に含まれる有効日指定の問合せ句は表示されません。「問合せのテスト」ダイアログを使用すると、この句を表示できます。有効日の問合せフィルタは通常、次のようになります。
(:Bind_SysEffectiveDate BETWEEN CustomerVO.EFFECTIVE_START_DATE AND CustomerVO.EFFECTIVE_END_DATE)
実行時に、問合せに対するバインド値がルート・アプリケーション・モジュールのプロパティから取得されるか、バインド値をビュー・オブジェクトに直接割り当てることができます。トランザクションに対して有効日を設定する場合は、次のようなコード・スニペットを使用します。
am.setProperty(ApplicationModule.EFF_DT_PROPERTY_STR, new Date("2008-10-01));
アプリケーション・モジュール上でEFF_DT_PROPERTY_STRを設定しない場合、問合せフィルタでは現在の日付が使用され、ビュー・オブジェクトからは現在の日付でフィルタリングされた有効な行が戻されます。
ビュー・オブジェクトには、ビュー行に対する有効日の設定に使用できるSysEffectiveDateという独自の一時属性があります。この一時属性は、有効日を指定できるようにビュー・オブジェクトを設定すると、ビュー・オブジェクト内に生成されます。有効日を設定しない場合、新規行およびデフォルト行に対するSysEffectiveDate属性の値は、アプリケーション・モジュールから導出されます。ADFビジネス・コンポーネントでは、DML操作中にのみビュー行からエンティティ・オブジェクトに有効日が伝播されます。
始める前に:
有効日が指定された行セットに関する知識が役立つ場合があります。詳細は、「有効日付範囲を使用したビュー・オブジェクト行の制限」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「特定の時点に関するデータを格納する方法」の説明に従い、有効日が指定されたエンティティ・オブジェクトを作成します。
「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従い、ビュー・オブジェクトの作成ウィザードを使用して、エンティティ・ベースのビュー・オブジェクトを作成します。
作成するビュー・オブジェクトは、作成済の有効日が指定されたエンティティ・オブジェクトに基づいている必要があります。ウィザードの「属性」ページで、エンティティ・オブジェクトの開始日と終了日を指定した有効日指定の属性を、ビュー・オブジェクトの「選択されたもの」リストに追加してください。
SysEffectiveDate属性を使用してビュー・オブジェクトに有効日を設定するには:
図に示すように、終了日の属性も正しく選択されていることを確認します。ビュー・オブジェクトで編集不可であることを示すため、これらのフィールドはグレー表示されています。
図5-17 ビュー・オブジェクトの概要エディタに表示される有効日設定
有効日が指定されたエンティティ・オブジェクトから、必要な属性がビュー・オブジェクトに継承されていることを確認したら、追加の手順は必要ありません。
有効日が指定された行は、通常のビュー行と同じように作成(挿入)できます。開始日および終了日は次のように指定できます。
ユーザーがアプリケーション・モジュールで有効日を指定します。開始日はこの有効日に設定され、終了日は指定可能な最後の日付に設定されます。
ADFビジネス・コンポーネントでは、指定可能な最後の日付は4712年12月31日と定義されています。
ユーザーが開始日および終了日のそれぞれの値を指定します(詳細設定)。
どちらの場合も、エンティティの検証中には、新規行によってギャップや重複が生じないようにチェックが実行されます。またポスト時には、ADFビジネス・コンポーネントにより、行の挿入時にギャップや重複が生じないよう、直前の行に対してロックが取得されます。
有効日が指定された行は、有効日が指定されていない行と同様に、Row.setAttribute()コールを使用して更新されます。ただし、目的の操作を有効にするためには、更新の前に、行に有効日のモードを設定しておく必要があります。ADFビジネス・コンポーネントでは、行の更新を開始するための様々なモードがサポートされています。
更新モードを設定するには、oracle.jbo.Rowクラスで定義された次のいずれかのモード定数を指定して、Row.setEffectiveDateMode(int mode)メソッドをコールします。
CORRECTION (修正モード)
有効開始日および有効終了日は変更されません。それ以外の属性値は変更される場合があります。これは行の更新に関する標準の動作です。
UPDATE (更新モード)
最新行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値のある行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は指定可能な最後の日付に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。
OVERRIDE(更新オーバーライド・モード)
変更された行の有効終了日が有効日として設定されます。次の行の有効開始日は有効日の翌日に設定され、次の行の有効終了日は指定可能な最後の日付に設定されます。
CHANGE_INSERT(変更挿入モード)
更新モードと似ていますが、変更挿入モードは、最新行ではなく過去の行に対する操作です。変更された行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値を持つ行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は次の行の有効開始日の前日に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。
ADFビジネス・コンポーネントでは、行の削除を開始するための様々なモードがサポートされています。RowSet.removeCurrentRow()やRow.remove()などのAPIコールを使用することにより、削除するビュー行をマークできます。
削除モードを設定するには、oracle.jbo.Rowクラスで定義された次のいずれかのモード定数を指定して、Row.setEffectiveDateMode(int mode)メソッドを起動します。
DELETE (削除モード)
行の有効終了日が有効日として設定されます。この行に対する操作は、削除から更新に変更されます。有効日でないキー値が同じであり、有効開始日が有効日より後になっている行はすべて削除されます。
NEXT_CHANGE(次の変更を削除するモード)
行の有効終了日が、有効日でないキー値が同じである次の行の有効終了日に設定されます。この行に対する操作は、削除から更新に変更されます。削除されるのは次の行です。
FUTURE_CHANGE(将来の変更を削除するモード)
行の有効終了日が指定可能な最後の日付に設定されます。この行に対する操作は、削除から更新に変更されます。有効日でないキー値が同じである将来の行はすべて削除されます。
ZAP (ZAPモード)
有効日でないキー値が同じである行がすべて削除されます。
有効日のモード定数は行インタフェースでも定義されます。
有効日が指定されたビュー・オブジェクトを作成すると、一時属性のSysEffectiveDateがエンティティ・オブジェクトから継承され、行の有効日が格納されます。通常は、挿入、更新および削除の操作によって一時属性が変更されますが、Oracle ADFフレームワークでは、有効日開始と有効日終了で適切な値を決定します。
概要エディタに表示される有効日が指定されたビュー・オブジェクトの問合せには、有効日の範囲のフィルタリングに必要なWHERE句は表示されません。WHERE句も含めて、有効日が指定されたビュー・オブジェクトの完全な問合せを表示するには、概要エディタの「問合せ」ページで問合せを編集し、「テストおよび説明」をクリックします。次のサンプルは、有効日の一般的な問合せと問合せフィルタを示しています。
SELECT OrdersVO.ORDER_ID, OrdersVO.CREATION_DATE,
OrdersVO.LAST_UPDATE_DATE
FROM ORDERS OrdersVO
WHERE (:Bind_SysEffectiveDate BETWEEN OrdersVO.CREATION_DATE AND
OrdersVO.LAST_UPDATE_DATE)
次の例は、有効日が指定されたビュー・オブジェクトの作成時に生成されるサンプルのXMLエントリを示しています。
<ViewObject
...
<!-- Property that enables date-effective view object. -->
IsEffectiveDated="true">
<EntityUsage
Name="Orders1"
Entity="model.OrdersDatedEO"
JoinType="INNER JOIN"/>
<!-- Attribute identified as the start date -->
<ViewAttribute
Name="CreationDate"
IsNotNull="true"
PrecisionRule="true"
IsEffectiveStartDate="true"
EntityAttrName="CreationDate"
EntityUsage="Orders1"
AliasName="CREATION_DATE"/>
<!-- Attribute identified as the end date -->
<ViewAttribute
Name="LastUpdateDate"
IsNotNull="true"
PrecisionRule="true"
IsEffectiveEndDate="true"
EntityAttrName="LastUpdateDate"
EntityUsage="Orders1"
AliasName="LAST_UPDATE_DATE"/>
<!-- The SysEffectiveDate transient attribute -->
<ViewAttribute
Name="SysEffectiveDate"
IsPersistent="false"
PrecisionRule="true" Type="oracle.jbo.domain.Date"
ColumnType="VARCHAR2"
AliasName="SysEffectiveDate"
Passivate="true"
SQLType="DATE"/>
</ViewObject>
有効日が指定されたアソシエーションおよびビュー・リンクを使用すると、有効日を考慮した問合せを作成できます。この問合せの実行中には、駆動行の有効日がバインド・パラメータとして渡されます。
「アソシエーションの作成」ウィザードまたは「ビュー・リンクの作成」ウィザードを使用すると、2つのエンティティの間に有効日が指定されていないアソシエーションを作成できますが、JDeveloperでは、どちらかの終了日が有効日であれば、アソシエーションまたはリンクは有効日が指定されたものとしてデフォルトで作成されます。ただし、有効日が指定されたオブジェクトと指定されていないオブジェクトとの間にアソシエーションまたはビュー・リンクが存在する場合は、実行時にADFビジネス・コンポーネントによって、問合せ句の生成と有効日のバインドが行われる前に、ビュー・オブジェクトまたはエンティティ・オブジェクトに対して有効日の指定が検証されます。有効日は、最初に駆動行から取得されます。駆動行から取得できない場合は、ルート・アプリケーション・モジュールのEFF_DT_PROPERTY_STRプロパティから取得されます。アプリケーション・モジュール上でEFF_DT_PROPERTY_STRを設定しない場合、駆動行に対する問合せフィルタでは現在の日付が使用され、さらにアソシエーションまたはビュー・リンクの相手側にも現在の日付が適用されます。
ビュー・オブジェクトの作成ウィザードを使用し、複数の表が含まれる結合問合せを宣言して定義します。
使用する問合せは、その多くが外部キーによって関連付けられた複数の表を対象としています。このシナリオでは、それらの表を1つのビュー・オブジェクト問合せに結合し、メインの問合せ結果の各行に追加情報を表示します。宣言オプションを使用する問合せの定義には、「ビュー・オブジェクトの作成」ウィザードを使用します。ビュー・オブジェクトを読取り専用にするかエンティティ・ベースにするかによって、結合の定義方法は異なります。
エンティティ・ベースのビュー・オブジェクトを使用する場合、「ビュー・オブジェクトの作成」ウィザードでは、エンティティ間に定義されている既存のアソシエーションが使用され、ビュー・オブジェクトの結合WHERE句が自動的に作成されます。エンティティ・オブジェクトから得られる結合のタイプは宣言的に指定できます。内部結合(等価結合)と外部結合のどちらもサポートされています。
非エンティティ・ベースのビュー・オブジェクトを使用する場合は、「SQL Builder」ダイアログを使用してビュー・オブジェクトの結合WHERE句を構築できます。この場合、結合する表から列を選択する必要があります。
図5-18は、結合問合せを定義するビュー・オブジェクトによって、問い合せられた2つの表から取得した行を示しています。この結合は、単一のフラット化された結果です。
図5-18 結合問合せ結果
ビジネス・アプリケーションでは、外部キー属性が示す内容をエンド・ユーザーが理解しやすいようにするために、プライマリ・ビジネス・ドメイン・オブジェクトとともにセカンダリ参照情報から情報を補足するのが一般的です。ItemEOエンティティ・オブジェクトを例として考えてみます。このオブジェクトには、次のようなNumber型の外部キー属性が含まれます。
ItemId: 発注項目が関係する製品を示します。
このような未処理の数値のみをエンド・ユーザーに示しても、あまり役立ちません。アプリケーションの使いやすさを向上させるには、ビュー・オブジェクトに関連付けられたエンティティ・オブジェクトからの参照情報の表示が理想的です。一般的な解決方法の1つとして、プライマリ情報と参照情報の組合せを取得する結合問合せを実行する方法があります。この方法は、参照表に対する特別な問合せに基づいて、問合せ対象の行ごとに参照情報とともにダミー・フィールドを移入するのと同じです。
エンド・ユーザーがデータを編集して外部キー値を変更できる場合、この方法は別の課題をもたらします。この場合、エンティティ・ベースのビュー・オブジェクトは、常に最新の状態の参照情報を簡単に組み込む機能をサポートしています。この機能を活用するには、ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名として機能するエンティティ・オブジェクトと、参照情報を提供するエンティティ・オブジェクト間にアソシエーションが確立されていることが必要です。
結合ビュー・オブジェクトに参照エンティティを取り込む場合は、「ビュー・オブジェクトの作成」ウィザードを使用します。「ビュー・オブジェクトの作成」ウィザードでは、次のいずれかの結合タイプを指定します。
内部結合
ビュー・オブジェクトから、(各エンティティが同じ主キー列を定義している)2つ以上のエンティティ・オブジェクト間のすべての行を戻す場合に選択します。結合されたエンティティに主キー値がない場合は、内部結合ビュー・オブジェクトから戻される行はありません。
外部結合
ビュー・オブジェクトから、1つのエンティティ・オブジェクトに存在するすべての行を(それに対応する行が結合されたエンティティ・オブジェクトになくても)戻す場合に選択します。左外部結合と右外部結合両方がサポートされています。左および右を指定すると、アソシエーションで指定された関連元(左)および関連先(右)のエンティティ・オブジェクトが参照されます。デフォルトの内部結合を外部結合に変更する方法の詳細は、「必要に応じたデフォルトの結合句の外部結合への変更」を参照してください。一致する外部エンティティ行が見つからない(存在しない)場合の詳細は、「外部結合に関する必知事項」を参照してください。
内部結合と外部結合のどちらにおいても、次のオプションを使用できます。
参照
エンティティ・オブジェクトのデータをビュー・オブジェクトの参照情報として使用する場合に選択します。データの自動参照がサポートされているため、制御キー属性が変更される場合は、属性値がエンティティ・キャッシュから動的にフェッチされます。この設定が実行時動作に与える影響の詳細は、「実行時の処理: ビュー行の作成」を参照してください。
更新可能
ビュー・オブジェクトによってエンティティ・オブジェクトの任意のエンティティ属性が変更されないようにする場合は選択を解除します。デフォルトでは、「選択済」リストの先頭にあるエンティティ・オブジェクト(プライマリ)は更新可能であり、後続のエンティティ・オブジェクト(セカンダリ)は更新できません。複数の更新可能なエンティティ・オブジェクトの慣用名を使用して結合ビュー・オブジェクトを作成する方法の詳細は、「多相エンティティ・オブジェクトの慣用名を持つサブタイプ・ビュー・オブジェクトを作成する方法」を参照してください。
行削除のサポート
エンティティが更新可能として定義されており、かつUIの行削除のアクションにより関連する参照エンティティ・オブジェクトが削除されるようにする場合に選択します。このオプションは、プライマリ・エンティティに対しては無効で、主として外部結合されたエンティティに使用されます。たとえば、注文項目は削除できますが、結合ビュー・オブジェクトから行削除がコールされた場合、その注文は削除できないようにする必要があります。この設定が様々な結合タイプのビューの行削除に及ぼす影響の詳細は、「エンティティ・ベースの結合と行削除サポートに関する必知事項」および「コンポジット・アソシエーションと結合に関する必知事項」を参照してください。
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
結合問合せに関連したOracle Databaseの機能を理解しておくと役に立つ場合があります。『Oracle Database SQL言語リファレンス』の「SQL問合せおよび副問合せ」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクトを結合するビュー・オブジェクトを作成するには:
「アソシエーション」ドロップダウン・リストには、選択したセカンダリ・エンティティ・オブジェクトの慣用名をプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションの名前が表示されます。たとえば、図5-19は、プライマリ・エンティティ・オブジェクトの慣用名ItemEOの他に、セカンダリの参照エンティティ・オブジェクトの慣用名ProductEOを1つ追加した結果を示しています。このセカンダリ・エンティティ・オブジェクトの慣用名に関連するアソシエーションは、SItemProductIdFkAssoc.ProductEOです。
参照エンティティ・オブジェクトやセカンダリ・エンティティ・オブジェクトが同じ表から導出される場合は、属性名が重複することがあります。図5-20では、「属性の選択」ドロップダウン・リストの属性Idが、「名前」フィールドでProductIdという名前に変更されています。
セカンダリ・エンティティ・オブジェクトの慣用名をビュー・オブジェクトに追加する場合、このエンティティ・オブジェクトの慣用名は、選択済エンティティのリストで上位にあるエンティティ・オブジェクトの慣用名に関連付けられます。この関係は、ビュー・オブジェクトの概要エディタの「エンティティ・オブジェクト」ページの「アソシエーション」ドロップダウン・リストに表示されるエンティティ・アソシエーションによって確立されます。エディタの「アソシエーション」ドロップダウン・リストを使用して、セカンダリ・エンティティ・オブジェクトの慣用名を、「選択されたもの」リストの上位にある目的のエンティティ・オブジェクトの慣用名に関連付けるエンティティ・アソシエーションを選択します。上位のエンティティ・オブジェクトの慣用名の名前は、「ソースの使用方法」ドロップダウン・リストで指定されます。
プライマリ・エンティティ・オブジェクトの慣用名の表とそれに関連付けられているセカンダリ・エンティティ・オブジェクトの慣用名の表の間に結合用のWHERE句が作成される場合、デフォルトでは常に内部結合が作成されます。必要であれば、デフォルトの内部結合句を左または右外部結合として変更もできます。左を指定すると、選択したアソシエーションで指定した関連元エンティティ・オブジェクトが参照されます。これは、「ソースの使用方法」ドロップダウン・リストで指定されたエンティティです。右を指定すると「選択されたもの」リストで選択している現在のセカンダリ・エンティティ・オブジェクトの慣用名が参照されます。
左外部結合では、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)右の表に対応する行がない場合でも、(「ソースの使用方法」リストで指定したエンティティ・オブジェクトに関連する)左の表のすべての行が結合に含まれます。右外部結合では、その逆で、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)左の表に対応する行がない場合でも、(「選択されたもの」リストで指定したエンティティ・オブジェクトに関連する)右の表のすべての行が結合に含まれます。
たとえば、ユーザーにまだメンバーシップ・ステータスが割り当てられていないとします。この場合、MembershipId属性はNULLになります。デフォルトの内部結合条件では、MEMBERSHIPS_BASE表からこれらのユーザーは取得されません。MembershipDiscountsVOビュー・オブジェクトを介して、メンバーシップ・ステータスを持たないユーザーを表示可能および更新可能にする必要がある場合は、概要エディタにある「エンティティ・オブジェクト」ページを使用して、ビュー・オブジェクトについての問合せを、MEMBERSHIP_ID列のnullになる可能性のある値についてのMEMBERSHIPS_BASE表に対する左外部結合に変更できます。ユーザー・エンティティをビュー・オブジェクトに追加する場合は、「結合タイプ」として「左外部結合」を選択します。図5-21に示すように、アソシエーションPersonsMembershipsBaseFkAssocでは、結合の左側としてソースの慣用名MembershipBaseEO、右側として選択済エンティティ・オブジェクトの慣用名PersonEOを指定します。ビュー・オブジェクトMembershipDiscountsVOでは、これら両方のエンティティ・オブジェクトに関連する行が結合され、またPersonEOに対する左外部結合の定義により、このビュー・オブジェクトは、PersonEOに関連する表に対応する行がない場合でも、MembershipBaseEOに関連する表の行を返すことができます。
図5-21 結合されたエンティティからNULLの行を返す外部結合の設定
ビュー・オブジェクトの更新されたWHERE句の等号の右側では、データを左外部結合に含む必要のない関連表に対して(+)演算子が追加されています。
PersonEO.MEMBERSHIP_ID = MembershipBaseEO.MEMBERSHIP_ID(+)
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
内部結合を外部結合に変更するには:
セカンダリ・エンティティ・オブジェクトの慣用名を追加したら、ビュー・オブジェクトの概要エディタを使用して、ビュー・オブジェクトに組み込むこれらの新しいオブジェクトの慣用名から特定の追加属性を選択できます。
ヒント:
概要エディタでは、「属性」ページに表示される属性を、エンティティ・オブジェクトの慣用名を基準にソートできます。デフォルトでは、属性表には、基礎となるエンティティ・オブジェクトに表示される順番に属性が表示されます。エンティティ・オブジェクトの慣用名を基準に属性をソートするには、属性表の「エンティティ・オブジェクトの慣用名」列のヘッダーをクリックします。属性表に「エンティティ・オブジェクトの慣用名」列が表示されない場合は、表の右上隅(ボタン・バーの下)のドロップダウン・メニューをクリックし、「列の選択」を選択して、この列を「選択されたもの」リストに追加します。
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
結合問合せに関連したOracle Databaseの機能を理解しておくと役に立つ場合があります。詳細は、『Oracle Database SQL言語リファレンス』の「SQL問合せおよび副問合せ」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
セカンダリ・エンティティ・オブジェクトの慣用名から属性を選択するには:
プライマリ・エンティティ・オブジェクトの慣用名の主キー属性に対応するビュー・オブジェクト属性は、ビュー行を識別するための主キーとして機能します。セカンダリ・エンティティ・オブジェクトの慣用名を追加すると、これらの主キー属性に対応するビュー・オブジェクト属性はビュー行キーの一部としてマークされます。ビュー・オブジェクトが単一の更新可能なプライマリ・エンティティ・オブジェクトの慣用名と多くの参照エンティティ・オブジェクトの慣用名で構成されている場合、ビュー行を一意に識別するにはプライマリ・エンティティ・オブジェクトの慣用名の主キー属性で十分です。セカンダリ・エンティティ・オブジェクトの慣用名から取り込まれた追加キー属性は不要になるため、これらの「キー属性」設定を無効にする必要があります。
たとえば、プライマリ・エンティティ・オブジェクトの慣用名ShippingOptionEOを持つビュー・オブジェクトに基づいて、エンティティ・オブジェクトの慣用名ShippingOptionTranslationEOの「キー属性」プロパティを無効にすることができ、これにより、この追加キー属性ShippingTranslationsIdに対してこのプロパティは選択されなくなります。
ただし、ビュー・オブジェクトが複数の更新可能なプライマリ・エンティティ・オブジェクトの慣用名で構成されている場合、ビュー行を識別するための主キーは、少なくともビュー・オブジェクトに含まれるすべての更新可能なエンティティ・オブジェクトの慣用名のすべてのキー属性で構成されている必要があります。
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
不要なキー属性を削除するには:
通常、ビュー・オブジェクトに自動的に追加された主キー属性は表示する必要がないため、属性の「ヒントの表示」プロパティを「非表示」に設定できます。
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
主キー属性を非表示にするには:
図5-7は、エンティティ・ベースのビュー・オブジェクトItemVOと、この問合せ文で参照される2つのエンティティ・オブジェクトの慣用名を示しています。点線は、問合せのSELECTリストの列を、ビュー・オブジェクトで使用されるエンティティ・オブジェクトの属性にマップする、エンティティ・ベースのビュー・オブジェクトのXMLドキュメントで取得されるメタデータを表します。エンティティ・ベースのビュー・オブジェクトの問合せにより、プライマリ・エンティティ・オブジェクトの慣用名(ItemEO)のデータと、セカンダリの参照エンティティ・オブジェクトの慣用名(ProductEO)のデータが結合されます。
図5-22 複数のエンティティ・オブジェクトの属性をマップするビュー・オブジェクト
結合ビュー・オブジェクトを作成して、参照別のセカンダリ・エンティティ・オブジェクトの慣用名を1つ以上組み込むと、ビュー・オブジェクトのXMLドキュメントが更新され、追加のエンティティ・オブジェクトの慣用名に関する情報が組み込まれます。たとえば、ビュー・オブジェクトのItemVO.xmlファイルに、別の参照エンティティ・オブジェクトの慣用名が含まれているとします。この情報は、複数の<EntityUsage>要素に記録されていることがわかります。たとえば、図5-5は、プライマリ・エンティティ・オブジェクトの慣用名を定義するエンティティ・オブジェクトの慣用名のエントリを示しています。
<EntityUsage Name="ItemEO" Entity="oracle.summit.model.entities.ItemEO"/>
セカンダリの参照エンティティ・オブジェクトの慣用名のエントリはこれとは若干異なり、次の例に示すエンティティ・オブジェクトの慣用名のように、これをプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションに関する情報が含まれます。
<EntityUsage Name="ProductEO" Entity="oracle.summit.model.entities.ProductEO" Association="oracle.summit.model.entities.assoc.SItemProductIdFkAssoc" AssociationEnd="oracle.summit.model.entities.assoc. SItemProductIdFkAssoc.ProductEO" SourceUsage="oracle.summit.model.views.ItemVO.ItemEO" ReadOnly="true" Reference="true" Participant="false" JoinType="INNER JOIN/>
XMLファイル内の各属性エントリは、参照先のエンティティ・オブジェクトの慣用名を示します。たとえば、次の例のOrdId属性のエントリは、これがItemEOエンティティ・オブジェクトの慣用名に関連付けられており、Name属性がProductEOエンティティ・オブジェクトの慣用名に関連付けられていることを示しています。
<ViewAttribute Name="OrdId" IsNotNull="true" EntityAttrName="OrdId" EntityUsage="ItemEO" AliasName="ORD_ID" > </ViewAttribute> ... <ViewAttribute Name="Name" IsUpdatable="true" IsNotNull="true" EntityAttrName="Name" EntityUsage="ProductEO" AliasName="NAME" > </ViewAttribute>
「ビュー・オブジェクトの作成」ウィザードでは、このアソシエーション情報が設計時に使用され、ビュー・オブジェクトの結合WHERE句が自動的に作成されます。この情報が実行時に使用されることにより、エンド・ユーザーによって外部キー属性値が変更されたときに参照情報を最新の状態に保つことが可能になります。
外部結合を指定した場合、一致する外部エンティティ行が見つからないときには、問合せのその部分に関して、データベースからNULLが返されます。たとえば、外部結合のDeptEmpViewでDeptエンティティとEmpエンティティを結合するときに、Dept 40に従業員が存在しないとします。その場合は、Dept 40の行に達すると、データベースから[40, null]が返され、ADFビジネス・コンポーネントでDept 40のエンティティ行と空白のEmpエンティティ行が作成されます。ビュー・オブジェクトのEmpエンティティが更新可能と設定されている場合は、この空白のエンティティ行に属性値を設定できます。その後、トランザクションをコミットすると、新しいエンティティ行が挿入されます。
CustomerとOrderというエンティティ・オブジェクトがあり、エンティティ・アソシエーションCustOrderIdFKAssoc (Customerのカーディナリティはmanyで、Orderのカーディナリティは1)に基づいてビュー・オブジェクト結合を作成するとします。
Orderエンティティ(カーディナリティが1のプライマリ・エンティティ)からCustomerエンティティ(カーディナリティがmanyのセカンダリ・エンティティ)への結合である、1対多の結合ビュー・オブジェクトOrderCustVOを作成すると、多数のOrder行に対して同じCustomerエンティティ行が返されます。
Customer(プライマリ、many)からOrder(セカンダリ、1)への結合である、多対1の結合ビュー・オブジェクトCustOrderVOを作成すると、多数のOrder行を持つ同じCustomerエンティティ行が返されます。
OrderCustVO (1対多)の場合は、Customerが参照エンティティであり、エンド・ユーザーが行を削除するとOrderエンティティ行のみが削除され、Customerは影響を受けません。同様に、CustOrderView(多対1)の場合は、Orderが参照エンティティであり、エンド・ユーザーが行を削除するとCustomerエンティティ行のみが削除され、Orderは影響を受けません。
ただし、CustOrderVO(多対1)の場合は、エンド・ユーザーが1つの行を削除すると、結合ビュー・インスタンスから複数の行が削除されます。たとえば、Customer 10に3つの発注(A、B、C)があるとします。エンド・ユーザーがこの中の最初の結合ビュー行である[10, A]を削除すると、実際には[10, A]、[10, B]および[10, C]の3つのビュー行が削除されます。エンティティ・レベルでは、Orderは参照エンティティであるため、Customer 10エンティティ行のみが削除されます。
1対多の結合(たとえばOrderCustVOビュー・オブジェクト)と多対1の結合(たとえばCustOrderVOビュー・オブジェクト)を作成し、セカンダリ・エンティティ・オブジェクトでは「行削除のサポート」が有効になっているとします(また、Customer 10にはOrder A、B、Cがあるものとします)。
1対多の結合OrderCustVOを作成し、Customerエンティティ・オブジェクトで「行削除のサポート」が有効になっていると仮定すると、エンド・ユーザーが[A, 10]を削除すると、Order Aエンティティ行が最初に削除され、その後Customer 10エンティティ行が削除されます。このCustomer 10が削除されるときには、実際にはそのエンティティ行を参照するすべてのビュー行が削除されます。つまり、[A, 20]と[A, 30]も削除されます(合計3つのビュー行)。
多対1の結合CustOrderVOを作成し、Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっていると仮定すると、エンド・ユーザーが[10, A]を削除すると、Customer 10エンティティ行が最初に削除されます。その後、そのエンティティ行を参照しているすべてのビュー行が削除されます。つまり、[20, A]と[30, A]もビューから削除されます。その後、Order Aエンティティ行が削除されます。
エンティティ・オブジェクトOrderおよびOrderItemの間のアソシエーションがコンポジット・アソシエーションで、これらのエンティティに基づいてビュー・オブジェクト結合を作成するとします。Order AにはItem 1、2、3が含まれるものとします。
ItemOrdVOビュー・オブジェクトの場合、Order(セカンダリ)は参照エンティティであり、エンド・ユーザーが[1, A]を削除しても、1のOrderItemエンティティ行のみが削除され、問題は発生しません。しかし、Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、エンド・ユーザーが[1, A]を削除すると、Item 1のエンティティ行の削除後、Order Aの削除も試行されます。ただし、コンポジット関係があるため、この操作は失敗し、RemoveWithDetailsExceptionがスローされます。これは、Order AにはまだOrder Aに属するOrderItem 2とOrderItem 3が存在するからです。
OrdItemVOビュー・オブジェクトの場合は、Item(セカンダリ)エンティティが参照エンティティであり、エンド・ユーザーが[A, 1]を削除するとOrder Aのエンティティ行の削除も試行されます。ただし、コンポジット関係があるため、この操作は失敗し、RemoveWithDetailsExceptionがスローされます。これは、Order AにはまだOrder Aに属するItem 1、Item 2およびItem 3が存在するからです。
Item(セカンダリ)エンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、[A, 1]を削除すると、Order Aに子の行があるために同じ例外が発生します。
エンティティ・アソシエーションで、「コンポジット・アソシエーション」の「カスケード削除の実装」が有効である場合は、異なる状況になります。
ItemOrderVOビュー・オブジェクトの場合、Orderは参照エンティティであり、エンド・ユーザーが[1, A]を削除しても、Item Aのエンティティ行が削除されるのみです(例外はスローされません)。Orderエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、エンド・ユーザーが[1, A]を削除すると、Item Aが最初に削除され、その後Order Aが削除されます。カスケード削除が有効になっているため、Order Aの削除により、Item 2およびItem 3を含む、Order Aの残りのすべての子も削除されます。その結果、ビュー行[2, A]および[3, A]がビュー・インスタンスから削除されます。
同様に、OrderItemVOビュー・オブジェクトの場合は、Itemが参照エンティティであり、エンド・ユーザーが[A, 1]を削除するとOrder Aが削除されます。「カスケード削除の実装」が有効になっているため、Item 1、2および3を含む、Order Aのすべての子も削除されます。その結果、ビュー行[A, 2]、[A, 2]および[A, 3]がビュー・インスタンスから削除されます。
Itemエンティティ・オブジェクトで「行削除のサポート」が有効になっている場合は、同じ動作になり、3つのビュー行すべてが削除されます。
2つの表を結合する読取り専用ビュー・オブジェクトを作成するには、「ビュー・オブジェクトの作成」ウィザードを使用します。
始める前に:
ビュー・オブジェクトの型により結合に影響を及ぼす仕組みに関する知識があると役立ちます。詳細は、「結合問合せ結果での複数表の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
2つの表を結合する読取り専用ビュー・オブジェクトを作成するには:
新規ビュー・オブジェクトをテストするには、アプリケーション・モジュールを編集し、「データ・モデル」ページで新規ビュー・オブジェクトのインスタンスをデータ・モデルに追加します。次にOracle ADFモデル・テスターを使用して、結合問合せが予期したとおりに動作しているかどうかを検証します。データ・モデルを編集してOracle ADFモデル・テスターを実行する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。
「SQL文」ダイアログの「クイックピック・オブジェクト」ページでは、他の表に関連する外部キーも含め、自分のスキーマで表を参照できます。問合せの選択リストに列を組み込む場合は、目的の列を「使用可能」リストから「選択済」リストに移動します。たとえば、図5-23は、S_PRODUCT_CATEGORIES表からCATEGORY列を選択すると同時に、S_PRODUCT表からID、NAMEおよびSUGGESTED_WHLSL_PRICEの各列を選択した結果を示しています。2番目の表の列は、「使用可能」リストのS_PRODUCT_CATEGORY_ID_FK外部キーの下に表示されています。外部キーによって結合された表から列を選択すると、必要な結合句が「SQL文」ダイアログで自動的に決定されます。
図5-23 結合を定義する、ビュー・オブジェクトの「SQL文」ダイアログ
必要に応じて、「SQL文」ダイアログの「WHERE句」ページで式を定義します。問合せの作成を終了する場合は、「SQL文」ダイアログの「OK」をクリックします。概要エディタの「問合せ」ページに、次の例に示すような問合せが表示されます。
SELECT
S_PRODUCT.ID ID,
S_PRODUCT.NAME NAME,
S_PRODUCT.SUGGESTED_WHLSL_PRICE SUGGESTED_WHLSL_PRICE,
S_PRODUCT_CATEGORIES.CATEGORY CATEGORY
FROM
S_PRODUCT JOIN S_PRODUCT_CATEGORIES ON S_PRODUCT.CATEGORY_ID =
S_PRODUCT_CATEGORIES.ID
「ビュー・オブジェクトの作成」ウィザードの「属性」ページでは、作成プロセスの一部としてビュー・オブジェクト属性の名前を直接変更できます。ここでビュー・オブジェクトの名前を変更しておくと、使用する属性名がわかっている場合にビュー・オブジェクトを再度編集する必要がなくなります。また、列の別名を割り当てることにより、Javaに適したデフォルトのビュー・オブジェクト属性名を変更することもできます。「カスタムSQLモードの計算式の属性名」を参照してください。
SELECTまたはFROM問合せ句を完全に制御する必要があるかどうかに応じて、標準モードまたはカスタムSQLモードでエンティティ・オブジェクトを定義できます。
標準モードでエンティティ・ベースのビュー・オブジェクトを定義する場合、WHERE句とORDER BY句はすべてを指定できますが、デフォルトでは、FROM句とSELECTリストは自動的に導出されます。FROM句は関係するエンティティ・オブジェクトの慣用名に関連する表の名前から決定されますが、SELECTリストは次のものが基になります。
関係するエンティティ・マップ属性の基礎となる列名
SQL計算属性のSQL式
問合せでSELECT句またはFROM句を完全に制御する必要がある場合は、カスタムSQLモードを有効にできます。
ヒント:
JDeveloperのビュー・オブジェクト・エディタとウィザードでは、選択内容に応じたSQLの生成が完全にサポートされています。たとえば、そのような2つのオプションを使用すると、外部結合を宣言的に定義して、宣言SQLモード(実行時までSQLが生成されない)で作業することができます。
SQL文を完全に制御する必要がある場合は、「ビュー・オブジェクトの作成」ウィザードでカスタムSQLモードを使用してその指定ができます。作成したカスタムSQLビュー・オブジェクトは、主に、UNIONまたはGROUP BY問合せを記述する必要がある場合に役立ちます。また、キー属性をマークしている場合は、ビュー・オブジェクト・ベースのキー存在バリデータで使用されるSQLベースの検証問合せを作成する必要がある場合に、カスタムSQLビュー・オブジェクトを作成できます。
エンティティ・ベースのビュー・オブジェクトを使用する場合とエンティティ・オブジェクトに基づかないカスタムSQLビュー・オブジェクトを使用する場合のトレードオフの詳細は、「読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用方法」を参照してください。
カスタムSQLビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能な「ビュー・オブジェクトの作成」ウィザードを使用します。
始める前に:
ビュー・オブジェクトに関する知識が役立つ場合があります。詳細は、「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
カスタムSQLビュー・オブジェクトを作成する手順:
有効なSQL文を「選択」テキスト・ボックスに入力するか、貼り付けます。問合せ文では、WHERE句とSort By句を使用できます。たとえば、図5-24は、WHERE句とOrder By句を使用して、アプリケーションで使用される言語の国コードのリストを問い合せる文を示しています。
「クエリー・ビルダー」をクリックして「SQL文」ダイアログを開き、そこで問合せ文を作成します。
注意:
「問合せ」ページではなく、「エンティティ・オブジェクト」ページが表示された場合は、ウィザードのステップ1に戻り、「カスタムSQL問合せ」を選択してあることを確認してください。
「ビュー・オブジェクトの作成」ウィザードでは、図5-25のように、データベースからキー属性が自動検出され、「キー属性」チェック・ボックスが選択されます。キー属性を定義しなかった場合、ビュー・オブジェクト・コレクションに基づくデータ・コントロールを持つADF Facesコンポーネントが、実行時に予期しない動作をすることがあります。
図5-25 「ビュー・オブジェクトの作成」ウィザードの「属性の設定」ページ
注意:
「ADFビジネス・コンポーネント」ウィザードおよびエディタのデフォルトの規則では、属性名に頭文字が大文字表記の名前を使用します。これは、最初の文字を大文字で表し、名前が複数の単語で構成されている場合には、読みやすくするために名前の途中でも大文字を使用する表記法です。
カスタムSQLモードを使用してビュー・オブジェクトを作成する際、JDeveloperでは最初にSELECTリストの列から次を推測する問合せが解析されます。
Javaに適したビュー属性名(COUNTRY_NAMEではなくCountryNameなど)
デフォルトでは、SELECTリスト列名に対応する、Javaに適したビュー・オブジェクト属性名がウィザードによって作成されます(図5-26を参照)。
ビュー・オブジェクト属性の名前を使用して、ビュー・オブジェクトの名前別結果セットの任意の行のデータにアクセスする方法は、「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。
各属性のSQLおよびJavaデータ型
SOME_COLUMN_NAMEのようにアンダースコアで区切られた列名の各部分は、SomeColumnNameのような単語の最初を大文字にした属性名に変えられます。ビュー・オブジェクト属性名はSELECTリストの基礎となる問合せ列に対応しますが、ビュー・オブジェクト・レベルでの属性名とは必ずしも一致しません。
ヒント:
ビュー・オブジェクト属性の名前は、基礎となる問合せを変更しなくても、より適切な名前に変更できます。
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLドキュメントが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのCountriesVOという名前のビュー・オブジェクトに対しては、プロジェクトのソース・パスに./lookups/CountriesVO.xmlというXMLファイルが作成されます。
ビュー・オブジェクト設定を表示するには、「アプリケーション」ウィンドウで目的のビューを選択して、「構造」ウィンドウを開きます。「構造」ウィンドウは、SQL問合せや属性のリストなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースに移動」を選択します。
カスタムSQLモードを有効にするには、「ビュー・オブジェクトの作成」ウィザードの「問合せ」ページで「カスタムSQLの書込み」を選択します。ビュー・オブジェクトの概要エディタで、既存のエンティティ・ベースのビュー・オブジェクトのSQL文を変更することもできます。概要エディタで、「問合せ」ページに移動し、「カスタムSQLの書込み」を選択します。
カスタムSQLモードを有効にすると、概要エディタまたはウィザードの「問合せ」ページの「選択」テキスト・ボックスが完全に編集可能になり、SQL文全体が表示されます。このテキスト・ボックスを使用して、SQL問合せのすべての部分を変更できます。
カスタムSQLモードでの作業中は、「選択」テキスト・ボックスにORDER BY句を直接追加できますが、ランタイム・エンジンで問合せにWHERE句を追加しなければならない場合があるため、句のORDER BYの部分を分離したままにすると便利です。ORDER BY句を別に保持することで、正しく適用されるようになります。
カスタムSQLモードを使用してSQL問合せを定義する場合は、エディタに直接SQL言語文を入力します。このモードを使用する場合、ビジネス・コンポーネントの開発者は、ビュー・オブジェクトによって問合せ定義に基づくメタデータがどのように処理されるのかを理解しておく必要があります。この後の説明で、カスタムSQLモードで作成した問合せを編集する場合の操作方法を確認してください。
SQL問合せに計算式が含まれている場合は、「ビュー・オブジェクトの作成」ウィザードで列に対してJavaに適した名前を指定する際、SQLの別名を使用します。次の例は、計算式を含むSQL問合せを示しています。
select CUSTOMER_ID, EMAIL, SUBSTR(FIRST_NAME,1,1)||'. '||LAST_NAME from CUSTOMERS order by EMAIL
次の例は、ビュー・オブジェクトの作成ウィザードで列に対してJavaに適した名前を指定する際にSQLの別名USER_SHORT_NAMEを使用した例です。ウィザードには、この計算式から導出された属性名としてUserShortNameが表示されます。
select CUSTOMER_ID, EMAIL, SUBSTR(FIRST_NAME,1,1)||'. '||LAST_NAME AS USER_SHORT_NAME from CUSTOMERS order by EMAIL
ビュー・オブジェクトと基礎になるエンティティ・オブジェクトの自動的な協調は、XMLドキュメントに保存されている正確な属性マッピング・メタデータに依存します。この情報は、ビュー・オブジェクトの属性と、関係するエンティティ・オブジェクトの慣用名の対応する属性を関連付けます。この属性マッピング情報は、通常のエンティティ・ベースのビュー・オブジェクトについては完全に自動的に維持されます。しかし、ビュー・オブジェクトでカスタムSQLモードを使用するときは、SELECTリストに対して行う変更に注意する必要があります。これは、SQL問合せの中で属性マッピングに直接関係する部分です。カスタムSQLモードでも、SELECTリストに対して次のことを行うときは、JDeveloperが属性マッピング・メタデータの維持を引き続きある程度支援します。
列別名を変更しない式の並替え
JDeveloperによって、対応するビュー・オブジェクト属性の並替えおよび属性マッピングの維持が行われます。
新しい式の追加
JDeveloperによって、新しい式の列別名に基づいた対応名(頭文字が大文字表記)を持つ新しいSQL計算済ビュー・オブジェクト属性が追加されます。
式の削除
JDeveloperによって、その式に関連している対応するSQL計算済属性またはエンティティ・マップ済属性が一時属性に変換されます。
ただし、SELECTリストで列別名を変更した場合は、JDeveloperにはそれを検出する方法がなく、古い列式を削除して別の名前で新しい列式を追加したかのように扱われます。
問合せのSELECTリストを変更した後は、概要エディタの「属性マッピング」ページで、属性マッピング・メタデータが正しいことを確認してください。このページの表は、標準モードではビュー・オブジェクトに対しては無効になっていますが、カスタムSQLモードのビュー・オブジェクトに対しては有効です。各ビュー・オブジェクト属性について、対応するSQL列別名を表で確認できます。「ビュー属性」列のセルをクリックすると、ドロップダウン・リストが表示され、エンティティ・マップ・ビュー属性が対応する必要のある適切なエンティティ・オブジェクト属性を選択できます。
注意:
ビュー属性がSQL計算属性または一時属性の場合は、それを示す「SQL」アイコンの付いた対応する属性が「ビュー属性」列に表示されます。これらのタイプの属性は、基礎となるエンティティ・オブジェクトと関連していないため、エンティティ属性関連情報は必要ありません。
ビュー・オブジェクトに対するカスタムSQLモードを無効にすると、SELECT句とFROM句は再び導出された状態に戻ります。その際、SQL文に対するカスタム編集が失われることを伝える警告が表示されます。失われてもかまわない場合は、この警告を確認すると、オブジェクトのSQL問合せがデフォルトに戻ります。
Productsビュー・オブジェクトで、SQL式がSUBSTR(NAME,1,10)と定義されたShortensという名前のSQL計算属性について考えます。このビュー・オブジェクトをカスタムSQLモードに切り替えると、「選択」テキスト・ボックスに次の例のようなSQL問合せが表示されます。
SELECT Products.PROD_ID, Products.NAME, Products.IMAGE, Products.DESCRIPTION, SUBSTR(NAME,1,10) AS SHORT_NAME FROM PRODUCTS Products
Shortens属性の属性定義に戻り、「SQL式」フィールドをSUBSTR(NAME,1,10)からSUBSTR(NAME,1,15)に変更すると、ビュー・オブジェクトのXMLドキュメントに変更が保存されます。ただし、「選択」テキスト・ボックスのSQL問合せは元の式のままになることに注意してください。これは、JDeveloperではカスタムSQL文のテキストの変更が試行されないためです。カスタムSQLモードでは、開発者がすべてを制御します。JDeveloperは、開発者がカスタムSQL文に対して行うある種の変更の結果としてメタデータの調節を試みますが、逆の処理は行いません。したがって、ビュー・オブジェクト・メタデータを変更しても、カスタムSQL文はそれを反映するために更新されません。
したがって、カスタムSQL文自体で式を更新する必要があります。完全に行うには、属性メタデータおよびカスタムSQL文の両方で変更する必要があります。これにより、後でカスタムSQLモードを無効に切り替えることがあっても、自動的に導出されるSELECTリストに正しいSQL導出式が含まれるようになります。
注意:
カスタムSQLモードのビュー・オブジェクトのビュー・オブジェクト・メタデータを大量に変更する必要がある場合は、カスタマイズした問合せのテキストを一時バックアップ・ファイルにコピーすると、SQL文に対して及ぼす影響を手作業で変換する必要がありません。次に、ビュー・オブジェクトのカスタムSQLモードを無効にし、変更が失われることを伝える警告を確認できます。この時点で、JDeveloperは新しく行われたメタデータの変更に基づいて、正しく生成されたSQL文を再び導出します。最後に、再度カスタムSQLモードを有効にして、SQLのカスタマイズを再適用します。
エンティティ・マップ済の属性データの変更されたバージョンを表示する必要がある場合は、適切な式を含む新しいSQL計算属性を導入して処理します。カスタムSQLモードでは、エンティティ・マップ済属性に対応するSELECTリスト式を編集する場合は、データを取得する際に属性の値を変更するSQL計算をSQL文に導入しないでください。
SQL文にSQL計算を導入した場合に発生する問題を説明するために、次の例に示すProductsという単純なエンティティ・ベースのビュー・オブジェクトに対する問合せを考えてみます。
SELECT Products.PROD_ID, Products.NAME, Products.IMAGE, Products.DESCRIPTION FROM PRODUCTS Products
製品の問合せの名前の先頭10文字のみを表示するよう、名前列を制限するものとします。これを行う正しい方法は、ShortNameなどのSUBSTR(Products.NAME,1,10)のような式の新しいSQL計算フィールドを導入することです。その上で避ける必要があるのは、次の例に示すように、ビュー・オブジェクトをカスタムSQLモードに切り替え、エンティティにマップされたNAME列のSELECTリストの式を変更して、SQL計算式を導入することです。
SELECT Products.PROD_ID, SUBSTR(Products.NAME,1,10) AS NAME, Products.IMAGE, Products.DESCRIPTION FROM PRODUCTS Products
この代替方法は、最初はうまくいくように見えます。実行時には、名前の値が意図したとおりに切り捨てられます。しかし、行を変更すると、基礎となるエンティティ・オブジェクトは、行をロックしようとして次の処理を行います。
SELECT FOR UPDATE文を発行し、行をロックしようとしてすべての列を取得します。
エンティティ・オブジェクトは、行のロックに成功すると、データベースから最後に取得されてエンティティ・キャッシュに格納されているすべての一時属性の元の値と、ロック操作の間にデータベースから取得した属性の値を比較します。
いずれかの値が異なっていると、次のエラーがスローされます。
(oracle.jbo.RowInconsistentException) JBO-25014: Another user has changed the row with primary key [...]
システムをテストしているユーザーが1人だけでも、実行時にこのようなエラーが発生する場合は、カスタムSQLビュー・オブジェクトに、エンティティ・マップされた属性の選択値を変更したSQL関数を導入したことが原因であると考えられます。前の例では、導入したSUBSTR(Products.NAME,1,10)関数によって、Name属性の選択された元の値が切り捨てられます。行ロックSQL文は、NAME列の値を選択するときに、値全体を選択します。これにより、前の例で示した比較が失敗し、別のユーザーが行を変更したというファントム・エラーが発生します。
カスタムSQLモードでSQL関数を適用し、エンティティ・マップ済属性に対して取得された値を切り捨てたり変更したりすると、NUMBER値やDATE値の属性でも同じことが発生します。
ビュー・オブジェクトをカスタムSQLモードに変更すると、そのXMLドキュメントは、別々のXML属性に問合せの一部を格納する状態から、問合せ全体を1つの<SQLQuery>要素に保存する状態に変更されます。問合せはXML CDATAセクションにラップされて、複雑な問合せを理解しやすくするために開発者が行った可能性のある行の書式設定を保持します。
カスタムSQLビュー・オブジェクトが次のような場合:
概要エディタの「問合せ」ページの「ORDER BY」フィールドに設計時に指定されたORDERBY句を含む場合
setWhereClause()またはsetOrderByClause()を使用して実行時に適用される動的なWHERE句またはORDER BY句を含む場合
このような場合、問合せは句を適用する前にインライン・ビューにネストされます。たとえば、カスタムSQL問合せが次の例のように定義されているものとします。
select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from CUSTOMERS union all select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_CUSTOMERS
実行時に、email = :TheUserEmailのような追加のWHERE句を設定すると、ビュー・オブジェクトは元の問合せを次の例のようにインライン・ビューにネストします。
SELECT * FROM( select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from CUSTOMERS union all select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_CUSTOMERS) QRSLT
そして、ビュー・オブジェクトにより動的なWHERE句の条件が最後に追加され、データベースで確認される最終的な問合せは次の例のようになります。
SELECT * FROM( select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from CUSTOMERS union all select CUSTOMER_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_CUSTOMERS) QRSLT WHERE email = :TheUserEmail
元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、カスタムSQL問合せの場合は一般にこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に単純に付加したのでは、予想外の結果が生成される可能性があります。たとえば、UNIONで結合された複数の文の最後の文にのみ適用される可能性があります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。
カスタムSQLビュー・オブジェクトはインライン・ビュー・ラッピングされるので、動的に追加されるWHERE句は、元の問合せのSELECTリストの列のみを参照できます。このような制限を回避する必要がある場合は、setNestedSelectForFullSql(false)を呼び出すことで、インライン・ビュー・ラッピングの使用を無効にできます。
ビュー・オブジェクトを含むビュー・リンクをすでに作成した後や、ビュー・オブジェクトを拡張する他のビュー・オブジェクトを作成した後に、そのビュー・オブジェクトの問合せをカスタムSQLモードに変更すると、図5-27の警告が表示されます。この警告には、これらの依存コンポーネントでSQL文がまだ正しい問合せを反映していることを確認するよう示されます。
図5-27 依存コンポーネントの確認を促す事前注意
たとえば、カスタムSQLモードが使用されるようにOrdersVOビュー・オブジェクトを変更する場合、そのビュー・オブジェクトはOrdersByStatusVOビュー・オブジェクトによって拡張されているため、変更された親コンポーネントの拡張が現在も論理的には問合せに反映されていることを、拡張されたコンポーネントで確認する必要があります。
カスタムSQLモードでビュー・オブジェクト問合せ文を作成し、Oracle Database変更通知を使用した自動問合せ更新を有効にした場合、問合せ文で問合せ結果変更通知との互換性をテストする必要があります。ビュー・オブジェクト概要エディタの「問合せ」ページで「テストおよび説明」ボタンをクリックして、「問合せのテスト」ダイアログで問合せをテストできます。「問合せのテスト」ダイアログの「変更通知」タブで、変更通知に対して問合せを登録できるかどうかを確認します。問合せ文に互換性がない場合は、Oracle Database問合せ結果の変更通知登録要件の要求に従って問合せを改訂する必要があります。詳細は、「ビュー・アクセッサのビュー・オブジェクトを自動的にリフレッシュする方法」を参照してください。
JDeveloperでは、カスタムSQLモードで自動作成されたビュー・オブジェクトの属性にマップされた列のSQL型の推測を試みます。属性の「型」プロパティは、VARCHAR2列の長さ情報やNUMBER列の精度およびスケール情報も含めて、列のSQL型を記録します。ただし、一部のSQL式では、推測値がデフォルトでVARCHAR2(255)になります。
このような型の属性に対して正しい長さがわかっている場合は、「型」の値を更新してその長さを反映します。たとえば、図5-28でState属性に対する「型」として示されているVARCHAR2(20)は、最大文字数が20文字であることを意味しています。NUMBER列の場合、小数点以下7桁の精度と2桁のスケールを持つ属性について、NUMBER(7,2)の「型」を示します。
パフォーマンスのヒント:
それぞれのSQL式では、データベースの記述から通知される列の長さを制御できます。それには、既存の式に対してSUBSTR()関数を使用します。たとえば、SUBSTR(yourexpression, 1, 15)と指定すると、データベースからの記述により、JDeveloperに列の最大長が15文字であることが通知されます。
図5-28 SQLで導出された属性の「詳細」セクションのカスタム属性設定
エンティティ・ベースのビュー・オブジェクトの場合は、エンティティ・オブジェクト用に表示される概要エディタの「属性」ページの「詳細」セクションで「型」プロパティを編集する必要があります(「データ型の長さ、精度およびスケールの指定方法」を参照)。
ADFビュー基準を定義してビュー・オブジェクト行からのデータをフィルタできます。様々な名前付きビュー基準を定義することで、ビュー・オブジェクトの特定の使用方法を作り出すことができます。
ビュー基準により、ビュー・オブジェクト・コレクションの行に関するフィルタ情報を指定できます。ビュー基準オブジェクトは1つ以上のビュー基準グループの行セットであり、この属性にはビュー・オブジェクト内の属性がミラーリングされます。ビュー基準の定義には、ターゲット・ビュー・オブジェクトのWHERE句を拡張するための問合せ条件が含まれています。ただし、ビュー・オブジェクトの問合せ文で定義されたWHERE句がビュー・オブジェクトのすべてのインスタンスに適用されるのとは異なり、ビュー基準の問合せ条件は特定のビュー・オブジェクト・インスタンスに追加されます。そのため、ターゲット・ビュー・オブジェクトの個々の属性に適用される問合せ条件を使用することで、ターゲット・ビュー・オブジェクト定義に特定の使用方法を作り出すことができます。
ビュー基準定義では、Query-By-Example演算子がサポートされるため、ユーザーはOrderId > 304などの条件を入力できます。
「ビュー基準の編集」ダイアログでは、ビュー基準を作成し、それをビュー・オブジェクト定義の一部として保存すると、名前付きビュー基準として表示されます。特定のビュー・オブジェクトに対してビュー基準を定義する場合は、概要エディタの「ビュー基準」ページを使用します。設計時に定義するビュー基準は、実行時に結果のフィルタリングが必要となる次のようなシナリオで使用されます。
ターゲット・ビュー・オブジェクトの属性に対するエンド・ユーザーによる値の指定を可能にするQuery-By-Example検索フォームをサポートする場合。
たとえば、エンド・ユーザーは、顧客名の値および日付を入力することによって、CustomerOrdersビュー・オブジェクトの行が表示されるWebページで結果をフィルタリングできます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示される名前付きビュー基準とADFビジネス・コンポーネントのデータ・コントロールを基に、検索フォームを容易に作成できます。「データ・コントロール」パネルに表示される名前付きビュー基準の利用方法の詳細は、「問合せ検索フォームの作成」を参照してください。
アプリケーションが非キー属性を使用した行参照を実行する目的で使用する行検索操作をサポートする場合。
たとえば、一般に、行のキー値(多くの場合ID)がわからなくてもエンド・ユーザーが行を更新できるようにしておくほうが適切です。このような場合は、ビュー基準に適用する行検索により、ユーザー名やユーザーの電子メール・アドレスなどの識別しやすい属性値を使用した行の特定をサポートします。「行検索の使用」を参照してください。
エンド・ユーザーが(UIにLOVコンポーネントとして表示される)1つの属性リストから選択できる値リスト(LOV)コンポーネントをフィルタリングする場合。
Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示されるビュー・オブジェクトの属性を基に、LOVコントロールを容易に作成できます。「データ・コントロール」パネルに表示されるLOV有効属性の利用方法の詳細は、「選択リストの作成」を参照してください。
ビュー・アクセッサ結果のフィルタリングのため、ビュー基準が適用されているビュー・アクセッサを使用して属性値を検証する場合。
ビュー・アクセッサのバリデータを作成する方法の詳細は、「ビュー・アクセッサによって指定された属性値に対する検証方法」を参照してください。
ビュー・インスタンスごとに一意のビュー基準が適用されている単一のビュー・オブジェクト定義からアプリケーション・モジュールのデータ・モデルを作成する場合。
ビュー基準によって変更される単一のビュー・オブジェクトの問合せは、アプリケーション全体で共有する必要がある参照データで有効です。この場合は、ベース・ビュー・オブジェクトの定義によってデータベース内の参照表に対して問合せが行われ、ビュー基準によって参照表のTYPE列が設定され、これによってアプリケーション固有のビューが定義されます。ベース・ビュー・オブジェクトの定義に対して作成するビュー基準によってデータ・モデル内にビュー・インスタンスを定義する方法は、「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。
さらに、ビュー基準ではAPIが完全にサポートされているため、ビュー基準の作成およびビュー・オブジェクトへの適用をプログラムによって実行できます。
実行時に宣言問合せに適用することに加えて、ビュー基準には多くの使用方法があります。すべての使用方法では、名前付きビュー基準定義は、個々のビュー・オブジェクト結果をフィルタリングするために指定する属性要件のセットで構成されます。使用できるビュー基準定義の機能は、その意図する使用方法によって異なります。
フィルタリングするビュー・オブジェクトに対してビュー基準を定義するには、概要エディタでそのビュー・オブジェクトを開き、「ビュー基準」ページの「作成」ボタンをクリックします。専用のエディタ(「ビュー基準の作成」ダイアログ)では、ターゲット・ビュー・オブジェクトの対応するSQL列名ではなく、属性名を使用してWHERE句を作成できます。名前付きビュー基準は、1つのビュー・オブジェクトに対して複数定義できます。
「ビュー基準の作成」ダイアログを使用して名前付きビュー基準を作成する場合は、その前に、「名前付きビュー基準の処理」で説明している使用方法を確認します。この章を参照すると、「ビュー基準の作成」ダイアログの適切な機能の使用方法の事前把握に役立ちます。たとえば、ビュー基準を作成して、検索フォームの検索可能属性を指定すると、ビュー基準条件により属性(ビュー・オブジェクトの属性のサブセット)の単純リストが定義され、ユーザーに提示されますが、ビュー基準定義ではUIヒント(モデルレベル・プロパティ)を指定して検索フォームにおけるこれらの属性の動作を制御することが必要です。「ビュー基準の作成」ダイアログにより、定義するビュー基準のために選択した個別のタブ付きページにすべてのUIヒントが表示されます。一方、ビュー・インスタンスをデータ・モデルで指定するためにビュー基準を対象とする場合、複雑な問合せフィルタ条件を任意に定義できますが、「ビュー基準の作成」ダイアログによって表示されるUIヒント機能を無視できます。
ビュー基準の定義はそれぞれ、次の要素で構成されています。
任意の数のビュー基準グループまたは現在のビュー・オブジェクトに対して定義されている別の名前付きビュー基準への任意の数の参照。
属性名、属性に適した演算子およびオペランドで構成される任意の数のビュー基準アイテム(ビュー基準グループ別)。オペランドには、フィルタの値が定義されている場合はリテラル値か、または、属性のプロパティ値へのドット表記アクセスを含むスクリプト式がオプションで利用可能なバインド変数を使用できます。
式の記述には、Groovyスクリプト言語を使用します(「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照)。
ビュー基準を定義する場合は、フィルタリングされた結果のソースを制御します。フィルタリングされたビュー・オブジェクトの結果は、次のいずれかに制限できます。
データベース問合せ結果のみ。
ビュー・オブジェクト問合せのメモリー内の結果のみ。たとえば、ユーザーが追加した新規の行。
データベースおよびビュー・オブジェクト問合せのメモリー内の結果の両方。
データベース表とビュー・オブジェクトのメモリー内の結果の両方でフィルタリングを実行する場合、トランザクションで作成されており、データベースのコミット前である行もフィルタリングできます。
「ビュー基準の編集」ダイアログで作成するビュー基準の式では、論理積により、選択した基準アイテム(または基準グループ)とその前にあるアイテム(またはグループ)を式の中でどのように結合するかを指定できます。
AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれのビュー基準アイテムを追加する場合は、この結合がデフォルトになります。
OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。ビュー基準グループに対しては、この結合がデフォルトになります。
また、ビュー・リンクされたディテール・ビューに対する基準に基づいて現在のビュー・オブジェクトの行をフィルタリングする場合は、ネストされたビュー基準を作成できます。ネストされたビュー基準グループは、任意の数のネストされたビュー基準アイテムで構成されます。ネストされたビュー基準を使用すると、様々なビュー基準アイテムの論理積をより詳細に制御できます。ネストされた基準では、その親ビュー基準グループの中で基準を満たしている行が制限されます。たとえば、給与がSalary > 3000という基準を満たし、かつ所属部署がDeptNo = 10またはDeptNo = 20という基準を満たしている従業員のリストを問い合せる場合があります。この場合、1つの項目Salary > 3000を含む第1のグループを使用してビュー基準と、2つの項目DeptNo = 10およびDeptNo =20を含む第2のグループを使用してネストされたビュー基準を定義できます。
始める前に:
ビュー基準を使用できる方法に関する知識があると役立ちます。実行する使用方法は、名前付きビュー基準を作成するためのベスト・プラクティスに影響を与えます。サポート対象の使用方法の詳細は、「名前付きビュー基準の処理」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。
ビュー基準がオペランドでバインド変数を使用する場合は、「ビュー・オブジェクト定義にビュー基準のバインド変数を追加する方法」の説明に従ってバインド変数を作成します。
名前付きビュー基準を定義するには:
基準アイテムで、必要な「属性」を選択します。デフォルトでは、リストの最初のノードがエディタによって追加されます。
現在編集中のビュー・オブジェクトにビュー・リンクが存在する場合は、必要に応じて、ネストされたビュー基準をインラインで追加できます。リンク先ビュー・オブジェクトの名前は、「属性」ドロップダウン・リストに表示されます。ビュー・オブジェクトを選択すると、ビュー・リンクの関係に従ってネストされたビュー基準のビュー基準アイテムに基づいて、ビュー基準をフィルタリングできます。たとえば、EmpVOがPaymentOptionsVOにリンクされており、PaymentOptionsVOのビュー基準定義に、リンク先ビュー・オブジェクトのAddressVOが表示されるとします。図5-29に示すように、ネストされたビュー基準を定義することにより、CustomerId基準アイテムで指定した現在の顧客のCountryId属性に基づいて、支払いオプションをフィルタリングできます。
図5-29 ネストされたビュー基準を指定した「ビュー基準の編集」ダイアログ
必要な「演算子」を選択します。
リストには、選択した属性またはビュー・オブジェクトに適切な演算子のみが表示されます。ビュー・オブジェクトの場合、exists演算子はオペランドとして定義(または参照)するビュー基準に適用されます。 String型およびDate型属性の場合、「次の間にある」および「次の間にない」演算子では、範囲を定義するために2つのオペランド値を指定する必要があります。Date型属性の場合、日付または日付の範囲をテストする演算子を選択できます(YYYY-MM-DDの書式で入力された日付値について)。たとえば、2010年12月16日の場合、2010-12-16と入力します。
JDeveloperでは、IN演算子をサポートしていません。ただし、「プログラムによるビュー基準の作成方法」で説明するように、APIを使用すると、IN演算子でビュー基準を作成できます。
図5-30に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー基準内でバインド変数名が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。
JDeveloperの 「ビュー基準の作成」ダイアログで、ビュー基準を簡単に作成し、名前付き定義として保存できます。これらの名前付きビュー基準定義により、ターゲット・ビュー・オブジェクトの宣言的設定を表すXMLドキュメント・ファイルにメタデータが追加されます。定義すると、名前付きビュー基準はビュー・オブジェクトの概要エディタの「ビュー基準」ページに名前で表示されます。
ビュー基準を表示するには、「アプリケーション」ウィンドウで目的のビュー・オブジェクトを開き、開いたビュー・オブジェクトのXMLファイルを選択後、「構造」ウィンドウを開いて、「ビュー基準」ノードを開きます。ビュー・オブジェクトのそれぞれのビュー基準定義には、「ビュー基準の作成」ダイアログで定義したグループの数に対応する、1つ以上の<ViewCriteriaRow>要素が含まれます。次の例は、<ViewCriteria>定義であるFindByProductNameCriteriaと、開発者が定義した製品検索フォームをバインド変数:bvProductNameを使用して定義する単一の<ViewCriteriaRow>を含む、ProductsVO.xmlファイルを示しています。開発者が定義した検索フォームの動作をカスタマイズするために選択したUIヒントは、<ViewCriteria>定義に<CustomProperties>要素の属性として表示されます。ビュー基準の固有のUIヒントの詳細は、「ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法」を参照してください。
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="ProductsVO"
... >
<SQLQuery>
...
</SQLQuery>
...
<ViewCriteria
Name="FindByProductNameCriteria"
ViewObjectName="oracle.summit.model.views.ProductsVO"
Conjunction="AND">
<Properties>
<CustomProperties>
<Property
Name="mode"
Value="Basic"/>
<Property
Name="autoExecute"
Value="false"/>
<Property
Name="showInList"
Value="true"/>
<Property
Name="displayName"
Value="Find Products By Name"/>
<Property
Name="displayOperators"
Value="InAdvancedMode"/>
<Property
Name="allowConjunctionOverride"
Value="true"/>
</CustomProperties>
</Properties>
<ViewCriteriaRow
Name="vcrow87">
<ViewCriteriaItem
Name="ProductName"
ViewAttribute="ProductName"
Operator="CONTAINS"
Conjunction="AND"
Value=":bvProductName"
UpperColumns="1"
IsBindVarValue="true"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
...
</ViewObject>
また、ビュー・オブジェクトを作成し、アプリケーション・モジュールでインスタンスとして指定する場合、JDeveloperにより、アプリケーション・モジュールに含まれるコレクション(ビュー・インスタンス)をカプセル化するデータ・コントロールが自動的に作成されます。次に、これらのコレクションと定義済のビュー基準が「データ・コントロール」パネルに移入されます(「「データ・コントロール」パネルでのビュー・オブジェクトの表示」を参照)。
バインド変数を使用して定義したビュー基準フィルタは、実行時にその値を取得します。この機能は、様々なユーザー・インタフェース・シナリオで有益です。特定の使用例をサポートできるように、表5-1に示した「検証」および「Null値の無視」設定の組合せを覚えるようにしてください。
表5-1 ビュー基準のバインド変数オプションの使用例
| 検証 | Null値の無視 | ユースケース | 注意 |
|---|---|---|---|
|
|
親LOV値がオプションのカスケード値リスト(LOV)を構成します。 検索フォームのオプション検索フィールドを生成します。 |
この組合せでは、SQL問合せ カスケードLOVで使用する場合、親LOVが選択されないと子LOVのすべての行が戻されます。 検索の実行前に、すべての行が返されないようにしておくために、リテラル・オペランド(バインド変数ではない)を持つビュー基準アイテムタイプの使用をお薦めします。ビュー基準に対するバインド変数(オプションで検証を使用するもの)が解決されない場合、結果としてすべての行が返されます。 |
|
|
親LOV値が必須のカスケードLOVを構成します。 |
この組合せでは、SQL問合せ カスケードLOVで使用する場合、親LOVが選択されないと子LOVの行が戻されません。 ユーザーが検索フィールドを空白のままにすると、検索ではこのフィールドが明示的にnullに設定されている行を見つけようとするため、検索フォームではこの組合せを使用しないでください。これを行うには、詳細検索モードで「IS NULL」演算子を明示的に選択するほうが効率的です。 |
|
|
検索フォームの必須検索フィールドを生成します。 |
この組合せでは、SQL問合せ 親LOVが選択されない場合、検証エラーが発生するため、カスケードLOVに対してこの設定を使用しないでください。 NULL以外の検索結果の存在を検索実行前に確認するために、リテラル・オペランド(バインド変数ではない)を持つビュー基準アイテム・タイプの使用をお薦めします。ビューに対するバインド変数(必須で検証を使用するもの)が解決されない場合、結果として行は返されません。 |
ビュー基準からUIデザイナによって作成される検索フォームでは、すべてのタイプのネストされた式が動作するわけではありません。特に、検索フォームでは、直接ネストされたビュー基準が含まれる式がサポートされていません。このタイプのネストされた式では、1つのビュー基準を別のビュー基準の直接の子として定義します。それ自体がビュー基準の子である基準アイテムの子としてビュー基準をネストしたネストされた式は、問合せ検索フォームでサポートされています。ビュー基準を使用した検索フォームの作成の詳細は、「暗黙的ビュー基準と名前付きビュー基準」を参照してください。
ビュー・オブジェクト・コレクションに対して作成された名前付きビュー基準は、Webページ・デザイナがQuery-By-Example検索フォームを作成する際に使用できます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルから名前付きビュー基準を選択して、Fusion Webアプリケーション用の検索フォームを作成します。Webページの検索フォームでは、「データ・コントロール」パネルで選択した名前付きビュー基準に最初にバインドされるADF Faces問合せ検索コンポーネントが利用されます。実行時、エンド・ユーザーは、「データ・コントロール」パネルに表示されるその他すべての名前付きビュー基準の中からいずれかを選択できます。エンド・ユーザーが検索フォームで選択できる名前付きビュー基準は、開発者定義のシステム検索と呼ばれます。問合せコンポーネントでは、「保存済の検索」ドロップダウン・リストに、これらのシステム検索が自動的に表示されます。検索フォームの作成およびADF問合せ検索コンポーネントの使用方法の詳細は、「問合せ検索フォームの作成」を参照してください。
注意:
デフォルトでは「ビュー基準の編集」ダイアログで作成するすべての名前付きビュー基準が、「データ・コントロール」パネルに表示されます。「ビュー基準の編集」ダイアログの「UIヒント」ページで「リストに表示」オプションが選択されているかぎり、名前付きビュー基準は開発者定義のシステム検索として使用可能であるとみなされます。作成する名前付きビュー基準が検索フォームを介してエンド・ユーザーに表示されないようにする場合は、ダイアログで「リストに表示」オプションの選択を解除します。たとえば、LOV有効属性に対してのみ名前付きビュー基準を作成する場合は、「リストに表示」オプションの選択を解除する必要があります。
開発者定義のシステム検索はモデル・プロジェクト内で作成されるため、「ビュー基準の編集」ダイアログの「UIヒント」ページでは、問合せコンポーネントにおける個々の名前付きビュー基準の実行時の使用方法に対して、デフォルト・プロパティを指定できます。実行時の問合せコンポーネントの動作は、次のシステム検索プロパティに何を選択するかによって決まります。
検索リージョン・モード: 問合せコンポーネントでシステム検索を表示する際のモードを選択します。「基本」モードでは、表示された検索基準フィールドをエンド・ユーザーが動的に変更することはできませんが、それ以外は使用できる機能は「詳細」モードとまったく同じです。「ビュー基準の編集」ダイアログで定義するビュー基準のデフォルトのモードは、「基本」モードです。
自動的に問合せ: 名前付きビュー基準に関連付けられた問合せを実行し、その結果をWebページに表示する場合に選択します。このオプションが有効になっている開発者定義のシステム検索は、エンド・ユーザーが問合せコンポーネントの「保存済の検索」リストから選択すると、自動的に実行されます。Webページ・デザイナの意向により、エンド・ユーザーがフォーム上の検索基準値を送信するまで以前の結果を更新しないようにする場合は、選択を解除します。また、タスク・フローから検索フォームが起動される場合は、このオプションの選択が解除されていると検索フォームは空白になり、選択されると移入されます。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して無効になっています。
「演算子の表示」: 問合せコンポーネントでエンド・ユーザーにビュー基準アイテムの演算子の選択フィールドを表示する方法を指定します。ユーザーが詳細から基本に問合せコンポーネントのモードを変更したときに、問合せコンポーネントにより表示される演算子は、「演算子の表示」の設定方法によって異なることに気をつけてください。問合せコンポーネントは、ユーザーが演算子の表示を常に表示に設定して両方のモードで演算子の完全なリストを表示できるようにした場合にのみ、2つのモード間でユーザーの選択を保持します。ただし、「演算子の表示」を詳細モードに設定して、詳細モードでのみ完全な演算子リストを表示する場合は、選択を行って基本モードに切り替えた後に、演算子はビュー基準で定義されたデフォルトに戻るため、ユーザーの選択が変更されたように見えます。ユーザーが定義した演算子だけを使用してビュー基準を実行する場合は、表示しないを選択します(この場合、演算子の完全なリストは基本モードでも詳細モードでも表示されません)。検索フォームには問合せのWHERE句で使用される任意のバインド変数が検索基準として表示されますが、「演算子の表示」設定ではこれらのバインド変数式に関連付けられた演算子の表示はサポートされません。
すべてに一致といずれかに一致を表示: 問合せコンポーネントで「すべてに一致」および「いずれかに一致」ラジオ・ボタンをエンド・ユーザーに表示する場合に選択します。これらのボタンが表示されている場合、エンド・ユーザーはこれらのボタンを使用して検索条件を変更し、すべてのビュー基準アイテムに一致またはいずれかのビュー基準アイテムに一致する結果を戻すことができます。これは、ビュー基準アイテム間にAND結合(すべてに一致)またはOR結合(いずれかに一致)を適用するのと同等です。定義されているビュー基準アイテム論理積を使用してビュー基準を実行する場合は、選択を解除します。この場合、問合せコンポーネントにラジオ・ボタンの選択は表示されません。
表示されたモード: ビュー基準ツリー・コンポーネントから個々のビュー基準アイテムを選択し、さらに、エンド・ユーザーが問合せコンポーネントのモードを「基本」と「詳細」の間で切り替える際に、選択したアイテムが検索フォームに表示されるようにするかどうかを選択します。それぞれのビュー基準アイテムに対するデフォルト設定は「すべて」です。このデフォルトのモードの場合、問合せコンポーネントでは、「基本」と「詳細」のどちらのモードでもアイテムをレンダリングできます。個々のビュー基準アイテムの「表示されたモード」設定を変更すると、実行時の検索フォームの外観をカスタマイズできます。たとえば、「基本」モードで簡略化した検索フォームをエンド・ユーザーに表示し、すべてのビュー基準アイテムのある検索フォームを表示できる「詳細」モードを予約する必要があるとします。この場合は、問合せコンポーネントの「基本」モードで表示しないビュー基準アイテムに対しては「詳細」を選択します。一方、選択したビュー基準アイテムを「基本」モードでのみレンダリングする場合は、「基本」を選択します。検索フォームで「基本」モードでも「詳細」モードでも表示しないアイテムに対しては「なし」を設定します。
注意:
ユーザーに公開しないアイテムがビュー基準に含まれている場合、「表示されたモード」設定に「なし」を使用して、検索フォームでそのアイテムを非表示にします。たとえば、ログインした顧客のカート内にある製品を検索するためのビュー基準は作成できますが、ユーザーが顧客IDを変更して別の顧客のカート内にある製品を表示することのないようにする必要があります。このようなシナリオでは、名前付きバインド変数を使用して、顧客IDに対応するビュー基準アイテムを現在の顧客IDに設定します。バインド変数定義で変数が任意または更新不可に指定されている場合がありますが、UIヒント・プロパティの「表示」が「非表示」に設定されている場合は、「表示されたモード」の設定によってのみ、検索フォームに値が表示されるかどうかが決まります。
「複数の値の選択をサポート」: エンド・ユーザーが問合せコンポーネントに表示される各基準アイテムの複数の選択を行えるようにする場合に選択します。このオプションは、ビュー基準アイテムによって指定されるビュー・オブジェクト属性に、値リスト(LOV)が定義されている場合にのみ有効になります。また、エンド・ユーザーが演算子equal toまたはnot equal toを選択している場合、複数の選択は問合せコンポーネントによってのみサポートされます。たとえば、基準アイテムで属性CountryIdが指定され、この属性が関連付けられたLOVによってアクセスされる国IDのリストから値を導出する場合、このオプションを選択すると、エンド・ユーザーは複数の国を選択して問合せを送信できます。実行時に、問合せコンポーネントはエンド・ユーザーが選択した演算子に基づいて適切な問合せ句を生成します。
「表示幅」: この基準アイテムを問合せコンポーネントに表示するコントロールにより使用される文字幅を入力します。基準アイテムの対応ビュー・オブジェクト属性用に定義された表示幅コントロール・ヒントを入力値によりオーバーライドします。たとえば、編集フォームでは属性コントロール・ヒントにおけるテキストの長さは1024まで可能ですが、検索フォームでは基準アイテムのフィールドにおける文字の長さを20文字に制限する場合があります。
「リストに表示」: ビュー基準を開発者がシードした問合せとして定義する場合に選択します。定義する名前付きビュー基準が、検索フォームを表示する問合せ検索コンポーネントで使用されないようにする場合は、選択を解除します。ここでの選択により、使用可能なシステム検索の問合せ検索コンポーネントの「保存済の検索」ドロップダウン・リストに、名前付きビュー基準が表示されるかどうかが決まります。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して有効になっています。
表示名: 問合せコンポーネントの「保存済の検索」ドロップダウン・リストに表示するシステム検索の名前を入力するか、「...」ボタン(編集フィールドの右)をクリックしてビュー・オブジェクトに関連付けられているリソース・バンドルからメッセージ文字列を選択します。表示名は、エンド・ユーザーがシステム検索を識別する名前になります。リソース・バンドルからメッセージ文字列を選択すると、この文字列に対応するメッセージ・キーがビュー・オブジェクト定義ファイルに保存されます。実行時に、UIはこの文字列を特定し、エンド・ユーザーのロケール設定とローカライズされたリソース・バンドルのメッセージ・キーに基づいて表示します。表示名が指定されていない場合、デフォルトでは、「ビュー基準の編集」ダイアログに表示されるビュー基準の名前が使用されます。
ADF問合せ検索コンポーネントで使用するシステム検索を作成する場合は、「ビュー基準の編集」ダイアログの「UIヒント」ページで、「リストに表示」を選択します。エンド・ユーザーの検索フォームにビュー基準を表示しない場合は、「リストに表示」の選択を解除します。
始める前に:
ビュー基準に関する知識が役立つ場合があります。「名前付きビュー基準の処理」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。
「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成します。
ビュー・オブジェクト属性のUIヒントの定義については、「属性固有のUIヒントの追加方法」を参照してください。
ユーザー・インタフェースに使用する名前付きビュー基準をカスタマイズするには:
ビュー・オブジェクトに追加したビュー基準をテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。
参照するビュー・オブジェクト・インスタンスをOracle ADFモデル・テスターで開くと、「ビュー基準」ダイアログが表示されます(図5-31を参照)。ダイアログで、1つ以上のビュー基準グループから構成されるビュー基準を作成できます。
単一のビュー基準グループから基準属性を適用するには、ブラウザの「ビュー基準の指定」ツールバー・ボタンをクリックして、目的のフィールドにQuery-By-Example基準を入力し、「検索」をクリックします。
Oracle ADFモデル・テスターを使用してビュー基準をテストするには:
プロジェクトのビュー・オブジェクトに追加したビュー基準をテストするには、リストから選択して「検索」をクリックします。「非定型基準」パネルに入力した追加の基準は、フィルタに追加されます。
単一のビュー基準グループから非定型基準属性をテストするには、ビュー基準に必要な値を入力し、「検索」をクリックします。たとえば、図5-31は、名前が"S"で始まり、居住地がCA(カリフォルニア州)であるすべての顧客を返すためのフィルタを示しています。
追加の非定型ビュー基準グループをテストするには、「OR」タブをクリックして、それぞれが固有のビュー基準グループを表すページを切り替えるために表示される追加タブを使用します。「検索」をクリックすると、Oracle ADFモデル・テスターによって、結果をフィルタリングするビュー基準が作成されて適用されます。
Groovy式adf.context.getSecurityContext().getUserName()を使用して、ビュー・インスタンス・フィルタの現在のユーザーの指定に使用する名前付きバインド変数のデフォルト値を設定できます。具体的には、プロジェクトのデータ・モデルのビュー・オブジェクト・インスタンスをフィルタリングするために定義する名前付きビュー基準で、バインド変数を使用できます。たとえば、名前付きバインド変数UserPrincipalは、図5-32に示すように、概要エディタの「ビュー基準」ページで定義されています。adf.context.getSecurityContext()methodName()のような式を使用してセキュリティ・コンテキストにアクセスするGroovy式をビジネス・コンポーネントに記述できます。たとえば、このセキュリティ・コンテキストからは、ユーザー名や特定のロールに所属しているかなど、現在のユーザーに関する情報にアクセスできます。ADFセキュリティ・コンテキストの詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。
図5-32 UserPrincipalバインド変数の設定に使用されるGroovy式
CustomerVOビュー・オブジェクトでは、AuthenticatedUserByPrincipalCriteriaビュー基準も定義されています。このビュー基準で定義されているPersonsVOのPrincipalName属性のフィルタには、バインド変数userPrincipalによって値が指定されます。この例では、バインド変数userPrincipalが定義され、「更新可能」が有効にされています。これにより、ビュー基準は、ADFセキュリティ・コンテキストから実行時に取得する値を設定できるようになります。バインド変数は、PersonsVOビュー・オブジェクトのSQLのWHERE句で使用されないため、「必須」フィールドの選択が解除されています。これによりこの値は任意になり、バインド変数が解決されない場合でも実行時例外はスローされません。
CustomerVOで慣用名AuthenticatedUserのビュー定義が指定されているデータ・モデルでは、名前付きバインド変数を含むビュー基準AuthenticatedUserByPrincipalCriteriaがビュー慣用名の実行時フィルタとして定義されています。プロジェクトのデータ・モデルのビュー・インスタンスの作成の詳細は、「アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ」を参照してください。
次の例は、フィルタリングするCustomerListビュー・オブジェクト・インスタンスを検索し、このビュー・オブジェクトの属性のビュー基準を作成して、このビュー基準をビュー・オブジェクトに適用するmain()メソッドを示しています。
ビュー基準をプログラムによって作成するには、次の基本的な手順に従います(SummitADF_Examplesワークスペースのサンプルoracle.summit.model.viewobjects.ProgrammaticVOCriteria.javaからの例である、次の例を参照)。
フィルタリングするビュー・オブジェクト・インスタンスを検索します。
ビュー・オブジェクトに対するビュー基準行セットを作成します。
ビュー基準を使用して、1つ以上の空のビュー基準グループを作成します。
適切なビュー基準グループでフィルタリングする属性値を設定します。
または、ビュー基準グループのensureCriteriaItem()、setOperator()およびsetSearchValue()の各メソッドを使用して、フィルタ対象となる属性名、比較演算子および値を個別に設定します。
ビュー基準グループをビュー基準行セットに追加し、ビュー基準をビュー・オブジェクトに適用します。
問合せを実行します。
新しく適用されたビュー基準は次の実行でビュー・オブジェクトのSQL問合せにのみ適用されるため、問合せの実行の最後の手順は重要です。
public class ProgrammaticVOCriteria {
public static void main(String[] args) {
// get the application module
String amDef = "oracle.summit.model.viewobjects.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
// 1. Find the View Object you want to filter
ViewObject customerList = am.findViewObject("SCustomerView1");
// Work with your appmodule and view object here
// iterate through all the rows first, just to see to full VO results
customerList.executeQuery();
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));
System.out.println("********* Set View Criteria and requery *********");
// 2. Create a view criteria row set for this view object
ViewCriteria vc = customerList.createViewCriteria();
// 3. Use view criteria row set to create at least one view criteria group
ViewCriteriaRow vcr1 = vc.createViewCriteriaRow();
// 4. Set attribute values to filter on
ViewCriteriaItem vci = vcr1.ensureCriteriaItem("State");
vci.setOperator("=");
vci.setSearchValue("TX");
// 5. Add the view criteria group to the view criteria row set
vc.add(vcr1);
// 6. Apply the view criteria to the view object
customerList.applyViewCriteria(vc, true);
// 7. Execute the query
customerList.executeQuery();
// Iterate throught the rows to see the new results
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));
}
System.out.println("********* Set View Criteria and requery *********");
// set the attribute to a different value
vci.setSearchValue("CA")
// Execute the query
customerList.executeQuery();
// iterate throught the rows to see the new results
while (customerList.hasNext()) {
Row customer = customerList.next();
System.out.println("Customer: " + customer.getAttribute("Name") + "
State: " + customer.getAttribute("State"));
}
Configuration.releaseRootApplicationModule(am, true);
}
}
ProgrammaticVOCriteria.javaテスト・クライアントを実行すると、問合せが実行されるたびに1つずつレコード・セットが生成されます。最初の問合せには基準が適用されておらず(すべてのレコードを表示)、2番目の問合せには1つの基準セットがあります(TXのレコードのみを表示)。3番目の問合せではこの基準が変更されています(CAのレコードのみを表示)。
Customer: Great Gear State: TX Customer: Acme Outfitters State: TX Customer: Athena's Closet State: TX Customer: Big John's Sports Emporium State: CA Customer: Perfect Purchase State: CA Customer: Father Gym's State: CA ... ********* Set View Criteria and requery ********* Customer: Great Gear State: TX Customer: Acme Outfitters State: TX Customer: Athena's Closet State: TX ... ********* Set View Criteria and requery ********* Customer: Big John's Sports Emporium State: CA Customer: Perfect Purchase State: CA Customer: Father Gym's State: CA ...
ビュー基準は、buildCriteria()を使用して作成することもできます。
public class ProgrammaticVOCriteria {
public static void main(String[] args) {
ProgrammaticVOCriteria pc = new ProgrammaticVOCriteria();
// get the application module
String amDef = "model.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
ViewObjectImpl deptvo = (ViewObjectImpl) am.findViewObject("DeptView1");
}
pc.testExpr("DeptViewCriteria", deptvo, "Deptno in (20, 30, 40)");
Configuration.releaseRootApplicationModule(am, true);
}
public void testExpr(String vcName, ViewObjectImpl vo, String expr){
System.out.println("Expression = " + expr);
ViewCriteria vc = vo.buildViewCriteria(vcName, expr);
System.out.println("VC: " + vc);
vo.applyViewCriteria(vc);
vo.executeQuery();
while(vo.hasNext()){
Row r = vo.next();
System.out.println("Dept : " + r.getAttribute("Deptno") + "/" + r.getAttribute("Dname"));
}
}
}
1つ以上のビュー基準グループを含むビュー基準をビュー・オブジェクトに適用すると、次に実行されるときに、ビュー基準グループに移入したQuery-By-Example基準に対応する追加のWHERE句条件を使用してビュー・オブジェクトのSQL問合せが拡張されます。図5-33のように、複数のビュー基準グループを含むビュー基準を適用すると、ビュー・オブジェクトでは、各ビュー基準グループの非NULLの例の基準属性に基づいて付加的な実行時WHERE句を追加することにより、設計時のWHERE句が拡張されます。
ビュー基準機能の当然の結果として、新規ビュー基準を適用(または既存のビュー基準を削除)するたびに、ビュー・オブジェクトのSQL問合せのテキストが効率的に変更されます。SQL問合せの変更は、データベースが次に実行されるときに文を再解析する原因になります。「Query-By-Example基準に関する必知事項」で説明するように、この再解析は省略できるため、ビュー基準のパフォーマンスが向上します。
図5-33 ビュー・オブジェクトでビュー基準グループを付加的な実行時WHEREフィルタに自動的に変換
「ビュー基準の編集」ダイアログでサポートされていないタスクを実行する必要がある場合は、ビュー基準APIを使用できます。たとえば、複数のビュー基準グループを使用した複合検索条件の変更、NULL属性値を持つ行の検索、大/小文字を区別しない検索、有効なビュー基準のクリアはいずれも、プログラムによって実行できます。
setWhereClause()メソッドを使用すると、ビュー・オブジェクトに動的WHERE句を追加できます(「ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド」を参照)。また、次のようなリテラル・データベース列名を含む文字列を渡す場合にもsetWhereClause()を使用できます。
vo.setWhereClause("LAST_NAME LIKE UPPER(:NameToFind)");
これに対して、ビュー基準のメカニズムを使用する場合は、「プログラムによるビュー基準の作成方法」の説明に従って、かわりに次のようにビュー・オブジェクト属性名を参照する必要があります。
ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setOperator(">");
vc_item1.setValue("304");
ビュー基準の属性値の設定に、過去のリリースのドキュメントに記載されていたvcr.setAttribute("UserId", "> 304")などのメソッド・コールは使用しないでください。
ビュー基準グループは、その後、ビュー・オブジェクトにより、当該の列名を参照する当該のWHERE句条件に変換されます。プログラムで設定するWHERE句は、設計時にビュー・オブジェクト用に定義されたビュー基準のWHERE句で論理積(AND)されます。
ビュー基準アイテムの値をバインド変数に設定する場合は、次のようにsetIsBindVarValue(true)を使用します。
ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setIsBindVarValue(true);
vc_item1.setValue(":VariableName");
NULLを列に含む行を検索するには、対応するビュー基準グループ属性にIS NULLという値を移入するか、ViewCriteriaItem.setOperator("ISBLANK")を使用します。
ビュー基準アイテムの日付値の比較を実行する場合は、次の事前定義済の演算子を使用します。
BEFORE
AFTER
ONORBEFORE
ONORAFTER
たとえば、値が特定の日付より後のDATE型属性を含む行を検索するには、ViewCriteriaItem.setOperator("AFTER")を使用します。
<、>、<=、>=のような演算子は、日付値に対して不正確な結果を生成する文字列比較を実行するため、使用しないでください。
列の値が指定する値リストのいずれかの値に一致するすべての行を検索するには、コンマ区切り値リストを使用して対応するビュー基準グループ属性を移入し、IN演算子を使用します。たとえば、IDが204および206に一致するユーザーのリストをフィルタリングするには、次のようにします。
ViewCriteriaItem vci = vcr.ensureCriteriaItem("CustomerId");
vci.setOperator("IN");
vci.setValue(0, 204);
vci.setValue(1, 206);
大/小文字を区別しないで検索するには、区別しない検索を適用するビュー基準グループのsetUpperColumns(true)をコールします。これは、ビュー・オブジェクトのString値の属性に対して生成されたWHERE句条件に影響を与え、COLUMN_NAMEではなくUPPER(COLUMN_NAME)が条件に使用されます。これらのString値の属性に対して提供されるビュー基準グループ属性の値は、大文字であるる必要があります。そでない場合は、条件が一致しません。UPPER()は、条件のみでなく、値に対しても使用できます。たとえば、UPPER(ename) = UPPER("scott")という設定が可能です。
有効な任意のビュー基準をクリアするには、ビュー・オブジェクトでgetViewCriteria()をコールし、remove()メソッドを使用し、削除する基準行のゼロベースのインデックスを渡して、ビュー基準グループをすべて削除します。他のビュー基準グループを再度追加しない場合は、ビュー基準名を渡してビュー・オブジェクトのremoveApplyViewCriteriaName("namedViewCriteria")をコールするのみでも、すべての有効なビュー基準をクリアできます。
複数のビュー基準を追加する場合、ビュー基準のsetConjunction()メソッドをコールして、そのビュー基準に対応する条件とその前のビュー基準に対する条件の間で使用される結合を変更できます。引数として渡す有効な定数は、次のとおりです。
ViewCriteriaComponent.VC_CONJ_AND
ViewCriteriaComponent.VC_CONJ_NOT
ViewCriteriaComponent.VC_CONJ_UNION
ViewCriteriaComponent.VC_CONJ_OR(デフォルト)
次のようなフィルタ基準を作成するために、NOT値をANDまたはORと組み合せることができます。
( PredicateForViewCriteria1 ) AND (NOT ( PredicateForViewCriteria2 ) )
または
( PredicateForViewCriteria1 ) OR (NOT ( PredicateForViewCriteria2 ) )
複合検索条件を実現する構文には、次のようにJavaのビット単位OR演算子を使用する必要があります。
vc2.setConjunction(ViewCriteriaComponent.VC_CONJ_AND | ViewCriteriaComponent.VC_CONJ_NOT);
パフォーマンスのヒント:
UNION問合せで索引を活用できる場合は、OR句のかわりにUNION値を使用します。たとえば、ビュー基準でsal > 2000 or job = 'CLERK'が検索される場合、この問合せでは全表スキャンが開始されることがあります。2つの内部ビュー基準の結合として問合せを指定し、データベース表のsalとjobに索引が存在する場合、問合せではこれらの索引を活用でき、問合せのパフォーマンスは大規模なデータ・セットに対して大幅に向上します。
UNION句の制限は、1つのビュー・オブジェクトに対して定義する必要がある点です。つまり、SELECTとFROMリストは、UNION句の複数の内部問合せで同じになります。UNION問合せを指定するには、次のように外部ビュー基準のsetConjunction()をコールします。
vc.setConjunction(ViewCriteriaComponent.VC_CONJ_UNION);
外部ビュー基準には、結果同士が結合される内部問合せが含まれている必要があります。たとえば、次の2つのビュー基準の結合を指定する必要があるとします。
Job = 'SALESMAN'を検索するビュー基準MyEmpJob
Sal = 1500を検索するビュー基準MyEmpSalary
これらの2つのビュー基準のUNION問合せを作成するには、次の例に示すコールを作成します。
vcu = voEmp.createViewCriteria();
vcm = voEmp.getViewCriteriaManager();
vcu.setConjunction(ViewCriteria.VC_CONJ_UNION);
vcu.add(vcm.getViewCriteria("MyEmpJob"));
vcu.add(vcm.getViewCriteria("MyEmpSal"));
voEmp.applyViewCriteria(vcu);
このビュー基準を適用すると、JobがSALESMAN、またはSalが1500より大きい行が返されます。
UNIONビュー基準を使用する場合は、適用するビュー基準の1つのみにUNION結合を含めるようにしてください。適用する別のビュー基準は、UNION問合せの各内部問合せに適用されます。
次の2つのケースでは、パフォーマンス上の理由から、バインド変数をビュー基準アイテムの値として設定しないようにしてください。
ビュー基準アイテムの値が選択的に必須として定義されており、NULL以外の値からNULLに変更される特殊な場合
この場合は、NULL以外の値からNULLに変更されるたびに、ビュー基準のSQL文が再生成されます。
ビュー基準アイテムの値が任意で、そのアイテムが索引列の属性を参照している場合
任意のビュー基準アイテムの場合は、追加のSQL句のOR (:Variable IS NULL)が生成されます。この句は列索引の使用をサポートしません。
これらのいずれかの場合であれば、「ビュー・オブジェクト定義にWHERE句のバインド変数を追加する方法」で説明するように、WHERE句に名前付きバインド変数が含まれるビュー・オブジェクトを使用することにより、パフォーマンスが向上します。
ADFビュー・オブジェクトまたはビュー基準にランタイム属性値を指定するバインド変数を定義できます。
バインド変数を使用すると、実行時にビュー・オブジェクトまたはビュー基準に属性値を組み込むことができます。バインド変数はすべて、ビュー・オブジェクトのレベルで定義され、次のいずれかの方法で使用されます。
ビュー・オブジェクトで開いた「ビュー基準の編集」ダイアログでは、バインド変数を選択リストから選択して、ビュー基準に使用する属性値を定義できます。この場合、バインド変数により、ビュー・オブジェクトの行セットのフィルタリングに使用する属性の値を変更できます。ビュー・オブジェクトの行セットのフィルタリングの詳細は、「名前付きビュー基準の処理」を参照してください。
UI開発者定義の検索フォームでビュー基準を使用する場合は、エンド・ユーザーがバインド変数を更新できるようにすることができます。この更新可能オプションを使用する場合、エンド・ユーザーはビュー・オブジェクト問合せに対応する検索フォームに値を入力する必要があります。
バインド変数をビュー・オブジェクトの問合せのWHERE句に直接入力し、実行ごとに変更される値を組み込むことができます。この場合、バインド変数はSQL文字列内のプレースホルダとして機能し、SQL文字列自体のテキストを変更することなく、実行時に簡単にその値を変更できます。問合せは変更しないため、データベースでは、同一の解析済問合せ表現を複数の実行で効率的に再使用できるようになり、結果としてアプリケーションの実行時パフォーマンスが向上します。
ビュー・オブジェクト実行の際に必ず必要とされる、問合せのWHERE句のバインド変数とは対照的に、ビュー基準に対して定義するバインド変数は、ビュー基準が適用される場合にのみ必要になります。
注意:
アプリケーションでは、問合せのWHERE句にフィルタをハードコーディングするのではなく、ビュー基準を使用してビュー・オブジェクトをフィルタリングすることをお薦めします。ビュー基準を使用すると、検索基準の値に変更があっても、そのたびにビュー・オブジェクトのSQL文のテキストを変更しなくても値の変更ができます。
バインド変数に対しては、デフォルト値を定義するか、属性プロパティ値へのドット表記法によるアクセスが可能なスクリプト式を記述できます。式の記述には、Groovyスクリプト言語を使用します(「ビジネス・コンポーネントでのGroovyスクリプト言語の使用」を参照)。
ビュー基準にバインド変数の使用を指定する際は、ビュー・オブジェクト定義にバインド変数を追加する必要があります。ビュー基準定義にバインド変数の使用を追加する場合は、ビュー・オブジェクトにバインド変数定義がないと、そのビュー基準を適用したときにランタイム例外が発生します。バインド変数定義を作成するには、該当のビュー・オブジェクトの概要エディタの「ビュー基準」ページを使用します。エディタで変数を定義すると、バインド変数が実行時に値を受け取ります。この値を定義しないままにすると、NULLになります。デフォルト値であるNULLは、一部のシナリオには適していますが、そうでない場合もあります。NULLでない値が必要な場合は、バインド変数定義にデフォルト値を指定するか、エンド・ユーザーが実行時に値を指定するようにできます(たとえば、問合せ検索フォームの場合は検索基準を使用するなど)。
ビュー基準のバインド変数をビュー・オブジェクトに追加するには、そのビュー・オブジェクトの概要エディタの「ビュー基準」ページを使用します。
始める前に:
バインド変数をビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー基準の名前付きバインド変数を定義するには:
図5-35に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー基準内でバインド変数が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。
図5-34 バインド変数の参照について確認するためのオレンジ色の枠線
問合せのWHERE句にバインド変数の使用を指定する際は、ビュー・オブジェクト定義にもバインド変数を追加する必要があります。問合せ文にバインド変数の使用を追加する場合は、ビュー・オブジェクトにバインド変数定義がないと、ランタイム例外が発生します。バインド変数定義を作成するには、該当のビュー・オブジェクトの概要エディタの「問合せ」ページを使用します。エディタで変数を定義すると、バインド変数が実行時に値を受け取ります。この値を定義しないままにすると、NULLになります。デフォルト値であるNULLは、一部のシナリオには適していますが、そうでない場合もあります。NULLでない値が必要な場合は、バインド変数定義にデフォルト値を指定するか、実行時に値を設定できます(「実行時に既存のWHERE句のバインド変数値を設定する方法」を参照)。
WHERE句のバインド変数をビュー・オブジェクトに追加するには、そのビュー・オブジェクトの概要エディタの「問合せ」ページを使用します。必要な数のバインド変数を定義できます。
注意:
「バインド変数の名前に関連するエラー」で説明するように、概要エディタで構成したバインド変数で、参照されていないものがあると、実行時エラーが発生します。ビュー・オブジェクト定義でこれに名前を付けるか、プログラムで参照する場合を除いて、すべてのバインド変数定義を概要エディタから削除します。
始める前に:
バインド変数をビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。詳細は、「バインド変数の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
WHERE句の名前付きバインド変数を定義するには:
図5-35に示すように、カーソルをバインド変数名フィールド上に移動して、ビュー・オブジェクトの問合せ内でバインド変数が指定されていることを確認します。JDeveloperでは、参照されていないバインド変数は、名前フィールドの枠線がオレンジ色で表示されることによってわかるようになっています。
図5-35 バインド変数の参照について確認するためのオレンジ色の枠線
ビュー・オブジェクトに1つ以上の名前付きバインド変数を追加すると、これらの変数の値を実行時に簡単に参照および設定する機能を使用できます。各バインド変数の名前、型およびデフォルト値の情報は、ビュー・オブジェクトのXMLドキュメント・ファイルに保存されます。バインド変数に対してUIヒントを定義した場合、この情報はビュー・オブジェクトの他のUIヒントとともにビュー・オブジェクトのコンポーネント・メッセージ・バンドル・ファイルに保存されます。
概要エディタでは、定義されてもビュー・オブジェクトの問合せで使用されていないバインド変数の変数名の周囲にオレンジ色の警告ボックスが表示されます。問合せ文またはビュー基準定義から参照されていないバインド変数は必ず削除してください。「バインド変数の名前に関連するエラー」で説明するように、ビュー・オブジェクトの問合せの実行時に1つ以上のバインド変数定義が参照されないままになっていると、実行時エラーが発生します。
Oracle ADFモデル・テスターでは、ビュー・オブジェクトに対する名前付きバインド変数の値を対話型で検査および変更ができ、名前付きバインド・パラメータを使用する場合にアプリケーション・モジュールのデータ・モデルを簡単に試すことができます。データ・モデルを編集してOracle ADFモデル・テスターを実行する方法の詳細は、「Oracle ADFモデル・テスターを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。
データ・ビュー・ページに結果を表示するために、Oracle ADFモデル・テスターでビュー・オブジェクトを初めて実行する場合、図5-36に示すように、「バインド変数」ダイアログが表示されます。
「バインド変数」ダイアログでは次のような操作が可能です。
リストから選択した特定のバインド変数の名前、デフォルト値および現在の値を表示します。
対応する「値」フィールドを更新してバインド変数の値を更新してから「OK」をクリックし、バインド変数値を設定して問合せを実行します。
ツールバーの「バインド・パラメータの編集」ボタン(アイコンが:idのように表示されます)を使用して、現在のデータ・ビュー・ページに表示されているビュー・オブジェクトに対するバインド変数を検査および設定します。
「バインド変数」リストにラベル・テキスト・ヒントを表示するか、それぞれのフォーマット・マスクを使用して「値」属性をフォーマットすることにより、UIヒントが正しく設定されていることを確認します。
図5-36 Oracle ADFモデル・テスター内のバインド変数の設定
「バインド変数」ダイアログでバインド変数を定義する際、「必須」チェック・ボックスの選択を解除すると、ビュー基準をテストし、必要に応じてバインド変数に値を指定できます。一方、「必須」チェック・ボックスが選択されている場合(デフォルト)、Oracle ADFモデル・テスターでバインド変数の値を1つ指定する必要があります。Oracle ADFモデル・テスターでは、SQL文で使用しているバインド変数の値の指定では解決されないビュー・オブジェクトに対しては、実行時と同じ例外がスローされます。
ビュー・オブジェクトのsetWhereClause()メソッドを使用して、実行時にフィルタリングの句をさらに追加できます。この実行時に追加されるWHERE句条件は、設計時に生成された条件のかわりに使用せずに、既存の設計時WHERE句に追加して問合せ結果をさらに絞り込みます。動的に追加された句が、アプリケーションの有効期間中に変化することのある値を参照するときは、WHERE句条件にリテラル値を連結するのではなく、常に名前付きバインド変数を使用してください。
たとえば、表のCUSTOMER_TYPE_CODE列の値に基づいて実行時にビュー・オブジェクトCustomerListをさらにフィルタリングすると仮定します。さらに、CUSTOMER_TYPE_CODE = 'CUST'である行、またはCUSTOMER_TYPE_CODE = 'SUPP'である行を検索する予定であると仮定します。コード行はわずかに少なくなりますが、次の例は好ましくありません。それは、同じCUSTOMER_TYPE_CODE列の異なる2つの値を問い合わせるためだけにWHERE句が2回変更されているからです。
// Don't use literal strings if you plan to change the value!
vo.setWhereClause("customer_type_code = 'CUST'");
// execute the query and process the results, and then later...
vo.setWhereClause("customer_type_code = 'SUPP'");
かわりに、次の例のような、実行時に定義する名前付きバインド変数を参照するWHERE句条件を追加する必要があります。
vo.setWhereClause("customer_type_code = :TheCustomerType");
vo.defineNamedWhereClauseParam("TheCustomerType", null, null);
vo.setNamedWhereClauseParam("TheCustomerType","CUST");
// execute the query and process the results, and then later...
vo.setNamedWhereClauseParam("TheCustomerType","SUPP");
これにより、問い合せる必要があるCUSTOMER_TYPE_CODEの値にかかわらず、SQL文のテキストが同じままになります。問合せテキストが複数の実行全体で同じ状態の場合は、問合せの再解析を行わずに結果がデータベースから戻されます。
これらのテクニックを示している更新済テスト・クライアント・クラスは、次の例のようになります。この場合、結果を数回ループする機能は、別個のexecuteAndShowResults()メソッドにリファクタされています。プログラムでは、最初に付加的なWHERE句のcustomer_id = :TheCustomerIdが追加されてから、後で第2句のcustomer_type_code = :TheCustomerTypeに置換されます。
package devguide.examples.readonlyvo.client;
import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
public class TestClientBindVars {
public static void main(String[] args) {
String amDef = "devguide.examples.readonlyvo.CustomerService";
String config = "CustomerServiceLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ViewObject vo = am.findViewObject("CustomerList");
// Set the two design time named bind variables
vo.setNamedWhereClauseParam("TheName","shelli%");
vo.setNamedWhereClauseParam("HighUserId", 215);
executeAndShowResults(vo);
// Add an extra where clause with a new named bind variable
vo.setWhereClause("customer_type_code = :TheCustomerId");
vo.defineNamedWhereClauseParam("TheCustomerId", null, null);
vo.setNamedWhereClauseParam("TheCustomerId",116);
executeAndShowResults(vo);
vo.removeNamedWhereClauseParam("TheCustomerId");
// Add an extra where clause with a new named bind variable
vo.setWhereClause("customer_type_code = :TheCustomerType");
vo.defineNamedWhereClauseParam("TheCustomerType", null, null);
vo.setNamedWhereClauseParam("TheCustomerType","SUPP");
// Show results when :TheCustomerType = 'SUPP'
executeAndShowResults(vo);
vo.setNamedWhereClauseParam("TheCustomerType","CUST");
// Show results when :TheCustomerType = 'CUST'
executeAndShowResults(vo);
Configuration.releaseRootApplicationModule(am,true);
}
private static void executeAndShowResults(ViewObject vo) {
System.out.println("---");
vo.executeQuery();
while (vo.hasNext()) {
Row curUser = vo.next();
System.out.println(curUser.getAttribute("CustomerId")+" "+
curUser.getAttribute("ShortName"));
}
}
}
ただし、このテスト・プログラムを実行すると、実際には次の例のような実行時エラーが発生することがあります。
oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation. Statement: SELECT * FROM (select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS where (upper(FIRST_NAME) like upper(:TheName)||'%' or upper(LAST_NAME) like upper(:TheName)||'%') and PERSON_ID between :LowUserId and :HighUserId order by EMAIL) QRSLT WHERE (person_type_code = :TheCustomerType) ## Detail 0 ## java.sql.SQLException: ORA-00904: "PERSON_TYPE": invalid identifier
PERSONS表にPERSON_TYPE_CODE列は確実に存在していますが、スタック・トレースの## Detail 0 ##の後に表示されている根本原因は、PERSON_TYPE_CODE列が存在しないというデータベースのレポートによるSQL解析エラーです。この問題は、ビュー・オブジェクトが読取り専用問合せの最初の部分で追加実行時WHERE句を適用するためにデフォルトで使用するメカニズムによって発生します。この問題の解決方法の詳細は、「実行時に行われる処理: 動的な読取り専用ビュー・オブジェクトのWHERE句」を参照してください。
実行時に名前付きバインド変数を設定するには、ViewObjectインタフェース上でsetNamedWhereClauseParam()メソッドを使用します。JDeveloperで、「リファクタ」→「複製」をメイン・メニューから選択すると、既存のTestClient.javaクラスに基づいてTestClientBindVarsクラスを新規に作成できます(「コマンド行Javaテスト・クライアントの作成方法」を参照)。このテスト・クライアント・クラスでは、コードを数行追加することにより、バインド変数の値を設定できます。たとえば、次の例に示すように、setNamedWhereClauseParam()の引数として、バインド変数HighUserIdおよびTheNameを使用できます。
// changed lines in TestClient class
ViewObject vo = am.findViewObject("CustomerList");
vo.setNamedWhereClauseParam("TheName","alex%");
vo.setNamedWhereClauseParam("HighUserId", 315);
vo.executeQuery();
// etc.
テスト・クライアント・クラスを実行すると、バインド変数によるデータのフィルタリングが行われます。たとえば、前の例のsetNamedWhereClauseParam()メソッドの結果行では、次の結果に示すように、alexという名前に基づく2つの一致のみ表示されます。
303 ahunold 315 akhoo
ビュー・オブジェクトの問合せが実行されるときは必ず、実行時デバッグ診断で、実際のバインド変数値が次の結果の例のように表示されます。
[256] Bind params for ViewObject: CustomerList [257] Binding param "LowUserId": 0 [258] Binding param "HighUserId": 315 [259] Binding param "TheName": alex%
アプリケーションをデバッグする際、この情報が非常に役立つ場合があります。コードでLowUserIdバインド変数の値が設定されなかったために、設計時にデフォルト値として0(ゼロ)が指定されたことに注意してください。さらに、WHERE句およびバインド変数の周囲でUPPER()関数を使用することにより、TheNameのバインド変数値を使用した照合が大/小文字の区別なしで確実に実行されたことに注意してください。サンプルのコードは、バインド変数値を小文字のaを使用するalex%に設定し、その結果がAlexanderと一致したことを示します。
実行時に付加的なWHERE句を読取り専用ビュー・オブジェクトに動的に追加する場合、その問合せは付加的なWHERE句を適用する前にインライン・ビューにネストされた状態になります。
たとえば、問合せが次の例のように定義されたと仮定します。
select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS where (upper(FIRST_NAME) like upper(:TheName)||'%' or upper(LAST_NAME) like upper(:TheName)||'%') and PERSON_ID between :LowUserId and :HighUserId order by EMAIL
実行時に、「実行時に名前付きバインド変数を含むWHERE句を追加する方法」のテスト・プログラムで示すperson_type_code = :TheCustomerTypeのような付加的なWHERE句を設定する場合、次の例のように、フレームワークにより元の問合せがインライン・ビューにネストされます。
SELECT * FROM( select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS where (upper(FIRST_NAME) like upper(:TheName)||'%' or upper(LAST_NAME) like upper(:TheName)||'%') and PERSON_ID between :LowUserId and :HighUserId order by EMAIL) QRSLT
そして、フレームワークにより動的なWHERE句の条件が最後に追加され、データベースで確認される最終的な問合せは次の例のようになります。
SELECT * FROM( select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS where (upper(FIRST_NAME) like upper(:TheName)||'%' or upper(LAST_NAME) like upper(:TheName)||'%') and PERSON_ID between :LowUserId and :HighUserId order by EMAIL) QRSLT WHERE person_type_code = :TheCustomerType
元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、通常はこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に付加するだけでは、予想外の結果が生成される可能性があり、たとえば、UNIONで結合された複数の文の最後の文に対してのみ適用されることがあります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。重要なのは、動的に追加されるWHERE句が、元の問合せで選択されている列しか参照できないことです(ORA-00904エラーにつながります)。
これを解決する最も簡単な方法は、ビュー・オブジェクトの概要エディタの「問合せ」ページで、問合せのSELECTリストの末尾に動的問合せの列名を追加することです。既存のSELECTリストの末尾にカンマを前に付けた新規の列名を追加するだけで、ORA-00904エラーを回避することができ、JDeveloperでは、問合せ文と同期して自動的にビュー・オブジェクトの属性リストが保持されます。または、このような問合せのネストが不要な場合にネストを無効にする方法は、「実行時のインライン・ビュー・ラッピング」を参照してください。
「実行時に名前付きバインド変数を含むWHERE句を追加する方法」で説明するテスト・クライアント・プログラムにより、次の結果が生成されました。
--- 116 S. Baida --- 116 S. Baida --- --- 116 S. Baida
名前付きバインド変数について知っておく必要のあることがいくつかあります。これには、バインド変数の名前が不一致である場合に表示される実行時エラー、バインド変数のデフォルト値などがあります。
SQL文で参照する名前付きバインド変数のリストは、ビュー・オブジェクトの概要エディタにある「問合せ」ページの「バインド変数」セクションで定義した名前付きバインド変数のリストと必ず一致している必要があります。これらの2つの変数を正しく一致させることができない場合、実行時に次の2つのエラーのどちらかが発生します。
SQL文で名前付きバインド変数を使用しても、それを定義していない場合は、次のようなエラー・メッセージを受け取ります。
(oracle.jbo.SQLStmtException) JBO-27122: SQL error during statement preparation. ## Detail 0 ## (java.sql.SQLException) Missing IN or OUT parameter at index:: 1
一方、名前付きバインド変数を定義しても、その変数をSQLで参照するのを忘れたか、名前の入力ミスをした場合、次のようなエラーが表示されます。
oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation. ## Detail 0 ## java.sql.SQLException: Attempt to set a parameter name that does not occur in the SQL: LowUserId
これらのエラーを解決するには、SQL内の名前付きバインド変数のリストが、概要エディタの「問合せ」ページの「バインド変数」セクションの名前付きバインド変数のリストと一致していることを再度確認します。
名前付きバインド変数にデフォルト値を指定しない場合、変数は実行時にNULLにデフォルト設定されます。つまり、次のようなWHERE句を持つ場合です。
PERSON_ID = :TheCustomerId
このとき、バインド変数TheCustomerIdにデフォルト値を指定しない場合は、デフォルトでNULLになるように設定され、問合せから行が戻されなくなります。アプリケーションとって意味を持つ場合は、必要に応じて状況に対処するために、NVL()、CASE、DECODE()などのSQL関数やその他の関数を活用できます。たとえば、次のようなWHERE句のフラグメントを使用すると、:TheNameの値がnullの場合、ビュー・オブジェクトの問合せに対してすべての名前が一致します。
upper(FIRST_NAME) like upper(:TheName)||'%'
ADFビュー基準を使用して行検索を使用し、行セット内の特定の行を取得します。ビュー基準の文でバインド変数を使用でき、その場合、バインド変数の値がフィルタ・パラメータの値です。
行検索は、ビュー基準を使用して行セットの中の特定の行を見つけるためにアプリケーションで使用されるオブジェクトです。行検索は、行セットに対して行参照操作を実行する必要があり、かつ、アプリケーションで行参照の指定に行のキー属性を使用しない場合に定義できます。
現在は、実行時に行キー以外の属性の参照が必要な場合に、次のシナリオで、設計時に定義した行検索を参加させることができます。
ADFビジネス・コンポーネントWebサービスで行検索を公開する場合。エンド・ユーザーは、サービス・ビュー・インスタンスの特定の行(行検索にマップされた、1つ以上の非キー属性値に一致する)に対して行更新を開始できます。このユースケースの詳細は、「ビュー基準と行検索の使用方法に関する必知事項」を参照してください。
行検索にマップされた、1つ以上の非キー属性値に一致する行セットを、アプリケーションでプログラムにより取得する場合。このユースケースの詳細は、「プログラムによる行検索の呼出し」を参照してください。
行検索では、一致した行をすべて特定するか、指定した数のみ特定するように指定できます。指定したフェッチ制限を超える数の行が行検索で特定された場合は、行検索から例外をスローするようにできます。
行検索を含むビュー・オブジェクト定義には、次の要素が含まれます。
1つ以上のビュー基準アイテムを適用してビュー・オブジェクトをフィルタリングする、指定されたビュー基準。ビュー基準アイテムは、一致する行を決定するビュー・オブジェクト属性に対して定義され、これらは、行検索で実行時に値を指定できるように、バインド変数によって定義されている必要があります。
ビュー基準のバインド変数と値のソース(ビュー・オブジェクトの一時属性または属性値の式)の間のマッピング。
たとえば、EmpVOに属性emailがある場合、EmpVOの行検索では、EmpVOに定義されたビュー基準と従業員の電子メール・アドレスを使用して、特定の従業員の行を見つけることができます。EmpVOのビュー基準は次の例のようになります。この例では、ビュー・オブジェクトEmpVOの電子メール属性の値を設定するために、ビュー基準の文にバインド変数EmailBindVarが使用されています。
( (UPPER(EmpEO.EMAIL) = UPPER(:EmailBindVar) ) )
アプリケーションでは、マップされたビュー基準のバインド変数に次のような様々な方法で値を適用することにより、行検索を起動します。
更新操作が有効なADFビジネス・コンポーネントWebサービスで、入力フィールドを持つフォームを表示できます。入力フィールドは、行検索でビュー基準のバインド変数にマップされるビュー・オブジェクトの一時属性にバインドされています。
ビジネス・コンポーネントのWebサービスの操作を有効化する方法の詳細は、「アプリケーション・モジュール・サービス・インタフェースの有効化の方法」を参照してください。
アプリケーションでビュー・オブジェクトの行検索を起動し、マップされたビュー・オブジェクト属性の値をプログラムでビュー基準のバインド変数に設定できます。「プログラムによる行検索の呼出し」を参照してください。
行検索を定義するには、ビュー・オブジェクトの概要エディタの「行検索」ページを使用します。エディタで、選択したビュー基準の各バインド変数の値のソースを定義します。ビュー・オブジェクトの属性と、属性値の式は、どちらも行検索によって定義されたバインド変数のソースとして有効です。
定義する行検索では、ビュー基準の任意の数のバインド変数を、値の有効なソースにマップできます。行検索定義でマップする追加の変数を多くすると、一致する行がより制限されます。この意味で、行検索は、行セットを変更しない問合せ検索操作に似ています。アプリケーションでは、適切に定義された行検索を使用して特定の1行を検索し、エンド・ユーザーがその行に更新を実行できるようにすることができます。
図5-37の概要エディタには、ビュー基準findEmpByEmpEmailで指定されたビュー基準のバインド変数EmailBindVarを、ビュー・オブジェクトEmpVOによって定義された一時属性TrEmpEmail(値のソース)にマップする行検索が表示されています。
注意:
マスター/ディテール階層で、ディテール・ビュー・オブジェクトの属性でマスターをフィルタリングする必要がある場合は、マスター・ビュー・オブジェクトに行検索を定義できます。このシナリオでは、「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」で説明しているように、ビュー基準でインライン・ビュー基準が使用されます。
始める前に:
行検索に関する知識が役立つ場合があります。詳細は、「行検索の使用」を参照してください。
ビュー基準に関する知識が役立つ場合があります。詳細は、「名前付きビュー基準の処理」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
目的のビュー・オブジェクトを作成します。「単一のデータベース表からのビュー・オブジェクト行の移入」または「結合問合せ結果での複数表の使用」を参照してください。
「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー・オブジェクトにビュー基準を定義します。
オプションで、「一時属性の追加方法」の説明に従い、更新可能な一時属性をビュー・オブジェクトに追加します。一時属性は、実行時に評価される属性値式の代替となります。一時属性は、アプリケーションでプログラムにより設定するか、ADFビジネス・コンポーネントWebサービス・ペイロードで公開してエンド・ユーザーに値を要求できます。基準参照値を受け取るには、一時属性を更新可能として定義する必要があります。
ビュー・オブジェクトの行検索を作成するには:
ビュー・オブジェクトの行検索を作成する場合は、行検索自体の定義も含めて、行検索で必要とされるすべてのメタデータをビュー・オブジェクト定義に含めます。次の例に示すように、行検索RowFinderのメタデータとして、ビュー・オブジェクト定義には、<Variable>要素にバインド変数EmailBindVar、<ViewAttribute>要素に一時属性TrEmpEmail、<ViewCriteria>要素にビュー基準findEmpByEmpEmailおよびビュー基準行EmpVOCriteria_Row0があり、最後に<RowFinders>要素に行検索EmpByEmailRowFinderが含まれています。
行検索の<VarAttributeMapping>サブ要素は、ビュー基準のバインド変数EmailBindVarをビュー・オブジェクトの一時属性TrEmpEmailにマップしています。これにより、エンド・ユーザーが実行時に値を指定し、アプリケーションで必要な基準属性を使用して行検索を起動できるようになっています。<ViewCriteriaItem>サブ要素は、基準属性Emailを、バインド変数EmailBindVarの値に設定しています。
実行時に、行ファインダがビュー・オブジェクトに対して起動される場合、1つ以上の基準属性に渡される一時属性値は行セット内の一致する行を識別します。この例では、従業員の電子メールアドレスを使用して、EMPLOYEE表の従業員レコードが照合されています。行検索では、行のキー値を渡さなくても従業員のレコードが特定されます。
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="EmpVO"
SelectList="EmpEO.ID,
EmpEO.LAST_NAME,
EmpEO.FIRST_NAME"
EmpEO.USERID"
EmpEO.DEPT_ID"
EmpEO.EMAIL"
FromList="S_EMP EmpEO"
...
<Variable
Name="EmailBindVar"
Kind="viewcriteria"
Type="java.lang.String"/>
<EntityUsage
Name="EmpEO"
Entity="model.entities.EmpEO"/>
...
<ViewAttribute
Name="TrEmpEmail"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="CHAR"
AliasName="VIEW_ATTR"
SQLType="VARCHAR"/>
...
<ViewCriteria
Name="findEmpByEmpEmail"
ViewObjectName="model.views.EmpVO"
Conjunction="AND">
...
<ViewCriteriaRow
Name="EmpVOCriteria_row_0"
UpperColumns="1">
<ViewCriteriaItem
Name="Email"
ViewAttribute="Email"
Operator="="
Conjunction="AND"
Value=":EmailBindVar"
IsBindVarValue="true"
Required="Optional"/>
</ViewCriteriaRow>
</ViewCriteria>
...
<RowFinders>
<AttrValueRowFinder
Name="EmpByEmailRowFinder"
FetchLimit="1"
ErrorOnExceedingLimit="true">
<ViewCriteriaUsage
Name="findEmpByEmpEmail"
FullName="model.views.EmpVO.findEmpByEmpEmail"/>
<VarAttributeMap>
<VariableAttributeMapping
Variable="EmailBindVar"
Attribute="TrEmpEmail"/>
</VarAttributeMap>
</AttrValueRowFinder>
</RowFinders>
</ViewObject>
行検索とビュー基準は、どちらもプログラムまたは宣言により使用して、ビュー・オブジェクト行セットをフィルタできます。行検索は、ビュー・オブジェクトおよびビュー基準属性バインド変数を定義する一時属性間のマップを定義するため、ビュー基準とは異なります。最終的に、行検索は、実行時に解決される一時属性値で定義されたバインド変数を持つビュー・オブジェクトにビュー基準を適用することで、ビュー・オブジェクトの1つ以上の行を照合します。
行検索によってマップされた一時属性により、アプリケーションで使用される行検索は、ビュー基準単体には適していないアプリケーション・ユースケースで使用できます。特に、行検索は、ADFビジネス・コンポーネントWebサービスがCRUD操作を有効にした場合に最も役立ちます。この場合、行検索はADFビジネス・コンポーネントWebサービスの開発者に、あいまいな行キー値を必要とせずにCRUD操作を公開する機能を提供します。
Fusion Webアプリケーション開発者は、Webサービス・データ・コントロールを作成して、JDeveloperの「データ・コントロール」パネルでADFビジネス・コンポーネントWebサービスのビュー・オブジェクトを公開できます。ビュー・オブジェクトの公開された行検索でマップされた一時属性を使用して、エンド・ユーザーが目的の更新を行える入力フォームを設計できます。たとえば、エンド・ユーザーは、個人の電子メール・アドレスなどの使い慣れた属性の値を提供して、特定の個人の行を照合し、名前変更を可能にする操作などの更新操作をその行の任意の属性に対して開始できます。
ADF Webサービスでの行検索サポートの詳細は、「行ファインダとADF Webサービス操作に関する必知事項」を参照してください。ADF Webサービスに基づくデータ・コントロールの作成の詳細は、『Oracle ADFデータ・コントロールによるアプリケーションの開発』の「ADFデータ・コントロールの使用」を参照してください。
「行検索を使用したマスター・ビュー・オブジェクトの行の検索方法」で説明するように、キー以外の属性を使用して行を照合する行検索の機能は、マスター/ディテール関連ビュー・オブジェクトに拡張されます。
行検索を定義したら、ビュー・オブジェクトに対して行検索を起動します。行検索定義で行制限が指定されている場合、実行された行検索ではRowFinderFetchLimitExceededException例外がスローされます。
ビュー・オブジェクトに定義した行検索を起動するには、次の基本手順に従います(後に例を示しています)。
行検索を定義しているビュー・オブジェクトを見つけます。
ビュー・オブジェクトから行検索を見つけます。
行検索の各バインド変数のマッピング用に、名前と値のペアを作成します。
行検索でマップされた一時属性を使用して、各バインド変数を設定します。
目的のビュー・オブジェクトに対して行検索を起動します。
一致する行数が行検索のフェッチ制限を超える場合は、例外をスローします。
実行時に、行検索がビュー・オブジェクトに対して起動される場合、setAttribute()によって移入された、行検索でマップされた一時属性値が基準属性に設定されて、行セット内の一致する行を識別します。次の例では、従業員の電子メール・アドレスを使用して、EmpViewビュー・オブジェクトの従業員レコードが照合されています。行検索EmpByEmailRowFinderは、一時属性TrEmpEmailを使用して、行キー値を渡す必要なしに条件属性を指定して、従業員のレコードを特定します。
package model;
import oracle.jbo.*;
import oracle.jbo.client.Configuration;
import oracle.jbo.server.RowFinder;
import oracle.jbo.server.ViewObjectImpl;
public class TestClient
{
public TestClient()
{
super();
}
public static void main(String[] args)
{
TestClient testClient = new TestClient();
String amDef = "model.AppModule";
String config = "AppModuleLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
// 1. Find the view object with the row finder
ViewObjectImpl vo = (ViewObjectImpl)am.findViewObject("EmpView1");
Row r;
RowIterator ri;
// 2. Find the row finder
RowFinder finder = vo.lookupRowFinder("EmpByEmailRowFinder");
// 3. Create name value pairs for the row finder
NameValuePairs nvp = new NameValuePairs();
// 4. Set the row-finder mapped transient attribute
nvp.setAttribute("TrEmpEmail", "cee.mague@company.com");
// 5. Invoke the row finder
try
{
ri = finder.execute(nvp, vo);
}
// 6. Throw an exception when row match exceeds specified limit
catch(RowFinderFetchLimitExceededException e)
{
System.out.println("Warning: more than one row match exists.");
}
while (ri.hasNext())
{
r = ri.next();
System.out.println("Find emp row by email finder: " +
r.getAttribute("FirstName") + "/" + r.getAttribute("LastName"));
}
Configuration.releaseRootApplicationModule(am, true);
}
}
ADFモデル・プロジェクトでビュー・オブジェクトの属性をLOV属性として定義し、ユーザー・インタフェースで選択内容に基づいてユーザー入力に使用できるようにすることが可能です。
アプリケーションのユーザー・インタフェース部分に表示される編集フォームでは、データ・モデルで定義するLOV有効属性を利用して、個々の入力フィールドの値リストを事前に指定できます。たとえば、編集フォームに国のリストが表示され、その編集フォーム内の対応する住所フィールドに値が移入されるようになっている場合があります。この一般的な設計タスクを容易にするために、ADFビジネス・コンポーネントでは、ユーザー・インタフェースでの属性のLOVの使用法を指定する宣言的な方法をサポートしています。
データ・モデル・プロジェクトでビュー・オブジェクトの属性に対してLOVを定義すると、ユーザー・インタフェースでリスト・コントロールを使用するタスクが大幅に簡略化されます。ビュー・オブジェクトの個々の属性にLOVを定義するため、属性に対してLOV使用をカスタマイズすると、属性が表示されるフォームでリスト・コンポーネントを参照できます。
注意:
LOVをUIに表示するには、ユーザー・インタフェース・デザイナによってデータバインドされたフォームが作成される前に、LOVの使用方法を指定しておく必要があります。既存のフォームから参照される属性に対してLOVの使用方法を定義しても、LOVに表示するフォームのコンポーネントは変更されません。
ユーザー・インタフェースに表示する任意のビュー・オブジェクト属性に対しては、LOVを選択リストとして定義できます。属性のLOV定義の特性は、ユーザー・インタフェースの要件に応じて異なります。ユーザー・インタフェース・デザイナから収集する情報により、最適な解決策が決定されます。たとえば、次のような場合に対してLOV属性を定義できます。
ビジネス・ドメイン・オブジェクトに対してビュー・オブジェクト問合せから取得した属性値を表示する必要がある場合。
たとえば、LOV属性を定義して発注書にサプライヤのリストを表示する場合などです。
ビュー・オブジェクト問合せから取得した属性値を表示すると同時に、LOV属性の現在行の任意の属性からパラメータ値を使用して、その属性値をフィルタリングする必要がある場合。
たとえば、LOV属性を定義して発注書にサプライヤのアドレス・リストを表示すると同時に、現在のサプライヤを基にアドレス・リストを制限する場合などです。
必要に応じて、2番目のLOVは、ユーザーの選択に基づくパラメータ値の制御に使用できます。たとえば、ユーザーが現在のサプライヤを選択するとそのサプライヤのアドレス・リストを操作できるようにします。この場合、2つのLOVはカスケード・リストと呼ばれます。
LOV属性を定義するには、LOVによって表示する属性値に対して適切な行を問い合せるデータソース・ビュー・オブジェクトを、データ・モデル・プロジェクト内にあらかじめ作成しておく必要があります。その後、ベース・ビュー・オブジェクトでLOVを定義するためのすべての処理を行います。ベース・ビュー・オブジェクトとは、ユーザー・インタフェースに表示するプライマリ・データを含むビュー・オブジェクトです。LOVの使用方法により、次のビュー・オブジェクト・メタデータが追加定義されます。
LOV属性のデータソースにアクセスするためのビュー・アクセッサ。ビュー・アクセッサとは、データソース・ビュー・オブジェクトの行セットから可能な値のリストを取得するためのADFビジネス・コンポーネントのメカニズムです。
リストが定義されているデータソース属性以外のベース・ビュー・オブジェクトの属性に対してデータソースから戻される追加の値(オプション)。
表示するリスト・コンポーネントのタイプを含むユーザー・インタフェース・ヒント、複数の表示属性が必要な場合に現在行から表示する属性、および選択リスト・コンポーネントに固有のオプション。
注意:
LOV機能では、表示リストを検証するための属性検証の使用はサポートされていません。リストの表示時には、データ・ソース属性(サプリメンタル属性を含む)に対して定義されている検証規則は抑制されるため、LOVリストは制限されません。開発者は、データ・ソース・ビュー・オブジェクトから返される値のリストに、必要で有効な値のみが含まれるようにする必要があります。
LOV有効属性を定義するプロセスでは通常、ベース・ビュー・オブジェクト属性に対して表示する「値リストの作成」ダイアログを使用します。
LOV有効属性を定義するには、通常は次のプロセスに従います。
ベース属性の「値リストの作成」ダイアログを開きます。
新規のビュー・アクセッサ定義を作成してデータソース・ビュー・オブジェクトを指定するか、またはベース・ビュー・オブジェクトによって定義済の既存のビュー・アクセッサを選択します。
サポートしたいユースケースごとに新しいビュー・アクセッサを必ず作成してください。同じデータ・ソースに依存する複数のLOVリストを定義するために1つのビュー・アクセッサを再利用しないでください。ビュー・アクセッサを再利用すると、実行時に予期しない結果が発生することがあります。
必要に応じて、ベース・ビュー・オブジェクトの現在行の任意の属性から値を取得するバインド変数を使用してビュー基準を作成することにより、ビュー・アクセッサをフィルタリングできます。
ビュー基準を作成してデータ・ソース・ビュー・オブジェクトをフィルタリングする場合は、ビュー基準のバインド変数への値の入力に使用するベース・ビュー・オブジェクトの属性に必須LOVを設定することもできます。このように連携するLOVリストは、カスケードLOVリストと呼ばれます。ユーザーによる属性の選択によって2番目の属性リストに表示されるオプションを制御する場合は、カスケードLOVリストを設定します。
ビュー・アクセッサのデータソース・ビュー・オブジェクトからリスト属性を選択します。
これにより、選択した属性がベース・ビュー・オブジェクトの現在の属性にマップされます。
必要に応じて、リスト戻り値を選択し、リストによりベース・ビュー・オブジェクトに戻される追加の値をマップします。
ユーザー・インタフェース・ヒントを選択して、リストの表示機能を指定します。
属性の変更内容を保存します。
LOV有効属性を作成した後、ユーザー・インタフェース・デザイナでは、「データ・コントロール」パネルからLOV有効属性のコレクションをドラッグするとリスト・コンポーネントをWebページに作成できます。リストを表示するWebページの作成の詳細は、「データバインドされた選択リストおよびシャトルの作成」を参照してください。特に、WebページでのLOV有効属性の処理の詳細は、「モデルドリブン・リストの作成方法」を参照してください。
編集フォームに表示されるリスト値が、編集フォーム内の別の選択内容に依存しないようにする場合は、ビュー・アクセッサを定義してリスト・データソースを指定できます。たとえば、ユーザーが注文項目のサプライヤを選択する必要があるフィールドが発注書に含まれているとします。この例では、最初にデータソース・ビュー・オブジェクト(SuppliersView)を指定するビュー・アクセッサを作成します。次に、ベース・ビュー・オブジェクト(PurchaseOrdersView)のSupplierDesc属性にLOVを設定します。最後に、ベース・ビュー・オブジェクトのLOV有効属性(SupplierDesc)からビュー・アクセッサを参照し、データソース属性(SupplierDesc)を選択します。
ベース・ビュー・オブジェクトのLOV有効属性を定義するには、「値リストの作成」ダイアログを使用します。このダイアログでは、既存のビュー・アクセッサを選択したり、新規のビュー・アクセッサを作成してLOV属性定義とともに保存できます。
始める前に:
LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
ビュー・オブジェクト属性の値を表示するLOVを定義するには:
アプリケーションのユーザー・インタフェースで、1つの入力フィールドの値リストが、別のフィールドへのユーザー入力値に依存する場合は、ユーザー・インタフェースにカスケード・リストとして表示される属性を作成できます。この場合は、LOV有効属性として使用可能な値のリストは、行ごとに異なります。LOV値は、ユーザーが現在行を変更するたびに、LOV有効属性のビュー行にある1つ以上の制御属性の値に基づいて変化します。制御属性をLOV有効属性に適用するには、データソース・ビュー・オブジェクトにアクセスするためのビュー・アクセッサを作成し、そのアクセッサに対して、使用可能な値リストを制御属性の現在値に基づいてフィルタリングするという要件を追加します。LOV有効属性をフィルタリングするには、ビュー・アクセッサを編集して、ユーザーの選択を取得するためのバインド変数を持つ名前付きビュー基準を追加します。
たとえば、発注フォームに、ユーザーがサプライヤ固有のサイトを選択する必要があるフィールドが含まれており、利用可能なサイトは注文で指定済のサプライヤによって決まるとします。この要件を満たすには、まず、データ・ソース・ビュー・オブジェクトを指定するビュー・アクセッサを作成します。データ・ソース・ビュー・オブジェクトは、ユーザーが選択したサプライヤに基づいて利用可能なサプライヤ・サイトをフィルタリングする問合せを実行する必要があるため、LOVの使用方法に固有のものになります。このデータ・ソース・ビュー・オブジェクトの定義にSupplierIdsForCurrentSupplierSiteという名前を指定することにより、データ・モデル内にすでに存在するSupplierSitesViewビュー・オブジェクトと区別できます。データ・ソース・ビュー・オブジェクトでは、制御属性(SupplierId)についてユーザーの選択を取得するためのバインド変数(TheSupplierId)でビュー基準アイテムを1つ設定した名前付きビュー基準(SupplierCriteria)が使用されます。
次に、ベース・ビュー・オブジェクト(PurchaseOrdersView)のSupplierSiteId属性にLOVを設定します。これにより、ベース・ビュー・オブジェクトのLOV有効属性(PurchaseOrdersView.SupplierSiteId)から、データベース・ビュー・オブジェクトを指定するビュー・アクセッサを参照できます。最後に、LOV有効属性のビュー・アクセッサ定義を編集することにより、ビュー・オブジェクトから対応する属性(SupplierIdsForCurrentSupplierSite.SupplierSiteId)をデータソースとして指定し、同時に、属性SupplierIdを使用してビュー行の結果からバインド変数の値を指定する必要があります。
LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義するには:
カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトを作成します。
カスケード・リストをフィルタリングするビュー・アクセッサを作成します。
データ・ソース・ビュー・オブジェクトでは、LOV有効属性の制御属性を定義します。制御属性をベース・ビュー・オブジェクトのLOV有効属性からアクセス可能にするには、別の属性の値に基づいてデータ・ソース属性をフィルタリングする名前付きビュー基準を定義する必要があります。制御属性の値は実行時に変更されるため、ビュー基準では、バインド変数を使用して制御属性を設定します。
始める前に:
LOV有効属性のカスケードに関する知識が役立つ場合があります。詳細は、「LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
LOV有効属性が参照可能なデータ・ソースのビュー基準を定義する手順:
カスケードLOV有効属性を移入するには、まずデータ・ソース・ビュー・オブジェクトで名前付きビュー基準を設定する必要があります。ベース・ビュー・オブジェクトのLOV有効属性がデータ・ソース・ビュー・オブジェクトの制御属性に依存するようにするために、ベース・ビュー・オブジェクトのLOV有効属性にビュー・アクセッサを追加し、以前に定義済のデータ・ソース・ビュー・オブジェクトの名前付きビュー基準を参照します。
始める前に:
LOV有効属性のカスケードに関する知識が役立つ場合があります。詳細は、「LOVが有効なビュー・オブジェクトの属性に対してカスケード・リストを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
LOV有効属性に対する表示値を、同じビュー行にある別の属性値に基づいてフィルタリングするためのビュー・アクセッサを作成する手順:
アプリケーションのユーザー・インタフェースに表示される値リストを変化させるもう1つの方法は、単一のLOV有効ビュー・オブジェクト属性に複数の値リストを定義することです。依存するLOVリスト選択に基づいてリストの内容を変化させるカスケード・リストとは対照的に、複数のLOVを含むLOV有効切替え属性により、LOV全体を変化させることができます。表示されるLOVの選択は、適用するLOV名の解決のために特別に定義した属性値によって実行時に制御されます。
たとえば、フォームの作成や編集で適用する1つのLOVと、検索コンポーネントに適用するもう1つのLOVを定義するとします。最初のケースでは、フォームが使用できるLOV有効属性は、エンティティを参照するすべてのビュー・オブジェクトで共有されるエンティティ・ベースのビュー・アクセッサになります。単一のアクセッサ定義をフォームの同じLOVの各インスタンスに適用できるので、エンティティ・ベースのビュー・アクセッサは、ユーザー・インタフェース・フォームで便利です。ただし、検索コンポーネントの場合は、基礎をなすエンティティから導出されたビュー・アクセッサに基づいたLOV定義は機能しません。検索コンポーネントのLOV定義は、ビュー・オブジェクトで定義されたビュー・アクセッサに基づいている必要があります。ユーザーが検索を開始すると、基準行の値がWHERE句のパラメータに変換されます。作成または編集タイプのフォームに表示される通常のビュー行とは異なり、基準行はエンティティを基礎としません。このシナリオでは、1つ目のLOVはデータ・ソースとしてエンティティ・ベースのアクセッサを使用し、2つ目のLOVはデータ・ソースとしてビュー・オブジェクトベースのアクセッサを使用します。
この要件に対応して同一の属性にアクセスする複数のLOVを定義するには、ベース・ビュー・オブジェクトに切替え属性を追加します。たとえば、Ordersビュー・オブジェクトに対して、式を通じて表示するLOVの名前を解決するShipperLOVSwitcher属性を追加できます。このような式では、ShipperID属性に適用できる2つのLOVを指定できます。
(adf.isCriteriaRow) ?"LOV_ShipperID_ForSearch" : "LOV_ShipperID"
この式は、切替え属性の「値」フィールドに表示されます。検索コンポーネントの場合は、実行時に、この式はビュー・オブジェクトベースのアクセッサのLOVを識別する値になります。作成または編集フォームの場合は、この式はエンティティ・ベースのアクセッサのLOVを識別する値になります。
ベース・ビュー・オブジェクトの属性に複数のLOVを追加するには、「値リストの作成」ダイアログを使用します。ベース・ビュー・オブジェクトの概要エディタの「属性」ページの「値リスト」セクションでは、表示するデフォルトのLOVと適用する切替え属性も定義できます。
始める前に:
LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性の最初のLOVリストを作成します。
切替え属性シナリオでは、一意のビュー・アクセッサを作成する必要があることに注意してください。複数のLOVリストを定義するために1つのビュー・アクセッサを再利用しないでください。様々なユース・ケースに対してビュー・アクセッサを再利用すると、実行時に予期しない結果が発生することがあります。
ビュー・オブジェクト属性に既存のLOVを使用して追加LOVリストを指定するには:
ビュー・オブジェクトで定義する参照属性は適切な属性である場合があり、LOVリストのソースとして使用されます。ビュー・オブジェクトに追加したセカンダリ・エンティティ・オブジェクト慣用名に参照属性は属し、エンティティ・オブジェクトの慣用名の主キー属性よりも意味のある情報を示します。たとえば、OrderInfoビュー・オブジェクトを作成すると、ビュー・オブジェクトによりPaymentOptionsEO用にセカンダリ・エンティティ・オブジェクトの慣用名が定義され、エンド・ユーザーがアカウントに追加したクレジット・カードのリストを含めて、順序用に請求情報が含まれる場合があります。
セカンダリ・エンティティ・オブジェクト用に定義したLOVは、プライマリ属性値を更新できる必要がありますが、エンド・ユーザーにとって意味のあるように、通常プライマリ属性はリストで非表示にし、かわりに参照属性を1つ以上表示します。この場合、LOVではクレジット・カードのリストが会社名別に表示される場合がありますが、エンド・ユーザーの選択により更新される支払いオプションID値は非表示になる場合があります。図5-38は、InstitutionName参照属性が定義されたLOVを示します。「値リストの作成」ダイアログの「リスト戻り値」セクションでは参照属性をリストしてから主キー属性のPaymentOptionIdをリストし、追加値を用意します。
図5-38 参照属性が指定されている「ビュー基準の作成」ダイアログ
始める前に:
セカンダリ・エンティティ・オブジェクトの慣用名における参照属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
LOVの参照属性を定義するには:
LOVとして定義するビュー・オブジェクト属性がユーザー・インタフェースにどのように表示されるかが明確な場合は、LOVの追加プロパティを指定してその表示特性を指定できます。これらのプロパティ(UIヒント)により、ADFビジネス・コンポーネントで任意のビュー・オブジェクト属性に設定できる属性ヒント・プロパティを拡張できます。LOV有効属性のLOV UIヒントには、ユーザー・インタフェースでリストの表示に使用されるコンポーネントがあります。使用可能なコンポーネントの詳細は、表5-2を参照してください。(表5-2に示すように、すべてのADF Facesコンポーネントがデフォルトのリスト・タイプをサポートしているとはかぎりません。)
表5-2 リスト・タイプのUIヒントのリスト・コンポーネント・タイプ
| LOVのリスト・コンポーネント・タイプ | 用途 |
|---|---|
選択リスト  |
このコンポーネントでは、ドロップダウン・リストからの選択のみ可能で、テキスト入力はできません。 |
コンボ・ボックス  |
このコンポーネントでは、テキスト入力もドロップダウン・リストからの選択も可能です。このコンポーネントでは、ユーザーによる入力にオートコンプリートがサポートされる場合があります。 このコンポーネントは、ADF Facesではサポートされていません。 |
値リストを持つコンボ・ボックス  |
このコンポーネントは、一番下にあるエントリ(「詳細」)を選択すると、UIヒントのLOV属性に対して有効にした場合に問合せでフィルタリングがサポートされる「値リスト」参照ダイアログが開くこと以外は、コンボ・ボックスと同じです。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。 ただし、LOV属性が表コンポーネントに表示される場合、リスト・タイプは、「値リストを使用した入力テキスト」コンポーネントに変わります。 |
値リストのある入力テキスト  |
このコンポーネントでは、横にLOVボタンのある入力テキスト・フィールドが表示されます。このボタンをクリックするか、テキスト・フィールドに無効な値を入力すると、「値リスト」参照ダイアログが表示されます。このコンポーネントの「値リスト」ダイアログでは、UIヒントのLOV属性に対して有効にした場合に、問合せでフィルタリングがサポートされます。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。 このコンポーネントでも、一致対象が1つになる場合は、オートコンプリートがサポートされます。 |
リスト・ボックス  |
このコンポーネントでは、(ユーザーがクリックするまで1行分の領域しか表示されない選択リストとは異なり)画面上に一定の大きさの領域が表示され、スクロール操作が可能です。 |
ラジオ・グループ  |
このコンポーネントには、LOV属性値で指定した選択項目で構成されるラジオ・ボタン・グループが表示されます。このコンポーネントは、項目の少ない固定リストには非常に有用です。 |
始める前に:
LOV有効属性に関する知識が役立つ場合があります。「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
LOV有効属性に対してビュー・オブジェクト属性のUIヒントを設定するには:
「アプリケーション」ウィンドウで、カスタマイズする属性を含むビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、目的の属性を選択し、「値リスト」タブをクリックします。
「値リスト」ページで、カスタマイズするLOVリストを選択し、「値リストの編集」ボタンをクリックします。
「値リストの編集」ダイアログで、「UIヒント」タブをクリックします。
「UIヒント」ページで、リストを表示するコンポーネントのタイプとして、「デフォルトのリスト・タイプ」を選択します。
使用可能なコンポーネントの詳細は、表5-2を参照してください。
Webページに表示されるリスト・コンポーネントと、ビュー・オブジェクトのデフォルトのリスト・タイプは実行時に一致する必要があり、一致しない場合は実行時例外(method-not-found)が発生します。このエラーを回避するには、ユーザー・インタフェース・デザイナで目的のリスト・コンポーネントを確認します。これらが一致するようにデフォルト・リストを編集できるので、その後ユーザー・インタフェース・デザイナでWebページで使用されるコンポーネントを変更しても、2つの同期が維持されます。
必要に応じて、さらに「属性の表示」を選択し、値を表示に追加します。
追加属性のリストは、LOV有効属性のビュー行から導出されます。追加属性の値を使用すると、エンド・ユーザーによるリストからの項目選択が容易になります。
「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択すると、デフォルトでは、コンポーネントのドロップダウン・リストにはデータ・ソースから最初の10レコードが表示されます。この制限により、ビュー・オブジェクトの小さいフェッチ・サイズも維持できます。「値リストを使用したコンボ・ボックス」コンポーネントのドロップダウン・リストに表示できるレコード数を変更するには、「問合せ限度」にレコード数を入力します。
ユーザーがレコードの全セットを表示できるようにする場合は、その目的に「問合せ限度」を使用しないでください。「問合せ限度」は、ビュー・オブジェクトでフェッチされる行数も制御(ビュー・オブジェクト定義のListRangeSizeプロパティを設定)しているため、最適なパフォーマンスを実現するうえで、この値は小さくしておく必要があります。レコードの全セットにアクセスする必要のあるエンド・ユーザーは、コンポーネントの参照アイコンをクリックしてLOV参照ダイアログを開き、そこでレコードを表示するようにしてください。
「問合せ限度」は、他のすべてのコンポーネント・タイプでは無効になっており、これらのコンポーネントでは、LOVがアクセスする行数は制限されません。
ListRangeSizeプロパティの詳細は、「実行時に行われる処理: LOVでリスト・データソースを問い合わせる方法」を参照してください。
値リストの参照ダイアログを開いてユーザーが値リストを選択できるようにするコンポーネント・タイプ(「値リストを使用したコンボ・ボックス」タイプ・コンポーネントや「値リストを使用した入力テキスト」タイプ・コンポーネントを含む)を選択した場合、参照ダイアログには、データ・ソース・ビュー・オブジェクトのすべての問合せ可能属性を検索できる検索フォーム(LOV有効属性のビュー・アクセッサによって定義されたもの)が表示されます。これらのコンポーネントのカスタマイズ方法を指定します。
「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択し、「選択されたもの」リストに多数の属性を追加済の場合は、「コンボ・ボックスに表示」を使用してこのコンポーネントのドロップダウン・リスト部分を読みやすくします。「値リストを使用したコンボ・ボックス」コンポーネントに表示されるドロップダウン・リストに含まれる属性列を制限するには、「コンボ・ボックスに表示」から「最初」を選択し、ドロップダウン・リストに表示する、「選択されたもの」リストの最上部からの属性の数に対応する数字を入力します(この組合せでは、「値リストの作成」ダイアログの「選択されたもの」リストから表示する最初のx個の属性を指定します)。ドロップダウン・リストに表示される属性列数を制限することにより、ユーザーは完全なリストを確認するために水平にスクロールする必要がなくなりますが、これによって「値リスト」参照ダイアログに表示される属性列の数が制限されるわけではありません。このオプションは、「値リストを使用したコンボ・ボックス」を除くすべてのリスト・コンポーネント・タイプで無効にされています。
「検索リージョンを含む」ドロップダウン・リストからビュー基準を選択すると、「値リスト」参照ダイアログに表示する属性を制限できます。ドロップダウン・リストにビュー基準を表示するには、そのビュー基準がデータソース・ビュー・オブジェクト(LOV有効属性のビュー・アクセッサで定義したオブジェクト)で定義されている必要があります。選択したビュー基準の検索フォーム・プロパティを設定するには、「ビュー基準の編集」ボタンをクリックします。検索フォームのビュー基準のカスタマイズの詳細は、「ビュー基準にユーザー・インタフェース・ヒントを設定して検索フォームをサポートする方法」を参照してください。
「リストを自動的に問合せ」を選択すると、「値リスト」参照ダイアログの結果表に事前に移入できます。ユーザーが「値リスト」参照ダイアログを開くと、問合せの結果が表示されます。このオプションの選択を解除したままだと、ユーザーが検索フォームを送信するまで結果は表示されません。
また、「値リスト」参照ダイアログに検索リージョンを表示したくない場合は、「検索リージョンを含む」ドロップダウン・リストから<検索なし>を選択します。この場合、「値リスト」参照ダイアログには、「属性の表示」リストに追加した属性しか表示されません。
リストに表示する選択タイプ・コンポーネントを選択した場合は、選択可能なすべての値を表示する代替手段として、「最近使用されたカウント」を指定できます。
たとえば、発注書に入力するSupplierId値の選択リストがフォームに表示されることがあります。このケースでは、最近表示されたサプライヤのリストからユーザーが選択できるようにし、入力するカウント数によってサプライヤの選択肢の数を指定できます。デフォルトのカウント0(ゼロ)では、選択リストに属性のすべての値が表示されます。
リストを表示するコンポーネントとして「値リストを使用したコンボ・ボックス」タイプを選択した場合、「コンボ・ボックスのフィルタ基準」ドロップダウン・リストからビュー基準を選択し、LOVに表示される有効な値のリストを制限できます。
「コンボ・ボックスのフィルタ基準」を有効にすると、ドロップダウン・リストには、LOVのビュー・アクセッサに関連するビュー・オブジェクト定義から既存のビュー基準が表示されます。ドロップダウン・リストにビュー基準が表示されない場合は、データ・ソース・ビュー・オブジェクトにビュー基準が定義されていません。この機能を有効にしない場合、「値リストを使用したコンボ・ボックス」コンポーネントは、ビュー・アクセッサから戻された完全な行セットからその値を導出します。「値リストを使用したコンボ・ボックス」のフィルタは、ポップアップ検索ダイアログでLOVを使用する場合や、有効な選択肢が限定されたドロップダウン・リストでLOVを使用する場合に便利な機能です。ユーザー・インタフェースでの「値リストを使用したコンボ・ボックス」コンポーネントの使用の詳細は、「値リスト(LOV)入力フィールド」を参照してください。
リスト・コンポーネントに表示されるNULL値の選択肢をリスト・コンポーネントが処理する方法を決定します。このオプションは、選択可能なすべてのリスト・コンポーネント・タイプで有効にされていません。
「"選択なし"アイテムを含める」を有効にすると、ドロップダウン・リストから選択して、NULL値の選択肢がリストに表示される方法も決定できます。たとえば、ラベル付きアイテムを選択する場合は、ドロップダウン・リストの編集フィールドに目的のラベルを入力するか、「...」ボタン(編集フィールドの右)をクリックしてビュー・オブジェクトに関連付けられているリソース・バンドルからメッセージ文字列を選択することができます。リソース・バンドルからメッセージ文字列を選択すると、この文字列に対応するメッセージ・キーがビュー・オブジェクト定義ファイルに保存されます。実行時に、UIはこの文字列を特定し、現在のユーザーのロケール設定とローカライズされたリソース・バンドルのメッセージ・キーに基づいて表示します。
「OK」をクリックします。
ビュー・オブジェクトのLOV有効属性が日付情報(属性OrderShippedDateなど)にバインドされている場合、Oracle ADFでは、デフォルトで、日付と時間を組み合せたyyyy-MM-dd hh:mm:ssのようなフィールドのフォーマットとみなされます。この日付と時間を組み合せたフォーマットは、ADFビジネス・コンポーネントDateドメイン・クラス(jbo.domain.Date)で指定されており、ユーザーがLOV有効属性によって指定される日付を選択するとADF Facesコンポーネントの変換の問題が生じます。ADF Facesコンポーネントがドメイン・タイプをDateタイプに変換できない場合、ユーザー・インタフェースによって入力フィールドが無効にされ、エラー: 日付の書式が正しくありません。というメッセージが表示されます。
このような変換エラーの発生を回避するために、LOVを有効にするビュー・オブジェクトの日付値属性に対してUIヒントを構成します。指定するUIヒントでは、yyyy-MM-ddのような日付のみのマスクを定義します。その後、この属性を参照するADF Facesコンポーネントは、そのEL値バインディング式(#{bindings.Hiredate.formatなど)によって指定されたパターンに基づいて変換を実行し、ADFビジネス・コンポーネント・ドメインの日付/時間ではなく、UIヒント・フォーマットを参照します。変換エラーは、フォーマット・マスクが指定されていないために、EL式でNULLと評価された場合に発生します。
始める前に:
LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
UIヒントをビュー・オブジェクトのレベルでサポートすることに関する知識が役立つ場合があります。UIヒントの詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
LOV有効属性の日付フォーマットに一致するUIヒントを設定するには:
ビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにする必要がある場合は、データ・ソース・ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定できます。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。アプリケーション・モジュールで定義する読取り専用ビュー・インスタンスに対して、この機能を有効にできます。ビュー・オブジェクトでこのプロパティを有効にすると、ユーザーがデータベース表にコミットする変更は、同一のデータベース表を利用して作業しているすべての他のユーザーに利用可能になります。一般的には、ビュー・アクセッサにLOV有効ビュー・オブジェクト属性を定義するときに、データソース・ビュー・オブジェクトの自動リフレッシュが有効にされます。
自動リフレッシュ機能はOracle Databaseの変更通知機能を使用するため、ビュー・オブジェクトで自動リフレッシュを有効にする場合は、これらの制限事項に従ってください。
ビュー・オブジェクトで読取り専用の表のみ問い合せて、表の数をできるだけ少なくしてください。これにより、パフォーマンスが最適化され、データベースで無効なキューが増大するのを防ぐことができます。
更新可能な自動リフレッシュ・ビュー・インスタンスが含まれるアプリケーション・モジュールは、共有し、更新中に行をロックするように構成します。
データベース・ユーザーに、データベースの通知権限があることを確認します。たとえば、SQL*Plusコマンドを使用して通知権限を付与するには、grant change notification to <ユーザー名>を使用します。
ビュー・オブジェクトの自動リフレッシュを有効にする前に、問合せで問合せ結果変更通知との互換性をテストします。すべての問合せ定義が、問合せ結果変更通知の要件を満たすとはかぎりません。
ビュー・オブジェクトの自動リフレッシュを有効にし、これらの制限事項に従うと、Oracleデータベースの変更通知機能によってリフレッシュが実行されます。実行時のビュー・オブジェクト問合せの実行前に、このフレームワークではJDBC APIを使用してビュー・オブジェクト問合せを登録し、基礎となるデータの変更に関するデータベース変更通知を受け取ります。(基礎となるデータが変更されたため)ビュー・オブジェクトが通知を受け取ると、ビュー・オブジェクトの行セットはダーティとしてマークされ、このフレームワークではクライアントから中間層への次のサーバー・トリップでこの行セットがリフレッシュされます。この時点で、ダーティ・コレクションは破棄され、更新されたデータがリクエストされると、ビュー・オブジェクトによって新しい問合せ実行がトリガーされます。アプリケーション・モジュールは次のチェックアウトまで待機するため、現在のトランザクションの行セットの状態が維持され、更新によってエンド・ユーザーの操作が妨げられることはありません。
たとえば、ユーザーはカレンダのエントリを作成または編集可能で、他のユーザーが追加したカレンダ・エントリの編集はできないとします。ユーザーが新しいエントリを作成し、コミットすると、同じサーバー・トリップで、他のユーザーが変更または入力したカレンダ・エントリが更新されます。しかし、もう1人のユーザーがカレンダ・エントリを作成すると、ビュー・オブジェクトは通知を受け取り、次のサーバー・トリップまで待機してからリフレッシュを行うため、この更新実行までの遅延により、同じデータを読み取る複数のユーザー間の競合を回避できます。
別の例では、LOVに郵便番号リストが表示されており、データベース管理者が読取り専用の方法で管理しています。管理者が新しい郵便番号をデータベースの行として追加すると、アプリケーション・モジュールが残っているリクエストがない時を検出し、郵便番号リストにアクセスするビュー・インスタンスに対して保留中の通知がないことを判断します。その時点で、ビュー・オブジェクトはデータのリフレッシュを行い、それ以降のすべてのリクエストは新しい郵便番号を参照します。
注意:
Webアプリケーションには、オプティミスティック行ロックを使用します。デフォルト構成で設定されているオプティミスティック・ロックでは、相互に影響を与えずに複数のトランザクションを完了できることが前提になります。したがって、オプティミスティック・ロックにより、リフレッシュ対象の行をロックせずに自動リフレッシュを開始できます。ペシミスティック行ロックでは、行セットのリフレッシュは妨げられ、行セットに保留中のトランザクションがある場合(たとえば、ユーザーが新しい行を追加中の場合)は例外がスローされます。アプリケーション・モジュール構成でオプティミスティック行ロックを確実に使用するには、adf-config.xml概要エディタの「ビジネス・コンポーネント」ページを開き、「ロック・モード」(jbo.locking.modeプロパティに対応)がoptimisticに設定されていることを確認します(「Fusion Webアプリケーションがオプティミスティック・ロックを使用していることを確認する方法」を参照。)
始める前に:
LOV有効属性に関する知識が役立つ場合があります。「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
問合せ結果変更通知に問合せを登録するための問合せ定義要件について理解しておくことが役立つ場合があります。『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』の「連続問合せ通知の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要もあります。
「エンティティ・オブジェクトまたはビュー・オブジェクトのビュー・アクセッサの作成方法」の説明に従って、ビュー・アクセッサを作成します。
問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』の「連続問合せ通知の使用」を参照してください。
データ変更通知を受け取るビュー・オブジェクトを登録するには:
ビュー・オブジェクト属性に作成したLOVをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。
Oracle ADFモデル・テスターでは、「値リスト」ダイアログの「UIヒント」ページで選択可能な2つのコンポーネント・タイプのいずれかを使用して、参照するビュー・オブジェクト・インスタンスについてLOVが有効な属性が表示されます。現時点では、選択リストのコンポーネント・タイプと値リストのある入力テキストのコンポーネント・タイプのみがサポートされています。それ以外の場合は、Oracle ADFモデル・テスターによってデフォルトの選択リストのタイプが使用され、LOV有効属性が表示されます。
始める前に:
LOV有効属性に関する知識が役立つ場合があります。詳細は、「ビュー・オブジェクト属性の値リスト(LOV)での作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
Oracle ADFモデル・テスターを使用してLOVをテストするには:
図5-39 Oracle ADFモデル・テスター内のLOV有効属性の表示
ビュー・オブジェクト属性に対してLOVを定義する場合、ビュー・オブジェクト・メタデータにより、次のように追加情報が定義されます(CustomerVO.SalesRepId属性に関する次の例を参照)。
<ViewAttribute>要素では、属性に名前を付けてLOV動作を定義するリスト・バインディング要素を指し、Webページに表示するコンポーネント・タイプを指定します。たとえば、LOV有効属性のSalesRepIdは、LOV_SalesRepIdという名前のリスト・バインディングを指し、LOVデータを表示するリスト(input_text_lov)を使用してCONTROLTYPE入力テキスト・フィールドを定義します。
ユーザー・インタフェース・デザイナで「データ・コントロール」パネルを使用してWebページを作成する場合、JDeveloperによってWebページに追加されるコンポーネントは、<CONTROLTYPE Value="namedType"/>定義によって決定されます。データ・モデル・プロジェクトのコンポーネント・タイプ定義とWebページに表示されるコンポーネント・タイプが一致しない場合は、ランタイム例外が発生します。詳細は、「実行時に行われる処理: LOVでリスト・データソースを問い合わせる方法」を参照してください。
<ListBinding>要素では、LOVの動作を定義します。また、LOV有効属性のデータソースにアクセスするためのビュー・アクセッサも指定します。ビュー・アクセッサとは、データソース・ビュー・オブジェクトの行セットから可能な値のリストを取得するためのADFビジネス・コンポーネントのメカニズムです。たとえば、ListVOName="EmpVO1"は、ビュー・オブジェクトEmpVOにアクセスするEmpVO1ビュー・アクセッサを指します。
<ListBinding>要素では、リスト・データソース属性をLOV有効属性にマップします。たとえば、ListAttrNames項目のIdは、LOV有効属性SalesRepIdにマップされます。
<ListBinding>要素では、現在行から表示する属性を1つ以上指定し、選択リスト・タイプのコンポーネントに固有のオプションも指定します。たとえば、ListDisplayAttrNames項目のFirstNameとLastNameは、LOV有効属性SalesRepIdによって表示される追加の属性です。この例では、NullValueFlagのnone値は、リストから空白項目を選択できないことを意味します。
<ViewAttribute
Name="SalesRepId"
LOVName="LOV_SalesRepId"
PrecisionRule="true"
EntityAttrName="SalesRepId"
EntityUsage="CustomerEO"
AliasName="SALES_REP_ID">
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="oracle.summit.model.views.CustomerVO.SalesRepId_LABEL"/>
<CONTROLTYPE
Value="input_text_lov"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
. . .
<ListBinding
Name="LOV_SalesRepId"
ListVOName="EmpVO1"
ListRangeSize="10"
NullValueFlag="none"
MRUCount="0">
<AttrArray Name="AttrNames">
<Item Value="SalesRepId"/>
</AttrArray>
<AttrArray Name="ListAttrNames">
<Item Value="Id"/>
</AttrArray>
<AttrArray Name="ListDisplayAttrNames">
<Item Value="Id"/>
<Item Value="FirstName"/>
<Item Value="LastName"/>
</AttrArray>
<DisplayCriteria
Hint="hide"/>
</ListBinding>
. . .
<ViewAccessor
Name="EmpVO1"
ViewObjectName="oracle.summit.model.views.EmpVO"
OrderBy="EmpEO.LAST_NAME">
<ViewCriteriaUsage
Name="FilterByTitleIdVC"
FullName="oracle.summit.model.views.EmpVO.FilterByTitleIdVC"/>
<ParameterMap>
<PIMap Variable="TitleIdBind">
<TransientExpression><![CDATA[2]]></TransientExpression>
</PIMap>
</ParameterMap>
</ViewAccessor>
ADFビジネス・コンポーネント・ランタイムにより、ビュー行およびエンティティ・オブジェクトの属性セッターにビュー・アクセッサが追加され、LOV有効属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。データ・バインドされたリスト・コンポーネントのデフォルトのAutoSubmitプロパティ設定はfalseで、エンド・ユーザーが値を選択した場合にのみブラウザでサーバーとのラウンドトリップが行われるようになっています。ラウンドトリップの結果、ADFモデル・レイヤー内の同じLOV有効属性から派生したすべてのリスト・バインディングが更新され、ユーザー・インタフェースの対応するリスト・コンポーネントにエンド・ユーザーの選択が反映されます。
LOV機能によりフェッチされるデータ・オブジェクト数は、部分的には、ビュー・オブジェクトの概要エディタの属性に表示される「値リストの編集」ダイアログで指定される、LOV有効属性のリスト・バインディング定義のListRangeSize設定で決定されます。デフォルトで、LOV問合せでは、すべてのリスト・コンポーネント・タイプ(LOVタイプと非LOVタイプのリスト・コンポーネントを含む)でレコードが打ち切られることなくフェッチされます。ListRangeSizeで指定されるデフォルト値-1は、ユーザーがデータ・ソースからすべてのデータ・オブジェクトを表示できることを意味します。ただし、フェッチされたレコードの数が多く、リスト・コンポーネントでのレコード表示で一部の値を切り捨てたい場合は、ListRangeSizeでフェッチするレコード数の値を指定します。ListRangeSize値は、2つのLOVタイプのコンポーネントに対して表示される参照ダイアログでエンド・ユーザーが検索できるレコードに影響を与えません。各リスト・コンポーネントによる値の表示方法の詳細は、「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」を参照してください。
<ListBinding>要素のメタデータ定義でListRangeSize値を変更することもできますが、値を別のレコード数(ListRangeSize="5"など)に設定すると、必要な選択項目が表示されなくなる可能性が高くなります。かわりに、値を-1 (リスト・コンポーネントのデフォルト)にすると、リスト・コンポーネントが表示するレコード数に制限は設定されず、ユーザーは完全な値セットにアクセスできます。
パフォーマンスのヒント:
値セットを制限するために、LOV表示では、「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」で説明するように、ビュー・アクセッサを使用してLOVバインディングをフィルタリングします。また、選択リストを表示するコンポーネント・タイプの場合は、「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」で説明するように、「最近使用されたカウント」設定を変更して、ユーザーが前に選択した項目のリスト表示を制限できます。
ビュー・オブジェクトのCONTROLTYPE定義に一致しないLOV有効属性のUIコンポーネントがWebページに表示されると、ランタイム例外が発生します。ユーザー・インタフェース・デザイナで、「データ・コントロール」パネルを使用してJDeveloperのページを作成すると、「リスト・タイプUIヒント」ダイアログで、ビュー・オブジェクトのLOV有効属性に対して「デフォルトのリスト・タイプ」で指定したリスト・コンポーネントが自動的に挿入されます。ただし、Webページの作成後にユーザー・インタフェース・デザイナでリスト・タイプを変更した場合は、「リスト・タイプUIヒント」ダイアログで選択した項目が一致するように編集する必要があります。
ビュー・オブジェクトの属性に定義するLOVについていくつか知っておく必要があります。たとえば、既存のビュー・オブジェクトの展開による、親ビュー・オブジェクトから子ビュー・オブジェクトへのLOVが有効な属性を伝播する方法や、LOVのかわりにバリデータを使用して値リストを管理するケースなどがあります。
ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。
また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクトを定義して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、「バインド変数の使用」を参照してください。
ビュー・オブジェクトにLOVが有効な属性を作成した場合、リスト・バリデータを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。リスト検証は、単純な静的データ、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、キーの存在検証を使用します。ADF Business Componentsでの宣言的な検証の詳細は、「検証とビジネス・ルールの宣言的な定義」を参照してください。
ADFビュー・オブジェクトの属性にUIヒントを定義して、エンド・ユーザーに状況依存UI情報を表示します。
ADFビジネス・コンポーネントの組込み機能の1つに、ビュー・オブジェクトとビュー・オブジェクトの属性についてのUIヒントを定義する機能があります。UIヒントは、ロケールに依存した一貫性のある方法で問合せ情報を自動表示する際にビュー・レイヤーで使用される設定です。たとえば、Webページでは、bindingsネーム・スペースで定義されADFバインディング・インスタンス名に対して指定されたEL式ユーティリティ・メソッドを入力することによりUIヒント値にUI開発者はアクセスできます。
JDeveloperでは、多言語アプリケーションを容易にローカライズできるリソース・バンドル・ファイルにヒントを格納します。
ビュー・オブジェクトのUIヒントを作成するには、「アプリケーション」ウィンドウからアクセスできる、ビュー・オブジェクトの概要エディタを使用します。また、属性の「プロパティ」ウィンドウを表示してUIヒントを表示および編集することもできます。
始める前に:
属性UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
UIヒントを使用してビュー・オブジェクト属性をカスタマイズするには:
注意:
Javaで定義される数値および日付のフォーマット・マスクの標準セットは、OracleデータベースのSQLおよびPL/SQL言語によって使用されるものとは異なります。詳細は、java.text.DecimalFormatおよびjava.text.SimpleDateFormatクラスのJavadocを参照してください。
ビュー・オブジェクトのUIヒントを作成するには、「アプリケーション」ウィンドウからアクセスできる、ビュー・オブジェクトの概要エディタを使用します。ビュー・オブジェクトで表示する「プロパティ」ウィンドウを使用しても、複数の追加のUIヒントを表示および編集できます。
始める前に:
UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
UIヒントを使用してビュー・オブジェクトをカスタマイズするには:
UI開発者は、EL式を使用してUIヒントにアクセスし、Webページにデータとしてヒント値を表示できます。UIヒントには、データバインドされたコンポーネントをWebページにドロップした後に作成するADFバインディング・インスタンスを通じてアクセスできます。
ビュー・オブジェクト・ヒントの場合は、UI開発者はそのビュー・オブジェクトに対して定義済のコレクション・バインディングを介してアクセスします。たとえば、次のようなビュー・オブジェクトUIヒントを構成したとします。
OrdersVOビュー・オブジェクト「表示名」ヒント = Order
OrdersVOビュー・オブジェクト「表示名(複数)」ヒント = Orders
OrdersVOビュー・オブジェクト「説明」ヒント = customer orders
UI開発者は、これらのヒントを活用するヘッダーを次のように表示できます。
Showing customer orders number 10 of 51 Orders.
次の例は、前に示したテキストを生成するEL式を示しています。このEL式では、コレクション・バインディングOrdersVO1によってビュー・オブジェクト・ヒントへのアクセスが提供されます。EL式ユーティリティ・メソッド名は、ビュー・オブジェクトXML定義ファイルのUIヒントで定義されているプロパティ名と一致します。たとえば、「表示名(複数)」ヒントを定義するビュー・オブジェクトのプロパティ名labelPluralは、式bindings.OrdersVO1.hints.labelPluralで使用されているユーティリティ・メソッド名と一致します。
<af:panelHeader id="ph1"
text="Showing #{bindings.OrdersVO1.hints.description} number
#{bindings.OrdersVO1.Orderno.inputValue} of
#{bindings.OrdersVO1.estimatedRowCount}
#{bindings.OrdersVO1.hints.labelPlural}.">
ビュー・オブジェクトまたはビュー・オブジェクトの属性に属性UIヒントを定義すると、属性UIヒントはデフォルトでリソース・バンドル・ファイルに格納されます。これにより、定義したヒントを生成されたユーザー・インタフェースのフォームや表に合わせてローカライズできます。
JDeveloperで使用されるリソース・バンドル・ファイルのタイプとファイルの粒度は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページで決定されます。デフォルトでは、このオプションは「プロパティ・バンドル」に設定され、データ・モデル・プロジェクト全体に対して1つの.propertiesファイルが生成されます。たとえば、Modelプロジェクトでビュー・オブジェクトのUIヒントを定義すると、パッケージには、ModelBundle.propertiesというバンドル・ファイルがJDeveloperにより作成されます。
また、「プロジェクト・プロパティ」ダイアログでオプションを選択して、ファイルごとに1つのリソース・バンドルを生成する場合は、「アプリケーション」ウィンドウでオブジェクトを選択し、「構造」ウィンドウの対応「ソース」ノードを参照して、ビュー・オブジェクトのメッセージ・バンドル・ファイルを検証できます。「構造」ウィンドウには、「アプリケーション」ウィンドウで選択したコンポーネントの実装ファイルが表示されます。図5-40に示すように、「アプリケーション」ウィンドウで目的のビュー・オブジェクトの親パッケージを開くと、ビュー・オブジェクトのリソース・バンドル・ファイルを検査できます。
図5-40 「アプリケーション」ウィンドウのリソース・バンドル・ファイル
選択可能なリソース・バンドル・オプションの詳細は、「メッセージ・バンドル・オプションの設定方法」を参照してください。
次の例は、UIヒントの情報が表示されたメッセージ・バンドル・ファイルのサンプルを示しています。各String配列の最初のエントリはメッセージ・キーで、2番目のエントリはこのキーに対応するロケール固有のString値です。
oracle.summit.model.views.CustomerVO.Id_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter
oracle.summit.model.views.CustomerVO.Id_FMT_FORMAT=00000
oracle.summit.model.views.CustomerVO.Id_LABEL=Id
oracle.summit.model.views.CustomerVO.Email_LABEL=Email Address
oracle.summit.model.views.CustomerVO.LastName_LABEL=Surname
oracle.summit.model.views.CustomerVO.FirstName_LABEL=Given Name
ビュー・オブジェクトにより定義する属性をグループ化する方法がUIカテゴリにより実現されます。作成したカテゴリ名は、表示用に属性をグループ化するために動的レンダリング・ユーザー・インタフェースで使用される識別子です。ユーザー・インタフェースでは、同じカテゴリの他の属性を使用して属性がレンダリングされます。カテゴリ・ヒントを使用すると、ユーザー・インタフェースによって、ビュー・オブジェクト属性の大量のリストをカテゴリで関連付けられた小さいグループに分割することが容易になります。
さらに、ユーザー・インタフェースでそのカテゴリ内で属性値がレンダリングされる方法を並べ替えるフィールド順ヒントを指定できます。たとえば、ビュー・オブジェクトで4つの属性(attributeA、attributeB、attributeCおよびattributeD)を定義し、属性ごとにそれぞれフィールド順を4、3、2および1に指定した場合、ユーザー・インタフェースでカテゴリがレンダリングされると、そのカテゴリの属性は、attributeD、attributeC、attributeBおよびattributeAの順序で表示されます。
注意:
ビュー・オブジェクトの概要エディタにある「UIカテゴリ」ページを使用して、作成したカテゴリ内にリストされる属性の順序を変更します。JDeveloperによって自動的に割り当てられ、リストの順序に基づいた属性のフィールド順値が維持されるので、数値を編集してフィールド順ヒントを定義する必要はありません。
カテゴリとフィールド順のヒントは、動的フォームと検索フォームを含めて、属性を表示するすべての動的レンダリング・ユーザー・インタフェースで使用されます。
動的フォームの場合、各カテゴリの属性は別のタブに表示されます。
検索フォームの場合、フォームの個別ビュー基準の順序は、ビュー基準アイテムのベースとなる属性に割り当てられたフィールド順とカテゴリにより決まります。
ビュー・オブジェクトの属性に対してUIカテゴリを作成するには、「アプリケーション」ウィンドウからアクセスできるビュー・オブジェクトの概要エディタを使用します。図5-41に示すように、「UIカテゴリ」ページを使用して、ビュー・オブジェクト全体でカテゴリの作成や編集ができます。
「UIカテゴリ」ページに作成されたカテゴリにビュー・オブジェクト属性を割り当てると、カテゴリ・リストに表示された属性の順序によりその数値フィールド順が決まります。「UIカテゴリ」ページにより、属性をリスト内でドラッグ・アンド・ドロップすると、カテゴリに割り当てた属性のフィールド順序を変更できます。属性をカテゴリ・リストにドラッグ・アンド・ドロップすると、JDeveloperにより自動的にフィールド順序ヒントの適切な順序がカテゴリ内で維持され、個々の属性のフィールド順序値が「UIカテゴリ」ページの「属性UIヒント」リストに表示されます。「UIカテゴリ」ページに表示されるその他の属性レベルUIヒントは、ビュー・オブジェクト・エディタの「属性」ページの「UIヒント」タブの設定と同期されます。
各カテゴリにはラベルとツールチップ・テキストの文字列リソースを持たせることができ、カテゴリがレンダリングされる際にユーザー・インタフェースによって使用できます。エントリ格納用に選択したリソース・バンドル・ファイルにあるこれらのリソース文字列をローカライズできます。たとえば、図5-42では、属性LastNameとCreditRatingIdが、Sales Rep NameとCredit Ratingというラベルで、Personal Informationというラベルのカテゴリに示されています。
始める前に:
UIヒントの知識があると役立ちます。詳細は、「ビュー・オブジェクトのUIヒントの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、「ビュー・オブジェクトの追加機能」を参照してください。
次のタスクを完了する必要があります。
「エンティティ・ベースのビュー・オブジェクトの作成方法」および「カスタムSQLモード・ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。
オプションで、「属性固有のUIヒントの追加方法」の説明に従い、属性UIヒントを指定します。属性UIヒントは、ビュー・オブジェクト・エディタの「UIカテゴリ」ページで、読取り専用として表示されます。
ユーザー・インタフェースのカテゴリを作成し、表示用に属性の順序を変更するには:
ビュー・オブジェクトの属性UIカテゴリを定義すると、JDeveloperによりビュー・オブジェクトのXMLドキュメント・ファイルが更新されます。JDeveloperは、CATEGORYとFIELDORDERのUIヒントを<ViewAttribute>要素の<SchemaBasedProperties>要素に追加します。カテゴリの定義は新しい<Category>要素に表示されます。
次の例のメタデータは、CustomerId属性のCATEGORYヒントがAccountInformationカテゴリを参照し、FirstName属性のCATEGORYヒントがUserInformationカテゴリを参照していることを示しています。両方のカテゴリの定義は<Category>要素に表示されます。属性ごとのFIELDORDERヒントにより数値を指定し、概要エディタで作成したUIカテゴリ・リストにおける属性の順序に基づいてJDeveloperによって割り当てられて維持されます。次の例に示すように、FIELDORDERヒントは10進数値です。10進数値がJDeveloperにより使用され、新しい属性をカテゴリに挿入でき、その際JDeveloperで既存の属性値をすべて変更する必要がなく、適切な順序を維持できます。
カテゴリで最初の属性におけるデフォルトのフィールド順値はJDeveloperにより0.0に割り当てられます。フィールド順の値は、カテゴリ・リストをソートするための数値に変更できますが、インデックスではありません。フィールド順の数値は連続している必要はありません。
<Category
Name="AccountInformation">
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="CUSTOMER_DETAILS"/>
<TOOLTIP
ResId="AccountInformation_TOOLTIP"/>
</SchemaBasedProperties>
</Properties>
</Category>
<Category
Name="UserInformation">
<Properties>
<SchemaBasedProperties>
<TOOLTIP
ResId="UserInformation_TOOLTIP"/>
<LABEL
ResId="CUSTOMER_DETAILS"/>
</SchemaBasedProperties>
</Properties>
</Category>
...
<ViewAttribute
Name="CustomerId"
IsNotNull="true"
PrecisionRule="true"
EntityAttrName="CustomerId"
EntityUsage="CustomerEO"
AliasName="CUSTOMER_ID">
<Data>
<Property
Name="OWNER_SCOPE"
Value="INSTANCE"/>
...
</Data>
<Properties>
<SchemaBasedProperties>
<CATEGORY
Value="AccountInformation"/>
<FIELDORDER
Value="0.0"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
...
<ViewAttribute
Name="FirstName"
PrecisionRule="true"
EntityAttrName="FirstName"
EntityUsage="CustomerEO"
AliasName="FIRST_NAME">
<Data>
<Property
Name="OWNER_SCOPE"
Value="INSTANCE"/>
...
</Data>
<Properties>
<SchemaBasedProperties>
<CATEGORY
Value="UserInformation"/>
<FIELDORDER
Value="0.0"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
ADFビジネス・コンポーネントを使用して作成されたアプリケーションのモデル・レイヤーを国際化するには、各コンポーネントのリソース・バンドル・ファイルの翻訳バージョンを作成する必要があります。たとえば、QueryDataWithViewObjectsBundle.propertiesファイルのイタリア語バージョンはQueryDataWithViewObjectsBundle_it.propertiesという名前のファイルになり、より限定されたスイス・イタリア語バージョンはQueryDataWithViewObjectsBundle_it_ch.propertiesという名前のファイルになります。
リソース・バンドル・ファイルには、ローカライズが必要なメッセージ・キーのエントリと、そのローカライズ済の翻訳が含まれています。たとえば、イタリア語ロケールに対する数値フォーマット・マスクの翻訳が不要であったと仮定すると、QueryDataWithViewoObjectsビュー・オブジェクトのメッセージ・キーのイタリア語バージョンは、次の例のようになります。実行時には、現在のユーザーのロケール設定に基づいてリソース・バンドルが自動的に使用されます。
oracle.summit.model.views.CustomerVO.Id_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter
oracle.summit.model.views.CustomerVO.Id_FMT_FORMAT=00000
oracle.summit.model.views.CustomerVO.Id_LABEL=Codice Utente
oracle.summit.model.views.CustomerVO.Email_LABEL=Indirizzo Email
oracle.summit.model.views.CustomerVO.LastName_LABEL=Cognome
oracle.summit.model.views.CustomerVO.FirstName_LABEL=Nome
モデル・プロジェクトの各リソース・バンドルは、Fusion Webアプリケーションの国際化の1つの特徴の要因になります。特定のロケールに対応した国際化では、ユーザー・インタフェースのADF Facesページのローカライズも必要になります。ADF Facesページのローカライズ方法の詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「ページの国際化およびローカライズ」を参照してください。
