Oracle® Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド

11gリリース2(11.1.2.3.0)

B66160-03(原本部品番号:E17272-04)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

リリース11.1.2.3.0用のこのガイドでの新しい情報

1 Oracle ADFを使用したJava EE Webアプリケーションの構築の概要

- 1.1 Oracle ADFの概要

- 1.2 Oracle ADFによる開発

- 1.2.1 中核となる開発手順

- 1.2.2 補完的な開発タスク

- 1.3 Summitデモ・アプリケーションの概要

- 1.3.1 アプリケーション・リソースのダウンロード方法

- 1.3.2 Summitデモ・アプリケーションのインストールと実行方法

- 1.3.3 Summitデモ・アプリケーション・コードの考察

2 Java EE WebアプリケーションでのADFモデル・データ・バインディングの使用

- 2.1 ADFデータ・バインディングの概要

- 2.2 ADFデータ・コントロールを使用したビジネス・サービスの公開

- 2.2.1 ADFデータ・コントロールの作成方法

- 2.2.2 データ・コントロール作成時のプロジェクト内の処理

- 2.2.2.1 DataControls.dcxの概要エディタ

- 2.2.2.2 「データ・コントロール」パネル

- 2.3 「データ・コントロール」パネルの使用

- 2.3.1 「データ・コントロール」パネルの使用方法

- 2.3.2 「データ・コントロール」パネルを使用したUIコンポーネントの作成時の処理

- 2.3.3 実行時に行われる処理

- 2.3.4 イテレータの結果のキャッシュについて

- 2.3.5 検証の構成について

- 2.3.6 カスタム・セッションBeanのアクセッサ・メソッドについて

3 データ・コントロールへのビジネス・ロジックの追加

- 3.1 データ・コントロールへのビジネス・ロジックの追加の概要

- 3.2 データ・コントロールの構成

- 3.2.1 データ・コントロールの編集方法

- 3.2.2 データ・コントロール編集時の処理

- 3.3 属性の使用

- 3.3.1 属性の更新可能性の制御方法

- 3.3.2 属性の静的なデフォルト値を定義する方法

- 3.3.3 Groovy式を使用してデフォルト値を定義する方法

- 3.3.4 Groovy式を使用したデフォルト値の作成時の処理

- 3.3.5 属性へのUIヒントの設定方法

- 3.3.6 属性へのUIヒントの設定時の処理

- 3.4 Beanへの一時属性の追加

- 3.4.1 一時属性の追加方法

- 3.4.2 一時属性の追加時の処理

- 3.5 属性への検証ルールの宣言的な定義

- 3.5.1 属性への検証ルールの追加方法

- 3.5.2 検証規則の追加時の処理

- 3.5.3 組込みの宣言的な検証ルールの使用方法

- 3.5.3.1 比較に基づいた検証

- 3.5.3.2 比較に基づく検証時の処理

- 3.5.3.3 値リストを使用した検証

- 3.5.3.4 リスト値を使用した検証時の処理

- 3.5.3.5 値が特定の範囲内にあることの確認

- 3.5.3.6 Range Validatorの使用時の処理

- 3.5.3.7 バイトまたは文字数に対する検証

- 3.5.3.8 バイトまたは文字数に対する検証時の処理

- 3.5.3.9 正規表現を使用した検証

- 3.5.3.10 正規表現を使用した検証時の処理

- 3.5.4 検証とビジネス・ルールでのGroovy式の使用方法

- 3.5.4.1 Groovy検証式でのBeanメソッドの参照

- 3.5.4.2 true/false式を使用した検証

- 3.5.4.3 true/false式を使用した検証時の処理

- 3.5.5 検証エラー・メッセージの作成方法

- 3.5.5.1 検証エラー・メッセージの作成

- 3.5.5.2 検証メッセージのローカライズ

- 3.5.5.3 Groovyを使用した条件付きでのエラー・メッセージの呼出し

- 3.5.5.4 エラー・メッセージへのGroovy式の埋込み

- 3.5.6 検証例外の重大度レベルの設定方法

- 3.6 名前付き基準を使用した結果セットのフィルタリング

- 3.6.1 名前付き基準の用途

- 3.6.2 名前付き基準を宣言的に作成する方法

- 3.6.3 名前付き基準の作成時の処理

- 3.6.4 名前付き基準でのバインド変数の使用方法

- 3.6.5 名前付き基準でのバインド変数使用時の処理

- 3.6.6 ネストされた式について

- 3.6.7 名前付き基準にユーザー・インタフェース・ヒントを設定する方法

- 3.7 Oracle ADFモデル・テスターを使用したBeanメタデータのテスト

- 3.7.1 Oracle ADFモデル・テスターの実行方法

- 3.7.2 Oracle ADFモデル・テスターを更新してプロジェクトの変更を表示する方法

- 3.7.3 Oracle ADFモデル・テスター使用時の処理

- 3.7.4 ビジネス・レイヤーの検証のテスト方法

- 3.7.5 代替言語のメッセージ・バンドルおよびUIヒントのテスト方法

- 3.7.6 行の作成およびデフォルト値の生成のテスト方法

- 3.7.7 Oracle ADFモデル・テスターを使用した名前付き基準のテスト方法

- 3.8 Groovy言語サポート

- 3.8.1 Groovy式でのADFオブジェクトの参照方法

- 3.8.2 Groovy式でのADFメソッドおよび属性の参照方法

4 データバインドされた基本的なページの作成

- 4.1 データバインドされた基本的なページの作成について

- 4.2 属性を使用したテキスト・フィールドの作成方法

- 4.2.1 テキスト・フィールドの作成方法

- 4.2.2 テキスト・フィールドの作成時の処理

- 4.2.2.1 イテレータ・バインディングの作成および使用

- 4.2.2.2 値バインディングの作成および使用

- 4.2.2.3 EL式を使用したUIコンポーネントのバインド

- 4.3 基本的なフォームの作成

- 4.3.1 フォームの作成方法

- 4.3.2 フォームの作成時の処理

- 4.4 レンジ・ナビゲーションのフォームへの組入れ

- 4.4.1 フォームへのナビゲーション・コントロールの挿入方法

- 4.4.2 コマンド・ボタンの作成時の処理

- 4.4.2.1 組込みナビゲーション操作のアクション・バインディング

- 4.4.2.2 イテレータのRangeSize属性

- 4.4.2.3 EL式を使用したナビゲーション操作へのバインド

- 4.5 パラメータをとるメソッドを使用するフォームの作成

- 4.5.1 パラメータをとるメソッドを使用するフォームまたは表の作成方法

- 4.5.2 パラメータをとるメソッドを使用するフォームの作成時の処理

- 4.5.3 実行時に行われる処理: メソッドのパラメータの設定

- 4.5.4 メソッドによるパラメータの設定について

- 4.5.5 パラメータのかわりのコンテキスト・イベントの使用について

- 4.6 既存レコードを編集するフォームの作成

- 4.6.1 編集フォームの作成方法

- 4.6.2 値を変更するメソッドの使用時の処理

- 4.6.2.1 メソッド・バインディング

- 4.6.2.2 EL式を使用したメソッドへのバインド

- 4.6.3 マージ・メソッドと永続化メソッドとの違いについて

- 4.6.4 宣言メソッドの上書きについて

- 4.7 入力フォームの作成

- 4.7.1 タスク・フローを使用した入力フォームの作成方法

- 4.7.2 タスク・フローを使用した入力フォームの作成時の処理

- 4.7.3 実行時に行われる処理: メソッド・アクティビティからのCreateアクション・バインディングの起動

- 4.8 フォーム上のUIコンポーネントおよびバインディングの変更

5 ADFによるデータバインドされた表の作成

- 5.1 表の追加について

- 5.2 基本表の作成

- 5.2.1 基本表の作成方法

- 5.2.2 表の作成時の処理

- 5.2.2.1 表のイテレータと値バインディング

- 5.2.2.2 ADF Faces表のJSFページのコード

- 5.2.3 表での現在行の設定について

- 5.3 編集可能な表の作成

- 5.3.1 編集可能な表の作成方法

- 5.3.2 編集可能な表の作成時の処理

- 5.4 入力表の作成

- 5.4.1 入力表の作成方法

- 5.4.2 入力表の作成時の処理

- 5.4.3 実行時に行われる処理: 作成および部分ページ・リフレッシュの動作方法

- 5.4.4 行の作成および列のソートについて

- 5.5 表に表示される属性の変更

6 マスター/ディテール・データの表示

- 6.1 マスター/ディテール・データの表示の概要

- 6.2 「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別

- 6.3 表およびフォームを使用したマスター/ディテール・オブジェクトの表示

- 6.3.1 表およびフォームでのマスター/ディテール・オブジェクトの表示方法

- 6.3.2 マスター/ディテール表およびフォームの作成時の処理

- 6.3.2.1 JSFページで生成されるコード

- 6.3.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

- 6.3.3 実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ

- 6.3.4 別々のページへのマスター/ディテール・ウィジェットの表示について

- 6.4 ツリーを使用したマスター/ディテール・オブジェクトの表示

- 6.4.1 ツリーでのマスター/ディテール・オブジェクトの表示方法

- 6.4.2 ADFデータバインド・ツリーの作成時の処理

- 6.4.2.1 JSFページで生成されるコード

- 6.4.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

- 6.4.3 実行時に行われる処理: ADFデータバインド・ツリーの表示

- 6.5 ツリー表を使用したマスター/ディテール・オブジェクトの表示

- 6.5.1 ツリー表でのマスター/ディテール・オブジェクトの表示方法

- 6.5.2 データバインド・ツリー表の作成時の処理

- 6.5.2.1 JSFページで生成されるコード

- 6.5.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

- 6.5.3 実行時に行われる処理: イベント

- 6.5.4 TargetIteratorプロパティの使用

- 6.6 ツリーおよび表での選択イベントの使用

- 6.6.1 ツリーおよび表での選択イベントの使用方法

- 6.6.2 実行時に行われる処理: RowKeySetオブジェクトとSelectionEventイベント

7 データバインドされた選択リストの作成

- 7.1 選択リストの概要

- 7.2 単一選択リストの作成

- 7.2.1 固定値を含む単一選択リストの作成方法

- 7.2.2 動的に生成される値を含む単一選択リストの作成方法

- 7.2.3 固定選択リストの作成時の処理

- 7.2.4 動的選択リストの作成時の処理

- 7.3 ナビゲーション・リスト・バインディングを持つリストの作成

8 データバインドされた検索フォームの作成

- 8.1 検索フォームの作成の概要

- 8.1.1 問合せ検索フォーム

- 8.1.2 クイック問合せ検索フォーム

- 8.1.3 フィルタ処理された表とQuery-by-Example検索

- 8.2 問合せ検索フォームの作成

- 8.2.1 結果表またはツリー表付きの問合せ検索フォームの作成方法

- 8.2.2 問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

- 8.2.3 保存済の検索をMDSに保存する方法

- 8.2.4 問合せフォーム作成時の処理

- 8.2.5 実行時に行われる処理: 検索フォーム

- 8.3 検索フォーム・プロパティの設定

- 8.3.1 問合せコンポーネントに検索フォーム・プロパティを設定する方法

- 8.4 クイック問合せ検索フォームの作成

- 8.4.1 結果表またはツリー表付きのクイック問合せ検索フォームの作成方法

- 8.4.2 クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

- 8.4.3 クイック問合せのレイアウト書式を設定する方法

- 8.4.4 クイック問合せ検索フォームの作成時の処理

- 8.4.5 実行時に行われる処理: クイック問合せ

- 8.5 スタンドアロンのフィルタ処理された検索表の作成

9 ADF Java EEアプリケーションのデプロイ

- 9.1 ADF Java EE Webアプリケーションのデプロイの概要

- 9.1.1 統合WebLogic Serverを使用したアプリケーションの開発

- 9.1.2 スタンドアロン・アプリケーション・サーバー用のアプリケーションの開発

- 9.2 統合WebLogic ServerでのJava EEアプリケーションの実行

- 9.2.1 統合WebLogic Serverでのアプリケーションの実行方法

- 9.2.2 統合WebLogic Serverでのメタデータを含むアプリケーションの実行方法

- 9.3 アプリケーションの準備

- 9.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

- 9.3.2 デプロイメント・プロファイルの作成方法

- 9.3.2.1 WARデプロイメント・プロファイルの作成

- 9.3.2.2 MARデプロイメント・プロファイルの作成

- 9.3.2.3 EJB JARデプロイメント・プロファイルの作成

- 9.3.2.4 アプリケーションレベルのEARデプロイメント・プロファイルの作成

- 9.3.2.5 共有ライブラリとしてのカスタマイズ・クラスの配布

- 9.3.2.6 デプロイメント・プロファイル・プロパティの表示および変更

- 9.3.2.7 JARへのカスタマイズ・クラスの追加

- 9.3.3 デプロイメント・ディスクリプタの作成および編集方法

- 9.3.3.1 デプロイメント・ディスクリプタの作成

- 9.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

- 9.3.3.3 WebLogic互換のapplication.xmlファイルの構成

- 9.3.3.4 WebLogic互換のweb.xmlファイルの構成

- 9.3.3.5 Real User Experience Insightに対するアプリケーションの有効化

- 9.3.4 ADF Securityを有効にしたアプリケーションのデプロイ方法

- 9.3.4.1 Oracle Single Sign-On(SSO)を使用して実行するアプリケーション

- 9.3.4.2 WebLogic Serverのセキュリティ構成

- 9.3.4.3 WebSphere Serverのセキュリティ構成

- 9.3.5 クラスタ環境でのメモリー・スコープのレプリケート方法

- 9.3.6 アプリケーションをADF MBeanに対して有効化する方法

- 9.3.7 Oracle WebLogic Server用のJDBCデータソースについて

- 9.4 アプリケーションのデプロイ

- 9.4.1 JDeveloperからWebLogic Serverへのデプロイ方法

- 9.4.2 デプロイメント用のEARファイルの作成方法

- 9.4.3 ADFライブラリについて

- 9.4.4 ADFライブラリに適用された新しいカスタマイズのデプロイ方法

- 9.4.4.1 デプロイ済アプリケーションへのカスタマイズのエクスポート

- 9.4.4.2 JARへのカスタマイズのデプロイ

- 9.4.5 ADFライブラリについて

- 9.4.6 EARファイルとパッケージ化について

- 9.4.7 スクリプトとAntを使用したアプリケーションのデプロイ方法

- 9.4.8 JDeveloperランタイム・ライブラリについて

- 9.5 デプロイ後の構成

- 9.5.1 アプリケーションの移行方法

- 9.5.2 ADF MBeanを使用したアプリケーションの構成方法

- 9.5.3 WebSphereの結果セット再利用の構成方法

- 9.6 アプリケーションのテストとデプロイの検証

Oracle® Fusion Middleware

Oracle Application Development Framework Java EE開発者ガイド

11gリリース2(11.1.2.3.0)

B66160-03(原本部品番号:E17272-04)

2012年8月

Java EE、ADFモデル、ADF ControllerおよびADF Facesリッチ・クライアントのコンポーネントを使用してWebベース型アプリケーションの開発とデプロイを行う方法について説明した、Oracle Application Development Framework(Oracle ADF)開発者向けのドキュメントです。

Oracle Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド, 11g リリース2 (11.1.2.3.0)

B66160-03

Copyright (C) 2010, 2012, Oracle and/or its affiliates.All rights reserved.

原本主著者: Robin Whitmore、Peter Jew、Patrick Keegan

原本協力著者: Lynn Munsinger, Jeff Falk, Jim Pham

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

Oracle Application Development Framework Java EE開発者ガイドへようこそ

対象読者

このドキュメントは、Oracle Application Development Framework (Oracle ADF)を使用してデータベース中心のJava EEアプリケーションを作成およびデプロイする必要のあるエンタープライズ開発者を対象としています。このマニュアルでは、Enterprise JavaBeans (EJB)、ADFモデル、ADFコントローラおよびADF Facesテクノロジを使用してWebアプリケーションを作成する方法を説明します。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

- 『Oracle Fusion Middleware Oracle Application Development FrameworkのためのFusion開発者ガイド』

- 『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』

- Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイド

- Oracle Fusion Middleware Skin Editor Oracle Application Development Frameworkユーザーズ・ガイド

- 『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』

- 『Oracle Fusion Middleware Oracle Application Development Frameworkのためのデスクトップ統合開発者ガイド』

- Oracle Fusion Middleware Oracle Application Development Frameworkモバイル・ブラウザ開発者ガイド

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

- 『Oracle Fusion Middleware High Availability Guide』

- 『Oracle Fusion Middleware Oracle JDeveloperインストレーション・ガイド』

- Oracle Fusion Middleware Oracle Application Development Framework Skin Editorインストレーション・ガイド

- Oracle JDeveloperのオンライン・ヘルプ

- Oracle JDeveloper 11gリリース・ノート(JDeveloperインストール内およびOracle Technology Networkから入手)

- Oracle Fusion Middleware Java API Reference for Oracle ADF Model

- Oracle Fusion Middleware Java API Reference for Oracle ADF Controller

- Oracle Fusion Middleware Java API Reference for Oracle ADF Lifecycle

- Oracle Fusion Middleware Java API Reference for Oracle ADF Faces

- Oracle Fusion Middleware Javascript API Reference for Oracle ADF Faces

- Oracle Fusion Middleware Java API Reference for Oracle ADF Data Visualization Components

- Oracle Fusion Middleware Java API Reference for Oracle ADF Share

- Oracle Fusion Middleware Java API Reference for Oracle Business Component Browser

- Oracle Fusion Middleware Generic Domains Java API Reference for Oracle ADF Business Components

- Oracle Fusion Middleware interMedia Domains Java API Reference for Oracle ADF Business Components

- Oracle Fusion Middleware Java API Reference for Oracle Metadata Service (MDS)

- Oracle Fusion Middlewareタグ・リファレンス for Oracle ADF Faces

- Oracle Fusion Middlewareタグ・リファレンス for Oracle ADF Facesスキン・セレクタ

- Oracle Fusion Middleware Data Visualization Toolsタグ・リファレンス for Oracle ADF Faces

- Oracle Fusion Middleware Data Visualization Toolsタグ・リファレンス for Oracle ADFスキン・セレクタ

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

リリース11.1.2.3.0用のこのガイドでの新しい情報

このマニュアルは、リリース11.1.2.3.0の情報で更新されています。次の表に、変更された項を示します。

このリリースでOracle JDeveloperおよびOracle Application Development Framework (Oracle ADF)に加えられた変更については、Oracle Technology Networkの新しい情報に関するページ(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html)を参照してください。

セクション

変更内容

第9章「ADF Java EEアプリケーションのデプロイ」

9.1項「ADF Java EE Webアプリケーションのデプロイの概要」

GlassFish Serverへのアプリケーションのデプロイに関する追加情報と、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』およびOracle Fusion Middleware Oracle Application Development Framework管理者ガイドに対する参照情報が記載されています。

1 Oracle ADFを使用したJava EE Webアプリケーションの構築の概要

この章では、EJB 3.0アノテーションを使用するセッションBeanとエンティティBean、Java Persistence API(JPA)、ADFモデル、ADF ControllerおよびADF Facesリッチ・クライアントによるWebアプリケーションの構築に使用される場合のOracle Application Development Framework(Oracle ADF)のアーキテクチャと主な機能について説明します。

この章には、次の項が含まれます:

- 1.1項「Oracle ADFの概要」

- 1.2項「Oracle ADFによる開発」

- 1.3項「Summitデモ・アプリケーションの概要」

1.1 Oracle ADFの概要

Oracle Application Development Framework (Oracle ADF)は、JavaプラットフォームEnterprise Edition (Java EE)標準とオープン・ソース・テクノロジを基盤とするエンドツーエンドのアプリケーション・フレームワークであり、エンタープライズ・アプリケーションの実装を簡略化および迅速化するものです。Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するエンタープライズ・ソリューションを構築する場合は、Oracle ADFで作業を簡素化できます。Oracle JDeveloperとOracle ADFを組み合せて使用すると、設計からデプロイに至る開発ライフサイクル全体に対応した環境が提供され、ドラッグ・アンド・ドロップによるデータ・バインディング、ビジュアルUI設計、チーム開発などの組込み機能を使用できます。

図1-1は、Webアプリケーション・アーキテクチャを構成する各Oracle ADFモジュールの場所を示しています。フレームワークの中核モジュールは、宣言的なデータ・バインディング機能であるADFモデルです。ADF Modelレイヤーにより、統一化されたアプローチを使用して、各ユーザー・インタフェースをコード記述なしで任意のビジネス・サービスにバインドできます。アプリケーション・テクノロジ・スタックを構成する、EJB以外の他のモジュールは次のとおりです:

- ADF Facesリッチ・クライアント: JavaServer Faces(JSF)で構築されるWebアプリケーションに豊富なAJAX対応のUIコンポーネント・ライブラリを提供します。ADF Facesの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。

- ADF Controller: JSFをADF Modelに統合します。ADF Controllerは、JSFページ間のみでなく、メソッド・コールやその他のタスク・フローなど、他のアクティビティ間に制御を渡す再利用可能なタスク・フローなどの追加機能を提供することにより、標準JSFコントローラを拡張します。ADFコントローラの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFタスク・フロー・スタート・ガイドに関する項を参照してください。

注意:

ADF Facesに加えて、Oracle ADFはSwing、JSPおよび標準のJSFビュー・テクノロジもサポートしています。これらのテクノロジの詳細は、Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイドを参照してください。Oracle ADFでは、アプリケーションのビュー・レイヤーとしてのMicrosoft Excelの使用もサポートされます。詳細は、『Oracle Fusion Middleware Oracle Application Development Frameworkのためのデスクトップ統合開発者ガイド』を参照してください。

図1-1 単純なADFアーキテクチャ

1.2 Oracle ADFによる開発

Oracle ADFでは、開発プロセスを通して宣言的なプログラミング・パラダイムを使用することが重視されます。これによって、ユーザーは、アプリケーション作成のロジックに集中でき、実装の詳細を知る必要がなくなります。Oracle ADFとともにJDeveloperを使用すると、データ・アクセス、検証、ページ・コントロールおよびナビゲーション、ユーザー・インタフェース設計、データ・バインディングでアプリケーションの宣言的メタデータを自動的に管理する生産性の高い環境が実現します。

1.2.1 中核となる開発手順

高度なJava EE Webアプリケーションの宣言的開発プロセスには、通常、次の中核となる手順が含まれます。

- アプリケーション・ワークスペースの作成: ウィザードを使用して、選択したテクノロジに必要なライブラリと構成の追加およびパッケージとディレクトリを含むプロジェクトへのアプリケーションの構成が、JDeveloperによって自動的に行われます。詳細は、Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイドのアプリケーションの作成方法に関する項を参照してください。

- 永続モデルの作成: ウィザードやダイアログを使用して、データベース表からEJB 3.0エンティティBeanを作成します。これらのBeanから、アプリケーションのページで使用されるファサードであるセッションBeanを作成します。JDeveloperでEJBを使用する方法の詳細は、Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイドのEJBおよびJPAコンポーネントを使用した開発に関する項を参照してください。

- サービスのデータ・コントロールの作成: エンティティBeanとセッションBeanを作成したら、メタデータ・インタフェースを使用して、EJB実装を抽象化し、使用されるプロパティ、メソッドおよびタイプに関する情報などの操作とデータ・コレクションを表すデータ・コントロールを作成します。これらのデータ・コントロールは「データ・コントロール」パネルに表示され、これらをページにドラッグしてデータバインドされたUIコンポーネントを作成できます。詳細は、第2章「Java EE WebアプリケーションでのADFモデル・データ・バインディングの使用」を参照してください。

- データ・コントロールへの宣言的なメタデータの追加: データ・コントロールにUIコントロール・ヒント、検証ルール、検索フォームでの使用条件やその他の機能を追加できます。詳細は、第3章「データ・コントロールへのビジネス・ロジックの追加」を参照してください。

- JSFによるユーザー・インタフェースの実装: JDeveloperの「データ・コントロール」パネルには、アプリケーションのBeanが表示されます。ユーザー・インタフェースの作成は簡単で、オブジェクトをページにドラッグし、ベースとなるデータを表示するUIコンポーネントを選択するだけです。データバインドされていないUIコンポーネントの場合、コンポーネント・パレットを使用してコンポーネントをドラッグ・アンド・ドロップします。JDeveloperによって、すべてのページ・コードが作成されます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のJSFを使用したユーザー・インタフェースの実装に関する項を参照してください。
特定のタイプのWebページの作成については、このガイドの次の箇所を参照してください。

- 第4章「データバインドされた基本的なページの作成」

- 第5章「ADFによるデータバインドされた表の作成」

- 第6章「マスター/ディテール・データの表示」

- 第7章「データバインドされた選択リストの作成」

- 第8章「データバインドされた検索フォームの作成」

- アプリケーションのデプロイ: ウィザードとエディタを使用して、デプロイメント・ディスクリプタ、JARファイルおよびアプリケーション・サーバー接続を作成します。詳細は、第9章「ADF Java EEアプリケーションのデプロイ」を参照してください。

注意:

Oracle ADFモジュールを使用したJava EEアプリケーションの開発プロセスは、Fusion Webアプリケーションの開発と非常によく似ています。主な違いは、Fusion Webアプリケーションでは、バックエンド・サービスにADF Business Componentsが使用されることです。両方のアプリケーション・タイプで開発プロセスと開発手順が同じ場合、このガイドでは、その詳細について、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照します。

Fusion開発者ガイド内のADF Business Componentsに関する情報(エンティティ・オブジェクトやビュー・オブジェクトなど)は無視してください。EJB/JPAに関する同様の情報は、Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイドのEJBおよびJPAコンポーネントを使用した開発に関する項を参照してください。

1.2.2 補完的な開発タスク

Oracle ADFを使用した前述のJava EEアプリケーションの中核となる手順に加え、JDeveloperでは次のタスクを実行するためのツールも提供しています。これらのタスクの詳細は、このガイドで説明していません。

- データベース・オブジェクトのモデル化: データベースのオフライン・レプリカを作成し、JDeveloperのエディタとダイアグラマを使用して定義の編集やスキーマの更新を行うことができます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のデータベース・オブジェクト定義によるモデル化に関する項を参照してください。

- ユースケースの作成: UMLモデラーを使用して、アプリケーションのユースケースを作成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のユースケースの作成に関する項を参照してください。

- アプリケーション・コントロールおよびナビゲーションの設計: ダイアグラマを使用して、アプリケーション・コントロールおよびナビゲーションのフローを視覚的に決定します。JDeveloperによって、ベースとなるXMLが作成されます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFタスク・フローを使用したアプリケーション・コントロールおよびナビゲーションの設計に関する項を参照してください。

- 共有リソースの識別: アプリケーションにドラッグ・アンド・ドロップするだけで、インポートされたライブラリを表示したり、使用できるリソース・ライブラリを使用します。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の共有リソースの識別に関する項を参照してください。

- アプリケーションの保護: エディタを使用してロールを作成し、テスト・ユーザーに実装します。フラット・ファイル・エディタを使用して、これらのロールにセキュリティ・ポリシーを定義し、アプリケーション内の特定のリソースに割り当てます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

- カスタマイズ可能なページとアプリケーションの開発: Oracle Metadata Services (MDS)のカスタマイズ機能を使用して、顧客がカスタマイズでき、かつ容易にアップグレードできるアプリケーション、エンド・ユーザーがアプリケーションのUIを実行時に変更できるページおよび実行時に完全にカスタマイズ可能なアプリケーションを作成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「MDSによるアプリケーションのカスタマイズ」および「実行時のユーザーによるカスタマイズの許可」を参照してください。

- テストとデバッグ: JDeveloperには、統合されたアプリケーション・サーバーが含まれていて、パッケージ化してデプロイすることなく、アプリケーションを完全にテストできます。JDeveloperには、ブレークポイントを設定してデータを調べることができるツールのADF宣言デバッガも含まれています。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「ADFコンポーネントのテストとデバッグ」を参照してください。

1.3 Summitデモ・アプリケーションの概要

このガイドの補足として、Java EEおよびOracle ADFのWebアプリケーション・テクノロジ・スタックを使用してトランザクション・ベースのWebアプリケーションを作成する方法を示すために、Summitデモ・アプリケーションが作成されました。デモ・アプリケーションを通して、要点が示され、サンプル・コードが提供されます。

1.3.1 アプリケーション・リソースのダウンロード方法

Summitアプリケーションには、既存のOracleデータベースが必要です。Summitアプリケーションの実行には、Oracle JDeveloper 11gリリース2を使用します。

Summitアプリケーションをインストールする前に、次の手順に従います。

- Oracle JDeveloperをインストールします。アプリケーションのプロジェクトを表示し、JDeveloper統合サーバーでアプリケーションを実行するには、Oracle JDeveloper 11gリリース2のStudio構成が必要です。Oracle JDeveloperは、次のURLからダウンロードできます。

http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

- SummitアプリケーションのZIPファイル(Summit_JPA.zip)をダウンロードします。このZIPファイルは次のURLからダウンロードできます。

http://www.oracle.com/webfolder/technetwork/jdeveloper/downloads/Summit_JPA/Summit_JPA.zip

- Summitデータベース・スキーマ(Summit_Schema.zip)をダウンロードします。このZIPファイルは次のURLからダウンロードできます。

http://www.oracle.com/webfolder/technetwork/jdeveloper/downloads/Summit_JPA/Summit_Schema.zip

- Oracleデータベースをインストールします。Summitアプリケーションには、そのデータ用のデータベースが必要です。
Oracleデータベース用にSQLスクリプトが作成されているため、11gやXEなどのOracle RDBMSの特定のバージョンが必要になります。スクリプトはOracle Liteにはインストールされません。Oracle Liteやその他のデータベースを使用する場合は、データベース・スクリプトを適宜変更する必要があります。Oracleデータベースは、次のURLからダウンロードできます。

http://www.oracle.com/technetwork/index.html

特に、ローカル・マシンにデータベースを設定するには、容量を節約できるOracle Express Edition(XE)が最適です。Oracle Express Editionは次のURLからダウンロードできます。

http://www.oracle.com/technetwork/database/express-edition/overview/index.html

1.3.2 Summitデモ・アプリケーションのインストールと実行方法

Summitデモ・アプリケーションをインストールして実行する方法は、次のドキュメントの手順に従ってください。

http://www.oracle.com/technetwork/developer-tools/jdev/learnmore/summitjpainstructions-364887.pdf

1.3.3 Summitデモ・アプリケーション・コードの考察

Summitアプリケーションは、Modelという名前のビジネス・サービス・プロジェクトとViewControllerという名前のWebユーザー・インタフェース・プロジェクトで構成されます。ViewControllerプロジェクトを実行することによってSummitアプリケーションを実行します。ViewControllerプロジェクトでは、ビュー・テクノロジとしてJavaServer Faces(JSF)を使用し、Modelプロジェクトでは、EJBとの対話にADFモデル・レイヤーを使用します。

図1-2は、アプリケーション・ワークスペースのファイルを開いた後のアプリケーション・ナビゲータを示しています。

図1-2 Oracle JDeveloperのSummitデモ・アプリケーション・プロジェクト

Oracle JDeveloperでデモ・アプリケーションのプロジェクトを開くと、各プロジェクト内のアーティファクトの確認を開始できます。Modelプロジェクトには、Webアプリケーションにデータを表示できるようにするJava クラスとメタデータ・ファイルが含まれています。modelパッケージにはJavaクラスおよびDataControls.dcxファイルが含まれています。persdef.modelパッケージにはデータ・コントロールの構造ファイルが含まれており、これらにはmodelパッケージの一部のBeanの宣言的メタデータが含まれています。図1-3は、Modelプロジェクトおよび関連するディレクトリを示しています。

図1-3 JDeveloperでのModelプロジェクト

ViewControllerプロジェクトには、バッキングBean、デプロイメント・ファイル、JSPXファイルなど、Webインタフェース用のファイルが含まれています。「アプリケーション・ソース」ノードには、マネージドBeanおよびOracle ADFによってバインド・データの表示に使用されるメタデータなど、Webクライアントで使用されるコードが含まれています。「Webコンテンツ」ノードには、JSPファイル、イメージ、スキン・ファイル、デプロイメント・ディスクリプタ、ライブラリなどのWebファイルが含まれています。図1-4は、ViewControllerプロジェクトおよび関連するディレクトリを示しています。

図1-4 JDeveloperでのViewController プロジェクト

2 Java EE WebアプリケーションでのADFモデル・データ・バインディングの使用方法

この章では、EJBセッションBeanに対してADFモデルのデータ・コントロールを作成する方法、さらに「データ・コントロール」パネルを使用して、データバインドされたUIコンポーネントをJSF Webページで作成する方法について説明します。

この章には、次の項が含まれます:

- 2.1項「ADFデータ・バインディングの概要」

- 2.2項「ADFデータ・コントロールを使用したサービスの公開」

- 2.3項「「データ・コントロール」パネルの使用」

UIコンポーネントにバインドするビジネス・サービスの構成の詳細は、第3章「データ・コントロールへのビジネス・ロジックの追加」を参照してください。ADFモデル・データ・バインディングの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

2.1 ADFデータ・バインディングの概要

ADFモデルによって、ユーザー・インタフェース・テクノロジとビジネス・サービス実装の分離を可能にする2つの概念(データ・コントロールと宣言的バインディング)が実装されています。

データ・コントロールでは、関連するプロパティ、メソッド、タイプの情報を含め、サービスの操作とデータ・コレクションを表す標準のメタデータ・インタフェースを使用してビジネス・サービスの実装技術を抽象化します。EJBセッション・ファサードを使用するアプリケーションでは、開発者はファサードのデータ・コントロールを作成できます。その後、JDeveloperの「データ・コントロール」パネル(図2-1を参照)に表示されたデータ・コントロールの表現を使用して、セッション・ファサードに自動的にバインドされるUIコンポーネントを作成できます。実行時に、ADFモデル・レイヤーによって、適切なXMLファイルからデータ・コントロールおよびバインディングを記述した情報が読み取られ、ユーザー・インタフェースとビジネス・サービスの双方向の結合が実装されます。

図2-1 「データ・コントロール」パネル

宣言的なバインディングによって、データ・コントロール内のデータ・コレクションからのデータ・アクセスの詳細と、その操作の実行が抽象化されます。次に、バインディング・オブジェクトの基本的な種類を示します。

- 値バインディング: データを表示するUIコンポーネントで使用します。値のバインディングは、単純なテキスト・フィールドで使用する最も基本的なものから、リスト、表、ツリーでのUIコントロールのニーズをサポートするような、より高度なリスト、ツリーのバインディングまで、様々な種類があります。

- アクション・バインディング: ハイパーリンクやボタンなどのUIコマンド・コンポーネントで使用され、コードを記述することなく、データ・コレクションやデータ・コントロールの組込み操作またはカスタム操作を実行します。

- 実行可能バインディング: インテレータ・バインディングを含み、問合せおよび現在の行を管理するために主にバックグラウンドで使用されます。また、実行可能バインディングには、ページ内で一連のページの検索およびネストを可能にするバインディングや、操作を即時実行するためのバインディングも含まれます。

図2-2は、バインディングによってUIコンポーネントをデータ・コントロール・コレクションおよびメソッドに関連付ける様子を示しています。

図2-2 バインディングによるデータ・コントロールへのUIコンポーネントの関連付け

ページのUIコンポーネントをサポートするバインディングのグループは、ページ定義ファイルというページ固有のXMLファイルに記述されます。ADF Modelレイヤーでは実行時にこのファイルが使用され、ページのバインディングがインスタンス化されます。これらのバインディングは、バインディング・コンテナと呼ばれるリクエスト・スコープ・マップに保持されます。JSFアプリケーションでは、バインディング・コンテナは、各ページ・リクエスト時にEL式#{bindings}を使用してアクセスできます。例2-1に、フォーム内のチェック・ボックスをOrdersSessionEJBLocalデータ・コントロールのorderFilled属性にバインディングするために使用されるコードを示します。

例2-1 JSF Webページのチェック・ボックスのバインディング・コード

<af:selectBooleanCheckbox value="#{bindings.orderFilled.inputValue}"
label="#{bindings.orderFilled.label}"
shortDesc="#{bindings.orderFilled.hints.tooltip}" id="sbc1"/>

ヒント:

ADF EL式の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFデータ・バインディングEL式の作成に関する項を参照してください。

データのバインディングにADFモデル・レイヤーを使用するには、JDeveloperを使用して、サービス用のデータ・コントロールを作成する必要があります。データ・コントロールが「データ・コントロール」パネルのツリー階層として表示され、ツリーの各サブノードにコレクション、操作、メソッドまたは属性が表されます。その後、Webページのビジュアル・エディタまたはその他のユーザー・インタフェース・コンポーネントに、それらのサブノードをドラッグ・アンド・ドロップすることにより、データバインドされたコンポーネントを作成できます。たとえば、JSPページ用にデータバインドされたHTML要素、JSFページ用にデータバインドされたUIコンポーネント、およびADF Swingパネル用にデータバインドされたSwing UIコンポーネントを作成できます。データ・コントロールからサブノードをページにドラッグすると、JDeveloperによって、ページからサービスへのバインディングを表すメタデータが自動的に作成されます。実行時、 ADFモデル・レイヤーは、データ・コントロールとバインディングの両方に対する適切なXMLファイルからメタデータ情報を読み取り、ユーザー・インタフェースとビジネス・サービスとの間の2方向の接続を実装します。

2.2 ADFデータ・コントロールを使用したビジネス・サービスの公開

アプリケーションのサービスの準備ができたら、JDeveloperを使用して、UIコンポーネントとサービスとの宣言的バインドに必要な情報を提供するデータ・コントロールを作成できます。Java EEアプリケーションでは、通常、データベース内の表を表すエンティティBeanを作成し、全EJBに対するセッション・ファサードを作成します。このファサードは、ベースとなるエンティティへの一元化されたインタフェースです。Oracle ADFアプリケーションでは、セッションBeanに対するデータ・コントロールを作成でき、そのデータ・コントロールには、セッションBean下のすべてのEJBに関する記述が含まれます。

データ・コントロールの生成には、「データ・コントロールの作成」コマンドを使用します。データ・コントロールは、1つ以上のXMLメタデータ・ファイルで構成され、これらのファイルでは、実行時にバインディングと連動するサービスの機能が定義されます。データ・コントロールは、Beanの実装を変更することなく、基礎となるBeanと連動して動作します。

たとえば、Summitデモ・アプリケーションでは、多数のリレーショナル・データベース表が含まれるsummitデータベース・スキーマが使用されます。アプリケーションのモデル・プロジェクトには、Summitデモ・アプリケーションが使用するスキーマ内の表を表すエンティティBeanが多数含まれています。Customer Bean、Product Bean、Order Beanなどです。また、モジュールには、表から作成されたBeanにアクセスするためのセッションBean、OrdersSessionEJBBeanも含まれています。セッションBeanに対してデータ・コントロールが存在し、開発者はセッションBeanとセッションBeanがカプセル化しているエンティティBeanに含まれるデータとロジックを使用して宣言的にUIページを作成できます。

2.2.1 ADFデータ・コントロールの作成方法

データ・コントロールは、JDeveloperのアプリケーション・ナビゲータ内から作成します。

始める前に:

データ・コントロール使用の一般的な知識があると役立ちます。詳細は、2.2項「ADFデータ・コントロールを使用したビジネス・サービスの公開」を参照してください。

次のタスクを完了する必要があります。

アプリケーション・ワークスペース、JPA/EJB 3.0エンティティ、およびエンティティ用に1つ以上のセッションBeanを作成します。詳細は、Oracle Fusion Middleware Oracle JDeveloperユーザー・ガイドのEJBビジネス・サービス・レイヤーの操作方法に関する項を参照してください。

注意:

Javaサービス・ファサード・クラスをデータ・コントロールの基礎とすることもできます。Javaサービス・ファサードを使用すると、EJBコンテナ内から、またはEJBコンテナを使用せずに、どちらからでもビジネス・メソッドを公開することが可能です。Javaサービス・ファサードのテンプレートは、「新規ギャラリ」にあります。また、データ・コントロールの基礎とするクラスは、JavaBeans仕様に準拠している必要がある点に注意してください。特に、クラスにはpublicなデフォルト・コンストラクタが必要です。

データ・コントロールを作成する手順:

1. 「アプリケーション・ナビゲータ」で、データ・コントロールの作成対象のセッションBeanを右クリックし、コンテキスト・メニューから「データ・コントロールの作成」を選択します。

2. 「EJBインタフェースの選択」ダイアログで、「ローカル」または「リモート」を選択します。Webアプリケーションの場合、通常は「ローカル」を選択します。

注意:

データ・コントロールの基礎となるBeanの名前を後に変更した場合、再度「データ・コントロールの作成」コマンドを使用して、データ・コントロールのメタデータを再生成する必要があります。

データ・コントロールの作成後にBeanに単に変更を加えた場合は、データ・コントロールを再生成する必要はありません。Beanへの変更はデータ・コントロールに反映されます。ただし、基礎となるBeanの変更をデータ・コントロールに反映させるために、プロジェクトを一度閉じて再度開く必要がある場合があります。

2.2.2 データ・コントロール作成時のプロジェクト内の処理

EJBセッションBeanに基づいてデータ・コントロールを作成すると、JDeveloperによってデータ・コントロール定義ファイル(DataControls.dcx)が作成され、ファイルが概要エディタで開かれ、ファイルの階層が「データ・コントロール」パネルに表示されます。このファイルにより、データ・コントロールがサービスおよびバインディングと直接連動して動作することが可能になります。図2-3は、概要エディタでのDataControls.dcxファイルを示しています。

図2-3 概要エディタでのDataControls.dcxファイル

例2-2に、対応するXMLファイルのコードを示します。これは、エディタ・ウィンドウの「ソース」タブをクリックすると表示されます。

例2-2 DataControls.dcxファイル

<?xml version="1.0" encoding="UTF-8" ?>
<DataControlConfigs xmlns="http://xmlns.oracle.com/adfm/configuration" version="11.1.2.58.66" id="DataControls"
Package="model">
<AdapterDataControl id="OrdersSessionEJBLocal" FactoryClass="oracle.adf.model.adapter.DataControlFactoryImpl"
ImplDef="oracle.adfinternal.model.adapter.ejb.EjbDCDefinition" SupportsTransactions="false"
SupportsSortCollection="true" SupportsResetState="false" SupportsRangesize="false"
SupportsFindMode="false" SupportsUpdates="true" Definition="model.OrdersSessionEJBLocal"
BeanClass="model.OrdersSessionEJBLocal" xmlns="http://xmlns.oracle.com/adfm/datacontrol">
<CreatableTypes>
<TypeInfo FullName="model.Product"/>
<TypeInfo FullName="model.Item"/>
<TypeInfo FullName="model.Ord"/>
<TypeInfo FullName="model.Customer"/>
<TypeInfo FullName="model.Emp"/>
</CreatableTypes>
<Source>
<ejb-definition ejb-version="3.0" ejb-name="OrdersSessionEJB" ejb-type="Session"
ejb-business-interface="model.OrdersSessionEJBLocal" ejb-interface-type="local"
initial-context-factory="weblogic.jndi.WLInitialContextFactory"
DataControlHandler="oracle.adf.model.adapter.bean.jpa.JPQLDataFilterHandler"
xmlns="http://xmlns.oracle.com/adfm/adapter/ejb"/>
</Source>
</AdapterDataControl>
</DataControlConfigs>

2.2.2.1 DataControls.dcxの概要エディタ

DataControls.dcxファイルの概要エディタには、データ・モデルのマスター/ディテール階層のビューおよびセッション・ファサードのメソッドが表示されます。ノードを選択するとフィールドが表示され、これらのフィールドを「属性」タブの対応するエンティティ・クラス内のデータベース列にマッピングできます。「アクセッサ」タブでは、エンティティの関係が定義されている対応するエンティティ・クラスのフィールドが表示されます(たとえばOneToManyおよびManyToOne)。「操作」タブでは、コレクション・アクセッサのaddおよびremoveメソッドなど、エンティティに対する操作のメソッドが表示されます。

概要エディタおよび「データ・コントロール」パネルで使用されるアイコンの説明は、表2-1を参照してください。

データ・コントロールの設定を変更するには、要素を選択し、「編集」アイコンをクリックします。データ・コントロールの編集方法の詳細は、3.2項「データ・コントロールの構成」を参照してください。

2.2.2.2 「データ・コントロール」パネル

データ・コントロールを作成すると、「データ・コントロール」パネルが「アプリケーション・ナビゲータ」に表示されます。「データ・コントロール」パネルはパレットとして機能し、ノードを「データ・コントロール」パネルからWebページのデザイン・エディタにドラッグすることにより、データバインドされたUIコンポーネントを作成できます。

DataControls.dcxの概要エディタと同様に、「データ・コントロール」パネルは、マスター・データ・コレクションの下にネストされたディテール・データ・コレクションを表示することで、データ・モデル内のマスター/ディテール階層を示します。たとえば、図2-4は、「データ・コントロール」パネルに表示されたSummitデモ・アプリケーションのデータ・コントロールを示しています。Customer、Emp、Item、OrdおよびProduct Beanはすべて、図ではアクセッサ戻りコレクションとして表されており、これらはさらにBeanで定義された名前付き問合せに対応します。

図2-4 「データ・コントロール」パネル

「データ・コントロール」パネルには、セッションBeanの各サービス・メソッドも、メソッド名と一致する名前のメソッド・アイコンとして表示されます。メソッドが引数をとる場合、その引数は、メソッドのノード内にネストされたパラメータとして「パラメータ」ノードに表示されます。図2-4に示すように、メソッドによって返されるオブジェクトも表示されます。

DataControls.dcxファイルの概要エディタに表示されるノードに加え、「データ・コントロール」パネルにはバインディングに使用できる他のオブジェクトのノードも表示されます(エンティティBean属性、組込み操作およびメソッド・パラメータなど)。

ヒント:

「データ・コントロール」パネルが表示されない場合、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「データ・コントロール」パネルの開き方に関する項でパネルを開く手順を確認してください。

返される各コレクションまたはオブジェクトには、関連付けられているBeanに定義された属性およびカスタム・メソッドが表示されます。図2-5は、itemFindAllアクセッサ・メソッドによって返されるItem Beanに定義されている属性とメソッドを示しています。

図2-5 返されるコレクションの子ノード

デフォルトでは、Beanで問合せ可能な各属性に対して暗黙的な名前付き基準が作成されます。それらは、図2-5に示すように、「データ・コントロール」パネルで「名前付き基準」ノードの下に「すべての問合せ可能な属性」ノードとして表示されます。このノードは、第8章「データバインドされた検索フォームの作成」で説明するような、クイック検索フォームの作成に使用されます。

図2-5に示すように、「データ・コントロール」パネルで返されるコレクションの下の「操作」ノードには、データ・コントロールが提供する使用可能な組込み操作がすべて表示されます。操作で1つ以上のパラメータを受け入れると、そのパラメータは、ネストされた「パラメータ」ノードに表示されます。実行時に、これらのデータ・コレクション操作の1つがデータ・バインディング・レイヤーによって名前別に起動されると、データ・コントロールは、組込み機能を処理するBeanインタフェース上の適切なメソッドにそのコールを委譲します。ほとんどの組込み操作は、現在の行に作用します。ただし、execute操作はデータ・コントロール自体をリフレッシュし、commitおよびrollback操作は、トランザクションの範囲内で実行されたすべての変更に影響を与えます。組込み操作は、次のとおりです。

- Create: 現在の行になる新規行を作成しますが、挿入はしません。

- Delete: 現在の行を削除します。

- Execute: アクセッサ・メソッドを実行または再実行することによって、データ・コレクションをリフレッシュします。

- First: 行セット内の最初の行を現在の行に設定します。

- Last: 行セット内の最後の行を現在の行に設定します。

- Next: 行セット内の次の行を現在の行に設定します。

- Next Set: 1つ後の行のセットに移動します。

- Previous: 行セット内の前の行を現在の行に設定します。

- Previous Set: 1つ前の行のセットに移動します。

- removeRowWithKey: パラメータとして渡された行キーのシリアライズされた文字列表現を使用して行の検索を試行します。検出されると、その行が削除されます。

- setCurrentRowWithKey: パラメータとして渡された行キーのシリアライズされた文字列表現を使用して行の検索を試行します。検出されると、その行が現在の行になります。

- setCurrentRowWithKeyValue: パラメータとして渡された主キーの属性値を使用して行の検索を試行します。検出されると、その行が現在の行になります。

- commit: 現在のトランザクションで行われたすべての変更をデータベースに永続化させます。(ステートフルBeanによって管理されたトランザクション・メソッドが含まれているセッション・ファサードでのみ使用可能)

- rollback: 現在のトランザクションのコンテキスト内でのすべての変更を元に戻します。(ステートフルBeanによって管理されたトランザクション・メソッドが含まれているセッション・ファサードでのみ使用可能)

注意:

デフォルトでは、JavaBeansコンポーネントはrowIndexをキーと見なします。明示的にキーを定義しない場合、索引が使用されます。

「データ・コントロール」パネルは、DataControls.dcxファイルと、データ・コントロールに関連付けられたすべてのデータ・コントロール構造ファイルを直接表したものです。ファイルを編集することで、パネルに表示されている要素を変更できます。データ・コントロールの基礎となるサービスが変更されると、これらの変更はデータ・コントロールに反映されます。

2.3 「データ・コントロール」パネルの使用

「データ・コントロール」パネルから項目をドラッグし、それを特定のUIコンポーネントとしてページ上にドロップすることで、データバインドされたユーザー・インタフェースを設計できます。データ・コントロールを使用してUIコンポーネントを作成すると、選択したデータ・コントロールにそのコンポーネントをバインドするために必要な、様々なコードおよびオブジェクトがJDeveloperによって自動的に作成されます。

「データ・コントロール」パネルでは、各オブジェクトは特定のアイコンで表されます。表2-1は、各アイコンが表すもの、「データ・コントロール」パネルの階層内で表示される場所、そのアイコンを使用して作成できるコンポーネントを示しています。

表2-1 データ・コントロールのアイコンおよびオブジェクト階層

アイコン

名前

説明

作成できるコンポーネント

データ・コントロール

データ・コントロールを表します。データ・コントロール自体を使用してUIコンポーネントを作成することはできませんが、その下に表示される子オブジェクトは、いずれも使用できます。ビジネス・サービスの定義方法によっては、複数のデータ・コントロールが存在することがあります。

他のオブジェクトのコンテナとして機能し、作成には使用されません。

アクセッサによって返されるコレクション

ビジネス・サービスでBean形式のアクセッサ・メソッドによって返されるオブジェクトを表します。たとえば、セッションBeanを作成する際、セッションBean下に各Javaエンティティに対するアクセッサ・メソッドも作成するよう選択した場合、アクセッサによって返されるコレクションがそれらの各エンティティに対して表示されます。

エンティティに他のエンティティへの関係が含まれている場合(外部キーなど)、そのエンティティについて子アクセッサによって返されるコレクションが表示されます。Oracle ADFでは、親および子エンティティ間の関係はマスター/ディテール関係と呼ばれます。

コレクション下の子には、コレクションを構成する要素の属性、コレクション全体に対する操作、コレクション内の各要素の行に対する操作などがあります。

コレクションの場合: フォーム、表、ツリー、レンジ・ナビゲーションの各コンポーネント、およびマスター/ディテール・ウィジェット。

単一オブジェクトの場合: フォーム、マスター/ディテール・ウィジェットおよび選択リスト。

フォームおよびナビゲーション・コンポーネントの作成の詳細は、第4章「データバインドされた基本的なページの作成」を参照してください。

表の作成の詳細は、第5章「ADFによるデータバインドされた表の作成」を参照してください。

ツリーおよび他のマスター/ディテールUIコンポーネントの作成の詳細は、第6章「マスター/ディテール・データの表示」を参照してください。

リストの作成の詳細は、第7章「データバインドされた選択リストの作成」を参照してください。

属性

オブジェクト内の個別のデータ要素(行の属性など)を表します。属性は、自分の属するコレクションまたはメソッド戻りの下に、子として表示されます。

このアイコンは「データ・コントロール」パネルで使用されますが、DataControls.dcxファイルの概要エディタでは使用されません。

ラベル、テキスト・フィールドおよび選択リストの各コンポーネント。

テキスト・フィールドの作成の詳細は、4.2項「属性を使用したテキスト・フィールドの作成方法」を参照してください。

メソッド

メソッドを表し、パラメータの受入れや、ビジネス・ロジックの実行を行ったり、オプションで単一の値、構造、または単一の値と構造のコレクションを戻すことができます。

コマンド・コンポーネント。

パラメータをとるメソッドの場合: コマンド・コンポーネントおよびパラメータ付きフォーム。

メソッドからのコマンド・コンポーネントの作成の詳細は、4.6項「既存レコードを編集するフォームの作成」を参照してください。

パラメータを使用するフォームの作成の詳細は、4.5項「パラメータをとるメソッドを使用するフォームの作成」を参照してください。

メソッド戻り

メソッドによって戻されたオブジェクトを表します。戻されたオブジェクトは、単一の値またはコレクションです。

メソッド戻りは、これを戻すメソッドの下に、子として表示されます。メソッド戻りの下に子として表示されるオブジェクトは、コレクションの属性、親コレクションに関連するアクションを実行する他のメソッド、または親コレクションで実行できる操作などです。

単一の値の場合: テキスト・フィールドおよび選択リスト。

コレクションの場合: フォーム、表、ツリー、レンジ・ナビゲーションの各コンポーネント。

単一値のメソッド戻り値がドロップされた場合、メソッドを起動するコードは自動的に生成されません。メソッドを起動するために、実行可能ファイルとして起動アクションも作成するか、対応するメソッドをボタンとしてドロップする必要があります。

操作

親オブジェクトに対してアクションを実行する、組込みデータ・コントロール操作を表します。データ・コントロール操作は、コレクションまたはメソッド戻りの下の「操作」ノードにあります。特定のコレクションまたはメソッド戻りの子である操作は、それらのオブジェクトにのみ作用します。

1つ以上のパラメータが操作に必要な場合、それらのパラメータは操作の下の「パラメータ」ノードにリストされます。

このアイコンは「データ・コントロール」パネルで使用されますが、DataControls.dcxファイルの概要エディタでは使用されません。

ボタンやリンクなどのコマンド・コンポーネント。

操作からのコマンド・コンポーネントの作成の詳細は、4.4項「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

パラメータ

メソッドまたはその下に表示される操作によって宣言されたパラメータ値を表します。パラメータは、メソッドまたは操作の下の「パラメータ」ノード内に表示されます。

このアイコンは「データ・コントロール」パネルで使用されますが、DataControls.dcxファイルの概要エディタでは使用されません。

ラベル、テキストおよび選択リストの各コンポーネント。

名前付き基準

ユーザー検索フォームを作成できる問合せを表します。

「すべての問合せ可能な属性」基準が各アクセッサ・コレクションについて自動的に生成されます。この問合せを使用して、コレクション内の任意の問合せ可能な属性に基づき、ユーザーが問合せを実行できる検索フォームを作成できます。

カスタム・ビュー基準を作成し、「データ・コントロール」パネルに追加できます。3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

このアイコンは「データ・コントロール」パネルで使用されますが、DataControls.dcxファイルの概要エディタでは使用されません。

検索フォーム。

検索フォームの作成の詳細は、第8章「データバインドされた検索フォームの作成」を参照してください。

2.3.1 「データ・コントロール」パネルの使用方法

JDeveloperは、ドロップするデータ・コントロール項目に対してそれぞれ選択できるUIコンポーネントの事前定義済セットを備えています。

「データ・コントロール」パネルを使用してUIコンポーネントを作成する手順:

1. 「データ・コントロール」パネルで項目を選択し、ページのビジュアル・エディタにその項目をドラッグします。パネルの各項目の定義は、表2-1を参照してください。

2. ポップアップ・メニューから、UIコンポーネントを選択します。
「データ・コントロール」パネルから項目をドラッグしてページにドロップすると、ドロップした項目に使用できるすべてのデフォルトUIコンポーネントのポップアップ・メニューが表示されます。

図2-6は、アクセッサ戻りコレクションが「データ・コントロール」パネルからページにドロップされる際に表示されるポップアップ・メニューを示しています。

図2-6 「データ・コントロール」パネルのポップアップ・メニュー

ポップアップ・メニューから選択したコンポーネントに応じて、そのコンポーネントの外観を定義するためのダイアログがJDeveloperで表示されます。

図2-7に示すように、結果のUIコンポーネントがJDeveloperのビジュアル・エディタに表示されます。

図2-7 データバインドされたUIコンポーネント: ADF表

ヒント:

「データ・コントロール」パネルを使用して自動的にバインドされるUIコンポーネントを作成するかわりに、UIをまず作成し、コンポーネントをADFモデル・レイヤーにバインドできます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の最初に単純なUIを開発する方法の使用に関する項を参照してください。

2.3.2 「データ・コントロール」パネルを使用したUIコンポーネントの作成時の処理

「データ・コントロール」パネルを使用してWebアプリケーションを構築すると、JDeveloperによって次の処理が行われます。

- DataBindings.cpxファイルがプロジェクトのデフォルト・パッケージに作成されます(このファイルが存在しない場合のみ)。また、そのページ用にエントリが追加されます。
DataBindings.cpxファイルは、アプリケーションのバインディング・コンテキスト(使用可能なデータ・コントロールとデータ・バインディング・オブジェクトのリストを保持するコンテナ・オブジェクト)を定義します。DataBindings.cpxファイルによって、個々のページがページ定義ファイルに含まれるバインディング定義にマップされ、これらのページが使用するデータ・コントロールが登録されます。図2-8は、JDeveloperの概要エディタでのDataBindings.cpxファイルを示しています。

図2-8 概要エディタでのDataBindings.cpxファイル

例2-3は、対応するXMLファイルのコードを示しています。

例2-3 DataBindings.cpxファイル

<?xml version="1.0" encoding="UTF-8" ?>
<Application xmlns="http://xmlns.oracle.com/adfm/application"
version="11.1.2.59.53" id="DataBindings"
SeparateXMLFiles="false" Package="view" ClientType="Generic">
<pageMap>
<page path="/ViewCustomerOrders.jspx"
usageId="view_ViewCustomerOrdersPageDef"/>
<page path="/editOrderItems.jspx" usageId="view_editOrderItemsPageDef"/>
<page path="/CreateOrder.jspx" usageId="view_CreateOrderPageDef"/>
<page path="PageFlow#addOrd" usageId="view_adfc_config___addOrdPageDef"/>
<page  path="/WEB-INF/create-order-task-flow-definition.xml
#create-order-task-flow-definition@Create"
usageId="view_adfc_config___CreatePageDef"/>
<page path="/EditOrder.jspx" usageId="view_EditOrderPageDef"/>
<page path="/login.jspx" usageId="view_loginPageDef"/>
<page path="/viewCust.jspx" usageId="view_viewCustPageDef"/>
</pageMap>
<pageDefinitionUsages>
<page id="view_ViewCustomerOrdersPageDef"
path="view.pageDefs.ViewCustomerOrdersPageDef"/>
<page id="view_editOrderItemsPageDef"
path="view.pageDefs.editOrderItemsPageDef"/>
<page id="view_CreateOrderPageDef" path="view.pageDefs.CreateOrderPageDef"/>
<page id="view_adfc_config___CreatePageDef"
path="view.pageDefs.adfc_config___CreatePageDef"/>
<page id="view_adfc_config___addOrdPageDef"
path="view.pageDefs.adfc_config___addOrdPageDef"/>
<page id="view_EditOrderPageDef" path="view.pageDefs.EditOrderPageDef"/>
<page id="view_loginPageDef" path="viewcontroller.pageDefs.loginPageDef"/>
<page id="view_viewCustPageDef"
path="viewcontroller.pageDefs.viewCustPageDef"/>
</pageDefinitionUsages>
<dataControlUsages>
<dc id="OrdersSessionEJBLocal" path="model.OrdersSessionEJBLocal"/>
</dataControlUsages>
</Application>

.cpxファイルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のDataBindings.cpxファイルの使用に関する項を参照してください。

- META-INFディレクトリにadfm.xmlファイルが作成されます。このファイルによってDataBindings.cpxファイルのレジストリが作成され、アプリケーション・メタデータ・レイヤーによって使用されて、アプリケーションのカスタマイズとパーソナライズが行われます。例2-4は、adfm.xmlファイルの例を示しています。

例2-4 adfm.xmlファイル

<?xml version="1.0" encoding="UTF-8" ?>
<MetadataDirectory xmlns="http://xmlns.oracle.com/adfm/metainf"
version="11.1.1.0.0">
<DataBindingRegistry path="view/DataBindings.cpx"/>
</MetadataDirectory>

- Webアプリケーションの場合、web.xmlファイルにADFバインディング・フィルタが登録されます。
このADFバインディング・フィルタによって、バインディング・コンテキストへのアクセスに必要なHTTPリクエストが事前処理されます。フィルタの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFデータ・バインディング・フィルタの構成に関する項を参照してください。

- プロジェクトに次のライブラリが追加されます。

- ADFモデル・ランタイム

- ADFモデル汎用ランタイム

- パッケージ定義ファイルがページ定義サブパッケージに追加されます(ページに対してファイルが存在しない場合)。デフォルトのサブパッケージはview.pageDefsです。
ページ定義ファイル(pageNamePageDef.xml)は、アプリケーションのビュー・レイヤーにある各ページのADFバインディング・コンテナを定義します。このバインディング・コンテナによって、すべてのADFバインディング・オブジェクトへのランタイム・アクセスが可能になります。図2-9は、JDeveloperの概要エディタでのページ定義ファイルを示しています。

図2-9 ページ定義ファイル

- ページで参照されるバインディング・オブジェクトの定義の追加も含めて、ページ定義ファイルが構成されます。例2-5は、ページ定義の対応するXMLファイルを示しています。

例2-5 ページ定義ファイル

<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel" version="11.1.2.59.53" id="CreateOrderPageDef"
Package="view.pageDefs">
<parameters/>
<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="customerFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Customer" id="customerFindAllIterator"/>
<accessorIterator MasterBinding="customerFindAllIterator"
Binds="SOrdList" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Ord" id="SOrdListIterator"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator1"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator1"
Binds="empFindAll" RangeSize="-1"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Emp" id="empFindAllIterator"/>
</executables>
<bindings>
<attributeValues IterBinding="SOrdListIterator" id="id">
<AttrNames>
<Item Value="id"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="SOrdListIterator" id="dateOrdered">
<AttrNames>
<Item Value="dateOrdered"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="SOrdListIterator" id="dateShipped">
<AttrNames>
<Item Value="dateShipped"/>
</AttrNames>
</attributeValues>
<attributeValues IterBinding="SOrdListIterator" id="total">
<AttrNames>
<Item Value="total"/>
</AttrNames>
</attributeValues>
<button IterBinding="SOrdListIterator" id="orderFilled"
DTSupportsMRU="false" StaticList="true">
<AttrNames>
<Item Value="orderFilled"/>
</AttrNames>
<ValueList>
<Item Value="Y"/>
<Item Value="N"/>
</ValueList>
</button>
<list IterBinding="SOrdListIterator" id="paymentType"
DTSupportsMRU="true" StaticList="true">
<AttrNames>
<Item Value="paymentType"/>
</AttrNames>
<ValueList>
<Item Value="CASH"/>
<Item Value="CREDIT"/>
</ValueList>
</list>
<list IterBinding="SOrdListIterator" id="salesRepId"
DTSupportsMRU="true" StaticList="false"
ListIter="empFindAllIterator">
<AttrNames>
<Item Value="salesRepId"/>
</AttrNames>
<ListAttrNames>
<Item Value="id"/>
</ListAttrNames>
<ListDisplayAttrNames>
<Item Value="firstName"/>
<Item Value="lastName"/>
</ListDisplayAttrNames>
</list>

<methodAction IterBinding="customerFindAllIterator" id="addOrd"
RequiresUpdateModel="true"
Action="invokeMethod" MethodName="addOrd"
IsViewObjectMethod="false"
DataControl="OrdersSessionEJBLocal"
InstanceName="bindings.customerFindAllIterator.
currentRow.dataProvider"
IsLocalObjectReference="true"
ReturnName="data.OrdersSessionEJBLocal.methodResults.
addOrd_addOrd_addOrd_result">
<NamedData NDName="order"
NDValue="#{bindings.SOrdListIterator.currentRow.dataProvider}"
NDType="model.Ord"/>
</methodAction>
<methodAction id="mergeCustomer" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="mergeCustomer"
IsViewObjectMethod="false"
DataControl="OrdersSessionEJBLocal"
InstanceName="data.OrdersSessionEJBLocal.dataProvider"
ReturnName="data.OrdersSessionEJBLocal.methodResults.
mergeCustomer_OrdersSessionEJBLocal_
dataProvider_mergeCustomer_result">
<NamedData NDName="customer"
NDValue="#{bindings.customerFindAllIterator.currentRow.
dataProvider}"
NDType="model.Customer"/>
</methodAction>
</bindings>
</pageDefinition>

ページ定義ファイルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のページ定義ファイルに関する項を参照してください。

- 事前作成済のコンポーネントがビュー・ページに追加されます。
これらの事前作成済のコンポーネントには、ページ定義ファイルのバインディング・オブジェクトを参照するADFデータ・バインディングが含まれます。例2-6は、ADFモデル・データ・バインドを使用してバインドされたコンポーネントのJSFページのコードを示しています。

例2-6 ADFモデル・データ・バインディングを使用したJSFページのコードの一部

.
.
.
<af:table value="#{bindings.Ord.collectionModel}" var="row"
rows="#{bindings.Ord.rangeSize}"
emptyText="#{bindings.Ord.viewable ? 'No data to display.' :
'Access Denied.'}"
fetchSize="#{bindings.Ord.rangeSize}" rowBandingInterval="0"
selectedRowKeys="#{bindings.Ord.collectionModel.selectedRow}"
selectionListener="#{bindings.Ord.collectionModel.makeCurrent}"
rowSelection="single" id="t1">
<af:column sortProperty="#{bindings.Ord.hints.dateOrdered.name}"
sortable="false"
headerText="#{bindings.Ord.hints.dateOrdered.label}" id="c1">
<af:outputText value="#{row.dateOrdered}" id="ot1">
<af:convertDateTime
pattern="#{bindings.Ord.hints.dateOrdered.format}"/>
</af:outputText>
</af:column>
<af:column sortProperty="#{bindings.Ord.hints.dateShipped.name}"
sortable="false"
headerText="#{bindings.Ord.hints.dateShipped.label}" id="c2">
<af:outputText value="#{row.dateShipped}" id="ot2">
<af:convertDateTime
pattern="#{bindings.Ord.hints.dateShipped.format}"/>
</af:outputText>
</af:column>
<af:column sortProperty="#{bindings.Ord.hints.id.name}" sortable="false"
headerText="#{bindings.Ord.hints.id.label}" id="c3">
<af:outputText value="#{row.id}" id="ot3"/>
</af:column>
.
.
.

- ADF Facesを使用するアプリケーションの場合、ADF Facesコンポーネントで必要なすべてのファイルと構成可能な要素が追加されます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。

2.3.3 実行時に行われる処理

ページにADF バインディングが含まれている場合、実行時には、クライアントまたはコントローラから起動されたビジネス・サービスとのやり取りが、バインディング・コンテキストを介して、アプリケーションによって管理されます。バインディング・コンテキストは、アプリケーション内のすべてのデータ・コントロールおよびページ定義のランタイム・マップ(名前付きdataでEL式#{data}を使用してアクセス可能)です。

ADFライフサイクルで、図2-10に示すように、DataControls.dcx、DataBindings.cpxおよびページ定義ファイルからADFバインディング・コンテキストが作成されます。DataControls.dcxファイルで、デザインタイム時にアプリケーションで使用可能なデータ・コントロールが定義され、DataBindings.cpxファイルで、実行時にアプリケーションで使用可能なデータ・コントロールが定義されます。DataBindings.cpxファイルには、アプリケーションのページで使用されるデータ・コントロールがすべてリストされ、ページ定義ファイルで定義済のバインディング・オブジェクトを含むバインディング・コンテナがWebページのURL、またはJava Swingアプリケーションの場合はJavaクラスにマップされます。ページ定義ファイルは、アプリケーション・ページで使用するバインディング・オブジェクトを定義します。各ページにページ定義ファイルが1つあります。

図2-10 ADFバインディング・ファイルの実行時の使用

バインディング・コンテキストには、これらのオブジェクトの現在の実際のインスタンスは含まれていません。かわりに、マップには必要に応じてデータ・コントロールまたはバインディング・コンテナ・オブジェクトになる参照がまず含まれます。オブジェクト(ページ定義など)がアプリケーションから解放されると(タスク・フローが終了したり、リクエストの終了時にバインディング・コンテナまたはデータ・コントロールが解放される場合)、データ・コントロールおよびバインディング・コンテナは参照オブジェクトに戻ります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「Fusionページ・ライフサイクルの理解」を参照してください。

2.3.4 イテレータの結果のキャッシュについて

データ・コントロールでコレクションを変更する場合、変更されていることがADFモデル・レイヤーで認識されるよう、データ・コントロールでコレクションの新規インスタンスをインスタンス化する必要があります。つまり、クライアントのアクションによってコレクションが変更されることがありますが、コレクションの新規インスタンスを作成しないかぎり、その変更はUIに反映されないということです。ただし、パフォーマンス上の理由から、アクセッサとメソッド・イテレータでは結果セットがキャッシュされます(デフォルトでは、イテレータのcacheResults属性はtrueに設定されています)。この設定は、ページが初めてレンダリングされるときにイテレータがリフレッシュされ、コレクションの新規インスタンスが作成されることを意味します。部分ページ・レンダリングを使用したページのリフレッシュやページに戻るユーザー・ナビゲーションなどのページの再アクセス時、イテレータはリフレッシュされません。

たとえば、ページで表のソートが可能であるとします。ソート後にページをリフレッシュする必要があるため、部分ページ・レンダリングを使用して表をリフレッシュする、ソート・イベント用のコードをリスナーに追加します(詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の部分的なページ・コンテンツのレンダリングに関する項を参照してください)。表のコレクションのインスタンスはすでにインスタンス化され、キャッシュされているため、アクセッサ・イテレータは再実行されません。このため、新しいソート順のコレクションの新規インスタンスは作成されず、ページ上のソート順は同じままになります。

この問題に対処するには、結果をキャッシュしないようイテレータを構成するか、ページのリフレッシュ時にイテレータの再実行に使用できるボタンをページに配置します。アクション属性をメソッドにバインドできるボタンがページにない場合、ページのリフレッシュ時に起動されるinvokeAction実行可能ファイルを使用できます。

注意:

ページでナビゲーション操作を使用してコレクション内を移動する場合、CacheResultsをfalseに設定しないでください。ナビゲーションが機能しなくなります。ボタンを使用してイテレータを再実行する必要があります。ナビゲーション操作の詳細は、第4.4項「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

パフォーマンスに関するヒント:

結果セットをキャッシュしないようイテレータを設定し、結果セットが多数の行を返す可能性のあるコレクションの場合、パフォーマンスにマイナスの影響があります。大規模な結果セットの場合、invokeActionを使用する必要があります。

結果セットをキャッシュしないようイテレータを設定する手順:

1. ページ定義ファイルを開き、結果をキャッシュしないイテレータを構造ウィンドウで選択します。

2. プロパティ・インスペクタで、「詳細」セクションを展開し、CacheResultsをfalseに設定します。

ボタンを使用してイテレータを再実行する手順:

1. コンポーネント・パレットの「ADF Faces」ページから、「ボタン」をページにドラッグ・アンド・ドロップします。

2. 構造ウィンドウで、ボタンを右クリックし、ポップアップ・メニューで「ADFコントロールにバインド」を選択します。

3. 「ADFコントロールにバインド」ダイアログで、再実行するイテレータに関連付けられているアクセッサを展開し、アクセッサの「操作」ノードを展開して「実行」を選択します。

invokeActionを使用してイテレータを再実行する手順:

1. ページ定義ファイルを開き、構造ウィンドウで「実行可能ファイル」を右クリックし、「実行可能ファイルの中に挿入」→「invokeAction」を選択します。

2. 「invokeActionの挿入」ダイアログで、「ID」を一意の名前に設定します。「バインド」ドロップダウン・リストを使用して、再実行するイテレータを選択します。

3. 新たに作成したinvokeActionが選択された状態で、プロパティ・インスペクタで「リフレッシュ」を「prepareModel」に設定します。
この設定によって、モデルの準備フェーズでアクセッサ・メソッドが起動されます。これによって、バインディング・コンテナがリフレッシュされます。

4. RefreshConditionを、値が実際に変更された場合にのみリフレッシュが行われるようにするEL式に設定します。この条件が設定されている場合、invokeActionが2回コールされます。
ページのライフサイクルのフェーズとrefreshおよびrefreshCondition属性の使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のJSFとADFのページ・ライフサイクルの概要に関する項を参照してください。

2.3.5 検証の構成について

データ・コントロール・レベルで属性の検証を設定する以外にも、ページ定義ファイル内の属性バインディングに対して検証を設定できます。ユーザーが、検証が定義されている属性のフィールド内のデータを編集または入力してフォームを送信すると、構成されているルールおよび条件に対してバインドされたデータが検証されます。検証に失敗すると、アプリケーションでエラー・メッセージが表示されます。

ほとんどの場合、ページ・レベルで検証を設定するよりも、データ・コントロール・レベルで検証を設定する方が便利です。データ・コントロールで設定したすべての検証ルールは、そのデータ・コントロールから作成されたすべてのUIコンポーネントに適用されます。

データ・コントロールでの検証の設定の詳細および手順は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

個別のUIコンポーネントでの検証の設定の詳細および手順は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「ADFモデル・レイヤーでの検証の使用」の章を参照してください。

検証を設定する際、表示されるメッセージを定義できます。デフォルトでは、これらのメッセージはクライアントのダイアログに表示されます。これらのメッセージがインラインで表示されるように構成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の検証および変更のヒントおよびエラー・メッセージの表示に関する項を参照してください。

独自のエラー処理クラスを作成して、メッセージの処理方法を変更することもできます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のエラー処理のカスタマイズに関する項を参照してください。

2.3.6 カスタム・セッションBeanのアクセッサ・メソッドについて

デフォルトで、アクセッサ戻りコレクションをセッションBeanデータ・コントロールからページにドラッグすると、ページに分割されたコレクションができます。この場合、組込みセッションBeanのqueryByRange()メソッドがバインディングから参照されます(セッションBeanの対応するgetBeanFindAll()メソッドではなく)。実行時に必ず使用するgetBeanFindAll()、getBeanFindAllSize()またはgetBeanFindAll(x,y)メソッドのカスタム・コードがBeanに存在する場合、データ・コントロールのDataControlHandler属性を削除する必要があります。DataControlHandler属性は、DataControls.dcxファイルのソース・エディタで削除できます。ただし、この属性を削除すると、名前付き問合せおよびページ分割の組込みサポートも使用できなくなります。

3 データ・コントロールへのビジネス・ロジックの追加

この章では、検証ルール、UIコントロール・ヒント、および属性のデフォルト値などのカスタム・ビジネス・ロジックによりデータ・コントロールを構成する方法を説明します。データ・コントロールを構成することにより、それらのデータ・コントロールからUIコンポーネントを作成する際に使用されるビジネス・ロジックを定義できます。

この章には、次の項が含まれます:

- 3.1項「データ・コントロールへのビジネス・ロジックの追加の概要」

- 3.2項「データ・コントロールの構成」

- 3.3項「属性の使用」

- 3.4項「Beanへの一時属性の追加」

- 3.5項「属性への検証ルールの宣言的な定義」

- 3.6項「名前付き基準を使用した結果セットのフィルタリング」

- 3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」

- 3.8項「Groovy言語サポート」

3.1 データ・コントロールへのビジネス・ロジックの追加の概要

データ・コントロールを生成すると、それ以上変更を加えずに、データ・モデルとアプリケーション内のUIコンポーネントとの間のバインディングを作成するためにそれらを使用できます。さらに、データ・コントロールを構成して、データ・モデルにビジネス・ロジックやその他の機能を追加し、UIコンポーネントの作成に「データ・コントロール」パネルを使用する際にそれらの機能を適用できます。たとえば、データ・コントロールを構成して次のことができます。

- 属性のデフォルト値の構成。

- 属性へのラベルおよびツールチップの追加。

- ADF Faces UIから式言語(EL)を介して参照可能なカスタム・メタデータ(通常は名前-値ペア)の追加。

- 計算属性の追加。

- 属性レベルの検証ルールとカスタム・エラー・メッセージの追加。

- 宣言的な検索フォームの定義。

3.2 データ・コントロールの構成

EJBセッションBeanのデータ・コントロールを作成すると、データ・コントロールについて、値と動作の標準的なセットが設定されます。たとえば、属性のラベルのクライアントでの表示方法がデータ・コントロールによって決定されます。エンティティBeanに対応するデータ・コントロール構造ファイルを作成および変更することにより、これらの値および動作を構成できます。まず、.dcxファイルの概要エディタを使用して、データ・コントロール構造ファイルを生成します。

3.2.1 データ・コントロールの編集方法

データ・コントロールを構成可能にするには、DataControls.dcxファイルの概要エディタを使用し、エンティティBeanに対応するデータ・コントロール構造ファイルを作成します。個別のデータ・コントロール構造ファイルを編集できるようになります。

始める前に:

データ・コントロール構成の一般的な知識があると役立ちます。詳細は、3.2項「データ・コントロールの構成」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

データ・コントロールを編集する手順:

1. 「アプリケーション・ナビゲータ」で、「DataControls.dcx」をダブルクリックします。

2. 概要エディタの「データ・コントロール」ツリーで、構成するBeanのアクセッサ戻りコレクションを選択し、「編集」アイコンをクリックしてデータ・コントロール構造ファイルを生成します。

3. データ・コントロール構造ファイルの概要エディタで、必要な変更を加えます。

3.2.2 データ・コントロール編集時の処理

EJBセッションBeanに基づいてデータ・コントロールを編集すると、JDeveloperにより、影響を受けたBeanのメタデータが含まれているデータ・コントロール構造ファイルが作成され、そのファイルが概要エディタで開かれます。このファイルには、そのBean固有のデータ・コントロールの構成データ(Beanに対して指定したUIヒントまたはバリデータなど)が保存されています。

データ・コントロール構成ファイルのベース名は、対応するエンティティBeanのものと同じです。たとえば、Customer.javaエンティティBeanに対応するアクセッサ戻りコレクションが選択されている状態で「編集」アイコンをクリックすると、データ・コントロール構成ファイルの名前はCustomer.xmlとなります。データ・コントロール構成ファイルはBeanクラスのパッケージに対応するパッケージに生成され、パッケージ名にpersdefが付加されます。たとえば、Summitアプリケーションでは、Customer.java Beanはmodelパッケージ内にあり、Customer.xmlデータ・コントロール構成ファイルはpersdef.modelパッケージ内にあります。データ・コントロール構成ファイルが生成された後、概要エディタを使用してそのファイルをさらに構成できます。

データ・コントロール構造ファイルには、次の情報が含まれます。

- 属性: サービスのすべての属性を表します。デフォルトでは、データベース列にマッピングされている各Beanプロパティについて属性が存在します。また、一時属性も追加できます。これらの属性のUIでの表示方法を定義するUIヒントを設定できます。属性値が必須か、一意である必要があるか、表示可能かどうかなどの他のプロパティを設定することもできます。UIヒントの設定の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のビュー・オブジェクトの属性UIヒントの定義に関する項を参照してください。

注意:

ビュー・オブジェクトは、SQL問合せのカプセル化と結果の操作の単純化に使用されるADF Business Componentsです。この項を読む際、ビュー・オブジェクトをBeanと読み替えてください。

属性の検証を設定したり、カスタム・プロパティを作成することもできます。検証の詳細は、第3.5項「属性への検証ルールの宣言的な定義」を参照してください。カスタム・プロパティの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のカスタム・プロパティにより促進される一般的機能性の実装方法に関する項を参照してください。

- アクセッサ: Beanの結果セットを返すデータ・コントロール要素を表します。「ベース・アクセッサ」セクションには、Beanプロパティに基づくアクセッサがリスト表示され、他のエンティティ・クラスへの関連付けはプロパティのフィールドで定義されます。

- 名前付き基準: 表示された行をフィルタリングするためのルールを作成できます。
詳細は、3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

- 操作: データ・コントロールの組込み操作で使用されるメソッドを表します。たとえば、それぞれ「作成」および「削除」組込み操作で使用されるaddおよびremoveメソッドなどです。

図3-1に、Summitデモ・アプリケーションのItem Beanのデータ・コントロール構造ファイルを示します。

図3-1 概要エディタでのデータ・コントロール構造ファイル

注意:

データ・コントロール構造ファイルの概要エディタでは、Beanに関連付けられているすべての属性、アクセッサおよび操作が表示されます。ただし、データ・コントロール構造ファイルのXMLソースには、編集した要素の定義のみが含まれます。ベース要素はBeanからイントロスペクションによって取得されます。また、基礎となるBeanに変更を加えると、データ・コントロールはそれらの変更を継承します。

3.3 属性の使用

EJBのデータ・コントロールを作成する際、Beanについて作成するデータ・コントロール構造ファイルで宣言的にBeanの永続属性の機能を拡張できます。たとえば、UIコンポーネントの属性のデフォルト表示を制御する検証ルールを作成し、UIヒントを設定できます。さらに、一時属性を作成できます。

いずれの場合も、これらのプロパティはデータ・コントロール構造ファイルの概要エディタの「属性」ページで設定します。データ・コントロール構造ファイルの作成の詳細は、3.2.1項「データ・コントロールの編集方法」を参照してください。

3.3.1 属性の更新可能性の制御方法

「更新可能」プロパティにより、特定の属性が更新可能かどうかを制御します。「更新可能」プロパティでは次の値を選択できます。

- 常に: 属性は常に更新可能です。

- なし: 属性は読取り専用です。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、3.3項「属性の使用」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

属性の更新可能性を設定する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで編集する属性を選択し、「詳細」タブをクリックします。

4. 「詳細」ページで「更新可能」属性を設定します。

3.3.2 属性の静的なデフォルト値を定義する方法

値のタイプが「リテラル」に設定されている場合、「詳細」セクションの「値」フィールドには、属性のデフォルト値を静的に指定できます。たとえば、ServiceRequestエンティティBeanのStatus属性のデフォルト値をOpenに設定したり、User BeanのUserRole属性のデフォルト値をuserに設定できます。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、3.3項「属性の使用」を参照してください。

属性の静的なデフォルト値を定義する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで編集する属性を選択し、「詳細」タブをクリックします。

4. 「詳細」ページで、「リテラル」オプションを選択します。

5. 「リテラル」オプションの下のテキスト・フィールドに、属性のデフォルト値を入力します。

3.3.3 Groovy式を使用してデフォルト値を定義する方法

属性のデフォルト値は、Groovy式を使用して定義できます。デフォルト値を実行時に変更する場合、この方法が便利です。ただし、デフォルト値が常に同じである場合は、「リテラル」タイプ(「詳細」タブ)で値のフィールドを使用する方が値の表示および管理が容易です。Groovyの使用の詳細は、3.8項「Groovy言語サポート」を参照してください。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、3.3項「属性の使用」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

Groovy式を使用してデフォルト値を定義する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで編集する属性を選択し、「詳細」タブをクリックします。

4. 「詳細」ページで、デフォルト値タイプに「式」を選択し、隣接したテキスト・フィールドの横の「編集」ボタンをクリックします。

5. 図3-2に示すように、「式の編集」ダイアログで、表示されているフィールドに式を入力します。
参照する属性には、Beanに定義されている任意の属性を使用できます。

図3-2 式エディタの編集

6. 同じダイアログで、適切な再計算設定を選択します。
「常に」(デフォルト)を選択すると、行のいずれかの属性が変更されるたびに式の評価が行われます。「なし」を選択すると、行が作成された場合にのみ式の評価が行われます。

7. オプションで、式の再計算を実行するタイミングの条件を指定します。
たとえば、「次の式に基づく」フィールドに次のような式を入力すると、Quantity属性またはUnitPrice属性が変更された場合に属性が再計算されます。

return (adf.object.dataProvider.isAttributeChanged("Quantity") || adf.object.dataProvider.isAttributeChanged("UnitPrice"));

8. ダイアログの下の「選択可能」リストで、値の式またはオプションの再計算式の基礎となる属性を選択し、それぞれ「選択済」リストに移動します。

9. 「OK」をクリックして、式を保存します。

3.3.4 Groovy式を使用したデフォルト値の作成時の処理

Groovy式を使用してデフォルト値を定義すると、データ・コントロール構造ファイルの対応する属性におけるタグ内に<TransientExpression>タグが追加されます。例3-1に、デフォルト値に現在の日付を返すGroovy式のサンプルXMLコードを示します。

例3-1 デフォルトの日付値

<TransientExpression>
<![CDATA[
adf.currentDate
]]>
</TransientExpression>

3.3.5 属性へのUIヒントの設定方法

属性のUIヒントを設定し、それらの属性を使用するすべてのUIコンポーネントでそれらの属性が一貫したローカライズ可能な方法で表示およびラベル付けされるように設定できます。属性に対してUIヒントを作成するには、アプリケーション・ナビゲータからアクセス可能な、Beanのデータ・コントロール構造ファイルの概要エディタを使用します。

始める前に:

属性プロパティの設定方法の知識があると役立ちます。詳細は、3.3項「属性の使用」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

UIヒントを設定する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで編集する属性を選択し、「UIヒント」タブをクリックします。

4. 「UIヒント」ページで、必要なUIヒントを設定します。

様々なUIヒントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のビュー・オブジェクトの属性UIヒントの定義に関する項を参照してください。

注意:

ビュー・オブジェクトは、SQL問合せのカプセル化と結果の操作の単純化に使用されるADF Business Componentsです。この項を読む際、ビュー・オブジェクトをBeanと読み替えてください。

3.3.6 属性へのUIヒントの設定時の処理

属性に対してUIヒントを設定すると、それらのヒントはJDeveloperによってプロパティとして扱われます。プロパティのタグがBeanのデータ・コントロール構造ファイルに追加され、プロパティの値はリソース・バンドル・ファイルに保存されます。リソース・バンドル・ファイルが存在しない場合は、データ・コントロールのパッケージに生成され、初めてUIヒントを設定した際にプロジェクト名に従って名前が設定されます。たとえば、Summitデモ・アプリケーションでは、リソース・バンドルはModelBundle.propertiesと呼ばれます。

例3-2に、Summitデモ・アプリケーションのItem.xmlデータ・コントロール構造ファイルにおけるprice属性のコードを示します。属性に対して設定されているラベルおよびフォーマット・タイプ・ヒントのタグも含まれます。

例3-2 UIヒントのXMLコード

<PDefAttribute
Name="price">
<Properties>
<SchemaBasedProperties>
<LABEL
ResId="${adfBundle['model.ModelBundle']['model.Item.price_LABEL']}"/>
<FMT_FORMATTER
ResId="${adfBundle['model.ModelBundle']['model.Item.price_FMT_
FORMATTER']}"/>
</SchemaBasedProperties>
</Properties>
</PDefAttribute>

例3-3に、ModelBundle.propertiesリソース・バンドル・ファイルにおけるラベルおよびフォーマット・タイプ・ヒントの対応するエントリを示します。これらにはプロジェクトのすべてのローカライズ可能なプロパティの値も含まれています。

例3-3 UIヒントのリソース・バンドル・コード

model.Item.price_LABEL=Price
. . .
model.Item.price_FMT_FORMATTER=oracle.jbo.format.DefaultCurrencyFormatter

3.4 Beanへの一時属性の追加

Beanのデータ・コントロール構造ファイルには、基礎となる表内の列にマップされる属性のみでなく、計算された値を表示する一時属性を組み込むことができます。

たとえば、FullNameなどの作成した一時属性は、FirstName属性の値とLastName属性の値を連結した値に基づいて計算できます。

一時属性を作成すると、属性定義でGroovy式を使用してデフォルト値を指定できます。

3.4.1 一時属性の追加方法

一時属性を作成するには、概要エディタの「属性」ページを使用します。

始める前に:

一時属性および計算属性の知識があると役立ちます。詳細は、3.4項「Beanへの一時属性の追加」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

Beanのデータ・コントロール構造ファイルに一時属性を追加する手順:

1. 「アプリケーション・ナビゲータ」で、Beanのデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックし、「新規」アイコンをクリックします。

3. 「新規ビュー属性」ダイアログで、属性の名前を入力し、「OK」をクリックします。

4. 概要エディタで、「詳細」タブをクリックし、「タイプ」ドロップダウン・リストからオブジェクト・タイプを選択します。

5. オプションで、「デフォルト値」セクションでデフォルト値を設定するか、デフォルト値を計算する式を入力します。
デフォルト値を計算する式の設定方法は、3.3.3項「Groovy式を使用したデフォルト値の定義方法」を参照してください。

6. 値を式によって計算する場合、「更新可能」を「なし」に設定します。

3.4.2 一時属性の追加時の処理

一時属性を追加すると、JDeveloperによって<ViewAttribute>タグがBeanのデータ・コントロール構造ファイルに追加され、新しい属性が反映されます。例3-4に、LineItemTotalという一時属性のXMLコードを示します。これはpriceおよびquantity属性の値を乗算する式を基礎としています。

例3-4 一時属性のXMLコード

<ViewAttribute
Name="LineItemTotal"
IsUpdateable="false"
IsSelected="false"
IsPersistent="false"
PrecisionRule="true"
Type="java.lang.String"
ColumnType="$none$">
SQLType="VARCHAR">
<RecalcCondition><![CDATA[true]]></RecalcCondition>
<TransientExpression><![CDATA[price * quantity]]></TransientExpression>
<Dependencies>
<Item
Value="price"/>
<Item
Value="quantity"/>
</Dependencies>
</ViewAttribute>

3.5 属性への検証ルールの宣言的な定義

検証ルールを作成および管理する最も容易な方法は、宣言的検証ルールを使用することです。宣言的検証ルールは概要エディタを使用して定義され、いったん作成されると、Beanのデータ・コントロール構造ファイルに保存されます。ビジネス・ロジックをこのようにカプセル化することにより、ビジネス情報にアクセスするすべてのクライアントで情報が一貫して検証され、検証の保管先を集中化することによって管理が容易になります。

Oracle ADFでは、大部分のビジネス上のニーズを満たすことができる組込みの宣言的な検証ルールが用意されています。3.5.4項「検証とビジネス・ルールでのGroovy式の使用方法」で説明されているように、Groovy式を検証の基礎にすることもできます。

検証ルールを追加する際、適切なエラー・メッセージを提供し、後に必要に応じて容易に他の言語に翻訳できます。また、重大度レベルも設定できます。

アプリケーションがビジネス・レイヤー検証に加えてページ・レベルでの検証の使用も保証する必要がある場合は、Beanで利用できる宣言的検証機能の多くをページ・レベルでも利用できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「ADFモデル・レイヤーでの検証の使用」の章を参照してください。

注意:

カスタム検証クラスを実装することによって検証ルールを追加することもできます。アプリケーションで複数回使用する必要のある複雑なパラメータ化された検証ルール(クレジット・カードの番号のチェックなど)を定義する必要がある場合、この方法が特に便利です。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のカスタム検証ルールの実装に関する項を参照してください。

3.5.1 属性への検証ルールの追加方法

Beanに検証ルールを追加する手順は、ほとんどの検証ルールと同じで、「検証ルールの追加」ダイアログを使用します。このダイアログを開くには、Beanのデータ・コントロール構造ファイルを開き、「属性」ページで属性を選択し、「検証ルール」タブをクリックして「追加」アイコンをクリックします。

「検証ルールの追加」ダイアログを使用してルールを宣言的に定義すると、そのルール定義が属性の有効な条件を指定することに注意する必要があります。実行時に、ユーザーが入力したエントリがルール定義に対して評価され、エントリが指定された基準を満たさない場合、エラーまたは警告が発せられます。たとえば、12より小さいか等しい必要のある属性に対して長さのバリデータを指定した場合、エントリが12文字よりも長いと検証が失敗し、エラーまたは警告が発行されます。

データ・コントロール構造ファイルに宣言的検証ルールを追加するには、Beanの概要エディタの「属性」ページを使用します。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

検証規則を追加する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログで、「ルール・タイプ」ドロップダウン・リストから、目的の検証ルールのタイプを選択します。

6. ダイアログの設定を使用して新しい規則を構成します。
このコントロールの内容は、選択する検証規則の種類によって異なります。様々な検証ルールの詳細は、3.5.3項「組込みの宣言的検証ルールの使用方法」を参照してください。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.6項「検証例外の重大度レベルの設定方法」を参照してください。

8. 「OK」をクリックします。

3.5.2 検証規則の追加時の処理

Beanに検証ルールを追加すると、Beanのデータ・コントロール構造ファイルが更新され、使用したルールと入力したルールのプロパティを示すエントリが含まれます。

たとえば、dateShipped属性に、出荷日がdateOrdered属性よりも前ではないことを確認する比較検証ルールを追加すると、XMLファイルに<validation:CompareValidationBean>エントリが作成されます(例3-5を参照)。

例3-5 Compare Validator

<validation:CompareValidationBean
Name="dateShipped_Rule_0"
ResId="${adfBundle['model.ModelBundle']['model.Ord.dateShipped_Rule_0']}"
OnAttribute="dateShipped"
OperandType="EXPR"
Inverse="false"
CompareType="GREATERTHANEQUALTO">
<validation:TransientExpression><![CDATA[dateOrdered]]>
</validation:TransientExpression>
</validation:CompareValidationBean>

3.5.3 組込みの宣言的な検証ルールの使用方法

組込みの宣言的な検証規則は、大部分のビジネス上のニーズを満たすことができます。このような規則は、コードの記述がないため実装が簡単です。検証のタイプとその使用方法を選択するには、ユーザー・インタフェース・ツールを使用します。

組込みの宣言的な検証規則を使用すると、次のことが可能です。

- 属性とリテラル値または式の比較

- 値が一定の範囲内にあるか、または特定のバイト数または文字数に制限されるかの確認

- 正規表現による検証またはGroovy式の評価

3.5.3.1 比較に基づいた検証

Compare Validatorは、エンティティ属性と値の論理比較を実行します。Compare Validatorの追加時に、演算子および比較対象を指定します。次のものを比較できます。

- リテラル値
Compare Validatorでリテラル値を使用すると、属性の値は指定したリテラル値と比較されます。この種類の比較を使用する場合は、データの型と書式を考慮することが重要です。リテラル値は、規則を適用するエンティティ属性のデータ型で指定した書式に準拠する必要があります。すべての場合において、型はエンティティ属性のタイプ・マッピングに対応します。

たとえば、列タイプDATEの属性はoracle.jbo.domain.Dateクラスにマッピングされますが、これはjava.sql.TimeStampおよびjava.sql.Dateによって受け入れられるのと同じ書式で日付と時間を受け入れます。書式マスクを使用することにより、属性の値の書式が指定されたリテラルに一致するよう指定できます。

- 式
式のオプションについては、3.5.4項「検証とビジネス・ルールでのGroovy式の使用方法」を参照してください。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

比較に基づいて検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「比較」を選択します。選択に応じて下位のフィールドは変わります。

6. 適切な演算子を選択します。

7. 「比較」リストで項目を選択し、選択項目に基づいて適切な比較値を指定します。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

9. 「OK」をクリックします。

3.5.3.2 比較に基づく検証時の処理

Compare Validatorを作成すると、<validation:CompareValidationBean>タグがBeanのデータ・コントロール構造ファイルに追加されます。

例3-5は、Ordデータ・コントロール構造ファイルのdateShipped属性に対するバリデータのXMLコードを示しています。

3.5.3.3 値リストを使用した検証

List Validatorは、属性値を値リストと比較します。バリデータは、Bean属性の値が値リスト内(指定された場合はリスト外)にあることを確認します。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

値リストを使用して検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「リスト」を選択します。

6. 「演算子」フィールドで、包含的リストか排他的リストかに応じて「In」または「NotIn」を選択します。

7. 「値リストの入力」セクションで、値を1行に1つずつ入力します。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

9. 「OK」をクリックします。

3.5.3.4 リスト値を使用した検証時の処理

値リストを使用して検証すると、<validation:ListValidationBean>タグがBeanのデータ・コントロール構造ファイルに追加されます。

3.5.3.5 値が特定の範囲内にあることの確認

Range Validatorは、エンティティ属性と値の範囲の論理比較を実行します。Range Validatorの追加時に、最小および最大のリテラル値を指定します。Range Validatorは、エンティティ属性の値が範囲内(指定された場合は、範囲外)にあることを検証します。

最小および最大値を動的に算出する必要がある場合や、エンティティの他の属性を参照する必要がある場合は、Script Expression Validatorを使用し、Groovy式を指定します。詳細は、3.8.1項「Groovy式でのADFオブジェクトの参照方法」を参照してください。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

特定の範囲内を検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「範囲」を選択します。

6. 「演算子」フィールドで、「Between」または「NotBetween」を選択します。

7. 「最小値」および「最大値」フィールドに適切な値を入力します。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

9. 「OK」をクリックします。

3.5.3.6 Range Validatorの使用時の処理

範囲に対して検証すると、<validation:RangeValidationBean>タグがデータ・コントロール構造ファイルに追加されます。

例3-6に、最小値が0で最大値が10のquantity属性を示します。

例3-6 Range ValidatorのXMLコード

<PDefAttribute
Name="quantity">
<validation:RangeValidationBean
Name="quantity_Rule_0"
ResId="${adfBundle['model.ModelBundle']['QUANTITY_VALIDATOR']}"
OnAttribute="quantity"
OperandType="LITERAL"
Inverse="false"
MinValue="0"
MaxValue="10"/>
. . .
</PDefAttribute>

3.5.3.7 バイトまたは文字数に対する検証

Length Validatorは、属性値の文字列長(文字またはバイト)が、指定した数より小さい、等しい、それより大きい、またはその範囲内かどうかを検証します。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

バイトまたは文字数を検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「長さ」を選択します。

6. 「演算子」フィールドで、値を評価する方法を選択します。

7. 「比較タイプ」フィールドで、「バイト」または「文字」を選択し、長さを入力します。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

9. 「OK」をクリックします。

3.5.3.8 バイトまたは文字数に対する検証時の処理

長さを使用して検証すると、<validation:LengthValidationBean>タグがデータ・コントロール構造ファイルに追加されます(例3-7を参照)。たとえば、ユーザーがパスワードまたはPINを入力するフィールドがあり、アプリケーションによってそれが6文字以上、10文字以下であることを検証するとします。Length ValidatorでBetween演算子を使用し、最小値および最大値をそれぞれ設定します。

例3-7 2つの値の長さの検証

<validation:LengthValidationBean
OnAttribute="pin"
CompareType="BETWEEN"
DataType="CHARACTER"
MinValue="6"
MaxValue="10"
Inverse="false"/>

3.5.3.9 正規表現を使用した検証

Regular Expression Validatorは、Java正規表現によって指定されたマスクに対して属性値を比較します。

メタデータでパーソナライズできる式を作成する場合は、Script Expression Validatorを使用できます。詳細は、3.5.4項「検証とビジネス・ルールでのGroovy式の使用方法」を参照してください。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

正規表現を使用して検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「正規表現」を選択します。

6. 「演算子」フィールドで、「一致」または「不一致」を選択します。

7. 事前定義された式(ある場合)を使用するには、ドロップダウン・リストから選択して「パターンの使用」をクリックします。事前定義された式を使用しない場合は、表示されているフィールドに独自の正規表現を記述します。

8. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

9. 「OK」をクリックします。

図3-3は、Regular Expression Validatorを選択して、Email属性が事前定義されたEmail Address式に一致することを検証する場合のダイアログを示しています。

図3-3 電子メール・アドレスを照合するRegular Expression Validator

3.5.3.10 正規表現を使用した検証時の処理

正規表現を使用して検証すると、<RegExpValidationBean>タグがデータ・コントロール構造ファイルに追加されます。例3-8は、正規表現に一致する必要のあるEmail属性を示しています。

例3-8 Regular Expression ValidatorのXMLコード

<validation:RegExpValidationBean
Name="Email_Rule_0"
OnAttribute="Email"
Pattern="[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}"
Flags="CaseInsensitive"
Inverse="false"/>

3.5.4 検証とビジネス・ルールでのGroovy式の使用方法

Groovy式は、データ・コントロール構造ファイルに格納されている、Javaのようなスクリプト・コードです。実行時でも値の変更や指定ができます。

検証ルールの作成の詳細は、第3章「属性への検証ルールの宣言的な定義」を参照してください。

ビジネス・ロジックでのGroovy式使用の詳細は、3.8項「Groovy言語サポート」を参照してください。

3.5.4.1 Groovy検証式でのBeanメソッドの参照

現在のオブジェクトのadf.source.dataProviderプロパティを使用すると、Beanに対してメソッドをコールできます。adf.source.dataProviderプロパティでは、検証対象のBeanにアクセスできます。

メソッドがブール型以外で、メソッド名が引数なしのgetXyzAbc()の場合、XyzAbcという名前のプロパティのようにその値にアクセスします。たとえば、例3-9のGroovy式により、getXyzAbc()メソッドがコールされます。

例3-9 サンプルのメソッドをコールするGroovy式

adf.source.dataProvider.XyzAbc

ブール・プロパティの場合は、同じ条件が当てはまりますが、JavaBeansコンポーネントのgetterメソッドの命名パターンが変更され、getXyzAbc()ではなくisXyzAbc()を再認識します。BeanのメソッドがJavaBeansのgetterメソッドの命名パターンに一致しない場合や、1つ以上の引数を使用する場合は、完全名を使用したメソッドのようにコールする必要があります。

3.5.4.2 true/false式を使用した検証

Groovy式を使用してtrue/false文を返すことができます。Script Expression Validatorでは、必ず式がtrueまたはfalseを返す必要があり、そうでなければadf.error.raise/warn()メソッドがコールされます。この機能の一般的な用途は、属性値の検証です(アカウント番号が有効であるかの確認など)。

注意:

adf.error.raise()およびadf.error.warn()メソッドを使用することにより(単純にtrueまたはfalseを返すかわりに)、ユーザーに表示するメッセージ・テキストを定義でき、バリデータを特定の属性に関連付けることができます。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

始める前に:

データ・コントロール構造ファイルにおける検証に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

また、検証ルールでのGroovyの使用方法を理解していると役立ちます。詳細は、3.5.4項「検証とビジネス・ルールでのGroovy式の使用方法」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

true/false式を使用して検証する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証ルールを追加する属性を選択し、「検証ルール」タブをクリックします。

4. ページの「検証ルール」セクションで、「検証ルールの追加」アイコンをクリックします。

5. 「検証ルールの追加」ダイアログの「ルール・タイプ」ドロップダウン・リストで「スクリプト式」を選択します。

6. 表示されているフィールドに検証式を入力します。

7. 「失敗処理」タブをクリックして、検証規則が失敗した場合にユーザーに対して表示されるエラー・メッセージを入力または選択します。詳細は、3.5.5項「検証エラー・メッセージの作成方法」を参照してください。

8. 「OK」をクリックします。

3.5.4.3 true/false式を使用した検証時の処理

Groovy式を作成すると、Beanのデータ・コントロール構造ファイルに保存されます。Groovy式は、<TransientExpression>タグによってラップされます。一部のGroovy式では、<TransientExpression>タグは、<validation:ExpressionValidationBean>タグによってもラップされます。

3.5.5 検証エラー・メッセージの作成方法

検証エラー・メッセージはユーザーにとって重要な情報であり、メッセージは不具合やその修正方法を伝達する必要があります。

3.5.5.1 検証エラー・メッセージの作成

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

検証エラー・メッセージを作成する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証エラー・メッセージを作成する属性を選択し、「検証ルール」タブをクリックします。

4. 「属性」ページの「検証ルール」セクションで、編集する検証ルールを選択し、「検証ルールの編集」アイコンをクリックします。

5. 「検証規則の編集: {0}」ダイアログで、「失敗処理」タブをクリックします。

6. 「メッセージ・テキスト」フィールドで、エラー・メッセージを入力します。
メッセージ・バンドル・ファイルにエラー・メッセージを定義することもできます。定義済のエラー・メッセージを選択する場合や、メッセージ・バンドル・ファイルに新しいエラー・メッセージを定義する場合は、「メッセージの選択」アイコンをクリックして、「テキスト・リソースの選択」ダイアログを開きます。

注意:

Script Expression Validatorでは、複数のエラー・メッセージを入力できます。これは、条件によって異なるエラーメッセージや警告メッセージを検証スクリプトで戻す場合に便利です。詳細は、3.5.5.3項「Groovyを使用した条件付きでのエラー・メッセージの呼出し」を参照してください。

7. オプションで、メッセージ・トークンを定義するには、メッセージ・トークン名をエラー・メッセージのテキスト内に中カッコ({})で囲んで入力します。トークンのエントリが「トークン・メッセージ式」セクションに表示されます。その後、メッセージ・トークンの値を「トークン・メッセージ式」リストで定義します。
図3-4は、メッセージ・トークンが含まれている、データ・コントロール構造ファイルの検証ルールに対する失敗メッセージを示しています。この機能の詳細は、3.5.5.4項「エラー・メッセージへのGroovy式の埋込み」を参照してください。

8. 「OK」をクリックします。

図3-4 検証ルールの失敗処理メッセージ

3.5.5.2 検証メッセージのローカライズ

エラー・メッセージは翻訳可能文字列であり、メッセージ・バンドル・ファイルの翻訳可能UIコントロール・ヒントと同じように管理されます。メッセージ・バンドル・クラス内の定義済ルールのエラー・メッセージを表示するには、そのバリデータに関するデータ・コントロール構造ファイルのエントリのResIdプロパティに対応するメッセージ・バンドルのStringキーを探します。

3.5.5.3 Groovyを使用した条件付きでのエラー・メッセージの呼出し

adf.error.raise()およびadf.error.warn()メソッドを使用して、Groovy式の分岐に応じて様々なエラー・メッセージを条件付きで呼び出すことができます。たとえば、属性値がxの場合は次のように検証し、検証が失敗した場合はエラーmessageAを呼び出し、一方、属性値がyの場合は別の検証を実行し、検証が失敗した場合はエラーmessageBを呼び出します。

式でfalseが戻される(raise()メソッドを使用して特定のエラー・メッセージが呼び出されるのに対して)場合、バリデータは、そのバリデータに関連付けられた最初のエラー・メッセージをコールします。

raise()メソッドの構文は必須パラメータを1つ(メッセージ・バンドルから使用するためのmsgId)利用し、オプションでattrNameパラメータを利用することができます。

例外をスローするか、処理を継続するかに応じて、adf.error.raise()またはadf.error.warn()のいずれのメソッドも使用できます(3.5.6項「検証例外の重大度レベルの設定方法」を参照)。

3.5.5.4 エラー・メッセージへのGroovy式の埋込み

バリデータのエラー・メッセージには、実行時にサーバーによって解決できる埋込み式を含めることができます。この機能にアクセスするには、Groovy式の結果を表示させるエラー・メッセージ・テキストに名前付きトークン{#}({2}や{errorParam}など)を入力するのみです。

「検証規則の編集: {0}」ダイアログの「失敗処理」タブで、エラー・メッセージのテキストにトークンを入力すると、ダイアログの下部の「トークン・メッセージ式」表で行が表示され、トークンのGroovy式を入力できます。図3-4は、メッセージ・トークンが含まれている、Item.xmlデータ・コントロール構造ファイルの検証ルールに対する失敗メッセージを示しています。

図3-4に示された式は、quantity属性の値を返すGroovy式です。また、Groovy式を使用して、データ・コントロール構造ファイルで定義されている属性のUIヒントやその他のオブジェクトにアクセスできます。

Groovy式newValueを使用して入力された値を返すことができます。

Groovyを使用してADFオブジェクトにアクセスする方法の詳細は、3.8項「Groovy言語サポート」を参照してください。

3.5.6 検証例外の重大度レベルの設定方法

検証例外の重大度レベルを、「情報警告」または「エラー」のいずれかに設定できます。重大度レベルを「情報警告」に設定すると、エラー・メッセージが表示されますが、処理は継続します。検証レベルを「エラー」に設定すると、エラーが修正されるまでユーザーは処理を続行できません。

通常、検証例外には「エラー」レベルを使用するため、これがデフォルト設定です。ただし、ユーザーが特定の機密取扱い資格を保持する場合は、情報警告メッセージを実装できます。たとえば、店長は事務員が同じことをした場合に、エラーとして表示されるように変更できます。

検証例外の重大度レベルを設定するには、「検証ルールの追加」ダイアログの「失敗処理」タブを使用します。

始める前に:

データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、3.5項「属性への検証ルールの宣言的な定義」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

検証例外の重大度レベルを設定する手順:

1. 「アプリケーション・ナビゲータ」で、使用するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。

3. 「属性」ページで検証エラー・メッセージを作成する属性を選択し、「検証ルール」タブをクリックします。

4. 「属性」ページの「検証ルール」セクションで、編集する検証ルールを選択し、「検証ルールの編集」アイコンをクリックします。

5. 「検証ルールの編集」ダイアログで、「失敗処理」タブをクリックし、「エラー」または「情報警告」のいずれかのオプションを選択します。

6. 「OK」をクリックします。

3.6 名前付き基準を使用した結果セットのフィルタリング

JDeveloperでは、データ・コントロール構造ファイルについて名前付き基準を作成できます。名前付き基準は、アプリケーションのデータ・モデルで使用し、検索フォームのシードされた問合せとしてユーザーに公開できます。

エンティティBeanで名前付き基準を指定して、表示する結果をフィルタリングできます。名前付き基準オブジェクトは1つ以上の名前付き基準行の行セットであり、この属性によってエンティティBean内の属性がミラーリングされます。名前付き基準の定義には、SQL問合せのWHERE句のように機能する問合せ条件が含まれています。

名前付き基準の結果セットでは、各属性のデータ型はStringであるため、QBE演算子を使用できます。たとえば、これによってユーザーは"OrderId > 304"のような条件を入力できます。

特定のデータ・コントロール構造ファイルに対して名前付き基準を定義するには、概要エディタの「名前付き基準」ページを使用します。

注意:

名前付き基準以外にも、データ・コントロールの作成時にエンティティBeanについて自動的に生成される暗黙的基準も存在します。暗黙的基準は、指定された表のすべてのデータを返すFindAllサービス・メソッドに基づきます。

名前付き基準および暗黙的基準のいずれも、「データ・コントロール」パネルの「名前付き基準」ノードの下に表示されます。暗黙的基準は、「すべての問合せ可能な属性」として表示されます。

3.6.1 名前付き基準の用途

個々のアクセッサ結果をフィルタリングする必要がある場合、名前付き基準定義を作成します。デザインタイムで定義した名前付き基準は、ターゲット・データ・コントロール構造ファイルの属性の値をエンド・ユーザーが指定できるような、QBEの検索フォームを簡単に作成する際に使用できます。

たとえば、エンド・ユーザーは、顧客名の値および日付を入力することによって、CustomerOrdersコレクションの行が表示されるWebページで結果をフィルタリングできます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルに表示される名前付き基準を基に、検索フォームを容易に作成できます。「データ・コントロール」パネルに表示される名前付き基準の利用方法の詳細は、8.1.1項「問合せ検索フォーム」を参照してください。

3.6.2 名前付き基準を宣言的に作成する方法

フィルタリングするデータ・コントロール構造ファイルの名前付き基準を定義するには、概要エディタでデータ・コントロール構造ファイルを開き、「基準の表示」ページの「名前付き基準」セクションを使用します。「名前付き基準」セクション・ヘルプから開く専用エディタで、属性名(SQL列名ではなく)を使用してWHERE句に相当するものを作成できます。名前付き基準は、1つのBeanに対して複数定義できます。

名前付き基準の定義はそれぞれ、次の要素で構成されています。

- 1つ以上の名前付き基準行。名前付き基準行は、任意の数の名前付き基準グループ、または現在のデータ・コントロール構造ファイルに対して定義されている別の名前付き基準への任意の数の参照で構成されます。

- 任意の数の名前付き基準アイテムで構成される、オプションの名前付き基準グループ。

- 属性名、属性に適した演算子、およびオペランドで構成される名前付き基準アイテム。オペランドには、フィルタの値が定義されている場合はリテラル値か、または、属性のプロパティ値へのドット表記アクセスを含むスクリプト式がオプションで利用可能なバインド変数を使用できます。
式の記述には、Groovyスクリプト言語を使用します(3.8項「Groovy言語サポート」を参照)。

名前付き基準を定義する場合は、フィルタリングされた結果のソースを制御します。結果を次のものに制限できます。

- エンティティBeanで指定されたデータベース表のみ。

- アクセッサ問合せのメモリー内の結果のみ。

- データベースおよびアクセッサ問合せのメモリー内の結果の両方。

データベース表とアクセッサのメモリー内の結果の両方でフィルタリングを実行する場合、トランザクションで作成されており、データベースのコミット前である行もフィルタリングできます。

「ビュー基準の編集」ダイアログで作成する名前付き基準の式では、論理積により、選択した基準アイテム(または基準グループ)とその前にあるアイテム(またはグループ)を式の中でどのように結合するかを指定できます。

- AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれの名前付き基準アイテムを追加する場合は、これがデフォルトになります。

- OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。名前付き基準グループに対しては、これがデフォルトになります。

さらに、様々な名前付き基準アイテム間の論理積をより制御するために、ネストされた名前付き基準を作成できます。ネストされた名前付き基準グループは、任意の数のネストされた名前付き基準アイテムで構成されます。ネストされた基準では、その親名前付き基準グループの中で基準を満たしている行が制限されます。たとえば、給与がSalary > 3000という基準を満たし、かつ所属部署がDeptNo = 10またはDeptNo = 20という基準を満たしている従業員のリストを問い合せる場合があります。この場合、1つの項目Salary > 3000を含む第1のグループを使用して名前付き基準と、2つの項目DeptNo = 10およびDeptNo =20を含む第2のグループを使用してネストされた名前付き基準を定義できます。

始める前に:

名前付き基準の知識があると役立ちます。詳細は、3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

次のタスクを完了する必要があります。

- 3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

- 名前付き基準がオペランドでバインド変数を使用する場合、3.6.4項「名前付き基準でバインド変数を使用する方法」を参照してバインド変数を作成します。

名前付き基準を定義する手順:

1. 「アプリケーション・ナビゲータ」で、名前付き基準を作成するデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「名前付き基準」ナビゲーション・タブをクリックします。

3. 「名前付き基準」ページで、「名前付き基準」セクションを展開して「新規ビュー基準の作成」ボタンをクリックします。

4. 「ビュー基準の作成」ダイアログで、名前付き基準の名前を入力し、アプリケーション内での用途がわかるようにします。

5. 「基準実行モード」ドロップダウン・リストで、名前付き基準によって問合せ結果をどのようにフィルタリングするかを決定します。
フィルタリングの名前付き基準は、アクセッサ問合せにより指定されたデータベース表、問合せにより生成されたメモリー内の行セット、またはデータベース表とメモリー内の結果の両方に制限できます。

適用したアソシエーションの一貫性の結果として作成された行を含める場合は、「両方」を選択することが適切です。この場合は、最初のフェッチの後にメモリー内フィルタリングが実行されます。

6. 名前付き基準を定義するには、次のいずれかの「追加」ボタンをクリックします。

- 単一の基準アイテムを追加するには、「アイテムの追加」を選択します。エディタによって、現在のグループまたは選択した名前付き基準の下の階層にアイテムが追加されます。デフォルトでは、アイテムを追加するたびに、エディタによって次の属性が選択され、基準アイテムが定義されます。属性は、データ・コントロール構造ファイルが定義する任意の属性に変更できます。

- 新しいグループを追加して、構成する基準アイテムをそのグループに追加するには、「グループの追加」を選択します。新しいグループを追加すると、エディタによって階層にOR結合が挿入されます。この結合は必要に応じて変更できます。

- 定義する名前付き基準を追加するには、「基準の追加」を選択します。この選択肢は、データ・コントロール構造ファイルにすでに存在する名前付き基準を追加する場合の代替の方法となります。新しい名前付き基準を追加すると、エディタによって階層にAND結合が挿入されます。この結合は必要に応じて変更できます。別の名前付き基準を追加するたびに、階層で現在選択している名前付き基準の下に新しい名前付き基準がエディタによってネストされます。階層のルート・ノードでは、現在編集中の名前付き基準が定義されます。

- データ・コントロール構造ファイルですでに定義されている名前付き基準を追加するには、「名前付き基準の追加」を選択します。

注意:

名前付き基準からUIデザイナによって作成される検索フォームでは、別の名前付き基準が含まれている名前付き基準を使用できません。

7. 名前付き基準階層の名前付き基準アイテム・ノードを選択し、追加したノードを「基準アイテム」セクションで定義します。

8. 基準アイテムで、必要な「属性」を選択します。デフォルトでは、リストの最初のノードがエディタによって追加されます。

9. 必要な「演算子」を選択します。
リストには、選択した属性に適合する演算子のみが表示されます。String型およびDate型属性の場合、「次の間にある」および「次の間にない」演算子では、範囲を定義するために2つのオペランド値を指定する必要があります。Date型属性の場合、日付または日付の範囲をテストする演算子を選択できます(YYYY-MM-DDの書式で入力された日付値について)。たとえば、2010年12月16日の場合、2010-12-16と入力します。

10. 選択した名前付き基準アイテムで、必要な「オペランド」を選択します。

- 属性に値を指定したり、QBE検索フォームに対するユーザー指定の検索フィールドにデフォルト値を定義する場合は、「リテラル」を選択します。名前付き基準でユーザー・インタフェースの問合せ検索フォームを定義する場合は、「値」フィールドが空のままでも構いません。この場合は、ユーザーが値を指定します。検索フィールドのデフォルト値として機能する値を指定して、ユーザーが上書きできるようにすることもできます。「値」フィールドに指定した値には、ワイルドカード文字の*または%を含めることができます。

- バインド変数を使用して実行時に値を決定する場合は、「バインド変数」を選択します。「新規」をクリックして「バインド変数」ダイアログを表示し、そこでデータ・コントロール構造ファイルに対するバインド変数を新規に作成します。バインド変数の作成の詳細は、3.6.4項「名前付き基準でのバインド変数の使用方法」を参照してください。

11. 定義する各アイテム、グループまたはネストされた名前付き基準に対して、必要に応じてデフォルト設定の論理積を変更し、アイテムの結合方法を指定します。

- AND結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれの名前付き基準アイテムまたはネストされた名前付き基準を追加する場合は、この結合がデフォルトになります。

- OR結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。名前付き基準グループに対しては、これがデフォルトになります。

12. オプションで、実行時に指定された値の大/小文字に基づいてフィルタリングする場合は、「大/小文字を区別しない」オプションの選択を解除します。デフォルトでは選択されており、このようなフィルタリングはされません。
基準アイテムには、定義したリテラル値またはエンド・ユーザーが入力するランタイム・パラメータを使用できます。このオプションは、String型の属性に対してのみサポートされています。デフォルトでは、大/小文字の区別のある検索は使用できません。

13. 「検証」ドロップダウン・リストで、生成されたWHERE句での属性値の比較において、名前付き基準アイテムを必須とするかオプションとするかを決定します。

- 「選択的に必須」を選択すると、名前付き基準アイテムに基準値が入力されず、かつ基準値を持つ基準アイテムが同じレベルに少なくとも1つ存在する場合、生成されるWHERE句では実行時にその名前付き基準アイテムが無視されます。それ以外の場合は、例外がスローされます。

- 「オプション」を選択すると、値がNULLでない名前付き基準のみWHERE句に追加されます。新規の各名前付き基準アイテムに対してデフォルトの「オプション」を選択すると、NULL値に対しても例外は生成されません。

- 「必須」を選択すると、基準アイテムに値が入力されなかった場合は、WHERE句が実行されず例外がスローされます。

14. 名前付き基準でオペランドとしてバインド変数を使用する場合、IS NULL条件がWHERE句で生成されるかどうかを決定します。バインド変数の検証に「オプション」を選択した場合のみ、このフィールドが有効になります。

- 実行時にバインド変数値が入力されていない場合でも名前付き基準が結果を返すようにする場合、「Null値の無視」を選択したままにしておきます(デフォルト)。検証が「必須」またはオプションで必須に設定されている場合、名前付き基準は値を必要とし、このnull値を無視するオプションは無効になります。
たとえば、ユーザー検索フォームで使用されるバインド変数に対してこのオプションを選択したままにしておくと、そのバインド変数を持つフィールドに値を入力しなくても検索の結果が表示されます。

- 実行時にバインド変数値が入力されていない場合に名前付き基準がnullの結果を返すようにする場合、「Null値の無視」の選択を解除します。
検証の設定が「必須」またはオプションで必須の場合、null値の条件も削除されますが、別の使用方法をサポートします。必要な実行時の動作を実現するために、「Null値の無視」機能と組み合せて使用する必要があります。

15. 「OK」をクリックします。

3.6.3 名前付き基準の作成時の処理

名前付き基準を作成すると、名前付き基準定義がデータ・コントロール構造ファイルに追加され、概要エディタの「名前付き基準」ページに名前が表示されます。

名前付き基準のXMLコードを表示するには、データ・コントロール構造ファイルのソース・エディタを開きます。それぞれの名前付き基準定義には、「ビュー基準の作成」ダイアログで定義したグループの数に対応する、1つ以上の<ViewCriteriaRow>要素が含まれます。

3.6.4 名前付き基準でのバインド変数の使用方法

バインド変数を使用すると、実行時に計算される属性値を名前付き基準に組み込むことができます。

シードされた検索で名前付き基準を使用する場合は、エンド・ユーザーによるバインド変数を更新可能にできます。この更新可能オプションを使用する場合、エンド・ユーザーは検索フォームに値を入力する必要があります。

バインド変数が割り当てられている名前付き基準アイテムが必須でない場合、名前付き基準の実行ではバインド変数値を必要としません。この動作を強制する場合、「バインド変数」ダイアログでバインド変数が必須かどうかを指定できます。

バインド変数に対しては、デフォルト値を定義するか、属性プロパティ値へのドット表記法によるアクセスが可能なスクリプト式を記述できます。式の記述には、Groovyスクリプト言語を使用します(3.8項「Groovy言語サポート」を参照)。

名前付きバインド変数を名前付き基準に追加する場合は、データ・コントロール構造ファイルの概要エディタにある「名前付き基準」ページを使用します。必要な数のバインド変数を定義できます。

始める前に:

名前付き基準の知識があると役立ちます。詳細は、3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

次のタスクを完了する必要があります。

3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

名前付きバインド変数を作成する手順:

1. 「アプリケーション・ナビゲータ」でデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「名前付き基準」ナビゲーション・タブをクリックします。

3. 「名前付き基準」ページで、「バインド変数」セクションを展開して「新規バインド変数の作成」ボタンをクリックします。

4. 「バインド変数」ダイアログで、新しいバインド変数の名前およびデータ型を入力します。
バインド変数はデータ・コントロール構造ファイル属性と同じネームスペースを共有するため、既存の属性名と競合しない名前を指定します。

5. 必要に応じて、バインド変数のデフォルト値を指定します。

- 実行時に式から値が決定されるようにするには、Groovyスクリプト言語の式を入力し、値タイプ「式」を選択して、「値」フィールドに式を入力します。必要に応じて、「編集」をクリックして「式」ダイアログを開きます。「式」ダイアログは、式を記述できる大きめのテキスト領域です。

- デフォルト値を定義する場合は、値のタイプ「リテラル」を選択し、「値」フィールドにリテラル値を入力します。

6. 「バインド変数」ダイアログで「コントロール・ヒント」タブをクリックし、「ラベル・テキスト」、「フォーマットの種類」、「フォーマット」マスクなどのヒントを指定します。
名前付きバインド変数の値を入力できる検索ページなどのユーザー・インタフェースを作成する場合、ビュー・レイヤーではバインド変数のコントロール・ヒントが使用されます。「更新可能」オプションでは、エンド・ユーザーがユーザー・インタフェースを使用してバインド変数の値を変更できるようになるかどうかを制御します。バインド変数が更新可能でない場合、その値は開発者のみがプログラムで変更できます。

7. 「OK」をクリックします。

3.6.5 名前付き基準でのバインド変数使用時の処理

1つ以上の名前付きバインド変数を構造定義ファイルに追加すると、実行時にこれらの変数の値を容易に表示し、設定できるようになります。各バインド変数の名前、型およびデフォルト値の情報は、Beanのデータ・コントロール構造ファイルに保存されます。バインド変数に対してUIヒントを定義した場合、この情報はデータ・コントロール構造ファイルの他のUIヒントとともにモデル・プロジェクトのメッセージ・バンドル・ファイルに保存されます。

3.6.6 ネストされた式について

名前付き基準からUIデザイナによって作成される検索フォームでは、すべてのタイプのネストされた式が動作するわけではありません。特に、検索フォームでは、直接ネストされた名前付き基準をサポートしていません。このタイプのネストされた式では、1つの名前付き基準を別の名前付き基準の直接の子として定義します。それ自体が名前付き基準の子である基準アイテムの子として名前付き基準をネストしたネストされた式は、問合せ検索フォームでサポートされています。名前付き基準を使用した検索フォームの作成の詳細は、8.1.1項「問合せ検索フォーム」を参照してください。

3.6.7 名前付き基準にユーザー・インタフェース・ヒントを設定する方法

データ・コントロール構造ファイル・コレクションに対して作成された名前付き基準は、Webページ・デザイナがQBE検索フォームを作成する際に使用できます。Webページ・デザイナは、JDeveloperの「データ・コントロール」パネルから名前付き基準を選択して、Webアプリケーション用の検索フォームを作成します。Webページの検索フォームでは、「データ・コントロール」パネルで選択した名前付き基準に最初にバインドされるADF Faces問合せ検索コンポーネントが利用されます。実行時に、エンド・ユーザーは、「データ・コントロール」パネルに表示されるその他すべての名前付き基準の中からいずれかを選択できます。検索フォームでエンド・ユーザーが選択できる名前付き基準は、開発者シード検索と呼ばれます。問合せコンポーネントでは、「保存済の検索」ドロップダウン・リストに、これらのシードされた検索が自動的に表示されます。検索フォームの作成およびADF問合せ検索コンポーネントの使用の詳細は、8.2項「問合せ検索フォームの作成」を参照してください。

開発者がシードした検索はモデル・プロジェクト内で作成されるため、「ビュー基準の編集」ダイアログの「UIヒント」ページでは、問合せコンポーネントにおける個々の名前付き基準の実行時の使用方法に対して、デフォルト・プロパティを指定できます。実行時の問合せコンポーネントの動作は、次のシードされた検索プロパティからどれを選択するかによって決まります。

ADF問合せ検索コンポーネントで使用するシードされた検索を作成する場合は、「ビュー基準の編集」ダイアログの「UIヒント」ページで「リストに表示」を選択します。エンド・ユーザーの検索フォームに名前付き基準を表示しない場合は、「リストに表示」の選択を解除します。

始める前に:

名前付き基準の知識があると役立ちます。詳細は、3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

次のタスクを完了する必要があります。

- 3.2.1項「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。

- 3.6.2項「名前付き基準を宣言的に作成する方法」に記載されている説明に従って、名前付き基準を作成します。

ユーザー・インタフェースに使用する名前付き基準を構成する手順:

1. 「アプリケーション・ナビゲータ」で、シードされた検索に使用する名前付き基準が定義されているデータ・コントロール構造ファイルをダブルクリックします。

2. 概要エディタで、「名前付き基準」ナビゲーション・タブをクリックします。

3. 「名前付き基準」ページで、シードされた検索で使用する名前付き検索を選択して「編集」アイコンをクリックします。

4. 「ビュー基準の編集」ダイアログで、「UIヒント」タブをクリックして「リストに表示」が選択されていることを確認します。
この選択により、問合せコンポーネントによってシードされた検索が「保存済の検索」ドロップダウン・リストに表示されるかどうかが決まります。

5. 問合せコンポーネントの「保存済の検索」ドロップダウン・リストに追加するシードされた検索に対して、わかりやすい表示名を入力します。
何も入力しない場合、問合せコンポーネントでは、「名前付き基準の編集」ダイアログに表示される名前付き基準の名前が使用されます。

6. エンド・ユーザーが「保存済の検索」ドロップダウン・リストからシードされた検索を選択するたびに、検索結果が自動的に問合せコンポーネントに表示されるようにする場合は、「自動的に問合せ」を有効にします。
デフォルトでは、検索結果は表示されません。

7. オプションで、ユーザーにアイテムが基本モードまたは詳細モードのいずれで表示されるかを決定する「表示されたモード」プロパティを各ビュー基準アイテムについて設定します。

注意:

ユーザーに公開しないアイテムが名前付き基準に含まれている場合、「表示されたモード」設定に「なし」を使用して、検索フォームでそのアイテムを非表示にします。たとえば、ログインした顧客のカート内にある製品を検索するための名前付き基準は作成できますが、ユーザーが顧客IDを変更して別の顧客のカート内にある製品を表示することのないようにする必要があります。このようなシナリオでは、名前付きバインド変数を使用して、顧客IDに対応する名前付き基準アイテムを現在の顧客IDに設定します。バインド変数定義で変数が任意または更新不可に指定されている場合がありますが、UIヒント・プロパティの「表示」が「非表示」に設定されている場合は、「表示されたモード」の設定によってのみ、検索フォームに値が表示されるかどうかが決まります。

8. 必要に応じて、「基準アイテムUIのヒント」を適用して、エンド・ユーザーが検索フォームのモードを「基本」と「詳細」の間で切り替える際に、問合せコンポーネントで個々の基準アイテムをレンダリングするかどうかを構成します。
デフォルトでは、シードされた検索で定義した名前付き基準アイテムはすべて、どちらかのモードで表示されます。

レンダリングされた基準アイテムがDate型の場合、対応するBean属性のUIヒントも定義する必要があります。『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のビュー・オブジェクトの属性コントロール・ヒントの定義に関する項を参照して、Bean属性のフォーマットの種類のヒントをSimple Dateに設定し、フォーマット・マスクを適切な値に設定します。これによって検索フォームで日付値を使用できるようになります。

9. 「OK」をクリックします。

3.7 Oracle ADFモデル・テスターを使用したBeanメタデータのテスト

アプリケーションのビューの設計を開始する前に、Oracle ADFモデル・テスターを使用してモデルの様々な要素をテストできます。たとえば、モデルに検証ルールまたはUIコントロール・ヒントを追加した場合、それらのオブジェクトをページにバインドする前にテストできます。UIページを作成した後でも、問題が発生した場合、Oracle ADFモデル・テスターは問題を診断する補助となります。Oracle ADFモデル・テスターで問題を再現して、問題がアプリケーションのビューまたはコントローラ・レイヤーにあるのか、あるいはビジネス・サービス・レイヤーのアプリケーション・モジュール自体にあるのかを確認できます。

3.7.1 Oracle ADFモデル・テスターの実行方法

データ・コントロールに定義したメタデータをテストするには、アプリケーション・ナビゲータからアクセスできるOracle ADFモデル・テスターを使用します。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

注意:

EJBデータ・コントロールの場合、テスターはリモート・セッションBeanインタフェースのデータ・コントロールに対してのみ機能します。データ・コントロールをローカルBeanインタフェースに基づいて作成した場合、テスターを使用するにはリモートBeanインタフェースのメタデータをDataControls.dcxファイルに追加する必要があります。リモートBeanインタフェースのメタデータを追加するには、セッションBeanを右クリックし、「データ・コントロールの作成」を選択し、次に「EJBインタフェースの選択」ダイアログで「リモート」ラジオ・ボタンを選択します。

後で「データ・コントロール」パネルを使用してページにバインディングを追加する際、ローカルおよびリモート・インタフェースの両方の高レベル・ノードが表示されます。各ノードには、同じデータ・コントロール構造ファイルを参照するデータ・コントロール・コレクションの同一階層が含まれます。2つの階層の唯一異なる点は、参照されているセッションBeanのインタフェースのみです。

アプリケーションのBeanメタデータをテストする手順:

1. 「アプリケーション・ナビゲータ」で、目的のデータ・コントロールが含まれているプロジェクトを展開します。

2. 該当するセッションBeanを右クリックして「実行」を選択します。
アプリケーション・サーバーが起動し、Beanがサーバーにロードされるのを待ちます。

アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

または、デバッグを有効にしたOracle ADFモデル・テスターでアプリケーションを実行する場合は「デバッグ」を選択します。JDeveloperにより、ログ・ウィンドウのデバッガ・プロセス・パネルおよび各種デバッガ・ウィンドウが開きます。たとえば、Oracle ADFモデル・テスターを使用してデバッグする場合、ステータス・メッセージと例外を表示し、ソース・コードをステップ・インおよびステップ・アウトし、ブレークポイントを管理できます。

3. DataControls.dcxファイルを右クリックして「実行」を選択します。
図3-5に示すように、Oracle ADFモデル・テスターが開きます。

図3-5 Oracle ADFモデル・テスター

表3-1に、エンティティBeanを表示する際にOracle ADFモデル・テスターのツールバー・ボタンで実行する操作の概要を示します。

表3-1 Oracle ADFモデル・テスターのツールバー・ボタン

ボタン

操作

用途

別の行に移動

Oracle ADFモデル・テスターで表示される現在の行を変更します。最初、前、次、または最後の行に移動します。

新規行を挿入

新規の行を作成して挿入します。

現在の行を削除

現在の行を削除します。

データベースへの変更を保存

保留中のトランザクションに対してコミット操作を実行します。ただし、EJBデータ・コントロールの場合、変更は実際にはデータベースにコミットされません。

このボタンは、トランザクション・メソッドがセッション・ファサードに実装されている場合のみ使用できます。

前回の保存以降の変更をすべて取消し

保留中のトランザクションを取り消し、元の値をリストアします。

このボタンは、トランザクション・メソッドがセッション・ファサードに実装されている場合のみ使用できます。

ビュー基準の指定

「ビュー基準」ダイアログが表示され、ビュー基準を作成し、結果セットに適用できます。

行の検証

データ・コントロール構造ファイルで定義されている検証ルールを適用することにより、現在の行を検証します。最低1つのフィールドが編集可能でないと、使用できません。

3.7.2 Oracle ADFモデル・テスターを更新してプロジェクトの変更を表示する方法

データ・コントロールをテストする際、モデル・プロジェクト全体を再デプロイすることなく、データ・コントロールを繰り返し変更して再度テストできます。データ・コントロール構造ファイルへの変更を再ロードするには、単にOracle ADFモデル・テスターを閉じて再度開きます。

Javaコード、またはモデル・プロジェクトのJARファイルにパッケージ化した他のファイルを変更した場合は、そのJARを再ビルドし、内部アプリケーション・サーバーに再デプロイする必要があります。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

稼働中のOracle ADFモデル・テスターにデータ・モデルのメタデータを再ロードする手順:

1. 「アプリケーション・ナビゲータ」で、DataControls.dcxファイルを右クリックして「実行」を選択します。

2. Oracle ADFモデル・テスターで、データ・モデルをテストして、必要な変更を判別します。

3. JDeveloperで、プロジェクトに必要な変更を加えます。

4. Javaクラス、またはセッションBeanのJARファイルの一部である他のアーティファクトを変更した場合、プロジェクトを再ビルドします。(たとえば、「アプリケーション・ナビゲータ」のデータ・モデル・プロジェクトを右クリックして、「再ビルド」を選択します。再ビルドしたJARファイルがサーバーにデプロイされます。)
データ・コントロール構造ファイルのみを変更した場合、プロジェクトを再ビルドする必要はありません。

5. Oracle ADFモデル・テスターを閉じます。

6. 「アプリケーション・ナビゲータ」で、DataControls.dcxファイルを右クリックして「実行」を選択し、更新されたメタデータでテスターを再度開きます。

3.7.3 Oracle ADFモデル・テスター使用時の処理

Oracle ADFモデル・テスターを起動すると、JDeveloperがテスターを別のプロセスで開始し、Oracle ADFモデル・テスター・ウィンドウが表示されます。ウィンドウの左側のツリーには、データ・モデルのすべてのアクセッサ戻りコレクションが表示されます。データ・モデルにマスター/ディテールのビュー・インスタンス関係が定義されている場合、ツリーには親ノードと子コードとして関係が表示されます。目的のコレクションをダブルクリックすると、Oracle ADFモデル・テスターでデータ・ビュー・ページが表示され、問合せ結果をインスペクトできます。たとえば、図3-6では、customerFindAllアクセッサ戻りコレクションがダブルクリックされ、右側のデータ・ビュー・ページにこのコレクションの最初のレコードが表示されているところが示されています。

図3-6 Oracle ADFモデル・テスターに表示されたcustomerFindAllコレクションの詳細

Oracle ADFモデル・テスターの一部の機能を次に示します。

- 「ラベル・テキスト」ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。(UIヒントの設定方法は、3.3.5項「属性へのUIヒントの設定方法」を参照してください。)

- ツールバー・ボタンを使用してデータのスクロールもできます。

- Query-By-Example基準を入力して、検査対象のデータのある特定の行を検索できます。ツールバーの「ビュー基準の指定」ボタンをクリックすると、「ビュー基準」ダイアログに使用可能なQBE基準のリストが表示されます。
たとえば、CustomerInfoCriteriaなどのビュー基準を選択し、LastName属性にH%などの問合せ基準を入力して、「検索」をクリックすると、文字Hで始まる姓のユーザーのみに検索対象を絞り込むことができます。

3.7.4 ビジネス・レイヤーの検証のテスト方法

定義した検証規則に応じて、無効な値を入力して検証例外のトリガーおよび検証を試行できます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

次のタスクを完了する必要があります。

3.7.1項「Oracle ADFモデル・テスターの実行方法」の手順に従ってテスターを起動します。

ビジネス・レイヤーの検証をテストする手順:

1. テスターで、属性の値を入力して「行の検証」アイコンをクリックします。
たとえば、属性について範囲検証ルールを定義した場合、その範囲外の値を入力して「行の検証」アイコンをクリックします。次のようなエラーが表示されます。

(oracle.jbo.AttrSetValException) Valid product codes are between 100 and 999

2. ツールバーで「ロールバック」ボタンをクリックして、データを前の状態に戻します。

3.7.5 代替言語のメッセージ・バンドルおよびUIヒントのテスト方法

アプリケーションにおいて、リソース・メッセージ・バンドル内に代替言語を定義する場合、これらの言語を認識するようにOracle ADFモデル・テスターを構成できます。Oracle ADFモデル・テスターで「ロケール」メニューを表示し、利用可能な言語の中から選択できます。

Oracle ADFモデル・テスターで言語メッセージ・バンドルをテストすることで、データ・コントロールのUIヒントの翻訳が正しく配置されているかどうかを検証できます。または、メッセージ・バンドルが特定の属性の日付書式を定義している場合は、ツールによって日付書式の変更(たとえば、04/12/2007から12/04/2007へ)を検証できます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

Oracle ADFモデル・テスターのデフォルト言語を指定する手順:

1. 「ツール」メニューで「設定」を選択します。

2. 選択パネルで「ADFビジネス・コンポーネント」を展開し、「テスター」を選択します。

3. Oracle ADFモデル・テスター・ページで、リソース・メッセージ・バンドルを作成したロケールを「選択済」リストに追加します。

3.7.6 行の作成およびデフォルト値の生成のテスト方法

Oracle ADFモデル・テスターを使用して、新規行の作成時に属性のデフォルト値が正しく生成されるかどうかを検証できます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

また、データ・コントロール構造ファイル内の属性を理解していると役立ちます。詳細は、3.3項「属性の使用」を参照してください。

次のタスクを完了する必要があります。

3.7.1項「Oracle ADFモデル・テスターの実行方法」の手順に従ってテスターを起動します。

行の作成およびデフォルト値の生成をテストする手順:

1. Oracle ADFモデル・テスターのツールバーで「新規行の挿入」ボタンをクリックし、空白行を作成します。
宣言的なデフォルト値があるフィールドの場合、その値が空白行に表示されます。

2. テスターで、すべての必要なフィールドに入力して「コミット」ボタンをクリックします。

3.7.7 Oracle ADFモデル・テスターを使用した名前付き基準のテスト方法

Oracle ADFモデル・テスターでは、既存の名前付き基準を使用し、非定型基準で問い合せてデータ・モデルをテストできます。

始める前に:

Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、3.7項「Oracle ADFモデル・テスターを使用したBeanメタデータのテスト」を参照してください。

また、名前付き基準を理解していると役立ちます。詳細は、3.6項「名前付き基準を使用した結果セットのフィルタリング」を参照してください。

Oracle ADFモデル・テスターを使用して名前付き基準および非定型問合せ基準をテストする手順:

1. 「アプリケーション・ナビゲータ」で、目的のデータ・コントロールおよびセッションBeanが含まれているプロジェクトを展開します。

2. セッションBeanを右クリックして「実行」を選択し、組込みアプリケーション・サーバーにデプロイされるのを待ちます。

3. DataControls.dcxファイルを右クリックして「実行」を選択し、Oracle ADFモデル・テスターを起動します。

4. Oracle ADFモデル・テスターで、フィルタリングするアクセッサ戻りコレクションをダブルクリックします。

5. 「ビュー基準の指定」ツールバー・ボタンをクリックして名前付き基準をテストします。

6. 「ビュー基準」ダイアログで、次のいずれかのタスクを実行します。

- プロジェクトのデータ・コントロール構造ファイルに追加した名前付き基準をテストするには、その基準を「選択済」リストに移動して「検索」をクリックします。非定型基準セクションに入力した追加の基準は、フィルタに追加されます。

- 単一の名前付き基準行から非定型基準属性をテストするには、名前付き基準に必要な値を入力し、「検索」をクリックします。
たとえば、図3-7は、信用格付けがPOORであるすべての顧客を返すフィルタを示しています。

図3-7 Oracle ADFモデル・テスターの「ビュー基準」ダイアログ

3.8 Groovy言語サポート

Groovyは、Javaプラットフォーム用のスクリプト言語で、Javaと同様の構文を持ちます。Groovyスクリプト言語では、ドット区切り表記法の採用により、コードの作成が簡素化されていますが、コレクション、文字列およびJavaBeansを操作する構文は引き続きサポートされています。Groovy言語式は実行時に動的にコンパイルされ、実行されます。ADFアプリケーションについて作成したGroovy式は、定義されたBeanのデータ・コントロール構造ファイルに保存されます。

Oracle ADFでは、データ・コントロール・オブジェクトへのアクセスが有用な場合のGroovyスクリプト言語の使用をサポートしています。これには、属性バリデータ、属性のデフォルト値、一時属性値の計算、バインド変数のデフォルト値(名前付き基準のフィルタリングにおける)、およびエラー・メッセージのプレースホルダ(検証ルールにおける)が含まれます。さらに、Oracle ADFには、Groovy式で使用できる組込みキーワードの限定されたセットが用意されています。

特に、Oracle ADFでは、次のタスクの実行でGroovy言語式の使用をサポートしています。

- Script Expression Validator (3.5.4.2項「true/false式を使用した検証」を参照)またはCompare Validator (3.5.3.1項「比較に基づいた検証」を参照)の定義。

- 検証エラーを処理するエラー・メッセージ・トークンの定義(3.5.5.4項「エラー・メッセージへのGroovy式の埋込み」を参照)。

- バリデータの条件付き実行の処理(3.5.5.3項「Groovyを使用した条件付きでのエラー・メッセージの呼出し」を参照)。

- エンティティBean属性のデフォルト値およびオプションの再計算条件の定義(3.3.3項「Groovy式を使用したデフォルト値の定義方法」を参照)。

- Beanのデータ・コントロール構造ファイルにおける一時属性の値の判別(3.4項「Beanへの一時属性の追加」を参照)。

これらのタスクをJDeveloperで実行する場合、タスク固有の式エディタ・ダイアログを使用します。たとえば、一時属性のデフォルト値を作成する場合、属性の「式エディタの編集」ダイアログを使用して、属性の実行時の値を決定する式を入力します。また、同じダイアログで値をいつ計算するかも指定できます(再計算条件と呼ばれます)。式はデザインタイム時に検証できませんが、すべての式エディタで、式の構文を保存する前にテストできます。

Groovy言語の詳細は、次のWebサイトを参照してください。

- http://groovy.codehaus.org/

3.8.1 Groovy式でのADFオブジェクトの参照方法

フレームワークでGroovyスクリプトを使用できるオブジェクトにアクセス可能な、adfという名前のトップレベルのオブジェクトが用意されています。アクセス可能なOracle ADFオブジェクトの構成は次のとおりです。

- adf.context: ADFContextオブジェクトを参照します。

- adf.object.dataProvider: 式が適用されるBeanオブジェクトを参照します。アクセス可能な他のメンバー名は、Groovyスクリプトが適用されたコンテキストに由来します。

- エンティティBean属性およびメソッド: コンテキストはBeanのデータ・コントロール構造ファイルです。このオブジェクトを介して、データ・コントロール構造ファイルで定義されているすべての属性、およびBeanクラスから継承されたすべての属性およびメソッドを参照できます。

- スクリプト検証ルール: コンテキストは、バリデータが適用されるエンティティBeanにマージされるバリデータ・オブジェクト(JboValidatorContext)です。このコンテキストで使用できるキーワードの詳細は、3.8.2項「Groovy式でのADFメソッドおよび属性の参照方法」を参照してください。

- adf.error: 検証規則において、検証式で例外または警告を生成できるエラー・ハンドラにアクセスします。

次の式を使用して現在の日付(時間切捨て)または現在の日付と時間を参照できます。

- adf.currentDate

- adf.currentDateTime

データの行では、次の組込みの集計関数を使用できます。

- rowSetAttr.sum(GroovyExpr)

- rowSetAttr.count(GroovyExpr)

- rowSetAttr.avg(GroovyExpr)

- rowSetAttr.min(GroovyExpr)

- rowSetAttr.max(GroovyExpr)

これらの集計関数は、文字列値引数を使用し、これはGroovy式として解釈され、集計が計算される際に行セットの各行のコンテキストで評価されます。Groovy式は数値(または数字のドメイン)を返す必要があります。

3.8.2 Groovy式でのADFメソッドおよび属性の参照方法

データ・コントロールのメンバー(BeanおよびBeanのデータ・コントロール構造ファイルが定義するメソッドおよび属性を含む)を参照する最も単純な例は、式を適用する属性と同じBeanに存在する属性の参照です。

たとえば、従業員の月給を指定する属性Salを持つBeanの一時属性AnnualSalaryの値を計算するGroovy式を定義できます。

Sal * 12

または、次のような構文を使用して単一のデータ・コントロール構造ファイルの属性を比較する単純な検証ルールをGroovyで作成できます。

PromotionDate > HireDate

Javaを使用すると、同じ比較は次のようになります。

((Date)getAttribute("PromotionDate")).compareTo((Date)getAttribute("HireDate")) > 0

現在のオブジェクトは、thisオブジェクトとしてスクリプトに渡されるため、属性名を使用するだけで現在のオブジェクトの属性を参照できます。たとえば、属性レベルまたはエンティティ・レベルのScript Expression Validatorで、HireDateという名前の属性を参照するには、スクリプトでHireDateを参照するだけですみます。

属性の参照と同様に、式の一部としてメソッドを起動できます。たとえば、次のように、属性のデフォルト値を定義します。

adf.object.dataProvider.getDefaultSalaryForGrade()

メソッド参照は接頭辞adf.object.dataProviderを必要とします。これによって式が適用される属性を定義する同じエンティティを参照できます。

検証ルールでエンティティBeanのメソッドを参照する場合は、objectのかわりにsourceを使用します。

adf.source.dataProvider.getDefaultSalaryForGrade()

objectキーワードは、メソッドが定義されているエンティティBeanではなく、検証ルール・オブジェクトを指すため、バリデータではsource接頭辞を使用する必要があります。

バリデータ・オブジェクトのメンバーを参照できるようにするために(JboValidatorContext)、検証ルール式で次のキーワードを使用できます。

- newValue: 属性レベルのバリデータで、設定されている属性値にアクセスします。

- oldValue: 属性レベルのバリデータで、設定されている現在の属性値にアクセスします。

たとえば、次の式を使用して、販売員の給与の動的検証ルール・チェックを指定できます。

if (Job == "SALESMAN")
{
return newValue < adf.source.dataProvider.getMaxSalaryForGrade(Job)
}
else
return true

4 データバインドされた基本的なページの作成

この章では、「データ・コントロール」パネルでADF Facesコンポーネントを使用してデータバインドされたフォームを作成する方法について説明します。テキスト・フィールドを個々の属性から作成する方法、アクセッサによって返されるコレクションからフォーム全体を生成する方法、および既存レコードを編集したり新規レコードを作成するためのフォームを作成する方法についても説明します。

この章には、次の項が含まれます:

- 4.1項「データバインドされた基本的なページの作成について」

- 4.2項「属性を使用したテキスト・フィールドの作成方法」

- 4.3項「基本的なフォームの作成」

- 4.4項「レンジ・ナビゲーションのフォームへの組入れ」

- 4.5項「パラメータをとるメソッドを使用するフォームの作成」

- 4.6項「既存レコードを編集するフォームの作成」

- 4.7項「入力フォームの作成」

- 4.8項「フォーム上のUIコンポーネントおよびバインディングの変更」

4.1 データバインドされた基本的なページの作成について

ビジネス・サービス用に作成されたデータ・コントロールを使用して情報の表示および収集を実行するための、UIページを作成できます。たとえば、「データ・コントロール」パネルを使用して、項目の属性をドラッグし、読取り専用テキストまたはラベル付き入力テキスト・フィールドとして、値を表示できます。関連データの表示および更新に必要なすべてのJSFタグとバインディング・コードがJDeveloperによって作成されます。「データ・コントロール」パネルおよび宣言的なバインディング機能の詳細は、第2章「Java EE WebアプリケーションでのADFモデル・データ・バインディングの使用」を参照してください。

JDeveloperでは、属性を個別にドロップするのではなく、オブジェクトのすべての属性をフォームとして一度にドロップできます。フォームを構成する実際のUIコンポーネントは、ドロップしたフォームのタイプによって異なります。値を表示するフォーム、ユーザーが値を編集できるフォームおよび値を収集するフォーム(入力フォーム)を作成できます。

たとえば、Summitデモ・アプリケーションは、図4-1に示すような、ユーザーが注文に関する情報を表示および編集できるページが含まれています。このフォームは、「データ・コントロール」パネルからSOrdListアクセッサ・コレクションをドラッグ・アンド・ドロップして作成されました。(SOrdListノードはcustomerFindAllノード内にネストされています。)

図4-1 Summitデモ・アプリケーションの注文編集フォーム

UIコンポーネントを作成すると、コレクション内のレコード間を移動できるようにしたり、ユーザーがデータを操作できるようにする組込み操作をコマンドUIコンポーネントとしてドロップできます。たとえば、フォームに表示されたデータ・オブジェクトをユーザーが削除できるようにするためのボタンを作成できます。また、必要に応じてデフォルトのコンポーネントを変更することもできます。

4.2 属性を使用したテキスト・フィールドの作成方法

JDeveloperでは、テキスト・フィールドを宣言的に作成可能な、JSFページ用の完全なWYSIWYG開発環境が用意されているため、ページのほとんどの内容をコードを見ずに設計できます。「データ・コントロール」パネルから項目をドラッグ・アンド・ドロップすると、属性バインディングを使用してADF FacesテキストUIコンポーネントがデータ・コントロールの属性に宣言的にバインドされます。

4.2.1 テキスト・フィールドの作成方法

属性を表示または更新できるテキスト・フィールドを作成するには、「データ・コントロール」パネルからコレクションの属性をドラッグ・アンド・ドロップします。

始める前に:

データ・コントロールを使用したテキスト・フィールドの作成に関する一般的な知識があると役立ちます。詳細は、4.2項「属性を使用したテキスト・フィールドの作成方法」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

バインドされたテキスト・フィールドの作成手順:

1. 「データ・コントロール」パネルから、コレクションの属性を選択します。属性およびその他のオブジェクトを表す「データ・コントロール」パネルのアイコンの説明は、表2-1を参照してください。
たとえば、図4-2は、Summitデモ・アプリケーションのOrdersSessionEJBLocalデータ・コントロールのcustomerFindAllアクセッサ・コレクション下のaddress属性を示しています。この属性は、住所の最初の部分を表示または入力する場合にドロップします。

図4-2 コレクションに関連付けられた属性の「データ・コントロール」パネルでの表示

2. ページに属性をドラッグし、ポップアップ・メニューから、属性値を表示または収集するウィジェットのタイプを選択します。各属性について、次の選択肢があります。

- テキスト:

- ラベル付ADF入力テキスト: ネストされたvalidatorコンポーネントを伴うADF Faces inputTextコンポーネントが作成されます。label属性に値が移入されます。

ヒント:

inputTextコンポーネントのバリデータおよびその他の属性の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「入力コンポーネントの使用とフォームの定義」を参照してください。

- ADF入力テキスト: ネストされたvalidatorコンポーネントを伴うADF Faces inputTextコンポーネントが作成されます。label属性は移入されません。

- ラベル付ADF出力テキスト: ADF Faces outputTextコンポーネントを保持するpanelLabelAndMessageコンポーネントを作成します。panelLabelAndMessageコンポーネントのlabel属性が移入されます。

- ADF出力テキスト: ADF Faces outputTextコンポーネントを作成します。ラベルは作成されません。

- ラベル付ADF出力フォーマット済: 「ラベル付ADF出力テキスト」と同様ですが、outputTextコンポーネントのかわりにoutputFormattedコンポーネントを使用します。outputFormattedコンポーネントでは、制限された分量のHTML書式設定を追加できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド 』の出力テキストおよびフォーマット済の出力テキストの表示に関する項を参照してください。

- ADF出力フォーマット済: 「ラベル付ADF出力フォーマット済」と同様ですが、ラベルはありません。

- ADFラベル: ADF Faces outputLabelコンポーネント。

- 単一選択: 単一選択リストを作成します。JSFページでのリストの作成の詳細は、第7章「データバインドされた選択リストの作成」を参照してください。

この章の目的に合せて、ここではテキスト・コンポーネントのみ(リストは除く)について説明します。

4.2.2 テキスト・フィールドの作成時の処理

JSFページに属性をドラッグしてUIコンポーネントとしてドロップすると、そのページのページ定義ファイル(すでに存在する場合を除く)などが作成されます。属性をページにドラッグした場合の詳細な説明は、第2.3.2項「「データ・コントロール」パネルを使用したUIコンポーネントの作成時の処理」を参照してください。イテレータと属性のバインディングが作成されてページ定義ファイルに追加されます。また、UIコンポーネントに必要なJSPXページのコードがJSFページに追加されます。

4.2.2.1 イテレータ・バインディングの作成および使用

「データ・コントロール」パネルからコレクションの一部である項目をドロップして(またはコレクション全体をフォームまたは表としてドロップして)ページ上にUIコンポーネントを作成するたびに、イテレータ・バインディングが自動的に作成されます(すでに存在する場合を除く)。イテレータ・バインディングは、データ・コレクションのイテレータを参照し、この機能によりそのデータ・オブジェクトを反復処理します。また、コレクション内のデータ・オブジェクトの現在行および状態を管理します。イテレータ・バインディングは実際にはデータにアクセスしません。かわりに、データにアクセスできるオブジェクトを単純に公開し、コレクション内の現在のデータ・オブジェクトを指定します。その後、現在のオブジェクトのデータを戻したり、オブジェクトのデータに対してアクションを実行するために、他のバインディングがこのイテレータ・バインディングを参照します。イテレータ・バインディングはイテレータではないことに注意してください。これはイテレータへのバインディングです。

たとえば、customerFindAllコレクションからaddress属性をドロップすると、JDeveloperによって、OrdersSessionEJBLocalデータ・コントロールに対するイテレータ・バインディングとcustomerFindAllコレクションに対するaccessorIteratorバインディングが作成され、OrdersSessionEJBLocalイテレータがマスター・バインディングになります。

ヒント:

アクセッサから返されるコレクションごとにアクセッサ・イテレータ・バインディングが1つ作成されます。つまり、同じアクセッサから2つの属性を個別にドロップした場合(もしくは同じ属性を2回ドロップした場合)は、同じバインディングが使用されます。コンポーネントごとに動作の異なるバインディングが必要な場合を除き、同じバインディングが使用されても問題はありません。その場合は、別個のイテレータ・バインディングを手動で作成する必要があります。

イテレータ・バインディングのrangeSize属性は、イテレータ・バインディングへのアクセスが行われるたびにデータ・コントロールからフェッチされるデータ行数を決定します。この属性により、行セット全体の中でいくつかの絶対開始位置に対して1-n行の相対セットが置かれます。デフォルトでは、属性は25に設定されています。

例4-1に、customerFindAllアクセッサ・コレクションから属性をドロップすると作成されるイテレータ・バインディングを示します。

例4-1 イテレータ・アクセッサ・バインディングのページ定義コード

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="customerFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Customer" id="customerFindAllIterator"/>
</executables>

このメタデータにより、ADFバインディング・コンテナは属性値にアクセスできます。イテレータ・バインディングは実行可能ファイルで、デフォルトではページのロード時に起動されるため、これによってイテレータがcustomerFindAllアクセッサによって返されるコレクションにアクセスし、反復処理を実行できます。つまり、イテレータによって、コレクション内のすべてのオブジェクトの管理(コレクション内の現在の行の決定や住所オブジェクトのレンジの決定など)が行われるということです。

4.2.2.2 値バインディングの作成および使用

「データ・コントロール」パネルから属性をドロップすると、UIコンポーネントを属性の値にバインドするための属性バインディングが作成されます。このタイプのバインディングは、コレクション内の現在行のシングル・オブジェクトに対する属性の値を提示します。値バインディングは、属性値の表示と収集の両方に使用できます。

たとえば、customerFindAllアクセッサの下にあるaddress属性を「ラベル付ADF出力テキスト」ウィジェットとしてページにドロップすると、JDeveloperによって、address属性の属性バインディングが作成されます。これにより、バインディングが現在のレコードの属性値にアクセスできるようになります。例4-2は、customerFindAllアクセッサから属性をドロップした場合に作成されるaddressの属性バインディングを示しています。この属性値は、customerFindAllIteratorという名前のイテレータを参照します。

例4-2 属性バインディングのページ定義コード

<bindings>
<attributeValues IterBinding="customerFindAllIterator" id="address">
<AttrNames>
<Item Value="address"/>
</AttrNames>
</attributeValues
</bindings>

属性バインディング要素のプロパティの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のOracle ADFバインディング・プロパティに関する付録を参照してください。

4.2.2.3 EL式を使用したUIコンポーネントのバインド

「データ・コントロール」パネルから属性をドロップしてテキスト・フィールドを作成すると、対応するタグがJSFページに記述され、ドロップしたウィジェットに関連付けられているUIコンポーネントが作成されます。

たとえば、address属性を「ラベル付出力テキスト」ウィジェットとしてドロップすると、JDeveloperによってpanelLabelAndMessageコンポーネントとoutputTextコンポーネントのタグが挿入されます。また、panelLabelAndMessageコンポーネントのlabel属性を、addressのバインディングのために作成されたヒントのlabelプロパティにバインドするEL式が作成されます。この式は、Beanのデータ・コントロールで設定されているラベルのUIヒントとして評価されます。また、現在の行のaddress属性の値に評価される、outputTextコンポーネントのvalue属性をaddressバインディングのinputValueプロパティにバインドする、別の式が作成されます。両方のコンポーネントに対してIDも自動的に生成されます。

ヒント:

JDeveloperでは、すべてのADF FacesコンポーネントのIDが自動的に生成されます。これらの値を必要に応じてオーバーライドできます。

例4-3に、address属性を「ラベル付出力テキスト」ウィジェットとしてドロップしたときにJSFページで生成されるコードを示します。

例4-3 「ラベル付き出力テキスト」としてドロップされた属性のJSFページ・コード

<af:panelLabelAndMessage label="#{bindings.address.hints.label}"
id="plam1">
<af:outputText value="#{bindings.address.inputValue}" id="ot1"/>
</af:panelLabelAndMessage>

かわりにaddress属性を「ラベル付入力テキスト」ウィジェットとしてドロップすると、JDeveloperによってinputTextコンポーネントが作成されます。例4-4に示すように、出力テキスト・コンポーネントと同様、値はaddressバインディングのinputValueプロパティにバインドされます。また、次のプロパティも設定されます。

- label: 属性のlabel UIヒントにバインドされます。

- required: mandatoryプロパティにバインドされ、これは属性のisNotNullプロパティを参照します(これはBeanのデータ・コントロール構造ファイルの概要エディタで属性の「詳細」セクションの「必須」オプションとして表されます)。

- columns: 属性のdisplayWidth UIヒントにバインドされます。テキスト・ボックスの幅を決定します。

- maximumLength: 属性の「精度」オプションにバインドされます。このプロパティは、フィールドに入力できる1行当たりの最大文字数を決定します。

- shortDesc: ツールチップのUIヒントにバインドされます。

さらに、JDeveloperはバリデータ・コンポーネントを追加します。

例4-4 「ラベル付入力テキスト」としてドロップされた属性のJSFページ・コード

<af:inputText value="#{bindings.address.inputValue}"
label="#{bindings.address.hints.label}"
required="#{bindings.address.hints.mandatory}"
columns="#{bindings.address.hints.displayWidth}"
maximumLength="#{bindings.address.hints.precision}">
shortDesc="#{bindings.address.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.address.validator}"/>
</af:inputText>

これらの値は必要に応じて変更できます。たとえば、データ・コントロールの属性のisNotNullプロパティはデフォルトではfalseに設定されています。つまり、コンポーネントのrequired属性もfalseと評価されるということです。コンポーネントのrequired属性をtrueに設定すると、この値を上書きできます。属性のすべてのインスタンスを必須にする場合、データ・コントロール構造ファイル内の「必須」オプションを変更することにより、すべてのインスタンスが必須となります。データ・コントロールの属性の編集方法の詳細は、3.3項「属性の使用」を参照してください。

4.3 基本的なフォームの作成

コレクションの各属性を個別にドロップしてフォームを作成するかわりに、オブジェクトのすべての属性のデータを表示または収集する、完全なフォームを作成できます。たとえば、Summitデモ・アプリケーションで、EditOrder.jspxページのフォームは、「データ・コントロール」パネルからordFindAllアクセッサ・コレクションをドロップして作成されています。

また、コレクションからデータを表示するだけでなく、多くの機能を提供するフォームの作成もできます。ユーザーがデータを更新できるフォームの作成に関する詳細は、4.6項「既存レコードを編集するフォームの作成」を参照してください。ユーザーがコレクションの新規オブジェクトを作成できるフォームの作成に関する詳細は、4.7項「入力フォームの作成」を参照してください。検索フォームを作成することもできます。詳細は、第8章「データバインドされた検索フォームの作成」を参照してください。

4.3.1 フォームの作成方法

データ・コントロールを使用してフォームを作成するには、UIコンポーネントをデータ・コントロールの対応するオブジェクトの属性にバインドします。JDeveloperでは、返されるコレクションを「データ・コントロール」パネルからドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

始める前に:

データ・コントロールからのフォームの作成に関する一般的な知識があると役立ちます。詳細は、4.3項「基本的なフォームの作成」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

基本的なフォームの作成手順:

1. 「データ・コントロール」パネルから、表示するデータを返すコレクションを選択します。図4-3は、アクセッサによって返されるコレクションordFindAllを示しています。

図4-3 「データ・コントロール」パネルでのproductFindAllアクセッサ

2. ページにコレクションをドラッグし、ポップアップ・メニューから、オブジェクトのデータの表示または収集に使用するフォームのタイプを選択します。選択できるフォームのタイプは次のとおりです。

- ADFフォーム: 「フォーム・フィールドの編集」ダイアログが起動し、デフォルトですべての属性に対して1つのフィールドが作成されるのではなく、属性を個別に選択できます。また、各属性に使用するラベルおよびUIコンポーネントを選択できます。デフォルトでは、ADF inputTextコンポーネントはほとんどの属性で使用されます。inputTextコンポーネントごとにlabel属性が移入されます。
日付である属性ではInputDateコンポーネントが使用されます。さらに、属性にUIヒントが作成されている場合、または属性がリストとして構成されている場合、ヒントにより設定されたコンポーネントが使用されます。InputTextコンポーネントには、属性の検証を設定するためのバリデータ・タグが含まれます。属性が数値または日付の場合、コンバータも含まれます。

ヒント:

inputTextコンポーネントのバリデータ、コンバータおよびその他の属性の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「入力コンポーネントの使用とフォームの定義」を参照してください。

- ADF読取り専用フォーム: 「ADFフォーム」と同じですが、読取り専用outputTextコンポーネントが使用されます。このフォームはデータの表示を目的としているため、validatorタグは追加されません(コンバータは含まれます)。タイプDateの属性は、読取り専用フォームではoutputTextコンポーネントを使用します。すべてのコンポーネントはpanelLabelAndMessageコンポーネント内に置かれます。このコンポーネントには、label属性が移入されます。 panelLabelAndMessageコンポーネントは、panelFormLayoutコンポーネント内に配置されます。

3. 「フォーム・フィールドの編集」ダイアログで、フォームを構成します。
フォーム・フィールドを追加、削除および並替えできます。

ユーザーがコレクション内のすべてのデータ・オブジェクトに移動できるように、ナビゲーション・コントロールを含めることもできます。詳細は、4.4項「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。 また、フォームの送信に使用する「送信」ボタンを含めることもできます。このボタンにより、HTMLフォームを送信し、JSF/ADFページ・ライフサイクルの一環としてフォームのデータをバンディングに適用します。このダイアログの使用方法に関する追加のヘルプを表示するには、「ヘルプ」をクリックします。すべてのUIコンポーネントは、panelFormLayoutコンポーネントの中に配置されます。

4. ユーザーによるデータの更新が可能なフォームを作成する場合は、ここで、更新を実行するメソッドをドラッグ・アンド・ドロップする必要があります。詳細は、4.6項「既存レコードを編集するフォームの作成」を参照してください。

4.3.2 フォームの作成時の処理

「データ・コントロール」パネルからオブジェクトをフォームとしてドロップすることは、単一の属性をドロップするのと同じ効果があります。ただし、複数の属性バインディングおよび関連するUIコンポーネントが作成される点が異なります。UIコンポーネントの属性(valueなど)は、その属性のバインディング・オブジェクト(inputValueなど)のプロパティ、または対応するサービスで設定されるコントロール・ヒントの値にバインドされます。例4-5に、SOrdListアクセッサ・コレクションをデフォルトADFフォームとしてドロップして注文の編集フォームを作成した場合にJSFページで生成されるコードの一部を示します。

注意:

関連付けられているデータ・コントロール構造ファイルで属性が非表示としてマークされている場合、対応するUIは作成されません。

例4-5 入力フォームのJSFページでのコード

<af:panelFormLayout id="pfl1">
<af:inputText value="#{bindings.id.inputValue}"
label="#{bindings.id.hints.label}"
required="#{bindings.id.hints.mandatory}"
columns="#{bindings.id.hints.displayWidth}"
maximumLength="#{bindings.id.hints.precision}"
shortDesc="#{bindings.id.hints.tooltip}" id="it1">
<f:validator binding="#{bindings.id.validator}"/>
</af:inputText>
<af:inputDate value="#{bindings.dateOrdered.inputValue}"
label="#{bindings.dateOrdered.hints.label}"
required="#{bindings.dateOrdered.hints.mandatory}"
columns="#{bindings.dateOrdered.hints.displayWidth}"
shortDesc="#{bindings.dateOrdered.hints.tooltip}" id="id1">
<f:validator binding="#{bindings.dateOrdered.validator}"/>
<af:convertDateTime pattern="#{bindings.dateOrdered.format}"/>
</af:inputDate>
<af:inputDate value="#{bindings.dateShipped.inputValue}"
label="#{bindings.dateShipped.hints.label}"
required="#{bindings.dateShipped.hints.mandatory}"
columns="#{bindings.dateShipped.hints.displayWidth}"
shortDesc="#{bindings.dateShipped.hints.tooltip}" id="id2">
<f:validator binding="#{bindings.dateShipped.validator}"/>
<af:convertDateTime pattern="#{bindings.dateShipped.format}"/>
</af:inputDate>
<af:selectBooleanCheckbox value="#{bindings.orderFilled.inputValue}"
label="#{bindings.orderFilled.label}"
shortDesc="#{bindings.orderFilled.hints.tooltip}"
id="sbc1"/>
<af:selectOneChoice value="#{bindings.paymentType.inputValue}"
label="#{bindings.paymentType.label}"
required="#{bindings.paymentType.hints.mandatory}"
shortDesc="#{bindings.paymentType.hints.tooltip}"
id="soc2">
<f:selectItems value="#{bindings.paymentType.items}" id="si2"/>
</af:selectOneChoice>
. . .
</af:panelFormLayout>

注意:

バリデータ・タグとコンバータ・タグの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「入力の検証および変換」を参照してください。

4.4 レンジ・ナビゲーションのフォームへの組入れ

ADFフォームを作成する際、ナビゲーション・コントロールの組込みを選択すると、データ・コントロールの既存のナビゲーション・ロジックにバインドされているADF Facesコマンド・コンポーネントが組み込まれます。この組込みロジックによって、ユーザーは、コレクション内のすべてのデータ・オブジェクトを移動できるようになります。たとえば、図4-4は、ordFindAllアクセッサをドラッグし、ナビゲーションを使用するADFフォームとしてドロップした場合に作成されるフォームを示しています。

図4-4 フォーム内のナビゲーション

4.4.1 フォームへのナビゲーション・コントロールの挿入方法

デフォルトでは、「データ・コントロール」パネルを使用してフォームを作成する際にナビゲーションの組込みを選択すると、「先頭へ」、「最後へ」、「前へ」および「次へ」の各ボタンが作成され、ユーザーがコレクション内を移動できるようになります。

また、既存のフォームにナビゲーション・ボタンを手動で追加できます。

始める前に:

ナビゲーション・コントロールの一般的な知識があると役立ちます。詳細は、4.4項「レンジ・ナビゲーションのフォームへの組入れ」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

ナビゲーション・ボタンを手動で追加する場合の手順:

1. 操作の実行対象となるオブジェクトのコレクションに関連付けられる操作を「データ・コントロール」パネルから選択し、JSFページ上にドラッグします。
たとえば、注文のコレクション内を移動できるようにする場合は、OrdFindAllアクセッサに関連付ける「次へ」操作をドラッグします。図4-5に、OrdFindAllアクセッサに関連付けられている操作を示します。

図4-5 コレクションに関連付けられている操作

2. 次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

ヒント:

「先頭へ」、「最後へ」、「前へ」および「次へ」のすべてのボタンを一度にドロップすることもできます。これを行うには、対応するコレクションをドラッグし、ポップアップ・メニューから「移動」→「ADFナビゲーション・ボタン」を選択します。

4.4.2 コマンド・ボタンの作成時の処理

任意の操作をコマンド・コンポーネントとしてドロップすると、JDeveloperによって次の処理が行われます。

- 関連付けられている操作について、ページ定義ファイルでアクション・バインディングが定義されます。

- コレクションに部分ページ・レンダリングを使用するように、イテレータ・バインディングが構成されます。

- コマンド・コンポーネント用のコードがJSFページに挿入されます。

4.4.2.1 組込みナビゲーション操作のアクション・バインディング

アクション・バインディングは、ビジネス・ロジックを実行します。たとえば、アクション・バインディング・オブジェクト上で組込みメソッドを起動できます。このような組込みメソッドは、イテレータやデータ・コントロール自体に対して作用し、「データ・コントロール」パネルに操作として表示されます。JDeveloperには、ユーザーによるコレクション内の前後のオブジェクトへの移動や最初または最後のオブジェクトへの移動を可能にするナビゲーション操作が用意されています。

アクション・バインディングがNextまたはPreviousなどのイテレータレベル・アクションにバインドされている場合、操作のアクション・バインディングには、値バインディングと同様にイテレータ・バインディングへの参照が含まれます。これらのタイプのアクションはイテレータによって実行されます。イテレータは現在のオブジェクトを判別するため、ナビゲーション・ボタンがクリックされたときに表示するオブジェクトが正しく判別されます。

アクション・バインディングはRequiresUpdateModelプロパティを使用して、アクションを実行する前にモデルを更新する必要があるかどうかを判別します。ナビゲーション操作の場合、デフォルトではこのプロパティはtrueに設定されています。つまり、ビュー・レイヤーでのすべての変更は、ナビゲーションを実行する前にモデルに移動する必要があります。例4-6に、ナビゲーション操作のアクション・バインディングを示します。

例4-6 操作アクション・バインディングのページ定義コード

<action IterBinding="ordFindAllIterator" id="First"
RequiresUpdateModel="true" Action="first"/>
<action IterBinding="ordFindAllIterator" id="Previous"
RequiresUpdateModel="true" Action="previous"/>
<action IterBinding="ordFindAllIterator" id="Next"
RequiresUpdateModel="true" Action="next"/>
<action IterBinding="ordFindAllIterator" id="Last"
RequiresUpdateModel="true" Action="last"/>

4.4.2.2 イテレータのRangeSize属性

イテレータ・バインディングにはrangeSize属性が含まれ、バインディングではこの属性を使用して、反復ごとにページで使用できるようにするデータ・オブジェクト数が決定されます。この属性は、データソース内のオブジェクト数がきわめて多い場合に役立ちます。イテレータ・バインディングは、すべてのオブジェクトではなく、1つのセット番号のみを戻すため、他のバインディングでアクセスできるようになります。イテレータはレンジの最後に到達すると、次のセットにアクセスします。例4-7に、ordFindAllイテレータのデフォルトのレンジ・サイズを示します。

例4-7 イテレータのRangeSize属性

<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="ordFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal" BeanClass="model.Ord"
id="ordFindAllIterator" ChangeEventPolicy="ppr"/>

注意:

このrangeSize属性は、表コンポーネントのrows属性とは異なります。

デフォルトでは、rangeSize属性は25に設定されています。つまり、ユーザーは、25個のオブジェクトを表示でき、データソースにアクセスしなくても、このオブジェクト間を前後に移動できるということです。イテレータは、現在のオブジェクトを追跡します。ユーザーが新しいレンジを要求するボタンをクリックすると(たとえば、オブジェクト番号25で「次へ」ボタンをクリックすると)、関連付けられているメソッドがバインディング・オブジェクトによってイテレータに対して実行され、イテレータは別の25個のレコードのセットを取得します。その後、そのセットがバインディングによって使用されます。この設定は、必要に応じて変更できます。完全なレコード・セットを戻すには、-1に設定します。

注意:

「データ・コントロール」パネルを使用してナビゲーション可能なフォームを作成する場合、関連するイテレータのCacheResultsプロパティはtrueに設定されます。これにより、現在行情報などのイテレータの状態はリクエスト間でキャッシュされ、現在のオブジェクトを判別できるようになります。このプロパティがfalseに設定されている場合、ナビゲーションは機能しません。

表4-1に、データ・コントロールで提供される組込みナビゲーション操作と、操作の起動または操作にバインドされたイベントの実行の結果を示します。

表4-1 組込みナビゲーション操作

操作

関連付けられているイテレータ・バインディングによる起動時の処理

先頭

現在のポインタを結果セットの先頭に移動します。

最後

現在のポインタを結果セットの最後に移動します。

前

現在のポインタを結果セットの前のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが戻るようにスクロールされます。

次

現在のポインタを結果セットの次のオブジェクトに移動します。このオブジェクトが現在のレンジの外にある場合は、レンジ・サイズと同じオブジェクト数だけレンジが進むようにスクロールされます。

前のセット

レンジ・サイズ属性と同じオブジェクト数だけ、レンジを戻すように移動します。

次のセット

レンジ・サイズ属性と同じオブジェクト数だけ、レンジを進めるように移動します。

4.4.2.3 EL式を使用したナビゲーション操作へのバインド

ナビゲーション操作を使用してコマンド・コンポーネントを作成すると、コマンド・コンポーネントはpanelGroupLayoutコンポーネント内に配置されます。JDeveloperにより、ナビゲーション・コマンド・ボタンのactionListener属性を、指定された操作のアクション・バインディングのexecuteプロパティにバインドするEL式が作成されます。

実行時、アクション・バインディングは、コアのJUCtrlActionBinding実装クラスを拡張するFacesCtrlActionBindingクラスのインスタンスです。FacesCtrlActionBindingクラスにより、次のメソッドが追加されます。

- public void execute(ActionEvent event): actionListenerプロパティで参照されるメソッドです(例: #{bindings.First.execute})。
ユーザーがボタンをクリックすると、この式によって、イテレータに対してバインディングの操作が起動されます。たとえば、「先頭へ」コマンド・ボタンのactionListener属性は、Firstアクション・バインディングのexecuteメソッドにバインドされています。

- public String outcome(): Actionプロパティで参照できます(例: #{bindings.Next.outcome})。
移動先となる次のページを決定するJSFナビゲーションの結果として、メソッド・アクション・バインディングの結果(Stringに変換後)に使用できます。

注意:

アクション・バインディングでoutcomeメソッドを使用すると、ビューおよびコントローラのレイヤーとモデルが過度に緊密に結ばれるため、ほとんど使用されません。

操作の各アクション・バインディングには、enabledブール型プロパティが含まれます。このプロパティは、操作を起動しない場合には、Oracle ADFによってfalseに設定されます。デフォルトでは、JDeveloperがこの値にUIコンポーネントのdisabled属性をバインドして、コンポーネントを有効化するかどうかを指定します。たとえば、「先頭へ」ボタンのUIコンポーネントのdisabled属性の値は、次のとおりです。

#{!bindings.First.enabled}

この式は、バインディングが有効でない場合、常にtrueに評価されます。つまり、操作を起動しない場合に、ボタンが無効になります。この例では、最初のレコードが表示されている場合はいつでも、フレームワークがバインディングのenabledプロパティをfalseに設定するため、「先頭へ」ボタンが自動的に無効になります。これは、enabledがFalseの場合は、常にdisabled属性がtrueに設定されるためです。enabledプロパティの詳細は、Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドのOracle ADFバインディング・プロパティに関する付録を参照してください。

例4-8に、ナビゲーション操作ボタンに対してJSFページで生成されたコードを示します。ボタンのpartialSubmit属性の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の部分ページ・レンダリングの宣言的な有効化に関する項を参照してください。

例4-8 ADF操作にバインドされているナビゲーション・ボタンのJSFコード

<f:facet name="footer">
<af:panelGroupLayout>
<af:commandButton actionListener="#{bindings.First.execute}"
text="First"
disabled="#{!bindings.First.enabled}"
partialSubmit="true" id="cb1"/>
<af:commandButton actionListener="#{bindings.Previous.execute}"
text="Previous"
disabled="#{!bindings.Previous.enabled}"
partialSubmit="true" id="cb2"/>
<af:commandButton actionListener="#{bindings.Next.execute}"
text="Next"
disabled="#{!bindings.Next.enabled}"
partialSubmit="true" id="cb3"/>
<af:commandButton actionListener="#{bindings.Last.execute}"
text="Last"
disabled="#{!bindings.Last.enabled}"
partialSubmit="true" id="cb4"/>
</af:panelGroupLayoutr>
</f:facet>

4.5 パラメータをとるメソッドを使用するフォームの作成

コンテンツを表示する前に、ページで情報を必要とする場合があります。このタイプのページの場合、パラメータをとるメソッドから返されるコレクションを使用してフォームを作成します。メソッドを実行するには、要求元のページがパラメータの値を指定する必要があります。

4.5.1 パラメータをとるメソッドを使用するフォームまたは表の作成方法

パラメータを必要とするフォームを作成する場合、返すレコードを決定するために、パラメータの値にアクセスできる必要があります。それらの値にアクセスするには、あるオブジェクトにパラメータ値を設定し、その後メソッドがそのオブジェクトにアクセスできるようなロジックを、別のページのコマンド・ボタンに追加します。

始める前に:

パラメータ・フォームの一般的な知識があると役立ちます。詳細は、4.5項「パラメータをとるメソッドを使用するフォームの作成」を参照してください。

次のタスクを完了する必要があります。

- 2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

- セッションBeanに、フォームでの表示に必要な項目を返すメソッドを作成するか指定します。たとえば、OrderSessionEJBBean.javaクラスにはmergeOrd(Ord)メソッドが含まれています。

ヒント:

データ・コントロールを生成した後にセッションBeanにサービス・メソッドを追加した場合、パネルに新しいメソッドを表示するために「データ・コントロール」パネルをリフレッシュする必要があります。パネルをリフレッシュするには、「リフレッシュ」アイコンをクリックします。

パラメータを使用するフォームまたは表を作成する手順:

1. 「データ・コントロール」パネルから、パラメータをとるメソッドの戻りであるコレクションをドラッグし、任意のタイプのフォームとしてドロップします。
たとえば、注文の編集のためのボタンをクリックすると表示されるフォームを作成するには、図4-6に示すように、Ord戻りをドラッグ・アンド・ドロップします。

図4-6 パラメータをとるカスタム・メソッドの戻り

2. 「フォーム・フィールドの編集」ダイアログで、必要に応じてフォームを構成し、「OK」をクリックします。
このダイアログの使用に関するヘルプを表示するには、「ヘルプ」をクリックします。

メソッドがパラメータをとるため、「アクション・バインディングの編集」ダイアログが開き、パラメータの値を設定するよう求められます。

3. アクション・バインディング・エディタで「値」フィールドの参照(「...」)アイコンをクリックし、EL式ビルダーを開いて各パラメータの値を入力します。パラメータの値を表すノードを選択します。
このエディタでは、この値を使用して、メソッドが実行される際のパラメータを表すNamedData要素が作成されます。メソッドの戻りであるコレクションをドロップしているため、このメソッドは(コマンド・ボタンにバインドされているメソッドとは異なり)、関連付けられているイテレータがページのロード時に実行される際に実行されます。パラメータ値は、ページがレンダリングされる前に設定される必要があります。つまり、NamedData要素は、送信元ページの設定に関係なく、この値を取得する必要があるということです。

ヒント:

同じページからの入力に基づいて表示されるフォームを作成する場合、「ADFパラメータ・フォーム」を使用してアクション・バインディングを作成できます。まず、「データ・コントロール」パネルからメソッドをドラッグし、「ADFパラメータ・フォーム」としてドロップします。次にメソッド戻りをドラッグし、任意のタイプのフォームとしてドロップします。

4.5.2 パラメータをとるメソッドを使用するフォームの作成時の処理

パラメータをとるメソッドの戻りを使用してフォームを作成すると、JDeveloperによって次の処理が行われます。

- メソッドに対するアクション・バインディング、メソッドの結果に対するメソッド・イテレータ・バインディング、オブジェクトの各属性に対する属性バインディング、表の場合は表バインディングが作成されます。メソッドが必要とする各パラメータのNamedData要素の作成も行われます。

- ADF Facesコンポーネントを使用するフォームのコードがJSFページに挿入されます。

例4-9では、mergeOrd(Ord)メソッドのOrd戻りをドロップした際に作成されるアクション・メソッド・バインディングを示しています。ここで、パラメータの値はSOrdListIteratorの現在の行のデータ・プロバイダに設定されています。

例4-9 メソッド戻りのメソッド・アクション・バインディング

<bindings>
<methodAction id="mergeOrd" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="mergeOrd"
IsViewObjectMethod="false" DataControl="OrdersSessionEJBLocal"
InstanceName="Sdata.OrdersSessionEJBLocal.dataProvider
ReturnName="data.OrdersSessionEJBLocal.methodResults.mergeOrd_
OrdersSessionEJBLocal_dataProvider_mergeOrd_result">
<NamedData NDName="productId"
NDValue="#{bindings.SOrdListIterator.currentRow.dataProvider}"
NDType="model.Ord"/>
</methodAction>
...
</bindings>

4.5.3 実行時に行われる処理: メソッドのパラメータの設定

ユーザーがコマンド・ボタンをクリックすると実行されるメソッドとは異なり、フォームの作成に使用されるメソッドは、ページのロード時に実行されます。ページのデータを返すためにメソッドが実行される際、メソッドでNamedData要素のEL式が評価され、その値がパラメータとして使用されます。このようにして正しいデータを返すことができます。メソッドが複数のパラメータをとる場合、各パラメータが順に評価され、メソッドにパラメータが設定されます。

たとえば、EditOrderページのロード時、SOrdListIteratorのcurrentRow.dataProviderパラメータの値が取得され、mergeOrd(Ord)メソッドで必要なパラメータの値として設定されます。メソッドが実行されると、パラメータの値に一致するレコードのみが返されます。メソッドの戻りをドロップしてフォームを作成したため、その戻りが表示される製品です。

4.5.4 メソッドによるパラメータの設定について

1つのページでのアクションに対して、アプリケーション機能を判別するためのパラメータを設定する必要が生じる場合があります。たとえば、あるページに、パラメータ値がfalseの場合にのみコンポーネントが表示される別のページに移動するコマンド・ボタンを作成できます。

ページ間でこのパラメータを渡す場合やパラメータ値のチェックに使用するメソッドを含める場合には、マネージドBeanを使用できます。コマンド・ボタン内にネストしている、typeプロパティがactionに設定されているsetPropertyListenerコンポーネントを使用して、パラメータを設定します。メソッドを使用したパラメータの設定の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のコマンド・コンポーネントを使用したパラメータ値の設定に関する項を参照してください。

注意:

タスク・フローを使用している場合、タスク・フローのパラメータ渡しメカニズムを使用できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「タスク・フローのパラメータの使用」を参照してください。

4.5.5 パラメータのかわりのコンテキスト・イベントの使用について

ページまたはページ内のリージョンで、ページの別の場所または別のリージョンの情報を必要する場合があります(リージョンの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フローのリージョンとしての使用に関する項を参照してください)。情報を取得するためにパラメータを渡すことは可能ですが、それはパラメータが既知であり、EL式でページにアクセスできる入力である場合のみ意味を持ちます。また、パラメータ値が変化した場合にタスク・フローを再起動する必要があるときに、パラメータは便利です。

ただし、複数のページ・フラグメントを持つタスク・フローがあり、ページ・フラグメントには、フロー内のあるページへの入力として使用できる様々な興味深い値が含まれているとします。パラメータを使用して値を渡す場合、タスク・フローはすべてのフラグメントの興味深い各値を結合するための出力パラメータを公開する必要があります。そのかわり、必要な情報を含む各フラグメントに対し、ページを送信すると発生するコンテキスト・イベントを定義できます。情報を必要とするページまたはフラグメントは、様々なイベントをサブスクライブし、イベントを介して情報を取得できます。

コンテキスト・イベントは、ページ定義ファイルを使用して作成および構成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のコンテキスト・イベントの使用に関する項を参照してください。

4.6 既存レコードを編集するフォームの作成

ユーザーが現在のデータを編集し、その変更をデータ・ソースにコミットするためのフォームを作成できます。これを行うには、コレクションに関連付けられたデータ・レコードを変更できるメソッドを使用して、コマンド・ボタンを作成します。たとえば、デフォルトのmergeOrd(Ord)メソッドを使用して、ユーザーが注文を更新できるボタンを作成できます。

ページがバインドされたタスク・フローの一部でない場合、変更をコレクションにマージするには、コレクションに関連付けられたマージ・メソッドまたは永続化メソッドを使用する必要があります。この2つの違いの詳細は、第4.6.3項「マージ・メソッドと永続化メソッドとの違いについて」を参照してください。ページが、バインド・タスク・フロー内のトランザクションの一部である場合、commit操作とrollback操作を使用して、タスク・フロー・リターン・アクティビティのトランザクションを解決します。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フロー・リターン・アクティビティの使用に関する項を参照してください。

4.6.1 編集フォームの作成方法

フォームでメソッドを使用するには、操作と同じ手順を実行します。

始める前に:

編集可能なフォームの一般的な知識があると役立ちます。詳細は、4.6項「既存レコードを編集するフォームの作成」を参照してください。

次のタスクを完了する必要があります。

- 2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

- セッションBeanに、フォームでの表示に必要な項目を返すメソッドを作成するか指定します。たとえば、OrderSessionEJBBean.javaクラスにはmergeOrd(Ord)メソッドが含まれています。

編集フォームの作成方法:

1. 「データ・コントロール」パネルから、フォームを作成するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。
これにより、inputTextコンポーネントを使用し、フィールドのデータを編集可能なフォームが作成されます。

2. 操作の実行対象となるオブジェクトのコレクションに関連付けられるマージ・メソッドを「データ・コントロール」パネルから選択し、JSFページ上にドラッグします。
たとえば、注文のレコードを更新できるようにし、そのインスタンスを再度使用しない場合、mergeOrd(Ord)メソッドをドラッグします。

3. 次に表示されるポップアップ・メニューから「ADFボタン」または「ADFリンク」を選択します。

4. 「アクション・バインディングの編集」ダイアログで、メソッドのパラメータに値を移入する必要があります。マージ・メソッド(およびその他のデフォルト・メソッド)の場合、これが更新されるオブジェクトです。

1. 「パラメータ」セクションで、「値」ドロップダウン・リストを使用して「EL式ビルダーの表示」を選択します。

2. 式ビルダーで、アクセッサのイテレータのノードを展開して「currentRow」ノードを展開し、「dataProvider」を選択します。
これによって、アクセッサのイテレータで現在の行の値と評価されるEL式が作成されます。

3. 「OK」をクリックします。

たとえば、ordFindAllアクセッサ・コレクションを使用してフォームを作成した場合、JDeveloperによってordFindAllIteratorという名前のaccessorIteratorバインディングが作成されます。図4-7に示すように、そのイテレータの下の現在の行のdataProviderを選択する必要があります。この参照は、パラメータ値が、現在フォームに表示されている行の値に解決されることを表します。

5. 「アクション・バインディングの編集」ダイアログ・ボックスで、「OK」をクリックします。

図4-7 ordFindAllIteratorバインディングの現在の行のdataProvider

注意:

ページが、バインド・タスク・フロー内のトランザクションの一部の場合、マージ・メソッド(または他のデフォルト・メソッド)からボタンを作成するかわりに、タスク・フロー・リターン・アクティビティの作成時に、トランザクション解決の値としてそのメソッドを設定します。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フロー・リターン・アクティビティの使用に関する項を参照してください。

4.6.2 値を変更するメソッドの使用時の処理

メソッドをコマンド・ボタンとしてドロップすると、JDeveloperによって次の処理が行われます。

- メソッドのメソッド・バインディングが定義されます。メソッドがパラメータを取得する場合は、パラメータ値を保持するNamedData要素が作成されます。NamedData要素の詳細は、4.5.3項「実行時に行われる処理: メソッドのパラメータの設定」を参照してください。

- ADF Facesコマンド・コンポーネント用のコードがJSFページに挿入されます。このコードは、他のあらゆるコマンド・ボタンのコードと類似しています。ただし、ボタンは、操作用のアクション・バインディングのexecuteメソッドではなく、ドロップしたメソッド用のアクション・バインディングのexecuteメソッドにバインドされます。

4.6.2.1 メソッド・バインディング

メソッドからボタンを作成する場合、組込み操作からボタンを作成する場合と同様に、JDeveloperによってメソッドに対する アクション・バインディングが作成されます。例4-10に、mergeOrd(Ord)メソッドをドロップした場合に作成されるアクション・バインディングを示します。

例4-10 イテレータによって使用されるアクション・バインディングのページ定義コード

<bindings>
<methodAction id="mergeOrd" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="mergeOrd"
IsViewObjectMethod="false" DataControl="OrdersSessionEJBLocal"
InstanceName="OrdersSessionEJBLocal.dataProvider"
ReturnName="OrdersSessionEJBLocal.methodResults.mergeOrd_
OrdersSessionEJBLocal_dataProvider_persistOrd_result">
<NamedData NDName="ord"
NDValue="#{bindings.ordFindAllIterator.currentRow.dataProvider}"
NDType="model.Ord/>
</methodAction>
</bindings>

この例では、アクション・プロパティ値がinvokeMethodであるため、バインディングがアクセスされると、メソッドが起動されます。

パラメータをとるメソッドをJSFページにドロップすると、JDeveloperによって各パラメータに対してNamedData要素も作成されます。これらの要素は、メソッドのパラメータを表します。たとえば、mergeOrd(Ord)メソッドのアクション・バインディングには、Ordパラメータに対するNamedData要素が含まれます。

4.6.2.2 EL式を使用したメソッドへのバインド

ナビゲーション操作を使用してコマンド・ボタンを作成するときと同様に、メソッドを使用してコマンド・ボタンを作成すると、JDeveloperによってactionListener属性を使用して、ボタンがメソッドにバインドされます。ボタンは、指定されたメソッドのアクション・バインディングのexecuteプロパティにバインドされます。このバインディングによって、バインディングのメソッドがビジネス・サービスで起動されます。actionListener属性の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の実行時に行われる処理とアクション・イベントおよびアクション・リスナーの動作方法に関する項を参照してください。

ヒント:

アクション・バインディングのexecuteメソッドにボタンをバインドするかわりに、executeメソッドを上書きするバッキングBean内のメソッドにボタンをバインドできます。そうすることで、元のメソッドの実行前か実行後に、ロジックを追加できるようになります。詳細は、4.6.4項「宣言メソッドの上書きについて」を参照してください。

ナビゲーション操作のように、ボタンのdisabledプロパティは、EL式を使用してボタンを表示するかどうかを決定します。例4-11に、コマンド・ボタンのmergeOrd(Ord)メソッドへのバインドに使用されるEL式を示します。

例4-11 コマンド・ボタンをメソッドにバインドするためのJSFコード

<af:commandButton actionListener="#{bindings.merge.Ord.execute}"
text="mergeOrd"
disabled="#{!bindings.mergeOrd.enabled}"
id="cb1"/>

ヒント:

UIコンポーネントをページにドロップすると、それより前にドロップされた同じタイプのコンポーネントの数に基づいて、JDeveloperによってIDが自動的に付けられます(cb1、cb2など)。このIDは、説明的なものに変更できます。特に、ページの複数のUIコンポーネントに対するメソッドを含むバッキングBeanで参照する必要がある場合は、変更した方が適しています。

4.6.3 マージ・メソッドと永続化メソッドとの違いについて

セッションBeanを作成する際に、構造化オブジェクトのマージ・メソッドと永続化メソッドを公開するよう選択した場合、それらのメソッドが「データ・コントロール」パネルに表示され、ユーザーがオブジェクトの現在のインスタンスをマージしたり、永続化できるボタンの作成に使用できます。どちらを使用するかは、更新が行われた後でページとインスタンスとの対話が必要かどうかで決まります。インスタンスを使用し続ける必要がある場合、永続化メソッドを使用します。

マージ・メソッドは、JPA EntityManager.mergeメソッドの実装です。このメソッドは、現在のインスタンスを取得してコピーし、そのコピーをPersistenceContextに渡します。その後、元のオブジェクトではなく、その永続化されたエンティティへの参照が返されます。つまり、それ以降そのインスタンスに行われる変更は、マージ・メソッドを再度コールしないかぎり永続化されないということです。

永続化メソッドは、JPA EntityManager.persistメソッドの実装です。マージ・メソッド同様、このメソッドは、現在のインスタンスをPersistenceContextに渡します。ただし、コンテキストによってそのインスタンスの管理が続けられるため、以降の更新はコンテキスト内のインスタンスに行われます。

4.6.4 宣言メソッドの上書きについて

操作またはメソッドをコマンド・ボタンとしてドロップすると、JDeveloperによって操作またはメソッドのexecuteメソッドにそのボタンがバインドされます。ただし、既存のロジックの前または後に、ロジックの追加が必要になる場合もあります。JDeveloperを使用すると、バインディング・コンテナにアクセスするマネージドBeanにメソッドおよびプロパティを新規作成することにより、宣言的操作にロジックを追加できます。デフォルトでは、この生成されたコードによって、操作またはメソッドが実行されます。その後、このコードの前か後にロジックを追加できます。元の操作またはメソッドのexecuteプロパティではなく、この新規メソッドにコマンド・コンポーネントが自動的にバインドされます。その後、ユーザーがボタンをクリックすると、新規メソッドが実行されます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の宣言メソッドの上書きに関する項を参照してください。

4.7 入力フォームの作成

ユーザーが新規レコードの情報を入力し、そのレコードをデータソースにコミットするためのフォームを作成できます。入力フォームを含むページが表示される前に、Create操作をコールするメソッド・アクティビティを含むタスク・フローを使用する必要があります。このメソッド・アクティビティによって空白行が行セットに挿入されます。その後、ユーザーはフォームを使用して空白行にデータを移入できます。

ヒント:

タスク・フローの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADFタスク・フローの作成に関するパートを参照してください。

たとえば、Address Beanがある場合、ユーザーによる住所の作成が可能な新規フォームを作成できます。createAddressメソッド・アクティビティを含むcreate-address-task-flowタスク・フローを作成します。このメソッド・アクティビティは、AddressFindAllアクセッサに対してCreate操作をコールします。その後、制御がcreateAddressビュー・アクティビティに渡され、図4-8に示すような、ユーザーが新しい住所を入力できるフォームが表示されます。

図4-8 住所の作成

注意:

アプリケーションでタスク・フローを使用しない場合は、タスク・フローのメソッド・アクティビティと同様の方法で、コール元のページでcreate操作を起動する必要があります。たとえば、コール元のページ上のコマンド・ボタンに関連付けられたイベント・ハンドラ内にアプリケーション・ロジックを指定できます。

4.7.1 タスク・フローを使用した入力フォームの作成方法

バインド・タスク・フロー内に入力フォームを作成し、適切なトランザクションの処理が行われるようにします。

始める前に:

入力フォームの一般的な知識があると役立ちます。詳細は、4.7項「入力フォームの作成」を参照してください。

次のタスクを完了する必要があります。

- 2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

- フォームとCreate操作を実行するメソッド・アクティビティの両方を含むバインド・タスク・フローを作成します。タスク・フローによって新規トランザクションが開始される必要があります。手順は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フローの作成に関する項を参照してください。

入力フォームの作成手順:

1. バインド・タスク・フローにメソッド・アクティビティを追加します。このアクティビティに、フォームを作成するアクセッサに関連付けられているCreate操作を実行させます。メソッド・アクティビティを使用する手順は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のメソッド・コール・アクティビティの使用に関する項を参照してください。
たとえば、ユーザーによる住所の作成が可能なフォームを作成する場合、メソッド・アクティビティに、AddressFindAllアクセッサに関連付けられているCreate操作を実行させます。

2. プロパティ・インスペクタで、fixed-outcomeプロパティに文字列を入力します。たとえば、fixed-outcome値としてcreateと入力します。

3. 入力フォームのページを表すビュー・アクティビティを追加します。ビュー・アクティビティ追加の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のビュー・アクティビティの使用に関する項を参照してください。

4. 制御フロー・ケースをメソッド・アクティビティからビュー・アクティビティに追加します。プロパティ・インスペクタで、手順2で設定したメソッド・アクティビティのfixed-outcomeプロパティの値を、制御フロー・ケースのfrom-outcomeの値として入力します。

5. 設計エディタでビュー・アクティビティのページを開き、「データ・コントロール」パネルから、新しいレコードの作成にフォームを使用するコレクションをドラッグし、ポップアップ・メニューから「ADFフォーム」を選択します。
たとえば、住所を作成するフォームの場合、「データ・コントロール」パネルから、AddressFindAllアクセッサ・コレクションをドラッグします。

ヒント:

データベースにコミットする前に、ユーザーが複数のエントリを作成できるようにする場合、次のようにします。

1. タスク・フローで、ビュー・アクティビティからメソッド・アクティビティに戻る別の制御フロー・ケースを追加し、from-outcomeメソッドの値を入力します。たとえば、createAnotherと入力します。

2. コンポーネント・パレットからコマンド・コンポーネントをページにドラッグ・アンド・ドロップし、action属性を、先ほど作成したfrom-outcomeに設定します。これによって、タスク・フローはメソッド・アクティビティに戻り、Create操作を再起動します。

6. タスク・フローに、リターン・アクティビティを追加します。このリターン・アクティビティでは、データ・コントロールに対してcommit操作を実行する必要があります。この手順は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フロー・リターン・アクティビティの使用に関する項を参照してください。

ヒント:

commit操作を実行するリターン・アクティビティを設定し、アクティビティでエラーが表示される場合、トランザクションを開始するようタスク・フロー自体が設定されていないことが原因である可能性があります。そのように設定する必要があります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のタスク・フローのトランザクションの管理に関する項を参照してください。

7. 制御フロー・ケースをビュー・アクティビティからリターン・アクティビティに追加します。fixed-outcome属性をテキスト文字列に設定します。たとえば、returnに設定します。

8. コンポーネント・パレットから、リターン・アクティビティの起動に使用されるボタンまたは他のコマンド・コンポーネントをドラッグ・アンド・ドロップします。action属性を、手順4で作成したfixed-outcomeに設定されているテキスト文字列に設定します。

4.7.2 タスク・フローを使用した入力フォームの作成時の処理

ADFフォームを使用して入力フォームを作成すると、JDeveloperによって次の処理が行われます。

- メソッド・アクティビティのページ定義に、アクセッサのイテレータ・バインディングおよびCreate操作のアクション・バインディングが作成されます。Create操作は、行を行セットに作成し、データソースに入力されたデータを移入します。その他のフォームに関しては、ページのページ定義に、返されるコレクションのイテレータ・バインディングと、コレクション内のオブジェクトの各属性に対する属性バインディングが作成されます。

- ADF Faces inputTextコンポーネント、および操作の場合はcommandButtonコンポーネントを使用して、JSFページにフォームのコードが挿入されます。

たとえば、図4-8に示すフォームは、メイン・ページの「Create Address」リンクをクリックすると表示されます。このリンクによって、新規住所のデータを入力できるフォームに移動します。住所を作成したら、「Save」ボタンをクリックすると、メイン・ページに戻ります。図4-9に、newAddressメソッド・アクティビティを含むcreate-address-task-flowタスク・フローを示します。

図4-9 入力フォーム用のタスク・フロー

例4-12に、メソッド・アクティビティのページ定義ファイルのコードを示します。

例4-12 Creationメソッド・アクティビティのページ定義コード

<executables>
<iterator Binds="root" RangeSize="25" DataControl="SupplierFacadeLocal"
id="SupplierFacadeLocalIterator"/>
<accessorIterator MasterBinding="SupplierFacadeLocalIterator"
Binds="addresses" RangeSize="25"
DataControl="SupplierFacadeLocal"
BeanClass="oracle.fodemo.supplier.model.Addresses"
id="addressesIterator"/>
</executables>
<bindings>
<action IterBinding="addressesIterator" id="Create"
RequiresUpdateModel="true" Action="createRow"/>
</bindings>

4.7.3 実行時に行われる処理: メソッド・アクティビティからのCreateアクション・バインディングの起動

前述の例では、newAddressメソッド・アクティビティにアクセスすると、Createアクション・バインディングが起動され、createRow操作が実行されてコレクション用に空白の新規インスタンスが作成されます。メソッド・アクティビティからビュー・アクティビティへのルーティング中、メソッド・アクティビティのバインディング・コンテナは必須属性の検証をスキップするため、空白のインスタンスがページ上のフォームに表示できます。

4.8 フォーム上のUIコンポーネントおよびバインディングの変更

「データ・コントロール」パネルを使用してフォームを作成すると、属性の削除、表示順序の変更、データの表示に使用するコンポーネントの変更、およびコンポーネントのバインド先の属性の変更を実行できます。

既存のUIコンポーネントとバインディングの変更の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のフォーム上のUIコンポーネントおよびバインディングの変更に関する項を参照してください。

5 ADFによるデータバインドされた表の作成

この章では、「データ・コントロール」パネルを使用して、編集可能な表や入力表など、ADF Facesコンポーネントに基づいてデータバインドされた基本的な表を作成する方法について説明します。

この章には、次の項が含まれます:

- 5.1項「表の追加について」

- 5.2項「基本表の作成」

- 5.3項「編集可能な表の作成」

- 5.4項「入力表の作成」

- 5.5項「表に表示される属性の変更」

5.1 表の追加について

フォームと異なり、表を使用すると、アクセッサによって返されたコレクションのレコードを一度に複数表示できます。図5-1に、Summitデモ・アプリケーションのCustomerFindAllコレクションをドラッグし、表示用に4つの列を選択して作成された表を示します。

図5-1 検索基準に合う製品を表示する結果表

単にデータを表示する表を作成することも、データの編集または作成が可能な表を作成することもできます。アクセッサを表としてドロップすると、選択した行に対してなんらかのロジックを実行するアクションにバインドされたコマンド・ボタンを追加できます。また、必要に応じてデフォルトのコンポーネントを変更することもできます。

5.2 基本表の作成

フォームを構成する個々のUIコンポーネントをコレクション上の個々の属性にバインドするフォームとは異なり、表では、ADF Facesのtableコンポーネントをコレクション全体にバインドするか、コレクションから一度にnデータ・オブジェクトのレンジにバインドします。その結果、列にデータを表示するために使用される個々のコンポーネントが属性にバインドされます。イテレータ・バインディングによって各オブジェクトの適切なデータが表示され、tableコンポーネントによって各オブジェクトが1行で表示されます。JDeveloperを使用すると、宣言的にこの処理を行うことができるため、コードを記述する必要がありません。

5.2.1 基本表の作成方法

データ・コントロールを使用して表を作成するには、返されるコレクションにtableコンポーネントをバインドします。JDeveloperでは、「データ・コントロール」パネルからコレクションをドラッグ・アンド・ドロップして、宣言的にこの処理を実行できます。

ヒント:

コンポーネント・パレットから表コンポーネントをドラッグし、ADF Faces Tableの作成ウィザードを完了して表を作成することもできます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のページでの表の表示方法に関する項を参照してください。

始める前に:

データ・コントロールを使用した表の作成に関する一般的な知識があると役立ちます。詳細は、5.2項「基本的な表の作成」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

データバインドされた表を作成する手順:

1. 「データ・コントロール」パネルから、コレクションを選択します。
たとえば、システム内の注文を表示する簡単な表をSummitデモ・アプリケーションで作成するには、ordFindAllアクセッサ・コレクションを選択します。

2. コレクションをJSFページにドラッグし、ポップアップ・メニューから適切な表を選択します。
コレクションをドラッグするときは、次のタイプの表から選択できます。

- ADF表: 編集可能な表の列の表示に必要な特定の属性と、データの表示に使用するUIコンポーネントを選択できます。デフォルトでは、ADF inputTextコンポーネントはほとんどの属性で使用され、このコンポーネントにより、表は編集可能となります。日付である属性ではinputDateコンポーネントが使用されます。さらに、属性にUIヒントが作成されている場合、または属性がリストとして構成されている場合、ヒントにより設定されたコンポーネントが使用されます。UIヒントの設定の詳細は、3.3.5項「属性へのUIヒントの設定方法」を参照してください。

- ADF読取り専用表: 「ADF表」と同じですが、各属性は、outputTextコンポーネントに表示されます。

- ADF読取り専用動的表: 返されて表示される属性が実行時に動的に決定される表を作成できます。このコンポーネントは、対応するオブジェクトの属性が実行時まで不明な場合、あるいはJSFページに列名をハードコーディングしない場合に適しています。

3. 次に表示される「表の列の編集」ダイアログには、コレクション内の各属性が表示されます。また、これらの属性がどのように動作し、表の列としてどのように表示されるかを定義できます。

注意:

コレクションに構造化属性(Javaのプリミティブ・タイプまたはコレクションのいずれでもない属性)が含まれる場合、その構造化属性の属性も同様にダイアログに表示されます。

ダイアログを使用すると、次の操作ができます。

- 「行選択」パネルで、ADFモデル・レイヤーによる選択の処理方法を指定します。「単一」ラジオ・ボタンを選択すると、ユーザーは1つの行を選択し、イテレータ・バインディングがイテレータにアクセスして選択した行を決定します。「複数」ラジオ・ボタンを選択すると、ユーザーは複数の行を選択でき、イテレータ・バインディングがイテレータにアクセスして選択した行を決定します。表での選択を実行しない場合は、「なし」を選択します。

- 「ソート」チェック・ボックスの選択による、ADFモデル・レイヤーでの列のソート処理。このオプションを選択すると、イテレータ・バインディングがイテレータにアクセスし、order-by問合せを実行して順序を決定します。列のソートを実行しない場合以外は、このオプションを選択してください。

- 「フィルタリング」チェック・ボックスの選択による、入力した基準を使用した、表の列のフィルタリングの実行。このオプションを選択すると、各列の上にあるテキスト・フィールドに基準を入力できます。その後で、この基準を使用してコレクションへのQuery-by-Example(QBE)検索を作成すると、問合せによって戻された結果のみが表に表示されます。詳細は、8.5項「スタンドアロンのフィルタ処理された検索表の作成」を参照してください。

- 目的の属性(ダイアログでは行として表示)の選択および「グループ化」ボタンのクリックによる、親列下での選択した属性の列のグループ化。図5-2に、表の作成後、グループ化された2つの列がビジュアル・エディタでどのように表示されるかを示します。

図5-2 ADF Faces表のグループ化された列

- テキストまたはEL式を入力して、ラベルの値を他のもの(リソース・ファイルのキーなど)にバインドすることによる、列の表示ラベルの変更。デフォルトでは、ラベルは表バインディング上の属性に定義されたすべてのUIヒントのlabelプロパティにバインドされます。このバインディングにより、データ・コントロール構造ファイルのラベル・テキストの値を1回のみ変更でき、また、その変更はラベルを表示するすべてのページに反映されます。

- バインド対象に別の属性を選択することによる、列の値バインディングの変更。単に列を並べ替える場合は、順序ボタンを使用してください。列の属性バインディングを変更すると、列のラベルも変更されます。

- ドロップダウン・メニューを使用した、属性の表示に使用されるUIコンポーネントの変更。UIコンポーネントは、コレクションをページにドロップしたときに選択した表と、対応する属性のタイプ(たとえば、日付である属性にはinputDateコンポーネントを使用)、およびBeanのデータ・コントロール構造ファイルでデフォルト・コンポーネントがUIヒントとして設定されているかどうかに基づいて設定されます。

ヒント:

表の属性の1つが主キーでもある場合、ユーザーが値を変更できないUIコンポーネントを選択します。

ヒント:

ドロップダウン・メニューに表示されないコンポーネントを使用する場合は、このダイアログを使用してoutputTextコンポーネントを選択した後、手動で他のタグをページに追加します。

- 順序ボタンを使用した列の順序の変更。

- 「追加」アイコンを使用した列の追加。追加できる列の数に制限はありません。最初にアイコンをクリックすると、JDeveloperではダイアログの下部に新規列の行が追加され、そこにバインドされたコレクションの最初の属性の値が移入されます。後続の新規列には順序内の次の属性の値が移入され、その後も同様に続きます。

- 「削除」アイコンを使用した列の削除。

4. 表をページにドロップした後は、プロパティ・インスペクタを使用して表に他の表示プロパティを設定できます。たとえば、表の幅を特定のパーセンテージまたはサイズに設定します。表示プロパティの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「表とツリーの使用」を参照してください。

ヒント:

表の幅を100%に設定すると、表には境界が含まれないため、表の実際の幅はさらに大きくなります。コンテナの幅の100%に表を設定するには、プロパティ・インスペクタの「スタイル」セクションを展開し、「ボックス」タブを選択してBorder Width属性を0ピクセルに設定します。

5. ユーザーが表の情報を編集し、変更を保存できるようにするには、変更を発行して保存する方法を指定する必要があります。詳細は、5.3項「編集可能な表の作成」を参照してください。ユーザーによるデータ入力が可能な表の作成手順は、5.4項「入力表の作成」を参照してください。

5.2.2 表の作成時の処理

「データ・コントロール」パネルから表をドロップすると、テキスト・フィールドまたはフォームをドロップするのと同じ効果があります。要約すると、JDeveloperによって行われる処理は次のとおりです。

- 表のバインディングを作成し、ページ定義ファイルにそのバインディングを追加します。

- UIコンポーネントに必要なコードをJSFページに追加します。

詳細は、4.2.2項「テキスト・フィールドの作成時の処理」を参照してください。

5.2.2.1 表のイテレータと値バインディング

「データ・コントロール」パネルから表をドロップすると、ツリーの値バインディングが作成されます。ツリーはノードの階層で構成され、各サブノードは上位レベルのノードから分岐します。表の場合、フラット化された階層であり、各属性(列)は表のサブノードになります。フォームで使用される属性バインディングと同様に、ツリーの値バインディングによってアクセッサ・イテレータ・バインディングが参照される一方、アクセッサ・イテレータ・バインディングによってデータ・コントロールのイテレータが参照されます。これにより、コレクションのデータ・オブジェクト全体の反復が円滑に行われます。属性ごとに異なるバインディングが作成されるのではなく、表ノードへのツリー・バインディングのみが作成されます。ツリー・バインディングでは、表の各行で表示または参照に使用する各属性の子要素が、nodeDefinition要素のAttrNames要素に含まれています。

ツリーの値バインディングは、FacesCtrlHierBindingクラスのインスタンスです。このクラスは、コアのJUCtrlHierBindingクラスを拡張して、次の2つのJSF固有のプロパティを追加します。

- collectionModel: JSFおよびADF Facesで表などのコレクション値コンポーネントに使用するjavax.faces.model.DataModelオブジェクトを拡張するオブジェクトによってラップされたデータを戻します。

- treeModel: collectionModelを拡張し、実質的に階層構造であるデータを戻します。詳細は、第6章「マスター/ディテール・データの表示」を参照してください。

例5-1に、SOrdListアクセッサ・コレクションをドロップすると作成される表の値バインディングを示します。

例5-1 ページ定義ファイルにおける表の値バインディング・エントリ

<bindings>
<tree IterBinding="SOrdListIterator" id="SOrdList">
<nodeDefinition DefName="model.Ord" Name="SOrdList0">
<AttrNames>
<Item Value="id"/>
<Item Value="dateOrdered"/>
<Item Value="paymentTypeId"/>
<Item Value="salesRepId"/>
<Item Value="total"/>
<Item Value="orderFilled"/>
<Item Value="dateShipped"/>
</AttrNames>
</nodeDefinition>
</tree>
...
</bindings>

データにアクセスする必要があるのは表のみであるため、(列または個々のセル内のテキスト・コンポーネントではなく)モデルにバインドする必要があるのは表コンポーネントのみです。表のツリー・バインディングは表の個々の構造化属性にドリルダウンするので、表の列は表コンポーネントからその情報を導出できます。

5.2.2.2 ADF Faces表のJSFページのコード

「データ・コントロール」パネルを使用してJSFページに表をドロップすると、表バインディングで指定された各属性に対するADF Facesのcolumnコンポーネントが含まれたADF FacesのtableコンポーネントがJDeveloperによって挿入されます。各列には、属性の値にバインドされた別のコンポーネント(inputTextコンポーネントやoutputTextコンポーネントなど)が含まれます。各列のヘッダーは、属性のコントロール・ヒントのlabelsプロパティにバインドされます。

ヒント:

関連付けられている構造ファイルで属性が非表示としてマークされている場合、対応するUIは作成されません。

例5-2に、ordFindAllアクセッサ・コレクションを読取り専用表としてドロップして作成した表から抜粋したコードを示します。

例5-2 ADF Faces読取り専用表のJSFコード

<af:table value="#{bindings.ordFindAll.collectionModel}" var="row"
rows="#{bindings.ordFindAll.rangeSize}"
emptyText="#{bindings.ordFindAll.viewable ? 'No data to display.' :
'Access Denied.'}"
fetchSize="#{bindings.ordFindAll.rangeSize}" rowBandingInterval="0"
id="t1">
<af:column sortProperty="#{bindings.ordFindAll.hints.dateOrdered.name}"
sortable="false"
headerText="#{bindings.ordFindAll.hints.dateOrdered.label}"
id="c1">
<af:outputText value="#{row.dateOrdered}" id="ot1">
<af:convertDateTime
pattern="#{bindings.ordFindAll.hints.dateOrdered.format}"/>
</af:outputText>
</af:column>
<af:column sortProperty="#{bindings.ordFindAll.hints.dateShipped.name}"
sortable="false"
headerText="#{bindings.ordFindAll.hints.dateShipped.label}"
id="c2">
<af:outputText value="#{row.dateShipped}" id="ot2">
<af:convertDateTime
pattern="#{bindings.ordFindAll.hints.dateShipped.format}"/>
</af:outputText>
</af:column>
. . .
</af:table>

ツリー・バインディングは、イテレータ・バインディングによって公開されたデータ全体を反復します。表の値は、collectionModelオブジェクトにアクセスするcollectionModelプロパティにバインドされています。表は、イテレータ・バインディングからの結果セットをcollectionModelオブジェクト内にラップします。collectionModelにより、コレクションの各アイテムは、var属性を使用して表コンポーネント内で使用できるようになります。

例では、表は、ordFindAllアクセッサ・バインディングの現在レンジの行全体を反復します。バインディングは、現在の行を追跡する行セット・イテレータにバインドします。表のvar属性をrowに設定すると、次のaf:outputTextタグの値に示すように、各列はrow変数を使用して、表タグに示される現在行の現在データ・オブジェクトにアクセスします。

<af:outputText value="#{row.dateOrdered}"/>

行変数にバインドするかわりに、ADF表(ADF読取り専用表ではなく)をドロップすると、入力コンポーネントの値は、bindingsプロパティによってバインディング・コンテナ内の特定の行に暗黙的にバインドされます(例5-3を参照)。さらに、入力コンポーネントごとにバリデータ・コンポーネントとコンバータ・コンポーネントが追加されます。bindingsプロパティを使用すると、発生した例外を該当するバインド・オブジェクトにリンクできます。コントローラは、バインディング・コンテナ内のすべての例外を反復処理し、FacesMessageオブジェクトの作成時にクライアントIDを取得するためのバインディング・オブジェクトを取得します。この取得により、特定のセルのエラーを表に表示できるようになります。この方法は、リストなどの選択コンポーネントを含め、すべての入力コンポーネントに使用されます。

例5-3 入力コンポーネントを使用したバリデータとコンバータの追加

<af:table value="#{bindings.ordFindAll.collectionModel}" var="row"
rows="#{bindings.ordFindAll.rangeSize}"
emptyText="#{bindings.ordFindAll.viewable ? 'No data to display.' :
'Access Denied.'}"
fetchSize="#{bindings.ordFindAll.rangeSize}" rowBandingInterval="0"
id="t1">
<af:column sortProperty="#{bindings.ordFindAll.hints.dateOrdered.name}"
sortable="false"
headerText="#{bindings.ordFindAll.hints.dateOrdered.label}"
id="c1">
<af:inputDate value="#{row.bindings.dateOrdered.inputValue}"
label="#{bindings.ordFindAll.hints.dateOrdered.label}"
required="#{bindings.ordFindAll.hints.dateOrdered.mandatory}"
columns="#{bindings.ordFindAll.hints.dateOrdered.displayWidth}"
shortDesc="#{bindings.ordFindAll.hints.dateOrdered.tooltip}"
id="id1">
<f:validator binding="#{row.bindings.dateOrdered.validator}"/>
<af:convertDateTime
pattern="#{bindings.ordFindAll.hints.dateOrdered.format}"/>
</af:inputDate>
</af:column>
<af:column sortProperty="#{bindings.ordFindAll.hints.dateShipped.name}"
sortable="false"
headerText="#{bindings.ordFindAll.hints.dateShipped.label}"
id="c2">
<af:inputDate value="#{row.bindings.dateShipped.inputValue}"
label="#{bindings.ordFindAll.hints.dateShipped.label}"
required="#{bindings.ordFindAll.hints.dateShipped.mandatory}"
columns="#{bindings.ordFindAll.hints.dateShipped.displayWidth}"
shortDesc="#{bindings.ordFindAll.hints.dateShipped.tooltip}"
id="id2">
<f:validator binding="#{row.bindings.dateShipped.validator}"/>
<af:convertDateTime
pattern="#{bindings.ordFindAll.hints.dateShipped.format}"/>
</af:inputDate>
</af:column>
<af:column sortProperty="#{bindings.ordFindAll.hints.id.name}"
sortable="false"
headerText="#{bindings.ordFindAll.hints.id.label}" id="c3">
<af:inputText value="#{row.bindings.id.inputValue}"
label="#{bindings.ordFindAll.hints.id.label}"
required="#{bindings.ordFindAll.hints.id.mandatory}"
columns="#{bindings.ordFindAll.hints.id.displayWidth}"
maximumLength="#{bindings.ordFindAll.hints.id.precision}"
shortDesc="#{bindings.ordFindAll.hints.id.tooltip}"
id="it1">
<f:validator binding="#{row.bindings.id.validator}"/>
</af:inputText>
</af:column>
. . .
</af:table>

ADF Facesのバリデータとコンバータの使用方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「入力の検証および変換」を参照してください。

表5-1に、「データ・コントロール」パネルを使用して作成されたADF Faces表に対して、デフォルトで定義された他の属性を示します。

表5-1 ADF Faces表の属性と移入される値

属性

説明

デフォルト値

rows

一度に表示する行数を決定します。

デフォルトで、関連付けられたイテレータ・バインディングのrangeSizeプロパティに評価されるEL式。これにより、データ・コントロールから一度にフェッチされるデータの行数が決定されます。表は戻される行数以上を表示できないため、rows属性の値は、対応するイテレータのrangeSize値以下にする必要があります。rangeSizeプロパティの詳細は、4.4.2.2項「イテレータのRangeSize属性」を参照してください。

emptyText

戻す行がない場合に表示するテキスト。

イテレータの表示可能なプロパティに評価されるEL式。表が表示可能で、戻すオブジェクトがない場合、「表示するデータがありません」と表示されます。表が表示できない場合(表に対して認可の制限が設定されている場合など)は、「アクセスが拒否されました」と表示されます。

fetchSize

データソースからフェッチされるデータの行数。

デフォルトで、関連付けられたイテレータ・バインディングのrangeSizeプロパティに評価されるEL式。rangeSizeプロパティの詳細は、4.4.2.2項「イテレータのRangeSize属性」を参照してください。この属性は、rows属性より大きい数値に設定することができます。

selectedRowKeys

表の選択の状態。

デフォルトでコレクション・モデルの選択された行に評価されるEL式。

selectionListener

選択イベントをリスニングするメソッドへの参照。

デフォルトでコレクション・モデルのmakeCurrentメソッドに評価されるEL式。

rowSelection

行が選択可能かどうかを決定します。

一度に1行のみ選択するにはsingleに設定します。

列の属性

sortProperty

列のソート基準のプロパティを決定します。

列の対応する属性バインディング値に設定します。

sortable

ソートできる列かどうかを決定します。

falseに設定します。trueに設定すると、イテレータ・バインディングがイテレータにアクセスし、順序を決定します。

headerText

列の上部に表示されるテキストを決定します。

デフォルトで、対応する属性に設定されたラベルのlabel UIヒントに評価されるEL式。

5.2.3 表での現在行の設定について

アプリケーションで表を使用し、ADF Modelレイヤーで行選択を管理できるようにする場合、現在行はイテレータによって決定されます。ユーザーがADF Faces表で行を選択すると、表の行が影付きになり、選択された行がコンポーネントによりイテレータに通知されます。そのためには、例5-4に示すように、表のselectedRowKeys属性をコレクション・モデルの選択した行にバインドします。

例5-4 表のselection属性

<af:table value="#{bindings.ordFindAll.collectionModel}" var="row"
.
.
.
selectedRowKeys="#{bindings.ordFindAll.collectionModel.selectedRow}"
selectionListener="#{bindings.ordFindAll.collectionModel.makeCurrent}"
rowSelection="single" id="t1">

このバインディングは、表の選択したキーをコレクション・モデルの選択した行にバインドします。selectionListener属性は、コレクション・モデルのmakeCurrentプロパティにバインドされます。このバインディングは、コレクションの選択した行をイテレータの現在行に設定します。

注意:

カスタム選択リスナーを作成した場合、コレクション・モデルのmakeCurrentプロパティへのメソッド・バインディング(#{binding.Ord.collectionModel.makeCurrent}など)を作成し、任意のカスタム・ロジックの前にこのメソッド・バインディングをカスタム選択リスナーで起動する必要があります。

表は選択を自動的に処理できますが、オブジェクトの現在行をイテレータにプログラムで設定する必要がある場合があります。

getKey()メソッドをどのビュー行でコールしても、行を識別する1つ以上のキー属性をカプセル化するKeyオブジェクトを取得できます。Keyオブジェクトは、findByKey()による行セット内のビュー行の検索にも使用できます。実行時に、setCurrentRowWithKeyまたはsetCurrentRowWithKeyValueのいずれかの組込み操作がデータ・バインディング・レイヤーによって名前で起動されると、findByKey()メソッドを使用して、パラメータとして渡された値に基づいて行が検索された後、検索された行が現在の行として設定されます。

setCurrentRowWithKey操作およびsetCurrentRowWithKeyValue操作ではいずれもrowKeyという名前のパラメータをとりますが、実行時にそのrowKeyパラメータに想定される値はそれぞれで異なります。

setCurrentRowWithKey操作

setCurrentRowWithKeyでは、rowKeyパラメータ値に、ビュー行キーのシリアライズされた文字列表現が想定されています。これは、次の文字列のような16進の暗号化された文字列です。

000200000002C20200000002C102000000010000010A5AB7DAD9

キーのシリアライズされた文字列表現により、ブラウザのURL文字列またはフォーム・パラメータで単一値として渡すことができる方法で、ビュー行のキーを構成する可能性のあるすべてのキー属性がエンコードされます。実行時に、有効なシリアライズされた文字列キーではないパラメータ値を間違って渡すと、oracle.jbo.InvalidParamExceptionまたはjava.io.EOFExceptionなどの例外を結果として受け取る場合があります。Webページでは、ADFコントロール・バインディングのrowKeyStrプロパティ(#{bindings.SomeAttrName.rowKeyStr}など)またはADF Faces表の行変数(#{row.rowKeyStr}など)を参照すると、行のシリアライズされた文字列キーの値にアクセスできます。

setCurrentRowWithKeyValue

setCurrentRowWithKeyValue操作では、rowKeyパラメータ値がビュー行のキーを表すリテラル値であると想定しています。たとえば、注文番号201を検索する場合、この値は単に201になります。

5.3 編集可能な表の作成

ユーザーが表内の情報を編集し、その変更をデータソースにコミットできるようにする表を作成できます。そのためには、返されるコレクション(またはデータ・コントロール自体)に関連付けられたデータ・レコードを変更できる操作を使用して、コマンド・ボタンを作成し、このボタンを表のツールバーに配置します。たとえば、browse.jspxページの表には、ユーザーが製品を削除できるボタンがあります。このボタンによって、現在は、ユーザーが削除を確定できるダイアログが表示されますが、製品を直接削除するメソッドにボタンをバインドすることもできます。

ヒント:

データ・ストアに新規レコードを挿入できる表を作成するには、5.4項「入力表の作成」を参照してください。

編集可能なフォーム同様、ADFモデル・レイヤーでは、コレクションの新規インスタンスが生成されるまで、行の変更が認識されないことに注意してください。したがって、変更をコミットするには、アクセッサ・イテレータで実行操作を起動する必要があります。詳細は、2.3.4項「イテレータの結果のキャッシュについて」を参照してください。

編集可能なコンポーネントを使用してデータを表示することにした場合、表に一度にすべての行を変更可能として表示するか、ユーザーが行内をダブルクリックするまですべての行を読取り専用として表示するかを選択できます。図5-3は、すべての行に編集可能フィールドがある表を示しています。ページは、ページに追加されたコンポーネント(inputText、inputDate、inputNumberSpinboxコンポーネントなど)を使用してレンダリングされます。

図5-3 編集可能フィールドがある表

図5-4は、同じ表ですが、データを編集または入力するにはユーザーが行をダブルクリック(または行がすでに選択されている場合はシングルクリック)する必要があるように構成されています。図5-3と同じ入力コンポーネントを使用してページは作成されていますが、outputTextコンポーネントを使用して選択されていない行のデータが表示されることに注意してください。これらのコンポーネントを実際にレンダリングしている行は、編集のために選択された行のみです。

図5-4 クリック可能な行が選択された表

ADF Facesの表コンポーネントによる編集の処理方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表、ツリーおよびツリー表のデータの編集に関する項を参照してください。

5.3.1 編集可能な表の作成方法

編集可能な表を作成するには、基本表の作成に類似した手順に従い、続いて操作にバインドされたコマンド・ボタンを追加します。ただし、表にツールバーを含めるには、表の作成に使用されたコレクションのアイテムとツールバーを関連付けるADF Facesコンポーネントを追加する必要があります。

始める前に:

編集可能な表の一般的な知識があると役立ちます。詳細は、5.3項「編集可能な表の作成」を参照してください。

次のタスクを完了する必要があります。

2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

編集可能な表を作成する手順:

1. 「データ・コントロール」パネルから、表に表示するコレクションを選択します。
たとえば、システム内の顧客を編集可能な簡単な表をSummitデモ・アプリケーションで作成するには、customerFindAllアクセッサ・コレクションを選択します。

2. アクセッサをJSFページにドラッグし、ポップアップ・メニューから「ADF表」を選択します。

3. 次に表示される「表の列の編集」ダイアログを使用して、属性がどのように動作し、表の列としてどのように表示されるかを決定します。「行選択」チェック・ボックスを必ず選択することにより、ユーザーは編集する行を選択できます。
このダイアログを使用して表を構成する方法の詳細は、5.2項「基本表の作成」を参照してください。

4. 構造ウィンドウで表を選択し、プロパティ・インスペクタの「動作」セクションを展開してEditingMode属性を設定します。全行を編集可能にする場合は、editAllを選択します。ユーザーに1行をクリックさせてその行を編集可能にする場合は、clickToEditを選択します。

5. 構造ウィンドウで、表コンポーネントを右クリックし、ポップアップ・メニューから「囲む」を選択します。

6. 「囲む」ダイアログでは、ドロップダウン・リストで「ADF Faces」が選択されていることを確認し、「パネル・コレクション」コンポーネントを選択して「OK」をクリックします。
panelCollectionコンポーネントのツールバー・ファセットによりツールバーが保持され、そのツールバーによりデータの更新に使用されるコマンド・コンポーネントが保持されます。

7. 構造ウィンドウで、panelCollectionのtoolbarファセット・フォルダを右クリックし、ポップアップ・メニューから「ツールバーの中に挿入」→「ツールバー」の順に選択します。
これにより、ユーザーが表の表示方法を変更できるデフォルトのメニューと、表全体の連結を解除する「連結解除」リンクをすでに含むツールバーが作成され、ブラウザ・ウィンドウの大部分を占めるように表示されます。panelCollectionコンポーネントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表メニュー、ツールバーおよびステータス・バーの表示に関する項を参照してください。

8. 「データ・コントロール」パネルから、ロジックの実行対象となるオブジェクトのコレクションに関連付けられているメソッドまたは操作を選択し、構造ウィンドウのtoolbarコンポーネントにドラッグします。これにより、データバインドされたコマンド・コンポーネントがツールバー内に配置されます。

たとえば、顧客レコードを削除できるようにする場合は、removeCustomer(Customer)メソッドをドラッグします。図5-5に、Summitデモ・アプリケーションの削除メソッドを示します。

図5-5 データ・コントロールの削除メソッド

9. ポップアップ・メニューから「操作」→「ADFツールバー・ボタン」を選択します。
メソッドがパラメータをとるため、 アクション・バインディング・エディタが開き、パラメータの値を設定するよう求められます。

10. 「アクション・バインディングの編集」ダイアログで、メソッドのパラメータに値を移入する必要があります。削除メソッド(およびその他のデフォルト・メソッド)の場合、これが選択されるオブジェクトです。

1. 「パラメータ」セクションで、「値」ドロップダウン・リストを使用して「EL式ビルダーの表示」を選択します。

2. 式ビルダーで、アクセッサのイテレータのノードを展開して「currentRow」ノードを展開し、「dataProvider」を選択します。
これによって、アクセッサのイテレータで現在の行の値と評価されるEL式が作成されます。

3. 「OK」をクリックします。

たとえば、ordFindAllアクセッサを使用して表を作成した場合、JDeveloperによってordFindAllIteratorという名前のaccessorIteratorバインディングが作成されます。図5-6に示すように、そのイテレータの下の現在の行のdataProviderオブジェクトを選択する必要があります。この参照は、パラメータ値が、現在選択されている行の値に解決されることを表します。

図5-6 ordFindAllIteratorバインディングの現在の行のdataProvider

11. コレクションが変更されていることをADFモデル・レイヤーに通知するには、イテレータをリフレッシュするメソッドにツールバー・ボタンをバインドする必要もあります。

1. ファイルを右クリックして「ページ定義に移動」を選択し、JSPXファイルのページ定義を開きます。

2. ページ定義の構造ウィンドウで、「バインディング」を右クリックし、「バインディングの中に挿入」→「一般バインディング」→「アクション」を選択します。

3. 「アクション・バインディングの作成」ダイアログで、「イテレータの選択」ドロップダウン・リストを使用してコレクションに関連付けるイテレータを選択し、「操作」に「実行」を選択します。
JDeveloperによって、イテレータのexecute操作に対するアクション・バインディングが作成されます。次に、コマンド・ボタンでこの操作をコールする必要があります。

12. JSFページで、手順8でメソッドをドロップして作成したコマンド・コンポーネントを選択します。プロパティ・インスペクタで、「アクション」を次のように設定します。

#{bindings.Execute.execute}

コマンド・コンポーネントがクリックされると、actionListener属性のバインディングの後でaction属性へのバインディングが評価されます。この順序によって、エンティティの削除後にイテレータでリフレッシュや実行が行われることが保障されます。

5.3.2 編集可能な表の作成時の処理

編集可能な表の作成は、レコードの編集に使用するフォームの作成と類似しています。「データ・コントロール」パネルからドロップした操作に対してアクション・バインディングが作成されます。詳細は、4.6.2項「値を変更するメソッドの使用時の処理」を参照してください。

5.4 入力表の作成

ユーザーが表に新しく空白行を挿入し、各列に値を追加することのできる表を作成できます(対応するデータ・コントロール構造ファイルに設定されたデフォルト値は自動的に移入されます)。

5.4.1 入力表の作成方法

入力表を作成する際に、現在の行セット内の他の行のコンテキストにある新しい空白行をユーザーに表示する必要があります。この挿入をできるようにするには、表の作成に使用したコレクションのアクセッサに関連付けられているcreate操作を使用する必要があります。

create操作はキャッシュに行を作成するだけであるため、新たに作成された行をコレクションに実際にマージするボタンを追加する必要もあります。図5-7は、この表に行が作成された場合を示しています。

図5-7 行の作成およびデータの保存のボタンがある入力表

ページ全体をリフレッシュするのではなく、他のコンポーネントとの対話に基づいて1つのコンポーネントをリフレッシュするようにADF Facesコンポーネントを設定できます。これは、部分ページ・レンダリングと呼ばれます。ユーザーが新規行を作成するボタンをクリックすると、その新規行が表示されるよう、表をリフレッシュする必要があります。これを行うには、ユーザー・アクションに対応するよう表を構成する必要があります。

始める前に:

入力表の一般的な知識があると役立ちます。詳細は、5.4項「入力表の作成」を参照してください。

次のタスクを完了する必要があります。

- 2.2.1項「ADFデータ・コントロールの作成方法」の説明に従って、セッションBeanのデータ・コントロールを作成します。

- 5.3項「編集可能な表の作成」で説明しているように、編集可能な表を作成します。

入力表を作成する手順:

1. 「データ・コントロール」パネルから、ドロップされたコレクションに関連付けられた「作成」操作をドラッグし、ツールバー・ボタンとしてツールバーにドロップします。

ヒント:

CreateなどのわかりやすいものにIDを変更できます。これによって、部分トリガーとして選択する際に識別しやすくなります。

2. 構造ウィンドウで、表コンポーネントを選択します。

3. プロパティ・インスペクタで「動作」セクションを展開し、PartialTriggers属性のドロップダウン・メニューをクリックして「編集」を選択します。

4. 「プロパティの編集」ダイアログで、panelCollectionコンポーネントのツールバー・ファセットを展開し、「作成」コマンド・コンポーネントを含むツールバーを展開します。そのコンポーネントを選択し、「選択済」パネルに移動します。「OK」をクリックします。これにより、そのコンポーネントが、表をリフレッシュするトリガーとして設定されます。

5. ユーザーが新規オブジェクトをコレクションにマージできるボタンを作成します。「データ・コントロール」パネルから、表の作成に使用されたコレクションに関連付けるマージ・メソッドをドラッグし、ツールバー・ボタンまたはリンクとしてツールバーにドロップします。

ヒント:

永続化後もユーザーが行を更新できるようにする場合、かわりに永続化メソッドを使用してボタンを作成します。詳細は、4.6.3項「マージ・メソッドと永続化メソッドとの違いについて」を参照してください。

図5-8は、Ordコレクションのマージ・メソッドを示しています。

図5-8 「データ・コントロール」パネルでのマージ・メソッド

5.4.2 入力表の作成時の処理

create操作を使用して入力表を作成すると、JDeveloperによって次の処理が行われます。

- コレクションのイテレータ・バインディング、create操作のアクション・バインディング、および表の属性バインディングが作成されます。create操作は、行セットに新しい行を作成します。マージ・メソッドを使用してコマンド・ボタンまたはリンクを作成した場合、JDeveloperによって、そのメソッドに対するアクション・バインディングも作成されます。

- ADF Facesコンポーネントの表のコードがJSFページに挿入されます。

例5-5に、入力表のページ定義ファイルを示します。

例5-5 入力表のページ定義コード

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="SessionEJBLocal"
id="SessionEJBLocalIterator"/>
<accessorIterator MasterBinding="SessionEJBLocalIterator"
Binds="suppliersFindAll" RangeSize="25"
DataControl="SessionEJBLocal" BeanClass="model.Suppliers"
id="suppliersFindAllIterator"/>
</executables>
<bindings>
<action IterBinding="suppliersFindAllIterator" id="Create"
RequiresUpdateModel="true" Action="createRow"/>
<methodAction id="mergeSuppliers" RequiresUpdateModel="true"
Action="invokeMethod" MethodName="mergeSuppliers"
IsViewObjectMethod="false" DataControl="SessionEJBLocal"
InstanceName="SessionEJBLocal.dataProvider"
ReturnName="SessionEJBLocal.methodResults.mergeSuppliers_
SessionEJBLocal_dataProvider_mergeSuppliers_result">
<NamedData NDName="suppliers"
NDValue="#{bindings.Create.currentRow.dataProvider}"
NDType="model.Suppliers"/>
</methodAction>
<tree IterBinding="suppliersFindAllIterator" id="suppliersFindAll">
<nodeDefinition DefName="model.Suppliers">
<AttrNames>
<Item Value="email"/>
<Item Value="phoneNumber"/>
<Item Value="supplierId"/>
<Item Value="supplierName"/>
<Item Value="supplierStatus"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

例5-6に、コマンド・ツールバー・ボタンを、表をリフレッシュするためのトリガーとして使用し、部分ページ・レンダリングを提供するJSFページに追加されたコードを示します。

例5-6 表のコマンド・ボタンに設定された部分ページ・トリガー

<af:form id="f1">
<af:panelCollection id="pc1">
<f:facet name="menus"/>
<f:facet name="toolbar">
<af:toolbar id="t2">
<af:commandToolbarButton actionListener="#{bindings.Create.execute}"
text="Create New Supplier"
disabled="#{!bindings.Create.enabled}"
id="ctb1"/>
<af:commandToolbarButton
actionListener="#{bindings.mergeSuppliers.execute}"
text="Commit New Suppliers"
disabled="#{!bindings.mergeSuppliers.enabled}"
id="ctb2"/>
</af:toolbar>
</f:facet>
<f:facet name="statusbar"/>
<af:table value="#{bindings.suppliersFindAll.collectionModel}"
var="row" rows="#{bindings.suppliersFindAll.rangeSize}"
emptyText="#{bindings.suppliersFindAll.viewable ? 'No data to
display.' : 'Access Denied.'}"
fetchSize="#{bindings.suppliersFindAll.rangeSize}"
rowBandingInterval="0"
selectedRowKeys=
"#{bindings.suppliersFindAll.collectionModel.selectedRow}"
selectionListener=
"#{bindings.suppliersFindAll.collectionModel.makeCurrent}"
rowSelection="single" id="t1"
partialTriggers="::ctb1 ::ctb2">
<af:column sortProperty="supplierId" sortable="false"
headerText=
"#{bindings.suppliersFindAll.hints.supplierId.label}"
id="c6">
<af:inputText value="#{row.bindings.supplierId.inputValue}"
label="#{bindings.suppliersFindAll.hints.supplierId.label}"
required="#{bindings.suppliersFindAll.hints.supplierId.mandatory}"
columns="#{bindings.suppliersFindAll.hints.supplierId.displayWidth}"
maximumLength="#{bindings.suppliersFindAll.hints.supplierId.precision}"
shortDesc="#{bindings.suppliersFindAll.hints.supplierId.tooltip}"
id="it4">
<f:validator binding="#{row.bindings.supplierId.validator}"/>
<af:convertNumber groupingUsed="false"
pattern="#{bindings.suppliersFindAll.hints.supplierId.format}"/>
</af:inputText>
</af:column>
.
.
.
</af:table>
</af:panelCollection>
</af:form>

5.4.3 実行時に行われる処理: 作成および部分ページ・リフレッシュの動作方法

create操作にバインドされたボタンを起動すると、アクションが実行され、ページがレンダリングされることによりコレクションの新しいインスタンスが作成されます。ボタンは、表をリフレッシュするトリガーとして構成されているため、表の最上部に新しい空白行を表示して再描画されます。ユーザーが、マージ・メソッドにバインドされたボタンをクリックすると、行セットに新規作成された行がデータベースに挿入されます。部分ページ・リフレッシュの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「部分ページ・コンテンツのレンダリング」を参照してください。

5.4.4 行の作成および列のソートについて

表の列のソートが可能で、新規行を挿入する前にユーザーが列をソートした場合、新規行はソートされません。新規行もソートされるようにするには、ユーザーは、希望するソートとは反対のソートを行った後、再度ソートする必要があります。これは、表で列がすでにソートされていると見なされるためで、最初から希望のソート順をクリックしても列には何の効果もあらわれません。

たとえば、ユーザーが列を昇順でソートし、その後行を新たに追加するとします。最初、その行は最上部に表示されます。ユーザーが列を再度昇順でソートするようクリックすると、表は再ソートされません。これは、列がすでに昇順であると見なされるためです。ユーザーは、降順でソートした後に昇順でソートする必要があります。

行を挿入すると、データが特定の列で特定の順に自動的にソートされるようにする場合、プログラムでコミット後にSortEventをキューに入れ、ソートを実行するハンドラを実装します。

5.5 表に表示される属性の変更

「データ・コントロール」パネルを使用して表を作成したら、属性の削除、表示順序の変更、表示に使用されるコンポーネントの変更、コンポーネントの属性バインディングの変更ができます。新しい属性を追加したり、表を新規のデータ・コントロールに再バインドすることもできます。

既存のUIコンポーネントとバインディングの変更の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の表に表示される属性の変更に関する項を参照してください。

6 マスター/ディテール・データの表示

この章では、「データ・コントロール」パネルを使用して、ADF Facesコンポーネントに基づいたマスター/ディテール・オブジェクトを作成する方法について説明します。事前作成済のマスター/ディテール・ウィジェット、表、ツリーおよびツリー表を使用してマスター/ディテール・データを表示する方法と、選択イベントの操作方法について説明します。

この章には、次の項が含まれます:

- 6.1項「マスター/ディテール・データの表示の概要」

- 6.2項「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別」

- 6.3項「表およびフォームを使用したマスター/ディテール・オブジェクトの表示」

- 6.4項「ツリーを使用したマスター/ディテール・オブジェクトの表示」

- 6.5項「ツリー表を使用したマスター/ディテール・オブジェクトの表示」

- 6.6項「ツリーおよび表での選択イベントの使用」

選択リストを使用して、関連するマスター・コレクションまたはディテール・コレクションからのキー値をコレクションに移入する方法の詳細は、第7章「データバインドされた選択リストの作成」を参照してください。

6.1 マスター/ディテール・データの表示の概要

オブジェクトがマスター/ディテール関係にある場合は、両方のオブジェクトのデータを同時に表示するページを宣言的に作成できます。たとえば、図6-1に示すページでは、ページ上部のフォームに国コードを表示し、関連する州および地方をページ下部の表に表示しています。このような表示ができるのは、オブジェクトがマスター/ディテール関係にあるためです。この例では、Country Codeがマスター・オブジェクトで、Statesがディテール・オブジェクトです。ADFイテレータは、選択されたマスター・データ・オブジェクトに対して表示されるディテール・データ・オブジェクトの同期化を自動的に管理します。イテレータ・バインディングにより、データ・コレクションのスクロール処理やページング、または概要情報から詳細情報へのドリルダウンを可能にするユーザー・インタフェースを簡単に作成できます。

図6-1 ディテール表

マスター・オブジェクトとディテール・オブジェクトは、フォームおよび表に表示します。マスター/ディテール・フォームを使用すると、これらのオブジェクトを別々のページに表示できます。たとえば、マスター・オブジェクトをあるページの表に表示し、ディテール・オブジェクトを別のページの読取り専用フォームに表示できます。

注意:

Jdeveloperで提供されるマスター/ディテールUIコンポーネントでは必要な機能を発揮できない場合があります。たとえば、マスター/ディテールUIコンポーネントを使用するかわりに、コンポーネントをプログラム的にバインドすることが必要な場合があります。

マスター・オブジェクトは多数のディテール・オブジェクトを保持でき、各ディテール・オブジェクトも自身のディテール・オブジェクトを多くのレベル(深さ)にわたって保持できます。この階層内のディテール・オブジェクトの1つをアプリケーション・ナビゲータからマスター/ディテール・フォームとしてページにドロップすると、直接の親マスター・オブジェクトのみがページに表示されます。最上位の親オブジェクトまで、階層全体が表示されるわけではありません。

ディテール・オブジェクトをツリー・オブジェクトまたはツリー表オブジェクトとして表示すると、複数のレベルからなる階層全体を、最上位のマスター・オブジェクトから各ノードの子ディテール・オブジェクトまで表示できます。

6.2 「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別

「データ・コントロール」パネルを使用して、マスター/ディテール・データを表示するページを宣言的に 作成できます。「データ・コントロール」パネルでは、マスター/ディテール関係にあるオブジェクトが階層に表示されます。この階層は、ディテール・オブジェクトがマスター・オブジェクトの子となるデータ・モデルを表したものです。

マスター/ディテール・オブジェクトをフォーム・オブジェクトまたは表オブジェクトとして表示するには、「データ・コントロール」パネルからディテール・オブジェクトをドラッグし、ページにドロップします。マスター・オブジェクトは、ページ上に自動的に作成されます。

図6-2は、「データ・コントロール」パネルに表示された、マスター/ディテール関係にある2つのアクセッサ戻りコレクションを示しています。ProductImageListがProductFindAllの子として表示されています。

注意:

「データ・コントロール」パネルに表示されるマスター/ディテール階層には、関係のカーディナリティ(1対多、1対1、多対多)は反映されません。この階層は単に、どのアクセッサ戻りコレクション(マスター)を使用して別のアクセッサ戻りコレクション(ディテール)から1つ以上のオブジェクトを取得しているかを示します。

図6-2 「データ・コントロール」パネルでのマスター/ディテール・オブジェクト

この例では、ProductFindAllとProductImageListの関係は一方向関係です。

6.3 表およびフォームを使用したマスター/ディテール・オブジェクトの表示

「データ・コントロール」パネルを使用すると、マスター/ディテール参照ページを単一の宣言的アクションで作成できます。そのために必要な操作は、ディテールのアクセッサ戻りコレクションをページにドロップして、使用するウィジェットのタイプを選択することのみです。

「データ・コントロール」パネルで使用できる事前作成済のマスター/ディテール・ウィジェットには、コレクション内のデータ・オブジェクトをエンド・ユーザーがスクロールできるレンジ・ナビゲーションが含まれます。テキスト・フィールドまたは列をページから削除すると、不要な属性を削除できます。

図6-3に、事前作成済のマスター/ディテール・ウィジェットの例を示します。このウィジェットでは、ページ上部のフォームに商品情報が表示され、ページ下部の表に在庫レベルが表示されています。ユーザーが「次へ」ボタンをクリックし、ページ上部のマスター・データのレコードをスクロールすると、関連するディテール・データが自動的にページに表示されます。

図6-3 「データ・コントロール」パネルの事前作成済のマスター/ディテール・ウィジェット

6.3.1 表およびフォームでのマスター/ディテール・オブジェクトの表示方法

事前作成済のマスター/ディテール・ウィジェットを使用しない場合、マスター・オブジェクトとディテール・オブジェクトを表やフォームとして、「データ・コントロール」パネルから単一のページまたは別々のページに1つずつドラッグ・アンド・ドロップできます。

「データ・コントロール」パネルで事前作成済のマスター/ディテール・フォームおよび表を使用すると、単一の宣言的アクションで、マスター・ウィジェットとディテール・ウィジェットの両方を1つのページ上に作成できます。

事前作成済のADFマスター/ディテール・フォームおよび表を使用したマスター/ディテール・ページを作成する手順:

1. 「データ・コントロール」パネルでディテール・オブジェクトを特定します。

2. ディテール・オブジェクトをJSFページにドラッグ・アンド・ドロップします。

注意:

編集可能なマスター/ディテール・フォームを作成する場合は、マスター・オブジェクトとディテール・オブジェクトを別々にページにドロップします。

3. ポップアップ・メニューから、次のいずれかのマスター/ディテールUIコンポーネントを選択します。

- ADFマスター表、ディテール・フォーム: 表にマスター・オブジェクトが表示され、表の下にある読取り専用フォームにディテール・オブジェクトが表示されます。
マスター表で特定のデータ・オブジェクトを選択すると、その下にあるフォーム内に、関連する最初のディテール・データ・オブジェクトが表示されます。後続の各ディテール・データ・オブジェクトをスクロールするには、フォーム・ナビゲーションを使用する必要があります。

- ADFマスター・フォーム、ディテール表: マスター・オブジェクトが読取り専用フォームに表示され、ディテール・オブジェクトがフォームの下にある読取り専用表に表示されます。
フォームに特定のマスター・データ・オブジェクトを表示すると、その下にある表に、関連するディテール・データ・オブジェクトが表示されます。

- ADFマスター・フォーム、ディテール・フォーム: マスター・オブジェクトとディテール・オブジェクトが別々のフォームに表示されます。
上のフォームに特定のマスター・データ・オブジェクトを表示すると、その下にあるフォームに、関連する最初のディテール・オブジェクトが表示されます。後続の各ディテール・データ・オブジェクトをスクロールするには、フォーム・ナビゲーションを使用する必要があります。

- ADFマスター表、ディテール表: マスター・オブジェクトとディテール・オブジェクトが別々の表に表示されます。
上の表で特定のマスター・データ・オブジェクトを選択すると、その下にある表に、関連する最初のディテール・データ・オブジェクトのセットが表示されます。

6.3.2 マスター/ディテール表およびフォームの作成時の処理

「データ・コントロール」パネルからアクセッサ戻りコレクションをドラッグ・アンド・ドロップすると、様々な処理が自動的に行われます。たとえば、JSFページにコードが追加され、ページ定義ファイルに対応するエントリが追加されます。

6.3.2.1 JSFページで生成されるコード

事前作成済のマスター/ディテール・ウィジェット用に生成されたJSFコードは、「データ・コントロール」パネルを使用して読取り専用のフォームまたは表を作成したときに生成されるJSFコードとほぼ同じです。独自のマスター/ディテール・ウィジェットを作成する場合、事前作成済のマスター/ディテール表およびフォームに自動的に組み込まれるものと同様のコンポーネントを組み込むことを検討してください。

事前作成済のマスター/ディテール・ウィジェットの表およびフォームには、フォームまたは表にデータを移入するデータ・オブジェクトの完全修飾名を保持するpanelHeaderタグが含まれます。このラベルは、リソース・バンドルにバインドする文字列またはEL式を使用して、必要に応じて変更できます。

コレクション内に複数のデータ・オブジェクトがある場合、事前作成済のマスター/ディテール・ウィジェットのフォームには、レンジ・ナビゲーション用としてFirst、Previous、NextおよびLastという4つのcommandButtonタグがあります。これらのレンジ・ナビゲーション・ボタンを使用して、コレクション内のデータ・オブジェクトをスクロールできます。各ボタンのactionListener属性は、ナビゲーションを実行するデータ・コントロール操作にバインドされています。ボタンをクリックすると、actionListenerバインディングで使用されるexecuteプロパティによって、操作が起動します。(フォームに単一のデータ・オブジェクトが表示されている場合、レンジ・ナビゲーション・コンポーネントは表示されません。)

ヒント:

ページに「ADFマスター表、ディテール・フォーム」ウィジェットまたは「ADFマスター表、ディテール表」ウィジェットをドロップすると、ディテール・コンポーネントの親タグ(panelHeaderタグやtableタグなど)のpartialTriggers属性はマスター・コンポーネントのidに自動的に設定されます。実行時に、ユーザーがマスター・コンポーネントで選択を行うと、partialTriggers属性によりディテール・コンポーネントのみが再度レンダリングされます。これは、部分レンダリングと呼ばれます。マスター・コンポーネントが表の場合、ADFでは部分レンダリングが使用されます。これは、ユーザーがファセット内で選択のみを行う場合、表を再度レンダリングする必要がないためです。新しいデータを表示するために再度レンダリングする必要があるのはディテール・コンポーネントのみです。

6.3.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

例6-1に、マスター/ディテール・ページ用に作成されたページ定義ファイルを示します。このマスター/ディテール・ページは、ProductFindAllオブジェクトの下位のディテール・オブジェクトであるWarehouseStockLevelListをADFマスター・フォーム、ディテール表としてページにドロップして作成したものです。

executables要素は2つのaccessorIteratorを定義しています。1つは商品(マスター・オブジェクト)に対するもの、もう1つはWarehouseStockLevels(ディテール・オブジェクト)に対するものです。実行時には、UI対応のデータ・モデルと行セット・イテレータにより、現在の行が変更されたときに、ディテール・コレクションの行セットが現在のマスター行の正しい行セットになるようにリフレッシュされます。

bindings要素は、値バインディングを定義します。フォーム内のテキスト・フィールドにデータを移入する属性バインディングは、attributeValues要素内で定義されます。attributeValues要素のid属性には各データ属性の名前が含まれ、IterBinding属性はイテレータ・バインディングを参照し、マスター・オブジェクトのデータをテキスト・フィールドに表示します。

フォーム内のテキスト・フィールドにデータを移入する属性バインディングは、attributeValues要素内で定義されます。attributeValues要素のid属性には各データ属性の名前が含まれ、IterBinding属性はイテレータ・バインディングを参照し、マスター・オブジェクトのデータをテキスト・フィールドに表示します。

フォーム内のレンジ・ナビゲーション・ボタンは、action要素で定義されたアクション・バインディングにバインドされます。属性バインディングの場合と同様、アクション・バインディングのIterBinding属性は、マスター・オブジェクトのイテレータ・バインディングを参照します。

ディテール・データを表示する表は、table要素で定義される表バインディング・オブジェクトにバインドされます。IterBinding属性は、ディテール・オブジェクトのイテレータ・バインディングを参照します。

例6-1 マスター/ディテール・ページ用にページ定義に定義されたバインディング・オブジェクト

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="SupplierFacadeLocal"
id="SupplierFacadeLocalIterator"/>
<accessorIterator MasterBinding="SupplierFacadeLocalIterator"
Binds="productFindAll" RangeSize="25"
DataControl="SupplierFacadeLocal"
BeanClass="oracle.fodemo.supplier.model.Product"
id="productFindAllIterator"
ChangeEventPolicy="ppr"/>
<accessorIterator MasterBinding="productFindAllIterator"
Binds="warehouseStockLevelList" RangeSize="25"
DataControl="SupplierFacadeLocal"
BeanClass="oracle.fodemo.supplier.model.WarehouseStockLevel"
id="warehouseStockLevelListIterator"
ChangeEventPolicy="ppr"/>
</executables>
<bindings>
<action IterBinding="productFindAllIterator" id="First"
RequiresUpdateModel="true" Action="first"/>
<action IterBinding="productFindAllIterator" id="Previous"
RequiresUpdateModel="true" Action="previous"/>
...
<attributeValues IterBinding="productFindAllIterator" id="attribute1">
<AttrNames>
<Item Value="warrantyPeriodMonths"/>
</AttrNames>
</attributeValues>
...
<tree IterBinding="warehouseStockLevelListIterator"
id="warehouseStockLevelList">
<nodeDefinition DefName="oracle.fodemo.supplier.model.WarehouseStockLevel">
<AttrNames>
<Item Value="lastUpdateDate"/>
<Item Value="objectVersionId"/>
<Item Value="productId"/>
<Item Value="quantityOnHand"/>
...
<Item Value="warehouseId"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

6.3.3 実行時に行われる処理: マスター/ディテール表およびフォームのADFイテレータ

実行時に、ADFイテレータは、マスター表オブジェクトのどの行をマスター/ディテール・フォームに表示するかを決定します。フォームが最初に表示されるときは、マスター表オブジェクトの1行目がフォームのマスター・セクションに強調表示されます。マスター行に関連付けられているディテール表の行は、フォームのディテール・セクションに表示されます。

6.3.2.2項「ページ定義ファイルで定義されるバインディング・オブジェクト」で説明しているように、ADFイテレータは基礎となるrowsetIteratorオブジェクトに関連付けられています。これらのイテレータは、ページに現在表示されているデータ・オブジェクト(つまり行)がどれかを管理します。実行時には、行セット・イテレータがマスター・コンポーネントとディテール・コンポーネントに表示されるデータを管理します。

マスターおよびディテールの行セット・イテレータは、どちらも行セット・ナビゲーション・イベント(ユーザーによるレンジ・ナビゲーション・ボタンのクリックなど)をリスニングし、適切な行をUIに表示します。デフォルトのマスター/ディテール・コンポーネントの場合は、行セット・ナビゲーション・イベントは、フォーム上のコマンド・ボタン(「先頭へ」、「前へ」、「次へ」、「最後へ」)になります。

ディテール・コレクションの行セット・イテレータは、 ディテール・データとマスター・データの同期化を管理します。ディテール行セット・イテレータは、マスター・コレクションとディテール・コレクションの両方で行ナビゲーション・イベントをリスニングします。マスター・コレクションで行セット・ナビゲーション・イベントが発生すると、ディテール行セット・イテレータが自動的に実行され、現在のマスター行に関連するディテール行が戻されます。

6.3.4 別々のページへのマスター/ディテール・ウィジェットの表示について

デフォルトのマスター/ディテール・コンポーネントでは、 マスター/ディテール・データは単一のページに表示されます。ただし、「データ・コントロール」パネルでマスター・オブジェクトとディテール・オブジェクトを使用して、バインディング・イテレータにマスター・オブジェクトとディテール・オブジェクトの同期化を管理させたまま、コレクションを別々のページに表示できます。

マスター/ディテール・オブジェクトを別々のページに表示するには、マスター・オブジェクト用として1ページ、ディテール・オブジェクト用として1ページの、計2ページを作成します。その際には、「データ・コントロール」パネルから使用できる、個々の表またはフォームを使用します。ディテール・オブジェクト・イテレータは、マスター・データとディテール・データの同期化を管理することを忘れないでください。ディテール・データを表示するページを作成する際には、必ず「データ・コントロール」パネルから適切なディテール・オブジェクトをドラッグしてください。詳細は、第6.2項「「データ・コントロール」パネルでのマスター/ディテール・オブジェクトの識別」を参照してください。

ページ・ナビゲーションを処理するには、ADFタスク・フローを作成し、マスター・ページ用として1つ、ディテール・ページ用として1つの、計2つのビュー・アクティビティを追加します。コマンド・ボタンまたはリンクを各ページに追加するか、「データ・コントロール」パネルを使用してフォームまたは表を作成するときに使用可能なデフォルトの「発行」ボタンを使用します。各ボタンについて、action属性内で、ナビゲーション・ルールの結果値を指定する必要があります。task-flow-defintion.xmlファイルで、マスター・データ・ページからディテール・データ・ページへのナビゲーション・ルール、およびディテール・データ・ページからマスター・データ・ページに戻るための別のルールを追加します。ナビゲーション・ルール内のfrom-outcomeの値は、ボタンのaction属性で指定された結果値と一致する必要があります。

6.4 ツリーを使用したマスター/ディテール・オブジェクトの表示

表およびフォーム以外に、階層ツリーにもマスター/ディテール・データを表示できます。ADF Facesのtreeコンポーネントは階層データの表示に使用します。マスター・オブジェクトのバインディングによって移入される複数のルート・ノードが表示されます。ツリー内の各ルート・ノードは、ディテール・オブジェクトのバインディングによって移入されるブランチを持つことが可能で、その数に制限はありません。ツリーには複数のレベルのノードがあり、各ノードは親ノードのディテール・オブジェクトを示します。ツリー内の各ノードは、階層でのノードのレベルを示します。

treeコンポーネントには、ツリー・ノードを開閉するメカニズムが含まれていますが、フォーカス機能はありません。フォーカス機能を使用する必要がある場合は、ADF FacesのtreeTableコンポーネントの使用を検討してください(詳細は、6.5項「ツリー表を使用したマスター/ディテール・オブジェクトの表示」を参照)。デフォルトでは、ツリーの各ノードのアイコンはフォルダですが、独自のアイコンを階層内の各レベルのノードに使用できます。

図6-4は、ルートとブランチという2つのレベルのノードを表示するツリーの例を示しています。ルート・ノードは「Media」、「Office」および「Electronics」などの親製品カテゴリを表示します。ブランチ・ノードには、「Office」親カテゴリの下の「Hardware」、「Supplies」、「Software」のような、各親カテゴリの下のサブカテゴリが表示されます。

図6-4 データバインドされたADF Facesツリー

6.4.1 ツリーでのマスター/ディテール・オブジェクトの表示方法

ツリーはノードの階層で構成され、各サブノードは上位レベルのノードから分岐します。データバインドされたADF Facesのtreeコンポーネントの各ノード・レベルは、異なるデータ・コレクションによって移入されます。JDeveloperでは、「ツリー・バインディングの編集」ダイアログを使用してデータバインド・ツリーを定義します。このダイアログで、ツリー内の各ノード・レベルにデータを移入するためのルールを定義できます。階層内の各ノード・レベルに対して1つのルールが必要です。それぞれのルールは、次のノード・レベル・プロパティを定義します。

- そのノード・レベルにデータを移入するアクセッサ戻りコレクション

- そのノード・レベルで表示される、アクセッサ戻りコレクションの属性

ツリーにマスター/ディテール・オブジェクトを表示する手順:

1. 「データ・コントロール」パネルからマスター・オブジェクトをドラッグし、ページにドロップします。これは、ツリーのルート・レベルを表すマスター・データである必要があります。

2. ポップアップ・メニューから、「ツリー」→「ADFツリー」を選択します。
図6-5に示す「ツリー・バインディングの編集」ダイアログが表示されます。バインディング・エディタを使用し、ツリーに表示する各レベルのルールを定義します。

図6-5 「ツリー・バインディングの編集」ダイアログ

3. 「ルート・データソース」ドロップダウン・リストで、ルート・ノード・レベルにデータを移入するアクセッサ戻りコレクションを選択します。
これがマスター・データ・コレクションとなります。デフォルトでは、これはツリーを作成するために「データ・コントロール」パネルからドラッグしたものと同じコレクション(マスター・コレクション)です。

ヒント:

目的のアクセッサ戻りコレクションが「ルート・データソース」リストに見つからない場合は、「追加」ボタンをクリックします。「データソースの追加」ダイアログで、データ・コントロールとイテレータ名を選択して新しいデータソースを作成します。

4. 「追加」アイコンをクリックし、選択したルート・データソースを「ツリー・レベル・ルール」リストに追加します。

5. 「ツリー・レベル・ルール」リストで、追加したデータソースを選択します。

6. 「使用可能な属性」リストで属性を選択し、「属性の表示」リストに移動します。
この属性はマスター・レベルのノードの表示に使用されます。

マスター・レベルのルールを定義したら、次にツリー内のマスター・レベルの下に表示されるディテール・レベルに対して2つ目のルールを定義する必要があります。

7. 2つ目のルールを追加するには、「ツリー・レベル・ルール」リストの上の「追加」アイコンをクリックします。
図6-6に示すように、マスター・データソースの下にディテール・データソースが自動的に表示されます。

図6-6 マスター/ディテール・ツリー・レベル・ルール

たとえば、マスターのルート・データソースとしてProductFindAllを指定すると、「ツリー・レベル・ルール」リストの下にWarehouseStockLevelListが自動的に表示されます。これは、2つのデータソースがマスター/ディテール関係にあるためです。

再帰的なマスター/ディテール階層を持つツリーを作成する場合は、データソースとセルフアクセッサを指定したルールを定義するだけで済みます。再帰的なツリーには、単一のコレクションに基づいてルート・ノードが表示されるとともに、そのコレクションからデータを繰返しフェッチするセルフアクセッサの属性から、子ノードが表示されます。再帰的なツリーは、ツリーのブランチを定義するためのルールが1つしか必要ないため、通常のマスター/ディテール・ツリーとは異なります。再帰的なデータソースは、図6-7に示すように、データソースの後にセルフアクセッサ名をカッコで囲んで指定した形で表示されます。

図6-7 再帰的なツリー・レベル・ルール

たとえば、EmployeesViewで定義されたコレクションでは、各ブランチのルート・ノードを従業員のManagerIdで指定できます。その場合、セルフアクセッサDirectReportsで指定されたとおり、同じブランチの子ノードはManagerIdに関連する従業員になります。

8. 「OK」をクリックします。

9. 「ツリー・レベル・ルール」リストにデータソースを追加し、ツリーに表示されるノード数を増やすこともできます。残りのデータソースの順序は、ツリーに表示するノードの階層に従う必要があります。

6.4.2 ADFデータバインド・ツリーの作成時の処理

「データ・コントロール」パネルからドラッグ・アンド・ドロップすると、様々な処理が自動的に行われます。

「データ・コントロール」パネルを使用してデータバインド・ツリーを作成すると、ページ定義ファイルにバインディング・オブジェクトが追加され、JSFページにtreeタグが追加されます。作成されたUIコンポーネントは、そのままで十分機能するため、変更する必要はありません。

6.4.2.1 JSFページで生成されるコード

例6-2は、「データ・コントロール」パネルを使用してツリーを作成したときにJSFページで生成されるコードを示しています。このサンプル・ツリーには、注文番号がルート・ノードとして、商品名がリーフ・ノードとして表示されます。

例6-2 データ・バインド・ツリー用にJSFページで生成されたコード

<af:tree
value="#{bindings.orderItemFindAll.treeModel}"
var="node"
selectionListener="#{bindings.orderItemFindAll.treeModel.makeCurrent}"
rowSelection="single" id="orderItemsTree">
<f:facet name="nodeStamp">
<af:outputText value="#{node}" id="ot2"/>
</f:facet>
</af:tree>

デフォルトで、フォームの中にaf:treeタグが作成されます。treeタグのvalue属性には、treeコンポーネントをページ定義ファイルのorderItemFindAllツリー・バインディング・オブジェクトにバインドするEL式が含まれます。バインディング式のtreeModelプロパティは、基礎となるデータ・モデルに基づいてtree階層の表示方法を定義する、ADFクラスを参照します。var属性は、現在のノードへのアクセスを提供します。

f:facetタグに含まれるnodeStampファセットは、各ノードのデータを表示するために使用されます。treeでは、ノードごとにコンポーネントを持つかわりに、ADF Facesの表コンポーネントに対して行がレンダリングされるのと同様の方法で、nodeStampファセットが繰返しレンダリングされます。

ADF Facesのtreeコンポーネントは、oracle.adf.view.faces.model.PathSetクラスのインスタンスを使用して、開いた状態のノードを表示します。このインスタンスは、コンポーネントのtreeState属性として格納されます。このインスタンスを使用して、階層での要素の開閉状態をプログラム的に管理できます。PathSetインスタンスに含まれるすべての要素は、開いた状態とみなされます。その他のすべての要素は閉じた状態です。

6.4.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

例6-3は、ADFデータバインド・ツリー用にページ定義ファイルで定義されたバインディング・オブジェクトを示しています。

例6-3 データバインド・ツリー用にページ定義ファイルで定義されたバインディング・オブジェクト

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="SupplierFacadeLocal"
id="SupplierFacadeLocalIterator"/>
<accessorIterator MasterBinding="SupplierFacadeLocalIterator"
Binds="orderItemFindAll" RangeSize="25"
DataControl="SupplierFacadeLocal"
BeanClass="oracle.fodemo.supplier.model.OrderItem"
id="orderItemFindAllIterator"/>
</executables>
<bindings>
<tree IterBinding="orderItemFindAllIterator" id="orderItemFindAll">
<nodeDefinition DefName="oracle.fodemo.supplier.model.OrderItem"
Name="orderItemFindAll0">
<AttrNames>
<Item Value="orderId"/>
</AttrNames>
<Accessors>
<Item Value="product"/>
</Accessors>
</nodeDefinition>
<nodeDefinition DefName="oracle.fodemo.supplier.model.Product"
Name="orderItemFindAll1">
<AttrNames>
<Item Value="productName"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

tree要素は、ツリーに表示されるすべての属性の値バインディングです。tree要素のIterBinding属性は、ツリーにデータを移入するイテレータ・バインディングを参照します。tree要素内のAttrNames要素は、マスター・コレクション内のすべての属性のバインディング・オブジェクトを定義します。ただし、ツリーに表示するように選択する属性は、nodeDefinition要素内のAttrNames要素で定義されます。

nodeDefinition要素は、ツリーのノードにデータを移入するためのルールを定義します。ノードごとに1つのnodeDefinition要素があり、各要素には次の属性およびサブ要素が含まれます。

- DefName: ノードへのデータの移入に使用されるデータ・コレクションの完全修飾名が含まれる属性

- id: ノードの名前を定義する属性

- AttrNames: 実行時にノードに表示される属性を定義するサブ属性

- Accessors: ツリーの次のブランチを戻すアクセッサ属性を定義するサブ属性

ページ定義ファイルでのnodeDefintion要素の順序によって、ツリーでのノードの順序またはレベルが決まります。最初のnodeDefinition要素は、ルート・ノードを定義します。後続の各nodeDefinition要素は、先行するノードのサブノードを定義します。

6.4.3 実行時に行われる処理: ADFデータバインド・ツリーの表示

treeコンポーネントは、org.apache.myfaces.trinidad.model.TreeModelを使用してデータにアクセスします。このクラスは、ADF Facesのtableコンポーネントがデータへのアクセスに使用するCollectionModelを拡張します。TreeModelクラスの詳細は、ADF Faces Javadocを参照してください。

treeを含むページが表示されると、ツリーのイテレータ・バインディングによって、ルート・ノードにデータが移入されます。ユーザーがノードを開いてブランチを表示したり、閉じて非表示にすると、DisclosureEventイベントが送信されます。このイベントのisExpandedメソッドは、ユーザーによるノードの操作(開いているか、閉じているか)を判断します。DisclosureEventイベントには、リスナーが関連付けられています。

treeのDisclosureListener属性は、ページ定義ファイルで定義済のノード・ルールで指定されたアクセッサ属性にバインドされます。このアクセッサ属性は、DisclosureEventイベントに応じて起動します。つまり、ユーザーがノードを開くたびに、アクセッサ属性によってブランチ・ノードにデータが移入されます。

6.5 ツリー表を使用したマスター/ディテール・オブジェクトの表示

ADF FacesのtreeTableコンポーネントを使用すると、マスター/ディテール・コレクションの階層を表に表示できます。treeコンポーネントのかわりにtreeTableコンポーネントを使用することの利点は、treeTableコンポーネントがツリー内の特定のノードにフォーカスして表示するメカニズムを使用できることです。

たとえば、国、州または地方、都市という3つのノード・レベルを表示するツリー表を作成できます。各ルート・ノードは、個別の国を表します。各ルート・ノードが分岐して、その国の州または地方が表示されます。各州または地方のノードが分岐して、その中の都市を表示します。

ツリーの場合と同様、複数のノードがあるツリー表を作成するには、コレクションにマスター/ディテール関係を持たせる必要があります。たとえば、国、州、都市という3つのレベルを持つツリー表を作成するには、CountryCodesコレクションからStatesandProvincesコレクションへのマスター/ディテール関係、およびStatesandProvincesコレクションからCitiesコレクションへのマスター/ディテール関係が必要です。

データバインドされたADF FacesのtreeTableには、一度に1つのルート・ノードしか表示されませんが、様々なルート・ノードをスクロールするためのナビゲーションが用意されています。また、各ルート・ノードに表示されるブランチの数は制限されません。すべてのノードは表内で個別の行として表示され、各行の左端の列には、フォーカス・メカニズムが用意されています。

プロパティ・インスペクタで、次のtreeTableコンポーネント・プロパティを編集できます。

- レンジ・ナビゲーション: ユーザーは、「前へ」および「次へ」のナビゲーション・ボタンをクリックして、ルート・ノードをスクロールできます。

- リスト・ナビゲーション: 「前へ」ボタンと「次へ」ボタンの間にあるリスト・ナビゲーションにより、ユーザーは、選択リストを使用してデータ・コレクション内の特定のルート・ノードに移動できます。

- ノードを開閉するためのメカニズム: ユーザーは、それぞれのノードを個別に開閉するか、「すべて開く」または「すべて閉じる」のコマンド・リンクを使用できます。デフォルトでは、個々のノードを開閉するためのアイコンは、プラス記号またはマイナス記号が表示された矢印です。カスタム・アイコンを選択して使用することもできます。

- フォーカス・メカニズム: ユーザーがノードの横(左端の列)のフォーカス・アイコンをクリックすると、ページが再表示され、ノードとそのブランチのみが表示されます。親ノードに戻るためのナビゲーション・リンクも表示されます。

6.5.1 ツリー表でのマスター/ディテール・オブジェクトの表示方法

ADF Facesデータバインド・ツリー表の作成手順は、ADF Facesデータバインド・ツリーの作成手順とほぼ同じですが、アクセッサ戻りコレクションをドロップする際に、ADFツリーとしてではなくADFツリー表としてドロップします。

6.5.2 データバインド・ツリー表の作成時の処理

「データ・コントロール」パネルからドラッグ・アンド・ドロップすると、様々な処理が自動的に行われます。

「データ・コントロール」パネルを使用してデータバインド・ツリー表を作成すると、ページ定義ファイルにバインディング・オブジェクトが追加され、JSFページにtreeTableタグが追加されます。作成されたUIコンポーネントは、そのままで十分機能するため、変更する必要はありません。

6.5.2.1 JSFページで生成されるコード

例6-4は、「データ・コントロール」パネルを使用してツリー表を作成したときにJSFページで生成されるコードを示しています。このサンプル・ツリー表には、商品と在庫レベルという2つのノード・レベルが表示されます。

デフォルトで、フォームの中にtreeTableタグが作成されます。tree tableタグのvalue属性には、treeコンポーネントを、データ移入を行うバインディング・オブジェクトにバインドするEL式が含まれます。treeModelプロパティは、基礎となるデータ・モデルに基づいてツリー階層の表示方法を定義する、ADFクラスを参照します。var属性は、現在のノードへのアクセスを提供します。

例6-4 データバインドされたADF Facesツリー表用にJSFページで生成されたコード

<af:treeTable value="#{bindings.orderItemFindAll.treeModel}" var="node"
selectionListener="#{bindings.orderItemFindAll.treeModel.makeCurrent}"
rowSelection="single" id="tt1">
<f:facet name="nodeStamp">
<af:column id="c1">
<af:outputText value="#{node}" id="ot1"/>
</af:column>
</f:facet>
<f:facet name="pathStamp">
<af:outputText value="#{node}" id="ot2"/>
</f:facet>
</af:treeTable>

facetタグに含まれるnodeStampファセットは、各ノードのデータを表示するために使用されます。ノードごとにコンポーネントを持つかわりに、ツリーでは、ADF Faces tableコンポーネントに対して行がレンダリングされるのと同様の方法で、nodeStampファセットが繰返しレンダリングされます。pathStampファセットは、ユーザーがディテール・ノードにフォーカスした後で親ノードに戻れるように、表の上に列およびパスのリンクをレンダリングします。

6.5.2.2 ページ定義ファイルで定義されるバインディング・オブジェクト

ツリー表に対してページ定義ファイルで作成されるバインディング・オブジェクトは、ツリーに対して作成されるものとまったく同じです。

6.5.3 実行時に行われる処理: イベント

treeコンポーネントは、oracle.adf.view.faces.model.TreeModelを使用してデータにアクセスします。このクラスは、ADF Facesのtableコンポーネントがデータへのアクセスに使用するCollectionModelを拡張します。TreeModelクラスの詳細は、ADF Faces Javadocを参照してください。

ツリー表を含むページが表示されると、treeTableコンポーネントのイテレータ・バインディングは、ルート・ノードにデータを移入し、行ナビゲーション・イベント(ユーザーによる「次へ」ボタンまたは「前へ」ボタンのクリック、もしくはレンジ・ナビゲータからの行の選択)をリスニングします。ユーザーが行ナビゲーション・イベントを開始すると、イテレータによって適切な行が表示されます。

ユーザーがコンポーネントのフォーカス・アイコンをクリックして表示のフォーカスを変更すると、treeTableコンポーネントによってフォーカス・イベント(FocusEvent)が生成されます。フォーカス変更後のノードが現在のノードになった後で、イベントが配信されます。その後、treeTableコンポーネントによってfocusPathプロパティが適切に変更されます。ツリー上のFocusListener属性は、マネージドBeanのメソッドにバインドできます。これにより、このメソッドはフォーカス・イベントに応じて起動されます。

ユーザーがノードを開閉するたびに、公開イベント(DisclosureEvent)が送信されます。この公開イベントのisExpandedメソッドは、ユーザーの操作に基づいてノードを開くか閉じるかを判断します。公開イベントには、リスナーDisclosureListenerが関連付けられます。ツリー表上のDisclosureListener属性は、ページ定義ファイルで定義済のノード規則で指定されたアクセッサ属性にバインドされます。このアクセッサ属性は、公開イベント(ユーザーがノードを開くなど)に応じて起動し、そのノードを移入するコレクションを戻します。

treeTableコンポーネントには、「すべて展開」リンクおよび「すべて閉じる」リンクも表示されます。ユーザーがどちらかのリンクをクリックすると、treeTableによってDisclosureAllEventイベントが送信されます。このイベントのisExpandedメソッドは、ユーザーの操作に基づいてすべてのノードを開くか閉じるかを判断します。その後、現在フォーカスしているルート・ノードの子ノードが、開くか閉じます。大規模なツリーの場合は、すべて展開コマンドを使用しても、直下の子より下にあるノードは開きません。ADF FacesのtreeTableコンポーネントでは、oracle.adf.view.faces.model.PathSetクラスのインスタンスを使用して、開いたノードが判別されます。このインスタンスは、コンポーネントのtreeState属性として格納されます。このインスタンスを使用して、階層でのノードの開閉状態をプログラム的に管理できます。PathSetインスタンスに含まれるすべてのノードは、開いているとみなされます。その他のすべてのノードは閉じた状態になります。このクラスでは、addAll()やremoveAll()のような操作もサポートされます。

ADF FacesのtreeTableコンポーネントの詳細は、ADF Faces Javadocのoracle.adf.view.faces.component.core.data.CoreTreeTableクラスを参照してください。

6.5.4 TargetIteratorプロパティの使用

ページ定義エディタでノード・バインディングを展開すると、ページのnode Definition要素を表示できます。これらは、ツリー・バインディング・ダイアログで構成できる同じツリー・バインディング・ルールです。

ノード定義(ルール)ごとに、オプションのTargetIteratorプロパティを指定できます。その値は、ユーザーがツリーで行を選択すると、実行時に評価されるEL式です。このEL式は、現在のバインディング・コンテナ内のイテレータ・バインディングを評価します。イテレータ・バインディングの行キーの属性は、ツリー用にnodeDefinitionタイプの行が取得されるイテレータの行キーと(数値、データ型の順で)一致します。

実行時に、ツリー・コントロールはselectionChangedイベントを受け取ると、ツリーのレベルごとにキーのリストを渡します。これらのキーは選択されたノードを一意に識別します。

ツリー・バインディングは、ツリーの最上位から始まります。Currently Selected Tree Node Keysリストにキーが存在するツリー・レベルごとに、そのnodeDefinitionについて構成されているTargetIteratorプロパティがある場合、ツリー・バインディングは選択されたターゲット・イテレータに対してsetCurrentRowWithKey()操作を実行します。Currently Selected Tree Node Keysリストの適切なレベルからキーを使用します。

6.6 ツリーおよび表での選択イベントの使用

アプリケーションでなんらかの処理を行うために、ツリーまたはツリー表で選択されているノードを判別する必要が生じることがあります。たとえば、ユーザーが「参照」ツリーでカテゴリ・ノードを選択すると、選択イベントが起動します。このイベントに関連付けられているリスナーは、選択されたノードの商品カテゴリを判別し、その値に一致するカテゴリ属性を持つ商品をすべて戻す必要があります。

6.6.1 ツリーおよび表での選択イベントの使用方法

選択イベントをプログラム的に使用するには、選択イベントを処理して必要なロジックを実行するリスナーを、マネージドBean内に作成する必要があります。その後、ツリーまたは表のselectionListener属性をそのリスナーにバインドする必要があります。

ツリーおよび表で選択イベントを使用する手順:

1. 必要なリスナーを格納するマネージドBeanがまだ存在しない場合は、作成します。

2. マネージドBeanのリスナー・メソッドを作成します。リスナー・メソッドの作成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のADF Facesサーバー・イベントの使用に関する項を参照してください。リスナーは次の処理を実行する必要があります。

1. イベント・ソースを使用してコンポーネントにアクセスします。例6-5は、HomeBeanマネージドBeanのproductCategoriesTreeSelectionListenerメソッドが、選択イベントを起動したツリーにアクセスする方法を示しています。

例6-5 イベント・ソースの取得

public void productCategoriesTreeSelectionListener(SelectionEvent evt) {
RichTree tree = (RichTree)evt.getSource();

イベント・ソース・コンポーネントの特定の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のイベントの発生元を返す方法に関する項を参照してください。

2. ツリー・モデルにアクセスしてモデルの値を取得し、RowKeySetオブジェクトを使用して現在選択されているノードを取得した後、例6-6に示すように、それをモデルの現在の行として設定します。RowKeySetオブジェクトの詳細は、6.6.2項「実行時に行われる処理: RowKeySetオブジェクトとSelectionEventイベント」を参照してください。

例6-6 ツリー・モデルの現在の行の設定

TreeModel model = (TreeModel)tree.getValue();
RowKeySet rowKeySet = evt.getAddedSet();
Object key = rowKeySet.iterator().next();
model.setRowKey(key);

3. 次に、現在選択されている行に対して実行するロジックを追加します。たとえば、productCategoriesTreeSelectionListenerメソッドは、選択されている行の値バインディングを使用してカテゴリIDを判別した後、その値を、実行時にそのカテゴリIDを持つ商品をすべて戻す(例6-7を参照)別のメソッドのパラメータとして使用します。

例6-7 特定の属性値に一致するオブジェクトを戻す

JUCtrlValueBinding nodeBinding =
(JUCtrlValueBinding)model.getRowData();
Number catId = (Number)nodeBinding.getAttribute("CategoryId");
_selectedCategory = (String)nodeBinding.getAttribute("CategoryName");

OperationBinding ob =
ADFUtils.findOperation("ProductsByCategoriesExecuteWithParams");
ob.getParamsMap().put("category", catId);
ob.execute();

3. 対応するJSFページで、ツリー・コンポーネントまたは表コンポーネントを選択します。プロパティ・インスペクタで、「動作」セクションを開いて、SelectionListener属性の値を、作成したリスナー・メソッドに設定します。ドロップダウン・メソッドの「編集」オプションを使用すると、Beanとメソッドを宣言的に選択できます。

6.6.2 実行時に行われる処理: RowKeySetオブジェクトとSelectionEventイベント

ユーザーがツリーのノード(または表の行)を選択するたびに、コンポーネントは選択イベントを起動します。selectionEventイベントは、選択解除された行と選択された行をレポートします。現在の選択内容、つまり選択済の行は、RowKeySetオブジェクトによって管理され、このオブジェクトは、行の関連キーをキー・セットに追加、またはキーセットから削除することで、現在選択されているすべてのノードを追跡します。ユーザーが新しいノードを選択したときに、ツリーまたは表が単一選択用に構成されている場合、それまで選択されていたキーは破棄され、新たに選択されたキーが追加されます。ツリーまたは表が複数選択用に構成されている場合は、新たに選択されたキーがセットに追加されます。それまで選択されていたキーを破棄するかどうかは、ノードの選択方法によって決まります。たとえば、ユーザーが[Ctrl]キーを押した場合、新たに選択されたノードは現在のセットに追加されます。

7 データバインドされた選択リストの作成

この章では、ページに選択リスト・コンポーネントを追加する方法について説明します。固定値のリストや動的に生成されるリストで選択コンポーネントを作成するための手順について説明します。また、ナビゲーション・リスト・バインディングを追加して、ユーザーがコレクション内のオブジェクトのリストを移動できるようにする方法についても説明します。

この章には、次の項が含まれます:

- 7.1項「選択リストの概要」

- 7.2項「単一選択リストの作成」

- 7.3項「ナビゲーション・リスト・バインディングを持つリストの作成」

7.1 選択リストの概要

選択リストは、標準的なJSFリスト・コンポーネントと同様に機能します。ただし、ADF Facesのリスト・コンポーネントには追加の機能(ラベルとメッセージの表示、自動フォーム送信、部分ページ・レンダリングのサポートなど)が備わっています。

ユーザーがナビゲーション・リストから項目を選択すると、リストにバインドされた対応するコンポーネントでも、選択に応じて値が変更されます。たとえば、ユーザーがショッピング・リストから商品を選択すると、商品リストにバインドされている表が更新され、選択した商品の詳細が表示されます。

7.2 単一選択リストの作成

ADF Faces Coreには、リストから単一値および複数値を選択するコンポーネントが含まれています。たとえば、selectOneChoiceを使用するとドロップダウン・リストから項目を1つ選択でき、selectManyChoiceを使用するとチェック・ボックスのリストから項目を複数選択できます。表7-1で、選択リスト・コンポーネントについて説明します。

表7-1 ADF Facesの単一選択および複数選択リスト・コンポーネント

ADF Facesコンポーネント

説明

例

SelectOneChoice

項目のリストから単一値を選択します。

SelectOneRadio

ラジオ・ボタンのセットから単一値を選択します。

SelectOneListbox

スクロール可能な項目のリストから単一値を選択します。

SelectManyChoice

スクロール可能なチェック・ボックスのリストから複数値を選択します。リストの最上位に、選択した項目の名前が表示されます。

SelectManyCheckbox

チェック・ボックスのグループから複数値を選択します。

SelectManyListbox

スクロール可能なチェック・ボックスのリストから複数値を選択します。

SelectOneChoice ADF Facesコンポーネントを使用して、選択リストを作成できます。作成の手順は、SelectOneRadioやSelectOneListboxのような他の単一値選択リストを作成する場合でも同様です。

データバインドされた選択リストは、アクセッサ戻りコレクションまたは静的リストの値を表示し、ユーザーの選択に基づいて別のコレクションの属性またはメソッド・パラメータを更新します。リストにバインディングを追加する場合は、リストで選択した値に基づいてデータが移入されるデータ・コントロールの属性を使用します。

注意:

selectOneChoiceコンポーネントでvaluePassThru=trueを指定して、ADFモデルのリスト・バインディングを使用することはサポートされていません。リスト・バインディングは、値ではなく索引を戻します。

選択リストを作成するには、「リスト・バインディングの編集」ダイアログでベース・データソースとリスト・データソースを選択します。

- ベース・データソース: ユーザーの選択に応じて更新される属性を含むアクセッサ戻りコレクションを選択します。これがコントロールにバインドされます。

- リスト・データソース: 表示する属性を含むアクセッサ戻りコレクションを選択します。

「リスト・バインディングの編集」ダイアログでは、次の2種類の選択リストを作成できます。

- 静的リスト: リストの選択は、エディタに1つずつ値を入力して手動で作成した固定リストに基づいています。

- 動的リスト: リストの選択肢は、1つ以上のデータバインドされた属性値に基づいて動的に生成されます。

7.2.1 固定値を含む単一選択リストの作成方法

他のデータソースから値を取得するのではなく、ユーザーが独自にコーディングした選択肢を含む選択リストを作成できます。

図7-1 固定の値リストにバインドされた選択リスト

始める前に:

固定リストとしてコンポーネントに組み込む値リストを準備します。

固定の値リストにバインドされたリストを作成する手順:

1. 「データ・コントロール」パネルから、属性をJSFページにドラッグ・アンド・ドロップし、「作成」→「単一選択」→「ADF選択肢を1つ選択」を選択します。
「リスト・バインディングの編集」ダイアログが表示されます。JSFページにドロップした属性を含むアクセッサ戻りコレクションが「ベース・データソース」リストでデフォルトで選択されています。

別のアクセッサ戻りコレクションを選択するには、リストの横にある「追加」アイコンをクリックします。

2. 「固定リスト」ラジオ・ボタンを選択します。
「固定リスト」オプションを使用すると、定義済の静的リストからエンド・ユーザーが値を選択できます。

3. 「ベース・データソース属性」リストで、属性を選択します。
「ベース・データソース属性」リストには、「ベース・データソース」リストで選択したコレクションのすべての属性が含まれています。

4. 「一連の値」ボックスで、リストに表示するそれぞれの値を入力します。[Enter]キーを押して値を設定してから、次の値を入力します。たとえば、支払タイプにATMおよびcheckを追加できます。
値を入力する順序は、実行時にSelectOneChoiceコントロールにリスト項目が表示される順序です。

SelectOneChoiceコンポーネントではnull値がサポートされています。このため、ユーザーが項目を選択しない場合、その項目のラベルがブランクとして表示され、コンポーネントの値がデフォルトで空の文字列に設定されます。ブランクまたは空の文字列を使用せずに、null値を表す文字列を指定できます。デフォルトでは、リストの先頭に新しい文字列が表示されます。

5. 「OK」をクリックします。

7.2.2 動的に生成される値を含む単一選択リストの作成方法

実行時に、選択リスト・コンポーネントに動的に値を移入できます。

始める前に:

2つのデータソースを定義します。1つは動的な値リストを提供するリスト・データソース用、もう1つはユーザーの選択に基づいて更新されるベース・データソース用です。

動的に生成される値を含むバインドされた選択リストを作成する手順:

1. 「データ・コントロール」パネルから、属性をJSFページにドラッグ・アンド・ドロップし、「作成」→「単一選択」→「ADF選択肢を1つ選択」を選択します。
「リスト・バインディングの編集」ダイアログが表示されます。JSFページにドロップした属性を含むアクセッサ戻りコレクションが「ベース・データソース」リストでデフォルトで選択されています。

別のアクセッサ戻りコレクションを選択するには、リストの横にある「追加」アイコンをクリックします。

2. 「動的リスト」ラジオ・ボタンを選択します。
「動的リスト」オプションを使用すると、別のバインド値セットから更新される1つ以上のベース・データソース属性を指定できます。

3. 「リスト・データソース」の横にある「追加」ボタンをクリックします。

4. 「データソースの追加」ダイアログで、選択リストに値を移入するアクセッサ戻りコレクションを選択します。

注意:

リスト・コレクションとベース・コレクションはマスター/ディテール関係になっている必要はありませんが、リスト・コレクション内の属性のタイプはベース・コレクション属性と同じである必要があります。

5. デフォルトのイテレータ名のままにして、「OK」をクリックします。
「リスト・バインディングの編集」ダイアログの「データ・マッピング」セクションが、デフォルトのデータ値およびリスト属性で更新されます。「データ値」コントロールには、選択リストでユーザーが項目を選択すると更新される、アクセッサ戻りコレクションの属性が含まれます。「リスト属性」コントロールには、選択リストに値を移入する属性が含まれます。

6. デフォルト・マッピングのままにするか、「データ値」リストおよび「リスト属性」リストから別の属性項目を選択して、マッピングを更新できます。
2番目のマッピングを追加するには、「追加」をクリックします。

7. 「OK」をクリックします。

7.2.3 固定選択リストの作成時の処理

固定選択リストを追加すると、JSFページにソース・コードが追加され、ページ定義ファイルにリスト・バインディング・オブジェクトとイテレータ・バインディング・オブジェクトが追加されます。

例7-1に、固定SelectOneChoiceコンポーネントを追加した後のページのソース・コードを示します。

例7-1 JSFページのソース・コード内の固定SelectOneChoiceリスト

<af:selectOneChoice value="#{bindings.paymentType.inputValue}"
label="#{bindings.paymentType.label}"
required="#{bindings.paymentType.hints.mandatory}"
shortDesc="#{bindings.paymentType.hints.tooltip}" id="soc1">
<f:selectItems  value="#{bindings.paymentType.items}" id="si1"/>
</af:selectOneChoice>

選択項目のリストを提供するためのf:selectItemsタグは、バインディング・コンテナ内のpaymentTypeリスト・バインディング・オブジェクトのitemsプロパティにバインドされています。

JDeveloperにより、ページ定義ファイルのexecutables要素内にイテレータ・バインディング・オブジェクトの定義が、bindings要素内にリスト・バインディング・オブジェクトの定義が追加されます(例7-2を参照)。

例7-2 ページ定義ファイル内の固定選択リストに対するリスト・バインディング・オブジェクト

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="customerFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Customer" id="customerFindAllIterator"/>
<accessorIterator MasterBinding="customerFindAllIterator"
Binds="SOrdList" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Ord"   id="SOrdListIterator"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator1"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator1"
Binds="empFindAll" RangeSize="-1"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Emp" id="empFindAllIterator"/>
</executables>
<bindings>
<list IterBinding="SOrdListIterator" id="paymentType" DTSupportsMRU="true"
StaticList="true">
<AttrNames>
<Item Value="paymentType"/>
</AttrNames>
<ValueList>
<Item Value="CASH"/>
<Item Value="CREDIT"/>
</ValueList>
</list>
</bindings>

7.2.4 動的選択リストの作成時の処理

動的選択リストをページに追加すると、JSFページにソース・コードが追加され、ページ定義ファイルにリスト・バインディング・オブジェクトとイテレータ・バインディング・オブジェクトが追加されます。

例7-3に、動的SelectOneChoiceコンポーネントを追加した後のページのソース・コードを示します。

例7-3 JSFページのソース・コード内の動的SelectOneChoiceリスト

<af:selectOneChoice value="#{bindings.salesRepId.inputValue}"
label="#{bindings.salesRepId.label}"
required="#{bindings.salesRepId.hints.mandatory}"
shortDesc="#{bindings.salesRepId.hints.tooltip}" id="soc2">
<f:selectItems value="#{bindings.salesRepId.items}" id="si2"/>
</af:selectOneChoice>

選択項目のリストを提供するためのf:selectItemsタグは、バインディング・コンテナ内のsalesRepIdリスト・バインディング・オブジェクトのitemsプロパティにバインドされています。

ページ定義ファイルでは、executables要素内にイテレータ・バインディング・オブジェクトの定義が追加され、bindings要素内にリスト・バインディング・オブジェクトの定義が追加されます(図7-1を参照)。

例7-4 ページ定義ファイル内の動的選択リストに対するリスト・バインディング・オブジェクト

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="customerFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Customer" id="customerFindAllIterator"/>
<accessorIterator MasterBinding="customerFindAllIterator"
Binds="SOrdList" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Ord"   id="SOrdListIterator"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator1"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator1"
Binds="empFindAll" RangeSize="-1"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Emp" id="empFindAllIterator"/>
</executables>
</bindings>
<list IterBinding="SOrdListIterator" id="salesRepId" DTSupportsMRU="true"
StaticList="false"
ListIter="empFindAllIterator">
<AttrNames>
<Item Value="salesRepId"/>
</AttrNames>
<ListAttrNames>
<Item Value="id"/>
</ListAttrNames>
<ListDisplayAttrNames>
<Item Value="firstName"/>
<Item Value="lastName"/>
</ListDisplayAttrNames>
</list>
</bindings>

AttrNames要素は、ベース・イテレータにより戻されるベース・データソース属性を指定します。ListAttrNames要素は、ベース・データソース属性にマッピングされるリスト・データソース属性を定義します。ListDisplayAttrNames要素は、実行時にユーザーに表示される値をリストに移入するリスト・データソース属性を指定します。

7.3 ナビゲーション・リスト・バインディングを持つリストの作成

ナビゲーション・リスト・バインディングを使用して、ユーザーがコレクション内のオブジェクトを移動できるようにします。ユーザーがナビゲーション・リスト・コンポーネントを使用して現在のオブジェクト選択を変更すると、属性を介して同じコレクションにバインドされている他のコンポーネントも、新しく選択したオブジェクトから表示されます。

また、コレクションの現在の行を変更したときに、そのコレクションがデータ・モデルのマスター/ディテール関係におけるマスター・コレクションである場合、ディテール・コレクションの行セットが自動的に更新され、新規の現在のマスター行に適したデータが表示されます。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成します。

ナビゲーション・リスト・バインディングを使用するリストの作成手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションをページにドラッグ・アンド・ドロップし、「作成」→「移動」→「ADFナビゲーション・リスト」を選択します。

2. 「リスト・バインディングの編集」ダイアログの「ベース・データソース」ドロップダウン・リストからコレクションを選択します。このコレクションのメンバーがリストの作成に使用されます。
これは、「データ・コントロール」パネルからドラッグしたコレクションです。そのコレクションがドロップダウン・メニューに表示されない場合は、「追加」ボタンをクリックして目的のコレクションを選択します。

3. 「属性の表示」ドロップダウン・リストから、属性を1つまたはすべて選択するか、「複数の選択」を選択して選択ダイアログを開きます。
「複数の表示属性の選択」ダイアログで、表示する属性を「使用可能な属性」ペインから「表示する属性」ペインに移動します。「OK」をクリックして、ダイアログを閉じます。

4. 「OK」をクリックします。

8 データバインドされた検索フォームの作成

この章では、複数の属性に対する複雑な検索および単一属性への検索を行う検索フォームの作成方法について説明します。複雑な問合せ検索フォームについては、問合せ検索フォーム・モードの設定方法、結果表、保存済みの検索リスト、およびパーソナライズについて説明します。単一属性検索フォームについては、フォーム・レイアウトの構成方法を説明します。さらに、Query-by-Example (QBE)に基づいてフィルタ処理された表の検索についても触れます。

この章には、次の項が含まれます:

- 8.1項「検索フォームの作成の概要」

- 8.2項「問合せ検索フォームの作成」

- 8.3項「検索フォーム・プロパティの設定」

- 8.4項「クイック問合せ検索フォームの作成」

- 8.5項「スタンドアロンのフィルタ処理された検索表の作成」

8.1 検索フォームの作成の概要

開発者は、オブジェクトの既知の属性に基づいてユーザーが検索基準を入力フィールドに入力することのできる検索フォームを作成できます。検索基準は入力テキスト・フィールドに入力するか、ポップアップ・リスト・ピッカーまたはドロップダウン・リスト・ボックスの値リストから選択できます。入力した基準は実行する問合せに組み込まれます。問合せの結果は、表、フォームまたは別のUIコンポーネントとして表示できます。

検索フォームは、再利用およびパーソナライズが可能なリージョン・ベースのコンポーネントです。また、問合せの実行に必要な多くのアクションおよびイテレータ管理操作をカプセル化および自動化します。イテレータの変更および新しいイテレータの作成を行わずに、同一ページに複数の検索フォームを作成できます。

検索フォームは、モデルドリブンのaf:queryおよびaf:quickQueryコンポーネントに基づいています。これらの基礎となるコンポーネントはモデルドリブンであるため、検索フォームはモデルの変更を反映するよう自動的に変更されます。ビュー・レイヤーは変更する必要がありません。

問合せ検索フォームは完全な機能を備えた検索フォームです。クイック問合せ検索フォームは、検索基準が1つしかない簡略化されたフォームです。どちらの検索フォームもフィルタ処理された表と組み合せて結果を表示できるため、検索機能をさらに追加することが可能です。スタンドアロンのフィルタ処理された表を作成し、問合せ検索パネルまたはクイック問合せ検索パネルを使用せずに検索を実行することもできます。

フィルタ処理された表は、それぞれの検索可能列の上に追加のQuery-by-Example(QBE)検索基準フィールドを持つ表です。表のフィルタ処理オプションが有効になっている場合、各列にQBE形式の検索基準を入力して、問合せ結果をフィルタ処理できます。

個々の問合せコンポーネントおよび表コンポーネントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」および「表およびツリーの使用」を参照してください。

8.1.1 問合せ検索フォーム

問合せ検索フォームは、複雑なトランザクション検索を行うための標準フォームです。複数の検索基準フィールド(それぞれが組込み演算子のドロップダウン・リストを持つ)がある複雑な検索フォームを作成できます。また、カスタム演算子を追加してリストをカスタマイズすることもできます。問合せ検索フォームでは、値リスト、AND結合とOR結合、および将来使用するための検索の保存がサポートされています。

問合せ検索フォームには基本モードと詳細モードがあります。ユーザーは「基本」ボタンまたは「詳細」ボタンを使用して、2つのモードを切り替えることができます。設計時にフォーム・プロパティを宣言的に指定(デフォルトの状態を設定するなど)して、基本または詳細のいずれかにすることができます。図8-1に、3つの検索基準を含む詳細モードの問合せ検索フォームを示します。

図8-1 3つの検索基準フィールドを含む詳細モードの問合せ検索フォーム

詳細モードの問合せフォームに含まれる機能は次のとおりです。

- ドロップダウン・リストからの検索基準演算子の選択

- カスタム演算子の追加と標準演算子の削除

- WHERE句の結合におけるANDまたはOR(すべてに一致またはいずれかに一致)の選択

- 実行時の検索基準フィールドの動的な追加および削除

- 将来使用するための検索の保存

- 保存済の検索のパーソナライズ

通常、問合せ検索フォームはいずれかのモードで、関連付けられた結果表またはツリー表とともに使用します。たとえば、図8-1の検索フォームの問合せ結果は、図8-2に示すように、表に表示されます。

図8-2 問合せ検索の結果表

基本モードには、ユーザーによる動的な検索基準フィールドの追加以外の詳細モードのすべての機能が含まれます。図8-3に、3つの検索基準フィールドを含む基本モードの問合せ検索フォームを示します。詳細モードで検索基準フィールドの追加に使用される、「保存」ボタンの隣のドロップダウン・リストがないことに注意してください。

図8-3 3つの検索基準フィールドを含む基本モードの問合せフォーム

どちらのモードでも、Greater ThanおよびEqual Toなどの演算子をドロップダウン・リストから選択して各検索基準フィールドを変更できます。また、「すべてに一致」または「いずれかに一致」ラジオ・ボタンを使用して検索パネル全体を変更できます。検索フォームでは、ほとんどすべての状況下で部分ページ・レンダリングもサポートされています。たとえば、「Between」演算子を選択した場合、別の入力フィールドが表示され、範囲の上限を選択できるようになります。

「すべてに一致」を選択すると、問合せのWHERE句の検索基準において暗黙的にAND結合が使用されます。「いずれかに一致」を選択すると、問合せのWHERE句において暗黙的にOR結合が使用されます。例8-1に、図8-1に示した検索基準において「すべてに一致」を選択した場合、簡略化されたWHERE句がどのように表示されるかを示します(ビュー基準の実際のWHERE句は異なります)。

例8-1 「すべてに一致」を選択した場合の簡略化されたWHERE句

WHERE (OrderId=4) AND (Quantity < 50) AND (Price > 100)

例8-2に、図8-3に示した検索基準において「いずれかに一致」を選択した場合、簡略化されたWHERE句がどのように表示されるかを示します。

例8-2 「いずれかに一致」を選択した場合の簡略化されたWHERE句

WHERE (orderId=4) OR (Quantity = 20) OR (Price > 100)

詳細モードの問合せフォームでは、より複雑な問合せを実行するために、ユーザーは問合せパネルに検索基準フィールドを動的に追加できます。ユーザーが作成した検索基準フィールドは削除できますが、ユーザーは既存のフィールドを削除できません。図8-4に、CategoryId基準フィールドを検索フォームに追加するために、「フィールドの追加」ドロップダウン・リストをどのように使用するかを示します。

図8-4 実行時の検索基準フィールドの動的な追加

図8-5に、ユーザー追加の検索基準を示します。その右側には削除アイコンがあります。削除アイコンをクリックすると条件を削除できます。

図8-5 削除アイコンがあるユーザー追加の検索基準

「すべてに一致」または「いずれかに一致」が選択されている場合に、ユーザーが検索基準の2つ目のインスタンスを動的に追加すると、「すべてに一致」と「いずれかに一致」はともに選択解除されます。ユーザーは、「検索」ボタンをクリックする前に、「すべてに一致」または「いずれかに一致」を再度選択する必要があります。

問合せ検索フォームに基本モードおよび詳細モードの両方を使用する場合、各検索基準フィールドは、基本モードのみでの表示、詳細モードのみでの表示、両方での表示のいずれかに定義できます。ユーザーがあるモードから別のモードに切り替えると、そのモードに定義された検索基準フィールドのみが表示されます。たとえば、基本モード用にA、B、Cの3つの検索フィールドを、詳細モード用にA、B、Dの3つの検索フィールドを問合せに定義したとします。問合せ検索フォームが基本モードの場合、検索基準フィールドA、B、Cが表示されます。問合せ検索フォームが詳細モードの場合、検索基準フィールドA、B、Dが表示されます。その検索フィールドに入力されたすべての検索データは、フォームがそのモードに戻ったときも保持されています。基本モードにおいてユーザーが検索フィールドCに35と入力し、詳細モードに切り替えた後に再度基本モードに戻ると、フィールドCには値35が入力された状態で再表示されます。

基本または詳細モードを使用するとともに、検索フォームをどの程度表示するかを決定することもできます。デフォルト設定では、フォーム全体が表示されます。圧縮モードまたはシンプル・モードで表示するように、問合せコンポーネントを構成することもできます。圧縮モードでは、ヘッダーや境界線がなく、「保存済の検索」ドロップダウン・リストは開く/閉じるアイコンの横に移動しています。図8-6に、圧縮モードに設定された問合せコンポーネントを示します。

図8-6 コンパクト・モードのqueryコンポーネント

シンプル・モードでは、ヘッダーおよびフッターがなく、通常その領域に表示されるボタンもないコンポーネントが表示されます。図8-7に、シンプル・モードに設定された同じ問合せコンポーネントを示します。

図8-7 簡易モードのqueryコンポーネント

ユーザーは、検索の状態を将来使用するために、実行時に保存済の検索を作成することもできます。図8-8に示すように、「保存」ボタンをクリックして「検索の保存」ダイアログを開き、入力された検索基準値、基本モードまたは詳細モードの状態、結果の表またはコンポーネントのレイアウトを保存できます。ユーザーが作成した保存済の検索はセッション内で保持されます。保存済の検索を、セッションを超えて使用できるようにするには、保存済の検索を格納するための永続データ・ストアを構成する必要があります。Oracle ADFでは、アクセス制御の対象となるデータソース(MDSなど)を使用できます。MDSの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

図8-8 実行時の「保存済の検索」ダイアログ・ウィンドウ

表8-1に、保存済の検索、その作成方式および可用性のシナリオを作成者別に示します。

表8-1 設計時および実行時の保存済の検索

作成者

設計時にビュー基準として作成

実行時に「保存」ボタンを使用して作成

開発者

開発者による保存済の検索(システム検索)は、アプリケーション開発時に作成され、通常はソフトウェア・リリースの一部に含まれます。これらの検索は、設計時にビュー基準として作成されます。通常、アプリケーションのすべてのユーザーが利用可能であり、「保存済の検索」ドロップダウン・リストの下部に表示されます。

管理者

管理者による保存済の検索は、デプロイ前にサイト管理者が作成します。これらの検索は、サイトを一般のエンド・ユーザーが利用可能になる前に作成されます。管理者は、設計時に適切なロールでログインしてJDeveloperを使用し、保存済の検索(またはビュー基準)を作成できます。これらの保存済の検索(またはビュー基準)は、「保存済の検索」ドロップダウン・リストの下部に表示されます。

エンド・ユーザー

エンド・ユーザーによる保存済の検索は、実行時に問合せフォームの「保存」ボタンを使用して作成します。これらの検索は、作成したユーザーのみが利用可能です。エンド・ユーザーの保存済の検索は、「保存済の検索」ドロップダウン・リストの最上部に表示されます。

図8-9に示すように、エンド・ユーザーは「保存済の検索」ドロップダウン・リストの「パーソナライズ」機能を使用して「保存済の検索のパーソナライズ」ダイアログを表示し、保存済の検索を管理できます。

エンド・ユーザーは、「パーソナライズ」機能を使用して次の操作を実行できます。

- ユーザー作成の保存済の検索の更新

- ユーザー作成の保存済の検索の削除

- 保存済の検索のデフォルトとしての設定

- 保存済の検索の自動実行の設定

- 「保存済の検索」ドロップダウン・リストでの保存済の検索の表示または非表示の設定

図8-9 「保存済の検索のパーソナライズ」ダイアログ

8.1.2 クイック問合せ検索フォーム

クイック問合せ検索フォームは、単一検索で十分な場合、またはフル問合せ検索を行うための起点とする場合に使用します。問合せ検索フォームおよびクイック問合せ検索フォームはどちらもADF Facesコンポーネントです。クイック問合せ検索フォームには、関連するデータ・コレクションから利用可能な検索可能属性のドロップダウン・リストとともに検索基準フィールドが1つ含まれます。通常は、関連するビュー・コレクションのすべての属性が検索可能属性となります。ユーザーは、選択された属性または表示されるすべての属性に対して検索を実行できます。検索基準フィールド・タイプは対応する属性タイプに自動的に一致します。フォームに組み込まれた「詳細」リンクを使用すると、開発者はクイック問合せ検索フォームから詳細モードの問合せ検索フォームへの切替えを制御するマネージドBeanを作成できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。

図8-10に示すように、フォームが水平方向レイアウトとなるように構成できます。

図8-10 水平方向レイアウトのクイック問合せ検索フォーム

図8-11に示すように、垂直方向レイアウトも選択できます。

図8-11 垂直方向レイアウトのクイック問合せ検索フォーム

8.1.3 フィルタ処理された表とQuery-by-Example検索

フィルタ処理された表はスタンドアロンとして作成することも、問合せ検索フォームまたはクイック問合せ検索フォームの結果表として作成することもできます。フィルタ処理された表の検索はQuery-by-Exampleに基づいており、QBEテキストまたは日付入力フィールド書式を使用します。検索条件を変更するための>および<=などの文字の入力を可能にするため、入力バリデータは無効化されています。たとえば、数値列の検索条件として>1500を入力できます。ワイルドカード文字もサポートされています。列でQBEがサポートされていない場合、検索条件入力フィールドはその列にレンダリングされません。

フィルタ処理された表の検索基準入力値は、問合せのWHERE句を作成するためにAND演算子とともに使用されます。フィルタ処理された表が問合せ検索パネルまたはクイック問合せ検索パネルと関連付けられている場合、複合検索基準値も組み合せてWHERE句を作成します。

図8-12に、フィルタ処理された結果表を含む問合せ検索フォームを示します。idフィールドに>200など、ユーザーがQBE検索基準を入力すると、問合せの結果は、問合せ検索基準とフィルタ処理された表の検索基準のAND結合となります。

図8-12 フィルタ処理された表を含む問合せ検索フォーム

表8-2に、検索値を変更するために使用可能なQBE検索演算子を示します。

表8-2 Query-by-Example検索基準演算子

演算子

説明

>

次より大きい

<

次より小さい

>=

次より大きいか等しい

<=

次より小さいか等しい

AND

および

OR

または

8.2 問合せ検索フォームの作成

問合せ検索フォームは、名前付き基準を「データ・コントロール」パネルからページにドロップして作成します。ドロップするものとして、検索パネルのみ、検索パネルと結果表、検索パネルとツリー表のいずれかを選択できます。

検索パネルを表とともにドロップすることにした場合、ダイアログでフィルタ処理オプションを選択し、表をフィルタ処理された表にすることができます。

通常は、問合せ検索パネルとともに結果表またはツリー表をドロップします。Jdeveloperでは、結果表またはツリー表が自動的に作成され、問合せパネルと関連付けられます。

問合せパネルのみをドロップし、結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、問合せパネルのResultsComponentIdと結果コンポーネントのIdを一致させる必要があります。

8.2.1 結果表またはツリー表付きの問合せ検索フォームの作成方法

検索フォームは、名前付き基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップして作成します。結果表付きとするか、問合せパネルのみとするかを選択できます。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成しておく必要があります。

結果表またはツリー表付きの問合せ検索フォームを作成する手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションを選択し、「名前付き基準」ノードを展開して名前付き基準のリストを表示します。

2. 名前付き基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

注意:

「すべての問合せ可能な属性」をページにドロップすると、検索フォームと、基礎となるコレクションで定義した検索可能属性のそれぞれに対応する検索基準フィールドが作成されます。それらの属性のうちの一部についてのみ検索基準フィールドを作成する場合、必要な属性の名前付き基準を作成します。

3. 図8-13に示すように、ポップアップ・メニューから、「作成」→「問合せ」→「表付きADF問合せパネル」または「作成」→「問合せ」→「ツリー表付きADF問合せパネル」を選択します。

図8-13 「データ・コントロール」パネルの「問合せ」ポップアップ・メニュー

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。

フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。これを行う方法の詳細は、8.3項「検索フォーム・プロパティの設定」を参照してください。

8.2.2 問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

検索フォームは、名前付き基準を「データ・コントロール」パネルからページにドラッグ・アンド・ドロップして作成します。結果表付きとするか、問合せパネルのみとするかを選択できます。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成しておく必要があります。

問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加する手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションを選択し、「名前付き基準」ノードを展開して名前付き基準のリストを表示します。

2. 名前付き基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

注意:

「すべての問合せ可能な属性」をページにドロップすると、検索フォームと、基礎となるコレクションで定義した検索可能属性のそれぞれに対応する検索基準フィールドが作成されます。それらの属性のうちの一部についてのみ検索基準フィールドを作成する場合、必要な属性の名前付き基準を作成します。

3. 図8-13に示すように、ポップアップ・メニューから「作成」→「問合せ」→「ADF問合せパネル」を選択します。

4. まだ結果コンポーネントがない場合は、アクセッサ戻りコレクションをドラッグし、表、ツリー、ツリー表のいずれかのコンポーネントとしてページにドロップします。

5. 表のプロパティ・インスペクタで、「ID」フィールドの値をコピーします。

6. 問合せパネルのプロパティ・インスペクタで、表のIDの値を問合せの「ResultsComponentId」フィールドに貼り付けます。

検索フォームの作成後、一部のプロパティの設定やカスタム機能の追加が可能です。詳細は、8.3項「検索フォーム・プロパティの設定」を参照してください。

8.2.3 保存済の検索をMDSに保存する方法

保存済の検索をMDSに保存するには、adf-config.xmlファイルに/persdefネームスペースを定義する必要があります。また、metadatapathの指定など、通常のMDS構成を行うことも必要です。例8-3に、/persdefネームスペースを定義したadf-config.xmlファイルを示します。

例8-3 /persdefネームスペースを定義したadf-config.xmlの例

<persistence-config>
<metadata-namespaces>
<namespace path="/persdef" metadata-store-usage="mdsstore"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="mdsstore" deploy-target="true"
default-cust-store="true"/>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>

追加した保存済の検索をユーザーが次にログインしたときに使用できるようにするには、cust-configをMDS構成の一部として定義する必要があります。cust-configとMDSの設定の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のカスタマイズ・クラスの作成方法に関する項を参照してください。

結果コンポーネントのレイアウトも保存する場合は、アプリケーションにADF PageFlow RuntimeライブラリとADF Controller Runtimeライブラリをインストールしておく必要があります。プロジェクトのテクノロジ・スコープに「ADFページ・フロー」が含まれるように設定します。

8.2.4 問合せフォーム作成時の処理

問合せ検索フォームをページにドロップすると、ページにaf:queryタグが作成されます。問合せと表またはツリー表をドロップした場合、af:queryタグの後にaf:tableタグまたはaf:treeTableタグが続きます。

af:queryタグの下には問合せのプロパティを定義する複数の属性があります。属性には、次のものが含まれます。

- 問合せを一意に識別するid属性。

- 問合せ結果が表示されるコンポーネントを識別するresultsComponentId属性。通常、これは問合せとともにページにドロップされた表またはツリー表です。この値は、別の結果コンポーネントのidに変更できます。詳細は、8.2.2項「問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。

ページ定義ファイルのexecutablesセクションに、iterator、accessorIteratorおよびsearchRegionエントリが作成されます。例8-4に、ページ定義ファイルのサンプル・コードを示します。

ページ定義ファイルのexecutableセクションでは、プロパティが次のように設定されます。

- iteratorのRangeSizeプロパティは、デフォルト値の25に設定されます。異なるページ・サイズが必要な場合は、この値を編集する必要があります。

- iteratorのidプロパティは、ルート・イテレータに設定されます。この例では、値がOrdersSessionEJBLocalIteratorに設定されています。

- accessorIteratorのBindsプロパティは、アクセッサに設定されます。この例では、値がitemFindAllに設定されています。

- accessorIteratorのidプロパティは、アクセッサ・イテレータに設定されます。この例では、値がitemFindAllIteratorに設定されています。

- searchRegionのCriteriaプロパティは、ItemCriteriaに設定されます。

- searchRegionのBindsプロパティは、検索イテレータに設定されます。この例では、値がitemFindAllIteratorに設定されています。

- searchRegionのidプロパティは、ItemCriteriaQueryに設定されます。

問合せを表またはツリーとともにページにドロップした場合は、ページ定義ファイルのbindingsセクションにtree要素が追加され、Iterbindingプロパティが検索イテレータに設定されます。この例では、値がitemFindAllIteratorに設定されています。

例 8-4 ページ定義ファイルの検索フォーム・コード

<executables>
<variableIterator id="variables"/>
<iterator Binds="root" RangeSize="25" DataControl="OrdersSessionEJBLocal"
id="OrdersSessionEJBLocalIterator"/>
<accessorIterator MasterBinding="OrdersSessionEJBLocalIterator"
Binds="itemFindAll" RangeSize="25"
DataControl="OrdersSessionEJBLocal"
BeanClass="model.Item"
id="itemFindAllIterator"/>
<searchRegion Criteria="ItemCriteria"
Customizer="oracle.jbo.uicli.binding.JUSearchBindingCustomizer"
Binds="itemFindAllIterator"
id="ItemCriteriaQuery"/>
</executables>
<bindings>
<tree IterBinding="itemFindAllIterator" id="itemFindAll">
<nodeDefinition DefName="model.Item">
<AttrNames>
<Item Value="itemId"/>
<Item Value="ordId"/>
<Item Value="price"/>
<Item Value="quantity"/>
<Item Value="quantityShipped"/>
</AttrNames>
</nodeDefinition>
</tree>
</bindings>

8.2.5 実行時に行われる処理: 検索フォーム

実行時には、検索フォームはページ上の検索パネルとして表示されます。検索パネルは、基本モードまたは詳細モードで表示されます。

ユーザーが検索基準を入力して「検索」をクリックすると、問合せが実行され、関連付けられた表、ツリー表またはコンポーネントに結果が表示されます。

8.3 検索フォーム・プロパティの設定

問合せコンポーネントがJSFページに追加された後に設定可能な検索フォーム・プロパティは、次のとおりです。

- 結果表または結果コンポーネントのid

- 「基本」ボタンまたは「詳細」ボタンの表示または非表示

- モード・ボタンの位置

- デフォルト、シンプルまたは圧縮の表示モード

8.3.1 問合せコンポーネントに検索フォーム・プロパティを設定する方法

図8-14に示すように、問合せ検索フォームをページにドロップした後に、プロパティ・インスペクタで他のフォーム・プロパティを編集できます。次のような共通プロパティを設定できます。

- 「基本」または「詳細」モード・ボタンの有効化または無効化

- 問合せ検索フォームのIDの設定

- 結果表などの結果コンポーネントのIDの設定

- デフォルト、シンプルまたは圧縮の表示モードの選択

図8-14 「問合せ」コンポーネントのプロパティ・インスペクタ

一般的なオプションの1つに、「基本」または「詳細」ボタンの表示または非表示があります。

問合せフォームで「基本」または「詳細」ボタンを有効化または非表示にする手順:

1. 構造ウィンドウで「af:query」をダブルクリックします。

2. プロパティ・インスペクタで「外観」タブをクリックします。

3. 「基本」または「詳細」モード・ボタンを有効化するには、「ModeChangeVisible」フィールドで「true」を選択します。「基本」または「詳細」モード・ボタンを非表示するには、「ModeChangeVisible」フィールドで「false」を選択します。

8.4 クイック問合せ検索フォームの作成

クイック問合せ検索フォームを使用すると、ユーザーによるコレクションの単一属性の検索が可能になります。クイック問合せ検索フォームのレイアウトは、水平または垂直に設定できます。クイック問合せ検索フォームは小さい領域のみを使用するため、ページの様々な領域に配置できます。ユーザーによるクイック問合せ検索からフル問合せ検索への切替えを可能にするマネージドBeanを作成できます。マネージドBeanを使用したクイック問合せから問合せへの切替えの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。

結果表またはツリーとともにクイック問合せパネルをドロップした場合、8.4.1項「結果表またはツリー表付きのクイック問合せ検索フォームの作成方法」で説明されているとおり、JDeveloperにより自動的に結果表が作成されます。クイック問合せパネルのみをドロップした後に結果表または結果コンポーネントが必要な場合、または結果を表示するコンポーネントがすでに存在する場合、8.4.2項「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」で説明されているとおり、クイック問合せのIdと結果コンポーネントのpartialTrigger値を一致させる必要があります。

8.4.1 結果表またはツリー表付きのクイック問合せ検索フォームの作成方法

検索可能な属性の完全セットを使用してクイック問合せ検索を作成すると同時に、表またはツリー表を結果コンポーネントとして追加できます。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成します。

結果表付きのクイック問合せ検索フォームを作成する手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションを選択し、「名前付き基準」ノードを展開して名前付き基準のリストを表示します。

2. 名前付き基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. 図8-15に示すように、ポップアップ・メニューから、「作成」→「クイック問合せ」→「表付きADFクイック問合せ」または「作成」→「クイック問合せ」→「ツリー表付きADFクイック問合せ」を選択します。

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。フィルタ処理オプションを選択した場合、表はフィルタ処理された表になります。

図8-15 「データ・コントロール」パネルの「クイック問合せ」ポップアップ・メニュー

8.4.2 クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法

検索可能な属性の完全セットを使用してクイック問合せ検索を作成した後で、表またはツリー表を結果コンポーネントとして追加できます。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成します。

クイック問合せ検索フォームを作成し、別のステップで結果コンポーネントを追加する手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションを選択し、「名前付き基準」ノードを展開して名前付き基準のリストを表示します。

2. 名前付き基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. ポップアップ・メニューから、「作成」→「クイック問合せ」→「ADFクイック問合せパネル」を選択します。

4. まだ結果コンポーネントがない場合は、アクセッサ戻りコレクションをドラッグし、表、ツリー、ツリー表のいずれかのコンポーネントとしてページにドロップします。

5. クイック問合せのプロパティ・インスペクタで、「ID」フィールドの値をコピーします。

6. 結果コンポーネント(表など)のプロパティ・インスペクタで、値を「PartialTriggers」フィールドに貼り付けるか入力します。

8.4.3 クイック問合せのレイアウト書式を設定する方法

デフォルトのレイアウト書式は垂直方向です。プロパティ・インスペクタを使用して、レイアウト・オプションを変更できます。

レイアウトを設定する手順:

1. 構造ウィンドウで「af:quickQuery」をダブルクリックします。

2. プロパティ・インスペクタの「共通」ページで、ドロップダウン・リストから「レイアウト」プロパティを選択して、「デフォルト」、「水平方向」、「垂直」のいずれかを指定します。

8.4.4 クイック問合せ検索フォームの作成時の処理

クイック問合せ検索フォームをページにドロップすると、af:quickQueryタグが作成されます。クイック問合せと表またはツリー表をドロップした場合、af:tableタグまたはaf:treeTableタグも追加されます。

af:quickQueryタグの下にはクイック問合せのプロパティを定義する複数の属性およびファセットがあります。タグの一部は次のとおりです。

- クイック問合せを一意に識別するid属性。この値は結果表または結果コンポーネントのpartialTriggers値に一致するように設定する必要があります。クイック問合せと表またはツリー表をドロップすると、JDeveloperはこれらの値を自動的に割り当てます。別の結果コンポーネントに変更する方法は、8.4.2項「クイック問合せ検索フォームを作成した後で結果コンポーネントを追加する方法」を参照してください。

- クイック問合せのレイアウトをデフォルト、水平または垂直に指定するlayout属性。

- 「詳細」リンク(クイック問合せから問合せにモードを変更)の表示に使用するコンポーネントを指定するendファセット。この機能の作成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。

8.4.5 実行時に行われる処理: クイック問合せ

実行時に、クイック問合せ検索フォームには、単一の検索基準フィールドが選択可能な検索基準アイテムのドロップダウン・リストとともに表示されます。検索可能な基準アイテムが1つしかない場合、ドロップダウン・リスト・ボックスはレンダリングされません。表8-3に示すように、選択した検索基準タイプと互換性のある入力コンポーネントが表示されます。たとえば、検索基準タイプがDATEの場合、inputDateがレンダリングされます。

表8-3 クイック問合せ検索基準フィールド・コンポーネント

属性タイプ

レンダリングされるコンポーネント

DATE

af:inputDate

VARCHAR

af:inputText

NUMBER

af:inputNumberSpinBox

また、「検索」ボタンが入力フィールドの右側にレンダリングされます。endファセットを指定すると、endファセットのコンポーネントはすべて表示されます。デフォルトでは、endファセットには「詳細」リンクが含まれます。

8.5 スタンドアロンのフィルタ処理された検索表の作成

複雑な検索では問合せ検索フォームを使用しますが、フィルタ処理された表を使用して単純なQBE検索を実行することもできます。関連付けられた検索パネルのないスタンドアロンのADFのフィルタ処理された表を作成し、QBE形式の検索基準入力フィールドを使用して検索を実行できます。フィルタ処理された表の詳細は、8.1.3項「フィルタ処理された表とQuery-by-Example検索」を参照してください。

表の作成時に、フィルタ処理オプションが有効な場合にそのオプションを選択すると、ほとんどすべての表をフィルタ処理された表にできます。スタンドアロンのフィルタ処理された表を作成するには、次の3つの方法があります。

- コンポーネント・パレットからページに表をドロップし、データ・コレクションにバインドしてフィルタ処理オプションを設定できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「問合せコンポーネントの使用方法」を参照してください。

- アクセッサ戻りコレクションをページにドラッグ・アンド・ドロップしてフィルタ処理オプションを設定すると、フィルタ処理された表を作成できます。

- 「すべての問合せ可能な属性」または名前付き基準をページにドロップし、フィルタ処理された表または読取り専用のフィルタ処理された表を作成することもできます。作成されるフィルタ処理された表には、検索可能属性のそれぞれに対応する列があり、各列の上に入力検索フィールドがあります。

af:tableコンポーネントのaf:columnのfilterFeature属性を使用すると、フィルタ処理可能な各列のQBE検索基準において、大文字と小文字を区別するかどうかを設定できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表でのフィルタ処理の有効化に関する項を参照してください。

始める前に:

「データ・コントロール」パネルでアクセッサ戻りコレクションを作成します。

フィルタ処理された表を作成する手順:

1. 「データ・コントロール」パネルから、アクセッサ戻りコレクションを選択し、「名前付き基準」ノードを展開してすべての名前付き基準のリストを表示します。

2. 名前付き基準項目をドラッグし、ページまたは「構造」ウィンドウにドロップします。

3. ポップアップ・メニューから、「作成」→「表」→「ADFフィルタリング済表」または「作成」→「表」→「ADF読取り専用フィルタリング済表」を選択します。

4. 「表の列の編集」ダイアログでは、任意の列を並べ替えて表オプションを選択できます。表はクイック問合せの作成時に自動的に作成されるため、図8-16に示すように、フィルタ処理オプションは自動的に有効になり、ユーザーは選択できません。

図8-16 フィルタ処理された表の「表の列の編集」ダイアログ

9 ADF Java EEアプリケーションのデプロイ

この章では、ターゲット・アプリケーション・サーバーにOracle ADF Java EEアプリケーションをデプロイする方法を説明します。デプロイメント・プロファイルを作成する方法、デプロイメント・ディスクリプタを作成する方法、およびADFランタイム・ライブラリをロードする方法も説明します。アプリケーションを統合WebLogic Serverで実行する手順、およびスタンドアロンOracle WebLogic ServerまたはIBM WebSphere Application Serverにデプロイする手順についても説明します。

この章には、次の項が含まれます:

- 9.1項「ADF Java EE Webアプリケーションのデプロイの概要」

- 9.2項「統合WebLogic ServerでのJava EEアプリケーションの実行」

- 9.3項「アプリケーションの準備」

- 9.4項「アプリケーションのデプロイ」

- 9.5項「デプロイメント後の構成」

- 9.6項「アプリケーションのテストとデプロイの検証」

9.1 ADF Java EE Webアプリケーションのデプロイの概要

デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲット・アプリケーション・サーバーに転送するプロセスです。JDeveloperを使用して、Oracle ADF Java EE Webアプリケーションをアプリケーション・サーバー(Oracle WebLogic ServerやIBM WebSphere Application Serverなど)に直接デプロイすることも、または間接的に、つまりアーカイブ・ファイルをデプロイメント・ターゲットにしてまずそれにデプロイし、そのアーカイブ・ファイルを後からターゲット・サーバーにインストールすることもできます。アプリケーション開発の際には、JDeveloperを使用して、統合WebLogic Serverでアプリケーションを実行することもできます。JDeveloperは、サーバー・クラスタへのデプロイをサポートしています。JDeveloperを使用して、クラスタ内の個々の管理対象サーバーにデプロイすることはできません。

注意:

ADFアプリケーションをGlassFish Serverにデプロイする場合は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「GlassFishへのADFアプリケーションのデプロイ」およびOracle Fusion Middleware Oracle Application Development Framework管理者ガイドの「GlassFish Serverの構成」を参照してください。

図9-1に、デプロイ処理全体を説明したフロー・ダイアグラムを示します。ADFランタイムをインストールしてターゲット・アプリケーション・サーバーをデプロイ用に準備する手順は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』で説明されています。

次のダイアグラムには、クリック可能なリンクが含まれています。

図9-1 デプロイの概要フロー・ダイアグラム

「図9-1 デプロイの概要フロー・ダイアグラム」の説明

注意:

通常、JDeveloperは開発やテストの目的でアプリケーションをデプロイする場合に使用します。Oracle ADF Java EE Webアプリケーションを本番用にデプロイする場合は、Enterprise Managerまたはスクリプトを使用して、本番レベルのアプリケーション・サーバーにデプロイできます。

後期テスト環境や本番環境へのデプロイの詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

ADF Java EEアプリケーションは、標準化されたモジュール型コンポーネントに基づいており、次のアプリケーション・サーバーにデプロイできます。

- Oracle WebLogic Server
Oracle WebLogic Serverは、そうしたモジュール用のサービス一式を備えており、細かいアプリケーション動作の多くを自動的に処理するため、プログラミングは必要ありません。JDeveloperと互換性のあるOracle WebLogic Serverのバージョンについては、認定情報のWebサイト(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html)を参照してください。

- IBM WebSphereアプリケーション・サーバー
互換性のあるIBM WebSphereのバージョンについては、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。

ADF Facesコンポーネントを含むJSFアプリケーションには、次の追加デプロイ要件があります。

- ADF Facesには、SunのJSF Reference Implementation 1.2およびMyFaces 1.0.8(またはそれ以降)が必要です。

JDeveloperを使用して、次の作業を実行できます。

- 統合WebLogic Serverでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、その後スタンドアロンのWebLogic ServerまたはWebSphereにデプロイできます。

統合IBM WebSphere Application Serverは、このリリースではサポートされていません。

- Oracle WebLogic Serverへのデプロイ
アプリケーションをスタンドアロン・アプリケーション・サーバーに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。

- アーカイブ・ファイルへのデプロイ
EARファイルをデプロイメント・ターゲットとして選択することで、アプリケーションを間接的にデプロイできます。その後、アーカイブ・ファイルをターゲットのOracle WebLogic Serverインスタンスにインストールします。

9.1.1 統合WebLogic Serverを使用したアプリケーションの開発

JDeveloperでアプリケーションを開発していて、統合WebLogic Serverでアプリケーションを実行する場合、Oracle WebLogic Serverに直接、またはアーカイブ・ファイルにデプロイするために必要なタスクを実行する必要はありません。JDeveloperには統合WebLogic Serverへのデフォルトの接続があるため、デプロイメント・プロファイルやデプロイメント・ディスクリプタは不要です。統合WebLogic Serverには、Oracle ADFアプリケーションの実行に必要なADFライブラリを含む事前構成済ドメイン、および-Djps.app.credential.overwrite.allowed=trueの設定が用意されています。JDeveloperのメイン・メニューから「実行」を選択すれば、アプリケーションを実行できます。

9.1.2 スタンドアロン・アプリケーション・サーバー用のアプリケーションの開発

通常、アプリケーションのテストと開発は、統合WebLogic Serverでアプリケーションを実行することで行います。その後、アプリケーションをスタンドアロンのOracle WebLogic Serverに開発モードでデプロイして本番環境を厳密にシミュレートし、アプリケーションのテストをさらに実施することができます。

一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。

- ターゲット・アプリケーション・サーバーへの接続を作成

- デプロイメント・プロファイルを作成(必要な場合)

- デプロイメント・ディスクリプタを作成(必要な場合)

- application.xmlとweb.xmlを更新してOracle WebLogic Serverとの互換性を確保(必要な場合)

- web.xmlでアプリケーションをReal User Experience Insight(RUEI)に対して有効化(希望する場合)

- アプリケーションレベルのセキュリティ・ポリシー・データをドメインレベルのセキュリティ・ポリシー・ストアに移行

- Oracle Single Sign-On(Oracle SSO)を使用してWebアプリケーションを実行する場合は、ドメインのjps-config.xmlファイルでOracle SSOのサービスおよびプロパティを構成

アプリケーション・サーバーがすでにインストールされている必要があります。Oracle WebLogic Serverの場合は、Oracle 11g InstallerまたはOracle Fusion Middleware 11g Application Developer Installerを使用してインストールできます。他のアプリケーション・サーバーについては、対象アプリケーション・サーバーのドキュメントの説明に従ってサーバーを取得し、インストールしてください。

また、ADFアプリケーションのデプロイに向けてアプリケーション・サーバーを準備する必要もあります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。

- アプリケーション・サーバー・インストール先にADFランタイムをインストール:

- WebLogic Serverの場合

- Oracle 11g Installer for JDeveloperを使用して、Oracle WebLogic ServerをJDeveloperとともにインストールした場合、ADFランタイムはすでにインストールされています。

- ADFランタイムがインストールされていない場合に、Oracle Enterprise Managerを使用してスタンドアロンのADFアプリケーション(Oracle SOA SuiteやOracle WebCenterのコンポーネントを使用しないアプリケーション)を管理するには、Oracle Fusion Middleware 11g Application Developer Installerを使用します。このインストーラでは、必要なOracle Enterprise ManagerコンポーネントがOracle WebLogicのインストール先にインストールされます。

- ADFランタイムがインストールされておらず、Enterprise Managerをインストールする必要がない場合は、Oracle 11g Installer for JDeveloperを使用します。

- WebSphereの場合

- Oracle Fusion Middleware 11g Application Developer Installerを使用して、ADFランタイムおよびOracle Enterprise Managerの必要なコンポーネントをWebSphereのインストール先にインストールします。WebSphereのインストールの詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。

- ADFランタイムを使用して、Oracle WebLogic ServerドメインまたはWebSphereセルをADF互換に拡張

- WebLogicの場合は、必要に応じて、Oracle WebLogic Server資格証明ストアの上書きを設定(-Djps.app.credential.overwrite.allowed=true設定)

- データ・ソースへの接続を必要とするアプリケーションのためのグローバルなJDBCデータ・ソースを作成

アプリケーションとアプリケーション・サーバーの準備が完了したら、次の作業を行うことができます。

- JDeveloperを使用する作業:

- デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、アプリケーション・サーバーに直接デプロイします。

- デプロイメント・プロファイルを使用して、EARファイルにデプロイします。ADFアプリケーションの場合、WARファイルとMARファイルはEARファイルの一部としてのみデプロイできます。

- Enterprise Manager、スクリプト、またはアプリケーションの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

9.2 統合WebLogic ServerでのJava EEアプリケーションの実行

JDeveloperは、統合WebLogic Serverとともにインストールされますが、この統合WebLogic Serverをアプリケーションのテストと開発に使用できます。開発目的では、統合WebLogic Serverで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。

注意:

アプリケーションを統合WebLogic Serverで初めて実行する際、「デフォルト・ドメインの構成」ダイアログが表示され、新しいドメインの管理者パスワードを定義する必要があります。

アプリケーション・ターゲットを実行すると、プロジェクトとワークスペースのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプが自動的に検出されます。次に、アプリケーションを統合WebLogic Serverにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。プロジェクトとアプリケーション・ワークスペースのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、標準のデプロイ手順に従って、展開EARファイルが統合WebLogic Serverに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。

要約すれば、実行ターゲットを選択して統合WebLogic Serverでアプリケーションを実行すると、JDeveloperによって次のことが行われます。

- プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出

- メモリー内にデプロイメント・プロファイルを作成

- プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー

- 模擬EARを統合WebLogic Serverに登録およびデプロイするためのデプロイ・タスクを実行

- アイデンティティ、資格証明およびポリシーを自動的に移行
後で、スタンドアロンのWebLogic Serverインスタンスにアプリケーションをデプロイする予定がある場合は、このセキュリティ情報の移行が必要になります。詳細は、9.3.4項「ADFセキュリティを有効にしてアプリケーションをデプロイする方法」を参照してください。

注意:

統合WebLogic Serverでアプリケーションを実行する際、アプリケーションに対して作成されたデプロイメント・プロファイルは無視されます。

アプリケーションは、統合WebLogic Serverの基本ドメインで実行されます。この基本ドメインは、スタンドアロンのWebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンのWebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。

JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、統合WebLogic Server環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。

統合WebLogic Serverのデフォルト・ドメインを明示的に作成することもできます。これらのドメインを使用して、アプリケーションを実行およびテストできます。アプリケーション・サーバー・ナビゲータを開き、「IntegratedWebLogicServer」を右クリックして、「デフォルト・ドメインの作成」を選択します。

JDeveloperには統合WebLogic Serverへのデフォルト接続があります。アプリケーションを実行するために接続を作成する必要はありません。統合WebLogic Serverへのアプリケーション・サーバー接続を手動で作成する場合は、第9.3.1項「ターゲット・アプリケーション・サーバーへの接続の作成方法」の説明に従って接続を作成します。ただし、手順2で、「スタンドアロン・サーバー」のかわりに「統合サーバー」を選択してください。

9.2.1 統合WebLogic Serverでのアプリケーションの実行方法

アプリケーションを統合WebLogic Serverで実行して、テストすることができます。ブレークポイントを設定して、ADF宣言デバッガでアプリケーションを実行することも可能です。

統合WebLogic Serverでアプリケーションを実行する手順:

1. アプリケーション・ナビゲータで、プロジェクト、バインドなしタスク・フロー、JSFページ、ファイルのいずれかを実行ターゲットとして選択します。

2. 実行ターゲットを右クリックして、「実行」または「デバッグ」を選択します。

3. アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

9.2.2 統合WebLogic Serverでのメタデータを含むアプリケーションの実行方法

アプリケーションが統合WebLogic Serverで実行されている場合、メタデータ・アーカイブ(MAR)プロファイルそのものはリポジトリにデプロイされませんが、MARに含まれるメタデータ情報を反映した模擬Oracle Metadata Services (MDS)リポジトリがアプリケーション用に構成されます。このメタデータ情報はシミュレートされ、ソース・コントロール内のこの場所を基準にアプリケーションが実行されます。

デフォルトでは、ADFビューとADFモデルのカスタマイズ内容のみがMARに組み込まれます。Java EEアプリケーションのカスタマイズ内容が他のディレクトリに存在する場合は、それらのディレクトリを組み込んだカスタムMARプロファイルを作成する必要があります。

アプリケーションによって作成されたカスタマイズ内容やドキュメントのうち、他のMDSリポジトリに格納するよう構成されていないものは、この模擬MDSリポジトリのディレクトリに書き込まれます。たとえば、オブジェクトをカスタマイズした場合、その内容は模擬MDSリポジトリに書き込まれます。新しいメタデータ・オブジェクトを作成するコードを実行した場合、この新しいメタデータ・オブジェクトも模擬MDSリポジトリの同じ場所に書き込まれます。このディレクトリは、デフォルトの場所(ORACLE_HOME\jdeveloper\systemXX.XX\o.mds.dt\adrs\Application\AutoGeneratedMar\mds_adrs_writedir)をそのまま使用することも、別のディレクトリに設定することも可能です。アプリケーションが複数回実行される間、このディレクトリをずっと保持するか、それとも各実行の前に削除するかも選択できます。

ワークスペースに異なるワーキング・セットがある場合、ワーキング・セットとその依存オブジェクトで定義されたプロジェクトのメタデータのみがMARに組み込まれます。アプリケーション・ナビゲータでプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、「依存性」を選択すると、プロジェクトの依存性の表示または変更が行えます。たとえば、アプリケーションに複数のプロジェクトがあるが、workingsetAはviewcontroller2およびviewcontroller5として定義され、viewcontroller5はmodelproject1に依存しているとします。workingsetAを実行またはデバッグすると、viewcontroller2、viewcontroller5およびmodelproject1のメタデータのみがデプロイ用のMARに組み込まれます。

MARプロファイルを用意しておく必要があります。これは、JDeveloperで自動的に生成されたものでも、ユーザーが手動で生成したものでもかまいません。

MARプロファイルを統合WebLogic Serverにデプロイする手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「アプリケーションのプロパティ」を選択します。

2. 「アプリケーションのプロパティ」ダイアログで、「実行」を展開して「MDS」を選択します。

3. 「MDSの実行」ページで次の作業を行います。

- 「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。

- 模擬MDSリポジトリの場所をカスタマイズする場合は、「オーバーライド場所」にディレクトリ・パスを入力します。

- 「ディレクトリ・コンテンツ」オプションを選択します。アプリケーションが複数回実行される間、カスタマイズ内容を維持するか、それとも各実行の前にカスタマイズ内容を削除するかを選択できます。

「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。図9-2は、MARプロファイルとして「Demometadata1」を選択したところを示しています。

図9-2 MDS実行オプションの設定

9.3 アプリケーションの準備

ADFアプリケーションをスタンドアロンのOracle WebLogic Serverインスタンスにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。

図9-3に、アプリケーションをデプロイ用に準備する場合のプロセス・フローを示します。『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』で説明されているようにアプリケーションが準備され、アプリケーション・サーバーが準備された後、9.4項「アプリケーションのデプロイ」の説明に従ってアプリケーションをデプロイできます。

次のダイアグラムには、クリック可能なリンクが含まれています。

図9-3 アプリケーションのデプロイ用の準備のフロー・ダイアグラム

「図9-3 アプリケーションのデプロイ用の準備のフロー・ダイアグラム」の説明

9.3.1 ターゲット・アプリケーション・サーバーへの接続の作成方法

JDeveloperアプリケーション・サーバー接続を介して、Oracle WebLogic Serverにアプリケーションをデプロイすることができます。アプリケーションにMDSを使用したカスタマイズが加えられている場合は、MDSリポジトリをOracle WebLogic Serverドメインに登録してください。

MDSの登録の詳細は、『Oracle Application Server管理者ガイド』を参照してください。

アプリケーション・サーバーへの接続を作成する手順:

1. アプリケーション・サーバー接続ウィザードを起動します。
次のいずれかを実行します。

- アプリケーション・サーバー・ナビゲータで、「アプリケーション・サーバー」を右クリックし、「アプリケーション・サーバー接続の作成」を選択します。

- 「新規ギャラリ」で、「一般」を展開し、「接続」→「アプリケーション・サーバー接続」を選択して、「OK」をクリックします。

- リソース・パレットで、「新規」→「接続の作成」→「アプリケーション・サーバー」を選択します。

2. 「AppServer接続の作成」ダイアログの「使用方法」ページで、「スタンドアロン・サーバー」を選択します。

3. 「名前とタイプ」ページで、接続名を入力します。

4. 「接続タイプ」ドロップダウン・リストで、次を選択します。

- Oracle WebLogic Serverへの接続を作成する場合は「WebLogic 10.3」

- IBM WebSphere Serverへの接続を作成する場合は「WebSphere Server 7.x」

5. 「次へ」をクリックします。

6. 「認証」ページで、アプリケーション・サーバーへのアクセスを認可された管理ユーザーのユーザー名とパスワードを入力します。

7. 「次へ」をクリックします。

8. 「コンフィギュレーション」ページで、次のサーバー情報を入力します。
WebLogicの場合:

- Oracle WebLogicホスト名は、アプリケーション(.jar、.war、.ear)がデプロイされるTCP/IP DNSを含む、WebLogic Serverインスタンスの名前です。

- 「ポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるOracle WebLogic Serverインスタンスのポート番号を入力します。
ポートを指定しない場合、ポート番号はデフォルトの7001になります。

- 「SSLポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるOracle WebLogic ServerインスタンスのSSLポート番号を入力します。
SSLポートの指定はオプションです。デプロイメント時に確実にセキュア接続にする場合にのみ必要です。

ポートを指定しない場合、SSLポート番号はデフォルトの7002になります。

- SSLポートを使用してOracle WebLogic Serverインスタンスに接続するために、「常にSSLを使用」を選択します。

- オプションで、Oracle WebLogic Serverが管理権限のないサーバー・ノードを名前で識別するように構成されている場合のみ、WebLogicドメインを入力します。

WebSphereの場合:

- 「ホスト名」フィールドに、Java EEアプリケーション(.jar、.war、.ear)がデプロイされる、TCP/IP DNSを含むWebSphereサーバーの名前を入力します。名前を入力しない場合は、デフォルトのlocalhostになります。

- 「SOAPコネクタのポート」フィールドに、ポート番号を入力します。このホスト名とポートが、デプロイ用にサーバーへの接続に使用されます。デフォルトのSOAP接続ポートは8879です。

- 「サーバー名」フィールドに、この接続のターゲット・アプリケーション・サーバーに割り当てられた名前を入力します。

- 「ターゲット・ノード」フィールドに、この接続のターゲット・ノード名を入力します。ノードとは、管理対象サーバーのグループです。デフォルトはmachineNode01で、この場合のmachineはノードが常駐するマシンの名前です。

- 「ターゲット・セル」フィールドに、この接続のターゲット・セルの名前を入力します。セルとは、ランタイム・コンポーネントをホストするプロセスのグループです。デフォルトはmachineNode01Cellで、この場合のmachineはノードが常駐するマシンの名前です。

- 「WS管理スクリプト・ファイルの場所」フィールドに、IBM WebSphereアプリケーション・サーバー接続のシステム・ログイン構成を定義するために使用するwsadminスクリプト・ファイルの場所を入力するか、参照して指定します。デフォルトの場所は、Unix/Linuxの場合はwebsphere-home/bin/wsadmin.sh、Windowsの場合はwebsphere-home/bin/wsadmin.batです。

9. 「次へ」をクリックします。

10. WebSphereを選択した場合は、「JMX」ページが表示されます。「JMX」ページで、JMXの情報を入力します(オプション)。

注意:

JMXの構成はオプションで、WebSphere Application Serverへの接続には必要ありません。JMXはSOAアプリケーションのデプロイにのみ必要です。

- 「この接続のJMXの有効化」を選択してJMXを有効にします。

- 「RMIポート」フィールドに、WebSphereのRMI接続ポートのポート番号を入力します。デフォルトは2809です。

- 「WebSphereランタイムJARの場所」フィールドに、WebSphereランタイムJARの場所を入力するか、参照して指定します。

- 「WebSphereプロパティの場所(セキュアなMBeanアクセス用)」フィールドに、セキュリティ構成および有効なMBeanのプロパティを含むファイルの場所を入力するか、参照して指定します。このフィールドへの入力は任意です。

11. 「次へ」をクリックします。

12. SSL署名者交換ダイアログが表示される場合は、「Y」をクリックします。

13. 「テスト」ページで、「接続のテスト」をクリックして、接続をテストします。
JDeveloperにより、数種類の接続テストが実行されます。アプリケーションをデプロイできるためには、JSR-88テストに合格する必要があります。テストに不合格だった場合は、ウィザードの前のページに戻って、構成を修正します。

14. 「終了」をクリックします。

9.3.2 デプロイメント・プロファイルの作成方法

デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイル:

- 作成されるアーカイブ・ファイルのフォーマットと内容を指定します。

- パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。

- 作成されるアーカイブ・ファイルのタイプおよび名前を記述します。

- 依存情報、プラットフォーム固有の指示、およびその他の情報を示します。

アプリケーションにデプロイするWebビュー・コントローラ・プロジェクトごとに、WARデプロイメント・プロファイルが必要です。シード・カスタマイズをパッケージ化する場合や、ベース・メタデータをMDSリポジトリに保存する場合は、アプリケーションレベルのメタデータ・アーカイブ(MAR)・デプロイメント・プロファイルも必要になります。シード・カスタマイズの詳細は、Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドのMDSによるアプリケーションのカスタマイズに関する項を参照してください。アプリケーションにカスタマイズ・クラスがある場合は、そのクラスを格納するJARファイルが必要であり、EARファイルの作成時にそのJARを追加する必要があります。EJBを使用する場合は、EJB JARプロファイルが必要です。さらに、アプリケーションレベルのEARデプロイメント・プロファイルも必要です。WARプロファイルやMARプロファイル、カスタマイズ・クラスのJARファイルなど、その中に組み込むプロジェクトをリストから選択する必要があります。アプリケーションがデプロイされるとき、EARファイルは、デプロイメント・プロファイルで選択されたすべてのプロジェクトを組み込みます。

Oracle ADFアプリケーションの場合、アプリケーションはEARファイルとしてのみデプロイできます。デプロイメント・プロファイルを作成する際に、アプリケーションの一部となるWARファイルとMARファイルをEARファイルに組み込む必要があります。

9.3.2.1 WARデプロイメント・プロファイルの作成

アプリケーションにパッケージ化するWebベースのプロジェクトごとに、WARデプロイメント・プロファイルを作成する必要があります。通常、WARプロファイルには必要な依存データ・モデル・プロジェクトが組み込まれます。

アプリケーションのWARデプロイメント・プロファイルを作成する手順:

1. アプリケーション・ナビゲータで、デプロイするWebプロジェクトを右クリックし、「新規」を選択します。
各WebプロジェクトのWARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「WARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- WARファイル」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。

- アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスを、WARからではなくEARレベルのアプリケーション・クラス・ローダーからロードする必要があります。このカスタマイズ・クラスは後でEARに追加します。
デフォルトでは、カスタマイズ・クラスはデータ・モデル・プロジェクトのWARクラス・パスに追加されます。したがって、WARごとにカスタマイズ・クラスを除外する必要があります。

カスタマイズ・クラスをアプリケーションの拡張プロジェクトで作成した場合は、ユーザー・インタフェース・プロジェクトごとにWARデプロイメント・プロファイルの「ライブラリの依存性」ページで、カスタマイズ・クラスのアーカイブの選択をすべて解除してください。

カスタマイズ・クラスをアプリケーションのデータ・モデル・プロジェクトで作成した場合は、ユーザー・インタフェース・プロジェクトごとにWARデプロイメント・プロファイルの「ファイル・グループ」→「WEB-INF/classes」→「フィルタ」ページで、カスタマイズ・クラスの選択をすべて解除してください。customization.propertiesファイルを使用する場合は、それも選択解除します。

- Java EE Webコンテキストのルート設定を変更することもできます(左側のペインで「一般」を選択)。
デフォルトでは、「プロジェクトのJava EE Webコンテキスト・ルートを使用」が選択されている場合、関連付けられている値は、Application1-Project1-context-rootなどのプロジェクト名に設定されています。ユーザーに違う名前でアプリケーションにアクセスさせる場合は、この名前を変更する必要があります。

JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。

5. 「OK」をクリックして、「WARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

6. 「OK」を再度クリックして、「プロジェクト・プロパティ」ダイアログを終了します。

7. デプロイするすべてのWebプロジェクトに対して、ステップ1から7を繰り返します。

9.3.2.2 MARデプロイメント・プロファイルの作成

MDSリポジトリに保存するシード・カスタマイズやベース・メタデータがある場合は、MARデプロイメント・プロファイルを作成する必要があります。

adf-config.xmlファイルの<mds-config>におけるMARコンテンツのネームスペース構成は、「MARデプロイメント・プロファイルのプロパティ」ダイアログでの選択内容に基づいて生成されます。

まれなことですが、1つのエンタープライズ・アプリケーション(1つのEARにパッケージ化)に複数のWebアプリケーション・プロジェクト(複数のWARにパッケージ化)が含まれている場合があります。しかし、このようなWebアプリケーションのメタデータはすべて、単一のメタデータ・アーカイブ(MAR)にパッケージ化されます。個々のWebアプリケーションのメタデータには、グローバル(すべてのWebアプリケーションで使用可能)なものと、特定のWebアプリケーション専用のローカルなものがあります。グローバル・スコープを持つメタデータの名前が競合するのを避けるため、すべてのメタデータ・オブジェクトおよび要素に、エンタープライズ・アプリケーションを構成するWebアプリケーション・プロジェクト全体で一意の名前を付けてください。名前の競合を避け、特定のWebアプリケーションのメタデータをそのアプリケーション専用のローカル・メタデータのまま保持するには、Webアプリケーション・プロジェクトに対してweb-app-rootを定義します。web-app-rootは、Webアプリケーション・プロジェクトのadf-settings.xmlファイルの要素です。adf-settings.xmlファイルは、Webプロジェクトのpublic_htmlディレクトリの下にあるMETA-INFディレクトリに保存してください。例9-1に、サンプルのadf-settings.xmlファイルの内容を示します。

例9-1 adf-settings.xmlファイルのweb-app-root要素

<?xml version="1.0" encoding="UTF-8" ?>
<adf-settings xmlns="http://xmlns.oracle.com/adf/settings"
xmlns:wap="http://xmlns.oracle.com/adf/share/http/config">
<wap:adf-web-config xmlns="http://xmlns.oracle.com/adf/share/http/config">
<web-app-root rootName="order"/>
</wap:adf-web-config>
</adf-settings>

この例では、adf-settings.xmlファイルに、rootNameをorderとして定義するweb-app-root要素があります。エンタープライズ・アプリケーションにWebアプリケーション・プロジェクトが1つしかない場合、web-app-root要素の定義は不要です。エンタープライズ・アプリケーションにWebアプリケーション・プロジェクトが複数ある場合は、1つを除くすべてのWebアプリケーションに対してweb-app-rootを定義する必要があります。これを行わないと、デプロイは失敗します。たとえば、web-application1、web-application2およびweb-application3がある場合、名前の競合を防ぐには、これらのWebアプリケーション・プロジェクトのうち2つに対してweb-app-rootを定義する必要があります。

「プロジェクト・プロパティ」ダイアログの「ADFビュー」ページで「ユーザー・カスタマイズの有効化」オプションと「MDSを使用したセッション間」オプションを選択した場合、またはadf-config.xmlファイルにデプロイメント・ターゲット・ディレクトリを明示的に指定した場合は、自動生成MARが作成されます。

デフォルトでは、ADFビューとADFモデルのカスタマイズ内容のみがMARに組み込まれます。Java EEアプリケーションのカスタマイズ内容が他のディレクトリに存在する場合は、それらのディレクトリを組み込んだカスタムMARプロファイルを作成する必要があります。

始める前に:

MARデプロイメント・プロファイルを使用してメタデータをデプロイするために、カスタマイズ要件を考慮したMDSリポジトリを作成します。

MARデプロイメント・プロファイルを作成する手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「新規」を選択します。
カスタマイズ内容を組み込む場合は、MARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「MARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- MARファイル」ダイアログで、MARデプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。
図9-4に、サンプルの「ユーザー・メタデータ」ディレクトリ・ツリーを示します。

図9-4 MARデプロイメント・プロファイルの項目の選択

次の重要な点に注意してください。

- すべてのカスタマイズ内容を組み込む場合は、目的のディレクトリを含むファイル・グループを作成するだけで済みます。

- ADFモデルとADFビュー以外のファイルを組み込む場合は、目的のディレクトリを含む「ユーザー・メタデータ」の下に新しいファイル・グループを作成し、「ディレクトリ」ページで必要なコンテンツを明示的に選択します。

- ADFモデルとADFビューのディレクトリはデフォルトで追加されます。ADFモデルとADFビューのカスタマイズ内容をMARにパッケージ化するために必要な作業はこれだけです。ADFビューのコンテンツは「HTMLルート・ディレクトリ」に追加され、ADFモデルのコンテンツは「ユーザー・メタデータ」に追加されます。アプリケーションにEJBプロジェクトなどのその他のカスタマイズ・ディレクトリがある場合は、それらのディレクトリを追加する必要があります。

- MDSリポジトリにベース・メタデータを組み込む場合は、対象となるディレクトリをダイアログで明示的に選択する必要があります。
MARに組み込むベース・ドキュメントを選択する際に、個々のパッケージも選択します。パッケージを1つ選択すると、そのパッケージの下にあるすべてのドキュメント(サブパッケージを含む)が使用されます。パッケージを選択したときに、その下の個々の項目を選択解除することはできません。

- プロジェクトの依存ADFライブラリJARにシード・カスタマイズが含まれている場合、そのシード・カスタマイズはMARのパッケージ化中にMARに自動的に追加されます。MARプロファイルには表示されません。

- ADFライブラリのカスタマイズ内容が使用側プロジェクトのコンテキストで作成された場合、そのカスタマイズ内容はMARプロファイルのダイアログにデフォルトで表示されます。

5. 「OK」をクリックして、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

6. 「OK」を再度クリックして、「アプリケーションのプロパティ」ダイアログを終了します。

9.3.2.3 EJB JARデプロイメント・プロファイルの作成

データ・モデル・プロジェクトでEJBモジュールを使用する場合は、EJB JARデプロイメント・プロファイルを作成する必要があります。

始める前に:

EJBモジュールを使用したデータ・モデル・プロジェクトを作成します。

アプリケーションのEJB JARデプロイメント・プロファイルを作成する手順:

1. アプリケーション・ナビゲータで、デプロイするWebプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EJB JARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- EJB JARファイル」ダイアログで、デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。

5. 「OK」をクリックして、「EJB JARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

6. 「OK」を再度クリックして、「プロジェクト・プロパティ」ダイアログを終了します。

9.3.2.4 アプリケーションレベルのEARデプロイメント・プロファイルの作成

EARファイルには、アプリケーション・サーバーでアプリケーションを実行するために必要なアプリケーション・アーティファクトがすべて含まれています。EARファイルの詳細は、9.4.6項「EARファイルとパッケージ化について」を参照してください。

始める前に:

- 9.3.2.7項「JARへのカスタマイズ・クラスの追加」の説明に従って、JARファイルにクラスを追加します。

- 9.3.2.1項「WARデプロイメント・プロファイルの作成」の説明に従って、WARデプロイメント・プロファイルを作成します。

アプリケーションのEARデプロイメント・プロファイルを作成する手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「新規」を選択します。
アプリケーションのEARプロファイルを作成します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- EARファイル」ダイアログで、アプリケーション・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。

4. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。
次の手順を必ず実行してください。

- 「アプリケーション・アセンブリ」を選択し、続いて「Java EEモジュール」リストで、デプロイメントに組み込むすべてのプロジェクト・プロファイルを選択します(WARまたはMARプロファイルを含む)。

- 「プラットフォーム」を選択し、デプロイ先となるアプリケーション・サーバーを選択した後、「ターゲット接続」ドロップダウン・リストから、ターゲット・アプリケーション接続を選択します。

注意:

JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。

5. アプリケーションにカスタマイズ・クラスがある場合は、そのクラスがEARレベルのアプリケーション・クラス・ローダーからロードされるように構成する必要があります。

1. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択します。

2. カスタマイズ・クラスを含むJARデプロイメント・プロファイルを選択して、ダイアログの一番下にある「EARのパス」フィールドにlibを入力します。

注意:

このJARは、9.3.2.7項「JARへのカスタマイズ・クラスの追加」の説明に従って作成したものです。

カスタマイズ・クラスを含むJARファイルが、EARファイルのlibディレクトリに追加されます。

注意:

アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスがWARからロードされないようにする必要があります。デフォルトでは、データ・モデル・プロジェクトのライブラリおよびクラスパスに追加されるカスタマイズ・クラスは、WARクラス・パスにパッケージ化されます。

拡張プロジェクトで作成したカスタマイズ・クラスがWARにも重複して存在するのを避けるため、WARの「ライブラリの依存性」ページでカスタマイズ・クラスのアーカイブの選択をすべて解除してください。

カスタマイズ・クラスをコンシューミング・アプリケーションのデータ・モデル・プロジェクトで作成した場合は、WARの「ファイル・グループ」→「WEB-INF/classes」→「フィルタ」ページでカスタマイズ・クラスの選択をすべて解除します。

6. 「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。

7. 「OK」を再度クリックして、「アプリケーションのプロパティ」ダイアログを終了します。

9.3.2.5 共有ライブラリとしてのカスタマイズ・クラスの配布

第9.3.2.4項「アプリケーションレベルのEARデプロイメント・プロファイルの作成」に記載されているように、カスタマイズ・クラスをEARに追加する別の方法として、カスタマイズ・クラスを共有ライブラリとしてコンシューミング・アプリケーションに追加することもできます。

始める前に:

カスタマイズ・クラスを含むアプリケーションをJDeveloperのStudio開発者ロールで開き、9.3.2.7項「JARへのカスタマイズ・クラスの追加」に記載されている手順を使用して、作成するアーカイブのタイプとして「共有ライブラリJARファイル」を選択します。

注意:

この手順では、Oracle Weblogic Serverにデプロイする場合の、共有ライブラリの作成および使用方法について説明します。

カスタマイズ・クラスの共有ライブラリを作成および使用する手順:

1. 「アプリケーション・ナビゲータ」で、カスタマイズ・クラス・プロジェクトを右クリックし、「デプロイ」→「deployment-profile」を選択します。

2. 「デプロイ」ウィザードで、WebLogic Application Serverにデプロイを選択し、「次へ」をクリックします。

3. 適切なアプリケーション・サーバーを選択し、「終了」をクリックします。
これにより、共有ライブラリがアプリケーション・サーバーで使用できるようになります。次に、コンシューミング・アプリケーションから共有ライブラリへの参照を追加する必要があります。

4. JDeveloperのStudio開発者ロールで、カスタマイズするアプリケーションを開きます。

5. アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、weblogic-application.xmlファイルをダブルクリックして開きます。

6. 「概要エディタ」で、「ライブラリ」タブをクリックします。

7. 「共有ライブラリ参照」セクションで、追加アイコンをクリックします。

8. 「共有ライブラリ参照」テーブルに新たに作成された行の「ライブラリ名」フィールドに、デプロイしたカスタマイズ・クラスの共有ライブラリの名前を入力し、変更を保存します。

9.3.2.6 デプロイメント・プロファイル・プロパティの表示および変更

デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。

プロジェクトのデプロイメント・プロファイルを作成、編集または削除する手順:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。

2. 「プロジェクト・プロパティ」ダイアログで、「デプロイメント」をクリックします。
「デプロイメント・プロファイル」リストには、現在プロジェクトに定義されているすべてのプロファイルが表示されます。

3. リストから、デプロイメント・プロファイルを1つ選択します。

4. 「編集」または「削除」をクリックして、デプロイメント・プロファイルを編集または削除します。

9.3.2.7 JARへのカスタマイズ・クラスの追加

アプリケーションにカスタマイズ・クラスがある場合は、そのカスタマイズ・クラスのみを格納するJARを作成します。このJARは、EARを作成する際にEARアセンブリに追加できます。WebプロジェクトのWARプロファイルを作成する場合は、このプロファイルにカスタマイズ・クラスのJARを組み込まないようにする必要があります。

始める前に:

プロジェクトにカスタマイズ・クラスがあることを確認します。アプリケーションにカスタマイズ・クラスがない場合、この手順を実行する必要はありません。カスタマイズ・クラスの詳細は、Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドのカスタマイズ・クラスの作成方法に関する項を参照してください。

JARにカスタマイズ・クラスを追加する手順:

1. 「アプリケーション・ナビゲータ」で、JARを作成するカスタマイズ・クラスを含むデータ・モデル・プロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」、「JARファイル」の順に選択して、「OK」をクリックします。
または、共有ライブラリを作成する場合は、プロファイル・タイプのリストから「共有ライブラリJARファイル」を選択し、「OK」をクリックします。

注意:

「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべての機能」タブをクリックします。

3. 「デプロイメント・プロファイルの作成 -- JARファイル」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前(CCArchiveなど)を入力して、「OK」をクリックします。

4. 「JARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「JARオプション」を選択します。

5. JARファイルの場所を入力します。

6. 「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」を展開します。

7. 「ファイル」タブで、JARファイルに追加するカスタマイズ・クラスを選択します。customization.propertiesファイルを使用する場合は、このファイルがJARファイルと同じクラス・ローダーにあることが必要です。customization.propertiesファイルを選択して、カスタマイズ・クラスとともに同じJARにパッケージ化することができます。

8. 「OK」をクリックして、「JARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。

9. 「OK」を再度クリックして、「プロジェクト・プロパティ」ダイアログを終了します。

10. アプリケーション・ナビゲータで、JARデプロイメント・プロファイルを含むプロジェクトを右クリックし、「デプロイ」→「deployment profile」→「JARファイルへ」を選択します。

注意:

デプロイメント・プロファイルからJARに初めてデプロイする場合は、ウィザードで「デプロイ」→「デプロイメント・プロファイル」を選択し、「JARにデプロイ」を選択します。

9.3.3 デプロイメント・ディスクリプタの作成および編集方法

デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルを宣言的に編集できない場合、JDeveloperはその内容を編集するためにソースエディタでXMLファイルを開きます。

ターゲットのOracle WebLogicアプリケーション・サーバー・インスタンスに固有のデプロイメント・ディスクリプタを指定できます。

標準のJava EEデプロイメント・ディスクリプタ(application.xmlおよびweb.xmlなど)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。たとえば、Oracle WebLogic Serverにデプロイする場合、weblogic.xml、weblogic-application.xmlおよびweblogic-ejb-jar.xmlを使用できます。

アプリケーションのEARファイルに、adf.oracle.domainへの参照を含むweblogic-application.xmlファイルが組み込まれていること、そしてデプロイ作業とアンデプロイ作業の間にアプリケーション・リソースをクリーンアップするためのADFApplicationLifecycleListenerが組み込まれていることを確認してください。例9-2に、サンプルのweblogic-application.xmlファイルを示します。

例9-2 サンプルのweblogic-application.xml

<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<listener>
<listener-class>oracle.adf.share.weblogic.listeners.
ADFApplicationLifecycleListener</listener-class>
</listener>
<listener>
<listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>
<library-ref>
<library-name>adf.oracle.domain</library-name>
<implementation-version>
</implementation-version>
</library-ref>
</weblogic-application>

Webサービスをデプロイする場合は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のOracle WebLogic ServerへのWebサービスのデプロイ方法に関する項の説明に従って、weblogic-application.xmlファイルとweb.xmlファイルを変更する必要が生じることがあります。

アプリケーションに対してReal User Experience Insight(RUEI)による監視を行えるようにするには、9.3.3.5項「Real User Experience Insightに対するアプリケーションの有効化」の説明に従って、web.xmlファイルにパラメータを追加する必要があります。

デプロイ時には、アプリケーションとともにEARファイルにデプロイされるweblogic-application.xmlファイルに、アプリケーションのセキュリティ・プロパティが書き込まれます。

Oracle WebLogic ServerはJava EE 1.5上で動作するため、application.xmlファイルとweb.xmlファイルを変更してサーバーと互換性を持たせることが必要になる場合があります。

9.3.3.1 デプロイメント・ディスクリプタの作成

必要なデプロイメント・ディスクリプタの多くは、自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、明示的な作成が可能です。

始める前に:

デプロイメント・ディスクリプタがすでに生成されているかどうかを確認します。

デプロイメント・ディスクリプタを作成する手順:

1. アプリケーション・ナビゲータで、ディスクリプタを作成するプロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」、ディスクリプタ・タイプの順に選択して、「OK」をクリックします。
目的の項目が見つからない場合は、正しいプロジェクトが選択されていることを確認してから「すべての機能」タブを選択するか、「検索」フィールドを使用してディスクリプタを検索します。項目が有効になっていない場合は、そのタイプのディスクリプタがプロジェクトにまだ存在しないことを確認します。1つのプロジェクトで使用できるディスクリプタのインスタンスは1つのみです。

デプロイメント・ディスクリプタの作成ウィザードが起動し、選択したデプロイメント・ディスクリプタのタイプに応じて、概要エディタまたはソース・エディタでファイルが開きます。

注意:

EARファイルの場合は、1つのアプリケーションまたはワークスペースに複数のデプロイメント・ディスクリプタを作成しないでください。これらのファイルはプロジェクトに割り当てられますが、アプリケーション・ワークスペース・スコープがあります。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制約は、application.xml、weblogic-jdbc.xml、jazn-data.xmlおよびweblogic.xmlに適用されます。

アプリケーションレベルのディスクリプタを作成するのに最適な場所は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。

9.3.3.2 デプロイメント・ディスクリプタ・プロパティの表示または変更

デプロイメント・ディスクリプタを作成したら、JDeveloperの各種ダイアログを使用するか、ソース・エディタでファイルを編集することで、そのプロパティを変更できます。デプロイメント・ディスクリプタは、通常「アプリケーション・ソース」ノードにあるXMLファイル(application.xmlなど)です。

デプロイメント・ディスクリプタのプロパティを表示または変更する手順:

1. アプリケーション・ナビゲータまたは「アプリケーション・リソース」パネルで、デプロイメント・ディスクリプタをダブルクリックします。

2. エディタ・ウィンドウで、「概要」タブまたは「ソース」タブを選択し、プロパティ値を設定してディスクリプタを構成します。
概要エディタが使用できない場合は、ソース・エディタでファイルが開きます。

9.3.3.3 WebLogic互換のapplication.xmlファイルの構成

Java EE 1.5に準拠するようにapplication.xmlファイルを構成しなければならないことがあります。

注意:

通常、プロジェクトには互換性のあるapplication.xmlファイルがあるため、この手順を実行する必要はありません。

application.xmlファイルを構成する手順:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ・ウィザード」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「application.xml」を選択して、「次へ」をクリックします。

4. 「バージョンを選択」ページで「5.0」を選択し、「次へ」をクリックします。

5. 「サマリー」ページで「終了」をクリックします。

6. application.xmlファイルを適切な値で編集します。

9.3.3.4 WebLogic互換のweb.xmlファイルの構成

Java EE 1.5(Servlet 2.5およびJSP 1.2に対応)に準拠するようにweb.xmlファイルを構成しなければならないことがあります。

注意:

通常、プロジェクトには互換性のあるweb.xmlファイルがあるため、この手順を実行する必要はありません。プロジェクトを作成すると、初期のweb.xmlファイルが自動的に作成されます。

web.xmlファイルを構成する手順:

1. アプリケーション・ナビゲータで、プロジェクトを右クリックし、「新規」を選択します。

2. 「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ・ウィザード」を選択して、「OK」をクリックします。

3. 「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「web.xml」を選択して、「次へ」をクリックします。

4. 「バージョンを選択」ページで「2.5」を選択し、「次へ」をクリックします。

5. 「サマリー」ページで「終了」をクリックします。

9.3.3.5 Real User Experience Insightに対するアプリケーションの有効化

Real User Experience Insight(RUEI)はWebベースのユーティリティで、ネットワークからリクエストされる、またはネットワークで生成される実際のユーザーのトラフィックに対してレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページやトランザクションのレスポンス時間を測定します。セッション診断情報を使用すれば、根本原因分析を実行できます。

RUEIでは、実際のユーザー体験に基づいてサーバーおよびネットワーク時間を表示し、キー・パフォーマンス・インディケータ(KPI)とサービス・レベル合意(SLA)を監視し、定義済のターゲットに違反するインシデントが発生した場合にアラート通知をトリガーすることが可能です。ページ・コンテンツ、サイト・エラー、およびトランザクションの機能要件に関するチェックを実施できます。この情報を使用することで、業務面、技術面から運用を検証できます。RUEIで認識されるすべての項目の可用性、スループットおよびトラフィックに関して、カスタム・アラートを設定することもできます。

RUEIの詳細は、Oracle Real User Experience Insightのユーザーズ・ガイド(http://download.oracle.com/docs/cd/E16339_01/doc.60/e16359/toc.htm)を参照してください。

例9-3に示すように、web.xmlファイルにcontext-paramタグを追加し、アプリケーションをRUEIに対して有効にする必要があります。

例9-3 web.xmlでのアプリケーションのRUEI監視の有効化

<context-param>
<description>This parameter notifies ADF Faces that the
ExecutionContextProvider service provider is enabled.
When enabled, this will start monitoring and aggregating
user activity information for the client initiated
requests. By default this param is not set or is false.
</description>
<param-name>
oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
</param-name>
<param-value>true</param-value>
</context-param>

9.3.4 ADF Securityを有効にしたアプリケーションのデプロイ方法

統合WebLogic Serverを使用してJDeveloperでアプリケーションを開発する場合、アプリケーション・セキュリティ・デプロイメント・プロパティがデフォルトで構成されます。つまり、開発目的で再デプロイするたびに、アプリケーションとセキュリティの資格証明およびポリシーが上書きされることになります。ただし、アプリケーション・セキュリティ・デプロイメント・プロパティは、統合WebLogic ServerおよびスタンドアロンのWebLogic Serverの両方で同じです。

9.3.4.1 Oracle Single Sign-On(SSO)を使用して実行するアプリケーション

Oracle ADF Securityを有効にしたWebアプリケーションを、Oracle WebLogic Serverにデプロイして実行するには、ターゲット・サーバーの管理者がOracle Access Manager(OAM)セキュリティ・プロバイダのドメインレベルのjps-config.xmlファイルを構成する必要があります。この構成タスクを助けるため、JDeveloperにはOracle WebLogic Scripting Tool(WLST)スクリプトが付属しています。この構成スクリプト(コマンドaddOAMSSOProvider(loginuri, logouturi, autologinuri)を使用)の実行の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』で、ADF Security、OAM SSOおよびOPSS SSOを使用したWebアプリケーションに対してOracle WebLogic Serverを構成する手順を参照してください。

構成スクリプトを実行することで、ADF Securityフレームワークが確実にOAMサービス・プロバイダに従って、ObSSOCookieトークンをクリアするようになります。OAMでは、このトークンを使用して認証済ユーザーのアイデンティティが保存されるため、ログアウト中にトークンがクリアされないかぎり、ユーザーはログアウトできません。

システム管理者がターゲット・サーバーに対してスクリプトを実行すると、ドメインのjps-config.xmlファイルに、ADF Security固有の次のセキュリティ・プロバイダ定義が追加されます。

<propertySet name="props.auth.uri">
<property name="login.url.FORM" value="/${app.context}/adfAuthentication"/>
<property name="logout.url" value=""/>
</propertySet>

また、SSOに必要な認証タイプはCLIENT-CERTです。デプロイ済アプリケーションのweb.xml認証構成に、<auth-method>要素を次のいずれかのCLIENT-CERTタイプとして指定する必要があります。

WebLogicでは、次の2種類の認証方式をサポートしています。

- FORMタイプの認証方式の場合、次のような要素を指定します。

<login-config>
<auth-method>CLIENT-CERT,FORM</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>

- BASICタイプの認証方式の場合、次のような要素を指定します。

<login-config>
<auth-method>CLIENT-CERT,BASIC</auth-method>
<realm-name>myrealm</realm-name>
</login-config>

WebSphereでは、次の1種類の認証方式をサポートしています。次のように要素を指定します。

<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>

web.xmlファイルは、Webアプリケーションをデプロイする前でも後でも構成可能です。シングル・サインオンの認証方式を設定する方法の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

9.3.4.2 WebLogic Serverのセキュリティ構成

開発環境では、サーバーが開発モードに設定されている場合にのみ、アプリケーションレベルの資格証明、アイデンティティおよびポリシーがリモートWebLogic Serverインスタンスへ自動的に移行されます。統合WebLogic Serverはデフォルトで開発モードに設定されています。Oracle WebLogic Serverドメインの作成時に、Oracle Fusion Middleware構成ウィザードを使用して、リモートWebLogic Serverを開発モードに設定できます。Oracle WebLogic Serverドメインの構成の詳細は、『Oracle Fusion Middleware構成ウィザードによるドメインの作成』を参照してください。

本番モードでは、アプリケーションレベルのセキュリティ資格証明はWebLogic Server設定に移行されません。本番環境では一般に、管理者はEnterprise ManagerまたはWLSTスクリプトを使用してアプリケーション(セキュリティ要件を含む)をデプロイします。

アプリケーションをWebLogic Serverにデプロイすると、資格証明(cwallet.ssoおよびjazn-data.xmlファイルに含まれる)は、WebLogic Serverのドメインレベルの資格情報ストアを上書きするか、これらとマージされます。上書きとマージのどちらが行われるかは、weblogic-application.xmlのプロパティがOVERWRITEまたはMERGEのいずれに設定されているかによって決まります。本番モードのWebLogic Serverでは、セキュリティ・リスクを回避するため、MERGEしか使用できません。開発モードのWebLogic Serverでは、モードをOVERWRITEに設定して、ユーザー名とパスワードをテストできます。また、プロパティを設定するには、setDomainEnv.cmdまたはsetDomainEnv.shを実行することもできます。その際、コマンド(通常はORACLE_HOME/user_projects/domains/MyDomain/binにあります)に次のオプションを追加します。

setDomainEnv.cmdの場合:

set EXTRA_JAVA_PROPERTIES=-Djps.app.credential.overwrite.allowed=true
%EXTRA_JAVA_PROPERTIES%

setDomainEnv.shの場合:

EXTRA_JAVA_PROPERTIES="-Djps.app.credential.overwrite.allowed=true
${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

管理サーバーがすでに稼働している場合、この設定を有効にするにはサーバーを再起動する必要があります。

WebLogic Serverが本番モードかどうかをチェックするには、Oracle WebLogic Server管理コンソールを使用するか、WebLogic Serverのconfig.xmlファイルで次の行を確認します。

<production-mode-enabled>true</production-mode-enabled>

デフォルトでは、アプリケーションの資格証明、アイデンティティおよびポリシーはOVERWRITEモードに設定されます。つまり、「アプリケーションのプロパティ」ダイアログの「デプロイメント」ページで、「アプリケーション・ポリシー」、「資格証明」、「ユーザーとグループ」の各オプションがデフォルトで選択されます。ただし、アプリケーションの資格証明が移行されるのは、ターゲットとなるWebLogic Serverインスタンスが-Djps.app.credential.overwrite.allowed=trueの指定によって開発モードに設定されている場合のみです。

ポリシーの移行は開発モードでのみ実行されます。アイデンティティの移行が実行できるのは、開発または本番モードにかかわらず、JDeveloperを使用してWebLogic Serverに直接デプロイする場合のみです。

アプリケーションを本番環境にデプロイする準備ができたら、jazn-data.xmlファイルからアイデンティティを削除するか、「アプリケーションのプロパティ」ダイアログで「ユーザーとグループ」を選択解除して、アイデンティティの移行を無効にしてください。アプリケーションの資格証明は、JDeveloperの外部で、手動で移行する必要があります。

注意:

jazn-data.xmlファイルを本番環境に移行する前に、ポリシー・ストアに、重複する権限付与のためのパーミッションがないか確認します。ファイル内に重複するパーミッション(同じ名前とクラスを持つパーミッション)がある場合は、ポリシー・ストアを移行する管理者にエラーが表示され、ポリシーの移行が停止します。jazn-data.xmlファイルを手動で編集して、権限付与の定義から重複するパーミッションをすべて削除する必要があります。

アプリケーションの資格証明とその他のjazn-dataユーザー資格証明の移行の詳細は、『Oracle Containers for J2EE セキュリティ・ガイド』を参照してください。

9.3.4.2.1 WebLogic用のJDBCデータ・ソースを使用するアプリケーション

アプリケーションがパスワード・インダイレクション機能を持つアプリケーションレベルのJDBCデータ・ソースを使用して、データベース接続を行う場合、WebLogic Serverで資格証明マップを作成し、データベース接続を有効にする必要があります。詳細は、第9.3.7項「Oracle WebLogic Server用のJDBCデータ・ソースについて」を参照してください。

9.3.4.3 WebSphere Serverのセキュリティ構成

jazn-data.xmlファイルおよびcwallet.ssoファイルに資格証明とポリシーを含むアプリケーションがWebSphereに移行されることがあります。この場合、WebSphereで追加のタスクを実行する必要があります。WebSphereへのデプロイを意図したアプリケーションのEARファイルには、opss-application.xmlファイルが含まれないことに注意してください。

注意:

jazn-data.xmlファイルを本番環境に移行する前に、ポリシー・ストアに、重複する権限付与のためのパーミッションがないか確認します。ファイル内に重複するパーミッション(同じ名前とクラスを持つパーミッション)がある場合は、ポリシー・ストアを移行する管理者にエラーが表示され、ポリシーの移行が停止します。jazn-data.xmlファイルを手動で編集して、権限付与の定義から重複するパーミッションをすべて削除する必要があります。

資格証明とポリシーを受け入れるためのWebSphereの設定の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。

9.3.4.3.1 WebSphere用のJDBCデータ・ソースを使用するアプリケーション

アプリケーションがパスワード・インダイレクション機能を持つアプリケーションレベルのJDBCデータソースを使用して、データベース接続を行う場合、WebSphereでJDBCデータソースを作成する必要があります。詳細は、IBM WebSphereのドキュメントを参照してください。

9.3.4.3.2 web.xmlファイルの編集によるWebSphereのアプリケーション・ルートの保護

WebアプリケーションのADFセキュリティを有効にすると、web.xmlファイルにJava EEセキュリティ制約のallPagesが格納され、Java EEのアプリケーション・ルートが保護されます。デフォルトでは、Oracle WebLogic Serverへのデプロイをサポートするために、JDeveloperでセキュリティ制約のURLパターンが/(バックスラッシュ)に指定されます。アプリケーションをIBM WebSphereにデプロイする場合、正しいURLパターンは/*(バックスラッシュとアスタリスク)になります。アプリケーションをWebSphereにデプロイする前に、アプリケーションのweb.xmlファイルを手動で編集し、allPagesセキュリティ制約を次のように変更します。

<security-constraint>
<web-resource-collection>
<web-resource-name>allPages</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
. . .
</security-constraint>

9.3.5 クラスタ環境でのメモリー・スコープのレプリケート方法

クラスタ環境での実行を想定したアプリケーションをデプロイする場合、存続期間が1つのリクエストより長いマネージドBeanがすべてシリアライズ可能であること、そしてADFフレームワークがADFスコープ(ビュー・スコープとページ・フロー・スコープ)に格納されるマネージドBeanへの変更を認識することを確認する必要があります。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のサーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法に関する項を参照してください。

9.3.6 アプリケーションをADF MBeanに対して有効化する方法

ADFアプリケーションでは、多くのXMLファイルを使用して構成情報が設定されています。こうした構成ファイルの一部には、アプリケーションとともにデプロイされ、構成ファイルと同じ役割を果すADF MBeanがあります。アプリケーションがデプロイされたら、Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用してADF MBeanにアクセスし、構成プロパティを変更することができます。

ADF MBeanを有効にするには、web.xmlファイルに登録する必要があります。例9-4に、接続と構成のリスナー・エントリを含むweb.xmlファイルを示します。

例9-4 web.xmlファイルでのADF MBeanの有効化

<listener>
<listener-class>
oracle.adf.mbean.share.connection.ADFConnectionLifeCycleCallBack
</listener-class>
</listener>
<listener>
<listener-class>
oracle.adf.mbean.share.config.ADFConfigLifeCycleCallBack</listener-class>
</listener>

また、ADFConnection MBeanとADFConfig MBeanを使用する場合は、MDSリポジトリを使用するようにアプリケーションを構成する必要があります。ファイルベースのMDSを使用する場合のadf-config.xmlファイルのMDS構成エントリを例9-5に示します。MDSの構成の詳細は、『Oracle Application Server管理者ガイド』を参照してください。

例9-5 adf-config.xmlファイルのMDS構成エントリ

<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<persistence-config>
<metadata-store-usages>
<metadata-store-usage
default-cust-store="true" deploy-target="true" id="myFileStore">
<metadata-store name="myReposName"
class-name=
"oracle.mds.persistence.stores.file.FileMetadataStore">
<property name="metadata-path" value="C:\Temp\"/>
<property name="partition-name" value="myAppName"/>
</metadata-store>
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>

本番環境では、データベースを使用するMDSリポジトリが必要です。JDeveloper、Enterprise Manager Fusion Middleware Control、WLSTコマンドのいずれかを使用して、ファイルベースのリポジトリからデータベースのMDSリポジトリに切り替えることができます。

また、複数のアプリケーションが同じMDS構成を共有している場合は、adf-config.xmlファイルでadf:adf-properties-childプロパティを定義して、各アプリケーションに異なるカスタマイズ・レイヤーを持たせることができます。このエントリは、アプリケーションの作成時に自動的に生成されます。adf-config.xmlファイルにこのエントリがない場合は、例9-6に示すようなコードを使用してファイルに追加できます。

例9-6 adf-config.xmlファイルへのMDSパーティション・コードの追加

<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="adfAppUID" value="Application3-4434"/>
<adf-property name="partition_customizations_by_application_id"
value="true"/>
</adf:adf-properties-child>

value属性は、JDeveloperで自動的に生成するか、アプリケーションのデプロイ先となるサーバー・ファーム内で一意の識別子に設定します。この値は、adfAppUIDプロパティのvalue属性に設定できます。

adf-property nameをadfAppUidに設定した場合は、対応するvalueプロパティをアプリケーションの名前に設定する必要があります。デフォルトでは、valueプロパティはアプリケーションのパッケージ名を使用して生成されます。パッケージ名を指定していない場合、valueプロパティはワークスペース名と4桁の乱数を使用して生成されます。

ADF MBeanを使用したOracle ADFアプリケーションの構成の詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

9.3.7 Oracle WebLogic Server用のJDBCデータソースについて

Oracle ADF Java EEアプリケーションでは、データベースへの接続にJDBCデータ・ソースを使用できます。JDBCデータ・ソースを構成するには、Oracle WebLogic Server管理コンソールを使用します。JDBCデータ・ソースには、グローバル、アプリケーションレベル、パスワード・インダイレクション機能を持つアプリケーションレベルの3種類があります。通常、グローバルなJDBCデータ・ソースはWebLogic Serverで設定します。データベースにアクセスする必要のあるアプリケーションは、そのJDBCデータ・ソースを使用できます。アプリケーションには、アプリケーションレベルのJDBCデータ・ソースを組み込むこともできます。アプリケーションをデプロイメント用にパッケージ化する際に、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」オプションを選択すると、定義した接続ごとにconnection_name-jdbc.xmlファイルが作成されます。各接続の情報は、対応するconnection_name-jdbc.xmlファイルに書き込まれます(weblogic-application.xmlとweb.xmlのエントリも変更されます)。アプリケーションがWebLogic Serverにデプロイされると、サーバーはグローバル・データ・ソースを検索する前に、アプリケーションレベルのデータ・ソース情報を検索します。

パスワード・インダイレクションをtrueに設定してアプリケーションをデプロイすると、WebLogic Serverは、connection_name-jdbc.xmlファイルを探してユーザー名情報を確認し、そのユーザー名に対応するアプリケーションレベルの資格証明マップを特定してパスワードを入手しようとします。JDeveloperを使用してアプリケーションをWebLogic Serverに直接デプロイする場合は、資格証明マップが自動的に作成され、MBeanコールを介してサーバーに組み込まれます。

ただし、EARファイルをデプロイする場合は、JDeveloperでWebLogic ServerへのMBeanコールを行えません。Oracle WebLogic Server管理コンソールを使用して、資格証明マップを設定する必要があります。グローバルなJDBCデータ・ソースを設定した場合でも、資格証明マッピングを設定していなければ、WebLogic Serverは資格証明をパスワードにマップできず、接続は失敗します。JDBCデータ・ソース、パスワード・インダイレクション、およびアプリケーション資格証明マッピングの設定方法の詳細は、JDeveloperオンライン・ヘルプの「アプリケーションのデプロイ」の「JDBCデータ・ソース」を参照してください。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。

9.4 アプリケーションのデプロイ

アプリケーションは、JDeveloperを使用してスアンドアロン・アプリケーション・サーバーに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。

図9-5に、ターゲット・スタンドアロン・アプリケーション・サーバーへのアプリケーションのデプロイとカスタマイズのデプロイのプロセス・フローを示します。

次のダイアグラムには、クリック可能なリンクが含まれています。

図9-5 アプリケーションのデプロイのフロー・ダイアグラム

「図9-5 アプリケーションのデプロイのフロー・ダイアグラム」の説明

注意:

Oracle ADFを使用するアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイし始める前に、ADFランタイムのインストール、およびドメインまたはセルの作成や拡張といったタスクを実行して、アプリケーション・サーバー環境を準備しておく必要があります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。

表9-1に、アプリケーションのデプロイおよびデプロイ・サイクル中に使用できる一般的なデプロイ方法を示します。開発環境でのデプロイから本番環境のデプロイまでの順序でデプロイ方法をリストしています。本番環境では、システム管理者がEnterprise ManagerまたはWLSTスクリプト・ツールを使用してアプリケーションをデプロイします。

表9-1 開発環境または本番環境でのデプロイ方法

デプロイ方法

環境

使用するとき

JDeveloperから直接実行

テストまたは開発

この方法は、アプリケーションの開発中に使用します。編集プロセスとデプロイ・プロセスを何度も繰り返すことになるため、デプロイは手早く行う必要があります。

JDeveloperには統合WebLogic Serverが含まれています。この統合WebLogic Serverでアプリケーションを実行してテストできます。

JDeveloperを使用してターゲット・アプリケーション・サーバーに直接デプロイ

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。

テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

JDeveloperを使用してEARファイルにデプロイし、ターゲット・アプリケーション・サーバーのデプロイ用ツールを使用

テストまたは開発

この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。JDeveloperから直接デプロイするかわりに、EARファイルにデプロイしてから、他のツールを使用してアプリケーション・サーバーにデプロイすることができます。

テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。

テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。

Enterprise ManagerまたはWLSTスクリプトを使用してアプリケーションをデプロイ

本番

この方法は、アプリケーションがテスト環境と本番環境にある場合に使用します。本番環境では、システム管理者がEnterprise Managerを使用するか、WLSTスクリプトを実行して、アプリケーションをデプロイするのが一般的です。

必要なMDSリポジトリをすべてアプリケーション・サーバーに登録する必要があります。MDSリポジトリがデータベースの場合、リポジトリはMDS固有の要件を備えたデータソースにマップされます。

アプリケーションをOracle WebLogic Serverにデプロイする前に、このデータソースのターゲットをWebLogic管理サーバー、およびアプリケーションのデプロイ先となるすべての管理対象サーバーに設定する必要があります。MDSの登録の詳細は、『Oracle Application Server管理者ガイド』を参照してください。

adf-config.xmlのMDSリポジトリ構成を必要とするEARファイルとしてパッケージ化されたアプリケーションを、アプリケーション・サーバーの管理コンソールまたはスクリプトを使用してデプロイする場合は、EARファイルをデプロイする前に、getMDSArchiveConfigコマンドを実行してMDSを構成する必要があります。MDS構成は、EARファイルにMARファイルが含まれる場合、またはアプリケーションがDT@RT(Design Time At Run Time)に対して有効化されている場合に必要です。

WLSTコマンドの詳細は、Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスを参照してください。wsadminコマンドの詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドおよびOracle Fusion Middleware WebSphere構成ガイドを参照してください。

アプリケーションのデプロイ後に、ADF MBeanを使用してADF接続情報(adf-config.xml)を構成する予定の場合は、アプリケーションがMDSを使用するように構成されていること、およびweb.xmlファイルでMBeanリスナーが有効になっていることを確認してください。詳細は、9.3.6項「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。

9.4.1 JDeveloperからWebLogic Serverへのデプロイ方法

始める前に:

EARファイルにデプロイするアプリケーションレベルのデプロイメント・プロファイルを作成します。

注意:

JDeveloperからOracle WebLogic Serverにデプロイする場合は、Oracle WebLogic Server管理コンソールで、HTTPトンネリング・プロパティが有効になっていることを確認してください。このプロパティは、「サーバー」→「ServerName」→「プロトコル」の下にあります。ServerNameは、Oracle WebLogic Serverの名前です。

注意:

JDeveloperは、クラスタに属する個々の管理対象サーバーへのアプリケーションのデプロイをサポートしていません。Oracle WebLogic Server管理コンソールやその他のOracle WebLogicツールを使用してクラスタ内の1つ以上の管理対象サーバーをターゲットに設定することは可能ですが、クラスタに悪影響を及ぼす可能性があります。Oracle WebLogic Serverクラスタへのデプロイの詳細は、『Oracle Application Server管理者ガイド』を参照してください。

JDeveloperからターゲット・アプリケーション・サーバーにデプロイする手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「deployment profile」を選択します。

2. デプロイ・ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。

3. 「サーバーの選択」ページで、アプリケーション・サーバー接続を選択します。

4. WebLogic Serverインスタンスにデプロイしている場合は、「WebLogicオプション」ページが表示されます。デプロイ・オプションを選択し、「次へ」をクリックします。

注意:

ADFアプリケーションをデプロイしている場合は、「ドメイン内の全インスタンスへのデプロイ」オプションは使用しないでください。

5. 「終了」をクリックします。
デプロイ中は、処理ステップがデプロイメント・ログ・ウィンドウに表示されます。作成中のモジュールの内容(アーカイブまたは展開EAR)を確認するには、ログ・ウィンドウに表示されたリンクをクリックします。アーカイブ・ファイルまたは展開EARファイルが該当するエディタまたはディレクトリ・ウィンドウで開き、確認できるようになります。

EARファイル内のadf-config.xmlファイルにMDSリポジトリ構成が必要な場合は、図9-6に示す「デプロイメント構成」ダイアログが表示されるので、そこでターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択します。「リポジトリ名」ドロップダウン・リストでは、管理サーバーに登録されているメタデータ・リポジトリのリストからターゲット・メタデータ・リポジトリを選択できます。「パーティション名」ドロップダウン・リストでは、デプロイ中にアプリケーションのメタデータがインポートされるメタデータ・リポジトリ・パーティションを選択できます。WLST/wsadminスクリプト、Oracle WebLogic Server管理ツールまたはWebSphere管理ツールのいずれかを使用して、MDSを構成および登録できます。MDSリポジトリの管理の詳細は、『Oracle Application Server管理者ガイド』を参照してください。

図9-6 デプロイメントのMDS構成およびカスタマイズ

注意:

Java EEアプリケーションをデプロイする場合は、アプリケーション・ナビゲータ内でJava EEアプリケーションの隣にあるアプリケーション・メニューをクリックします。

アプリケーション・サーバー接続の作成の詳細は、9.3.1項「ターゲット・アプリケーション・サーバーへの接続の作成方法」を参照してください。

ヒント:

大きなEARファイルをデプロイしようとすると、JDeveloperで例外が発生する場合があります。この場合は、Oracle WebLogic Server管理コンソールを使用してアプリケーションをデプロイしてください。

9.4.2 デプロイメント用のEARファイルの作成方法

デプロイメント・プロファイルを使用してアーカイブ・ファイル(EARファイル)を作成することもできます。作成したアーカイブ・ファイルは、Enterprise Manager、WLSTスクリプト、Oracle WebLogic Server管理コンソールのいずれかを使用してデプロイできます。

Oracle ADF Java EEアプリケーションはEARファイル(通常はWAR、MAR、JARのコンポーネントを含む)にカプセル化されますが、部分的にEARではデプロイされないことがあります。

EARアーカイブ・ファイルを作成する手順:

- アプリケーション・ナビゲータで、デプロイメント・プロファイルを含むアプリケーションを右クリックし、「デプロイ」→「deployment profile」→「EARファイルへ」を選択します。
EARファイルがアプリケーションレベルでデプロイされ、そのEARファイルにデータ・モデル・プロジェクトのJARファイルとビュー・コントローラ・プロジェクトのWARファイルへの依存性が存在する場合、各ファイルはデフォルトで次のディレクトリに保存されます。

- ApplicationDirectory/deploy/EARdeploymentprofile.EAR

- ApplicationDirectory/ModelProject/deploy/JARdeploymentprofile.JAR

- ApplicationDirectory/ViewControllerProject/deploy/WARdeploymentprofile.WAR

ヒント:

アーカイブ・ファイルの作成時に生成されたメッセージを確認するには、「表示」→「ログ」を選択し、「デプロイメント」タブを選択します。

9.4.3 ADFライブラリについて

ADFライブラリは、ADFコンポーネント(ADFタスク・フロー、ページ、アプリケーション・モジュールなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。

リソース・パレットを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・コンポーネントの再利用に関する項を参照してください。

9.4.4 ADFライブラリに適用された新しいカスタマイズのデプロイ方法

ADFライブラリ用に新しいカスタマイズを作成した場合は、MARプロファイルを使用して、このカスタマイズをADFライブラリを使用する任意のデプロイ済アプリケーションにデプロイできます。たとえば、ADFLibraryBを使用するapplicationAがリモート・アプリケーション・サーバーにデプロイされたとします。その後、新しいカスタマイズがADFLibraryBに追加された場合は、この更新されたカスタマイズをapplicationAにデプロイするだけで済みます。アプリケーション全体を再パッケージ化したり再デプロイする必要はありません。また、MDSリポジトリに手動でパッチを適用する必要もありません。

注意:

この手順は、ADFライブラリのカスタマイズ変更を、リモート・アプリケーション・サーバーのデプロイ済アプリケーションに適用するためのものです。カスタマイズを初めてMARにパッケージ化し、最終的にEARの一部とするための手順ではありません。MARを使用したカスタマイズの初回パッケージ化の詳細は、第9.3.2.2項「MARデプロイメント・プロファイルの作成」を参照してください。

ADFライブラリのカスタマイズをデプロイするには、デプロイするカスタマイズのみを格納した新しいMARプロファイルを作成し、JDeveloperを使用して次を実行します。

- カスタマイズをリモート・アプリケーション・サーバーのMDSリポジトリに直接デプロイします。

- カスタマイズをJARにデプロイします。次に、Fusion Middleware Controlなどのツールを使用して、JARをMDSリポジトリにインポートします。

9.4.4.1 デプロイ済アプリケーションへのカスタマイズのエクスポート

カスタマイズは、JDeveloperからリモート・アプリケーション・サーバーのデプロイ済アプリケーションのMDSリポジトリに直接エクスポートできます。

始める前に:

JDeveloperを使用して、ADFライブラリに新しいカスタマイズを作成します。

カスタマイズをアプリケーション・サーバーに直接エクスポートする手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「メタデータ」を選択します。

2. 「デプロイメント・アクション」ページのメタデータのデプロイダイアログで、「デプロイ済アプリケーションへのエクスポート」を選択し、「次へ」をクリックします。
MARプロファイルがアプリケーションのEARプロファイルに格納されると、「デプロイ済アプリケーションへのエクスポート」がグレー表示されて無効化されます。

3. 「アプリケーション・サーバー」ページで、目的のアプリケーション・サーバー接続を選択し、「次へ」をクリックします。

4. WebLogic Serverの場合は、「サーバー・インスタンス」ページが表示されます。このページで、デプロイ済アプリケーションを含むサーバー・インスタンスを選択し、「次へ」をクリックします。

5. 「デプロイ済アプリケーション」ページで、カスタマイズを適用するアプリケーションを選択し、「次へ」をクリックします。

6. サンドボックスにデプロイする場合は、「サンドボックス・インスタンス」ページで、「関連するサンドボックスにデプロイ」を選択し、「次へ」をクリックします。

7. 「サマリー」ページで、内容を確認して「終了」をクリックします。

9.4.4.2 JARへのカスタマイズのデプロイ

ADFライブラリのカスタマイズをJARにデプロイする場合は、MARプロファイルに定義されているとおりにコンテンツをパッケージ化します。

始める前に:

JDeveloperを使用して、ADFライブラリに新しいカスタマイズを作成します。

カスタマイズをJARとしてデプロイする手順:

1. アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「メタデータ」を選択します。

2. 「デプロイメント・アクション」ページのメタデータのデプロイダイアログで、「MARにデプロイ」を選択します。

3. 「サマリー」ページで「終了」をクリックします。

4. Enterprise Manager Fusion Middleware Controlまたはアプリケーション・サーバーの管理ツールを使用して、JARをMDSリポジトリにインポートします。

9.4.5 ADFライブラリについて

ADFライブラリは、ADFコンポーネント(ADFタスク・フローまたはページなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。

リソース・パレットを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・コンポーネントの再利用に関する項を参照してください。

9.4.6 EARファイルとパッケージ化について

Oracle ADFアプリケーションをEARファイルにパッケージ化する場合、EARファイルには次のものを組み込むことができます。

- WARファイル: Webベースのビュー・コントローラ・プロジェクトはそれぞれWARファイルにパッケージ化します。

- MARファイル: アプリケーションとともにデプロイするカスタマイズ内容がある場合、カスタマイズ内容はMARにパッケージ化します。

- ADFライブラリJARファイル: アプリケーションでADFライブラリJARが使用される場合、そのJARファイルはEARにパッケージ化できます。

- その他のJARファイル: アプリケーションに必要な依存JARファイルが他にもある場合があります。それらはEARにパッケージ化できます。

9.4.7 スクリプトとAntを使用したアプリケーションのデプロイ方法

コマンドを使用してアプリケーションをデプロイし、そのコマンドをスクリプトに記述してプロセスを自動化することができます。ojdeployコマンドを使用すると、JDeveloperなしでアプリケーションをデプロイできます。Antスクリプトを使用してアプリケーションをデプロイすることもできます。JDeveloperには、Antスクリプトの作成に役立つ機能が用意されています。要件によっては、通常のスクリプトをAntスクリプトと組み合せることも可能です。

コマンド、スクリプトおよびAntの詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

9.4.8 JDeveloperランタイム・ライブラリについて

アプリケーションをデプロイすると、必要なライブラリの一部がアプリケーションとともに組み込まれます。JDeveloperランタイム・ライブラリとしてすでにWebLogic Serverにロードされている共有ライブラリも必要になる場合があります。どのJDeveloperライブラリがどのWebLogic Server共有ライブラリにパッケージ化されているかを知っておくと便利です。JDeveloperランタイム・ライブラリの内容の一覧は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』を参照してください。

9.5 デプロイ後の構成

アプリケーションをWebLogic Serverにデプロイしたら、構成タスクを実行できます。

9.5.1 アプリケーションの移行方法

Oracle ADF Java EEアプリケーションをあるWebLogic Serverから別のWebLogic Serverに移行する場合は、初回のデプロイの際と同じステップの一部を実行する必要があります。

一般に、アプリケーションを移行する際には、次の作業を行います。

- ターゲットとなるアプリケーション・サーバーにADFランタイムをロードします(まだインストールされていない場合)。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。

- ターゲットとなるWebLogic Serverインスタンスを正しいデータベース接続情報またはURL接続情報で構成します。

- セキュリティ情報をソースからターゲットに移行します。詳細は、9.3.4項「ADF Securityを有効にしたアプリケーションのデプロイ方法」を参照してください。

- Enterprise Manager、Oracle WebLogic管理コンソール、スクリプトのいずれかを使用してアプリケーションをデプロイします。詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

9.5.2 ADF MBeanを使用したアプリケーションの構成方法

ADF MBeanが有効化され、デプロイ済アプリケーションとともにパッケージ化されている場合、Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用してADFプロパティを構成できます。アプリケーションをMBeanに対して有効化する手順は、9.3.6項「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。

ADF MBeanを使用したADFアプリケーションの構成方法の詳細は、Oracle Fusion Middleware Oracle Application Development Frameworkの管理者ガイドを参照してください。

9.5.3 WebSphereの結果セット再利用の構成方法

WebSphere Application ServerにデプロイされたADFアプリケーションは、共有データベース接続を使用します。WebSphereでnon-transactional datasourceおよびDisableMultiThreadedServletConnectionMgmtプロパティを設定して、アプリケーションが結果セットをリクエスト全体で再利用できるようにする必要があります。

これらのプロパティを設定しないと、WebSphereは結果セットをリクエスト間で閉じます。

詳細は、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドのWebSphere Application Serverの構成に関する項を参照してください。

9.6 アプリケーションのテストとデプロイの検証

アプリケーションは、デプロイが完了したら、Oracle WebLogic Serverからテストすることができます。ADFアプリケーションをテストするには、ブラウザ・ウィンドウを開き、次のURLを入力します。

- Faces以外のページの場合: http://<host>:port/<context root>/<page>

- Facesページの場合: http://<host>:port/<context root>/faces/<view_id>
<view_id>は、ADFタスク・フローにおけるビュー・アクティビティのビューIDです。

ヒント:

アプリケーションのコンテキスト・ルートは、ビュー・コントローラ・プロジェクト設定に、デフォルトでApplicationName/ProjectName/context-rootとして設定されています。この名前を短くするには、ターゲット・アプリケーション・サーバー全体で一意の名前を指定します。ビュー・コントローラ・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログで、「Java EEアプリケーション」を選択し、コンテキスト・ルートの一意の名前を入力します。

注意:

FacesページのURLには、/facesが含まれている必要があります。これは、JDeveloperがFacesサーブレットとの関連付けのために、/facesというURLパターンを使用するようweb.xmlファイルを構成するためです。Facesサーブレットは、リクエスト単位処理を実行し、URL内の/faces部を取り除いた後、そのURLをJSPに転送します。URLに/facesを指定しないと、Facesサーブレットは関与しません(URLパターンが一致しないためです)。JSPは必要なJSFリクエスト単位処理なしで実行されます。

Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved.