| Oracle® Fusion Middleware Oracle WebCenter Portal開発者ガイド 11g リリース1 (11.1.1.6.0) B72084-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portal開発者ガイド 11g リリース1 (11.1.1.6.0) B72084-01 |
|
前 |
次 |
この章では、Oracle JDeveloper Javaポートレットの作成ウィザードを使用して作成したJavaポートレットを拡張する方法について説明します。
この章の内容は、次のとおりです。
開始する前に
この章を読み始める前に、次のことを確認してください。
ポートレット・モードなど、ポートレットに関する用語の知識があること。詳細は、第58章「ポートレットの概要」を参照してください。
WLS_Portletサーバーなど、ポートレット・コンテナとして使用するように構成されているWebLogic Server (WLS)管理対象サーバーにアクセスできること。
JDeveloperに関する知識があり、それを使用したJavaコンポーネントの構築およびデプロイ方法を習得していること。JDeveloperはOTNからダウンロードできます。
http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html
JSR 286またはPDK-Javaのいずれかに基づいてJavaでポートレットを作成する場合は、この項の次のガイドラインに従ってください。
この項の内容は、次のとおりです。
ポートレット・モードは、実行時のポートレットの機能をユーザーが確認できるようにするものです。WebCenter Portalで提供されている標準モードに加え、一連の拡張モードを提供できます。各種ポータル製品でサポートされている拡張ポートレット・モードは次のとおりです。
WebCenter Portalでは一連の拡張ポートレット・モードが定義されています。PDK-JavaとJSR 286の両方のポートレットで様々なモードが使用可能です。たとえば、JSR 286ポートレット用のJSR 286 Javaポートレット・ウィザードには、「印刷」という拡張モードがあり、これを使用してポートレットの印刷用のバージョンを提供できます。PDK-Javaでは、JSR 286で提供されないモードがいくつか提供されます。ポートレットをJSR 286に従ってコーディングする場合は、portlet.xmlファイルで、カスタム・ポートレット・モードをPDK-Javaが提供する拡張モードにマップすると宣言することも、カスタム・ポートレット・モードに提供するその他の機能を含めると宣言することもできます。
カスタム・モードの定義は、特に、ポートレットを他のベンダーのポータル実装と相互運用する場合に役立ちます。どのカスタム・モードでもユーザーに提供できます。実際には、デフォルトの編集など、いくつかのモードを提供することをお薦めします。
サード・パーティ製品には、プロデューサが提供できる独自の拡張モード・セット(JSR 286カスタム・モード)がある場合もあります。WebCenter Portal: Frameworkアプリケーションでは、ポートレット・クロムにはWebCenter Portal: Frameworkで定義されたカスタム・モードのみが表示されます。サード・パーティやカスタム・ポートレット・プロデューサが提供する任意のカスタム・モードは無視されるため、サポートされません。
この項では、各標準ポートレット・モードについて説明します。この項の内容は、次のとおりです。
表示モードはPDK-Javaでは共有画面モードと呼ばれます。表示モードの詳細は、第58.1.3.1項「表示モード」を参照してください。
ポートレットの開発時には、ページ上でポートレットの外観に影響を与える可能性のあるすべての要素(ポートレットのコンテナ・オブジェクトや、開発したポートレットがページを共有する他のポートレットなど)について検討する必要があります。たとえば、ポートレットをHTML表のセル内に配置するとします。このポートレットでは、表のセル内でレンダリングできるコンテンツのみを表示できます。さらに、表のセルの実際のサイズは、ユーザー設定、ブラウザの幅、およびポートレットに表示されるコンテンツの量とスタイルによって変わります。
プレーンHTMLは最も基本的なポートレットのレンダリング方法であり、ポートレットの開発者に大きな柔軟性を提供します。リンク、フォーム、イメージ、表など、HTMLの表のセル内に表示できるほとんどの標準的なHTMLパラダイムを使用できます。HTMLが適切に作成されていない場合は、異なる複数のブラウザで表示したときに表示の一貫性がなくなり、ページの一部が表示されないこともあります。次のルールに従ってください。
標準HTMLを使用する。HTMLの正式な仕様は、W3Cにあります(詳細はhttp://www.w3.org/を参照)。
閉じていないタグや不要なタグがないように注意する。ページはブラウザの動作の影響を受けるため、タグが正しく閉じていないとページの動作は予測不可能になります。weblintやHTML Tidyなどのツールは、閉じていないタグや不要なタグの検出および修正に役立ちます。
コンテナ・オブジェクトによる制限を検討する。ポートレットをHTML要素(表のセルなど)に格納する場合、ポートレットをそのコンテナ内で確実にレンダリングできるようにする必要があります。たとえば、ポートレットを表のセル内に配置する場合、ポートレット内でフレームを使用できません。これは表内に挿入されると、フレームが表示されないためです。
ポートレットのコンテンツは簡潔にする。全画面のコンテンツを取得して、小さなポートレットから公開しないでください。ポートレットのコンテンツが小さくなりすぎて、小さなモニターではポートレットが使用不能になるのみです。全画面のコンテンツは、PDK-Javaの全画面モードで最適に表示されます。
ポートレット内に固定幅のHTMLの表を作成しない。ユーザーのページに表示されるポートレットの列幅を事前に知る方法はありません。与えられた空間よりも広い空間がポートレットに必要な場合、特定のブラウザでは、他のポートレットとオーバーラップする可能性があります。
折り返しのない長いテキスト行を避ける。固定幅の表を使用した場合と同様の結果になります。特定のブラウザでは、他のポートレットとオーバーラップする可能性があります。
ページ・サイズ変更時の動作をチェックする。ブラウザ・ウィンドウをサイズ変更した際のポートレットの動作をテストし、ポートレットがブラウザ・ウィンドウの様々なサイズで動作することを確認してください。
ブラウザのデフォルトのフォントが変更された場合の動作をチェックする。ユーザーは希望するフォント・サイズを選択でき、いつでも変更できます。ポートレットは、その変更に対応する必要があります。
使用するHTMLも、サイトの知覚されるパフォーマンスに直接影響を与えます。ユーザーは、リクエストしたページの表示にかかる時間に基づいてパフォーマンスを判断します。ブラウザには、HTMLを解釈して表示するための時間が必要です。このため、次の点を考慮してください。
長く複雑なHTMLを避ける。ポートレットはページを他のポートレットと共有します。したがって、ポートレットの生成時間はページのパフォーマンス全体に大きく影響します。ポートレットが複雑なHTMLをレンダリングしたり、サード・パーティのアプリケーションなど外部リソースを待ったりする場合は、ページのレンダリングが大幅に遅くなることがあります。
ページ上のそれぞれのポートレットのフォントと色は、ユーザーが選択したスタイル設定に一致する必要があります。このために、これらのスタイル選択は、各ページのCascading Style Sheet（CSS）を使用して自動的に埋め込まれます。その後、ポートレットは直接またはApplication Programming Interface（API）を使用して、フォントと色の設定にアクセスします。
ブラウザによってCSS仕様の実装レベルが異なりますが、WebCenter Portal: Frameworkは、この仕様の非常に基本的なサブセットを使用して、整合性のあるフォントと色を実現します。CSSの実装レベルによってブラウザ間でのページの一貫性が影響されることはありません。CSS使用に関するガイドラインは、次のとおりです。
ハードコーディングではなくCSSを使用する。フォントと色のハードコーディングは非常に危険です。フォントと色をハードコーディングすると、ユーザーがページ・スタイルの設定を変更した場合に、ポートレットが不釣合いに見えることがあります。開発者はユーザーが設定するフォントや色を予測できないため、ユーザーが選択した背景色と同じフォント色でハードコーディングする可能性があります。この場合、ユーザーはポートレットを識別できなくなります。
テキストの書式設定にはCSS APIを使用する。スタイルシートの定義はページの最上部にありますが、直接コールしないでください。かわりに、テキストの適切な書式設定のために用意されているAPIを使用してください。これによって、後でスタイルシートが変更された場合でもポートレットは正しく動作します。
CSSを使用した絶対位置の設定は避ける。ユーザーは各自のページをパーソナライズできるため、ポートレットが特定の位置に表示される保証はありません。
アクセシビリティの標準に従う。必ず既存のアクセシビリティの標準に従って、スタイルシートを記述してください(詳細はhttp://www.w3.org/TR/WCAG10-CSS-TECHS/を参照)。
編集モードの詳細は、第58.1.3.2項「編集モード」を参照してください。
次のガイドラインに従って、編集モードでユーザーに公開する内容を管理してください。
ユーザーがポートレットのタイトルをパーソナライズできるようにする。同じポートレットが同じページに複数回追加されることがあります。ユーザーがタイトルをパーソナライズできると混乱を避けることができます。
キャッシュを使用する場合はコンテンツを無効化する。パーソナライズによってポートレットの表示やコンテンツに変更が生じた場合は、ポートレットのコンテンツが再生成され、キャッシュから戻されないことを確認する必要があります。確認しないと、誤ったコンテンツが表示されることがあります。
編集モードを管理ツールとして使用しない。編集モードは、ユーザーがポートレットの動作を変更するために使用します。プロデューサ設定の変更などの管理タスクが必要な場合は、そのタスク専用の安全なポートレットを作成してください。
整合性を維持し、ユーザーにとっても便利なように、次のボタンを次の順序で編集モードに実装してください。
OK: ユーザーのパーソナライズを保存し、ポートレットを表示モードに戻します。
適用: ユーザーのパーソナライズを保存し、現在のページをリロードします。
取消: 変更を保存せずに、ポートレットを表示モードに戻します。
パーソナライズ設定を変更するフォームを表示する場合は、デフォルトの値を表示し、ユーザーが設定を毎回再入力しないで済むようにしてください。動作の整合性を維持するために、パーソナライズ値のレンダリングは次の順序で行います。
ユーザー設定項目: このユーザーのパーソナライズが使用可能な場合は、問い合せて表示します。
インスタンス・デフォルト: ユーザーのパーソナライズがない場合は、ポートレット・インスタンスのシステム・デフォルトを問い合せて表示します。これらのデフォルトは編集モードで設定され、このポートレット・インスタンスに対してのみ適用されます。
ポートレット・デフォルト: システム・デフォルトのパーソナライズがない場合は、一般的なポートレットのデフォルトを表示しますが、空白の場合があります。一般的なポートレットのデフォルトはポートレットにハードコーディングされている場合がありますが、前述の2つの条件のいずれかが該当する場合は上書きしてください。
このロジックによって、Frameworkアプリケーション内の他のポートレットとの整合性がとれた予測可能な方法でパーソナライズを表すことができます。
デフォルト編集モードの詳細は、第58.1.3.3項「デフォルト編集モード」を参照してください。
次のガイドラインに従って、デフォルト編集モードでページ設計者に公開する内容を管理してください。
デフォルト編集モードを管理ツールとして使用しない。デフォルト編集モードは、ユーザーがポートレットの動作を変更するために使用します。プロデューサ設定の変更などの管理タスクが必要な場合は、そのタスク専用の安全なポートレットを作成してください。
整合性を維持し、ユーザーにとっても便利なように、次のボタンを次の順序でデフォルト編集モードに実装してください。
OK: ユーザーのパーソナライズを保存し、ポートレットを表示モードに戻します。
適用: ユーザーのパーソナライズを保存し、現在のページをリロードします。
取消: 変更を保存せずに、ポートレットを表示モードに戻します。
パーソナライズ設定を変更するフォームを表示する場合は、デフォルトの値を表示し、アプリケーション開発者が設定を毎回再入力しないで済むようにしてください。動作の整合性を維持するために、パーソナライズ値のレンダリングは次の順序で行います。
インスタンス設定: ポートレット・インスタンスのシステム・デフォルトを問い合せて表示します。
ポートレット・デフォルト: システム・デフォルトのパーソナライズがない場合は、一般的なポートレットのデフォルトを表示しますが、空白の場合があります。一般的なポートレットのデフォルトはポートレットにハードコーディングされている場合がありますが、システム・デフォルトで上書きしてください。
このロジックによって、Frameworkアプリケーション内の他のポートレットとの整合性がとれた予測可能な方法でパーソナライズを表すことができます。
ヘルプ・モードの詳細は、第58.1.3.4項「ヘルプ・モード」を参照してください。
次のガイドラインに従って、ヘルプ・モードでユーザーに公開する内容を管理してください。
ポートレットの使用方法を説明する。ポートレットのインタフェースのみでは、ポートレットのすべての機能がユーザーに理解されない可能性があります。ポートレットの機能とその活用方法を説明してください。
情報モードの詳細は、第58.1.3.5項「情報モード」を参照してください。
次のガイドラインに従って、情報モードでユーザーに公開する内容を管理してください。
関連の著作権、バージョンおよび作成者の情報を表示する。ユーザーは、使用しているポートレットの内容と詳細情報の入手先を参照できる必要があります。この情報ページは、ポートレットのサポート時に重要になることがあります。
|
注意: このモードはFrameworkアプリケーション内での特定の用途はありませんが、Oracle Portalのポートレット・リポジトリでは使用されます。 |
次のガイドラインに従って、プレビュー・モードでユーザーに公開する内容を管理してください。
ポートレットの機能に関する情報を提供する。プレビュー・モードでは、ユーザーがポートレットの実際のコンテンツや機能に関する情報を得られるように、十分なコンテンツを生成する必要があります。
ポートレットのプレビューは大きくしない。このモードで生成されるデータの量は、数行以内のHTMLまたは1つの画面ショットにとどめてください。プレビュー・モードは小さい領域に表示されるため、ウィンドウのサイズより大きくなると見栄えが悪くなり、ユーザーによるスクロールが必要になります。
ライブ・ハイパーリンクを使用しない。 プレビュー・モードでレンダリングしたリンクは、予想どおりに機能しないことがあります。ハイパーリンクは、下線付きのフォントでシミュレートできます。
アクティブ・フォーム・ボタンを使用しない。 プレビュー・モードでレンダリングしたフォームは、予想どおりに機能しないことがあります。フォーム要素をレンダリングする場合、そのフォーム要素はどこにもリンクしないでください。
厳密には、JSR 286ポートレットに全画面モードはありません。ただし、表示モードとウィンドウの最大化を使用して、JSR 286ポートレット用に全画面モードと同等の機能を実装できます。
いろいろな点で、1つのポートレットの異なるセクションまたはページ間のナビゲーションは、標準のWebページ間のナビゲーションと似ています。ユーザーはフォームを実行してリンクをクリックできます。通常の標準的なWebページの場合、これらの操作により、新しいコンテンツをレンダリングするサーバーにメッセージが直接送信され、次に、このコンテンツがクライアントに戻されます。ポートレットの場合は、ページの一部分のみを構成するため、そのポートレット内でのフォーム実行またはリンクのレンダリングでは、情報は直接ポートレットに渡されません。これらの操作では、情報はFrameworkアプリケーションを介してポートレットに渡されます。ポートレット内でのリンクまたはフォームの実行がアプリケーションを参照しない場合は、そのリンクをたどるとユーザーをアプリケーションポータルから離れさせることになり、通常好ましくない動作です。
コンポーネントの開発者は、フォームまたはリンクのパラメータがユーザー、アプリケーションおよびポートレット間を受け渡しされる詳細な機構を知る必要はありません。しかし、通常の標準的なWebページの場合と同じ方法でポートレット内にリンクを作成できないことは理解しておく必要があります。
ポートレット用のリンクのタイプ
ポートレットは、次の4つのクラスのリンクをレンダリングできます。
ポートレット内リンク: ポートレットはFrameworkアプリケーションのアドレスを認識できるようにしておきます。実際になんらかの方法で参照するためです。
アプリケーション・リンク: ポートレット内リンクと同じ理由で、Frameworkアプリケーションのアドレスを認識できるようにしておきます。
外部リンク: Frameworkアプリケーションを参照せず、標準のWebページの場合と同様にポートレット内で機能します。
内部/リソース・リンク: 外部リンクと同様にFrameworkアプリケーションを参照しません。
図61-1に、これらのリンク・タイプの概要を示します。矢印は、リンクがどのように論理的な参照先であるリソースを参照するかを示します。
図61-1 WebCenter Portal: Frameworkアプリケーション・リンク・タイプ
この項の内容は、次のとおりです。
ポートレット内リンクは、所定のポートレット内の様々なセクションまたはページに移動します。厳密に言えば、ポートレットが含まれているページが参照されますが、このリンクには、ユーザーによってリクエストされたときに、ポートレットにページ内の様々なセクションまたはページをレンダリングさせるパラメータが含まれています。
この直接の結果として、ポートレットは、独自のサーバー・コンテキストに基づく相対リンクまたは絶対リンクを使用して、自身の様々なセクションまたはページへのリンクのレンダリングをリクエストすることはできません。ポートレット内リンクは、リンクまたはフォーム実行ターゲットとしてポートレット内のナビゲーションには便利です。
外部リンクは、ポートレット(ページを介して)も、Frameworkアプリケーションのどの部分も参照しません。これらのリンクを選択した場合、ユーザーはアプリケーションの外(たとえばwww.oracle.com)に出ます。
内部/リソース・リンクは、(ポートレットの)内部リソースを参照します。このリンクは、ポートレットのレンダリング中に内部で排他的に、たとえばサーバー側インクルードとして、使用されることがあります。また、外部的に、イメージなどのポートレット・リソースの参照に使用されることもあります。外部的に使用される場合は、PDK-JavaのUrlUtilsクラスのconstructResourceURLメソッドを使用し、リソース・プロキシを使用してファイアウォールの内部からイメージを取得します。リソース・プロキシが機能するようにするには、まずプロデューサに対して、JNDI変数oracle/portal/provider/sample/resourceUrlKeyを設定する必要があります。JNDI変数設定の詳細は、第61.3.5.2項「JNDI変数値の設定」を参照してください。
たとえば、PDK-Javaに含まれている宝くじのサンプルjspであるlottery.jspには、イメージに対するリソース・プロキシ・リクエストが含まれています。
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page session="false" import="oracle.portal.provider.v2.render.*" %>
<%@ page import="oracle.portal.provider.v2.render.http.HttpPortletRendererUtil" %>
<%@ page import="oracle.portal.provider.v2.url.UrlUtils" %>
<%@ page import="oracle.portal.sample.v2.devguide.lottery.*" %>
<%
LottoPicker picker = new LottoPicker();
picker.setIdentity(request.getRemoteAddr() ); %>
<% PortletRenderRequest portletRequest = (PortletRenderRequest)
request.getAttribute("oracle.portal.PortletRenderRequest"); %>
<% String name = portletRequest.getUser().getName(); %>
<P class="PortletHeading1" ALIGN="CENTER">Hi <%= name %>, Your Specially
Picked</P><P ALIGN="CENTER"><IMG SRC="<%= UrlUtils.constructResourceURL(portletRequest,
HttpPortletRendererUtil.absoluteLink(request, "images/winningnumbers.gif")) %>"
WIDTH="450" HEIGHT="69" ALIGN="BOTTOM" BORDER="0"></P>
<P>
<P ALIGN="CENTER">
<TABLE ALIGN="CENTER" BORDER="0" CELLPADDING="0" CELLSPACING="0">
<TR>
<%
int [] picks = picker.getPicks();
for (int i = 0; i < picks.length; i++) {
%>
<TD>
<IMG SRC="<%= UrlUtils.constructResourceURL(portletRequest,
HttpPortletRendererUtil.absoluteLink(request, "images/ball" + picks[i])) %>
.gif" WIDTH="68" HEIGHT="76" ALIGN="BOTTOM" BORDER="0">
</TD>
<%
}
セッション・ベースのプロデューサの場合、元のinitSessionコールからプロデューサに戻されるCookieは、リクエストとともに戻され、正しいセッション・コンテキストを維持します。
JavaScriptは、多くの場合ポートレット内で役に立ちますが、使用するポートレット内では次のガイドラインを念頭に置いてください。
ポートレットがレンダリングされるページをリダイレクトするのに、JavaScriptを絶対に使用しないでください。ユーザーを他の場所にダイレクトしたい場合は、コードを処理するポートレット・アクションで行うか、ブラウザで新しいウィンドウを開く必要があります。
JavaScript内の識別子が修飾されていることを確認します。識別子を修飾することにより、識別子が一意であり、ページ上のどのJavaScriptとも競合しないようにします。
第60.2.1項「JSR 286 Javaポートレットの作成方法」の説明に従ってJSR 286 Javaポートレットの作成ウィザードで初期ポートレットを構築したら、次はそれを拡張します。JSR 286ポートレットはJava標準に準拠しているため、これの拡張に関する情報は、サード・パーティの書籍やWebページなど様々なソースから多数入手できます。
この項の内容は、次のとおりです。
アプリケーションのポートレット・デプロイメント・ディスクリプタ・ファイルportlet.xmlは、アプリケーション内のポートレット・リソースを指定します。ポートレット・ウィザードでJSR 286ポートレットを作成した後、portlet.xmlファイルを編集することによりこれらのリソースを編集できます。
JDeveloperでportlet.xmlファイルを開いたら、ソース・コードを編集するか、概要エディタを使用することにより、ソース・モードで手動で修正することなくポートレット・リソースを編集できます。
ポートレット・デプロイメント・ファイルを編集する手順は次のとおりです。
JDeveloperのアプリケーション・ナビゲータで、ポートレット・プロデューサ・アプリケーションを開きます。
ポートレット・プロジェクトを開きます。
「Webコンテンツ」ノード、「WEB-INF」ノードの順に開きます。
portlet.xmlを右クリックし、「開く」を選択します。
「設計」タブをクリックして、portlet.xmlに対する概要エディタを開きます。
portlet.xmlに対する概要エディタには次のタブがあります。
アプリケーション: ポートレット・プロデューサ・アプリケーションの全般的な情報を指定するために使用します。これらのプロパティはアプリケーション内のすべてのポートレットに適用されます。
ポートレット: アプリケーション内の個々のポートレットの情報を指定するために使用します。たとえば、ポートレットによりサポートされるポートレット・イベントやパブリック・レンダラ・パラメータを指定できます。
イベント: アプリケーション内のすべてのポートレットにより使用されるポートレット・イベントの作成と管理に使用します。詳細は、第61.2.5項「ポートレット・イベントの使用方法」を参照してください。
パラメータ: アプリケーション内のすべてのポートレットにより使用されるパブリック・レンダラ・パラメータの作成と管理に使用します。詳細は、第61.2.6項「パブリック・レンダラ・パラメータの使用方法」を参照してください。
フィルタ: アプリケーション内のポートレットのフィルタ情報を指定するために使用します。詳細は、第61.2.8項「ポートレット・フィルタの使用方法」を参照してください。
フィルタ・マッピング: 個々のポートレットにポートレット・フィルタを割り当てるために使用します。詳細は、第61.2.8項「ポートレット・フィルタの使用方法」を参照してください。
JSR 286 Javaポートレットの作成ウィザードでは、「コンテンツ・タイプとポートレット・モード」ページのリストに追加することによりポートレット・モードを追加します。ウィザードの使用方法の詳細は、第60.2.1項「JSR 286 Javaポートレットの作成方法」を参照してください。ウィザードでは、JSR 286でサポートされている標準モードと、WebCenter Portalにより提供される拡張モードを実装できます。
JSR 286でサポートされている標準モードは次のとおりです。
表示
編集
ヘルプ
WebCenter Portalでサポートされている追加のカスタム・モードは次のとおりです。
情報
構成
デフォルト編集
プレビュー
印刷
ポートレットの初期作成後に、独自のカスタム・ポートレット・モードを定義することもできます。PDK-Javaにより提供される追加のモード(たとえば、「全画面モード」)にマップするため、または提供するその他の固有の機能に対応するためにカスタム・モードを追加できます。
ポートレット・モードを実装する原理は、どのモードについても同じです。
開始する前に
ここで説明する手順は、次のことを前提としています。
JSR 286 Javaポートレットの作成ウィザードを使用してポートレットを構築済であること
ポートレットのプロデューサが正しく登録されていること
ポートレットがページに追加されていること
カスタム・ポートレット・モードを追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
必要に応じて「アプリケーション」タブをクリックします。
必要に応じて「カスタム・モード」セクションを開きます。
このセクションには、アプリケーション内のポートレットで使用可能なすべてのカスタム・モードのリストが表示されます。WebCenter Portalの拡張ポートレット・モードも含まれます。
「カスタム・モードの追加」アイコンをクリックして、ポートレット・モードに対する新しい行を作成します。
「ポートレット・モード」フィールドに、ポートレット・モードの名前を入力します。
この名前は、アプリケーション内で一意である必要があります。
「説明」フィールドに、モードの目的についての簡単な説明を入力します。
ポートレット・モードがポータルにより管理されない場合は、「ポータル管理」チェック・ボックスの選択を解除します。
portlet.xmlファイルを保存します。
カスタム・ポートレット・モードをアプリケーションに追加したら、次にポートレット実装ファイル内にモードに対するコードを作成する必要があります。
ポートレット・プロデューサ・アプリケーション内に、user.login.idやuser.name.familyなど、頻繁に使用するユーザー情報にアクセスするためのユーザー属性を作成できます。実行時には、これらのユーザー属性は現在のユーザーの実際の属性にマップされます。ポートレットはこの情報を使用して現在のユーザーに関する情報を取得できます。
ユーザー情報にアクセスする手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
必要に応じて「アプリケーション」タブをクリックします。
必要に応じて「ユーザー属性」セクションを開きます。
「ユーザー属性の追加」アイコンをクリックして、属性に対する新しい行を作成します。
「名前」フィールドに、ユーザー属性の名前(たとえばuser.login.id)を入力します。
「説明」フィールドに、ユーザー属性の説明を入力します。
実行時に、ポートレット・コンテナによりこの属性が適切な値にマップされます。たとえば現在のユーザーがJohn Doeの場合、user.name.familyユーザー属性はDoeにマップされます。ポートレットは、ユーザー属性を含むMapオブジェクトをPortletRequestインタフェースから取得できます。
portlet.xmlファイルを保存します。
ポートレットの実行時には、ポートレット・コンテナによりランタイム環境およびポートレット・プロデューサ・アプリケーションとポートレット間のインタフェースが提供されます。
コンテナ・ランタイム・オプションを使用すると、ポートレット・コンテナの動作をカスタマイズすることによりランタイム環境をカスタマイズできます。
この項の内容は、次のとおりです。
表61-1に、WebCenter Portalポートレット・コンテナでサポートされるコンテナ・ランタイム・オプションを示します。
JSR 286コンテナ・ランタイム・オプションの詳細は、次のURLで提供されているJSR 286仕様を参照してください。
http://jcp.org/en/jsr/detail?id=286
表61-1 サポートされるコンテナ・ランタイム・オプション
javax.portlet.actionScopedRequestAttributes
新しいアクションが発生するまでポートレットで使用できるように、アクション・スコープのリクエスト属性を格納するかどうかを指定します。
WebCenter Portal固有のexcludedActionScopeRequestAttributesコンテナ・ランタイム・オプションを使用して、どのリクエスト属性がスコープに格納されるかを制限できます。
有効な値は次のとおりです。
true: processActionで始まるリクエスト属性を次のprocessActionまで格納します。ポートレット・コンテナによりキャッシュされるスコープの数を示すnumberOfCachedScopesの2つ目の値および3つ目の値を指定できます。
false: リクエスト属性を格納しません。
javax.portlet.escapeXml
actionUrl、renderUrlおよびresourceUrl JSR 286タグ・ライブラリのタグから返されたURLをXMLエンコードするかどうかを指定します。
encodeXml属性を使用して、タグごとにこのオプションをオーバーライドできます。
有効な値は次のとおりです。
true: (デフォルト)actionUrl、renderUrlおよびresourceUrlタグにより返されたURLはXMLエンコードされます(パラメータ区切りのためのアンパサンド・エンティティを使用して)。
false: actionUrl、renderUrlおよびresourceUrlタグにより返されるURLはXMLエンコードされません(アンパサンド文字のみを使用します)。
|
注意: このオプションは、 |
javax.portlet.servletDefaultSessionScope
Javaポートレットに含まれるかそこから転送される、サーブレットまたはJSPに提供されるセッション・オブジェクトのスコープを指定します。
有効な値は次のとおりです。
APPLICATION_SCOPE: (デフォルト)ポートレット・セッションをアプリケーション・スコープにマップします。
PORTLET_SCOPE: ポートレット・セッションをポートレット・スコープにマップします。
com.oracle.portlet.allowEventPayloadsWithoutJAXBBinding
portlet.xmlで宣言されたイベント・ペイロード・タイプおよびJSR 286ポートレットから送信されたイベント・ペイロードが、これらのタイプが有効なJAXBバインディングを持つことを要求するJSR 286仕様を無視することを許可します。
有効な値は次のとおりです。
true: 有効なJAXBバインディングなしのイベント・ペイロードが許可されます。
false: JSR 286仕様に従い、有効なJAXBバインディングなしのイベント・ペイロードを許可しません。
com.oracle.portlet.allowWsrpExport
Webアプリケーションに対してWSRPのexport-portlets操作をサポートするべきかどうかを指定します。
このオプションは主に下位互換性のために使用されます。export-portlets操作はwsrp-producer-config.xml設定を使用して制御することをお薦めします。
有効な値は次のとおりです。
true: (デフォルト)export-portletsが許可されます。
false: export-portletsは許可されません。これにより、WEB-INF/wsrp-producer-config.xmlの設定がオーバーライドされます。
com.oracle.portlet.compatibilityMode
owc168に設定すると、WebCenter Portal JSR 286コンテナJSR 168互換モードが呼び出されます。
また、disallowResourceServingランタイム・オプションに対して別の値が指定されていない場合は、これによりこのオプションが自動的にtrueに設定されます。
com.oracle.portlet.defaultProxiedResourceRequiresWsrpRewrite
ポートレットにより提供されないリソースに対するURLのエンコード時に使用するデフォルトのWSRP requiresRewriteフラグを指定します。PortletResponse.encodeURL()メソッドのコール時にoracle.portlet.server.resourceRequiresRewritingリクエスト属性の存在によってオーバーライドされないかぎり、PortletResponse.encodeURL()メソッドにより返されるすべてのURLにこの設定が使用されます。
有効な値は次のとおりです。
true: (デフォルト)requiresRewriteフラグがtrueに設定されます。これはリソースがコンシューマにより書きなおされるべきであることを示します。
false: requiresRewriteフラグがfalseに設定されます。これはリソースが必ずしもコンシューマにより書きなおされるべきではないことを示します。
com.oracle.portlet.defaultServedResourceRequiesWsrpRewrite
ポートレットにより提供されるリソースに対するリソースURLの生成時に使用するデフォルトのWSRP requiresRewriteフラグを指定します。
リソースURLメソッドwrite()またはtoString()のコール時にresourceRequiresRewritingリクエスト属性の存在によってオーバーライドされないかぎり、ポートレットにより作成されるすべてのリソースURLにこの設定が使用されます。この設定は提供されるリソース・レスポンスのWSRP requiresRewritingフラグを指定するためにも使用されますが、ポートレットのserveResource()メソッドが返される際にresourceRequiresRewritingリクエスト属性の存在によりオーバーライドされることがあります。
有効な値は次のとおりです。
true: requiresRewrite URLフラグとrequiresRewritingレスポンス・フラグがtrueに設定されます。これは、リソースがコンシューマにより書きなおされるべきであることを示します。
false: requiresRewrite URLフラグとrequiresRewritingレスポンス・フラグがfalseに設定されます。これは、コンシューマがURLを書きなおすことがあるが、リソースは必ずしもコンシューマにより書きなおされる必要はないことを示します。
値を指定しないと、requiresRewrite URLフラグには値が設定されず、serveResource操作に対するrequiresRewritingレスポンス・フラグはレスポンスのMIMEタイプに基づいて設定されます。
com.oracle.portlet.disallowResourceServing
ポートレットにリソースの提供を許可するかどうかを指定します。これは、JSR 168ポートレットを286コンテナで実行している場合に有用です。javax.portlet.GenericPortletを拡張するJSR 168ポートレットは自動的にJSR 286の機能を継承するため、リソース・リクエストがリソースIDに基づく名前が付けられたWebアプリケーション内のファイルに自動的に転送され、これにより潜在的なセキュリティの問題が発生します。同じセキュリティ上の理由から、リソースを提供しないJSR 286ポートレットではリソースの提供を許可しないことをお薦めします。
有効な値は次のとおりです。
true: ポートレットによるリソースの提供を許可しません。
false: ポートレットによるリソースの提供を許可します。
com.oracle.portlet.escapeXmlEncodeUrls
JSR 286コンテナで、PortletResponse.encodeURL()メソッドから生成されたURLをXMLエンコードするべきかどうかを指定します。
有効な値は次のとおりです。
true: PortletResponse.encodeURL()メソッドにより生成されたURLがXMLエンコードされます。
false: (デフォルト)PortletResponse.encodeURL()により生成されたURLはXMLエンコードされません。
com.oracle.portlet.eventPayloadsXmlType
イベントがWSRPを介して送信される場合のJAXBバインド可能なJavaオブジェクト・イベント・ペイロードに対するオプションのXMLスキーマ・タイプを指定します。これは複数値ランタイム・オプションであり、各値はコロン(:)で区切られたJavaクラス名とQNameペアから構成されます。QNameには、QNameの標準Java String表現({namespace}localpart)を使用します。指定した値ごとに、QNameは、オブジェクトのXMLへのマーシャリング後に、指定されたJavaオブジェクト・タイプのWSRPイベント・ペイロードに注釈付けするためのXMLスキーマ・タイプとして使用されます。これは、複数のプロデューサ上のポートレット間の通信にイベントを使用する場合に有用です。
com.oracle.portlet.excludedActionScopeRequestAttributes
これは、それぞれの値が正規表現である複数値を持つプロパティです。com.oracle.portlet.externalScopeRequestAttributesコンテナ・ランタイム・オプションで定義されている正規表現に値が一致するリクエスト・パラメータに加え、javax.portlet.actionScopedRequestAttributesコンテナ・ランタイム・オプションが使用されている場合は、いずれかの正規表現に一致するリクエスト属性はアクション・スコープ・リクエスト属性として格納されません。
com.oracle.portlet.externalScopeRequestAttributes
これは、それぞれの値が正規表現である複数値を持つプロパティです。いずれかの正規表現に一致するリクエスト属性はポートレット・スコープ外と見なされ、基礎となるポータル・リクエストと共有されます。
javax.portlet.actionScopedRequestAttributesオプションが使用されている場合は、externalScopeRequestAttributesで宣言されている正規表現に一致するリクエスト属性はアクション・スコープ・リクエスト属性には格納されません。
com.oracle.portlet.importCssToIFrame
ポータル・コンシューマに対して、CSSファイルをIFRAMEポートレットにインポートするべきかどうかを指定します。
有効な値は次のとおりです。
false: (デフォルト)何も実行されません。
true: コンシューマからのCSSファイルがIFRAMEポートレットに適用されます。
com.oracle.portlet.minimumWsrpVersion
ポートレットが機能するために最低限必要なWSRPバージョンを指定します。使用されているWSRPバージョンが指定した値よりも低い場合は、ポートレットはWSRP GetServiceDescription、GetPortletDescription、GetMarkupおよびその他のWSRPレスポンスには含まれません。
有効な値は次のとおりです。
1
2
com.oracle.portlet.offerPortletOverWsrp
ポートレットがWSRPプロデューサのサービス説明で提供されるかどうかを指定します。
JSR 168/286ポートレットを参照する.portletファイル内のofferRemote設定は、このコンテナ・ランタイム・オプションをオーバーライドします。
有効な値は次のとおりです。
true: (デフォルト)ポートレットがWSRPプロデューサのサービス説明で提供されます。
false: ポートレットはサービス説明に含まれません。
値を指定しないと、WEB-INF/producer-config.xmlで指定されているデフォルト値が使用されます。
com.oracle.portlet.portalInfoProvider
com.bea.portlet.container.IPortalInfoインタフェースのオプション実装のクラス名を指定します。この実装は、JSR 286コンテナのrequest.getPortalContext().getPortalInfo()により返される値を定義します。デフォルトの実装ではプロデューサ/ローカル・サーバー名とバージョンが返されますが、カスタム実装ではWSRPシナリオのコンシューマ・サーバー情報とプロデューサ・サーバー情報の両方を返せます。
com.oracle.portlet.redirectAfterAction
結果ページのリロードにより別のprocessActionが実行されないように、processActionの実行(およびイベントの処理)後に、JSR 286コンテナが、ポートレットのレンダラURLへのリダイレクトをブラウザに送信するようにします。
有効な値は次のとおりです。
true: すべてのポートレット・アクション後にリダイレクトが発行されます。
false: ポートレット・アクション後に自動的にリダイレクトは発行されません。
com.oracle.portlet.requireIFrame
ポートレットをIFRAME内でレンダリングするべきかどうかを指定します。
有効な値は次のとおりです。
true: ポートレットをIFRAME内でレンダリングします。
false: ポートレットをIFRAME内で強制的にレンダリングしません。
com.oracle.portlet.streamingOptimized
ポートレットが、パフォーマンスを向上させる可能性があるストリーミング・モードで実行するように最適化されていることを示します。
有効な値は次のとおりです。
true: ポートレットはストリーミング・モードで実行するように最適化されています。
false: ポートレットはストリーミング・モードで実行するように最適化されていません。
com.oracle.portlet.suppressWsrpOptimisticRender
ポートレットがWSRPを介して実行されている場合に、アクションやイベント・ライフサイクル後のポートレットのオプティミスティック・レンダリングを抑制します。
有効な値は次のとおりです。
true: オプティミスティック・レンダリングは常に抑制されます。
false: オプティミスティック・レンダリングを実行できます。
com.oracle.portlet.trapWsrpRenderExceptions
JSR 286コンテナが、レンダリング中の例外をWSRP SOAPフォルトとして送信するべきか、またはポートレット・マークアップに対する例外メッセージをレンダリングするべきかを指定します。
有効な値は次のとおりです。
true: (デフォルト)例外はSOAPフォルトとして送信されず、例外スタック・トレースとしてレンダリングされます。
false: レンダリング中にポートレットにより生成された例外はSOAPフォルトとして処理されます。
com.oracle.portlet.trimEncodeUrls
JSR 286コンテナで、PortletResponse.encodeURL()メソッドに渡されたURLから空白を削除するべきかどうかを指定します。
有効な値は次のとおりです。
true: (デフォルト)先頭および最後の空白がPortletResponse.encodeURL()に渡されたURLから削除されます。
false: PortletResponse.encodeURL()に渡されたURLから空白は削除されません。
com.oracle.portlet.useWsrpUserContextForUserAuthentication
PortletRequestメソッドのgetRemoteUser()、getUserPrincipal()およびisUserInRole()が、WSRPユーザー・コンテキスト情報または標準のJ2EEセキュリティのどちらに基づいているかを指定します。
有効な値は次のとおりです。
true: ポートレットがWSRPを介して実行されている場合、ユーザー情報はWSRPユーザー・コンテキストに基づいています。これはセキュリティ上の問題となることがあるため、このオプションを使用する場合は注意が必要です。
false: (またはプロトコルがWSRPを介して実行されていない場合)ユーザー情報はJ2EE認証ユーザーに基づいています。
com.oracle.portlet.wsrpHeaderMode
ポートレットがWSRPリモート・ポートレットとしてレンダリングされている場合にのみ使用されます。ヘッダーまたはCookieの意図された最終的な宛先についてのWSRPコンシューマに対するヒントとして、WSRP SOAPレスポンスのどこにヘッダーおよびCookieを含めるべきかを示します。
ポートレットがローカルに実行されている場合(WSRPを介してではなく)、ポートレットにより設定されたヘッダーおよびCookieは常にクライアントに送信されるものと見なされます。このコンテナ・ランタイム・オプションを設定すると、PortletRequest属性com.oracle.portlet.wsrpHeaderModeのデフォルト値が設定されますが、これはヘッダーごとに実行時にポートレットによりオーバーライドできます。
有効な値は次のとおりです。
client: ポートレットにより設定されたヘッダーおよびCookieはクライアント(ブラウザなど)に送信されるようにダイレクトされます。
consumer: ポートレットにより設定されたヘッダーおよびCookieはコンシューマに送信されるようにダイレクトされ、クライアントには渡されません。
both: ポートレットにより設定されたヘッダーおよびCookieはクライアントとコンシューマに送信されるようにダイレクトされます。
値を設定しないと、ポートレット・コンテナは、WEB-INF/wsrp-producer-config.xmlファイルに指定されているプロデューサのデフォルト値を使用します。
com.oracle.portlet.wsrpLegacyPortletHandle
ポートレットに対して使用するレガシーWSRPポートレット・ハンドルを指定することを許可します。これはWebアプリケーション内で重複してはなりません。これは、レガシーのポートレット位置に基づいたWSRPポートレット・ハンドルを使用するWebCenter Portalコンシューマとの下位互換性に有用です。
指定したレガシー・ポートレット・ハンドルはWSRP serviceDescription内でポートレットのレガシー・ハンドル拡張として公開されます。ポートレットはWSRP serviceDescriptionのレガシー・ポートレット・ハンドルの下で公開されませんが、コンシューマはレガシー・ポートレット・ハンドルを使用してポートレットにアクセスできます。
com.oracle.portlet.wsrpPortletHandle
ポートレットに対して使用するWSRPポートレット・ハンドルを指定することを許可します。これはWebアプリケーション内で重複してはなりません。
oracle.portlet.bridge.adf.raiseUndeclaredContextualEvents
Oracle JSF Portlet Bridgeが、対応するポートレット・イベントがportlet.xmlファイル内で宣言されていないADFmイベントを発生させることを許可します。
有効な値は次のとおりです。
true: 発生したADFmイベントはポートレット・イベントとして転送されます。
false: 対応するポートレット・イベント宣言があるイベントのみが転送されます。
アプリケーション・レベルでコンテナ・ランタイム・オプションを設定すると、アプリケーション内のすべてのポートレットに影響します。
アプリケーション・レベルでコンテナ・ランタイム・オプションを設定する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
必要に応じて「アプリケーション」タブをクリックします。
必要に応じて「コンテナ・ランタイム・オプション」セクションを開きます。
コンテナ・ランタイム・オプションの追加アイコンをクリックして、使用可能なオプションのリストを表示します。
このリストには、表61-1に示している、WebCenter Portalポートレット・コンテナでサポートされるすべてのコンテナ・ランタイム・オプションが含まれます。
リストに含まれない追加のコンテナ・ランタイム・オプションをサポートする別のポートレット・コンテナを使用している場合は、「カスタマイズ」を選択して、「名前」フィールドにオプションの名前を入力します。
ポートレット・コンテナでサポートされないコンテナ・ランタイム・オプションを指定した場合、そのオプションは無視されます。
「値」フィールドに、コンテナ・ランタイム・オプションの値を入力します。
コンテナ・ランタイム・オプションがportlet.xmlのコードに追加されます。
<container-runtime-option> <name>com.oracle.portlet.requireIFrame</name> <value>true</value> </containter-runtime-option>
portlet.xmlファイルを保存します。
アプリケーション全体の設定に優先する、個々のポートレット・レベルのコンテナ・ランタイム・オプションを設定することができます。
ポートレット・レベルでコンテナ・ランタイム・オプションを設定する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
必要に応じて、「ポートレット」タブをクリックします。
「詳細設定」タブをクリックします。
コンテナ・ランタイム・オプションの追加アイコンをクリックして、使用可能なオプションのリストを表示します。
このリストには、表61-1に示している、WebCenter Portalポートレット・コンテナでサポートされるすべてのコンテナ・ランタイム・オプションが含まれます。
リストに含まれない追加のコンテナ・ランタイム・オプションをサポートする別のポートレット・コンテナを使用している場合は、「カスタマイズ」を選択して、「名前」フィールドにオプションの名前を入力します。
ポートレット・コンテナでサポートされないコンテナ・ランタイム・オプションを指定した場合、そのオプションは無視されます。
「値」フィールドに、コンテナ・ランタイム・オプションの値を入力します。
コンテナ・ランタイム・オプションがportlet.xmlのコードに追加されます。
<container-runtime-option> <name>com.oracle.portlet.requireIFrame</name> <value>false</value> </containter-runtime-option>
portlet.xmlファイルを保存します。
ポートレット・イベントは、ポートレット外で発生したアクション(たとえばポートレットを含むページ上または同じページの別のポートレット上で実行されたアクション)に応答する機能をポートレットに提供することによりポートレット間通信を可能にするJSR 286の機能です。ポートレット・イベントはカスケードできます。つまり、ポートレットが自身のイベントをトリガーすることにより別のイベントに応答すると、このトリガーされたイベントによりページ上の他のポートレットが影響を受けます。
ポートレットによりサポートされるポートレット・イベントは、ポートレット・デプロイメント・ディスクリプタ(portlet.xml)のアプリケーション・セクションで宣言する必要があります。このようにアプリケーション・レベルで定義されたポートレット・イベントは、アプリケーション内のすべてのポートレットで使用できます。
アプリケーション内の個々のポートレットは、これらのポートレット・イベントのうちのどれを使用するかを指定できます。ポートレットは、受信したいイベント(処理イベント)およびトリガーするイベント(公開イベント)を宣言できます。
この項の内容は、次のとおりです。
ポートレット・イベントおよびその実装方法の詳細は、次のURLで提供されているJSR 286仕様を参照してください。
http://jcp.org/en/jsr/detail?id=286
ポートレット・イベントをポートレットで使用できるようにするには、まずそのイベントをポートレット・デプロイメント・ディスクリプタ(portlet.xml)のアプリケーション・セクションで宣言する必要があります。
ポートレット・イベントをアプリケーション・レベルで定義する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「イベント」タブをクリックします。
「追加」アイコンをクリックして、新しいポートレット・イベントを作成します。
ドロップダウン・リストから、ポートレット・イベントに対する完全修飾名(QName)または名前のローカル部分のみのどちらを指定するのかを選択します。
QNameは、ローカル名のほかにパラメータに対する名前空間を指定することにより、複数のアプリケーション間でポートレット・イベントを一意に識別します。通常、1つのページには様々なアプリケーションからの複数のポートレットが含まれます。QNameを使用することにより、これらのポートレットがどのアプリケーションのものであるかにかかわらず、1つのポートレットからのポートレット・イベントが同じページ上の他のポートレットに意図せずに干渉することを防げます。
ポートレット・イベントの名前空間がアプリケーションのデフォルトの名前空間と同じである場合は、イベントの定義時に未修飾名を指定することにより名前空間を省略できます。アプリケーションのデフォルトの名前空間が定義されていない場合は、未修飾名のポートレット・イベントにはXMLのデフォルトの名前空間が使用されます。
「修飾名」を選択した場合は、次を実行します。
「ネームスペース」フィールドに、ポートレット・イベントに対する名前空間を入力します。
「名前」フィールドに、ポートレット・イベント名のローカル部分を入力します。
「未修飾名」を選択した場合は、「名前」フィールドにポートレット・イベント名のローカル部分を入力します。イベントは、イベントの名前空間としてアプリケーションのデフォルトの名前空間(またはアプリケーションに対して名前空間が定義されていない場合はXMLのデフォルトの名前空間)を使用します。
「ペイロード」フィールドで、ポートレット・イベントにより提供されるペイロードのデータ型を入力するか参照します。
「説明」フィールドに、ポートレット・イベントの説明を入力します。
(オプション)「別名」パネルでは、ポートレット・イベントのQNameがポートレットにより定義されているQNameと異なる場合にもそのポートレット・イベントがポートレットにより認識されるように、別名のリストを指定できます。
「作成」アイコンをクリックして、ポートレット・イベントに対する新しい別名を作成します。
「ネームスペース」フィールドに、別名に対して使用するポートレット・イベントの名前空間を入力します。
「ネームスペース」フィールドに、別名に対して使用するポートレット・イベントの名前空間を入力します。
ポートレット・イベントがportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<event-definition> <description>This is my event</description> <qname xmlns:x="http://example.com/events">myEvent</qname> <value-type>java.lang.String</value-type> </event-definition>
portlet.xmlファイルを保存します。
ポートレットが特定のポートレット・イベントをリスニングするようにするには、そのイベントを処理イベントとして定義します。
ポートレットに処理イベントを追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
ポートレット・プロデューサ・アプリケーション内にまだポートレット・イベントを定義していない場合は、最初に定義する必要があります。詳細は、第61.2.5.1項「アプリケーション・レベルでのポートレット・イベントの定義」を参照してください。
「ポートレット」タブをクリックして、ポートレット・イベントを使用するポートレットを選択します。
「イベント」タブをクリックします。
「処理イベント」パネルの「使用可能」リストには、そのアプリケーションに対して定義されているすべてのポートレット・イベントが表示されます。
ポートレットで使用するポートレット・イベントを選択し、追加アイコンをクリックして「選択済」リストに移動します。
これにより、ポートレット・イベントが処理イベントとしてportlet.xmlのポートレット定義に追加されます。
<portlet id="1234567890">
...
<supported-processing-event>
<name>myParam</name>
</supported-processing-event>
...
</portlet>
portlet.xmlファイルを保存します。
これにより、このポートレット・イベントをポートレットのコード内で使用できるようになります。
ポートレットが特定のポートレット・イベントをトリガーするようにするには、そのイベントを公開イベントとして定義します。
ポートレットに公開イベントを追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
ポートレット・プロデューサ・アプリケーション内にまだポートレット・イベントを定義していない場合は、最初に定義する必要があります。詳細は、第61.2.5.1項「アプリケーション・レベルでのポートレット・イベントの定義」を参照してください。
「ポートレット」タブをクリックして、ポートレット・イベントを使用するポートレットを選択します。
「イベント」タブをクリックします。
「公開イベント」パネルの「使用可能」リストに、アプリケーションに定義されているすべてのポートレット・イベントが表示されます。
ポートレットで使用するポートレット・イベントを選択し、追加アイコンをクリックして「選択済」リストに移動します。
これにより、ポートレット・イベントが公開イベントとしてportlet.xmlのポートレット定義に追加されます。
<portlet id="1234567890">
...
<supported-publishing-event>
<name>myParam</name>
</supported-publishing-parameter>
...
</portlet>
portlet.xmlファイルを保存します。
これにより、このポートレット・イベントをポートレットのコード内で使用できるようになります。
パブリック・レンダラ・パラメータは、ポートレットがパラメータ値を共有することによりポートレット間の通信を可能にするJSR 286の機能です。
たとえば、地図ポートレットと天気ポートレットの両方が郵便番号のパブリック・レンダラ・パラメータを使用するように構成されている場合、地図ポートレットで郵便番号を入力すると、天気ポートレットでも同じパラメータ値が更新されます。
ポートレットによりサポートされるパブリック・レンダラ・パラメータは、ポートレット・デプロイメント・ディスクリプタ(portlet.xml)のアプリケーション・セクションで宣言する必要があります。このようにアプリケーション・レベルで定義されたパブリック・レンダラ・パラメータは、アプリケーション内のすべてのポートレットで使用できます。
アプリケーション内の個々のポートレットは、これらのパブリック・レンダラ・パラメータのうちのどれを使用するかを指定できます。
この項の内容は、次のとおりです。
パブリック・レンダラ・パラメータおよびその実装方法の詳細は、次のURLで提供されているJSR 286仕様を参照してください。
http://jcp.org/en/jsr/detail?id=286
パブリック・レンダラ・パラメータをポートレットで使用できるようにするには、まずそのパラメータをポートレット・デプロイメント・ディスクリプタ(portlet.xml)のアプリケーション・セクションで宣言する必要があります。
アプリケーション・レベルでパブリック・レンダラ・パラメータを定義する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「パラメータ」タブをクリックします。
「追加」アイコンをクリックして、新しいパブリック・レンダラ・パラメータを作成します。
ドロップダウン・リストから、パラメータに対する完全修飾名(QName)または名前のローカル部分のみのどちらを指定するのかを選択します。
QNameは、ローカル名のほかにパラメータに対する名前空間を指定することにより、複数のアプリケーション間でパブリック・レンダラ・パラメータを一意に識別します。ポートレット・コード内では、パブリック・レンダラ・パラメータをアプリケーション内で一意に識別する識別子を使用してパラメータにアクセスします。ただし、通常、1つのページには様々なアプリケーションからの複数のポートレットが含まれます。QNameを使用することにより、これらのポートレットがどのアプリケーションのものであるかにかかわらず、1つのポートレットからのパブリック・レンダラ・パラメータが同じページ上の他のポートレットに意図せずに干渉することを防げます。
パラメータの名前空間がアプリケーションのデフォルトの名前空間と同じである場合は、パラメータの定義時に未修飾名を指定することにより名前空間を省略できます。アプリケーションのデフォルトの名前空間が定義されていない場合は、未修飾名のパラメータにはXMLのデフォルトの名前空間が使用されます。
「修飾名」を選択した場合は、次を実行します。
「ネームスペース」フィールドに、パラメータに対する名前空間を入力します。
「名前」フィールドに、パラメータ名のローカル部分を入力します。
「未修飾名」を選択した場合は、「名前」フィールドにパラメータ名のローカル部分を入力します。パラメータは、パラメータの名前空間としてアプリケーションのデフォルトの名前空間(またはアプリケーションに対して名前空間が定義されていない場合はXMLのデフォルトの名前空間)を使用します。
「識別子」フィールドに、アプリケーション内でパブリック・レンダラ・パラメータを識別するための名前を入力します。
識別子はアプリケーション内で一意でなければならず、ポートレットにより使用されるパラメータを識別するため、またポートレット・コード内でパラメータにアクセスするために使用します。識別子を使用することにより、ポートレットの開発者はパラメータの完全修飾名を知っている必要はありません。より単純なアプリケーション固有の識別子を知っているだけで十分です。
「説明」フィールドに、パブリック・レンダラ・パラメータの説明を入力します。説明には、ポートレットの開発者がポートレット内でこのパラメータをどのように使用すべきか判断するために十分な情報を含める必要があります。
(オプション)「別名」パネルでは、QNameが異なる場合でも他のパブリック・レンダラ・パラメータからの値をパラメータが受け入れられるように、別名のリストを指定できます。
「作成」アイコンをクリックして、パラメータに対する新しい別名を作成します。
「ネームスペース」フィールドに、別名に対して使用するパラメータの名前空間を入力します。
「名前」フィールドに、別名に使用するパラメータ名のローカル部分を入力します。
|
注意: パブリック・レンダラ・パラメータに対する別名の作成時には、相互に別名を設定することをお薦めします。つまり、ポートレットAのパラメータにポートレットBのパラメータに対する別名がある場合は、可能であれば、ポートレットBのパラメータにもポートレットAのパラメータに対する別名を作成します。 |
パブリック・レンダラ・パラメータがportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<public-render-parameter> <description>This is my parameter</description> <identifier>myParam</identifier> <qname xmlns:x="http://example.com/params">x:myParam</qname> <alias xmlns:x="http://example.com/params">x:yourParam</alias> </public-render-parameter>
portlet.xmlファイルを保存します。
ポートレットでパブリック・レンダラ・パラメータがサポートされるようにするには、そのパラメータをポートレットに追加します。
パブリック・レンダラ・パラメータをポートレットに追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
ポートレット・プロデューサ・アプリケーション内でパブリック・レンダラ・パラメータがまだ定義されていない場合は、まずこれを定義する必要があります。詳細は、第61.2.6.1項「アプリケーション・レベルでのパブリック・レンダラ・パラメータの定義」を参照してください。
「ポートレット」タブをクリックし、パブリック・レンダラ・パラメータを使用するポートレットを選択します。
「パラメータ」タブをクリックします。
「イベントの公開中」パネルの「使用可能」リストに、アプリケーションに定義されているすべてのポートレット・イベントが表示されます。
「パラメータ」タブをクリックします。
「パブリック・レンダラ・パラメータ」パネルの「使用可能」リストには、そのアプリケーションに対して定義されているすべてのパブリック・レンダラ・パラメータが表示されます。
ポートレットで使用するパブリック・レンダラ・パラメータを選択し、「追加」アイコンをクリックして、パラメータを「選択済」リストに移動します。
これにより、パブリック・レンダラ・パラメータがportlet.xmlのポートレット定義に追加されます。
<portlet id="1234567890"> ... <supported-public-render-parameter>myParam</supported-public-render-parameter> ... </portlet>
portlet.xmlファイルを保存します。
これで、このパブリック・レンダラ・パラメータをポートレットのコードで使用できるようになりました。
ポートレット・プリファレンスを使用すると、エンド・ユーザーが実行時にポートレットをパーソナライズすることが可能になります。パーソナライズは実行したユーザーにのみ表示され、他のユーザーには表示されません。デフォルトでは、JDeveloperウィザードを使用してJSR 286ポートレットを作成すると、エンド・ユーザーが実行時にポートレットのタイトルをパーソナライズすることを可能にするポートレット・プリファレンスが作成されます。ポートレットの作成時に、またはポートレットの作成後にportlet.xmlを編集することにより、エンド・ユーザーが実行時にその他のパーソナライズを行うことを可能にする追加のポートレット・プリファレンスを作成できます。
この項の内容は、次のとおりです。
ポートレットのパーソナライズを追加するには、ユーザーにパーソナライズを許可するポートレットの属性に対するポートレット・プリファレンスを作成する必要があります。
ポートレットにポートレット・プリファレンスを追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「ポートレット」タブをクリックし、パーソナライズを追加するポートレットを選択します。
「詳細設定」タブをクリックします。
「プリファレンス」パネルに、portletTitleプリファレンスなど、ポートレットに対する既存のポートレット・プリファレンスが表示されます。
「追加」アイコンをクリックして、新しいポートレット・プリファレンスを作成します。
「名前」フィールドに、プリファレンスの名前を入力します。
名前はポートレット内で一意でなければならず、また文字、数字およびアンダースコアのみを使用する必要があります。
「値」フィールドに、プリファレンスに対する1つ以上のデフォルト値を入力します。複数の値はカンマで区切ります。
ユーザーがプリファレンスの値を更新できないようにする場合は、「読取り専用」を選択します。
これで、getPreferenceメソッドを使ってポートレット・コード内でこのプリファレンスを使用できるようになります。
|
注意: プリファレンスを翻訳可能にするには、適切なキーと値のペアをリソース・バンドル・クラスに追加する必要があります。 |
次の例は、ポートレットでパーソナライズを有効にする方法を簡単に示しています。
単純なパーソナライズをポートレットに追加する手順は次のとおりです。
JDeveloperのアプリケーション・ナビゲータで、ポートレットを含むアプリケーションを開きます。
そのポートレットを含むプロジェクトを開きます。
view.jspを右クリックし、「開く」を選択します。
ビジュアル・エディタで「ソース」タブをクリックし、例61-1で太字で示した、portletContentカスタマイズ・プリファレンスを表示するためのコードを追加します。
例61-1 view.jspのサンプル・コード
<%@ page contentType="text/html"
import="javax.portlet.*,java.util.*,Portlets.Portlet1,
Portlets.resource.Portlet1Bundle"%>
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
<portlet:defineObjects/>
<%
String[] str = {"Portlet Content"};
PortletPreferences prefs = renderRequest.getPreferences();
str = prefs.getValues("portletContent",str);
for (int i=0; i<str.length; i++)
{
%><%=(i<str.length-1)?str[i]+", ":str[i]%><%}%>
アプリケーション・ナビゲータでedit.jspを右クリックし、「開く」を選択します。
このJSPは、フォーム・フィールド、フォーム入力フィールドおよび2つのフォーム・ボタン・フィールドで構成されています。
ビジュアル・エディタで「ソース」タブをクリックし、例61-2で太字で示した、ユーザーがportletContentカスタマイズ・プリファレンスに対する値を入力するためのフォーム・フィールドを実装します。
例61-2 edit.jspのサンプル・コード
<%@ page contentType = "text/html; charset=windows-1252"
pageEncoding = "windows-1252"
import = "javax.portlet.*, java.util.*,
Portletenhance.Portletenhance,
Portletenhance.resource.PortletenhanceBundle"%>
@ <%@ taglib uri = "http://java.sun.com/portlet" prefix="portlet"%>
<portlet:defineObjects/>
<%
PortletPreferences prefs = renderRequest.getPreferences();
ResourceBundle res =
portletConfig.getResourceBundle(renderRequest.getLocale());
%>
<form action="<portlet:actionURL/>" method="POST">
<table border="0">
<tr>
<td width="20%">
<p class="portlet-form-field" align="right">
<%= res.getString(PortletenhanceBundle.PORTLETCONTENT) %>
</p>
</td>
<td width="80%">
<input class="portlet-form-input-field"
type="TEXT"
name="<%= Portletenhance.PORTLETCONTENT_KEY %>"
value="<%= Portletenhance.buildValue(prefs,
Portletenhance.PORTLETCONTENT_KEY) %>"
size="20">
</td>
</tr> <tr>
<td width="20%">
<p class="portlet-form-field" align="right">
<%= res.getString(PortletenhanceBundle.PORTLETTITLE) %>
</p>
</td>
<td width="80%">
<input class="portlet-form-input-field"
type="TEXT"
name="<%= Portletenhance.PORTLETTITLE_KEY %>"
value="<%= prefs.getValue(Portletenhance.PORTLETTITLE_KEY,
res.getString("javax.portlet.title")) %>"
size="20">
</td>
</tr>
<%
String[] str = {"Portlet Content"};
str = prefs.getValues("portletContent",str);
%>
<tr><td width="20%">
<p class="portlet-form-field" align="right">
Content
</p>
</td><td width="80%">
<textarea rows="10" cols="60" class="portlet-form-input-field"
name="portletContent"><%
for (int i=0; i<str.length; i++)
{%><%= (i<str.length-1) ? str[i]+", " : str[i] %><%}%>
</textarea>
</td></tr>
<tr>
<td colspan="2" align="center">
<input class="portlet-form-button" type="submit"
name="<%=Portletenhance.OK_ACTION%>"
value="<%=res.getString(PortletenhanceBundle.OK_LABEL)%>">
<input class="portlet-form-button" type="submit"
name="<%=Portletenhance.APPLY_ACTION%>"
value="<%=res.getString(PortletenhanceBundle.APPLY_LABEL)%>">
</td>
</tr>
</table>
</form>
アプリケーション・ナビゲータでportletName.javaを右クリックし、「開く」を選択します。
ビジュアル・エディタで「ソース」タブをクリックし、次の2行のコード(太字で示した)をprocessActionメソッドに追加します。
// Save the preferences. PortletPreferences prefs = request.getPreferences(); String param = request.getParameter(PORTLETTITLE_KEY); prefs.setValues(PORTLETTITLE_KEY, buildValueArray(param)); String contentParam = request.getParameter("portletContent"); if (contentParam != null) { prefs.setValues("portletContent", buildValueArray(contentParam)); } prefs.store();
ポートレットを再デプロイします。
JDeveloperによりコードが自動的に保存およびコンパイルされた上で、ポートレットがデプロイされます。この手順の実行方法の詳細は、第62章「ポートレットのテストとデプロイ」を参照してください。
ポートレットを含むページをリロードします。ポートレットには、加えた変更の1つである「Portlet Content」というテキストが表示されるようになっています。
「パーソナライズ」リンクをクリックすると、追加したフォーム・フィールドが表示されます。このフィールドに任意のテキストを入力し、ダイアログを閉じます。入力したテキストがポートレットに表示されます。
ポートレット・フィルタは、実行時にポートレットのコンテンツを変更することを可能にするJSR 286の機能です。ポートレット・フィルタは、ポートレット・リクエストおよびポートレット・レスポンスのコンテンツを変換できる、再利用可能なJavaコンポーネントです。通常、フィルタはポートレットのようにレスポンスを作成したり、リクエストに応答したりはせず、リクエストおよびレスポンスを変更または調整します。
この項の内容は、次のとおりです。
ポートレット・フィルタおよびその実装方法の詳細は、次のURLで提供されているJSR 286仕様を参照してください。
http://jcp.org/en/jsr/detail?id=286
ポートレットでポートレット・フィルタを使用するには、まずアプリケーション内でそのフィルタを定義する必要があります。
アプリケーションにポートレット・フィルタを追加する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「フィルタ」タブをクリックします。
「追加」アイコンをクリックして、新しいポートレット・フィルタを作成します。
「ポートレット・フィルタの作成」ダイアログで、ポートレット・フィルタを実装する新しいフィルタ・クラスする場合は「新規ポートレット・フィルタ」を選択します。手順5に進んでください。
ポートレット・フィルタを実装するフィルタ・クラスがすでに存在する場合は、「既存のクラスから選択」を選択し、フィルタ・クラスを入力するか参照します。手順9に進んでください。
「名前」フィールドに、ポートレット・フィルタの名前を入力します。
名前はアプリケーション内で一意でなければならず、また文字、数字およびアンダースコアのみを使用する必要があります。
「パッケージ」フィールドで、新しいフィルタ・クラスを含めるパッケージを入力するか参照します。
1つ以上の「ライフサイクル・フェーズ」チェック・ボックスを選択して、フィルタ・クラスにどのjavax.portlet.filterインタフェースを実装するかを指定します。
アクション: フィルタ・クラスにはActionFilterインタフェースが実装されます。
イベント: フィルタ・クラスにはEventFilterインタフェースが実装されます。
レンダリング: フィルタ・クラスにはRenderFilterインタフェースが実装されます。
リソース: フィルタ・クラスにはResourceFilterインタフェースが実装されます。
|
注意: 「ポートレット・フィルタの作成」ダイアログでフィルタ・クラスを作成する場合は、フィルタ・クラスにどのフィルタ・インタフェースを実装するかを指定できます。フィルタ・クラスの作成後は、概要エディタでフィルタ・インタフェースを追加または削除することはできません。かわりに、フィルタ・クラスのソースを直接編集し、インタフェースおよびこれらのインタフェースに対して定義される |
「OK」をクリックします。
「表示名」フィールドに、ポートレット・フィルタに対するわかりやすい名前を入力します。
「説明」フィールドに、ポートレット・フィルタの説明を入力します。
「初期化パラメータ」パネルでは、フィルタ・クラスのinit()メソッドに値を渡す初期化パラメータを指定できます。
「追加」アイコンをクリックして、ポートレット・フィルタに対する初期化パラメータを指定します。
「名前」フィールドに、初期化パラメータの名前を入力します。
「値」フィールドに、初期化パラメータに渡す値を入力します。
「説明」フィールドに、初期化パラメータの説明を入力します。
ポートレット・フィルタがportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<filter>
<display-name>Test Filter</display-name>
<filter-name>filter_1</filter-name>
<filter-class>javaportlets.MyFilter</filter-class>
<lifecycle>ACTION_PHASE</lifecycle>
<lifecycle>RENDER_PHASE</lifecycle>
</filter>
portlet.xmlファイルを保存します。
アプリケーションでポートレット・フィルタを定義したら、そのフィルタをアプリケーション内の1つ以上のポートレットに適用できます。ポートレット・フィルタをポートレットに適用する順序も指定できます。
ポートレットにポートレット・フィルタを適用する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「フィルタ・マッピング」タブをクリックします。
「追加」アイコンをクリックして、フィルタ・マッピング表に行を追加します。
「フィルタ名」ドロップダウン・リストから、ポートレットに適用するポートレット・フィルタを選択します。
ドロップダウン・リストには、portlet.xmlファイルで定義されているすべてのポートレット・フィルタが表示されます。
「ポートレット名」ドロップダウン・リストから、ポートレット・フィルタを適用するポートレットを選択します。
ドロップダウン・リストには、portlet.xmlファイルで定義されているすべてのポートレットが表示されます。
またはワイルドカードを使用して、ポートレット・フィルタを1つ以上のポートレットに適用することもできます。たとえば*と入力して、ポートレット・フィルタをアプリケーション内のすべてのポートレットに適用することができます。
フィルタ・マッピングがportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<filter-mapping>
<filter-name>filter_1</filter-name>
<portlet-name>jsrportlet4</portlet-name>
</filter-mapping>
「上」、「上へ」、「下へ」および「下」アイコンを使用して、portlet.xmlファイル内でのポートレット・フィルタの順序を指定します。ポートレット・フィルタの順序により、ポートレットに適用されるフィルタの順序が決まります。
|
注意: フィルタは複数のポートレットにマップされている場合があることに注意してください。複数のポートレットが1つのフィルタにマップされている(フィルタを共有している)場合、フィルタの順序を勝手に変更すると、望ましくない影響が発生することがあります。たとえば、1つのポートレットでフィルタが適用される順序を変更すると、その変更は同じフィルタを共有するその他すべてのポートレットにも適用されます。 |
portlet.xmlファイルを保存します。
ポートレットの基本機能の設定が完了した後は、ポートレットのパフォーマンスに注目する必要があります。
キャッシュは、高度な動的コンテンツを含むWebサイトのパフォーマンスの向上に使用される一般的な手法です。この手法では、キャッシュと呼ばれる待機時間の短い大きなデータ・ストアを備えたローカル・エージェントを使用してリクエストをプロキシ化することで、動的コンテンツのデータの取得と出力の生成に伴うオーバーヘッドを大幅に削減できます。キャッシュ・エージェントは、リクエストに対して次のいずれかの方法で応答します。
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在する場合、エージェントは既存のキャッシュ・コピーをそのまま戻します。これによって、コンテンツの取得と生成というコストがかかるプロセスを省くことができます。この状況をキャッシュ・ヒットと呼びます。
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在しない場合、エージェントはリクエストをその宛先に転送し、コンテンツが戻されるのを待機します。エージェントはコンテンツをリクエスト元に戻し、そのキャッシュ内にローカル・コピーを格納して、同じコンテンツに対するリクエストが後で発生した場合に再利用します。この状況をキャッシュ・ミスと呼びます。
プロデューサは、動的コンテンツ(つまり、ポートレット)の生成元であり、多くの場合、デプロイされているFrameworkアプリケーション・インスタンスから離れた場所にあります。このため、キャッシュによるパフォーマンス向上が可能となります。アーキテクチャは、キャッシュに適切です。プロデューサでレンダリングされたポートレットをキャッシュし、キャッシュされたコピーを再利用して後続のリクエストを処理することによって、プロデューサがページ作成にもたらすオーバーヘッドを最小限にできます。
JSR 286ポートレットには2つのキャッシュ方法があります。これらのキャッシュ方法の主な違いは、コンテンツが有効かどうかを判断する方法にあります。
有効期限ベースのキャッシュ: プロデューサはレンダリング・リクエストを受信すると、そのレスポンスに有効期限のスタンプを付けます。レンダリングされたレスポンスはキャッシュに格納され、同じコンテンツに対する後続のすべてのリクエストは、有効期限が経過するまで、このキャッシュを使用して処理されます。このキャッシュ・スキームは最も簡単でパフォーマンスが優れていると考えられます。それは、キャッシュの有効性をテストするためのオーバーヘッドがほとんどなく、ネットワークのラウンドトリップを伴わないためです。有効期限ベースのキャッシュは、コンテンツの使用期間が効率よく定義されているアプリケーションに適しています。コンテンツの使用期間が確実ではない場合、有効期限ベースのキャッシュは効果的ではありません。詳細は、第61.2.9.1項「有効期限ベースのキャッシュの実装」を参照してください。
有効化ベースのキャッシュ: レンダリング・リクエストを受信したプロデューサは、そのレスポンスにバージョン識別子(またはETag)のスタンプを付けます。この方法でもレスポンスはキャッシュされますが、コンシューマはキャッシュされたレスポンスを再利用する前に、キャッシュされたバージョンがまだ有効かどうかを判断する必要があります。そのために、キャッシュされたコンテンツのバージョン識別子を含めたレンダリング・リクエストをプロデューサに送信します。プロデューサは、このバージョン識別子が有効であるかどうかを判断します。バージョン識別子が有効である場合、プロデューサはコンテンツを含まない軽量のレスポンスをコンシューマに即座に送信し、キャッシュされたバージョンを再利用できることを通知します。バージョン識別子が無効な場合、プロデューサは新しいバージョン識別子を含む新しいコンテンツを生成し、以前にキャッシュされたバージョンを置き換えます。このキャッシュ方法では、コンシューマは、常にプロデューサに対してコンテンツが最新かどうかを確認する必要があります。キャッシュされたコピーの有効性は、プロデューサのロジックによって判断されます。この方法では、固定期間に依存するのではなく、キャッシュされたコンテンツの使用をプロデューサが管理できるという利点があります。詳細は、第61.2.9.2項「有効化ベースのキャッシュの実装」を参照してください。
この項の内容は、次のとおりです。
JSR 286ポートレットの作成ウィザードを使用してポートレットを最初に作成する際に、有効期限ベースのキャッシュを実装することを選択できます。ただしポートレットの初期開発段階ではポートレット・キャッシュを無効にし、開発の後の段階でポートレット・コンテンツがより安定してから実装した方が良い場合もあります。また、有効期限の編集やキャッシュ・スコープの変更が必要になることもあります。
有効期限ベースのキャッシュを実装する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「ポートレット」タブをクリックし、有効期限ベースのキャッシュを実装するポートレットを選択します。
「詳細設定」タブをクリックします。
「キャッシュ管理」パネルで「キャッシュ・ポートレット」を選択します。
|
注意: ポートレット・キャッシュを無効にするには、「キャッシュ・ポートレット」の選択を解除します。これにより、キャッシュの有効期限が |
「キャッシュ・スコープ」を選択します。
キャッシュ・コンテンツをユーザー間で共有する場合は「パブリック」を選択します。
キャッシュ・コンテンツをユーザー間で共有しない場合は「プライベート」を選択します。
キャッシュの有効期限を指定します。
キャッシュの有効期限を-1に設定するには、「キャッシュ・コンテンツ失効なし」を選択します。これは、キャッシュ・コンテンツが失効することはなく、コンテンツが常にキャッシュから取得されることを意味します。このオプションは、ポートレットに変更される可能性の低い静的コンテンツが含まれていることが確実である場合に使用します。このオプションを設定すると、portlet.xmlファイルに次のコードが追加されます。
<portlet> ... <expiration-cache>-1</expiration-cache> ... </portlet>
キャッシュされたポートレット・コンテンツを指定した秒数後に失効させるには、「キャッシュ・コンテンツ有効期限」を選択します。隣のフィールドに有効期限を秒単位で入力します。このオプションを設定すると、portlet.xmlファイルに次のコードが追加されます。
<portlet> ... <expiration-cache>300</expiration-cache> ... </portlet>
portlet.xmlファイルを保存します。
有効化ベースのキャッシュの実装はポートレットの初期作成後に行い、ハンドコーディングが必要です。
例61-3は、コンシューマが有効化ベースのキャッシュを使用してマークアップをキャッシュするようにGenericPortletでdoView()メソッドを実装する場合の一般的な方法を示します。この例では、有効期限ベースのキャッシュをプログラムで定義し(CacheControl.setExpirationTime()メソッドを使用して)、有効化ベースのキャッシュとともに使用することにより、プロデューサの負荷を減らす方法も示します。この方法はserveResource()に対しても同様に使用できます。
例61-3 有効化ベースのキャッシュを実装するJSR 286ポートレット
protected void doView (RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
CacheControl cacheControl = response.getCacheControl();
String eTag = request.getETag();
if (isMarkupStillValid(eTag))
{
cacheControl.setExpirationTime(30); // Wait 30 seconds before checking ETag again
cacheControl.setUseCachedContent(true); // Tell consumer to use its cached content
return;
}
// ETag not valid so set a new one ...
cacheControl.setETag(generateETag(...)); // Define a new ETag
cacheControl.setExpirationTime(60); // Wait 60 seconds before checking ETag again
// ... and generate fresh portlet markup
createMarkup(request, response);
}
private boolean isMarkupStillValid(String eTag)
{
if (eTag == null)
{
return false; // No ETag was supplied
}
// Perform portlet specific checks for the consumer's cached
// copy of the markup still being valid based on the given ETag
...
}
private String generateETag(...)
{
// Portlet specific code to generate an ETag, for example, a hash
// of the data on which the portlet's markup is based
...
return eTag;
}
JSR 286ポートレットでの有効化ベースのキャッシュの詳細は、次のURLで提供されているJSR 286仕様を参照してください。
WSRP 2.0で提供されるもう1つの新機能は、ポートレットを1つのデプロイメントから別のデプロイメントに移動する際に、ポートレットのカスタマイズを維持する能力です。カスタマイズは、デフォルト編集モードで設定されたポートレット・プリファレンスです。たとえば、ポートレットを作成し、開発環境内でそのタイトルをカスタマイズしたとします。そのプロデューサに対するエクスポートを有効にしたとすると、カスタマイズされたタイトルは、ポートレットを本番環境にデプロイする際に、ポートレットとともにトランスポートされます。エクスポートを有効にしないと、ポートレットをあるデプロイメント環境から別のデプロイメント環境にトランスポートする際に、カスタマイズはすべて失われてしまいます。
ポートレットのカスタマイズのエクスポートを実装する手順は次のとおりです。
portlet.xmlファイルの概要エディタを開きます。詳細は、第61.2.1項「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「アプリケーション」タブの「コンテナ・ランタイム・オプション」セクションで、「追加」アイコンをクリックしてcom.oracle.portlet.allowWsrpExportを選択します。
新たに追加されたコンテナ・ランタイム・オプションに対する行で、「値」フィールドをダブルクリックして編集し、trueと入力します。
portlet.xmlファイルを保存します。
リソース・プロキシは、WSRPでリソースを取得する標準的な方法です。ポートレット内でのURLの問題を回避するには、指定したリソース内のURLをすべて書きなおすためのフラグを設定できます。たとえば、URLを含むHTMLのフラグメントがある場合、WSRPリソース・プロキシを考慮に入れてURLを書きなおすために、このフラグを設定できます。
URLを書きなおす必要があることを示すために、PortletRequest属性のoracle.portlet.server.resourceRequiresRewritingをtrueに設定します。たとえばエンコード中のURLにリソース・プロキシを使用するには、例61-4に示すようなコードを含めます。このコードをメソッド内にカプセル化して、URLごとにこれを繰り返すことを回避します。
例61-4 WSRP用のリソース・プロキシ
request.setAttribute("oracle.portlet.server.resourceRequiresRewriting",
Boolean.TRUE);
String url = response.encodeURL(pathToResourceForRewriting);
request.removeAttribute("oracle.portlet.server.resourceRequiresRewriting");
oracle.portlet.server.resourceRequiresRewritingを明確に設定しないと、falseにデフォルト設定され、URLが書きなおされなくなります。この属性をtrueに設定することで、機能を明示的にアクティブにする必要があります。
プロトコル・リソースに書きなおしが不要なものがある場合は、ステートレス・リソース・プロキシを使用できます。ステートレス・リソース・プロキシとは、ブラウザに返されるURLにポートレットIDやその他のコンテキスト情報が必要ないことを意味します。これにより、このようなリソースに対するキャッシュ・ヒット率が高くなります。ステートレス・リソース・プロキシは、静的JavaScriptファイル、静的イメージなどの機能に有用です。
ステートレス・プロキシが必要であることを示すために、PortletRequest属性のoracle.portlet.server.useStatelessProxyingをtrueに設定します。たとえばエンコード中のURLにステートレス・プロキシを使用するには、例61-5に示すようなコードを含めます。このコードをメソッド内にカプセル化して、URLごとにこれを繰り返すことを回避します。
例61-5 ステートレス・リソース・プロキシ
request.setAttribute("oracle.portlet.server.useStatelessProxying", Boolean.TRUE);
String url = response.encodeURL(pathToResource);
request.removeAttribute("oracle.portlet.server.useStatelessProxying");
oracle.portlet.server.useStatelessProxyingを明確に設定しないと、falseにデフォルト設定されます。この属性をtrueに設定することで、機能を明示的にアクティブにする必要があります。
プリファレンス・ストアのパフォーマンスを向上させるために、プリファレンス・ストアへのアクセスにJavaオブジェクト・キャッシュを使用することを選択できます。これにより、リクエストごとに永続ストアにアクセスする必要がなくなります。次のJNDI変数を使用して、WSRPプリファレンス・ストアでのキャッシュの使用を構成できます。
oracle/portal/wsrp/server/enableJavaObjectCache
デフォルトで、この変数はfalseに設定されています。次のようにして、ユーザー自身が、ポートレット・プロデューサ・アプリケーション用のweb.xmlファイルに変数を設定できます。
<env-entry> <env-entry-name>oracle/portal/wsrp/server/enableJavaObjectCache</env-entry-name> <env-entry-type>java.lang.Boolean</env-entry-type> <env-entry-value>true</env-entry-value> </env-entry>
JNDI変数設定の詳細は、第61.3.5.2項「JNDI変数値の設定」を参照してください。
WSRPプロデューサ側とクライアント側でセキュリティを構成することにより、WSRPプロデューサにデプロイされるJSR 286ポートレットを保護できます。WSRPプロデューサによるJSR 286ポートレットの保護の詳細は、第69.17項「WS-Securityを使用したWSRPプロデューサを介するアイデンティティ伝播の保護」を参照してください。
第60.2.4項「PDK-Javaポートレットの作成方法」の説明に従ってPDK-Javaポートレットの作成ウィザードで初期ポートレットを構築したら、次はそれを拡張します。PDK-Java用の参照JavaDocは、Oracle Fusion Middleware Oracle PDK Java Java APIリファレンスにあります。
この項では、実行できるいくつかの拡張機能について説明します。この項の内容は、次のとおりです。
この項で参照される多数の例のソース・コードは、Portlet Developer's Kit (PDK)の一部として提供されています。
PDK-Javaを解凍すると、次の場所に例があります。
../pdk/jpdk/v2/src/oracle/portal/sample/v2/devguide
WebCenter Portal: Frameworkでは、PDK-Javaポートレットは、Oracle Portalの場合とは少し異なる働きをします。そのため、WebCenter Portal: FrameworkでPDK-Javaポートレットを作成する際、次の新しい設計上の検討事項を認識しておく必要があります。
ポートレットには、リクエストでポートレットによって明示的に追加されなかったURLの書式またはパラメータに依存するコードを含めないでください。
ポートレットのモードに関係なく、作成したポートレットがページ上で唯一のポートレットであると想定しないでください。たとえば、作成したポートレットが編集モードであっても、そのポートレットがページ上の唯一のポートレットであるとは考えないでください。
簡単にリダイレクトするポートレット・モードを記述しないでください。リダイレクトは、ポートレットに対するポストの処理中、またはポートレットによって生成されたリンクをたどる間にのみ発行できます。
Oracle PDK-Javaポートレットの作成ウィザードでは、ウィザード・ページのチェック・ボックスを選択することによりポートレット・モードを追加します。ウィザードの使用方法の詳細は、第60.2.4項「PDK-Javaポートレットの作成方法」を参照してください。ウィザードで選択したポートレット・モードごとに、基本的なスケルトンが作成されています。ポートレットの作成後にポートレット・モードを追加する必要がある場合、provider.xmlおよびHTMLまたはJSPをJDeveloperで更新することにより、手動で追加できます。
RenderManagerを使用してポートレット・モードを実装する原理は、どのモードについても同じです。
この項で使用するPDKランタイム・クラスの詳細は、Oracle Fusion Middleware Oracle PDK Java Java APIリファレンスのJavaDocを参照してください。
provider.xmlの構文の詳細は、同じくOTNで提供されているプロバイダのJavaDocを参照してください。
開始する前に
ここで説明する手順は、次のことを前提としています。
PDK-Javaポートレットの作成ウィザードを使用してポートレットを構築済であること
ポートレットのプロデューサが正しく登録されていること
ポートレットがページに追加されていること
ポートレット・モードを追加する手順は次のとおりです。
JDeveloperのアプリケーション・ナビゲータで、ポートレットを含むアプリケーションを開きます。
そのポートレットを含むプロジェクトを開きます。
「Webコンテンツ」ノード、「htdocs」ノード、プロデューサのノードの順に開きます。
ポートレットのノードを右クリックし、「新規」を選択します。
ポートレットのノードは、「Webコンテンツ」→「htdocs」→プロバイダの下にあります。
「新規ギャラリ」で「Web層」を開き、「HTML」または「JSP」を選択し、「OK」をクリックします。
ポートレットに追加するモードごとに、HTMLファイルまたはJSPを作成する必要があります。たとえばヘルプ・モードを実装するには、ヘルプ・コンテンツを提供するためのHTMLファイルを作成します。
表示されるダイアログで、HTMLファイルまたはJSPに対するファイル名を入力し、「OK」をクリックします。
ビジュアル・エディタで、必要な機能を実装するページのコンテンツを編集します。
たとえば、ヘルプ・モードの場合は次のHTMLを追加できます。
<p>This is the <i>Help</i> mode of your portlet!</p>
アプリケーション・ナビゲータで、ポートレットが属するプロバイダのprovider.xmlファイルを右クリックして「開く」を選択します。
provider.xmlファイルは、「Webコンテンツ」→「WEB-INF」→「プロバイダ」→プロバイダの下にあります。
追加するモードに対する適切なタグの値をtrueに変更します。
たとえばヘルプ・モードを追加する場合は、hasHelpタグを次のように変更します。
<hasHelp>true</hasHelp>
これは、そのモードへのリンクまたはアイコンをレンダリングする必要があることをPDKフレームワークに示します。
そのモードに対して前の手順で作成したHTMLページまたはJSPを指定するコードを追加します。
たとえばヘルプ・ページについては、次のコードを追加します。
<helpPage>/htdocs/myprovider/myportlet/myHelpPage.html</helpPage>
変更を保存します。
ポートレットを再デプロイします。詳細は、第62章「ポートレットのテストとデプロイ」を参照してください。
再デプロイする場合は、JDeveloperにより、コードが自動的に保存およびコンパイルされた上で、ポートレットがデプロイされます。
作成したHTMLファイルまたはJSPと更新したprovider.xmlファイルを、ポートレットをデプロイするWLSインスタンスにコピーします。
プロデューサ・アプリケーションをサーバー・インスタンスに再デプロイ済である場合は、この手順は不要です。
プロデューサをリフレッシュします。
ポートレットが含まれているページをリフレッシュします。
これで、新しいモードにアクセスできるようになります。たとえばヘルプ・モードを追加した場合は、「ヘルプ」をクリックできます。
PDK-JavaおよびWebCenter Portal: Frameworkは、ポートレット開発者が再利用可能で複雑なポートレットを簡単に作成できるように、パブリック・ポートレット・パラメータおよびプライベート・ポートレット・パラメータを提供しています。JDeveloperのOracle PDK-Javaポートレットの作成ウィザードは、パラメータを使用するように設定されたポートレットを作成します。この機能によって、開発者はビジネス・ロジックをポートレットに追加するのみで、provider.xmlを変更する必要はありません。
パラメータの概要については、第58.2.11項「パブリック・ポートレット・パラメータのサポート」および第58.2.12項「プライベート・ポートレット・パラメータのサポート」を参照してください。
開始する前に
ここで説明する手順は、次のことを前提としています。
第60.2.4項「PDK-Javaポートレットの作成方法」を読み終えて理解していること。
ウィザードで作成したポートレットがページに正常に追加されていること。
|
注意: 各ポートレットのデータは4Kに制限されています。パラメータ、イベント名、表示名および説明の各長さもすべてこの4Kの制限に対するカウント対象に含まれます。このため、各ポートレットに対して必要以上の数のパラメータやイベントを使用しないこと、またはこれらの名前や説明を長くしないことが必要です。 |
Oracle PDK-Javaポートレットの作成ウィザードを使用すると、パブリック・パラメータを使用するポートレットを容易に作成できます。プロデューサを登録し、ページ上にポートレットをドロップすると、ポートレットのパラメータがページの変数に自動的にリンクされます。
パブリック・パラメータを使用するポートレットを作成する手順は次のとおりです。
JDeveloperのアプリケーション・ナビゲータで、ポートレットを含むアプリケーションを開きます。
ポートレットの作成先であるプロジェクトを右クリックし、「新規」を選択します。
|
注意: 既存のプロデューサにポートレットを作成するには、プロデューサの |
「新規ギャラリ」で、「Web層」を開き、「ポートレット」を選択して、「Oracle PDK-Javaポートレット」を選択し、「OK」をクリックします。
「パブリック・ポートレット・パラメータ」ページが表示されるまで、Oracle PDK-Javaポートレットの作成ウィザードの手順を進めます。
ウィザードの手順の進め方についての基本情報は、第60.2.4項「PDK-Javaポートレットの作成方法」を参照してください。
「パブリック・ポートレット・パラメータ」ページ(図61-2)で、「追加」をクリックします。
これにより、パラメータの表に新しい行が追加されます。
「名前」、「表示名」および「説明」フィールドのデフォルト値を、パラメータに対する意味のある値で置き換えます。
必要に応じてパラメータを追加し、「終了」をクリックします。
アプリケーション・ナビゲータで、ポートレットが属するプロバイダのprovider.xmlファイルを右クリックして「開く」を選択します。
provider.xmlファイルは、「Webコンテンツ」→「WEB-INF」→「プロバイダ」→プロバイダの下にあります。
ウィザードの「パブリック・ポートレット・パラメータ」ページで追加したパラメータのエントリが、例61-6に示すように表示されます。
例61-6 provider.xmlのサンプル・パブリック・パラメータ
<?xml version = '1.0' encoding = 'UTF-8'?><?providerDefinition version="3.1"?>
<provider class="oracle.portal.provider.v2.DefaultProviderDefinition">
<session>false</session>
<passAllUrlParams>false</passAllUrlParams>
<preferenceStore class=
"oracle.portal.provider.v2.preference.FilePreferenceStore">
<name>prefStore1</name>
<useHashing>true</useHashing>
</preferenceStore>
<portlet class="oracle.portal.provider.v2.DefaultPortletDefinition">
<id>1</id>
<name>MyPortlet</name>
<title>My Portlet</title>
<description>My Portlet Description</description>
<timeout>40</timeout>
<showEditToPublic>false</showEditToPublic>
<hasAbout>false</hasAbout>
<showEdit>true</showEdit>
<hasHelp>false</hasHelp>
<showEditDefault>false</showEditDefault>
<showDetails>false</showDetails>
<inputParameter class=
"oracle.portal.provider.v2.DefaultParameterDefinition">
<name>Parameter_01</name>
<displayName>Parameter_01</displayName>
<description>My first parameter</description>
</inputParameter>
<inputParameter class=
"oracle.portal.provider.v2.DefaultParameterDefinition">
<name>Parameter_02</name>
<displayName>Parameter_02</displayName>
<description>My second parameter</description>
</inputParameter>
<inputParameter class=
"oracle.portal.provider.v2.DefaultParameterDefinition">
<name>Parameter_03</name>
<displayName>Parameter_03</displayName>
</inputParameter>
<renderer class="oracle.portal.provider.v2.render.RenderManager">
<renderContainer>true</renderContainer>
<renderCustomize>true</renderCustomize>
<autoRedirect>true</autoRedirect>
<contentType>text/html</contentType>
<showPage>/htdocs/myportlet/MyPortletShowPage.jsp</showPage>
<editPage>/htdocs/myportlet/MyPortletEditPage.jsp</editPage>
</renderer>
<personalizationManager class=
"oracle.portal.provider.v2.personalize.PrefStorePersonalizationManager">
<dataClass>
oracle.portal.provider.v2.personalize.NameValuePersonalizationObject
</dataClass>
</personalizationManager>
</portlet>
</provider>
アプリケーション・ナビゲータで、ポートレットに対するportletnameShowPage.jspを右クリックし、「開く」を選択します。
このファイルは、「Webコンテンツ」→「htdocs」→プロバイダ→ポートレットの下にあります。
たとえば図61-2に示すように、ポートレットにはパラメータを取得するためのロジックが含まれます。
例61-7 ShowPage.jspのサンプル
<%@page contentType="text/html; charset=windows-1252"
import="oracle.portal.provider.v2.render.PortletRenderRequest"
import="oracle.portal.provider.v2.http.HttpCommonConstants"
import="oracle.portal.provider.v2.ParameterDefinition"
%>
<%
PortletRenderRequest pReq = (PortletRenderRequest)
request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
%>
<P>Hello <%= pReq.getUser().getName() %>.</P>
<P>This is the <b><i>Show</i></b> render mode!</P>
<%
ParameterDefinition[] params =
pReq.getPortletDefinition().getInputParameters();
%>
<p>This portlet's input parameters are...</p>
<table align="left" width="50%" ><tr><td><span
class="PortletHeading1">Name</span></td><td><span
class="PortletHeading1">Value</span></td></tr>
<%
String name = null;
String value = null;
String[] values = null;
for (int i = 0; i < params.length; i++)
{
name = params[i].getName();
values = pReq.getParameterValues(name);
if (values != null)
{
StringBuffer temp = new StringBuffer();
for (int j = 0; j < values.length; j++)
{
temp.append(values[j]);
if (j + 1 != values.length)
{
temp.append(", ");
}
}
value = temp.toString();
}
else
{
value = "No values have been submitted yet.";
}
%>
<tr>
<td><span class="PortletText2"><%= name %></span></td>
<td><span class="PortletText2"><%= value %></span></td>
</tr>
<%
}
%>
</table>
ポートレットに、ユーザーが入力したパラメータ値を送信できるようにするロジックを追加します。
同じ手順を使用して、取得したパラメータ値を単に表示する2つ目のポートレットを作成します。
プロデューサをFrameworkアプリケーションに登録します。詳細は、第64.2.3項「Oracle PDK-Javaポートレット・プロデューサの登録方法」を参照してください。
2つのポートレットをアプリケーション内のページに追加します。詳細は、第64.3項「ページへのポートレットの追加」を参照してください。
アプリケーション・ナビゲータの「構造」ウィンドウでページの要素を右クリックし、「ページ定義に移動」を選択します。
ページ定義は、例61-8のようになります。ページ・レベルの変数とポートレット・レベルのパラメータ(太字で示した)に注意してください。
例61-8 ページ定義ファイルのサンプル
<?xml version="1.0" encoding="UTF-8"?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"
version="10.1.3.38.90" id="untitled1PageDef"
Package="view.pageDefs">
<executables>
<variableIterator id="variables">
<variable Name="portlet1_Parameter_01" Type="java.lang.Object"/>
<variable Name="portlet1_Parameter_02" Type="java.lang.Object"/>
<variable Name="portlet1_Parameter_03" Type="java.lang.Object"/>
</variableIterator>
<portlet id="portlet1" portletInstance="/oracle/adf/portlet/PdkPortletProducer1_1153936627784
/applicationPortlets/Portlet1_abfc5a10_010c_1000_8003_82235f50d831"
class="oracle.adf.model.portlet.binding.PortletBinding"
xmlns="http://xmlns.oracle.com/portlet/bindings">
<parameters>
<parameter name="Parameter_01" pageVariable="portlet1_Parameter_01"/>
<parameter name="Parameter_02" pageVariable="portlet1_Parameter_02"/>
<parameter name="Parameter_03" pageVariable="portlet1_Parameter_03"/>
</parameters>
</portlet>
</executables>
</pageDefinition>
アプリケーションを実行します。
1つ目のポートレットに値を入力すると、同じ値が2つ目のポートレットに表示されるはずです。
場合によっては、そのポートレット・インスタンスに対してのみ認識されるパラメータが必要なことがあります。これらのパラメータは、ページには関係がなく、ポートレットに対してのみ認識されるため、プライベート・パラメータとして知られています。プライベート・パラメータは、ポートレットのナビゲーション作成中に思いがけずに役に立つことがよくあります。たとえば、複数ページから構成されるポートレットがある場合、これらのプライベート・パラメータを使用して、ポートレットの別のリソースにジャンプすることができます。
この項の内容は、次のとおりです。
プライベート・パラメータは、標準的なWebアプリケーションで情報をブラウザのリンクまたはフォームからサーバーに渡すために使用されます。サーバーはこれに対して処理を行い、適切なコンテンツを戻します。たとえば、ディクショナリWebサイトのユーザーがハリネズミに関する情報を求めると、サーバーに送信されるURLには、プライベート・パラメータが次のように追加されます。
http://dictionary.reference.com/search?q=Hedgehog
サーバーがページ全体のレンダリングを担当し、クライアントがサーバーと直接通信する場合、このURLのフォームは非常に役に立ちます。Frameworkアプリケーションの場合、クライアントはポートレットと直接通信しません。かわりに、WebCenter Portal: Frameworkが、クライアントとポートレットの間を仲介します。また、ほとんどのページには複数のポートレットがあるため、WebCenter Portal: Frameworkは複数のポートレットと通信します。
たとえば、ページにシソーラス・ポートレットとディクショナリ・ポートレットという2つのポートレットがあるとします。これら2つのポートレットはqをパラメータとして使用して、ユーザーによって実行された検索問合せを記録します。ユーザーがシソーラス・ポートレットを問い合せる場合、更新されたシソーラス・ポートレットがあるページを再リクエストするためのURLには、シソーラス・ポートレットのパラメータqを含める必要があります。また、このシソーラス・パラメータは、このポートレットに対して同じ機能を実行するディクショナリ・ポートレット・パラメータ1とは区別する必要があります。
ポートレットが、次の基準を満たしていることを確認する必要があります。
ポートレット独自のパラメータがリンクおよびフォームに組み込まれるときにポートレットがこれらのパラメータを正しく修飾していること。
ポートレットに属さないパラメータをポートレットで変更しないこと。
次のAPIコールは、非修飾パラメータ名を修飾パラメータ名に変換します。
HttpPortletRendererUtil.portletParameter(HttpServletRequest request, String param);
HttpPortletRendererUtilは、パッケージoracle.portal.provider.v2.render.httpに含まれています。
次に例を示します。
qualParamQ = HttpPortletRendererUtil.portletParameter(r, "q");
受信リクエストからポートレット・パラメータの値をフェッチするには、次のAPIを使用します。
|
注意: このAPIは、受信リクエストから値をフェッチする前にパラメータ名を修飾パラメータ名に変換します。このため、この手順を実行する必要はありません。 |
PortletRenderRequest.getQualifiedParameter(String name)
PortletRenderRequestは、パッケージoracle.portal.provider.v2.renderに含まれています。
次に例を示します。
valueQ = r.getQualifiedParameter("q");
プライベート・パラメータに関するポートレットの役割には、ポートレットに属さないURLパラメータを妨害しないという側面もあります。このルールに準拠するために使用するユーティリティの詳細は、第61.3.4.3項「ポートレットのURLタイプを使用したリンクの構築」および第61.3.4.4項「ポートレットのURLタイプを使用したフォームの構築」を参照してください。
ポートレットが自身をレンダリングする場合、WebCenter Portal: Frameworkではポートレットに様々なURLを渡し、ポートレットはそれらを使用してリンクをレンダリングします。これらのURLをフェッチし、操作して、リンク作成のタスクを簡略化できます。ポートレットに提供されるURLのリストは、次のとおりです。
PAGE_LINK: ポートレット・インスタンスがあるページのURLです。このURLは、すべてのポートレット内リンクのベースとして使用します。ユーザーを同じポートレットの別のセクションにナビゲートするリンクをポートレットでレンダリングする場合、このナビゲーションは、PAGE_LINKを使用してパラメータ・セットとしてエンコードする必要があります。
DESIGN_LINK: ポートレットのパーソナライズ(編集モード)ページのURLです。ポートレットの編集モードおよびデフォルト編集モードは、ポートレットと同じページ上にはレンダリングされません。編集モードおよびデフォルト編集モードは、ブラウザ・ウィンドウ全体を占有します。ポートレットの編集モードおよびデフォルト編集モードは、必ずしもすべてのユーザーがアクセスできるとはかぎりません。このページは、ポートレットがそのパーソナライズオプションを自由にレンダリングできる最小限の静的フレームワークです。このURLは、パーソナライズ・リンクをレンダリングする際にのみ役立ちます。
BACK_LINK: ポートレットが自身をレンダリングする現行ページから戻る便利なポイントのURLです。たとえば、ポートレットがそのパーソナライズ・ページ(編集モード)をレンダリングする場合、このリンクは、ポートレットがあり、ユーザーがパーソナライズ・ページへ移動した元のページを参照します。このため、このリンクは、保留中のアクションを受け入れる、または取り消すボタンにエンコードします。このURLは、ポートレットのデスクトップ・レンダリングでのみ役に立ちます（通常は編集またはデフォルト編集モード）。
ポートレットのURLタイプを使用してリンクを構築するには、ポートレットのレンダリング・コードの作成時にこれらにアクセスして使用する必要があります。リンクのURLをフェッチするには、PDK-Javaで次のAPIをコールします。
portletRenderRequest.getRenderContext().getPageURL() portletRenderRequest.getRenderContext().getEventURL() portletRenderRequest.getRenderContext().getDesignURL() portletRenderRequest.getRenderContext().getLoginServerURL() portletRenderRequest.getRenderContext().getBackURL()
ポートレットのナビゲーションでは、ページURLにポートレットのパラメータを追加(または更新)する必要があります。このタスクを実行するには、次のAPIを使用して適切なURLを構築します。
UrlUtils.constructLink( PortletRenderRequest pr, int linkType, -- UrlUtils.PAGE_LINK in this case NameValue[] params, boolean encodeParams, boolean replaceParams)
UrlUtilsは、oracle.portal.provider.v2.urlと呼ばれるパッケージに含まれています。実際には自分自身でページURLをフェッチすることはありません。かわりに、提供されているポートレットURLタイプUrlUtils.PAGE_LINKを使用します。
params引数のパラメータ名は完全に修飾されている必要があります。また、パラメータが正しく修飾されていると、適切なlinkTypeを持つUrlUtils.constructLinkがポートレットに属さない他のURLパラメータを妨害することはありません。
UrlUtils.contructLinkの代替バージョンは、URLを受け入れて、それを、戻されるURLのベースとします。HTMLリンクが必要な場合、UrlUtils.constructHTMLLinkを使用して完全なアンカー要素を作成できます。
次のポートレット例であるThesaurusLink.jspでは、パラメータqを使用して、シソーラスで検索する単語を識別します。次に、見つかった関連単語についてのリンクが作成されます。ユーザーはこのリンクをたどり、この新しい単語に影響するシソーラスを取得します。qの値を設定する初期の実行フォームの詳細は、第61.3.4.4項「ポートレットのURLタイプを使用したフォームの構築」の例を参照してください。
<%
String paramNameQ = "q";
String qualParamNameQ =
HttpPortletRendererUtil.portletParameter(paramNameQ);
PortletRenderRequest pRequest = (PortletRenderRequest)
request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String paramValueQ = pRequest.getQualifiedParameter(paramNameQ);
%>
<!-- Output the HTML content -->
<center>
Words similar to <%= paramValueQ %>
<br>
Click the link to search for words related to that word.
<br>
<ul>
<%
String[] relatedWords = Thesaurus.getRelatedWords(paramValueQ);
NameValue[] linkParams = new NameValue[1];
for (int i=0; i<=relatedWords.length; i++)
{
linkParams[0] = new NameValue(
qualParamNameQ, relatedWords[i]);
%>
<li>
<b> <%= relatedWords[i] %> </b>
<%= UrlUtils.constructHTMLLink(
pRequest,
UrlUtils.PAGE_LINK,
"(words related to " + relatedWords[i] + ")",
"",
linkParams,
true,
true)%>
</li>
<%
}
%>
</ul>
</center>
フォームでのポートレット・パラメータの使用は、リンクでのパラメータの使用に似ています。次の2つの基本的ルールが同様に適用されます。
ポートレットのパラメータ名を修飾します。
受信URLのその他のパラメータは操作や削除はしません。
マークアップおよび動作の点では、フォームとリンクはかなり異なります。ただし、リンクの場合と同様、PDK-Javaにはこれら2つの基本ルールに準拠するためのユーティリティが含まれています。
ページ上のリンクにしてもフォーム要素の名前にしても、パラメータ名は単なる文字列です。したがって、ポートレットのパラメータ名を正しく修飾するためのコードは、第61.3.4.3項「ポートレットのURLタイプを使用したリンクの構築」で説明しているコードと同じです。
フォームは、URLのその他のパラメータは変更しないままにする必要があるという点でリンクとは異なります。マークアップでフォームを開いた後、次のAPIを使用できます。
UrlUtils.htmlFormHiddenFields(pRequest,UrlUtils.PAGE_LINK, formName); UrlUtils.htmlFormHiddenFields(someURL);
この場合、formName = UrlUtils.htmlFormName(pRequest,null)です。
|
注意: ページに複数のフォームがある可能性があるため、フォーム名は完全に修飾する必要があります。これは、ページ上のその他のポートレットと競合するのを避けるために、URLのパラメータとフォームの要素名に修飾が必要であるのと同様です。 |
htmlFormHiddenFieldsユーティリティは、HTMLの非表示フォーム要素をフォームに書き込みます。この場合、指定したURLの、ポートレットに属さないパラメータごとに1つのフォーム要素を書き込みます。
<INPUT TYPE="hidden" name="paramName" value="paramValue">
このため、ポートレットのパラメータをフォームに追加するのみでよいのです。
もう1つ注意が必要なのは、フォームの送信ターゲットを導出する方法です。多くの場合、送信ターゲットは現行のページです。
formTarget = UrlUtils.htmlFormActionLink(pRequest,UrlUtils.PAGE_LINK)
formTargetの値には、HTMLフォームのアクション属性やSimpleFormのターゲット属性を使用できます。メソッド名にHTMLが含まれている場合でも、実際にはURLを戻すのみであるため、これはモバイル・ポートレットでも使用できます。
次の例のフォームは、シソーラス・ポートレットの送信フォームをレンダリングします。このフォームの送信により生成されるポートレットの詳細は、第61.3.4.3項「ポートレットURLタイプを使用したリンクの構築」の例を参照してください。
<%
String paramNameSubmit = "submit";
String paramNameQ = "q";
String qualParamNameQ =
HttpPortletRendererUtil.portletParameter(paramNameQ);
String qualParamNameSubmit =
HttpPortletRendererUtil.portletParameter(paramNameSubmit);
PortletRenderRequest pRequest = (PortletRenderRequest)
request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String formName = UrlUtils.htmlFormName(pRequest,"query_form");
%>
<!-- Output the HTML content -->
<center>
<b>Thesaurus</b>
Enter the word you want to search for
<form name="<%= formName %>" method="POST"
action="<%= UrlUtils.htmlFormActionLink(pRequest,UrlUtils.PAGE_LINK) %>">
<%= UrlUtils.htmlFormHiddenFields(pRequest,UrlUtils.PAGE_LINK, formName)%>
<table><tr><td>
Word of interest:
</td><td>
<input
type="text"
size="20"
name="<%= qualParamNameQ %>"
value="">
</td></tr></table>
<input type=submit name="<%= qualParamNameSubmit %>" Value="Search">
</form>
</center>
ポートレット内でナビゲーションを実装する方法には、次の3つがあります。
プライベート・ポートレット・パラメータを使用して、レンダリングされるURLにナビゲーション情報を渡します。このURLに基づいて、ポートレット・コード内のブランチ・ロジックは、どのポートレットのセクションをレンダリングするのかを確認できます。このオプションは、第61.3.4.3項「ポートレットのURLタイプを使用したリンクの構築」および第61.3.4.4項「ポートレットのURLタイプを使用したフォームの構築」に示されているシソーラス例を少し拡張したものです。基本的に、このポートレットは、パラメータ値qを使用してシソーラスの検索動作を実行するのでなく、パラメータ値に基づいて分岐し、これに応じて様々なコンテンツをレンダリングします。
前の項目と同じようにナビゲーション情報を渡します。ただし、PDK-Javaを使用してパラメータを解釈し、その値に基づいて分岐してください。この方法の場合、シソーラスの例をいくらか変更する必要があるため、後でその詳細を説明します。
セッション記憶域を使用してポートレットの状態を記録し、プライベート・パラメータを使用して明示的なナビゲーションではなくアクションを示します。この方法は、ポートレットが含まれるページからユーザーが移動したときにポートレットを前の状態にリストアする唯一の方法です。ユーザーがこのページから移動すると、すべてのプライベート・ポートレット・パラメータは失われ、セッション記憶域にある状態のみをリストアできます。ただし、その状態がセッション記憶域に保管されていることが前提です。このオプションを使用するには、セッション記憶域について理解し、これを実装する必要があります。セッション記憶域の実装の詳細は、第61.3.6項「セッション情報へのアクセス方法」を参照してください。
次のポートレット・コードは、PDK-Javaのサンプル・プロデューサのマルチページ例の一部です。
<portlet>
<id>11</id>
<name>Multipage</name>
<title>MultiPage Sample</title>
<shortTitle>MultiPage</shortTitle>
<description>
This portlet depicts switching between two screens all
in an application page.
</description>
<timeout>40</timeout>
<timeoutMessage>MultiPage Sample timed out</timeoutMessage>
<renderer class="oracle.portal.provider.v2.render.RenderManager">
<contentType>text/html</contentType>
<showPage>/htdocs/multipage/first.jsp</showPage>
<pageParameterName>next_page</pageParameterName>
</renderer>
</portlet>
|
注意:
|
シソーラスの例をこのパラメータで動作するように変更できます。特に、フォーム送信ポートレットをシソーラスの入力用（ポートレットの先頭ページ）として使用し、シソーラス内をさらにドリルダウンしていくためのリンクが含まれる結果ページにユーザーをナビゲートできます。次の例は、これらの変更内容を示します。
|
注意: 次の例は、このシソーラスの例のように、比較的簡単なケースの場合に最も役に立ちます。ウィザードの使用経験を積む必要があるなど、より込み入った必要性がある場合は、StrutsなどのMVCフレームワークを使用することを検討してください。Strutsアプリケーションからポートレットを構築する方法の詳細は、第61.5項「Strutsポートレットの作成」を参照してください。 |
ThesaurusForm.jsp:
<%
PortletRenderRequest pRequest = (PortletRenderRequest)
request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String paramNameSubmit = "submit";
String paramNameQ = "q";
String qualParamNameQ =
HttpPortletRendererUtil.portletParameter(pRequest, paramNameQ);
String qualParamNameSubmit =
HttpPortletRendererUtil.portletParameter(pRequest, paramNameSubmit);
String formName = UrlUtils.htmlFormName(pRequest,"query_form");
%>
<!-- Output the HTML content -->
<center>
<b>Thesaurus</b>
Enter the word you want to search for
<form name="<%= formName %>" method="POST"
action="<%= UrlUtils.htmlFormActionLink(pRequest,UrlUtils.PAGE_LINK) %>">
<%= UrlUtils.htmlFormHiddenFields(pRequest,UrlUtils.PAGE_LINK, formName)
%>
<%= UrlUtils.emitHiddenField(
HttpPortletRendererUtil.portletParameter(request, "next_page"),
"htdocs/path/ThesaurusLink.jsp" ) %>
<table><tr><td>
Word of interest:
</td><td>
<input
type="text"
size="20"
name="<%= qualParamNameQ %>"
value="">
</td></tr></table>
<input type=submit name="<%= qualParamNameSubmit %>" Value="Search">
</form>
</center>
ThesaurusLink.jspを指し示すためにnext_pageを明示的に設定する必要がありますので、その方法に留意してください。この方法でnext_pageを明示的に設定しない場合、このパラメータは、provider.xmlに登録されているリソース（ThesaurusForm.jsp）にデフォルト設定されます。
ThesaurusLink.jsp:
<%
PortletRenderRequest pRequest = (PortletRenderRequest)
request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String paramNameQ = "q";
String paramNameNextPage = "next_page";
String qualParamNameQ =
HttpPortletRendererUtil.portletParameter(pRequest, paramNameQ);
String qualParamNameNextPage =
HttpPortletRendererUtil.portletParameter(pRequest, paramNameNextPage);
String paramValueQ = pRequest.getQualifiedParameter(paramNameQ);
%>
<!-- Output the HTML content -->
<center>
Words similar to <%= paramValueQ %>
<br>
Click the link to search for words related to that word.
<br>
<ul>
<%
Thesaurus t = new Thesaurus();
String[] relatedWords = t.getRelatedWords(paramValueQ);
NameValue[] linkParams = new NameValue[2];
linkParams[0] = new NameValue(
qualParamNameNextPage, "htdocs/path/ThesaurusLink.jsp");
for (int i=0; i<relatedWords.length; i++)
{
linkParams[1] = new NameValue(
qualParamNameQ, relatedWords[i]);
%>
<li>
<b> <%= relatedWords[i] %> </b>
<%= UrlUtils.constructHTMLLink(
pRequest,
UrlUtils.PAGE_LINK,
"(words related to " + relatedWords[i] + ")",
"",
linkParams,
true,
true)%>
</li>
<%
}
%>
</ul>
<a href="<%=XMLUtil.escapeXMLAttribute
(pRequest.getRenderContext().getPageURL())%>">
Reset Portlet
</a>
</center>
プライベート・パラメータによるナビゲーションの実装における制限事項の1つは、制限する必要のあるポートレット・リソースにユーザーが移動できることです。制限されたリソースへのナビゲーションを制御するために、ユーザーが移動できるリソースのホワイトリストを作成できます。ナビゲーションを制限するためのホワイトリストを作成しないと、ポートレットのリソースは、次のデフォルト・ルールに従ってアクセス可能になります。
サーブレット・ルート直下のパスはナビゲート可能です。たとえば、/index.jspはアクセス可能ですが、/WEB-INF/web.xmlにはアクセスできません。
htdocsディレクトリの下のパスはナビゲート可能です。たとえば、/htdocs/multipage/first.jspと/htdocs/lottery/lotto.jspはどちらもアクセス可能です。
このデフォルトの動作を変更するには、許容できるパス値をプロバイダ定義ファイルprovider.xmlに追加します。たとえば、pageParameterNameプライベート・パラメータに応じて、リクエストを他のページに転送するコントローラとして、JSPが使用されるポートレットがあるとします。例61-9のXMLの抜粋では、/htdocs/multiportletの下のリソースのみが表示されます。その他のリソースはすべて制限されます。
例61-9 provider.xmlファイルからのホワイトリストの抜粋
<portlet class="oracle.portal.provider.v2.DefaultPortletDefinition">
<id>1</id>
<name>Multipage</name>
<title>A MultiPage Portlet</title>
...
<renderer class="oracle.portal.provider.v2.render.RenderManager">
<contentType>text/html</contentType>
<showPage>/htdocs/multiportlet/controller.jsp</showPage>
<pageParameterName>show_page</pageParameterName>
<allowedPath>/htdocs/multiportlet/*</allowedPath>
</renderer>
</portlet>
この機能のパターン一致ルールは、web.xmlファイルのURLパターン一致と類似しています。ルールは次のとおりです。
定義されたパターンに一致する場合、リソース・パスは、ワイルドカードが使用されないかぎり、正解に一致する必要があります。
最初のワイルドカードはパス一致のためのもので、/で始まり/*で終わる文字列で構成されています。パスがこの文字列で始まるリソースは一致します。/htdocs/sub1/*の<allowedPath>値の場合、プライベート・パラメータの有効値には、/htdocs/sub1/file.jspと/htdocs/sub1/sub2/file2.jspが含まれます。
2番目のワイルドカードはタイプ一致のためのもので、*.で始まりファイル拡張子で終わる文字列で構成されています。ページ・パラメータの有効値は、そのファイル拡張子で終わります。*.jspの<allowedPathvalue>の場合、プライベート・パラメータの有効値には、/htdocs/sub1/file.jspと/htdocs/sub1/file2.jspが含まれます。
Javaポートレットを作成する場合、JNDIサービスを介して、デプロイ固有のプロパティを設定できます。これにより、これらの値がプロデューサ・コードから取得されるようにできます。この方法により、プロデューサ・デプロイに任意のプロパティを指定し、プロデューサ・コード内の任意の場所からこのプロパティに簡単にアクセスできます。
JNDI変数を使用して、プロデューサのデプロイ後にプロデューサのプロパティ値を変更できます。環境エントリはweb.xmlで宣言する必要があります。その後、デプロイメント・プランを使用してデプロイメントで更新できます。
PDK-Javaには、Java EEコンテナ内のプロデューサJNDI変数と非プロデューサJNDI変数の両方を取得するためのユーティリティが用意されています。
この項の内容は、次のとおりです。
JNDI変数は、プロデューサのweb.xmlファイルで宣言します。JNDI変数を宣言するための書式は、次のとおりです。
<env-entry>
<env-entry-name>variableName</env-entry-name>
<env-entry-type>variableType</env-entry-type>
<env-entry-value>variableValue</env-entry-value>
</env-entry>
env-entry-name要素にはこの変数を識別する名前が含まれます。env-entry-typeにはこの変数の完全修飾されたJava型が含まれます。env-entry-valueにはこの変数のデフォルト値が含まれます。
この項の内容は、次のとおりです。
env-entry-type要素では、Javaコードによって予期される、完全に修飾されたJava型変数を指定する必要があります。JNDI変数で使用可能なJava型は、次のとおりです。
java.lang.Boolean
java.lang.String
java.lang.Integer
java.lang.Double
java.lang.Float
Java EEコンテナは、これらの型宣言を使用して、指定された型のオブジェクトを自動的に構成し、コード内で変数を取得するときに、指定された値をオブジェクトに設定します。
PDK-Javaは、個々のプロデューサ・サービス・レベルまたはWebアプリケーション・レベルで設定可能な環境変数を定義します。同じWebアプリケーションにパッケージ化されている様々なプロデューサ・サービスやアプリケーション・コンポーネントの間で命名が競合しないようにするには、特定の命名規則を策定することをお薦めします。
|
注意:
|
次に例を示します。
プロデューサ・サービス固有名の書式は、次のようにする必要があります。
company/component name/producer name/variable name
共有名の書式は、次のようにする必要があります。
company/component name/producer name/global
これらの意味は、次のとおりです。
company: アプリケーションを所有する会社名です。
component name: プロバイダが関連付けられているアプリケーションまたはコンポーネントの名前です。
producer name: プロデューサのサービス名です。
variable name: 変数自体の名前です。
これらの命名規則は、Javaパッケージに使用されている命名規則と似ています。この方法により、アプリケーションまたはアプリケーション・コンポーネントの間で名前が衝突する可能性を最小限に抑えることができます。PDK-Javaには、プロデューサのサービス名をサーブレットまたはJSPにハードコーディングせずにこの書式の変数を取得するためのユーティリティが用意されています。このサービス名は、プロデューサのWARファイルに定義しておくのみでよいのです。JNDI変数の取得の詳細は、第61.3.5.3項「JNDI変数の取得」を参照してください。
次の例は、プロデューサの変数名を示します。
oracle/portal/myProvider/myDeploymentProperty oracle/portal/myprovider/myProperties/myProperty
次の例は、プロデューサ以外の変数名を示します。
oracle/portal/myOtherProperty
プロデューサ・デプロイでは、JNDI変数の一部またはすべてに対して新しい値を設定できます。このタスクは、WLSデプロイメント・プラン内で値を手動で設定することにより行えます。デプロイメント・プランは、WLSコンソールを通してプロデューサ・デプロイに対して作成できます。
デプロイメント・プラン内で変数値を手動で設定する手順は次のとおりです。
WLSコンソール内でプロデューサ・デプロイに移動し、デプロイメント・プランが存在しない場合は新しいデプロイメント・プランを作成します。
デプロイメント・プランのXMLファイルを編集します。設定するデプロイメント・プロパティごとに、<deployment-plan>タグの下に直接、次の変数定義を追加します。
<variable-definition>
<variable>
<name>jndi_var_def</name>
<value>false</value>
</variable>
</variable-definition>
この変数定義を実際のJNDI変数に関連付けるには、各プロパティに対し、WEB-INF/web.xmlモジュール・ディスクリプタの下に次の割当てを追加します(例としてoracle/portal/sample/rootDirectoryを使用します)。
<module-descriptor external="false"> <root-element>web-app</root-element> <uri>WEB-INF/web.xml</uri> <variable-assignment> <name>jndi_var_def</name> <xpath>/web-app/env-entry/[env-entry-name="oracle/portal/sample/rootDirectory"]/env-entry-value</xpath> </variable-assignment> </module-descriptor>
ファイルを保存して閉じます。
デプロイメント・プランを適用して新しい設定を有効にするには、プロデューサ・デプロイに対して「更新」を選択します。
JNDIは、標準的なJava EEテクノロジです。このため、JNDI変数にはJava EE APIを介してアクセスできます。次に例を示します。
String myVarName = "oracle/portal/myProvider/myVar"
String myVar = null;
try
{
InitialContext ic = new InitialContext();
myVar = (String)ic.lookup("java:env/" + myVarName);
}
catch(NamingException ne)
{
exception handling logic
}
基本的なJava EE API以外にも、PDK-Javaには、PDK自体によって定義および使用される変数値を取得するための簡素なユーティリティ・クラスが用意されています。これらの変数はすべて、第61.3.5.1.2項「変数の命名規則」で説明されている命名規則に準拠しており、その書式は次のとおりです。
oracle/portal/provider_service_name/variable_name oracle/portal/variable_name
これらのAPIを使用するには、provider_service_nameおよびvariable_nameを指定するのみでよいのです。このユーティリティは、指定された情報に基づいて完全なJNDI変数名を構成し、前に示したものと類似のコードを使用して変数を参照し、変数値を戻します。
EnvLookupクラス（oracle.portal.utils.EnvLookup）には、2つのlookup()メソッドがあります。1つはプロデューサ変数を取得し、もう1つは非プロデューサ変数を取得します。どちらのメソッドもjava.lang.Objectを戻します。これは、目的のJava型にキャストできます。
次のコード例では、プロデューサ変数を取得しています。
EnvLookup el = new EnvLookup(); String s = (String)el.lookup(myProviderName, myVariableName);
変数名のうち、myProviderNameは、プロデューサのサービス名を示す部分です。変数名のうち、このプロデューサのサービス名の後ろに続く部分がmyVariableNameです。この例では、取得される変数の型がjava.lang.Stringであると想定しています。
非プロデューサ変数を取得するには、同じコードを使用し、1つのパラメータ、myVariableNameのみをlookup()に渡します。また、この場合、接頭辞oracle/portalは除きます。
EnvLookup el = new EnvLookup();Object o = el.lookup(myVariableName);
表61-2は、デフォルトでPDK-Javaに用意されているJNDI変数を示しています。これらの変数を宣言しない場合、PDK-Javaは、元の場所(web.xmlおよびデプロイメント・プロパティ・ファイル)でこれらの値を検索します。
表61-2 PDK-JavaのJNDI変数
| 変数 | 説明 |
|---|---|
oracle/portal/provider/provider_name/autoReload
|
ブール型の自動リロード・フラグ。デフォルト値はtrue。 |
oracle/portal/provider/provider_name/definition
|
プロデューサの定義ファイルの場所。 |
oracle/portal/provider/global/log/logLevel |
ログ設定（0〜8）。0はロギングなし、8は最大限のロギング。 |
oracle/portal/provider/provider_name/maxTimeDifference
|
プロデューサのHMAC時間差。 |
oracle/portal/provider/<service_name>/resourceUrlKey |
Parallel Page Engineによるリソースのプロキシ化の認証キー。詳細は、Oracle Fusion Middleware Oracle Portal管理者ガイドを参照してください。 |
oracle/portal/provider/provider_name/rootDirectory
|
プロデューサのパーソナライズの場所。デフォルト値はなし。 |
oracle/portal/provider/provider_name/sharedKey
|
HMAC共有キー。デフォルト値はなし。 |
oracle/portal/provider/provider_name/showTestPage
|
（非プロデューサ）プロデューサのテスト・ページにアクセス可能どうかを決定するブール型フラグ。デフォルト値はtrue。 |
oracle/portal/provider/global/transportEnabled |
「デフォルトの編集」のパーソナライズをエクスポートおよびインポート可能かを決定するブール型フラグ。 |
ユーザーがページにアクセスすると、ページではパブリックの認証されていないセッションを開始し、リクエスト全体のセッションに関する情報を追跡します。ユーザーがログインすると、このセッションはログイン・ユーザーの認証済セッションとなります。このセッションは、次の場合に終了します。
ブラウザ・セッションが終了したとき（つまり、ユーザーがすべてのブラウザ・ウィンドウを閉じたとき）
ユーザーが明示的にログアウトしたとき
ユーザーのアイドル時間が設定時間を超えたためにセッションがタイムアウトしたとき
ポートレットをページに提供するプロデューサが、なんらかの特別な処理のためにコールされるように登録時に指定している場合、メタデータ生成の一環として、プロデューサすべてに連絡します。このコールにより、プロデューサは、ユーザー・セッションに基づいて処理を行い、必要に応じてプロデューサのアプリケーションのユーザーをログに記録し、プロデューサ・セッションを確立できるようになります。プロデューサの場合、このコールはinitSessionと呼ばれます。Web対応型アプリケーションの大部分はCookieを使用してセッションを追跡するため、アプリケーションのプロデューサはCookieを戻すのにこのAPIコールを利用できます。
セッション・ストアを使用すると、ポータル・セッションの間存続する情報を保存および取得できます。この情報が有効で使用可能なのは、そのセッションの存続期間中のみです。セッション・ストアに格納するのは、一時情報のみです。アプリケーション開発者はこのセッション・ストアを使用して、現行のユーザー・セッションに関する情報を格納できます。セッション・ストアのデータは複数のポートレット間で共有できます。
格納する情報を複数のセッションにわたって存続させる必要がある場合は、セッション・ストアのかわりにプリファレンス・ストアに格納できます。一般的なセッション・ストアの適用例を次に示します。
ロードや演算にコストがかかるデータ（たとえば、検索結果）をキャッシュする場合。
ポートレットの現在の状態（たとえば、ポートレットに表示された検索結果の現在の範囲（ページ）やユーザーが実行したイベントの順序）をキャッシュする場合。
セッション記憶域を実装する前には、パフォーマンス・コストを慎重に検討する必要があります。ポートレットとプロデューサはリモートであるため、セッション・ストアに情報を作成して保持する操作は、少ない情報量であっても比較的コストがかかる可能性があります。このため、多数のユーザーが頻繁にアクセスするパブリック・ページについては、セッション記憶域の実装を避けた方がよい場合があります。
また、プロデューサでセッション・ストアを使用する場合は、メモリー内の状態情報を追跡するステートフルなアプリケーションを作成します。同様に、プリファレンス・ストアのファイル・システム実装を使用する場合も、ステートフルなアプリケーションを作成します。
スケーラビリティに重要な関心がある場合、ステートフルなアプリケーションは問題発生の原因となる可能性があります。ステートフルなアプリケーションは、使用している構成のロード・バランシングとフェイルオーバー・メカニズムに影響を与えることがあります。これは、複数の中間層をデプロイしても、状態を追跡するためには面倒なルーティング（同じノードが後続のリクエストを同じセッションで処理する）を実装する必要があるためです。このルーティングによって、ノードがクラッシュした場合に不均衡なロード・バランスやセッション・データの消失が発生し、フェイルオーバーに影響を与えることがあります。多くの開発者がステートレスなアプリケーションの構築を選ぶ理由の1つはここにあります。ただし、スケーラビリティが問題でない場合、ステートフルなアプリケーションによる問題は発生しません。
PDKフレームワークでは、セッションをProviderSessionオブジェクトを使用して表します。このオブジェクトはプロバイダ・インスタンスのinitSessionメソッドへのコールの際に確立されます。このオブジェクトは、ProviderUserと関連付けられています。リクエスト間でデータを永続的に保持するには、ProviderSessionオブジェクト上のsetAttributeメソッドを使用してセッション・オブジェクトにデータを書き込む必要があります。このメソッドはjava.lang.Objectをjava.lang.Stringにマップし、そのマッピングをセッション・オブジェクト内に格納します。Stringは、その後、セッションがまだ有効である場合、後続のリクエスト中にObjectを取得するために使用できます。
次のような場合は、プロデューサ・セッションが無効になることがあります。
セッションがタイムアウトした場合
ProviderSession上のinvalidateメソッドがコールされた場合
サーブレット・コンテナを実行中のJVMプロセスが終了した場合
同じProviderInstanceに含まれるすべてのポートレットは、特定のProviderUserに対して同じセッションを共有します。したがって、特定のポートレット・インスタンスに対して一意のデータは、セッション内の一意のStringにマップする必要があります。これは、PortletRendererUtilクラス内のportletParameterメソッドを使用して行います。このメソッドは、そのインスタンス用に生成された識別子を先頭に付けることで、提供されたStringパラメータまたは属性名をPortletInstanceに対して一意にします。戻されたインスタンス固有の名前を使用すると、セッションにポートレット・インスタンス・データを書き込むことができます。
PDK Frameworkクラスの詳細は、Oracle Fusion Middleware Oracle PDK Java Java APIリファレンスのJavaDocを参照してください。
この項の例では、共有画面モードでポートレットをレンダリングした回数をカウントするために、セッション記憶域を使用します。
開始する前に
ここで説明する手順は、次のことを前提としています。
第60.2.4項「PDK-Javaポートレットの作成方法」を読み終えて理解していること。
ウィザードで作成したポートレットがページに正常に追加されていること。
セッション記憶域を実装する手順は次のとおりです。
ProviderSession、PortletRendererUtilおよびHttpPortletRendererUtilをインポートします。
プロデューサ・セッションを取得します。
Javaポートレット内からセッションにアクセスして、セッションの読取りと書込みを行います。
provider.xmlでsessionをtrueに設定します。
セッション記憶域のプロデューサを登録し、「ログイン頻度」を設定します。
次に、現行セッションでポートレットがレンダリングされた回数を表示するセッション・カウントをポートレットに追加する手順を説明します。
ウィザードを使用してポートレットを作成した後は、Oracle JDeveloperの「表示」ページのJSPを編集できます。次のクラスをインポートする必要があります。
<%@page contentType="text/html; charset=windows-1252" import="oracle.portal.provider.v2.render.PortletRenderRequest" import="oracle.portal.provider.v2.http.HttpCommonConstants" import="oracle.portal.provider.v2.ProviderSession" import="oracle.portal.provider.v2.render.PortletRendererUtil" import="oracle.portal.provider.v2.render.http.HttpPortletRendererUtil" %>
最初に有効なセッションをチェックし、次にカウントを増分して表示するコードを挿入します。セッションが有効で、以前に格納した値が存在する場合は、その値を表示し、カウントを増分して新しい値を格納します。セッションは有効だが以前に格納した値がない場合は、カウントを1に初期化し、その値を表示して格納します。また、このポートレットの一意の文字列キーを取得し、その文字列キーを配列で使用してセッションをカウントできます。セッション情報を受信していない場合は、ユーザーに対して、再度ログインが必要であることを示す情報を提供できます。
<% PortletRenderRequest pReq = (PortletRenderRequest) request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST); ProviderSession pSession = pReq.getSession(); if (pSession != null) { String key = PortletRendererUtil.portletParameter(pReq, "count"); Integer i = (Integer)pSession.getAttribute(key); if (i == null) { i = new Integer(0); } i = new Integer(i.intValue()+1); pSession.setAttribute(key, i); %> <p>Render count in this session: <%=i%> </p> <% } else { %> <p>The session has become invalid</p> <br> Please log out and log in again. <% } %>
デフォルトでは、ウィザードでprovider.xmlのsessionをtrueに設定することはありません。プロデューサがポータルからセッション情報を受信するためには、このフラグを更新する必要があります。このタグをtrueに設定する必要があるのは、プロデューサまたはポートレットでセッション情報を使用する場合のみです。このフラグをtrueに設定すると、プロデューサ・コールに余分なロードが追加されます。
<provider class="oracle.portal.provider.v2.DefaultProviderDefinition">
<session>true</session>
プロデューサをセッション・サポートに登録します。ポートレットの登録方法に関する注意は、第62.4項「ポートレットの登録と表示」を参照してください。
Javaポートレットをページに追加していない場合は、ここで追加します。次のタスクを実行します。
ポートレットの基本機能の設定が完了した後は、ポートレットのパフォーマンスに注目する必要があります。
キャッシュは、高度な動的コンテンツを含むWebサイトのパフォーマンスの向上に使用される一般的な手法です。この手法では、キャッシュと呼ばれる待機時間の短い大きなデータ・ストアを備えたローカル・エージェントを使用してリクエストをプロキシ化することで、動的コンテンツのデータの取得と出力の生成に伴うオーバーヘッドを大幅に削減できます。キャッシュ・エージェントは、リクエストに対して次のいずれかの方法で応答します。
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在する場合、エージェントはキャッシュされた既存のコピーをそのまま戻します。これによって、コンテンツの取得と生成というコストがかかるプロセスを省くことができます。この状況はキャッシュ・ヒットと呼ばれます。
リクエストされたコンテンツの有効なバージョンがキャッシュ内に存在しない場合、エージェントはリクエストをその宛先に転送し、コンテンツが戻されるのを待機します。エージェントはコンテンツをリクエスト元に戻し、そのキャッシュ内にローカル・コピーを格納して、同じコンテンツに対するリクエストが後で発生した場合に再利用します。この状況はキャッシュ・ミスと呼ばれます。
プロデューサは、動的コンテンツ(つまり、ポートレット)の生成元であり、多くの場合、デプロイされているFrameworkアプリケーション・インスタンスから離れた場所にあります。このため、キャッシュによるパフォーマンス向上が可能となります。アーキテクチャは、キャッシュに適切です。プロデューサでレンダリングされたポートレットをキャッシュし、キャッシュされたコピーを再利用して後続のリクエストを処理することによって、プロデューサがページ作成にもたらすオーバーヘッドを最小限にできます。
プロデューサでは、どれがアプリケーションに最も適しているかによって、次の3種類のキャッシュ方法のいずれかを使用できます。これらのキャッシュ方法の主な違いは、コンテンツが有効かどうかを判断する方法にあります。3種類のキャッシュ方法を次に示します。
有効期限ベースのキャッシュ: プロデューサはレンダリング・リクエストを受信すると、そのレスポンスに有効期限のスタンプを付けます。レンダリングされたレスポンスはキャッシュに格納され、同じコンテンツに対する後続のすべてのリクエストは、有効期限が経過するまで、このキャッシュを使用して処理されます。このキャッシュ・スキームは最も簡単でパフォーマンスが優れていると考えられます。それは、キャッシュの有効性をテストするためのオーバーヘッドがほとんどなく、ネットワークのラウンドトリップを伴わないためです。有効期限ベースのキャッシュは、コンテンツの使用期間が効率よく定義されているアプリケーションに適しています。コンテンツの使用期間が確実ではない場合、有効期限ベースのキャッシュは効果的ではありません。詳細は、第61.3.7.1項「キャッシュのアクティブ化」および第61.3.7.2項「有効期限ベースのキャッシュの追加」を参照してください。
有効化ベースのキャッシュ: レンダリング・リクエストを受信したプロデューサは、そのレスポンスにバージョン識別子(またはETag)のスタンプを付けます。この方法でもレスポンスはキャッシュされますが、コンシューマはキャッシュされたレスポンスを再利用する前に、キャッシュされたバージョンがまだ有効かどうかを判断する必要があります。そのために、キャッシュされたコンテンツのバージョン識別子を含めたレンダリング・リクエストをプロデューサに送信します。プロデューサは、このバージョン識別子が有効であるかどうかを判断します。バージョン識別子が有効である場合、プロデューサはコンテンツを含まない軽量のレスポンスをコンシューマに即座に送信し、キャッシュされたバージョンを再利用できることを通知します。バージョン識別子が無効な場合、プロデューサは新しいバージョン識別子を含む新しいコンテンツを生成し、以前にキャッシュされたバージョンを置き換えます。このキャッシュ方法では、コンシューマは、常にプロデューサに対してコンテンツが最新かどうかを確認する必要があります。キャッシュされたコピーの有効性は、プロデューサのロジックによって判断されます。この方法では、固定期間に依存するのではなく、キャッシュされたコンテンツの使用をプロデューサが管理できるという利点があります。詳細は、第61.3.7.1項「キャッシュのアクティブ化」および第61.3.7.3項「有効化ベースのキャッシュの追加」を参照してください。
この項の内容は、次のとおりです。
開始する前に
ここで説明する手順は、次のことを前提としています。
第60.2.4項「PDK-Javaポートレットの作成方法」を読み終えて理解していること。
ウィザードで作成したポートレットがページに正常に追加されていること。
キャッシュ機能をプロデューサで使用するには、最初に、中間層キャッシュをアクティブにする必要があります。このキャッシュは、mod_plsql（データベース・プロシージャおよびデータベース・プロデューサをHTTPでコールするOracle HTTP Serverプラグイン）で使用されるキャッシュと同じであるため、PL/SQLキャッシュと呼ばれます。
通常、キャッシュに関する構成詳細の責任は管理者にあります。
有効期限ベースのキャッシュは実装が簡単なキャッシュ・スキームで、XMLプロデューサ定義内で宣言によってアクティブにできます。使用するManagedRendererの出力には、出力のキャッシュ時間（分）をそのpageExpiresプロパティに設定することによって、有効期限を設定できます。たとえば、ポートレット出力を1分間キャッシュすると仮定します。
有効期限ベースのキャッシュを追加する手順は次のとおりです。
第60.2.4項「PDK-Javaポートレットの作成方法」の説明に従ってOracle PDK-Javaポートレットの作成ウィザードを使用してポートレットを作成した後、provider.xmlファイルを編集し、showPageのpageExpiresプロパティ・タグを1に設定します。これによって、ポートレットの1分間の期限切れエントリが設定されます。
デフォルトでは、ウィザードによって、showPageの圧縮された標準的なタグが生成されます。サブタグpageExpiresを含めるようにこのタグを拡張します。
<showPage class="oracle.portal.provider.v2.render.http.ResourceRenderer">
<resourcePath>/htdocs/mycacheportlet/MyCachePortletShowPage.jsp
</resourcePath>
<pageExpires>1</pageExpires>
</showPage>
JSPコードを表示ページに追加して、ポートレットが1分間キャッシュされることをテストします。ここでは、現在の時刻をJSPに追加します。
<%@page contentType="text/html; charset=windows-1252" import="oracle.portal.provider.v2.render.PortletRenderRequest" import="oracle.portal.provider.v2.http.HttpCommonConstants" import="java.util.Date" import="java.text.DateFormat" %> <% PortletRenderRequest pReq = (PortletRenderRequest) request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST); DateFormat df = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.LONG,pReq.getLocale()); String time = df.format(new Date()); %> <P>Hello <%=pReq.getUser().getName() %>.</P> <P>This is the <b><i>Edit</i></b> render mode!</P> <P>This information is correct as of <%=time%>.</P>
ポートレットを表示して、時間(秒を含む)が1分間で一定していることを確認します。時間が経過すると、ポートレットは最新の時刻を表示し、新しいキャッシュが設定されます。
有効化ベースのキャッシュの追加は多少複雑ですが、プロデューサに対するどのリクエストがキャッシュ・ヒットであるかを厳密に制御できます。ここでは、ポートレット内のデータが変更された場合のみキャッシュを更新する例を説明します。このアルゴリズムを実装するには、prepareResponseメソッドを上書きする必要があります。BaseManagedRenderer.prepareResponseメソッドの署名は次のとおりです。
public boolean prepareResponse(PortletRenderRequest pr)
throws PortletException,
PortletNotFoundException
使用しているバージョンのprepareResponse()で、次の処理を実行する必要があります。
キャッシュされたバージョン識別子を取得します。この識別子は、HttpPortletRendererUtil.getCachedVersion()メソッドをコールすることで、コンシューマによってレンダリング・リクエストに設定されます。
public static java.lang.String getCachedVersion
(PortletRenderRequest request)
以前にキャッシュされたバージョンが有効であることをポートレットが検出した場合は、HttpPortletRendererUtil.useCachedVersion()メソッドをコールして適切なヘッダーを設定する必要があります。また、RenderManagerに対しては、ポートレット本体をレンダリングするためにrenderBody()をコールする必要がないことが指示されます。
public static void useCachedVersion(PortletRenderRequest request)
これ以外の場合は、HttpPortletRendererUtil.setCachedVersion()を使用して、新しいバージョンのポートレットを生成します。このポートレットがキャッシュされます。また、コンシューマに対しては、renderBody()メソッドをコールして、ポートレットのコンテンツを再生成する必要があることが指示されます。
public static void setCachedVersion(PortletRenderRequest request,
java.lang.String version,
int level)
throws java.lang.IllegalArgumentException
有効化ベースのキャッシュの場合、provider.xmlを更新する必要はありません。ポートレットを表示するには、ページをリフレッシュするか、ポートレットをページに追加してコンテンツを更新します。コンテンツが変更されている場合、ポートレットは新しいコンテンツを表示します。コンテンツが変更されていない場合は、キャッシュされたバージョンのポートレットが表示されます。
ポートレットのパーソナライズを実装した場合、「パーソナライズ」リンクは、認証されたユーザーのポートレットにのみ表示されます。したがって、ポートレットのパーソナライズ（「パーソナライズ」リンク」）をテストするには、ポートレットを使用するアプリケーションに対して、なんらかの形のセキュリティを実装しておく必要があります。テストのためには、最も基本的な認証を構成すればすみます。詳細は、第69.12項「ポートレット・パーソナライズをテストするための基本認証の構成」を参照してください。
Oracle PDKには、Apache Strutsアプリケーションを統合するための新しい拡張機能が含まれています。この項では、既存のStrutsアプリケーションからポートレットを作成する方法を説明します。また、その作成手順に従うと、Model-View-Controllerパラダイムを使用するポートレットも作成できます。この項で説明するPDK-Javaの拡張機能は、Apache Struts 1.1に準拠しています。
Strutsフレームワークを使用してポートレットの動作を拡張することができます。たとえば、ポートレット内のページ・フローにStrutsコントローラを使用できます。ポートレット・レンダリング・リクエストとStrutsサーブレット・リクエスト間のブリッジとしてポートレット・レンダラが使用されます。
次に示すコードは、プロデューサ定義ファイル（provider.xml）の一部です。
...
<renderContainer>true</renderContainer>
<renderCustomize>true</renderCustomize>
<autoRedirect>true</autoRedirect>
<contentType>text/html</contentType>
<showPage class="oracle.portal.provider.v2.render.http.StrutsRenderer">
<defaultAction>showCustomer.do</defaultAction>
</showPage>
</renderer>
...
StrutsポートレットのshowPageには次の2つの重要なコンポーネントが含まれます。
レンダラ・クラス(oracle.portal.provider.v2.render.http.StrutsRenderer): レンダラ・リクエストを受信し、それをStrutsアクション・サーブレットに転送します。
defaultActionタグ: ポートレットが初めてコールされたときにデフォルトで使用するStrutsアクションを定義します。
PDK-Javaを使用すると、Strutsアプリケーションのビュー(ポートレット・ビュー)を容易に開発できます。このビューによって、ポータル・スタイルを使用するStrutsポートレットでは整合性のとれたルック・アンド・フィールが維持され、エンド・ユーザーはポータル内でアプリケーションを使用できます。
Strutsポートレットを作成するには、デフォルトのStruts JSPタグの拡張であるPDK-Java Strutsタグを使用する必要があります。この開発プロセスは、スタンドアロンのStrutsアプリケーションを作成するプロセスに似ています。プロデューサ・アプリケーション内のポートレットがStrutsフレームワークを使用するには、Strutsコンポーネントが同じWebアプリケーションの一部である必要があります。
既存のStrutsアプリケーションの一部をポートレットとして公開するには、最初に、アプリケーションのポートレット・ビューとして機能する新しいビューを作成することをお薦めします。このビューでは、既存のオブジェクト（Actions、ActionFormなど）とともに新しいマッピングとJSPを使用します。
|
注意: アプリケーションのポートレット・ビューを作成することをお薦めしますが、アプリケーションのStrutsタグをPDK-JavaのStrutsタグに置き換えることもできます。この方法を使用すると、アプリケーションをスタンドアロンStrutsとポートレットの両方として実行できます。 |
この例では、新しいエントリをBlogに追加できるポートレットを作成します。図61-3および図61-4は、Blogを送信してBlogエントリを保存する方法を示しています。
prepareNewBlogは、リクエストをenterNewBlog.jspページにリダイレクトする単純な空のアクションです。このページには、新しいBlogを送信するためのフォームが表示されます。
struts-config.xmlで対応するエントリは次のとおりです。
<action path="/prepareNewBlog" scope="request"
type="view.PrepareNewBlogAction" >
<forward name="success" path="/view/enterNewBlog.jsp"/>
</action>
<action path="/saveNewBlog" name="blogForm" scope="request"
type="view.SaveNewBlogAction" input"/view/enterNewBlog.jsp" >
<forward name="success" path="/view/newBlogConfirmation.jsp"/>
</action>
この項の内容は、次のとおりです。
新しいビューを作成するには、最初に、様々なアクションとリクエストをポータル固有のJSPにリダイレクトするActionMappings (ページ・フロー)の新しいセットを作成します。
<action path="/portal/prepareNewBlog" scope="request" type="view.PrepareNewBlogAction" > <forward name="success" path="/view/portal/enterNewBlog.jsp"/> </action> <action path="/portal/saveNewBlog" name="blogForm" scope="request" type="view.SaveNewBlogAction" input="/view/enterNewBlog.jsp" > <forward name="success" path="/view/portal/newBlogConfirmation.jsp"/> </action>
変更するのはパス属性のみです。FormBeanアクションは、アプリケーションのビジネス・ロジックが変更されないようにします。
前述の手順で指定したように、アクションによってリクエストが新しいJSPに転送され、JSPでポートレットのコンテンツがレンダリングされます。新しいポートレット・ビューのJSPは、HTMLをスタンドアロン・ビューと共有できますが、ポートレットが次の条件を満たしていることを確認してください。
ページの他の部分と整合性のとれたルック・アンド・フィールを維持するスタイルが使用されていること。
HTMLの表のセルに格納できるHTMLコードが含まれていること（つまり、<html>、<body>および<frame>タグ以外）。
PDK-JavaバージョンのStruts HTMLタグ・ライブラリを使用すること。これにより、ポートレット・コンテキストで機能する正しい形式でURLがレンダリングされます。
PDK Struts HTMLタグ・ライブラリには、ポートレット・マークアップで使用可能なバージョンのStruts HTMLタグが含まれます。
|
注意: Oracle PDKはOracle JDeveloperに登録できるため、Oracle JDeveloperのコンポーネント・パレットからタグを削除できます。詳細は、Oracle JDeveloperのオンライン・ヘルプの「JDeveloperでのカスタム・タグ・ライブラリの登録」の項を参照してください。 |
Strutsポートレットは、手動またはOracle PDK-Javaポートレットの作成ウィザードを使用して作成できます。ウィザードでは明示的にStrutsサポートを提供していませんが、ウィザードを使用してStrutsポートレットを作成できます。
ポートレットを作成する手順は次のとおりです。
JDeveloperでOracle PDK-Javaポートレットの作成ウィザードを開きます。
詳細は、第60.2.4項「PDK-Javaポートレットの作成方法」を参照してください。
ウィザードの「ビュー・モード」ページで、「ページの表示」モードに対して、「実装スタイル」として「Java Class」を選択します。
「パッケージ名」には、oracle.portal.provider.v2.render.httpと入力します。
「クラス名」には、StrutsRendererと入力します。これにより、ポートレットのレンダラ・クラスのスケルトンとしてStrutsRendererが生成されます。
StrutsRendererはPDKに含まれているため、この生成されたファイルは必要ありません。したがって、ウィザードが完了した後は、ウィザードで生成されたファイルを削除する必要があります。これを行うには、システム・ナビゲータ・ウィンドウでファイルをクリックし、JDeveloperの「ファイル」メニューから「ディスクから削除」を選択します。
provider.xmlを編集して、次のプロパティを変更します。
プロデューサ・レベルで、次のタスクを実行します。
Strutsアプリケーションがセッションを使用する場合（たとえば、フォーム・シンクロナイザのトークン・メカニズムが使用されているか、または<actionInSession>がtrueに設定されている場合）、セッション処理を有効にします。
<session>true</session>
ポートレット・レベルで、次のタスクを実行します。
ユーザーがコンテナ・ページを終了したときと同じポートレット状態に常に戻るようにするには、StrutsアクションをStrutsコンテキストに保存するようにStrutsレンダラを構成します。
<actionInSession>true</actionInSession>
ユーザーがコンテナ・ページの外部から戻ると常にポートレットの先頭から開始するようにするには、Strutsアクションを保存しないでください。
<actionInSession>false</actionInSession>
この設定はデフォルトの動作です。
ポートレットがコールされたときに起動する最初のアクションを指定します。次のコードを使用します。
<showPage class="oracle.portal.provider.v2.render.http.StrutsRenderer"> <defaultAction>/portal/prepareNewBlog.do</defaultAction> </showPage>
アプリケーションで、ユーザーの情報、パーソナライズ、ローカライゼーションなど、環境固有のコードを追加する必要があります。これを行うために、コンテキストでのみコールでき、すべてのビジネス・ロジックを処理する新しいActionクラスを作成できます。
ポートレットをコンシューマが使用する準備が完了すると、そのポートレットを登録してアクセス可能にする必要があります。PDK-Javaポートレットの登録方法の詳細は、第62.4項「ポートレットの登録と表示」を参照してください。
