Oracle® WebCenter Content Site Studio for External Applications開発者ガイド

11g リリース1(11.1.1)

B72419-01(原本部品番号:E13650-03)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Site Studio for External Applicationsについて

- 1.1 このリリースの新機能

- 1.2 Site Studio for External Applicationsの概要

- 1.3 Site Studio for External Applicationsのインストール

- 1.3.1 Oracle JDeveloperへの必要な拡張機能のインストール

- 1.3.2 Oracle WebCenter Content Server 11gR1での必要なコンポーネントの有効化

- 1.3.3 Oracle Content Server 10gR3での必要なコンポーネントの有効化

- 1.4 Site Studioプロジェクトの構造の理解

- 1.5 Site Studioのサイト・ファイルの理解

- 1.6 サイトURLフォーマットの理解

- 1.7 セキュリティおよびコントリビュータ認証の理解

- 1.8 コンテンツ・キャッシュの理解

- 1.9 Site Studioタグ・ライブラリを使用したサービス・キャッシュの理解

- 1.10 Site StudioのJSP/JSPXテンプレートの理解

- 1.10.1 ローカルJSPXテンプレートの作成

- 1.10.2 リモートJSPXテンプレートの作成

- 1.11 Oracle Site Studio Manager機能の組込み

- 1.12 HCSPベースのカスタム要素フォームの有効化

2 Site Studio Webサイトの理解

- 2.1 サイトのプレゼンテーションとコンテンツの分離

- 2.2 サイト・アセットの記憶域

- 2.3 サイトに関連するロール

- 2.4 プレゼンテーション・モデル

- 2.5 コントリビューション・モデル

- 2.6 サイトのオブジェクト階層

- 2.7 サイト・アセットの再利用

- 2.8 要素と要素定義

- 2.9 リージョン・テンプレートとリージョン定義

- 2.10 プレースホルダとプレースホルダ定義

- 2.11 サブ・テンプレート

- 2.12 ページ・テンプレート

- 2.13 コントリビュータ・データファイルとネイティブ・ドキュメント

- 2.14 プライマリ・ページとセカンダリ・ページ

3 Webサイトの計画

- 3.1 計画が重要である理由

- 3.2 サイト階層の計画

- 3.3 コントリビューション・モデルの計画

- 3.4 サイト・アセットの計画と命名

- 3.5 サイト・アセットの作成

- 3.5.1 要素定義の作成

- 3.5.2 リージョン定義の作成

- 3.5.3 リージョン・テンプレートの作成

- 3.5.4 サブテンプレートの作成

- 3.5.5 プレースホルダ定義の作成

- 3.5.6 ページ・テンプレートの作成

4 Site Studio Webサイトの構築チュートリアル

- 4.1 Site Studioプロジェクトの作成と接続

- 4.1.1 新規アプリケーションおよびプロジェクトの作成

- 4.1.2 コンテンツ・サーバー接続の作成

- 4.1.3 プロジェクトへの接続の追加

- 4.2 サンプルWebサイトの作成

- 4.2.1 コンテンツ・サーバーでのWebサイトの新規作成

- 4.2.2 コントリビューション・モードでのユーザー資格証明の指定

- 4.2.3 Webアプリケーション・デプロイメント・ディスクリプタの編集

- 4.2.4 ホームページの新規作成

- 4.2.5 サイトへのページ・テンプレートの関連付け

- 4.2.6 サイトの実行とホームページの表示

- 4.2.7 サイト・フラグメントの作成

- 4.2.8 要素定義の作成

- 4.2.9 リージョン定義の作成

- 4.2.10 リージョン・テンプレートの作成

- 4.2.11 プレースホルダ定義の作成

- 4.2.12 ホームページへのプレースホルダの追加

- 4.2.13 プレースホルダへのコンテンツの割当て

- 4.3 サイドバー・リンクの作成

- 4.3.1 静的リスト要素定義の作成

- 4.3.2 サイドバー・リージョン定義の作成

- 4.3.3 静的リスト・データファイルの作成

- 4.3.4 リージョン・テンプレートの作成

- 4.3.5 サイドバー・フラグメントの更新

- 4.3.6 サイドバー・コンテンツ・リージョン定義の作成

- 4.3.7 サイドバー・コンテンツ・リージョン・テンプレートの作成

- 4.3.8 サイドバー・コンテンツ・プレースホルダ定義の作成

- 4.3.9 サイトへのサイドバー・プレースホルダ・マッピングの追加

- 4.3.10 サイドバーへのコンテンツの割当て

- 4.4 動的変換ページの作成

- 4.4.1 変換定義の作成

- 4.4.2 ネイティブ・ドキュメント用ページ・テンプレートの作成

- 4.4.3 ネイティブ・ドキュメント用新規セクションの作成

- 4.4.4 ネイティブ・ドキュメント用リージョン定義の作成

- 4.4.5 ネイティブ・ドキュメント用リージョン・テンプレートの作成

- 4.4.6 ネイティブ・ドキュメント用プレースホルダ定義の作成

- 4.4.7 ネイティブ・ドキュメント・ページへのプレースホルダの追加

- 4.4.8 ネイティブ・ドキュメント・ページ上のプレースホルダに対するコンテンツの割当て

- 4.5 スタイル・シートの追加

- 4.5.1 スタイル・シートの新規作成

- 4.5.2 CSSファイル用サブディレクトリの作成

- 4.5.3 ページ・テンプレートへのスタイル・シートの追加

- 4.5.4 サンプルのCSSドキュメント

5 リモート・アプリケーション・サーバーへのSite Studioプロジェクトのデプロイ

- 5.1 アプリケーション・サーバー接続の作成

- 5.2 WebプロジェクトWARおよびアプリケーションEARデプロイメント・プロファイルの作成

- 5.3 JDeveloperによるプロジェクトのデプロイ

- 5.4 プロジェクトの手動デプロイ

- 5.5 WAR/EARアーカイブの接続情報の編集

- 5.5.1 接続情報の手動での編集

- 5.5.2 接続情報の手動での上書き

- 5.5.3 アプリケーション・サーバー上にデプロイされたファイルの編集

6 Site Studioアプリケーション・コンポーネントおよびテクノロジ

- 6.1 Site Studioアプリケーション・コンポーネント

- 6.2 Site Studioテクノロジ

- 6.2.1 Site Studioサーブレット

- 6.2.2 Site Studioフィルタ

- 6.3 Site Studioテクノロジの統合での使用

7 Site Studioタグ・ライブラリおよびヘルパー・メソッド

- 7.1 Site Studioタグ・ライブラリ

- 7.1.1 Site Studioタグの説明

- 7.1.2 Site Studio <wcm:context>タグ

- 7.1.3 Site Studio <wcm:dataFile>タグ

- 7.1.4 Site Studio <wcm:dynamicConversion>タグ

- 7.1.5 Site Studio <wcm:dynamicList>タグ

- 7.1.6 Site Studio <wcm:idcParameter>タグ

- 7.1.7 Site Studio <wcm:idcService>タグ

- 7.1.8 Site Studio <wcm:metadata>タグ

- 7.1.9 Site Studio <wcm:placeholder>タグ

- 7.1.10 Site Studio <wcm:staticPlaceholder>タグ

- 7.1.11 Site Studio <wcm:url>タグ

- 7.2 Site Studioヘルパー・メソッド

- 7.2.1 Site Studio <filterSections>メソッド

- 7.2.2 Site Studio <listSectionsForRows>メソッド

- 7.2.3 Site Studio <isNodeInNavigationPath>メソッド

- 7.2.4 Site Studio <lookupSection>メソッド

索引

Oracle® WebCenter Content

Site Studio for External Applications開発者ガイド

11g リリース1(11.1.1)

B72419-01(原本部品番号:E13650-03)

2011年11月

Oracle WebCenter Content Site Studio for External Applications開発者ガイド, 11g リリース1 (11.1.1)

B72419-01

Copyright © 2010, 2011, Oracle and/or its affiliates.All rights reserved.

原本著者:  Will Harris

原本協力者:  Rex Young, David Truckenmiller, Ron van de Crommert

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

Site Studio for External Applications開発者ガイドには、Site Studio for External Applicationsを使用して、Oracle WebCenter Content Serverにより管理されるWebサイトの設計および開発を担当するユーザーを支援する情報が記載されています。

対象読者

このドキュメントは、組織内で、Site Studioにより管理される組織のWebサイトを設計する担当者を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

Oracle Site Studio for External Applicationsおよび関連するテクノロジの詳細は、次のドキュメントを参照してください。

- Oracle WebCenter Content Site Studio for External Applications Java APIリファレンス

- Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス

- Oracle WebCenter Contentサービス・リファレンス・ガイド

- Oracle WebCenter Contentのインストレーション・ガイド

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Site Studio for External Applicationsについて

Site Studio for External Applicationsを使用すると、生産性を大幅に改善できます。また、組織は正確でタイムリな最新のWebコンテンツを維持し、すべての企業サイトで一貫したブランディングとプレゼンテーションを提供できます。Site Studioを使用すると、サイト・アーキテクチャとプレゼンテーションの制御を一元管理する一方で、コンテンツ開発と継続的なメンテナンスを部署またはその他のチームに分散できます。さらに、Site Studio for External Applicationsをサード・パーティ製のアプリケーション・サーバーと統合することもできます。

この項の内容は次のとおりです。

- 第1.1項「このリリースの新機能」

- 第1.2項「Site Studio for External Applicationsの概要」

- 第1.3項「Site Studio for External Applicationsのインストール」

- 第1.4項「Site Studioプロジェクトの構造の理解」

- 第1.5項「Site Studioのサイト・ファイルの理解」

- 第1.6項「サイトURLフォーマットの理解」

- 第1.7項「セキュリティおよびコントリビュータ認証の理解」

- 第1.8項「コンテンツ・キャッシュの理解」

- 第1.9項「Site Studioタグ・ライブラリを使用したサービス・キャッシュの理解」

- 第1.10項「Site StudioのJSP/JSPXテンプレートの理解」

- 第1.11項「Oracle Site Studio Manager機能の組込み」

- 第1.12項「HCSPベースのカスタム要素フォームの有効化」

1.1 このリリースの新機能

このリリースで新しく加わった拡張機能、アップグレードおよび変更は次のとおりです。

- Site Studioプロジェクトは、JDeveloperからリモートWebSphereアプリケーション・サーバーへバンドルおよびデプロイできます。詳細は、第5項「リモート・アプリケーション・サーバーへのSite Studioプロジェクトのデプロイ」を参照してください。

- Site Studio for External Applicationsは、Oracle Content Server 10gR3上で使用できます。詳細は、第1.3項「Site Studio for External Applicationsのインストール」を参照してください。

- JSPXテンプレートは、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3上に保存できます。詳細は、第1.10項「Site StudioのJSP/JSPXテンプレートの理解」を参照してください。

- Oracle Site Studio Manager機能をサイトに追加できます。詳細は、第1.11項「Oracle Site Studio Manager機能の組込み」を参照してください。

- Oracle WebCenter ContentのSSXAサーバーをサポートするために、自動的に構成されるドメインを生成するオプションがFusion Middleware構成ウィザードに用意されています。詳細は、『Oracle WebCenter Contentインストレーション・ガイド』またはFusion Middleware構成ウィザードのオンライン・ヘルプを参照してください。

- プリファレンス設定に、テンプレート・ファイルと定義ファイルがエディタで保存されるときにそれらのファイルを自動チェックインする設定が含められました。これらのプリファレンス設定はデフォルトで有効になっていますが、その設定はプリファレンス・パネルで変更できます(JDeveloperのメイン・メニューから、「ツール」→「プリファレンス」→「SiteStudio」を選択します)。

1.2 Site Studio for External Applicationsの概要

Site Studio for External Applicationsは、強力で柔軟性の高いWeb開発ツールです。アプリケーション・サーバー環境で企業規模のWebサイトを設計、構築およびメンテナンスするための包括的なアプローチを提供します。Webサイトの開発とテンプレートの作成は、JDeveloper環境で行います。ファイルやグラフィックなどのサイト・アセットは、コンテンツ・サーバーに保存して管理されます。テンプレートはそのタイプに応じて、コンテンツ・サーバーで保存して管理することも、プロジェクトの一部としてJDeveloperで保存して管理することもできます。

Site StudioのJSP/JSPXテンプレートは(ページ・テンプレート、リージョン・テンプレートおよびサブテンプレートを含む)、Oracle JDeveloperにローカルで保存することも、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3のインスタンスにチェックインすることもできます。

- ローカルで保存されるJSPXテンプレートは、通常はJDeveloperのプロジェクト内のサブディレクトリに置かれます。たとえば、プロジェクトに関連付けられたページ・テンプレートは、通常はすべて/wcm/templates/page/サブディレクトリに保存されます。

- JSPXテンプレートは、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3のインスタンスにも保存できます。この方法で保存したテンプレートは、アプリケーションを再デプロイしなくてもサイト上で変更および更新ができます。Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3に保存したJSPXテンプレートは、JDeveloper環境で編集することができ、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3へコミットする前に何回でもプレビューできます。

ローカルで保存されたJSPXテンプレートと、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3に保存されたJSPXテンプレートの両方を、プロジェクトに含めることができます。しかし、各プロジェクトを1つのテンプレート・タイプを使用して作成することをお薦めします。

1.3 Site Studio for External Applicationsのインストール

Site Studio for External Applicationsを使用するには、Oracle JDeveloperに2つの拡張機能をインストールし、Oracle WebCenter Content Serverで2つのコンポーネントを有効にする必要があります。

次の各セクションで説明する手順に従って、必要な拡張機能とコンポーネントをインストールしてください。

- 第1.3.1項「Oracle JDeveloperへの必要な拡張機能のインストール」

- 第1.3.2項「Oracle WebCenter Content Server 11gR1での必要なコンポーネントの有効化」

- 第1.3.3項「Oracle Content Server 10gR3での必要なコンポーネントの有効化」

1.3.1 Oracle JDeveloperへの必要な拡張機能のインストール

Site Studio for External Applications 11gR1を使用するには、Oracle JDeveloperのRemote Intradoc Client(RIDC)拡張機能とSite Studio for External Applications(SSXA)拡張機能をインストールする必要があります。

必要な拡張機能

次の拡張機能をOracle JDeveloperにインストールする必要があります。

- Oracle Remote Intradoc Client(RIDC)拡張機能11.1.1.6(11gR1 PS5)。JDeveloperのRemote Intradoc Client(RIDC)拡張機能は、Remote Intradoc Client(RIDC)スイート・ディストリビューションに含まれています。
RIDC拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)は、RIDCスイート・ディストリビューション(ridc-suite-11.1.1.6.zip)のmodules/jdevディレクトリにあります。

- Oracle Site Studio for External Applications(SSXA)拡張機能11.1.1.6(11gR1 PS5)。JDeveloperのSite Studio for External Applications(SSXA)拡張機能は、Webコンテンツ管理(WCM)スイート・ディストリビューションに含まれています。
SSXA拡張機能(oracle.ucm.wcm.jdev-11.1.1.6.zip)は、Webコンテンツ管理(WCM)スイート・ディストリビューション(wcm-suite-11.1.1.6.zip)のmodules/jdevディレクトリにあります。

Remote Intradoc Client(RIDC)スイート・ディストリビューションとWebコンテンツ管理(WCM)スイート・ディストリビューションは、Oracle Technology Network(OTN)(http://otn.oracle.com)からダウンロードできます。

インストールの手順

必要な拡張機能をOracle JDeveloper 11gR1にインストールするには、次の手順を実行します。

1. Remote Intradoc Client(RIDC)スイート・ディストリビューションとWebコンテンツ管理(WCM)スイート・ディストリビューションをOracle Technology Network(OTN)からダウンロードします。

2. Remote Intradoc Client(RIDC)スイート・ディストリビューション(ridc-suite-11.1.1.6.zip)を、Oracle JDeveloperインスタンスをホストしているシステム上の場所にアンバンドルします。

3. Webコンテンツ管理(WCM)スイート・ディストリビューション(wcm-suite-11.1.1.6.zip)を、Oracle JDeveloperインスタンスをホストしているシステム上の場所にアンバンドルします。

4. JDeveloperのメイン・メニューから、「ヘルプ」→「更新の確認」を選択します。

5. 「ローカル・ファイルからインストール」オプションを有効にします。

6. 「参照」をクリックして、アンバンドルしたRemote Intradoc Client(RIDC)スイート・ディストリビューション(ridc-suite-11.1.1.6.zip)へナビゲートします。

7. modules/jdevディレクトリにあるRIDC拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)を選択し、「開く」をクリックします。

8. 「次へ」をクリックして、拡張機能をインストールまたは更新します。

9. 「終了」をクリックします。

10. JDeveloperのメイン・メニューから、「ヘルプ」→「更新の確認」を選択します。

11. 「ローカル・ファイルからインストール」オプションを有効にします。

12. 「参照」をクリックして、アンバンドルしたWebコンテンツ管理(WCM)スイート・ディストリビューション(wcm-suite-11.1.1.6.zip)へナビゲートします。

13. modules/jdevディレクトリにあるSSXA拡張機能(oracle.ucm.wcm.jdev-11.1.1.6.zip)を選択し、「開く」をクリックします。

14. 「次へ」をクリックして、拡張機能をインストールまたは更新します。

15. 「終了」をクリックします。

JDeveloperの拡張機能の詳しいインストール方法は、『Oracle Fusion Middleware Oracle JDeveloperインストレーション・ガイド』またはOracle JDeveloperのオンライン・ヘルプを参照してください。

1.3.2 Oracle WebCenter Content Server 11gR1での必要なコンポーネントの有効化

Site Studio for External Applications 11gR1を使用するには、Oracle WebCenter Content ServerでSiteSudioコンポーネントとSiteStudioExternalApplicationsコンポーネントを有効にする必要があります。

SiteStudioコンポーネントとSiteStudioExternalApplicationsコンポーネントは両方とも、Oracle UCMのフル・インストールの一環としてインストールされるため、必要な操作はOracle WebCenter Content Server 11gR1上での有効化のみです。

Site Studio Webサイトでネイティブ・ドキュメントの動的変換を使用する場合は、Oracle Content ServerでDynamic Converterを構成する必要があります。

必須コンポーネント

Oracle WebCenter Content Server 11gR1では、次のコンポーネントを有効にする必要があります。

- SiteStudio 11.1.1.6(11gR1 PS5)。

- SiteStudioExternalApplications 11.1.1.6(11gR1 PS5)。

コンポーネントを有効化する手順は、Oracle WebCenter Content Serverのドキュメントまたはオンライン・ヘルプを参照してください。

1.3.3 Oracle Content Server 10gR3での必要なコンポーネントの有効化

Site Studio for External Applicationsは、Oracle Content Server 10gR3プラットフォームで使用できます。ただし、Universal Content Management 11gR1ディストリビューションは10gR3ディストリビューションとは大きく異なるため、いくつかの操作を手動で実行する必要があります。

必要な更新および追加構成

次の更新と追加構成を完了する必要があります。

- Oracle Content Server 10gR3が、最新の10gR35CoreUpdateおよび10gR35NativeUpdateバンドルとともにインストールされている必要があります。これらのバンドルは、Oracle Content ServerおよびDynamic Converterを必要な機能レベルに更新し、Webフィルタを必要なバージョンに更新します。

- SSUrlMapPlugin.dll(.so)11.1.1.3.0以上
このDLLは10gR35NativeUpdateバンドルに含まれています。バージョン番号を確認するには、コンテンツ・サーバーの「管理」メニューから「フィルタ管理」を選択します。

- Dynamic Converter 8.1.0.736以上
Site Studio Webサイトでネイティブ・ドキュメントの動的変換を使用する場合は、Oracle Content ServerにDynamic Converterビルド・バージョン8.1.0.736以上をインストールして構成する必要があります。

- JDKバージョン1.6がインストールされている必要があります(Oracle Content Server 10gR3はJDK 1.5とともに出荷されます)。

- Oracle Content Serverの構成ファイルIntradoc.cfgを更新して、新しいJDK 1.6のインストール・ディレクトリを参照するように設定する必要があります。そのエントリは、構成ファイルの#Additional Variablesセクションに追加します(例: JDK_custom="C:\Program Files\Java\SDK 1.6.0")。

- JDeveloper Site Studio for External Applicationsの接続ダイアログでは、Oracle WebCenter Content Server 11gインスタンス用としてデフォルトのWeb接続ポート値16200が事前に移入されています。Oracle Content Server 10gR3 Webサーバーはほとんどの場合、ポート80をリスニングします。したがって、Oracle Content Server 10gR3インスタンスに接続する場合は、この値を変更する必要があると考えられます。

必須コンポーネント

Server10gR3では、次のコンポーネントをインストールして有効にする必要があります。

- SiteStudio 11.1.1.6(11gR1 PS5)。
SiteStudio 11.1.1.6コンポーネントは、Site Studioスイート・ディストリビューションとともに提供されます(sitestudio-11.1.1.6.zip)。

- SiteStudioExternalApplications 11.1.1.6(11gR1 PS5)。
SiteStudioExternalApplications 11.1.1.6コンポーネント(oracle.ucm.wcm.idc-component-11.1.1.6.zip)は、Webコンテンツ管理(WCM)スイート・ディストリビューション(wcm-suite-11.1.1.6.zip)の/componentディレクトリにあります。

