www.bea.com code library downloads support.bea.com BEA logo

WebLogic Portal ベスト プラクティス ガイド

 前 次 目次

開発の方法

 


WebLogic Portal 8.1 の開発

この節では、開発者が WebLogic Portal Platform Edition を使用する際に多く遭遇する問題について、そのガイドラインと解決策をいくつか紹介し、以下の内容を説明します。

分割コンフィグレーションについて

WebLogic Portal は、サーブレットと EJB コンテナが別々のサーバ インスタンスで実行される分割コンフィグレーションをサポートしません。

カスタム アプリケーションへの訪問者ツールの追加

WebLogic Portal Platform Edition をインストールすると、あらかじめ作成された sampleportal というポータル アプリケーションが一緒にインストールされます。このポータル アプリケーションには、訪問者がポータルのパーソナライズされたビューのプロパティを設定できるようにする一連の JSP などが含まれています。以下の手順を実行することにより、このような訪問者ツールを新しいポータル アプリケーションに追加し、カスタマイズすることができます。

  1. ネイティブのファイル システムで以下のディレクトリをすべてコピーします。
  2. WebLogic Workshop Platform Edition で、新しいポータル アプリケーションを開きます。
  3. Portal Designer でメイン ブックを選択します。
  4. 図 0-1 メイン ブックの選択


     
  5. Properties Designer で、メニューの [編集] に [編集可能] プロパティを設定します。使用可能なプロパティに [モード プロパティ] のヘッダが追加されます。
  6. [コンテンツ URI] をクリックして、/visitorTools/visitorTools.portion ファイルを参照します。
  7. このポータルを (開発モードではなく実際のデスクトップで) 実行すると、メイン ブックに [編集] アイコンが表示されます。このアイコンをクリックすると、訪問者ツールが表示されます。

注意 : 訪問者ツールの JSP は、ポータル サーバが実行されている場合にのみ使用可能です。また、この JSP にはデスクトップにログインしたユーザがアクセスする必要があります。

ユーザを認証する

PortalServletFilter により、セッションで正しいユーザ プロファイルが確実にコンフィグレーションされるため、カスタム コードを作成する必要はありません。

<um:login>

デフォルトでは、このタグは、ユーザのログイン後の処理を担当します。これは、ユーザを認証し、セッションのプロファイルをユーザのプロファイルに更新し、UserRegistrationEvent を発生させる処理です。また、PortalServletFilter は、ユーザが別の方法 (フォームベース、j_security_check、ServletAuthentication.weak() など) で認証された場合に、その次のリクエストにおけるユーザのログイン後の処理を担当します。

<um:createUser>

デフォルトでは、このタグは、ユーザ登録後の処理を担当します。これは、匿名プロファイルのプロパティをユーザのプロファイルに保存し、ユーザをログインし (ユーザを認証し、セッションのプロファイルをユーザのプロファイルに更新し、SessionLoginEvent を発生させる)、UserRegistrationEvent を発生させる処理です。

匿名ユーザ プロファイルを使用する

匿名ユーザ プロファイルは非常に便利です。匿名ユーザ プロファイルにはプロパティを設定します。ユーザ ベースのすべての機能 (<pz:div>、<pz:contentSelector>、<ph:placeholder> など) を匿名プロファイルに対して使用できるため、このような機能のためにログインを要求する必要はありません。これらのプロパティは、<um:createUser> を介してユーザ プロファイルに保持されます。自主登録ページを作成する場合は、<um:createUser> を呼び出す前に <um:setProperty> を使用して (匿名) プロファイル内のすべてのプロパティを設定することをお勧めします。この方法は、ユーザを作成してからプロパティを設定するより簡単で、SessionLoginEventandUserRegistrationEvent が発生する前にユーザのプロファイルに確実にプロパティが設定されます。

コンテンツ プレースホルダ

コンテンツ プレースホルダは、ユーザ、リクエスト、およびセッションのプロパティを参照するクエリをサポートするようになりました。これにより、カスタマイズしたクエリをユーザのプレースホルダに追加するためだけにキャンペーンを使用する必要がなくなります。さらに、<cm:search> および <pz:contentQuery> のコンテンツ検索クエリでも、ユーザ、リクエスト、およびセッションのプロパティを参照できます (" color = userProperty('myPropSet', 'favoriteColor') " など)。

ページ フローとポートレット

ページ フローを使用する場合は、JSP 内で href を使用しないことをお勧めします。代わりに、action を使用します。これには、アクションをフローにドラッグして「doClientRequest」などの名前を付けます。ここから参照先のページにリンクし、フローが図 1-2 のようになるようにします。

図 0-2 ページ フロー 1


 

別ページ (図 1-2 の index.jsp) を呼び出す JSP で、JSP を開いてアンカー タグを編集します。図 1-3 に示すように、アンカー タグを href から action に変更します。

図 0-3 ページ フロー 2


 

プロセッサ

リクエストにデータを追加するプロセッサ (Webflow 内で使用されるようなもの) を作成する必要がある場合は、ページの更新を考慮に入れる必要があります。たとえば、プロセッサがデータを取得してリクエスト内に格納し、その後 JSP がリクエスト内のこのデータを読み込んで情報を表示する場合、マスター Webflow の lastContenturl へのイベント更新リンクは、入力プロセッサによってリクエスト内に格納されたデータを失います。

ページ フローとポートレット」の節でも説明されているように、ページ フローには HREF を使用しないでください。更新イベント (ポートレット Webflow の標準イベントの 1 つ) に対しては、入力プロセッサや Pipeline コンポーネントを呼び出すことができます。こうすると、JSP からデータが使用できるようになります。

「出力データ」をセッション スコープでパイプライン セッションに格納する Pipeline コンポーネントを作成することができますが、このようなパイプラインは設計パターンとして柔軟性を欠く場合があります。これは、パイプラインからはプレゼンテーションの状態がわからないことによります。表示するデータは Webflow (入力プロセス) によって準備されるため、データをセッション スコープで保持する (例 : 更新後に表示データを保持する) タイミングも、入力プロセッサで判断されるべきです。

