| 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サイトの作成が成功するための鍵です。テキスト、グラフィックおよびスクリプトをページ・テンプレートに挿入し始める前に、そのサイトの機能または役割は何なのかをよく考える必要があります。そのサイトは、部門レベルのサイトなのか、会社全体のサイトなのか、社内用なのか、それとも外部向けなのでしょうか。そのサイトを閲覧すると見込まれるユーザーの数はどれほどでしょうか。そのサイトにコントリビュートすると見込まれるユーザーの数はどれほどでしょうか。各コントリビュータに対してそれぞれ異なるセキュリティ・アクセス・レベルを設定することになるのでしょうか。サイトのレプリケートや公開を予定していますか。そのサイトは時間の経過とともに成長していくと予想されていますか。
これらはすべて、作業を開始する前に考慮する必要がある重要な質問です。個々のケースでの特定のニーズは予測できませんが、サイトを開発する前に考慮する必要がある重要なポイントをいくつかあげることはできます。
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サイトの数百から数千ものページの作成に費やす時間が短縮されます。
サイト階層はWebサイトのフレームワークです。Webページの作成を始める前に、階層の計画に多くの時間をかける必要があります。サイト階層は、サイト上のコンテンツの編成と管理に役立つのみでなく、Site Studioによって特定のタスクを自動化するためにも使用されます。
深い階層では、情報が複数のレベルに配置されて詳細に分類されます。これは、大規模な組織やWebサイトの成長を予期している組織には適しています。
Webサイトを計画するときには、サイト内のWebページの階層について慎重に検討する必要があります。Webサイトの階層は、望みどおりに深くすることができます。ホームページから必要な数の異なるセクションを作成でき、各セクションにも必要な数のセクションを含められます。ただし、階層を設計するときには、構造は必要に応じて広げられるけれど(つまり、セクションのネストはどこまでも深くできますが)、そうするとURLが長くなりすぎる可能性があることを頭に置いておく必要があります。Webサイト内のセクションが深くネストされるほど、情報を取得するためのURLが長くなります。通常、これは些細な問題ですが、一部の設計者にとっては大きな問題になることがあります。
サイト階層内の各セクションは、それぞれプライマリ・ページとセカンダリ・ページを持つことができます。セカンダリ・ページはそのコンテンツを置換できるため、セクション内で1つのページの複数のバージョンを作成するために使用されます。セクション内のプライマリ・ページは、そのセクションにナビゲートすると開くページであり、そのセクションの待ち受けページのようなものと考えることができます。
サイト階層はサイトの管理にも役立ちますが、閲覧者にとっては目的のコンテンツを見つける手段になります。Site Studioでは、ページ・テンプレートにナビゲーション・フラグメントを追加すると、そのフラグメントにサイト階層が表示され、全体的なサイトのナビゲーションを構成するリンクが生成されます。サイトのセクションの追加、削除および名前変更は簡単に実行でき、それらの変更はサイトのナビゲーションに反映されます。この階層を構成するときには、閲覧者の使い心地について慎重に検討する必要があります。
サイト階層には、Products、Services、About Usなどの名前を持つ個々のセクションがあります。これらの名前は重要です。サイト上でのコンテンツの編成に役立つのみでなく、閲覧者が見るサイトのナビゲーション内にも表示されるからです。これらの名前がセクションに表示されるコンテンツを反映した名前になっていることを定期的に再確認してください。
サイト階層を組み立てるときに考慮する必要があるもう1つの点は、コントリビュータやサイト閲覧者がWebブラウザのアドレス・バーで見ることになるWebサイト・アドレスです。デフォルトでは、各セクションに付けられた名前(ラベル)がサイト階層内で使用されます。
これらの値は必要に応じて、各セクションについて別のパス名とページ名を指定することでオーバーライドできます。サイト・アドレスやアドレス内で使用するパスを後ほど変更すると、コントリビュータやサイト閲覧者が使用するリンクが切れたりショートカットが失われる可能性があるため、後で変更する必要性を最小限に抑えるために、事前に計画しておく必要があります。
ページ・テンプレートをどの程度再利用可能にするか
サイトを計画するときに、各セクション用にそれぞれ新規のページ・テンプレートを作成することも、他のセクションですでに使用されているページ・テンプレートを再利用することもできます。少数のページ・テンプレートを使用する設計にすると、管理するアセットの数が減り、Webサイト全体の管理が簡単になります。
ページ・テンプレートを再利用すると、Webサイトのルック・アンド・フィールを1つまたは少数のページ・テンプレートで維持でき、変更がただちにサイト全体に反映されます。
各セクションで固有の新しいテンプレートを作成すると、サイトのレイアウトの全体をより柔軟に設計できる可能性があります。固有のデザインを作成することも、その場所に表示するコンテンツに合せて別のページ・テンプレートに変更を加えることもできます。ただし、サイトに対して大きいグローバルな変更を行う場合は、複数のページ・テンプレートを変更する必要があります。それは、ミスや矛盾を招きやすい反復作業になる可能性があります。
複数のページ・テンプレートを使用する場合は、1つまたは少数のフラグメントのみを対象にグローバルな変更が行えるように、参照スニペットを備えたフラグメントをできるかぎり再利用してください。
ただし、プレースホルダを備えたサブテンプレートを適切に使用すれば、通常はページ・テンプレートの数を減らせます。
プライマリ・ページとセカンダリ・ページを両方とも使用する必要があるか
ページ・テンプレートの活用法は数通りあります。サイト階層の各セクションに、1つのプライマリ・ページと1つのセカンダリ・ページを割り当てることができます。
プライマリ・ページは、ユーザーがWebサイト上の当該セクションに移動したときに表示されるWebページです(従来のWebサイトのデフォルト・ページに似ています)。ページ上の情報は、静的にリンクされています。コントリビュータは、プライマリ・ページ上のコントリビュータ・データファイルまたはネイティブ・ドキュメント(つまりデータファイル内の情報)を、コントリビュータ・インタフェースを使用して変更できます。
セカンダリ・ページは、そのコンテンツを動的に配置できるページです。セカンダリ・ページに静的コンテンツを表示することもできますが、セカンダリ・ページの有用性は、動的に配置されるコンテンツを表示できる機能にあります。
全体がプライマリ・ページで構成されたサイトを作成することもできますが、その場合は、サイトを拡大するために新規のプライマリ・ページからなる新しいセクションを作成する必要があります。セカンダリ・ページを使用すれば、コントリビュータが追加のコンテンツを発行するとサイトが自動的に成長するため、設計者は何もする必要がありません。セカンダリ・ページを使用すると、サイトがはるかにスケーラブルになります。
プライマリ・ページとセカンダリ・ページに同じページ・テンプレートを使用できます。ページ・テンプレートは、そのテンプレートを使用するページがプライマリとセカンダリのどちらになるかには関係しません。
コンテンツをどのように再利用するか
コントリビュータ・データファイルとネイティブ・ドキュメントは、単一のWebサイト全体でも同じコンテンツ・サーバー内の複数のWebサイト間でも共有および再利用できます。これらの項目をサイトに追加するときには、その項目を表示する場所として、特定の場所を1つ指定するか、関連付けられたサイト・アセットを再利用することによって複数の場所を指定します。
現在コンテンツ・サーバー内のどのWebサイトにも関連付けられていないコンテンツをサイトに追加することもできます。同じドキュメントの複数のバージョンを作成する必要なしで、同じドキュメントを複数の異なるサイトにそれぞれ独自のルック・アンド・フィールで表示できます。
ただし、そのためには、コンテンツがそのWebサイトおよび公開に適していることを確認する必要があります。これを確実にするには、ワークフローの実装が適しています。また、そのコンテンツが表示される各セクションは、置換可能なリージョン・テンプレートを備えたセカンダリ・ページを持っている必要があります。
サイト・マネージャは必要か
設計者自身がサイト階層を管理することも、サイト・マネージャにその職務を任せることもできます。サイト・マネージャは、セクションの作成や変更など様々な操作を実行できます。
これらの変更により、サイトの外観と動作が大きく変化する可能性があります。これらの変更と、それがサイトの構造、ワークフロー、レプリケーション、コントリビュータの役割などに与える影響について、よく検討する必要があります。
サイト階層を計画し、Webサイトのアセットを準備するときには、コントリビューション・モデルについてよく考える必要があります。つまり、ユーザー(コントリビュータとマネージャ)がサイト上にコンテンツをどのように配置するかについて考慮する必要があります。
どの程度の量のコンテンツをユーザーがサイトに提供するか
背景色、配置デバイス(HTMLテーブルやCSSなど)、サイトのナビゲーション、カスタム・スクリプトなどは、設計者がサイトに追加する必要があります。しかし、各Webページのコンテンツの大部分(つまりページの実際の情報)は、コントリビュータが作成および編集できます。
Site Studioの能力を本当に使いこなすには、Webサイトのできるだけ多くの部分をコントリビュータに任せる必要があります。そうすれば、Webサイトによくあるボトルネックや遅延なしで、Webサイトが継続的に更新されるようになります。
どの程度ユーザーが制御できるようにするか
各ページ・テンプレートには、1つの大きなコントリビューション・リージョンを配置することも、複数の小さなコントリビューション・リージョンを配置することもできます。リージョン・テンプレート内には1つまたは複数の要素を配置でき、各要素はユーザー(コントリビュータ)がコンテンツを追加および編集できるフィールドとして表示されます。
テキストやグラフィックスの追加と編集、リストの更新など、特定の目的に使用できる、様々なタイプの要素があります。フォントの選択、フォント・サイズ、イメージ、表、カスタム・プロパティなど、一部の書式属性は、有効と無効を切り替えることができます。これらの選択は、特定のWebページをコントリビュータがどの程度制御できるようにするかによって決まります。また、検証機能または独自の検証スクリプトを使用して、どのようなコンテンツを追加できるかを強制することもできます。
ユーザーにサイトへのアクセス権を付与する前に、ユーザーとその組織内での役割およびそのユーザーのWebパブリッシングに関する知識について、知っておく必要があります。Webサイトのすべてのコントリビューション・リージョンに対してすべてのユーザーが同じアクセス権を持つようにする必要がある場合も、一部のユーザーのアクセスは制限し、残りのユーザーには完全なアクセスを許可する必要がある場合もあります。
たとえば、マーケティング部門のメンバーに対してはWebページ全体への完全なアクセスを提供し、それ以外の部門に対してはそのページの一部についてのみアクセスを提供するというケースが考えられます。それには、コンテンツ・サーバー上で異なるユーザーを設定し、各リージョンに異なるコントリビュータ・データファイルまたはネイティブ・ドキュメントを割り当て、それらのファイルに一意のセキュリティ・メタデータを割り当てる(コンテンツ・サーバー上のメタデータ・フレームワークを使用して)必要があります。
その結果、コントリビューション・モードのWebページでは、特定のコントリビュータが編集権限を持つファイルにのみコントリビューション・グラフィック(図3-1)が表示されるようになります。
Webサイトの各セクションにも、特定のユーザーのみがそのセクションを表示できるように指定するマークを付けられます。これは、Webサイト階層内のセクション設定によって制御されます。セクションへのアクセスを制限すると、そのセクションを表示(そして必要に応じて編集)できるのは、アクセスを許可されたユーザーのみになります。
コントリビュータは、Site Studioデータファイルに保存されたコンテンツの追加と編集のみでなく、ネイティブ・ドキュメント(Microsoft Word、Excel、PowerPointなどのアプリケーションで作成されたドキュメント)をサイトに追加することもできます。これらのドキュメントは、コンテンツ・サーバー上のDynamic Convertorコンポーネントを使用して、Webで表示できるレンディションに変換できます。
コントリビュータは、新規および既存のネイティブ・ドキュメントを直接Webサイトに追加できます(たとえば、リンク・ウィザードを使用してリージョンに割り当てたり、動的リストに追加することによって)。
コントリビュータがネイティブ・ドキュメントをWebサイトに発行することを許可する(そしてコントリビューション・リージョン、要素およびリスト・フラグメント内でそれを制御する)場合は、ネイティブ・ドキュメントの扱い方と従うべきスタイル・ガイドラインについてコントリビュータを教育する必要があります。
コントリビューション・プロセスをどのように調整するか
Webサイトの設計者、マネージャおよびコントリビュータは、サイトのどこをいつ更新する必要があるかを知っています。設計者が1人のコントリビュータまたはマネージャと共同作業する場合、設計者はサイトに対する必要な更新を通知する必要があります。特に、サイトに対する特定の変更を彼らに知らせる必要があります。ただし、コントリビュータも、コンテンツが追加されたことを設計者に警告する必要がある場合もあります。
設計者が複数のユーザーと共同作業する場合は、コミュニケーションがすぐに複雑になってしまう可能性があります。ある種のユーザー間のコミュニケーション・プロセスを組み込む必要があります。解決法の1つは、ワークフローを使用して公式のレビュー・プロセスを導入することです。これは、サイトに対する変更が実際に適用される前に様々な人がその変更をレビューして承認することを意味します。
Site Studioでは、サイト・アセットが再利用されることが前提となっています。アセット自体は同じ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サイトを調べる必要がないことも意味します。
Webサイトの計画が完了したら、そのWebサイトを構成するアセットを作成する必要があります。効率化のために、これらのアセットを特定の順序で作成することをお薦めします。
ほとんどのWebサイトにとって最も効率的な方法は、要素定義から始めてボトムアップでアセットを作成していくという方法です。
ステップ1: 要素定義の作成
ステップ2: リージョン定義の作成
ステップ3: リージョン・テンプレートの作成
ステップ4: サブテンプレートの作成
ステップ5: プレースホルダ定義の作成
ステップ6: ページ・テンプレートの作成
必ずしもアセットをこの順序で作成する必要はありません。しかし、この順序で作成すれば、Webサイトを迅速かつ効率的に組み立てられます。
最初に定義するのが最も効率的なアセットは要素です。要素は、コントリビュータが使用する編集インタフェースを定義するアセットです。各要素の固有の用途は、要素定義によって制御されます。コントリビュータがアクセスできる編集領域とツールバーを定義して要素定義を作成することで、そのデータ・ファイルに対してコントリビュータが何を実行できるかを定義することになります。
要素定義によって、ツールバー内のどの編集機能をコントリビュータが使用できるかを正確に制御できます。たとえば、コントリビュータがフォントのサイズと色は変更できないけれど、太字と斜体は使用できるようにすることもできます。通常は、各種の要素(WYSIWYG、テキストのみ、イメージのみ、静的リスト、動的リストおよびカスタム)を少なくとも1つは定義し、Contributor内の異なるツールバーに対応するために各タイプの要素をそれぞれ複数定義します。
要素定義は、コントリビュータがページを編集するためにアクセスできるツールバーを制御するために使用されます。ただし、コントリビュータに対してツールバーのオプションを1つか2つではなく複数提供できるように、各要素について複数の異なる定義を作成する場合もあります。コントリビュータの役割と彼らが様々なページにどの程度コントリビュートするかについて、考慮することが重要です。
要素定義の名前はよく考えて付けてください。ページ内での場所やサイトの名前に関連する名前を要素に付けると、要素を直観的に再利用することが難しくなる可能性があるためです。ページ上またはWebサイト内の場所を示す名前を要素に付けたり、要素定義内でWebサイト内の名前を使用することは避けてください。要素定義のネーミング規則のオプションとして、element_WYSIWYG_fulleditやelement_text_undo_onlyのように、ツールバー内の機能にどの程度アクセスできるかを示す名前を付けるという方法もあります。
これらの要素定義の名前がelementという単語で始まっている点に注意してください。これは、コンテンツ・サーバーで要素を検索するときにすべての要素がまとまって表示されるようにするためです。Webサイトの名前を含めるなどの他のネーミング規則でもWebサーバー内のアセットをグループ化できますが、その方法では、複数のWebサイトで同じ定義を使用する場合に定義を直観的に管理しにくくなります。
リージョン・テンプレートを作成する前に、リージョン定義を作成する必要があります。定義(リージョン定義、プレースホルダ定義、要素定義)は、どのデータが表示され、そのデータに対してコントリビュータがどのような操作を実行できるかを制御します。テンプレート(リージョン・テンプレート、サブテンプレート)は、データがどのように表示されるかを制御します。リージョン定義は特に、Contributorでどの要素(WYSIWYG、イメージのみ、その他)が開くかを制御します。リージョン・テンプレートは、要素の配置と、その特定のデータがWebページ上でどのように表示されるかを調整するために使用されます。
リージョン・テンプレートを作成するときには、そのテンプレートをリージョン定義に関連付けるように求められます。定義が関連付けられていないリージョン・テンプレートに、後になって定義を関連付けることは簡単ではありません。
典型的なリージョン定義には複数の要素が含まれており、それらの要素の様々なコントリビューションが複数の異なるリージョン・テンプレートで使用されます。つまり、リージョン定義ができるかぎり幅広く包括的なものになっています。それにより、複数のリージョン・テンプレートが同じ要素グループ(同じデータファイルである必要はありません)にアクセスしてそれらを異なる配置で表示することが可能になります。
リージョン定義はコントリビューション・モードでの要素の可用性を制限するため、適切なリージョン定義ネーミング規則に従うことが特に重要です。これは、作成した様々なリージョン・テンプレートに最も適した定義を選別する役に立ちます。
リージョン・テンプレートは、データファイルをHTMLにフォーマットするアセットです。リージョン・テンプレートは、要素の中に含まれないテキスト、イメージまたはその他の単純な項目や、要素などのコンテンツを配置するために使用されます。リージョン・テンプレートは、Webサイト内の別の場所に適していると判断されたときに再利用することを意図したレイアウトに要素(リージョン定義によって制限されます)を配置するために使用されます。
リージョン・テンプレートに配置できる要素は、そのテンプレートのリージョン定義に要素定義がリストされている要素のみです。ただし、定義にリストされた要素をリージョン・テンプレートがすべて使用する必要はありません。これにより、テンプレートごとにコンテンツに大きな多様性を持たせることができます。
リージョン・テンプレートはたいていの場合、Webサイト用に最も数多く作成するアセットです。そのため、リージョン・テンプレートの作成で使用するネーミング規則が重要になります。テンプレートがページ上またはWebサイト内のどこで使用されるかではなく、テンプレートが何をするかを定義する助けになる名前を付けてください。サイトをメンテナンスするときには、regtem_titlebodyviewやrt_bodynoimageのような名前の方が、たとえばregiontemplate14やRT_SupportForumのような名前より役に立ちます。
リージョン・テンプレートには、要素を通じて渡されるデータファイルの一部ではないHTMLやイメージやその他のアセット(たとえば、リージョン・テンプレート固有のCSS)を含めることができるため、コントリビュータが編集できない情報およびテキストを組み込むためにテンプレートを利用できます。ただし、その情報はコントリビュータが編集するコントリビュータ・データファイルの一部ではないことを理解することが重要です。つまり、リージョン・テンプレートに関連付けられたデータは、そのテンプレートが再利用されるときに、そのテンプレートにどのようなデータが関連付けられるかに関係なく、まったく同じように表示されます。また、その特定のデータを変更できる人は、設計者のみです。コントリビュータはプレースホルダを通じて、リージョン・テンプレート内の要素に関連付けられるデータの作成および編集を行えますが、要素の外に配置されたものはリージョン・テンプレートに属する情報であるため、静的です。
サブテンプレートはHTMLの主要部分であり、プレースホルダを含むことができます。これにより、Webサイト内のページを複数の異なる方法で表示できる機能を確保しながらページ・テンプレートの数を減らす手段として非常に役に立ちます。
サブテンプレートはプレースホルダの中にのみ表示できます。サブテンプレートに含められるのは、プレースホルダか、HTMLやイメージなどの静的コンテンツのみです。サブテンプレートはCSSファイルを参照することもできます。
サイトにサブテンプレートは必要か
サブテンプレートを使用する利点を1つは、Webサイト内で使用されるページ・テンプレートの数を減らせることです。サブテンプレートを使用すれば、プライマリ・ページとセカンダリ・ページに同じページ・テンプレートを使用できます。
これが、計画が不可欠である理由の1つです。サブテンプレートによってページ・テンプレートの数を減らせますが、その一方で、そのWebサイトに関してサブテンプレートを管理する必要が生じます。ページ・テンプレートの数が減ると、サイト全体に対する変更が簡単になります。サブテンプレートを使用すると、特定の数のページ(たとえばセカンダリ・ページ)に配置するHTML、イメージおよび他の類似した静的サイト・アセットをページに追加できるため、サブテンプレートはある程度の静的情報を追加する目的にも使用できます(サブテンプレートに含めない場合、これらの静的情報はサブテンプレートとは別個に管理する必要があります)。
サブテンプレートは、単一のプレースホルダの中に複数のプレースホルダを配置する手段としても使用できます。プレースホルダにはサブテンプレートを、サブテンプレートにはプレースホルダを含めることができるため、まだ決まっていないWebサイトの将来の拡張に対応できるようにサブテンプレートを配置しておくことも考えられます。
プレースホルダ定義は、各プレースホルダを、コンテンツやそのプレースホルダに表示するために関連付けられた他のアセットに結び付ける働きをします。
プレースホルダはページ上でどのような働きをするか
プレースホルダはプレースホルダ定義とはまったく別物であり、Webページ上のコントリビューション・リージョン(つまり編集可能な領域)の場所を識別するための、アプリケーション内での単なるページ上のマークです。プレースホルダは単なる概念上の境界です。プレースホルダがWebページ上で使用する実際の場所の大きさは、その中に配置されるコンテンツのサイズによって決まります。
プレースホルダに関連付けられるデータは、そのプレースホルダがどのページ上にあるかによって決まり、その決定はサイト構造が完成してWebサイトの各セクションへのコンテンツの配置が始まった後で行われます。
プレースホルダがどのように機能し、プレースホルダに何が含められるかを決めるのは、プレースホルダ定義です。つまり、プレースホルダは広範囲の各領域でコンテンツを使用および再利用するために使用できるセクションであると見なす必要があります。たとえば、ナビゲーションとヘッダー・イメージのみを備え、その間にはプレースホルダ以外何もないページ・テンプレートは、珍しくありません。このプレースホルダは、それぞれ固有のコンテンツを表示する任意の数のページと簡単に置換できます。最小限の数のテンプレートを基礎として複数のプレースホルダとサブテンプレートを様々に使い分けてサイトを作成するという設計計画になっている場合は、コンテンツをより小さいプレースホルダに分割できます。
プレースホルダ定義は何を制御するのか
プレースホルダは、コンテンツが表示されるページ上の領域を定義するためのタグにすぎません。プレースホルダ定義には、情報を渡すためにどのリージョン定義(およびそれに関連付けられたリージョン・テンプレート)およびサブテンプレートを使用できるかがリストされます。
また、プレースホルダ定義を通じて、各プレースホルダごとに他の詳細も制御できます。このような項目には、ワークフロー、プレースホルダを通じて表示されたデータをコントリビュータが編集できるかどうか、コントリビュータがメタデータを編集できるかどうか、Webサイト使用状況レポートを表示する機能、およびContent Trackerレポートを表示する機能などが含まれます。
多数のWebサイトを、2つの単純なページ・テンプレートに要約できます。その2つとは、ホームページと他のすべてのページです。レイアウトとデザインがWebサイト内の他のページと異なるホームページを持つWebサイトは珍しくありません。
サイトによっては、複数のページ・テンプレートが使用されています。また、Webサイト全体で1つのページ・テンプレートを使用することもできます。複数のページ・テンプレートを使用するようにWebサイトを設計する場合は、おそらくページ・テンプレートの数を減らすためにサブテンプレートの使用を考慮する必要があるでしょう。Webサイトのページ・テンプレートの数が少なければ、サイト全体に対する変更がはるかに簡単になります。
プライマリ・ページとセカンダリ・ページに別々のテンプレートが必要か
プライマリ・ページとセカンダリ・ページの両方で同じページ・テンプレートを使用できます。ただし、コンテンツを動的に配置できるのはセカンダリ・ページのみであるため、ページ・テンプレートの外観(およびプレースホルダとプレースホルダ定義)に対する影響を考慮する必要があります。
セカンダリ・ページは、コントリビュータによってサイトに追加されたコンテンツのバックドロップとして機能します。新規のコントリビュータ・データファイルまたはネイティブ・ドキュメント(両方とも新規のWebページになります)をコントリビュータがサイトに追加できるように設定する場合は、セカンダリ・ページが必須です。これらのファイルは、動的リスト、検索またはリンクのターゲットによって選択されたときにサイトで使用できるようになります。
最初はプライマリ・ページのみを持つサイトを構築しておき、その後プライマリ・ページ上にコントリビューション・リージョンを設定するまで、そしてコントリビュータがそのサイトに発行するコンテンツの種類がわかるまで、セカンダリ・ページの作成を保留にしておくという方法をとることになるでしょう。その後、そのコンテンツ用のセカンダリ・ページを追加できます。
Webサイトのプライマリ・ページとセカンダリ・ページに使用するページ・テンプレートが同じであっても異なっていても、そのページ・テンプレートに適切な名前を付けることが重要です。これは、Site Studio内のどのアセットでも同じです。たとえば、あるページ・テンプレートをプライマリ・ページとセカンダリ・ページの両方に使用するとします。そのページ・テンプレートの名前として、そのテンプレートが最初にサイト内に配置された場所に基づいた名前を付けると、サイトが拡張されてそのページ・テンプレートがセカンダリ・ページでも再利用されるようになったときに、混乱が生じる可能性があります。
ページ・テンプレートも含むサイト・アセットの最も効率的なネーミングは、そのページ・テンプレートがどのように使用されるかに基づいた名前を付けることです。Webサイト内でアセットが使用される場所に基づくネーミング規則(たとえばpage_template_primarypage)や作成された順序に基づくネーミング規則(たとえばpagetemplate3)を使用すると、アセットを管理しにくくなる可能性があります。