Site Studioスイート・ディストリビューションとWebコンテンツ管理(WCM)スイート・ディストリビューションは、Oracle Technology Network(OTN)(http://otn.oracle.com)からダウンロードできます。

コンポーネントのインストールと有効化の手順は、Oracle Content Server 10gR3のドキュメントまたはOracle Content Serverのオンライン・ヘルプを参照してください。

1.4 Site Studioプロジェクトの構造の理解

JDeveloper環境でのSite Studioプロジェクトの基本構造は、次のようになっています。

+ Site Files
+ templates
+ page
+ region
+ subtemplates
+ Web Content
+ wcm
+ WEB-INF
+ sites
- wcm-config.xml
- web.xml
- weblogic.xml

次のノードとファイルに注意してください。

- Site Files: これは、Web Content/wcmノードを指している仮想ノードです。

- Web Content/wcm: このノードには、このプロジェクトのページ・テンプレート、リージョン・テンプレートおよびサブテンプレートが含まれています。

- Web Content/WEB-INF: このノードには、XMLディスクリプタ・ファイルおよび構成ファイルが含まれています。

- WEB-INF/sites: このノードには、Site Studioサイトのデータと構成情報が保存されるXMLファイルが含まれています。詳細は、第1.5項「Studio Siteのサイト・ファイルの理解」を参照してください。

- WEB-INF/wcm-config.xml: Site Studioの構成ファイル。

- WEB-INF/web.xml: WebアプリケーションのXMLディスクリプタ・ファイル。

- WEB-INF/weblogic.xml: Oracle WebLogicのデプロイメント・ディスクリプタ・ファイル。

1.5 Site Studioのサイト・ファイルの理解

JDeveloperでは、Site Studioのサイト・ファイルはSite Studioプロジェクトのsitesディレクトリにあります(メイン・メニューから「表示」→「アプリケーション・ナビゲータ」→「プロジェクト」を選択し、Web Contentを開いてWEB_INFを開き、sitesを開きます)。

Site Studioのサイト・ファイルは、Site Studioサイトのデータと構成情報が保存されるXMLファイルです。これらのXMLファイルはJDeveloper上に保持されますが、コンテンツはすべてコンテンツ・サーバー上にあります。

サイト・ファイルには、次のようなサイトに関連する情報が保存されます。

- サイト階層。

- サイトの各セクションのプロパティ(関連するページ・テンプレート、リージョン・テンプレートおよびコンテンツ・ファイルとカスタム・セクション・プロパティを含みます)。

- 明示的なデータ・ファイル・アソシエーション(たとえば、どのコンテンツ・ファイルが使用されているかや、サイト内でのそれらのファイルの位置など)。

- プレースホルダ名とプレースホルダ定義とのマッピング。

- アセット・ペイン内のアイテム(それらがどのように分類されるかも含めて)。

1.6 サイトURLフォーマットの理解

サイトURLは階層化されており、プロジェクト・ファイル内をナビゲートできます。サイトURLの一般的なフォーマットは次のとおりです。

/[Site Identifier]/[Section 1]/[Section 2]/.../[content].html

- Site Identifier: サイト(wcm-config.xml fileにリストされているURLパターン)を識別するパス。

- Section: プロジェクト・ファイル内のurlDirName属性またはlabel属性によって識別されるセクションのリスト。

- Content: Oracle WebCenter Content Server上のアイテムのコンテンツID(dDocName)またはプライマリ・ページを参照するための索引(index)。

たとえば、「About」セクションのプライマリ・ページのパスは次のようになります。

/mysite/About/index.html

「Products」セクションに表示するコンテンツの1つへのパスは次のようになります。

/mysite/Products/new_product.html

1.7 セキュリティおよびコントリビュータ認証の理解

セキュリティ・チェックは、Site Studio for External Applicationsレイヤーで実行されます。Webブラウザのユーザー(通常は匿名)はuserIdとして認識され、そのuserIdがコンテンツ・サーバーのWebインタフェース全体を通じて同じ権限を持っているかどうかを評価するために、各データファイルがSite Studio for External Applicationsレイヤーによってチェックされます。コンテンツ・サーバーからデータファイルをフェッチしてSite Studio for External Applicationsのキャッシュに保存するには、adminUserのuserIdが使用されます。

セキュリティの設定

セキュリティがどのように処理されるかは、wcm-config.xmlファイル内のsecurity要素によって定義されます。有効になっている属性がfalseに設定されると、消費モードではセキュリティ・チェックが実行されなくなり、プレースホルダを通じて表示されるすべてのコンテンツが読取り可能になります。この場合も、プロキシ・サーブレットを介したリクエストは検証されます。

コンテンツ・サーバーの構成によっては、securityType属性を使用してセキュリティのレベルを指定することもできます(各レベルは先行するレベルに追加されていきます)。

- groups: コンテンツ・サーバーのセキュリティ・グループに基づいてセキュリティをチェックします。

- accounts: グループをチェックした後、セキュリティ・アカウントをチェックします。

- acl: アカウントをチェックした後、アクセス制御リスト(ACL)に基づく検証を実行します。

コントリビューションモードと設計モードでの認証

コントリビューション・モードとデザイン・モードでは、サイトを実行しているアプリケーション・サーバーに対する認証が必要です。これは、これらの設定がweb.xmlファイルを確認していることを検証するために、自動的にweb.xmlファイルに保存されます。コントリビューション・モードと設計モードの詳細は、オンライン・ヘルプのコントリビュータおよび設計者のセキュリティ・ロールの割当てに関するトピックを参照してください。

例:

<security-constraint>
<web-resource-collection>
<web-resource-name>ContributionMode</web-resource-name>
<url-pattern>/wcm-contrib/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>WCMContributor</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>FORM</auth-method>
<realm-name>OpenWCM</realm-name>
<form-login-config>
<form-login-page>/wcm/support/login/wcm-login.jsp</form-login-page>
<form-error-page>/wcm/support/login/wcm-login.jsp</form-error-page>
</form-login-config>
</login-config>

<security-role>
<role-name>WCMContributor</role-name>
</security-role>

プレースホルダ・コンテンツを含むページで[Ctrl]と[Shift]を押しながら[F5](コントリビューション・モードに切り替えるためのデフォルトのキーボード・ショートカット)を押すと、ページが/wcm-contribを最初のセグメントとするURLにリフレッシュされます。次に、そのユーザーがアプリケーション・サーバーを通じて適切なアプリケーション・ロールを割り当てられていることをアプリケーション・サーバーが検証します。web.xmlに記述されているロール名は、WCMContributorです。ユーザーがこのロールを持っていない場合はログイン画面が表示され、資格証明が検証されてロール条件が満たされるまで、アプリケーション・サーバーへのアクセスが拒否されます。

カスタマイズしたJAASログイン・ページを指すようにweb.xmlを変更したり、/wcm/support/login/wcm-login.jspファイルのローカル・コピーをWebアプリケーションに追加することにより、デフォルトのログイン・ページをカスタマイズできます。その後は、そのページが共有のデフォルト・バージョンのかわりに使用されるようになります。

コントリビューション・モードまたは設計モードでは、ユーザーIDを使用してセキュリティが検証され、すべてのプレースホルダ・コンテンツがコンテンツ・サーバーからライブで取得されます。また、レンディションが「最新リリース」から「最新」に切り替わるため、コントリビュータ・ユーザーがワークフロー内のコンテンツやまだリリースされていないコンテンツを表示できるようになります。

1.8 コンテンツ・キャッシュの理解

コンテンツは、アプリケーション・サーバー上の一時的な場所にキャッシュされます。これは、wcm-config.xmlファイル内のstaging要素のstagingDir属性を使用して、特定の場所にカスタマイズすることができます。コンテンツ・キャッシュには、すべてのファイルのローカル・コピー、関連するメタデータ、および関連する変換またはレンディションが保存されます。

コンテンツに対するリクエストはすべて、まずローカル・キャッシュをチェックします。ローカル・キャッシュ内で見つからない場合はコンテンツ・サーバーへの接続が実行され、コンテンツがキャッシュに保存されます。セキュリティ情報はキャッシュされないという点に注意してください。セキュリティ・コールはすべてコンテンツ・サーバーへ送られます。また、キャッシュされるのは最新リリース・コンテンツのみであり、コントリビュータ・モードまたは設計モードで取得されたコンテンツ(最新レンディション)はキャッシュされません。

pollerInterval属性を使用するcontentServer要素によって制御されるバックグラウンド・スレッドは、キャッシュの内容を最新の状態に保つために、コンテンツ・サーバーを定期的にpingします。コンテンツ・サーバー管理者は、次のURLにあるコンテンツ・サーバーのキャッシュ管理ページ(例)を使用して、すべてのキャッシュをリフレッシュするように要求することができます。

http://localhost:16200/cs/idcplg?IdcService=SSXA_GET_ADMIN_PAGE

1.9 Site Studioタグ・ライブラリを使用したサービス・キャッシュの理解

Site Studioのキャッシュ機能により、サービス・コールをキャッシングできます。サービス・コールはすべて、.コンテンツとメタデータが現在キャッシュされているのと同じ場所にキャッシュできます。キャッシュ機能はDataBinderプロパティを使用して定義されます。

1. キャッシングを有効にするための特殊パラメータを指定します。

2. 次のいずれかの方法で、キャッシュ・キーを決定します。

- カスタム・キャッシュ・キーを指定します。

- キーを生成するために使用するローカル・データ・フィールドを指定します。

- すべてのローカル・データのハッシュを使用してキャッシュ・キーが自動的に算出されるようにします。

キャッシュのプロパティ

キャッシングはすべて、DataBinderで設定されたプロパティを使用して制御されます。JSP/JSPXの場合、これらのプロパティはwcm:idcParameterタグを使用してwcm:idcServiceコールまたはwcm:dynamicListコールに追加されます。

パラメータ

- __ssxaCacheEnabled: キャッシングを有効にするには、trueに設定します。

- __ssxaCacheKey: このリクエストで使用するキャッシュ・キーを指定します。オプションです。

- __ssxaCacheFields: キャッシュ・キーを生成するために使用するフィールドのカンマ区切りの値(CSV)のリストを指定します(指定しなかった場合はすべてのローカル・データが使用されます)。オプションです。

- __ssxaCacheTTL: キャッシュ・データの存続時間の値をミリ秒単位で指定します。指定しなかった場合は、デフォルト値の5分が使用されます。この値が0(ゼロ)以下の場合、キャッシュ項目は無期限に存続します(タイムアウトはありません)。オプションです。

値が60秒ごとにリフレッシュされる動的リストのキャッシングの例

<wcm:dynamicList var="searchResponse" element="nativedocs">
<wcm:idcParameter name="__ssxaCacheEnabled" value="true" />
<wcm:idcParameter name="__ssxaCacheTTL" value="60000" />
</wcm:dynamicList>

GET_SEARCH_RESULTSサービス・コールのキャッシングの例

<wcm:idcService var="dataBinder" service="GET_SEARCH_RESULTS">
<wcm:idcParameter name="QueryText" value="" />
<wcm:idcParameter name="__ssxaCacheEnabled" value="true" />
</wcm:dynamicList>

キャッシュ詳細

サービス・コールは、コンテンツ、メタデータおよびプロジェクト・ファイルとともに、キャッシュ・ディレクトリにステージングされます。次のディレクトリ構造を持つディレクトリ/idc-serviceが作成されます。

/idc-service/service_name/user_name/cacheID.hda

次の例は、GET_SEARCH_RESULTSサービス・コールのキャッシュ・ディレクトリを示しています。

+- idc-service/
+- ssxa_get_dynamic_list_results/
+- anonymous/
+- 3164744485.hda
+- get_search_results/
+- anonymous/
+- 2452981209.hda

1.10 Site StudioのJSP/JSPXテンプレートの理解

Site StudioのJSP/JSPXテンプレートは(ページ・テンプレート、リージョン・テンプレートおよびサブテンプレートを含む)、ローカルでJDeveloper内に保存することも、リモートでOracle WebCenter Content Server上に保存することもできます。

- ローカルで保存されるJSPXテンプレートは、通常はJDeveloperのプロジェクト内のサブディレクトリに置かれます。たとえば、プロジェクトに関連付けられたページ・テンプレートは、通常はすべて/wcm/templates/page/サブディレクトリに保存されます。ローカルで保存するテンプレートは、JDeveloperの「新規ギャラリ」ダイアログから作成します。詳細は、第1.10.1項「ローカルJSPXテンプレートの作成」を参照してください。

- JSPXテンプレートは、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3のインスタンスにも保存できます。この方法で保存したテンプレートは、アプリケーションを再デプロイしなくてもサイト上で変更および更新ができます。Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3に保存したJSPXテンプレートは、JDeveloper環境で編集することができ、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3へコミットする前に何回でもプレビューできます。Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3上にリモートで保存するテンプレートは、Site Studioの「サイト・アセット」ウィンドウから作成します。詳細は、第1.10.2項「リモートJSPXテンプレートの作成」を参照してください。

ローカルで保存されたJSPXテンプレートと、Oracle WebCenter Content Server 11gR1またはOracle Content Server 10gR3に保存されたJSPXテンプレートの両方を、プロジェクトに含めることができます。しかし、各プロジェクトを1つのテンプレート・タイプを使用して作成することをお薦めします。

テンプレートの構文と構造

どのテンプレート・タイプも、任意の有効なJSP構文を含むことができます。ただし、テンプレートは次のような構造を持っているものと想定されています。

- ページ・テンプレート: 割当て可能なコンテンツのための領域をページ内に作成するwcm:placeholderタグを含んでいます。

- リージョン・テンプレート: データ・ファイルの内容のモデリング用です。通常は、割り当てられたコンテンツを取得するためのwcm:dataFileタグまたはwcm:dynamicConversionタグを含んでいます。wcm:placeholderタグは含んでいません。

- サブテンプレート: ページ・テンプレートに似ていますが、通常はプレースホルダに割り当てられた後のページの一部に対応します。他のwcm:placeholderタグを含む場合があります。

テンプレート登録

テンプレートは、一意の識別子を付けてwcm-config.xmlファイルに登録されます。この識別子は、Site Studioアプリケーション全体でテンプレートを識別するために使用されます。識別子は、プロジェクト・ファイル内でのページ・テンプレートの識別(プライマリまたはセカンダリ)、プレースホルダ定義の識別、およびリージョン・テンプレートまたはサブテンプレートの識別に使用されます。

次のテンプレートでは、homepageという名前がパス/wcm/templates/page/homepage.jspxにマップされています。ホームページ識別子に遭遇すると、そのパスを含めるためにRequestDispatcherが起動されます。

<mappings>
<pageTemplates>
<mapping path="/wcm/templates/page/homepage.jspx" id="homepage"/>
</pageTemplates>
</mappings>

テンプレートがJSPファイルまたはJSPXファイルを指している必要はありません。このマッピングは、任意の有効なWebアプリケーション・リソースを指すことができます。たとえば、あるセクションが処理のために別のサーブレットを指すこともできます。

<mappings>
<pageTemplates>
<mapping path="/servlets/reserveMeetingRoom.do" id="reserveMeeting"/>
</pageTemplates>
</mappings>

1.10.1 ローカルJSPXテンプレートの作成

JDeveloper上にローカルで保存されるJSPXテンプレートを作成するには(通常はJDeveloperのプロジェクト内のサブディレクトリに)、次の手順を実行します。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. アプリケーション・ナビゲータで「プロジェクト」パネルを開きます。

3. Site Studioプロジェクトを選択します。

4. Web Contentを開いてwcmを開き、templatesを開きます。

5. ページを右クリックして「新規」を選択します。
「新規ギャラリ」ダイアログが開きます。

6. 「カテゴリ」リストから「Web層」を開き、「JSP」を選択します。

7. アイテム・リストで、「JSP」を選択します。

8. 「OK」をクリックします。
「JSPの作成」ダイアログが開きます。

9. 「ファイル名」に、このファイルがこのサイトのテンプレートであることを示すわかりやすいファイル名を入力します。

10. 「ディレクトリ」では、デフォルトを受け入れるか、別のディレクトリを指定します。デフォルトでは、JDeveloperのSite Studioテンプレート・ディレクトリが使用されます。JDeveloperディレクトリ構造の外にファイルを保存する場合は、その場所を指定します。

11. 「XMLドキュメントの作成(*.jspx)」を選択します。これにより、XML構文に従って書かれたJSPページが作成されます。ファイル拡張子はJSPXになります。

12. 「サイト・ファイルの登録」を選択して、テンプレートをサイトに登録します。ほとんどの場合、テンプレートは自サイトに登録されます。

13. 「アセット・タイプ」ドロップダウン・リストからテンプレートのタイプを選択します。

14. このファイルをこのサイトのテンプレートとして識別するサイト・ファイルIDを入力します。

15. 新しいテンプレートの説明を入力します。

16. 「OK」をクリックします。

17. メイン・メニューから、「ファイル」→「すべて保存」を選択します。

ローカルでJDeveloper上に保存されるJSPXテンプレートの作成と編集の詳細は、オンライン・ヘルプのローカル・テンプレートの作成と編集に関するトピックを参照してください。

1.10.2 リモートJSPXテンプレートの作成

Oracle WebCenter Content Server上に保存されるリモートJSPXテンプレートを作成するには、次の手順を実行します。

1. メイン・メニューから「表示」、「Site Studio」→「サイト・アセット」を選択します。

2. 「プロジェクト」ドロップダウン・リスト(左上)から、プロジェクトを選択します。
プロジェクトがリストされない場合は、接続にログインしていないことを示します。「アプリケーション・リソース」パネルで「接続」→「Site Studio」を選択し、接続を右クリックして「ログイン」を選択します。

3. 「アセット・タイプ」ドロップダウン・リスト(右上)から、テンプレートのタイプを選択します。たとえば、「ページ・テンプレート」、「リージョン・テンプレート」または「サブテンプレート」を選択します。

4. 新規アセット・タイプを作成するボタンをクリックし、新規JSPXテンプレートを選択します。

5. 「新規アセットの作成」ダイアログで、タイトルとコンテンツIDを入力します。たとえば、ss-homepage-ptのように入力します。

6. 「OK」をクリックします。

7. サイト・アセットウィンドウで、「リフレッシュ」ボタンをクリックして新しく作成したコンテンツ・サーバー・テンプレートを表示します。

Oracle WebCenter Content Server上に保存されるリモートJSPXテンプレートの作成と編集の詳細は、オンライン・ヘルプのリモート・テンプレートの作成と編集に関するトピックを参照してください。

1.11 Oracle Site Studio Manager機能の組込み

Oracle Site Studio Managerは、セクションの追加と削除、セクションに割り当てるページ・テンプレートの変更、サイト・プロパティの変更など、サイト・マネージャがサイト階層に変更を加えることができる環境を提供します。

Site Studio for External Applicationsを使用する外部サイト上で、Oracle Site Studio Manager機能を有効にすることができます。ただし、環境の違いにより、外部アプリケーション内でのManagerの機能は、Oracle WebCenter Content Serverインスタンス内で実行されているOracle Site Studio Managerとはいくつかの点で異なります。その相違点には、Manager機能の提供と起動の方法、外部で管理されるJSP/JSPXページ・テンプレートの取り扱い、プレビューURLの生成方法などが含まれます。

Oracle Site Studio Managerのサイトへの組込み

Site Studio for External ApplicationsでOracle Site Studio Manager機能をサポートするために、site-managerページが提供されています。このページで、Oracle Site Studio Manager機能がホストされます。Oracle Site Studio Manager機能をサイトに組み込むには、そのサイトからsite-manager.jspファイルへのリンクを提供する必要があります。

注意:
このセクションで使用しているコード・サンプルでは、当該のサイト上にManagerという名前のセクションがあり、そのセクションがコントリビューション・モードでのみ表示されるようにするコントリビュータ専用セクションのマークがそのセクションに付けられているものと想定されています。

そのためには、Managerセクションに割り当てられるページ・テンプレートが次のコードを含んでいる必要があります。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<c:redirect url="/wcm-contrib/wcm/support/manager/
site-manager.jsp?siteID=${wcmContext.siteID}" /></jsp:root>

redirectタグは、ブラウザをsite-manager.jspファイルにリダイレクトします。ユーザーがサイトのManagerセクションへナビゲートすると、自動的にこのファイルにリダイレクトされます。

Oracle Site Studio Managerの使用方法と、Oracle Site Studio Manager機能に関するその他の詳細は、Oracle Site Studio管理者およびマネージャ・ガイドを参照してください。

1.12 HCSPベースのカスタム要素フォームの有効化

Site Studio for External ApplicationをHCSPベースのカスタム要素とともに使用する場合は、MIMEマッピングを変更する必要があります。

Site Studio for External Applicationsでは、カスタム要素フォームは要素で使用するカスタム・フォーム(たとえば、特定のファイル・タイプを選択するためのフォーム)を定義するHTMLファイルです。Hyper Content Server Page(HCSP)フォームは、HTMLおよびIdoc Scriptコード(固有のスクリプト言語)を含んでおり、コンテンツ・サーバーからサービスを要求するためによく使用されます。HCSPベースのカスタム要素フォームのファイル拡張子は、.hcspです。HCSPベースのカスタム要素フォームは、デフォルトではSite Studio for External ApplicationsのJDeveloper環境にはロードされず、ユーザーはそのファイルをダウンロードして保存するように求められます。HCSPベースのカスタム要素フォームを使用するには、カスタム要素フォームがダウンロードされるかわりに実行されるようにするために、Site Studioプロジェクトのweb.xmlファイル(UCMのweb.xmlファイルではなく)にMIMEマッピングを追加する必要があります。

Site Studioプロジェクトのweb.xmlファイルにMIMEマッピングを追加するには、次の手順を実行します。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクトを開きます。

3. 「Webコンテンツ」を開いてから「WEB-INF」を開きます。

4. 「web.xml」を右クリックして「開く」を選択します。

5. 「ソース」タブを選択します。

6. 次のMIMEマッピングを、web.xmlファイルの最後、web-appタグの閉じタグの前に追加します。

<mime-mapping>
<extension>hcsp</extension>
<mime-type>text/html</mime-type>
</mime-mapping>

7. メイン・メニューで「ファイル」→「すべて保存」を選択します。

2 Site Studio Webサイトの理解

Site Studioは、Webサイトの効率的な設計、構築およびメンテナンスを可能にする強力なツールのセットを提供します。これらのツールを最大限に活用するには、Site Studio Webサイトの基本概念を理解しておくと役に立ちます。

この項の内容は次のとおりです。

- 第2.1項「サイトのプレゼンテーションとコンテンツの分離」

- 第2.2項「サイト・アセットの記憶域」

- 第2.3項「サイトに関連するロール」

- 第2.4項「プレゼンテーション・モデル」

- 第2.5項「コントリビューション・モデル」

- 第2.6項「サイトのオブジェクト階層」

- 第2.7項「サイト・アセットの再利用」

- 第2.8項「要素と要素定義」

- 第2.9項「リージョン・テンプレートとリージョン定義」

- 第2.10項「プレースホルダとプレースホルダ定義」

- 第2.11項「サブテンプレート」

- 第2.12項「ページ・テンプレート」

- 第2.13項「コントリビュータ・データファイルとネイティブ・ドキュメント」

- 第2.14項「プライマリ・ページとセカンダリ・ページ」

2.1 サイトのプレゼンテーションとコンテンツの分離

Site Studioを貴重なツールにしている要因の1つは、WebサイトのコンテンツをWebサイトのプレゼンテーションから完全に分離できることです。この分離により、誤ってサイトのレイアウト、デザインまたはルック・アンド・フィールに影響を与える心配なしで、1つのWebサイト上の情報を複数の人々が管理および担当することが可能になります。サイトのコンテンツの管理を割り当てられた人々が、必要に応じて変更を行うことができます。そのタスクを完了するために誰か他の人に変更内容を送信する必要はありません。これにより、多くのサイト管理シナリオに存在する、サイトに対するすべての変更を非常に限られた数のサイト管理者が処理する必要があるという重要なボトルネックが取り除かれます。

サイトのプレゼンテーションとコンテンツの分離を念頭に置いて、Webサイトに関連付けられるファイルを次の3つの主なカテゴリに分類できます。

- 第2.1項「サイト・プレゼンテーション・ファイル」

- 第2.1項「サイト・コンテンツ・ファイル」

- 第2.1項「サイト制御および構成ファイル」

サイト・プレゼンテーション・ファイル

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ファイル。

- 変換定義: Webサイト上のネイティブ・ドキュメントの変換ルールを指定するファイル。

- カスタム構成スクリプト: コントリビュータがカスタマイズされた編集操作を実行できるようにするJavaScriptファイル。デフォルトのContributorエディタ構成よりも優先されます。

- カスタム要素フォーム: 特定のファイル・タイプの選択フォームなど、要素内で使用するカスタム・フォームを定義するHTMLファイル。Site Studioには、いくつかの事前定義済のカスタム要素フォームが付随しています。(これらのフォームは、Site Studioコンポーネントのインストール時にコンテンツ・サーバーにもチェックインされます。)

2.2 サイト・アセットの記憶域

Site Studio Webサイトに関連するファイルはすべて、Oracle WebCenter Content Serverを使用して保存および管理されます。ファイルがどこでどのように使用されるかを指定するには、Site Studio専用のいくつかのカスタム・メタデータ・フィールドが使用されます。

図2-1 サイト・アセットの「コンテンツ情報」ページにあるSite Studio用メタデータ・フィールド

「図2-1 サイト・アセットの「コンテンツ情報」ページにあるSite Studio用メタデータ・フィールド」の説明

Site Studioでは、すべてのサイト関連ファイルについて次のメタデータ・フィールドが使用されます。

- Webサイト・オブジェクト・タイプ: Webサイト用のファイルのタイプを指定します(「データファイル」、「スタイルシート」、「リージョン・テンプレート」、「プレースホルダ定義」など)。

- Webサイト: ファイルが関連付けられているWebサイトをリストします。つまり、そのファイルはリストされている各サイトで使用できます(必ず使用する必要があるわけではありません)。1つのファイルを複数のWebサイトに関連付けることができます。これは、そのファイルをサイト間で再利用できるということを意味します。これにより、複数サイトの管理を効率化できます。

- リストから除外: コントリビュータがWebサイト上の動的リストに特定のコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)を表示しないように指定したWebサイトをリストします。

- Webサイト・セクション: コンテンツ・ファイルをデフォルトでWebサイト上のどこに表示するかを指定します(元のハイパーリンク内でターゲット・セクションが明示的に指定されていないかぎり)。

- リージョン定義: リージョン・テンプレートまたはコンテンツ・ファイル(コントリビュータ・データファイルまたはネイティブ・ドキュメント)が関連付けられているリージョン定義を指定します。これにより、ファイルがサイト上でどのように表示されるかと、どのコントリビュータがそれを許可されるかが決まります。リージョン・テンプレートとコンテンツ・ファイルに関連付けることのできるリージョン定義はそれぞれ1つのみですが、1つのリージョン定義に複数のリージョン・テンプレートおよびコンテンツ・ファイルを関連付けることは可能です。

一部のフィールドはファイルが作成されてコンテンツ・サーバーにチェックインされるときに自動的に設定されるという点に注意してください。また、すべてのサイト・アセットですべてのメタデータ・フィールドが使用されるわけではありません。アセットによっては該当しないフィールドもあるためです。たとえば、xRegionDefinitionメタデータ・フィールドはページ・テンプレートには使用されません。ページ・テンプレートはリージョン定義とは関連付けられないためです。

これらのフィールドの値は、ファイルのコンテンツ情報ページで変更できますが、フィールド値の変更は、そのファイルがサイト上でどのように使用されるかに影響するため、変更には注意が必要です。

2.3 サイトに関連するロール

組織内でWebサイトの作成や管理のために様々なロールを決定するときには、Webサイトの作成における特定のタスクに各ロールの焦点を合わせることができます。

設計者は、Webサイトの外観に焦点を合せます。つまり、ページの構造、ページのレイアウト、デザインおよび企業の特色などに集中します。

コントリビュータは、ページに関するコーディングを行う必要なしで、ページ上にコンテンツを配置できます。コントリビュータはその後、ページの外観に影響を与えずに、そしてWebサイトの複数の領域に対して複数の変更を加える必要なしで、コンテンツの更新や編集を行うことができます。設計者は、コンテンツの制御をほとんど行いません。コントリビュータは、サイト上にコンテンツがどのように表示されるかをほとんど制御しません。

2.4 プレゼンテーション・モデル

Site Studioでは、図2-2に示すように、Webサイトのプレゼンテーション・レイヤーとコンテンツ・レイヤーが完全に分離されています。

図2-2 Site Studio Webサイトのプレゼンテーション・モデル

「図2-2 Site Studio Webサイトのプレゼンテーション・モデル」の説明

ページ・テンプレートは、コンテンツが表示されるサイトのフレームワークを定義するために使用されます。ページ・テンプレートには、標準のHTMLレイアウトおよびフォーマット・コードと、フラグメントおよびプレースホルダをどこに配置するかを指定するSite Studioタグが含まれています。プレースホルダは、ページのどこにコントリビューション・リージョン(つまり編集可能な領域)を配置するかを指定します。プレースホルダは、これらのリージョンに何が表示されるかに関しては、コンテンツの点でも視覚的なプレゼンテーションの点でも何も指定しないとう点に注意してください。それらはリージョン・テンプレートによって処理されます(関連付けられたリージョン定義を使用して)。

リージョン・テンプレートは、Webページのコントリビューション・リージョン内のデータのレイアウトとルック・アンド・フィールを定義します。要素定義は個別に管理されるサイト・アセットです。つまり、要素定義はWebサイト内またはWebサイト間で再利用できます。(リリース10gR4より前のリリースでは、リージョンのプレゼンテーションは別個に管理されておらず、ページ・テンプレート、すなわち以前のリリースでの名称である「レイアウト・ページ」に含まれていました。)

コントリビューション・リージョンのコンテンツはデータファイルに保存されますが、これらのファイルもやはり別個に管理されるサイト・アセットです。Webページを生成する際に、Site Studioはページ・テンプレート内のプレースホルダをチェックし、プレースホルダに関連付けられたリージョン・テンプレートとデータファイルを取得してその2つをマージし、ページ・テンプレート内のプレースホルダ・タグの位置に挿入するHTMLコードを作成します。これにより、すべてのコンテンツがあるべき場所に配置され、サイトとページの設定に従って提示およびフォーマットされた、最終的なWebページが作成されます。

2.5 コントリビューション・モデル

プレゼンテーション・モデルの場合と同様に、Site Studio Webサイトのコントリビューション側では、図2-3のようにサイトのコンテンツがプレゼンテーションから分離されています。

図2-3 Site Studio Webサイトのコントリビューション・モデル

「図2-3 Site Studio Webサイトのコントリビューション・モデル」の説明

サイトのコントリビュータは、Webページのコンテンツを編集しようと決めると、適切なキーの組合せを押して、そのページをコントリビューション・モードで再ロードします。(デフォルトのキーの組合せは[Ctrl]と[Shift]キーを押しながら[F5]ですが、これは変更されている可能性があります。)

ページがコントリビューション・モードになると、Webページ内のすべてのコントリビューション・リージョン(つまり編集可能な領域)がマークされ、各コントリビューション・リージョンにどのプレースホルダが関連付けられているかを識別するために、その基礎となっているコードがページに追加されます。Site Studioはこの情報に基づいて、そのプレースホルダに使用するプレースホルダ定義およびリージョン定義を確立できます。リージョン定義は、コントリビューション・リージョン内のコンテンツの構造を、そのコンテンツを構成するデータ・セグメント(要素)の観点から識別します。各要素には要素定義があり、その要素をコントリビュータが編集するときに使用できる編集オプションが定義されています。

コントリビュータがコントリビューション・リージョン内のコンテンツを編集するときには、そのリージョンに関連付けられたコントリビュータ・データファイルがコンテンツ・サーバーからチェックアウトされます。データファイルの構造は、要素の数とタイプの点で、そのファイルに関連付けられたリージョン定義の構造と一致しますデータはデータ・ファイルからロードされてContributorエディタに表示されます。データファイル内の各要素は、編集可能な要素としてエディタ内に表示され、その要素タイプの要素定義の中で定義された編集機能を使用できます。

コントリビュータが編集を終えてContributorエディタの保存アイコンをクリックすると、データファイルが更新されてコンテンツ・サーバーに再チェックインされます。その後、サイトの更新スケジュールに従ってWebページが更新されます。

Contributorエディタでは常に、コントリビューション・リージョンに関連付けられたリージョン定義内の(そしてデータファイル内の)すべての要素が表示されるという点に注意してください。これは、たとえそれらの要素がその特定のリージョンで使用されない場合でも変わりません。当該のリージョンで使用されない他の要素が同じWebサイト内の他の場所で使用されている可能性があるため、その情報を編集するとサイト内の他のページに影響する可能性があります。

2.6 サイトのオブジェクト階層

図2-4は、Site Studio Webサイトの作成と管理に使用されるサイト・オブジェクトの階層を示しています。

図2-4 Webサイトのオブジェクト階層

「図2-4 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-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つずつの編集領域が提供されます。各領域で使用できる編集機能は、要素定義によって設定されています。

2.7 サイト・アセットの再利用

Site Studioの最も有用で強力な機能の1つは、サイト・アセットをWebサイト内および複数のサイト間で再利用できる機能です(各サイトがすべて同じコンテンツ・サーバーで管理されている場合)。あるアセットに変更が加えられると、そのアセットが使用されているすべての場所でその変更が行われます。すべてのWebページが確実に更新されるようにするために、当該データのすべてのインスタンスを追跡する必要はありません。これは、サイトのプレゼンテーションに関連付けられたファイルにもコンテンツに関連付けられたファイルにも適用されます(第2.1項「サイトのプレゼンテーションとコンテンツの分離」)を参照してください。ページ・テンプレート、リージョン・テンプレート、要素および類似のアセットは、何回でも再利用できるようにするのが最も効率的です。同様に、同じコンテンツ・ファイルの全体または一部(異なるセグメント)を、サイト内の異なる場所にコンテキストに合せて表示できます。

