| 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 |
|
前 |
次 |
この章では、顧客がOracle Metadata Services(MDS)フレームワークに基づいてカスタマイズおよびデプロイできるADFアプリケーションを開発する方法について説明します。これらのアプリケーションにカスタマイズを実装する方法についても説明します。
この章の内容は次のとおりです。
カスタマイズしたアプリケーションのデプロイ方法の詳細は、41.4項「アプリケーションのデプロイ」を参照してください。
MDSのカスタマイズ機能を使用して、次のカスタマイズ・パターンのアプリケーションを作成できます。
シード・カスタマイズ
アプリケーションのシード・カスタマイズとは、汎用化されたアプリケーションを特定のグループ(特定の産業やサイトなど)のニーズにあわせて変更するプロセスです。シード・カスタマイズはデプロイされたアプリケーションの一部として存在し、特定のデプロイ期間中保持されます。この章では、カスタマイズ可能なアプリケーションを作成し、JDeveloperを使用してそのアプリケーションをカスタマイズする方法について説明します。
ユーザー・カスタマイズ(変更永続性)
ユーザー・カスタマイズでは、エンド・ユーザーは実行時に個々の設定(表にどの列を表示するかなど)にあわせてアプリケーションの内容を変更できます。変更内容は、次回そのアプリケーションを開くときに記憶されます。ユーザー・カスタマイズの詳細は、第40章「実行時のユーザー・カスタマイズの許可」を参照してください。
MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middleware管理者ガイド』のMDSリポジトリの管理に関する項を参照してください。
カスタマイズしたアプリケーションは、ベース・アプリケーションとカスタマイズを含む1つ以上のレイヤーで構成されます。MDSは、カスタマイズをメタデータ・リポジトリに格納し、実行時にこのカスタマイズを取得してベース・メタデータにマージし、カスタマイズ済アプリケーションを公開します。カスタマイズはベースとは別個に保存されるため、アップグレードの際にカスタマイズが保護されます。つまり、新しいパッチをベースに適用する場合でも、カスタマイズに影響を与えずに行えるということです。カスタマイズ済アプリケーションが起動されると、カスタマイズの内容がベース・アプリケーションに適用されます。
たとえば、給与フィールドを4000に制限する検証規則を持つ、一般的な給与アプリケーションがあるとします。次に、給与フィールドを3300に制限する、この検証規則のカスタマイズを作成します。実行時に、ベース・アプリケーションにカスタマイズが適用され、給与フィールドの検証規則によりフィールドは3300に制限されます。
カスタマイズ可能なアプリケーションには、複数のカスタマイズ・レイヤーを設定できます。カスタマイズ・レイヤーには、業種やサイトなどがあります。各レイヤーには複数のカスタマイズ・レイヤー値を設定できますが、通常、実行時には、各レイヤーからこのようなレイヤー値が1つだけ適用されます。たとえば、カスタマイズ可能なアプリケーションのindustryレイヤーには、healthcareやfinancialなどの業種の値を格納できます。一方、デプロイ対象のカスタマイズ済アプリケーションで一度に使用されるのは、このレイヤー値のいずれか1つのみです。
複数のカスタマイズ・レイヤーからのレイヤー値を、指定の優先順位に従ってベース・メタデータの最上位に適用できます。たとえば、カスタマイズされたアプリケーションでは、industryレイヤーのfinancialレイヤー値とsiteレイヤーのFinancial Company #1レイヤー値にカスタマイズを含めることができます。各カスタマイズ・レイヤーは、基礎となるメタデータを変更する一連の指示を含んだカスタマイズ・ドキュメントに対応します。
カスタマイズしたアプリケーションのカスタマイズ・コンテキストは、適用された一連のカスタマイズ・レイヤー値により定義されます。
図39-1に、カスタマイズしたアプリケーションにレイヤーを適用する方法を示します。
これをサポートするために、JDeveloperを使用してカスタマイズ・クラスを作成し、レイヤーと値を定義して、優先順位を指定します。これらの手順については、39.2項「カスタマイズ可能なアプリケーションの開発」を参照してください。
カスタマイズは、静的なものと動的なものに分類できます。動的なカスタマイズでは、アプリケーションの実行コンテキストによって変化する値を指定できるのに対し、静的なカスタマイズでは、アプリケーションのすべての実行で有効な1つのレイヤー値のみを指定できます。アプリケーションを実行する様々なユーザーによってカスタマイズが変化する可能性がある場合、それは動的なカスタマイズです。アプリケーションを実行するすべてのユーザーでカスタマイズの値が同じである場合、それは静的なカスタマイズです。
ADF Business Componentsオブジェクトにカスタマイズを実装する場合、カスタマイズはアプリケーションの実行時全体にわたって変化しません。これらのオブジェクトはアプリケーションに対して1回だけロードされ、アプリケーションの継続中再利用されるためです。たとえば、サイト・レイヤーのHealthcare Company #1値で、そのサイトの給与フィールドを3300に制限するカスタマイズされた検証規則を持つことができます。これは静的なカスタマイズ・コンテンツです。
ただし、ユーザー・ロール(職責)または他のアプリケーション固有の条件に基づいて実行時にレイヤー値を決定できるカスタマイズを、コントローラ・レベルまたはビュー・レベルで実装することもできます。たとえば、組織が異なるユーザーには画面上で異なるフィールドを表示するように、アプリケーションを設計できます。これは動的なカスタマイズ・コンテンツです。
カスタマイズが静的か動的かの判断は、カスタマイズ・クラスで行われます。カスタマイズ・クラスで、getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、39.2.2項「カスタマイズ・クラスについて」を参照してください。
カスタマイズ・クラスの実装方法によっては、すべてのオブジェクトが静的なカスタマイズ・レイヤーを持つことができます。ただし、ADF Business Componentsオブジェクトの場合、静的なカスタマイズしか使用できません。
カスタマイズを使用し始める前に、他の機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。
MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middleware管理者ガイド』のMDSリポジトリの管理に関する項を参照してください。
ADF Faces変更永続性フレームワークを使用して、ユーザーが実行時にカスタマイズ可能なJSFページを作成できます。詳細は、第40章「実行時でのユーザー・カスタマイズの許可」を参照してください。
カスタマイズ可能なアプリケーションを作成するには、ベース・アプリケーションを作成して次の手順を実行します。
カスタマイズ用にアプリケーションを準備する手順:
39.2.1項「カスタマイズ・クラスの作成方法」の説明に従って、使用するカスタマイズ・クラスを作成します。
39.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。
39.2.7項「adf-config.xmlの構成方法」の説明に従って、adf-config.xmlファイルでカスタマイズ・クラスを指定します。
オプションで、39.4.1項「拡張メタデータ・プロパティの編集方法」の説明に従って、アプリケーションでランタイム・カスタマイズを制限できます。
カスタマイズ用にアプリケーションを準備した後、39.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、JDeveloperを使用してカスタマイズを実装できるようにJDeveloperを準備する必要があります。
カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。各カスタマイズ・クラスでカスタマイズ・レイヤー(industryやsiteなど)を定義して、複数のレイヤー値を含めることができます。アプリケーションで使用するカスタマイズ・クラスは、アプリケーションのカスタマイズ時にJDeveloperで使用できる必要があります。また、デプロイされたアプリケーションに含める必要があります。
カスタマイズ・クラスでは、現在のコンテキストが評価されてStringの結果が戻されます。このStringの結果を使用してカスタマイズ・レイヤーが検索されます。
カスタマイズ・クラスによって、次の情報が提供されます。
レイヤー名を表す名前。
カスタマイズ・レイヤー値を表す値の配列通常、各レイヤーで値が1つ戻されます。複数の値が戻される場合、MDSリポジトリでこれらの値に使用可能なカスタマイズが、配列に表示された順序で適用されます。詳細は、39.2.1.2項「カスタマイズ・クラスでのgetValue()メソッドの実装」を参照してください。
レイヤーで作成されたオブジェクトのIDPrefix。カスタマイズ・レイヤーで新しいオブジェクトを作成する場合、一意のIDが必要です。オブジェクトの自動生成IDにIDPrefixが追加されて、新たに追加されたオブジェクトのIDが作成されます。異なるカスタマイズ・レイヤーで作成されたオブジェクトに一意のIDを指定するために、各レイヤーに一意のIDPrefixを指定する必要があります。
カスタマイズ・クラスによって定義されたレイヤーのキャッシュ・ヒント。キャッシュ・ヒントは、レイヤーが静的か動的かを定義します。getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤは静的です。動的なカスタマイズの詳細は、39.1.2項「静的および動的なカスタマイズ・コンテンツ」を参照してください。CacheHint値の詳細は、39.2.2項「カスタマイズ・クラスについて」を参照してください。
カスタマイズを使用して、特定の業種ドメインにあわせてアプリケーションを調整できます(垂直統合)。このようなドメインはそれぞれカスタマイズ・レイヤーを表しており、カスタマイズ・クラスを使用して示されます。
カスタマイズ・クラスを使用してシード・カスタマイズを実装するには:
adf-config.xmlのcust-configセクション(mds-configの下)に、カスタマイズ・クラスへの参照を含める必要があります(例39-6を参照)。
カスタマイズ構成(cust-config)セクションでは、カスタマイズしたアプリケーションのカスタマイズ・クラスと優先順位が指定されます。39.2.7項「adf-config.xmlファイルの構成方法」を参照してください。
カスタマイズ・クラスをアプリケーションに含め、シード・カスタマイズをサポートする必要があります。
詳細は、39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」を参照してください。実行時に、EARレベルのアプリケーション・クラス・ローダーでカスタマイズ・クラスを使用できる必要があります。
レイヤー値が、CustomizationLayerValues.xmlファイルにリストされている必要があります。
このファイルは、jdev_install\jdevディレクトリにあります。このファイルのレイヤーの名前は、カスタマイズ・クラスと一致する必要があります。(詳細は、39.3.4項「カスタマイズ・レイヤーの構成方法」を参照してください。)JDeveloperは、このファイルを使用してデザインタイムにレイヤー値を取得します。
「カスタマイズ開発者」ロールでJDeveloperが起動されると、「カスタマイズ・コンテキスト」ウィンドウに使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを適用するレイヤーと値を選択します。「カスタマイズ開発者」ロールでの作業の詳細は、39.3.1項「「カスタマイズ開発者」ロールの概要」を参照してください。カスタマイズするために選択するレイヤーは、ヒント・レイヤーと呼ばれます。詳細は、39.3.3項「ヒント・レイヤーの概要」を参照してください。
例39-1に、カスタマイズ・クラスのサンプルを示します。すべてのカスタマイズ・クラスは、単一の引数なしのコンストラクタを持っている必要があります。
例39-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値の詳細は、39.2.2項「カスタマイズ・クラスについて」を参照してください。
getName()メソッドは、カスタマイズ・レイヤーの名前を戻します。たとえば、SiteCCカスタマイズ・クラスはsiteを戻します。この例では、getName()メソッドはindustryを戻します。
generateIDPrefix()メソッドは、IDPrefixを作成します。IDPrefixはレイヤーの名前と値を識別する、一意の省略形の文字列です。カスタマイズ・レイヤーで作成されたオブジェクトのIDの接頭辞として使用されます。デフォルト実装では(IDPrefixが指定されていない場合)、カスタマイズ値と連結されたレイヤー名が戻されます。パフォーマンス上の理由により、IDPrefixは短くする必要があります(4文字以下)。このため、デフォルト実装をオーバーライドする必要があります。関連するgetIDPrefix()メソッドは、カスタマイズ・レイヤーのIDPrefixを戻します。この例では、getIDPrefix()メソッドはI(industryの場合)を戻します。
getValue()メソッドは、カスタマイズ・クラスのカスタマイズ値(複数可)を戻します。この例では、getValue()メソッドは単一値financialを戻し、レイヤー名と組合せてカスタマイズ・コンテキストを定義します。39.2.1.2項「カスタマイズ・クラスでのgetValue()メソッドの実装」で、getValue()メソッドを使用するその他の手法について説明します。
|
注意: レイヤー名に対応する有効なレイヤー値は、JDeveloperによって |
getValue()メソッドを使用して、アプリケーションのコンテキストとメタデータに基づいて、カスタマイズ・クラスのレイヤー値が取得されます。たとえば、SiteCCカスタマイズ・クラスでgetValue()を呼び出すと、単一エントリheadquartersを持つ配列が戻されます。一般に、getValue()メソッドは単一値を持つ配列を戻します(例39-1を参照)。
getValue()メソッドから複数の値を戻すこともできます(例39-2を参照)。
例39-2 複数の値を戻すgetValue()メソッド
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
return new String[]{"North America", "US", "CA"}
}
複数の値が戻される場合、すべての値に適用できるカスタマイズが適用されます。カスタマイズは、配列に表示された順序で適用されます。この例では、North Americaカスタマイズがベース・アプリケーションに適用され、次にUSカスタマイズが適用され、最後にCAが適用されます。
|
注意: カスタマイズ・レイヤーに複数の値を戻すことは高度な概念で、通常は必要とされません。 |
getValue()メソッドは、現行ユーザーの現在の実行コンテキストに基づいてレイヤー値を戻すことができます。この値は、クライアントが保持する静的またはスレッド・ローカル状態から、またはMDSセッションでメタデータ・オブジェクト名に基づいてクライアントによって設定されたプロパティから取得されます。例39-3は、このタイプの実装を示しています。
例39-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を戻して、リモート・サイトのカスタマイズを適用します。
|
注意:
|
開発サイクル中に有効なその他の手法として、外部プロパティ・ファイルを使用してレイヤー値を指定する手法があります。例39-4は、レイヤー値を格納するプロパティ・ファイル(customization.properties)を参照しています。
例39-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ファイルを使用する場合は、同じクラス・ローダーからロードされるように、カスタマイズ・クラスとともにパッケージ化する必要があります。
例39-5に、customization.propertiesファイルのサンプルを示します。このプロパティ・ファイルでIndustryCCクラスがロードされる場合、レイヤー値healthcareが適用されます。
カスタマイズ・クラスを作成したら、別個のプロジェクトに配置します。これによりJARにデプロイして、JARを最下位レベルのプロジェクト(一般に、データ・モデル・プロジェクト)にインポートできます。このアプローチによってモジュール性が高まり、カスタマイズ・クラスを社内の複数のアプリケーションに容易に組み込み、一元的にパッチを適用できます。このアプローチの詳細は、39.2.3項「カスタマイズ・クラスの使用方法」を参照してください。
また、1つのアプリケーションのみで使用するカスタマイズ・クラスを作成している場合、「カスタマイズ開発者」ロールを使用する必要がなく、単純にJDeveloperからアプリケーションをローカルで実行する場合またはMDS構成を使用してリモートにデプロイする場合、カスタマイズ・クラスをデータ・モデル・プロジェクトに配置できます。
アプリケーションにカスタマイズ・クラスのコピーが1つしかないことおよびEARレベルのアプリケーション・クラス・ローダーからロードできるようにJARファイルにパッケージ化されていること、を確認してください。デフォルトでは、プロジェクトの依存性を追加すると、カスタマイズ・クラスがWARプロファイルに追加されます。これは、アプリケーションをパッケージ化してデプロイした後は正しく機能しません。デプロイ用にアプリケーションをパッケージ化する方法については、41.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
カスタマイズ・クラスを作成するには、次の手順を使用します。
作業を始める前に、次のようにします。
カスタマイズ・クラスの機能に関する知識が役立つ場合があります。詳細は、39.2.1.1項「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ・クラスを保持するアプリケーションを開く(または作成する)必要があります。
カスタマイズ・クラスを作成するには:
メイン・メニューから「ファイル」→「新規」の順に選択します。
「新規ギャラリ」で、「一般」を開き、「プロジェクト」、「Javaプロジェクト」の順に選択して、「OK」をクリックします。
Javaプロジェクトの作成ダイアログが開きます。このダイアログのオプションの詳細は、オンライン・ヘルプを参照してください。
プロジェクトの適切な設定を指定して、「終了」をクリックします。
|
注意: すべてのカスタマイズ・クラスを保持するには、単一のプロジェクトを使用する必要があります。 |
アプリケーション・ナビゲータで、プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」をクリックしてから「ライブラリの追加」をクリックします。
「ライブラリの追加」ダイアログでMDSランタイムを選択し、「OK」をクリックし、もう一度「OK」をクリックして「プロジェクト・プロパティ」ダイアログを閉じます。
アプリケーション・ナビゲータで、プロジェクトを右クリックして「新規」を選択します。
「新規ギャラリ」で「一般」を開き、「Java」、「クラス」を選択して「OK」をクリックします。
「Javaクラスの作成」ダイアログで、クラスの名前と適切なパッケージを入力します。
|
注意: カスタマイズ・クラスには一般に、戻すレイヤー名が付けられます。たとえば、レイヤー名 |
「拡張」フィールドにoracle.mds.cust.CustomizationClassと入力します。
このクラスの詳細は、Javadocを参照してください。
「抽象メソッドの実装」が選択されていることを確認して、「OK」をクリックします。
生成されたファイルで、コードを例39-1に示すようなコードで置き換えます。
変更内容を保存してプロジェクトを再ビルドします。
これでカスタマイズ・クラスが作成されます。サンプル・コードではパッケージ名mycompanyとクラス名IndustryCCが使用されています。これらを、アプリケーションにあわせて変更する必要があります。
39.2.1.1項「カスタマイズ・クラス」で説明したように、カスタマイズ・クラスではカスタマイズ・レイヤーでのメタデータ・オブジェクトの可視性、およびその結果としてのメモリー内での存続期間を指定するCacheHintが定義されます。MDSはこの情報を使用して、カスタマイズをキャッシュするかどうか、およびどこにキャッシュするかを決定します。このカスタマイズ・クラスを使用して構築されたカスタマイズ・レイヤーは、このキャッシュ・ヒントを持ちます。
次の定数は、CacheHintでサポートされる値です。
ALL_USERS: カスタマイズは特定のデプロイメントでグローバルに適用されます(条件付きではない)。この定数は、静的なカスタマイズ・レイヤーで使用されます。
MULTI_USER: カスタマイズは複数のユーザーに適用されます。
REQUEST: カスタマイズは、リクエスト期間にのみ適用されます。
USER: カスタマイズは単一ユーザーに対して、ユーザーのアプリケーション・セッション中にアクセスされるドキュメントに適用されます。(Webアプリケーションでは、アプリケーション・セッションは通常サーブレット・セッションです。)
|
注意: カスタマイズ・クラスは頻繁に実行されることが多いため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。 |
カスタマイズ・クラスを作成後、これらを設計時に「カスタマイズ開発者」ロールでおよび実行時にアプリケーションで使用できます。アプリケーションまたはJDeveloperで使用するには、クラスを適切にパッケージ化する必要があります。
カスタマイズ・クラスの作成後、JDeveloperでカスタマイズ・クラスを使用可能にして、カスタマイズの実装時に「カスタマイズ開発者」ロールで操作中に使用できるようにする必要があります。
カスタマイズ・クラスは再利用可能コンポーネントであるため、別個のプロジェクトを作成してこれにカスタマイズ・クラスを含めて、独自のJARファイルにパッケージ化できます。その後、使用するアプリケーションにJARをインポートし、カスタマイズ・クラスをJDeveloperで使用できます。別個のプロジェクトへのカスタマイズ・クラスの作成の詳細は、39.2.1.3項「カスタマイズ・クラスの作成」を参照してください。カスタマイズ・クラスのJARファイルへのパッケージ化の詳細は、41.3.2.6項「JARへのカスタマイズ・クラスの追加」を参照してください。
|
注意: 使用するアプリケーションのデータ・モデル・プロジェクトでカスタマイズ・クラスを作成した場合、この手順は不要です。 |
次の手順を使用してアプリケーションでカスタマイズ・クラスを表示できるようにしてから、39.2.7項「adf-config.xmlファイルの構成方法」の説明に従って、カスタマイズ・クラスをadf-config.xmlファイルのcust-configセクションに追加します。
作業を始める前に、次のようにします。
カスタマイズ・クラスをパッケージ化する方法に関する知識が役立つ場合があります。詳細は、39.2.1.1項「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、外部プロジェクトでカスタマイズ・クラスを作成します。
41.3.2.6項「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
外部プロジェクトからカスタマイズ・クラスを使用するには:
「アプリケーション・ナビゲータ」でデータ・モデル・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」をクリックします。
「JAR/ディレクトリの追加」をクリックします。
「アーカイブまたはディレクトリの追加」ダイアログで、カスタマイズ・クラスを含む作成済JARファイルを選択して、「選択」をクリックします。
「OK」をクリックして、「プロジェクト・プロパティ」ダイアログを終了します。
JDeveloperでプロジェクトをローカルに実行するためやカスタマイズのために、カスタマイズ・クラスを使用できます。
カスタマイズしたアプリケーションをパッケージ化してデプロイする際、アプリケーションのクラス・パスで、アプリケーション・レベルでカスタマイズ・クラスを使用できる必要があります。
アプリケーションのデプロイメント・プロファイルを定義する際、カスタマイズ・クラスJARファイルをEARアセンブリに追加する必要があります。また、重複を避けるために、WARプロファイルにカスタマイズ・クラスJARファイルが含まれないようにする必要があります。詳細は、41.3.2.3項「アプリケーション・レベルのEARデプロイメント・プロファイルの作成」を参照してください。
すべてのカスタマイズ可能なコンポーネントと同様に、カスタマイズ可能なメタデータ・オブジェクトのXML要素はMDSによって一意に識別できる必要があるため、NULL以外の一意の識別子を指定する必要があります。このコンポーネントの識別子を使用して、カスタマイズ・レイヤー内のカスタマイズ指示の要素を参照します。IDプロパティは、ADF Faces .jspxまたは.jsffファイルの各タイプのコンポーネントの識別子です。
JSFページとJSPページでカスタマイズを可能にするには、ページの一部のデフォルト設定を受け入れずに、アプリケーションのビュー・プロジェクトでシード・カスタマイズを有効にする必要があります。これは、モデル・プロジェクトとコントローラ・プロジェクトでは不要です。
|
注意: MDSでは、カスタマイズするにはこれらのページがXMLベースである必要があります。このため、 さらに、Faceletファイルには、カスタマイズを可能にするために拡張子 |
作業を始める前に、次のようにします。
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
ビュー・プロジェクトでシード・カスタマイズを有効にする手順:
アプリケーション・ナビゲータでビュー・プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「ADFビュー」をクリックします。
図39-2に示すように、「シード・カスタマイズの有効化」チェック・ボックスを選択します。
「OK」をクリックします。
プロジェクトの変更を保存します。
プロジェクトに前のバージョンのJDeveloperで作成されたページがある場合、これらの既存のページでもシード・カスタマイズを有効にする必要があります。これは、アプリケーションを前のバージョンのJDeveloperから移行して、移行中にIDを生成していない場合にのみ必要です。
作業を始める前に、次のようにします。
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
既存のページでシード・カスタマイズを有効にする手順:
監査プロファイルを作成して、ページのすべてのXMLオブジェクトにIDトークンを実装します。
「ツール」メニューで「設定」を選択します。
「設定」ダイアログで、「監査」→「プロファイル」を選択します。
「プロファイル」ページの「ルール」タブで、すべてのルールを選択解除します。
ルール「ADF Faces」→「コンポーネントIDルール」→「ADF Facesが存在する場合、IDをチェックします」を選択します。
「デフォルト修正」ドロップダウン・リストで、「一意のIDの生成」を選択します。
「名前を付けて保存」をクリックし、プロファイルに識別可能な名前(「一意のIDの生成」など)を入力して「保存」をクリックします。
「OK」をクリックして「プリファレンス」ダイアログを閉じます。
アプリケーション・ナビゲータで、シード・カスタマイズを有効にするページを選択します。プロジェクトを選択して、そのプロジェクトに含まれるすべてのファイルに対して監査を実行することもできます。
「ビルド」メニューから、「監査」→「ファイル名」を選択します。
「監査」ダイアログで、作成したプロファイルを選択してIDを生成し、「実行」をクリックします。
ログ・ウィンドウを使用して問題を確認し、修正を適用します。
監査が完了したら、変更内容を保存します。
カスタマイズの実装時に新しいリソース・キーを作成する予定がある場合、「アプリケーション・プロパティ」ダイアログを使用して影響を受けるリソース・バンドルを指定できます。
作業を始める前に、次のようにします。
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
リソース・バンドルでカスタマイズを有効にする手順:
アプリケーションのコンテキスト・メニューから「アプリケーション・プロパティ」を選択します。
「アプリケーション・プロパティ」ダイアログで、「リソース・バンドル」をクリックします。
「追加」をクリックします。
「リソース・バンドルの選択」ダイアログで、カスタマイズを有効化するリソース・バンドルを探して選択します。
「開く」をクリックします。
「アプリケーション・プロパティ」ダイアログで、「バンドル」表の「オーバーライド済」列のチェックボックスを選択します。
「OK」をクリックします。
アプリケーションのadf-config.xmlファイルでは、mds-configセクションで適切なcust-config要素が指定されている必要があります。クライアントはcust-config要素を使用して、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを定義できます。adf-config.xmlファイルの概要エディタを使用して、カスタマイズ・クラスを追加します(図39-3を参照)。
作業を始める前に、次のようにします。
カスタマイズ・クラスを作成しパッケージ化する方法に関する知識が役立つ場合があります。詳細は、39.2.1.1項「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
41.3.2.6項「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
adf-config.xmlファイルでカスタマイズ・クラスを識別する手順:
アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを開きます。
「ディスクリプタ」および「ADF META-INF」を展開します。
adf-config.xmlを右クリックして、「開く」を選択します。
概要エディタで「MDS構成」ナビゲーション・タブをクリックして、「追加」アイコンをクリックします。
「カスタマイズ・クラスの編集」ダイアログで、作成済のカスタマイズ・クラスを検索するか、作成済のカスタマイズ・クラスに移動します。
適切なクラスを選択して、「OK」をクリックします。
カスタマイズ・クラスをすべて追加した後、矢印アイコンを使用して適切な順序で配置できます。
図39-3は、2つのカスタマイズ・クラスが追加されたadf-config.xmlファイルの概要エディタを示しています。
customization-class要素の順序により、カスタマイズ・レイヤーの優先順位が指定されます。たとえば、例39-6に示すコードでは、IndustryCCクラスはSiteCCクラスの前に表示されています。これは、industryレイヤーでのカスタマイズがベース・アプリケーションに適用されてから、siteレイヤーでのカスタマイズが適用されることを示します。
例39-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>
カスタマイズ可能アプリケーションを作成する際、カスタマイズしたアプリケーションの基礎として使用するために必要な部分を含むベース・アプリケーションがあります。
カスタマイズを実行するには、39.3項「アプリケーションのカスタマイズ」の説明に従って、「カスタマイズ開発者」ロールを使用してJDeveloperでアプリケーションを開く必要があります。
Oracle ADFコンポーネント(コントローラ、モデルおよびビジネス・コンポーネント・オブジェクトなど)をカスタマイズするには、これらに一意の識別子を指定する必要があります。ビュー・コントローラ・プロジェクトのJSPページとJSFページを除き、JDeveloperによって生成されるADFコンポーネントは、デフォルトでは識別子とともに作成されます。JDeveloperにビュー・コントローラ・プロジェクトのページ上のコンポーネントの識別子を生成させるには、プロジェクト・レベルで明示的に指定する必要があります(39.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」を参照)。
アプリケーションでカスタマイズを実装する前に、カスタマイズするすべてのオブジェクトに必要な識別子が指定されていることを確認します。多くの場合、監査ルールを実行し、欠落を把握して修正することができます(39.2.5項「既存のページでシード・カスタマイズを有効化する方法」を参照)。
また、カスタマイズ・クラスは頻繁に実行できるため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。
「カスタマイズ開発者」ロールを使用して、カスタマイズ可能アプリケーションでカスタマイズを作成できます。
「カスタマイズ開発者」ロールを使用して、プロジェクトのメタデータをカスタマイズします。カスタマイズ機能は、このロールでのみ使用できます。「カスタマイズ開発者」ロールでは、次の作業を実行できます。
カスタマイズの作成および更新
カスタマイズしたアプリケーションのヒント・レイヤーの選択および編集
既存のカスタマイズの削除
「カスタマイズ開発者」ロールで作業する場合、ソース・エディタは読取り専用になり、次のJDeveloperの機能が無効になります。
ワークスペースの移行
アプリケーションおよびIDE接続の作成、削除および変更「カスタマイズ開発者」ロールでアプリケーションを開く前に、デフォルト・ロールで接続を構成する必要があります。
「カスタマイズ開発者」ロールでアプリケーションを使用する場合、新規オブジェクトは作成できず、カスタマイズ不能オブジェクトは変更できません。ただし、次のコンテンツ・タイプはカスタマイズ可能です。
ポータル・モジュール
ADFモジュール(ADF Faces、ADF Model、ADF Business Components、ADF Controllerなど)
|
注意: ADF Business Componentsオブジェクトは、「カスタマイズ・コンテキスト」ウィンドウで静的カスタマイズ・クラスが選択されている場合のみカスタマイズ可能です。それ以外の場合、ビジネス・コンポーネント・オブジェクトは読取り専用です。 |
「カスタマイズ開発者」ロールで作業する場合、Javaクラス、リソース・バンドル、セキュリティ・ポリシー、デプロイメント・ディスクリプタ、構成ファイルなどのカスタマイズ不能ファイルは編集できません。「カスタマイズ開発者」ロールで作業している際、カスタマイズ不能ファイルはロック・アイコンで示されます。
|
注意: Faceletファイルには、カスタマイズを可能にするために拡張子 |
プロジェクト設定の変更や、サービス・インタフェースやビジネス・イベント定義など特定のADF Business Components機能のカスタマイズも制限されます。また、カスタマイズ不能ファイルの変更が必要になる場合は、カスタマイズ可能ファイルをリファクタまたは変更できません。
「カスタマイズ開発者」ロールでは、JDeveloperのカスタマイズ機能を使用できます。このロールで作業するには、JDeveloperの起動時に選択するか、JDeveloperがすでに実行されている場合は「ロールの切替え」メニューで「カスタマイズ開発者」ロールに切り替えます。
作業を始める前に、次のようにします。
「カスタマイズ開発者」ロールの機能に関する知識が役立つ場合があります。詳細は、39.3.1項「「カスタマイズ開発者」ロールの概要」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
JDeveloperを起動する必要もあります。
JDeveloperで「カスタマイズ開発者」ロールに切り替える手順:
メイン・メニューで「ツール」→「ロールの切替え」→「カスタマイズ開発者」の順に選択します。
|
注意: 任意で「ツール」→「ロールの切替え」→「起動時にロール選択を常に要求」メニュー・アイテムを切り替え、JDeveloper起動時にロールを選択するかどうかを指定できます。この選択を解除すると、JDeveloperは、最後に閉じたときのロールで起動します。 |
「カスタマイズ開発者」ロールで作業する際、「カスタマイズ・コンテキスト」ウィンドウで選択したレイヤーとレイヤー値の組合せをヒント・レイヤーと呼びます。このレイヤーには、「カスタマイズ開発者」ロールで作業中に行った変更が適用されます。
JDeveloperのエディタに表示されるメタデータは、ベース・メタデータと(adf-config.xmlで設定された優先順位に従った)ヒント・レイヤーまでのカスタマイズ・レイヤーを組み合せたもので、各レイヤーの値は「カスタマイズ・コンテキスト」ウィンドウで指定したものです。
「カスタマイズ開発者」ロールでの作業時には、アプリケーションのカスタマイズされていない状態も確認できます。「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」が選択されている場合、現在使用しているヒント・レイヤーはありません。したがって、表示されているのはカスタマイズされていない状態です。このビューでは、(アプリケーション・ナビゲータの)カスタマイズ可能ファイルすべてにロック・アイコンが表示され、これらのファイルが読取り専用であることが示されます。
ヒント・レイヤーでカスタマイズを行うと、プロパティ・インスペクタでこれらのカスタマイズはオレンジのアイコンで示されます。緑のアイコンは、ヒント以外のレイヤーのカスタマイズを示します。プロパティの横にオレンジのアイコンが表示されている場合、そのプロパティのドロップダウン・メニューから「カスタマイズ・アクションの削除」を選択して、そのカスタマイズを削除できます。
アプリケーションをカスタマイズするには、JDeveloperで認識できるように、CustomizationLayerValues.xmlファイルでカスタマイズ・レイヤーとその値を指定する必要があります。
カスタマイズ可能なアプリケーションを「カスタマイズ開発者」ロールで開くと、JDeveloperによりadf-config.xmlファイルが読み取られ、使用するカスタマイズ・クラスと優先順位が判別されます。また、CustomizationLayerValues.xmlファイルも読み取られ、「カスタマイズ・コンテキスト」ウィンドウで使用可能にするレイヤー値が判別されます。CustomizationLayerValues.xmlファイルで定義されたレイヤー値がカスタマイズ・クラス(adf-config.xmlファイルにリストされている)で定義されていない場合、これらは「カスタマイズ・コンテキスト」ウィンドウに表示されません。
したがって、CustomizationLayerValues.xmlファイルにすべてのカスタマイズ・プロジェクトの包括的なレイヤー値リストを含めて、現在のアプリケーションに適したもののみを「カスタマイズ・コンテキスト」ウィンドウに表示できます。逆に、アプリケーションの包括的なカスタマイズ・クラスのリストをadf-config.xmlファイルに含めて、作業するレイヤー値のサブセットのみをCustomizationLayerValues.xmlファイルに含めることもできます。
|
注意: デザインタイムには、JDeveloperは |
CustomizationLayerValues.xmlファイルに入力するレイヤー名およびレイヤー値は、カスタマイズ・クラスで指定されたものと一致する必要があります。例39-7にサンプルのCustomizationLayerValues.xmlファイルの内容を示します。
例39-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が作成されます。たとえば、例39-7では、siteレイヤーにsというid-prefixが付けられ、headquartersレイヤー値にhqというid-prefixが付けられています。したがって、ヒント・レイヤーとしてsite/headquartersを選択して、コマンド・ボタンをページに追加すると、メタデータ・カスタマイズ・ファイルでコマンド・ボタンにshqcb1というidが設定されます。
各レイヤー値にdisplay-nameトークンを追加して、レイヤー値に人間が判読可能な名前を指定することもできます。「カスタマイズ開発者」ロールで作業する際、そのレイヤー値のdisplay-nameトークンの値が「カスタマイズ・コンテキスト」ウィンドウに表示されます。
カスタマイズ・レイヤー値はJDeveloper用にグローバルにまたはアプリケーション固有ファイルで定義できます。アプリケーション固有ファイルを使用する場合、このファイルはグローバル・ファイルより優先されます。JDeveloper用にグローバルにレイヤー値を構成する方法の詳細は、39.3.4.1項「レイヤー値をグローバルに構成」を参照してください。アプリケーション固有のレイヤー値を構成する方法の詳細は、39.3.4.2項「Studio開発者ロールでのワークスペースレベルのレイヤー値の構成」を参照してください。
JDeveloper用にCustomizationLayerValues.xmlファイルをグローバルに構成する手順は、次のとおりです。
作業を始める前に、次のようにします。
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、39.3.4項「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
JDeveloper用にデザインタイム・カスタマイズ・レイヤー値をグローバルに構成する手順:
CustomizationLayerValues.xmlファイルを探して開きます。
このファイルは、JDeveloperインストール・ディレクトリのjdevサブディレクトリにあります(jdev_install\jdev\CustomizationLayerValues.xml)。
各レイヤーに、例39-7のようにcust-layer要素を入力します。
各レイヤー値に、例39-7のようにcust-layer-value要素を入力します。
CustomizationLayerValues.xmlファイルを保存して閉じます。
グローバルなCustomizationLayerValues.xmlファイルに変更を加えた後は、JDeveloperを再起動する必要があります。
アプリケーションのレイヤー値を構成する場合Studio開発者ロールまたは「カスタマイズ開発者」ロールのいずれかを使用できます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルのMDS DTノードでアクセスできます。
次に、Studio開発者ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。
作業を始める前に、次のようにします。
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、39.3.4項「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
Studio開発者ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
アプリケーション・ナビゲータで、adf-config.xmlファイルをダブルクリックします。
adf-config.xmlファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードのADF META-INFにあります。
概要エディタで、「MDS構成」ナビゲーション・タブをクリックします。
カスタマイズ・クラスの表の下の「MDS構成」ページで、「デザインタイム・カスタマイズ・レイヤー値の構成」リンクをクリックして、ワークスペースレベルのCustomizationLayerValues.xmlファイルを開きます。
リンクをクリックすると、JDeveloperによって、ソース・エディタでファイルが開きます。オーバーライド・ファイルがまだ存在しない場合、JDeveloperは、確認ダイアログを表示します。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。
39.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。
変更を保存します。
「カスタマイズ開発者」ロールでアプリケーションのレイヤー値を構成することもできます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルのMDS DTノードでアクセスできます。
次に、「カスタマイズ開発者」ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。
作業を始める前に、次のようにします。
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、39.3.4項「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
「カスタマイズ開発者」ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
「カスタマイズ・コンテキスト」ウィンドウで、「グローバル・レイヤー値のオーバーライド」リンクをクリックします。
リンクをクリックすると、JDeveloperによって、ソース・エディタでCustomizationLayerValues.xmlファイルが開きます。オーバーライド・ファイルがまだ存在しない場合、JDeveloperは、確認ダイアログを表示します。「はい」をクリックして、グローバル・ファイルのコピーを作成して開きます。
39.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、必要なレイヤー値を指定します。
変更を保存します。
「カスタマイズ開発者」ロールの間にアプリケーション固有のCustomizationLayerValues.xmlファイルに対して変更を行った後、「カスタマイズ・コンテキスト」ウィンドウで選択したヒント・レイヤーが選択解除されます。必要なヒント・レイヤーを選択できます。
ベース・アプリケーションの開発時と同じ開発手順および開発手法を使用して、メタデータをカスタマイズします。ただし、カスタマイズを実装するには、メタデータを編集する前に、「カスタマイズ開発者」ロールを使用し、ヒント・レイヤーとレイヤー値を選択してカスタマイズ・コンテキストを指定する必要があります。カスタマイズ可能にできるアプリケーションに対して、プロジェクトでカスタマイズを有効にする必要があります。詳細は、39.2項「カスタマイズ可能なアプリケーションの開発」を参照してください。
作業を始める前に、次のようにします。
カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」および39.3項「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
41.3.2.6項「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
39.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」および39.2.5項「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションのシード・カスタマイズを有効化します。
39.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
JDeveloperでメタデータをカスタマイズする手順:
「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを実装するレイヤーと値を選択します。
図39-4に示すように、(「カスタマイズ・コンテキスト」ウィンドウの下部に表示される)「カスタマイズ・コンテキスト」が選択内容を反映して変更されます。
|
注意: 「カスタマイズ・コンテキスト」ウィンドウで選択された内容は、JDeveloperに実装するカスタマイズのコンテキストを示します。この選択内容が、アプリケーションの実行時に直接影響を及ぼすことはありません。実行時には、カスタマイズ・クラスからカスタマイズ・コンテキストが戻されます。詳細は、39.2.1項「カスタマイズ・クラスの作成方法」を参照してください。 |
開発時に通常行うように、メタデータを編集します。たとえば、エンティティ・オブジェクトを右クリックして、「開く」を選択します。その後、概要エディタを使用してオブジェクトを編集します。
カスタマイズ時には、開発時と同じ方法でメタデータを編集しますが、一定の制約が適用されます。たとえば、ボタン・ラベルなど一部の文字列プロパティは、プロパティ・インスペクタで直接編集できません。「テキスト・リソースの選択」ダイアログまたは式ビルダーを使用して編集する必要があります。カスタマイズ時の編集に対する制限の詳細は、39.3.1項「「カスタマイズ開発者」ロールの概要」を参照してください。式ビルダーの使用については、13.8.1.1項「プロパティ・インスペクタから式ビルダーを開く手順」を参照してください。
概要エディタを使用してカスタマイズを実装する場合でも、ベース・メタデータ・ファイルは変更しません。変更内容は、カスタマイズ・メタデータ・ファイルに別個に保存されます。
|
注意: カスタマイズされていないベース・メタデータを表示するには、「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」を選択します。 |
オプションで、(プロパティ・インスペクタで)プロパティのドロップダウン・メニューから「カスタマイズの削除」を選択して、既存のカスタマイズを消去できます。
|
注意: プロパティ・インスペクタでは、ヒント・レイヤーのカスタマイズはオレンジのアイコンで示され、現在のヒント・レイヤーでカスタマイズされないプロパティは緑のアイコンで示されます。カスタマイズは、これを追加したコンテキストでのみ削除できます。したがって、削除できるのは、プロパティ・インスペクタでオレンジのインジケータが付いているカスタマイズのみになります。 |
「ファイル」メニューから、「保存」を選択して変更を保存します。
カスタマイズの完了後、カスタマイズしたアプリケーションを実行してテストできます。
アプリケーションでカスタマイズを実装する場合、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を使用してADFライブラリのアーティファクトをカスタマイズできます。これが必要になるのは、たとえば、ある開発チームがフレームワーク・サービスの一部としてタスク・フローを作成し、これを他のチームがADFライブラリとして使用できるようにする場合です。その後、他の開発チームがいずれかのタスク・フローを使用アプリケーションで使用して、アプリケーションの要件にあわせて調整する必要が生じます。
ADFライブラリのプロジェクトへの追加は、Studio開発者ロールで実行するのと同様に「カスタマイズ開発者」ロールで実行できます。ただし、 「カスタマイズ開発者」ロールでは、ADFライブラリのコンテンツは編集可能でカスタマイズを実装できるのに対し、Studio開発者ロールでは読取り専用になります。ADFライブラリの使用の詳細は、第38章「アプリケーション・コンポーネントの再利用」を参照してください。
作業を始める前に、次のようにします。
カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」および39.3項「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2.1.3項「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
39.2.3.1項「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
41.3.2.6項「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
39.2.4項「ビュー・プロジェクトでシード・カスタマイズを有効化する方法」および39.2.5項「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションのシード・カスタマイズを有効化します。
39.3.4項「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
ADFライブラリ・アーティファクトをカスタマイズする手順:
アプリケーション・ナビゲータで、「ナビゲータの表示オプション」アイコンをクリックして「ライブラリの表示」を選択します。
これによりアプリケーション・ナビゲータにライブラリが表示されるので、いろいろ見てまわってアーティファクトにアクセスすることができます。
アプリケーション・ナビゲータのライブラリに希望するライブラリがない場合は、希望するライブラリをプロジェクトに追加します。
この手順の詳細は、38.4項「プロジェクトへの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デプロイメント・プロファイルの作成の詳細は、41.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
JDeveloperの「カスタマイズ開発者」ロールで作業している場合、エクスポートしたJARに含まれるADFライブラリ・アーティファクトに実装されたランタイム・カスタマイズを表示できます。
作業を始める前に、次のようにします。
カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、39.1.1項「カスタマイズおよびレイヤーのユースケースおよび例」および39.3項「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、39.1.3項「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
39.2項「カスタマイズ可能なアプリケーションの開発」の説明に従って、カスタマイズ可能なアプリケーションを作成します。
アプリケーションをデプロイし、ランタイム・カスタマイズをこれに実装し、ランタイム・カスタマイズをJARファイルにエクスポートします。詳細は、Oracle WebCenter Framework開発者ガイドを参照してください。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズ可能なアプリケーションを開きます。
ランタイム・カスタマイズを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プロファイルの作成方法の詳細は、41.3.2.2項「MARデプロイメント・プロファイルの作成」を参照してください。
JDeveloperを使用してADFアプリケーションをパッケージ化する場合、次のいずれかの条件が満たされると、デフォルト・メタデータ(カスタマイズなど)を含む自動生成MARプロファイルが作成されます。
ユーザー・インタフェース・プロジェクトの「プロジェクト・プロパティ」ダイアログの「ADFビュー設定」ページで、「ユーザー・カスタマイズの有効化」→「MDSを使用したセッション間チェック・ボックスが選択されている。
adf-config.xmlファイルのMSD構成セクションに、例39-8に示すようにdeploy-target="true"とマークされている<metadata-store-usage>要素が含まれる。
例39-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プロファイルを作成します。デプロイしたEARファイルにMARプロファイルを含めて、実行時にカスタマイズを使用できるようにします。アプリケーションレベル・クラス・ローダーに配置されるように、カスタマイズ・クラスをEARファイルにパッケージ化する必要があります。
|
注意: シード・カスタマイズしかない場合は、ランタイム・カスタマイズもサポートする場合を除き、MARプロファイルを作成してMDSリポジトリにインポートする必要はありません。シード・カスタマイズがあり、セッション間の永続性が有効でない場合、シード・カスタマイズはデフォルトでEARファイルにパッケージ化され、クラス・パスからロードされます。 |
カスタマイズを、アプリケーションで使用されるランタイム・リポジトリにインポートします。
この方法は一般に、ライブラリ・メタデータへのカスタマイズを、別個にデプロイされたアプリケーションに適用する必要がある場合に使用します。この方法を使用してカスタマイズをJARファイルにパッケージ化し、importMetadata WLSTコマンドを使用してMDSランタイム・リポジトリにインポートします。これらのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
アプリケーションにADFライブラリのオブジェクトのカスタマイズがある場合、MARプロファイルの作成時にカスタマイズ・メタデータが暗黙的に含められます。「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更する場合は、パッケージ化する前に、MARプロファイルを再作成する必要があります。
実行時のデザインタイム機能を使用して、実行時にオーバーライド・バンドルでリソース・キーを追加または編集する予定がある場合は、オーバーライド・バンドルをMARプロファイルの一部としてパッケージ化する必要があります。デフォルトでは、アプリケーションにシード・カスタマイズが含まれる場合、オーバーライド・バンドルは自動生成MARプロファイルの一部としてパッケージ化されます。ただし、アプリケーションにシード・カスタマイズが含まれない場合は、MARデプロイメント・プロファイルを明示的に作成してオーバーライド・バンドルをパッケージ化する必要があります。MARプロファイルが明示的に作成される場合、オーバーライド・バンドルはデフォルトでユーザー・メタデータの一部として追加されて含められます。
完了したカスタマイズ済アプリケーションをパッケージ化してデプロイする場合、 「カスタマイズ開発者」ロールではなくStudio開発者ロールで行う必要があります。MARプロファイルの作成方法の詳細は、41.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
実行時に、アプリケーションではadf-config.xmlファイルのcust-configセクションで定義された優先順位に従って、カスタマイズ・メタデータ・ファイルがベース・アプリケーション全体に適用されます。
レイヤー値は実行時にカスタマイズ・クラスから取得され、アプリケーションが実行されているコンテキストで評価されて、そのレイヤー値に適したカスタマイズが適用されます。
アプリケーションをカスタマイズする場合、統合ソース・コントロールを使用したり、リソース文字列をカスタマイズすることがあります。これらの機能を使用する場合に、知っておくべき追加情報があります。
「カスタマイズ開発者」ロールでの作業時には、ソース・コントロール統合によってカスタマイズ・プロセスが補完されます。自動的にチェックアウトして新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されている場合、ソース・コントロール・システムから使用可能なベース・ドキュメントをカスタマイズしようとすると、JDeveloperは次のように動作します。
該当するカスタマイズ・ファイルがまだ使用可能でない場合、ソース・コントロールで新しいカスタマイズ・ファイルが作成されてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在する場合、チェックアウトされてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在し、すでにチェックアウトされている場合、またはまだバージョン・コントロールにない場合、バージョン・コントロール操作なしでカスタマイズが書き込まれます。
ベース・ドキュメントは「カスタマイズ開発者」ロールでは変更されないため、ベース・ドキュメントはチェックアウトされません。
自動的にチェックアウトしたり新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されていない場合、手動でカスタマイズ・ファイルを編集可能にして、新たに作成したカスタマイズ・ファイルをソース・コントロールにチェックインする必要があります。JDeveloperでのソース・コントロールの使用の詳細は、1.4.2項「ソース・コントロール・システムの使用」を参照してください。
アプリケーションをカスタマイズする過程で、コンテンツをカスタマイズして、別のリソース・バンドル・キーを使用したり、新しいリソース・キーを定義して使用できます。
「カスタマイズ開発者」ロールでカスタマイズ可能なアプリケーションを開き、プロパティ・インスペクタを使用してリソース・バンドル文字列の使用方法をカスタマイズできます。ドキュメントを変更して、リソース・バンドルにすでに存在する別のリソース・キーを使用したり、新しいリソースを作成できます。リソース・バンドルの詳細は、4.7項「リソース・バンドルの使用」を参照してください。
新しいリソース・キー(「カスタマイズ開発者」ロールで作成された)は、アプリケーションレベルのオーバーライド・バンドルに(XLIFF形式で)保存され、JDeveloperにより例39-9に示すようなエントリがadf-config.xmlファイルに追加されて、アプリケーションレベルのオーバーライド・バンドルが構成されます。
また、ベース・リソース・バンドルのオーバーライドをサポートするように、adf-config.xmlファイルを構成する必要があります。例39-9に示すように、bundleId要素をoverride="true"とともにタグ付けしてオーバーライド可能にする必要があります。オーバーライド可能に指定すると、そのバンドルのカスタマイズはアプリケーションのオーバーライド・バンドルに格納されます。
例39-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>
|
注意: アプリケーションがカスタマイズ用に構成されていない場合、「カスタマイズ開発者」ロールで開き、「アプリケーション」メニューから「リソース・バンドルの編集」を選択して新しいリソース・キーを定義できます。ただし、カスタマイズ用に構成されていない場合、ドキュメントを変更して新しいリソース・キーを使用することはできません。 |
拡張メタデータは、メタデータのコンテンツを説明するデータです。拡張メタデータ・ファイルには、メタデータ・ファイルについての追加情報が含まれます。この拡張情報を使用する目的の1つは、実行時にメタデータのどの部分をカスタマイズできるか(実行時のデザインタイムのカスタマイズ)および誰がカスタマイズできるか識別することです。拡張メタデータ・プロパティのこの用法の詳細は、39.4.2項「実行時のデザインタイムのカスタマイズを有効にする方法」を参照してください。
メタデータ・ファイル(.jspxファイルなど)をJDeveloperで開き、プロパティ・インスペクタを使用して拡張メタデータ・プロパティを表示および編集できます。メタデータ・ファイルを開くと、プロパティ・インスペクタに拡張メタデータ・プロパティが表示されます。これらのプロパティを編集して、次のいずれかのレベルでメタデータ情報を追加できます。
ファイルレベル: 構造ウィンドウでルート要素が選択されている場合、プロパティ・インスペクタにこれらのプロパティが表示されます。
要素レベル: 構造ウィンドウで要素が選択されている場合、プロパティ・インスペクタにこれらのプロパティが表示されます。選択した要素は、null以外の識別子を持つ必要があります。
拡張メタデータ・プロパティは、カスタマイズをサポートし、MARにパッケージ化できるファイル・タイプ(.jsffファイルや.jspxファイルなど)に対してサポートされます。
メタデータ・ドキュメントの拡張メタデータは、関連するリソース記述フレームワーク(RDF)ファイルに格納されます。RDFは、メタデータを定義するXMLフレームワークの定義に使用されるW3C標準です。メタデータ・ドキュメントに関連付けられるRDFファイルは、プロパティ・インスペクタを使用して最初のプロパティ値を指定するときに作成されます。JDeveloperがStudio開発者ロールの場合にのみ、拡張メタデータ・プロパティは編集できます。「カスタマイズ開発者」ロールでは、RDFファイルは読取り専用です。
RDFファイルは、mdssysディレクトリに格納されます。たとえば、記述されるメタデータが/myapp/data/page1.jspxとしてファイル・システムに格納される場合、対応する拡張メタデータ・ドキュメントは/myapp/data/mdssys/mdx/page1.jspx.rdfとして格納されます。その後、拡張メタデータ・ドキュメントを対応するメタデータ・ベース・ファイルとともにパッケージ化して、同じデプロイメント・プロファイルに追加する必要があります。MARデプロイメント・プロファイルの作成の詳細は、41.3.2項「デプロイメント・プロファイルの作成方法」を参照してください。
|
注意: 拡張メタデータ・ドキュメントを直接編集することはできません。プロパティ・インスペクタを使用してください。 |
拡張メタデータ・プロパティを使用して、メタデータ・ファイル(.jspxファイルなど)に含まれていない追加のメタデータ情報を提供できます。JDeveloperでメタデータ・ファイルを開くと、プロパティ・インスペクタに拡張メタデータ・プロパティが表示されます。JDeveloperをStudio開発者ロールで使用している場合は、プロパティ・インスペクタを使用してこれらのプロパティを編集できます。
たとえば、なんらかのフォームのメタデータ・ファイルを外部の顧客に配信するとします。メタデータ・ファイルとともに、作成者、題目、内容、形式、権利などファイルに関する追加情報を提供する必要があります。メタデータ・ファイルの拡張メタデータ・プロパティ・ファイルを作成することで、これらの情報を提供できます。
拡張メタデータ・プロパティを編集する手順:
Studio開発者ロールを使用してJDeveloperを起動します。
JDeveloperで、適切なアプリケーションとプロジェクトを開きます。
アプリケーション・ナビゲータで、拡張メタデータ・プロパティを編集するオブジェクトを選択します。
構造ウィンドウで、適切な要素(通常はルート要素)を選択します。
プロパティ・インスペクタで、適切なノードを展開してプロパティを編集します。
選択したコンポーネントの値のプロパティ・インスペクタを表示するには、「表示」メニューから「プロパティ・インスペクタ」を選択します。
目的のプロパティの値を編集して、[Enter]を押します。
「ファイル」メニューから、「保存」を選択して作業内容を保存します。
メタデータ・ファイルの拡張メタデータ・プロパティを編集した場合は、アプリケーションのデプロイ時に、拡張メタデータ(またはRDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
拡張メタデータ・プロパティを使用して、実行時にメタデータのどの部分をカスタマイズできるか、および誰がメタデータのコンテンツをカスタマイズできるかについての情報を提供することもできます。
デフォルトでは、.jspxページに追加できるすべてのコンポーネントは、ランタイム・カスタマイズを許可するように事前構成されており、暗黙的なユーザー・カスタマイズをサポートしています(表の列順の変更など)。作成するすべてのページおよびフラグメントもデフォルトではカスタマイズできるように構成されます。ユーザー・カスタマイズの詳細は、第40章「実行時のユーザー・カスタマイズの許可」を参照してください。
カスタマイズできるようにコンポーネントが事前構成されている場合、さらに変更を加えて実行時のデザインタイムのカスタマイズを可能にする必要はありません。このようなコンポーネントを.jspxページで使用する場合、デフォルトでカスタマイズ可能になっています。
アプリケーションの要件に応じて、次の状況でカスタマイズ・プロパティを変更する必要があります。
カスタマイズを許可するように構成されているコンポーネントの場合、デフォルト設定をオーバーライドしてカスタマイズを禁止できます。
カスタマイズを許可するように構成されていないコンポーネントおよびメタデータ・オブジェクト(.jspxページなど)の場合、設定をオーバーライドしてカスタマイズを許可できます。
カスタマイズを許可するように構成されているコンポーネントの場合、オプションで、実行時にカスタマイズを実行できるユーザーを制限することができます。
カスタマイズ・プロパティを編集する場合は、アプリケーションのデプロイ時に、拡張メタデータ(RDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
また、サブツリーのルートをカスタマイズ禁止にマーキングすることによって、コンポーネントのサブツリー全体のカスタマイズを制限できます。そのサブツリーの個別のコンポーネントにカスタマイズ可能のマークを付けて、その特定のコンポーネントのカスタマイズを許可できます。
プロパティ・インスペクタのカスタマイズ・グループには、実行時にオブジェクトをカスタマイズできるかどうか、および誰がカスタマイズを実行できるかを指定する2つのプロパティがあります。任意の要素にCustomizationAllowedプロパティを設定して、カスタマイズできるかどうかを指定できます。CustomizationAllowedByプロパティは、要素をカスタマイズできるユーザーを制御します。JDeveloperを使用してシード・カスタマイズを実装する場合、これらの設定は強制されませんが、実行時にアプリケーションをカスタマイズする場合は強制されます(実行時のデザインタイムのカスタマイズ)。
たとえば、2つのパネルで構成される.jspxページがあり、パネル1のコンテンツにはランタイム・カスタマイズを許可する必要があり、パネル2のコンテンツには許可する必要がないとします。パネル1ではCustomizationAllowedにtrueを設定し、パネル2ではfalseを設定します。ページ全体でランタイム・カスタマイズを許可する必要がある場合は、.jspxページ・ルートのCustomizationAllowedにtrueを設定します。
カスタマイズ・プロパティを編集する手順:
Studio開発者ロールを使用してJDeveloperを起動します。
JDeveloperで、適切なアプリケーションとプロジェクトを開きます。
アプリケーション・ナビゲータで、カスタマイズ・プロパティを編集するオブジェクトを選択します。
構造ウィンドウで、適切な要素を選択します。
プロパティ・インスペクタで、カスタマイズ・ノードを展開してカスタマイズ・プロパティを編集します。
選択したコンポーネントの値のプロパティ・インスペクタを表示するには、「表示」メニューから「プロパティ・インスペクタ」を選択します。
プロパティの値を編集して、[Enter]を押します。
たとえば、.jspxファイルでランタイム・カスタマイズを許可する場合、ファイルを選択してCustomizationAllowedプロパティをtrueに設定します。
「ファイル」メニューから、「保存」を選択して作業内容を保存します。
任意でスタンドアロン注釈ファイルを使用して、カスタマイズを指定のタイプのコンポーネントに対して許可するかどうかを指定できます。このファイルを使用すると、インスタンスではなく要素型に基づいてカスタマイズ・プロパティを設定できます。特定のインスタンスに対して明示的にtrueまたはfalseを設定して、指定のタイプの設定をオーバーライドできます。例39-10に、サンプルのスタンドアロン注釈ファイルの内容を示します。
例39-10 スタンドアロン注釈ファイルの内容
<?xml version="1.0" encoding="UTF-8"?>
<grammarMetadata xmlns="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:md="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:mmd="http://xmlns.oracle.com/bali/xml/metadata/model"
xmlns:mds="http://xmlns.oracle.com/mds"
namespace="http://www.oracle.com/mds/restrictCustomizations">
<elementMetadata elementName="orderDetail">
<attributeMetadata attributeName="itemTypeRef">
<mds:customizationAllowedBy>sales admin</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="description">
<mds:customizationAllowed>true</mds:customizationAllowed>
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="title">
<mds:customizationAllowed>true</mds:customizationAllowed>
</attributeMetadata>
</elementMetadata>
<elementMetadata elementName="bankTransfer">
<mds:customizationAllowed>false</mds:customizationAllowed>
</elementMetadata>
<elementMetadata elementName="order">
<mds:customizationAllowed>true</mds:customizationAllowed>
<attributeMetadata attributeName="paymentRef">
<mds:customizationAllowedBy>sales</mds:customizationAllowedBy>
</attributeMetadata>
<elementMetadata elementName="itemDetail">
<attributeMetadata attributeName="itemsRef">
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
</elementMetadata>
</elementMetadata>
</grammarMetadata>
スタンドアロン注釈ファイルを使用する場合、これをadf-config.xmlファイルのMDSに登録する必要があります。例39-11に示すように、adf-config.xmlファイルのmdsc:type-configセクションにmdsc:standalone-definitionsセクションを作成します。
例39-11 adf-config.xmlのstandalone-definitionsセクション
<?xml version="1.0"?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:mdsc="http://xmlns.oracle.com/mds/config">
<mdsdata>
<mdsc:mds-config version="11.1.1.000" >
<mdsc:type-config>
<mdsc:type-definitions>
<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>
<mdsc:mds>/oracle/mds/TypeSeven.xml</mdsc:mds>
<mdsc:mds>/oracle/mds/TypeEight.xml</mdsc:mds>
<mdsc:file>typefile7.xsd</mdsc:file>
<mdsc:file>typefile8.xsd</mdsc:file>
</mdsc:type-definitions>
<mdsc:standalone-definitions>
<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>
<mdsc:mds>/oracle/mds/standAloneSeven.xml</mdsc:mds>
<mdsc:mds>/oracle/mds/standAloneEight.xml</mdsc:mds>
<mdsc:file>standAloneFile7.xsd</mdsc:file>
<mdsc:file>standAloneFile8.xsd</mdsc:file>
</mdsc:standalone-definitions>
</mdsc:type-config>
....
</mdsc:mds-config>
</mdsdata>
</adf-config>
カスタマイズしたアプリケーションで実行時にセッションごとにカスタマイズ構成(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ドキュメントを参照してください。
フィルタ実装でsessionOptionsFactoryをADFに登録して、リクエストのライフサイクルでMDSセッションが作成される前に、ADFが実装から変更済セッション・オプションを取得できるようにします。
例39-12に、sessionOptionsFactoryの実装方法を示します。この例では、adf-config.xmlファイルで指定されたカスタマイズ構成に関係なく、siteカスタマイズ・レイヤーのみを使用する変更済カスタマイズ構成をセッションに設定します。詳細は、oracle.mdsのJavadocを参照してください。
例39-12 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());
}
}
