Oracle® Fusion Middleware Oracle WebCenter Portal開発者ガイド 11g リリース1 (11.1.1.7.0) B72084-02 |
|
![]() 前 |
![]() 次 |
この章では、WebCenter Portal: Frameworkアプリケーションのアーキテクチャ、コンポーネントおよび機能について概説します。この章の内容は、次のとおりです。
WebCenter Portal: Frameworkアプリケーションはポータルです。エンド・ユーザーから見ると、ポータルは、タブなどのナビゲーション・フォームで編成されたページを持つWebサイトです。各ページには、階層的に関連したサブページのネストを含めることができます。どのページにも複数のポートレット、タスク・フローやその他の要素を含めることができるので、ユーザーは1箇所で様々な情報やツールにアクセスできます。管理者は、新しいページの追加、ルック・アンド・フィールの変更などにより、実行時にポータルを変更できます。委任管理により権限が与えられている場合、個々のユーザーはポータルのビューの変更もできます。
図8-1にポータルの例を示します。ここには、ナビゲーション(タブ、ブレッドクラム、リンク)、コンテンツ(ポートレット、タスク・フロー、イメージ)、管理機能などが含まれています。
ポータルのエンド・ユーザーは、ポータル・ページのパーソナライズされたビューも表示できます。パーソナライズされたビューとは、そのユーザーについて収集された情報に基づいたコンテンツで変更されたビューのことです。たとえば、書籍販売サイトでユーザーが最近数冊の探偵小説を購入したことを覚えていて、次回そのサイトにログインした際には、その情報に基づいて類似の探偵小説を推奨したりします。第66章「WebCenter Portalアプリケーションのパーソナライズ」を参照してください。
ポータルでは、整合性のとれたWebベースの統合インタフェースを使用して、種々のコンテンツとアプリケーションがユーザーに表示されます。ポータルの管理者とユーザーはポータルをカスタマイズでき、ユーザー・プリファレンスやパーソナライズに基づいてコンテンツを表示できます。各ポータルは、Web上でのポータルの実行に必要なすべてのリソースを備えたWebアプリケーションに関連付けられています。
図に示されているように、ポータルの一部の主要要素には、ページやサブページ、ナビゲーション、委任管理とその他のセキュリティ機能、実行時カスタマイズおよびパーソナライズが含まれています。
検索: エンタープライズおよびWebベースの検索機能
コンテンツの統合: Oracle WebCenter Contentなどのエンタープライズ・コンテンツ管理システムとの統合によるコンテンツの作成、管理、およびポータルへの配信。
シングル・サインオン: これにより、ユーザーは一度でポータル内のすべてのアプリケーションにログオンできます。
ルック・アンド・フィールの管理: これにより、開発者はカスタム・ページのテンプレートを作成でき、ユーザーはポータルのカスタマイズに様々なスキンを適用できます。ポータルには、ルック・アンド・フィールをポータル内で確実に整合性のとれたものにするツールが備わっています。
Oracle WebCenter Portal: Frameworkにより、ページ階層やナビゲーション・モデルなどのポータル固有の多くの機能がFrameworkアプリケーションに追加されます。この項では、その詳細を説明します。
WebCenter Portal: Frameworkアプリケーション・テンプレートを使用してFrameworkアプリケーションを作成すると、フレームワークが自動的に組み込まれます。これ以上の手順は不要です。第5.2項「Frameworkアプリケーションの作成」も参照してください。
注意: 非ポータルFrameworkアプリケーションのFrameworkアプリケーションへの移行は、サポートされていません。 |
Oracle WebCenter Portal: Frameworkにより、多くのポータル固有の機能がFrameworkアプリケーションに追加されます。WebCenter Portal: Frameworkアプリケーション・テンプレートを使用して新しいアプリケーションを作成する場合には、これらの機能がデフォルトで備わっています。第5.1項「アプリケーション・テンプレートとは」も参照してください。
このフレームワークで提供される基本機能は次のとおりです。
ページ階層: 従来のADFページ・セキュリティでは、ページごとにページ・セキュリティを管理できました。しかし、ポータルには通常多くのページが含まれており(場合によっては数百ページに及ぶこともある)、個別ページへのアクセスの指定は必ずしも実用的ではありません。ページの階層は、ページ間の親子関係により、ページをツリー構造に編成します。この階層構造により、ページからサブページにセキュリティ設定を簡単に伝播または継承することが可能になります。第8.5.1項「ページ、ページ・テンプレートおよびポータルのページ階層の理解」を参照してください。
ナビゲーション・モデル: ナビゲーション・モデルは、ポータルに表示されるナビゲーション・ユーザー・インタフェースにバックエンド・データを提供します。ナビゲーション・モデルは、ページ、タスク・フロー、外部サイト、ポートレットおよび特定のコンテンツ・アイテムへのナビゲーションを制御する幅広いAPIを備え、柔軟性が非常に高くなっています。このようなAPIにより、ナビゲーション・ユーザー・インタフェースをレンダリングする方法をすべての面において管理できます。たとえば、ポータル・ページやページ・テンプレートに簡単なEL式を記述すると、ツリー・ナビゲーションUIを追加できます。また、WebCenterではナビゲーション・モデルの構成および変更のための実行時ツールも提供しています。第8.5.3項「ナビゲーション・モデルおよびナビゲーション・レジストリの理解」を参照してください。
ナビゲーション・レジストリ: ナビゲーション・レジストリは、ユーザーがリソース・マネージャを使用して、実行時にナビゲーションに追加できる一連の要素を定義します。第16章「リソース・マネージャの追加および使用」および第10章「ポータル用のナビゲーション・モデルの構築」も参照してください。
委任管理: 委任管理は、ユーザー・ロールに基づいてポータル・リソースを保護するメカニズムを提供します。たとえば、1つのロール(マネージャなど)のユーザーにすべてのポータル機能へのアクセスを許可し、それ以外のロール(従業員など)のユーザーには特定の機能へのアクセスを拒否できます。ページ階層は、委任管理ではプライマリ・コンテナになります。設計時および実行時のどちらの環境においても、ページ階層に委任管理を適用すると、特定のセキュリティ割当てがページとサブページの階層に自動的に伝播されます。第68章「WebCenter Portal: Frameworkアプリケーションの保護」を参照してください。
カスタマイズ: ユーザーは、ポートレットの追加や削除、スキンの変更、ポータルのレイアウトの際配置などにより、独自のポータル・ページをカスタマイズできます。第16章「リソース・マネージャの追加および使用」を参照してください。
ページ・テンプレート – ページ・テンプレートにより、ページ全体のレイアウトを定義してページに適用し、ポータル全体で一貫したレイアウトを作成できます。テンプレートを使用してページを作成すると、すべてのページで定義済のレイアウトが継承されます。詳細は、第11章「ポータルのルック・アンド・フィールの設計」を参照してください。『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のページ・テンプレートの使用に関する項も参照してください。
カタログおよびカタログ・レジストリ: カタログは、タスク・フロー、ポートレット、コンテンツ・アイテム、および実行時にアプリケーションに追加できるその他の要素の任意のコレクションです。カタログ・レジストリは、リソース・カタログに含めることができる一連のアイテムを定義します。第15章「リソース・カタログの作成と管理」を参照してください。
スキン: スキンは、ポータル内のルック・アンド・フィールを整合させるためにアプリケーション・コンポーネントの色、フォント、イメージ、および高さや幅など一部のディメンションの詳細を定義します。第14章「スキンの作成および管理」を参照してください。
ポータル・プリファレンス: デフォルトのナビゲーション・モデル、ページ・テンプレート、その他のコンポーネントなどポータル向けのデフォルト・プリファレンスを変更できます。第8.7項「デフォルトのポータル・プリファレンスの変更」を参照してください。
JDeveloperには、ポータル開発用のツールが備わっています。このツールには、ページ階層の作成および変更用エディタ、ナビゲーション・モデル、カタログおよびカタログ・レジストリ、ページ・テンプレート、ページ・スタイル、スキン、委任管理などがあります。さらに、実行時ツールが提供され、これによりエンド・ユーザーと管理者はこれらの機能の一部を実行できます。第8.11.2項「実行時WebCenter Portal管理コンソール」も参照してください。
ポータルのライフ・サイクルとは、開発から本番サーバーへのデプロイメントまでのポータルを作成する過程のことです。このライフ・サイクルには、ソフトウェア開発者、コンテンツ・モデラー、コンテンツ・コントリビュータ、IT管理者、ポータル・サイト管理者などの多くの人々が関与します。ポータルのライフ・サイクルにおける全ステージの管理に関する詳細は、第9章「WebCenter Portalのライフ・サイクルの理解」を参照してください。
WebCenter Portal: Frameworkアプリケーション・テンプレートを使用して、JDeveloperで新しいフレームワーク・アプリケーションを作成します。アプリケーション・テンプレートはJDeveloperの標準機能で、ポータル・テンプレートでは必要なポータルのコンポーネントと機能でアプリケーションを構成するだけで済みます。
ヒント: Frameworkアプリケーション・テンプレートは、基本的に旧バージョンのWebCenterのFrameworkアプリケーション・テンプレートと同じですが、特定のポータル固有の機能が追加されています。さらに、これらのポータル機能の他に、Frameworkアプリケーションにはタスク・フロー、データ・コントロール、セキュリティ機能、ADF Faceレイアウト・コンポーネントなどの従来のFrameworkアプリケーションに備わっていたすべての機能が含まれます。 |
Frameworkアプリケーション作成の基本的な手順は、5項「Frameworkおよびポートレット・プロデューサ・アプリケーションの作成」を参照してください。
この項では、理解しておく必要のあるポータルの主な機能について説明します。
この項では、Oracle WebCenter Portal: Frameworkの3つの関連項目である、ページ、ページ・テンプレート、およびページ階層について説明します。
ポータルは1ページ以上で構成されており、ページはポータルの構造や編成において重要な役割を果たします。通常、ページはタスク・フロー、ポートレット、コンテンツなどの1つ以上のエンティティのコンテナです。また一般に、ページにはナビゲーション・ツリー、タブ、ブレッドクラムなどのナビゲーション・インタフェースが含まれます。Frameworkアプリケーションでは、oracle/webcenter/portalapp/pages
フォルダの下にあるポータル・プロジェクトに一連のデフォルト・ページが格納されています(図8-2を参照)。これらのページは編成上の理由で配置されていますが、新しいページについては必ずしもこのページ・フォルダ下に作成する必要はありません。
注意: ページ階層で使用されるページは、 |
ページ・テンプレートを使用すると、全ページにわたって共通にするビュー要素を指定できます。ページ・テンプレートとは、ADFレイアウト・コンポーネントやその他の要素を含むJSPXファイルのことです。一般に、ページ・テンプレートは、ヘッダー、フッターおよびコンテンツ領域によりページ・レイアウトを定義します。また、ページ・テンプレートでは、通常、ページのナビゲーションUIの配置とスタイルを指定します。たとえば、すべてのページに同じタブのセットを入れる場合や、各ページにツリー・ナビゲーション・パネルとブレッドクラムを表示する場合には、テンプレートにこれらのコンポーネントを追加できます。
ヒント: ページ・テンプレートは、それを使用するページによって参照されます。基礎となるページ・テンプレートを変更すると、そのテンプレートを参照するすべてのページで自動的に変更内容が継承されます。 |
ページ・テンプレート・フォルダは、図8-3に示されているように、oracle/webcenter/portalapp/pagetemplates
にあります。このフォルダには、すぐに使用できるデフォルトのページ・テンプレートが2つ格納されています。
ページ階層とは、一連の親子関係によってページを配置する論理的な構造で、ここではどのページでも1ページ以上のサブページを含むことができます。この階層モデルはポータルの構造全体の定義に使用できるだけでなく、子ページにその親に指定されているセキュリティ・ポリシーを継承させることもできます。各階層にセキュリティ・ポリシーを伝播するページの機能は、ページごとにセキュリティを設定する必要がないため、数十ページまたは数百ページもの非常に大型のポータルには特に便利です。新しいページを作成すると、それがページ階層内で格納された場所に基づいて、そのセキュリティ・ポリシーが自動的に設定されます。
ページ階層ファイルは、図8-4に示されているように、oracle/webcenter/portalapp/pagehierarchy
にあります。
注意: ページ階層ファイルは、ページ階層構造を定義するメタデータが含まれるXMLファイルです。これらのファイルを直接編集することはお薦めしません。次に説明するように、ページ階層エディタを使用して、ページ階層の作成や操作を行ってください。 |
基本的なページ階層モデルは、WebCenter Portal: Frameworkアプリケーション・テンプレートで作成されたアプリケーションに含まれています。JDeveloperでページ階層エディタを使用してページ階層を変更できます。このエディタにアクセスするには:
図8-4に示すアプリケーション・ナビゲータで、ポータル・プロジェクトを開きます。
pagehierarchy
フォルダを右クリックします。
メニューから「ページ階層の編集」を選択します。
ヒント: ページ階層エディタは、ポータル・ページ・ファイル(JSPXファイル)を右クリックしてメニューから「ページ階層の編集」を選択するか、ページ階層ファイルを直接開いても起動できます。 |
ポータルにページを作成した後、エディタを使用してサイト構造を作成します。アプリケーション・ナビゲータのoracle/webcenter/portalapp
フォルダ内の任意の場所からページ階層エディタにページをドラッグ・アンド・ドロップして(一度に1ページまたは数ページ)、希望する階層に配置できます。
または、階層ペインの上に配置された「追加」ボタンを使用できます。このボタンをクリックすると、プロジェクト内からページを選択できるダイアログがポップアップ表示されます。このページは、図8-5に示されているように、現在エディタで選択されているページの子として追加されます。
エディタでは、ツリー表示内のページ・ノードをドラッグ・アンド・ドロップで簡単に再配置できます。階層が大きい場合には、階層内のページを右クリックして「親ページの変更」を選択し、「親ページの変更」ダイアログを使用すると便利です。このダイアログを使用すると、選択済ページの新しい親を個々のウィンドウから選択でき、大きすぎて一度に表示できない階層内をスクロールする必要がなくなります。
ヒント: ページ階層エディタのノードを右クリックし、「ページに移動」を選択して関連付けられているJSPX(ポータル・ページ)ファイルを開きます。 |
注意: ページ階層内に作成する新しい各レベルには、 |
図8-6に、最上位レベルのページ、「Benefits」(福利厚生)、「Careers」(キャリア)、「Payroll」(給与)および「Location」(場所)を含む単純な人事管理サイトの構造を示します。「Benefits」、「Careers」および「Location」の各ページには、複数の子ページがあります。
ポータルを実行すると、この階層は図8-7に示すように表示されます。この例では、ナビゲーション・バーが表示されるデフォルトのページ・テンプレートが使用されています。このバーは、ページでタブのようなリンクとしてレンダリングされます。このナビゲーションUIは、ページ・テンプレートに追加されたため、そのテンプレートを使用するすべてのページに同様に表示されるようになります。デフォルトのナビゲーション・コンポーネント以外に、ナビゲーション・ツリー、ブレッドクラム、ページ・テンプレートへのナビゲーションUIのその他のスタイルなどを追加できます。多くの場合、テンプレートには2つ以上のナビゲーション・コンポーネントが含まれます。
ページ・テンプレートの詳細は、第11章「ポータルのルック・アンド・フィールの設計」を参照してください。デフォルトのナビゲーション・モデルおよびナビゲーション・モデルとユーザー・インタフェースの作成の詳細は、第10章「ポータル用のナビゲーション・モデルの構築」を参照してください。
ページ階層の詳細は、第68.6.2項「ページ階層の構築」を参照してください。
設計時に、ページ階層エディタでポータルのページにセキュリティを設定できます。前述のとおり、ページ階層ではページ間(親子)の構造的関係が定義されているため、子ページがその親のセキュリティ・ポリシーを継承できます。
注意: ADFページ・セキュリティ・モデルまたは階層構造のWebCenter Portalページ・セキュリティ・モデルで、ページを保護できます。ページのページ階層への追加は、ページが階層セキュリティ・モデルにより保護されることを意味します。第68.6項「ページ階層セキュリティ・エディタの使用」も参照してください。 |
図8-8に示すように、ページ階層エディタには、ページに関するロールベースのセキュリティ・ポリシーを指定する「セキュリティ」セクションがあります。このセキュリティ・インタフェースによって、ポリシーを継承するか委任するかを決定できます。継承を指定すると、そのページのセキュリティ・ポリシーがその親ページから継承されます。セキュリティを委任すると、そのポリシーが親のセキュリティより優先され、セキュリティを継承しているすべての子ページにそのポリシーが伝播されます。
ヒント: 小さな南京錠のアイコンが横に表示されているページは、継承されたセキュリティの設定が上書きされます。つまり、委任されたセキュリティが指定されているページを示す際にこのアイコンが表示されます。 |
たとえば、図8-8では、Payrollページは、管理者がページに完全にアクセスできるように構成されますが、ページの表示やパーソナライズが可能なのは認証されたユーザーのみです。匿名ユーザーは、このページにはまったくアクセスできません。第8.5.3項「ナビゲーション・モデルおよびナビゲーション・レジストリの理解」で、ページへのセキュリティ・ポリシーの設定方法に応じて、ナビゲーションUIの表示も影響を受けることについて説明します。この例では、「Payroll」ページを使用できるのが管理者と認証されたユーザーのみであるため、ナビゲーションUIは認証されたユーザーと管理者にのみ「Payroll」ページへのリンクを表示します。その他のすべてのユーザーには、「Payroll」リンクは表示されません。
ナビゲーション・モデルとページ階層を区別することは重要です。最初に、ページ階層では、ページ間の親子関係を指定します。以前に説明したように、ページは1つ以上の子ページを保有できます。次に、ページ階層では、階層を縦断して親ページから子ページ(サブ・ページ)に継承されるセキュリティ・ポリシーを考慮します。ページ階層のみがページ間の関係を指定することに注意してください。タスク・フロー、ポートレットおよび外部リンクなどの他のリソースをページ階層に含めることはできません。
ページ階層では、管理者が大量のページを備えたポータルのセキュリティを容易に制御できるセキュリティ継承モデルが提供されます。たとえば、100ページのポータルの場合、ページ階層のルートにセキュリティ・ポリシーを指定すると、100ページすべてがそのポリシーを継承します。次に、ルートの下のページの設定を変更する場合、変更した設定がそのページのすべてのサブページに伝播します。また、継承された設定を無視して、階層の任意の場所にある個々のページにセキュリティ設定を適用することもできます。
それに対して、ナビゲーション・モデルはナビゲーションの構造を定義し、ナビゲーション・データを記録し、アプリケーションのビュー・レイヤーにそのデータを提供します。ページ階層はページのみで構成されているのに対して、ナビゲーション・モデルはタスク・フロー、ページ、外部リンクなどの多様なリソースで構成できます。
ここで重要なのは、ナビゲーション・モデルが制御する要素(ページ、リンク、タスク・フローなど)に適用されるセキュリティ・ポリシーをナビゲーション・モデルが認識している点です。認証されたユーザーに特定のページを表示する権限がない場合、デフォルトでは、ナビゲーション・モデルはそのページへのナビゲーション・リンクをすべて非表示にします。ポータルで定義されたセキュリティを備えていないリソース(外部リンクなど)には、開発者が手動で表示を制御する必要があります。それを実行する1つの方法として、リソースの表示を制御する(表示/非表示)際に、ページまたはページ・テンプレートにEL式を追加する方法があります。詳細は、第13章「ポータル・ナビゲーションの視覚化」を参照してください。
たとえば、ポータル・ページにナビゲーションUIが含まれる場合、そのUIはナビゲーション・モデルに、ユーザーがどのページまたはその他の要素にナビゲートできるか、ポータルの現在のナビゲーション状態は何かなどについて問い合せます。最初の質問では、UIが表示できるリンクを通知します。2番目の問合せでは、そのリンクの表示方法をUIに通知します。ナビゲーション・ビューがツリーの場合、モデルはUIに現在選択されているページなどを通知します。これにより、ツリーUIは、開いているフォルダ、選択されたページなどとして、そのページを正確に表すノードを表示できます。
JDeveloperでは、ナビゲーション・エディタを使用してナビゲーション・モデルを変更します。エディタを開くには、図8-9に示すように、navigations
フォルダでdefault-navigation-model.xml
ファイルをダブルクリックします。
navigation-registry.xml
ファイルは、ユーザーがナビゲーション・モデルを作成または編集する際にリソース・マネージャで使用します。レジストリは、作成または変更するモデルに含められるすべてのアイテムのスーパーセットを定義します。1つのアプリケーションに対して複数のナビゲーション・モデルを作成できますが、1つのアプリケーションが持つことのできるナビゲーション・レジストリ・ファイルは1つのみです。ナビゲーション・モデル、ナビゲーション・エディタおよびレジストリの詳細は、第10章「ポータル用のナビゲーション・モデルの構築」を参照してください。
図8-10に示すように、デフォルトのナビゲーション・モデルには、「ページ階層」というノードが含まれています。デフォルトでは、このノードはpagehierarchyフォルダ内のデフォルトのページ階層ファイルpages.xml
を指します。このノードはナビゲーション・モデルにページ階層構造を参照するように指示し、ナビゲーションUIがレンダリングされるようにその構造をナビゲーションUIに伝えます。前述の図8-7に示されているように、デフォルトUIはページ階層をタブのようなリンクで表示します。このモデルが提供する情報により、各リンクにマウス・ポインタを置くとドロップダウン・メニューにサブページのリンクが表示されます。
ナビゲーション・モデルには数種類のナビゲーション要素を含めることができます。これまでの説明のとおり、モデルにはページ階層と単独ページの両方を含めることができます。また、外部Webページや特定のコンテンツへのリンクなど、その他の要素へのナビゲーションも作成できます。
詳細は、第10章「ポータル用のナビゲーション・モデルの構築」を参照してください。
カタログでは、レイアウト・コンポーネント、タスク・フロー、ポートレット、ドキュメントなど、権限のあるユーザーが実行時に追加できる関連性のない他の要素グループの集まりを指定します。Oracle WebCenter Portalのコンポーザは、実行時にカタログを使用して、権限のあるユーザーがポータル・ページに追加できる要素を判別します。
Frameworkアプリケーション・テンプレートには、デフォルトのリソース・カタログ(default-catalog.xml
)およびカタログ・レジストリ・ファイル(catalog-registry.xml
)が含まれています。これらのファイルは、oracle/webcenter/portalapp/catalogs
にあります。
ユーザーが実行時にコンポーザを使用してページを編集すると、デフォルトのカタログ・ファイルは、ページに追加できるすべてのアイテムを指定します。カタログ・レジストリ・ファイルは、ユーザーがリソース・カタログを作成または編集する際にリソース・マネージャで使用します。レジストリは、作成または変更するカタログに含められるすべてのアイテムのスーパーセットを定義します。
1つのアプリケーションに対して複数のカタログを作成できますが、1つのアプリケーションが持つことのできるカタログ・レジストリ・ファイルは1つのみです。詳細は、第15章「リソース・カタログの作成および管理」を参照してください。
開発時に、リソース・カタログ・エディタを使用して既存のカタログを編集できます。このエディタを開くには、図8-12に示すように、アプリケーション・ナビゲータのcatalogs
フォルダ内にあるカタログ・ファイル(default-catalog.xml
など)を開きます。
新規カタログを作成するには、「ファイル」メニューから「新規」を選択します。「新規ギャラリ」ダイアログで、「Web層」ノードの下の「ポータル」を選択します。次に、「アプリケーション・リソース・カタログ」を選択して「OK」をクリックします。「アプリケーション・リソース・カタログの作成」ダイアログを使用して、新規カタログを作成します。
ヒント: リソース・カタログ・エディタを使用して、ナビゲーション・レジストリを編集することも可能です。 |
図8-13にリソース・カタログ・エディタを示します。
図8-14に実行時管理ツールのリソース・カタログ・エディタを示します。
たとえば、複数の部署のそれぞれに個別のカタログを作成できます。
ヒント: 個々のカタログ・エントリはユーザーのロールに基づいて表示/非表示にできます。 |
設計時にアプリケーション・ナビゲータに表示される、その他のフォルダは次のとおりです。
images: ページ・テンプレートが参照するイメージが格納されています。
WEB-INF: Webアプリケーションが使用する構成ファイルが格納されています。これらのファイルは、通常、すべてのADFベースのWebアプリケーションに見られる典型的なファイルです。
Page Flows: adfc-config.xml
構成ファイルが格納される、もう1つの標準ADFフォルダです。
デフォルトでは、複数のファイルがアプリケーション・ナビゲータのビューから除外されています。これらのファイルが除外されているのは、ファイルを編集する必要がほとんどないためです。ただし、そのようなファイル編集を行うユース・ケースがいくつかあるため、ファイルをJDeveloper UIに追加しなおせるようにしておく必要があります。
除外されたファイルを配置するには:
プロジェクト・フォルダを右クリックし、メニューから「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「プロジェクトのソース・パス」ノードの「Webアプリケーション」を選択します。
図8-15に示すように、「除外」タブを選択します。
除外リストから要素を選択し、「削除」をクリックして除外リストから削除します。これで、目的の要素がアプリケーション・ナビゲータの該当するフォルダに自動的に追加されます。
例では、navigation-renderer.jspx
ファイルを使用して、ページ・テンプレートに即してリソースをレンダリングします。外部URLをページ内で表示する方法を変更する場合、まず除外リストからnavigation-renderer.jspx
を削除すると、アプリケーション・ナビゲータのpages
フォルダの下にこれが表示されるようになります。次に、そのページを開き、必要に応じて編集します。
バナー、ナビゲーション、フッターなどコンテンツ領域周りの特定の表示要素を追加して、ルック・アンド・フィールを設計できます。ポータル構造に適したルック・アンド・フィールを決めると、その設定をページ・テンプレートとして保存して、ポータル作成時に使用できます。さらに、同じ設定をポータル内のページ全体で使用できます。ページ・テンプレートとページ・スタイルを使用すると、ポータル内のページがある程度統一できます。第11章「ポータルのルック・アンド・フィールの設計」を参照してください。
ポータルのカスタム・スキンも開発できます。スキンは、アプリケーション全体に対して1箇所に指定されるCSS 3.0構文に基づいたスタイルシートです。アプリケーションの各コンポーネントに対してスタイルシートを用意したり、各ページにスタイルシートを挿入するのではなく、アプリケーション全体に対して1つのスキンを作成できます。各コンポーネントで自動的に、スキンで記述されているスタイルが使用されます。スキンを使用すると、外観を変更するために、設計時にポータル・ページを変更する必要がなくなります。第14章「スキンの作成および管理」を参照してください。
基本的なルック・アンド・フィールの設計は設計時にJDeveloperで作成できますが、管理者や適切なアクセス権限を持つユーザーはリソース・マネージャを使用して、アプリケーションがデプロイされた後もポータルのルック・アンド・フィールの開発を続行できます。たとえば、リソース・マネージャを使用して、ページの追加と削除、ナビゲーション・ユーザー・インタフェースの追加、ページ・テンプレート、スキンおよびページ・スタイルの変更などを実行できます。これらおよびその他のリソース・マネージャ機能の詳細は、第16章「リソース・マネージャの追加および使用」を参照してください。
Frameworkアプリケーションには、ポータルの特定のデフォルト・コンポーネントを指定する一連のプリファレンスが用意されています。この項では、そのプリファレンスとデフォルト値の変更方法について説明します。
表8-1に、ポータルのプリファレンスとそのデフォルト設定を示します。
表8-1 デフォルトのプリファレンス
プリファレンス | デフォルト設定 |
---|---|
ナビゲーション・モデル |
|
リソース・カタログ |
|
ページ・テンプレート |
|
ナビゲーション・レンダラ |
|
スキン |
|
設計時にデフォルト・プリファレンスを変更するには、adf-config.xml
ファイルを直接編集します。このファイルをJDeveloperで見つけるには、アプリケーション・ナビゲータの「アプリケーション・リソース」部分を開きます。次に、図8-16に示すように、「ディスクリプタ」フォルダおよびADF META-INFフォルダを開きます。
たとえば、デフォルトのナビゲーション・モデル・ファイルを変更するには、このプリファレンスの値を編集します。
<portal:preference id="oracle.webcenter.portalapp.navigation.model" desc="Default Navigation Model" value="/oracle/webcenter/portalapp/navigations/default-navigation-model.xml" resourceType="navigation" display="true" />
プリファレンスは、実行時にも、「管理」ページの「構成」タブで変更できます。このページから、ランタイム・アプリケーションのデフォルトのページ・テンプレート、スキン、リソース・カタログおよびナビゲーション・コンポーネントを構成できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のアプリケーションのデフォルトの構成に関する項を参照してください。
反復開発とは、開発プロセスを促進できる生産性の機能のことです。反復開発では、統合WebLogic ServerでFrameworkアプリケーションを実行しながら、JDeveloperでこのアプリケーションに変更を加えて保存し、ブラウザの現在のページをリフレッシュするだけで、その変更の効果を確認することができます。Frameworkアプリケーションでは、反復開発機能はデフォルトで有効になっています。詳細は、第1.5.3項「反復開発の有効化」を参照してください。
ラウンドトリップ開発とは、メンテナンスや拡張のため、デプロイされた実行時ポータルからJDeveloperにリソースを戻すことができる機能および技法です。JDeveloperでリソースを編集した後、リソース・マネージャを使用して、デプロイされたポータルにリソースをアップロードし直すことができます。WebCenter Portalのラウンドトリップ開発機能は、アプリケーション全体を再度デプロイすることなくポータル・リソースを変更する、簡単で便利な方法を提供します。
ラウンドトリップ開発の詳細は、第16.3項「ポータルの実行時管理の有効化」および第16.4項「リソースのラウンドトリップ開発の有効化」を参照してください。
「アプリケーション・ソース」フォルダは、ポータルを作成する際にJDeveloperで生成される2つの最上位ポータル・プロジェクト・フォルダの1つとして表示されます。アプリケーションに対して記述するJavaクラスの他に、「アプリケーション・ソース」に含まれる内容は次のとおりです。
oracle.webcenter.portalapp: ページ、ページ・テンプレート、ページ・カタログ、ナビゲーションのXML定義ファイルが格納されています。ページ定義ファイルは、ADFバインディング、ページ・パラメータおよび権限の設定を指定します。ページ定義ファイルは、ページやページ・テンプレートに使用される様々なマッピングおよびバインディングを指定します。たとえば、ページ定義ファイルはページの親および子ページがある場合、それらを指定します。また、ページで許可されている操作などの、セキュリティ・ポリシー情報も指定します。デフォルトのページ定義ファイルは、ポータルのページをページ階層に追加すると、自動的に作成されます。
portal: リソース・バンドル、ソース・コードおよびその他のJavaアーティファクトが含まれます。
META-INF: データ・バインディングとページ・テンプレート・メタデータを指定するファイルが格納されています。
Oracle WebCenter Portal: Frameworkには、多くの興味深い実行時機能が用意されています。
統合WebLogic Serverを開発環境(JDeveloperを介してポータルを実行)で使用する場合、デフォルトでは実行時(リソース・マネージャを使用)のポータルに対する変更は再デプロイメントの際に破棄されます。たとえば、リソース・マネージャを使用してページに対する資格の追加、レイアウトの変更、ナビゲーション・モデルの変更などを実行した場合、その変更はアプリケーションを次に再デプロイしたときに保持されません。リソース・マネージャの詳細は、第16章「リソース・マネージャの追加および使用」を参照してください。
注意: この項の情報は、開発環境で統合WebLogic Serverとともに実行するポータルに対してのみ適用されます。ポータルを本番環境にデプロイする際には、実行時の変更が破棄されることはありません。 |
注意: JDeveloper環境で作業する開発者の便宜を考慮して、カスタマイズはデフォルトでは保持されません。実行時にファイルを変更すると、新しいバージョンのファイルがMDS書込みディレクトリに書き込まれます。すると、この新規バージョンが、JDeveloper内で最優先バージョンとなります。その時点で、JDeveloperで設定を変更し、ブラウザで「リフレッシュ」をクリックしても、変更は表示されません。したがって、JDeveloperで作業する際には、実行時のカスタマイズを保持しない方が便利で自然です。 |
デフォルトの動作を変更し、実行の間に実行時のカスタマイズを保持することは可能です。たとえば、特定のテスト用シナリオを有効にする際に、そのようにできます。アプリケーションのデプロイメント(実行)間にカスタマイズを保持できるようにするには:
「アプリケーション」メニューから、「アプリケーション・プロパティ」を選択します。
「アプリケーション・プロパティ」ダイアログで、「実行」ノードの下の「MDS」を選択します。
「ディレクトリ・コンテンツ」で、「アプリケーションの実行間でカスタマイズを維持」を選択し、デフォルト(各実行前にカスタマイズが破棄される)を無効にします。詳細は、図8-19を参照してください。
WebCenter Portal管理コンソールを使用すると、リソース、サービス、セキュリティおよびポータルの構成について作業できます。WebCenter Portal管理コンソールは、URL(http
://<server
>:<port
>/<context_root
>/admin
)にあり、図8-20に示されています。
ヒント: WebCenter Portal管理コンソールのデフォルトのURLを変更するには、 |
「リソース」タブ(リソース・マネージャ)の詳細は、第8.11.4項「ポータル・リソースの実行時の編集」および第16章「リソース・マネージャの追加および使用」を参照してください。セキュリティの詳細は、第68章「WebCenter Portal: Frameworkアプリケーションの保護」を参照してください。
ロール・ベースのセキュリティ・ポリシーは、ビジターが表示および操作(作成、削除、更新など)できるページ、リソースおよびナビゲーション要素を制御します。設計時(JDeveloper)ページ・エディタでは、第8.5.2項「ポータルのページの保護」で説明するように、ページまたはページ階層でこれらのポリシーを設定できます。Oracle WebCenter Portal: Frameworkでは、次の方法でこれらのセキュリティ・ポリシーを順守します。
ページ(およびタスク・フローなどその他の特定のリソース)は、表示する権限を持つユーザーのみに表示されます。同じ原理が、権限付与、作成、削除、更新、パーソナライズなど、ユーザーがページ上で実行できる操作に対して保持されます。
リソース(ページ、タスク・フローなど)へのナビゲーションは、認証ユーザーがそのページを使用できない場合、非表示になります。たとえば、「Payroll」ページへのアクセスが許可されていないユーザーの場合、そのページへのリンクはすべてのナビゲーション・ユーザー・インタフェースで表示されません。
リソース・カタログ内で使用できるリソースは、セキュリティ・ポリシーに応じて調整されます。タスク・フローなどの特定のリソースに対するアクセス権を持たないユーザーの場合、そのリソースはリソース・カタログに表示されません。
WebCenter Portal管理コンソールには、次のようなポータル固有の機能を実行時に使用可能にする「リソース」タブが表示されます。
ページ
ページ・テンプレート
ナビゲーション・モデル
リソース・カタログ
スキン
ページ・スタイル
コンテンツ・プレゼンタ表示テンプレート
マッシュアップ・スタイル
データ・コントロール
タスク・フロー
ポータル・ユーザーは、リソース・マネージャを使用して、リソースまたはアプリケーション全体を実行時環境からダウンロードし、JDeveloperで編集して、デプロイ済アプリケーションにアップロードして戻すこともできます。リソースのダウンロードおよびアップロードの詳細は、第16.3項「ポータルの実行時管理の有効化」および第16.4項「リソースのラウンドトリップ開発の有効化」を参照してください。
リソース・マネージャの「ソースの編集」機能により、ランタイム・アプリケーションでリソースのソース・コードを編集できます。たとえば、ポータル・リソース(ページ・テンプレートなど)をアップロードすると、リソース・マネージャで直接それを編集できます。それには、リソースを選択して「編集」メニューから「ソースの編集」を選択します。図8-21に示すように、ソース編集ウィンドウが表示されます。
注意:
|
Frameworkアプリケーション・ウィザードを実行すると、大量のプロジェクト・アーティファクトが構成され、プロジェクト・ディレクトリにインストールされます。JDeveloperでは、プロジェクトの合理化されたビューが表示されます。ポータル・プロジェクトは、ファイルシステムで直接確認することもできます。
この項では、Frameworkアプリケーションの編成方法とその理由について説明します。
JDeveloperで新しいFrameworkアプリケーションを作成すると、自動的に大量のファイルがプロジェクトに配置されます。JDeveloperの「アプリケーション・ナビゲータ」ビューに、編成されたこれらのファイルが表示されます。
アプリケーション・ナビゲータを見ていくと、図8-22に示すように、まずFrameworkアプリケーションが1つのプロジェクト(デフォルトでPortalと呼ばれる)で構成されていることがわかります。当然、この名前は、アプリケーションの作成時やその後いつでも変更できます。プロジェクト内のファイルは、ほとんどが<application_root>/<project_root>/public_html/oracle/webcenter/portalapp
ディレクトリにあります。
図8-22 「アプリケーション・ナビゲータ」のWebCenter Portal: Frameworkアプリケーション
アプリケーション内に保存されているファイル間における次の違いを理解することは重要です。
注意: XMLファイルなどの一部のファイルは |
<application_root>/<project_root>/public_html/oracle/webcenter/portalapp
ディレクトリに格納されたファイルの特徴は次のとおりです。
メタデータ・サービス(MDS)リポジトリにデプロイされます。
ポータル・リソースとして登録でき、実行時にリソース・マネージャで管理できます。
通常、WebCenterの権限を使用して保護されます(ポータル・リソースの場合)。
<application_root>/<project_root>/public_html
の他の場所に格納されたファイルの特徴は次のとおりです。
アプリケーションWARファイルにデプロイされます。
ポータル・リソースとして登録できないため、リソース・マネージャで管理できません。
アーティファクトのネイティブの権限クラスで保護されます。
Frameworkアプリケーションがこのように構造化されているため、自分のページを作成する際に十分な情報を得た上で決定できるということを理解することが重要です。場合によっては、特にJSPXページを使用して、oracle/webcenter/portalapp
でページを作成しないことがあります。それは、アプリケーションでのページの使用目的に応じて変わります。
プロジェクト・ファイルをファイル・システムに配置する最も簡単な方法は、アプリケーション・ナビゲータでファイルまたはフォルダを選択し、「編集」メニューから「パスのコピー」を選択します。この機能では、ファイルやフォルダへのパスがクリップボードに配置されるので、それをコマンド・シェルやファイル・ブラウザに貼り付けられます。
図8-23にサンプルFrameworkアプリケーションのファイルシステムの編成を示します。プロジェクトのファイルの多くは、public_html
フォルダの下に編成されます。
図8-23 ファイルシステム上のWebCenter Portal: Frameworkアプリケーションの例
見てわかるように、JDeveloperでは多少異なる、より合理化されたビューが提供されます。詳細は、次の第8.12.3項「JDeveloperでのポータル・プロジェクトの表示」を参照してください。
JDeveloperのプロジェクト・ビューでは、開発者が使用しそうなプロジェクト・ファイルが表示されます。これらのファイルには、ページ、ページ階層、ナビゲーション・モデル、ページ・テンプレート、カタログ、XML構成ファイル、Javaソース・ファイル、イメージなどがあります。
JDeveloperでは、ポータル・プロジェクトは図8-24に示すように、「アプリケーション・ソース」および「Webコンテンツ」の2つのフォルダに編成されます。
「アプリケーション・ソース」フォルダは、主に、ソース・コードおよびページ定義ファイルのリポジトリです。第8.9項「「アプリケーション・ソース」フォルダについて」も参照してください。
「Webコンテンツ」フォルダには、ページ、ページ階層、ナビゲーション・モデルなどWebプロジェクトを構成するすべてのファイルが格納されています。これらは、Frameworkアプリケーションを開発する際に積極的に作成および変更できるファイルです。
図8-25は、「Webコンテンツ」フォルダの基本的な構造を示しています。作成および変更するファイルの多くは、oracle/webcenter/portalapp
サブ・フォルダに格納されています。フォルダの内容(カタログ、ナビゲーション、ページ階層、ページ、スキンおよびページテンプレート)により、ポータルの基本的なコンポーネントが構成されます。これらのポータル・コンポーネントの詳細は、第8.12.1項「WebCenter Portal: Frameworkアプリケーションの編成の理解」を参照してください。
ヒント: アプリケーション・ナビゲータでローカルのファイル・システムの階層を表示するには、「プロジェクト」パネルの「ナビゲータの表示オプション」アイコンをクリックして「ディレクトリでグループ化」を選択します。 |
PortalWebAssetsプロジェクトには、HTMLやイメージ・ファイルのような静的アプリケーション・リソースが含まれます。静的リソースを個々のプロジェクトに分離することによって、これらのリソースを専用サーバーにデプロイすることが可能となります。詳細は、第5.4項「PortalWebAssetsプロジェクトの理解」を参照してください。
oracle/portalapp/pages/home.jspx
ファイルは、新しいFrameworkアプリケーションのデフォルトのホーム・ページです。この項では、デフォルトのホーム・ページを別のページ、またはURL、ポートレット、タスク・フローなどのナビゲート可能なリソースに変更する方法を説明します。
デフォルトのFrameworkアプリケーションには、index.html
ファイルがあり、これはポータル・プロジェクト・ディレクトリに格納されています。この索引ファイルには、次のリダイレクト文が記述されています。
<meta http-equiv="refresh" content="0;url=./faces/pages_home" />
注意:
|
URL要素pages_home
は、ページ階層で指定された"home"ページを参照します。(一意のIDとなるように、接頭辞"pages_
"をフォルダ名に追加します。)図8-26に示すように、「ナビゲーション」ダイアログで「フォルダの内容の挿入」チェック・ボックスが選択されています。「フォルダの内容の挿入」オプションにより、指定されたフォルダ(この場合、"home
")がフォルダの内容に置換されます。したがって、この例では、ポータルはページ階層内の"home
"というフォルダを検索します。また、ページ階層はナビゲーション・モデルでは要素として指定されます。
デフォルトのポータル・ホーム・ページの指定方法を理解できるよう、ナビゲーション・モデルではデフォルトでpages
というデフォルト・ノードが作成されます。このノードのナビゲーション・パスは、図8-26に示すように、ページ階層ファイルのpages.xml
を指しています。
pages.xml
へのナビゲートの際、home
というノードが検索されます。そのノードのパスは、図8-27に示すように、/oracle/webcenter/portalapp/pages/home.jspx
です。
デフォルトのホーム・ページを変更するには、index.html
のリダイレクト文をナビゲーション・モデルで参照される別のリソースのプリティURLに変更します。たとえば、新しいホーム・ページを作成してそれを共通のユース・ケースにリダイレクトするとします。新しいホーム・ページを自分のホーム・ページに指定するには、index.htm
l
のリダイレクトを新しいページのプリティURLに変更します。(ページのリンク要素を作成するには、ナビゲーション・モデルで新しいページをドラッグします。)たとえば、ナビゲーション・モデルのリンクIDがTheHomePage
の場合には、次のようにします。
<meta http-equiv="refresh" content="0;url=./faces/TheHomePage" />
ここでは、.faces/TheHomePage
がプリティURLであり、これはナビゲーション・モデルで指定したリンク要素を指します。
この例では、ブラウザでのポータルへのアクセスは次のURLを使用します。
http://myserver:myport/MyPortalApp-Portal-context-root
図8-29に示すように、このポータルでは新しいホーム・ページからのコンテンツが記載されたホーム・ページがレンダリングされています。
統合Weblogic Serverのインスタンスのデフォルト索引ページは、index.html
です。新しいポータル・プロジェクトには、Web Content
フォルダにデフォルトでこのファイルが含まれています。
デフォルト索引ファイルのindex.html
を別のファイルに変更する場合、2つの選択肢があります。このデフォルト索引ファイルを変更する1つの方法では、次のようにweb.xml
ファイルの<welcome-file-list>
要素を編集します。
<welcome-file-list> <welcome-file>/index.html</welcome-file> </welcome-file-list>
あるいは、「実行構成の編集」の「デフォルト」ダイアログ・ボックスを使用してデフォルトの索引ページを変更する方法もあります。このダイアログにアクセスするには、プロジェクトのプロパティ・ダイアログを開き、「実行/デバッグ/プロファイル」オプションを選択します。「編集」をクリックして、図8-30に示すように、デフォルトの索引ページを変更できる、「実行構成の編集」の「デフォルト」ダイアログを表示します。
ログインまたはログアウト後にターゲット・ページを指定するには、例8-1に示すように、ポータル・プロジェクトのWebContent/WEB-INF/faces-config.xml
構成ファイルで<navigation-rule>
要素を編集します。ターゲット・ページを別のナビゲーション・リソースのプリティURLまたはFacesページに変更できます。
例8-1 ログインおよびログアウトに対するターゲット・ページの指定
<navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>login_success</from-outcome> <to-view-id>/pages_home</to-view-id> <redirect/> </navigation-case> <navigation-case> <from-outcome>logout_success</from-outcome> <to-view-id>/pages_home</to-view-id> <redirect/> </navigation-case> </navigation-rule>
たとえば、ログアウト後のページにユーザーをリダイレクトするには、次の手順に従います。
ログアウト後のページを作成して、それにコンテンツを追加します。例:
/oracle/webcenter/portalapp/pages/postlogout.jspx
faces-config.xml
のナビゲーション・ルールを変更します。例:
<navigation-case> <from-outcome>logout_success</from-outcome> <to-view-id>/oracle/webcenter/portalapp/pages/postlogout.jspx</to-view-id> <redirect/> </navigation-case>
正常なログアウト後に、ユーザーは指定されたページにリダイレクトされます。
この項では、Frameworkアプリケーションの開発に関係する基本的なタスクの一部を示します。
ソース・コントロール、共通データベースおよび共通コンテンツ・リポジトリを使用して、統合チーム開発環境を設定します。
WebCenter Portal: Frameworkアプリケーション・テンプレートを使用して、Frameworkアプリケーションを作成します。
ポータルを構成する最上位ページおよびサブ・ページの概要を作成して、ポータルの構造全体を設計します。
ポータルのセキュリティを考慮します。ユーザーにアクセスを許可するページを決定します。これらの決定に対応する適切なロールを作成します。
ポータル全体のルック・アンド・フィールについての検討を開始し、ページ・テンプレートで作業を開始します。
ポータルに含めるWebCenter Portalのサービスを検討します。たとえば、Wiki、ブログ、アクティビティ・ストリームなどを追加するかどうかを検討します第2.4項「Oracle WebCenter Portal: Servicesの概要」を参照してください。
ポータル全体の構造に基づいてページを作成します。この時点ではページは空白ですが、ページを作成するとページ階層を作成できるようになります。
ページ階層エディタを使用して、ページ階層を作成します。
ナビゲーション・モデルを作成します。ユーザーがナビゲートできるリソースの種類を検討します。たとえば、ページ、外部URL、タスク・フロー、コンテンツ・フォルダなどについて検討します。
ナビゲーションUIをページ・テンプレートに追加します。Oracle WebCenter Portal: Frameworkでは、ナビゲーションUIの複数のオプションが用意されています。最も一般的に使用されるオプションは、ページ・テンプレートで直接ELを使用するというものです。また、WebCenterにはナビゲーション・タスク・フローおよびナビゲーション用Java APIが用意されています。
ページ階層にセキュリティ・ポリシーを適用します。階層のルート・ノードにポリシーを適用して開始します。これらのポリシーは、階層内のすべてのページに継承されます。次に、個々のページまたは階層全体のサブブランチでセキュリティ設定を調整します。
ページ自体に対し、ポートレット、タスク・フロー、コンテンツ、その他の機能の追加および構成を行います。