図2-6と図2-7は、再利用されているサイト・コンテンツの例を示しています。図2-6には、タイトル、イメージおよびサブタイトルで構成されるアイテム・リストが示されています。この情報は、別個のコントリビュータ・データファイルから取得されます。これらのリスト・アイテムはそれぞれ、図2-7のような詳細ページを開くためにハイパーリンクされている場合があります。実際、これは多くのサイトで見かける種類のデザインです。つまり、プライマリ・ページに情報が表示され、完全な情報はリンクをクリックすると開く後続のページに表示されます。

図2-6 導入コンテンツが表示されたWebページ

「図2-6 導入コンテンツが表示されたWebページ」の説明

図2-7 完全なコンテンツが表示されたWebページ

「図2-7 完全なコンテンツが表示されたWebページ」の説明

図2-7のWebページには、同じ情報が数多く表示されています。これは、図2-6のリージョン・テンプレートと図2-7のページの両方で同じデータファイルが使用されているためです。使用されている要素も同じです。たとえば、イメージの提示にはイメージのみの要素が使用され、タイトルの提示にはテキストのみの要素が使用されます。残りの情報の表示には、おそらく要素タイプとしてWYSIWYGが使用されます。通常、Webサイトの作成に必要な要素は多くありません。1つのWYSIWYG要素を、Webサイト上でコントリビュータ向けにそのスタイルの編集を設定する場所ならどこでも使用できるためです。

サイト・アセットはWebサイト間での再利用を意図しているため、設計者がWebサイト内に何か作成する前にWebサイトを完全に計画することが特に重要です。詳細は、第3章「Webサイトの計画」を参照してください。

2.8 要素と要素定義

要素は、Site Studio Webサイトにおける再利用可能な情報の最小チャンクです(たとえば、プレス・リリースのタイトル、製品イメージ、本文など)。要素データはWebサイト内(またはWebサイト間)で再利用できるため、サイトの設計者はサイトのコンテンツをどのようにセグメントに分割するかについて慎重に考慮する必要があります。そのためには事前にある程度の作業が必要になることがありますが、それによってサイト・コンテンツの再利用可能性が最大限に高まり、サイト・コンテンツの管理が長期的に効率化されます。

定義済の各要素は、WYSIWYG、テキストのみ、イメージのみ、静的リスト、動的リストまたはカスタムの各特定のタイプです。これらのタイプは、要素コンテンツの構成内容の特性を示し、要素定義をとおして、コントリビュータが使用できる編集オプションを示します。たとえば、プレス・リリースのタイトルはテキストのみの要素(通常はコントリビュータが使用できる編集オプションが限られています)として設定できますが、実際のプレス・リリースのテキストはWYSIWYG要素(通常は、コントリビュータがイメージや表を追加するなど、より自由に編集できます)として設定することになるでしょう。

要素は要素定義によって制御されます。要素は基本的には関連付けられている要素定義がインスタンス化されたものであり、要素定義はWebページ上のその要素に対してコントリビュータがどのような編集操作を行えるか(特に、Contributorエディタでどの編集機能を使用できるか)を指定します。要素定義は個別に管理されるサイト・アセットです。つまり、要素定義はWebサイト内またはWebサイト間で再利用できます(それらのサイトがすべて同じコンテンツ・サーバー上で管理されていれば)。図2-8に示すように、要素が使用されるコンテキストに応じてコントリビュータに異なる編集環境を提供するために、同じタイプの要素(TitleとSubtitle)に異なる要素定義が関連付けられる場合があります。同様に、複数の要素(Intro_TextとBody_Text)が同じ要素定義を共有して、各要素について同じ編集環境をコントリビュータに提供する場合もあります。

図2-8 要素と要素定義

「図2-8 要素と要素定義」の説明

個々の要素は別個に管理されるサイト・アセットではありません。リージョン定義の中では要素がグループにまとめられ、それによってサイトのコンテンツのタイプが指定されます。図2-8に示すように、Title、Subtitle、Intro_Text、Body_TextおよびImage要素から構成されるPress_Releaseという名前のリージョン定義が考えられます。したがって、リージョン定義はコンテンツ・クラスであると考えることができます。

要素データは、リージョン定義に関連付けられたコントリビュータ・データファイルに保存されます。各コントリビュータ・データファイルには、関連付けられたリージョン定義に基づく各要素のインスタンスが含まれています。図2-8の例では、Title、Subtitle、Intro_Text、Body_TextおよびImageという5つの要素がコントリビュータ・データファイルに含まれています。コントリビュータは、各要素に関連付けられた要素定義で設定されている編集機能を使用して、コントリビュータ・データファイル内の要素データを編集できます。

2.9 リージョン・テンプレートとリージョン定義

リージョン定義は、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-9 リージョン定義からの限られた要素セットが表示されたリージョン・テンプレート」の説明

図2-9のコンテンツは、同じデータに適用されてデータファイルからの要素をより多く表示する別のリージョン・テンプレートを使用する新しいページを開くために、ハイパーリンクされている場合があります。図2-10は、そのようなリージョン・テンプレート(およびサンプル・コンテンツ)の例を示していますが、この例ではタイトルが一番上に、サブタイトルと導入テキストと本文がその下に配置されます。このリージョン・テンプレートにはイメージも含まれています(サイズと配置は異なりますが)。コンテンツはすべて、図2-9で使用されているものと同じデータファイルから取得されたものです。

図2-10 リージョン定義からの完全な要素セットが表示されたリージョン・テンプレート

「図2-10 リージョン定義からの完全な要素セットが表示されたリージョン・テンプレート」の説明

図2-9と図2-10の場合、どちらのページでもコントリビュータがデータを編集できるようにコントリビューション・リージョンを設定できます。ただし、同じデータファイルを編集することになるため、加えた変更はそのデータファイルが使用されているすべての場所に反映されます。限られた要素セットが表示されているリージョン・テンプレート(図2-9)からデータファイルを編集する場合、たとえその特定のコンテキストですべての要素が使用されてはいなくても、Contributorエディタにはデータファイルのすべての要素が表示されるという点に注意してください。

2.10 プレースホルダとプレースホルダ定義

プレースホルダは、Webページ上のコントリビューション・リージョン(つまり編集可能な領域)の場所を識別するための、ページ・テンプレート上の(第2.12項「ページ・テンプレート」を参照してください)挿入ポイント(タグ)です。プレースホルダは、次のような単純なタグによって表されます。

<!--$wcmPlaceholder("Name")-->

プレースホルダによって識別されたコントリビューション・リージョンのコンテンツとそのサイト上での外観は、リージョン・テンプレートとリージョン定義を使用して定義されます(第2.9項「リージョン・テンプレートとリージョン定義」を参照してください)。ページ・テンプレートには、複数のプレースホルダを含めることができ、各プレースホルダはページ上のコントリビューション・リージョンを表します。プレースホルダにはファイルは関連付けられません。図2-11のWebページには、プレースホルダが1つあります(サンプル・コンテンツが表示されている点線で囲まれた部分)。

図2-11 Webページ上のプレースホルダ(およびサンプル・コンテンツ)

「図2-11 Webページ上のプレースホルダ(およびサンプル・コンテンツ)」の説明

ページ・テンプレートにプレースホルダを挿入するときに行う操作は、コンテンツを挿入できるようにする名前付きの位置をテンプレート内にマークすることのみです。その位置でコンテンツがどのように処理されるかを制御するために、プレースホルダ名をプレースホルダ定義と関連付ける必要があります。プレースホルダ定義は、コントリビューション・リージョンにどのようなコンテンツがどのような外観で表示されるかと、コントリビュータが実行できるアクションを指定します。たとえば、コントリビュータがコントリビューション・リージョンに表示されるコンテンツのメタデータを更新したり、コントリビューション・リージョンのコンテンツを切り替えることができるように、プレースホルダを設定できます。(どのような種類のコンテンツに切り替えられるかは、リージョン定義によって制御されるという点に注意してください。)

プレースホルダとプレースホルダ定義の関連付け(マッピングとも呼ばれます)は、次のいずれかの方法で方法で行えます。

- サイト・レベル(グローバル・マッピングを使用): セクション・レベルまたはプレースホルダ・レベルでオーバーライドが指定されないかぎりサイト全体に適用される、デフォルトのプレースホルダ・マッピングを設定できます。それには、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項「サイト・アセットの記憶域」を参照してください)。

2.11 サブテンプレート

サブテンプレートは、<HTML>、<HEAD>および<BODY>セクションがないこと以外は、ページ・テンプレートと同じです。したがって、基本的にはページ・テンプレートに挿入できるHTMLコードのチャンクです。サブテンプレートには非常に単純なHTMLコードを含めることができますが、独自のスクリプトなどを持つ非常に複雑なものにすることもできます。サブテンプレート内のコードは、ページ・テンプレートに直接挿入された場合とまったく同様に扱われます。

サイトのオブジェクト階層(図2-4)に示されているように、サブテンプレートを配置できるのはプレースホルダの中のみで、サブテンプレート内に独自のプレースホルダを含めることができます。図2-12に示すように、サブテンプレートは通常、ページ・テンプレート上のプレースホルダ(つまりコントリビューション・リージョン)を、再利用可能で独自のプレースホルダを持つより小さな領域に分割する手段として使用されます。プレースホルダには、1つ以上の他のプレースホルダを含むサブテンプレートを1つ含めることができます。サブテンプレート内のプレースホルダはそれぞれ独自のサブテンプレートまたはリージョン・テンプレートを持ちます。

図2-12 プレースホルダ内のサブテンプレート

「図2-12 プレースホルダ内のサブテンプレート」の説明

優れたサイト設計に必ずサブテンプレートが必要というわけではなく、サブテンプレートをまったく使用していないWebサイトも数多く存在します。サブテンプレートを追加すると、設計者が管理する必要があるサイト・アセットのタイプが増えるためです。

サブテンプレートを使用すると、Webサイト内で使用されるページ・テンプレートの数を減らせます。これは、できるかぎり広範囲で再利用できるメイン・ページ・テンプレートを1つ作成し、特定のケースではサブテンプレートを使用してメイン・ページ・テンプレート上のプレースホルダを複数のプレースホルダに変更することによって達成できます。これにより、再利用可能性がさらに高まります。サイトの設計者は、1つのプレースホルダを持つ大きな領域を作成し、レイアウトが異なる複数のプレースホルダを備えたサブテンプレートをプレースホルダに含めることで、その領域を使用および再利用できます。

2.12 ページ・テンプレート

ページ・テンプレートは、Webページのレイアウトと高レベルのルック・アンド・フィールを定義します。これには、コントリビューション・リージョン(ページの編集可能な領域)、ナビゲーション・ツール(フラグメント形式)、サイト全体にわたるイメージ(バナーなど)の配置も含まれます。ページ・テンプレートは、サイトのコンテンツの表示に使用するフレームワークを提供します。

ページ・テンプレートは、レイアウトおよびフォーマット・コードと、フラグメントおよびプレースホルダをどこに配置するかを指定するSite Studioタグで構成されます。したがって、ページ・テンプレートは通常は軽量であり、含まれているのはコントリビューション・リージョンが配置されるページ上の場所を示す高レベルの参照のみです。それらのリージョンに表示されるものに関しては、コンテンツについても視覚的なプレゼンテーションについても何も指定しません(第2.9項「リージョン・テンプレートとリージョン定義」を参照してください)。ページ・テンプレートには通常、企業バナーやページ・レイアウト用イメージなどのサイト全体にわたるグラフィックと、ナビゲーション・ツールや標準的なページ・コンテンツ(フッターなど)などの繰り返し使用される編集不可能なコンテンツが含まれています。

Webサイトに必要なページ・テンプレートの数はサイトの複雑さによって決まりますが、通常はわずかな数で足ります。たとえば、ホーム・ページ用にページ・テンプレートを1つ使用し、他のすべてのページ用に別のページ・テンプレートを1つ使用すれば十分でしょう。様々なWebサイト・ページに表示されるコンテンツの多様性に関しては、ページ・テンプレート上のプレースホルダの中でリージョン・テンプレート(およびリージョン定義)を使用して対処できます。ページ・テンプレートの数が少ないほど、Webサイトのメンテナンスが容易になります。そのためには、事前の作業を増やす必要があります。つまり、素材のレイアウトや、どの情報をWebサイトのどのセクションに表示するかなどについて、Webサイトの設計をより綿密に考え抜く必要があります。これは、どの情報についてコントリビュータによる変更を許可し、どの情報を固定するかについて、サイト設計者が慎重に考慮する必要があることも意味します。

図2-13は、Webサイトのホームページによく使用される汎用ページ・テンプレートを示しています。最上部にバナー・イメージ、左側にナビゲーション・フラグメント、最下部にフッター・フラグメント、中央にいくつかの小さなプレースホルダが配置され、それぞれになんらかのコンテンツが表示されます。プレースホルダは、ページ領域を詳しく記述することはありません。プレースホルダは、コントリビューション・リージョンの場所を指定する単なる挿入ポイントです。これらのリージョンに何がどのように表示されるかは、リージョン・テンプレートとリージョン定義によって処理されます。サイト閲覧者がこのコンテンツをクリックすると、コンテンツが完全に表示されます。この完全なコンテンツは、潜在的にホームページ以外のすべてのサイト・ページで使用される可能性があるページ・テンプレートに表示されます。図2-14は、このような汎用ページ・テンプレートの例を示しています。このテンプレートは基本的にはホームページ用のテンプレート(図2-13)と同じですが、ページのコンテンツを完全に表示するために、コンテンツ領域が単一のプレースホルダになっています。

図2-13 Webサイトのホームページ用の汎用ページ・テンプレート

「図2-13 Webサイトのホームページ用の汎用ページ・テンプレート」の説明

図2-14 Webサイトの他のあらゆるページ用の汎用ページ・テンプレート

「図2-14 Webサイトの他のあらゆるページ用の汎用ページ・テンプレート」の説明

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をすでに使い慣れているため、このアプリケーションがサイト・コンテンツ用の簡単で便利な編集環境になることです。

2.14 プライマリ・ページとセカンダリ・ページ

サイト・セクションのプライマリ・ページは、閲覧者が最初にそのセクションに入ったときに表示されるページです。通常、サイト階層内の各セクションにはプライマリ・ページが割り当てられていますが、これは必須ではありません。たとえば、ユーザーが直接参照できないようにする必要がある検索結果ページは、セカンダリ・ページしか備えていない場合があります。サイト・セクションのプライマリ・ページとして、ページ・テンプレートを割り当てます。

プライマリ・ページ上の情報は、静的にリンクされています。コントリビュータは、プライマリ・ページ上のコントリビュータ・データファイルはContributorエディタを使用して、ネイティブ・ドキュメントは関連付けられたサード・パーティ・アプリケーションを使用して変更できます。

セカンダリ・ページはサイト・セクションにとってオプションであり、通常はWebサイト上でコンテンツを動的に提示するために使用されます。セカンダリ・ページに静的コンテンツを表示することもできますが、セカンダリ・ページの有用性は、動的に配置される置換可能なコンテンツを表示できる機能にあります。そのため、セカンダリ・ページはサイト・セクション内のページの複数のバージョンを作成するために使用され、1つのサイト・セクション内でコンテンツを様々に表示できます。セカンダリ・ページを使用すれば、何千ものページを物理的に作成する必要なしで大規模なサイトを処理できます。

セカンダリ・ページは、基本的にはコントリビュータによってサイトに追加されたコンテンツのバックドロップとして機能します。新規のコントリビュータ・データファイルまたはネイティブ・ドキュメント(両方とも新規のWebページになります)をコントリビュータがサイトに追加できるように設定する場合は、セカンダリ・ページが必須です。これらのファイルは、動的リスト、検索またはリンクのターゲットによって選択されたときにサイトで使用できるようになります。ページ・テンプレートをセカンダリ・ページとして構成できます。

全体がプライマリ・ページで構成されたサイトを作成することもできますが、その場合は、サイトを拡大するために新規のプライマリ・ページからなるセクションを作成する必要があります。セカンダリ・ページを使用すれば、コントリビュータが追加のコンテンツを発行するとサイトが自動的に成長するため、設計者は何もする必要がありません。セカンダリ・ページを使用すると、サイトがはるかにスケーラブルになります。

セカンダリ・ページの一般的な用途の1つは、ハイパーリンクされた項目(たとえば図2-15のプレス・リリースのタイトルなど)の動的リストです。各項目をクリックすると、その項目がセカンダリ・ページに完全に表示されます。より具体的にいうと、リンクのターゲットが同じセクションのセカンダリ・ページ上の置換可能なリージョン内に開きます(デフォルトの場合)。

図2-15 プレス・リリースの動的リスト

「図2-15 プレス・リリースの動的リスト」の説明

3 Webサイトの計画

計画は、Site StudioによるWebサイトの作成が成功するための鍵です。テキスト、グラフィックおよびスクリプトをページ・テンプレートに挿入し始める前に、そのサイトの機能または役割は何なのかをよく考える必要があります。そのサイトは、部門レベルのサイトなのか、会社全体のサイトなのか、社内用なのか、それとも外部向けなのでしょうか。そのサイトを閲覧すると見込まれるユーザーの数はどれほどでしょうか。そのサイトにコントリビュートすると見込まれるユーザーの数はどれほどでしょうか。各コントリビュータに対してそれぞれ異なるセキュリティ・アクセス・レベルを設定することになるのでしょうか。サイトのレプリケートや公開を予定していますか。そのサイトは時間の経過とともに成長していくと予想されていますか。

これらはすべて、作業を開始する前に考慮する必要がある重要な質問です。個々のケースでの特定のニーズは予測できませんが、サイトを開発する前に考慮する必要がある重要なポイントをいくつかあげることはできます。

- 第3.1項「計画が重要である理由」

- 第3.2項「サイト階層の計画」

- 第3.3項「コントリビューション・モデルの計画」

- 第3.5項「サイト・アセットの作成」

3.1 計画が重要である理由

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サイトの数百から数千ものページの作成に費やす時間が短縮されます。

3.2サイト階層の計画

サイト階層は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サイトおよび公開に適していることを確認する必要があります。これを確実にするには、ワークフローの実装が適しています。また、そのコンテンツが表示される各セクションは、置換可能なリージョン・テンプレートを備えたセカンダリ・ページを持っている必要があります。

サイト・マネージャは必要か

設計者自身がサイト階層を管理することも、サイト・マネージャにその職務を任せることもできます。サイト・マネージャは、セクションの作成や変更など様々な操作を実行できます。

これらの変更により、サイトの外観と動作が大きく変化する可能性があります。これらの変更と、それがサイトの構造、ワークフロー、レプリケーション、コントリビュータの役割などに与える影響について、よく検討する必要があります。

3.3 コントリビューション・モデルの計画

サイト階層を計画し、Webサイトのアセットを準備するときには、コントリビューション・モデルについてよく考える必要があります。つまり、ユーザー(コントリビュータとマネージャ)がサイト上にコンテンツをどのように配置するかについて考慮する必要があります。

どの程度の量のコンテンツをユーザーがサイトに提供するか

背景色、配置デバイス(HTMLテーブルやCSSなど)、サイトのナビゲーション、カスタム・スクリプトなどは、設計者がサイトに追加する必要があります。しかし、各Webページのコンテンツの大部分(つまりページの実際の情報)は、コントリビュータが作成および編集できます。

Site Studioの能力を本当に使いこなすには、Webサイトのできるだけ多くの部分をコントリビュータに任せる必要があります。そうすれば、Webサイトによくあるボトルネックや遅延なしで、Webサイトが継続的に更新されるようになります。

どの程度ユーザーが制御できるようにするか

各ページ・テンプレートには、1つの大きなコントリビューション・リージョンを配置することも、複数の小さなコントリビューション・リージョンを配置することもできます。リージョン・テンプレート内には1つまたは複数の要素を配置でき、各要素はユーザー(コントリビュータ)がコンテンツを追加および編集できるフィールドとして表示されます。

テキストやグラフィックスの追加と編集、リストの更新など、特定の目的に使用できる、様々なタイプの要素があります。フォントの選択、フォント・サイズ、イメージ、表、カスタム・プロパティなど、一部の書式属性は、有効と無効を切り替えることができます。これらの選択は、特定のWebページをコントリビュータがどの程度制御できるようにするかによって決まります。また、検証機能または独自の検証スクリプトを使用して、どのようなコンテンツを追加できるかを強制することもできます。

ユーザーごとに異なるセキュリティ・アクセスを割り当てるか

ユーザーにサイトへのアクセス権を付与する前に、ユーザーとその組織内での役割およびそのユーザーのWebパブリッシングに関する知識について、知っておく必要があります。Webサイトのすべてのコントリビューション・リージョンに対してすべてのユーザーが同じアクセス権を持つようにする必要がある場合も、一部のユーザーのアクセスは制限し、残りのユーザーには完全なアクセスを許可する必要がある場合もあります。

たとえば、マーケティング部門のメンバーに対してはWebページ全体への完全なアクセスを提供し、それ以外の部門に対してはそのページの一部についてのみアクセスを提供するというケースが考えられます。それには、コンテンツ・サーバー上で異なるユーザーを設定し、各リージョンに異なるコントリビュータ・データファイルまたはネイティブ・ドキュメントを割り当て、それらのファイルに一意のセキュリティ・メタデータを割り当てる(コンテンツ・サーバー上のメタデータ・フレームワークを使用して)必要があります。

その結果、コントリビューション・モードのWebページでは、特定のコントリビュータが編集権限を持つファイルにのみコントリビューション・グラフィック(図3-1)が表示されるようになります。

図3-1 コントリビューション・グラフィック

Webサイトの各セクションにも、特定のユーザーのみがそのセクションを表示できるように指定するマークを付けられます。これは、Webサイト階層内のセクション設定によって制御されます。セクションへのアクセスを制限すると、そのセクションを表示(そして必要に応じて編集)できるのは、アクセスを許可されたユーザーのみになります。

コントリビュータはネイティブ・ドキュメントを発行するか

コントリビュータは、Site Studioデータファイルに保存されたコンテンツの追加と編集のみでなく、ネイティブ・ドキュメント(Microsoft Word、Excel、PowerPointなどのアプリケーションで作成されたドキュメント)をサイトに追加することもできます。これらのドキュメントは、コンテンツ・サーバー上のDynamic Convertorコンポーネントを使用して、Webで表示できるレンディションに変換できます。

コントリビュータは、新規および既存のネイティブ・ドキュメントを直接Webサイトに追加できます(たとえば、リンク・ウィザードを使用してリージョンに割り当てたり、動的リストに追加することによって)。

コントリビュータがネイティブ・ドキュメントをWebサイトに発行することを許可する(そしてコントリビューション・リージョン、要素およびリスト・フラグメント内でそれを制御する)場合は、ネイティブ・ドキュメントの扱い方と従うべきスタイル・ガイドラインについてコントリビュータを教育する必要があります。

コントリビューション・プロセスをどのように調整するか

Webサイトの設計者、マネージャおよびコントリビュータは、サイトのどこをいつ更新する必要があるかを知っています。設計者が1人のコントリビュータまたはマネージャと共同作業する場合、設計者はサイトに対する必要な更新を通知する必要があります。特に、サイトに対する特定の変更を彼らに知らせる必要があります。ただし、コントリビュータも、コンテンツが追加されたことを設計者に警告する必要がある場合もあります。

設計者が複数のユーザーと共同作業する場合は、コミュニケーションがすぐに複雑になってしまう可能性があります。ある種のユーザー間のコミュニケーション・プロセスを組み込む必要があります。解決法の1つは、ワークフローを使用して公式のレビュー・プロセスを導入することです。これは、サイトに対する変更が実際に適用される前に様々な人がその変更をレビューして承認することを意味します。

3.4 サイト・アセットの計画と命名

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サイトを調べる必要がないことも意味します。

3.5 サイト・アセットの作成

Webサイトの計画が完了したら、そのWebサイトを構成するアセットを作成する必要があります。効率化のために、これらのアセットを特定の順序で作成することをお薦めします。

ほとんどのWebサイトにとって最も効率的な方法は、要素定義から始めてボトムアップでアセットを作成していくという方法です。

- ステップ1: 要素定義の作成

- ステップ2: リージョン定義の作成

- ステップ3: リージョン・テンプレートの作成

- ステップ4: サブテンプレートの作成

- ステップ5: プレースホルダ定義の作成

- ステップ6: ページ・テンプレートの作成

必ずしもアセットをこの順序で作成する必要はありません。しかし、この順序で作成すれば、Webサイトを迅速かつ効率的に組み立てられます。

3.5.1要素定義の作成

最初に定義するのが最も効率的なアセットは要素です。要素は、コントリビュータが使用する編集インタフェースを定義するアセットです。各要素の固有の用途は、要素定義によって制御されます。コントリビュータがアクセスできる編集領域とツールバーを定義して要素定義を作成することで、そのデータ・ファイルに対してコントリビュータが何を実行できるかを定義することになります。

要素定義によって、ツールバー内のどの編集機能をコントリビュータが使用できるかを正確に制御できます。たとえば、コントリビュータがフォントのサイズと色は変更できないけれど、太字と斜体は使用できるようにすることもできます。通常は、各種の要素(WYSIWYG、テキストのみ、イメージのみ、静的リスト、動的リストおよびカスタム)を少なくとも1つは定義し、Contributor内の異なるツールバーに対応するために各タイプの要素をそれぞれ複数定義します。

要素定義は、コントリビュータがページを編集するためにアクセスできるツールバーを制御するために使用されます。ただし、コントリビュータに対してツールバーのオプションを1つか2つではなく複数提供できるように、各要素について複数の異なる定義を作成する場合もあります。コントリビュータの役割と彼らが様々なページにどの程度コントリビュートするかについて、考慮することが重要です。

要素定義の名前はよく考えて付けてください。ページ内での場所やサイトの名前に関連する名前を要素に付けると、要素を直観的に再利用することが難しくなる可能性があるためです。ページ上またはWebサイト内の場所を示す名前を要素に付けたり、要素定義内でWebサイト内の名前を使用することは避けてください。要素定義のネーミング規則のオプションとして、element_WYSIWYG_fulleditやelement_text_undo_onlyのように、ツールバー内の機能にどの程度アクセスできるかを示す名前を付けるという方法もあります。

これらの要素定義の名前がelementという単語で始まっている点に注意してください。これは、コンテンツ・サーバーで要素を検索するときにすべての要素がまとまって表示されるようにするためです。Webサイトの名前を含めるなどの他のネーミング規則でもWebサーバー内のアセットをグループ化できますが、その方法では、複数のWebサイトで同じ定義を使用する場合に定義を直観的に管理しにくくなります。

3.5.2 リージョン定義の作成

リージョン・テンプレートを作成する前に、リージョン定義を作成する必要があります。定義(リージョン定義、プレースホルダ定義、要素定義)は、どのデータが表示され、そのデータに対してコントリビュータがどのような操作を実行できるかを制御します。テンプレート(リージョン・テンプレート、サブテンプレート)は、データがどのように表示されるかを制御します。リージョン定義は特に、Contributorでどの要素(WYSIWYG、イメージのみ、その他)が開くかを制御します。リージョン・テンプレートは、要素の配置と、その特定のデータがWebページ上でどのように表示されるかを調整するために使用されます。

リージョン・テンプレートを作成するときには、そのテンプレートをリージョン定義に関連付けるように求められます。定義が関連付けられていないリージョン・テンプレートに、後になって定義を関連付けることは簡単ではありません。

典型的なリージョン定義には複数の要素が含まれており、それらの要素の様々なコントリビューションが複数の異なるリージョン・テンプレートで使用されます。つまり、リージョン定義ができるかぎり幅広く包括的なものになっています。それにより、複数のリージョン・テンプレートが同じ要素グループ(同じデータファイルである必要はありません)にアクセスしてそれらを異なる配置で表示することが可能になります。

