| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
 前へ |
 次 |
ホーム > Content Server開発者ガイド > コンテンツ・サーバー・インタフェースのカスタマイズ
| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
前へ |
次 |
ホーム > Content Server開発者ガイド > コンテンツ・サーバー・インタフェースのカスタマイズ
この章では、Oracle WebCenter Content Serverインタフェースのルック・アンド・フィールのカスタマイズに使用できる様々な方法について説明します。ユーザー・インタフェースの外観を変更する場合はスキンとレイアウトを使用し、ナビゲーションを変更する場合は動的サーバー・ページを変更します。
この章では、次の項目について説明します。
|
ヒント: この章で説明されている方法以外の方法でも、ユーザーに提示されるメタデータ・フィールドを変更したり、チェックイン・ページや検索ページなどのユーザー・インタフェースで使用されるプレゼンテーションのタイプを変更できます。メタデータ・フィールドの作成と変更、およびコンテンツ・プロファイルの作成については、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のリポジトリ・コンテンツの管理に関する項を参照してください。 |
スキンとレイアウトは、代替色スキームと代替ナビゲーション設計を実現しています。
Oracle WebCenter Content Serverには、いくつかのスキンとレイアウトがデフォルトで同梱されています。さらに、カスタム・スキンとカスタム・レイアウトを設計することもできます。スキンまたはレイアウトを変更するときには、インタフェースのルック・アンド・フィールを変更します。スキンとレイアウトは、「ユーザー・プロファイル」ページに用意されているオプションから選択できます。
スキンまたはレイアウトを作成および変更するには、HTML、カスケード・スタイル・シートおよびJavaScriptを理解してさえいれば十分です。外観の変更後、編集されたレイアウトおよびスキンがパブリッシュされ、同じ環境内にいる他のユーザーが使用できるようになります。
|
注意: 新規スキンまたはカスタム・スキンを作成できるのは管理者のみです。ユーザー・インタフェースのデフォルトのルック・アンド・フィールの設定の詳細は、第3.3項「新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成」を参照してください。 |
スキンによって、色スキームが定義され、さらに、グラフィック、フォント、フォント・サイズなど、レイアウトの外観の他の面が定義されます。(デフォルトのスキンはOracle)。カスタム・スキンを設計したり、既存のスキンを変更できます。
代替色スキームを実現する別のスキン、または代替ナビゲーション設計を実現する別のレイアウト、あるいはその両方を選択できます。
「ユーザー・プロファイル」ページで利用可能なユーザー・パーソナライズ設定を使用すると、ユーザーは、コンテンツ・サーバーのレイアウト、またはスキンを変更できます。
|
重要: このパーソナライズ機能は、Internet Explorerの7以上、またはMozilla Firefoxの3以上のバージョンで使用できます。 |
別のスキンまたはレイアウトを選択する手順は次のとおりです。
コンテンツ・サーバーの「ホーム」ページのトップ・メニュー・バーで、your_user_nameをクリックします。
「ユーザー・プロファイル」ページが表示されます。
目的のスキンおよびレイアウトを選択します。
「更新」をクリックして変更を表示します。
コンテンツ・サーバーのインスタンスのデフォルトの動作を変更するために、次に示す値をIntradocDir/config/config.cfgファイルに配置できます。
LmDefaultSkin: ゲストおよび新規ユーザーによって使用されるスキンの名前。デフォルトは「Oracle」です。
LmDefaultLayout: ゲストおよび新規ユーザーによって使用されるレイアウトの名前。デフォルトは「トレイ」ですが、「トップ・メニュー」に設定することもできます。
「トップ・メニュー」レイアウトと「トレイ」レイアウトは、デフォルトでシステムに含まれています。この2つのレイアウトには、2つのスキン・オプション(「Oracle」と「Oracle2」)があります。レイアウトはJavaScriptで記述されており、スキンのルックはカスケード・スタイル・シートを使用して作成されます。
コンテンツ・サーバーに付属しているテンプレート・ファイルを変更してスキンおよびレイアウトを変更することも、他のユーザーと共有可能なコンポーネントを作成して新規のスキンおよびレイアウトを設計することもできます。
コンテンツ・サーバーが起動するか、またはPUBLISH_WEBLAYOUT_FILESサービスが実行されると、std_resource.htmファイルにあるPublishedWeblayoutFiles表が使用され、ファイルがweblayoutディレクトリにパブリッシュされます。このパブリッシュ・メカニズムをカスタム・コンポーネントで使用するようにするには、テンプレートを作成し、そのテンプレートを使用するカスタム行をPublishedWeblayoutFiles表にマージします。
他のユーザーのファイルを変更またはカスタマイズする場合は、そのユーザーのテンプレート、またはPublishedWeblayoutFiles表にあるそのユーザーの行を無効にできます。他のユーザーのテンプレートでリソース・インクルードが使用されている場合は、それらのインクルードをいずれも無効にするか、または標準的なsuper表記法を使用して独自のIdocスクリプト・コードを挿入することができます。コンポーネントが無効になっていると、ファイルはパブリッシュも変更もされなくなり、コンテンツ・サーバーはそのデフォルトの状態に戻ります。
自分の作成したものに対する変更および追加を、他のユーザーが簡単にできるようにすることに加え、Idocスクリプトを使用して、以前は静的だったこれらのファイルを構成することもできます。たとえば、カスタム構成フラグの値に応じてファイルが変更されるようにすることができます。Idocスクリプトのカスタム機能を記述し、自分のテンプレート内から参照することによって、コンテンツ・サーバーのコアなオブジェクトおよび機能を使用できます。
このIdocスクリプトはパブリッシュ時に一度評価されるため、IdcHomeDir/resources/core/idoc/std_page.idocファイルから通常使用するようにはIdocスクリプトを使用できません。ユーザーがそのファイルを要求した時点では、すでに作成されているため、作成に使用されたスクリプトは、現在のサービスのDataBinderオブジェクトにも、現在のユーザーに関するいずれの情報にもアクセスできませんでした。
これにより、これらのファイルで記述できるIdocスクリプトのタイプが制限されます。ユーザーまたはサービスとともに動的に変化する情報を必要とするCSSまたはJavaScriptを記述する場合は、このコードを必要とするページにコード・インラインを含めることを検討してください。これにより、Webサーバーによって配信されるページのサイズが増えるため、使用される帯域幅の量が増えます。
匿名のランダム・ユーザーのインタフェースを変更するには、ExtranetLookコンポーネントを使用できます。この例としては、コンテンツ・サーバーをベースにしたWebサイトを、外部の顧客がログインなしで利用できるようにする必要があるが、そのWebサイトに自社の従業員が投稿できるようにしたい場合が挙げられます。
コンテンツ・サーバーがOracle WebLogic Serverで実行中の場合は、ExtranetLookコンポーネントによって、特定のページでの権限が変更され、アクセスするには書込み権限が必要となります。またこのコンポーネントでは、静的ポータル・ページを少し変更して、匿名のランダム・ユーザーに見せないリンクを除去することも行われます。
|
注意: ExtranetLookコンポーネントでは、Oracle WebLogic Serverにフォームベースの認証を提供したり、カスタマイズ可能なエラー・ページを提供することもありません。 |
ExtranetLookコンポーネントは、コンテンツ・サーバーとともにインストールされています。このコンポーネントを使用するには、コンポーネント・マネージャを使用して有効にする必要があります。
Webページをカスタマイズして顧客がコンテンツを簡単に検索できるようにしたり、従業員にログインを付与してログイン時にインタフェースを表示できるようにすることができます。カスタマイズを行うには、ExtranetLook.idocファイルを変更して、ユーザー・ログインに基づいてカスタマイズできる動的リソース・インクルードを提供します。IDOCファイルは、コンテンツ・サーバーのリポジトリにチェックインされるため、コンテンツ・サーバーのテンプレートによって参照できます。
コンテンツ・サーバーのWebサイトの匿名ユーザー・インタフェースのルック・アンド・フィールを更新するには、IntradocDir/data/usersディレクトリに格納されている次のファイルを変更します。
prompt_login.htm
access_denied.htm
report_error.htm
匿名ユーザー・インタフェースを変更する手順は次のとおりです。
Webレイアウト・エディタを表示します。
「オプション」メニューから「ポータルの更新」を選択します。
ポータル・ページを目的どおりに変更します。動的リソース・インクルードを使用して、このページをカスタマイズできます。
「OK」をクリックします。
ExtranetLook.idocファイルを目的どおりにカスタマイズします。
コンテンツ・サーバーからExtranetLookコンテンツをチェックアウトします。
改訂されたExtranetLook.idocファイルをコンテンツ・サーバーにチェックインします。
コンテンツ・サーバーのログイン・ページのURLは、そのコンテキスト・ルート(通常は/cs/)を変更することによって変更できます。HttpRelativeWebRootプロパティを使用して相対コンテキスト・ルートを設定してもURLは変更できません。それは、ログイン・ページにはこのプロパティの値が適用されないためです。ユーザーがログインするWebロケーションを変更する必要がある場合は、デプロイ・プランを使用してWebCenter Contentアプリケーションを再デプロイできます。
ログイン・ページのURLを変更する手順は次のとおりです。
WebCenter Contentがデプロイされているドメインの管理者として、Oracle WebLogic Server管理コンソールにログインします。
左側の「ドメイン構造」領域で、ドメインの名前で「デプロイメント」をクリックします。「デプロイメントのサマリー」ページの「制御」タブにある「デプロイメント」表の「Oracle WebCenter Content - コンテンツ・サーバー」をクリックします。
このアプリケーションは、表の2ページ目か3ページ目にある場合もあります。
デプロイ・プランへのパスを書き留めます。
WebCenter Contentインスタンスのプランが指定されていない場合は、次のようにして作成できます。
「Oracle WebCenter Content - コンテンツ・サーバー」ページの「設定」で「構成」をクリックします。
「構成」タブ上の任意のパラメータの値を変更します。
「保存」をクリックします。
「デプロイメント・プランの保存」ページでデプロイ・プロセスへのパスを確定するか、またはパスを変更します。
「OK」をクリックします。
テキスト・エディタで、次のように、デプロイ・プランの2箇所に行を追加します。
original_loginpage_path変数とoriginal_loginerror_path変数を、それぞれ<variable-definition>要素の<variable>要素に追加します。この例では次のようになります。
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>ServletPlugin</application-name>
<variable-definition>
<variable>
<name>original_loginpage_path</name>
<value>/content/login/login.htm</value>
</variable>
<variable>
<name>original_loginerror_path</name>
<value>/content/login/error.htm</value>
</variable>
<variable>
<name>SessionDescriptor_timeoutSecs_12996472139160</name>
<value>3600</value>
</variable>
cs.warファイルのweb.xmlの<module-descriptor>要素に、2つの<variable-assignment>要素を追加します。これらの要素によって、original_loginpage_path変数とoriginal_loginerror_path変数に、次の値がそれぞれ割り当てられます。
/web-app/login-config/form-login-config/form-login-page
/web-app/login-config/form-login-config/form-error-page
次に例を示します。
<module-override>
<module-name>cs.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
<variable-assignment>
<name>original_loginpage_path</name>
<xpath>/web-app/login-config/form-login-config/form-login-page</xpath>
</variable-assignment>
<variable-assignment>
<name>original_loginerror_path</name>
<xpath>/web-app/login-config/form-login-config/form-error-page</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
<module-override>
stopManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバー(デフォルトではUCM_server1)を停止します。
UNIXスクリプト:
DomainHome/bin/stopManagedWebLogic.sh UCM_server1
Windowsスクリプト:
DomainHome\bin\stopManagedWebLogic.cmd UCM_server1
管理コンソールで、ドメインの名前で「デプロイメント」をクリックします。
「デプロイメント」表で「Oracle WebCenter Content - コンテンツ・サーバー」を選択して、「更新」をクリックします。
「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」を選択し、デプロイ・プランへのパスが正しいことを確認して「終了」をクリックします。
再デプロイが正常に完了したら、「変更の適用」をクリックします。
startManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを起動します。
UNIXスクリプト:
DomainHome/bin/startManagedWebLogic.sh UCM_server1
Windowsスクリプト:
DomainHome\bin\startManagedWebLogic.cmd UCM_server1
管理コンソールで「デプロイメント」をクリックします。
「デプロイメント」表で「Oracle WebCenter Content - コンテンツ・サーバー」を選択して、「起動」メニューから「すべてのリクエストを処理」を選択します。
WebCenter Contentアプリケーションが起動したら、ログイン・ページのURLが変わったことを確認します。
新規レイアウトの作成およびパブリッシュに必要な一般的な手順は次のとおりです。
IdcHomeDir/resources/core/tables/std_publishing.htm内のLmLayouts表に表をマージして、新規レイアウトを定義します。レイアウトID、ラベル、および有効(1に設定)になっているかどうかを定義します。
IdcHomeDir/resources/core/tables/std_publishing.htm内のPublishedWeblayoutFiles表に表をマージします。この新しい表では、コンテンツ・サーバーのテンプレートから作成され、weblayoutディレクトリにプッシュアウトされたファイルについて説明します。それぞれのスキン・ディレクトリにプッシュアウトするために必要なskin.cssファイルを指定します。
std_publishing.htm内のPublishedStaticFiles表に表をマージします。ここには、imagesのように、weblayoutディレクトリにパブリッシュするファイルを含むディレクトリが一覧表示されています。
コンテンツ・サーバーに対し、パブリッシュされたファイルをバンドルして一括配信して、サーバーへのページ・リクエストの数を最小に抑えるように指示することができます。さらに、パブリッシュされたページを、Idocスクリプトを使用して参照することによって、ファイルを最適化できます。
複数のリソースをまとめて、バンドルというユニットにパッケージすることができます。バンドルとは、パブリッシュされたリソースを1つ以上含む単一のファイルです。JavaScriptとcssのリソースのみを、同じタイプの他のリソースのみとバンドルする必要があります。バンドルを行うと、ページがロードされたときのクライアントのオーバーヘッドを減らすことには役立ちますが、クライアント解析、コンパイルおよび実行オーバーヘッドは増えます。一般的には、類似したテーマを持つリソース、および同時に含まれると予想されるリソースをバンドルすることをお薦めします。たとえば、リソースA、BおよびCがあらゆるページで必要であり、リソースD、EおよびFはめったに必要とはならないが、必要となるときは一括して必要になるとわかっている場合は、A、BおよびCをまとめてバンドルし、D、EおよびFは別のバンドルに入れることをお薦めします。
コンテンツ・サーバーのコア向けJavaScriptリソースはほとんどすべて、2つのバンドルのいずれかにバンドルされます。1つはyuiBundle.jsで、これにはサードパーティであるYahooユーザー・インタフェース・ライブラリによって提供されるスクリプトが含まれ、もう1つはbundle.jsで、これにはそれ以外のリソースが含まれます。
リソースをどのようにバンドルするかを決定するには、PublishedBundles表が使用されます。本質的に、バンドルを識別するのは、そのターゲットであるbundlePath、すなわちバンドルへのパス名(weblayoutディレクトリへの相対パス)、およびどのリソース・クラスが含まれているか除外されているかを記述したルールのリストです。この表にあるloadOrderの値が適用されるのは、フィルタリング・ルールの適用順序であり、バンドルでのリソースの表示順序ではありません。
|
注意: Oracle Universal Content Management 10gでは、別の表を使用し、各バンドルでのリソースの順序を決定するloadOrderの値がありましたが、その後、バンドルは変化しました。 |
静的なweblayoutファイルの内容がクライアント・マシンおよびWebプロキシにキャッシュされ、それによって、使用されるサーバー帯域幅の量が大幅に減りました。そのため、ベスト・プラクティスとして、可能なかぎりこれらのタイプのファイルを使用してください。
ただし、クライアントのブラウザによって要求されるそれぞれの静的weblayoutファイルでは、そのファイルの最新バージョンがクライアントにあることを確認するためだけに、サーバーとの間で双方向通信を行う必要があります。これは、ファイルがキャッシュされている場合にも当てはまります。これらのファイルの数が増えると、ページ・リクエストごとにサーバーから行われるダウンロードの回数も増えます。
双方向通信の回数を最小に抑えるようにするため、コンテンツ・サーバーでは、パブリッシュされた複数のファイルをバンドルして、一括配信されるようにできます。この機能は、サーバーのIntradocDir/config/config.cfgファイルで次の構成を設定することで無効にできます。
BundlePublishedWeblayoutFiles=false
バンドルは、例3-1に示すように、std_publishing.htmファイル内のPublishedBundles表を使用することによって実行されます。
例3-1 std_publishing.htmファイル内のPublishedBundles表
<@table PublishedBundles@>
<table border=1><caption><strong>
<tr>
<td>bundlePath</td>
<td>includeClass</td>
<td>excludeClass</td>
<td>loadOrder</td>
</tr>
<tr>
<td>resources/bundle.js</td>
<td>javascript:common</td>
<td></td>
<td>128</td>
</tr>
. . .
</table>
<@end@>
この表の列は、次のとおりです。
bundlePath: バンドルがパブリッシュされる最終的な位置。このパスはweblayoutディレクトリに対する相対パスです。
includeClass: これは、どのリソースをバンドルに含めるかを決定するために使用されます。
excludeClass: これは、どのリソースをバンドルから除外するかを決定するために使用されます。
前の例では、javascript:commonクラスのファイルは、resources/layouts/commonBundle.jsにある単一のバンドルにパブリッシュされます。このクラスに一致する、バンドルされたすべてのファイルの内容が付加されて、その位置に格納される単一のファイルが形成されます。
パブリッシュされたファイルのほとんどは(バンドルされているものもいないものも含めて)、ページに含めるにはHTML内から直接参照できる必要があります。そのため、指定された状況でどのファイルを含めるかを把握することが難しくなることがあります。バンドルを有効にするか無効にするかをサーバー管理者が決められる場合は特にそうです。指定されたページに、必要なファイルのすべてを容易かつ透過的に含めるには、単純なIdocスクリプト・メソッドを使用できます。
たとえば、(前述したように)javascript:commonバンドルに関連付けられているファイルをすべて含むページを記述していて、2番目の表に記述されているバンドルに加えて、最初の表に記述されているファイルのすべてを含むHTMLを記述していない場合は、ファイルごとにサーバーに尋ねられます。これではバンドルの目的が否定されます。ファイルごとに、実際に存在しているかどうかがサーバーに対してpingされるからです。
例3-2に、あるページのHEADセクション内のIdocスクリプト・コードを示します。このコードでは、ページ上のこれらのファイルが含まれます。
例3-2 ファイルのバンドルを参照するためのIdocスクリプト
<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>
ここに抜粋したコードでは、バンドルがオフになっていても、javascript:commonファイルがすべて含まれます。javascript:commonでなくjavascriptが渡された場合は、javascriptをクラスの先頭とするファイルがすべて含まれます。
このPublishedResources結果セットはloadOrderでソートされるため、loadOrderが最も低いファイルおよびバンドルが最初に含まれます。より大きなloadOrderを持つファイルでは、それ以前に宣言されていたJavaScriptメソッドまたはCSSスタイルが無効になります。
