|
|
この章では、ポータルの開発を始める際に役立つ概要および参考情報について説明します。
Workshop for WebLogic を使用してポータルを開発する場合、ポータルの定義は単一の XML ファイルとして存在します。エディタを使用してポータルを構築すると、Workshop for WebLogic によって XML ファイルが自動的に作成されます。
ポータル ファイルには、特定のポータル インスタンスを構成するすべてのコンポーネント (ブック、ページ、ポートレット、ルック アンド フィール コンポーネントなど) が格納されます。
多くのコンポーネントは、相互に階層的な関係を持ちます。たとえば、ブックにはページが含まれ、ページにはポートレットが含まれます。図 3-1 は、ポータルのコンポーネント間の関係を示しています。
Workshop for WebLogic でポータル リソースやテンプレートを開発する場合、または WebLogic Portal Administration Console でポータルの作成や管理を行う場合のいずれにおいても、ポータル フレームワークによって統一されたコンポーネントを個別に操作します。
図 3-1 は、WebLogic Portal アーキテクチャの柔軟性と拡張性を示しています。この図で、(0...1) は 0 または 1 を意味し、(1...n) は 1 以上を意味し、(0...n) は 0 以上を意味します。たとえば、ポータルには 1 つまたは複数のデスクトップを含めることができます。ルック アンド フィールやシェルのように一度しか出現しないリソースの場合、一度に 1 つしか使用できなくても複数のバージョンを作成できます。
BEA Workshop for WebLogic Platform は、Eclipse Platform に対するプラグインとして実装されます。具体的には、Eclipse Workbench、Java 開発ツール (JDT)、Web Tools Platform Project (WTP) のカスタマイズ バージョン、Workshop for WebLogic 固有のプラグインなどがあります。Workshop for WebLogic ワークベンチを使用する際の具体的な手順については、BEA Workshop for WebLogic Platform のドキュメントを参照してください。WebLogic Portal には、ポータルおよびポートレットの開発を容易にする付加機能が用意されています。
この手順を進める前に、BEA Workshop for WebLogic のプログラマーズ ガイドまたは e-docs のヘルプにあるチュートリアル「BEA Workshop for WebLogic Platform 入門」を参照して、Workshop for WebLogic の機能をよく理解しておいてください。
「ポータル開発環境の設定」の説明に従ってポータル開発環境を設定した場合、一般的に、アプリケーションは図 3-2 に示すコンポーネントで構成されます。
これらは、ポータル アプリケーションの開発とテストに必要となる基本的な部分です。
WebLogic Portal では、Eclipse および Workshop for WebLogic の標準的なビューと独自のカスタマイズ ビューを組み合わせることによって、ポータルの構築を簡略化しています。図 3-3 に、ポータル開発時における Workshop for WebLogic ワークベンチの外観の例を示します。
開発時には、伝播パースペクティブおよびページ フロー パースペクティブも使用します。伝播パースペクティブの詳細については、『プロダクション業務ガイド』を参照してください。ページ フロー パースペクティブの詳細については、Workshop for WebLogic のヘルプを参照してください。
共有 J2EE ライブラリ (ライブラリ モジュールとも呼ばれます) を使用すると、すべての EAR プロジェクトおよびポータル Web プロジェクトにリソースを複製する代わりに、単一のリソース セットをデプロイして使用できます。ソース管理、ファイル共有、およびアプリケーションへのパッチ適用を行う場合に大きな利点があるため、共有 J2EE ライブラリの使用をお勧めします。WebLogic Portal では、共有 J2EE ライブラリが実装されたコンフィグレーションのみがサポートされます。共有 J2EE ライブラリの詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。
図 3-2 のように、EAR プロジェクトと Web プロジェクトには、実際にはドメイン レベルで格納される共有 J2EE ライブラリへの参照が設定されています。これらのプロジェクトは、参照元アプリケーションの一部としてパッケージ化されたモジュールのように使用できます。
J2EE ライブラリのリソースは、ポータル Web プロジェクトにコピーしてからカスタマイズすることで、オーバーライドできます。たとえば、特定のポータル Web プロジェクトでデフォルトのルック アンド フィールを変更する場合、デフォルトのルック アンド フィールをライブラリからポータル Web プロジェクトにコピーし、変更を加えることができます。
リソースをコピーすると、ポータル Web プロジェクト内の「一致する」場所にそのリソースが配置されます。このプロジェクトをデプロイすると、コピーしたリソースが検出され、ライブラリ内のリソースのインスタンスの代わりに、コピーしたリソースのインスタンスが使用されます。
| 警告 : | J2EE ライブラリのリソースをプロジェクトにコピーすると、将来 WebLogic Portal 製品を更新するときに、これらのリソースに影響する製品の変更を手動で組み込む作業が必要になる場合があります。今後配布されるパッチをインストールした場合、WebLogic Portal では、コピーした J2EE ライブラリ リソースがプロジェクトに含まれていないコンフィグレーションだけをサポートします。 |
J2EE ライブラリのリソースをプロジェクトにコピーする方法については、「プロジェクトへの J2EE ライブラリ ファイルのコピー」を参照してください。ポータル開発に対する共有 J2EE ライブラリの影響については、「プロダクションへのポータルのデプロイ」を参照してください。
Workshop for WebLogic で作成する .portal ファイルはテンプレートです。このテンプレートの中に、ブック、ページ、およびポートレットを作成し、それぞれのデフォルト値を定義します。この .portal ファイルをブラウザで表示するときは、ポータルは「シングル ファイル モード」で表示されます。これは、ポータルをデータベースからではなく、ファイル システムから表示していることを意味します。つまり、.portal ファイルの XML が解析され、表示されたポータルがブラウザに返されるしくみです。.portal ファイルの作成と使用は開発を目的としていますが、プロダクション環境でも .portal ファイルにアクセスできます。データベースを使用しないため、ユーザ カスタマイズや資格などの機能は利用できません。
.portal ファイルの作成が済んだら、WebLogic Portal Administration Console を使用して、プロダクション環境用のデスクトップを作成することができます。
デスクトップは、訪問者がアクセスできるポータルのビューです。ポータルを複数のデスクトップで構成して、デスクトップのコンテナとして使用することができます。デスクトップには、ポータルの個々のユーザ ビューを作成するために必要なポートレット、コンテンツ、シェル、レイアウト、およびルック アンド フィール要素がすべて含まれます。
WebLogic Portal Administration Console で .portal ファイルに基づいてデスクトップを作成した場合、.portal とそのリソースをデータベースに格納できます。ルック アンド フィールなど、.portal ファイル内の各設定がデスクトップのデフォルトになります。.portal テンプレートから新しいデスクトップを作成すると、そのデスクトップはテンプレートから切り離されるため、.portal ファイルを変更してもデスクトップには反映されません。また、デスクトップへの変更も .portal ファイルに反映されません。たとえば、WebLogic Portal Administration Console でデスクトップのルック アンド フィールを変更した場合、その変更はデスクトップだけに反映され、元の .portal ファイルには反映されません。デスクトップをブラウザで表示した場合、デスクトップは (データベースから) 「ストリーミング モード」で表示されます。この場合はデータベースが使用されるため、デスクトップのカスタマイズを保存し、委託管理と資格をポータル リソースに設定することができます。
ストリーミング ポータルとファイルベース ポータルのシステム パフォーマンスの違いはそれほど大きくありません。それぞれのポータル タイプの利点は、作成するポートレット数、ポータルのエンド ユーザに提供する機能、およびポータルの管理方法に大きく左右されます。
表 3-1 では、ストリーミング ポータルとファイルベース ポータルの詳細な比較を示しています。
| 注意 : | ファイルベース ポータルで資格を設定することはできません。ただし、そのポータルに基づくデスクトップを作成し、デスクトップのアーティファクトに対して資格を設定すると、.portal ファイルは実行時にそれらを選択します。.portal ファイルはデータベースにアクセスしませんが、資格チェックは実行時に実施されます (これらの資格は LDAP に格納されます)。ファイルベース ポータルで実行時の資格チェックを行わない場合には、WEB-INF/netuix-config.xml ファイルでこの機能をオフにすることができます。 |
パフォーマンス関連の推奨事項については、「単純なアプリケーションでのファイルベース ポータルの使用」を参照してください。
Java コントロールはイベント、メソッド、およびプロパティで使用する視覚的コンポーネントで、既存のデータ、システム、アプリケーション、およびビジネス ロジックとの接続に関する詳細な実装を規定します。
WebLogic Portal および Workshop for WebLogic で利用可能なコントロールは、次の 3 つのカテゴリに分類されます。
Java コントロールの大部分は WebLogic Portal に含まれています。また、独自のカスタム Java コントロールを作成してビジネス ロジックをカプセル化することもできます。
WebLogic Portal で提供されるカスタム Java コントロールは、定義済みの実行時インタフェースや実行時にポータル HTML を表示するために使用されるコンフィグレーション可能なプロパティを備えた開発オブジェクトです。WebLogic Portal のカスタム コントロールを使用すると、開発者が利用しようと考えるすべての情報に基づいて、ポータルの実行時動作を動的に操作できます。コントロール ツリーは要求されるたびに作成されます。また、デスクトップ、メニュー、ページ、またはポートレット レベルで、ツリー内の各コントロールの動作を操作できます。WebLogic Portal のカスタム コントロールは、WebLogic Portal アーキテクチャの「コンテキスト」によって抽象化されます。これらのコンテキストでは、必要なほとんどすべての実行時動作を実現するのに使用可能な、わかりやすい一連の API が利用できます。
WebLogic Portal のポートレット向けカスタム コントロールは、明確に定義されたライフサイクルに準拠します。このライフサイクルは、必要なコントロール操作を行うためのプラグイン ポイントを提供します。たとえば、init() ライフサイクル ステージでは、ポートレットが表示されないように、ポートレットの「非表示」プロパティを動的に「true」に設定する場合があります。
WebLogic Portal のポータル向けカスタム コントロールは、ページ フロー コントロールと相互運用されます。コントロール アーキテクチャはページ フロー コントロール アーキテクチャと相互運用されます。これにより、ポートレットで表示されるページ フロー アプリケーション間の高度な対話と、より一般的なポータル ウィンドウ管理の定義が可能になります。WebLogic Portal のカスタム コントロールとページ フローの統合は、プロパティ シートなどの Workshop for WebLogic のワークベンチ ツールで表示されるため、ページ フローとポートレットを結合するためにコードを記述する必要はありません。
ポータルをデプロイする際にコントロールにアクセスする手順については、「ページ フローのカスタム コントロール」を参照してください。WebLogic Portal に付属するコントロールとアクションの技術的情報については、「Javadoc」を参照してください。
WebLogic Portal には、JSP 内で使用できる JSP タグが用意されています。ポートレットでは JSP をコンテンツ ノードとして使用できるため、再利用が有効になり、パーソナライゼーションやその他のプログラム機能が簡易化されます。Workshop for WebLogic を使用して JSP を作成すると、ポートレットに追加する他の要素の構造を提供できます。
ポータルの開発時に使用できる JSP タグを表示するには、[ウィンドウ｜ビューの表示｜JSP デザイン パレット] を選択します。
WebLogic Portal の JSP タグに関連付けられたクラスについては、「Jsp Tag Javadoc」を参照してください。
ポータルを非同期的に表示するように選択することができます。このプロパティを設定すると、ページやブックの全体が表示可能になるまで待たなくても、ライフ サイクルの完了時点でポータルの各コンポーネントが表示されます。このプロパティはポータルで (「ポータル コンポーネントのプロパティの設定」を参照)、または各ポートレットごとに (『ポートレット開発ガイド』を参照) 設定できます。
ポータル フレームワーク コントロールのライフサイクル内のポータルの動作を制御する一般的な方法は、バッキング ファイルを使用することです。バッキング ファイルは、init()、preRender() など、ライフサイクルの各段階に対応するメソッドを含むことができる Java クラスです。ポータルのバッキング コンテキスト、つまり、ポータル フレームワーク コントロール 自体を抽象化したものを使用して、ポートレットの特性を問い合わせたり、変更したりすることができます。たとえば、init() ライフサイクル メソッドでは、要求パラメータが評価され、そのパラメータの値に応じて、ポートレットのバッキング コンテキストを使用してポートレットを表示するか非表示にするかを指定できます。バッキング コンテキストの詳細については、『ポータル開発ガイド』を参照してください。
バッキング ファイルは、Workshop for WebLogic を使用するか、特定のフレームワーク コントロールの XML ファイルにコードを直接入力することによって、ポータルに追加できます。
バッキング ファイルは、com.bea.netuix.servlets.controls.content.backing.JspBacking インタフェースの実装、または com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking インタフェース抽象クラスの拡張を行う単純な Java クラスです。インタフェースのメソッドは、コントロール ライフサイクル メソッド (「バッキング ファイルの実行方法」を参照) に類似しており、コントロール ライフサイクル メソッドの呼び出しと同時に呼び出されます。
以下のポータル コントロールがバッキング ファイルをサポートしています。
ポートレット間通信の例については、『ポートレット開発ガイド』を参照してください。
すべてのバッキング ファイルは、JSP 呼び出しの前後に実行されます。ライフサイクルの中で、各バッキング ファイルでは以下のメソッドが呼び出されます。
図 3-4 にバッキング ファイルのライフサイクルを示します。
| 注意 : | 以下の処理手順では、ツリーの最適化が有効で、非アクティブ ページの項目が「最適化により除外」されていない場合にメソッドが呼び出されます。たとえば、ツリーの最適化が有効で、生成される部分的なコントロール ツリーに非アクティブ ページの項目が含まれていない場合、メソッドは呼び出されません。 |
init() メソッドが深さ優先順 (つまり、ツリーに表示されている順) に呼び出されます。このメソッドは、コントロール (ポータル、ページ、ブック、デスクトップ) がアクティブなページ上にあるかないかにかかわらず、呼び出されます。 _nfpb パラメータが true に設定されている場合、すべての handlePostbackData() メソッドが呼び出されます。 handlePostbackData() メソッドの要求パラメータで _nfpb パラメータが true に設定されている場合、raiseChangeEvents() が呼び出される。このメソッドにより、イベントが発生します。バッキング ファイルが状態またはモードの変更を行おうとする場合、イベントの発生が必要です。 | ヒント : | AbstractJspBacking.isRequestTargeted(request) メソッドを使用して、特定のポートレットに対する要求かどうかを判別できます。 |
handlePostbackData() メソッドが true を返す場合、raiseChangeEvents() メソッドが呼び出される。 preRender() メソッドが呼び出されます。dispose() メソッドが呼び出されます。
バッキング ファイルの新しいインスタンスは要求ごとに作成されるため、スレッドの安全性の問題を心配する必要はありません。新しい Java VM は、有効期限が短いオブジェクト用に特別に調整されているため、以前のようなパフォーマンスの問題は発生しません。さらに、JspContent コントロールでサポートされる特殊なバッキング ファイルを使用すると、バッキング ファイルがスレッド セーフかどうかを指定できます。この値を true に設定すると、バッキング ファイルのインスタンスが 1 つだけ作成され、すべての要求で共有されます。
異なるスコープのバッキング ファイルでは、動作が異なります。たとえば、あるフレームワーク コントロールのスコープで使用されるバッキング ファイルは、JSP コンテンツのスコープで使用されるものと異なる動作を持ちます。
<netuix: portlet backingfile =some_value> を使用してポートレット自体にバッキング ファイルがある場合、ポートレットの表示を実際に停止することができます。<netuix: jspContent backingfile=some_value> の一部としてバッキング ファイルを持っている場合、コントロール ツリーのポートレット部分はすでに実行されています。この実装は、ポートレット内の JSP 専用のプロセスを実行したい場合は、このスコープを使用します。
HTTPRequest オブジェクトは変更されやすいため、ライフサイクル メソッド間でデータを渡すときには、リクエスト オブジェクトでなくセッションを使用することをお勧めします。
バッキング ファイルを作成する際は、以下のガイドラインに従う必要があります。
コード リスト 3-1 にバッキング ファイルのサンプルを示します。このサンプルでは、AbstractJspBacking クラスが拡張され、ポートレットで必要なバッキング機能が使用可能になります。HTTPRequest オブジェクトは変更されやすいため、このサンプルではセッション属性を使用しています。ライフサイクル メソッド間でデータを渡すときには、リクエスト オブジェクトでなくセッションを使用することをお勧めします。
package backing;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import com.bea.netuix.events.Event;
import com.bea.netuix.events.CustomEvent;
import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
public class ListenCustomerName extends AbstractJspBacking
{
public void listenCustomerName(HttpServletRequest request,
HttpServletResponse response, Event event)
{
CustomEvent customEvent = (CustomEvent) event;
String message = (String) customEvent.getPayload();
HttpSession mySession = request.getSession();
mySession.setAttribute("customerName", message);
}
}
図 3-5 に示すように、バッキング ファイルは Workshop for WebLogic 内から [プロパティー] ビューの [バッキング ファイル] フィールドでバッキング ファイルを指定するか、関連付けるファイル内に直接にコード化して追加することができます。バッキング ディレクトリを指定し、ドット区切り文字に続けてバッキング ファイルの名前だけを指定します。バッキング ファイルの拡張子は含めないでください。たとえば次のように入力します。
backing.ListenCustomerName.java
この例では、ファイル拡張子を含めた場合、ファイル拡張子がファイル名と解釈されます。これは、ドット区切り文字によってファイル パスが指定されるためです。その結果、アプリケーションは、存在しない ListenCustomerName という名前のディレクトリの、存在しない java という名前のファイルを検索します。
バッキング ファイルをポータル フレームワーク コントロールの XML ファイルにコード化して追加するには、コード リスト 3-2 に示すように、<netuix:jspContent> 要素の中で backingFile パラメータを使用できます。
<netuix:content>
<netuix:jspContent
backingFile="portletToPortlet.pageFlowSelectionDisplayOnly.menu.contentUri="/portletToPortlet/pageFlowSelectionDisplayOnly/menu/
backing.MenuBacking"
menu.jsp"/>
</netuix:content>
Java ページ フローは、Struts ベースの Web アプリケーション プログラミング モデル上に構築される機能セットです。Java ページ フローは Struts の優れた機能と拡張性を利用するだけでなく、Struts ベース アプリケーションを構築する際の問題点を解消します。Java ページ フロー機能では、Web アプリケーション プログラミング モデルや、Web アプリケーション プログラミング モデルに基づいて開発者がアプリケーションを迅速かつ容易に構築するためのツールを実行時にサポートしています。
基本的に、ページ フローは Web アプリケーション ファイルのディレクトリです。これらのファイルは相互に連携して、ユーザ インタフェースの機能を実現します。たとえば、ページ フローによって、Web アプリケーションのユーザ登録ウィザード機能を実現することができます。
ページ間の状態、データ、およびナビゲーション フローは、Java ページ フロー (JPF) ファイルを使用して管理できます。ページ フローでは、他の Workshop for WebLogic アプリケーションと同じプログラミング モデルを使用します。また、Java コントロールのワンクリック生成や標準的な Struts フレームワーク プラグインを使用できます。JPF では、双方向の JSP/HTML エディタを使用して、「WYSIWYG」を開発することもできます。JPF は、コントロールやデータ バインディング タグを使用する Web サービス、ドラッグ アンド ドロップ コントロール、およびデータをバインドしてフォームやデータバウンド Web ページを作成できます。
ページ フローがある場合には、ページ フロー ポートレットを生成して容易にカプセル化できます。この手順の詳細については、『ポートレット開発ガイド』を参照してください。
Workshop for WebLogic によるページ フローの作成の詳細については、e-docs の『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。
WebLogic Portal では、さまざまなメカニズムを利用して HTTP セッションや HTTP リクエストなどの状態を管理できます。また、WebLogic Portal の Java ページ フローでも、Struts ベース フレームワーク内での柔軟性の高い強力な状態管理機能を利用できます。ページ フローの状態管理は、リクエストとセッションの状態管理の間にある溝を埋める役割を果たします。多くのプロジェクトにおいて、リクエストの有効期間は非常に短く、セッションの有効期間は非常に長いため、アプリケーションのニーズを満たすのは困難です。ページ フローを利用すると、状態の有効期間を必要なだけ長くすることができます。
  
|