リージョン定義はコントリビューション・モードでの要素の可用性を制限するため、適切なリージョン定義ネーミング規則に従うことが特に重要です。これは、作成した様々なリージョン・テンプレートに最も適した定義を選別する役に立ちます。

3.5.3 リージョン・テンプレートの作成

リージョン・テンプレートは、データファイルをHTMLにフォーマットするアセットです。リージョン・テンプレートは、要素の中に含まれないテキスト、イメージまたはその他の単純な項目や、要素などのコンテンツを配置するために使用されます。リージョン・テンプレートは、Webサイト内の別の場所に適していると判断されたときに再利用することを意図したレイアウトに要素(リージョン定義によって制限されます)を配置するために使用されます。

リージョン・テンプレートに配置できる要素は、そのテンプレートのリージョン定義に要素定義がリストされている要素のみです。ただし、定義にリストされた要素をリージョン・テンプレートがすべて使用する必要はありません。これにより、テンプレートごとにコンテンツに大きな多様性を持たせることができます。

リージョン・テンプレートはたいていの場合、Webサイト用に最も数多く作成するアセットです。そのため、リージョン・テンプレートの作成で使用するネーミング規則が重要になります。テンプレートがページ上またはWebサイト内のどこで使用されるかではなく、テンプレートが何をするかを定義する助けになる名前を付けてください。サイトをメンテナンスするときには、regtem_titlebodyviewやrt_bodynoimageのような名前の方が、たとえばregiontemplate14やRT_SupportForumのような名前より役に立ちます。

リージョン・テンプレートには、要素を通じて渡されるデータファイルの一部ではないHTMLやイメージやその他のアセット(たとえば、リージョン・テンプレート固有のCSS)を含めることができるため、コントリビュータが編集できない情報およびテキストを組み込むためにテンプレートを利用できます。ただし、その情報はコントリビュータが編集するコントリビュータ・データファイルの一部ではないことを理解することが重要です。つまり、リージョン・テンプレートに関連付けられたデータは、そのテンプレートが再利用されるときに、そのテンプレートにどのようなデータが関連付けられるかに関係なく、まったく同じように表示されます。また、その特定のデータを変更できる人は、設計者のみです。コントリビュータはプレースホルダを通じて、リージョン・テンプレート内の要素に関連付けられるデータの作成および編集を行えますが、要素の外に配置されたものはリージョン・テンプレートに属する情報であるため、静的です。

3.5.4 サブテンプレートの作成

サブテンプレートはHTMLの主要部分であり、プレースホルダを含むことができます。これにより、Webサイト内のページを複数の異なる方法で表示できる機能を確保しながらページ・テンプレートの数を減らす手段として非常に役に立ちます。

サブテンプレートはプレースホルダの中にのみ表示できます。サブテンプレートに含められるのは、プレースホルダか、HTMLやイメージなどの静的コンテンツのみです。サブテンプレートはCSSファイルを参照することもできます。

サイトにサブテンプレートは必要か

サブテンプレートを使用する利点を1つは、Webサイト内で使用されるページ・テンプレートの数を減らせることです。サブテンプレートを使用すれば、プライマリ・ページとセカンダリ・ページに同じページ・テンプレートを使用できます。

これが、計画が不可欠である理由の1つです。サブテンプレートによってページ・テンプレートの数を減らせますが、その一方で、そのWebサイトに関してサブテンプレートを管理する必要が生じます。ページ・テンプレートの数が減ると、サイト全体に対する変更が簡単になります。サブテンプレートを使用すると、特定の数のページ(たとえばセカンダリ・ページ)に配置するHTML、イメージおよび他の類似した静的サイト・アセットをページに追加できるため、サブテンプレートはある程度の静的情報を追加する目的にも使用できます(サブテンプレートに含めない場合、これらの静的情報はサブテンプレートとは別個に管理する必要があります)。

サブテンプレートは、単一のプレースホルダの中に複数のプレースホルダを配置する手段としても使用できます。プレースホルダにはサブテンプレートを、サブテンプレートにはプレースホルダを含めることができるため、まだ決まっていないWebサイトの将来の拡張に対応できるようにサブテンプレートを配置しておくことも考えられます。

3.5.5 プレースホルダ定義の作成

プレースホルダ定義は、各プレースホルダを、コンテンツやそのプレースホルダに表示するために関連付けられた他のアセットに結び付ける働きをします。

プレースホルダはページ上でどのような働きをするか

プレースホルダはプレースホルダ定義とはまったく別物であり、Webページ上のコントリビューション・リージョン(つまり編集可能な領域)の場所を識別するための、アプリケーション内での単なるページ上のマークです。プレースホルダは単なる概念上の境界です。プレースホルダがWebページ上で使用する実際の場所の大きさは、その中に配置されるコンテンツのサイズによって決まります。

プレースホルダに関連付けられるデータは、そのプレースホルダがどのページ上にあるかによって決まり、その決定はサイト構造が完成してWebサイトの各セクションへのコンテンツの配置が始まった後で行われます。

プレースホルダがどのように機能し、プレースホルダに何が含められるかを決めるのは、プレースホルダ定義です。つまり、プレースホルダは広範囲の各領域でコンテンツを使用および再利用するために使用できるセクションであると見なす必要があります。たとえば、ナビゲーションとヘッダー・イメージのみを備え、その間にはプレースホルダ以外何もないページ・テンプレートは、珍しくありません。このプレースホルダは、それぞれ固有のコンテンツを表示する任意の数のページと簡単に置換できます。最小限の数のテンプレートを基礎として複数のプレースホルダとサブテンプレートを様々に使い分けてサイトを作成するという設計計画になっている場合は、コンテンツをより小さいプレースホルダに分割できます。

プレースホルダ定義は何を制御するのか

プレースホルダは、コンテンツが表示されるページ上の領域を定義するためのタグにすぎません。プレースホルダ定義には、情報を渡すためにどのリージョン定義(およびそれに関連付けられたリージョン・テンプレート)およびサブテンプレートを使用できるかがリストされます。

また、プレースホルダ定義を通じて、各プレースホルダごとに他の詳細も制御できます。このような項目には、ワークフロー、プレースホルダを通じて表示されたデータをコントリビュータが編集できるかどうか、コントリビュータがメタデータを編集できるかどうか、Webサイト使用状況レポートを表示する機能、およびContent Trackerレポートを表示する機能などが含まれます。

3.5.6 ページ・テンプレートの作成

多数のWebサイトを、2つの単純なページ・テンプレートに要約できます。その2つとは、ホームページと他のすべてのページです。レイアウトとデザインがWebサイト内の他のページと異なるホームページを持つWebサイトは珍しくありません。

サイトによっては、複数のページ・テンプレートが使用されています。また、Webサイト全体で1つのページ・テンプレートを使用することもできます。複数のページ・テンプレートを使用するようにWebサイトを設計する場合は、おそらくページ・テンプレートの数を減らすためにサブテンプレートの使用を考慮する必要があるでしょう。Webサイトのページ・テンプレートの数が少なければ、サイト全体に対する変更がはるかに簡単になります。

プライマリ・ページとセカンダリ・ページに別々のテンプレートが必要か

プライマリ・ページとセカンダリ・ページの両方で同じページ・テンプレートを使用できます。ただし、コンテンツを動的に配置できるのはセカンダリ・ページのみであるため、ページ・テンプレートの外観(およびプレースホルダとプレースホルダ定義)に対する影響を考慮する必要があります。

セカンダリ・ページは、コントリビュータによってサイトに追加されたコンテンツのバックドロップとして機能します。新規のコントリビュータ・データファイルまたはネイティブ・ドキュメント(両方とも新規のWebページになります)をコントリビュータがサイトに追加できるように設定する場合は、セカンダリ・ページが必須です。これらのファイルは、動的リスト、検索またはリンクのターゲットによって選択されたときにサイトで使用できるようになります。

最初はプライマリ・ページのみを持つサイトを構築しておき、その後プライマリ・ページ上にコントリビューション・リージョンを設定するまで、そしてコントリビュータがそのサイトに発行するコンテンツの種類がわかるまで、セカンダリ・ページの作成を保留にしておくという方法をとることになるでしょう。その後、そのコンテンツ用のセカンダリ・ページを追加できます。

Webサイトのプライマリ・ページとセカンダリ・ページに使用するページ・テンプレートが同じであっても異なっていても、そのページ・テンプレートに適切な名前を付けることが重要です。これは、Site Studio内のどのアセットでも同じです。たとえば、あるページ・テンプレートをプライマリ・ページとセカンダリ・ページの両方に使用するとします。そのページ・テンプレートの名前として、そのテンプレートが最初にサイト内に配置された場所に基づいた名前を付けると、サイトが拡張されてそのページ・テンプレートがセカンダリ・ページでも再利用されるようになったときに、混乱が生じる可能性があります。

ページ・テンプレートも含むサイト・アセットの最も効率的なネーミングは、そのページ・テンプレートがどのように使用されるかに基づいた名前を付けることです。Webサイト内でアセットが使用される場所に基づくネーミング規則(たとえばpage_template_primarypage)や作成された順序に基づくネーミング規則(たとえばpagetemplate3)を使用すると、アセットを管理しにくくなる可能性があります。

4 Site Studio Webサイトの構築チュートリアル

この項では、JDeveloper環境でSite Studio Webサイトを作成する手順を説明します。このチュートリアルでは、ナビゲーションを使用して単純なWebサイトを作成しながら説明します。この項の内容は、次のとおりです。

- 第4.1項「Site Studioプロジェクトの作成と接続」

- 第4.2項「サンプルWebサイトの作成」

- 第4.3項「サイドバー・リンクの作成」

- 第4.4項「動的変換ページの作成」

- 第4.5項「スタイル・シートの追加」

4.1 Site Studioプロジェクトの作成と接続

Site Studioプロジェクトとコンテンツ・サーバー接続の作成手順は次のとおりです。

- ステップ1: アプリケーションとプロジェクトの新規作成

- ステップ2: コンテンツ・サーバー接続の作成

- ステップ3: プロジェクトへの接続の追加

4.1.1 アプリケーションとプロジェクトの新規作成

アプリケーションとSite Studioプロジェクトを新規作成する手順は次のとおりです。

1. JDeveloperメイン・メニューから「ファイル」→「新規」を選択します。

2. 「新規ギャラリ」ダイアログ・ボックスの「General」カテゴリを開いて、「アプリケーション」を選択します。

3. アイテム・リストで、「汎用アプリケーション」を選択します。

4. 「OK」をクリックします。

5. アプリケーションの名前付けステップでは:

- 「アプリケーション名」には、SiteStudioDemoと入力します。

- 「アプリケーション・パッケージの接頭辞」には、demo.SiteStudioDemoと入力します。

6. 「次」をクリックします。

7. プロジェクトの名前付けステップでは:

- 「プロジェクト名」には、SiteStudioDemoと入力します。

- 「使用可能なテクノロジ」には、Site Studio Technologyと入力し、シャトル・ボタンをクリックしてそれを選択済のテクノロジ・リストに移動します。
このSite StudioプロジェクトをWebSphereアプリケーション・サーバーにデプロイする場合は、「ADFライブラリWebアプリケーション・サポート」を選択してシャトル・ボタンをクリックし、それも選択済のテクノロジ・リストに移動する必要があります。

8. 「終了」をクリックします。

9. JDeveloperメイン・メニューから「ファイル」→「すべて保存」を選択します。

4.1.2 コンテンツ・サーバー接続の作成

コンテンツ・サーバーへの接続を作成し、それをSite Studioプロジェクトに追加する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」が開いていない場合は、「ビュー」を選択してから「アプリケーション・ナビゲータ」を選択します。

2. 「アプリケーション・リソース」パネルを選択します。

3. 「接続」を右クリックして「接続の作成」→「Site Studio」を選択します。

4. 「コンテンツ・サーバー接続の作成」ダイアログで次の操作を実行します。

- 「アプリケーション・リソース」オプション(まだ選択されていない場合は)を有効にします。

- 「接続名」には、コンテンツ・サーバーのホスト名を入力します(たとえば、developmentserver2またはdevelopmentserver2.mycompany.comなど)。

- デザインタイムURLフィールドは、指定された接続名に基づき自動的に設定されます。サーバーのデフォルト設定を変更した場合は、このフィールドを編集する必要があります。

- ランタイムURLフィールドは、指定された接続名に基づき自動的に設定されます。サーバーのデフォルト設定を変更した場合は、このフィールドを編集する必要があります。

- 「このJDeveloperセッションのログイン資格証明を指定」オプションを有効にします。

- 「ユーザー名」には、コンテンツ・サーバーの管理ユーザー名を入力します。

- 「パスワード」には、コンテンツ・サーバーの管理パスワードを入力します。

5. 「接続のテストとログイン」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの接続名とURLが正しいこと、また有効なログイン資格証明を指定したことを確認してください。

6. 「OK」をクリックします。

4.1.3 プロジェクトへの接続の追加

Site Studioプロジェクトにコンテンツ・サーバー接続を追加する手順は次のとおりです。

1. アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。

2. 「接続」を開いてから、「Site Studio」を開きます。

3. 新しいコンテンツ・サーバー接続を右クリックして、「プロジェクトに追加」を選択します。

4. 「プロジェクトの選択」ダイアログで、リストから「SiteStudioDemo.jpr」を選択します。

5. 「OK」をクリックします。

6. JDeveloperメイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2 サンプルWebサイトの作成

サンプルのWebサイトを作成する手順は次のとおりです。

- ステップ1: コンテンツ・サーバーでのWebサイトの新規作成

- ステップ2: コントリビューション・モードでのユーザー資格証明の指定

- ステップ3: Webアプリケーション・デプロイメント・ディスクリプタの編集

- ステップ4: ホームページの作成

- ステップ5: サイトへのページ・テンプレートの関連付け

- ステップ6: サイトの実行とホームページの表示

- ステップ7: サイト・フラグメントの作成

- ステップ8: 要素定義の作成

- ステップ9: リージョン定義の作成

- ステップ10: リージョン・テンプレートの作成

- ステップ11: プレースホルダ定義の作成

- ステップ12: ホームページへのプレースホルダの追加

- ステップ13: プレースホルダへのコンテンツの割当て

4.2.1 コンテンツ・サーバーでのWebサイトの新規作成

コンテンツ・サーバーでWebサイトを新規作成する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を開いてから「WEB-INF」を開きます。

4. 「wcm-config.xml」を右クリックして「開く」を選択します。

5. 「サーバー」タブを選択して、「サイト」を開きます。

6. 「作成」ボタンをクリックします。

7. 「新規サイトの作成」ダイアログで名前およびIDフィールドにSiteStudioDemoと入力します。

8. 「OK」をクリックします。

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.2 コントリビューション・モードでのユーザー資格証明の指定

コントリビューション・モードでユーザー資格証明を指定する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を開いてから「WEB-INF」を開きます。

4. 「weblogic.xml」を右クリックして「開く」を選択します。

5. 「セキュリティ」を選択して、「セキュリティ・ロールの割当て」を開きます。

6. 「作成」ボタンをクリックします。

7. 「ロール名」には、WCMContributorと入力します。

8. プリンシパル・セクションで、「作成」ボタンをクリックします。
新しく作成されたセキュリティ・ロールに、コンテンツ・サーバーに存在するプリンシパルと一致するプリンシパル(ユーザー)を追加します。このチュートリアルでは、weblogic プリンシパルを使用します。

9. プリンシパル名には、weblogicと入力します。

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.3 Webアプリケーション・デプロイメント・ディスクリプタの編集

Webアプリケーションを編集してJSPFファイルを処理する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を開いてから「WEB-INF」を開きます。

4. 「web.xml」を右クリックして「開く」を選択します。

5. 「ページ」を選択して、「JSPプロパティ・グループ」を開きます。

6. 「作成」ボタンをクリックします。

7. 新しいJSPプロパティ・グループで、「一般」タブを選択します。

- 「名前の表示」には、Fragmentsと入力します。

- 「ページ・エンコード」には、UTF-8と入力します。

- 「XML」オプションを有効にします。

8. 「URLパターン」タブを選択します。

9. 「作成」ボタンをクリックします。

10. 新しいURLパターンとして*.jspfを入力します。

11. メイン・メニューで「ファイル」→「すべて保存」を選択します。

注意:
環境のエンコーディングをUTF-8に設定するには、「ツール」を選択してから「プリファレンス」を選択します。

4.2.4 ホームページの新規作成

ユーザー・アプリケーションで簡単なホームページを作成する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

4. 「ページ」を右クリックして、「新規」を選択します。

5. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

6. アイテム・リストで、「JSP」を選択します。

7. 「OK」をクリックします。

8. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」には、home.jspxと入力します。

- XMLドキュメントとして作成オプションを有効にします。

- 「サイト・ファイルの登録」オプションを有効にします。

- 「アセット・タイプ」には、リストから「ページ・テンプレート」を選択します。

- 「サイト・ファイルID」には、ssd-home-ptと入力します。

- 「説明」には、Homepage for SiteStudioDemo siteと入力します。

- 「OK」をクリックします。

注意:
このチュートリアルでは、ローカル(通常はJDeveloper上のプロジェクト内のサブディレクトリ)に保存されているJSPXテンプレートを使用します。JSPXテンプレートの作成と編集の詳細は、第1.10項「Site Studio JSP/JSPXテンプレートの理解」を参照してください。

9. エディタに新しいページ・テンプレートが開いたら、「ソース」タブを選択します。

10. このチュートリアルでは、デフォルトのエンコーディングがUTF-8に設定されていることが前提となります。異なるエンコーディングが設定されている場合は、encodingおよびcharsetエントリを必要に応じて編集するか、次のコードで置き換えます。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html;charset=UTF-8"/>

<head>セクション:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

11. スタイル・シートを<head>セクションに追加します。

注意:
このチュートリアルでは、スタイル・シートを使用せずに済ませることも、後にオプションでスタイル・シートをサイトに追加することもできます。

例:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>SiteStudioDemo</title>
<link type="text/css" rel="stylesheet"
href="../wcm/css/template.css"/>
</head>

注意:
これは単なる例です。サブディレクトリとスタイル・シートの名前を正確に指定する必要があります。例: href="../styles/basicstyle4.css".

SiteStudioDemoサイトでは、ヘッダー、メニュー、サイドバー、フッター(JSPセグメント)が使用されます。既存のCSSファイルを使用するか、新規にスタイル・シートを作成するか、このチュートリアルに用意されているスタイル・シートをコピーできます。詳細は、第4.5項「スタイル・シートの追加」を参照してください。

- このチュートリアルのコード・サンプルは、template.cssスタイル・シートを参照します。これは単なる例です。スタイル・シートを新規作成する手順は、第4.5.1項「スタイル・シートの新規作成」を参照してください。

- このチュートリアルのコード・サンプルは、スタイル・シートの場所としてWebコンテンツ・サブディレクトリ/wcm/cssを参照します。これは単なる例です。このサブディレクトリの作成方法は、第4.5.2項「CSSファイル用サブディレクトリの作成」を参照してください。

12. <body>セクションを次のコードで置き換えます。

注意:
このコードには4つのJSPFファイルへの参照が含まれます。これらのJSPセグメントは、このチュートリアルの後半で作成します。

<body>
<jsp:include page="/wcm/templates/fragments/header.jspf"/>
<div id="container">
<jsp:include page="/wcm/templates/fragments/menu.jspf"/>
<jsp:include page="/wcm/templates/fragments/sidebar.jspf"/>
<!-- add content here -->
<jsp:include page="/wcm/templates/fragments/footer.jspf"/>
</div>
</body>

13. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.5 サイトへのページ・テンプレートの関連付け

新規に作成したhome.jspxページ・テンプレートをSiteStudioDemoサイトに関連付ける手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

4. 「SiteStudioDemo.xml」を右クリックして、「開く」を選択します。

5. サイト構造エディタで、「Home」を右クリックして、「プライマリ・ページ・テンプレートの選択」を選択します。

6. 「ssd-home-pt」を選択して、「OK」をクリックします。

7. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.6 サイトの実行とホームページの表示

ホームページを表示する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を開きます。

4. 「startSiteStudioDemo.jspx」を右クリックして、「実行」を選択します。

5. 統合されたWebLogicサーバーが起動すると、ログ・パネルに起動情報が表示されます。アプリケーションの起動後に、ブラウザ・ウィンドウが開き、SiteStudioDemoホームページが表示されます。

4.2.7 サイト・フラグメントの作成

JSPセグメントをヘッダー、フッター、サイドバー、およびメニューに追加する手順は、次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「サイト・ファイル」を開きます。

4. 「テンプレート」を「新規」を選択します。

5. 「新規ギャラリ」ダイアログで、「すべてのアイテム」を選択します。

6. アイテム・リストからフォルダ(一般)を選択します。

7. 「OK」をクリックします。

8. 「フォルダの作成」ダイアログで「フォルダ名」にfragmentsと入力します。

9. 「OK」をクリックします。

JSPセグメント(ヘッダー)の作成

10. 新しいフラグメント・フォルダを右クリックして、「新規」を選択します。

11. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

12. アイテム・リストで、「JSPセグメント」を選択します。

13. 「OK」をクリックします。

14. 「JSPセグメントの作成」ダイアログの「ファイル名」にheader.jspfと入力します。

15. 「OK」をクリックします。

16. エディタに新しいJSPセグメントが表示されたら、「ソース」タブを選択します。

17. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="top">
<b>
<a href="#">SiteStudioDemo</a>
</b>
</div>
</jsp:root>

18. メイン・メニューで「ファイル」→「すべて保存」を選択します。

2番目のJSPセグメント(フッター)の作成

1. 新しいフラグメント・フォルダを右クリックして、「新規」を選択します。

2. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

3. アイテム・リストで、「JSPセグメント」を選択します。

4. 「OK」をクリックします。

5. 「JSPセグメントの作成」ダイアログの「ファイル名」にfooter.jspfと入力します。

6. 「OK」をクリックします。

7. エディタに新しいJSPセグメントが表示されたら、「ソース」タブを選択します。

8. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="footer">
<p align="center">
Copyright © 2010 | SiteStudioDemo
</p>
</div>
</jsp:root>

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

3番目のJSPセグメント(サイドバー)の作成

1. 新しいフラグメント・フォルダを右クリックして、「新規」を選択します。

2. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

3. アイテム・リストで、「JSPセグメント」を選択します。

4. 「OK」をクリックします。

5. 「JSPセグメントの作成」ダイアログの「ファイル名」にsidebar.jspfと入力します。

6. 「OK」をクリックします。

7. エディタに新しいJSPセグメントが表示されたら、「ソース」タブを選択します。

8. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1">
<div id="sidebar">
<h1 class="first">The Sidebar</h1>
<p><!-- add content here -->
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
In sit amet lacus sed lacus egestas fringilla eu sit amet leo.
In hac habitasse platea dictumst.
</p>
<h1>Linkroll</h1>
<ul class="linkroll">
<li>
<a href="#">Link 1</a>
</li>
<li>
<a href="#">Link 2</a>
</li>
<li>
<a href="#">Link 3</a>
</li>
<li>
<a href="#">Link 4</a>
</li>
</ul>
</div>
</jsp:root>

9. "Lorem ipsum"を適した内容に変更します。

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4番目のJSPセグメント(メニュー)の作成

1. 新しいフラグメント・フォルダを右クリックして、「新規」を選択します。

2. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

3. アイテム・リストで、「JSPセグメント」を選択します。

4. 「OK」をクリックします。

5. 「JSPセグメントの作成」ダイアログの「ファイル名」にmenu.jspfと入力します。

6. 「OK」をクリックします。

7. エディタに新しいJSPセグメントが表示されたら、「ソース」タブを選択します。

8. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:fn="http://java.sun.com/jsp/jstl/functions">
<div id="menu">
<ul id="nav">
<li>
<wcm:url var="root" type="node"
url="${wcmContext.project.structure.rootSection.ID}"/>
<a href="${root}">
${wcmContext.project.structure.rootSection.properties.label}
</a>
</li>
<c:set var="sections"
value="${wcmContext.project.structure.rootSection.activeChildren}"/>

<!-- Iterate through the site structure nodes and add them to the menu -->
<c:forEach var="section" items="${sections}">
<wcm:url var="sectionUrl" type="node" url="${section.ID}"/>
<li>
<a title="${section.properties.label}" href="${sectionUrl}">
<em>${fn:substring(section.properties.label, 0, 1)}</em>
${fn:substring(section.properties.label, 1, -1)}
</a>
</li>
</c:forEach>
</ul>
<br class="clear"/>
</div>
</jsp:root>

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.8 要素定義の作成

2つの要素定義ファイルを作成する手順は次のとおりです。

1. メイン・メニューから「表示」、「Site Studio」→「サイト・アセット」を選択します。

2. 「プロジェクト」ドロップダウン・リスト(上部左)から「SiteStudioDemo」プロジェクトを選択します。
プロジェクトがリストされない場合は、接続にログインしていないことを示します。「アプリケーション・リソース」パネルで「接続」→「Site Studio」を選択し、接続を右クリックして「ログイン」を選択します。

3. 「アセット・タイプ」ドロップダウン・リスト(上部右)から「要素定義」を選択します。

4. 新規アセット・タイプの作成ボタンをクリックして、新規プレーン・テキスト要素の定義を選択します。

5. 「タイトル」と「コンテンツID」の両方に「ssd-plaintext-ed」と入力します。

6. 「OK」をクリックします。

7. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

8. 新規アセット・タイプの作成ボタンを再度クリックして新規WYSIWYG要素定義を選択します。

9. 「タイトル」と「コンテンツID」の両方にssd-wysiwyg-edと入力します。

10. 「OK」をクリックします。

11. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

12. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.9 リージョン定義の作成

コンテンツ・サーバーでリージョン定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リスト(上部右)から「リージョン定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして、新規リージョン定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-content-rdと入力します。

4. 「OK」をクリックします。

5. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

6. 「ssd-content_rd」アセットを右クリックして、「編集」を選択します。

7. エディタにリージョン定義が表示されたら、「追加」をクリックします。

8. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方に、titleと入力します。

- 場所には、「参照」をクリックします。

- ssd-plaintext-ed要素定義を選択して「OK」をクリックします。

- 再度「OK」をクリックします。

9. 「追加」をクリックします。

10. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方にcontentと入力します。

- 場所には、「参照」をクリックします。

- 「ssd-wysiwyg-ed」要素定義を選択して、「OK」をクリックします。

- 再度「OK」をクリックします。

11. メイン・メニューで「ファイル」→「すべて保存」を選択します。

12. 「チェックイン」ダイアログで「OK」をクリックします。

4.2.10 リージョン・テンプレートの作成

リージョン定義ファイルを使用するリージョン・テンプレートを作成する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

4. 「リージョン」を右クリックして、「新規」を選択します。

5. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

6. アイテム・リストで、「JSP」を選択します。

7. 「OK」をクリックします。

8. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」にcontent.jspxと入力します。

- XMLドキュメントの作成オプションを選択します。

- 「サイト・ファイルの登録」オプションを選択します。

- 「アセット・タイプ」ドロップダウン・リストから「リージョン・テンプレート」を選択します。

- 「サイト・ファイルID」には、ssd-content-rtと入力します。

- 「説明」には、Content Region Templateと入力します。

- 「リージョン定義」では、「参照」をクリックします。

- 「ssd-content-rd」リージョン定義を選択して、「OK」をクリックします。

- 再度「OK」をクリックします。

9. エディタに新しいテンプレートが表示されたら、「ソース」タブをクリックします。

10. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<wcm:dataFile var="dataFile"/>
<div id="content">
<h1><a href="#">${dataFile.title}</a></h1>
<p>${dataFile.content}</p>
</div>
</jsp:root>

11. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.11 プレースホルダ定義の作成

新しいリージョン定義テンプレートと新しいリージョン定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リスト(上部右)から「プレースホルダ定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして、新規プレースホルダ定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-content-phdと入力します。

4. 「OK」をクリックします。

5. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

6. 「ssd-content_phd」を右クリックして「編集」を選択してエディタで開きます。

7. すべての「許可されたアクション」・オプションを選択します。

8. リージョン定義表で「追加」をクリックします。

9. ssd-content-rdを選択して「OK」をクリックします。

10. リージョン・テンプレート表で、「追加」をクリックしてssd-content-rtと入力します。

11. ssd-content-rtを選択して「OK」をクリックします。

12. メイン・メニューで「ファイル」→「すべて保存」を選択します。

13. 「チェックイン」ダイアログで「OK」をクリックします。

4.2.12 ホームページへのプレースホルダの追加

home.jspxにプレースホルダを追加する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「サイト・ファイル」を開き、「テンプレート」を開いてから「ページ」を開きます。

4. 「home.jspx」を右クリックして「開く」を選択します。

5. エディタにホームページが表示されたら、「ソース」タブを選択します。

6. メイン・メニューで「表示」→「コンポーネント・パレット」を選択します。

7. 「コンポーネント・パレット」で、ドロップダウン・リストから「Site Studio」を選択します。

8. 「プレースホルダの挿入」ダイアログで次の操作を実行します。

- 「名前」にcontentと入力します。

- 「プレースホルダ定義マッピングへの名前の追加」オプションを有効にします。

- ドロップダウン・リストから「SiteStudioDemo」を選択します。

- 「OK」をクリックします。

9. 次のようなホームページが表示されます。

<body>
<jsp:include page="/wcm/templates/fragments/header.jspf"/>
<div id="container">
<jsp:include page="/wcm/templates/fragments/menu.jspf"/>
<jsp:include page="/wcm/templates/fragments/sidebar.jspf"/>
<!-- add content here -->
<wcm:placeholder name="content"/>
<jsp:include page="/wcm/templates/fragments/footer.jspf"/>
</div>
</body>

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

11. Site Studioプロジェクト(SiteStudioDemo)を開きます。

12. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

13. 「SiteStudioDemo.xml」を右クリックして、「開く」を選択します。

14. サイト構造エディタで、Webサイト(SiteStudioDemo)ノードを開きます。

15. 「デザイン・モード・ロール」をクリックして、ドロップダウン・リストからadminセキュリティ・ロールを選択します。

16. 「プレースホルダ定義マッピング」ボタンをクリックします。

17. リストから「コンテンツ」を選択して、「編集」をクリックします。

18. 「プレースホルダ定義マッピングの編集」ダイアログで次の操作を実行します。

- 「プライマリ定義ID」で「検索」をクリックします。

- 「ssd-content-phd」を選択して「OK」をクリックします。

- 再度「OK」をクリックします。

19. 「OK」をクリックします。

20. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.2.13 プレースホルダへのコンテンツの割当て

コントリビューション・モードに入って、ホームページ上のプレースホルダにコンテンツを追加する手順は次のとおりです。

1. ユーザーのSite Studioプロジェクト(SiteStudioDemo)を開き、「Webコンテンツ」を開きます。

2. 「startSiteStudioDemo.jspx」を右クリックして、「実行」を選択します。

3. アプリケーションがロードされたら、[Ctrl]と[Shift]と[F5]を同時に押してコントリビューション・モードに入ります。

4. 「コンテンツ」 プレースホルダでは、「コンテンツの割当」ボタンをクリックします。

5. コンテンツの切替えウィザードのコンテンツ・ファイルの選択ステップで「新規コントリビュータ・データファイル」オプションを有効にします。

6. 「次」をクリックします。

7. コンテンツのチェックイン・ステップでは、次の操作を実行します。

- 「コンテンツID」にssd-home-dfと入力します。

- 「Webサイト」で、SiteStudioDemoがリストされていることを確認します(これは自動的にリストされます)。

- 「リージョン定義」で、ssd-content-rdがリストされていることを確認します(これは自動的にリストされます)。

8. 「終了」をクリックします。

9. コンテンツ・プレースホルダで、「リージョン・コンテンツの編集」ボタンをクリックします。

10. 「要素」タブの「タイトル」にIntroductionと入力します。

11. コンテンツ・エディタでテキストを追加します。

12. 「保存して閉じる」ボタンをクリックします。

13. [Ctrl]と[Shift]と[F5]を同時に押してコントリビューション・モードを終了します。

4.3 サイドバー・リンクの作成

この項は、チュートリアル内の前の項に基づいて構成されています。静的プレースホルダを作成して、サイトのサイドバーにリンクを表示する手順は次のとおりです。

- ステップ1: 静的リスト要素定義の作成

- ステップ2: サイドバー・リージョン定義の作成

- ステップ3: 静的リスト・データファイルの作成

- ステップ4: リージョン・テンプレートの作成

- ステップ5: サイドバー・フラグメントの更新

- ステップ6: サイドバー・コンテンツ・リージョン定義の作成

- ステップ7: サイドバー・コンテンツ・リージョン・テンプレートの作成

- ステップ8: サイドバー・コンテンツ・プレースホルダ定義の作成

- ステップ9: サイトへのサイドバー・プレースホルダ・マッピングの追加

- ステップ10: サイドバーへのコンテンツの割当て

4.3.1 静的リスト要素定義の作成

静的リスト要素定義を作成する手順は次のとおりです。

1. メイン・メニューから「表示」→「Site Studio」→「サイト・アセット」を選択します。

2. 「プロジェクト」ドロップダウン・リスト(上部左)から「SiteStudioDemo」プロジェクトを選択します。

3. 「アセット・タイプ」ドロップダウン・リスト(上部右)から「要素定義」を選択します。

4. 新規アセット・タイプの作成ボタンをクリックして、新規静的リスト要素定義を選択します。

5. 「タイトル」と「コンテンツID」の両方にssd-links-staticlist-edと入力して「OK」をクリックします。

6. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

7. 「ssd-links-staticlist-ed」アセットを右クリックして、「編集」を選択します。

8. 「要素」をクリックします。

9. 「要素」ダイアログで「追加」をクリックします。

10. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方に、labelと入力します。

- 場所には、「参照」をクリックします。

- ssd-plaintext-ed要素定義を選択して「OK」をクリックします。

- 再度「OK」をクリックします。

11. 「追加」をクリックして、2番目の要素を追加します。

12. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方に、urlと入力します。

- 場所には、「参照」をクリックします。

- ssd-plaintext-ed要素定義を選択して「OK」をクリックします。

- 再度「OK」をクリックします。

13. 「要素」ダイアログで「OK」をクリックします。

14. メイン・メニューで「ファイル」→「すべて保存」を選択します。

15. 「チェックイン」ダイアログで「OK」をクリックします。

4.3.2 サイドバー・リージョン定義の作成

サイドバー・リージョン定義を作成する手順は次のとおりです。

1. メイン・メニューから「表示」→「Site Studio」→「サイト・アセット」を選択します。

2. 「アセット・タイプ」ドロップダウン・リスト(上部右)から「リージョン定義」を選択します。

3. 新規アセット・タイプの作成ボタンをクリックして、新規リージョン定義を選択します。

4. 「タイトル」と「コンテンツID」の両方にssd-links-rdと入力して、「OK」をクリックします。

5. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

6. ssd-links-rdアセットを右クリックして、「編集」を選択します。

7. エディタにリージョン定義が表示されたら、「追加」をクリックします。

8. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方にlinksと入力します。

- 場所には、「参照」をクリックします。

- ssd-links-staticlist-ed要素定義を選択して、「OK」をクリックします。

- 再度「OK」をクリックします。

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

10. 「チェックイン」ダイアログで「OK」をクリックします。

4.3.3 静的リスト・データファイルの作成

静的リスト・データファイルを作成する手順は次のとおりです。

1. メイン・メニューから「表示」→「Site Studio」→「サイト・アセット」を選択します。

2. 「アセット・タイプ」ドロップダウン・リストから「データファイル」を選択します。

3. 新規アセット・タイプの作成ボタンをクリックして、「新規コントリビュータ・データファイル」を選択します。

4. 新規アセットの作成ダイアログで次の操作を実行します。

- 「タイトル」と「コンテンツID」の両方にssd-sidebarlinks-dfと入力します。

- 「リージョン定義」では、「参照」をクリックします。

- ssd-links-rdリージョン定義を選択して、「OK」をクリックします。

- 再度「OK」をクリックします。

5. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.3.4 リージョン・テンプレートの作成

リージョン・テンプレートを使用するリージョン・ファイルを作成する手順は次のとおりです。

1. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

2. 「リージョン」ノードを右クリックして、「新規」を選択します。

3. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

4. アイテム・リストで、「JSP」を選択します。

5. 「OK」をクリックします。

6. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」にlinks.jspxと入力します。

- XMLドキュメントの作成オプションを選択します。

- 「サイト・ファイルの登録」オプションを選択します。

- 「アセット・タイプ」ドロップダウン・リストから「リージョン・テンプレート」を選択します。

- 「サイト・ファイルID」にssd-links-rtと入力します。

- 「説明」にSidebar Region Templateと入力します。

- 「リージョン定義」では、「参照」をクリックします。

- ssd-links-rdリージョン定義を選択して、「OK」をクリックします。

- 再度「OK」をクリックします。

7. エディタに新しいリージョン定義が表示されたら、「ソース」タブをクリックします。

8. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<wcm:dataFile var="dataFile"/>
<ul class="linkroll">    <c:forEach var="row" items="${dataFile.links.rows}">
<li>
<a href="${row.url}">${row.label}</a>
</li>
</c:forEach>
</ul>
</jsp:root>

9. 前述のサイドバー・リージョン・テンプレートでは、新しいssd-sidebarlinks-dfデータファイルの使用法と、プロパティを参照してデータをフォーマットする方法に注目してください。

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.3.5 サイドバー・フラグメントの更新

サイドバー・フラグメントを更新する手順は次のとおりです。

1. 「サイト・ファイル」を開いて、「テンプレート」→「フラグメント」を選択します。

2. sidebar.jspfフラグメントを右クリックして、「開く」を選択します。

3. エディタでファイルが開いたら、「ソース」タブをクリックします。

4. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:fn="http://java.sun.com/jsp/jstl/functions">
<div id="sidebar">
<h1 class="first">Sidebar</h1>
<p>
<wcm:placeholder name="sidebar"/>
</p>
<h1>Linkroll</h1>

<wcm:staticPlaceholder dataFile="ssd-sidebarlinks-df"
template="@ssd-links-rt"/>
</div>
</jsp:root>

5. 前述のサイドバー・リージョン・テンプレートでは、データファイルの使用法とデータファイル・プロパティの参照方法に注目してください。

6. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.3.6 サイドバー・コンテンツ・リージョン定義の作成

サイドバー・コンテンツ・リージョン定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リストから「リージョン定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして、新規リージョン定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-text-rdと入力して、「OK」をクリックします。

4. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

5. 「ssd-text-rd」アセットを右クリックして、「編集」を選択します。

6. エディタにリージョン定義が表示されたら、「追加」をクリックします。

7. 「要素インスタンス」ダイアログで次の操作を実行します。

- 「名前」と「ラベル」の両方にtextと入力します。

- 場所には、「参照」をクリックします。

- 「ssd-wysiwyg-ed」 要素定義を選択して「OK」をクリックします。

8. 再度「OK」をクリックします。

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

10. 「チェックイン」ダイアログで「OK」をクリックします。

4.3.7 サイドバー・コンテンツ・リージョン・テンプレートの作成

サイドバー・コンテンツ・リージョン・テンプレートを作成する手順は次のとおりです。

1. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

2. 「リージョン」を右クリックして、「新規」を選択します。

3. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

4. アイテム・リストで、「JSP」を選択します。

5. 「OK」をクリックします。

6. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」には、simple.jspxと入力します。

- XMLドキュメントの作成オプションを選択します。

- 「サイト・ファイルの登録」オプションを選択します。

- 「アセット・タイプ」ドロップダウン・リストから「リージョン・テンプレート」を選択します。

- 「サイト・ファイルID」には、ssd-text-rtと入力します。

- 「説明」にText Region Templateと入力します。

- 「リージョン定義」では、「参照」をクリックします。

- ssd-text-rdリージョン定義を選択して、「OK」をクリックします。

7. 再度「OK」をクリックします。

8. エディタでファイルが開いたら、「ソース」タブをクリックします。

9. 次のコードを追加します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<wcm:dataFile var="dataFile"/>
<p>${dataFile.text}</p>
</jsp:root>

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

11. 「チェックイン」ダイアログで「OK」をクリックします。

4.3.8 サイドバー・コンテンツ・プレースホルダ定義の作成

サイドバー・コンテンツ・プレースホルダ定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リストから「プレースホルダ定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして、新規プレースホルダ定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-simple-phdと入力して「OK」をクリックします。

4. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

5. ssd-simple-phdアセットを右クリックして「編集」を選択します。

6. すべての「許可されたアクション」・オプションを選択します。

7. リージョン定義表で「追加」をクリックします。

8. ssd-text-rdを選択して「OK」をクリックします。

9. リージョン・テンプレート表で、「追加」をクリックします。

10. ssd-simple-rtを選択して「OK」をクリックします。

11. メイン・メニューで「ファイル」→「すべて保存」を選択します。

12. 「チェックイン」ダイアログで「OK」をクリックします。

4.3.9 サイトへのサイドバー・プレースホルダ・マッピングの追加

サイトにサイドバー・プレースホルダ・マッピングを追加する手順は次のとおりです。

1. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

2. 「SiteStudioDemo.xml」を右クリックして、「開く」を選択します。

3. 「プレースホルダ定義マッピング」ボタンをクリックします。

4. 「プレースホルダ定義マッピング」ダイアログで「追加」をクリックします。

5. 「プレースホルダ定義マッピングの定義」ダイアログで次の操作を実行します。

- 「名前」にsidebarと入力します。

- 「プライマリ定義ID」で「検索」をクリックします。

- ssd-simple-phdを選択して「OK」をクリックします。

- 再度「OK」をクリックします。

6. 「プレースホルダ定義マッピング」ダイアログで「OK」をクリックします。

7. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.3.10 サイドバーへのコンテンツの割当て

コントリビューション・モードに入り、サイドバー上のプレースホルダにコンテンツを追加する手順は次のとおりです。

1. ユーザーのSite Studioプロジェクト(SiteStudioDemo)を開き、「Webコンテンツ」を開きます。

2. 「startSiteStudioDemo.jspx」を右クリックして、「実行」を選択します。

3. アプリケーションがロードされたら、[Ctrl]と[Shift]と[F5]を同時に押してコントリビューション・モードに入ります。

4. 「設計モードへの切替え」ボタン(右上の角)をクリックします。

5. サイドバー・プレースホルダで「コンテンツの割当」ボタンをクリックします。

6. コンテンツの切替えウィザードのコンテンツ・リージョンの選択ステップでssd-text-rdを選択します。

7. コンテンツ・ファイルの選択ステップで、「新規コントリビュータ・データファイル」オプションを選択します。

8. 「次」をクリックします。

9. コンテンツのチェックイン・ステップでは、次の操作を実行します。

- 「コンテンツID」にssd-sidebarcontent-dfと入力します。

- 「Webサイト」で、SiteStudioDemoがリストされていることを確認します(これは自動的にリストされます)。

- 「リージョン定義」にssd-text-rdがリストされている(これは自動的にリストされる)ことを確認します。

10. 「終了」をクリックします。

11. 「設計モードへの切替え」ボタン(右上の角)をクリックします。

12. サイドバー・プレースホルダでリージョン・コンテンツの編集ボタンをクリックします。

13. テキスト・エディタでIntroductionと入力します。

14. 「保存して閉じる」ボタンをクリックします。

15. ssd-sidebarlinks-dfプレースホルダで「リージョン・コンテンツの編集」ボタンをクリックします。

16. リンク・エディタで「行の追加」→「行の編集」をクリックして次のリンクを追加します。
リンク1:

- 「ラベル」にGoogleと入力します。

- 「URL」にhttp://www.google.comと入力します。

- 「行を更新して閉じる」をクリックします。

リンク2:

- 「ラベル」にYahoo!と入力します。

- 「URL」にhttp://www.yahoo.comと入力します。

- 「行を更新して閉じる」をクリックします。

リンク3:

- 「ラベル」にBingと入力します。

- 「URL」にhttp://www.bing.comと入力します。

- 「行を更新して閉じる」をクリックします。

17. 「保存して閉じる」ボタンをクリックします。

18. [Ctrl]と[Shift]と[F5]を同時に押してコントリビューション・モードを終了します。

4.4 動的変換ページの作成

この項は、チュートリアル内の前の項に基づいて構成されています。以下は動的変換ページの追加手順です。これは、アプリケーション内でのネイティブ・ドキュメントの使用法を示します。手順を実行する前に、コンテンツ・サーバーのDynamicConverterが有効なこと、また正しく設定されていることを確認してください。

- ステップ1: 変換定義の作成

- ステップ2: ネイティブ・ドキュメント用ページ・テンプレートの作成

- ステップ3: ネイティブ・ドキュメント用新規セクションの作成

- ステップ4: ネイティブ・ドキュメント用リージョン定義の作成

- ステップ5: ネイティブ・ドキュメント用リージョン・テンプレートの作成

- ステップ6: ネイティブ・ドキュメント用プレースホルダ定義の作成

- ステップ7: ネイティブ・ドキュメント・ページへのプレースホルダの追加

- ステップ8: ネイティブ・ドキュメント・ページ上のプレースホルダに対するコンテンツの割当て

4.4.1 変換定義の作成

変換定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リストから「変換定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして新規変換定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-default-cdと入力して「OK」をクリックします。

4. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

5. ssd-default-cdアセットを右クリックして、「編集」を選択します。

6. エディタに変換定義が表示されたら、「追加」をクリックして定義に動的変換ルールを追加します。

7. 「ネイティブ・ドキュメント変換設定」ダイアログで次の操作を実行します。

- 「名前」にsimpleと入力します。

- 「オプション」で「単純なインライン動的変換の使用」を有効にします。

- 「OK」をクリックします。

8. メイン・メニューで「ファイル」→「すべて保存」を選択します。

9. 「チェックイン」ダイアログで「OK」をクリックします。

10. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

11. 「SiteStudioDemo.xml」を右クリックして、「開く」を選択します。

12. Webサイト(SiteStudioDemo)ノードを開きます。

13. 「変換定義」の値をダブルクリックして「変換定義を選択します」ダイアログを表示します。ssd-default-cd変換定義を選択します。

14. 「OK」をクリックします。

15. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.4.2 ネイティブ・ドキュメント用ページ・テンプレートの作成

ネイティブ・ドキュメント用ページ・テンプレートを作成する手順は次のとおりです。

1. Site Studioプロジェクト(SiteStudioDemo)を開きます。

2. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

3. ページ・ノードを右クリックして「新規」を選択します。

4. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

5. アイテム・リストで、「JSP」を選択します。

6. 「OK」をクリックします。

7. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」にnative.jspxと入力します。

- XMLドキュメントとして作成オプションを有効にします。

- 「サイト・ファイルの登録」オプションを有効にします。

- 「アセット・タイプ」には、リストから「ページ・テンプレート」を選択します。

- 「サイト・ファイルID」にssd-native-ptと入力します。

- 「説明」にNative Documents Page for the SiteStudioDemo siteと入力します。

- 「OK」をクリックします。

8. 次の内容を追加してファイルを保存します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>SiteStudioDemo - Demo Blog</title>
<link type="text/css" rel="stylesheet"
href="../wcm/css/template.css"/>
</head>
<body>
<jsp:include page="/wcm/templates/fragments/header.jspf"/>
<div id="container">
<jsp:include page="/wcm/templates/fragments/menu.jspf"/>

<jsp:include page="/wcm/templates/fragments/sidebar.jspf"/>
<!--
Add content below.
-->
<jsp:include page="/wcm/templates/fragments/footer.jspf"/>
</div>
</body>
</html>
</jsp:root>

4.4.3 ネイティブ・ドキュメント用新規セクションの作成

新規のページ・テンプレートをサイトに関連付ける手順は次のとおりです。

1. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

2. SiteStudioDemo.xmlを右クリックして「開く」を選択します。

3. Webサイト(SiteStudioDemo)ノードを開きます。

4. 「ホーム」を右クリックして「新規セクションの追加」を選択します。

5. 「新規セクションの追加」ダイアログで次の操作を実行します。

- 「ラベル」にAboutと入力します。

- 「URL」にAboutと入力します。

- 「OK」をクリックします。

6. 「バージョン情報」セクション・ノードで「セクションをナビゲーションに含める」を選択します。

7. 「バージョン情報」セクション・ノードを右クリックして「プライマリ・ページ・テンプレートの選択」を選択します。

8. 「ページ・テンプレートを選択します」ダイアログでssd-native-ptページ・テンプレートを選択します。

9. 「OK」をクリックします。

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.4.4 ネイティブ・ドキュメント用リージョン定義の作成

リージョン定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リストから「リージョン定義」を選択します。

2. 「新規作成」ボタンをクリックして新規リージョン定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-native-rdと入力して「OK」をクリックします。

4. 「リフレッシュ」ボタンをクリックして、リストを更新します。コンテンツ・サーバーによる新しいアセットの索引付けが完了してリストが表示されるまで数分間掛ることがあります。

5. ssd-native-rdを右クリックして「編集」を選択します。

6. 表から要素を選択して「リージョン・コンテンツの切替え」をクリックします。

7. 「リージョン・コンテンツ・オプション」ダイアログで「新規ネイティブ・ドキュメントの作成」オプションを有効にします。

8. 「ドキュメント・タイプ」で「選択」をクリックします。

9. リストから任意のドキュメント・タイプを選択して「OK」をクリックします。

10. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.4.5 ネイティブ・ドキュメント用リージョン・テンプレートの作成

ネイティブ・ドキュメント用リージョン・テンプレートを作成する手順は次のとおりです。

1. Site Studioプロジェクト(SiteStudioDemo)を開きます。

2. 「サイト・ファイル」を開いてから「テンプレート」を開きます。

3. 「リージョン」ノードを右クリックして、「新規」を選択します。

4. 「新規ギャラリ」ダイアログで、「Web層」を開き、「JSP」を選択します。

5. アイテム・セクションで「JSP」を選択します。

6. 「OK」をクリックします。

7. 「JSPの作成」ダイアログで次の操作を実行します。

- 「ファイル名」にconversion.jspxと入力します。

- XMLドキュメントとして作成オプションを有効にします。

- 「サイト・ファイルの登録」オプションを有効にします。

- 「アセット・タイプ」には「リージョン・テンプレート」を選択します。

- 「サイト・ファイルID」にssd-conversion-rtと入力します。

- 「説明」にNative File Region Templateと入力します。

- 「リージョン定義」には「参照」をクリックしてssd-native-rdリージョン定義を選択します。

- 「OK」をクリックします。

8. 次の内容を追加してファイルを保存します。

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:wcm="http://www.oracle.com/jsp/wcm">
<div id="content">
<wcm:dynamicConversion rule="simple"/>
</div>
</jsp:root>

4.4.6 ネイティブ・ドキュメント用プレースホルダ定義の作成

新規に作成されたリージョン・テンプレートとリージョン定義を使用するプレースホルダ定義を作成する手順は次のとおりです。

1. 「アセット・タイプ」ドロップダウン・リストから「プレースホルダ定義」を選択します。

2. 新規アセット・タイプの作成ボタンをクリックして、新規プレースホルダ定義を選択します。

3. 「タイトル」と「コンテンツID」の両方にssd-native-phdと入力します。

4. ssd-content-phdアセットを右クリックして「編集」を選択します。

5. リージョン定義表で「追加」をクリックしてssd-native-rdを選択します。

6. リージョン・テンプレート表で「追加」をクリックしてssd-conversion-rtと入力します。

7. すべての「許可されたアクション」・オプションを選択します。

8. メイン・メニューで「ファイル」→「すべて保存」を選択します。

9. チェックインしてプレースホルダ定義を閉じます。

4.4.7 ネイティブ・ドキュメント・ページへのプレースホルダの追加

native.jspxファイルにプレースホルダを追加する手順は次のとおりです。

1. コンポーネント・パレットから「Site Studio」を選択します。

2. 下のコンテンツを追加コメントの下のプレースホルダ・タグをドラッグします。

3. 「プレースホルダの挿入」ダイアログで次の操作を実行します。

- 「名前」にnativeと入力します。

- 「プレースホルダ定義マッピングへの名前の追加」オプションを選択します。

- サイトとしてSiteStudioDemoを選択します。

- 「OK」をクリックします。

4. 「Webコンテンツ」→「WEB-INF」→「サイト」を開きます。

5. 「SiteStudioDemo.xml」を右クリックして、「開く」を選択します。

6. 「プレースホルダ定義マッピング」ボタンをクリックします。

7. ネイティブのプレースホルダ定義マッピングを選択して「編集」をクリックします。

8. 「プレースホルダ定義マッピングの編集」ダイアログで次の操作を実行します。

- 「プライマリ定義ID」で「検索」をクリックします。

- ssd-simple-phdを選択して「OK」をクリックします。

- 再度「OK」をクリックします。

9. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.4.8 ネイティブ・ドキュメント・ページ上のプレースホルダに対するコンテンツの割当て

コントリビューション・モードに入り、ネイティブ・ドキュメント・ページ上のプレースホルダにコンテンツを割り当てる手順は次のとおりです。

1. ユーザーのSite Studioプロジェクト(SiteStudioDemo)を開き、「Webコンテンツ」を開きます。

2. startSiteStudioDemo.jspを右クリックして「実行」を選択します。

3. バージョン情報ページで[Ctrl]tと[Shift]と[F5]を同時に押してコントリビューション・モードに入ります。

4. ネイティブ・プレースホルダ上の「コンテンツの割当」ボタンをクリックします。

5. コンテンツの切替えウィザードでssd-native-rdリージョン定義を選択します。

6. 「次」をクリックします。

7. コンテンツ・ファイルの選択ステップで「既存のローカル・ファイル」オプションを選択します。

8. 「次」をクリックします。

9. コンテンツのチェックイン・ステップでは、次の操作を実行します。

- 「タイトル」と「コンテンツID」の両方にssd-about-native-dfと入力します。

- プライマリ・ファイルを参照して、それを選択します。

- 「Webサイト」で、SiteStudioDemoがリストされていることを確認します(これは自動的にリストされます)。

- リージョン定義にssd-native-rdがリストされている(自動的にリストされる)ことを確認します。

10. [Ctrl]と[Shift]と[F5]を同時に押してコントリビューション・モードを終了します。

11. ドキュメントの内容がバージョン情報ページに表示されます。

4.5 スタイル・シートの追加

この項はスタイル・シートのサンプル・サイトへの追加に関連する情報を提供し、次のトピックについて説明します。

- 第4.5.1項「スタイル・シートの新規作成」

- 第4.5.2項「CSSファイル用サブディレクトリの作成」

- 第4.5.3項「ページ・テンプレートへのスタイル・シートの追加」

- 第4.5.4項「サンプルのCSSドキュメント」

SiteStudioDemoサイトでは、ヘッダー、メニュー、サイドバー、フッター(JSPセグメント)が使用されます。既存のCSSファイルの利用、スタイル・シートの新規作成、またはこの項のサンプル・スタイル・シートのコピーが可能です。

