|
|
この章で説明するタスクを実行する前に、『ポータル開発環境の設定』 に記載された設定手順をすでに実行していることを確認してください。また、ポータルの構築を始める前に、ルック アンド フィール要素や必要な CSS ファイルなど、ポータルのフレームワークを準備しておく必要があります。
ポータルを作成すると、WebLogic Portal によりポータル ファイルが作成されます。このファイルは、.portal ファイル拡張子を持つ XML ファイルです。.portal ファイルは、ポータルでの中心的なファイルとして定義され、デスクトップ、ブック、ページ、ポートレットなど、ポータルのすべての主要なコンポーネントへの参照が設定されています。
ポータルとそれに付随する .portal ファイルを作成するには、以下の手順を実行します。
WebContent) に移動し、ディレクトリを右クリックして [新規｜ポータル] を選択します。
図 7-1 に示すように、[新しいポータル] ダイアログが表示されます。
Web コンテンツ ディレクトリを右クリックしてこのウィザードを起動したため、親フォルダ フィールドにそのディレクトリ名が自動的に表示されます。
Web プロジェクト ディレクトリの下位にある Web コンテンツ ディレクトリで、目的のポータル ファイルを見つけます。デフォルトの Web コンテンツ ディレクトリ名は WebContent で、この名前は [ポータル Web プロジェクト] ウィザードを使用するときに割り当てられます。Web コンテンツのディレクトリの名前は、必要に応じて変更できます。詳細については、「[新しいポータル Web プロジェクト - Web Module] ダイアログ」を参照してください。
ポータルのファイル タイプは .portal にする必要があります。ポータルの名前に拡張子 .portal を入力することもできますが、入力を省略するとこの拡張子が自動的に追加されます。
図 7-2 に示すように、ポータル Web プロジェクトの指定したフォルダにポータルが追加され、このポータルがエディタに表示されます。
作成したポータルには、デスクトップ、ヘッダ、フッタ、ブック、およびページが含まれます。デスクトップは、ポータル コンテンツのユーザ固有のビューです。ポータルでは多数のデスクトップをサポートできます。1 つのポータルでは、従業員固有のデスクトップや顧客固有のデスクトップなどをサポートできます。各デスクトップでは、さまざまな種類のコンテンツをさまざまなグループのユーザに公開します。ポータルの任意の部分 (ブック、ページ、特定のアプリケーション、個々のリンクなど) をデスクトップに含めたり、デスクトップから除外したりできます。
また、デスクトップでは、ポータルのルック アンド フィール属性を定義することもできます。デスクトップは、使用する配色、フォント、および画像を定義する特定のスキンに関連付けることができます。デスクトップには、ヘッダとフッタも含まれています。イメージ、テキスト、任意の Web コンテンツをこれらの領域に配置することで、デスクトップのルック アンド フィールに一貫性を持たせることができます。
通常、Workshop for WebLogic を使用してポータルとその主要コンポーネントを開発した後、WebLogic Portal Administration Console でポータルをテンプレートとして使用して、特定のデスクトップを作成します。開発の次の段階でデスクトップを作成する方法については、「ポータル デスクトップの管理」を参照してください。
階層形式でコンテンツとナビゲーションを整理するには、ブックを使用します。ブックには他のブックまたはページを含めることができます。ブラウザでは、ブックは一連のタブまたはリンクとして表示されます。各ポータルには、「メイン ページ ブック」というメイン ブックがデフォルトで含まれています。ページは、ポータルの実際のコンテンツを編成する一連のカラムとウィンドウで構成されます。ページに移動するには、個々のタブまたはリンクをクリックします。Workshop for WebLogic または WebLogic Portal Administration Console のいずれかを使用して、ブックおよびページを作成できます。
この節では、ポータルのメイン ブックに次のページを追加する方法について説明します。ブラウザにポータルが表示されると、2 つのページはクリックできる 2 つのタブとして表示されます。新しいページを追加する方法はいくつかあります。この節では、ドラッグ アンド ドロップによる方法について説明します。
| 注意 : | ポータルにブックを追加する手順は、ページを追加する手順とほとんど同じです。ここでは、両方の手順を説明するのではなく、ページを追加する方法について説明し、必要な箇所で両方のタスクの違いについて説明することにします。 |
| ヒント : | パレット ビューが表示されていない場合は、[ウィンドウ｜ビューの表示｜パレット] を選択します。 |
スタンドアロン ブックまたはページを作成することができます。作成すると、ブックまたはページの情報は別個の .book または .page ファイルに保存され、.portal ファイルには組み込まれせん。スタンドアロン ブックおよびページは、ポータル開発環境で非常に有用な要素です。たとえば、チーム開発環境では、個別に管理して後でポータルに追加できる個々のブックまたはページを開発者は作成できます。また、リモートのコンシューマ アプリケーションにアクセスできるブックやページを作成する場合は、Workshop for WebLogic を使用して、ブックまたはページをスタンドアロンの .book または .page ファイルとして作成する必要があります。
| 注意 : | スタンドアロン ブックの作成手順は、スタンドアロン ページの作成手順とほとんど同じです。ここでは、両方の手順を説明するのではなく、スタンドアロン ページを作成する方法について説明し、必要な箇所で両方の手順の違いを説明することにします。 |
ポータルにスタンドアロン ページを作成するには、以下の手順を実行します。
![[新しいポータル] ダイアログ](wwimages/portalTut-22.gif)
WebContent) または Web コンテンツ フォルダ内のフォルダに移動します。
Web プロジェクト ディレクトリの下位にある Web コンテンツ ディレクトリまたはサブディレクトリで、ブックとページを見つけます。デフォルトの Web コンテンツ ディレクトリ名は WebContent で、この名前は [ポータル Web プロジェクト] ウィザードを使用するときに割り当てられます。Web コンテンツのディレクトリの名前は、必要に応じて変更できます。詳細については、「[新しいポータル Web プロジェクト - Web Module] ダイアログ」を参照してください。
[新しいページ] ダイアログで、ウィザードを開始する前に移動した親フォルダのパスが自動入力されていることを確認します。
スタンドアロン ページの場合、ファイル タイプは .page にする必要があります (スタンドアロン ブックの場合は .book)。必要な場合は .page 拡張子を入力できますが、入力しないと、WebLogic Portal により自動的に拡張子が追加されます。
図 7-5 に示すように、指定したフォルダのポータル Web プロジェクトに新しいページが追加されます。
また、エディタでページを開くと、図 7-6 のようになります。
既存のページを抽出して、このページは、Web プロジェクト内の別のポータル アプリケーションに再利用できます。既存のページを抽出する場合、そのすべてのコンテンツ (ポートレットなど) も抽出されます。
既存のページまたはブックを抽出するには、以下の手順に従います。
次の選択手順に従って、既存のブックまたはページへの参照をポータルのブックまたはページに追加します。
ポータル エディタからブックまたはページの参照を追加するには、以下の手順を実行します。
[ブックの選択] ダイアログまたは [ページの選択] ダイアログが表示されます。Web プロジェクト用のすべての .book ファイルまたは .page ファイルが一覧表示されます。
| 注意 : | [挿入] メニュー オプションは、選択したポータル要素に応じて、この選択が有効な場合にのみ表示されます。 |
![[新しいページ] ダイアログ](wwimages/dlg_page_standalone_newpage.gif)
.book ファイルまたは .page ファイルを選択し、[OK] をクリックします。
Workshop for WebLogic ウィンドウが更新されて、アウトライン ビューに Book (または Page) Content ノードが追加され、プロパティ ビューにコンテンツ プロパティが表示されます。
[アウトライン] ビューからブックまたはページの参照を追加するには、以下の手順を実行します。
[ブックの選択] ダイアログまたは [ページの選択] ダイアログが表示されます。Web プロジェクト用のすべての .book ファイルまたは .page ファイルが一覧表示されます。
| 注意 : | [挿入] メニュー オプションは、選択したポータル要素に応じて、この選択が有効な場合にのみ表示されます。 |
.book ファイルまたは .page ファイルを選択し、[OK] をクリックします。
Workshop for WebLogic ウィンドウが更新されて、アウトライン ビューに Book (または Page) Content ノードが追加され、プロパティ ビューにコンテンツ プロパティが表示されます。
ブックおよびページの順序を変更できます。たとえば、メイン ページ ブックに 1 つのページと 1 つのブックが次の順序で配置されているとします。
ブックおよびページの順序を変更するには、アウトライン ビューで、移動するブックまたはページを右クリックし、[上へ移動] または [下へ移動] を選択します。アウトライン ビュー内でブックまたはページが上または下に移動し、ポータル エディタ内では水平方向の順序が変更されます。
ブックおよびページの配置を変更しても、WebLogic Portal Administration Console を使用して作成済みのブックおよびページの配置は、ポータル デスクトップでは変更されません。これらのブックおよびページの再配置の手順については、「ポータル デスクトップの管理」を参照してください。
ポータルのプロパティは、ポータルをユニークに識別し、ポータルの特性を定義する名前付きのポータルの属性です。一部のプロパティ (タイトル、定義ラベルなど) は必須です。多くのオプションのプロパティを使用すると、プレゼンテーション プロパティ、ロールオーバ画像、コントロール ツリーの最適化など、ポータルの特定の機能を有効にできます。ポータルに使用する特定のプロパティは、そのポータルの使い方に応じて異なります。
各ポータル コンポーネントには、動作のコンフィグレーションに使用するプロパティのセットが含まれています。たとえば、デスクトップで使用するルック アンド フィール、および実行時に使用するエンコーディングのタイプを指定するデスクトップ プロパティをコンフィグレーションできます。
ポータル プロパティには、メイン コンポーネント (ブック、ページ、デスクトップなど) 用のプロパティのサブセットが含まれています。*.portal ファイルでは、これらのプロパティの全体のビューが提供されます。
ポータル ライフサイクルの開発段階では、通常 Workshop for WebLogic を使用してポータルのプロパティを編集します。この節では、Workshop for WebLogic を使用して編集できるプロパティについて説明します。
ステージング段階およびプロダクション段階では、通常 WebLogic Portal Administration Console を使用してポータルのプロパティを編集します。この時点では、プロパティのサブセットのみ編集可能です。WebLogic Portal Administration Console でポータル プロパティを編集する手順については、「ポータル デスクトップの管理」を参照してください。
ポータル エディタ ビューで境界線をクリックすると、ポータルのそのセクションの周囲にオレンジ色の輪郭が表示され、関連するプロパティのセットがプロパティ ビューに表示されます。表示されるプロパティは、ビューで選択した境界線に応じて異なります。図 7-7 は、強調表示されたヘッダ領域と関連するプロパティを示しています。
ポータル プロパティを編集するには、以下の手順を実行します。
.portal ファイルをダブルクリックしてエディタで開きます。
表示されるプロパティは、選択したアクティブ領域に応じて異なります。たとえば、境界線の外側 (デスクトップ) をクリックするとデスクトップ全体が表示され、プレースホルダの内側をクリックするとそのプレースホルダのプロパティが表示されます。
マウスをプロパティ フィールドの上に移動すると、そのフィールドの説明がポップアップ ウィンドウに表示されます。
一部のプロパティは、ポータルを作成した後は値を編集できなくなります。
プロパティ フィールドによっては、そのプロパティに関連する情報を表示できる場合があります。たとえば、スケルトン URI プロパティには、関連付けられているファイルを表示する [開く] 
ボタンが用意されています。プロパティ ビューで利用できるオプションの詳細については、「プロパティ ビューを使用する場合のヒント」を参照してください。
プロパティ ビューの動作は、編集するフィールドの種類に応じて異なります。次に説明するヒントは、プロパティ ビューのデータ フィールドの内容を操作するときに役立つ場合があります。
ボタンがプロパティ ビューに表示され、[開く] をクリックすると、そのファイル タイプ用のエディタまたはビューが表示される。 
.portal ファイルを右クリックし、[アプリケーションから開く｜XML エディター] を選択すると、Eclipse に用意されている基本的な XML エディタを使用してファイルを開くことができる。
ポータルの各コンポーネントには、ユニークなプレゼンテーション プロパティを設定できます。表 7-1 に、プレゼンテーション プロパティとその値を示します。
デスクトップ プロパティでは、ポータル デスクトップの動作を指定できます。デスクトップに、バッキング ファイル、ルック アンド フィール プロパティ (シェル、タイトルなど)、およびデスクトップで使用するルック アンド フィールを割り当てることができます。表 7-2 に、デスクトップ プロパティとその値を示します。
ツリー最適化、および非同期モードの 2 つのデスクトップ プロパティはパフォーマンスのためにも重要です: パフォーマンスを重視したポータルの設計の詳細については、「最適なパフォーマンスを得るためのポータルの設計」を参照してください。
|
|||
.portal ファイルに保存されるときに実際の IANA 名に変換されます。
|
|||
|
|||
true に設定すると、ポータル フレームワークによってコントロール ツリーの全体ではなく一部が生成される。ツリー最適化はポータルの動作に多少の変化をもたらすので、必ず事前にポータルで完全なリグレッション テストを実行してから使用すること。詳しくは、「最適なパフォーマンスを得るためのポータルの設計」を参照してください。
|
ブック プロパティを使用すると、バッキング ファイルをブックに割り当てることができます。また、ポータルのルック アンド フィール ファイルではなく、テーマ ファイルを使用するようにページを設定することもできます。ブック プロパティには、ブックのさまざまなプレゼンテーション プロパティも含まれています。表 7-3 を参照してください。
|
||||
|
|
||||
|
||||
ページ プロパティを使用すると、ポータルで個々のページのプロパティをコンフィグレーションすることができます。レイアウト プロパティは、ページに含まれるプレースホルダの数と場所を決定します。表 7-4 に、各ページ プロパティを示します。
|
||||
|
|
プレースホルダは、ページ レイアウト内にある、名前が付いた節です。プレースホルダのプロパティを編集して、プレースホルダのテキスト フロー、幅などを変更することができます。レイアウトの詳細については、「レイアウトの操作」を参照してください。
表 7-5 では、プレースホルダのプロパティを示します。
共有 J2EE ライブラリのリソースは、ポータル Web プロジェクトにコピーしてからカスタマイズすることで、オーバーライドできます。
| 警告 : | J2EE ライブラリのリソースをプロジェクトにコピーすると、将来 WebLogic Portal 製品を更新するときに、これらのリソースに影響する製品の変更を手動で組み込む作業が必要になる場合があります。今後配布されるパッチをインストールした場合、WebLogic Portal では、コピーした J2EE ライブラリ リソースがプロジェクトに含まれていないコンフィグレーションだけをサポートします。 |
J2EE ライブラリのリソースをプロジェクトにコピーするには、以下の手順を実行します。
[ウィンドウ｜ビューの表示｜マージ済みプロジェクト] ビューを選択します。
マージ済みプロジェクト ビューは、デフォルト ポータル パースペクティブの一部で、[パッケージ・エクスプローラー] ビューと同じ領域に表示されます。
マージ済みプロジェクト ビューの斜体の項目は、共有 J2EE ライブラリに格納されているエンティティを表します。作成したポータル ファイルなど、ファイル システムに格納されているエンティティはすべて、通常の書体で表示されます。
1 つのファイル、ファイルのセット、またはフォルダ全体をプロジェクトにコピーすることができます。
リソースがプロジェクトの Web コンテンツ フォルダにコピーされ、J2EE ライブラリ内のそれらのリソースの場所の階層に反映されます。
| 注意 : | マージ済みプロジェクト ビューでファイルの [プロパティ] ダイアログを表示するには、ファイルを右クリックして [プロパティ] を選択します。このダイアログには、J2EE ライブラリの名前やバージョンなど、そのファイルの J2EE ライブラリの情報が表示されます。 |
次のいずれかの方法を使用して、J2EE ライブラリ ファイルをオーバーライドするローカル ファイルを表示できます。
デフォルトでは、J2EE ライブラリのオーバーライドを指示するアイコンはオフになっています。これは、情報の更新に処理時間が必要となるため、アイコンを使用すると WebLogic Portal プラグインを起動時に常にロードする必要があるためです。
WebLogic Portal には、開発を容易にし、自動化するためのカスタム Java コントロールがあります。このコントロールは、ページ フローにドラッグ アンド ドロップできるアクション (Java メソッド) の集合です。グラフィカル インタフェースにアクションを追加し、Workshop for WebLogic エディタでアクションをコンフィグレーションできるので、Java コードを直接操作する必要はありません (ソース ビューで直接コードを操作することもできます)。コードを直接操作する場合でも、最初にグラフィカル インタフェースで操作することにより、コード入力を自動化し、構文エラーをなくすことができます。
たとえば、WebLogic Portal に付属するカスタム コントロールでは、一部のメソッドで組み込みのフォームを利用できます。ユーザを作成するアクションが必要な場合、ユーザ プロバイダ コントロールの createUser メソッドを使用できます。createUser メソッドをコントロールのアクション領域に追加すると、JSP に追加しアクションに自動的にリンクできる CreateUserForm Bean をコントロールで利用できます。
Workshop for WebLogic によるページ フローの作成の詳細については、『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。WebLogic Portal に付属する特定のコントロールの詳細については、Javadoc を参照してください。
以降の節では、WebLogic Portal が提供するコントロールをページ フローで使用する方法について説明します。
.jpf ファイル) を開くか、新しいページ フローを作成します。
Workshop for WebLogic によるページ フローの作成の詳細については、『BEA Workshop for WebLogic Platform プログラマーズ ガイド』を参照してください。
図 7-9 に示すように、[コントロールの選択] ダイアログが表示されます。
これで、コントロールのすべてのメソッドがページ フローで使用できます。ポータル コントロールの詳細については、Javadoc を参照してください。
図 7-10 に示すように、ページ フロー エクスプローラ ビューからページ フロー エディタのフロー ビューにメソッドをドラッグすることにより、ページ フローにメソッド (アクション) を追加できます。
多くのポータル フレームワーク コントロールには保護されたメソッドが装備されています。つまり、コントロールがこれらのメソッドを実行するには、認可されたセキュリティ ロールが必要になります。ページ フローでは、アクションごとにセキュリティ ロールを指定できます。アクションを実行する場合、実行するユーザは所定のロールのメンバーでなければなりません。たとえば、ユーザ プロバイダ コントロールには removeUser() アクションがありますが、このアクションの呼び出し側は「Framework SystemAdministrator」ロールまたは「Admin」ロールに所属している必要があります。
ユーザおよびグループ管理アクションでは、WebLogic Administration Portal の認証セキュリティ プロバイダ サービスで指定したロールによって、ユーザがアクションを実行できるかどうかが決まります。
WebLogic Server Administration Console を使用して、ドメインにセキュリティ ロールを追加できます。
ポータルをサーバにデプロイ (公開) すると、ブラウザ ウィンドウに表示できます。
| 注意 : | Eclipse の問題のため、一部の JSP タグは、実際には正しい場合でも、エラーが含まれているものとしてマークされます。実際にはエラーが存在しないにもかかわらず、Eclipse ではそのアプリケーションは公開 (デプロイ) されません。このような場合は、公開前に JSP 検証を無効にする必要があります。これらのタグが原因となっている問題を除くすべての問題を解決するまで、JSP 検証を有効にしておきます。デプロイ前に、[ウィンドウ｜設定] を選択し、ツリーで [妥当性検査] を選択して、[JSP 構文バリデーター] チェック ボックスのチェックをはずします。 |
ポータル プロジェクトをデプロイ (公開) し、表示するには、以下の手順に従います。
![[挿入｜コントロール] メニューの選択](wwimages/menu_insert_control.gif)
![[コントロールの選択] ダイアログ](wwimages/dlg_select_control.gif)
.portal ファイルを右クリックし、[実行｜サーバーで実行] を選択します。 | 注意 : | 多くの場合、ポータルを再デプロイして、行った変更を確認する必要はありません。詳細については、「サーバでのプロジェクトの実行」を参照してください。 |
[サーバーで実行 - 新規サーバーの定義] ダイアログが表示されます。使用するサーバが強調表示されていることを確認します。
サーバが起動されるまで待機し、ファイルをサーバにデプロイして、アプリケーションを実行します。デプロイメントが進行している間、ウィンドウ下部のステータス バーにステータス メッセージが表示されます。
図 7-12 に示すように、エディタ ビューの新しいタブに結果が表示されます。
| ヒント : | 以前に同じ名前のプロジェクトをデプロイし、そのプロジェクトが別の場所にある場合、サーバからそのプロジェクトをアンデプロイする必要があります。アンデプロイするには、サーバ ビューでサーバをダブルクリックし、[パブリッシュされたモジュール] リストから該当するポータル Web プロジェクト (共有 J2EE ライブラリではありません) を削除します。この作業の詳細については、『BEA Workshop for WebLogic Platform プログラマーズ ガイド』の「サーバの管理」を参照してください。 |
| ヒント : | 必要に応じて、ポータルを表示する場合に常に外部 Web ブラウザを使用するように設定できます。この設定を行うには、[ウィンドウ｜設定] を選択し、プロパティ ツリーで [一般｜Web ブラウザー] を選択して、[外部 Web ブラウザーを使用] ラジオ ボタンを選択します。 |
以下の節では、WebLogic Portal で URL を操作する方法について説明します。
WebLogic Portal は、特にサーバ名とポート番号を変更したときに途切れることなく、ドメインからドメインに転送できるポータル Web プロジェクト内のポータル リソースに URL を作成する便利で拡張可能なメカニズムを用意しています。この URL 作成メカニズムは、セキュア URL と非セキュア URL (http と https) 間で切り替えることができます。
移植可能な URL を作成するには、次の 2 つの項目が必要です。
beehive-url-template-config.xml ファイルには、ユニークな名前を持つ複数の URL「テンプレート」が含まれています。これらのテンプレートの URL には、url:domain や url:port などの変数が含まれ、これらはアクティブなサーバから読み込まれます。<render:*Url> JSP タグには、beehive-url-template-config.xml ファイル内の URL テンプレートの名前を指定できる「テンプレート」属性があります。
表 7-6 に、JSP タグでテンプレートを使用して URL を作成する方法を示します。
WebLogic Portal に付属する beehive-url-template-config.xml ファイルにある任意の URL テンプレートを使用できると共に、必要な数のテンプレートをファイルに追加することができます。
URL テンプレートを構築する場合、以下の変数を使用できます。
{url:domain} - 現在の要求からサーバの名前を読み込みます。{url:port} - 現在の要求からサーバのリスン ポート番号を読み込みます。(以下のトラブルシューティングを参照){url:securePort} - 現在の要求からサーバの SSL ポート番号を読み込みます。(以下のトラブルシューティングを参照){url:path} - Web アプリケーションの名前を読み込みます。Web アプリケーション内のすべてのリソースへの URL は、その Web アプリケーションのディレクトリを基準にした相対パスです。 {url:queryString} - URL の queryString 変数を読み込みます。{url:compression} - より短い、より読み込みやすい URL を作成するために、プラグイン可能な圧縮メカニズムを使用できるようにします。詳細については、「URL 圧縮」を参照してください。
URL 文字列が応答 HTML の大きな割合を占める場合があります。WebLogic Portal の URL 圧縮メカニズムは、より短い URL を作成するプラグイン可能な手段を提供します。次に例を示します。
http://abc.com/webapp/portletEvents/activatePage/activatePage.portal?_nfpb=true&_windowLabel=pfTPC_source_1&pfTPC_source_1_actionOverride=%2FportletEvents%2FactivatePage%2FtoPage1
WebLogic Portal は、文字列をデータベースにマッピングすることによって URL 圧縮を実装します。Web アプリケーション レベルの設定を使用して、URL 圧縮を設定します。処理は GenericURL クラスを介して呼び出されます。
デフォルトのアルゴリズムでは、マッピング用に 2 つの p13n キャッシュ (wlp.urlCompression.compressed と wlp.urlCompression.expanded) が使用されます。これらのキャッシュは、framework-full-app ライブラリ モジュールの p13n-cache-config.xml にあります。
URL 圧縮を使用するように Web アプリケーションをコンフィグレーションするには、以下の手順に従います。
web.xml に圧縮サーブレットを定義します。
<servlet>
<servlet-name>UrlCompressionServlet</servlet-name>
<servlet-class>com.bea.portlet.compression.UrlCompressionServlet
</servlet-class>
<init-param>
<param-name>defaultPage</param-name>
<param-value>/index.jsp</param-value>
</init-param>
<init-param>
<param-name>errorPage</param-name>
<param-value>/errors/error.jsp</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>UrlCompressionServlet</servlet-name>
<url-pattern>wlp.c</url-pattern>
</servlet-mapping>
{url:compression} を追加します。
以下の節では、URL 圧縮を実装する際に特に考慮すべきいくつかの点について説明します。
URL 圧縮は、ポートレットの非同期表示に関連する、ページ更新のための AJAX 固有のメカニズムの一部を妨害します。このため、コンテンツの非同期表示が無効でページ更新が強制される場合は、必ず URL 圧縮を無効にする必要があります。WebLogic Portal では、ファイルのアップロード フォームが使用される場合を除き、URL 圧縮が自動的に無効になります。その場合は、URL 圧縮を明示的に無効にする必要があります。詳細については、『ポートレット開発ガイド』を参照してください。
URL 圧縮を正しく実装するには、ポータル開発者はベスト プラクティスを遵守し、サポートされている URL タグとクラスを使用して URL を生成する必要があります。
オフサイト URL は、URL を生成するコードの Web アプリケーションでホストされないリソースの URL です。 圧縮が有効化された Web アプリケーションでは、GenericURL、そのサブタイプ、または対応する JSP タグを使用してオフサイト URL を生成する場合は、圧縮を無効にした URL テンプレートを指定する必要があります。
GenericURL redirectURL = GenericURL.createGenericURL(request, response); redirectURL.setDomain("www.yahoo.com"); redirectURL.setPort(80); redirectURL.setPath("/compressedUrl/index.html"); redirectURL.setTemplate("no_compression_template");
ここで、「no_compression_template」は、{url:compression} 擬似トークンを除外する URL テンプレートの名前です。
コード内でアクセス頻度の高い URL を参照する場合、ベスト プラクティスは URL 圧縮を無効にすることです。URL 圧縮が有効になっていると、URL にアクセスするたびに新しいデータベース エントリが作成されます。アクセス頻度の高い URL の場合、パフォーマンスの問題が発生するおそれがあります。
ページ フローまたは JSP で URL ごとに URL 圧縮を無効にするには、WEB-INF/beehive-url-template-config.xml ファイルに非圧縮テンプレートを追加する必要があります。これで、コード内でこのテンプレートを参照できるようになります。
たとえば、次の JSP はデータベース内のエントリを増加させます。この JSP が表示されるたびに、リンクが押されたかどうかに関係なく、データベース内に新しいエントリが作成されます。
<%
String value = String.valueOf(System.currentTimeMillis());
%>
<render:postbackUrl var="url">
<render:param name="name" value="hello" />
<render:param name="value" value="<%=value%>" />
</render:postbackUrl>
<a href="${url}">Post current time</a> url:${url}<p/>
この状況を改善するには、コード リスト 7-2 に示すように、WEB-INf/beehive-url-template-config.xml に URL 圧縮を使用しない新しいテンプレートを追加します。
<url-template>
<name>defaultNoCompression</name>
<value>{url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString}{url:currentPage}</value>
</url-template>
非圧縮テンプレートを追加したら、コード リスト 7-3 に示すように、このテンプレートを JSP 内の postbackURL に追加します。この例では、URL は圧縮されません。
<render:postbackUrl var="noCompressionUrl" template="defaultNoCompression">
<render:param name="name" value="hello" />
<render:param name="value" value="<%=value%>" />
</render:postbackUrl>
<a href="${noCompressionUrl}">Post current time</a> url:${noCompressionUrl}
プロキシ サーバを使用したり、非セキュアなポートとセキュアなポートの間で切り替えているとき、{url:port} または {url:securePort} 変数を使用している場合は URL が解決されないことがあります。これは、その値に対する変数がリクエストから読み込まれるためです。たとえば、非セキュアなポート (ポート番号 80) にいるユーザが {url:securePort} 変数を使用する URL テンプレートで作成されたセキュアな https リンクをクリックすると、request (80) というポート番号が {url:securePort} 変数に対して使用されますが、これは非セキュアなポートでセキュア リクエスト (https) を作成します。プロキシ サーバ (ポート 80) にいるユーザがプロキシ サーバ (ポート 443) の外にあるリソースへのリンクをクリックした場合も同様です。
どちらの場合も、正しく解決される URL を取得するように、URL テンプレートにポート番号をハード コーディングする必要があります。
beehive-url-template-config.xml ファイルは、すべてのポータル Web プロジェクトに (J2EE 共有ライブラリを介して) 自動的に組み込まれます。このファイルには、コンシューマでの URL の書き換えをサポートするために必要な URL テンプレートが含まれています。Web アプリケーションを WSRP プロデューサとして使用することを予定している場合は、これらの URL テンプレートや変数を beehive-url-template-config.xml ファイルから削除しないでください。
WebLogic Portal は、WebLogic Portal が生成した URL の形式をコンフィグレーションするために、Beehive コンフィグレーション ファイル beehive-url-template-config.xml を使用します。アンパサンド エンティティ (&) またはアンパサンド文字 (&) を使用するための Beehive コンフィグレーション要素は、NetUI コンフィグレーション ファイル (beehive-netui-config.xml) にあります。HTML コンフィグレーションでは、アンパサンド文字を使用するように指定するコンフィグレーション要素がないときは、デフォルトでアンパサンド エンティティを使用して URL が生成されます。
XHTML コンフィグレーションでは、コンフィグレーション設定にかかわらず、URL にアンパサンド エンティティが使用されます。
GenericURL クラスの useAmpEntity メソッドおよび setForcedAmpForm メソッドを使用して、手動でコンフィグレーション設定をオーバーライドできます。これらのメソッドの詳細については、Javadoc を参照してください。
WebLogic Portal の以前のリリースが URL 内のアンパサンドをどのように処理するかについては、「ポータル URL 内のアンパサンド」を参照してください。
WebLogic Portal のルック アンド フィールでは、次の 2 つの条件下で、リソース (CSS、JavaScript、画像など) のパスに ResourceURL (つまり、URL リライタ) を使用します。
ルック アンド フィールのリソースに固有の URL テンプレートは、「lookandfeel-url-templates」というリファレンス グループで指定できます。このグループには、「laf-resource」キーまたは「window-resource」キーのいずれか、またはこの両方を含める必要があります。「laf-resource」キーは、スキンまたはスケルトンに関連するリソースに使用し、「window-resource」キーは、ウィンドウの依存関係に関連するリソースに使用します。対応する URL テンプレートの「{url:path}」パラメータを置き換えるには、解決済みの (相対) リソース パスを使用します。以下に、URL テンプレートの構文例として、beehive-url-template-config.xml ファイルの一部を示します。
<url-template>
<name>laf-resource-template</name>
<value>http://my.domain.com/resources/laf/{url:path}</value>
</url-template>
<url-template-ref-group>
<name>lookandfeel-url-templates</name>
<url-template-ref>
<key>laf-resource</key>
<template-name>laf-resource-template</template-name>
</url-template-ref>
</url-template-ref-group>
ルック アンド フィールの URL テンプレートがない場合、ルック アンド フィールのリソース パスは相対パスのままになります。ただし、例外が 1 つあります。リモート ポートレットのコンテキスト内でパスが生成された場合、そのパスは標準の「リソース」URL テンプレートを使用します。
オプションの LookAndFeel URL テンプレートを使用すると、リソースを別のサーバに「オフロード」できます。ただし、このようなリソースは、(移動ではなく) コピーし、ポータル Web アプリケーションと同じ相対リソース パス (例 : .../framework/skins/bighorn/css/book.css) を含む URL を使用して必ず解決できるようにする必要があります。ルック アンド フィールのパスの解決は、リソースへのローカル ファイル システムのアクセスに引き続き依存します。
render taglib の GetSkinPath タグは、オプションのルック アンド フィール URL テンプレートの影響を受けることはありません。このタグによって生成されたパスは、どの場合でも相対パスになります。
この節では、HTTP 応答にエンコーディングを設定する方法について説明します。
WebLogic Portal は、.portal ファイルの情報に基づいて、次のエンコーディング設定方法を使用します。
encoding 属性の netuix:desktop 要素を調べ、要素がある場合はその値を使用する。directive.page 要素の .portal ファイルを調べる。このメカニズムは推奨されていません。この要素が存在する場合は、属性からエンコーディングを選択します。<defaultEncoding> 要素に対して netuix-config.xml を調べ、encoding 属性を使用する。web.xml ファイルの <jsp-param> セクションにある <encoding> 要素を使用する。このメカニズムは推奨されていません。
この実装は、WebLogic Portal の以前のバージョンの実装とは異なります。詳細については、『WebLogic Portal 10.0 へのアップグレード』の機能の変更に関する付録を参照してください。
.portal ファイルの <netuix:desktop ... encoding="UTF-8" />
netuix-config.xml ファイルの <defaultEncoding encoding="UTF-8" />
キャッシュを正しくコンフィグレーションすれば、頻繁に使用するデータの検索にかかる時間を大幅に短縮できます。Workshop for WebLogic を使用して、現在実行しているインスタンスの既存のキャッシュの設定を変更したり、キャッシュをフラッシュしたりできます。キャッシュをコンフィグレーションするときは、パラメータを修正してキャッシュの動作または容量を変更します。たとえば、最新の 200 エントリのみ保持するようにキャッシュを設定したり、キャッシュに残す時間 (ミリ秒単位) を設定したりできます。また、キャッシュをフラッシュし、新しく要求された情報はすべてデータベースから取得するようにすることもできます。
Workshop for WebLogic のユーザ インタフェースを使用して、新しいキャッシュを追加することはできません。ただし、EAR プロジェクトのコンテンツ ディレクトリ (デフォルトの名前は EarContent) 内にあるキャッシュ コンフィグレーション ファイル META-INF/p13n-content-config.xml を手動で編集して、キャッシュを追加することができます。必要な場合は、マージ済みプロジェクト ビューからプロジェクトにキャッシュ ファイルをコピーすることもできます。
Workshop for WebLogic を使用して行ったキャッシュの変更は永続的に保持されず、次回アプリケーションを公開したとき、またはサーバを再起動したときに失われます。変更を永続的に保持するには、WebLogic Portal Administration Console を使用します。
| 注意 : | この節で説明する手順を実行する前に、サーバを稼働させる必要があります。 |
Workshop for WebLogic でキャッシュ設定を変更するには
各キャッシュの詳細については、そのキャッシュに関連する特定の機能のドキュメントを参照してください。たとえば、パーソナライゼーション関連のキャッシュについては、『対話管理ガイド』を参照してください。
管理対象サーバ上でポータル アプリケーションを実行している場合は、以下の例に示すように web.xml ファイルの <context-param> パラメータを使用すると、WebLogic Server Administration Console のパフォーマンスを向上させることができます。
<context-param>
<param-name>portalFileDirectory</param-name>
<param-value>/</param-value>
</context-param>
このパラメータは、EAR コンテンツ情報を返す最適化された呼び出しを利用します。このパラメータがないと、呼び出しは .portal ファイルを再帰的に検索します。このパラメータを使用する場合、すべての .portal ファイルをポータル Web アプリケーションの同じディレクトリに配置する必要があります。<param-value> を使用してディレクトリを指定します。上記の例では、すべての .portal ファイルが、Web アプリケーションのルート ディレクトリ (/) にあります。
移動先 URL の対象であるブックの [デフォルト ページに戻る] 属性が true に設定されている場合、そのブックのデフォルト ページが表示されるはずです。ただし、動作が予期したとおりに行われない場合があります。この節の目的は、このような動作を明確にすることです。
この節では、ブックがネストされていて、メイン ブックの直接の子がブックである場合のみを対象とします。[デフォルト ページに戻る] は、ブック間の移動にのみ適用され、ブック内の移動には適用されません。次に、各ページにブック 2 への URL が設定されたポートレットを含む単純なポータルの階層を示します。
ブック 2 - デフォルト ページに戻る = true、デフォルト ページ = ページ 2
このポータルを表示すると、ブック 2 とページ 2 が表示されます。
ページ 2 がブック 2 のデフォルトであるため、これは想定されたとおりの動作であり、ブック 2 の最後のアクティブなページはページ 3 です。
このポータルを表示すると、ブック 2 とページ 2 が表示されます。
これは、ページ 3 が同じブック内にあり、デフォルトに戻る設定が適用されないために発生します。
次のようにメイン ブックの子がページである階層では、デフォルトに戻る設定は適用されません。
ブック 2 - デフォルト ページに戻る = true、デフォルト ページ = ページ 2
この階層では、ユーザはブック 2 の最後のアクティブなページに戻ります。
コマース関連機能を追加せずにポータル EAR プロジェクトやポータル Web プロジェクトを作成した場合は、コマース関連ファセットをプロジェクトに追加して、後でその機能を有効化できます。
| 注意 : | コマース API およびライブラリ モジュールは、WebLogic Portal 10.0 では推奨されていません。この API は、WebLogic Portal とは別の製品として用意されている BEA Commerce Services に置き換えられています。 |
コマース機能に直接関連付けられた J2EE 共有ライブラリは、表 7-8 に表示されます。
コマース機能をポータル アプリケーションに追加するには、以下の手順を実行します。
図 7-13 にコマース ファセットを示します。
図 7-14 にコマース ファセットを示します。
コマース サービスの技術的な詳細については、com.bea.commerce.* および com.beasys.commerce.* パッケージの Javadoc を参照してください。
| 注意 : | コマース API は、WebLogic Portal 10.0 では推奨されていません。この API は、別の製品として用意されている BEA Commerce Services に置き換えられています。 |
Workshop for WebLogic ではエラー、警告および情報メッセージを問題ビューに表示します。WebLogic Portal 検証フレームワークは、Eclipse platform の Web Standard Tools フレームワークに基づいて作成されています。
Workshop for WebLogic では、グローバルかプロジェクト単位で検証を有効化または無効化することができます。
ワークスペースですべてのプロジェクトの検証を有効化または無効化するには、以下の手順に従います。
図 7-15 に [検証] ダイアログを示します。
![[検証] ダイアログ](wwimages/validation-1.gif)
プロジェクトの検証を有効化または無効化するには、以下の手順に従います。
エラーの重大度、警告、および情報メッセージは Workshop for WebLogic でマップして報告することができます。この節では、検証マッピングをグローバルおよびプロジェクト単位でカスタマイズする方法を説明します。
WebLogic Portal 検証フレームワークで確認されるポータル コードの主な領域には、以下のようなものがあります。
通常、プロジェクト内にエラーが発生すると、Workshop for WebLogic はアプリケーションのデプロイを防止します。この問題を無視して、アプリケーションのデプロイを優先する場合もあります。または、デプロイ済みアプリケーションの中で警告が許可されないポリシーが存在する場合があります。このような場合、デプロイを防止するために、エラーとして警告をフラグする方法をとることも選択できます。特定の問題に関連したメッセージを有効化または無効化できなくても、問題の種類の重大度をマップして報告する方法を変更することができます。
ワークスペースですべてのプロジェクトの検証をカスタマイズするには、以下の手順に従います。
| ヒント : | インクリメンタル ビルドを行う場合、関連ファイルの検証を許可するために、[Verify related files on incremental builds] チェック ボックスを選択します。ポータル web アプリケーション内のブックのようなポータル リソースをコピーする場合、この機能が役に立ちます。元のファイルと複製ファイルで報告された定義ラベルの重複に関連する検証エラーが表示されます。重複定義ラベルを変更すると、インクリメンタル ビルド上の変更されたファイルのみが検証されます。元のファイルには検証のエラーがそのまま残ります。[Verify related files on incremental builds] を選択すると、新たに変更されたファイルと元のファイルの両方が検証され、元のファイル上の検証エラーが消去されます。 |
特定プロジェクトですべてのプロジェクトの検証をカスタマイズするには、以下の手順に従います。
| 注意 : | プロジェクト レベルの設定は、グローバル設定よりも優先されます。 |
  
|
