Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2 (11.1.2.4.0) B69399-03 |
|
![]() 前 |
![]() 次 |
この章では、Oracle Application Development Framework (Oracle ADF)アプリケーションのADFモデル・レイヤーで検証規則を作成し、ユーザー・インタフェースに入力されるデータがビジネス・サービス・レイヤーではなくページで検証されるようにする方法を説明します。
この章は次の項で構成されています:
Modelレイヤーでは、ADF Model検証規則を特定のページのバインディングの属性として設定できます。ユーザーがフィールド内のデータを編集または入力してフォームを送信したときに、設定した規則および条件に対してバインドされたデータが検証されます。検証が失敗すると、アプリケーションによりエラー・メッセージが表示されます。
エンティティ・オブジェクトのビジネス・ドメイン・レイヤーに検証規則をすでに設定している場合は、ADF Model検証を追加する必要はありません。ADF Business ComponentsベースのFusion Webアプリケーションでは、アプリケーション・モジュールのデータ・コントロール以外のデータ・コントロールを使用しないかぎり、ADF Model検証を使用する必要はありません。
アプリケーションでADF Business Componentsに基づかないデータ・コントロールを使用している場合は、ADFモデル・レイヤー検証を使用してユーザーが入力したデータの品質を確保できます。
ベスト・プラクティス: 可能な場合はビジネス・レイヤー検証を使用します。ただし、次の例に示すような場合には、モデル・レイヤー検証の使用が必要になる場合があります。
また、サーバーとのラウンドトリップの前に検証を実行する場合、クライアント側の検証を使用することもできます。『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の検証の追加に関する項を参照してください。 |
アプリケーションで、ビジネス・レイヤー検証に加えてモデル・レイヤー検証の使用も保証されている場合は、ADF Business Componentsオブジェクトで利用できる宣言的検証機能の多くをモデル・レイヤーでも利用できます。
モデル・レイヤー認証を使用する前に、他のADF検証機能を理解しておくと役立つ場合があります。次に、関連する他の機能へのリンクを示します。
ADF Business Componentsアプリケーション・モジュールのデータ・コントロールを使用する場合、モデル・レイヤー検証を使用する必要はありません。可能であれば、すべての検証規則を、ビジネス・レイヤー内の再使用と管理が容易で一元管理されたエンティティ・オブジェクトに定義することを検討してください。詳細は、第7章「検証とビジネス・ルールの宣言的な定義」を参照してください。
ページ・レベルで利用できる宣言的検証機能の多くは、Beanレベルでも利用できます(その場合はデータ・コントロール構造ファイルで実装します)。データ・コントロール構造ファイルの検証規則は、データ・コントロールが使用されるすべての場合に適用されるため、非常に役立ちます。データ・コントロール構成ファイルで検証規則を実装する場合の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド』の「データ・コントロールへのビジネス・ロジックの追加」を参照してください。
バインディングの属性に対するADFモデル検証は、ページ定義ファイルで構成できます。モデル・レイヤーの検証規則は、特定のページのバインディング属性に対して、その対象を含むフォームの送信時に実行されます。
オプションで、skipValidation
プロパティをtrue
に設定すると、ADFモデル検証をバイパスできます。skipValidation
をskipDataControls
に設定して、トランザクションを検証せずに、バインド・オブジェクトを検証できます。たとえば、データ入力を受け付けるポップアップ・ウィンドウを開く表アクションがあるときに、表でコミットする前にビュー・レイヤーでこれらの入力を検証できるようにする場合は、skipValidation
をskipDataControls
に設定します。構造ウィンドウでページ定義ファイルのルート・ノードを選択すると、skipValidation
プロパティがプロパティ・インスペクタに表示されます。
ADF Model検証をページ定義ファイルに設定します。検証規則を定義し、規則に違反した場合に表示するエラー・メッセージを設定します。
表16-1に、バインディングの属性に対して構成できるADF Model検証規則を示します。
表16-1 ADF Model検証規則
バリデータ規則名 | 説明 |
---|---|
比較 |
属性の値とリテラル値を比較する。 |
リスト |
値が値リスト内にあるかどうかを検証する |
範囲 |
値が値範囲内にあるかどうかを検証する。 |
長さ |
値の文字またはバイト・サイズをサイズおよびオペランド(greater than or equal toなど)に対して検証する。 |
正規表現 |
Java正規表現構文を使用してデータを検証する。 |
必須 |
属性にその値が存在するかどうかを検証する。 |
始める前に:
モデル・レイヤーでの検証規則の使用に関する知識があると役立つ場合があります。詳細は、16.2項「ADFモデル・レイヤーでの検証規則の定義」を参照してください。
また、他の検証機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は、16.1.2項「ADFモデル・レイヤー検証の追加機能」を参照してください。
次のタスクを完了する必要があります。
ページにコンポーネントを作成します。このコンポーネントにはバインディング属性が必要です。
ADF Model検証規則を作成する手順:
規則を作成するバインディングが含まれるページ定義を開きます。
構造ウィンドウで、属性、リストまたは表バインディングを選択します。
プロパティ・インスペクタで、「詳細」に続いて「検証ルールの編集」を選択します。
「検証ルールの編集」ダイアログで「バインディング」ノードを展開し、属性名を選択して、「新規」をクリックします。
「検証ルールの追加」ダイアログで、検証規則を選択し、必要に応じて規則を構成します。
「失敗処理」タブを選択して、規則に違反した場合に表示するメッセージを構成します。
ユーザーがデータを送信すると、送信された値がNULL以外の値か、少なくとも1つの文字からなる文字列値であった場合、コンポーネントに設定されているすべてのバリデータが1つずつコールされます。コンポーネントのf:validator
タグはバインディングのvalidator
プロパティにバインドされるため、モデルに設定されている検証ルーチンがアクセスされて実行されます。
続いて、プロセスは次のコンポーネントに進みます。すべての検証が正常に完了すると、モデル値更新フェーズが開始され、ローカル値を使用してモデルが更新されます。いずれかの検証が失敗すると、現在のページがエラー・メッセージとともに再表示されます。
デフォルトのDCErrorHandlerImpl
クラスを拡張するカスタム・エラー・ハンドラを使用して、エラーをレポートできます。カスタム例外ハンドラ・クラスを登録するためにコードを記述する必要はありません。かわりに、構造ウィンドウでDataBindings.cpx
ファイルのルート・ノードを選択した後、プロパティ・インスペクタを使用してErrorHandlerClass
プロパティに、使用するエラー・ハンドラの完全修飾名を設定します。
カスタム・エラー・ハンドラには、次の上書き可能なメソッドを含めることができます。
reportException()
: 発生した例外をレポートするためにコールされます。レポートされた例外を分析するように上書きできます。
getDisplayMessage()
: 発生したエラーごとにJSFにレポートされるメッセージを戻します。カスタム・エラー・ハンドラで特定の例外をクライアントにレポートする必要がない場合は、null
を戻します。
getDetailedDisplayMessage()
: 発生したエラーごとにJSFにレポートされるメッセージの詳細部分を、String
オブジェクトまたはHTMLとして戻します。カスタム・エラー・ハンドラで特定の例外をクライアントにレポートする必要がない場合は、null
を戻します。
skipException()
: ユーザー向けに表示される最終的なエラー・リストに、ネストされた例外から各アイテムを表示するかどうかに応じたブール値を戻します。このメソッド・オーバーライドにより、特定の例外タイプをチェックし、ビジネス・シナリオに基づいて、このタイプをリストに表示するかどうかを判断するロジックを実装できます。
例16-1は、DCErrorHandlerImpl
クラスを拡張したカスタム・エラー・ハンドラです。この例は、ユーザーに表示されるリストに載せない例外をスキップするために必要なskipException()
メソッドに対するオーバーライドを示しています。
例16-1 カスタム・エラー・ハンドラ
package view.controller.fwkext; import java.sql.SQLIntegrityConstraintViolationException; import java.util.ArrayList; import java.util.List; import oracle.adf.model.binding.DCBindingContainer; import oracle.adf.model.binding.DCErrorHandlerImpl; import oracle.jbo.CSMessageBundle; import oracle.jbo.DMLConstraintException; import oracle.jbo.JboException; public class CustomErrorHandler extends DCErrorHandlerImpl { List<ExceptionMapper> exceptionMapperList = new ArrayList<ExceptionMapper>(); public CustomErrorHandler() { this(true); } public CustomErrorHandler(boolean setToThrow) { super(setToThrow); exceptionMapperList.add(new DisableJboExceptionCodesMapper()); } public void reportException(DCBindingContainer bc, Exception ex) { for (ExceptionMapper mapper : exceptionMapperList) { if (mapper.canMapException(ex)) { ex = mapper.mapException(ex); } } super.reportException(bc, ex); } /** * If an exception is a RowValException or a TxnValException and they * have nested exceptions, then do not display it. This example shows * an implementation that skips the SQLIntegrityConstraintViolationException * from displaying in the error final list displayed to the user. */ @Override protected boolean skipException(Exception ex) { if (ex instanceof DMLConstraintException) { return false; } else if (ex instanceof SQLIntegrityConstraintViolationException) { return true; } return super.skipException(ex); } }
コンストラクタをMyErrorHandler()
に変更する必要があります。例外エラー・ハンドラには、例16-2に示すように、デフォルトのコンストラクタが必要です。
例16-2 デフォルトのコンストラクタ
ErrorHandlerClass="viewcontroller.MyErrorHandler" public MyErrorHandler() { super(true); }
メッセージの詳細部分をカスタマイズし、使用する予定のある場合は、このメッセージを取得し、処理するために、カスタム・エラー・ハンドラを作成し、getDetailedDisplayMessage
メソッドを実装することができます。最終的なメッセージは、ビュー・レイヤーに渡され、他のメッセージと統合されます。
メッセージの詳細部分をカスタマイズするには:
デフォルトのDCErrorHandlerImpl
クラスを拡張するカスタム・エラー・ハンドラを作成します。
このクラスで、DCErrorMessage
オブジェクトを戻すgetDetailedDisplayMessage
メソッドをオーバーライドします。
例16-3に、カスタム・エラー・ハンドラ・クラスでのgetDetailedDisplayMessage
メソッドの実装を示します。
例16-3 getDetailDisplayMessageメソッドを使ったカスタム・エラー・ハンドラ・クラス
public final class MyErrorMessageHandler extends DCErrorHandlerImpl { public MyErrorMessageHandler (){ super(false); } public DCErrorMessage getDetailedDisplayMessage(BindingContext ctx, RegionBinding ctr, Exception ex) { ... return new MyDCErrorMesssage(ctr, ex); } }
DCErrorMessage
インタフェースを実装するカスタム・クラスを作成します。このクラスはgetHTMLText
メソッドおよびgetText
メソッドを実装する必要があります。
getHTMLText
メソッドに、実際の処理を実行するためのコードを追加しますが、インタフェースの要件を満たすには、getText
の実装も必要です。
getHTMLText
の実装では、エラー・メッセージを作成、処理するためのコードを追加します。
getDetailedDisplayMessage
のgetHTMLText
は、エラー・メッセージの最終版をHTMLフラグメントとして戻す必要があります。このフラグメントは、ページのHTMLコードに挿入されます。このため、getDetailedDisplayMessage
によりメッセージが戻される前に、テキスト・メッセージに対して、必要な前処理をすべて実行しておく必要があります。たとえば、ローカライズしたメッセージの取得や、メッセージの順番を右から左に変更するなどの処理が必要である場合は、メッセージが戻される前に行います。
例16-4はこのインタフェースの実装を示しています。
例16-4 DCErrorMessageインタフェースの実装
public final class MyDCErrorMesssage implements DCErrorMessage { RegionBinding m_regionBinding; Exception m_ex; public MyDCErrorMesssage(RegionBinding ctr, Exception ex) { super(); this.m_regionBinding = ctr; this.m_ex = ex; } public String getText() { ... return "Message String"; } public String getHTMLText() { ... /* Add code to process the message, including localization */ /* and right-to-left directional requirements. */ /* Return the message as the finalized HTML fragment.*/ return "<b>error</b> message details"; } }
Oracle ADFでは、作成されるBindingContext
オブジェクトごとにカスタム・エラー・ハンドラのインスタンスを1つ作成します。Oracle ADFでは、同じ論理エンド・ユーザー・セッションからの同時Webリクエストをシリアライズするため、通常、複数スレッドは同じエラー・ハンドラを同時に使用しません。しかし、スレッドセーフのカスタム・エラー・ハンドラを保証するには、JboException
でsetProperty()
APIを使用します。このメソッドは、表示用に例外がJSF FacesMessage
オブジェクトに変換されるときに、後で必要になる可能性があるヒントをすべて例外オブジェクト自体に格納します。