ホワイト ペーパー : WebLogic Portal フレームワーク
|
 |
 |
|
このドキュメントでは、ポータル フレームワークの基本的な技術について概説します。このドキュメントの読者は、J2EE に関する十分な知識があり、すでに WebLogic Portal に精通している開発者を対象にしています。
このドキュメントは、オンライン ドキュメントの補足資料として作成されており、オンライン ドキュメントを理解したうえで、さらに技術的な内容を理解するための資料として使用できます。このドキュメントでは、ポータル フレームワークについての説明があり、WebLogic Workshop や WebLogic Administration Portal との対話、または WebLogic Portal のパーソナライゼーション、キャンペーン、コンテンツ管理、コマース コンポーネント、資格、ユーザ管理の機能との対話については直接的には扱っていません。このドキュメントの作成時点では、このドキュメントで説明する多くの機能は WebLogic Workshop や WebLogic Administration Portal で使用されていませんが、ぜひこれらの機能についても調べることをお勧めします。
最初に用語を定義しておきます。これらの用語はこのドキュメント全体を通して使用されるので重要です。これらの用語の概念は覚えるようにしてください。
アプリケーションを表示するための XML フレームワーク。Netuix は当初、Netui の拡張機能として設計されました。しかし、現在の Netuix は、Netui に基づく技術でも、依存する技術でもありません。Netuix とNetui はまったく異なる技術として発展しました。その結果、名前だけが似ている技術となりました。ただし、技術的には異なっていても、Netuix は Netui アプリケーションをシームレスにホストします。
API を通じてポータルを変更する場合に使用される用語。この API は通常、WebLogic Administration Portal や訪問者ツールのページから呼び出せますが、デスクトップを変更する開発者も利用できます。
この API には、デスクトップの変更に必要なすべての CRUD 機能と、そのすべてのコンポーネント (ポートレット、ブック、ページ、メニューなど) が備わっています。カスタマイズは、パーソナライゼーションとは異なります。カスタマイズは、デスクトップの構成を意図的に変更することを意味します。一方、パーソナライゼーションは、ルールと行動に基づいて変更することを意味します (たとえば、ブロンコスのチケットを広告に掲載するのは、金曜日であり、訪問者がデンバーに居住しているというルールや行動に基づく)。
EJB やデータベースが含まれていない WebLogic Portal の簡易バージョン。ライト ポータルは、カスタマイズを除く、ポータル フレームワークのすべての機能をサポートします。ライト ポータルはポータル ファイルのみを表示します。データベースにアクセスして、デスクトップをカスタマイズすることはできません。ライト ポータルは、WebLogic Workshop の開発環境での表示に使用しますが、プロダクション システムでの表示にも使用できます。
Netuix のユーザ インタフェース コントロール。WebLogic Workshop のビジネス コントロールとは異なります。XML ドキュメントの各要素 (.portal、.portal、.shell、.layout、.laf および .menu) が UI コントロールのインスタンスを表します。一般的なコントロールには、ブック、ページ、メニュー、ポートレットなどがあります。
WebLogic Workshop で作成する .portal ファイルは完全に機能するポータルですが、デスクトップを作成するテンプレートとして利用することもできます。このテンプレートでは、ブック、ページ、ポートレットの参照を作成し、それらのデフォルトを定義します。
この .portal ファイルをブラウザで表示するときは、ポータルは「シングル ファイル モード」で表示されます。これは、ポータルをデータベースからではなく、ファイル システムから表示していることを意味します。つまり、.portal ファイルの XML が解析され、表示されたポータルがブラウザに返されるしくみです。.portal を作成するのは、開発目的に使用したり、静的ポータル (エンド ユーザや管理者によってカスタマイズされないポータル) として利用するためです。データベースを使用しないため、ユーザ カスタマイズや資格などの機能は利用できません。
作成した .portal ファイルを使用して、デスクトップ (ストリーミングされたポータル) を作成することができます。デスクトップは、訪問者がアクセスできるポータルのビューです。デスクトップは、管理者やエンド ユーザが更新することができます。
ポータルを複数のデスクトップで構成して、デスクトップのコンテナとして使用することができます。デスクトップには、ユーザ専用のポータル ビューを作成するために必要なポートレット、コンテンツ、シェル、レイアウト、およびルック アンド フィール要素をすべて配置できます。WebLogic Administration Portal で .portal ファイルに基づいてデスクトップを作成する場合は、デスクトップと、そのブックおよびページをデータベースに格納することができます。
デスクトップ、ブック、ページは、シェル、メニュー、ルック アンド フィール、およびポートレットを参照します。.portal ファイルに記述されているルック アンド フィールなどの設定は、デスクトップのデフォルトとなります。.portal テンプレートから新しいデスクトップを作成した場合、そのデスクトップはテンプレートから切り離され、.portal ファイルへの変更はデスクトップに反映されなくなります (デスクトップへの変更も .portal ファイルに反映されない)。
たとえば、WebLogic Administration Portal でデスクトップのルック アンド フィールを変更した場合は、その変更はデスクトップのみに反映され、元の .portal ファイルには反映されません。ブラウザでデスクトップを表示した場合は、そのデスクトップは (データベースから) 「ストリーミング モード」で表示されます。この場合はデータベースが使用されるため、デスクトップのカスタマイズを保存し、委託管理と資格をポータル リソースに設定することができます。
前述のとおり、Netuix はアプリケーションを表示する XML フレームワークです。アプリケーションがポータルに見えるかどうかは関係ありません。現在、BEA 社の製品を利用されている多くのユーザは、そのフレームワークからポータルの外観を持たないアプリケーションを作成しています。一般的にポータルといえば、「My Yahoo!」を思い浮かべますが、Netuix で開発された数多くのアプリケーションには My Yahoo! のようなものもあれば、そうでないものもあります。
Netuix アプリケーションは、1 つまたは複数の XML ドキュメントで表示されます。その最も一般的なドキュメントには、.portal ファイル (.portal 拡張子の付いた XML ファイル) があります。このポータル ファイルには、ポータル インクルード ファイルがインクルードされているものと、そうでないものがあります。このインクルード ファイルは .pinc ファイル (.pinc 拡張子の付いたファイル) と呼ばれます。ちょうど JSP に他の JSP ファイルをインクルードして機能を拡張できるように、ポータル ファイルには他のポータル ファイルをインクルードすることができます。
.pinc ファイルはポータル ファイルとは異なります。ポータルにはルート要素やコントロールがインクルードされますが、.pinc ファイルにはインクルードされません。この点については後で詳しく説明します。ただし、重要な点だけ述べておくと、ポータル ファイルは親ファイルであり、そのファイルに 1 つまたは複数の .pinc ファイルがインクルードされる場合もあれば、さらにそのファイルに他の .pinc ファイルがインクルードされる場合があります。また、もう 1 つの重要な点ですが、.pinc ファイルのルート要素として、ブックまたはページ要素を最初に指定する必要があることも覚えておいてください。ブックとページについては後述します。
ポータル ファイルでは、各要素が UI コントロールのインスタンスを表しているものと考えることができます (UI コントロールは Workshop のビジネス コントロールとは異なります)。これらのコントロールは階層ツリーで表現できます。つまり、どのコントロールにも親があり、子を持つ場合もあります。コントロールは実行時に相互に検出することが可能で、新しい子を追加したり、既存の子を削除すると、ツリーの形状は変わります。コントロールはすべて、特定のライフサイクル (コントロールによって特定の順序で呼び出される一連のメソッド) に基づいて実行されます。メソッドはすべて、深さ優先順で次々と呼び出されます。
このことを例証するには、あるユーザがブラウザからポータルをシングル ファイル モードで要求する際に起きるイベント シーケンスを考えてみましょう。ただしその前に、ポータル フレームワークのアーキテクチャについて説明しておく必要があります。ポータルやデスクトップに対する要求はすべて、PortalServlet を介して行います。PortalServlet は、appmanager の URL パターンおよび *.portal の下にある web.xml ファイルに登録されています。PortalServlet が .portal で終わる要求を検出すると、その要求はロケール ファイルに対する要求であり、XML 用の永続性 API を呼び出す必要がないことを認識します。
PortalServlet は最初に、XML ファイル (.portal) を解析し、その解析結果に基づいてコントロール ツリーを生成します。ポータル ファイル内の各要素はコントロール ツリー上のコントロールを表し、要素の各属性はコントロールのインスタンス変数を表します。これで、コントロール ツリーと同じ階層が、XML ドキュメント内で維持されることになります。コントロールとは、別の Java クラスである UI コントロールを拡張した Java クラスです。このリリースでは、開発者に対してこれらのコントロールを明示的に公開していませんが、開発者はバッキング ファイル、コンテキスト、スケルトン JSP などを使用してコントロールを操作できます。このことについては後述します。
注意 : 実際には、PortalServlet が要求ごとに XML ドキュメントを解析することはありません。エンタープライズ アプリケーションに必要なパフォーマンスを確保するために、キャッシュなどのさまざまな技術がバックグラウンドで実行されています。
コントロール ツリーが作成され、すべてのインスタンス変数がコントロールに設定されたら、コントロール ツリーはそのライフサイクルを通して実行されます。ライフサイクルとは、明確に定義された順序でコントロールから呼び出される一連のメソッドと考えることができます。ライフサイクルのメソッドには、次のものがあります。
init()
loadState()
handlePostbackData()
raiseChangeEvents()
preRender()
saveState()
render()
dispose()
これらのメソッドは、深さ優先順で呼び出されます。つまり、最初にすべての init() メソッド、次に loadState() メソッドという順序で呼び出されます。また、さらにこれらのメソッドが深さ優先順で呼び出されます。たとえば、以下のコントロール ツリーでは、init() メソッドは C1、C2、C5、C3、C6、C7、C4 の順に呼び出され、次に loadState() メソッドも同じ順序で呼び出されます。
最後に呼び出されるメソッドは、C4 の dispose() になります。
この節では、ポータル フレームワークを構成する Netuix の全コントロールについて説明します。コントロールの関係は、XML スキーマ定義 controls-netuix-1_0_0.xsd に基づきます。次の図は、スキーマ定義をまとめたものです。
デスクトップ コントロールは、他のすべての Netuix コントロールをホストする親コントロールです。どのポータルにも、1 つのデスクトップ コントロールが必要です。デスクトップ コントロールは実際には、資格チェック以外にわずかな機能を提供するだけで、主に他のコントロールを検出する場所になります。
開発者にとって最も重要な機能は、デスクトップ コントロールの PresentationContext です。これでコントロール ツリーを走査すると、ブック、ページ、ポートレットなどの子コントロールをすべて参照できます。他にも DesktopBackingContext や子コントロールを検出するための数多くのメソッドが、WebLogic Platform 8.1 SP3 で追加されました。
ウィンドウ コントロールは、一般的なコンピュータのウィンドウ表示に類似する機能を備えています。ウィンドウでは、状態とモードがサポートされています。状態は、最小化、最大化、フロート、削除のようにウィンドウの表示に影響します。モードは、編集やヘルプのようにコンテンツに影響します(カスタム モードもサポートされている)。また、ウィンドウは、他のウィンドウのコンテナとしても機能します。たとえば、ブックにはページを含めることができます。
ウィンドウ コントロールには、コンテンツ コントロールが含まれている必要があります。コンテンツ コントロールは、ウィンドウ内部に実際のコンテンツをホストします。ウィンドウ コントロールは抽象クラスであり、ポータルで使用する必要があるブック、ページ、ポートレットという 3 種類の派生クラスの中の 1 つです。以下の図に、ウィンドウ、ブック、ページ、ポートレットの関係を示します。
ブックは、移動先の対象の集まりです。移動先の対象は、ブックやページです。ブックには、移動先の対象間を移動するためのメニュー コントロールがオプションで含まれています。コードの観点からすると、移動先の対象とはブックやページが実装するインタフェースであるといえます。
ページを使用すると、配置の対象を表示できます。配置の対象は、ポートレットやブックです。ページには、1 つまたは複数のプレースホルダを含むレイアウトがあります。プレースホルダは 0 個以上の配置の対象をホストできます。
ポートレットをウィンドウとして使用すると、さまざまなタイプのアプリケーションをホストできます。このドキュメントの作成時点では、アプリケーションとして、HTML ページ、JSP ファイル、.pinc ファイル、ページフロー、Struts、Webflow、JSR 168 ポートレット、および WSRP プロキシ ポートレットを指定できます。
メニューは、ブックやページに緩やかに結合されたオプションのコンポーネントです。メニューは、タブやリンク、またはツリー構造などのナビゲーション コンポーネントを表示します。メニューが PageChaneEvents を起動すると、ページはこれをリスンしてアクティブになります。
このドキュメントの記載時点では、WebLogic Portal には Singlelevel と Multilevel の 2 種類のメニューがあります。今後配布されるサービス パックやリリースでは、メニューの種類がさらに増える可能性があります。また、独自のメニューを作成することもできます。その場合は、JSP の <render:pageUrl/> タグを使用するか、preRender メソッドの前にバッキング ファイルから setupPageChangeEvent メソッドと、ブック、ページ、またはポートレットのバッキング コンテキストを呼び出します。
ブックの直接のページと子ブックについて、1 行分のタブが表示されます。
ブック内のすべてのブックとページについて、階層メニューが再帰的に表示されます。つまり、このメニューが表示されるのは、最初の子だけではありません。ツリー全体が表示されます。親ブックで multilevelmenu が使用されている場合は、子ブックにも multilevelmenu が適用されるため、その子ブックではメニューを使用しません。
レイアウトとプレースホルダ (パーソナライゼーション プレースホルダとは異なる) を使用すると、ページにポートレットとブックを表示する方法を構成できます。レイアウトのプレースホルダは HTML テーブル セルとして表示されます。
WebLogic Portal には、事前に定義されたレイアウトと、独自のカスタム レイアウトを作成する機能が含まれています。今後配布されるサービス パックやリリースでは、レイアウトの種類がさらに増える可能性があります。事前に用意されているレイアウトで満足できない場合は、独自のカスタム レイアウトを作成する必要があります。次の節では、そのプロセスについて詳しく説明します。
カスタム レイアウトを作成する際には、次の 3 つのファイルを作成する必要があります。
レイアウト ファイルには、レイアウトを構成するコントロールを記述した XML の断片が含まれています。このファイルのマークアップは、.portal ファイルとデータベースにコピーされてから再アセンブリされます。レイアウト ファイルには、.layout 拡張子を付け、WEB-INF 以外の Web アプリケーション ディレクトリに格納します。
注意 : レイアウト ファイルを作成した後の変更は、データベースには自動的に反映されますが、.portal ファイルのレイアウトには自動的に反映されません。.portal ファイルには、マークアップの参照ではなく、マークアップのコピーが記述されているためです。
.layout ファイルは、手動で (テキストまたは XML エディタで) 作成する必要があります。初めて作成する場合は、既存のレイアウトをコピーすることをお勧めします。ポータルに含まれるレイアウト ファイルは、/framework/markup/layout ディレクトリにあります。
次の要素セットは、レイアウトに固有のものです。独自のレイアウトを作成する場合は、以下の 4 種類の基本レイアウト コントロールのいずれかを選択する必要があります。<netuix:layout/> はその中で最も汎用性があり、他のコントロールはすべてこのコントロールから派生しています。<netuix:layout/> は、最も柔軟性が高いコントロールですが、同時に実装が最も困難なコントロールであるともいえます。
これは、すべてのレイアウトの基本となるコントロールです。このコントロールを直接使用することも、このコントロールから派生した以下の 3 種類のコントロールを使用することもできます。
このレイアウトでは、列数と行数を指定して、グリッドを定義できます。このレイアウトは通常、1 列、2 列、3 列というようなレイアウトを作成するために使用します。
このレイアウトは、4 つのボーダー プレースホルダと 1 つの中央プレースホルダで構成されます。上下の
プレースホルダは、テーブルの横に広がります。左、中央、および右のプレースホルダは、上下のプレースホルダの間の行に配置され、それぞれ 25、50、および 25% の幅を占めます。上下のプレースホルダ内のポートレットは横フローになり、他のポートレットは縦フローになります。
コンテンツを縦フローにするか、横フローにするかを指定するだけのレイアウトです。
プレースホルダは、上記の 4 種類のレイアウトの子要素です。どのレイアウトにも、少なくとも 1 つのプレースホルダ子要素を指定する必要があります。各プレースホルダには、「レイアウト ロケーション」があります。このレイアウト ロケーションは、レイアウト ファイル内のポジションによって定義されます。レイアウト ロケーションは、0、1、2 から始まります。
これまで 4 種類の基本レイアウト コントロールと子プレースホルダ コントロールについて説明してきました。次に、これらのいずれかを選択して、カスタム レイアウトを作成します。3 つのサブクラス レイアウト コントロールのパラメータを調整して使用しない場合は、<netuix:layout> コントロールを使用します。
カスタム レイアウトを作成する方法をわかりやすく説明するために、例を示します。横に広がる 1 つの行を上に配置し、その下に 2 つの列を配置したカスタム レイアウトを作成します。下の 2 つの列は、30% と 70% の幅の比率で配置します。
<netuix:layout title="Spanning Two Column" description="One row and two columns."
type="spanning"
skeletonUri="/customskeletons/spanningtwocolumnlayout.jsp"
htmlLayoutUri="/framework/markup/layout/spanningtwocolumn.html.txt"
iconUri="/framework/markup/layout/spanningtwocolumn.gif"
markupType="Layout" markupName="spanningTwoColumnLayout">
<netuix:placeholder title="top" description="The top spanning placeholder."
markupType="Placeholder"
markupName="spanningTwoColumn_top">
</netuix:placeholder>
<netuix:placeholder title="left" description="The bottom left placeholder"
markupType="Placeholder"
markupName="spanningTwoColumn_left">
</netuix:placeholder>
<netuix:placeholder title="right" description="The bottom right placeholder"
markupType="Placeholder"
markupName="spanningTwoColumn_right">
</netuix:placeholder>
</netuix:layout>
<netuix:markupDefinition>、<netuix:locale/>、および <netuix:markup/> 要素は、このコードをわかりやすくするために省略しています。実際の .layout ファイルにはこれらの要素を記述してください。
このレイアウト例では、<netuix:layout/> 要素を使用し、その下に 3 つのプレースホルダを使用しました。また、markupNames には独自の名前を指定し、表示するための独自のカスタム スケルトンを指定しました。
表示するためにカスタム スケルトンを使用しているので (skeletonUri 属性で指定)、この JSP を作成する必要があります。最も簡単に作成するには、既存の JSP をコピーします。
注意 : コントロールのスケルトン JSP は 2 回呼び出されます。1 回目は「begin render」、2 回目は「end render」のときです。この begin render と end render フェーズの間に子が表示されます。これにより、HTML テーブルを begin render セクションで開き、end render セクションで閉じることができます。どのスケルトン ファイルにも、次の JSP タグを使用します。
beginRender タグの本体は begin render フェーズのときだけ評価され、endRender タグの本体は end render フェーズのときだけ評価されます。
新しいスケルトン JSP (/customskeletons/spanningtwocolumnlayout.jsp) を次に示します。
%@ page import="com.bea.netuix.servlets.util.RenderToolkit,
com.bea.netuix.servlets.controls.layout.LayoutPresentationContext,
java.util.List,
com.bea.netuix.servlets.controls.layout.PlaceholderPresentationContext"
%>
<%@ taglib uri="render.tld" prefix="render" %>
<%
RenderToolkit toolkit = RenderToolkit.htmlInstance();
LayoutPresentationContext layout =
LayoutPresentationContext.getLayoutPresentationContext(request);
%>
<render:beginRender>
<table
<% toolkit.writeId(out, layout.getPresentationId()); %>
<% toolkit.writeAttribute(out, "class", layout.getPresentationClass(), "layout-custom"); %>
cellspacing="0"
>
<tbody>
<%
List children = layout.getChildren("layout:placeholder");
// 省略可能なプロパティを取得して表示できる。
// String property = layout.getProperty("myProperty");
for (int i = 0; i < children.size(); i++)
{
PlaceholderPresentationContext placeholderPresentationContext =
(PlaceholderPresentationContext)children.get(i);
if (i == 0)
{
%>
<tr>
<td colspan="2" width="100%" valign="top" class="layout-placeholder-container">
<% toolkit.renderChild(placeholderPresentationContext, request); %>
</td>
</tr>
<%
}
else if (i == 1)
{
%>
<tr>
<td width="30%" valign="top" class="layout-placeholder-container">
<% toolkit.renderChild(placeholderPresentationContext, request); %>
</td>
<%
}
else if (i == 2)
{
%>
<td width="70%" valign="top" class="layout-placeholder-container">
<% toolkit.renderChild(placeholderPresentationContext, request); %>
</td>
</tr>
<%
}
}
%>
</render:beginRender>
<render:endRender>
</tbody>
</table>
</render:endRender>
注意 : この例では width が JSP にハードコード化されています。ハードコード化しない場合、width はプレースホルダの属性としてレイアウト ファイルで指定する必要があります。width は次のようにスケルトンで参照されます。
"rowspan=2" などのプロパティは、プロパティ属性の名前/値ペアとして渡せます。また、"endtop" を指定して、行/列が広げられた、より汎用的なレイアウトを作成できます。
これで、カスタム レイアウトは完全に機能します。html.txt ファイルをまだ作成していなくても、レイアウトをテストすることはできます。そのために、WebLogic Workshop を起動し、ポータル ファイルを開くか作成します。次に、ページを選択してから、[プロパティ エディタ] ウィンドウの [レイアウト タイプ] フィールドでカスタム レイアウトを選択します。
注意 : .portal ファイルで使用した後に .layout ファイルを変更した場合、その変更は .portal ファイルに反映されません。これは、.portal ファイルでレイアウトを使用したときに、.portal ファイルにはレイアウトのマークアップがコピーされているためです。変更を反映させるには、いったん別のレイアウトを選択してから、元のレイアウトを選択し直す必要があります。
.html.txt は、WebLogic Administration Portal と Weblogic Workshop でのみ使用される HTML の断片です。このファイルにより、レイアウトを視覚的に表現できるため、管理者はポートレットを適切なプレースホルダに配置できます。このファイルは、表示フレームワークによって使用されないため、最後に作成するファイルになります。
ここでは、最後の作業として html.txt ファイルを作成し、WebLogic Administration Portal でレイアウトを視覚的に表現できるようにします。/framework/markup/layout/spanningtwocolumn.html.txt は、次のようになります。
<table class="portalLayout" id="thePortalLayout" width="100%" height="100%">
<tbody>
<tr>
<td class="placeholderTD" valign="top" width="100%" colspan="2">
<placeholder number="0"></placeholder><br>
</tr>
<tr>
<td class="placeholderTD" valign="top" width="30%">
<placeholder number="1"></placeholder><br>
</td>
<td class="placeholderTD" valign="top" width="70%">
<placeholder number="2"></placeholder><br>
</td>
</tr>
</tbody>
</table>
コントロールは開発者に直接公開されていないため、開発者にはコントロールの動作を直接操作し、制御する手段が必要です。そのため、WebLogic Portal のコンテキスト、バッキング ファイル、スケルトン、およびイベントが公開されています。開発者は、ポータル フレームワークの動作を変更したり、ポータル フレームワークを操作する場合、これらのコンポーネントを使用する必要があります。
コンテキストは、基礎となるコントロールの代理としてのみ機能します。つまり、この代理機能は、コントロールにサポートされているメソッドをエクスポーズするだけの役割を持ちます。
コンテキストには、バッキング コンテキストとプレゼンテーション コンテキストの 2 種類があります。バッキング コンテキストはバッキング ファイルから取得し、プレゼンテーション コンテキストは JSP から取得します。
2 種類のコンテキストが必要になるのは、ライフサイクルを通して適用するメソッドが異なるためです。たとえば、プレゼンテーション コンテキストでは setTitle() メソッドを使用しません。ポータルではすでに表示が開始されており、setTitle() メソッドを使用しても意味がないためです。しかし、このメソッドをバッキング ファイルから呼び出す場合は意味があります。
バッキング コンテキストはバッキング ファイルから取得します。バッキング コンテキストへの参照は、次のいずれかの方法で取得できます。
getXXXBackingContext を使用する。このメソッドは、同タイプのアクティブなバッキング コンテキストを返します。つまり、ポートレット A のバッキング ファイルからこのメソッドを呼び出した場合は、ポートレット B ではなく、ポートレット A のバッキング コンテキストを取得します。同様に、ポートレット A から getPageBackingContext(request) を呼び出した場合は、ポートレット A が配置されているページのページ バッキング コンテキストを取得します。
ポートレット A がポートレット B と同じページに配置されている場合は、以下のコードを使用します。
PortletBackingContext portletB = PageBackingContext.getPageBackingContext(request).PortletBackingContext getPortletBackingContextRecursive("Portlet Bs instance label");
ポートレット A からはポートレット B がどこに配置されているかわからない場合は、DesktopBackingContext に委託できます。
PortletBackingContext portletB = DesktopBackingContext.getPageBackingContext(request).PortletBackingContext getPortletBackingContextRecursive("Portlet Bs instance label");
詳細については、Javadoc で以下のバッキング コンテキストや他のバッキング コンテキストを参照してください。
com.bea.netuix.servlets.controls.page.PageBackingContext
com.bea.netuix.servlets.controls.application.backing.DesktopBackingContext
プレゼンテーション コンテキストは、JSP ファイルから取得します。プレゼンテーション コンテキストへの参照は、次のいずれかの方法で取得できます。
getPagePresentationContext(request) を呼び出した場合は、ポートレット A が配置されているページのページ プレゼンテーション コンテキストを取得します。 バッキング ファイルは、com.bea.netuix.servlets.controls.content.backing.JspBacking インタフェースを実装するか、com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking 抽象クラスを拡張したシンプルな Java クラスです (バッキング クラスと呼ぶこともできる)。インタフェースのメソッドは、コントロール ライフサイクル メソッドに類似しており、コントロール ライフサイクル メソッドの呼び出しと同時に呼び出されます。
このドキュメントの記載時点でバッキング ファイルをサポートするコントロールには、次のものがあります。
注意 : Service Pack 3 以降は、デスクトップでもバッキング ファイルがサポートされています。
バッキング ファイルの新しいインスタンスは要求ごとに作成されるため、スレッドの安全性の問題を心配する必要はありません。新しい Java VM は、有効期限が短いオブジェクト用に特別に調整されているため、以前のようなパフォーマンスの問題は発生しません。さらに、JspContent コントロールでサポートされる特殊なバッキング ファイルを使用すると、バッキング ファイルがスレッド セーフかどうかを指定できます。この値を true に設定すると、バッキング ファイルのインスタンスが 1 つだけ作成され、すべての要求で共有されます。
スケルトンは、表示フェーズで使用される JSP です。表示フェーズは、実際には begin render と end render で構成されます。親のコントロールの begin render が呼び出されると、次にその子の begin render、さらに孫の begin render が次々と呼び出されます。最後の begin render が呼び出された後は、子孫の end render から順に親の end render まで呼び出されます。これにより、親は HTML テーブルなどのコンテナを提供でき、子はテーブル コンテンツを提供できます。
スケルトンは実際には 2 回呼び出されます。スケルトンには、特定の表示フェーズにおいてのみ true を返す特殊なタグがあります。
モード、状態およびページ変更イベントは、開発者に直接公開されていませんが、ウィンドウ バッキング ファイルの特殊なメソッドを使用して設定することができます。たとえば、setupModeChangeEvent、setupStateChangeEvent、setupPageChangeEvent() などのメソッドを使用します。これらのメソッドは preRender メソッドの前に呼び出す必要があります。イベントは、handlePostbackData メソッドの後に起動するためです。また、これらのメソッドは、handlePostbackData メソッドが true を返す場合にのみ有効です (Javadoc を参照)。
注意 : setupxxevent メソッドのいずれかを呼び出す場合、その呼び出しは、バッキング ファイルが関連付けられているバッキング コンテンツで行う必要があります。そうしないと、イベントが起動しない場合があります。
ポートレット イベント (ページフロー イベントとは異なる) を使用すると、ポートレット間の通信が可能になります。一方のポートレットでイベントを作成し、他方のポートレットでそのイベントをリスンできます。これらのポートレット イベントはペイロードを伝達することもできます。
一方のポートレットがバッキング ファイルからイベントを起動し、他方のポートレットがそのイベントをリスンする例を次に示します。
コード リスト 4 ポートレットがバッキング ファイルからイベントを起動するコードの例
/**
* バッキング ファイルからイベントを起動するポートレットの実装。
*/
public boolean handlePostbackData(HttpServletRequest request, HttpServletResponse response)
{
// 新しいポートレット イベントを作成し、その結果をペイロードに格納する。
PortletEvent portletEvent = new PortletEvent(new MyPayload("Hello From portlet A"));
// ポートレット イベント マネージャを呼び出し、イベントを起動する。
PortletBackingContext portletBackingContext =
PortletBackingContext.getPortletBackingContext(request);
PortletEvent.Manager portletEventManager =
PortletEvent.getEventManager(this, portletBackingContext);
portletEventManager.fireEvent(portletEvent);
// イベントの起動に必要。
return true;
}
/**
* イベントを受信するポートレットの実装。
*/
public class ResultBacking extends AbstractJspBacking implements PortletEventListener
{
MyPayload result;
public void init(HttpServletRequest request, HttpServletResponse response)
{
result = null;
// ポートレット イベント用に登録する。
PortletBackingContext portletBackingContext =
PortletBackingContext.getPortletBackingContext(request);
PortletEvent.addGlobalListener(portletBackingContext, this);
CustomPortletEvent.Manager portletEventManager =
CustomPortletEvent.getEventManager(this, portletBackingContext);
}
public void handleEvent(Object source, AbstractEvent event)
{
//イベントのソースを確認できる。
if (source instanceof PortletA)
{
result = (MyPayload)((PortletEvent)event).getPayload();
}
}
注意 : チュートリアル ポートレットには、イベントを介してポートレット間で通信を行うサンプルがあります。
カスタマイズは、管理者やエンド ユーザがデスクトップに変更を行う場合に使用される用語です。カスタマイズは通常、管理ツールまたは訪問者ツールの Web アプリケーションを使用して行います。ただし、開発者はこれらの API をコード内で直接呼び出すことができます。これらの API の詳細については、Javadoc を参照してください。
|
|
|