![]() ![]() ![]() ![]() |
この章では、ポートレット ウィザード、製品付属のポートレットの使用を含め、ポートレットの最も一般的な作成方法について説明します。また、WebLogic Portal でサポートされている各ポートレット タイプの構築手順も説明します。
この章に進む前に、「ポートレットの開発について」に記述されているポートレット作成に関する概念を把握する必要があります。
WebLogic Portal では、次のポートレット タイプがサポートされています。
各ポートレット タイプの詳細については、「ポートレット タイプ」を参照してください。
J2EE 共有ライブラリ内にあるポートレットなどのリソースをポータル アプリケーションにコピーし、必要に応じて変更することができます。プロジェクトに存在するポートレットは、J2EE 共有ライブラリ内の同じ名前のポートレットよりも優先されます。使用可能なポートレットのリストを表示するには、ワークベンチのマージ済みプロジェクト ビューを使用します。J2EE 共有ライブラリ内のリソースは、斜体で表示されます。ツリーを展開すると、各モジュールに格納されたリソースを表示できます。すべてのJ2EE ライブラリと、それらのファイル システム上での場所を示す参照リストを表示するには、[ウィンドウ|設定|WebLogic|J2EE ライブラリ] を選択します。
使用するポートレットが見つかったら、マージ済みプロジェクト ビュー内でポートレットを右クリックして、[プロジェクトにコピー] オプションを選択します。図 5-1 は、[プロジェクトにコピー] オプションが選択されているマージ済みプロジェクト ビュー内の J2EE 共有ライブラリ ポートレットの例を示しています。
注意 : | GroupSpace サンプル アプリケーションに属するポートレットは、GroupSpace 対応でないアプリケーションでは使用できません。 |
注意 : | J2EE 共有ライブラリのリソースをプロジェクトにコピーすると、将来 WebLogic Portal 製品を更新するときに、これらのリソースに影響する製品の変更を手動で組み込む作業が必要になる場合があります。今後配布されるパッチをインストールした場合、WebLogic Portal では、コピーされた J2EE ライブラリ リソースがプロジェクトにないコンフィグレーションのみがサポートされます。 |
J2EE 共有ライブラリの詳細については、『ポータル開発ガイド』を参照してください。
新規のポートレットを作成する場合に使用できる重要なツールの 1 つに WebLogic Portal のポートレット ウィザードがあります。以降の節では、ポートレット ウィザードについて詳しく説明します。
通常、このウィザードの最初のダイアログでポートレット タイプを選択します。既存のリソースに基づいてポートレットを生成する場合、可能であればポートレット ウィザードによって常にポートレット タイプが自動的に検出されます。
この節では、ポートレットの作成を開始する 2 つの方法の概要を示します。その方法とは、ポートレットのリソース情報またはリソース ファイルを先に作成する方法と、ポートレット自体を先に作成する方法です。
ポートレットの基礎として使用する JSP ファイルなどがすでに存在する場合があります。JSP ファイル以外でも、リソースをポータル (コンテンツ セレクタなど) にドラッグすると、ポートレット ウィザードが自動的に起動します。
ポートレットの基礎として使用するリソースがすでにある場合、以下の手順を実行します。
最初の段階でソース ファイルがまだ存在しない場合、[新しいポートレット] ダイアログとポートレット ウィザードを使用してポートレットを作成できます。そのためには、ポータル Web プロジェクトのフォルダを右クリックし、[新規|ポートレット] を選択します。図 5-4 に [新しいポートレット] ダイアログの例を示します。
親フォルダを確認または変更し、ポートレット名を指定して [終了] をクリックすると、ポートレット ウィザードが起動し、[ポートレット タイプの選択] ダイアログが表示されます。図 5-5 にダイアログの例を示します。
注意 : | Java Server Faces (JSF) ポートレットの選択項目は、ポータル ウェブ プロジェクトに JSF プロジェクト ファセットを追加した場合のみ表示されます。詳細については、「JSF ポートレット」を参照してください。 |
各ポートレット タイプの作成手順の詳細については、「各ポートレット タイプの構築方法」を参照してください。
ポートレット ウィザードは、Workshop for WebLogic で以下のいずれかの操作を実行すると起動します。
portal
ファイルがワークベンチのエディタ ビューで開かれている)。Workshop for WebLogic で、図 5-6 の例に示すような確認ダイアログが表示されます。
[はい] をクリックすると、リソース ファイルの情報を使用してポートレットの作成プロセスが開始されます。
[ファイル|新規|ポートレット] を使用して新規ポートレットを作成する場合は、ポートレット ウィザードが起動する前に [新しいポートレット] ダイアログが表示されます。図 5-4 に [新しいポートレット] ダイアログの例を示します。
デフォルトで、ポートレットを追加するために選択した場所が親フォルダになります。
このダイアログでは、新規ポートレット用のプロジェクトおよびディレクトリを選択し、ポートレット ファイルの名前を指定する必要があります (このファイル名は、ポートレットの作成後に [パッケージ・エクスプローラー] ビューに表示されます)。[終了] ボタンは最初は無効になっています。このボタンは、有効なプロジェクトまたはディレクトリおよびポートレット名を選択した場合に有効になります。このダイアログのフォルダ ツリーで無効なポータル プロジェクトを選択すると、ダイアログの最上部近くのステータス領域に、当該プロジェクトが有効なポータル プロジェクトではないことを示すエラー メッセージが表示されます。有効なプロジェクト (使用できるものがある場合) が選択されるまで次の手順に進むことはできません。
注意 : | WebLogic Portal バージョン 9.2 およびそれ以降のバージョンでは、ポータル以外のプロジェクトをポータル プロジェクトに変換するオプションは用意されていません。既存のプロジェクトにポータル J2EE 共有ライブラリを統合する方法については、『ポータル開発ガイド』を参照してください。 |
ポートレット ウィザードを起動すると、作業しているプロジェクトのタイプに基づいて有効なポートレット タイプが決定され、[ポートレット タイプの選択] ダイアログに表示されます。
たとえば、WSRP プロデューサ機能 (および必要な付属機能) のみがインストールされたポータル Web プロジェクトで作業している場合は、ポータル ライブラリのフルセットがダイアログに含まれるわけではありません。この場合は、JPF、JSF、ブラウザ、および Struts ポートレット タイプのみが有効な選択項目となり、他のポートレット タイプは [ポートレット タイプの選択] ダイアログに表示されません。
プロジェクト タイプに基づく有効なポートレット タイプが存在しない場合は、情報メッセージが表示されます。
図 5-8 に、[ポートレット タイプの選択] ダイアログの例を示します。
注意 : | Java Server Faces (JSF) ポートレットの選択項目は、ポータル ウェブ プロジェクトに JSF プロジェクト ファセットを追加した場合のみ表示されます。詳細については、「JSF ポートレット」を参照してください。 |
ポートレット タイプの選択後に表示される [ポートレットの詳細] ダイアログは、作成するポートレットのタイプに応じて異なります。[ポートレットの詳細] ダイアログの各データ入力フィールドの詳細については、「各ポートレット タイプの構築方法」に記載されているポートレット構築タスクを参照してください。
以下の節では、WebLogic Portal でサポートされている各ポートレット タイプの作成方法を説明しています。
JSP ポートレットは単純な JSP ファイルによく似ています。多くの場合、既存の JSP ファイルを使用してポートレットを構築できます。ポートレットが単純で、複雑なビジネス ロジックの実装を必要としない場合、JSP ポートレットをお勧めします。さらに、JSP ポートレットは、単一ページのポートレットに最適です。
「ポートレット ウィザードの起動」で説明するように、ポートレット ウィザードを起動する方法はいくつかあります。ここでは、既存の JSP ファイルをベースにポートレットを作成する場合を想定します。
JSP ポートレットを作成するには、以下の手順を実行します。
ポートレット ウィザードの [ポートレットの詳細] ダイアログが表示されます。図 5-9 に例を示します。
|
Workshop for WebLogic のウィンドウが更新され、表示ツリーに Portlet_Name.portlet ファイルが追加されます。デフォルトで、コンテンツ ファイルと同じディレクトリにポートレット ファイルが配置されます。
Java ポートレットは、ポートレット ポータビリティのルールを規定する JSR 168 仕様に基づきます。Java ポートレットは、各種ポートレット コンテナ間でのポータビリティを重視するソフトウェア会社などの企業に適しています。
WebLogic Portal は、JSR 168 仕様の規定を上回る機能を Java ポートレット用に備えています。たとえば、スレッディング オプションを設定したり、バッキング ファイルを使用したりすることができます。これらの機能を実装するために、WebLogic Portal では、他のポートレット タイプと同じ方法で作成する通常の .portlet
ファイルだけでなく、標準的な portlet.xml
ファイルと weblogic-portlet.xml
ファイルも使用されます。
Java ポートレットを作成するには、以下の手順を実行します。
ポートレット ウィザードに [ポートレット タイプの選択] ダイアログが表示されます。
[Java ポートレットの詳細] ダイアログが表示されます。図 5-10 に例を示します。
portlet.xml
ファイル内のエントリとして) 更新するかを指定します。
新規ポートレットを作成する場合、WebLogic Portal では、ウィザードで入力した情報を基に、以下の 2 つのタスクが実行されます。
入力した値に基づき、ウィザードによって .portlet
ファイルが作成され、/WEB-INF/portlet.xml
にエントリが追加されるか (すでに存在する場合)、または必要な場合は当該ファイルが作成されます。
Workshop for WebLogic に、新しく作成されたポートレットと最新のプロパティが表示されます。図 5-11 に、Java ポートレットの外観とプロパティの例を示します。
portlet.xml
ファイルの portlet-name
属性は、.portlet
ファイルの definitionLabel
プロパティに一致します。
ポートレット作成後、プロパティ ビューでプロパティを変更することも、エディタ内でポートレットをダブルクリックして生成された Java クラスを表示および編集することもできます。
注意 : | .portlet ファイルを削除すると、対応するエントリは portlet.xml ファイル内に残ります。portlet.xml ファイルは、定期的にクリーンアップしたほうがよい場合もあります。これらの余分なエントリは、ポータル実行時に問題を引き起こすことはありませんが、ログ ファイルにエラー メッセージが生成されます。 |
Java ポートレットには、portlet.xml
という個別のデプロイメント記述子ファイルが WEB-INF
ディレクトリに用意されています。さらに、weblogic-portlet.xml
というファイルもあります。このファイルは、機能を追加するために使用できる BEA 固有のオプションのファイルです。
コード リスト 5-1 に、portlet.xml
ファイルのエントリの例を示します。
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app version="1.0"
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<portlet>
<description>Description goes here</description>
<portlet-name>helloWorld</portlet-name>
<portlet-class>aJavaPortlet.HelloWorld</portlet-class>
<portlet-info><title>Hello World!</title></portlet-info>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info><title>new Java Portlet</title></portlet-info>
</portlet>
</portlet-app>
WebLogic Portal では、JSR 168 仕様に準拠し、各種オペレーティング システムで広く使用できる Java ポートレットが生成されます。Workshop for WebLogic では、Java ポートレットを、サポート対象サーバにデプロイ可能のサポートされているアーカイブ ファイル (WAR、JAR または ZIP) にエクスポートできます。 さらに、インポート機能を使用して、Java ポートレットを含むアーカイブ ファイルを Workshop for WebLogic ワークスペースにインポートできます。詳細については、「Java ポートレットのインポートおよびエクスポート」を参照してください。
WebLogic Portal では、標準の JSR 168 仕様を上回る機能を Java ポートレットで実現できます。オプションの weblogic-portlet.xml
ファイルを使用すると、機能を追加することができます。以下の節で例を示します。
フロート可能な Java ポートレットを作成するには、以下のサンプル コードに示すように、weblogic-portlet.xml
でカスタム状態を宣言します。
<portlet-name>fooPortlet</portlet-name>
<mime-type>text/html</mime-type>
Java ポートレットにアイコンを追加するには、以下の説明に従って weblogic-portlet.xml
ファイルを編集する必要があります。
weblogic-portlet.xml
ファイルを探し、ダブルクリックして開きます。このファイルは、たとえば以下のようにポータルの WEB-INF フォルダにあります。
myPortal/WEB-INF/weblogic-portlet.xml
weblogic-portlet.xml
ファイルに以下の行を追加します。 <portlet>
<portlet-name>myPortlet</portlet-name>
<supports>
<mime-type>text/html</mime-type>
<titlebar-presentation>
<icon-url>myIcon.gif</icon-url>
</titlebar-presentation>
</supports>
</portlet>
init-param 要素には、ポートレットの初期化パラメータとして、名前および値のペアが含まれています。javax.portlet.PortletConfig インタフェースの getInitParameterNames および getInitParameter メソッドを使用して、ポートレット コード内のこれらの初期化パラメータ名および値を返させることができます。Init-params は JSR168 仕様で記述されています。
New Init-Param アイコンをパレットからポートレット エディタ内の Java ポートレットにドラッグすることにより、Java ポートレットに init-params を追加できます。その後、プロパティ ビューにパラメータのプロパティを表示するには、ポートレットの init-param セクションをクリックします。プロパティ ビューでは、以下の init-param データを入力できます。
たとえば、「Color」 という名前の init-param を作成してデフォルト値を 「green」 に設定すると、次のエントリが portlet.xml
ファイルに作成されます。
<init-param>
<description>My init param</description>
<name>Color</name>
<value>green</value>
</init-param>
ポートレット ウィザードでは、Apache Beehive ページ フローを使用してコンテンツを取得するポートレットを構築できます。
ヒント : | ページ フローの作成の詳細については、e-docs の Workshop for WebLogic Platform のドキュメントを参照してください。 |
ページ フロー ポートレットを作成するには、以下の手順を実行します。
ポートレット ウィザードに [ポートレット タイプの選択] ダイアログが表示されます。
ポートレット ウィザードの [ポートレットの詳細] ダイアログが表示されます。図 5-12 に例を示します。
|
Workshop for WebLogic のウィンドウが更新され、表示ツリーに Portlet_Name.portlet ファイルが追加されます。デフォルトで、コンテンツ ファイルと同じディレクトリにポートレット ファイルが配置されます。
ページ フロー ポートレットの作成プロセスを十分に理解するには、ページ フローの概念に精通していることが必要です。WebLogic Portal でのページ フローの使用の詳細については、『ポータル開発ガイド』を参照してください。
Web サービスを呼び出すページ フロー ポートレットを作成する場合は、「Web サービス ポートレット」を参照してください。
JSF ファセットがインストールされている (つまり、ポータル Web プロジェクトを作成したときに JSF ファセットを選択した) WSRP プロデューサまたはフレームワーク Web アプリケーション用に JSF ポートレットを作成できます。
注意 : | Java Server Faces (JSF) ポートレットの選択項目は、ポータル ウェブ プロジェクトに JSF プロジェクト ファセットを追加した場合のみポートレット ウィザードに表示されます。JSF プロジェクト ファセットを追加するには、パッケージ エクスプローラのポータル Web プロジェクトを右クリックします。プロパティ ダイアログで、左側のツリーから [Project Facets] を選択します。[Add/Remove Project Facets] をクリックし、[Project Facets] ダイアログ内で [JSF] を選択して、[終了] をクリックします。 |
JSF ポートレットを作成するには、以下の手順を実行します。
[新しいポートレット] ダイアログが表示されます。図 5-15 に [新しいポートレット] ダイアログの例を示します。
デフォルトで、ポートレットを追加するために選択した場所が親フォルダになります。
[終了] ボタンは最初は無効になっています。このボタンは、有効な親フォルダとポートレット名を選択した場合に有効になります。このダイアログのフォルダ ツリーで無効なポータル プロジェクトを選択すると、ダイアログの最上部近くのステータス領域に、当該プロジェクトが有効なポータル プロジェクトではないことを示すエラー メッセージが表示されます。
ポートレット ウィザードに [ポートレット タイプの選択] ダイアログが表示されます。
ポートレット ウィザードの [ポートレットの詳細] ダイアログが表示されます。図 5-14 に例を示します。
|
|||
|
Workshop for WebLogic のウィンドウが更新され、表示ツリーに Portlet_Name.portlet ファイルが追加されます。
注意 : | ポータル ページで複数の JSF ポートレットを使用する場合は、JSF 表示タグのすぐ後で namingContainer JSP タグを使用して、生成されるコンポーネント ツリーでのコンポーネントの命名を可能にします。このタグの詳細については、『ポータル開発ガイド』か、パッケージ com.bea.portlet.adapter.faces の Javadoc を参照してください。 |
ブラウザ ポートレット (コンテンツ URI ポートレットとも呼ばれます) は、基本的には、URL を使ってコンテンツを取得する HTML ポートレットです。ポータル プロジェクト内に含まれるデータの表示だけに限定されている他のポートレットのタイプとは違って、ブラウザ ポートレットは、ポータル プロジェクトの範囲外にある URL コンテンツを表示することができます。
「ポートレット ウィザードの起動」で説明するように、ポートレット ウィザードを起動する方法はいくつかあります。ここでは、[パッケージ・エクスプローラー] ビュー ツリーのポータル プロジェクト内を右クリックして、メニューから [新規|ポートレット] を選択した場合を想定します。
ブラウザ ポートレットを作成するには、以下の手順を実行します。
[新しいポートレット] ダイアログが表示されます。図 5-15 に [新しいポートレット] ダイアログの例を示します。
デフォルトで、ポートレットを追加するために選択した場所が親フォルダになります。
[終了] ボタンは最初は無効になっています。このボタンは、有効な親フォルダとポートレット名を選択した場合に有効になります。このダイアログのフォルダ ツリーで無効なポータル プロジェクトを選択すると、ダイアログの最上部近くのステータス領域に、当該プロジェクトが有効なポータル プロジェクトではないことを示すエラー メッセージが表示されます。
ポートレット ウィザードに [ポートレット タイプの選択] ダイアログが表示されます。
ポートレット ウィザードの [ポートレットの詳細] ダイアログが表示されます。図 5-16 に例を示します。
|
Workshop for WebLogic のウィンドウが更新され、表示ツリーに Portlet_Name.portlet ファイルが追加されます。デフォルトで、コンテンツ ファイルと同じディレクトリにポートレット ファイルが配置されます。
注意 : | ブラウザ ポートレットの内部実装は、ポートレット コンテンツの非同期表示により異なります。このため、プロパティ ビューに表示されるポートレット属性 [非同期コンテンツ表示] は [none ] に設定され、読み込み専用です。コンテンツの非同期表示の詳細については、「ポートレット コンテンツの非同期表示」を参照してください。 |
この節で説明されているように、ポートレット ウィザードを使用して、Struts モジュールに基づくポートレットを生成します。
Struts ポートレットを作成するには、まず、既存の Struts アプリケーションをポータル Web アプリケーションに統合する必要があります。WebLogic Portal への Struts アプリケーションの統合の詳細については、『ポータル開発ガイド』を参照してください。
ヒント : | ポータル内でホストする前に、Struts アプリケーションを完全に開発してテストすることを推奨します。これにより、実用の Struts アプリケーションの開発に関連する複雑さと Struts アプリケーションをポートレットに組み込むことで生じる他の問題を区別できます。 |
Struts ポートレットを作成するには、以下の手順を実行します。
WEB-INF
ディレクトリにある、Struts アプリケーション モジュールの XML コンフィグレーション ファイルを右クリックします。
Workshop for WebLogic のウィンドウが更新され、表示ツリーに Portlet_Name.portlet
ファイルが追加されます。デフォルトでは、ウィザードの [Struts モジュール パス] ダイアログで指定したディレクトリにポートレット ファイルが配置されます。
リモート ポートレットの開発は、結合ポートレット環境での基本的なタスクであるため、リモート ポートレットの作成タスクの詳細については、『BEA WebLogic Portal の連合ポータル ガイド』を参照してください。
WSRP を使用すると、WebLogic ポータル内で以下のタイプのポートレットを表示できます。
Web サービス ポートレットは、特別なタイプのページ フロー ポートレットであり、Web サービスを呼び出すことができます。Web サービス ポートレットを作成するには、Workshop for WebLogic と WebLogic Portal の機能を使用します。
Web サービスを呼び出すポートレットを作成するには、まず以下の必須タスクを実行する必要があります。
これらのタスクの実行手順については、BEA Workshop for WebLogic のプログラマーズ ガイドを参照してください。
セットアップ タスクを実行した後、Web サービス ポートレットを以下の手順で作成できます。
WebLogic Portal では、ポップアップ形式で表示されるデタッチされたポートレットを使用できます。技術上、デタッチされたポートレットは、呼び出し側のポータル コンテキストの外にあるものとして定義されます。WebLogic Portal でサポートされているどのポートレット タイプも、デタッチされたポートレットとして表示できます。
デタッチされたポートレットを実装する場合は、次の点に注意してください。
デタッチされたポートレットの URL を作成するには、standalonePortletUrl
クラスか、関連する JSP タグを使用します。
JSP ページからデタッチされたポートレット URL を作成するには、render:standalonePortletUrl という JSP タグまたはクラスを使用します。以下の例にこの JSP タグの構文を示します。
<render:standalonePortletUrl portletUri="/
absolute_path/
detached_portlet_name.portlet" .../>
Java コードからデタッチされたポートレットの URL を作成するには、以下の例を参考にしてください。
StandalonePortletURL detachedURL = StandalonePortletURL.createStandalonePortletURL(request, response);
detachedURL.setPortletUri("/path/to/detached.portlet");
ファイルベースのポートレットは、スタンドアロンの .portlet
ファイルまたはインライン ポートレットのいずれかのかたちで存在可能です。通常、Workshop for WebLogic ポータル編集フレームワーク内では、.portlet
ファイルは参照によってポートレット内に取り込まれます。たとえば、.portlet
ファイルをポータル、ページ、ブックのいずれかにドラッグした場合、ポータル、ページ、またはブック内の portlet ファイルに参照が作成されます。一方、インライン ポートレットでは、 XML 定義全体がページまたはブックに内に直接埋め込まれます。
.book
または .page
ファイル内にインライン化されます。リモート ブックおよびページの作成の詳細については、『連合ポータル ガイド』を参照してください。 .book
または .page
ファイルを抽出する場合、それらが元々インライン化されていた場合は、それらのポートレットはインライン化されます。元のページがポートレットを参照のかたちで含む場合、ページの抽出時にもそれらのポートレットは参照されます。エクスポート/インポート ユーティリティの詳細については、『プロダクション業務ユーザーズ ガイド』を参照してください。
ポータル エディタからまたはポータル エディタ内で、1つのページまたはブックから別のページまたはブックへ、インライン ポートレットのドラッグ アンド ドロップ、切り取り、コピー、貼り付けを行うことができます。
図 5-19 は、インライン ポートレットおよび参照されたポートレットを含むリモート ページを示しています。インライン ポートレットで使用されているアイコンが参照されているポートレットとは異なることに注意してください。
ヒント : | インライン ポートレットのプロパティは、ファイルベースのポートレットとまったく同様に編集できます。ただし、インライン ポートレットの場合、ポートレットの状態およびモードは編集できません。 |
インライン ポートレットを .portlet
ファイルにエクスポートできます。インライン ポートレットをファイルにエクスポートしても、結果として得られる .portlet
ファイルは機能上、他の .portlet
ファイルと同等です。インライン ポートレットを抽出する場合、そのインライン ポートレット XML コードは自動的にソース ファイル (ページまたはブック) から削除され、新しく作成された .portlet
ファイルへの参照に置換されます。
注意 : | インライン ポートレットを抽出した後、操作を元に戻すことができます (ポートレットの再インライン化)。ただし、抽出時に作成された .portlet ファイルはシステムから削除されないことに注意してください。単に、ソース ドキュメントがその .portlet ファイルを参照しなくなるだけです。 |
インライン ポートレットを抽出するには、次の手順に従います。
ヒント : | ポートレットを抽出した後にエラーが表示された場合、必ずソース ファイルを保存してから [プロジェクト|クリーン] コマンドを実行するようにします。 |
参照されたポートレットと同様に、インライン ポートレットにもテーマを設定できます。テーマを設定するには、ブックまたはページ エディタ内でインライン ポートレットを右クリックし、[テーマ] メニューからテーマを選択します。テーマは、ページまたはブック内で参照され続けるかぎり、そのポートレットに対し保持されます。
ポータルのブックまたはページを .book
または .page
ファイルに抽出できます。ブックまたはページを抽出後、必要に応じて、同じポータル ウェブ アプリケーション内の別のポータルでそれを使用できます。
ブックおよびページの抽出手順は、「インライン ポートレットの抽出」に記載されているインライン ポートレットの抽出手順と同様です。ブックまたはページを抽出するには、次の手順に従います。
ヒント : | ブックまたはページに適用されたテーマは、そのページまたはブックがポータル内で参照され続けるかぎり、抽出されたブックまたはページに対し保持されます。 |
ポートレットのプロパティは、ポートレットをユニークに識別し、ポートレットの特性を定義する名前付きのポートレットの属性です。タイトル、定義ラベル、コンテンツ URI などの一部のプロパティは必須です。省略可能なプロパティは数多く存在し、それらの省略可能プロパティを使用すると、スクロール、プレゼンテーション プロパティ、(認可などを目的とした) 前処理、マルチスレッド表示などの特定の機能をポートレットで有効にすることができます。ポートレットに使用するプロパティは、そのポートレットの使い方に応じて異なります。
ポータル ライフサイクルの開発段階では、一般に Workshop for WebLogic インタフェースを使用してポートレット プロパティを編集します。この節では、Workshop for WebLogic で編集できるプロパティについて説明します。
ステージング段階とプロダクション段階では、通常 WebLogic Portal Administration Console を使用してポートレット プロパティを編集します。この時点で編集できるプロパティは、一部のプロパティに限られます。WebLogic Portal Administration Console によるポートレット プロパティの編集手順については、「ライブラリ ポートレットのプロパティの変更」と「デスクトップ ポートレットのプロパティの変更」を参照してください。
すべてのポートレット プロパティの詳細については、「ポータルのプロパティ ビューのポートレット プロパティ」と「ポートレットのプロパティ ビューのポートレット プロパティ」を参照してください。
ポートレット プロパティを編集するには、以下の手順を実行します。
.portlet
ファイルをダブルクリックしてワークベンチ エディタで開きます。
表示されるプロパティは、選択したアクティブ領域に応じて異なります。たとえば、外側の境界線をクリックするとポートレット全体のプロパティが表示され、内側の境界線をクリックするとポートレットのコンテンツのプロパティが表示されます。
プロパティ フィールドをクリックすると、ステータス バーにそのフィールドの説明が表示されます。
一部のポートレット プロパティは、ポートレットを作成した後は値を編集できなくなります。
プロパティ フィールドによっては、そのポートレット プロパティに関連する情報を表示できる場合があります。たとえば、Java ポートレットの [クラス名] プロパティには読み込み専用の値が格納され、[開く] ボタンを使用すると関連する Java ファイルが表示されます。プロパティ ビューで使用できるオプションの詳細については、「プロパティ ビューを使用する場合のヒント」を参照してください。
プロパティ ビューの動作は、編集するフィールドの種類に応じて異なります。次に説明するヒントは、プロパティ ビューのデータ フィールドの内容を操作するときに役立つ場合があります。
.portlet
ファイルを右クリックし、[アプリケーションから開く|XML エディター] を選択すると、Eclipse に用意されている基本的な XML エディタを使用してそのファイルを開くことができる。 注意 : | Eclipse の XML エディタは、検証機能が限定されています。手作業で編集した XML の有効性を確実にするために、強力な検証ツールの使用をお勧めします。 |
.portlet
ファイルに格納されます。プロパティ エディタによって、指定したページ フロー URI が検証され、対応するページ フロー クラスのない URI を選択した場合は警告が表示されます。警告が表示された場合でも、処理を続行して無効な URI を格納できます。ポートレットが正常に動作するように、後で有効なクラスを作成する必要があります。
この節で説明するプロパティは、.portal
ファイルに含まれ、Workshop for WebLogic ワークベンチで編集できます。ここに入力する値は、.portal
ファイルの対応する値をオーバーライドします (値が存在する場合)。
ポータルのプロパティ ビューに表示されるポートレット プロパティを表示するには、以下の手順を実行します。
注意 : | 以下の手順は、ポートレットを含むポータルがあることを前提としています。 |
プロパティ ビューはポートレット インスタンスのプロパティを表示します。図 5-22 に例を示します。
表 5-6 でこれらのプロパティと値について説明します。
.portlet ファイルで表される単一のポートレットは、ポータル内で複数回使用できる。そのポートレットの毎回の使用が、ポートレット インスタンスであり、各ポートレット インスタンスには、ユニークな ID またはインスタンス ラベルが必要である。デフォルト値が自動的に入力されますが、その値を変更できます。インスタンス ラベルを使用することで、WebLogic Portal は、ポートレットの複数のインスタンスの実行時状態をサーバ上でそれぞれ独立して管理することができる。また、WebLogic Portal は、URL の書き換えや、フォーム名、ID 属性などの各種 HTML コントロールのスコープ設定でもインスタンス ラベルを使用する。
|
|
この節で説明するプロパティは、.portlet
ファイルに含まれ、Workshop for WebLogic ワークベンチで編集できます。ここに入力する値は、.portlet
ファイルの対応する値をオーバーライドします (値が存在する場合)。
エディタでポートレット インスタンスの外側の境界線を選択すると、関連するプロパティ セットがプロパティ ビューに表示されます。表示されるプロパティは、表示中のポートレット タイプによって異なります。図 5-23 にポートレットのプロパティ ビューの一部を示します。
表 5-7 でこれらのプロパティと値について説明します。
none 、ajax 、または iframe を選択します。asyncContent 属性のないポートレット ファイルが表示されるときには、初期値として [none ] が表示される。
|
|||
\WEB-INF\client-classifications.xml から取得される。クライアントをポータル Web プロジェクトの分類に対応付けるには、このファイルを作成する必要がある。このタスクの詳細については、『ポータル開発ガイド』を参照。
|
|||
|
|||
true 」に設定すると、ポータル管理者は [フォーク表示] プロパティを使用して、ポートレットをマルチスレッド表示できる。デフォルトは、false です。
|
|||
true 」に設定してポートレットをキャッシュする。たとえば、Web サービスを呼び出すポートレットは、コストのかかるプロセスを頻繁に実行する。Web サービス ポートレットをキャッシュすると、パフォーマンスが向上する。
|
|||
none 、session 、transient-session である。この属性では、ページ フロー、JSF、および Struts の各ポートレットの属性の永続性を設定する。デフォルト値は session 。この場合、アクションによって設定されたリクエスト属性はコレクション クラスに永続化され、このクラスがセッション属性に格納される。これにより、ポータル フレームワークは、アクションを再実行しなくても後続のリクエストで転送 JSP を安全に取り込むことができる。session 値を使用すると、スタンドアロンのページ フロー、JSF、または Struts アプリケーションでは起こらないセッション メモリの消費とレプリケーションにつながる。transient-session 値は、Hashmap の近くのシリアライズ可能なラッパー クラスをセッションに格納する。値 none は、永続化処理を実行しない。
transient-session 値が適用されている Java ページ フローまたは Struts ポートレットは、通常、既存のポートレットと同じように機能する。ただし、フェイルオーバの場合は例外である。永続化されたリクエスト属性は、サーバへのフェイルオーバが発生すると消失する。フェイルオーバの場合、転送 JSP を作成してこのような不測の事態を適切に処理する必要がある。そのためには、少なくとも、特定のリクエスト属性が設定されていることを前提とせず、自動的にリクエスト属性を再設定する機能を用意するか、最後のアクションを再実行してリクエスト属性を再設定するためのリンクをユーザに表示するのが理想的である。フェイルオーバがない場合、リクエスト属性は永続化され、非ポストバック ポートレットに対してデフォルトの session 永続性ポートレットに匹敵するパフォーマンスが実現される。
|
|||
myfaces/foo.face などの JSF ビュー ID への参照である。イベント ハンドラの追加の詳細については、「ポートレット イベント」を参照。
|
|||
|
|||
true は、ポートレットへのアクセスを許可する。リモート ポートレットの資格付与の詳細については、『連合ポータル ガイド』を参照。
|
|||
true 」に設定すると、ポートレットを別のウィンドウに移動できる。フロート可能な Java ポートレットの作成では、weblogic-portlet.xml ファイルの編集が必要となる。フロート可能な Java ポートレットの作成手順については、「weblogic-portlet.xml による Java ポートレットのカスタマイズ」を参照。
|
|||
lafDependenciesUri 値がある場合、プロデューサはポートレットの記述の invokeRenderDependencies boolean を公開する。この属性の詳細については、「ポートレットの依存関係」を参照。
|
|||
true になる。サードパーティ プロデューサの場合、GetServiceDescription からの応答により、true と false のどちらにもなりうる。false の場合、getMarkup リクエストおよび performBlockingInteraction リクエストのたびにユーザ コンテキスト全体が送信される。true の場合、送信はプロデューサ セッションにつき 1 回に限定される。
|
|||
|
ポートレット プリファレンスは、ポートレットにアプリケーション データを関連付ける主な手段です。この機能は、用途に基づいてポートレットをパーソナライズするうえで鍵となります。この節では、ポートレット プリファレンスについて詳しく説明します。
作成したポートレットは、何度もインスタンス化することができます。ポートレットのインスタンスを複数作成することができるため、当然ですが、各インスタンスで異なる動作を行いながらも、同じコードとユーザ インタフェースを使用したいと思うものです。たとえば、株価を表示する一般的なポートレットを考えてみましょう。このポートレットは、株式銘柄リストが指定されると、株価情報 Web サービスから定期的に株価を取得し、ポートレット ウィンドウに株価を表示します。各ユーザが株式銘柄リストと株価データの再ロード間隔を変更できるようにすることにより、各ユーザにこのポートレットをカスタマイズさせることができます。
このポートレットは、株式銘柄リストと取得間隔を永続的に格納できることと、ユーザがこれらの値をカスタマイズするときにこれらの値を更新できることが必要です。特に、以下のデータを永続的に管理する必要があります。
ポートレット プリファレンスは、技術上、名前付きの文字列データです。たとえば、株価情報ポートレットでは、以下のポートレット プリファレンスを設定できます。
こうした複数のプリファレンスを 1 つのポートレットに関連付けることができます。WebLogic Portal には、ポートレット プリファレンスを管理するために以下の手段が用意されています。
Workshop for WebLogic ワークベンチでポートレットを構築するとき、各ポートレットのプリファレンスの名前とデフォルト値を指定できます。このポートレットから作成される各ポートレット インスタンスでは、デフォルトで、開発時に指定された値が使用されます。
WebLogic Portal では、ポータルの管理者が特定のポートレット インスタンスのプリファレンスを変更できます。このタスクは、ステージング段階で行い、WebLogic Portal Administration Console を使用します。
リクエスト時に、ポートレットのプログラムで javax.portlet.PortletPreferences
オブジェクトを操作することにより、プリファレンスにアクセスし、値を変更することができます。ポートレットの編集ページを作成してユーザにプリファレンスを更新させることも、通常のポートレット アプリケーション フローの一部として自動的にプリファレンスを更新することもできます。
プリファレンスをポートレットに関連付ける手順は、構築するポートレット タイプにより異なります。「プリファレンス API を使用した Java ポートレットのプリファレンスの取得と設定」で説明する Java ポートレット API を使用する場合、手順は Java ポートレット仕様で指定された手順に基づきます。Java ページ フロー、Struts、JSP などの他のポートレット タイプの場合は、Workshop for WebLogic ワークベンチを使用してポートレットにプリファレンスを追加します。
管理者に Administration Console で新しいプリファレンスを作成させることもできます。ただし、ポートレットの開発者のほうが、ポートレットによるポートレット プリファレンスの使用に敏感であるため、一般に開発段階でポートレット プリファレンスを作成するほうがよいと考えられます。
Java ポートレット API を使用するポートレットでは、仕様に従ってポートレット デプロイメント記述子にプリファレンスを指定できます。Web プロジェクトのすべてのポートレットに対応するデプロイメント記述子は、Web プロジェクトの WEB-INF
ディレクトリにある portlet.xml
です。コード リスト 5-2 に例を示します。
<portlet>
<description>This portlet displays a stock portfolio.</description>
<portlet-name>portfolioPortlet</portlet-name>
<portlet-class>portlets.stock.PortfolioPortlet </portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>edit</portlet-mode>
</supports>
<portlet-info>
<title>My Portfolio</title>
</portlet-info>
<portlet-preferences>
<preference>
<name>stockSymbols</name>
<value>BEAS, MSFT</value>
</preference>
<preference>
<name>refreshInterval</name>
<value>600</value>
</preference>
</portlet-preferences>
</portlet>
この断片は、2 つのプリファレンスを持つ株価情報ポートレットをデプロイします。名前が「stockSymbols」で値が「BEAS, MSFT」のプリファレンスと、名前が「refreshInterval」で値が「600」のプリファレンスです。
コード リスト 5-3 の太字の値要素に示すように、stockSymbols プリファレンスに単一の値を指定する代わりに、各銘柄を別々の値として宣言することができます。
<portlet>
<description>
This portlet displays a stock portfolio.
</description>
<portlet-name>portfolioPortlet</portlet-name>
<portlet-class>portlets.stock.PortfolioPortlet </portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>edit</portlet-mode>
</supports>
<portlet-info>
<title>My Portfolio</title>
</portlet-info>
<portlet-preferences>
<preference>
<name>stockSymbols</name>
<value>BEAS</value>
<value>MSFT</value>
</preference>
<preference>
<name>refreshInterval</name>
<value>600</value>
</preference>
/portlet-preferences>
</portlet>
ポートレットで特定のプリファレンスがプログラムによって更新されないようにする場合は、プリファレンスに読み込み専用のマークを付けることができます。コード リスト 5-4 に、refreshInterval の変更を防ぐポートレットの例を示します。
<portlet>
<description>
This portlet displays a stock portfolio.
</description>
<portlet-name>portfolioPortlet
<portlet-class>portlets.stock.PortfolioPortlet
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>edit</portlet-mode>
</supports>
<portlet-info>
<title>My Portfolio</title>
</portlet-info>
<portlet-preferences>
<preference>
<name>stockSymbols</name>
<value>BEAS</value>
<value>MSFT</value>
/preference>
<preference>
<name>refreshInterval</name>
<value>600</value>
<read-only>true</read-only>
</preference>
</portlet-preferences>
</portlet>
プリファレンスに読み込み専用のマークを付けると、リクエスト時のみ現在の値の変更を防ぐことができます。ポータル管理者は、Administration Console を使用してプリファレンスの値を常に変更できます。
Java ページ フロー、Struts、単純な JSP などの他のポートレット タイプを構築する場合は、Workshop for WebLogic を使用してプリファレンスを追加できます。
表 5-8 では、プロパティ ビューに表示されるポートレット プリファレンスの属性について説明します。
リクエスト時に特定のポートレットのポートレット プリファレンスが javax.portlet.PortletPreferences
インタフェースのインスタンスとして表示されます。このインタフェースは、Java ポートレット API の一部です。このインタフェースは、ポートレット プリファレンスのアクセスと変更を行うメソッドを指定します。
表 5-9 で、ポートレットからプリファレンスにアクセスするためのメソッドについて説明します。
String getValue(String name, String default) |
|
String[] getValues(String name, String[] defaults) |
|
boolean isReadOnly(String name) |
|
Enumeration getNames() |
|
Map getMap() |
表 5-10 で、ポートレットからプリファレンスの値を変更するためのメソッドについて説明します。
void setValue(String name, String value) |
|
void setValues(String name, String[] values) |
|
void store() |
|
void reset(String name) |
setValue()、setValues()、および reset() メソッドを呼び出してプリファレンスを変更した後は、変更内容を永続化するために store() を明示的に呼び出す必要があります。そうしない場合、変更内容は永続化されません。
Java ポートレット API を使用して作成するポートレットでは、受信したポートレット リクエスト、つまり processAction()
メソッド内の javax.portlet.RenderRequest
、または render()
メソッド内の javax.portlet.ActionRequest
オブジェクトから javax.portlet.PortletPreferences
のインスタンスを取得できます。
コード リスト 5-5 のポートレットは、JSP ページのポートレット プリファレンスの現在値を編集するフォームを表示します。この値は、株価情報ポートレットの doEdit()
メソッドから取り込まれます。
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
<%@ page import="javax.portlet.PortletPreferences" %>
<portlet:defineObjects/>
<%
PortletPreferences prefs = renderRequest.getPreferences();
String refreshInterval = prefs.getValue("refreshInterval", "600");
String symbols = prefs.getValue("stockSymbols", "BEAS, MSFT");
%>
<form method="POST" action="">
<table>
<tr>
<td>Symbols</td><td><input name="symbols" value="<%=symbols>"/></td>
</tr>
<tr>
<td>Refresh Interval</td><td><input name="refreshInterval"
value="<%=refreshInterval>"/></td>
</tr>
<tr>
<td></td>
<td><input type="submit" value="Submit"/></td>
</tr>
</table>
</form>
コード リスト 5-6 に示すように、このポートレットは processAction()
メソッドでプリファレンスを更新します。
public class PortfolioPortlet extends GenericPortlet
{
{
public void doEdit(RenderRequest renderRequest, RenderResponse
renderResponse)
throws IOException, PortletException
{
...
}
public void processAction(ActionRequest actionRequest, ActionResponse
actionResponse)
throws PortletException
{
String refreshInterval =
actionRequest.getParameter("refreshInterval");
String symbols = actionRequest.getParameter("stockSymbols");
PortletPreferences prefs = actionRequest.getPreferences();
prefs.setValue("refreshInterval", refreshInterval);
prefs.setValue("stockSymbols", symbols);
try
{
prefs.store();
}
catch(SecurityException se) {
// ユーザがプリファレンスを格納するための十分な特権がない場合にスローされる。
// ユーザがポータルにログインしていることを確認すること。
...
}
catch(catch(IOException ioe) {
// プリファレンスの格納でエラーが発生した場合
...
}
}}
processAction()
の実行中、このポートレットは javax.portlet.ActionRequest
オブジェクトを使用してプリファレンスを取得します。
他のポートレット タイプからも、ポートレット プリファレンスにアクセスし、更新することができます。主な相違は、ポートレットが javax.portlet.PortletPreferences
オブジェクトのインスタンスを取得するときの方法です。
com.bea.netuix.servlets.controls.portlet.PortletBackingContext
を使用してポートレット プリファレンスを取得できる。たとえば、ページ フロー アクションや、ポートレットに関連するバッキング ファイルの handlePostbackData()
メソッドからポートレット プリファレンスを取得できます。 com.bea.netuix.servlets.controls.portlet.PortletPresentationContext
を使用してポートレット プリファレンスを取得できる。たとえば、ページ フローに関連する JSP でポートレット プリファレンスを取得できます。
どちらのクラスにも、javax.servlet.HttpServletRequest
を引数として取得し、タイプ javax.portlet.PortletPreferences
のオブジェクトを返す getPortletPreferences() メソッドが用意されています。
WebLogic Portal には、ポートレット プリファレンスを設定するために JSP タグ ライブラリが用意されています。適用可能な JSP タグについて表 5-11 で説明します。
getPreference |
|
getPreferences |
|
forEachPreference |
|
ifModifible |
|
else |
これらのタグに関連付けられた Java クラスの詳細については、「Javadoc」を参照してください。
WebLogic Portal のフレームワークにはデフォルトの実装があり、組み込みのデータベース テーブル PF_PORTLET_PREFERENCE および PF_PORTLET_PREFERENCE_VALUE の中にあるポートレット プリファレンスを管理することができます。必要な場合、この実装を独自の実装に置き換えることができます。
ポートレット プリファレンス SPI を使用すると、ポータル アプリケーションは、フレームワークの管理対象データベース テーブル以外でポートレット プリファレンスを管理することができます。たとえば、プリファレンスを他のアプリケーション データと共に別のバックエンド システムまたは別のデータベース テーブル セットに格納できます。
ポータルを伝播するとき、プリファレンス SPI は伝播プロセスに関与します。伝播のためにデータをエクスポートするとき、プリファレンスを取得するために SPI が呼び出され、データをインポートするとき、プリファレンスを格納するために SPI が呼び出されます。
以下の節では、ポートレット プリファレンス SPI の使用方法について説明します。
SPI は、com.bea.portlet.prefs.IPreferenceAppStore
インタフェースを使用して指定します。このクラスの実装は、EJB の jar ファイルとしてデプロイする必要があります。
コード リスト 5-7 に例を示します。
public interface IPreferenceAppStore extends EJBObject
{
/**
* ポートレット エンティティのプリファレンスを指定の uniqueId と共に返す。
*
* 返される java.util.Map には、名前に基づいてキーが付けられた
* com.bea.netuix.application.prefs.Preference
* オブジェクトが格納される。</p>
*
* @param uniqueId unique ID
* @return preferences
*/
public Map getPreferences(PortletPreferencesId uniqueId) throws
RemoteException, PreferenceAppStoreException;
/**
* ベースとなる永続性ストアにプリファレンスを書き込む。
*
* このメソッドは、原子性を持つように実装する必要がある。つまり、
* 実装では、すべてのプリファレンス値が永続化されるか、まったく
* 永続化されないかのどちらかでなければならない。
*
* java.util.Map の引数には、名前に基づいてキーが付けられた
* com.bea.netuix.application.prefs.Preference
* オブジェクトが必要。
*
* @param uniqueId unique ID
* @param preferences preferences
*/
public void storePreferences(PortletPreferencesId uniqueId,
Map preferences) throws RemoteException, PreferenceAppStoreException;
/**
* 指定されたユニーク ID を持つすべてのプリファレンスを
* ベースとなる永続性ストアからクリアする。
*
* @param uniqueIds unique IDs
*/
public void removePreferences(PortletPreferencesId[] uniqueIds) throws
RemoteException, PreferenceAppStoreException;
}
フレームワークでデフォルト SPI の代わりに新しい SPI を使用するには、netuix.jar
内にある ejb-jar.xml
ファイルの PreferencePersistenceManager
という EJB を更新する必要があります。デプロイメント記述子 (ejb-jar.xml
) の指定に従って、値 BEA_netuix.DefaultStore
を SPI EJB の名前に変更します。また、値 com.bea.portlet.prefs.provider.DefaultStoreHome
は、SPI 実装のホーム インタフェースに変更します。
注意 : | ejb-jar.xml ファイルを編集するには、J2EE ライブラリ リソースをプロジェクトにコピーする必要があります。将来 WebLogic Portal 製品を更新するときに、これらのリソースに影響する製品の変更を手動で組み込まなければならない場合があります。 |
コード リスト 5-8 のコード セグメントに、SPI を使用するために変更が必要なデフォルト エントリを示します。
<session>
<ejb-name>PreferencePersistenceManager</ejb-name>
<home>com.bea.portlet.prefs.PreferencePersistenceManagerHome</home>
<remote>com.bea.portlet.prefs.PreferencePersistenceManager</remote>
<ejb-class>com.bea.portlet.prefs.PreferencePersistenceManagerImpl
</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<env-entry-name>prefs-spi-jndi-name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>BEA_netuix.DefaultStore</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>prefs-spi-home-class-name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.bea.portlet.prefs.provider.DefaultStoreHome
</env-entry-value>
</env-entry>
<!-- Snip -->
</session>
作成したプリファレンスを表示し、テストするには、Workshop for WebLogic のサーバで開くビューからではなく、WebLogic Portal Administration Console からデスクトップ ビューを使用する必要があります。
.portal
ファイルからアクセスされたポートレットは、プリファレンスを格納できません。.portal
ファイルを使用してプリファレンスを更新する場合、ポートレットで java.lang.UnsupportedOperationException
エラーが検出されます。
ユーザがプリファレンスを更新する前にユーザにログインさせる手段が必要です。ポートレット プリファレンスを更新しようとするユーザを最初に認証する必要があります。匿名ユーザがポートレットを更新しようとすると、java.lang.SecurityException
エラーが発生します。
ユーザが匿名かどうかに関係なく、また、ポートレットへのアクセスが .portal
ファイル経由かどうかに関係なく、ポートレットは常にポートレット プリファレンスを取得できます。
任意のアプリケーション データをポートレット プリファレンスとして格納したいと思うことがあります。たとえば、ユーザがサーバにドキュメントをアップロードし、格納することができるポートレットでは、それらのドキュメントをポートレット プリファレンスとして格納することが妥当と思われるかもしれません。しかし、これはお勧めできません。ポートレット プリファレンスの目的は、実装固有のポートレット インスタンス ID を意識することなくポートレット インスタンスの一部のプロパティを関連付けることにあります。これらのプロパティにより、ポートレットの動作をカスタマイズすることができます。ポートレット プリファレンスのベースとなる実装は、任意のアプリケーション データを格納するようには設計されていません。
このポートレットのニーズを満たすことができる代わりの実装の概要を以下の手順に示します。
この手順により、アプリケーション データのスコープは常にポートレット インスタンスに設定されます。
ポータル フレームワークは、内部で生成されたインスタンス ID を使用してインスタンス ID を管理します。ポートレットは、com.bea.netuix.servlets.controls.portlet.PortletPresentationContext
と com.bea.netuix.servlets.controls.portlet.PortletBackingContext
の getInstanceId()
メソッドを使用してインスタンス ID にアクセスします。
以下の理由から、ポートレット インスタンス ID を使用してデータベースにデータを直接格納することはできません。
コントロールのライフサイクル内のポートレットの動作を制御する最も一般的な方法は、ポートレット バッキング ファイルを使用することです。ポートレット バッキング ファイルは、init()、preRender() など、ポータル コントロールのライフサイクルの各段階に対応するメソッドを含むことができる Java クラスです。ポートレットのバッキング コンテキスト、つまり、ポートレット コンテキスト自身を抽象化したものを使用して、ポートレットの特性を問い合わせたり、変更したりすることができます。たとえば、init() ライフサイクル メソッドでは、要求パラメータが評価され、そのパラメータの値に応じて、ポートレットのバッキング コンテキストを使用してポートレットを表示するか非表示にするかを指定できます。バッキング コンテキストの詳細については、『ポータル開発ガイド』を参照してください。
バッキング ファイルは、Workshop for WebLogic を使用するか、または .portlet
ファイルにコードを直接入力することによって、ポータルに追加できます。
バッキング ファイルは、com.bea.netuix.servlets.controls.content.backing.JspBacking
インタフェースの実装、または com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking
インタフェース抽象クラスの拡張を行う単純な Java クラスです。インタフェースのメソッドは、コントロール ライフサイクル メソッド (「バッキング ファイルの実行方法」を参照) に類似しており、コントロール ライフサイクル メソッドの呼び出しと同時に呼び出されます。
以下のポータル コントロールがバッキング ファイルをサポートしています。
「ローカル ポートレット間通信」のポートレット間通信の例では、バッキング ファイルが使用されています。
すべてのバッキング ファイルは、JSP 呼び出しの前後に実行されます。ライフサイクルの中で、各バッキング ファイルでは以下のメソッドが呼び出されます。
図 5-26 にバッキング ファイルのライフサイクルを示します。
注意 : | 以下の処理手順では、ツリーの最適化が有効で、非アクティブ ページの項目が「最適化により除外」されていない場合にメソッドが呼び出されます。たとえば、ツリーの最適化が有効で、生成される部分的なコントロール ツリーに非アクティブ ページの項目が含まれていない場合、メソッドは呼び出されません。 |
ヒント : | AbstractJspBacking.isRequestTargeted(request) メソッドを使用して、特定のポートレットに対する要求かどうかを判別できます。 |
バッキング ファイルの新しいインスタンスは要求ごとに作成されるため、スレッドの安全性の問題を心配する必要はありません。新しい Java VM は、有効期限が短いオブジェクト用に特別に調整されているため、以前のようなパフォーマンスの問題は発生しません。さらに、JspContent
コントロールでサポートされる特殊なバッキング ファイルを使用すると、バッキング ファイルがスレッド セーフかどうかを指定できます。この値を true
に設定すると、バッキング ファイルのインスタンスが 1 つだけ作成され、すべての要求で共有されます。
<netuix: portlet backingfile =some_value>
部分としてバッキング ファイルを持つことと <netuix: jspContent backingfile=some_value>
部分としてバッキング ファイルを持つことには、スコープ設定上の相違があります。
たとえば、ポートレット自体にバッキング ファイルがある場合、ポートレットの表示を実際に停止することができます。バッキング ファイルが jspContent レベルの場合、コントロール ツリーのポートレット部分はすでに実行されています。この実装は、ポートレット内の JSP 専用のプロセスを実行するために使用します。
バッキング ファイルを作成する際は、以下のガイドラインに従う必要があります。
コード リスト 5-9 にバッキング ファイルのサンプルを示します。このサンプルでは、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);
}
}
バッキング ファイルをポートレットに追加するには、Workshop for WebLogic を使用するか、追加先のファイルにコードを直接入力します。Workshop for WebLogic を使用する場合、図 5-27 に示すように、プロパティ ビューの [ポートレット バッキング ファイル] フィールドにバッキング ファイルを指定するだけです。バッキング ディレクトリを指定し、ドット区切り文字に続けてバッキング ファイルの名前だけを指定します。バッキング ファイルの拡張子は含めないでください。たとえば次のように入力します。
backing.ListenCustomerName.java
この例では、ファイル拡張子を含めた場合、ファイル拡張子がファイル名と解釈されます。これは、ドット区切り文字によってファイル パスが指定されるためです。その結果、アプリケーションは、存在しない ListenCustomerName
という名前のディレクトリの、存在しない java
という名前のファイルを検索します。
バッキング ファイルを .portlet
ファイルにコード化して追加するには、コード リスト 5-10 に示すように、<netuix:jspContent>
要素の中で backingFile
パラメータを使用します。
<netuix:content>
<netuix:jspContent
backingFile="portletToPortlet.pageFlowSelectionDisplayOnly.menu.
contentUri="/portletToPortlet/pageFlowSelectionDisplayOnly/menu/
backing.MenuBacking"
menu.jsp"/>
</netuix:content>
デフォルトでは、色、レイアウト、テーマなど、ポートレットの外観の一部は、ポータル レベルで管理されます。一方、外観または表示特性およびポートレット固有の機能は、タイトルバーおよび関連する状態 (最小化、最大化、フロート、削除) の使用、さらにポートレット コンテンツに影響するモード (編集モード、ヘルプ モード、カスタム モード) などです。
ポートレット固有の表示機能とコンテンツ機能、およびポートレット固有のモードについて、その使用方法を以下の節で説明します。
表示される HTML ページでは、スクリプト ファイルやスタイル シート参照などの大部分のリソース タイプを配置する場所として、ドキュメントのヘッダが適しています。ポートレットによっては、ページ表示に必要なリソースを指定しなければならない場合があります。以前は、必要な要素をページ上に提供する方法として、スケルトンに要素を配置するという方法がありました。しかし、スケルトンとポートレットとの間で結合が行われるため、この方法はお勧めできません。また、ポートレット コンテンツに参照を直接配置する方法もありましたが、この方法も無効な HTML が作成されるおそれがあります。
結合 (WSRP) 環境では問題はさらに深刻でした。リモート ポートレットは複数の場所に取り込まれる可能性がありますが、たとえばこれらのポートレットのいずれかが外部ファイル内の CSS に依存している場合、そのポートレットにはそのことを示す方法がなかったためです。
最新の WebLogic Portal には、ポートレットの依存関係の機能を使用してこの要件を処理する明示的な方法が追加されています。
スキンとスケルトンのリソースに関連する依存関係の概念には、表示依存関係およびスクリプト依存関係という正式な名称が与えられています。これらの依存関係の一般的な例が CSS ファイルと JavaScript ファイルです。
スキンとスケルトンのどちらでも、こうした依存関係を指定できるようになり、依存関係を解決するための関連する検索パスも指定できるようになりました。さらに、冗長性解消メカニズムと、スキン、スケルトン、テーマのスキンおよびスケルトンに関連する依存関係のための信頼性の高い順序指定メカニズムも用意されています。これらの機能は、ポータルだけでなく、ポートレットでも使用できるようになったため、ポートレットでは標準に準拠した方法で必要な依存関係を指定できます。これらの依存関係は、表示されるページの <head> セクションで該当する要素を使用して指定します。信頼性の高い順序指定や冗長性解消など、ルック アンド フィールの依存関係フレームワークに伴う他のメリットも、ポートレット レベルで実現されています。
ポートレットの依存関係のコンフィグレーションは、標準のルック アンド フィールと同じメカニズムを持ち、標準のルック アンド フィール スキーマに準拠した XML コンフィグレーション ドキュメントを使用します。この XML ドキュメントは、.portlet
ファイルから、ポートレット要素の属性を使用して参照されます。
ルック アンド フィールの表示依存関係と同様に、ポートレットの表示依存関係はアプリケーションの検索パスを使用して解決できます。さらに、ポートレットの表示依存関係を解決するために、ポートレット自身の検索パスの前に、ルック アンド フィール スキンの検索パスまたは該当するテーマ スキンが使用されます。
ポートレットの依存関係コンフィグレーション ファイルは、Workshop for WebLogic のプロパティ ビューにある [LAF 依存関係パス] フィールドに値を入力して指定します。別の方法として、以下の例に示すように、.portlet
ファイルのポートレット要素に lafDependenciesUri
属性を追加する方法もあります。
<netuix:portlet definitionLabel="myPortlet" title="My Portlet" lafDependenciesUri="/portlets/example/myPortlet.dependencies">
慣例により、ポートレットの依存関係コンフィグレーション ファイルを設定するときには、以下のガイドラインに従う必要があります。
ここに示したガイドラインは必須ではありませんが、外れると予測しない動作につながる場合があります。詳細については、「考慮事項と制限事項」を参照してください。
ポートレットの依存関係コンフィグレーション ファイルは、標準のルック アンド フィール スキーマから標準的なタイプを使用します。コード リスト 5-11 に例を示します。
<?xml version="1.0" encoding="UTF-8"?>
<p:window
xmlns:p="http://www.bea.com/servers/portal/framework/laf/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.bea.com/servers/portal/framework/laf/1.0.0
laf-window-1_0_0.xsd ">
<p:render-dependencies>
<p:html>
<p:links>
<p:search-path>
<p:path-element>.</p:path-element>
</p:search-path>
<p:link rel="stylesheet" type="text/css" href="my.css"/>
</p:links>
</p:html>
</p:render-dependencies>
</p:window>
コード リスト 5-11 に示すコンフィグレーション ファイルを使用すると、表示されるページ出力に CSS ファイルが (HTML の <head> セクションのリンク要素として) 取り込まれます。まず、リンク要素のルック アンド フィール スキンまたはテーマ スキンの検索パスを基準として CSS ファイルが検索されます。CSS ファイルが見つからない場合、コンフィグレーション ファイルの検索パスが使用されます。相対検索パスは、コンフィグレーション ファイルのディレクトリを基準とします。
デフォルトの動作では、最初に、ルック アンド フィールまたはテーマで指定された検索パスで検索が行われます。この動作により、ルック アンド フィールまたはテーマはポートレット リソースにスキンを正しく適用できます。ただし、ルック アンド フィールまたはテーマのディレクトリにポートレット レベルのリソースを配置しないでください。デフォルトの動作を望まない状況が発生した場合は、render-dependencies
要素の use-skin-paths
属性に値 false
に指定してこの動作を無効にすることができます。
現時点の Workshop for WebLogic には、ポートレットの表示依存関係コンフィグレーション ファイルの編集機能は用意されていません。この目的には、組み込まれている Eclipse ベースの XML ファイル エディタを使用できます。
1 つの .dependencies
ファイルを複数のポートレット間で共有することはお勧めできません。WebLogic Portal ではこの使用方法を禁じているわけではありませんが、1 つのファイルを共有すると、後でファイルに対する更新内容を統合するときに混乱が生じるおそれがあります。
Workshop for WebLogic を使用して有効な依存関係ファイルを作成することができます。その後、Workshop の XML エディタを使ってファイルを完成できます。
laf-window-1_0_0.xsd
を選択します。[次へ] をクリックします。 .xml
から .dependencies
に変更します。
1 つのページにポートレットの複数のインスタンスを配置した場合、常に、JavaScript 変数と CSS スタイルのスコープ指定の問題が発生する可能性があります。たとえば、インライン JavaScript が含まれているポートレットの 2 つのインスタンスを 1 つのページに配置すると、一方の JavaScript 変数に対する変更が、もう一方のポートレットに影響を与える可能性があります。
JavaScript および CSS スタイルのスコープが、特定のポートレット インスタンスに指定されるようにするには、変数またはスタイルのクラス名の前に、トークン wlp_rewrite_
を追加します。ポートレットが表示されるときに、このトークンは、各ポートレット インスタンスにユニークなポートレット インスタンスのラベルによって置き換えられます。
たとえば、stockQuote
という名前の JavaScript 変数 (.dependencies
ファイルから参照されている .js
ファイルで定義されている) について、ポートレット インスタンス レベルのスコープ指定を確実にするには、以下のように、変数名の前に wlp_rewrite_
を追加する必要があります。
var wlp_rewrite_stockQuote
portlet_bg
という名前の CSS クラス名 (.dependencies
ファイルから参照されている .css
ファイルで定義されている) について、ポートレット インスタンス レベルのスコープ指定を確実にするには、クラス名の前に wlp_rewrite_
を追加する必要があります。次に例を示します。
.wlp_rewrite_portlet_bg { background_color:white; }
いずれの場合も、wlp_rewrite_ トークンは、ユニークな識別子である、ポートレットのインスタンス ラベルによって置き換えられます。
注意 : | この節で説明されているスコープ指定のメカニズムは、content-uri 依存関係ファイル属性によって参照されている、.css および .js ファイルでのみ機能します。src 属性または link タグでリンクされているファイルは書き換えられません。 |
ポータルによっては、同じ名前のリソースを含む複数のルック アンド フィールがある場合があります。たとえば、ルック アンド フィール ABC とルック アンド フィール XYZ の両方に logo.gif
という名前のグラフィックがある場合があります。ポータル開発者としては、ポータル管理者またはユーザがいずれのルック アンド フィールを選択するかは分かりません。ポータルのリソースへのパス名のハード コーディングを避けるために、wlp_rewrite?
および /wlp_rewrite
トークンを使用して、リソース名を囲むことができます。たとえば、以下の画像ソースはハード コーディングされています。
<IMG SRC="/framework/skins/classic/images/logo.gif">
特定のルック アンド フィール (/classic
など) へのリソース パスの関連付けを避けるために、以下のようにできます。
<IMG SRC="wlp_rewrite?logo.gif/wlp_rewrite">
このトークンを使用すると、WebLogic Portal は、現在指定されているルック アンド フィールに関連付けられているリソースを検索する場合と同じメカニズムを使用して、指定されたリソースを検索します。つまり、いずれのルック アンド フィールが選択されても、適切なグラフィックが取得されます (そのルック アンド フィールに、指定されたグラフィックが存在することを前提としています)。現在のルック アンド フィールのスコープでリソースが見つからない場合、指定されている元の値 ( logo.gif
など) がそのまま使用されます。
WebLogic Portal で作成したポートレットは、モードの使用をサポートしています。モードを使用すると、エンド ユーザのポートレット編集機能やポートレット ヘルプ表示機能を変更できます。モードが使用できることを示すには、ポートレットのタイトルバーにアイコン ボタンを追加します。
WebLogic Portal に事前に定義されているモードは以下のとおりです。
WebLogic Portal を使用してカスタム ポートレット モードを独自に作成することもできます。
選択したモードのボタンがポートレットのタイトルバーに表示されます。図 5-28 に、エディタに表示されたポートレット モードのデフォルト ボタンの例を示します。図 5-29 は、ポートレットが実行中のときに表示されるモード アイコンの外観です。
ポートレット ウィザードでポートレットを作成するとき、[ポートレットの詳細] ダイアログでモード設定と状態設定を指定できます。これらの設定は、ポートレットのプロパティ ビューで編集することもできます。以下の節では、これらのタスクを行うために使用できる方法について説明します。
タイトルバーに対してヘルプまたは編集モードの追加または削除を行うには、以下の手順を実行します。
サブメニューのチェックマークは、このポートレットで使用できるモードを示します。これらのモードは、ポートレット作成時に指定したものです。図 5-31 にサブメニューの例を示します。
モードのプロパティの詳細をプロパティ ビューに表示し、編集できます。たとえば、ポートレットのモード ページ (編集ページなど) を表示する前に前処理を実行する場合は、[ポートレット バッキング ファイル] プロパティを編集できます。
ポートレットのモード プロパティを表示するには、ポートレットの [ポートレット モード] 領域にある展開/縮小切り替えボタン をクリックします。プロパティ ビューに編集モードのプロパティとヘルプ モードのプロパティが表示されます。
モード プロパティの説明については、表 5-7 を参照してください。
カスタム モードは、ユーザが実装するポートレット モードです。ヘルプや編集モードと同様、カスタム モードはポートレットのタイトルバーに表示されているボタンでアクティブ化します。カスタム モードを実装するには、表示部 (通常は JSP) とバッキング ファイルを供給する必要があります。この節では、例を使って、ユーザがポートレットに [最大化] ボタンを追加または削除できるようにするための単純なカスタム モードの作成方法について説明します。カスタム モードの記述に当たっての基本的な原則を理解することで、必要に応じて、特定のタスクを実行するためのカスタム モードを作成できるようになります。
図 5-32 は、サンプル ポートレットとそのポートレットのカスタム モード ビューです。ポートレット内の左側にあるカスタム モード ボタンをクリックすると、ポートレットの表示の右側がカスタム モード ビューに変わります。この例では、カスタム モードによりポートレットの [最大化] ボタンを追加または削除する機能を提供します。
togglebutton.jsp
とされています。 <%@ page import="com.bea.portlet.PostbackURL"%>
<%
PostbackURL url = PostbackURL.createPostbackURL(request, response);
%>
<TABLE CELLSPACING="10" ID="toggleButtonsTable">
<TH>Using a Button and Backing File</TH>
<TR>
<TD>
Click <b>Toggle</b> Off to remove the Maximize button from the portlet.<br>
Click <b>Toggle On</b> to restore it.
</TD>
</TR>
<TR>
<TD>
<FORM method="post" name="Toggle" action="<%=url.toString()%>">
<INPUT ID="toggle_off" TYPE="SUBMIT" NAME="toggle_off" VALUE="Toggle Off">
<INPUT ID="do_nothing" TYPE="SUBMIT" NAME="do_nothing" VALUE="Toggle On">
</FORM>
</TD>
</TR>
</TABLE>
package modes;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.bea.netuix.servlets.controls.content.backing.JspBacking;
import com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext;
import com.bea.netuix.servlets.controls.window.WindowCapabilities;
import com.bea.p13n.util.debug.Debug;
public class MyMode implements JspBacking {
public void dispose() {
}
public boolean handlePostbackData(HttpServletRequest arg0,
HttpServletResponse arg1) {
return true;
}
public void init(HttpServletRequest arg0, HttpServletResponse arg1) {
}
public boolean preRender(HttpServletRequest request, HttpServletResponse response) {
PortletBackingContext pbc =
PortletBackingContext.getPortletBackingContext(request);
if (request.getParameter("toggle_off") != null)
{
try
{
pbc.setCapabilityVisible(WindowCapabilities.MAXIMIZED.getName(),
false);
}
catch (NullPointerException npe)
{
//
}
}
return true;
}
}
ヒント : | プロパティ ビューでは、カスタム モード ボタンの画像、ロールオーバ画像、ボタン テキスト、代替テキストなどのような、その他の多くのカスタム モード プロパティを設定できます。カスタム モードの各プロパティの詳細については、この節の最後にある 表 5-12 を参照してください。 |
表 5-12 は、カスタム モードの各プロパティを簡単に説明したものです。
ポートレットの状態により、エンド ユーザが使用できるポートレット表示機能が決まります。WebLogic Portal では、以下のポートレット状態がサポートされています。
ポートレット ウィザードでポートレットを作成するとき、[ポートレットの詳細] ダイアログで状態設定とモード設定を指定できます。これらの設定は、ポートレットのプロパティ ビューで編集することもできます。以下の節では、これらのタスクを行うために使用できる方法について説明します。
ポートレットに組み込む状態を選択するには、以下の手順を実行します。
ポートレットの最小化と最大化は、ポートレット ファイルとポートレットのバッキング ファイルのどちらでも行うことができます。実際のコードはどちらも同じです。(Java ページ フロー) ポートレットを最大化する例を示します。
PortletBackingContext context = PortletBackingContext.getPortletBackingContext(request);
context.setupStateChangeEvent(WindowCapabilities.MAXIMIZED.getName());
このコードを Java ページ フローの action
メソッドか、バッキング ファイルの handlePostbackData
メソッドに挿入できます。バッキング ファイルを使用する場合は、handlePostbackData メソッドを呼び出すために URL に _nfpb=true
を含める必要があります。
ポートレットでコンテンツの非同期表示が有効な場合、これらのメカニズムは機能しません。
ポートレットのタイトルバーで使用される状態およびモードのデフォルト アイコンは、wlp-lookandfeel-web-lib J2EE 共有ライブラリに格納されています。これらのデフォルト アイコンは、マージ済みプロジェクト ビューの framework/skins
の各サブディレクトリにあります。
WebLogic Portal で作成するポートレットには、高さとスクロールを指定できます。
ポートレットの高さと、ポートレットのコンテンツをスクロールするかどうかを指定できます。
ポートレットの高さとスクロールは、以下の CSS スタイル属性で指定します。
ポートレットをワークベンチ エディタで開き、これらの属性を設定できます。
注意 : | [プレゼンテーション スタイル] と [コンテンツ プレゼンテーション スタイル] の相違は、たとえば、スタイル指定が適用される場所の違い (ポートレットかコンテンツか) です。どちらを使用するかは、具体的なスタイル指定で実行する内容の詳細によります。 |
図 5-38 に、[コンテンツ プレゼンテーション スタイル] を使用して設定された高さプロパティの例を示します。
図 5-38 のエントリに基づく外観は、図 5-39 の例のようになります。
[プレゼンテーション スタイル] プロパティでなく、[プレゼンテーション クラス] プロパティを使用する場合、対応するスタイルのクラスを CSS ファイルに定義する必要があります。
たとえば、[コンテンツ プレゼンテーション クラス] フィールドで値 .portlet-scroll を使用する場合、以下のスタイル クラス定義が CSS ファイルに設定済みであることが必要です。
ポートレットの高さとスクロールを自動的に指定するには、標準のポートレット コンテンツの CSS クラスにルールを追加指定します。たとえば、以下のいずれかを実行できます。
ポータルのスキン、テーマ、スケルトンの詳細については、『ポータル開発ガイド』を参照してください。
ページ フローは、要求の中に情報を格納します。ポータル ページに複数のページ フロー ポートレットがある場合、各ページ フローが個別にその情報を格納し、取得するための方法を用意する必要があります。たとえば、あるページのリクエスト オブジェクトに変数 car_type とその値 x
があるとします。ページ フローは、実行中にこの値を取得し、何らかの方法で使用します。ここで、別のページ フロー ポートレットで car_type 値に z
が指定されていると仮定します。この場合、ページ全体で要求が 1 つしか存在しなければ、2 つのページ フロー ポートレットが互いに干渉する可能性があります。この問題を解消するために、WebLogic Portal は、基本的に、外部 (ポータル) の要求のコピーを作成し、スコープ指定された要求をポートレットごとに 1 つずつ作成します。これにより、各ページ フロー ポートレットは、その情報を格納するために独自のユニークな要求を持つことになります。
場合により、スコープ指定された要求の中でなく、外部要求に格納された情報を使用することもできます。
たとえば、Netui フォーム タグの中で通常の HTML タグを使用する場合は、以下のようになります。
<netui:form action="myAction">
<input type="check box" name="test"/>
<netui:button value="myAction"></netui:button>
</netui:form>
上記で使用されるタグでは、以下のような通常の getParameter
要求を使用するのが一般的です。
<%request.getParameter("test"
)%>
ただし、外部要求から HTML 入力値を取得するには、以下のコードを使用します。
<%@page import="org.apache.beehive.netui.pageflow.scoping.ScopedServletUtils"%>
<%
HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest
( request );
%>
test: <%=outerReq.getParameter("test")%>
WebLogic Portal には、JSP 内で使用できる JSP タグが用意されています。Workshop for WebLogic で JSP デザイン パレット ビューを使用すると、使用可能な JSP タグを表示して、それらを JSP のソース ビューにドラッグしたり、プロパティ ビューを使用してコードの要素を編集したりできます。
また、WebLogic Portal には、ビルド済みモジュールをポータルに簡単に追加できるようにするためのカスタム Java コントロールがあります。カスタム Java コントロールは、イベント管理、訪問者ツール、コミュニティ管理などに使用されます。たとえば、ほとんどのユーザ管理機能は、ページ フローの User Manager コントロールを使用して簡単に公開できます。
注意 : | デスクトップ、ブック、ページなどのポータル (netuix) フレームワーク コントロールの参照には、用語コントロールも使用されます。テキストでは、これらのコントロールはポータル フレームワーク コントロールとも呼ばれます。 |
Workshop for WebLogic で JSP を開くと、現在ロードされ、使用可能なすべての JSP タグを JSP デザイン パレット ([ウィンドウ|ビューの表示|JSP デザイン パレット]) に表示することができます。図 5-40 にその表示部分を示します。
タグを使用するには、タグをエディタにドラッグし、ソース ビューでコードを直接編集し、図 5-41 に示すようにプロパティ ビューでプロパティを設定します。
各 JSP タグに関連付けられた Java クラスについては、「Javadoc」を参照してください。
ページ フローの表示中に WebLogic Portal で使用可能なカスタム コントロールを表示するには、以下の手順を実行します。
.java
ファイル) を開くか、新しいページ フローを作成します。
Workshop for WebLogic によるページ フローの作成の詳細については、『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。
図 5-43 のような [コントロールの選択] ダイアログが表示されます。
WebLogic Portal のカスタム コントロールを追加した後で、コントロールのメソッドはすべてページ フローで使用可能になります。
WebLogic Portal に用意されているカスタム コントロールの詳細については、『ポータル開発ガイド』を参照してください。各コントロールの詳細については、「コントロールの Javadoc」を参照してください。
ポートレット状態の永続性を管理するには、デフォルトで WEB-INF ディレクトリに存在する netuix-config.xml
ファイルの persistence-enabled
属性を使用します。この属性を使用すると、状態が WebLogic Portal データベースに保存されます。この属性は、デフォルトで false
に設定されます。
<control-state-location>
<session persistence-enabled="true"/>
</control-state-location>
WebLogic Portal は PROPERTY_KEY テーブルにコントロール ツリーのエントリを以下の PROPERTY_SET_NAME 値と共に格納します。
ポータル ライフサイクルの開発段階では、Workshop for WebLogic ワークベンチを使用してポータルにポートレットを追加します。
注意 : | ページにポートレットを追加する前に、ページのレイアウトを設定する必要があります。プレースホルダでのポートレットの縦位置と横位置は、ページに選択されたレイアウトによって決まります。 |
.portal
ファイル) をダブルクリックします。 .portlet
ファイル) をポータル ページ上の目的の位置までドラッグします。
図 5-44 にこの手順の例を示します。
ポートレットを選択すると、プロパティ ビューを使用して目的のポートレット プロパティをカスタマイズできます。
ポートレット プロパティの詳細については、「ポートレット プロパティ」を参照してください。
ワークベンチ エディタ内のページにポートレットを追加すると、そのポートレットの参照が .portal
ファイルに追加されます。WebLogic Portal Administration Console で、この .portal
ファイルをデスクトップ作成のテンプレートとして使用できます。ポータル管理者がそのテンプレートに基づいてデスクトップを作成すると、ポートレットはポータル リソース ライブラリに追加され、このライブラリでストリーミング デスクトップのページにポートレットを追加することができます。ファイルベース ポータルとストリーミング ポータルの相違の概要については、『ポータル開発ガイド』を参照してください。
ポータル ライフサイクルのステージング段階では、WebLogic Portal Administration Console を使用してデスクトップ上のポートレットをコンフィグレーションします。ポートレットのインスタンスを作成して、単一のポートレット定義を 1 つまたは複数のポータル (デスクトップ) に関連付けることができます。これらの各ポートレット インスタンスに独自の「個性」を持たせ、各種のコンフィグレーション オプションの指定に従って動作させることができます。
WebLogic Portal Administration Console でポータル デスクトップにポートレットを追加する具体的な方法については、「ページのポートレットの管理」を参照してください。
ポータル Web プロジェクトからポートレットを削除せずにポータルからポートレットを削除するには、Workshop for WebLogic ワークベンチのエディタでポートレットを右クリックし、[削除] をクリックします。
ポータル Web プロジェクトからポートレットを削除するには、[パッケージ・エクスプローラー] ビューでポートレットを右クリックし、[削除] をクリックします。
Administration Console を使用してポートレット インスタンスをポータル デスクトップに構築した後でポートレットを削除する方法については、「ポートレットの削除」を参照してください。
開発段階では、GroupSpace コミュニティ、カスタム コミュニティ、またはポータル Web アプリケーションに他のリソースを追加できます。これらのリソースは、以下のタグ ライブラリに含まれています。
その他の情報については、『コミュニティ ガイド』を参照してください。
GroupSpace コミュニティ、カスタム コミュニティ、またはポータル Web アプリケーションに ActiveMenus
JSP タグ ライブラリを追加できます。
ActiveMenus JSP タグ ライブラリでは、マウスを特定のテキストの上に置いた時に表示されるポップアップ メニューを設定できます。activemenus-config.xml
ファイルは、各メニューのコンテンツを制御します。activemenus_taglib.jar
ファイルには、ActiveMenus タグ ライブラリが格納されます。
デフォルトでは、GroupSpace コミュニティで ActiveMenus が有効化されているため、ActiveMenus タグだけをコンフィグレーションする必要があります (ActiveMenus タグのコンフィグレーションを参照)。GroupSpace コミュニティの ActiveMenus タグのサンプルについては、図 5-45 を参照してください。
マウスを項目 (問題など) の上に移動し、表示される矢印の上に移動すると、ActiveMenu が表示されます。このアクティブ メニューとユーザの機能を関連付けることができます。この例では、項目の削除を含む機能を割り当てられた場合は、図 5-45 に示すように、[削除] 機能が表示されます。
ヒント : | GroupSpace コミュニティがある場合は、以下の手順を実行する必要はありません。 GroupSpace コミュニティではデフォルトで ActiveMenus が有効になっています。 |
カスタム コミュニティの ActiveMenus を有効化するには、以下の手順を実行します。
activemenus_taglib.jar
ファイルをポータル Web プロジェクトで使用できるようにします。ポータル Web プロジェクトを作成する場合は、[WebLogic Portal コラボレーション] チェック ボックスを選択して GroupSpace ファセットを有効にする必要があります。activemenus-config.xml
ファイルをポータル Web プロジェクトの /WEB-INF
ディレクトリに追加します。activemenus-config.xml
ファイルを右クリックして [プロジェクトにコピー] を選択し、ファイルを追加します。ActiveMenus タグのコンフィグレーションの説明に従ってファイルをコンフィグレーションし、activemenus-config.xml
ファイルを編集します。/WEB-INF
ディレクトリにある web.xml
ファイルに追加して、GetActiveMenusResourceServlet
を登録します。web.xml
ファイルをダブルクリックすると、Workshop for WebLogic でファイルを編集できます。ファイルの web-app 行を右クリックして、[子の追加|message-destination - welcome-file-list|servlet] を選択します。GetActiveMenusResourceServlet を servlet-name
行に追加します。com.bea.apps.groupspace.servlets.GetActiveMenusResourceServlet を servlet-class
行に追加します。編集したファイルを Workshop for WebLogic で表示するには、図 5-46 を参照してください。
コード リスト 5-1 のコード サンプルに、追加した新しい情報を示します。
<!-- ActiveMenus サーブレット マッピング -->
<servlet>
<servlet-name>GetActiveMenusResourceServlet</servlet-name>
<servlet-class>
com.bea.apps.groupspace.servlets.GetActiveMenusResourceServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>GetActiveMenusResourceServlet</servlet-name>
<url-pattern>GetActiveMenusResourceServlet</url-pattern>
</servlet-mapping>
ActiveMenus を有効化したら、ActiveMenus
タグをコンフィグレーションする必要があります。
ActiveMenus タグを使用するには、activemenus-config.xml
file
を設定する必要があります (このコンフィグ ファイルを定義する XSD
は activemenus-config.xsd
として activemenus_taglib.jar
ファイル内にあります)。この activemenus-config.xml
file
ファイルは、Web アプリケーションの /WEB-INF
ディレクトリに存在している必要があります。全く異なる項目、スタイル、アイコンなどで構成された複数のメニューを設定できます。
activemenus-config.xml
file
ファイルをコンフィグレーションするには、以下のセクションを参照してください。
コンフィグレーション ファイルをクリーンな状態に保つには、typeInclude
タグを使用します。type
タグ (Type タグの使用を参照) を追加する代わりに、このタグを追加して、href
属性が type
情報のすべてを格納した XML ファイル (Web アプリケーションの相対パス) を指すように設定します。typeInclude
タグのサンプルは次のようになります: <typeInclude xhref="/WEB-INF/activemenuTypes/ username.xml"/>
。
また、type
タグは typeInclude
タグと共にコンフィグレーション ファイルで使用できます。コード リスト 5-2 のコード サンプルを参照してください。
<typeInclude xhref="/WEB-INF/activemenuTypes/username.xml"/>
<type>
<menuItem>
<param name="linkId"/>
<action action="editLink">
<i18nNamebundleName="com.bea.apps.groupspace.links.
LinksPopupMenu" key="edit.link"/>
</action>
<img xsrc="wlpAppsCollaborationCore/images/wlp-edit-16.gif"/>
</menuItem>
</type>
別の XML ファイルを指す場合は、コード リスト 5-3 に示すように、正しくネームスペースを行うようにする。
<type name="username"
xmlns="http://www.bea.com/servers/apps/groupspace/ui/
activemenus-config/9.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/apps/groupspace/ui/
activemenus-config/9.0">
...
</type>
type
タグは、個々のメニューを定義して Web アプリケーション内で使用します。name
属性は各メニューでユニークな名前でなければなりません。これは、ActiveMenus タグを使用する場合に名前によりメニューが参照されるためです。以下に type
タグのサンプルを示します。
<type name="foo">
</type>
注意 : | TypeDefault タグと MenuItem タグは、type タグ内に含まれている必要があります。 |
typeDefault
タグは、ActiveMenus
タグが使用されている場合にブラウザに表示する内容を定義します。表示するテキスト、テキストのスタイル、マウスのテキストへの配置により表示される画像 (これはメニュー自体を示す) などをコントロールできます。
以下の項目は、ActiveMenus
タグを使用した場合にブラウザ内に表示されます。
displayText
属性 - 表示される実際のテキストを定義します。displayText
が定義されていない場合は、ActiveMenus
タグの display
属性に配置され任意のテキストが表示されます。ただし、他のテキストを表示したい場合は、表示する文字列を返すクラスとそのクラス内のメソッドを指定できます。次のサンプルに、他のテキストを表示する方法を示します。GetUserNameFromProfile.java
public class GetUserNameFromProfile
{
public static String getName(String userName)
{
return "XXX-" + username + "-XXX";
}
}
このコードと、上記で定義したコンフィグレーション、および次の ActiveMenus
タグ: <activemenus display="UserName" type="foo"/>
を使用する場合は、次のようにブラウザに表示されます: XXX-UserName-XXX
。
このサンプルでは、ActiveMenus
タブの本文に入力した情報を使用して、表示する他の情報を検索することができます。たとえば、ユーザ名を使って表示するユーザのフルネームを検索することができます。このアクションに関する唯一の規則は、表示テキストに使用するメソッドは public で、static であり、String 内に取り込まれ、String を返すことです。その他の情報をこのメソッドに渡すことはできません。
displayTextStyle
属性 - 表示テキストにスタイルを与える CSS スタイルまたはクラスを定義します。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。 displayMenuImage
属性 - 表示テキストがマウスに渡されたときに表示される画像を定義します。このタグが定義されていない場合は、デフォルトの画像が使用されます。この画像は activemenus_taglib.jar
ファイルにあり、menu_default.gif
という名前です。 menuStyle
属性 - 枠や背景色など、メニュー自体にスタイルを与える CSS スタイルまたはクラスを定義します。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。注意 : | TypeDefault タグと MenuItem タグは、type タグ内に含まれている必要があります。 |
menuItem
タグはポップアップ メニュー内の個々の項目を定義します。コード リスト 5-4 に、menuItem
タグを使用したコード サンプルを示します。
<menuItem>
<param name="q" value="foo"/>
<param name="userId"/>
<xmlHttp url="GetFirstNameServlet"/>
<row class="menuRow" style="backround-color:red"/>
<text class="menuText" style="color:#000000"/>
<rowRollover class="menuRowRollover" style="background-color:green"/>
<textRollover class="menuTextRollover" style="color:#FFFFFF"/>
</menuItem>
<menuItem>
<javascript>
<name>Testing</name>
<script>testing(this);</script>
</javascript>
</menuItem>
<menuItem default="true" showMenuItem="false">
<link url="http://www.google.com">
<name>Google</name>
</link>
</menuItem><menuItem>
<showMenuItem className="com.foo.CheckUserRights" methodName=
"doesUserHaveRights">
<rights name="can_view"/>
<rights name="can_edit"/>
</showMenuItem>
<allParams/>
<action action="addEditLink" disableAsync="true">
<i18nName bundleName="com.foo.LinksPopupMenu" key="edit.link"/>
</action>
</menuItem>
<menuItem>
<allParams/>
<dcAction action="showFeedData" dcContainerId="feedDataContainer">
<i18nName bundleName="com.foo.LinksPopupMenu" key="show.
feedData"/>
</dcAction>
</menuItem>
menuItem
タグは、次の 4 つのタイプを持ったポップアップ メニュー内の個々の項目を定義します。
javascript
要素 - この要素は、ユーザがこのメニュー項目をクリックしたときに実行する任意の JavaScript です。これをさらに便利にするために、メニュー項目に追加したカスタム パラメータにより param
タグで指定した値を取得できます (以下のコード サンプルを参照)。以下に、JavaScript を実装する基本的な方法を示します。...
<activeMenus:activemenus display="Foo Link" type="link">
<param name="linkId" value="${fooLink.id}"/>
<param name="linkParent" value="${fooLink.parent}"/>
</activeMenus:activemenus>
...
次の手順により、コンフィグレーション ファイルにカスタム JavaScript を定義します。JavaScript は コード リスト 5-5 に示すコードで渡す必要があります。
...
<
<type name="link">
menuItem>
<allParams/>
<javascript>
<name>Testing</name>
<script>fooTest(this);</script>
</javascript>
</menuItem>
</type>
...
JavaScript 要素を実装する場合の最後の手順は、以下のコード サンプルに示すように、JavaScript 関数の値にアクセスすることです。
...
<script>
function fooTest(object)
{
var linkId = object.getAttribute("linkId");
var linkParentName = object.getAttribute("linkParent");
}
</script>
...
xmlHttp
要素 - xmlHttp
はサーブレットを参照します (これは標準のサーブレット コンフィグレーションに完全に従う必要がある)。サーブレットが出力するものはメニューのその行に表示されます。""
または null
が xmlHttp
サーブレットから返された場合は、メニュー項目行はメニューに表示されません。情報は xmlHttp
リクエストにより取得されます。これにより、ページをリフレッシュせずに情報を更新できます。たとえば、ユーザのオンライン状態を示し、それによってフル掲載しないで更新できます。このためのサーブレットの書き込みに関する規則は 2 つあります。1 つは、すべての処理はサーブレットの doPost()
メソッドで行われる必要があること。もう 1 つは、定義されたパラメータは、リクエスト パラメータとして渡されることです。以下に、クエリ パラメータを取得するサンプルを示します。
String userName = request.getHeader("linkId");
link
要素 - この static URL は、定義した URL を指す新しいブラウザ ウィンドウを開きます。このタグは、メニュー自体に表示される name
タグまたは i18nName
タグ (以下に定義) のいずれかに取り込むことができます。定義したパラメータは、通常のリクエスト パラメータとしてリンクの末尾に追加されます。action
要素 - この action
名は、ActiveMenus
タグを含んだページまたはポートレットで使用できなければなりません。この要素は現在のブラウザ内でアクションを実行するため、転送を使用してページ フローをコントロールできます。このタグは、メニュー自体に表示される name
タグまたは i18nName
タグ (以下に定義) に取り込むことができます。渡された定義済みパラメータは、パラメータとしてリクエストで使用できます。ページ フローからこれらの値を取得するサンプルを次に示します:String linkId = getRequest().getParameter("linkId");
また、AJAX 対応ポートレット内の disableAsync
という属性を使用することもできます。メニュー項目のアクションに AJAX フレームワークの外部に送信させたい場合 (そのため、ページはフル掲載を行う) は、この属性を true
に設定します。デフォルトでは、この属性は false
に設定されます。
dcAction
要素 - ページ内で動的コンテンツ コンテナを設定した場合は、アクションを呼び出すメニュー項目を設定し、そのアクションにより動的コンテンツ コンテナを更新できます。これは action
メニュー項目と同じように機能し、実行するアクション名に取り込みます。唯一の違いは、dcContainerId
を指定する必要があり、これをページの <dc:executeContainerAction>
タグ内で定義した dcContainerId
に対応させる必要があります。 showMenuItem
要素 - 状況に応じてメニュー項目を表示する必要がある場合は、この要素を追加します (たとえば、現在のユーザの権限設定に基づく場合など)。メニュー項目を表示するかどうかを決定するクラス名とメソッド名を定義します。複数の showMenuItem
タグを使って、それぞれに異なるクラス、メソッド、または権限を使用できます。複数のタグを使用する場合は、メニュー項目を表示するすべてのケースが満たされる必要があります。たとえば、ユーザが 10 の内 9 の場合で条件を満たしても、メニュー項目は表示されません。これは、すべての場合が満たされなかったためです。コード リスト 5-6 に、showMenuItem
タグの使い方を示します。public class CheckUserRights
}
{
public static boolean doesUserHaveRights(HttpServletRequest request,
String[] rights)
{
for(int i=0;i<rights.length;i++)
{
if(!checkAccess(request, rights[i]))
{
return false;
}
return true;
}
}
default
属性 - この属性を menuItem
タグで使用し、true
に設定すると、表示テキスト アンカーの href
はリンクまたはアクションになります。メイン リンクをクリックしたときにデフォルトのアクションを起こしたい場合や、一貫性を実現するためにアクションを表示したい場合は、この属性を使用します。この属性のデフォルト値は、false
です。showMenuItem
属性 - この属性を menuItem
タグで使用し、false
に設定すると、メニュー項目は ActiveMenu に表示されません。メイン リンクをクリックしたときにデフォルトのアクションを起こしたいが、アクションを表示したくない場合は、この属性を使用します。この属性のデフォルト値は、true
です。注意 : | ActiveMenus タグを anchor タグ内に内包しないでください。これは、望ましくない結果を生じる場合があるためです。代わりに、default 属性および showMenuItem 属性を使用して、ActiveMenu 表示テキスト リンクをコントロールします。 |
allParams
要素 - この要素は、タグ (「ActiveMenus タグの使用」を参照) で定義されたすべてのパラメータがこのメニュー項目に対して設定されるように指定します。この要素が使用されない場合 (また、param
用紙が使用されない場合) は、パラメータはメニュー項目に対して設定されません。param
要素 - この要素は特定のパラメータをメニュー項目に設定します。param
要素には name
属性があり、この属性は ActiveMenu
タグ内 (「ActiveMenus タグの使用」を参照) で設定されたparam
要素の name
属性と一致しなければなりません。また、これには value
属性があり、コンフィグレーション時に値をハード コードするために使用できます。この value
属性は設定されていますが、value
はランタイム時にも (たとえば、ActiveMenu
タグ内のparam
タグを使用して) 指定されたため、ランタイム値はハード コードされた値より優先されます。また、ハードコードした値を使用する場合は、param
タグは ActiveMenus
タグを使用するときに指定する必要がありません。name
要素 - この要素はタグ内でメニュー項目として定義された静的な名前だけを表示します。i18nName
要素 - この要素には、使用できる .properties
ファイルにマップする必要がある bundleName
属性と、キー属性の両方があります。bundleName
属性は標準 Java ResourceBundle 表記法を使用します。key
属性は指定したバンドル内で捕捉するキーを定義します。このバンドル内でこのキーに関連するテキストは、メニュー項目に表示されますimg
要素 - この要素は指定した画像をアイコンで左のカラムに追加します。Web アプリケーションに対する画像ファイルのパスを指定する必要があります。bgImg
要素 - この要素は左のカラムで使用する背景画像を指定した画像に置き換えます。Web アプリケーションに対する画像ファイルのパスを指定する必要があります。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。text
要素 - この要素はメニュー項目のテキストにスタイルを与える CSS スタイルまたはクラスを定義します。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。rowRollover
要素 - この要素は、マウスのポインタが上に置かれたときに、メニュー項目の行にスタイルを与える CSS スタイルまたはクラスを定義します。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。 textRollover
要素 - この要素は、マウスのポインタが上に置かれたときに、メニュー項目のテキストにスタイルを与える CSS スタイルまたはクラスを定義します。class
属性を正しく機能させるには、クラスをページで定義する (またはクラスを定義する CSS ファイルをインポートする) 必要があります。 注意 : | TypeDefault タグと MenuItem タグは、type タグ内に含まれている必要があります。 |
taglib.tld
ファイルは activemenus_taglib.jar
ファイルにあります。
以下の属性と要素を ActiveMenus
タグで使用できます。
display
属性 - この属性はタグ自体に代わって表示されるものを定義します。displayText
属性を使用する場合、これは displayText
タグで定義されたメソッドに渡される値になります。activemenus-config.xml
ファイルで定義されたタイプと一致する必要があります。href
属性 - この属性はオプションで、タグの表示テキストのデフォルトのアンカ href
をオーバーライドできます。newWindow
属性 - この href
属性はオプションで、新しいブラウザ ウィンドウに開くリンクを指定します。これはブーリアン属性で、true
または false
に設定します。 class
属性 - この属性はオプションで、表示テキストの CSS クラスを定義します。 style
属性 - この属性はオプションで、表示テキストに適用する CSS スタイルを定義します。 rightClick
属性 - このブーリアン属性はメニューを、ロールオーバー メニューではなく、右クリック メニューに変えます。デフォルトは、false
です。この属性を true
に設定すると、表示テキストを右クリックするとメニューが表示されます。メニューはマウスの下に現れます。 escapeXml
属性 - この属性は JSTL タグ内の escapeXml
と同じです。true
に設定すると、文字は対応する文字エンティティ コードに変換されます。 param
要素 - この要素は、渡すことにより異なるメニュー項目に使用できるパラメータを設定します。次の 2 つの属性はどちらも必須です。注意 : | タグでクラスが指定された場合は、activemenus-config.xml ファイルで指定されたデフォルトのクラスがオーバーライドされ、デフォルトのスタイルは activename に適用されません。タグでスタイルが指定された場合は、デフォルトのクラスが activename に適用されます。タグで class="" が指定された場合は、デフォルトのクラスが activename に適用されません。 |
DragDrop JSP タグ ライブラリを使用すると、ドラッグ アンド ドロップ機能を GroupSpace コミュニティ、カスタム コミュニティ、またはポータル Web アプリケーションで有効化できます。JSP に表示されるドラッグ可能なオブジェクトを特定し、ドロップされたドラッグ可能なオブジェクトに反応するようにコンフィグレーションされるドロップ ゾーンを特定します。ページ フロー アクションのトリガ、JavaScript 関数の呼び出し、またはサーブレットへのデータの送信により、ドロップ ゾーンは反応します。
DragDrop タグ ライブラリを使用する前に、以下のアクションを実行します。
dragdrop_taglib.jar
ファイルを Web アプリケーションの CLASSPATH に含めます。web.xml
ファイルに配置します。<servlet>
<servlet-name>DragDropResourceServlet</servlet-name>
<servlet-class>com.bea.apps.communities.servlets.
GetDragDropResourceServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>DragDropResourceServlet</servlet-name>
<url-pattern>DragDropResourceServlet</url-pattern>
</servlet-mapping>
DragDrop タグ ライブラリには 3 つのタグが定義されています。以下に、各タグの使用法と JSP コードのサンプルを示します。
ページで他の DragDrop タグを使用する前に、dragDropScript
タグを含める必要があります。このタグは、適切な JavaScript ライブラリが含まれるようにします。dragDropScript
タグは属性を取りません。
次の例は、dragDropScript
タグ: <dragdrop:dragDropScript/>
の使い方を示します。
draggableResource
タグはページ上でドラッグ可能なリソースを指定します。このタグは次の属性を取ります。
draggableResource
タグは、dragdrop:image
属性を持った子 img
タグの検索を行います。この画像は、ドラッグ操作中に表示される画像になります。画像には絶対高さと幅の属性がなければなりません。
resourceId
値は、値が resourceDropZone
にドロップされたときに、JavaScript 関数の getSourceId()
によりアクセスできます。また、resourceId
値も、POST
アクションをトリガする resourceDropZone
にドロップされると、sourceId
というリクエストのパラメータとして入手できます。コード リスト 5-7 を参照してください。
<dragdrop:draggableResource imageId="0" resourceId="${id}"resourceName=
"${name}">
<img src="/image.gif" width="16px" height="16px"dragdrop:image="true"/>
${name}
</dragdrop:draggableResource>
resourceDropZone
タグは、ドラッグ可能なリソースをドロップできる領域を識別します。
targetId
属性 - ドロップ ゾーン オブジェクトのユニークな識別子です。この識別子は、基盤となるビジネス ロジックにより使用され、ドロップ アクションを受け取ったオブジェクトをユニークに識別できる ID です。 jsFunctionCall
属性 - draggableResource
がこの resourceDropZone
にドロップされると実行する JavaScript 関数です。 pageFlowAction
属性 - draggableResource
がこの resourceDropZone
にドラッグされると開始される有効なページ フロー アクションです。 formAction
属性 - draggableResource
がこの resourceDropZone
にドロップされたときに、POST
アクションを受信する有効な JSP またはサーブレットです。
次の属性のいずれかが必要です: jsFunctionCall
、pageFlowAction
、または formAction
。jsFunctionCall
が最も優先度が高く、次に pageFlowAction
、最後に formAction
となります。
targetId
値は、ドラッグ可能なリソースがドロップされたときに、JavaScript 関数の getTargetId()
によりアクセスできます。また、ドラッグ可能なリソースがドロップされたときに POST アクションをトリガする targetId
リクエストのパラメータとしても入手できます。この動作方法については、次のコードを参照してください。
<dragdrop:resourceDropZone targetId="${id}" pageFlowAction="moveIssue">
<img src="/folder.gif"/>Issues Folder
</dragdrop:resourceDropZone>
コード リスト 5-8 に、moveIssue
アクションを IssuesPageFlowController.java
という名前のファイルにコーディングする方法を示します。
@Jpf.Action(forwards={ @Jpf.Forward(name = "success", path =
"displayIssuesTree.do")})
protected Forward moveIssue() {
Forward forward = new Forward("success");
String sourceId = getRequest().getParameter("sourceId");
String targetId = getRequest().getParameter("targetId");
move(sourceId, targetId);
return forward;
}
DynamicContent
タグ ライブラリを使用すると、GroupSpace コミュニティ、カスタム コミュニティ、またはポータル Web アプリケーションで JSP ページの部分を素早く更新できます。
DynamicContent
タグでは、AJAX リクエストを使用してページ フロー ベースのポートレット内にある JSP ページの部分を更新できます。このタグは、フル ポータル リクエストを実行ずにページの部分を更新できます。これらの AJAX リクエストはフル ポータル リクエストに比べ小さく高速であるため、ポータル アプリケーションでの対話の応答性が向上します。
これらのタグは標準的なページ フロー ベースのポートレット開発に簡単に組み込むことができ、ユーザのポータルの使用感を向上できる高度なユーザ インタフェースを作成するのに役立ちます。
注意 : | DynamicContent タグはポートレット コンテンツの非同期表示とは関係がありません。ポートレットの非同期では、ポーレット全体のコンテンツをポータルから独立して表示できます。DynamicContent タグはポーレット内の JSP ページの小部分に影響を与えるように設計されています。 |
このセクションでは、DynamicContent
タグ ライブラリの主なタグについて説明します。
Container
タグは、ページ フロー アクションの実行による HTML 出力を格納する JSP ページ上の場所を指定します。このタグに必要な唯一の属性はコンテナ id です。この id は、コンテナを識別するために他の DynamicContent
タグにより参照されます。次のコードに、このタグの使用方法を示します: <dc:container dcContainerId="outputContainer"/>
。
このタグは Container
タグの子で、実行可能なページ フロー アクションを識別し、その HTML 出力は親コンテナ内に配置されます。containerActionScript
タグは次の属性を取ります。
action
属性だけが必須です。次のサンプル コードに、このタグを親 Container
タグで使用する方法を示します。
<dc:container dcContainerId="outputContainer">
<dc:containerActionScript action="resetDynamicContentContainer"
initial="true"/>
<dc:containerActionScript action="showServerTime"/>
<dc:container/>
Execute Container Action タグは、コンテナ内の特定のアクションの呼び出しを作成するために使用します。このタグは次の属性を取ります。
dcContainerId
属性および action
属性が必要です。次に、このタグの使用方法のサンプルを示します。
<dc:executeContainerAction action="showServerTime" dcContainerId=
"outputContainer"
var="showServerTimeVar"/>
前のサンプルでは、特例のアクションの呼び出しを変数 showServerTimeVar
に格納しました。次に示す HTML コードにより、この変数を参照できます。
<form>
<input type="button" onclick="${showServerTimeVar}" value="Show Server
Time"/>
</form>
ユーザがボタンをクリックすると、showServerTime
アクションを実行する AJAX リクエストが作成され、そのアクションにより生成された HTML 出力を outputContainer
の id を持ったコンテナに配置します。
DynamicContent
タグも、リクエストによりアクションに渡されるパラメータのタグを含みます。executeContainerAction
タグまたは containerActionScript
タグ内にパラメータを定義できます。これらのパラメータには、request.getParameter()
method
を呼び出すことにより、ページ フロー アクションでアクセスできます。
DynamicContent
タグにはいくつかの重要な制限があります。ページ フロー アクションをトリガするために使用する AJAX リクエストは、メイン ポータル サーブレットにより処理されません。これらのリクエストは、一部の処理を実行する専用のサーブレットを調べて、適切なページ フローのインスタンスが使用されるようにします。通常はリクエストで入手できる多くの主要要素は、これらの AJAX リクエストからアクセスできません。たとえば、コミュニティ ベースのポータル アプリケーションでは、CommunityContext
オブジェクトは AJAX リクエストからアクセスできません。これらのフレームワーク要素へのアクセスが足りないと、資格の付与やセキュリティなどに影響を与える可能性があります。
これらの制限のために、DynamicContent
タグは、大規模なフレームワーク サービスに依存関係がほとんどなく、処理量が少ない場合の使用に適しています。次の使用例では、DynamicContent
タグを最適化します。
DynamicContent
タグは、各写真を表示するために高価なポータル リクエストを使用しないツールを提供します。
sample.zip
ファイルに含まれたサンプル コードやユーティリティについては、「dev2dev」を参照してください。
開発段階では、UserPicker
タグ ライブラリを使用して、GroupSpace コミュニティ、 カスタム コミュニティまたは、ポータル Web アプリケーションで、JSP ページにフォーム ボタンを追加することができます。
UserPicker:popupButton
タグは、JSP ページにフォーム ボタンを追加して、ポップアップ ウィンドウを開き、現在のユーザのリストを表示する機能を開発者に提供します。このリストからユーザを選択することができます。選択したユーザの名前は親ウィンドウの指定されたフォーム フィールドに入力されます。
この節では、カスタム コミュニティの UserPicker:popupButton
タグについて説明し、さらに以下の属性の使用方法について説明します。
inputId
タグ - 選択したユーザ名が入力されている HTML フォーム入力要素の ID。 このタグは省略可能。inputTagId
タグ - 選択したユーザ名が入力されている netui ベース フォーム入力要素の tagId
。 inputId
タグを設定する場合は、inputTagId
タグは無視される。このタグは省略可能。buttonImage
タグ - ポップアップ ボタンのための画像への src パス。 このタグは必須。atnProviderName
タグ - 認証プロバイダの名前。 atnProviderName
を設定する場合は、ポップアップ ウィンドウにプロバイダ ドロップダウン ボックスは表示されない。atnProviderName
を設定しない場合は、デフォルト プロバイダが使用される。複数の認証プロバイダをコンフィグレーションした場合は、ポップアップ ウィンドウにドロップダウン ボックスが表示され、そこからプロパイダを指定できる。このタグは省略可能。ヒント : | コミュニティでUserPicker:popupButton タグを使用すると、ユーザではなくコミュニティ メンバーがリストされます。 |
Workshop for WebLogic では、Java (JSR168) ポートレットをインポートおよびエクスポートすることができます。Java ポートレットは Web アーカイブ (WAR)、Java アーカイブ (JAR)、または ZIP ファイルからワークスペースに、直接、インポートできます。Workshop for WebLogic では、インポートされるすべての Java ポートレットについて .portlet
ファイルが自動的に作成されます。これにより、Java ポートレットをポータルですぐに使用できるようになります。また、Java ポートレットをワークスペースからサポート対象のアーカイブ ファイルにエクスポートすることができます。
注意 : | この節全体を通し、サポート対象のアーカイブ ファイルとは WAR、JAR、および ZIP の各ファイルを指します。 |
デフォルトでは、Workshop for WebLogic は、portlet.xml
、ポートレットで必要な Java クラス ファイル、および Java ソース ファイルをインポート/エクスポートします。また、JAR または ZIP アーカイブ内にクラス ファイルまたは Java ファイルが存在する場合は、そのアーカイブもインポート/エクスポートします。インポートまたはエクスポート対象のファイルとして、追加のファイルを任意で指定できます。エクスポート後、サポート対象のアーカイブ ファイルに含まれている Java ポートレットは互換性のあるどのような Web サーバでも使用できます。
ヒント : | JSR168 インポート ユーティリティを使用して、サポート対象のアーカイブ ファイルに含まれた Java ポートレットを、直接、 WebLogic Server インスタンスにデプロイできます。このユーティリティでデプロイ後、WSRP を通じてコンシューマがポートレットを使用できるようになります。このユーティリティの詳細については、「JSR168 インポート ユーティリティの使用」を参照してください。 |
サポート対象のアーカイブ ファイルにパッケージ化された Java ポートレットを Workshop for WebLogic ワークスペースにインポートするには、以下の手順を実行します。
注意 : | 選択したアーカイブに Java ポートレットが含まれていない場合、標準的なアーティファクトは一切選択されません。これは、デフォルトのアーカイブ フォーマット プラグインがそのアーカイブを Java ポートレット アーカイブとして認識しないためです。この場合、ウィザードでアーカイブ フォーマットを選択するか、またはインポートするファイルを手動で選択できます。これは一般的な使用例ではありません。 |
ヒント : | [対象パス] フィールドにフォルダ名を入力することで、インポートしたポートレットのための新しいフォルダを簡単に作成できます。たとえば、/portlets を入力すると、WebContent/portlets というフォルダが作成され、ポートレットはそのフォルダに配置されます。ポートレットを選択して対象パス入力することで、簡単に 1 つまたは複数のポートレットに特定の対象パスを割り当てることができます。[リセット] ボタンを押すと元のパスに戻ります。ポートレットのグループを複数選択して、選択したグループに対象パスを割り当てることもできます。 |
ヒント : | オプションのファイルとは、サポート対象のアーカイブ ファイル内のファイルで、インポート テンプレートで必須として指定されていないファイルを指します。デフォルトのインポート テンプレートでは、ポートレットで必要な portlet.xml ファイルとすべてのクラス ファイルがアーカイブに含まれている必要があります。 |
ヒント : | 独自のカスタム インポート プラグインを開発する場合、[フォーマットの選択] ダイアログのドロップダウン フォーマット リストにそのプラグインも表示されます。インポートするアーカイブのフォーマットを指定する必要がある場合、およびデフォルト フォーマットでは不十分な場合は、カスタム ポートレット インポート プラグインを作成できます。プラグインを作成するには、PortletImporterPlugin インタフェースを実装する必要があります。詳細については、インタフェースの Javadoc を参照してください。 |
.portlet
ファイルがワークスペースに自動的に作成されます。 ヒント : | インポートで問題が発生する場合、プロジェクト ワークスペースに既存するアーティファクトと競合している可能性があります。このイベントでは、[戻る] ボタンを使用して競合しているアーティファクトの対象パスを変更するか、または [プロジェクトの選択] ダイアログのウィザード オプションを選択して既存のリソースを強制的に上書きするようにします (図 5-47 を参照)。 |
新規または既存のサポート対象のアーカイブ ファイル (WAR、JAR、または ZIP) に Java ポートレットをエクスポートできます。サポート対象のアーカイブ ファイルに Java ポートレットをエクスポートするには、以下の手順を実行します。
エクスポート ツールを使用して重複ファイルを強制的に自動上書きする場合は、[警告なしで既存リソースを上書き] チェックボックスを選択します。
注意 : | 選択したポートレットはすべて、同じ Web プロジェクト内にある必要があります。エクスポートするポートレットを異なる Web プロジェクトにまたがって選択することはできません。 |
portlet.xml
ファイルに書き込まれます。[次へ] をクリックして、次に進みます。 注意 : | [タイトル] は各ポートレットに必須です。すべての [タイトル] フィールドが空白の場合は、タイトルを指定するまで [次へ] ボタンが無効になります。 |
ヒント : | 独自のカスタム エクスポート プラグインを開発する場合、[フォーマットの選択] ダイアログのドロップダウン フォーマット リストにそのプラグインも表示されます。エクスポートするアーカイブのフォーマットを指定する必要がある場合、およびデフォルト フォーマットでは不十分な場合は、カスタム ポートレット エクスポート プラグインを作成できます。プラグインを作成するには、PortletExporterPlugin インタフェースを実装する必要があります。詳細については、インタフェースの Javadoc を参照してください。 |
portlet.xml
など) は、ダイアログで自動的に選択されます。[対象パス] のパスを選択したすべてのファイルに関連付けることができます。これらのファイルは、アーカイブ ファイル内で指定した対象パスに配置されます。デフォルトでは、アーカイブのルート ディレクトリを基準とした場合の相対パスにすべてのファイルが格納されます。
WebLogic Portal には、JSR-168 WAR ファイルにパッケージされた JSR 168 ポートレットを自動的にデプロイするユーティリティが用意されています。このユーティリティでは、JSR-168 ポートレットを格納した JSR-168 WAR をインポートして、WSRP プロデューサでポートレットを公開できます。このユーティリティ の詳細については、『プロダクション業務ガイド』の「ポータル アプリケーションのデプロイ」の章を参照してください。
![]() ![]() ![]() |