- このチュートリアルのコード・サンプルは、template.cssスタイル・シートを参照します。これは単なる例です。スタイル・シートを新規作成する手順は、第4.5.1項「スタイル・シートの新規作成」を参照してください。

- このチュートリアルのコード・サンプルは、スタイル・シートの場所としてWebコンテンツ・サブディレクトリ/wcm/cssを参照します。これは単なる例です。このサブディレクトリの作成方法は、第4.5.2項「CSSファイル用サブディレクトリの作成」を参照してください。

グラフィック(オプション)

この項に用意されているサンプル・スタイル・シートはいくつかのJPGおよびGIFファイルを参照します。このチュートリアルに提供されているサンプルのCSSコードを表示する方法は、第4.5.4項「サンプルのCSSドキュメント」を参照してください。SiteStudioDemoサイトにこのスタイル・シートを使用する場合は、独自の画像の作成、参照の編集、参照の削除が可能です。

body.jpg
content.jpg
header.jpg
menu.jpg
menu_a.jpg
menu_a_hoover.jpg
menu_link.jpg
sidebar.jpg
top.jpg
linkroll.gif
linkroll_hoover.gif

4.5.1 スタイル・シートの新規作成

CSSファイルを新規作成する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を右クリックして「新規」を選択します。

4. 「新規ギャラリ」ダイアログで「すべてのアイテム」を選択します。

5. アイテム・リストから「CSSファイル(HTML)」を選択します。

6. 「OK」をクリックします。

7. 「Cascading Style Sheet」ダイアログで次の操作を実行します。

- 新しいスタイル・シートの名前を指定します。たとえば、template.cssなど。
このチュートリアル内のサンプル・コードは/wcm/cssWebコンテンツ・サブフォルダ内のtemplate.cssスタイル・シートを参照します。スタイル・シートとディレクトリは両方とも単なる例です。このサブディレクトリの作成方法は、第4.5.2項「CSSファイル用サブディレクトリの作成」を参照してください。

- 「OK」をクリックします。

8. Site Studioプロジェクト(SiteStudioDemo)を開きます。

9. 「Webコンテンツ」→「css」を開きます。

10. 「template.css」を右クリックして「開く」を選択します。

11. エディタでCSSファイルが開いたら、「ソース」タブを選択します。

12. SiteStudioDemoサイトでは、ヘッダー、メニュー、サイドバー、フッター(JSPセグメント)が使用されます。独自のコードを入力して新しいスタイル・シートを作成するか、このチュートリアルに用意されているサンプルのスタイル・シートをコピーして使用することができます。このチュートリアルに提供されているサンプルのCSSコードを表示する方法は、第4.5.4項「サンプルのCSSドキュメント」を参照してください。

13. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.5.2 CSSファイル用サブディレクトリの作成

このチュートリアルのコード・サンプルは、このスタイル・シートの場所としてWebコンテンツ・サブディレクトリ/wcm/cssを参照します。これは単なる例です。

注意:
サブフォルダを作成するには、フォルダを右クリックして「新規」→「すべてのアイテム」→フォルダ(一般)を選択して「OK」をクリックします。

このチュートリアルでCSSファイルの場所として使用されるサブディレクトリを再作成する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「Webコンテンツ」を右クリックして「新規」を選択します。

4. 「新規ギャラリ」ダイアログで「すべてのアイテム」を選択します。

5. アイテム・リストからフォルダ(一般)を選択します。

6. 「OK」をクリックします。

7. 「新規フォルダ」ダイアログで次の操作を実行します。

- 新しいフォルダの名前を指定します。たとえば、wcmなど。

- 「OK」をクリックします。

8. 「Webコンテンツ」→「wcm」を開きます。

9. 「wcm」を右クリックして、「新規」を選択します。

10. 「新規ギャラリ」ダイアログで「すべてのアイテム」を選択します。

11. アイテム・リストからフォルダ(一般)を選択します。

12. 「OK」をクリックします。

13. 「新規フォルダ」ダイアログで次の操作を実行します。

- 新しいサブフォルダの名前を指定します。たとえば、cssなど。

- 「OK」をクリックします。

14. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.5.3 ページ・テンプレートへのスタイル・シートの追加

ページ・テンプレートにCSSファイルを追加する手順は次のとおりです。

1. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

2. Site Studioプロジェクト(SiteStudioDemo)を開きます。

3. 「サイト・ファイル」を開いて、「テンプレート」→「ページ」を選択します。

4. home.jspx (ホームページにCSSを追加する場合は)を右クリックして「開く」をクリックします。

5. メイン・メニューから「表示」を選択してから「コンポーネント・パレット」を選択します。

6. コンポーネント・パレットでリストからCSSオプションを選択します。

7. プロジェクトのCSSファイル(例: template.css)を<head>セクションにドラッグします。

8. メイン・メニューで「ファイル」→「すべて保存」を選択します。

4.5.4 サンプルのCSSドキュメント

/* CSS Document */

body {
background-color:#fff;
background-image:url(../images/body.jpg);
background-position:top;
background-repeat:repeat-x;
font-family:Tahoma, Verdana, Arial, Helvetica, sans-serif;
font-size:78%;
color:#666;
margin:0;
}

#top {
width:715px;
padding:12px 25px 15px 25px;
background-image:url(../images/top.jpg);
background-position:top;
background-repeat:no-repeat;
color:#fff;
margin:0 auto;
text-align:right;
}

#top a {
padding:0 10px 0 10px;
color:#fff;
border:none;
}

#top a:hover {
text-decoration:none;
}

#top b {
float:left;
font-weight:normal;
}

#top b a {
border-left:1px dotted #ccc;
border-right:none;
border:none;
}

#container {
width:765px;
margin:0 auto;
background-image:url(../images/header.jpg);
background-position:top;
background-repeat:no-repeat;
padding:30px 0 0 0;
}

#menu {
width:706px;
margin:0 auto;
text-align:left;
background-image:url(../images/menu.jpg);
background-position:top;
background-repeat:repeat-x;
}

#menu #nav {
margin:0;
padding:0;
float:left;
}

#nav li {
margin:0;
padding:0;
list-style:none;
float:left;
}

#nav li a {
display:block;
width:100px;
text-align:center;
margin:0 1px 0 0;
background-image:url(../images/menu_link.jpg);
background-position:left;
background-repeat:no-repeat;
color:#ccc;
font-family:Trebuchet MS, Verdana, Arial, Helvetica, sans-serif;
font-size:14px;
text-transform:uppercase;
font-weight:bold;
text-decoration:none;
padding:55px 0 23px 0;
border:none;
}

#nav li a em {
font-style:normal;
text-decoration:underline;
}

#nav li a.last {
margin:0;
}

#nav li a:hover {
background-image:url(../images/menu_link.jpg);
background-position:right;
color:#fff;
}

#nav li a.active {
background-image:url(../images/menu_link.jpg);
background-position:right;
color:#fff;
}

.clear {
clear:both;
}

#sidebar {
width:262px;
float:right;
background-image:url(../images/sidebar.jpg);
background-position:top;
background-repeat:no-repeat;
margin:0 29px 0 0 !important;
margin:0 15px 0 0;
padding:7px 20px 20px 20px;
color:#777;
line-height:18px;
font-size:90%;
word-spacing:-1px;
}

#sidebar h1 {
font-family:Century Gothic, Verdana, Arial, Helvetica, sans-serif;
font-size:20px;
color:#F2C21C;
font-weight:normal;
margin:10px 0 10px 0;
}

#sidebar h1.first {
color:#fff;
margin:10px 0 35px 0;
}

#content {
margin:0 331px 0 20px;
background-image:url(../images/content.jpg);
background-position:top right;
background-repeat:no-repeat;
padding:10px 20px 10px 20px;
}

#content {
line-height:20px;
word-spacing:2px;
overflow: auto;
height: 400px;
}

#content h1, p.ID11A, p.IDDF {
font-family:Trebuchet MS, sans-serif;
font-size:24px;
color:#333;
font-weight:normal;
margin:30px 0 35px 0;
border-bottom:2px solid #F4C833;
padding:0 0 2px 0;
}

p.IDAC{
font-family:Trebuchet MS, sans-serif;
font-size:16px;
color:#333;
font-weight:normal;
margin:20px 0 20px 0;
letter-spacing:-2px;
font-style: italic;
padding:0 0 2px 0;
}

#content h1 a {
color:#333;
text-decoration:none;
border:none;
}

#content h1 a:hover {
color:#666;
}

#content p {
text-indent:15px;
}

#sidebar .linkroll {
margin:10px 0 10px 0;
padding:0;
border-top:1px solid #eee;
}

.linkroll li {
margin:1px;
padding:0 !important;
padding:1px;
list-style:none;
}

.linkroll li a {
padding:2px 2px 2px 18px;
display:block;
margin:0;
color:#777;
text-decoration:none;
border-bottom:1px solid #eee;
background-image:url(../images/document.gif);
background-position:left;
background-repeat:no-repeat;
}

.linkroll li a:hover {
border-bottom:1px solid #ccc;
background-color:#fbfbfb;
color:#444;
}

h2 {
font:120% Verdana;
color:#333;
border-bottom:1px dotted #ccc;
}

blockquote {
margin:0;
padding:5px 15px 5px 15px;
background:#f6f6f6;
}

a {
color:#333;
border-bottom:1px solid #ccc;
text-decoration:none;
}

a:hover {
border-bottom:1px solid #999;
}

#footer {
padding:10px;
border-top:2px solid #f6f6f6;
text-align:center;
margin:20px 0 0 0;
}

5 リモート・アプリケーション・サーバーへのSite Studioプロジェクトのデプロイ

Site Studioプロジェクトは、リモート・アプリケーション・サーバーにバンドルしてデプロイできます。バンドルされたSite Studioプロジェクトは、JDeveloperを使用するか手動でリモートのWebLogicアプリケーション・サーバーやWebSphereアプリケーション・サーバーにデプロイできます。

このトピックでは、WebプロジェクトWARアーカイブおよびアプリケーションEARアーカイブを作成して、それらのアーカイブをリモートのWebLogicアプリケーション・サーバーやWebSphereアプリケーション・サーバーにデプロイする手順を説明します。

注意:
前提条件として、WebSphereアプリケーション・サーバーにデプロイする場合はSite Studioテクノロジを含むSite Studioプロジェクトが必要です。また、WebSphereアプリケーション・サーバーにデプロイする場合はADFライブラリとWebアプリケーション・サポートが必要です。Site Studioプロジェクトを新規作成する方法および必要なテクノロジを既存のプロジェクトに関連付ける方法については、第4.1項「Site Studioプロジェクトおよび接続の作成」またはオンライン・ヘルプのSite Studioプロジェクトの作成に関する項を参照してください。

この項の内容は次のとおりです。

- 第5.1項「アプリケーション・サーバー接続の作成」

- 第5.2項「WebプロジェクトWARおよびアプリケーションEARデプロイメント・プロファイルの作成」

- 第5.3項「JDeveloperによるプロジェクトのデプロイ」

- 第5.4項「手動によるプロジェクトのデプロイ」

- 第5.5項「WAR/EARアーカイブの接続情報の編集」

5.1 アプリケーション・サーバーの接続の作成

この項では、アプリケーション・サーバー接続を作成する手順について説明します。

1. メイン・メニューで「ファイル」→「新規」を選択します。

2. 「新規ギャラリ」ダイアログで「一般」l→「接続」を選択します。

3. 「アプリケーション・サーバー接続」を選択し、「OK」をクリックします。

4. アプリケーション・サーバー接続の作成ウィザードを使用して、リモート・アプリケーション・サーバーへの接続を作成します。

- 名前とタイプ・ステップで、接続名を指定し、接続タイプとしてWebLogic 10.3かWebSphere 7.xを選択します。

- 認証ステップで、管理者レベルのユーザー名とパスワードを指定します。

- WebLogicの構成ステップでは、WebLogicリモート・サーバーのホスト名とポートを指定し、WebLogicサーバーが管理権限のないサーバー・ノードを名前で識別するように構成されている場合はWebLogicドメイン名を指定します。インストール時のデフォルトでは、WebLogicサーバーは、myserverという1つのバックエンド・ノードと、ポート番号7001のリスニング・ポートで構成されており、このダイアログでもこれらがデフォルト値です。

- WebSphereの構成ステップでは、ホスト名、SOAP接続ポート、サーバー名(デフォルトはSSXA_server1)、ターゲット・ノード、およびターゲット・セルを指定します。WS管理スクリプト・ファイルの場所には、WebSphereローカル・アプリケーション・サーバー上のwsadmin.shファイルへのパスを入力するか、「参照」をクリックしてwsadmin.shファイルまでナビゲートします。例: /WebSphere/AppServer/bin/wsadmin.sh

- テスト・ステップで、「接続のテスト」をクリックして、指定された情報によりアプリケーション・サーバーとの接続が確立されるかどうか確認します。テストがうまく行ったら「終了」をクリックします。

5.2 WebプロジェクトWARおよびアプリケーションEARデプロイメント・プロファイルの作成

この項では、WebプロジェクトWARデプロイメント・プロファイルとアプリケーションEARデプロイメント・プロファイルを作成する手順を説明します。

WebプロジェクトWARデプロイメント・プロファイルを作成する手順は次のとおりです。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. 「アプリケーション・ナビゲータ」で、「プロジェクト」パネルを選択します。

3. Site Studioプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。

4. 「プロジェクト・プロパティ」ダイアログで次の操作を実行します。

- 「デプロイメント」を選択します。

- ユーザーの構成により、プロジェクト設定を使用デフォルト・オプションを受け入れるか、「カスタム設定の使用」を選択します。

- 「新規」をクリックします。

5. 「デプロイメント・プロファイルの作成」ダイアログで次の操作を実行します。

- 「アーカイブ・タイプ」にはリストから「WARファイル」を選択します。これでJava EE Webモジュール(WAR)をアプリケーション・サーバーにデプロイするためのプロファイルが作成されます。WARはWebコンポーネント(JSPおよびサーブレット)とデプロイメント・ディスクリプタで構成されます。

- 「名前」には、デプロイメント・プロファイルの説明的な名前を指定します。この名前は、アプリケーションまたはプロジェクトのデプロイ時に、このデプロイメント・プロファイルの識別に使用されます。

- 「OK」をクリックします。

6. 「WARデプロイメント・プロファイルのプロパティの編集」ダイアログで次の操作を実行します。

- 「プラットフォーム」を選択します。

- 「デフォルト・プラットフォーム」には、「WebLogic 10.3」または「WebSphere 7.x」を選択します。

- 「ターゲット接続」でデフォルトの「<none>」を受け入れます。これによりプロジェクトをデプロイするときに接続を選択できます。

- 「OK」をクリックします。

7. 「プロジェクト・プロパティ」ダイアログで次の操作を実行します。

- 新しいWARアーカイブがデプロイメント・プロファイル・リストに表示されます。

- 「OK」をクリックします。

8. メイン・メニューで「ファイル」→「すべて保存」を選択します。

アプリケーションEARデプロイメント・プロファイルを作成する手順は次のとおりです。

1. メイン・メニューで「アプリケーション」→「アプリケーション・プロパティ」を選択します。

2. 「アプリケーション・プロパティ」ダイアログで次の操作を実行します。

- 「デプロイメント」を選択します。

- ユーザーの構成により、プロジェクト設定を使用デフォルト・オプションを受け入れるか、「カスタム設定の使用」を選択します。

- 「新規」をクリックします。

3. 「デプロイメント・プロファイルの作成」ダイアログで次の操作を実行します。

- 「アーカイブ・タイプ」にはリストから「EARファイル」を選択します。これでJava EEエンタープライズ・アーカイブ(EAR)ファイルをアプリケーション・サーバーにデプロイするためのプロファイルが作成されます。EARファイルは、アプリケーションのアセンブルされたWARファイル、EJB JARファイルおよびクライアントJARファイルで構成されます。

- 「名前」には、デプロイメント・プロファイルの名前を指定します。この名前は、アプリケーションまたはプロジェクトのデプロイ時に、このデプロイメント・プロファイルの識別に使用されます。

- 「OK」をクリックします。

4. 「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで次の操作を実行します。

- 「アプリケーション・アセンブリ」を選択します。

- 「Java EEモジュール」では、作成したWebプロジェクト・アーカイブ(WARファイル)のチェック・ボックスをオンにします。

- 「プラットフォーム」を選択します。

- 「デフォルト・プラットフォーム」には、「WebLogic 10.3」または「WebSphere 7.x」を選択します。

- 「ターゲット接続」でデフォルトの「<none>」を受け入れます。これによりプロジェクトをデプロイするときに接続を選択できます。

- 「OK」をクリックします。

5. 「アプリケーション・プロパティ」ダイアログで次の操作を実行します。

- 新しいEARアーカイブがデプロイメント・プロファイル・リストに表示されます。

- 「OK」をクリックします。

6. メイン・メニューで「ファイル」→「すべて保存」を選択します。

5.3 JDeveloperによるプロジェクトのデプロイ

JDeveloperを使用してプロジェクトをデプロイするには、WebプロジェクトWARデプロイメント・プロファイルとアプリケーションEARデプロイメント・プロファイルを作成する必要があります。

リモート・サーバーにアーカイブをデプロイする手順は次のとおりです。

1. メイン・メニューから「アプリケーション」→「デプロイ」を選択してから、作成したデプロイメント・プロファイルを選択します。

2. デプロイメント・アクション・ステップで、「アプリケーション・サーバーへのデプロイ」を選択します。

3. 「次」をクリックします。

4. サーバーの選択ステップで、作成したアプリケーション・サーバー接続を選択します。

5. 「次」をクリックします。

6. デプロイメント・サマリーを確認して「終了」をクリックします。

これでリモート・アプリケーション・サーバーにサイトがデプロイされます。

サイトにアクセスするリンクの例は、次のとおりです。http://192.0.2.200:7001/4235-4235Project-context-root/4235site/index.html

注意: アプリケーション・サーバーが正しく設定され、適切なライブラリがインストールされている必要があります。

5.4 プロジェクトの手動デプロイ

プロジェクトを手動でデプロイするには、WebプロジェクトWARデプロイメント・プロファイルとアプリケーションEARデプロイメント・プロファイルを作成する必要があります。

アーカイブをデスクトップに出力する手順は次のとおりです。

1. メイン・メニューから「アプリケーション」→「デプロイ」を選択してから、作成したデプロイメント・プロファイルを選択します。

2. デプロイメント・アクション・ステップで、「EARにデプロイ」を選択します。

3. 「次」をクリックします。

4. デプロイメント・サマリーを確認して、出力ファイルの場所をメモします。

5. 「終了」をクリックします。

6. 出力ファイル・ディレクトリからEARを取得します。

これでプロジェクトはリモート・アプリケーション・サーバーに移動できます。アプリケーションEARアーカイブ(WebプロジェクトWARアーカイブはアプリケーションEARアーカイブに含まれる)をWebLogicリモート・アプリケーション・サーバーに手動で転送し、WebLogic管理コンソールを使用してEARアーカイブをデプロイします。

5.5 WAR/EARアーカイブの接続情報の編集

このトピックでは、デプロイ用にバンドルされたSite Studioプロジェクトおよびリモート・アプリケーション・サーバーにデプロイされたSite Studioプロジェクトの接続情報を編集する手順について説明します。接続情報は3つの方法を使用して手動で編集できます。1つはアプリケーションEARおよびWebプロジェクトWARアーカイブに含まれるconnections.xmlおよびwcm-config.xmlファイルを編集する方法です。2つ目は更新された接続情報を含む新しいファイルを使用して前の接続情報を上書きする方法です。3つ目はアプリケーション・サーバーにデプロイされたプロジェクト・ファイルを編集する方法です。

デプロイ用にバンドルされたSite Studioプロジェクトは、WebプロジェクトWARアーカイブを含むアプリケーションEARアーカイブで構成されます。EARアーカイブには、接続情報を提供するconnections.xmlファイルが含まれます。WARアーカイブには、connections.xml内の特定の接続を参照するwcm-config.xmlファイルが含まれます。接続情報を編集するには、connections.xmlファイル内の3つの接続エントリを編集し、オプションでwcm-config.xmlファイル内の1つのエントリを編集する必要があります。

- connections.xmlファイルには通常、複数の接続エントリが含まれます。それぞれの接続エントリで、connectionURLおよびidcServerURLの値と参照名を編集する必要があります。これらの値はリストされたそれぞれの接続の接続情報を提供します。

- wcm-config.xmlファイルはconnections.xmlファイル内の特定の接続を参照します。connectionNameエントリは、オプションで編集を必要とする唯一の値です。これはプロジェクトに使用する接続です。この値を変更して、connections.xmlファイルにリストされた接続から別の接続を選択できます。

この項の内容は次のとおりです。

- 第5.5.1項「接続情報の手動での編集」

- 第5.5.2項「接続情報の手動での上書き」

- 第5.5.3項「アプリケーション・サーバー上にデプロイされたファイルの編集」

5.5.1 接続情報の手動での編集

Site Studioプロジェクトの接続情報は、アプリケーションEARアーカイブの中のconnections.xmlファイル(およびオプションでWebプロジェクトのWARアーカイブの中のwcm-config.xmlファイル)を手動で編集することによって変更できます。この方法は通常、編集を必要とする接続エントリの数が非常に少ないときに使用されます。多数の接続エントリを編集する必要がある場合は、正しい接続エントリが指定されたファイルでconnections.xmlファイルを上書きすることをお薦めします。

EARアーカイブをアンバンドルする手順は次のとおりです。

リモート・アプリケーション・サーバー用に出力するSite Studioプロジェクト(アプリケーションEARアーカイブ)を見つけてEARアーカイブをアンバンドルします。

EARアーカイブの構造は次のとおりです。

yourapplication.ear
|- adf
|- META-INF
|- adf-config.xml
|- connections.xml
|- lib
|- META-INF
|- yourwebproject.war

connections.xmlファイルを編集する手順は、次のとおりです。

1. アンバンドルされたEARアーカイブで、/adf/META-INF/ディレクトリ内のconnections.xmlファイルを見つけます。

2. テキスト専用のエディタでconnections.xmlファイルを開きます。connections.xmlファイルには通常、複数の接続エントリが含まれます。これらの接続エントリのそれぞれで参照名、connectionURLおよびidcServerURLの値を編集する必要があります。これらの値はリストされたそれぞれの接続の接続情報を提供します。

3. 対象となる接続について、参照名の値を編集します。
たとえば、以下に:

<Reference name="productionserver7" className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns="">

新しい値を指定します:

<Reference name="server4" className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns="">

4. 接続のconnectionURL値を編集します。
たとえば、以下に:

<StringRefAddr addrType="oracle.stellent.idc.connectionUrl">
<Contents>idc://productionserver7.yourcompany.com:4444</Contents>
</StringRefAddr>

新しい値を指定します:

<StringRefAddr addrType="oracle.stellent.idc.connectionUrl">
<Contents>idc://server4.yourcompany.com:4444</Contents>
</StringRefAddr>

5. 接続のidcServerURL値を編集します。
たとえば、以下に:

<StringRefAddr addrType="oracle.stellent.idc.idcServerURL">
<Contents>http://productionserver7.yourcompany.com:16200/cs/idcplg</Contents>
</StringRefAddr>

新しい値を指定します:

<StringRefAddr addrType="oracle.stellent.idc.idcServerURL">
<Contents>http://server4.yourcompany.com:16200/cs/idcplg</Contents>
</StringRefAddr>

6. connections.xmlファイル内のその他の接続に対してこれらの手順を必要なだけ繰り返します。

7. connections.xmlファイルを保存します。

WARアーカイブをアンバンドルする手順は次のとおりです。

アンバンドルされたアプリケーションEARアーカイブで、WebプロジェクトWARアーカイブを見つけて、それをアンバンドルします。

WARアーカイブの構造は次のとおりです。

yourwebproject.war
|- wcm
|- WEB-INF
|- sites
|- tags
|- wcm-config.xml
|- web.xml
|- weblogic.xml

wcm-config.xmlファイルを編集する手順は、次のとおりです。

1. WARアーカイブをアンバンドルするには、/WEB-INF/ディレクトリ内でwcm-config.xmlファイルを見つけます。

2. テキスト専用エディタでwcm-config.xmlを開きます。connectionNameエントリは、オプションで編集を必要とする唯一の値です。これはプロジェクトに使用する接続です。この値を変更して、connections.xmlファイルにリストされた接続から別の接続を選択できます。

3. コンテンツ・サーバーのconnectionName値を希望どおりに編集します。
たとえば、以下に:

<contentServer pollerInterval="10000" enablePoller="true" connectionName="productionserver7" adminUser="sysadmin"/>

新しい値を指定します:

<contentServer pollerInterval="10000" enablePoller="true" connectionName="server4" adminUser="sysadmin"/>

4. wcm-config.xmlファイルを保存します。

WARおよびEARアーカイブを再度バンドルする手順は次のとおりです。

1. アンバンドルされたアプリケーションEARアーカイブで、アンバンドルされたWebプロジェクトWARアーカイブを見つけます。

2. WARアーカイブを再バンドルします。

3. 完全なEARアーカイブ(再バンドルされたWARアーカイブを含む)を再バンドルします。

4. Site Studioプロジェクトを再デプロイします。

5.5.2 接続情報の手動での上書き

バンドルされたSite Studioプロジェクトの接続情報は、新しいファイルでconnections.xmlファイルを上書きすることにより手動で変更できます。この方法は多数の接続エントリを変更する必要があるときに一般的に使用されます。少数の接続エントリを編集するときには、connections.xmlファイルを直接編集することをお薦めします。詳細は、第5.5.1項「接続情報の手動での編集」を参照してください。

1. JDeveloperを使用して新しい(空の) Site Studioプロジェクトを作成します。

2. 接続情報を定義します。

3. 新しいWebプロジェクトWARアーカイブとアプリケーションEARアーカイブを作成します。

4. アーカイブを出力します。

5. 新しいプロジェクトEARアーカイブからconnections.xmlファイルを抽出します。
connections.xmlファイルは、アンバンドルされたEARアーカイブの/adf/META-INF/ディレクトリにあります。

6. 新しいconnections.xmlファイルをコピーして古いEARアーカイブの中の古いXMLファイルを上書きします。

7. アプリケーションEARアーカイブをリモート・アプリケーション・サーバーに手動で転送します。

8. アプリケーション・サーバー管理コンソールを使用して、新しい接続情報で更新されたEARアーカイブを再デプロイします。

5.5.3 アプリケーション・サーバー上にデプロイされたファイルの編集

アプリケーション・サーバーにデプロイした後に接続情報を編集するには、アプリケーション・サーバー上にデプロイされたプロジェクト・ファイルを編集します。デプロイ後のプロジェクト・ファイルは、デプロイ可能ユニットの一部となり、デプロイ前のEARおよびWARアーカイブにはバンドルされていません。接続情報を編集するには、デプロイ可能ユニットの中のconnections.xmlファイルとwcm-config.xmlファイルを見つけて、それをアプリケーション・サーバー上で編集する必要があります。

WebLogic管理コンソールを使用して、実行中のWebLogicアプリケーション・サーバー上でデプロイされたSite Studioプロジェクト・ファイルを見つけて編集する手順は次のとおりです。それ以外のアプリケーション・サーバー上であっても、デプロイ可能ユニットでconnections.xmlファイルおよびwcm-config.xmlファイルを見つけて編集する手順は類似しています。アンバンドルされたファイルを見つける方法は、それぞれのアプリケーション・サーバー管理ガイドを参照してください。

1. Oracle WebLogic管理コンソールを起動します。

2. 「ドメイン構造」から「デプロイメント」を選択します。

3. 「デプロイメントのサマリー」から「コントロール」タブを選択します。

