この章の内容は次のとおりです。
データ・コントロールを生成すると、それ以上変更を加えずに、データ・モデルとアプリケーション内のUIコンポーネントとの間のバインディングを作成するためにそれらを使用できます。さらに、データ・コントロールを構成して、データ・モデルにビジネス・ロジックやその他の機能を追加し、UIコンポーネントの作成に「データ・コントロール」パネルを使用する際にそれらの機能を適用できます。たとえば、作成するデータ・コントロールのタイプに応じて、次の作業を行うことができます。
属性のデフォルト値の構成
属性へのラベルおよびツールチップの追加
ADF Faces UIから式言語(EL)を介して参照可能なカスタム・メタデータ(通常は名前-値ペア)の追加
計算属性の追加
属性レベルの検証ルールとカスタム・エラー・メッセージの追加
宣言的な検索フォームの定義
データ・コントロールを作成すると、データ・コントロールについて、値と動作の標準的なセットが設定されます。たとえば、属性のラベルのクライアントでの表示方法がデータ・コントロールによって決定されます。データ・コントロールの要素に対応するデータ・コントロール構造ファイルを作成および変更することによって、これらの値と動作を構成できます。まず、.dcx
ファイルの概要エディタを使用して、データ・コントロール構造ファイルを生成します。
データ・コントロールを構成可能にするには、DataControls.dcx
ファイルの概要エディタを使用し、データ・コントロールに含まれるオブジェクトに対応するデータ・コントロール構造ファイルを作成します。個別のデータ・コントロール構造ファイルを編集できるようになります。
始める前に:
データ・コントロール構成の一般的な知識があると役立ちます。詳細は、「データ・コントロールの構成」を参照してください。
また、「ADFデータ・コントロールの作成方法」の説明に従って、データ・コントロールを作成する必要があります。
データ・コントロールを編集するには:
データ・コントロールを編集すると、JDeveloperにより、影響を受けたコレクションのメタデータが含まれているデータ・コントロール構造ファイルが作成され、そのファイルが概要エディタで開かれます。このファイルには、そのコレクション固有のデータ・コントロールの構成データ(データ・オブジェクトに対して指定したUIヒントまたはバリデータなど)が保存されています。
データ・コントロール構造ファイルのベース名は、対応するデータ・オブジェクトのものと同じです。たとえば、Customer.java
エンティティBeanに対応するコレクション・ノードが選択されている状態で「編集」アイコンをクリックすると、データ・コントロール構造ファイルの名前はCustomer.xml
となります。データ・コントロール構成ファイルはBeanクラスのパッケージに対応するパッケージに生成され、パッケージ名にpersdef
が付加されます。たとえば、Customer.java
Beanがmodel
パッケージ内にある場合、Customer.xml
データ・コントロール定義ファイルはpersdef.model
パッケージ内に生成されます。データ・コントロール構成ファイルが生成された後、概要エディタを使用してそのファイルをさらに構成できます。
データ・コントロール構造ファイルには、次の情報が含まれます。
属性: サービスのすべての属性を表します。たとえば、エンティティBeanの場合は、データベース列にマップされたBeanプロパティごとに属性が存在します。また、一時属性も追加できます。これらの属性のUIでの表示方法を定義するUIヒントを設定できます。属性値が必須か、一意である必要があるか、表示可能かどうかなどの他のプロパティを設定することもできます。詳細は、「属性の操作」を参照してください。
属性の検証を設定したり、カスタム・プロパティを作成することもできます。検証の詳細は、「属性への検証ルールの宣言的な定義」を参照してください。カスタム・プロパティの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のカスタム・プロパティによって駆動される汎用機能の実装方法に関する項を参照してください。
アクセッサ: 結果セットを返すデータ・コントロール要素を表します。
名前付き基準: 表示された行をフィルタリングするためのルールを作成できます。名前付き基準は、JPAベースのデータ・コントロールに対して使用できます。
詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
値リスト: 現在のデータ・オブジェクトの属性と、別のデータ・オブジェクトの行の間に、宣言的な関連付けを作成できます。その後、これらの関連からドロップダウン・リストなどのコンポーネントを作成できます。
操作: データ・コントロールの組込み操作で使用されるデータ・オブジェクト上のメソッドを表します。たとえば、それぞれ「作成」および「削除」組込み操作で使用されるadd
およびremove
メソッドなどです。
図7-2に、Item
Beanのデータ・コントロール構造ファイルを示します。
図7-2 概要エディタでのデータ・コントロール構造ファイル
注意:
データ・コントロール構造ファイルの概要エディタには、データ・オブジェクトに関連付けられているすべての属性、アクセッサおよび操作が表示されます。ただし、データ・コントロール構造ファイルのXMLソースには、編集した要素の定義のみが含まれます。基本要素は、データ・オブジェクトからイントロスペクションされます。また、基礎となるデータ・オブジェクトに変更を加えると、データ・コントロールはそれらの変更を継承します。
データ・コントロール構造ファイルのフォーマットがリリース11.1.2では変更され、名前付き基準や値リストなどの追加機能が有効になりました。また、データ・コントロール構造ファイルはオンデマンドでのみ生成されるようになりました。たとえば、メタデータをデータ・コントロール・オブジェクトに追加する必要がある場合や、データ・コントロールを作成する際に構造ファイルの生成を要求した場合などに生成されます。データ・コントロール・オブジェクトのメタデータのうち、データ・コントロールのベースとなるオブジェクト内ですでに使用可能な情報を単に繰り返すものは生成されなくなりました。JPAベースのデータ・コントロールの場合、UpdatableSingleValue.xml
ファイルとUpdateableCollection.xml
ファイルは生成されなくなりました。
前のリリースで作成したデータ・コントロールがある場合は、JDeveloperの新しいバージョンで開発したアプリケーション内でそのデータ・コントロールを引き続き使用できます。ただし、そのデータ・コントロールに変更を加える予定がある場合は、まずデータ・コントロールを新しいフォーマットに変換する必要があります。古いフォーマットのデータ・コントロールの変更はサポートされていません。
現在の構造定義フォーマットを使用するように古いデータ・コントロールを変換するには、次の表からの実装クラスのエントリを更新するなど、DataControls.dcx
ファイルにいくつか変更を加える必要があります。
表7-1 データ・コントロール実装クラス
データ・コントロール・タイプ | データ・コントロール実装クラス |
---|---|
EJB |
|
Bean |
|
Webサービス |
|
URLサービス |
|
新しいデータ・コントロール構造ファイルも生成する必要があります。ただし、既存のUIコンポーネントを更新されたデータ・コントロールに再バインドする必要はありません。
データ・コントロールを前のリリースから移行する手順は次のとおりです。
JDeveloperの現在のバージョンで、対象のデータ・コントロールを含むアプリケーション・ワークスペースを開きます。
DataControls.dcx
ファイルを開き、次の変更を行います。
ImplDef
属性の値を、該当するデータ・コントロール実装クラスの名前に変更します(表7-1を参照)。
オプションで、BeanおよびEJBデータ・コントロールの場合、データ・コントロールのbean-definition
要素またはejb-definition
要素にDataControlHandler
属性を追加して、問合せとページングの完全なサポートを有効にします。JPAベースのデータ・コントロールの場合、通常はoracle.adf.model.adapter.bean.jpa.JPQLDataFilterHandler
を使用します。非JPAデータ・コントロールの場合、通常はoracle.adf.model.adapter.bean.DataFilterHandler
を使用します。
オプションで、JPAベースのBeanおよびEJBデータ・コントロールの場合、データ・コントロールのbean-definition
要素またはejb-definition
要素にaccessMode
属性を追加して、データ・コントロールのページングのタイプを指定します。accessMode
の値は、scrollable
またはrangePaging
のどちらかです。アクセス・モードの詳細は、「EJBデータ・コントロールでのデータのページ分割されたフェッチ」を参照してください。
オプションで、JPAベースのBeanおよびEJBデータ・コントロールの場合、データ・コントロールのbean-definition
要素またはejb-definition
要素にeagerPersist
属性を追加して、新規レコードの永続化を自動的に行うかどうかを指定します。eagerPersist
の値は、false
またはtrue
のどちらかです。詳細は、「新規行の自動永続化について」を参照してください。
メタデータを追加したデータ・コントロール(UIヒントやバリデータなど)の場合は、「データ・コントロールを編集する方法」で説明しているとおりに新規データ・コントロール構造ファイルを作成します。
オプションで、データ・コントロールのプロジェクト内にある古いデータ・コントロール構造ファイルを削除します。これには次のものがあります。
UpdatableSingleValue.xml
UpdateableCollection.xml
データ・コントロール・オブジェクトのメタデータを含む、.xml
が末尾に付いたファイル(ステップ3で生成した新しいファイルは含まない)。
次の例は、変換されたDataControls.dcx
ファイルを示しています。
<?xml version="1.0" encoding="UTF-8" ?> <DataControlConfigs xmlns="http://xmlns.oracle.com/adfm/configuration" version="11.1.1.61.92" id="DataControls" Package="model1"> <AdapterDataControl id="BeanPagingDC1" FactoryClass="oracle.adf.model.adapter.DataControlFactoryImpl"ImplDef="oracle.adf.model.adapter.bean.BeanDCDefinition"
SupportsTransactions="false" SupportsSortCollection="true" SupportsResetState="false" SupportsRangesize="false" SupportsFindMode="false" SupportsUpdates="true" Definition="model1.BeanPagingDC1" BeanClass="model1.BeanPagingDC1" xmlns="http://xmlns.oracle.com/adfm/datacontrol"> <CreatableTypes> <TypeInfo FullName="model1.SampleData1"/> <TypeInfo FullName="model1.BeanPagingDC1"/> </CreatableTypes> <Source> <bean-definition BeanClass="model1.BeanPagingDC1"DataControlHandler="oracle.adf.model.adapter.bean.DataFilterHandler"
AccessMode="scrollable"
xmlns="http://xmlns.oracle.com/adfm/adapter/bean"/> </Source> </AdapterDataControl> </DataControlConfigs>
データ・コントロールに含まれるすべてのオブジェクトをOracle Metadata Services (MDS)カスタマイズ可能にする必要がある場合は、パッケージされたアプリケーションにこれらのオブジェクトのデータ・コントロール構造ファイルが含まれている必要があります。
アダプタ・フレームワークに基づくデータ・コントロールを作成する際には、データ・コントロール構造ファイルはデフォルトでは生成されません。これは、特定のオブジェクトにメタデータを追加しない場合、データ・コントロールにこれらのファイルは必要ないからです。「データ・コントロールを編集する方法」で説明しているように、通常、データ・コントロール構造ファイルは、データ・コントロールを編集して宣言的なメタデータ(UIヒントまたはバリデータなど)を追加すると、1つのデータ・コントロール・オブジェクト用にのみ生成されます。各データ・コントロール・オブジェクトにデータ・コントロール構造ファイルを作成するには、データ・コントロール・オブジェクトごとにその手順を繰り返す必要があります。
注意:
「EJBデータ・コントロールの作成」ウィザードと「Beanデータ・コントロールの作成」ウィザードには「メタデータの生成」チェック・ボックスがあり、データ・コントロールの作成時にデータ・コントロール・オブジェクトごとに構造ファイルが生成されるようにするには、このチェック・ボックスを選択します。
MDSの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「MDSによるアプリケーションのカスタマイズ」を参照してください。
ビジネス・サービスのデータ・コントロールを作成する際、個々のデータ・オブジェクトについて作成するデータ・コントロール構造ファイルで宣言的にデータ・オブジェクトの永続属性の機能を拡張できます。たとえば、UIコンポーネントの属性のデフォルト表示を制御する検証ルールを作成し、UIヒントを設定できます。さらに、一時属性を作成できます。
いずれの場合も、これらのプロパティはデータ・コントロール構造ファイルの概要エディタの「属性」ページで設定します。データ・コントロール構造ファイルの作成の詳細は、「データ・コントロールの編集方法」を参照してください。
データ・オブジェクトのデータ・コントロール構造ファイルの概要エディタで、そのデータ・オブジェクトの主キーとして属性を指定できます(データ・オブジェクトの基礎クラスでまだ指定していない場合)。
始める前に:
属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性の操作」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
属性を主キーとして設定する手順は次のとおりです。
注意:
属性がクラス内ですでに主キーとして指定されている場合は(たとえば、JPA @IDアノテーションによって)、データ・コントロールはその設定を継承し、「キー属性」チェック・ボックスが選択されます。ただし、この場合は、「キー属性」オプションを選択解除することはできません。
「更新可能」
プロパティにより、特定の属性が更新可能かどうかを制御します。「更新可能」
プロパティでは次の値を選択できます。
常に: 属性は常に更新可能です。
なし: 属性は読取り専用です。
新規の間: 行を初めて作成するトランザクション中は属性を設定できますが、データベースへのコミットが成功した後、属性は読取り専用になります。
始める前に:
属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性の操作」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
属性の更新可能性を設定する手順:
値のタイプが「リテラル」に設定されている場合、「詳細」セクションの「値」フィールドには、属性のデフォルト値を静的に指定できます。たとえば、ServiceRequest
エンティティBeanのStatus
属性のデフォルト値をOpen
に設定したり、User
BeanのUserRole
属性のデフォルト値をuser
に設定できます。
始める前に:
属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性の操作」を参照してください。
属性の静的なデフォルト値を定義する手順:
属性のデフォルト値は、Groovy式を使用して定義できます。デフォルト値を実行時に変更する場合、この方法が便利です。ただし、デフォルト値が常に同じである場合は、「リテラル」タイプ(「詳細」タブ)で値のフィールドを使用する方が値の表示および管理が容易です。Groovyの使用の詳細は、「Groovy言語サポート」を参照してください。
始める前に:
属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性の操作」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
Groovy式を使用してデフォルト値を定義する手順:
Groovy式を使用してデフォルト値を定義すると、データ・コントロール構造ファイルの対応する属性のタグ内に<RecalcCondition>
タグと<TransientExpression>
タグが追加されます。また、式に依存性を指定した場合は、<Dependencies>
タグが追加されます。次の例は、作成された式でデフォルト値がprice
属性とquantity
属性の積として定義され、再計算条件が「常に」として指定されている場合に、LineItemTotal
属性に追加されるコードを示しています。
<RecalcCondition><![CDATA[true]]></RecalcCondition> <TransientExpression><![CDATA[price * quantity]]></TransientExpression> <Dependencies> <Item Value="price"/> <Item Value="quantity"/> </Dependencies>
属性のUIヒントを設定し、それらの属性を使用するすべてのUIコンポーネントでそれらの属性が一貫したローカライズ可能な方法で表示およびラベル付けされるように設定できます。属性に対してUIヒントを作成するには、「アプリケーション」ウィンドウからアクセス可能な、データ・オブジェクトのデータ・コントロール構造ファイルの概要エディタを使用します。
注意:
EJBおよびBeanデータ・コントロールのUIヒントを設定するためにデータ・コントロール構造ファイルを使用する代わりの方法として、Beanクラスに直接アノテーションを追加して、多くの同じ機能を作成することができます。詳細は、「アノテーションを使用した属性のUIヒントの提供」を参照してください。
始める前に:
属性プロパティの設定方法の知識があると役立ちます。詳細は、「属性の操作」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
UIヒントを設定する手順:
各種のUIヒントについては、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のビュー・オブジェクトのUIヒントの定義に関する項を参照してください。
注意:
『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』に示されているビュー・オブジェクトは、SQL問合せをカプセル化し、結果の処理を簡単にするために使用されるADFビジネス・コンポーネントです。データ・コントロール構造ファイルは、アダプタ・データ・コントロール内のビュー・オブジェクトとほぼ同じように機能し、同じ構成オプションを多数提供しています。ビュー・オブジェクトの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のビュー・オブジェクトについてに関する項を参照してください。
属性に対してUIヒントを設定すると、それらのヒントはプロパティとして格納されます。プロパティのタグがデータ・オブジェクトのデータ・コントロール構造ファイルに追加され、プロパティの値はリソース・バンドル・ファイルに保存されます。リソース・バンドル・ファイルが存在しない場合は、データ・コントロールのパッケージに生成され、初めてUIヒントを設定した際にプロジェクト名に従って名前が設定されます。
次の例に、Item.xml
データ・コントロール構造ファイルにおけるprice
属性のコードを示します。属性に対して設定されているラベルおよびフォーマット・タイプ・ヒントのタグも含まれます。
<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>
次の例に、ModelBundle.properties
リソース・バンドル・ファイルにおけるラベルおよびフォーマット・タイプ・ヒントの対応するエントリを示します。これらにはプロジェクトのローカライズ可能なプロパティすべての値も含まれています。
model.Item.price_LABEL=Price . . . model.Item.price_FMT_FORMATTER=oracle.jbo.format.DefaultCurrencyFormatter
データ・コントロール構造ファイルには、基礎となる表内の列にマップされる属性のみでなく、計算された値を表示する一時属性を組み込むことができます。
たとえば、FullName
などの作成した一時属性は、FirstName
属性の値とLastName
属性の値を連結した値に基づいて計算できます。
一時属性を作成すると、属性定義でGroovy式を使用してデフォルト値を指定できます。
一時属性を作成するには、概要エディタの「属性」ページを使用します。
始める前に:
一時属性および計算属性の知識があると役立ちます。詳細は、「データ・オブジェクトへの一時属性の追加」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
データ・オブジェクトのデータ・コントロール構造ファイルに一時属性を追加する手順は次のとおりです。
一時属性を追加すると、JDeveloperによって<ViewAttribute>
タグがデータ・オブジェクトのデータ・コントロール構造ファイルに追加され、新しい属性が反映されます。次の例は、LineItemTotal
という一時属性のXMLコードを示します。これはprice
およびquantity
属性の値を乗算する式を基礎としています。
<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>
検証ルールを作成および管理する最も容易な方法は、宣言的検証ルールを使用することです。宣言的検証ルールは概要エディタを使用して定義され、いったん作成されると、データ・オブジェクトのデータ・コントロール構造ファイルに保存されます。ビジネス・ロジックをこのようにカプセル化することにより、ビジネス情報にアクセスするすべてのクライアントで情報が一貫して検証され、検証の保管先を集中化することによって管理が容易になります。
Oracle ADFでは、一般的なビジネス上のニーズの多くを満たすことができる組込みの宣言的な検証ルールが用意されています。「検証ルールでのGroovy式の使用方法」で説明されているように、Groovy式を検証の基礎にすることもできます。
検証ルールを追加する際、適切なエラー・メッセージを提供し、後に必要に応じて容易に他の言語に翻訳できます。また、重大度レベルも設定できます。
アプリケーションがビジネス・レイヤー検証に加えてページ・レベルでの検証も使用する必要がある場合は、データ・オブジェクトで利用できる宣言的検証機能の多くをページ定義レベルでも利用できます。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFモデル・レイヤーでの検証の使用」の章を参照してください。
注意:
カスタム検証クラスを実装することによって検証ルールを追加することもできます。アプリケーションで複数回使用する必要のある複雑なパラメータ化された検証ルール(クレジット・カードの番号のチェックなど)を定義する必要がある場合、この方法が特に便利です。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のカスタム検証規則の実装に関する項を参照してください。
データ・オブジェクトに検証規則を追加する手順は、ほとんどの検証規則と同じで、「検証ルールの追加」ダイアログを使用します。このダイアログを開くには、データ・オブジェクトのデータ・コントロール構造ファイルを開き、「属性」ページで属性を選択し、「検証ルール」タブをクリックして「追加」アイコンをクリックします。
「検証ルールの追加」ダイアログを使用してルールを宣言的に定義すると、そのルール定義が属性の有効な条件を指定することに注意する必要があります。実行時に、ユーザーが入力したエントリがルール定義に対して評価され、エントリが指定された基準を満たさない場合、エラーまたは警告が発せられます。たとえば、12より小さいか等しい
必要のある属性に対して長さのバリデータを指定した場合、エントリが12文字よりも長いと検証が失敗し、エラーまたは警告が発行されます。
データ・コントロール構造ファイルに宣言的検証ルールを追加するには、データ・オブジェクトの概要エディタの「属性」ページを使用します。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
検証規則を追加するには:
データ・オブジェクトに検証ルールを追加すると、データ・オブジェクトのデータ・コントロール構造ファイルが更新され、使用したルールと入力したルールのプロパティを示すエントリが含まれます。
次の例に示すように、たとえば、dateShipped
属性に、出荷日がdateOrdered
属性よりも前ではないことを確認する比較検証ルールを追加すると、XMLファイルに<validation:CompareValidationBean>
エントリが作成されます。
<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>
組込みの宣言的な検証規則は、大部分のビジネス上のニーズを満たすことができます。このような規則は、コードの記述がないため実装が簡単です。検証のタイプとその使用方法を選択するには、ユーザー・インタフェース・ツールを使用します。
組込みの宣言的な検証規則を使用すると、次のことが可能です。
属性とリテラル値または式を比較します。
手動で指定した値リストに対する検証を行います。
値が一定の範囲内にあること、または特定のバイト数または文字数に制限されていることを確認します。
正規表現による検証、またはGroovy式の評価を行います。
Compare Validatorは、属性と値の論理比較を実行します。比較バリデータの追加時に、演算子および比較対象を指定します。次のものを比較できます。
リテラル値
比較バリデータでリテラル値を使用すると、属性の値は指定したリテラル値と比較されます。この種類の比較を使用する場合は、データの型と書式を考慮することが重要です。リテラル値は、ルールを適用する属性のデータ型で指定した書式に準拠する必要があります。すべての場合において、型は属性のタイプ・マッピングに対応します。
たとえば、列タイプDATEの属性はoracle.jbo.domain.Date
クラスにマッピングされますが、これはjava.sql.TimeStamp
およびjava.sql.Date
によって受け入れられるのと同じ書式で日付と時間を受け入れます。書式マスクを使用することにより、属性の値の書式が指定されたリテラルに一致するよう指定できます。
式
式のオプションについては、「検証ルールでのGroovy式の使用方法」を参照してください。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
比較に基づいて検証するには:
Compare Validatorを作成すると、<validation:CompareValidationBean>
タグがデータ・オブジェクトのデータ・コントロール構造ファイルに追加されます。
「検証規則の追加時の処理」の例は、dateShipped
属性に対するバリデータのXMLコードを示しています。
List Validatorにより、ユーザーが手動で指定した値リストと属性が比較されます。バリデータは、データ・オブジェクト属性の値がそのリスト内(指定された場合はリスト外)にあることを確認します。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
値リストを使用して検証するには:
値リストを使用して検証すると、<validation:ListValidationBean>
タグがデータ・オブジェクトのデータ・コントロール構造ファイルに追加されます。
Range Validatorは、属性と値の範囲の論理比較を実行します。範囲バリデータの追加時に、最小および最大のリテラル値を指定します。Range Validatorは、属性の値が範囲内(指定された場合は、範囲外)にあることを検証します。
最小および最大値を動的に算出する必要がある場合や、他の属性を参照する必要がある場合は、Script Expression Validatorを使用し、Groovy式を指定します。詳細は、「Groovy式でのADFオブジェクトの参照方法」を参照してください。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
特定の範囲内を検証するには:
範囲に対して検証すると、<validation:RangeValidationBean>
タグがデータ・コントロール構造ファイルに追加されます。
次の例は、最小値が0で最大値が10のquantity
属性を示します。
<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>
長さバリデータは、属性値の文字列長(文字またはバイト)が、指定した数より小さい、等しい、それより大きい、またはその範囲内かどうかを検証します。たとえば、ユーザーがパスワードまたはPINを入力するフィールドがあり、それが6文字以上、10文字以下であることを検証する必要があるとします。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
バイトまたは文字数を検証するには:
長さを使用して検証すると、<validation:LengthValidationBean>
タグがデータ・コントロール構造ファイルに追加されます。次の例は、最小値6、最大値10を指定したBetween演算子を示しています。
<validation:LengthValidationBean OnAttribute="pin" CompareType="BETWEEN" DataType="CHARACTER" MinValue="6" MaxValue="10" Inverse="false"/>
正規表現バリデータは、Java正規表現によって指定されたマスクに対して属性値を比較します。
メタデータでパーソナライズできる式を作成する場合は、Script Expression Validatorを使用できます。詳細は、「検証ルールでのGroovy式の使用方法」を参照してください。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
正規表現を使用して検証する手順:
図7-4は、Regular Expression Validatorを選択して、Email
属性が事前定義されたEmail Address式に一致することを検証する場合のダイアログを示しています。
図7-4 電子メール・アドレスを照合するRegular Expression Validator
Groovy式は、データ・コントロール構造ファイルに格納されている、Javaのようなスクリプト・コードです。実行時でも値の変更や指定ができます。
検証ルールの作成の詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
ビジネス・ロジックでのGroovy式使用の詳細は、「Groovy言語サポート」を参照してください。
Groovy式を使用してtrue/false文を返すことができます。スクリプト式バリデータでは、必ず式がtrue
またはfalse
を返す必要があり、そうでなければadf.error.raise
/warn()
メソッドがコールされます。この機能の一般的な用途は、属性値の検証です(アカウント番号が有効であるかの確認など)。
注意:
adf.error.raise()
およびadf.error.warn()
メソッドを使用することにより(単純にtrue
またはfalse
を返すかわりに)、ユーザーに表示するメッセージ・テキストを定義でき、バリデータを特定の属性に関連付けることができます。詳細は、「Groovyを使用した条件付きでのエラー・メッセージの呼出し」を参照してください。
始める前に:
データ・コントロール構造ファイルにおける検証に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
また、検証ルールでのGroovyの使用方法を理解していると役立ちます。詳細は、「検証ルールでのGroovy式の使用方法」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
true/false式を使用して検証するには:
Groovy式を作成すると、データ・オブジェクトのデータ・コントロール構造ファイルに保存されます。Groovy式は、<TransientExpression>
タグによってラップされます。一部のGroovy式では、<TransientExpression>
タグは、<validation:ExpressionValidationBean>
タグによってもラップされます。
現在のオブジェクトのadf.source.dataProvider
プロパティを使用すると、データ・オブジェクトに対してメソッドをコールできます。adf.source.dataProvider
プロパティでは、検証対象のデータ・オブジェクトにアクセスできます。
メソッドがブール型以外で、メソッド名が引数なしのgetXyzAbc()
の場合、XyzAbc
という名前のプロパティのようにその値にアクセスします。たとえば、次のGroovy式により、getXyzAbc()
メソッドがコールされます。
adf.source.dataProvider.XyzAbc
ブール・プロパティの場合は、同じ条件が当てはまりますが、JavaBeansコンポーネントのgetterメソッドの命名パターンが変更され、getXyzAbc()
ではなくisXyzAbc()
を再認識します。データ・オブジェクトのメソッドがJavaBeansのgetterメソッドの命名パターンに一致しない場合や、1つ以上の引数を使用する場合は、完全名を使用したメソッドのようにコールする必要があります。
検証エラー・メッセージはユーザーにとって重要な情報であり、メッセージは不具合やその修正方法を伝達する必要があります。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
検証エラー・メッセージを作成するには:
図7-5 検証ルールの失敗処理メッセージ
検証ルールのエラー・メッセージを作成する際に、メッセージは.properties
ファイルに保存されます。.properties
ファイルとメッセージ文字列は、データ・コントロール構造ファイル内でバリデータのタグのResId
タグ属性から参照されます。
次の例は、エラー・メッセージの場所とキーを指定する検証ルール・タグのResId
属性を示しています。
<validation:CompareValidationBean
Name="dateShipped_Rule_0"
ResId="${adfBundle['model.ModelBundle']['model.Ord.dateShipped_Rule_0']}"
次の例は、エラー・メッセージを含む.properties
ファイルの対応するエントリを示しています。
model.Ord.dateShipped_Rule_0=Date Shipped cannot be before Date Ordered
エラー・メッセージは翻訳可能文字列であり、メッセージ・バンドル・ファイルの翻訳可能UIヒントと同じように管理されます。メッセージ・バンドル・クラス内の定義済ルールのエラー・メッセージを表示するには、そのバリデータに関するデータ・コントロール構造ファイルのエントリのResId
プロパティに対応するメッセージ・バンドルのキーを探します。
adf.error.raise()
およびadf.error.warn()
メソッドを使用して、Groovy式の分岐に応じて様々なエラー・メッセージを条件付きで呼び出すことができます。
式でfalse
が戻される(raise()
メソッドを使用して特定のエラー・メッセージが呼び出されるのに対して)場合、バリデータは、そのバリデータに関連付けられた最初のエラー・メッセージをコールします。
raise()
メソッドの構文は必須パラメータを1つ(メッセージ・バンドルから使用するためのmsgId
)利用し、オプションでattrName
パラメータを利用することができます。
例外をスローするか、処理を継続するかに応じて、adf.error.raise()
およびadf.error.warn()
のいずれのメソッドも使用できます(「検証例外の重大度レベルの設定方法」を参照)。
次の例は、5000以下の値の入力を許可するルールを示しています。値が5000を超える場合は、SALARY_TOO_HIGH_ERROR
リソース・バンドル・プロパティに関連したエラー・メッセージが表示され、検証は失敗します。入力された値が1001と5000の間にある場合、検証は正常に終了しますが、ユーザーに警告が表示されます。
if (newValue > 1000) { if (newValue > 5000) {adf.error.raise("SALARY_TOO_HIGH_ERROR") return false} adf.error.warn("SALARY_LIMIT_WARNING") return true } else { return true }
バリデータのエラー・メッセージには、実行時にサーバーによって解決できる埋込み式を含めることができます。この機能にアクセスするには、Groovy式の結果を表示させるエラー・メッセージ・テキストに名前付きトークン{#}({2}
や{errorParam}
など)を入力するのみです。
「検証規則の編集」ダイアログの「失敗処理」タブで、エラー・メッセージのテキストにトークンを入力すると、ダイアログの下部の「トークン・メッセージ式」表で行が表示され、トークンのGroovy式を入力できます。図7-5は、メッセージ・トークンが含まれている検証ルールに対する失敗メッセージを示しています。
図7-5に示された式は、quantity
属性の値を返すGroovy式です。また、Groovy式を使用して、データ・コントロール構造ファイルで定義されている属性のUIヒントやその他のオブジェクトにアクセスできます。
Groovy式newValue
を使用して入力された値を返すことができます。
Groovyを使用してADFオブジェクトにアクセスする方法の詳細は、「Groovy言語サポート」を参照してください。
検証例外の重大度レベルを、「情報警告」または「エラー」のいずれかに設定できます。重大度レベルを「情報警告」に設定すると、エラー・メッセージが表示されますが、処理は継続します。検証レベルを「エラー」に設定すると、エラーが修正されるまでユーザーは処理を続行できません。
通常、検証例外には「エラー」レベルを使用するため、これがデフォルト設定です。ただし、ユーザーが特定の機密取扱い資格を持っている場合は、情報警告メッセージを実装できます。たとえば、店長は事務員が同じことをした場合に、エラーとして表示されるように変更できます。
検証例外の重大度レベルを設定するには、「検証ルールの追加」ダイアログの「失敗処理」タブを使用します。
始める前に:
データ・コントロール構造ファイルにおける検証ルールの使用に関する知識があると役立ちます。詳細は、「属性への検証ルールの宣言的な定義」を参照してください。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成する必要があります。
検証例外の重大度レベルを設定するには:
JDeveloperでは、JPAベースのデータ・コントロールを対象に、データ・コントロール構造ファイルに関する名前付き基準を作成できます。名前付き基準は、アプリケーションのデータ・モデルで使用し、検索フォームのシードされた問合せとしてユーザーに公開できます。
名前付き基準を指定して、表示する結果をフィルタリングできます。名前付き基準オブジェクトは1つ以上の名前付き基準行の行セットであり、この属性によって対応するデータ・オブジェクト内の属性がミラーリングされます。名前付き基準の定義には、SQL問合せのWHERE
句のように機能する問合せ条件が含まれています。
名前付き基準の結果セットでは、各属性のデータ型はString
であるため、Query-by-Example演算子を使用できます。たとえば、これによってユーザーは"OrderId > 304
"のような条件を入力できます。
特定のデータ・コントロール構造ファイルに対して名前付き基準を定義するには、概要エディタの「名前付き基準」ページを使用します。
個々のアクセッサ結果をフィルタリングする必要がある場合、名前付き基準定義を作成します。デザインタイムで定義した名前付き基準は、ターゲット・データ・コントロール構造ファイルの属性の値をエンド・ユーザーが指定できるような、Query-by-Exampleの検索フォームを簡単に作成する際に使用できます。
たとえば、エンド・ユーザーが顧客名の値および日付を入力することによって、CustomerOrders
コレクションの行が表示されるWebページで結果をフィルタリングできるようにする場合について考えてみましょう。この要件を満たすために、Webページ・デザイナはこの目的に合せて作成された名前付き基準に基づく検索フォームを容易に作成でき、「データ・コントロール」パネルで使用可能にすることができます。「データ・コントロール」パネルでの名前付き基準の使用の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFによるデータバインドされた検索フォームの作成」を参照してください。
JPAベースのデータ・コントロール構造ファイル用の名前付き基準を定義するには、概要エディタでデータ・コントロール構造ファイルを開き、「名前付き基準」ページを使用します。「名前付き基準」ページから開く専用エディタで、属性名(SQL列名ではなく)を使用してWHERE
句に相当するものを作成できます。名前付き基準は、1つのデータ・オブジェクトに対して複数定義できます。
名前付き基準の定義はそれぞれ、次の要素で構成されています。
1つ以上の名前付き基準行。名前付き基準行は、任意の数の名前付き基準グループ、または現在のデータ・コントロール構造ファイルに対して定義されている別の名前付き基準への任意の数の参照で構成されます。
任意の数の名前付き基準アイテムで構成される、オプションの名前付き基準グループ。
属性名、属性に適した演算子、およびオペランドで構成される名前付き基準アイテム。オペランドには、フィルタの値が定義されている場合はリテラル値か、または、属性のプロパティ値へのドット表記アクセスを含むスクリプト式がオプションで利用可能なバインド変数を使用できます。
式の記述には、Groovyスクリプト言語を使用します(「Groovy言語サポート」を参照)。
「ビュー基準の編集」ダイアログで作成する名前付き基準の式では、論理積により、選択した基準アイテム(または基準グループ)とその前にあるアイテム(またはグループ)を式の中でどのように結合するかを指定できます。
AND
結合を使用すると、結合した条件のどちらにも一致する問合せ結果が得られます。それぞれの名前付き基準アイテムを追加する場合は、これがデフォルトになります。
OR
結合を使用すると、結合した条件の少なくとも一方に一致する問合せ結果が得られます。名前付き基準グループに対しては、これがデフォルトになります。
さらに、様々な名前付き基準アイテム間の論理積をより制御するために、ネストされた名前付き基準を作成できます。ネストされた名前付き基準グループは、任意の数のネストされた名前付き基準アイテムで構成されます。ネストされた基準では、その親名前付き基準グループの中で基準を満たしている行が制限されます。たとえば、給与がSalary > 3000
という基準を満たし、かつ所属部署がDeptNo = 10
またはDeptNo = 20
という基準を満たしている従業員のリストを問い合せる場合があります。この場合、1つの項目Salary > 3000
を含む第1のグループを使用して名前付き基準と、2つの項目DeptNo = 10
およびDeptNo =20
を含む第2のグループを使用してネストされた名前付き基準を定義できます。
始める前に:
名前付き基準の知識があると役立ちます。詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
次のタスクを完了する必要があります。
「EJBデータ・コントロールを作成する方法」の説明に従ってEJBデータ・コントロールを作成するか、「JPAベースのBeanデータ・コントロールを作成する方法」の説明に従ってJPAベースのBeanデータ・コントロールを作成し、ウィザードでデータ・コントロールを作成する際に「名前付き基準のサポート」チェック・ボックスを選択します。
「データ・コントロールの編集方法」の説明に従って、必要なデータ・コントロール構造ファイルを作成します。
名前付き基準を定義する手順:
名前付き基準を作成すると、名前付き基準定義がデータ・コントロール構造ファイルに追加され、概要エディタの「名前付き基準」ページに名前が表示されます。
名前付き基準のXMLコードを表示するには、データ・コントロール構造ファイルのソース・エディタを開きます。それぞれの名前付き基準定義には、「名前付き基準の作成」ダイアログで定義したグループの数に対応する、1つ以上の<ViewCriteriaRow>
要素が含まれます。
バインド変数を使用すると、実行時に計算される属性値を名前付き基準に組み込むことができます。
シードされた検索で名前付き基準を使用する場合は、エンド・ユーザーがバインド変数を更新できるようにすることができます。この更新可能オプションを使用する場合、エンド・ユーザーは検索フォームに値を入力する必要があります。
バインド変数が割り当てられている名前付き基準アイテムが必須でない場合、名前付き基準の実行ではバインド変数値を必要としません。この動作を強制する場合、「バインド変数」ダイアログでバインド変数が必須かどうかを指定できます。
バインド変数に対しては、デフォルト値を定義するか、属性プロパティ値へのドット表記法によるアクセスが可能なスクリプト式を記述できます。式の記述には、Groovyスクリプト言語を使用します(「Groovy言語サポート」を参照)。
名前付きバインド変数を名前付き基準に追加する場合は、データ・コントロール構造ファイルの概要エディタにある「名前付き基準」ページを使用します。必要な数のバインド変数を定義できます。
始める前に:
名前付き基準の知識があると役立ちます。詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
次のタスクを完了する必要があります。
名前付きバインド変数を作成する手順:
1つ以上の名前付きバインド変数をデータ・コントロール構造ファイルに追加すると、実行時にこれらの変数の値を容易に表示し、設定できるようになります。各バインド変数の名前、型およびデフォルト値の情報は、データ・オブジェクトのデータ・コントロール構造ファイルに保存されます。バインド変数に対してUIヒントを定義した場合、この情報はデータ・コントロール構造ファイルの他のUIヒントとともにデータ・モデル・プロジェクトのメッセージ・バンドル・ファイルに保存されます。
名前付き基準からUIデザイナによって作成される検索フォームでは、すべてのタイプのネストされた式が動作するわけではありません。特に、検索フォームでは、直接ネストされた名前付き基準をサポートしていません。このタイプのネストされた式では、1つの名前付き基準を別の名前付き基準の直接の子として定義します。それ自体が名前付き基準の子である基準アイテムの子として名前付き基準をネストしたネストされた式は、問合せ検索フォームでサポートされています。名前付き基準を使用して検索フォームを作成する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFによるデータバインドされた検索フォームの作成」を参照してください。
データ・コントロール構造ファイル・コレクションに対して作成された名前付き基準は、Webページ・デザイナがQuery-by-Example検索フォームを作成する際に使用できます。Webページ・デザイナは、「データ・コントロール」パネルから名前付き基準を選択して、Webアプリケーション用の検索フォームを作成します。Webページの検索フォームでは、「データ・コントロール」パネルで選択した名前付き基準に最初にバインドされるADF Faces問合せ検索コンポーネントが利用されます。実行時に、エンド・ユーザーは、「データ・コントロール」パネルに表示されるその他すべての名前付き基準の中からいずれかを選択できます。検索フォームでエンド・ユーザーが選択できる名前付き基準は、開発者シード検索と呼ばれます。問合せコンポーネントでは、「保存済の検索」ドロップダウン・リストに、これらのシードされた検索が自動的に表示されます。検索フォームの作成、およびADF問合せ検索コンポーネントの使用の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFによるデータバインドされた検索フォームの作成」を参照してください。
開発者がシードした検索はモデル・プロジェクト内で作成されるため、「ビュー基準の編集」ダイアログの「UIヒント」ページでは、問合せコンポーネントにおける個々の名前付き基準の実行時の使用方法に対して、デフォルト・プロパティを指定できます。実行時の問合せコンポーネントの動作は、次のシードされた検索プロパティからどれを選択するかによって決まります。
ADF問合せ検索コンポーネントで使用するシードされた検索を作成する場合は、「ビュー基準の編集」ダイアログの「UIヒント」ページで「リストに表示」を選択します。エンド・ユーザーの検索フォームに名前付き基準を表示しない場合は、「リストに表示」の選択を解除します。
始める前に:
名前付き基準の知識があると役立ちます。詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
次のタスクを完了する必要があります。
ユーザー・インタフェースに使用する名前付き基準を構成する手順:
JPAベースのデータ・コントロール上でエンティティ・クラスの名前付き基準を作成する際には、その特定のエンティティに関連した属性のみがフィルタリングに使用できます。ただし、外部キーによって関連付けられる複数の表からデータを集約する、カスタムBeanとJPA問合せに基づいた名前付き基準を作成することも可能です。
始める前に:
名前付き基準の知識があると役立ちます。詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
複数のJPAエンティティに基づく名前付き基準を作成する手順は次のとおりです。
データベース・アプリケーションでは、あるデータベース表の一部の列に、別のデータベース表に定義された可能な値の制限セットが指定されている場合があります。たとえば、Orders
データベース表にCountry
列が含まれていて、この列にはCountries
データベース表から導出された値のみを挿入するように指定されている場合があります。他の表からこのようなデータを容易に操作できるように、JDeveloperでは値リスト・オブジェクト(LOV)を作成することにより、一方のオブジェクトからのデータを他方のオブジェクトで参照できます。データ・モデル内でこの値リスト関係を設定することにより、選択リスト、コンボ・ボックスなどの値リストUIコンポーネントを容易に作成できます。このためには、「データ・コントロール」パネルからページに、LOV属性をドラッグします。
JPAベースのデータ・コントロールの場合は、実行時にリストに表示されるオブジェクトを制限するために、リスト・ソースであるオブジェクト上で定義した名前付き基準を適用することもできます。名前付き基準を作成するには、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
LOVオブジェクトは、データ・コントロール構造ファイル内で定義します。
始める前に:
値リスト・コンポーネントに関する知識が役立つ場合があります。詳細は、「値リスト・オブジェクトの作成」を参照してください。
次のタスクを完了する必要があります。
属性のLOVを作成する手順は次のとおりです。
LOV定義を格納するデータ・コントロール構造ファイルの概要エディタで、「値リスト」ナビゲーション・タブをクリックして、「オブジェクトの値リストの追加」をクリックします。
「値リストの作成」ダイアログで、次の手順を実行して名前付き基準を適用します。
「値リスト名」フィールドで、LOVオブジェクトの名前を入力します。
「ベース・オブジェクト・フィールド」ツリーで、値リストへのアクセスに使用されるデータ・コントロール・オブジェクトを選択します。たとえば、コレクションとのOneToMany
関係を持つ構造化属性ノードを選択できます。
「リスト・データソース」ツリーで、値のソースのデータ・コントロール・オブジェクトを選択します。
このアクセッサは、アプリケーション内で他の用途に使用しないでください。このアクセッサを他の場所で使用する場合は、機能を複製した代行のデータ・コントロール上で新規アクセッサ・メソッドを作成し、それをリスト・データソースとして使用します。
注意:
LOVを使用してJPAエンティティを選択する場合、リソース・データソース・アクセッサから返されるJPAエンティティが、LOVにバインドされたプロパティと比較されます(equals()
を使用して)。リスト・データソース内のJPAエンティティがEntityManager
によって管理されている状態にあり、デタッチ状態にないことが保証されていれば、比較は正しく動作します。デタッチ状態になる可能性がある場合は、デフォルトのequals()
メソッドによる比較が期待どおりに動作しないことがあり、少なくともエンティティのIDフィールドを含むように、エンティティ・クラスのequals()
メソッドとhashCode()
メソッドをオーバーライドする必要があります。
同様に、基礎となるセッションBeanがステートレスのときは、equals()
メソッドをオーバーライドする必要があります。ステートレス・セッションBean内でメソッド・コールが行われるたびに、固有の永続性コンテキストが使用されるので、デフォルトのequals()
の実装では、別々のメソッド・コールから返されたインスタンスを比較する場合にfalse
が返されます。
これら2つのメソッドをオーバーライドするコードを生成できます。このためには、「アプリケーション」ウィンドウでエンティティ・クラスを選択し、「構造」ウィンドウでエンティティのノードを右クリックして、「equals()およびhashCode()の生成」を選択します。ただし、JPAもこれらのメソッドに依存しているので、この方法はお薦めしません。これらのメソッドをオーバーライドする場合は、予期しない動作が可能なかぎり起こらないように、equals()
の実装によってエンティティ内の一時的でないプロパティすべてが比較されることを確認してください。お薦めする方法は、ADF Webアプリケーション内でデタッチされたエンティティの使用を避けることです。このためには、拡張永続性コンテキストでステートフル・セッションBeanを使用します。このモデル・タイプを使用すれば、同じ論理エンティティに複数のインスタンスが存在しなくなり、不変のIDに基づいてエンティティを比較するためにequals()
メソッドをオーバーライドする必要はありません。
「OK」をクリックします。
オプションで、JPAベースのデータ・コントロールの場合、ビュー属性の編集アイコンをクリックして、表示される値の制限に使用するデータソースからの名前付き基準のいずれかを適用します。このアイコンは、ページの右側、「リスト・データソース」パネルと「リスト戻り値」パネルの間にあります。
概要エディタで、「リストUIヒント」タブをクリックして、次の手順を実行します。
「デフォルトのリスト・タイプ」ドロップダウン・リストで、値リストを表示するコンポーネントを選択します。使用可能なコンポーネントのタイプについては、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のリスト・タイプUIヒントのリスト・コンポーネント・タイプの表を参照してください。
オプションで、「属性の表示」セクションでリストに表示される属性を変更します。
オプションで、使用するリストのタイプに応じて使用可能なその他のオプションを構成します。
オプションで、「アクセッサUIのヒント」タブをクリックして、リストに表示される属性、ユーザーの選択内容が自動的に送信されるかどうかなどに関するUIヒントを設定します。
LOVオブジェクトを作成する際には、次の処理が行われます。
まだ存在しない場合は、LOVオブジェクトの属性ノードがベース・オブジェクトのサブノードとして「データ・コントロール」パネルに表示されます。このノードを使用して、ページにドラッグすることにより、モデルドリブン・リストUIコンポーネントを作成できます。属性の親コレクションをページにドラッグして、その属性をリスト・コンポーネントによって表現するフォームまたは表を作成することもできます。
注意:
リスト・ソースへのマッピングがオブジェクト定義内の属性に含まれていない場合、LOVオブジェクトを作成する前に、この属性ノードが「データ・コントロール」パネルにすでに表示されている場合があります。
オブジェクト定義にリスト・ソースへのマッピングが含まれている場合(たとえば、JPAエンティティ・クラス内の@JoinColumn
アノテーションの形式で)、デフォルトではその属性が「データ・コントロール」パネルに構造化属性として表示されます。ただし、デフォルトでは、親コレクションをページにドラッグしてADFフォームまたはADF表を作成する際に、この構造化属性のUIコンポーネントは生成されません。このため、別の表にマップされた属性のLOVオブジェクトを作成すれば、以後はモデルドリブン選択リストに組み込むフォームと表の作成が簡単になります。
次の要素が、LOV属性を含むコレクションのデータ・コントロール構造ファイルに追加されます。
<PDefAttribute>
要素。これは、属性を指定し、LOV動作を定義するリスト・バインディング要素を指し、Webページに表示するコンポーネント・タイプを指定します。
<ViewAccessor>
要素。これは、データソースの行セットから可能な値のリストを取得するために使用される手段です。
<ListBinding>
要素。これは、問合せ限度、リストの表示にブランク・エントリを含めるかどうかなど、LOVの動作を定義します。
アプリケーションのビューの設計を開始する前に、Oracle ADFモデル・テスターを使用して、EJBおよびBeanデータ・コントロールのモデルの様々な要素をテストできます。たとえば、モデルに検証ルールまたはUIヒントを追加した場合、それらのオブジェクトをページにバインドする前にテストできます。UIページを作成した後でも、問題が発生した場合、Oracle ADFモデル・テスターは問題を診断する補助となります。Oracle ADFモデル・テスターを使用して、問題がビジネス・サービス・レイヤーに存在するのかどうかを絞り込むことができます。
データ・コントロールに定義したメタデータをテストするには、「アプリケーション」ウィンドウからアクセスできるOracle ADFモデル・テスターを使用します。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
次のタスクを完了する必要があります。
注意:
EJBデータ・コントロールの場合、テスターはローカル・セッションBeanインタフェースに対しては機能しません。ただし、セッションBeanと同じ永続性ユニットに基づくJavaサービス・ファサード・クラスを作成し、そのクラス用のデータ・コントロールを作成し、そのデータ・コントロールをテスター内で使用することによって、この制限を回避できます。このJavaサービス・ファサードはEJBセッションBeanと同じ永続性ユニットを使用するので、2つのデータ・コントロールはエンティティに対して同じデータ・コントロール構造ファイルを使用します。
Javaサービス・ファサード・クラスの作成の詳細は、「JPAベースのBeanデータ・コントロールのサービス・ファサードを作成する方法」を参照してください。
この方法を使用すると、統合WebLogic Serverインスタンスのオーバーヘッドを削減できるという利点もあります。インスタンスはテスター用のプロセスを実行する必要がありますが、セッションBean自体を実行する必要はありません。
アプリケーションのBeanメタデータをテストする手順:
Oracle ADFモデル・テスターを起動すると、JDeveloperがテスターを別のプロセスで開始し、Oracle ADFモデル・テスター・ウィンドウが表示されます。ウィンドウの左側のツリーには、データ・モデルのすべてのコレクションが表示されます。データ・モデルにマスター/ディテールのビュー・インスタンス関係が定義されている場合、ツリーには親ノードと子コードとして関係が表示されます。目的のコレクションをダブルクリックすると、Oracle ADFモデル・テスターでデータ・ビュー・ページが表示され、問合せ結果をインスペクトできます。たとえば、図7-7では、customerFindAllコレクションがダブルクリックされ、右側のデータ・ビュー・ページにこのコレクションの最初のレコードが表示されているところが示されています。
図7-7 Oracle ADFモデル・テスターに表示されたcustomerFindAllコレクションの詳細
Oracle ADFモデル・テスターの一部の機能を次に示します。
「ラベル・テキスト」ヒントに基づいたUIヒント、およびフォーマット・マスクが正しく定義されているかどうかを検証できます。(UIヒントの設定方法は、「属性へのUIヒントの設定方法」を参照してください。)
ツールバー・ボタンを使用してデータのスクロールもできます。
Query-By-Example基準を入力して、検査対象のデータのある特定の行を検索できます。ツールバーの「ビュー基準の指定」ボタンをクリックすると、「ビュー基準」ダイアログに使用可能なQuery-by-Example基準のリストが表示されます。
たとえば、CustomerInfoCriteria
などの名前付き基準を選択し、LastName
属性にH%
などの問合せ基準を入力して、「検索」をクリックすると、文字H
で始まる姓のユーザーのみに検索対象を絞り込むことができます。
表7-2は、Oracle ADFモデル・テスターのツールバー・ボタンが実行する操作の概要を示しています。
表7-2 Oracle ADFモデル・テスターのツールバー・ボタン
ボタン | 操作 | 使用方法 |
---|---|---|
![]() |
別の行に移動 |
Oracle ADFモデル・テスターで表示される現在の行を変更します。最初、前、次、または最後の行に移動します。 |
![]() |
新規行を挿入 |
新規の行を作成して挿入します。 |
![]() |
現在の行を削除 |
現在の行を削除します。 |
![]() |
データベースへの変更を保存 |
保留中のトランザクションに対してコミット操作を実行します。ただし、JPAベースのデータ・コントロールの場合、変更は実際にはデータベースにコミットされません。 このボタンは、トランザクション・メソッドがサービスに実装されている場合のみ使用できます。 |
![]() |
前回の保存以降の変更をすべて取消し |
保留中のトランザクションを取り消し、元の値をリストアします。 このボタンは、トランザクション・メソッドがサービスに実装されている場合のみ使用できます。 |
![]() |
ビュー基準の指定 |
「ビュー基準」ダイアログが表示され、名前付き基準を作成し、結果セットに適用できます。 |
![]() |
行の検証 |
データ・コントロール構造ファイルで定義されている検証ルールを適用することにより、現在の行を検証します。最低1つのフィールドが編集可能でないと、使用できません。 |
定義した検証規則に応じて、無効な値を入力して検証例外のトリガーおよび検証を試行できます。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
次のタスクを完了する必要があります。
ビジネス・レイヤーの検証をテストする手順:
テスターで、属性の値を入力して「行の検証」アイコンをクリックします。
たとえば、属性について範囲検証ルールを定義した場合、その範囲外の値を入力して「行の検証」アイコンをクリックします。次のようなエラーが表示されます。
(oracle.jbo.AttrSetValException) Valid product codes are between 100 and 999
Oracle ADFモデル・テスターを使用して、新規行の作成時に属性のデフォルト値が正しく生成されるかどうかを検証できます。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
また、データ・コントロール構造ファイル内の属性を理解していると役立ちます。詳細は、「属性の操作」を参照してください。
次のタスクを完了する必要があります。
行の作成およびデフォルト値の生成をテストする手順:
Oracle ADFモデル・テスターでは、既存の名前付き基準を使用し、非定型基準で問い合せてデータ・モデルをテストできます。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
また、名前付き基準を理解していると役立ちます。詳細は、「名前付き基準を使用した結果セットのフィルタリング」を参照してください。
次のタスクを完了する必要があります。
Oracle ADFモデル・テスターを使用して名前付き基準および非定型問合せ基準をテストする手順:
図7-8 Oracle ADFモデル・テスターの「ビュー基準」ダイアログ
データ・コントロールをテストする際、データ・モデル・プロジェクト全体を再デプロイすることなく、データ・コントロールを繰り返し変更して再度テストできます。データ・コントロール構造ファイルへの変更を再ロードするには、単にOracle ADFモデル・テスターを閉じて再度開きます。
Javaコード、またはデータ・モデル・プロジェクトのJARファイルにパッケージ化した他のファイルを変更した場合は、そのJARファイルを再ビルドし、内部アプリケーション・サーバーに再デプロイする必要があります。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
次のタスクを完了する必要があります。
稼働中のOracle ADFモデル・テスターにデータ・モデルのメタデータを再ロードするには:
アプリケーションにおいて、リソース・メッセージ・バンドル内に代替言語を定義する場合、これらの言語を認識するようにOracle ADFモデル・テスターを構成できます。Oracle ADFモデル・テスターで「ロケール」メニューを表示し、利用可能な言語の中から選択できます。
Oracle ADFモデル・テスターで言語メッセージ・バンドルをテストすることで、データ・コントロールのUIヒントの翻訳が正しく配置されているかどうかを検証できます。または、メッセージ・バンドルが特定の属性の日付書式を定義している場合は、ツールによって日付書式の変更(たとえば、04/12/2007
から12/04/2007
へ)を検証できます。
始める前に:
Oracle ADFモデル・テスターの知識があると役立ちます。詳細は、「Oracle ADFモデル・テスターを使用したデータ・オブジェクト・メタデータのテスト」を参照してください。
Oracle ADFモデル・テスターのデフォルト言語を指定するには:
Groovyは、Javaプラットフォーム用のスクリプト言語で、Javaと同様の構文を持ちます。Groovyスクリプト言語では、ドット区切り表記法の採用により、コードの作成が簡素化されていますが、コレクション、文字列およびJavaBeansを操作する構文は引き続きサポートされています。Groovy言語式は実行時に動的にコンパイルされ、実行されます。ADFアプリケーションについて作成したGroovy式は、定義されたデータ・オブジェクトのデータ・コントロール構造ファイルに保存されます。
Oracle ADFでは、データ・コントロール・オブジェクトへのアクセスが有用な場合のGroovyスクリプト言語の使用をサポートしています。これには、属性バリデータ、属性のデフォルト値、一時属性値の計算、バインド変数のデフォルト値(名前付き基準のフィルタリングにおける)、およびエラー・メッセージのプレースホルダ(検証ルールにおける)が含まれます。さらに、Oracle ADFには、Groovy式で使用できる組込みキーワードの限定されたセットが用意されています。
特に、Oracle ADFでは、次のタスクの実行でGroovy言語式の使用をサポートしています。
Script Expression Validator (「Groovy式を使用した検証」を参照)またはCompare Validator (「比較に基づいた検証」を参照)の定義。
検証エラーを処理するエラー・メッセージ・トークンの定義(「エラー・メッセージへのGroovy式の埋込み」を参照)。
バリデータの条件付き実行の処理(「Groovyを使用した条件付きでのエラー・メッセージの呼出し」を参照)。
データ・オブジェクト属性のデフォルト値およびオプションの再計算条件の定義(「Groovy式を使用したデフォルト値の定義方法」を参照)。
データ・オブジェクトのデータ・コントロール構造ファイルにおける一時属性の値の判別(「データ・オブジェクトへの一時属性の追加」を参照)。
これらのタスクをJDeveloperで実行する場合、タスク固有の式エディタ・ダイアログを使用します。たとえば、一時属性のデフォルト値を作成する場合、属性の「式エディタの編集」ダイアログを使用して、属性の実行時の値を決定する式を入力します。また、同じダイアログで値をいつ計算するかも指定できます(再計算条件と呼ばれます)。式はデザインタイム時に検証できませんが、すべての式エディタで、式の構文を保存する前にテストできます。
Groovy言語の詳細は、次のWebサイトを参照してください。
フレームワークでGroovyスクリプトを使用できるオブジェクトにアクセス可能な、adf
という名前のトップレベルのオブジェクトが用意されています。アクセス可能なOracle ADFオブジェクトの構成は次のとおりです。
adf.context
- ADFContext
オブジェクトを参照します。
adf.object.dataProvider
- 式が適用されるデータ・オブジェクトを参照します。アクセス可能な他のメンバー名は、Groovyスクリプトが適用されたコンテキストに由来します。
データ・オブジェクト属性およびメソッド: コンテキストはデータ・オブジェクトのデータ・コントロール構造ファイルです。このオブジェクトを介して、データ・コントロール構造ファイルで定義されているすべての属性、およびデータ・オブジェクトから継承されたすべての属性およびメソッドを参照できます。
スクリプト検証ルール: コンテキストは、バリデータが適用されるデータ・オブジェクトにマージされるバリデータ・オブジェクト(JboValidatorContext
)です。このコンテキストで使用できるキーワードの詳細は、「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式は数値(または数字のドメイン)を返す必要があります。
データ・コントロールのメンバー(データ・オブジェクトおよびデータ・オブジェクトのデータ・コントロール構造ファイルが定義するメソッドおよび属性を含む)を参照する最も単純な例は、式を適用する属性と同じデータ・オブジェクトに存在する属性の参照です。
たとえば、従業員の月給を指定する属性Sal
を持つデータ・オブジェクトの一時属性AnnualSalary
の値を計算するGroovy式を定義できます。
Sal * 12
または、次のような構文を使用して単一のデータ・コントロール構造ファイルの属性を比較する単純な検証ルールをGroovyで作成できます。
PromotionDate > HireDate
Javaを使用すると、同じ比較は次のようになります。
((Date)getAttribute("PromotionDate")).compareTo((Date)getAttribute("HireDate")) > 0
現在のオブジェクトは、this
オブジェクトとしてスクリプトに渡されるため、属性名を使用するだけで現在のオブジェクトの属性を参照できます。たとえば、属性レベルまたはエンティティ・レベルのスクリプト式バリデータで、HireDateという名前の属性を参照するには、スクリプトでHireDate
を参照するだけですみます。
属性の参照と同様に、式の一部としてメソッドを起動できます。たとえば、次のように、属性のデフォルト値を定義します。
adf.object.dataProvider.getDefaultSalaryForGrade()
メソッド参照は接頭辞adf.object.dataProvider
を必要とします。これによって式が適用される属性を定義する同じオブジェクトを参照できます。
検証ルールでデータ・オブジェクトのメソッドを参照する場合は、object
のかわりにsource
を使用します。
adf.source.dataProvider.getDefaultSalaryForGrade()
object
キーワードは、メソッドが定義されているデータ・オブジェクトではなく、検証ルール・オブジェクトを指すため、バリデータではsource
接頭辞を使用する必要があります。
バリデータ・オブジェクトのメンバーを参照できるようにするために(JboValidatorContext
)、検証ルール式で次のキーワードを使用できます。
newValue
: 属性レベルのバリデータで、設定されている属性値にアクセスします。
oldValue
: 属性レベルのバリデータで、設定されている現在の属性値にアクセスします。
たとえば、次の式を使用して、販売員の給与の動的検証ルール・チェックを指定できます。
if (Job == "SALESMAN") { return newValue < adf.source.dataProvider.getMaxSalaryForGrade(Job) } else return true