多少のオーバーヘッドはありますが、出力データが「内部」状態のものでなければ、Pipeline コンポーネントがリクエスト スコープで出力データを書き込み、Pipeline と Webflow の間のアクセスが (Pipeline セッション) リクエストになるようにすることをお勧めします。この方法は、移植と再利用のしやすいポータル コンポーネントの作成に役立ちます。また、セッション スコープで保持されているデータを積極的に維持して、セッションの「メモリ リーク」を防止し、クラスタ レプリケーションのオーバーヘッドを削減することもお勧めします。

モバイル デバイス用のさまざまなコンテンツへの対応

ポータルにアクセスできる Web 対応のモバイル デバイスには多くのタイプがあります。このようなデバイスのインタフェースや表示領域のサイズはさまざまであるため、各デバイスで表示されるコンテンツのタイプには独自の要件があります。

WebLogic Workshop Portal Extensions で提供されるマルチチャネル フレームワークを使用すると、ポータルを拡張してモバイル デバイスのアクセスにも対応するようにできます。この柔軟なフレームワークにより、各種 Web 対応デバイスにシームレスかつ同時にコンテンツを提供する単一のポータルを作成できます。また、Mozilla、Netscape、Opera、Internet Explorer などの多様なブラウザにさまざまなコンテンツを提供できます。

マルチチャネル フレームワークでは、特定のデバイスに固有のコンテンツとルック アンド フィール要素を作成できます。デバイスがポータルにアクセスすると、ポータルはそれがどのような種類のデバイスかを認識し、そのデバイス用に作成したコンテンツを自動的に提供します。

デバイス (PC またはハンドヘルド) は、ポータルにアクセスすると、デバイスは自身についての情報を HTTP ヘッダに格納してポータルに送信します。このような情報には、使用しているブラウザのタイプやデバイスのタイプなどがあります。このような情報の組み合わせによって、「クライアント」、つまりデバイスのモデルが定義されます。また、クライアントは「分類」にグループ化できます。たとえば、Palm ハンドヘルド デバイスには多くのモデルがありますが、それらはすべて「Palm」という分類に属します。分類は、ポータルのマルチチャネル サポートを可能にするうえで重要な要素です。

図 1-4 は、マルチチャネル フレームワークと、モバイル デバイス用のコンテンツおよびプレゼンテーションの構築手順を示しています。この図には注釈があり、以下に番号順に説明されています。

図 0-4 マルチチャネル リクエストのサイクル


 
  1. デバイスが URL を持つポータル対応サーバにアクセスする場合、デバイスはクライアントの種類を示すユーザ エージェント文字列を HTTP ヘッダに格納して送信します。サーバは、このユーザ エージェント文字列をポータル アプリケーションの「User-Agent」リクエスト プロパティに格納します。
  2. 「User-Agent」リクエスト プロパティは、WebLogic Workshop Platform Edition で作成するすべてのポータル アプリケーションに自動的に含まれます。このプロパティを表示するには、WebLogic Workshop でファイル <PORTAL_APP>¥data¥request¥DefaultRequestPropertySet.req を開きます。

    ポータル開発者のタスク : なし。この処理は自動的に実行されます。

  3. デバイスのマルチチャネル サポートを有効にするには、「User-Agent」プロパティに格納されたユーザ エージェント文字列をポータル Web プロジェクトで分類にマップできなければなりません。このマッピングは、ポータルがモバイル デバイスからアクセスされる前に作成する必要があります。
  4. ポータル開発者のタスク : ポータル Web プロジェクトの WEB-INF¥client-classifications.xml ファイルで、クライアントを分類にマップする必要があります。デフォルトの client-classifications.xml ファイルには、デフォルトのクライアント マッピングが含まれています。

    分類にマップされるクライアント エントリごとに、デバイスから送信される内容どおりにマップされた明示的なユーザ エージェント文字列か、複数のユーザ エージェント文字列に対応する正規表現を入力できます。

    以下の client-classifications.xml のクライアント分類マッピングの例は、明示的なマッピング (<useragent> タグを使用) と正規表現のマッピング (<useragent-regex> タグを使用) を示しています。

    <classification name="pocketpc" description="For the PocketPC">
    <useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240x320)"/>
    <useragent value="Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320)"/>
    <useragent-regex value=".*PDA; Windows CE.*NetFront/3.*" priority="1"/>
    </classification>

    明示的な <useragent> の値は、1 つの分類に対してのみ使用できます。複数の <useragent-regex> タグを使用して、正規表現でマップを実行する場合は、ポータルにアクセスするデバイスが複数の分類にマップされる可能性があります。デバイスがマップされる分類を決定するには、上記のように priority 属性を使用します。値「1」は最高の優先順位を示します。優先順位の値には、任意の整数を入力します。

