| Oracle® Fusion Middleware Oracle WebCenter PortalおよびOracle JDeveloperでのポータルの開発 11gリリース1 (11.1.1.8.3) E49666-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter PortalおよびOracle JDeveloperでのポータルの開発 11gリリース1 (11.1.1.8.3) E49666-03 |
|
前 |
次 |
この章では、実行時にページに対して行われた変更を保存するためのカスタマイズ・レイヤーを作成する方法を説明します。コンポーザのサンドボックスの作成を有効にし、変更をバック・エンドに保存する前にプレビューするオプションをユーザーに提供する方法も説明します。
この章の内容は、次のとおりです。
ほとんどの業界では、様々な顧客および分野で役に立つようにエンタープライズ・アプリケーションをカスタマイズします。サイトレベルでアプリケーションを変更すると問題が発生する可能性があります。たとえば、アプリケーション・レベルのカスタマイズでアプリケーションをアップグレードすると、データの損失またはデータ・マージ・エラーが発生する場合があります。結果として、すべてのマージ競合を解決するまで新しいバージョンのアプリケーションをデプロイできません。
メタデータ・ドメインでは、MDSにこのような問題に対処するカスタマイズ機能が用意されています。このカスタマイズ機能を使用すると、ベースのアプリケーション定義の上に適用される、元の状態に干渉しないカスタマイズ・レイヤーを作成できます。カスタマイズ・レイヤー(またはレイヤー化された変更)は、独自のドキュメントに記述され、ベースのアプリケーション定義から隔離されて格納されます。実行時、適用可能なカスタマイズは、メタデータ・ストアからロードされ、ベースのメタデータ定義の上にレイヤー化され、目的の効果を実現します。製品のアップグレードおよびパッチは、ベースのメタデータ定義にのみ影響するため、カスタマイズは正しい動作を継続します。
カスタマイズ・レイヤー
MDSでは、クライアントは複数のカスタマイズ・タイプを指定できます。たとえば、カスタマイズを実行時モード、アプリケーション・ロール、ユーザー・ロール、アプリケーションの状態またはクライアント指定の条件に追加できます。このようなカスタマイズ・タイプそれぞれは、カスタマイズ・レイヤーと呼ばれ、CustomizationClassを使用して描写されます。CustomizationClassはインタフェースMDSで、ベース定義でオーバーレイされるカスタマイズ・レイヤーを特定するために使用されます。たとえば、アプリケーションを構成して、ユーザーが属している部門に基づいてカスタマイズを保存できます。DepartmentCCというカスタマイズ・レイヤーを作成でき、そこで異なる部門のユーザーによって行われたアプリケーションのカスタマイズは、レイヤー内の異なるフォルダに格納されます。その他の例は、MDSを構成して表示モードの変更をユーザー・カスタマイズとしてあるレイヤーで保存し、編集モードの変更をアプリケーション・カスタマイズとして別のレイヤーで保存する場合(またはこの逆)です。
カスタマイズ・レイヤーは、優先順位の順番で適用されます。つまり、同じ変更が、指定のユーザーおよびセッションに適用される2つの異なるレイヤーで行われた場合、高い優先順位のレイヤーで定義された変更がまず適用されます。
CustomizationClassを実装する場合、これをMDSで登録する必要があります。MDSには、CustomizationClassタイプのリストを単一のMetadataObjectと関連付ける方法が用意されています。これは、ファイングレイン関連付けと呼ばれます。MDSには、CustomizationClassタイプのリストを一連のMetadataObjectsと関連付ける方法も用意されています。これは粗密な関連付けと呼ばれます。CustomizationClassおよびカスタマイズ・レイヤーの作成の詳細は、第21.3項「カスタマイズ・レイヤーの表示モードおよび編集モードへの追加: 例」を参照してください。
コンポーザのサンドボックス
通常、Portal Frameworkアプリケーションでは、実行時のカスタマイズ内容はJDEV_HOME/jdev/system_directory/o.mds.dt/adrs/application_name/AutoGeneratedMar/mds_adrs_writedirディレクトリにすぐに保存されます。表示モードと編集モードの両方で行われた変更はこの方法で保存されます。ただし、特定の状況では、ユーザーは、変更をバック・エンドに実際に保存する前に、まず独自のビューでカスタマイズを適用してその変更を保持するか取り消すかを評価する必要がある場合があります。データベース・リポジトリを使用してカスタマイズを格納する場合、コンポーザを構成してサンドボックスを作成できます。サンドボックスの作成の詳細は、第21.2項「コンポーザのサンドボックスの使用」を参照してください。
サンドボックスは、実行時のページ・カスタマイズをバック・エンドにコミットするまで保存する一時ストレージ・レイヤーです。サンドボックスを構成すると、コンポーザのツールバーに「保存」ボタンが表示され、ユーザーは変更を保存できます。サンドボックス対応のアプリケーションでは、ユーザーがまず変更を保存せずに「閉じる」をクリックすると、「クローズの確認」ダイアログによって、コンポーザを閉じる前に変更を保存するか、取り消すかの確認を求められます。
表示モードで行われたユーザー・カスタマイズはすぐに保存されます。このような変更はページを変更したユーザーに対してのみ使用可能であるため、保存する前に変更を確認する特定の値はありません。
編集モードのカスタマイズはページにアクセスするすべてのユーザーが使用できるため、サンドボックスを有効にして、変更をコミットする前にユーザーがページ・カスタマイズを確認し、これを評価できます。アプリケーションでサンドボックスを有効にした場合、ページの編集モードでコンポーザのツールバーに「保存」ボタンが表示されます。
この項では、サンドボックスの作成を有効にする手順およびサンドボックス対応アプリケーションの実行時の動作を説明します。次のサブセクションが含まれます:
アプリケーションがデータベース・ストアを使用している場合のみサンドボックスを有効にできます。したがって、この項の手順を実行する前にデータベース・ストアが構成されていることを確認する必要があります。データベース・ストアの設定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』を参照してください。
この項では、コンポーザのサンドボックスの作成を有効にする方法を説明します。次のサブセクションが含まれます:
デフォルトでは、サンドボックスの作成は、(adf-config.xmlファイルの<mds-config>セクションで定義された)デフォルトのカスタマイズ・ストアにマップされたすべてのネームスペースに対して有効になっています。ただし、選択した数のネームスペースに対してのみサンドボックスを有効にできます。これを行うには、<pe:sandbox-namespaces>要素をadf-config.xmlファイルに追加してから、サンドボックスの作成をサポートするネームスペースを定義する必要があります。
adf-config.xmlでサンドボックスの作成を構成するには:
adf-config.xmlファイルを開きます。これは、「アプリケーション・リソース」パネルの「ディスクリプタ」の下のADF META-INFフォルダにあります。
例21-1に示すように、<metadata-namespaces>要素の下で、<namespace>要素が、サンドボックスの作成を有効にするすべてのメタデータに対して定義されていることを確認します。
例21-1 adf-config.xmlファイルのネームスペースの定義
<!-- Your jspx customizations alone go here -->
<namespace path="/pages" metadata-store-usage="WebCenterFileMetadataStore">
<namespace-restriction type="CUSTOMIZATIONS"/>
</namespace>
<!-- Your pagedef customizations alone go here -->
<namespace path="/pageDefs" metadata-store-usage="WebCenterFileMetadataStore">
<namespace-restriction type="CUSTOMIZATIONS"/>
</namespace>
例21-2に示すように、<pe:sandbox-namespaces>要素を<pe:page-editor-config>セクション内に追加し、サンドボックスの作成を有効にするすべてのネームスペースの個別の<pe:namespace>タグを追加します。
adf-config.xmlファイルを保存します。
ページの編集モードからサンドボックスが構成されたことを確認するには、アプリケーションのweb.xmlファイルでフィルタを作成し、適切なフィルタ・マッピングを設定する必要があります。すべてのリクエストがこのフィルタを通るようにルーティングされ、サンドボックスがすべての編集モードのカスタマイズに対して作成されます。ファイル・システムのメタデータ・ストアを使用している場合、フィルタされたリクエストに対して実行される処理はありません。
この項では、コンポーザ固有のフィルタおよびその関連フィルタ・マッピングをアプリケーションのweb.xmlファイルに定義する例を提供します。ここでは、フィルタ(WebCenterComposerFilter)を追加する方法を説明します。
コンポーザ固有のフィルタおよびフィルタ・マッピングを定義するには:
application_root/Portal/public_html/WEB-INF/web.xmlファイルを開きます。
WebCenterComposerFilterを追加してからadfBindingsフィルタを追加します。
<filter> <filter-name>composerFilter</filter-name> <filter-class>oracle.adf.view.page.editor.webapp.WebCenterComposerFilter</filter-class> </filter>
例21-3に示すように、AdfBindingFilterのフィルタ・マッピングの前に対応する<filter-mapping>要素を追加します。
例21-3 コンポーザ固有のフィルタのためのフィルタ・マッピング
<filter-mapping> <filter-name>composerFilter</filter-name> <servlet-name>Faces Servlet</servlet-name> <dispatcher>FORWARD</dispatcher> <dispatcher>REQUEST</dispatcher> </filter-mapping>
<url-pattern>タグを使用してWebCenterComposerFilterを通過する必要があるページを指定し、ページが編集モードになったときにサンドボックスの作成を有効化できるようにします。
|
注意: フィルタの定義順序が重要です。リクエストがこれらのフィルタで順番に渡されるので、適切な順序で定義されていないと、アプリケーションは設計されたように実行されません。 |
web.xmlファイルを保存します。
サンドボックスの作成を有効にするには、アプリケーションを構成しデータベース・ストアを使用する必要があります。したがって、アプリケーションをWebLogic管理対象サーバーにデプロイするときに、データベース・リポジトリを選択し、そのアプリケーションのパーティション名を指定します。
JDeveloperからWebLogic管理対象サーバーへのアプリケーションのデプロイの詳細は、第7.3.4.1項「ローカル・データ・ソースを使用した管理対象サーバーへのデプロイ」を参照してください。
アプリケーションでサンドボックスの作成を有効にするとき、ページ編集モードに入るときとそのモードを終了するときにフル・ページ・リフレッシュが実行されるようにする必要があります。その実行手順の詳細は第21.3.7項「サーブレットをリダイレクトしてMDSカスタマイズ・レイヤー間の切替えを有効にする方法」を参照してください。
ユーザーがページ編集モードに切り替えるとき、コンポーザのツールバーに「保存」ボタンが表示されるということは、サンドボックスの作成がアプリケーションで有効であることを示します。ページまたはページの共有コンポーネントに対して行われた変更は、ユーザーが「保存」をクリックするまで保存されません。保存されると、すべてのアプリケーション・ユーザーがこのカスタマイズを使用できます。「保存」ボタンがレンダリングされない場合、サンドボックスを使用できず、各変更はすぐにコミットされます。
「コンポーネント・プロパティ」ダイアログでコンポーネント・プロパティを編集するとき、「適用」をクリックすると次のようになります。
サンドボックスを使用できない場合、ページがリフレッシュされてコンポーネント・プロパティに対して行われた変更が表示され、変更はバック・エンドに保存されます。
サンドボックスを使用できる場合、ページがリフレッシュされてコンポーネント・プロパティに対して行われた変更が表示されます。変更を保存するには、ユーザーは「保存」をクリックする必要があります。
ページで「保存」または「閉じる」をクリックすると、次のイベントが実行されます。
「保存」をクリックすると、サンドボックスがコミットされ、新しいサンドボックスが作成されます。ページは編集モードのままです。
「閉じる」をクリックすると、次の2つのイベントのいずれかが発生します。
最後の保存操作以降の変更がない場合、サンドボックスが破棄され、コンポーザが閉じ、ユーザーは表示モードに戻ります。
保存されていない変更がある場合、図21-1に示すように、「クローズの確認」ダイアログにページ名と保存されていないタスク・フロー名がリストされます。
ユーザーは、次のオプションから選択できます。
「保存」をクリックして、サンドボックスをコミットし、コンポーザを閉じます。
「保存しない」をクリックして、サンドボックスを破棄し、コンポーザを閉じます。
「取消」をクリックし、ダイアログを閉じ、変更を保存せずにコンポーザに戻ります。
|
注意: ユーザーがページを編集中にページ外にナビゲートし、そのページに戻った場合、保存されていない変更は失われます。 |
並行編集時の処理
同じカスタマイズ・レイヤーを使用して2人以上のユーザーが同じページまたはタスク・フローを編集している場合、図21-2に示すように、ページに別のユーザーがページまたはタスク・フローを編集しているというメッセージがそれぞれのユーザーに表示されます。
複数のユーザーが同じカスタマイズ・レイヤーで同時にタスク・フローにズームインし、それを編集している場合、図21-3に示すように、並行処理メッセージが表示されます。
|
注意: ユーザーがタスク・フローにズームインし、いくつかのカスタマイズを行い、タスク・フローからズームアウトした場合、そのユーザーがカスタマイズを保存するまで、タスク・フローの並行処理メッセージが他のユーザーに対して継続して表示されます。 |
最後に保存された変更は前の変更を上書きします。たとえば、ユーザーAとBがページまたはタスク・フローを同時に編集している場合、並行性の問題は次のように処理されます。
Aが最初にページまたはタスク・フローを保存すると、Aの変更がMDSにコミットされます。その後、Bがページまたはタスク・フローを保存すると、Aの変更はBの変更で上書きされます。
Bが表示モードでコンポーネントをパーソナライズ(たとえば移動)しようとしている間にAがその同じコンポーネントを削除すると、WebCenterのエラー・ページがBに表示されます。Bは、元のページにナビゲートして戻る必要があります。削除されたコンポーネントは表示されず、Bは他のコンポーネントで作業を継続できます。
変更がすぐにバック・エンドにコミットされるようにするために、サンドボックスを無効にできます。
サンドボックスを無効にするには:
adf-config.xmlファイルを開きます。これは、「アプリケーション・リソース」パネルの「ディスクリプタ」の下のADF META-INFフォルダにあります。
<pe:page-editor-config>要素の下に<pe:disable-sandbox>属性を追加し、これをtrueに設定します。
adf-config.xmlを保存します。
ユーザーが実行時にページを編集するとき、ブラウザが予期せずに閉じた場合またはユーザーがページ外にナビゲートした場合、そのセッションで使用されていたサンドボックスは使用可能なままです。同じページにアクセスしている他のユーザーには、同じページを別のユーザーが編集しているという並行処理メッセージが表示されたままになります。このような失効したサンドボックスを破棄して、データベース・ストアの領域を解放し、パフォーマンスを向上できます。
失効したサンドボックスが次の場合に破棄されるようにできます。
セッションがタイムアウトした場合。
アプリケーションのweb.xmlファイルの<session-timeout>要素は、サンドボックスが破棄されるまでの期間を定義できます。これが確実に起こるようにするためには、アプリケーションのweb.xmlファイルでWebCenterComposerSessionListenerを構成する必要があります。このリスナーは、セッションがタイムアウトになるとコールされます。これは、同じユーザーがページ編集モードに入るときに新しいサンドボックスを作成します。
ユーザーがページの編集モードに同じユーザー名で再ログインした場合。
この場合、同じユーザーが編集モードに切り替えると、新しいサンドボックスが作成されます。
WebCenterComposerSessionListenerを構成するには:
application_root/Portal/public_html/WEB-INF/web.xmlファイルを開きます。
次の例に示すように、新しいリスナー(WebCenterComposerSessionListener)を定義します。
<listener>
<description>Composer Http Session Listener</description>
<display-name>Composer Http Session Listener</display-name>
<listener-class>
oracle.adf.view.page.editor.webapp.WebCenterComposerSessionListener
</listener-class>
</listener>
web.xmlファイルを保存します。
web.xmlで作成できるコンポーザ固有構成の詳細は、第B.2.4項「web.xmlの更新」を参照してください。
カスタマイズをクライアント定義の条件に基づいてメタデータ・オブジェクトに適用できます。たとえば、エンド・ユーザーの権限、アプリケーションのデプロイ場所(ローカライゼーションとも呼ばれる)または特定の産業分野に基づいて使用するアプリケーションおよびメタデータ・オブジェクトをカスタマイズできます。このような各カテゴリ(権限、ローカライゼーションおよび分野)は、カスタマイズ・レイヤーを指し、それぞれがCustomizationClassを使用して描写されます。CustomizationClassはインタフェースMDSで、ベース定義でオーバーレイされるカスタマイズ・レイヤーを特定するために使用されます。例については、第21.3.3項「カスタムUserCCヒント・レイヤーの作成方法」を参照してください。
CustomizationClassを実装する場合、これをMDSで登録する必要もあります。MDSには、CustomizationClassタイプのリストを単一のMetadataObjectと関連付ける機能が用意されています。これは、ファイングレイン関連付けと呼ばれます。MDSには、CustomizationClassタイプのリストを一連のMetadataObjectsと関連付ける機能も用意されています。これは粗密な関連付けと呼ばれます。
カスタマイズ可能アプリケーションは、複数のカスタマイズ・レイヤーを持つことができます。カスタマイズを適用するレイヤーを選択できます。カスタマイズ先として選択したレイヤーは、ヒント・レイヤーと呼ばれます。コンポーザ・コンポーネントをJSFページにドロップすると、ADFは、アプリケーションにデフォルトのSiteCC (site)ヒント・レイヤーを構成します。その結果、adf-config.xmlファイルが更新され、SiteCCカスタマイズ・クラスを組み込みます。このヒント・レイヤーは、ページに対して行われたすべてのカスタマイズを格納します。
この項では、例を使用して、カスタマイズ・ヒント・レイヤーを表示実行時モードおよび編集実行時モードに追加すると、ユーザーのカスタマイズ機能がすべてのユーザーにどのように提供され、アプリケーションのカスタマイズ機能が選択したユーザーにどのように提供されるかを説明します。アプリケーションのカスタマイズを編集モードで有効にするために、siteヒント・レイヤーが追加されます。ユーザーのカスタマイズを表示モードで有効にするために、userヒント・レイヤーが追加されます。デフォルトでは、userヒント・レイヤーはsiteヒント・レイヤーの上に適用されます。userヒント・レイヤーは、表示モードで行われたすべてのユーザーのカスタマイズ内容を、カスタマイズを行ったユーザー用に作成された特定の場所に格納します。このような変更はそのユーザーにしか表示されません。siteヒント・レイヤーは、編集モードで行われたすべてのアプリケーションのカスタマイズを格納し、すべてのユーザーに対して表示されます。
実行時にヒント・レイヤーを有効にするために、コンポーザはWebCenterComposerFilterフィルタを提供し、MDS SessionOptionsオブジェクトを作成するための抽象ファクトリを定義する方法を提供します。このオブジェクトでは、実行時に適用可能なカスタマイズ・レイヤーが提供され、ユーザーはロールに基づいてユーザーのカスタマイズ(表示モード)およびアプリケーションのカスタマイズ(編集モード)を実行できます。新しいMDSセッションを作成するとき、このオブジェクトのMDSSession.createSessionメソッドを使用して、セッションのオプションを指定します。
この項では、カスタマイズ・レイヤーを作成、実装および登録し、WebCenterComposerFilterを構成し、MDSカスタマイズ・レイヤー間で切り替える例を提供します。次のサブセクションが含まれます:
この項では、JSFページにPage Customizableコンポーネントを追加する方法を説明します。この演習の目的は、adminユーザーがサイト・レベルでカスタマイズを実行できるように、実行時に編集モードのコンポーザを提供することです。この項では、実行時に表示モードから編集モードへの切替えを可能にするために、Change Mode Linkを追加します。
JSFページにコンポーザを追加するには:
JSPXページを開き、「コンポーネント・パレット」から「コンポーザ」を選択します。
Change Mode Linkを選択し、これをページにドロップします。
Page Customizableを選択し、これをページにドロップします。
「ソース」ビューは次のようになります。
<af:form id="f1">
<pe:changeModeLink id="cml1"/>
<pe:pageCustomizable id="pageCustomizable1">
<cust:panelCustomizable id="panelCustomizable1" layout="scroll"/>
<f:facet name="editor">
<pe:pageEditor id="pep1"/>
</f:facet>
</pe:pageCustomizable>
</af:form>
これらのコンポーネントをページにドロップすると、デフォルトのSiteCCヒント・レイヤーがADFによって拡張されます。その結果、adf-config.xmlファイルがこのカスタマイズ・クラスで更新されます。
<cust-config>
<match>
<customization-class name="oracle.adf.share.config.SiteCC" />
</match>
</cust-config>
|
注意: アプリケーションで |
この項では、編集モードで実行されたすべてのアプリケーション・レベルのカスタマイズ内容が格納される、カスタムSiteCCヒント・レイヤー(site)を作成する方法を説明します。このサンプル・アプリケーションでは、アプリケーション・レベルのカスタマイズ内容は、/mds/mdssys/cust/site/webcenter/pagename.jspx.xmlディレクトリに格納されます。
siteヒント・レイヤーを作成するには:
「ファイル」メニューから、「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドにSiteCCと入力します。
「拡張対象」フィールドにCustomizationClassと入力します。
こうすることによってoracle.mds.cust.CustomizationClassがインポートされます。
「抽象メソッドの実装」チェック・ボックスが選択されていることを確認します。
「OK」をクリックします。
SiteCC.javaファイルは「ソース」ビューにレンダリングされます。
「ソース」ビューで、public class SiteCC extends CustomizationClassの後に[Enter]を押し、次の文字列を追加します。
{
private static final String DEFAULT_LAYER_NAME = "site";
private String mLayerName = DEFAULT_LAYER_NAME;
private String mLayerValue = "webcenter";
次のライブラリがインポートされます。
import oracle.mds.core.MetadataObject; import oracle.mds.core.RestrictedSession; import oracle.mds.cust.CacheHint;
ここで太字で示したようにコードを更新します。
public class SiteCC extends CustomizationClass
{
private static final String DEFAULT_LAYER_NAME = "site";
private String mLayerName = DEFAULT_LAYER_NAME;
private String mLayerValue = "webcenter";
//Note: You can provide any site name.
public CacheHint getCacheHint()
{
return CacheHint.ALL_USERS;
}
public String getName()
{
return mLayerName;
}
public String[] getValue(RestrictedSession mdsSession, MetadataObject mo)
{
return new String[] { mLayerValue };
}
}
SiteCC.javaファイルを保存します。
この項では、ユーザーscott用のカスタムuserヒント・レイヤーを作成する方法を示す例を説明します。このレイヤーはsiteレイヤーの上に適用されます。表示モードでユーザーが実行するユーザーのカスタマイズは、ログイン・ユーザー専用に作成されたフォルダのこのuserヒント・レイヤーに保存されます。この例では、表示モードで実行したユーザーのカスタマイズ内容は、/mds/mdssys/cust/user/scott/pagename.jspx.xmlディレクトリに格納されます。
|
注意: 説明上の目的のため、この例では、 |
userヒント・レイヤーを作成するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドにUserCCと入力します。
「拡張対象」フィールドにCustomizationClassと入力します。
こうすることによってoracle.mds.cust.CustomizationClassがインポートされます。
「抽象メソッドの実装」チェック・ボックスが選択されていることを確認します。
「OK」をクリックします。
「ソース」ビューにUserCC.javaファイルが表示されます。
「ソース」ビューで、public class UserCC extends CustomizationClassの後に[Enter]を押し、次の文字列を追加します。
{
private static final String DEFAULT_LAYER_NAME = "user";
private String mLayerName = DEFAULT_LAYER_NAME;
private String mLayerValue = "scott"; //The name of the logged-in user
in this example. The logged-in user name can be acquired dynamically.
次のライブラリがインポートされます。
import oracle.mds.core.MetadataObject; import oracle.mds.core.RestrictedSession; import oracle.mds.cust.CacheHint;
ここで太字で示したようにコードを更新します。
public class UserCC extends CustomizationClass
{
private static final String DEFAULT_LAYER_NAME = "user";
private String mLayerName = DEFAULT_LAYER_NAME;
private String mLayerValue = "scott";
public CacheHint getCacheHint()
{
return CacheHint.USER;
}
public String getName()
{
return mLayerName;
}
public String[] getValue(RestrictedSession mdsSession, MetadataObject mo)
{
return new String[]{mLayerValue};
}
}
UserCC.javaファイルを保存します。
この項では、ADFが提供するComposerSessionOptionsFactoryクラスが実装され、MDS SessionOptionsを各HTTPリクエストに提供します。
ComposerSessionOptionsFactoryクラスを実装するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドにAppsSessionOptionsFactoryImplと入力します。
「OK」をクリックします。
AppsSessionOptionsFactoryImpl.javaファイルが「ソース」ビューにレンダリングされます。
次のライブラリをインポートします。
import oracle.adf.view.page.editor.mds.ComposerSessionOptionsFactory; import oracle.adf.view.page.editor.mode.ModeContext; import oracle.mds.config.CustClassListMapping; import oracle.mds.config.CustConfig; import oracle.mds.core.SessionOptions; import oracle.mds.cust.CustClassList; import oracle.mds.cust.CustomizationClass;
次のコードを追加してComposerSessionOptionsFactoryクラスを実装し、SessionOptionsを渡します。
public class AppsSessionOptionsFactoryImpl
implements ComposerSessionOptionsFactory
{
public SessionOptions createSessionOptions(SessionOptions defaultSessionOptions, String mode)
{
CustomizationClass[] custLayer;
CustConfig custConfig = null;
if (ModeContext.EDIT_MODE.equals(mode))
{
//Mode is Edit, change to SiteCC
custLayer = EDIT_LAYER;
}
else
{
//Mode is View, change to UserCC + SiteCC
custLayer = VIEW_LAYER;
}
try
{
CustClassList custClassList = new CustClassList(custLayer);
CustClassListMapping custClassListMapping =
new CustClassListMapping("/", null, null, custClassList);
custConfig = new CustConfig(new CustClassListMapping[]
{ custClassListMapping });
}
catch (Exception e)
{
e.printStackTrace();
}
if(defaultSessionOptions.getServletContextAsObject() != null){
return new SessionOptions(defaultSessionOptions.getIsolationLevel(),
defaultSessionOptions.getLocale(), custConfig,
defaultSessionOptions.getVersionContext(),
defaultSessionOptions.getVersionCreatorName(),
defaultSessionOptions.getCustomizationPolicy(),
defaultSessionOptions.getServletContextAsObject());
}
else
{
return new SessionOptions(defaultSessionOptions.getIsolationLevel(),
defaultSessionOptions.getLocale(), custConfig,
defaultSessionOptions.getVersionContext(),
defaultSessionOptions.getVersionCreatorName(),
defaultSessionOptions.getCustomizationPolicy());
}
}
//Edit mode SiteCC
private static final CustomizationClass[] EDIT_LAYER =
new CustomizationClass[]
{ new SiteCC() };
//View mode SiteCC + USerCC
private static final CustomizationClass[] VIEW_LAYER =
new CustomizationClass[]
{ new SiteCC(), new UserCC() };
}
AppsSessionOptionsFactoryImpl.javaファイルを保存します。
siteカスタマイズ・レイヤーおよびuserカスタマイズ・レイヤーを機能させるには、コンポーザにComposerSessionOptionsFactoryクラスを登録する必要があります。たとえば、具体的なクラスがview.AppsSessionOptionsFactoryImplの場合、次のスニペットをアプリケーション・ディレクトリの/.adf/META-INFフォルダにあるadf-config.xmlファイルに追加する必要があります。
<pe:page-editor-config xmlns="http://xmlns.oracle.com/adf/pageeditor/config"> <pe:session-options-factory>view.AppsSessionOptionsFactoryImpl</pe:session-options-factory> </pe:page-editor-config>
アプリケーション・ディレクトリのPortal/public_html/WEB-INFフォルダにあるweb.xmlファイルのWebCenterComposerFilterフィルタを構成する必要があります。このフィルタは、すべてのHTTPリクエストについてコンポーザの具体的なSessionOptionsFactoryをADFに登録します。フィルタがADFからコールを受信すると、リクエストをアプリケーションに転送し、新しくカスタマイズされたレイヤーでSessionOptionsを取得します。SessionOptionsでSandboxまたはVersionContextを設定していない場合、コンポーザはその独自のサンドボックスを設定し、それをADFに返します。サンドボックスの詳細は、第21.2.1項「コンポーザのサンドボックスの作成を有効にする方法」を参照してください。
composerFilterとそのフィルタ・マッピングは、ADFBindingFilterより前に構成する必要があります。たとえば、次のweb.xmlファイルを参照してください。
....
<!-- WebCenterComposerFilter goes here -->
<filter>
<filter-name>composerFilter</filter-name>
<filter-class>oracle.adf.view.page.editor.webapp.WebCenterComposerFilter</filter-class>
</filter>
<filter>
<filter-name>adfBindings</filter-name>
<filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
</filter>
.....
<!-- WebCenterComposerFilter mapping goes here -->
<filter-mapping>
<filter-name>composerFilter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>adfBindings</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
....
|
注意: フィルタの定義順序が重要です。リクエストがこれらのフィルタで順番に渡されるので、適切な順序で定義されていないと、アプリケーションは設計されたように実行されません。 |
web.xmlで作成できるコンポーザ固有構成の詳細は、第B.2.4項「web.xmlの更新」を参照してください。
サーブレットをリダイレクトする、つまり実行時にフル・ページをリフレッシュするには、次のものを作成する必要があります。
AppNavigationUtils.redirectToSamePage()メソッドをコールするAppNavigationUtilsクラス
AppNavigationUtilsクラスを使用するAppCloseHandler CloseListener
編集モードを表示するAppModeBean
この項では、これらのオブジェクトの作成方法を説明します。次のサブセクションが含まれます:
AppNavigationUtilsクラスを作成するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドに、AppNavigationUtilsと入力し、「OK」をクリックします。
AppNavigationUtils.javaファイルは「ソース」ビューにレンダリングされます。
次のライブラリをインポートします。
import javax.faces.context.FacesContext; import javax.servlet.http.HttpServletRequest;
次のコードを追加します。
public class AppNavigationUtils
{
public static void redirectToSamePage()
{
HttpServletRequest request =
(HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();
String url = request.getRequestURL().toString();
String _adfCtrlState = request.getParameter("_adf.ctrl-state");
url = url + "?_adf.ctrl-state="+ _adfCtrlState;
System.out.println(url);
try
{
FacesContext.getCurrentInstance().getExternalContext().redirect(url);
FacesContext.getCurrentInstance().responseComplete();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
AppNavigationUtils.javaファイルを保存します。
AppCloseHandlerを作成するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドに、AppCloseHandlerと入力し、「OK」をクリックします。
「ソース」ビューにAppCloseHandler.javaファイルが表示されます。
次のライブラリをインポートします。
import oracle.adf.view.page.editor.event.CloseEvent; import oracle.adf.view.page.editor.event.CloseListener;
次のコードを追加します。
public class AppCloseHandler
implements CloseListener
{
public void processClose(CloseEvent closeEvent)
{
AppNavigationUtils.redirectToSamePage();
}
}
AppCloseHandler.javaファイルを保存します。
AppCloseHandlerを作成した後、これをコンポーザ拡張ファイルpe_ext.xmlに登録する必要があります。
このイベント・ハンドラを登録するには:
pe_ext.xmlファイルで、次のエントリを追加します。
<event-handlers> <event-handler event="close">view.AppCloseHandler</event-handler> </event-handlers>
ファイルを保存します。
イベント・ハンドラの詳細は、第19.6項「コンポーザUIイベントのイベント・ハンドラの構成」を参照してください。
AppModeBeanを作成するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドに、AppModeBeanと入力し、「OK」をクリックします。
「ソース」ビューにAppModeBean.javaファイルが表示されます。
次のライブラリをインポートします。
import javax.faces.event.ActionEvent;import oracle.adf.view.page.editor.mode.ModeContext;
次のコードを追加します。
public class AppModeBean
{
public void edit(ActionEvent actionEvent)
{
ModeContext.getCurrent().setEditMode();
AppNavigationUtils.redirectToSamePage();
}
}
ファイルを保存します。
siteカスタマイズ・レイヤーの機能を確認するには、まずブラウザでJSFページを実行します。次に、ページにadminとしてログインし、「編集」リンクをクリックして編集モードに切り替えます。実行時、ページをカスタマイズします。たとえば、Webページ、移動可能ボックスまたはイメージをページにドロップします。ページは図21-4のようになります。
アプリケーション・ディレクトリの/mds/mdssys/cust/site/webcenterに移動し、pagename.jspx.xmlファイルを開きます。これは、ページに対して実行したアプリケーション・レベルのカスタマイズが格納される場所です。
userカスタマイズ・レイヤーを使用するには、ページにscottとしてログインし、表示モードでページをパーソナライズします。次にアプリケーション・ディレクトリの/mds/mdssys/cust/user/scottに移動し、pagename.jspx.xmlファイルを開きます。これは、ページに対して実行したユーザーレベルのカスタマイズが格納される場所です。
この項では、コンポーザの使用中に発生する可能性のあるMDS関連の問題のトラブルシューティングに役立つ情報を提供します。
ロギングの構成の詳細は、「コンポーザのADFロギングの構成」を参照してください。
問題
アプリケーションはMDSサンドボックスを使用するように構成されています。アプリケーションを実行すると、サンドボックスは動作せず、また例外も生成しません。
解決方法
次の点を確認してください。
データベース・リポジトリが使用されています。サンドボックスは、データベース・ベースのリポジトリでのみ動作し、ファイルベースのリポジトリでは動作しません。
web.xmlのフィルタの順序が正確です。サンドボックスが正しく動作するためには、<filter>エントリが正しい順序である必要があります。
詳細は、第21.2項「コンポーザのサンドボックスの使用」を参照してください。
