| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 12c (12.2.1.3.0) E90143-05 |
|
 前 |
 次 |
この章では、Oracle WebCenter Content Serverインタフェースのルック・アンド・フィールのカスタマイズに使用できる様々な方法について説明します。ユーザー・インタフェースの外観を変更する場合はスキンとレイアウトを使用し、ナビゲーションを変更する場合は動的サーバー・ページを変更します。
この章の内容は次のとおりです。
注意:
この章で説明されている方法以外の方法でも、ユーザーに提示されるメタデータ・フィールドを変更したり、チェックイン・ページや検索ページなどのユーザー・インタフェースで使用されるプレゼンテーションのタイプを変更できます。メタデータ・フィールドの作成と変更、およびコンテンツ・プロファイルの作成の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のリポジトリ・フィールドとメタデータのカスタマイズに関する項およびコンテンツ・プロファイルの管理に関する項を参照してください。
スキンとレイアウトにより、代替の色スキームと代替のナビゲーション・デザインを用意できます。コンテンツ・サーバーのインタフェースは、スキンやレイアウトを変更することでカスタマイズできます。
コンテンツ・サーバーのナビゲーション・システムは、メニュー・バーとツリー・ビューの組合せで構成されます。これは、ユーザーが使用しているレイアウト(「トップ・メニュー」または「トレイ」)に基づいた組合せになります。デフォルトのレイアウトは「トレイ」です。このレイアウトでは、ページの左側にメニュー・タイトルのリストとオプションが表示されます。事前定義済の「トップ・メニュー」レイアウトでは、これらのオプションがページの上部に沿ったメニュー・バーで選択できるようになります。
コンテンツ・サーバーには、いくつかのスキンとレイアウトがデフォルトで同梱されています。さらに、カスタム・スキンとカスタム・レイアウトを設計することもできます。スキンまたはレイアウトを変更するときには、インタフェースのルック・アンド・フィールを変更します。スキンとレイアウトは、「ユーザー・プロファイル」ページに用意されているオプションから選択できます。
スキンまたはレイアウトを作成および変更するには、HTML、カスケード・スタイル・シートおよびJavaScriptを理解してさえいれば十分です。外観の変更後、編集されたレイアウトおよびスキンがパブリッシュされ、同じ環境内にいる他のユーザーが使用できるようになります。
注意:
新規スキンまたはカスタム・スキンを作成できるのは管理者のみです。ユーザー・インタフェースのデフォルトのルック・アンド・フィールの設定の詳細は、「新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成」を参照してください。
スキンによって、色スキームが定義され、さらに、グラフィック、フォント、フォント・サイズなど、レイアウトの外観の他の面が定義されます。カスタム・スキンを設計したり、既存のスキンを変更できます。
コンテンツ・サーバーには次の2つの既存のスキンがあります。
Oracle (デフォルトのスキン)
Oracle2
レイアウトによって、ナビゲーション階層表示が定義され(デフォルトのレイアウトは「トレイ」)、カスタム・レイアウトを設計できます。カスタム・レイアウトによって、システム全体の動作とルック・アンド・フィールが変更されます。変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。用意されているレイアウトは次のとおりです。
トレイ: 標準的なOracleスキンを備えたこのレイアウトが、デフォルトのインタフェースです。高水準のナビゲーションは、ナビゲーション・トレイを通じて実現します。
トップ・メニュー: このレイアウトでは、ナビゲーションを提供するトップ・メニューを備えた代替ルックが実現します。
ほとんどのメニュー・アイテムはデータから生成されます。その後で、メニューにJavaScriptのフックを組み込みます。各ユーザーは、ユーザーごとのナビゲーション・リンクを生成するパーソナライズされたJavaScriptファイルを取得します。
代替色スキームを実現する別のスキン、または代替ナビゲーション設計を実現する別のレイアウト、あるいはその両方を選択できます。
ユーザー・プロファイルページで利用可能なユーザー・パーソナライズ設定を使用すると、ユーザーは、コンテンツ・サーバーのレイアウト、またはスキンを変更できます。
注意:
このパーソナライズ機能は、Internet Explorerの7以上、またはMozilla Firefoxの3以上のバージョンで使用できます。
別のスキンまたはレイアウトを選択する手順は次のとおりです。
別のスキンまたはレイアウトを選択した後は、ログインするたびに、そのスキンまたはレイアウトがコンテンツ・サーバーのユーザー・インタフェースとなります。
コンテンツ・サーバーのインスタンスのデフォルトの動作を変更するために、次に示す値を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サーバーによって配信されるページのサイズが増えるため、使用される帯域幅の量が増えます。
次のナビゲーション・エンジン参照では、「ナビゲーション」メニューまたはトレイに追加するために使用できるデータを示します。このデータを使用して、コンテンツ・サーバー・ナビゲーションをカスタマイズする方法の詳細は、「カスタム・コンポーネントの作成」を参照してください。
次の項では、各表が何のためにあるか、各列が何をするかを含め、コンテンツ・サーバー・ナビゲーションの動的データ表リソース(dynamicdata表)を説明します。
このdynamicdata表では、各メニュー・アイテムの基本情報を定義します。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
メニュー・アイテムのラベルを指定します。ローカライズされた文字列のキーとIdocScriptはここで受入れ可能です。 |
|
最終リンクを作成するために |
|
このリンクのデータを指定します。 |
このdynamicdata表では、コア・ナビゲーション・システムのメニューが相互にどのように関連するかを定義しています。この表では、各アイテムがそれぞれの親との関係でどこにあるべきか、および兄弟との関係でどこにあるべきかの両方を示します。
| 列 | 説明 |
|---|---|
|
親メニュー・アイテムのIDを指定します。ノードが最上位レベルのノードの場合、ここでは「 |
|
メニュー・アイテムのIDを指定します。 |
|
メニュー・アイテムのロード順序を指定します。兄弟のメニュー・アイテムはこの順序でロードされます。 |
このdynamicdata表では、メニュー・アイテムのフラグを定義します。また、「フラグのリスト」も参照してください。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
このメニュー・アイテムのフラグのコロン区切りリストを指定します。 |
このdynamicdata表では、「トレイ」レイアウト内にある際のメニュー・アイテムのイメージを定義します。指定しない場合にはデフォルトのイメージが使用されるため、すべてのアイテムにイメージを定義する必要はありません。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
メニュー・アイテムの横に表示するイメージを指定し、さらに閉じられているときフォルダ・アイテムの横に表示するイメージも指定します。 |
|
開いているときにメニュー・アイテムの横に表示するイメージを指定します。 |
このdynamicdata表では、メニュー・アイテムの動的ロード・コールバックであるJavaScript関数を定義します。これは、「トレイ」レイアウト内でのみ動作します。メニュー・アイテムが開かれると、関数がコールされます。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
動的ロード・コールバックとして適用するJavaScript関数を指定します。関数を返して終わるかぎり、任意のJavaScriptをここに配置することもできます。 |
このdynamicdata表では、メニュー・アイテムの出口URLを定義します。出口URLは、パラメータに追加されます(指定された場合)。この特化表はほとんどの場合、必要ありません。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
最終出口リンクを作成するために |
|
この出口リンクのデータを指定します(CoreMenuItemsの |
このdynamicdata表では、メニュー・アイテムのトレイ・ドキュメントURLを定義します。これは、「トレイ」レイアウト内でのみ動作します。トレイ・ドキュメントURLは最上位レベル・トレイ・ノードに追加することができ、これは、標準の子ノードではなく、このURLを使用してiframeを開きます。この特化表はほとんどの場合、必要ありません。
| 列 | 説明 |
|---|---|
|
メニュー・アイテムのIDを指定します。 |
|
最終トレイ・ドキュメント・リンクを作成するために |
|
このトレイ・ドキュメント・リンクのデータを指定します(CoreMenuItemsの |
LinkTypeは、最終URLを取得するためにLinkData値を操作する方法を決定するのに使用されます。次の表では、コアなLinkType値を示します。自分用のLinkType値を作成し、データをstd_compute_menu_linkまたはnavigation_modify_rset_menu_itemインクルードのいずれかから操作できます。
| LinkType値 | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
次の表のフラグは、CoreMenuItemsFlagsの行に追加して、メニュー・アイテムの動作を制御できます。複数フラグはコロンで区切ってください。
| フラグ | 説明 |
|---|---|
|
メニュー・アイテムは |
|
メニュー・アイテムは |
|
メニュー・アイテムは、ログインしているユーザーにのみ表示されます。 |
|
メニュー・アイテムは、ログインしていないユーザーにのみ表示されます。 |
|
メニュー・アイテムは、 |
|
メニュー・アイテムは、「自己登録」が有効な場合のみ表示されます。 |
|
メニュー・アイテムは、 |
|
メニュー・アイテムは、ユーザーがコントリビュータの場合のみ表示されます。 |
|
メニュー・アイテムは、ユーザーが1つ以上のグループの管理者の場合のみ表示されます。 |
|
メニュー・アイテムは、ユーザーが副管理者またはシステム管理者の場合のみ表示されます。 |
|
メニュー・アイテムは、ユーザーが管理者の場合のみ表示されます。 |
|
メニュー・アイテムは、ユーザーが副管理者の場合のみ表示されます。 |
|
メニュー・アイテムは、ユーザーがシステム管理者の場合のみ表示されます。 |
|
メニュー・アイテムは、コンテンツ・リファイナリがある場合のみ表示されます。 |
|
メニュー・アイテムは、Dynamic Converterが有効な場合のみ表示されます。 |
|
メニュー・アイテムは、JSPサーバーが有効な場合のみ表示されます。 |
|
メニュー・アイテムは、索引管理処理がある場合のみ表示されます。 |
|
メニュー・アイテムをグループとして設定します。アイテムは表示されませんが、このアイテムが親であるアイテムはすべて一緒にグループ化されます。 |
|
このメニュー・アイテムのターゲットを「 |
|
このメニュー・アイテムのターゲットを「 |
次の表の変数はメニューを作成した後に使用可能で、その場でメニューを変更できます。
| Javascript変数 | 説明 |
|---|---|
|
|
|
|
|
サイド・トレイの |
YUI APIを使用して、ノードにアクセスすることができます。メニューまたはメニュー・アイテム・ノードを取得するためのいくつかのヒントを次に示します。
YAHOO.idc.widget.TrayTreeViewオブジェクトには、変数oNodeListがあります。ノード自体に対するノードのIDを参照するオブジェクトです。このリストは起動後にすべて指定されますが、後で手動で更新する必要があります。 YAHOO.widget.MenuManagerを使用して、メニューおよびメニュー・アイテムに簡単にアクセスすることができ、これにはメソッドgetMenu()およびgetMenuItem()が含まれます。 MENU_?_」で始まり、この?は、'A'または'B'です(アイテムがどちらのメニューにあるかに依存します)。 11gメニュー・システムと古いNavBuilder APIの間には、一部、下位互換性があります。これは古いコンポーネントを動作させるためです。新しいコンポーネントでは、これらのメソッドは使用しないでください。次の表では、古いNavBuilder関数とそれらのサポートのレベルを示します。
| メソッド | 互換性 | 注意 |
|---|---|---|
|
一部 |
このメソッドの影響を受けるのは、 |
|
一部 |
このメソッドの影響を受けるのは、 |
|
フル |
|
|
フル |
|
|
一部 |
移動中のクローニングは使用できなくなりました。最上位レベル・コンテナ(つまり、 |
|
一部 |
移動中のクローニングは使用できなくなりました。このメソッドで、最上位レベルと下位レベルのアイテムを混在させることはできません。たとえば、トレイのノードを移動して最上位レベル・ノードにすることはできません。 |
|
なし |
XMLツリーは完全に使用されなくなったため、このメソッドは適用できません。 |
|
一部 |
YUIメニューからアイテムを削除し、親にアイテムがない場合でも、親は空であるにもかかわらず子があることを示します。 |
|
一部 |
YUIメニューの子を削除する場合、メニューは空であるにもかかわらず子があることを示します。 |
|
一部 |
このメソッドは、 |
|
なし |
XMLツリーは完全に使用されなくなったため、このメソッドは適用できません。 |
匿名のランダム・ユーザーのインタフェースを変更するには、ExtranetLookコンポーネントを使用できます。この例としては、コンテンツ・サーバーをベースにしたWebサイトを、外部の顧客がログインなしで利用できるようにする必要があるが、そのWebサイトに自社の従業員が投稿できるようにしたい場合があげられます。
コンテンツ・サーバーがOracle WebLogic Serverで実行中の場合は、ExtranetLookコンポーネントによって、特定のページでの権限が変更され、アクセスするには書込み権限が必要となります。またこのコンポーネントでは、静的ポータル・ページを少し変更して、匿名のランダム・ユーザーに見せないリンクを除去することも行われます。
注意:
ExtranetLookコンポーネントでは、Oracle WebLogic Serverにフォームベースの認証を提供したり、カスタマイズ可能なエラー・ページを提供することもありません。
ExtranetLookコンポーネントは、コンテンツ・サーバーとともにインストールされています。このコンポーネントを使用するには、コンポーネント・マネージャを使用して有効にする必要があります。
Webページをカスタマイズして顧客がコンテンツを簡単に検索できるようにしたり、従業員にログインを付与してログイン時にインタフェースを表示できるようにすることができます。カスタマイズを行うには、ExtranetLook.idocファイルを変更して、ユーザー・ログインに基づいてカスタマイズできる動的リソース・インクルードを提供します。IDOCファイルは、コンテンツ・サーバーのリポジトリにチェックインされるため、コンテンツ・サーバーのテンプレートによって参照できます。
IntradocDir/config/config.cfgファイルでIsWebServerPagesOnly構成変数がTRUEに設定されている場合、ExtranetLook Webサーバー・プラグインは、Webサーバー・フィルタによって作成された、カスタマイズされたバージョンのページを提供します。また、Cookieベースのログイン機能を無効にします。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のコンテンツ・サーバーの通信のカスタマイズに関する項を参照してください。
コンテンツ・サーバーのWebサイトの匿名ユーザー・インタフェースのルック・アンド・フィールを更新するには、IntradocDir/data/usersディレクトリに格納されている次のファイルを変更します。
prompt_login.htmaccess_denied.htmreport_error.htm匿名ユーザー・インタフェースを変更する手順は次のとおりです。
ExtranetLook.idocファイルを目的どおりにカスタマイズします。ExtranetLookコンテンツをチェックアウトします。ExtranetLook.idocファイルをコンテンツ・サーバーにチェックインします。ポータル・ページを変更し、ExtranetLook.idocファイルをカスタマイズした後は、ユーザーがログインせずにWebサイトにアクセスした場合に、その設計が常にコンテンツ・サーバーのユーザー・インタフェースとして機能します。
コンテンツ・サーバーのログイン・ページのURLは、そのコンテキスト・ルート(通常は/cs/)を変更することによって変更できます。HttpRelativeWebRootプロパティを使用して相対コンテキスト・ルートを設定してもURLは変更できません。それは、ログイン・ページにはこのプロパティの値が適用されないためです。ユーザーがログインするWebロケーションを変更する必要がある場合は、デプロイ・プランを使用してWebCenter Contentアプリケーションを再デプロイできます。
ログイン・ページのURLを変更する手順は次のとおりです。
このアプリケーションは、表の2ページ目か3ページ目にある場合もあります。
WebCenter Contentインスタンスのプランが指定されていない場合は、次のようにして作成できます。
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)を停止します。 DomainHome/bin/stopManagedWebLogic.sh UCM_server1 DomainHome\bin\stopManagedWebLogic.cmd UCM_server1startManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを起動します。 DomainHome/bin/startManagedWebLogic.sh UCM_server1 DomainHome\bin\startManagedWebLogic.cmd UCM_server1新規レイアウトの作成およびパブリッシュに必要な一般的なステップは次のとおりです。
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
バンドルは、{例 - std_publishing.htmファイル内のPublishedBundles表}に示すように、std_publishing.htmファイル内のPublishedBundles表を使用することによって実行されます。
前の例では、javascript:commonクラスのファイルは、resources/layouts/commonBundle.jsにある単一のバンドルにパブリッシュされます。このクラスに一致する、バンドルされたすべてのファイルの内容が付加されて、その位置に格納される単一のファイルが形成されます。
この表の列は、次のとおりです。
| PublishedBundles表の列 | 説明 |
|---|---|
bundlePath |
バンドルがパブリッシュされる最終的な位置。このパスはweblayoutディレクトリに対する相対パスです。 |
oMenuBarB |
menuBのYAHOO.widget.MenuBar。「トップ・メニュー」レイアウトにのみ存在します。 |
oTreeViewA |
サイド・トレイのYAHOO.idc.widget.TrayTreeView。「トレイ」レイアウトにのみ存在します。 |
Example - PublishedBundles Table in std_publishing.htm File <@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@>
パブリッシュされたファイルのほとんどは(バンドルされているものもいないものも含めて)、ページに含めるにはHTML内から直接参照できる必要があります。そのため、指定された状況でどのファイルを含めるかを把握することが難しくなることがあります。バンドルを有効にするか無効にするかをサーバー管理者が決められる場合は特にそうです。指定されたページに、必要なファイルのすべてを容易かつ透過的に含めるには、単純なIdocスクリプト・メソッドを使用できます。
たとえば、(前述したように)javascript:commonバンドルに関連付けられているファイルをすべて含むページを記述していて、2番目の表に記述されているバンドルに加えて、最初の表に記述されているファイルのすべてを含むHTMLを記述していない場合は、ファイルごとにサーバーに尋ねられます。これではバンドルの目的が否定されます。ファイルごとに、実際に存在しているかどうかがサーバーに対してpingされるからです。
{例 - ファイルのバンドルを参照するためのIdoc Script}に、あるページのHEADセクション内のIdoc Scriptコードを示します。このコードによって、これらのファイルがページに適切にインクルードされます。
ここに抜粋したコードでは、バンドルがオフになっていても、javascript:commonファイルがすべて含まれます。javascript:commonでなくjavascriptが渡された場合は、javascriptをクラスの先頭とするファイルがすべて含まれます。
このResultSet PublishedResourcesはloadOrderでソートされるため、loadOrderが最も低いファイルとバンドルが最初にインクルードされます。より大きなloadOrderを持つファイルでは、それ以前に宣言されていたJavaScriptメソッドまたはCSSスタイルが無効になります。
Example - Idoc Script to Reference a Bundle of Files
<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>