4. 編集対象のデプロイされたSite Studioプロジェクトのリンクをクリックします(例: mySiteStudioProject)。

5. 「設定」から「概要」タブを選択します。

6. Path値に管理サーバー上のデプロイ可能ユニットのソースへのパスが表示されます。
注意: ソース・パスが相対パスの場合は、InstallDirがヌルでなければInstallDir/appに対する相対パスです。そうでない場合は、ドメイン・ルートに対する相対パスです。

例:

\JDeveloper\mywork\mySiteStudioProject\

7. connections.xmlファイルと(オプションで) wcm-config.xmlファイルを手動で編集します。
注意: これらのファイルはデプロイ可能ユニットの一部です。つまり、これらはデプロイ前のEARおよびWARアーカイブにはバンドルされていません。

- connections.xmlファイルは、/.adf/META-INF/サブディレクトリにあります。

- wcm-config.xmlファイルは/WEB-INF/サブディレクトリにあります。

8. 変更は更新されたSite Studioプロジェクトを再起動した後に有効になります。

6 Site Studioアプリケーション・コンポーネントおよびテクノロジ

この項の内容は次のとおりです。

- 第6.1項「Site Studioアプリケーション・コンポーネント」

- 第6.2項「Site Studioテクノロジ」

- 第6.3項「Site Studioテクノロジの統合での使用」

6.1 Site Studioアプリケーション・コンポーネント

Site Studioアプリケーションは、Site Studio Webサイトを配布する複数のWARファイルを含むEARファイルです。

JavaEE EARファイル

この項に示す例では、MySitesというWebプロジェクトを持つMyApplicationというSite Studioアプリケーションが使用されます。EARファイルの構造は次のとおりです。

+-- MyApplication.ear
+-- MySites.war
+-- adf/META-INF/
+-- connections.xml
+-- META-INF/
+-- application.xml
+-- weblogic-application.xml

MySites.war: これは単一のコンテンツ・サーバーを参照し、そのコンテンツ・サーバーからサイトを配信するwarファイルです(「JavaEE WARファイル」を参照)。

adf/META-INF/connections.xml: ランタイムに問合せが実行されたコンテンツ・サーバーの定義を保持するADF接続ファイルです。

META-INF/weblogic-application.xml: Site Studio (およびRIDC)共有EARライブラリへの参照を保持するWeblogic固有のアプリケーション／ファイルです。

JavaEE WARファイル

Site Studio WebサイトはWARファイルを介して配信されます。Site Studioライブラリは、WARファイル当たり1つのOracle WebCenterコンテンツ・サーバー・インスタンスと通信できます。WARファイルの構造は次のとおりです。

+-- MySites.war
+-- wcm/templates/
+-- WEB-INF/
+-- web.xml
+-- wcm-config.xml
+-- weblogic.xml

wcm/templates: wcm-config.xmlファイルに登録されたすべてのローカル・テンプレート(JSP/JSPXファイル)を含むディレクトリです。

WEB-INF/wcm-config.xml: 使用可能なサイト、接続名、およびその他の構成設定がリストされた主要なSite Studio構成ファイルです。

WEB-INF/weblogic.xml: 共有Site Studio WARライブラリへの参照を保持するWeblogic固有のファイルです。

WEB-INF/web.xml: アプリケーションのサーブレット、フィルタ、セキュリティ設定がリストされた標準のJavaEE構成ファイルです。

6.2 Site Studioテクノロジ

Site Studioテクノロジは、サーブレット、フィルタ、タグ・ライブラリを使用して、デプロイ済のWebアプリケーションを介してSite Studioサイトを配信します。

この項では、サイトID MySiteを持ち、MyApplicationという名のSite Studioアプリケーションを介して配信される単一Site Studioサイトのデフォルト構成の例を示します。

- 第6.2.1項「Site Studioサーブレット」

- 第6.2.2項「Site Studioフィルタ」

6.2.1 Site Studioサーブレット

使用可能なSite Studioサーブレットは次のとおりです。

- SiteStudioプロキシ・サーブレット: Oracle WebCenterコンテンツ・サーバーのコンテンツのプロキシをローカル・アプリケーションに提供します。これにより、コンテンツ・サーバーはドメイン内のローカル・リソースとして取り扱われ、IDの伝播を介してシングル・サインオンが可能になります。

- 初期化サーブレット: Site Studioライブラリを初期化します。Webリクエストを処理することはありません。

6.2.2 Site Studioフィルタ

使用可能なSite Studioフィルタは次のとおりです。

- モード・フィルタ: 現在のリクエストのモードを判断します。モードは、Consumption、ContributionまたはDesignです。

- サイト・フィルタ: Oracle WebCenterコンテンツ・サーバー内の関連するプロジェクトに基づき、Site Studio URL講文を使用してSite Studio Webページを配信します。

- プロキシ・フィルタ: コンテンツ・サーバーのコンテンツの代用を提供して、コンテンツ・サーバーのUIをローカルWebアプリケーションから操作できるようにします。

モード・フィルタ

