| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
前 |
次 |
この章では、アプリケーション内でナビゲーション、カプセル化、再利用、マネージドBeanのライフサイクルおよびトランザクションを使用できるようにするADFタスク・フローの作成方法について説明します。これにはタスク・フロー・ダイアグラムの作成、このダイアグラムへのアクティビティと制御フローの追加、および完成したタスク・フローの実行の基本的な手順が含まれています。
この章の内容は次のとおりです。
ADFタスク・フローでは、Fusion Webアプリケーションの制御フローを定義するためのモジュール・アプローチが提供されます。アプリケーションは単一の大規模なJSFページ・フローとして表すのではなく、再利用可能な一連のタスク・フローに分割できます。各タスク・フローには、アプリケーションのナビゲーション・グラフが含まれます。タスク・フロー内のノードは、アクティビティです。アクティビティ・ノードでは、ページの表示、アプリケーション・ロジックの実行または別のタスク・フローのコールなど、シンプルな論理的操作が表示されます。アクティビティ間のトランザクションは制御フロー・ケースと呼ばれます。
図18-1には、CreateとConfirmと呼ばれる2つのビュー・アクティビティが示されています。これらのビュー・アクティビティは、JSFページ・フロー内部のページ・ノードに類似しています。
ADFタスク・フローには次の2つの種類があります。
バインドなしタスク・フロー: ユーザーがタスクを完了できるように対話する一連のアクティビティ、制御フロー・ルールおよびマネージドBeanです。バインドなしタスク・フローは、バインド・タスク・フローに含まれていない、アプリケーション内のすべてのアクティビティおよび制御フローで構成されています。
バインド・タスク・フロー: タスク・フローの特殊な形式であり、バインドなしタスク・フローとは異なり、単一エントリ・ポイント(ブラウザからの直接の要求が可能なビュー・アクティビティ)と0以上の終了ポイントがあります。プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットが含まれています。バインド・タスク・フローでは、再利用、パラメータ、トランザクション管理および再開が可能なほか、JSFページにあるADFリージョン内へのレンダリングも可能です。
バインドなしタスク・フローまたはバインド・タスク・フローに追加可能なアクティビティ・タイプの説明は、第19章「タスク・フロー・アクティビティの使用」を参照してください。
デフォルトでは、JDeveloperはバインド・タスク・フローのソース・ファイルに対して次のファイル名を使用します。
task-flow-definitionN.xml
ここでNは新しいバインド・タスク・フローを作成するたびに増分する番号です。バインド・タスク・フローのファイル名を選択できます。たとえば、バインド・タスク・フローの目的が顧客によるショッピング・アプリケーションのチェックアウトを可能にすることであれば、checkout-task-flow.xmlを使用できます。
ソース・ファイルには、バインド・タスク・フローのメタデータが含まれています。次のメタデータを使用して、複数のバインド・タスク・フローを同一ソース・ファイル内に追加できます。
<task-flow-definition id="TaskFlowID1">
...
</task-flow-definition>
<task-flow-definition id="TaskFlowID2">
...
</task-flow-definition>
ただし、JDeveloperのビジュアル・エディタではファイルごとに1つのバインド・タスク・フローが表示されるため、2つ以上のバインド・タスク・フローを同一ソース・ファイル内に追加することはお薦めしません。
通常のアプリケーションでは、バインドなしタスク・フローと1つまたは複数のバインド・タスク・フローが組み合されています。たとえば、Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成する場合、JDeveloperでは、空のバインドなしタスク・フロー(ソース・ファイル名はadfc-config.xml)がデフォルトで作成されます。実行時、Fusion Webアプリケーションでは、バインドなしタスク・フローに追加したアクティビティからバインド・タスク・フローをコールできます。
図18-2に示すように、アプリケーションで実行する最初のアクティビティは、多くの場合、バインドなしタスク・フロー内のビュー・アクティビティです。ビュー・アクティビティは、アプリケーションの一部として表示するJSFページを表します。図18-2に示すアクティビティは、Homeビュー・アクティビティで始まり、バインド・タスク・フローをコールします。calltoLogin_taskFlowアクティビティは、ユーザーのアプリケーションへのログインを可能にするバインド・タスク・フローをコールします。
また、バインドなしフロー内にすべてのアプリケーション・アクティビティが含まれているアプリケーションを設計できます。これは、JSFアプリケーションを模倣していますが、バインド・タスク・フローの機能の利点が活用されていません。タスク・フロー機能を十分に活用するには、バインド・タスク・フローを使用します。
表18-1では、JSFページ・フローが提供する制御フローと比較して、ADFタスク・フローが提供する制御フローがもたらす利点について説明します。シナリオによっては、JSFページ・フローの使用が必要な場合もあります。たとえば、25.4項「ADFページ・ライフサイクルのカスタマイズ」の説明のように、フェーズ・リスナーを使用するには、JSFページ・フローのfaces-config.xml構成ファイルを使用する必要があります。一般には、アプリケーションでJSFページ・フローとADFタスク・フローを併用することをお薦めしません。
表18-1 ADFタスク・フローの利点
| JSFページ・フロー | ADFタスク・フロー |
|---|---|
|
アプリケーション全体を単一のページ・ナビゲーション・ファイルに配置する必要があります( |
アプリケーションは、相互にコールする一連のモジュール型のフローに分割できます。 |
|
JSFページ・フロー内のすべてのノードは、JSFページである必要があります。他のタイプのオブジェクトは、JSFページ・フロー内には存在しません。 |
ビュー、メソッド・コールおよび他のタスク・フローへのコールなどのタスク・フロー・ダイアグラム・ノードに追加できます。 |
|
ナビゲーションはページ間のみです。 |
ナビゲーションは複数のページや、ルーターを含む他のアクティビティにも及びます。詳細は、19.4項「ルーター・アクティビティの使用」を参照してください。 |
|
アプリケーション・フラグメントを再利用できません。 |
ADFタスク・フローは、同一、または完全に別のアプリケーション内で再利用可能です。 アプリケーションをタスク・フローに分割した後で、一般機能を備えたタスク・フローを再利用できます。 詳細は、第38章「アプリケーション・コンポーネントの再利用」を参照してください。 |
|
セッション・スコープを除き、複数のリクエスト間では共有メモリー・スコープがありません。 |
タスク・フロー内のアクティビティ間でのデータ渡しを可能にする共有メモリー・スコープ(ページ・フロー・スコープなど)があります。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。 |
Fusion Webアプリケーションには常にADFバインドなしタスク・フローが組み込まれており、アプリケーションへのエントリ・ポイントが含まれています。エントリー・ポイントは、ブラウザからの直接の要求が可能なビュー・アクティビティです。Fusion Webアプリケーションには、1つのバインドなしタスク・フローのみが含まれます。デフォルトでは、バインドなしタスク・フローのソース・ファイルはadfc-config.xmlファイルです。バインドなしタスク・フローに対して追加ソース・ファイルを作成できますが、アプリケーションでは、実行中のすべてのソース・ファイルがadfc-config.xmlファイルにまとめられます。図18-3は、Fusion Order Demoアプリケーションからのバインドなしタスク・フローのダイアグラムを示しています。このタスク・フローにはいくつかのビュー・アクティビティが含まれており、いずれもアプリケーションへのエントリ・ポイントになっています。
次の場合には、バインド・タスク・フローではなく、バインドなしタスク・フローを使用します。
ビュー・アクティビティのブックマークなど、バインド・タスク・フローでは提供されないADFコントローラ機能を利用する場合。詳細は、19.2.2項「ビュー・アクティビティのブックマーク」を参照してください。
タスク・フローが別のタスク・フローによってコールされない場合。
アプリケーションに複数のエントリ・ポイントがある場合。図18-3では、バインドなしタスク・フロー上にビュー・アクティビティ・アイコンで表されるどのページからでも、タスク・フローを開始できます。
タスク・フローで複数のアクティビティにブックマークを付ける場合。詳細は、19.2.2項「ビュー・アクティビティのブックマーク」を参照してください。
バインドなしタスク・フローではパラメータを宣言的に指定できません。さらにここでは、デフォルト・アクティビティ、つまりバインドなしタスク・フローで最初に実行するよう設計されたアクティビティも含まれません。これは、バインドなしタスク・フローには単一エントリ・ポイントがないためです。これらのいずれかを実行するには、バインド・タスク・フローが必要です。
完全に宣言的なADFコントローラ・トランザクションおよび再開サポートの利点を活用するには、バインドなしタスク・フローではなくバインド・タスク・フローを使用します。
ADFバインド・タスク・フローを使用して、アプリケーションの再利用可能な部分をカプセル化します。バインド・タスク・フローは、次のようなJavaメソッドに類似しています。
単一エントリ・ポイントがある。
入力パラメータを受け入れることができる。
戻り値を生成できる。
アクティビティおよび制御フロー・ルールの独自のコレクションがある。
独自のメモリー・スコープおよびマネージドBeanの存続期間(ページ・フロー・スコープ・インスタンス)がある。
メモリー・スコープの詳細は、18.2.4項「タスク・フローのメモリー・スコープについて」を参照してください。
独立したデータ・コントロール・フレームがあるのかどうかを判別できます。
データ・コントロール・フレームへのアクセスの詳細は、22.2項「タスク・フロー間のデータ・コントロールの共有」を参照してください。
アクティビティを例外処理アクティビティとして定義できます。
バインド・タスク・フローの例外処理の詳細は、22.5項「タスク・フローの例外処理」を参照してください。
図18-3のcheckout-task-flowアクティビティはバインド・タスク・フローのコールです。バインドなしタスク・フローは、バインド・タスク・フローをコールできますが、別のタスク・フローからコールできません。バインド・タスク・フローからは別のバインド・タスク・フローをコールでき、さらにそのバインド・タスク・フローからも次々にコールできます。コールに深さ制限はありません。
チェックアウト・プロセスは、図18-4のように別個のバインド・タスク・フローとして作成されます。
コール先のバインド・タスク・フローとしてcheckout-task-flowアクティビティを作成する理由は次のとおりです。
バインド・タスク・フローでは、常にバインド・タスク・フローの開始直後に実行する必要のある単一エントリ・ポイントとなる、デフォルト・アクティビティを指定します。
チェックアウト・タスク・フローのreconcileShoppingCartというアクティビティは、無名ユーザー(アプリケーションにまだログインしていないユーザー)が購入するものとして選択した可能性のあるアイテムのリストを返すメソッドを呼び出します。認証前に選択されたアイテムは、ユーザーがログインするとショッピング・カートに追加されます。このメソッドはデフォルト・アクティビティであるため、常にショッピング・カート注文ページが表示される前に起動されます。
checkout-task-flowは再利用が可能です。たとえば、アイテムのチェックアウト・プロセスを必要とする他のアプリケーションに組み込むことができます。バインド・タスク・フローは、同じアプリケーション内でも再利用できます。
checkout-task-flow内で使用することにしたマネージドBeanは、ページ・フロー・スコープで指定できるため、残りのアプリケーションからは分離されます。これらのマネージドBean(およびページ・フロー・スコープ)は、タスク・フローが完了した際に自動的に解放されます。
表18-2に、バインド・タスク・フローの主要な機能をまとめます。
表18-2 バインド・タスク・フローの機能
| 機能 | 説明 |
|---|---|
|
明確に定義された境界 |
バインド・タスク・フローは、プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットで構成されます。コール元は、バインド・タスク・フロー境界内におけるページ名、メソッド・コール、子バインド・タスク・フロー、マネージドBean、制御フロー・ルールなどの内部知識を必要としません。入力パラメータをバインド・タスク・フローに渡すことが可能なほか、バインド・タスク・フローの終了時に戻り値を返すことが可能です。データ・コントロールはタスク・フロー間で共有できます。 |
|
単一エントリ・ポイント |
バインド・タスク・フローには、タスク・フロー内の他のすべてのアクティビティの前に実行されるデフォルト・アクティビティである、単一のエントリ・ポイントがあります。詳細は、18.2.3項「バインド・タスク・フローのデフォルト・アクティビティについて」を参照してください。 |
|
ページ・フロー・メモリー・スコープ |
バインド・タスク・フロー内のアクティビティ間でデータを受け渡すためのメモリー・スコープとしてページ・フロー・スコープを指定できます。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。その存続期間はバインド・タスク・フローであり、requestスコープより長く、sessionスコープより短くなっています。詳細は、18.2.4項「タスク・フローのメモリー・スコープについて」を参照してください。 |
|
アドレス可能 |
バインド・タスク・フローにアクセスするには、バインド・タスク・フローのXMLソース・ファイルに記述されている一意の識別子とXMLソース・ファイルのファイル名を指定します。詳細は、19.6.8項「タスク・フロー・コール・アクティビティ追加時の処理」を参照してください。 |
|
再利用 |
アクティビティ・グループ全体を単一のエンティティ、つまりバインド・タスク・フローとして識別し、そのバインド・タスク・フローをADFリージョン内の別のアプリケーションで再利用できます。たとえば、Fusion Order Demoアプリケーションのホーム・ページ上のホット・アイテムおよび買い物をスタートタブでは、リージョン内に組み込まれたものと同じタスク・フローを使用しています。リージョンごとに各種パラメータが渡され、表示する製品のリストが決定されます。詳細は、21.3項「ADFリージョンのパラメータの指定」を参照してください。 また、既存のバインド・タスク・フローは、コールするのみで再利用できます。たとえば、あるタスク・フローは、タスク・フロー・コール・アクティビティまたはURLを使用して別のバインド・タスク・フローをコールできます。 さらに、タスク・フロー・テンプレートを使用して、様々なバインド・タスク・フローで再利用するための共通の動作を取得できます。詳細は、22.9項「タスク・フロー・テンプレートの作成」を参照してください。 |
|
パラメータおよび戻り値 |
コール元は、バインド・タスク・フローに入力パラメータを渡し、戻り値を取得します。詳細は、20.3項「バインド・タスク・フローへのパラメータ渡し」を参照してください。 また、バインド・タスク・フロー間でデータ・コントロールを共有できます。詳細は、22.2項「タスク・フロー間のデータ・コントロールの共有」を参照してください。 |
|
トランザクション管理 |
バインド・タスク・フローは、作業のトランザクション単位を示すことができます。タスク・フローの開始時に、新規のトランザクションを作成するか、既存のものを結合するか、または既存のトランザクションの一部ではないかどうかを決定するオプションをバウンド側のタスク・フローに宣言的に指定できます。詳細は、22.3項「タスク・フローのトランザクションの管理」を参照してください。 |
|
再開 |
再開できるかどうかを決定するオプションを、バインド側のタスク・フローで指定できます。詳細は、22.4項「バインド・タスク・フローの再開」を参照してください。 |
|
メタデータのオンデマンド・ロード |
バインド・タスク・フロー・メタデータは、バインド・タスク・フローの開始時にオンデマンドでロードされます。 |
|
セキュリティ |
バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、第35項「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。 |
タスク・フローは、アクティビティ、およびアクティビティ間の遷移を定義する制御フロー・ケースで構成されます。図18-5は、制御フロー・ルール、つまりラベル付けしたtoView2を示しています。ここでは、ViewActivity1およびViewActivity2のビュー・アクティビティ間の遷移が定義されています。図18-5のタスク・フローが実行されると、ViewActivity1ビュー・アクティビティがViewActivity2ビュー・アクティビティの前に表示されます。
また、図18-5のタスク・フローにはメソッド・コール・アクティビティ(methodCall1)が含まれており、ViewActivity2ビュー・アクティビティの後およびtaskflowCall1タスク・フロー・コール・アクティビティの前に呼び出されます。タスク・フローでは、ページのレンダリング前後のメソッド・コール・アクティビティなどのアクティビティを呼び出します。特定のページの外部でメソッド・コール・アクティビティを呼び出すことによって再利用を促進できます。これは、そのメソッドを必要としない他のコンテキスト(別のタスク・フローなど)でページを再利用できるからです。制御フロー・ルールの詳細は、18.4項「タスク・フローへの制御フロー・ルールの追加」を参照してください。
ワイルドカード制御フロー・ルールは制御フローのfrom-activity-idを表し、これには、後方ワイルドカード(foo*)または単一ワイルドカード文字(*)が含まれます。タスク・フロー内の任意のアクティビティからワイルドカード制御フロー・ルールに制御を渡す場合は、単一ワイルドカード文字を使用します。あるいは、ワイルドカード制御フロー・ルールに制御を渡すアクティビティを制限する場合は、後方ワイルドカードを使用します。
図18-6では、ワイルドカード制御フロー・ルールに単一ワイルドカード文字が含まれており、タスク・フロー内のどのアクティビティからでもタスク・フロー・ダイアグラムで接続先となっているアクティビティに制御を渡せることを示しています。
図18-7の後方ワイルドカードは、activity-idがstorefrontという文字で始まる有効なソース・アクティビティからloginPageビューに制御フローを渡せることを示しています。
ワイルドカード制御フロー・ルールの詳細は、18.4.2項「ワイルドカード制御フロー・ルールの追加方法」を参照してください。
図18-8は、第2章「ADFサンプル・アプリケーションの概要」で説明したFusion Order Demoアプリケーションの画面を示しています。エンド・ユーザーは、この画面から多くのバインド・タスク・フローを呼び出すことができます。顧客として登録コマンド・ボタンによって、顧客登録タスク・フロー(customer-registration-task-flow.xml)が呼び出され、今後顧客になるユーザーがこのアプリケーションを使用登録できるようにします。このタスク・フローでは、名前や電子メール・アドレスなどのデータをユーザーが入力する画面がレンダリングされます。従業員として登録コマンド・ボタンでは従業員登録タスク・フロー(employee-registration-task-flow.xml)が呼び出され、従業員を登録できます。必要に応じて、顧客登録および従業員登録のタスク・フローでは同じビュー・アクティビティが再利用されます。図18-8にある3番目のタスク・フローは、help-task-flow.xmlタスク・フローで、「登録のヘルプ」エリアにレンダリングします。このタスク・フローによって、顧客および従業員の登録タスク・フローにあるタスクをユーザーが移動する支援を行います。
また、タスク・フローを使用して、エンド・ユーザーに公開するアクセス・ポイントの数を減らすことによって、Fusion Webアプリケーションのセキュリティを確保できます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローのURL起動プロパティをurl-invoke-disallowedに設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。URL起動プロパティの詳細は、19.6.4項「URLを使用したバインド・タスク・フローのコール方法」を参照してください。Fusion Webアプリケーションのセキュリティ保護の詳細は、第35章「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
ADFタスク・フローを構成または使用する前に、他のADF機能を理解しておくことは有効だと思われます。さらに、タスク・フローの構成で可能な機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。
タスク・フローはマネージドBeanを起動します。タスク・フローで使用するマネージドBeanの定義、サポートしているメモリー・スコープ、その他の関連する情報の詳細は、18.2.4項「タスク・フロー用のメモリー・スコープについて」および24.4項「Fusion Web ApplicationでのマネージドBeanの使用]を参照してください。
タスク・フローは再利用が可能です。アプリケーションの機能の再利用の詳細は、第38章「アプリケーション・コンポーネントの再利用」を参照してください。
タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、第35章「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
カスタム・コードを記述することでタスク・フローで実行される機能を拡張できます。たとえば、タスク・フロー・アクティビティでの例外発生時にタスク・フローが制御を渡すカスタム例外ハンドラを記述できます。詳細は、22.5.3項「例外ハンドラとしてカスタム・コードを指定する方法」を参照してください。
次の例のように、内部としてマークされていないパッケージをインポートしないようにカスタム・コードを記述していることを確認します。
import oracle.adfinternal.controller.*;
カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。
Oracle Fusion Middleware Oracle ADF Controller Java APIリファレンス
Oracle Fusion Middleware Java APIリファレンス for Oracle ADF Faces
タスク・フローはタスク・フロー自体と、複数のアクティビティ、そしてそれらのアクティビティ間の制御フロー・ルールで構成されています。ほとんどの場合は、アクティビティの多くがフロー内の異なるページを示すビュー・アクティビティです。たとえば、ページのレンダリング前などに一部のメソッドや操作をコールする必要がある場合は、メソッド・コール・アクティビティをそのアクティビティから次の適切なアクティビティまでの制御フロー・ケースとともに使用します。別なタスク・フローをコールする場合は、タスク・フロー・コール・アクティビティを使用します。フローになんらかのブランチ化が必要な場合は、ルーター・アクティビティを使用します。バインド・タスク・フローの最後で、リターン・アクティビティを使用してフローを終了し、そのバインド・タスク・フローをコールしたフローに制御を戻します。
各コンポーネント用のメタデータと設定可能な追加構成を含む、タスク・フローの各コンポーネントの詳細および手順は、18.3項「タスク・フローへのアクティビティの追加」を参照してください。
バインド・タスク・フローとバインドなしタスク・フローを作成するプロセスは類似しています。主な相違は、「タスク・フローの作成」ダイアログの「バインド・タスク・フローとして作成」チェック・ボックスを選択してバインド・タスク・フローを作成する点です。
|
注意: プロジェクトの作成時は、バインドなしタスク・フローを必ずしも作成する必要はありません。「プロジェクト・プロパティ」ダイアログの「テクノロジ・スコープ」ページで、選択したテクノロジとして「ADFページ・フロー」を指定している場合は、プロジェクト内で新しい |
作業を始める前に、次のようにします。
タスク・フローの構成内容を理解しておくと役に立つ場合があります。詳細は、18.2項「タスク・フローの作成」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
タスク・フローの作成方法:
タスク・フローの作成:
アプリケーション・ナビゲータで、タスク・フローを作成するプロジェクトを右クリックして、「新規」を選択します。
「新規ギャラリ」で、「Web層」を開いて、「JSF/Facelets」→「ADFタスク・フロー」を選択し、「OK」をクリックします。
図18-9に示すダイアログが表示されます。
「タスク・フローの作成」ダイアログでは、デフォルトで「バインド・タスク・フローとして作成」チェック・ボックスが選択されています。アプリケーションのバインドなしタスク・フローに組み込まれるソース・ファイルを作成するには、チェック・ボックスの選択を解除します。
チェック・ボックスの選択を解除すると、「ファイル名」フィールドのデフォルト値が自動的に変更されます。この値は、作成するタスク・フローのXMLソース・ファイルの名前に使用されます。XMLソース・ファイルには、タスク・フローのアクティビティおよび制御フロー・ルールを記述するメタデータが含まれます。
|
ヒント: バインドなしタスク・フローのデフォルト名は、 |
1つのプロジェクトには複数のタスク・フローを含めることができるので、ソース・ファイルに一意の名前を付けるために、「ファイル名」フィールドのデフォルト値に数字が追加されます(task-flow-definition3.xmlなど)。
「タスク・フローの作成」ダイアログでは、「ページ・フラグメントを使用して作成」チェック・ボックスがデフォルトで選択されます。
タスク・フローに追加するビュー・アクティビティが必要な場合はこのチェック・ボックスを選択解除して、メインのブラウザ・ウィンドウにレンダリングするJSFページをルート・ページとして参照します。タスク・フローに追加するビュー・アクティビティが必要な場合は、「ページ・フラグメントを使用して作成」チェック・ボックスを選択したままにして、実行時にADFリージョンでタスク・フローが表示するページ・フラグメント・ファイル(.jsff)を参照します。
「OK」をクリックします。
タスク・フローを表すダイアグラムがエディタに表示されます。
|
ヒント: タスク・フロー・ダイアグラム全体のサムネイルは、ダイアグラムをクリックし、メイン・メニューで「表示」→「サムネイル」を選択すると表示できます。 |
タスク・フローの作成後、ダイアグラム、概要およびソース・エディタを使用して更新できます。
タスク・フローの更新には、構造ウィンドウも使用できます。
|
ヒント: タスク・フローの作成には、既存のタスク・フローの内容を新規のタスク・フローにリファクタするなど、別の方法もあります。詳細は、18.6項「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。 |
「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルからダイアグラムへアクティビティをドラッグ・アンド・ドロップします。
通常は、ビュー・アクティビティから開始します。すべての種類のアクティビティを追加する手順の詳細は、18.3.1項「タスク・フローにアクティビティを追加する方法」を参照してください。
ダイアグラム上にビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、タスク・フローで起動するように構成されているJSFページまたはページ・フラグメントのウィザードを表示できます。このウィザードを使用してページまたはページ・フラグメントの特性を定義します。詳細は、19.2項「ビュー・アクティビティの使用」を参照してください。
|
注意: アプリケーション・ナビゲータからタスク・フローのダイアグラム上にページをドラッグ・アンド・ドロップして、タスク・フローにビュー・アクティビティを追加することもできます。 |
ルーター・アクティビティをダイアグラムにドラッグすると、プロパティ・インスペクタを使用して、どの制御フローに従うのかを判断するための式を作成できます。詳細は、19.4項「ルーター・アクティビティの使用」を参照してください。
コール・アクティビティをダイアグラム上にドラッグすると、プロパティ・インスペクタを使用して、コールするメソッドを構成できます。詳細は、19.5項「メソッド・コール・アクティビティの使用」を参照してください。
ダイアグラム上にタスク・フロー・アクティビティをドラッグすると、アクティビティをダブルクリックして、新しいバインド・タスク・フローの設定を定義できる「バインド・タスク・フローの作成」ウィザードを表示できます。詳細は、19.6項「タスク・フロー・コール・アクティビティの使用」を参照してください。
バインド・タスク・フローを作成し、ダイアグラム上にタスク・フロー・リターン・アクティビティをドラッグすると、プロパティ・インスペクタを使用してアクティビティを構成できます。詳細は、19.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。
アクティビティ間の制御フロー・ケースを作成します(詳細および詳細な手順は、18.4.1項「タスク・フローへの制御フロー・ルールの追加方法」を参照してください)。
コンポーネント・パレットの「ADFタスク・フロー」ページで、「制御フロー・ケース」を選択します。
ダイアグラムで、ビューなどのソース・アクティビティをクリックし、次にターゲット・アクティビティをクリックします。たとえば図18-15では、制御フローに2つのアクティビティがリンクされています。ソースとターゲットの両方(view1およびview2)のアクティビティがリンクされています。
「アクション(自)」属性(結果がメソッドによって決定する場合)または「結果(自)」属性(結果をStringとして設定可能な場合)を使用して結果値を設定します。
バインド・タスク・フローを作成する場合、いずれかのアクティビティをデフォルトに指定できます。それにより、タスク・フローの実行中は常にこの特定のアクティビティを最初に実行できます。デフォルトでは、タスク・フローに最初に追加したアクティビティがデフォルトになります。別なアクティビティに変更する場合は、ダイアグラム内で該当するアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択します。詳細は、18.2.3項「バインド・タスク・フローのデフォルト・アクティビティについて」を参照してください。
新規のバインドなしタスク・フローまたはバインド・タスク・フローを作成するたびに、新しいXMLソース・ファイルが作成されます。デフォルトでは、バインドなしタスク・フローのXMLソース・ファイルはadfc-config.xmlと呼ばれます。
例18-1に示すように、すべてのADFコントローラXMLソース・ファイルには、最上位の要素として<adfc-config>が最初に表示されます。バインド・タスク・フロー、アクティビティおよび制御フロー・ルールは、<adfc-config>要素の内部に定義されます。バインド・タスク・フローは、ソース・ファイル内で<task-flow-definition>メタデータ要素によって識別されます。
例18-1 バインド・タスク・フローのXMLソース・ファイル
<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
<task-flow-definition id="task-flow-definition">
<use-page-fragments/>
</task-flow-definition>
</adfc-config>
バインド・タスク・フローは、識別子とドキュメント名の一意な組合せで構成されたタスク・フロー参照によって識別されます。例18-2は、タスク・フロー・コール・アクティビティ内のタスク・フロー参照の例を示しています。
例18-2 タスク・フロー参照
<adfc-config xmlns="http://xmlns.oracle.com/adf/Controller" version="1.2">
<task-flow-definition id="task-flow-definition">
<use-page-fragments/>
.
.
<task-flow-call id="taskFlowCall">
<task-flow-reference>
<document>/WEB-INF/target-task-flow-definition.xml</document>
<id>my-task-flow</id>
</task-flow-reference>
</task-flow-call>
.
.
</task-flow-definition>
</adfc-config>
|
注意: JDeveloperを使用してバインド・タスク・フローを作成する場合は、各ドキュメントに1つのID(1つのバインド・タスク・フローを示す)のみを指定します。 |
バインド・タスク・フローを作成する場合は、識別子とドキュメント名の両方を割り当てます。例18-2に示すように、識別子は、「タスク・フローID」フィールドの値です。ドキュメント名は、「ファイル名」フィールドの値です。
デフォルト・アクティビティは、バインド・タスク・フローで実行される最初のアクティビティです。たとえば、タスク・フロー・コール・アクティビティからバインド・タスク・フローに制御が渡される場合は、デフォルト・アクティビティは常に最初に実行されます。
バインドなしタスク・フローにはデフォルト・アクティビティはありません。
図18-10に示すように、緑の円はタスク・フロー・ダイアグラムのデフォルト・アクティビティを示します。
新しいバインド・タスク・フロー・ダイアグラムに最初に追加するアクティビティはデフォルト・アクティビティとして自動的に識別されます。タスク・フロー・ダイアグラム内の任意のアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択することもできます。このデフォルトはすべてのアクティビティ・タイプで指定可能で、バインド・タスク・フローの制御フロー内でどの位置にも配置できます。デフォルト・アクティビティを検索するには、タスク・フロー・ダイアグラム上の任意の場所で右クリックし、「デフォルト・アクティビティに移動」を選択します。
バインド・タスク・フローで使用できるデフォルト・アクティビティは1つのみです。デフォルトとして2つ目のアクティビティをマークすると、最初のマークが自動的に解除されます。アクティビティのマークを手動で解除するには、タスク・フロー上の任意のアクティビティを右クリックし、「アクティビティのマーク解除」→「デフォルト・アクティビティ」を選択します。
トレインの途中でトレイン・ストップをデフォルト・アクティビティとして指定しないでください(詳細は、22.8項「バインド・タスク・フローでのtrainコンポーネントの使用」を参照)。
例18-3に、バインド・タスク・フローのSurveyPromptというデフォルト・アクティビティのメタデータの例を示します。
Fusion Webアプリケーション内の各タスク・フローでは、状態を管理するためにpageFlowスコープを定義しています。pageFlowスコープはタスク・フローの開始時に始まり、タスク・フローの終了時に終わります。pageFlowスコープで定義する一意の記憶域は、タスク・フローのアクティビティ間でのデータの受渡しに使用するアプリケーション内でタスク・フローのインスタンスごとに定義されます。あるタスク・フローが別なタスク・フローをコールする際、呼出し側のタスク・フローは呼出される側のpageFlowスコープにアクセスします。したがって、たとえば、タスク・フローのビュー・アクティビティが参照するページ上のUIコンポーネントでは、たとえこのタスク・フローがUIコンポーネントと同じページに組み込まれたADFリージョンであっても、別のタスク・フローのpageFlowスコープにアクセスできません。
タスク・フローで複数のマネージドBeanを定義できます。図18-11に、デフォルトのバインドなしタスク・フロー(adfc-config.xml)および顧客が登録したタスク・フローが、各種のスコープ値を使用して複数のマネージドBeanを参照している、Fusion Order Demoアプリケーションの例を示します。マネージドBeanに割り当てられたスコープを特定できます。
表18-3は、マネージドBeanに使用可能なスコープを示しています。また、タスク・フローで定義したマネージドBeanの各スコープの使用に適したタイミングも説明しています。この表はスコープを存続期間順に示しています。たとえば、アプリケーション・スコープは、リクエスト・スコープよりも存続期間が長くなっています。オブジェクト・スコープの存続期間の詳細は、25.3項「オブジェクト・スコープ・ライフサイクルについて」を参照してください。
表18-3 ADFマネージドBeanのメモリー・スコープ
| スコープ | 説明 |
|---|---|
|
アプリケーション |
アプリケーション・スコープはアプリケーション終了時まで続行します。このスコープのマネージドBeanに保存する値は、そのアプリケーションを使用する各セッションと各リクエストで使用できます。 タスク・フローに使用すると、タスク・フローが終了しても存続してしまうので、避けてください。 |
|
セッション |
セッション・スコープはユーザーがアプリケーション内のページに最初にアクセスしたときに始まり、非アクティブ状態になった場合、またはアプリケーションによるセッション認証が失敗した場合に、ユーザー・セッションがタイムアウトしたときに終了します。 このスコープは、セッション全体に関連する情報(ユーザー情報やコンテキスト情報など)にのみ使用します。タスク・フロー間で値を渡すためにセッション・スコープを使用しないでください。タスク・フロー間での値のやり取りには、パラメータを使用します。パラメータを使用すると、タスク・フローは、コール元あるいはコール先となる他のタスク・フローと明確に結ばれます。セッション・スコープの使用を避けるもう1つの理由は、タスク・フローが終了しても存続する可能性がある点です。最後に、同じセッション内でエンド・ユーザーが複数のブラウザ・ウィンドウを開いた場合は、ブラウザ・ウィンドウ間でセッション・スコープの値が共有されます。これらのブラウザ・ウィンドウ間では競合が発生する可能性もあります。 |
|
pageFlow |
タスク・フロー内のアクティビティ全体でマネージドBeanにアクセスできるようにしたい場合は、このスコープを選択します。pageFlowがあるマネージドBeanは、それにアクセスするタスク・フローのページと同じ状態にあります。pageFlowがあるマネージドBeanは、タスク・フローの存続期間中に存在します。 |
|
ビュー |
このスコープは、現在のビュー・アクティビティ内でのみ必要とされ、ビュー・アクティビティ間をまたがっていないマネージドBeanオブジェクトに使用します。 このスコープの存続期間は、ビュー・ポートの現在の JSFとOracle ADFにはこのスコープが実装されています。Fusion Webアプリケーションでは、1つの式にビュー・スコープを使用すると、Oracle ADF実装に解決されます。 |
|
リクエスト |
リクエスト・スコープは、現在のリクエストより長期間、マネージドBeanが存続する必要がない場合に使用します。 |
|
backingBean |
バッキングBeanは、JSFページ上のUIコンポーネントのアクセッサとイベント処理コードを保存するマネージドBeanの記述規則です。リクエストが終了するまで存続するもので、状態の維持には使用しないでください。 タスク・フローが同じJSFページの複数のADFリージョンに表示される可能性がある場合に、ADFリージョンの各インスタンスを分離するために使用します。 |
タスク・フローでマネージドBeanを定義すると、JDeveloperではタスク・フローのソース・ファイル内にある次のようなエントリが生成されます。
<managed-bean id="__15">
<managed-bean-name id="__16">egBackingBean</managed-bean-name>
<managed-bean-class id="__13">oracle....egBackingBean</managed-bean-class>
<managed-bean-scope id="__14">backingBean</managed-bean-scope>
</managed-bean>
<managed-bean-scope>要素には、マネージドBeanのスコープの値(例ではbackingBean)が含まれています。
UIコンポーネントをマネージドBeanにバインドすると、JDeveloperはマネージドBeanの参照用に生成するEL式のスコープ名にScopeを付加します。たとえば、マネージドBeanを参照する表コンポーネントのバインド属性には次のEL式があります。
<af:table id="cartTab"
...
binding="#{backingBeanScope.egBackingBean.table}"
...
</af:table>
UIコンポーネントのバインド属性で参照するマネージドBeanのスコープを、backingBeanまたはリクエスト・スコープに限定します。UIコンポーネントのインスタンスはシリアライズできません。backingBeanとリクエスト以外のスコープのオブジェクトは、シリアライズ可能と考えられています。そのため、backingBeanまたはリクエスト以外のスコープのマネージドBeanに、UIコンポーネントをバインドしてはなりません。JDeveloperでは、UIコンポーネントのバインディング属性およびリージョン・フラグメントが、backingBeanスコープを使用するようにデフォルト設定されています。
|
注意: Oracle ADF固有のカスタム・スコープ(pageFlow、backingBean、ビュー・スコープなど)にアクセスするEL式を記述する場合、アクセスするスコープを明示的に指定するEL式を記述します.たとえばpageFlowスコープにアクセスするEL式は次のように記述します。
|
単一のアプリケーションで、複数のバインドなしタスク・フローXMLソース・ファイルと複数のバインド・タスク・フローXMLソース・ファイルを持つことができます。バインドなしタスク・フローの生成のために組み合せたファイル・セットは、アプリケーションのADFコントローラ・ブートストラップ構成ファイルと呼ばれています。バインドなしタスク・フローは、1つ以上のADFコントローラ・ブートストラップ構成ファイルを組み合せて、実行時にアセンブルされます。バインド・タスク・フロー内に含まれないブートストラップ構成ファイルのすべてのアクティビティは、バインドなしタスク・フロー内にあるとみなされます。
1つのアプリケーション内のソース・ファイル名は、異なる名前である必要があります。図18-12の例には、2つのバインドなしタスク・フロー(adfc-config、adfc-config2)と、1つのバインド・タスク・フロー(task-flow-definition)があります。
タスク・フローの作成後、タスク・フローにアクティビティを追加し、アクティビティ間の制御フローを構成します。JDeveloperの「コンポーネント・パレット」に、使用可能なアクティビティおよび制御フローが表示されます。「コンポーネント・パレット」からタスク・フロー・ダイアグラムに、アクティビティおよび制御フローをドラッグ・アンド・ドロップします。次にアクティビティ間の制御フローを構成し、タスク・フローが必要なタスクを実行できるようにします。
タスク・フローを作成すると、タスク・フロー・ダイアグラムとコンポーネント・パレットが自動的に表示されます。タスク・フロー・ダイアグラムはビジュアル・エディタであり、そこでタスク・フローのアクティビティおよび制御フローを追加できます。これは、コンポーネント・パレットからドラッグしてダイアグラムに追加できます。
作業を始める前に、次のようにします。
タスク・フローに追加可能なアクティビティを理解しておくと役に立つ場合があります。詳細は、18.3項「タスク・フローへのアクティビティの追加」を参照してください。
また、他のADF機能を使用してタスク・フローに追加可能な機能について理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
タスク・フローにアクティビティを追加する手順:
アプリケーション・ナビゲータで、タスク・フロー・ソース・ファイルをダブルクリックします。
たとえば、図18-13はタスク・フロー・ソース・ファイル(task-flow-definition.xml)をダブルクリックすると自動的に表示されるエディタおよび「コンポーネント・パレット」を示します。
「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルからダイアグラムへアクティビティをドラッグ・アンド・ドロップします。
ダイアグラム上にビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、JSFページまたはページ・フラグメントの作成用ウィザードを表示できます。詳細は、19.2項「ビュー・アクティビティの使用」を参照してください。
ダイアグラム上にタスク・フロー・アクティビティをドラッグすると、アクティビティをダブルクリックして、新しいバインド・タスク・フローの設定を定義できる「バインド・タスク・フローの作成」ウィザードを表示できます。詳細は、19.6項「タスク・フロー・コール・アクティビティの使用」を参照してください。
|
ヒント: タスク・フロー・ダイアグラムに各アクティビティをドラッグすると、アクティビティに関する追加情報を提供するオプションのステータス・アイコンとツールチップを表示できます。たとえば、タスク・フロー・ダイアグラムにビュー・アクティビティをドラッグすると、それをJSFページに関連付けるまで警告アイコンが表示されることがあります。 アイコンをオンにするには、タスク・フロー・ダイアグラムの上部にある「表示」を選択し、続いて「ステータス」と次のいずれかを選択します。
2次アイコンの上にマウスをドラッグすると、アイコンの意味を説明するツールチップを表示できます。 |
ADFコントローラ制御フロー・ルールでは、タスク・フローで、あるアクティビティから次のアクティビティに制御を渡す方法が定義されています。制御フロー・ルールには、1つまたは複数の制御フロー・ケースを含めることができます。制御フロー・ケースでは、制御フローを渡すアクティビティが特定されます。また、制御ケースでは、オプションで、条件付きナビゲーション(<if>要素を使用)、または制御フローの発生元から取得したアクション値に基づく制限ナビゲーション(from-action要素を使用)を構成できます。
制御フロー・ルールは、JSFナビゲーション・ルールに基づきますが、その他の情報を取得します。JSFナビゲーションは常にページ間のものですが、制御フロー・ルールはアクティビティ間の遷移を示します。たとえば、制御フロー・ルールは、ビュー・アクティビティとそれ以降のメソッド・コール・アクティビティ間の遷移を示します。または、そのページ(ビュー・アクティビティ)から別のタスク・フローに制御を渡すように指定できます。
次のタスク・フロー・アクティビティは、制御フロー・ルールのソースになることはありません。
セーブポイント・リストア
タスク・フロー・リターン
URLビュー
制御フロー・ルールの基本構造は、JSFナビゲーション・ルールを模倣したものです。表18-4には、JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのメタデータのマップ方法が示されています。
表18-4 JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのマッピング
| JSFナビゲーション・ルール | ADFコントローラ制御フロー・ルール |
|---|---|
|
ナビゲーション・ルール |
制御フロー・ルール |
|
ビューID(自) |
アクティビティID(自) |
|
ナビゲーション・ケース |
制御フロー・ケース |
|
アクション(自) |
アクション(自) |
|
結果(自) |
結果(自) |
|
条件 |
条件 |
|
ビューID(至) |
アクティビティID(至) |
ADFタスク・フローの使用時、faces-config.xmlファイルのJSFナビゲーション・ルールを使用するかわりに、ADFコントローラ制御フロー・ルールを使用してすべてのアプリケーション・ナビゲーションを実行します。ADFコントローラは、メタデータ内に一致する制御フロー・ケースが見つからない場合はナビゲーション処理を委譲します。ただし、ADF以外のコントローラのナビゲーション・ハンドラによってナビゲーションが実行された場合は、すべてのADFコントローラ機能の正常動作が保証されるとは限りません。ADFコントローラによる制御フロー・ルールの評価方法の詳細は、18.4.4項「実行時に行われる処理: 制御フロー・ルール」を参照してください。
アクティビティ間の基本的な制御フロー作成の開始ポイントとして、タスク・フロー・ダイアグラムを使用します。その後、タスク・フロー・ダイアグラムの構造ウィンドウ、プロパティ・インスペクタまたは概要エディタで制御フロー・プロパティを編集できます。
|
ヒント: アクティビティを既存の制御フローにドラッグ・アンド・ドロップできます。これによって既存の制御フローが、アクティビティを中心として2つに分割されます。 |
制御フロー・ルールを作成するには、「コンポーネント・パレット」の「ADFタスク・フロー」ページから「制御フロー・ケース」をソース・タスク・フロー・アクティビティおよびターゲット・タスク・フロー・アクティビティにドラッグ・アンド・ドロップします。
作業を始める前に、次のようにします。
タスク・フロー・ルールの内容を理解しておくと有効な場合があります。詳細は、18.4項「タスク・フローへの制御フロー・ルールの追加」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
制御フロー・ルールをタスク・フローに追加する手順:
「アプリケーション・ナビゲータ」で、制御フロー・ルールを追加するタスク・フローのソース・ファイルをダブルクリックします。たとえば、adfc-config.xmlなどです。
コンポーネント・パレットの「ADFタスク・フロー」ページで、「制御フロー・ケース」を選択します。
ダイアグラム上で、ソースとなるタスク・フロー・アクティビティ(ビュー・アクティビティなど)をクリックしてから、対象先のタスク・フロー・アクティビティをクリックします。
図18-15には、制御フロー・ケースとリンクされている2つのタスク・フロー・アクティビティ(view1およびview2)が示されています。
ダイアグラムに制御フロー・ケースが追加されます。JDeveloperによってタスク・フロー・アクティビティ間に追加された各行は制御フロー・ケースを表します。矢印は、制御フロー・ケースの方向を示します。「結果(自)」要素には、UIコンポーネントのaction属性で指定された値に一致する可能性がある値が含まれています。
「結果(自)」の値を変更するには、ダイアグラムで制御フローの隣にあるテキストを選択します。図18-15に示すように、デフォルトでは、このテキストはワイルドカード(*)文字です。このテキストは新しい値(toView2など)で上書きができます。
「アクティビティID(自)」(ソース・アクティビティを識別する)または「アクティビティID(至)」(ターゲット・アクティビティを識別する)の値を変更するには、ダイアグラム内で矢印の端のいずれかをドラッグして、新規のアクティビティまで移動します。
|
ヒント: タスク・フロー・ダイアグラムの制御フローを選択すると、プロパティ・インスペクタや構造ウィンドウでそのプロパティを変更することもできます。構造ウィンドウは、制御ルールとケースの間の関連の表示に役立ちます。 また、タスク・フロー・ダイアグラムの概要エディタの「制御フロー」をクリックしてケースを追加することもできます(図18-16を参照)。ケースを追加するには、ルールの「アクティビティ(自)」(ソース・アクティビティ)および「アクティビティ(至)」(ターゲット・アクティビティ)がタスク・フローに追加されていることを確認します。 |
オプションとして、「プロパティ・インスペクタ」では、「動作」セクションを開いて、値がtrueになる必要がある、「If」フィールド内のEL式を記述した後に、「アクティビティID(至)」によって識別されたアクティビティに制御を渡すことができます。
バインドなしまたはバインド・タスク・フローにワイルドカード制御フロー・ルールを追加できます。追加の手順は、タスク・フロー・ダイアグラムへのアクティビティの追加の手順とほぼ同じです。
作業を始める前に、次のようにします。
使用可能な制御フロー・ルールのオプションを理解しておくと有効な場合があります。詳細は、18.4項「タスク・フローへの制御フロー・ルールの追加」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
ワイルドカード制御フロー・ルールを追加する手順:
「アプリケーション・ナビゲータ」で、タスク・フローのソース・ファイルをダブルクリックして、タスク・フロー・ダイアグラムを表示します。たとえば、adfc-config.xmlなどをダブルクリックします。
「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「ワイルドカード制御フロー・ルール」をダイアグラム上にドラッグ・アンド・ドロップします。
「コンポーネント・パレット」の「ADFタスク・フロー」ページにある「制御フロー・ケース」を選択します。
タスク・フロー・ダイアグラムで、制御フロー・ケースをワイルドカード制御フロー・ルールからターゲット・アクティビティにドラッグします。
ターゲットはどのアクティビティ・タイプでもかまいません。
デフォルトでは、ワイルドカード制御フロー・ルールの後のラベルは*です。これは、「アクティビティID(自)」要素の値です。この値を変更するには、ダイアグラムでワイルドカード制御フロー・ルールを選択します。ワイルドカード制御フロー・ルールのプロパティ・インスペクタで、 「アクティビティID(自)」フィールドに新しい値を入力します。たとえば、project*と入力します。新しいラベルでは、ワイルドカードは後続の文字である必要があります。
|
ヒント: タスク・フロー・ダイアグラムの概要エディタにある「アクティビティID(自)」の値も変更できます。 |
オプションとして、「プロパティ・インスペクタ」では、「動作」セクションを開いて、値がtrueになる必要がある、「If」フィールド内のEL式を記述した後に、「アクティビティID(至)」によって識別されたアクティビティに制御を渡すことができます。
タスク・フローのソース・ファイルのルールを定義する要素を理解すると、タスク・フロー・ダイアグラム、タスク・フローの概要エディタまたは「構造」ウィンドウで制御フロー・ルールを直接作成する際、あるいは制御フロー・ルールをXMLソース・ファイルに直接追加する際に役に立ちます。例18-4に、タスク・フロー・ソース・ファイルの制御フロー・ルール要素の一般的な構文を示します。
例18-4 ソース・ファイルの制御フロー・ルールの構文
<control-flow-rule>
<from-activity-id>from-view-activity</from-activity-id>
<control-flow-case>
<from-action>actionmethod</from-action>
<from-outcome>outcome</from-outcome>
<to-activity-id>destinationActivity</to-activity-id>
<if>#{myBean.someCondition}</if>
</control-flow-case>
<control-flow-case>
....
</control_flow-case>
</control-flow-rule>
制御フロー・ルールは、次のメタデータで構成されます。
control-flow-rule: 制御フロー・ケース要素の必須ラッパー要素。
from-activity-id: 制御フロー・ルールの発生元となるアクティビティの識別子(sourceなど)。
from-activity-idの後方ワイルドカード(*)文字がサポートされています。ルールは、ワイルドカードのパターンに一致するすべてのアクティビティに適用されます。たとえば、login*は、リテラルloginで始まるすべての論理アクティビティID名と一致します。メタデータに(後方ワイルドカードではなく)単一のワイルドカード文字を指定すると、ダイアグラムで、制御フローが自動的にワイルドカード制御フロー・ルール・アクティビティに変換されます。詳細は、18.4.2項「ワイルドカード制御フロー・ルールの追加方法」を参照してください。
control-flow-case: 制御フロー・ルールの各ケースの必須ラッパー要素。それぞれのケースで、同じソース・アクティビティに対して異なる制御フローを定義します。制御フロー・ルールには、少なくとも1つの制御フロー・ケースが必要です。
from-action: 指定されたアクション・メソッドからの結果のみにルールの適用を制限する任意の要素。アクション・メソッドは、ELバインディング式(#{backing_bean.cancelButton_action}など)として指定されます。
例18-4では、outcomeがactionmethodから返された場合にのみ制御がdestinationActivityに渡されます。
from-actionの値は、ビュー・アクティビティから発生する制御フローのみに適用され、その他のアクティビティ・タイプからのものには適用されません。from-actionでは、ワイルドカードはサポートされていません。
from-outcome: 特定の元のアクティビティ結果に基づき、続いて起こる制御フロー・ケースを識別する要素。考えられるすべての元のアクティビティの結果は、制御フロー・ケースと適合する必要があります。
from-action要素とfrom-outcome要素の両方を空のままにすると、ケースはアクティビティに対して定義されたその他の制御フロー・ケースでは識別されないすべての結果に適用されるため、アクティビティのデフォルト・ケースが作成されます。from-outcomeでは、ワイルドカードはサポートされていません。
to-activity-id: 制御フロー・ケースが実行される場合にナビゲーションのルーティング先となるアクティビティの完全な識別子が含まれる必須要素。各制御フロー・ケースは、異なるto-activity-idを指定できます。
if: EL式の値を受け取るオプション要素です。実行時にEL式の値がtrueの場合は、to-activity-id要素によって識別されたアクティビティに制御フローを渡します。
実行時、ADFコントローラは、最も具体的な一致から最も具体的でない一致まで制御フロー・ルールを評価して、アクティビティ間の次の遷移を決定します。評価は次の優先順位に基づきますが、これはJSFナビゲーション・ルールと類似しています。
from-activity-id、from-action、from-outcome
from-activity-id、from-outcome
from-activity-id
ADFコントローラは、最初にfrom-activity-id、from-action、from-outcomeの3つの要素すべての一致を検索します。一致がない場合は、from-activity-idおよびfrom-outcome要素のみの一致を検索します。最後に、from-activity-id要素のみの一致を検索します。
ADFコントローラのメタデータ内でリクエストと一致する制御フロー・ルールを検出できない場合は、標準JSFナビゲーション・ハンドラによる一致の検出が許可されます。
バインドなしタスク・フローには、複数のADFコントローラXMLソース・ファイルを含めることができます。複数のADFコントローラXMLソース・ファイルに制御フロー・ルールを定義できるため、似たようなルールが異なるファイルに定義される場合もあります。2つ以上のケースに同じfrom-activity-id、from-actionまたはfrom-outcomeの値が存在するといった競合がある場合は、(adfc-config.xml、ブートストラップまたはバインド・タスク・フローのソース・ファイルで記述される順序で)最後のケースが使用されます。異なるソース・ファイルに定義されたルール間で競合がある場合は、最後にロードされるソース・ファイルのルールが使用されます。
また、ADFコントローラには、次の複数の制限を使用して次のインタフェースを実装します。
javax.faces.application.ConfigurableNavigationHandler
制限は次のとおりです。
getNavigationCases()によって返されたMapオブジェクトは変更できません。制御フロー・ルールを実行時に変更するには、必ずMDSフレームワークを実装したカスタマイズ機能で実行される必要があります。詳細は、第39章「MDSによるアプリケーションのカスタマイズ」を参照してください。
JSFアプリケーション起動フェーズ後は、performNavigation()メソッドを起動してはいけません。これは、ADFレンダリング準備フェーズとJSFレスポンス・レンダリング・フェーズとの間でビューIDが変更されていないことを確認するためです。ページ・リクエストのライフサイクルでのJSFフェーズとADFフェーズの統合方法の詳細は、第25章「Fusionページ・ライフサイクル」を参照してください。
タスク・フロー・ビュー・アクティビティのブックマークおよびリダイレクトのプロパティに対するメタデータの値には、getNavigationCases()によって返されるナビゲーション・ケース・オブジェクトに対応する情報が移入されます。
タスク・フローを実行してデバッグするプロシージャは、タスク・フローがバインドかバインドなしか、ページまたはページ・フラグメントのどちらを含んでいるか、入力パラメータを受け入れるかどうかに応じて異なります。
JDeveloperおよびOracle ADFには、作成したタスク・フローのテストに役立つ多くの機能があります。その1つとして、タスク・フロー・アクティビティにADF宣言ブレークポイントを設定する機能があります。詳細は、36.9.1項「タスク・フロー・アクティビティ・ブレークポイントの設定方法および使用方法」を参照してください。さらに、統合WebLogic Serverで現在実行しているアプリケーションのタスク・フローのメタデータを変更できます。タスク・フローに対する変更をアプリケーションにデプロイする作業は、アプリケーションを停止し、統合WebLogic Serverに再デプロイしなくても実行できます(ホット・リロードとも呼ばれます)。これを行うには、変更されたタスク・フロー上で作成用のコマンドを起動します(タスク・フローを右クリックし、表示されたコンテキスト・メニューから「メイク」を選択します)。これにより、変更されたタスク・フローが統合WebLogic Serverで実行中のアプリケーションにデプロイされます。ホット・リロードの詳細は、36.4項「統合WebLogic ServerでのOracle ADFメタデータのリロード」を参照してください。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
ページであるビュー・アクティビティを含むバインド・タスク・フローを実行またはデバッグできます。
ページ・フラグメントであるビュー・アクティビティを含むバインド・タスク・フローの実行方法の詳細は、18.5.2項「ページ・フラグメントを使用するバインド・タスク・フローの実行方法」を参照してください。
|
注意: タスク・フロー・ダイアグラムまたはアプリケーション・ナビゲータ内でビュー・アクティビティを選択し、「実行」を選択すると、バインド・タスク・フローを実行できます。 バインド・タスク・フローでは、ビューをデフォルト・アクティビティとして指定し、アプリケーション・ナビゲータからタスク・フローを実行する必要があります。詳細は、18.2.3項「バインド・タスク・フローのデフォルト・アクティビティについて」を参照してください。 タスク・フローで実行される最初のアクティビティがビュー以外のアクティビティ・タイプである場合は、バインド・タスク・フローを使用する必要があります。 |
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
ページを使用するバインド・タスク・フローを実行またはデバッグする手順:
タスク・フロー・ダイアグラムで、タスク・フローを右クリックし、「実行」または「デバッグ」を選択します。
ブラウザにURLを入力してタスク・フローを直接実行することもできます。たとえば、次のように入力します。
http://somecompany.com/internalApp/MyApp/faces/adf.task-flow?adf.tfId=displayHelp&adf.tfDoc=%2FWEB-INF%2Fdisplayhelp.xml&topic=createPurchaseOrder
詳細は、19.6.6項「URLを使用したバインド・タスク・フローのコールについて」を参照してください。
アプリケーション・ナビゲータでバインド・タスク・フローを右クリックし、「実行」または「デバッグ」を選択できます。
ページ・フラグメントを使用するバインド・タスク・フローは、ADFリージョン内でのみ実行することを目的としています。ページ・フラグメントは、別のJSFページのコンテンツとしてレンダリングされるJSFドキュメントです。詳細は、21.1.1項「ページ・フラグメントおよびADFリージョンについて」を参照してください。
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
ページ・フラグメントを使用するバインド・タスク・フローを実行またはデバッグする手順:
まだ実行していない場合は、バインド・タスク・フローにバインドされたリージョンを含むJSFページを作成します。ページ・フラグメントを含むバインド・タスク・フローをページ上にドロップすると、JDeveloperではJSFページに使用するリージョンが自動作成されます。リージョン作成の詳細は、21.2項「ADFリージョンの作成」を参照してください。
ページを参照するプロジェクトのバインドなしタスク・フローにビュー・アクティビティを作成します。詳細は、18.3.1項「タスク・フローにアクティビティを追加する方法」を参照してください。
アプリケーション・ナビゲータまたはタスク・フロー・ダイアグラムでビュー・アクティビティを右クリックし、「実行」を選択します。
パラメータのあるバインド・タスク・フローを実行する前に、ページを含むバインド・タスク・フローを実行する必要があります。バインド・タスク・フロー入力パラメータの詳細は、第20章「タスク・フローのパラメータの使用」を参照してください。
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
入力パラメータ定義を含むバインド・タスク・フローを実行する手順:
JSFページは、アプリケーション・ナビゲータでページを右クリックし、「実行」を選択して実行できます。ただし、ボタンやリンクなどのナビゲーションUIコンポーネントがページに含まれている場合は、ナビゲーションが機能する保証はありません。
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
ナビゲーションを完全に機能させてJSFページを実行する手順:
バインド・タスク・フローまたはバインドなしタスク・フローを作成します。詳細は、18.2.1項「タスク・フローの作成方法」を参照してください。
タスク・フローにビュー・アクティビティを追加します。詳細は、18.3.1項「タスク・フローにアクティビティを追加する方法」を参照してください。
アプリケーション・ナビゲータで、実行するJSFページを選択し、タスク・フロー・ダイアグラムにあるビュー・アクティビティの上部にドロップします。
これにより、JSFページがビュー・アクティビティと関連付けられます。
ダイアグラムでビュー・アクティビティを右クリックし、「実行」を選択します。
バインドなしタスク・フローを実行またはデバッグするには、バインドなしタスク・フローの起動に使用する特定のビュー・アクティビティを選択します。
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
バインドなしタスク・フローでビュー・アクティビティを実行する手順:
タスク・フロー・ダイアグラムで、ビュー・アクティビティを右クリックし、「実行」または「デバッグ」を選択します。
選択したビュー・アクティビティからバインドなしタスク・フローが実行されます。
単一のビュー・アクティビティ以外を選択している(あるいは何も選択していない)場合、「実行コンフィギュレーションの設定」ダイアログで1つ選択するように求められます。
実行構成には、タスク・フローで実行する最初のアクティビティなど、プロジェクトの実行方法を決定する設定が含まれます。1つのプロジェクトに対して1つ以上の実行構成を定義できます。実行構成内では、デフォルトの実行ターゲットとしてADFコントローラのソース・ファイルを指定できます。プロジェクトを実行すると、ソース・ファイルが最初に実行されます。
作業を始める前に、次のようにします。
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.5項「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
デフォルトのタスク・フロー実行ターゲットを定義する手順:
アプリケーション・ナビゲータでプロジェクトを選択します。
メイン・メニューから、「実行」→「アクティブな実行構成を選択」→「実行構成の管理」を選択します。
「実行構成の管理」ダイアログで「実行/デバッグ/プロファイル」を選択し、次に「新規」を選択します。
「新規」ダイアログで、新規実行構成の名前を入力します。
既存の構成に基づいて新規の構成を作成する場合は、「設定のコピー元」ドロップダウン・リストで構成を選択します。
「OK」をクリックして、ダイアログを終了します。
「編集」をクリックします。
「実行構成の編集」ダイアログの「デフォルトの実行ターゲット」で、プロジェクトの実行時に最初に実行が必要なタスク・フローのソース・ファイルを指定します。
タスク・フローを選択すると、(バインドなしタスク・フロー用の)ビュー・アクティビティまたは(バインド・タスク・フロー用の)入力パラメータを設定できます。
「構成の編集」ダイアログの左側のパネルで、「ADFタスク・フロー」をクリックします。
右側のパネルにある「タスク・フロー」ドロップダウン・リストで、実行ターゲットを含むタスク・フローを選択します。
バインドなしタスク・フローを実行している場合は、「実行構成の編集」ダイアログにターゲット・アクティビティの実行リストが表示されます。アプリケーションで最初に実行するビュー・アクティビティを選択します。
「開く」をクリックします。
次にプロジェクトを実行する際、保存された実行構成が「実行」→「アクティブな実行構成を選択」メニューで利用可能になります。
入力パラメータを受け付ける用に設定されたバインド・タスク・フローを実行している場合は、バインド・タスク・フロー用に定義されたすべての入力パラメータの値を指定するセクションがダイアログに表示されます。詳細は、18.5.3項「パラメータのあるバインド・タスク・フローの実行方法」を参照してください。
既存のアクティビティ、JSFページ・フローおよびJSFページを、新規のADFコントローラ・コンポーネント(バインド・タスク・フローおよびタスク・フロー・テンプレートなど)に変換できます。
新規のバインド・タスク・フローは、既存のバインドまたはバインドなしタスク・フローで選択したアクティビティに基づいて作成できます。
作業を始める前に、次のようにします。
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.6項「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
選択されたアクティビティから新規のバインド・タスク・フローを作成する手順:
「アプリケーション・ナビゲータ」で、新規バインド・タスク・フローへの解凍が必要なアクティビティを含む、バインドなしタスク・フローまたはバインド・タスク・フローのソース・ファイルをダブルクリックします。
タスク・フロー・ダイアグラムで1つ以上のアクティビティを選択します。
|
ヒント: ダイアグラムで複数のアクティビティを選択するには、マウスの左ボタンをクリックしたまま、アクティビティの上にカーソルをドラッグします。 [Ctrl]キーを押しながらそれぞれのアクティビティを選択することもできます。 |
選択を右クリックして、表示されたコンテキスト・メニューから「タスク・フローの抽出」を選択します。
「バインド・タスク・フローの抽出」ダイアログが表示されます。このダイアログでは、新規のバインド・タスク・フローのファイル名およびディレクトリの場所を指定できます。詳細は、18.2項「タスク・フローの作成」を参照してください。
タスク・フロー・ダイアグラムに新規のバインド・タスク・フローが表示されます。表18-5は、JDeveloperにより自動設定される、新規のバインド・タスク・フローのプロパティについて説明しています。
表18-5 新規バインド・タスク・フローで更新されるプロパティ
| プロパティ | 値 |
|---|---|
|
タスク・フロー定義ID |
「バインド・タスク・フローの抽出」ダイアログの「ファイル名」フィールドに入力した値です。 |
|
デフォルト・アクティビティ |
すべての受信制御フロー・ケースのターゲットとして指定。複数のターゲットが存在する場合、エラーのフラグが立てられ、操作全体がロールバックされます。 |
|
制御フロー・ルール |
選択されたソース・アクティビティのある制御フロー・ケースは、新規のバインド・タスクに組み込まれます。ソース・アクティビティは、制御フローの発生元のアクティビティです。新規のバインド・タスク・フローには、次のタイプの制御フロー・ケースがあります。
|
元のタスク・フロー(新規タスク・フローの基礎として選択したアクティビティを含むタスク・フロー)で次のような変更が自動的に実行されます。
新規タスク・フロー・コール・アクティビティが、元のタスク・フローに追加されます。タスク・フロー・コール・アクティビティは、新規のバインド・タスク・フローをコールします。
選択されたアクティビティが元のタスク・フローから削除されます。
選択したアクティビティに関連付けられた既存の制御フロー・ケースが、元のタスク・フローから削除されます。これは新規の制御フロー・ケースに置き換えられます。
古いアクティビティに対する受信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティにリダイレクトされます。
古いアクティビティからの送信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティからリダイレクトされます。
JSFページ・フローで選択したページに基づいて、新規のバインド・タスク・フローを作成できます。JDeveloperでは、フローの一部であるJSFページ(つまり、JSFナビゲーション・ケースによってリンクされたページ)が新規タスク・フローのビュー・アクティビティに変換されます。
作業を始める前に、次のようにします。
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.6項「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
ページ・フローで選択したJSFページから新規のタスク・フローを作成する手順:
「アプリケーション・ナビゲータ」で、新規バインド・タスク・フローで使用するページを含むページ・フローのソース・ファイルをダブルクリックします。
タスク・フロー・ダイアグラムで1つ以上のJSFページを選択します。
|
ヒント: ダイアグラムで複数の要素を選択するには、マウスの左ボタンをクリックしたまま、要素の上にカーソルをドラッグします。 [Ctrl]キーを押しながらそれぞれの要素を選択することもできます。 |
選択したものを右クリックして、「ADFタスク・フローの生成」を選択します。
「タスク・フローの作成」ダイアログが表示され、新規のバインドなしタスク・フローまたはバインド・タスク・フローを作成できます。詳細は、18.2項「タスク・フローの作成」を参照してください。
既存のバインド・タスク・フローをバインドなしタスク・フローに変換したり、そこに含まれるビューがページまたはページ・フラグメントのいずれかを変更できます。表18-6に、それぞれの変換結果を示します。
表18-6 バインド・タスク・フローの変換
| 変換 | 結果 |
|---|---|
|
バインド・タスク・フローからバインドなしタスク・フローへの変換 |
パラメータ定義やトランザクションなど、バインドなしタスク・フローに対して無効なすべてのメタデータが失われます。 |
|
JSFページを使用するためのバインド・タスク・フローの変換 |
タスク・フロー内の任意のビュー・アクティビティに関連付けられたページ・フラグメントをJSFページに変換します。「ページ・フラグメントを保持」チェック・ボックスを選択している場合、古いページ・フラグメントは保存されます。新規のJSFページ名は、デフォルトで古いページ・フラグメント名になります。 |
|
ページ・フラグメントを使用するためのバインド・タスク・フローの変換 |
バインド・タスク・フロー内のビュー・アクティビティに関連付けられたすべてのページをページ・フラグメントに変換します。「ページを保持」チェック・ボックスを選択している場合、古いページは保存されます。新規のページ・フラグメント名は、デフォルトで古いページ名になります。 |
作業を始める前に、次のようにします。
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、18.6項「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、18.1.5項「ADFタスク・フローの追加の機能」を参照してください。
バインド・タスク・フローを変換する手順:
「アプリケーション・ナビゲータ」で、変換が必要なバインド・タスク・フローのソース・ファイルをダブルクリックします。
タスク・フロー・ダイアグラムで、アクティビティまたは制御フロー以外の任意の場所を右クリックします。
次の適切なメニュー・オプションを選択します。
バインドなしタスク・フローへの変換
ページ・フラグメントを含むタスク・フローへの変換
ページを含むタスク・フローへの変換
表18-7では、タスク・フロー、アクティビティ、その他ADFコントローラの関連機能を使用する場合の前提条件と制約をまとめています。
表18-7 ADFコントローラ機能の前提条件および制約
| 機能エリア | 前提条件/ 制約 |
説明 |
|---|---|---|
|
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
JSFビュー・レイヤー |
ADFコントローラはJSF環境で動作します。OracleのWebベースのFusion Webアプリケーション戦略は、唯一のビュー・レイヤー・テクノロジとしてJSFに焦点を当てています。 |
|
Oracle ADF Faces依存 |
ADFコントローラの拡張機能はOracle ADF Faces上に実装されています。この機能はADF Facesライブラリに依存しますが、これらのライブラリが存在する場合はJSF実装に対して実行できます。 |
|
|
カプセル化されたナビゲーションおよび状態管理 |
ADFコントローラでは、ナビゲーションと(ある程度までの)状態管理もカプセル化します。JSFおよびサーブレットAPIは、現在もアプリケーション、セッションおよびリクエストのレベルでの基本の状態管理に利用できます。 |
|
|
モデル・レイヤー |
ADFモデル・レイヤーは、アプリケーションのモデル・レイヤーの実装に使用されます。 |
|
|
MDSへの依存 |
ADFコントローラ・メタデータはMDSに保存されます。ただし、MDSは現在 MDSが提供しているカスタマイズ機能が必要な場合は、ADFタスク・フローを占有使用してマネージドBeanと制御フロー・ルールの定義を行う必要があります。 |
|
|
StrutsまたはModel 1からの移行パスのサポートなし |
StrutsまたはModel 1からFusion ADF Controllerへの移行はサポートされていません。 しかし、JSFページ・フローで選択したページに基づいて、新規のADFバインド・タスク・フローを作成できます。詳細は、18.6.2項「JSFページからのタスク・フローの作成方法」を参照してください。 |
|
|
バインド・タスク・フロー |
ページ・フロー・スコープ状態として公開 |
ADFコントローラは、ページ・フロー・スコープの状態の実装を管理します。フレームワークによって提供される自動管理機能(「戻る」ボタンのサポート、状態のクリーンアップ機能など)は、ページ・フロー・スコープのデータを想定しています。アプリケーションでそのページのすべてに対してこのような機能を完全実装するために、必要に応じてネストされたバインド・タスク・フローを使用して、アプリケーション全体をADFバインド・タスク・フローとして公開します。アプリケーションには、ページ・フロー・スコープ内にバージョニングを必要とする状態が格納されます。 |
|
トランザクション境界 |
開発者は、ADFバインド・タスク・フローを使用してトランザクション境界を管理します。 |
|
|
ページ・フロー・スコープ |
ADFライフサイクル内のアクセスの可用性 |
ADFコントローラでアクセス準備ができる前のADFライフサイクルの初期段階では、アプリケーションによるページ・フロー・スコープへのアクセスは試行できません。 ページ・フロー・スコープは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerが実行されるまでは、アクセス可能になるとは保証されていません。ADFコントローラは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerを使用して、サーバー側の状態をリクエストと同期化させます。ここでは、ブラウザの「戻る」ボタン検出やブックマーク参照解除などが処理されます。 |
|
ナビゲーション |
ナビゲーション |
ADFコントローラの使用時、 ADFコントローラはADFコントローラ・メタデータ内に一致する制御フロー・ケースがない場合にナビゲーション処理を委譲しますが、ADF以外コントローラ以外の |