注意 : クライアント分類を割り当てられたポートレットの場合、WebLogic Administration Portal では、分類の「description」の値を使用してそのポートレットに割り当てられた分類を表示します。ポータル管理者にわかりやすい説明を入力してください。

  1. 定義した client-classification.xml のマッピングにより、「User-Agent」プロパティに格納されたユーザ エージェント文字列が指定の分類名にマップされます。上記のマッピング例では、名前は「pocketpc」です。
  2. ポータル開発者のタスク : なし。この処理は自動的に実行されます。

  3. クライアントが正常に分類にマップされると、DefaultRequestPropertySet の「Client Classification」プロパティに分類名が格納されます。
  4. ポータル開発者のタスク : なし。この処理は自動的に実行されます。

  5. DefaultRequestPropertySet に格納された分類名は、デバイスに合わせたコンテンツとプレゼンテーションを識別するためにポータル フレームワーク全体で使用されます。
  6. ポータル開発者のタスク : ポータルは、さまざまなデバイスが使用する固有のコンテンツやプレゼンテーションを開発し、使用できるようにする場所です。ポータル フレームワークには、デバイス固有のコンテンツとプレゼンテーションを作成する以下の基本機能があります。

    ポートレット開発 - WebLogic Workshop Portal Extensions を使用してポートレットを開発すると、さまざまなデバイス (クライアント分類) で使用するポートレットを割り当てることができます。Portlet Designer でポートレットを開いた状態で、[プロパティ エディタ] ウィンドウで以下を実行します。

    1. [クライアント分類] フィールドの省略符号アイコン [...] をクリックして、[ポートレット分類の管理] ダイアログ ボックスを開きます。
    2. ダイアログ ボックスで、ポートレットの分類を有効にするかどうかを選択します (分類を無効にした場合、ポートレットは無効として選択されていない分類について自動的に有効になります)。
    3. 有効/無効にする分類を、[選択可能な分類] リストから [選択済みの分類] リストに移動し、[OK] をクリックします。client-classifications.xml ファイルから分類のリストが読み込まれます。

    JSP タグ - WebLogic Workshop Portal Extensions には、JSP にインラインで埋め込むデバイス固有のコンテンツを作成するための JSP タグ セットが含まれています。JSP タグで定義されたデバイスの条件に合ったコンテンツのみがデバイスに配信されます。

    JSP タグには、JSP コンテンツを分類にマッピングするために必要な「client」属性があります。JSP タグの client の値には、client-classification.xml ファイルで使用されている値と同じ値 (DefaultRequestPropertySet の「Client Classification」プロパティに格納されている値) を使用する必要があります。

    ルック アンド フィール開発 - WebLogic Workshop Portal Extensions に付属のルック アンド フィール (スキンとスケルトン) は、いくつかのモバイル デバイス (Nokia、Palm、および PocketPC) をサポートします。このようなスキンとスケルトンは、ポータル Web プロジェクト内にメインのスキンおよびスケルトンのサブ ディレクトリとして含まれています。たとえば、PocketPC のスキンは、「デフォルト」のスキンの一部として、<project>¥framework¥skins¥default¥pocketpc に入っています。

    また、独自のスキンとスケルトンを開発して、さまざまなデバイスをサポートすることもできます。デスクトップにルック アンド フィールを選択すると、ポータル フレームワークは DefaultRequestPropertySet の「Client Classification」プロパティを読み込み、そのルック アンド フィールのロジックを使用してクライアント分類の名前に一致するスキンとスケルトンのディレクトリを検索します。

    対話管理開発 - DefaultRequestPropertySet の「Client Classification」プロパティに格納されているクライアント分類名を使用して、プロパティの値を基に各デバイスのパーソナライゼーションとキャンペーンを構築および実行できます。

  7. HTTP リクエスト内のユーザ エージェント (クライアント) 文字列と分類名を照合するために設定したマッピングを基に、ポータルにアクセスするさまざまなデバイスに対して、開発したデバイス固有のコンテンツとプレゼンテーションが送信されます。
  8. ポータル開発者のタスク : なし。この処理は自動的に実行されます。

マルチチャネル機能のサンプル

WebLogic Workshop Portal Extensions に付属のポータル サンプルの 1 つであるチュートリアル ポータルには、マルチチャネル機能のサンプルが含まれています。また、ポータル Web プロジェクトを作成すると、WEB-INF¥client-classifications.xml ファイルがデフォルトの設定で自動的に作成されます。

作成するすべてのポータル Web プロジェクトには、マルチチャネルのルック アンド フィールのデフォルト セットも含まれます。このセットは、スキンとスケルトンのサブディレクトリ (<project>¥framework¥skins および <project>¥framework¥skeletons) に入っています。

ルック アンド フィール要素の操作

この節では、ルック アンド フィール要素を作成して実行時のポータルのプレゼンテーションを変更する方法を説明します。これらの要素の組み合わせが動作するしくみについては、『WebLogic Portal 8.1 へのアップグレード』の「プレゼンテーション フレームワーク」の節を参照してください。

ルック アンド フィール ファイル

ルック アンド フィールは、簡単な XML ファイルで記述されます。このファイルにより、ルック アンド フィールに使用するスキンとスケルトンが決定されます。ルック アンド フィール ファイルを作成するときには、ポータル デスクトップの Portal Designer で新しいルック アンド フィールを選択できます。

以下のトピックでは、ルック アンド フィールのアーキテクチャと、ポータルでルック アンド フィールを作成および使用する方法について説明します。

ルック アンド フィール ファイルを作成する

  1. WebLogic Workshop でポータル アプリケーションを開いた状態で、[アプリケーション] ウィンドウを使用して、既存のルック アンド フィール ファイル <project>¥framework¥markup¥lookandfeel¥*.laf を開きます。
  2. [ファイル|名前を付けて保存] を選択し、ファイルの名前を変更します。拡張子 .laf を必ず付け、このファイルを他のルック アンド フィール ファイルと同じディレクトリに保存します。
  3. <netuix:lookAndFeel> 要素の属性、definitionLabel、title、description、および markupName の値を、対象のルック アンド フィールの名前に変更します。各ルック アンド フィールには、ユニークな markupName が必要です。markupType の値は変更しないでください。
  4. skin 属性の値には、使用するスキンのディレクトリ名を入力します。
  5. skinPath 属性の値には、使用するスキンの親フォルダまでの相対パス (プロジェクト フォルダを基準とする) を入力します。
  6. たとえば、スキンを作成して <project>/framework/skins/modern (スキン名は「modern」) に保存した場合、skin 属性は以下のようになります。

    skin="modern" skinPath="/framework/skins/"

    /framework/skins/ パスは、ポータル フレームワークで使用されるデフォルト パスです。skinPath の値を入力しなければ、デフォルト パスが使用されます。

  7. skeleton 属性の値には、使用するスケルトンのディレクトリ名を入力します。
  8. skeletonPath 属性の値には、使用するスケルトンの親フォルダまでの相対パス (プロジェクト フォルダを基準とする) を入力します。
  9. たとえば、スケルトンを作成して <project>/framework/skeletons/modern (スケルトン名は「modern」) に保存した場合、skeleton 属性は以下のようになります。

    skeleton="modern" skeletonPath="/framework/skeletons/"

    /framework/skeletons/ パスは、ポータル フレームワークで使用されるデフォルト パスです。skeletonPath の値を入力しなければ、デフォルト パスが使用されます。

    多くの場合、<project>/framework/skeletons/default に格納された「デフォルト」のスケルトンを使用します。

    skeleton 属性を指定しない場合は、skin.properties ファイルで識別されるスケルトンが使用されます。「スキンキンとスキン テーマの作成」を参照してください。

  10. また、defaultWindowIcon および defaultWindowIconPath 属性を設定することにより、ポートレットのタイトルバーで使用されるデフォルトのアイコンも設定できます。たとえば、使用するアイコンが <project>/images/window-icon.gif である場合、これらの属性は次のように設定します。
  11. defaultWindowIcon="window-icon.gif" defaultWindowIconPath="images/"

  12. ファイルを保存します。
  13. ポータル用のルック アンド フィールを使用するには、WebLogic Workshop Platform Edition でポータルを開き、[ドキュメント構造] ウィンドウの [デスクトップ] アイコンを選択して、プロパティ エディタの [ルック アンド フィール] フィールドでルック アンド フィールを選択します。
  14. Portal Designer でデスクトップ用のルック アンド フィールを選択すると、ポータルにはデフォルトのルック アンド フィール設定が割り当てられます。ポータルの管理者およびユーザは、デスクトップに使用するルック アンド フィールを変更できます。

    ルック アンド フィールを適切に動作させるには、スキンとスケルトンを正しく作成および格納することが重要です。具体的には、スキンとスケルトンのプロパティ ファイルにすべての必要なパスを記述して正しく設定し、有効な スケルトン JSP を使用し、スキン リソース (画像、CSS ファイル、JavaScript ファイルなど) をスケルトン ファイルで正しく参照できるようにする必要があります。たとえば、ポートレットのタイトルバー用アイコンに正しいグラフィック名を使用する必要があります。

