| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章では、顧客がOracle Metadata Services (MDS)フレームワークに基づいてカスタマイズおよびデプロイできるADFアプリケーションを開発する方法について説明します。これらのアプリケーションにカスタマイズを実装する方法についても説明します。
この章の内容は次のとおりです。
カスタマイズしたアプリケーションのデプロイ方法の詳細は、36.4項「アプリケーションのデプロイ」を参照してください。
MDSのカスタマイズ機能を使用して、次のカスタマイズ・パターンのアプリケーションを作成できます。
シード・カスタマイズ
アプリケーションのシード・カスタマイズとは、汎用化されたアプリケーションを特定のグループ(特定の産業やサイトなど)のニーズにあわせて変更するプロセスです。シード・カスタマイズはデプロイされたアプリケーションの一部として存在し、特定のデプロイ期間中保持されます。この章では、カスタマイズ可能なアプリケーションを作成し、JDeveloperを使用してそのアプリケーションをカスタマイズする方法について説明します。
ユーザー・カスタマイズ(変更永続性)
ユーザー・カスタマイズでは、エンド・ユーザーは実行時に個々の設定(表にどの列を表示するかなど)にあわせてアプリケーションの内容を変更できます。変更内容は、次回そのアプリケーションを開くときに記憶されます。ユーザー・カスタマイズの詳細は、第35章「実行時のユーザー・カスタマイズの許可」を参照してください。
実行時のデザインタイム
Oracle WebCenter Portalの機能を使用して、実行時にカスタマイズ可能なアプリケーションを作成できます。これにより、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。ランタイム・カスタマイズの詳細は、Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイドを参照してください。
MDSアーキテクチャとメタデータ・リポジトリ(データベースおよびファイル・ベース)、およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middleware管理者ガイド』のMDSリポジトリの管理に関する項を参照してください。
カスタマイズしたアプリケーションは、ベース・アプリケーションとカスタマイズを含む1つ以上のレイヤーで構成されます。MDSは、カスタマイズをメタデータ・リポジトリに格納し、実行時にこのカスタマイズを取得してベース・メタデータにマージし、カスタマイズ済アプリケーションを公開します。カスタマイズはベースとは別個に保存されるため、アップグレードの際にカスタマイズが保護されます。つまり、新しいパッチをベースに適用する場合でも、カスタマイズに影響を与えずに行えるということです。カスタマイズ済アプリケーションが起動されると、カスタマイズの内容がベース・アプリケーションに適用されます。
たとえば、給与フィールドを4000に制限する検証規則を持つ、一般的な給与アプリケーションがあるとします。次に、給与フィールドを3300に制限する、この検証規則のカスタマイズを作成します。実行時に、ベース・アプリケーションにカスタマイズが適用され、給与フィールドの検証規則によりフィールドは3300に制限されます。
カスタマイズ可能なアプリケーションには、複数のカスタマイズ・レイヤーを設定できます。カスタマイズ・レイヤーには、industryやsiteなどがあります。各レイヤーには複数のカスタマイズ・レイヤー値を設定できますが、通常、実行時には、各レイヤーからこのようなレイヤー値が1つだけ適用されます。たとえば、カスタマイズ可能なアプリケーションのindustryレイヤーには、healthcareやfinancialなどの業種の値を格納できます。一方、デプロイ対象のカスタマイズ済アプリケーションで一度に使用されるのは、このレイヤー値のいずれか1つのみです。
複数のカスタマイズ・レイヤーからのレイヤー値を、指定の優先順位に従ってベース・メタデータの最上位に適用できます。たとえば、カスタマイズされたアプリケーションでは、industryレイヤーのfinancialレイヤー値とsiteレイヤーのFinancial Company #1レイヤー値にカスタマイズを含めることができます。各カスタマイズ・レイヤーは、基礎となるメタデータを変更する一連の指示を含んだカスタマイズ・ドキュメントに対応します。
カスタマイズしたアプリケーションのカスタマイズ・コンテキストは、適用された一連のカスタマイズ・レイヤー値により定義されます。
図34-1に、カスタマイズしたアプリケーションにレイヤーを適用する方法を示します。
これをサポートするために、JDeveloperを使用してカスタマイズ・クラスを作成し、レイヤーと値を定義して、優先順位を指定します。これらの手順については、34.2項「カスタマイズ可能なアプリケーションの開発」を参照してください。
カスタマイズは、静的なものと動的なものに分類できます。動的なカスタマイズでは、アプリケーションの実行コンテキストによって変化する値を指定できるのに対し、静的なカスタマイズでは、アプリケーションのすべての実行で有効な1つのレイヤー値のみを指定できます。アプリケーションを実行する様々なユーザーによってカスタマイズが変化する可能性がある場合、それは動的なカスタマイズです。アプリケーションを実行するすべてのユーザーでカスタマイズの値が同じである場合、それは静的なカスタマイズです。
ADFビジネス・コンポーネント・オブジェクトにカスタマイズを実装する場合、カスタマイズはアプリケーションの実行時全体にわたって変化しません。これらのオブジェクトはアプリケーションに対して1回だけロードされ、アプリケーションの継続中再利用されるためです。たとえば、サイト・レイヤーのHealthcare Company #1値で、そのサイトの給与フィールドを3300に制限するカスタマイズされた検証規則を持つことができます。これは静的なカスタマイズ・コンテンツです。
ただし、ユーザー・ロール(職責)または他のアプリケーション固有の条件に基づいて実行時にレイヤー値を決定できるカスタマイズを、コントローラ・レベルまたはビュー・レベルで実装することもできます。たとえば、組織が異なるユーザーには画面上で異なるフィールドを表示するように、アプリケーションを設計できます。これは動的なカスタマイズ・コンテンツです。
カスタマイズが静的か動的かの判断は、カスタマイズ・クラスで行われます。カスタマイズ・クラスで、getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、34.2.2項「カスタマイズ・クラスについて」を参照してください。
カスタマイズ・クラスの実装方法によっては、すべてのオブジェクトが静的なカスタマイズ・レイヤーを持つことができます。ただし、ADFビジネス・コンポーネント・オブジェクトの場合、静的なカスタマイズしか使用できません。
カスタマイズ可能なアプリケーションを作成するには、ベース・アプリケーションを作成して次の手順を実行します。
カスタマイズ用にアプリケーションを準備するには:
34.2.1項「カスタマイズ・クラスの作成方法」の説明に従って、使用するカスタマイズ・クラスを作成します。
34.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。
34.2.7項「adf-config.xmlの構成方法」の説明に従って、adf-config.xmlファイルでカスタマイズ・クラスを指定します。
オプションで、34.4.1項「拡張メタデータ・プロパティの編集方法」の説明に従って、アプリケーションでランタイム・カスタマイズを制限できます。
カスタマイズ用にアプリケーションを準備した後、34.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、JDeveloperを使用してカスタマイズを実装できるようにJDeveloperを準備する必要があります。
カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。各カスタマイズ・クラスでカスタマイズ・レイヤー(industryやsiteなど)を定義して、複数のレイヤー値を含めることができます。アプリケーションで使用するカスタマイズ・クラスは、アプリケーションのカスタマイズ時にJDeveloperで使用できる必要があります。また、デプロイされたアプリケーションに含める必要があります。
カスタマイズ・クラスでは、現在のコンテキストが評価されてStringの結果が戻されます。このStringの結果を使用してカスタマイズ・レイヤーが検索されます。
カスタマイズ・クラスによって、次の情報が提供されます。
レイヤー名を表す名前。
カスタマイズ・レイヤー値を表す値の配列通常、各レイヤーで値が1つ戻されます。複数の値が戻される場合、MDSリポジトリでこれらの値に使用可能なカスタマイズが、配列に表示された順序で適用されます。詳細は、34.2.1.2項「カスタマイズ・クラスでのgetValue()メソッドの実装」を参照してください。
レイヤーで作成されたオブジェクトのIDPrefix。カスタマイズ・レイヤーで新しいオブジェクトを作成する場合、一意のIDが必要です。オブジェクトの自動生成IDにIDPrefixが追加されて、新たに追加されたオブジェクトのIDが作成されます。異なるカスタマイズ・レイヤーで作成されたオブジェクトに一意のIDを指定するために、各レイヤーに一意のIDPrefixを指定する必要があります。
カスタマイズ・クラスによって定義されたレイヤーのキャッシュ・ヒント。キャッシュ・ヒントは、レイヤーが静的か動的かを定義します。getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。動的なカスタマイズの詳細は、34.1.2項「静的および動的なカスタマイズ・コンテンツ」を参照してください。CacheHint値の詳細は、34.2.2項「カスタマイズ・クラスについて」を参照してください。
カスタマイズを使用して、特定の業種ドメインにあわせてアプリケーションを調整できます(垂直統合)。このようなドメインはそれぞれカスタマイズ・レイヤーを表しており、カスタマイズ・クラスを使用して示されます。
カスタマイズ・クラスを使用してシード・カスタマイズを実装するには:
adf-config.xmlのcust-configセクション(mds-configの下)に、カスタマイズ・クラスへの参照を含める必要があります(例34-6を参照)。
カスタマイズ構成(cust-config)セクションでは、カスタマイズしたアプリケーションのカスタマイズ・クラスと優先順位が指定されます。34.2.7項「adf-config.xmlファイルの構成方法」を参照してください。
シード・カスタマイズをサポートするには、JDeveloperのクラス・パスでカスタマイズ・クラスを使用できる必要があります。
カスタマイズ・クラスの作成後、JDeveloperのクラス・パスに含める拡張ライブラリを作成できます。(詳細は、34.2.3.1項「JDeveloperでカスタマイズ・クラスを使用可能にする」を参照してください。)実行時に、EARレベルのアプリケーション・クラス・ローダーでカスタマイズ・クラスを使用できる必要があります。
レイヤー値が、CustomizationLayerValues.xmlファイルにリストされている必要があります。
このファイルは、jdev_install\jdevディレクトリにあります。このファイルのレイヤーの名前は、カスタマイズ・クラスと一致する必要があります。(詳細は、34.3.4項「カスタマイズ・レイヤーの構成方法」を参照してください。)JDeveloperは、このファイルを使用してデザインタイムにレイヤー値を取得します。
「カスタマイズ開発者」ロールでJDeveloperが起動されると、「カスタマイズ・コンテキスト」ウィンドウに使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを適用するレイヤーと値を選択します。「カスタマイズ開発者」ロールでの作業の詳細は、34.3.1項「「カスタマイズ開発者」ロールの概要」を参照してください。カスタマイズするために選択するレイヤーは、ヒント・レイヤーと呼ばれます。詳細は、34.3.3項「ヒント・レイヤーの概要」を参照してください。
例34-1に、カスタマイズ・クラスのサンプルを示します。すべてのカスタマイズ・クラスは、単一の引数なしのコンストラクタを持っている必要があります。
例34-1 mycompanyパッケージ内のIndustryCCカスタマイズ・クラスのサンプル
package mycompany;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import oracle.mds.core.MetadataObject;
import oracle.mds.core.RestrictedSession;
import oracle.mds.cust.CacheHint;
import oracle.mds.cust.CustomizationClass;
public class IndustryCC extends CustomizationClass {
private static final String DEFAULT_LAYER_NAME = "industry";
private String mLayerName = DEFAULT_LAYER_NAME;
public IndustryCC() {
}
public CacheHint getCacheHint() {
return CacheHint.ALL_USERS;
}
public String getName() {
return mLayerName;
}
public String generateIDPrefix(RestrictedSession sess, MetadataObject mo) {
return new String ("I");
}
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
// This needs to return the appropriate value at runtime.
return new String[] {"financial"};
}
}
この例では、カスタマイズ・クラスの動作を定義する4つのメソッドgetCacheHint()、getName()、generateIDPrefix()およびgetValue()を示しています。
getCacheHint()の戻り値は、このカスタマイズによりメタデータ・オブジェクトの可視性が広がり、その結果メモリー内での存続期間が長くなることを、MDSに示します。また、レイヤーが静的か動的かも定義します。この例では、getCacheHint()メソッドはALL_USERSを戻すため、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、34.2.2項「カスタマイズ・クラスについて」を参照してください。
getName()メソッドは、カスタマイズ・レイヤーの名前を戻します。たとえば、SiteCCカスタマイズ・クラスはsiteを戻します。この例では、getName()メソッドはindustryを戻します。
generateIDPrefix()メソッドは、IDPrefixを作成します。IDPrefixはレイヤーの名前と値を識別する、一意の省略形の文字列です。カスタマイズ・レイヤーで作成されたオブジェクトのIDの接頭辞として使用されます。デフォルト実装では(IDPrefixが指定されていない場合)、カスタマイズ値と連結されたレイヤー名が戻されます。パフォーマンス上の理由により、IDPrefixは短くする必要があります(4文字以下)。このため、デフォルト実装をオーバーライドする必要があります。関連するgetIDPrefix()メソッドは、カスタマイズ・レイヤーのIDPrefixを戻します。この例では、getIDPrefix()メソッドはI (industryの場合)を戻します。
getValue()メソッドは、カスタマイズ・クラスのカスタマイズ値(複数可)を戻します。この例では、getValue()メソッドは単一値financialを戻し、レイヤー名と組合せてカスタマイズ・コンテキストを定義します。34.2.1.2項「カスタマイズ・クラスでのgetValue()メソッドの実装」で、getValue()メソッドを使用するその他の手法について説明します。
|
注意: レイヤー名に対応する有効なレイヤー値は、JDeveloperによって |
getValue()メソッドを使用して、アプリケーションのコンテキストとメタデータに基づいて、カスタマイズ・クラスのレイヤー値が取得されます。たとえば、SiteCCカスタマイズ・クラスでgetValue()を呼び出すと、単一エントリheadquartersを持つ配列が戻されます。一般に、getValue()メソッドは単一値を持つ配列を戻します(例34-1を参照)。
getValue()メソッドから複数の値を戻すこともできます(例34-2を参照)。
例34-2 複数の値を戻すgetValue()メソッド
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
return new String[]{"North America", "US", "CA"}
}
複数の値が戻される場合、すべての値に適用できるカスタマイズが適用されます。カスタマイズは、配列に表示された順序で適用されます。この例では、North Americaカスタマイズがベース・アプリケーションに適用され、次にUSカスタマイズが適用され、最後にCAが適用されます。
|
注意: カスタマイズ・レイヤーに複数の値を戻すことは高度な概念で、通常は必要とされません。 |
getValue()メソッドは、現行ユーザーの現在の実行コンテキストに基づいてレイヤー値を戻すことができます。この値は、クライアントが保持する静的またはスレッド・ローカル状態から、またはMDSセッションでメタデータ・オブジェクト名に基づいてクライアントによって設定されたプロパティから取得されます。例34-3は、このタイプの実装を示しています。
例34-3 現在の実行コンテキストに基づいてレイヤー値を戻すgetValue()メソッド
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
if (mo.getName().equals("/sample/abc.jspx"))
{
return new String[]{"Headquarters"};
}
else
{
return new String[]{"RemoteSite"};
}
}
この例では、getValue()メソッドはメタデータ・オブジェクトでgetName()メソッドを使用して、メタデータ・ドキュメントの名前が/sample/abc.jspxかどうかを判断します。この名前である場合、getValue()はHeadquartersを戻して、headquartersカスタマイズを適用します。この名前でない場合、RemoteSiteを戻して、リモート・サイトのカスタマイズを適用します。
|
注意:
|
開発サイクル中に有効なその他の手法として、外部プロパティ・ファイルを使用してレイヤー値を指定する手法があります。例34-4は、レイヤー値を格納するプロパティ・ファイル(customization.properties)を参照しています。
例34-4 プロパティ・ファイルを使用してレイヤー値を指定するgetValue()メソッド
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
Properties properties = new Properties();
String configuredValue = null;
Class clazz = IndustryCC.class;
InputStream is = clazz.getResourceAsStream("/customization.properties");
if (is != null){
try {
properties.load(is);
String propValue = properties.getProperty(mLayerName);
if (propValue != null){
configuredValue = propValue;
}
} catch (IOException e) {
e.printStackTrace();
}
finally {
try {
is.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
return new String[] {configuredValue};
}
この手法を使用するアプリケーションがJDeveloperで実行されている場合、プロパティ・ファイルでレイヤー値を変更し、ブラウザをリフレッシュして、適用される新しいカスタマイズを確認できます。このカスタマイズ・クラスとプロパティ・ファイルの組合せによって、レイヤー値を別のファイルに保持できるため、特定のデプロイメントのためにJavaコードを修正およびリコンパイルしてレイヤー値を変更する必要はありません。customization.propertiesファイルを使用する場合は、同じクラス・ローダーからロードされるように、カスタマイズ・クラスとともにパッケージ化する必要があります。
例34-5に、customization.propertiesファイルのサンプルを示します。このプロパティ・ファイルでIndustryCCクラスがロードされる場合、レイヤー値healthcareが適用されます。
カスタマイズ・クラスを作成したら、別個の拡張機能プロジェクトに配置します。これにより、カスタマイズ・クラスをJARにデプロイして、JARを最下位レベルのプロジェクト(一般に、モデル・プロジェクト)にインポートできます。このアプローチによってモジュール性が高まり、社内の複数のアプリケーションに容易に組み込み、一元的にパッチを適用できるようになります。このアプローチの詳細は、34.2.3項「カスタマイズ・クラスの使用方法」を参照してください。
または、単一アプリケーションでのみ使用するカスタマイズ・クラスを作成する場合は、カスタマイズ・クラスをモデル・プロジェクトに配置できます。
アプリケーションにカスタマイズ・クラスのコピーが1つしかないこと、およびEARレベルのアプリケーション・クラス・ローダーからロードできるようにJARにパッケージ化されていること、を確認してください。デフォルトでは、プロジェクトの依存性を追加すると、カスタマイズ・クラスがWARに追加されます。これは、アプリケーションをパッケージ化してデプロイした後は正しく機能しません。デプロイ用にアプリケーションをパッケージ化する方法については、36.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
カスタマイズ・クラスを作成するには、次の手順を使用します。
拡張機能プロジェクトでカスタマイズ・クラスを作成するには:
デフォルト・ロールを使用してJDeveloperを起動し、カスタマイズ・クラスを保持するアプリケーションを開きます(または作成します)。
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」で「プロジェクト」、「拡張機能プロジェクト」を選択して「OK」をクリックします。
「拡張機能プロジェクトの作成」ダイアログが開きます。このダイアログのオプションの詳細は、オンライン・ヘルプを参照してください。
|
注意: 「拡張機能プロジェクト」が表示されない場合は、「すべてのテクノロジ」タブをクリックします。 |
拡張機能プロジェクトの適切な設定を指定して、「OK」をクリックします。
|
注意: すべてのカスタマイズ・クラスを保持するには、単一の拡張機能プロジェクトを使用する必要があります。 |
アプリケーション・ナビゲータで拡張機能プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」をクリックしてから「ライブラリの追加」をクリックします。
「ライブラリの追加」ダイアログでMDSランタイムを選択し、「OK」をクリックします。
アプリケーション・ナビゲータで、拡張機能プロジェクトを右クリックして「新規」を選択します。
「新規ギャラリ」で「一般」を展開し、「Java」、「Javaクラス」を選択して「OK」をクリックします。
「Javaクラスの作成」ダイアログで、クラスの名前と適切なパッケージを入力します。
|
注意: カスタマイズ・クラスには一般に、戻すレイヤー名が付けられます。たとえば、レイヤー名 |
「拡張」フィールドにoracle.mds.cust.CustomizationClassと入力します。
「抽象メソッドの実装」が選択されていることを確認して、「OK」をクリックします。
生成されたファイルで、コードを例34-1に示すようなコードで置き換えます。
変更内容を保存してプロジェクトを再ビルドします。
これでカスタマイズ・クラスが作成されます。サンプル・コードではパッケージ名mycompanyとクラス名IndustryCCが使用されています。これらを、アプリケーションにあわせて変更する必要があります。
34.2.1.1項「カスタマイズ・クラス」で説明したように、カスタマイズ・クラスではカスタマイズ・レイヤーでのメタデータ・オブジェクトの可視性、およびその結果としてのメモリー内での存続期間を指定するCacheHintが定義されます。MDSはこの情報を使用して、カスタマイズをキャッシュするかどうか、およびどこにキャッシュするかを決定します。特定のカスタマイズ・クラスを使用して構築されたカスタマイズ・レイヤーは、同じキャッシュ・ヒントを持ちます。
次の定数は、CacheHintでサポートされる値です。
ALL_USERS -- カスタマイズは特定のデプロイメントでグローバルに適用されます(条件付きではない)。この定数は、静的なカスタマイズ・レイヤーで使用されます。
MULTI_USER -- カスタマイズは複数のユーザーに適用されます。
REQUEST -- カスタマイズは、リクエスト期間にのみ適用されます。
USER -- カスタマイズは単一ユーザーに対して、ユーザーのアプリケーション・セッション中にアクセスされるドキュメントに適用されます。(Webアプリケーションでは、アプリケーション・セッションは通常サーブレット・セッションです。)
|
注意: カスタマイズ・クラスは頻繁に実行できるため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。 |
カスタマイズ・クラスを作成後、これらをデザインタイムに「カスタマイズ開発者」ロールで、および実行時にアプリケーションで使用することができます。アプリケーションまたはJDeveloperで使用するには、クラスを適切にパッケージ化する必要があります。
アプリケーションのデプロイメント・プロファイルを定義する際、カスタマイズ・クラスJARをEARアセンブリに追加する必要があります。また、重複を避けるために、WARにカスタマイズ・クラスJARが含まれないようにする必要があります。詳細は、36.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
カスタマイズ・クラスの作成後、JDeveloperでカスタマイズ・クラスを使用可能にして、カスタマイズの実装時に使用できるようにする必要があります。「カスタマイズ開発者」ロールで作業する場合、JDeveloperのクラス・パスでカスタマイズ・クラスを使用できる必要があります。
カスタマイズ・クラスは再利用可能コンポーネントであるため、JDeveloperの拡張機能を作成してこれにカスタマイズ・クラスを含めて、JDeveloperで使用できるようにすることができます。JDeveloperの拡張機能の作成および使用については、JDeveloperオンライン・ヘルプのJDeveloperの拡張機能の記述に関する項を参照してください。
ただし、カスタマイズしたアプリケーションをパッケージ化してデプロイする際、またはJDeveloperから実行する際、アプリケーションのクラス・パスで、アプリケーション・レベルでカスタマイズ・クラスを使用できる必要があります。このため、JDeveloperの拡張機能としてだけではなく、使用するアプリケーションにも(たとえば、モデル・プロジェクトに)カスタマイズ・クラスを含めることが重要です。カスタマイズ・クラスを実行時に使用可能にする方法の詳細は、34.2.3.2項「拡張機能プロジェクトからのカスタマイズ・クラスの使用」を参照してください。
カスタマイズ・クラスをJDeveloperの拡張機能としてパッケージ化するには:
34.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、拡張機能プロジェクトでカスタマイズ・クラスを作成します。
アプリケーション・ナビゲータで拡張機能プロジェクトを右クリックして、Rebuild project.jprを選択します。
アプリケーション・ナビゲータで拡張機能プロジェクトを右クリックして、「ターゲット・プラットフォームへのデプロイ」を選択します。
これにより、カスタマイズ・クラスがJDeveloperにデプロイされ、「カスタマイズ開発者」ロールで使用できるようになります。
カスタマイズしたアプリケーションをパッケージ化してデプロイする際、またはJDeveloperから実行する際、EARレベルのアプリケーション・クラス・ローダーでカスタマイズ・クラスを使用できる必要があります。
|
注意: 使用するアプリケーションのモデル・プロジェクトでカスタマイズ・クラスを作成した場合、この手順は不要です。 |
作業を始める前に、次のようにします。
カスタマイズ・クラスを含むアプリケーションをデフォルト・ロールを使用してJDeveloperで開き、36.3.2.1項「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
次の手順を使用してアプリケーションでカスタマイズ・クラスを表示できるようにしてから、34.2.7項「adf-config.xmlの構成方法」の説明に従って、カスタマイズ・クラスをadf-config.xmlファイルのcust-configセクションに追加します。これで、JDeveloperからローカルに実行するときに、アプリケーションでカスタマイズ・クラスを使用できるようになります。
拡張機能プロジェクトからカスタマイズ・クラスを使用するには:
JDeveloperのデフォルトのロールで、カスタマイズするアプリケーションを開きます。
アプリケーション・ナビゲータでモデル・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」をクリックします。
「JAR/ディレクトリの追加」をクリックします。
「アーカイブまたはディレクトリの追加」ダイアログで、カスタマイズ・クラスを含む作成済のJARを選択して、「選択」をクリックします。
「OK」をクリックして、「プロジェクト・プロパティ」ダイアログを終了します。
JDeveloperでプロジェクトをローカルに実行している場合に、カスタマイズ・クラスを使用できるようになります。ただし、アプリケーションをリモートにデプロイしている場合は、36.3.2.4項「アプリケーションレベルのEARデプロイメント・プロファイルの作成」の説明に従って、カスタマイズ・クラスJARをEARクラス・パスに追加する必要もあります。
すべてのカスタマイズ可能なコンポーネントと同様に、カスタマイズ可能なメタデータ・オブジェクトのXML要素はMDSによって一意に識別できる必要があるため、NULL以外の一意の識別子を指定する必要があります。このコンポーネントの識別子を使用して、カスタマイズ・レイヤー内のカスタマイズ指示の要素を参照します。IDプロパティは、ADF Faces .jspxまたは.jsffファイルの各タイプのコンポーネントの識別子です。
JSFページとJSPページでカスタマイズを可能にするには、ページの一部のデフォルト設定を受け入れずに、アプリケーションのビュー・プロジェクトでシード・カスタマイズを有効にする必要があります。これは、モデル・プロジェクトとコントローラ・プロジェクトでは不要です。
|
注意: MDSでは、カスタマイズするにはこれらのページがXMLベースである必要があります。このため、 |
ビュー・プロジェクトでシード・カスタマイズを有効にするには:
デフォルト・ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開きます。
アプリケーション・ナビゲータでビュー・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ADFビュー」をクリックします。
図34-2に示すように、「シード・カスタマイズの有効化」チェック・ボックスを選択します。
「OK」をクリックします。
プロジェクトの変更を保存します。
プロジェクトに前のバージョンのJDeveloperで作成されたページがある場合、これらの既存のページでもシード・カスタマイズを有効にする必要があります。これは、アプリケーションを前のバージョンのJDeveloperから移行して、移行中にIDを生成していない場合にのみ必要です。
既存のページでシード・カスタマイズを有効にするには:
デフォルト・ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開きます。
監査プロファイルを作成して、ページのすべてのXMLオブジェクトにIDトークンを実装します。
「ツール」メニューで「設定」を選択します。
「設定」ダイアログで、「監査」→「プロファイル」を選択します。
「プロファイル」ページの「ルール」タブで、すべてのルールを選択解除します。
ルール「ADF Faces」→「コンポーネントIDルール」→「ADF Facesが存在する場合、IDをチェックします」を選択します。
「デフォルト修正」ドロップダウン・リストで、「一意のIDの生成」を選択します。
「名前を付けて保存」をクリックし、プロファイルに識別可能な名前(「一意のIDの生成」など)を入力して「保存」をクリックします。
「OK」をクリックして「プリファレンス」ダイアログを閉じます。
アプリケーション・ナビゲータで、シード・カスタマイズを有効にするページを選択します。プロジェクトを選択して、そのプロジェクトに含まれるすべてのファイルに対して監査を実行することもできます。
「ビルド」メニューから、「監査」→「ファイル名」を選択します。
「監査」ダイアログで、作成したプロファイルを選択してIDを生成し、「実行」をクリックします。
ログ・ウィンドウを使用して問題を確認し、修正を適用します。
監査が完了したら、変更内容を保存します。
カスタマイズの実装時に新しいリソース・キーを作成する予定がある場合、「アプリケーション・プロパティ」ダイアログを使用して影響を受けるリソース・バンドルを指定できます。
リソース・バンドルでカスタマイズを有効にするには:
アプリケーションのコンテキスト・メニューから「アプリケーション・プロパティ」を選択します。
「アプリケーション・プロパティ」ダイアログで、「リソース・バンドル」をクリックします。
「追加」をクリックします。
「リソース・バンドルの選択」ダイアログで、カスタマイズを有効化するリソース・バンドルを探して選択します。
「開く」をクリックします。
「アプリケーション・プロパティ」ダイアログで、「バンドル」表の「オーバーライド済」列のチェックボックスを選択します。
「OK」をクリックします。
アプリケーションのadf-config.xmlファイルでは、mds-configセクションで適切なcust-config要素が指定されている必要があります。クライアントはcust-config要素を使用して、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを定義できます。adf-config.xmlファイルの概要エディタを使用して、カスタマイズ・クラスを追加します(図34-3を参照)。
adf-config.xmlファイルでカスタマイズ・クラスを識別するには:
カスタマイズするアプリケーションをJDeveloperで開き、アプリケーション・ナビゲータで「アプリケーション・リソース」パネルを開きます。
「ディスクリプタ」および「ADF META-INF」を展開します。
adf-config.xmlを右クリックして、「開く」を選択します。
概要エディタで「MDS構成」ナビゲーション・タブをクリックして、「追加」アイコンをクリックします。
「カスタマイズ・クラスの編集」ダイアログで、作成済のカスタマイズ・クラスを検索するか、作成済のカスタマイズ・クラスに移動します。
適切なクラスを選択して、「OK」をクリックします。
カスタマイズ・クラスをすべて追加した後、矢印アイコンを使用して適切な順序で配置できます。
図34-3は、2つのカスタマイズ・クラスが追加されたadf-config.xmlファイルの概要エディタを示しています。
customization-class要素の順序により、カスタマイズ・レイヤーの優先順位が指定されます。たとえば、例34-6に示すコードでは、IndustryCCクラスはSiteCCクラスの前に表示されています。これは、industryレイヤーでのカスタマイズがベース・アプリケーションに適用されてから、siteレイヤーでのカスタマイズが適用されることを示します。
例34-6 adf-config.xmlファイルでのカスタマイズ・クラスの順序
<adf-config xmlns="http://xmlns.oracle.com/adf/config">
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<cust-config>
<match path="/">
<customization-class name="com.mycompany.IndustryCC"/>
<customization-class name="com.mycompany.SiteCC"/>
</match>
</cust-config>
</mds-config>
</adf-mds-config>
</adf-config>
カスタマイズ可能アプリケーションを作成する際、カスタマイズしたアプリケーションの基礎として使用するために必要な部分を含むベース・アプリケーションがあります。
カスタマイズを実行するには、34.3項「アプリケーションのカスタマイズ」の説明に従って、「カスタマイズ開発者」ロールを使用してJDeveloperでアプリケーションを開く必要があります。
Oracle ADFコンポーネント(コントローラ、モデルおよびビジネス・コンポーネント・オブジェクトなど)をカスタマイズするには、これらに一意の識別子を指定する必要があります。ビュー・コントローラ・プロジェクトのJSPページとJSFページを除き、JDeveloperによって生成されるADFコンポーネントは、デフォルトでは識別子とともに作成されます。JDeveloperにビュー・コントローラ・プロジェクトのページ上のコンポーネントの識別子を生成させるには、プロジェクト・レベルで明示的に指定する必要があります(34.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」を参照)。
アプリケーションでカスタマイズを実装する前に、カスタマイズするすべてのオブジェクトに必要な識別子が指定されていることを確認します。多くの場合、監査ルールを実行し、欠落を把握して修正することができます(34.2.5項「既存のページでシード・カスタマイズを有効化する方法」を参照)。
また、カスタマイズ・クラスは頻繁に実行できるため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。
「カスタマイズ開発者」ロールを使用して、カスタマイズ可能アプリケーションでカスタマイズを作成できます。
「カスタマイズ開発者」ロールを使用して、プロジェクトのメタデータをカスタマイズします。カスタマイズ機能は、このロールでのみ使用できます。「カスタマイズ開発者」ロールでは、次の作業を実行できます。
カスタマイズの作成および更新
カスタマイズしたアプリケーションのヒント・レイヤーの選択および編集
既存のカスタマイズの削除
「カスタマイズ開発者」ロールで作業する場合、ソース・エディタは読取り専用になり、次のJDeveloperの機能が無効になります。
ワークスペースの移行
アプリケーションおよびIDE接続の作成、削除および変更「カスタマイズ開発者」ロールでアプリケーションを開く前に、デフォルト・ロールで接続を構成する必要があります。
「カスタマイズ開発者」ロールでアプリケーションを使用する場合、新規オブジェクトは作成できず、カスタマイズ不能オブジェクトは変更できません。ただし、次のコンテンツ・タイプはカスタマイズ可能です。
WebCenterポータル・モジュール
ADFモジュール(ADF Faces、ADFモデル、ADFビジネス・コンポーネント、ADFコントローラなど)
|
注意: ADFビジネス・コンポーネント・オブジェクトは、「カスタマイズ・コンテキスト」ウィンドウで静的カスタマイズ・クラスが選択されている場合のみカスタマイズ可能です。それ以外の場合、ビジネス・コンポーネント・オブジェクトは読取り専用です。 |
「カスタマイズ開発者」ロールで作業する場合、Javaクラス、リソース・バンドル、セキュリティ・ポリシー、デプロイメント・ディスクリプタ、構成ファイルなどのカスタマイズ不能ファイルは編集できません。「カスタマイズ開発者」ロールで作業している際、カスタマイズ不能ファイルはロック・アイコンで示されます。
プロジェクト設定の変更や、サービス・インタフェースやビジネス・イベント定義など特定のADFビジネス・コンポーネント機能のカスタマイズも制限されます。また、カスタマイズ不能ファイルの変更が必要になる場合は、カスタマイズ可能ファイルをリファクタまたは変更できません。
「カスタマイズ開発者」ロールでは、JDeveloperのカスタマイズ機能を使用できます。このロールで作業するには、JDeveloperの起動時に選択するか、JDeveloperがすでに実行されている場合は「設定」ダイアログで「カスタマイズ開発者」ロールに切り替えます。
JDeveloperで「カスタマイズ開発者」ロールに切り替えるには:
「ツール」メニューで「設定」を選択します。
「設定」ダイアログで、「ロール」ノードをクリックします。
「設定」ダイアログの「ロール」ページに、使用可能な様々なロールが表示されます。
「カスタマイズ開発者」を選択して「OK」をクリックします。
「カスタマイズ開発者」ロールで作業する際、「カスタマイズ・コンテキスト」ウィンドウで選択したレイヤーとレイヤー値の組合せをヒント・レイヤーと呼びます。このレイヤーには、「カスタマイズ開発者」ロールで作業中に行った変更が適用されます。
JDeveloperのエディタに表示されるメタデータは、ベース・メタデータと(adf-config.xmlで設定された優先順位に従った)ヒント・レイヤーまでのカスタマイズ・レイヤーを組み合せたもので、各レイヤーの値は「カスタマイズ・コンテキスト」ウィンドウで指定したものです。
「カスタマイズ開発者」ロールでの作業時には、アプリケーションのカスタマイズされていない状態も確認できます。「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」が選択されている場合、現在使用しているヒント・レイヤーはありません。したがって、表示されているのはカスタマイズされていない状態です。このビューでは、(アプリケーション・ナビゲータの)カスタマイズ可能ファイルすべてにロック・アイコンが表示され、これらのファイルが読取り専用であることが示されます。
ヒント・レイヤーでカスタマイズを行うと、プロパティ・インスペクタでこれらのカスタマイズはオレンジのアイコンで示されます。緑のアイコンは、ヒント以外のレイヤーのカスタマイズを示します。プロパティの横にオレンジのアイコンが表示されている場合、そのプロパティのドロップダウン・メニューから「カスタマイズ・アクションの削除」を選択して、そのカスタマイズを削除できます。
アプリケーションをカスタマイズするには、JDeveloperで認識できるように、CustomizationLayerValues.xmlファイルでカスタマイズ・レイヤーとその値を指定する必要があります。
カスタマイズ・レイヤーはJDeveloper用にグローバルに、またはアプリケーション固有ファイルで定義できます。アプリケーション固有ファイルを使用する場合、このファイルはグローバル・ファイルより優先されます。JDeveloper用にグローバルにレイヤー値を構成する方法の詳細は、34.3.4.1項「レイヤー値をグローバルに構成」を参照してください。アプリケーション固有のレイヤー値を構成する方法の詳細は、34.3.4.2項「adf-configエディタでのワークスペースレベルのレイヤー値の構成」を参照してください。
カスタマイズ可能なアプリケーションを「カスタマイズ開発者」ロールで開くと、JDeveloperによりadf-config.xmlファイルが読み取られ、使用するカスタマイズ・クラスと優先順位が判別されます。また、CustomizationLayerValues.xmlファイルも読み取られ、「カスタマイズ・コンテキスト」ウィンドウで使用可能にするレイヤー値が判別されます。adf-config.xmlファイルにリストされたカスタマイズ・クラスで定義されていないレイヤーがCustomizationLayerValues.xmlファイルに含まれる場合、これらのレイヤーは「カスタマイズ・コンテキスト」ウィンドウには表示されません。
したがって、JDeveloper用にグローバルにカスタマイズ・レイヤーを指定する際は、CustomizationLayerValues.xmlファイルにすべてのカスタマイズ・アプリケーションの包括的なレイヤー値リストを含めて、現在のアプリケーションに適したもののみを「カスタマイズ・コンテキスト」ウィンドウに表示できます。逆に、アプリケーションの包括的なカスタマイズ・クラスのリストをadf-config.xmlファイルに含めて、作業するレイヤー値のサブセットのみをCustomizationLayerValues.xmlファイルに含めることもできます。
|
注意: デザインタイムには、JDeveloperは |
CustomizationLayerValues.xmlファイルに入力するレイヤー名は、カスタマイズ・クラスで指定されたレイヤー名と一致する必要があります。例34-7 CustomizationLayerValues.xmlで定義されたレイヤーとレイヤー値に、サンプルのCustomizationLayerValues.xmlファイルの内容を示します。
例34-7 CustomizationLayerValues.xmlで定義されたレイヤーとレイヤー値
<cust-layers xmlns="http://xmlns.oracle.com/mds/dt">
<cust-layer name="industry" id-prefix="i">
<cust-layer-value value="financial" display-name="Financial" id-prefix="f"/>
<cust-layer-value value="healthcare" display-name="Healthcare" id-prefix="h"/>
</cust-layer>
<cust-layer name="site" id-prefix="s">
<cust-layer-value value="headquarters" display-name="HQ" id-prefix="hq"/>
<cust-layer-value value="remoteoffices" display-name="Remote" id-prefix="rm"/>
</cust-layer>
</cust-layers>
各レイヤーとレイヤー値に、id-prefixトークンを追加できます。これにより、idの一意性を確保し、カスタマイズを正確に適用できます。カスタマイズ中に新規要素(コマンド・ボタンなど)をページに追加すると、(選択したヒント・レイヤーで決定された)レイヤーとレイヤー値のid-prefixが要素の自動生成識別子に追加され、カスタマイズ・メタデータ・ファイルで新たに追加された要素のidが作成されます。たとえば、例34-7では、siteレイヤーにsというid-prefixが付けられ、headquartersレイヤー値にhqというid-prefixが付けられています。したがって、ヒント・レイヤーとしてsite/headquartersを選択して、コマンド・ボタンをページに追加すると、メタデータ・カスタマイズ・ファイルでコマンド・ボタンにshqcb1というidが設定されます。
各レイヤー値にdisplay-nameトークンを追加して、レイヤー値に人間が判読可能な名前を指定することもできます。「カスタマイズ開発者」ロールで作業する際、そのレイヤー値のdisplay-nameトークンの値が「カスタマイズ・コンテキスト」ウィンドウに表示されます。
JDeveloper用にCustomizationLayerValues.xmlファイルをグローバルに構成する手順は、次のとおりです。
JDeveloper用にデザインタイム・カスタマイズ・レイヤー値をグローバルに構成するには:
CustomizationLayerValues.xmlファイルを探して開きます。
このファイルは、JDeveloperインストール・ディレクトリのjdevサブディレクトリにあります(jdev_install\jdev\CustomizationLayerValues.xml)。
各レイヤーに、例34-7のようにcust-layer要素を入力します。
各レイヤー値に、例34-7のようにcust-layer-value要素を入力します。
CustomizationLayerValues.xmlファイルを保存して閉じます。
カスタマイズ・クラスJAR(34.2.3.1項「JDeveloperでカスタマイズ・クラスを使用可能にする」で作成された)がJDeveloperクラス・パスで使用できることを確認します。
グローバルなCustomizationLayerValues.xmlファイルに変更を加えた後は、JDeveloperを再起動する必要があります。
アプリケーションのレイヤー値を構成する場合、adf-configエディタ(デフォルト・ロールまたは「カスタマイズ開発者」ロールで)または「カスタマイズ・コンテキスト」ウィンドウ(「カスタマイズ開発者」ロールで)のどちらかを使用できます。「カスタマイズ・コンテキスト」ウィンドウでこの作業を行う方法については、34.3.4.3項「「カスタマイズ・コンテキスト」ウィンドウでのワークスペースレベルのレイヤー値の構成」を参照してください。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」セクションのMDS DTフォルダでアクセスできます。
次に、adf-configエディタで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。
adf-configエディタからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
アプリケーション・ナビゲータで、adf-config.xmlファイルをダブルクリックします。
adf-config.xmlファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードのADF META-INFにあります。
概要エディタで、「MDS構成」タブをクリックします。
カスタマイズ・クラスの表の下で、「デザインタイム・カスタマイズ・レイヤー値の構成」リンクをクリックして、ワークスペースレベルのCustomizationLayerValues.xmlファイルを開きます。
リンクをクリックすると、JDeveloperによってエディタにファイルが開きます。ワークスペースレベルのCustomizationLayerValues.xmlがまだない場合、JDeveloperにより確認ダイアログが表示されます。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。
34.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。
変更を保存します。
グローバルなCustomizationLayerValues.xmlファイルとは異なり、ワークスペースレベルのCustomizationLayerValues.xmlファイルのレイヤー値は「カスタマイズ開発者」ロールで変更できます。また、変更内容を保存すると、JDeveloperを再起動しなくても、「カスタマイズ・コンテキスト」ウィンドウに変更された値が反映されます。ファイルを変更する前にアクティブだったカスタマイズ・コンテキストが、変更されたカスタマイズ・レイヤー値によって無効になる場合、そのカスタマイズ・コンテキストは選択解除されます。更新されたカスタマイズ・レイヤー値から、カスタマイズ・コンテキストを選択する必要があります。
アプリケーションのレイヤー値を構成する場合、「カスタマイズ・コンテキスト」ウィンドウ(「カスタマイズ開発者」ロールで)またはadf-configエディタ(デフォルト・ロールまたは「カスタマイズ開発者」ロールで)のどちらかを使用できます。adf-configエディタでこの作業を行う方法については、34.3.4.2項「adf-configエディタでのワークスペースレベルのレイヤー値の構成」を参照してください。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」セクションのMDS DTフォルダでアクセスできます。
次に、「カスタマイズ開発者」ロールで「カスタマイズ・コンテキスト」ウィンドウから特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。
「カスタマイズ・コンテキスト」ウィンドウからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
「カスタマイズ」ウィンドウで、「グローバル・レイヤー値のオーバーライド」リンクをクリックします。
リンクをクリックすると、JDeveloperにより概要エディタでCustomizationLayerValues.xmlファイルが開きます。ワークスペースレベルのCustomizationLayerValues.xmlがまだない場合、JDeveloperにより確認ダイアログが表示されます。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。
34.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。
変更を保存します。
グローバルなCustomizationLayerValues.xmlファイルとは異なり、ワークスペースレベルのCustomizationLayerValues.xmlファイルのレイヤー値は「カスタマイズ開発者」ロールで変更できます。また、変更内容を保存すると、JDeveloperを再起動しなくても、「カスタマイズ・コンテキスト」ウィンドウに変更された値が反映されます。ファイルを変更する前にアクティブだったカスタマイズ・コンテキストが、変更されたカスタマイズ・レイヤー値によって無効になる場合、そのカスタマイズ・コンテキストは選択解除されます。更新されたカスタマイズ・レイヤー値から、カスタマイズ・コンテキストを選択する必要があります。
ベース・アプリケーションの開発時と同じ開発手順および開発手法を使用して、メタデータをカスタマイズします。ただし、カスタマイズを実装するには、メタデータを編集する前に、「カスタマイズ開発者」ロールを使用し、ヒント・レイヤーとレイヤー値を選択してカスタマイズ・コンテキストを指定する必要があります。カスタマイズ可能にできるアプリケーションに対して、プロジェクトでカスタマイズを有効にする必要があります。詳細は、34.2項「カスタマイズ可能なアプリケーションの開発」を参照してください。
JDeveloperでメタデータをカスタマイズするには:
「カスタマイズ開発者」ロールを使用してJDeveloperを起動します。
カスタマイズ可能なアプリケーションを開きます。
「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを実装するレイヤーと値を選択します。
図34-4に示すように、(「カスタマイズ・コンテキスト」ウィンドウの下部にある)「カスタマイズ・コンテキスト」が選択内容を反映して変更されます。
|
注意: 「カスタマイズ・コンテキスト」ウィンドウで選択された内容は、JDeveloperに実装するカスタマイズのコンテキストを示します。この選択内容が、アプリケーションの実行時に直接影響を及ぼすことはありません。実行時には、カスタマイズ・クラスからカスタマイズ・コンテキストが戻されます。詳細は、34.2.1項「カスタマイズ・クラスの作成方法」を参照してください。 |
開発時に通常行うように、メタデータを編集します。たとえば、エンティティ・オブジェクトを右クリックして、「開く」を選択します。その後、概要エディタを使用してオブジェクトを編集します。
カスタマイズ時には、開発時と同じ方法でメタデータを編集しますが、一定の制約が適用されます。たとえば、ボタン・ラベルなど一部の文字列プロパティは、プロパティ・インスペクタで直接編集できません。「テキスト・リソースの選択」ダイアログまたは式ビルダーを使用して編集する必要があります。カスタマイズ時の編集に対する制限の詳細は、34.3.1項「「カスタマイズ開発者」ロールの概要」を参照してください。式ビルダーの使用については、12.7.1.1項「プロパティ・インスペクタから式ビルダーを開く手順」を参照してください。
概要エディタを使用してカスタマイズを実装する場合でも、ベース・メタデータ・ファイルは変更しません。変更内容は、カスタマイズ・メタデータ・ファイルに別個に保存されます。
|
注意: カスタマイズされていないベース・メタデータを表示するには、「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」を選択します。 |
オプションで、(プロパティ・インスペクタで)プロパティのドロップダウン・メニューから「カスタマイズの削除」を選択して、既存のカスタマイズを消去できます。
|
注意: プロパティ・インスペクタでは、ヒント・レイヤーのカスタマイズはオレンジのアイコンで示され、ヒント以外のレイヤーの変更は緑のアイコンで示されます。カスタマイズの削除は、カスタマイズが追加されたコンテキストでのみ実行できます。したがって、削除できるのは、プロパティ・インスペクタでオレンジのインジケータが付いているカスタマイズのみになります。 |
「ファイル」メニューから、「保存」を選択して変更を保存します。
カスタマイズの完了後、カスタマイズしたアプリケーションを実行してテストできます。
ベース・メタデータ・ドキュメントがアップグレードされた場合、またはベース・ドキュメント・タイプ定義が変更された場合(後方互換性のため、タイプ定義の変更は避ける必要があります)、そのドキュメントのカスタマイズが無効になる可能性があります。
たとえば、XSDの要素にminOccurs=0、maxOccurs=1があり、ベース・ドキュメントには当初この要素の出現箇所がなかったとします。このため、この要素の出現箇所をカスタマイズとして挿入します。ベース・ドキュメントがアップグレードされ、同じ要素の出現箇所が追加されます。このような場合、カスタマイズを適用すると、要素の出現箇所が2箇所になり、XSDのmaxOccursルールに違反します。
こうした状況が発生した場合、「カスタマイズ開発者」ロールでドキュメントを開いたときに、構造ウィンドウでこのようなヒント・カスタマイズの問題が警告されます。JDeveloperでドキュメントを開いたときに、(スキーマ違反によるエラーなどの)エラーがある場合は構造ウィンドウに表示されます。エラーの状況によっては、監査修正アクションが提供されます。エラーをダブルクリックして、ドキュメント内の問題の原因に移動できます。構造ウィンドウでは、現在のヒント・レイヤーのカスタマイズで発生した違反エラーのみがレポートされます。ヒント・レイヤー以外のレイヤーに違反エラーがある場合、それらはレポートされません。
ヒント・レイヤーのカスタマイズ・エラーを修正するために、JDeveloperの「カスタマイズ開発者」ロールで、「すべてのヒント・カスタマイズ検証エラーの修正」というデフォルトの監査アクションが提供されます。このアクションでは、ヒント・レイヤーのカスタマイズを削除して、マージされたドキュメントでの検証違反を修正します。
アプリケーションでカスタマイズを実装する場合、JDeveloperによりカスタマイズ用のメタデータ・ファイルとこれらを格納するサブパッケージが作成されます。
メタデータ・ファイルにはカスタマイズしたオブジェクトのカスタマイズが含まれ、これらは実行時にベース・メタデータに適用されます。新しいメタデータ・ファイルには、オブジェクトのベース・ファイルと同じ名前が付けられ、拡張子.xmlが付加されます。たとえば、browseOrders.jsffページのカスタマイズを実装する場合、カスタマイズ・メタデータ・ファイルの名前はbrowseOrders.jsff.xmlになります。また、OrderItemsエンティティ・オブジェクトにカスタマイズを実装する場合は、ベース・メタデータ・ファイルの名前はOrderItems.xmlになり、カスタマイズ・メタデータ・ファイルの名前はOrderItems.xml.xmlになります。
カスタマイズ・メタデータ・ファイルは、カスタマイズするオブジェクトと同じレベルで作成されたサブパッケージ階層に格納されます。第1レベルのパッケージ名はmdssysで、custという名前のパッケージが含まれます。custパッケージには、カスタマイズを実装した各カスタマイズ・レイヤーのパッケージが含まれます。
たとえば、エンティティ・オブジェクトを含むoracle.fod.modelというパッケージを持つベース・アプリケーションがあり、headquartersとremoteofficesの2つのレイヤー値を持つsiteという名前のカスタマイズ・レイヤーがあるとします。その後、headquartersレイヤー値でOrderItemsエンティティ・オブジェクトにカスタマイズを実装します。これらのカスタマイズを実装する場合、JDeveloperによりサブパッケージ階層oracle.fod.model.mdssys.cust.site.headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。
同様に、ビュー・コントローラ・プロジェクトのページ用に、ディレクトリ構造が作成されてカスタマイズ・メタデータ・ファイルが格納されます。たとえば、ビュー・コントローラ・プロジェクトの「Webコンテンツ」フォルダのBrowseOrders.jsffページをカスタマイズする場合、JDeveloperにより「Webコンテンツ」の下にディレクトリ構造mdssys/cust/site/headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。
「カスタマイズ開発者」ロールでは、JDeveloperを使用してGroovyスクリプトを実装し、エンティティ・オブジェクトの次の事前定義トリガー・ポイントに対してレスポンスできます。
作成の後
変更の前
無効化の前
削除の前
データベースでの挿入の前
データベースでの挿入の後
データベースでの更新の前
データベースでの更新の後
データベースでの削除の前
データベースでの削除の後
データベースでのコミットの前
データベースでのコミットの後
データベースでのロールバックの前
データベースでのロールバックの後
これらのトリガー・ポイントは、エンティティ・オブジェクトの概要エディタの「ビジネス・ルール」タブで使用できます。
エンティティ・オブジェクトのトリガーを追加する手順:
アプリケーション・ナビゲータでエンティティ・オブジェクトを右クリックして、「開く」を選択します。
概要エディタで、「ビジネス・ルール」ナビゲーション・タブをクリックします。
「追加」アイコンをクリックして、「トリガー」を選択します。
「トリガーの追加」ダイアログで、使用するトリガー・ポイントを選択し、トリガー・ポイントに対するレスポンスとして実行する式を入力します。
「失敗処理」タブをクリックして、トリガーが失敗した場合に表示されるエラー・メッセージを入力または選択します。
「OK」をクリックします。
「カスタマイズ開発者」ロールでは、JDeveloperを使用してADFライブラリのアーティファクトをカスタマイズできます。これが必要になるのは、たとえば、ある開発チームがフレームワーク・サービスの一部としてタスク・フローを作成し、これを他のチームがADFライブラリとして使用できるようにする場合です。その後、他の開発チームがいずれかのタスク・フローを使用アプリケーションで使用して、アプリケーションの要件にあわせて調整する必要が生じます。
デフォルト・ロールで追加する場合と同じように、「カスタマイズ開発者」ロールでプロジェクトにADFライブラリを追加できます。ただし、「カスタマイズ開発者」ロールでは、ADFライブラリのコンテンツは編集可能でカスタマイズを実装できるのに対し、デフォルト・ロールでは読取り専用になります。ADFライブラリの使用の詳細は、第33章「アプリケーション・コンポーネントの再利用」を参照してください。
ADFライブラリ・アーティファクトをカスタマイズするには:
「カスタマイズ開発者」ロールで、カスタマイズ可能なアプリケーションを開きます。
アプリケーション・ナビゲータで、「ナビゲータの表示オプション」アイコンをクリックして「ライブラリの表示」を選択します。
これによりアプリケーション・ナビゲータにライブラリが表示されるので、いろいろ見てまわってアーティファクトにアクセスすることができます。
アプリケーション・ナビゲータのライブラリに希望するライブラリがない場合は、希望するライブラリをプロジェクトに追加します。
この手順の詳細は、33.3項「プロジェクトへのADFライブラリ・コンポーネントの追加」を参照してください。
プロジェクトの他のコンテンツをカスタマイズするのと同じように、アーティファクトをカスタマイズします。
たとえば、タスクフローのライブラリから使用プロジェクトの.jspxまたは.jsffページへのドラッグ・アンド・ドロップ、タスクフローのライブラリから他のライブラリのページまたはフラグメントへのドラッグ・アンド・ドロップ、ライブラリ・コンテンツまたはタスクフローのリソース・カタログからのドラッグ・アンド・ドロップ、データ・コントロールの「データ・コントロール」パネルからライブラリの.jspxまたは.jsffページへのドラッグ・アンド・ドロップ、ビジネス・コンポーネントの編集、データ・コントロールのライブラリから「データ・コントロール」パネルへのドラッグ・アンド・ドロップおよび他のパレットのページへのドロップなどを行うことができます。これらのアクションすべてが、ライブラリのカスタマイズになります。
ADFライブラリのカスタマイズが保存される場所は、デフォルトではproject-dir\libraryCustomizationsです。ワークスペースに複数のプロジェクトが含まれる場合、この場所を各プロジェクトのワークスペースレベルの場所に変更する必要があります(workspace-dir\.mds\ADFLibraryCustomizationsなど)。
ADFライブラリのカスタマイズの場所は、「プロジェクト・プロパティ」ダイアログの「プロジェクトのソースパス」→「ADFライブラリのカスタマイズ」ページで変更できます。ADFライブラリでカスタマイズを実装後にこの場所を変更する場合は、カスタマイズ・メタデータ・ファイルを新しい場所に移動する必要があります。そのためには、ファイル・システムを使用してカスタマイズ・メタデータ(XML)ファイルを古いディレクトリから新しいディレクトリに移動します。
ワークスペースに、共通の場所に移動する必要がある既存のADFライブラリのカスタマイズを持つプロジェクトが複数存在する場合は、一度に1つのプロジェクトずつカスタマイズを新しい場所に移動します。プロジェクトごとに、「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更してから、カスタマイズ・メタデータ・ファイルを古い場所から新しい場所に移動します。複数のプロジェクトでADFライブラリ・アーティファクトにカスタマイズがある場合の競合を緩和するために、次のオプションが用意されています。
両方のプロジェクトで、カスタマイズが競合しているADFライブラリ・アーティファクトを開き、どちらが必要なカスタマイズかを決定します。保持するカスタマイズを残して、もう一方は削除します。
両方のカスタマイズが重要である場合は、最初のプロジェクトでADFライブラリ・アーティファクトを開き、前に2つめのプロジェクトで行われたカスタマイズを実装します。その後、最初のプロジェクトでカスタマイズを保存して、2つめのプロジェクトからカスタマイズを削除します。
複数のプロジェクトのADFライブラリ・カスタマイズ・メタデータ・ファイルをテキスト・エディタで開いて、そのコンテンツをマージすることはできません。これを行うと、カスタマイズ・メタデータ・ファイルが破損する可能性があります。
また、MARデプロイメント・プロファイルを作成すると、ADFライブラリのカスタマイズが保存されている場所が自動的に含められます。また、MARプロファイルの作成後にこの場所を変更する場合は、パッケージ化する前に、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの「ユーザー・メタデータ」ファイル・グループ・ページにあるコントリビュータ・リストで、対応するエントリを変更する必要があります。または、MARプロファイルを再作成して、この変更を取得することも可能です。MARデプロイメント・プロファイルの作成の詳細は、36.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
JDeveloperの「カスタマイズ開発者」ロールで作業している場合、エクスポートしたJARに含まれるADFライブラリ・アーティファクトに実装されたランタイム・カスタマイズを表示できます。
ランタイム・カスタマイズをJDeveloperで表示できるようにするには:
「カスタマイズ開発者」ロールで、カスタマイズしたアプリケーションを開きます。
アプリケーション・ナビゲータのポップアップ・メニューから「アプリケーション・プロパティ」を選択します。
「アプリケーション・プロパティ」ダイアログで「カスタマイズ・ライブラリ」をクリックします。
「参照」をクリックして、エクスポートしたJARの場所に移動します。
JARファイルを選択して「選択」をクリックします。
「OK」をクリックして「アプリケーション・プロパティ」ダイアログを閉じます。
これで、JARが使用可能になり、JDeveloperはADFライブラリ・アーティファクトのカスタマイズを検索できます。ADFライブラリ・アーティファクトを含むオブジェクトを開くと、JDeveloperはこのJARでカスタマイズを検索し、必要に応じて表示します。JDeveloperは特定のカスタマイズ・コンテキストで特定のアーティファクトについて表示する内容を、次のように決定します。
アーティファクトにランタイム・カスタマイズまたはシード・カスタマイズが関連付けられていない場合、ADFライブラリのアーティファクトが表示されます。
アーティファクトにランタイム・カスタマイズまたはシード・カスタマイズのいずれかのみ(両方ではなく)が関連付けられている場合、カスタマイズされたアーティファクトが表示されます。
アーティファクトにランタイム・カスタマイズとシード・カスタマイズの両方が関連付けられている場合、シード・カスタマイズが優先されて表示されます。
また、アプリケーションをJDeveloperからローカルに実行する場合は、ランタイム・カスタマイズが表示されます。ただし、ランタイム・カスタマイズはアプリケーションのデプロイメント用のパッケージには含められません。
エンタープライズ・アプリケーションを開発する際、複数のアプリケーションで再利用可能なアーティファクト(タスク・フローなど)が存在することがあります。再利用しやすいように、これらの共通アーティファクトは通常、ADFライブラリにパッケージ化されて配布されます。これにより、使用アプリケーションが依存するライブラリ・リストにADFライブラリを追加できます。アプリケーションがパッケージ化されると、追加したすべてのADFライブラリのカスタマイズがMARに含められ、その後、MDSリポジトリにデプロイされます。
|
注意: ADFライブラリ・プロバイダは、ライブラリのカスタマイズを原因とする名前の競合がないことを確認する必要があります。ADFライブラリにパッケージ化されたカスタマイズと使用プロジェクトのカスタマイズとの間で名前の競合が発生した場合、ADFライブラリのカスタマイズは無視されます。 |
ADFライブラリのオブジェクトにカスタマイズを実装すると、デフォルトでは、カスタマイズ・メタデータはlibraryCustomizationsというプロジェクトのサブディレクトリに格納されます。また、プロジェクト・レベルでADFライブラリのカスタマイズを作成しても、これらは実行時にアプリケーションで使用できるように、パッケージ化される際に一緒にマージされます。基本的に、ADFライブラリはプロジェクト・レベルで追加されるJARであり、プロジェクト・レベルで作成されるライブラリ・カスタマイズにマップされます。ただし、プロジェクトは実行時にWebアプリケーションにマップされますが、MAR(ライブラリのカスタマイズを含む)はEARレベルにあるため、すべてのWebアプリケーションからライブラリのカスタマイズを確認できます。
したがって、ある特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーおよびレイヤー値)では、アプリケーションの1箇所でしかADFライブラリ・アーティファクトをカスタマイズできません。同一ライブラリ・コンテンツをカスタマイズ・コンテキストが同一の複数のプロジェクトでカスタマイズすると、MARパッケージで重複が発生します。パッケージ化の失敗の原因となる重複を回避するには、アプリケーションの1つのプロジェクトにのみ特定ライブラリのカスタマイズを実装します。
たとえば、使用中のADFライブラリにページ・フラグメントtext.jsffが含まれるとします。使用アプリケーションで、このライブラリ・ページを1つのプロジェクトでのみカスタマイズします。これにより、実行時にこのライブラリを使用するアプリケーションのすべてのプロジェクトで、カスタマイズが使用可能になります。
プロジェクトに同じ名前のオブジェクトがすでに含まれる場合、ADFライブラリのオブジェクトをカスタマイズすることも制限されます。重複する場合は、重複するドキュメントの1つを削除するか、削除してから差異をもう一方にマージして、プロジェクトを修正する必要があります。
同様に、ADFライブラリに特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーとレイヤー値)のアーティファクトのシード・カスタマイズが含まれる場合、同じカスタマイズ・コンテキストでそのアーティファクトにカスタマイズを実装することはできません。この場合、ADFライブラリ・アーティファクトは読取り専用になります。ただし、他のカスタマイズ・コンテキストでアーティファクトにカスタマイズを実装することはできます。
たとえば、使用中のADFライブラリに、SiteレイヤーのHeadquartersレイヤー値のシード・カスタマイズが含まれるとします。「カスタマイズ・コンテキスト」ウィンドウでこれをヒント・レイヤーとして選択すると、そのADFライブラリのカスタマイズ済オブジェクトは読取り専用になります。ただし、Site/Remote Site 1をヒント・レイヤーとして選択すると、オブジェクトはカスタマイズ可能になります。
|
注意: 使用アプリケーションでADFライブラリのコンテンツに対するカスタマイズが実装されると、カスタマイズはローカル・プロジェクトのディレクトリには書き込まれますが、パッケージ化する際に |
アプリケーションをカスタマイズしたら、そのアプリケーションをデプロイできます。カスタマイズしたアプリケーションをデプロイする前に、『Oracle Fusion Middleware管理者ガイド』の説明に従って、MDSリポジトリを設定する構成手順を実行する必要があります。
エンタープライズ・アプリケーションにはモデル・プロジェクトおよびユーザー・インタフェース・プロジェクトを含めることができ、どちらのタイプのプロジェクトにもカスタマイズしたメタデータを含めることができます。カスタマイズしたメタデータは、デプロイのためにMARにパッケージ化されます。デフォルトでは、どちらのタイプのプロジェクトのカスタマイズも1つのMARに追加されます。MARプロファイルの作成方法の詳細は、36.3.2.3項「MARデプロイメント・プロファイルの作成」を参照してください。
JDeveloperを使用してADFアプリケーションをパッケージ化する場合、次のいずれかの条件が満たされると、デフォルト・メタデータ(カスタマイズなど)を含む自動MARが作成されます。
ユーザー・インタフェース・プロジェクトの「プロジェクト・プロパティ」ダイアログの「ADFビュー設定」ページで、「ユーザー・カスタマイズの有効化」→「MDSを使用したセッション間チェック・ボックスが選択されている。
adf-config.xmlファイルのMDS構成セクションに、例34-8に示すようにdeploy-target="true"とマークされている<metadata-store-usage>要素が含まれる。
例34-8 adf-config.xmlのmetadata-store-usage要素
< . . . >
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/apps" metadata-store-usage="repos1"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="repos1" deploy-target="true">
. . .
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
< . . . >
JDeveloperで作成されたカスタマイズをデプロイ時にアプリケーションで有効にするには、これらのカスタマイズを実行時にアプリケーションで使用可能にする必要があります。そのために、2つの方法を使用できます。
MARを使用して、カスタマイズをアプリケーションとともにパッケージ化します。
カスタマイズ・メタデータを含むMARプロファイルを作成します。MARプロファイルをデプロイしたEARに含めて、実行時にカスタマイズを使用できるようにします。アプリケーションレベル・クラス・ローダーに配置されるように、カスタマイズ・クラスをEARファイルにパッケージ化する必要があります。
|
注意: シード・カスタマイズしかない場合は、ランタイム・カスタマイズもサポートする場合を除き、MARを作成してMDSリポジトリにインポートする必要はありません。シード・カスタマイズがあり、セッション間の永続性が有効でない場合、シード・カスタマイズはデフォルトでEARにパッケージ化され、クラス・パスからロードされます。 |
カスタマイズを、アプリケーションで使用されるランタイム・リポジトリにインポートします。
この方法は一般に、ライブラリ・メタデータへのカスタマイズを、別個にデプロイされたアプリケーションに適用する必要がある場合に使用します。この方法を使用してカスタマイズをJARにパッケージ化し、Oracle WebLogic Scripting Tool (WLST)とともにimportMetadataコマンドを使用してMDSランタイム・リポジトリにインポートします。これらのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
アプリケーションにADFライブラリのオブジェクトのカスタマイズがある場合、MARプロファイルの作成時にカスタマイズ・メタデータが暗黙的に含められます。「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更する場合は、パッケージ化する前に、MARプロファイルを再作成する必要があります。
実行時のデザインタイム機能を使用して、実行時にオーバーライド・バンドルでリソース・キーを追加または編集する予定がある場合は、オーバーライド・バンドルをMARの一部としてパッケージ化する必要があります。デフォルトでは、アプリケーションにシード・カスタマイズが含まれる場合、オーバーライド・バンドルは自動生成MARの一部としてパッケージ化されます。ただし、アプリケーションにシード・カスタマイズが含まれない場合は、MARデプロイメント・プロファイルを明示的に作成してオーバーライド・バンドルをパッケージ化する必要があります。MARプロファイルが明示的に作成される場合、オーバーライド・バンドルはデフォルトでユーザー・メタデータの一部として追加されて含められます。
完了したカスタマイズ済アプリケーションをパッケージ化してデプロイする場合、「カスタマイズ開発者」ロールではなくデフォルト・ロールで行う必要があります。MARプロファイルの作成方法の詳細は、36.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
実行時に、アプリケーションではadf-config.xmlファイルのcust-configセクションで定義された優先順位に従って、カスタマイズ・メタデータ・ファイルがベース・アプリケーション全体に適用されます。
レイヤー値は実行時にカスタマイズ・クラスから取得され、アプリケーションが実行されているコンテキストで評価されて、そのレイヤー値に適したカスタマイズが適用されます。
アプリケーションをカスタマイズする場合、統合ソース・コントロールを使用したり、リソース文字列をカスタマイズすることがあります。これらの機能を使用する場合に、知っておくべき追加情報があります。
「カスタマイズ開発者」ロールでの作業時には、ソース・コントロール統合によってカスタマイズ・プロセスが補完されます。自動的にチェックアウトして新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されている場合、ソース・コントロール・システムから使用可能なベース・ドキュメントをカスタマイズしようとすると、JDeveloperは次のように動作します。
該当するカスタマイズ・ファイルがまだ使用可能でない場合、ソース・コントロールで新しいカスタマイズ・ファイルが作成されてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在する場合、チェックアウトされてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在し、すでにチェックアウトされている場合、またはまだバージョン・コントロールにない場合、バージョン・コントロール操作なしでカスタマイズが書き込まれます。
ベース・ドキュメントは「カスタマイズ開発者」ロールでは変更されないため、ベース・ドキュメントはチェックアウトされません。
自動的にチェックアウトしたり新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されていない場合、手動でカスタマイズ・ファイルを編集可能にして、新たに作成したカスタマイズ・ファイルをソース・コントロールにチェックインする必要があります。JDeveloperでのソース・コントロールの使用の詳細は、1.4.2項「ソース・コントロール・システムの使用」を参照してください。
アプリケーションをカスタマイズする過程で、コンテンツをカスタマイズして、別のリソース・バンドル・キーを使用したり、新しいリソース・キーを定義して使用できます。
「カスタマイズ開発者」ロールでカスタマイズ可能なアプリケーションを開き、プロパティ・インスペクタを使用してリソース・バンドル文字列の使用方法をカスタマイズできます。ドキュメントを変更して、リソース・バンドルにすでに存在する別のリソース・キーを使用したり、新しいリソースを作成できます。リソース・バンドルの詳細は、4.7項「リソース・バンドルの使用」を参照してください。
新しいリソース・キー(「カスタマイズ開発者」ロールで作成された)は、アプリケーションレベルのオーバーライド・バンドルに(XLIFF形式で)保存され、JDeveloperにより例34-9に示すようなエントリがadf-config.xmlファイルに追加されて、アプリケーションレベルのオーバーライド・バンドルが構成されます。
また、ベース・リソース・バンドルのオーバーライドをサポートするように、adf-config.xmlファイルを構成する必要があります。例34-9に示すように、bundleId要素をoverride="true"とともにタグ付けしてオーバーライド可能にする必要があります。オーバーライド可能に指定すると、そのバンドルのカスタマイズはアプリケーションのオーバーライド・バンドルに格納されます。
例34-9 adf-config.xmlのadf-resourcebundle-configセクション
<adf-resourcebundle-config xmlns="http://xmlns.oracle.com/adf/resourcebundle/config">
<applicationBundleName>
path-to-resource-bundle/bundle-name
</applicationBundleName>
<bundleList>
<bundleId override="true">
package.BundleID
</bundleId>
</bundleList>
</adf-resourcebundle-config>
|
注意: アプリケーションがカスタマイズ用に構成されていない場合、「カスタマイズ開発者」ロールでアプリケーションを開き、「アプリケーション」メニューから「Edit Resource Bundles」を選択して新しいリソース・キーを定義できます。ただし、カスタマイズ用に構成されていない場合、ドキュメントを変更して新しいリソース・キーを使用することはできません。 |
拡張メタデータは、メタデータのコンテンツを説明するデータです。拡張メタデータ・ファイルには、メタデータ・ファイルについての追加情報が含まれます。この拡張情報を使用する目的の1つは、実行時にメタデータのどの部分をカスタマイズできるか(実行時のデザインタイムのカスタマイズ)および誰がカスタマイズできるか識別することです。拡張メタデータ・プロパティのこの用法の詳細は、34.4.2項「実行時のデザインタイムのカスタマイズを有効にする方法」を参照してください。
メタデータ・ファイル(.jspxファイルなど)をJDeveloperで開き、プロパティ・インスペクタを使用して拡張メタデータ・プロパティを表示および編集できます。メタデータ・ファイルを開くと、プロパティ・インスペクタに拡張メタデータ・プロパティが表示されます。これらのプロパティを編集して、次のいずれかのレベルでメタデータ情報を追加できます。
ファイルレベル: 構造ウィンドウでルート要素が選択されている場合、プロパティ・インスペクタにこれらのプロパティが表示されます。
要素レベル: 構造ウィンドウで要素が選択されている場合、プロパティ・インスペクタにこれらのプロパティが表示されます。選択した要素は、null以外の識別子を持つ必要があります。
拡張メタデータ・プロパティは、カスタマイズをサポートし、MARにパッケージ化できるファイル・タイプ(.jsffファイルや.jspxファイルなど)に対してサポートされます。
メタデータ・ドキュメントの拡張メタデータは、関連するリソース記述フレームワーク(RDF)ファイルに格納されます。RDFは、メタデータを定義するXMLフレームワークの定義に使用されるW3C標準です。メタデータ・ドキュメントに関連付けられるRDFファイルは、プロパティ・インスペクタを使用して最初のプロパティ値を指定するときに作成されます。拡張メタデータ・プロパティは、JDeveloperがデフォルト・ロールの場合にのみ編集できます。「カスタマイズ開発者」ロールでは、RDFファイルは読取り専用です。
RDFファイルは、mdssysディレクトリに格納されます。たとえば、記述されるメタデータが/myapp/data/page1.jspxとしてファイル・システムに格納される場合、対応する拡張メタデータ・ドキュメントは/myapp/data/mdssys/mdx/page1.jspx.rdfとして格納されます。その後、拡張メタデータ・ドキュメントを対応するメタデータ・ベース・ファイルとともにパッケージ化して、同じデプロイメント・プロファイルに追加する必要があります。MARデプロイメント・プロファイルの作成の詳細は、36.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
|
注意: 拡張メタデータ・ドキュメントを直接編集することはできません。プロパティ・インスペクタを使用してください。 |
拡張メタデータ・プロパティを使用して、メタデータ・ファイル(.jspxファイルなど)に含まれていない追加のメタデータ情報を提供できます。JDeveloperでメタデータ・ファイルを開くと、プロパティ・インスペクタに拡張メタデータ・プロパティが表示されます。JDeveloperをデフォルト・ロールで使用している場合は、プロパティ・インスペクタを使用してこれらのプロパティを編集できます。
たとえば、なんらかのフォームのメタデータ・ファイルを外部の顧客に配信するとします。メタデータ・ファイルとともに、作成者、題目、内容、形式、権利などファイルに関する追加情報を提供する必要があります。メタデータ・ファイルの拡張メタデータ・プロパティ・ファイルを作成することで、これらの情報を提供できます。
拡張メタデータ・プロパティを編集するには:
デフォルト・ロールを使用してJDeveloperを起動します。
JDeveloperで、適切なアプリケーションとプロジェクトを開きます。
アプリケーション・ナビゲータで、拡張メタデータ・プロパティを編集するオブジェクトを選択します。
構造ウィンドウで、適切な要素(通常はルート要素)を選択します。
プロパティ・インスペクタで、適切なノードを展開してプロパティを編集します。
選択したコンポーネントの値のプロパティ・インスペクタを表示するには、「表示」メニューから「プロパティ・インスペクタ」を選択します。
目的のプロパティの値を編集して、[Enter]を押します。
「ファイル」メニューから、「保存」を選択して作業内容を保存します。
メタデータ・ファイルの拡張メタデータ・プロパティを編集した場合は、アプリケーションのデプロイ時に、拡張メタデータ(またはRDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
拡張メタデータ・プロパティを使用して、実行時にメタデータのどの部分をカスタマイズできるか、および誰がメタデータのコンテンツをカスタマイズできるかについての情報を提供することもできます。
デフォルトでは、.jspxページに追加できる多くのコンポーネント(表やpanelSplitterなど)は、ランタイム・カスタマイズを許可するように事前構成されており、暗黙的なユーザー・カスタマイズをサポートしています(表の列順の変更など)。一部のWebCenter Portalコンポーネント(panelCustomizableなど)でも、タイプ定義のカスタマイズが許可されています。ユーザー・カスタマイズの詳細は、第35章「実行時のユーザー・カスタマイズの許可」を参照してください。WebCenter Portalコンポーネントの詳細は、Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイドを参照してください。
カスタマイズできるようにコンポーネントが事前構成されている場合、さらに変更を加えて実行時のデザインタイムのカスタマイズを可能にする必要はありません。このようなコンポーネントを.jspxページで使用する場合、デフォルトでカスタマイズ可能になっています。ただし、メタデータ・オブジェクトのルート要素(.jspxページやページ定義ファイルなど)および.jspxページに追加できるその他のコンポーネント(ボタンなど)は、実行時にカスタマイズできるように事前構成されていないため、ランタイム・カスタマイズを許可するように明示的に構成する必要があります。
このため、アプリケーションの要件に応じて、次の状況でカスタマイズ・プロパティを変更する必要があります。
カスタマイズを許可するように事前構成されているコンポーネントの場合、デフォルト設定をオーバーライドしてカスタマイズを禁止することができます。
カスタマイズを許可するように事前構成されていないコンポーネントおよびメタデータ・オブジェクト(.jspxページなど)の場合、デフォルト設定をオーバーライドしてカスタマイズを許可することができます。
カスタマイズを許可するように構成されているコンポーネントの場合、オプションで、実行時にカスタマイズを実行できるユーザーを制限することができます。
プロパティ・インスペクタのカスタマイズ・グループには、実行時にオブジェクトをカスタマイズできるかどうか、および誰がカスタマイズを実行できるかを指定する2つのプロパティがあります。任意の要素にCustomizationAllowedプロパティを設定して、カスタマイズできるかどうかを指定できます。CustomizationAllowedByプロパティは、要素をカスタマイズできるユーザーを制御します。JDeveloperを使用してシード・カスタマイズを実装する場合、これらの設定は強制されませんが、実行時にアプリケーションをカスタマイズする場合は強制されます(実行時のデザインタイムのカスタマイズ)。
たとえば、2つのパネルで構成される.jspxページがあり、パネル1のコンテンツにはランタイム・カスタマイズを許可する必要があり、パネル2のコンテンツには許可する必要がないとします。パネル1ではCustomizationAllowedにtrueを設定し、パネル2ではfalseを設定します。ページ全体でランタイム・カスタマイズを許可する必要がある場合は、.jspxページ・ルートのCustomizationAllowedにtrueを設定します。
カスタマイズ・プロパティを編集するには:
デフォルト・ロールを使用してJDeveloperを起動します。
JDeveloperで、適切なアプリケーションとプロジェクトを開きます。
アプリケーション・ナビゲータで、カスタマイズ・プロパティを編集するオブジェクトを選択します。
構造ウィンドウで、適切な要素を選択します。
プロパティ・インスペクタで、カスタマイズ・ノードを展開してカスタマイズ・プロパティを編集します。
選択したコンポーネントの値のプロパティ・インスペクタを表示するには、「表示」メニューから「プロパティ・インスペクタ」を選択します。
プロパティの値を編集して、[Enter]を押します。
たとえば、.jspxファイルでランタイム・カスタマイズを許可する場合、ファイルを選択してCustomizationAllowedプロパティをtrueに設定します。
「ファイル」メニューから、「保存」を選択して作業内容を保存します。
カスタマイズ・プロパティを編集した場合は、アプリケーションのデプロイ時に、拡張メタデータ(RDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
カスタマイズしたアプリケーションで実行時にセッションごとにカスタマイズ構成(adf-config.xmlファイルのcust-configセクション)をオーバーライドできるようして、特定のセッション(またはWebリクエスト)にカスタマイズを適用する方法をユーザーが変更できるようにすることができます。
アプリケーションがsiteレイヤーとuserレイヤーで構成されていて、siteレイヤーに実行時のデザインタイムのカスタマイズを行うシナリオを考えてみます。アプリケーションのカスタマイズ構成(adf-config.xmlファイルで定義された)を使用する場合、実装するカスタマイズはすべてuserレイヤーに適用されます。このため、特定のセッションのカスタマイズ構成を調整して、カスタマイズをsiteレイヤーに適用できる必要があります。
または、管理者がsiteレイヤーのカスタマイズのみを持つベース・メタデータ・ドキュメントを確認できる必要があるとします。このような場合、アプリケーションのadf-config.xmlファイルで元々指定されている以外の、変更済のカスタマイズ構成を指定する必要があります。
Webリクエストごとに、Oracle ADFはMDSセッションを作成します。セッション(Webリクエスト)に適用するMDSカスタマイズ構成変更に対して、新しいカスタマイズ構成の変更済MDSセッション・オプションをOracle ADFにプログラムで提供できます。これは、MDSセッションの作成時に、元のMDS構成の上に適用されます。
この機能を実装するには、sessionOptionsFactoryの次のADFインタフェースを使用します。
oracle.adf.share.mds.SessionOptionsFactoryは、ADFアプリケーションでWebリクエストの変更済MDSセッション・オプションを指定するためのインタフェースです。
SessionOptionsFactory :: oracle.mds.core.SessionOptions createSessionOptions(oracle.mds.core.SessionOptions defaultOptions)
このメソッドを実装すると、変更済MDS sessionOptionsがADFに戻されます。
oracle.adf.share.config.ConfigUtilsは、セッション・オプション・ファクトリをADFに登録するためのパブリック・クラスです。
ConfigUtils :: public static void setSessionOptionsFactory(ADFContext context, SessionOptionsFactory factory)
これらのインタフェースの詳細は、ADF APIドキュメントを参照してください。
|
注意: Oracle WebCenter Portalのコンポーザ・コンポーネントを使用している場合、 ComposerSessionOptionsFactory :: public SessionOptions createSessionOptions(SessionOptions defaultOptions, String mode);
|
フィルタ実装でsessionOptionsFactoryをOracle ADFまたはOracle WebCenter Portalのコンポーザに登録して、リクエストのライフサイクルでMDSセッションが作成される前に、Oracle ADFが実装から変更済セッション・オプションを取得できるようにします。
例34-10に、sessionOptionsFactoryの実装方法を示します。この例では、adf-config.xmlファイルで指定されたカスタマイズ構成に関係なく、siteカスタマイズ・レイヤーのみを使用する変更済カスタマイズ構成をセッションに設定します。詳細は、oracle.mdsのJavadocを参照してください。
例34-10 sessionOptionsFactoryクラスのサンプル
package mycompany;
import oracle.adf.share.mds.SessionOptionsFactory;
import oracle.mds.config.CustClassListMapping;
import oracle.mds.config.CustConfig;
import oracle.mds.config.MDSConfigurationException;
import oracle.mds.core.SessionOptions;
import oracle.mds.cust.CustClassList;
import oracle.mds.cust.CustomizationClass;
public class MySessionOptionsFactory implements SessionOptionsFactory {
public MySessionOptionsFactory() {
super();
}
/**
* Called to allow the application code to create a new SessionOptions object.
* The application code should make sure to read the values from the
* defaultOptions object as part of contruction of their new object and make
* sure they only override the intended values.
* @param defaultOptions
* @return modified MDS session options
*/
public SessionOptions createSessionOptions(SessionOptions defaultOptions) {
// create new mds Customization configuration
CustConfig custconfig = null;
// create customization class array. Just put SiteCC implementation as we
// wish to apply site customizations alone.
CustomizationClass[] custclassarray = new CustomizationClass[] {new SiteCC()};
CustClassList custclasslist = new CustClassList(custclassarray);
// specify the base metdata package namespace mapping on which site
// customizations would apply
CustClassListMapping[] mappings =
new CustClassListMapping[] {new CustClassListMapping("mycompany/package",
null, null, custclasslist)};
// create new customization configuration
try{
custconfig = new CustConfig(mappings);
}
catch (Exception ex){
//do nothing
}
// now return modified sessionOptions to ADF with new mds customization
// configuration. Only use newly created customization configuration in here.
// For rest of option, use whatever available in defaultOptions.
return new SessionOptions(defaultOptions.getIsolationLevel(),
defaultOptions.getLocale(),
custconfig,
defaultOptions.getVersionContext(),
defaultOptions.getVersionCreatorName(),
defaultOptions.getCustomizationPolicy(),
defaultOptions.getServletContextAsObject());
}
}
