| Oracle® WebCenter Content Site Studio Designerユーザーズ・ガイド 11g Release 1 (11.1.1) B72416-01 |
|
 前 |
 次 |
Site Studio Designer11gR1は、サイト・アセットを使用して、Webサイトをできるだけ効率的に管理できるようにします。Site StudioでWebサイトを適切に作成するには、いくつかの設計ポイントに留意しながら、Webサイトとそのサイト・アセットを計画する必要があります。
計画作業は、Site Studioで適切なWebサイトを構築するための鍵となります。ページ・テンプレートにテキスト、グラフィックおよびスクリプトを挿入する前に、次のことを検討する必要があります。サイトの機能や役割は何でしょうか。サイトは、部門レベルのサイト、企業全体のサイト、内部サイト、外部サイトのいずれでしょうか。どのくらいの数のユーザーがサイトを訪問するでしょうか。どのくらいの数のユーザーがサイトの構築に協力するでしょうか。コントリビュータごとに異なるセキュリティ・アクセス・レベルを使用するでしょうか。サイトをレプリケートまたはパブリッシュする予定はあるでしょうか。サイトは長期にわたって成長が見込まれるでしょうか。
これらはすべて作業の開始前に検討する必要のある重要な問題です。ユーザー固有のニーズを予測することはできませんが、サイトを開発する前に検討する必要のあるいくつかの主なポイントについて提案することは可能です。
この項の情報は、Site Studio 10gR4に導入された機能に関するものであり、以前のバージョンのSite Studioには適用されません。
純粋なHTMLのみを使用して静的なWebサイトを作成する場合、一般的に、サイトがどのように流れるかを計画する必要はほとんどありません。Site Studioがデザイナにもたらす主なメリットの1つに、サイト・アセットの再利用性があります。これは、Webサイトの作成において最も複雑かつ重要な面がサイトの計画であることを意味します。Webサイトのあらゆる面(特定の情報を表示する場所など)について、その情報が未定の場合でも検討する必要があります。
Webサイトを適切に計画すると、ページ・テンプレート、サブテンプレートおよびリージョン・テンプレートを適切に使用および再利用して、Webサイトの再利用性を最大限に高める方法を決めやすくなります。
Webサイトを計画する場合、次の質問に回答する必要があります。
計画プロセスに多くの時間を費やすほど、Webサイトおよびサイト・アセットの作成と管理が簡単になることを理解する必要があります。Site Studioを使用して管理対象のWebサイトを計画するにはより多くの時間が必要になると捉えられますが、結果としては、アセットの管理に要する時間が大幅に短縮されます。
適切な計画は、サイトをより簡単に実行できるようにするために不可欠です。初期の段階では、従来のWebサイトの作成方法よりも、ページを完成するまでに要する時間が長く感じられる場合があります。ただし、十分な時間を費やしてWebサイトを計画しておくと、サイト・アセットを使用したWebサイトの構築や、Webサイトの管理、特に後でWebサイトの実行中に行う変更が、はるかに簡単になります。
Webサイトについて検討する場合、コンテンツおよび構造をすべて確認し、再利用可能なものと、1回のみ使用するものについて検討する必要があります。その際は、ページのレイアウトのみ、表示するデータのみ、または特定の方法で表示する特定のデータ部分について検討する場合があります。
サイトの様々な部分を配列および再利用する方法は多岐にわたるため、独自のWebサイトについて検討するときは、ここに示す編成および再利用の例を参照すると便利です。
一般的なWebサイトでは、左側にナビゲーション、一番上にバナー・グラフィック、中央にページ自体の情報を示す大きな領域が表示されます。バナーとナビゲーションはすべてのページに配置する必要があります。そのため、これらの要素はページ・テンプレート自体に配置します。ただし、中央の情報は明らかにページごとに異なります。この部分について検討することが最も重要です。
最も重要な検討事項は、情報の編成方法です。ページを表示すると、オブジェクトが1列に配列されるか、アレイ状に配列されるか、イメージで分割される場合があります。すべてのオブジェクトを1つのプレースホルダに配列することは可能ですが、反対に、より小さなセクションを複数作成し、各セクションに独自のより小さなコントリビュータ・データ・ファイルを割り当てることもできます。
空いた職席をリストするWebサイトのページについて検討します。1つのプレースホルダとなるようにページを作成し、内部の職席と外部の職席をすべてリストできます。または、そのプレースホルダ内にサブテンプレートを作成し(結果として別のプレースホルダやリージョン・テンプレートなどが含まれる)、外部の職席が内部の職席とは別に格納されるようにすることもできます。各職席を別個のコントリビュータ・データ・ファイルに保持し、外部のWebサイトには外部の通知のみが表示され、内部のWebサイトには外部の通知を含むコントリビュータ・データ・ファイルと内部の通知を含むファイルの両方が表示できます。
別の使用例として、会社内の各部署で独自の空いている職席をリストし、1つの中央ページに個々の空いている職席をすべて収集して表示する場合があります。このような場合、サブテンプレートを使用すると、異なる数のプレースホルダを簡単に管理できます。
また、ページ上にデータをレイアウトする方法や、Webサイト内でデータの配置を編成する方法について、ページごとにこのような検討を行う必要があります。
次の質問を検討する必要があります。ページ・テンプレートで1つのプレースホルダを使用し、サブテンプレートを使用してそのプレースホルダを分割することが最適でしょうか。または、追加のページ・テンプレートを使用して、プレースホルダの配列を変更できるようにする方がより適切でしょうか。
別の例として、個別のページを用意する必要はないが、後で必ず再利用する少量の情報を表示する場合があります。この例には、通常の企業の連絡先情報とは異なる、株主の連絡先情報や求人情報などがあります。このような情報は、独自のページを確保するほどのものではありません。
前述のいずれの場合も、ページ・テンプレートは同じになります。このテンプレートには、バナー、ナビゲーション、フッターが含まれ、中央には、必要な情報を置換および入力し、意図したとおりに構成できる領域を表すプレースホルダが含まれます。ここでは、すべてのページに必要な1つの外観が維持できるテンプレート内で、サブテンプレートを使用してさらに1つ以上のプレースホルダを使用する方法について検討しました。
また、このレイアウトは、ページごとに異なるページ・テンプレートを使用して実現することも可能です。やはり、このレイアウトを実現する方法は、サイトの計画方法によって異なります。
前述のとおり、サイト作成で最も重要な点は、Webサイトの各部分を構造およびコンテンツの両方の観点でどのように表示するかを特定することです。Site Studioを使用する場合、作成前の計画に多くの時間を費やすほど、Webサイトで配信する何百、何千というページを作成するのに要する時間が短縮されます。
Site Studio Designerでは、サイト・アセットは再利用するように設計されています。アセット自体は、Webサイトの様々な領域だけでなく、設計する様々なWebサイトでも使用できるため、各アセットの命名は重要です。適切な命名方法を使用すると、Webサイトの1つ以上の領域と、1つ以上のWebサイトで、アセットをより簡単に管理およびデプロイできます。
アセットの命名方法としては、Webサイトでアセットが使用される場所に基づく名前を使用するのではなく、アセットの機能とその動作を表す名前を使用するのが最適です。
多くのデザイナは最初に、Webサイトの名前を各アセットの名前に入れることを考えます。この場合、コンテンツ・サーバーのコンテンツをリストするときに、アセットがグループ化されます。ただし、すべてのアセットが再利用可能なため、複数のWebサイトを実行する場合は問題があります。Webサイト内の特定のセクション用に完全に新しいアセットおよび定義のセットを作成するのではなく、すでに作成された他のアセットを簡単にインポートできます。ただし、この方法を行う場合、アセットの名前に他のWebサイトの名前が含まれていると、特定のアセットの存在理由に関して一貫性、理解および混乱の問題を招く場合があります。また、アセットの名前には、Webサイト内のアセットの場所を含めないようにする必要があります。
図には、場所に基づいてアセットに命名する場合の問題が示されています。元々プライマリ・ページ・テンプレート用に意図していたページ・テンプレートにprimary_templateと命名すると、このテンプレートがセカンダリ・ページでも使用される場合に、いくつかの問題が生じます。適切に計画するとこの問題は排除され、テンプレートにpage_template_with_2_placeholdersのような名前が割り当てられます。
プロジェクトにおけるサイト・アセットの命名方法として、次の2つの異なる方法について検討します。
| 管理に向けて十分に計画しなかった場合のネーミング規則 | 管理に向けて十分に計画した場合のネーミング規則 |
|---|---|
| placeholder_def_1
p_def_2 default_definition front_page_template subtemplate_up element_title region_replace |
element_def_WYSIWYG_fulledit
element_def_imageonly_minedit placeholderdef_subtemplate_newslist regiondef_customform regiontemplate_title_and_body pagetemplate_home pagetemplate_errorhandler |
アセットにその機能を表す名前を付けておくと、後で更新するときに作業がはるかに簡単になり、意図したとおりに配置できるようになります。また、すべての管理対象Webサイトで、すでに作成されたアセットがあるかどうか検索する必要もなくなります。
Site Studio DesignerとJDeveloper用のSite Studio拡張機能でのSite Studioアセットの共有を計画している場合、JSPページでは一部の文字が正しく表示されないことに注意する必要があります。このため、Javaで予約されている演算子や語(-または+など)は使用しないでください。Javaの要件の詳細は、次のリンクを参照してください。
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/variables.html
および
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSPIntro7.html
また、URLとして使用される可能性があるすべての値ではマルチバイト文字(MBC)を使用しないように注意してください。Site Studioでは、値がURLの一部になる可能性があるフィールドでMBCを使用できません。SiteID、ContentID、URLPageNameおよびURLDocNameフィールドなどが、URLとして使用されるフィールドです。フラグメントの内部ではMBCを使用できますが、フラグメントによってURLが生成される場合には使用しないでください。
さらに、データ・ファイルまたはネイティブ・ドキュメントのコンテンツIDにすでにMBCが含まれる場合は、そのドキュメントを参照する際に別の方法(dDocName以外のメタデータ・フィールドを使用するSSUrlFieldName構成オプションなど)を使用する必要があります。
サイト階層を計画してWebサイトのアセットを準備したら、コントリビューション・モデルについて検討する必要があります。つまり、ユーザー（コントリビュータおよびマネージャ）によるサイトへのコンテンツの配置方法について検討します。
コントリビューション・モデルを計画する場合、次の質問に回答する必要があります。
デザイナは、背景色、位置決めの仕組み(HTML表またはCSS)、サイト・ナビゲーション、カスタム・スクリプトなどをサイトに追加する必要があります。ただし、各Webページのコンテンツの大部分(つまり、ページ上の実際の情報)は、コントリビュータが作成および編集できます。
Site Studioの機能を真に活用するには、できるかぎりWebサイトの多くの部分をこれらのユーザーに開放する必要があります。これにより、Webサイトに一般的に付随するボトルネックや遅延なしに、Webサイトを継続的に更新できます。
すべてのページ・テンプレートには、1つの大きなコントリビューション・リージョンを割り当てるか、複数の小さなコントリビューション・リージョンを割り当てることができます。リージョン・テンプレート内には、1つ以上の要素を割り当てることが可能で、各要素はコントリビュータ・アプリケーションでフィールドとして表示されます。このフィールドで、ユーザー(各コントリビュータ)はコンテンツを追加および編集できます。
テキストやグラフィックの追加と編集、リストの更新といった特殊な用途に使用できる様々なタイプの要素があります。特定の書式属性の有効と無効は、切り替えることができます（書体、フォント・サイズ、イメージ、表、カスタム・プロパティの選択など）。これらの選択は、任意のWebページをどの程度コントリビュータに制御させるかに応じて変化します。また、検証機能または独自の検証スクリプトを使用して、追加されるコンテンツを管理できます。
これ以外に、サイト階層の変更をユーザーに許可するために、1つ以上のページでマネージャ・アプリケーションを有効化できます。
この制御の程度は、組織のガイドラインに基づいて、サイトの一貫性を損わないように調整する必要があります。
デザイナは、各ユーザーにサイトへのアクセス権を付与する前に、個々のユーザー、ユーザーの組織内での役割、およびWebパブリッシングに関するユーザーの知識を把握する必要があります。すべてのユーザーにWebサイトのすべてのコントリビューション・リージョンに対する同じアクセス権を付与することも、制限されたアクセス権と完全なアクセス権をユーザーごとに個別に付与することもできます。
たとえば、マーケティング部門のメンバーにはWebページ全体への完全なアクセス権を付与し、他のすべての部門にはそのページの一部のみに対するアクセス権を付与することができます。これを行うには、コンテンツ・サーバーに異なるユーザーを設定し、各リージョンに異なるコントリビュータ・データ・ファイルまたはネイティブ・ドキュメントを割り当て、(コンテンツ・サーバーのメタデータ・フレームワークを使用して)それらのファイルに一意のセキュリティ・メタデータを割り当てます。
結果として、コントリビューション・モードのときにWebページでファイル上にコントリビューション・グラフィック(図4-2)が表示されるのは、特定のコントリビュータが編集権限を保持するファイルのみとなります。
また、Webサイトのセクションには、表示を特定のユーザーのみに許可するようにマークすることもできます。この処理は、Webサイト階層内のセクション設定で行われます。セクションにアクセス制限を設定すると、そのセクションは、アクセス権を付与されたユーザーのみに表示（設定によっては編集も）できるようになります。
各コントリビュータは、コントリビュータ・アプリケーションを使用して、Site Studioデータ・ファイルに格納されているコンテンツを追加および編集する以外に、サイトにネイティブ・ドキュメント(Microsoft Word、Excel、PowerPointなどのアプリケーションで作成されたドキュメント)を追加することもできます。これらのドキュメントは、Dynamic Converterの使用により、Webで参照可能なレンディションに変換されます。
各コントリビュータは、(リージョンに割り当てる、リンク・ウィザードを使用する、動的リストに追加するなどの方法を通じて)新規および既存のネイティブ・ドキュメントを直接Webサイトに追加できます。また、コンテンツ・サーバーにおける既存の方法を使用してドキュメントをチェックインすることも可能です(Content Serverのコンテンツ・チェックイン、Desktop Integration Suiteクライアント、Oracle Content Serverのフォルダ機能など)。
各コントリビュータは、(コントリビューション・グラフィックの「メニュー」アイコンにある「チェックアウトして開く」オプションとコントリビュータ・アプリケーションのドキュメント編集機能を使用することで)Webサイトから直接ネイティブ・ドキュメントを編集することもできます。
ネイティブ・ドキュメントは、コントリビュータ・データ・ファイルの場合と同様、再利用可能なチャンクではなくWebページに表示されます。
Webサイトに対するネイティブ・ドキュメントの発行をコントリビュータに許可する場合(これもコントリビューション・リージョン、要素およびリスト・フラグメントで制御します)、デザイナは、ネイティブ・ドキュメントの使用方法と、適用されるスタイル・ガイドラインについてコントリビュータに情報を提供する必要があります。
1人のユーザーがWebサイトのデザイナ、マネージャおよびコントリビュータを兼ねている場合、そのユーザーはサイトを更新する必要のある時期と場所を把握しています。デザイナが1人のコントリビュータまたはマネージャと共同で作業をする場合、サイトで必要な更新について通知する必要があります。特に、サイトに対する一定の変更に関してコントリビュータやマネージャに通知する必要があります。ただし、コントリビュータも、コンテンツが追加されたときにデザイナに連絡する場合があります。
デザイナが複数のユーザーと共同で作業をする場合、コミュニケーションはすぐに複雑になる可能性があります。デザイナは、ユーザー間になんらかのコミュニケーション・プロセスを導入する必要があります。解決策の1つは、ワークフローを使用した正式なレビュー・プロセスを導入することです。つまり、サイト変更は、様々なユーザーが確認および承認した後で有効になります。
コントリビュータにSite Studioの動作方法の概要を伝える場合、状況に応じて各コントリビュータに『Oracle WebCenter Content Site Studio Contributorユーザーズ・ガイド』を配布できます。
Webサイトを計画したら、デザイナでWebサイトを構築するために使用するアセットを作成する必要があります。最も効率的に使用するためには、このアセットを特定の順序で作成することをお薦めします。
ほとんどのWebサイトで最も効率的なアセットの作成方法は、アセットをボトムアップ式に作成することです。
要素定義(4.5項「要素定義の作成」を参照)
リージョン定義(4.6項「リージョン定義の作成」を参照)
リージョン・テンプレート(4.7項「リージョン・テンプレートの作成」を参照)
サブテンプレート(4.8項「サブテンプレートの作成」を参照)
プレースホルダ定義(4.9項「プレースホルダ定義の作成」を参照)
ページ・テンプレート(4.10項「ページ・テンプレートの作成」を参照)
サイト階層(4.11項「サイト階層の計画」を参照)
もちろん、完全にこの順序でアセットを作成する必要はありません。ただし、この順序に従うと、一般的にWebサイトをより迅速かつ効率的に作成できます。
最初に定義する最も効率的なアセットは、要素です。要素は、コントリビュータが使用する編集インタフェースを定義するアセットです。各要素の特定の使用は、要素定義を通じて処理されます。要素定義を作成し、コントリビュータがアクセスできる編集リージョンおよびツールバーを定義することにより、コントリビュータによるデータ・ファイルの処理方法を定義します。
要素定義では、ツールバーでコントリビュータが使用できる編集機能を正確に制御できます。たとえば、コントリビュータにフォント・サイズまたは色の変更を許可せず、太字およびイタリックの使用を許可できます。通常は、各種の要素（WYSIWYG、テキスト専用、イメージ専用、静的リスト、動的リストおよびカスタム）のうち少なくとも1つを定義します。また、コントリビュータで異なるツールバーを使用可能にするには、各種の要素のうち2つ以上を定義します。
要素定義は、コントリビュータがページを編集するときにアクセスできるツールバーを制御するために使用されます。ただし、要素ごとに複数の異なる定義を作成して、コントリビュータに複数（3つ以上）のツールバー・オプションを提供できます。コントリビュータの役割と、コントリビュータが様々なページにどの程度寄与するのかを検討することが重要です。
要素定義の命名は慎重に行うことを強くお薦めします。これは、ページ上の場所やサイトの名前に基づいて命名すると、要素をあまり直観的に再利用できなくなるためです。Webサイト内のページ上の場所や、要素定義に含まれるWebサイト内の名前に基づいて要素に命名することはお薦めできません。要素定義の命名方法としては、element_WYSIWYG_fulleditやelement_text_undo_onlyのように、ツールバーにおける相対的なアクセス内容をリストするのが最適です。
要素定義には、elementという語句で始まる名前が付けられています。このため、コンテンツ・サーバーで要素を検索すると、すべての要素がまとめて表示されます。Webサイトの名前を含めるようなネーミング規則を使用した場合も、Webサーバーでアセットはグループ化されますが、その場合、同じ定義を複数のWebサイトで使用するときには、定義をあまり直観的に管理できなくなります。
リージョン・テンプレートを作成する前にリージョン定義を作成する必要があります。定義（リージョン定義、プレースホルダ定義、要素定義）は、表示されるデータと、コントリビュータがデータを対話処理する方法を制御します。テンプレート（リージョン・テンプレート、サブテンプレート）は、データの表示方法を制御します。リージョン定義は特に、コントリビュータで開かれる要素（WYSIWYG、イメージ専用など）を制御します。リージョン・テンプレートは、要素の配置およびその特定のデータをWebページに表示する方法を調整するために使用されます。
リージョン・テンプレートを作成すると、そのテンプレートをリージョン定義に関連付けるよう求められます。定義が作成されていないと、後でリージョン・テンプレートを定義に関連付ける操作が困難になります。
一般的なリージョン定義には複数の要素が含まれます。また、これらの要素の様々な組合せは、複数の異なるリージョン・テンプレートで使用されます。つまり、リージョン定義はできるかぎり広範で包括的なものになります。これにより、複数のリージョン・テンプレートから同じ要素グループ（ただし同じデータ・ファイルである必要はない）にアクセスできるようになり、要素を様々な方法で配列することが可能になります。ただし、リージョン定義に多くの要素定義を追加する場合は、リージョン定義にリストされているすべての要素定義がコントリビュータで開かれることに注意する必要があります(ページで一部のみを表示可能にしている場合も同様です)。
リージョン定義によりコントリビューション・モデルでの要素の使用が制限されるため、リージョン定義用の適切なネーミング規則に従うことが特に重要です。このようにすると、作成した別のリージョン・テンプレートに最適な定義を選択するときに便利です。
リージョン・テンプレートは、データ・ファイルをHTMLに書式設定するアセットです。リージョン・テンプレートを使用して、要素に含まれないコンテンツ（テキスト、イメージまたは他の単純なアイテムなど）と要素を配置します。リージョン・テンプレートは、再利用する必要があるレイアウトに要素(リージョン定義によって制限される)を配列して、Webサイト内の様々な場所に適切に表示するために使用されます。
リージョン・テンプレートで使用できる要素は、テンプレートのリージョン定義に要素定義がリストされているもののみです。ただし、リージョン・テンプレートでは、定義にリストされているすべての要素を使用する必要はありません。このため、使用可能な各種のテンプレートに大幅な多様性がもたらされます。
リージョン・テンプレートは、Webサイト用に作成する最大数のアセットとなる可能性があります。このため、リージョン・テンプレートを作成するときに使用するネーミング規則は重要です。名前は、使用されるページ上の場所やWebサイト内の場所ではなく、テンプレートの機能を定義するものにする必要があります。regtem_titlebodyviewやrt_bodynoimageなどの名前にしておくと、regiontemplate14やRT_SupportForumなどの名前の場合よりも、サイトを管理するときに役立ちます。
リージョン・テンプレートには、要素を通じて渡されるデータ・ファイルに含まれないHTML、イメージおよび他のアセット（たとえば、リージョン・テンプレート固有のCSS）を含めることができるため、テンプレートを使用して、コントリビュータが編集できない情報やテキストを組み込むことができます。ただし、その情報はコントリビュータが編集するコントリビュータ・データ・ファイルには含まれないことを理解する必要があります。つまり、リージョン・テンプレートを再利用すると、そのリージョン・テンプレートに関連付けられているデータは、種類に関係なく同じ方法で開きます。さらに、その特定のデータを変更できるのはデザイナに制限されます。コントリビュータは、プレースホルダを通じてリージョン・テンプレート内の要素に割り当てられるデータをすべて作成および編集できます。ただし、要素の外部に配置されたデータのうち、リージョン・テンプレート内に存在するものは静的になります。
サブテンプレートは、プレースホルダを含めることができるHTMLの主要部分です。このため、サブテンプレートは、Webサイトで表示できるページの様々な方法を維持したまま、ページ・テンプレートの数を減らす方法として非常に役立ちます。
サブテンプレートを表示できるのはプレースホルダ内のみです。サブテンプレートに含めることができるのは、プレースホルダまたはHTMLやイメージなどの静的コンテンツのみです。また、サブテンプレートはCSSファイルを参照できます。
サブテンプレートを計画する場合、次の質問に回答する必要があります。
サブテンプレートを使用するメリットの1つに、Webサイトで使用されるpページ・テンプレートの数を減らすことができるという点があります。サブテンプレートを使用すると、プライマリ・ページとセカンダリ・ページの両方に同じページ・テンプレートを使用できます。
このため、計画はきわめて重要になります。サブテンプレートを使用するとページ・テンプレートの数を減らすことができますが、サブテンプレートを使用してWebサイトを管理することにもなります。ページ・テンプレートの数が少なくなるほど、サイト全体の変更が簡単になります。また、サブテンプレートを使用して、一定レベルの静的情報を追加することもできます。これは、1つのページにHTML、イメージおよび他の類似した静的サイト・アセットを追加して特定の数のページ（セカンダリ・ページなど）に配置できるためです。こうすることで、サブテンプレートから個別に管理する必要がなくなります。
サブテンプレートを使用すると、1つのプレースホルダ内に複数のプレースホルダを配置することもできます。プレースホルダにはサブテンプレートを含めることができ、サブテンプレートにはプレースホルダを含めることができるため、未定になっている将来のWebサイト拡張のためにサブテンプレートを保存しておくことができます。
プレースホルダ定義では、各プレースホルダが、そのプレースホルダに関連付けられたコンテンツおよび他のアセットに連結して表示されます。
プレースホルダ定義を計画する場合、次の質問に回答する必要があります。
プレースホルダ（プレースホルダ定義と混同しないこと）は、デザイナ・アプリケーションでページに表示される単なるマークです。プレースホルダは、デザイナにおける概念的な境界にすぎません。
図4-3に示されているように、プレースホルダは、placeholderという語句を使用した単なるマーカーであり、プレースホルダの名前をリストします。プレースホルダがWebページで使用する実際のスペースは、そこに配置されるコンテンツのサイズで決まります。
プレースホルダに関連付けられたデータは、プレースホルダが配置されているページに依存します。この状態になるのは、サイト構造が完成し、Webサイトのセクションにコンテンツを配置し始めた後です。
プレースホルダの機能とプレースホルダに含まれるデータは、プレースホルダ定義によって決まります。つまり、広範な領域でコンテンツを使用および再利用するためには、プレースホルダを使用可能なセクションとして表示する必要があります。たとえば、ページ・テンプレートには、ナビゲーションとヘッダー・イメージ、およびその両者の間のプレースホルダのみを含めるのが一般的です。
図4-3には、バナー、フラグメントであるサイド・ナビゲーション部分およびプレースホルダのみが存在します。これらはすべて表を使用して配列されます。この基本設計は、プレースホルダの使用方法に応じて、Webサイトの全体構造として確実に使用できます。
このプレースホルダは、任意の数のページにおいて、そのページに固有のコンテンツで簡単に置き換えられます。設計の計画において、最小数のページ・テンプレートに基づき、複数のプレースホルダとサブテンプレートを様々な方法で使用してサイトを作成することにした場合、コンテンツをより小さなプレースホルダに分割できます。
プレースホルダは、コンテンツが表示されるページ上の領域を定義するためのタグにすぎません。プレースホルダ定義は、情報を渡すのに使用できるリージョン定義（およびそれに関連付けられたリージョン・テンプレート）とサブテンプレートをリストします。
また、プレースホルダ定義を通じて、プレースホルダごとに他の詳細を制御することもできます。このアイテムには、ワークフロー、プレースホルダを通じて表示されたデータをコントリビュータが編集できるかどうか、メタデータをコントリビュータが編集できるかどうか、Webサイト使用状況レポートを表示する機能およびコンテンツ追跡レポートを表示する機能などがあります。
多くのWebサイトは、ホームページと他のすべてのページという2つの単純なページ・テンプレートに分類できます。Webサイトでは、ホームページをレイアウトや設計の点で、Webサイト内の他のページと異なるものにする場合があります。
サイトには複数のテンプレートが存在する場合があります。また、Webサイト全体を1つのページ・テンプレートと連携させることも可能です。複数のページ・テンプレートを使用してWebサイトを設計する場合、サブテンプレートを使用してページ・テンプレートの数を減らすことを検討する必要があります。Webサイトのページ・テンプレートの数が少なくなるほど、サイト全体の変更が簡単になります。
ページ・テンプレートを計画する場合、次の質問に回答する必要があります。
フラグメントは、動的コンテンツまたはカスタム・スクリプトで作成されたコンテンツを管理する場合に特に役立ちます。また、フラグメントは、サイト・アセットおよびコントリビュータ・データ・ファイルとは別に管理するコンテンツにも使用できます。フラグメントには、コピーライト文のように簡単なものから、JavaScriptメニューのように複雑なものまであります。フラグメントの数とその複雑さは、サイトの状況に応じて変化します。
フラグメントの詳細は、第13章「フラグメントの操作」を参照してください。
プライマリ・ページとセカンダリ・ページには、同じページ・テンプレートを使用できます。ただし、セカンダリ・ページは、動的に配置されるコンテンツを含めることができるページにすぎないため、動的に配置されるコンテンツのメリットについて、ページ・テンプレート（およびプレースホルダとプレースホルダ定義）の表示方法に対する影響を検討する必要があります。
セカンダリ・ページは、コントリビュータによりサイトに追加されるコンテンツの背景として機能します。コントリビュータ・データ・ファイルまたはネイティブ・ドキュメントのWebサイトへの追加をコントリビュータに許可する場合、セカンダリ・ページは必須です(どちらのファイルも新規Webページになります)。これらのファイルは、動的リスト、検索、またはリンクのターゲットによって選択されたときに、サイトで使用可能になります。
最初にプライマリ・ページのみでサイトを構築し、プライマリ・ページにコントリビューション・リージョンを設定して、コントリビュータがサイトに発行するコンテンツのタイプが正確にわかるまで、セカンダリ・ページは使用せずに取っておく場合があります。その後、そのコンテンツを処理するためにセカンダリ・ページを追加できます。
Webサイト内のプライマリ・ページとセカンダリ・ページに同じページ・テンプレートを使用するかどうかに関係なく、ページ・テンプレートに適切な名前を付けることが重要です。これは、Site Studio内の他のすべてのサイト・アセットでも同様です。
図4-4に示されている例について検討します。
プライマリ・ページとセカンダリ・ページの両方に同じページ・テンプレートが使用されています。ページ・テンプレートの名前は、初期の配置をベースとしたテンプレートの場所に基づいています。また、サイトを拡張したときに、ページ・テンプレートを再利用したため、配列に混乱が生じています。
サイト・アセット（ページ・テンプレートを含む）の命名は、ページ・テンプレートの使用方法に基づいて行うのが最も効率的です。アセットがWebサイトで使用される場所に基づくネーミング規則(たとえば、page_template_primarypage)や、作成順序に基づくネーミング規則(たとえば、pagetemplate3)を使用すると、アセットを管理しにくくなる可能性があります。
サイト階層は、Webサイトのフレームワークです。Webページの作成を開始する前に、時間をかけて階層を計画する必要があります。サイト階層は、サイトのコンテンツの編成および管理に役立つだけでなく、Site Studioが特定のタスクを自動化する際にも使用されます。
サイト階層を計画する場合、次の質問に回答する必要があります。
深い階層では、情報が複数のレベルに配置され、様々なカテゴリにグループ化されます。この階層は、大規模な組織や、Webサイトの拡張が見込まれる組織に適しています。
Webサイトを計画する場合、サイト内のWebページの階層についてかなり慎重に検討する必要があります。Webサイトの階層は、必要な深さにすることができます。ホームページからは必要な数の異なるセクションを作成し、セクションには必要な数のセクションを含めることもできます。ただし、階層を設計するときには、構造は必要に応じて広範にできます（つまり、セクションは任意の深さにネストできます）が、結果として、扱いにくいURLが作成されることに注意する必要があります。Webサイトでネストされるセクションの範囲が広くなるほど、その情報を取得するためのURLが長くなります。通常、これは大きな考慮事項ではありませんが、デザイナによっては重要なポイントになる場合があります。
サイト階層にリストされているセクションごとに、1つのプライマリ・ページと1つのセカンダリ・ページを割り当てることができます。セカンダリ・ページは、置換え可能なコンテンツを含むページであるため、セクション内で複数のバージョンのページを作成するのに使用されます。セクション内のプライマリ・ページは、そのセクションに対して開かれるページであるため、そのセクションのランディング・ページと考えられます。
デザイナはサイト階層を使用してサイトを管理しますが、訪問者は階層を使用してコンテンツを参照および検索します。Site Studioでは、ページ・テンプレートにナビゲーション・フラグメントを追加すると、フラグメントによってサイト階層が読み取られ、サイト・ナビゲーション全体を構成するリンクが生成されます。サイトのセクションの追加、削除および名前変更は簡単で、これらの変更はサイト・ナビゲーションに反映されます。サイト階層を構成する際には、訪問者の観点から慎重に検討する必要があります。
サイト階層には、Products、Services、About Usなどの名前を持つ個々のセクションが含まれます。これらの名前は重要です。これらの名前は、サイトのコンテンツの編成に役立つだけでなく、訪問者が参照するサイトのナビゲーションにも表示されます。それぞれの名前が、対応するセクションの内容を反映しているかどうかを確認するために、各名前を定期的に再検討することをお薦めします。
もう1つ、サイト階層の編成時に検討する必要のあることは、コントリビュータとサイト訪問者がWebブラウザのアドレス・バーで参照するWebサイト・アドレスです。デフォルトでは、サイト階層のセクションに割り当てられた名前（ラベル）が使用されます。
必要に応じて、各セクションに異なるパス名およびページ名を指定することで、これらの値を上書きできます(7.2.2項「サイト・アドレスに使用されるパスの変更」を参照)。前もってこれらの名前を計画することで、サイト・アドレスまたはアドレスで使用されるパスを後から変更することを最小限にとどめるのが最適です。これらを後から変更すると、コントリビュータやサイト訪問者が使用するリンクの破損またはショートカットの欠落につながる可能性があります。
サイトを計画する場合、セクションごとに新規ページ・テンプレートを作成するか、他のセクションですでに使用されているページ・テンプレートを再利用できます。少数のページ・テンプレートを使用して設計すると、管理するアセットの数が減るため、Webサイト全体を管理しやすくなります。
ページ・テンプレートを再利用すると、Webサイトのルック・アンド・フィールを1つまたは少数のページ・テンプレートの形式に維持できます。また、ページ・テンプレートの変更は即座にサイト全体に反映されます。
セクションごとに新しく一意のページ・テンプレートを作成すると、サイト・レイアウト全体の設計の柔軟性が向上します。一意の設計を作成するか、異なるページ・テンプレートを多少変更して、ページ・テンプレートに表示するコンテンツに対応します。ただし、サイトに重大なグローバル変更を行う場合、複数のページ・テンプレートを変更する必要があります。これは、繰返しの多い作業となり、間違いや一貫性のない状態が発生しやすくなります。
複数のページ・テンプレートを選択する場合、1つまたは少数のフラグメントのみをグローバル変更すれば済むように、できるかぎり参照スニペットを含むフラグメントを再利用してください。
ただし、プレースホルダを含むサブテンプレートを慎重に使用すると、一般的にページ・テンプレートの数を減らすことができます。
ページ・テンプレートを扱うには、いくつかの方法があります。サイト階層のセクションごとに、1つのプライマリ・ページと1つのセカンダリ・ページを割り当てることができます。
プライマリ・ページは、Webサイトのそのセクションに移動したときに、ユーザーが最初に目にするWebページです(従来のWebサイトのデフォルト・ページとほぼ同じです)。ページ上の情報は、静的にリンクされます。コントリビュータは、プライマリ・ページのコントリビュータ・データ・ファイルまたはネイティブ・ドキュメントを変更したり、コントリビュータのインタフェースからデータ・ファイル内の情報を変更したりできます。
セカンダリ・ページは、コンテンツを動的に配置できるページです。セカンダリ・ページに静的コンテンツを含めることはできますが、セカンダリ・ページが有用なのは、動的に配置されるコンテンツを含めることができる点にあります。
プライマリ・ページのみで構成されたサイトを作成することもできますが、サイトを拡張する場合、新規プライマリ・ページを含んだ新規セクションを作成する必要があります。セカンダリ・ページを使用すれば、サイトはコントリビュータが発行する追加のコンテンツに基づいて自然に成長するため、デザイナは何もする必要がありません。サイトは、セカンダリ・ページの使用によりスケーラビリティが大幅に向上します。
プライマリ・ページとセカンダリ・ページには、同じページ・テンプレートを使用できます。ページ・テンプレートは、そのテンプレートを使用するページがプライマリかセカンダリかということには関係しません。
コントリビュータ・データ・ファイルとネイティブ・ドキュメントは、コンテンツ・サーバーの単一のWebサイトおよび複数のWebサイト全体で共有および再利用できます。これらのアイテムをサイトに追加する場合、関連付けられたサイト・アセットを再利用して、アイテムを表示する特定の場所または複数の場所を指定できます。
コンテンツ・サーバーで現在Webサイトに関連付けられていないコンテンツでも、サイトに追加できます。同じドキュメントを、それぞれ独自のルック・アンド・フィールで、複数のバージョンを作成することなく異なるサイトに表示できます。
ただし、この方法を選択する場合、そのコンテンツがWebサイトや一般公開に適していることを確認する必要があります。これを確認するには、ワークフローを実装するのが適しています。また、コンテンツが表示される各セクションに、置換え可能なリージョン・テンプレートを含むセカンダリ・ページがあることも確認する必要があります。
デザイナは、サイト階層を自分で作成および管理するか、その役割をサイト・マネージャに委任することができます。サイト・マネージャは、マネージャ・アプリケーションを使用して、セクションの作成や変更などを行うことができます。
これらの変更により、サイトの外観と動作が大きく変化する可能性があります。これらの変更と、それによるサイト構造、ワークフロー、レプリケーション、コントリビュータの役割などに対する影響について検討する必要があります。
マネージャ・アプリケーションの設定方法の詳細は、第16章「マネージャの設定」を参照してください。