スキンとスキン テーマの作成

スキンは、ボタンのグラフィック、テキスト スタイル、マウスオーバー アクションなどのポータルの外観を定義する、グラフィック、カスケーディング スタイル シート (CSS)、および JavaScript の動作です。スキンとスケルトンの組み合わせにより、ポータル デスクトップのルック アンド フィールが決定されます。ポータル デスクトップのルック アンド フィールを選択すると、そのルック アンド フィールは使用するスキンとスケルトンを指し示します。

スキンは、親スキン ディレクトリに格納されたグラフィック、CSS ファイル、および JavaScript ファイルを 1 つにまとめたものです。スキンは必要なだけ作成できます。また、スキンには、モバイル デバイス固有のスキン用のサブディレクトリを含めることができます。

スキンには、テーマも含めることができます。スキン テーマは、グラフィック、CSS スタイル、または JavaScript の動作のサブセットで、ブック、ページ、およびポートレットで使用して、その外観を他のポータル デスクトップと異なるようにすることができます。

スキンを作成する

  1. WebLogic Workshop Platform Edition でポータル アプリケーションを開いた状態で、ポータル Web プロジェクトの既存のスキン ディレクトリを複製します。たとえば、<project>¥framework¥skins¥default を右クリックして [複製] を選択します。
  2. 名前の末尾に数字が付加された新しいスキン ディレクトリが表示されます。

  3. 新しいスキン ディレクトリの名前を変更します。
  4. 使用する予定のないサブディレクトリがあれば、削除します。
  5. images サブディレクトリで、必要に応じてボタンのアイコンを変更します。ファイルの名前は変更しないでください。ファイル名は、スケルトン JSP およびクラス ファイルでボタンの表示に使用されます。
  6. css サブディレクトリで、必要に応じて CSS ファイルを変更します。CSS ファイルのスタイル名は変更しないでください。スタイル名は、スケルトン JSP やレイアウト ファイルなどでスタイルの表示に使用されます。
  7. モバイル デバイスでマルチ レベル メニューをサポートするには、book.css ファイルで display: none; と表示された行を削除します。

  8. js サブディレクトリで、必要に応じて JavaScript を変更します。
  9. スキンにはビジネス ロジックを組み込まないでください。ビジネス ロジックには別の JSP を作成し、それらの JSP をポータル シェル (デスクトップのヘッダまたはフッタの場合) またはポートレットに格納します。

  10. ルート スキンおよびすべてのサブ スキン用の skin.properties ファイルを変更します。
  11. skin.properties ファイルには、イメージ、テーマ、スタイルシートのリンク、JavaScript のスクリプト エントリ、スケルトンの依存関係などの情報が含まれます。このファイルは自己記述型であるため、ファイルの変更処理はガイドに従って実行します。

    参照は、ポータルが表示されるときに HTML ヘッダに挿入されるため、すべての参照を skin.properties に入力することが重要です。参照が欠けていると、スキンは正しく表示されません。

  12. ルック アンド フィール ファイルを開くか作成して、スキンをルック アンド フィールに関連付けます。「ルック アンド フィール ファイルの作成」を参照してください。
  13. ポータル用のスキンを使用するには、WebLogic Workshop Platform Edition でポータルを開き、[ドキュメント構造] ウィンドウの [デスクトップ] アイコンを選択して、プロパティ エディタの [ルック アンド フィール] フィールドでルック アンド フィールを選択します。

Portal Designer でデスクトップ用のルック アンド フィールを選択すると、ポータルにはデフォルトのルック アンド フィール設定が割り当てられます。ポータルの管理者およびユーザは、デスクトップに使用するルック アンド フィールを変更できます。

スキン テーマを作成する

テーマは、スキンとスケルトンで共有される 1 つの .theme ファイルで表されます。たとえば、ポートレット用に「alert」というテーマを選択すると、ポータル フレームワークは「alert」というスキンおよびスケルトンのサブディレクトリを検索します。テーマがすでに存在しているため、テーマのスキンのみを作成する場合は、以下の手順 5 から始めてください。

  1. WebLogic Workshop Platform Edition でポータル アプリケーションを開いた状態で、ポータル Web プロジェクトの既存のテーマ ファイルを複製します。たとえば、<project>¥framework¥markup¥theme¥alert.theme を右クリックして [複製] を選択します。
  2. 名前の末尾に数字が付加された新しいテーマ ファイルが表示されます。

  3. 新しいテーマ ファイルの名前を変更します。拡張子 .theme は必ずそのままにしてください。
  4. 新しいテーマ ファイルを開いた状態で、<netuix:theme> 要素の属性、name、title、description、および markupName を変更します。title 属性は、ドロップダウン メニューでテーマを選択するための名前になります。markupName は、テーマの中でユニークである必要があります。
  5. テーマ ファイルを保存します。
  6. スキン ディレクトリにテーマと同じ名前のサブディレクトリを作成します。
  7. 適切なスキンのディレクトリとファイルを既存のスキンから新しいテーマ ディレクトリにコピーします。
  8. スキン テーマ内のスキン ファイルを変更します。ファイル名は変更しないでください。
  9. テーマを使用するスキンに新しいテーマを関連付けます。各スキンの skin.properties ファイルで、以下の作業を行います。
    1. ファイルの「THEME IMAGES DIRECTORIES」セクションのテーマを参照する。
    2. テーマにユニークなスタイルシートが含まれている場合は、ファイルの「LINK ENTRIES」セクションでそれらのスタイル シートを参照する。
    3. テーマにユニークなスクリプトが含まれている場合は、ファイルの「SCRIPT ENTRIES」セクションでスクリプトを参照する。
  10. skin.properties ファイルを保存します。
  11. スキン テーマの skin.properties ファイルを変更します。
  12. スキン テーマのディレクトリをサブディレクトリとして他のスキン ディレクトリにコピーします。

