11 ポートレットの概要
この章の内容は次のとおりです。
ポートレットについて
ポートレットは再利用可能なWebコンポーネントで、多数の異なるソースからコンテンツを描画できます。ポートレットには静的HTMLコンテンツから、複雑なWebサービスや処理負荷の高いアプリケーションのためのJavaのコントロールまで、あらゆるものを含めることができます。
ポートレットは、複数のソースからのデータを意味のある関連付けられた形式で表示する手段を提供します。ポートレットでは、他のWebサイトからの抜粋の表示、主要情報のサマリーの生成、検索の実行および多様なデータ・ソースの情報を収集したコレクションへのアクセスなどを実行できます。様々なポートレットを単一のページに配置できるため、ユーザーはコンテンツが実際には複数のソースからのものであっても単一のソースとして利用できます。
ポートレットはイベントやその他の手法を使用して相互に通信することもできます。また、単一のポートレットが複数のインスタンスを持つこともできます。つまり、単一のポータル内の、さらには複数のポータルにまたがる様々なページ上に表示できます。ページ設計者はそれぞれの関係者のニーズに合せてポートレットをカスタマイズできます。正しい権限を持つエンド・ユーザーはさらに独自の要件に合せてポートレットをパーソナライズできます。
WebCenter Portalは、業界標準であるJSR 286を使用したポートレットの開発をサポートします。また、Oracle JSF Portlet Bridgeを使用して既存のJSFアプリケーションからポートレットを作成することもできます。詳細は、「ポートレット・リソースについて」を参照してください。
ポートレットの構造について
ポートレットの構造とは、ページ上でのポートレットの視覚的な表現です。
図11-2は、WebCenter Portalの典型的なポートレットに表示されるポートレットの構造の側面をいくつか示しています。同じポートレットでも別のアプリケーションに表示された場合は違って見えることがあるので注意してください。
代表的なポートレットの構造の主な側面(図11-2に示されているのはその一部です)は次のとおりです。
-
ポートレット・クロム - ヘッダー、シャドウ、サイズ変更、「アクション」メニュー、アイコンを含む、ポートレットを囲む様々な種類の飾りの総称。
-
ポートレット・ヘッダー - ポートレット・アイコン、タイトル、「アクション」メニュー、「カスタマイズ」アイコン、および「パーソナライズ」アイコンを表示するポートレットの領域。
-
ポートレット・アイコン - ポートレットを視覚的に特定するためのポートレット・ヘッダー内の小さいイメージ。
-
ポートレット・タイトル - ポートレットの目的を示すポートレット・ヘッダー内のテキスト。エンド・ユーザーは実行時にこのタイトルをパーソナライズして特定の用途に合った、わかりやすいタイトルにすることができます。
-
パーソナライズ・アイコン - エンド・ユーザーがポートレットを変更して自分だけに見えるようにできるポートレット・ヘッダー内のアイコン。
「パーソナライズ」アイコンは、認証を受けたユーザー(つまりログインしているユーザー)にのみ表示されます。パブリック・ユーザーまたは認証を持たないユーザーには表示されません。ユーザーがポートレットの表示をパーソナライズできるようにするには、なんらかのアプリケーション・セキュリティを実装する必要があります。
-
カスタマイズ・アイコン - アプリケーション管理者が実行時にポートレットのデフォルト設定を変更できるようにするポートレット・ヘッダー内のアイコン。これらの内容はすべてのユーザーに表示されます。
典型的なカスタマイズ設定はポートレット・タイトルです。アプリケーション管理者は実行時にポートレット・ヘッダーに表示されるタイトルを決定できます。
-
処理アイコン - クリックすると「アクション」メニューを表示する、ポートレット・ヘッダー内のアイコン。
-
処理メニュー - ユーザーがポートレット上で実行できる様々な処理を一覧するメニュー。ポートレットがユーザー・レベルでキャッシュされると、ポートレットへのアクセス権限が実行され、ユーザーはポートレットをパーソナライズできます。アクションには、「移動」、「削除」、「リフレッシュ」、「上へ移動」、「下へ移動」などがあります。「処理」メニューからは、「バージョン情報」、「ヘルプ」、「構成」、「印刷」などのポートレットで使用できるその他のポートレット・モードへもアクセスできます。
ページにポートレットを追加したユーザーがポートレット・ヘッダーを表示しないことを選択した場合、「処理」メニューは、マウス・ロールオーバー上に表示されるフェードインおよびフェードアウトのツールバーに表示されます。
-
サイズ変更ハンドル - ユーザーがポートレットのサイズを変更できるようにするポートレット右下の領域。
-
スクロール・バー - ポートレットに指定された幅と高さにポートレット・コンテンツがおさまらない場合に、表示され、最初に表示されていないコンテンツへのアクセスを可能にします。
-
ポートレット・コンテンツ - ポートレット・ロジックによって決定されているポートレットの実際のコンテンツ。
ページでレンダリングされるポートレット構造は、次の2つのファクタで制御されます。
-
ポートレット開発者によって決定されるポートレットそのもののロジック。これには、ポートレットがどのポートレット・モードをサポートしているかも含まれます。
-
設計時にページにポートレットを追加したアプリケーション開発者によって決定される、ポートレットをページにバインドするポートレット・タグの属性。
たとえば、ポートレットを設計する場合、ポートレット開発者はポートレットにヘルプ・モードを実装できます。ページ設計者がページにポートレットを追加する際に、ポートレット・プロパティisHelpModeAvailableを使用して、ポートレットの「アクション」メニューに「ヘルプ」コマンドを含めるかどうかを決定できます。ページ設計者がisHelpModeAvailableをfalseに設定した場合、「ヘルプ」コマンドは、ポートレット・ロジックで指定されていても「アクション」メニューには含まれません。逆に、ポートレット開発者がポートレットにヘルプ・モードを実装していない場合、isHelpModeAvailableがtrueに設定されていても、「ヘルプ」コマンドは、「アクション」メニューに表示されません。
ポートレット・リソースについて
アプリケーション内のポートレットは、Oracle製品やサード・パーティ・ベンダーなどの様々なソースに基づく可能性があります。
また、ポートレット・リソースには、JSR 286のWebCenter PortalのJavaポートレット・ウィザードを使用して構築されたカスタム構築ポートレットも含まれます。これらのリソースはそれぞれ異なる製品機能を提供し、対象とするユーザーの経験レベルも様々です。
この項には次のトピックが含まれます:
構築済ポートレットについて
Oracleでは、ユーザーが機能をポートレットとして公開できるようにすることで、他のOracleアプリケーションとの統合を提供しています。
概要
サポートされているアプリケーションは、次のとおりです。
-
Peoplesoft - PeoplesoftアプリケーションはWSRPポートレットとして公開できます。詳細は、『Oracle WebCenter Portalの管理』のPeopleSoftアプリケーションの統合に関する項を参照してください。
-
JD Edwards - JD Edwardsスタンドアロン・リージョンはポートレットとして公開できます。詳細は、『Oracle WebCenter Portalの管理』のJD Edwardsアプリケーションの統合に関する項を参照してください。
-
Oracle E-Business Suite - Oracle E-Business Suiteは、WebCenter Portalに追加できる、アプリケーション・ナビゲータ、お気に入り、ワークリストといった複数の構築済ポートレットを提供します。詳細は、『Oracle WebCenter Portalの管理』のE-Business Suiteアプリケーションの統合に関する項を参照してください。
- 他の構築済ポートレットは、オラクル社と、主要なシステム・インテグレータ、ソフトウェア・ベンダーおよびコンテンツ・プロバイダとの提携によって提供されます。
対象ユーザー
開発済のダウンロード可能なポートレットは、WebCenter Portalにプロデューサをダウンロード、インストールおよび登録する方法を理解しているポータル開発者が使用するのに最適です。これらのポートレットは、すべての経験レベルで使用可能です。
使用する場合
構築済ポートレットは、そのポートレットが提供する機能でニーズが満たされる場合や、すぐに利用できるパーソナライズのレベルで目的のタスクを十分に完了できる場合に使用します。
異なるユーザー・インタフェースが必要な場合や希望する機能のために複雑な設定が必要な場合など、ポートレットの拡張やパーソナライズが必要なときには、別の方法を検討してください。
Java Server Faces (JSF)ポートレットについて
JSFポートレットは、Oracle JSF Portlet Bridgeを使用してJSFアプリケーションから作成されます。
概要
Oracle JSF Portlet Bridgeを使用すると、アプリケーション開発者は、既存のJSFアプリケーションおよびタスク・フローをJSR 286 Javaポートレットとして公開できます。Oracle JSF Portlet Bridgeは、JSFアプリケーションとWebCenter PortalなどのWSRPポートレット・コンシューマとの統合を容易にします。
JSFポートレットでは、JSFアプリケーションとは別のソース・コードは必要ありません。これらのポートレットはOracle JSF Portlet Bridgeを使用して作成されるので、アプリケーションとポートレットの両方で1つのソースを維持するだけで済みます。同様に、ポートレット化されたJSFアプリケーションをデプロイすると、JSFポートレットも一緒にデプロイされます。したがって、Oracle JSF Portlet Bridgeを使用すると、アプリケーションとは別にポートレットを保存、管理、デプロイする必要がなくなります。
JSFポートレットの作成の詳細は、「Oracle JSF Portlet Bridgeを使用したJSFアプリケーションからのポートレットの作成」を参照してください。
対象ユーザー
Facesの知識があるアプリケーション開発者。
使用する場合
JSFポートレットは、アプリケーション開発者が、アプリケーション全体をホストしたり、同じものに対してポートレットを別に構築したりせずに、JSFアプリケーションまたはアプリケーション内の個々のタスク・フローからのコンテンツをポートレットとして表示する場合に最適です。ポートレット化すると、ポートレットの使用はWSRPプロデューサと同じです。
カスタムJavaポートレットについて
カスタムJavaポートレットとは、Java Portlet Specification 2.0 (JSR 286)を使用して、自分自身で作成するJavaのポートレットです。
概要
WebCenter Portalでは、規格に基づいたJSR 286 Javaポートレットの作成を簡単にするために、JDeveloperに宣言型ウィザードが用意されています。このウィザードは、ポートレットを作成するフレームワークの構成を支援します。
注意:
ポータルではOracle WebLogic PortalなどからのレガシーJSR 168ポートレットやWSRP 1.0ポートレットを使用できます。これらのポートレットは最初にJSR 286に変換する必要はありません。ただし、新しいJavaポートレットを作成する場合は、JSR 286を使用してパブリック・レンダラ・パラメータやポートレット・イベントなどの機能を利用することをお薦めします。
また、Oracle PDK-Javaポートレットもポータルで使用できます。
対象ユーザー
ウィザードの使用は簡単ですが、ポートレット・ロジックを最も上手に作成するのは、JSR 286の使用に慣れていて、プロデューサの構成を理解している経験と知識が豊富なJava開発者です。
使用する場合
要件を満たす構築済ポートレットや既存のJSFアプリケーションが見つからない場合は、カスタムJavaポートレットの使用を検討してください。
カスタムJavaポートレットは、非常に特化したビジネス・ルールやロジックがある、およびパーソナライズした認証、動的結果の精度の高い処理およびユーザー・インタフェースの完全な制御が必要な場合に使用します。
カスタムJavaポートレットの作成の詳細は、「JSR 286を使用した標準ベースのJavaポートレットの作成」を参照してください。
ポートレット・テクノロジ
新しいポートレットを作成する場合、使用できるテクノロジは何種類かあります。使用するテクノロジはいくつかの要因によって決まります。
-
コンポーネントを分散させる必要はありますか。
-
はい: 質問2に進みます。
-
いいえ: ポートレットは必要ありません。使用側のアプリケーションにローカルなOracle ADFタスク・フロー(または他のテクノロジ)を使用します。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFタスク・フローの作成」を参照してください。
分散環境では、デプロイメントがより複雑になるため、問題の追跡がより困難になる可能性があります。ただし、処理の負荷を複数のサーバーに分散したり、複数の異なるコンシューマがコンポーネントを使用できるようになります。
-
-
リモートで公開する必要がある既存のOracle ADFまたはJSFのページまたはタスク・フローはありますか。
-
はい: Oracle JSF Portlet Bridgeを使用して既存のコンポーネントを公開します。詳細は、「Oracle JSF Portlet Bridgeを使用したJSFアプリケーションからのポートレットの作成」を参照してください。
-
いいえ: 質問4に進みます。
このように既存のOracle ADFコンポーネントを使用すると、ポートレットの開発は非常に簡単になりますが、Oracle ADFを使用してポートレットを実装した場合、表11-1に示すような影響があることに注意してください。
-
-
既存のJSR 168またはJSR 286ポートレットはありますか。
-
はい: 既存のJSR 168またはJSR 286ポートレットを使用します。詳細は、WSRPプロデューサの登録に関する項を参照してください。
-
いいえ: 質問5に進みます。
WebCenter Portalでは、WebCenterコンシューマと完全な互換性があるJSR 168およびJSR 286ポートレットをWSRP経由で公開し、そのようなポートレットで、特定のコンシューマに固有の条件を想定しないことを前提としています。
-
-
WebCenter Portalコンシューマと正しく連携して動作する既存のOracle PDK-Javaポートレットはありますか。
-
はい: 既存のPDK-Javaポートレットを使用します。詳細は、「Oracle PDK-Javaポートレット・プロデューサの登録」を参照してください。
-
いいえ: 質問6に進みます。
-
-
コンポーネントを(インライン・フレーム内ではなく)直接コンシューマ・ページ内にレンダリングする必要はありますか。
-
はい: インライン・フレーム内へのレンダリングを要求するマークアップを使用しないJSR 286ポートレットを記述します。詳細は、「JSR 286を使用した標準ベースのJavaポートレットの作成」を参照してください。
-
いいえ: 質問7に進みます。
-
-
Oracle ADFを使用してコンポーネントを実装する必要はありますか。
-
はい: Oracle JSF Portlet Bridgeを使用し、Oracle ADFのページまたはタスク・フローをポートレットとして公開します。詳細は、「Oracle JSF Portlet Bridgeを使用したJSFアプリケーションからのポートレットの作成」を参照してください。
-
いいえ: JSR 286ポートレットを記述します。詳細は、「JSR 286を使用した標準ベースのJavaポートレットの作成」を参照してください。
Oracle ADFを使用してポートレットを実装するかどうかを決めることは、大まかに言えば、それを使用して通常のWebアプリケーションを実装するかどうかを決めることと同じです。ただし、Oracle ADFを使用すると、リモート・ポートレットの使用時に特有の(マークアップ、リソースおよびPPRに対する)ネットワーク・ホップとコンシューマに関する処理が追加で発生するため、ポートレットを使用しない場合に比べて、有効な選択肢にならない可能性があります。
また、Oracle ADFを使用してJava EEアプリケーションを開発することの具体的な利点について、OTNで提供されているOracle ADFの概要に関するホワイト・ペーパーを参照してください。Oracle ADFタスク・フローを使用することのもう1つの利点は、インライン・フレームでの実行時に問題が発生した場合、後からローカルで同じタスク・フローを実行できることです。
-
表11-1は、WebCenter Portalで使用するコンポーネントを実装する場合に、様々な基準にあわせて特定のポートレット・テクノロジを選択することでどのような影響があるかをまとめたものです。
表11-1 ポートレット構築テクノロジの比較マトリックス
| タイプ | ローカルのOracle ADFページとタスク・フロー | JSR 286ポートレット | JSFポートレット |
|---|---|---|---|
|
分散アーキテクチャ |
いいえ |
可。WSRP SOAP/HTTPを使用します。 |
可。WSRP SOAP/HTTPを使用します。 |
|
ナビゲーション/フロー制御のサポート |
宣言型ナビゲーションに対する包括的なサポートを提供します。 |
制限はありませんが、ポートレット開発者がおそらくサード・パーティ製のフレームワークを使用して実装する必要があります。 |
宣言型ナビゲーションに対する包括的なサポートを提供します。 |
|
UIの豊富さ |
多くのAJAX対応のコンポーネントで豊富なWebベースのUIを提供します。 |
制限はありませんが、ポートレット開発者がおそらくサード・パーティ製のフレームワークを使用して実装する必要があります。 |
多くのAJAX対応のコンポーネントで豊富なWebベースのUIを提供します。 |
|
セキュリティ: |
アプリケーションとの完全統合 |
WS-Securityを使用して伝播される、またはWSRPを使用してコンシューマによってアサートされるユーザー・アイデンティティ 認証チェックは開発者が実装する必要があります。 ユーザー・プロファイル情報はWSRPユーザー・プロファイル項目を使用して渡すことができます。 |
WS-Securityを使用して伝播されるユーザー・アイデンティティ。 認証はOracle ADFによって実装されます。 |
|
コンポーネント間通信(イベント) |
ADFコンテキスト・イベントにより、タスク・フローは通信できます。 |
JSR 286イベントを完全サポート。コンシューマのポートレット・イベントとADFコンテキスト・イベントとの間のポートレットとイベントのマッピング間での自動イベント配信を含みます。 |
ADFコンテキスト・イベントに加えてJSR 286ポートレットにより、ローカルな場合と同じようにタスク・フローの通信を可能にします。 |
|
コンシューマとコンポーネントとの間の対話処理(パラメータ) |
タスク・フロー入力パラメータは、各種ソースから値をとることができます。 |
JSR 286パラメータを完全サポート。コンシューマとの間でのパブリック・パラメータ値の受け渡し、およびポートレット間でのパラメータ値の自動共有を含みます。 |
タスク・フロー入力パラメータに加えてJSR 286ポートレットにより、ローカルな場合と同じにようにコンシューマ・アプリケーションの各種ソースから値を取得します。 |
|
パフォーマンスとキャッシュ |
コンポーネントはローカル・サーバー上で実行するため追加のネットワーク・ホップはありません。 |
リモート・コンポーネントは追加のネットワーク・ホップを必要とします。 リソースはコンシューマによってプロキシされます。 コンポーネントのパフォーマンスは実装によって異なります。 有効期限ベースおよび有効化ベースのキャッシュがサポートされています。その制御はポートレット開発者が行います。 |
リモート・コンポーネントは追加のネットワーク・ホップを必要とします。 多くのリソースがコンシューマを介してプロキシされます。 フレームワークは重い性質を持つため、単純なアプリケーションはパフォーマンスを重視するか、手作りのJSR 286相当とで比較されることになります。ただし、より複雑な機能を提供するアプリケーションについては、フレームワークを使用するパフォーマンス上のメリット(たとえば部分的なページ・レンダリング)がより明白になります。 JavaScript、CSSおよびその他のリソースは、ブラウザにキャッシュされます。キャッシュはフレームワークによって制御されます。 |
|
同時実行性 |
複数のタスク・フローが順次呼び出されます。 |
ポートレットはパラレルに呼び出されます。 |
ポートレットはパラレルに呼び出されます。 |
|
ジオメトリ管理 |
コンポーネントは、格納元のページで直接レンダリングされます。 |
ポートレットのジオメトリとインライン・レンダリングは(フレーム化されたレンダリングに対して)ポートレット開発者が制御します。 複雑なUIは、インライン・フレームでのレンダリングをより必要とする傾向があります。 |
ポートレットはインライン・フレームでレンダリングする必要があります。 |
|
JavaScriptの使用 |
JavaScriptは、豊富なユーザー経験を提供するフレームワークの基本部分として頻繁に使用されます。 通常、開発者はJavaScriptを記述する必要はありません。 |
JavaScriptの使用とパッケージ化のレベルはポートレット開発者によって制御されます。 開発者は、ポートレットがインラインでレンダリングされる場合にはJavaScriptの使用に関して特別に配慮する必要があります。 |
JavaScriptは、豊富なユーザー経験を提供するフレームワークの基本部分として頻繁に使用されます。 通常、開発者はJavaScriptを記述する必要はありません。 スクリプトはすべてコンシューマを介してプロキシする必要があります。 |
|
スキル要件/開発の容易さ |
ADF、およびおそらくJavaの知識が必要です。 ADFは、すべてのレイヤー間に統合フレームワークを提供します。 JDeveloperは、ADFアプリケーションを開発するための完全統合環境を提供します。これには、フレームワークのすべてのレイヤーの宣言オプションも含まれます。 |
Java、Javaポートレット、およびコンポーネントの実装に使用されるその他のフレームワークの知識が必要です。 開発時間は、サーブレット・ベースのコンポーネントの開発に必要な時間と同程度です。 |
ADF、およびおそらくJavaの知識が必要です。ADFが提供する豊富なUIと制御フレームワークにより、最も単純なアプリケーションを除くすべてのアプリケーションに関し、(手作りのポートレットに比べて)開発時間が短縮される可能性があります。 ADFは、すべてのレイヤー間に統合フレームワークを提供します。 JDeveloperは、ADFアプリケーションを開発するための完全統合環境を提供します。これには、フレームワークのすべてのレイヤーの宣言オプションも含まれます。 |
|
デバッグ |
JDeveloperはアプリケーション・コードをデバッグするための包括的なソリューションを提供します。 |
デプロイメントのリモートという性質によって、より困難です。 プロデューサは、コンシューマとプロデューサとの通信をモニターするためのツールを提供します。 JDeveloperはアプリケーション・コードをデバッグするための包括的なソリューションを提供します。 |
デプロイメントのリモートという性質によって、より困難です。 プロデューサは、コンシューマとプロデューサとの通信をモニターするためのツールを提供します。 JDeveloperはアプリケーション・コードをデバッグするための包括的なソリューションを提供します。 |
|
デプロイメント |
コンポーネントはクライアント・アプリケーションの一部としてデプロイされます。 アプリケーション全体を1つのEARファイルにパッケージ化してデプロイできます。 |
デプロイメントの分散された性質と、複数のアプリケーションによって複雑さが増します。 |
デプロイメントの分散された性質と、複数のアプリケーションによって複雑さが増します。 コンポーネントは必要に応じてスタンドアロンで簡単に実行できます。 |
|
サポート・レベル |
ADFフレームワークはOracle製品です。したがってサポートされています。 |
JSR 286プロデューサはOracle製品です。したがってサポートされています。 |
ADFフレームワーク、Oracle JSF Portlet Bridge、およびJSR 286プロデューサはOracle製品です。したがってサポートされています。 |
ポートレットとタスク・フロー
ポータルの作成時に共通する質問は、ポートレットとタスク・フローを使用する状況についてです。
ポートレットは再利用可能なWebコンポーネントで、多数の異なるソースからコンテンツを描画できます。ポートレットでは、静的HTMLから、複雑なWebサービスや処理負荷の高いアプリケーションのためのJavaのコントロールまで、どのようなものでも管理と表示が可能です。
1つのポートレットで複数のインスタンスを保持することもできます。つまり、1つのポータル内の各種ページにポートレットが表示され、ポートレットがWeb Services for Remote Portlets (WSRP)に対して有効な場合は複数のポータル間でも表示できます。特定のユーザーやグループのニーズに応えるようにポートレットをカスタマイズできます。
タスク・フローを使用すると、カスタマイズ可能なアプリケーションを、再使用可能なビジネス・ロジックのユニットで作成できます。これは、アプリケーションの制御フローをモジュール単位で定義するアプローチを意味します。それぞれのタスク・フローは、再利用可能な1つのビジネス・ロジックを表します。メモリーとトランザクションのスコープが分離されているため、タスク・フローとそれを囲むアプリケーションは分離されています。この分離より、Oracle WebCenter Portalのページ・エディタなどにタスク・フローを含めることができます。
タスク・フローは、制御フローのルール、アクティビティおよびマネージドBeanをカプセル化して、ビジネス・モジュールを実装します。WebCenter Portalを使用して構築されたポータルでは、簡単にタスク・フローを再利用できます。タスク・フローは、カスタマイズ可能な任意のWebCenter Portalポータル・ページにドラッグ・アンド・ドロップできます。このような意味で、タスク・フローは、任意のADFアプリケーションでの再利用や削除が可能な論理ポートレットとみなすことができます。
タスク・フローはビジネス・プロセスの高水準の実装ですが、データアクセスやビジネス・ロジックをホストすることはありません。そのためには、タスク・フローがデータ・コントロールや宣言バインディングと相互作用する必要があります。さらに、これらのデータ・コントロールやバインディングは、ADFビジネス・コンポーネント・フレームワークと相互作用します。
Oracle発行の標準JSR 329に従い、タスク・フローを標準ベースのポートレットとして公開できます。アプリケーションを改訂すると、ポートレットは、アプリケーションとともに必然的かつ自動的に更新されます。個別の開発プロジェクトは必要ありません。JSR 329をサポートするために、WebCenter Portalでは、Oracle JSF Portlet Bridgeが用意されています。Oracle JSF Portlet Bridgeの詳細は、「Oracle JSF Portlet Bridgeを使用したJSFアプリケーションからのポートレットの作成」を参照してください。
タスク・フローをポートレットとして消費する他に、タスク・フローをJSFアプリケーションで共有ライブラリとして消費してこれらのJSFフラグメントを直接埋め込むことができます。タスク・フローの周囲のトランザクションを、アプリケーションのそれ以外の機能と一緒にラップできます。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFタスク・フローの概説」を参照してください。
ポートレットとタスク・フローを使用する状況の詳細は、Oracle WebCenter & ADF Architecture Teamのブログを参照してください。
ポートレットの開発について
ポートレット・プロデューサはOracle JDeveloperで開発できます。
この項には次のトピックが含まれます:
ポートレット・プロデューサ・アプリケーション
この項には次のトピックが含まれます:
ポートレット・プロデューサ・アプリケーションについて
ポートレット・プロデューサ・アプリケーションは、Javaポートレットを作成およびデプロイすることに特化して構成されたアプリケーションです。
ポートレット・プロデューサ・アプリケーションに適したコンポーネントを簡単に見つけて使用できるようにするには、適切なテクノロジ・スコープを設定し、タグ・ライブラリを追加して、必要になるJavaクラスをクラス・パスに追加しておく必要があります。このようにしておくと、関連するコンポーネントがコンポーネント・パレットに取り込まれ、関連するコンテキスト・メニューがJDeveloperで使用できるようになります。
JDeveloperには、ポートレット・プロデューサ・アプリケーションの作成に適したスコープが設定され、適切なタグとJavaライブラリが追加されるアプリケーション・テンプレートが用意されています。「WebCenterポートレット・プロデューサ・アプリケーション」テンプレートを使用すると、Javaポートレットの作成用にスコープ設定された単一のプロジェクトを使用して、簡単にアプリケーションを作成できます。
ポートレット・プロデューサ・アプリケーションの作成方法
ポートレットを作成するには、まずポートレット・プロデューサ・アプリケーションを作成する必要があります。
「WebCenterポートレット・プロデューサ・アプリケーション」テンプレートを使用してアプリケーションを作成するには:
図11-4は、アプリケーション・ナビゲータ内に表示されている、単一のポートレット・プロジェクトを使用して新しく作成したポートレット・プロデューサ・アプリケーションを示しています。
Oracle JDeveloperのユーザー・インタフェース内で公開されるオプションは、ポートレットの開発に適したものに制限されます。
このアプリケーション内でポートレットを作成する方法の詳細は、「JSR 286を使用した標準ベースのJavaポートレットの作成」を参照してください。
ポートレット・モード
この項には次のトピックが含まれます:
ポートレット・モードについて
ポートレット・モードは、実行時機能をユーザーが確認できるようにするものです。WebCenter Portalは、次の標準ポートレット・モードをサポートします。
-
表示モード
-
編集モード
-
デフォルト編集モード
-
ヘルプ・モード
-
情報モード
WebCenter Portalは、サポートする一連の拡張モードを定義します。各種モードは、JSR 286ポートレットに使用できます。たとえば、JSR 286 Javaポートレットの作成ウィザードには、「印刷」モードがあり、これを使用してポートレットの印刷用のバージョンを使用できます。
コーディング・ポートレットをJSR 286にコーディングする場合は、portlet.xmlファイルに独自のカスタム・ポートレット・モードも宣言できます。これらを使用してポートレットで提供するその他の機能に対応できます。
カスタム・ポートレット・モードの定義は、特に、ポートレットを他のベンダーのポータル実装と相互運用する場合に役立ちます。これらのモードはすべてユーザーに提供できます。実際に、デフォルト編集モードのようなモードの提供をお薦めします。
注意:
サード・パーティのポータル製品には、プロデューサが提供できる各自の拡張モード・セット(JSR 286カスタム・モード)があります。サード・パーティまたはカスタム・ポートレット・プロデューサが提供する任意のカスタム・モードは無視されるため、サポートされません。
表示モード
ポートレットは表示モードを使用して他のポートレットとともにページ上に現れます。ポートレットといえば、ほとんどの人がこのモードを思い浮かべます。JSR 286ポートレットは表示モードを持つ必要がありますが、他のモードはオプションです。
ポートレットの開発時には、ページ上でポートレットの外観に影響を与える可能性のあるすべての要素(ポートレットのコンテナ・オブジェクトや、開発したポートレットがページを共有する他のポートレットなど)について検討する必要があります。たとえば、ポートレットをHTML表のセル内に配置するとします。ポートレットは、表のセル内でレンダリングできるコンテンツしか表示しないはずです。さらに、表のセルの実際のサイズは、エンド・ユーザー設定、ブラウザの幅、およびポートレットに表示されるコンテンツの量とスタイルによって変わる場合があります。
ポートレットのレンダリングに関するHTMLガイドライン
プレーンHTMLは最も基本的なポートレットのレンダリング方法であり、ポートレットの開発者に大きな柔軟性を提供します。リンク、フォーム、イメージ、表など、HTMLの表のセル内に表示できるほとんどの標準的なHTMLパラダイムを使用できます。HTMLが適切に作成されていない場合は、異なる複数のブラウザで表示したときに表示の一貫性がなくなり、ページの一部が表示されないこともあります。次のルールに従ってください。
-
標準HTMLを使用する - HTMLの公式な仕様はW3Cから入手できます。詳細は、
http://www.w3c.org/を参照してください。 -
長い複雑なHTMLは避ける - 使用するHTMLはサイトのパフォーマンスの印象に影響します。ユーザーは、リクエストしたページの表示にかかる時間に基づいてパフォーマンスを判断します。ブラウザには、HTMLを解釈して表示するための時間が必要です。ポートレットが複雑なHTMLをレンダリングしたり、サード・パーティのアプリケーションなど外部リソースを待機する場合は、ページのレンダリングが大幅に遅くなることがあります。
-
閉じていないタグや外部タグを避ける - ページはブラウザの動作の影響を受けるため、タグが正しく閉じていないとページの動作は予測不可能になります。
-
コンテナ・オブジェクトによって課される制限を考慮する - ポートレットが表のセルなどのHTML要素に含まれない場合、ポートレットがコンテナ内でレンダリングできることを確認する必要があります。たとえば、表のセルにポートレットを置く場合、これらは表への挿入時には表示されないためポートレット内でフレームを使用することはできません。
-
ポートレット・コンテンツを簡潔に保つ - 全画面のコンテンツを取得して、小さなポートレットから公開しないでください。ポートレットのコンテンツが小さくなりすぎて、小さなモニターではポートレットが使用不能になる場合があります。
-
ポートレットに固定幅のHTML表示を作成しない - ユーザーのページ上にポートレットが持つ列の幅を伝える方法はありません。与えられた空間よりも広い空間がポートレットに必要な場合、一部のブラウザでは、他のポートレットとオーバーラップする可能性があります。
-
長い、途切れのないテキスト行を避ける - 固定幅の表を使用した場合と同様の結果になります。一部のブラウザでは、他のポートレットとオーバーラップする可能性があります。
-
ページのサイズ変更時の動作を確認する - ブラウザ・ウィンドウをサイズ変更した際のポートレットの動作をテストし、ポートレットがブラウザ・ウィンドウの様々なサイズで動作することを確認してください。
-
デフォルト・ブラウザのフォント変更時の動作を確認する - エンド・ユーザーはどんなフォント・サイズでも好きなものを選択する可能性があり、彼らはいつでも変更する可能性があります。ポートレットは、その変更に対応する必要があります。
ポートレットのレンダリングに関するCSSガイドライン
ページ上のそれぞれのポートレットのフォントと色は、ユーザーが選択したスタイル設定に一致する必要があります。このために、これらのスタイル選択は、Cascading Style Sheet (CSS)を使用して自動的に埋め込まれます。その後、ポートレットは直接またはApplication Programming Interfac (API)を使用して、フォントと色の設定にアクセスします。
ブラウザによってCSS仕様の実装レベルが異なりますが、WebCenter Portalは、この仕様の非常に基本的なサブセットを使用して、整合性のあるフォントと色を実現します。CSSの実装レベルによってブラウザ間でのページの一貫性が影響されることはありません。CSSの使用に関する次のガイドラインを考慮してください。
-
ハードコーディングのかわりにCSSを使用する - ハードコーディングのフォントとカラーはお薦めしません。フォントと色をハードコーディングすると、エンド・ユーザーがページ・スタイルの設定を変更した場合に、ポートレットが不釣合いに見えることがあります。開発者はエンド・ユーザーが設定するフォントや色を予測できないため、ユーザーが選択した背景色と同じフォント色でハードコーディングする可能性があり、この場合、ユーザーにはポートレット・コンテンツが表示されなくなります。
-
絶対配置にCSSの使用は避ける - ユーザーは各自のポータル・ページをパーソナライズできるため、ポートレットがページ上の特定の位置に表示される保証はありません。
-
アクセシビリティの標準に従う - 必ず既存のアクセシビリティの標準に従って、スタイルシートを記述してください。詳細は、
http://www.w3c.org/TR/WCAG10-CSS-TECHSを参照してください。
編集モード
ポートレットは編集モードを備えており、これによってユーザーはポートレットの動作をパーソナライズできます。パーソナライズはこれらを実行するユーザーのみに表示され、他のユーザーには表示されません。編集モードには設定のリストがあり、ユーザーはその設定を変更できます。設定には、タイトル、コンテンツの種類、書式、情報量、フォーム要素のデフォルト、およびポートレットの外観や内容に影響する他のあらゆる要素が含まれます。
通常、ユーザーは、ポートレット・ヘッダーの「パーソナライズ」アイコンをクリックしてポートレットの編集モードにアクセスします(図11-5)。
ユーザーが「パーソナライズ」をクリックすると、同じブラウザ・ウィンドウに新しいページが表示されます。このポートレットは、通常、ポートレットの設定を選択するダイアログを表すWebページを作成します。設定を適用すると、自動的に元のページに戻ります。
編集モード操作に関するガイドライン
次のガイドラインに従って、編集モードでユーザーに公開する内容を管理してください。
-
ポートレットのタイトルをユーザーがパーソナライズできるようにする - 同じポートレットが同じポータル・ページに複数回追加されることがあります。ユーザーがタイトルをパーソナライズできると混乱を避けることができます。
-
キャッシュを使用する場合はコンテンツを無効化する - パーソナライズによってポートレットの表示やコンテンツに変更が生じた場合は、ポートレットのコンテンツがキャッシュから再生成されることを確認する必要があります。確認しないと、誤ったコンテンツが表示されることがあります。
-
編集モードを管理ツールとして使用しない - 編集モードは、エンド・ユーザーがポートレットの動作を変更するために使用します。プロデューサ設定の変更などの管理タスクが必要な場合は、そのタスク専用の安全なポートレットを作成してください。
デフォルト編集モード
ポートレットはデフォルト編集モードを備えており、アプリケーション管理者はこのモードを使用して、特定のポートレット・インスタンスのデフォルト動作を実行時にカスタマイズできます。デフォルト編集モードには設定のリストがあり、アプリケーション管理者はその設定を変更できます。設定には、タイトル、コンテンツの種類、書式、情報量、フォーム要素のデフォルト、またはポートレットの外観や内容に影響するあらゆる要素が含まれます。
パーソナライズは個々のユーザーのポータル・インスタンスに影響しますが、デフォルト編集モードで行われたカスタマイズはすべてのユーザーのポートレット・インスタンスに影響します。デフォルト編集モードは、ポートレットの表示内容と表示形式に対してシステム・レベルのデフォルトを定義するためのモードであるため、このモードを管理ツールとして使用したり、他のポートレットの管理に使用したりすることは避けてください。
アプリケーション管理者は、ページの編集時に、コンポーネントの「アクション・メニューの表示」から「カスタマイズ」を選択して、デフォルト編集モードにアクセスします(図11-6)。
ユーザーが「カスタマイズ」をクリックすると、同じブラウザ・ウィンドウに新しいページが表示されます。このポートレットは、通常、ポートレット・インスタンスの設定をカスタマイズするダイアログを表すWebページを作成します。設定を適用すると、ユーザーは自動的に元のページに戻されます。
デフォルト編集モード操作に関するガイドライン
デフォルト編集モードでアプリケーション管理者に公開する内容は、次のガイドラインに従う必要があります。
-
デフォルト編集モードを管理ツールとして使用しない - デフォルト編集モードは、アプリケーション管理者がポートレットの動作を変更するために使用します。プロデューサ設定の変更などの管理タスクが必要な場合は、そのタスク専用の安全なポートレットを作成してください。
デフォルト編集モードのボタンに関するガイドライン
整合性を維持し、ユーザーにとっても便利なように、次のボタンを次の順序でデフォルト編集モードに実装してください。
-
OK - アプリケーション管理者のカスタマイズを保存し、ポートレットを表示モードに戻します。
-
適用 - アプリケーション管理者のカスタマイズを保存し、現在のページをリロードします。
-
取消 - 変更を保存せずに、ポートレットを表示モードに戻します。
カスタマイズ値のレンダリングに関するガイドライン
カスタマイズ設定の変更に使用されるフォームを表示する場合、アプリケーション管理者が何度も設定を再入力せずにすむように値のデフォルト値を設定する必要があります。動作の整合性を維持するために、カスタマイズ値のレンダリングは次の順序で行います。
-
インスタンス設定 - ポートレット・インスタンスのシステム・デフォルトを問い合せて表示します。
-
ポートレット・デフォルト - システム・デフォルトのカスタマイズがない場合は、一般的なポートレットのデフォルトを表示しますが、空白の場合があります。一般的なポートレットのデフォルトはポートレットにハードコーディングされている場合がありますが、システム・デフォルトで上書きしてください。
ヘルプ・モード
ポートレットは、ヘルプ・モードを使用して、そのポートレットの機能と使用方法に関する情報を表示します。ユーザーはこのモードで、ポートレットおよびそのコンテンツと機能に関する有用な情報を検索できます。
ユーザーは、「アクション」メニューから「ヘルプ」を選択して、ポートレットのヘルプ・モードにアクセスします(図11-7)。
情報モード
ポートレットは情報モードを使用してユーザーに現在実行中のポートレットのバージョン、発行と著作権の情報、ポートレット開発者への連絡方法などの情報を提供します。登録が必要なポートレットは、情報モードからもWebベースの登録アプリケーションまたは連絡先情報にリンクできます。
ユーザーは、「アクション」メニューから「情報」を選択して、ポートレットの情報モードにアクセスします(図11-8)。
同じブラウザ・ウィンドウに新しいページが表示されます。このページにコンテンツを生成するか、またはユーザーを既存のページやアプリケーションに移動させることができます。
ポートレット間通信
ポートレット間通信により、ポートレットはデータを共有してイベントに対応できます。WebCenter Portalは、パラメータとイベントを通じたポートレット間通信をサポートします。
-
パラメータ - パブリック・レンダラ・パラメータにより、ポートレット間のパラメータ値を共有することでポートレット間通信が可能になります。たとえば、マップ・ポートレットと天気ポートレットが両方ともZipcodeパラメータを使用するように構成されている場合、マップ・ポートレットに郵便番号を入力すると、天気ポートレットの同じパラメータ値が更新されます。
パブリック・レンダラ・パラメータの詳細は、「JSR 286ポートレットでのパブリック・レンダラ・パラメータの使用方法」を参照してください。
-
イベント - ポートレットを含むページ上で、または同じページ上の別のポートレットで実行されるアクションなど、ポートレットそのものの外側で発生するアクションに対応する機能をポートレットに提供することでポートレット間通信を可能にします。ポートレット・イベントは、ポートレットがそれ自体のイベントをトリガーすることでイベントに応答し、それがそのページ上の他のポートレットに影響を与えるようにカスケードできます。
ポートレット・イベントの詳細は、「JSR 286ポートレットでのポートレット・イベントの使用方法」を参照してください。
WebCenter Portalでは、パラメータとイベントが同じ名前を共有している、または適切な別名を定義していれば、ポートレット間通信がデフォルトで自動的に発生します。この通信を可能にするために追加コードを提供する必要はありません。
Oracle JSF Portlet Bridgeを使用して作成されるポートレットに固有のポートレット間通信ガイドラインは、「イベントを使用したその他のポートレットとのJSFポートレットのリンク」を参照してください。
ポートレットのパーソナライズとカスタマイズ
ポートレット・プリファレンスによってエンド・ユーザーはポートレットを実行時にパーソナライズまたはカスタマイズできます。パーソナライズはこれらを実行するユーザーのみに表示され、他のユーザーには表示されません。カスタマイズは、ポートレットをパーソナライズしていないすべてのユーザーに表示されます。
ポートレット・プリファレンスによって、ポートレットの再利用性が大幅に向上します。同じポートレットを複数のページ上で、または同じページ上で複数回インスタンス化できます。ポートレット・プレファレンスを使用することで、ポートレットの各インスタンスは様々な方法で動作できますが、使用するコードとユーザー・インタフェースは同じままです。
たとえば、デフォルトでは、JDeveloperのウィザードを使用してJSR 286ポートレットを作成すると、実行時にユーザーがポートレットのタイトルを変更できるようにポートレット・プリファレンスが作成されます。ポートレットの作成中に、またはポートレットの作成後にportlet.xmlファイルを編集することで、追加のポートレット・プリファレンスを作成して、実行時のユーザーによるその他のポートレット変更を可能にすることができます。
ポートレット・プリファレンスは、登録やポートレット・ハンドルなどの、登録およびポートレット・インスタンスに関する情報とともに永続ストアに格納されます。ポートレット・プロデューサは、3種類の永続ストアのうちの1つを使用できます。
-
コンシューマ - コンシューマ永続ストアは、プロデューサ・メタデータをコンシューマ・アプリケーションに関連付けます。本番環境ではコンシューマの永続性を使用することをお薦めします。
-
データベース - データベース永続ストアは、リレーショナル・データベースを使用してデータを永続化します。
-
ファイル - ファイルベースの永続ストアは、ファイル・システムを使用してデータを永続化します。
データベースの依存性が削除されるため、テストにはファイルベースまたはコンシューマ永続ストアを使用することができます。ただし、本番の構成ではコンシューマの永続ストアを使用することをお薦めします。
デフォルトでは、JSR 286およびJSFポートレットではコンシューマ永続ストアが使用されます。このデフォルト設定の変更方法の詳細は、「WSRPプロデューサ用の永続ストアのセットアップ」を参照してください。
テスト環境から本番環境に移行する際などの永続ストアの移行の詳細は、「WSRPプロデューサの永続ストアの移行」を参照してください。
ポートレット・パフォーマンス
キャッシュは、高度な動的コンテンツを含むWebサイトのパフォーマンスの向上に使用される一般的な手法です。この手法では、キャッシュと呼ばれる待機時間の短い大きなデータ・ストアを備えたローカル・エージェントを使用してリクエストをプロキシ化することで、動的コンテンツのデータの取得と出力の生成に伴うオーバーヘッドを大幅に削減できます。キャッシュ・エージェントは、リクエストに対して次のいずれかの方法で応答します。
-
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在する場合、エージェントは既存のキャッシュ・コピーをそのまま戻します。これによって、コンテンツの取得と生成というコストがかかるプロセスを省くことができます。この状態は、キャッシュ・ヒットと呼ばれます。
-
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在しない場合、エージェントはリクエストをその宛先に転送し、コンテンツが戻されるのを待機します。エージェントはコンテンツをリクエスト元に戻し、そのキャッシュ内にローカル・コピーを格納して、同じコンテンツに対するリクエストが後で発生した場合に再利用します。この状態は、キャッシュ・ミスと呼ばれます。
ポートレット・プロデューサは、動的コンテンツ(つまり、ポートレット)を生成しますが、デプロイ先となるWebCenter Portalインスタンスから離れた場所にあります。このため、キャッシュによるパフォーマンス向上が可能となります。アーキテクチャは、キャッシュに適切です。プロデューサでレンダリングされたポートレットをキャッシュし、キャッシュされたコピーを再利用して後続のリクエストを処理することによって、プロデューサがページ作成にもたらすオーバーヘッドを最小限にできます。ポートレット・キャッシュは、ユーザー・リクエストに対して迅速にレスポンスするためのキーです。
JSR286ポートレットについては、2とおりのキャッシュ方法があります。これらのキャッシュ方法の主な違いは、コンテンツが有効かどうかを判断する方法にあります。
-
有効期限ベースのキャッシュ - プロデューサはレンダリング・リクエストを受信すると、そのレスポンスに有効期限のスタンプを付けます。レンダリングされたレスポンスはキャッシュに格納され、同じコンテンツに対する後続のすべてのリクエストは、有効期限が経過するまで、このキャッシュを使用して処理されます。このキャッシュ・スキームは最も簡単でパフォーマンスが優れていると考えられます。それは、キャッシュの有効性をテストするためのオーバーヘッドがほとんどなく、ネットワークのラウンドトリップを伴わないためです。有効期限ベースのキャッシュは、コンテンツの使用期間が効率よく定義されているアプリケーションに適しています。コンテンツの使用期間が確実ではない場合、有効期限ベースのキャッシュは効果的ではありません。
ポートレット・コンテンツが静的である場合、またはコンテンツの表示が最新であることが重要でない場合は、有効期限ベースのキャッシュの使用を検討します。
ポートレットに対する有効期限ベースのキャッシュの実装方法の詳細は、「JSR 286ポートレットでの有効期限ベースのキャッシュの実装」を参照してください。
-
有効化ベースのキャッシュ - レンダリング・リクエストを受信したプロデューサは、そのレスポンスにバージョン識別子(またはETag)のスタンプを付けます。この方法でもレスポンスはキャッシュされますが、キャッシュされたコンテンツをコンシューマが再利用する前に、キャッシュされたコンテンツがまだ有効かどうかを判断する必要があります。そのために、キャッシュされたコンテンツのバージョン識別子を含めたレンダリング・リクエストをプロデューサに送信します。プロデューサは、このバージョン識別子が有効であるかどうかを判断します。バージョン識別子が有効である場合、プロデューサはコンテンツを含まない軽量のレスポンスをコンシューマに即座に送信し、キャッシュされたバージョンを再利用できることを通知します。バージョン識別子が無効な場合、プロデューサは新しいバージョン識別子を含む新しいコンテンツを生成し、以前にキャッシュされたバージョンを置き換えます。このキャッシュ形式では、コンシューマは常にコンテンツが最新であるかどうかをプロデューサと確認する必要があります。キャッシュされたコピーの有効性は、プロデューサのロジックによって判断されます。この方法では、固定期間に依存するのではなく、キャッシュされたコンテンツの使用をプロデューサが管理できるという利点があります。
頻繁な変更または予測不可能な変更がある動的コンテンツを含むポートレットの場合、有効化ベースのキャッシュの使用を検討します。
ポートレットに対する検証ベースのキャッシュの実装方法の詳細は、「JSR 286ポートレットでの検証ベースのキャッシュの実装」を参照してください。
キャッシュ・ルールは、ポートレットのコンテナ・レベルで指定でき、ポートレット独自のロジックでエンコードするか、ポートレット・ウィザードを介して設定することができます。
JSFポートレットおよびカスタムJavaポートレットでは、有効期間および有効化ベースのキャッシュがサポートされています。
アプリケーション・レベルのWebCenter Portalでは、アプリケーション・レベルのキャッシュ・ルールの設定にCoherenceが使用されます。WebCenter Portalポートレット・クライアントには、ポートレット用のデフォルト・キャッシュ構成ファイルが用意されています。
<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>portlets</scope-name>
</defaults>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>portlet-consumer-content-cache-*</cache-name>
<scheme-name>portlet-thin-direct</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>portlet-thin-direct</scheme-name>
<local-storage>true</local-storage>
</distributed-scheme>
</caching-schemes>
</cache-config>独自のキャッシュ構成ファイルを作成してポートレット・コンシューマ・キャッシュに使用したり、adf-config.xmlファイルのポートレット・クライアント構成情報を更新してそのファイルを指すようにすることもできます。詳細は、『Oracle WebCenter Portalの管理』のポートレット・クライアント構成の編集に関する項を参照してください。デフォルト・キャッシュ構成ファイルに基づいてファイルを作成すると、キャッシュ名portlet-consumer-content-cache-*のマッピングが定義されます。Coherenceの詳細は、『Oracle WebCenter Portalの管理』のデータ・キャッシュ・パフォーマンスの改善に関する項を参照してください。
複数言語に対応したポートレット
ポートレットは次の3つのステップで多言語対応にすることができます。
-
portlet.xmlファイルの<supported-locale>要素を使用することでポートレットでサポートされているロケールを宣言する。次に例を示します。<portlet id="1328624289503"> ... <supported-locale>en</supported-locale> <supported-locale>fr</supported-locale> <supported-locale>es</supported-locale> ... </portlet>
-
ポートレットに表示されるポートレット・メタデータ(ポートレット・タイトル、説明、キーワードなど)を作成する。
変換はたとえば次のように
portlet.xmlファイルに直接含めることができます。<portlet id="1328624289503"> <portlet-name>LotteryPortlet</portlet-name> <display-name xml:lang="en">Lottery Numbers</display-name> <display-name xml:lang="fr">Numéros de Loterie</display-name> <display-name xml:lang="es">Números de la Lotería</display-name> ... <supported-locale>en</supported-locale> <supported-locale>fr</supported-locale> <supported-locale>es</supported-locale> ... </portlet>
または、別のリソース・バンドルで変換を提供することもできます。リソース・バンドルはたとえば次のように
portlet.xmlファイルに宣言する必要があります。<portlet id="1328624289503"> <portlet-name>LotteryPortlet</portlet-name> <display-name>Lottery Numbers</display-name> ... <supported-locale>en</supported-locale> <supported-locale>fr</supported-locale> <supported-locale>es</supported-locale> <resource-bundle>portlet.resource.LotteryPortletBundle</resource-bundle> ...その後、次のようなリソース・バンドルに変換を提供します。
# English Resource Bundle # # filename: LotteryPortletBundle_en.properties javax.portlet.display-title=Lottery Numbers # French Resource Bundle # # filename: LotteryPortletBundle_fr.properties javax.portlet.display-title=Numéros de Loterie # Spanish Resource Bundle # # filename: LotteryPortletBundle_es.properties javax.portlet-title=Números de la Lotería
-
ポートレットのコンテンツを他のWebアプリケーションと同じように変換できるようにします。
ポートレットのデプロイ
アプリケーションでポートレットを登録および使用できるようにするには、まずポートレットをデプロイする必要があります。JSR 286ポートレットはWSRPプロデューサにデプロイされます。このプロデューサはリモートであり、Web Services for Remote Portlets (WSRP)を介してコンシューマ・アプリケーションと通信します。JSFポートレットはJSR 286ポートレットとしてデプロイされます。つまり、JDeveloperから、または手動でWSRPプロデューサにデプロイされます。
WebCenter Portalは、WSRPバージョン1.0および2.0をサポートします。この標準によって、ポートレット間通信と、ポートレット・カスタマイズのエクスポートまたはインポートがサポートされます。
WSRPは、ポートレット・コンシューマ・アプリケーションとポートレット・コンテナ間の通信プロトコルです。ユーザーを対象とした視覚的なWebサービスを、中間Webアプリケーションにプラグ・アンド・プレイできるようにするWebサービスの標準です。
その標準性により、特定の言語(JSR 286、Perlなど)をベースとする標準対応のコンテナと任意のWSRPポータル間の相互運用が可能です。このため、WSRP対応のコンテナにデプロイされたポートレットは、その言語に関係なく、この標準をサポートするあらゆるアプリケーション上にレンダリングできます。
図11-9は、WSRPプロデューサの基本的なアーキテクチャを示しています。
エンド・ユーザーがWebブラウザでページを表示するとき、リクエストの流れは次のようになります。
-
エンド・ユーザーは、Webブラウザの場所フィールドにURLを入力することで、Webブラウザからページをリクエストします。
-
ブラウザは、HTTPを介してリクエストをコンシューマ・アプリケーションに送信します。
-
アプリケーションは、リクエストされたページで表示されているポートレットを提供するポートレット・プロデューサと通信します。
プロデューサは、ポートレットがHTMLコードまたはXMLコード形式のポートレット・コンテンツを生成するように、それぞれのポートレットに対して必要なコールを実行します。
-
プロデューサはWSRP 1.0または2.0プロトコルを使用してコンシューマ・アプリケーションにポートレット・コンテンツを戻します。
-
コンシューマ・アプリケーションは、HTTPを介してポートレット・コンテンツをブラウザに送信します。
標準のポートレットをWebCenter Portalのコンシューマ・アプリケーションで使用できるようにするには、それらを1つのポートレット・コンシューマ・アプリケーションにパッケージ化し、WSRPコンテナにデプロイする必要があります。