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