使用可能なすべてのテーマ (.theme ファイルとして識別される) は、スキンにそのテーマが含まれているかどうかに関係なく、ブック、ページ、およびポートレット用に選択できます。デスクトップ用に選択されたルック アンド フィールが参照するスキンの skin.properties ファイルに選択したテーマが含まれていない場合は、前の手順で説明されているように、テーマは使用されません。

スケルトンとスケルトン テーマ

ポータル デスクトップは、互いに階層構造の関係にある、ブック、ページ、ポートレットなどのポータル コンポーネントの集合です (たとえば、ブックにはページ、ページにはポートレットが含まれています)。ポータル コンポーネントは大部分が XML ファイルであるため、ブラウザに表示するには HTML に変換する必要があります。この表示がスケルトンの機能です。

各ポータル コンポーネントには、対応する複数のスケルトン JSP ファイルがあります。ポータル デスクトップが表示されると、各ポータル コンポーネントのスケルトン JSP (関連するクラスがあればそれらも) はそれぞれのロジックを実行し、結果の HTML を HTML ファイルの階層の正しい位置に挿入します。

スケルトンには、テーマも含めることができます。スケルトン テーマはスケルトン JSP のサブセットで、ブック、ページ、およびポートレットで使用してその使い勝手を他のポータル デスクトップと異なるようにすることができます。スケルトンとスキンの組み合わせにより、ポータル デスクトップのルック アンド フィールが決定されます。ポータル デスクトップのルック アンド フィールを選択すると、そのルック アンド フィールは使用するスケルトンとスキンを指し示します。

スケルトンの作成が必要な場合

ポータル アプリケーションにポータル Web プロジェクトを作成すると、そのプロジェクトには使用可能な定義済みのスケルトンが含まれています。ほとんどの場合、定義済みのスケルトンを使用して必要を満たすことができます。ポータル デスクトップの物理的な外観や動作は、ほとんどの場合新しいスケルトンを作成しなくても、新しいスキンやシェルを作成すれば変更できます。

スケルトンは、以下の内容を実行する必要がある場合に作成します。

スケルトンを作成する

新しいスケルトンを作成するには、以下の手順を実行します。

  1. WebLogic Workshop Platform Edition でポータル アプリケーションを開いた状態で、既存のスケルトン ディレクトリのコピーを作成します。たとえば、<project>¥framework¥skeletons¥default を右クリックして [複製] を選択します。複製したディレクトリが表示されたら、名前を変更します。
  2. モバイル デバイスをサポートするためのスケルトンを作成する場合は、新しいディレクトリをメインのスケルトンのサブディレクトリに移動します。新しいディレクトリには、<project>¥WEB-INF¥client-classifications.xml ファイルにあるデバイスの分類名と同じ名前を付けます。

  3. 新しいスケルトン ディレクトリで、skeleton.properties ファイルを開きます (デフォルトのスケルトン ディレクトリをコピーした場合は、別のスケルトンの skeleton.properties を新しいスケルトン ディレクトリのルートにコピーして開きます)。
  4. スケルトンの検索順序に変更が必要であれば、skeleton.properties で変更します。例 :
  5. jsp.search.path: ., ../default

    このエントリにより、まずカレント ディレクトリ (.) でスケルトン ファイルが検索されます。カレント ディレクトリでスケルトンが見つからなかった場合は、../default ディレクトリが検索されます。どちらのディレクトリでもスケルトンが見つからなければ、見つかるまでスケルトンのディレクトリ全体が検索されます。

  6. skeleton.properties を保存します。
  7. スケルトン JSP を変更して、目的の表示を実行するようにします。Portal Skeleton Rendering JSP タグ ライブラリ内のタグを使用します。特に、<render:beginRender> および <render:endRender> タグを使用してください。
  8. 変更するスケルトン JSP に関するガイダンスについては、後述の「ポータル コンポーネントとスケルトンの対応関係」の表を参照してください。

    スケルトン ファイルの名前を変更しないでください。スケルトンのファイル名は、個々のクラス ファイルでハード コーディングされています。唯一の例外として、独自のバッキング クラス ファイルを使用し、作成しようとしているスケルトンの名前を明示的に指定する新しい表示インフラストラクチャを作成する場合には、ファイル名を変更できます。

  9. スケルトン JSP を保存します。
  10. スケルトンのサブディレクトリに何らかのデバイス用のスケルトンが格納されている場合は、対応する skeleton.properties またはスケルトン JSP を適宜変更します。
  11. 新しいスケルトンを使用するには、ルック アンド フィール ファイルでそのスケルトンを参照します。「ルック アンド フィール ファイルの作成」を参照してください。

注意 : WebLogic Workshop Portal Extensions Portal Designer でポータルを操作する場合は、プロパティ エディタで、選択した各ポータル コンポーネントに Skeleton URI プロパティを設定できます。このプロパティを使用すると、ポータル デスクトップ用に選択したルック アンド フィールで指定されているスケルトンの代わりにコンポーネントで使用する特定のスケルトン ファイルを指し示すようにできます。

スケルトンにはビジネス ロジックを追加しないでください。スケルトンは、物理的な表示のみを目的に設計されています。ビジネス ロジックは、シェル (ヘッダまたはフッタ) に追加してください。

スケルトン テーマを作成する