モード・フィルタは、コントリビューション・モードのルート(/wcm-contrib/*)または設計モードのルート(/wcm-design/*)をマップするURLをリッスンします。URLの最初のセグメントがこれらのURLのいずれかと一致する場合には、モードがリクエストに設定され、リソースが処理のために最初のセグメントなしにWebアプリケーションに転送されます。

サイト・フィルタ

サイト・フィルタは、Site Studio URLの処理を可能にします。Site Studio URLはプロジェクト・ファイルの構造に基づく階層構造です。Site Studio URLの典型的な例は、/mysite/about/index.htmlです。詳細は、第1.6項「サイトURLフォーマットの理解」を参照してください。

Site Studio制御フロー

1. ブラウザからサイトURLがリクエストされました: /mysite/about/index.html

2. 現在のサイトIDとセクションを特定します。

- wcm-config.xmlファイルでurlPathを照合します。

- サイトIDはmysiteに設定され、サイト・パスは/about/index.htmlに設定されます。

3. 新しいSiteContextオブジェクトをインスタンス化して、それをwcmContextという名の属性としてHttpServletRequestに置きます。

4. ページ・テンプレートIDを特定します。この場合、ページ・テンプレートはindex.htmlファイル名を介してプライマリです。

5. wcm-config.xmlファイルでテンプレートIDを探して、ローカルのJSP/JSPXリソースを見つけます。

6. RequestDispatcherを起動して、関連するJSP/JSPXページを含め、レンダリングします。

プロキシ・フィルタ

プロキシ・フィルタは、ローカル・ユーザーIDを使用してコンテンツ・サーバーのコンテンツのプロキシを提供して、Oracle WebCenterコンテンツ・サーバーのUIをローカルWebアプリケーションから操作できるようにします。これによりWebアプリケーションをSite Studioコントリビュータおよびコンテンツ・サーバー・ドメイン内にあるOracle WebCenterコンテンツ・サーバーのユーザー・インタフェース・ページに統合できます。

6.3 Site Studioテクノロジの統合での使用

この項では、他のテクノロジおよびフレームワークとの統合により外部アプリケーションでWebコンテンツ管理機能を提供する様々なSite Studioテクノロジに関する注意点を述べます。

Site Studioタグ・ライブラリ、Site Studioヘルパー・メソッド、および様々なSite Studioフィルタを含むSite Studioテクノロジおよびサーブレットは、他のテクノロジおよびフレームワークと統合してWebコンテンツ管理機能を外部アプリケーションに提供できます。

リンクの使用

外部から管理されたページまたはアプリケーションでプレースホルダ・タグを使用するときには、データ・ファイル内またはリージョン・テンプレートによって作成されたリンクの妥当性についてはすべてユーザーが責任を持ちます。標準のSite Studioセクションおよびコンテンツのリンクは、管理対象外のサイトやアプリケーションには適していません。

Site Studioタグの使用

Context、Datafile、およびTemplateタグは、Placeholderタグと組み合せて使用され、外部から管理されたアプリケーションで使用できます。

詳細は、第7.1項「Site Studioタグ・ライブラリ」を参照してください。

Site Studioヘルパー・メソッドの使用

Site Studioヘルパー・メソッドを使用してテンプレートを作成できます。

詳細は、第7.2項「Site Studioヘルパー・メソッド」を参照してください。

その他のテクノロジおよびフレームワークとの統合

Site Studioタグは他のテクノロジと統合できますが、統合で使用するときには、すべてのURL管理はアプリケーションまたはアプリケーション・サーバーが処理する必要があります。Site Studioはアプリケーション構造の管理、URLマッピングまたはページ・テンプレートの作成を実行しません。

Site Studioコンテンツは、静的プレースホルダかページやアプリケーションへの動的プレースホルダを追加することにより他のコンポーネントと組み合せることができます。

- 静的プレースホルダとは、明示的に割り当てられたdDocName (コンテンツID)を持つプレースホルダです。つまり、静的プレースホルダは設計時にバックアップ・データ・ファイル(およびオプションでリージョン表示テンプレート)と関連付けられます。

- 動的プレースホルダは、バックアップ・データ・ファイルdDocName (およびオプションでリージョン・テンプレート)をプロジェクト・ファイル内に格納するプレースホルダです。動的プレースホルダは、コントリビューション・プロセスの一部であるリージョン・コンテンツの切り替え機能を使用してビジネス・ユーザーによりバックアップ・データ・ファイルと関連付けられます。コンテンツの切り替えアクションがコンテンツの切り替えウィザードによって生成された値を書き込むプロジェクト・ファイル内の場所を定義するためにコンテキスト・タグを指定する必要があります。

7 Site Studioタグ・ライブラリおよびヘルパー・メソッド

この項ではSite Studioタグ・ライブラリおよびヘルパー・メソッドについて説明します。この項の内容は、次のとおりです。

- 第7.1項「Site Studioタグ・ライブラリ」

- 第7.2項「Site Studioヘルパー・メソッド」

注意:
Site Studioタグおよびヘルパー・メソッドはSite Studioの各リリースごとに変更される可能性があります。タグ・ライブラリ・サービス・キャッシングの詳細は、第1.9項「Site Studioタグ・ライブラリを使用したサービス・キャッシュの理解」を参照してください。

7.1 Site Studioタグ・ライブラリ

このトピックでは、Site Studioタグ・ライブラリに関する情報を示し、各タブについて個別に説明します。

- Site Studioタグの説明

- Site Studio <wcm:context>タグ

- Site Studio <wcm:dataFile>タグ

- Site Studio <wcm:dynamicConversion>タグ

- Site Studio <wcm:dynamicList>タグ

- Site Studio <wcm:idcParameter>タグ

- Site Studio <wcm:idcService>タグ

- Site Studio <wcm:metadata>タグ

- Site Studio <wcm:placeholder>タグ

- Site Studio <wcm:staticPlaceholder>タグ

- Site Studio <wcm:url>タグ

7.1.1 Site Studioタグの説明

この項では、Site Studioの各タグとその簡単な説明を示します。追加の詳細は、それぞれのタグの項を参照してください。

タグ

説明

wcm:context

ContextタグはSiteContextオブジェクトを新規作成し、それを現在のHttpServletRequest上に設定します。これにより既存のSiteContextが置き換えられます。これ以降のSite Studio APIまたはタグへのコールでは、このコンテキストが使用されます。

wcm:dataFile

データファイル・タグはコンテンツ・サーバーからコンテンツをロードして、DataFileオブジェクトへと解析します。オブジェクトは次に、式言語(EL)によってデータファイルの個々のコンポーネントへのアクセスに使用される変数として公開されます。

wcm:dynamicConversion

動的変換タグは、ネイティブ・ドキュメントの動的変換を作成するときに使用される変換ルールを指定するために使用されます。

wcm:dynamicList

動的リスト・タグは、リージョン定義内の指定された動的リスト要素から問合せを実行し、その結果をvar変数に入れます。

wcm:idcParameter

Idcパラメータ・タグは、Idcサービス・タグと組み合せて使用され、コンテンツ・サーバー上でIDCサービス・コールを実行します。名前と値のペアを取ります。

wcm:idcService

Idcサービス・タグは、Idcパラメータ・タグと組み合せて使用され、コンテンツ・サーバー上でIDCサービス・コールを実行します。

wcm:metadata

メタデータ・タグは、コンテンツ・アイテム用のDOC_INFOサービス・コールを実行し、結果としてのDataBinderにコンテンツ・アイテムに関する情報を含めます。

wcm:placeholder

プレースホルダ・タグは、テンプレート内のどアイテムを挿入する場所を指定するために使用されます。これは通常はコンテンツですが、ナビゲーション、コード、サブテンプレートなども可能です。

wcm:staticPlaceholder

静的プレースホルダ・タグは、固定データファイルにプレースホルダを追加するために使用できます。これはヘッダーやフッターなど、変更されないコンテンツに便利です。

wcm:url

URLタグは、サイト構造への階層リンクか、コンテンツ・サーバーのコンテンツへのリンクか、どちらかをレンダリングします。

7.1.2 Site Studio <wcm:context>タグ

コンテンツ・タグは、SiteContextオブジェクトを新規作成し、それを現在のHttpServletRequest上に設定します。これにより既存のSiteContextが置き換えられます。これ以降のSite Studio APIまたはタグへのコールでは、このコンテキストが使用されます。

コンテンツが現在のパスから初期化されていない場合(initFromPathがfalseか、指定されていない)、新規のSiteContextは既存のSiteContext(がある場合)と同じサイトIDと同じURLを持ちます。

パラメータ

- siteID: サイトID。必須です。

- url: サイト・パス。これはサイトIDを差し引いたパスの一部です(例: /about/index.html)。必須です。

- initFromPath: 現在のHttpServletRequestからのコンテキストを初期化するにはtrueに設定します(urlパラメータは無視されます)。

例

サイトID "mysite"のバージョン情報セクションのプライマリ・ページへの新しいコンテキストを初期化します。

<wcm:context siteID="mysite" url="/about/index.html" />

サイトIDを指定せずに、新しいURLへの現在のSiteContextをリセットします。

<wcm:context url="/index.html" />

7.1.3 Site Studio <wcm:dataFile>タグ

データファイル・タグはコンテンツ・サーバーからコンテンツをロードして、DataFileオブジェクトへと解析します。オブジェクトは次に、式言語(EL)によってデータファイルの個々のコンポーネントへのアクセスに使用される変数として公開されます。wcm:dataFileタグは通常、リージョン・テンプレート上で使用され、割り当てられたDataFileを表示するためにロードします。

DataFileオブジェクトはマップ・インタフェースを実装し、すべてのメンバーに要素名によるアクセスを許可します。次の2種類の要素を取得できます。

- TextElement: テキスト・コンテンツ。

- ListElement: 静的リスト・コンテンツ。ListElementはListインタフェースを実装します。リストの各メンバーはTextElementsのマップです。

パラメータ

- var: 結果としてのDataFileオブジェクトの変数名です。必須です。

- dataFile: データファイルのコンテンツIDです。省略すると、wcm:placeholderタグ内からコールされた場合に、現在のプレースホルダに割り当てられているIDが使用されます。オプションです。

例

コンテンツIDがAWARDSのデータファイルの例を以下に示します。

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="http://www.stellent.com/wcm-data/ns/8.0.0" version="8.0.0.0">
<element name="title">Awards</wcm:element>
<list name="list">
<row>
<element name="name">2007 Outstanding Organization Award</element>
</row>
<row>
<element name="name">2006 Top 50 Company</element>
</row>
</list>
</root

割り当てられたデータファイルをリージョン・テンプレートからロードします。

<wcm:dataFile var="dataFile" />

あるいは、コンテンツIDを指定してデータファイルをロードします。

<wcm:dataFile var="dataFile" contentID="" />

HTMLにデータをモデリングします。

<h2>${title}</h2>
<ul>
<c:forEach var="row" items="${dataFile.list}">
<li>${row.name}</li>
</c:forEach>
</ul>

7.1.4 Site Studio <wcm:dynamicConversion>タグ

動的変換タグは、ネイティブ・ドキュメントの動的変換を作成するときに使用される変換ルールを指定するために使用されます。

パラメータ

- rule: ConversionsDefinitionファイルに定義された動的変換ルールの名前。必須です。
「表示」→「プロパティ・インスペクタ」→「ルール」→「編集」を選択して動的変換タグのルールを選択できます。ルールが選択されない場合はデフォルトのルールが使用されます。

- page: 表示するページの番号。オプションです。

- var: 動的変換の出力を割り当てる変数。省略すると、変換後の出力はページに直接書き込まれます。オプションです。

- dataFile: 変換対象アイテムのdDocName (コンテンツID)。省略すると、現在のプレースホルダに割り当てられたデータファイルが使用されます。オプションです。

例

ルールruleNameを使用して現在のデータファイルを変換します。

<wcm:dynamicConversion rule="ruleName" />

ルールruleNameを使用してデータファイルMY_WORD_DOCを変換します。

<wcm:dynamiConversion dataFile="MY_WORD_DOC" rule="ruleName" />

7.1.5 Site Studio <wcm:dynamicList>タグ

動的リスト・タグは、リージョン定義内の指定された動的リスト要素から問合せを実行し、その結果をvar変数に入れます。

パラメータ

- element: リスト要素の構築に使用されたリスト内の要素の名前。必須です。

- var: 動的リスト変数。必須です。

- dataFile: この動的リストをレンダリングするプレースホルダに割り当てられたデータファイル。オプションです。

- placeholder: この動的リストをレンダリングするプレースホルダの名前。オプションです。

例

リージョン・テンプレート内で割り当てられたデータファイルを使用する問合せです。

<wcm:dynamicList element="example" var="example"/>

結果をモデリングします。

<ul>
<c:forEach var="row" items="${example.resultSets.SearchResults.rows}">
<li>${row.dDocName} - ${row.dDocTitle}</li>
</c:forEach>
</ul>

7.1.6 Site Studio <wcm:idcParameter>タグ

Idcパラメータ・タグは、Idcサービス・タグと組み合せて使用され、コンテンツ・サーバー上でIDCサービス・コールを実行します。名前と値のペアを取ります。

重要: パラメータはコールされたサービスにより異なります。サービス・コールとパラメータの詳細は、『Oracle WebCenter Contentサービス・リファレンス・ガイド』を参照してください。

パラメータ

- name: IDCパラメータ。コンテンツ・サーバー上のIDCサービス・コールのパラメータを入力します。Site Studio IdcServiceタグを使用して、コンテンツ・サーバー上で実行するIDCサービス・コールを定義します。必須です。

- value: Idcパラメータ変数。このパラメータに有効な値を入力します。必須です。

- file: trueの場合、値パラメータはパス(ローカル・ファイル・パスまたはこのWebアプリケーション内での相対ファイル・パス)を指定し、ファイル・オブジェクトとしてDataBinderに追加されます。オプションです。

例

この例では、Idcサービス・タグとIdcパラメータ・タグの両方が使用されます。この例では、CHECKIN_UNIVERSALサービスがコールされ、サービスのパラメータは名前と値のペアを使用して定義されます。

- doFileCopyパラメータはTRUE (1)に設定されます。このため、チェック・インしたファイルはハード・ドライブから削除されません。

- dDocNameパラメータはコンテンツIDを定義します。

- dDocTitleパラメータはタイトルを定義します。

- dDocTypeパラメータはタイプを定義します。

- dSecurityGroupパラメータはセキュリティ・グループを定義します。

- dDocAuthorパラメータは作成者を定義します。

- primaryFileパラメータは、ファイルのオリジナル名とサーバーから見たファイルの場所への絶対パスを定義します。

<wcm:idcservice service="CHECKIN_UNIVERSAL" var="callStatus"
<wcm:idcparameter name="doFileCopy" value="1"/>
<wcm:idcparameter name="dDocName" value="RemoteTestCheckin23"/>
<wcm:idcparameter name="dDocTitle" value="Test1"/>
<wcm:idcparameter name="dDocType" value="ADACCT"/>
<wcm:idcparameter name="dSecurityGroup" value="Public"/>
<wcm:idcparameter name="dDocAuthor" value="sysadmin"/>
<wcm:idcparameter name="primaryFile" value="C:/inetpub/Scripts/query2.asp"/>
/>

この例はサービス・コールからデータを取り戻す方法を示します。

<wcm:idcService service="DOC_INFO_BY_NAME" var="docinfo">
<wcm:idcParameter name="dDocName" value="DATAFILE1234" />
<wcm:idcParameter name="RevisionSelectionMethod" value="LatestReleased" />
</wcm:idcService>
<c:forEach var="row" items="${docinfo.resultSets.DOC_INFO.rows}">
<p>The content item <em>${row.dDocName}</em> is a
<u>${row.xWebsiteObjectType}</u></p>
</c:forEach>

7.1.7 Site Studio <wcm:idcService>タグ

Idcサービス・タグは、Idcパラメータ・タグと組み合せて使用され、コンテンツ・サーバー上でIDCサービス・コールを実行します。

重要: パラメータはコールされたサービスにより異なります。サービス・コールとパラメータの詳細は、『Oracle WebCenter Contentサービス・リファレンス・ガイド』を参照してください。

パラメータ

- service: Idcサービス。コンテンツ・サーバー上で実行するIDCサービス・コールを入力します。サービス・コールはデータ・バインダを戻します。Site Studio IdcParameterタグを使用して、サービス・コールのパラメータを設定します。必須です。

- var: Idcサービス変数。コンテンツ・サーバーから返されるレスポンスの結果を格納する変数の名前を入力します。必須です。

- type: streamに設定すると、コンテンツ・サーバーからのレスポンスはInputStreamオブジェクトです。デフォルト設定のレスポンスはoracle.stellent.ridc.model.DataBinderです。オプションです。

例

この例では、Idcサービス・タグとIdcパラメータ・タグの両方が使用されます。この例では、CHECKIN_UNIVERSALサービスがコールされ、サービスのパラメータはフィールドと値のペアを使用して定義されます。

- doFileCopyパラメータはTRUE (1)に設定されます。このため、チェック・インしたファイルはハード・ドライブから削除されません。

- dDocNameパラメータはコンテンツIDを定義します。

- dDocTitleパラメータはタイトルを定義します。

- dDocTypeパラメータはタイプを定義します。

- dSecurityGroupパラメータはセキュリティ・グループを定義します。

- dDocAuthorパラメータは作成者を定義します。

- primaryFileパラメータは、ファイルのオリジナル名とサーバーから見たファイルの場所への絶対パスを定義します。

<wcm:idcservice service="CHECKIN_UNIVERSAL" var="callStatus"
<wcm:idcparameter name="doFileCopy" value="1"/>
<wcm:idcparameter name="dDocName" value="RemoteTestCheckin23"/>
<wcm:idcparameter name="dDocTitle" value="Test1"/>
<wcm:idcparameter name="dDocType" value="ADACCT"/>
<wcm:idcparameter name="dSecurityGroup" value="Public"/>
<wcm:idcparameter name="dDocAuthor" value="sysadmin"/>
<wcm:idcparameter name="primaryFile" value="C:/inetpub/Scripts/query2.asp"/>
/>

この例はサービス・コールからデータを取り戻す方法を示します。

<wcm:idcService service="DOC_INFO_BY_NAME" var="docinfo">
<wcm:idcParameter name="dDocName" value="DATAFILE1234" />
<wcm:idcParameter name="RevisionSelectionMethod" value="LatestReleased" />
</wcm:idcService>
<c:forEach var="row" items="${docinfo.resultSets.DOC_INFO.rows}">
<p>The content item <em>${row.dDocName}</em> is a
<u>${row.xWebsiteObjectType}</u></p>
</c:forEach>

7.1.8 Site Studio <wcm:metadata>タグ

メタデータ・タグは、コンテンツ・アイテム用のDOC_INFOサービス・コールを実行し、結果としてのDataBinderにコンテンツ・アイテムに関する情報を含めます。

パラメータ

- contentID: コンテンツID。必須です。

- var: メタデータ変数。必須です。

例

<wcm:metadata contentID="DATAFILE1234" var="metadata"/>
<c:forEach var="metadatarow" items="${metadata.resultSets.DOC_INFO.rows}">
<p>The content item <em>${metadatarow.dDocName}</em> is a
<u>${metadatarow.xWebsiteObjectType}</u></p>
</c:forEach>

固定IDでなく、リージョン・テンプレート上のデータファイルを使用することもできます。例を以下に示します。

<wcm:metadata contentID="${wcmContext.placeholder.dataFile}" var="meta"/>

7.1.9 Site Studio <wcm:placeholder>タグ

プレースホルダ・タグは、テンプレート内のどアイテムを挿入する場所を指定するために使用されます。これは通常はコンテンツですが、ナビゲーション、コード、サブテンプレートなども可能です。

パラメータ

- name: プレースホルダの名前。必須です。

- location: テンプレート上の場所。オプションです。

- definition: プレースホルダ定義へのマッピングを指定します。これにより他の方法で指定されたマッピングは無効になります。オプションです。

- template: データファイルのレンダリングに使用されるリージョン・テンプレート。オプションです。

- dataFile: このプレースホルダに割り当てるデータファイルのdDocName。オプションです。

- regionDefinition: データファイル上のxRegionDefinitionのかわりに使用するdDocNameリージョン定義。オプションです。

- actions: プレースホルダ定義の許可されたアクション。任意数のアクションを設定できます。一緒に使用できないパラメータ(たとえば、サブテンプレートとリージョン定義を同時に指定するなど)を使用する場合、タグは前述のパラメータの順序に基づいて実行します。オプションです。

- Update [E]: コントリビュータを更新します。

- Approve [A]: ワークフローを承認します。

- Reject [R]: ワークフローを拒否します。

- Document Information [I]: ドキュメント情報を表示します。

- Switch Data File [S]: データファイルを切り替えます。

- View Usage Report [U]: Web使用状況レポートを表示します。

- View tracker Report [T]: Web Trackerレポートを表示します。

- Update Document Information [M]: コンテンツ情報を更新します。

- Switch Region Template [V]: リージョン・テンプレートを切り替えます。

- Remove Content [N]: コントリビュータにコンテンツの削除を可能にします。

例

<wcm:placeholder name="yourplaceholdername" actions="E"/>
<wcm:placeholder name="yourplaceholdername" actions="EPRISUTMVN"/>

7.1.10 Site Studio <wcm:staticPlaceholder>タグ

静的プレースホルダ・タグは、固定データファイルにプレースホルダを追加するために使用できます。これはヘッダーやフッターなど、変更されないコンテンツに便利です。

パラメータ

- dataFile: この静的プレースホルダに割り当てるデータファイルのdDocName (コンテンツID)。必須です。

- name: 静的プレースホルダの名前。オプションです。

- template: データファイルのレンダリングに使用されるリージョン・テンプレート。オプションです。

- actions: プレースホルダ定義の許可されたアクション。任意数のアクションを設定できます。一緒に使用できないパラメータ(たとえば、サブテンプレートとリージョン定義を同時に指定するなど)を使用する場合、タグは前述のパラメータの順序に基づいて実行します。オプションです。

- Update [E]: コントリビュータを更新します。

- Approve [A]: ワークフローを承認します。

- Reject [R]: ワークフローを拒否します。

- Document Information [I]: ドキュメント情報を表示します。

- View Usage Report [U]: Web使用状況レポートを表示します。

- View tracker Report [T]: Web Trackerレポートを表示します。

- Update Document Information [M]: コンテンツ情報を更新します。

- Switch Region Template [V]: リージョン・テンプレートを切り替えます。

例

<wcm:staticPlaceholder datafile="yourdatafile" actions="E"/>
<wcm:staticPlaceholder datafile="yourdatafile" actions="EPRIUTMV"/>

7.1.11 Site Studio <wcm:url>タグ

URLタグは、サイト構造への階層リンクか、コンテンツ・サーバーのコンテンツへのリンクか、どちらかをレンダリングします。

パラメータ

- var: リンク結果を格納する変数名。

- type: リンクのタイプ。必須です。

- node: ノードのURLを定義します。

- dcresource: 動的変換リソースのURLを定義します。プレースホルダ・タグ内でのみ有効。

- dcpage: 動的変換ページのURLを定義します。プレースホルダ・タグ内でのみ有効。

- rendition: レンダリングのURLを定義します。

- resource: リソースのURLを定義します。画像などのWebレイアウト静的リソースへのリンクに使用されます。

- Link: コンテンツへのリンクの作成に使用されます。

- url: リンク・パラメータ(タイプによりフォーマットが異なる)。必須です。

- node: nodeId|nodePathのフォーマット。

- dcresource: dcResourcePathのフォーマット。

- dcpage: dcPageNumのフォーマット。

- rendition: dDocName/renditionNameのフォーマット。

- resource: dDocName or webLayoutPathのフォーマット。

- Link: dDocNameまたは(nodeId|nodePath)/dDocNameのフォーマット。

- siteID: リンク・ターゲットのサイトID。これはサイト・コンテンツ・アイテムのセクションIDとコンテンツIDで構成されます。たとえば、セクションID 56とコンテンツID TEST_ITEM。

例

/Aboutセクション(セクションID 20)へのリンクを作成します。

<wcm:url var="url" type="node" url="/About" />
<wcm:url var="url" type="node" url="20" />

コンテンツ・サーバー内のコンテンツの一部へのリンクを作成します。

<wcm:url var="url" type="resource"
url="/groups/public/documents/document/news_article.doc" />

コンテンツ・アイテムのレンダリングへのURL

<!--$wcmUrl("resource","dDocName")-->
<!--$wcmUrl("resource","groups/public/documents/adacct/mydocname.jpg")-->

コンテンツの一部へのリンクを作成し、ノードの内部を表示します(オプションでセクションを指定します)。

<wcm:url var="url" type="link" url="NEWS_ARTICLE" />
<wcm:url var="url" type="link" url="20/NEWS_ARTICLE" />

7.2 Site Studioヘルパー・メソッド

これらのSite Studioヘルパー・メソッドはテンプレートの作成に使用できます。

- 第7.2.1項「Site Studio <filterSections>メソッド」

- 第7.2.2項「Site Studio <listSectionsForRows>メソッド」

- 第7.2.3項「Site Studio <isNodeInNavigationPath>メソッド」

- 第7.2.4項「Site Studio <lookupSection>メソッド」

7.2.1 Site Studio <filterSections>メソッド

セクション・リストをフィルタして、非アクティブなセクションと、コントリビューション・モードでない場合にコントリビュータのみのセクションを削除します。

public static List<SectionNode> filterSections (SiteContext siteContext, List sections) { }

パラメータ

- siteContext: サイト・コンテキスト。

- sections: {@link SectionNode}オブジェクトのリスト。

- stopLevel: 終了レベル(含む)。

- includeHome: Trueの場合はhomeセクションを含めます。

返り値

- sectionList: リストの行を返します(セクションのリストとして示される)。

コード

public static List<SectionNode> filterSections (SiteContext siteContext, List sections) {
if (sections == null) {
return null;
}

List<SectionNode> sectionList = new ArrayList<SectionNode> (sections.size ());
for (Object sectionObj : sections) {
SectionNode section = (SectionNode)sectionObj;
if (!Boolean.parseBoolean (section.getModel ().getActive ())) {
continue;
}
if (Boolean.parseBoolean (section.getModel ().getContributorOnly ())
&& !siteContext.isContributorMode ()) {
continue;
}

//add the section to the list
sectionList.add (section);
}

return sectionList;
}

7.2.2 Site Studio <listSectionsForRows>メソッド

指定されたパラメータと一致するセクションのリストを作成します。リスト内の各行に当該レベルのすべてのセクションが含まれます。

public static List listSectionsForRows (SiteContext siteContext, int startLevel, int stopLevel, boolean includeHome) { }

パラメータ

- siteContext: サイト・コンテキスト。

- startLevel: 開始レベル(含む)

- stopLevel: 終了レベル(含む)。

- includeHome: Trueの場合はhomeセクションを含みます。

返り値

- rows: リストの行を返します(セクションのリストとして示される)

コード

public static List listSectionsForRows (SiteContext siteContext, int startLevel, int stopLevel, boolean includeHome) {
List<List<SectionNode>> rows = new ArrayList<List<SectionNode>> ();
//get the first level
if (startLevel < 1) {
startLevel = 1;
}
if (stopLevel < 1) {
stopLevel = 1;
}
Project project = siteContext.getProject ();
for (int i = startLevel; i <= stopLevel; i++) {
List<SectionNode> sections = project.getStructure ().getSectionsAtLevel (i);
if (sections.isEmpty ()) {
//no more sections so we can end here
break;
}
rows.add (sections);
}
if (startLevel == 1 && includeHome) {
List<SectionNode> nodes = null;
if (rows.size () >= 1) {
nodes = rows.get (0);
} else {
nodes = new ArrayList<SectionNode> ();
rows.add (nodes);
}
nodes.add (0, project.getStructure ().getRootSection ());
}
return rows;
}

7.2.3 Site Studio <isNodeInNavigationPath>メソッド

現在のノードがナビゲーション・パスの中にあるかどうかチェックします。

public static boolean isNodeInNavigationPath
(SiteContext siteContext, String nodeID, boolean includeHome) { }

パラメータ

- siteContext: サイト・コンテキスト。

- nodeID: ノードID。

- includeHome: trueの場合はこのチェックでhomeセクション含め、falseの場合は除外します。

返り値

- isInNavPath: ノードIDがナビゲーション・パスの一部の場合はtrueを返します。

コード

public static boolean isNodeInNavigationPath (SiteContext siteContext, String nodeID, boolean includeHome) {         if (nodeID == null) {             return false;         }          boolean isInNavPath = false;         SectionNode section = siteContext.getSection ();         if (section != null) {             isInNavPath = (section.getID ().equals (nodeID));              if (!isInNavPath) {                 for (SectionNode parent : section.getAncestors ()) {                     if (parent.getParent () == null && !includeHome) {                         continue;                     }                     isInNavPath = (parent.getID ().equals (nodeID));                     if (isInNavPath) {                         break;                    }                }             }          }            return isInNavPath;      }

7.2.4 Site Studio <lookupSection>メソッド

パスまたはIDでセクションを検索します。

public static SectionNode lookupSection (SiteContext siteContext, String id) { }

パラメータ

- siteContext: サイト・コンテキスト。

- id: セクション・パスまたはID。

返り値

- section: セクションを返すか、見つからない場合はヌルを返します。

コード

public static SectionNode lookupSection (SiteContext siteContext, String id) {
//see if this is a number
SectionNode section = null;
boolean isNumber = false;
try {
Integer.parseInt (id);
isNumber = true;
} catch (NumberFormatException exp) {
//ignored
}

if (isNumber) {
section = siteContext.getProject ().getStructure ().getSectionByID (id);
} else {
//fix up path
id = PathHelper.ensureForwardSlashes (id);
//handle relative
if (!id.startsWith ("/")) {
//get the current section
SectionNode current = siteContext.getSection ();
if (current != null) {
id = current.getUrlPath () + "/" + id;
}
}
section = siteContext.getProject ().getStructure ().getSectionByPath (id);
}

return section;
}

索引

A  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W  X

記号

__ssxaCacheEnabled, 1.9

__ssxaCacheFields, 1.9

__ssxaCacheKey, 1.9

__ssxaCacheTTL, 1.9

A

アクセス制御リスト, 1.7

ネイティブ・ドキュメントへのプレースホルダの追加, 4.4.7

ホームページへのプレースホルダの追加, 4.2.12

ページ・テンプレートへのスタイル・シートの追加, 4.5.3

プロジェクトへの接続の追加, 4.1.3

プレースホルダ・マッピングの追加, 4.3.9

アプリケーション, 4.1.1

アプリケーション・コンポーネント, 6.1

アプリケーションEARアーカイブ, 5.2

アプリケーション・サーバー接続, 5.1

アーカイブ・タイプ, 5.2

資産

コントリビュータ・データファイル, 2.1, 2.6, 2.13, 2.13

変換定義, 2.1

カスタム構成スクリプト, 2.1

カスタム要素フォーム, 2.1

要素定義, 2.1, 2.6, 2.6, 2.8

要素, 2.6, 2.6, 2.8

階層, 2.6

イメージ, 2.1

ネイティブ・ドキュメント, 2.1, 2.13, 2.13

その他のメディア, 2.1

ページ・テンプレート, 2.1, 2.6, 2.12

プレースホルダ定義, 2.1, 2.6, 2.10, 2.10

プレースホルダ, 2.6, 2.10

リージョン定義, 2.1, 2.6, 2.6, 2.9

リージョン・テンプレート, 2.1, 2.6, 2.6, 2.9

再利用, 2.7, 2.13

ストレージ、2.2

サブテンプレート, 2.1, 2.6, 2.11

検証スクリプト, 2.1

プレースホルダへのコンテンツの割当て, 4.2.13 ネイティブ・ドキュメント上のプレースホルダへのコンテンツの割当て, 4.4.8 サイドバーへのコンテンツの割当て, 4.3.10 サイトへのページ・テンプレートの関連付け, 4.2.5 認証

コントリビューション・モード, 1.7

設計モード, 1.7

C

キャッチオール・プレースホルダ定義, 2.10

構成ファイル, 2.1

構成スクリプト, 2.1

接続タイプ, 5.1

接続, 4.1.3

connections.xml, 6.1

コンテンツ

プレゼンテーションとコンテンツの分離, 2.1

コンテンツ・キャッシュ, 1.8 コンテンツ・ファイル, 2.1, 2.13

再利用, 2.7, 2.13

サイト・アセットのコンテンツ情報フィールド, 2.2 コンテンツ情報ページ, 2.2 コンテンツ・プレースホルダ定義, 4.3.8 コンテンツ・リージョン定義, 4.3.6 コンテンツ・リージョン・テンプレート, 4.3.7 コンテンツ・サーバー

セキュリティ・モデル, 3.3

コンテンツ・サーバー接続, 4.1.2 コンテキスト・タグ, 7.1.2 コントリビューション

アクセス・レベル, 3.3

コントリビューション・グラフィック, 3.3 コントリビューション・モード, 1.7, 2.5, 4.2.2 コントリビューション・モードでの認証, 1.7 コントリビューション・モデル, 2.5 コントリビューション・リージョン

セキュリティ・モデル, 3.3

コントリビュータ

コンテンツ・プロバイダとして, 3.3

コントリビューションのレベル, 3.3

ロール, 3.3

コントリビュータ・データファイル, 3.1

およびセカンダリ・ページ, 3.5.6

Webサイト間での共有, 3.2

コントリビュータ・データファイル, 2.1, 2.6, 2.13, 2.13 コントリビュータ, 2.3, 2.13 制御ファイル, 2.1 変換定義, 2.1 変換定義, 4.4.1 コンテンツ・サーバー接続の作成, 4.1.2 新しいアプリケーションの作成, 4.1.1 新規プロジェクトの作成, 4.1.1 ネイティブ・ドキュメント用新規セクションの作成, 4.4.3 スタイル・シートの新規作成, 4.5.1 コンテンツ・サーバーでのWebサイトの新規作成, 新しいWebサイト, Webサイト 4.2.1 ネイティブ・ドキュメント用ページ・テンプレートの作成, 4.4.2 ネイティブ・ドキュメント用プレースホルダ定義の作成, 4.4.6 ネイティブ・ドキュメント用リージョン定義の作成, 4.4.4 ネイティブ・ドキュメント用リージョン・テンプレートの作成, 4.4.5 スタイル・シート用サブディレクトリの作成, 4.5.2 WebプロジェクトWARアーカイブの作成, 5.2 アプリケーションEARアーカイブの作成, 5.2 アプリケーション・サーバー接続の作成, 5.1 コンテンツ・プレースホルダ定義の作成, 4.3.8 コンテンツ・リージョン定義の作成, 4.3.6 コンテンツ・リージョン・テンプレートの作成, 4.3.7 変換定義の作成, 4.4.1 要素定義の作成, 4.2.8 プレースホルダ定義の作成, 4.2.11 リージョン定義の作成, 4.2.9 リージョン・テンプレートの作成, 4.2.10, 4.3.4 サイドバー・リンクの作成, 4.3 サイドバー・リージョン定義の作成, 4.3.2 サイト・フラグメントの作成, 4.2.7 静的リスト・データファイルの作成, 4.3.3 静的リスト要素定義の作成, 4.3.1 ホームページの作成, 4.2.4 カスタム構成スクリプト, 2.1 カスタム要素フォーム, 2.1

D

データファイル, 2.1, 2.13, 2.13

dataFileタグ, 7.1.3

デフォルトのプレースホルダ定義, 2.10

定義

変換, 2.1

要素, 2.1, 2.8

プレースホルダ, 2.1, 2.10, 2.10

リージョン, 2.1, 2.9

Site Studioプロジェクトのデプロイ, 5 プロジェクトの手動デプロイ, 5.4 JDeveloperによるプロジェクトのデプロイ, 5.3 リモート・アプリケーション・サーバーへのSite Studioプロジェクトのデプロイ, 5 設計モード, 1.7 設計モードでの認証, 1.7 設計者, 2.3

ロール, 3.3

動的リスト

およびセカンダリ・ページ, 2.14

dynamicConversionタグ, 7.1.4 dynamicListタグ, 7.1.5

E

EARアーカイブ, 5.2, 5.5

接続情報の編集, 5.5

アプリケーション・サーバー上にデプロイされたファイルの編集, 5.5.3

Webアプリケーション・デプロイメント・ディスクリプタの編集, 4.2.3

要素定義, 2.1, 2.6, 2.6, 2.8, 4.2.8

ネーミング規則, 3.5.1

サイトの計画, 3.3, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.5.5, 3.5.6

要素フォーム, 2.1 要素, 2.6, 2.6, 2.8 HCSPベースのカスタム要素フォームの有効化, 1.12 リストから除外(メタデータ), 2.2

F

ファイル

コンテンツ, 2.1, 2.13

コントリビュータ・データファイル, 2.1, 2.13, 2.13, 2.13

制御および構成, 2.1

変換定義, 2.1

カスタム構成スクリプト, 2.1

カスタム要素フォーム, 2.1

要素定義, 2.1

イメージ, 2.1

メディア, 2.1

ネイティブ・ドキュメント, 2.1, 2.13, 2.13, 2.13

ページ・テンプレート, 2.1, 2.12

プレースホルダ定義, 2.1

プレゼンテーション, 2.1

リージョン定義, 2.1

リージョン・テンプレート, 2.1

サブテンプレート, 2.1, 2.11

検証スクリプト, 2.1

フィルタ

モード, 6.2.2

プロキシ・フィルタ, 6.2.2

サイト・フィルタ, 6.2.2

filterSectionsメソッド, 7.2.1 要素のフォーム, 2.1

G

グローバル・プレースホルダ・マッピング, 2.10

H

HCSPベースのカスタム要素, 1.12

ヘルパー・メソッド

filterSections, 7.2.1

isNodeInNavigationPath, 7.2.3

listSectionsForRows, 7.2.2

lookupSection, 7.2.4

サイト・オブジェクトの階層, 2.6 ホームページ, 4.2.4, 4.2.6, 4.2.12

I

idcParameterタグ, 7.1.6

idcServiceタグ, 7.1.7

イメージ, 2.1

初期化サーブレット, 6.2.1

isNodeInNavigationPathメソッド, 7.2.3

J

JavaEE EARファイル, 6.1

JavaEE WARファイル, 6.1

L

レイアウト

およびサイトの計画, 3.1

リンク・ウィザード, 3.3 リスト

動的, 2.14

listSectionsForRowsメソッド, 7.2.2 lookupSectionメソッド, 7.2.4

M

接続情報の手動での編集, 5.5.1

接続情報の手動での上書き, 5.5.2

プレースホルダとプレースホルダ定義とのマッピング, 2.10

メディア・ファイル, 2.1

メタデータ

およびサイトの計画, 3.3

サイトの計画, 3.5.5

xRegionDefinition, 2.2

メタデータ・フィールド

リストから除外, 2.2

リージョン定義, 2.2

Webサイト・オブジェクト・タイプ, 2.2

Webサイト・セクション, 2.2

Webサイト, 2.2

xRegionDefinition, 2.2

サイト・アセットのメタデータ, 2.2 メタデータ・タグ, 7.1.8 MIMEマッピング, 1.12 ミニタイプ, 1.12 モード・フィルタ, 6.2.2, 6.2.2 コントリビューションのモデル, 2.5 プレゼンテーションのモデル, 2.4

N

ネーミング規則

要素定義, 3.5.1

ページ・テンプレート, 3.4

リージョン定義, 3.5.2

リージョン・テンプレート, 3.5.3

セクション、3.2

サイト・アセット, 3.4

サイトの計画, 3.5.6

ネイティブ・ドキュメント, 2.1, 2.13, 2.13, 3.3, 4.4.2, 4.4.3, 4.4.4, 4.4.5, 4.4.6, 4.4.7, 4.4.8

Webサイト間での共有, 3.2

サイトへの発行, 3.3

サイトのナビゲート, 3.2

O

その他のメディア, 2.1

P

ページ・テンプレート, 1.10, 2.1, 2.6, 2.12, 4.2.5, 4.4.2

複数のページ・テンプレートの活用, 3.2

およびサブテンプレート, 3.5.4

説明, 3.2

複数のページ・テンプレートと再利用可能なページ・テンプレート, 3.2

プライマリ・ページ, 3.5.6

セカンダリ・ページ, 3.5.6

サイトの計画, 3.2, 3.5.4, 3.5.6

ページ

プライマリ, 2.14

セカンダリ, 2.14

プレースホルダ定義, 2.1, 2.6, 2.10, 2.10, 3.5.5, 4.2.11

キャッチオール, 2.10

デフォルト, 2.10

プレースホルダ・マッピング, 4.3.9 プレースホルダ・タグ, 7.1.9 placeholderDefinitionDocName, 2.10 プレースホルダ, 2.6, 2.10

マッピング, 2.10

Webサイトの計画, 3, 3 サイト階層の計画, 3.2 プレゼンテーション・ファイル, 2.1 プレゼンテーション・モデル, 2.4 プレゼンテーション, コンテンツとの分離, 2.1 プライマリ・ページ, 2.14

説明, 3.2

サイトの計画, 3.2, 3.5.6

プロジェクト, 4.1.1 プロジェクトの構造, 1.2, 1.4, 1.10 プロキシ・フィルタ, 6.2.2, 6.2.2

R

リージョン・コンテンツ

Webサイトに関連付けられていないコンテンツの追加, 3.2

リージョン定義(メタデータ), 2.2 リージョン定義, 2.1, 2.2, 2.6, 2.6, 2.9, 4.2.9

ネーミング規則, 3.5.2

サイトの計画, 3.5.2

リージョン・テンプレート, 1.10, 2.1, 2.6, 2.6, 2.9, 4.2.10, 4.3.4

ネーミング規則, 3.5.3

サイトの計画, 3.2, 3.5.3

テンプレートの登録, 1.10 再使用可能なページ・テンプレート, 3.2 サイト・アセットの再利用, 2.7, 2.13 ロール

コントリビュータ, 2.3

設計者, 2.3

Webサイトのロール, 2.3 サイトの実行, 4.2.6

S

サンプルのCSSドキュメント, サンプル・スタイル・シート, 4.5.4

スクリプト

カスタム構成スクリプト, 2.1

検証, 2.1

セカンダリ・ページ, 2.14

およびコントリビュータ・データファイル, 3.5.6

動的リスト, 2.14

説明, 3.2

サイトの計画, 3.2, 3.2, 3.5.6

セクション

名前, 3.2

ネーミング規則, 3.2

プレースホルダ・マッピング, 2.10

プライマリ・ページ, 2.14

セカンダリ・ページ, 2.14

サイト階層, 3.2

セキュリティ・モデル, 3.3 セキュリティ設定

アクセス制御リスト, 1.7

アカウント, 1.7

グループ, 1.7

プレゼンテーションとコンテンツの分離, 2.1 サービス・キャッシュ, 1.9 サービス・キャッシュ・パラメータ

__ssxaCacheEnabled, 1.9

__ssxaCacheFields, 1.9

__ssxaCacheKey, 1.9

__ssxaCacheTTL, 1.9

サーブレット

初期化, 6.2.1

SiteStudioプロキシ, 6.2.1

サイドバー・リンク, 4.3 サイドバー・リージョン定義, 4.3.2 サイト・アセット, 3.4

コントリビュータ・データファイル, 2.1, 2.6, 2.13, 2.13

変換定義, 2.1

カスタム構成スクリプト, 2.1

カスタム要素フォーム, 2.1

要素定義, 2.1, 2.6, 2.6, 2.8

要素, 2.6, 2.6, 2.8

階層, 2.6

イメージ, 2.1

管理, 3.4

ネーミング, 3.4

ネイティブ・ドキュメント, 2.1, 2.13, 2.13

作成の順序, 3.5

その他のメディア, 2.1

ページ・テンプレート, 2.1, 2.6, 2.12

プレースホルダ定義, 2.1, 2.6, 2.10, 2.10

プレースホルダ, 2.6, 2.10

リージョン定義, 2.1, 2.6, 2.6, 2.9

リージョン・テンプレート, 2.1, 2.6, 2.6, 2.9

再利用, 2.7, 2.13

ストレージ、2.2

サブテンプレート, 2.1, 2.6, 2.11

検証スクリプト, 2.1

サイト構成ファイル, 2.1 サイト・コンテンツ・ファイル, 2.1 サイト制御ファイル, 2.1 サイト用のファイル, 1.5 サイト・フィルタ, 6.2.2, 6.2.2 サイト・フラグメント, 4.2.7 サイト階層

コントリビューション・モデル, 3.3

深さ, 3.2

計画, 3.2

目的, 3.2

セクション名, 3.2

セクション、3.2

サイトの計画, 3.3, 3.5.6

サイトID, 1.6 サイトのナビゲーション

計画, 3.3

セクションのロール, 3.2

サイトのオブジェクト階層, 2.6 サイトの計画, 3.1, 3.2

およびページ・テンプレート, 3.1, 3.4

およびリージョン・テンプレート, 3.1

およびサブテンプレート, 3.1

データの配置, 3.1

アセットの作成, 3.5

通信, 3.3

構成, 3.1

コンテンツ, 3.1, 3.1

コントリビュータ・データファイル, 3.1

コントリビュータ・ロール, 3.3, 3.3, 3.3, 3.3

設計者ロール, 3.3

要素定義, 3.3, 3.5.1, 3.5.2, 3.5.3, 3.5.4, 3.5.5, 3.5.6

例

ページ・テンプレート, 3.1

プレースホルダ, 3.1, 3.1

サブテンプレート, 3.1, 3.1, 3.1

重要性, 3.1 レイアウト, 3.1 マネージャ・ロール, 3.3 メタデータ, 3.3, 3.5.5 複数のコントリビュータ, 3.3 ネーミング規則, 3.5.6 編成, 3.1 ページ・テンプレート, 3.2, 3.5.4, 3.5.6 プレースホルダ定義, 3.5.5 プライマリ・ページ, 3.2, 3.5.6 リージョン定義, 3.5.2 リージョン・テンプレート, 3.2, 3.5.3 セカンダリ・ページ, 3.2, 3.2, 3.5.6 セクション、3.2 サイト階層, 3.2, 3.3, 3.5.6 サイトのナビゲーション, 3.3 サイトの更新, 3.4 構造, 3.1 サブテンプレート, 3.5.4, 3.5.4, 3.5.5, 3.5.6 ユーザーのアクセス, 3.3 ワークフロー, 3.2, 3.3, 3.5.5 サイトのプレゼンテーション・ファイル, 2.1 Site Studio

コントリビューション・モデル, 2.5

メタデータ・フィールド, 2.2

プレゼンテーション・モデル, 2.4

サイトのオブジェクト階層, 2.6

Site Studioプロジェクト, 5 Site Studioのサイト・ファイル, 1.5 Site Studioタグ・ライブラリ

コンテキスト, 7.1.1

dataFile, 7.1.1

dynamicConversion, 7.1.1

dynamicList, 7.1.1

idcParameter, 7.1.1

idcService, 7.1.1

メタデータ, 7.1.1

プレースホルダ, 7.1.1

staticPlaceholder, 7.1.1

url, 7.1.1

Site Studioテクノロジ, 6.2 サイトURLフォーマット

コンテンツ, 1.6

セクション、1.6

サイトID, 1.6

SiteStudioプロキシ・サーブレット, 6.2.1 ユーザー資格証明の指定, 4.2.2 静的リスト・データファイル, 4.3.3 静的リスト要素定義, 4.3.1 staticPlaceholderタグ, 7.1.10 サイト・アセットの記憶域, 2.2 Site Studioプロジェクトの構造 スタイル・シート, 4.5.3 スタイル・シート, 4.5.1, 4.5.2 サブテンプレート, 1.10, 2.6

およびページ・テンプレート, 3.5.4, 3.5.6

サイトの計画, 3.5.4, 3.5.4, 3.5.5, 3.5.6

テンプレート

サブテンプレート, 2.1, 2.11

T

プレースホルダのタグ, 2.10

タグ・ライブラリ

コンテキスト, 7.1.2

dataFile, 7.1.3

dynamicConversion, 7.1.4

dynamicList, 7.1.5

idcParameter, 7.1.6

idcService, 7.1.7

メタデータ, 7.1.8

プレースホルダ, 7.1.9

staticPlaceholder, 7.1.10

url, 7.1.11

テンプレート登録, 1.10 テンプレート

ページ, 2.1, 2.12

ページ・テンプレート, 1.10

リージョン, 2.1, 2.9

リージョン・テンプレート, 1.10

サブテンプレート, 1.10

サード・パーティ・アプリケーション, 2.13

U

フラグメントの更新, サイドバー・フラグメント, 4.3.5

urlタグ, 7.1.11

ユーザー資格証明, 4.2.2

ユーザー

コントリビュータ, 2.3

設計者, 2.3

V

検証スクリプト, 2.1

ホームページの表示, 4.2.6

W

WARアーカイブ, 5.2, 5.5

wcm-config.xml, 1.4, 6.1

Webアプリケーション・デプロイメント・ディスクリプタ, 4.2.3

WebプロジェクトWARアーカイブ, 5.2

Webサイト

コントリビュータによるアクセス, 3.3

現在関連付けられていないコンテンツの追加, 3.2

コンテンツ・ファイル, 2.1

制御および構成ファイル, 2.1

計画, 3

プレゼンテーション・ファイル, 2.1

サイト・アセットの再利用, 2.7, 2.13

ロール, 2.3

プレゼンテーションとコンテンツの分離, 2.1

コントリビュータ・データファイルの共有, 3.2

ネイティブ・ドキュメントの共有, 3.2

ネイティブ・ドキュメントの発行, 3.3

更新, 3.3

Webサイト・オブジェクト・タイプ(メタデータ), 2.2 Webサイト・プロパティ

デフォルトのプレースホルダ定義, 2.10

Webサイト・セクション(メタデータ), 2.2 Webサイト(メタデータ), 2.2 WebLogic接続タイプ, 5.1 weblogic-application.xml, 6.1 weblogic.xml, 1.4, 6.1 WebSphere接続タイプ, 5.1 web.xml, 1.4, 1.12, 6.1 ウィザード

リンク, 3.3

ワークフロー

サイトの計画, 3.2, 3.3, 3.5.5

X

XML, 2.13

xRegionDefinition, 2.2

Copyright © 2010, 2011, Oracle and/or its affiliates. All rights reserved.