| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章では、ADFビュー・オブジェクトを作成して、Oracle Application Development Framework (Oracle ADF)アプリケーションで使用するためにデータの結合、フィルタ、ソートおよび集約を行うSQL問合せを作成する方法について説明します。SQL派生属性をデータベース表の列や他の静的データソース(フラット・ファイルなど)にビュー・オブジェクトによりマップする方法も説明します。
この章の内容は次のとおりです。
ビュー・オブジェクトは、SQL問合せをカプセル化しその結果の作業を簡略化するOracle Application Development Framework (Oracle ADF)コンポーネントです。ADFビジネス・コンポーネント・プロジェクトで作成できるビュー・オブジェクトにはいくつかのタイプがあります。
データの更新が必要ない場合の読取り専用ビュー・オブジェクト(エンティティ・ベースの場合もあり)
データの更新を実行する場合のエンティティ・ベースのビュー・オブジェクト
ビュー・オブジェクト自体によって定義されるデータに対する静的データ・ビュー・オブジェクト
プログラムにより移入されたビュー・オブジェクト(詳細は第39章「ビュー・オブジェクトの高度な手法」を参照)
エンティティ・ベースのビュー・オブジェクトでは、その属性が1つ以上の既存エンティティ・オブジェクトの属性とマップされるビュー・オブジェクトを作成する際に、更新可能な行をサポートするように構成できます。マッピングされたエンティティ・オブジェクトは、ビュー・オブジェクト定義にエンティティ・オブジェクトの慣用名として保存されます。このように、エンティティ・ベースのビュー・オブジェクトでは、エンティティ・オブジェクトと自動的に連携することにより、完全に更新可能なデータ・モデルが実現します。エンティティ・ベースのビュー・オブジェクトでは、クライアント側のタスクに必要なデータのみを問い合せ、マップされたエンティティ・オブジェクトを活用してビュー行に対する変更を自動的に検証および保存します。読取り専用のビュー・オブジェクトと同様に、エンティティ・ベースのビュー・オブジェクトは、SQL問合せをカプセル化し、ビュー・リンクを使用してマスター/ディテール階層にリンクしたり、アプリケーション・モジュールのデータ・モデルで使用したりできます。
エンティティ・オブジェクトの慣用名が定義されていないビュー・オブジェクトは常に読取り専用です。これらはエンティティから導出されたデフォルト値は使用されず、保留中の変更、および更新された参照情報は反映されません。エンティティ・ベースのビュー・オブジェクトとは異なり、読取り専用ビュー・オブジェクトでは、SQL問合せ言語を使用して問合せを記述する必要があります。一方、エンティティ・ベースのビュー・オブジェクトでは、ビュー・オブジェクトの作成ウィザードおよび概要エディタを使用してSQL問合せを宣言的に構成できるため、問合せの記述が容易です。そのため、ほとんどの場合は、データの読取りにのみ使用するビュー・オブジェクトを作成するときでも、エンティティにマップされた、更新不可能なビュー・オブジェクトを作成することをお薦めします。また、設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、実行時にSQL文を動的に生成するエンティティにマップされたビュー・オブジェクトを作成することもできます。
ただし、状況によっては、SQLベースの検証、UNION、GROUP BY問合せなど、エンティティにマップされていないビュー・オブジェクトを作成してデータの読取りに使用する方が適切な場合もあります。
この章では、図5-1に示すようなビュー・オブジェクトの概念についてわかりやすく説明します。
SQL問合せを作成する(明示的または宣言的に定義する)ことによりビュー・オブジェクトを定義します。
ビュー・オブジェクト・インスタンスは、問合せのデータベース・トランザクションを提供するアプリケーション・モジュールと関連して使用します。
ビュー・オブジェクトを1つ以上の他のビュー・オブジェクトにリンクして、マスター/ディテール階層を作成できます。
実行時には、ビュー・オブジェクトにより問合せが実行され、(RowSetオブジェクトで表される)行セットが生成されます。
各行は、対応する行キーによって識別されます。
行セット・イテレータを使用して、行セットの行を反復します。
一連のQuery-By-Example基準行を適用すると、ビュー・オブジェクトにより生成される行セットをフィルタリングできます。
ビュー・オブジェクトに基礎となるエンティティ・オブジェクトの慣用名が1つ以上ある場合、新しい行の作成や、問合せ結果の行の変更または削除が可能です。エンティティ・ベースのビュー・オブジェクトは基礎となるエンティティ・オブジェクトと連携して、ビジネス・ルールを適用し、データベースに対する変更を永続的に保存します。また、エンティティ・ベースのビュー・オブジェクトは、読取り専用ビュー・オブジェクトにはない次のような機能を備えています。
エンティティで管理されるキャッシュ内の変更(更新、挿入、削除)は、ビュー・オブジェクトの実行後も保持されます。
同じトランザクションの他のビュー・オブジェクトを介して行われた、関連するエンティティ・オブジェクト属性に対する変更は即時に反映されます。
新しい行の属性値は、基礎となるエンティティ・オブジェクト属性の値で初期化されます。
外部キー属性値が変更されると、参照情報が更新されます。
行(エンティティ)レベルの検証がサポートされています。
検証、ロック、順序付けられた更新などのコンポジット機能がサポートされています。
有効日指定、更新識別子およびビジネス・イベントがサポートされています。
この章では、アプリケーション・モジュールのデータ・モデル内のエンティティ・ベースのビュー・オブジェクトのインスタンスを使用して、再使用可能なビジネス・ドメイン・オブジェクトが持つ明確なオブジェクト指向のカプセル化能力にSQLの完全なデータ形成能力を組み合せることにより、クライアントがビジネス・ドメイン・レイヤー情報を検索、更新、挿入および削除できるようにする方法について説明します。また、これらすべての作業についてコード行は必要ありません。この章では、図5-2に示すように、エンティティ・ベースのビュー・オブジェクトの概念についてわかりやすく説明します。
更新可能なビュー・オブジェクトは、1つ以上のエンティティ・オブジェクトの属性を参照して定義します。
関連付けられた複数のエンティティ・オブジェクトを使用することにより、参照情報の操作を簡略化できます。
基礎となるエンティティ・アソシエーションに基づいてビュー・リンクを定義できます。
エンティティ・ベースのビュー・オブジェクトは、トランザクションを提供するアプリケーション・モジュールとの関連で使用します。
実行時に、ビュー行は、属性の格納および検証を基礎となるエンティティ・オブジェクトに委譲します。
ビュー・オブジェクトは、データソースからデータを取得する手段を備えています。ほとんどの場合、データベースがデータソースとなり、データの取得にはSQL問合せが使用されます。ADFビジネス・コンポーネントでは、JDBCと連携することによってこの問合せをデータベースに渡し、結果を取得できます。
ビュー・オブジェクトでSQL問合せが使用される場合、問合せ列がそのビュー・オブジェクトのビュー・オブジェクト属性にマップされます。これらの属性の定義は、ビュー・オブジェクトのXML定義ファイルに保存され、データ型および精度とスケールの指定など、これらの列の様々なプロパティを反映しています。
|
パフォーマンスに関するヒント: ビュー・オブジェクトに関連付けられた問合せに、実行ごとに変更される値が含まれる場合は、バインド変数を使用します。問合せでバインド変数を使用すると、データベースで問合せを再解析する必要なく、問合せを再実行できます。バインド変数は、ビュー・オブジェクトの概要エディタの「問合せ」ページでビュー・オブジェクトに追加できます。詳細は、5.10項「バインド変数の使用」を参照してください。 |
ビュー・オブジェクトの作成ウィザードでは、既存のエンティティ・オブジェクトの属性にマップされるビュー・オブジェクトもマップされないビュー・オブジェクトも作成できます。エンティティ・ベースのビュー・オブジェクトのみが、マップされたエンティティ・オブジェクトと自動的に連携し、ビジネス・ルールの適用とデータ・モデルの変更の永続的な保存が可能です。また、エンティティ・ベースのビュー・オブジェクトの「更新可能」機能を無効にし、読取り専用データの問合せを完全に宣言的に実行できます。ウィザードまたはエディタのエキスパート・モードを使用してSQL問合せ言語を直接使用することもできますが、この場合、作成したビュー・オブジェクトでは、エンティティ・ベースのビュー・オブジェクトのトランザクション機能はサポートされません。
ビュー・オブジェクト行とエンティティ・オブジェクト行の間の調整には、実行時に若干のオーバーヘッドが生じますが、ビュー・オブジェクト定義を完全に宣言的に維持し、カスタマイズ可能なビュー・オブジェクトをメンテナンスする機能と比較検討してください。エンティティ・オブジェクトでは記述できず、そのためにエキスパート・モードによる編集が必要な問合せには、UNIONやGROUP BY問合せがあります。エキスパート・モード・ベースのビュー・オブジェクトは、ビュー・オブジェクト・ベースのKey Exists Validatorによって使用されるSQLベースの検証問合せでも便利です。本質的に、エキスパート・モードを使用してSQL問合せを定義すると、ビュー・オブジェクトは必ず読取り専用になります。
エンティティ・ベースのビュー・オブジェクトと読取り専用ビュー・オブジェクトの差異の詳細は、5.1.2項「エンティティ・ベースのビュー・オブジェクト固有の実行時機能」を参照してください。
ビュー・オブジェクトの作成では、エンティティ・ベースのビュー・オブジェクトの作成が最も簡単な方法です。これは作成時にSQL文を自分で入力する必要がないため、エキスパート・モードでの読取り専用ビュー・オブジェクトより簡単に作成できます。また、エンティティ・ベースのビュー・オブジェクトの方が、エキスパート・モードのビュー・オブジェクトより非常に多くの実行時機能を備えています。
エンティティ・ベースのビュー・オブジェクトでは、ビュー・オブジェクトとエンティティ・オブジェクトが果す役割が明確に区別されています。
ビュー・オブジェクトは、データ・ソースで、SQLを使用してデータを取得します。
エンティティ・オブジェクトは、データ・シンクで、データの変更を検証および保存します。
ビュー・オブジェクトとエンティティ・オブジェクトの役割は明確に区別されているため、再使用可能なエンティティ・オブジェクトを変更せずに、大量の異なるビュー・オブジェクトを作成することができ、アプリケーションごとのユーザー・インタフェースで求められる方法で、データを計画、フィルタ、結合およびソートできます。実際、エンティティ・オブジェクトのコア・ビジネス・ドメイン・レイヤーを担当する開発チームを、エンド・ユーザー環境のサポートに必要な特定のアプリケーション・モジュールおよびビュー・オブジェクトを担当するチームから完全に独立させることができます。このような関係は、エンティティ・ベースのビュー・オブジェクトによってカプセル化されるメタデータによって実現されます。このメタデータでは、基礎となる1つ以上のエンティティ・オブジェクトの属性に対してSELECTリストの列がどのように関連付けられるかが指定されます。
使用するエンティティ・ベースのビュー・オブジェクトは、複数のデータベース表を基にできます。データベース結合を使用して複数の表をビュー・オブジェクトに追加するには、5.5項「結合問合せ結果での複数表の使用」を参照してください。
エンティティ・ベースのビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能なビュー・オブジェクトの作成ウィザードを使用します。
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。
単一表からエンティティ・ベースのビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ・オブジェクトを介した更新可能アクセス」を有効のままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。
「エンティティ・オブジェクト」ページで、ビュー・オブジェクトでデータを使用するエンティティ・オブジェクトを選択します。「次へ」をクリックします。
このリストのエントリは、ビュー・オブジェクトが使用するエンティティ・オブジェクトを記録するため、エンティティ・オブジェクトの慣用名と呼ばれます。また、ビュー・オブジェクトがこのエンティティの属性を参照するため、各エントリはエンティティ参照とも呼ばれます。表結合を使用してエンティティ・オブジェクトの慣用名を追加で作成する方法の詳細は、5.5項「結合問合せ結果での複数表の使用」を参照してください。
たとえば、図5-3は、PersonEOエンティティ・オブジェクトを「選択済」リストに移動した結果を示しています。
「属性」ページで、各エンティティ・オブジェクトの慣用名から組み込む属性を「使用可能」リストから選択し、「選択済」リストに移動します。「次へ」をクリックします。
たとえば、図5-4は、PersonEOから選択された属性を示しています。
「属性の設定」ページでは、「属性の選択」ドロップダウン・リストを使用してビュー・オブジェクト属性を切り替え、名前や初期設定を変更できます。
属性設定の詳細は、[F1]キーを押すか、「ヘルプ」をクリックしてください。
「問合せ」ページでは、必要に応じてデータのフィルタリングや順序付けを行うためにWHERE句およびORDER BY句を問合せに追加できます。選択したエンティティ属性に基づいて、SELECT文が自動的に生成されます。
「WHERE」フィールドおよび「ORDER BY」フィールドの値には、WHEREキーワードやORDER BYキーワードを含めないでください。これらのキーワードは、実行時に問合せを実行する際に追加されます。
たとえば、図5-5に示すように、データを名、姓および電子メールを基準にして順序付ける場合は、ORDER BY句が指定されます。
目的のビュー・オブジェクトを作成したら、「終了」をクリックします。
基礎となるエンティティ・オブジェクトの すべての属性をクライアントが操作できるようにするには、5.2.1.1項「単一表からのエンティティ・ベースのビュー・オブジェクトの作成」で説明するように、「ビュー・オブジェクトの作成」ウィザードを使用できます。この場合、エンティティ・オブジェクトを選択した後、「属性」ページですべての属性を選択します。ただし、これは頻繁に行う操作であるため、同じ作業をアプリケーション・ナビゲータでより簡単に実行する方法があります。
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。
デフォルトのエンティティ・ベースのビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、エンティティ・オブジェクトを右クリックし、「新規デフォルト・ビュー・オブジェクト」を選択します。
「デフォルト・ビュー・オブジェクトを作成」ダイアログで、新しいビュー・オブジェクトのパッケージ名およびコンポーネント名を指定します。
「デフォルト・ビュー・オブジェクトを作成」ダイアログでは、「参照」をクリックして、既存のパッケージのリストからパッケージ名を選択できます。たとえば、図5-6では、「参照」をクリックして、StoreFrontModuleアプリケーションのStoreFrontServiceプロジェクトのクラスパス上にあるoracle.fodemo.storefront.entiesパッケージを特定します。
作成される新しいエンティティ・ベースのビュー・オブジェクトは、ビュー・オブジェクトの作成ウィザードで作成できるものと同一のものです。デフォルトでは、このビュー・オブジェクトには、アプリケーション・ナビゲータで選択したエンティティ・オブジェクトを参照する単一のエンティティ・オブジェクトの慣用名があり、そのすべての属性が含まれます。最初は、このビュー・オブジェクトにはWHERE句もORDER BY句もないため、次のビュー・オブジェクトの操作には概要エディタを使用する必要があります。
不要な属性の削除
WHERE句を使用した選択内容の限定
ORDER BY句による結果の順序付け
ビュー・オブジェクトのプロパティのカスタマイズ
ビュー・オブジェクトを作成する際、JDeveloperでビュー・オブジェクトの宣言的設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリに保存されます。たとえば、Ordersというビュー・オブジェクトがqueriesパッケージに追加された場合は、プロジェクトのソース・パスに./queries/Orders.xmlというXMLファイルが作成されます。
ビュー・オブジェクト設定を表示するには、アプリケーション・ナビゲータで目的のビュー・オブジェクトを展開し、展開されたビュー・オブジェクトのXMLファイルを選択して、構造ウィンドウを開きます。構造ウィンドウは、SQL問合せ、エンティティ・オブジェクトの慣用名および各属性のプロパティなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースへ移動」を選択します。
|
注意: ADFビジネス・コンポーネントに対してデフォルトのJavaクラスを生成するようにJDeveloperの設定を構成すると、ウィザードにより、オプションのカスタム・ビュー・オブジェクト・クラス( |
図5-7は、エンティティ・ベースのビュー・オブジェクトOrderItemsInfoVOと、この問合せ文で参照される3つのエンティティ・オブジェクトの慣用名を示しています。点線は、問合せのSELECTリストの列を、ビュー・オブジェクトで使用されるエンティティ・オブジェクトの属性にマップする、エンティティ・ベースのビュー・オブジェクトのXMLコンポーネント定義で取得されるメタデータを表します。エンティティ・ベースのビュー・オブジェクトの問合せにより、プライマリ・エンティティ・オブジェクトの慣用名(OrderItemEO)のデータと、セカンダリの参照エンティティ・オブジェクトの慣用名(ProductBaseEOおよびSupplierEO)のデータが結合されます。
SQL文を完全に制御する必要がある場合は、ビュー・オブジェクトの作成ウィザードでビュー・オブジェクトを読取り専用にするよう指定できます。この場合、更新不可能なエンティティ・ベースのビュー・オブジェクトを定義するために宣言的な機能を使用する利点はありません。ただし、一部の状況では、エキスパート・モードを使用して読取り専用ビュー・オブジェクトを作成する方が適切な場合があります。作成した読取り専用ビュー・オブジェクトは、主に、UNIONまたはGROUP BY問合せを記述する必要がある場合に役立ちます。また、キー属性をマークしている場合は、ビュー・オブジェクト・ベースのKey Exists Validatorで使用されるSQLベースの検証問合せを作成する必要がある場合に、読取り専用ビュー・オブジェクトを使用できます。
|
ベスト・プラクティス: エンティティ・ベースのビュー・オブジェクトとは異なり、エキスパート・モードで作成する読取り専用ビュー・オブジェクトはデフォルトではキー属性を定義しません。キー属性を定義せずに読取り専用オブジェクトを作成することはできますが、エキスパート・モードでは問合せた表の主キーに対応する属性を選択し、キー属性としてマーキングしておくのがベスト・プラクティスです。キー属性の存在により、実行時の行セット・ナビゲーションの正しい動作が保証されます。たとえば、ユーザー・インタフェース開発者は、読取り専用ビュー・オブジェクト・コレクションに基づいてLOVコンポーネントを作成することがあります。行キー値を指定するキー属性がなければ、LOVが正しく機能せず、実行時エラーが発生することがあります。 |
更新不可能な、厳密な意味での読取り専用ビュー・オブジェクトとして定義したエンティティ・ベースのビュー・オブジェクトを使用する場合のトレードオフの詳細は、39.2.2項「読取り専用データへのエンティティ・ベースのビュー・オブジェクトの使用の検討」を参照してください。
読取り専用ビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能なビュー・オブジェクトの作成ウィザードを使用します。
読取り専用ビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「SQL問合せによる読取り専用アクセス」を選択し、このビュー・オブジェクトが読取り専用アクセスでデータを管理することを示します。「次へ」をクリックします。
「問合せ」ページでは、次のいずれかの操作を行います。
有効なSQL文を「問合せ文」ボックスに貼り付けます。問合せ文では、WHERE句とOrder By句を使用できます。たとえば、図5-8は、WHERE句とOrder By句を使用して、アプリケーションで使用される言語の国コードのリストを問い合せる文を示しています。
「クエリー・ビルダー」をクリックして「SQL文」ダイアログを開き、そこで対話型のクエリー・ビルダーを使用します。
|
注意: 「問合せ」ページではなく、「エンティティ・オブジェクト」ページが表示された場合は、ウィザードのステップ1に戻り、「読取り専用アクセス」を選択してあることを確認してください。 |
問合せ文を入力または作成した後、「次へ」をクリックします。
「バインド変数」ページで、次のいずれかを実行します。
問合せがバインド変数を参照しない場合は、「次へ」をクリックして、ステップ6を省略します。
バインド変数を追加し、それを問合せの中で使用する場合は、5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」を参照してください。
「属性の設定」ページでは、「属性の選択」ドロップダウンを使用して、問合せ表の主キーに対応する属性を選択し、「キー属性 」チェックボックスを有効にします。
読取り専用のビュー・オブジェクトはエンティティ・オブジェクトには基づいていないため、ビュー・オブジェクトの作成ウィザードはデフォルトではキー属性を定義しません。キー属性を定義しなかった場合、読取り専用ビュー・オブジェクト・コレクションに基づくデータを持つADF Facesコンポーネントが、実行時に予期しない動作をするこことがあります。読取り専用ビュー・オブジェクトの場合は、図5-9に示すように、キー属性を定義します。
「属性マッピング」ページで「終了」をクリックします。
|
注意: ADFビジネス・コンポーネントウィザードおよびエディタのデフォルトの規則では、属性名に頭文字が大文字表記の名前を使用します。これは、最初の文字を大文字で表し、名前が複数の単語で構成されている場合には、読みやすくするために名前の途中でも大文字を使用する表記法です。 |
ビュー・オブジェクトを作成する際、JDeveloperでは最初にSELECTリストの列から次を推測する問合せが解析されます。
Javaに適したビュー属性名(COUNTRY_NAMEではなくCountryNameなど)
デフォルトでは、SELECTリスト列名に対応する、Javaに適したビュー・オブジェクト属性名がウィザードによって作成されます(図5-10を参照)。
ビュー・オブジェクト属性の名前を使用して、ビュー・オブジェクトの名前別結果セットの任意の行のデータにアクセスする方法は、6.4項「ビュー・オブジェクト・インスタンスのプログラムによるテスト」を参照してください。
各属性のSQLおよびJavaデータ型
SOME_COLUMN_NAMEのように下線で区切られた列名の各部分は、SomeColumnNameのような単語の最初を大文字にした属性名に変えられます。ビュー・オブジェクト属性名はSELECTリストの基礎となる問合せ列に対応しますが、ビュー・オブジェクト・レベルでの属性名とは必ずしも一致しません。
|
ヒント: ビュー・オブジェクト属性の名前は、基礎となる問合せを変更しなくても、より適切な名前に変更できます。 |
次に、JDeveloperでビュー・オブジェクトの宣言設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に格納されます。たとえば、lookupsパッケージのCountriesVOという名前のビュー・オブジェクトに対しては、プロジェクトのソース・パスに./lookups/CountriesVO.xmlというXMLファイルが作成されます。
ビュー・オブジェクト設定を表示するには、アプリケーション・ナビゲータで目的のビュー・オブジェクトを展開し、展開されたビュー・オブジェクトのXMLファイルを選択して、構造ウィンドウを開きます。構造ウィンドウは、SQL問合せや属性のリストなどXML定義のリストを表示します。エディタでXML定義を開くには、対応するノードを右クリックして「ソースへ移動」を選択します。
ビュー・オブジェクトを作成した後、ビュー・オブジェクトの概要エディタでその設定を編集できます。
|
パフォーマンスに関するヒント: データをフェッチするためにビュー・オブジェクトをどのように構成するかは、ビュー・オブジェクトの実行時パフォーマンスにおいて重要な役割を果します。パフォーマンスを最適化するために編集可能なチューニング・パラメータの詳細は、6.3.10項「ビュー・オブジェクトの実行時パフォーマンスの最適化について」を参照してください。 |
ビュー・オブジェクト定義を編集するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックし、概要エディタを開きます。
ナビゲーション・タブを選択して任意のエディタのページを開き、SQL問合せの調整、属性名の変更、名前付きバインド変数の追加、UIコントロール・ヒントの追加、Java生成オプションの制御、およびその他の設定の編集を実行することができます。
エンティティ・ベースのビュー・オブジェクトに関して興味深い特徴の1つは、基礎となるエンティティ・オブジェクト属性に関連する各属性がその属性のプロパティを継承することです。図5-11は、継承された属性が選択されている状態の「属性の編集」ダイアログを示しています。ここでは、Javaの属性タイプや問合せ列のタイプなどのフィールドは無効になっており、これらの値は、このビュー・オブジェクトが関連付けられている基礎となるエンティティ・オブジェクトの関連属性から継承されています。属性のデータ型などの一部のプロパティは継承され、ビュー・オブジェクト・レベルでは変更できません。
QueryableおよびUpdatableなどの他のプロパティは継承されますが、上書き後の設定の方が継承された設定より制限が大きい場合、これらのプロパティを上書きできます。たとえば、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定は、「常に」です。図5-11のように、「属性の編集」ダイアログでは、対応するビュー・オブジェクト属性を、より制限の大きい「新規の間」や「なし」などに設定できます。ただし、基礎となるエンティティ・オブジェクトの属性に対する「更新可能」設定が「なし」である場合、エディタでは、ビュー・オブジェクトの関連属性をより制限の小さい「常に」などに設定できません。
「属性の編集」ダイアログにビュー・オブジェクトの特定の属性を表示すると、その実行時動作を制御する宣言設定の値を参照および変更できます。重要なプロパティの1つに、「問合せ列」セクションの「型」があります(図5-11を参照)。このプロパティは、VARCHAR2列の長さ情報やNUMBER列の精度およびスケール情報を含む、列のSQL型を記録します。
JDeveloperでは、列の型が自動的に推測されますが、一部のSQL式では推測された値がデフォルトでVARCHAR2(255)になることがあります。このような型の属性に対して正しい長さがわかっている場合は、「型」の値を更新してその長さを反映します。読取り専用ビュー・オブジェクトの場合、このプロパティは、ビュー・オブジェクトの概要エディタから表示できる「属性の編集」ダイアログで編集できます。エンティティ・ベースのビュー・オブジェクトの場合は、エンティティ・オブジェクト用に表示される「属性の編集」ダイアログで「型」プロパティを編集する必要があります(4.10.2項「データ型の長さ、精度およびスケールの指定方法」を参照)。
たとえば、図5-12でFirstName属性に対する「型」として示されているVARCHAR2(30)は、最大文字数が30文字であることを意味しています。NUMBER列の場合、小数点以下7桁の精度と2桁のスケールを持つ属性について、NUMBER(7,2)の「型」を示します。
|
パフォーマンスに関するヒント: それぞれのSQL式では、データベースの記述から通知される列の長さを制御できます。それには、既存の式に対して |
「ビュー・オブジェクトの作成」ウィザードを使用して読取り専用ビュー・オブジェクトを作成する場合、デフォルトでは、このビュー・オブジェクトの属性は更新不可になります。作成した後に、SQLにマップされた表の列を更新できるようにビュー・オブジェクトを変換できます。ただし、属性の「更新可能」プロパティを変更するだけでこの目的を達成することはできません。読取り専用ビュー・オブジェクトを更新可能に変換するには、読取り専用ビュー・オブジェクトの作成に使用した表と同じ表にマップするエンティティ・オブジェクトの慣用名を追加する必要があります。同じ表を定義するエンティティ・オブジェクトの慣用名を選択すると、SQLから導出されたビュー属性を、同一の表列に対応するエンティティ・オブジェクトの慣用名の属性に再マップできます。
更新できるように読取り専用ビュー・オブジェクトを変更するには:
「アプリケーション・ナビゲータ」で、読取り専用ビュー・オブジェクトをダブルクリックします。
概要エディタで、「エンティティ・オブジェクト」ナビゲーション・タブをクリックします。
「エンティティ・オブジェクト」ページで、「選択可能」リストを展開し、読取り専用ビュー・オブジェクトの属性を指定するエンティティ・オブジェクトをダブルクリックします。
ダブルクリックしたエンティティ・オブジェクトが、「選択されたもの」リストにエンティティ・オブジェクトの慣用名として表示されます。SQLから導出された属性を、エンティティ・オブジェクトの慣用名で定義される対応する属性に再マップする必要があります。
「問合せ」ナビゲーション・タブをクリックし、「問合せ」ページで「SQL問合せの編集」ボタンをクリックします。
「問合せの編集」ダイアログで、「問合せ」をクリックしてから「属性マッピング」をクリックします。
属性マッピング」ページで、次の手順を実行し、SQLから導出されたすべての属性を、対応するエンティティ・オブジェクトの慣用名にマップされた属性に変換します。
「ビュー属性」列の属性フィールドをクリックし、ドロップダウン・リストの最上部までスクロールしてエンティティ・オブジェクトの慣用名の属性を探します。
図5-11に示されているように、エンティティ・オブジェクトの慣用名の属性のリストで、再マップする読取り専用属性に対応する属性を選択します。
「OK」をクリックします。
概要エディタでビュー・オブジェクトを編集するときに、概要エディタの「属性」ページをカスタマイズし、表示されるビュー・オブジェクトの属性表を有効活用することができます。
属性表でカスタマイズできるのは、属性表に列として表示する属性プロパティのリスト、属性表に表示される列の順序(左から右)、列のソート順、列の幅などです。表示可能な列の全リストは、ビュー・オブジェクトの「属性の編集」ダイアログで編集できる属性のプロパティに対応します。
たとえば、ビュー・オブジェクトのどの属性が更新可能かを即座に把握する必要がある場合は、属性表に表示する列として「更新可能」プロパティを追加できます。また、属性の「ラベル」プロパティを列として追加し、エンド・ユーザーに表示されるものと同じ説明を表示できます。また、エンティティ・オブジェクトの慣用名に基づいて属性のリストを表示する必要があるとします。その場合は、「エンティティ・オブジェクトの慣用名」列を表示して、この列に基づいて属性表全体をソートできます。
最も有益な列のリストを含めるように属性表を設定した後、属性表を右クリックして「すべてのビュー・オブジェクトに適用」を選択すると、他のビュー・オブジェクトに表示される属性表にも同じ列セットを適用することができます。
属性表の表示のカスタマイズには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、属性列ヘッダー右(属性表のボタン・バー下)のドロップダウン・メニューをクリックし、「列の選択」を選択します。
「列の選択」ダイアログで、次のアクションを実行します。
概要エディタの属性表に表示される列のリストを変更するには、左/右シャトル・ボタンをクリックします。概要エディタには、「選択されたもの」リストに表示される属性プロパティに対応する列のみが表示されます。
概要エディタの属性表の列の位置を変更するには、選択項目を移動のボタンの1つをクリックします。概要エディタの属性プロパティは、「選択されたもの」リストの上位にあるプロパティから、左から右に配置されて表示されます。
「OK」をクリックします。
概要エディタの「属性」ページで、次のアクションを実行します。
選択した列を基準として属性表のすべての列をソートするには、列ヘッダーをクリックします。
この機能は、特定の列に注目する必要がある場合に特に有益です。たとえば、エンティティ・ベースのビュー・オブジェクトの場合、「エンティティ・オブジェクトの慣用名」列ヘッダーをクリックして、基礎となるエンティティ・オブジェクトごとに属性表の属性をグループ化できます。概要エディタに表示するビュー・オブジェクト全体でこの設定を保存するには、列ヘッダー右のドロップダウン・メニューをクリックし、「すべてのビュー・オブジェクトに適用」をクリックします。
属性表の列の幅を調節するには、列ヘッダーの境界線をクリックしてドラッグします。
現在の属性表に表示されている列を変更するには、列ヘッダー右のドロップダウン・アイコンをクリックし、表示されている列のリストから選択します。
現在のビュー・オブジェクトの概要エディタの属性表表示を簡易化する場合に、この機能によって容易に列を非表示にできます。
列の変更(列のリスト、列の順序、列のソート、列幅を含む)をすべての他のビュー・オブジェクトの概要エディタに拡張する場合は、列ヘッダー右のドロップダウン・メニューをクリックし、「すべてのビュー・オブジェクトに適用」をクリックします。
この機能により、ビュー・オブジェクト全体で同じ属性を容易に比較できます。概要エディタにより、「列の選択」ダイアログで選択した列(および順序)、および現在の属性表の列ソートと列幅が、ユーザーが編集するすべてのビュー・オブジェクトに適用されます。開いている概要エディタに現在表示中のビュー・オブジェクトは、これらの設定によって更新されないため、ビュー・オブジェクトの概要エディタを閉じてからもう一度開き、このビュー・オブジェクトをもう一度開いて設定が適用されたことを確認してください。
ビュー・オブジェクト定義を作成した後、ビュー・オブジェクトが問い合せる属性の順序を変更できます。このビュー・オブジェクト編集機能により、ビュー・オブジェクトの概要エディタの「属性」ページに表示される属性表の属性の順序を容易に変更できます。この機能は、特定の属性に対して作用し、現在のビュー・オブジェクトのXML定義を変更するため、ユーザーが編集する別のビュー・オブジェクトには適用されません。または、概要エディタの属性表の列ヘッダーをクリックして、ソース・ファイルに影響を与えずに、ビュー・オブジェクトの概要エディタの「属性」ページの属性表示をソートする方法もあります。
ビュー・オブジェクトのソース・ファイルの属性の順序を変更するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「ソース・オーダーの設定」をクリックします。
「ソース・オーダーの設定」ダイアログで、位置を変更する属性を選択し、選択項目を移動のボタンの1つをクリックします。
「OK」をクリックします。
この機能は、ユーザーが編集する他のビュー・オブジェクトには影響せず、現在のビュー・オブジェクトにのみ適用されます。
JDeveloperのUMLダイアグラムを使用すると、ビジネス・コンポーネント・ダイアグラムを作成してビジネス・ドメイン・レイヤーを視覚化できます。JDeveloperのUMLダイアグラムでは、エンティティ・オブジェクトのサポートのみならず、ビュー・オブジェクトをダイアグラムにドロップして、その構造とエンティティ・オブジェクトの慣用名を視覚化できます。たとえば、oracle.fodemo.storefrontパッケージにStoreFrontService Data Modelという名前の新しいビジネス・コンポーネント・ダイアグラムを作成し、アプリケーション・ナビゲータからダイアグラムにCustomerAddressVOビュー・オブジェクトをドラッグすると、そのエンティティ・オブジェクトの慣用名が図5-14のように表示されます。ノードを拡張して表示すると、ダイアグラムには、ビュー・オブジェクトのエンティティ・オブジェクトの慣用名を含む部分が表示されます。
ダイアグラムの作成の詳細は、4.4項「ビジネス・レイヤーのエンティティ・ダイアグラムの作成」を参照してください。
ADFビジネス・コンポーネントでは、設計時に移入した行を使用して、各自のデータ・モデル・プロジェクトでビュー・オブジェクトを作成できます。通常、保持するデータ量が少なく、それらのデータを変更する頻度が低いと予想される場合は、静的データを使用してビュー・オブジェクトを作成します。データベースの参照表を使用するか、ハードコードされた値のリストに基づいて静的ビュー・オブジェクトを使用するかは、データのサイズおよび性質に基づいて決定します。リストのエントリ数が100未満の場合は、静的ビュー・オブジェクトの方が便利です。行が相当数ある場合は、従来の表ベースのビュー・オブジェクトを使用してデータベースから読み取る必要があります。静的ビュー・オブジェクトには、変換が容易であるという長所があります。ただし、静的ビュー・オブジェクトの行はすべて一括で取得されるため、使用するエントリ数が100未満であれば最適なパフォーマンスが得られます。
|
ベスト・プラクティス: データ量が少ない静的データのリストにアクセスするためにビュー・オブジェクトを作成する必要がある場合は、データベースに問い合せるよりも静的ビューを使用することをお薦めします。静的ビューは、データの行数が100を超えないリストで使用することが理想的です。ビュー・オブジェクトの作成ウィザードでは、データはリソース・メッセージ・ファイルに保存されるため、これらのデータの変換は簡単です。 |
データベースに対する問合せによって値のリストを取得することが適切でない場合は、静的リスト・ビュー・オブジェクトをLOVデータソースとして使用できます。たとえば、注文に対して未処理、処理済、保留中というステータスがあるとします。これらの値を使用して静的ビュー・オブジェクトを作成し、その静的ビュー・オブジェクトのステータス属性に基づいてLOVを定義できます。ウィザードではステータス・ビュー・オブジェクトの値が変換可能なリソース・ファイルに格納されるため、アプリケーションの現在のロケールに対応したリソース・ファイルを使用して、UIにステータス値が表示されます。
静的ビュー・オブジェクトの作成には、ビュー・オブジェクトの作成ウィザードを使用します。このウィザードでは、目的の属性(列)を定義し、必要な数の行を入力できます。このウィザードには、作成したとおりに静的データ表が表示されます。
|
注意: 静的ビュー・オブジェクトは、その中のデータがデータベース表からのものではないため、読取り専用です。 |
ビュー・オブジェクトの作成ウィザードでは、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づいて属性を作成することもできます。このウィザードでは、フラット・ファイルの先頭行のデータを使用して定義した属性が作成されます。
静的ビュー・オブジェクトの属性を手動で作成するには:
アプリケーション・ナビゲータで、静的リスト・ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから「ビュー・オブジェクト」を選択し、「OK」をクリックします。
これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「デザインタイムで移入された行(静的リスト)」を選択し、このビュー・オブジェクトに対して静的リスト・データが取り込まれるよう指定します。「次へ」をクリックします。
「属性」ページで、「新規」を選択し、静的データ表の列に対応する属性を追加します。「新規ビュー・オブジェクト属性」ダイアログで、名前を入力して属性タイプを選択します。「OK」をクリックしてウィザードに戻り、「次へ」をクリックします。
「属性の設定」ページでは、何も行わず「次へ」をクリックします。
「静的リスト」ページで、「追加」アイコンをクリックし、ウィザード・ページにデータを直接入力します。定義した属性は、静的データ表の列として表示されます。
「アプリケーション・モジュール」ページでは、何も行わず「次へ」をクリックします。
「サマリー」ページで「終了」をクリックします。
ビュー・オブジェクトの作成ウィザードの「インポート」機能を使用すると、スプレッドシート・ファイルなどのカンマ区切り(CSV)ファイル形式のデータに基づく属性によって、静的データ・ビュー・オブジェクトを作成できます。このウィザードでは、属性の識別にはCSVフラット・ファイルの先頭行が使用され、それぞれの属性のデータに対してはCSVファイルの後続行が使用されます。たとえば、アプリケーションで国際通貨を表示する必要がある場合は、図5-15のように、最初の行にSymbol、Country、Descriptionの列を定義し、行を追加して各通貨タイプのデータを定義します。
フラット・ファイルに基づいて静的ビュー・オブジェクトの属性を作成するには:
アプリケーション・ナビゲータで、静的リスト・ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
これがプロジェクトで作成する最初のコンポーネントである場合、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示され、データベース接続を選択できます。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「デザインタイムで移入された行(静的リスト)」を選択し、このビュー・オブジェクトに対して静的リスト・データが取り込まれるよう指定します。「次へ」をクリックします。
必要に応じて、「属性」ページで「新規」を選択し、静的データ表の列に対応する属性を追加します。「新規ビュー・オブジェクト属性」ダイアログで、名前を入力して属性タイプを選択します。「OK」をクリックしてウィザードに戻り、「次へ」をクリックします。
静的データがCSVフラット・ファイルからロードされる場合は、このステップを省略できます。属性を自分で作成しない場合は、ウィザードでCSVファイルの先頭行に基づいて属性が作成されます。ただし、ウィザードで属性を作成する場合は、作成する属性はフラット・ファイルで定義されている列の順序と一致する必要があります。作成した属性の数が列数より少ない場合、余分な列はインポート中に無視されます。逆に、作成した属性の数が列数より多い場合は、余分な属性にNULL値が定義されます。
「属性の設定」ページでは、何も行わず「次へ」をクリックします。
「静的リスト」ページで、「インポート」をクリックし、ウィザードにデータを表示します。データを確認し、必要に応じて編集します。
属性値を編集するには、値フィールドをダブルクリックします。
必要に応じて、「追加」アイコンまたは「削除」アイコンをクリックし、データの行数を変更します。「次へ」をクリックします。
新しい行の属性値を入力するには、値フィールドをダブルクリックします。
「アプリケーション・モジュール」ページでは、何も行わず「次へ」をクリックします。
「サマリー」ページで「終了」をクリックします。
静的ビュー・オブジェクトを作成すると、ウィザードで定義したデータの行がビュー・オブジェクトの概要エディタに表示されます。エディタを使用すると、図5-16に示すように追加データを定義できます。
静的ビュー・オブジェクトの生成済XML定義には、データの列ごとに一時属性が1つずつ格納されます。たとえば、国際通貨のデータが格納されたCSVファイルをインポートすると、静的ビュー・オブジェクトには、例5-1のように、Symbol、CountryおよびDescriptionの一時属性が格納されます。
例5-1 静的ビュー・オブジェクトのXML定義
<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>要素がリソース・バンドル・ファイルを参照します。リソース・バンドル・ファイルには、データの行が記述されるため、データのローカライズも可能です。デフォルトのリソース・バンドル・タイプが使用されている場合は、例5-2のように、データ・モデル・プロジェクトにModelNameBundle.propertiesファイルが表示されます。
例5-2 静的ビュー・オブジェクトのデフォルトのリソース・バンドル・ファイル
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ビジネス・コンポーネントにより、有効日に基づいてビュー行を制限するための問合せフィルタが生成されます。
有効日に関する問合せフィルタが生成されるかどうかは、ビュー・オブジェクトの「プロパティ・インスペクタ」に表示される「有効日指定」プロパティの値によって決まります(このプロパティを表示するには、ビュー・オブジェクトの概要エディタで「属性」以外のいずれかのタブを選択します)。
|
注意: 有効日が指定されたビュー・オブジェクトは有効日が指定されたエンティティ・オブジェクトに基づく必要があるため、有効日が指定された基礎となるエンティティ・オブジェクトを指定せずに、ビュー・オブジェクトの「有効日指定」プロパティを「True」に設定すると、ランタイム例外が発生します。 |
ビュー・オブジェクトの概要エディタでは、WHERE句に含まれる有効日指定の問合せ句は表示されません。「実行計画」ダイアログまたは「問合せのテスト」ダイアログを使用すると、この句を表示できます。有効日の問合せフィルタは通常、次のようになります。
(:Bind_SysEffectiveDate BETWEEN Person.EFFECTIVE_START_DATE AND Person.EFFECTIVE_END_DATE)
実行時には、問合せに対するバインド値が、ルート・アプリケーション・モジュールのプロパティから取得されます。トランザクションに対して有効日を設定する場合は、次のようなコード・スニペットを使用します。
am.setProperty(ApplicationModule.EFF_DT_PROPERTY_STR, new Date("2008-10-01));
アプリケーション・モジュール上でEFF_DT_PROPERTY_STRを設定しない場合、問合せフィルタでは現在の日付が使用され、ビュー・オブジェクトからは現在の日付でフィルタリングされた有効な行が戻されます。
ビュー・オブジェクトには、ビュー行に対する有効日の設定に使用できるSysEffectiveDateという独自の一時属性があります。有効日を設定しない場合、新規行およびデフォルト行に対するSysEffectiveDate属性の値は、アプリケーション・モジュールから導出されます。ADFビジネス・コンポーネントでは、DML操作中にのみビュー行からエンティティ・オブジェクトに有効日が伝播されます。
作業を始める前に、次のようにします。
4.2.8項「特定の時点に関するデータを格納する方法」の説明に従い、有効日が指定されたエンティティ・オブジェクトを作成します。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」の説明に従って、「ビュー・オブジェクトの作成」ウィザードを使用してエンティティ・ベースのビュー・オブジェクトを作成します。
作成するビュー・オブジェクトは、作成済の有効日が指定されたエンティティ・オブジェクトに基づいている必要があります。ウィザードの「属性」ページで、エンティティ・オブジェクトの開始日と終了日を指定した有効日指定の属性を、ビュー・オブジェクトの「選択されたもの」リストに追加してください。
SysEffectiveDate属性を使用してビュー・オブジェクトに有効日を設定するには:
「アプリケーション・ナビゲータ」で、有効日が指定されたエンティティ・オブジェクトに基づいて作成したビュー・オブジェクトをダブルクリックします。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
プロパティ・インスペクタ」で、「名前」カテゴリを展開します。
「プロパティ・インスペクタ」に「名前」カテゴリが表示されていない場合は、概要エディタの「一般」ナビゲーション・タブをクリックし、適切なフォーカスを設定します。
「有効日指定」プロパティのポップアップ・メニューに「True」が表示されていることを確認します。
概要エディタで、「属性」ナビゲーション・タブをクリックし、開始日の属性をダブルクリックします。
図5-17に示すように、「属性の編集」ダイアログで、「有効日」および「開始」が選択されていることを確認します。図に示すように、終了日の属性も正しく選択されていることを確認します。ビュー・オブジェクトで編集不可であることを示すため、これらのフィールドはグレー表示されています。
「OK」をクリックします。
有効日が指定されたエンティティ・オブジェクトから、必要な属性がビュー・オブジェクトに継承されていることを確認したら、追加の手順は必要ありません。
有効日が指定された行は、通常のビュー行と同じように作成(挿入)できます。開始日および終了日は次のように指定できます。
ユーザーがアプリケーション・モジュールで有効日を指定します。開始日はこの有効日に設定され、終了日は指定可能な最後の日付に設定されます。
ユーザーが開始日および終了日のそれぞれの値を指定します(詳細設定)。
どちらの場合も、エンティティの検証中には、新規行によってギャップや重複が生じないようにチェックが実行されます。またポスト時には、ADFビジネス・コンポーネントにより、行の挿入時にギャップや重複が生じないよう、直前の行に対してロックが取得されます。
Row.setAttribute()などのAPIコールを使用することにより、ビュー行を更新できます。ADFビジネス・コンポーネントでは、行の更新を開始するための様々なモードがサポートされています。
更新モードを設定するには、次のいずれかのモード定数を指定したRow.setEffectiveDateMode(int mode)メソッドを起動します。
CORRECTION(修正モード)
有効開始日および有効終了日は変更されません。それ以外の属性値は変更される場合があります。これは行の更新に関する標準の動作です。
UPDATE(更新モード)
行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値のある行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は指定可能な最後の日付に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。
UPDATE_OVERRIDE(更新オーバーライド・モード)
変更された行の有効終了日が有効日として設定されます。次の行の有効開始日は、有効日の翌日に設定されます。
UPDATE_CHANGE_INSERT(変更挿入モード)
変更された行の有効終了日が有効日として設定されます。この行では、ユーザーにより変更された行の値がすべて元に戻されます。また、変更された値を持つ行が新たに作成されます。新規行の有効開始日は有効日の翌日に設定され、有効終了日は次の行の有効開始日の前日に設定されます。新規行は、トランザクションがデータベースにポストされた後に表示されます。
ADFビジネス・コンポーネントでは、行の削除を開始するための様々なモードがサポートされています。RowSet.removeCurrentRow()やRow.remove()などのAPIコールを使用することにより、削除するビュー行をマークできます。
削除モードを設定するには、次のいずれかのモード定数を指定したRow.setEffectiveDateMode(int mode)メソッドを起動します。
DELETE(更新モード)
行の有効日が有効日として設定されます。この行に対する操作は、削除から更新に変更されます。有効日でないキー値が同じであり、有効開始日が有効日より後になっている行はすべて削除されます。
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)
例5-3は、有効日が指定されたビュー・オブジェクトの作成時に生成されるサンプルのXMLエントリを示しています。
例5-3 有効日が指定されたビュー・オブジェクトの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つの表から取得した行を示しています。この結合は、単一のフラット化された結果です。
ビジネス・アプリケーションでは、外部キー属性が示す内容をエンド・ユーザーが理解しやすいようにするために、プライマリ・ビジネス・ドメイン・オブジェクトとともにセカンダリ参照情報から情報を補足するのが一般的です。OrderItemsエンティティ・オブジェクトを例として考えてみます。このオブジェクトには、次のようなNumber型の外部キー属性が含まれます。
ProductId: 発注項目が関係する製品を示します。
経験上、このような未処理の数値のみをエンド・ユーザーに示しても、あまり役立ちません。アプリケーションの使いやすさを向上させるには、ビュー・オブジェクトに関連付けられたエンティティ・オブジェクトからの参照情報の表示が理想的です。一般的な解決方法の1つとして、プライマリ情報と参照情報の組合せを取得する結合問合せを実行する方法があります。この方法は、参照表に対する特別な問合せに基づいて、問合せ対象の行ごとに参照情報とともにダミー・フィールドを移入するのと同じです。
エンド・ユーザーがデータを編集して外部キー値を変更できる場合、この方法は別の課題をもたらします。この場合、エンティティ・ベースのビュー・オブジェクトは、常に最新の状態の参照情報を簡単に組み込む機能をサポートしています。この機能を活用するには、ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名として機能するエンティティ・オブジェクトと、参照情報を提供するエンティティ・オブジェクト間にアソシエーションが確立されていることが必要です。
結合ビュー・オブジェクトに参照エンティティを取り込む場合は、ビュー・オブジェクトの作成ウィザードを使用します。ビュー・オブジェクトの作成ウィザードでは、次のいずれかの結合タイプを指定します。
内部結合
ビュー・オブジェクトから、(各エンティティが同じ主キー列を定義している)2つ以上のエンティティ・オブジェクト間のすべての行を戻す場合に選択します。結合されたエンティティに主キー値がない場合は、内部結合ビュー・オブジェクトから戻される行はありません。
外部結合
ビュー・オブジェクトから、1つのエンティティ・オブジェクトに存在するすべての行を(それに対応する行が結合されたエンティティ・オブジェクトになくても)戻す場合に選択します。左外部結合と右外部結合両方がサポートされています。左および右を指定すると、アソシエーションで指定された関連元(左)および関連先(右)のエンティティ・オブジェクトが参照されます。デフォルトの内部結合を外部結合に変更する方法の詳細は、5.5.5項「必要に応じたデフォルトの結合句の外部結合への変更」を参照してください。
内部結合と外部結合のどちらにおいても、次のオプションを使用できます。
参照
エンティティ・オブジェクトのデータをビュー・オブジェクトの参照情報として使用する場合に選択します。データの自動参照がサポートされているため、制御キー属性が変更される場合は、属性値がエンティティ・キャッシュから動的にフェッチされます。
更新可能
ビュー・オブジェクトによってエンティティ・オブジェクトの任意のエンティティ属性が変更されないようにする場合は選択を解除します。デフォルトでは、「選択済」リストの先頭にあるエンティティ・オブジェクト(プライマリ)は更新可能であり、後続のエンティティ・オブジェクト(セカンダリ)は更新できません。複数の更新可能なエンティティ・オブジェクトの慣用名を使用して結合ビュー・オブジェクトを作成する方法の詳細は、39.9項「複数の更新可能エンティティによるビュー・オブジェクトの作成」を参照してください。
行削除のサポート
エンティティが更新可能として定義されており、かつUIの行削除のアクションにより関連する参照エンティティ・オブジェクトが削除されるようにする場合に選択します。このオプションは、プライマリ・エンティティに対しては無効です。たとえば、注文項目は削除できますが、結合ビュー・オブジェクトから行削除がコールされた場合、その注文は削除できないようにする必要があります。
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。
エンティティ・オブジェクトを結合するビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
関連付けられているエンティティ・オブジェクトから参照情報を取り込むために、作成した既存のビュー・オブジェクトを変更する場合は、そのビュー・オブジェクトをダブルクリックし、ビュー・オブジェクトの概要エディタで「エンティティ・オブジェクト」ページを開きます。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ・オブジェクトを介した更新可能アクセス」を有効のままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。
「エンティティ・オブジェクト」ページの、「選択されたもの」リストの先頭にあるエンティティ・オブジェクトの慣用名は、ビュー・オブジェクトのプライマリ・エンティティ・オブジェクトの慣用名と呼ばれます。「使用可能」リストからプライマリ・エンティティ・オブジェクトを選択し、それを「選択済」リストに移動します。
このリストへの移動は、1つのプライマリ・エンティティ・オブジェクトの慣用名には限定されません。
さらに、セカンダリ・エンティティ・オブジェクトをビュー・オブジェクトに追加する場合は、これらを「使用可能」リストから選択し、「選択済」リストに移動します。
「アソシエーション」ドロップダウン・リストには、選択したセカンダリ・エンティティ・オブジェクトの慣用名をプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションの名前が表示されます。たとえば、図5-19は、プライマリ・エンティティ・オブジェクトの慣用名ShippingOptionBaseEOの他に、セカンダリ参照エンティティ・オブジェクトの慣用名ShippingOptionTranslationEOを1つ追加した結果を示しています。このセカンダリ参照エンティティ・オブジェクトの慣用名に関連するアソシエーションは、ShippingOptionTranslationFkAssociationです。
デフォルト名が明確でない場合は、「別名」フィールドを使用して、より意味のある名前をエンティティ・オブジェクトの慣用名として指定することもできます。
同じエンティティに対して複数のエンティティ・オブジェクトの慣用名を追加する場合、「アソシエーション」ドロップダウン・リストを使用して、このオブジェクトの慣用名とプライマリ・エンティティ・オブジェクトの慣用名との関連を示すアソシエーションを選択します。「次へ」をクリックします。
各セカンダリ・エンティティ・オブジェクトの慣用名に対しては、「参照」オプションが有効にされており、これは各エンティティが参照情報を提供すること、およびプライマリ・エンティティではないことを示します。「更新可能」オプションは無効にされています。この組合せが一般的に使用されます。ただし、複数の更新可能なエンティティ・オブジェクトの慣用名を使用して結合ビュー・オブジェクトを作成する必要がある場合は、39.9項「複数の更新可能エンティティによるビュー・オブジェクトの作成」を参照してください。
更新可能なセカンダリ・エンティティ・オブジェクトの慣用名に対しては、行削除のサポートオプションを有効にすることもできます。これにより、プライマリ・エンティティが表示される際、セカンダリ・エンティティ属性にNULL値を表示できます。
「属性」ページで、各エンティティ・オブジェクトの慣用名からビュー・オブジェクトに取り込む属性を選択します。「次へ」をクリックします。
「属性の設定」ページでは、属性の名前がわかりにくい場合はその名前を変更できます。
参照エンティティ・オブジェクトやセカンダリ・エンティティ・オブジェクトが同じ表から導出される場合は、属性名が重複することがあります。図5-20では、「属性の選択」ドロップダウン・リストの属性ShippingOptionId1が、「名前」フィールドでShippingOptionTranslationIdという名前に変更されています。
「終了」をクリックします。
セカンダリ・エンティティ・オブジェクトの慣用名を追加したら、ビュー・オブジェクトの概要エディタを使用して、ビュー・オブジェクトに組み込むこれらの新しいオブジェクトの慣用名から特定の追加属性を選択できます。
|
ヒント: 概要エディタでは、「属性」ページに表示される属性を、エンティティ・オブジェクトの慣用名を基準にソートできます。デフォルトでは、属性表には、基礎となるエンティティ・オブジェクトに表示される順番に属性が表示されます。エンティティ・オブジェクトの慣用名を基準に属性をソートするには、属性表の「エンティティ・オブジェクトの慣用名」列のヘッダーをクリックします。属性表に「エンティティ・オブジェクトの慣用名」列が表示されない場合は、表の右上隅(ボタン・バーの下)のドロップダウン・メニュー・アイコンをクリックし、「列の選択」を選択して、この列を「選択されたもの」リストに追加します。 |
セカンダリ・エンティティ・オブジェクトの慣用名から属性を選択するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「エンティティからの追加」ボタンをクリックして、エンティティから導出された利用可能な属性を表示します。
「属性」ページで、目的の属性を選択し、「選択されたもの」ボタンをクリックします。
これらを組み込む意図がなかったとしても、各エンティティ・オブジェクトの慣用名の主キー属性が「選択済」リストの一部であるかどうかが自動的に検証されます。これらがリストに含まれていない場合は自動的に追加されます。処理が終了すると、概要エディタの「問合せ」ページには、JDeveloperによって新規の列がSELECT文に取り込まれたことを示すメッセージが表示されます。
「OK」をクリックします。
プライマリ・エンティティ・オブジェクトの慣用名の主キー属性に対応するビュー・オブジェクト属性は、ビュー行を識別するための主キーとして機能します。セカンダリ・エンティティ・オブジェクトの慣用名を追加すると、これらの主キー属性に対応するビュー・オブジェクト属性はビュー行キーの一部としてマークされます。ビュー・オブジェクトが単一の更新可能なプライマリ・エンティティ・オブジェクトの慣用名と多くの参照エンティティ・オブジェクトの慣用名で構成されている場合、ビュー行を一意に識別するにはプライマリ・エンティティ・オブジェクトの慣用名の主キー属性で十分です。セカンダリ・エンティティ・オブジェクトの慣用名から取り込まれた追加キー属性は不要になるため、これらの「キー属性」設定を無効にする必要があります。
たとえば、プライマリ・エンティティ・オブジェクトの慣用名ShippingOptionEOを持つビュー・オブジェクトに基づいて、エンティティ・オブジェクトの慣用名ShippingOptionTranslationEOの「キー属性」プロパティを無効にすることができ、これにより、この追加キー属性ShippingTranslationsIdに対してこのプロパティは選択されなくなります。
不要なキー属性を削除するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページの属性表で、キー属性(「名前」のキー・アイコンで識別)を選択し、「選択した属性の編集」ボタンをクリックします。
「属性の編集」ダイアログの「ビュー属性」ページで、「キー属性」プロパティの選択を解除します。
「OK」をクリックします。
通常、ビュー・オブジェクトに自動的に追加された主キー属性は表示する必要がないため、「属性の編集」ダイアログの「コントロール・ヒント」ページで、属性の「ヒントの表示」プロパティを「非表示」に設定できます。
主キー属性を非表示にするには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページの属性表で、プライマリ・キー属性(「名前」のキー・アイコンで識別)を選択し、「選択した属性の編集」ボタンをクリックします。
「属性の編集」ダイアログの「コントロール・ヒント」ページで、「ヒントの表示」ドロップダウン・リストから「非表示」を選択します。
「OK」をクリックします。
セカンダリ・エンティティ・オブジェクトの慣用名をビュー・オブジェクトに追加する場合、このエンティティ・オブジェクトの慣用名は、選択済エンティティのリストで上位にあるエンティティ・オブジェクトの慣用名に関連付けられます。この関係は、ビュー・オブジェクトの概要エディタの「エンティティ・オブジェクト」ページの「アソシエーション」ドロップダウン・リストに表示されるエンティティ・アソシエーションによって確立されます。エディタの「アソシエーション」ドロップダウン・リストを使用して、セカンダリ・エンティティ・オブジェクトの慣用名を、「選択されたもの」リストの上位にある目的のエンティティ・オブジェクトの慣用名に関連付けるエンティティ・アソシエーションを選択します。上位のエンティティ・オブジェクトの慣用名の名前は、「ソースの使用方法」ドロップダウン・リストで指定されます。
プライマリ・エンティティ・オブジェクトの慣用名の表とそれに関連付けられているセカンダリ・エンティティ・オブジェクトの慣用名の表の間に結合用のWHERE句が作成される場合、デフォルトでは常に内部結合が作成されます。必要であれば、デフォルトの内部結合句を左または右外部結合として変更もできます。左を指定すると、選択したアソシエーションで指定した関連元エンティティ・オブジェクトが参照されます。これは、「ソースの使用方法」ドロップダウン・リストで指定されたエンティティです。右を指定すると「選択されたもの」リストで選択している現在のセカンダリ・エンティティ・オブジェクトの慣用名が参照されます。
左外部結合では、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)右の表に対応する行がない場合でも、(「ソースの使用方法」リストで指定したエンティティ・オブジェクトに関連する)左の表のすべての行が結合に含まれます。右外部結合では、その逆で、(現在選択しているセカンダリ・エンティティ・オブジェクトに関連する)左の表に対応する行がない場合でも、(「ソースの使用方法」リストで指定したエンティティ・オブジェクトに関連する)右の表のすべての行が結合に含まれます。
たとえば、ユーザーにまだメンバーシップ・ステータスが割り当てられていないとします。この場合、MembershipId属性はNULLになります。デフォルトの内部結合条件では、MEMBERSHIPS_BASE表からこれらのユーザーは取得されません。MembershipDiscountsVOビュー・オブジェクトを介して、メンバーシップ・ステータスを持たないユーザーを表示可能および更新可能にする必要がある場合は、概要エディタにある「エンティティ・オブジェクト」ページを使用して、ビュー・オブジェクトについての問合せを、MEMBERSHIP_ID列のnullになる可能性のある値についてのMEMBERSHIPS_BASE表に対する左外部結合に変更できます。ユーザー・エンティティをビュー・オブジェクトに追加する場合は、「結合タイプ」として「左外部結合」を選択します。図5-21に示すように、アソシエーションPersonsMembershipsBaseFkAssocでは、結合の左側としてソースの慣用名MembershipBaseEO、右側として選択済エンティティ・オブジェクトの慣用名PersonEOを指定します。ビュー・オブジェクトMembershipDiscountsVOでは、これら両方のエンティティ・オブジェクトに関連する行が結合され、またPersonEOに対する左外部結合の定義により、このビュー・オブジェクトは、PersonEOに関連する表に対応する行がない場合でも、MembershipBaseEOに関連する表の行を返すことができます。
ビュー・オブジェクトの更新されたWHERE句の等号の右側では、データを左外部結合に含む必要のない関連表に対して(+)演算子が追加されています。
PersonEO.MEMBERSHIP_ID = MembershipBaseEO.MEMBERSHIP_ID(+)
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、目的のエンティティ・オブジェクトとアソシエーションを作成します。
内部結合を外部結合に変更するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「エンティティ・オブジェクト」ナビゲーション・タブをクリックします。
選択するエンティティ・オブジェクトは、結合の右側の表を表します。
「エンティティ・オブジェクト」ページの「選択されたもの」リストで、結合タイプを変更するエンティティ・オブジェクトを選択します。
選択するエンティティ・オブジェクトは、結合の右側の表を表します。
「アソシエーション」ドロップダウン・リストで、定義が1つのみの場合は選択されているままにし、それ以外の場合は、セカンダリ・エンティティ・オブジェクトを目的のエンティティ・オブジェクトに関連付けるエンティティ・オブジェクト・アソシエーションのリストから選択します。結合された表を表すエンティティ・オブジェクトの慣用名が、「ソースの使用方法」ドロップダウン・リストに表示されます。
アソシエーションの選択を通じて選択する、「ソースの使用方法」ドロップダウン・リストのエンティティ・オブジェクトは、結合の左側の表を表します。
「結合タイプ」ドロップダウン・リストで、ビュー・オブジェクトが結合されたエンティティ・オブジェクトから行を返す方法を指定します。
「左外部結合」では、右の表に対応する行がない場合でも、結合に左の表の行が含まれます。
「右外部結合」では、左の表に対応する行がない場合でも、結合に右の表の行が含まれます。
「ソースの使用方法」ドロップダウン・リストは、結合の左側を表し、 「選択されたもの」リストの現在のエンティティ・オブジェクトの慣用名は、結合の右側を表します。
結合ビュー・オブジェクトを作成して参照別のセカンダリ・エンティティ・オブジェクトの慣用名を組み込むと、ビュー・オブジェクトのXMLコンポーネント定義が更新され、追加のエンティティ・オブジェクトの慣用名に関する情報が組み込まれます。たとえば、ビュー・オブジェクトのShippingOptionsVO.xmlファイルには、別の参照エンティティ・オブジェクトの慣用名が含まれているとします。この情報は、複数の<EntityUsage>要素に記録されていることがわかります。たとえば、例5-0は、プライマリ・エンティティ・オブジェクトの慣用名を定義するエンティティ・オブジェクトの慣用名のエントリを示しています。
例5-4 プライマリ・エンティティ・オブジェクトの慣用名
<EntityUsage Name="ShippingOptionBaseEO" Entity="oracle.fodemo.storefront.entities.ShippingOptionBaseEO"/>
セカンダリの参照エンティティ・オブジェクトの慣用名のエントリはこれとは若干異なり、例5-5に示すエンティティ・オブジェクトの慣用名のように、これをプライマリ・エンティティ・オブジェクトの慣用名に関連付けるアソシエーションに関する情報が含まれます。
例5-5 セカンダリの参照エンティティ・オブジェクトの慣用名
<EntityUsage
Name="ShippingOptionTranslationEO"
Entity="oracle.fodemo.storefront.entities.ShippingOptionTranslationEO"
Association="oracle.fodemo.storefront.entities.associations.
ShippingOptionTranslationFkAssoc"
AssociationEnd="oracle.fodemo.storefront.entities.associations.
ShippingOptionTranslationFkAssoc.ShippingOptionTranslation"
SourceUsage="oracle.fodemo.storefront.store.queries.ShippingOptionsVO.
ShippingOptionBaseEO"
ReadOnly="true"
Reference="true"/>
XMLファイル内の各属性エントリは、参照先のエンティティ・オブジェクトの慣用名を示します。たとえば、例5-6のShippingOptionId属性のエントリは、これがShippingOptionBaseEOエンティティ・オブジェクトの慣用名に関連付けられており、ShippingMethod属性がShippingOptionTranslationEOエンティティ・オブジェクトの慣用名に関連付けられていることを示しています。
例5-6 エンティティ・オブジェクトの慣用名のビュー・オブジェクト属性の参照
<ViewAttribute
Name="ShippingOptionId"
IsNotNull="true"
EntityAttrName="ShippingOptionId"
EntityUsage="ShippingOptionBaseEO"
AliasName="SHIPPING_OPTION_ID" >
</ViewAttribute>
...
<ViewAttribute
Name="ShippingMethod"
IsUpdatable="true"
IsNotNull="true"
EntityAttrName="ShippingMethod"
EntityUsage="ShippingOptionTranslationEO"
AliasName="SHIPPING_METHOD" >
</ViewAttribute>
ビュー・オブジェクトの作成ウィザードでは、このアソシエーション情報が設計時に使用され、ビュー・オブジェクトの結合WHERE句が自動的に作成されます。この情報が実行時に使用されることにより、エンド・ユーザーによって外部キー属性値が変更されたときに参照情報を最新の状態に保つことが可能になります。
2つの表を結合する読取り専用ビュー・オブジェクトを作成するには、ビュー・オブジェクトの作成ウィザードを使用します。
2つの表を結合する読取り専用ビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで、データベース接続を選択するか、「新規」を選択して接続を作成します。「OK」をクリックします。
ビュー・オブジェクトの作成ウィザードの「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。「SQL問合せによる読取り専用アクセス」を選択し、このビュー・オブジェクトが読取り専用アクセスでデータを管理することを示します。「次へ」をクリックします。
「問合せ」ページでは、目的の表を結合するSQL問合せ文を作成するため、次のいずれかの操作を行います。
有効なSQL文を「問合せ文」ボックスに貼り付けます。
「クエリー・ビルダー」をクリックして「SQL文」ダイアログを開き、そこで対話型のクエリー・ビルダーを使用します(5.5.9項「クエリー・ビルダーで読取り専用ビュー・オブジェクトを処理する方法」を参照)。
問合せ文を入力または作成した後、「次へ」をクリックします。
「バインド変数」ページで、次のいずれかを実行します。
問合せがバインド変数を参照しない場合は、「次へ」をクリックして、ステップ3を省略します。
バインド変数を追加し、それを問合せの中で使用する場合は、5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」を参照してください。
「属性マッピング」ページで「終了」をクリックします。
新規ビュー・オブジェクトをテストするには、アプリケーション・モジュールを編集し、「データ・モデル」ページで新規ビュー・オブジェクトのインスタンスをデータ・モデルに追加します。次にビジネス・コンポーネント・ブラウザを使用して、結合問合せが予期したとおりに動作しているかどうかを検証します。データ・モデルの編集およびビジネス・コンポーネント・ブラウザの実行に関する詳細は、6.3項「ビジネス・コンポーネント・ブラウザを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。
「SQL文」ダイアログの「クイックピック・オブジェクト」ページでは、他の表に関連する外部キーも含め、自分のスキーマで表を参照できます。問合せの選択リストに列を組み込む場合は、目的の列を「使用可能」リストから「選択済」リストに移動します。たとえば、図5-22は、SUPPLIERS表からSUPPLIER_NAME列を選択すると同時に、PRODUCTS表からPRODUCT_ID、PRODUCT_NAMEおよびCOST_PRICEの各列を選択した結果を示しています。2番目の表の列は、「使用可能」リストのPRODUCTS_SUPPLIERS_FK外部キーの下に表示されています。外部キーによって結合された表から列を選択すると、必要な結合句がクエリー・ビルダーによって自動的に決定されます。
必要に応じて、「SQL文」ダイアログの「WHERE句」ページで式を定義します。問合せの作成を終了する場合は、「SQL文」ダイアログの「OK」をクリックします。「問合せの編集」ダイアログには、例5-7のような問合せが表示されます。
例5-7 SQL Builderを使用した問合せの作成
SELECT
PRODUCTS_BASE.PRODUCT_ID PRODUCT_ID,
PRODUCTS_BASE.PRODUCT_NAME PRODUCT_NAME,
PRODUCTS_BASE.COST_PRICE COST_PRICE,
SUPPLIERS.SUPPLIER_NAME SUPPLIER_NAME
FROM
PRODUCTS_BASE JOIN SUPPLIERS USING (SUPPLIER_ID)
ビュー・オブジェクトの作成ウィザードの「属性」ページでは、作成プロセスの一部としてビュー・オブジェクト属性の名前を直接変更できます。ここでビュー・オブジェクトの名前を変更しておくと、使用する属性名がわかっている場合にビュー・オブジェクトを再度編集する必要がなくなります。また、列の別名を割り当てることにより、Javaに適したデフォルトのビュー・オブジェクト属性名を変更することもできます(5.9.2項「エキスパート・モードで属性名を指定する方法」を参照)。
使用する問合せは、その多くが外部キーによって関連付けられた複数の表を対象としています。このシナリオでは、関連情報を問い合せる別個のビュー・オブジェクトを作成してからソース・ビュー・オブジェクトを1つ以上のターゲット・ビュー・オブジェクトにリンクして、マスター/ディテール階層を形成します。
この状況に対処する方法は2つあります。次のいずれかの方法が可能です。
ソース・ビュー・オブジェクトとターゲット・ビュー・オブジェクトの関連付けを定義するビュー・リンクを作成します。
ソース・ビュー・オブジェクトとターゲット・ビュー・オブジェクトが、基礎となるエンティティ・オブジェクトのアソシエーションに基づいている場合は、そのエンティティ・オブジェクト間のアソシエーションに基づいてビュー・リンクを作成します。
どちらの場合も、ビュー・リンクの作成ウィザードで関係を定義します。
図5-23は、リンクされたマスター/ディテール問合せにより生成されたマルチレベルの結果を示しています。
ユーザーにマスター行のセットを表示し、マスター行ごとに調整されたディテール行のセットを表示する必要がある場合、ビュー・リンクを作成して、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトをどのように関連付けるかを定義できます。たとえば、顧客のマスター/ディテール階層、および関連する発注済の注文のセットを作成する場合は、Personsビュー・オブジェクトとOrdersビュー・オブジェクトをリンクさせます。
ビュー・リンクを作成するには、ビュー・リンクの作成ウィザードを使用します。
作業を始める前に、次のようにします。
読取り専用ビュー・オブジェクトの作成の詳細は、5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」を参照してください。
読取り専用ビュー・オブジェクト間のビュー・リンクを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ビュー・リンク」を選択し、「OK」をクリックします。
ビュー・リンクの作成ウィザードの「名前」ページで、パッケージ名とビュー・リンク名を入力します。たとえば、ビュー・リンクの目的を考慮したOrdersPlacedByなどの名前が適切です。「次へ」をクリックします。
「ビュー・オブジェクト」ページで、マスターとして動作するビュー・オブジェクトからソース属性を選択します。
たとえば図5-24は、このロールを実行するPersonsVOビュー・オブジェクトから選択したPersonId属性を示しています。「次へ」をクリックします。
「ビュー・オブジェクト」ページで、ディテールとして動作するビュー・オブジェクトから、対応するリンク先属性を選択します。
たとえば、ディテール問合せにより、現在選択している顧客からの注文が表示されるようにする場合は、このロールを実行するOrdersVOからCustomerId属性を選択します。
「追加」をクリックし、対応する属性ペアを、下にあるソース属性とリンク先属性のペアの表に追加します。マスター/ディテール・リンクの定義が終了したら、「次へ」をクリックします。
図5-24では、ペアが1つのみ(PersonId、CustomerId)選択されています。ただし、マスターとディテールの間のリンクを定義するために必要な属性ペアが複数ある場合、「ビュー・オブジェクト」ページでこれらのステップを繰り返して、ソース/ターゲット属性ペアをさらに追加できます。
「ビュー・リンク・プロパティ」ページでは、「アクセッサ名」フィールドを使用して、リンク先ビュー・オブジェクトへのプログラムによるアクセスを可能にするアクセッサのデフォルト名を変更できます。
デフォルトでは、アクセッサ名は、リンク先ビュー・オブジェクトの名前と一致します。たとえば、デフォルトのアクセッサ名をOrdersVOからCustomerOrdersに変更すると、アクセッサで定義されるマスター/ディテール関係が明確になります。
また、「ビュー・リンク・プロパティ」ページで、ビュー・リンクが一方向と双方向のどちらを表すのかを制御できます。
デフォルトでは、ビュー・リンクは、ソース(マスター)の現在行をリンク先(ディテール)ビュー・オブジェクトの関連する行のセットにアクセスできるようにする一方向関係です。たとえば、図5-25におけるチェック・ボックスの設定では、PersonsVOの現在行のOrdersVOから行のディテール・コレクションにはアクセスできますが、逆方向のアクセスはできません。この場合の動作は、OrdersVOの「リンク先アクセッサ」グループ・ボックスのチェック・ボックス(「アクセッサの生成」の「ビュー・オブジェクト: PersonsVO」ボックスを選択)と、PersonsVOの「リンク元アクセッサ」グループ・ボックスのチェック・ボックス(「アクセッサの生成」の「ビュー・オブジェクト: OrdersVO」ボックスの選択を解除)の設定によって指定します。
「ソース問合せの編集」ページで、実行時にソース・ビュー・オブジェクトのマスター行へのアクセスに使用されるビュー・リンクのSQL述語をプレビューし、「次へ」をクリックします。
「関連先問合せの編集」ページで、実行時にソース・ビュー・オブジェクトの現在行に対するリンク先ビュー・オブジェクトから相関ディテール行へのアクセスに使用されるビュー・リンクのSQL述語をプレビューし、「次へ」をクリックします。
「アプリケーション・モジュール」ページで、目的のアプリケーション・モジュールのデータ・モデルにビュー・リンクを追加し、「終了」をクリックします。
デフォルトでは、ビュー・リンクはアプリケーション・モジュールのデータ・モデルに追加されません。ビュー・リンクは、後でアプリケーション・モジュールの概要エディタを使用してデータ・モデルに追加できます。
読取り専用ビュー・オブジェクトの場合と同様に、エンティティ・ベースのビュー・オブジェクトを他のビュー・オブジェクトにリンクし、任意の複雑さでマスター/ディテール階層を形成できます。作成手順で唯一異なるのは、マスター・ビュー・オブジェクトとディテール・ビュー・オブジェクトの両方がエンティティ・ベースのビュー・オブジェクトで、これらの各エンティティ・オブジェクトの慣用名がアソシエーションによって関連付けられている場合です。この場合、アソシエーションにより、これらのオブジェクトを関連付ける一連のソース属性と関連先属性のペアが取得されるため、ベースとなるアソシエーションを指定するのみでビュー・リンクを作成できます。
アソシエーション・ベースのビュー・リンクを作成するには、ビュー・リンクの作成ウィザードを使用します。
作業を始める前に、次のようにします。
エンティティ・ベースのビュー・オブジェクトの作成の詳細は、5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」を参照してください。
アソシエーション・ベースのビュー・リンクの作成方法:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
ビュー・リンクの作成ウィザードでパッケージ名の入力を省略するには、アプリケーション・ナビゲータでlinksパッケージ・ノードのポップアップ・メニューから選択できる「新規ビュー・リンク」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ビュー・リンク」を選択し、「OK」をクリックします。
ビュー・リンクの作成ウィザードの「名前」ページで、パッケージ名とコンポーネント名を指定します。
「ビュー・オブジェクト」ページの「ソース属性の選択」ツリーで、目的のパッケージのソース・ビュー・オブジェクトを開きます。「関連先属性の選択」ツリーで、リンク先ビュー・オブジェクトを開きます。
ビュー・オブジェクト属性の他にも、エンティティ・ベースのビュー・オブジェクトの場合、リストには関連するアソシエーションも表示されます。
ソースのツリーおよび宛先のツリーで同じアソシエーションを選択します。その後、「追加」をクリックして、次の表にアソシエーションを追加します。
たとえば、図5-26では、ソースのツリーおよび宛先のツリーの両方で同じOrderItemsOrdersFkAssocアソシエーションが選択されています。
「終了」をクリックします。
ビュー・リンク、またはアソシエーションベースのビュー・リンクを作成する場合、JDeveloperでその宣言的設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に保存されます。たとえば、OrderInfoToOrderItemsInfoという名前のビュー・リンクが作成され、queries.linksパッケージに表示された場合、プロジェクトのソース・パスに作成されるXMLファイルは、./queries/link/OrderInfoToOrderItemsInfo.xmlになります。このXMLファイルには、指定したソース属性とリンク先属性のペアに関する宣言情報が含まれ、ビュー・リンクがアソシエーションベースの場合は、指定したソース・ビュー・オブジェクトとリンク先ビュー・オブジェクトを関連付けるアソシエーションに関する宣言情報が含まれます。
ビュー・リンク・コンポーネント定義自体を保存するのみでなく、JDeveloperはビュー・リンク関係でのビュー・オブジェクトsourceのXML定義を更新して、定義したビュー・リンク・アクセッサに関する情報を追加します。これを確認するため、アプリケーション・ナビゲータでソース・ビュー・オブジェクトを選択し、構造ウィンドウでその詳細を検証できます。図5-27に示すように、OrderInfoToOrderItemsInfoビュー・リンクのOrderItemsInfoVOソース・ビュー・オブジェクトに定義されたアクセッサは、「ビュー・リンク・アクセッサ」ノードに表示されています。
|
注意: 1つのビュー・リンクにより、2つのビュー・オブジェクト間の基本的なマスター/ディテール関係が定義されます。ただし、より多くのビュー・リンクを作成することにより、次のものを含む複雑なマスター/ディテール階層を構成できます。
これらのより複雑な階層を定義する手順は、5.6.2項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」で説明された手順と同じで、1回に1つのビュー・リンクを作成するだけですみます。 |
5.6.2項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」で説明したように、ビュー・リンクを定義して、相関ディテールの行セットにプログラムで移動できるようにする場合、コードがリクエストする際に、調整されたディテール行セットを取得するために必要な情報を定義するのみという受動的な役割をビュー・リンクは担います。ビュー・リンク・アクセッサ属性が存在し、ビュー・リンクのソース・ビュー・オブジェクトの任意のインスタンスから任意の結果行でプログラムによるアクセスが可能です。つまり、プログラムによるアクセスでは、アプリケーション・モジュールのデータ・モデルを変更する必要はありません。
ただし、マスター/ディテール・ユーザー・インタフェースは、エンタープライズ・アプリケーション内で頻繁に発生するため、マスター/ディテール画面をプログラムで調整する必要性をなくすために、ビュー・リンクをより能動的に使用することもできます。ビュー・リンクされたビュー・オブジェクトのインスタンスをアプリケーション・モジュールのデータ・モデルに 明示的に追加することにより、この能動的なマスター/ディテール調整を実行できます。
マスター/ディテールの調整を有効にするには、概要エディタでアプリケーション・モジュールを開き、「データ・モデル」ページを選択します。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」の説明に従って、目的のビュー・オブジェクトを作成します。
ビュー・オブジェクトのディテール・インスタンスを追加する方法:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
「データ・モデル」ページで、「ビュー・オブジェクト・インスタンス」セクションを展開し、 「使用可能なビュー・オブジェクト」リストで、マスター・ビュー・オブジェクトの下でインデントされたディテール・ビュー・オブジェクト・ノードを選択します。
このリストには、ディテール・ビュー・オブジェクトが、それ自体として1回、およびビュー・リンクを介するディテール・ビュー・オブジェクトとして1回の計2回表示されることに注意してください。たとえば、図5-28では、OrderItemsInfoVOのラベルのビュー・オブジェクト(この場合は、強調表示されているビュー・オブジェクトの下に表示)ではなく、OrderItemsInfoVO via OrderInfoToOrderItemInfoディテール・ビュー・オブジェクトを選択しています。
「使用可能なビュー・オブジェクト」リストの下の「ビュー・インスタンスの名前の指定」フィールドに、作成しようとしているディテール・インスタンスの名前を入力します。
たとえば、図5-28では、ディテール・ビューであるOrderItemsInfoVOビュー・オブジェクトのインスタンスの名前はOrderItemsDetailVOです。
「データ・モデル」リストで、アクティブに調整するマスターにする必要があるビュー・オブジェクトのインスタンスを選択します。
「インスタンスの追加」をクリックして、データ・モデル内で現在選択されているマスター・インスタンスに、自分が選択した名前でディテール・インスタンスを追加します。
たとえば、図5-29では、「データ・モデル」リストに、ビュー・オブジェクト・インスタンスのマスター/ディテール階層(ディテール・ビュー・オブジェクトはOrderItemsDetailVO)が表示されています。
マスター/ディテールのアクティブな調整をテストするには、アプリケーション・ナビゲータのポップアップ・メニューから「実行」を選択して、アプリケーション・モジュール上でビジネス・コンポーネント・ブラウザを起動します。ビジネス・コンポーネント・ブラウザのデータ・モデル・ツリーには、マスター・ビュー・オブジェクト・インスタンスにあわせてディテール・ビュー・オブジェクト・インスタンスをアクティブに調整するビュー・リンク・インスタンスが表示されます。ツリー内のビュー・リンク・インスタンス・ノードをダブルクリックすると、ビジネス・コンポーネント・ブラウザのマスター/ディテール・データ・ビュー・ページが開きます。ツールバー・ボタンを使用してマスター・ビュー・オブジェクト内で移動する(結果としてビュー・オブジェクトの現在行を変更する)場合に、調整されたディテールのセットが自動的にリフレッシュされ、ユーザー・インタフェースは同期を維持します。
マスターまたはディテールとして定義されていない別のビュー・オブジェクトをダブルクリックすると、2番目のタブが開き、そのデータが表示されます。この場合、そのビュー・オブジェクトに対してはビュー・リンクによるアクティブな調整が行われないため、その問合せはマスター・ビュー・オブジェクトの現在行による制約を受けません。
データ・モデルの編集およびビジネス・コンポーネント・ブラウザの実行に関する詳細は、6.3項「ビジネス・コンポーネント・ブラウザを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。
ビュー・リンクを効果的に使用するためには、ビュー・リンク・アクセッサ属性によりRowSetオブジェクトが戻されることや、ディテール・コレクションへのビュー・リンク・アクセッサでのプログラムによるアクセスが可能になることを理解しておく必要があります。
実行時に、RowオブジェクトにあるgetAttribute()メソッドにより、ビュー・オブジェクトの名前別の結果セットで行の属性にアクセスできます。ビュー・リンク・アクセッサは、ソース・ビュー・オブジェクトの現在行の追加属性のような動作をするため、同じgetAttribute()メソッドを使用してその値を取得できます。通常のビュー属性とビュー・リンク・アクセッサ属性との実際の相違点は、そのデータ型のみです。通常のビュー属性は、一般に303やngreenbeのような値を持つスカラー・データ型であるのに対し、ビュー・リンク・アクセッサ属性の値はゼロまたは1つ以上の相関ディテール行の行セットです。curUserがOrdersビュー・オブジェクトのいくつかのインスタンスからのRowオブジェクトであると仮定すると、注文項目のディテール行セットを取得するための、次のコードを1行作成することができます。
RowSet items = (RowSet)curUser.getAttribute("OrderItems");
|
注意: ビュー行のカスタムJavaクラスを生成する場合、ビュー・リンク・アクセッサのタイプは |
例5-8に示すように、ビュー・リンク・アクセッサを使用してディテール行のRowSetオブジェクトを取得すると、ビュー・オブジェクトの結果の行セットをループする場合と同じように、それが含まれる行全体をループできます。
例5-8 ディテール・コレクションへのプログラムによるアクセス
while (items.hasNext()) {
Row curItem = items.next();
System.out.println("--> (" + curItem.getAttribute("LineItemId") + ") " +
curItem.getAttribute("LineItemTotal"));
}
テスト・クライアントの作成の詳細は、6.4.6項「ビュー・リンク・アクセッサを使用したディテール・コレクションのアクセス方法」を参照してください。
再帰的なデータ・モデルは、単一の表に基づくマスター/ディテール関係の関連元属性と関連先属性の名前を指定する単一の問合せを活用するものです。通常のマスター/ディテール関係では、関連元属性はマスター・ビュー・オブジェクトの主キー属性によって指定され、関連先属性はディテール・ビュー・オブジェクトの外部キー属性によって指定されます。たとえば、一般的なマスター/ディテール関係では、DEPARTMENT表のDepartmentId属性と、対応するEMPLOYEE表のDepartmentId属性が関連付けられます。しかし、再帰的モデルでは、関連元属性EmployeeIdと関連先属性ManagerIdがともにEMPLOYEE表に存在します。したがって、この関係に対する問合せで使用するのは、単一のビュー・オブジェクトのみです。このシナリオでは、両方の属性を指定する単一のベース・エンティティ・オブジェクトのビュー・オブジェクトを作成してから、自己参照型のビュー・リンクを定義し、このビュー・オブジェクトを「関連元」ビュー・オブジェクトおよび「関連先」ビュー・オブジェクト両方として構成してマスター/ディテール階層を形成します。
ビュー・リンクを作成したら、2つの方法でデータ・モデル・プロジェクトの再帰的マスター/ディテール階層を操作できます。次のいずれかの方法が可能です。
同一のビュー・オブジェクトの2つのインスタンス(ビュー・リンク・インスタンスによって能動的に調整され、マスターとしての役割を果たすものと、ディテールとしての役割を果たすもの)を公開するデータ・モデルを作成します。これは、2つの別々の表で同時に単一レベルのマスター行とディテール行を表示する必要があるときに有益です。
ビュー・オブジェクトの単一のインスタンスのみを公開するデータ・モデルを作成し、各行のビュー・リンク・アクセッサ属性を使用してディテール行セットにアクセスします。再帰的マスター/ディテール階層のデータが存在する任意のレベルを表示(またはプログラム的に操作)できるため、2つのうち、この方法が一般的に使用されます。たとえば、treeまたはtreeTableコンポーネントの再帰的階層を表示する場合は、24.4.1項「ツリーでのマスター/ディテール・オブジェクトの表示方法」で説明されているように、このアプローチを使用します。
再帰的マスター/ディテール階層では、ビュー・リンクで選択するリンク元およびリンク先のビュー・オブジェクトの属性は、通常、基礎となるエンティティ・オブジェクト間の自己参照型アソシエーションを定義する属性ペアと同じになります(このアソシエーションが存在する場合)。基礎をなすこのアソシエーションはビュー・リンクの作成には不要ですが、これによりビュー・リンクの作成が容易になるため、まず、ビュー・オブジェクトのベース・エンティティ・オブジェクトに対する外部キーを作成します。
アソシエーションを作成するには、「アソシエーションの作成」ウィザードを使用します。「ビュー・リンクの作成」ウィザードを使用するときに、このアソシエーションが選択肢として表示されます。関連元ビュー・オブジェクトと関連先ビュー・オブジェクトに対して選択するアソシエーションでは、単一のデータベース表から導出された同じエンティティ・オブジェクトの名前を指定するため、このビュー・リンクは自己参照型になります。
作業を始める前に、次のようにします。
ビュー・リンクを作成する場合、エンティティ・オブジェクトの関連元属性と関連先属性間のアソシエーションは推測されません。再帰的階層をサポートするために、「アソシエーションの作成」ウィザードを使用して、関連元属性と関連先属性間のアソシエーションを作成できます。「エンティティ・オブジェクト」ページで、同一のエンティティ・オブジェクトを選択して関連元属性と関連先属性を指定し、ウィザードの他のすべてのデフォルト設定をそのままにします。アソシエーションの作成の詳細は、4.3項「アソシエーションの作成および構成」を参照してください。
たとえば、再帰的マスター/ディテール階層に、管理階層に基づく従業員のリストを表示するとします。このシナリオでは、Employeesエンティティ・オブジェクトに基づいてアソシエーションを作成します。「アソシエーションの作成」ウィザードの「エンティティ・オブジェクト」ページで、関連元属性としてEmployees.EmployeeIdを、関連先属性としてEmployee.ManagerIdを選択します。エンティティ・オブジェクトEmployeesによって両方の属性が指定されるため、このアソシエーションは自己参照型になります。
エンティティ・ベースのビュー・オブジェクトを作成し、階層の「ルート」に表示する行のみを含めるようにビュー・インスタンスの結果をフィルタリングするビュー基準を作成します。バインド変数を使用してビュー・オブジェクトをフィルタリングするビュー基準の作成の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
たとえば、管理者と従業員の再帰的階層で、エンティティ・ベースのビュー・オブジェクトEmployeesViewを作成します。アソシエーションの作成ウィザードでビュー・オブジェクトを作成したら、概要エディタの「問合せ」ページで、階層の最上部に表示する従業員を特定するバインド変数とビュー基準を作成します。階層のルートに表示する従業員を1人にする必要がある場合、このシナリオのビュー基準では、従業員ID(関連元属性に対応)のバインド変数を使用してフィルタリングすると、「ビュー基準の作成」ダイアログに表示されるWHERE句は、((Employees.EMPLOYEE_ID = :TheEmployeeId ))のようになります(TheEmployeeIdはバインド変数名)。バインド変数を使用してビュー・オブジェクトをフィルタリングするビュー基準作成の詳細は、5.12.2.1項「カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトの作成」を参照してください。
プロジェクトのデータ・モデルの従業員ビュー・オブジェクトを公開する準備ができたら、このビュー基準を使用してツリーのルートの最初の従業員をフィルタリングするように、データ・モデルのビュー・インスタンスを構成します。階層全体のルート値にする従業員の従業員IDを指定するバインド変数を構成します。たとえば、管理者と従業員の再帰的階層のルート値は、組織で最高レベルの管理者の従業員IDにします。
アソシエーション・ベースの自己参照型ビュー・リンクを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
ビュー・リンクの作成ウィザードでパッケージ名の入力を省略するには、アプリケーション・ナビゲータでlinksパッケージ・ノードのポップアップ・メニューから選択できる「新規ビュー・リンク」を選択します。
「新規ギャラリ」で、「ビジネス層」を展開し、「ADFビジネス・コンポーネント」を選択してから、「ビュー・リンク」を選択し、「OK」をクリックします。
ビュー・リンクの作成ウィザードの「名前」ページで、パッケージ名とコンポーネント名を指定します。
「ビュー・オブジェクト」ページの「ソース属性の選択」ツリーで、目的のパッケージのソース・ビュー・オブジェクトを開きます。「関連先属性の選択」ツリーで、リンク先ビュー・オブジェクトを開きます。
ビュー・オブジェクト属性の他にも、エンティティ・ベースのビュー・オブジェクトの場合、リストには関連するアソシエーションも表示されます。
ソースのツリーおよび宛先のツリーで同じアソシエーションを選択します。その後、「追加」をクリックして、次の表にアソシエーションを追加します。
たとえば、図5-30では、関連元のツリーおよび関連先のツリーの両方で同じEmpManagersFkAssocアソシエーションが選択されています。アソシエーションの定義で、同じエンティティ・オブジェクト(この場合はEmployees)上で関連元属性と関連先属性が指定されているため、このビュー・リンクは自己参照型です。
「ビュー・リンク・プロパティ」ページで、デフォルトの選択をそのままにしますが、関連先アクセッサのアクセッサ名を意味のわかりやすい名前に変更します。
たとえば、図5-31では、関連先アクセッサ名はEmployeesViewからStaffListに変更されています。この名前は、ユーザー・インタフェース開発者がこのアクセッサを選択してADF Facesツリー・コンポーネントを移入するときにバインディング・エディタで公開されます。ここで指定する名前により、UI開発者はこのアクセッサの目的(このケースでは、各管理者に関連付けられた従業員リストの生成)を理解します。
「終了」をクリックします。
既存のアプリケーション・モジュールにビュー・オブジェクト・インスタンスを定義するには:
アプリケーション・ナビゲータで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「データ・モデル」ナビゲーション・タブをクリックします。
「データ・モデル」ページで、「ビュー・オブジェクト・インスタンス」セクションを展開し、 「使用可能なビュー・オブジェクト」リストで、フィルタリング対象のビュー基準を定義したビュー・オブジェクト定義を選択します。
リストの下の「新規ビュー・インスタンス」フィールドに、データ・モデルに追加するビュー・オブジェクトの次のインスタンスを識別する際に使用される名前が示されます。
ビュー・オブジェクトを追加する前に名前を変更するには、「新規ビュー・インスタンス」フィールドに別の名前を入力します。
目的のビュー・オブジェクトを選択し、「データ・モデル」リストに移動します。
図5-32では、ビュー・オブジェクトEmployeesViewの名前をEmployeesに変更してから、「データ・モデル」リストに移動しています。
ビュー・オブジェクト・インスタンスをフィルタリングして階層のルート値を指定するには、追加したビュー・オブジェクト・インスタンスを選択し、「編集」をクリックします。
「ビュー・インスタンスの編集」ダイアログで、作成したビュー基準を「選択されたもの」リストに移動し、階層のルートに対応するバインド・パラメータ値を入力します。
図5-33は、ビュー・オブジェクトのByEmployeeIdビュー基準と、階層の最高レベルの従業員に対応する値100に設定されているバインド・パラメータTheEmployeeIdを示しています。
「OK」をクリックします。
自己参照型ビュー・リンクを作成する場合、JDeveloperでその宣言的設定を表すXMLコンポーネント定義ファイルが作成され、そのパッケージの名前に対応するディレクトリ内に保存されます。このXMLファイルには、選択したアソシエーションで指定した関連元属性と関連先属性のペアに関する宣言情報と、選択した関連元および関連先ビュー・オブジェクトを関連付けるアソシエーションに関する宣言情報が含まれます。
例5-9では、EmpManagerFkLinkのXMLコンポーネント定義ファイルで、関連元と関連先に同じビュー・オブジェクトEmployeesViewが定義されています。
例5-9 XMLで定義された自己参照型ビュー・リンク
<ViewLink
xmlns="http://xmlns.oracle.com/bc4j"
Name="EmpManagerFkLink"
Version="11.1.1.53.5"
EntityAssociation="test.model.EmpManagerFkAssoc">
<ViewLinkDefEnd
Name="EmployeesView1"
Cardinality="1"
Owner="test.model.EmployeesView"
Source="true">
<DesignTime>
<Attr Name="_finderName" Value="ManagerIdEmployeesView"/>
<Attr Name="_isUpdateable" Value="true"/>
</DesignTime>
<AttrArray Name="Attributes">
<Item Value="test.model.EmployeesView.EmployeeId"/>
</AttrArray>
</ViewLinkDefEnd>
<ViewLinkDefEnd
Name="EmployeesView2"
Cardinality="-1"
Owner="test.model.EmployeesView">
<DesignTime>
<Attr Name="_finderName" Value="DirectReports"/>
<Attr Name="_isUpdateable" Value="true"/>
</DesignTime>
<AttrArray Name="Attributes">
<Item Value="test.model.EmployeesView.ManagerId"/>
</AttrArray>
</ViewLinkDefEnd>
</ViewLink>
ビュー・リンク・コンポーネント定義自体が保存されるだけでなく、JDeveloperによりビュー・オブジェクトのXML定義も更新され、定義されたビュー・リンク・アクセッサに関する情報が追加されます。これを確認するため、「アプリケーション・ナビゲータ」でビュー・オブジェクトを選択し、「構造」ウィンドウでその詳細を検証できます。図5-34に示すように、定義済のアクセッサが、EmpManagerFkLinkビュー・リンクのEmployeesViewビュー・オブジェクトの「ビュー・リンク・アクセッサ」ノードに表示されます。
実行時に、ADFビジネス・コンポーネントとJDBCが連携して問合せをデータベースに渡し、その結果を取得する場合、データの取得にはSQL問合せが使用されます。設計時にSQL文を指定するビュー・オブジェクトを作成するかわりに、SQL文を含まないエンティティ・ベースのビュー・オブジェクトを作成することもできます。ADFビジネス・コンポーネントの設計時および実行時のこの機能は、宣言SQLモードと呼ばれます。データ・モデルの開発者がビュー・オブジェクト用のウィザードやエディタを宣言SQLモードで使用する場合は、SQLの知識は必要ありません。宣言SQLモードでは、ビュー・オブジェクトのメタデータに基づいて、次のようにADFビジネス・コンポーネント・ランタイムによりSQL問合せ文が生成されます。
オプションで、レンダリング済WebページのデータバインドされたUIコンポーネントで使用されている1つ以上のエンティティ・オブジェクトの属性に基づいて、SELECTリストおよびFROMリストを生成します。
実行時問合せ文を最適化するには、ビュー・オブジェクトの属性ごとに制御できるIsSelectedプロパティ設定を変更し、データバインドされたUIコンポーネントが使用する属性のみに基づくように指定します。デフォルトでは、宣言SQLモードでビュー・オブジェクトに追加した属性ごとに、このプロパティはIsSelected=trueに設定されています。このデフォルト設定では、データバインドされたコンポーネントによってUIに公開されるかどうかにかかわらず、追加された属性はSQL文で選択されます。実行時問合せ文最適化のためにプロパティ設定を変更する方法の詳細は、5.8.1項「宣言SQLモードでSQLに依存しないビュー・オブジェクトを作成する方法」を参照してください。
オプションで、ビュー・オブジェクト定義に追加するビュー基準に基づいてWHERE句を生成できます。
オプションで、ビュー・オブジェクト定義に追加するソート基準に基づいてORDER BY句を生成できます。
オプションで、ビュー・オブジェクト定義に追加する名前付きビュー基準に基づいて、表の結合がサポートされるようにWHERE句を拡張できます。
オプションで、ビュー・リンク定義のリンク元またはリンク先に追加するビュー基準に基づいて、マスター/ディテール・ビュー・フィルタリングがサポートされるようにWHERE句を拡張できます。
また、宣言SQLモードのビュー・オブジェクトによって実行時に生成されるSQL文は、「プロジェクト・プロパティ」ダイアログの「ビジネス・コンポーネント」ページで指定されるSQLスタイルによって決まります。
|
注意: 現在、ランタイムSQL生成用にサポートされているスタイルには、SQL92 (ANSI)およびOracleスタイルがあります。プロジェクトに使用するSQLスタイルの設定の詳細は、3.3.1項「接続、SQLスタイルおよび型マップの選択」を参照してください。 |
JDeveloperでは、宣言SQLモードをデータ・モデル・プロジェクト全体または作成した個々のビュー・オブジェクトに適用できる設定として選択できます。また、ADFビジネス・コンポーネント・デザインタイムでは、作成したビュー・オブジェクトについて、宣言SQLモードのプロジェクト・レベルの設定をオーバーライドできます。
宣言SQLモード以外には、標準モードとエキスパート・モードがあります。これらのモードを使用した場合、設計時に作成するビュー・オブジェクト定義には、常にアプリケーション・モジュールの定義済データベース接続に必要なSQLスタイルに基づいた、完全なSQL文が含まれます。そのため、SQLに依存しない機能は、標準モードまたはエキスパート・モードで作成したビュー・オブジェクトには適用されません。設計時にSQLが必要な場合にビュー・オブジェクトをカスタマイズするためのウィザードおよびエディタの使用に関する詳細は、5.2項「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
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モードをグローバル設定として有効化してビュー・オブジェクトの作成ウィザードのデフォルト・モードにすることも、この設定を無効にしたまま目的のモードをウィザードで直接選択することもできます。ビュー・オブジェクトのエディタでも、既存のビュー・オブジェクト定義に対するモードの選択や変更を行えます。
すべての新規ビュー・オブジェクトに対して宣言SQLモードを有効にするには:
メイン・メニューから、「ツール」→「プリファレンス」を選択します。
「設定」ダイアログで、「ビジネス・コンポーネント」ノードを展開し、「ビュー・オブジェクト」を選択します。
「ビジネス・コンポーネント: ビュー・オブジェクト」ページで、「新規オブジェクトの宣言SQLモードの有効化」を選択し、「OK」をクリックします。
実行時にFROMリストをどのように生成するかを事前に指定する場合は、「すべての属性を実行時生成問合せに含めます」を選択できます(5.8.4項「宣言SQLモードのビュー・オブジェクトに対する属性問合せを強制実行する方法」を参照)。
宣言SQLモードでエンティティ・ベースのビュー・オブジェクトを作成するには、「新規ギャラリ」から使用可能なビュー・オブジェクトの作成ウィザードを使用します。
作業を始める前に、次のようにします。
4.2.1項「既存の表から複数のエンティティ・オブジェクトおよびアソシエーションを作成する方法」の説明に従って、該当するエンティティ・オブジェクトを作成します。
宣言SQLベースのビュー・オブジェクトを作成するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「ビジネス層」を展開し、「ADFビジネス・コンポーネント」、「ビュー・オブジェクト」を選択して、「OK」をクリックします。
「名前」ページで、パッケージ名とビュー・オブジェクト名を入力します。デフォルト設定の「エンティティ・オブジェクトを介した更新可能アクセス」を有効のままにして、このビュー・オブジェクトとその基礎となるエンティティ・オブジェクトの連動によってデータを管理します。「次へ」をクリックします。
データ選択についてこれ以外を選択した場合、ビュー・オブジェクトの作成ウィザードでは宣言SQLモードは無効になります。
「エンティティ・オブジェクト」ページで、ビュー・オブジェクトでデータを使用するエンティティ・オブジェクトを選択します。「次へ」をクリックします。
エンティティ・オブジェクトを結合するビュー・オブジェクトを作成する場合は、セカンダリ・エンティティ・オブジェクトをリストに追加できます。より複雑なエンティティ・ベースのビュー・オブジェクトを作成する方法は、5.5.1項「エンティティ・ベースのビュー・オブジェクトに対する結合の作成方法」を参照してください。
「属性」ページで、「使用可能」リストからエンティティ・オブジェクトの慣用名の属性を少なくとも1つ選択し、それを「選択済」リストに移動します。選択しなかった属性は、ビュー基準およびソート基準には使用できません。「次へ」をクリックします。
(「属性の設定」ページで)属性をカスタマイズする場合、または(「問合せ」ページで)ビュー基準またはソート基準に属性を使用する場合は、それらの属性を選択します。また、実行時に生成される問合せのFROMリストに表示される表は、選択したエンティティ・オブジェクトの属性に対応する表に限定されます。
「属性の設定」ページでは、「属性の選択」ドロップダウン・リストを使用してビュー・オブジェクト属性を切り替え、名前や初期設定を変更できます。
「属性の選択」ドロップダウン・リストを使用して、以前に選択済のビュー・オブジェクト属性を切り替え、データバインドされたUIコンポーネントによってレンダリングされるかどうかのみに基づいてSQL文で選択する各属性の「問合せで選択済」の選択を解除します。「次へ」をクリックします。
デフォルトでは、宣言SQLモードで追加したすべてのオブジェクト属性の「問合せで選択済」チェックボックスが選択されています。このデフォルト設定により、追加されたすべての属性が選択された状態でSQL文が生成されます。属性のこのチェックボックスの選択を解除すると、IsSelectedプロパティがfalseに設定され、この属性が選択されるかどうかは、データバインドされたUIコンポーネントが使用する属性によって、実行時に決定されます。
「問合せ」ページの「問合せモード」ドロップダウン・リストで、「宣言」を選択します(表示されていない場合)。ウィザードにより、宣言SQLモードに変更されます。
「プリファレンス」ダイアログで「新規オブジェクトの宣言SQLモードの有効化」を選択していない場合、デフォルトの問合せモードの「標準」がウィザードに表示されます。ウィザードでモードを「宣言」に変更すると、このビュー・オブジェクトのみでデフォルト・モードをオーバーライドできます。
必要に応じて、データのフィルタリングや順序付けを行うためにWHERE基準およびORDER BY基準を定義します。実行時には、作成した基準に基づいて、対応するSQL文がADFビジネス・コンポーネントにより自動的に生成されます。
「WHERE」フィールドの横にある「編集」をクリックし、データのフィルタリングに使用するビュー基準を定義します。入力したビュー基準は、実行時にWHERE句に変換された上で問合せ文に適用されます。ビュー基準の指定の詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
「ORDER BY」フィールドで、「使用可能」リストから目的の属性を選択し、「選択」リストに移動します。選択しなかった属性は、実行時に生成されるSQLのORDER BY句には使用されません。結果を複数の列でソートする場合は、さらに他の属性を「選択済」リストに追加します。ソートの優先順位に従って、選択した属性をリスト内で並べ替えます。次に、それぞれのソート属性に対して、ソートを昇順で実行するか降順で実行するかを指定します。それぞれの属性にソート順序を指定すると、UIコンポーネントでは無視される属性に対して必要なソート順序が適用されます。
たとえば、図5-35に示すように、CustomerCardStatusビュー・オブジェクトに対して、CUSTOMERS表の行のうち特定のクレジット・カード・コードを持つ顧客の行のみが表示されるように制限するには、「WHERE」フィールドのビュー基準によって、CardTypeCode属性を実行時に決定される値に制限します。顧客IDおよび顧客のカードの有効期限を基準にデータを並べ替えるには、「ORDER BY」フィールドで、それらの属性を「選択済」リストに指定します。
「終了」をクリックします。
エンティティ・ベースのビュー・オブジェクトを作成する場合、ビュー・オブジェクト定義では複数のエンティティ・オブジェクトを参照できます。宣言SQLモードで作成するビュー・オブジェクトの場合、ベース・エンティティ・オブジェクトがビュー・オブジェクト定義からアクティブ化されるかどうかは、実行時におけるデータバインドされたUIコンポーネントの要件によって決まります。UIコンポーネントに複数のエンティティ・オブジェクトの属性値が表示される場合、実行時に生成されたSQLには、目的の表に対して問合せを行うためのJOIN演算子が含まれます。
作成する他のビュー・オブジェクトと同様に、名前付きビュー基準を適用すると、表結合から得られる結果をフィルタリングできます。標準モードのビュー・オブジェクトの場合、すべてのエンティティ・オブジェクトおよびその属性は、ビュー・オブジェクト定義により参照され、ビュー・オブジェクトのSQL文に自動的に取り込まれます。ただし、宣言SQLモードを使用する場合、実行時までSQLは生成されないため、ビュー基準が適用されるかどうかは判断できません。
|
注意: 宣言SQLモードでは、ビュー・オブジェクト定義を作成する際に、 |
SQL JOINは、常に宣言SQLモードで複数のエンティティ・オブジェクトを使用して定義されるビュー・オブジェクトから得られるとは限らないため、問合せ結果をフィルタリングするために定義した名前付きビュー基準を、実行時に条件付きで適用する必要があります。つまり、宣言SQLベースのビュー・オブジェクトに対して作成した名前付きビュー基準は、自動フィルタとして必ず適用する必要はありません。宣言SQLモードをサポートするため、宣言SQLモードで作成されたビュー・オブジェクトに対する名前付きビュー基準の適用は、そのビュー基準が参照する属性にUIコンポーネントがバインドされる場合に限定するよう設定できます。ただし、名前付きビュー基準が、一度適用されると、フィルタリングされた結果セットを表示するというUIコンポーネントの要件がサポートされます。
「ビュー基準の編集」ダイアログを使用して名前付きビュー基準を作成し、プロパティ・インスペクタでappliedIfJoinSatisfiedプロパティを設定してその条件付での使用を有効化します。
結合が要件を満たしている場合にのみフィルタリングするビュー基準を定義するには:
5.8.1項「宣言SQLモードでSQLに依存しないビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードを有効にしてビュー・オブジェクトを作成します。
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「ビュー基準」セクションを展開し、「新規ビュー基準の作成」ボタンをクリックします。
「ビュー基準の作成」ダイアログで、5.11.1項「名前付きビュー基準を宣言的に作成する方法」の説明に従ってビュー基準を作成します。
ビュー基準の作成後、概要エディタの「問合せ」ページにある「ビュー基準」セクションでそれを選択します。
ビュー基準を選択して「プロパティ・インスペクタ」を開き、AppliedIfJoinSatisfiedプロパティをtrueに設定します。
プロパティの値をtrueに設定すると、ビュー基準によって参照される属性がUIコンポーネントで必要になる場合のみ、ビュー基準が適用されます。デフォルト値のfalseでは、ビュー基準は実行時に自動的に適用されます。宣言SQLモード・ベースのビュー・オブジェクトの場合、値をtrueに設定すると、ビュー・オブジェクトのデータバインドされたUIコンポーネントの要件に応じて問合せフィルタが適用されます。
標準モードのビュー・オブジェクトを使用する場合と同様に、宣言SQLモードで作成したビュー・オブジェクトを他のビュー・オブジェクトにリンクし、任意の複雑さでマスター/ディテール階層を構成できます。ビュー・リンクの作成手順は、5.6.2項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」で説明した他のエンティティ・ベースのビュー・オブジェクトの作成手順と同じです。ただし、宣言SQLモードで作成するビュー・オブジェクトの場合、「ビュー・リンクの作成」ウィザードまたはビュー・リンク用の概要エディタで事前に定義されたビュー基準を選択すると、ビュー・リンクの「リンク元SQL」ダイアログまたは「リンク先SQL」ダイアログでビュー・オブジェクトの結果をさらに絞り込めます。
ビュー・リンクのリンク元またはリンク先に対してビュー基準を定義するには:
5.8.1項「宣言SQLモードでSQLに依存しないビュー・オブジェクトを作成する方法」の説明に従って、宣言SQLモードでビュー・オブジェクトを作成します。
ビュー・オブジェクトの概要エディタで、ソース(マスター)・ビュー・オブジェクトまたはリンク先(ディテール)ビュー・オブジェクトに対して、目的のビュー基準を定義します(5.8.2項「表結合が適用された場合に宣言SQLベースのビュー・オブジェクトをフィルタリングする方法」を参照)。
5.6.2項「エンティティ・ベースのビュー・オブジェクトに対するマスター/ディテール階層の作成方法」の説明に従ってビュー・リンクを作成し、次のいずれかの追加手順を実行します。
「SQLソース」ページで、事前に定義したビュー基準を選択して、マスター・ビュー・オブジェクトをフィルタリングします。「次へ」をクリックします。
「関連先SQL」ページで、事前に定義したビュー基準を選択して、ディテール・ビュー・オブジェクトをフィルタリングします。
図5-35は、顧客IDに基づいてマスター・ビュー・オブジェクトをフィルタリングするビュー基準を示しています。
ビュー・リンクを作成した後でも、事前に定義したビュー基準を選択できます。概要エディタのナビゲーション・リストで、「問合せ」を選択し、「ソース」セクションまたは「リンク先」セクションを展開します。「ビュー基準」ドロップダウン・リストで、目的のビュー基準を選択します。このビュー・オブジェクトに対するビュー基準が存在しない場合は、ドロップダウン・リストには何も表示されません。
概要エディタにビュー基準選択のドロップダウン・リストが表示されない場合、ビュー・リンクで選択したビュー・オブジェクトは宣言SQLモードで作成されていません。ビュー・オブジェクトを標準モードまたはエキスパート・モードで作成している場合は、必要に応じてWHERE句を編集してデータをフィルタリングする必要があります。
宣言SQLモードのビュー・オブジェクトを定義する場合、実行時に問合せが行われる属性は、通常、データバインドされたUIコンポーネントがWebページにレンダリングされる際の要件によって決まります。この実行時生成機能により、ビュー・オブジェクトを、設計時のデータベースのSQLスタイルに依存しないようにできます。ただし、このようなビュー・オブジェクトは、UIのADFデータ・バインディングに公開せず、プログラムによって実行が必要となる場合もあります。この場合、「すべての属性を実行時生成問合せに含めます」オプションを有効にすると、プログラムによって実行されたビュー・オブジェクトからすべてのエンティティ・オブジェクトへのアクセスを可能にできます。
|
注意: 「すべての属性を実行時生成問合せに含めます」オプションは、プログラムによって実行されるビュー・オブジェクトに対してのみ使用します。この設定を有効にしたビュー・オブジェクトをデータバインドされたUIコンポーネントに公開した場合、ランタイム問合せにはすべての属性が取り込まれます。 |
「すべての属性を実行時生成問合せに含めます」オプションは、グローバル設定として指定することも、個々のビュー・オブジェクトに対する設定とすることもできます。この2つの設定は、次のように組み合せて使用できます。
作成する各ビュー・オブジェクトですべての属性がランタイム問合せ文に取り込まれるようにグローバル設定を有効にします。
グローバル設定を有効にする一方で、プログラムにより実行されず、そのため一部の属性がランタイム問合せ文に取り込まれないビュー・オブジェクトに対しては設定を無効にします。
グローバル設定を無効(デフォルト)にする一方で、プログラムによって実行され、そのためすべての属性がランタイム問合せ文に取り込まれるビュー・オブジェクトに対しては設定を有効にします。
グローバル設定を有効にして問合せにすべての属性が取り込まれるようにするには:
メイン・メニューから、「ツール」→「プリファレンス」を選択します。
「設定」ダイアログで、「ビジネス・コンポーネント」を展開し、「ビュー・オブジェクト」を選択します。
「ビジネス・コンポーネント: ビュー・オブジェクト」ページで、「新規オブジェクトの宣言SQLモードの有効化」を選択します。
「すべての属性を実行時生成問合せに含めます」を選択して、ビュー・オブジェクトの基礎となるエンティティ・オブジェクトのすべての属性が問合せに強制的に取り込まれるようにし、「OK」をクリックします。
このオプションを有効にすると、ビュー・オブジェクト定義内にフラグが設定されますが、選択したエンティティ・オブジェクトおよびエンティティ・オブジェクトの属性をビュー・オブジェクト定義に追加する必要があります。
ビュー・オブジェクトの設定は、概要エディタの「一般」ページにある「チューニング」セクションで変更できます。すでにビュー・オブジェクトを宣言SQLモードで作成している場合、概要エディタには、「すべての属性を実行時生成問合せに含めます」オプションのみが表示されます。
ビュー・オブジェクト固有の設定によってすべての属性が問合せに取り込まれるようにするには:
特定のビュー・オブジェクトのすべての属性が強制的に取り込まれるようにする場合は、ビュー・オブジェクトの作成ウィザードでビュー・オブジェクトを作成し、宣言SQLモードが有効になっていることを確認します。
これは概要エディタで検証できます。概要エディタで、「問合せ」ナビゲーション・タブを選択し、ページ上部にある「SQL問合せの編集」ボタンをクリックします。「問合せの編集」ダイアログで、「SQLモード」ドロップダウン・リストに「宣言」が表示されていることを確認します。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
「一般」ページで、「チューニング」 セクションを展開し、「すべての属性を実行時生成問合せに含めます」を選択します。
このオプションを有効にすると、ビュー・オブジェクトの基礎となるエンティティ・オブジェクトのすべての属性が問合せに強制的に取り込まれます。このオプションを有効にすると、ビュー・オブジェクト定義内にフラグが設定されますが、選択したエンティティ・オブジェクトおよびエンティティ・オブジェクトの属性をビュー・オブジェクト定義に追加する必要があります。
宣言SQLモードでビュー・オブジェクトを作成する場合、SelectListFlags、FromListFlagsおよびWhereFlagsの3つのプロパティがビュー・オブジェクトのメタデータに追加されます。宣言SQLモードに含まれないプロパティは、標準モードのビュー・オブジェクトのプロパティSelectList、FromListおよびWhere(または、エキスパート・モードの場合はSQLQuery要素)で、これらには実際のSQL文が指定されます。例5-10は、宣言SQLモードで有効にされるビュー・オブジェクトのメタデータの3つのフラグを示したもので、これによりSQLは、ビュー・オブジェクト定義内のメタデータとして指定されるのではなく、実行時に生成されます。
例5-10 宣言SQLモードが有効になっている場合のビュー・オブジェクトのメタデータ
<ViewObject xmlns="http://xmlns.oracle.com/bc4j" Name="CustomerCardStatus" SelectListFlags="1" FromListFlags="1" WhereFlags="1" ...
標準モードまたはエキスパート・モードで作成するビュー・オブジェクトと同様、このビュー・オブジェクトのメタデータには、ビュー・オブジェクトの作成ウィザードの「属性」ページで選択した各属性に対するViewAttribute要素も含まれます。ただし、宣言SQLモードでは、ウィザードで属性を選択する場合(または概要エディタで属性を追加する場合)、設計時にはFROMリストまたはSELECTリストを作成しません。ビュー・オブジェクトのメタデータに含まれる属性定義では、実行時に生成される文に取り込まれる可能性のあるエンティティおよび属性のリストのみが決定されます。このようなADFビジネス・コンポーネントでのSQLリストの生成の詳細は、5.8.6項「実行時に行われる処理: 宣言SQLモードでのSQL生成時」を参照してください。
例5-11は、オプションの宣言WHERE句(DeclarativeWhereClause要素)およびオプションの宣言ORDER BY句(SortCriteria要素)を含む宣言SQLモードのビュー・オブジェクトの追加機能を示しています。
例5-11 ビュー・オブジェクト・メタデータ: 宣言的なビュー基準およびソート基準
<DeclarativeWhereClause>
<ViewCriteria
Name="CustomerStatusWhereCriteria"
ViewObjectName="oracle.fodemo.storefront.store.queries.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スタイルです。
JDeveloperを使用すると、データ・モデル・プロジェクトに新規に追加したすべてのビュー・オブジェクトや作成または編集した個々のビュー・オブジェクトに対して宣言SQLモードを制御できます。これらの設定は、次のように組み合せて使用できます。
「設定」ダイアログ(「ツール」→「設定」を選択)でグローバル設定を有効にします。この場合、作成した各ビュー・オブジェクトでのSQL生成は実行時まで行われません。図5-37は、「新規オブジェクトの宣言SQLモードの有効化」が有効にされているグローバル・プリファレンスを示しています。
「設定」ダイアログでグローバル設定を有効にしたまま、個々のビュー・オブジェクトに対するSQLモードを変更します。この場合、SQLモードを変更しないかぎり、作成したビュー・オブジェクトでのSQL生成は実行時まで行われません。
「設定」ダイアログでグローバル設定を無効(デフォルト)にしたまま、個々のビュー・オブジェクトに対して宣言SQLモードを選択します。この場合、SQLモードを変更しないかぎり、作成したビュー・オブジェクトにはSQL文が含まれます。
作成済のビュー・オブジェクトに対するSQLモードを編集する場合は、「問合せの編集」ダイアログの「問合せ」ページを開き、「SQLモード」ドロップダウン・リストから「宣言」を選択します。「問合せの編集」ダイアログを表示するには、概要エディタでビュー・オブジェクトを開き、ナビゲーション・リストから「問合せ」を選択して「SQL問合せの編集」ボタンをクリックします。このオプションは、ビュー・オブジェクトの作成ウィザードの「問合せ」ページにも表示されます。
開発者の便宜を考慮して、個々の属性の選択および選択解除は、ビュー・オブジェクト実装のAPIを介してプログラムにより実行できるようになっています。このAPIは、宣言SQLモードで作成してプログラムにより実行するビュー・オブジェクトと組み合せると有用な場合があります。例5-12は、SQLモードを有効にして構成済の属性に属性のサブセットを追加する場合に、ビュー・オブジェクトでselectAttributeDefs()をコールする方法を示しています。
例5-12 SQLモードのビュー・オブジェクトでのViewObjectImpl API
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に対して公開しないように注意してください。 |
エンティティ・ベースのビュー・オブジェクトを定義するとき、WHERE句とORDER BY句はすべてを指定できますが、デフォルトでは、FROM句とSELECTリストは自動的に導出されます。FROM句は関係するエンティティ・オブジェクトの慣用名に関連する表の名前から決定されますが、SELECTリストは次のものが基になります。
関係するエンティティ・マップ属性の基礎となる列名
SQL計算属性のSQL式
問合せでSELECT句またはFROM句を完全に制御する必要がある場合は、エキスパート・モードを有効にできます。
|
ヒント: JDeveloperのビュー・オブジェクト・エディタとウィザードでは、選択内容に応じたSQLの生成が完全にサポートされています。たとえば、そのような2つのオプションを使用すると、外部結合を宣言的に定義して、宣言SQLモード(実行時までSQLが生成されない)で作業することができます。 |
エキスパート・モードを有効にするには、ビュー・オブジェクトの作成ウィザードの「問合せ」パネルにある「SQLモード」ドロップダウン・リストから、「エキスパート・モード」を選択します。ビュー・オブジェクトの概要エディタで、既存のエンティティ・ベースのビュー・オブジェクトのSQL文を変更することもできます。概要エディタで「問合せ」ページにナビゲートし、「SQL問合せの編集」ボタンをクリックします。「問合せの編集」ダイアログで、「SQLモード」ドロップダウン・リストから「エキスパート・モード」を選択します。
SQL問合せに計算式が含まれている場合は、ビュー・オブジェクトの作成ウィザードで列に対してJavaに適した名前を指定する際、SQLの別名を使用します。例5-13は、計算式を含むSQL問合せを示しています。
例5-13 計算式を含むSQL問合せ
select PERSON_ID, EMAIL,
SUBSTR(FIRST_NAME,1,1)||'. '||LAST_NAME
from PERSONS
order by EMAIL
例5-14は、「ビュー・オブジェクトの作成」ウィザードで列に対してJavaに適した名前を指定する際にSQLの別名USER_SHORT_NAMEを使用した例です。ウィザードには、この計算式から導出された属性名としてUserShortNameが表示されます。
エキスパート・モードを有効にすると、「問合せ」ページにある読取り専用の「生成されたSQL文」セクションが、完全に編集可能な「問合せ文」テキスト・ボックスになり、SQL文全体が表示されます。このテキスト・ボックスを使用して、SQL問合せのすべての部分を変更できます。
たとえば、図5-38は、OrderItemsビュー・オブジェクトに対する、「問合せの編集」ダイアログの「問合せ」ページを示しています。これは、エキスパート・モードでのエンティティ・ベースのビュー・オブジェクトであり、ShippingCost属性に設定された式から入力値を取得するためのPL/SQLファンクションdecodeを参照します。
「問合せの編集」ダイアログでエキスパート・モードを使用してSQL問合せを定義する場合は、エディタに直接SQL言語文を入力します。このモードを使用する場合、ビジネス・コンポーネントの開発者は、ビュー・オブジェクトによって問合せ定義に基づくメタデータがどのように処理されるのかを理解しておく必要があります。この後の説明を通して、「問合せの編集」ダイアログをエキスパート・モードで使用する場合の操作方法を確認してください。
ビュー・オブジェクトと基礎になるエンティティ・オブジェクトの自動的な協調は、XMLコンポーネント定義に保存されている正確な属性マッピング・メタデータに依存します。この情報は、ビュー・オブジェクトの属性と、関係するエンティティ・オブジェクトの慣用名の対応する属性を関連付けます。この属性マッピング情報は、通常のエンティティ・ベースのビュー・オブジェクトについては完全に自動的に維持されます。しかし、ビュー・オブジェクトでエキスパート・モードを使用するときは、SELECTリストに対して行う変更に注意する必要があります。これは、SQL問合せの中で属性マッピングに直接関係する部分です。エキスパート・モードでも、SELECTリストに対して次のことを行うときは、JDeveloperが属性マッピング・メタデータの維持を引き続きある程度支援します。
列別名を変更しない式の並替え
JDeveloperによって、対応するビュー・オブジェクト属性の並替えおよび属性マッピングの維持が行われます。
新しい式の追加
JDeveloperによって、新しい式の列別名に基づいた対応名(頭文字が大文字表記)を持つ新しいSQL計算済ビュー・オブジェクト属性が追加されます。
式の削除
JDeveloperによって、その式に関連している対応するSQL計算済属性またはエンティティ・マップ済属性が一時属性に変換されます。
ただし、SELECTリストで列別名を変更した場合は、JDeveloperにはそれを検出する方法がなく、古い列式を削除して別の名前で新しい列式を追加したかのように扱われます。
問合せのSELECTリストを変更した後は、「属性マッピング」ページで、属性マッピング・メタデータが正しいことを確認してください。このページの表は、標準モードではビュー・オブジェクトに対しては無効になっていますが、エキスパート・モードのビュー・オブジェクトに対しては有効です。各ビュー・オブジェクト属性について、対応するSQL列別名を表で確認できます。「ビュー属性」列のセルをクリックすると、ドロップダウン・リストが表示され、エンティティ・マップ・ビュー属性が対応する必要のある適切なエンティティ・オブジェクト属性を選択できます。
|
注意: ビュー属性がSQL計算属性または一時属性の場合は、それを示す「SQL」アイコンの付いた対応する属性が「ビュー属性」列に表示されます。これらタイプの属性は基礎となるエンティティ・オブジェクトと関連していないため、エンティティ属性関連情報は必要ありません。 |
ビュー・オブジェクトに対するエキスパート・モードを無効にすると、SELECT句とFROM句は再び導出された状態に戻ります。その際、SQL文に対するカスタム編集が失われることを伝える警告が表示されます。失われてもかまわない場合は、この警告を確認すると、オブジェクトのSQL問合せがデフォルトに戻ります。
Productsビュー・オブジェクトで、SQL式がSUBSTR(NAME,1,10)と定義されたShortensという名前のSQL計算属性について考えます。このビュー・オブジェクトをエキスパート・モードに切り替えると、「問合せ文」ボックスに例5-15のようなSQL問合せが表示されます。
例5-15 エキスパート・モードでの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ではエキスパート・モードの問合せのテキストの 変更が試行されないためです。エキスパート・モードでは、開発者がすべてを制御します。JDeveloperは、開発者がエキスパート・モードのSQL文に対して行うある種の変更の結果としてメタデータの調節を試みますが、逆の処理は行いません。したがって、ビュー・オブジェクト・メタデータを変更しても、エキスパート・モードのSQL文はそれを反映するために更新されません。
したがって、エキスパート・モードのSQL文自体で式を更新する必要があります。完全に行うには、属性メタデータおよびエキスパート・モードSQL文の両方で変更する必要があります。これにより、後でエキスパート・モードを無効に切り替えることがあっても、自動的に導出されるSELECTリストに正しいSQL導出式が含まれるようになります。
|
注意: エキスパート・モードのビュー・オブジェクトのビュー・オブジェクト・メタデータを大量に変更する必要がある場合は、カスタマイズした問合せのテキストを一時バックアップ・ファイルにコピーすると、SQL文に対して及ぼす影響を手作業で変換する必要がありません。次に、ビュー・オブジェクトのエキスパート・モードを無効にし、変更が失われることを伝える警告を確認できます。この時点で、JDeveloperは新しく行われたメタデータの変更に基づいて、正しく生成されたSQL文を再び導出します。最後に、再度エキスパート・モードを有効にして、SQLのカスタマイズを再適用します。 |
エンティティ・マップ済属性に対応するSELECTリスト式を変更する場合は、データを取得する際に属性の値を変更するSQL計算をSQL文を導入しないでください。これを行った場合の問題を説明するため、Productsという名前の簡単なエンティティ・ベースのビュー・オブジェクトに対して、例5-16のような問合せについて考えます。
例5-16 SQL計算式のない問合せ文
SELECT Products.PROD_ID,
Products.NAME,
Products.IMAGE,
Products.DESCRIPTION
FROM PRODUCTS Products
製品の問合せの名前の先頭10文字のみを表示するよう、名前列を制限するものとします。これを行う正しい方法は、ShortNameなどのSUBSTR(Products.NAME,1,10)のような式の新しいSQL計算フィールドを導入することです。その上で避ける必要があるのは、例5-17に示すように、ビュー・オブジェクトをエキスパート・モードに切り替え、エンティティにマップされたNAME列のSELECTリストの式を変更して、SQL計算式を導入することです。
例5-17 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機能を導入したことが原因であると考えられます。例5-17では、導入したSUBSTR(Products.NAME,1,10)機能は、Name属性の選択された元の値を切り捨てます。行ロックSQL文は、NAME列の値を選択するときに、値全体を選択します。これにより例5-17の比較が失敗し、別のユーザーが行を変更した場合のようなエラーが発生します。
エキスパート・モードでSQL機能を適用し、エンティティ・マップ済属性に対して取得された値を切り捨てたり変更したりすると、NUMBER値やDATE値の属性でも同じことが発生します。
このため、エンティティ・マップ済データの変更されたバージョンを表示する必要がある場合は、適切な式を含む新しいSQL計算属性を導入して処理を行います。
ビュー・オブジェクトをエキスパート・モードに変更すると、そのXMLコンポーネント定義は、別のXML属性に問合せの一部を格納する状態から、問合せ全体を<SQLQuery>要素に保存する状態に変更されます。問合せはXML CDATAセクションにラップされて、複雑な問合せを理解しやすくするために開発者が行った可能性のある行の書式設定を保持します。
エキスパート・モードのビュー・オブジェクトには次のような場合があります。
設計時に「問合せ句」ページの「ORDER BY」フィールドで指定されているORDER BY句を含む場合
setWhereClause()またはsetOrderByClause()を使用して実行時に適用される動的なWHERE句またはORDER BY句を含む場合
このような場合、問合せは句を適用する前にインライン・ビューにネストされます。たとえば、エキスパート・モードの問合せが例5-18のように定義されているものとします。
例5-18 設計時に指定されたエキスパート・モードの問合せ
select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS union all select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_PERSONS
実行時に、email = :TheUserEmailのような追加のWHERE句を設定すると、ビュー・オブジェクトは元の問合せを例5-19のようにインライン・ビューにネストします。
例5-19 インラインにネストした問合せで実行時に生成された問合せ
SELECT * FROM( select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS union all select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_PERSONS) QRSLT
そして、ビュー・オブジェクトにより動的なWHERE句の条件が最後に追加され、データベースで確認される最終的な問合せは例5-20のようになります。
例5-20 動的なWHERE句で実行時に生成された問合せ
SELECT * FROM( select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from PERSONS union all select PERSON_ID, EMAIL, FIRST_NAME, LAST_NAME from INACTIVE_PERSONS) QRSLT WHERE email = :TheUserEmail
元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、エキスパート・モードの問合せの場合は一般にこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に単純に付加したのでは、予想外の結果が生成される可能性があります。たとえば、UNIONで結合された複数の文の最後の文にのみ適用される可能性があります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。
エキスパート・モードのビュー・オブジェクトはインライン・ビュー・ラッピングされるので、動的に追加されるWHERE句は、元の問合せのSELECTリストの列のみを参照できます。このような制限を回避する必要がある場合は、setNestedSelectForFullSql(false)を呼び出すことで、インライン・ビュー・ラッピングの使用を無効にできます。
ビュー・オブジェクトを含むビュー・リンクをすでに作成した後や、ビュー・オブジェクトを拡張する他のビュー・オブジェクトを作成した後に、そのビュー・オブジェクトの問合せをエキスパート・モードに変更すると、図5-39の警告が表示されます。この警告には、これらの依存コンポーネントでSQL文がまだ正しい問合せを反映していることを確認するよう示されます。
たとえば、エキスパート・モードが使用されるようにOrdersVOビュー・オブジェクトを変更する場合、そのビュー・オブジェクトはOrdersByStatusVOビュー・オブジェクトによって拡張されているため、変更された親コンポーネントの拡張が現在も論理的には問合せに反映されていることを、拡張されたコンポーネントで確認する必要があります。
バインド変数を使用すると、実行時にビュー・オブジェクトまたはビュー基準に属性値を組み込むことができます。バインド変数はすべて、ビュー・オブジェクトのレベルで定義され、次のいずれかの方法で使用されます。
バインド変数をビュー・オブジェクトの問合せのWHERE句に直接入力し、実行ごとに変更される値を組み込むことができます。この場合、バインド変数はSQL文字列内のプレースホルダとして機能し、SQL文字列自体のテキストを変更することなく、実行時に簡単にその値を変更できます。問合せは変更しないため、データベースでは、同一の解析済問合せ表現を複数の実行で効率的に再使用できるようになり、結果としてアプリケーションの実行時パフォーマンスが向上します。
ビュー・オブジェクトで開いた「ビュー基準の編集」ダイアログでは、バインド変数を選択リストから選択して、ビュー基準に使用する属性値を定義できます。この場合、バインド変数により、ビュー・オブジェクトの行セットのフィルタリングに使用する属性の値を変更できます。ビュー・オブジェクトの行セットのフィルタリングの詳細は、5.11項「名前付きビュー基準の処理」を参照してください。
シードされた検索でビュー基準を使用する場合は、エンド・ユーザーによるバインド変数を更新可能にできます。この更新可能オプションを使用する場合、エンド・ユーザーはビュー・オブジェクト問合せに対応する検索フォームに値を入力する必要があります。
WHERE句に追加するバインド変数には、実行時に有効な値を指定する必要があり、指定しないと実行時例外エラーが発生します。これに対し、バインド変数が割り当てられているビュー基準アイテムが必須でない場合、ビュー基準を実行する際にバインド変数の値は不要です。この動作を強制する場合、「バインド変数」ダイアログでバインド変数が必須かどうかを指定できます。
バインド変数に対しては、デフォルト値を定義するか、属性プロパティ値へのドット表記法によるアクセスが可能なスクリプト式を記述できます。式の記述には、Groovyスクリプト言語を使用します(3.6項「Groovyサポートの概要」を参照)。
名前付きバインド変数をビュー・オブジェクトに追加する場合は、そのビュー・オブジェクトの概要エディタにある「問合せ」ページを使用します。必要な数のバインド変数を定義できます。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
名前付きバインド変数を定義するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「バインド変数」セクションを展開して「新規バインド変数の作成」ボタンをクリックします。
「バインド変数」ダイアログで、新しいバインド変数の名前およびデータ型を入力します。
バインド変数はビュー・オブジェクト属性と同じネームスペースを共有するため、既存のビュー・オブジェクト属性名と競合しない名前を指定します。ビュー・オブジェクト属性と同様に、バインド変数名は最初が大文字という規則で作成されますが、必要に応じて名前を変更することもできます。
必要に応じて、バインド変数のデフォルト値を指定します。
実行時に式から値が決定されるようにするには、Groovyスクリプト言語の式を入力し、値タイプ「式」を選択して、「値」フィールドに式を入力します。必要に応じて、「編集」をクリックして「式」ダイアログを開きます。「式」ダイアログは、式を記述できる大きめのテキスト領域です。たとえば、5.10.2項「Groovyを使用して名前付きバインド変数で現在のユーザーを参照する方法」で説明されているように、現在のユーザーに基づいてビュー・インスタンスをフィルタリングするバインド変数を定義できます。
デフォルト値を定義する場合は、値のタイプ「リテラル」を選択し、「値」フィールドにリテラル値を入力します。
次のいずれかからバインド変数の実行時の使用方法を決定します。
SQLのWHERE句に含まれるバインド変数を使用して、値がその句に指定されるようにする場合は、「必須」チェック・ボックスを選択します。これにより、値が指定されない場合にはランタイム例外がスローされます。詳細は、5.10.8.2項「バインド変数の命名に関連するエラー」を参照してください。
ビュー基準のバインド変数を使用してその値をビュー基準に指定されるようにする場合、SQLのWHERE句で同一のバインド変数を参照する必要があるとき、またはビュー・オブジェクトに適用されるビュー基準によって必要に応じて定義されるビュー基準アイテムの割当て値としてバインド変数を使用するときにのみ、「必須」チェック・ボックスを選択してください。「必須」の選択が解除された場合、これによりこの値は任意になり、バインド変数が解決されない場合でも実行時例外はスローされません。たとえば、バインド変数が定義されているビュー基準は、ユーザー・インタフェースでQuery-By-Example検索フォームの作成に使用できます。詳細は、5.11項「名前付きバインド変数の処理」を参照してください。
「コントロール・ヒント」タブを選択し、「ラベル・テキスト」、「フォーマット・タイプ」、「フォーマット」マスクなどのコントロール・ヒントを指定します。
名前付きバインド変数の値を入力できる検索ページなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のコントロール・ヒントが使用されます。「更新可能」チェック・ボックスでは、エンド・ユーザーがユーザー・インタフェースを使用してバインド変数の値を変更できるようになるかどうかを制御します。バインド変数が更新可能でない場合、その値は開発者のみがプログラムで変更できます。
「OK」をクリックします。
バインド変数を定義した後、次のステップではそれらの変数をSQL文で参照します。SQL構文によりバインド変数がSELECTリストとWHERE句の両方に表示されるようになりますが、通常はWHERE句の一部としてバインド変数を使用します。たとえば、例5-21は、ビュー・オブジェクトの概要エディタの「問合せ」ページで作成したSQL文に導入されるLowUserIdおよびHighUserIdのバインド変数を示しています。
例5-21 ビュー・オブジェクトのSQL文の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
:TheNameや:LowUserIdなどのようにコロンを名前の前に付けることによって、SQL文でバインド変数を参照していることに注意してください。任意の順序でバインド変数を参照し、SQL文の中で必要な回数のみ繰り返すことができます。
Groovy式adf.context.securityContext.userNameを使用して、ビュー・インスタンス・フィルタの現在のユーザーの指定に使用する名前付きバインド変数のデフォルト値を設定できます。具体的には、プロジェクトのデータ・モデルのビュー・オブジェクト・インスタンスをフィルタリングするために定義する名前付きビュー基準で、バインド変数を使用できます。たとえば、Fusion Order DemoアプリケーションのStoreFrontモジュールでは、図5-40に示すように、名前付きバインド変数userPrincipalがPersonsVOビュー・オブジェクトに対して定義されています。
PersonsVOビュー・オブジェクトでは、AuthenticatedUserByPrincipalCriteriaビュー基準も定義されています。このビュー基準で定義されているPersonsVOのPrincipalName属性のフィルタには、バインド変数userPrincipalによって値が指定されます。この例では、バインド変数userPrincipalが定義され、「更新可能」が有効にされています。これにより、ビュー基準は、ADFセキュリティ・コンテキストから実行時に取得する値を設定できるようになります。バインド変数は、PersonsVOビュー・オブジェクトのSQLのWHERE句で使用されないため、「必須」フィールドの選択が解除されています。これによりこの値は任意になり、バインド変数が解決されない場合でも実行時例外はスローされません。
PersonsVOで慣用名AuthenticatedUserのビュー定義が指定されているStoreFrontServiceプロジェクトのデータ・モデルでは、名前付きバインド変数を含むビュー基準AuthenticatedUserByPrincipalCriteriaがビュー慣用名の実行時フィルタとして定義されています。プロジェクトのデータ・モデルのビュー・インスタンスの作成の詳細は、9.2.3.3項「アプリケーション・モジュールに追加するビュー・オブジェクト・インスタンスのカスタマイズ」を参照してください。
ビュー・オブジェクトに1つ以上の名前付きバインド変数を追加すると、これらの変数の値を実行時に簡単に参照および設定する機能を使用できます。各バインド変数の名前、型およびデフォルト値の情報は、ビュー・オブジェクトのXMLコンポーネント定義ファイルに保存されます。バインド変数に対してUIコントロール・ヒントを定義した場合、この情報は他のビュー・オブジェクトのコントロール・ヒントとともにビュー・オブジェクトのコンポーネント・メッセージ・バンドル・ファイルに保存されます。
ビジネス・コンポーネント・ブラウザでは、ビュー・オブジェクトに対する名前付きバインド変数の値を対話型で検査および変更することができ、名前付きバインド・パラメータを使用する場合にアプリケーション・モジュールのデータ・モデルを簡単に試すことができます。データ・モデルの編集およびビジネス・コンポーネント・ブラウザの実行に関する詳細は、6.3項「ビジネス・コンポーネント・ブラウザを使用したビュー・オブジェクト・インスタンスのテスト」を参照してください。
データ・ビュー・ページに結果を表示するために、ビジネス・コンポーネント・ブラウザでビュー・オブジェクトを初めて実行する場合、図5-41に示すように、「バインド変数」ダイアログが表示されます。
「バインド変数」ダイアログでは次のような操作が可能です。
リストから選択した特定のバインド変数の名前、デフォルト値および現在の値を表示します。
対応する「値」フィールドを更新してバインド変数の値を更新してから「OK」をクリックし、バインド変数値を設定して問合せを実行します。
ツールバーの「バインド・パラメータの編集」ボタン(アイコンが:idのように表示されます)を使用して、現在のデータ・ビュー・ページに表示されているビュー・オブジェクトに対するバインド変数を検査および設定します。
「バインド変数」リストにラベル・テキストを表示するか、それぞれのフォーマット・マスクを使用して「値」属性をフォーマットすることにより、コントロール・ヒントが正しく設定されていることを確認します。
「バインド変数」ダイアログでバインド変数を定義する際、「参照」チェック・ボックスの選択を解除すると(デフォルト)、ビュー基準をテストし、必要に応じてバインド変数に値を指定できます。一方、「参照」チェック・ボックスを選択した場合は、ビジネス・コンポーネント・ブラウザでバインド変数の値を1つ指定する必要があります。ビジネス・コンポーネント・ブラウザでは、SQL文で使用しているバインド変数の値の指定では解決されないビュー・オブジェクトに対しては、実行時と同じ例外がスローされます。
ビュー・オブジェクトのsetWhereClause()メソッドを使用して、実行時にフィルタリングの句をさらに追加できます。この実行時に追加されるWHERE句条件は、設計時に生成された条件のかわりに使用せずに、既存の設計時WHERE句に追加して問合せ結果をさらに絞り込みます。動的に追加された句が、アプリケーションの有効期間中に変化することのある値を参照するときは、WHERE句条件にリテラル値を連結するのではなく、常に名前付きバインド変数を使用してください。
たとえば、表のPERSON_TYPE_CODE列の値に基づいて実行時にビュー・オブジェクトPersonListをさらにフィルタリングすると仮定します。さらに、PERSON_TYPE_CODE = 'CUST'である行、またはPERSON_TYPE_CODE = 'SUPP'である行を検索する必要があると仮定します。コード行は少なくなりますが、同じPERSON_TYPE_CODE列の異なる2つの値を問い合せるためにWHERE句を2回変更するため、例5-22は好ましくありません。
例5-22 setWhereClause()メソッドの誤った使用
// Don't use literal strings if you plan to change the value!
vo.setWhereClause("person_type_code = 'CUST'");
// execute the query and process the results, and then later...
vo.setWhereClause("person_type_code = 'person'");
かわりに、例5-23のような、実行時に定義する名前付きバインド変数を参照するWHERE句条件を追加します。
例5-23 setWhereClause()メソッドおよびバインド変数の正しい使用
vo.setWhereClause("person_type_code = :ThePersonType");
vo.defineNamedWhereClauseParam("ThePersonType", null, null);
vo.setNamedWhereClauseParam("ThePersonType","CUST");
// execute the query and process the results, and then later...
vo.setNamedWhereClauseParam("ThePersonType","person");
これにより、問い合せる必要があるPERSON_TYPE_CODEの値にかかわらず、SQL文のテキストが同じままになります。問合せテキストが複数の実行全体で同じ状態の場合は、問合せの再解析を行わずに結果がデータベースから戻されます。
動的に追加されたWHERE句とバインド変数を後から削除する必要がある場合で、次にそれらを別のものにする必要がある場合は、問合せを実行する直前に削除する必要があります。これにより、5.10.8.1項「バインド変数のクリアに関連するエラー」で説明するような種類のSQL実行エラーを防止できます。WHERE句の設定直後は、コード内でremoveNamedWhereClauseParam()をコールしないでください。
これらのテクニックを示している更新済テスト・クライアント・クラスは、例5-24のようになります。この場合、結果を数回ループする機能は、別個のexecuteAndShowResults()メソッドにリファクタされています。プログラムでは、最初に付加的なWHERE句のperson_id = :ThePersonIdが追加されてから、後で第2句のperson_type_code = :ThePersonTypeに置換されます。
例5-24 名前付きバインド変数テクニックを実行するTestClientプログラム
package devguide.examples.readonlyvo.client;
import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
import oracle.jbo.domain.Number;
public class TestClientBindVars {
public static void main(String[] args) {
String amDef = "devguide.examples.readonlyvo.PersonService";
String config = "PersonServiceLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef,config);
ViewObject vo = am.findViewObject("PersonList");
// Set the two design time named bind variables
vo.setNamedWhereClauseParam("TheName","shelli%");
vo.setNamedWhereClauseParam("HighUserId", new Number(215));
executeAndShowResults(vo);
// Add an extra where clause with a new named bind variable
vo.setWhereClause("person_type_code = :ThePersonId");
vo.defineNamedWhereClauseParam("ThePersonId", null, null);
vo.setNamedWhereClauseParam("ThePersonId",new Number(116));
executeAndShowResults(vo);
vo.removeNamedWhereClauseParam("ThePersonId");
// Add an extra where clause with a new named bind variable
vo.setWhereClause("person_type_code = :ThePersonType");
vo.defineNamedWhereClauseParam("ThePersonType", null, null);
vo.setNamedWhereClauseParam("ThePersonType","SUPP");
// Show results when :ThePersonType = 'SUPP'
executeAndShowResults(vo);
vo.setNamedWhereClauseParam("ThePersonType","CUST");
// Show results when :ThePersonType = '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("PersonId")+" "+
curUser.getAttribute("ShortName"));
}
}
}
ただし、このテスト・プログラムを実行すると、実際には例5-25のような実行時エラーになることがあります。
例5-25 SQL解析エラーによるランタイム・エラー
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 = :ThePersonType) ## Detail 0 ## java.sql.SQLException: ORA-00904: "PERSON_TYPE": invalid identifier
PERSONS表にPERSON_TYPE_CODE列は確実に存在していますが、スタック・トレースの## Detail 0 ##の後に表示されている根本原因は、PERSON_TYPE_CODE列が存在しないというデータベースのレポートによるSQL解析エラーです。この問題は、ビュー・オブジェクトが読取り専用問合せの最初の部分で追加実行時WHERE句を適用するためにデフォルトで使用するメカニズムによって発生します。この問題の解決方法の詳細は、5.10.7項「実行時に行われる処理: 読取り専用ビュー・オブジェクトのWHERE句の設定時」を参照してください。
実行時に名前付きバインド変数を設定するには、ViewObjectインタフェース上でsetNamedWhereClauseParam()メソッドを使用します。JDeveloperで、「リファクタ」→「複製」を選択すると、既存のTestClient.javaクラスに基づいてTestClientBindVarsクラスを新規に作成できます(6.4.2項「コマンドラインJavaテスト・クライアントの作成方法」を参照)。このテスト・クライアント・クラスでは、数行の追加コードを使用して、バインド変数の値を設定できます。たとえば、setNamedWhereClauseParam()の引数として、バインド変数HighUserIdおよびTheNameを使用できます(例5-26を参照)。
例5-26 名前付きバインド変数の値をプログラムで設定
// changed lines in TestClient class
ViewObject vo = am.findViewObject("PersonList");
vo.setNamedWhereClauseParam("TheName","alex%");
vo.setNamedWhereClauseParam("HighUserId", new Number(315));
vo.executeQuery();
// etc.
テスト・クライアント・クラスを実行すると、バインド変数によるデータのフィルタリングが行われます。たとえば、例5-26のsetNamedWhereClauseParam()メソッドの結果行では、例5-27に示すように、alexという名前に基づく2つの一致のみ表示されます。
ビュー・オブジェクトの問合せが実行されるときは必ず、実行時デバッグ診断で、実際のバインド変数値が例5-28のサンプルように表示されます。
例5-28 バインド変数値を使用したデバッグ診断のサンプル
[256] Bind params for ViewObject: PersonList [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句を適用する前にインライン・ビューにネストされた状態になります。
たとえば、問合せが例5-29のように定義されたと仮定します。
例5-29 設計時に指定された問合せ
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
実行時に、例5-24のテスト・プログラムのようにperson_type_code = :ThePersonTypeのような付加的なWHERE句を設定する場合、例5-30のサンプルのように、フレームワークにより元の問合せがインライン・ビューにネストされます。
例5-30 インラインにネストした問合せで実行時に生成された問合せ
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句の条件が最後に追加され、データベースで確認される最終的な問合せは例5-31のサンプルのようになります。
例5-31 動的な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 = :ThePersonType
元の問合せが複雑で、SQLのUNION、INTERSECT、MINUSまたは複数の問合せを単一の結果に結合する他の演算子を含んでいる可能性があるため、通常はこのような問合せのラッピングが必要です。このような場合、実行時に追加のWHERE句を問合せテキストの最後に付加するだけでは、予想外の結果が生成される可能性があり、たとえば、UNIONで結合された複数の文の最後の文に対してのみ適用されることがあります。元の問合せをそのままインライン・ビューにネストすることで、ビュー・オブジェクトは、元の問合せがどれほど複雑であっても、元の問合せの結果をフィルタ処理するために追加のWHERE句が正しく使用されることを保証します。重要なのは、動的に追加されるWHERE句が、元の問合せで選択されている列しか参照できないことです(ORA-00904エラーにつながります)。
これを解決する最も簡単な方法は、「問合せの編集」ダイアログで、(ビュー・オブジェクトの概要エディタの「問合せ」ページで「SQL問合せの編集」ボタンをクリックして)問合せのSELECTリストの末尾に動的問合せの列名を追加することです。既存のSELECTリストの末尾にカンマを前に付けた新規の列名を追加するだけで、ORA-00904エラーを回避することができ、JDeveloperでは、問合せ文と同期して自動的にビュー・オブジェクトの属性リストが保持されます。または、このような問合せのネストが不要な場合に無効にする方法は、5.9.4.7項「実行時のインライン・ビュー・ラッピングの制限」を参照してください。
名前付きバインド変数について知っておく必要のあることがいくつかあります。これには、バインド変数の名前が不一致である場合に表示される実行時エラー、バインド変数のデフォルト値などがあります。
実行時にビュー・オブジェクト・インスタンス設定の能動化および受動化で使用できるように、アプリケーションでバインド変数の値の変更が正しく処理されるようにする必要があります。たとえば、アプリケーションをデプロイする前には、40.10項「アプリケーション・モジュールの能動化が安全であることの確認テスト」で説明するように、アプリケーション・モジュールのプーリングを無効にして、JDeveloperでアプリケーションのストレス・テストを実施する必要があります。該当のセクションの指示に従うと、最終的にアプリケーションをデプロイするときに、アプリケーションでの受動化ストアの管理方法を効果的にシミュレートできます。
同じユーザー・セッション中の後続のリクエスト時に受動化ストアから保留中の状態が再能動化されると、アプリケーションは動的に追加された名前付きWHERE句のバインド変数の値の設定を試みます。受動化が実行される前に値をNULLに変更すると、ビュー・オブジェクトの最後の実行時にバインド変数の値が一致しなくなり、能動化中に次のエラーが発生します。
(oracle.jbo.SQLStmtException) JBO-27122: SQL error during statement preparation. (java.sql.SQLException) Attempt to set a parameter name that does not occur in SQL: 1
ビュー・オブジェクトの実行直後には、バインド変数(またはビュー・オブジェクト・インスタンスの設定)の値を変更しないでください。同じコード・ブロック中(同じHTTPリクエスト中)にビュー・オブジェクトを再実行しない場合は、むしろ、次に変更する必要が生じるまで(問合せを実行する直前まで)ビュー・オブジェクト・インスタンスのバインド変数値を遅延するようにしてください。そのためには、次のパターンを使用します。
(リクエストを開始し、アプリケーション・モジュールが取得される。)
setWhereClause(null)をコールしてWHERE句をクリアする。
setWhereClauseParam(null)をコールしてWHERE句バインド変数をクリアする。
nバインド変数を参照するsetWhereClause()をコールする。
setWhereClauseParams()をコールして、nバインド変数のn値を設定する。
executeQuery()をコールする。
(アプリケーション・モジュールが解放される。)
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内の名前付きバインド変数のリストが、ビュー・オブジェクトの概要エディタにある「問合せ」ページの「バインド変数」セクションの名前付きバインド変数のリストと一致していることを再度確認します。さらに、バインド変数に対する「バインド変数」ダイアログを開き、「参照」チェック・ボックスの選択が解除されていないこと(デフォルト)を確認します。SQL文でバインド変数を使用する場合は、「参照」チェック・ボックスを選択する必要があります。
名前付きバインド変数にデフォルト値を適用しない場合、変数は実行時にNULL値にデフォルト設定されます。つまり、次のようなWHERE句を持つ場合です。
PERSON_ID = :ThePersonId
このとき、バインド変数ThePersonIdにデフォルト値を指定しない場合は、デフォルトでNULL値になるように設定され、これが問合せから行が戻されない原因になります。アプリケーションとって意味を持つ場合は、必要に応じて状況に対処するために、NVL()、CASE、DECODE()などのSQL関数やその他の関数を活用できます。たとえば、次のようなWHERE句のフラグメントを使用すると、:TheNameの値がnullの場合、ビュー・オブジェクトの問合せに対してすべての名前が一致します。
upper(FIRST_NAME) like upper(:TheName)||'%'
ビュー基準の定義により、ビュー・オブジェクト・コレクションの行に関するフィルタ情報を指定できます。ビュー基準オブジェクトは1つ以上のビュー基準行の行セットであり、この属性によってビュー・オブジェクト内の属性がミラーリングされます。ビュー基準の定義には、ターゲット・ビュー・オブジェクトのWHERE句を拡張するための問合せ条件が含まれています。指定した問合せ条件は、ターゲット・ビュー・オブジェクトの個々の属性に適用されます。
問合せ結果のビュー・オブジェクト行とビュー基準行との主な違いは、ビュー基準行の各属性のデータ型がStringである点にあります。この違いによってQuery-by-Example演算子がサポートされ、そのため、ユーザーはOrderId > 304などの条件を入力できます。
「ビュー基準の編集」ダイアログでは、ビュー基準を作成し、それをビュー・オブジェクト定義の一部として保存すると、名前付きビュー基準として表示されます。特定のビュー・オブジェクトに対してビュー基準を定義する場合は、概要エディタの「問合せ」ページを使用します。
さらに、ビュー基準ではAPIが完全にサポートされているため、ビュー基準の作成およびビュー・オブジェクトへの適用をプログラムによって実行できます。
個々のビュー・オブジェクト結果をフィルタリングする必要がある場合、名前付きビュー基準定義を作成します。設計時に定義するビュー基準は、実行時に結果のフィルタリングが必要となる次のようなシナリオで使用されます。
ターゲット・ビュー・オブジェクトの属性に対するエンド・ユーザーによる値の指定を可能にするQuery-by-Example検索フォームをサポートする場合。
たとえば、エンド・ユーザーは、顧客名の値および日付を入力することによって、CustomerOrdersビュー・オブジェクトの行が表示されるWebページで結果をフィルタリングできます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示される名前付きビュー基準を基に、検索フォームを容易に作成できます。「データ・コントロール」パネルに表示される名前付きビュー基準の利用方法の詳細は、27.2項「問合せ検索フォームの作成」を参照してください。
エンド・ユーザーが(UIにLOVコンポーネントとして表示される)1つの属性リストから選択できる値リスト(LOV)コンポーネントをフィルタリングする場合。
Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示されるビュー・オブジェクトの属性を基に、LOVコントロールを容易に作成できます。「データ・コントロール」パネルに表示されるLOV有効属性の利用方法の詳細は、25.3項「選択リストの作成」を参照してください。
ビュー・アクセッサ結果のフィルタリングのため、ビュー基準が適用されているビュー・アクセッサを使用して属性値を検証する場合。
ビュー・アクセッサ・バリデータの作成の詳細は、10.4.2項「ビュー・アクセッサに対する検証方法」を参照してください。
ビュー・インスタンスごとに一意のビュー基準が適用されている単一のビュー・オブジェクト定義からアプリケーション・モジュールのデータ・モデルを作成する場合。
ビュー基準によって変更される単一のビュー・オブジェクトの問合せは、アプリケーション全体で共有する必要がある参照データで有効です。この場合は、ベース・ビュー・オブジェクトの定義によってデータベース内の参照表に対して問合せが行われ、ビュー基準によって参照表のTYPE列が設定され、これによってアプリケーション固有のビューが定義されます。ベース・ビュー・オブジェクトの定義に対して作成するビュー基準を使用してデータ・モデル内にビュー・インスタンスを定義する方法は、10.3.3項「ビュー基準を使用した検索ビュー・オブジェクトのWHERE句の定義方法」を参照してください。
フィルタリングするビュー・オブジェクトに対してビュー基準を定義するには、概要エディタでそのビュー・オブジェクトを開き、「問合せ」ページの「ビュー基準」セクションを使用します。「ビュー基準」セクションから開く専用のエディタでは、WHERE句を作成する際、ターゲット・ビュー・オブジェクトの対応するSQL列名ではなく、属性名を使用できます。名前付きビュー基準は、1つのビュー・オブジェクトに対して複数定義できます。
ビュー基準の定義はそれぞれ、次の要素で構成されています。
1つ以上のビュー基準行。ビュー基準行は、任意の数のビュー基準グループ、または現在のビュー・オブジェクトに対して定義されている別の名前付きビュー基準への任意の数の参照で構成されます。
任意の数のビュー基準アイテムで構成される、オプションのビュー基準グループ。
属性名、属性に適した演算子、およびオペランドで構成されるビュー基準アイテム。オペランドには、フィルタの値が定義されている場合はリテラル値か、または、属性のプロパティ値へのドット表記アクセスを含むスクリプト式がオプションで利用可能なバインド変数を使用できます。
式の記述には、Groovyスクリプト言語を使用します(3.6項「Groovyサポートの概要」を参照)。
ビュー基準を定義する場合は、フィルタリングされた結果のソースを制御します。フィルタリングされたビュー・オブジェクトの結果は、次のいずれかに制限できます。
ビュー・オブジェクトにより指定されたデータベース表のみ。
ビュー・オブジェクト問合せのメモリー内の結果のみ。
データベースおよびビュー・オブジェクト問合せのメモリー内の結果の両方。
データベース表とビュー・オブジェクトのメモリー内の結果の両方でフィルタリングを実行する場合、トランザクションで作成されており、データベースのコミット前である行もフィルタリングできます。
「ビュー基準の編集」ダイアログで作成するビュー基準の式では、論理積により、選択した基準アイテム(または基準グループ)とその前にあるアイテム(またはグループ)を式の中でどのように結合するかを指定できます。
AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれのビュー基準アイテムを追加する場合は、この結合がデフォルトになります。
OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。ビュー基準グループに対しては、この結合がデフォルトになります。
また、ビュー・リンクされたディテール・ビューに対する基準に基づいて現在のビュー・オブジェクトの行をフィルタリングする場合は、ネストされたビュー基準を作成できます。ネストされたビュー基準グループは、任意の数のネストされたビュー基準アイテムで構成されます。ネストされたビュー基準を使用すると、様々なビュー基準アイテムの論理積をより詳細に制御できます。ネストされた基準では、その親ビュー基準グループの中で基準を満たしている行が制限されます。たとえば、給与がSalary > 3000という基準を満たし、かつ所属部署がDeptNo = 10またはDeptNo = 20という基準を満たしている従業員のリストを問い合せる場合があります。この場合、1つの項目Salary > 3000を含む第1のグループを使用してビュー基準と、2つの項目DeptNo = 10およびDeptNo =20を含む第2のグループを使用してネストされたビュー基準を定義できます。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
ビュー基準がオペランドでバインド変数を使用する場合、5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」に従ってバインド変数を作成します。
名前付きビュー基準を定義するには:
アプリケーション・ナビゲータで、名前付きビュー基準を作成するビュー・オブジェクトをダブルクリックします。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「ビュー基準」セクションを展開し、「新規ビュー基準の作成」ボタンをクリックします。
「ビュー基準の作成」ダイアログで、ビュー基準の名前を入力し、アプリケーション内での用途を識別できるようにします。
「問合せ実行モード」ドロップダウン・リストで、ビュー基準によってビュー・オブジェクトの問合せ結果をどのようにフィルタリングするかを決定します。
フィルタリングのビュー基準は、ビュー・オブジェクト問合せにより指定されたデータベース表、問合せにより生成されたメモリー内の行セット、またはデータベース表とメモリー内の結果の両方に制限できます。
適用したアソシエーションの一貫性の結果として作成された行を含める場合は、「両方」を選択することが適切です。この場合は、最初のフェッチの後にメモリー内フィルタリングが実行されます。
ビュー基準を定義するには、次のいずれかの追加ボタンを選択します。
単一の基準アイテムを追加するには、「アイテムの追加」を選択します。エディタによって、現在のグループまたは選択したビュー基準の下の階層にアイテムが追加されます。デフォルトでは、アイテムを追加するたびに、エディタによって次の属性が選択され、基準アイテムが定義されます。属性は、ビュー・オブジェクト問合せで定義されている属性に変更できます。
新しいグループを追加して、構成する基準アイテムをそのグループに追加するには、「グループの追加」を選択します。新しいグループを追加すると、エディタによって階層にOR結合が挿入されます。この結合は必要に応じて変更できます。
定義するビュー基準を追加するには、「基準の追加」を選択します。この選択は、ビュー・オブジェクト定義にすでに存在する名前付き基準を追加するかわりになります。新しいビュー基準を追加すると、エディタによって階層にAND結合が挿入されます。この結合は必要に応じて変更できます。別のビュー基準を追加するたびに、階層で現在選択しているビュー基準の下に新しいビュー基準がエディタによってネストされます。階層のルート・ノードでは、現在編集中の名前付きビュー基準が定義されます。
UIデザイナによりビュー基準から作成される検索フォームでは、直接ネストされたビュー基準を使用できません。検索フォームで使用するネストされた式の定義の詳細は、5.11.4項「ネストされた式について」を参照してください。
ビュー・オブジェクトで定義されているビュー基準を追加するには、「名前付き基準の追加」を選択します。名前付き基準は、ビュー基準を定義しているビュー・オブジェクトの概要エディタに表示される必要があります。
ビュー基準階層のビュー基準アイテム・ノードを選択し、追加したノードを「基準アイテム」セクションで定義します。
基準アイテムで、必要な「属性」を選択します。デフォルトでは、リストの最初のノードがエディタによって追加されます。
現在編集中のビュー・オブジェクトにビュー・リンクが存在する場合は、必要に応じて、ネストされたビュー基準をインラインで追加できます。リンク先ビュー・オブジェクトの名前は、「属性」ドロップダウン・リストに表示されます。ビュー・オブジェクトを選択すると、ビュー・リンクの関係に従ってネストされたビュー基準のビュー基準アイテムに基づいて、ビュー基準をフィルタリングできます。たとえば、AddressVOがPaymentOptionsVOにリンクされており、PaymentOptionsVOのビュー基準定義に、リンク先ビュー・オブジェクトのAddressVOが表示されるとします。図5-42に示すように、ネストされたビュー基準を定義することにより、CustomerId基準アイテムで指定した現在の顧客のCountryId属性に基づいて、支払いオプションをフィルタリングできます。
必要な「演算子」を選択します。
リストには、選択した属性またはビュー・オブジェクトに適切な演算子のみが表示されます。ビュー・オブジェクトの場合、exists演算子はオペランドとして定義(または参照)するビュー基準に適用されます。 String型およびDate型属性の場合、「次の間にある」および「次の間にない」演算子では、範囲を定義するために2つのオペランド値を指定する必要があります。Date型属性の場合、日付または日付の範囲をテストする演算子を選択できます(YYYY-MM-DDの書式で入力された日付値について)。たとえば、2010年12月16日の場合、2010-12-16と入力します。
JDeveloperでは、IN演算子をサポートしていません。ただし、5.11.7項「プログラムによるビュー基準の作成方法」で説明するように、APIを使用すると、IN演算子でビュー基準を作成できます。
選択したビュー基準アイテムで、必要な「オペランド」を選択します。
属性に値を指定したり、Query-by-Example検索フォームに対するユーザー指定の検索フィールドにデフォルト値を定義する場合は、「リテラル」を選択します。ビュー基準でユーザー・インタフェースの問合せ検索フォームを定義する場合は、「値」フィールドが空のままでも構いません。この場合は、ユーザーが値を指定します。検索フィールドのデフォルト値として機能する値を指定して、ユーザーが上書きできるようにすることもできます。「値」フィールドに指定する値には、ワイルドカード文字の*または%を含めることができます。
バインド変数を使用して実行時に値を決定する場合は、「バインド変数」を選択します。ビュー・オブジェクトに対して変数がすでに定義されている場合は、「パラメータドロップダウン・リストからその変数を選択します。定義されていない場合は、「新規」をクリックして「バインド変数」ダイアログを表示し、そこでビュー・オブジェクトに対するバインド変数を新規に作成します。バインド変数の作成の詳細は、5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」を参照してください。
ビュー・オブジェクトに対してビュー基準に使用するバインド変数を定義する場合は、ビュー・オブジェクトで定義されるSQL問合せで、そのバインド変数が必須にならないよう指定する必要があります。そのためには、「バインド変数」ダイアログの「必須」チェック・ボックスの選択を解除します(5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」を参照)。
ビュー基準でバインド変数とリテラルを使用するケースの詳細は、5.11.3項「バインド変数オプションについて」を参照してください。
定義する各アイテム、グループまたはネストされたビュー基準に対して、必要に応じてデフォルト設定の論理積を変更し、アイテムの結合方法を指定します。
AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれのビュー基準アイテムまたはネストされたビュー基準を追加する場合は、この結合がデフォルトになります。
OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。ビュー基準グループに対しては、この結合がデフォルトになります。
次のいずれかを実行して、ビュー基準の定義が有効かどうかを検証します。
「実行計画」をクリックし、生成されたビュー基準のWHERE句を視覚的に検証します。
「テスト」をクリックし、JDeveloperでWHERE句が有効かどうかを検証します。
実行時に指定される値の大/小文字の区別で属性がフィルタリングされないようにするには、「大/小文字を区別しない」を選択したままにします。
基準アイテムには、定義したリテラル値またはエンド・ユーザーが入力するランタイム・パラメータを使用できます。このオプションは、String型の属性に対してのみサポートされています。デフォルトでは、大/小文字の区別のある検索は使用できません。
「検証」ドロップダウン・リストで、生成されたWHERE句での属性値の比較の際にビュー基準アイテムを必須とするかオプションとするかを指定します。
「選択的に必須」を選択すると、ビュー基準アイテムに基準値が入力されず、かつ基準値を持つ基準アイテムが同じレベルに少なくとも1つ存在する場合、WHERE句では実行時にそのビュー基準アイテムが無視されます。それ以外の場合は例外がスローされます。
「オプション」を選択すると、値がNULLでない場合にのみビュー基準がWHERE句に追加されます。新規の各ビュー基準アイテムに対してデフォルトの「オプション」を選択すると、NULL値に対しても例外は生成されません。
「必須」を選択すると、基準アイテムに値が入力されなかった場合は、WHERE句が実行されず例外がスローされます。
ビュー基準でオペランドとしてバインド変数を使用する場合に、IS NULL条件がWHERE句で生成されるかどうかを指定します。バインド変数の検証に「オプション」を選択した場合のみ、このフィールドが有効になります。
実行時にバインド変数値が入力されていない場合でもビュー基準が結果を返すようにする場合、「Null値の無視」を選択したままにしておきます(デフォルト)。たとえば、子リストの制御属性としてcountryIDを取得するバインド変数を通じて、ユーザーが国と州(または郡)のカスケード・リストを表示できるようにするビュー基準を定義するとします。この場合、ビュー基準実行のデフォルトの動作では、ユーザーが親LOVで選択を行わない(countryIdフィールドが空)と、すべての州のリストが戻されます。生成されたWHERE句は、(((CountryEO.COUNTRY_ID =:bvCountryId) OR (:bvCountryId IS NULL)))のようになります(null値のテストにより、バインド変数が設定されない場合でも、子リストに結果が表示されることが保証されます)。検証が「必須」またはオプションで必須に設定されている場合、ビュー基準は値を必要とするため、このnull値を無視するオプションは無効になります。
実行時にバインド変数値が入力されない場合にビュー基準がnullの結果を返すようにする場合、「Null値の無視」の選択を解除します。カスケード・リストの例の場合、ビュー基準実行では、ユーザーが選択を行わなずcountryIdフィールドが空だと、州は戻されません。このケースでは、生成されたWHERE句は、((CountryEO.COUNTRY_ID=:bvCountryId))のようになります(null値のテストは行われず、問合せはnull値のバインド変数で正常に動作します)。
検証の設定が「必須」またはオプションで必須の場合、null値の条件も削除されますが、別の使用方法をサポートします。必要な実行時の動作を実現するために、「Null値の無視」機能と組み合せて使用する必要があります。これらの機能の詳細は、5.11.3項「バインド変数オプションについて」を参照してください。
「OK」をクリックします。
JDeveloperの 「ビュー基準の作成」ダイアログで、ビュー基準を簡単に作成し、名前付き定義として保存できます。これらの名前付きビュー基準定義により、ターゲット・ビュー・オブジェクトの宣言設定を表すXMLコンポーネント定義ファイルにメタデータが追加されます。定義すると、名前付きビュー基準はビュー・オブジェクトの概要エディタの「問合せ」ページに名前で表示されます。
ビュー基準を表示するには、アプリケーション・ナビゲータで目的のビュー・オブジェクトを展開し、展開されたビュー・オブジェクトのXMLファイルを選択して、構造ウィンドウを開き、「ビュー基準」ノードを展開します。ビュー・オブジェクトのそれぞれのビュー基準定義には、「ビュー基準の作成」ダイアログで定義したグループの数に対応する、1つ以上の<ViewCriteriaRow>要素が含まれます。図5-33は、<ViewCriteria>定義のFindByProductNameCriteriaと、開発者がシードした製品の検索をバインド変数:bvProductNameを使用して定義する単一の<ViewCriteriaRow>を含むProductsVO.xmlファイルを示しています。開発者シード検索の動作をカスタマイズするためにユーザーが選択したコントロール・ヒントは、<ViewCriteria>定義に<CustomProperties>要素の属性として表示されます。ビュー基準のコントロール・ヒントの詳細は、5.11.5項「ビュー基準にユーザー・インタフェース・ヒントを設定する方法」を参照してください。
例5-33 ProductsVOビュー・オブジェクト定義のFindByProductNameCriteriaビュー基準
<ViewObject
xmlns="http://xmlns.oracle.com/bc4j"
Name="ProductsVO"
... >
<SQLQuery>
...
</SQLQuery>
...
<ViewCriteria
Name="FindByProductNameCriteria"
ViewObjectName="oracle.fodemo.storefront.store.queries.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により、アプリケーション・モジュールに含まれるコレクション(ビュー・インスタンス)をカプセル化するデータ・コントロールが自動的に作成されます。次に、これらのコントロールと定義済のビュー基準が「データ・コントロール」パネルに移入されます(12.2.1.3項「「データ・コントロール」パネルでのビュー・オブジェクトの表示」を参照)。
バインド変数を使用して定義したビュー基準フィルタは、実行時にその値を取得します。この機能は、様々なユーザー・インタフェース・シナリオで有益です。特定の使用例をサポートできるように、表5-1に示した「検証」および「Null値の無視」設定の組合せを覚えるようにしてください。
表5-1 ビュー基準のバインド変数オプションの使用例
| 検証 | Null値の無視 | 使用例 | メモ |
|---|---|---|---|
|
|
|
親LOV値がオプションのカスケード値リスト(LOV)を構成します。 検索フォームのオプション検索フィールドを生成します。 |
この組合せでは、SQL問合せ カスケードLOVで使用する場合、親LOVが選択されないと子LOVのすべての行が戻されます。 オプションの検索フィールドには、オペランド・タイプがリテラルのビュー基準アイテムが推奨されます。 |
|
|
|
親LOV値が必須のカスケードLOVを構成します。 |
この組合せでは、SQL問合せ カスケードLOVで使用する場合、親LOVが選択されないと子LOVの行が戻されません。 ユーザーが検索フィールドを空白のままにすると、検索ではこのフィールドが明示的にnullに設定されている行を見つけようとするため、検索フォームではこの組合せを使用しないでください。これを行うには、詳細検索モードで「IS NULL」演算子を明示的に選択するほうが効率的です。 |
|
|
|
検索フォームの必須検索フィールドを生成します。 |
この組合せでは、SQL問合せ 親LOVが選択されない場合、検証エラーが発生するため、カスケードLOVに対してこの設定を使用しないでください。 必須の検索フィールドには、(バインド変数でなく)オペランド・タイプがリテラルのビュー基準アイテムが推奨されます。 |
ビュー基準からUIデザイナによって作成される検索フォームでは、すべてのタイプのネストされた式が動作するわけではありません。特に、検索フォームでは、直接ネストされたビュー基準が含まれる式がサポートされていません。このタイプのネストされた式では、1つのビュー基準を別のビュー基準の直接の子として定義します。それ自体がビュー基準の子である基準アイテムの子としてビュー基準をネストしたネストされた式は、問合せ検索フォームでサポートされています。ビュー基準を使用した検索フォームの作成の詳細は、27.1.5項「暗黙的ビュー基準と名前付きビュー基準」を参照してください。
ビュー・オブジェクト・コレクションに対して作成された名前付きビュー基準は、Webページ・デザイナがQuery-by-Example検索フォームを作成する際に使用できます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルから名前付きビュー基準を選択して、Fusion Webアプリケーション用の検索フォームを作成します。Webページの検索フォームでは、「データ・コントロール」パネルで選択した名前付きビュー基準に最初にバインドされるADF Faces問合せ検索コンポーネントが利用されます。実行時、エンド・ユーザーは、「データ・コントロール」パネルに表示されるその他すべての名前付きビュー基準の中からいずれかを選択できます。検索フォームでエンド・ユーザーが選択できる名前付きビュー基準は、開発者シード検索と呼ばれます。問合せコンポーネントでは、「保存済の検索」ドロップダウン・リストに、これらのシードされた検索が自動的に表示されます。検索フォームの作成およびADF問合せ検索コンポーネントの使用の詳細は、27.2項「問合せ検索フォームの作成」を参照してください。
|
注意: デフォルトでは「ビュー基準の編集」ダイアログで作成するすべての名前付きビュー基準が、「データ・コントロール」パネルに表示されます。「ビュー基準の編集」ダイアログの「UIヒント」ページで「リストに表示」オプションが選択されているかぎり、名前付きビュー基準は開発者シード検索として使用可能であるとみなされます。作成する名前付きビュー基準が検索フォームを介してエンド・ユーザーに表示されないようにする場合は、ダイアログで「リストに表示」オプションの選択を解除します。たとえば、LOV有効属性に対してのみ名前付きビュー基準を作成する場合は、「リストに表示」オプションの選択を解除する必要があります。 |
開発者シード検索はモデル・プロジェクト内で作成されるため、「ビュー基準の編集」ダイアログの「UIヒント」ページでは、問合せコンポーネントにおける個々の名前付きビュー基準の実行時の使用方法に対して、デフォルト・プロパティを指定できます。実行時の問合せコンポーネントの動作は、次のシードされた検索プロパティからどれを選択するかによって決まります。
検索リージョン・モード: 問合せコンポーネントでシードされた検索を表示する際のモードを選択します。「基本」モードでは、表示された検索基準フィールドをエンド・ユーザーが動的に変更することはできませんが、それ以外は使用できる機能は「詳細」モードとまったく同じです。「ビュー基準の編集」ダイアログで定義するビュー基準のデフォルトのモードは、「基本」モードです。
自動的に問合せ: 名前付きビュー基準に関連付けられた問合せを実行し、その結果をWebページに表示する場合に選択します。このオプションが有効になっている開発者がシードした検索は、エンド・ユーザーが問合せコンポーネントの「保存済の検索」リストから選択すると、自動的に実行されます。Webページ・デザイナの意向により、エンド・ユーザーがフォーム上の検索基準値を送信するまで以前の結果を更新しないようにする場合は、選択を解除します。また、タスク・フローから検索フォームが起動される場合は、このオプションの選択が解除されていると検索フォームは空白になり、選択されると移入されます。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して無効になっています。
「演算子の表示」: 問合せコンポーネントでエンド・ユーザーにビュー基準アイテムの演算子の選択フィールドを表示する方法を指定します。たとえば、エンド・ユーザーが基準アイテムの演算子を(基本モードまたは詳細モードで)カスタマイズできるようにするには、「常に」を選択し、定義されている演算子を使用してビュー基準を実行する場合は、「なし」を選択します。バインド変数は複数の基準アイテムで使用される可能性があるため、エンド・ユーザーは、バインド変数で指定されている基準アイテムの演算子を変更できません。
すべてに一致といずれかに一致を表示: 問合せコンポーネントで「すべてに一致」および「いずれかに一致」ラジオ・ボタンをエンド・ユーザーに表示する場合に選択します。これらのボタンが表示されている場合、エンド・ユーザーはこれらのボタンを使用して検索条件を変更し、すべての条件に一致またはいずれかの条件に一致する結果を戻すことができます。これは、ビュー基準アイテム間にAND結合(すべてに一致)またはOR結合(いずれかに一致)を適用するのと同等です。定義されている論理積を使用してビュー基準を実行する場合は、選択を解除します。この場合、問合せコンポーネントにラジオ・ボタンの選択は表示されません。
表示されたモード: ビュー基準ツリー・コンポーネントから個々のビュー基準アイテムを選択し、さらに、エンド・ユーザーが問合せコンポーネントのモードを「基本」と「詳細」の間で切り替える際に、選択したアイテムが検索フォームに表示されるようにするかどうかを選択します。それぞれのビュー基準アイテムに対するデフォルト設定は「すべて」です。このデフォルトのモードの場合、問合せコンポーネントでは、「基本」と「詳細」のどちらのモードでもアイテムをレンダリングできます。個々のビュー基準アイテムの「表示されたモード」設定を変更すると、実行時の検索フォームの外観をカスタマイズできます。たとえば、「基本」モードで簡略化した検索フォームをエンド・ユーザーに表示し、すべてのビュー基準アイテムのある検索フォームを表示できる「詳細」モードを予約する必要があるとします。この場合は、問合せコンポーネントの「基本」モードで表示しないビュー基準アイテムに対しては「詳細」を選択します。一方、選択したビュー基準アイテムを「基本」モードでのみレンダリングする場合は、「基本」を選択します。検索フォームで「基本」モードでも「詳細」モードでも表示しないアイテムに対しては「なし」を設定します。
|
注意: ユーザーに公開しないアイテムがビュー基準に含まれている場合、「表示されたモード」設定に「なし」を使用して、検索フォームでそのアイテムを非表示にします。たとえば、ログインした顧客のカート内にある製品を検索するためのビュー基準は作成できますが、ユーザーが顧客IDを変更して別の顧客のカート内にある製品を表示することのないようにする必要があります。このようなシナリオでは、名前付きバインド変数を使用して、顧客IDに対応するビュー基準アイテムを現在の顧客IDに設定します。バインド変数定義で変数が任意または更新不可に指定されている場合がありますが、コントロール・ヒント・プロパティの「表示」が「非表示」に設定されている場合は、「表示されたモード」の設定によってのみ、検索フォームに値が表示されるかどうかが決まります。 |
「複数の値の選択をサポート」: エンド・ユーザーが問合せコンポーネントに表示される各基準アイテムの複数の選択を行えるようにする場合に選択します。このオプションは、ビュー基準アイテムによって指定されるビュー・オブジェクト属性に、値リスト(LOV)が定義されている場合にのみ有効になります。また、エンド・ユーザーが演算子equal toまたはnot equal toを選択している場合、複数の選択は問合せコンポーネントによってのみサポートされます。たとえば、基準アイテムで属性CountryIdが指定され、この属性が関連付けられたLOVによってアクセスされる国IDのリストから値を導出する場合、このオプションを選択すると、エンド・ユーザーは複数の国を選択して問合せを送信できます。実行時に、問合せコンポーネントはエンド・ユーザーが選択した演算子に基づいて適切な問合せ句を生成します。
「リストに表示」: ビュー基準を開発者がシードした問合せとして定義する場合に選択します。定義する名前付きビュー基準が、検索フォームを表示する問合せ検索コンポーネントで使用されないようにする場合は、選択を解除します。このオプションにより、使用可能なシードされた検索の問合せ検索コンポーネントの「保存済の検索」ドロップダウン・リストに、名前付きビュー基準が表示されるかどうかが決まります。このオプションは、デフォルトでは、「ビュー基準の編集」ダイアログで定義するビュー基準に対して有効になっています。
「表示名」: 問合せコンポーネントの「保存済の検索」ドロップダウン・リストに表示するシード検索の名前を入力するか、「...」ボタン(編集フィールドの右)をクリックしてビュー・オブジェクトに関連付けられているリソース・バンドルからメッセージ文字列を選択します。表示名は、エンド・ユーザーがシード検索を識別する名前になります。リソース・バンドルからメッセージ文字列を選択すると、この文字列に対応するメッセージ・キーがビュー・オブジェクト定義ファイルに保存されます。実行時に、UIはこの文字列を特定し、エンド・ユーザーのロケール設定とローカライズされたリソース・バンドルのメッセージ・キーに基づいて表示します。表示名が指定されていない場合、デフォルトでは、「ビュー基準の編集」ダイアログに表示されるビュー基準の名前が使用されます。
ADF問合せ検索コンポーネントで使用するシード検索を作成する場合は、「ビュー基準の編集」ダイアログの「UIヒント」ページで、「リストに表示」を選択します。エンド・ユーザーの検索フォームにビュー基準を表示しない場合は、「リストに表示」の選択を解除します。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
5.11.1項「名前付きビュー基準を宣言的に作成する方法」の説明に従って、ビュー基準を作成します。
ユーザー・インタフェースに使用する名前付きビュー基準をカスタマイズするには:
アプリケーション・ナビゲータで、シードされた検索として使用する名前付きビュー基準を定義しているビュー・オブジェクトをダブルクリックします。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「ビュー基準」セクションを展開し、シード検索で使用可能にする名前付きビュー基準をダブルクリックします。
「ビュー基準の編集」ダイアログの「UIヒント」ページで、「リストに表示」が選択されていることを確認します。
この選択により、問合せコンポーネントによってシードされた検索が「保存済の検索」ドロップダウン・リストに表示されるかどうかが決まります。
問合せコンポーネントの「保存済の検索」ドロップダウン・リストに追加するシードされた検索に対して、わかりやすい表示名を入力します。
何も入力しない場合、問合せコンポーネントでは、「ビュー基準の編集」ダイアログに表示されるビュー基準の名前が使用されます。
エンド・ユーザーが「保存済の検索」ドロップダウン・リストからシードされた検索を選択するたびに、検索結果が自動的に問合せコンポーネントに表示されるようにする場合は、「自動的に問合せ」を有効にします。
デフォルトでは、検索結果は表示されません。
必要に応じて、「基準アイテムUIのヒント」を適用して、エンド・ユーザーが検索フォームのモードを「基本」と「詳細」の間で切り替える際に、問合せコンポーネントで個々の基準アイテムをレンダリングするかどうかをカスタマイズします。
デフォルトでは、シードされた検索で定義したビュー基準アイテムはすべて、どちらかのモードで表示されます。
レンダリングされた基準アイテムがDate型の場合、対応するビュー・オブジェクト属性のUIヒントも定義する必要があります。 5.13.1項「属性のコントロール・ヒントの追加方法」の説明に従って、ビュー・オブジェクト属性の「フォーマット・タイプ」のヒントをSimple Dateに設定し、「フォーマット・マスク」を適切な値に設定します。これにより、検索フォームに日付値を受け入れることができます。
「OK」をクリックします。
ビュー・オブジェクトに追加したビュー基準をテストするには、アプリケーション・ナビゲータからアクセスできるビジネス・コンポーネント・ブラウザを使用します。
参照するビュー・オブジェクト・インスタンスをビジネス・コンポーネント・ブラウザで開くと、「ビジネス・コンポーネント・ビュー基準」ダイアログが表示されます(図5-43を参照)。ダイアログで、1つ以上のビュー基準行から構成されるビュー基準を作成できます。
単一のビュー基準行から基準属性を適用するには、ブラウザの「ビュー基準の指定」ツールバー・ボタンをクリックして、目的のフィールドにQuery-by-Example基準を入力し、「検索」をクリックします。
ビジネス・コンポーネント・ブラウザを使用してビュー基準をテストするには:
アプリケーション・ナビゲータで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを展開します。
アプリケーション・モジュールを右クリックし、「実行」を選択します。
ビジネス・コンポーネント・ブラウザで、フィルタリングするビュー・インスタンスを右クリックし、「検索」を選択します。
または、ビュー・インスタンスをダブルクリックした後、「ビュー基準の指定」ツールバー・ボタンをクリックしてビュー基準をテストできます。
「ビジネス・コンポーネント・ビュー基準」ダイアログで、次のタスクのいずれかを実行します。
プロジェクトのビュー・オブジェクトに追加したビュー基準をテストするには、リストから選択して「検索」をクリックします。「非定型基準」パネルに入力した追加の基準は、フィルタに追加されます。
単一のビュー基準行から非定型基準属性をテストするには、ビュー基準に必要な値を入力し、「検索」をクリックします。たとえば、図5-43は、文字「d」から始まり、合計が100を超える注文を行った顧客IDを持つすべての顧客を返すフィルタを示しています。
追加の非定型ビュー基準行をテストするには、「または」タブをクリックして、それぞれが固有のビュー基準行を表すページを切り替えるために表示される追加タブを使用します。「検索」をクリックすると、ビジネス・コンポーネント・ブラウザによって、結果をフィルタリングするためのビュー基準が作成されて適用されます。
例5-34は、フィルタリングするPersonListビュー・オブジェクト・インスタンスを検索し、このビュー・オブジェクトの属性のビュー基準を作成し、このビュー基準をビュー・オブジェクトに適用するmain()メソッドを示しています。
ビュー基準をプログラムによって作成するには、次の基本的な手順に従います(例5-34を参照)。
フィルタリングするビュー・オブジェクト・インスタンスを検索します。
ビュー・オブジェクトに対するビュー基準行セットを作成します。
ビュー基準を使用して、1つ以上の空のビュー基準行を作成します。
適切なビュー基準行でフィルタリングする属性値を設定します。
単一のsetAttribute()メソッドをビュー基準行で使用して、フィルタ対象となる属性名、比較演算子および値を設定できます。または、ビュー基準行上のensureCriteriaItem()、setOperator()およびsetValue()を使用して、フィルタ対象となる属性名、比較演算子および値を個別に設定します。
ビュー基準行をビュー基準行セットに追加します。ビュー基準をビュー・オブジェクトに適用します。
問合せを実行します。
新しく適用されたビュー基準は次の実行でビュー・オブジェクトのSQL問合せにのみ適用されるため、問合せの実行の最後の手順は重要です。
例5-34 ビュー基準の作成および適用
package devguide.examples.readonlyvo.client;
import oracle.jbo.ApplicationModule;
import oracle.jbo.Row;
import oracle.jbo.ViewCriteria;
import oracle.jbo.ViewCriteriaRow;
import oracle.jbo.ViewObject;
import oracle.jbo.client.Configuration;
public class TestClientViewCriteria {
public static void main(String[] args) {
String amDef = "devguide.examples.readonlyvo.PersonService";
String config = "PersonServiceLocal";
ApplicationModule am =
Configuration.createRootApplicationModule(amDef, config);
// 1. Find the view object to filter
ViewObject vo = am.findViewObject("PersonList");
// Work with your appmodule and view object here
Configuration.releaseRootApplicationModule(am, true);
// 2. Create a view criteria row set for this view object
ViewCriteria vc = vo.createViewCriteria();
// 3. Use the view criteria to create one or more view criteria rows
ViewCriteriaRow vcr1 = vc.createViewCriteriaRow();
ViewCriteriaRow vcr2 = vc.createViewCriteriaRow();
// 4. Set attribute values to filter on in appropriate view criteria rows
vcr1.setAttribute("PersonId","> 200");
vcr1.setAttribute("Email","d%");
vcr1.setAttribute("PersonTypeCode","STAFF");
// Note the IN operator must be followed by a space after the operator.
vcr2.setAttribute("PersonId","IN (204,206)");
vcr2.setAttribute("LastName","Hemant");
// 5. Add the view criteria rows to the view critera row set
vc.add(vcr1);
vc.add(vcr2);
// 6. Apply the view criteria to the view object
vo.applyViewCriteria(vc);
// 7. Execute the query
vo.executeQuery();
while (vo.hasNext()) {
Row curPerson = vo.next();
System.out.println(curPerson.getAttribute("PersonId") + " " +
curPerson.getAttribute("Email"));
}
}
}
TestClientViewCriteriaの例を実行すると、例5-34に示した結果が生成されます。
206 SHEMANT
1つ以上のビュー基準行を含むビュー基準をビュー・オブジェクトに適用する場合は、次に実行されるときに、ビュー基準行に移入したQuery-By-Example基準に対応する追加のWHERE句条件を使用してビュー・オブジェクトのSQL問合せを拡張します。図5-44のように、複数のビュー基準行を含むビュー基準を適用する場合、ビュー・オブジェクトでは、各ビュー基準行の非nullの例の基準属性に基づいて付加的な実行時WHERE句を追加することによって、その設計時WHERE句が拡張されます。
ビュー基準機能の当然の結果として、新規ビュー基準を適用(または既存のビュー基準を削除)するたびに、ビュー・オブジェクトのSQL問合せのテキストが効率的に変更されます。SQL問合せの変更は、データベースが次に実行されるときに文を再解析する原因になります。5.11.10項「Query-By-Example基準について」で説明するように、この再解析は省略できるため、ビュー基準のパフォーマンスが向上します。
「ビュー基準の編集」ダイアログでサポートされていないタスクを実行する必要がある場合は、ビュー基準APIを使用できます。たとえば、複数のビュー基準行を使用した複合検索条件の変更、NULL属性値を持つ行の検索、大/小文字を区別しない検索、有効なビュー基準のクリアはいずれも、プログラムによって実行できます。
setWhereClause()メソッドを使用すると、ビュー・オブジェクトに動的WHERE句を追加できます(6.4.1項「ビュー・オブジェクトのデフォルト行セットを使用した操作のViewObjectインタフェース・メソッド」を参照)。また、次のようなリテラル・データベース列名を含む文字列を渡すためにもsetWhereClause()を使用できます。
vo.setWhereClause("LAST_NAME LIKE UPPER(:NameToFind)");
これに対して、ビュー基準のメカニズムを使用する場合は、例5-34に示すように、かわりに次のようにビュー・オブジェクト属性名を参照する必要があります。
ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setOperator(">");
vc_item1.setValue("304");
ビュー基準行は、ビュー・オブジェクトによって当該の列名を参照する当該のWHERE句条件に変換されます。
ビュー基準アイテムの値をバインド変数に設定する場合は、次のようにsetIsBindVarValue(true)を使用します。
ViewCriteriaItem vc_item1 = vc_row1.ensureCriteriaItem("UserId");
vc_item1.setIsBindVarValue(true);
vc_item1.setValue(":VariableName");
複数のビュー基準を追加する場合、ビュー基準の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句の制限は、1つのビュー・オブジェクトに対して定義する必要がある点です。つまり、SELECTとFROMリストは、UNION句の複数の内部問合せで同じになります。UNION問合せを指定するには、次のように外部ビュー基準のsetConjunction()をコールします。
vc.setConjunction(ViewCriteriaComponent.VC_CONJ_UNION);
外部ビュー基準には、結果同士が結合される内部問合せが含まれている必要があります。たとえば、次の2つのビュー基準の結合を指定する必要があるとします。
Job = 'SALESMAN'を検索するビュー基準MyEmpJob
Sal = 1500を検索するビュー基準MyEmpSalary
この2つのビュー基準のUNION問合せを作成するには、例5-35に示すコールを作成します。
例5-35 2つのビュー基準の結合を適用
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問合せの各内部問合せに適用されます。
NULL値を列に含む行を検索するには、対応するビュー基準行属性にIS NULLという値を移入するか、またはViewCriteriaItem.setOperator("ISBLANK")を使用します。
列の値が、指定する値リストのいずれかの値に一致するすべての行を検索するには、コンマ区切り値リストを使用して対応するビュー基準列属性を移入し、IN演算子を使用します。たとえば、IDが204および206に一致するユーザーのリストをフィルタリングするには、次のようにします。
vcr.setAttribute("PersonId","IN (204,206)");
IN演算子と括弧の間にはスペースが必要です。
IN (204,206)は正しい記述です。
IN(204,206)では、SQLSyntaxErrorExceptionエラーがスローされます。
大/小文字を区別しないで検索するには、区別しない検索を適用するビュー基準行のsetUpperColumns(true)をコールします。これは、ビュー・オブジェクトのString値の属性に対して生成されたWHERE句条件に影響を与え、COLUMN_NAMEではなくUPPER(COLUMN_NAME)が条件に使用されます。これらのString値の属性に対して提供されるビュー基準行属性の値は、大文字であるか、または条件が一致しないものである必要があります。UPPER()は、条件のみでなく、値に対しても使用できます。たとえば、UPPER(ename) = UPPER("scott")という設定が可能です。
次の2つのケースでは、パフォーマンス上の理由から、バインド変数をビュー基準アイテムの値として設定しないようにしてください。
ビュー基準アイテムの値が選択的に必須として定義されており、NULL以外の値からNULLに変更される特殊な場合
この場合は、NULL以外の値からNULLに変更されるたびに、ビュー基準のSQL文が再生成されます。
ビュー基準アイテムの値が任意で、そのアイテムが索引列の属性を参照している場合
任意のビュー基準アイテムの場合は、追加のSQL句のOR (:Variable IS NULL)が生成されます。この句は列索引の使用をサポートしません。
次のいずれかの場合は、5.10.1項「ビュー・オブジェクト定義にバインド変数を追加する方法」で説明するように、WHERE句に名前付きバインド変数が含まれるビュー・オブジェクトを使用することにより、パフォーマンスが向上します。ビュー基準フィルタリング機能とは対照的に、名前付きバインド変数を使用する場合は、これらの値が変わるたびにビュー・オブジェクトのSQL文のテキストを変更せずに、検索基準の値を変更できます。
アプリケーションのユーザー・インタフェース部分に表示される編集フォームでは、データ・モデルで定義するLOV有効属性を利用して、個々の入力フィールドの値リストを事前に指定できます。ユーザーが値を選択したフォームを送信すると、ADFモデル・レイヤーのADFデータ・バインディングにより、データバインドされたフィールドに対応するビュー・オブジェクト属性の値が更新されます。この一般的な設計タスクを容易にするために、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ページの作成の詳細は、第25章「データバインドされた選択リストおよびシャトルの作成」を参照してください。特に、WebページでのLOV有効属性の処理の詳細は、25.3.2項「モデルドリブン・リストの作成方法」を参照してください。
編集フォームに表示されるリスト値が、編集フォーム内の別の選択内容に依存しないようにする場合は、ビュー・アクセッサを定義してリスト・データソースを指定できます。たとえば、ユーザーが注文項目のサプライヤを選択する必要があるフィールドが発注書に含まれているとします。この例では、最初にデータソース・ビュー・オブジェクト(SuppliersView)を指定するビュー・アクセッサを作成します。次に、ベース・ビュー・オブジェクト(PurchaseOrdersView)のSupplierDesc属性にLOVを設定します。最後に、ベース・ビュー・オブジェクトのLOV有効属性(SupplierDesc)からビュー・アクセッサを参照し、データソース属性(SupplierDesc)を選択します。
ベース・ビュー・オブジェクトのLOV有効属性を定義するには、「値リストの作成」ダイアログを使用します。このダイアログでは、既存のビュー・アクセッサを選択したり、新規のビュー・アクセッサを作成してLOV属性定義とともに保存できます。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
ビュー・オブジェクト属性の値を表示するLOVを定義するには:
アプリケーション・ナビゲータで、LOVとして有効にする属性が含まれているビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、LOVを表示する属性を選択し、「値リスト」セクションを展開して、「値リストの追加」ボタンをクリックします。
概要エディタの属性リストで現在選択している属性にLOVを作成するには、「値リストの作成」ダイアログを使用します。JDeveloperにより、LOVの使用方法を識別する一意の名前が割り当てられます。たとえば、属性SupplierDescのメタデータでは、この属性がLOV対応であることを示すSupplierDescLOVという名前が指定されます。
「値リストの作成」ダイアログで、「新規ビュー・アクセッサの作成」ボタンをクリックし、現在編集中のビュー・オブジェクトにビュー・アクセッサを追加します。
または、「リスト・データソース」を展開し、既存のアクセッサから選択できます。ドロップダウン・リストには、編集中のビュー・オブジェクトに追加したすべてのアクセッサが表示されます。
「ビュー・アクセッサ」ダイアログで、属性のデータソースを定義するビュー・オブジェクト定義または共有ビュー・インスタンスを選択し、それをビュー・アクセッサ・リストに移動します。
デフォルトでは、作成したビュー・アクセッサにはビュー・オブジェクトと同じ名前が表示されます。アクセッサ名を編集して一意の名前を付けることができます。たとえば、SuppliersViewビュー・オブジェクトにSuppliersViewAccessorという名前を割り当てます。
ビュー・インスタンスは、共有アプリケーション・モジュールのデータ・モデルで定義したビュー・オブジェクトの使用方法になります。LOVでの共有ビュー・インスタンスの使用の詳細は、10.4.4項「参照表を基にしてLOVを作成する方法」を参照してください。
「OK」をクリックして、ビュー・オブジェクトのビュー・アクセッサ定義を保存します。
「値リストの作成」ダイアログで、「リスト・データソース」を展開し、ベース・ビュー・オブジェクトに対して作成したデータ・ソースとして使用するビュー・アクセッサを選択します。次に、このビュー・アクセッサから、LOV有効属性のリスト・データを取得する同じ属性を選択します。
エディタにより、リスト・データソース属性とLOV有効属性の間のデフォルト・マッピングが作成されます。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SuppliersDescは、SuppliersViewAccessorビュー・アクセッサの属性SuppliersDescにマップされます。
このエディタでは、リストが定義されている属性のデフォルト属性マッピングは削除できません。
必要に応じて、リストによりベース・ビュー・オブジェクトに戻される値を追加で指定する場合、「リスト戻り値」セクションの「戻り属性マップを作成します」ボタンをクリックし、目的のベース・ビュー・オブジェクト属性をビュー・アクセッサによりアクセスされる属性にマップします。
あわせて更新するため、属性のリスト選択をユーザーには要求せず、現在の行で決定している属性値を必要とする場合、追加属性の戻り値が便利です。たとえば、PurchaseOrdersViewビュー・オブジェクトの属性SupplierAddressをマップする場合は、SuppliersViewAccessorビュー・アクセッサの属性SupplierAddressを選択します。
「OK」をクリックします。
アプリケーションのユーザー・インタフェースで、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有効属性SupplierSiteIdが制御属性SupplierIdの値に依存する場合は、すべてのサプライヤ・サイトのリストを問い合せるデータソース・ビュー・オブジェクトSupplierIdsForCurrentSupplierSiteがすでに作成されています。
概要エディタで、「問合せ」ナビゲーション・タブをクリックします。
「問合せ」ページで、「バインド変数」セクションを展開して「新規バインド変数の作成」ボタンをクリックし、データ・ソース・ビュー・オブジェクトにバインド変数を追加します。
たとえば、すべてのサプライヤのサイトのリストを問い合せるためのデータソース・ビュー・オブジェクトSupplierIdsForCurrentSupplierSiteは、LOV有効属性の制御属性となるため、これに対してバインド変数TheSupplierIdを作成します。
「バインド変数」ダイアログで、バインド変数の名前および型を入力します。その他の部分は一切変更せず、「OK」をクリックします。
デフォルトでは、作成したビュー・アクセッサには、ビュー・オブジェクト・インスタンスと同じ名前が表示されます。アクセッサ名を編集して一意の名前を付けることができます。たとえば、CurrencyLookupViewビュー・オブジェクト・インスタンスにCurrencyLookupViewAccessorという名前を割り当てます。
概要エディタの「問合せ」ページで、「ビュー基準」セクションを展開し、「新規ビュー基準の作成」ボタンをクリックして、現在編集中のデータ・ソース・ビュー・オブジェクトにビュー基準を追加します。
「ビュー基準の作成」ダイアログで、「グループの追加」をクリックし、次のようにグループに対して1つの「基準アイテム」を定義します。
ビュー基準を識別する「基準名」を入力します。たとえば、SupplierIdsForCurrentSupplierSiteに対してはSupplierCriteriaという名前を入力します。
「属性」リストから制御属性を選択します。たとえば、SupplierIdsForCurrentSupplierSiteからSupplierSiteId属性を選択します。
ビュー基準の「演算子」リストから「次と等しい」を選択します。
ビュー基準の「オペランド」リストから「バインド変数」を選択します。
「パラメータ」リストから事前に定義されているバインド変数の名前を選択します。
次のバインド変数構成オプションから選択して、親LOVが値を必要とするかどうかを指定します。
親LOV値が必要とされるカスケードLOVを構成する場合は、「検証」メニューの「オプション」で、「Null値の無視」の選択を解除します。この組合せは、親LOVを選択しない場合に子LOVの行が返されないカスケードLOV使用例をサポートします。「ビュー基準の編集」ダイアログには、((SupplierIdsForCurrentSupplierSite.SUPPLIER_ID = :TheSupplierId))という形のWHERE句が表示されます。
親LOV値がオプションのカスケードLOVを構成する場合は、「検証」メニューの「オプション」で、「Null値の無視」を選択します(デフォルト)。この組合せは、親LOVを選択しない場合に子LOVの行がすべて返されるカスケードLOV使用例をサポートします。「ビュー基準の編集」ダイアログには、(((SupplierIdsForCurrentSupplierSite.SUPPLIER_ID = :TheSupplierId) OR ( :TheSupplierId IS NULL )))のようなWHERE句が表示されます。
これらの設定の詳細は、5.11.3項「バインド変数オプションについて」を参照してください。親LOVを選択しないと検証エラーが発生するため、カスケードLOVの「検証」オプションでは、「必須」を選択しないでください。
「OK」をクリックします。
カスケードLOV有効属性を移入するには、まずデータ・ソース・ビュー・オブジェクトで名前付きビュー基準を設定する必要があります。ベース・ビュー・オブジェクトのLOV有効属性がデータ・ソース・ビュー・オブジェクトの制御属性に依存するようにするために、ベース・ビュー・オブジェクトのLOV有効属性にビュー・アクセッサを追加し、以前に定義済のデータ・ソース・ビュー・オブジェクトの名前付きビュー基準を参照します。
作業を始める前に、次のようにします。
5.12.2.1項「カスケード・リストを制御するデータ・ソース・ビュー・オブジェクトの作成」の説明に従って、データ・ソース・ビュー・オブジェクトと名前付きビュー基準を作成します。
LOV有効属性に対する表示値を、同じビュー行にある別の属性値に基づいてフィルタリングするためのビュー・アクセッサを作成するには:
アプリケーション・ナビゲータで、フィルタ対象のビュー・アクセッサをリスト・データソースとして使用する属性を含むベース・ビュー・オブジェクトをダブルクリックします。
たとえば、ベース・ビュー・オブジェクトPurchaseOrdersViewには、制御属性SupplierIdの値に依存する属性SupplierSiteIdが含まれています。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、カスケードLOVをフィルタリングする属性を選択してから、「値リスト」セクションを展開し、「値リストの追加」ボタンをクリックします。
「値リストの作成」ダイアログで、「新規ビュー・アクセッサの作成」ボタンをクリックし、現在編集中のビュー・オブジェクトにビュー・アクセッサを追加します。
または、「リスト・データソース」を展開し、既存のアクセッサから選択できます。ドロップダウン・リストには、編集中のビュー・オブジェクトに追加したすべてのアクセッサが表示されます。
「ビュー・アクセッサ」ダイアログで、データソース・ビュー・オブジェクトに対して作成したビュー・オブジェクト・インスタンス名を選択し、そのインスタンスをビュー・アクセッサ・リストに移動します。
ダイアログで新規のビュー・アクセッサを選択し、「編集」をクリックします。
「ビュー・アクセッサの編集」ダイアログで、事前に定義されているビュー基準をビュー・アクセッサに適用し、次の手順に従ってバインド変数に値を指定します。
「使用可能」リストでデータソース・ビュー・オブジェクトのビュー基準をクリックし、選択したビュー基準を「選択済」リストに追加します。たとえば、SupplierIdsForCurrentSupplierSiteビュー・オブジェクト定義からSupplierCriteriaを選択します。
バインド変数の値を制御属性の名前に設定します。この属性名は、ベース・ビュー・オブジェクトの制御属性の名前と一致している必要があります。たとえば、ベース・ビュー・オブジェクトPurchaseOrdersViewに、制御属性SupplierIdの値に依存するLOV有効属性SupplierSiteIdが含まれている場合、バインド変数値としてSupplierIdを入力します。
「パラメータ」リストから事前に定義されているバインド変数の名前を選択します。
「使用方法」ドロップダウン・リストから「必須」を選択します。
「OK」をクリックして、ベース・ビュー・オブジェクトのビュー・アクセッサ定義を保存します。
概要エディタの「属性」ページで、LOVを表示する属性を選択してから、「値リスト」セクションを展開し、「値リストの追加」ボタンをクリックします。
「値リストの作成」ダイアログで、「リスト・データソース」を展開し、データ・ソース・ビュー・オブジェクト・インスタンスに対して作成したビュー・アクセッサを選択して、データ・ソースとして使用します。次に、このビュー・アクセッサから、現在編集中の属性をフィルタリングするための制御属性を選択します。
エディタにより、ビュー・オブジェクト属性とLOV有効属性との間のデフォルト・マッピングが作成されます。ユーザーによる制御属性の選択によって設定されるバインド変数でLOV有効属性をフィルタリングできるようにするには、個別の属性を使用します。たとえば、PurchaseOrdersViewビュー・オブジェクトのLOV有効属性SupplierIdは、SupplierIdsForCurrentSupplierSiteViewAccessorに対する制御属性SupplierSiteIdにマップされます。ランタイムでは、行セットとベース行属性が異なるこれら2つのカスケードLOVが自動的にサポートされます。
「OK」をクリックします。
アプリケーションのユーザー・インタフェースに表示される値リストを変化させるもう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と適用する切替え属性も定義できます。
作業を始める前に、次のようにします。
5.12.1項「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性の最初のLOVリストを作成します。
切替え属性シナリオでは、一意のビュー・アクセッサを作成する必要があることに注意してください。複数のLOVリストを定義するために1つのビュー・アクセッサを再利用しないでください。様々なユース・ケースに対してビュー・アクセッサを再利用すると、実行時に予期しない結果が発生することがあります。
ビュー・オブジェクト属性に既存のLOVを使用して追加LOVリストを指定するには:
「アプリケーション・ナビゲータ」で、複数のLOVリストを指定する属性が含まれているビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
「属性」ページで、目的の属性を選択してから、「値リスト」セクションを展開し、「値リストの追加」ボタンをクリックします。
「値リストの作成」ダイアログで、5.12.1項「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性の最初のLOVを定義します。
LOVを定義するときに、属性によって返される値と一致するようにLOV名を変更します(これを使用して、アプリケーションによってLOV有効属性に適用されるLOVを決定します)。
1つ目のLOVを定義したら、概要エディタの「属性」ページの「値リスト」セクションに戻り、元の属性を選択したまま、「値リストの追加」ボタンをクリックします。
概要エディタの「属性」ページで正しい属性を選択すると、「値リスト」セクションには先に定義したLOVが表示されます。
「値リストの作成」ダイアログで、5.12.1項「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」で説明されている手順を繰り返し、後続の各LOVを定義します。
各LOVの名前は、属性によって返される(LOV有効属性を適用するLOVを決定する)一意の値に対応させる必要があります。
2つ目LOVは一意のビュー・アクセッサを使用して定義する必要がありますが、属性は任意のものを使用できます。複数のLOVリストが指定された属性に追加できるLOVリストのタイプに制限はありません。
2つ目のLOVを定義すると、「値リスト」セクションが変更され、LOVの選択の制御に使用する追加機能が表示されます。
概要エディタの「属性」ページで、「値リスト」セクションを展開し、「値リストの切替え」ドロップダウン・リストで、使用する値リストの名前を返す属性を選択します。
ドロップダウン・リストにベース・ビュー・オブジェクトの属性が表示されます。アプリケーションで、定義済の複数のLOVからLOVを動的に適用する場合には、ビュー・オブジェクトに、値が定義済のLOVの名前に変換される属性を定義する必要があります。この属性をビュー・オブジェクトに追加していない場合は、ドロップダウン・リストに<未指定>が表示されることを確認してください。この場合、実行時にアプリケーションのLOV有効属性にデフォルトのLOVが表示され、別のLOVを適用することはできません。
実行時に適用されるデフォルトのLOVを変更するには、目的のLOV定義に対応する「デフォルト」ラジオ・ボタンを選択します。
デフォルトで選択されたLOVにより、「値リストの切替え」ドロップダウン・リストに<未指定>が表示されている場合にアプリケーションに表示される値リストが決定します。最初は、概要エディタの「値リスト」セクションの1つ目のLOVがデフォルトになります。
アプリケーションが様々なLOVリストを表示するために使用するコンポーネントを変更するには、「リスト・タイプUIヒント」ドロップダウン・リストから目的のコンポーネントを選択します。
選択したコンポーネントがすべてのLOVリストに適用されます。使用可能なコンポーネントの詳細は、表5-2を参照してください。
LOVとして定義するビュー・オブジェクト属性がユーザー・インタフェースにどのように表示されるかが明確な場合は、LOVの追加プロパティを指定してその表示特性を指定できます。これらのプロパティ(UIヒント)により、ADFビジネス・コンポーネントで任意のビュー・オブジェクト属性に設定できる属性ヒント・プロパティを拡張できます。LOV有効属性のLOV UIヒントには、ユーザー・インタフェースでリストの表示に使用されるコンポーネントがあります。使用可能なコンポーネントの詳細は、表5-2を参照してください。(表5-2に示すように、すべてのADF Facesコンポーネントがデフォルトのリスト・タイプをサポートしているとはかぎりません)。
表5-2 リスト・タイプのコントロール・ヒントのリスト・コンポーネント・タイプ
| LOVのリスト・コンポーネント・タイプ | 使用方法 |
|---|---|
|
選択リスト
|
このコンポーネントでは、ドロップダウン・リストからの選択のみ可能で、テキスト入力はできません。 |
|
コンボ・ボックス
|
このコンポーネントでは、テキスト入力もドロップダウン・リストからの選択も可能です。このコンポーネントでは、ユーザーによる入力にオートコンプリートがサポートされる場合があります。 このコンポーネントは、ADF Facesではサポートされていません。 |
|
値リストを持つコンボ・ボックス
|
このコンポーネントは、一番下にあるエントリ(「詳細」)を選択すると、UIヒントのLOV属性に対して有効にした場合に問合せでフィルタリングがサポートされる「値リスト」参照ダイアログが開くこと以外は、コンボ・ボックスと同じです。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。 このコンポーネントは、ADF Facesではサポートされていません。 ただし、LOV属性が表コンポーネントに表示される場合、リスト・タイプは、「値リストを使用した入力テキスト」コンポーネントに変わります。 |
|
値リストのある入力テキスト
|
このコンポーネントでは、横にLOVボタンのある入力テキスト・フィールドが表示されます。このボタンをクリックするか、テキスト・フィールドに無効な値を入力すると、「値リスト」参照ダイアログが表示されます。このコンポーネントの「値リスト」ダイアログでは、UIヒントのLOV属性に対して有効にした場合に、問合せでフィルタリングがサポートされます。デフォルトのUIヒントでは、すべての属性に対して問合せが有効になります。 このコンポーネントでも、一致対象が1つになる場合は、オートコンプリートがサポートされます。 |
|
リスト・ボックス
|
このコンポーネントでは、(ユーザーがクリックするまで1行分の領域しか表示されない選択リストとは異なり)画面上に一定の大きさの領域が表示され、スクロール操作が可能です。 |
|
ラジオ・グループ
|
このコンポーネントには、LOV属性値で指定した選択項目で構成されるラジオ・ボタン・グループが表示されます。このコンポーネントは、項目の少ない固定リストには非常に有用です。 |
作業を始める前に、次のようにします。
5.12.1項「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、属性のLOVリストを作成します。
LOV有効属性に対してビュー・オブジェクト属性のUIヒントを設定するには:
アプリケーション・ナビゲータで、カスタマイズする属性を含むビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
概要エディタの「属性」ページで、目的の属性を選択し、「値リスト」セクションを展開します。
「値リスト」セクションで、カスタマイズするLOVリストを選択し、「値リストの編集」ボタンをクリックします。
「値リストの編集」ダイアログで、「UIヒント」タブを選択します。
「UIヒント」ページで、リストを表示するコンポーネントのタイプとして、「デフォルトのリスト・タイプ」を選択します。
使用可能なコンポーネントの詳細は、表5-2を参照してください。
Webページに表示されるリスト・コンポーネントと、ビュー・オブジェクトのデフォルトのリスト・タイプは実行時に一致する必要があり、一致しない場合は実行時例外(method-not-found)が発生します。このエラーを回避するには、ユーザー・インタフェース・デザイナで目的のリスト・コンポーネントを確認します。これらが一致するようにデフォルト・リストを編集できるので、その後ユーザー・インタフェース・デザイナでWebページで使用されるコンポーネントを変更しても、2つの同期が維持されます。
必要に応じて、さらに「属性の表示」を選択し、値を表示に追加します。
追加属性のリストは、LOV有効属性のビュー行から導出されます。追加属性の値を使用すると、エンド・ユーザーによるリストからの項目選択が容易になります。
「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択すると、デフォルトでは、コンポーネントのドロップダウン・リストにはデータ・ソースから最初の10レコードが表示されます。この制限により、ビュー・オブジェクトの小さいフェッチ・サイズも維持できます。「値リストを使用したコンボ・ボックス」コンポーネントのドロップダウン・リストに表示できるレコード数を変更するには、「問合せ限度」にレコード数を入力します。
「問合せ限度」では、ビュー・オブジェクトにフェッチされる行数も制御されるため(ビュー・オブジェクト定義のListRangeSizeプロパティを設定)、「問合せ限度」に大きな値を指定することは推奨されません。エンド・ユーザーは、(コンポーネントの参照アイコンをクリックすることにより)コンポーネントのLOV参照ダイアログを使用して、完全なレコード・セットにアクセスできます。「問合せ限度」は、他のすべてのコンポーネント・タイプでは無効になっており、これらのコンポーネントでは、LOVがアクセスする行数は制限されません。
ListRangeSizeプロパティの詳細は、5.12.9項「実行時に行われる処理: LOVでリスト・データソースを問い合せる場合」を参照してください。
値リストの参照ダイアログを開いてユーザーが値リストを選択できるようにするコンポーネント・タイプ(「値リストを使用したコンボ・ボックス」タイプ・コンポーネントや「値リストを使用した入力テキスト」タイプ・コンポーネントを含む)を選択した場合、参照ダイアログには、データ・ソース・ビュー・オブジェクトのすべての問合せ可能属性を検索できる検索フォーム(LOV有効属性のビュー・アクセッサによって定義されたもの)が表示されます。これらのコンポーネントのカスタマイズ方法を指定します。
「値リストを使用したコンボ・ボックス」タイプ・コンポーネントを選択し、「選択されたもの」リストに多数の属性を追加済の場合は、「コンボ・ボックスに表示」を使用してこのコンポーネントのドロップダウン・リスト部分を読みやすくします。「値リストを使用したコンボ・ボックス」コンポーネントに表示されるドロップダウン・リストに含まれる属性列を制限するには、「コンボ・ボックスに表示」から「最初」を選択し、ドロップダウン・メニューに表示する、「選択されたもの」リストの最上部からの属性数に対応する数字を入力します(この組合せでは、「値リストの作成」ダイアログの「選択されたもの」リストから表示する最初のx個の属性を指定します)。ドロップダウン・リストに表示される属性列数を制限することにより、ユーザーは完全なリストを確認するために水平にスクロールする必要がなくなりますが、これによって「値リスト」参照ダイアログに表示される属性列の数が制限されるわけではありません。このオプションは、「値リストを使用したコンボ・ボックス」を除くすべてのリスト・コンポーネント・タイプで無効にされています。
「検索リージョンを含む」ドロップダウン・リストからビュー基準を選択すると、「値リスト」参照ダイアログに表示する属性を制限できます。ドロップダウン・リストにビュー基準を表示するには、そのビュー基準がデータソース・ビュー・オブジェクト(LOV有効属性のビュー・アクセッサで定義したオブジェクト)で定義されている必要があります。選択したビュー基準の検索フォーム・プロパティを設定するには、「ビュー基準の編集」ボタンをクリックします。検索フォームのビュー基準のカスタマイズの詳細は、5.11.5項「ビュー基準にユーザー・インタフェース・ヒントを設定する方法」を参照してください。
「リストを自動的に問合せ」を選択すると、「値リスト」参照ダイアログの結果表に事前に移入できます。ユーザーが「値リスト」参照ダイアログを開くと、問合せの結果が表示されます。このオプションの選択を解除したままだと、ユーザーが検索フォームを送信するまで結果は表示されません。
また、「値リスト」参照ダイアログに検索リージョンを表示したくない場合は、「検索リージョンを含む」ドロップダウン・リストから<検索なし>を選択します。この場合、「値リスト」参照ダイアログには、「属性の表示」リストに追加した属性しか表示されません。
リストに表示する選択タイプ・コンポーネントを選択した場合は、選択可能なすべての値を表示する代替手段として、「最近使用されたカウント」を指定できます。
たとえば、発注書に入力するSupplierId値の選択リストがフォームに表示されることがあります。このケースでは、最近表示されたサプライヤのリストからユーザーが選択できるようにし、入力するカウント数によってサプライヤの選択肢の数を指定できます。デフォルトのカウント0(ゼロ)では、選択リストに属性のすべての値が表示されます。
リストを表示するコンポーネントとして「値リストを使用したコンボ・ボックス」タイプを選択した場合、「コンボ・ボックスのフィルタ基準」ドロップダウン・リストからビュー基準を選択し、LOVに表示される有効な値のリストを制限できます。
「コンボ・ボックスのフィルタ基準」を有効にすると、ドロップダウン・リストには、LOVのビュー・アクセッサに関連するビュー・オブジェクト定義から既存のビュー基準が表示されます。ドロップダウン・リストにビュー基準が表示されない場合は、データ・ソース・ビュー・オブジェクトにビュー基準が定義されていません。この機能を有効にしない場合、「値リストを使用したコンボ・ボックス」コンポーネントは、ビュー・アクセッサから戻された完全な行セットからその値を導出します。「値リストを使用したコンボ・ボックス」のフィルタは、ポップアップ検索ダイアログでLOVを使用する場合や、有効な選択肢が限定されたドロップダウン・リストでLOVを使用する場合に便利な機能です。ユーザー・インタフェースでの「値リストを使用したコンボ・ボックス」コンポーネントの使用の詳細は、27.1.6項「値リスト(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と評価された場合に発生します。コントロール・ヒントの詳細は、5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照してください。
LOV有効属性の日付フォーマットに一致するコントロール・ヒントを設定するには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、コントロール・ヒントを使用してカスタマイズする日付値属性をダブルクリックします。
また、選択した属性のプロパティ・インスペクタを表示し、「UIヒント」ナビゲーション・タブを選択します。プロパティ・インスペクタでは、「属性の編集」ダイアログを使用せずに属性のコントロール・ヒントをカスタマイズできます。
「属性の編集」ダイアログで、「コントロール・ヒント」を選択し、「コントロール・ヒント」ページで、「フォーマット・タイプ」に対してSimple Dateを選択し、日付のみのマスクのフォーマットを選択します。
ADFビジネス・コンポーネント・ドメイン・タイプと、使用可能なフォーマッタとのマッピングは、JDeveloperシステム・ディレクトリのBC4Jサブディレクトリにあるformatinfo.xmlファイルで指定されます(たとえば、C:\Documents and Settings\<username>\Application Data\JDeveloper\system<version#>\o.BC4J.\formatinfo.xml)。
「OK」をクリックします。
ビュー・アクセッサがデータベース表から常に最新のデータを問い合せるようにする必要がある場合は、データ・ソース・ビュー・オブジェクトで「自動リフレッシュ」プロパティを設定できます。このプロパティにより、データベースが変更されると、ビュー・オブジェクト・インスタンスを自動的にリフレッシュできます。この機能は、アプリケーション・モジュールで定義されているすべてのビュー・インスタンスに対して有効にできます。ビュー・オブジェクトでこのプロパティを有効にすると、ユーザーがデータベース表にコミットする変更は、同一のデータベース表を利用して作業しているすべての他のユーザーに利用可能になります。一般的には、ビュー・アクセッサにLOV有効ビュー・オブジェクト属性を定義するときに、データ・ソース・ビュー・オブジェクトの自動リフレッシュが有効にされます。
自動リフレッシュ機能はデータベースの変更通知機能を使用するため、ビュー・オブジェクトで自動リフレッシュを有効にする場合は、これらの制限事項に従ってください。
ビュー・オブジェクトで読取り専用の表の問合せを実行する場合は、表の数をできるだけ少なくしてください。これにより、パフォーマンスが最適化され、データベースで無効なキューが増大するのを防ぐことができます。
更新可能な自動リフレッシュ・ビュー・インスタンスが含まれるアプリケーション・モジュールは、更新中に行をロックするように構成する必要があります。
データベース・ユーザーには、データベースの通知権限を付与する必要があります。たとえば、SQL*Plusコマンドを使用して通知権限を付与するには、grant change notification to <ユーザー名>を使用します。
ビュー・オブジェクトで自動リフレッシュを有効にする場合、このフレームワークではJDBC APIを使用してビュー・オブジェクト問合せを登録し、実行時のビュー・オブジェクト問合せの実行前に基礎となるデータの変更に関するOracleデータベース変更通知を受け取ります。(基礎となるデータが変更されたため)ビュー・オブジェクトが通知を受け取ると、ビュー・オブジェクトの行セットはダーティとしてマークされ、このフレームワークではクライアントから中間層への次のサーバー・トリップでこの行セットがリフレッシュされます。この時点で、ダーティ・コレクションは破棄され、更新されたデータがリクエストされると、ビュー・オブジェクトによって新しい問合せ実行がトリガーされます。たとえば、ユーザーはカレンダのエントリを作成または編集可能で、他のユーザーが追加したカレンダ・エントリの編集はできないとします。ユーザーが新しいエントリを作成すると、同じサーバー・トリップで、他のユーザーが変更または入力したカレンダ・エントリが更新されます。しかし、もう1人のユーザーがカレンダ・エントリを作成すると、ビュー・オブジェクトは通知を受け取り、次のサーバー・トリップまで待機してからリフレッシュを行うため、この更新実行までの遅延により、同じデータを読み取る複数のユーザー間の競合を回避できます。
|
ベスト・プラクティス: Webアプリケーションには、オプティミスティック行ロックを使用します。デフォルト構成で設定されているオプティミスティック・ロックでは、相互に影響を与えずに複数のトランザクションを完了できることが前提になります。したがって、オプティミスティック・ロックにより、リフレッシュ対象の行をロックせずに自動リフレッシュを開始できます。ペシミスティック・ロックでは、行セットのリフレッシュは妨げられ、行セットに保留中のトランザクションがある場合(たとえば、ユーザーが新しい行を追加中の場合)は例外がスローされます。アプリケーション・モジュールの構成でオプティミスティック行ロックを確実に使用するには、「ビジネス・コンポーネントの構成」ダイアログの「プロパティ」タブを開き、 |
データ変更通知を受け取るビュー・オブジェクトを登録するには:
アプリケーション・ナビゲータで、データベースの変更通知を受け取るビュー・オブジェクトをダブルクリックします。
「プロパティ・インスペクタ」で「データベース取得のチューニング」セクションを展開し、「自動リフレッシュ」プロパティで「True」を選択します。
ビュー・オブジェクト属性に作成したLOVをテストするには、アプリケーション・ナビゲータからアクセスできるビジネス・コンポーネント・ブラウザを使用します。
ビジネス・コンポーネント・ブラウザでは、「値リスト」ダイアログの「UIヒント」ページで選択可能な2つのコンポーネント・タイプのいずれかを使用して、参照する任意のビュー・オブジェクト・インスタンスについてLOVが有効な属性が表示されます。現時点では、選択リストのコンポーネント・タイプと値リストのある入力テキストのコンポーネント・タイプのみがサポートされています。それ以外の場合は、ビジネス・コンポーネント・ブラウザによってデフォルトの選択リストのタイプが使用され、LOVが有効な属性が表示されます。
ビジネス・コンポーネント・ブラウザを使用したLOVをテストするには:
アプリケーション・ナビゲータで、目的のアプリケーション・モジュールおよびビュー・オブジェクトを含むプロジェクトを展開します。
アプリケーション・モジュールを右クリックし、「実行」を選択します。
「ビジネス・コンポーネント構成の選択」ダイアログで、「構成名」リストから目的のアプリケーション・モジュール構成を選択し、ビジネス・コンポーネント・ブラウザを実行します。
「接続」をクリックし、選択した構成を使用してアプリケーション・モジュールを起動します。
ビジネス・コンポーネント・ブラウザで、左側のセクションから目的のビュー・オブジェクトを選択します。ビジネス・コンポーネント・ブラウザには、コンポーネント・タイプをリスト値のある入力テキストのUIヒントとして指定しないかぎり、LOVが有効な属性がドロップダウンの選択リストとして表示されます。
図5-45は、UIヒント・リスト・タイプとして入力テキスト・フィールドと「値リスト」ダイアログを指定するOrdersVOのLOV有効属性TypeCouponCodeを示しています。「値リストを使用した入力テキスト」コンポーネントは、独立したLOVダイアログに選択肢を表示する場合に便利です。他のリスト・タイプは、ビジネス・コンポーネント・ブラウザではサポートされていません。
ビュー・オブジェクト属性に対してLOVを定義する場合、ビュー・オブジェクト・メタデータにより、次のように追加情報が定義されます(Fusion Order DemoアプリケーションのOrdersVO.TypedCouponCode属性に関する例5-36を参照)。
<ViewAttribute>要素では、属性に名前を付けてLOV動作を定義するリスト・バインディング要素を指し、Webページに表示するコンポーネント・タイプを指定します。たとえば、LOV有効属性のTypedCouponCodeは、LOV_TypedCouponCodeという名前のリスト・バインディングを指し、LOVデータを表示するリスト(input_text_lov)を使用してCONTROLTYPE入力テキスト・フィールドを定義します。
ユーザー・インタフェース・デザイナで「データ・コントロール」パネルを使用してWebページを作成する場合、JDeveloperによってWebページに追加されるコンポーネントは、<CONTROLTYPE Value="namedType"/>定義によって決定されます。データ・モデル・プロジェクトのコンポーネント・タイプ定義とWebページに表示されるコンポーネント・タイプが一致しない場合は、ランタイム例外が発生します。詳細は、5.12.9項「実行時に行われる処理: LOVでリスト・データソースを問い合せる場合」を参照してください。
<ListBinding>要素では、LOVの動作を定義します。また、LOV有効属性のデータソースにアクセスするためのビュー・アクセッサも指定します。ビュー・アクセッサとは、データソース・ビュー・オブジェクトの行セットから可能な値のリストを取得するためのADFビジネス・コンポーネントのメカニズムです。たとえば、ListVOName="Coupon"は、ビュー・オブジェクトCouponsVOにアクセスするCouponsビュー・アクセッサを指します。
<ListBinding>要素では、リスト・データソース属性をLOV有効属性にマップします。たとえば、ListAttrNames項目のEasyCode値は、LOV有効属性TypedCouponCodeにマップされます。
<ListBinding>要素では、必要に応じて、リストが定義されているデータソース属性以外のベース・ビュー・オブジェクトの属性に対してデータソースから戻される追加の値が定義されます。たとえば、DerivedAttrNames項目のCouponId値は、ListAttrNames項目のDiscountId値によって設定された追加の値です。
<ListBinding>要素では、現在行から表示する属性を1つ以上指定し、選択リスト・タイプのコンポーネントに固有のオプションも指定します。たとえば、ListDisplayAttrNames項目のEasyCode値は、LOV有効属性TypedCouponCodeによって表示される属性のみになります。この例では、NullValueFlagのnone値は、リストから空白項目を選択できないことを意味します。
例5-36 ビュー・オブジェクト・メタデータにおけるLOV属性の使用方法
<ViewAttribute
Name="TypedCouponCode"
LOVName="LOV_TypedCouponCode"
. . .
<Properties>
<SchemaBasedProperties>
<CONTROLTYPE Value="input_text_lov"/>
</SchemaBasedProperties>
</Properties>
</ViewAttribute>
. . .
<ListBinding
Name="LOV_TypedCouponCode"
ListVOName="Coupons"
ListRangeSize="-1"
NullValueFlag="none"
NullValueId="LOV_TypedCouponCode_NullValueId"
MRUCount="0">
<AttrArray Name="AttrNames">
<Item Value="TypedCouponCode"/>
</AttrArray>
<AttrArray Name="DerivedAttrNames">
<Item Value="CouponId"/>
</AttrArray>
<AttrArray Name="ListAttrNames">
<Item Value="EasyCode"/>
<Item Value="DiscountId"/>
</AttrArray>
<AttrArray Name="ListDisplayAttrNames">
<Item Value="EasyCode"/>
</AttrArray>
</ListBinding>
. . .
<ViewAccessor
Name="Coupons"
ViewObjectName="oracle.fodemo.storefront.store.queries.CouponsVO"/>
ADFビジネス・コンポーネント・ランタイムにより、ビュー行およびエンティティ・オブジェクトの属性セッターにビュー・アクセッサが追加され、LOV有効属性の動作が実現されます。ユーザー・インタフェースにLOVが有効な属性値を表示するために、LOVの機能によりデータソースをフェッチし、該当する行の属性とマップされたターゲット属性を検索します。
LOV機能によりフェッチされるデータ・オブジェクト数は、ビュー・オブジェクトの概要エディタの属性に表示される「値リストの編集」ダイアログで指定される、LOV有効属性のリスト・バインディング定義のListRangeSize設定で部分的に決定されます。フェッチされるレコード数が非常に多い場合、ListRangeSizeのデフォルト値により、レコードの表示に使用されるドロップダウン・リスト・コンポーネントで使用可能な値が切り捨てられることがあります。LOV問合せでフェッチされるレコードのデフォルト数は、レコードの表示に使用されるリスト・コンポーネントのタイプによって異なります。「値リストを使用したコンボ・ボックス」コンポーネントおよび「値リストを使用した入力テキスト」の場合、ListRangeSizeのデフォルト値は10です。選択可能な他のすべてのリスト・コンポーネント(選択リスト、コンボ・ボックス、リスト・ボックス、ラジオ・ボタン・グループを含む)の場合、ListRangeSizeのデフォルト値は-1に設定されています。値-1は、ユーザーがデータ・ソースからすべてのデータ・オブジェクトを表示できることを意味します。ListRangeSize値は、2つの「値リスト」タイプのコンポーネントに対して表示される参照ダイアログでエンド・ユーザーが検索できるレコードに影響を与えません。各リスト・コンポーネントによる値の表示方法の詳細は、5.12.4項「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」を参照してください。
<ListBinding>要素のメタデータ定義でListRangeSize値を変更することもできますが、値を別のレコード数(ListRangeSize="5"など)に設定すると、必要な選択項目が表示されなくなる可能性が高くなります。かわりに、値を-1(LOVダイアログを使用しないシンプルなリスト・コンポーネントのデフォルト)にすると、リスト・コンポーネントが表示するレコード数に制限は設定されず、ユーザーは完全な値セットにアクセスできます。
|
パフォーマンスに関するヒント: LOVに表示される値セットを制限するには、5.12.1項「単一のLOVが有効なビュー・オブジェクトの属性を定義する方法」の説明に従って、ビュー・アクセッサを使用してLOVバインディングをフィルタリングします。また、選択リストを表示するコンポーネント・タイプの場合には、5.12.4項「ビュー・オブジェクトのLOV有効属性にユーザー・インタフェース・ヒントを設定する方法」の説明に従って、ユーザーの以前の選択を表示するリストを制限するように「最近使用されたカウント」設定を変更できます。 |
ビュー・オブジェクトのCONTROLTYPE定義に一致しないLOV有効属性のUIコンポーネントがWebページに表示されると、ランタイム例外が発生します。ユーザー・インタフェース・デザイナで、「データ・コントロール」パネルを使用してJDeveloperのページを作成すると、「リスト・タイプUIヒント」ダイアログで、ビュー・オブジェクトのLOV有効属性に対して「デフォルトのリスト・タイプ」で指定したリスト・コンポーネントが自動的に挿入されます。ただし、Webページの作成後にユーザー・インタフェース・デザイナでリスト・タイプを変更した場合は、「リスト・タイプUIヒント」ダイアログで選択した項目が一致するように編集する必要があります。
ビュー・オブジェクトの属性に定義するLOVについていくつか知っておく必要があります。たとえば、既存のビュー・オブジェクトの展開による、親ビュー・オブジェクトから子ビュー・オブジェクトへのLOVが有効な属性を伝播する方法や、LOVのかわりにバリデータを使用して値リストを管理するケースなどがあります。
ビュー・オブジェクトにより他のビュー・オブジェクトが拡張される場合、ベース・オブジェクトにLOVが有効な属性を作成できます。概要エディタで子ビュー・オブジェクトを定義すると、対応するビュー・オブジェクト属性にLOV定義が表示されます。この継承メカニズムにより、LOVが有効な属性を1回定義し、後で同じ属性の複数のビュー・オブジェクト・インスタンス全体にその属性を適用できます。
また、概要エディタを使用して継承LOV定義を拡張できます。たとえば、ベース・ビュー・オブジェクトの問合せによりすでに定義されている属性を追加して、選択リストに表示できます。あるいは、カスタムのWHERE句を使用するビュー・オブジェクトを定義して、ベース・ビュー・オブジェクトによりまだ問合せされていない追加属性を問合せできます。エンティティ・ベース・ビュー・オブジェクトのカスタマイズの詳細は、5.10項「バインド変数の使用」を参照してください。
ビュー・オブジェクトにLOVが有効な属性を作成した場合、List Validatorを使用して属性を検証する必要はありません。ユーザー・インタフェースにリストを表示せず、有効値のリストを制限する必要がある場合のみ属性バリデータを使用します。リスト検証は、単純な静的リスト、または定義するビュー・アクセッサから取得した使用可能な値のリストです。UIに表示された属性がキー値(主キー、外部キー、または代替キー)を参照する属性の場合には、キーの存在検証を使用します。ADFビジネス・コンポーネントでの宣言的な検証の詳細は、第7章「検証とビジネス・ルールの宣言的な定義」を参照してください。
アプリケーションでアプリケーション・モジュール・サービスの公開にEJBセッションBeanが使用される場合、LOVが有効な属性に関連する制限事項が発生します。「データ・コントロール」パネルのユーザー・インタフェース・プロジェクトにデータ・バインディング機能を使用してこれらのサービスが表示されるため、データバインドされたLOVリスト・コンポーネントを作成できます。ただし、実行時にはLOVリストは空の状態で表示されます。また、LOVダイアログに検索機能が含まれる場合、検索リンクをクリックすると、FacesCtrlSearchBinding例外エラーが発生します。これは、EJBセッションBeanでサポートされているとおりに、ビジネス・サービスとユーザー・インタフェースを別々の層にデプロイした場合に発生する既知の制限事項です。
ADFビジネス・コンポーネントの組込み機能の1つに、ビュー・オブジェクトとビュー・オブジェクトの属性についてのコントロール・ヒントを定義する機能があります。コントロール・ヒントは、ロケールに依存した一貫性のある方法で問合せ情報を自動表示する際にビュー・レイヤーで使用される設定です。たとえば、Webページでは、UI開発者は、bindingsネーム・スペースで定義され、ADFバインディング・インスタンス名に対して指定されたEL式ユーティリティ・メソッドを入力することによりコントロール・ヒント値にアクセスできます。
JDeveloperでは、多言語アプリケーションを容易にローカライズできるリソース・バンドル・ファイルにヒントを格納します。
ビュー・オブジェクトの属性に対してコントロール・ヒントを作成するには、アプリケーション・ナビゲータからアクセスできるビュー・オブジェクトの概要エディタを使用します。コントロール・ヒントの表示と編集は、属性で表示するプロパティ・インスペクタを使用しても可能です。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
コントロール・ヒントを使用してビュー・オブジェクト属性をカスタマイズするには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、コントロール・ヒントを使用してカスタマイズする属性をダブルクリックします。
また、選択した属性のプロパティ・インスペクタを表示し、「UIヒント」ナビゲーション・タブを選択します。プロパティ・インスペクタでは、「属性の編集」ダイアログを使用せずに属性のコントロール・ヒントをカスタマイズできます。
「属性の編集」ダイアログで、「コントロール・ヒント」を選択し、目的のヒントを定義します。
たとえば、UserIdという属性の場合、その「ラベル・テキスト」ヒントにIdなどの値を入力するか、または「フォーマットの種類」を「Number」に設定し、「フォーマット」にフォーマット・マスクとして00000と入力します。
「OK」をクリックします。
|
注意: Javaで定義される数値および日付のフォーマット・マスクの標準セットは、OracleデータベースのSQLおよびPL/SQL言語によって使用されるものとは異なります。詳細は、 |
ビュー・オブジェクトの属性に対してコントロール・ヒントを作成するには、アプリケーション・ナビゲータからアクセスできるビュー・オブジェクトの概要エディタを使用します。ビュー・オブジェクト属性で表示する「プロパティ・インスペクタ」を使用しても、複数の追加のコントロール・ヒントを表示および編集できます。
作業を始める前に、次のようにします。
コントロール・ヒントの知識があると役立ちます。詳細は、5.13項「ビュー・オブジェクトのコントロール・ヒントの定義」を参照してください。
次のタスクを完了する必要があります。
コントロール・ヒントを使用してビュー・オブジェクトをカスタマイズするには:
アプリケーション・ナビゲータで、ビュー・オブジェクトをダブルクリックします。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
「一般」ページで、「表示名」を入力し、ビュー・オブジェクト名に対してELでアクセス可能なヒントを定義します。
たとえば、ビュー・オブジェクトOrdersVOの場合には、「表示名」ヒントに「Order」のような値を入力できます。
概要エディタで「一般」ページを表示したまま、ビュー・オブジェクトの「プロパティ・インスペクタ」を開き、「UIヒント」セクションを展開して、必要に応じて追加のヒントを入力します。
たとえば、ビュー・オブジェクトOrdersVOに対しては、「表示名(複数)」ヒントに「Orders」のような値を入力し、「説明」ヒントには「customer orders」のような値を入力できます。
UI開発者は、EL式を使用してコントロール・ヒントにアクセスし、Webページにデータとしてヒント値を表示できます。コントロール・ヒントには、データバインドされたコンポーネントをWebページにドロップした後に作成するADFバインディング・インスタンスを通じてアクセスできます。
ビュー・オブジェクト・ヒントの場合は、UI開発者はそのビュー・オブジェクトに対して定義済のイテレータ・バインディングを介してアクセスします。たとえば、次のようなビュー・オブジェクト・コントロール・ヒントを構成したとします。
OrdersVOビュー・オブジェクト「表示名」ヒント = Order
OrdersVOビュー・オブジェクト「表示名(複数)」ヒント = Orders
OrdersVOビュー・オブジェクト「説明」ヒント = customer orders
UI開発者は、これらのヒントを活用するヘッダーを次のように表示できます。
Showing customer orders number 10 of 51 Orders.
例5-37は、上記のテキストを生成するEL式を示しています。このEL式では、イテレータ・バインディングOrdersVO1Iteratorによってビュー・オブジェクト・ヒントへのアクセスが提供されます。EL式ユーティリティ・メソッド名は、ビュー・オブジェクトXML定義ファイルのコントロール・ヒントで定義されているプロパティ名と一致します。たとえば、「表示名(複数)」ヒントを定義するビュー・オブジェクトのプロパティ名labelPluralは、式bindings.OrdersVO1Iterator.hints.labelPluralで使用されているユーティリティ・メソッド名と一致します。
ビュー・オブジェクトまたはビュー・オブジェクト属性にコントロール・ヒントを定義する場合、デフォルトでは、それらが格納されるプロジェクトレベルのリソース・バンドル・ファイルが作成されます。たとえば、StoreFrontプロジェクトでビュー・オブジェクトのコントロール・ヒントを定義すると、パッケージには、StoreFrontBundle.xxxという名前のメッセージ・バンドル・ファイルが作成されます。定義したヒントは、関連付けられたビュー・クライアントで生成されたフォームおよび表によって使用できます。JDeveloperで使用されるリソース・バンドル・ファイルのタイプおよびファイルの粒度は、「プロジェクト・プロパティ」ダイアログの「リソース・バンドル」ページの設定で指定します。デフォルトでは、このオプションは「プロパティ・バンドル」に設定され、データ・モデル・プロジェクト全体に対して1つの.propertiesファイルが生成されます。
また、「プロジェクト・プロパティ」ダイアログでオプションを設定して、ファイルごとに1つのリソース・バンドルを生成する場合は、アプリケーション・ナビゲータでオブジェクトを選択し、構造ウィンドウの対応する「ソース」ノードを参照して、ビュー・オブジェクトのメッセージ・バンドル・ファイルを検証できます。構造ウィンドウには、アプリケーション・ナビゲータで選択したコンポーネントの実装ファイルが表示されます。図5-46に示すように、アプリケーション・ナビゲータで目的のビュー・オブジェクトの親パッケージを展開すると、ビュー・オブジェクトのリソース・バンドル・ファイルを検証できます。
選択可能なリソース・バンドル・オプションの詳細は、4.7.1項「メッセージ・バンドル・オプションの設定方法」を参照してください。
例5-38は、コントロール・ヒントの情報が表示されたメッセージ・バンドル・ファイルのサンプルを示しています。各String配列の最初のエントリはメッセージ・キーで、2番目のエントリはこのキーに対応するロケール固有のString値です。
例5-38 ロケールに依存したコントロール・ヒントを持つリソース・ファイル
devguide.examples.readonlyvo.queries.Persons.PersonId_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter
devguide.examples.readonlyvo.queries.Persons.PersonId_FMT_FORMAT=00000
devguide.examples.readonlyvo.queries.Persons.PersonId_LABEL=Id
devguide.examples.readonlyvo.queries.Persons.Email_LABEL=Email Address
devguide.examples.readonlyvo.queries.Persons.LastName_LABEL=Surname
devguide.examples.readonlyvo.queries.Persons.FirstName_LABEL=Given Name
ADFビジネス・コンポーネントを使用して作成されたアプリケーションのモデル・レイヤーを国際化するには、各コンポーネントのリソース・バンドル・ファイルの翻訳バージョンを作成する必要があります。たとえば、QueryDataWithViewObjectsBundle.propertiesファイルのイタリア語バージョンはQueryDataWithViewObjectsBundle_it.propertiesという名前のファイルになり、より限定されたスイス・イタリア語バージョンはQueryDataWithViewObjectsBundle_it_ch.propertiesという名前のファイルになります。
リソース・バンドル・ファイルには、ローカライズが必要なメッセージ・キーのエントリと、そのローカライズ済の翻訳が含まれています。たとえば、イタリア語ロケールに対する数値フォーマット・マスクの翻訳が不要であったと仮定すると、QueryDataWithViewoObjectsビュー・オブジェクトのメッセージ・キーのイタリア語バージョンは、例5-39のようになります。実行時には、現在のユーザーのロケール設定に基づいてリソース・バンドルが自動的に使用されます。
例5-39 イタリア語にローカライズされたビュー・オブジェクト・コンポーネントのリソース・バンドル
devguide.examples.readonlyvo.queries.Persons.PersonId_FMT_FORMATTER=
oracle.jbo.format.DefaultNumberFormatter devguide.examples.readonlyvo.queries.Persons.PersonId_FMT_FORMAT=00000 devguide.examples.readonlyvo.queries.Persons.PersonId_LABEL=Codice Utente devguide.examples.readonlyvo.queries.Persons.Email_LABEL=Indirizzo Email devguide.examples.readonlyvo.queries.Persons.LastName_LABEL=Cognome devguide.examples.readonlyvo.queries.Persons.FirstName_LABEL=Nome
ビュー・オブジェクトには、基礎となるエンティティ・オブジェクトにマップされた属性以外にも、エンティティ・オブジェクトの属性値にマップされない計算属性を組み込むこともできます。計算属性としては、次の2種類があります。
SQL計算属性(値がSQL問合せのSELECTリスト内の式として取得される場合)
一時属性(値が問合せの一部として取得されない場合)
ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。
SQL計算属性を追加するには、ビュー・オブジェクトの概要エディタを使用します。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
SQL計算属性をビュー・オブジェクトに追加するには:
「アプリケーション・ナビゲータ」で、SQL計算属性を定義するビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。
「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力します。
Java属性の型を適切な値に設定します。
「列またはSQLにマップ済」チェック・ボックスを選択します。
「式」フィールドにSQL式を入力します。
たとえば、名前と姓の順序を変更するには、図5-47に示すように、LAST_NAME||', '||FIRST_NAMEと式を記述します。
属性名と一致するようにSQL列の別名を変更するかどうかを検討します。
データベースの問合せ列の型を確認し、必要に応じて長さ(または精度/スケール)を調整します。
「OK」をクリックします。
ビュー・オブジェクトの概要エディタでSQL計算属性を追加すると、ビュー・オブジェクトのXMLコンポーネント定義が更新され、新しい属性が反映されます。エンティティにマップされた属性の<ViewAttribute>タグは、例5-40に示すサンプルのようになります。エンティティにマップされた属性のプロパティの大部分は、基礎となるエンティティの属性からマップ先に継承されます。
例5-40 エンティティにマップされた属性のメタデータ
<ViewAttribute Name="LastName" IsNotNull="true" EntityAttrName="LastName" EntityUsage="User1" AliasName="LAST_NAME" > </ViewAttribute>
これに対し、SQL計算属性の<ViewAttribute>タグは、例5-41に示すサンプルのようになります。想定どおり、このタグにはEntityUsageまたはEntityAttrNameプロパティはなく、次のようにデータ型情報とともにSQL式が含まれます。
例5-41 SQL計算属性のメタデータ
<ViewAttribute Name="LastCommaFirst" IsUpdatable="false" IsPersistent="false" Precision="62" Type="java.lang.String" ColumnType="VARCHAR2" AliasName="FULL_NAME" Expression="LAST_NAME||', '||FIRST_NAME" SQLType="VARCHAR" > </ViewAttribute>
|
注意:
|
一時属性は通常、データベースに格納されない小計などの計算式を使用可能にする場合に使用されます。
作業を始める前に、次のようにします。
5.2.1項「エンティティ・ベースのビュー・オブジェクトの作成方法」および5.2.3項「エキスパート・モードの読取り専用ビュー・オブジェクトの作成方法」に従って、該当するビュー・オブジェクトを作成します。
一時属性をビュー・オブジェクトに追加するには:
「アプリケーション・ナビゲータ」で、一時属性を定義するビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。
「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力します。
Java属性の型を適切な値に設定します。
たとえば、名前と姓を連結する計算属性の型は、図5-48に示すようにString型になります。
「列またはSQLにマップ済」チェック・ボックスの選択を解除します。
「OK」をクリックします。
式に基づいて一時属性を作成するには:
「アプリケーション・ナビゲータ」で、一時属性を定義するビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規属性の作成」ボタンをクリックします。
「新規ビュー・オブジェクト属性」ダイアログで、属性の名前を入力します。
Java属性の型を適切な値に設定します。
「列またはSQLにマップ済」チェック・ボックスの選択を解除します。
一時属性にはSQL式は含まれません。
「値」フィールドの横にある「編集」をクリックし、属性の値を計算する式を定義します。
定義した式は、Groovy式言語を使用して評価されます。Groovyを使用すると、式や変数を文字列に挿入できます。この式は、ビュー・オブジェクト定義の一部として保存されます。Groovyの詳細は、3.6項「Groovyサポートの概要」を参照してください。
「式の編集」ダイアログで、表示されているフィールドに式を入力します。
参照する属性には、ベース・エンティティ・オブジェクトで定義されている任意の属性を使用できます。式にある属性のうち、ビュー・オブジェクトの基礎となるエンティティ・オブジェクトで定義されていない属性は参照しないでください。
適切な再計算設定を選択します。
「常に」(デフォルト)を選択すると、行のいずれかの属性が変更されるたびに式の評価が行われます。「なし」を選択すると、行が作成された場合にのみ式の評価が行われます。
必要に応じて、式の再計算を実行するタイミングの条件を指定できます。
たとえば、「次の式に基づく」フィールドに次のような式を入力すると、Quantity属性またはUnitPrice属性が変更された場合に属性が再計算されます。
return (adf.object.isAttributeChanged("Quantity") || adf.object.isAttributeChanged("UnitPrice"));
定義した値式またはオプションの再計算式がベース・エンティティ・オブジェクトの属性を参照する場合は、「式の編集」ダイアログでこれを依存性として定義する必要があります。「使用可能」リストでそれぞれの属性を特定し、それを「選択済」リストに移動します。
「OK」をクリックして式を保存し、「新規ビュー・オブジェクト属性」ダイアログに戻ります。
「OK」をクリックします。
ビュー・オブジェクトには、エンティティ・オブジェクト・レベルではそれ自体が一時属性である、エンティティにマップされた属性を組み込むことができます。
エンティティ・ベースのビュー・オブジェクトにエンティティ・オブジェクトの一時属性を追加するには:
アプリケーション・ナビゲータで、エンティティ・オブジェクトの慣用名に基づいて一時属性を追加するビュー・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックし、「エンティティからの追加」ボタンをクリックします。
「属性」ダイアログで、目的の一時属性を「使用可能」リストから「選択済」リストに移動します。
「OK」をクリックします。
ビジネス・コンポーネント・ブラウザを使用してデータ・モデルをテストする場合、一時属性の使用方法を確認できます。図5-49は、SQL計算属性(LastCommaFirst)、一時属性(FirstDotLast)およびエンティティから導出された一時属性(FullName)を使用して作成された3つの属性を示しています。
特定のビュー・オブジェクト一時属性に対する属性レベルの検証規則は、エンド・ユーザーまたはプログラム・コードによる属性値の変更が試行されるとトリガーされます。属性を設定する順序は指定できないため、属性レベルの検証規則は、規則の成否がその属性の候補値のみに依存する場合にのみ使用する必要があります。
ビュー・オブジェクト一時属性に検証規則を追加する手順は、宣言的検証規則の作成と同じで、「検証ルールの追加」ダイアログを使用します。このダイアログを開くには、ビュー・オブジェクトの概要エディタで、「属性」ページの「検証ルールの追加」アイコンをクリックします。まず、属性リストから一時属性を選択する必要があります。
一時属性に検証規則を追加するには:
「アプリケーション・ナビゲータ」で、目的のビュー・オブジェクトをダブルクリックします。
概要エディタの「属性」ナビゲーション・タブをクリックします。
検証規則を追加する一時属性を選択し、「検証ルール」Validation Rulesセクションを展開して、「検証ルールの追加」アイコンをクリックします。
新しい検証規則を追加すると、「検証ルールの追加」ダイアログが表示されます。
「ルール・タイプ」ドロップダウン・リストから、目的の検証規則のタイプを選択します。
ダイアログの設定を使用して新しい規則を構成します。
このコントロールの内容は、選択する検証規則の種類によって異なります。様々な検証規則の詳細は、7.4項「組込みの宣言的な検証規則の使用」を参照してください。
必要に応じて、「検証実行」タブをクリックして、依存属性や事前条件式などの規則の実行基準を入力できます。詳細は、7.6項「検証実行のトリガー」を参照してください。
「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、7.7項「検証エラー・メッセージの作成」を参照してください。
「OK」をクリックします。
ビュー・オブジェクトの概要エディタで一時属性を追加すると、ビュー・オブジェクトのXMLコンポーネント定義が更新され、新しい属性が反映されます。XMLでは、一時属性の<ViewAttribute>タグは、SQL計算属性の場合と類似していますが、Expressionプロパティがありません。
一時属性がGroovy式に準拠している場合は、例5-42に示すように、適切な属性内に<TransientExpression>タグが作成されます。
一時属性は、データ値のプレースホルダです。一時属性の「更新可能」プロパティを「新規の間」または「常に」に変更すると、エンド・ユーザーは属性値を入力できるようになります。一時属性に計算値を表示する場合は通常、「更新可能」プロパティを「なし」に設定し、値を計算するカスタムJavaコードを記述します。
ビュー・オブジェクトに一時属性を追加した後、この属性を計算済一時属性にするには、ビュー・オブジェクトの概要エディタにある「Java」ページの「編集」アイコンをクリックして開く「Java」ダイアログで、カスタム・ビュー行クラスを有効にし、アクセッサ・メソッドの生成を選択する必要があります。次に、一時属性のアクセッサ・メソッドの内部で、計算済値を戻すJavaコードを記述します。例5-42に示すStaffListRowImpl.javaビュー行クラスには、getLastCommaFirst()メソッドの計算値を戻すJavaコードが含まれています。
// In StaffListRowImpl.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();
}