テーマは、スキンとスケルトンで共有される 1 つの .theme ファイルで表されます。たとえば、ポートレット用に「alert」というテーマを選択すると、ポータル フレームワークは「alert」というスキンおよびスケルトンのサブディレクトリを検索します。テーマがすでに存在しているため、テーマのスケルトンのみを作成する場合は、以下の手順 5 から始めてください。

  1. WebLogic Workshop Platform Edition でポータル アプリケーションを開いた状態で、ポータル Web プロジェクトの既存のテーマ ファイルを複製します。たとえば、<project>¥framework¥markup¥theme¥alert.theme を右クリックして [複製] を選択します。
  2. 名前の末尾に数字が付加された新しいテーマ ファイルが表示されます。

  3. 新しいテーマ ファイルの名前を変更します。拡張子 .theme は必ずそのままにしてください。
  4. 新しいテーマ ファイルを開いた状態で、<netuix:theme> 要素の属性、name、title、description、および markupName を変更します。title 属性は、ドロップダウン メニューでテーマを選択するための名前になります。markupName は、テーマの中でユニークである必要があります。
  5. テーマ ファイルを保存します。
  6. スケルトン ディレクトリにテーマと同じ名前のサブディレクトリを作成します。
  7. 既存のスケルトン ディレクトリから新しいテーマ ディレクトリに適切なスケルトン JSP をコピーします。テーマを適用するポータル コンポーネント用のスケルトン JSP のみをコピーしてください。対応するテーマのスケルトン JSP を持たないポータル コンポーネントでは、親のスケルトン JSP が使用されます。
  8. スケルトン テーマのスケルトン JSP ファイルを変更します。ファイル名は変更しないでください。
  9. スケルトン テーマのディレクトリをサブディレクトリとして他のスケルトン ディレクトリにコピーします。
  10. 使用可能なすべてのテーマ (.theme ファイルとして識別される) は、スケルトンにそのテーマが含まれているかどうかに関係なく、ブック、ページ、およびポートレット用に選択できます。デスクトップ用に選択されたルック アンド フィールが参照するスケルトンに選択したテーマが使用されていない場合、テーマは使用されません。

    表 5 ポータル コンポーネントとスケルトン JSP

    ポータル コンポーネント

    使用されるスケルトン JSP

    目的

    デスクトップ

    desktop.jsp

    HTML ドキュメントの宣言と、<!-- Begin Desktop --> および <!-- End Desktop --> のコメントを挿入する。

    シェル

    shell.jsp

    HTML ドキュメントの開始と終了の <html> タグと、<!-- Begin Shell --> および <!-- End Shell --> のコメントを挿入する。

    シェル - .shell ファイルの <netuix:head> タグ

    head.jsp

    HTML ドキュメントの開始と終了の <head> タグと、<!-- Begin Head --> および <!-- End Head --> のコメントを挿入する。

    シェル - .shell ファイルの <netuix:body> タグ

    body.jsp

    HTML ドキュメントの開始と終了の <body> タグを挿入し、プレゼンテーション ロジックを提供する。

    シェル - .shell ファイルの <hetuix:header> タグ

    header.jsp

    デスクトップのヘッダ領域を表示する。

    シェル - .shell ファイルの <netuix:footer> タグ

    footer.jsp

    デスクトップのフッタ領域を表示する。

    ブック

    book.jsp

    ブックのフレームワークとスタイルを表示する。

    ナビゲーション メニュー

    singlelevelmenu.jsp

    WebLogic Portal によって提供されるシングル レベル メニューを表示する。

    ナビゲーション メニュー

    multilevelmenu.jsp

    WebLogic Portal によって提供されるマルチ レベル メニューを表示する。

    ブック、ナビゲーション メニュー

    submenu.jsp

    ブック内のブックのナビゲーション メニューを表示する。

    ページ

    page.jsp

    ページのフレームワークとスタイルを表示する。

    レイアウト - .layout ファイルの <netuix:gridLayout> タグ

    gridlayout.jsp

    グリッド レイアウト スタイルを使用してレイアウト内のプレースホルダを表示する。

    レイアウト - .layout ファイルの <netuix:borderLayout> タグ

    borderlayout.jsp

    枠レイアウト スタイルを使用してレイアウト内のプレースホルダを表示する。

    レイアウト - .layout ファイルの <netuix:flowLayout> タグ

    flowlayout.jsp

    フロー レイアウト スタイルを使用してレイアウト内のプレースホルダを表示する。

    レイアウト - .layout ファイルの <netuix:placeholder> タグ

    placeholder.jsp

    レイアウト内の個々のプレースホルダを表示する。

    ポートレットのタイトルバー

    titlebar.jsp

    ポートレットのタイトルバーを表示する。

    ポートレットのタイトルバーから移動可能なウィンドウを表示するボタン

    buttonfloat.jsp

    独立したポートレット モード ウィンドウを開くボタン ([編集] や [ヘルプ] など) を表示する。

    ポートレットのタイトルバーの切り替えボタン

    togglebutton.jsp

    ポートレットの状態を切り替えるボタン ([Minimize] または [Restore] および [Maximize] または [Restore] など) を表示する。

    ポートレットのタイトルバーの [削除] ボタン

    togglebuttondelete.jsp

    ポートレットをページから削除するボタンを表示する。

    ポートレット

    error.jsp

    ポートレット内にエラー メッセージを表示する。

    ポートレット

    webflowportlet.jsp

    以前のバージョンの WebLogic Portal で作成され、互換性ドメインで実行される Webflow ポートレットを表示する。

    ブック、ページ、およびポートレット

    window.jsp

    コンテンツ領域のコンテナを表示する。

    テーマ

    theme.jsp

    テーマ内でテーマに適用されるブック、ページ、およびポートレットを表示する。

スキンにはスケルトン ファイルはありません。スケルトンには、適切なグラフィック、スタイル、および JavaScript 機能を使用してコンポーネントを表示するためのスキン リソースへの参照が含まれます。テーマはスキンと関連がありますが、スキンのスタイルをオーバーライドするためにインライン形式で挿入する必要があることから、テーマにはスケルトンが必要です。

レイアウト

レイアウトは、ブック、ページ、およびポートレットを配置できるページのプレースホルダ (テーブル構造) を提供します。たとえば、3 つのテーブル セルを使用するレイアウトには 3 つのプレースホルダがあり、プレースホルダ内のページにポートレットを配置できます。

WebLogic Workshop Portal Extensions には、以下の 3 つのレイアウト スタイルがあり、これらを使用して独自のレイアウトを作成できます。




