Lotus Web Content Management

第 1 版

公開日: 2010 年 9 月

この資料について

IBM のアクセシビリティーに関するコミットメントに従い、この資料はアクセシビリティーに対応しています。

印刷

この資料を印刷する場合、最良の印刷出力を得るために、一部の装飾は除去されます。 以下に印刷についてのいくつかのヒントを示します。
  • この資料の長さは、ブラウザーで印刷可能な長さを超えている可能性があります。 Microsoft Internet Explorer では、大きなファイルを正しく印刷できることが実証されています。
  • この資料はボリュームの大きな資料です。 印刷プレビュー機能を利用して、印刷されるページの長さを確認してください。
  • 資料のセクションを強調表示して、その選択部分の内容だけを印刷することもできます。

オフラインでの作業

ブラウザーからこの資料のローカル・コピーを保存することができます。 メニューおよびオプションはブラウザーごとに異なります。 資料をローカルに保存する方法について詳しくは、ブラウザーのヘルプを参照してください。

フィードバックを送る

この資料のフィードバックをお送りになりたい場合は、 「フィードバックを送る」をご覧ください。

概説

Lotus Web Content Management は WebSphere Portal に同梱されており、堅固な Web コンテンツ管理ソリューションを提供します。カスタマイズと拡張可能なオーサリング・インターフェース、ワークフロー、バージョン管理、分類、およびその他多くのものを含んでいます。

IBM Lotus Web Content Management

Web Content Management は Web サイトに関するコンテンツの作成、管理、および配信に使用します。Web コンテンツ・オーサリング・ポートレットを使用してコンテンツを作成したり、独自にカスタマイズされたオーサリング・インターフェースを作成したりできます。外部コンテンツ管理システムに格納された Web コンテンツを、Web Content Management システム内で参照することもできます。Web コンテンツ・ビューアー・ポートレットか Web Content Management サーブレットを使用して Web コンテンツを配信したり、サイトを HTML に事前レンダリングしたりできます。

Web サイトの作成

Web Content Management ソリューションで、Web サイトのレイアウトおよび設計エレメントは、 Web サイトのコンテンツとは分離して管理されます。 これにより、コンテンツを変更しなくても Web ページのレイアウトおよび設計を変更でき、 レイアウトおよび設計を更新しなくてもコンテンツを変更できます。 ナビゲーションなど Web サイトの設計機能の多くは、 事前定義のエレメントおよびコンポーネントを使用して自動的に生成されます。

Web コンテンツ・オーサリング

Web Content Management の基本的な使用法の 1 つに、 Web コンテンツのクリエーター用に Web コンテンツ・オーサリング・システムを構築することがあります。 Web Content Management システムでは、Web サイトの設計とレイアウトは Web サイトに表示されるコンテンツから分離されます。 これにより、Web コンテンツの作成者は、Web サイトの構築方法を知らなくてもサイトのコンテンツを作成できます。 作成する Web コンテンツ・オーサリング・システムは、さまざまなタイプのユーザーがさまざまな Web コンテンツ・オーサリングを実行できるように設計されます。

外部コンテンツのアクセス

Web Content Management で使用される Web コンテンツを外部コンテンツ管理システム内で格納したり管理したりすることもできます。 RSS フィード形式を使用してコンテンツを Web Content Management システムにインポートするには、Web Content Integrator を使用します。コンテンツを統合コンテンツ・システムから Web Content Management システムに直接リンクできます。WebDAV を使用して、コンテンツをファイル・システムから Web Content Management システムにインポートすることもできます。

Web コンテンツの管理

Web Content Management には、 Web コンテンツ・システムの保守および管理に役立つ機能のセットが含まれます。 これには、バージョン管理、変更管理と承認、複数項目のプロジェクト、および Web コンテンツ項目のセットをグループ化するためのユーザー定義フォルダーが含まれます。

プリインストールされた Web コンテンツ・ライブラリー

ブログおよび Wiki 機能を Web サイトに追加するために、プリインストールされた Web コンテンツ・ライブラリーのセットが提供されています。 ブログ、ブログ・ライブラリー、および Wiki を使用して、コミュニティーの能力を活用し、作業する方法を変更します。

Web コンテンツの配信

Web コンテンツ・ビューアー・ポートレットまたはサーブレットを使用するか、事前レンダリングされた HTML ファイルとして、Web コンテンツを Web サイト・ビューアーに配信できます。

Web Content Management システムの計画

このインフォメーション・センターには、Web Content Management システムの計画と管理に役立つように準備された多くのトピックが含まれています。 これらのトピックを参考にすると、Web Content Management システムのパフォーマンスを最適で使いやすいように設計し、Web Content Management システムを十分に計画してリソースを割り当てることができます。

Web Content Management の構成と管理

Web Content Management システムをインストールするとき、 システム内での役割に応じて、システム内でサーバーを別々に構成します。 構成すると、Web コンテンツ・ライブラリー、シンジケーション、およびフィードの管理に使用する一連の管理機能が用意されます。

IBM Lotus Web Content Management の新機能および改良機能

Web Content Management バージョン 7.0 には、 フォルダーやプロジェクトなどの新機能が含まれており、既存の機能に対するさまざまな改良が行われています。

コンテンツ・オーサリングの改良

オーサリング・ポートレットが更新されて、 使いやすさが向上し、ナビゲートや項目の検出がより簡単になりました。 改良には、以下が含まれます。
  • 新鮮なルック・アンド・フィール
  • 必要な項目とロケーションを保管する機能
  • 改良された「最近の項目」ビュー
  • すべてのライブラリーからの項目を表示する機能
  • 改良されたグローバリゼーション機能
詳しくは、オーサリング・ポートレットに関する作業を参照してください。

フォルダーを使用した作業の編成

オーサリング・テンプレート、プレゼンテーション・テンプレート、 およびオーサリング・ポートレットのコンポーネント・ビュー内に複数のフォルダーを作成して、設計作業を編成できるようになりました。 フォルダーを使用してこれらの項目タイプを論理グループに編成することにより、必要なときに項目を見つけることが簡単になります。

ファイル・リソースに基づくコンテンツ項目

オーサリング・テンプレートを構成して、 ファイル・リソースをコンテンツ項目として保管できるようになりました。 これは、PDF ファイルなどのファイルを格納して、その PDF ファイルをページで直接レンダリングする一方で、その PDF ファイルをメニューやナビゲーターなどのナビゲーション・コンポーネントで表示する場合に便利なテンプレートです。

分類法に基づくオプション選択エレメント

オプション選択エレメントに、 既存の分類法からのカテゴリーを取り込むことができるようになりました。 オプション選択エレメントで選択されたカテゴリーは、コンテンツ項目のプロファイルを作成するためにも使用できます。 これにより、複数のオプション選択エレメントをオーサリング・テンプレートに追加して、 コンテンツ作成者によるコンテンツ項目のプロファイル作成のプロセスを容易にすることができます。

改良された Web コンテンツ・タグ・サポート

Web コンテンツ・タグの形式は、読みやすさの向上とリッチ・テキスト・フィールドへの組み込みを改善するために、大括弧を使用するように変更されました。 Web コンテンツ・タグを HTML 設計に容易に追加できるようにするために、新しい「タグ・ヘルパー」機能がオーサリング・ポートレットに追加されました。

拡張された変更管理機能

Web Content Management の変更管理機能が拡張されて、 以下が含まれるようになりました。
  • 単一の項目に対して複数のドラフトを作成する機能
  • ワークフローを必要とすることなくドラフトを作成する機能
  • ワークフロー・アクションの日時オフセットを含む改良されたワークフロー制御
  • 双方向のワークフロー制御
詳しくは、ドラフト項目に関する作業を参照してください。

プロジェクトを使用する協同的なコンテンツ管理

プロジェクト内の複数の項目に対する変更を、 作成、編集、ワークフロー化、プレビュー、およびシンジケートできるようになりました。 プロジェクト内のすべての項目を公開する準備ができたときに、それらを単一の操作でまとめて公開できます。

詳しくは、プロジェクトの項目に関する作業を参照してください。

改良された JSR 286 Web コンテンツ・ビューアー

ローカルおよびリモートの Web コンテンツのレンダリングに使用される JSR 286 Web コンテンツ・ビューアーが、 以下のように機能拡張されました。
  • Web コンテンツ用の分かりやすい URL のサポート。 Web コンテンツの分かりやすい URL は、ユーザーがコンテンツ項目のブックマークを作成したり、 外部アプリケーションがポータルのコンテンツ項目に対する直接的なリンクを提供したりするための便利な方法です。
  • 推奨されない従来型の Web コンテンツ・ビューアーから JSR 286 Web コンテンツ・ビューアーへの自動マイグレーション。
  • タグ付けおよびレーティングのサポート。

詳しくは、Web コンテンツ・オーサリング・インターフェースのストラテジーを参照してください。

Web コンテンツ・ページの強化

Web コンテンツ・ページでは、 以下の追加機能を提供するようになりました。
  • Web コンテンツ・ページに表示されるコンテンツ項目のアクセス制御をページ自体に委任する、 ページ・ベースのアクセス制御によるパフォーマンスの改善。 ページ・ベースのアクセス制御が Web コンテンツ・ページに対して使用可能なら、 ページを表示する権限があるユーザーは、そのページに関連付けられたコンテンツを表示する権限も自動的に付与されます。
  • XML 構成インターフェース、ポータル・スクリプト・インターフェース、コンテンツ・マッピングの REST API などのツールによって管理および自動化が可能な、 堅固なコンテンツ・マッピング・サポート。

詳しくは、Web コンテンツ・ページに関する作業を参照してください。

より簡単になった構成

WebSphere Application Server リソース環境プロバイダーを使用することにより、 WebSphere Application Server 管理コンソールを使用して Web Content Management システム・プロパティーを編集できるようになったので、 Web コンテンツ環境を構成するプロセスが改善されました。

改善された保守容易性

Web Content Management のロギングおよびトレース機能が改善されて、 特定のデバッグ・モジュールを IBM サポートからインストールしなくても問題判別ができるようになりました。 このサポートには、FFDC ロギング用の WebSphere Application Server 公開 API の使用が含まれます。

Java メッセージング・サービスのサポート

Web Content Management は、 (項目の状態変更、サービスの開始/停止など) イベントの通知をサポートします。 これらの通知は、Java メッセージング・サービスへのメッセージとして配信可能です。

詳しくは、Web コンテンツ用の Java メッセージング・サービスの使用可能化を参照してください。

資料リソース

情報の開始点は、製品資料です。 以前は、製品資料は、インフォメーション・センターのフレームワークを使用して配信されていましたが、WebSphere Portal 7.0 では、製品資料は WebSphere Portal Family wiki で配信されます。 WebSphere Portal の操作時に使用できるサイトやリソースが他にもありますが、情報の検索を容易にするためにこの統合が行われました。 また、コンテンツに改善を加え、資料に対してコミュニティー全体で編集およびコメント記入を行えるようにすることも意図しています。 情報の検索場所を知っていると、手間と費用を節約できます。 WebSphere Portal と Lotus Web Content Management の資料および補足コンテンツに関する 1 次リソースと 2 次リソースについて詳しく説明します。

コンテンツの 1 次ソースには、WebSphere Portal Family wiki および WebSphere Portal サポート・サイトの 2 つがあります。 優れた 2 次ソースとして developerWorks があります。ここには、例およびチュートリアル・ベースの記事があります。

コンテンツの 2 つの 1 次ソースである WebSphere Portal Family wiki およびサポート・ページを図示した概念的なグラフィック。さらにそれらに接続するハイパーリンク。
リソース間のナビゲートに役立つように、各コンテンツ・ソースは他のソースにリンクしています。 各コンテンツ・ソースには特定の目的があり、他のソースと併用することを意図しています。

Wiki で配信される製品資料 (「製品マニュアル (Product Documentation)」タブにある) は、予期される使用パターンに基づいて機能を活用できるように、IBM により開発されています。 ユーザーは製品を使用した経験を反映させることにより、コンテンツに貢献できます。 「ホーム」タブからアクセスする Wiki コンテンツは、IBM 内外のコミュニティーによって作成されます。 製品を使用した経験から得た、実際の使用パターンとユース・ケースに基づく知識を共有することを意図しています。 サポート・コンテンツは、IBM サポートによって、問題を避けたり診断したりするのに役立つように開発されており、可能な限り即応性があるよう意図されています。

WebSphere Portal Wiki

Wiki には、次の内容が含まれます。
  • 「製品マニュアル (Product Documentation)」タブには、次のものが含まれます。
    • 新しいフィーチャーのハイライト、製品フィーチャー、およびユーザー補助を含む製品の概説
    • デプロイメントの計画情報
    • 概念検証または開発サーバー用の単一サーバー、スタンドアロン実稼働、およびクラスター実稼働の各環境を対象にしたインストール指示
    • 通常 1 回、またはまれにしか指定されない、ポータル全体に影響する構成オプション
    • 毎日使用する管理タスク
    • 統合に関する指示
    • ポートレットや複合アプリケーションの開発に役立つ開発情報
    • トラブルシューティング情報と、ロギングおよびトレースの情報
    • 問題の診断やトラブルシューティングに役立つメッセージ
  • パフォーマンスおよびチューニング・ガイドなどの補足的な手引き
  • IBM Redbooks
  • ベスト・プラクティス
  • デプロイメント・シナリオ
  • タスク・ベースのデモンストレーションやビデオなどのマルチメディア・オファリング
  • 参照カード
Wiki に関して覚えておく必要があるキーポイントは以下のとおりです。
  • 以前はインフォメーション・センターで配信された情報は、現在 Wiki の「製品マニュアル (Product Documentation)」タブで配信されています。
  • コンテンツは体験主導型です。
  • ユーザーは記事を編集したり、コメントを追加したり、ユーザー独自の記事を作成したりできます。
  • IBM が Wiki をモニターします。
  • 新しい記事、コメント、および最新の編集に関して RSS フィードにサブスクライブできます。

WebSphere Portal Support ページ

Support ページには、次の内容が含まれます。
  • 製品か資料に伴う問題に対応して書き込まれた技術情報
  • フィックスの適用に関する指示を含む、フィックスパックのダウンロード
  • トラブルシューティング情報
  • 優先順位が高い問題に関するフラッシュ
Support ページに関して覚えておく必要があるキーポイントは以下のとおりです。
  • MyNotifications を使用して、更新や新規サポート・コンテンツにサブスクライブできます。
  • IBM Support Assistant などのツールをダウンロードできます。

ユーザー補助機能

ユーザー補助機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるように サポートします。

このバージョンの IBM WebSphere Portal は、以下をサポートしています。

  • コンソール・モード というコマンド行インターフェースによるインストールをサポート。このインストールは、グラフィカル・ユーザー・インターフェースを使用したインストールと同等のユーザー補助です。
  • スクリーン・リーダーおよび画面拡大機能で一般的に使用されるインターフェースをサポート (Windows のみ)
  • 画面の表示内容を聞き取るために、スクリーン・リーダー・ソフトウェアおよびディジタル音声シンセサイザーの使用をサポート
  • キーボードのみを使用して操作可能
  • 時刻指定応答を完了する時間をさらに要求することが可能
  • カラー、コントラスト、フォント・サイズなどの表示属性のカスタマイズをサポート
  • カラーとは関係なく、すべての情報を伝達
  • 代替入出力デバイスの接続をサポート
  • 音声情報の代替手段をサポート
  • 調整可能なボリューム制御をサポート
  • てんかん発作を誘発する可能性のあるレートで画面が明滅しない
  • 利用できるフォーマットでドキュメンテーションを提供
注: スクリーン・リーダーを使用して WebSphere Portal を表示する際に最善の結果を得るには、Freedom Scientific JAWS 11 以上と Firefox 3.5 以上を併用してください。
ユーザー補助を強化するため、資料に、次のような機能が含まれています。
  • すべての資料は、スクリーン・リーダー・ソフトウェア・テクノロジーの適用の可能性が最大となる HTML 形式で入手可能。
  • 資料内のすべてのイメージは、視覚障害のあるユーザーがイメージの内容を理解できるように、代替テキストと共に提供される。

該当する場合は、特定の製品機能のドキュメンテーションに、ユーザー補助に関する追加情報が含まれています。

ユーザー補助に対する IBM のコミットメントについて詳しくは、IBM Human Ability and Accessibility Centerを参照してください。

Web サイトのタイプ

Web サイトのタイプごとに、異なるソリューションを必要とし、異なるアプリケーションおよび機能を使用します。 このセクションでは、さまざまな Web サイトの例と、それらを配信するのに必要なタイプのアプリケーションおよび機能を示します。

イントラネット・ポータル

イントラネット・ポータル・サイトは、従業員に情報を迅速に配信できるようにし、共通の社内ビジネス・プロセスを効率化し、組織内で連帯感を持たせるために設計されています。

このサイトでは、以下の内容にアクセスできます。

  • 組織内での出来事に関するニュース。
  • 従業員が留意すべき (場合によっては行動が求められる) 情報を含む通知。
  • 休暇申請、購入、出張といった各種の社内プロセスを処理するためのフォーム。
  • 方針および手順に関するオンライン版の文書すべてを備えた、方針および手順のライブラリー。
  • ブログおよびフォーラムなどのコラボレーション機能を備えた、組織のコミュニティー。
  • 従業員によるコンテンツの検索を可能にする検索システム。

さらに、イントラネット・ポータルには個別設定されるホーム・ページがあります。 このページは、現在のユーザーの役割、部門、場所に基づいてコンテンツを取得する一式のルールを使用して、動的に構築されます。適切にコンテンツをタグ付けし、そのコンテンツを現在のユーザーに突き合わせることにより、そのユーザーに合ったコンテンツを表示することが可能になります。

このイントラネット・ポータルを機能させるには、以下に示す数多くのコンポーネントを組み合わせて使用します。
  • WebSphere Portal を使用して、イントラネット・ポータルを形成するコンテンツおよびアプリケーションを統合するためのプラットフォームを提供します。
  • イントラネットにおける全体のテーマおよび最上位ナビゲーションも、WebSphere Portal を使用して管理します。
  • Web Content Management は、ポータル内にあるコンテンツのミクロ・レベルのレイアウトを提供し、ニュース、通知、およびコミュニティーのコンテンツを直接構築するためにも使用されます。
  • 各フォームは、フォーム/リスト・システムを使用して構築されたオンライン・アプリケーションであり、Web Content Management を使用してサイトに取り込みます。
  • 方針および手順は、IBM FileNet Content Manager を使用して管理される文書ライブラリーです。
  • IBM FileNet Content Manager からのフィードを Web Content Integrator でコンシュームできるようにカスタム・フィード・プロデューサーを作成し、Web Content Management を使って Web サイトの文書を提供することができます。
  • Personalization を使用してコンテンツとユーザーを関連付けることにより、動的にコンテンツを生成して、個別設定されたホーム・ページに表示します。
  • サード・パーティーのディスカッション・システムは、カスタム・ポートレットを使用してサイトのコミュニティー・セクションでコラボレーション・フォーラムを提供するために使用します。
  • コミュニティー領域は、Lotus Quickr チーム・ルームを基礎にすることもできます。
  • Web Content Management によるカテゴリー化と WebSphere Portal 検索を使用することにより、単純なテキスト検索と、カテゴリー・ベースの高機能な検索の両方を提供します。

イントラネット・ポータルのサイズは、組織の規模に応じたものになる傾向があります。大規模な組織では、配信する情報、ビジネス・プロセス、および従業員のコミュニティーはいっそう多くなります。つまり、コンテンツとユーザー数は同じ割合で増加する傾向があります。

e-business サイト

e-business サイトは外部に向けられたサイトで、企業の製品やサービスを消費者に売り出して、消費者がオンライン上でこれらの品目を購入できるように設計されています。 サイトのねらいは、消費者が自分のニーズに合致する適切な製品またはサービスを見つけられるように支援し、消費者の購買量を最大限に高めることにあります。

このサイトでは、以下の内容を提供します。
  • 企業の製品およびサービスに関する最新ニュースについてのプレス・リリース。
  • セール、特別セット販売、ディスカウントを含む、製品およびサービスに関する情報を提供する販促領域。
  • 検索可能な分類構造で表示されるカタログ全体を含む、製品およびサービスのカタログ領域。
  • ユーザーが以下の内容を閲覧可能なショッピング領域。
    • オンラインで購入できる、選択可能な製品およびサービスの検索可能なリスト。
    • 購入を検討している品目の要約。
    • 税額、送料、その他の費用を計算する領域。
    • これらの品目をオンライン、メール・オーダー、または販売スタッフからの折り返し電話により購入するための領域。
    • 注文済みの内容を追跡するための領域。
  • 顧客を支援するために企業が使用する、製品およびサービスについて説明した記事。
  • 技術文書、連絡先電話番号、サポート要求フォーム、FAQ、およびダウンロードなどが含まれる、サポート領域。
  • 新しい販売促進商品、製品、または記事を目立たせた更新情報を定期的にユーザーが受信できるよう、ニュースレターを購読するためのサービス。

サイトのホーム・ページは、最新の販売促進商品を目立たせ、組織のブランドを強く印象付けるために使用します。 サイト全体において、協調フィルタリングを使用することにより、利用者の購買活動およびナビゲーション活動に基づいて製品およびサービスを各利用者に提案できるようにします。 また、ディスカッション・システムを使用することにより、ユーザーがコミュニティーを形成して、さまざまな製品およびサービスについてコメントおよび評価できるようにすることも可能です。

e-business サイトを構築するには、以下に示す数多くのコンポーネントを組み合わせて使用します。
  • WebSphere Portal を使用して、e-business サイトを形成するコンテンツおよびアプリケーションを統合するためのプラットフォームを提供します。
  • イントラネットにおける全体のテーマおよび最上位ナビゲーションも、WebSphere Portal を使用して管理します。
  • Web Content Management は、サイト内にあるコンテンツのミクロ・レベルのレイアウトを提供し、プレス・リリース、FAQ、記事、および販促用のコンテンツを直接構築するためにも使用されます。
  • カタログ領域およびショッピング領域は、Websphere Commerce を使用して実行されます。
  • Personalization は、協調フィルタリングに基づいて製品をユーザーに提案し、ニュースレターを E メール送信するために使用します。
  • サード・パーティーのディスカッション・システムは、カスタム・ポートレットを使用してサイトのコミュニティー・セクションでコラボレーション・フォーラムを提供するために使用します。

e-business サイトでは、比較的少量のコンテンツで、大量のトラフィックをもたらすことが可能です。

ブローシュアウェア・サイト

ブローシュアウェア・サイトは、ワールド・ワイド・ウェブ上で組織の存在を示す、外部に向けられたサイトです。 主要な目的は、潜在顧客に対して組織のブランドを印象付けることです。

このタイプのサイトは割合に静的で、WebSphere Portal の集約機能を必要としない代わりに、Web Content Management のサーブレット配信と事前レンダリングの機能を両方とも使用して配信します。 また、Google などの検索エンジンによって容易に索引付けされるようにサイトを設計します。

サイトには、以下のような内容が含まれます。
  • 組織の理念、目標、任務、沿革といった、組織に関する情報。
  • 現在および将来に向けて組織が行っていることについて説明する、ニュース領域。
  • 所在地、電話番号、およびオンライン問い合わせ用フォームがリストされた連絡先領域。 ここからユーザーは、問い合わせをしたり、電話によるフォローアップを依頼したりできます。
  • 組織が求人情報を載せる採用情報領域。
  • 組織の提携先がリストされた提携先領域。 ここには、提携先に関する情報や、それらと当該組織との関係に関する情報、さらに提携先の Web サイトへのリンクおよび連絡先情報が含まれます。
  • 組織の製品およびサービスに関する情報。これには、ケース・スタディーおよび推奨意見なども含まれます。

このサイトのコンポーネントは Web Content Management によるものに限られており、これによってプレゼンテーション、ナビゲーション、およびコンテンツのすべてが提供されます。

ブローシュアウェア・サイトでは、比較的少量のコンテンツで、大量のトラフィックをもたらすことが可能です。

エレクトロニック・ライブラリー・サイト

オンライン・ライブラリー・サイトは、もっぱら大容量のコンテンツにアクセスするためのサイトです。 典型的な例はニュース・サイトです。 ここでは新しいコンテンツが、毎日欠かさず終日作成されてオンライン上に公開され、古くなるとアーカイブされます。 他の例としては、雑誌、アナリスト・レポート、およびソフトウェア・ライブラリーなどがあります。

これらのサイトでは通常、ユーザー登録が必要です。 こうして、最新のコンテンツを要約した E メールを定期的に受信できる場合もあります。 ニュース・サイトでは、最新のニュースは無料でも、アーカイブされたコンテンツへのアクセスは有料である場合があります。 他のタイプのライブラリー・サイトでは、どのコンテンツへのアクセスも有料である場合があります。

エレクトロニック・ライブラリー・サイトを配信するには、以下に示す数多くのコンポーネントを組み合わせて使用します。
  • WebSphere Portal を使用して、e-business サイトを形成するコンテンツおよびアプリケーションを統合するためのプラットフォームを提供します。
  • イントラネットにおける全体のテーマおよび最上位ナビゲーションも、WebSphere Portal を使用して管理します。
  • Web Content Management は、サイト内にあるコンテンツのミクロ・レベルのレイアウトを提供し、コンテンツを直接構築するためにも使用されます。
  • コンテンツを文書として公開するエレクトロニック・ライブラリーの場合、IBM FileNet Content Manager を使用して文書を保管および管理することが考えられます。
  • IBM FileNet Content Manager からのフィードを Web Content Integrator でコンシュームできるようにカスタム・フィード・プロデューサーを作成し、Web Content Management を使って Web サイトの文書を提供することができます。

エレクトロニック・ライブラリー・サイトは、利用者が多く、コンテンツも大容量になることがあります。

パートナー・サイト

パートナー・サイトの利用者は、組織の提携先です。 このサイトで提供される情報およびアプリケーションは、対象となる利用者が広範囲ではありません。 パートナー・サイトでは通常、ログインを必要としますが、自動登録システムは使用されません。 ビジネス・パートナーは、当該の企業によって認識されており、パートナー・サイトにアクセスするためのログイン情報が与えられます。

パートナー・サイトには、以下のような領域が含まれます。
  • 提携先に焦点を合わせたニュース領域。 複数の業務領域で活動する大規模な組織では、各提携先に合わせてニュース領域を個別設定することもできます。
  • 提携先向けの特別な取引について説明する販促領域。
  • 提携先が使用する計算機能、フォーム、およびカタログなどの役立つツールおよびリソースを提供する、オンライン・サービス。
  • 当該組織からの契約済みサービスに対する現在の請求状況を提携先が確認できる、請求領域。
  • 提携先が自身の情報を掲示したり、相互に協力し、当該組織からの支援を得るためにやり取りしたりする、コミュニティー領域。
パートナー・サイトを配信するには、以下に示す数多くのコンポーネントを組み合わせて使用します。
  • WebSphere Portal を使用して、イントラネット・ポータルを形成するコンテンツおよびアプリケーションを統合するためのプラットフォームを提供します。
  • イントラネットにおける全体のテーマおよび最上位ナビゲーションも、WebSphere Portal を使用して管理します。
  • Web Content Management は、ポータル内にあるコンテンツのミクロ・レベルのレイアウトを提供し、ニュースおよび販促用のコンテンツを直接構築するためにも使用されます。
  • 各種の IBM 製品とサード・パーティーのアプリケーションを使用して、オンライン・サービス領域を構築およびデプロイします。
  • サイト内のカタログ・サービスおよび請求サービスは、WebSphere Commerce を使用して実行されます。
  • サード・パーティーのディスカッション・システムは、カスタム・ポートレットを使用してサイトのコミュニティー・セクションでコラボレーション・フォーラムを提供するために使用します。
  • Personalization を使用してサイト全体のコンテンツをフィルタリングし、適切なコンテンツおよびインライン・サービスが該当する提携先に提供されるようにします。

パートナー・サイトはおそらく、利用者が限られていますがコンテンツは大規模でしょう。

Web コンテンツ・ライブラリー・デフォルト項目

Web コンテンツ・ライブラリーを作成するとき、新規ライブラリーの中にデフォルト Web コンテンツ項目のセットを含めるよう選択することができます。 Web Content Management システムおよび Web サイトの開始点としてこれらを使用できます。

デフォルト項目

ライブラリーの作成時に「新しいライブラリーにデフォルトの項目を含める」を選択すると、以下の項目が作成されます。

ワークフロー項目:
  • 「Express Workflow」という名前のワークフロー。これには「公開」という公開アクションを使用する「公開ステージ (Publish Stage)」という名前の 1 つのワークフロー・ステージが含まれます。
  • 以下のワークフロー・ステージを使用する「3 ステージ・ワークフロー (Three Stage Workflow)」というワークフロー。
    • ドラフト・ステージ (Draft Stage)
    • 「公開」という公開アクションを使用する「公開ステージ (Publish Stage)」
    • 「期限切れ」という期限切れアクションを使用する「期限切れステージ (Expire Stage)」
オーサリング・テンプレート:
オーサリング・テンプレートは「記事 (Article)」という名前で、「本文 (Body)」という 1 つのリッチ・テキスト要素を含み、このオーサリング・テンプレートを使って作成されるコンテンツ項目のデフォルト・ワークフローとして「Express Workflow」を使用します。
プレゼンテーション・テンプレート:
プレゼンテーション・テンプレートは「単純な記事レイアウト (Simple Article Layout)」という名前です。
サイト・エリアおよびコンテンツ項目:
  • 「サンプル記事 (Sample Article)」および「サンプル記事 2 (Sample Article 2)」というコンテンツ項目が「記事 (Articles)」というサイト・エリアに保管されます。
  • 「記事 (Articles)」というサイト・エリアには、「記事 (Article)」というオーサリング・テンプレートと「単純な記事レイアウト (Simple Article Layout)」というプレゼンテーション・テンプレートの間のテンプレート・マップが含まれます。
コンポーネント:
  • 「記事ツールバー (Article Toolbar)」というオーサリング・ツールは、レンダリングされるページに「新規」および「編集」機能を追加するために使用されます。 これは「単純な記事レイアウト (Simple Article Layout)」というプレゼンテーション・テンプレートで参照されます。
  • 「記事リスト (Articles List)」というメニューは、レンダリングされるページ上にコンテンツ項目のリストを表示するために使用されます。 これは「単純な記事レイアウト (Simple Article Layout)」というプレゼンテーション・テンプレートで参照されます。

アクセス制御

Web コンテンツ・ライブラリー・デフォルト項目は、保管場所のライブラリーからアクセス設定を継承するよう構成されるため、ライブラリーのアクセス設定が構成されるまでは、ユーザーはこれらの項目にアクセスできません。

デフォルト項目の使用

デフォルト項目を表示するには、次のように Web コンテンツ・ビューアー・ポートレットを使用するのが最適です。
  1. 「管理」>「ページの管理」に移動します。
  2. 「新規ページの作成元 (Create New Page From)」を選択します。
  3. 「Web コンテンツのマッピング」の下で、Web コンテンツ・ライブラリーから「記事 (Articles)」というサイト・エリアを選択します。
  4. フォームの残りの部分に入力して、「OK」をクリックします。
  5. 新しいページ上のページ・レイアウトを編集して、「Web コンテンツ・ビューアー (JSR 286)」ポートレットをページに追加します。
  6. 「サンプル記事 (Sample Article)」という名前のコンテンツ項目がページに表示されます。

Web サイトの計画

ベスト・プラクティスとしては、Web サイトを作成する前に時間を取って、作成しようとする Web サイト、その Web サイトの管理に必要な Web コンテンツ・システム、システムに必要なインフラストラクチャー、および Web サイトの作成とインフラストラクチャーのインストールに必要なロールとユーザーを、分析、計画、および設計しておくことを推奨します。

プロジェクトの定義

Web コンテンツ・システムの目標、成果物、およびスコープについて理解しておくことは重要です。プロジェクト定義は、プロジェクトの「何」、「なぜ」、「誰」について定義し、Web コンテンツ・システムの全存続期間に渡り使用できます。

プロジェクト計画では、以下のような情報を定義します。

経歴

プロジェクトの経歴情報を定義します。この情報には、そのプロジェクトが行われている理由や過去および現在の関連プロジェクトのすべての履歴を含めることができます。

任務

プロジェクトの任務を明確にします。任務についての記述を書くと、Web サイトの要件を決める際に役立ちます。

目標

プロジェクトの目標を決めることは大切です。これらの目標は、プロジェクト・チームが提供できるもので、プロジェクト・ステークホルダーとのミーティングやユーザーとのユーザビリティー・ワークショップによって決めることができます。サイトの最終目標について、すべてのステークホルダーが合意していることは重要です。各目標は、明確で簡潔なものでなければなりません。仮定や解釈の違いの余地があってはなりません。

ビジネス目標
これらの目標は、ビジネスで成し遂げたいことを定義します。利益やブランドの価値などの関心事にフォーカスします。
インターネット・サイトのビジネス目標の例には、以下のようなものが含まれます。
  • プレス・リリースや営業資料の配布コストの削減
  • サポート・チームが受ける電話の回数の削減
  • 既存顧客のロイヤルティーの強化
  • 潜在的な顧客のオンラインでの発見
イントラネットのビジネス目標の例には、以下のようなものが含まれます。
  • 会社内の主要グループに合わせて専門化され調整されたコンテンツの提供
  • 従業員が尊重されていると確実に感じるようにする
  • スタッフのコア作業を改善することにより、生産性を上げてビジネス・コストを削減する
運用目標
運用目標は、短期間と長期間の目標にグループ化できます。
運用目標の例には、以下のようなものが含まれます。
  • 会社の従業員に情報を提供する
  • 顧客に情報を提供する
  • 会社内の Web サイト管理スキルを開発する
  • シングル・サインオン機能を開発する
ユーザー目標
これらの目標は、Web サイトのユーザーのニーズを定義し、サイト目標、構成、および機能を開発するのにきわめて重要です。
インターネット・サイトのユーザー目標の例には、以下のようなものが含まれます。
  • 望むものを容易に見つけられる
  • 情報が理解しやすく適切
  • サイトのどこにいるかが分かる
  • プライバシーが保たれる
イントラネットのユーザー目標の例には、以下のようなものが含まれます。
  • 最新の適切な情報が、可能な限り早く見つかる
  • 最新のニュースと更新を知らせてくれる
  • タイム・カードや休暇願の記入などのコア・ビジネス機能を行う際に役立つ
  • フラストレーションを削減してくれる
  • 情報を公開できる
  • つながっていて、サポートされていて、尊重されていると感じられるようにしてくれる
サイト目標
サイト目標は、ビジネス目標、運用目標、およびユーザー目標から派生させます。ビジネス目標、運用目標、ユーザー目標の論理積、または分析の結果である追加の目標かもしれません。
インターネット・サイトのサイト目標の例には、以下のようなものが含まれます。
  • ユーザーが素早く情報を見つけられる、明確で理解しやすいナビゲーションを提供する
  • 検索機能を提供する
  • 読みやすく理解しやすい Web コンテンツを作成する
  • サポート・チームが最もよく尋ねられる質問について扱った FAQ セクションを提供する
  • ビジネス上の部門ではなく、ユーザー用のコンテンツを構成するフレームワークを提供する
イントラネットのサイト目標の例には、以下のようなものが含まれます。
  • ユーザーが素早く情報を見つけられる、明確で理解しやすいナビゲーションを提供する
  • タイム・カードの入力などの主要な共通作業をサポートする
  • カスタマイズされたニュース・セクションを提供する
  • サポート・チームが最もよく尋ねられる質問について扱った FAQ セクションを提供する
  • ビジネス上の部門ではなく、ユーザー用のコンテンツを構成するフレームワークを提供する
  • イントラネットに公開される前に、ワークフローを構成するコンテンツをスタッフが入力できるようにする

プロジェクト・チーム

プロジェクトに関係する各チームの役割とチームの組織を定義します。 プロジェクト・チームの例には、以下のようなものが含まれます。
エグゼクティブ・スポンサー
プロジェクトの所有者および推進者
プロジェクト・チーム
日常の管理、分析、および新規サイト構築の責任を持ちます
参照グループ
ニーズが対象になっているか確認する、ビジネス単位の代表者
フォーカス・グループ
新規サイトがユーザーに焦点を当てているか確認する、ユーザーの代表者

成果物

プロジェクトのすべての成果物に関する文書。成果物とは何かということと配信のために予想される時間フレームに関して記述します。

人事計画

これらの役割は、Web サイトを作成して管理する担当者によって行われる作業のタイプを示す例です。 単一の個人が、このセクションで概説されている複数の役割を担当することもあります。 Web サイトをサポートするために組織に実装する役割は、デプロイ先のシステムのサイズと複雑性に応じて決まります。 すべての Web サイトで、以下の役割のすべてが必要になるわけではありませんが、 どのようなシステム・デプロイメントであってもこれらの役割のすべての側面を検討する必要があります。

プロジェクト管理者

大きく複雑なデプロイメントでは、 システムをデプロイするために十分なリソースが使用可能であること、適切なユーザーがプロジェクトに割り当てられていること、 およびシステムのデプロイに必要なタスクがデプロイメント・プロセス全体の中の適切な時点で生じることを、 プロジェクト管理者が確認する必要があります。

プロジェクトを定義する:
Web コンテンツ・システムの目標、成果物、およびスコープについて理解しておくことは重要です。プロジェクト管理者は、プロジェクトの全体的な範囲と目標を文書化するプロジェクト計画の作成を担当します。
サイト・プロトタイプおよび設計文書の開発を監督する:
プロジェクト管理者は、プロジェクトを定義して分析文書を作成した後に、サイト・プロトタイプおよび設計文書の開発を監督します。
プロジェクトに最適なレベルの人的および物理的なリソースがあることを確認する:
プロジェクト管理者は、Web サイトおよび関連したインフラストラクチャーの初期設計、 開発、および継続的な保守のために、十分な人的および物理的リソースが計画されるようにすることを担当します。
Web サイトの管理と配信に使用されるハードウェアおよびソフトウェアのデプロイメントおよびインストールをプロジェクト管理する:
プロジェクト管理者は、Web サイトの管理と配信に使用されるハードウェアおよびソフトウェアのデプロイメントおよびインストールの監督を担当します。 プロジェクト管理者は、デプロイメント全体の進行を監視して、予定どおりの時期と予算で各段階に到達できるように適切なアクションを起こします。
Web サイトの管理と配信に使用されるハードウェアおよびソフトウェアの継続的な保守と維持をプロジェクト管理する:
プロジェクト管理者は、Web サイトおよび関連するインフラストラクチャーの、継続的なモニターと保守のための計画を策定します。

ビジネス分析者

ビジネス分析者は、分析文書の作成を担当します。

ビジネス分析者は、分析文書の作成を担当します。 この文書は、Web サイト、そのコンテンツ、およびその機能の設計を決めるために、ステークホルダーから収集した情報を記録するために使用されます。 分析文書には、以下に関する情報が含まれます。
  • システムを使用するユーザーのタイプ
  • Web サイトで必要とされる機能およびアプリケーション
  • 新しい Web コンテンツ・システムにインポートする必要のある既存のコンテンツ、および作成する必要のある新規コンテンツ

アーキテクチャーおよび設計チーム

アーキテクチャーおよび設計チームは、分析文書に収集されたデータに基づいて、WebSphere Portal システムに必要なすべてのものを文書化します。 チームが作成する設計文書は、デプロイメントおよび開発チームによって WebSphere Portal システムをデプロイおよび管理するために使用されます。

技術アーキテクチャー・チーム

技術面の企画者は、システム全体に必要な全体的なサーバー・トポロジー、およびシステムを形成するサーバーのアーキテクチャーの設計を担当します。 技術アーキテクチャー・チームには、技術面の企画者、データベース企画者、セキュリティー企画者、パフォーマンス技術者、 および他の要員が必要に応じて組み込まれます。

サーバー・アーキテクチャーを決める:
技術面の企画者は、Web サイトを配信するために必要なすべてのサーバーと関連するソフトウェアについて記述するサーバー・アーキテクチャーの設計を担当します。
データベース・アーキテクチャーを決める:
データベース企画者は、 システムで使用されるデータベースに必要なすべての構成設定を記述するデータベース・アーキテクチャーの設計を担当します。
シンジケーション戦略を決める:
技術面の企画者は、Web コンテンツ・システム内の異なる環境間で必要なシンジケーション戦略を決めます。
セキュリティー・アーキテクチャーを決める:
セキュリティー企画者は、さまざまなタイプのユーザーがその役割に適した機能とコンテンツにのみアクセスできるようにするための、 すべてのグループ、役割、およびアクセス・レベルについて記述したセキュリティー・アーキテクチャーの設計を担当します。
コンテンツ取得アーキテクチャーを決める:
技術面の企画者は、既存のコンテンツを新しい Web コンテンツ・システムにインポートする際に使用するメソッドの技術的な詳細を記述した、コンテンツ取得の設計を担当します。 インポートするコンテンツは、分析文書に収集された情報に基づいています。
デリバリー戦略を決める:
技術面の企画者は、配信される Web サイトのタイプに最適な配信方式の決定を担当します。
システム保守戦略を決める:
技術アーキテクチャー・チームは、システムに対する継続的な保守の戦略と手順の決定も担当します。

情報企画者

情報企画者は、分析文書で収集した要件に基づいて、Web サイトの全体的な情報構造を決めます。

Web サイト構造を決める:
情報企画者によって設計された Web サイト構造によって、以下が決まります。
  • ポートレット配信を使用する場合に作成することが必要となるポータル・ページ。
  • 作成することが必要となるサイト・エリア。
必要なコンテンツ・タイプを決める:
Web サイト構造の各セクションで必要なコンテンツ・タイプによって、以下が決まります。
  • 必要なオーサリング・テンプレート
  • 必要なプレゼンテーション・テンプレート
  • 必要なテンプレート・マップ
コンテンツ・プロファイルのアーキテクチャーを決める:
情報企画者は、メニューなどの機能に必要なコンテンツ・プロファイルを決めます。

Web サイト設計者

Web サイト設計者は、Web サイト内の Web ページのレイアウトおよびスタイルの設計を担当します。 Web サイトのグラフィックスおよびカラー・スキームの作成のために、グラフィック設計者が採用されることもあります。

必要なテーマ、スタイル・シート、およびテンプレートを決める:
Web サイト設計者は、Web サイトを配信するために必要なテーマ、スタイル・シート、およびプレゼンテーション・テンプレートを決めます。
どのエレメントおよびコンポーネントが必要かを決める:
サイトに必要なページ・タイプおよびプレゼンテーション・テンプレートによって、以下が決まります。
  • 必要なコンポーネント
  • 各オーサリング・テンプレートで必要なエレメント
  • サイト・エリアに保管する必要のあるエレメント
パーソナライゼーション戦略を決める:
Web サイト設計者は、Web サイトに必要なパーソナライゼーション戦略を決めます。

オーサリング・システム企画者

オーサリング・システム企画者は、Web コンテンツの作成および管理に使用されるオーサリング・システムのアーキテクチャーを決めることを担当します。

ライブラリー・アーキテクチャーを設計する:
オーサリング・システム企画者は、Web サイトに必要なライブラリーを決めます。
必要なオーサリング・テンプレートを決める:
オーサリング・システム企画者は、オーサリング・システムで使用される各オーサリング・テンプレートの構成、 およびオーサリング・テンプレートとプレゼンテーション・テンプレートをリンクするために必要なテンプレート・マップを文書化します。
フォルダー・アーキテクチャーの設計
オーサリング・システム企画者は、論理グループ内の項目タイプを保管するために必要なフォルダーを決めます。
変更管理モデルを設計する:
オーサリング・システム企画者は、承認プロセスの管理に必要なワークフロー、およびワークフローを必要とする項目を決めます。
バージョン管理戦略を決める:
オーサリング・システム企画者は、Web コンテンツ・システムに適用する必要のあるバージョン管理戦略を決めます。

デプロイメント・チーム

デプロイメント・チームは、技術設計チームが作成した設計文書に基づいて、 WebSphere Portal システムを構築して管理します。

データベース・アドミニストレーター

データベース・アドミニストレーターは、データベース企画者が開発したテクニカル・アーキテクチャーに基づいて、 データベース・サーバーおよびデータ・リポジトリーをデプロイすることを担当します。

データベース・アドミニストレーターは、Web サイトおよび関連したシステムによって使用されるすべてのデータベースのインストールを担当します。 アドミニストレーターがセットアップするデータベースは、技術面の企画者およびデータベース企画者によって開発されたテクニカル・アーキテクチャーに基づきます。 データベース・アドミニストレーターは、データのユーザー文書および Web コンテンツ・システムで使用されるユーザー・リポジトリーに精通する必要があります。

WebSphere Portal 管理者

WebSphere Portal アドミニストレーターは、技術面の企画者が開発したアーキテクチャーに基づいて、 WebSphere Portal デプロイメント内のサーバーの全体的なデプロイメントおよび管理を担当します。

WebSphere Portal のインストールと構成
WebSphere Portal アドミニストレーターは、システム全体で使用される WebSphere Portal のすべてのインスタンスのインストールおよび構成を担当します。
マイグレーション:
WebSphere Portal アドミニストレーターは、WebSphere Portal の以前バージョンからデータおよび構成設定をマイグレーションすることを担当します。

Web コンテンツ・アドミニストレーター

Web コンテンツ・アドミニストレーターは、 WebSphere Portal システム内での Web コンテンツ・サーバーの構成を担当します。

Web コンテンツのオーサリング環境
Web コンテンツ・オーサリング環境で、Web コンテンツ・アドミニストレーターは以下のタスクを実行します。
新規ページを作成。
アドミニストレーターは、さまざまなユーザーによって使用される追加のオーサリング・ポートレットを表示するため、 または内部のサイトをプレビューする Web コンテンツ・ビューアー・ポートレットを表示するために、新しいページを作成しなければならないことがあります。
オーサリング・ポートレットの構成
オーサリング環境内の各オーサリング・ポートレットは、 各オーサリング・ポートレットを使用するユーザーのために正しく構成されていることを確認できるように、構成される必要があります。
Web コンテンツ・ビューアー・ポートレットの構成
オーサリング環境内の各 web コンテンツ・ビューアー・ポートレットは、 プレビュー中のコンテンツを表示するように構成する必要があります。
web コンテンツ・ライブラリーの作成
web コンテンツ・アドミニストレーターは、 web コンテンツ企画者の推奨に基づいて、web コンテンツ・ライブラリーのセットを作成します。
web コンテンツ・リポジトリーの複製
シンジケーションを使用可能にする前に、web コンテンツ・アドミニストレーターはデータベース・アドミニストレーターと共に、 web コンテンツ・リポジトリーをオーサリング環境から他の環境に複製します。
シンジケーションの管理
シンジケーション関係は、通常はサブスクライバー・サーバーで作成されます。 通常はオーサリング環境から他の環境にシンジケーションするだけなので、 オーサリング環境からシンジケーション関係を作成することは普通ありませんが、 Web コンテンツ・アドミニストレーターはシンジケーション設定および構成を管理する必要が生じることがあります。
フィード構成およびジョブの作成および管理
Web コンテンツが外部システムに保管されて保守されることがあります。 Web Content Integrator により、フィードを使用して外部システムからのコンテンツをコンシュームします。
オーサリング環境の構成設定の調整
オーサリング環境の構成設定を特定の機能に合わせて調整できます。
Web コンテンツの配信環境
Web コンテンツ配信環境で、Web コンテンツ・アドミニストレーターは以下のタスクを実行します。
新規ページを作成。
アドミニストレーターは、Web コンテンツ・ビューアー・ポートレットを使用してコンテンツを表示するとき、 新しいページを作成する必要があります。
Web コンテンツ・ビューアー・ポートレットの構成
配信環境内の各 Web コンテンツ・ビューアー・ポートレットは、 正しいコンテンツを表示するように構成する必要があります。
シンジケーションの管理
Web コンテンツ・アドミニストレーターは、Web コンテンツのステージングおよびオーサリング環境から配信環境へのシンジケーション関係を作成します。
配信環境の構成設定の調整
配信環境の構成設定を特定の機能に合わせて調整できます。
UAT 環境で:

ユーザー受け入れテスト環境は、実行される UAT のタイプに応じて、オーサリング環境および配信環境と類似したものにセットアップされます。 UAT 環境のセットアップに必要なタスクは、オーサリング環境および配信環境と同じです。

セキュリティー・アドミニストレーター

セキュリティー・アドミニストレーターは、アクセス制御戦略やファイアウォールなど、システム全体の保護を担当します。

セキュリティー・アーキテクチャー文書に概要が示されたセキュリティー計画を実装する:
セキュリティー・アドミニストレーターは、 セキュリティー企画者が作成したセキュリティー・アーキテクチャー文書に概要が示されたセキュリティー機能およびプロセスの実装を担当します。
ユーザー・レジストリーの管理
セキュリティー・アドミニストレーターは、さまざまな更新削除タスクを実行して、セキュリティー・レジストリーを保守します。
ユーザーおよびグループの管理:
セキュリティー・アドミニストレーターは、ユーザー・レジストリーに保管されたユーザーおよびグループを保守します。
アクセス制御の管理
セキュリティー・アドミニストレーターは、ページ、ポートレット、モジュール、および他のアプリケーションへのアクセス制御を管理します。
追加セキュリティー・タスク
使用している環境に応じて、セキュリティー・アドミニストレーターが実行する他のさまざまなタスクがあります。

開発チーム

開発チームは、技術設計チームが作成した設計文書に基づいて、 製品 API を使用したカスタム・アプリケーションの作成を担当します。

ポートレット開発者

ポートレット開発者は、新しいポートレットの開発を担当します。

ポートレット開発者は、外部アプリケーションからのコンテンツおよび機能を集約するために使用される、カスタム・ポートレットの作成を主に担当します。 開発されるポートレットは、設計文書で識別されるポートレットに基づいています。

テーマ開発者

テーマ開発者は、情報企画者およびグラフィック設計者によって作成された設計に基づく、新しいテーマの作成を担当します。

テーマ開発者は、設計アーキテクチャーおよび Web サイト・プロトタイプで使用される HTML によって概要が示される、Web サイト設計に基づくカスタム・テーマの作成を主に担当します。 テーマとは、共通のディレクトリー構造内で一緒にパッケージ化された JSP、イメージ、およびスタイルシートのセットです。wps.war 内に直接パッケージ化するか、別個の WAR ファイル内にパッケージ化できます。そのテーマだけでパッケージ化するか、または他のテーマ、スキン、およびリソースと共にパッケージ化することができます。

Web コンテンツ開発者

Web コンテンツ開発者は、Web Content Management API を使用し、 JSP コンポーネントを開発し、Web コンテンツ・プラグインを作成することにより、 Web Content Management を拡張することを担当します。

Web Content Management API
Web Content Management API を使用してWeb Content Management の機能を拡張することができます。
カスタム・オーサリング・インターフェース
カスタム・オーサリング・インターフェースは、 オーサリング・ポートレットの使用に代わるものとして、コンテンツ作成者によって使用されます。
カスタム・プラグイン
カスタム・ワークフロー・アクションや複数ロケール・サイト用のテキスト・プロバイダーなどのカスタム・プラグインを作成して、 サイトにカスタム機能を追加できます。

Web サイト作成チーム

Web サイト作成チームは、技術設計チームが作成した設計文書に基づいて、 Web サイトおよび関連するシステムの作成を担当します。

Web サイト・クリエーター

Web サイト・クリエーターは、プレゼンテーション・テンプレート、オーサリング・テンプレート、サイト・エリア、コンポーネント、およびカテゴリーを作成することにより、 Web サイトの構築を担当します。 また、Web サイト・クリエーターはフォルダーやワークフローなどのコンテンツ管理項目の作成も担当します。 Web サイト・クリエーターによって作成される項目は、 情報企画者およびグラフィック設計者によって作成される設計に基づいています。

Web コンテンツ管理項目の作成
Web サイトを作成する前に、Web コンテンツ・クリエーターは以下の必要なコンテンツ管理項目を最初に作成します。
フォルダーの作成
フォルダーは、論理グループ内の項目タイプを保管するために使用されます。
ワークフローの作成
ワークフローは、項目の承認プロセスを管理するために必要です。
プロジェクトの作成
プロジェクトは、一連の項目の承認プロセスを管理するために使用されます。
Web サイトの作成
Web サイトを作成するには、 以下の Web Content Management 項目を作成する必要があります。
サイト・エリア
サイト・エリアは、サイトのサイト・フレームワークを定義するために使用されます。 サイト・フレームワークの一部を形成するコンテンツ項目は、 サイト・フレームワーク内に保管されます。
オーサリング・テンプレート
オーサリング・テンプレートは、Web サイト内のさまざまなタイプのページのために必要です。コンテンツ作成者によって作成されるコンテンツ項目は、Web サイト・クリエーターによって作成されるオーサリング・テンプレートに基づいています。
プレゼンテーション・テンプレート
プレゼンテーション・テンプレートによって Web サイト内のページのレイアウトが決まり、 それらはサイト・エリアで定義されたテンプレート・マップによってオーサリング・テンプレートにリンクされます。
エレメントおよびコンポーネント
エレメントは、さまざまなタイプのコンテンツを保管するために、オーサリング・テンプレートおよびサイト・エリアに追加されます。 コンポーネントは、Web サイト全体で再利用できる単一のエレメントを作成するために使用されます。
カテゴリー
カテゴリーは、コンテンツ・プロファイルを許可するように構成されたプロファイル項目で使用されます。

web コンテンツ作成者

Web コンテンツ作成者は、Web Content Managementを使用して開発および管理されるサイトの Web コンテンツの作成を担当します。

コンテンツ作成者は、オーサリング・ポートレットにアクセスして、またはカスタム・コンテンツ・オーサリング・インターフェースを使用して、 コンテンツを作成します。
コンテンツ項目の作成
プレゼンテーション・テンプレートによって Web サイト内のページのレイアウトが決まり、 それらはサイト・エリアで定義されたテンプレート・マップによってオーサリング・テンプレートにリンクされます。
エレメントおよびコンポーネントに関する作業
エレメントは、さまざまなタイプのコンテンツを保管するために、オーサリング・テンプレートおよびサイト・エリアに追加されます。 コンポーネントは、Web サイト全体で再利用できる単一のエレメントを作成するために使用されます。

Web コンテンツ管理者

Web コンテンツ管理者は、継続的なサイト保守活動の実行を担当します。

項目の移動、リンク、およびコピー:
ときどき、Web コンテンツ管理者は項目を移動またはコピーして、Web サイトの構造を再設計する必要があります。
オーサリング・テンプレートの管理:
ときどき、Web コンテンツ管理者はコンテンツ項目によって使用されるオーサリング・テンプレートを再適用または変更する必要があります。
項目の復元:
ときどき、Web コンテンツ管理者は項目を以前に保存されたバージョンに復元する必要があります。
ユーザー・プロファイルの編集:
Web コンテンツ・システムに特定のプロファイル情報をユーザー・プロファイルに追加することにより、 ユーザーの特定のセットに合わせてコンテンツを個別設定できます。
アクセス制御の管理
ときどき、Web コンテンツ管理者は項目のセットに対するアクセス制御を再適用または変更する必要があります。

コンテンツ取得チーム

コンテンツ取得チームは、分析文書で識別されるコンテンツに基づいて、レガシー・システムのコンテンツを新しい Web サイトにインポートすることを担当します。 チームは管理者と開発者の両方から構成されます。 チームのメンバーは、レガシー製品と WebSphere Portal との両方に精通していることが必要です。

Web Content Management API:
Web Content Management API を使用して、コンテンツを Web Content Management にインポートできます。
Web コンテンツ・フィード
Web Content Integrator により、フィードを使用して外部システムからのコンテンツをコンシュームします。
Web コンテンツのために WebDAV を使用する:
IBM WebSphere Portal 用の WebDAV によって、 標準のオーサリング・ポートレットではなくオペレーティング・システムの標準的なツールを使用して Web コンテンツを作成、変更、および削除できます。

保守チーム

保守チームは、技術設計チームが作成した保守アーキテクチャーに基づいて、 システム全体の継続的なモニターおよび保守を担当します。

データベース・アドミニストレーター

データベース・アドミニストレーターは、すべてのデータベースをセットアップした後に、 システム内のすべてのデータベースの継続的なモニターおよび保守を担当します。

WebSphere Portal アドミニストレーター

WebSphere Portal アドミニストレーターは、 システム内の WebSphere Portal サーバーの継続的な保守を担当します。

Web コンテンツ・アドミニストレーター

シンジケーションの管理:
シンジケーション関係は、通常はサブスクライバー・サーバーで作成されます。 通常はオーサリング環境から他の環境にシンジケーションするだけなので、 オーサリング環境からシンジケーション関係を作成することは普通ありませんが、 Web コンテンツ・アドミニストレーターはシンジケーション設定および構成を管理する必要が生じることがあります。
フィード構成およびジョブの管理:
Web コンテンツが外部システムに保管されて保守されることがあります。 Web Content Integrator により、フィードを使用して外部システムからのコンテンツをコンシュームします。
オーサリング・システムの保守:
ときどき、Web コンテンツ・アドミニストレーターは保守タスクを実行する必要があります。

セキュリティー・アドミニストレーター

ユーザー・レジストリーの管理
セキュリティー・アドミニストレーターは、さまざまな更新削除タスクを実行して、セキュリティー・レジストリーを保守します。
ユーザーおよびグループの管理:
セキュリティー・アドミニストレーターは、ユーザー・レジストリーに保管されたユーザーおよびグループを保守します。
アクセス制御の管理:
セキュリティー・アドミニストレーターは、ページ、ポートレット、モジュール、および他のアプリケーションへのアクセス制御を管理します。
追加セキュリティー・タスク:
使用している環境に応じて、セキュリティー・アドミニストレーターが実行する他のさまざまなタスクがあります。

パフォーマンス技術者

パフォーマンス技術者は、 システム内のすべてのハードウェアおよびソフトウェアが調整されて、 パフォーマンスおよび信頼性が最高になるようにすることを担当します。

分析文書の作成

分析文書を使用して、ステークホルダーから集めた、Web サイトの設計、コンテンツ、機能を決定する情報を記録します。

Web コンテンツ・システムを設計する際に行える分析の例を以下に示します。

ユーザー分析

会社やユーザーのニーズをサポートする Web サイトを設計するには、対象者を知る必要があります。プロジェクトのこの早い段階で、ユーザーを決定することは重要です。知るべき事柄には、以下のようなものがあります。
  • 対象者。
  • 最も重要なグループ。
  • サイトで行いたいと希望していること。
  • サイトを繰り返し訪問させるようにするもの。
  • Web の経験レベル。
主なユーザー・グループをさらに理解する助けとして、ペルソナとシナリオを作成できます。
ペルソナ
ペルソナとは、サイトの主なユーザー・グループを代表する架空のユーザーのことです。複数のユーザーについて集めた情報を使用して、主な各ユーザー・グループを代表する 1 人のユーザーを作成します。ペルソナに以下のことを定義します。
  • 名前とピクチャー
  • 年齢、教育、および家族状況などの人口統計上の情報
  • 仕事上の役割および責任
  • サイトと関連した目標やタスク
  • コンピューターや Web の使用に関する経歴
シナリオ
シナリオとは、ユーザーがサイトで経験すると思われる「物語」です。 これらは、サイトやそのユーザーを視覚化する際に役立ちます。これらのものは、ナビゲーション・プロセスを全体として見る上で役立ちます。また、シナリオは、Web サイト設計が終わった後の検証にも役立ち、ユーザビリティー・テストにも使用できます。ペルソナを使用し、サイトで行うべきタスクを与えてください。そのキャラクターがサイトを使用して、与えられたタスクをどのように終わらせるかに関する物語を作成します。創造力を働かせて作成してください。

競合分析

公開する Web サイトを構築する場合、競争相手が何を行っているかを調べることは役に立ちます。 競争相手のリストを生成し、そのインターネット・サイトに関して好きな点や嫌いな点について文書化します。競争相手のサイトと比較することができないイントラネット・サイトについては、その代わりに、イントラネット・サイトが現在の規格を満たしていることを確認します。

Web サイト要件

Web サイト要件では、Web サイトの特徴や機能を記述します。この文書には、サイトに何がなければならないか、およびユーザーが何をできるかを記述します。要件文書は、Web サイトの構築方法を記述するためには使用しません。それらは、設計文書で詳述します。

以下に例を示します。
一般機能:
  • 検索
  • 連絡先に関する詳細
ユーザーが行えること:
  • 製品の購入
  • ニュースレターの申し込み
  • オンラインでのタイムカードの記入
以下のコンテンツとサイト・エリアを含めます。
  • プレス・リリース
  • ポリシーと指針
  • 関連するものへのリンク

コンテンツ・インベントリー

これは、サイトを構成するコンテンツのタイプを識別するのに役立ちます。新規 Web サイトで既存のサイトを再設計する場合、どのような既存コンテンツがありどのような新規コンテンツを作成する必要があるかを識別します。コンテンツ・インベントリーを作成し、既存 Web ページと考え得る含められそうなコンテンツのタイプを追加してください。含めるコンテンツのタイプには以下のようなものがあります。
  • 著作権表示やプライバシーに関する記述などの静的コンテンツ
  • 最新ニュースや製品キャンペーンなどの動的コンテンツ
  • ログオン・ページや E メール・ニュースレターの登録ページなどのトランザクションのコンテンツ
コンテンツ・インベントリーを作成する際には、以下の情報を集めることができます。
  • 要旨
  • トピック・エリアまたはカテゴリー
  • 優先度
  • Web ページ、ファイル、紙などの形式
  • 想定対象者
  • 関連コンテンツ
  • 作成日
  • 最終変更日
  • 所有者
  • 作成者
  • 有効期限

HTML を使用したプロトタイプ Web サイトの設計

Web コンテンツ・システムの設計文書を作成する前に、HTML を使用してサイトのプロトタイプを作成することは役に立ちます。このプロトタイプは、プロジェクト計画で定義されたにアウトラインと分析文書に収集されているデータに基づいているべきです。プロトタイプ用に開発したサイト構成、設計、および HTML コードを、設計文書に定義する項目の多くの基礎として使用できます。

HTML を使用してプロトタイプ Web サイトを作成することにより、実際の Web サイトがどのような外観になるか知ることができますし、Web コンテンツ・システムおよび Web サイトで使用する多くの機能を開発できます。

プロトタイプの構築

  • プロトタイプ Web サイトには、プロジェクト計画および分析文書で定義されている各ページ・タイプのサンプル・ページを含めるべきです。また、提案されている Web サイトの基本的なサイト構成も含めるべきです。
  • プロトタイプは、機能する Web サイトであるべきです。プロトタイプをブラウズできる、機能するナビゲーション機能を含めるべきです。実際のコンテンツの例を、プロトタイプに取り込みます。
  • プロトタイプを作成するための HTML および他のコードの大部分は Web Content Management サイトで再利用されますから、コーディング・ベスト・プラクティスに確実に合致するように注意してください。

HTML を使用してサイトの設計を計画する

コンテンツ管理システムの設計を開始するために便利な方法は、HTML を使用してサイトのプロトタイプを開発することです。 このタスクは Web コンテンツの情報企画者と協議して行ってください。

HTML サイトには、以下を含める必要があります。
  • サイトの各セクションのメイン・ホーム・ページの設計
  • 各セクションに保管されるコンテンツ・ページの設計
  • サイトのナビゲーション機能

その後、この HTML サイトを使用して、Web コンテンツ管理システム用に作成する必要のある Web コンテンツ項目を判別できます。

例えば、HTML モックアップの各 Web ページの設計により、Web Content Management サイトの異なる部分を決定できます。
  • 各 HTML ページのレイアウトによって、プレゼンテーション・テンプレートのレイアウトが決まります。
  • ナビゲーション機能の設計により、作成する必要のあるメニューおよびナビゲーターが決まります。

プレゼンテーション・テンプレートを使用して、サイト・エリア、コンテンツ項目、およびコンポーネントなどの Web コンテンツ・システムの異なる部分からのエレメントを結合させる。

イメージやスタイルシートなど、設計に含まれるその他のフィーチャーにより、 作成する必要のあるコンポーネント、および新しい WebSphere Portal テーマを開発する必要があるかどうかが決まります。

設計文書の作成

プロジェクトの定義と分析文書の作成の後、設計文書に Web コンテンツ・システムの要件を定義します。設計文書は、サイトで必要なコンテンツのタイプ、サイトの構成方法、コンテンツのオーサリング方法、そして最終的な Web サイトの外見に関する概略を示します。

サーバー・アーキテクチャー

技術面の企画者は、システムで必要な Web コンテンツ環境と、各環境で必要なシステムを定義します。 この情報によって、Web コンテンツ・システムをサポートするために必要かつ十分なリソースを供給するハードウェアが確実に備えられます。

環境アーキテクチャー

すべての Web Content Management システムは、少なくとも 1 つのオーサリング環境と 1 つの配信環境から成り立っています。 オーサリング環境は、Web サイトを構成する個々の項目の作成と管理に使用されます。配信システムは、ビューアーに Web コンテンツを配信するために使用されます。これらの環境に加え、ユーザー受け入れテスト (UAT) を行うためのテスト環境も必要になるでしょう。

技術面の企画チームは、Web Content Management システムで必要な環境アーキテクチャー全体を文書化します。これには以下の事柄が含まれます。
  • 必要なオーサリング環境、配信環境、および UAT 環境
  • 各環境で必要な WebSphere Portal サーバーまたはクラスター
  • WebSphere Portal サーバーまたはクラスターで使用するデータ・リポジトリーを保管するために必要なデータベース・サーバー
  • 各環境間に必要なシンジケーション関係
  • LDAP などの、必要なユーザー・リポジトリー

サーバー・アーキテクチャー

技術面の企画チームは、環境アーキテクチャーに記述される各サーバーのサーバー・アーキテクチャーの文書化も行います。サーバー・アーキテクチャーには各サーバーの詳細なセットアップが記述され、以下の情報が含められます。
  • 各サーバーで必要なハードウェア
  • 各サーバーで必要なオペレーティング・システム
  • 必要なソフトウェア
  • すべてのハードウェア、ソフトウェア、およびオペレーティング・システムの構成設定
  • リモート・データ・リポジトリー、ユーザー・リポジトリーなど、他の関連事項

セキュリティー・アーキテクチャー

セキュリティー・アーキテクチャーは、サイトで必要なグループと、ポートレットのオーサリングと Web サイトのレンダリングにおいて各グループが必要とするアクセス権限を記述します。

この例では、項目タイプ役割が次のグループに適用されます。
表 1. グループ
グループ 詳細
WCMAdmins このグループのメンバーは、オーサリング・ポートレット内のすべての機能に対するアクセス権を必要とします。
SiteAdmins このグループのメンバーは、オーサリング・ポートレット内のワークフローを除くすべての機能に対するアクセス権を必要とします。
SiteDesigners このグループのメンバーは、コンテンツ項目、プレゼンテーション・テンプレート、オーサリング・テンプレート、およびコンポーネントに対するアクセス権を必要とします。
ContentAuthors このグループのメンバーは、コンテンツ項目に対する編集アクセス権のみを必要とします。
ContentApprovers このグループのメンバーは、コンテンツ項目に対するコントリビューター・アクセス権のみを必要とします。

ライブラリー・アクセス

ライブラリー・アクセスを設定するための最も簡単な方法は、すべてのグループにコントリビューター・アクセス権を与えるやり方です。このアクセス権により、すべてのユーザーとグループに、ライブラリーおよびオーサリング・ポートレットに対するコントリビューター・アクセス権が付与されます。 追加のアクセス権は、リソースのアクセス権を使用して各グループに付与されます。 また、匿名ポータル・ユーザー・グループにユーザー・アクセス権を付与して、運営する Web サイトで匿名アクセスが必要な場合には、すべての匿名ユーザーがライブラリーにアクセスできるようにすることが可能です。
表 2. ライブラリー・アクセス
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター  
管理者  
編集者  
ユーザー 不可 匿名ポータル・ユーザー
コントリビューター

WCMAdmins

SiteAdmins

SiteDesigners

ContentAuthors

ContentApprovers

リソースのアクセス権

役割タイプごとに、次のリソースのアクセス権を設定します。
  • WCMAdmins グループには、すべてのリソースに対するアドミニストレーター役割を割り当てます。
  • SiteAdmins グループには、すべてのリソースに対する管理者の役割を割り当てます。ただし、ワークフローとワークフロー・エレメントに対するアクセス権は不要なので、これらのリソースは除きます。
  • 他のグループには、次の指示に従い、リソースごとに役割を割り当てます。
オーサリング・テンプレート

SiteDesigners グループは、新規のオーサリング・テンプレートを作成する必要があるため、オーサリング・テンプレートに対する編集者アクセス権を割り当てます。

表 3. オーサリング・テンプレート
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者 SiteDesigners
ユーザー  
コントリビューター  
コンポーネント

SiteDesigners は、コンポーネントを作成する必要があるため、コンポーネントに対する編集者アクセス権を割り当てます。

表 4. コンポーネント
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者 SiteDesigners
ユーザー  
コントリビューター  
コンテンツ

SiteDesigners と ContentAuthors の両方のグループは、コンテンツ項目を作成する必要があるため、コンテンツに対する編集者アクセス権を割り当てます。

ContentApprovers グループは、新規コンテンツ項目を作成する必要はありませんが、ワークフローの間にコンテンツ項目に対する承認アクセス権が必要になるため、コントリビューターのみを割り当てます。また、ContentApprovers がコンテンツ項目の承認に使用するすべてのワークフロー・ステージのプロパティー・セクションで、ContentApprovers グループに承認アクセス権を割り当てる必要もあります。

表 5. コンテンツ
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者 SiteDesigners

ContentAuthors

ユーザー  
コントリビューター

ContentApprovers

プレゼンテーション・テンプレート

SiteDesigners グループは、新規のプレゼンテーション・テンプレートを作成する必要があるため、プレゼンテーション・テンプレートに対する編集者アクセス権を割り当てます。

表 6. プレゼンテーション・テンプレート
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者 SiteDesigners
ユーザー  
コントリビューター  
サイト・エリア
WCMAdmins グループと SiteAdmins グループは、サイト・フレームワークを作成する唯一のグループなので、これらのグループだけがサイト・エリアへのアクセス権を必要とします。
表 7. サイト・エリア
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者  
ユーザー  
コントリビューター  
分類
WCMAdmins グループと SiteAdmins グループは、分類法を作成する唯一のグループなので、これらのグループだけが分類法へのアクセス権を必要とします。
表 8. 分類
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者 SiteAdmins
編集者  
ユーザー  
コントリビューター  
ワークフローとワークフロー・エレメント
WCMAdmins グループは、ワークフローを作成する唯一のグループなので、このグループのみがワークフローとワークフロー・エレメントへのアクセス権を必要とします。ワークフローを使用するグループは、ワークフローとワークフロー・エレメント・リソースのアクセス権に対するアクセス権は不要です。
表 9. ワークフロー
役割 伝搬を許可 継承を許可 ユーザーまたはグループ
アドミニストレーター WCMAdmins
管理者  
編集者  
ユーザー  
コントリビューター  

項目レベルのセキュリティー継承

デフォルトでは、各役割のアクセス権はライブラリー内の各項目に自動的に継承されていきます。 ユーザーまたはグループが項目に対するアクセス権を自動的に継承しないようにするには、その項目に対する継承をオフにする必要があります。

項目タイプに設定されたアクセス権があっても、個々の項目に対するアクセス権が自動的に与えられるわけではありません。 その段階では、オーサリング・ポートレット内の特定のタスクまたはビューに対するアクセス権が与えられるだけです。

また、項目ごとに、個々のグループまたはユーザーに特定のアクセス権を割り当てることもできます。

情報アーキテクチャー

情報アーキテクチャーは、サイトの情報構造とユーザーがサイトをナビゲートする方法を記述します。

サイト・マップ

情報企画者により設計された Web サイト構造は、サイトに階層構造を与えるためにどのページとサイト・エリアを作成する必要があるかを決定します。 サイト・マップは、サイトの構造を記述し、サイトにどのページとサイト・エリアが必要か決定します。例:
  • ホーム・ページ
    • ニュース・ページ
    • 製品ページ
      • 製品サイト・エリア 1
      • 製品サイト・エリア 2
      • 製品サイト・エリア 3
    • ダウンロード・ページ
    • サポート・ページ

コンテンツ・タイプ

情報企画者により指定されたコンテンツ・タイプは、オーサリング・システムにどのオーサリング・テンプレートが必要か決定します。例えば、サイトに以下のようなコンテンツ・タイプが必要かもしれません。
  • ホーム・ページ・セクション
  • ニュース記事
  • 従業員プロファイル
  • 製品情報
  • 写真ギャラリー
  • 法的特記事項

コンテンツのプロファイルと分類

情報企画者は、ユーザーがコンテンツのプロファイルを作成できるようにするために、どの分類が必要かを決定する責任を負っています。この情報は、メニュー・コンポーネント内にどのコンテンツが表示されるかを決定します。

これは、金融サービス会社の分類の例です。

  • MetaBank 分類:
    • 財務
      • バンキング解決策
      • 利率
        • 個人用
        • ビジネス
        • 企業
    • ニュース

設計アーキテクチャー

設計アーキテクチャーは、Web サイトの外観、およびどのようなコンポーネントがサイトを構築するのに必要か記述します。 プレゼンテーション・テンプレート、コンポーネント、およびテーマを定義する必要があります。

テーマとスタイルシート

設計アーキテクチャーには、テーマ、スタイルシートおよびスタイルをリストします。これらの設計は、プロトタイプ Web サイト用に開発したスタイルに基づくようにすることもできます。

ページ・ワイヤーフレーム

ページ・ワイヤーフレームを使用して、サイトの各ページ・タイプの基本構造や、各ページで使用されるエレメントについて記述します。

プレゼンテーション・テンプレート

設計アーキテクチャーに、Web サイトに必要な各プレゼンテーション・テンプレートとその HTML をリストします。 プロトタイプの Web サイト用に開発した HTML を、設計文書の HTML の基礎として使用できます。プレゼンテーション・テンプレート設計には、以下のものが含まれます。
  • プレゼンテーション・テンプレートの HTML 設計
  • アクセス設定
  • ワークフローが必要かどうか、必要な場合、どれか

コンポーネントおよびエレメント

Web サイトに必要な各コンポーネントとエレメントを設計アーキテクチャーにリストし、以下のような追加情報もリストします。
  • すべての必要なコンポーネント・フィールドの HTML 設計
  • すべてのコンポーネント・パラメーターのパラメーター選択
  • アクセス設定
  • ワークフローが必要かどうか、必要な場合、どれか

パーソナライゼーション戦略

Web サイトの設計者は、どのコンテンツが特定のユーザー用にパーソナライズする必要があるかも決めます。例えば、ユーザー・プロファイルに基づいて、それぞれ個々のユーザーにパーソナライズされたホーム・ページを表示する場合があります。設計アーキテクチャーのパーソナライゼーション戦略文書により、どのルール、コンテンツ・スポット、およびキャンペーンを Personalization アプリケーションを使用する際に作成する必要があるか決めます。

オーサリング・アーキテクチャー

オーサリング・アーキテクチャーでは、サイトにどのようなタイプのコンテンツが必要になるか、コンテンツと設計を更新する際にどのような変更管理戦略を適用するかを記述します。システムにどのようなオーサリング・テンプレートが必要か、変更管理にどのようなワークフローを使用するか、どのようなフォルダーを使用してオーサリング・ポートレットの項目をグループ化するのかを定義する必要があります。

ライブラリー・アーキテクチャー

ライブラリー・アーキテクチャーでは、Web コンテンツ項目をどこに格納するかを記述します。例えば、プレゼンテーション・テンプレートやコンポーネントなどのサイトの外観を制御する項目と、サイトのコンテンツにサイトを分けられます。またライブラリーを、「人事」と「サポート」など、チームごとに異なるライブラリーに分離することもできます。

オーサリング・テンプレート

サイトで使用されるコンテンツ項目のタイプごとに別個のオーサリング・テンプレートが必要になります。 オーサリング・アーキテクチャーで定義されるオーサリング・テンプレートのリストは、プロジェクト計画、分析文書、およびプロトタイプ Web サイト中で指定されている個別のページ・タイプに基づいています。

各オーサリング・テンプレートに指定されている情報には、次のものが含まれます。
  • オーサリング・テンプレートそのものに関して:
    • 名前
    • 表示タイトル
    • 説明
    • テンプレート・タイプ
    • アクセス設定
  • デフォルトのコンテンツ・フォーム設定には、次のものが含まれます。
    • デフォルトのプレゼンテーション・テンプレート (必要な場合)
    • デフォルトのスタイルシート (必要な場合)
    • コンテンツ・フォームのレイアウト
    • エディターがエレメントの管理を行えるかどうか
    • 非表示にするアクション
    • コンテンツの保存場所
    • ヘルプ・テキスト
    • バージョン管理の方針
  • 以下のコンテンツ項目のデフォルトのコンテンツとフィールド:
    • 名前とフィールドの表示オプション
    • 表示タイトルとフィールドの表示オプション
    • 記述とフィールドの表示オプション
    • 必須エレメント
      • 任意のデフォルト要素コンテントの HTML 設計
      • 任意のコンポーネント・パラメーターのデフォルトのパラメーター選択
      • フィールド表示オプション
  • 以下の各コンテンツ項目のデフォルトのコンテンツ・プロパティー:
    • 任意のデフォルト・プロファイルとフィールドの表示オプション
    • 任意のデフォルトのワークフロー・パラメーターとフィールドの表示オプション
    • 任意のデフォルトのアクセス設定とフィールドの表示オプション
    • 履歴セクションのフィールド表示オプション

ワークフロー

ワークフローを使用して、項目へのアクセス、検証、および最終承認を制御します。 項目が公開ステージまでのすべてのステージで承認された場合のみ、ユーザーが Web サイトで表示できます。 ワークフローを使用して以下の事柄を行えます。
  • コンテンツの正確さを検討する
  • 法的な影響があるかどうかについてコンテンツを検討する
  • アクセシビリティーのガイドラインを満たしていることについてコンテンツを検討する
  • クロス・スクリプト攻撃などの悪意のあるコードがコンテンツに追加されていないことを確証する

Web コンテンツ・システムで必要な各ワークフロー、ワークフロー・ステージおよびワークフロー・アクションを、オーサリング・アーキテクチャーにリストします。

フォルダー

フォルダーを使用して、項目タイプのセットを論理グループに分類します。 これは、ライブラリーに数多くの項目があり、各項目タイプ・ビュー内の項目をさまざまなグループに区別したい場合に便利です。Web コンテンツ・システムで必要な各フォルダーを、オーサリング・アーキテクチャーにリストします。

例えば、フォルダーのセットを使用して、イメージ・コンポーネントのさまざまなセットをグループ化できます。
  • ロゴ
  • スタッフの写真
  • 製品の写真

バージョン管理戦略

公開のたびに項目のバージョンを自動的に保存するか、または項目のバージョンを保存する時点をユーザーに選択させるように、システムを構成することができます。 異なる項目タイプのバージョン管理戦略は、オーサリング・アーキテクチャーに文書化します。

コンテンツ入手アーキテクチャー

コンテンツ入手アーキテクチャーを使用して、どの既存コンテンツを Web コンテンツ・システムにインポートするか、そのコンテンツのインポート方法、およびどのコンテンツを作成する必要があるか定義します。

コンテンツ入手アーキテクチャーは、プロジェクトの分析フェーズ中に集められたコンテンツ・インベントリーに基づきます。コンテンツ・インベントリーで指定されているコンテンツの各部分について、以下の情報を定義します。
  • このコンテンツは Web コンテンツ・システムにインポートされるか、新たに作成されるか。
  • コンテンツがインポートされる場合、どのツールを使用するか。例えば、WebDav または Web Content Integrator
さらに、作成される項目のタイプを指定する必要があります。 例:
  • コンテンツの再使用可能な部分は、コンポーネントとして作成されるのに最適なものです
  • Web ページ特定のコンテンツは、コンテンツ項目として作成されるのに最適なものです
  • Web サイトの特定のセクションに特定のコンテンツは、サイト・エリア内に保存されるのに最適なものです

配信アーキテクチャー

技術設計者および情報設計者は、配信する Web サイトにどの配信方式が最も適切であるか定義する必要があります。

配信アーキテクチャーでは、Web コンテンツ・システムにどの配信方式が必要か記述します。

事前レンダリングされた配信

Web サイト全体を HTML に事前レンダリングし、ディスクに保存することができます。 事前レンダリングされたサイトは、その後、表示サイトとして使用でき、Web Content Management または Web サーバーのいずれかを使用してユーザー向けに表示することができます。ポートレットなどの使用している WebSphere Portal の機能が 1 つもなく、コンテンツが静的で、定期的にしか更新されない場合には、事前レンダリングされたサイトをデプロイします。

サーブレット配信

ユーザーは、Web Content Management サーブレットを介して表示されるコンテンツにアクセスできます。 オーサリング・ツールなど、WebSphere Portal ベースの機能を使用する必要がない場合は、サーブレットが配信する Web サイトを使用してください。

ローカル Web コンテンツ・ビューアー配信

Web コンテンツ・ビューアーは、Web コンテンツ・ライブラリーからのコンテンツをポータル・ページの一部として表示するポートレットです。表示が単純な場合は単一の Web コンテンツ・ビューアーで十分である場合もありますが、 複数の Web コンテンツ・ビューアーを使用してさまざまなライブラリーからのコンテンツを集約することにより、 より豊富な情報をユーザーに提供することもできます。 ローカル Web コンテンツ・ビュー・ポートレットを使用して、Web コンテンツ配信環境に含まれるコンテンツを表示します。

リモート Web コンテンツ・ビューアー配信

リモート Web コンテンツ・ビュー・ポートレットを使用して、リモートの WebSphere Portal サーバーまたはクラスター上のコンテンツを表示します。

メンテナンス・アーキテクチャー

Web コンテンツ・システムの正常性と整合性を維持するために計画する必要のある一連のタスクがあります。 技術面の企画者とデータベース企画者は、システムで必要な保守手順と、その実行が必要な時と頻度を定義する必要があります。

バックアップとリストアの戦略

Web コンテンツ・システム内のすべてのソフトウェアとリポジトリーに対するバックアップとリストアの戦略について文書化しておくべきです。このアプローチには、以下のバックアップとリストアの手順の文書化が含まれます。
  • データ・リポジトリー
  • テーマ
  • ポートレット
  • ページ構成
  • 構成設定
  • カスタム・アプリケーション

更新の適用

ソフトウェア更新の処理とタイミングはメンテナンス・アーキテクチャーで定義します。これは、Web Content Management および WebSphere Portal だけではなく、Web コンテンツ・システム内のすべてのソフトウェア製品に適用されます。

例えば、定期的に Web Content Management に対して累積フィックスをインストールする手順を文書化しておくことが考えられます。

メンテナンス・ツールの実行

各メンテナンス・ツール実行の処理とタイミングを文書化します。この文書化は、Web Content Management および WebSphere Portal だけはでなく、Web コンテンツ・システム内のすべてのソフトウェア製品に適用されます。

例えば、メンバー修正タスクなどのメンテナンス・ツールを実行する時と頻度、およびサーバー・パフォーマンスを維持するために項目とバージョンの履歴をクリアする時を文書化しておきます。

Web コンテンツ・システム構築のロードマップ

Web コンテンツ・システムを構築するには、ハードウェアを導入し、サーバーを構成し、オーサリング・システムを設計し、配信環境を構成してシンジケーションを使用可能にする必要があります。Web コンテンツ・システムを構築するのに必要なステップの概要を理解してください。ロードマップをレビューする際に、プロジェクトの計画段階で作成した分析および設計文書のことを心に留めておいてください。

オーサリング環境のデプロイ

最初にデプロイする環境は、オーサリング環境です。 初期段階では、この環境を小さなチームのための開発環境として使用できますが、やがてはすべてのユーザーのためのオーサリング環境として使用できるようになります。オーサリング環境をデプロイするときには、プロジェクト設計文書で定義されている技術アーキテクチャーを基盤にします。

このタスクについて

手順

  1. データベース管理者がプロジェクト設計文書で定義されているデータベース・アーキテクチャーに基づいてオーサリング環境のデータベース・サーバーをデプロイします。
  2. LDAP 管理者がプロジェクト設計文書で定義されているセキュリティー・アーキテクチャーに基づいて以下の作業を行います。
    1. LDAP サーバーがない場合は、新しい LDAP サーバーを作成します。
    2. Web コンテンツ・システムで必要になるすべてのグループとユーザーを作成します。
  3. WebSphere Portal 管理者がプロジェクト設計文書で定義されているサーバー・アーキテクチャーに基づいて以下の作業を行います。
    1. WebSphere Portal のサーバーまたはサーバー・クラスターをインストールします。
    2. WebSphere Portal のサーバーまたはクラスターで、データベース管理者がセットアップするデータベース・サーバーを使用するための構成を行います。
    3. WebSphere Portal で、ユーザー・リポジトリーとして LDAP サーバーを使用するための構成を行います。
    4. WebSphere Application ServerWebSphere PortalWeb Content Management のさまざまな構成プロパティーを構成して、Web コンテンツ・オーサリングのためにシステムを正しくセットアップし、パフォーマンスを最適化するための調整を行います。
  4. WebSphere Portal 管理者がプロジェクト設計文書で定義されている情報アーキテクチャーとセキュリティー・アーキテクチャーに基づいて以下の作業を行います。
    1. Web コンテンツ・システムで必要になるすべてのライブラリーを作成します。
    2. ユーザーとグループに役割とアクセス権を割り当てます。
    3. Web コンテンツ・システムで必要になるすべてのページを作成します。
    4. 該当するページにすべての必要なオーサリング・ポートレットを追加し、それらのオーサリング・ポートレットで、さまざまなチームが Web コンテンツ項目の作成と管理の作業を実行するための構成を行います。
    5. プレビュー・ページとして使用する必要があるページにすべての必要な Web コンテンツ・ビューアー・ポートレットを追加します。
  5. すべての管理者がオーサリング環境の最終的なテストと調整を行います。

タスクの結果

オーサリング環境を使用する準備が整います。

コンテンツ・オーサリング・システムの作成

Web コンテンツ・システムへのコンテンツの追加を始める前に、Web コンテンツを管理し配信するために使用されるすべての項目を作成する必要があります。

手順

  1. Web コンテンツの開発者は、プロジェクト設計文書に定義されている設計アーキテクチャーに基づいて、コンテンツ・オーサリング・システムの作成に備えてプラグインおよび JSP コードを作成します。
  2. Web サイトの作成者は、プロジェクト設計文書に定義されている情報アーキテクチャーに基づいて、以下のことを行います。
    1. サイト・エリアを作成します。
    2. 分類およびカテゴリーを作成します。
  3. Web サイトの作成者は、プロジェクト設計文書に定義されているコンテンツ・オーサリング・アーキテクチャーに基づいて、以下のことを行います。
    1. ワークフロー・アクション、ステージを作成し、ワークフローを定義します。
    2. オーサリング・テンプレートを作成します。
  4. Web サイトの作成者は、プロジェクト設計文書に定義されている設計アーキテクチャーに基づいて、以下のことを行います。
    1. コンポーネントを作成します。
    2. プレゼンテーション・テンプレートを作成します。
  5. Web サイトの作成者は、プロジェクト設計文書に定義されている情報アーキテクチャーに基づいて、サイト・エリアを編集しテンプレート・マップを定義します。
  6. 必要な場合、Web コンテンツの開発者は、プロジェクト設計文書に定義されているコンテンツ・オーサリング・アーキテクチャーに基づいて、カスタム・コンテンツ・オーサリング・インターフェースも作成します。
  7. その後、Web サイトの作成者は、コンテンツ・オーサリング・システムをテストするためのテスト・コンテンツを作成し、テスト・コンテンツをプレビューします。コンテンツ・オーサリング・システムに何らかの問題が見つかった場合はそれが解決され、パフォーマンスと使いやすさを改善するためにさらに変更がなされます。

コンテンツのインポートと作成

オーサリング・システムの準備ができると、その後、ユーザーのシステムのためのデフォルト・コンテンツを作成しインポートします。これはしばしば、Web コンテンツ・オーサリング・システムを作成する個別の異なるチームによって管理されます。

手順

  1. プロジェクトの分析フェーズ中に集められたデータに基づき、コンテンツ入手チームは、Web コンテンツ・オーサリング・システムにインポートするすべての既存のコンテンツを特定し準備します。
  2. それから、Web Content Integrator、WebDav または Web コンテンツ API などのフィーチャーを使用して、コンテンツ入手チームは既存のコンテンツを Web コンテンツ・オーサリング・システムにインポートします。
  3. それから、プロジェクト設計文書に定義されている情報アーキテクチャーに基づき、コンテンツ入手チームは新規コンテンツを作成します。
  4. それから、コンテンツ入手チームはオーサリング・システムをテストし、デフォルト・コンテンツをプレビューします。オーサリング・システムに何らかの欠陥が見つかった場合はそのことが述べられ、パフォーマンスと使いやすさを改善するためにさらに変更がなされます。

配信環境のデプロイ

配信環境は、Web サイト・ビューアーに Web サイトを配信するための環境です。配信環境をデプロイするときには、プロジェクト設計文書で定義されている要件を基盤にします。

手順

  1. データベース管理者がプロジェクト設計文書で定義されているデータベース・アーキテクチャーに基づいて以下の作業を行います。
    1. 配信環境のデータベース・サーバーをデプロイします。
    2. オーサリング・データベースに格納されているデータの複製を配信データベースに配置します。
  2. WebSphere Portal 管理者がプロジェクト設計文書で定義されているサーバー・アーキテクチャーに基づいて以下の作業を行います。
    1. WebSphere Portal のサーバーまたはサーバー・クラスターをインストールします。
    2. WebSphere Portal のサーバーまたはクラスターで、データベース管理者がセットアップするデータベース・サーバーを使用するための構成を行います。
    3. WebSphere Application ServerWebSphere PortalWeb Content Management のさまざまな構成プロパティーを構成して、Web コンテンツ配信のためにシステムを正しくセットアップし、パフォーマンスを最適化するための調整を行います。
  3. WebSphere Portal 管理者がプロジェクト設計文書で定義されている情報アーキテクチャーとセキュリティー・アーキテクチャーに基づいて以下の作業を行います。
    1. Web コンテンツ・システムで必要になるすべてのページを作成します。
    2. 該当するページにすべての必要な Web コンテンツ・ビューアー・ポートレットを追加します。
  4. WebSphere Portal 管理者がシンジケーションを構成して有効にします。
  5. すべての管理者が配信環境の最終的なテストと調整を行います。

タスクの結果

オーサリング環境を使用する準備が整います。

最終ステップ

環境がインストールされ、オーサリング・システムが完了し、デフォルト・コンテンツをサイトに追加し、十分システムをテストしたら、運用の準備ができたことになります。

手順

  1. ステークホルダーが Web サイトとオーサリング・システムを使う準備ができていることを確認してください。
    1. コンテンツ作成者が、新規 Web コンテンツ・オーサリング・システムの使い方のトレーニングを受けていることを確認してください。
    2. すべての既存のオーサリングまたは配信システムが、新規システムにリダイレクトされることを確認してください。
    3. 新規 Web サイトに訪問者を呼び込むマーケティング・キャンペーンを立ち上げてください。
  2. プロジェクト設計文書に定義されている保守アーキテクチャーに基づき、定期的なモニターおよび保守タスクを行ってシステムが正常に稼働し効率的に運用されていることを確認してください。

インストールとマイグレーション

Lotus Web Content Management は、WebSphere Portal インストール・インターフェースを使ってインストールされます。 詳細なインストール手順は、WebSphere Portal 製品資料に含まれています。 WebSphere Portal のインストール手順に従った後、実際の必要に合わせて、この資料の説明に従ってオーサリング環境と配信環境を構成してください。 WebSphere Portal 製品資料にはマイグレーション手順も含まれています。Lotus Web Content Management のマイグレーションは、WebSphere Portal 全体のマイグレーション・プロセスに含まれています。

Web Content Management の構成

コンテンツ・サーバーをセットアップするには、さまざまなデプロイメントに IBM Lotus Web Content Management をインストールし、Web コンテンツの開発と配信のために、堅固で柔軟な環境を用意します。コンテンツ・サーバーをインストールした後、そのサーバーが Web コンテンツ環境で果たす役割に応じて、追加の構成ステップを実行する必要があります。

このタスクについて

Web Content Management の構成は、IBM WebSphere Application Server でリソース環境プロバイダーとして定義されたサービスによって管理されます。WebSphere Application Server 管理コンソールを使用すると、サービスごとに既存のプロパティーの編集、および新規プロパティーの追加ができます。

Web コンテンツ・オーサリング環境の構成

オーサリング環境をセットアップするには、オーサリング・ポートレットをインストールし、オーサリング環境をサポートするために必要なその他の機能を使用可能にします。

オーサリング・ポートレットのインストール

WebSphere Portal を初めてインストールすると、Web Content Management オーサリング・ポートレットおよびローカル・レンダリング・ポートレットが組み込まれているページが作成されます。 オーサリング・ポートレットまたはローカル・レンダリング・ポートレットを以前にアンインストールしている場合は、オーサリング・ポートレットの構成タスクを実行するだけで済みます。オーサリング・ポートレット構成タスクを実行すると、Web Content Management ページが自動的に作成され、オーサリング・ポートレットおよびローカル・レンダリング・ポートレットが自動的にインストールされます。

構成タスクの実行

  1. コマンド・プロンプトを開く。
  2. wp_profile_root/ConfigEngine ディレクトリーから configure-wcm-authoring タスクを実行する。
    Windows
    ConfigEngine.bat configure-wcm-authoring -DPortalAdminPwd=password -DWasUserid=username -DWasPassword=password
    UNIX
    ./ConfigEngine.sh configure-wcm-authoring -DPortalAdminPwd=password -DWasUserid=username -DWasPassword=password
    i
    ConfigEngine.sh configure-wcm-authoring -DPortalAdminPwd=password -DWasUserid=username -DWasPassword=password
  3. ポータルからログアウトしてから、ログインし直す。
  4. 製品のバナーで「Web コンテンツ」を選択し、オーサリング・ポートレットにアクセスする。
クラスターに関する注意事項: クラスターでのインストール後にオーサリング・ポートレットが表示されない場合は、ポートレットのアクティブ化が必要になることがあります。

ロケールの整合性

オーサリング・ポートレットで表示される言語は、ユーザーの地域またはロケールで決まります。ただし、オーサリング・ポートレットのエレメントのなかには、 日付選択フィールドのような、WebSphere Portal 機能を使用するものも一部あります。これらは、WebSphere Portal サーバーの ロケールを使用して表示されます。このため、 作成されるサイト、クライアント、およびサーバーの言語とロケールには、 整合性がなければなりません。

サイトにさまざまな言語のコンテンツが含まれていると、 別のWebSphere Portal サーバーでは、 言語ごとに個別のWeb Content Management オーサリング・アプリケーションをセットアップする必要があります。 次にこれらを、ステージング・サーバーを使用して 1 つのサイトに結合することができます。

注: ユーザーが ロケールを変更すると、その時点で開いていたWeb Content Management ダイアログは 閉じられます。またユーザーは、新規のロケールを使用して表示する前に、新規のセッションを開始しておく必要があります。 ベスト・プラクティスは、Web Content Management を使用する前にクライアントのロケールを正しく設定しておくことです。

追加オーサリング・ポートレット構成オプション

ポートレット管理ビューを使用して、追加オーサリング・ポートレット構成オプションを指定できます。

追加オーサリング・ポートレット構成パラメーターを追加するには、次のようにします。

  • ポータル管理ビューを開く。
  • 「管理」>「ポートレットの管理」>「ポートレット」に移動する。
  • Web コンテンツ・オーサリング・ポートレットを検索する。
  • 構成ビューを開く。
次のオプション構成パラメーターのいずれかを追加できます。
表 10. オーサリング・ポートレットの追加の構成パラメーター
パラメーター 詳細
htmlfield.rows エレメント設計またはプレゼンテーション・テンプレートで使用する HTML フィールドに表示される行数を定義します。指定しないと、デフォルト設定の 15 行が使用されます。
htmlfield.columns エレメント設計またはプレゼンテーション・テンプレートで使用する HTML フィールドの幅を定義します。幅は、行ごとに表示される文字数として定義されます。指定しないと、デフォルト設定の 85 文字が使用されます。
htmlfield.embedded.rows エレメント設計またはプレゼンテーション・テンプレートで使用する HTML フィールドに表示される行数を定義します (HTML コンポーネントには該当しません)。指定しないと、htmlfield.rows を使用して定義した行数が使用されます。
htmlfield.embedded.columns エレメント設計またはプレゼンテーション・テンプレートで使用する HTML フィールドの幅を定義します (HTML コンポーネントには該当しません)。幅は、行ごとに表示される文字数として定義されます。指定しないと、htmlfield.columns を使用して定義した文字数が使用されます。
htmlfield.htmlcomponent.rows HTML コンポーネントで使用する HTML フィールドに表示される行数を定義します。指定しないと、htmlfield.rows を使用して定義した行数が使用されます。
htmlfield.htmlcomponent.columns HTML コンポーネントで使用する HTML フィールドの幅を定義します。幅は、行ごとに表示される文字数として定義されます。指定しないと、htmlfield.columns を使用して定義した文字数が使用されます。
htmlfield.presentation.rows プレゼンテーション・テンプレートで使用する HTML フィールドに表示される行数を定義します。指定しないと、htmlfield.rows を使用して定義した行数が使用されます。
htmlfield.presentation.columns プレゼンテーション・テンプレートで使用する HTML フィールドの幅を定義します。幅は、行ごとに表示される文字数として定義されます。指定しないと、htmlfield.columns を使用して定義した文字数が使用されます。
EDIT_LIVE_CUSTOM_LICENCE これを使用してカスタム・ライセンス・キーを入力し、この形式を使用する Ephox EditLive の OEM ライセンスの代わりに使用します。
Account ID,Domain,Expiration,License Key,Licensee,Product,Release
注: オーサリング・ポートレットに構成変更が表示されるためには、すべてのユーザーがログオフしてからログインする必要があります。

Web コンテンツ・オーサリング・オプション

ワークフロー、プロファイル、およびバージョン管理などの構成設定を変更することによって、Web コンテンツ環境のオーサリングの動作を調整できます。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスでオーサリング・オプションを定義および管理します。

ワークフローの使用可能化

デフォルトでは、IBM Lotus Web Content Management アプリケーションはコンテンツ項目のみをワークフローに 入れます。WCM WCMConfigService サービスを更新すると、さまざまな項目に関するワークフローを使用可能にできます。
ワークフローを使用可能にするには、ワークフローを適用する項目タイプの新規プロパティーを作成し、そのプロパティーの com.aptrix.pluto.workflow.WorkflowControl の値を指定します。 以下の項目タイプのワークフローを使用可能にできます。
  • コンテンツ項目 (control.Content)
  • プレゼンテーション・テンプレート (control.Style)
  • オーサリング・テンプレート (control.Template)
  • 分類項目 (control.Taxonomy)
  • カテゴリー (control.Category)
  • サイト項目 (control.Sites)
  • サイト・エリア項目 (control.SiteArea)
  • ライブラリー・コンポーネント (control.Cmpnt)
例えば、オーサリング・テンプレートのワークフローを使用可能にする場合は、以下のプロパティーを追加します。
  • プロパティー名: control.Template
  • 値: com.aptrix.pluto.workflow.WorkflowControl
項目タイプのワークフローを使用不可にするには、プロパティーを「false」に設定します。例えば、オーサリング・テンプレートのワークフローを使用不可にするには、以下のように設定します。
  • プロパティー名: control.Template
  • 値: false
注: 次の項目に対してワークフローが使用可能になっている場合、項目ビュー・ナビゲーターではワークフロー・ビューが使用可能になりません。
  • サイト・エリア
  • 分類およびカテゴリー
  • ワークフロー、ワークフロー・ステージ、またはワークフロー・アクション

ただし、ワークフロー・ステージでの個々の項目の移動は行うことができます。 移動するには、標準の項目ビューから項目にアクセスして、それらの項目を承認します。

注: Web コンテンツ API を使用してワークフロー内を移動できるのは、コンテンツ項目だけです。他の項目タイプで ワークフローを使用可能にした場合は、API を使用してこれらの項目を承認することも 否認することもできません。

プロファイルの使用可能化

デフォルトでは、Web Content Management アプリケーションはコンテンツ項目のみをプロファイルします。WCM WCMConfigService サービスを更新すると、さまざまな項目に関するプロファイルを使用可能にできます。
プロファイルを使用可能にするには、プロファイルを適用する項目タイプの新規プロパティーを作成し、そのプロパティーの com.aptrix.pluto.taxonomy.ProfileControl の値を指定します。 以下の項目タイプのワークフローを使用可能にすることができます。
  • コンテンツ項目 (control.Content)
  • プレゼンテーション・テンプレート (control.Style)
  • オーサリング・テンプレート (control.Template)
  • 分類項目 (control.Taxonomy)
  • カテゴリー (control.Category)
  • サイト項目 (control.Sites)
  • サイト・エリア項目 (control.SiteArea)
  • ライブラリー・コンポーネント (control.Cmpnt)
例えば、コンポーネントのプロファイルを使用可能にするには、以下のプロパティーを追加します。
  • プロパティー名: control.Cmpnt
  • 値: com.aptrix.pluto.taxonomy.ProfileControl
項目タイプのプロファイルを使用不可にするには、プロパティーを「false」に設定します。例えば、コンポーネントでのプロファイルを使用不可にするには、以下のように設定します。
  • プロパティー名: control.Cmpnt
  • 値: false

バージョン管理オプション

デフォルトで使用可能になっているバージョン管理は以下のプロパティーです。
  • versioningStrategy.AuthoringTemplate
  • versioningStrategy.Component
  • versioningStrategy.Content
  • versioningStrategy.PresentationTemplate
  • versioningStrategy.Site
  • versioningStrategy.Taxonomy
  • versioningStrategy.Workflow
  • versioningStrategy.Default
以下の値を使用して、バージョン管理設定を指定できます。
always
非ワークフロー項目が保管されるたび、またはワークフロー項目が公開されるたびに、バージョンが保管されます。
manual
少なくとも編集者アクセスを持つユーザーが、バージョンを保管することを選択した場合にのみ、バージョンが保管されます。この設定により、インターフェースで以下の変更が生じます。
  • 「バージョンの保存」ボタンが、読み取りモードの非ワークフロー項目と公開状態のワークフロー項目で使用可能になります。
  • 「保存してバージョン作成」ボタンが、編集モードの非ワークフロー項目と公開状態のワークフロー項目で使用可能になります。
never
項目タイプのバージョン管理を使用不可にします。

項目タイプのバージョン管理ストラテジーが定義されていない場合、versioningStrategy.Default プロパティーに定義されているバージョン管理ストラテジーが使用されます。

継承オプション

デフォルトでは、継承は自動的に各項目へ下方向に伝搬されます。以下のプロパティーを指定すると、自動的な継承を使用不可に設定できます。
  • プロパティー名: default.inherit.permissions.enabled
  • 値: false
この設定を指定した場合、設定は新しい項目にのみ適用されます。既存の項目上の継承は、変更されずにそのまま残されます。

階層項目のロック・オプション

コンテンツ項目は、 編集中はロックされます。アンロックされるまで、他のユーザーはそのコンテンツ項目を 編集できません。サイト・エリア、分類およびカテゴリーのロックは構成可能であり、デフォルトでは使用不可です。 階層項目タイプのロックを可能にするには、以下のプロパティーを指定し、以下のパラメーターを 「true」に変更します。
プロパティー名
wcm.authoringui.lock.taxonomies true
wcm.authoringui.lock.categories true
wcm.authoringui.lock.siteareas true

サイト・エリアのロックが有効な場合、ロックされているサイト・エリアの下で子を作成することはできません。例えば、サイト・エリアがロックされている場合、アンロックされるまでは、このサイト・エリアに新規サイト・エリアおよびコンテンツ項目を作成できません。この対象になるのは、ロックされている親の 1 レベル下にある項目に限られます。ロックされている親の子の下にある項目は該当しません。

イメージ・エレメントの有効な MIME タイプの定義

イメージ・エレメントにアップロードできるファイルの MIME タイプを定義するときは、imageresourcecmpnt.allowedmimetypes プロパティーおよびその値の MIME タイプのリストを使用します。 例:
  • プロパティー名: imageresourcecmpnt.allowedmimetypes
  • 値: image/gif,image/jpeg
この場合、ユーザーは非イメージ・ファイルをイメージ・エレメントにアップロードできなくなります。

アクティブ・コンテンツ・フィルター

アクティブ・コンテンツ・フィルターを使用すれば、エレメントに入力されている HTML から指定の HTML フラグメントを除去できます。これにはリッチ・テキスト・エレメントや HTML エレメントが含まれます。アクティブ・コンテンツ・フィルターは、active.content.filtering.enable プロパティーを使用して構成されます。 デフォルトで、アクティブ・コンテンツ・フィルターは有効になっています。有効になっている場合、ユーザーは、クロス・サイト・スクリプトなどの悪意のあるコードを Web サイトに導入できなくなります。

例えば、ユーザーが以下のコードを HTML エレメントに入力したとしましょう。
Welcome
<a href="javascript:window.alert("boo!")">my link</a>
<script language="javascript">window.alert("boo 2!")</script>
Click the link for a surprise.
保管すると、以下のように変更されます。
Welcome
<a href="<"- active content removed -->">my link</a>
<"- active content removed -->
Click the link for a surprise.

大容量のファイルおよび画像のインポート

大容量のファイルを IBM Lotus Web Content Management にインポートするとパフォーマンスが低下する場合があるため、 いくつかの設定を調整して、ファイルのインポート時のパフォーマンスを改善することができます。

始める前に

大きなファイルの処理の設定を更新する前に、以下の考慮事項を検討してください。
UNIX の注記: UNIX オペレーティング・システム上で実行している場合、 作成可能なファイルの最大サイズを、コンテンツ・サーバーにアップロードする必要がある最大のファイル以上のサイズに、ulimit -f コマンドを使用して設定してあることを確認してください。 コマンド ulimit -f unlimited は、ファイル・サイズの制限を除去します。サイズを設定するとき、その設定をサポートするための十分なディスク・スペースがシステムにあることも確認してください。
ディスク・スペースの要件 : ファイルをインポートするとき、アップロード処理中に一時ディレクトリーを使用してファイルが保管されます。 アップロード・ファイルのサイズが一時ディレクトリーの使用可能ディスク・スペースを超えた場合、インポート操作は失敗します。 大きなファイルをアップロードするときは、インポートが可能な十分なディスク・スペースがあることを確認してください。 一時ディレクトリーの場所は、 wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties ファイルの jcr.binaryValueFileDir プロパティーで指定されます。

手順

  1. IBM WebSphere Application Server の「管理コンソール」にログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項: この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. resource.maxUploadSize プロパティーに、インポートを許可するファイルの 最大サイズに対応する値 (MB) を指定する。 例えば、34 MB を超えるファイルのインポートを許可しない場合は、resource.maxUploadSize プロパティーを更新して値を 34 にします。この値は 100 MB を超えないようにすることをお勧めします。
  4. resourceserver.maxCacheObjectSize プロパティーに、300 KB 以下の値を指定する。
  5. transaction.sync.remove プロパティーを追加し、true の値を指定する。
  6. 「サーバー」>「サーバー・タイプ」>「WebSphere WebSphere Application Server」 > portal_server > 「サーバー・インフラストラクチャー」 > 「管理」 > 「カスタム・プロパティー」をクリックする。
  7. protocol_http_large_data_inbound_buffer プロパティーを追加して、その値にファイルの最大サイズをバイト単位で指定する。 この値は、WCM WCMConfigService サービスの resource.maxUploadSize プロパティー用に設定した値と一致する必要があります。

    protocol_http_large_data_inbound_buffer プロパティーではバイトを使用していることに、注意してください。つまり、resource.maxUploadSize プロパティーで値 34 MB を指定した場合は、 protocol_http_large_data_inbound_buffer プロパティーでは値 35651584 バイトを指定します。

  8. 「リソース」 > 「JDBC」 > 「データ・ソース」 > datasource_name > 「カスタム・プロパティー」をクリックする。
  9. fullyMaterializeLobData プロパティーの値に false を指定する。
  10. 「Resource」 > 「JDBC」 > 「データ・ソース」 > datasource_name > 「接続プール・プロパティー」をクリックする。
  11. 「最大接続数」フィールドの値をデフォルトの 50 接続よりも大きい値に増やすことにより、アプリケーション・サーバーで許容されるデータベース接続の最大数を増やします。
  12. 100 MB よりも大きなファイルを処理する場合、Web コンテナーのトランザクション・タイムアウト設定を増やします。
    1. 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」 > portal_server > 「コンテナー・サービス」 > 「トランザクション・サービス」をクリックします。
    2. 「合計トランザクション存続時間タイムアウト」設定の値を、デフォルト設定の 120 秒から増やす。
  13. Web コンテナーによって使用されるスレッド・プールに許可されたスレッドの最大数を増やす。
    1. 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」 > portal_server > 「スレッド・プール」 > 「WebContainer」をクリックします。
    2. 「最大サイズ」フィールドの値を 100 スレッドに設定する。
  14. IBM HTTP Server バージョン 7 を使用している場合、アプリケーションへの接続の接続タイムアウト値を増やす。
    1. 「サーバー」>「サーバー・タイプ」>「Web サーバー」 > web_server > 「プラグイン・プロパティー」 > 「カスタム・プロパティー」 > 「新規作成」をクリックします。
    2. 「名前」フィールドに、ServerIOTimeout と入力する。
    3. 「値」フィールドに、タイムアウト値を秒数で指定する。

      デフォルト値は 60 秒です。 ただし、大きなファイルを処理するときにはこのデフォルト値では通常は不十分で、サーバー・エラー応答が誤って送信され、 ポータルが要求を再送信する結果になることがあります。 失敗した要求で応答を受け取ることが可能となる十分に長いタイムアウト値を指定するか、 または -1 を入力して無制限のタイムアウト値を指定します。

  15. 「保管」をクリックして、構成変更を保管する。
  16. ポータルを再起動して設定を有効にする。

次のタスク

注: ポータルのポリシー・キャッシュ・マネージャーにより、複数の Web コンテナー・スレッドがハングしたことが示された場合は、 WP CacheManagerService サービスの cacheinstance.com.ibm.wps.policy.services.PolicyCacheManager.lifetime プロパティーを -1 の値に設定します。この設定により、データベースの接続数およびロード回数が減り、スレッドのハング防止に役立ちます。

タイムアウトの拡大

ユーザーが項目を保管する際にタイムアウト・エラーが起こる場合は、WebSphere Portal サーバーの「合計トランザクション存続時間タイムアウト」設定を大きくすることができます。

合計トランザクション存続時間タイムアウト」設定は、WebSphere Application Server 管理コンソールから 変更します。

「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」portal_server>「コンテナー・サービス」>「トランザクション・サービス」に移動します。

合計トランザクション存続時間タイムアウト」設定は、 Web コンテンツ・システム内のすべてのサーバーで、同じ値に変更する必要があります。

サーバー・タイムアウト拡大の代替策

合計 トランザクション存続時間タイムアウト」設定の拡大が、 常にサーバーのタイムアウトに対する最善の解決策であるとは限りません。この設定を大きくすると、 パフォーマンスが低下する場合があるためです。項目の保管時に生成されるタイムアウト・エラーが 発生するのは、項目の保管が完了する前に現在のトランザクションが終了してしまう場合です。 保管しようとする項目に大容量のデータが含まれている場合は、「合計トランザクション存続時間タイムアウト」設定を変更するよりも、 項目を再設計する方がよいでしょう。
表 11. サーバー・タイムアウト拡大の代替策
オプション 詳細
オーサリング・テンプレート オーサリング・テンプレートに多数のエレメントが追加されると、 保管中にタイムアウト・エラーが発生することがあります。単一のオーサリング・テンプレートを 使用する代わりに、特定のタスクに必要なエレメントだけを含む複数のオーサリング・テンプレートを 作成してください。
プレゼンテーション・テンプレートとコンポーネント 設計上大量の HTML やリッチ・テキストを含む プレゼンテーション・テンプレートやコンポーネントを保管中に、タイムアウト・エラーになる 場合があります。代替策としては、複数の HTML コンポーネントまたはリッチ・テキスト・コンポーネントを作成してから、 プレゼンテーション・テンプレートまたはコンポーネント設計で、これらのコンポーネントを参照します。
サイト・エリアおよびコンテンツ項目

大量の HTML を使用するエレメントを含むサイト・エリア、およびコンテンツ項目を保管中に、タイムアウト・エラーになる ことがあります。代替策としては、複数の HTML コンポーネントまたはリッチ・テキスト・コンポーネントを作成してから、 エレメント設計で、これらのコンポーネントを参照します。

サイト・エリア、 またはコンテンツ項目に多数のエレメントが追加されると、 保管中にタイムアウト・エラーが発生することもあります。この場合は、サイト・エリア、 またはコンテンツ項目に保管されるエレメントの数を少なくする必要があります。

ダウンロード可能なファイル 大量の HTML またはリッチ・テキストを含む Web コンテンツを 作成するもう 1 つの方法は、Web サイト上にダウンロード可能なファイルの形式で 情報を置くことです。これらは、ファイル・リソース・エレメントとして保管できます。

リモート・サーバー・アクセスをリンク用に構成する

リモート・コンテンツ管理システム内に保管されたファイルおよび文書へのリンクを Web コンテンツ・エレメントに追加する前に、 リモート・システムに関する情報と、そのシステムとの通信の処理に使用される設定を使って、サーバーを構成する必要があります。

始める前に

IBM Content Manager と SSL の使用法 : IBM Content Manager Services for Lotus Quickr は、IBM Content Manager で保管される文書にリンクする機能を提供します。 これらのリンクは、cmpathservice.properties ファイル内の urlBaseService プロパティーの指定どおりに、IBM Content Manager Services for Lotus Quickr 内で構成されている基本サービス URL に従って生成されます。 ポータル用に Secure Sockets Layer (SSL) 暗号化を使用可能にしている場合は、このリンクが確実に正しく生成されるように、基本サービス URL が http プロトコルではなく https プロトコルを反映していることを確認してください。 urlBaseService プロパティーの更新方法について詳しくは、IBM Content Manager Services for Lotus Quickr の資料を参照してください。

このタスクについて

安全ではないサーバーにリンクしないようにするために、ポータルの Ajax プロキシー・コンポーネントを使用してポータルがアクセスできる、許可されたドメインのリストを指定する必要があります。 Ajax プロキシーのグローバル構成を使用して、特定の HTTP タイムアウト値を適用したりアウトバウンド HTTP プロキシー・サーバーを構成したりするなど、発信 HTTP トラフィックをカスタマイズできます。 これを行うには、WP ConfigService 構成サービスを使用して、ECM サーバーの URL パターンを federated_documents_policy 動的ポリシーにマップします。

手順

  1. WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WP ConfigService」をクリックする。
  4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
  5. 「新規」をクリックして、プロパティー名「wp.proxy.config.urlreplacement.federated_documents_policy.suffix」を入力し、 ストリング値を ECM サーバーの URL パターンに設定する。
    例えば、サーバーが HTTP を介してポート 10038 上の ECM サーバー ecm.example.com からの情報にアクセスできるようにするには、以下のプロパティーを追加します。
    wp.proxy.config.urlreplacement.federated_documents_policy.1=http://ecm.example.com:10038/*
    注: プロパティー・キー suffix の値は、 federated_documents_policy にマップするキーのセット内で固有である限り、 任意の値とすることができます。
  6. サーバーを介してアクセスするために必要な他の ECM サーバーのために、必要に応じて追加のプロパティーを作成する。
  7. 変更を保存して、ポータル・サーバーを再起動する。

次のタスク

許可されたドメインのリストに追加されていないサーバー (例えば www.example.com) にユーザーがアクセスしようとすると、次のメッセージが表示されます。
Access to remote server www.example.com has not been granted. Please contact your system administrator.

フェデレーテッド文書のサポートのセットアップ

フェデレーテッド文書からメタデータにアクセスする前に、 フェデレーテッド文書機能を構成する必要があります。 また、フェデレーテッド文書機能と共に使用されるキャッシュ設定を調整することもできます。

始める前に

シングル・サインオンの要件 : フェデレーテッド文書機能を使用する前に、IBM WebSphere Application Server で、 ポータル・サーバーとコンテンツ管理システムとの間のシングル・サインオン (SSO) を使用可能にする必要があります。
重要: シングル・サインオンを IBM Lotus® Quickr とポータル・サーバーとの間に設定する場合、 SSO キーは Lotus Quickr サーバーからエクスポートしてポータル・サーバーにインポートする必要があり、 その逆は行わないでください。

フェデレーテッド文書の構成

リモート・コンテンツ管理システム上の文書のメタデータ情報を取り出すには、 リモート・システムに関する情報およびシステムで通信を処理するために使用される設定値によって、フェデレーテッド文書機能を構成します。

このタスクについて
フェデレーテッド文書機能は Ajax プロキシー・コンポーネントを使用してリモート・コンテンツ管理システムにアクセスするので、 グローバル Ajax プロキシー構成を使用して、特定の HTTP タイムアウト値を適用したりアウトバウンド HTTP プロキシー・サーバーを構成したりするなど、 発信 HTTP トラフィックをカスタマイズできます。 フェデレーテッド文書機能を介してアクセスされる個別のコンテンツ管理サーバーを、許可された要求ターゲットとして Ajax プロキシー構成にリストして、 それらの要求のために LTPA cookie 転送を使用可能にする必要があります。 これを行うには、WP ConfigService 構成サービスを使用して、 コンテンツ管理サーバーの URL パターンを federated_documents_policy 動的ポリシーにマップします。
手順
  1. WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WP ConfigService」をクリックする。
  4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
  5. 「新規」をクリックして、プロパティー名 wp.proxy.config.urlreplacement.federated_documents_policy.suffix を入力し、 ストリング値をコンテンツ管理サーバーの URL パターンに設定する。
    例えば、フェデレーテッド文書機能が HTTP を介してポート 10038 上のコンテンツ管理サーバー ecm.example.com からの情報にアクセスできるようにするには、 以下のプロパティーを追加できます。
    wp.proxy.config.urlreplacement.federated_documents_policy.1=http://ecm.example.com:10038/*
    注: プロパティー・キー suffix の値は、 federated_documents_policy 動的ポリシーにマップするキーのセット内で固有である限り、 任意の値とすることができます。
  6. フェデレーテッド文書機能を介してアクセスするために必要な他のコンテンツ管理サーバーのために、必要に応じて追加のプロパティーを作成する。
  7. オプション: フェデレーテッド文書機能により、任意の ATOM フィードをコンシュームすることもできます。 これを可能にするには、ATOM フィードの URL 接頭部を default_policy 動的ポリシーにマップします。
    1. 「新規作成」をクリックして、プロパティー名 wp.proxy.config.urlreplacement.default_policy.suffix を入力し、ストリング値を、ATOM フィードを提供しているサーバーの URL パターンに設定する。
      例えば、フェデレーテッド文書機能によってサーバー www.example.com からの ATOM フィードにアクセスできるようにするには、以下のプロパティーを追加します。
      wp.proxy.config.urlreplacement.default_policy.1=http://www.example.com/*
      プロパティー・キー suffix の値は、 default_policy 動的ポリシーにマップする一連のキーの中で固有である限り、任意の値にすることができます。
      重要: 非トラステッド・サーバーへのセキュリティー・トークンの転送を防ぐため、federated_documents_policy 動的ポリシーをそれらのサーバーに対して使用しないようにしてください。
    2. フェデレーテッド文書機能を介してアクセスするために必要な他の ATOM フィード・サーバーのために、必要に応じて追加のプロパティーを作成する。
  8. 変更を保存して、ポータル・サーバーを再起動する。

フェデレーテッド文書のキャッシュ・チューニング

フェデレーテッド文書機能は文書リスト・キャッシュおよび文書データ・キャッシュを使用して、 文書のリストおよび文書データに関する情報を管理します。

  • 文書リスト・キャッシュには、特定のユーザーのルール選択結果および特定の選択ルールに含まれる、文書 ID のリストが含まれます。
  • 文書データ・キャッシュには、特定の文書のメタデータが含まれます。
どちらのキャッシュも、キャッシュ・エントリーの存続時間をデフォルトの 10 分間として、デフォルトでアクティブ化されます。

これらのキャッシュを調整するために、キャッシュ・マネージャー・サービス (WP CacheManagerService) を IBM WebSphere Application Server 管理コンソールで構成できます。 文書リスト・キャッシュのプロパティーは cacheinstance.com.ibm.pzn.wcm.ecm.DocumentListCache で示され、 文書データ・キャッシュのプロパティーは cacheinstance.com.ibm.pzn.wcm.ecm.DocumentMetaDataCache で示されます。

リモートのコンテンツ管理システムで生じる更新は、対応する項目がキャッシュ内で見つかった場合には、 ポータル・サイドに即時に反映されないことがあります。 個別のキャッシュの存続時間の値によって、対応する更新の最大の時間遅れが決まります。
注:
  • 新しい文書が表示されるときおよび削除された文書が除去されるときの時間遅れは、 構成された文書リスト・キャッシュの存続時間の値に依存します。
  • 文書について説明するメタデータの更新 (文書のタイトルの変更など) の時間遅れは、 文書リスト・キャッシュの構成された存続時間の値に依存します。

使用可能な文書 ID の最新のリストがログイン時に使用可能になるように、ユーザーに特定の文書リスト・キャッシュはユーザーがログインするたびに明示的に無効にされます。

Web コンテンツのステージング環境の構成

Web コンテンツ配信環境をエミュレートし、デプロイメントの前にテストできるように、ステージング環境を構成します。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスのステージング環境オプションを定義および管理します。

  • 純粋に配信環境へ変更をシンジケートする前にサイトへのその変更を累積して保持するサーバーとしてステージング・サーバーを使用する場合は、ステージング・サーバーのシンジケーション設定をレビューすることのみが必要です。ほとんどの場合、自動シンジケーションは確実に使用不可に設定することになります。
  • 配信環境にシンジケートする前にステージング環境をユーザー受け入れテストで使用する場合は、ステージング・サーバーで構成する他のすべての設定と、配信サーバーで設定する構成とを確実に一致させる必要があります。

Web コンテンツ配信環境の構成

配信環境をセットアップするには、Web コンテンツ・ビューアーをインストールし、その他の必要な機能を使用可能にします。

Web コンテンツ・ビューアーのサイト分析のセットアップ

JSR 286 Web コンテンツ・ビューアーの使用状況データを追跡するために、 ポータルを Web コンテンツ・ビューアーのサイト分析ロギング用に構成できます。

Web コンテンツ・ビューアー・ロガーの使用可能化

JSR 286 Web コンテンツ・ビューアーで使用可能なサイト分析ロギングを利用するには、 WP SiteAnalyzerLogService サービスを構成して SiteAnalyzerJSRPortletLogger サービスをアクティブにする必要があります。

始める前に
SiteAnalyzerJSRPortletLogger ロガーをアクティブにする前に、サーバー・サイドのサイト・データのロギングおよび分析で説明されているように、 サイト分析がポータル全般に対して使用可能になっていることを確認する必要があります。
手順
  1. WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WP SiteAnalyzerLogService」をクリックする。
  4. パラメーター SiteAnalyzerJSRPortletLogger.isLogging を定義してそのパラメーター値を true に設定することにより、 WP SiteAnalyzerLogService を介して SiteAnalyzerJSRPortletLogger ロガーをアクティブにする。
  5. 変更を保存し、ポータルを再起動する。

Web コンテンツ・ビューアーのサイト分析の例

サイト分析ログは、NCSA 結合ログ・フォーマットを使用します。 これは、NCSA 共通ログ・フォーマットと 3 つの追加フィールド (リファラー・フィールド、 ユーザー・エージェント・フィールド、および Cookie フィールド) の組み合わせです。 この例では、JSR 286 Web コンテンツ・ビューアーのための典型的なサイト分析ロギングの情報を説明します。

IBM WebSphere Portal のサイト分析ロギングは、次のとおりです。

wp_profile_root/logs/WebSphere_Portal/sa_date_time.log
ここで、date_time はファイルが作成された日時です。現行 (アクティブ) ログ・ファイルの名前は sa.log です。
注: WP SiteAnalyzerService を構成して、異なるファイル名を使用するようにすることができます。

以下の例は、SiteAnalyzerJSRPortletLogger が使用可能な場合に Web コンテンツ・ビューアーによって記述される、 サイト分析ログのサンプル・エントリーを示しています。

9.37.3.88 - jdoe [22/Nov/2008:22:11:27 +0100] "GET /Portlet/5_8000CB1A00U6B02NVSPH1G20G1/Web_Content_Viewer_(JSR_286)/Web%20Content%2fTestSite01%2fTestSiteArea01%2fTestContent01?PortletPID=5_8000CB1A00U6B02NVSPH1G20G1&PortletMode=view&PortletState=normal&RequestType=render&PUBLIC_CONTEXT=%2fWeb%20Content%2fTestSite01 %2fTestSiteArea01%2fTestContent01 HTTP/1.1" 200 -1 "http://myserver.company.com/Page/ 6_8000CB1A00UR402F0JC25U1O25/MyPage" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18" "JSESSIONID=0000JwIm04xm7btVLwzCj9Qo-uj:-1"

この表では、ログ・フォーマットの各フィールドについて説明します。
表 12. ログ・フォーマットの各フィールドの説明
サンプル内のフィールド ログ・フィールド名および説明
9.37.3.88
ホスト
要求を送信した HTTP クライアントの IP アドレス。
重要: クライアントとポータルとの間にリバース・プロキシー・サーバーがある場合、 ログに記録される IP アドレスは、HTTP クライアントではなくリバース・プロキシー・サーバーのアドレスになります。 HTTP クライアントの IP アドレスをログに記録するには、リバース・プロキシー・サーバーを環境から除去する必要があります。
-
rcf931
要求を出すクライアントの識別に使用される ID。 クライアント ID が不明の場合、このフィールドはハイフン文字 (-) に設定されます。
jdoe
username
クライアントのユーザー ID。ユーザー ID が不明の場合、このフィールドはハイフン文字 (-) に設定されます。
[22/Nov/2008:22:11:27 +0100]
date:time timezone
HTTP 要求の日時。
"GET /Portlet/[...] HTTP/1.1" 
request
HTTP メソッド、要求されるリソースの URI およびクライアントが使用する HTTP のバージョン。URI は、以下のエレメントから作成されます。
  • ID の Portlet
  • 要求される Web コンテンツ・ビューアー・インスタンスの ID。
  • Web コンテンツ・ビューアーの管理名 (注: ポートレットが複製されていなければ、この名前は常に同じです)。
  • UTF-8 でエンコードされた、レンダリングされた Web Content Management 項目のコンテキスト・パス。
  • 以下のパラメーターを含む照会ストリング。
    PortletPID
    要求される Web コンテンツ・ビューアー・インスタンスの ID。
    PortletMode
    ポートレットがレンダリングされるモード。 Web コンテンツ・ビューアーはそのビュー・モードでのみログ項目を書き込むことに注意してください。
    PortletState
    ポートレット・ウィンドウの状態。
    RequestType
    要求タイプ (Web コンテンツ・ビューアーはレンダリング要求についてのみログ項目を書き込むことに注意してください)。
    この後に、Web コンテンツ・ビューアー・インスタンスで使用可能なすべての要求パラメーターのリストが、 UTF-8 でエンコードされたキーと値の対として示されます。
200
statuscode
要求の HTTP 状況コード。
-1
bytes
要求の一部として、クライアントから転送されるデータのバイト数。値の -1 は、バイト数が不明であることを示しています。
"http://myserver.company.com/Page/6_8000CB1A00UR402F0JC25U1O25/MyPage"
referrer
ポートレット・サイト分析ログ項目によって Web コンテンツ・ビューアー・インスタンスがレンダリングされたポータル・ページが示された場合のリファラー。
"Mozilla/5.0 [...]"
user_agent
クライアントが使用する Web ブラウザーのタイプ。
"JSESSIONID=0000JwIm04xm7btVLwzCj9Qo-uj:-1"
cookie
要求の一部として、クライアント・ブラウザーに送信された Cookie の名前と値。複数の Cookie が送信された場合は、このリストをセミコロン文字で区切ります。

JSR 286 Web コンテンツ・ビューアーの XML 構成インターフェース・パラメーター

ポータル内の他のポートレットと同様に、 XML 構成インターフェース (xmlaccess コマンド) を使用して、JSR 286 Web コンテンツ・ビューアーをデプロイおよび構成できます。 XML 構成インターフェースによるポートレットの構成を簡単にするために、 指定可能なポートレット・パラメーターは、標準 ID に加えてパス値を受け入れます。

デフォルトでは、JSR 286 Web コンテンツ・ビューアーは固有 ID を使用して構成されます。 これには、項目が名前変更または移動される場合にも構成が破損しないという利点があります。 ただし、XML 構成インターフェースを使用してポートレットを構成するときは、 項目の固有 ID を判別することが困難なことがあります。 JSR 286 Web コンテンツ・ビューアーを構成するとき、以下のパラメーターを使用することにより、 Web コンテンツ項目をそのパスによって参照することもその ID によって参照することもできます。
AUTHORINGTEMPLATE_OVERRIDE
プロファイル・セクションのオーサリング・テンプレートを指定します。このパラメーターには、複数の値をコンマで区切って組み込むこともできます。リストでは、ID とパス値の両方を指定できます。
CATEGORY_OVERRIDE
プロファイル・セクションのカテゴリーを指定します。複数のカテゴリーをリストするには、それらのカテゴリーをコンマで区切ります。 ID 値とパス値を両方使用することができます。
SITEAREA_OVERRIDE
プロファイル・セクションのサイト・エリアを指定します。複数のサイト・エリアをリストするには、それらのサイト・エリアをコンマで区切ります。 ID 値とパス値を両方使用することができます。
WCM_BROADCASTS_TO
Web コンテンツ・ビューアーのリンク・ブロードキャスト設定を指定します。 値には、以下が含まれます。
  • WCM_LINKING_DYNAMIC: Web コンテンツ・ビューアーで表示される Web コンテンツ項目の情報に基づいて、コンテキストのブロードキャスト先のページを動的に決定します。
  • WCM_LINKING_SELF: 現在の Web コンテンツ・ビューアーのコンテキストを同じポータル・ページにある他の Web コンテンツ・ビューアーにブロードキャストします。
  • WCM_LINKING_OTHER: 現在の Web コンテンツ・ビューアーのコンテキストを別のポータル・ページ (WCM_PORTAL_PAGE_ID パラメーターで指定されているページ) にある他の Web コンテンツ・ビューアーにブロードキャストします。
  • WCM_LINKING_NONE: 現在の Web コンテンツ・ビューアーのコンテキストを他の Web コンテンツ・ビューアーにブロードキャストしません。
WCM_COMPONENT_IDR
ライブラリー・コンポーネントを指定し、 コンテンツ・タイプの「コンポーネント」が選択された場合にのみ使用されます。
WCM_CONTENT_COMPONENT
WCM_CONTENT_TYPE パラメーターの値が CONTENT_COMPONENT になっている場合に表示するエレメントの名前を指定します。
WCM_CONTENT_CONTEXT_IDR
コンテンツ・レンダリング・コンテキストを指定します。WCM_CONTENT_CONTEXT_TYPE パラメーターの指定値に応じて、コンテンツ項目またはサイト・エリアを指定できます。
WCM_CONTENT_CONTEXT_TYPE
構成するコンテンツ・コンテキストのタイプを指定します。値には、以下が含まれます。
  • CONTENT: コンテンツ・コンテキストがコンテンツ項目であることを指定します。
  • PARENT: コンテンツ・コンテキストがサイト・エリアであることを指定します。
WCM_CONTENT_TYPE
表示する項目を指定します。値には、以下が含まれます。
  • CONTENT: 表示する項目がコンテンツ項目であることを指定します。
  • COMPONENT: 表示する項目がコンポーネントであることを指定します。
  • CONTENT_COMPONENT: 表示する項目がエレメントであることを指定します。
WCM_DESIGN_IDR
代替プレゼンテーション・テンプレートを指定します。
WCM_LISTENS_TO
Web コンテンツ・ビューアーで他の Web コンテンツ・ビューアーからブロードキャストされるリンクを受け取る方法の構成設定を指定します。値には、以下が含まれます。
  • WCM_LINKING_OTHER: あらゆる Web コンテンツ・ビューアー・ブロードキャスト・リンクから情報を受け取ります。
  • WCM_LINKING_SELF: この Web コンテンツ・ビューアーからの情報だけを受け取ります。
  • WCM_LINKING_NONE: 他の Web コンテンツ・ビューアーから情報を受け取りません。
WCM_PAGE_TITLE
WCM_PAGE_TITLE_TYPE パラメーターと一緒に使用して、Web コンテンツ・ビューアーのページ・タイトルを指定します。 値には、以下が含まれます。
  • WCM_PAGE_TITLE_TYPE パラメーターの値が WCM_PAGE_TITLE_TYPE_GENERAL になっている場合は、ページのユーザー定義タイトル。
  • WCM_PAGE_TITLE_TYPE パラメーターの値が WCM_PAGE_TITLE_TYPE_RESBUN になっている場合は、ページのタイトルが含まれているリソース・バンドルの名前。
WCM_PAGE_TITLE_TYPE
Web コンテンツ・ビューアーのページ・タイトルの表示方法を指定します。値には、以下が含まれます。
  • WCM_PAGE_TITLE_TYPE_DEFAULT: ポータルの管理インターフェースで定義するデフォルトのタイトルを使用します。
  • WCM_PAGE_TITLE_TYPE_GENERAL: WCM_PAGE_TITLE パラメーターで指定するユーザー定義タイトルを使用します。
  • WCM_PAGE_TITLE_TYPE_RESBUN: WCM_PAGE_TITLE パラメーターで指定するリソース・バンドルでタイトルを定義します。
  • WCM_PAGE_TITLE_TYPE_DYN: Web コンテンツ・ビューアーで表示するコンテンツ項目の「表示タイトル」フィールドの値でタイトルを定義します。
WCM_PORTAL_PAGE_ID
WCM_BROADCASTS_TO パラメーターを WCM_LINKING_OTHER に設定する場合に、リンク・ブロードキャストのターゲットになるページの固有の名前またはオブジェクト ID を指定します。
WCM_PORTLET_TITLE
WCM_PORTLET_TITLE_TYPE パラメーターと一緒に使用して、Web コンテンツ・ビューアーのポートレット・タイトルを指定します。 値には、以下が含まれます。
  • WCM_PORTLET_TITLE_TYPE パラメーターの値が WCM_PORTLET_TITLE_TYPE_GENERAL になっている場合は、ポートレットのユーザー定義タイトル。
  • WCM_PORTLET_TITLE_TYPE パラメーターの値が WCM_PORTLET_TITLE_TYPE_RESBUN になっている場合は、ポートレットのタイトルが含まれているリソース・バンドルの名前。
WCM_PORTLET_TITLE_TYPE
Web コンテンツ・ビューアーのポートレット・タイトルの表示方法を指定します。値には、以下が含まれます。
  • WCM_PORTLET_TITLE_TYPE_DEFAULT: ポータルの管理インターフェースで定義するデフォルトのタイトルを使用します。
  • WCM_PORTLET_TITLE_TYPE_GENERAL: WCM_PORTLET_TITLE パラメーターで指定するユーザー定義タイトルを使用します。
  • WCM_PORTLET_TITLE_TYPE_RESBUN: WCM_PORTLET_TITLE パラメーターで指定するリソース・バンドルでタイトルを定義します。
  • WCM_PORTLET_TITLE_TYPE_DYN: Web コンテンツ・ビューアーで表示するコンテンツ項目の「表示タイトル」フィールドの値でタイトルを定義します。
コンテンツ・パスを指定する場合は、先頭のスラッシュ文字 (/) の後にライブラリー名を記述する必要があります。有効なコンテンツ・パスの例を以下に示します。
/mylib/myfolder/mysitearea/mycontent
または
/mylib/mypresentationtemplate
注: 項目を ID ではなくパスで構成した場合、 その項目が名前変更されるかまたは移動されると、ポートレット構成が無効になることがあります。 項目がパスによって構成されている場合、「共用設定の編集」または「構成」モードのときに、 Web コンテンツ・ビューアーは項目の後に小さなパス・アイコンを表示します。
重要: 項目をパスで構成しているときは、 パス内の項目の「表示タイトル」フィールドからパスを作成することはできません。 パスを指定するとき、項目の「名前」フィールドを使用する必要があります。

キャッシング・オプション

IBM Lotus Web Content Management アプリケーションでは、Web Content Management によって生成された Web ページと、外部のデータ・ソースから得られるコンテンツの両方をキャッシュに格納できます。Web Content Management キャッシングを適切に使用すれば、サイトのパフォーマンスを大幅に改善できます。

Web コンテンツ・キャッシュ・タイプ

IBM Lotus Web Content Management によって使用されるキャッシュ・タイプである、基本 Web コンテンツ・キャッシングおよび拡張 Web コンテンツ・キャッシングについて説明します。

基本 Web コンテンツ・キャッシング

これは、最もシンプルなキャッシング・オプションです。 Web ページは、Web Content Management アプリケーションによって初めてレンダリングされたときに、 キャッシュ内に保存されます。その後ユーザーは、 有効期限切れになるまで、キャッシュからこのページにアクセスします。更新された Web ページがレンダリングされるのは、 この有効期限が切れた後です。このシナリオの主な利点は、パフォーマンスが向上することです。基本キャッシングは、「リアルタイム」のアクセスを必要としない静的コンテンツにのみ使用します。

拡張 Web コンテンツ・キャッシング
基本キャッシングと 拡張キャッシングには、大きく分けて 2 つの違いがあります。
  • 拡張キャッシングでは、異なるユーザー・プロファイルに基づいてページをキャッシュできます。
  • Connect タグと URL 要求の中でキャッシュ・パラメーターを使用して サーバーのデフォルトの拡張 Web コンテンツ・キャッシュの設定値を変更することで、 個々の Web ページまたはコンポーネント用にカスタム・キャッシュ設定を設定できます。
表 13. 拡張キャッシングのタイプ
拡張キャッシングのタイプ 詳細
サイト・キャッシング これは、Connect タグと URL 要求の中でキャッシュ・パラメーターを使用して サーバーのデフォルトの拡張 Web コンテンツ・キャッシュの 設定値を変更できることを除いては、基本 Web コンテンツ・キャッシュと同じです。
セッション・キャッシング セッション・キャッシングを有効にすると、ユーザーが利用した各 Web ページのコピーがセッション・キャッシュに保存されます。 ユーザーは、 新しいセッションを開始するか、キャッシュ内の Web ページの有効期限が切れるまで、 キャッシュ内にある Web ページにアクセスします。
ユーザー・キャッシング ユーザー・キャッシングを有効にすると、ユーザーが利用した各 Web ページのコピーがユーザー・キャッシュに保存されます。 ユーザーは、 キャッシュ内の Web ページの有効期限が切れるまで、 キャッシュ内にある Web ページにアクセスします。
保護キャッシング 項目セキュリティー機能が使用されているサイトでは、保護キャッシングを使用して、ユーザーが属するグループに基づき、 異なる Web ページおよびコンポーネントに対する異なるアクセス権をユーザーに付与します。
個別設定キャッシング 個別設定キャッシングを使用して、 同じ「個別設定プロファイル」を持つユーザーの Web ページをキャッシュします。これは、 同じ個別設定カテゴリーとキーワードを選択し、同じグループに属するユーザーにより 1 つの キャッシュが共有されることを意味します。
デフォルトの Web コンテンツ・キャッシングとカスタム・キャッシングの比較

Connect タグと URL 要求の中でキャッシュ・パラメーターを使用して サーバーのデフォルトの拡張 Web コンテンツ・キャッシュの設定値を変更することで、 個々の Web ページまたはコンポーネント用にカスタム・キャッシュ設定を設定できます。

ほとんどの場合、 基本キャッシング、サイト・キャッシング、およびセッション・キャッシングは、 サーバーのデフォルト Web コンテンツ・キャッシュとしてのみ使用されます。 ユーザー・キャッシング、保護キャッシング、および個別設定キャッシングは 多くの場合、Connect タグおよび URL 要求内でカスタム・キャッシングを 使用している場合に使用されます。

注: デフォルトの Web コンテンツ・キャッシュとして基本キャッシングを使用する場合、 カスタム・キャッシングは使用できません。
キャッシュの比較
表 14. 基本キャッシングと拡張キャッシングの比較
機能 基本キャッシング 拡張キャッシング
1 項目あたりのメモリー使用量:
パフォーマンス改善: 非常に高い
カスタム・キャッシングが使用可能: 不可
Connect タグの処理: 不可
Web コンテンツ・ビューアー・ポートレット: 不可
パーソナライゼーション・コンポーネントのキャッシング:

Web コンテンツ・キャッシングは、パーソナライゼーション・コンポーネントと共に使用されることがあるとしても、 パーソナライゼーション・ルールで設定された条件、またはルールの結果の判別に使用されるリソースに依存します。 パーソナライゼーション・コンポーネントによって返されるコンテンツを Web コンテンツ・キャッシングを使用してキャッシングできるかどうかを判別するために、 キャッシュ・テストが必要になります。

キャッシングと事前レンダリングの比較

レンダリング・ポートレット内で IBM Lotus Web Content Management を介して表示されるコンテンツは、 キャッシュすることができます。キャッシングの代わりに、事前レンダリング機能を使用することもできます。 各ストラテジーの違いについて概観します。

事前レンダリングされたサイトは 2 つの方法で表示できます。
Web サーバーの使用
事前レンダリングされたサイトを Web サーバー経由で表示する方法は、 表示されるコンテンツが静的であり、カスタム・キャッシングを使用できないという意味で、 基本キャッシングを使用する方法と似ています。
Web Content Management の使用
事前レンダリングされたサイトを、Web Content Management を介して表示する方法は、動的コンテンツを扱える点、およびカスタム・キャッシングを使用できるという点で、 拡張キャッシングを使用する方法と似ています。
基本キャッシングと、Web サーバーで提供される事前レンダリングされたサイトの比較

一見したところ、事前レンダリング機能と基本キャッシングは同じことを行います。しかしながら、大きな違いがいくつかあり、その違いによって、 どちらの機能がお客様にとって最適であるかが決まります。

これら 2 つの機能の主な違いは、 事前レンダリング機能が、実行されるたびにサイト全体のスナップショットをとるという点です。基本キャッシングではページ単位のキャッシュしか行われません。パフォーマンスが主要な課題である場合には、事前レンダリングが 答になるでしょう。そうでない場合には、基本キャッシングを選ぶ方がよいでしょう。

表 15. 基本キャッシングと、Web サーバーで提供される事前レンダリングされたサイトの比較
機能 基本キャッシング Web サーバーで提供される事前レンダリングされたサイト
パフォーマンス: 非常に高速 きわめて高速
Connect タグの処理: あり なし
カスタム・キャッシング: あり なし
メモリー要件: 低から中 メモリー所要量は使用する Web サーバーによって異なります。
ディスク要件: 低から中 サイト全体をディスクに納められるようにしなければならないため、 非常に多くなる可能性があります。
予期しないリンク切れ: あり

複数のページがさまざまな時刻にキャッシュに入ることがあるため、 キャッシュに入っているページのリンクが現在、必ずしもすべて有効であるとは限らない場合が 起きます。

なし

サイトは単一のバッチで事前レンダリングされるため、サイトで不整合が発生する可能 性は大幅に低くなります。

拡張キャッシングと、Web Content Management を使用して提供される事前レンダリングされたサイトの比較

これらのオプションは非常に似ています。両方のストラテジーをテストして、 サイトに最適のストラテジーを選択する必要があります。

表 16. 拡張キャッシングと、Web Content Management を使用して提供される事前レンダリングされたサイトの比較
機能 拡張キャッシング Web Content Management を介して提供される事前レンダリングされたサイト
パフォーマンス: キャッシュに入っている場合は高速。ただし、要求されたページのキャッシュ期限が切れた場合には低速になります。 (タグの処理にコストがかかるため、ページに含まれる Connect タグの数によって異なります。) 高速。ただし、タグの処理にコストがかかるため、 ページに含まれる Connect タグの数によって異なります。
Connect タグの処理: あり なし
カスタム・キャッシング: あり なし
メモリー要件: 中から高 中から高
ディスク要件: 中から高 中から高
予期しないリンク切れ: あり

複数のページがさまざまな時刻にキャッシュに入ることがあるため、 キャッシュに入っているページのリンクが現在、必ずしもすべて有効であるとは限らない場合が 起きます。

なし

サイトは単一のバッチで事前レンダリングされるため、サイトで不整合が発生する可能 性は大幅に低くなります。

有効期限ストラテジー

キャッシング・ストラテジーと同様に、サーバーのデフォルトの有効期限ストラテジーも、IBM WebSphere Application Server 管理コンソールを使用して WCM WCMConfigService サービスに設定できます。Connect タグおよび URL 要求内で カスタム有効期限パラメーターを設定して、 サーバーのデフォルトの有効期限ストラテジーを変更することもできます。

注: デフォルトの Web コンテンツ・キャッシュとして基本キャッシングを使用する場合は、 カスタム有効期限を使用できません。

ほとんどの場合、有効期限のスケジュールは、ソース・コンテンツが更新される頻度に基づきます。そのため、 ソース・コンテンツが 1 時間ごとに更新される場合は、各キャッシュは 1 時間で有効期限が切れるようにします。ソース・コンテンツが 1 日ごとに更新される場合は、各キャッシュは 1 日で有効期限が切れるようにします。

これらの例とは異なり、別の有効期限のスケジュールを使用することもできます。Web ページが週ごと、または月ごとにのみ更新される場合にも、キャッシュの有効期限を 1 日にスケジュールすることができます。あるいは、ソース・コンテンツが更新された場合に、 それをサイト上に 1 週間まで表示させることもできます。

キャッシングの有効期限とワークフローの有効期限の比較

ワークフローの Expires パラメーターは、IBM Lotus Web Content Management キャッシングの Expires パラメーターとは関係がありません。ワークフローの一部として、真夜中に有効期限終了となるように設定されたページは、そのページがすでにキャッシュに保存されていない場合に限り、設定通りになります。 このページは、ワークフローの Expires 設定値とは無関係に、Web Content Management アプリケーションで有効期限切れになるまで、キャッシュ内に保持されます。

Web コンテンツ・キャッシュの構成

デフォルトのキャッシュ・タイプおよび有効期限の設定などの構成設定を変更することによって、Web コンテンツ環境のキャッシングの動作を調整できます。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスで Web コンテンツ・キャッシュ・オプションを定義および管理します。

デフォルトの Web コンテンツ・キャッシュ・タイプの設定
Web コンテンツ・サーバーの デフォルトの Web コンテンツ・キャッシング環境は、以下のプロパティーによって 指定されます。
  • connect.businesslogic.defaultcache
  • connect.moduleconfig.ajpe.contentcache.defaultcontentcache
表 17. キャッシングのパラメーター
パラメーター defaultcache defaultcontentcache
キャッシュなし: false None
基本キャッシュ: true 指定なし
サイト・キャッシング: false Site
セッション・キャッシング: false Session
ユーザー・キャッシング: false User
保護されたキャッシング: false Secured
個別設定キャッシング: false Personalized
追加のデフォルト Web コンテンツ・キャッシュ・パラメーター

Web コンテンツの キャッシュ構成設定は、WCM WCMConfigService サービスの以下のプロパティーで 指定されます。

表 18. キャッシュ・タイプごとのキャッシュ・プロパティー
キャッシュ・タイプ プロパティー
基本キャッシュ: connect.businesslogic.defaultcacheexpires

connect.businesslogic.defaultcache

拡張キャッシュ: すべて connect.moduleconfig.ajpe.contentcache.defaultcontentcache

connect.moduleconfig.ajpe.contentcache.contentcacheexpires

拡張キャッシュ: セッション・キャッシュのみ connect.sessioncacheconfig.memcachesize
表 19. キャッシュ・プロパティーの詳細
キャッシュ・プロパティー 詳細
contentcacheexpires すべての拡張キャッシュのデフォルトの 有効期限を設定します。相対的な期間または絶対的な日時のいずれかを指定できます。
defaultcache true の場合は、基本キャッシングが 有効になります。false が指定されるか、何も指定されない場合は、拡張キャッシングが有効になります。
defaultcacheexpires 基本キャッシュのデフォルトの 有効期限を設定します。相対的な期間または絶対的な日時のいずれかを指定できます。
defaultcontentcache 拡張キャッシュが有効になっている場合は、 ここでデフォルトの拡張キャッシュを設定します。
resourceserver.browserCacheMaxAge 項目が Web ブラウザー・キャッシュに保管される最大時間を定義します。
resourceserver.maxCacheObjectSize キャッシュできるオブジェクトの最大サイズをキロバイト単位で定義します。デフォルトでは 300 に設定されます。
キャッシュ有効期限の形式
上記のキャッシュ有効期限を設定する場合、相対時間と絶対時間のどちらでも設定できます。
  • REL {整数値}{単位}
  • ABS {日付形式ストリング}
{単位} =
  • 日数の場合は d|D
  • 月数の場合は m|M
  • 秒数の場合は s|S
  • 時間数の場合は h|H
{日付形式ストリング} =
  • Mon, 06 Nov 2000 09:00:00 GMT
  • Monday, 06-Nov-00 09:00:00 GMT
  • Mon Nov 6 09:00:00 2000
  • 6 Nov 2000 9:00 AM
注: 最後の 2 つの書式では GMT が想定されます。
例:
  • contentcacheexpires="REL 300S"
  • contentcacheexpires="ABS Mon, 06 Nov 2000 09:00:00 GMT"

データ・キャッシュの構成

データ・キャッシングは、IBM Lotus Web Content Management アプリケーションが Connect タグを使用して外部ソースから取得したデータ、または URL を介した要求によって取得されたデータのキャッシュに使用されます。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスのデータ・キャッシュ・オプションを定義および管理します。

データ・キャッシュ・オプションに次のプロパティーを指定します。

connect.connector.httpconnector.defaultcache
データ に対する要求でキャッシュが指定されていない場合に使用されます。指定可能な値は、true または false です。 true の場合は、 データがサイト・キャッシュに保存されます。
connect.connector.httpconnector.defaultcacheexpires
要求で 有効期限の日時が指定されていない場合の、キャッシュ (サイトまたはセッション) に 追加された項目の有効期限の日時です。
connect.connector.sqlconnector.defaultcache
デフォルトとしてデータをキャッシュするかどうかを決定します。指定可能な値は、true または false です。

事前レンダリングの構成

事前レンダリングを有効にすると、コンテンツを、IBM Lotus Web Content Management アプリケーションを介して表示することも、 Web サーバー経由でアクセスされる独立型サイトとして表示することもできます。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスで事前レンダリング・オプションを定義および管理します。

Web Content Management を使用して表示されたサイトの事前レンダリングの使用可能化

このオプションはWeb Content Management を介して事前レンダリングされたサイトにアクセスする場合に使用します。 この場合、静的なコンテンツは事前レンダリングされたサイトから アクセスされるため、パフォーマンスが向上します。しかしこの場合も、動的なコンテンツはWeb Content Management を介してレンダリングされます。

Web Content Management アプリケーション経由で事前レンダリングされたサイトへのユーザーからのアクセスを使用可能に設定するため、 IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスの connect.businesslogic.module.default.class プロパティーを指定します。
  • プロパティー名: connect.businesslogic.module.default.class
  • 値: com.aptrix.cacher.CacherModule
注: 事前レンダリングがデフォルト・モジュールとして設定されている場合は、ローカル・レンダリング・ポートレット (Web Content Viewer) を使用することはできません。

独立型サイトに対する事前レンダリングの使用可能化

このオプションは、Web Content Management を使用して事前レンダリングされたサイトを生成するが、この事前レンダリングされたサイトを表示するのにWeb Content Management を使用しない場合に使用します。 この事前レンダリングされたサイトを表示するには Web サーバーを使用する必要があります。

WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスの connect.businesslogic.module.cacher.class プロパティーを指定します。
  • プロパティー名: connect.businesslogic.module.cacher.class
  • 値: com.aptrix.cacher.CacherModule
キャッシュを構成するため、次のプロパティーを指定します。 リストにはデフォルト値を示しますが、これらの値は必要に応じて調整できます。
connect.moduleconfig.cacher.destdir
値: ${USER_INSTALL_ROOT}/ilwwcm/cacher
各サイト・キャッシュが入る基本ディレクトリーが作成されます。 各サイトごとにサブディレクトリーが 1 つ作成されます。
重要: connect.moduleconfig. cacher.overwritecache プロパティーを true に設定して事前レンダラーを実行した場合は、事前レンダラーの前回の実行時に書き込まれたものではない、connect.moduleconfig.cacher.destdir パス内のすべてのファイルが削除されます。 このため、connect.moduleconfig.cacher.destdir パスには、レンダリングされたコンテンツのみを保存し、 再作成できないその他のデータは含めないでください。
connect.moduleconfig.cacher.tempdir
値: ${USER_INSTALL_ROOT}/ilwwcm/cacher/temp

connect.moduleconfig. cacher.destdir プロパティーによって指定される基本ディレクトリーにデータを移動する前に、サイト・キャッシュを作成するために必要な一時ディレクトリー。

connect.moduleconfig.cacher.delay
値: 1

キャッシングの際にページを要求する間隔を 秒単位で設定するために使用されます。

connect.moduleconfig.cacher.busydelay
値: 5

busy delay 設定値を秒単位で設定するために使用されます。busy start から busy end までの間での実行の場合に 使用されます。 それ以外の場合は、delay 設定値が使用されます。

connect.moduleconfig.cacher.busystart/connect.moduleconfig.cacher.busyend
値: 9:00 am/5:00 pm

これらの設定によって、busy delay 設定値が使用される時間間隔が決まります。 表示されたように、絶対日時を入力します。

connect.moduleconfig.cacher.overwritecache
true
事前レンダラーは、destdir キャッシュ・ディレクトリー内のファイルを上書きします (その後、不必要なファイルを削除します)。これで、ユーザーから見ると、サイトのコンテンツが連続して変更されることになります。これはデフォルト値です。
false
初めてサイトが事前レンダリングされるときには、キャッシュされたサイト・ファイルが保存先ディレクトリーに追加されます。このサイトをオーサリング・ポートレットで変更するにつれて、新しいバージョンのサイトが一時ディレクトリーにキャッシュされ、古いサイトは保存先ディレクトリーにそのまま維持されます。 キャッシュ機能がサイトのキャッシュを完了すると、一時ディレクトリーのコンテンツが保存先ディレクトリーに移されるため、このディレクトリーにはキャッシュされたサイトの古いバージョンと新しいバージョンの両方が含まれることになります。
注: Web サーバーの中にはデータ・ディレクトリーをロックしているものもあるため、Web サーバーを使用して事前レンダリングされたデータを表示する場合には false の値を使用しないでください。
connect.moduleconfig.cacher.rendereruser
値: Anonymous

これにより、Web Content Management コンテンツをレ ンダリングするのに使用されるユーザーが決定されます。 Anonymous または Administrator と入力するか、特定のユーザーまたはグループの名前を入力します。

サイトの事前レンダリングは、このユーザーのセキュリティー権限に基づいて行われ ます。ここで指定されたユーザーが特定のコンポーネントに対するアクセス権を 所持していない場合、事前レンダリングは行われません。

connect.moduleconfig.cacher.task.cacherurl
値: http://${WCM_HOST}:${WCM_PORT}/${WCM_CONTEXT_ROOT}/connect/

事前レンダリングされるページで接続サーブレットを置き換えるために使用される完全 URL。空白にしない場合、この URL の末尾は connect.moduleconfig.cacher.task.servletpath プロパティーに指定されたストリングにしてください。cacherurl のコンテンツは、事前レンダリングで URL を生成するときに使用されます。予約済みタスク、または SRV=cacheSite 要求によるサイト・レベルでの事前レンダリングが完了していないサイトにページが属する場合には、このプロパティーは使用されません。

connect.moduleconfig.cacher.task.servletpath
値: /connect

connect.moduleconfig.cacher.task.cacherurl プロパティーに定義された、置換接続サーブレットのパス。 cacherurl コンテキストを変更せずに使用する場合は、このプロパティーを空白のままにします。

connect.moduleconfig.cacher.defaultcontentname
値: index.html

これは、事前レンダリングされたサイトへの アクセス時に使用する、デフォルトまたはホーム・ファイルの名前を設定します。 これは通常、index.html になります。

connect.moduleconfig.cacher.task.siteareas
値: LibraryA/SiteAreaA,LibraryB/SiteAreaB,SiteAreaC

キャッシュに入れるWeb Content Management 環境内のサイト・エリアを、コンマで区切ってここに入力します。このプロパティーでは、 サイト・エリアだけではなくライブラリーまで指定するオプションが提供されています。ライブラリーを指定した場合、 事前レンダラーはそのライブラリー内でサイト・エリアを探します。ライブラリーを指定しない場合は、 defaultLibrary プロパティーで指定されている、デフォルトのライブラリーが使用されます。

connect.moduleconfig.cacher.task.interval.recurrence
connect.moduleconfig.cacher.task.interval.startdelay
CacherModule は、数分後に繰り返し実行するように設定できます。
recurrence:
値: 10

繰り返し実行するタスクの繰り返し間隔 (分単位)。

startdelay:
値: 1

最初の繰り返しタスクを開始するまでの遅延 (分単位)。

connect.moduleconfig.cacher.task.scheduled.times
値: 3:00 am
代わりに、CacherModule をある特定の時間に実行するように設定することもできます。 一連の絶対日時をコンマで区切って入力します。
重要: 時間の値を指定する際には、必ず H:MM am|pm という書式に準拠してください。コロン (:) 文字とスペースも含めてこの書式にします。 値を誤って指定した場合、事前レンダリングが適切に機能しなくなります。

事前レンダリング・リソース

connect.moduleconfig.cacher.useTieredResourceFolders
値: true
画像やファイル・リソースなどのすべてのリソースは、以下のフォルダーに保管されます。
CACHER_DIR¥LIBRARY¥SITEAREA¥resources
デフォルトでは、リソースはそのリソース ID の最初の 2 文字に基づいて、階層化されたサブフォルダーに保管されます。 例えば、ID が「7961d78049717f29bc57fee5670e9d7b」のリソースは、次のフォルダーに保管されます。
CACHER_DIR¥LIBRARY¥SITEAREA¥resources¥7¥9¥
ID が「79」で始まるその他すべてのリソースも、このフォルダーに保管されます。 このような振る舞いの目的は、「resources」フォルダーのサブフォルダーの数を減らすためです。
この振る舞いを変更して、個々のリソースが独自のフォルダーに保管されるようにするには、「connect.moduleconfig.cacher.useTieredResourceFolders」を false に変更します。false に設定すると、ID が「7961d78049717f29bc57fee5670e9d7b」のリソースは、次のフォルダーに保管されます。
CACHER_DIR¥LIBRARY¥SITEAREA¥resources¥7961d78049717f29bc57fee5670e9d7b

予約済みオーサリング・ポートレット

JSR 286 Web コンテンツ・ビューアーまたは Web コンテンツ・ページで作業するとき、 いくつかのシナリオには、オーサリング・ツール・コンポーネントを使用して実行される Web コンテンツ・オーサリング・タスクが含まれます。そのようなオーサリング・タスクは、オーサリング・ポートレットの 1 つの特殊なインスタンスによって実行されます。 それは、これらのタスクのために特に予約されているものであり、通常のユーザーが使用できるページ・ナビゲーションでは表示されないページ上にインストールされています。

以下のタスクでは、予約済みオーサリング・ポートレットを使用します。
  • Web コンテンツ・ページのプロパティーを作成または編集する際に、Web コンテンツ・フォルダーを選択する。
  • JSR 286 Web コンテンツ・ビューアーを構成する (表示するコンテンツ項目の選択など)。
  • JSR 286 Web コンテンツ・ビューアーでレンダリングされたオーサリング・ツール・コンポーネントを使用する、インライン編集の実行。

通常、オーサリング・タスクは現行ページから開かれる別個のウィンドウで実行されますが、 予約済みオーサリング・ポートレットが含まれる非表示ページにユーザーをリダイレクトするように、オーサリング・ツール・コンポーネントの動作を構成できます。

予約済みオーサリング・ポートレットの可用性の確保

オーサリング・ポートレット・インスタンスまたは非表示ポータル・ページのいずれかが使用できないか、 ユーザーにそれらのいずれかのアクセス権がない場合、予約済みオーサリング・ポートレットを必要とするオーサリング・タスクは失敗して、 Web コンテンツ・ページおよび JSR 286 Web コンテンツ・ビューアーが使用できなくなります。このため、予約済みオーサリング・ポートレットおよび非表示ポータル・ページを管理する際には注意が必要です。

以下の条件は、予約済みオーサリング・ポートレットが正常に機能するために重要です。
  • 上記のいずれかのオーサリング・タスクを実行するユーザーは、非表示ポータル・ページに対するユーザー役割を持つ必要があります。
  • 上記いずれかのオーサリング・タスクを実行するユーザーは、予約済みオーサリング・ポートレットに対するユーザー役割を持つ必要があります。
  • 予約済みオーサリング・ポートレットは、非表示ポータル・ページに存在する唯一のポートレットでなければなりません。
  • 非表示ポータル・ページの固有名は、com.ibm.wps.hiddenpage.wcm.Authoring_Portlet にする必要があります。
  • 非表示ポータル・ページ上のオーサリング・ポートレット・インスタンスのポートレット・ウィンドウの固有名は、 com.ibm.wps.hiddenpage.wcm.control.Authoring_Portlet にする必要があります。
予約済みオーサリング・ポートレットまたは非表示ポータル・ページに関連した可用性の問題は、通常は以下の症状によって識別されます。
  • ポータル・サーバーの SystemOut.log ファイルには、オーサリング・ポートレットまたは非表示ページを参照するエラー・メッセージが格納されます。 例:
    • EJPDB0124E: The specified string [com.ibm.wps.hiddenpage.wcm.Authoring_Portlet] can neither be deserialized as an object ID nor resolved as a unique name.
    • EJPDB0124E: The specified string [com.ibm.wps.hiddenpage.wcm.control.Authoring_Portlet] can neither be deserialized as an object ID nor resolved as a unique name.
  • 現行ページからオーサリング・タスクを実行するための別のウィンドウが起動されると、新しいウィンドウには以下のメッセージが表示されます。

    Error 400: EJPPH0006E: The resolution of a URI failed. Refer to the stack trace for more detailed information.

  • 現行ページからオーサリング・タスクを実行するための別のウィンドウが起動されると、新しいウィンドウは空になります。
  • オーサリング・タスクを実行するためにユーザーが別のポータル・ページにリダイレクトされるとき、 ユーザーは予約済みポートレットを含むページではなくデフォルトのポータル・ページにリダイレクトされます。
  • オーサリング・タスクを実行するためにユーザーが別のポータル・ページにリダイレクトされるとき、ユーザーは空のページにリダイレクトされます。

これらのいずれかの問題が発生する場合は、 予約済みオーサリング・ポートレットおよび非表示ポートレット・ページを正常に操作するための条件が完全に実装されていることを検証してください。

注: 予約済みオーサリング・ポートレットまたは非表示ポートレット・ページが誤って除去された場合、 action-install-wcm-hidden-authoring 構成タスクを使用して、それらを再デプロイできます。

予約済みオーサリング・ポートレットの構成

予約済みオーサリング・ポートレットは、Web コンテンツ・ページおよび JSR 286 Web コンテンツ・ビューアーを正常に操作するために重要なので、 予約済みオーサリング・ポートレットの構成が、IBM Lotus Web Content Management オーサリング・ポートレットの他のインスタンスの構成での、 オーサリング・タスクを実行するための類似の設定値を反映するようにすることは大切です。

手順

  1. アドミニストレーターとしてポータルにログインする。
  2. ツールバーの「管理」をクリックする。
  3. ナビゲーション・ツリーの「ポータル・ユーザー・インターフェース」で、「ページの管理」をクリックする。
  4. 固有名 com.ibm.wps.hiddenpage.wcm.Authoring_Portlet のページを検索する。
  5. そのページの「ページ・レイアウトの編集」アイコン (小さな鉛筆) をクリックする。
  6. ポートレット・メニューから「共用設定の編集」を選択して、 予約済みオーサリング・ポートレットのための設定を指定する。 予約済みオーサリング・ポートレットで使用可能な設定およびそれらを更新するプロセスは、 オーサリング・ポートレットの他のすべてのインスタンスの場合と同じです。
    注: 「共用設定の編集」モードでの予約済みオーサリング・ポートレットに対する変更は、 予約済みオーサリング・ポートレットにのみ影響を与え、オーサリング・ポートレットの他のインスタンスには影響を与えません。 一貫性のあるオーサリングが実現するように、他のオーサリング・ポートレットのインスタンスに対しても、 それぞれのインスタンスで「共用設定の編集」モードを使用して同じ変更を行うことができます。 あるいは、単一のインスタンスから「構成」モードを使用して、 オーサリング・ポートレットのすべてのインスタンスに対して同じ変更を行うこともできます。 「構成」モードで行う変更は、 予約済みオーサリング・ポートレットにも影響を与えます。
  7. 変更内容を保管する。

追加の構成オプション

これらの構成オプションを使用して、追加デプロイメントのシナリオについてのインストール要件を指定できます。

URL で指定したホストへのアクセスの制御

デフォルトでは、コンテンツを取り出すために使用する URL に任意のホスト名を指定できます。ただし、WCM WCMConfigService サービスの構成を変更することにより、ホスト名の指定リストへのアクセスを制限することができます。

手順

  1. IBM WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項: この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. 不明なホストからのアクセスをブロックするため、構成を更新する。 次のプロパティーを指定する。
    • プロパティー名: connect.connector.httpconnector.denyunknownhosts
    • 値: true
  4. アクセス権を付与するホスト名ごとに、新規プロパティーを追加する。 新規プロパティーには以下のフォーマットを使用します。
    • プロパティー名: connect.connector.httpconnector.hosts.host_name。ここで、host_name はアクセス権の対象にする完全修飾ホスト名です。例: connect.connector.httpconnector.hosts.www.example.com
    • 値: true または false
  5. オプション: 追加したホスト名に対してデフォルトのキャッシュ有効期限値を指定するため、プロパティーを新規追加する。 新規プロパティーには以下のフォーマットを使用します。
    • プロパティー名: connect.connector.httpconnector.hosts.host_name.defaultcacheexpires。ここで、host_name はアクセス権の対象にする完全修飾ホスト名です。例: connect.connector.httpconnector.hosts.www.example.com.defaultcacheexpires
    • 値: expiration_time。例: REL 9000s
  6. オプション: プロパティーの新規追加によって追加したホスト名のデフォルトのキャッシュ設定を指定する。 新規プロパティーには以下のフォーマットを使用します。
    • プロパティー名: connect.connector.httpconnector.hosts.host_name.defaultcache。ここで、host_name はアクセス権の対象にする完全修飾ホスト名です。例: connect.connector.httpconnector.hosts.www.example.com.defaultcacheexpires
    • 値: true または false

Web コンテンツ置換変数

IBM Lotus Web Content Management は、IBM WebSphere Application Server の構成で定義されるいくつかの置換変数を使用します。

これらの変数を変更する必要がある場合は、アプリケーション・サーバーの管理コンソールを 使用してください。管理対象セルまたはクラスターを処理する場合は、 デプロイメント・マネージャーの管理コンソールを使用して変更を行います。
表 20. Web コンテンツ置換変数
変数 説明
WCM_CONTEXT_ROOT Web Content Management のエンタープライズ・アプリケーションのコンテキスト・ルート。

例: wps/wcm

WCM_HOST ポータルを実行するマシンの完全修飾ホスト名。

例: www.example.com

WCM_ILWWCM_HOME これは、Web Content Management アプリケーションがインストールされているディレクトリーです。

例: PortalServer_root/wcm

WCM_PORT ポータルへのアクセスに使用されるポート番号。

例: 10038

WCM_SCHEMA IBM WebSphere Portal で使用するように構成される JCR ドメインのデータベース・スキーマ名。

例: jcr

WCM_SEARCHSEED_CONTEXT_ROOT 検索シード・ポートレットのコンテキスト・ルート。

例: wps/wcmsearchseed

WCM_WEB_APP_HOME ilwwcm.war ファイルが位置指定されているディレクトリー・パス。

例: was_profile_root/wp_profile/installedApps/node_name/wcm.ear/ilwwcm.war

WCM_WPS_CONTEXT_ROOT ポータル用のコンテキスト・ルートまたは基本 URI。 このパスから始まるすべての URL はポータル用に確保されます。

例: wps

http://hostname.example.com:10038/wps/portal

WCM_WPS_DEFAULT_HOME デフォルトのポータル・ページ。これはログインしていないユーザーのページです。

例: portal

http://hostname.example.com:10038/wps/portal

WCM_WPS_PERSONALIZED_HOME 既にポータルにログインしているユーザーのポータル・ページ。匿名ユーザーはこのページにアクセスできません。

例: myportal

http://hostname.example.com:10038/wps/myportal

Web コンテンツ・イベント・ログのリセット

時々、Web コンテンツ・イベント・ログをリセットすることが必要になります。

始める前に

最初にイベント・ログのリセット・モジュールを使用可能にするために、IBM WebSphere Application Server 管理コンソールを使用して以下のパラメーターを WCM WCMConfigService サービスに追加します。
  • connect.businesslogic.module.reseteventlog.class=com.ibm.workplace.wcm.services.eventlog.ResetEventLogModule
  • connect.businesslogic.module.reseteventlog.remoteaccess=true
  • connect.businesslogic.module.reseteventlog.autoload=false

このタスクについて

以下のような場合は、Web コンテンツ・イベント・ログをリセットしなければなりません。
  • JCR インポートまたは他のカスタム・アプリケーションなどの外部メカニズムでリポジトリーのコンテンツを変更した場合。
  • シンジケーション前のマイグレーション中にマイグレーション後のステップとして。
  • シンジケーターの項目が送信されないなどのシンジケーションの問題のトラブルシューティングを実行する場合。
注:
  • Web コンテンツ・イベント・ログをリセットする前に、wkplc_dbtype.properties ファイルを編集して、DbSafeMode プロパティーが false に設定されていることを確認する必要があります。このファイルは、wp_profile_root/ConfigEngine/properties にあります。
  • クラスター環境では、1 次ノードのイベント・ログのみリセットする必要があります。
  • 最後のシンジケーション以降にシンジケーター上で「パージ」されたオブジェクトはすべて、サブスクライバー上ではパージされません。 イベント・ログは削除されたオブジェクトのレコードを保持しないため、パージされたオブジェクトは失われます。 パージされた項目をサブスクライバー上でクリーンアップするには、サブスクライバーに移動し、それらを手動で削除する必要があります。

手順

  1. コマンド・プロンプトを開く。
  2. wp_profile_root/ConfigEngine ディレクトリーから run-wcm-admin-task-reset-event-log タスクを実行する。
    Windows
    ConfigEngine.bat run-wcm-admin-task-reset-event-log -Dlibrary=library_name -Dfix=true
    UNIX
    ./ConfigEngine.sh run-wcm-admin-task-reset-event-log -Dlibrary=library_name -Dfix=true
    i
    ConfigEngine.sh run-wcm-admin-task-reset-event-log -Dlibrary=library_name -Dfix=true
    注: -Dfix=true が省略されている場合、タスクはレポート・モードでのみ実行されます。

connect タグの使用可能化

Web コンテンツ・コンポーネントを参照し、コンポーネントにカスタマイズ・キャッシュを適用するため、connect タグを使用可能に設定します。

手順

  1. IBM WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項 : この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. connect.businesslogic プロパティーを指定して、任意のホストまたは特定のホストからの connect タグを処理する。
    オプション 説明
    任意のホストからの connect タグの処理 次のプロパティーを追加します。
    • プロパティー名: connect.businesslogic.processunknownhosts
    • 値: true
    特定のホストからの connect タグの処理 次のプロパティーを追加します。
    • プロパティー名: connect.businesslogic.processunknownhosts
    • 値: false
    処理を使用可能に設定するホストごとに、次のプロパティーを新規追加します。
    • プロパティー名: connect.businesslogic.hosts.hostname
    • 値: true
  4. サーバーまたはクラスターを再始動する。

「オーサリング除去」構成タスク

「オーサリング除去」構成タスクを実行すると、オーサリング・ポートレットおよび関連するポータル・ページがアンインストールされます。

構成タスクの実行

オーサリング・ポートレットを除去するには:

  1. サーバーを停止する。
  2. コマンド・プロンプトを開く。
  3. wp_profile_root/ConfigEngine ディレクトリーから remove-wcm-authoring タスクを実行する。
    Windows
    ConfigEngine.bat remove-wcm-authoring -DWasPassword=password
    UNIX
    ./ConfigEngine.sh remove-wcm-authoring -DWasPassword=password
    i
    ConfigEngine.sh remove-wcm-authoring -DWasPassword=password

E メールの使用可能化

E メール・ワークフロー・アクションを使用するには、SMTP サーバーを使用するように Web Content Management を構成する必要があります。

手順

  1. IBM WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項: この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. connect.connector.mailconnect プロパティーを指定して、実際の SMTP サーバーを使用するようにする。 次のプロパティーを追加します。
    デフォルトの SMTP サーバー
    • プロパティー名: connect.connector.mailconnector.defaultsmtpserver
    • 値: mail.yourmailserver.com
    「from」フィールドで使用するデフォルトの E メール・アドレス
    • プロパティー名: connect.connector.mailconnector.defaultfromaddress
    • 値: admin@yourmailserver.com
    「reply-to」フィールドで使用するデフォルトの E メール・アドレス
    • プロパティー名: connect.connector.mailconnector.defaultreplytoaddress
    • 値: admin@yourmailserver.com
  4. セキュア SMTP サーバーを使用する場合は、次のようにして SMTP サーバーにアクセスするためのユーザー名とパスワードも指定する必要があります。 次のプロパティーを追加します。
    デフォルトのユーザー名
    • プロパティー名: connect.connector.mailconnector.defaultusername
    • 値: username
    デフォルトのパスワード
    • プロパティー名: connect.connector.mailconnector.defaultpassword
    • 値: password
  5. 変更内容を保管する。
  6. ポータルを再起動して新しい設定を有効にする。

シンジケートの構成

シンジケーションは、サーバー間で Web コンテンツを同期化するために使用されます。 シンジケーションを実行する時点、および実行する頻度を構成することができます。

シンジケーション・プロパティー

シンジケーション間隔や自動シンジケーションなどの構成設定を変更することにより、Web コンテンツ環境のシンジケーションの動作を調整できます。

IBM WebSphere Application Server 管理コンソールを使用して、WCM WCMConfigService サービスのシンジケーション・オプションを定義および管理します。

シンジケーション間隔の変更

シンジケーションの頻度は、インストール中にデフォルトで設定されますが、 それぞれの環境の要件に合わせて、シンジケーションの間隔を変更できます。

例えば、ユーザーが頻繁にコラボレーションを行い、適宜複製を行う必要があるアクティブなオーサリング環境では、間隔を短くします。 同様に、頻繁に更新されないデータの過度な複製を避けるには、間隔を長くします。
注: シンジケーション間隔は、すべてのシンジケーション処理に適用されます。シンジケーション・サブスクライバーの組み合わせごとに別個に指定することはできません。

シンジケーション間隔を変更するには、deployment.itemChangedTaskDelay プロパティーを変更します。 シンジケーション間隔は、デフォルトで 30 秒に設定されています。 シンジケーション間隔として使用する秒数は、最小で 0 秒、 最大で 65536 秒の間に指定します。 値が 0 である場合、シンジケーションは行われません。 設定した値の示す間隔が短すぎ、その間隔の期限が切れるまでにシンジケーションが完了できない場合には、 前のシンジケーションが完了した時点から再び、シンジケーションが開始されます。

自動シンジケーションの使用不可化

シンジケーションの発生時に完全な制御を行うため、手動シンジケーションのみの使用を選択する場合があります。 これを行うには、自動シンジケーションを使用不可にする必要があります。 自動シンジケーションが使用不可の場合、シンジケーションの間隔設定は無視されます。 このプロパティーは、シンジケーターおよびサブスクライバーの両方で同じ値に設定する必要があります。

自動シンジケーションを使用不可にするには、以下のプロパティーを指定します。
  • プロパティー名: connect.moduleconfig.syndication.inittasks
  • 値: false

サブスクライバーのみのサーバーの構成

シンジケーター・サーバーは、シンジケーションのコンテンツを収集し、キューに入れるためにいくつかのプロセスを使用します。 これらのプロセスは、実行時に、サーバーのパフォーマンスに影響を与える場合があります。 ただし、サブスクライバーのみのサーバーはこれらのプロセスを必要としないため、プロセスの使用不可化によってサブスクライバーのみのサーバーで、パフォーマンスを向上させることができます。

これを行うには、deployment.subscriberOnly プロパティーが true に設定されていることを確認してください。

SSL を使用したセキュア・シンジケーションの使用可能化

シンジケーションで SSL を有効にして使用するには、WCM WCMConfigService の以下のプロパティーを変更して、「HTTPS」プロトコルと適切なポートを使用するようにする必要があります。
  • deployment.itemDispatcherUrl
  • deployment.syndicatorUrl
  • deployment.subscriberUrl

自動シンジケーションの使用不可化

シンジケーションの発生時に完全な制御を行うため、手動シンジケーションのみの使用を選択する場合があります。 これを行うには、自動シンジケーションを使用不可にする必要があります。

このタスクについて

自動シンジケーションが使用不可の場合、シンジケーションの間隔設定は無視されます。 この設定は、シンジケーター・サーバー上でのみ変更します。

手順

  1. 自動シンジケーションを使用不可にするには、IBM WebSphere Application Server 管理コンソールにログインします。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項: この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. connect.moduleconfig.syndication.inittasks プロパティーを指定する。
    • プロパティー名: connect.moduleconfig.syndication.inittasks
    • 値: false
  4. 変更を保管する。

シンジケーション間隔の変更

シンジケーションの頻度は、インストール中にデフォルトで設定されますが、 それぞれの環境の要件に合わせて、シンジケーションの間隔を変更できます。

このタスクについて

例えば、ユーザーが頻繁にコラボレーションを行い、適宜複製を行う必要があるアクティブなオーサリング環境では、間隔を短くします。 同様に、頻繁に更新されないデータの過度な複製を避けるには、間隔を長くします。
注: シンジケーション間隔は、すべてのシンジケーション処理に適用されます。シンジケーション・サブスクライバーの組み合わせごとに別個に指定することはできません。

手順

  1. IBM WebSphere Application Server 管理コンソールにログインする。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」 > 「WCM WCMConfigService」 > 「カスタム・プロパティー」をクリックする。
    クラスターに関する注意事項: この Web コンテンツ・サーバーがクラスターの一部として使用される場合は、構成プロパティーを操作するときに、デプロイメント・マネージャーの管理コンソールを必ず使用してください。
  3. deployment.itemChangedTaskDelay プロパティーの値を変更する。 シンジケーション間隔は、デフォルトで 30 秒に設定されています。

    シンジケーション間隔として使用する秒数は、最小で 0 秒、 最大で 65536 秒の間に指定します。 値が 0 である場合、シンジケーションは行われません。 設定した値の示す間隔が短すぎ、その間隔の期限が切れるまでにシンジケーションが完了できない場合には、 前のシンジケーションが完了した時点から再び、シンジケーションが開始されます。

  4. 変更を保管する。

Web コンテンツのタグ付けおよびレーティングの管理

Web コンテンツでタグ付けおよびレーティングを使用する場合、タグ付けとレーティングの結果をフィルター処理するための追加的なスコープ・オプションを JSR 286 Web コンテンツ・ビューアーで使用できます。 Web コンテンツ・システム内の変更により、ポータルで使われるタグ付けとレーティングの情報の正確さが影響を受ける可能性があるため、スコープを定期的に同期化して、スコープ情報を最新に保つことが重要です。

Web コンテンツでのタグ付けおよびレーティングのスコープの使用

スコープ (有効範囲) は、通常、タグ付け対象のリソースに付加される階層メタデータに従ってタグ・クラウドやレーティング概要をフィルター処理するために使われます。 Web コンテンツにタグ付けとレーティングを適用するとき、オーサリング・テンプレート、カテゴリー、またはコンテンツ項目の親に基づいてこれらの表示コンポーネントのスコープを設定できます。

このタスクについて

以下の 1 つまたは複数のスコープに関連付けられたタグやレーティングだけを限定的に結果で表示するよう、JSR 286 Web コンテンツ・ビューアーの拡張設定を構成することができます。
  • (例えばサイト・エリアなど) 表示されるコンテンツ項目の親。
  • 表示されるコンテンツ項目の生成に使われるオーサリング・テンプレート。
  • 表示されるコンテンツ項目のプロファイル作成に使われるカテゴリー。 こうして、コンテンツ項目の分類を定義するだけで、Web コンテンツ・システム内部からスコープを管理できます。

Web コンテンツのスコープの同期化

ユーザーが Web コンテンツのタグ付けまたはレーティングを行うとき、JSR 286 Web コンテンツ・ビューアーはタグ付けやレーティングの情報を保管場所のポータルに提示します。 これにより、Web コンテンツ・システム内の情報が変更された場合、ポータルに保管されるタグ付けとレーティングの情報の同期が失われる可能性があります。 例えばコンテンツ項目が移動されたり、カテゴリー情報が変更されたりした場合にこれが発生する可能性があります。 タグ付けとレーティングの情報を最新に保つには、Web コンテンツに使用されるスコープを同期化してください。

このタスクについて

スコープの同期を使用可能にするには、Web Content Management 構成サービスの中で tagging.syndication.enableTagSynchronization プロパティーを指定します。

手順

  1. WebSphere Application Server 管理コンソールにログインする (http://hostname.example.com:10027/ibm/console)。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WCM WCMConfigService」をクリックする。
  4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
  5. tagging.syndication.enableTagSynchronization プロパティーを追加する。
    1. 「新規」をクリックして、プロパティー名 tagging.syndication.enableTagSynchronization を入力する。
    2. ストリング値を true に設定する。
  6. 「OK」をクリックして、マスター構成に変更内容を保存する。
  7. ポータルを再起動する。

タスクの結果

スコープの同期を使用可能にした後、さまざまな条件に従って自動同期をセットアップできます。または、必要に応じて手動で同期を実行することもできます。

項目が変更されたときスコープの同期化

Web コンテンツ・システムで項目が変更されるたびにスコープの同期を自動的に実行するには、Web Content Management 構成サービス内で tagging.syndication.enableItemModificationSynchronization プロパティーを指定します。

このタスクについて
注: この種類の同期は、個々の項目が変更された場合にのみ機能します。 例えばサイト・エリア全体またはフォルダーが移動された場合には、この種類の同期は自動的に実行されません。 そのような変更が発生した後でスコープを同期化するには、手動で同期を実行できます。
手順
  1. WebSphere Application Server 管理コンソールにログインする (http://hostname.example.com:10027/ibm/console)。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WCM WCMConfigService」をクリックする。
  4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
  5. tagging.syndication.enableItemModificationSynchronization プロパティーを追加する。
    1. 「新規」をクリックして、プロパティー名 tagging.syndication.enableItemModificationSynchronization を入力する。
    2. ストリング値を true に設定する。
  6. 「OK」をクリックして、マスター構成に変更内容を保存する。
  7. ポータルを再起動する。

シンジケーション後のスコープの同期化

シンジケーションが発生するたびにスコープ同期を自動的に実行するには、Web Content Management 構成サービスの中で tagging.syndication.enableTagSynchronization プロパティーを指定します。

手順
  1. WebSphere Application Server 管理コンソールにログインする (http://hostname.example.com:10027/ibm/console)。
  2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
  3. 「WCM WCMConfigService」をクリックする。
  4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
  5. tagging.syndication.enableTagSynchronization プロパティーを追加する。
    1. 「新規」をクリックして、プロパティー名 tagging.syndication.enableTagSynchronization を入力する。
    2. ストリング値を true に設定する。
  6. 「OK」をクリックして、マスター構成に変更内容を保存する。
  7. ポータルを再起動する。

スコープ同期のスケジューリング

XML 構成インターフェースを使ってスケジュールを定義することにより、特定の時間にスコープの同期を実行するようスケジュールできます。

手順
  1. ポータルに対して同期のスケジュールが既に定義されているかどうかを確認する。
    1. xmlaccess コマンドで使用することのできるエクスポート・ファイルを作成する。 現在の構成を照会するために使用できる要求は、例えば次のとおりです。
      <?xml version="1.0" encoding="UTF-8"?> 
      <request type="export" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd" > 
        <portal action="locate"> 
          <task action="export" name="com.ibm.portal.cp.SynchronizationTask"/> 
        </portal> 
      </request>
    2. エクスポート・ファイルを指定して xmlaccess コマンドを実行する。 結果として生成される出力ファイルには、ポータルで定義されている同期時間のスケジュールがすべて含まれます。
  2. 同期のスケジュールを設定する。
    1. 同期スケジュールの時間を設定するために、XML 要求文書を作成する。 例えば、毎日 15 時 36 分に同期を実行するようスケジュールするには、以下のような要求を使用できます。
      <?xml version="1.0" encoding="UTF-8"?> 
      <request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> 
        <portal action="locate"> 
          <task action="create" name="com.ibm.portal.cp.SynchronizationTask"> 
            <startTime>15:36</startTime> 
          </task> 
        </portal> 
      </request>

      それぞれの同期スケジュールに対して別個の task エレメントを作成し、startTime エレメントを使って時間を指定します。

    2. スケジュール要求が入っているファイルを指定して xmlaccess コマンドを実行する。 定義されたスケジュールに従って、Web コンテンツ・システムのスコープ情報が自動的に同期されるようになります。
  3. オプション: 後続の同期が実行されるまでの最小時間を設定するには、Web Content Management 構成サービスの中で tagging.syndication.minimumTagSynchronizationTimeInterval プロパティーを指定する。
    1. WebSphere Application Server 管理コンソールにログインする (http://hostname.example.com:10027/ibm/console)。
    2. 「リソース」 > 「リソース環境」 > 「リソース環境プロバイダー」をクリックする。
    3. 「WP ConfigService」をクリックする。
    4. 「追加プロパティー」で、「カスタム・プロパティー」をクリックする。
    5. 「新規」をクリックして、プロパティー名 tagging.syndication.minimumTagSynchronizationTimeInterval を入力する。
    6. ストリング値を、同期の間隔を示す秒数に設定する。
    7. 「OK」をクリックして、マスター構成に変更内容を保存する。
    8. ポータルを再起動する。

手動によるスコープの同期化

Web コンテンツ用に使われるスコープの自動同期をまだ使用可能にしていない場合、またはスケジュールされた同期期間外で同期を実行したい場合には、手動で同期化処理を開始できます。

手順
手動で同期を実行するには、cp-sync 構成タスクを実行するか、XML 構成インターフェースを使って XML 要求をポータルに送信します。
  • 構成タスクを使って同期を実行するには、wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行します。
    • Windows: ConfigEngine.bat cp-sync -DWasPassword=password -DPortalAdminPwd=password
    • UNIX: ./ConfigEngine.sh cp-sync -DWasPassword=password -DPortalAdminPwd=password
    • i: ConfigEngine.sh cp-sync -DWasPassword=password -DPortalAdminPwd=password
  • XML 要求ファイルを作成し、xmlaccess コマンドを使ってそれを実行依頼します。 同期を開始するために使用できる要求は、例えば次のとおりです。
    <?xml version="1.0" encoding="UTF-8"?> 
    <request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> 
      <portal action="locate"> 
        <task action="create" name="com.ibm.portal.cp.SynchronizationTask"/> 
      </portal> 
    </request>

ポータル・サイトのセットアップ

ポータル・サイトのセットアップには、 ポータルのルック・アンド・フィールのカスタマイズ、ページの作成、検索のセットアップ、 およびコンテンツのサイトへの追加が含まれます。ポータルのルック・アンド・フィールを カスタマイズするために、テーマが使用されます。出来合いのテンプレートおよび サイト・ウィザードは、ポータル・サイトのセットアップ時間を短縮するのに役立ちます。サイトに Wiki およびブログを追加したり、ユーザーがサイト上でコンテンツのタグ付けや評価を 実行できるようにしたりすることができます。

サイト・ウィザード、サンプル・サイト、およびテンプレート

WebSphere Portal には、サイトの作成を高速かつ容易にするために、 サイト・ウィザード、サンプル・サイト、テンプレートなどが含まれています。サイトの作成を 開始する前に、出来合いのサンプルを理解して、サイト・ウィザードについて詳しく 学習してください。

サンプル・サイトおよび新規サイト・ウィザード

IBM® WebSphere® Portal はサンプル・インターネットおよびイントラネット Web サイトを含み、独自のポータル・サイトの開発を合理化するためのテンプレートとして使用できます。新規サイト・ウィザードを使用すれば、ポータル開発のスキルについて学習しなくても、独自のポータル・サイトを生成できます。

サンプル・サイト

サンプルのイントラネットおよびインターネット・サイトは、WebSphere Portal のインストール時に自動的にインストールされるわけではありませんが、インストールが完了した後、ポータル・データベース、ユーザー・レジストリー、コンテキスト・ルート、またはセキュリティーのいずれかを構成する前に configure-express タスクを実行することにより、それらのサンプル・サイトを追加できます。 詳しくは、ご使用の特定のプラットフォーム上でのスタンドアロン・サーバーまたはクラスター・サーバーのセットアップに関する説明を参照してください。

サンプルのイントラネットおよびインターネット・サイトにアクセスするには、メイン・ポータル・バナーの「詳細表示」メニューを使用するか、ブラウザーで該当する URL を開きます。
  • イントラネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/intranet
  • インターネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/internet

独自の従業員サイトを作成する開始点として、イントラネット・サイト・テンプレートを使用します。「ホーム」、「作業 (Work)」、および「リソース (Resources)」ページは、現状のまま使用したりカスタマイズしたりできるプレースホルダー・コンテンツでシードされます。 使いやすいリスト・ポートレットにより、アナウンス、ニュース、イベント、FAQ、およびリンクを編成して管理できます。

イントラネット・サイト・グラフィックの説明が、このトピックで提供されます。

インターネット・サイト・テンプレートを使用して、カスタマーが製品のオファリング、マーケティング・プロモーション、および会社ニュースについて学習できる Web サイトの構築を迅速に開始できます。

インターネット・サイト・グラフィックの説明が、このトピックで提供されます。

さらにその他のコンテンツ・サンプルが IBM WebSphere Portal Business Solutions Catalog で入手できます。

ポータル・サイトのオンデマンド作成

「新規サイト・ウィザード」を使用して、独自のサイトを生成します。ポータル開発のスキルや管理者からの支援は必要ありません。使用可能なサンプルからサイト・テンプレートを選択し、ご希望の外観を選択してから、残りの作業をウィザードに行わせるだけです。

このウィザードは、新しいサイトを仮想ポータルとして自動的に作成します。しかし、管理者および開発者は、このウィザードを拡張して不特定型のポータル・サイトを作成できます。ポータル開発者は、カスタム・サイト・テンプレートを作成してからウィザードに追加することにより、「新規サイト・ウィザード」を拡張することもできます。

「新規サイト・ウィザード」は、IBM WebSphere Portal Business Solutions Catalog からダウンロードします。パッケージのコンテンツにはポートレット .war (Web Application Archive) ファイル、サポート・ファイルとディレクトリー、および .pdf ファイル形式の詳細な指示が含まれています。ウィザードのデプロイ後に、ユーザーがアクセスできるページにポートレットを追加する必要があります。詳しくは、ウィザードに付属の .pdf ファイルを参照してください。

「新規サイト・ウィザード」画面。この図について詳しくは、このトピックのテキストを参照してください。

サンプル・サイト・テンプレートの探索

独自の取り組みを開始する前に、製品に付属しているデフォルトのインターネット・サイトおよびイントラネット・サイトのテンプレートについて、時間をかけて試験的に運用し、検討してください。

ワークフローの基本概念を理解することは、イントラネット・サイトおよびインターネット・サイトのテンプレートを使用して作業する上で重要です。 アナウンス、イベント、会社ニュース、FAQ などのさまざまなオーサリング・テンプレートは、コンテンツの作成プロセスを簡素化するのに役立ちます。 ただし、作成したコンテンツをサイト上に表示するには、そのコンテンツが一連のステージ (ワークフロー) を経て「公開」ステージに到達している必要があります。 イントラネット・サイトおよびインターネット・サイトのテンプレート内にあるオーサリング・テンプレートでは、標準ワークフローと QuickFlow の 2 つの事前定義ワークフローが使用されます。

標準ワークフローには、「ドラフト」、「確認」、「公開」、および「期限切れ」の 4 つのステージがあります。標準ワークフローを使用するオーサリング・テンプレートを使用して作業すると、保存したコンテンツは「ドラフト」ステージに移行します。 ドラフト・コンテンツをその他の利用可能なコンテンツと共に表示するには、その前にアドミニストレーターがドラフト・コンテンツを確認して公開する必要があります。 あるいは、コンテンツを「確認」ステージに移すために、「保管して承認」を選択することもできます。 そこから「次のステージ」をクリックして、コンテンツを公開します。 標準ワークフローを使用するオーサリング・テンプレートには、「最新のニュース (Latest News)」(イントラネット・サイト・テンプレート内)、および「製品と会社のニュース (Products and Company News)」(インターネット・サイト・テンプレート内) があります。

QuickFlow には、「公開」と「期限切れ」の 2 つのステージしかありません。QuickFlow を使用するオーサリング・テンプレートで作業する場合、「保管」をクリックすると、コンテンツは即座に公開されます。QuickFlow を使用するオーサリング・テンプレートには、「アナウンス」および「イベント」(イントラネット・サイト・テンプレート内) および「新着情報」、「プロモーション」、および「FAQ」(インターネット・サイト・テンプレート内) があります。

デフォルトでは、全認証ポータル・ユーザー・グループに属するユーザーは、イントラネットおよびインターネット・サイト・テンプレートへの特権ユーザー・アクセス権を持ちます。このため、すべての認証済みポータル・ユーザーは、これらのページをカスタマイズすることができます。このグループを表示アクセスのみに制限するには、グループをイントラネットおよびインターネット・サイト・テンプレートの特権ユーザー役割から除去し、「ユーザー」役割に追加します。

contentAuthors グループのユーザーは、特権ユーザー・アクセス権だけでなく、Web Content Management で作成および保守されるインターネットおよびイントラネット・サイト・テンプレート・コンテンツに対する編集者アクセス権も持ちます。コンテンツ作成者は、すぐに使用可能な状態で配信されるコンテンツを編集できるほか、インターネットおよびイントラネット・サイト・テンプレートの新規コンテンツの作成、編集、および削除も行うことができます。

IBM WebSphere Portal バージョン 7.0 のサンプル・イントラネットおよびインターネット・サイトにアクセスするには、メイン・ポータル・バナーの「詳細表示」メニューを使用するか、ブラウザーで以下の Web ページのいずれかを開きます。
  • イントラネット・サイト・テンプレート (Business to Employee): http://hostname.example.com:port/wps/portal/intranet
  • イントラネット・サイト・テンプレート (Business to Customer): http://hostname.example.com:port/wps/portal/internet

ポータル・ページ構造

ポータル・サイトをカスタマイズする前に、ポータルの基本構造を理解してください。

ポータル・ページは、通常、ポータルの Web 設計者が作成する画面テーマ、およびスキン用の JSP と、静的に組み込まれた JSP フラグメント (JSPF) から構成されています。 これらの JSP は、以下のディレクトリーの下にある、それぞれに対応した /screens/themes/skins の各ディレクトリーにあります。

この場所では、ポータル集約をサポートするために、マークアップ、ロケール、およびクライアント・タイプのサブディレクトリーが使用されています。

テーマ
ポートレットのコンテンツ領域 (「ホーム」画面) 外の、ポータルのナビゲーション、表示、およびレイアウト (カラー、フォント、イメージなど) を提供します。
画面
通常、ポートレット (「ホーム」画面) を表示するポータルの領域。 しかし、エラー・メッセージなどの、他のコンテンツを表示することもできます。 画面は、テーマ内のナビゲーション・アイコンから選択します。
スキン
行コンテナー、列コンテナー、ポートレットなどのようなコンポーネントの周辺にレンダリングされる枠を表します。 スキンはテーマとは無関係でインストールされます。 ただし、アドミニストレーターはテーマにデフォルトのスキンを設定できます。

ポータル・ページの作成は、/themes ディレクトリーの Default.jsp から開始します。 画面とスキンは、ポータル・コア・タグ・ライブラリーの対応するタグによって呼び出されます。画面は <portal-core:screenRender/> タグによって呼び出され、スキンは <portal-core:pageRender/> タグによって呼び出されます。

以下の図は、テーマ、画面、およびスキンがポータルで使用される様子を示しています。
ポータル・ページを構成するタグ。テーマ、スクリーン、およびスキンについて詳しくは、
このトピックのテキストを参照してください。

テーマ

新規テーマを作成し、Default.jsp および組み込まれている JSP 内のレイアウトを変更することにより、独自に作成したエレメントを HTML ポータル・ページに追加してレイアウトを再配置できます。 インストール後に提供される JSP を使用してポータル・ページ・テーマを作成する際の順序とレイアウトについて説明します。この情報を使用して、独自のテーマを作成する際にこれらのコンポーネントをインクルードする方法について学んでください。

注: このセクションの情報は、ポータル・テーマおよびポータル Web 2 テーマのみに適用されます。ページ・ビルダーとデフォルトのページ・ビルダーテーマに関する詳しい説明は、ページ・ビルダーでの作業のトピックを参照してください。

ほぼすべての要求では、ポータル・ページは /themes ディレクトリーの Default.jsp からレンダリングされます。 唯一の例外として、要求が newWindow="true" パラメーターによって変更された場合があります。 この場合、ページは Plain.jsp を使用してレンダリングされます。Plain.jsp は通常、 ポートレット・ヘルプのレンダリングや、フレーム・スキンを使用するポートレットのレンダリングに使用されます。

テーマ・ポリシーは、テーマをページ上にレンダリングする方法を制御するために使用します。 ポリシーは、XML 構成インターフェースを使用して作成および保管されます。 いったん保管されると、XML 構成インターフェースでページ・メタデータ属性 com.ibm.portal.ThemePolicy を使用して、またはプロパティー・ポートレットを使用してページに適用できます。 テーマ・ポリシーは継承されるため、親と異なるポリシーを必要とするページ上で設定するだけで済みます。

ヘッダー

Head.jspf は、ポータル・ページを正しく表示するために必要なヘッダー情報を提供します。 このファイルは、スタイルシートおよびクライアント・サイド・スクリプトをリンクすると同時に、ページの表題とテキストの方向を設定するために使用されます。

バナー

Banner.jspf には、ページの上部にわたるユーザー・インターフェース・エレメントを含んでいます。 これには、以下が含まれています。
  • 最上位リンク - リンク数が一定の値を超える場合に「詳細表示...」メニューを表示する「コンテンツ・ルート」のすぐ下に表示される、最上位ノードのリスト。
  • パンくずリスト (banner_crumbtrail.jspf) - 現在のページへの現在のページ選択パス。
  • 検索コントロール (banner_searchControl.jspf) - さまざまな検索スコープへの検索書式。
  • ツールバー・アクション (banner_toolbar.jspf) - さまざまなフライアウト・パネルおよびアクションにアクセスするためのボタンのセット。

トップ・ナビゲーション

topNav.jspf は、1 行以上のナビゲーション・タブを作成します。 テーマ・ポリシーの値は、トップ・ナビゲーションがレンダリングされるかどうか、およびレンダリングする行数を制御します。

サイド・ナビゲーション

sideNav.jspf は、ナビゲーション・ノードの拡張可能ツリーを作成します。 サイド・ナビゲーションは、トップ・ナビゲーションによってレンダリングされていないナビゲーション・レベルをレンダリングします。

フッター

footer.jspf は、ポータル・ページの下部にわたるセクションをレンダリングします。 デフォルトで、これはポータルの共通アクセス・エリアへのクイック・リンクを含んでいます。 レンダリングされたリンクは、固有名 ibm.portal.Quick Links を持つポータル・ページの子である内部 URL です。

パレット

Flyout.jspf には、必要に応じて動的に表示および非表示にされるコンテンツを表示するために、バナーのツールバーのアクションによって使用される非表示の文書部 (<div/>) が含まれます。

コンテキスト・メニュー

ポータル・テーマと IBM スキン (デフォルト) のコンテキスト・メニューは、非同期でロードされます。 メニューのコンテンツは、/themes/html/Portal ディレクトリーにある JSP により制御されます。 以下の情報は、特定のメニューを制御するために使用される JSP について説明します。
表 21. コンテキスト・メニューおよび制御 JSP
メニュー 制御 JSP
詳細表示メニュー moreMenu.jsp
ページ・メニュー (選択されたページ) pageContextMenu.jsp
ポートレット・メニュー portletContextMenu.jsp
注: ページおよびポートレットのコンテキスト・メニュー・アイコンは、ポートレットおよびページ・タイトルの右上隅の上に移動したときだけ表示されます。
これらの JSP への URL は、<portal-navigation:url themeTemplate="mainMenu"/> を使用して作成されます。ここで、themeTemplate 属性は、ロードする JSP の名前です (ファイル拡張子なし)。 その結果、urlGeneration タグで themeTemplate 属性を使用するか、または使用可能な public API を使用することにより、これらの制御 JSP のいずれかで作成される URL で、テーマ・テンプレートをリセットする必要があることに注意するのは重要です。
注: コンテキスト・メニューは、ページが完全にロードされるまで使用できません。 詳しく説明すると、ページ上のコンテキスト・メニュー (例えば、メインメニュー、ページ・メニュー、およびデフォルトのポータル・テーマの任意のポートレット・メニュー) は最初は使用不可になっており、onload ハンドラーで再度使用可能になります。 このイベントが発生するのは、ページが完全にロードされる前 (つまり、ポートレット JSP がコンパイル中) にコンテキスト・メニューをクリックすると、エラーが発生してメニューがロードされないためです。

ドラッグ・アンド・ドロップ機能

ドラッグ・アンド・ドロップ機能を使用すると、スキンを使用する個々のポートレットの配置を簡単に変更することができます。 ドラッグ・アンド・ドロップ機能によって、ページ上の現在の位置から別の位置にカスタム・ポートレットを移動することができるようになります。 これによって、ページ上のカスタム・ポートレットの配置を簡単に変更できます。

テーマ・ポリシー

テーマ・ポリシーは、テーマが特定のページについてレンダリングされる方法を制御します。 現在のページに割り当てられるテーマ・ポリシーの属性は、レンダリング対象およびレンダリング方法を制御するために、テーマ JSP によって利用されます。

画面

選択状態の画面は <portal:screenRender/> タグによってレンダリングされます。

デフォルト・テーマ

HTML 用として、WebSphere Portal では次のテーマを提供しています。
  • ページ・ビルダーテーマ - これは、WebSphere Portal のデフォルト・テーマです。詳しくは、ページ・ビルダーでの作業のトピックを参照してください。
  • ポータル・テーマ - これは、旧リリースの WebSphere Portal のデフォルト・テーマで、使用可能なすべてのテーマ機能を説明するフル機能のテーマです。
  • 最小テーマ - このテーマは、ルート themes/html ディレクトリーにあり、機能ポータルをレンダリングするのに必要な最小値のみを含む、最小の「セーフ」フォールバックです。 これには、WebSphere Portal で使用可能な機能 (ドラッグ・アンド・ドロップ・メニューやコンテキスト・メニューなど) がすべて含まれているわけではありません。 このテーマは通常の使用を意図しておらず、テーマとして名前で明示的に定義されているわけではありません。 それよりも、メイン・ポータル・テーマに問題がある場合に、フォールバックとしてのみ存在します。 また、最小テーマの例としても存在します。
  • ポータル Web 2 テーマ - このテーマでは、WebSphere Portal の Web 2.0 機能を活用しています。 このテーマでは、ページの部分更新やポートレットのインライン編集が可能なクライアントによって、AJAX および JavaScript の利点を活用したリッチなユーザー・エクスペリエンスが提供されます。
注: ポータル・テーマ・ディレクトリーが削除または名前変更されている場合、 ポータル・リソース・ローダーは themes/html/Default.jsp を使用します。 この場合は、フォールバック・スキンを使うことも必要です。 これを行うには、skins ディレクトリーを名前変更します。 例えば、skins¥html¥IBM ディレクトリーは、skins¥html¥IBM1 に名前変更する必要があります。 テーマが破損している場合は、問題の原因となっているそのテーマとスキンのディレクトリーを名前変更して、 機能する最小限のテーマにすることができます。

<portal-theme:cacheProxyUrl/> JSP タグ

スタイルシート用の JSP を使用するように切り替えることは、スタイルシートの更新時に保守または生成しなければならないファイルの数を減らすのに大きく役立ちます。 しかし、コンパイル済み JSP を要求ごとに生成しなくても済むように、それらの出力をキャッシュする必要があるというパフォーマンス上の懸念が発生します。 WebSphere Portal には、この問題を解決する <portal-theme:cacheProxyUrl/> JSP タグが用意されています。

<portal-theme:cacheProxyUrl/> タグは、Caching Proxy サーブレットに対する URL を作成します。 作成された URL は完全にキャッシュ可能であり、要求元のクライアントに関する情報が含まれています。 CC/PP クライアント・プロファイルは、URL のクライアントに関する情報を収集するために使用します。 このタグの目的は、.CSS ファイルを JSP にリンクすることです。
注: セキュリティー上の理由から、 キャッシュ・プロキシー・サーブレットは、テーマ、スキン、 および画面のディレクトリー内にあるリソースを指す URL のみを提供します。 これにより、これらのディレクトリーの下にあるすべてのリソースが公開されます。 また、「..」文字を含む URL は提供されません。

テーマ・ポリシー

テーマ・ポリシー、テーマ・ポリシーの属性、および WebSphere Portal と併用できるテーマ・ポリシーについて説明します。XML 構成インターフェースを使用したページ上のテーマ・ポリシーの設定、JSP でのテーマ・ポリシーの使用、独自のテーマ・ポリシーの作成、およびテーマ・ポリシーの更新、エクスポート、削除について説明します。

テーマ・ポリシーは、テーマをページ上にレンダリングする方法を制御するために使用します。 ポリシーは、XML 構成インターフェースを使用して作成および保管されます。 いったん保管されると、XML 構成インターフェースでページ・メタデータ属性 com.ibm.portal.ThemePolicy を使用して、またはプロパティー・ポートレットを使用してページに適用できます。 テーマ・ポリシーは継承されるため、親と異なるポリシーを必要とするページ上で設定するだけで済みます。

注: ページ・ビルダーとページ・ビルダーテーマはテーマ・ポリシーをサポートしないので、以下のセクションの情報はページ・ビルダーとページ・ビルダーテーマには適用されません。
このトピックには、テーマ・ポリシーに関する以下の情報を記載しています。

テーマ・ポリシーの属性

テーマ・ポリシーは、複数の属性で構成されています。 各属性は、テーマの 1 つの性質を制御します。 例えば、ブール renderBreadCrumb 属性はパンくずが表示されるかどうかを制御し、breadCrumbMaxLevels 属性はパンくずが表示された場合に、それにリストされるステップの数を制御します。

以下の表では、使用可能なすべてのテーマ・ポリシー属性のタイプおよび機能に関する情報を示します。 完全なリストを参照するには、テーマ・ポリシーをエクスポートすることをお勧めします。 詳しくは、このトピックの『テーマ・ポリシーのエクスポート』のセクションを参照してください。
表 22. テーマ・ポリシーの属性
属性 タイプ 機能
renderMainMenu ブール値 true の場合は、メインメニューがレンダリングされます。
renderTopNavigation ブール値 true の場合は、トップ・ナビゲーションがレンダリングされます。
renderMainMenuActions ブール値 true の場合は、メインメニュー・アクションがレンダリングされます。
renderSelfCare ブール値 true の場合は、セルフケアがレンダリングされます。
renderBreadCrumbTrail ブール値 true の場合は、パンくずリストがレンダリングされます。
renderSearch ブール値 true の場合は、検索がレンダリングされます。
renderToolBar ブール値 true の場合は、ツールバーがレンダリングされます。
renderContentPalette ブール値 true の場合は、ポートレット・パレットがレンダリングされます。
renderPeoplePalette ブール値 true の場合は、ユーザー・パレットがレンダリングされます。
renderContextMenus ブール値 true の場合は、コンテキスト・メニューがレンダリングされます。
renderSideNavigation ブール値 true の場合は、サイド・ナビゲーションがレンダリングされます。
renderTaskBar ブール値 true の場合は、タスクバーがレンダリングされます。
renderFavorites ブール値 true の場合は、お気に入りがレンダリングされます。
renderExtensions ブール値 true の場合は、拡張がレンダリングされます。
renderBannerTitleGraphic ブール値 true の場合、バナー・タイトル・グラフィックがレンダリングされます (ある場合)。
renderPortletFragmentIDAnchor ブール値 ユーザーがパレット・ページ上にいるかどうかを判別するのに使用されます。
renderBannerTitle ブール値 true の場合、バナー・タイトルがレンダリングされます (ある場合)。
breadCrumbMaxLevels 整数 パンくずリストにリストされるステップの数を示します。
breadCrumbStartLevel 整数 パンくずリストを開始するレベルを示します。
rootNavigationStartLevel 整数 ルート・ナビゲーションの開始レベルを示します。
rootNavigationStopLevel 整数 ルート・ナビゲーションの停止レベルを示します。
topNavigationNumRows 整数 トップ・ナビゲーションでレンダリングする行数を示します。
topNavigationStartLevel 整数 トップ・ナビゲーションの開始レベルを示します。
topNavigationStopLevel 整数 トップ・ナビゲーションの停止レベルを示します。
sideNavigationStartLevel 整数 サイド・ナビゲーションの開始レベルを示します。
isCustomizable ブール値 true の場合は、テーマ・カスタマイザー・ポートレットでポリシーを編集できます。
isDeletable ブール値 true の場合は、テーマ・カスタマイザー・ポートレットでポリシーを削除できます。
注: xmlaccess はこの属性を無視します。
colorPalette ストリング

指定すると、この属性の値はカラー・パレットの名前になります。

ページで使用されるカラー・パレットの名前の検索順序は次のとおりです。
  1. colorPalette ページ・メタデータ属性の値
  2. 現在のページに割り当てられたポリシーの colorPalette 属性の値
  3. ストリング「default」

カラー・パレットの名前は、テーマで提供されるプロパティー・ファイルの名前から .properties 拡張子を除いた名前にする必要があります。

colorPaletteProperties ストリング カラー・パレット情報。これは、テーマ・カスタマイザー・ポートレットによって作成される、保管された java.util.Properties オブジェクトです。このテーマは、まずページのカラー・パレットをロードし、次にそれらの値をこの属性で指定されている値で上書きします。
graphicFilesMimeData ストリング 指定されている場合は、テーマ・カスタマイザー・ポートレットによってアップロードされたグラフィック・ファイル。この属性は、Base64 エンコードによってエンコードされた添付を含む標準マルチパート/混合 MIME テキスト・ストリームです。
styleVersion 整数 ポリシーのバージョン番号。この値は、テーマ・カスタマイザー・ポートレットがポリシーを保存するたびに増分されるため、ポリシーに対する更新はブラウザー・キャッシュをクリアせずにロードできます。
bannerTitleText ストリング

バナーおよびブラウザーのタイトル・バーにタイトルとして表示されるテキストを示します。

この値を空にすると、bannerTitleTextResourceBundle 属性と bannerTitleTextResourceKey 属性を使用してタイトル・テキストが決定されます。

bannerTitleTextResourceBundle ストリング タイトル・テキストが含まれているリソース・バンドルを示します。
bannerTitleTextResourceKey ストリング タイトルの場所を指定するために使用されるリソース・バンドル・キーを示します。
bannerTitleGraphic ストリング

バナーに表示されるタイトル画像の URI を示します。この値は、portal-resolver:url タグの uri 属性に渡されます。

テーマ・カスタマイザー・ポートレットによって作成される値の形式は、「themeGraphic:policy:filePath:xxx」です (ここで、xxx は graphicFilesMimeData 属性に保管される添付の名前です)。

renderBannerQuickLinks ブール値 true の場合は、バナー・クイック・リンクがレンダリングされます。
renderHelpLink ブール値 true の場合は、ヘルプ・リンクがレンダリングされます。
renderQuickLinksShelf ブール値 true の場合は、クイック・リンク・シェルフがレンダリングされます。
quickLinksShelfStyle 整数

クイック・リンク・シェルフのスタイル属性。これは、ビット・マスク・フィールドです。ビット 1 をオンにすると、クイック・リンク・シェルフのデフォルト状態が拡張されます。ビット 2 をオンにすると、展開/縮小リンクが非表示になります。

このようにして、以下の値がサポートされています。
  • 0 = デフォルト・シェルフ状態が縮小され、展開/縮小リンクが表示される
  • 1 = デフォルト・シェルフ状態が展開され、展開/縮小リンクが表示される
  • 2 = デフォルト・シェルフ状態が縮小され、展開/縮小リンクが非表示になる
  • 3 = デフォルト・シェルフ状態が展開され、展開/縮小リンクが非表示になる
0、1、2、または 3 以外の数字は、将来のために予約されています。
renderApplicationName ブール値 true の場合は、アプリケーション名がレンダリングされます。
renderCustomizeThemeLink ブール値 true の場合は、テーマ・カスタマイザー・リンクがレンダリングされます。

用意されているテーマ・ポリシー

WebSphere Portal には、変更しなくても使用できる 10 個のポリシーが用意されています。 以下の情報は、各ポリシーと対応する属性、値、およびタイプのリストを示したものです。

注: Federation、SingleTopNavLevel2、および Palette の各テーマ・ポリシーは変更しないでください。
デフォルト
  • renderMainMenu=TRUE
  • renderTopNavigation=TRUE
  • renderMainMenuActions=TRUE
  • renderSelfCare=TRUE
  • renderBreadCrumbTrail=FALSE
  • renderSearch=TRUE
  • renderToolBar=TRUE
  • renderContentPalette=TRUE
  • renderPeoplePalette=TRUE
  • renderContextMenus=TRUE
  • renderSideNavigation=TRUE
  • renderTaskBar=TRUE
  • renderFavorites=TRUE
  • renderExtensions=TRUE
  • renderBannerTitleGraphic=TRUE
  • renderBannerTitle=TRUE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels=5
  • breadCrumbStartLevel=1
  • rootNavigationStartLevel=1
  • rootNavigationStopLevel=1
  • topNavigationNumRows=1
  • topNavigationStartLevel=2
  • topNavigationStopLevel=2
  • sideNavigationStartLevel=3
  • isCustomizable=FALSE
  • isDeletable=TRUE
  • colorPalette=""
  • colorPaletteProperties=""
  • graphicFilesMimeData=""
  • styleVersion=1
  • bannerTitleText=""
  • bannerTitleTextResourceBundle=""
  • bannerTitleTextResourceKey=""
  • bannerTitleTextResourceKey=""
  • bannerTitleGraphic=""
  • renderBannerQuickLinks=TRUE
  • renderHelpLink=TRUE
  • renderQuickLinksShelf =FALSE
  • quickLinksShelfStyle=1
  • renderApplicationName=TRUE
  • renderCustomizeThemeLink=FALSE
SingleTopNav
  • renderMainMenu = TRUE
  • renderTopNavigation = TRUE
  • renderMainMenuActions= TRUE
  • renderSelfCare = TRUE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = TRUE
  • renderSideNavigation = TRUE
  • renderTaskBar = TRUE
  • renderFavorites = TRUE
  • renderExtensions = TRUE
  • renderBannerTitleGraphic = TRUE
  • renderBannerTitle=TRUE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 1
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 1
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 2
  • sideNavigationStartLevel = 3
SingleTopNavMinimal
  • renderMainMenu = TRUE
  • renderTopNavigation = TRUE
  • renderMainMenuActions = FALSE
  • renderSelfCare = FALSE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = FALSE
  • renderToolBar = FALSE
  • renderContentPalette = FALSE
  • renderPeoplePalette = FALSE
  • renderContextMenus = FALSE
  • renderSideNavigation = TRUE
  • renderTaskBar = FALSE
  • renderFavorites = FALSE
  • renderExtensions = FALSE
  • renderBannerTitleGraphic = FALSE
  • renderBannerTitle = FALSE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 0
  • breadCrumbStartLevel = 0
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 1
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 2
  • sideNavigationStartLevel = 3
DoubleTopNav
  • renderMainMenu = TRUE
  • renderTopNavigation = TRUE
  • renderMainMenuActions = TRUE
  • renderSelfCare = TRUE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = TRUE
  • renderSideNavigation = TRUE
  • renderTaskBar = TRUE
  • renderFavorites = TRUE
  • renderExtensions = TRUE
  • renderBannerTitleGraphic = TRUE
  • renderBannerTitle = TRUE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 1
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 2
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 3
  • sideNavigationStartLevel = 4
DoubleTopNavMinimal
  • renderMainMenu = TRUE
  • renderTopNavigation= TRUE
  • renderMainMenuActions = FALSE
  • renderSelfCare = FALSE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = FALSE
  • renderToolBar = FALSE
  • renderContentPalette = FALSE
  • renderPeoplePalette = FALSE
  • renderContextMenus = FALSE
  • renderSideNavigation = TRUE
  • renderTaskBar = FALSE
  • renderFavorites = FALSE
  • renderExtensions = FALSE
  • renderBannerTitleGraphic = FALSE
  • renderBannerTitle = FALSE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 0
  • breadCrumbStartLevel = 0
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 2
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 3
  • sideNavigationStartLevel = 4
SideNavOnly
  • renderMainMenu = TRUE
  • renderTopNavigation = FALSE
  • renderMainMenuActions = TRUE
  • renderSelfCare = TRUE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = TRUE
  • renderSideNavigation = TRUE
  • renderTaskBar = TRUE
  • renderFavorites = TRUE
  • renderExtensions = TRUE
  • renderBannerTitleGraphic = TRUE
  • renderBannerTitle = TRUE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 1
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 0
  • topNavigationStartLevel = 0
  • topNavigationStopLevel = 0
  • sideNavigationStartLevel = 2
SideNavOnlyMinimal
  • renderMainMenu = TRUE
  • renderTopNavigation = FALSE
  • renderMainMenuActions = FALSE
  • renderSelfCare = FALSE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = FALSE
  • renderToolBar = FALSE
  • renderContentPalette = FALSE
  • renderPeoplePalette = FALSE
  • renderContextMenus = FALSE
  • renderSideNavigation =TRUE
  • renderTaskBar = FALSE
  • renderFavorites = FALSE
  • renderExtensions = FALSE
  • renderBannerTitleGraphic = FALSE
  • renderBannerTitle = FALSE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 0
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 0
  • topNavigationStartLevel = 0
  • topNavigationStopLevel = 0
  • sideNavigationStartLevel = 2
NoTheme
  • renderMainMenu = FALSE
  • renderTopNavigation = FALSE
  • renderMainMenuActions = FALSE
  • renderSelfCare = FALSE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = FALSE
  • renderToolBar = FALSE
  • renderContentPalette = FALSE
  • renderPeoplePalette = FALSE
  • renderContextMenus = FALSE
  • renderSideNavigation = FALSE
  • renderTaskBar = FALSE
  • renderFavorites = FALSE
  • renderExtensions = FALSE
  • renderBannerTitleGraphic = FALSE
  • renderBannerTitle = FALSE
  • renderPortletFragmentIDAnchor=FALSE
  • breadCrumbMaxLevels = 0
  • breadCrumbStartLevel = 0
  • rootNavigationStartLevel = 0
  • rootNavigationStopLevel = 0
  • topNavigationNumRows = 0
  • topNavigationStartLevel = 0
  • topNavigationStopLevel = 0
  • sideNavigationStartLevel = 0
Federation
注: Federation テーマ・ポリシーは、 XML 構成インターフェース (ページ属性 com.ibm.portal.ThemePolicy を使用) またはプロパティー・ポートレットのいずれを介しても、 ページに適用することはできません。
  • renderMainMenu = FALSE
  • renderTopNavigation = FALSE
  • renderMainMenuActions = FALSE
  • renderSelfCare = FALSE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = FALSE
  • renderSideNavigation = FALSE
  • renderTaskBar = FALSE
  • renderFavorites = FALSE
  • renderExtensions = FALSE
  • renderBannerTitleGraphic = FALSE
  • renderBannerTitle = FALSE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 0
  • breadCrumbStartLevel = 0
  • rootNavigationStartLevel = 0
  • rootNavigationStopLevel = 0
  • topNavigationNumRows = 0
  • topNavigationStartLevel = 0
  • topNavigationStopLevel = 0
  • sideNavigationStartLevel = 0
SingleTopNavLevel2
  • renderMainMenu = TRUE
  • renderTopNavigation = TRUE
  • renderMainMenuActions= TRUE
  • renderSelfCare = TRUE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = TRUE
  • renderSideNavigation = TRUE
  • renderTaskBar = TRUE
  • renderFavorites = TRUE
  • renderExtensions = TRUE
  • renderBannerTitleGraphic = TRUE
  • renderBannerTitle = TRUE
  • renderPortletFragmentIDAnchor=TRUE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 2
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 1
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 2
  • sideNavigationStartLevel = 3
Palette
  • renderMainMenu = TRUE
  • renderTopNavigation = TRUE
  • renderMainMenuActions= TRUE
  • renderSelfCare = TRUE
  • renderBreadCrumbTrail = FALSE
  • renderSearch = TRUE
  • renderToolBar = TRUE
  • renderContentPalette = TRUE
  • renderPeoplePalette = TRUE
  • renderContextMenus = TRUE
  • renderSideNavigation = TRUE
  • renderTaskBar = TRUE
  • renderFavorites = TRUE
  • renderExtensions = TRUE
  • renderBannerTitleGraphic=TRUE
  • renderBannerTitle=TRUE
  • renderPortletFragmentIDAnchor=FALSE
  • breadCrumbMaxLevels = 5
  • breadCrumbStartLevel = 1
  • rootNavigationStartLevel = 1
  • rootNavigationStopLevel = 1
  • topNavigationNumRows = 1
  • topNavigationStartLevel = 2
  • topNavigationStopLevel = 2
  • sideNavigationStartLevel = 3

カスタム・テーマ属性

上記の各ポリシーの属性に加えて、テーマ・ポリシーに属性を追加して、JSP または JSPF で使用できます。 以下のコード例は、カスタム属性 renderTestAttribute がどのようにテーマ・ポリシーに追加され、JSP または JSPF でどのようにアクセスされるかを示したものです。

メイン・テーマ・ポリシーにはこの属性およびロック属性が必要です。 これは、以下のようにルート・テーマ・ポリシーに追加されます。
<policyValue
      Name="renderTestAttribute"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
</policyValue>
<policyValue
      Name="renderTestAttributeLock"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>false</value>
</policyValue>

属性とその値で構成されるポリシー値セットは、ネストできます。子属性は、親属性から値を継承するかオーバーライドすることができます。ポリシー属性に対応するロック属性の値を true として指定すると、ポリシー・ノードがロックされます。この場合、子属性は、親属性から値を継承する必要があり、親属性の値をオーバーライドすることはできません。

以下のコードを使用して、ルート・テーマ・ポリシーとは異なる値を必要とする各テーマ・ポリシーに属性を追加します。
<policyValue
      Name="renderTestAttribute"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>false</value>
</policyValue>
これはブールであるため、値は true または false に設定されます。
以下のコードを使用して、JSP または JSPF 内の属性にアクセスします。
<% boolean isTestAttribute = themePolicy.getValueAsBoolean("renderTestAttribute", false); 
if(isTestAttribute){%>	  
<p> Display this paragrah if renderTestAttribute is true. </p>
<%}%>

上記の例で、renderTestAttribute の値が true の場合は、段落が表示されます。 themePolicy は、このトピックの『JSP でのテーマ・ポリシーの使用』のセクションで定義されています。

3 つのアクセサー・メソッドがあります。
  • getValueAsBoolean(String key, boolean defaultValue);
  • getValueAsInt(String key, int defaultValue);
  • getValueAsString(String key, String defaultValue);
ここで、key は属性の名前であり、defaultValue は、テーマ・ポリシーから属性値が取得できなかった場合に使用される値です。

XML 構成インターフェースを使用したページ上でのテーマ・ポリシーの設定

テーマ・ポリシーは、ページ・メタデータ属性 com.ibm.portal.ThemePolicy を使用して、XML 構成インターフェースを介してページに適用できます。 以下に、ページ ThemePolicyPageTest のテーマ・ポリシーのページ・メタデータを設定する XML スクリプトの例を示します。

<request type="update" create-oids="true" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd">
    <portal action="locate">
        <content-node action="update" ordinal="last"
uniquename="ibm.portal.ThemePolicyPageTest" content-parentref="Content.Root"
active="true" allportletsallowed="false" create-type="explicit"
objectid="wp.theme.policytestpage" type="page">
		    <supported-markup markup="html" update="set"/>
		 <!--@LocaleData_1@-->
		   <parameter name="com.ibm.portal.ThemePolicy" type="string"
update="set">theme/SingleTopNavMinimal</parameter>
        </content-node>

    </portal>
</request>

JSP でのテーマ・ポリシーの使用

テーマ・ポリシーを JSP 内で直接使用することもできます。 これには、以下のコードを使用します。

<themepolicy:initthemepolicy/>
<jsp:useBean id="themePolicy"
class="com.ibm.portal.theme.policy.ThemePolicyBean" scope="page"/>
<% themePolicy.setValuesMap(portalThemePolicyMap);%>

このコード例では、テーマ・ポリシー属性をラップするテーマ Bean が初期化されます。

JSP 内で属性を使用するには、${themePolicy.attribute) という構文を使用してその属性を参照します。ここで、属性は例えば renderSideNavigation などです。 以下のコードは、renderSideNavigation をテストします。 これが TRUE の場合は、以下のコードが実行されます。

<c-rt:if test = "${themePolicy.renderSideNavigation}">
<!-- following code -->
<….>
<….>
</c-rt:if>

以下のコード例は、startLevel をテーマ・ポリシー属性 sideNavigationStartLevel の値に設定します。

<portal:navigation  startLevel="${themePolicy.sideNavigationStartLevel}"

ユーザー独自のテーマ・ポリシーの作成

以下のコード例 addThemePolicyNode.xml は、新規テーマ・ポリシーを作成および追加する方法の例を示しています。 その後この XML ファイルは、テーマ・ポリシー XML 定義を含むファイルの場所と名前を反映するように更新されます。

<?xml version="1.0" encoding="UTF-8"?>
<request xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
 create-oids="true" type="update" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <portal action="locate">
        <policy-node action="update" label="WebPage" type="" path="">
             <url>file:///c:/temp/addTestThemePolicyNode.xml</url>
        </policy-node>
    </portal>
</request>
XML 構成インターフェースを使用して、以下にリストされている TestThemePolicy 定義ファイル addTestThemePolicyNode.xml を参照する addThemePolicyNode.xml を実行します。 このファイルは、テーマ・ポリシーの XML 定義を表します。
注: ここでは、このファイルの以下の属性を以下のように設定することが重要です。
  • Type 属性を「theme」に設定する。
  • PathType 属性を「/theme」に設定する。
  • PznType 属性および Title 属性に同じ値を設定する。
<?xml version="1.0" encoding="UTF-8"?>
<!--

    Licensed Materials - Property of IBM, 5724-E76, 5655-R17, 
    (C) Copyright IBM Corp. 2006 - All Rights reserved.

-->
<policyList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="Policy.xsd">
<policy>
    <policyValue 
      Name="Path"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value></value>
    </policyValue>
    <policyValue 
      Name="Type"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>theme</value>
    </policyValue>
    <policyValue 
      Name="Description"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>Test Theme Policy</value>
    </policyValue>
    <policyValue 
      Name="Title"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>TestThemePolicy</value>
    </policyValue>
    <policyValue 
      Name="Editor"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value></value>
    </policyValue>
    <policyValue 
      Name="NameResKey"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value></value>
    </policyValue>
    <policyValue 
      Name="PznRule"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value></value>
    </policyValue>
    <policyValue 
      Name="PznType"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>TestThemePolicy</value>
    </policyValue>
    <policyValue 
      Name="Remote"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value></value>
    </policyValue>
    <policyValue 
      Name="PathType"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>/theme</value>
    </policyValue>
    <policyValue
      Name="renderMainMenu"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderTopNavigation"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderMainMenuActions"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderSelfCare"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderBreadCrumbTrail"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>false</value>
    </policyValue>
    <policyValue
      Name="renderSearch"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderToolBar"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderContentPalette"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderPeoplePalette"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderContextMenus"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderSideNavigation"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderTaskBar"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderFavorites"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderExtensions"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderBannerTitleGraphic"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderBannerTitle"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
    </policyValue>
    <policyValue
      Name="renderPortletFragmentIDAnchor"
      Factory="com.ibm.wps.policy.parse.BooleanFactory">
      <value>true</value>
		</policyValue>
		<policyValue
      Name="breadCrumbMaxLevels"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>5</value>
    </policyValue>
    <policyValue
      Name="breadCrumbStartLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>1</value>
    </policyValue>
    <policyValue
      Name="rootNavigationStartLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>1</value>
    </policyValue>
    <policyValue
      Name="rootNavigationStopLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>1</value>
    </policyValue>
    <policyValue
      Name="topNavigationNumRows"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>1</value>
    </policyValue>
    <policyValue
      Name="topNavigationStartLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>2</value>
    </policyValue>
    <policyValue
      Name="topNavigationStopLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>2</value>
    </policyValue>
    <policyValue
      Name="sideNavigationStartLevel"
      Factory="com.ibm.wps.policy.parse.IntegerFactory">
      <value>3</value>
    </policyValue>
    <policyValue 
      Name="Version"
      Factory="com.ibm.wps.policy.parse.StringFactory">
      <value>1.0</value>
    </policyValue>
  </policy>
 </policyList>

テーマ・ポリシーの更新

テーマ・ポリシーを更新するだけの場合は、以下のガイドラインを使用します。
  • テーマ・ポリシーをエクスポートする。
  • 更新する属性の値を編集する。
  • XML 構成インターフェースを使用して、更新されたテーマ・ポリシー定義を含むファイルを参照する addThemePolicyNode.xml を実行する。

テーマ・ポリシーの拡張および更新

更新時に、テーマ・ポリシーに属性を追加して拡張する場合は、ルート・テーマ・ポリシーに属性を追加する必要もあります。 これを実行するには、以下のガイドラインを使用します。
  • テーマ・ポリシー構造全体をエクスポートする。
  • ルート・テーマ・ポリシーを編集する。
  • ルート・テーマ・ポリシーと値が異なる場合は、属性を追加して更新するテーマ・ポリシーを編集する。
  • 更新された定義を含むファイルを参照する addThemePolicyNode.xml を実行する。
テーマ・ポリシーに既に存在する属性の値を変更するだけの場合は、以下のガイドラインを使用します。
  • 変更する必要のあるテーマ・ポリシーをエクスポートする。
  • 属性に適切な変更を行う。
  • 更新された定義を含むファイルを参照する addThemePolicyNode.xml を実行する。

テーマ・ポリシーのエクスポート

以下のコード例 exportThemePolicyNode.xml を使用して、テーマ・ポリシーをエクスポートします。 指定されたファイルは、エクスポートされた情報が書き込まれる場所を示します。 以下の例では、すべての テーマ・ポリシーをエクスポートします。

<?xml version="1.0" encoding="UTF-8"?>
<request xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
 create-oids="true" type="export" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <portal action="locate">
        <policy-node action="export" label="WebPage" 
                type="theme" path="">
             <url>file:///c:/temp/exportThemePolicies.xml</url>
        </policy-node>
    </portal>
</request>

以下の例では、TestThemePolicy テーマ・ポリシーのみをエクスポートします。

<?xml version="1.0" encoding="UTF-8"?>
<request xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
 create-oids="true" type="export" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <portal action="locate">
        <policy-node action="export" label="WebPage" 
                type="theme" path="TestThemePolicy">
             <url>file:///c:/temp/exportTestThemePolicy.xml</url>
        </policy-node>
    </portal>
</request>

テーマ・ポリシーの削除

以下のコード例 deleteThemePolicyNode.xml を使用して、テーマ・ポリシーを削除します。
注: path は、削除される子ポリシーの「PznType」です。 「PznType」は、XML ファイル内で使用されるポリシーの ID です。 具体的には、「PznType」は、この子ノードの実際の JCR (Java Content Repository) XPath 名です。 XPath は、XML 文書 (テーマ・ポリシーなど) からエレメントを選択するために設計された検索言語です。 ポリシーは、XPath または Root/Child1/Child2 のような形の検索で探し出されます。
<request xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
 create-oids="true" type="update" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <portal action="locate">
        <policy-node action="delete" label="WebPage" 
                type="theme" path="TestThemePolicy">
        </policy-node>
    </portal>
</request>

テーマ・エクステンション・ポイント

Eclipse Extension Point Framework を使用すると、テーマは、さまざまなポイントで、クラスパスに新規 JAR ファイルを配置するだけでテーマ機能を拡張できるようになります。

テーマにエクステンション・ポイントを組み込む

<portal-theme-ext> TLD のタグは、テーマ・エクステンション・ポイントを処理するために提供されています。 以下のコードは、テーマに組み込まれたエクステンション・ポイントの単純な例を示しています。
<%-- Declares extension point ID that you want to retrieve attached extensions for --%>
	<portal-theme-ext:themeExtension id="com.ibm.portal.theme.plugin.SimpleLinks" >		
		<%-- loop over active extensions, if any --%>
		<portal-theme-ext:themeExtensionLoop>
		<%-- Use extension properties to add content to the page --%>	
		<a href="<portal-theme-ext:themeExtensionItemUrl />" >
		<portal-fmt:title varname=
     '<%=(com.ibm.portal.theme.plugin.ThemeItem)themeExtension%>' /></a>
	</portal-theme-ext:themeExtensionLoop>				
</portal-theme-ext:themeExtension>

テーマ・エクステンション・タグおよびその使用オプションについて詳しくは、 ポータル JSP で使用されるタグの説明を参照してください。 テーマ公開 API の Javadoc 情報も参照してください。これは、<portal-theme-ext> タグがこれらのインターフェースのみと連動するためです。

組み込まれたポータル・テーマの既存のエクステンション・ポイントを使用する

組み込まれたポータル・テーマには、テーマ JSP を編集することなく限定的にカスタマイズを可能にするエクステンション・ポイントが用意されています。 これを実行するには、以下のガイドラインを使用します。
  1. 希望のインターフェースを実装する (例えば、com.ibm.portal.theme.plugin.ThemeLinkItem)。
  2. エクステンションを宣言する plugin.xml ファイルを作成する。
  3. 必要な JAR ファイルを作成する。
  4. ポータル・アプリケーションのクラスパスにあるディレクトリーに、JAR ファイルを格納する。新規ディレクトリーを作成して、カスタム・コードとベース・コードを区別することをお勧めします。このディレクトリーは、 was_profile_root ディレクトリー内に作成できます。
  5. 既存の共有ライブラリーを編集して、${USER_INSTALL_ROOT}/<directory_with_new_JAR> の項目を追加することにより、WebSphere Application Server 管理コンソールから JAR ファイルのクラスパスを更新する。 詳しくは、WebSphere Application Serverを参照してください。
  6. サーバーを再起動する。これで、エクステンションがテーマに表示されます。
plugin.xml ファイルまたはエクステンション・フレームワークの詳細については、Eclipse Extension Point Framework のドキュメンテーションを参照してください。 テーマ公開 API の Javadoc 情報には、コーディングおよび plugin.xml のサンプルも含まれています。

デフォルトのエクステンション・ポイント

以下の表に、ポータル・テーマに組み込まれているエクステンション・ポイントについての説明を示します。「ID」フィールドは、plugin.xml で使用されるエクステンション・ポイント ID です。「デフォルト・インプリメンテーション」フィールドは、デフォルトのエクステンション・ポイントで必要とされる情報を提供するインターフェースの説明です。タイプの実施は実行時には実行されません。

表 23. ポータル・テーマのデフォルト・エクステンション・ポイント
ID 説明 デフォルト・インプリメンテーション
com.ibm.portal.theme.plugin.MetaTagDataItems  ページのメタ・タグにデータを追加する方法をコンポーネントに提供する {@link DefaultThemeTextItem}
com.ibm.portal.theme.plugin.Styles  CSS スタイル (リンクまたは埋め込み css) をページに提供する方法をコンポーネントに提供する {@link DefaultThemeTextItem}
com.ibm.portal.theme.plugin.JavascriptItems  JavaScript (リンクまたは実際の js コード) をページに追加する方法をコンポーネントに提供する {@link DefaultThemeTextItem}
com.ibm.portal.theme.plugin.HorizontalPageBarItems  jsp コンテンツを水平ページ・バーに追加する方法をコンポーネントに提供する {@link DefaultThemeJspInclude} 
com.ibm.portal.theme.plugin.VerticalPageBarItems jsp コンテンツを垂直ページ・バーに追加する方法をコンポーネントに提供する {@link DefaultThemeJspInclude}
com.ibm.portal.theme.plugin.PageContextMenuItems  項目をページ・コンテキスト・メニューに追加する方法をコンポーネントに提供する {@link DefaultThemeLinkItem} 
com.ibm.portal.theme.plugin.PortletContextMenuItems 項目をポートレット・コンテキスト・メニューに追加する方法をコンポーネントに提供する {@link DefaultThemeLinkItem}
com.ibm.portal.theme.plugin.Flyouts  フライアウトをページに追加する方法をコンポーネントに提供する {@link DefaultThemeJspInclude}
ページ・ビルダー テーマには、 ページ・コンテキスト・メニューおよびポートレット・コンテキスト・メニューに項目を追加するため、 およびアクティブ・サイト分析を使用するときにアグリゲーターをページに組み込むための、拡張ポイントが含まれています。 以下は、これらのデフォルトの拡張ポイントの拡張ポイント ID です。
  • com.ibm.portal.theme.plugin.PageContextMenuItems
  • com.ibm.portal.theme.plugin.PortletContextMenuItems
  • com.ibm.portal.theme.plugin.ActiveSiteAnalyticsItems

アクティブ・サイト分析の拡張ポイントに関する背景情報については、『アクティブ・サイト分析用にテーマを備える』および『カスタム・アグリゲーターの注入』のトピックを参照してください。

画面

画面はポータル・コンテンツのページです。 ポータル・ページを最初にロードすると、 まず「ホーム」画面 (Home.jsp) が表示されます。 「エラー」画面などのその他の画面も表示できます。 画面の選択は、テーマによって提供されるツールバー上のリンクまたはボタンにより決定されます。 「ホーム」画面には、ページ・レイアウトとコンテンツをレンダリングする <portal-core:pageRender/> タグが含まれています。

カスタム画面へのリンクの作成

ポートレット・コンテンツは「ホーム」画面内にのみレンダリングされます。 ただし、作成した他の画面にコンテンツを表示することもできます。 例えば、導入画面を作成して、 ユーザーがポータル・サイトにログインする前に、 マルチメディアのあいさつをユーザーに表示することもできます。 <portal-navigation:url screen="name"/> タグを使用して、/screens ディレクトリーにある JSP へのリンクを作成します。 name 値は 、.jsp 拡張子なしの、画面 JSP ファイル名でなければなりません。

banner_toolbar.jspf からの次の例では、 リンクの HREF 属性に応じて ForgotPassword 画面への URL が作成されます。

   <%-- forgot password button --%>
   <portal-logic:if loggedIn="no" notScreen="ForgotPassword">
      <% if (firstButton) { firstButton = false; } else { %> | <% } %>
      <a class="wpsToolBarLink" href='<portal-navigation:url screen="ForgotPassword" home="public"/>'>
         <portal-fmt:text key="link.password" bundle="nls.engine"/>
      </a>
   </portal-logic:if>

スキン

スキンは、行コンテナー、列コンテナー、ポートレットなどのようなコンポーネントの周辺にレンダリングされる境界線を表します。 スキンは、<portal-core:pageRender/> タグによってポータル・ページにロードされます。スキンはテーマとは無関係でインストールされます。 しかし、スキンはテーマに関連付けされます。

スキンはポートレット以外の「ルック・アンド・フィール」も定義します。 すなわち、コンポーネント のルック・アンド・フィールを定義します。 これらのコンポーネントには、コンテナー、および制御が組み込まれます。 この階層構造は下のダイアグラムに描画されています。

図 1. 「ホーム」画面の基本的なレイアウト
スキンの構成。
この図では、ページに 1 つの行が含まれ、その中に 2 つの列コンテナーがあります。
それぞれの列コンテナーには、ポートレットが 2 つ含まれています。
この図について詳しくは、このトピックのテキストを参照してください。

スキンのコンポーネントは、以下の順序で呼び出されます。

  1. 「ホーム」画面 (Home.jsp) の <portal-core:pageRender/> タグが、選択したノードのコンポーネントを表示します。 各コンポーネントは、『ポータル・ページのカスタマイズ』のトピックで定義されるポータル・レイアウトに従って、行コンテナー、列コンテナー、およびコントロールとして実装されます。 制御は Control.jsp を使用して表示されます。 「ホーム」画面の基本的なレイアウトの図のトピックは、 2 つの列コンテナー (それぞれに 2 つのポートレットがある) を持つ 1 つの行コンテナーを示しています。
  2. 行および列コンテナーは、Java コードまたは <portal-skin:layoutNodeLoop/> および <portal-skin:layoutNodeRender/> エレメントを使用して、ネストされているコンポーネントを表示する。
  3. それぞれのポートレットは、Control.jsp. ファイル内の <portal-skin:portletRender/> タグによりレンダリングされる。 また、コントロールにより、ポートレット出力の周辺に境界線およびタイトル・バーが作成されます。

    注: ポートレット・タイトル・バーの一部のアイコンはパフォーマンスに影響を与えます。

用意されているスキン

ポートレットのレンダリング用として、WebSphere Portal には IBM、スキンなし、シン・スキンおよびフレーム・スキンが用意されています。

2 つの新しいスキン「ページ・ビルダー - 標準」および「ページ・ビルダー - コンパクト」を、ページ・ビルダーテーマに割り当てることができます。これらのスキンは、 wp_profile_root/installedApps/node_name/Enhanced_Theme.ear/wp.theme.enhancedtheme.war/skins/html にあります。

用意されているスキンの使用上の注意
  • 「ページ・ビルダー - 標準」および「ページ・ビルダー - コンパクト」スキンは、ページ・ビルダーテーマのみと併用しなければなりません。ページ・ビルダーテーマ以外のテーマにこれらのスキンを割り当てることは推奨されていません。
  • フレーム・スキンは、ポータルのデフォルト・スキンとして設定できません。 また、フレーム・スキンをポータル・テーマに適用することも推奨されていません。 フレーム・スキンは、このスキン用に限定的に設計されたポートレットにのみ適用することができます。
  • ポータル・テーマ・ディレクトリーが削除または名前変更されている場合、 ポータル・リソース・ローダーは themes/html/Default.jsp を使用します。 この場合は、フォールバック・スキンを使うことも必要です。 これを行うには、skins ディレクトリーを名前変更します。 例えば、skins¥html¥IBM ディレクトリーは、skins¥html¥IBM1 に名前変更する必要があります。 テーマが破損している場合は、問題の原因となっているそのテーマとスキンのディレクトリーを名前変更して、 機能する最小限のテーマにすることができます。

フレーム・スキンの詳細

用意されているフレーム (インライン・フレーム)・スキンには、他のスキンに比べ、より実践的な目的があります。 このスキンは、ページ上の HTML フレームにポートレット・コンテンツをレンダリングします。 フレームは、個別のブラウザー・ウィンドウとして扱われ、他の HTML 形式ドキュメントを含む外部オブジェクトの組み込みに使用します。

フレーム・スキンは、レンダリングするのが遅いポートレットの場合にとりわけ有用です。 このスキンでは、フレーム内でポートレットのコンテンツを待機することなく、 ポータル・ページの残り部分をレンダリングすることができます。 このスキンの幅は 100% に、高さは 250 ピクセルに設定されています。

この設定を変更するには、次のステップを実行します。

  1. ../skins/html ディレクトリー内の /IFrame サブディレクトリーを見つける。
  2. ファイル Control.jsp を編集する。
  3. フレーム用のマークアップを見つける。
    <iframe src='<%wpsURL.write(out);%>' SCROLLING="auto" FRAMEBORDER="0" Width="100%" height="250">
  4. このタグの幅属性と高さ属性を変更する。
  5. ファイルを保管して閉じる。

ポートレットの自動最大化

WebSphere Portal の初期のバージョンでは、ポートレット・モードが表示モードから別のモードに変更された場合に、ポートレットの状態が自動的に最大化に設定されていました。 例えば、編集モードに切り替えた場合、ポートレットはユーザーが表示モードに戻すまで最大化状態に変更されます。 この自動最大化の動作はデフォルトでは削除されていますが、以下のレベルで実装することができます。
  • ポータル・レベル

    モードの変更時にすべてのポートレットを自動的に最大化するように構成するには、portlet.automaximize 構成サービス・パラメーターを true に設定します。

  • スキン・レベル

    この動作は、<portal-navigation:urlGeneration/> タグを使用してポートレット・スキンに実装することができ、これによりアドミニストレーターはどのポートレットが自動的に最大化されるかを制御することができます。 例えば、Highlight および Highlight_Max というスキンを作成することができます。この 2 つの違いは、Highlight_Max を使用した場合は、ポートレットが表示以外のモードに切り替わったときに、自動的にポートレットの状態が変更されるということだけです。

  • ポートレット・レベル

    特定のポートレットを自動的に最大化するように構成するには、ポートレット開発者が、com.ibm.portal.automaximize 初期設定パラメーターを true に設定します。

重要: 自動最大化は、編集または構成モードに切り替わった場合に最大化するように開発されていない標準ポートレットでは問題を引き起こすことがあり、それによって、「完了」または「キャンセル」ボタンの作成時に、正しいウィンドウ状態情報が提供されないことがあります。 また、IBM ポートレットでは、<portletAPI:createReturnURI> タグおよび <portal-skin:portletBack> タグ、または createReturnURI() メソッドによって作成された戻り URI と自動最大化を組み合わせて使用すると、望ましくない結果が発生する場合があります。 ポートレット・モードとウィンドウ状態は直交であり、ユーザーが「戻る」をクリックして表示モードに戻る前には表示されていなかったポートレット・モードとウィンドウ状態の組み合わせが表示される可能性があります。

集約

WebSphere Portal は、ポータル・データベースに保持されているページ・ディスクリプターから、完全に動的なページの集合体を提供します。

ポータルでは、ポータル・アプリケーション上で一貫性のあるビューをユーザーに提供することが必要であり、また 1 つのコンテキストで提示される特定のアプリケーション・セットをユーザーが定義できるようにすることが必要です。 ユーザーが使用するデバイスにより、そのデバイスの要件を満たすためのアプリケーション・セットのレンダリングは異なります。 例えば、「ニュース」、「株価」、「お天気」、および「検索」が組み込まれたアプリケーション・セットがあるときに 、音声対話による従来型の電話、ディスプレイやキーボードが制限されている WML デバイス、あるいは PC 系のブ ラウザー上でレンダリングをするときのことを考えてください。 集約コンポーネントは、以下のタスクに、デバイスからの各要求を提供する必要があります。

  1. ユーザー、デバイスまたは クライアント、および選択言語に関する情報を収集する。
  2. ユーザーにアクセス権があるアプリケーション・セットからアクティブなポートレットを選択する。
  3. アクティブ・ポートレットの出力を一貫性があり使用可能な表示内容に集約する。

アクティブ・ページが判別されると、選択済みのページのレイアウトを使用して定義されたアプリケーションのコンテンツを集約し、出力を調整し、すべてを 1 つの完全なページに統合する必要があります。 WebSphere Portal は、ポータル・データベースに保持されているページ・ディスクリプターから、完全に動的なページの集合体を提供します。

ページ・コンポーネントをレンダリングするには、JSP、イメージ、スタイルシート、およびリソースを使用します。 リソースはファイル・システム内にあり、Portal Server が使用するパス命名規則により、クライアントが必要とするリソースを正しく見つけることができます。 ビジュアルな外観やレイアウトをカスタマイズしたり、他のマークアップ言語やクライアントのサポートを追加したりするには、これらのリソースの場所が集約をサポートする方法を最初に把握している必要があります。

ポータル・リソースの検索順序

集約を行うあいだ、Portal Server はテーマとスキンを検索します。 検索順序は、特定のサブディレクトリーから始まり、より一般的な上位のディレクトリーに移動します。

表 24. ディレクトリー別のポータル・リソースの検索順序
/themes ディレクトリー内の場所 /skins ディレクトリー内の場所
  1. /locale_region
  2. /locale
  3. /client
  4. /theme_name
  5. /markup
  1. /locale_region
  2. /locale
  3. /client
  4. /skin_name
  5. /markup

例えば、ロケールが en_US、ユーザーのスキンが Shadow に設定されている Internet Explorer を使用したクライアントからの要求の場合を考えてみます。 Portal Server の集約コンポーネントは、次の順序で Control.jsp ファイルを検索します。

 1.  /skins/html/Shadow/ie/en_US/Control.jsp
 2.  /skins/html/Shadow/ie/en/Control.jsp
 3.  /skins/html/Shadow/ie/Control.jsp
 4.  /skins/html/Shadow/en_US/Control.jsp
 5.  /skins/html/Shadow/en/Control.jsp
 6.  /skins/html/Shadow/Control.jsp
 7.  /skins/html/ie/en_US/Control.jsp
 8.  /skins/html/ie/en/Control.jsp
 9.  /skins/html/ie/Control.jsp
10.  /skins/html/en_US/Control.jsp
11.  /skins/html/en/Control.jsp
12.  /skins/html/Control.jsp
13.  /skins/Control.jsp

この例では、../ie/en_US ディレクトリーにファイルがないため、Portal Server は、 ../ie/en ディレクトリーでファイルを検索します。 Portal Server は、ファイルが見つかるまでこの階層を上に移動します。 必要なファイルは、/skins または /themes ディレクトリーに置く必要があります。 より特定のファイル・バージョンはそれに適したサブディレクトリーに置いてください。

集約によりファイルが見つけられると、メモリー内に情報が格納されます。 この検索は、Portal Server が再始動されるまで、後続の要求に対して繰り返されません。 その結果、ファイルが元の場所から移動された場合、ファイルは後続の要求でクライアントに送信されません。 例えば、集約が /themes/html/ie/en/Styles.css という場所を検索し保管する場合、言語設定が英語である Internet Explorer からの後続の要求は、/themes/html/ie/Styles.css を戻すのではなく、ファイルなしで戻されます。

ページに関する作業

ページの管理ポートレットに関連するさまざまなタスクを説明します。

ページの管理ポートレットを使用すると、以下のタスクを実行できます。
  • ページのプロパティー、ラベル、および URL の作成、再配列、削除、および編集
  • ページ、ラベル、および URL の再配列
  • ページ、ラベル、および URL へのアクセス権の割り当て
  • ポータル階層内の新規ロケーションへのページの移動

アドミニストレーターおよびユーザーはいずれも、適切なアクセス権を持っていれば、ページの作成および削除を実行できます。 ユーザーが削除できるのは、自分が作成したページ、または少なくとも管理者アクセス権を持つページのみです。

注: URL マッピングを作成するとき、またはページを作成あるいは変更するときは、URL マッピングとフレンドリー URL とがポータル内で一致したり、部分的に重複したり、相互に干渉したりしないようにしてください。 例えば、homeibmibm.com などのストリングを使用したり、ポータル内で URL マッピングまたはフレンドリー URL として既に使用されているストリングは使用しないようにします。 そうでないと、ときにはエラー・メッセージなしで、無限のブラウザー・リダイレクト・ループが発生することがあります。 そのようなストリングを判別するには、XML 構成インターフェースを使用してポータルからのエクスポートを作成し、 エクスポートされた XML 結果の出力ファイルをスキャンして、URL マッピングまたはフレンドリー URL として使用するストリングを見つけます。

ページ、共用ページ、派生ページ、および非表示のページ

共用ページ、派生ページ、および非表示のページでの動作と相違を理解しておくと、ページの管理、およびニーズにあった正しいタイプのページの作成に役立ちます。

ページは、コンテンツの表示方法を定義する編成エレメントです。 ページには、ポートレットとその他のページを含めることができます。共用ページを使用して、レイアウト・モデルを複数のページと共用できます。ページが共用されると、他のページは共用されているページのレイアウトを参照できます。派生ページは、共用ページの子で、その動作を認識しておく必要があります。

派生ページは、元のページのプロパティーを継承します。派生ページの作成は、オリジナルのページ上に新しい特殊なレイヤーを作成するのと同等です。 元のページと新しいレイヤーは、レンダリング時に集約されます。 新しいレイヤーは、元のページにあり、ここで制御されます。 既存ページを参照すると、元のページのコンテンツとレイアウトを維持した上で、他のユーザーに管理アクセス権を与えることができます。 以下は、派生ページに暗黙で適用されます。
  • 参照先のページでコンテンツがロックされている場合は、そのページを参照するすべての派生ページでコンテンツがロックされます。
  • 参照先のページでポートレットが削除されると、そのページを参照するすべてのページからポートレットが削除されて、そのポートレットの個々のユーザー設定値はすべて失われます。
  • 派生ページにアクセスするには、ユーザーは元のページへのアクセス権を所有している必要があります。 したがって、プライベート・ページをこのようにして共用することはできません。

元の親ページに行われた変更は、元の親ページを参照する派生ページに反映される場合があります。 レイヤーを別のレイヤー上に作成して、カスケード・ページのチェーンを作成できます。これを代行ページの特殊化といいます。 このプロセスでは、ルート・ページを作成して、最上位のアドミニストレーターがページの初期レイアウトとコンテンツを決定できることを意味します。次に、次のレベルのアドミニストレーターは、コンテンツとレイアウトを追加して、このページの特殊レイヤーを制御および変更できます。 このプロセスは、ページの管理者から副管理者へと続きます。 チェーン内の管理者または副管理者には、チェーン内のそれぞれのレイヤーだけしか見えません。ただし、自分のレイヤーよりも上のレイヤーのコンテンツを表示するには、それらのすべてのレイヤーに対するユーザー役割が必要です。 エンド・ユーザーは、適切なアクセス権がある場合に限り、そのページのレイヤーを見ることができます。 この概念を説明する例を以下に示します。

John はスーパーアドミニストレーターで、「Home」という名前のページを作成して、そのページに「Home」というタイトルを付けます。 Brandy は副アドミニストレーターで、このページの次のレベル (「Home_operations」という名前) を管理し、オペレーション・グループの従業員のために「Home」ページに追加する追加コンテンツを決定します。 Nick は、その次のレベルのアドミニストレーターで、「Home」ページの次のレベルの「Home_operations_transportation」を管理し、輸送部門の従業員のために「Home」ページに掲載するコンテンツを決定します。 Nick は、輸送ページのアドミニストレーターなので、「Home_operations」に対するユーザーの役割と「Home」に対するユーザーの役割のほかに、すべてのユーザーに影響するこのページに対して変更を施すことができるように、「Home_operations_transportation」に対する管理者としての役割が必要です。つまり、Nick には、「Home_operations_transportation」レベルを作成するために、すべてのレイヤーの組み合わせについてのユーザーの役割が必要です。 Desi は、「Home_operations_transportation」ページのエンド・ユーザーです。Desi には、「Home_operations_transportation」に対するユーザーの役割のほか、「Home_operations」に対するユーザーの役割と「Home」に対するユーザーの役割も必要です。 エンド・ユーザーである Desi がポータルにログオンすると、Desi は「Home」ページを見ることができます。 この「Home」ページは、ルートの「Home」ページに関連付けられているすべてのレイヤーの集合体です。

注:
  • 他のページが参照するページを削除すると、そのページを参照するすべてのページが削除されます。
  • ルート・ページ用に指定されているマークアップを、派生ページ上で変更することはできません。すべてのレイヤーを含む派生ツリー構造全体は、ルート・ページで指定されるマークアップをサポートしています。
  • 派生ページのタイトルと説明を変更する機能は、ポータル構成で使用不可にできます。 詳しくは、ポータル構成サービスallow.derived.titles パラメーターの説明を参照してください。

非表示のページ

ポータルに表示されないが、他のページから起動できるポートレットを含むページが必要なシナリオおよび使用例があります。 そのような非表示のページは、サイト・ナビゲーションには表示されませんが、ポートレットまたはテーマ・コード内に生成されたリンクから起動できます。 管理を容易にしシステム・リソースを節減するために、 そのような複数のページを 1 つの場所に配置して管理できます。 例えば People Finder の場合、ユーザーはテーマ内のリンクから起動できますが、 ポートレット・インスタンス自体はコンテンツ・モデル内の非表示のページにあります。

そのような目的のための非表示のページを作成する最も簡単な方法は、 コンテンツ・ルートの子の「非表示のページ (Hidden Pages)」ラベルの下にページを作成することです。 このラベルは、ナビゲーションには表示されません。 これはポータル内の非表示のページのコンテナーで、非表示のページに対するサポートの提供を続けながら、 トップ・ナビゲーション・リンクにレンダリングするために必要なサイクルを最小化します。

既存のテーマを使用する場合、ナビゲーションを適切なレベルでレンダリングするために、 テーマ・ポリシーまたはページ・メタデータに指定されたレベルに基づいてトップ・ナビゲーションをレンダリングすることに注意してください。 そのようなテーマを使用して、「非表示のページ (Hidden Pages)」ラベルの下に新しい非表示のページを作成する場合、 ページのメタデータ値 com.ibm.portal.themepolicy.topNavigationStartLevel3 に設定します。

ロックおよびアクセス権の変更を組み合わせて行う場合の派生ページの動作

親ページでアクセス権とロック機能を同時に使用し、変更を行うと、派生構造の複雑さに応じて、派生ページが変更されます。 以下のシナリオで、派生ページの動作を説明します。

編集者役割を持つアドミニストレーターが、2 列のレイアウトを持つページを作成し、各列にポートレットを配置します。 以下の図の青色の矢印は、このページのコンポーネントの親子関係を表しています。

2 列レイアウト

ポートレット、列、およびページの関係を表す 2 列レイアウトの図

次に、編集者役割を持つユーザーは、このページから明示的派生を作成し (「拡張オプション」で、「共用ページからコンテンツを使用するページ」を選択する)、次の図に示すように、明示的な派生ページに 2 つのポートレット (各列に 1 つのポートレット) を追加します。

ポートレットが 4 つある 2 列のレイアウト

各列に 2 つのポートレットがある 2 列レイアウトの図

2 つの新しい制御のまわりにある赤色のボックスは、これらの制御がページの新規 レイヤー 上にあることを表します。 元のページ・コンテンツと新規レイヤーとで、完全なページが構成されます。

編集者役割を持つユーザーが、既存の 2 列の横に 3 番目の列を作成し、すべてのポートレットをその新しい列に移動します。 新しい列は派生ページのレイヤー (赤色のボックス) に存在します。そのため次の図に示されるように、元のポートレットが追加情報 (緑色の矢印) によって新規列に移動されます。

3 列レイアウト

3 列レイアウトの図

明示的に派生したページをレンダリングすると、前の図に示すように、4 つのポートレットすべてが縦方向に配置されて表示されます。

次に、アドミニストレーターが、元のページ上のすべてのコンテナーおよびポートレットをロックします。 これは、集約されたページ (元のページと派生ページ) には影響しません。 次にアドミニストレーターは、その派生ページを作成したユーザーから編集者権限を除去し、そのユーザーに対し、特権ユーザー・アクセス権のみを割り当てます。

この特権ユーザーが派生ページにナビゲートすると、次の問題が発生します。

  • アドミニストレーターが元のページ上でロックを設定すると、派生ページに対して、元のページのレイアウトが強制される。 そのため、元のポートレットを新規列に移動させる情報 (上の図の緑色の矢印) が削除されます。
  • ロックがあるため、派生ページ (赤色のボックス) の追加レイヤーへの追加は抑止される。 特権ユーザーに表示される派生ページは、元のページと全く同じものです。

アドミニストレーターが派生ページのユーザーに対して編集者アクセス権を再割り当てすると、そのレイアウトはそのユーザーには、派生ページのどの段階とも異なって表示されます。 派生ページへの追加のレイヤーは、もう一度可視になりますが、次の図に示すとおり、元のポートレットの移動についての情報は削除されています。

ポートレットの移動についての情報が欠落している 3 列レイアウト

欠落情報を示す 3 列レイアウトの図

他のレイヤーのシナリオにも、同様の方法で同じ規則が適用されます。 元のページからのエレメントの移動情報は、削除されます。 一方、派生ページのレイヤーでのアクション、例えば、ポートレット、行、または列の追加などは、上述のようなアクセス権の再割り当て後にも存続します。

ページの追加

ページでは、ポートレットやその他のページなどのコンテンツを単一のエリアに表示します。ページを作成すると、情報を編成し、新規ナビゲーション・エレメントをサイトに追加できます。

このタスクについて

既存ページの下に新規ページを作成したり、既存ページの参照、レイアウトの適用、サポートされるマークアップの選択が可能になります。公開用ページでは、アドミニストレーター、管理者、または編集者の役割が割り当てられている必要があります。専用ページでは、アドミニストレーターまたは特権ユーザーの役割が割り当てられている必要があります。

ページを作成する際は、常に新規ページを新規レイアウトで作成するオプションがあります。編集者および特権ユーザーの役割が割り当てられている場合は、派生ページを派生元の親ページに作成することができます。派生ページで編集者の役割が割り当てられている場合は、マークアップ以外のすべてを変更することができます。派生ページで特権ユーザーの役割が割り当てられている場合は、派生ページのタイトル、スキン、レイアウトを変更することができます。レイアウトについては、派生元の親ページにより制限されます。 既存ページ、レイアウト、サポートされるマークアップ、ロック、スキン、ポートレット・リストを参照する場合、ロケール固有のタイトルは参照する既存ページにより事前に定義されます。元のページへの変更は、参照されたすべてのページへの変更内容と同じになります。

新規ページを作成する際は、タイトルを付けることができます。その他すべての設定はオプションです。

新規ページを作成するには、以下のステップを実行します。

手順

  1. 「管理」 > 「ページの管理」とクリックする。
  2. 「コンテンツ・ルート」 をクリックする。
  3. 「ホーム」をクリックするか、新しいページを作成する ポータルの別のセクションにナビゲートする。
  4. 「新規ページ」をクリックして新規ページを作成する。新規ページを作成するには、ページの管理ポートレットを終了します。
  5. 新規ページのタイトルを「タイトル」に入力する。 これは、デフォルト・ロケールのタイトルです。
  6. 「固有名」にページの固有名を入力する。 既存のページと既に関連付けられている固有名を指定した場合、新規ページは指定した固有名ではなく、直列化 ID (システム・デフォルトで提供) を使用して作成されます。
  7. 「分かりやすい URL」に固有の URL を入力する。 これにより、覚えやすく共用しやすい、ページのカスタム・アドレスが作成されます。
    注: URL マッピングを作成するとき、またはページを作成あるいは変更するときは、URL マッピングとフレンドリー URL とがポータル内で一致したり、部分的に重複したり、相互に干渉したりしないようにしてください。 例えば、homeibmibm.com などのストリングを使用したり、ポータル内で URL マッピングまたはフレンドリー URL として既に使用されているストリングは使用しないようにします。 そうでないと、ときにはエラー・メッセージなしで、無限のブラウザー・リダイレクト・ループが発生することがあります。 そのようなストリングを判別するには、XML 構成インターフェースを使用してポータルからのエクスポートを作成し、 エクスポートされた XML 結果の出力ファイルをスキャンして、URL マッピングまたはフレンドリー URL として使用するストリングを見つけます。
  8. 新しいページの外観を決めるテーマを選択します。 このオプションは、レベル 1 または 2 のページのみで利用できます。
  9. 「テーマ・スタイル」を選択して、ページに適用するスタイルを選択する。
  10. 「アイコン」フィールドに、ページ・タイトルの横のタブに表示するページ・アイコンのパスとファイル名を入力する。 このイメージのパスは、現行テーマを基準にした相対パスにする必要があります。
  11. 「このページを自分専用のページにする」選択して、他のユーザーによるページへのアクセスを制限する。
  12. 他のユーザーがこのページにブックマークを付けることを許可する場合は、「このページをユーザーの「お気に入り」リストに追加できるようにする」にチェック・マークを付ける。ユーザーがこのページにブックマークを付けると、バナーの「お気に入り」から利用することができます。
  13. このページのコンテンツを他のページと共用する場合は、「他のページがこのページのコンテンツを共用できるようにする」にチェック・マークを付ける。チェック・マークを付けると、ユーザーが新規ページを作成するときにこのページを参照できるようになります。
  14. ページのタイプとして、以下のいずれかを選択する。
    標準ポータル・レイアウト
    このオプションは、ポータルによって事前定義されているレイアウトを使用してページを作成する場合に選択します。
    静的レイアウト
    このオプションは、マークアップ・ファイルを使用してページ・レイアウトを作成する場合に選択します。
  15. 「ページ・キャッシュ・オプション」の場合は、以下のいずれかを選択する。
    キャッシュ有効範囲
    ページが複数のユーザー間で共用されている場合には、「ユーザー間の共用キャッシュ」を選択すると、最良のパフォーマンスを得ることができます。
    キャッシュの有効期限
    これは、キャッシュが使用される期間を秒単位で設定するのに使用するオプションです。「キャッシュは有効期限なし」を選択すると、コンテンツは常にキャッシュから取得されます。
    キャッシュ・アクセス制御
    デフォルトでは、ポータルは、認証ページの共用キャッシュを許可していません。 「キャッシュのアクセス制御を無視」にチェックマークを付けると、この動作を無効にします。ただし、悪意がある可能性のある匿名ユーザーにもページから保護されたコンテンツにアクセスすることを許可してしまう場合があります。
  16. 「OK」をクリックして新規ページのこれらの設定を保管し、新規コンテンツを追加する。新規ページを作成せずに 「ページの管理」に戻るには、「キャンセル」をクリックします。

共用ページの作成

ページの管理ポートレットを使用して、元のページが共用されるようにセットアップします。

このタスクについて

手順

  1. アドミニストレーターとしてポータルにログインする。
  2. 「管理」をクリックする。
  3. ナビゲーション・ツリーで、「ポータル・ユーザー・インターフェース」 をクリックし、次に「ページの管理」をクリックする。 現在選択しているノードに属しているノードが表示されます。
  4. ページの管理ポートレットを開く。
  5. 参照する元のページを見つける。
  6. 「ページ・プロパティーの編集」アイコンをクリックする。
  7. 「ページ・プロパティー」フィールドを展開する。
  8. 「他のページがこのページのコンテンツを共用できるようにする」が選択されていることを確認する。
  9. 「OK」をクリックする。

派生ページの作成

ページが既存ページを参照するように設定できるのは、ページ作成時のみです。

始める前に

このタスクについて

ルート・ページに作成されたワイヤーは、ルート・ページの参照によって作成した 派生ページには適用されません。そのようなページは元のページの コンテンツを継承しますが、継承関係はワイヤーには適用されません。 派生ページのワイヤーは明示的に作成する必要があります。派生ページを作成し、管理するには、以下のステップを実行してください。

手順

  1. 「ページの管理」ポートレットを使用してページを作成するときは、 「ページ・タイプ」セクションを展開する。
  2. 「ページ・レイアウト・プロパティーの設定」をクリックする。
  3. 「共用ページからコンテンツを使用するページ」を選択する。 ポータルに「他のページがこのページのコンテンツを共用できるようにする」が使用可能になっている別のページがある場合にのみ、このオプションが表示されます。
  4. ドロップダウン・リストから親ページを選択し、「OK」をクリックする。
  5. 他のページ・プロパティーの設定が終了したら、「OK」をクリックする。

ページ・テンプレートの作成

簡単にページを作成できるようにするため、新しいページの作成時にテンプレートとして使用できる事前構成済みのページを定義します。

このタスクについて

テンプレート・ページの構成はポータル・ページと同様に行うことができ、事前構成したポートレットを追加できます。テンプレートから新しいページを作成する場合、 常にページ・レイアウト、ポートレット、およびポートレットの構成が、テンプレートから新しいページにコピーされます。
重要: テンプレートから新しいページを作成する場合、ページの作成に使用したテンプレート・ページへの参照は保持されません。したがって、テンプレートからページを作成した後で、 そのテンプレート・ページに変更を加えても、それらのすべての変更は既存のどのページにも伝搬されません。

手順

  1. 「管理」 > 「ページの管理」とクリックする。
  2. 「コンテンツ・ルート」 > 「管理」 > 「WebSphere Portal」 > 「ポータル・ユーザー・インターフェース」 > 「ページ・テンプレート」をクリックする。
    注: 仮想ポータルは、デフォルトで「ページ・テンプレート 」ラベルを含みません。ただし、ラベルを手動で追加することはできます。 その場合は、必ず wps.content.template.root の固有の名前をラベルに付けてください。
  3. 「新規ページ (New Page)」または「新規ページ (New Page from)」をクリックして、テンプレートとして使用するページを作成する。
    • 「新規ページ (New Page)」は、標準のポータル・ページを作成します。 標準ポータル・ページの場合と同様に、ページのタイトルおよび他の特性を指定します。
    • 「新規ページ (New Page from)」は、Web コンテンツ・ページを作成するか、テンプレートから標準ページを作成します。 ページのタイトルおよび他の特性を指定します。 Web コンテンツ・ページのテンプレートを作成する場合、表示するコンテンツを Web コンテンツ・ライブラリーから選択します。標準ポータル・ページのテンプレートを 別のテンプレートから作成する場合、既存のテンプレートを選択して新しいテンプレートに使用します。
  4. 新しいテンプレートを保存する。
  5. 新しいページ・テンプレートの「ページ・レイアウトの編集」アイコン (小さな鉛筆) をクリックする。
  6. デフォルトでページに表示するポートレットを追加して構成する。
  7. 変更内容を保管する。

ページ・テンプレートを使用したページの作成

ページ・テンプレートを使用して、新しいページを迅速に作成します。ページ・テンプレートから作成されたページは、事前構成されたポートレットおよび設定が含まれています。

手順

  1. 「管理」 > 「ページの管理」とクリックする。
  2. 「コンテンツ・ルート」 をクリックする。
  3. 「ホーム」をクリックするか、新しいページを作成する ポータルの別のセクションにナビゲートする。
  4. 「新規ページ」をクリックする。
  5. 新規ページのタイトルを「タイトル」に入力する。 これは、デフォルト・ロケールのタイトルです。
  6. 「分かりやすい URL」に固有の URL を入力する。 これにより、覚えやすく共用しやすい、ページのカスタム・アドレスが作成されます。
    注: URL マッピングを作成するとき、またはページを作成あるいは変更するときは、URL マッピングとフレンドリー URL とがポータル内で一致したり、部分的に重複したり、相互に干渉したりしないようにしてください。 例えば、homeibmibm.com などのストリングを使用したり、ポータル内で URL マッピングまたはフレンドリー URL として既に使用されているストリングは使用しないようにします。 そうでないと、ときにはエラー・メッセージなしで、無限のブラウザー・リダイレクト・ループが発生することがあります。 そのようなストリングを判別するには、XML 構成インターフェースを使用してポータルからのエクスポートを作成し、 エクスポートされた XML 結果の出力ファイルをスキャンして、URL マッピングまたはフレンドリー URL として使用するストリングを見つけます。
  7. 「このページを自分専用のページにする」選択して、他のユーザーによるページへのアクセスを制限する。
  8. 「ページ・テンプレート」セクションで、 使用可能なテンプレートのリストから新しいページに使用するページ・テンプレートを選択する。
    注: 公開ページを作成する場合は、使用するテンプレート・ページに対して少なくとも編集者役割のアクセス権限を持っている必要があります。
  9. 「Web コンテンツ」をスキップする。
  10. 「OK」をクリックして、新しいページを作成する。

ページ・ビルダーでの作業

ページの作成およびカスタマイズは以前よりも簡単になりました。 ページの作成は、「ページ・ビルダー」テーマを使用してシングルクリックで行うことができます。ユーザーは、ポータル・ページ・ビルダー・フィーチャーを使用して、ページの作成やカスタマイズ、およびチームメイトやコミュニティー・メンバーとのページの共用を素早く簡単に行うことができます。 コンテンツ・カタログで使用可能なさまざまなソース (ポータル・ポートレットおよび共用ページなど) を使用して、これらのページにコンテンツを追加できます。 構成できる他のカスタム・コンテンツ・ソースには、IBM Mashup Center のフィード、ウィジェット、およびページと、IBM Lotus Connections のアクティビティー、コミュニティー、およびソーシャル・ブックマークが含まれます。

このタスクについて

以前のポータルのバージョンでは、ページのカスタマイズ処理には、コンテンツの追加、ページのレイアウトや外観の変更など、通常のタスクを実行する場合にも、多くのページおよびポートレットが関係する複数のユーザー処置が含まれていました。 ページ・ビルダーでは、こうした機能をユーザーのオーサリング・エクスペリエンスの重要な課題として、散在するページ上で別の画面を通して行うのではなく、そのページ自体の上にある編集ツールを使用することでページを変更する処理を簡素化しています。 これらの新規のカスタマイズ・フィーチャーを使用可能にする場合、ユーザーは、「検索」フィールドの横にある「編集モード (Edit mode)」アイコンをクリックして編集モードに移行することができます。

ページ・ビルダー」テーマを含むページ上では、表示中のタブから直接にページの作成や、ページのレイアウトの変更ができます。 コンテンツを追加したり、現行ページのスタイルおよびレイアウトを変更したりするには、「カスタマイズ」ボタンを使用します。 事前定義されたスタイルおよびレイアウトのリストから選択します。他のオプションについては、「追加アクション」ボタンを使用します。 ドラッグ・アンド・ドロップを使用して、ナビゲーションの中でコンテンツまたはページを移動することができます。 さらに、作成またはカスタマイズしたページを他のユーザーと共用することもできます。 新規ページを作成するには、ナビゲーションで「新規ページ」リンクをクリックします。

ページ・ビルダー・フィーチャーの主な利点には、以下のものがあります。
  • WYSIWYG スタイルのページ編集ツール
  • Web 2.0 への対応
  • サーバー要求の減少によるパフォーマンスの向上
  • エンド・ユーザー指向のインターフェース。
ページ・ビルダーは「ページ・ビルダー」テーマですぐに使用可能です。これを独自のカスタム・ポータル・テーマに追加することもできます。コンポーネントが、直接に取り込み可能なモジュラー・ウィジェットであるためです。

ポータルおよびマッシュアップ・ページを作成し、ポートレット、フィード、ウィジェット、および共同作業用のソーシャル・エレメント (アクティビティー、コミュニティー、ソーシャル・ブックマークなど) を追加した後で、単純なテーマを適用することによってページのスタイルを変更できます。 ページのレイアウトを変更するには、テンプレートを使用するか、あるいはページ内でコンポーネントをドラッグ・アンド・ドロップします。 ページを共用するユーザーおよびグループを検索して、ページの表示および編集を行うためのユーザー・アクセスを割り当てることもできます。 ページを共用しているユーザーは、ページ・タブの下にあるプレース・バーの「共用」メニューを使用してページにアクセスできます。 共用ページのユーザーは、ページの分かりやすい URL にブックマーク (ドッグイア) を付けることができます。 ポータル・コンテンツを管理するには、共用ページとそれに含まれるポートレット、フィード、ウィジェット、およびソーシャル・コンポーネントを管理します。

ページ・ビルダーと従来型のページ管理のどちらのページ処理方式を自分のサイトで使用するかを決めます。
  • ページ・ビルダー: コンテンツ・カタログから追加するポートレット、フィード、 およびソーシャル・コンポーネントを含む、ポータル・ページを作成するには、ページ・ビルダーを使用します。 ウィジェットを含むマッシュアップ・ページを作成することもできます。 作成したページは、以下のアクションでカスタマイズできます。
    • コンテンツの追加
    • スタイルの変更
    • レイアウトの変更
    これらのタスクを実行するには、「カスタマイズ」ボタンをクリックします。
  • ポータルの管理: 従来型のページ管理およびカスタマイズでは、ポータル管理から使用可能な以下の管理ポートレットを使用できます。
    • ページの管理
    • テーマとスキン
    • テーマ・カスタマイザー
    • サイト管理
注:ページ・ビルダー」テーマは、サイド・ナビゲーションを使用しません。したがって、「ページ・ビルダー」テーマを使用するポータルのユーザーが、例えば SideNavOnly を選択してテーマのスタイルをサイド・ナビゲーションのみに変えるなどして、トップ・ナビゲーションを非表示にすると、ナビゲーションは表示されなくなります。

トップレベル・ページ・タブの作成

子ページを作成する前に、トップレベル・ページ・タブを作成する必要があります。ページ・タイトルおよびページのプライバシー・モードだけをこのダイアログからカスタマイズできます。

始める前に

このタスクについて

このためには、 以下のようにします。

手順

  1. 既存のページ・タブの横にある「新規ページ」リンクをクリックして新規のトップレベル・ページ・タブを作成します。
  2. 表示される入力ボックスにタイトルを入力します。
  3. Enter キーを押すか、あるいは入力ボックスをクリックしてタブを作成します。

次のタスク

タブの作成後に、子ページを作成できます。

ページ・タブの移動

ページ・タブを他の場所に移動できます。

始める前に

このタスクについて

このためには、 以下のようにします。

手順

  1. ページ・タブをクリックし、その横にある点線で表示されたハンドルを使ってドラッグします。
  2. タブは他のタブの間の希望する位置にドラッグすることもできますし、別のタブの上まで移動してその子を表示してから、メニューの中にタブをドラッグして、これを子として設定することもできます。

子ページの作成

既存のページの下に新しい子ページを作成できます。 ページ・タイトルおよびページのプライバシー・モードだけをこのダイアログからカスタマイズできます。

始める前に

このタスクについて

これを行うには、「タブ・メニュー - ページ・ビルダー」テーマで「追加アクション」メニューの「新規子ページ」オプションを使用します。

次のタスク

ページの作成後に、以下のアクションを実行できます。
  • コンテンツの追加
  • 外観の変更
  • レイアウトの変更
  • ページの編集
  • ページの共用
  • 公開ページ

子ページの移動

子ページを他の場所に移動できます。

始める前に

このタスクについて

このためには、 以下のようにします。

手順

  1. ページをクリックし、その横にある点線で表示されたハンドルを使ってドラッグします。
  2. 子ページを、同位のページの間、または別タブの子ページの間の希望する場所、またはトップ・タブ・レベルにドラッグします。

コンテンツの追加

コンテンツをページに追加するには、コンテンツ・カタログにリストされているコンテンツ・ソース (すべてのソース、 IBM Mashup Center、またはポータル) からポータル・ページ用のポートレットまたはマッシュアップ・ページ用のウィジェットを選択します。

始める前に

このタスクについて

コンテンツを追加するには、以下のようにします。

手順

  1. ツールバーの「カスタマイズ」ボタンをクリックして、コンテンツ・カタログを開きます。
  2. 横にあるメニューからカテゴリーを選択します。
  3. 上部隅近くにある入力ボックスにスペース区切りの検索ストリングを入力して、表示される結果をフィルターします。 ポータルは、スペースで区切られた検索語を AND で結合します。 例: login search で検索すると、結果リストには、 タイトルまたは記述に login および search両方を含むすべての用語が示されます。 検索ストリングを OR で結合して結果をフィルターすることはできません。
    注: 左記のカテゴリーの一部は、基礎となるタグ付けフィードが検索可能でないために検索できません。
  4. 検索結果の下にある「前へ」および「次へ」リンクまたは「次に指定するページへ ___」入力を使用してコンテンツのページ間で移動します。
  5. 特定のコンテンツに関する情報を表示するには、タイトルをクリックして、項目を詳述するポップアップ・ダイアログを表示します。
  6. 詳細ダイアログで「ページに追加」ボタンをクリックするか、 結果リストのタイトルの横にあるプラス (+) アイコンをクリックして、ドラッグ・アンド・ドロップにより項目をページに追加します。 項目に複数のレンダラーがある場合、ダイアログが選択項目のドロップダウン・ボックスとともにポップアップ表示されます。選択項目を選択してコンテンツをレンダリングし、「追加」ボタンをクリックします。 プレースホルダーがページに表示されます。 これには新しいコンテンツのタイトルが含まれます。
  7. 新しく追加された項目を保存して表示するには、「保存」ボタンをクリックします。 これにより、ページ領域が同期され、すべてのコンテンツを表示できるようになります。
    注: コンテンツを追加してからページを保存すると、ページに追加された新規コンテンツをサーバー・サイドのページにレンダリングするために全ページが最新表示されます。
  8. 必要に応じて、コンテンツをドラッグ・アンド・ドロップし、ページを再配列します。

次のタスク

コンテンツ・ソース

複数のカテゴリーからページにコンテンツを追加することができます。

これには、「カスタマイズ」ボタンをクリックします。これにより、カスタマイズ・シェルフが開きます。タブ「コンテンツの追加」をクリックします。コンテンツ・カタログには、ページに追加できる複数のソースのコンテンツ・カテゴリーが表示されます。

「コンテンツの追加」タブで、ご使用の環境と構成に応じて以下にリストされているカテゴリーを選択できます。
  • すぐに使用可能な以下のカテゴリーを選択できます。
    • 新規。このオプションは、ページに新規フィードを追加するために使用します。
    • ポートレット。このオプションは、ページに新規ポートレットを追加するために使用します。
  • Web Content Management がある場合、「新規」カテゴリーの下からブログおよび Wiki を追加することもできます。
  • カスタム・コンテンツ: 独自のカスタム・コンテンツ・ソースを追加および構成して、それらをシェルフの「コンテンツの追加」の部分に追加できます。このようにして、カスタム・コンテンツ・ソースを検索してそのコンテンツをページに追加し、カスタム・ポートレットまたはウィジェットを介してレンダリングできます。

カスタム・コンテンツ・ソースの追加

独自のカスタム・コンテンツを追加することもできます。

始める前に
これを行うには、以下に示されているステップを実行してください。
注: 以下の指示は、管理者を対象としたものであり、javascript、json および dojo に関する基本的な知識を必要とします。
手順
  1. ページに追加できる項目が入っている REST フィードを含むコンテンツ・ソースを選択します。
  2. Dojo Read API に準拠したソースのデータ・ストアを作成します。ソースが JSON 形式である場合、dojo.data.ItemFileReadStore または com.ibm.data.JsonStore を拡張します。
  3. データ・ストアを拡張するには、com.ibm.portal.data.CatalogMixin をサブクラス化します。 これには、「コンテンツの追加」ウィジェットですべてのソースに対して一様な方法で検索およびアクセスを行えるようにする、mapItem および prepareQuery 関数が含まれています。 mapItem および prepareQuery 関数について詳しくは、以下の説明を参照してください。
    mapItem
    指定されたデータ・ストア項目のパラメーターを含むマップを戻します。 以下のマップ・キーは単一ストリングです。すなわち、labeldescriptionratingurlthumbnail、および id です。マップ・キー tags は、ストリングの配列です。すべてのデータ・ストアが同じキーを持つ項目マップを作成すると、ウィジェットはすべてのソースで一様な方法で情報にアクセスできるようになります。 データ・ストアに、いずれかのキーの適切な属性が含まれていない場合、マップ・エントリーを省略するか、あるいは静的デフォルト値を置換することができます。 ステップ 4 で必要なカスタム属性をマップに追加することもできます。
    例: 以下のデータ・ストア項目には、titlesummaryrating、および identifier 属性があります。
    mapItem: function(/*DatastoreItem*/ item) {
            // does not include the "tags", "thumbnail", and "url" keys
    		 var map = {};
    		 map["label"] = this.getValue(item, "title", "untitled");
    		 map["description"] = this.getValue(item, "summary", "");
    		 map["rating"] = this.getValue(item, "rating", 0);
    		 map["id"] = this.getValue(item, "identifier", "");
    		 return map;
         }
    prepareQuery
    dojo.data.api.Read.fetch で使用される keywordArgs オブジェクトを変更するための拡張ポイントを提供し、フィード URL を作成する場合に照会パラメーターを使用できるようにします。 これは、keywordArgs.query がオブジェクト・マップに対して正規化されてから、URL を作成するためのその他の処理が実行されるまでの間に呼び出されます。 照会パラメーターにあるその他の項目は、(?|&)key1=value1&key2=value2&key3=value3=value3 の形式でフィード URL に付加されます。
    keywordsArgs マップの他の部分を取り出して、フィードのバックエンド実装に依存したプロパティーを照会オブジェクトに追加します。 URL の一部ではない keywordArgs.query プロパティーは削除する必要があります。
    例: フィード URL に searchTermsstartIndex、および count パラメーターが含まれている場合に prepareQuery 関数がどのように使用されるかを調べてください。
    prepareQuery: function(/*Object*/ keywordArgs) {
            if(keywordArgs.query.keywords){
    		     // searchTerms is a comma separated list of search parameters
    		     keywordArgs.query.searchTerms = keywordArgs.query.keywords.join(",");
    		     delete keywordArgs.query.keywords;
            }
            if(keywordArgs.count){
    		     keywordArgs.query.count = keywordArgs.count;
    		     if(keywordArgs.start ==  null){
    		 		     keywordArgs.start = 0;
    		     }
    		     keywordArgs.query.startIndex = keywordArgs.start;
            }
         }
    この例では、keywordArgs.query.keywords の値が ["term1","term2","term3"]keywordArgs.count の値が 12keywordArgs.start の値が 3 の場合、作成される URL は次のようになります。http://baseURL?searchTerms=term1,term2,term3&count=12&startIndex=3
  4. データ・ストアからのコンテンツをレンダリングするために使用されるものを判別します。 レンダラーごとに、mapItem 関数によって戻される項目マップを com.ibm.portal.data.CatalogMixin から受け取り、レンダラーがコンテンツを表示するために使用できる優先マップを戻す、簡単な関数を作成します。 例えば、この関数はフィード・リーダー・ポートレット用の優先マップを作成します。
    feedReader: function(/*Object*/itemMap){
             var map = {};
             map["FeedReaderPortlet_feedURL"] = itemMap.url.replace(/&/g,"&"); 
             map["FeedReaderPortlet_feedName"] = itemMap.label; 
             map["FeedReaderPortlet_feedActionPane"] = "false";           
             return map;      }
    これらの関数は、dojo.getObject(String) 関数を使用して「コンテンツの追加」ウィジェットによりアクセスされます。 これらの関数がテーマ内で使用可能であることを確認する必要があります。 レンダラーを指定しなかった場合、ソースの各項目はレンダラー自体であると見なされ、直接ページに追加されます。 こうしたコンテンツ・タイプの例には、「コンテンツの追加」ウィジェットで構成されるすぐに使用可能なポートレットがあります。
  5. 新規ソースを「コンテンツの追加」ウィジェットに登録するには、 WebDAV 内の dav/fs-type1/themes/PageBuilder2/system/ にある addContent.json および addContent_wcm.json ファイルを編集します。 ファイルのカテゴリー配列にこの JSON を追加します。
    {
          "label":"your_category_name",
    "searchStr":"Search your_category_name","datastore":"your.Datastore.Name",
    "url":"base_url_to_your_source_REST_service",
    "renderers":[{"id":"renderer_unique_id","label":"renderer_name",
    "fcn":"renderer.prefMapper.fcn.name"},
    {"id":"another_renderer_unique_id","label":"renderer_name",
          "fcn":"another.renderer.prefMapper.fcn.name"}]
    }
    "myShelfCategoryTag" でタグ付けされたすべてのポートレット定義を含むカテゴリーの例:
    {
    "label":"My category with tags",
    "searchStr":"Search my category with tags",
    "datastore":"com.ibm.pb.data.TaggedItemStore",
    "url":ibmPortalConfig.contentHandlerURI + "rm/empty?tmparam=tm%3aname%3amyShelfCategoryTag",
    "renderers":[]
    }
    注: カテゴリーのラベルおよび検索ストリングは、2 つの別個の属性です。 ラベルは、シェルフのサイドにあるカテゴリーのリスト内に表示されます。 検索ストリングは検索ボックス内にテキストとして表示されます。 「Search」 とラベルとを連結しただけではすべての言語で正常に機能しないので、 それらは 2 つの別個のストリングとなります。 翻訳の問題が生じない場合は、searchStr 属性をカテゴリー定義から除外できます。 この場合、連結が使用されます。
  6. json ファイルで提供される categorysource、および renderer 表示ストリングを各国語化するかどうかを決定します。 これを行う場合、json ファイルは localizationPackageName および localizationBundleName を以下のように指定する必要があります。
    {
    	localizationPackageName:'bundle object notation', 
          localizationBundleName:'bundle name',
        	categories:[category array]
    	}
    これらは、dojo.i18n.getLocalization("bundle object notation", "bundle name") でバンドルを作成してローカライズ・ストリングを提供するために、dojo.i18n によって使用されます。 json ファイルに既にバンドルが提供されている場合、必要なキーおよび値を追加します。 それ以外の場合は、新規バンドルを作成します。新規キーを使用するには、表示ストリングの代わりに json ファイルでそれらのキーを指定する必要があります。 ウィジェットは、キーごとにバンドルから値を自動的に取り出します。 以下は、完成した json ファイルの例です。キーが強調表示されています。
      {
    localizationPackageName:"com.ibm.bundles", localizationBundleName:"Shelf",
    categories:[
    {
    "label":"new_createCategory",
    "searchStr":"shelf_searchCreate",
    "datastore":"com.ibm.data.JsonStore",
    "url":ibmCfg.themeConfig.themeRootURI+"/system/new.json",
    "renderers":[]
    },
    {
    "label":"shelf_all",
    "searchStr":"shelf_searchAll",
    "datastore":"com.ibm.portal.data.InstalledPortletStore",
    "url":ibmPortalConfig.contentHandlerURI + 
         "pdl/addable:oid:"+com.ibm.mashups.enabler.navigation.Factory.getNavigationModel().
         find(com.ibm.mashups.builder.model.Factory.getRuntimeModel().getCurrentPage()
         .getID()).start().getContent().start().getID()+"?rep=compact",
    "idPrefix":"pm:oid:",
    "renderers":[]
    },
    {
    "label":"My Category",
    "searchStr":"Search my Category",
    "datastore":"com.ibm.pb.data.TaggedItemStore",
    "url":ibmPortalConfig.contentHandlerURI + "rm/empty?tmparam=tm%3aname%3amyCategoryTag",
    "renderers":[]
    }
    ]
    }
  7. 新しいファイルを選択するには、ブラウザー・キャッシュを最新表示します。
  8. カスタム・ソースが追加されているかどうかを確認します。

他のカスタム・コンテンツの追加

ページにはカスタム・コンテンツだけでなく、他のコンテンツも追加することができます。

始める前に
例えば、適切なカテゴリーを使用して Web Content Management コンテンツまたはフィード・リーダーをページに追加することができます。これらをページに追加する場合、その前に余分の作業を行う必要があります。 これを行うには、以下に示されているステップを実行してください。
注: 以下の指示は、管理者を対象としたものであり、javascript、json および dojo に関する基本的な知識を必要とします。
手順
  1. カスタム・ソースを追加するための手順に説明されているように、新規カテゴリーを json ファイルに追加します。 com.ibm.data.JsonStore データ・ストアを使用し、レンダラーのプロキシーおよび配列を省略します。 URL は、ストアで項目を提供する別の json ファイルを指していなければなりません。 エントリーの例を以下に示します。
    {
    "label":"your_Category_Name",
    "searchStr":"Search your_Category_Name",
    "datastore":"com.ibm.data.JsonStore",
    "url":pathToTheJsonFileWithTheDatastoreItems.json",
    "renderers":[]
    }
  2. json ファイルを作成して、「コンテンツの追加」ウィジェットの新規カテゴリーの下に表示される項目を保持します。ファイル内の json オブジェクトには、項目配列、およびオプションで言語サポート・バンドルに必要なストリングを含める必要があります。 例:
    { localizationPackageName:'com.ibm.bundles', localizationBundleName:'Customize', 
         identifier:'label', items: [
    {'label':'wcm_blog',context:'/Blog/Home',
         'takeover':'com.ibm.customize.AddContentController.newWCM',
         'description':'new_wcm_blogDescription'},
    {'label':'wcm_blogLibrary',context:'/Blog/Central',
         'takeover':'com.ibm.customize.AddContentController.newWCM',
         'description':'new_wcm_blogLibraryDescription'},
    {'label':'wcm_wiki',context:'/Wiki Central/Home',
         'takeover':'com.ibm.customize.AddContentController.newWCM',
         'description':'new_wcm_wikiDescription'},
    {'label':'new_feed',
         'takeover':'com.ibm.customize.AddContentController.newFeed',
         'description':'new_wcm_feedDescription'}
    ] 
    }
    上の例のすべての項目には、「コンテンツの追加」ウィジェットで表示できるラベルと説明があります。 上述の Web Content Management 項目で使用される "context" 属性など、他の必要な属性を項目オブジェクトに追加することもできます。 各項目には "takeover" 属性も必要です。これは関数の名前をドット表記したものです。 この関数は、ユーザーが項目をクリックして追加したときに呼び出されます。この関数は、オブジェクトである 1 つの引数を指定して呼び出されます。thisObject.hub はデータ・ストアへの参照で、thisObject.item はデータ・ストア内の項目への参照です。 ページにコンテンツを追加するための通常の機能は実行されません。

ページ・スタイルの変更

事前定義されたテーマのリストからスタイルを選択することによって、ページの外観を変更します。 テーマを選択すると、ページ上にそのプレビューが表示されます。 選択可能なページ・テーマのリストにカスタム・スタイルを追加できます。

このタスクについて

ページの外観を変更するには、以下のようにします。

手順

  1. ツールバーの「カスタマイズ」ボタンをクリックして、コンテンツ・カタログを開きます。
  2. 「スタイルの変更」タブにナビゲートします。
  3. 横にあるメニューからカテゴリーを選択します。
  4. 上部隅近くにある入力ボックスにスペース区切りの検索語を入力して、表示される結果をフィルターします。
  5. 検索結果の下にある「前へ」および「次へ」リンクまたは「次に指定するページへ ___」入力を使用してコンテンツのページ間で移動します。
  6. スタイルをプレビューするには、そのスタイルをクリックします。
  7. スタイルの変更をサーバーにコミットするには、「保存」ボタンをクリックします。
  8. 「カスタマイズ」ボタンをクリックしてシェルフを閉じるか、または「編集モード」トグル・ボタンをクリックして表示モードに戻ります。

次のタスク

注: デフォルトのポータル・インストールで使用可能なデフォルトのスタイルは、ページをリセットして、カスタム・スタイルシートを適用しないようにします。 そのため、デフォルトのスタイルが適用されたページは、その上位のページに適用されているスタイルだけを継承します。

カスタム・スタイルの追加

独自のカスタム・スタイルを追加することもできます。

始める前に
このためには、 以下のようにします。
このタスクについて
手順
  1. テーマの代替カスケーディング・スタイルシート (.css) ファイルを作成します。 ポータルが WebDAV の dav/fs-type1/themes/PageBuilder2/css/gold で提供するスタイルをガイドとして使用してください。
  2. WebDAV の dav/fs-type1/themes/PageBuilder2/css/ にフォルダーを追加します。
  3. 新規スタイルの CSS およびリソースをここに保存します。
  4. WebDAV の dav/fs-type1/themes/PageBuilder2/system/styles.json にあるファイルを開きます。
  5. 以下の形式で items 配列にエントリーを追加することによって、スタイルを登録します。
    {'label':'display_name_for_the_style',
         'id':'path_to_the_stylesheet_relative_to_theme_folder_in_webdav',
         'thumbnail':'path_to_the_thumbnail_for_the_style',
         'help':'short_description_for_the_style'} 
    例:
    {'label':'change_style_gold','id':'gold.css','url':'css/gold/gold.css',
    'thumbnail':ibmCfg.themeConfig.themeRootURI+'/images/changeStyle/goldThumb.gif',
    'help':''}

    表示名は「カスタマイズ」シェルフに表示されます。スタイルシートの名前はその ID として使用されます。 パスは WebDAV 内のフォルダーに対する相対パスとする必要があります。 ファイル styles.json の json オブジェクトには、スタイル表示ストリング localizationPackageName および localizationBundleName をグローバル化するために使用される 2 つの属性が含まれます。 これらは、dojo.i18n.getLocalization("localizationPackageName","localizationBundleName") でバンドルを作成してローカライズ・ストリングを提供するために、dojo.i18n によって使用されます。 新規スタイルの表示名をグローバル化するよう選択する場合は、新規キーをバンドルに追加し、json のラベル値をキー名に置換します。 カスタマイズ・シェルフは、このキーを使用してバンドル内の表示名を自動的に検索します。

    上記のステップにより、「カスタマイズ」シェルフの「スタイルの変更」の下のデフォルトの「すべて」カテゴリーに新規スタイルが追加されます。

  6. 新規カテゴリーを追加するには、WebDAV の dav/fs-type1/themes/PageBuilder2/system/changeStyle.json にあるファイルを編集し、 json オブジェクトのカテゴリー配列に別の項目を追加します。 例:
          {
    "label":"My new category",
    "searchStr":"Search my new category",
    "datastore":"com.ibm.data.JsonStore",
    "url":”path_to_your_styles_json_file"
    }
    ここで、属性 url は、新規カテゴリーのスタイル・エントリーが入っている json ファイルへのパスです。 この json ファイルを、WebDAV の dav/fs-type1/themes/PageBuilder2/system/styles.json にあるファイルに従ってモデル化します。
  7. カスタム・スタイルが「カスタマイズ」領域に追加されたことを確認します。

ページ・レイアウトの変更

ページ・レイアウトは、事前定義された形式のリストから選択できます。. ポートレットおよびウィジェットは、新規レイアウトに自動的に配置されます。 選択可能なページ形式のリストに、自分で定義したカスタム・レイアウトを追加できます。ページのレイアウトを調整するには、ドラッグ・アンド・ドロップを使用します。

このタスクについて

注: ページ・ビルダーはロックされたコンテナーをサポートしません。
ページのレイアウトを変更するには、以下のようにします。

手順

  1. ツールバーの「カスタマイズ」ボタンをクリックして、コンテンツ・カタログを開きます。
  2. 「レイアウトの変更」タブにナビゲートします。
  3. 横にあるメニューからカテゴリーを選択します。
  4. 上部隅近くにある入力ボックスにスペース区切りの検索語を入力して、表示される結果をフィルターします。
  5. 検索結果の下にある「前へ」および「次へ」リンクまたは「次に指定するページへ ___」入力を使用してコンテンツのページ間で移動します。
  6. レイアウトを選択するには、そのレイアウトをクリックします。 この時点では、ブラウザーに何の変化も生じません。
  7. レイアウトの変更をサーバーにコミットするには、「保存」ボタンをクリックします。 ページは自動的に最新表示され、レイアウトの変更がレンダリングされます。

カスタム・レイアウトの追加

独自のカスタム・レイアウトを追加することもできます。

始める前に
このためには、 以下のようにします。
手順
  1. レイアウト・リソースのための新しいフォルダーを作成します。 各レイアウトには、アイコン、layout.html 静的ページ・レイアウト・テンプレート、 metadata.properties ファイル、およびサポートされる言語ごとのローカライズ・プロパティー・ファイルがあります。 HTML テンプレートは、ポータル静的ページのフォーマットに従います。 これについて詳しくは、『>ポータルの静的コンテンツの作成』に関するトピックを参照してください。 ファイル metadata.properties は、サムネールの WebDAV ファイル・システムに対する相対パスのプロパティーを保持します。 dav/fs-type1/layout-templates にある WebDAV のその他のレイアウトをガイドとして使用してください。 このファイルのフォルダーを WebDAV に追加することにより、 「カスタマイズ」シェルフの「レイアウトの変更」の下のデフォルトの「すべて」カテゴリーに新規レイアウトが追加されます。
  2. ブラウザー・キャッシュをリフレッシュする。
  3. カスタム・レイアウトが正常に「カスタマイズ」領域に追加されたことを確認します。

ページの共用

ユーザーは他のユーザーとページを共用できます。これらのユーザーは、共用ページを表示する前にそれらを受け入れる必要があります。

このタスクについて

注:

手順

  • 『ポータルでのマッシュアップ統合の使用可能化』に関するトピックの指示を実行して、マッシュアップ統合をデプロイします。
  • マッシュアップ統合ではなく、ページ共用を使用可能にする場合は、以下の構成タスクを実行します。
    ConfigEngine.sh|bat deploy-portal-page-sharing 
                        -DWasPassword=was_password
                        -DPortalAdminPwd=portal_password
    仮想ポータルでは、仮想ポータルのコンテキストを指定するパラメーター -DVirtualPortalContext=vp_context_root を追加します。
    ConfigEngine.sh|bat deploy-portal-page-sharing 
                        -DWasPassword=was_password
                        -DPortalAdminPwd=portal_password
                        -DVirtualPortalContext=vp_context_root
  • ページを共用するユーザーのページ階層内の共用ページを受け入れたユーザーには、 共有先のユーザーが階層の上位にあるページを削除した後も、その受け入れたページが表示されることがあります。 これが該当するのは、階層内で共用ページの下の下位ページだけです。 直接共用されているページは、共用するユーザーがそれらのページを削除すると、予期するように他のユーザーには非表示になります。 例:
    1. ユーザー X はページ a のページ階層を、ページ b がページ a の下位になるように作成します。
    2. ユーザー X はページ b をユーザー Y と共用します。
    3. ユーザー Y がページ b を受け入れます。
    4. ユーザー X がページ a を削除します。
    5. 結果:
      • ユーザー X はページ a を削除したので、ページ b を含むすべての下位ページも削除されます。 その結果、ユーザー X にはページ b が表示されなくなります。
      • ただし、ユーザー Y にはページ b が表示されています。

共有ページ用にアクセス制御を構成する (必須)

例えばユーザーがページ・ビルダーまたは (パーソナル・ページとマッシュアップ・スペースのページの両方の) マッシュアップ統合で作業を行う場合など、共有機能の使用をユーザーに許可するには、管理者としてポータルにログインし、該当するアクセス制御設定を手動で設定する必要があります。 この構成は必須です。

始める前に
仮想ポータルの前提条件: 仮想ポータルでは、さらに下に示された手順により共有機能のアクセス制御を構成する前に、 仮想ポータル・アドミニストレーターが共有機能へのアクセス権限を割り当てることができるようにする必要があります。 これを行うには、以下のステップを実行します。
  1. 仮想ポータルにポータル・アドミニストレーターとしてログインする。
  2. 「管理」 > 「アクセス」 > 「リソースのアクセス権」 > 「ページ」を選択する。
  3. 「共用ページ」を検索し、共用ページの横にあるアイコン「アクセス権の割り当て」をクリックする。
  4. 「アドミニストレーター」役割の横にあるアイコン「役割の編集」をクリックする。
  5. 「追加」ボタンをクリックして、仮想ポータル・アドミニストレーターへのアクセス権限を割り当てる。
  6. 「OK」をクリックする。
このタスクについて
共有機能のアクセス制御を構成するには、以下のようにします。
手順
  1. 「管理」 > 「アクセス」 > 「リソースのアクセス権」を選択する。
  2. 「仮想リソース」を選択する。 この項目を見つけるには、リソース・タイプのリストをスクロールしなければならない場合があります。
  3. リソース「USER GROUPS」を検索し、その横にあるアイコン「アクセス権の割り当て」をクリックする。 この項目を見つけるには、リソース・タイプのリストをスクロールしなければならない場合があります。
  4. 「代行者」役割の横にあるアイコン「役割の編集」をクリックする。
  5. 「追加」ボタンをクリックする。
  6. 他のユーザー・グループにページへのアクセス権限を付与できるようにするユーザーまたはユーザー・グループに、チェック・マークを付ける。
  7. 「OK」をクリックします。
  8. 逆方向にナビゲートしてリソース・タイプ「仮想リソース」に戻る (例えば、ポートレットに表示されているパンくずリストの「仮想リソース」をクリックする)。
  9. リソース「USERS」を検索し、その横にあるアイコン「アクセス権の割り当て」をクリックする。 この項目を見つけるには、リソース・タイプのリストをスクロールしなければならない場合があります。
  10. 「代行者」役割の横にあるアイコン「役割の編集」をクリックする。
  11. 「追加」ボタンをクリックする。
  12. 他のユーザーにページへのアクセス権限を付与できるようにするユーザーまたはユーザー・グループに、チェック・マークを付ける。
  13. 「OK」をクリックします。
  14. 「管理」 > 「アクセス」 > 「リソースのアクセス権」 > 「ページ」を選択する。
  15. 「共用ページ」を検索し、共用ページの横にあるアイコン「アクセス権の割り当て」をクリックする。
  16. 「編集者」役割の横にあるアイコン「役割の編集」をクリックする。
  17. 「追加」ボタンをクリックして、ページの共有を可能にするすべてのユーザーにアクセス権限を割り当てる。
  18. 「OK」をクリックする。

他のユーザーとのページの共用

作成またはカスタマイズしたページを他のユーザーと共用することができます。 これは、社内の個々のユーザーと、ユーザーのグループの両方で機能します。

このタスクについて
注: 共用できるのは、プライベート・ページのみです。
ページの共用を許されたユーザーは、そのページを開くときに、それを自分のナビゲーションに追加するかどうかを選択できます。 それらのユーザーにビューまたは編集アクセス権限のどちらかを割り当てることができます。
  • ビュー・アクセス権限: ユーザーにビュー・アクセス権限を付与すると、ユーザーはページの表示のみを行うことができます。
  • 編集アクセス権限: ユーザーに編集アクセス権限を付与すると、ユーザーはポータルの編集者役割アクセス権を使用して共用ページを編集できます。 詳しくは、『役割』に関するトピックを参照してください。 ページの所有者を含む、そのページを共用しているすべてのユーザーが、編集者の加えた変更を参照できます。 しかし、編集アクセス権限を受けたユーザーが、他のユーザーにページの共用を許すことはできません。ページの所有者だけが、ページの共用を許すことができます。
注:
  1. ページ・エディターまたは所有者が最初にページを共用すると、 他のユーザーはそのページを自分のナビゲーションに追加することによって、そのページに関連した現行タイトル、説明、 およびメタデータを使用できるようになります。 ただし、所有者がこの情報に対して行う後続の変更については、他のユーザーは使用できません。 共用ページを表示するユーザーは、共用ページを自分のビューで表示する際にタイトルおよび説明を制御できます。
  2. ここに示される記述は、非プライベート・ページに適用されます。 ユーザーが非プライベート・マッシュアップ・ページを共用すると、 ページの共用先のユーザーはそのページを受け入れなくても自分のナビゲーション内にページを表示できます。 プライベート・ページおよび非プライベート・ページについて詳しくは、『コンテンツの共用』に関するトピックを参照してください。
テーマおよび共用ページ: ページを共用すると、 そのページのテーマは、デフォルト・ポータル・テーマまたは親テーマから派生しないで、明示的に設定されます。 後でデフォルト・ポータル・テーマまたは親テーマを変更しても、 共用ページに使用されるテーマは、ページが最初に共用されたときと同じテーマのままとなります。 以前のバージョンからマイグレーションするときにデフォルト・ポータル・テーマを変更した場合も、同様です。 共用ページのテーマは、新しいテーマが反映されず、同じテーマが保持されます。

ページを他のユーザーと共用するには、以下のステップを実行します。

手順
  1. 共用するページ上で、「共用」メニューを開きます。
  2. 「共用ページ」リンクをクリックして、アクセス権ダイアログを開きます。
  3. 「このページの共用」を選択します。
  4. アクセス権ダイアログ・ウィンドウで、以下のようにユーザーまたはグループを検索します。
    • ユーザーとグループのどちらを検索するかを切り替えるには、ドロップダウン・メニューをクリックして検索タイプを選択します。
    • 検索を実行するには、「検索」フィールドに検索ストリングを入力し、「検索」ボタンをクリックします。
    検索が完了すると、検索フィールドの下に検索結果リストが表示されます。 ページを上下に移動するには、「上へ (Up)」および「下へ (Down)」矢印をクリックします。
  5. 結果リストのユーザーまたはグループを共用ページのアクセス権の役割のいずれかに追加するには、ページを共用するユーザーまたはグループの横にあるチェック・ボックスにマークを付けます。
  6. 「ビューに追加 (Add to View)」をクリックして、選択したユーザーにビュー・アクセス権限を付与するか、「編集に追加 (Add to Edit)」をクリックして、選択したユーザーに編集アクセス権限を付与します。 選択したユーザーおよびグループは、対応する役割リストにコピーされます。
  7. ユーザーおよびグループをページ・アクセス権にさらに追加するには、異なる検索ストリングでさらに検索を実行するか、必要に応じて検索タイプを変更します。
  8. ユーザーまたはグループがページに対して持つアクセス権を変更するには、現在の役割リストでユーザーまたはグループを選択し、該当する「追加...」ボタンをクリックしてアクセス権を変更します。ユーザーおよびグループをリスト間でドラッグ・アンド・ドロップすることもできます。 複数選択を転送するには、特定のリスト内ですべてのユーザーまたはグループを選択し、それらすべてを一度に新規リストにドラッグ・アンド・ドロップします。
  9. ユーザーまたはグループをアクセス権リストから除去するには、それらを選択し、「除去」ボタンをクリックします。

共用ページの表示および追加

あるユーザーが他のユーザーとページを共用する場合、それらの他のユーザーは共用ページを表示する前にそれらを受け入れる必要があります。

このタスクについて
別のユーザーが共用するよう設定したページを受け入れて追加するには、以下の手順を実行します。
手順
  1. 「共用」メニューを開きます。
  2. 「共有ページの追加 (Add Pages Shared with Me)」をクリックします。 これにより、「ページの追加 (Add Pages)」ダイアログが開きます。
  3. ダイアログで、他のユーザーが共用として設定したページのリストを参照します。
  4. ページをナビゲーションに受け入れるには、追加するページの横にある「追加」ボタンをクリックします。 ページは、ナビゲーションの「ホーム」の子として追加されます。

ページ・ビルダーのドラッグ・アンド・ドロップ

ページ・ビルダーのフィーチャーの 1 つに、ドラッグ・アンド・ドロップ機能があります。

ページ・ビルダーでは、2 つのリソース・タイプ、つまりページおよびポートレットをドラッグ・アンド・ドロップすることができます。
  • ナビゲーション・ウィジェットでレンダリングされるページには、ドラッグ・ハンドルが関連付けられています。 それを使用して、必要な場所にページをドラッグできます。
  • さらに、ドラッグ・アンド・ドロップを使用してポートレットを配列することもできます。ポートレットのタイトル・バーはドラッグ・ハンドルの働きをします。 ポートレットをページ上の他のポートレットまたは空のコンテナーにドラッグすると、シャドーが表示されます。 シャドーは、ターゲット上に移動したときにコンテナーに表示されるプレビュー・プレースホルダーです。これは、ポートレットがドロップされた場合にレイアウトがどのように表示されるかを説明します。
制限: ページ・ビルダーのドラッグ・アンド・ドロップ機能は、複数選択およびリソースのコピーをサポートしません。

Dojo およびドラッグ・アンド・ドロップについて詳しくは、以下に示すドキュメンテーション・リンクを参照してください。

ポートレットのドラッグ・アンド・ドロップ

テーマ Default.jsp には、ポートレットをドラッグする場合のドラッグ・アンド・ドロップの動作を定義する、ibmPortalConfig オブジェクトに設定されたパラメーターがあります。
dndPortletsWithHandles
このパラメーターは、コンテナーでドラッグ・ハンドルを使用可能にするかどうかを定義します。 デフォルト値は true です。
dndPortletsWithGhost
このパラメーターは、ドラッグ時にシャドーを表示するかどうかを定義します。デフォルト値は true です。
portletDndSource
このパラメーターは、使用するドラッグ・ソース・クラスを定義します。デフォルト値は com.ibm.portal.dnd.PortletSourceGhost です。
ファイル Default.jsp では、ポートレットのドラッグ・アンド・ドロップは以下の行で初期化されます。
dojo.addOnLoad(com.ibm.portal.dnd.PORTLET_MEDIATOR.init);
ポートレットのドラッグ・アンド・ドロップ・クラスは、ポータルの Dojo Resources アプリケーションと一緒に配置されます。 クラスの場所は以下のとおりです。
wp_profile_root/installedApps/node/Dojo_Resources.ear/dojo.war/com/ibm/portal/dnd
その場所にあるファイルは、Dojo ドラッグ・アンド・ドロップのコア機能に追加して使用されます。 これらのファイルを以下にリストします。
PortletMediator.js
このソース・クラスには、初期化コード、つまりアバター作成者が含まれます。 これは、UI の更新を起動する公開済みの Dojo ドラッグ・アンド・ドロップ・イベントに接続します。
PortletAvatar.js
このソース・クラスは、デフォルトの Dojo アバター構成メソッドをオーバーライドして、ドラッグ時にポートレット・コンテンツを表示します。
PortletSource.js
このソース・クラスは、デフォルトのドラッグ・アンド・ドロップ・スタイルをポートレットに使用します。 このクラス名を ibmPortalConfig オブジェクトの portletDndSource の値に設定して、デフォルトの Dojo スタイルを使用できます。
PortletSourceGhost.js
このソース・クラスはシャドーを使用して、ポートレットの配置をプレビューします。 これは、ibmPortalConfig オブジェクトの portletDndSource のデフォルトの値クラス名として設定されます。 シャドーのスタイルを変更するには、クラス ibmPortalDndGhost を変更します。これは次のファイルにあります。
wp_profile_root/installedApps/[node]/Enhanced_Theme.ear/wp.theme.enhancedtheme.war/themes/html/Enhanced/css/portal.css

ページのドラッグ・アンド・ドロップ

ページのドラッグ・アンド・ドロップ・クラスは、ポータルの Dojo Resources アプリケーションと一緒に配置されます。 クラスの場所は以下のとおりです。
wp_profile_root/installedApps/[node]/Dojo_Resources.ear/dojo.war/com/ibm/dnd
ModeledSource.js
このソース・クラスは、モデル化されたウィジェットでの dnd 操作をサポートします。これを拡張して、ドラッグするデータ・タイプに応じて別のドロップ・アクションおよびドロップ・ゾーンを指定することができます。
PageAvatar.js
このクラスは、デフォルトの Dojo 実装をオーバーライドすることによって、ページ・タブ用のアバターを構成します。 アバターの不透明性は、creator メソッドで割り当てられるクラス ibmPortalDndPageAvatar によって適用されます。 ページ・アバターのスタイルを変更するには、クラス ibmPortalDndPageAvatar を変更します。これは次のファイルにあります。
wp_profile_root/installedApps/node/Enhanced_Theme.ear/wp.theme.enhancedtheme.war/themes/html/Enhanced/css/portal.css
PageCreator.js
このクラスは、ドラッグ時にアバターとして使用されるノードを作成します。デフォルトで、これはページ・タイトルを含むグレーのボックスです。
ナビゲーション・ウィジェットでは、ドラッグ・アンド・ドロップの動作を使用可能化および変更するためのいくつかのパラメーターが渡されます。 ナビゲーション・ウィジェットは、ファイル NavWidget.jspf によって「タブ・メニュー - ページ・ビルダー」テーマ内で初期化されます。
dndEnabled
これはウィジェット内でドラッグ・アンド・ドロップを切り替えます。デフォルト値は true です。
dndType
これは、ページ・ノードに指定されたタイプです。デフォルト値は cmNode です。
dndAccept
これは、ページ・ノードが受け入れるタイプです。デフォルト値は cmNode です。
dndCreator
これは、アバター・ノードを作成する creator メソッドです。デフォルト値は com.ibm.dnd.PAGE_CREATOR.creator です。

アバター

アバターを変更するために、ポータルは creator 関数を提供します。ポートレットの場合、これはファイル PortletMediator.js にあります。ページの場合、これは PageCreator.js にあります。メソッド creator は、hint パラメーターが avatar と等しいかどうかを調べます。等しい場合は、ドラッグ時に表示するために使用されるノードを作成します。 以下の例を参照してください。
creator: function(item, hint){
if(hint=="avatar"){
   ...			
   Modify this code to create a custom node that is to be used as the avatar. 
   The default avatar is the portlet markup itself.
   ...		
}else{ 
   ...			
      When there is no avatar creator function given, a default avatar is created. 
      The default avatar is based on the one defined in dojo.dnd.Source 
      in the functions _normalizedCreator/onDropExternal."
   ...		
}
}

異なる Dojo バージョンの使用

デフォルトで、ポータルは Dojo バージョン 1.4.3 をテーマに使用します。必要に応じて、以前の Dojo バージョンを使用することができます。

このタスクについて

WebSphere Portal バージョン 7.0 には、Dojo バージョン V 1.4.3、V 1.3.2、および V 1.1.1 が付属します。 Dojo バージョンの使用法について、詳しくは次の情報を参照してください。
  • WebSphere Portal での Dojo の一般情報については、『Dojo および WebSphere Portal』に関するトピックを参照してください。 このトピックでは、以前のポータル・インストールで作成したカスタム・テーマを Dojo V 1.1.1 または V 1.3.2 から V 1.4.3 にアップグレードする方法に関する情報も提供されています。
  • 異なるテーマでの複数の Dojo バージョンの使用法について詳しくは、『Dojo および WebSphere Portal』に関するトピックを参照してください。

ページ・ビルダーのためのヒント

ページ・ビルダーのヒントおよび既知の制限事項について説明します。

ページ・ビルダーでの作業の使用上のヒント

ページ・ビルダーはドラッグ・アンド・ドロップ・タグを使用しません。ページ・ビルダーは Dojo ドラッグ・アンド・ドロップ・フレームワークを使用します。

既知の制限事項

ページ・ビルダーには、以下の制約があります。
  • ページ・ビルダーと「ページ・ビルダー」テーマは、以下のポータル・フィーチャーをサポートしません。
    • サイド・ナビゲーション。ページ・ビルダー」テーマは、サイド・ナビゲーションを使用しません。したがって、ページ・ビルダー・テーマを使用するポータルのユーザーが、例えば SideNavOnly を選択してテーマのスタイルをサイド・ナビゲーションのみに変えるなどして、トップ・ナビゲーションを非表示にすると、ナビゲーションは表示されなくなります。
    • ロックされているコンテナー。
    • ポータル・スタイル・クラス。
    • テーマのポータル・カラー・パレット。
  • ページ・ビルダーのスキンは、現行ページがレイアウト・テンプレートと共にレンダリングされた場合にのみ、 ポートレット・コンテキスト・メニューで方向を示す「移動」オプションをサポートします。 従来のレイアウトが使用されている場合、「移動」オプションはポートレット・コンテキスト・メニューで使用できません。
  • ページ・ビルダーから起動した新しいページ・ダイアログは、ページ・タイトルおよびそのプライバシー・モードだけをカスタマイズすることができ、 モデル化されたレイアウトによる通常のポータル・ページの作成だけをサポートします。

ページのカスタマイズ

ページ・カスタマイザーには、ページのレイアウト、コンテンツ、および外観を編集するためのポートレットが含まれています。 また、ページ上の連携ポートレットの間の接続をセットアップすることができるワイヤー・ポートレットや、 コンテナーとコンテナーの内容をロックしたり、アンロックしたりすることができるロック・ポートレットも用意されています。 これらのポートレットの設定は、一定の機能だけを表示するように構成して、基本ユーザーが高度なタスクを実行できないようにすることができます。

スキンは、ポートレットを囲む枠 (タイトル・バーなど) を表します。 ユーザーに必要なアクセス権があれば、ページ・カスタマイザーの外観ポートレットを使用して、個々のポートレットのスキンを選択することができます。 ポートレットにスキンを設定するには、ページ・カスタマイザーにアクセスして、外観ポートレットを選択します。詳しくは、このポートレットのヘルプを参照してください。

ページは、変更を開始すると、非アクティブ化されます。ページの編集中は、すべての変更は即時に有効になり、元に戻したり、キャンセルすることはできません。 「完了」をクリックして変更を確定するまでは、他のユーザーはそのページにアクセスできず、そのページでポートレットの編集モードを起動するアイコンは非アクティブ化されます。

共用ページを編集すると、ページを編集しているユーザーに割り当てられた役割によって、異なる結果が得られる可能性があります。

  • ページに対して編集者の役割を持つユーザーは、そのページのすべてのユーザーに影響を与える変更を行うことができます。
  • ページに対して特権ユーザーの役割を持つユーザーは、そのページの専用コピー (つまりレイヤー) への変更のみ行うことができます。 この変更は、ページのその他のユーザーには影響を与えません。 このページの初期レイアウトで、少なくとも 1 つはコンテナーが含まれていなければ、特権ユーザーの役割を割り当てられたユーザーがページの変更を行うことはできません。
  • ページに対してユーザーの役割を持つユーザーは、ページを編集することはできません。
ポートレットにアクセスするには、ポータルにログインして次のいずれかのメソッドを使用してください。
  • 変更するページに移動して、ドロップダウン・メニューから「ページ・レイアウトの編集」を選択する。ページのドロップダウン・メニューは、そのページのタブ上にあります。 レイアウトの編集ポートレットは、現行ページを編集のために開きます。 適切なアクセス権があれば、ページ・カスタマイザーの他のポートレットを使用することもできます。
  • 新規ページが作成されると、新規ページのレイアウトおよびコンテンツの編集を行うレイアウトの編集ポートレットに誘導される。 適切なアクセス権があれば、ページ・カスタマイザーの他のポートレットを使用することもできます。 新規ページを作成するには、ドロップダウン・メニューから「新規ページ」を選択します。 ページのドロップダウン・メニューは、そのページのタブ上にあります。
  • ページの管理ポートレットにナビゲートして、該当する行の「ページ・レイアウトの編集」アイコンをクリックする。

レイアウトおよびコンテンツ

レイアウトの編集ポートレットにより、ポータル・ページのレイアウトおよびコンテンツを定義できます。

このポートレットは、「ページ・カスタマイザー」に配置されています。 ページ上では、次のようなオプションが選択できます。

  • レイアウト・テンプレート: 事前に構成されたいくつかのページ・レイアウトから 1 つを選択することができます。
  • ポートレットの追加: リストから、ページ上のコンテナーに追加できるポートレットを選択できます。 場合によっては、ここで、使用可能なすべてのポートレットをリストするのではなく、ポートレットの検索条件を入力する必要があります。
    注: ポートレットを、ポートレット・パレットからドラッグしてページに追加することもできます。
  • レイアウト・ツールを表示: ページ・コンテナーの作成および編集のための高機能なレイアウト・ツールを表示します。このオプションを選択すると、事前に構成したレイアウト・テンプレートはオーバーライドされます。

    「レイアウト・ツールを表示」オプションが レイアウトの編集ポートレットに表示されない場合は、「 編集」アイコンをクリックし、オプション「「レイアウト・ツールを表示/レイアウト・ツールを隠す」の切り替えリンクを表示」にチェック・マークを付けることにより、それを表示できます。

次のサンプル・ページには、次のレイアウトが使用されています。

  • 行コンテナーには、次の項目が含まれています。
    • 2 つの列コンテナー。それぞれのコンテナーに次の内容を組み込みます。
      • 2 つのポートレット・コンテナー (コントロール)。それぞれにポートレットが 1 つ入っています。

この例では、ページの構造は次のようになります。

画像は、2 つの列コンテナーを含む行コンテナーのあるページ・レイアウトを示しています。
それぞれの列コンテナーには、ポートレットを含む 2 つのポートレット・コンテナーがあります。
列コンテナー 1 には、Hello world および Stocks のポートレットが含まれます。
列コンテナー 2 には、News および Weather のポートレットが含まれます。

注:ページ・ビルダー」テーマは、レイアウト・テンプレートを使用する代替のレイアウト・メカニズムを提供します。 これらのレイアウト・テンプレートについて詳しく知るには、『ページ・ビルダー』セクションで『ページ・レイアウトの変更』に関するトピックを参照してください。 行と列のレイアウトと、レイアウト・テンプレートを使用する手法は、以下のように切り替えることができます。
  • 行と列からテンプレートへ: 行と列のレイアウトのページからページ・テンプレートに変換するには、「ページ・ビルダー」テーマのインライン・カスタマイズ・シェルフのユーザー・インターフェースによってページ・テンプレートを割り当てます。 行と列のレイアウト内のポートレットは、新しいレイアウト・テンプレート構造に移されます。
  • テンプレートから行と列へ: レイアウト・テンプレート・ページを行と列のレイアウトに変換するには、レイアウト・テンプレート割り当てを除去します。 これを行うには、テーマ内の「追加アクション」メニューの「ページ・プロパティーの編集」をクリックするか、または「ページの管理」管理ポートレットを使用することによって、 「ページ・プロパティー」ポートレットにアクセスします。 「拡張オプション」をクリックしてから、「パラメーターを設定する」をクリックします。 「レイアウト (layout)」という名前のパラメーターを見つけて、「削除」をクリックします。 これでページ・レイアウトは、1 列がレイアウト・テンプレートの 1 つのコンテナーを表す、列のセットによって構成されるようになります。このレイアウトは、「レイアウトの編集」ポートレットを使用して変更できます。

ポートレットをページに追加する

ポートレットは、検索を実行依頼し、次に使用可能なポートレットのリストから選択することにより、ページに追加されます。選択したページに配置できるのは、このポートレット・リストで使用可能なポートレットだけです。一度ポートレットを行または列に配置してしまうと、その外側のコンテナーからすべてのポートレットを除去しない限り、その行または列を変更することはできません。

手順
  1. 「管理」 > 「ページの管理」とクリックする。
  2. ポートレットを追加するページに移動する。
  3. ページ名の横の「ページ・レイアウトの編集」アイコン (小さな鉛筆) をクリックする。
  4. 「ポートレットの追加」をクリックする。
  5. 使用可能なポートレットのリストで、ポートレット・タイトルの横のボックスをクリックしてポートレットを選択し、「OK」をクリックする。 ポートレットのリストが長い場合は、ポートレット・タイトルを検索することもできます。複数のポートレットを選択してページに追加できます。
  6. 「OK」をクリックする。
  7. 「完了」をクリックして、変更したページを保存する。

オブジェクトの編成

ポートレットやコンテナーなどのオブジェクトは、ページ上で再配置できます。

このタスクについて

ポートレットおよびコンテナーを希望する位置に移動するには、該当する矢印を使用します。ページ・マネージャーが列または行コンテナー、あるいはコンテナーのコンテンツをロックしていた場合、そのページの変更が制限されることがあります。制限されているタスクを表すアイコンは表示されません。

列と行を作成し、ポートレットをこれらのコンテナー内に配置して、ページ上でそれらのコンテナーを再配置できます。

「レイアウト・ツールを表示」を選択すると、ページ上でオブジェクトを移動するためのオプションをさらに多く利用できます。 例えば、複数のポートレットにそれぞれチェック・マークを付けてポートレットの移動アイコンをクリックすると、選択したポートレットを新しいロケーションに移動できます。

ページ・レイアウトの変更

ページを作成する場合、ポートレットの表示領域の上に表示されるレイアウト・テンプレートの 1 つを選択できます。ほとんどの場合、必要になるのは、これらの事前定義されているレイアウトの 1 つにポートレットを追加することだけです。

このタスクについて

レイアウトをさらに制御する必要がある場合は、「レイアウト・ツールを表示」をクリックして、拡張レイアウト・アイコンを表示します。スペースをネストしたり、行および列を追加することができます。

ユーザーがオプション「レイアウト・ツールを表示」をクリックできるのは、レイアウトの編集ポートレットの「構成」または「共用設定の編集」モード内で「「レイアウト・ツールを表示/レイアウト・ツールを隠す」切り替えリンクを表示」チェック・ボックスが事前に有効になっている場合のみです。

ページ上のポートレット固有名の編集

ページ・カスタマイザーからページのレイアウトを編集している間に、ページ上のポートレットの固有名を変更できます。 設定した固有名は、ページ上のポートレット・インスタンスのみに影響します。

このタスクについて
手順
  1. 「管理」 > 「ページの管理」とクリックする。
  2. 変更しようとしている固有名のポートレットを含む、該当するページにナビゲートします。
  3. ページ名の横の「ページ・レイアウトの編集」アイコン (小さな鉛筆) をクリックする。
  4. ポートレット名の隣にあるドロップダウン・メニュー >「ポートレット・ウィンドウの固有名を設定」をクリックします。
  5. フィールド内に固有名を入力します。
  6. 「OK」 > 「完了」をクリックします。
次のタスク
注:
  1. 「カスタム固有名の管理」ポートレットからページ上のポートレット・インスタンスの固有名を作成したり編集したりすることもできます。
  2. 変更するページのコンテキスト・メニューから適切なオプションを選択することによっても、「ページ・レイアウトの編集」ポートレットに移動できます。

ポートレットの設定の変更

レイアウトの編集ポートレットにリストされる各ポートレットの設定を変更できます。これらのオプションは、コンテナー内に表示される各ポートレット上のドロップダウン・メニューから選択できます。

このタスクについて
これらの各オプションは、ポートレットの設定を変更するための新規ウィンドウを開きます。所有しているアクセス権限によっては、これらのオプションの一部は使用できない場合があります。
手順
  • ポートレットを個別設定するには、「このポートレットの個別設定」を選択します。ここで行った更新では、ポートレットの外観が変化するだけです。
  • すべてのユーザーに対してポートレットのデフォルトの外観を変更するには、このポートレットの「共用設定の編集」を選択します。ここで行う更新は、特定のページにポートレットを表示するすべてのユーザーに影響します。 変更は、その他のページに表示されるポートレットのインスタンスには反映されません。
  • すべてのページに渡ってすべてのユーザーに対してポートレットのデフォルトの外観を変更するには、「構成」を選択します。ここで行う更新は、ポートレットを任意のページに表示するすべてのユーザーに影響を与えます。
以下の設定値を変更できます。
ユーザーはページ・レイアウトを変更できます
このオプションは、ページのレイアウトを、事前定義されたレイアウト・テンプレートの 1 つに変更できるようにする場合に選択します。「許可されているレイアウト」の 1 つを選択すると、このオプションをさらにカスタマイズできます。
切り替えリンクの表示
このオプションは、拡張レイアウト・ツールのリンクを表示する場合に選択します。このリンクを最初にクリックすると、拡張ページ・レイアウトの作成を可能にするツールが表示されます。
ポートレットを列に追加または移動する前にポートレットの幅をチェックする
このオプションは、特定の幅のポートレットが、幅が狭すぎるコンテナーに移動または追加されないようにする場合に選択します。
ページ当たりの項目数
検索結果が返された後、この設定により各ページのポートレットの数が制限されます。複数ページの場合は、矢印アイコンを使用して他のページに移動できます。
この数を超える項目は表示しない
検索で返されるポートレットの数を制限します。
検索結果に以下の情報も表示する
各ポートレットによってサポートされているマークアップも結果に表示するかどうかを選択します。

Personalization ルールの選択

レイアウトの編集ポートレットから、特定のポートレットの Personalization ルールを管理できます。

このタスクについて
ポートレット・ルールのマッピングを表示するには、「レイアウトの編集」の設定で「ポートレットのルール・マッピングの表示」が有効になっていることを確認します。
手順
  • ルールを選択するには、ポートレット上の「マップされるルールなし」ドロップダウン・リストから「ルールの選択」を選択します。 Personalization ルール・ピッカー・ポートレットが表示されます。ルールを選択すると、レイアウトの編集ポートレットに戻ります。
  • 既存のルールを削除するには、ポートレットの「マップされるルールなし」ドロップダウン・リストから「マッピングの削除」を選択します。

ページ上のコンテンツのロック

コンテナーやコンテンツの移動、またはポートレットの削除のためのアクセス権を設定するには、ロック・ポートレットを使用します。そうすると、コンテンツをページ上の一定の位置にロックすることができます。 行コンテナー、列コンテナー、あるいはポートレットなどのページ上のエレメントは、さまざまな形でロックまたはアンロックでき、これによりユーザーが変更できる内容を制御できます。 コンテンツやレイアウトを維持する必要があるページでは、他のユーザーがページ上のコンテナーやポートレットの配置を変更しないようにするために、コンテンツとレイアウトの両者をロックできます。

始める前に

特定のページのロックを変更するには、そのページに対する編集者役割が必要です。ユーザーに必要なアクセス権があれば、そのページで他のユーザーが操作できる範囲を決定できます。

このタスクについて

ロックおよびアクセス権が、共用ページからコンテンツを継承するページに与える可能性のある影響について、ご注意ください。 ページ上のコンテンツをロックまたはアンロックするには、以下のようにします。

コンテンツのロックとアンロック

アドミニストレーターは、コンテナーのコンテンツを使用して実行できるタスクを制限できます。

このタスクについて
ポータル・ユーザーが静的ページ上のコンテナーのコンテンツを変更できないようにできます。ページ上のコンテナーのコンテンツをロックすると、ポートレットをそのコンテナーに追加したり、ポートレットをそのコンテナーの中または外に移動させることはできなくなります。
コンテナーがロックされている場合、そのコンテナーをページから除去することはできません。アドミニストレーターは、コンテナーのコンテンツを使用して実行できる以下のタスクを制限できます。
  • コンテナーへのポートレットの追加
  • コンテナーからのポートレットの除去
  • コンテナー内から別のコンテナーへのポートレットの移動
  • コンテナーへのサブコンテナー (列または行) の追加
  • コンテナーからのサブコンテナー (列または行) の除去
  • コンテナー内のポートレットの位置の変更
  • コンテナー内のサブコンテナーの位置の変更
  • コンテナーの幅の設定
手順
  1. 「管理」 > 「ページの管理」とクリックする。
  2. ページ名の横の「ページ・レイアウトの編集」アイコン (小さな鉛筆) をクリックする。
  3. 「ロック」タブをクリックする。
  4. コンテナーのコンテンツをロックするために、コンテナー・ボックスの左上隅のロック・アイコンをクリックする。このアイコンは、コンテナーのコンテンツがロックされると閉じたロックを表示し、アンロックされると開いたロックを表示します。 このアイコンをクリックすると、ロック状態とアンロック状態が切り替わります。
  5. 「完了」をクリックしてページの変更を保存する。
「コンテンツ」タブをクリックすると、コンテナーのコンテンツがロックされていることを確認できます。コンテナー・ボックスのコンテンツがロックされている場合は、「ポートレットの追加」ボタンまたは方向を示す矢印は表示されません。

削除オプションの設定

ユーザーによるポートレットの削除を使用可能または使用不可にします。

このタスクについて
削除オプションは、コンテナーの右上隅にあるチェック・ボックスです。ポートレットの削除ボックスが未チェックの場合は、「レイアウトとコンテンツの編集」でページを変更しようとしても、ユーザーはそのポートレットの削除アイコンを使用できません。ポートレットの削除ボックスにチェック・マークが付けられている場合は、ユーザーは「レイアウトとコンテンツの編集」でページを変更するときに、そのポートレットの削除アイコンを使用できます。ポートレットがページに追加された場合の、そのポートレットのチェック・ボックスには、デフォルトでチェックマークが付けられます。

ポートレット間の接続

ポートレット・ワイヤリング・ツールを使用すると、連携ポートレット間の接続、すなわちワイヤーを構成することができます。 連携ポートレットは、プロパティー・ブローカーを経由して、相互に情報、すなわちプロパティーを交換することができます。 プロパティーの交換は、Click-to-Action メニューをユーザーに促すことにより行うか、あるいは構成済みワイヤーを使用することにより自動的に行うことができます。 この結果、ページ上のポートレットがユーザーのアクションに対して、統合され、統一された形で応答できるようになります。

ポートレット間のワイヤーをセットアップすると、ユーザーの転送選択を保管することができます。 ワイヤーを使用すると、特定の相互作用が行われたときに、 さらに情報をプロンプトするポップアップ・メニューをユーザーに表示することなく、ターゲット・ポートレットに自動的にプロパティーを転送することができます。 ポートレット・ワイヤリング・ツールを使用すると、ページ上のポートレットが送受信できるプロパティーを表示することができます。 2 つのポートレット間で一致がある場合は、2 つのポートレット間のワイヤーを作成できます。 既存ワイヤーの削除も、このツールを使用して行えます。

ポートレット・ワイヤリング・ツールは、クロス・ページ・ポートレット通信を実装する機能も提供します。 クロス・ページ・ワイヤーによって、ポートレットは各ページ間でプロパティーの交換ができるようになります。 クロス・ページ・ワイヤーを作成する前に、そのポートレットでグローバルに定義されたアクションを、その対象ページが受信する必要があります。 アクションをグローバルに設定することで、そのアクションは Click-to-Action メニューでも使えるようになります。 アクションをグローバルに設定するには、ターゲット・ページに移動してタイトル・バー上のドロップダウン・メニューから「ページ・レイアウトの編集」を選択します。 それから「ワイヤー」タブを選択して「アクションの管理」をクリックします。 これによって、ページのポートレットのリストと、対応する受信アクションが表示されます。

ポートレット・ワイヤリング・ツールを使用する代わりに、ポートレットで対話式にワイヤーを作成することもできます。 ブラウザーに応じて、十分なアクセス権のあるユーザーは、CTRL キーまたは ALT キーを押しながら、Click-to-Action 機能と関連づけられたポートレットのアイコンまたはホット・スポットをクリックすることで、ワイヤーを作成できます。 ダイアログが表示されるので、そのダイアログでユーザーはページ上の他のポートレットへのワイヤーを作成できます。

ワイヤリング・ツールでは、対話式のアプローチでは処理されない状態のときに、ワイヤーを作成することができます。 例えば、このツールではワイヤー作成を開始するのに Click-to-Action メニューが存在する必要がありません。また、このツールを使用して単一のソース・プロパティーから複数のワイヤーを作成できます (対話式アプローチを使用する場合は、単一ソースをワイヤーできるのは単一ターゲットまたは全ターゲットであり、任意のサブセットにはワイヤーできません。)。 ワイヤーの作成または削除は、下記の説明のとおり、アクセス制御検査に従います。

このツールそのものを表示するためには、ユーザーは、そのページおよびポートレット上で、少なくとも「ユーザー」役割アクセス権を所持していなければなりません。 ユーザーにポートレット間のワイヤーの表示、作成、または削除を許可する前に、さらにアクセス検査が実行されます。 ユーザーがページのワイヤーを表示するためには、ユーザーはページ上、およびページにあるワイヤーを作成されたポートレットで少なくとも「ユーザー」役割アクセス権を所持していなければなりません。 またユーザーは、ユーザー・ワイヤーの作成または削除を行うことも (この場合、そのページのユーザー個人のビューに影響します)、共用ワイヤーを作成または削除することもできます (この場合、そのページのすべてのユーザーのビューに影響します)。 ユーザー・ワイヤーを作成または削除するには、ユーザーは、少なくともそのページの「特権ユーザー」役割のアクセス権、およびそのポートレットの「ユーザー」アクセス権を所有している必要があります。 それに対し、共用ワイヤーを作成または削除するには、少なくともそのページの「編集者」役割のアクセス権、およびそのポートレットの「ユーザー」アクセス権が必要です。

テーマとスキン

テーマは、ページ全体の外観を決定するものです。 この目的は、視覚的な整合性を確保することです。 テーマは、ナビゲーション構造、バナー、色とフォント、使用可能なポートレットのスキン、およびその他のページの視覚的なエレメントに影響します。 スキンは、ポートレット周囲に表示されるフレームを決定します。

テーマとスキン・ポートレットを使用して、以下を実行します。

  • ポータル・デフォルト・テーマの設定
  • ポータル・デフォルト・スキンの設定
  • テーマの関連スキン
  • テーマにデフォルト・スキンを設定
  • ポータルにテーマとスキンを新規追加
  • ポータルからテーマとスキンを削除

このポートレットは、「管理」 > 「ポータル・ユーザー・インターフェース」 > 「テーマとスキン」の下にあります。追加手順については、関係ポートレットのヘルプを参照してください。

注:
  1. テーマを削除すると、そのテーマへの参照およびそのテーマと関連スキン間のリンクも削除されます。 削除したテーマに関連するスキンも同時に削除する場合は、削除したテーマだけに関連付けられているスキンのみを削除するように注意してください。 スキンは、ポートレットに関連付けられています。 そのため、1 つのスキンが複数のテーマに関連付けられているときに、そのテーマの 1 つを削除しても、他のテーマではそのスキンが表示されます。
  2. テーマまたはスキンを削除しても、/theme または /skin ディレクトリーはサーバーから除去されません。
  3. 言語の設定で DBCS 文字を使用する場合、テーマとスキンのタイトルの一部が正しく表示されないことがあります。 これらのタイトルの表示を訂正するには、HTML マークアップの言語設定で使用する文字セットを UTF-8 に変更してください。

デフォルト・テーマの設定

ポータル全体にわたって使用するテーマを選択します。

このタスクについて
ポータル全体のデフォルト・テーマを設定するには、以下のようにします。
手順
  1. テーマ・リストからテーマを選択します。
  2. 「デフォルト・ポータル・テーマとして設定」をクリックします。
タスクの結果
ページに対してテーマが設定されない場合は、ポータル・デフォルト・テーマが使用されます。

デフォルト・スキンの設定

ポータルのすべてのポートレットに対するデフォルトとして使用するスキンを選択します。

このタスクについて
ポートレットに対するポータル全体のデフォルト・スキンを設定するには、以下のようにします。
手順
  1. スキン・リストからスキンを選択します。
  2. 「デフォルト・ポータル・スキンとして設定」をクリックします。
タスクの結果
テーマに対してデフォルトのスキンが 設定されない場合は、ポータル・デフォルト・スキンが使用されます。「NoSkin」という名前のスキンをポートレットに適用しないでください。このスキンは管理ポートレットを意図し、タイトル・バーなしでポートレットをレンダリングします。

ページ上のポートレットの管理

ポートレット・パレットは、ページのカスタマイズを高速かつ容易に実行するために、ページにドラッグできるポートレットのコレクションを提供します。

ポートレット・パレットは、ポータル・テーマで使用可能です。ポートレット・パレットを開くには、 次の展開矢印アイコンをクリックします:
パレットの引き出し。
ポートレット・パレットを開くには、展開矢印アイコンをクリックします。
注: ポートレット・パレットは、フライアウト・パレットで機能するように設計されています。 ポートレット・パレットをページに追加すると、望ましくない結果になることがあります。

デプロイメントに使用できるポートレットを、カテゴリーを使用して、コレクションから編成およびグループ化することができます。 カテゴリーは、独自の分類方式を使用して、ポートレットを編成する方法を提供します。 コレクション内のポートレットをグループ化して編成するための新規カテゴリーを作成し、そのカテゴリーを適宜名前変更できます。 カテゴリーの再配置、カテゴリーへのポートレットの追加、およびカテゴリー間でのポートレットの移動を行うことで、ポートレット・パレットをさらにカスタマイズできます。 また、興味のあるポートレットのタイトル別に検索することもできます。 これらのカスタマイズをポートレット・パレットの個々のインスタンスに適用したり、必要に応じてポートレット・パレットのすべてのインスタンスまたは選択したインスタンスに反映するように設定を変更したりすることができます。

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

ポートレット・パレットを使用したポートレットのページへの追加

ポートレット・パレットは、ポートレットをページに迅速かつ簡単にデプロイする手段となります。 単一のポートレットまたは同じカテゴリー内の複数のポートレットをページにドラッグすることができます。 カテゴリーは、ポートレット・パレット内でポートレットを編成する手段となります。 ページへのポートレットの追加は、ポートレット・パレットからドラッグ・アンド・ドロップ機能のみを使用して、実行することをお勧めします。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

ポートレットをページに追加するには、次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. ポートレット・パレットからポートレットをクリックして、マウス・キーを押し下げたままにする。 複数のポートレットをカテゴリー内で選択するには、Ctrl キーを押したまま該当するポートレットをクリックします。
  3. ポートレットをページ上の移動先にドラッグする。デプロイメントに利用できるページ上の領域にポートレットをドラッグすると、水平バーが表示されます。 ポートレットを許可されているドロップ・ゾーンの近くにドラッグすると、水平バーの色は無色から色付きに変わります。
  4. ポートレットを所定のページにマウス・キーを離してドロップし、水平バーが表示されている場所にポートレットを追加する。
  5. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

ポートレットをページに追加するために利用可能な代替方法

ポータルのドラッグ・アンド・ドロップ機能を使用するためにはマウスが必要です。 ポートレット・パレットからページへのポートレットのドラッグに代わる利用可能な代替方法として、 キーボードを使用してポートレットをページに追加することができます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

ポートレットをページに追加するドラッグ・アンド・ドロップ機能の使用に代わる代替方法として、以下のステップを実行します。

手順

  1. ポートレットを追加するページに移動する。
  2. タブ・キーを押して、ページ・タイトルの横にあるドロップダウン・メニューまで進む。
  3. タブ・キーを押して、「ページ・レイアウトの編集」を強調表示する。
  4. 「コンテンツ」ページ上にある「レイアウトの編集」から、タブ・キーを押して、ポートレットを追加する適切なコンテナー内の「ポートレットの追加」を強調表示する。
  5. 用意されている機能を使用して、追加するポートレットを選択する。 追加するポートレットごとにチェック・ボックスを選択する必要があります。
  6. タブ・キーを押して「OK」を強調表示し、ポートレットをコンテナーに追加する。
  7. Enter キーを押します。 追加したポートレットのあるページが表示されます。

ページ上のポートレットの再配置

ポータルのドラッグ・アンド・ドロップ機能を使用して、ページ上の個々のポートレットの配置を変更することができます。 ドラッグ・アンド・ドロップ機能は、すべてのテーマ用、およびロックされていない行および列コンテナー用に備えられています。 ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。

このタスクについて

ポートレットをページ上にドロップするのをキャンセルするには、ポートレットをドロップすることが許可されていないページ上の宛先にポートレットをドロップするか、またはブラウザー・ウィンドウの外部にポートレットをドロップできます。 ページ上にポートレットを再配置するには、以下のステップを実行してください。

手順

  1. カーソルが移動標識 移動標識 を表示するように変わるまで、ポートレットのタイトル・バーの方へマウスを移動させ、それからポートレットのタイトル・バーをクリックします。水平バーは、ポートレットをドロップすることが許可されている、ページの潜在的なエリア上に表示されます。
  2. ポートレットをページ上の移動先にドラッグします。ポートレットを許可されているドロップ・ゾーンの近くにドラッグすると、水平バーの色は無色から色付きに変わります。
  3. ポートレットをページにマウス・キーをリリースしてドロップし、ページ上の新規の宛先にポートレットを移動します。

ページ上にポートレットを再配置するために使用できる代替手段

ポータルのドラッグ・アンド・ドロップ機能を使用するためにはマウスが必要です。 あるいは、ポートレットをページ上に新規の宛先にドラッグするために利用できる代替手段として、キーボードを使用して、ポートレットをページ上に再配置できます。

このタスクについて

ページ上にポートレットを再配置するには、以下のステップを実行してください。

手順

  1. 移動するポートレットを含むページに移動する。
  2. タブ・キーを押して、ページ・タイトルの横にあるドロップダウン・メニューまで進む。
  3. 適切なディレクトリーに移動する。
  4. Enter キーを押し、必要に応じて上矢印または下矢印を使用して、「ページ・レイアウトの編集」を強調表示する。
  5. 「コンテンツ」ページ上にある「レイアウトの編集」から、タブ・キーを押して、ポートレットに適した矢印ボタンを強調表示する。 矢印ボタンは、ポートレットを移動できる方向 (左、右、上、または下) を示します。
  6. Enter キーを押して、ポートレットを矢印の方向に移動する。
  7. タブ・キーを押して、「完了」を強調表示する。
  8. Enter キーを押します。

ページ上のポートレットの可動性の制限

コンテナーの幅を定義できます。この機能を使用して、ユーザーによるページ上でのポートレットの移動可能性を制限できます。ポータルでは、ポートレット配置フィルターまたは幅フィルターによって、この機能が実現されます。この幅フィルターは、ポートレットの幅を列コンテナーの幅と比較します。ポートレットの幅が列コンテナーの幅より大きい場合は、このコンテナーにポートレットを移動することはできません。

このタスクについて

幅フィルターを使用するには、以下のステップを実行してください。

手順

  1. ポータル構成サービスでフィルターを使用可能にする。プロパティー PortletPlacementFilterImpl の 値を com.ibm.wps.model.filters.portletplacement.impl.WidthFilterImpl に設定します。
  2. 必要に応じて、ポートレットの最大幅を設定する。ポートレット管理用のポートレットを使用し、正の数値を指定したポートレット・パラメーター MAX_WIDTH を追加します。値は、ピクセル数を指定します。パーセント値は、幅フィルターで無視されます。
  3. 必要に応じて、列コンテナーの幅を設定する。正の数値を使用します。値は、ピクセル数を指定します。パーセント値は、幅フィルターで無視されます。列コンテナーの幅を設定するには、次のステップを実行してください。
    1. ページ・レイアウトを編集するオプションを選択する。
    2. ポートレットを構成するためのオプション、またはポートレットの共用設定を編集するためのオプションを選択する。
    3. レイアウト・ツールを表示または非表示にする切り替えリンクを表示するためのボックスにチェック・マークを付け、「OK」をクリックする。
    4. レイアウト・ツールを表示するリンクをクリックする。
    5. 列幅を設定する二重矢印をクリックする。
    6. 入力フィールドに数値を入力する。値は、ピクセル数を指定します。パーセント値は、幅フィルターで無視されます。
    7. 「OK」をクリックします。列コンテナーの幅を設定したことを示す確認メッセージが表示されます。

カテゴリーを作成する

カテゴリーは、独自の分類方式を使用して、ポートレットを編成する方法を提供します。 コレクション内のポートレットをグループ化して編成するための新規カテゴリーを作成できます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。
次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. ポートレット・タイトル・バーの横にあるドロップダウン・メニューをクリックする。
  3. 「新規カテゴリーの作成」をクリックする。
  4. 新規カテゴリーの名前を入力する。
  5. 「OK」をクリックして変更を保管する。
  6. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

ポートレットを検索する

「検索」フィールドにポートレットのタイトルの一部または全部を入力することにより、ポートレット・パレット内のポートレットを検索できます。 検索では大/小文字を区別しません。また、正しいアクセス権を持っているポートレットだけが検索結果に表示されます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. 「検索」フィールドにポートレットのタイトルの一部または全部を入力する。
  3. 「検索」をクリックします。
  4. ポートレットをページに適宜ドラッグする。
  5. 「キャンセル」をクリックして、検索の起動前に表示されていたビューを復元する。
  6. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

検索結果の制限

検索結果の数は構成パラメーターによって制限されます。これは、アドミニストレーターが変更できます。 デフォルト値は検索結果を 100 個に制限します。

このタスクについて

ポートレット・パレットに表示される検索結果の数を 100 以外の値に変更するには、以下の指示を実行します。

手順

  1. 「管理」をクリックする。
  2. 「ポートレットの管理」をクリックする。
  3. 「ポートレット」をクリックする。
  4. 「ポートレット・パレット」を見つけて、ポートレットの「構成」をクリックする。
  5. SearchResultsLimit パラメーターを見つけて、新規の検索結果制限を反映するように値を更新する。
  6. 「ポートレットの管理」タイトル・バーにあるポートレット・メニューから使用可能なヘルプを参照する。

ポートレット・パレットでのカテゴリーの再配置

カテゴリーをポートレット・パレット内の新規移動先にドラッグすることにより、カテゴリーを再配置できます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. カーソルが移動標識 移動標識 を表示するように変わるまで、該当するカテゴリーのタイトルの方へマウスを移動し、それから該当するカテゴリーをクリックする。
  3. カテゴリーをポートレット・パレット内の適切な場所にドラッグする。 ポートレット・パレット内のカテゴリーを再配置できるエリアに水平線が表示されます。
  4. マウス・キーを放してカテゴリーをドロップし、ポートレット・パレット内でのカテゴリーの再配置を完了する。
    注: 再配置するカテゴリーは、ポートレット・パレット内のそれをドロップするカテゴリーの前に置かれます。
  5. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

別のカテゴリーへのポートレットの移動

ポートレットのコピーをあるカテゴリーから別のカテゴリーにドラッグして、ポートレット・パレットをカスタマイズできます。 ポートレットを別にカテゴリーに移動するときに、このポートレットはオリジナルのカテゴリーから削除されません。 ポートレットを別のカテゴリーにドラッグする場合は、このポートレットを一度に 1 つのカテゴリーにのみ移動できます。 また、カテゴリー内のポートレット名の横にあるドロップダウン・メニューにアクセスすることにより、 ポートレットのコピーを一度に複数のカテゴリーに追加することもできます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

ポートレットを別のカテゴリーに移動するには、以下のステップを実行してください。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. カテゴリー内のポートレットをクリックして、マウス・キーを押し下げたままにする。 複数のポートレットを選択するには、Ctrl キーを押したまま該当するポートレットをクリックします。
  3. ポートレットをポートレット・パレット内の該当するカテゴリーにドラッグする。 ポートレットを移動できるカテゴリー内のエリアにポートレットをドラッグすると、水平線が表示されます。 ポートレットをカテゴリーに移動すると、既にこのカテゴリー内にあるポートレットの間でポートレットがアルファベット順に配置されます。
  4. マウス・キーをリリースすることによってポートレットをドロップし、ポートレットを別のカテゴリーに移動する。
  5. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

ポートレットを複数のカテゴリーにコピーする

適切なアクセス・レベルを持つ場合は、カテゴリーのポートレットのコピーを一度に複数のカテゴリーに追加できます。 ポートレットのコピーを単一のカテゴリーに追加する必要があるだけの場合は、単純にポートレットのコピーを該当するカテゴリーにドラッグできます。 ポートレットのコピーを複数のカテゴリーに追加する場合、このポートレットはオリジナルのカテゴリーから削除されません。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. ポートレット名の上に移動して、矢印をクリックしてポップアップ・メニューを表示する。
  3. 「その他のカテゴリーに追加」をクリックする。
  4. 適切なカテゴリーのチェック・ボックスを選択して、ポートレットをそれらのカテゴリーに追加する。
  5. 「OK」をクリックして変更を保管する。
  6. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

パレットでのカテゴリーの名前変更

ポートレット・パレットにはデフォルト・カテゴリーが用意されています。 アクセス・レベルに応じて、これらのカテゴリーおよび後で作成するカテゴリーを名前変更し、ポートレット・パレット内のポートレットに最適な編成方式を実現することにより、ポートレット・パレットをカスタマイズできます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. カテゴリー名の横にあるドロップダウン・メニューをクリックする。
  3. 「カテゴリーの名前変更」をクリックする。
  4. カテゴリーの新規名を入力する。
  5. 「OK」をクリックして変更を保管する。
  6. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

その他の言語のカテゴリー・タイトルの設定

ポートレット・パレット内のカテゴリーを名前変更するときに、その他の言語のカテゴリー名を編集することができます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. カテゴリー名の横にあるドロップダウン・メニューをクリックする。
  3. 「カテゴリーの名前変更」をクリックする。
  4. 「その他の言語のタイトルの設定」をクリックして、言語のリストに対して現在設定されているタイトルを表示する。
  5. 「編集」をクリックして、該当する言語のカテゴリーのタイトルを変更する。
  6. 表示されたフィールドに、その言語の新規タイトルを入力する。
  7. ステップ 5 から 6 を繰り返して、その他の言語のカテゴリーのタイトルを編集する。
  8. 該当する言語のカテゴリーのタイトルの編集が終了したら、「OK」をクリックする。 「OK」をクリックすると、カテゴリーを名前変更するためのビューに戻ります。
  9. 「OK」をクリックして変更を保管する。
  10. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

パレットのデフォルト設定へのリセット

ポートレット・パレットを、アドミニストレーターによって現在保守されているデフォルト設定に戻すことができます。 ポートレット・パレットを現行のアドミニストレーター設定を使用するようにリセットすると、行ったすべてのカスタマイズは除去されます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. ポートレット・タイトル・バーの横にあるドロップダウン・メニューをクリックする。
  3. 「デフォルトにリセット」をクリックする。
  4. 「OK」をクリックして、ポートレット・コレクションをデフォルト値にリセットすることを確認する。
  5. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

カテゴリーを削除する

適切なアクセス・レベルを持っている場合は、必要に応じてポートレット・パレット内のカテゴリーを削除できます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. カテゴリー名の横にあるドロップダウン・メニューをクリックする。
  3. 「カテゴリーの削除」をクリックする。
  4. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

パレット・カテゴリーからのポートレットの削除

必要に応じてポートレット・パレット内のカテゴリーからポートレットを削除できます。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

ポートレットをカテゴリーから削除するには、次のステップを実行します。

手順

  1. 展開矢印アイコンをクリックして、ポートレット・パレットを開く。
  2. ポートレット名の上に移動して、矢印をクリックしてポップアップ・メニューを表示する。
  3. 「ポートレットの削除」をクリックする。
  4. 「OK」をクリックして、このポートレットをカテゴリーから削除することを確認する。
  5. 縮小矢印アイコンをクリックして、ポートレット・パレットを閉じる。

パレットの設定の変更

設定を変更して、すべてのページのポートレット・パレットのすべてのインスタンスに反映したり、異なるポートレット・モードを選択することによって、選択したインスタンスに反映したりすることができます。 最初にポートレット・パレットを開くと、アクセス・レベルに応じて「表示」モードまたは「パーソナライズ」モードに入ります。

このタスクについて

ポートレット・パレットで作業するときには、 以下の点に注意してください。
  • ページの変更に必要なアクセス権のある ID を使用して、ポータル・サイトにログインする必要があります。 ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。使用できるポートレットは、ページに存在している制限されるポートレットのリストによってもフィルター操作されます。
  • ロックされていない行およびコンテナー内のデフォルトのポータル・テーマ用に、ドラッグ・アンド・ドロップ機能が用意されています。
  • ポートレット・パレット内の項目は、古くなる可能性があります。 例えば、ユーザーがページを作成中または編集中にアドミニストレーターがポータルからポートレットを削除しても、ユーザーがそれらの更新に気付かない場合があります。 アドミニストレーターが加えた変更をユーザーが見るには、ポータルからログアウトして再度ログインする必要があります。 ポートレットがすでに存在していない場合にポートレット・パレットからポートレットをドラッグしようとすると、 メッセージがポータルのログに記録されます。 これはまれな状況ですが、アドミニストレーターは通常の業務時間にポートレットを除去したり追加したりすべきではありません。
  • ポートレット・パレットでは、カテゴリー名での二重引用符の使用はサポートされていません。
  • ポートレット・パレットは、ポータル・テーマで使用可能です。

以下の指示では、「表示」または「パーソナライズ」モードを離れ、「共用設定の編集」または「構成」モードを適宜使用することにより、他のユーザーの設定を変更することを想定しています。 アクセス・レベルによっては、これらのオプションがすべて表示されない場合があります。

「共用設定の編集」および「構成」モードの場合に、ポートレットをページにドラッグできません。

以下のステップを実行して、ポートレット・パレットの設定を変更します。

手順

  1. 「ポートレット」タイトル・バーの横にあるドロップダウン・メニューをクリックする。
  2. 「共用設定の編集」または「構成」を適宜クリックする。
    1. 「共用設定の編集」モードを使用すると、すべてのユーザーに対してポートレット・パレットのデフォルトの外観を変更できます。 ここで行う更新は、このページでポートレット・パレットを表示するすべてのユーザーに影響します。 変更は、その他のページに表示される、このポートレットのインスタンスには反映されません。
    2. 「構成」モードを使用すると、すべてのページのすべてのユーザーに対してこのポートレットのデフォルトの外観を変更できます。 ここで行う更新は、このポートレットを任意のページに表示するすべてのユーザーに影響を与えます。
  3. 「共用設定の編集」または「構成」モードを終了するには、ポートレット・タイトル・バーにあるドロップダウン・メニューをクリックして、「戻る」を選択する。

パレットのアクセス制御

ポートレット・パレットをカスタマイズし、それを扱うためのアクセス制御は、ポートレット役割、ポートレット・モード、およびページ・アクセス権に基づいています。 デフォルトで、ユーザーはポートレット・パレットに対する読み取りアクセスのみを提供する、全認証ポータル・ユーザー役割に割り当てられます。 ユーザーは、表示のためのユーザー・アクセス権を持っているポートレット・パレット上のポートレットのみ見ることができます。

ポートレットおよびページ役割のアクセス権

以下の表は、さまざまなポートレット役割に関連した使用可能なアクセス権を説明します。
表 25. さまざまなポートレット役割に関連した使用可能なアクセス権
ポートレット役割およびページ役割 アクセス権の説明
User@portlet、 User@Portlet Palette ページ ポートレット・パレットへの読み取り専用アクセス。 ユーザーは、ポートレット・パレットからページにポートレットをドラッグできますが、ポートレット・パレットを変更またはカスタマイズすることはできません。
Privileged User@portlet、 Privileged User@Portlet Palette ページ ユーザー役割のすべての特権、および「パーソナライズ」モードの場合はポートレット・パレットの私用ビューをカスタマイズする機能。 以下のタスクを実行できます。
  • ポートレットをカテゴリーに追加する
  • カテゴリーを作成する
  • ポートレットを検索する
  • カテゴリーを再配列する
  • ポートレットを別のカテゴリーにコピーする
  • ポートレットを複数のカテゴリーにコピーする
  • 作成するカテゴリーを名前変更する
  • 作成するカテゴリーを削除する
  • カテゴリーを追加するポートレットを削除する
  • 別のカテゴリーにコピーするポートレットを削除する
注: 「共用設定の編集」および「構成」モードで作成されたポートレットまたはカテゴリーは削除できません。
Editor@portlet、 Editor@Portlet Palette ページ ユーザー役割のすべての特権、および「共用設定の編集」モードの場合はポートレット・パレットをカスタマイズする機能。 変更は、この特定のページに対するアクセスを持つすべてのユーザーに表示されます。 「共用設定の編集」モードの場合は、以下のタスクを実行できます。
  • ポートレットをカテゴリーに追加する
  • カテゴリーを作成する
  • ポートレットを検索する
  • カテゴリーを再配列する
  • ポートレットを別のカテゴリーにコピーする
  • ポートレットを複数のカテゴリーにコピーする
  • 作成するカテゴリーを名前変更する
  • このモードで作成したカテゴリーを削除する
  • このモードで別のカテゴリーにコピーするポートレットを削除する
注:
  • パレットの個々のインスタンスをパーソナライズするには、ポートレット・パレットに対する特権ユーザー・アクセス役割も持っている必要があります。
  • 「共用設定の編集」モードの場合、ポートレットをページにドラッグできません。
  • 「構成」モードで作成されるポートレットまたはカテゴリーは削除できません。
Manager@portlet、 Manager@Portlet Palette ページ 編集者役割のすべての特権、および「構成」モードの場合はポートレット・パレットのすべてのページにおいてすべてのインスタンスを変更する機能。 「構成」モードの場合は、以下のタスクを実行できます。
  • ポートレットをカテゴリーに追加する
  • カテゴリーを作成する
  • ポートレットを検索する
  • カテゴリーを再配列する
  • ポートレットを別のカテゴリーにコピーする
  • ポートレットを複数のカテゴリーにコピーする
  • カテゴリーを名前変更する
  • カテゴリーを削除する
  • 別のカテゴリーにコピーするポートレットを削除する
注:
  • ポートレット・パレットの個々のインスタンスをパーソナライズするには、ポートレット・パレットに対する特権ユーザー・アクセス役割も持っている必要があります。
  • 「共用設定の編集」または「構成」モードの場合に、ポートレットをページにドラッグできません。
Administrator@portlet、 Administrator@Portlet Palette ページ 特権ユーザーおよび管理者役割のすべての特権。 アドミニストレーター役割は、「パーソナライズ」、「共用設定の編集」、および「構成」モードのタスクを実行できます。
注: 「共用設定の編集」または「構成」モードの場合に、ポートレットをページにドラッグできません。

ポートレット・ワイヤーの使用

ポートレット間で情報またはアクションを交換するには、ワイヤーを使用します。

このタスクについて

ワイヤリング・ツール・ポートレットにアクセスするには、以下を実行します。

手順

  1. ページの管理ポートレットにアクセスします。
  2. ワイヤーを追加するページを見つけます。
  3. そのページの「ページ・レイアウトの編集」アイコンをクリックします。 「レイアウトの編集」パネルが表示されます。
  4. 「ワイヤー」タブをクリックします。 以上で、ワイヤー操作を開始できるようになります。

ポートレット・ワイヤーに関する作業

ワイヤーにより、ポートレットが相互に対話できます。例えば、 ポートレット同士で情報を交換したり、あるポートレットのアクションで 別のポートレットを更新したりすることができます。

このタスクについて

ワイヤー により、複数のポートレットが情報を転送できるようになるため、 ソース・ポートレットでのアクション、公開イベント、またはクリックによってターゲット・ポートレットで自動的にアクションまたはイベントがトリガーされ、表示が更新されます。その結果、情報の変更時に、複数のポートレットを同時に更新できます。ワイヤーを作成できるのは、連携ポートレットとイベントを定義しているポートレット、すなわち他のポートレットと情報を共用するように開発されたポートレットの間だけです。「ワイヤー」ポートレットを最初に開いたときに、ページのすべての公開ワイヤーと個人用ワイヤーが表示されます。

ワイヤー・ポートレットは、以下のトピックで説明するタスクの 実行に使用します。ワイヤーの操作が終了したら、「完了」をクリックして変更内容を保存します。 最初に「ワイヤー」にアクセスしたページに戻ります。
注:
  1. ページ上のワイヤーを変更している間は、ページが非アクティブ化されます。
  2. ページの編集中は、すべての変更内容がただちに有効になります。更新内容を元に戻したりキャンセルしたりすることはできません。
  3. 他のユーザーは、「完了」をクリックして変更をコミットするまで、ページにアクセスすることはできません。
  4. ポートレットなどのポータル用語の詳細な説明については、ポータル・ページのヘルプを参照してください。

マッチング・モードの選択

ポートレット間のワイヤーを作成できる条件を決定する マッチング・モードを選択します。

このタスクについて

選択するマッチング・モードにより、ポートレットがサポートする意味体系およびペイロードのタイプに応じて、ソース・ポートレットとターゲット・ポートレットの間でワイヤーを作成できるかどうかが決まります。 ワイヤーを作成する前に、以下のいずれかのマッチング・モードを選択します。
マッチングするソースとターゲットの意味体系タイプのみ考慮する
このオプションを選択すると、ソース・ポートレットおよびターゲット・ポートレットに定義されたネーム・スペース意味体系タイプが一致する場合にワイヤーを作成できます。 ワイヤーを経由して移送される情報のペイロード・タイプは考慮されません。 例えば、このペイロード・タイプは java.lang.string または java.util.HashTable にすることができます。 これはデフォルトのマッチング・モードです。このモードは、バージョン 6.1 より前のポータル・バージョンに最もよく似ているモードです。
マッチングするソースとターゲットのペイロード・タイプのみ考慮する
このオプションでは、ソース・ポートレットおよびターゲット・ポートレットに定義されたネーム・スペース意味体系タイプに関係なく、ソースとターゲットのペイロード・タイプが一致する場合にワイヤーを作成できます。
マッチングするソースとターゲットの意味体系またはペイロードのタイプを考慮する
このオプションでは、ソース・ポートレットおよびターゲット・ポートレットのネーム・スペース意味体系タイプまたはペイロード・タイプが一致する場合にワイヤーを作成できます。 これは最も制限の緩いマッチング・モードです。

ワイヤーの追加

ワイヤーの追加方法について説明します。

このタスクについて

前提条件:
  1. クロスページ・ワイヤーを作成する場合は、ターゲット・ポートレットにグローバル・ターゲットが定義されていることを確認してください。詳しくはグローバル・ターゲットの定義を参照してください。
  2. ワイヤーを作成する前に、マッチング・モードを選択します。 マッチング・モードは、ワイヤーを作成できるかどうかを判別する条件を指定します。 詳しくは、マッチング・モードの選択を参照してください。
ワイヤーを作成するには、次の手順を実行します。

手順

  1. 新規ワイヤーを追加するテーブルで、以下のドロップダウン・リストのいずれかからオプションを選択します。
    ソース・ポートレット
    ページ上の他のポートレットに情報を送信するポートレット。 他のポートレットに情報を提供するページ上のポートレットのみを選択できます。
    送信
    ポートレットが送信可能な情報のタイプ。
    ターゲット・ページ
    通信ターゲットを含むページ。ドロップダウン・リストには、グローバル・ターゲットが定義されているピア・ページのみが含まれます。必要なページがリストされていない場合は、「続く」を選択して、必要なページを選択するかターゲット・ページを検索します。
    注: グローバル・ターゲットが定義されていないターゲット・ページが、クロスページ・ワイヤーに対して選択されている場合、ターゲット・ポートレットまたは通信ターゲットを選択することはできません。
    ページの切り替え
    このフラグは、クロスページ・ワイヤーにのみ関係します。ワイヤーのターゲット・ページへのリダイレクトを使用不可または使用可能にする場合は、これを使用します。このフラグは、ワイヤー・ターゲット・アクションまたはイベントの実際の処理には影響しません。 異なるページを指す複数のクロスページ・ワイヤーが同時に呼び出される場合は、これらの内の 1 つだけにページの切り替えフラグを設定するようにしてください。 ユーザーの誘導先のターゲット・ページを明確に決定する場合は、この設定を行う必要があります。
    ターゲット・ポートレット
    ソースから情報を受信するポートレット。 送信情報を処理できるポートレットのみが表示されます。
    受信
    情報を受信した後にポートレットが実行できるアクション、またはポートレットが処理できるイベント。選択した情報を処理できるアクションのみが表示されます。
  2. オプション: 代わりに、個人用の専用ワイヤーを作成するよう選択することもできます。 デフォルトで作成されるワイヤーは、すべてのユーザー向けの公開ワイヤーです。ただしこれは、作成者が必要な特権を持っている場合に限ります。公開ワイヤーの作成に必要な特権がない場合は、専用ワイヤーのみ作成できます。
  3. 変更が終了したら、「新規ワイヤーの追加」アイコンをクリックします。ページのワイヤーを編集するたびに、そのページ上のすべてのワイヤーのリストに新規ワイヤーが表示されます。

ワイヤーの削除

ワイヤーの削除方法について説明します。

このタスクについて

ワイヤーを削除するには、次の手順を実行します。

手順

  1. 削除するワイヤーの行で、「削除」アイコンをクリックします。 ワイヤーを削除するかどうかを確認するメッセージが表示されます。
  2. 「OK」をクリックします。リストからワイヤーが削除されます。

グローバル・ターゲットの定義

グローバル・ターゲットの定義方法を学習します。

このタスクについて

クロス・ページ・ワイヤーによって、ポートレットは各ページ間でプロパティーの交換ができるようになります。 クロスページ・ワイヤーを 作成する前に、ターゲット・ページの通信ターゲットを、そのポートレットでグローバルと 定義する必要があります。ターゲットをグローバルとして定義することにより、そのターゲットは Click-to-Action メニューでも使えるようになります。 ターゲット・ページにグローバル・ターゲットを設定するには、以下の手順を実行します。

手順

  1. ポータルのターゲット・ページへナビゲートします。
  2. 「ページの編集」を選択します。
  3. 「ワイヤー」タブを選択します。
  4. 「グローバル・ターゲットの定義...」ボタンをクリックします。
  5. 「グローバル」を選択して、ポートレット上の通信ターゲットを、ワイヤーおよび他のページの連携ポートレットの Click-to-Action メニューで使用できるようにします。
  6. 「OK」をクリックして通信ターゲットを使用可能にします。
  7. クロスページ・ワイヤーの追加方法について詳しくは、ワイヤーの追加を参照してください。

次のタスク

ポータル・サイトの設計とセットアップ

WebSphere Portal 7 には、改良されたページ・ビルダーと改良されたクライアント・サイド・レンダリングが用意されており、新規デフォルト・ポータル・テーマである、「ページ・ビルダー」テーマがあります。 テーマは、ポータル・サイトの外観を定義します。 インストールの後、デフォルト・テーマがデプロイされ、そのテーマをカスタマイズしたり、独自のテーマを作成したりすることができます。 7 で新しく導入されたテーマのアプローチでは、JSP の編集作業が軽減され、iWidget とポートレットを同じポータル・ページ上で混用することができ、クライアント・サイドとサーバー・サイドの両方のレンダリング・モードを利用できます。 WebSphere Portal 7 は、ユーザーのカスタム・テーマを含め、その他のテーマも引き続きサポートしています。 既存のポータル・サイトがある場合は、既存のテーマを引き続き使用することも、テーマを新しい標準にマイグレーションすることも可能です。

ヒント: サーバーを再起動せずに変更内容を表示するには、『自動 JSP 再ロードの使用可能化』のセクションで説明されているステップに従ってください。
次のリストに、WebSphere Portal バージョン 7.0 で使用可能かつサポートされるテーマを示します。
ページ・ビルダー」テーマ
このテーマは、ポータルと同梱で、ポータルのデフォルト・テーマとしてデプロイされます。
パンくず - フリー・フォーム・レイアウト
パンくず - 列レイアウト
これらのテーマはポータルと同梱で、サポート対象ですが、インストールはされません。 これらのテーマを使用できるようにするには、構成タスク deploy-portal-mashup-ui を実行する必要があります。
タブ・メニュー - ページ・ビルダーtheme
Portal Web2 テーマ
これらのテーマはポータルと同梱で、サポート対象ですが、インストールはされません。 これらのテーマを使用できるようにするには、これらをデプロイする必要があります。 これらは、ディレクトリー PortalServer_root/installer/wp.ear/installableApps/wps_theme.ear/wps_theme.war/themes/html にあります。
IBM テーマ
Portal V 6.0.x からのその他のテーマ
これらのテーマもサポート対象ですが、Portal バージョン 7.0 と同梱ではありません。
ユーザー独自のカスタム・テーマ

ページ・ビルダーのテーマおよびスキンを使用したサイトの設計

IBM WebSphere Portal バージョン 7.0 では、 ページとテーマのアーキテクチャーが導入され、同じポータル・ページ上で iWidget とポートレットを混合したり、 クライアント・サイドとサーバー・サイドの両方のレンダリング・モードを利用したりすることができます。 これによって、テーマの作成および編集を単純化することができます。

新規アーキテクチャーの概要を以下に示します。
  • 静的ページは簡潔な HTML を使用します。これには、ポートレットや iWidget などの 動的コンテンツのプレースホルダーを含めることができます。ユーザーが選択した HTML エディター・ツールを使用して、静的ページの作成や編集を行うことができます。
  • ページ・ビルダー」テーマにより、 ポートレットおよび iWidget が含まれる静的ページのレンダリングや編集を 行うことができます。このテーマでは、各ページに対して、ページのレンダリングが クライアント・サイド集約モードで行われるのか、サーバー・サイド集約モードで行われるのかを 構成することができます。ページのエディター権限を持つユーザーは、クライアント・サイド・モードと サーバー・サイド・モードでページを切り替えることができます。「ページ・ビルダー」テーマは、 簡潔な HTML ファイルで構成されます。これは、ユーザーが選択した HTML エディター・ツールを使用して カスタマイズできます。ポータルはいくつかのインクルード・ファイルを提供します。 このファイルを使用して、ページの開始および編集のロジックを追加することができます。
  • ポートレットおよび iWidget を使用して、静的ページにアプリケーション・ロジックを 追加できます。JSR168 および 286 は、ポートレットの標準を定義し、 iWidget 仕様 2.0 は iWidget を定義します。ポートレットと iWidget はどちらも自己完結のアプリケーション・ロジックで、 柔軟に開発、デプロイ、および使用することができます。コードのタイプと実行とを区別する必要があります。
    • ポートレットは Java コードとして記述されます。 これらは、サーバー・サイドのポートレット・コンテナーで実行されるように設計されます。 クライアント・サイドの実行でレンダリングが行われる場合は、 ポータルはそれらを、ブラウザーで実行可能な iWidget マークアップに変換します。
    • iWidget は Javascript ロジックとして記述されます。これらは、クライアント・サイドの ブラウザーで実行するように設計されます。サーバー・サイドで実行する場合は、 ポータルは iWidget をポートレットにラップします。

ページ・ビルダーのテーマ

ページ・ビルダーのテーマを使用することにより、 ポータル・ページを短時間で作成、カスタマイズ、共用することができます。 テーマ、テーマ・リソース、ウィジェット、およびポートレットの操作方法とカスタマイズ方法について学習します。

テーマに関する作業

ポータル・テーマは一連の要件を満たしている必要があります。

テーマの最小要件は以下のとおりです。
  • テーマはポータル・データベースに登録されている必要があります。
  • テーマには、このテーマが割り当てられているページをレンダリングするために ポータル・サーバーが呼び出す Default.jsp が含まれている必要があります。
Default.jsp が実行されると、テーマは以下を実行する必要があります。
  • HTML または他のマークアップによって指定されたページの構成、ヘッド、および 本文のセクションの初期化
  • テーマまたは Javascript や CSS などのページ・コンテンツで必要な共通リソースのロード
  • ページのバナーやフッターなどのサイトの構成のレンダリング
  • サイト内でページ間をナビゲートする方法をユーザーに提供するためのナビゲーションのレンダリング
  • 現在のページのコンテンツのレンダリング。
従来は、テーマはこれらの要件を満たすために、JSP および関連テクノロジーを 使用していました。JSP や他の J2EE 成果物での作業を必要とせずに、静的 HTML、CSS、および Javascript と連動するテーマを実装する方法を提供するための、 静的ベースのテーマ・エレメントが導入されました。
注: WebSphere Portal バージョン 7 以降のバージョンでは、 テーマとスキンを作成、更新、および削除するにはテーマの管理権限が必要です。 詳しくは、アクセス権についてのポータル Information Center のトピックを参照してください。
テーマのエレメント<