| Oracle® WebCenter Content Site Studio for External Applications開発者ガイド 11g リリース1 (11.1.1) B72419-01 |
|
 前 |
 次 |
| Oracle® WebCenter Content Site Studio for External Applications開発者ガイド 11g リリース1 (11.1.1) B72419-01 |
|
前 |
次 |
Site Studioは、Webサイトの効率的な設計、構築およびメンテナンスを可能にする強力なツールのセットを提供します。これらのツールを最大限に活用するには、Site Studio Webサイトの基本概念を理解しておくと役に立ちます。
この項の内容は次のとおりです。
Site Studioを貴重なツールにしている要因の1つは、WebサイトのコンテンツをWebサイトのプレゼンテーションから完全に分離できることです。この分離により、誤ってサイトのレイアウト、デザインまたはルック・アンド・フィールに影響を与える心配なしで、1つのWebサイト上の情報を複数の人々が管理および担当することが可能になります。サイトのコンテンツの管理を割り当てられた人々が、必要に応じて変更を行うことができます。そのタスクを完了するために誰か他の人に変更内容を送信する必要はありません。これにより、多くのサイト管理シナリオに存在する、サイトに対するすべての変更を非常に限られた数のサイト管理者が処理する必要があるという重要なボトルネックが取り除かれます。
サイトのプレゼンテーションとコンテンツの分離を念頭に置いて、Webサイトに関連付けられるファイルを次の3つの主なカテゴリに分類できます。
Site Studio Webサイトに関連付けられるいくつかのファイルは、ページのレイアウトと書式の観点からサイトがどのように見えるかを定義するために使用されます。これらのファイルは、サイトのコンテンツの表示に使用するデザイン・フレームワークを提供します。これらのファイルに対する変更は通常はサイト全体(またはサイトの大きな部分)に影響し、これらのファイルは通常は専門のサイト設計者によって作成および管理されます。
Site Studioでは、サイトのプレゼンテーション用に次のファイルが使用されます。
ページ・テンプレート: Webページのレイアウトと高レベルのルック・アンド・フィールを定義する、完全に形成されたHTMLファイル。コントリビューション・リージョン(ページの編集可能な領域)、ナビゲーション・ツール(フラグメント形式)、サイト全体にわたるイメージ(バナーなど)の配置も含まれます。ページ・テンプレートは、最上位レベルのサイト設計オブジェクトです。詳細は、第2.12項「ページ・テンプレート」を参照してください。
リージョン・テンプレート: Webページ内のコントリビューション・リージョンのデータのレイアウトおよびルック・アンド・フィールを定義する、部分HTMLファイル(つまり、ヘッダー・セクションおよびボディ・セクションがない)。詳細は、第2.9項「リージョン・テンプレートとリージョン定義」を参照してください。
サブテンプレート: ページ・テンプレート上のプレースホルダに挿入して、独自のプレースホルダとコントリビューション・リージョンを持つさらに小さくて再利用可能な領域にページ・テンプレートを分割できる、部分HTMLファイル(つまり、ヘッダー・セクションおよびボディ・セクションがない)。詳細は、第2.11項「サブテンプレート」を参照してください。
サイトのプレゼンテーションに直接影響するこれらのファイルのほかに、Webサイトのプレゼンテーションに影響する構成ファイルもいくつかあります(「サイト制御および構成ファイル」を参照してください)。
サイトのコンテンツ(つまり、サイト上の実際の情報)は、それが表示されるプレゼンテーション・コンテキストとは別に管理される独立したファイルに保存されます。これにより、コンテンツを別個に管理してWebサイト内や異なるWebサイト間で再利用することが可能になります(それらのサイトがすべて同じコンテンツ・サーバーを使用して管理されていれば)。
Site Studioでは、サイトのコンテンツ用に次のファイルが使用されます。
コントリビュータ・データファイル: Site Studioによって生成されるXML形式のコンテンツ・ファイル。コントリビュータ・データファイルは、Site Studio Contributorアプリケーションを使用して編集します。詳細は、第2.13項「コントリビュータ・データファイルとネイティブ・ドキュメント」を参照してください。
ネイティブ・ドキュメント: Microsoft Wordのような使い慣れたサード・パーティ・アプリケーションを使用して作成されたコンテンツ・ファイル。ネイティブ・ドキュメントは、Dynamic Converterを使用してHTMLフォーマットに変換し、関連付けられたアプリケーションを使用して編集します。詳細は、第2.13項「コントリビュータ・データファイルとネイティブ・ドキュメント」を参照してください。
イメージ: 企業バナーや製品イメージなど、コンテンツ・ファイルまたはページ・テンプレートに含まれているグラフィック・ファイル(JPG、GIF、PNG)。
その他のメディア: Webサイト上で使用できるその他すべてのメディア・ファイル。Flashアニメーション、ビデオ・ファイル、オーディオ・ファイルなどがあります。
サイトのプレゼンテーションに直接影響するファイルのほかに、Webサイトのプレゼンテーションに影響する構成ファイルもいくつかあります。
Site Studioでは、サイトの制御と構成のために次のファイルが使用されます。
要素定義: 要素タイプの編集操作を定義するファイル。特に、コントリビュータが要素を編集するときに実行できる操作を指定します。詳細は、第2.8項「要素と要素定義」を参照してください。
リージョン定義: 特定タイプの要素を構成するコンテンツのタイプを定義するファイル。コントリビュータがコントリビューション・リージョンに対して使用可能なコンテンツの作成および切換えオプションの指定や、これらのリージョンに関連付けられたコンテンツ・ファイルのデフォルト・メタデータの設定もこのファイルで行います。詳細は、第2.9項「リージョン・テンプレートとリージョン定義」を参照してください。
プレースホルダ定義: 関連付けられたプレースホルダに許可されているリージョン定義、リージョン・テンプレートおよびサブテンプレートを定義するファイル。プレースホルダに対して許可されるコントリビュータ・アクションもこのファイルで指定します。詳細は、第2.10項「プレースホルダとプレースホルダ定義」を参照してください。
検証スクリプト: 一定の最大長を超えていないこと、不正な文字が含まれていないことなど、データが要件を満たしているかどうかを判断するための要素データの検証ルールを定義するJavaScriptファイル。
カスタム構成スクリプト: コントリビュータがカスタマイズされた編集操作を実行できるようにするJavaScriptファイル。デフォルトのContributorエディタ構成よりも優先されます。
カスタム要素フォーム: 特定のファイル・タイプの選択フォームなど、要素内で使用するカスタム・フォームを定義するHTMLファイル。Site Studioには、いくつかの事前定義済のカスタム要素フォームが付随しています。(これらのフォームは、Site Studioコンポーネントのインストール時にコンテンツ・サーバーにもチェックインされます。)
Site Studio Webサイトに関連するファイルはすべて、Oracle WebCenter Content Serverを使用して保存および管理されます。ファイルがどこでどのように使用されるかを指定するには、Site Studio専用のいくつかのカスタム・メタデータ・フィールドが使用されます。
図2-1 サイト・アセットの「コンテンツ情報」ページにあるSite Studio用メタデータ・フィールド
Site Studioでは、すべてのサイト関連ファイルについて次のメタデータ・フィールドが使用されます。
Webサイト・オブジェクト・タイプ: Webサイト用のファイルのタイプを指定します(「データファイル」、「スタイルシート」、「リージョン・テンプレート」、「プレースホルダ定義」など)。
Webサイト: ファイルが関連付けられているWebサイトをリストします。つまり、そのファイルはリストされている各サイトで使用できます(必ず使用する必要があるわけではありません)。1つのファイルを複数のWebサイトに関連付けることができます。これは、そのファイルをサイト間で再利用できるということを意味します。これにより、複数サイトの管理を効率化できます。
リストから除外: コントリビュータがWebサイト上の動的リストに特定のコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)を表示しないように指定したWebサイトをリストします。
Webサイト・セクション: コンテンツ・ファイルをデフォルトでWebサイト上のどこに表示するかを指定します(元のハイパーリンク内でターゲット・セクションが明示的に指定されていないかぎり)。
リージョン定義: リージョン・テンプレートまたはコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)が関連付けられているリージョン定義を指定します。これにより、ファイルがサイト上でどのように表示されるかと、どのコントリビュータがそれを許可されるかが決まります。リージョン・テンプレートとコンテンツ・ファイルに関連付けることのできるリージョン定義はそれぞれ1つのみですが、1つのリージョン定義に複数のリージョン・テンプレートおよびコンテンツ・ファイルを関連付けることは可能です。
一部のフィールドはファイルが作成されてコンテンツ・サーバーにチェックインされるときに自動的に設定されるという点に注意してください。また、すべてのサイト・アセットですべてのメタデータ・フィールドが使用されるわけではありません。アセットによっては該当しないフィールドもあるためです。たとえば、xRegionDefinitionメタデータ・フィールドはページ・テンプレートには使用されません。ページ・テンプレートはリージョン定義とは関連付けられないためです。
これらのフィールドの値は、ファイルのコンテンツ情報ページで変更できますが、フィールド値の変更は、そのファイルがサイト上でどのように使用されるかに影響するため、変更には注意が必要です。
組織内でWebサイトの作成や管理のために様々なロールを決定するときには、Webサイトの作成における特定のタスクに各ロールの焦点を合わせることができます。
設計者は、Webサイトの外観に焦点を合せます。つまり、ページの構造、ページのレイアウト、デザインおよび企業の特色などに集中します。
コントリビュータは、ページに関するコーディングを行う必要なしで、ページ上にコンテンツを配置できます。コントリビュータはその後、ページの外観に影響を与えずに、そしてWebサイトの複数の領域に対して複数の変更を加える必要なしで、コンテンツの更新や編集を行うことができます。設計者は、コンテンツの制御をほとんど行いません。コントリビュータは、サイト上にコンテンツがどのように表示されるかをほとんど制御しません。
Site Studioでは、図2-2に示すように、Webサイトのプレゼンテーション・レイヤーとコンテンツ・レイヤーが完全に分離されています。
ページ・テンプレートは、コンテンツが表示されるサイトのフレームワークを定義するために使用されます。ページ・テンプレートには、標準のHTMLレイアウトおよびフォーマット・コードと、フラグメントおよびプレースホルダをどこに配置するかを指定するSite Studioタグが含まれています。プレースホルダは、ページのどこにコントリビューション・リージョン(つまり編集可能な領域)を配置するかを指定します。プレースホルダは、これらのリージョンに何が表示されるかに関しては、コンテンツの点でも視覚的なプレゼンテーションの点でも何も指定しないとう点に注意してください。それらはリージョン・テンプレートによって処理されます(関連付けられたリージョン定義を使用して)。
リージョン・テンプレートは、Webページのコントリビューション・リージョン内のデータのレイアウトとルック・アンド・フィールを定義します。要素定義は個別に管理されるサイト・アセットです。つまり、要素定義はWebサイト内またはWebサイト間で再利用できます。(リリース10gR4より前のリリースでは、リージョンのプレゼンテーションは別個に管理されておらず、ページ・テンプレート、すなわち以前のリリースでの名称である「レイアウト・ページ」に含まれていました。)
コントリビューション・リージョンのコンテンツはデータファイルに保存されますが、これらのファイルもやはり別個に管理されるサイト・アセットです。Webページを生成する際に、Site Studioはページ・テンプレート内のプレースホルダをチェックし、プレースホルダに関連付けられたリージョン・テンプレートとデータファイルを取得してその2つをマージし、ページ・テンプレート内のプレースホルダ・タグの位置に挿入するHTMLコードを作成します。これにより、すべてのコンテンツがあるべき場所に配置され、サイトとページの設定に従って提示およびフォーマットされた、最終的なWebページが作成されます。
プレゼンテーション・モデルの場合と同様に、Site Studio Webサイトのコントリビューション側では、図2-3のようにサイトのコンテンツがプレゼンテーションから分離されています。
サイトのコントリビュータは、Webページのコンテンツを編集しようと決めると、適切なキーの組合せを押して、そのページをコントリビューション・モードで再ロードします。(デフォルトのキーの組合せは[Ctrl]と[Shift]キーを押しながら[F5]ですが、これは変更されている可能性があります。)
ページがコントリビューション・モードになると、Webページ内のすべてのコントリビューション・リージョン(つまり編集可能な領域)がマークされ、各コントリビューション・リージョンにどのプレースホルダが関連付けられているかを識別するために、その基礎となっているコードがページに追加されます。Site Studioはこの情報に基づいて、そのプレースホルダに使用するプレースホルダ定義およびリージョン定義を確立できます。リージョン定義は、コントリビューション・リージョン内のコンテンツの構造を、そのコンテンツを構成するデータ・セグメント(要素)の観点から識別します。各要素には要素定義があり、その要素をコントリビュータが編集するときに使用できる編集オプションが定義されています。
コントリビュータがコントリビューション・リージョン内のコンテンツを編集するときには、そのリージョンに関連付けられたコントリビュータ・データファイルがコンテンツ・サーバーからチェックアウトされます。データファイルの構造は、要素の数とタイプの点で、そのファイルに関連付けられたリージョン定義の構造と一致しますデータはデータ・ファイルからロードされてContributorエディタに表示されます。データファイル内の各要素は、編集可能な要素としてエディタ内に表示され、その要素タイプの要素定義の中で定義された編集機能を使用できます。
コントリビュータが編集を終えてContributorエディタの保存アイコンをクリックすると、データファイルが更新されてコンテンツ・サーバーに再チェックインされます。その後、サイトの更新スケジュールに従ってWebページが更新されます。
Contributorエディタでは常に、コントリビューション・リージョンに関連付けられたリージョン定義内の(そしてデータファイル内の)すべての要素が表示されるという点に注意してください。これは、たとえそれらの要素がその特定のリージョンで使用されない場合でも変わりません。当該のリージョンで使用されない他の要素が同じWebサイト内の他の場所で使用されている可能性があるため、その情報を編集するとサイト内の他のページに影響する可能性があります。
図2-4は、Site Studio Webサイトの作成と管理に使用されるサイト・オブジェクトの階層を示しています。
ページ・テンプレートは階層の最も上に位置しています。ページ・テンプレートは、サイトのコンテンツが表示されるWebサイト内のページのフレームワークを提供します。ページテンプレートには、標準のHTMLレイアウトおよびフォーマット・コードに加えて、サイト全体のイメージおよび他のアセットと、フラグメントおよびプレースホルダのタグも含まれています。ページ・テンプレートは、コンテンツ・サーバー上で保存および管理されます。詳細は、第2.12項「ページ・テンプレート」を参照してください。
プレースホルダは、Webページ上のコントリビューション・リージョン(つまり編集可能な領域)の場所を識別するための、ページ・テンプレート上の挿入ポイントです。コントリビューション・リージョンに表示されるコンテンツとその外観は、リージョン・テンプレートとリージョン定義を使用して定義されます。ページ・テンプレートには、複数のプレースホルダを含めることができます。プレースホルダには、ファイルは関連付けられません。プレースホルダはプレースホルダ定義によって制御されます。プレースホルダ定義は、コントリビューション・リージョンにどのようなコンテンツがどのような外観で表示されるかと、コントリビュータが実行できるアクション(コンテンツの切替えやメタデータの変更など)を指定します。プレースホルダには、1つのサブテンプレートまたは1つのリージョン・テンプレートが含まれます。詳細は、第2.10項「プレースホルダとプレースホルダ定義」を参照してください。
サブテンプレートは、ページ・テンプレート上のプレースホルダをさらに小さく独自のプレースホルダを持つ再利用可能な領域に分割するメカニズムを提供する、部分HTMLファイル(つまり、ヘッダー・セクションとボディ・セクションがない)です。プレースホルダとサブテンプレートの間には循環関係があります。つまり、1つのプレースホルダは1つのサブテンプレートを含むことができ、そのサブテンプレートは1つ以上のプレースホルダを含むことができます。サブテンプレートは、コンテンツ・サーバー上で保存および管理されます。詳細は、第2.11項「サブテンプレート」を参照してください。
リージョン・テンプレートは、コントリビューション・リージョン(ページ・テンプレート上でプレースホルダ・タグを使用してマークされます)のデータのレイアウトおよびルック・アンド・フィールを定義する、部分HTMLファイル(つまり、ヘッダー・セクションとボディ・セクションがない)です。リージョン・テンプレートは、その中にどのような種類のコンテンツを含められるかを定義するリージョン定義によって制御されます。コントリビュータがコントリビューション・リージョンに対して使用できるコンテンツ作成および切換えオプションの指定や、そのリージョンに関連付けられたコンテンツ・ファイルのデフォルト・メタデータの設定も、リージョン定義によって行われます。リージョン・テンプレートもリージョン定義も、独立したアセットとしてコンテンツ・サーバー上で保存および管理されます。リージョン・テンプレートには、要素への参照を1つ以上含めることができます。詳細は、第2.9項「リージョン・テンプレートとリージョン定義」を参照してください。
要素は、Site Studio Webサイトにおける再利用可能な情報の最小チャンクです。要素がリージョン・テンプレート内で参照されると、そのテンプレートで定義されているレイアウトとプレゼンテーションを使用して、要素のデータがリージョン・テンプレートに挿入されます。リージョン・テンプレートには、複数の要素参照を含めることができます。要素にはファイルは関連付けられません。リージョン定義の中では要素がグループにまとめられ、それによってサイトのコンテンツのタイプが指定されます。要素は要素定義によって制御されます。要素定義では、その要素タイプに対してコントリビュータがどのような編集操作を行えるかが指定されます。要素定義では特に、コントリビュータがコントリビュータ・データファイル内の要素を編集するときにContributorエディタで使用できる編集機能が設定されます。詳細は、第2.8項「要素と要素定義」を参照してください。
図2-5は、サイトのオブジェクト階層の例を示しています。
図2-5には、2つのリージョン・テンプレートを使用できる(プレースホルダ定義で指定されているとおりに)プレースホルダ(ページ・テンプレート上の編集可能なコントリビューション・リージョン)が示されています。リージョン・テンプレートAに表示されるデータは限られており、タイトルと短い概要の文章のみです。リージョン・テンプレートBには、タイトル、サブタイトル、本文およびイメージを備えたより詳細なデータが表示されます。サイトのコンテキストに応じて、このプレースホルダに対してどちらかのテンプレートを使用できます。どちらのリージョン・テンプレートも、再利用可能な情報の各チャンクに対応する要素(Title、Subtitle、Intro_Text、Body_TextおよびImage)を含む同じリージョン定義に関連付けられています。これらの要素はそれぞれ要素定義に関連付けられています。
Title要素とSubtitle要素は同じタイプ(テキストのみ)ですが、要素定義はそれぞれ異なります。これは、コントリビュータが各要素に対して使用できる編集機能が異なるということを意味します。Intro_Text要素とBody_Text要素は両方ともWYSIWYG要素です。これは通常、コントリビュータがこれらの要素を編集するときに多様な編集オプションを使用できるということを意味します(たとえば、表を追加したり高度なテキスト・フォーマットを使用できる機能など)。コントリビュータが体験する編集操作の方法は、どの要素でも同じです。
1つ以上のコントリビュータ・データファイルがリージョン定義に関連付けられ、最終的にはコントリビューション・リージョンに関連付けられます。その構造は、リージョン定義の構造と一致します。両方とも、同じ要素(Title、Subtitle、Intro_Text、Body_TextおよびImage)を含んでいます。コントリビュータがコントリビューション・リージョン内のコンテンツを編集するときには、そのリージョンに関連付けられたコントリビュータ・データファイルがContributorエディタにロードされ、データファイル内の各要素につき1つずつの編集領域が提供されます。各領域で使用できる編集機能は、要素定義によって設定されています。
Site Studioの最も有用で強力な機能の1つは、サイト・アセットをWebサイト内および複数のサイト間で再利用できる機能です(各サイトがすべて同じコンテンツ・サーバーで管理されている場合)。あるアセットに変更が加えられると、そのアセットが使用されているすべての場所でその変更が行われます。すべてのWebページが確実に更新されるようにするために、当該データのすべてのインスタンスを追跡する必要はありません。これは、サイトのプレゼンテーションに関連付けられたファイルにもコンテンツに関連付けられたファイルにも適用されます(第2.1項「サイトのプレゼンテーションとコンテンツの分離」)を参照してください。ページ・テンプレート、リージョン・テンプレート、要素および類似のアセットは、何回でも再利用できるようにするのが最も効率的です。同様に、同じコンテンツ・ファイルの全体または一部(異なるセグメント)を、サイト内の異なる場所にコンテキストに合せて表示できます。
図2-6と図2-7は、再利用されているサイト・コンテンツの例を示しています。図2-6には、タイトル、イメージおよびサブタイトルで構成されるアイテム・リストが示されています。この情報は、別個のコントリビュータ・データファイルから取得されます。これらのリスト・アイテムはそれぞれ、図2-7のような詳細ページを開くためにハイパーリンクされている場合があります。実際、これは多くのサイトで見かける種類のデザインです。つまり、プライマリ・ページに情報が表示され、完全な情報はリンクをクリックすると開く後続のページに表示されます。
図2-7のWebページには、同じ情報が数多く表示されています。これは、図2-6のリージョン・テンプレートと図2-7のページの両方で同じデータファイルが使用されているためです。使用されている要素も同じです。たとえば、イメージの提示にはイメージのみの要素が使用され、タイトルの提示にはテキストのみの要素が使用されます。残りの情報の表示には、おそらく要素タイプとしてWYSIWYGが使用されます。通常、Webサイトの作成に必要な要素は多くありません。1つのWYSIWYG要素を、Webサイト上でコントリビュータ向けにそのスタイルの編集を設定する場所ならどこでも使用できるためです。
サイト・アセットはWebサイト間での再利用を意図しているため、設計者がWebサイト内に何か作成する前にWebサイトを完全に計画することが特に重要です。詳細は、第3章「Webサイトの計画」を参照してください。
要素は、Site Studio Webサイトにおける再利用可能な情報の最小チャンクです(たとえば、プレス・リリースのタイトル、製品イメージ、本文など)。要素データはWebサイト内(またはWebサイト間)で再利用できるため、サイトの設計者はサイトのコンテンツをどのようにセグメントに分割するかについて慎重に考慮する必要があります。そのためには事前にある程度の作業が必要になることがありますが、それによってサイト・コンテンツの再利用可能性が最大限に高まり、サイト・コンテンツの管理が長期的に効率化されます。
定義済の各要素は、WYSIWYG、テキストのみ、イメージのみ、静的リスト、動的リストまたはカスタムの各特定のタイプです。これらのタイプは、要素コンテンツの構成内容の特性を示し、要素定義をとおして、コントリビュータが使用できる編集オプションを示します。たとえば、プレス・リリースのタイトルはテキストのみの要素(通常はコントリビュータが使用できる編集オプションが限られています)として設定できますが、実際のプレス・リリースのテキストはWYSIWYG要素(通常は、コントリビュータがイメージや表を追加するなど、より自由に編集できます)として設定することになるでしょう。
要素は要素定義によって制御されます。要素は基本的には関連付けられている要素定義がインスタンス化されたものであり、要素定義はWebページ上のその要素に対してコントリビュータがどのような編集操作を行えるか(特に、Contributorエディタでどの編集機能を使用できるか)を指定します。要素定義は個別に管理されるサイト・アセットです。つまり、要素定義はWebサイト内またはWebサイト間で再利用できます(それらのサイトがすべて同じコンテンツ・サーバー上で管理されていれば)。図2-8に示すように、要素が使用されるコンテキストに応じてコントリビュータに異なる編集環境を提供するために、同じタイプの要素(TitleとSubtitle)に異なる要素定義が関連付けられる場合があります。同様に、複数の要素(Intro_TextとBody_Text)が同じ要素定義を共有して、各要素について同じ編集環境をコントリビュータに提供する場合もあります。
個々の要素は別個に管理されるサイト・アセットではありません。リージョン定義の中では要素がグループにまとめられ、それによってサイトのコンテンツのタイプが指定されます。図2-8に示すように、Title、Subtitle、Intro_Text、Body_TextおよびImage要素から構成されるPress_Releaseという名前のリージョン定義が考えられます。したがって、リージョン定義はコンテンツ・クラスであると考えることができます。
要素データは、リージョン定義に関連付けられたコントリビュータ・データファイルに保存されます。各コントリビュータ・データファイルには、関連付けられたリージョン定義に基づく各要素のインスタンスが含まれています。図2-8の例では、Title、Subtitle、Intro_Text、Body_TextおよびImageという5つの要素がコントリビュータ・データファイルに含まれています。コントリビュータは、各要素に関連付けられた要素定義で設定されている編集機能を使用して、コントリビュータ・データファイル内の要素データを編集できます。
リージョン定義は、Webサイト上で使用されるコンテンツのタイプを定義します。リージョン定義はコンテンツ・クラスであると考えることができます。リージョン定義は基本的に、特定のサイト・コンテンツ・タイプについて様々な再利用可能な情報のチャンクを定義する個々の要素のグループです。たとえば、図2-8に示すような、Title、Subtitle、Intro_Text、Body_TextおよびImage要素から構成されるPress_Releaseという名前のリージョン定義(コンテンツ・クラス)が考えられます。コントリビュータ・データファイルは、リージョン定義内の各要素のデータを保存するために、そのリージョン定義と関連付けられます。(コントリビュータがデータに対して実行できる操作は要素定義によって制御されます。第2.8項「要素と要素定義」を参照してください。)
リージョン定義は、サイト・コンテンツ・タイプをそれを構成する要素の観点から定義するのみでなく、その定義に関連付けられたコントリビューション・リージョンに対してコントリビュータが使用できるコンテンツ作成および切替えオプションも指定します。たとえば、あるコントリビューション・リージョンが、コントリビュータがそのリージョンのコンテンツを切り替えられるように設定されている場合、コントリビュータはサーバー上の既存のコントリビュータ・データファイルのみを使用できます(ネイティブ・ドキュメントや新規のコントリビューション・データファイルは使用できません)。(コントリビュータがコントリビューション・リージョン内のコンテンツを実際に切り替えられるかどうかは、プレースホルダ定義によって制御されるという点に注意してください。)最後に、リージョン定義は、コントリビューション・リージョン内のコンテンツのデフォルト・メタデータも、コンテンツ・サーバーへのチェックイン時に設定します。
リージョン・テンプレートは、Webページのコントリビューション・リージョン内のデータのレイアウトとルック・アンド・フィールを定義します。リージョン・テンプレートは、ヘッダー・セクションとボディ・セクションを持たない部分HTMLファイルです。したがって、Site Studioサイト用にWebページを生成するときに、他のHTMLコードの中に挿入できます。
リージョン・テンプレートは、レイアウトおよびフォーマット・コードと、要素(コントリビュータ・データファイルからの)または動的変換(ネイティブ・ドキュメントの)をどこに配置するかを指定するSite Studioタグで構成されます。コントリビュータ・データファイルからの要素があるリージョン・テンプレートでは表示され他のリージョン・テンプレートでは表示されないようにすることで、異なるページ間で情報を再利用することが可能になります(図2-5を参照)。
サイト設計者は、おそらく他のどのサイト・アセットよりも多くのリージョン・テンプレートを作成することになるでしょう。リージョン・テンプレートを使用すると、コントリビュータ・データファイルまたはネイティブ・ドキュメント内の情報を、Webサイトの様々なコンテキストに合せて異なる方法で提示できます。要素の場合と同様に、リージョン・テンプレートを使用してサイト内の情報をどのように提示するかについては、時間をかけて検討する価値があります。リージョン・テンプレートを賢明に活用すれば、サイト・コンテンツの再利用可能性を最大限に高めるとともに、サイト・コンテンツの管理を効率化できます。
つまり、リージョン定義は、Webページ上のコントリビューション・リージョンに何を含めるかを指定し、リージョン・テンプレートはコントリビューション・リージョンの外観を定義します。言い換えると、リージョン定義はサイト・コンテンツの構造(および属性)を指定し、リージョン・テンプレートはそのコンテンツのWebページ上でのプレゼンテーションを定義します。
1つのリージョン定義に複数のリージョン・テンプレートを関連付けることができます。それにより、サイトのコンテンツをサイト内のコンテキストに合せて異なる方法で表示できます。1つのリージョン定義に対して複数のリージョン・テンプレートがある場合、特に別のリージョン・テンプレートを使用するように設定されていないかぎり、デフォルトのリージョン・テンプレートが使用されます。
リージョン・テンプレートを使用すれば、同じデータファイルからのデータを使用して、複数の場所にそれぞれ異なるレイアウトで情報を表示できます。その一般的な例として、たとえあタイトル、簡潔なサブタイトルおよび小さなイメージが表示されるアイテム・リストがあげられます。その一例である図2-9では、イメージが左、タイトルとサブタイトルが右という配置で3つの要素を表示するリージョン・テンプレートが、サンプル・コンテンツ付きで示されています。
図2-9のコンテンツは、同じデータに適用されてデータファイルからの要素をより多く表示する別のリージョン・テンプレートを使用する新しいページを開くために、ハイパーリンクされている場合があります。図2-10は、そのようなリージョン・テンプレート(およびサンプル・コンテンツ)の例を示していますが、この例ではタイトルが一番上に、サブタイトルと導入テキストと本文がその下に配置されます。このリージョン・テンプレートにはイメージも含まれています(サイズと配置は異なりますが)。コンテンツはすべて、図2-9で使用されているものと同じデータファイルから取得されたものです。
図2-9と図2-10の場合、どちらのページでもコントリビュータがデータを編集できるようにコントリビューション・リージョンを設定できます。ただし、同じデータファイルを編集することになるため、加えた変更はそのデータファイルが使用されているすべての場所に反映されます。限られた要素セットが表示されているリージョン・テンプレート(図2-9)からデータファイルを編集する場合、たとえその特定のコンテキストですべての要素が使用されてはいなくても、Contributorエディタにはデータファイルのすべての要素が表示されるという点に注意してください。
プレースホルダは、Webページ上のコントリビューション・リージョン(つまり編集可能な領域)の場所を識別するための、ページ・テンプレート上の(第2.12項「ページ・テンプレート」を参照してください)挿入ポイント(タグ)です。プレースホルダは、次のような単純なタグによって表されます。
<!--$wcmPlaceholder("Name")-->
プレースホルダによって識別されたコントリビューション・リージョンのコンテンツとそのサイト上での外観は、リージョン・テンプレートとリージョン定義を使用して定義されます(第2.9項「リージョン・テンプレートとリージョン定義」を参照してください)。ページ・テンプレートには、複数のプレースホルダを含めることができ、各プレースホルダはページ上のコントリビューション・リージョンを表します。プレースホルダにはファイルは関連付けられません。図2-11のWebページには、プレースホルダが1つあります(サンプル・コンテンツが表示されている点線で囲まれた部分)。
ページ・テンプレートにプレースホルダを挿入するときに行う操作は、コンテンツを挿入できるようにする名前付きの位置をテンプレート内にマークすることのみです。その位置でコンテンツがどのように処理されるかを制御するために、プレースホルダ名をプレースホルダ定義と関連付ける必要があります。プレースホルダ定義は、コントリビューション・リージョンにどのようなコンテンツがどのような外観で表示されるかと、コントリビュータが実行できるアクションを指定します。たとえば、コントリビュータがコントリビューション・リージョンに表示されるコンテンツのメタデータを更新したり、コントリビューション・リージョンのコンテンツを切り替えることができるように、プレースホルダを設定できます。(どのような種類のコンテンツに切り替えられるかは、リージョン定義によって制御されるという点に注意してください。)
プレースホルダとプレースホルダ定義の関連付け(マッピングとも呼ばれます)は、次のいずれかの方法で方法で行えます。
サイト・レベル(グローバル・マッピングを使用): セクション・レベルまたはプレースホルダ・レベルでオーバーライドが指定されないかぎりサイト全体に適用される、デフォルトのプレースホルダ・マッピングを設定できます。それには、Designerで「ツール」メニューを開き、「プレースホルダ定義マッピングの定義」を選択します。これにより、プライマリ・ページおよびセカンダリ・ページについてプレースホルダ名をプレースホルダ定義と関連付けることができます。その後は、ページ・テンプレート内でそのプレースホルダ名が参照されるようになります。プレースホルダ名は複数のセクションの複数のテンプレートで使用されることがありますが、その場合もマッピングは適用されます。
セクション・レベル(セクション・プロパティを使用): サイト・セクションのプライマリ・ページ、セカンダリ・ページまたはその両方について、特定のプレースホルダ定義マッピングを設定することもできます。この方法でマッピングを確立すると、そのマッピングがサイト全体(グローバル)レベルのマッピングより優先されます。この方法でマッピングを設定したセクションは、同じプレースホルダを使用している他のセクションとは異なるマッピングを使用することになるという点に注意してください。
プレースホルダ・レベル(プレースホルダ・タグ内でパラメータを使用): 特定のプレースホルダについて特定のプレースホルダ定義を設定することもできます。それには、プレースホルダ・タグにplaceholderDefinitionDocName=[NAME]を追加します(ソース・ビューで)。ここでマッピングを確立すると、そのマッピングがすべてのセクション・レベルおよびサイト全体(グローバル)のマッピングより優先されます。また、このテンプレートが使用される場所ではどこでもこの定義が使用されるということも意味します。そのテンプレートはその後、サイト内のどこで使用されるかに関係なく、常に指定された定義を使用するようになります。また、このマッピングを変更する唯一の手段は、ソース・ビューでテンプレートに変更を加えることです。これはハードコード化されるため、定義マッピングを指定する最も柔軟性の低い方法であるといえますが、必要に応じて使用できます。
キャッチオールとして(Webサイト・プロパティを使用): 前述の他の3つの方法がいずれも適用されない場合に使用される、デフォルトのプレースホルダ定義を設定できます。それには、サイトのWebサイト・プロパティ・カテゴリの「デフォルトのプレースホルダ定義」プロパティを設定します。
また、キャッチオール・プレースホルダとして働く(他のプレースホルダ定義が適用されない場合に)デフォルトのプレースホルダ定義を設定することもできます。
プレースホルダ定義は、コントリビューション・リージョン(プレースホルダ・タグでマークされた領域)にどのようなコンテンツがどのような外観で表示されるかと、コントリビュータが実行できるアクションを指定します。たとえば、コントリビュータがコントリビューション・リージョンに表示されるコンテンツのメタデータを更新したり、コントリビューション・リージョンのコンテンツを切り替えることができるように、プレースホルダを設定できます。(どのような種類のコンテンツに切り替えられるかは、リージョン定義によって制御されるという点に注意してください。)
プレースホルダ定義は、Webページ上の関連付けられたプレースホルダ(つまりコントリビューション・リージョン)に対してどのリージョン定義、リージョン・テンプレートおよびサブテンプレートを使用できるかも指定します。たとえば、あるプレースホルダ定義で、REGION_DEFINITION_1、REGION_DEFINITION_2およびREGION_DEFINITION_3という3つのリージョン定義が許可されているとします。
リージョン定義1には、3つのリージョン・テンプレート(A、B、C)が関連付けられており、リージョン・テンプレートAがデフォルトになっています。これは、リージョン定義1に関連付けられたすべてのコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)には、別のリージョン・テンプレートが特に設定されていないかぎり、リージョン・テンプレートAが適用されることを意味します。通常は、コンテンツ・ファイルを作成するときに、そのファイルにリージョン定義を関連付けますが、その関連付けはいつでもコンテンツ情報ページで変更できます(第2.2項「サイト・アセットの記憶域」を参照してください)。
サブテンプレートは、<HTML>、<HEAD>および<BODY>セクションがないこと以外は、ページ・テンプレートと同じです。したがって、基本的にはページ・テンプレートに挿入できるHTMLコードのチャンクです。サブテンプレートには非常に単純なHTMLコードを含めることができますが、独自のスクリプトなどを持つ非常に複雑なものにすることもできます。サブテンプレート内のコードは、ページ・テンプレートに直接挿入された場合とまったく同様に扱われます。
サイトのオブジェクト階層(図2-4)に示されているように、サブテンプレートを配置できるのはプレースホルダの中のみで、サブテンプレート内に独自のプレースホルダを含めることができます。図2-12に示すように、サブテンプレートは通常、ページ・テンプレート上のプレースホルダ(つまりコントリビューション・リージョン)を、再利用可能で独自のプレースホルダを持つより小さな領域に分割する手段として使用されます。プレースホルダには、1つ以上の他のプレースホルダを含むサブテンプレートを1つ含めることができます。サブテンプレート内のプレースホルダはそれぞれ独自のサブテンプレートまたはリージョン・テンプレートを持ちます。
優れたサイト設計に必ずサブテンプレートが必要というわけではなく、サブテンプレートをまったく使用していないWebサイトも数多く存在します。サブテンプレートを追加すると、設計者が管理する必要があるサイト・アセットのタイプが増えるためです。
サブテンプレートを使用すると、Webサイト内で使用されるページ・テンプレートの数を減らせます。これは、できるかぎり広範囲で再利用できるメイン・ページ・テンプレートを1つ作成し、特定のケースではサブテンプレートを使用してメイン・ページ・テンプレート上のプレースホルダを複数のプレースホルダに変更することによって達成できます。これにより、再利用可能性がさらに高まります。サイトの設計者は、1つのプレースホルダを持つ大きな領域を作成し、レイアウトが異なる複数のプレースホルダを備えたサブテンプレートをプレースホルダに含めることで、その領域を使用および再利用できます。
ページ・テンプレートは、Webページのレイアウトと高レベルのルック・アンド・フィールを定義します。これには、コントリビューション・リージョン(ページの編集可能な領域)、ナビゲーション・ツール(フラグメント形式)、サイト全体にわたるイメージ(バナーなど)の配置も含まれます。ページ・テンプレートは、サイトのコンテンツの表示に使用するフレームワークを提供します。
ページ・テンプレートは、レイアウトおよびフォーマット・コードと、フラグメントおよびプレースホルダをどこに配置するかを指定するSite Studioタグで構成されます。したがって、ページ・テンプレートは通常は軽量であり、含まれているのはコントリビューション・リージョンが配置されるページ上の場所を示す高レベルの参照のみです。それらのリージョンに表示されるものに関しては、コンテンツについても視覚的なプレゼンテーションについても何も指定しません(第2.9項「リージョン・テンプレートとリージョン定義」を参照してください)。ページ・テンプレートには通常、企業バナーやページ・レイアウト用イメージなどのサイト全体にわたるグラフィックと、ナビゲーション・ツールや標準的なページ・コンテンツ(フッターなど)などの繰り返し使用される編集不可能なコンテンツが含まれています。
Webサイトに必要なページ・テンプレートの数はサイトの複雑さによって決まりますが、通常はわずかな数で足ります。たとえば、ホーム・ページ用にページ・テンプレートを1つ使用し、他のすべてのページ用に別のページ・テンプレートを1つ使用すれば十分でしょう。様々なWebサイト・ページに表示されるコンテンツの多様性に関しては、ページ・テンプレート上のプレースホルダの中でリージョン・テンプレート(およびリージョン定義)を使用して対処できます。ページ・テンプレートの数が少ないほど、Webサイトのメンテナンスが容易になります。そのためには、事前の作業を増やす必要があります。つまり、素材のレイアウトや、どの情報をWebサイトのどのセクションに表示するかなどについて、Webサイトの設計をより綿密に考え抜く必要があります。これは、どの情報についてコントリビュータによる変更を許可し、どの情報を固定するかについて、サイト設計者が慎重に考慮する必要があることも意味します。
図2-13は、Webサイトのホームページによく使用される汎用ページ・テンプレートを示しています。最上部にバナー・イメージ、左側にナビゲーション・フラグメント、最下部にフッター・フラグメント、中央にいくつかの小さなプレースホルダが配置され、それぞれになんらかのコンテンツが表示されます。プレースホルダは、ページ領域を詳しく記述することはありません。プレースホルダは、コントリビューション・リージョンの場所を指定する単なる挿入ポイントです。これらのリージョンに何がどのように表示されるかは、リージョン・テンプレートとリージョン定義によって処理されます。サイト閲覧者がこのコンテンツをクリックすると、コンテンツが完全に表示されます。この完全なコンテンツは、潜在的にホームページ以外のすべてのサイト・ページで使用される可能性があるページ・テンプレートに表示されます。図2-14は、このような汎用ページ・テンプレートの例を示しています。このテンプレートは基本的にはホームページ用のテンプレート(図2-13)と同じですが、ページのコンテンツを完全に表示するために、コンテンツ領域が単一のプレースホルダになっています。
Site Studio Webサイトは、2種類のファイル、つまりコントリビュータ・データファイルかネイティブ・ドキュメントのどちらかに保存されます。これらのコンテンツ・ファイルはコンテンツ・サーバーに保存され、コントリビュータがWebサイトのコンテンツを追加または編集するときにはこれらのファイルが操作対象になります。サイト設計者は、特定のWebサイト用にどちらのファイルを使用するか(または両方とも使用するか)を決定します。
Webサイトのコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)は、最初は設計者かコントリビュータによって選択または作成され、その後はコントリビュータによって変更されます。設計者がコントリビューション・リージョンに関連付けられたプレースホルダ定義でコンテンツ・ファイルの切替えを許可していれば、コントリビュータがそのリージョンに関連付けるコンテンツ・ファイルを切り替えることができます。
Webページのコントリビューション・リージョンにサイト・コンテンツが表示されるとき、そのコンテンツは、コンテンツ・ファイルの名前付きの各部分がページ内のどこにどのように表示されるかを定義するリージョン・テンプレートとリージョン定義を通じて表示されます。特定のコンテンツをサイト内で再利用するかどうかに応じて、一意のコントリビュータ・データファイルまたはネイティブ・ドキュメントをコントリビューション・リージョンに割り当てることも、同じファイルを何回も割り当てることもできます。コンテンツ・ファイルを最初に作成するときには、コンテンツ・ファイルの名前とメタデータを選択し、そのファイルをコンテンツ・サーバーにチェックインします。コンテンツ・ファイルに付ける名前は、サイト上でそのファイルを管理するときに役立つ可能性があります。また、コンテンツを再利用するかどうかによって、選択する名前が決まる場合もあります。詳細は、第 3.4項「サイト・アセットの計画とネーミング」を参照してください。
コントリビュータ・データファイルは、Site Studioによって作成されるXMLファイルです。各コントリビュータ・データファイルは、そのコンテンツ・クラスを構成要素の観点から定義する1つの(そして唯一の)リージョン定義に関連付けられます(第2.9項「リージョン・テンプレートとリージョン定義」を参照してください)。たとえば、あるリージョン定義がTitle、Subtitle、Body_TextおよびImageという4つの要素で構成されている場合、そのリージョン定義に関連付けられたコントリビュータ・データファイルはすべて、同じ4つの要素を含むことになります。コントリビュータ・データファイル内の各要素は、リージョン定義でその要素と関連付けられた要素定義に従って編集できます(第2.8項「要素と要素定義」を参照してください)。要素定義では、コントリビュータがコントリビュータ・データファイル内の要素を編集するときに使用できる編集オプションが指定されています。非常に限られたフォーマット機能しか備えていないプレーン・テキストとして設定される要素もあれば、通常ははるかに多様な編集操作ができるWYSIWYG(What You See Is What You Get)要素もあります。
コントリビュータ・データファイルのコンテンツは、Webサイト上で簡単に再利用できます。つまり、使用される場所に応じてコンテンツの全体または一部(異なる要素)を、サイト内の異なる場所に表示できます。コントリビュータがコントリビュータ・データファイルを編集するときには、たとえ編集対象のコントリビューション・リージョンに実際に表示されるのが一部の要素のみであっても、そのファイルのすべての要素がContributorエディタに表示されることに注意してください。当該のリージョンで使用されない他の要素が同じWebサイト内の他の場所で使用されている可能性があるため、その情報を編集するとサイト内の他のページに影響する可能性があります。
ネイティブ・ドキュメントは、Microsoft Wordのような使い慣れたサード・パーティ・アプリケーションを使用して作成されたファイルです。ネイティブ・ドキュメントは、Webサイトに表示できるように、Dynamic Converterを使用してHTML形式に変換されます。Dynamic Converterは、変換ルールおよびテンプレートを使用して、ネイティブ・ドキュメントをどのように変換するかを決定します。ネイティブ・ドキュメントは、関連付けられたアプリケーションを使用して編集されます(たとえば、.docファイルの場合はMicrosoft Wordを使用します)。
ネイティブ・ドキュメントのコンテンツもWebサイト上で再利用できますが、ネイティブ・ドキュメントは一般に、コントリビュータ・データファイルほど柔軟には再利用できません。Microsoft Wordのスタイルや他のフォーマット機能を適切に使用すれば、ネイティブ・ドキュメントの再利用可能性に関する弱点をある程度克服できる可能性もあります。ネイティブ・ドキュメントを使用することの重要な利点の1つは、ほとんどのコントリビュータが、たとえばMicrosoft Wordをすでに使い慣れているため、このアプリケーションがサイト・コンテンツ用の簡単で便利な編集環境になることです。
サイト・セクションのプライマリ・ページは、閲覧者が最初にそのセクションに入ったときに表示されるページです。通常、サイト階層内の各セクションにはプライマリ・ページが割り当てられていますが、これは必須ではありません。たとえば、ユーザーが直接参照できないようにする必要がある検索結果ページは、セカンダリ・ページしか備えていない場合があります。サイト・セクションのプライマリ・ページとして、ページ・テンプレートを割り当てます。
プライマリ・ページ上の情報は、静的にリンクされています。コントリビュータは、プライマリ・ページ上のコントリビュータ・データファイルはContributorエディタを使用して、ネイティブ・ドキュメントは関連付けられたサード・パーティ・アプリケーションを使用して変更できます。
セカンダリ・ページはサイト・セクションにとってオプションであり、通常はWebサイト上でコンテンツを動的に提示するために使用されます。セカンダリ・ページに静的コンテンツを表示することもできますが、セカンダリ・ページの有用性は、動的に配置される置換可能なコンテンツを表示できる機能にあります。そのため、セカンダリ・ページはサイト・セクション内のページの複数のバージョンを作成するために使用され、1つのサイト・セクション内でコンテンツを様々に表示できます。セカンダリ・ページを使用すれば、何千ものページを物理的に作成する必要なしで大規模なサイトを処理できます。
セカンダリ・ページは、基本的にはコントリビュータによってサイトに追加されたコンテンツのバックドロップとして機能します。新規のコントリビュータ・データファイルまたはネイティブ・ドキュメント(両方とも新規のWebページになります)をコントリビュータがサイトに追加できるように設定する場合は、セカンダリ・ページが必須です。これらのファイルは、動的リスト、検索またはリンクのターゲットによって選択されたときにサイトで使用できるようになります。ページ・テンプレートをセカンダリ・ページとして構成できます。
全体がプライマリ・ページで構成されたサイトを作成することもできますが、その場合は、サイトを拡大するために新規のプライマリ・ページからなるセクションを作成する必要があります。セカンダリ・ページを使用すれば、コントリビュータが追加のコンテンツを発行するとサイトが自動的に成長するため、設計者は何もする必要がありません。セカンダリ・ページを使用すると、サイトがはるかにスケーラブルになります。
セカンダリ・ページの一般的な用途の1つは、ハイパーリンクされた項目(たとえば図2-15のプレス・リリースのタイトルなど)の動的リストです。各項目をクリックすると、その項目がセカンダリ・ページに完全に表示されます。より具体的にいうと、リンクのターゲットが同じセクションのセカンダリ・ページ上の置換可能なリージョン内に開きます(デフォルトの場合)。