グリッド レイアウトでは、指定した数のプレースホルダが指定した数のカラムと行で自動的に配置される。この例では、8 つのプレースホルダを columns="3" の設定で配置している。

フロー レイアウトでは、使用される数のプレースホルダが垂直または折り返されずに水平方向に自動的に配置される。

枠レイアウトでは、最大 5 つのプレースホルダを使用できる。プレースホルダは、「north」、「south」、「east」、「west」、および「center」の属性で配置できる。

レイアウトには、以下の 2 つのファイルが必要です。

また、レイアウトの各スタイルを表示するために使用される、gridlayout.jsp、flowlayout.jsp、および borderlayout.jsp というスケルトン JSP もあります。これらのスケルトン ファイルによって各スタイルの動作が管理されるため、スケルトンを変更する必要はありません。

以下のトピックでは、各タイプのレイアウトを作成するための具体的な手順も含めて、レイアウトの作成手順を説明します。

レイアウトを作成する

  1. WebLogic Workshop Platform Edition でポータル アプリケーションを開いた状態で、ポータル Web プロジェクトの既存のレイアウト ファイルを複製します。たとえば、<project>¥framework¥markup¥layout¥fourcolumn.layout を右クリックして [複製] を選択します。
  2. 名前の末尾に数字が付加された新しいレイアウト ファイルが表示されます。

  3. 新しいレイアウト ファイルの名前を変更します。拡張子 .layout は必ずそのままにしてください。
  4. 既存の .html.txt ファイルを複製し、新しいレイアウトに使用します。このファイルの名前を .layout ファイルの名前と関連する名前に変更します。拡張子 .html.txt は必ずそのままにしてください。.html.txt ファイルに、表示するレイアウトの外観と同様の外観になるように HTML テーブルの構造を作成します。
  5. <netuix:markup> タグ内に、作成するレイアウトのタイプに応じて、<netuix:gridLayout>、</netuix:flowLayout>、または </netuix:borderLayout> の開始および終了タグを挿入します (既存の <netuix:*Layout> の開始および終了タグを置き換える)。
  6. <netuix:*Layout> の開始タグ内で、以下の属性を追加 (または変更) します。

title

ドロップダウン メニューでレイアウトを選択するための名前を指定します。

description

選択したレイアウトの説明を指定します。

グリッド レイアウトの属性

columns

レイアウト内のカラム数を決定する。行数は自動的に決定される。「columns」属性を使用する場合は、「rows」属性は使用しない。

rows

レイアウト内の行数を決定する。カラム数は自動的に決定される。「rows」属性を使用する場合は、「columns」属性は使用しない。

フロー レイアウトの属性

orientation

「vertical」または「horizontal」を入力して、プレースホルダを配置する方向を決定する。

枠レイアウトの属性

layoutStrategy

「order」または「title」を入力する。

  • 「order」を入力した場合、プレースホルダは <netuix:placeholder> タグに入力した値に従って順序付けされる (次の手順で説明)。

例 : <netuix:placeholder>North</netuix:placeholder> と指定すると、プレースホルダは north のプレースホルダになる。

  • 「title」を入力すると、プレースホルダは <netuix:placeholder> の「title」属性の値に従って順序付けされる。

例 : <netuix:placeholder title="south" ...></netuix:placeholder> と指定すると、このプレースホルダは south のプレースホルダになる。

htmlLayoutUri

作成した .html.txt ファイルのパス (プロジェクトを基準とした相対パス) を指定します。

例 : "/framework/markup/layout/yourNewLayout.html.txt"

iconUri

互換性ドメインの管理専用です。互換性ドメインで実行されるポータルを管理する場合に、レイアウトをグラフィカルに表現したアイコンへのパス (プロジェクトを基準とした相対パス) を指定します。

例 : "/framework/markup/layout/yourNewLayout.gif"

markupName

markupName は、レイアウトの中でユニークである必要があります。

  1. <netuix:*Layout> タグ内で、レイアウト内に配置する各プレースホルダに開始の <netuix:placeholder> および終了の </netuix:placeholder> タグを追加します。
  2. 枠レイアウトを作成する場合、使用できるプレースホルダは 5 つまでです。

  3. 各プレースホルダの開始の <netuix:placeholder> タグに以下の属性を追加します。

title

プレースホルダのタイトルを入力します。layoutStrategy 属性に「title」を設定して枠レイアウトを使用する場合は、枠レイアウトにおけるプレースホルダの位置を決定する title に、「north」、「south」、「east」、「west」、または「center」を入力します。

description

プレースホルダの説明を入力します。

flow

省略可能。プレースホルダへのブックとポートレットの配置を制御するには、「true」を入力します。

usingFlow

省略可能。「flow」属性を「true」に設定する場合は、この属性の値に「vertical」または「horizontal」を入力します。この値により、プレースホルダ内でブックやポートレットが上下 (vertical) と左右 (horizontal) のどの方向に配置されるかが決定されます。

width

省略可能。プレースホルダの幅を設定します。

markupType

必須。「Placeholder」と入力します。

markupName

必須。プレースホルダの ID として使用されます。各プレースホルダは、すべてのレイアウトの中でユニークな markupName を持つ必要があります。

  1. 枠レイアウトを作成する場合、layoutStrategy 属性に「order」を設定するときには、各 <netuix:placeholder> タグのコンテンツとして「North」、「South」、「East」、「West」、または「Center」を入力し、レイアウト内の各プレースホルダの位置を決定します。たとえば、<netuix:placeholder>North</netuix:placeholder> と指定すると、プレースホルダは north のプレースホルダになります。
  2. レイアウト ファイルを保存します。
  3. レイアウトの *.html.txt ファイルを変更して、.layout ファイルのレイアウトをシミュレートする HTML テーブルを作成します。
  4. レイアウトを使用するには、Portal Designer の [ドキュメント構造] ウィンドウでページを 1 つ選択します。[プロパティ エディタ] ウィンドウの [レイアウト タイプ] フィールドで新しいレイアウトを選択します(新しいレイアウトが [レイアウト タイプ] ドロップダウン リストに表示されるには、サーバが実行されていなければなりません)。

ナビゲーション メニュー

ナビゲーション メニューは、ポータル デスクトップの異なるページを選択する手段を提供します。WebLogic Portal には、次のようなデフォルトのナビゲーション メニューのセットがあります。

シングル レベル メニュー

ブックおよびページ リンクの目に見えるレイヤを提供します。サブブックおよびページはすべて、メイン ブック ナビゲーションの下の行に表示されます。

マルチ レベル メニュー

マルチ レベルメニューを適用したレベルで、ブックおよびページへのタブ状のリンクが 1 列に表示される。サブブックおよびページはすべて、ドロップダウン リストに選択対象として表示されます。マルチ レベル メニューは、スキンに含まれる JavaScript 機能を実装します。

デフォルト メニューで提供される動作以外のナビゲーション メニューの動作が必要な場合は、必要に応じてデフォルト メニューのいずれかを変更できます。デフォルトのナビゲーション メニューは、「ナビゲーション メニュー ファイルを変更する」と「スケルトン JSP ファイルを変更する」のいずれかの手順を使用して変更できます。

ナビゲーション メニュー ファイルを変更する

ナビゲーション メニュー ファイルを変更するには、以下の手順を実行します。

  1. <project>¥framework¥markup¥menu¥ の.menu ファイルのいずれかを開きます。
  2. <netuix:markup> タグ内で、<netuix:singleLevelMenu ... /> または <netuix:multiLevelMenu ... /> タグの以下の属性を変更します。タグの名前は変更しないでください。

注意 : 以下の align 属性は省略可能です。

スケルトン JSP ファイルを変更する

スケルトン JSP ファイルを変更するには、以下の手順を実行します。

  1. スケルトン JSP を後から戻せるように、元のスケルトン JSP をバックアップします。対象のスケルトン ファイル、multilevelmenu.jsp および singlelevelmenu.jsp は、<project>¥framework¥skeletons¥default ディレクトリにあります。
  2. これらのファイルは、他のスケルトン ディレクトリにもあります。作業が完了したら、これらのファイルを変更したファイルに置き換えます。

  3. スケルトン JSP を変更します。ファイルの名前は変更しないでください。
  4. multilevelmenu.jsp スケルトン ファイルでは、menu.js に含まれる JavaScript 関数が使用されます。menu.js は、スケルトン ファイルとは別のスキン ディレクトリ、<project>¥framework¥skins に入っています。

  5. JSP の変更が完了したら、変更した JSP を関連する他のスケルトン ディレクトリにコピーして、既存のバージョンと置き換えます。

変更したナビゲーション メニューを使用するには、Portal Designer の [ドキュメント構造] ウィンドウでブックを選択します。[プロパティ エディタ] ウィンドウの [ナビゲーション] フィールドで新しいナビゲーション メニューを選択します (新しいナビゲーション メニューが [ナビゲーション] ドロップダウン リストに表示されるには、サーバが実行されていなければなりません)。

シェル

シェルは、ポータル デスクトップのメイン コンテンツ領域 (ブック、ページ、およびポートレット) を囲む表示領域です。最も重要な機能として、シェルはデスクトップのヘッダおよびフッタ領域に表示されるコンテンツを制御します。

特定の JSP やHTML ファイルを使用するようにシェルを設定して、ヘッダまたはフッタのコンテンツ (特にパーソナライズされたコンテンツ) を表示することができます。異なるヘッダ/フッタの組み合わせごとに、新しいシェルを 1 つ作成します。

シェルを作成する

新しいシェルを作成するには、以下の手順を実行します。

  1. 開発マシンでサーバが実行されていることを確認します。サーバが実行されていない場合は、ポータル アプリケーションを開き、[ツール|WebLogic Server|WebLogic Server の起動] を選択します。
  2. WebLogic Workshop Platform Edition で、既存のシェル (<project>¥framework¥markup¥shell ディレクトリ内) を開きます。
  3. <netuix:shell> 要素の title、description、および markupName 属性を変更します。title 属性は、ドロップダウン メニューでシェルを選択するための名前になります。markupName は、シェルの中でユニークである必要があります。
  4. <netuix:header> または <netuix:footer> 要素を使用して、ヘッダまたはフッタに使用する JSP または HTML ファイルを指定します。これには、以下の手順を実行します。
    1. 空の要素を変更して、開始タグと終了タグを持つ要素にします。
    2. 例 :

      変更前

      <netuix:header/>

      変更後は次にようになります。

      <netuix:header>
      </netuix:header>
    3. <netuix:header> または <netuix:footer> タグに <netuix:jspContent conentUri=" "> タグを追加し、contentUri 属性を使用してヘッダまたはフッタに表示する JSP または HTML ファイルを指定します。ファイルのパスは、プロジェクトを基準とした相対パスです。
    4. たとえば、ヘッダでファイル <project>¥my_jsps¥campaign_header.jsp を使用する場合は、以下のようにシェル ヘッダを設定します。

      <netuix:header>
      <nexuix:jspContent contentUri="/my_jsps/campaign_header.jsp"/>
      </netuix:header> 

      JSP または HTML ファイルは、<html>、<head>、<title>、または <body> HTML タグをすでに含んでいる単体の HTML ファイルに挿入されるため、これらのファイルにこのようなタグを含まないようにしてください。ファイルは、<div>、<table>、<p> などの HTML のネスト タグだけでフォーマットできます。

    5. <netuix:jspContent> タグでは、以下の属性を使用して、エラー JSP、およびヘッダまたはフッタ JSP用のバッキング ファイルを指定することもできます。

コード リスト 0-1 シェル ヘッダ

<netuix:header>
<nexuix:jspContent contentUri="/my_jsps/campaign_header.jsp" errorUri="/my_jsps/my_error.jsp"
backingFile="custom.portal.backing.campaignBacking" />
</netuix:header> 
    1. シェル ファイルを保存します。
    2. デスクトップ用のシェルを選択するには、[ドキュメント構造] ウィンドウで [デスクトップ] を選択し、プロパティ エディタの [シェル] フィールドでシェルを選択します (新しいシェルの名前は、サーバが実行されていなければ表示されません)。

Portal Designer でシェルにデスクトップを選択すると、ポータルには単にデフォルトのシェル設定が適用されます。ポータル管理者は、WebLogic Administration Portal を使用して、デスクトップに使用するシェルを変更できます。

 

 ページの先頭 前 次