Oracle® Fusion Middleware

Oracle WebCenter Sitesでの開発

12c (12.2.1)

E72540-01(原本部品番号:E49197-02)

2016年3月

WebCenter SitesでデフォルトおよびモバイルのWebサイトの設計および構築の方法について説明する、WebCenter Sites開発者向けのドキュメント。このドキュメントでは、Visitor Services (複数の外部プラットフォーム間でデータを取得して、訪問者のセグメント分けとセグメント単位のコンテンツのターゲット設定を改善)の開発と、A/B Testing (コンテンツの各部を比較して、各部の有効性を判断)の開発についても説明します。このドキュメントでは、訪問者のアクティビティを適切に追跡および分析するための変換およびイベントについても説明します。

Oracle Fusion Middleware Oracle WebCenter Sitesでの開発12c (12.2.1)

E72540-01

Copyright ©2012, 2016, Oracle and/or its affiliates All rights reserved.

原本協力者: Promila Chitkara (著者)、Hareesh Kadlabalu (協力エンジニア)

原本協力者: Bonnie Vaughan、Melinda Rubenau

協力者: Aswini Kalyanam、Chandra Busireddy、Eric Gandt、Eugene Shevchenko、Kannan Appachi、Kuldeep Tiwari、Naveen Chintala、Revanth Potnuru、Ravi Khanuja、Saikat Chaudhuri、Sailaxmi Rajanala、Suchitra Tata

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

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

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

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

目次

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

はじめに

- 対象読者

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

- Oracle Supportへのアクセス

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

第I部 Oracle WebCenter Sitesスタート・ガイド

1 WebCenter Sitesでの開発の概要

- 1.1 WebCenter Sitesでの開発について

- 1.2 WebCenter Sites開発者の一般的なタスク

- 1.2.1 コンテンツ表示のデータ・モデル

- 1.2.2 コンテンツ管理サイトのコンテンツ・エントリ・フォーム

- 1.2.3 コンテンツをWebサイトにレンダリングするためのテンプレートおよびエレメント

- 1.2.3.1 エレメントのファイル

- 1.2.3.2 APIおよびJSPタグ

- 1.2.3.3 セッションおよびCookie

- 1.2.4 開発、管理、配信およびテスト用WebCenter Sitesシステム

- 1.2.5 承認およびパブリッシュ

- 1.2.6 キャッシングによるパフォーマンスの最適化

- 1.2.6.1 ページのキャッシング

- 1.2.6.2 結果セットのキャッシング

- 1.2.6.3 アセットのキャッシング

- 1.2.6.4 Satellite Serverのキャッシング

- 1.2.6.4.1 HTTPリクエスト

- 1.2.6.4.2 Satellite Serverのサーブレット

- 1.3 WebCenter Sitesのユーティリティ

- 1.4 WebCenter Sitesのインタフェース

- 1.5 WebCenter Sitesのユースケース・シナリオ

- 1.5.1 情報発信(ブランド確立)用Webサイトの開発

- 1.5.2 市場志向型Webサイトの作成

- 1.5.3 モバイル用Webサイトの作成

2 avisportsサンプル・サイトの概要

- 2.1 コンテンツ・コントリビュータとしてのavisportsサンプル・サイトのツアー

- 2.2 avisportsサンプル・サイトのインフラストラクチャのツアー

3 WebCenter Sitesの開発プロセス

- 3.1 手順1: チームを発足する

- 3.2 手順2: 機能とデザインの仕様を作成する

- 3.2.1 機能要件

- 3.2.2 ページのデザイン

- 3.2.3 キャッシュ戦略

- 3.2.4 セキュリティ戦略(アクセス制御)

- 3.2.5 フォーマットとコンテンツの切離し(アセットのエレメント)

- 3.2.5.1 アセット・タイプ(コンテンツ)の判別

- 3.2.5.2 イメージなどのBLOBの処理方法の判断

- 3.2.5.3 機能デザインとフォーマットの策定(エレメント)

- 3.2.6 データ・デザイン

- 3.2.6.1 アセット・タイプ

- 3.2.6.2 アセット・タイプをサポートする補助表

- 3.2.6.3 訪問者データ

- 3.3 手順3: 管理システムの要件を設定する

- 3.4 手順4: データ・デザインを実装する

- 3.5 手順5: オンライン・サイトを構築する

- 3.6 手順6: 管理システムを設定する

- 3.6.1 コンテンツをアセットとしてインポート

- 3.6.2 カタログ・データおよびフレックス・アセット・データのインポート

- 3.6.3 サイトのデザインについて編集チームに指示

- 3.7 手順7: 配信システムを設定する

- 3.8 手順8: 配信システムにパブリッシュする

第II部 データ・モデルの構築

4 アセット・モデルの理解

- 4.1 アセット・タイプとアセット・モデルについて

- 4.1.1 2つのデータ・モデル

- 4.1.2 デフォルトのコアなアセット・タイプ

- 4.1.2.1 WebCenter Sitesで配信されるアセット・タイプ

- 4.1.2.2 Engageで配信されるアセット・タイプ

- 4.1.3 コンテンツを表すために使用するアセット・モデルはどれか

- 4.1.3.1 ベーシック・モデルを使用する場合

- 4.1.3.2 フレックス・モデルを使用する場合

- 4.2 ベーシック・アセット・モデル

- 4.2.1 ベーシック・アセット間の関係

- 4.2.1.1 アソシエーション

- 4.2.1.2 名前なし関係

- 4.2.2 カテゴリ、ソースおよびサブタイプ

- 4.2.2.1 カテゴリ

- 4.2.2.2 ソース

- 4.2.2.3 サブタイプ

- 4.2.3 ベーシック・アセット・タイプとデータベース

- 4.2.3.1 テンプレート・アセット・タイプとデータベース

- 4.2.3.2 ベーシック・アセット・タイプのデータベース表のデフォルトの列

- 4.3 フレックス・アセット・モデル

- 4.3.1 フレックス・ファミリ

- 4.3.1.1 親アセット、子アセットおよびフレックス・アセット

- 4.3.2 avisportsサンプル・サイトのフレックス・ファミリ

- 4.3.3 フレックス属性

- 4.3.3.1 属性のデータ型

- 4.3.3.2 属性のデフォルトの入力スタイル

- 4.3.3.3 外部属性

- 4.3.4 フレックス親とフレックス親定義

- 4.3.4.1 ビジネス・ルールと分類

- 4.3.5 フレックス・アセットとフレックス定義アセット

- 4.3.6 フレックス・ファミリとデータベース

- 4.3.6.1 フレックス・アセット・タイプのデータベース表のデフォルトの列

- 4.3.6.2 _Mungo表

- 4.3.6.3 MungoBlobs表

- 4.3.6.4 _AMap表

- 4.4 assetsetおよびsearchstate

- 4.5 検索エンジンと2つのアセット・モデル

- 4.6 タグと2つのアセット・モデル

- 4.7 要約: ベーシック・アセット・モデルとフレックス・アセット・モデル

5 ベーシック・アセット・タイプの設計

- 5.1 AssetMakerユーティリティについて

- 5.1.1 AssetMakerの仕組み

- 5.1.2 アセット記述子ファイル

- 5.1.2.1 アセット記述ファイルについて

- 5.1.2.2 フォーマットと構文について

- 5.1.2.3 AssetMakerのタグについて

- 5.1.3 アセット・タイプのデータベース表の列

- 5.1.3.1 ソース列: 特殊な場合

- 5.1.3.2 列の記憶域のタイプ

- 5.1.3.3 フィールドの入力タイプ

- 5.1.3.4 標準アセット・フィールドのデータ型

- 5.1.4 アセット・タイプに対応したエレメントとSQL文

- 5.1.4.1 エレメント

- 5.1.4.1.1 PreUpdateエレメントとPostUpdateエレメントについて

- 5.1.4.2 SQL文

- 5.2 ベーシック・アセットの作成を開始する前に

- 5.2.1 アセット・タイプの設計の立案

- 5.2.2 開発システムの設定

- 5.3 ベーシック・アセット・タイプの作成

- 5.3.1 アセット記述子ファイルのコーディング

- 5.3.2 アセット記述子ファイルのWebCenter Sitesへのアップロード

- 5.3.3 アセット表の作成

- 5.3.4 アセット・タイプの構成

- 5.3.5 サイトのアセット・タイプの有効化

- 5.3.6 アセット記述子ファイルの微調整

- 5.3.7 (オプション)アセット・タイプのエレメントのカスタマイズ

- 5.3.8 (オプション)サブタイプの追加

- 5.3.9 (オプション)アソシエーション・フィールドの構成

- 5.3.10 (オプション)カテゴリの構成

- 5.3.11 (オプション)ソースの構成

- 5.3.12 (条件付き) MIMEタイプの追加

- 5.3.13 (オプション)索引付き検索を有効にするための検索エレメントの編集

- 5.3.14 アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)

- 5.3.15 アセット・タイプのテンプレートのコーディング

- 5.3.16 他のシステムへのアセット・タイプの移動

- 5.4 ベーシック・アセット・タイプの削除

6 フレックス・アセット・タイプの設計

- 6.1 フレックス・アセット・タイプの設計について

- 6.2 フレックス・ファミリの設計ヒント

- 6.2.1 配信システムへの訪問者

- 6.2.2 管理システムのユーザー

- 6.2.3 作成する属性タイプの数

- 6.2.4 フレックス属性の設計

- 6.2.4.1 属性に使用可能なデータ型

- 6.2.4.2 属性エディタの使用について

- 6.2.4.3 各属性の使用場所

- 6.2.4.4 階層による属性の依存性

- 6.2.5 作成する定義タイプの数

- 6.2.6 親定義とフレックス定義アセットの設計

- 6.2.6.1 階層の配置の指定

- 6.2.6.2 属性継承の指定

- 6.2.6.3 フレックス親定義アセットの数

- 6.2.6.4 フレックス定義アセットの数

- 6.3 フレックス・ファミリ・メーカー・ユーティリティ

- 6.4 フレックス・アセット・エレメント

- 6.5 開発システムの設定

- 6.6 フレックス・アセット・ファミリの作成

- 6.6.1 フレックス・ファミリの作成

- 6.6.2 (条件付き)追加のフレックス・ファミリ・メンバーの作成

- 6.6.3 (条件付き)フレックス・ファミリ・メンバーの構成

- 6.6.4 新規のフレックス・アセット・タイプの有効化

- 6.6.5 フレックス属性の作成

- 6.6.5.1 フレックス属性の作成: 基本的な手順

- 6.6.5.2 タイプBlobのフレックス属性(アップロード・フィールド)の作成

- 6.6.5.3 タイプAssetのフレックス属性の作成

- 6.6.5.4 外部フレックス属性の作成

- 6.6.6 (条件付き)フレックス・フィルタ・アセットの作成

- 6.6.7 親定義アセットの作成

- 6.6.8 フレックス定義アセットの作成

- 6.6.9 フレックス親アセットの作成

- 6.6.10 アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)

- 6.6.11 フレックス・アセットのテンプレートのコーディング

- 6.6.12 設計のテスト(テスト用フレックス・アセットの作成)

- 6.6.13 (条件付き)フレックス・アセットのアソシエーションの作成

- 6.6.14 他のシステムへのアセット・タイプの移動

- 6.7 フレックス属性、親および定義の編集に関するに関する必知事項

- 6.7.1 属性の編集に関する必知事項

- 6.7.2 親定義とフレックス定義の編集に関する必知事項

- 6.7.3 親およびフレックス・アセットの編集に関する必知事項

- 6.8 製品セットの使用

- 6.8.1 製品セットの使用について

- 6.8.2 製品セットの作成

7 階層的なフレックス・ファミリの作成

- 7.1 階層組織

- 7.2 フレックス・ファミリの仕様

- 7.3 現実世界の例を使用したサンプルのフレックス・ファミリの作成

- 7.3.1 フレックス・ファミリの作成

- 7.3.2 新規のフレックス・アセット・タイプの有効化

- 7.3.3 フレックス・ファミリ・タブのWebCenter Sitesのツリーへの追加

- 7.3.4 親定義アセットの作成

- 7.3.5 フレックス親アセットの作成

- 7.3.6 フレックス定義アセットの作成

- 7.3.7 フレックス・アセットの作成

- 7.3.8 現実世界のデータ・モデルへの定型データ・モデルの変換

- 7.3.9 現実世界のモデルの開発

8 フレックス・フィルタの作成

- 8.1 フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットについて

- 8.1.1 フレックス・フィルタ・クラス

- 8.1.2 フレックス・フィルタ・アセット

- 8.2 フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成

- 8.2.1 フレックス・フィルタ・クラスの実装

- 8.2.1.1 AbstractFlexFilterクラスの拡張

- 8.2.2 カスタム・フレックス・フィルタ・クラスの定義

- 8.2.3 フレックス・フィルタ・アセットの作成

- 8.3 ドキュメント変換フレックス・フィルタ

- 8.3.1 デフォルトのソリューション

- 8.3.2 カスタム・ソリューションについて

- 8.3.3 デフォルトの変換エンジンの使用

- 8.3.4 ドキュメント変換フレックス・フィルタのカスタマイズ

- 8.3.4.1 ドキュメント・トランスフォーマ・フレックス・フィルタの作成とデプロイ

- 8.3.4.2 変換エンジンの登録

- 8.3.4.3 ドキュメント・トランスフォーマの登録

9 属性エディタの設計

- 9.1 属性エディタについて

- 9.1.1 presentationobject.dtdファイル

- 9.1.2 属性エディタ・アセット

- 9.1.2.1 構文とデフォルト・タグ

- 9.1.2.2 CHECKBOXES

- 9.1.2.3 CKEditor

- 9.1.2.4 PICKASSET

- 9.1.2.5 PULLDOWNの例

- 9.1.2.6 RADIOBUTTONS

- 9.1.2.7 TEXTAREA

- 9.1.2.8 TEXTFIELD

- 9.1.2.9 TYPEAHEAD

- 9.1.2.10 UPLOADER

- 9.1.3 属性エディタのエレメント

- 9.1.4 属性エディタのエレメントの規則

- 9.2 属性エディタの作成

- 9.3 属性エディタのカスタマイズ

- 9.3.1 例: カスタマイズされた属性エディタ

- 9.3.1.1 手順1: presentationobject.dtdファイルの編集

- 9.3.1.2 手順2: 属性エディタの例に対する権限の指定

- 9.3.1.3 手順3: TEXTAREAエレメントの編集

- 9.3.2 アップロード対象のファイルを検証するためのカスタム・ロジックの追加

- 9.4 属性エディタの編集に関する考慮事項

10 付属の属性エディタの構成

- 10.1 CKEditorの構成

- 10.1.1 始める前に

- 10.1.2 CKEditorインスタンスの作成方法とフィールドに対して有効化する方法

- 10.1.3 CKEditorをWebモードで使用可能にする方法

- 10.1.4 選択したアセット・タイプをCKEditorで使用可能にする方法

- 10.1.5 組み込まれたアセットの承認依存性を設定する方法

- 10.1.6 CKEditorツールバーをカスタマイズする方法

- 10.1.7 CKEditorでスペル・チェック・サポートを構成する方法

- 10.2 Clarkii Online Image Editorの構成

- 10.2.1 Clarkii OIEインスタンスの作成方法とフィールドに対して有効化する方法

- 10.2.2 Clarkii OIEのプロパティを構成する方法

- 10.2.3 アセットを分類するためにフィールド・コピアー・フィルタを実装する方法

- 10.3 イメージ・ピッカーの構成

- 10.3.1 イメージ・ピッカーに表示するイメージ・アセットを分類する方法

- 10.3.2 イメージ・ピッカー属性エディタ定義のコードを作成する方法

11 WebCenter Sitesデータベースでの作業

- 11.1 データベース表のタイプ

- 11.1.1 オブジェクト表

- 11.1.2 ツリー表

- 11.1.3 コンテンツ表

- 11.1.4 外部表

- 11.1.5 システム表

- 11.1.6 表のタイプの特定

- 11.2 列(フィールド)のタイプ

- 11.2.1 汎用的なフィールド・タイプ

- 11.2.2 データベース固有のフィールド・タイプ

- 11.2.3 WebCenter SitesのURLフィールドを使用した間接的なデータ格納

- 11.3 システム表への追加について

- 11.4 プロパティ・ファイルおよびデータベースについて

12 アセットを保持しない表内のデータ管理

- 12.1 非アセット表でのメソッドおよびタグを使用したデータ管理のプログラミング

- 12.1.1 データの記述と取得について

- 12.1.1.1 CatalogManagerを介したセキュリティ

- 12.1.1.2 ツリー表を管理するためのTreeManagerコマンド

- 12.1.2 データの問合せのメソッド

- 12.1.3 リストおよびデータ・リストの作成

- 12.2 データ・エントリ・フォームのコード化

- 12.2.1 行の追加方法

- 12.2.1.1 addrowFORMエレメント

- 12.2.1.2 addrowページのルート・エレメント

- 12.2.2 行の削除方法

- 12.2.2.1 deleterowFORMエレメント

- 12.2.2.2 deleterowページのルート・エレメント

- 12.2.3 表の問合せ方法

- 12.2.3.1 SelectNameFormエレメント

- 12.2.3.2 QueryEditRowFormページのルート・エレメント

- 12.2.3.3 QueryEditRowページのルート・エレメント

- 12.2.4 埋め込まれたSQL文を使用した表の問合せ方法

- 12.2.4.1 QueryInlineSQLForm

- 12.2.4.2 QueryInlineSQLページのルート・エレメント

- 12.3 非アセット表の削除に関する考慮事項

第III部 Webサイトの開発

13 MVCフレークワークおよびAPIを使用したWebsサイト開発

- 13.1 サーバー側およびクライアント側の開発方法

- 13.2 サーバー側MVCフレームワーク

- 13.2.1 開発者のサンプルWebサイト

- 13.2.2 WebCenter Sites MVCフレームワークの概要

- 13.2.3 コントローラ

- 13.2.4 ビュー

- 13.3 ページ、ページレットおよびエレメント

- 13.4 テンプレート・アセット、CSElementアセットおよびSiteEntryアセット

- 13.5 ページ・アセットおよびサイト・ナビゲーション

- 13.6 日付ベースのプレビュー

- 13.7 多言語サポート

- 13.8 MVCフレームワークのキャッシング

- 13.9 サーバー側Java API

- 13.9.1 アセット・リーダー

- 13.9.2 ナビゲーション・リーダー

- 13.9.3 リンク・ビルダー

- 13.9.4 BLOBリンク・ビルダー

- 13.9.5 検索

- 13.9.6 推奨リーダー

- 13.9.7 表リーダー

- 13.10 REST API

- 13.11 サンプルWebサイト

14 サーバー側Webサイトの開発

- 14.1 サーバー側Webサイトの開発について

- 14.2 コントローラの作成

- 14.3 テンプレートの作成

- 14.4 ホームページの設定

- 14.5 サイト・ナビゲーションの追加

15 クライアント側Webサイトの開発

- 15.1 クライアント側Webサイトについて

- 15.2 REST-avisportsを開発するためのRESTコール: 例

- 15.2.1 ナビゲーション・メニューの取得

- 15.2.2 「Home」ページの取得

- 15.2.3 追加のWebサイト・ページの取得

- 15.2.4 ページからの記事のコール

- 15.2.5 ページ区切りを使用したコレクション・リソースのコール

- 15.2.6 検索リソースのコール

- 15.2.7 ページ・セグメントのコール

- 15.2.7.1 セグメントのないページのコール

- 15.2.7.2 特定の訪問者をターゲットにしたセグメントのあるページのコール

- 15.2.7.3 異なる訪問者をターゲットにしたセグメントのあるページのコール

- 15.2.7.4 追加の訪問者をターゲットにしたセグメントのあるページのコール

16 タグ・テクノロジを使用したWebサイト開発

- 16.1 コーディング言語の選択について

- 16.2 Oracle WebCenter Sitesのコンテキストについて

- 16.2.1 ICSオブジェクト

- 16.2.2 FTCSタグ

- 16.3 WebCenter Sites JSPの理解

- 16.3.1 WebCenter Sitesの標準先頭部について

- 16.3.1.1 taglibディレクティブ

- 16.3.1.2 pegeディレクティブ

- 16.3.1.3 cs:ftcsタグ

- 16.3.2 JSPの暗黙オブジェクトについて

- 16.3.3 JSP構文について

- 16.3.4 JSPアクションについて

- 16.3.5 JSP宣言について

- 16.3.6 スクリプトレットと式について

- 16.3.7 JSPディレクティブについて

- 16.3.8 Oracle WebCenter Sitesのタグ・ライブラリについて

- 16.3.8.1 ベーシック・アセットとフレックス・アセット両方のタグ・ライブラリ

- 16.3.8.2 ベーシック・アセット用のタグ・ライブラリ

- 16.3.8.3 フレックス・アセット用のタグ・ライブラリ

- 16.4 WebCenter Sites XMLの理解

- 16.4.1 WebCenter Sitesの標準先頭部

- 16.4.1.1 XMLのバージョンとエンコーディング

- 16.4.1.2 DTDファイル

- 16.4.1.3 FTCSタグ

- 16.4.2 XMLのエンティティと予約文字

- 16.4.3 XML解析エラー

- 16.5 WebCenter Sitesタグの理解

- 16.5.1 WebCenter Sitesのコンテキストを作成するタグ

- 16.5.2 変数を処理するタグ

- 16.5.3 ページとエレメントをコールするタグ

- 16.5.4 URLを作成するタグ

- 16.5.5 キャッシングを制御するタグ

- 16.5.6 Cookieを設定するタグ

- 16.5.7 プログラミング構文のタグ

- 16.5.8 構成上と承認上の依存関係を管理するタグ

- 16.5.9 ベーシック・アセットに関する情報を取得するタグ

- 16.5.9.1 アセット・タグに関するパフォーマンス上の注意事項

- 16.5.10 アセットセットを作成するタグ(フレックス・アセット)

- 16.5.11 検索状態を作成するタグ(フレックス・アセット)

- 16.6 WebCenter Sitesでサポートされる変数について

- 16.6.1 予約変数

- 16.6.2 標準変数

- 16.6.2.1 SETVARを使用した変数

- 16.6.2.2 URLを使用した変数

- 16.6.2.3 Explorerを使用したエレメントとテンプレートのデフォルト変数

- 16.6.2.4 HTMLフォームを使用した変数

- 16.6.3 セッション変数

- 16.6.4 変数の操作

- 16.6.4.1 変数の値を読み取るための構文

- 16.6.4.2 変数の値を表示するためのタグ

- 16.6.4.3 別の変数への単一変数値の割当て

- 16.6.4.4 HTMLタグの変数

- 16.6.4.5 IF/THEN/ELSEを使用した変数の評価

- 16.6.5 変数と優先順位

- 16.6.6 変数に関するベスト・プラクティス

- 16.7 WebCenter Sitesの他の記憶域構成体

- 16.7.1 ビルトイン

- 16.7.2 リスト

- 16.7.2.1 リストのループ処理

- 16.7.3 カウンタ

- 16.8 特殊文字の値について

17 セッションおよびCookieについて

- 17.1 セッションについて

- 17.2 セッションのライフタイム

- 17.2.1 WebCenter Sitesによって保持されるセッション変数

- 17.2.2 ログインとログアウト

- 17.3 セッションの例

- 17.3.1 FeelingsFormエレメント

- 17.3.2 SetFeelingエレメント

- 17.3.3 Meatエレメント

- 17.4 Cookieについて

- 17.4.1 CookieServer

- 17.4.2 Cookieのタグ

- 17.5 Cookieの例

- 17.5.1 Start.xml

- 17.5.2 ColorForm

- 17.5.3 CreateCookie

- 17.5.4 DisplayWelcome

- 17.5.5 Cookie例の実行

- 17.6 ヒントとコツ

- 17.7 Satellite Serverのセッション・トラッキング

- 17.7.1 URLを使用したセッションのフラッシュ

- 17.7.2 現行セッション情報のフラッシュ

- 17.7.3 その他のセッション情報のフラッシュ

18 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成

- 18.1 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットについて

- 18.2 ページ、ページレットおよびエレメントの使用

- 18.2.1 エレメント、ページレットおよびキャッシュ

- 18.2.2 ページとエレメントのコール

- 18.2.3 ページとページレットの比較

- 18.3 CSElementアセット、テンプレート・アセットおよびSiteEntryアセットの使用

- 18.3.1 テンプレート・アセット

- 18.3.2 CSElementアセット

- 18.3.3 SiteEntryアセット

- 18.3.4 非アセット・エレメント

- 18.4 テンプレート・アセットの作成

- 18.4.1 テンプレート・アセットの作成を開始する前に

- 18.4.1.1 テンプレート・アセットの名前付け

- 18.4.1.2 タイプ付きまたはタイプなしとしてのテンプレートの指定

- 18.4.1.3 テンプレート共有とサイト・レプリケーション

- 18.4.2 テンプレート・アセットの作成

- 18.4.2.1 「テンプレート」フォームを開く

- 18.4.2.2 テンプレート・アセットの名前付けと記述

- 18.4.2.3 テンプレートのエレメントの構成

- 18.4.2.4 SiteEntryの構成

- 18.4.2.5 マップの構成

- 18.4.2.6 (オプション)サムネイルの作成

- 18.4.2.7 テンプレートの調査

- 18.5 CSElementアセットの作成

- 18.5.1 CSElementの作成を開始する前に

- 18.5.1.1 CSElementの名前付け

- 18.5.1.2 CSElement共有とサイト・レプリケーション

- 18.5.2 CSElementアセットの作成

- 18.5.2.1 「CSElement」フォームを開く

- 18.5.2.2 CSElementアセットの名前付けと記述

- 18.5.2.3 エレメントの構成

- 18.5.2.4 マップの構成

- 18.5.2.5 CSElementの保存と調査

- 18.5.2.6 ブックマークへのCSElement追加

- 18.6 SiteEntryアセットの作成

- 18.6.1 SiteEntryアセットの作成を開始する前に

- 18.6.2 SiteEntryアセットの作成

- 18.6.2.1 「SiteEntry」フォームを開く

- 18.6.2.2 SiteEntryアセットの作成

- 18.6.2.3 SiteEntryアセットの保存と調査

- 18.7 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの管理

- 18.7.1 デフォルトの承認テンプレートの指定(静的パブリッシュのみ)

- 18.7.2 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの編集

- 18.7.3 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの共有

- 18.7.4 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの削除

- 18.7.5 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー

- 18.7.5.1 テンプレートとプレビュー

- 18.7.5.2 CSElementアセットとSiteEntryアセットおよびプレビュー

- 18.8 Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集

- 18.8.1 テンプレートとCSElementの作成

- 18.8.2 テンプレートとCSElementの編集

19 テンプレートとラッパーの作成

- 19.1 テンプレートの使用

- 19.1.1 レイアウト・テンプレート

- 19.1.1.1 レイアウト・テンプレートはブラウザから起動可能

- 19.1.1.2 レイアウト・テンプレートはアセットに割当て可能

- 19.1.1.3 レイアウト・テンプレートは通常、Webページ全体をレンダリングする

- 19.1.1.4 ユースケース1: 記事アセット用にレイアウト・テンプレートを作成

- 19.1.2 ページレット・テンプレート

- 19.1.2.1 ページレット・テンプレートはブラウザから直接起動できない

- 19.1.2.2 ページレット・テンプレートはアセットに割り当てできない

- 19.1.2.3 ページレット・テンプレートはページ・フラグメントをレンダリングする

- 19.1.2.4 ユースケース2: ページレット・テンプレートの使用

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

- 19.1.3.1 ページ・テンプレートはブラウザから起動可能

- 19.1.3.2 ページ・テンプレートはアセットに割り当てできない

- 19.1.3.3 ページ・テンプレートはプレビュー用に使用可能

- 19.2 ラッパーの使用

- 19.2.1 ラッパー・ページの作成

- 19.2.2 ラッパーのプレビュー

20 テンプレートおよびCSElementのエレメントのコーディング

- 20.1 依存性について

- 20.1.1 パブリッシュ・システムと承認依存性

- 20.1.1.1 承認依存性の計算

- 20.1.1.2 Exists、ExactおよびNone

- 20.1.1.3 ディスクへのエクスポート用の承認テンプレート

- 20.1.1.4 サブタイプ、フレックス定義および承認テンプレート

- 20.1.2 ページの生成と構成依存性

- 20.1.2.1 CacheManagerと動的パブリッシュ・セッション

- 20.1.2.2 CacheManagerとプレビュー機能

- 20.2 依存性をログに記録するためのコーディングについて

- 20.2.1 ASSET.LOADおよびasset:load

- 20.2.2 ASSETSET (assetset)タグ・ファミリ

- 20.2.2.1 承認依存性タイプの設定

- 20.2.3 RENDER.GETPAGEURLおよびrender:getpageurl

- 20.2.4 RENDER.LOGDEP (render:logdep)

- 20.2.4.1 承認依存性タイプの設定

- 20.2.5 RENDER.FILTERおよびrender:filter

- 20.2.6 RENDER.UNKNOWNDEPSおよびrender:unknowndeps

- 20.3 CSElementアセットとSiteEntryアセットのコール

- 20.4 ベーシック・アセットを表示するエレメントのコーディング

- 20.4.1 シンプルなコンテンツを表すアセット

- 20.4.2 アソシエーション

- 20.4.3 ImageFileアセットまたは他のBLOBアセット

- 20.4.4 埋込みリンクを保持できるベーシック・アセット

- 20.4.5 コレクション

- 20.4.5.1 コレクション・テンプレートと承認依存性

- 20.4.5.2 コレクション・テンプレートと構成依存性

- 20.4.6 問合せアセット

- 20.4.7 ページ・アセット

- 20.5 フレックス・アセットを表示するエレメントのコーディングについて

- 20.5.1 アセットセット

- 20.5.2 検索状態オブジェクト

- 20.5.3 アセットセット、検索状態およびフレックス属性アセット・タイプ

- 20.5.4 有効範囲

- 20.6 フレックス・アセットを表示するテンプレートのコーディング

- 20.6.1 この項の例で使用するサンプル・データ・セット

- 20.6.2 1つの製品(フレックス・アセット)が含まれたアセットセットの例

- 20.6.2.1 検索状態の作成とアセットセットへの適用

- 20.6.2.2 製品の価格の取得

- 20.6.2.3 製品の価格の表示

- 20.6.2.4 製品の色の取得

- 20.6.2.5 製品の色の表示

- 20.6.2.6 ASSETSET.GETMULTIPLEVALUESタグのリスト・オブジェクトの作成

- 20.6.2.7 ASSETSET.GETMULTIPLEVALUESを使用した価格と色の両方の値の取得

- 20.6.2.8 jeans-2製品の価格と色の値の表示

- 20.6.3 特殊なケース: TEXT型、BLOB型およびURL型のフレックス属性

- 20.6.3.1 TEXT型のフレックス属性について

- 20.6.3.2 BLOB型のフレックス属性について

- 20.6.3.3 BlobServer URLの作成

- 20.6.3.4 BLOBフレックス属性の値の取得および表示

- 20.6.4 複数の製品(フレックス・アセット)が含まれたアセットセットの例

- 20.6.4.1 検索状態の作成とアセットセットへの適用

- 20.6.4.2 アセットセット内のアセットの数の表示

- 20.6.4.3 ジーンズで用意されている色の表示

- 20.6.4.4 アセットセット内のジーンズの色とスタイルの表示

- 20.6.4.5 すべてのジーンズとそれらの属性値を表示する表の作成

- 20.6.4.6 価格範囲に基づいたジーンズの検索

- 20.6.4.7 色のワイルドカードを使用したジーンズの検索

- 20.6.4.8 特定の色のジーンズの検索

- 20.7 ハイパーリンクのURLの作成

- 20.7.1 RENDER.GETPAGEURL (render:getpageurl)

- 20.7.2 RENDER.SATELLITEBLOB (render:satelliteblob)

- 20.7.3 RENDER.GETBLOBURL (render:getbloburl)

- 20.7.4 referURL変数の使用

- 20.8 エラー状態の処理

- 20.8.1 errno変数の使用

- 20.8.2 間違ったページのキャッシングの防止

21 コンテキスト内編集およびプレゼンテーション編集用テンプレートのコーディング

- 21.1 コンテキスト内コンテンツ編集用テンプレートのコーディング

- 21.1.1 属性のデータ型

- 21.1.2 文字列フィールドの編集可能化

- 21.1.2.1 <insite:edit/>タグのバリアント

- 21.1.3 テキスト・フィールドの編集可能化

- 21.1.4 日付フィールドの編集可能化

- 21.1.4.1 日付書式設定API

- 21.1.4.2 Webモードでの日付フィールの編集の有効化

- 21.1.5 バイナリ・フィールドの編集可能化

- 21.1.6 アセット・フィールドの編集可能化

- 21.1.6.1 アソシエーションの編集

- 21.1.6.2 親アセットの編集

- 21.1.7 数値フィールド

- 21.1.8 複数値フィールド

- 21.1.8.1 例1: 複数値テキスト・フィールドの編集

- 21.1.8.2 例2: 複数値テキスト・フィールドの変更

- 21.1.8.3 異なる順序の指定

- 21.1.8.4 モードの編集とキャッシング

- 21.2 プレゼンテーション編集用テンプレートのコーディング

- 21.2.1 Webページ全体に対する異なるレイアウトの選択

- 21.2.2 ページ・フラグメントに対する異なるレイアウトの選択

- 21.2.2.1 プレゼンテーション編集用のスロットの定義

- 21.2.2.2 スロット・タイトルの調整

- 21.2.2.3 テンプレート引数の管理

- 21.2.3 プレゼンテーションとコンテンツの同時編集

- 21.2.3.1 コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの理解

- 21.2.3.2 コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの組合せ

- 21.2.4 コンテキスト・システム変数の理解

- 21.2.4.1 スロットの有効範囲の定義について

- 21.2.4.2 動作中のコンテキスト変数の使用方法

- 21.2.4.3 コンテキスト値の初期化

- 21.2.4.4 コンテキストのオーバーライド

- 21.2.4.5 コンテキストのキャッシング

- 21.2.5 CSElementアセットとSiteEntryアセットによるスロットの使用

- 21.2.5.1 CSElementアセットを含むスロットの定義

- 21.2.5.2 CSElementアセットまたはSiteEntryアセットを使用するタイミング

- 21.2.5.3 適切な引数の定義について

- 21.2.5.4 ネストされたスロットの使用に関する考慮事項

- 21.2.6 アセット・タイプの制約

- 21.2.7 CSSとJavaScriptの競合回避

- 21.3 Webモードでのコンテンツ作成の有効化

- 21.3.1 コンテンツ内作成用のスタート・メニューの定義

- 21.3.2 コンテキスト内作成用のレイアウト・テンプレートの提供

- 21.3.2.1 スタイルシートの調整

- 21.3.2.2 スロット用のスタイルシート調整

- 21.3.3 空の値インジケータの提供

- 21.3.4 編集固有のプレゼンテーション・ロジックの提供

22 ベーシック・アセットのテンプレート・エレメント例

- 22.1 ベーシック・モジュラ・デザインの作成

- 22.1.1 Homeエレメント

- 22.1.2 MainStoryListエレメント

- 22.1.3 LeadSummaryエレメント

- 22.1.4 TeaserSummaryエレメント

- 22.1.5 LeadSummaryの再開

- 22.1.6 MainStoryListの再開

- 22.1.7 Homeの再開

- 22.2 コレクション・アセット内の記事アセットへのリンクのコーディング

- 22.2.1 SectionFrontエレメント

- 22.2.2 PlainListエレメント

- 22.3 ct変数の使用

- 22.3.1 SectionFrontエレメント

- 22.3.2 TextOnlyLinkエレメント

- 22.3.3 ColumnistFront

- 22.4 問合せアセットのテンプレートのコーディング

- 22.4.1 Homeエレメント

- 22.4.2 WireFeedBoxエレメント

- 22.4.3 ExecuteQueryエレメント

- 22.4.4 WireFeedBoxの再開

- 22.5 テンプレートを使用しない記事アセットの表示

- 22.5.1 Fullエレメント

- 22.5.2 AltVersionBlockエレメント

- 22.5.3 EmailFrontエレメント

- 22.6 サイト・ナビゲーション情報の表示

- 22.6.1 Homeエレメント

- 22.6.2 SiteBannerエレメント

- 22.6.3 TopSiteBarエレメント

- 22.6.3.1 「Home」ページのリンクの作成

- 22.6.3.2 「Home」ページの子ページへのリンクの作成

- 22.6.4 SiteBannerの再開

- 22.7 アセット以外の情報の表示

- 22.7.1 Homeエレメント

- 22.7.2 ShowMainDateエレメント

23 コレクション・アセット、問合せアセットおよびページ・アセットの作成

- 23.1 アセットの作成について

- 23.2 コレクション・アセットの作成

- 23.2.1 開始する前に

- 23.2.2 コレクション・アセットの作成

- 23.2.3 コレクション・アセットの共有

- 23.3 問合せアセットの作成

- 23.3.1 問合せアセットとその他のアセットの使用方法

- 23.3.2 問合せの格納方法

- 23.3.3 問合せ用の一般的なフィールド

- 23.3.4 問合せアセットの作成を開始する前に

- 23.3.5 問合せアセットの作成

- 23.3.6 問合せアセットの共有

- 23.3.7 問合せアセットのプレビューと承認

- 23.4 ページ・アセットの作成

- 23.4.1 ページ・アセット・モデルの理解

- 23.4.2 ページ属性の設計方法

- 23.4.3 ページ・アセットの作成方法

- 23.4.4 ページ・アセットの配置方法

- 23.4.5 サイト・ツリー内でのページ・アセットの移動方法

- 23.4.5.1 子ページの並替え

- 23.4.5.2 親ページの変更

- 23.4.6 ページ・アセットとワークフローの配置に関する考慮事項

- 23.4.7 ページ・アセットの編集に関するヒント

- 23.4.8 ページ・アセットの削除に関する考慮事項

24 将来サイト・プレビュー・アセットおよびテンプレートを作成するためのベスト・プラクティス

- 24.1 将来サイト・プレビューの実装について

- 24.2 一連のアセットの作成

- 24.3 将来サイト・プレビューのテンプレートの作成

- 24.3.1 asset:filterassetsbydateタグ

- 24.3.2 入力リスト

- 24.4 キャッシングに関する考慮事項

25 多言語サポートのサイトの構成

- 25.1 多言語サポートのサイトの構成について

- 25.1.1 ディメンション

- 25.1.2 ディメンション・セット

- 25.1.3 サイト間の多言語サポート

- 25.1.4 マスター・アセット、翻訳および多言語セット

- 25.1.5 翻訳およびアセット関係

- 25.1.6 承認依存性

- 25.2 ロケール・フィルタリングでの作業

- 25.2.1 ロケール・フィルタリングによるアセット関係の実装のオプション

- 25.2.2 含まれるロケール・フィルタの理解

- 25.2.2.1 簡易フィルタ

- 25.2.2.2 簡易参照フィルタ

- 25.2.2.3 階層フィルタ

- 25.2.3 カスタム・ロケール・フィルタの使用について

- 25.2.4 構成依存性の説明

- 25.2.4.1 アセットの検索連鎖

- 25.2.4.2 キャッシング・ルール

- 25.2.5 サイトへのフィルタリング・サポートの追加について

- 25.2.5.1 テンプレートへのフィルタリングの追加について

- 25.2.5.2 訪問者のロケール・プリファレンスの取得と保持について

- 25.2.5.3 検索結果のフィルタ処理について

- 25.3 サイトに対する多言語サポートの計画

- 25.4 サイトに対する多言語サポートの構成

- 25.4.1 構成のクイック・リファレンス

- 25.4.2 「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプの有効化

- 25.4.3 「ディメンション」アセット・タイプの「ロケール」サブタイプの有効化

- 25.4.4 ロケールの作成方法

- 25.4.5 別のサイトでのロケールの共有方法

- 25.4.6 ディメンション・セットの作成と構成方法

- 25.4.7 別のサイトでのディメンション・セットの共有方法

- 25.4.8 ロケール・フィルタの構成方法

- 25.4.9 階層フィルタのフォールバック階層の構成方法

- 25.4.10 デフォルト・ロケールのサイト内アセットへの一括割当て方法

- 25.4.10.1 デフォルト・ロケールの一括割当て用サンプル・エレメント・コード

- 25.5 WebCenter Sites翻訳メカニズムの使用のヒント

- 25.5.1 顧客が希望すること

- 25.5.2 顧客の要件を効率的に満たすためのWebCenter Sites翻訳メカニズムの使用

第IV部 モバイル用Webサイトの開発

26 モバイルWebサイトをサポートするためのWebCenter Sitesの構成

- 26.1 開発者の前提条件

- 26.2 主要なMobilityの概念の理解

- 26.2.1 デバイス・リポジトリについてy

- 26.2.2 デバイス・グループおよび接尾辞について

- 26.2.3 デバイス・アセットについて

- 26.2.4 サイト・ナビゲーションについて

- 26.2.5 モバイル・テンプレートについてs

- 26.3 Mobility機能を構成するための前提条件

- 26.4 Mobility機能の構成

- 26.4.1 デバイス・リポジトリの構成方法

- 26.4.2 デバイス・グループ基準に対するカスタム・フィルタの作成方法

- 26.4.2.1 WebCenter Sitesに付属するデフォルトのDefaultCustomFIlter.javaカスタム・フィルタの使用

- 26.4.2.2 独自のDeviceGroupFilter実装の作成

- 26.4.3 デバイス・リポジトリのアクティブ化方法

- 26.4.4 デバイス・グループの構成方法

- 26.4.5 デバイス・グループの優先順位付け方法

- 26.4.6 デバイス・アセットの作成方法

- 26.4.7 サイト・ナビゲーションの作成方法

- 26.4.8 サイト・ナビゲーションの編成方法

- 26.5 配信システムへのデバイス・リポジトリのミラー・パブリッシュ

- 26.6 テンプレートの作成

- 26.6.1 テンプレート・バリアントを作成するための基本ガイドライン

- 26.6.2 Mobilityタグの理解

- 26.6.3 デバイス検出とページ・レンダリングをサポートするために変更されるタグ

- 26.6.4 テンプレート・バリアントを作成するための基本ガイドライン

- 26.6.4.1 単一のテンプレートのバリアントの作成方法

- 26.6.4.2 テンプレート・バリアントのバルク作成方法

- 26.7 モバイルWebサイトのイメージの最適化

- 26.7.1 イメージ最適化フィルタを使用したイメージの最適化方法

- 26.7.1.1 ImageOptimizationFilterタイプのフレックス・フィルタの作成

- 26.7.1.2 サイトのイメージ定義へのフィルタの追加

- 26.7.1.3 blobタイプ属性アセットのインスタンスの作成

- 26.7.1.4 最適化用のイメージ・プロパティの設定

- 26.7.1.5 既存のイメージへのイメージ最適化フィルタの適用

- 26.7.1.6 イメージ最適化フィルタが適用されているかどうかの確認

- 26.7.1.7 サイトでの最適化されたイメージの使用

- 26.7.2 プラガブル・インタフェースを使用したイメージの最適化方法

- 26.8 デバイス検出の仕組み

第V部 Developer Toolsを使用したコーディング

27 Developer Toolsについて

- 27.1 IDeveloper Toolsアーキテクチャの概要

- 27.2 IIDE統合

- 27.3 Developer Toolsワークスペース

- 27.4 WebCenter Sitesインスタンスへの接続

- 27.5 同期

- 27.6 JSPの管理

- 27.7 コマンドライン・ツール

- 27.8 バージョン・コントロール・システムの使用について

28 Developer Toolsのインストールと構成

- 28.1 前提条件

- 28.2 Developer Toolsの設定

- 28.2.1 Developer Toolsプラグインのインストール方法

- 28.2.2 Developer Toolsプラグインのインストールを確認する方法

- 28.2.3 WebCenter SitesとEclipse IDEを統合する方法E

- 28.2.4 リモート・ホストでコード補完を有効にする方法E

- 28.2.5 Developer Toolsを使用して既存のリソースを操作する方法

- 28.2.6 WebCenter Sitesリソースを管理する方法

- 28.2.7 Eclipseで既存のプロジェクトを使用する方法

- 28.3 Developer Toolsの更新

- 28.3.1 Developer Toolsプラグインの場所を更新する方法

- 28.3.2 既存のプラグインの更新のチェック方法

- 28.3.3 Developer Toolsプラグインが更新されていることを確認する方法

- 28.4 EclipseでのWebCenter Sitesリソースの管理

- 28.4.1 リソースの作成方法

- 28.4.2 Developer Toolsビューをパネルに表示する方法

- 28.4.3 WebCenter SitesとDeveloper Toolsの間でデータをエクスポートおよびインポートする方法

- 28.5 Developer Toolsのアンインストール

29 EclipseのDeveloper Toolsの概要

- 29.1 「Oracle WebCenter Sites」パースペクティブについて

- 29.2 構成フォームの理解

- 29.3 Eclipseのプロジェクトとワークスペースの理解

- 29.4 Developer Toolsのビューについて

- 29.4.1 ワークスペース

- 29.4.2 ログ・ビューア

- 29.4.3 テンプレート・ビュー

- 29.4.4 プレビュー・ビュー

- 29.4.5 Sitesビュー

- 29.4.6 Controllerビュー

- 29.4.7 ロギング構成ビュー

- 29.4.8 開発者参照ビュー

- 29.4.9 ウィザード

- 29.5 データ同期(エクスポート/インポート)ツール

- 29.5.1 エクスポート(WebCenter Sitesからワークスペースにリソースを同期)

- 29.5.2 インポート(ワークスペースからWebCenter Sitesにリソースを同期)

30 Developer Toolsを使用したJSPの開発

- 30.1 Developer Toolsを使用したJSPの開発

- 30.2 タグおよびJava APIの補完

- 30.3 デバッグ

31 Developer Toolsを使用したモバイルWebサイト用テンプレートの作成

- 31.1 Developer ToolsのMobilityサポートについて

- 31.2 サイト・ワークスペース・タブからのモバイル・テンプレートの作成

- 31.3 サイトおよびデバイス・グループ・ビューでのモバイル・テンプレートの作成

32 Developer Toolsを使用した同期および交換

- 32.1 Developer Toolsを使用した同期

- 32.2 同期シナリオ

- 32.3 依存性の解決について

- 32.4 IDマッピング

- 32.4.1 IDマッピングについて

- 32.4.2 リソースのfw_uidのオーバーライド

- 32.4.3 既存のリソースとDeveloper Toolsの併用について把握すべき内容

- 32.5 サイト・マッピングの使用

- 32.5.1 ナチュラル・サイト・マッピングについて

- 32.5.2 コマンドライン・ツールを使用したナチュラル・サイト・マッピングのオーバーライドについて

33 Developer Toolsのワークスペースの使用

- 33.1 ワークスペースの概要

- 33.2 ワークスペースの構造

- 33.3 アセット記憶域の構造

- 33.4 コード・ベースのリソース記憶域の構造

- 33.5 属性エディタ記憶域の構造

- 33.6 アセット・タイプ記憶域の構造

34 Developer Toolsコマンドライン・ツールの使用

- 34.1 コマンドライン・ツールの実行と使用

- 34.2 コマンド例

- 34.3 モジュールのインポートについて

35 Developer Toolのワークスペースとバージョン・コントロール・システムとの統合

- 35.1 バージョン・コントロールとDeveloper Toolsについて

- 35.2 Developer ToolsとVCSの統合について

- 35.3 Developer Toolsが統合されたVCSの使用: 例

36 Developer Toolsを使用したリソースの管理および交換

- 36.1 今日: サイトおよび関連付けられたリソースの開発

- 36.2 3日後...デプロイメント

37 Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成

- 37.1 再利用可能なモデルの作成

- 37.2 WebCenter Sitesインスタンスでのリソースのリスト

- 37.3 スタート・メニュー・アイテムのリスト

- 37.4 ワークスペースへのすべてのリソースのエクスポート

- 37.5 モジュールのコンテンツの調査

- 37.6 モジュールのアーカイブ

- 37.7 WebCenter Sitesインスタンスへのモジュールのインポート

第VI部 キャッシングの管理

38 ページのデザインとキャッシングの理解

- 38.1 モジュラ・ページ・デザインについて

- 38.2 キャッシングについて

- 38.2.1 WebCenter Sitesのキャッシング

- 38.2.2 BlobServerとキャッシング

- 38.2.3 Satellite Serverのキャッシング

- 38.2.3.1 キャッシュの有効期限

- 38.2.3.2 Satelliteサーブレットを使用したキャッシング

- 38.2.3.3 Satellite Serverキャッシュのコンテンツの表示

- 38.2.3.3.1 CacheManager

- 38.2.3.3.2 SiteCatalog表

- 38.2.3.3.3 キャッシュ・キー

- 38.2.3.3.4 キャッシング・プロパティ

- 38.2.3.3.5 ページ・キャッシング・プロパティ

- 38.2.3.3.6 Satellite Serverのプロパティ

- 38.3 二重バッファ・キャッシング

- 38.3.1 二重バッファ・キャッシングの実装について

- 38.3.1.1 ページレットのキャッシュ戦略

- 38.3.2 cscacheinfoの設定

- 38.3.3 キャッシングのためのコーディング

- 38.3.4 キャッシングとセキュリティ

- 38.3.4.1 WebCenter Sitesのセキュリティ

- 38.3.4.2 Satellite Serverのセキュリティ

39 結果セットのキャッシングと問合せでの作業

- 39.1 結果セットのキャッシングと問合せについて

- 39.2 キャッシング・フレームワーク

- 39.3 データベース問合せ

- 39.4 結果セットのキャッシングの仕組み

- 39.5 データベースのロードの削減

- 39.6 表名の指定

- 39.6.1 SELECTTO

- 39.6.2 EXECSQL

- 39.6.3 CALLSQL

- 39.6.4 WebCenter Sitesインタフェースのフォームの検索

- 39.6.5 問合せアセット

- 39.6.6 SEARCHSTATE

- 39.7 結果セットのキャッシュのフラッシュ

- 39.8 キャッシング・フレームワーク間の切替え

- 39.9 結果セットのキャッシングの戦略およびプロパティについて

- 39.9.1 結果セットのキャッシング戦略の計画作成

- 39.9.2 デフォルト・プロパティ

- 39.9.3 表固有のプロパティ

40 WebCenter Sitesでのキャッシュ管理の使用

- 40.1 WebCenter Sitesのレンダリング・エンジン・キャッシュについて

- 40.2 CacheManagerについて

- 40.3 CacheManagerの有効化

- 40.3.1 第1層のキャッシュ構成プロパティ

- 40.3.2 第2層のキャッシュ構成プロパティ

41 ページ・キャッシングの高度な手法の使用

- 41.1 高度なページ・キャッシングについて

- 41.2 WebCenter Sitesキャッシュの構成

- 41.2.1 キャッシュの最大サイズの構成

- 41.2.2 個々のエントリの有効期限の設定

- 41.2.3 キャッシュからのエントリの明示的削除

- 41.2.3.1 手動削除

- 41.2.3.2 自動削除

- 41.3 BlobServerキャッシュの構成

- 41.3.1 最大キャッシュ・サイズの構成に関する考慮事項

- 41.3.2 個々のエントリの有効期限の設定

- 41.3.3 キャッシュからのエントリの明示的削除

- 41.3.3.1 手動削除

- 41.3.3.2 自動削除

- 41.4 Satellite Serverキャッシュの構成

- 41.4.1 キャッシュの最大サイズの構成

- 41.4.2 キャッシュからのエントリの明示的削除

- 41.5 CacheInfo文字列の構文

- 41.6 キャッシングのベスト・プラクティス

- 41.6.1 ページ当たりのページレット数の削減

- 41.6.2 ページ間でのキャッシュの共有

第VII部 コンテンツ管理システムへの作業内容の移行

42 任意タイプのアセットのインポート

- 42.1 XMLPostユーティリティを使用したアセットのインポートについて

- 42.1.1 開発者が実行する手順

- 42.1.2 XMLPostとWebCenter Sitesが実行する処理

- 42.2 XMLPost構成ファイルの使用

- 42.2.1 XMLPostの構成プロパティ

- 42.2.2 ポスト・エレメントの構成プロパティ

- 42.2.3 ソース・ファイルの構成プロパティ

- 42.2.3.1 サイトのプロパティ

- 42.2.3.2 アセット・タイプのプロパティ

- 42.2.4 XMLPostのサンプル構成ファイル

- 42.3 XMLPostソース・ファイルの使用

- 42.3.1 XMLPostのサンプル・ソース・ファイル

- 42.3.2 XMLPostとファイル・エンコード方式

- 42.4 XMLPostユーティリティの使用

- 42.4.1 開始する前に

- 42.4.2 コマンドラインからのXMLPostの実行

- 42.4.3 ソース・ファイルの識別

- 42.4.3.1 単一のファイル

- 42.4.3.2 ファイルのディレクトリ

- 42.4.3.3 リスト・ファイル

- 42.4.4 バッチ・プロセスとしてのXMLPostの実行

- 42.4.5 プログラムからのXMLPostの実行

- 42.5 RemoteContentPostとPreUpdateのカスタマイズ

- 42.5.1 プログラムによるフィールド値の設定

- 42.5.2 アセットのアソシエーションの設定

- 42.6 XMLPostのトラブルシューティング

- 42.6.1 XMLPostが実行されず、ログ・ファイル・メッセージが作成されない

- 42.6.2 XMLPostでエラーが発生して、ログ・ファイルにエンティティの欠落というメッセージが記録されている

- 42.6.3 XMLPostがアセットを保存しようとするとエラー105が発生する

- 42.6.4 ポスト・エレメントのデバッグ

43 フレックス・アセットのインポート

- 43.1 フレックス・アセットのインポートについて

- 43.1.1 データ構造フレックス・アセット・タイプのインポートを開始する前に

- 43.1.2 フレックス・アセットのインポートについて

- 43.1.2.1 BulkLoaderを使用する場合

- 43.1.2.2 XMLPostを使用する場合

- 43.1.3 フレックス・アセットのインポートのプロセスの概要

- 43.1.4 カスタムのデータ・デリミタについて

- 43.2 XMLPostとフレックス・アセット・モデルの理解

- 43.3 フレックス・モデル内の構造アセット・タイプのインポートについて

- 43.3.1 属性エディタ

- 43.3.1.1 サンプル構成ファイル: 属性エディタ

- 43.3.1.2 サンプル・ソース・ファイル: 属性エディタ

- 43.3.2 フレックス属性

- 43.3.2.1 サンプル構成ファイル: フレックス属性

- 43.3.2.2 サンプル・ソース・ファイル: 属性

- 43.3.3 フレックス定義とフレックス親定義: サンプル・ファイル

- 43.3.3.1 サンプル構成ファイル: フレックス定義

- 43.3.3.2 サンプル・ソース・ファイル: フレックス定義

- 43.3.4 フレックス親

- 43.3.4.1 サンプル構成ファイル: 個別のフレックス親

- 43.3.4.2 サンプル・ソース・ファイル: 個別のフレックス親

- 43.4 XMLPostを使用したフレックス・アセットのインポート

- 43.4.1 フレックス・アセットの構成ファイル・プロパティとソース・ファイル・タグ

- 43.4.1.1 addDataポスト・エレメントの場合

- 43.4.1.2 RemoteContentPostポスト・エレメントの場合

- 43.4.2 addDataのサンプル・フレックス・アセット構成ファイル

- 43.4.3 構成ファイル・プロパティとBLOB (またはURL)型の属性

- 43.4.3.1 アップロード・フィールドとしてのBLOB (またはURL)型の属性

- 43.4.3.2 テキスト・フィールドとしてのBLOB (またはURL)型の属性

- 43.4.4 addDataのサンプル・フレックス・アセット・ソース・ファイル

- 43.4.4.1 サンプル・ファイル

- 43.4.4.2 特殊文字の処理

- 43.4.4.3 フレックス・アセットとそれらの親

- 43.4.4.4 フレックス・アセットの親の指定

- 43.4.4.5 親の属性値の設定

- 43.4.4.6 フレックス・ソース・ファイル内の複数値の設定

- 43.4.5 RemoteContentPostのサンプル・フレックス・アセット構成ファイル

- 43.4.6 RemoteContentPostのサンプル・フレックス・アセット・ソース・ファイル

- 43.5 XMLPostを使用したフレックス・アセットの編集

- 43.5.1 フレックス・アセットを編集するための構成ファイル

- 43.5.2 フレックス・アセットを編集するためのソース・ファイル

- 43.5.2.1 属性の値の変更

- 43.5.2.2 属性値の削除

- 43.5.2.3 親関係の編集

- 43.6 XMLPostを使用したアセットの削除

- 43.6.1 アセットを削除するための構成ファイル

- 43.6.2 アセットを削除するためのソース・ファイル

44 BulkLoaderユーティリティによるフレックス・アセットのインポート

- 44.1 BulkLoaderユーティリティについて

- 44.1.1 BulkLoader機能の理解

- 44.1.2 BulkLoaderの仕組み

- 44.1.3 BulkLoaderユーティリティの使用について

- 44.1.4 フラット表からのフレックス・アセットのインポート

- 44.1.4.1 基本手順

- 44.1.4.2 ドライバ要件

- 44.1.4.3 DB2の要件

- 44.1.5 XMLPostを使用して構造アセットをインポートするタイミング

- 44.1.6 入力表(データソース)の作成

- 44.1.6.1 挿入

- 44.1.6.2 更新

- 44.1.7 マッピング表の作成

- 44.1.8 BulkLoader構成ファイルの作成

- 44.1.8.1 BulkLoader構成ファイルのプロパティ

- 44.1.8.2 initIDパラメータの設定

- 44.1.8.3 構成ファイルの例

- 44.1.9 BulkLoaderユーティリティの実行

- 44.1.10 Contributorインタフェースでのインポート済アセットへのアクセスの有効化

- 44.1.11 フィードバック情報の確認

- 44.1.12 アセットの承認と配信システムへのパブリッシュ

- 44.2 カスタム抽出メカニズムを使用したフレックス・アセットのインポート

- 44.2.1 IDataExtractインタフェース

- 44.2.2 IPopulateDataSlice

- 44.2.3 IFeedbackインタフェース

- 44.3 BulkApproverユーティリティによるフレックス・アセットの承認

- 44.3.1 BulkApproverの構成

- 44.3.2 BulkApproverの使用

第VIII部 セキュリティ: コンテンツ管理ユーザーの管理

45 管理システムのユーザーの管理

- 45.1 ディレクトリ・サービスAPIについて

- 45.1.1 エントリ

- 45.1.2 階層

- 45.1.3 グループ

- 45.1.4 ディレクトリ・サービス・タグ

- 45.1.5 ディレクトリの操作

- 45.1.5.1 検索

- 45.1.5.2 ユーザーの検索

- 45.1.5.3 ユーザーのリスト作成

- 45.1.5.4 ディレクトリ・サービスのコード・サンプル

- 45.1.6 エラー処理

- 45.1.7 ディレクトリ・サービス・アプリケーションのトラブルシューティング

- 45.2 ユーザー・アクセスの制御

- 45.2.1 ACLタグ

- 45.2.2 USERタグ

- 45.2.3 WebCenter Sitesおよび暗号化

第IX部 サイトのパブリッシュ

46 コンテンツ管理サイトをオンラインで使用可能にするためのパブリッシ

第X部 Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発

47 訪問者データ・アセットの作成

- 47.1 訪問者データ・アセットについて

- 47.1.1 訪問者属性

- 47.1.2 履歴属性と履歴定義

- 47.1.3 セグメント

- 47.1.4 訪問者データ・アセットの開発: プロセスの概要

- 47.2 訪問者データ・アセットの作成

- 47.2.1 訪問者属性の作成

- 47.2.1.1 データ型の構成

- 47.2.1.2 制約基準の構成

- 47.2.1.3 属性の保存

- 47.2.2 履歴属性の作成

- 47.2.2.1 制約基準の構成

- 47.2.2.2 履歴属性の保存

- 47.2.3 履歴定義の作成

- 47.3 訪問者データ・アセットの確認

- 47.4 訪問者データ・アセットの承認

48 推奨アセットの理解

- 48.1 推奨アセットについて

- 48.2 推奨の設定の開発プロセス

- 48.3 動的リスト・エレメントの作成について

49 メモリー中心の訪問者追跡の使用

- 49.1 メモリー中心の訪問者追跡

- 49.1.1 データベース中心のモデル

- 49.1.2 メモリー中心のモデル

- 49.2 メモリー中心の訪問者追跡の有効化

- 49.2.1 訪問者追跡のプロパティ

- 49.2.2 サポート・コード

- 49.2.3 バッチを使用したデータベースへの履歴属性の保存

- 49.3 メモリー中心の訪問者追跡の機能

- 49.3.1 訪問者の検出

- 49.3.2 スカラー値の取得

- 49.3.3 履歴属性値の収集

- 49.3.4 合計および数の計算

- 49.3.5 セグメントの計算

- 49.3.6 推奨されるアセットの表示

- 49.3.7 依存性の記録

50 Engageページのコーディング

- 50.1 商用コンテキストおよび訪問者コンテキスト

- 50.2 訪問者の識別およびセッションのリンク

- 50.3 訪問者データの収集

- 50.4 訪問者データを収集するサイト・ページのコーディング

- 50.4.1 例1: 訪問者属性

- 50.4.2 例2: 履歴定義

- 50.4.3 例3: バイナリ・タイプの訪問者属性

- 50.5 テンプレートおよび推奨

- 50.5.1 推奨のテンプレートの作成

- 50.5.2 Oracle Real-Time Decisionsを使用した推奨のテンプレートの作成

- 50.6 ショッピング・カートおよびEngageについて把握する必要がある内容

- 50.7 サイト・ページのデバッグ

- 50.7.1 セッション・リンク

- 50.7.2 訪問者データの収集

- 50.7.3 推奨およびプロモーション

第XI部 A/B Testingの実行

51 A/B Testingの開発

- 51.1 A/B Testingの要件

- 51.2 A/B Testingのスクリプト・テンプレート

- 51.3 A/B Testingのキャッシュ基準の更新

- 51.4 JSONとしてのA/Bテストの詳細の表示

- 51.5 確信度アルゴリズムの理解

第XII部 ブログのカスタマイズ

52 ブログ・コンポーネントのカスタマイズ

- 52.1 ブログ・アセット・フォームのカスタマイズ

- 52.1.1 ブログ属性の作成

- 52.1.2 ブログ・アセット定義へのブログ属性の追加

- 52.2 CMサイトへのブログ機能の追加

- 52.2.1 ブログ・ページの作成

- 52.2.2 ブログ・コードの追加

- 52.2.3 サイトのSiteEntryアセットへのブログ・パラメータの追加

- 52.3 RSSフィードのURLのカスタマイズ

第XIII部 WebCenter Sites: Visitor Servicesの開発

53 WebCenter Sites: Visitor Servicesの開発

- 53.1 Visitor Servicesの概要

- 53.2 Visitor Services URLの構成

- 53.3 アイデンティティ・プロバイダの構成

- 53.3.1 アイデンティティ・プロバイダ設定の構成

- 53.3.2 Oracle Access Manager (OAM)とVisitor Servicesの統合

- 53.3.3 カスタム・アイデンティティ・プロバイダの作成: 例

- 53.4 アクセス・プロバイダの構成

- 53.5 1つ以上のプロファイル・プロバイダの構成

- 53.5.1 プロファイル・プロバイダ設定およびエンリッチメント・ルールの構成

- 53.5.1.1 Eloquaプロファイル・プロバイダの構成について

- 53.5.2 カスタム・プロファイル・プロバイダの作成: 例

- 53.6 1つ以上の集計テンプレートの作成

- 53.7 Visitor Servicesデータを使用した操作性の最適化

- 53.7.1 WebCenter SitesコンポーネントでのVisitor Servicesプロファイル情報のリクエスト方法

- 53.7.2 EngageでのVisitor Servicesの構成

- 53.7.3 訪問者プロファイルのリンク付けおよびCookieの管理

- 53.7.4 拡張属性およびアクティビティの追加情報の格納

- 53.7.4.1 拡張属性およびアクティビティについて

- 53.7.4.2 Visitor Servicesで拡張属性およびアクティビティを使用する方法

- 53.8 Visitor Servicesリファレンス

- 53.8.1 Visitor Servicesアーキテクチャについて

- 53.8.2 Iアイデンティティ・プロバイダ・リファレンス

- 53.8.2.1 アイデンティティ・プロバイダについて

- 53.8.2.2 Visitor ServicesがWebサイトの訪問者を識別する方法

- 53.8.3 アクセス・プロバイダ・リファレンス

- 53.8.3.1 コンテナ保護およびVisitor Services保護について

- 53.8.3.2 コンテナ保護の仕組み

- 53.8.3.3 Visitor Services保護の仕組み

- 53.8.4 プロファイル・プロバイダ・リファレンス

- 53.8.4.1 プロファイル・プロバイダおよびエンリッチメント・サービスについて

- 53.8.4.1.1 プロファイル・プロバイダ

- 53.8.4.1.2 エンリッチメント・サービス

- 53.8.4.1.3 プロファイル・プロバイダおよびエンリッチメント・サービスの仕組み

- 53.8.4.2 Visitor Servicesが訪問者属性を複数のチャネルから収集およびエンリッチする仕組み

- 53.8.5 集計テンプレート・リファレンス

- 53.8.5.1 集計テンプレートについて

- 53.8.5.1.1 集計サービスの仕組み

- 53.8.5.2 Visitor Servicesが未加工の訪問者プロファイルを単一の集計済プロファイルにマージする仕組み

- 53.8.5.3 Visitor Servicesが集計済訪問者プロファイルをターゲット設定、テストおよび分析に使用できるようにする仕組み

- 53.8.6 Visitor Servicesデータ・モデルについて

- 53.8.7 用語集

第XIV部 サイト・キャプチャ・プロセスの制御

54 クローラ構成ファイルのコーディング

- 54.1 クローラの制御について

- 54.2 BaseConfiguratorのメソッド

- 54.2.1 getStartUri

- 54.2.2 createLinkExtractor

- 54.3 クローラのカスタマイズ・メソッド

- 54.3.1 getMaxLinks

- 54.3.2 getMaxCrawlDepth

- 54.3.3 getConnectionTimeout

- 54.4 getSocketTimeout

- 54.5 getPostExecutionCommand

- 54.6 getNumWorkers

- 54.7 getUserAgent

- 54.8 createResourceRewriter

- 54.9 createMailer

- 54.10 getProxyHost

- 54.11 getProxyCredentials

- 54.12 インタフェース

- 54.12.1 LinkExtractor

- 54.12.1.1 LinkExtractorインタフェース

- 54.12.1.2 LinkExtractorのデフォルト実装の使用

- 54.12.1.3 カスタム・リンク・エクストラクタの作成とデプロイ

- 54.12.2 ResourceRewriter

- 54.12.2.1 ResourceRewriterインタフェース

- 54.12.2.2 ResourceRewriterのデフォルト実装の使用

- 54.12.2.3 カスタムResourceRewriterの作成

- 54.12.3 Mailer

- 54.12.3.1 Mailerインタフェース

- 54.12.3.2 Mailerのデフォルト実装の使用

- 54.12.3.3 カスタムMailerの作成

- 54.13 メソッドとインタフェースの概要

- 54.13.1 メソッド

- 54.13.2 インタフェース

第XV部 サードパーティ・コンテンツ・ソースとの統合

55 プロキシ・アセットを使用したサードパーティ・コンテンツ・ソースの統合

- 55.1 プロキシ・アセットのアーキテクチャおよびContributorインタフェース

- 55.2 サンプル・プロキシ・アセットのインストール

- 55.2.1 プロキシ・アセット・ディレクトリの設定y

- 55.2.2 プロキシ・アセットの作成

- 55.2.3 プロキシ・アセットへの検索機能の追加

- 55.2.4 プロキシ・アセットへのサムネイル・グリッド機能の追加

- 55.2.5 プロキシ・アセットへのツリー機能の追加

- 55.3 Contributorインタフェースの外部コンテンツの統合

- 55.3.1 事例: ProxyTestリポジトリ

- 55.3.2 新しいプロキシ・アセット・タイプの登録

- 55.3.3 UI統合コードの実装について

- 55.3.4 検索のカスタマイズ

- 55.3.4.1 提供済のサード・パーティAPIを使用した検索結果の取得

- 55.3.4.2 検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集

- 55.3.4.3 グリッド・ウィジェット用のデータ・ストアの作成

- 55.3.4.4 カスタム検索のテスト

- 55.3.4.5 追加のカスタマイズ

- 55.3.5 カスタム・ツリーの実装

- 55.3.5.1 カスタム・ツリー・タブの登録

- 55.3.5.2 ツリーのコードの実装

- 55.4 YouTubeプロキシ・アセットの設定

- 55.5 ユーザー・インタフェースのカスタマイズ

- 55.5.1 検索スタート・メニューのカスタマイズ

- 55.5.2 コンテンツ・ツリーのカスタマイズ

- 55.6 Webページへのプロキシ・アセットの埋込みについて

- 55.6.1 プロキシ・アセット用テンプレートの作成

- 55.6.2 プロキシ・アセットのスロットでの使用

- 55.6.3 プロキシ・アセットのキャッシングについて

第XVI部 Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発

56 Webエクスペリエンス管理(WEM)フレームワークについて

- 56.1 WEMフレームワークについて

- 56.2 アプリケーション開発の前提条件

- 56.2.1 テクノロジ

- 56.2.2 WebCenter Sitesインタフェース、オブジェクトおよびAPI

- 56.2.3 ドキュメントDocumentation

- 56.2.4 サンプル・アプリケーションおよびファイル

- 56.2.5 アプリケーション・アクセス

- 56.3 はじめに

57 WEMフレームワークとサービスの理解

- 57.1 アプリケーション開発のサポート

- 57.2 RESTサービス

- 57.3 UIコンテナ

- 57.3.1 登録

- 57.3.2 WEMコンテキスト・オブジェクト

- 57.4 シングル・サインオン

- 57.5 認可モデル

- 57.6 カスタム・アプリケーション

- 57.7 RESTリソースの要件

58 Articlesサンプル・アプリケーションでの作業

- 58.1 Articlesサンプル・アプリケーションについて

- 58.2 Articlesサンプル・アプリケーションの起動

- 58.2.1 Articlesアプリケーションのビルドおよびデプロイ

- 58.2.2 Articlesサンプル・アプリケーションの登録

- 58.3 Articlesアプリケーションのテスト

59 WEMフレームワークでのアプリケーションの開発

- 59.1 Articlesサンプル・アプリケーションの構造について

- 59.2 Articlesサンプル・アプリケーションの構成ファイルについて

- 59.3 RESTコールの実行

- 59.3.1 JavaScriptからのRESTコールの実行

- 59.3.2 JavaからのRESTコールの実行

- 59.4 バイナリ・データを処理するURLの作成

- 59.5 WEMフレームワークからのパラメータへのアクセス

- 59.5.1 サンプル・ドメイン内のコンテキスト・オブジェクトの初期化および使用

- 59.5.2 クロスドメイン・アプリケーションのコンテキスト・オブジェクトの初期化および使用

- 59.5.3 コンテキスト・オブジェクトで使用可能なメソッド

- 59.6 様々なビューを使用したアプリケーションの登録

- 59.6.1 iframeビューを使用したアプリケーションの登録

- 59.6.2 JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録

- 59.6.2.1 JavaScriptビューのレンダリング

- 59.6.2.2 HTMLビューのレンダリング

60 WEMフレームワークを使用したカスタムRESTリソースの開発

- 60.1 WebCenter SitesおよびSatellite Server用のRESTリソースの作成: 例

- 60.1.1 Recommendationsサンプル・アプリケーションのビルドおよびデプロイ

- 60.1.2 Recommendationsサンプル・アプリケーションのテスト

- 60.2 RESTリソースの作成

- 60.2.1 Recommendationsサンプル・アプリケーションの構造について

- 60.2.2 カスタムRESTリソースの実装

61 本番サイトでのシングル・サインオンの使用

- 61.1 SSOサンプル・アプリケーションのデプロイ

- 61.2 SSOサンプル・アプリケーションの構造の理解

- 61.3 シングル・サインオンの実装

- 61.4 シングル・サインアウトの実装

62 WEMフレームワークでのRESTリソースの使用

- 62.1 RESTリソースの認証

- 62.1.1 Javaコードからのチケットの取得

- 62.1.2 他のプログラミング言語からのチケットの取得(HTTPを経由)

- 62.1.3 チケットおよびマルチチケットの使用

- 62.1.4 スタンドアロン・アプリケーションのSSO構成

- 62.1.4.1 Beanおよびプロパティ

- 62.1.4.2 SSOフィルタで処理される問合せパラメータ

- 62.2 CASの構成について

- 62.3 REST認可

- 62.3.1 セキュリティ・モデル

- 62.3.2 RESTリソースへのセキュリティ・モデルを使用したアクセス

- 62.3.3 RESTセキュリティの構成について

- 62.3.4 権限解決アルゴリズム

- 62.4 RESTを介したアセットの管理

63 WEMフレームワークへのCustomizable Single Sign-Onファシリティの導入

- 63.1 WEMフレームワークのログイン動作のカスタマイズについて

- 63.2 デフォルトCSSO実装のコンポーネントについて

- 63.3 カスタムSSO動作の構成およびデプロイ

- 63.3.1 デフォルトCSSOクラスの拡張について

- 63.3.2 リゾルバ資格証明の設定

- 63.3.3 Springへのインスタンス化するJavaクラスの指定について

- 63.3.3.1 Spring構成ファイルの作成について

- 63.3.3.2 Spring構成ファイルの配置について

- 63.3.4 外部ユーザー識別子のWebCenter Sites資格証明へのマッピング

- 63.3.5 CAS Webアプリケーションの再起動

- 63.4 CSSOサンプル実装の実行

- 63.4.1 サンプルCSSOクラス

- 63.4.2 サンプルSpring構成ファイル

- 63.4.2.1 サンプルSpring構成ファイルの分析

- 63.4.2.2 サンプルSpring構成ファイルの配置

- 63.4.3 サンプルCSSOコンポーネント

64 WEMフレームワークでのバッファリング

- 64.1 バッファリング・システムのアーキテクチャ

- 64.2 バッファリングの使用

65 WEMフレームワークでのアプリケーションの手動登録

- 65.1 WEMフレームワークでのアプリケーションの登録

- 65.2 リファレンス: 登録アセット・タイプ

- 65.2.1 FW_Viewアセット・タイプ

- 65.2.2 FW_Applicationアセット・タイプ

第XVII部 Oracle WebCenter Sitesのカスタマイズ

66 Adminインタフェースのツリーのカスタマイズ

- 66.1 Adminインタフェースのツリーについて

- 66.1.1 ツリー・タブのロード

- 66.1.1.1 アプレット全体のパラメータ

- 66.1.1.2 ツリー固有のパラメータ

- 66.1.1.3 ノードのパラメータ

- 66.1.1.4 コマンド・ノードのコンテキスト・メニューの追加

- 66.1.2 ツリーのリフレッシュ

- 66.2 ツリーおよびセキュリティについて

- 66.3 ツリーのエラー・ロギングについて

67 Contributorインタフェースのコンポーネントのカスタマイズについて

- 67.1 開始する前に

- 67.2 Contributorインタフェースでカスタマイズできる内容

- 67.3 サンプル・コードの検索場所

- 67.4 開始する場所

68 Contributorインタフェース・フレームワークおよびUIコントローラの理解

- 68.1 AContributorインタフェース・フレームワークについて

- 68.2 UIコントローラ

- 68.2.1 UIコントローラでリクエストを処理する方法

- 68.2.2 エレメント・リクエストを処理するUIコントローラ: 例

- 68.3 カスタム・エレメント

- 68.3.1 エレメント・ストレージ

- 68.3.2 UIコントローラでエレメントを検索する方法

- 68.3.3 エレメントの命名規則

69 Contributorインタフェースのダッシュボードのカスタマイズ

- 69.1 ダッシュボードのカスタマイズについて

- 69.2 ダッシュボードのカスタマイズ

- 69.3 ダッシュボードのカスタマイズの例

- 69.3.1 Hello World'ウィジェットの追加

- 69.3.2 最近変更されたアセットを表示するウィジェットの追加

70 Contributorインタフェースの検索ビューのカスタマイズ

- 70.1 検索ビューのカスタマイズについて

- 70.1.1 検索ビューのタイプ

- 70.1.2 検索ビューでカスタマイズ可能な内容

- 70.1.3 ビューレンダリング・プロセス

- 70.1.4 検索ビューの構成エレメント

- 70.2 カスタマイズ・プロセス

- 70.3 ドッキングされていないビューのカスタマイズ

- 70.3.1 ドッキングされていないビューのカスタマイズの基本手順

- 70.3.2 デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

- 70.3.3 ドッキングされていないリスト表示のカスタマイズ

- 70.3.4 ドッキングされていないサムネイル表示のカスタマイズ

- 70.3.4.1 ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細

- 70.3.4.1.1 静的アイコンの使用

- 70.3.4.1.2 システム定義のイメージ・サムネイル・エレメントの再使用

- 70.3.4.1.3 カスタム・サムネイル・レンダリング・エレメントの使用

- 70.4 ドッキングされたビューのカスタマイズについて

- 70.5 ソート・メニューおよびツールチップのカスタマイズ

- 70.5.1 ソート・メニューのカスタマイズ

- 70.5.2 検索結果のツールチップのカスタマイズ

- 70.5.3 コンテキスト・メニューのカスタマイズ

71 Contributorインタフェースでのグローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ

- 71.1 グローバル構成プロパティのカスタマイズ

- 71.1.1 構成プロパティについて

- 71.1.2 変更可能なデフォルトの構成プロパティ

- 71.1.3 カスタム構成プロパティの追加

- 71.1.3.1 カスタム・グローバル・プロパティの追加

- 71.1.3.2 サイト固有のプロパティの追加

- 71.2 ツールバーのカスタマイズ

- 71.2.1 ツールバーのカスタマイズについて

- 71.2.2 ツールバー・カスタマイズの例

- 71.2.2.1 Webモード用の標準アクションを使用したツールバーのカスタマイズ

- 71.2.2.2 アセット・タイプおよびサブタイプ用の標準アクションを使用したツールバーのカスタマイズ

- 71.2.2.3 カスタム・アクションを使用したツールバーのカスタマイズ

- 71.3 メニュー・バーのカスタマイズ

- 71.3.1 メニュー・バーのカスタマイズについて

- 71.3.2 カスタム・アクションのメニュー・バーへの追加

- 71.4 コンテキスト・メニューのカスタマイズ

72 Contributorインタフェースのアセット・フォームのカスタマイズ

- 72.1 アセット・フォームのカスタマイズについて

- 72.2 アセット・フォームのヘッダーの変更

- 72.3 属性エディタの構築

- 72.3.1 Dojoウィジェットとそのテンプレートの作成

- 72.3.1.1 Dojoウィジェットのテンプレートの作成

- 72.3.1.2 Dojoウィジェットの作成

- 72.3.2 プレゼンテーション・オブジェクトとしての属性エディタの定義

- 72.3.3 属性エディタ・エレメントの作成

- 72.3.4 属性エディタの作成

- 72.3.5 複数値属性エディタの実装

73 ワークフローのカスタマイズ

- 73.1 ワークフロー・ステップ条件

- 73.2 ワークフロー・アクション

- 73.2.1 ステップ・アクションのエレメント

- 73.2.2 時間指定アクションのエレメント

- 73.2.3 デッドロック・アクションのエレメント

- 73.2.4 グループ・デッドロック時のアクションのエレメント

- 73.2.5 委任アクションのエレメント

74 カスタマイズ・フックのリアルタイム・パブリッシュの使用

- 74.1 リアルタイム・パブリッシュについて

- 74.2 カスタム・トランスポータの作成

- 74.2.1 独自のトランスポータの作成

- 74.2.2 AbstractTransporterメソッドのオーバーライドの考慮事項

- 74.2.3 AbstractTransporterのヘルパー・メソッド

- 74.2.4 トランスポータの実装: 例

- 74.2.5 リアルタイム・パブリッシュ・トランスポータを記述するためのコード

- 74.2.6 境界状況のシナリオの理解

- 74.2.7 管理インスタンスでのアセット・パブリッシュ・イベントのインターセプト

- 74.2.8 UnpackersとCacheUpdatesの区別

75 WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベントの理解

- 75.1 アセット・イベント

- 75.1.1 アセット・イベント・リスナーの記述

- 75.1.2 アセット・イベント・リスナーの登録

- 75.2 パブリッシュ・イベント

- 75.2.1 パブリッシュ・イベント・リスナーの記述

- 75.2.2 パブリッシュ・イベント・リスナーの登録

第XVIII部 トラブルシューティング

76 エラーのロギングおよびデバッグ

- 76.1 WebCenter Sitesログ・ファイルへのカスタム・メッセージの書込みについて

- 76.2 タグによるエラー・コードの使用方法

第XIX部 リファレンス

77 Asset APIの使用: チュートリアル

- 77.1 Asset APIの理解

- 77.2 主要インタフェース

- 77.3 はじめに

- 77.4 Asset APIによる読取り

- 77.4.1 簡単な例: フィールド値の読取り

- 77.4.2 AssetIdの読取り

- 77.4.3 アセットIDに基づいた属性の読取り

- 77.4.4 問合せの実行

- 77.4.5 複雑な問合せの実行

- 77.4.6 ソートによる結果の取得

- 77.4.7 BlobObjectの読取り

- 77.4.8 複数値属性の取得

- 77.4.9 多言語アセット: 翻訳の取得

- 77.4.10 アセットと属性の定義の読取り

- 77.4.11 キーと値のマッピングの読取り

- 77.5 Asset APIによる書込み

- 77.5.1 新規アセットの作成

- 77.5.2 既存のアセットの更新

- 77.5.3 既存のアセットの削除

- 77.5.4 多言語アセット

- 77.6 開発戦略

- 77.6.1 データ型と属性データ

- 77.6.2 問合せのタイプ

- 77.6.3 データ型と有効な問合せ演算

- 77.7 オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定

78 パブリック・サイト検索の使用

- 78.1 検索フレームワークについて

- 78.2 索引タイプ

- 78.2.1 Global索引

- 78.2.2 アセット・タイプ索引

- 78.3 検索APIについて

- 78.3.1 SearchEngine

- 78.3.2 QueryExpression

- 78.3.3 問合せ式の構成

- 78.4 詳細構成

- 78.4.1 Luceneパラメータの構成

- 78.4.2 カスタムAnalyzerFactoryの構成

第XX部 Oracle WebCenter Sitesコアの付録

79 WebCenter Sitesのツールおよびユーティリティの概要

- 79.1 Oracle WebCenter Sites Explorer

- 79.2 WebCenter Sitesデータベースへの接続

- 79.3 CatalogMover

- 79.3.1 CatalogMoverの起動

- 79.3.2 WebCenter Sitesへの接続

- 79.3.3 CatalogMoverのメニュー・コマンド

- 79.3.4 「カタログ」メニュー

- 79.3.5 表のエクスポート

- 79.3.5.1 選択した表の行のエクスポート

- 79.3.5.2 エクスポート対象の行の選択

- 79.3.5.3 ZIPファイルへのエクスポート

- 79.3.6 表のインポート

- 79.3.6.1 以前にエクスポートされたHTMLファイルのインポート

- 79.3.6.2 以前にエクスポートされたZIPファイルのインポート

- 79.3.6.3 CatalogMoverの既存のファイルのマージ

- 79.3.6.4 CatalogMoverの既存のファイルの置換

- 79.3.7 コマンドライン・インタフェース

- 79.4 プロパティ管理ツール

- 79.4.1 プロパティ管理ツールへのアクセス

- 79.4.2 プロパティの設定

- 79.4.3 wcs_properties.jsonファイルへのプロパティの追加

- 79.5 XMLPostを使用したインポートについて

80 空白と圧縮の理解

- 80.1 空白とJSP

- 80.2 空白とXML

- 80.3 圧縮

- 80.4 JSPの設計

81 WebCenter SitesのURLアセンブラの使用

- 81.1 WebCenter SitesのURLアセンブラについて

- 81.1.1 URLアセンブリ

- 81.1.2 アセンブラ検出と逆アセンブリ

- 81.1.3 GETリクエストとPOSTリクエストを使用するURLアセンブリとURL逆アセンブリ

- 81.2 WebCenter Sitesとともにインストールされるアセンブラ

- 81.2.1 Queryアセンブラ

- 81.2.2 QueryAsPathInfoアセンブラ

- 81.3 アセンブラの使用

- 81.3.1 アセンブラの作成

- 81.3.2 アセンブラの登録とランク付け

- 81.3.3 リンク・タグの変更

- 81.4 WebページのバニティURLリンク

はじめに

このガイドでは、Oracle WebCenter Sitesを開発して、コンテンツ・コントリビュータおよび管理者向けの高度にインタラクティブなデスクトップ用およびモバイル用のWebサイトを作成、管理、配信する方法について説明します。

対象読者

このガイドは、主に開発者を対象としています。開発者は、会社のビジネス・ニーズを把握しており、オンライン・サイトおよびそのバック・エンドの開発における各自の役割を基本的に理解していることが前提です。このガイドは、開発者と協力して、コンテンツ管理サイト、サイト・ユーザー、ワークフロー・プロセス、公開方法およびOracle WebCenter Sitesクライアント・オプションを設定する管理者にとっても役立ちます。

開発者には、Java、JavaServer Pages (JSP)、XMLおよびHTMLの知識が必要です。管理者にはプログラミングの経験は必要ありませんが、技術的なバックグラウンドはあると見なされます。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

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サポートへのアクセス

サポートを購入したオラクル社のお客様は、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 WebCenter Sitesリリース・ノート

- Oracle WebCenter Sitesのインストールと構成

- Oracle WebCenter Sitesの使用

- Oracle WebCenter Sitesの管理

- Oracle WebCenter Sitesプロパティ・ファイル・リファレンス

表記規則

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

表記規則

意味

太字

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

イタリック

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

固定幅フォント

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

このガイドで説明する新機能

ここでは、WebCenter Sites 12c (12.2.1)の新機能について説明し、追加情報の参照先を示します。また、非推奨の機能についてもリストします。

Oracle WebCenter Sites 12c (12.2.1)には、次の新機能が含まれます。

機能

説明

次の項を参照

Visitor Services

Visitor Servicesを使用すると、WebCenter Sitesのページで、Google、Facebook、主なCRMシステム、およびカスタム・データ・ソースなどの複数の外部プラットフォームにわたって取得された訪問者データを活用できるようになります。取得された訪問者のアクティビティ・データは、(一意の訪問者IDと組み合されたテンプレート・ベースの集計を使用して)複数のリポジトリから統合訪問者プロファイルに集計できます(WebCenter Sitesのマーケティング担当者はこのプロファイルを使用して、訪問者のセグメント分けやセグメント単位でのコンテンツのターゲット設定作業を改善できます)。

革新的なプロファイリングにより、以前に取得した訪問者データが新しいデータを使用して継続的に改善されるため、訪問者がサイトで費やす時間が長くなるほどターゲット設定の精度が高まります。ビルトインREST APIにより、取得およびエンリッチされた訪問者データと外部アプリケーションの共有が可能になり、電子メール・マーケティング・システム、CRMシステム、およびその他の多くのシステムと統合できます。

- WebCenter Sites: Visitor Servicesの理解

- WebCenter Sites: Visitor Servicesの開発

A/B Testing

A/B Testingを使用すると、マーケティング担当者は、コンテンツの各部を互いに実地試験することにより、どの部分が訪問者の好みに最も合っているかを確認できます。Contributorインタフェースから直接アクセス可能なA/B Testingを使用すると、マーケティング担当者はテストを完全に制御できます。また、テスト・バリアントとしてコンテンツ、プレゼンテーション、またはこれら両方の混成のいずれを使用するかを選択することもできます。マーケティング担当者は、テストの開始、テストが成功したかどうかの判断、およびテストの終了に関する基準を選択できます。

テストが開始されたら、マーケティング担当者は、コンテキストに対応した対話式のレポートを使用して、ターゲット・ページで各テストのパフォーマンスをリアルタイムで直接追跡したり、特定のテスト・バリアントを停止またはプロモーションしたり、テストのレポート・インタフェースに進んでより包括的なパフォーマンス・メトリックを参照できます。A/B TestingはWebCenter Sitesに完全に統合されているため、別個のサードパーティのテスト・ツールに関するライセンス供与やトレーニングは必要なく、オーサリング、構築、テスト、配信が統合された単一のソリューションを提供します。

- A/B Testingの使用

- A/B Testingの管理

- A/B Testingの開発

新しい開発構成: MVCフレームワーク、データ・アクセスAPI、RESTサービス

WebCenter Sitesでは、デスクトップおよびモバイルの両方の環境で使用されるアプリケーションを従来よりも柔軟に開発できる、最新の開発フレームワーク、データ・アクセスAPI、およびRESTサービスが導入されました。

新しいモデル・ビュー・コントローラ(MVC)フレームワークと新しいデータ・アクセスAPIの組合せにより、ビジネス・ロジックを明確に分離するサーバー・ベースのアプリケーションの堅牢な開発(Groovyコントローラとして実装)とプレゼンテーション(WebCenter Sitesテンプレートとして実装)が可能になります。このような分離のレベルにより、動的デプロイメントと高パフォーマンスのキャッシングの最適な組合せをアプリケーションに提供できます。

新しい集計スタイルのRESTサービスでは、消費される帯域幅が最小限に抑えられ、カスタムRESTサービスの作成機能を含む、クライアント・ベースのシングル・ページ・アプリケーション(SPA)、モバイルWeb、およびモバイル・アプリケーション開発のための堅牢なコンテンツ・アクセス・メカニズムが提供されます。境界セキュリティとシングル・サインオン・ソリューションに対する非依存性により、開発の柔軟性がさらに強化されます。

MVCフレームワーク、データ・アクセスAPIおよびRESTサービスがWebCenter Sitesライフサイクルと開発者ツール(CSDT)に完全に統合され、自由にな組合せとマッチングが可能になります。学習時間も大幅に短縮し、WebCenter Sitesに基づいた既存のアプリケーションとの完全な下位互換性により、シームレスな採用が可能になります。

- MVCフレークワークおよびAPIを使用したWebsサイト開発

- サーバー側Webサイトの開発

- クライアント側Webサイトの開発

XMLPost CLIサポート

XMLPostユーティリティで、ユーザー資格証明を.iniファイルから読み取るかわりに、コマンドラインの引数として受け入れるようになりました。

コマンドラインからのXMLPostの実行

EclipseおよびCLI用WebCenter Sites Developer Toolsプラグイン

Eclipse IDE内からWebCenter Sites Developer Toolsにアクセスできるインストール可能プラグインがWebCenter Sitesに同梱されています。WebCenter Sites Developer Toolsの機能にコマンドラインからもアクセスできるようになり、スクリプト・ベースの自動化が可能になりました。

- EclipseのDeveloper Tools機能の概要

- Developer Toolsビューをパネルに表示する方法

- ロギング構成ビュー

- コントローラの作成

- Developer Toolsコマンドライン・ツールの使用

- Developer Toolsプラグインのインストール方法

Enterprise Manager

Oracle Enterprise Managerを使用してWebCenter SitesおよびVisitor Servicesの管理と監視が可能になりました。インスタンスの開始/停止、コンポーネント・ホーム・ページの表示、ログの管理およびパフォーマンス・メトリックの確認がサポートされています。

Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの管理

セキュリティ拡張機能

セキュリティの向上のため、WebCenter SitesでOracle Platform Security Services (OPSS)資格証明ストアがサポートされるようになりました。資格証明ストアとの通信が暗号化され(HTTPS)、個々のWebCenter Sitesインスタンスが一意に認証されます。

- 外部セキュリティの設定

- 資格証明ストアのプロパティ

- Oracle WebCenter Sitesのインストールと構成

ODLによるlog4jの置換え

log4jロギングのレガシー・メカニズムがより堅牢なOracle Diagnostic Loggingソリューションによって置き換えられました。

- ログODLの構成ツールの使用

- Oracle Diagnostic Logging (ODL)プロパティ・ファイル

プロキシ・アセットの拡張機能

WebCenter Sitesのプロキシ・アセットでYouTube API v3がサポートされるようになりました。

- YouTubeプロキシ・アセットの設定

- サンプル・プロキシ・アセットのインストール

テストから本番のサポート

標準のOracle Fusion Middlewareのテストから本番のスイッチオーバー・プロセスがWebCenter Sitesでサポートされるようになりました。

テスト・モードから本番モードへの切替え

構成のインポート/エクスポート・ユーティリティ

WebCenter SitesおよびSatellite Serverのwcs_properties.jsonファイルのプロパティ値のバルク・エクスポートおよびバルク・インポートが可能な、構成のインポート/エクスポート・ユーティリティがWebCenter Sitesにが同梱されています。

インポート/エクスポート・ユーティリティの使用

モビリティ・フレームワークの拡張機能

WebCenter Sitesモビリティ・フレームワークで、ビルトインおよび外部の最適化アルゴリズムを含む、モバイル・サイトのイメージの最適化がサポートされるようになりました。「サイト」ビューと「デバイス・グループ」ビューの両方でのテンプレートの作成もサポートされるようになりました。

- サイトおよびデバイス・グループ・ビューでのモバイル・テンプレートの作成

- モバイルWebサイトのイメージの最適化

共有ファイル・システムをデータベースに格納可能

ローカルまたはネットワーク・ディスク・ボリュームではなく、データベースにWebCenter Sitesの共有ファイル・システムを格納できるようになりました。提供される変換ツールにより、デフォルトのディスク・ベースの共有ファイル・システムがWebCenter Sitesリポジトリ・データベース、または個別のデータベースまたはスキーマのいずれかに移動されます。このツールでは、ディスク・ベースの共有ファイル・システムに戻すこともできます。

データベースへの共有ファイル・システムの移動

新しいデプロイメント・プロセス

WebCenter Sitesおよびそのコンポーネント・アプリケーションがOracle Universal Installerに組み込まれました。以前は手動だったデプロイメント・タスクが自動化され、インストール後の構成がWebベースのコンフィギュレータで実行されるようになりました。特定のデプロイメント・タスクは、ターゲット環境の仕様に基づいて、従来どおり手動で完了する必要があります。

Oracle WebCenter Sitesのインストールと構成

IPv6のサポート

WebCenter Sitesおよびそのコンポーネント・アプリケーションでIPv6プロトコルがサポートされるようになりました(ハイブリッドIPv6/IPv4操作を含む)。

Oracle WebCenter Sitesのインストールと構成

新しいプロパティ管理ツール/JSON形式に移行されたプロパティ

WebCenter Sitesおよびそのコンポーネント・アプリケーションの動作を制御するプロパティがJSON形式でサポートされるようになり、新しいプロパティ管理ツールのAdminインタフェースを使用して管理されます。

- プロパティ管理ツールの使用

- JSONファイルのプロパティの管理

次の機能は、このリリースでは非推奨になりました。

- WebCenter Sites GadgetsおよびGadget Server

- Community/GadgetsでのWebCenter Sitesのネイティブ認証

- WebCenter Sites Analytics 2.5

- WebCenter Sites Content Integration Platform - EMC Documentum

- WebCenter Sites Content Integration Platform Filesystem

- WebCenter Sites Content Integration Platform Sharepoint

- WebCenter Sites Janrain Integration

- WebCenter Sites Netomat Mobility Server

- SOAPベースのWebサービス

- ページ・デバッガ。

注意:
JSPデバッグ機能のIDE統合を使用してください。DebugServletはデプロイされません。

- サイト・デスクトップ

- サイトDocLink

第I部 Oracle WebCenter Sitesスタート・ガイド

この部では、Oracle WebCenter Sitesで開発を開始する方法について説明します。ここでは、WebCenter Sitesの開発者が一般に実行するタスクと、使用するツールおよびテクノロジについて説明します。また、サンプル・サイトの概要および開発環境の設定方法についても説明します。

この部は、次の章で構成されています。

- WebCenter Sitesでの開発の概要

- avisportsサンプル・サイトの概要

- WebCenter Sitesの開発プロセス

1 WebCenter Sitesでの開発の概要

このガイドの目的、サイトの作成における開発者の役割、Oracle WebCenter Sitesインタフェース、およびWebCenter Sitesで開発するためのテクノロジおよびツールを理解するには、次の項を参照してください。

- WebCenter Sitesでの開発について

- WebCenter Sites開発者の一般的なタスク

- WebCenter Sitesのユーティリティ

- WebCenter Sitesのインタフェース

- WebCenter Sitesのユースケース・シナリオ

1.1 WebCenter Sitesでの開発について

このガイドでは、WebCenter Sitesに関連する開発タスクについて説明します。これらのタスクは次の主要グループに編成できます。

- Webサイトの構築
Webサイトを作成するには、開発者がWebサイトのインフラストラクチャを構築して、管理者がコンテンツ管理サイトおよびサイト・ナビゲーションを作成し、コンテンツ・コントリビュータがコンテンツをWebサイトに追加します。

このガイドでは、開発者がWebCenter Sitesを使用して、Webサイトのインフラストラクチャをどのように作成できるかを中心に説明します。

WebCenter Sitesでは、テンプレートと情報の両方がアセットとして格納されます。Webサイトのインフラストラクチャを開発する場合、作成するアセット・タイプおよびアセットを組み込むアセット・モデルが最初に設計されます。アセット・タイプの準備が整ったら、サイト・レイアウト、ページ・テンプレートおよびページレットがコーディングされ、パフォーマンス向上のためにキャッシュが実装されます。Webサイト・アクセス、ユーザー、ACLおよびロールが作成され、関連するロールにユーザーが割り当てられます。様々なタイプのコンテンツがアセットとしてインポートされます。次に、管理者およびコンテンツ・コントリビュータがサイトの設計を開始する管理システムにインフラストラクチャがミラー・パブリッシュされます。開発プロセスの詳細は、「WebCenter Sitesの開発プロセス」を参照してください。

注意:

組織の設定に応じて、開発者または管理者のいずれかがコンテンツ管理サイト(オンライン・サイトのコンテンツを格納するためのフレームワーク)とサイト・ナビゲーションを作成します。コンテンツ・コントリビュータは、ページとコンテンツをサイト・ナビゲーションに追加し、サイトがオンラインになり、Webサイトのように機能を開始する配信システムにパブリッシュできるように、管理者がコンテンツを承認します。

Webサイトの構築の詳細は、「Oracle WebCenter Sitesスタート・ガイド」、「データ・モデルの構築」、「Webサイトの開発」、「モバイル用Webサイトの開発」、「Developer Toolsを使用したコーディング」、「キャッシングの管理」、「コンテンツ管理システムへの作業内容の移行」および「セキュリティ: コンテンツ管理ユーザーの管理」を参照してください。

- Websサイトの機能拡張
Webサイトは、ビジネスおよび顧客プロファイルの性質に応じて機能拡張できます。WebCenter Sitesを使用すると、訪問者情報を収集して、訪問者ごとの販促用メッセージをパーソナライズしたり、Webサイトの訪問者や訪問者のページの使用に関するデータを取得できるようにオンライン・サイトを設計できます。サイト・ページはFacebook、Twitter、Googleなどと統合可能で、ガジェットやアプリケーションを設計してWebCenter Sitesと統合することもできます。

詳細は、「Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発」、「A/B Testingの実行」、および「WebCenter Sites: Visitor Servicesの開発」を参照してください。

- WebCenter Sitesのカスタマイズ
開発環境と操作性を効率化し、コンテンツ・コントリビュータの仕事を簡単にするために、Oracle WebCenter Sites: AdminインタフェースおよびOracle WebCenter Sites: Contributorインタフェースをカスタマイズできます。効率性と生産性を向上するために、プロパティ、ダッシュボード、検索ビュー、アセット・フォーム、ワークフローなどを変更できます。

詳細は、「Oracle WebCenter Sitesのカスタマイズ」を参照してください。

1.2 WebCenter Sites開発者の一般的なタスク

開発者の一般的なタスクは、次の項に説明されています。

- コンテンツ表示のデータ・モデル

- コンテンツ管理サイトのコンテンツ・エントリ・フォーム

- コンテンツをWebサイトにレンダリングするためのテンプレートおよびエレメント

- 開発、管理、配信およびテスト用WebCenter Sitesシステム

- 承認およびパブリッシュ

- キャッシングによるパフォーマンスの最適化

1.2.1 コンテンツ表示のデータ・モデル

WebCenter Sites開発者は、Webサイトに表示するのに必要なコンテンツのデータ・モデルを構築します。WebCenter Sitesでサポートされているデータ・モデルは次のとおりです。

- ベーシック・アセット・モデル: 水平なデータ構造をサポートし、ベーシック・アセットはお互いのプロパティ(このガイドでは属性と呼称)を継承できません。コンテンツはWebCenter Sitesのユーザーによって入力され、アセットというオブジェクトとしてWebCenter Sitesデータベースに格納されます。アセットの各タイプは、データベース内の1つのプライマリ記憶域表に格納されるので、あるタイプのベーシック・アセットを別のタイプのベーシック・アセットに関連付けることができます。

- フレックス・アセット・モデル: 総合的なデータ・モデルで、それぞれのアセット・タイプは複数の記憶域表を使用できるので、階層的なデータ構造が作成でき、子アセットは親アセットから属性値を継承します。フレックス・アセット・モデルでは、その独自フレームワーク内で水平データ構造もサポートされます。フレックス・アセット・モデルはベーシック・アセット・モデルと無関係に機能し、2つのモデル内で作成された表は交差しません。

フレックス・アセット・モデルとベーシック・アセット・モデルのどちらを選択するかは、訪問者へのサービス提供を計画しているデータの複雑さによって決まります。フレックス・アセット・モデルはこれまで、製品の大規模なオンライン・カタログの作成に使用されてきました。ただし、あまり複雑でない状況で使用することもできます。特に使用することが好ましいのは、水平データ構造を階層構造に最終的に変換することを意図している場合です。この変換プロセスでは、データの再作成は不要です。

1.2.2 コンテンツ管理サイトのコンテンツ・エントリ・フォーム

WebCenter Sitesの開発者は、データ・モデルを使用してコンテンツ・エントリ・フォームを作成し、このフォームは、Webサイトのコンテンツを作成するためにコントリビュータが使用します。　コンテンツ・エントリ・フォームの各フィールドは、1つのデータベース表(または複数の表)で対応する列にマップされます。また、開発者は、コンテンツ・エントリ・フォームをWebモードでレンダリングし、WebサイトにパブリッシュされたコンテンツをレンダリングするJSPを作成します。

コンテンツを世間に配信する準備ができたら、動的と静的のいずれかのパブリッシングを使用してWebサイトにパブリッシュできます。書式設定されたコンテンツは、JSPによってWebサイトに表示されます。表1-1では、動的WebCenter Sitesページと典型的なHTMLページの違いについて説明します。

表1-1 静的ページと動的ページ

静的ページ(HTMLページ)

動的ページ(WebCenter Sitesページ)

単一のディスク・ファイルで、Webサーバーを介してサイトが提供されます。

要求時に構成および作成されます。

HTMLページと、訪問者のWebブラウザに表示されるページの間での、1対1の関連付。

訪問者の画面に表示されるWebページは、WebCenter Sites内から作成されるページレットという複数のコンポーネントで構成できます。

プレゼンテーションとコンテンツは分離されません。そのため、プレゼンテーションとコンテンツをお互いと無関係に変更することは困難です。

プレゼンテーションとコンテンツの分離。プレゼンテーションとコンテンツをお互いと無関係に変更して保持することができます。

1.2.3 コンテンツをWebサイトにレンダリングするためのテンプレートおよびエレメント

WebCenter Sitesの開発者は、Webサイト上のコンテンツのレンダリングに使用されるコード・テンプレートおよびエレメントに、APIとJSPタグを使用します。次のプログラミング・コンポーネントは、コーディングのプロセスで使用されます。

- エレメントのファイル

- APIおよびJSPタグ

- セッションおよびCookie

1.2.3.1 エレメントのファイル

簡単に言ってしまえば、WebCenter Sitesの主な機能は、フォーマットをコンテンツから分離することです。WebCenter Sitesでは、この2つを分離すれば、コンテンツを構成する数多くの部品に対して、書式設定コードの同じ部分を再利用できます。たとえば、記事のフォーマットを変更するには、システム内のすべての記事のコードをリライトする必要はなく、1箇所のコードをリライトします。

書式設定コードは、エレメントという名前のファイルに格納されます。このコードによって、データベースからコンテンツが抽出され、コンテンツが書式設定されます。コンテンツが書式設定されるのはページが要求された場合のみであるため、実行時に構成されるページを、要求する訪問者のIDに従って設定することもできます。

エレメントのファイルは、WebCenter SitesデータベースのElementCatalog表に格納されます。ページの名前はSiteCatalog表に格納されます。つまり、SiteCatalog表には、Webサイトのすべての適切なページ名に対するエントリが格納されます。SiteCatalog表の各行は、ページ・エントリです。それぞれのページ・エントリは、ElementCatalog表内のエレメントを指しています。ページ・エントリによって指されているエレメントは、ページ・エントリのルート・エレメントと呼ばれます。

WebCenter Sitesでは、SiteCatalogページ・エントリを実行することによって、コンテンツをオンライン・ページにレンダリングします。その具体的な動作を次に示します。

1. 訪問者が、WebサイトのURLをブラウザで入力します。

2. HTTPリクエストを処理するWebサーバーによって、そのURLがWebCenter SitesのURLにマップされます。たとえばWebCenter Sites URLは次のようになります。

http://www.FiscalNews.com/servlet/ContentServer?pagename=FiscalNews/Home

WebCenter SitesのURLの後ろにあるテキストはページ名と呼ばれます。この例では、ページ名はFiscalnews/Homeです。

3. WebCenter SitesはSiteCatalog表でページ名を調べ、そのルート・エレメントを判別し、そのエレメントをElementCatalog表の中で検索して、そのエレメントを起動します。
エレメントが実行されます。ルート・エレメント内からコールされる他のエレメントが次に実行されます。

4. イメージや記事など、HTMLタグを含めた結果がHTMLコードにレンダリングされ、訪問者のブラウザに返されます。

その結果は、要求時に動的にレンダリングされるページです。

1.2.3.2 APIおよびJSPタグ

WebCenter Sitesには、エレメントのコーディングに使用するタグ・ファミリがいくつか含まれています。このタグ・ファミリを使用すると、アセットを特定し、抽出してWebサイトに表示できます。WebCenter SitesにはJavaメソッドとJavaユーティリティも用意されており、それらは、Webサイトの設計、独自のコンテンツ管理アプリケーションの開発、およびWebCenter Sitesのモジュール/製品のカスタマイズに使用できます。

注意:

ベーシック・データ・モデルを使用するアセットを表示するページのコーディングの詳細は、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。WebCenter Sitesタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

WebCenter Sitesオペレーティング・システムは、アプリケーション・サーバーのさらに上で稼働する複数のサーブレットで構成されています。それぞれのサーブレットは、必要に応じて、不連続なタスクを実行するために起動されます。それぞれのサーブレットには、対応するJava APIとJavaメソッドおよびJSPタグがあり、機能を起動するために使用します。

図1-1に、WebCenter Sitesの主なサーブレットを示します。

図1-1 WebCenter Sitesの主なサーブレット

WebCenter Sitesの主なサーブレットは次のとおりです。

- ContentServer: ページの生成とその提供を動的に行います。このサーブレットでは、ディスク・キャッシング、セッション管理、イベント管理、検索、パーソナライズの各種サービスが提供されます。

- CatalogManager: リビジョン追跡、セキュリティ、結果セットのキャッシング、パブリッシュ・サービスなど、WebCenter Sitesデータベースに対するデータベース管理のほとんどを提供します。

- TreeManager: WebCenter Sitesデータベースにある他の表の階層情報を格納したツリー表を管理します。

- BlobServer: バイナリ・ラージ・オブジェクト(BLOB)の検索とその提供を行います。BLOBは一切処理されず、格納されている状態そのままで提供されます。

- DebugServer: XMLコードのデバッグに役立つツールを提供します。

- CookieServer: WebCenter SitesのページにCookieを提供します(それらのページの配信元がContentServerサーブレットであってもSatellite Serverアプリケーションであっても関係ありません)。

- HelloCS: システムにインストールされているWebCenter Sitesソフトウェアのバージョン情報を表示します。

一般的には、どのサーブレットがどのサービスまたはタスクを実行しているかを認識する必要はありません。適切なJavaメソッド、あるいはXMLタグまたはJSPタグを起動して、どのサーブレットをコールすべきかをWebCenter Sitesのコア・アプリケーションに判断させるのみです。このルールに対する例外は、サーブレットのURLを参照するコードを記述するときです。つまり、BLOBへのリンク、またはWebCenter Sitesのページでの別ページへのリンクを含めるときです。ContentServerサーブレットとBlobServerサーブレットは別々のURLにあるので、<A HREF>タグには、適切なサーブレットのURLを含める必要があります。

BLOBおよびページへのリンクのコーディングの詳細は、「タグ・テクノロジを使用したWebサイト開発」および「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

1.2.3.3 セッションおよびCookie

WebCenter Sitesでは、初めてWebサイトを訪問したときに、その訪問者のセッションが自動的に作成されます。その訪問者の情報は、WebCenter Sitesコアでタグおよびメソッドを使用することによって、セッション変数に格納できます。後続のエレメントは、その後それらの変数にアクセスし、条件付きで応答できます。

ただし、セッション変数は変化しやすいものです。これらは、セッションが持続している間、つまり次のイベントのいずれかが発生するまで持続するにすぎません。

- 訪問者が自分のブラウザを閉じます。

- 非アクティブになっている期間が経過してセッションがタイムアウトします。Adminインタフェースのプロパティ管理ツールから、cs.timeoutプロパティ(wcs_properties.jsonファイル内)を設定して、セッション・タイムアウトを制御します。

- アプリケーション・サーバーが再起動されます(クラスタ内にある場合は除く)。

- セッションが他のなんらかのやり方で無効になります。

Cookieは、情報をより永続的に格納する場合に使用されます。訪問者の情報をその人のブラウザに格納するCookieを記述するようにエレメントをコーディングできます。次に、格納された情報を使用し、ページをカスタマイズして、該当する訪問者がWebサイトに戻ってきたときに適切なバージョンのページを表示するようにできます。

セッションとCookieの詳細は、「セッションおよびCookieについて」を参照してください。

1.2.4 開発、管理、配信およびテスト用WebCenter Sitesシステム

コンテンツ管理ニーズについてWebCenter Sitesを操作するときには、チームの人間が協力して、最大で次に示す4種類のシステムを操作します。

- 開発システム: 開発者と設計者が、Webサイトの計画立案と作成を行います。購入したWebCenter Sites製品のすべてが、このシステムにインストールされています。

- 管理システム: ライター、編集者、グラフィック・アーティスト、マーケッタなどのコンテンツ・プロバイダには、Webサイトの訪問者に配信されるコンテンツを開発するために、コンテンツ管理サイトが割り当てられます。リビジョン追跡機能とワークフロー機能では、アセット(コンテンツ)に対する変更が追跡され、配信システムへのパブリッシュが承認されるまでアセット(コンテンツ)が監視されます。
コンテンツ管理サイトは、実際のWebサイトを表しています。たとえば、Webサイトの別々のセクションに対して、別々のコンテンツ管理サイトを作成できます。各セクションにコンテンツを提供するチームは、お互いにまったく別々であり、そのセクション(コンテンツ管理サイト)にアクセスできるのはそのチームのメンバーのみとなるからです。または、avisportsのサンプル・サイトと同様の、Webサイト全体を表すコンテンツ管理サイトを作成することもできます。コンテンツ管理サイトの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

- 配信システム: 使用可能にしているコンテンツまたは販売している製品が、訪問者または顧客に提供されます。
コンテンツを動的に配信するには、購入したWebCenter Sites製品のすべてをこのシステムにインストールする必要があります。コンテンツを静的に配信する場合、つまり、静的なHTMLページを提供する場合は、配信システムにWebサーバーのみが必要です。つまり、WebCenter Sites製品をシステムにインストールする必要はありません。

- テスト・システム: 開発者またはQAエンジニアが、管理システムと配信システムの両方のパフォーマンスをテストします。テストは、専用のシステムまたは開発システムのいずれかで実行できます。

WebCenter Sitesの開発者は、時間の大部分を開発システムでの作業に費やします。開発するアセット・タイプおよび設計したサイトの準備ができたら、できあがったものを開発システムから管理システムに移行(パブリッシュ)します。コンテンツ・プロバイダによってアセットが作成、変更および承認されると、管理システムから配信システムにパブリッシュされます。

1.2.5 承認およびパブリッシュ

Webサイトの開発が終了したら、できあがったもの(テンプレート、エレメント、アセット・タイプ、サイト・ナビゲーションなど)を開発システムから管理システムにパブリッシュします。できあがったものをパブリッシュすると、管理システムで使用できるようになります。コントリビュータはこれを受けて、アセット・タイプとサイト・デザインを使用して、Webサイトのコンテンツを作成できます。コントリビュータがサイトのコンテンツの作成を終了したら、(サポートしているアセット・タイプ、テンプレート、エレメント、サイト・ナビゲーションなどとともに)そのコンテンツを承認し、Webサイトにパブリッシュできます。

アセットをパブリッシュする準備ができたら、誰かが最初に、そのアセットを承認済とマークします。次に、パブリッシュ・プロセスの開始準備ができたら、承認システムが起動します。これは、承認されたアセットすべてのリストをまとめ、それらのアセットに依存するものをすべて検査するシステムです。承認されたアセットにリンク付けされたアセットをパブリッシュする前に、そのアセットも承認する必要があります。

WebCenter Sitesのパブリッシュ・システムと承認システムでは、配信システムでのコンテンツの整合性を維持するために、アセット依存関係をすべて追跡および検証します。パブリッシュ・システムと承認システムでは、パブリッシュの準備ができたアセットのみが、パブリッシュされるアセットとなります。

コンテンツとエレメントをパブリッシュすると、WebCenter Sitesでは、そのコンテンツとエレメントが、あるシステム(たとえば管理システム)から別のシステム(たとえば配信システム)にコピーされます。WebCenter Sitesでは、WebCenter SitesのパブリッシュAPIから構築された2つのパブリッシュ方法が配信されます。これらのパブリッシュ方法は、WebCenter Sitesの承認システム、つまり、どのアセットが承認されているかを判別する基礎となるシステムと対話します。

WebCenter Sitesのパブリッシュ方法は次のとおりです。

- リアルタイム: 動的なパブリッシュ方法です。それはWebCenter SitesのリアルタイムAPIで構築され、あるシステム上のWebCenter Sitesデータベースから別のシステム上のWebCenter Sitesデータベースに、承認されたアセットがコピーされます。

- ディスクへのエクスポート: 静的なパブリッシュ方法です。承認されたアセットに割り当てられているテンプレート・エレメントを使用して、このアセットを静的なHTMLファイルにレンダリングします。次に管理者または自動化されたプロセスによって、FTPなどのファイル転送方法を使用して、これらのファイルが配信システムにコピーされます。

関連項目:

- パブリッシュの構成の詳細は、『Oracle WebCenter Sitesの管理』

- 依存性を適切にロギングするためのエレメントのコーディング、およびWebCenter Sitesによる承認の依存性の計算の詳細は、「テンプレートおよびCSElementのエレメントのコーディング」

- アセットの承認方法の詳細は、『Oracle WebCenter Sitesの使用』および『Oracle WebCenter Sitesの管理』

1.2.6 キャッシングによるパフォーマンスの最適化

開発者は、様々なキャッシング・フレームワークを実装して、パフォーマンスを最適化します。WebCenter Sitesでは、Satellite Serverキャッシングの使用もサポートされており、このキャッシングでは、第2レベルのキャッシングが実現し、Webページのリモート・キャッシュとして使用することもできます。デフォルトでは、WebCenter SitesとSatellite Serverは、ページのキャッシング・フレームワークとしてinCacheを使用します。次の各項で、キャッシングについて説明します。

- ページのキャッシング

- 結果セットのキャッシング

- アセットのキャッシング

- Satellite Serverのキャッシング

1.2.6.1 ページのキャッシング

ページのキャッシングはテンプレート・レベルで実装され、WebCenter Sitesシステムでページをキャッシュするために使用されます。ページのキャッシングは、システム・パフォーマンスにおいて重大な役割を果たしています。キャッシュされるページは、最初に生成を必要とする場合に比べて、より迅速に提供できます。

(Satellite Serverと無関係に) WebCenter Sitesのみで、SiteCatalog表のページ・エントリによって特定される各ページまたは各ページレットを別々にキャッシュできます。その表におけるそのページ・エントリの値を指定することによって、キャッシュ内の任意のページレットの有効期限をマークすることができます。

ページのキャッシングは、Satellite Serverを追加することで特に有効になります。Satellite Serverのアプリケーションをインストールすると、Satellite Serverをホストするサーバーにページ・キャッシュをインストールすることになり、それによってWebCenter Sitesページ・キャッシュが拡張されます。

関連項目:

- ページ・キャッシングの詳細は、「ページのデザインとキャッシングの理解」

- inCacheページのキャッシングの詳細は、『Oracle WebCenter Sitesの管理』

- Satellite Serverの詳細は、「Satellite Serverのキャッシング」

1.2.6.2 結果セットのキャッシング

結果セットのキャッシングは、システム・パフォーマンスを大幅に拡張できる別の機能です。WebCenter Sitesデータベースに対して、任意のメカニズムによって問合せが行われると、WebCenter Sitesアプリケーションは、返す結果セットをキャッシュできます。データベース内のすべての表を追跡します。表が変更されると常に、その表のためにキャッシュされた結果セットがすべてフラッシュされます。

結果セットのキャッシングの詳細は、「結果セットのキャッシングと問合せでの作業」を参照してください。

1.2.6.3 アセットのキャッシング

アセットのキャッシングは、inCacheフレームワーク上に構築された、メモリーをベースにしたシステムで、そのままではデータベースに影響を与えるような負荷を占有することによって、WebCenter Sitesのパフォーマンスを最適化します。WebCenter Sitesでは、アセットのプログラム的な使用は、その属性のローディングとレンダリングで構成されます。アセットは、WebCenter Sitesデータベースに格納されているテンプレートによってロードされるため、AssetCacheはWebCenter Sitesノードでのみ使用されます。アセットのキャッシングにはAssetCacheコンテナ・コンポーネントが含まれており、そのコンポーネントは、アセットをキャッシュして既存のinCacheコンポーネントと対話することによって機能します。

inCacheフレームワークおよびおアセットのキャッシングの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

1.2.6.4 Satellite Serverのキャッシング

Satellite Serverはキャッシング・アプリケーションです。これは、追加のページ・キャッシュを提供することによって、WebCenter Sitesのキャッシング機能を補足するものです。WebCenter SitesとSatellite Serverのキャッシュを併用すると、自動的に二重にバッファされたキャッシングとなります。

デフォルトでは、一緒に常駐するSatellite Serverは、WebCenter Sitesがインストールされているのと同じコンピュータにインストールされます。Satellite Serverをリモートにインストールし、ページおよびページレットを、想定された利用者により近い場所にキャッシュできるようにすることによって、システムのパフォーマンスをさらに向上させることができます。リモートのSatellite Serverホストは、WebCenter Sitesのページの高速で安価なキャッシュです。WebCenter Sitesホスト上の負荷が減り、サイト訪問者へのページ配信スピードが大幅にアップし、WebCenter Sitesシステムのスケールを変更する簡略で安価な手段が提供されます。

1.2.6.4.1 HTTPリクエスト

ページに対するHTTPリクエストをロード・バランサがSatellite Serverにルーティングすると、Satellite Serverは、ページがキャッシュの中にあるとそのページを提供し、ページがキャッシュされていないとHTTPリクエストをWebCenter Sitesに転送します。イベントのベーシックなチェーンは次のとおりです。

1. Satellite Serverがそのキャッシュをチェックします。

2. 次に何を行うかは、Satellite Serverキャッシュにページが格納されているかどうかによって異なります(詳細は表1-2を参照)。

表1-2 Satellite Serverキャッシュに格納されているページと格納されていないページ

Satellite Serverキャッシュに格納されているページ

Satellite Serverキャッシュに格納されていないページ

Satellite Serverが、訪問者のブラウザにページを提供します。

この場合は、Satellite ServerはWebCenter Sitesデータベースにリクエストを転送する必要がないため、WebCenter Sitesデータベースにかかる負荷は軽減します。

- Satellite Serverが、WebCenter Sitesにリクエストを転送します。

- WebCenter Sitesでは、キャッシュされたページが、そのキャッシュからSatellite Serverに返されます。そのキャッシュに格納されていないページがレンダリングされ、コピーがキャッシュされてSatellite Serverにページが送信されます。

- Satellite Serverが、ページをキャッシュして訪問者のブラウザに提供します。再度要求されたら、ページはSatellite Serverキャッシュから提供され、WebCenter Sitesデータベースにかかる負荷は軽減します。

各Satellite Serverアプリケーションは、それ以外のあらゆるSatellite Serverアプリケーションと無関係です。個々のSatellite Serverアプリケーションには、次のような特徴があります。

- 独自のキャッシュを保持します。

- 別のSatellite Serverアプリケーションからは、ページもページレットも要求できません。ページまたはページレットを要求できるのは、WebCenter Sitesコアからのみです。

1.2.6.4.2 Satellite Serverのサーブレット

Satellite Serverはいくつかのサーブレットで構成されています。次に示すように、ページのキャッシュと提供を行うサーブレットが1つ、キャッシュを管理するサーブレットが2つです。

- Satellite: ページレット・レベルでページをキャッシュします。Satelliteのエレメント内にあるXMLタグまたはJSPタグは、どのページレットをキャッシュする必要があるかを示し、Satellite Serverの各種設定を制御します。

- Inventory: Satellite Serverキャッシュを調べ、必要に応じて、キャッシュから個々のページまたはページレットを手動でフラッシュするために必要な情報を入手できるようにします。

- FlushServer: すべてのタイプのキャッシュ・フラッシュを処理します。FlushServerでは、キャッシュ全体をフラッシュすることも、キャッシュ内の個々のアイテムをフラッシュすることもできます。

Satellite Serverのタグおよびページのキャッシングを使用したページのコーディング全般については、「ページのデザインとキャッシングの理解」を参照してください。

1.3 WebCenter Sitesのユーティリティ

WebCenter Sitesにはユーティリティが用意されており、これは、WebCenter Sitesのデータベースおよび各種コードを管理するための、開発者向けツールです。ユーティリティはGUIベースであり、(特に指示のないかぎり)手動でインストールする必要があります。これらは次のとおりです。

- Developer Tools: WebCenter SitesとEclipse統合開発環境(IDE)を統合します。WebCenter Sitesの開発者がDeveloper Toolsキットを使用すると、Eclipseやバージョン・コントロール・システム(VCS)統合などのツールを使用して分散環境で作業ができます。

- Sites Explorer: WebCenter Sitesデータベースで表の表示および編集を行います。

- CatalogMover: データベース表のエクスポートおよびインポートを行います。

- XMLPost: WebCenter Sitesデータベースにデータを増分インポートします。

- BulkLoader: WebCenter Sitesデータベースに大量のデータを高速インポートします。

- プロパティ管理ツール: Adminインタフェースからアクセス可能で、wcs_properties.jsonファイル(システム構成ファイル)の表示と整理を行います。

1.4 WebCenter Sitesのインタフェース

WebCenter Sitesの開発者は、主にAdminインタフェースで作業しますが、使用可能なすべてのインタフェースを理解していることが重要です。

- Adminインタフェース: Adminインタフェース(図1-2)により、開発者および管理者はWebCenter Sitesを管理および構成できます。

図1-2 Adminインタフェース

左側のツリー・パネルには、開発者と管理者が操作する必要のあるコンテンツ管理エレメントがすべて含まれています。右側の作業領域は、すべてのタスクと操作が実行される場所です。

Adminインタフェースではコードをベースにした操作がサポートされており、ベーシック・アセット・タイプの作成をグラフィカルに完了できます。たとえば、ベーシック・アセット・タイプを作成する手順は次のとおりです。

1. (アセット記述子ファイルと呼ばれる) XMLファイルを記述して、ベーシック・アセット・タイプを定義します。

2. このファイルをWebCenter Sitesにアップロードします。

3. AssetMakerユーティリティを起動します。このインタフェース(AssetMaker)の機能の1つは、アセット記述子ファイルを読み取り、そこからこのアセット・タイプの記憶域表を作成します。このインタフェースで他の機能を使用すると、アセット・タイプを構成できます(たとえば、その認可されたユーザーの名前を付ける)。

管理者は同じインタフェースを使用して、コンテンツ管理サイトの作成、システム・ユーザーの管理、それらシステム・ユーザーのコンテンツに対する権限の制御、ワークフロー・プロセスの確立、およびWebCenter Sitesの機能(Mobilityなど)の構成ができます。

- Contributorインタフェース: Contributorインタフェース(図1-3)は、特に、コンテンツ・プロバイダおよびビジネス・ユーザー向けに設計されています。アセットのプレビュー、作成、編集、削除、承認など、WebCenter Sitesのコンテンツ管理機能のほとんどが使いやすくなり、迅速にアクセスできます。

図1-3 Contributorインタフェース

Contributorインタフェースでアセットを操作するときには、次のWYSIWYGエディタに対応したフィールドが表示される場合があります。

- CKEditor: CKSource社製のオープン・ソースWYSIWYGテキスト・エディタで、クライアント側にインストールしておく必要はありません。開発者はCKEditorを使用して、テキスト入力フィールドでフィールドの入力メカニズムとしてCKEditorを使用するベーシック・アセットを作成できます。開発者はまた、入力手段としてCKEditorを使用するフレックス属性に対する属性エディタを作成することもできます。

- Clarkii Online Image Editor (Clarkii OIE): InDis Baltic社製の広く普及したサード・パーティ・イメージ・エディタです。開発者はClarkii OIEを有効にして、ユーザーがフォーム・モードでイメージを直接編集できるようにすることで、外部のイメージ・エディタが不要になります。

- WEMのAdminインタフェース: WEMのAdminインタフェースは、特に、ロールを使用してアプリケーションおよびユーザーのサイトへの割当てを管理者が管理できるように設計されています(図1-4)。

図1-4 WEMのAdminインタフェース

関連項目:

『Oracle WebCenter Sitesの管理』および「Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発」。

1.5 WebCenter Sitesのユースケース・シナリオ

WebCenter Sitesでは、ビジネス・ユーザー・コンテンツの作成、大規模な動的サイトの配信、コンテンツのテーゲット設定と最適化、ユーザー生成コンテンツ、エンド・ユーザーのパーソナライズ、マーケティングとリード生成、およびモバイルWeb配信の機能があります。

WebCenter Sitesは、様々な業界で使用され、マーケティング・キャンペーンを実行したり、ビジネス・リード創出したりするための、情報発信およびブランド確立を目的としたWebサイトを作成します。

次の各項では、WebCenter Sitesのユースケースついて説明します。

- 情報発信(ブランド確立)用Webサイトの開発

- 市場志向型Webサイトの作成

- モバイル用Webサイトの作成

1.5.1 情報発信(ブランド確立)用Webサイトの開発

WebCenter Sitesでは、製品およびサービスのブランド確立用Webサイトを開発するための使いやすく効率的な機能を提供します。最初に、WebCenter Sitesコアを使用して、基本インフラストラクチャを作成します。WebCenter SitesでWebサイトを設計する場合は、次の点を考慮してください。

- コンテンツ・タイプ: 最初に、サイト・コンテンツをどのように分類してWebCenter Sitesで設計するかを決定します。どのコンテンツ・タイプを構造化してバイナリにすべきか。コンテンツ・コントリビュータがWebCenter Sitesのフォーム・モードまたはWebモードで作成するコンテンツは構造化されますが、インポートされるコンテンツ(Microsoft Wordファイルなど)はバイナリです。
コンテンツ・タイプについては、アーキテクトが次を決定します。

- どのコンテンツ・タイプに変数属性が含まれ、どのコンテンツ・タイプに固定属性が含まれるようにするか。企業は既存の範囲の提供品を時々改善するため、コンテンツの製品モデルまたはサービス・タイプでは変数属性が必要になる場合があります。

- どのコンテンツを水平にし、どのコンテンツを階層化するか。たとえば、イメージは通常は水平タイプまたはベーシック・タイプになります。MP3プレーヤのヘッドフォンなどの製品アクセサリ・モデルは階層化できます。

- 製品またはサービスに基づいて、どのコンテンツを他のコンテンツから継承するか。製品モデルでは、親製品から属性を継承する必要が生じる場合があります。一部のコンテンツ・タイプはスタンドアロンになる場合があります。

- 一部のコンテンツ・タイプには、関連付けられたコンテンツが必要になる場合があります。たとえば、製品モデルの記事と同様の製品モデルまたは親製品の記事を関連付ける必要が生じる場合があります。

- 障害発生時にコンテンツをどのようにリカバリするか。

これらの考慮事項では、アセット・モデルおよびその実装を決定します。一般に、Webサイトではベーシック・アセットとフレックス・アセットを組み合せる必要があります。コンテンツ・タイプがWebCenter Sitesでどのように決定および設計されるかの詳細は、「アセット・モデルの理解」を参照してください。

- コンテンツ・ボリューム: コンテンツのボリュームを処理できるようにWebサイトを設計する必要があります。これはスケーラブルにする必要があります。

- ページ: ページには、再利用可能な多くのページレットが含まれます。ページを設計する場合は、パフォーマンス向上のために、再利用性の利点とキャッシング戦略を考慮します。詳細は、「テンプレートおよびCSElementのエレメントのコーディング」および「ページのデザインとキャッシングの理解」を参照してください。

- ページ・キャッシング: パフォーマンス向上のため、ページレットがいつ使用されるかを決定します。ページごとに使用される未キャッシュのページレットが少なくなるように、ページ・テンプレートを設計します。詳細は、「キャッシングの管理」を参照してください。

- テンプレート: テンプレートを設計する前に、テンプレート・コンポーネントが再利用されるシナリオと、ページレットが他のページで使用できるシナリオを考慮します。ページレットの一部の例: 多くのページで、上部、LeftNavおよびフッターが再利用される可能性があります。詳細は、「Webサイトの開発」を参照してください。

- コンテンツ・モード: WebCenter Sitesでは、フォーム・モードおよびWebモードをコンテンツ管理サイトに含めることができます。フォーム・モードはすぐ使用できますが、Webモードでは、制限されたロールを実行する使用頻度の低いユーザーが、アセットのレンダリングされた(プレビュー)バージョンから直接コンテンツを検索、編集および送信できます。Webモードでは、コンテンツ・コントリビュータが2つ以上のバージョンのWebページを比較して、どちらのバージョンが効果的かを判断することもできます。詳細は、「Webサイトの開発」を参照してください。

- コンテンツ管理(CM)サイト: CMサイトは、オンライン・サイトのコンテンツのソースで、オンライン・サイト全体を表すことも、そのセクションのいずれかを表すこともできます。CMサイトとそのオンライン・サイトが1つの場合、CMサイトが1つでオンライン・サイトが複数の場合、CMサイトとオンライン・サイトが複数の場合など、顧客のニーズを考慮して、CMサイトとオンライン・サイトをどのように設計するかを決定します。詳細は、『Oracle WebCenter Sitesの管理』のコンテンツ管理モデルに関する項を参照してください。

- 多言語要件: 顧客が探しているものを見つけます。顧客が大抵希望するのは、マスター言語でコンテンツを作成して、関連する他のコンテンツに接続してから(マスター言語でない場合もあります)、パブリッシュして後で翻訳することです。また、コンテンツと、関連する他の部分を最初に翻訳してから、全体を1つのパッケージとしてパブリッシュすることも希望します。顧客が、レンダリングされるコンテンツに特定の国に固有のルールを適用したいと考えているかどうかを判断します。詳細は、「多言語サポートのサイトの構成」を参照してください。

- ユーザー権限: アクセス制御リスト(ACL)を使用して、WebCenter Sitesデータベースおよびレンダリングされるページ(WebCenter Sitesによってサイト上に表示)へのユーザー・アクセスを制限します。WebCenter Sitesでは、ユーザー・タグを提供して、ユーザーのログインとログアウト、およびアカウントの作成とユーザー・プロファイルの編集も行います。一般的なユーザー権限の例: コンテンツの作成、編集、承認、WEM、AdminおよびContributorインタフェースへのアクセス権。様々なロールに対してどのようなタイプの全権限を作成するかを考慮します。詳細は、『Oracle WebCenter Sitesの管理』のユーザーの作成および認可に関する項および「セキュリティ: コンテンツ管理ユーザーの管理」を参照してください。

- セキュリティ: 開発者がオンライン・サイトの設計や管理システムのユーザー・インタフェースの変更の検討を開始する前に、管理者はセキュリティ・プロトコルを決定し、実装する必要があります。セキュリティ構成に関する決定は、オンライン・サイトのコード化および実装方法に影響を与えます。詳細は、『Oracle WebCenter Sitesの管理』の外部セキュリティの設定に関する項を参照してください。

- カスタマイズ: 顧客チームはContributorインタフェースを操作してWebサイトの編集と更新を行います。効率性と利便性のため、サイト・ツリー、ダッシュボード、アセット・フォーム、検索ビューなどのContributorインタフェース・コンポーネントをカスタマイズできます。詳細は、「Oracle WebCenter Sitesのカスタマイズ」を参照してください。

1.5.2 市場指向型Webサイトの作成

Oracle WebCenter Sitesでは、マーケティング担当者およびビジネス・ユーザーが、販売および顧客ロイヤルティ向けに、コンテキスト的に関連するWebサイト・コンテンツを簡単に作成および管理できます。パーソナライズおよびターゲット設定されたWebサイトの開発と、Webサイトの効果を分析して製品販売と新規顧客の創出を可能にするコンポーネントが提供されます。

Oracle WebCenter Sites: Engageを使用すると、サイトの訪問者および顧客に関する情報を収集するオンライン・サイトを設計できます。マーケティングでは、この情報を使用して、各訪問者に表示される製品の配置および販促用の提供品をパーソナライズできます。

Oracle WebCenter Sites: A/B Testing・モジュールでは、2つ以上のバージョンのWebページを比較して、販売を通してWebサイトの訪問者をWebサイトの顧客に変換可能な、最も効果的なバージョンを判断できる機能が提供されます。WebCenter Sitesでは、多くの方法でページ・バージョンの効果を分析できます。それらの一部には、リンクをクリックする、特定のページを訪問する。一定期間サイトに留まる、アイテムをショッピング・カートに追加するなどの行動があり、製品の販売もあります。詳細は、「A/B Testingの開発」を参照してください。

詳細は、「Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発」を参照してください。

1.5.3 モバイル用Webサイトの作成

WebCenter Sitesのモビリティ機能では、Webプレゼンスをモバイル・デバイスに拡張して、マルチチャネルのマーケティングおよび顧客体験を提供し、モバイル・サイトの管理の時間、コスト、労力を大幅に削減します。モビリティ機能を使用して、携帯電話やタブレットなどの様々なモバイル・デバイスでWebサイトを作成、プレビューおよび配信できます。モバイル用Webサイトの開発の詳細は、「モバイル用Webサイトの開発」を参照してください。

2 avisportsサンプル・サイトの概要

avisportsはスポーツを中心としサンプル・サイトで、イメージを添えたスポーツ記事が掲載されています。avisportsは、フォーム・モードおよびWebモードでのアセットの作成や編集など、Oracle WebCenter Sites: Contributorインタフェースでの機能を示すために使用します。また、avisportsでは、アセットの「作成」ビューおよび「編集」ビューをWebモードでレンダリングするようにコーディングされたサンプル・テンプレートが、開発者に提供されます。

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

- コンテンツ・コントリビュータとしてのavisportsサンプル・サイトのツアー

- avisportsサンプル・サイトのインフラストラクチャのツアー

2.1 コンテンツ・コントリビュータとしてのavisportsサンプル・サイトのツアー

Oracle WebCenter Sitesでできることを理解するには、最初に、WebCenter Sitesツールおよびテクノロジを使用して開発されるavisportsデモ・サイトをプレビューします。このサイトをプレビューするには、WebCenter Sitesインスタンスにログインします。デフォルトでは、Contributorインタフェースが起動します。

Contributorインタフェースの左側は、avisportsサイトの3つのサイト・ナビゲーションで構成される「サイト・ツリー」です。「デフォルト」サイト・ナビゲーション・ノードの下のavisportsサイトは、デスクトップおよびラップトップ・コンピュータ用です。「タッチ」サイト・ナビゲーション・ノードは、タッチ・スクリーン・デバイス用、非タッチ・サイト・ナビゲーション・ノードは、QWERTYキーパッド搭載の非タッチ・デバイス用です。これらのノードを展開すると、サイト・ページが表示されます。ページをダブルクリックすると、ページがWebモードで表示され、コンテンツ・コントリビュータでコンテンツを編集およびプレビューできます。

avisportsサイトは、単一または複数のデバイスのコンテキストでプレビューできます。avisportsを単一デバイスのコンテキストでプレビューするには、右側の「デバイスの表示/非表示」アイコンをクリックして、このサイトをプレビューするデバイスを選択します。マルチデバイス・プレビューの場合は、「マルチデバイス・プレビュー」アイコンをクリックします。これらのプレビューには、サイト訪問者のデバイスでサイトがどのように表示されるかを示します。

これらの機能の詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

2.2 avisportsサンプル・サイトのインフラストラクチャのツアー

次に、Adminインタフェースでavisportsサイトの各部について見てみましょう。WebCenter Sitesインタフェースの左上の「管理」アイコンをクリックして、Adminインタフェースに切り替えます。

Adminインタフェースで、「サイト」をクリックして、そのコンテンツを表示します。「サイト・ナビゲーション」ノードを開きます。Contributorインタフェースの「サイト・ツリー」に表示されるのと同じアセットを含むノードが3つあります。サイト・ナビゲーション・ノード(「デフォルト」、「タッチ」非タッチ)を開くと、「ホーム」ページ、ナビゲーション・パージ、記事およびイメージが表示されます。

「サイト管理者」ノードを開き、「アセット・タイプ」ノードを開くと、avisportsサイトに対して有効にしたアセットが表示されます。

「サイト・ナビゲーション」ノードを開きます。これにより、新しいサイト・ナビゲーションの作成と、既存のサイト・ナビゲーションの並べ替えが可能になります。

「一般的な管理」ツリーで、「モビリティ」ノードを開きます。「デバイス・グループ」、「デバイス」、「デバイス・リポジトリ」およびイメージのプロパティ」の各ノードが表示されます。これらのノードは、タッチ・スクリーン・デバイスおよびQWERTYデバイス用にavisportsサイトを設計する場合に使用されています。

avisportsサイトに使用されるテンプレートを表示するには、ツールバーの「検索」をクリックします。「検索」ドロップダウン・リストで、「接尾辞」を選択し、「検索文字列」ドロップダウン・リストでデフォルトの「すべて」を選択します。これらの選択により、デスクトップおよびラップトップ・デバイス、タッチ・スクリーン・デバイス、および非タッチQWERTYデバイス向けのavisportsに使用されるテンプレートが表示されます。

Adminインタフェースには、Contributorインタフェースでプレビューしたサイトのインフラストラクチャが表示されます。

開発プロセスの概要を理解するには、「WebCenter Sitesの開発プロセス」を参照してください。WebCenter Sitesで開発可能なWebサイトのタイプの詳細は、「WebCenterサイトのユースケース・シナリオ」を参照してください。

3 WebCenter Sitesの開発プロセス

オンライン・サイトを開発する場合は、配信システムから訪問者のブラウザに配信されるオンライン・サイトと、コンテンツ・プロバイダが管理システムから配信システムにパブリッシュするデータを入力するために使用するコンテンツ管理サイトという2つのサイトを実際に設計します。

言い換えると、次の2種類のエンド・ユーザーのユーザー作業環境を担当します。

- 配信システムを使用するサイト訪問者

- 管理システムを使用するコンテンツ・プロバイダ

これら2つの、緊密につながってはいるが別々のサイトを作成する際には、開発チームは、計画立案、開発、テストという一連の手順を実行します。この章では、1つの考えられるイベントの流れで、そして一般的な用語で、開発プロセスについて説明します。実際のワークフローは、作業環境とビジネス・ニーズに応じて異なります。

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

- 手順1: チームを発足する

- 手順2: 機能とデザインの仕様を作成する

- 手順3: 管理システムの要件を設定する

- 手順4: データ・デザインを実装する

- 手順5: オンライン・サイトを構築する

- 手順6: 管理システムを設定する

- 手順7: 配信システムを設定する

- 手順8: 配信システムにパブリッシュする

3.1 手順1: チームを発足する

最初の手順は開発チームを結成することであり、チームは次のような人たちで構成します。

- ソリューション・アーキテクト(サイト設計者)

- XMLおよびJSP開発者

- Javaアプリケーション開発者

- データベース管理者

- システム・ネットワーク管理者

- マーケティング担当者および広告担当者

- 製品マネージャ(商用サイトを開発している場合)

- コンテンツ・プロバイダ

開発チームには、データベース管理者、システム管理者、コンテンツ・プロバイダなどの人たちが必要であり、(開発者のように)次のような様々な理由で実際のコーディングを行う人たちも必要です。

- ページ・デザインを作成することに加えて、データ・モデルを設計する必要があります。つまり、各システム上のデータベースをサポートするデータベース管理者から、早めに情報を入手する必要があります。

- 複数の別々のシステム(そのうちのいくつかはクラスタ化されている可能性が高い)で、コードとデータをあちこち動かす必要があります。つまり、システム管理者およびネットワーク管理者から、早めに情報を入手する必要があります。

- WebCenter Sitesシステムの実装は、コンテンツ・プロバイダの作業習慣が管理システムの設計に正確に反映されているかどうかに依存します。管理システムを使用する人たちから、早めに情報を入手する必要があります。

3.2 手順2: 機能とデザインの仕様を作成する

Oracle WebCenter Sitesのコンテンツ管理システムから配信されるオンライン・サイトは、すべてを包括した構成体で、その中ではすべてのものが他のすべてのものと対話、交差および作業します。したがって、2番目の手順は、機能仕様とデザイン仕様を作成すること、すなわちオンライン・サイトを紙上で設計することです。何かのコーディングを始める前に、この手順のなんらかのバージョンを完了する必要があります(デザイン仕様を作業する際に、なんらかの概念検証コーディングを行う場合もあり)。

3.2.1 機能要件

デザインの指定を開始する前に、製品管理とマーケティングでは、オンライン・サイトに機能要件を提供する必要があります。

3.2.2 ページのデザイン

マーケティング担当者からの機能要件の入手後、最初に行う作業としては、オンライン・サイトに提示するすべてのタイプのページを策定することをお薦めします。たとえば、ホーム・ページ、セクション・ページ、コラムニスト・ページ、検索ページ、記事ページです。商用ページを設計する場合は、登録ページ、製品カテゴリ・ページ、製品の説明ページ、記事ページ、FAQページ、請求書ページなど、他の種類のページが必要です。

各ページおよびサイト全体のグラフィック、ナビゲーション、機能の各面での特徴を決定します。具体的には、ナビゲーション・バー、購入ボタンとショッピング・カート、詳細ボタン、検索機能、ロゴの配置、アニメーション化されたグラフィックなどです。

Oracle WebCenter Sites: Engageを使用している場合は、マーチャンダイジング・メッセージ(推奨)をページのどこに配置するか、またどのページに配置するかを判断します。たとえば、それぞれの製品カテゴリ・ページには、ページの右上隅に新製品という名前のセクションが含まれる場合があります。

サイトの構造全体を策定して、原寸大の模型を作成します。

3.2.3 キャッシュ戦略

デザインにおける代表的なエレメントはキャッシングで、ページ・キャッシングと結果セット・キャッシングがあります。キャッシュ戦略を計画、テスト、実装しないと、オンライン・サイトはパフォーマンスの目標を達成できません。オンライン・サイトに提示するページを設計する際には、各ページの断片ごとに、ページ・キャッシングをいつどのように実装できるか、また実装する必要があるかを検討する必要があります。問合せを設計する際には、データベース内のすべての表を策定し、それぞれの表に結果セット・キャッシング設定をどのように設定するカスタマイズを決定します。

3.2.4 セキュリティ戦略(アクセス制御)

ページを正しく設定できるようにするためには、設計プロセスの初期段階で、どのような種類のアクセス制御を実施するかを決定する必要があります。たとえば、オンライン・サイトのどの部分にアクセスする場合も、事前に訪問者にIDを明らかにしてもらう必要があります。訪問者がページにアクセスすることを許可する前に訪問者のアイデンティティをチェックする必要がある場合、これは、そのページの構成要素のキャッシュ方法に影響します。キャッシュされることのないコンテナ・ページを設計することもできます。このページは、訪問者のアイデンティティを検証し、この検証が成功した場合にかぎって、キャッシュされたページレットからページを組み立てます。

3.2.5 フォーマットとコンテンツの切離し(アセットのエレメント)

コンテンツとフォーマットを切り離すという基本的な提案に続いて、サイト内に提案された各ページの各断片を見て、その断片をデータとロジックのいずれで表すかを決定します。

データがアセットとして表されるように設計され、エレメント・コードに埋め込まれていないというのが優れたデザインです。デザインまたはコンテンツのすべての構成要素を調べて、アセットが何であるかを判別します。その判別を行うには、データとロジック/コードどちらのカテゴリに構成要素が属しているかを判断します。

簡潔に言えば、本当はデータであれば、エレメントにコーディングしない(ロジックに埋め込まない)でください。データは別のアセットに入れる必要があります。

別の見方を次に示します。

- コンテンツを表すアセットは、コンテンツ・プロバイダの担当です。

- ロジック(任意のエレメントにコーディングされているもの)は、開発者の担当です。

3.2.5.1 アセット・タイプ(コンテンツ)の判別

ドキュメント、記事、製品およびイメージは、簡単にアセットと識別されます。ただし、ヘッダーやフッターなどのデザイン構成要素もアセットになり得ます。

- ヘッダーまたはフッター内のコンテンツがエレメントのコードに埋め込まれている場合は、コンテンツ内の何か(電話番号やロゴなど)が変更されたら、担当開発者または別の開発者がコンテンツ内のテキストを変更する必要があります。

- ヘッダーまたはフッター内のコンテンツがアセットに含まれている場合は、エレメント内のコードはそのアセットのIDを取得できる必要があります。そのコンテンツは、コンテンツ・プロバイダの担当になります。

ページのそれ以外の構成要素でアセットになり得るものには、次があります。

- アニメーションなどのメディア

- その日の相場

- 会社または株式のプロファイル

- ナレッジ・ベースの質問と回答

開発者の視点では、アセット内に表されている構成要素のコンテンツは他の人間が担当します。自分で担当するのは、オンライン・サイトのどこにいつ表示するか、そして表示したときの外観をどのようにするかのみです。

3.2.5.2 イメージなどのBLOBの処理方法の判断

オンライン・サイトで使用するイメージなどのBLOBを管理する方法を判断する際には、次の2つの一般的なオプションがあります。

- アセットとして扱う: WebCenter Sitesデータベースに格納し、BlobServerサーブレットで提供します。

- 静的ファイルとして扱う: Webサーバー上のファイル構造に入れて、Webサーバーで提供します。

どちらの方法も有効なオプションです。WebCenter Sitesタグを使用してWebサーバーに格納されているイメージ・ファイルへのリンクを作成できます。Webサーバーがイメージを配信できるようにすると、パフォーマンス上のメリットを得ることができます。ただし、イメージとBLOBをWebCenter Sitesデータベースから切り離しておく場合は、次のようになります。

- 別のファイル管理プロセスを実装する必要があります。管理システムから配信システムにイメージ・アセットを移動するパブリッシュ方法では、WebCenter Sitesデータベース内にないコンテンツを移動することはできません。このプロセスは自分で管理する必要があります。

- WebCenter Sitesのネイティブ・セキュリティ・メカニズムはどれも当てはまりません。つまり、WebCenter Sitesで管理されていないBLOBへのアクセスを制限する場合、ACLは使用できません。

3.2.5.3 機能デザインとフォーマットの策定(エレメント)

オンライン・サイトに組み込む予定の機能のすべてを分析します。商用サイトの一部は、どちらかというとアプリケーションのように動作することは疑いありません。訪問者の登録ページ、訪問者のデータ・コレクション・ページ、ショッピング・カート、パーソナライズなどに必要なコードまたはロジックが何であるかの概略を記します。

WebCenter Sitesシステムに用意されているコーディング・オプションが、Java、XMLおよびJSPであることを忘れないでください。実現しようとしている機能のそれぞれを見ていき、その機能にとって最適のコーディング解決策がどれであるかを判別します。

3.2.6 データ・デザイン

サイトの断片のいずれをアセットとして表す必要があるかがわかったら、アセット・タイプを何にすべきかを策定できます。それぞれの新規アセット・タイプでは、データベース表を1つ以上使用します(ベーシックとフレックスいずれのアセット・タイプであるかによって異なります)。

3.2.6.1 アセット・タイプ

ベーシックとフレックスどちらのアセット・モデルを使用する場合でも、アセット・タイプを設計する際には次の点を検討してください。

- アセット・タイプのデザインは、設計対象とするユーザー・グループの両方(オンライン・サイトへの訪問者と、データを入力するコンテンツ・プロバイダ)に影響を与えます。

- ページ・デザインを正常に実装するためには、いずれのタイプのアセットを、他のタイプの他のアセットにリンクまたは関連付ける必要がありますか。これらの関係を、アセット・タイプに忘れずに実装してください。

- 使用する予定が本当にあるデータのみをアセット・タイプに格納して、だれも使用しないデータを保持することにコンテンツ・プロバイダが時間を浪費しないようにしてください。

3.2.6.2 アセット・タイプをサポートする補助表

システムに実装するデータ・デザインは、アセットを保持しているデータベース表を越えています。提供する情報の種類によっては、アセット・タイプをサポートする補助表を作成することが必要になる場合もあります。たとえば、Mimetypeドロップダウン・リストを持つアセット・タイプが含まれるサイトの場合、ユーザーはこのリストから値を選択する必要があります。MimeTypeという名前の参照表を作成し、これらの値をこの表示から取得できます。ニーズによっては、使用システムで同様の表を作成することが必要になる場合もあります。

作成する予定のあるアセット・タイプおよび補助表についての議論にはデータベース管理者にも参加してもらい、管理システムと配信システムで発生する可能性のある種類のデータベース・チューニング問題を理解してもらってください。

3.2.6.3 訪問者データ

Engageを使用している場合は、訪問者のどのようなデータを収集するかを判別します。これらのデータ型は、Engageの訪問者データ・アセットで表され、訪問者のIDに基づいてサイトをパーソナライズする際にセグメントを作成するために使用します。たとえば、人口統計、購入履歴、クリックストリームなどの情報です。

WebCenter Sitesシステムが本番稼働し、訪問者のデータ収集を開始したら、そのデータを格納する表はすぐに大きくなります。これも、データベース管理者と相談しておく必要のある分野です。

3.3 手順3: 管理システムの要件を設定する

コーディングを開始する前に、管理システムをどのように編成するかを知っておく必要があります。デザインはコンテンツ管理サイトに応じて異なるため、これらの意思決定がデザインに影響を与えます。

コンテンツ管理サイトとは、実際のオンライン・サイト向けの組織構成メンバーとして、またアクセス制御ツールとして使用するオブジェクトです。テンプレート・アセットを作成すると、WebCenter Sitesでは、SiteCatalog表でエントリが作成されます。ページ・エントリのネーミング規則には、テンプレートの作成対象となるコンテンツ管理サイトの名前が含まれます。つまり、コンテンツ管理システム全体(開発システム、管理システムおよび配信システム),で整合性を維持する必要があり、コーディングを開始する前に、使用しているサイトの名前を知っておく必要があります。

第1の関心事は各サイトの名前ですが、システム管理者とビジネス・マネージャは次の点も決定する必要があります。

- 必要なユーザーおよびACL(アクセス制御リスト)の数(オンライン・サイトの訪問者に割り当てるACLを作成する必要がある場合もあることに注意)

- 必要なサイト・ロール数

- どのアセット・タイプがワークフロー・プロセスを必要とするか

- リビジョン追跡を使用する必要があるアセット・タイプ

- どのユーザーがどのサイトのどのアセット・タイプへのアクセス権を持つ必要があるか

このガイドと『Oracle WebCenter Sitesの管理』の両方を使用すると、これらの決定を下しやすくなります。

3.4 手順4: データ・デザインを実装する

デザイン仕様を作成し、管理システムの構成を理解したら、データ・デザインを実装できます。

開発システムで、次の種類のタスクを完了します。

- 管理システムで使用される名前と同じ名前でコンテンツ管理サイトを作成します。詳細は、『Oracle WebCenter Sitesの管理』のAdminインタフェースからのサイトの作成に関する項を参照してください。

- アセット・タイプを設計して作成します。詳細は、「ベーシック・アセット・タイプの作成」および「フレックス・アセット・ファミリの作成」を参照してください。

- アセット・タイプに対して参照表などの補助表を追加します。

- 各タイプのサンプル・アセットを作成します。詳細は、『Oracle WebCenter Sitesの使用』のフォーム・ビューでのアセットの作成に関する項を参照してください。

この手順と「手順5: オンライン・サイトを構築する」は反復作業であり、多くの部分が重複する可能性が高いと考えられます。アセット・タイプを作成して、テンプレート作成前にアセットを作成できるようにする必要がある一方、データ・デザインに改良が必要な領域が明らかになるのは、テンプレートのコーディングとコードのテストを行った後のみになる可能性が高いと思われます。

3.5 手順5: オンライン・サイトを構築する

たった1つのタイプでもサンプル・アセットを開発システム上に作成したら、テンプレートのコーディングおよびオンライン・サイトの構築を開始できます。(実際は、デザイン仕様を作成した後であれば、アセットを表示しないエレメントのコーディングをいつでも開始できます。)

この手順では、次の種類のタスクを完了します。

- オンライン・サイトの機能を実装した、ページ、問合せ、コレクションの各アセットを作成します。詳細は、「コレクション・アセット、問合せアセットおよびページ・アセットの作成」を参照してください。

- Engageを使用している場合は、訪問者データ・アセット、サンプル・セグメント、推奨事項およびサンプル・プロモーションを作成します。詳細は、「Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発」を参照してください。

- アセット・タイプのすべてに対し、テンプレート・アセットを登録(してテンプレート・エレメントをコーディング)します。詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

- Oracle WebCenter Sites: ContributorインタフェースのWebモード機能については、insiteファミリのタグを使用してテンプレートをコーディングします。詳細は、「コンテキスト内コンテンツ編集用テンプレートのコーディング」を参照してください。

- 基礎となる機能を実装する(アセットを表示しない) CSElementをコーディングします。詳細は、「CSElementアセットの作成」を参照してください。

- 商用サイトについては、ショッピング・カートを実装するページをコーディングします。詳細は、「ショッピング・カートおよびEngageについて把握する必要がある内容」を参照してください。

- Engageを使用している場合は、訪問者データを収集するページをコーディングします。詳細は、「訪問者データの収集」を参照してください。

- すべてをテストします。
オンライン・サイトに対して操作性と市場性に関する両方のテストを実行します。

オンライン・サイトの構築の詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

3.6 手順6: 管理システムを設定する

オンライン・サイトが開発システムで稼働するようになったら、オンライン・サイトを管理システムに移動します。

開発者は、次のタスクを実行します。

- コンテンツ管理サイトおよびそのすべてのコンポーネントを管理システムにパブリッシュします。詳細は、『Oracle WebCenter Sitesの管理』のリアルタイム・パブリッシュでの作業に関する項を参照してください。

次にシステム管理者は、次の種類のタスクを完了します。

- ユーザー、ACLおよびロールを作成します。コンテンツ管理サイトごとに、ユーザーにロールを割り当てます。詳細は、『Oracle WebCenter Sitesの管理』のACLおよびロールでの作業に関する項を参照してください。

- ワークフロー・プロセスを作成します。詳細は、『Oracle WebCenter Sitesの管理』のワークフロー・プロセスの作成および管理に関する項を参照してください。

- StartMenuショートカットを作成します。詳細は、『Oracle WebCenter Sitesの管理』のスタート・メニュー・アイテムの作成に関する項を参照してください。

- リビジョン追跡を有効にします。詳細は、『Oracle WebCenter Sitesの管理』のリビジョン追跡の有効化に関する項を参照してください。

管理システムの設定の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

3.6.1 コンテンツをアセットとしてインポート

コンテンツは、使用するなんらかの非アセット・フォーマットになっていると考えられます。このコンテンツをWebCenter Sitesデータベースにアセットとしてインポートするには、XMLPostユーティリティを使用します。詳細は、「XMLPostユーティリティを使用したアセットのインポートについて」を参照してください。

3.6.2 カタログ・データおよびフレックス・アセット・データのインポート

フレックス・アセット・モデルの場合、BulkLoaderユーティリティを使用して既存の大量のデータをインポートできます。詳細は、「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。ただし、システム化された更新の場合は、XMLPostユーティリティを使用します。詳細は、「XMLPostユーティリティの使用」を参照してください。

3.6.3 サイトのデザインについて編集チームに指示

編集チームがオンライン・サイトを正常に維持できるようにするには、デザインを理解しておく必要があります。たとえば、コレクションをどのくらいの頻度で再構築するかなどがあります。

ベーシック・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

- 該当する問合せおよびコレクション別にアセットが検索されるようにするには、アセットにどのカテゴリおよびソースを割り当てるべきか。

- どのテンプレートをどのアセットに割り当てるべきか。

- サイト・ページ上のリンクが正常に機能するようにするには、どのアソシエーション・フィールドにデータを入力する必要があるか。

アセット・タイプごとに開発者とシステム管理者が作成するスタート・メニュー・ショートカットに、できるだけ多くの情報をプログラムすることをお薦めします。

フレックス・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

- フレックス・アセットに定めた一般的な階層または分類。

- フレックス・アセットが何の情報を継承するかについての情報。

- どのテンプレートをどのアセットに割り当てるべきか。

3.7 手順7: 配信システムを設定する

配信システムを設定する場合、管理システム上のアセットのすべてを配信システムにパブリッシュします。配信システムは公に対するサイトをホストするため、実際のビジネス・サイト・コンテンツを作成するためにコンテンツ・コントリビュータおよびマーケティング担当者用として管理システム上で構成したスタート・メニュー、ワークフロー、リビジョン追跡などは必要ありません。

また、このシステムは管理システムでないため、次の手順も完了します。

- セキュリティ戦略を実装します。詳細は、『Oracle WebCenter Sitesの管理』の外部セキュリティの設定に関する項を参照してください。

- Webサーバーで、自分のサイトのURL (www.example.com)を、ホーム・ページのWebCenter SitesのURLにマップします。詳細は、『Oracle WebCenter Sitesの管理』のWebサーバーのURL接頭辞のマッピングに関する項を参照してください。

配信システムの設定の詳細は、『Oracle WebCenter Sitesの管理』のパブリッシュに関する項を参照してください。

3.8 手順8: 配信システムにパブリッシュする

管理システム上のコンテンツが準備できたら、配信システムにパブリッシュします。パフォーマンスと負荷の両面で集中的なテストを実施した後で、サイトを世間に公開します。詳細は、『Oracle WebCenter Sitesの管理』のリアルタイム・パブリッシュでの作業に関する項を参照してください。

第II部 データ・モデルの構築

この部は、アセット・モデルの詳細な概要から始まります。ここでは、ベーシック・アセット・タイプとフレックス・アセット・タイプの設計およびフレックス・ファミリの作成について詳しく説明します。フレックス・フィルタ・クラスについて、およびフレックス・フィルタ・アセットの作成方法について説明します。また、この部には、属性エディタの設計および属性エディタのインスタンスの構成の手順も含まれます。最後に、WebCenter Sitesデータベース内の表と列の様々な種類、表の作成方法、およびアセットが保持されていないデータベース表とのやり取り方法について説明します。

この部は、次の章で構成されています。

- アセット・モデルの理解

- ベーシック・アセット・タイプの設計

- フレックス・アセット・タイプの設計

- 階層的なフレックス・ファミリの作成

- フレックス・アセットの作成

- 属性エディタの設計

- 付属の属性エディタの構成

- WebCenter Sitesデータベースでの作業

- アセットを保持しない表内のデータ管理

4 アセット・モデルの理解

ほとんどの場合、データ・デザインはアセット・デザインを意味します。ただし、開発者はアセットの基礎データを保持する表を頻繁に作成する必要があります。これらの表の必要性を決定し、表を設計する作業もデータ・デザインの一部です。

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

- アセット・タイプとアセット・モデルについて

- ベーシック・アセット・モデル

- フレックス・アセット・モデル

- assetsetおよびsearchstate

- 検索エンジンと2つのアセット・モデル

- タグと2つのアセット・モデル

- 要約: ベーシック・アセット・モデルとフレックス・アセット・モデル

注意:

アセットを保持しない表の設計と作成については、「WebCenter Sitesデータベースでの作業」で説明します。

4.1 アセット・タイプとアセット・モデルについて

アセットとは、WebCenter Sitesデータベースに格納されているオブジェクトで、作成、編集、調査、削除、複製、ワークフローへの配置、リビジョン追跡による追跡、検索、および配信(ライブ)サイトへのパブリッシュが可能なオブジェクトのことです。

アセット・タイプとは、該当するタイプのアセット・オブジェクトの特性を決定する定義または仕様です。

図4-1に、WebCenter Sitesコンテンツ・エントリ・フォームと、フィールド名およびフィールド値とアセット・タイプのデータベース表の関係を示します。

図4-1 アセット・タイプ: データベース表とWebCenter Sitesのフォーム

開発者は、アセット・タイプの設計および作成を行うと同時に、コンテンツ管理システムとオンライン・サイトの設計も行います。コンテンツ・プロバイダは、これらのタイプのアセットを作成および編集します。

一般的に、アセットは次の3つのロールのいずれかを実行します。

- 訪問者がオンライン・サイトで読み取ったり調べたりするコンテンツの提供

- コンテンツ表示用の書式設定ロジックまたはコードの提供

- WebCenter Sitesデータベースへのコンテンツ格納用のデータ構造の提供

開発者の仕事は、コンテンツ・プロバイダにとって管理システムで操作しやすく、配信システムから訪問者に効率的に配信可能なアセット・タイプを設計することです。

次の内容について理解してください。

- 2つのデータ・モデル

- デフォルトのコアなアセット・タイプ

- コンテンツを表すために使用するアセット・モデルはどれか

4.1.1 2つのデータ・モデル

WebCenter Sitesには、設計したアセット・タイプ用に、ベーシックとフレックスという2つのデータ・モデルが用意されています。

- ベーシック: アセット・タイプは、単純なデータ構造を備えています。1つのプライマリ記憶域表と、お互いの間に単純な親子関係が設定されています。
ベーシック・アセット・タイプは独立したスタンドアロン・アセット・タイプであり、記事、イメージ・ファイル、ページ、問合せなど、個別の種類のコンテンツを表しています。(「一般的な管理」ツリーの「管理」ノードにある) AssetMakerユーティリティを使用して、ベーシック・アセット・タイプを作成します。

- フレックス:・アセット・タイプは、複数のデータベース表を備えた複合データ構造になっており、ベーシック・アセット・タイプよりも多くのフィールドをサポートできます。さらに、複数の親や任意の数の祖父母などを割り当て、そこから属性値を継承することもできます。
フレックス・アセット・タイプは、相互に定義したり、相互に属性値を割り当てるアセット・タイプのファミリで構成されます。(「一般的な管理」ツリーの「管理」ノードにある)フレックス・ファミリ・メーカー・ユーティリティ・を使用して、フレックス・アセット・タイプのファミリを作成します。

4.1.2 デフォルトのコアなアセット・タイプ

WebCenter SitesとOracle WebCenter Sites: Engageにより、複数のコア・アセット・タイプが配信されます。WebCenter Sitesはスタック・アーキテクチャで構成されているため、コアなアセット・タイプは次の方法で利用可能になります。

- WebCenter Sitesからテンプレート、問合せ、コレクション、SiteEntry、CSElement、リンク、およびページのアセット・タイプが配信されます。その他のモジュールおよび製品はすべて、テンプレートおよびページのアセット・タイプを使用します。

- WebCenter Sitesから属性エディタのアセット・タイプが配信されます。作成したフレックス属性アセット・タイプはいずれもサポートされます。

- Engageから訪問者属性、履歴属性、履歴定義、セグメント、推奨、およびプロモーションのアセット・タイプが配信されます。

これらのタイプのアセットは、アセットの取得、順序付け、編成、書式設定によって、コンテンツを保持しているアセット・タイプの表示用にフォーマットまたはロジックを提供します。つまり、コアなアセット・タイプを使用してオンライン・サイト上でコンテンツの編成と書式設定を行います。

4.1.2.1 WebCenter Sitesで配信されるアセット・タイプ

WebCenter Sitesで配信されるアセット・タイプは、基本的なサイト・デザイン・ロジックを提供します。これらのタイプのアセットは必要に応じていくつでも作成できますが、アセット・タイプ自体は変更できません。

- 問合せ: 選択したパラメータまたは基準に基づいてアセットのリストを取得する問合せが格納されます。問合せアセットはページ・アセット、コレクション、および推奨で使用します。データベース問合せは、問合せアセットに対してSQL問合せとして「新規」フォームまたは「編集」フォームに直接書き込むか、「新規」フォームまたは「編集」フォームで特定されたエレメント(WebCenter Sitesの問合せタグが付いているもの、または検索エンジン問合せ)に書き込むことができます。

- コレクション: 1つのタイプのアセットの順序付けリストが格納されます。コレクションの構築は、1つ以上の問合せを実行し、その結果セットからアイテムを選択し、選択したアイテムをランキングする(順序付ける)ことによって行います。このランキングされ、順序付けられたリストがコレクションです。たとえば、前夜の選挙結果に関する記事が1位になるように政治関連記事のコレクションをランキングできます。

- ページ: 他のアセットに対する参照が格納されます。ページ・アセットの配置と設計によって、組織の表示方法やサイトのデザインが決まります。ページ・アセットの設計は、適切なコレクション、記事、イメージ・ファイル、問合せなどをページ・アセット用に選択して行います。さらに、WebCenter Sites Adminインタフェースの左側にサイトをツリー表示するサイト・ナビゲーション・ノードにページ・アセットを配置します。
ページ・アセットとWebCenter Sitesのページがまったく異なることに注意してください。ページ・アセットは、サイト・ナビゲーション・ノードでサイト・デザイン補助として使用したり、エレメント内のデータを特定するために使用する編成構造です。WebCenter Sitesのページは、ブラウザに表示されたり、他の機構によって表示されるレンダリングされたページです。

- テンプレート: 他のアセットをWebCenter Sitesのページおよびページレットにレンダリングするコード(XMLまたはJSPおよびJava)が格納されます。開発者は、同一タイプのアセットがすべて同じように書式設定されるように、テンプレートの標準セットを(CSElementおよびSiteEntry以外の)アセット・タイプごとにコーディングします。
コンテンツ・プロバイダは、コード自体にアクセスしたりコーディングする必要もなく、テンプレートを選択してコンテンツ・アセットをプレビューできます。

- CSElement: アセットをレンダリングしないコード(XMLまたはJSPおよびJava)が格納されます。通常は、複数のテンプレート(バナーなど)からコールする共通のコードに対してCSElementを使用します。また、CSElementは、EngageでDynamicList推奨の作成に必要な問合せを提供する場合にも使用します。

- SiteEntry: WebCenter Sitesのページまたはページレットを表すものであり、そのページを生成したルート・エレメントとしてCSElementが割り当てられています。テンプレート・アセットは、エレメントとWebCenter Sitesのページの両方を表すため、SiteEntryアセットは関連付けられていません。

- リンク: 外部WebサイトのURLが格納されます。このアセットは、外部リンクを別のアセット内に埋め込むために使用します。

- 属性エディタ: フレックス・アセットまたはフレックス親アセットに対してフレックス属性が「新規」フォームまたは「編集」フォームに表示されるときに、その属性に対してデータ入力方法を指定する属性エディタです。これはテンプレート・アセットに類似しています。ただし、テンプレート・アセットとは異なり、属性値をオンライン・サイトに表示するときではなく、そのインタフェースに属性を表示するときにWebCenter Sitesで使用するコードを特定する場合に使用されます。

WebCenter Sitesのコンテンツ管理システムを使用する各組織のデータ・ニーズはそれぞれ異なるため、コンテンツを表示するデフォルトのアセット・タイプは用意されていません。ただし、サンプル・コンテンツのアセット・タイプがサンプル・サイトから配信されるため、そのアセット・タイプを調べて、各自のサイトに応じて変更できます。

4.1.2.2 Engageで配信されるアセット・タイプ

Engageアプリケーションから配信される複数のコアなアセット・タイプを使用して訪問者情報を収集し、訪問者別に表示される製品の配置や販促用の提供品をパーソナライズできます。

- 訪問者属性: 1つの特性のみ(スカラー値)を指定する情報のタイプが保持されます。たとえば、years of experience、job title、number of childrenのような名前の訪問者属性を作成できます。

- 履歴属性: Engageで単一レコードとして扱われる情報のベクターを作成するためにグループ化した個々の情報タイプです。データのこのベクターが履歴定義です。たとえば、purchasesという履歴タイプは、SKU、itemname、quantityおよびpriceという履歴属性で構成できます。

- セグメント: 共通の特性(訪問者属性および履歴タイプ)に基づいて訪問者をグループに分けるアセットです。セグメントの作成は、セグメントの基となる訪問者データ・アセットを決定し、その基準に対して適格値を設定することによって行います。たとえば、アラスカの住民でフライ・フィッシングの道具一式を所有している人々や、過去6か月以内にパソコンを購入した人々などをセグメントで定義できます。

収集する訪問者データを定義して分類した後、次のアセット・タイプを使用して、オンライン・サイトにコンテンツを表示するフレックス・アセットの選択、編成、表示を行います。

- 推奨: コレクションの拡張版のようなものです。これは、フレックス・アセット(製品や記事など)を収集、評価、ソートし、現在の訪問者が属するセグメントに基づいて、その訪問者に最適なものを推奨します。

- プロモーション: サイト訪問者が購入しようとしているフレックス・アセット(製品など)と訪問者が資格を有するセグメントに基づいて、ある種の価値または割引を訪問者に提供するマーチャンダイジング・アセットです。

注意:

Engageは、フレックス・アセット・モデルのみを使用して作成されたアセットと対話します。推奨とプロモーションをプログラミングして、ベーシック・アセット・モデルを使用するアセットを操作することはできません。

4.1.3 コンテンツを表すために使用するアセット・モデルはどれか

WebCenter Sitesのコンテンツ管理システムによるオンライン・サイトの設計中に、開発チーム全員でサイト用にコンテンツを表示する必要のあるアセット・タイプを作成します。WebCenter Sitesのテンプレートおよびページ・アセット・タイプにより、ベーシック・データ・モデルとフレックス・データ・モデルのいずれを使用しているかに関係なく、データを表すアセット・タイプに対して書式設定フレームワークが提供されます。

オンライン・サイトに表示するデータを表すために選択する必要のあるアセット・データ・モデル(ベーシックまたはフレックス)は、次の2つの項で説明するように、そのデータの特性に依存します。

- ベーシック・モデルを使用する場合

- フレックス・モデルを使用する場合

4.1.3.1 ベーシック・モデルを使用する場合

データに次の特性が備わっている場合は、ベーシック・モデルを選択します。

- 固定していて、予測可能です。つまり、アセット・タイプに属性を追加する必要はありません。

- 同種です。つまり、同一タイプのアセットはすべて類似属性を持っています。

- 適度な数の属性を持っています。ベーシック・アセット用にアセット・タイプに割当て可能な列/属性の数に関して、データベースによる制限があります。

- 静的なパブリッシュ方法を使用したい場合。静的なパブリッシュ方法の使用が合理的と見なされるフレックス・アセット・モデルのアプリケーションは非常に限られています。

- 訪問者は、リンク間を移動してオンライン・サイトを参照します。

アセット・タイプのデータがスプレッドシートと推測でき、そのタイプの各アセットが単一レコードであり、すべてのレコードに同じ列が含まれている単純なフラット・テーブルと推測できる場合には、そのアセット・タイプにベーシック・アセット・モデルを使用する必要があります。

4.1.3.2 フレックス・モデルを使用する場合

データに次の特性が備わっている場合は、フレックス・モデルを選択します。

- 数多くの属性を持ちます。たとえば、製品には数百もの属性を割り当てられる可能性があります。フレックス・ファミリ・メンバーの属性値は、列ではなく行として格納されるため、フレックス・アセットは物理的にベーシック・アセットよりも多くの属性を持つことができます。

- これは、アセットが親アセットから属性値を継承する階層で表すことができます。

- 属性が将来必要になるか、また、データに定期的に属性を追加する必要があるかは予測できません。

- 同一タイプのアセット・インスタンスは大幅に変動する可能性があります。つまり、同一タイプのアセットがすべて同じ属性を持っている必要はありません。たとえば、バスタオル製品アセットには、トースタ製品アセットにはない属性が割り当てられますが、バスタオルもトースタもともに製品アセットです。

- 訪問者は、ドリルダウン、つまりデータの属性値に基づく検索を通して移動することによって、オンライン・サイトを参照します。

- Engageを使用する場合。

マーケットは絶えず変動しているため、製品はフレックス・アセット・モデルに適合します。翌年にどの製品が売れるか、または製品にどの属性が割り当てられるかを常に予測できるとはかぎりません。

ビジネスでアセット・タイプの属性を追加または変更するなど、アセット・タイプに変更を加える必要が生じる場合には、フレックス・データ・モデルが最適です。フレックス・アセット・モデルは、予測不能な特性を持つデータを表す必要がある場合に幅広く対応できます。

4.2 ベーシック・アセット・モデル

WebCenter Sitesからベーシック・アセット・モデルが配信されます。一般的には、ベーシック・アセット・タイプのデータ・モデルでは、アセット・タイプごとにデータベース表が1つずつ用意されます。同じタイプのベーシック・アセットには完全に同一のフィールド(プロパティ)があり、単一タイプのアセットはすべて、同じデータベース表に格納されます。WebCenter Sitesのコアなアセット・タイプのほとんどで、ベーシック・データ・モデルが使用されます。

ベーシック・アセット・タイプを作成するには、AssetMakerユーティリティを使用します。PROPERTYというカスタム・タグを使用してアセット記述子ファイルと呼ばれるXMLファイルをコーディングし、AssetMakerを使用してファイルをアップロードします。プロパティは列にもフィールドにもなります。PROPERTY文では、該当するタイプのアセットを格納する表に列を定義し、WebCenter Sitesのフォームでその列に対応するフィールドへのデータ入力方法を定義します。

アセット記述子ファイルのコーディングとベーシック・アセット・タイプの新規作成の詳細は、「ベーシック・アセット・タイプの設計」を参照してください。

次の内容について理解してください。

- ベーシック・アセット間の関係

- カテゴリ、ソースおよびサブタイプ

- ベーシック・アセット・タイプとデータベース

4.2.1 ベーシック・アセット間の関係

ベーシック・アセット・タイプは、非常に単純な親子関係を備えています。この関係を使用して、アセットの相互関連付けやリンクを実行します。オンライン・サイト用にオンライン・ページを設計する際に、アセットの子または親アセットを識別し、抽出して、適切な方法で表示するテンプレート・エレメントをコーディングします。

ベーシック・アセットで相互に割当て可能な関係をアソシエーションおよび名前なし関係といいます。個々のアセット間でこのような関係が発生する場合、その関係はAssetRelationTree表に書き込まれます。

4.2.1.1 アソシエーション

アソシエーションは定義済のアセット・タイプ固有の関係であり、WebCenter Sitesのアセット・フォームにフィールドとして表されます。AssetMakerを使用してアセット・タイプを作成した後、そのアセット・タイプの「アソシエーション」フォームを使用してアソシエーション・フィールドを作成します。

アソシエーションを使用して、システム内でアセット・タイプにとって意味のある関係を設定し、その関係の名前を使用して関連アセットを識別し、それをサイト・ページに適切な方法で表示します。たとえば、イメージ・ファイル・アセット・タイプとのアソシエーションとして、Main Imagefile、Teaser ImageFile、Spot ImageFileなどの3つのアソシエーションがアセットの名前付き記事に割り当てられているサイトでは、これらのアソシエーションを通して記事にリンクされるイメージ・ファイルを表示するように、記事テンプレートがコーディングされます。アソシエーションによって、テンプレートは個々の記事アセットの表示に適切なイメージ・ファイルを決定できます。コンテンツ・プロバイダが「新規」記事フォームおよび「編集」記事フォームのイメージ・ファイル・フィールドでイメージ・アセットを選択すると、選択されたイメージ・ファイル・アセットが記事アセットの子になります。(この同じイメージ・ファイル・アセットが、他の記事の子になる場合もあることに注意してください。)

アセット・タイプ間のアソシエーションを新規作成すると、WebCenter Sitesではそのタイプのアソシエーションに対する行がAssociation表に作成されます。さらに、アセットを作成して別のアセットの名前をアソシエーション・フィールドに指定すると、その関係がAssetRelationTree表に書き込まれます。

4.2.1.2 名前なし関係

名前なし関係はコレクション作成時に発生し、コレクション内のアイテムはコレクションの子となります。

4.2.2 カテゴリ、ソースおよびサブタイプ

ベーシック・アセットを編成または分類する方法として、このほかにカテゴリ、ソース、サブタイプの3つがあります。カテゴリとサブタイプはアセット・タイプに固有のものです。ただしソースは、コンテンツ管理サイトのすべてのアセット・タイプに当てはまります。したがって、ソースはサイト固有になります。

4.2.2.1 カテゴリ

categoryは、サイトに適用される規則に従ってアセットを分類する際に使用できるデフォルトの列およびフィールドです。すべてのベーシック・アセット・タイプには、category列がデフォルトで設定されていますが、これを使用する必要はありません(これは必須フィールドではありません)。たとえば、バンキング・サイトには、Personal Finance、Banking and Loans、Rates and Bonds、Newsなどのカテゴリがあります。これらのカテゴリによって識別された記事は、選択基準としてカテゴリを使用する問合せによって選択され、特定のサイト・ページに適宜表示されます。

ベーシック・アセット・タイプを新規作成すると、そのタイプのアセットに対するカテゴリ・コードがAssetMakerによって作成されます。さらに、この機能を使用するには、新規アセット・タイプに対して「カテゴリ」フォームを使用し、カテゴリを追加作成します。

新規カテゴリはCategory表に書き込まれます。この表は、ベーシック・アセット・モデルを使用するアセット・タイプに対する「新規」アセット・フォームおよび「編集」アセット・フォームの「カテゴリ」フィールドに対する参照表として機能します。

「カテゴリ」フィールドおよび列は、サイト・デザインを目的としています。オンライン・サイトの問合せおよび問合せアセットにカテゴリを使用できますが、使用しなくても差し支えありません。WebCenter Sitesアプリケーションの機能はいずれも、カテゴリ・コードに基づいてはいません。(例外として、このフィールドを使用している場合は、それに基づいてアセットを検索できます。)

注意:

SQL Serverでは、属性カテゴリで大文字と小文字を区別できません。たとえば、SQL Serverを使用している場合は、MyCategoryという名前のカテゴリとmycategoryという名前のカテゴリを同時に使用することはできません。

4.2.2.2 ソース

sourceは、アセットが最初に作成された場所の特定に使用できる列およびフィールドです。WebCenter Sitesは、オンライン・サイトの設計でこの機能が使用できるように(「ソース」フォームを通して)管理サポートを提供していますが、デフォルトでは、source列は、Article以外のベーシック・アセット・タイプのプライマリ記憶域表には存在しません。ベーシック・アセット・タイプでソースを使用するには、ソースのアセット記述子ファイルにプロパティ文を含める必要があります。

たとえば、バンキング・サイトには、WireFeed、Asia Pulse、UPIなどのソースがあります。一部のオンライン・ページでは、ソース列の値に基づいて記事を検索する問合せの結果に基づいて表示するようにストーリーが選択されます。

ベーシック・アセット・タイプを新規作成した後で、必要に応じて、「一般的な管理」ツリーの「管理」ノードの「ソース」フォームで新規ソースを追加します。新規ソースはSource表に書き込まれます。この表は、ベーシック・スタイル・アセットに対する「新規」アセット・フォームおよび「編集」アセット・フォームの「ソース」フィールドに対する参照表として機能します。

4.2.2.3 サブタイプ

サブタイプという概念から、アセット・タイプをさらに分類する方法が生まれました。フレックス・アセット・データ・モデルでは、定義アセット・タイプによってフレックス・アセットおよびフレックス親アセットのサブタイプが作成されます。ベーシック・アセット・データ・モデルでは、サブタイプの概念は、アセット・タイプに対するプライマリ記憶域表のsubtype列を通して実現されます。

WebCenter Sitesアプリケーションでは、アセットの「サブタイプ」の値を様々な方法で使用します。

- テンプレート・アセットの場合、サブタイプは、テンプレートが書式設定するアセットのタイプを意味します。記事を書式設定するテンプレートは、イメージを書式設定するテンプレートとはサブタイプが異なるテンプレートです。記事アセットを作成する場合は、記事を書式設定するテンプレートのみが、そのアセットの「新規」フォームまたは「編集」フォームの「テンプレート」フィールドにオプションとして表示されます。
また、Oracle WebCenter Sites: Contributorインタフェースを使用して、所定のテンプレートを使用して表示されるサブタイプを指定することもできます。たとえば、Webサイトでスポーツおよびニュースという2つのサブタイプの記事アセットを使用する場合、スポーツ・サブタイプの記事のみを表示するテンプレートを作成できます。

- 問合せアセットの場合、サブタイプは、問合せが返すアセットのタイプを意味します。記事を返す問合せアセットは、イメージ・ファイルを返すものとは異なるサブタイプの問合せアセットです。

- コレクション・アセットの場合、サブタイプは、コレクションが保持するアセットのタイプを意味します。記事を保持するコレクションは、イメージ・ファイルを保持するものとは異なるサブタイプのコレクション・アセットです。

- 設計したベーシック・アセット・タイプの場合、サブタイプはレンダリングされた方法に基づいてアセットを分類するように機能します。パブリッシュ先それぞれで、アセット・タイプの各サブタイプにデフォルトのテンプレートを定義できます。

アセットのパブリッシュ先に基づいて、特定のタイプのアセットに別のテンプレートを割り当てる必要がある場合にのみ、サブタイプを作成する必要があります。

任意のサブタイプを作成するアセット・タイプの「新規」フォームおよび「編集」フォームに「サブタイプ」というフィールドが表示されます。このフィールドのドロップダウン・リストに、そのアセット・タイプに用意されているサブタイプがすべて表示されます。

注意:

フレックス・アセット・モデルでは、定義アセット・タイプがサブタイプとして機能します。たとえば、avisportsサンプル・サイトのフレックス・ファミリには、Articleという名前の定義があります。つまり、記事アセットの1つのサブタイプとして、Articleサブタイプがあります。

アセット・タイプの中には、サブタイプが暗黙的に設定されていて変更できないものもあります。また、ユーザーがContributorインタフェースを使用してアセットのサブタイプを選択できるアセット・タイプもあります。表4-1に、WebCenter Sitesのアセット・タイプを、構成可能なサブタイプがあるかどうかに応じて一覧表示します。

表4-1 暗黙的なサブタイプと構成可能なサブタイプ

暗黙的なサブタイプ

構成可能なサブタイプ

- すべてのフレックス・アセット

- 問合せアセット

- コレクション・アセット

- テンプレート・アセット

- ページ・アセット

- すべてのカスタム・ベーシック・アセット(AssetMakerで作成)

- 記事アセット

- イメージ・アセット

- リンクセット・アセット

- 推奨アセット

- リンク・アセット

構成可能なサブタイプの設定の詳細は、「ベーシック・アセット・タイプの設計」を参照してください。

4.2.3 ベーシック・アセット・タイプとデータベース

ベーシック・アセット・タイプにはプライマリ記憶域表が1つありますが、WebCenter Sitesでは、ベーシック・アセットの基本情報は他の表に保持されています。ベーシック・タイプのアセットを新規作成すると、WebCenter Sitesでは次のデータベース表に書き込まれます。

- そのタイプのアセットを保持するプライマリ・データベース表。たとえば、各ページ・アセットではPage表に1行が表示され、各記事アセットではArticle表に1行が表示されます。
これらの表には、アセットの名前、そのオブジェクトID、作成者、使用するテンプレートなど、アセットの属性またはフィールド値がすべて格納されます。この表の名前は、アセット・タイプの名前と常に一致します。

ベーシック・アセット・タイプを新規作成すると、このプロセスの一環として、アセット・タイプに対するプライマリ記憶域表(WebCenter Sitesのオブジェクト表の1つ)がAssetMakerユーティリティによって作成されます。

- アセットに他のアセットとのアソシエーションが設定されている場合は、AssetRelationTree表。ベーシック・アセットに設定可能な関係は、「ベーシック・アセット間の関係」で説明しています。

- アセットへのアクセスを許可するコンテンツ管理サイト(パブリケーション)を指定するAssetPublication表。サイト(パブリケーション)間でアセットが共有される場合は、pubidごとに行エントリがあります。pubidは、サイト(パブリケーション)を識別する一意の値です。

- アセットがページ・アセットの場合は、SitePlanTree表。この表には、サイト・ナビゲーションにおけるページ・アセットの階層位置に関する情報が格納されます。

コンテンツを表すアセットを表示するテンプレートを開発する場合、先行リストの表から情報を抽出して表示するエレメントを、XMLタグまたはJSPタグを使用してコーディングします。

各種サンプル・アセット・タイプに対して「新規」フォームおよび「編集」フォームを調べ、Explorerツールを使用してWebCenter Sitesデータベース内の表を調べてください。

注意:

これらの表のいずれでも、データの変更にはExplorerツールを使用しないでください。アセットとそれに関連する表の編集すべてには、WebCenter Sitesインタフェースのみを使用してください。

4.2.3.1 テンプレート・アセット・タイプとデータベース

テンプレート・アセット・タイプはコアのアセット・タイプですが、ベーシック・アセット・モデルを使用しません。これは、次のデータベース表にエントリを持つコンプレックス・アセット・タイプです。

- Template表(プライマリ記憶域表)

- SiteCatalog表

- ElementCatalog表

テンプレート・アセットを新規作成すると、WebCenter Sitesでは、SiteCatalog表とElementCatalog表の両方で、そのアセットに対するエントリが自動的に作成されます。

4.2.3.2 ベーシック・アセット・タイプのデータベース表のデフォルトの列

WebCenter Sitesは、基本機能用にデフォルトの列を複数必要とします。したがって、該当するアセット・タイプに対してアセット記述子ファイルに定義された列のほかに、表4-2に示すように、列がAssetMakerによってアセット・タイプのプライマリ記憶域表にそれぞれ作成されます。

表4-2の列に対してプロパティ文を含めるようにアセット記述子ファイルをコーディングする必要はありません。

表4-2 アセット・タイプのプライマリ記憶域表の列

デフォルトの列(フィールド)名

説明

WebCenter Sitesインタフェースでの表示場所

id

アセット作成時にWebCenter Sitesによって自動生成される、各アセットの一意のID。

このフィールドの値は変更できません。

フォーム:

- 調査

- 編集

- ステータス

- 検索フォーム

name

アセットの一意の名前。名前は64個の英数字に制限されています。

フォーム:

- 新規

- 編集

- 調査

- ステータス

検索結果リストにもあります。

description

名前のみよりも多くの情報を提供するアセットの短い説明。

フォーム:

- 新規

- 編集

- 調査

- ステータス

検索結果リストにもあります。

status

アセットのステータスで、StatusCode表から取得した次のステータス・コードのいずれか。

PL: 作成済

ED: 編集済

RF: 受信済(たとえばXMLPostから)

UP: Xcelerate 2.xからアップグレード済

VO: 削除済(void)

このフィールドの値はWebCenter Sitesで制御されます。このフィールドは手動では編集できません。

フォーム: ステータス(アセットのステータスがPL(作成済)とED(編集済)のいずれかの場合)

ステータスがVO (削除済)であるアセットが、WebCenter SitesのWindowsインタフェースのどこにも表示されないことに注意してください。

createdby

アセットを元々作成したユーザーのID。このユーザー名はSystemUsers表から取得されます。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

フォーム: ステータス

また、このタイプのアセットにリビジョン追跡が有効になっている場合は、「リビジョン履歴」リスト。

createddate

アセットが初めてデータベースに書き込まれた日時。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

フォーム: ステータス

また、このタイプのアセットにリビジョン追跡が有効になっている場合は、「リビジョン履歴」リスト。

updatedby

いずれかの方法でアセットを最後に変更したユーザーのID。このユーザー名はSystemUsers表から取得されます。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

フォーム: ステータス

また、このタイプのアセットにリビジョン追跡が有効になっている場合は、「リビジョン履歴」リスト。

updateddate

ステータス・フィールドの情報が現在の状態に変更された日付。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

フォーム: ステータス

また、このタイプのアセットにリビジョン追跡が有効になっている場合は、「リビジョン履歴」リスト。

startdate

プロモーション・アセット(Engageアセット)には、ライブ・システムで訪問者のページに表示可能な期間が設定されています。この列には、プロモーションの期間の開始時刻が格納されます。

プロモーション・アセット・タイプのみが、この列を使用するデフォルトのアセット・タイプです。

アセット・タイプにstartdateフィールドとenddateフィールドを使用する場合は、「ベーシック・アセット・タイプの作成」の例5-7を参照してください。

フォーム:

- プロモーション・アセットに対する「期間」、「編集」および「調査」。

- 他のアセット・タイプに対して有効化する場合は、「新規」、「編集」、「調査」および「ステータス」。

enddate

プロモーション・アセット(Engageアセット)の場合、この列には、プロモーションの期間の終了時刻が格納されます。

プロモーション・アセット・タイプのみが、この列を使用するデフォルトのアセット・タイプです。

フォーム:

- プロモーション・アセットに対する「期間」、「編集」および「調査」。

- 他のアセット・タイプに対して有効化する場合は、「新規」、「編集」、「調査」および「ステータス」。

subtype

アセットのサブタイプの値。サブタイプは、アセットごとに異なる方法で設定されます。詳細は、「サブタイプ」を参照してください。

フォーム:

- テンプレート・アセット(「アセット・タイプ」フィールド)の場合は、「新規」および「編集」。

- 問合せアセット(「問合せの結果」フィールド)の場合は、「新規」および「編集」。

- サブタイプが構成されているアセット・タイプの場合は、「新規」および「編集」

- デフォルトのテンプレートの設定。

filename

ディスクへのエクスポートのパブリッシュ方法の使用中に、このアセットに作成されたファイルに使用する名前。

ページ・アセット・タイプおよび記事アセット・タイプのみが、デフォルトでこのフィールドが有効になっているアセット・タイプです。

アセット・タイプにfilenameフィールドを使用する場合は、「ベーシック・アセット・タイプの作成」の例5-7を参照してください。

フォーム:

- ページ・アセットおよび記事アセットの場合は、デフォルトで「新規」および「編集」

- このフィールドが有効になっている他のアセット・タイプの場合は、「新規」および「編集」

path

ディスクへのエクスポートのパブリッシュ方法でアセットをファイルにレンダリングする際、そのアセットの子アセットから生成されるエクスポート済ページ・ファイルに使用するディレクトリ・パス。

ページ・アセット・タイプおよび記事アセット・タイプのみが、デフォルトでこのフィールドが有効になっているアセット・タイプです。

アセット・タイプにfilenameフィールドを使用する場合は、「ベーシック・アセット・タイプの作成」の例5-7を参照してください。

フォーム:

- ページ・アセットおよび記事アセットの場合は、デフォルトで「新規」および「編集」

- このフィールドが有効になっている他のアセット・タイプの場合は、「新規」および「編集」

template

アセットのテンプレート。

これは、ディスクへのエクスポートを使用してパブリッシュされるか、ライブのダイナミック配信システムでレンダリングする際に、アセットのレンダリングに使用されるテンプレートです。

このテンプレートは、アセットがディスクへのエクスポートのパブリッシュ方法で承認されている場合の依存性の計算にも使用されます。ただし、アセット・タイプにサブタイプが設定されていて、そのサブタイプに基づいてデフォルトの承認テンプレートがアセットに割り当てられている場合を除きます。

フォーム:

- 新規

- 編集

- 調査

- ステータス

category

アセットに割り当てられたカテゴリがある場合は、そのカテゴリのカテゴリ・コード。

categoryフィールドを使用してアセットを編成する場合は、「一般的な管理」ツリーの「管理」ノードの「アセット・タイプ」フォームでカテゴリ・コードを追加します。

フォーム:

- 新規

- 編集

- 調査

- ステータス

urlexternaldoc

非推奨

アセットが、WebCenter Sitesインタフェースでなくサイト・デスクトップ・インタフェースで入力された場合、そのアセットのソースである外部ドキュメントを格納します。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

該当なし

externaldoctype

非推奨

urlexternaldocフィールドに保持されているファイルのMIMEタイプ。

このフィールドの値はWebCenter Sitesで制御されます。手動では編集できません。

該当なし

urlexternaldocxml

将来の使用のために予約されています。

該当なし

4.3 フレックス・アセット・モデル

フレックス・アセット・モデルの主な特徴は次のとおりです。

- フレックス・アセットは、フレックス定義によって定義されます。フレックス定義は、個々のフレックス・アセットをどのフレックス属性で構成するかを決定するアセット・タイプです。フレックス定義により、フレックス・アセット・タイプのサブタイプが作成されます。

- 定義アセット・タイプによってフレックス・アセットおよびフレックス親アセットのサブタイプが作成されるため、フレックス・アセット・タイプまたはフレックス親アセット・タイプの個々のインスタンスのバリエーションを広げることができます。

- フレックス属性はアセットです。フレックス・データ・モデルによって、フレックス属性を既存のフレックス・アセット・タイプに随時追加(または削除)できます。

- フレックス・フィルタは1つのフレックス属性からデータを取り込み、それを変換または評価し、フレックス・アセットの保存時に別のフレックス属性に結果を格納できます。フレックス・フィルタのアクションによって得られた値を、導出された属性値といいます。フレックス・フィルタの詳細は、「フレックス・フィルタの作成」を参照してください。

- フレックス・アセットは属性値を(導出値でさえも)フレックス親から継承できるため、データを階層で表すことが可能になります。

ベーシック・アセット・タイプの場合とは異なり、個々のフレックス・アセット・タイプは作成せず、かわりにアセット・タイプのフレックス・ファミリを作成します。

次の内容について理解してください。

- フレックス・ファミリ

- avisportsサンプル・サイトのフレックス・ファミリ

- フレックス属性

- フレックス親とフレックス親定義

- フレックス・アセットとフレックス定義アセット

- フレックス・ファミリとデータベース

4.3.1 フレックス・ファミリ

フレックス・アセット・データ・モデルは、アセット・タイプのファミリの観点から考えることができます。フレックス・ファミリには6つのアセット・タイプがあります。表4-3に示すように、5つは必須であり、6つ目はオプションです。

表4-3 フレックス・ファミリのメンバー

フレックス・ファミリのメンバー

ファミリ当たりの数

フレックス属性アセット・タイプ

1つ

フレックス親定義アセット・タイプ

1つ以上

フレックス定義アセット・タイプ

1つ以上

フレックス親アセット・タイプ

1つ以上

フレックス・アセット・タイプ

1つ以上

フレックス・フィルタ・アセット・タイプ

ゼロまたはそれ以上

アセット・タイプの中には、開発者がデータ・モデルに他のアセット・タイプを作成するために排他的に使用されるものがありますが、フレックス・アセット・タイプは常に、コンテンツ・プロバイダが当該タイプのアセットを作成するために使用します。(必要に応じて、認証ユーザーに、追加のフレックス・ファミリ・メンバーへのアクセス権を与えることができます。)

フレックス・ファミリを作成するには、Adminインタフェースの「フレックス・ファミリ・メーカー」ノードの「新規ファミリの追加」(「一般的な管理」ツリーの「管理」ノードの「フレックス・ファミリ・メーカー」にあります)をダブルクリックして、「新規フレックス・ファミリの追加」フォームにアクセスします。このフォームで、ファミリ内の各アセット・タイプに名前を付けます。たとえば、製品ファミリという名前のフレックス・ファミリがあるとします。フレックス・アセットは製品アセット、フレックス属性は製品属性というように呼ばれます。

フレックス・ファミリのキー・メンバーはフレックス・アセットです。フレックス・アセットは、データベースから抽出してオンライン・サイト(配信システム)の訪問者に表示するデータの単位です。ファミリ内の他のメンバーのすべては、なんらかの点でフレックス・アセット・メンバーの一部となります。

フレックス・アセットがキーであるのに対し、属性はフレックス・アセット・モデルの基盤です。属性は情報の個々のコンポーネントです。たとえば、色、高さ、作成者、ヘッドラインなどがあります。属性は、フレックス・アセットおよびフレックス親の定義に使用します。フレックス・アセットは親から属性値を継承し、親はその親から属性値を継承する、となります。

どの属性がどのフレックス・アセットおよびフレックス親を記述するかを決定するには、フレックス定義およびフレックス親定義のアセット・タイプを使用してテンプレートを作成します。フレックス親とその定義によって、属性値の継承が実装されます。

フレックス親もフレックス・アセットも、2つのタイプの属性で定義することはできません。サイトには、2つ以上の種類の属性があります。たとえば、製品属性とコンテンツ属性です。製品アセット(製品フレックス・ファミリのフレックス・アセット・メンバー)は製品属性のみで定義できます。その定義にコンテンツ属性を含めることはできません。

フレックス・フィルタによって、属性値に対してなんらかのアクションを実行し、フレックス・アセットの保存時にアクションの結果を保存するように構成できます。たとえば、WordファイルのテキストをHTMLコードに変換するフィルタを構成できます。

要するに、フレックス・ファミリのフレックス・アセット・メンバーはファミリの理由であり、表示するコンテンツの単位です。フレックス・ファミリのその他のメンバーはフレックス・アセットのデータ構造を提供します。ただし、ファミリのメンバーはすべてアセットであるため、リビジョン追跡、ワークフロー、検索など、WebCenter Sitesの標準機能が利用できます。

4.3.1.1 親アセット、子アセットおよびフレックス・アセット

フレックス・アセット・データ・モデルを使用している場合、親子関係という語句は、フレックス・アセットとそのフレックス親アセットの関係を指します。この親子関係は、ベーシック・アセットがアセット・アソシエーションを通して得る親子関係とは異なります。

フレックス・アセットがベーシック・アセットと同種の親子関係を持つことは可能ですが、次の理由により、現実に行われるとは考えられません。

- WebCenter Sitesにはタグ・ファミリASSETSETおよびSEARCHSTATEがあり、表示するフレックス・アセットを選択する場合は、コレクション・アセット・タイプおよび問合せアセット・タイプのかわりに使用します。このタグ・ファミリの詳細は、「assetsetおよびsearchstate」を参照してください。

- フレックス・アセットはアソシエーションを必要としません。たとえば、製品などのフレックス・アセットにイメージ・ファイルを割り当てるには、イメージ・ファイルを特定する属性を作成して、それをフレックス・アセットの定義に割り当てることができます。

4.3.2 avisportsサンプル・サイトのフレックス・ファミリ

avisportsサンプル・サイトでは、調査可能なフレックス・ファミリが1つあります。サンプル・フレックス・アセット・タイプの次の説明を理解しやすくするためにこの項をお読みになる際には、Contributorインタフェースの記事アセットおよびイメージ・アセットをいくつか調査してください。

avisportsフレックス・ファミリ

avisportsサンプル・サイトのフレックス・ファミリでは、avisportsサンプル・サイトに示す記事およびイメージのデータ構造が提供されます。スポーツ記事のオンラインWebサイトが作成されます。

次に、avisportsフレックス・ファミリのアセット・タイプを示します。

- ContentAttribute: avisportsサンプル・サイトの記事、イメージおよび親の属性の定義に使用するフレックス属性アセット・タイプです。たとえば、ヘッドライン、サブヘッドライン、著者、関連イメージなどの名前の属性があります。

- ContentParentDef: avisportsサンプル・サイトのフレックス・ファミリのフレックス親定義アセット・タイプです。これは、親のサブタイプの作成に使用します。1つあります: カテゴリ。

- ContentDef: avisportsサンプル・サイトのフレックス・ファミリのフレックス定義アセット・タイプです。Article、ArticleImage、Imageの各定義のサブタイプの作成に使用されます。このサイトのすべてのAVIArticleアセットは、Article定義で定義されます。このサイトのAVIImageアセットは、ImageまたはArticleImageのいずれかの定義によって定義されます。

- ImageCategory: ランニング・イメージ、スキー・イメージ、野球イメージなどのイメージのカテゴリを表すフレックス親です。

- ArticleCategory: ランニング記事、野球記事、スキー記事どの記事のカテゴリを表すフレックス親です。

- AVIImage: アップロードされたイメージ・ファイルを格納するフレックス・アセット・タイプです。イメージ・アセットは、avisports Webサイトに示されるイメージを表します。

- AVIArticle: 記事のテキストと関連情報を格納するフレックス・アセット・タイプです。ヘッドライン、署名行、サブヘッドライン、本文などの属性があります。

avisportsサンプル・サイトのフレックス・ファミリには、3つのコンテンツ定義があり、コンテンツ・アセット・タイプは2つのみであることに注意してください。記事定義は、AVIArticleアセット・タイプによって使用されます。ImageおよびArticleImage定義は、どちらもAVIImageアセット・タイプによって使用されます。

4.3.3 フレックス属性

フレックス属性はフレックス・アセット・モデルの基盤です。属性は、情報の1単位を表します。属性アセットは、フレックス・アセットおよびフレックス親の定義に使用します。これらは、フレックス・アセットおよびその親に対して、「新規」フォームおよび「編集」フォームでフィールドとして表示されます。

属性は、ベーシック・アセットのプロパティに似ています。プロパティと同様に、属性はWebCenter Sitesデータベース表の列に格納できるデータの種類を定義し、フォーム内のフィールドを記述します。ただし、プロパティがアセット・タイプのデータベース表に列を定義するのに対し、属性は専用のデータベース表を持つアセットです。

このデータ構造(列としてではなく、アセットとしての属性)は、フレックス・アセットの柔軟性が高い理由の1つです。

繰り返しますが、フレックス親もフレックス・アセットも、2つのタイプの属性で定義することはできません。たとえば、製品フレックス・ファミリとコンテンツ・フレックス・ファミリが含まれるサイトでは、製品アセット・タイプは製品属性のみで定義できます。その定義にコンテンツ属性を含めることはできません。

注意:

削除したフレックス属性によって格納されたデータは、データベースから削除されません(このデータは問合せによって引き続き返されます)。

4.3.3.1 属性のデータ型

属性のデータ型は、wcs_properties.jsonファイルに配置されているWebCenter Sitesデータベースのプロパティによって定義されます(「コア」に分類)。

表4-4に、フレックス属性のデータ型、データ型を定義するプロパティ、およびプロパティが配置されているファイルを一覧表示します。

表4-4 フレックス属性のデータ型

型

プロパティ

date

cc.datetime

float

cc.double

integer

cc.integer

money

cc.money

string

cc.varchar

text

cc.bigtext

asset

cc.bigint

blob

cc.bigint

4.3.3.2 属性のデフォルトの入力スタイル

フレックス属性は、「新規」フォームまたは「編集」フォームにフィールドとして表示されるときに、そのデータ型に基づいたデフォルトの入力スタイルが設定されます。次のリストに、フレックス属性のデフォルトの入力スタイルを示します。

- Date: 図4-2のように表示される入力ボックス。

図4-2 Date属性

- Float: 小数部の桁を強制表示したテキスト・フィールド。

- Integer: テキスト・フィールド。

- Money: 通貨フォーマットを強制表示したテキスト・フィールド。

- String: 最大255文字を受け入れるテキスト・フィールド。

- Text: テキスト・ボックス。受け入れられる文字数は、使用しているデータベースおよびデータベース・ドライバによって異なります。

- Asset: 指定されたタイプの全アセットを示したドロップダウン・リスト。

- Blob: 「参照」ボタンが設定されたテキスト・フィールド。

デフォルトの入力スタイルを使用するかわりに、属性エディタを作成して、それを属性に割り当てることができます。属性エディタはアセットですが、属性フィールドへのデータ入力方法を指定するという点で、ベーシック・アセットに対するアセット記述子ファイル内のINPUTFORM文にも似ています。属性エディタの詳細は、「属性エディタの設計」を参照してください。

4.3.3.3 外部属性

外部表に格納されるフレックス属性、つまり外部属性を設定できます。外部属性は、次の制約を受けます。

- 外部表をWebCenter Sitesで登録する必要があります。つまり、外部表はSystemInfo表でWebCenter Sitesに対して識別される必要があります。

- 外部表には、各行を一意に識別する識別子が保持される列を設定する必要があります。識別子は20文字未満とします。

- 外部表には、任意の適切なデータ型が使用可能な属性データ値用に予約された列を設定する必要があります。たとえば、属性の型がstringの場合は、文字列に適切なデータ型を使用する必要があります。

4.3.4 フレックス親とフレックス親定義

フレックス親とそのフレックス親定義は編成構造であり、次の2つのアクションを実行します。

- 属性値の継承を実装します。親定義は継承ルールを設定(記述)し、親はこれらの継承ルールに従って属性値をフレックス・アセットに渡します。

- WebCenter Sitesインタフェースでアセットを表示するタブにおけるフレックス・アセットの位置を決定します。タブ上にツリー形式で表示される親とフレックス・アセットの階層は、親定義を使って設定された階層に基づきます。

それぞれの親アセット・タイプには、親定義で指定されたように、専用の属性セットがあります。親定義によって、WebCenter Sitesインタフェースに表示されるフォームが作成されます。

親を使用してフレックス・アセットを編成または管理するには、親の子アセットごとに変更する必要のない標準の属性値を渡します。

親アセット・タイプは、WebCenter Sitesインタフェース内で、開発者やコンテンツ・プロバイダがデータを表示する方法と、データと対話する方法に影響します。

たとえば、CategoryおよびSubCategoryという2つの親定義がある、ProductSiteという名前のサイトがあるとします。これらは、(Contributorインタフェース内の)「コンテンツ・ツリー」で構造体を作成することのみを目的としています。

製品親の定義がCategoryの場合、製品親は「コンテンツ・ツリー」の最上位レベルに表示されます。製品親の定義がSubCategoryの場合、図4-3に示すように、製品親は第2レベルに表示され、専用の親が指定されます。

図4-3 「コンテンツ・ツリー」の「製品」ノード

図4-3では、Compact Fluorescent、Halogenなど、最上位レベルの製品親が複数あります。これらはカテゴリ定義を使用して作成されています。Double BIAX and 2-Pin、Double BIAX and 4-pinなどの次レベルの製品親は、サブカテゴリ定義を使用して作成されています。

4.3.4.1 ビジネス・ルールと分類

親定義および親アセットの目的は、データの分類を表現することのみではありません。エンド・ユーザーによる入力エラーのリスクなしで、ビジネス・ルール(ロジック)を適用できるようにもします。特定の定義のフレックス・アセットを作成した場合は、継承する必要のある依存性が存在する場合、そのフレックス・アセットには親を設定する必要があります。

たとえば、次の5つの属性を持つトースタという単純な製品があるとします。

- SKU = 1234

- 説明 = トースタ

- 価格 = 20

- CAT1 = キッチン

- CAT2 = 電化製品

CAT2の値が電化製品の場合、CAT1の値にはキッチンのみを指定できます。つまり、CAT1の値とCAT2の値の間にはビジネス・ルールの依存性が存在します。

このような場合、コンテンツ・プロバイダは両方のフィールドを入力する必要はありません。データを手動入力しなければならないフィールドはすべて、入力エラーによって不正なデータが保持される可能性があるため、継承を使用してビジネス・ルールを適用することをお薦めします。

- CAT1とCAT2を親定義にします。

- キッチンをCAT1の定義で作成された親にして、電化製品をCAT2の定義で作成された親にします。

- キッチンを電化製品のフレックス親にします。

コンテンツ・プロバイダが製品を作成するときに、CAT2に対して電化製品を選択した場合、CAT1の値は継承によって自動的に設定されます。

4.3.5 フレックス・アセットとフレックス定義アセット

フレックス・アセットは、フレックス・ファミリの理由です。これは、製品、表示されるコンテンツの一部など、最終目標を表すアセット・タイプです。たとえば、avisportsサンプル・サイトには次の2つのフレックス・アセット・タイプがあります。

- Article (フレックス): テキストを保持するアセット。

- Image (フレックス): アップロードしたイメージ・ファイル保持するアセット。

ファミリ内の他のメンバーのすべては、なんらかの点でフレックス・アセット・メンバーの一部となります。

フレックス定義アセットは、靴、トースタ、ボーリングのボール、パンフレット、ニュースレター、記事など、フレックス・ファミリ内で1種類のフレックス・アセットを記述します。フレックス定義アセットは、Contributorインタフェースで表示されるフォームに直接影響するテンプレートです。

avisportsサンプル・サイトでは、記事の定義が1つ(Article)、イメージの定義が2つ(ImageおよびArticleImage)あります。フレックス定義は必要に応じていくつでも作成できます。たとえば、スポーツと天気の記事を提供するニュース・サイトでは、スポーツ用に設定されたフレックス定義と、天気用に設定された別のフレックス定義アセットが必要になります。

個々のフレックス・アセットは、1つのフレックス定義アセットのみに従って作成します。Image定義とArticleImage定義の両方を使用したイメージは作成できませんが、Image定義を使用するイメージを作成してから、ArticleImage定義を使用する別のイメージを作成することはできます。

フレックス・アセットには、作成時に直接割り当てられた属性のみでなく、親から継承する属性も割り当てられます。これには複数のフレックス親を割り当てることができ、親に親があるかどうかは設計した階層構造によって異なります。図4-4に、3つのレベルの階層のサイトの例を示します。

図4-4 階層のレベル

Other Compact Fluorescent製品親には専用の親(Compact Fluorescent)と複数の子(10576、10578など)が割り当てられています。

4.3.6 フレックス・ファミリとデータベース

フレックス・ファミリ内のアセット・タイプには、それぞれ複数のデータベース表があります。たとえば、フレックス・アセット・メンバーには6つの表、フレックス親タイプには5つの表があります。このデータ・モデルでは、フレックス・ファミリ内のフレックス・メンバーは、ベーシック・アセット・モデルの場合よりも多くのフィールドをサポートできます。

フレックス・モデルで最も重要な4つの表のタイプは次のとおりです。

- アセット・タイプのプライマリ表

- _Mungo表: フレックス・アセットおよびフレックス親アセットのみの属性値を保持します。

- MungoBlobs表: blob型のすべてのフレックス属性の値を保持します。

- _AMap表: フレックス・アセットおよびフレックス親のみの属性値の継承に関する情報を保持します。

その他にも複数の表があり、これらの表にはフレックス・アセット間の関係に関する基礎データだけでなく、追加の構成情報(検索エンジンの詳細、外部属性の場所、パブリッシュ情報、リビジョン追跡が有効になっている場合はバージョン情報)も格納されています。

さらに、特定の種類のサイト情報は、ベーシック・アセットで使用される表と同じ表に保持されます。たとえば、AssetPublication表では、アセット・タイプが有効化されているコンテンツ管理サイトを指定します。

フレックス・アセットを表示するテンプレートを開発する場合、_Mungo表およびMungoBlobs表から情報を抽出して表示するエレメントをコーディングします。

4.3.6.1 フレックス・アセット・タイプのデータベース表のデフォルトの列

ベーシック・アセット・タイプと同様に、各フレックス・アセット・タイプには、アセット・タイプの名前を採用したプライマリ記憶域表があります。たとえば、avisportsサンプル・サイトで、articleという名前のアセット・タイプのプライマリ表はAVIArticleで、このサンプル・サイトのイメージ・アセット・タイプのプライマリ表はAVIImageになります。記事とイメージの両方の属性のプライマリ表の名前はContentAttributeです。

ベーシック・アセット・タイプのプライマリ表と異なり、フレックス・アセット・タイプのプライマリ表には、デフォルトの列のみが設定されます。これは、属性値を持つフレックス・アセット・タイプが、属性値をプライマリ表に格納しないためです。属性値は、このアセット・タイプの_Mungo表に格納されます。

一般的に、フレックス・アセット・タイプに対するプライマリ表のデフォルトの列タイプは、ベーシック・アセット・タイプに対するプライマリ記憶域表のデフォルトの列と同じです。デフォルトの列タイプの全般的なリストは、「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

ただし、表4-5に示すように、例外や追加事項は当然ながら存在します。

表4-5 フレックス・アセット・タイプのデータベース表のデフォルトの列

列

説明

category

カテゴリはフレックス・アセット・モデルでは使用されないため、フレックス・アセット・タイプのプライマリ表にはcategory列は存在しません。

フレックス・アセットに対する問合せがそのフレックス属性の値に基づいているため、フレックス・アセットはカテゴリ機能を必要としません。

template

この列では、製品、記事(フレックス)、イメージ(フレックス)などのフレックス・ファミリ内のフレックス・アセット・メンバーに対する表のみに値が保持されます。これは、ファミリ内のフレックス・アセット・メンバーのみにテンプレート・アセットを割り当てて、オンライン・サイトで表示できるためです。

renderid

フレックス・アセットに割り当てられたテンプレート・アセットのオブジェクトIDを保持します。

attributetype

フレックス属性タイプに対するプライマリ表の追加列です。属性が「新規」フォームおよび「編集」フォームに表示されるときに、その属性の入力スタイルを書式設定する属性エディタの名前を保持します(属性エディタが存在する場合)。

flextemplateid

フレックス・アセット・タイプ(フレックス・ファミリのフレックス・アセット・メンバー)に対するプライマリ表の追加列です。フレックス・アセットの作成に使用したフレックス定義のIDを保持します。

flexgrouptemplateid

フレックス親アセット・タイプに対するプライマリ表の追加列です。フレックス親アセットの作成に使用した親定義のオブジェクトIDを保持します。

4.3.6.2 _Mungo表

フレックス・アセット・タイプおよびフレックス親アセット・タイプには、AssetType_Mungo表があり、この場合、AssetTypeはフレックス・アセット・タイプの名前です(また、メイン記憶域表の名前と一致します)。その目的は、アセットの作成時にそのタイプのアセットに割り当てられた属性値を格納することです。たとえば、avisportsサンプル・サイト表のAVIArticle_Mungoには、記事アセットの属性値が保持され、AVIImage_Mungo表には、イメージ・アセットの属性値が保持されています。

各属性値には、別々の行が割り当てられます。

_Mungo表の各行には、表4-6の各列の値が表示されます。

表4-6 _Mungo表の行

列

説明

id

フレックス・アセットが保存され、行が作成されたときに、WebCenter Sitesによって自動生成される、各属性値の一意のID。

これは、表の主キーです。

ownerid

属性値が属するフレックス・アセットのID。(フレックス・アセットの表、たとえばProductのもの。)

attrid

属性のID。(属性の表、たとえばPAttributesのもの。)

assetgroupid

属性値が継承された場合は、値を渡した親のID。(親の表、たとえばProductGroupsのもの。)

_Mungo表の各行には表4-7の列もすべて含まれますが、値(データ)は属性のデータ型に応じて1つの列のみに指定されます。

表4-7 _Mungo表の列

列

説明

floatvalue

属性のデータ型がfloatの場合は、属性の値。

moneyvalue

属性のデータ型がmoneyの場合は、属性の値。

textvalue

属性のデータ型がtextvalueの場合は、属性の値。

datevalue

属性のデータ型がdateの場合は、属性の値。

intvalue

属性のデータ型がintの場合は、属性の値。

blobvalue

属性のデータ型がblobの場合は、MungoBlobs表で属性の値を保持する行のID。

urlvalue

属性のデータ型がurlの場合は、属性に対して入力されたパスまたはURL。

assetvalue

属性のデータ型がassetの場合は、アセットのID。

stringvalue

属性のデータ型がfloatの場合は、属性の値。

_Mungo表にはURL列があるため(「WebCenter SitesのURLフィールドを使用した間接的なデータ格納」を参照)、その列に対してデフォルトの記憶域ディレクトリ(defdir)を設定する必要があります。_Mungo表に対してdefdirを設定するには、wcs_properties.jsonファイルのcc.urlattrpathプロパティを使用します。

4.3.6.3 MungoBlobs表

MungoBlobs表が1つ存在します。これには、システム内のすべてのフレックス属性タイプに対して、blob型のすべてのフレックス属性の値が保持されています。各属性値には、表の別々の行が割り当てられます。

4.3.6.4 _AMap表

フレックス・アセット・タイプおよびフレックス親アセット・タイプには、AssetType _AMap表があります。その目的は、親から継承した属性にアセットをマップすることです。これにより、オンライン・サイトのページにアセットを表示するテンプレートを作成するときに、属性が継承されたか直接割り当てられたかどうかに関係なく、属性のいずれかに基づいてアセットを問い合せたり、それらの属性のいずれかを表示できます。

_AMap表では、継承された属性の値を持つフレックス・アセットごとに行が1つ割り当てられます。(ただし、属性が複数の値を持っている場合、_Mungo表では値ごとに行が1つ割り当てられます。)

_AMap表には、表4-8に示す列があります。

表4-8 _AMap表の列

列

説明

id

フレックス・アセットが保存され、行が作成されたときに、WebCenter Sitesによって自動生成される、各行の一意のID。これは、表の主キーです。

inherited

属性が継承された場合は、その継承元である親のID。(親の表、たとえばProductGroupsのもの。)

attributeid

属性のID。(属性の表、たとえばPAttributesのもの。)

ownerid

属性値が属するフレックス・アセットのID。(フレックス・アセットの表、たとえばProductのもの。)

4.4 assetsetおよびsearchstate

WebCenter Sitesには、オンライン・ページに表示する個々のフレックス・アセットを識別するために、メソッド・ファミリASSETSETおよびSEARCHSTATEがあります。

assetset

assetsetはフレックス・アセットまたはフレックス親アセットのみのグループであり、フレックス属性、フレックス定義またはフレックス親定義は含まれません。たとえば、avisportsサンプル・サイトでは、記事およびイメージを含めたassetsetを作成できます。サイト・ページのコーディング時には、assetsetを作成して、その中にアセットを表示する文をコーディングします。

searchstate

フレックス・アセットのテンプレートでSEARCHSTATEメソッド・ファミリを使用して、assetsetに含める必要のあるフレックス・アセットを特定します。searchstateは、フレックス・アセットのリストまたはセットに適用される検索絞込み条件のセットです。絞込み条件として、属性値または別のsearchstate(ネストされたsearchstate)のいずれかに基づいたフィルタ(制限)を使用できます。

searchstateは、データベース内の_Mungo表でも、検索エンジンで作成された属性索引のいずれでも検索できます。つまり、データベース検索とリッチテキスト(索引を通じたフルテキスト)検索を同じ問合せ内に混在させることができます。

これらのタグは、_Mungo表または属性索引のみでフレックス・アセット・タイプを検索するため、これらのタグを使用してフレックス・アセットを抽出することは、ASSETタグまたは問合せアセットを使用するよりもはるかに効率的です。

assetsetと属性アセット・タイプ

WebCenter Sitesでは、属性アセット・タイプ全体の検索は実行できません。assetsetは属性値に基づいて作成されるため、同じassetsetに含められるのは同じ属性アセット・タイプを共有するアセットのみです。これは、フレックス・ファミリを設計する際の重要な考慮点であり、共通の属性アセット・タイプを共有しないフレックス・アセット・タイプを作成する場合は、データが分離されます。このようなフレックス・アセット・タイプを作成することで、異なるタイプのアセットが共通assetsetに含まれないようにします。また、assetsetを表示することは、配信システム上でフレックス・アセットを表示するためのメカニズムです。

たとえば、同じフレックス・ファミリに2つのタイプのフレックス・アセットを持つことができます。これらが同じタイプの属性を使用するかぎり、両方のタイプのアセットを含むassetsetを作成できます。ただし、2つのタイプのフレックス・アセットにわたって検索すると、それぞれの_Mungo表の間に結合が生じるため、パフォーマンスが低下する可能性があることに留意してください。

avisportsサンプル・サイトには、articleおよびimageという2つのフレックス・アセット・タイプがあります。これらは、同じ属性アセット・タイプ(ContentAttribute)を共有します。これは共有の属性アセット・タイプであるため、2つの異なるフレックス・アセット・タイプの場合であっても、同じassetsetに含めることができます。

4.5 検索エンジンと2つのアセット・モデル

この2つのアセット・モデルのデータ構造は非常に異なるため、アセット・モデルが検索エンジンと対話する方法も大きく異なります。

- ベーシック・アセット・タイプはアセット記述子ファイルによって定義されます。そのプライマリ記憶域表には、すべてのプロパティが列として含まれます。ベーシック・アセット・タイプで索引付けするフィールドを指定するには、そのアセット・タイプの特定のエレメントをカスタマイズする必要があります。「ベーシック・アセット・タイプの設計」を参照してください。

- フレックス・アセットのフィールドはフレックス属性であり、これはアセットであるため、リッチテキスト検索に対してどのフィールドを索引付けするかを、属性別に決定します。また、WebCenter Sitesアプリケーションでは、属性の「新規」フォームと「編集」フォームで「検索エンジン」フィールドを使用してどの属性を索引付けするかを指定できます。この機能を有効化するためにエレメントをカスタマイズする必要はありません。

4.6 タグと2つのアセット・モデル

アセットの作成と管理の最終目標は、アセットを配信システムに移動して、配信システム上でエレメントに組み込んだコードによってアセットをデータベースから抽出し、それをサイトの訪問者に表示することです。WebCenter Sitesアプリケーションは、様々なツールセット(カスタム・タグ・セット)をXMLとJSPの両方で提供しています。

テンプレート内でデータベースからのアセット抽出に使用するツールセットは、使用しているアセットの種類によって異なります。

- ベーシック・アセット・モデルのあるアセットには、ASSETメソッド・ファミリを使用します。

- フレックス・ファミリ内のフレックス・アセット・メンバーには、ASSETSETおよびSEARCHSTATEのメソッド・ファミリを使用します。フレックス・ファミリ内のフレックス・アセット・メンバー(製品、記事、イメージなど)には、ASSET.LOADタグを使用しないでください。フレックス・アセットに対してASSET.LOADタグを使用すると、アセットのすべての表からそのアセットに関する全情報を取得するため、効率がきわめて悪くなります。SEARCHSTATEメソッドは、フレックス・アセットのアセット・タイプに対する_Mungo表とMungoBlobs表のみを問い合せます。

- 推奨アセットには、COMMERCECONTEXTメソッド・ファミリを使用します。

これらの製品ではさらに多くのメソッド・ファミリが使用できるだけでなく、WebCenter Sitesおよび複数のAPIからも多数のカスタム・タグが使用できます。

WebCenter Sitesタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

4.7 要約: ベーシック・アセット・モデルとフレックス・アセット・モデル

2つのアセット・モデルの類似点と相違点は次のとおりです。

アセット・モデルの共通点

ベーシック・アセット・モデルとフレックス・アセット・モデルの機能方法には多くの相違点がありますが、いくつかの共通点も見られます。

- ベーシックとフレックスどちらのアセット・モデルを使用する場合でも、WebCenter Sitesアプリケーションに付属しているテンプレート・アセット・タイプとページ・アセット・タイプを使用します。

- すべてのアセット・タイプにはステータス・コードが割り当てられています。つまり、フレックスかベーシックかに関係なく、すべてのアセットはステータスに基づく問合せを使用して検索できます。

- すべてのアセット・タイプは、フレックスかベーシックかに関係なく、次の構成または管理特性を共通して備えています。

- サイト別に有効化する必要があります。

- これらのタイプの個々のインスタンスを作成できるようにするには、スタート・メニュー・アイテムをあらかじめ構成しておく必要があります。

- 個々のインスタンスはXMLPostユーティリティを使用してインポートできます。

アセット・モデルの相違点

表4-9に、これらのアセット・モデルの主な相違点を要約します。

表4-9 アセット・モデルの主な相違点

機能

ベーシック・アセット・モデル

フレックス・アセット・モデル

データベース表の数

1つ。

複数。

アセット・タイプへのフィールドの追加

スキーマ変更が必要です。

スキーマ変更は必要ありません。

他のアセットへのリンク

アソシエーションと名前なし関係を使用します。

フレックス・ファミリの関係を使用します。

サブタイプ

通常は「管理」タブの「サブタイプ」アイテムを使用します。サブタイプの設定の詳細は、「サブタイプ」を参照してください。

フレックス定義とフレックス親定義を使用します。

検索エンジンの索引付け

アセット・タイプの特定のエレメントをカスタマイズする必要があります。

フレックス属性フォームで「検索エンジン」フィールドを使用します。

主なタグ・ファミリ

ASSET、SITEPLANおよびRENDER。

ASSETSET、SEARCHSTATEおよびRENDER。

パブリッシュ方法

ディスクにエクスポート。

サーバーへのミラーリング。

「サーバーにエクスポート」も使用できますが、フレックス・モデルには標準ではありません。

サーバーへのミラーリング。

5 ベーシック・アセット・タイプの設計

AssetMakerユーティリティを使用して、ベーシック・アセット・タイプを作成します。これらは通常、開発システム上で作成し、準備が整ったら開発システムから管理システムと配信システムに移行します。

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

- AssetMakerユーティリティについて

- ベーシック・アセットの作成を開始する前に

- ベーシック・アセット・タイプの作成

- ベーシック・アセット・タイプの削除

5.1 AssetMakerユーティリティについて

AssetMakerのXMLタグを使用して、アセット記述子ファイルというXMLファイルをコーディングして、ベーシック・アセット・タイプをWebCenter Sitesの外で定義します。アセット記述子ファイルでは、新しいアセット・タイプのプロパティが定義されます。プロパティという用語は、データベース表の列とWebCenter Sitesの入力フォームのフィールドの両方を意味します。

次に、ファイルをWebCenter Sitesにアップロードし、新しいアセット・タイプのデータベース表と、新しいタイプのアセットで作業(作成、編集、コピーなど)する際に使用するフォームを生成するWebCenter Sitesエレメントの2つのアイテムを、AssetMakerを使用して作成します。

この項には次のトピックが含まれます:

- AssetMakerの仕組み

- アセット記述子ファイル

- アセット・タイプのデータベース表の列

- アセット・タイプに対応したエレメントとSQL文

5.1.1 AssetMakerの仕組み

AssetMakerを使用して新しいベーシック・アセット・タイプを作成するには、次の手順に従います。

1. アセット記述子ファイルをコーディングします。

この章では、アセット記述子ファイルとそのコーディングについて説明します。AssetMakerタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

2. ファイルをアップロードします。

AssetMakerによってAssetType表に行が作成され、その行にアセット記述子ファイルがコピーされます。

3. 表を作成します。

「アセット表の作成」ボタンをクリックすると、AssetMakerによって次の操作が実行されます。

- アセット記述子ファイルを解析します。

- 該当するタイプのアセットに対応するプライマリ記憶域表を作成します。表の名前は、アセット記述子ファイルで特定されたアセット・タイプの名前と一致します。各列のデータ型もファイルに記述される文で定義されます。
アセット記述子ファイルで定義された列に加えて、WebCenter Sitesが正常に機能するために必要なデフォルトの列がAssetMakerによって作成されます。

- 新しく作成された表の行をSystemInfo表に追加します。
すべてのアセット表はオブジェクト表であるため、systable列の値はobjに設定されます。

すべてのアセット表にURL列が存在します。そのため、defdir列の値は、アセット・タイプを作成する際に、アセット記述子ファイルで指定した値、または「アセット表の作成」フォームの「DefDir」フィールドで指定した値に設定されます。

- 「「一般」カテゴリの追加」オプションを選択してある場合には、Asset MakerによってCategory表に、新しいアセット・タイプに対応する行が1つ追加され、そのカテゴリにGeneralという名前が付けられます。

4. エレメントを登録します。

AssetMakerによって次の操作が実行されます。

- OpenMarket/Xcelerate/AssetTypeディレクトリの下にあるElementCatalog表に、新しいアセット・タイプに対応するサブディレクトリを作成します。

- AssetStubCatalog表のエレメントを、ElementCatalog表の新しいサブディレクトリにコピーします。これらのエレメントは、このタイプのアセットを操作できるようにWebCenter Sitesのフォームをレンダリングし、WebCenter Sitesの機能に処理ロジックを提供します。

- 検索フォームの個々のフィールドに対する検索機能を実装したSQL文を作成します。これらの文はSystemSQL表に配置されます。

このタイプのアセットの作成、編集、調査などを行うと、AssetMakerによってAssetType表に配置されているアセット記述子ファイルが解析され、このフォームがアセット・タイプに固有になるよう、WebCenter Sitesにその値が渡されます。アセット記述子ファイル内の文により、フィールドの入力タイプが決まり、フィールドの長さの制限が指定され、フィールドを検索フォームと検索結果フォームに表示するかどうかが決まります。

アセット・タイプを作成した後に、このアセット・タイプを使用するサイトでのアセット・タイプの有効化やスタート・メニューのショートカットの作成などが必要になります。

次の図には、AssetMakerの仕組みや、ベーシック・アセット・タイプが作成される際に使用するデータベース表がまとめてあります。

図5-1 AssetMakerの仕組み

5.1.2 アセット記述子ファイル

AssetMaker XMLタグを使用して、システムに設計するアセット・タイプを定義するアセット記述子ファイルをコーディングします。

この項には次のトピックが含まれます:

- アセット記述ファイルについて

- フォーマットと構文について

- AssetMakerのタグについて

5.1.2.1 アセット記述ファイルについて

アセット記述子ファイルとは、開発者がAssetMakerのタグを使用してベーシック・アセット・タイプを定義する有効なXML文書のことです。アセット記述子ファイルは、次を行います。

- データ構造の観点からアセット・タイプを説明します。データベース表名、列名、列のデータ型、WebCenter Sitesフォームのフィールド・サイズを指定します。

- 指定されたタイプのアセットをユーザーが操作する際に、WebCenter Sitesによって表示されるHTMLフォームの書式設定を行います。HTMLフォームの書式設定とは、フォーム上のフィールドに名前を付け、必要なフォーマットでフィールド(チェック・ボックス、ラジオ・ボタン、ドロップダウン・リストなど)を表示し、フィールドの仕様(テキスト・フィールドに入力できる文字数など)を指定することなどです。

AssetMakerはアセット記述子ファイルを使用して、新しいアセット・タイプのデータベース表を作成します。指定されたタイプのアセットをコンテンツ・プロバイダが操作(作成や編集など)すると、AssetMakerはアセット記述子ファイルを解析し、ファイル内のデータを使用して、WebCenter Sitesが表示するフォームをカスタマイズします。

注意:

参照用に、AssetMakerのサンプル記述子コードがWebCenter Sitesインストール媒体に提供され、「Samples」フォルダに格納されます。同じフォルダには、サンプル記述子ファイルを説明するreadme.txtファイルが格納されています。

5.1.2.2 フォーマットと構文について

すべてのアセット記述子ファイルの基本的なフォーマットは、次のとおりです。AssetMakerのそれぞれのタグの右側に、そのタグについての簡単な説明が示されています。

<?xml version="1.0" ?>
<ASSET ...> Names the asset type (storage table)
<PROPERTIES> Starts the properties specification section
<PROPERTY ...> Specifies column and field name for the property
<STORAGE .../> Specifies data type for the column
<INPUTFORM .../> Specifies field format on New, Edit, Inspect forms
<SEARCHFORM .../> Specifies field format on Advanced Search form
<SEARCHRESULTS .../> Specifies which fields are shown in search results
</PROPERTY>
<PROPERTY ...>
<STORAGE .../>
<INPUTFORM .../>
<SEARCHFORM .../>
<SEARCHRESULTS .../>
</PROPERTY>
<PROPERTY ...>
...
</PROPERTIES> Ends the properties specification section
</ASSET> Ends the asset descriptor file

次の例は、AssetMakerのタグが使用できるパラメータの一部を示す、アセット記述子ファイルの構文です。

<?xml version="1.0" ?>
<ASSET NAME="assetTypeName" DESCRIPTION=""assetTypeName" ...>
<PROPERTIES>
<PROPERTY NAME="fieldName1" DESCRIPTION="fieldName1"/>
<STORAGE TYPE="VARCHAR" LENGTH="36"/>
<INPUTFORM TYPE="TEXT" DESCRIPTION="fieldName1".../>
<SEARCHFORM TYPE="TEXT" DESCRIPTION="fieldName1".../>
<SEARCHRESULTS INCLUDE="TRUE"/>
</PROPERTY>
<PROPERTY NAME="fieldName2" DESCRIPTION="fieldName2"/>
<STORAGE TYPE="INTEGER" LENGTH="4"/>
<INPUTFORM TYPE="TEXT" DESCRIPTION="fieldName2".../>
<SEARCHFORM TYPE="TEXT" DESCRIPTION="fieldName2".../>
<SEARCHRESULTS INCLUDE="TRUE"/>
</PROPERTY>
...
</PROPERTIES>
</ASSET>

WebCenter Sitesタグとそれらのパラメータ、およびサンプル・コードの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

5.1.2.3 AssetMakerのタグについて

- アセット記述子ファイルは、次のように標準のXMLバージョンのタグで始まります。
<?xml version="1.0"?>

- XMLバージョン・タグの後に続くASSETタグが、アセット・タイプ、つまりWebCenter Sitesデータベースの記憶域表の名前を付けます。また、ASSETタグはアセット・タイプの一部の動作属性や表示属性を設定し、たとえば、ASSETタグは必須フィールドを指定するグラフィック表記を決定したり、アセットをプレビューできるかどうかを決定します。
開始タグの<ASSET>は常にコードの1行目にあり、終了タグの<\ASSET>は常にアセット記述子ファイルの最後の行にあります。アセット記述子ファイルごとにアセット・タイプは1つのみ作成されるため、各アセット記述子ファイルには一対のASSETタグしか存在しないことに注意してください。

- PROPERTIESタグは、プロパティの説明が保持されているファイルのセクションをマークします。開始タグの<PROPERTIES>は、常にアセット記述子ファイルの2番目の文になります。各アセット記述子ファイルには一対のPROPERTIESしか存在しません。

注意:

PROPERTIESタグは、PROPERTYタグが不要な場合でも、アセット記述子ファイルごとに必要です。

- PROPERTYタグは、対になったPROPERTIESタグ内にネストされていて、このタイプのアセットの列とフィールドを指定します。各PROPERTYタグは、このプロパティに対してユーザーが入力する値を保持する列のデータベース名、および列の表示名(そのフィールド名)を指定し、この表示名は、このタイプのアセットを使用するユーザーに対してレンダリングされるフォーム上に表示されます。

- PROPERTYタグの各ペアの中にネストされるタグは、次のとおりです。

- STORAGE: このプロパティによって構築されている列のデータ型を指定します。STORAGEタグ内のデータ型は、futuretense.iniファイルのデータベース・エントリのプロパティが定義するデータ型の1つにマップする必要があります。

- INPUTFORM: 「新規」、「編集」、「調査」の各フォームのフィールドの名前とフォーマットを指定します。たとえば、そのフィールドは、ドロップダウン・リスト、チェック・ボックス、またはテキスト・フィールドになります。そのフィールドの入力タイプは、STORAGE文で指定されたように、データベース列のデータ型と互換性がある必要があります。

- SEARCHFORM: 「詳細検索」フォームに表示される際のフィールド(プロパティ)のフォーマットを指定します。SEARCHFORM文がPROPERTYセクションから削除されると、定義されているフィールドは「詳細検索」フォームに表示されません。
TYPEパラメータの値をTableまたはDateに設定すると、ドロップダウン・リストはアセット・タイプの「詳細検索」フォームには表示されますが、「標準検索」フォームには表示されません。

- SEARCHRESULTS: 検索実行後に検索結果フォームに表示されるフィールドを指定します。このフィールド値は、INCLUDEパラメータがtrueに設定されている場合にも表示されます。このタグはオプションです。
標準フィールドを変更する場合には、SEARCHRESULTSを名前や説明に対してtrueに設定しないでください。

AssetMakerタグおよびそれらのパラメータの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。その項には、STORAGE TYPE、INPUTFORM TYPEおよびSEARCHFORM TYPEの各パラメータ間の依存性や制限についても記載されています。

5.1.3 アセット・タイプのデータベース表の列

AssetMakerにより新しいアセット・タイプに対してデータベース表が作成されると、アセット記述子ファイルのPROPERTYタグで定義されたすべてのプロパティに対して列が作成され、その基本的な機能についてWebCenter Sitesで必要となるデフォルトの列が作成されます。各アセット・タイプの表内のデフォルトの列のリストについては、「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

この項には次のトピックが含まれます:

- ソース列: 特殊な場合

- 列の記憶域のタイプ

- フィールドの入力タイプ

- 標準アセット・フィールドのデータ型

5.1.3.1 ソース列: 特殊な場合

すべてのアセット・タイプ表には、source列を入れることも可能です。WebCenter Sitesには、Source表に行を追加する際に使用する、「一般的な管理」ツリーの「管理」ノードに、Source表と「ソース」フォームが用意されています。この機能を使用して、アセットが最初に作成された場所を特定できます。ただし、前述の表に記載された列とは異なり、source列はAssetMakerによるアセット・タイプ表の作成時に自動的に作成されません。ソース列を表に追加してアセット・フォームに表示させるには、そのPROPERTYの説明をアセット記述子ファイルに追加する必要があります。たとえば、例5-2 を参照してください。

5.1.3.2 列の記憶域のタイプ

STORAGE TYPEパラメータは列のデータ型を指定します。このデータ型は、wcs_properties.jsonファイルに配置されているWebCenter Sitesデータベース・プロパティによって定義されています。

表5-1は、アセット・タイプの表の列に対応できるデータ型を示しています。

表5-1 STORAGE TYPEパラメータ

タイプ(汎用ODBC/JDBCデータ型)

プロパティ

CHAR

cc.char

VARCHAR

cc.varchar

SMALLINT

cc.smallint

INTEGER

cc.integer

BIGINT

cc.bigint

DOUBLE

cc.double

TIMESTAMP

cc.datetime

BINARY

cc.binary

LONGVARCHAR

cc.bigtext

5.1.3.3 フィールドの入力タイプ

INPUT TYPEパラメータは、WebCenter Sitesのフォームにデータが表示される際にフィールドへ入力する方法を指定します。表5-2は、すべての入力タイプを示しています。フィールドへの入力タイプは、列のデータ型に対応している必要があることに注意してください。

表5-2 INPUT TYPEパラメータ

入力タイプ

説明

TEXT

単一行のテキスト。

TEXTという名前のHTML入力タイプに対応します。

TEXTAREA

スクロール・バー付きのテキスト・ボックスで、複数行のテキストに対応します。

TEXTAREAという名前のHTML入力タイプに対応します。

大量のテキストをフィールドに入力できるようにするには、URL列のコンテンツを表示するテキスト・ボックスを作成します。そうするには、PROPERTY NAMEに対してurlで始まる文字列を指定し、STORAGE TYPEをVARCHARに設定する必要があります。

ユーザーが「保存」をクリックすると、この種類のフィールドに入力されたテキストは、このアセット・タイプのデフォルトの記憶域ディレクトリとして指定されたファイル・ディレクトリに保存されます。デフォルトの記憶域ディレクトリ(defdir)は、アセット記述子ファイル、またはアセット・タイプ作成時のAssetMakerフォームで指定できます。

注意:

- urlフィールドの無制限サイズは、MAXLENGTHパラメータの値を指定するのではなく、TEXTAREAフィールドで編集して指定できます。

- PROPERTY NAMEに対してurlという文字で始まる文字列を指定する場合、接尾辞として_type、_size、_folderおよび_fileを使用しないでください。

UPLOAD

ファイル名(URL)を入力して「参照」ボタンを表示するフィールドです(それにより、ファイルへのパスとファイル名を入力するか参照して選択できるようになります)。

フィールドがアップロード・フィールドであることを指定した場合、PROPERTY NAMEに対してurlで始まる文字列を設定し、STORAGE TYPE(プロパティのデータ型)をVARCHARに設定します。

アップロード・フィールドにBLOB記憶域タイプを使用することも可能です。この場合、PROPERTY NAMEの文字列をurlで開始する必要はありません。

ユーザーが「保存」をクリックすると、WebCenter Sitesでは選択したファイルがアップロードされ、このアセット・タイプのデフォルトの記憶域ディレクトリとして指定されたファイル・ディレクトリに保存されます。デフォルトの記憶域ディレクトリ(defdir)は、アセット記述子ファイル、またはファイルのアップロード時のAssetMakerフォームで指定できます。

注意:

- アップロード・フィールドで選択されたファイルのサイズは最大30 MBです。

- PROPERTY NAMEに対してurlという文字で始まる文字列を指定する場合、接尾辞として_type、_size、_folderおよび_fileを使用しないでください。

SELECT

選択可能なオプションのドロップダウン・リストが表示されるフィールドです。

リストに表示されるオプションを指定することも、オプションをデータベース(または外部の表)から選択して動的に表示するように問合せを指定することも可能です。

HTML入力タイプSELECTに対応します。

CHECKBOX

チェック・ボックスのフィールドです。

チェック・ボックスのオプション名を指定することも、オプション名をデータベース(または外部の表)から選択して動的に表示するように問合せを指定することも可能です。この入力タイプにより、複数のオプションを選択できるようになります。

HTML入力タイプCHECKBOXに対応します。

RADIO

ラジオ・ボタンの制御です。

ラジオ・ボタンのオプション名を指定することも、オプション名をデータベース(または外部の表)から選択して動的に表示するように問合せを指定することも可能です。この入力タイプにより、オプションを1つだけ選択できるようになります。

HTML入力タイプRADIOに対応します。

CKEDITOR

CKEditorテキスト・エディタを使用してコンテンツを編集するフィールドです。

CKEditorフィールドを指定するには、フィールドをURLフィールドにすることをお薦めします。つまり、url接頭辞でPROPERTY NAMEに対する文字列を設定し、STORAGE TYPE (プロパティのデータ型)をVARCHARに設定します。

url接頭辞で始まるPROPERTY NAMEに文字列を指定する場合には、接尾辞として_type、_size、_folderおよび_fileは使用しないでください。

ELEMENT

ContentForm、ContentDetails、SearchFormいずれかのフォームにフィールドを表示する際に作成するエレメントをコールします。カスタム・エレメントは、次の場所のいずれかにあります。

- ContentFormフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/ ContentForm/fieldname

- ContentDetailsフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/ContentDetails/fieldname

- SearchFormフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/SearchForm/fieldname

myAssetTypeはカスタム・フィールドを作成しているアセット・タイプであり、fieldnameはカスタム・フィールドの名前です。

ELEMENTフィールドには、BLOBなど、どのような記憶域のタイプでも指定できます。

5.1.3.4 標準アセット・フィールドのデータ型

WebCenter Sitesの標準アセット・フィールドの外観をカスタマイズできます。その他の変更内容はすべて下記のとおりフィールドのタイプに対応しています。

- すべての標準フィールド。表示名を変更できます。

- システム・フィールドではない標準フィールド。次の例外を除いて、データ型を変更しないでください。データ型がVARCHARの長さのみを変更できます。

- システム・フィールド。データ型(VARCHARタイプのフィールドの長さも含めて)を変更しないでください。
表5-3は、標準フィールドのデータ型を示しています(フィールドがシステム・フィールドであるかどうかも示しています)。

表5-3 標準アセット・フィールドのデータ型

標準フィールド

システム・フィールド

データ型

ID

あり

NOT NULL NUMBER(38)

NAME

なし

NOT NULL VARCHAR(64)

DESCRIPTION

なし

VARCHAR(128)

TEMPLATE

あり

VARCHAR(64)

SUBTYPE

なし

VARCHAR(24)

FILENAME

なし

VARCHAR(64)

PATH

なし

VARCHAR(255)

STATUS

あり

NOT NULL VARCHAR(2)

EXTERNALDOCTYPE

あり

VARCHAR(64)

URLEXTERNALDOCXML

あり

VARCHAR(255)

URLEXTERNALDOC

あり

VARCHAR2(255)

CREATEDBY

あり

NOT NULL VARCHAR(64)

UPDATEDBY

あり

NOT NULL VARCHAR(64)

CREATEDDATE

あり

NOT NULL DATE

UPDATEDDATE

あり

NOT NULL DATE

STARTDATE

なし

DATE

ENDDATE

なし

DATE

5.1.4 アセット・タイプに対応したエレメントとSQL文

アセット記述子ファイルをアップロードした後、エレメントを登録します。エレメントを登録すると、AssetMakerによりAssetStubElementCatalog表のエレメントがElementCatalog表内のこのアセット・タイプに対応するディレクトリにコピーされます。さらに、このタイプのアセットに対する「簡易検索」フォームと「詳細検索」フォームに、WebCenter Sites検索を実装する複数のSQL文がコピーされます。

必要に応じて、SQL文、アセット・タイプ固有のエレメント、また場合によってはAssetStubElementCatalog表のエレメントをカスタマイズできます。エレメントのカスタマイズの詳細は、「(オプション)アセット・タイプのエレメントのカスタマイズ」を参照してください。

注意:

いかなる状況においても、その他のWebCenter Sitesエレメントを変更しないでください。

この項には次のトピックが含まれます:

- エレメント

- SQL文

5.1.4.1 エレメント

AssetMakerによって、次のネーミング規則に従って新しいアセット・タイプのエレメントがElementCatalog表に格納されます。

OpenMarket/Xcelerate/AssetType/YourNewAssetType

たとえば、サンプル・アセット・タイプImageFileのエレメントは、次の場所にあります。

OpenMarket/Xcelerate/AssetType/ImageFile

表5-4に、AssetMakerによって各アセット・タイプについてコピーされたエレメントを示します。

表5-4 AssetMakerのエレメント

エレメント

説明

ContentForm

このタイプのアセットに対する「新規」フォームと「編集」フォームをレンダリングします。

この機能が起動されると、AssetMakerによってアセット記述子ファイルでINPUTFORM文を使用してこれらのフォームが書式設定されます。

ContentDetails

このタイプのアセットに対する「調査」フォームを書式設定します。

この機能が呼び出されると、アセット記述子ファイルでINPUTFORM文を使用してこれらのフォームがカスタマイズされます。

SimpleSearch

このタイプのアセットに対する「簡易検索」フォームをレンダリングします。

この機能が呼び出されると、AssetMakerでは、アセット記述子ファイル内のSEARCHFORM 文を使用して、これらのフォームを書式設定します。

SearchForm

このタイプのアセットに対する「詳細検索」フォームを書式設定します。

この機能が呼び出されると、AssetMakerでは、アセット記述子ファイル内のSEARCHFORM 文を使用して、これらのフォームを書式設定します。

AppendSelectDetails

「詳細検索」フォームの個々のフィールドにSQL問合せを作成します。

「詳細検索」フォームがレンダリングされると、アセット記述子ファイルでSEARCHFORM文を使用してそのフォームがカスタマイズされます。

AppendSelectDetailsSE

システムで外部の検索エンジンが使用されると、「詳細検索」フォームの個々のフィールドでSQL文が作成されます。

この機能が呼び出されると、アセット記述子ファイルでSEARCHFORM文を使用してSQL問合せが作成されます。

IndexAdd

IndexAddエレメントとIndexReplaceエレメントは、検索エンジンの使用時に検索エンジンで索引付されるフィールド(列)を設置します。デフォルトでは、標準フィールドのみが索引付されます。その他のフィールドを索引付けするには、これらのフォームをカスタマイズする必要があります。詳細は、「(オプション)アセット・タイプのエレメントのカスタマイズ」を参照してください。

IndexReplace

IndexAddの説明を参照してください。

Tile

「検索結果」ページを書式設定します。このページには、このタイプのアセットに対して、検索基準に適合するアセットが示されています。

このページがレンダリングされると、アセット記述子ファイルでSEARCHRESULTS文を使用してこの結果が表示されます。

LoadTree

このタイプのアセットが、サイト・ナビゲーション・タブ以外の、ツリーの任意のタブに表示される際の外観を決定します。

LoadSiteTree

このタイプのアセットが「サイト」ツリーのサイト・ナビゲーション・ノードに表示される際の外観を決定します。

PreUpdate

データベースに書き込む機能が完了する前にコールされます。つまり、アセットが保存される前の作成、編集、削除またはXMLPostの機能が稼働中に、このエレメントがコールされます。

このエレメントは、アセット記述子ファイルからは何も入力しません。ただし、直接カスタマイズできます。

PostUpdate

データベースへの書込みが終了した後でコールされます。つまり、XMLPostでアセットが作成、編集、削除またはインポートされた後、このエレメントがコールされます。

このエレメントをカスタマイズできます。

5.1.4.1.1 PreUpdateエレメントとPostUpdateエレメントについて

アセットで実行できるアクションや手順を機能と呼びます。たとえば、New、EditおよびDeleteは、AdminインタフェースとOracle WebCenter Sites: Contributorインタフェースのユーザーがアセットの作成、編集および削除の際に起動できるすべての機能です。そのような機能は、PreUpdateエレメントとPostUpdateエレメントもコールします。

PreUpdateエレメントとPostUpdateエレメントを使用して、エレメントがコールされたときに各種操作を開始するロジックを格納します。PreUpdateエレメントは機能が起動されたときにコールされ、PostUpdateエレメントは、WebCenter Sitesがアセット情報をデータベースに書き込んだ後にコールされます。各エレメントには変数が含まれており、その変数の名前と値によりエレメントがコールされる条件が指定されます。Adminインタフェースから、またはContributorインタフェースやXMLPostユーティリティのフォーム・モードからエレメントをコールするには、変数にupdatetypeと名付けます。ContributorインタフェースのWebモードからエレメントをコールするには、変数にservicesUpdateTypeと名付けます。たとえば、コンテンツ・マネージャがAdminインタフェースで稼働しており、そのシステムが記事のバッチを通信社からインポートするように構成されているとします。エレメントでこれらの操作をコーディングして、updatetype=remotepostをエレメントがコールされる条件として設定すれば、インポートの直前にPreUpdateエレメントの「ソース」フィールドの値をwirefeedに、「署名行」フィールドの値をAPIに設定できます。

注意:

PreUpdateエレメントとPostUpdateエレメントは、WebCenter SitesユーザーがAdminインタフェースまたはContributorインタフェースで、「新規」、「編集」、「削除」の各機能を起動するとき、またはアセットがXMLPostを使用してインポートされるときに、常にコールされます。操作がPreUpdateエレメントとPostUpdateエレメントを使用して実行されるかどうかは、それらのエレメントのコード方法によります。デフォルトでは、アクションなしに設計されています。

PreUpdateエレメントとPostUpdateエレメントには、次のパスで、Explorerからアクセスできます。

ElementCatalog\OpenMarket\Xcelerate\AssetType

表5-5は、updatetype変数の値について定義しています。

注意:

Adminインタフェースで新規アセットまたは編集済のアセットを保存すると、PreUpdateエレメントは2回コールされます。

最初のコールは、「新規」フォームまたは「編集」フォームがレンダリングされる前に実行されます。2回目のコールは、「新規」フォームまたは「編集」フォームで「保存」がクリックされた後に行われますが、この時点でWebCenter Sitesではアセット情報がデータベースに書き込まれていません。

前述の条件により、新規機能または編集機能が呼び出されると、PreUpdateを使用して操作を1箇所または数箇所で実行できるようになり、それは、エレメントのupdatetype変数の値に応じて、「新規」フォームか「編集」フォームがレンダリングされる前、アセット情報がデータベースに書き込まれる前、またはその両方のタイミングで発生します。

表5-5 UpdateType変数の値

updatetype =

説明

setformdefaults

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが「新規」機能を起動した場合。

- PreUpdateエレメントは、「新規」フォームがレンダリングされる前にコールされます。

- PostUpdateでは、setformdefaultsはupdatetype変数に対する適切な値ではありません。

create

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが新しいアセットを保存した場合:

- PreUpdateエレメントは、新しいアセットがデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、新しいアセットがデータベースに書き込まれた後でコールされます。

editfront

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが「編集」機能を起動した場合:

- 「編集」フォームがレンダリングされる前に、PreUpdateエレメントがコールされます。

- PostUpdateでは、editfrontはUpdateType変数に対する適切な値ではありません。

edit

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが編集済のアセットを保存した場合:

- PreUpdateエレメントは、編集内容がデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、編集内容がデータベースに書き込まれた後でコールされます。

delete

Adminインタフェースからユーザーがアセットを削除した場合:

- PreUpdateエレメントは、WebCenter Sitesによってアセットが削除される前にコールされます。

- PostUpdateエレメントは、WebCenter Sitesによってアセットが削除された後で実行されます。

remotepost

ユーザーがXMLPost機能を呼び出してアセットをインポートする場合:

- アセットがインポートされる前に、PreUpdateエレメントがコールされます。

- アセットがインポートされた後に、PostUpdateエレメントがコールされます。

InSite

Webモードから保存された場合、servicesUpdateTypeと呼ばれる変数があり、ユーザーの操作に応じて作成、編集または削除を実行します。

表5-6 は、servicesUpdateType変数の値について定義しています。

表5-6 は、servicesUpdateType変数の値について定義しています。

表5-6 servicesUpdateType変数の値(Contributorインタフェース)

servicesUpdateType =

説明

create

Contributorインタフェースでユーザーが新しいアセットを保存した場合:

- PreUpdateエレメントは、新しいアセットがデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、新しいアセットがデータベースに書き込まれた後でコールされます。

edit

Contributorインタフェースでユーザーが編集済のアセットを保存した場合:

- PreUpdateエレメントは、編集内容がデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、編集内容がデータベースに書き込まれた後でコールされます。

delete

Contributorインタフェースでユーザーがアセットを削除した場合:

- PreUpdateエレメントは、WebCenter Sitesによってアセットが削除される前にコールされます。

- PostUpdateエレメントは、WebCenter Sitesによってアセットが削除された後でコールされます。

5.1.4.2 SQL文

AssetMakerによって、次のネーミング規則に従ってSQL文がSystemSQL表に格納されます。

OpenMarket/Xcelerate/AssetType/YourNewAssetType

たとえば、サンプル・アセット・タイプImageFileのエレメントは、次の場所にあります。

OpenMarket/Xcelerate/ImageFile

表5-7は、AssetMakerによって作成されるSQLエレメントを示しています。

表5-7 SQLのエレメント

文

説明

SelectSummary

このタイプのアセットに対する「簡易検索」フォームと「詳細検索」フォームで使用される問合せを定義するSQL文です。

SelectSummarySE

使用されません。

5.2 ベーシック・アセットの作成を開始する前に

ベーシック・アセットの作成を開始する前に、次の各項の説明に従い、設計プランを立て、開発システムを設定する必要があります。

- アセット・タイプの設計の立案

- 開発システムの設定

5.2.1 アセット・タイプの設計の立案

必ずアセット・タイプを紙上で設計してから、アセット記述子ファイルのコーディングを開始してください。下記のような詳細を考慮します。

- 必要なフィールドは何か。
通常、情報を便利な単位にまとめて、使用するフィールド数を最小限にします。その単位を決定する際には、オンライン・サイトに表示する予定の情報と、データを入力するコンテンツ・プロバイダのデータ入力の必要性の両方を考慮します。

- 各フィールドに対する適切なデータ型は何か。

- オプションのあるフィールドの場合、どのようにオプションを表示するか。
アセット記述子ファイルでコーディングされた静的リストにするか、または有効なオプションを記載した参照表にするか。

- どのWebCenter Sitesの機能を使用して、このタイプのアセットを編成したりカテゴリ分けするか。
(ソース、カテゴリ、アセットのアソシエーションなど。)それぞれについて、その名前、および管理システムとオンライン・サイトの設計の両方で使用する方法を決定します。

- サイト設計の実装にはこのタイプのアセットに、パブリッシュ先の公開ターゲットに基づいて異なるデフォルトのテンプレートを使用する必要があるのか。
必要な場合には、「サブタイプ」機能を使用する必要があります。このタイプのアセットに必要なサブタイプの名前を決定します。

5.2.2 開発システムの設定

また、開始する前に必ず開発システムを設定してください。このような準備手順の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

- 適切なサイトを作成します。

- 管理者権限を持つ管理者専用のユーザー名を作成し、開発システムのすべてのサイトでそのユーザー名を有効にします。TableEditorがユーザー名に割り当てられていることを確認してください(確認できないと、アセット・タイプの作成はできなくなります)。

注意:

管理者権限がないと、「一般的な管理」ツリーの「管理」ノードにアクセスできず、この章に記載した手順を実行できません。便宜上、ユーザー名に「デザイナ」ロールと「GeneralAdmin」ロールを割り当てます。そうすることで、すべてのタブと、サンプル・サイト内のアセットへのすべての既存の「スタート・メニュー」ショートカットにアクセスできるようになります。

5.3 ベーシック・アセット・タイプの作成

新しいアセット・タイプの作成にかかる時間の長さは、アセット・タイプの複雑さに応じて幅広い範囲に及びます。

単純なアセット・タイプでは、1つのアセット記述子ファイルをコーディングしてアップロードする必要があります。より複雑なアセット・タイプでは、アセット・タイプに対して作成されたエレメント内のコードを変更するか、ドロップダウン・リストに表示する情報を保持するためにデータベース表を追加する必要があります。

ベーシック・アセット・タイプの作成のタスクは次のとおりです。

- アセット記述子ファイルのコーディング。

- アセット記述子ファイルのWebCenter Sitesへのアップロード(「管理」タブを使用)。

- アセット表の作成(アセット・タイプのエレメントをAssetStubElementCatalog表からElementCatalog表の適切なディレクトリにコピーして、アセット・タイプを登録します)。

- アセット・タイプの構成。

- サイトでのアセット・タイプの有効化(アセット・タイプを使用できるようにスタート・メニューのショートカットを作成します)。

- アセット記述子ファイルの微調整((必要に応じて)アセット・タイプ・エレメントを再登録します)。

- (オプション)アセット・タイプのエレメントのカスタマイズ。

- (オプション)サブタイプの追加(新しいアセット・タイプの場合)。

- (オプション)アソシエーション・フィールドの構成(新しいアセット・タイプの場合)。

- (オプション)カテゴリの構成(新しいアセット・タイプの場合)。

- (オプション)ソースの構成(新しいアセット・タイプの場合)。

- (条件付き) MIMEタイプの追加(新しいアセット・タイプの場合)。

- (オプション)索引付き検索を有効にするための検索エレメントの編集(WebCenter Sitesデータベース検索ユーティリティではなく、検索エンジンを使用して、検索フォームの背後にある論理を実行し、新しいアセット・タイプにそれを使用する場合)。

- アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ) (Contributorインタフェースのナビゲーション・ツリー(「サイト・ツリー」、「コンテンツ・ツリー」および「ワーク」ツリー)でアセット・タイプを表すアイコンを作成して割り当てます)。

- アセット・タイプのテンプレートのコーディング。「テンプレートおよびCSElementのエレメントのコーディング」も参照してください。

- 他のシステムへのアセット・タイプの移動(管理と配信)。これにより、管理者は、ワークフローの設定、スタート・メニュー・アイテムの作成など、アセット・タイプ作成の最後の手順を完了できます。

5.3.1 アセット記述子ファイルのコーディング

「アセット記述子ファイル」で説明されているとおり、次に示すのがアセット記述子ファイルの基本的な書式です。

<?xml version="1.0" ?>
<ASSET NAME="assetName"...>
<PROPERTIES>
<PROPERTY.../>
<STORAGE.../>
<INPUTFORM.../>
<SEARCHFORM.../>
<SEARCHRESULTS.../>
</PROPERTY>
<PROPERTY... />
<STORAGE.../>
<INPUTFORM.../>
<SEARCHFORM.../>
<SEARCHRESULTS.../>
</PROPERTY>
</PROPERTIES>
</ASSET>

アセット記述子ファイルをコーディングするには、Oracle WebCenter Sitesタグ・リファレンスを参照し、そのガイドの説明に従ってタグを使用してファイルをコーディングします。ファイルをコーディングするには、ExplorerのネイティブXMLエディタを使用するか、その他のXMLエディタを使用します。

標準アセット・フィールドをアセット記述子ファイルに追加すると、標準アセット・フィールドの外観をカスタマイズできます。フィールドの記憶域タイプの変更は、条件付きとなります。たとえば、システム・フィールドの記憶域タイプは変更できません。標準フィールドのリスト、それらの記憶域タイプ、および記憶域タイプに許可された変更の詳細は、「標準アセット・フィールドのデータ型」を参照してください。

この項では、サンプルのアセット記述子ファイルとコーディング固有のプロパティの例を示します。

この項では、次の例を示します。

- 例5-1

- 例5-2

- 例5-3

- 例5-4

- 例5-5

- 例5-6

- 例5-7

- 例5-8

- 例5-9

- 例5-10

例5-1 サンプルのアセット記述子ファイル: ImageFile.xml

アセット記述子ファイルImageFile.xmlの例を次に示します。

<!-- this is the description of an asset -->
<ASSET NAME="ImageFile" DESCRIPTION="ImageFile"
MARKERIMAGE="/Xcelerate/data/help16.gif" PROCESSOR="4.0"
DEFDIR="c:\FutureTense\Storage\ImageFile">

<PROPERTIES>

<PROPERTY NAME="source" DESCRIPTION="Source">
<STORAGE TYPE="VARCHAR" LENGTH="24"/>
<INPUTFORM DESCRIPTION="Source" TYPE="SELECT" TABLENAME="Source"
OPTIONDESCKEY="description" OPTIONVALUEKEY="source" SOURCETYPE="TABLE"/>
<SEARCHFORM DESCRIPTION="Source" TYPE="SELECT" TABLENAME="Source"
OPTIONDESCKEY="description" OPTIONVALUEKEY="source" SOURCETYPE="TABLE"/>
</PROPERTY>

<PROPERTY NAME="urlpicture" DESCRIPTION="Image File">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="UPLOAD" WIDTH="36" REQUIRED="NO" LINKTEXT="Image"/>
</PROPERTY>

<PROPERTY NAME="urlthumbnail" DESCRIPTION="Thumbnail File">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="UPLOAD" WIDTH="36" REQUIRED="NO" LINKTEXT="Image"/>
</PROPERTY>

<PROPERTY NAME="mimetype" DESCRIPTION="Mimetype">
<STORAGE TYPE="VARCHAR" LENGTH="36"/>
<INPUTFORM TYPE="SELECT" SOURCETYPE="TABLE" TABLENAME="MimeType"
OPTIONDESCKEY="description" OPTIONVALUEKEY="mimetype"
SQL="SELECT mimetype, description
FROM MimeType
WHERE keyword = 'image'
AND isdefault = 'y'"
INSTRUCTION="Add more options to mimetype table with isdefault=y
and keyword=image"/>
<SEARCHFORM DESCRIPTION="MimeType" TYPE="SELECT" SOURCETYPE="TABLE"
TABLENAME="MimeType" OPTIONDESCKEY="description" OPTIONVALUEKEY="mimetype"
SQL="SELECT mimetype, description
FROM MimeType
WHERE keyword = 'image'
AND isdefault = 'y'"/>
</PROPERTY>

<PROPERTY NAME="width" DESCRIPTION="Width">
<STORAGE TYPE="INTEGER" LENGTH="4"/>
<INPUTFORM TYPE="TEXT" WIDTH="4" MAXLENGTH="4" REQUIRED="NO" DEFAULT=""/>
<SEARCHFORM DESCRIPTION="Width is" TYPE="TEXT" WIDTH="4"
MAXLENGTH="4" VERB="="/>
</PROPERTY>

<PROPERTY NAME="height" DESCRIPTION="Height">
<STORAGE TYPE="INTEGER" LENGTH="4"/>
<INPUTFORM TYPE="TEXT" WIDTH="4" MAXLENGTH="4" REQUIRED="NO" DEFAULT=""/>
<SEARCHFORM DESCRIPTION="Height is" TYPE="TEXT" WIDTH="4"
MAXLENGTH="4" VERB="="/>
</PROPERTY>

<PROPERTY NAME="align" DESCRIPTION="Alignment">
<STORAGE TYPE="VARCHAR" LENGTH="8"/>
<INPUTFORM TYPE="SELECT" SOURCETYPE="STRING"
OPTIONVALUES="Left,Center,Right" OPTIONDESCRIPTIONS="Left,Center,Right"/>
<SEARCHFORM DESCRIPTION="Alignment" TYPE="SELECT" SOURCETYPE="STRING"
OPTIONVALUES="Left,Center,Right" OPTIONDESCRIPTIONS="Left,Center,Right"/>
</PROPERTY>

<PROPERTY NAME="artist" DESCRIPTION="Artist">
<STORAGE TYPE="VARCHAR" LENGTH="64"/>
<INPUTFORM TYPE="TEXT" WIDTH="36" MAXLENGTH="36" REQUIRED="NO" DEFAULT=""/>
<SEARCHFORM DESCRIPTION="Artist contains" TYPE="TEXT"
WIDTH="36" MAXLENGTH="64"/>
</PROPERTY>

<PROPERTY NAME="alttext" DESCRIPTION="Alt Text">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" REQUIRED="NO" DEFAULT=""/>
<SEARCHFORM DESCRIPTION="Alt Text contains" TYPE="TEXT"
WIDTH="48" MAXLENGTH="255"/>
</PROPERTY>

<PROPERTY NAME="keywords" DESCRIPTION="Keywords">
<STORAGE TYPE="VARCHAR" LENGTH="128"/>
<INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="128" REQUIRED="NO" DEFAULT=""/>
<SEARCHFORM DESCRIPTION="Keywords contain" TYPE="TEXT"
WIDTH="48" MAXLENGTH="128"/>
</PROPERTY>

<PROPERTY NAME="imagedate" DESCRIPTION="Image date">
<STORAGE TYPE="TIMESTAMP" LENGTH="8"/>
<INPUTFORM TYPE="ELEMENT" WIDTH="24" MAXLENGTH="48" REQUIRED="NO"
DEFAULT="" INSTRUCTION="Format: yyyy-mm-dd hh:mm"/>
<SEARCHFORM DESCRIPTION="Image date" TYPE="ELEMENT"
WIDTH="48" MAXLENGTH="128"/>
</PROPERTY>

</PROPERTIES>
</ASSET>

例5-2 ソース列とフィールドの追加

WebCenter Sitesの「一般的な管理」ツリーの「管理」ノードには「ソース」機能備わっていますが、デフォルトでソース列は作成されません。ソース機能を新しいアセット・タイプで使用するには、ソース列とフィールドにプロパティ文を追加する必要があります。

次の点に注意してください。

- STORAGE TYPEはVARCHAR,に、LENGTHは24に設定する必要があります。

- INPUTFORM SOURCETYPEはTABLE,に、TABLENAMEはSourceに設定する必要があります。

例:

<PROPERTY NAME="source" DESCRIPTION="Source">
<STORAGE TYPE="VARCHAR" LENGTH="24"/>
<INPUTFORM TYPE="SELECT" TABLENAME="Source"
OPTIONDESCKEY="description"
OPTIONVALUEKEY="source" SOURCETYPE="TABLE"/>
<SEARCHFORM DESCRIPTION="Source" TYPE="SELECT"
TABLENAME="Source" OPTIONDESCKEY="description"
OPTIONVALUEKEY="source" SOURCETYPE="TABLE"/>
</PROPERTY>

例5-3 標準アップロード・フィールドの作成

「参照」ボタンを備えたアップロード・フィールドを作成するには、PROPERTY文を次のようにコーディングします。

1. PROPERTY NAMEに設定する文字列では、先頭の文字をurlにする必要があります。

2. STORAGE TYPEの値をVARCHARに設定する必要があります。

3. INPUT TYPEの値はUPLOADに設定する必要があります。

ImageFileアセット記述子ファイルのアップロード・フィールドのコード・スニペットは、次のとおりです。

<PROPERTY NAME="urlpicture" DESCRIPTION="Image File">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="UPLOAD" WIDTH="36" REQUIRED="NO" LINKTEXT="Image"/>
</PROPERTY>

注意:

アップロード・フィールドで選択できるファイルのサイズは、30 MBに制限されています。

例5-4 テキスト・ボックスを使用したアップロード・フィールドの作成

(ファイルの選択に使用する「参照」ボタンでなく)テキストを入力できるテキスト・ボックスを使用してアップロード・フィールドを作成するには、PROPERTY文を次のようにコーディングします。

1. PROPERTY NAMEに設定する文字列では、先頭の文字をurlにする必要があります。

2. STORAGE TYPEの値をVARCHARに設定する必要があります。

3. INPUT TYPEの値はTEXTAREAに設定する必要があります。

次のコード・スニペットでは、url列のテキスト・エリア・フィールドが作成されます。

<PROPERTY NAME="urlbody" DESCRIPTION="Article Body">
<STORAGE TYPE="VARCHAR" LENGTH="256"/>
<INPUTFORM TYPE="TEXTAREA" COLS="48" ROWS="25" REQUIRED="YES"/>
</PROPERTY>

例5-5 CKEditorを使用したアップロード・フィールドの作成

CKEditorのフィールドを作成するには、次のようにプロパティ文をコーディングします。

1. PROPERTY NAMEでは、先頭の文字をurlにする必要があります。したがって、フィールドでURL列を使用します(そうしないと、フィールドが小さくなりすぎる恐れがあります)。

2. STORAGE TYPEの値をVARCHARに設定する必要があります。

3. INPUT TYPEの値はCKEDITORに設定する必要があります。

<PROPERTY NAME="urlbody" DESCRIPTION="Body">
<STORAGE TYPE="VARCHAR" LENGTH="50"/>
<INPUTFORM TYPE="CKEDITOR" WIDTH="300" HEIGHT="300" REQUIRED="YES"
INSTRUCTION="Be concise! No more than 3 paragraphs."/>
</PROPERTY>

タイプVARCHARの長さは、データが格納されているファイルへのパスの長さです。これは、通常100未満です。長さの値が大きすぎる場合(5000など)、データベースはデータをCLOBとして格納するため、データ記憶域に関する問題の原因になります。また、データがファイルではなくデータベースに格納されるため、URLフィールドが破損する恐れがあります。

例5-6 バイナリ・ファイルをアップロードするアップロード・フィールドの作成

次のコードは、blobをアップロードできるフィールドを作成します。MIMETYPEを指定しないと、「編集」フォームおよび「調査」フォームにblobを表示できなくなります。

<PROPERTY NAME="type_binary" DESCRIPTION="Binary">
<STORAGE TYPE="BINARY"/>
<INPUTFORM TYPE="UPLOAD"
WIDTH="24" MAXLENGTH="64"
MIMETYPE="application/msword"
LINKTEXT="Edit with Microsoft Word"
INSTRUCTION="maps to cc.blob"/>
</PROPERTY>

例5-7 パス、ファイル名、開始日および終了日の有効化

パス、ファイル名、開始日および終了日の列は特殊な例です。

AssetMakerにより、PROPERTY文を使用しないでパス、ファイル名、開始日および終了日の列が作成されます。ただし、アセット記述子ファイルにそれらの列に対するPROPERTY文を記述しないと、列は存在してもそれらのフィールドはアセット・フォームに表示されません。

これらの列について、次の事項に注意してください。

- path: STORAGE TYPEをVARCHARに、LENGTHを255に設定する必要があります。

- filename: STORAGE TYPEをVARCHARに、LENGTHを128に設定する必要があります。

- startdate: STORAGE TYPEをTIMESTAMPに設定する必要があります。

- enddate: STORAGE TYPEをTIMESTAMPに設定する必要があります。

注意:

これらの標準列のいずれかをアセット記述子ファイルに追加しても、記憶域タイプがこのリストに指定されているものと一致しない場合には、AssetMakerでアセット・タイプを作成できません。

例:

<PROPERTY NAME="path" DESCRIPTION="Path">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM DESCRIPTION="Path" TYPE="TEXT" LENGTH="255"/>
</PROPERTY>

例5-8 問合せを使用したドロップダウン・リストのオプションの取得

プロパティのINPUTFORM TYPEがSELECTの場合、WebCenter Sitesの選択フィールドのドロップダウン・リストには、OPTIONDESCRIPTIONSパラメータで設定した項目の静的リスト、またはWebCenter Sitesでデータベース表から動的に取得した項目のリストが移入されます。

ドロップダウン・リストを表から動的に移入する選択フィールドの別の例は、imagefileフォームのMimetypeフィールドで、このフィールドでは、そのオプションに対するMimeType表を問い合せます。コードは次のとおりです。

<PROPERTY NAME="mimetype" DESCRIPTION="Mimetype">

<STORAGE TYPE="VARCHAR" LENGTH="36"/>
<INPUTFORM TYPE="SELECT" SOURCETYPE="TABLE"
TABLENAME="mimetype" OPTIONDESCKEY="description"
OPTIONVALUEKEY="mimetype" SQL="SELECT mimetype, description
FROM mimetype
WHERE keyword = 'image'
AND isdefault = 'y'"
INSTRUCTION="Add more options to mimetype table
with isdefault=y and keyword=image"/>

<SEARCHFORM DESCRIPTION="Mimetype" TYPE="SELECT"
SOURCETYPE="TABLE" TABLENAME="mimetype"
OPTIONDESCKEY="description" OPTIONVALUEKEY="mimetype"
SQL="SELECT mimetype, description
FROM mimetype
WHERE keyword ='image'
AND isdefault = 'y'"/>

</PROPERTY>

この例は、データベース表からの項目を選択するだけではなく、追加のSQL問合せによってデータベース表から返される項目をさらに制限するフィールドも示しています。

例5-9 問合せを使用したラジオ・ボタンのラベルの取得

RADIOをプロパティのINPUTFORM TYPEとして使用し、OPTIONDESCRIPTIONSパラメータで設定した項目の静的リスト、またはWebCenter Sitesがデータベース表から動的に取得した項目のリストを使用して各ラジオ・ボタンにラベルを入力します。

次のサンプル・コードは、CreditCard表から取得したラベルでラジオ・ボタンを作成します。

<PROPERTY NAME="sqlrbcc" DESCRIPTION="SQL RB Credit Card">
<STORAGE TYPE="VARCHAR" LENGTH="4"/>
<INPUTFORM TYPE="RADIO" SOURCETYPE="TABLE" TABLENAME="CreditCard"
RBVALUEKEY="ccvalue" RBDESCKEY="ccdescription" />
<SEARCHFORM TYPE="SELECT" DESCRIPTION="Credit Card:" SOURCETYPE="TABLE"
TABLENAME="CreditCard" OPTIONVALUEKEY="ccvalue" OPTIONDESCKEY="ccdescription"
SQL="SELECT ccvalue,ccdescription
FROM CreditCard ORDER BY ccdescription"/>
</PROPERTY>

例5-10 ELEMENT入力タイプを使用したフィールドの作成

必要に応じてフィールドをアセット・フォームに表示するには、ELEMENT入力タイプを使用して、カスタム・コードをコールします。この方法は、アセット・フィールドの作成または標準アセット・フィールドの外観の変更に使用しますが、標準アセット・フィールドの記憶域タイプは変更できません。

ELEMENTフィールドには、BLOBなど、どのような記憶域のタイプでも指定できます。フィールドの入力タイプをELEMENTに設定した場合、WebCenter Sitesではそのフィールドを表示する際にカスタム・エレメントがコールされます。カスタム・エレメントは、次の場所のいずれかにあります。

ContentFormフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/ContentForm/fieldname

ContentDetailsフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/ContentDetails/fieldname

SearchFormフォーム上のフィールドの場合:

OpenMarket/Xcelerate/AssetType/myAssetType/SearchForm/fieldname

myAssetTypeはカスタム・フィールドを作成しているアセット・タイプであり、fieldnameはカスタム・フィールドの名前であることに注意してください。

アセット記述子ファイルからの次の抜粋では、ELEMENT入力タイプが使用されています。

<PROPERTY NAME="imagedate" DESCRIPTION="Image date">
<STORAGE TYPE="TIMESTAMP" LENGTH="8"/>
<INPUTFORM TYPE="ELEMENT" WIDTH="24" MAXLENGTH="48" REQUIRED="NO" DEFAULT=""
INSTRUCTION="Format: yyyy-mm-dd hh:mm"/>
<SEARCHFORM DESCRIPTION="Image date" TYPE="ELEMENT"
WIDTH="48" MAXLENGTH="128"/>
</PROPERTY>

入力フォームではカスタマイズされたフィールドが使用されますが、検索フォームとコンテンツ詳細フォームではデフォルトのフィールドが表示されることに注意してください。

次のコードの抜粋は、記述子ファイルがコールするエレメントです。

<!-- OpenMarket/Xcelerate/AssetType/ImageFile/ContentForm/imagedate
-
- INPUT
- Variables.AssetType
Variables.fieldname
Variables.fieldvalue- default or value for this field
Variables.datatype - from STORAGE tag in ADF for this field
Variables.helpimage - help icon
Variables.alttext - help text from INPUT tag in ADF
Other fields from input tag are in:
Variables.assetmaker/property/Variables.fieldname/inputform/[tag attribute]
- field name used in form should be Variables.AssetType:Variables.fieldname

- OUTPUT
-
-->
Enter date in the format yyyy-mm-dd hh:mm:ss<br/>

<setvar
NAME="inputfieldsize"
VALUE="Variables.assetmaker/property/Variables.fieldname/inputform/width"/>

<callelement NAME="OpenMarket/Xcelerate/Scripts/FormatDate"/>

<INPUT TYPE="text" SIZE="Variables.inputfieldsize"
NAME="Variables.AssetType:Variables.fieldname"
VALUE="Variables.fieldvalue"
REPLACEALL="Variables.inputfieldsize,Variables.fieldvalue,Variables.fieldname,
Variables.AssetType"onChange="padDate(this.form.elements['Variables.AssetType:
Variables.fieldname'].value,this,'Variables.AssetType:Variables.fieldname'
);"/>

</FTCS>

ELEMENT入力タイプを使用して必要な数のフィールドをカスタマイズできますが、フィールドごとに個別のエレメントを記述する必要があります。

5.3.2 アセット記述子ファイルのWebCenter Sitesへのアップロード

アセット・タイプに対応したアセット記述子ファイルをコーディングした後、AssetMakerを使用してそれをアップロードして新しいエレメントを登録します。

1. Adminインタフェースを開きます。

2. 「一般的な管理」ツリーを選択して、「管理」ノードを開きます。

3. 「AssetMaker」を開いて、「新規追加」をクリックします。

「新規AssetMakerアセット・タイプの追加」フォームが開きます。

4. 「名前」フィールドに、新しいアセット・タイプの名前を入力します。このフィールドに入力する文字列は、アップロードするアセット記述子ファイルのASSET NAMEで指定された文字列と完全に一致している必要があります。

5. 「記述子ファイル」フィールドで、「参照」をクリックして。アセット記述子ファイルを選択します。

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

AssetMakerでは、ファイルがAssetType表に入力され(つまり、アセット記述子ファイルがAssetType表のデフォルトの記憶域ディレクトリにアップロードされ)、「アセット・タイプ」フォームが開きます。

「アセット・タイプ」フォームが開きます(図5-2)。

図5-2 「アセット・タイプ」フォーム

5.3.3 アセット表の作成

この手順は、「アセット記述子ファイルのWebCenter Sitesへのアップロード」の手順6からの続きです。

1. 「アセット表の作成」を選択します。

2. 「Defdir」フィールドの値を調べて、必要に応じて変更します。AssetMakerはこの値をアセット記述子ファイルから読み取ります。次のいずれかの条件がある場合には、このフィールドに値を入力する必要があります。

- アセット記述子のASSETタグに対応するDEFDIRパラメータを使用して値を入力しなかった場合。

- デフォルトの記憶域ディレクトリを変更する場合(これは、アセット・タイプを別のシステムに移行する際の典型的な状況です)。

「「一般」カテゴリの追加」オプションを有効にします。Asset MakerによってCategory表に、新しいアセット・タイプに対応する行が1つ追加され、そのカテゴリに「一般」という名前が付けられます。

3. 「アセット表の作成」をクリックします。

AssetMakerによって表が作成され、確認が表示されます。

4. 「アセット・エレメントの登録」を選択して、「アセット・エレメントの登録」をクリックします。

エレメントがAssetStubElementCatalog表からElementCatalog表のアセット・タイプのディレクトリにコピーされ、SQL文がSystemSQL表にコピーされます。

終了すると、確認が表示されます。

5.3.4 アセット・タイプの構成

AssetMakerで新しいアセット・タイプが作成されると(「アセット記述子ファイルのWebCenter Sitesへのアップロード」)、アイコンと新しいアセット・タイプを構成するための管理フォームも作成され、「一般的な管理」ツリーの「管理」ノードに配置されます。

アセット・タイプを構成する手順:

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」アイコンを開きます。

2. 「アセット・タイプ」で、新しいアセット・タイプを選択します。リストに表示されていない場合は、右クリックし、コンテキスト・メニューからリフレッシュを選択して、新しいアセット・タイプを選択します。

3. 「編集」をクリックします。

「アセット・タイプの編集」フォームが開きます(図5-3)。

図5-3 「アセット・タイプの編集」フォーム

4. (オプション)「説明」フィールドで、必要に応じて値を変更します。このフィールドのテキストには、フォームのこのアセット・タイプに対してWebCenter Sitesで使用される名前と、WebCenter Sitesインタフェースのリストが記述されています。デフォルトでは、「説明」はアセット記述子ファイルのASSET DESCRIPTION文の値に設定されています。

5. (オプション)「複数形」フィールドで、必要に応じて値を変更します。このフィールドのテキストには、複数形でアセット・タイプを参照するのが適切な場合に、WebCenter SitesがAdminインタフェースで使用するテキストが記述されています。デフォルトでは、「複数形」はアセット記述子ファイルのASSET DESCRIPTION文の値に「s」を追加して設定されています。アセット記述子ファイルの複数形を独自で指定するには、ASSETタグのPLURALパラメータの値を設定します。

6. (オプション)「子アセットに設定可能」フィールドで、必要に応じて値を変更します。デフォルトでは、このフィールドは「True」に設定されています。つまり、このアセット・タイプは別のアセット・タイプのアソシエーション・フィールドで子アセット・タイプである可能性があります。その名前は、「新規アソシエーションの追加」フォームの「子アセット」フィールドにあるアセット・タイプのリストに表示されます。

7. (オプション)ディメンションを使用フィールドで、必要に応じて値を変更します。デフォルトでは、このフィールドはTrue (このアセット・タイプは多言語コンテンツの作成をサポートします)に設定されます。

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

5.3.5 サイトでのアセット・タイプの有効化

新しいエレメントがアセット・タイプにレンダリングするフォームを調べる前に、作業するサイトでアセットを有効にし、それに対して簡単なスタート・メニュー・アイテムを作成する必要があります。

アセット・タイプを有効にして、それらにスタート・メニュー・アイテムを作成する手順は、『Oracle WebCenter Sitesの管理』を参照してください。

5.3.6 アセット記述子ファイルの微調整

新しいタイプの新しいアセットを作成し、「新規」、「編集」、「調査」および「検索」の各フォームを調べます。(このタイプの新しいアセットを作成するには、ツールバーの「新規」をクリックし、前述の手順で作成したスタート・メニュー・ショートカットを選択します。)

フォームを調べた後、アセット記述子ファイルを変更する必要が生じることがあります。

次のいずれかの項目を比較的少ない手順で変更できます。

- アセット・タイプのWebCenter Sitesフォームに表示されるフィールドの並替え。

- フィールド名(PROPERTY DESCRIPTIONの値)の変更

- INPUTFORM、SEARCHFORM、SEARCHRESULTSいずれかの文におけるなんらかの変更

前述のリストになんらかの変更を加えるには、次の手順を実行します。

1. Explorerを使用して、「アセット記述子ファイルのWebCenter Sitesへのアップロード」でアップロードしたアセット記述子ファイルを開いて変更します。

2. 変更を保存します。

3. アセット・タイプのエレメントを登録しなおします。

アセット・タイプのデータベース表の作成後は、そのスキーマを変更できません。スキーマの変更内容を次に示します。

- 列名(既存のPROPERTY文のNAMEパラメータ)の変更。

- 列のデータ型(既存のPROPERTY文のSTORAGE TYPEまたはLENGTH)の変更。

- 新しいプロパティ(新しいPROPERTY文)の追加。これにより表に新しい列が追加されます。

- プロパティ(既存のPROPERTY文)の削除。これにより表から列が削除されます。

したがって、前述のリストのいずれかの変更を実行するには、まずアセット・タイプを削除し、アセット記述子ファイルを変更し、アセット・タイプを再び作成します。

AssetStubElementCatalog表からElementCatalog表のアセット・タイプのディレクトリにコピーしたエレメントをカスタマイズした場合、変更内容はエレメントを再登録した時点で上書きされることに注意してください。

5.3.7 (オプション)アセット・タイプのエレメントのカスタマイズ

コンテンツ管理システムでアセット・タイプのエレメントをカスタマイズする方法を次に示します。

- 特定のアセット・タイプに固有な変更の場合、Explorerを使用して、そのアセット・タイプのエレメントをElementCatalog表で変更します。エレメントの変更の詳細は、「PreUpdateエレメントとPostUpdateエレメントについて」を参照してください。

- すべてのタイプのアセットに同じ変更を加えるには、Explorerを使用して、AssetStubElementCatalog表のソース・エレメントを変更してから、アセット・タイプを作成します。その方法では、一度だけカスタマイズする必要があります。

注意:

AssetStubElementCatalog表のソース・エレメントのカスタマイズが必要な場合もありますが、サポートされていません。スタブ・エレメントをカスタマイズする場合には、次の条件で上書きされることを考慮してください。

- スタブ・エレメントを変更する場合には、新しい変更内容を取得する必要があるすべてのアセット・エレメントを再登録する必要があります。アセット・エレメントの再登録では、AssetMakerはエレメントの新しいコピーをAssetStubElementCatalog表からElementCatalog表内のアセット・タイプのディレクトリに移動し(パスはElementCatalog\OpenMarket\Xcelerate\AssetType)、このプロセスで既存のエレメントを上書きします。AssetTypeディレクトリにあるカスタマイズしたエレメントは上書きされます。

- WebCenter Sitesアップグレード・プロセスでは、通常、新しいソース・エレメントはAssetStubElementCatalog表にインストールされます。スタブ・エレメントのコードの変更は、アップグレード後にアセット・タイプを再登録すると上書きされます。

すべてのカスタマイズのトラッキングについては、常に細心の注意を払ってください。その方法で、必要に応じて作業を作成しなおすことができます。

変更可能なアセット・タイプ・エレメントの詳細は、「エレメント」を参照してください。

5.3.8 (オプション)サブタイプの追加

サブタイプとは、アセットがレンダリングされる方法に基づいたベーシック・アセット・タイプのサブクラスです。サブタイプを使用して、各公開ターゲットでそのタイプおよびサブタイプのアセットに対する個々のデフォルトの承認テンプレートを定義します。

次の手順を実行して、サブタイプを作成します。

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」オプションを開きます。

2. 「アセット・タイプ」オプションの下で、サブタイプの作成対象とするアセット・タイプを選択します。

3. 「サブタイプ」オプションを選択します。

「サブタイプ」フォームが開きます(図5-4)。

図5-4 「アセット・タイプのサブタイプ」ダイアログ

4. 「新規サブタイプの追加」をクリックします。

5. 次のフォームの「名前」列に、サブタイプの名前を入力します。

6. 「サイト」列の対応するフィールドで、このサブタイプに必要なサイト名を選択します。

7. 最大5つのサブタイプまでこれらの手順を繰り返します。

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

5.3.9 (オプション)アソシエーション・フィールドの構成

アソシエーションとは、親子関係を説明するアセット・タイプ固有の関係、または個々のアセットやアセットのサブタイプ間のリンクのことです。アソシエーションは、「ベーシック・アセット・モデル」で説明されています。

テンプレート・エレメントをコーディングする際に、これらの関係の名前を使用して個々のアセットやサブタイプを特定するため、オブジェクト名でオブジェクトを参照する必要はありません。たとえば、イメージ・ファイル・アセットが記事アセットに関連付けられているサイトでは、テンプレート・エレメントは、アセットの名前ではなくアソシエーションの名前で関連付けられたイメージ・ファイル・アセットを抽出するようにコーディングされます。これにより、テンプレートをコーディングしなおす必要なく、記事に異なるイメージ・ファイルをテンプレートで表示できます。

アソシエーションは、アセット・フォームのフィールドとして表されます。これらのフィールドはアセット記述子ファイルからは作成されません。かわりに、「一般的な管理」ツリーの「管理」ノードの「アセットのアソシエーション」フォームを使用します。

アソシエーション・フィールドを追加する手順は次のとおりです。:

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」を開きます。

2. 「アセット・タイプ」オプションで、アソシエーションを作成するアセット・タイプを選択します。

3. 選択したアセット・タイプで、「アセットのアソシエーション」→「新規追加」を選択します。

「新規アソシエーションの追加」フォームが開きます(図5-5)。

図5-5 「新規アソシエーションの追加」ダイアログ

4. 「名前」フィールドで、スペース、小数点または引用符を使用せずにアソシエーション・フィールド名を入力します。

5. 「説明」フィールドに、フィールドの短い説明を入力します。WebCenter Sitesでは、新しいアセット・フォームに表示される際、このフィールドに入力したテキストがフィールド名として使用されます。

6. 「子アセット」フィールドで、このフィールドに表示されるアセット・タイプの種類を選択します。(「子アセット」フィールドと呼ばれるのは、アソシエーションがアセット間の親子関係を作成しているためです。)このフィールドでは、テンプレートやページ・アセット・タイプを指定できません。

7. 「サブタイプ」フィールドで、このアソシエーションに対する1つまたは複数のサブタイプを強調表示して選択します。複数のサブタイプを選択するには、選択内容をマウスでクリックしながら[Ctrl]キーを押します。

8. 「依存性タイプのミラーリング」セクションで、このアセットのアソシエーションに最適なオプションを選択します。デフォルトでは、「存在」に設定されています。ここで指定された依存性タイプは、公開方法がサーバーに対してミラーの場合、承認システムで使用されます。依存性タイプの詳細は、「依存性をログに記録するためのコーディングについて」を参照してください。

9. 「新規アソシエーションの追加」をクリックします。

WebCenter Sitesでは、このアソシエーションの「アソシエーション」表に行が作成されます。この行で使用される名前は、手順4で「名前」フィールドに入力したテキストです。

5.3.10 (オプション)カテゴリの構成

カテゴリを使用して、サイト設計に対応した一部の表記規則に従ってアセット・タイプを編成します。すべてのベーシック・アセット・タイプに「カテゴリ」フィールド(列)がデフォルトで備わっていますが、それは必須フィールドではなく、使用する必要はありません。

カテゴリを追加する手順は次のとおりです。:

1. 「管理」ノードで、「アセット・タイプ」を選択します。

2. 「アセット・タイプ」オプションで、カテゴリを作成するアセット・タイプを選択します。たとえば、「記事」を選択します。

3. 該当するアセット・タイプで、「カテゴリ」→「新規追加」を選択します。

「新規カテゴリの追加」フォームが開きます(図5-6)。

図5-6 「新規カテゴリの追加」ダイアログ

4. 「説明」フィールドに、カテゴリの短い説明を入力します。WebCenter Sitesでは、このフィールドに入力したテキストがサイト・ツリーと、このタイプのアセットに対するフォームの「カテゴリ」フィールドのドロップダウン・リストで使用されます。

5. 「カテゴリ・コード」フィールドに、新しいカテゴリの2文字コードを入力します。

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

7. 必要に応じて、手順2から6を繰り返し、このアセット・タイプのカテゴリの作成を終了します。

作成したカテゴリは、新規アセットの作成またはアセットの編集時に「カテゴリ」フィールドのドロップダウン・リストに表示されます。

5.3.11 (オプション)ソースの構成

ソースは、システムのすべてのサイトのすべてのアセット・タイプに適用します。したがって、ソースを一度のみ追加する必要があります(各アセット・タイプに追加するのではなく)。

ソースを作成する手順は次のとおりです。:

1. 「管理」ノードで、「ソース」→「新規追加」を選択します。

「新規ソースの追加」フォームが開きます。

2. 「ソース」で、ソースの名前を入力します。

3. 「説明」で、ソースの短い説明を入力します。WebCenter Sitesでは、アセットに対するフォームの「ソース」フィールドのドロップダウン・リストで、このフィールドに入力したテキストが使用されます。

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

ソースがSource表に書き込まれます。

5. アセット・タイプに必要な各ソースに対して、手順1から4を繰り返します。

5.3.12 (条件付き) MIMEタイプの追加

MimeType表には、MIMEタイプのフィールドに表示できるMIMEタイプ・コードが保持されています。MimeType表をアセット記述子ファイルで参照する場合、アセットにMIMEタイプを追加する必要があります。たとえば、イメージファイルとスタイルシートの両方のアセット・タイプで、横に「参照」ボタンのあるフィールドをアップロードしてあるとします。アップロード・フィールドでファイルを選択したら、「MIMEタイプ」ドロップダウン・リストから選択したファイルのMIMEタイプを指定します。

イメージ・ファイル・アセット・タイプとスタイルシート・アセット・タイプの「MIMEタイプ」フィールドは、keyword列に基づいたMIMEタイプ・コードのMimeType表を問い合せます。

- keywordがstylesheetに設定されているMIMEタイプ・コードが、「スタイルシート」フォームの「MIMEタイプ」フィールドのドロップダウン・リストに表示されます。

- keywordがimageに設定されているMIMEタイプ・コードが、「イメージ・ファイル」フォームの「MIMEタイプ」フィールドのドロップダウン・リストに表示されます。

デフォルトでは、スタイルシートのファイルはCSSファイル、イメージファイルのファイルはGIFファイルまたはJPEGファイルになります。これらのアセット・タイプ、独自のカスタム・アセット・タイプ、またはその他の理由に対するMIMEタイプ・コードを追加できます。

「MIMEタイプ」ドロップダウン・リストにMIMEタイプを追加する手順:

1. Explorerを開きます。

2. 「MIMEタイプ」表を開きます。

3. 次のいずれかを行います:

- イメージ・ファイル・アセット・タイプにMIMEタイプを追加するには、MimeType表でimageを選択します。

- スタイルシート・アセット・タイプにMIMEタイプを追加するには、MimeType表でtextを選択します。

- アップロード・フィールド持つカスタム・アセット・タイプ、またはその他の理由に対してMIMEタイプをカスタム・アセット・タイプに追加には、MimeType表の適切な場所を選択します。

4. 右のフレーム内を右クリックし、ドロップダウン・リストから「新規」を選択します。

Explorerによって、新しい行が表に作成されます。

5. 「MIMEタイプ」フィールドに、MIMEタイプ名を入力します。たとえば、XSLです。

6. 「拡張機能」フィールドに、このタイプのMIMEタイプの拡張子を入力します。たとえば、xmlと入力します。

7. 「説明」フィールドに、MIMEタイプの短い説明を入力します。

8. 「デフォルト」フィールドで、次のいずれかを実行します。

- 同一のMIMEタイプに複数の拡張子を指定するには、nと入力します。たとえば、JPGというMIMEタイプにjpgとjpegの拡張子がある場合、「デフォルト」をnに設定します。

- これがMIMEタイプに対する唯一の拡張子の場合、yと入力します。

9. 「キーワード」フィールドで、次のいずれかを実行します。

- イメージ・ファイル・アセット・タイプにMIMEタイプを追加するには、imageと入力します。

- スタイルシート・アセット・タイプにMIMEタイプを追加するには、stylesheetと入力します。

- アップロード・フィールド持つカスタム・アセット・タイプ、またはその他の理由に対してMIMEタイプを追加するには、適切なキーワードを入力します。

10. 「ファイル」→「すべて保存」を選択します。

Explorerによって行が保存されます。

keywordがimageに設定されているMIMEタイプのコードを追加した場合、そのMIMEタイプのコードは「イメージ・ファイル」フォームの「MIMEタイプ」フィールドに表示されます。keywordがstylesheetに設定されているMIMEタイプのコードを追加した場合、そのMIMEタイプのコードは「スタイルシート」フォームの「MIMEタイプ」フィールドに表示されます。

5.3.13 (オプション)索引付き検索を有効にするための検索エレメントの編集

WebCenter SitesとOracle WebCenter Sites: Engageには、標準検索と詳細検索を実行する独自のデータベースSQL検索メカニズムが備わっています。ただし、サポートされているサード・パーティの検索エンジンのいずれかに管理システムを設定することも可能です。構成情報は、『Oracle WebCenter Sitesの管理』を参照してください。

管理システムで検索エンジンを使用する場合、各アセットは作成後または編集後に保存される際に索引付けされます。デフォルトでは、デフォルト・フィールドのみが索引付けされます(リストは、「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください)。アセット記述子ファイル内のPROPERTY文で作成したフィールドを索引付けするには、次のエレメントでフィールド用の文を追加します。

- OpenMarketXcelerate/AssetType/YourAssetType/IndexAdd.xml

- OpenMarketXcelerate/AssetType/YourAssetType/IndexReplace.xml

アセット・タイプのカスタム・フィールドをこれらのエレメントに追加するには、WebCenter Sites INDEXタグを使用してこれらのエレメント用の表記規則に従います。

5.3.14 アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)

Contributorインタフェースのナビゲーション・ツリー(「サイト・ツリー」、「コンテンツ・ツリー」および「ワーク」ツリー)でアセット・タイプを表すアイコンを作成して割り当てます。アイコンはイメージ・ファイルのいずれかのタイプに指定できます(PNG、GIFなど)。この例では、タイプPNGのイメージ・ファイルが作成されます。

1. アセット・タイプを表す20x20ピクセル以内のイメージを作成します。

2. 構文assetType.pngを使用してファイルに名前を付けます。ファイル名は、アイコンが表示されるアセット・タイプを決定します。名前は大/小文字が区別されます。

3. 次のディレクトリにファイルを格納します。

<cs_app_dir>/Xcelerate/OMTree/TreeImages/AssetTypes/

ここで、<cs_app_dir>はアプリケーション・サーバーのデプロイ済WebCenter Sitesアプリケーションのディレクトリです。

4. アプリケーション・サーバーを再起動します(アイコンがContributorインタフェース(「サイト」ツリー、「コンテンツ」ツリーおよび「ワーク」ツリー)に表示されます)。

5.3.15 アセット・タイプのテンプレートのコーディング

アセット・タイプの作成と該当するタイプのアセットに対応するテンプレートのコーディングは、反復プロセスです。

- アセット・タイプを作成して、テンプレート作成前に該当するタイプのアセットに対応するテンプレートを作成する必要がありますが、データ設計の微調整の必要がある領域は、テンプレートをコーディングしてコードをテストした後にのみ明らかになる可能性が高いようです。
テンプレートのコーディングの詳細は、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

5.3.16 他のシステムへのアセット・タイプの移動

すべての新しいアセット・タイプの作成(それらに対するテンプレートの作成も含む)が終了したら、他のシステムへ移行します。

- アセット・タイプを管理システムおよび配信システムに移行します。
次に、システム管理者が管理システムのアセット・タイプを構成します。必要に応じてリビジョン追跡の有効化、ワークフロー・プロセスの作成、スタート・メニューのショートカットの作成などを実行します。

詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

5.4 ベーシック・アセット・タイプの削除

AssetMakerで作成したアセット・タイプを削除すると、WebCenter Sitesでは、選択したアセット・タイプのコンポーネントを削除するか、データベースからアセット・タイプのすべてのトレースを削除できます。アセット・タイプのコンポーネントは次のとおりです。

- データベース表およびその中のすべてのデータ

- ElementCatalog表のエレメント

- SystemSQL表のSQL文

- AssetType表の行

- Association表の行(オプション)

- Category表の行(オプション)

- AssetPublication表の行

- AssetRelationTree表の行

AssetMakerで作成したアセット・タイプを削除する手順は次のとおりです。:

1. Adminインタフェースを開きます。

2. 「一般的な管理」ツリーを選択して、「管理」ノードを開きます。

3. 「AssetMaker」を開いて、削除するアセット・タイプを選択します。

「アセット・タイプ」フォームが開きます。

4. 「アセットの削除」オプションを選択して、「送信」をクリックします。

WebCenter Sitesに確認メッセージが表示されます。

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

6 フレックス・アセット・タイプの設計

フレックス・アセット・タイプのデータ・モデルは、ファミリ内のアセット・タイプごとに複数のデータベース表を持つ、アセット・タイプのファミリです。フレックス・アセット・タイプの設計には、アセット・ファミリの作成およびフレックス属性、親および定義の編集が含まれます。

データ・モデルの概要は、「アセット・モデルの理解」を参照してください。フレックス・アセット・タイプの詳細は、次の項を参照してください。

- フレックス・アセット・タイプの設計について

- フレックス・ファミリの設計ヒント

- フレックス・ファミリ・メーカー・ユーティリティ

- フレックス・アセット・エレメント

- 開発システムの設定

- フレックス・アセット・ファミリの作成

- フレックス属性、親および定義の編集に関する必知事項

- 製品セットの使用

6.1 フレックス・アセット・タイプの設計について

フレックス・ファミリ・メーカー・ユーティリティを使用して、フレックス・アセット・タイプを作成します。フレックス・アセット・モデルで作業する際には、フレックス・アセット・タイプ、およびそれらのタイプの各データ構造のアセットを作成します。フレックス属性、フレックス親定義、フレックス定義、フレックス親アセットなどのタイプの個々のデータ構造のアセットも作成します。

通常、フレックス・アセット・タイプを設計し、開発システムでデータ構造アセットを作成します。データ・モデルの準備ができたら、それを開発システムから管理システムと配信システムに移行します。

6.2 フレックス・ファミリの設計ヒント

フレックス・ファミリ設計時には、開発者は次の2つの対象読者のニーズを満たすデータ構造を作成します。

- オンライン・サイトへの訪問者(配信システムのユーザー)

- WebCenter Sitesデータベースにデータを入力するコンテンツ・プロバイダ(管理システムのユーザー)。

この項には次のトピックが含まれます:

- 配信システムへの訪問者

- 管理システムのユーザー

- 作成する属性タイプの数

- フレックス属性の設計

- 作成する定義タイプの数

- 親定義とフレックス定義アセットの設計

6.2.1 配信システムへの訪問者

オンライン・サイトへの訪問者が参照する画面は、次のアセット・タイプに基づいています。

- フレックス・アセット

- フレックス属性

オンライン・サイトのページには、属性値(searchstates)に基づいた問合せによる訪問者向けフレックス・アセット(assetsets)が表示されます。詳細は、「assetsetおよびsearchstate」を参照してください。オンライン・サイトの階層の外観を指定するには、ドリルダウン検索の基準として属性値を使用します。

6.2.2 管理システムのユーザー

管理システムのユーザーは、次のフレックス・アセット・タイプで作成したビジュアルな階層構造により移動します。

- フレックス親定義

- フレックス定義

- フレックス親

これらのアセット・タイプを使用して作成する組織構造はデータに影響を及ぼしますが、どの属性値をどのフレックス・アセットが継承するかを決定します。最大の影響を受けるのは管理システムのユーザーです。

フレックス親とフレックス親定義の使用は必須ではありませんが、それらの継承プロパティはオンライン・カタログなどの大量のデータを維持するユーザーには有効なツールとなります。

- 親レベルの属性値を変更すると、その親の子供であるフレックス・アセットはすべてその値に変更されるため、値を一度変更するだけで済みます。

- 継承された属性値はユーザーのエラーの影響を受けないため、データのクリーンアップの必要が少なくなります。

コンテンツ・プロバイダ用に作成する継承ツリーは、設計中のオンライン・サイトをサイト訪問者が移動する方法とは何の関係もありません。たとえば、なんらかの完全に自動化されたプロセスで管理システムにコンテンツが入力された場合(ERPシステムからバルク・ロードされた場合など)、親アセット・タイプをまったく必要とせずに、オンライン・サイトでドリルダウン検索を作成できます。

6.2.3 作成する属性タイプの数

「assetsetおよびsearchstate」で説明されているとおり、問合せ(searchstates)は属性に基づいており、親定義やフレックス定義の組織構造に基づいていないため、共通の属性タイプを共有するフレックス・アセットのみが同一のassetsetに所属できます。

個別の属性タイプを使用するようにデータを編成すると、管理システムでは非常に明確なインタフェースを作成できることがありますが、配信システムではそのデータが適切に合成されません。通常、システムに対して1タイプの属性を作成する必要があります。その他のファミリ・メンバーを複数バージョン作成できますが(フレックス・アセット・タイプ、フレックス定義タイプ、フレックス親タイプおよびフレックス親定義タイプ)は、その場合でも属性の同一プールを共有する必要があります。たとえば、avisportsサンプル・サイトでは、記事アセット・タイプとイメージ・アセット・タイプが同一の属性タイプを共有します。したがって、記事およびその記事に対応するイメージが含まれたassetsetを作成できます。

6.2.4 フレックス属性の設計

属性の作成を開始する前に、それを紙上で設計します。必要な属性をすべて指定し、フレックス・アセットまたはフレックス親を使用してそれらを表示する場所を決定します。まず、階層の最下位レベル(製品などのフレックス・アセット・タイプの個々のインスタンス)を計画し、そのレベルの各アイテムに必要な属性を指定します。たとえば、フレックス・フィルタ・アセットを作成する前に、フィルタに対して入力と出力の属性として作成して定義に割り当てる必要のある属性を指定します。

必要なフレックス属性の使用を計画する方法に応じて、作成時に説明する必要のある依存性が作成されるため、それらの属性を事前にすべて指定する必要があります。

6.2.4.1 属性に使用可能なデータ型

属性に対して有効なデータ型とそれらのデータ型のデフォルト入力タイプを評価します。どのデータ型がどの属性に最も効果的に機能するか確認します。属性に対するデフォルトの入力スタイルを変更するには、そのための属性エディタを作成してから属性を作成します。詳細は、「属性エディタの設計」を参照してください。

タイプblobの属性を使用するフレックス・アセットを作成する場合、「調査」フォームに入力する属性値の書式はそのタイプに応じて異なります。たとえば、テキスト・ファイルではファイルの最初の200バイトが表示されます。イメージ・ファイルはサムネイル・イメージとして表示されます。一部のファイルはまったく表示できません。この場合、WebCenter Sitesではファイル名は表示できませんというメッセージが表示されますが、ファイルの場所は正常に記録されています。

6.2.4.2 属性エディタの使用について

属性に対するデフォルトの入力タイプは、選択するデータ型に応じて異なります。デフォルトの入力スタイルを使用するかわりに、属性エディタを作成できます。

フレックス・アセットとその属性エディタの作成は、反復プロセスになります。まず属性エディタを作成するか、最初に属性を作成して、戻って属性エディタを割り当てます。属性エディタの作成のプロセスの詳細は、「属性エディタの設計」を参照してください。

タイプblobの属性について

タイプblobの属性のデフォルト入力スタイルは、「参照」ボタンの付いたテキスト・フィールドです。「参照」をクリックし、ファイルを検索して選択すると、WebCenter Sitesによって、デフォルトの記憶域ディレクトリにアップロードされます。WebCenter Sitesフォームを使用してファイルのコンテンツを編集できません。

WebCenter Sitesフォームを使用して外部ファイルに直接コンテンツを入力できるようにするには、属性エディタを属性に割り当てる必要があります。

- TEXTAREA入力スタイルを使用する属性エディタの場合、最大2,000文字を入力できるフィールド(フォームを使用して入力)を作成します。保存すると、そのコンテンツがデフォルトの記憶域ディレクトリに書き込まれます。

- CKEditorでは、CKEDITORフィールドを使用して属性が表現する外部ファイルのコンテンツを編集できます。

タイプAssetの属性について

タイプAssetの属性に対するデフォルトの入力スタイルは、指定されたタイプのすべてのアセットのドロップダウン・リストです。該当するタイプのアセットが20を超える場合、フィルタのないドロップダウン・リストはお薦めしません。

通常、タイプ・アセットの属性を作成するたびに、それに属性エディタを割り当てる必要があります。

- PICKASSETスタイルを使用する属性エディタは、ツリーがWebCenter Sitesインタフェースのオン/オフで切り替えられるかどうかを確認します。ツリーがオンの場合、ユーザーはツリーのタブからアセットを選択できます。ツリーをオフに切り替えると、属性エディタの「ブックマーク」タブと「履歴」タブで、アセットのリストを表示するダイアログ・ボックスが表示されます。

- もう1つのオプションは、PULLDOWNスタイルの使用ですが、リストに表示されるオプションを制限する問合せアセットを入力するものです。

- 有効な選択肢となるアセット数が少ない場合、CHECKBOXES入力スタイルまたはRADIOBUTTONS入力スタイルを使用し、両方ともアセットを識別する問合せアセットを必要とします。

6.2.4.3 各属性の使用場所

属性のリストを指定した後、それらをフレックス定義またはフレックス親定義のどちらで使用するかを指定します。次のガイドラインに従って、論理的にソートします。

- 属性の値が個々のフレックス・アセット(製品、記事、イメージなど)で一意の場合、その属性はフレックス・アセットのツリーの最下位に属します。

- 属性値が複数のフレックス・アセットで同一の場合、その属性は親に属します。もちろん、常に例外があります。たとえば、トースタの費用がボーリングのボールと同額であっても、共通の親からその値段を継承しているとは思えません。

- その属性の配置に基づいて、必要なフレックス定義の数と親定義の数を指定できます。

個々のフレックス・アセットまたはフレックス親に使用できる、または使用する必要のある属性の数に関しては、物理的制限(DBMSに基づく)と心理的制限(ユーザーの満足度)の両方があることに注意してください。誰かがそのすべての値を入力する必要があります。必ず、実際に使用する予定がある属性のみを作成し、定義に割り当てます。追加の属性が必要な場合には、属性をさらに追加できます。

6.2.4.4 階層による属性の依存性

属性を使用する場所を確認したら、階層関係で属性に追加する要件があるかかどうかを確認します。たとえば、フレックス・アセットは複数の値を継承することがあるため、フレックス親で使用される属性は、フレックス・アセットに複数の親を追加できるデータ構造で複数の値を保持するように構成する必要があります。通常は、継承構造を複雑にしすぎないようにします。

6.2.5 作成する定義タイプの数

管理システムのデータの外観と入力は、フレックス・アセット定義とフレックス親定義に基づいています。親とフレックス・アセットは、定義によって作成する階層に基づいてツリーのタブに表示されます。

通常、最も望ましいのは、ファミリ内の各フレックス・アセット・メンバーに対して個々の定義タイプを作成することです。たとえば、avisportsサンプル・サイトでは、記事アセット・タイプとイメージ・アセット・タイプが同一の属性タイプを共有しますが、異なる親とフレックス定義を持ちます。記事アセットの定義には、記事に関連する属性のみが含まれますが、イメージ・アセットの定義には、イメージ・アセットに関連する属性のみが含まれます。記事アセットに適用されない属性とイメージ・アセットに適用されない属性があるため、同じ親および定義を共有する記事アセットとイメージ・アセットでは、一部の属性が両方のタイプのアセットで空白のままになります。

6.2.6 親定義とフレックス定義アセットの設計

WebCenter Sitesインタフェース内のツリーのタブの階層は、フレックス親定義とフレックス定義を介して作成されます。

- 階層を3レベルの深さに設定するには、少なくとも2つの親定義と少なくとも1つのフレックス定義が必要です。

- 階層を2レベルの深さに設定するには、少なくとも1つの親定義と少なくとも1つのフレックス定義が必要です。

構造的階層をフレックス定義とフレックス親定義を使用して設定する際には、必ず、ユーザビリティの基本的な原則を考慮してください。例:

- コンテンツ・プロバイダがツリーで所在位置が分からなくなるまでの階層の深さ。

- 入力中にユーザーのエラーの可能性を軽減するために継承できる属性値の数。

- ドロップダウン・リスト内に無理なく表示できるオプションの数。

コンテンツ・プロバイダは、複雑なシステムの使用を回避しようとします。データ構造をオンライン・サイトのフレックス・ファミリを使用して設計する際には、次のルールに注意してください。

- 慎重な計画に従った、使用しやすいアセット設計(データ設計)は、コンテンツ・プロバイダを満足させます。

- 使用可能なレイアウトと効率的なコードは、サイト訪問者を満足させます。

どちらのユーザー・グループも、適切に実行する効率的なシステムを必要としています。

6.2.6.1 階層の配置の指定

WebCenter Sitesにログインして、avisportsサンプル・サイトにアクセスし、新しいコンテンツの親定義または新しいコンテンツの定義に対するフォームを調べることができます。

これらのフォームの「親定義」セクションで、次の2つの項目を指定します。

- この定義を使用するアセットの階層での位置。

- 属性の継承元の親

階層位置が管理システムのOracle WebCenter Sites: Contributorインタフェース内のみを対象としていても、継承される属性は管理システムとオンライン・サイトの両方を対象としている点に注意してください。

「使用可能」テキスト・ボックスには、既存の親定義がすべて表示されます。フォームのこのセクションを使用して、可能な親数を指定します(「使用可能」リストから親定義を選択して、「選択済」リストに移動してください)。

アセットまたはフレックス・アセットを作成すると、親またはフレックス・アセットの定義を指定する定義フィールドが「新規」フォームに表示されます。親またはフレックス・アセットを作成する際に使用する定義を作成してある場合、選択できる定義は、「使用可能」リストから選択した定義によって決定されます。

注意:

デフォルトでは、作成している親またはフレックス・アセットに使用可能な定義がドロップダウン・リストに表示されます。ただし、親定義を作成する場合、ドロップダウン・リスト、先行入力フィールド、またはドロップ・ゾーン(ツリーから選択)フィールドのいずれに表示されるかを指定できます。

アセットは、「新規」フォームで選択した親の属性値(存在する場合)を継承します。「使用可能」リストから親定義を選択すると、その分、新しいフレックス・アセットを作成する際にコンテンツ・プロバイダが入力するフィールドが増えます。「使用可能」リストで親定義を選択しない場合、この定義で作成されたアセットが、フレックス・アセットを表示するタブのツリーで最上位に配置されるようになります。親定義、フレックス定義、親アセットおよびフレックス・アセットが相互作用する方法を理解するには、avisportsサンプル・サイトで配信されるアセットを調べてください。

6.2.6.2 属性継承の指定

親定義フォームの「属性」セクションで属性継承を構成できます。そのセクションを使用して、この定義で作成された親を定義する属性を指定します。この定義で親を作成すると、これらの属性に入力された値は親アセットの子のフレックス・アセットに渡されます。

6.2.6.3 フレックス親定義アセットの数

必要なフレックス親定義アセット数、およびそれらの定義の親アセット数を決定する際には必ずユーザビリティを考慮してください。新しい親およびフレックス・アセット・フォームの短いドロップダウン・リストの場合、各定義の親が少なくなるように、多くの親定義を作成します。しかし、少数の親定義と多数の親を含めるには、すべての親を表示するタブを作成して、コンテンツ・プロバイダがタブから正しい親を選択できるようにします。

6.2.6.4 フレックス定義アセットの数

「新規」フレックス・アセット・フォームと「編集」フレックス・アセット・フォームでフィールド(属性)空白のままにならないよう、十分な数のフレックス定義を作成します。作成する定義が少ないと、多くの属性フィールドを持つフォーム・サイズになり、一部が各アセットに適用されなくなります。多くの属性フィールドを持つ長いフォームがあると、現在作成中のアセットに適用する属性を決定するために、コンテンツ・プロバイダがフォームをソートする必要があるのみでなく、フォームがユーザーのブラウザでレンダリングされる時間が長くなります。

6.3 フレックス・ファミリ・メーカー・ユーティリティ

フレックス・ファミリ・メーカーを使用してフレックス・ファミリを作成すると、次の操作が実行されます。

- 複数のデータベース表を作成します(数は作成するフレックス・アセット・タイプに応じて異なります)。

- 新しいフレックス・ファミリの情報を次の表に書き込みます。

- FlexAssetTypes: 各フレックス・アセット・メンバー・タイプの行を保持します。

- FlexGrpTmplTypes: 各フレックス親定義タイプの行を保持します。

- FlexGrpTypes: 各フレックス親タイプの行を保持します。

- FlexTmplTypes: 各フレックス定義タイプの行を保持します。

- 次のネーミング規則を使用して、ElementCatalog表に新しいディレクトリを作成します。
OpenMarket/Xcelerate/AssetType/NameOfYourAssetType

- ElementCatalog表からのエレメントを、アセット・タイプに作成されたディレクトリにコピーします。WebCenter Sitesでは、これらのエレメントを使用して、該当するタイプのアセットの「新規」フォーム、「編集」フォーム、「調査」フォーム、「検索」フォームおよび「検索結果」フォームが書式設定されます。

フレックス・アセットおよびフレックス親アセットのメイン・データベース表の詳細は、「フレックス・ファミリとデータベース」を参照してください。

6.4 フレックス・アセット・エレメント

新しいアセット・タイプを作成すると、フレックス・ファミリ・メーカーによってエレメントがElementCatalog表の次の場所にコピーされます。

OpenMarket/Xcelerate/AssetType/NameOfAssetType

たとえば、avisportsサンプル・サイトの記事アセット・エレメントは次の場所にあります。

OpenMarket/Xcelerate/AssetType/AVIArticle

これは、検索エレメントが使用し、OpenMarket/Xcelerate/AssetType/NameOfAssetTypeのSystemSQL表に配置されるSQL文も作成します。

エレメントおよびフレックス・ファミリ・メーカーによってコピーされるSQL文は、「アセット・タイプに対応したエレメントとSQL文」を参照してください。フレックス・アセットのエレメントは、AppendSelectDetailsSEエレメントを除いてベーシック・アセット・エレメントと同じです。

6.5 開発システムの設定

フレックス・アセット・ファミリを作成する前に、次のように開発システムを設定してアクセスします。

1. 適切なWebCenter Sitesサイトを作成します。

2. 管理者権限を持つ独自のユーザー名を作成し、開発システムのすべてのサイトでそのユーザー名を有効にします。

管理者権限がないと、「一般的な管理」ツリーの「管理」ノードにアクセスできず、この章に記載した手順を実行できません。

3. ユーザー名にDesignerロールとGeneralAdminロールを割り当て、WebCenter Sites Adminインタフェース内のすべてのツリーと、サンプル・サイト内のアセットへのすべての既存のすべての「スタート・メニュー」ショートカットにアクセスできるようにします。

TableEditor ACLがユーザー名に割り当てられていることを確認してください。

詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

6.6 フレックス・アセット・ファミリの作成

オンライン・サイトのコンテンツを表現するフレックス・アセットのデータ・モデルを使用している場合、他の開発者はフレックス・アセット・タイプのみを作成しているのではありません。それらのタイプ(フレックス属性、フレックス親定義、フレックス定義およびフレックス親アセット)の個々のデータ構造のアセットも作成します。

注意:

この項のトピックは、新しいフレックス・アセット・ファミリの作成順に説明されます。フレックス・ファミリを初めて作成するには、トピックの説明順にこの手順に従います。

この項には次のトピックが含まれます:

- フレックス・ファミリの作成。

- (条件付き)追加のフレックス・ファミリ・メンバーの作成。

- (条件付き)フレックス・ファミリ・メンバーの構成。

- フレックス・アセット・タイプの有効化(開発システムのすべてのWebCenter Sitesサイトで有効化し、すべての新しいセット・タイプのスタート・メニュー・ショートカットを作成)。

- フレックス属性の作成(および属性エディタの設計)。属性エディタの詳細は、「属性エディタの設計」を参照してください。

- (条件付き)フレックス・フィルタ・アセットの作成(フレックス・フィルタの詳細は、「フレックス・フィルタの作成」を参照)。

- 親定義アセットの作成。

- フレックス定義アセットの作成。

- フレックス親アセットの作成。

- アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ) (「サムネイル」ビューで表示される検索結果リストにフレックス・ファミリのメンバーを表します)。

- フレックス・アセットのテンプレートのコーディング。

- 設計のテスト(テスト用フレックス・アセットの作成) (十分なフレックス・アセットを作成して、設計したデータ構造を調べます)。

- (条件付き)フレックス・アセットのアソシエーションの作成。

- 他のシステムへのアセット・タイプの移動。詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

6.6.1 フレックス・ファミリの作成

新規フレックス・ファミリを作成するには:

注意:

WebCenter Sitesでは、データベースの基礎となる大文字/小文字の区別に関係なく、フレックス・アセットの名前の大文字/小文字は区別されません。既存のアセットの名前で大文字/小文字が異なるフレックス・ファミリを作成すると、WebCenter Sitesによって、それ以外のフレックス・ファミリが既存のアセット・タイプに追加されます。たとえば、{Product_A, Product_PD, Product_CD, Product_P, Product_C}のフレックス・ファミリがすでに存在し、{PRODUCT_A, PRODUCT_PD, PRODUCT_CD, PRODUCT_P, myProduct_C}のフレックス・ファミリを作成しようとすると、WebCenter Sitesは、既存のアセット・タイプを使用して、{Product_A, Product_PD, Product_CD, Product_P, myProduct_C}のフレックス・ファミリを作成します。

1. 「一般的な管理」ツリーで「管理」ノードを選択します。

2. 「フレックス・ファミリ・メーカー」を開いて、「新規ファミリの追加」をクリックします。
「新規フレックス・ファミリの追加」フォームが開きます。

3. 「新規フレックス・ファミリの追加」フォームで、次のフィールドにフレックス・ファミリのメンバーの名前を入力します。

a. 「フレックス属性」フィールドに、新規フレックス属性のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規属性のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

注意:

3つの接尾辞が予約されています。フレックス属性には、末尾が_size、_typeまたは_fileの名前を使用できません。たとえば、broadformsizeは使用できるフレックス属性名ですが、broadform_sizeは使用できません。

b. 「フレックス親定義」フィールドに、新規フレックス親定義のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規親定義のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

c. 「フレックス定義」フィールドに、新規フレックス定義のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス定義のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

d. 「フレックス定義」フィールドに、新規フレックス親アセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規親のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

e. 「フレックス・アセット」フィールドに、新規フレックス・アセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス・アセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

f. 「フレックス・フィルタ」フィールドに、新規フレックス・フィルタのアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス・フィルタのアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

4. 「続行」をクリックします。
「新規フレックス・ファミリの追加」フォームが開きます(図6-1)。WebCenter Sitesによって、「説明」フィールドと「複数形」フィールドに自動的に移入されます。

図6-1 「新規フレックス・ファミリの追加」ダイアログ

5. 「新規フレックス・ファミリの追加」フォームで、次を実行します。

a. ファミリのメンバーごとに独自の値を「説明」フィールドに入力するには、アセット・タイプの外部名、つまりWebCenter Sitesに表示される際のアセット・タイプの名前を入力します。これは、フォーム(「新規」、「編集」、「調査」など)に表示される名前です。

b. ファミリのメンバーごとに独自の名前を「複数形」フィールドに入力するには、その名前の複数形を入力します。このバージョンは、必要に応じてステータス・メッセージなどで使用されます。

6. 「新規フレックス・ファミリの追加」をクリックします。
フレックス・ファミリ・メーカーにより、これらのタイプのアセットを格納するデータベース表が作成されます。これらの表の詳細は、「フレックス・ファミリとデータベース」を参照してください。

また、これらのタイプのアセットでフォームの書式を設定するエレメントが、ElementCatalog表とSystemSQL表のアセット・タイプの名前を持つディレクトリにコピーされます。

6.6.2 (条件付き)追加のフレックス・ファミリ・メンバーの作成

追加のフレックス・ファミリ・メンバーを作成する手順(複数のフレックス親アセット・タイプが必要な場合など):

1. 「一般的な管理」ツリーで、「管理」ノードを開き、作成したフレックス・ファミリを開きます。

2. 作成するフレックス・ファミリ・メンバーのタイプ(例: フレックス親)に到達するまで、フレックス・ファミリ・ツリーをドリルダウンします。

3. 作成するフレックス・ファミリ・メンバーのタイプで、新規メンバー・アセット・タイプの追加をダブルクリックします。

新規メンバー・アセット・タイプ・フォームが開きます(図6-2)。

図6-2 「フレックス・ファミリ・メーカー: 新規親定義アセット・タイプ」フォーム

4. フォームで、必要なフィールドに入力して「保存」をクリックします。

WebCenter Sitesに、アセット・タイプが作成されたことを確認するメッセージが表示されます。

5. 作成する追加のフレックス・ファミリ・メンバーごとに、この手順を繰り返します。

6.6.3 (条件付き)フレックス・ファミリ・メンバーの構成

フレックス・ファミリ・メーカーによって、新しいフレックス・ファミリが作成されると、新しいフレックスファミリを構成するためのアイコンおよび管理フォームも作成されます(「管理」タブに配置)。

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」アイコンを開きます。

2. 「アセット・タイプ」で、新しいフレックス・ファミリのアセット・タイプの1つを選択します。リストでフレックス・ファミリのアセット・タイプを確認するには、ナビゲーション・ペインを右クリックし、コンテキスト・メニューからすべてリフレッシュを選択して、新しいアセット・ファミリのアセット・タイプを選択します。

3. 「編集」をクリックします。
「アセット・タイプの編集」フォームが開きます。

4. 「アセット・タイプの編集」フォームで、次を実行します。

a. 「説明」フィールドで、必要に応じて値を変更します。このフィールドのテキストには、フォームのこのアセット・タイプに対してWebCenter Sitesで使用される名前とWebCenter Sitesインタフェースのリストが記述されています。デフォルトでは、「説明」は、そのアセット・タイプの「新規フレックス・ファミリの追加」フォームで指定した値に設定されます(「フレックス・ファミリの作成」を参照)。

b. 「複数形」フィールドで、必要に応じて値を変更します。このフィールドのテキストには、複数形でアセット・タイプを参照するのが適切な場合にWebCenter Sitesインタフェースで使用するテキストが記述されています。

c. 「子アセットに設定可能」フィールドで、必要に応じて値を変更します。アセット・タイプを別のアセットのアソシエーション・フィールドの子アセット・タイプにするには、値をTrueに設定します。

d. ディメンションを使用フィールドで、必要に応じて値を変更します。このアセット・タイプで多言語コンテンツの作成をサポートするには、値をTrueに設定します。

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

6. 構成するフレックス・ファミリ・メンバーごとに、手順1から5を繰り返します。

6.6.4 新規のフレックス・アセット・タイプの有効化

アセット(属性、フレックス親定義など)の作成を開始する前に、「管理」タブで必要な手順を完了しておく必要があります。ログインでは、「管理」タブにアクセスするための管理者権限を付与する必要があります。

新規のフレックス・アセット・タイプを有効化するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「サイト」アイコンをクリックして次の手順を完了します。

a. これらのアセット・タイプで作業するのに使用するサイトを開きます。

b. そのサイトで、「アセット・タイプ」→「有効化」を選択します。

c. リストから新しいアセット・タイプを選択して、「アセット・タイプの有効化」をクリックします。
WebCenter Sitesでは、新規スタート・メニュー・アイテムまたは有効にしたアセット・タイプでスタート・メニューの項目の検索が自動的に作成されます。

d. 図6-3に示すように、WebCenter Sitesに作成する、任意のスタート・メニューの項目の隣にあるオプションを有効にします。

図6-3 スタート・メニューの選択ダイアログ

これらのメニュー・アイテムをここで生成するか、または、サイト管理者がそれらを後から手動で作成する必要があります(有効化されたアセット・タイプに対してスタート・メニュー・アイテムが作成されるまでは、そのアセット・タイプのアセットを作成できません)。

2. 「アセット・タイプの有効化」をクリックします。

3. これでアセット・タイプはサイトに対して有効になります。スタート・メニュー・アイテムを生成する際にWebCenter Sitesを使用しなかった場合には、この時点では手動で作成する必要があります。アセット・タイプの開発者およびオンライン・サイトのデザイナには、管理者が意味のあるスタート・メニュー・アイテムを構成できるように、アセットとサイト設計について十分な情報を知らせる責任があります。

開発者は、サイト管理者とシステム管理者がコンテンツ・プロバイダに対して意味のあるスタート・メニュー・アイテムを作成できるように、オンライン・サイトに対する問合せ、コレクション、その他のデザイン・エレメントで使用するフィールドについて知らせる必要があります。スタート・メニュー・アイテムの作成の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

4. これらのアセット・タイプを有効にするサイトごとに、手順1から3を繰り返します。

開発者または管理者が新規アセット・タイプにスタート・メニュー・アイテムを作成した後は、それらのタイプのアセットを作成できるようになります。

注意:

アセット・タイプをツリーのタブに追加している可能性があります。ただし、これらのタイプのアセットを作成するには、それらのスタート・メニュー・ショートカットを作成する必要があります。

6.6.5 フレックス属性の作成

手順は、属性に対して選択したデータ型に応じて大きく異なる場合があります。したがって、この項では複数の手順について示します。

- フレックス属性の作成: 基本的な手順

- タイプBlobのフレックス属性(アップロード・フィールド)の作成

- タイプAssetのフレックス属性の作成

- 外部フレックス属性の作成

6.6.5.1 フレックス属性の作成: 基本的な手順

この例では、フレックス属性の作成の基本的な手順について示します。

1. メニュー・バーで、「新規」をクリックして、ショートカットのリストから属性タイプの名前を選択します。たとえば、「新規製品属性」を選択したとします。このアセットに関連付けられているワークフローの割当て先を選択できるようにするには、各ロールから少なくとも1人のユーザーを選択して「割当て先の設定」をクリックします。

製品属性フォームが開きます(図6-4)。

図6-4 製品属性フォーム

2. 「新規」フォームでは、次のフィールドに入力します。

a. 「名前」フィールドで、最大64文字(空白は除く)の名前を入力します。

b. 「説明」フィールドで、この属性の使用や機能について簡潔に記述します。

c. 「値タイプ」フィールドで、この属性に対してデータ型を選択します。

- blobを選択した場合、「タイプBlobのフレックス属性(アップロード・フィールド)の作成」を参照して、手順3から開始します。

- assetを選択した場合、「タイプAssetのフレックス属性の作成」を参照してください。

- 外部属性を作成する場合、assetまたはblob以外の値を選択し、手順dを実行して、「外部フレックス属性の作成」の手順3を続行します。

- textを選択した場合、Adminインタフェースはtext以外のすべてのタイプの属性値の検索に対応します。属性値の検索実行の情報は、『Oracle WebCenter Sitesの使用』を参照してください。

属性の適切なデータ型の決定の詳細は、「属性のデータ型」を参照してください。

d. 「値の数」フィールドで、必要に応じて「値タイプ」フィールドで選択したデータ型に対して、「単一」または「複数」のいずれかをドロップダウン・リストから選択します。

この属性をフレックス親で使用可能にするには(データ構造がフレックス・アセットに複数のフレックス親を許可する場合)、この属性の値を継承するフレックス・アセットが複数の親から値を継承するため、「複数」を選択する必要があります。

注意:

属性が複数の値を受け入れるように構成されている場合、その属性はフレックス親フォームとフレックス・アセット・フォームに別の属性名を追加ボタンが備わったフィールドとして表示されます。継承の理由から属性が複数の値を受け入れるが、コンテンツ・プロバイダが個々の親またはフレックス・アセットに対して属性の値を複数選択しないようにするには、その属性を単一値のフィールドとして表示する属性エディタをその属性に割り当てます(「値タイプ」フィールドで複数選択)。

WebCenter Sitesでは、textタイプの属性のデータベースへの格納方法の制限により、これらの属性が複数の値を持つことは許可されていません。そのような方法で構成した属性を保存しようとすると、この制限を意味するメッセージが表示されます。

e. この属性にデフォルト・タイプ以外の入力タイプ(「値タイプ」フィールドで選択したデータ型に基づいている)を使用するには、「属性エディタ」フィールドで、ドロップダウン・リストから属性エディタを1つ選択します。

注意:

CHECKBOXES属性エディタを選択する場合は、「値の数」フィールドが「複数」に設定されていることを確認します。

詳細は、次の情報を参照してください。

- デフォルト入力タイプ(かわりに属性エディタを使用するかどうかを指定できる)は、「属性のデフォルトの入力スタイル」を参照してください。

- 属性エディタの作成は、「属性エディタの設計」を参照してください。

- 該当する属性のデータ型に適切な属性エディタは、「属性エディタ・アセット」を参照してください。

f. デフォルトISO文字セット(ISO 8859-1)をオーバーライドするには、ISO文字セット・フィールドで、該当する属性に使用する文字セットを入力します。

3. 「保存」をクリックします。

6.6.5.2 タイプBlobのフレックス属性(アップロード・フィールド)の作成

この例では、タイプBlobのフレックス属性の作成方法を示します。

1. 「フレックス属性の作成: 基本的な手順」の手順1から2cを実行します。

2. 「値タイプ」フィールドで、blobを選択します。

3. (オプション)「フォルダ」フィールドで、属性値を格納するディレクトリへのパスを入力します。このフィールドに入力する値は、MungoBlobs表に対するデフォルトの記憶域ディレクトリ(defdir)として値セットに追加されます。

4. 「値の数」フィールドで、必要に応じて「単一」または「複数」を選択します。このフィールドの詳細は、「フレックス属性の作成: 基本的な手順」を参照してください。

5. デフォルトの入力タイプ(「参照」ボタン)を使用しない場合、「属性エディタ」フィールドで、次のうちのいずれかを選択します。

- TEXTAREA入力スタイルを指定する属性エディタ。属性エディタの詳細は、「属性エディタ・アセット」を参照してください。

- システムがCKEditorを使用するように構成されている場合には、CKEDITOR入力スタイルを指定する属性エディタ。

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

6.6.5.3 タイプAssetのフレックス属性の作成

タイプassetの属性を作成するには:

1. 「フレックス属性の作成: 基本的な手順」の手順1から22.bを実行します。

2. 「値タイプ」フィールドで、assetを選択します。

3. 「アセット・タイプ」フィールドで、ドロップダウン・リストからオプションを選択します。

4. 「依存性タイプのミラーリング」フィールドで、依存性タイプを選択します。

5. 「値の数」フィールドで、必要に応じて「値タイプ」フィールドで選択したデータ型に対して、「単一」または「複数」のいずれかをドロップダウン・リストから選択します。

この属性がフレックス親で使用され、データ構造がフレックス・アセットに複数のフレックス親を許可する場合、この属性の値を継承するフレックス・アセットが複数の親から値を継承するため、「複数」を選択する必要があります。

6. 「値の数」フィールドで選択したタイプのアセットの数が20を超えた場合、「属性エディタ」フィールドで1つ選択します。適切な属性エディタの詳細は、「属性エディタの使用について」を参照してください。

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

6.6.5.4 外部フレックス属性の作成

フレックス・アセットでも使用する別のシステム内のデータ(価格リストなど)を保持するには、フレックス属性として使用するデータの外部表の列を指す外部属性を作成します。

外部属性を作成するには:

1. フレックス属性として使用するデータが格納された外部表を登録します。

2. 「フレックス属性の作成: 基本的な手順」の手順1から2dを実行します。

注意:

「値タイプ」フィールドでは、assetもblobも選択できません。

3. WebCenter Sitesのフレックス・アセット・フォームを使用して外部表に属性値を入力する場合、「値タイプ」フィールドで選択したデータ型のデフォルト入力タイプを使用しないときは、「属性エディタ」フィールドで、適切な属性エディタを選択します。

4. 「編集スタイル」フィールドで、次のいずれかを実行します。

- WebCenter Sitesフォームを使用して、属性を使用するフレックス・アセットのこの属性のフィールドに値を入力するには、「ローカル」を選択します。

- ユーザーがWebCenter Sitesフォームでこの表に値を書き込めないようにするには、「外部」を選択します。

5. 「ストレージ・スタイル」フィールドで、ドロップダウン・リストから「外部」を選択します。

6. 「外部ID」フィールドで、この外部属性を保持する表の主キーとして処理する列、つまり属性を一意で識別する列の名前を指定します。

7. 「外部表」フィールドで、この属性が格納されている表名を記入します。

8. 「外部列」フィールドで、該当する属性の値を保持する「外部表」で指定された表の列名を入力します。

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

6.6.6 (条件付き)フレックス・フィルタ・アセットの作成

機能がいずれかのデフォルトWebCenter Sitesフィルタ・クラスで定義されているフレックス・フィルタ・アセットを作成します。

フレックス・フィルタ・アセットの作成前に、入力および出力の属性として使用するフレックス属性を作成しておく必要があります。適切なフレックス属性が存在しない場合には作成します。次の要件に注意してください。

- フレックス・フィルタがDocument Transformationフィルタ・タイプを使用している場合、入力と出力の属性はタイプblobである必要があります。

- どのフレックス・フィルタでも、入力属性、出力属性およびフレックス・フィルタ・アセットはすべて同一のフレックス・ファミリに属している必要があります。

フレックス・フィルタ・クラスの情報と、フレックス・フィルタ・アセットの作成手順の詳細は、「フレックス・フィルタの作成」を参照してください。

フレックス・フィルタ・アセットを作成するには::

1. メニュー・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、作成するフィルタのタイプを選択します。たとえば、「新規メディア・フィルタ」を選択したとします。このアセットに関連付けられているワークフローの割当て先を選択できるようにするには、各ロールから少なくとも1人のユーザーを選択して「割当て先の設定」をクリックします。

メディア・フィルタ・フォームが開きます(図6-5)。

図6-5 メディア・フィルタ・ダイアログ

3. 「新規」フォームで、次を実行します。

- 「名前」フィールドに、このフィルタ・アセットの一意の名前を入力します。

- 「説明」フィールドに、フィルタの機能を要約した短い説明を入力します。

- フィルタフィールドで、作成するフレックス・フィルタ・アセットの機能を定義するフィルタ・クラスを選択します。デフォルトでは、フィルタのオプションはDoc-Type、ドキュメント変換、フィールド・コピアーおよびサムネイル・クリエータです。

注意:

このリストには、システムに作成されている可能性のあるカスタム・フィルタが表示されます。カスタム・フレックス・フィルタ・クラスの作成の詳細は、「フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成」を参照してください。

- 「引数の取得」をクリックします。「引数」フィールドで、フレックス・フィルタ・アセットに対する入力および出力の引数を指定します。「追加」をクリックして、フィルタに引数を追加します。

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

6.6.7 親定義アセットの作成

親定義アセットを作成する手順:

1. メニュー・バーで、「新規」をクリックします。

2. 製品の定義アセットの名前をショートカットのリストから選択します。たとえば、「新規製品の親定義」を選択したとします。このアセットに関連付けられているワークフローの割当て先を選択できるようにするには、各ロールから少なくとも1人のユーザーを選択して「割当て先の設定」をクリックします。
製品親定義フォームが開きます(図6-6)。

図6-6 製品親定義ダイアログ

3. 製品親属性フォームで、次のようにフィールドに入力します。

a. 名前では、最大64文字の名前を入力します。

b. 「説明」では、親定義を説明する簡単なフレーズを入力します。

c. 「親選択スタイル」では、該当する定義を使用するフレックス親が親アセット・フォームで選択される方法を指定します。次のいずれかの操作を行います。

- 該当するタイプの親数が少ない場合には、「選択ボックス」を選択します。それにより、このタイプのすべての親がフレックス・アセット・フォームのドロップダウン・リストにオプションとして表示されます。

- 該当するタイプの親数が多い場合には、「ツリーからの選択」を選択します。そのうえで、フレックス・アセット・フォームでこのタイプの親を選択する場合は、カタログ・データが表示されたタブのツリーから選択します。

d. 製品親定義セクションで、親定義を「使用可能」リストから選択し、表6-1に説明するボタンの1つをクリックします。

表6-1 親定義フォームのボタン

親定義フォームのボタン

新規親フォームで次の操作を実行するフィールドの作成

単一値: 必須

フィールドに対して1つの親を強制的に選択します。

単一値: オプション

フィールドに対して親を1つのみ選択できます。

複数値: 必須

フィールドに対して少なくとも1つの親アセットを強制的に選択します。

複数値: オプション

フィールドに対して複数の親アセットを選択できます。

WebCenter Sitesによって、親定義が「使用可能」リストから「選択済」リストに移動されます。親定義の選択の詳細は、「階層の配置の指定」を参照してください。

e. 必要な回数だけ、手順3.dを繰り返します。対応する「新規」親フォームには、その親の定義フォームの「使用可能」リストで選択する各アイテムのフィールドが追加されます。

f. 「属性」セクションで、適切な属性を「使用可能」リストから選択し、次のいずれかを実行します。

- 「必須」をクリックして、その属性が必須であることを指定します(つまり、該当する定義で作成されたすべてのフレックス親にはその属性の値が存在する必要があります)。

- 「オプション」をクリックして、その属性がオプションであることを指定します。

注意:

フレックス・フィルタ・アセットを将来この親定義に割り当てるには、そのフレックス・フィルタで使用される入力と出力の属性を追加する必要があります。

該当するタイプの親の親フォームに表示する順番で属性を並べ替えるには、「選択済」ボックスの右側の「表示の順序」矢印を使用します。

g. 「フィルタ」セクションで、この親定義に適切な任意のフレックス・フィルタ・アセットを選択します。

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

5. この手順を、作成する必要のある親定義アセットごとに繰り返します。

6.6.8 フレックス定義アセットの作成

フレックス定義アセットを作成する手順:

1. メニュー・バーで、「新規」をクリックします。

2. フレックス定義アセット・タイプの名前をショートカットのリストから選択します。たとえば、「新規製品の定義」を選択したとします。このアセットに関連付けられているワークフローの割当て先を選択できるようにするには、各ロールから少なくとも1人のユーザーを選択して「割当て先の設定」をクリックします。
親定義フォームが開きます。

3. 親定義フォームで、次のようにフィールドに入力します。

a. 「名前」フィールドに、最大64文字の名前を入力します。

b. 「説明」フィールドで、親定義を説明する簡単なフレーズを入力します。

c. 製品親定義セクションで、親定義を「使用可能」リストから選択し、表6-2に説明するボタンの1つをクリックします。

表6-2 フレックス定義フォームのボタン

フレックス定義フォームのボタン

新規フレックス・アセット・フォームで次の操作を実行するフィールドの作成

単一値: 必須

フィールドで親を1つのみ強制的に選択します。

単一値: オプション

フィールドで親を1つのみ選択できます。

複数値: 必須

フィールドで少なくとも1つの親アセットを強制的に選択します。

複数値: オプション

フィールドに対して複数の親アセットを選択できます。

WebCenter Sitesによって、親定義が「使用可能」リストから「選択済」リストに移動されます。親定義の選択の詳細は、「階層の配置の指定」を参照してください。

d. 必要に応じて、前述の手順を繰り返します。対応する新規フレックス・アセット・フォームには、そのフレックス定義フォームの「使用可能」リストで選択する各アイテムのフィールドが追加されます。

e. 「属性」セクションで、属性を「使用可能」リストから選択し、次のいずれかを実行します。

- 「必須」をクリックして、その属性が必要であることを指定します(つまり、該当する定義で作成されたすべてのフレックス・アセットにはその属性の値が存在する必要があります)。

- 「オプション」をクリックして、その属性がオプションであることを指定します。

注意:

フレックス・フィルタ・アセットを将来このフレックス定義に割り当てるには、そのフレックス・フィルタで使用される入力と出力の属性を追加する必要があります。

フレックス・アセットの「新規」フォームおよび「編集」フォームに表示する順番で属性を並べ替えるには、「選択済」ボックスの右側の「表示の順序」矢印を使用します。

f. 「フィルタ」セクションで、このフレックス定義に適切な任意のフレックス・フィルタ・アセットを選択します。

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

5. この手順を、作成する必要のあるフレックス定義ごとに繰り返します。

6.6.9 フレックス親アセットの作成

フレックス親アセットを作成するには:

1. WebCenter Sitesに管理者としてログインし、Contributorインタフェースを選択します。

2. メニュー・バーで、「コンテンツ」→「新規」を選択し、作成するフレックス親アセットのタイプを選択します。
作成するフレックス親アセットの「作成」ビューを表示したタブが開きます(図6-7)。

図6-7 製品親ダイアログ

3. 製品親フォームで、次のようにフィールドに入力します。

a. 「名前」フィールドに、最大64文字の名前を入力します。

b. 製品親フィールドで、親定義をドロップダウン・リストから選択します。選択する定義により、フォームの次のセクション(この親アセットを定義する際に入力するセクション)の書式が設定されます。

c. 「続行」をクリックします。

フォームの「コンテンツ」セクションが開きます(図6-8)。

図6-8 「コンテンツ」セクション

4. フォームの「コンテンツ」セクションで、次の点に注意してフィールドに入力します。

- フィールドの隣のアスタリスク(*)は、そのフィールドが必須であることを示しています。

- この例では、親アセットを指定するフィールドはFSIIProductTopLevelと呼ばれます。このフィールドにドラッグ・アンド・ドロップした親は、この手順で作成中の親の子として指定するフレックス・アセットの祖父母になります。このフィールドが必須ではなく、親(祖父母)を選択しない場合、作成中の親が「コンテンツ」ツリーのトップレベルの親になります。

- フィールドを単一値または複数値のいずれにするかを決めるには、フィールドに関連付けられたドロップ・ゾーンを指します。このフィールドが受け入れるタイプを示したツールチップが、フィールドを単一値または複数値のいずれに指定するかに関する情報とともに表示されます。

5. フォーム・セクション・セレクタを使用して、フォームの次のセクションに切り替えます(「マーケティング」セクションと「メタデータ」セクション)。フィールドの隣のアスタリスク(*)は、必須のフィールドであることを示しています。
これらのセクションに表示されたフィールドは、この親に選択した親定義に基づいています。これらのフィールドに入力する値は、この親アセットを親として持っているすべてのフレックス・アセットによって継承されます。

6. アセットのツールバーで、「保存」アイコンをクリックします。
WebCenter Sitesでは、新しい親がデータベースに書き込まれます。属性値以外のすべての情報が、FlexParent、FlexParent _AMapおよびFlexParent_Extension表に書き込まれます(ここで、FlexParentは、フレックス親の内部名を表します)。属性値は、FlexParent _Mungo表に書き込まれます。

6.6.10 アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)

ユーザーがContributorインタフェースで検索を実行し、「サムネイル」ビューに検索結果が表示されると、検索結果リストの各アセットはサムネイル・イメージで表されます。デフォルトでは、検索結果リストのアセットの名前、アセット・タイプ、変更日およびロケールが、アセットまたはアセットのタイプを表すサムネイル・イメージの下に表示されます。イメージは、アセットごとまたはアセット・タイプごとに割り当てることができます。このセクションでは、各アセット・タイプへのサムネイル・イメージの割当てについて重点的に説明します。

新規フレックス・ファミリのメンバーを一意に識別するイメージを作成して割り当てる必要があります。

1. 各フレックス・ファミリ・メンバーに対して、次の操作を実行します。

a. タイプがJPGの2つのイメージ・ファイルを作成します。1つはドッキングされた検索結果リストに表示され、もう1つはドッキングされていない検索結果リストに表示されます。ドッキングされた検索結果リストに表示されるイメージの標準サイズは、96x96ピクセルです。ドッキングされていない検索結果リストに表示されるイメージの標準サイズは、170x170ピクセルです。

b. イメージ・ファイルは、次のとおり名前を付けます。

- ドッキングされた検索結果リストのアセット・タイプに表示されるイメージの名前を付けるには、構文assetType.jpgを使用します。

- ドッキングされていない検索結果リストのアセット・タイプに表示されるイメージの名前を付けるには、構文assetType_large.jpgを使用します。

注意:

イメージをJPGとして保存する必要があります。ファイル名は、アイコンが表示されるアセット・タイプを決定します。名前は大/小文字が区別されます。

c. イメージ・ファイルを適切なディレクトリに配置します。
<cs_app_dir>/images/search

ここで、<cs_app_dir>はアプリケーション・サーバーのデプロイ済WebCenter Sitesアプリケーションのディレクトリです。

2. アプリケーション・サーバーを再起動します(Contributorインタフェースの検索結果リストの「サムネイル」ビューにアイコンが表示されます)。

6.6.11 フレックス・アセットのテンプレートのコーディング

フレックス・アセット定義の作成、およびこれらの定義を使用するフレックス・アセットのテンプレートのコード化は、反復作業となります。フレックス・アセットにテンプレートを作成する前に、定義とフレックス・アセットを作成する必要がありますが、データ設計の微調整の必要がある領域は、テンプレートをコード化してコードをテストした後にのみ明らかになる可能性が高いようです。

テンプレートのエレメントのコード化については、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」および「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

6.6.12 設計のテスト(テスト用フレックス・アセットの作成)

設計を十分テストするには、フレックス・アセットがツリー上で表示される場所、フォームの外観、フォームへのロード時間などを調査できるようにする必要があります。フレックス・アセットをいくつか作成して調査します。

アセットの作成の詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

6.6.13 (条件付き)フレックス・アセットのアソシエーションの作成

ほとんどの場合、フレックス・アセットの属性を使用してアソシエーションを形成する必要があります。アソシエーションをフレックス定義間で稼働する必要があることがまれにあり、その場合には、フレックス・アセット間のアソシエーションを作成します。

アソシエーションを作成する手順:

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「アセット・タイプ」ノードを開きます。

2. アソシエーションを作成するアセット・タイプのノードを開きます。

3. 「アセットのアソシエーション」のノードを開きます。

4. 「新規追加」をクリックします。

「新規アソシエーションの追加」フォームが開きます(図6-9)。

図6-9 「新規アソシエーションの追加」ダイアログ

5. 「新規アソシエーションの追加」フォームで、次のようにフィールドに入力します。

- 「名前」フィールドに、アソシエーションの名前を入力します。

- 「説明」フィールドに、アソシエーションの説明を入力します。

- 「子アセット」フィールドで、このアセットに関連付ける子アセットを選択します。

- 「サブタイプ」フィールドで、このアソシエーションのサブタイプを複数選択します。

- 「依存性タイプのミラーリング」フィールドで、関連付けられているフレックス・アセットの依存性タイプを選択します。

- 「アソシエーションのタイプ」フィールドで、次のいずれかを選択します。

- 単一値 - アセットごとに1つの値のみ可能です。

- 複数値 - アセットごとに複数の値が可能です。

6. 「新規アソシエーションの追加」をクリックし、フレックス・アセット・タイプを関連付けます。

6.6.14 他のシステムへのアセット・タイプの移動

フレックス・ファミリの作成、データ構造アセット(属性エディタを含む)の作成、およびフレックス・アセット・タイプのテンプレートのコーディングが終了すると、システム管理者は管理システムのアセット・タイプを構成できます。これにより、必要に応じてリビジョン追跡の有効化、ワークフロー・プロセスの作成、スタート・メニューのショートカットの作成などが可能になります。

フレックス・ファミリ、データ構造アセット、およびコーディング・テンプレートを管理システムと配信システムに移動して、システム管理者が構成できるようにします。アセット・タイプの管理システムおよび配信システムへの移動の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

6.7 フレックス属性、親および定義の編集に関する必知事項

フレックス・アセット・タイプの編集には、通常、慎重な計画が必要です。特定の編集でスキーマの変更が生じ、スキーマの変更がデータ消失の原因となるためです。この項では、フレックス・ファミリのアセット・タイプの編集に関するヒントとアドバイスを述べます。

この項には次のトピックが含まれます:

- 属性の編集に関する必知事項

- 親定義とフレックス定義の編集に関する必知事項

- 親およびフレックス・アセットの編集に関する必知事項

6.7.1 属性の編集に関する必知事項

フレックス属性の編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをWebCenter Sitesデータベースにインポートするには、XMLPostファイルを編集する必要があります(属性名を変更する場合)。

- データ消失を発生せずに、「説明」を変更できます。

- 「値タイプ」フィールドでデータ型を変更すると、この属性タイプを使用する_Mungo表の属性に関連付けられたすべてのデータが消失します。

- 属性のデータ型がassetの場合、そのアセット・タイプを変更すると、その属性に対するすべての既存データが無効になります。

- blob属性の「フォルダ」フィールドを変更すると、WebCenter Sitesではその属性の既存データを検索できなくなります。この値を変更する必要がある場合は、設定した新しい値に一致させるためにファイル・システムを移動します。

- データ消失や困難な事態を発生せずに、「値の数」を単一から複数に変更できます。

- 「値の数」を「複数」から「単一」に変更すると、既存の行のどの値が保持すべき値であるかをWebCenter Sitesで指定できなくなります。

- 「検索エンジン」とISO文字セットは、データ消失を発生せずに変更できます。

6.7.2 親定義とフレックス定義の編集に関する必知事項

親定義またはフレックス定義の編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをWebCenter Sitesデータベースにインポートするには、XMLPostファイルを編集する必要があります(親定義の名前を変更する場合)。

- 「説明」フィールドと「親選択スタイル」フィールドは、データ消失を発生せずに変更できます。

- 親の選択肢を変更する場合:

- 親の追加は許可されます。

- 親の削除は、アセットが有効なデータを消失させる原因となることがあります。

- 親をオプションから必須に変更すると、新しく必須となった親のいずれかが存在しない親またはフレックス・アセットが有効でなくなるため、問題を発生する可能性があります。

- 親の必須からオプションへの変更は許可されます。

- 親の単一力複数値への変更は許可されます。

- 親を複数値から単一値に変更すると、以前に受け入れられていた複数値を保持するか削除するかをWebCenter Sitesで決定できなくなるため、予測できない結果が発生します。

- 属性の選択内容を変更する場合:

- オプションの属性の追加は許可されます。

- 必須の属性を追加すると、その属性を保持しない既存の親やフレックス・アセットを無効にします。

- 属性を削除すると、削除された属性の属性値を持つ既存の親やフレックス・アセットを無効にします。

6.7.3 親およびフレックス・アセットの編集に関する必知事項

フレックスまたは親アセットの編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをWebCenter Sitesデータベースにインポートするには、XMLPostファイルを編集する必要があります(親定義の名前を変更する場合)。

- データ消失を発生せずに、「説明」を変更できます。

- 親を変更すると、継承された属性値すべてがWebCenter Sitesによって修正されます。

- 親またはフレックス・アセットを作成する際に使用した定義を変更できません。

- 属性値の変更は許可されます。親の属性値を変更すると、該当する親から属性値を継承するすべてのアセットの属性がWebCenter Sitesによって修正されます。フレックス・アセットの属性値の変更は許可されます。

6.8 製品セットの使用

WebCenter Sitesを使用してオンライン・カタログを管理すると、製品セットという製品アセットで使用できる特殊な機能があります。製品セットを使用すると、別々に梱包され販売されるものを除いて、実際には同じ製品になる製品をグループ化できます。

この項には次のトピックが含まれます:

- 製品セットの使用について

- 製品セットの作成

6.8.1 製品セットの使用について

本はペーパーバック版でもハードカバー版でも同じ本です。ソフト・ドリンクは、個別の缶、6パック、2リットルのボトル、またはケースのいずれで販売されても同じソフト・ドリンクです。製品セットでは、このように製品をまとめてグループ化できるため、管理システムで一緒に(同一のフォームに)表示でき、個々の販売単位のままSKU(最小在庫管理単位)などで識別されます。

販売セット機能のモデルは、次のとおりです。

- 製品セットは、製品アセットの特性を帯びる製品の親です。製品セット(親)には、コア製品を定義するすべての属性が備わっています。

- 製品セットは最小在庫管理単位です。つまり、製品セットにはパッケージを説明する属性、またはセットのメンバーの一意の識別子(SKU、ボトル・サイズなど)のみが含まれます。

- 製品セット(親)には、製品セットとマークする属性があり、この属性の値はすべての製品セットで一意です。この属性はGAProductSetと呼ばれ、予約ネームとなります。セット内の製品はこの属性を継承し、この継承により、その製品セットのメンバー(その製品の親の子)としてマークされます。

6.8.2 製品セットの作成

製品セットを作成するには:

1. GAProductSetと名付けられた製品の属性を作成します。これは予約ネームであり、属性名はそれに完全に一致している必要があります。

2. 新しい製品の親定義を作成し、GAProductSet属性を選択します。

3. 新しい製品の定義を作成し、手順2で作成した定義を使用して作成された親がこの製品定義で作成された製品の親になることができるように指定します。

4. 手順2で作成した定義から新しい製品の親を作成します。

5. 手順3で作成した製品の定義を使用し、セットの製品を作成して手順4で作成した親がそれらの製品の親になるよう指定します。

ここで、製品セット(製品の親)を調査または編集すると、セット内の各製品(SKU)は製品セットの関係を表して、「製品の親」フォームにリストされます。

WebCenter Sitesデータベースに存在できるのは、1つのGAProductSet属性のみです。複数のWebCenter Sitesサイトで製品セットを作成するには、GAProductSet属性を使用するサイトに対してその属性を共有する必要があります。

7 階層的なフレックス・ファミリの作成

この章では、値が1つの定義に基づいた3つのレベルによる単純な階層である、フレックス・ファミリの作成方法について説明します(また、ここでは当面、属性とそれを継承したものは無視します)。この章を完了すると、フレックス・アセット・モデルについて、またWebCenter Sitesで階層的なコンテンツを作成するためにフレックス・アセット・モデルをどのように使用するかについて、基本的なことが理解できるようになります。同様の階層の作成元となるモデルも得られます。

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

- 階層組織

- フレックス・ファミリの仕様

- 現実世界の例を使用したサンプルのフレックス・ファミリの作成

「階層組織」および「フレックス・ファミリの仕様」では、作成するフレックス・ファミリについて説明します。「現実世界の例を使用したサンプルのフレックス・ファミリの作成」はチュートリアルで、ここでは、そのファミリ・メンバーの総称名で小さなフレックス・ファミリを作成します。

7.1 階層組織

このチュートリアルで作成するフレックス・ファミリは、次の3つのレベルで構成されています。

- 最上位レベルの親(ここに示す例ではParent 1 [Level 1])。

- 2番目のレベルの親(ここに示す例ではParent 2 [Level 2])。

- 3番目のレベルのアセット。あるアセットは、そのレベル1の親の直下に配置され、別のアセットは、そのレベル2の親の直下に配置され、3番目のアセットは、レベル1とレベル2両方の親の下に配置されます。

WebCenter Sitesインタフェースでは、階層は図7-1の左側に示したとおりになります。そこに表されているのは定型的なものです。この図の右側は、それが、avisportsサンプル・サイトで表される現実世界のモデルにどのように変換されるかを示しています。

図7-1 定型的なデータ・モデルと現実世界のデータ・モデル

サンプル・サイトでは(図7-1の右側):

- Parent 1 [Level 1]には、Outdoor Sports Equipmentという名前が付けられています。

- Parent 2 [Level 2]には、Mountain Climbingという名前が付けられており、これはOutdoor Sports Equipmentのサブタイプです。

- Asset 1には、Our Awesome Catalogという名前が付けられています。これはタイプOutdoor Sports Equipmentのアセットです。

- Asset_12には、Special Offersという名前が付けられています。Outdoor Sports EquipmentとMountain Climbingの、両方の下に表示されます。

7.2 フレックス・ファミリの仕様

表7-1には、作成するフレックス・ファミリのメンバーが一覧表示されています。

表7-1 フレックス・ファミリのメンバー

フレックス・ファミリのメンバー

名前

インスタンス

親定義がベース

フレックス定義がベース

フレックス属性タイプ

My Attribute

Attribute_1[1]

Attribute_2

なし

なし

フレックス親定義タイプ

My Parent Definition

Level 1 Def

Level 2 Def

なし

Level 1 Def

なし

フレックス定義タイプ

My Flex Definition

Flex Def 1

Flex Def 2

Flex Def_12

Level 1 Def

Level 2 Def

Level 1 DefおよびLevel 2 Def

なし

フレックス親タイプ

My Parent

Parent 1 [Level 1]

Parent 2 [Level 2]

Level 1 Def

Level 2 Def

なし

フレックス・アセット・タイプ

My Asset

Asset 1

Asset 2

Asset_12

なし

Flex Def 1

Flex Def 1

Flex Def_12

フレックス・フィルタ・タイプ

なし

なし

なし

なし

7.3 現実世界の例を使用したサンプルのフレックス・ファミリの作成

このチュートリアルでは、小さなフレックス・ファミリを作成し、そのファミリ・メンバーに汎用的な名前を付けます。このアプローチでは、階層構築の公式を視覚化しやすくなります。

このチュートリアルの終了時には、定型的なデータ・モデルがビジネス関連のデータ・モデルにどのように変換されるかを理解するために、選択したファミリ・メンバーの名前を現実世界の名前に変更します。また、さらに多くの親とアセットを階層に追加し、作成する際に現実世界の名前を付けます。

この項には次のトピックが含まれます:

- フレックス・ファミリの作成

- 新規のフレックス・アセット・タイプの有効化

- フレックス・ファミリ・タブのWebCenter Sitesのツリーへの追加

- 親定義アセットの作成

- フレックス親アセットの作成

- フレックス定義アセットの作成

- フレックス・アセットの作成

- 現実世界のデータ・モデルへの定型データ・モデルの変換

- 現実世界のモデルの開発

7.3.1 フレックス・ファミリの作成

この手順では、フレックス・ファミリを作成し、その必須メンバーに名前を付けます。

フレックス・ファミリを作成するには::

1. Adminインタフェースを起動します。

2. 「一般的な管理」ツリーで、「管理」ノードを開き、「フレックス・ファミリ・メーカー」を開いてから、「新規ファミリの追加」をダブルクリックします。

3. 「フレックス・ファミリ・メーカー」フォームのフィールドに、表7-2に示すように正確に入力します。

表7-2 「フレックス・ファミリ・メーカー」フォーム

フィールド名

入力値

コメント

フレックス属性

MyAttribute

この手順では、フレックス・ファミリに対してWebCenter Sitesが作成するデータベース表に名前を付けます。この名前には空白を入れないでください。

フレックス親定義

MyParentDefinition

なし

フレックス定義

MyFlexDefinition

なし

フレックス親

MyParent

なし

フレックス・アセット

MyAsset

なし

フレックス・フィルタ

なし

なし

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

5. 次のフォームで、ファミリの新規メンバーごとに、各フィールドに次のように入力します。

a. 「説明」フィールドで、手順3と同じ名前を入力します(ただし、名前の中の単語は空白で区切ります)。
ここで入力する名前は、アセット・タイプを識別するために、WebCenter Sitesインタフェース全体で使用されます。

b. 「複数」フィールドで、前の手順で使用した名前の複数形を入力します。

c. 「新規フレックス・ファミリの追加」をクリックします。

6. WebCenter Sitesがフレックス・ファミリを作成し、フレックス・ファミリ・メンバー(アセット・タイプ)が正常にインストールされたことを示すメッセージを返すまで待ってください。

7.3.2 新規のフレックス・アセット・タイプの有効化

この手順では、avisportsサンプル・サイトに対してフレックス・ファミリ・メンバーを有効化します。また、メンバーのスタート・メニュー・アイテムも作成し、後続の手順でインスタンスの作成および検索ができるようにします。

新規のフレックス・アセット・タイプを有効化するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「サイト」ノードを開いて次の手順を完了します。

a. avisports (フレックス・ファミリが有効にされるサンプル・サイト)、または選択したサイトを開きます。

b. そのサイトで「アセット・タイプ」を開き、「有効化」をダブルクリックします。

i. リストから、先ほど作成したアセット・タイプ(MyAsset、MyAttribute、MyFlexDefinition、MyParent、MyParentDefinition)を選択します。

ii. 「アセット・タイプの有効化」をクリックします。

c. 「アセット・タイプの有効化」フォームで次の操作を行います。

i. 「スタート・メニュー」のオプションがすべて選択されていることを確認します(後でファミリ・メンバーのインスタンスの作成および検索ができるようにするため。)

ii. 「アセット・タイプの有効化」をクリックします。

2. アセット・タイプがサイトで有効化されたことを示すメッセージをWebCenter Sitesが表示するまで待ってください。

7.3.3 フレックス・ファミリ・タブのWebCenter Sitesのツリーへの追加

この手順では、フレックス・ファミリの作成を追跡するタブを追加します。このタブは、フレックス・ファミリのメンバーの作成を終了したら、選択したそのメンバーが表示されるようにするために設定します。

ツリー・タブを追加するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ツリー」ノードをダブルクリックします。

2. 「ツリー・タブ」フォームで、一番下までスクロールして「新規ツリー・タブの追加」をクリックします。

3. 「新規ツリー・タブの追加」フォームで、フィールドに表7-3のように入力します。

表7-3 「新規ツリー・タブの追加」フォーム

フィールド名

入力または選択する値

コメント

タイトル

Sample Flex Family

タブの名前。

ツールチップ

Sample Flex Family

タブの説明。

サイト

avisports (または「新規のフレックス・アセット・タイプの有効化」で選択したサイト)

フレックス・ファミリを有効化するサイト。

必須ロール

任意

なし

タブ・コンテンツ

My Parent Definition

My Parent

My Flex Definition

My Asset

注意: 「選択したアイテムの追加」をクリックし、「表示の順序」矢印を使用して、前述の順にメンバーを並べ替えます。

なし

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

5. ページをリフレッシュします。

6. 「Sample Flex Family」タブをクリックして、そのコンテンツが、図7-2の表示と同一のものになっていることを確認してください。

図7-2 「Sample Flex Family」タブ

7.3.4 親定義アセットの作成

この手順では、2つの親定義を作成します。最初の親定義では階層の最上位レベルが確立され、2番目の親定義では2番目のレベルが確立されます。

最初の親定義アセットを作成するには::

1. メニュー・バーで、「新規」をクリックします。

2. 表示されるオプションのリストで、新規のマイ親定義を選択します。

3. 次のフォームで、次の操作を行います。

a. 表7-4のようにフィールドに入力します。

表7-4 「新規のマイ親定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Level 1 Def

これは、階層の最初のレベルの定義に付けた名前です。

説明

Level 1 Def

なし

親選択スタイル

選択ボックス

なし

マイ親定義

なし

このフィールドでは、親定義が選択されていません(または使用できません)。そのため、この親定義では階層の最初のレベルが確立されます。

b. 「保存」アイコンをクリックします。

2番目の親定義アセットを作成するには::

1. メニュー・バーで、「新規」をクリックします。

2. 表示されるオプションのリストで、新規のマイ親定義を選択します。

3. 次のフォームで、次の操作を行います。

a. 表7-5のようにフィールドに入力します。

表7-5 「新規のマイ親定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Level 2 Def

これは、階層の2番目のレベルの定義に付けた名前です。

説明

Level 2 Def

なし

親選択スタイル

選択ボックス

なし

マイ親定義

Level 1 Def

注意: 「単一値」で「必須」矢印をクリックして、選択したものを「選択済」リストに移動します。

「Level 1 Def」を選択すると、現在の親定義が「Level 1 Def」の下位に置かれます。このようにして定義を変更すると、2番目のレベルとしてLevel 2 Defが確立されます。

親が作成され、現在の親定義(Level 2 Def)がベースにされると、Level 1 Defをベースにした親の下位に置かれます。

b. 「保存」アイコンをクリックします。

4. ページをリフレッシュします。

5. 「Sample Flex Family」タブをクリックして、そのコンテンツを開き、図7-3の表示と同一のものになっていることを確認してください。

図7-3 親定義を含む「Sample Flex Family」タブ

7.3.5 フレックス親アセットの作成

この手順では、2つのフレックス親アセットを作成し、前の手順で作成したフレックス親アセットをベースにします。最初の親アセットは、階層の最上位レベルを占めます。2番目の親アセットは、階層の2番目のレベルを占めます。

階層の最上位レベルの親を作成するには::

1. 最上位で「コントリビュータ」アイコンをクリックして、Oracle WebCenter Sites: Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

3. 表示されたフォームで、フィールドに表7-6のように入力します。

表7-6 「新規のマイ親」フォーム

フィールド名

入力または選択する値

コメント

名前

Parent 1 [Level 1]

これは、階層内のレベル1の親に付けた名前です(レベルを識別しやすくするためのみの汎用名です)。

注意: このチュートリアルの終了時には、この名前をビジネス固有の名前(この例ではOutdoor Sports Equipment。これは、スポーツ用品を扱う会社の在庫を記述しています)に変更します。

マイ親定義

Level 1 Def

「Level 1 Def」を選択すると、作成中の親が階層の最上位レベルに置かれます。

4. フォームの最上部で、「保存」アイコンをクリックします。

階層の2番目のレベルの親を作成するには::

1. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

2. 表示されたフォームで、フィールドに表7-7のように入力します。

表7-7 新規のマイ親フォーム

フィールド名

入力または選択する値

コメント

名前

Parent 2 [Level 2]

これは、階層内のレベル2の親に付けた名前です(レベルを識別しやすくするための汎用名です)。

注意: このチュートリアルの終了時には、この名前をビジネス固有の名前(この例ではMountain Climbing)に変更します(これは、Parent 1 [Level 1]がSports Equipmentであれば適切な名前です)。

マイ親定義

Level 2 Def

「Level 2 Def」を選択すると、作成中の親が階層の2番目のレベルに置かれます。

Level 1 Def

デフォルトでは、Parent 1 [Level 1]が選択されます。

なし

3. 「保存」アイコンをクリックします。

4. 「コンテンツ・ツリー」で「Sample Flex Family」を開き、そのコンテンツが図7-4の表示と同一のものになっていることを確認してください。

図7-4 「コンテンツ・ツリー」で開いた「Sample Flex Family」タブ

注意:

次の手順に進む前に、図7-5 (作成したオブジェクト(親定義、および定義をベースにした親)が、お互いどのように関連しているかをまとめたものです)を確認してください。

図7-5 親および親定義

7.3.6 フレックス定義アセットの作成

この手順では、3つのフレックス定義アセットを作成します。

- 最初のフレックス定義アセットは、アセットをParent 1 [Level 1]の下に配置するために使用します。

- 2番目のフレックス定義アセットは、アセットをParent 2 [Level 2]の下に配置するために使用します。

- 3番目のフレックス定義アセットは、アセットを階層の両方のレベルの下に配置するために使用します。

最初のフレックス定義アセットを作成するには::

1. アプリケーション・バーにある「管理」アイコンをクリックして、Adminインタフェースに切り替えます。

2. メニュー・バーで、「新規」をクリックします。

3. 表示されるオプションのリストで、新規のマイ・フレックス定義を選択します。

4. 表示されたフォームで、フィールドに表7-8のように入力します。

表7-8 「新規のマイ・フレックス定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Flex Def 1

なし

マイ親定義

Level 1 Def

注意: 「単一値」で「必須」矢印をクリックします。

「Level 1 Def」と「単一値」を選択するとは、現在のフレックス定義を使用してフレックス・アセットを作成するときに、その親定義としてLevel 1 Defを使用する唯一の親の下にアセットを配置できるという意味です。ここに示す例では、このアセットはParent 1 [Level 1]の下に配置されます。

注意: 「複数値」オプションを選択すると、その親定義としてLevel 1 Defを使用する、任意の、そしてすべての親の下にアセットを配置できます。

5. 「保存」アイコンをクリックします。

2番目のフレックス定義アセットを作成するには::

1. ボタン・バーから、「新規」をクリックします。

2. 表示されるオプションのリストで、新規のマイ・フレックス定義を選択します。

3. 表示されたフォームで、フィールドに表7-9のように入力します。

表7-9 「新規のマイ・フレックス定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Flex Def 2

なし

マイ親定義

Level 2 Def

注意: 「単一値」で「必須」矢印をクリックします。

「Level 2 Def」と「単一値」を選択するとは、現在のフレックス定義を使用してフレックス・アセットを作成するときに、その親定義としてLevel 2 Defを使用する唯一の親の下にアセットを配置できるという意味です。ここに示す例では、このアセットはParent 2 [Level 2]の下に配置されます。

注意: 「複数値」オプションを選択すると、その親定義としてLevel 2 Defを使用する、任意の、そしてすべての親の下にアセットを配置できます。

4. 「保存」アイコンをクリックします。

3番目のフレックス定義アセットを作成するには::

1. ボタン・バーから、「新規」をクリックします。

2. 表示されるオプションのリストで、新規のマイ・フレックス定義を選択します。

3. 表示されたフォームで、フィールドに表7-10のように入力します。

表7-10 「新規のマイ・フレックス定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Flex Def_12

なし

親定義

Level 1 Def

Level 2 Def

注意: 「単一値」で「必須」矢印をクリックします。

「Level 1 Def」、「Level 2 Def」および「単一値」を選択するとは、現在のフレックス定義を使用してフレックス・アセットを作成するときに、親定義としてLevel 1 Defを使用する唯一の親の下、および親定義としてLevel 2 Defを使用する唯一の親の下に、アセットが配置されるという意味です。

この例では、このアセットは、Parent 1 [Level 1]およびParent 2 [Level 2]の下に配置されます。

親定義(続き)

なし

注意: 「複数値」オプションを選択すると、その親定義としてLevel 1 DefおよびLevel 2 Defを使用する、任意の、そしてすべての親の下にアセットを配置できます。

4. 「保存」アイコンをクリックします。

5. ページをリフレッシュします。

6. 「Sample Flex Family」タブをクリックして、そのコンテンツを開き、図7-6の表示と同一のものになっていることを確認してください。

図7-6 「Sample Flex Family」タブ

注意:

次の手順に進む前に、図7-7を確認してください(この図には、Sample Flex Familyの構造が、Contributorアプリケーションで表示されるとおりに描かれています)。この図は、作成したオブジェクト(フレックス定義)とベースの親定義の関連を示したものです。フレックス定義1は、Level 1親定義に基づきます。このフレックス定義をアセットの作成に使用すると、アセットはParent 1 [Level 1]の下に配置されます。フレックス定義2は、Level 2親定義に基づきます。このフレックス定義をアセットの作成に使用すると、アセットはParent 2 [Level 2]の下に配置されます。フレックス定義12は、Level 1およびLevel 2親定義に基づきます。このフレックス定義をアセットの作成に使用すると、アセットはParent 1 [Level 1]およびParent 2 [Level 2]の下に配置されます。

図7-7 フレックス定義およびアセット

7.3.7 フレックス・アセットの作成

この手順では、階層の3番目のレベル(フレックス・アセット)を追加して、フレックス・ファミリを完成します。作成するアセットは次の3つです。

- Parent 1 [Level 1]の下に配置する最初のアセット。

- Parent 2 [Level 2]の下に配置する2番目のアセット。

- Parent 1 [Level 1]とParent 2 [Level 2]の、両方の下に配置する3番目のアセット。

最初のフレックス・アセットを作成するには::

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから、「新規」→新規のマイ・アセットを選択します。

3. 表示されたフォームで、フィールドに表7-11のように入力します。

表7-11 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset 1

なし

マイ・フレックス定義

Flex Def 1

Flex Def 1を選択すると、作成中のアセットがParent 1 [Level 1]の下に配置されます。

4. 「保存」アイコンをクリックします。

2番目のフレックス・アセットを作成するには::

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから、「新規」→新規のマイ・アセットを選択します。

3. 表示されたフォームで、フィールドに表7-12のように入力します。

表7-12 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset 2

なし

マイ・フレックス定義

Flex Def 2

Flex Def 2を選択すると、作成中のアセットがParent [Level 2]の下に配置されます。

4. 次のフォームで、「保存」をクリックします。

2番目のフレックス・アセットを作成するには::

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから、「新規」→新規のマイ・アセットを選択します。

3. 表示されたフォームで、フィールドに表7-13のように入力します。

表7-13 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset_12

なし

フレックス定義

Flex Def_12

Flex Def_12を選択すると、作成中のアセットがParent [Level 1]とParent [Level 2]の、両方の下に配置されます。

4. 次のフォームで、「保存」アイコンをクリックします。

5. ページをリフレッシュします。

6. 「Sample Flex Family」タブをクリックして、そのコンテンツを開き、図7-8の表示と同一のものになっていることを確認してください。

図7-8 Sample Flex Familyの構造

図7-9は、作成したオブジェクト(アセット)が、ベースとなるフレックス定義とどのように関連しているかを示したものです。定義に基づいて、各アセットが関連する親の下に配置されます。たとえば、Flex Def 1定義では、Asset 1アセットがParent 1 [Level 1]の下に配置されます。ただし、Flex_Def_12定義の場合、Asset_12アセットはParent 1 [Level 1]とParent 2 [Level 2]の両方の下に配置されます。

図7-9 フレックス定義およびアセット

7.3.8 現実世界のデータ・モデルへの定型データ・モデルの変換

この手順では、作成した定型データ・モデルを現実世界のモデルに変換するために、親定義、親およびアセットの名前を変更します。(実際には、フレックス・ファミリ・メンバーの名前を変更するのではなく、フレックス・ファミリ・メンバーの作成時に、ビジネス・コンテキストにおいて直接名前を付けます。)

ここに示す例では、現実世界のモデルは、スポーツ用品を扱う企業を記述しています。フレックス親とアセットは、名前変更の終了後に、図7-10に示すように、「コンテンツ・ツリー」タブに一覧表示されます。

図7-10 「コンテンツ・ツリー」タブ

現実世界のモデルを作成するには::

1. 次のようにして、親定義の名前を変更します。

a. Adminインタフェースを開きます。

b. Sample Flex Familyのツリーで「Level 1 Def」を右クリックし、コンテキスト・メニューから「編集」を選択します。

c. 親の名前を「Level 1 Def (Type of Sports Equipment)」に置換し、「保存」アイコンをクリックします。

d. 同じようにして、「Level 2 Def」の名前をLevel 2 Def (Sport)に置換します。

2. 次のようにして、親の名前を変更します。

a. Contributorインタフェースに切り替えます。

b. 「コンテンツ・ツリー」をクリックして、そのコンテンツを表示します。

c. Sample Flex Familyのツリーで「Parent 1 [Level 1]」を右クリックし、コンテキスト・メニューから「編集」を選択します。

d. 親の名前をOutdoor Sports Equipmentに置換して、「保存」アイコンをクリックします。

e. 同じようにして、「Parent 2 [Level 2]」の名前をMountain Climbingに置換します。Sample Flex Familyのツリーは、図7-11のようになります。

図7-11 展開したSample Flex Familyのツリー・ノード

3. 次のようにして、アセットの名前を変更します。

a. Sample Flex Familyのツリーで、「Outdoor Sports Equipment」を開きます。

b. 「Asset 1」を右クリックし、「編集」を選択します。

c. アセットの名前をOur Awesome Catalogに置換し、「保存」アイコンをクリックします。

d. 同じようにして、「Mountain Climbing」を開いて「Asset 2」の名前をHigh Altitude Gearに置換します。

e. 「Asset_12」の名前をSpecial Ordersに置換します。
名前変更後のアセットは、図7-12のようになります。

図7-12 展開したSample Flex Familyのツリー・ノード

7.3.9 現実世界のモデルの開発

この手順では、親およびそのアセットを新規作成し、それぞれに現実世界の名前を指定することによって、データ・モデルを開発します。次の操作を行います。

- レベル2の2番目の親を作成し、White Wateringという名前を付けます。

- 親のアセット(カタログ)を作成し、Rafts, Canoes, and Kayaksという名前を付けます。図7-13に示すように、「White Watering」を開いて、そのアセットを表示します。

図7-13 展開したSample Flex Familyのツリー・ノード

レベル2の親を作成するには:

1. アプリケーション・バーで「コントリビュータ」アイコンをクリックして、Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

3. 表示されたフォームで、フィールドに表7-14のように入力します。

表7-14 「新規のマイ親」フォーム

フィールド名

値

名前

White Watering

マイ親定義

Level 2 Def (Sports)

4. 「保存」アイコンをクリックします。

親のアセットを作成するには:

1. アプリケーション・バーで「コントリビュータ」アイコンをクリックして、Contributorインタフェースに切り替えます。

2. 「コンテンツ」メニューから、「新規」→新規のマイ・アセットを選択します。

3. 表示されたフォームで、フィールドに表7-15のように入力します。

表7-15 「新規のマイ・アセット」フォーム

フィールド名

値

名前

Rafts, Canoes, and Kayaks

マイ・フレックス定義

Flex Def 2

4. 「Level 2 Def」ドロップダウン・リストから、「White Watering」を選択します。

5. 「保存」アイコンをクリックします。

6. ページをリフレッシュして、Sample Flex Familyのツリー・タブを表示します。

そのコンテンツは、図7-14に表示されるものと同一になります。

図7-14 展開したSample Flex Familyのツリー・ノード

[1]
接尾辞の1、2および_12は、階層のレベルのことです(_12は、レベル1とレベル2の両方を指しています)。たとえば、Asset 1はレベル1の下に配置されているアセットを指しています。Asset_12はレベル1とレベル2の、両方の下に配置されているアセットを指しています。

8 フレックス・フィルタの作成

この章では、フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成の手順について説明します。

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

- フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットについて

- フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成

- ドキュメント変換フレックス・フィルタ

8.1 フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットについて

フレックス・フィルタでは、そのフィルタが割り当てられたフレックス・アセットに対して、処理後の操作を行います。フィルタは、関連付けられたアセットが保存されたときにコールされます。フィルタは、アセットの編集操作が取り消されるとコールされません。

1つのフレックス・アセットに、複数のフレックス・フィルタを割り当てることができます。アセットのフィルタは、アセットの定義の「フィルタ」セクションで定義された順番で、指定されたタスクを実行します。フレックス・フィルタが実行するタスクは、フィルタを定義するフレックス・フィルタ・クラスにより決まります。たとえば、Doc-Typeフィルタ・クラスで定義されるフレックス・フィルタは、そのクラスにより有効化され、アセットのMIMEタイプを決定したり、URLパスからファイル・タイプを抽出したりします。

各フレックス・フィルタは、属性に関連付けられており、アセット用に処理したデータでこの属性を更新します。これらの属性は導出属性と呼ばれます。導出属性は、フィルタが割り当てられているのと同じフレックス・ファミリに作成する必要があります。ただし、導出属性は厳密にはフレックス・フィルタの出力であるため、アセット定義には指定しないでください。それらはアセットが保存されたときにのみアセットに追加されます。1つのアセットに複数のフィルタが割り当てられる場合、どのフィルタも、そのアセットに関連付けられた他のフィルタが出力した属性に依存しないようにしてください。

(WebCenter SitesのデータベースのFilters表に)フィルタが定義されている場合、そのフィルタは任意のアセット・タイプの子定義に適用できます。(フィルタは、アセット・タイプの親定義に適用することはできません。)特定のアセット・タイプに関連した特定の目的のために作成されるフィルタは、そのアセット・タイプの子定義にのみ関連付ける必要があります。たとえば、Mediaアセットのイメージ・タイプを処理するよう設計されているフィルタは、テキストをベースにしたアセットに適用すると機能しません。

この項には次のトピックが含まれます:

- フレックス・フィルタ・クラス

- フレックス・フィルタ・アセット

8.1.1 フレックス・フィルタ・クラス

フレックス・フィルタ・クラスには、フレックス・フィルタ・アセットの機能が実装されます。これらのクラスは、WebCenter SitesデータベースのFilters表に一覧表示されます。フレックス・フィルタ・アセットを作成する場合には、対象となるフレックス・フィルタ・クラスを選択します。

WebCenter Sitesに用意されているフレックス・フィルタ・クラスは次のとおりです。

- Doc-Type: 1つ以上のMIMEファイル・タイプを含むアセットからコンポーネントを抽出し、各ファイル・タイプを個々に名付けられた属性にマップします。

- サムネイル・クリエータ: イメージをサムネイルに変換します。

- フィールド・コピアー: システム定義された属性の内容をユーザー定義の属性にコピーします。

- ドキュメント変換: 登録された変換エンジン(SystemTransforms表で指定されたエンジン)を起動して、あるファイル・タイプのドキュメントを別のファイル・タイプのドキュメントに変換します。変換エンジンは、ドキュメント・トランスフォーマにコールを転送してドキュメントの変換を行うラッパーとして機能します。

WebCenter SitesのFiltersデータベース表に定義することにより、カスタム・フレックス・フィルタ・クラスを作成できます。カスタム・フレックス・フィルタ・クラスの作成方法については、「カスタム・フレックス・フィルタ・クラスの定義」を参照してください。

Doc-Typeフィルタ・クラス

Doc-Typeフィルタは、ドキュメントを取り込んで、ファイルに関連付けられたMIMEタイプ・データを個々のコンポーネントに抽出します。たとえば、テキストおよびGIF写真を含むアップロードされたファイルは、TXTフォーマット・データおよびGIFフォーマット・データをそれぞれ含む2つの生成された属性にフィルタされます。

Doc-Typeクラスは、次の引数で定義されます。

- Attribute to Hold Derived File Name: (オプション) 出力ファイル名を格納するフレックス属性を入力します。

- Attribute to Hold Derived File Type: この属性にはファイル拡張子が格納されます。

- Attribute to Hold Derived MIME Type: (オプション) MIMEファイルには、プレーン・テキスト、添付ファイル、メディア・ファイルなど、いくつかのタイプがあります。

- Input Attribute Name: アップロードされたファイル名に対応する、WebCenter Sitesによって格納された属性名。

サムネイル・クリエータ・フィルタ・クラス

サムネイル・クリエータ・フィルタを使用すると、コンテンツ・プロバイダは元のグラフィックをアップロードでき、WebCenter Sitesは新しいサムネイル・サイズのGIFグラフィック・ファイルを作成できます。

サムネイル・クリエータ・クラスを定義する引数は次のとおりです。

- Input Attribute Name: アップロードされたファイルの名前。

- 大きなバージョンのサムネイル・グラフィックのための表示値: Output Attribute for Main Height、Output Attribute for Main WidthおよびEnter Maximum Pixel Size。

- 作成するサムネイルを定義する属性: Output Attribute Name、Output Attribute for Thumb Height、Output Attribute for Image AspectおよびOutput Attribute for Thumb Width。

フィールド・コピアー・フィルタ・クラス

フィールド・コピアー・フィルタは、システム定義された属性の内容をユーザー定義のフレックス属性にコピーします。

フィールド・コピアー・クラスを定義する引数は次のとおりです。

- Name: コピーするシステム定義された属性の名前。

- Value: システム定義された属性の値のコピー先とするフレックス属性の名前。

図10-3は、FirstSiteIIサンプル・サイトのMediaフレックス・ファミリを使用して、フィールド・コピアー・フィルタを実装する方法の詳細な例を示しています。フィールド・コピアー・フィルタのこの例での目的は、親アセットの名前によりイメージ・アセットを分類することです。

ドキュメント変換フィルタ・クラス

ドキュメント変換フィルタ・クラスを定義する引数は次のとおりです。

- Document Transformer Name: SystemTransforms表に一覧表示されているとおりの、登録された変換エンジンの名前。デフォルトでは、SystemTransforms表にCS: Convert to Raw Textが一覧表示されています。このエンジンは、バイナリ・ファイルからテキスト・フォーマットへの変換を開始する場合に使用されます。

注意:

WebCenter Sitesでは、次のドキュメント・トランスフォーマを使用できます。

com.fatwire.transformer.tika.DocumentTransformerImpl

ドキュメント・トランスフォーマは、CS: Convert to Raw Textエンジンによって起動されたときに、ドキュメントを未加工のテキスト・ファイルに変換するようにコーディングされています。他のファイル・タイプに変換するには、そのファイル・タイプ用にドキュメント・トランスフォーマを作成して、(登録されていないかぎりは)対応する変換エンジンを登録し、そのドキュメント・トランスフォーマをWebCenter Sitesに登録する必要があります。デフォルトの実装およびドキュメント変換ソリューションの詳細は、「ドキュメント変換フレックス・フィルタ」を参照してください。

- Input Attribute Name: フレックス・フィルタによって内容が変換されるフレックス属性の名前。ドキュメント変換フィルタについては、入力属性はblobタイプである必要があります。これは、ドキュメント変換フィルタがこの属性のファイルを検索するためです。

- Fail on Transform Error: 変換が正常終了しなかった場合に、エラー・メッセージが表示されるようにするかどうかを選択します。

- Output Attribute Name: ドキュメント変換の結果を格納するフレックス属性の名前。ドキュメント変換フィルタについては、出力属性はblobタイプである必要があります。これは、変換結果がファイルとして格納されるためです。
出力属性(フィールド)に格納されるデータは、入力属性のデータに由来するため、読取り専用です。このデータは、アセットが保存されるたびに、入力属性のソース・データから再生成されます。

- Output Document Extension: 結果として生成されるファイルに割り当てられるファイル拡張子。選択したDocument Transformer Nameに適したドキュメント拡張子を入力してください。たとえば、ドキュメント変換エンジンをCS: Convert to HTMLに指定した場合、ドキュメント拡張子はhtmまたはhtmlにする必要があります。

8.1.2 フレックス・フィルタ・アセット

フレックス・フィルタ・アセットは、次の基準のすべてで定義されます。

- Filters表に登録されたフレックス・フィルタ・クラス。

- そのフィルタ・クラスに(引数を介して)渡された情報。これらの引数は、使用するデータ、フィルタのアクションに対する制約、およびアセットが保存されたときにフィルタリング・プロセスの結果を格納する場所を指定します。

フレックス・フィルタ・アセットを作成する場合、使用するフレックス・フィルタ・クラスを選択し、フィルタ・クラスのアクションに必要な引数の値を入力します。

フレックス・フィルタ・アセットを作成した後、それを適切なフレックス定義アセットに割り当てます。その後、コンテンツ・プロバイダがその定義のフレックス・アセットを保存するたびに、フィルタは割り当てられたアクションを自動的に実行します。手順の詳細は、「フレックス・フィルタ・アセットの作成」を参照してください。

8.2 フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成

フレックス・フィルタを使用するには、まず、WebCenter Sitesデータベースにカスタム・フレックス・フィルタ・クラスを定義する必要があります。次に、そのクラスで機能が定義されているフレックス・フィルタ・アセットを作成することにより、カスタム・フレックス・フィルタ・クラスをアクティブ化します。

基本的な手順は次のとおりです。

1. カスタム・フレックス・フィルタ・クラス用の実装コードを提供するJavaクラスを作成します。手順は、「フレックス・フィルタ・クラスの実装」を参照してください。

2. 新規フレックス・フィルタ・クラスを、WebCenter SitesデータベースのFilters表に定義します。手順は、「カスタム・フレックス・フィルタ・クラスの定義」を参照してください。

3. カスタム・フレックス・フィルタ・クラスで定義されたフレックス・フィルタ・アセットを作成します。

a. フィルタの引数として参照される属性を作成します。

b. フレックス・フィルタ・アセットを作成し、フレックス・フィルタ・クラスに割り当てます。

c. 新規フィルタ・アセットを子定義に追加します。

d. フィルタ・アセットを追加した定義に関連付けられたすべての関連アセットを再度保存します。

手順は、「フレックス・フィルタ・アセットの作成」を参照してください。

この項には次のトピックが含まれます:

- フレックス・フィルタ・クラスの実装

- カスタム・フレックス・フィルタ・クラスの定義

- フレックス・フィルタ・アセットの作成

8.2.1 フレックス・フィルタ・クラスの実装

カスタム・フレックス・フィルタを実装するには、AbstractFlexFilterクラスを拡張することにより、そのための新規Javaクラスを作成します。このフィルタ・クラスには、フィルタ要求の処理に必要なデフォルト機能がすべて含まれています。AbstractFlexFilterクラスを拡張し、フレックス属性にアクセスして導出属性値を設定することを目的とするカスタム・フレックス・フィルタ・クラスの実行例は、ソース・ファイルSampleFlexFilter.javaに提供されています。

フレックス・フィルタの機能は、抽象化インタフェースと呼ばれるパラメータにより実装されます。フレックス・フィルタは、フィルタリングしているアセットの特定の側面についてのみ知る必要があるため、抽象化インタフェースは、指定されたフレックス・アセットに対して機能を実行するために必要なアセット情報にのみフィルタがアクセスできるようにしています。

表8-1に、フレックス・フィルタの実装に必要な抽象化インタフェース、および各抽象化インタフェースがフィルタに渡すアセット情報の一覧を示します。カスタム・フレックス・フィルタ・クラスの実装に使用される抽象化インタフェースの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

表8-1 抽象化インタフェース(com.openmarket.gator.interfacesパッケージ)

抽象化インタフェース

説明

IFilterEnvironment

フィルタをサポートしている環境についての情報を取得するための方法を提供します。

IFilterableAssetInstance

フィルタされているアセットを操作するための方法を提供します。

IFilterDescription

フィルタが実行中に変更する可能性のあるすべての導出属性を記述するための方法を提供します。

IFilterDependencies

フィルタされるアセット・インスタンスに対する依存性を記録するための方法を提供します。依存性は、フィルタされるアセットとの関係を共有するタイプおよびIDにより別のアセットを参照します。依存性が宣言される場合、その依存性はexactとexistsのいずれかです。

注意:

標準アセット属性は、IFilterableAssetInstance.getメソッドにより取得できます。たとえば、標準アセット記述を取得するには、次の行を追加します。

String description = instance.get(description);

新規フレックス・フィルタ・クラスのJavaコードを作成する場合、(COM.FutureTense.Interfacesパッケージ内の)単一のFTValListパラメータ付きでコンストラクタを定義します。このパラメータは、Filtersデータベース表に格納されているフィルタの定義から取得した引数のリストを提供します。これらの引数は、キー/値のペアの形でフィルタに渡されます。Filtersデータベース表内のフィルタ・クラスに対してあらかじめ定義された引数がない場合、FTValListはNULLとなります。

8.2.1.1 AbstractFlexFilterクラスの拡張

フレックス・フィルタ・クラスの実装を作成するために、AbstractFlexFilterクラスを拡張できます。このクラスはcom.openmarket.gator.flexfiltersパッケージ内にあります。新規フレックス・フィルタのJavaクラスを作成する場合、theAbstractFlexFilterクラスのJavaコードからフィルタの機能に必要なメソッドをコールできます。これにより、カスタム実装の作成に必要なコードの量が簡略化されます。

メソッドがコールされると、フィルタのアセット識別子である、引数String filterIdentifierが提供されます。同じフィルタを異なるフレックス・アセット・ファミリに関連付けると、フィルタ識別子に、関連付けられたファミリのフィルタ定義が反映されます。この引数は、異なるアセット・ファミリが使用するフィルタを実装している場合に便利です。フィルタは、起動された時点でどのフレックス・ファミリの関連付けが使用されているかを知ることができます。

フレックス・フィルタ・クラスの実装に使用される抽象化メソッドの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

Required Abstract Methods

すべてのフレックス・フィルタ実装で必要となる抽象化メソッドは次のとおりです。

public void filterAsset(IFilterEnvironment env,
String filterIdentifier,
FTValList filterArguments,
IFilterableAssetInstance instance)
throws AssetException;

これらの行は、新規または既存のアセットが保存されるときに、アセットの後処理を実行するための主要なメソッドです。このメソッドは、編集が取り消されるとコールされません。フィルタの目的を表す作業を実行します。引数のリスト(FTValList)が提供され、フィルタは、入力属性定義または出力属性定義(あるいはその両方)を入手でき、フィルタに対して有効な他の情報も入手できます。WebCenter Sitesインタフェース内にフィルタが作成されると、filterArgumentsリストが定義されます。

public FTValList getLegalArguments(IFilterEnvironment env,
String filterIdentifier)
throws AssetException;

これらの行は、適切なフィルタ引数のリストを返すためにコールされるメソッドです。フィルタを選択して「引数の取得」ボタンを押した後に、WebCenter Sitesインタフェースはドロップダウン・リストを埋めるために、フィルタの作成または編集中にこのメソッドをコールします。

Optional Abstract Methods

次の抽象化メソッドは、AbstractFlexFilter クラス内の抽象化メソッドをオーバーライドするために使用できます。AbstractFlexFilterクラスが提供するデフォルトの実装は通常、ほとんどのフィルタで十分であるため、これらのメソッドはオプションです。

public void describeDerivedAttributes(IFilterEnvironment env,
String filterIdentifier, FTValList filterArguments,
String defTypeName, String parentDefTypeName,
IFilterDescription descriptionObject) throws AssetException

このメソッドは、すべての可能性のある導出属性、グループ・アフィニティ、およびフィルタで設定できる推奨を記述します。フィルタが属性を出力するように計画している場合、このメソッドは変更される属性を識別する必要があります。これは、フレックス・アセットが表示されるたびに、アセットの編集を行うためにコールされます。

public void getDependencies(IFilterEnvironment env,String filterIdentifier,
FTValList filterArguments, String assetTypeName, String parentTypeName,
IFilterDependencies filterdeps) throws AssetException

このメソッドは、フィルタのアセット依存性を記述するためにコールされます。フィルタ依存性は、existsとexactのいずれかに設定されます。

public String[] getArgumentLegalValues(IFilterEnvironment env,
String filterIdentifier, String argumentName) throws AssetException

このメソッドは、指定された引数の許容値のリストを返すためにコールされます。返された一覧がNULLの場合、どのような値でも許容されます。このメソッドは、フィルタ・アセットに指定された引数値を有効化するために、フィルタ・アセットが作成または編集されているときに、Adminインタフェースによってコールされます。

8.2.2 カスタム・フレックス・フィルタ・クラスの定義

カスタム・フレックス・フィルタ・クラスを、WebCenter SitesデータベースのFilters表に定義します。次の手順では、フレックス・フィルタ・クラスにはCustomFilterという名前が付けられます。

カスタム・フレックス・フィルタ・クラスを定義する手順:

1. カスタム・フレックス・フィルタ・クラス用の実装コードを含む.jarファイルまたはclassファイルを、WebCenter Sites製品のjarsを保持しているディレクトリにコピーします。

注意:

カスタム・フレックス・フィルタ・クラス用の実装コードを提供するJavaクラスの作成の詳細は、「フレックス・フィルタ・クラスの実装」を参照してください。

- WebLogicの場合: app-server-install-dir/bea/path-to-domain/domain-name/applications/WEB-INF/lib

- WebSphereの場合: WebSphere-Installation-Directory/InstalledApps/WEB-INF/lib

2. Oracle WebCenter Sites Explorerを開き、新規フィルタ・クラス用の行をFilters表に追加します。

a. ツリーで、「表」ノードを展開し、Filters表を選択します。

b. 「ファイル」→「新規」→「レコード」の順に選択します。

c. データベースで次の列に入力して、フィルタを定義します。

- name: WebCenter Sitesインタフェースに表示させるフィルタの名前を入力します。

- description: (オプション) フィルタ・クラスの目的についての短い要約を入力します。

- classname: フィルタ・クラスの実装の正確なクラス名(例: com.fatwire.firstsite.filter.SampleFlexFilter)を入力します。この名前は、WebCenter Sitesのクラスパスにロード可能である必要があります。

- args: (オプション) フィルタ用の入出力引数を入力します。引数のキー/値のペアは、アンパサンド(&)文字で区切られます (例: arg1=argument1&arg2=argument2)。これらの引数は、フィルタ・コンストラクタに渡され、その使用はフィルタの開発者に任されます。

注意:

フレックス・フィルタ・クラスの入出力引数をFilters表に定義しない場合、それらの引数はフレックス・フィルタ・クラスのコードに定義できます。詳細は、「フレックス・フィルタ・クラスの実装」を参照してください。

d. 「ファイル」→「保存」の順に選択します。
新規フィルタ・エントリは図8-1のようになります。

図8-1 サンプルのフィルタ・エントリ

フィルタ・クラスは、フィルタ・アセットの「新規」フォームおよび「編集」フォームの「フィルタ」ドロップダウン・リスト内のオプションとして表示されます。

8.2.3 フレックス・フィルタ・アセットの作成

フィルタ・アセットの作成前に、入出力の属性として使用するフレックス属性が存在している必要があります。既存の属性の値が上書きされないようにするために、カスタム・フレックス・フィルタの引数が参照する属性を作成します。この例では、タイプstringのMedia属性を2つ(入力属性として使用するFSII_CustomInputと、出力属性として使用するFSII_CustomOutput)を作成しました。

FirstSiteIIサンプル・サイトのMediaフレックス・ファミリに対して、FSII_CustomFlexFilterという名前のフレックス・フィルタ・アセットを作成します。

フレックス・フィルタ・アセットを作成する手順:

1. 一般管理者としてAdminインタフェースにログインし、フレックス・フィルタ・アセットを作成するサイトを選択します(この例ではFirstSiteIIサンプル・サイト)。

2. フィルタの入出力引数が参照する属性を作成します(定義されていない場合)。次の要件に注意してください。

- ドキュメント変換フィルタ・クラスを使用しているフレックス・フィルタの場合、入出力属性のタイプはblobである必要があります。

- どのフレックス・フィルタでも、入力属性、出力属性、フレックス・フィルタはすべて、同一のフレックス・ファミリに属している必要があります。

フレックス属性の作成の手順は、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

3. 関連付けられたフレックス・ファミリ(この例ではMediaフレックス・ファミリ)に対するフレックス・フィルタ・アセットを作成します。

a. スタート・メニュー項目から「新規」をクリックします。

b. アセット・タイプのリストで、作成するフィルタのタイプを選択します。この例では、New Media Filterです。
メディア・フィルタ・フォームが開きます。

c. 次の各フィールドに値を入力します。

i. 「名前」フィールドで、このフィルタの一意の名前を入力します(この例ではFSII_CustomFlexFilterを使用)。

ii. 「説明」フィールドに、フィルタの機能を要約した短い説明を入力します。

iii. 「フィルタ」ドロップダウン・リストから、カスタム・フィルタに割り当てた名前と一致するフィルタ定義を選択します(この例では、CustomFilterを選択)。次に「引数の取得」をクリックします。

iv. 「引数」フィールドで、フレックス・フィルタ・アセットに対する入力および出力の引数を指定します。「追加」をクリックして、フィルタに引数を追加します。

d. 「保存」をクリックします。
図8-2に、保存したフィルタを示します。

図8-2 新規フィルタ

4. 新規フィルタ・アセットを追加する先の子定義を検索します(この例では、たとえば、フィルタをMedia子定義FSII_Imageに追加します)。

a. スタート・メニュー項目から「検索」をクリックします。

b. アセット・タイプのリストで、フィルタを追加する先のアセット定義のタイプを選択します(この例ではFind Media Definition)。

c. 「検索」フィールドに、フィルタを追加する先の定義の名前を入力します(この例ではFSII_Image)。

d. 「検索」をクリックします。

e. 検索結果のリストで定義に移動して、その「編集」アイコンをクリックします(この例ではFSII_Image)。
定義の「編集」フォームが開きます。

5. 「編集」フォームで、フィルタと入力引数を定義に追加します。

a. 「属性」で、「使用可能」リスト内の入力属性を強調表示して、「選択済」リストに移動します(この例ではFSII_CustomInput)。

b. 「フィルタ」で、「使用可能」リスト内のフレックス・フィルタを強調表示して、「選択済」リストに移動します(この例ではFSII_CustomFlexFilter)。

注意:

新規フィルタを追加します。新規フィルタが依存または共有する属性を作成または変更するフィルタがほかにあれば、そのフィルタの後に追加します。

c. 「保存」をクリックします。図8-3に、保存したフィルタを示します。

図8-3 新規フィルタ

6. フィルタを追加した定義に関連付けられたすべての既存アセットを検索し、再度保存します。これにより、フィルタは出力属性(FSII_CustomOutput)に、入力属性(FSII_CustomInput)からの導出値を移入できます。例:

a. アプリケーション・バーで、「コントリビュータ」アイコンをクリックし、Oracle WebCenter Sites: Contributorインタフェースに切り替えます。

b. 「検索」フィールドで下矢印アイコンをクリックします。「検索タイプ」メニューで、手順5で変更した定義に関連付けられたアセットのタイプを選択します(この例ではFind Media)。次に、虫めがねアイコンをクリックします。
「検索」タブが開き、検索結果が表示されます。

c. アセットを再度保存します。アセットのツールバーで、「保存」アイコンをクリックします。

d. アセットを調査します。アセットのツールバーで、「調査」アイコンをクリックします。
このイメージは、この項で作成したフィルタを含む、複数のフィルタを起動するフレックス・アセットの編集結果です。デフォルトでは、MediaアセットはFSII_FieldCopierフィルタ、FSII_ImageTypeフィルタおよびFSII_ThumbnailExtractorフィルタをコールします。この例では、Mediaアセットも、入力属性(MediaCustomInput)の値をとるFSII_CustomFlexFilterフィルタをコールし、導出文字列値を出力属性(MediaCustomOutput)に挿入します。

図8-4 「調査」ダイアログ

8.3 ドキュメント変換フレックス・フィルタ

ドキュメント変換フレックス・フィルタの実装に必要なコンポーネントは次のとおりです。

- SystemTransforms表に登録され、目的のファイル・タイプを示す名前が付けられた変換エンジン。たとえば、CS:Convert to Raw Textのようになります。

- ドキュメント変換(たとえば、バイナリ・ファイルを未加工のテキスト・ファイルに変換する)を行うカスタム・クラスである、ドキュメント・トランスフォーマ。ドキュメント・トランスフォーマ・クラスは、次のインタフェースを実装します。

com.fatwire.transformer.common.DocumentTransformer

- 変換エンジンのドキュメント・トランスフォーマへの関連付けに使用されるtransformer-formats.xmlファイル。WebCenter SitesのWEB-INF/classesフォルダにあるこのファイルは、目的のファイル・タイプとドキュメント・トランスフォーマを指定します。

ドキュメント変換フレックス・フィルタが起動されると、変換エンジンはラッパーとして機能します。エンジンは(transformer-formats.xmlファイルを使用して)ドキュメント・トランスフォーマへコールを転送し、ドキュメント・トランスフォーマがファイル変換を実行します。

この項には次のトピックが含まれます:

- デフォルトのソリューション

- カスタム・ソリューションについて

- デフォルトの変換エンジンの使用

- ドキュメント変換フレックス・フィルタのカスタマイズ

8.3.1 デフォルトのソリューション

WebCenter Sitesは、ドキュメントを未加工のテキスト・ファイルに変換するために使用できるデフォルトのソリューションを提供しています。デフォルトのコンポーネントは次のとおりです。

- SystemTransforms表に登録されたCS:Convert to Raw Text変換エンジン。

- com.fatwire.transformer.tika.DocumentTransformerImplという名前のドキュメント・トランスフォーマ。CS:Convert to Raw Textエンジンによって起動されたときに、未加工のテキスト・ファイルを出力するようにコーディングされています。

- transformer-formats.xmlファイル。前述で命名されたドキュメント・トランスフォーマ・クラスにCS:Convert to Raw Textエンジンを関連付けるように構成されています。

デフォルトのソリューションを使用するには、対応するドキュメント変換フレックス・フィルタの実装が必要で、これにより、変換エンジンが、WebCenter Sitesインタフェースからドキュメント変換オプションとしてアクセスできるようになります。

8.3.2 カスタム・ソリューションについて

前述したデフォルトのソリューション以外のドキュメント変換のソリューションを設計するには、次のコンポーネントを作成およびカスタマイズします。

1. 目的のファイル・タイプ用のドキュメント・トランスフォーマを作成して、デプロイします。

2. 目的のファイル・タイプ用の変換エンジンを登録します。

3. ドキュメント・トランスフォーマと目的のファイル・タイプを指定するようにtransformer-formats.xmlファイルを構成します。(このxmlファイルは、複数のドキュメント・トランスフォーマをサポートします。)

4. この章で記述しているように、ドキュメント変換フレックス・フィルタを実装します。

手順の詳細は、「ドキュメント変換フレックス・フィルタのカスタマイズ」を参照してください。

8.3.3 デフォルトの変換エンジンの使用

WebCenter Sitesには、CS:Convert to Raw Text変換エンジンが用意されています。これらのエンジンはすべて、デフォルトでSystemTransforms表に登録されます。ドキュメント・トランスフォーマをHTML、HTMLフラグメントまたはXMLの出力ファイルに書き込む場合は、対応するエンジンを使用してください。

デフォルトの変換エンジンを使用する手順:

1. Oracle WebCenter Sites Explorerを開きます。

2. SystemTransforms表を選択します。

3. 作成したエンジンを見つけます。エンジンのtargetフィールドの値をメモします。この値を、「ドキュメント・トランスフォーマの登録」に記載されているtransformer-formats.xmlファイルの<mime-type>に入力します。

4. この変換エンジンに適した引数があれば、argsフィールドで設定します。たとえば、exporttype=HTMLと入力します。

5. 「ドキュメント・トランスフォーマの登録」に進みます。

8.3.4 ドキュメント変換フレックス・フィルタのカスタマイズ

WebCenter Sitesには、デフォルトのドキュメント・トランスフォーマとしてcom.fatwire.transformer.tika.DocumentTransformerImplが用意されており、これは、CS:Convert to Raw Textエンジンによって起動されたときに、未加工のテキスト・ファイルを出力するようにコーディングされています。目的のファイルが未加工のテキスト以外の場合は、次のように、フレックス・フィルタがサポートするコンポーネントを作成して登録します。

ドキュメント・トランスフォーマ・フレックス・フィルタを実装する前に:

- ドキュメント・トランスフォーマ・フレックス・フィルタの作成とデプロイ

- 変換エンジンの登録

- ドキュメント・トランスフォーマの登録

8.3.4.1 ドキュメント・トランスフォーマ・フレックス・フィルタの作成とデプロイ

ドキュメント・トランスフォーマ・フレックス・フィルタを作成およびデプロイできます

1. com.fatwire.transformer.common.DocumentTransformerインタフェースの実装を作成します。次のメソッドを実装します。

public String getOutputDocument(String filename,
TransformerFormat outputformat);

および

public String getOutputDocument(String filename,String inputFileExt,
TransformerFormat outputformat);

このメソッドは非推奨になったため、次のメソッドではNULLを返すことができます。

public InputStream getBytesAsStream(String filename,
TransformerFormat outputformat);

2. ドキュメント・トランスフォーマのjar ファイルまたはclassファイルを、WebCenter Sites Webアプリケーションのlibフォルダまたはclassesフォルダにコピーします。

- WebLogic Serverの場合:

app-server-install-dir/bea/path-to-domain/domain-name/applications/WEB-INF/lib

- WebSphere Application Serverの場合:

WebSphere-Installation-Directory/InstalledApps/WEB-INF/lib

8.3.4.2 変換エンジンの登録

ドキュメント・トランスフォーマを未加工のテキスト以外の出力ファイルに書き込んだ場合は、次の手順を実行します。それ以外の場合は、次を参照してください。

変換エンジンを登録するには::

1. Oracle WebCenter Sites Explorerを開き、新規変換エンジン用の行をSystemTransforms表に追加します。

2. SystemTransforms表を選択して、表の作業領域をクリックします。

3. 「ファイル」→「新規」→「レコード」の順に選択して、新規の行に次のように入力します。

- name列に、変換エンジンの名前を入力します。

- description列に、エンジンの説明を入力します。

- target列に、text/<filetype>と入力します。

注意:

次の項(「ドキュメント・トランスフォーマの登録」)では、<mime-type>のターゲット値を使用します。

- classname列に、エンジンのデフォルトのクラス名com.fatwire.transformer.common.FWTransformerを入力します。

- この変換エンジンに適した引数があれば、argsフィールドで設定します。

4. 変更を保存します。

8.3.4.3 ドキュメント・トランスフォーマの登録

ドキュメント・トランスフォーマを、WebCenter SitesのWEB-INF/classesフォルダにあるtransformer-formats.xmlファイルに登録できます。デフォルトのファイルを例8-1に示します。

1. <mime-type>を、変換エンジンのtargetフィールドの値に設定します。

targetの値は、「変換エンジンの登録」で設定されています。

2. ドキュメント・トランスフォーマーのクラス名を指定します。

クラス名は、「ドキュメント・トランスフォーマ・フレックス・フィルタの作成とデプロイ」で作成されています。

3. 複数のドキュメント・トランスフォーマを指定するには、各トランスフォーマに対してエントリを繰り返します。

<mime-type>の値によって、変換エンジンによってどのドキュメント・トランスフォーマが起動されるかが決まります。

例8-1 デフォルトのtransformer-formats.xml

<transformer-format>
<name>Text Format</name>
<!-- name of the output format supported by this repository -->
<mime-type>text/plain</mime-type>

<file-extension>txt</file-extension>
<transformer-options>
<!-- number of possible transformers available for this transformation -->
<transformer>
<name>TIKA</name>
<properties>
<property>
<name>ClassName</name>
<!-- name of the transformer class that gets loaded by transformer factory -->
<value>com.fatwire.transformer.tika.DocumentTransformerImpl</value>
</property>
<property>
<name>InputFile_Exts</name>
<!-- allowed input file extensions..* means all file types supported by tika -->
<value>*</value>
</property>
</properties>
</transformer>
</transformer-options>
</transformer-format>

9 属性エディタの設計

属性エディタは、フレックス・アセットまたはフレックス親アセットに対して属性が「新規」フォームまたは「編集」フォームに表示されるときに、その属性に対するデータの入力方法を指定します。属性エディタを属性に割り当てると、その属性のデフォルトの入力メカニズム(スタイル)のかわりに、その属性エディタが使用されます。デフォルトの入力スタイルは、その属性のデータ型に基づいています。

属性エディタによって属性の入力メカニズムの形式が設定されるため、フレックス属性を設計するのと同じように属性エディタを設計します。属性エディタはアセットであるため、ワークフローとリビジョンの追跡機能を使用して、他のタイプのアセットと同じように属性エディタを管理できます。

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

- 属性エディタについて

- 属性エディタの作成

- 属性エディタのカスタマイズ

- 属性エディタの編集に関する考慮事項

9.1 属性エディタについて

属性エディタは、次の3つの必須要素と2つのオプション要素で構成されます。

- WebCenter Sitesのインストール・ディレクトリに配置されているpresentationobject.dtdファイル(必須)。これは、フレックス属性とそれらのスタイル・タグのすべての使用可能な入力スタイル(プレゼンテーション・オブジェクト)を定義するDTDファイルです。

- 属性エディタ・アセット(必須)。属性エディタ・アセットは、このアセットが関連付けられている属性の入力オプションを提供するXMLコードを格納または参照しています。DTDで定義されたスタイル・タグを使用して、このXMLコードを作成します。

- 属性が「新規」フォームまたは「編集」フォームに表示される場合に、その属性を形式設定する(編集メカニズムを表示する)エレメント(必須)。このエレメントは、検索できるようElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリに配置される必要があります。その名前は、属性エディタからそれを呼び出すスタイル・タグの名前と一致する必要があります。

- 属性値が「調査」フォームに表示される場合に、その属性値を書式設定するエレメント(オプション)。このエレメントは、ElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリにも配置される必要があります。
このエレメントの名前は、DisplayStyleTagという書式に従っている必要があります。ここでStyleTagは、それを属性エディタから呼び出すスタイル・タグの名前を表し、このスタイル・タグの名前と完全に一致している必要があります。

- データベースに保存される前の属性データを書式設定するエレメント(オプション)。このエレメントは、ElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリにも配置される必要があります。
このエレメントの名前は、StyleTagFlexAssetGatherという書式に従っている必要があります。ここでStyleTagは、それを属性エディタから呼び出すスタイル・タグの名前を表し、このスタイル・タグの名前と完全に一致している必要があります。

WebCenter Sitesでは、属性エディタの開発をサポートするために次のアイテムがデフォルトで用意されています。

- presentationobject.dtdファイル。このファイルでは、属性エディタで使用できるいくつかの入力スタイル(プレゼンテーション・オブジェクト)が定義されています。したがって、このファイルに含まれている9個の入力スタイルでは不十分な場合を除いて、独自の入力スタイルを定義する必要はありません。

- 属性エディタ・アセットを作成するために使用できるサンプルXMLが含まれた9個のテキスト・ファイル。これらのサンプルXMLを作成する属性エディタ・アセットにカット・アンド・ペーストできます。これらのファイルは、インストール・ディレクトリのSamples/Attribute_Editorsに配置されています。

- 属性エディタ・アセットのサンプルXMLコードと組み合せて使用できる10個の表示エレメント。これらのエレメントは、ElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリに配置されています。

属性エディタを使用しない場合は、WebCenter Sitesでは、属性のデータ型に基づいてその属性のデフォルトの入力スタイルが使用されます。デフォルトのスタイルの詳細は、「属性のデフォルトの入力スタイル」を参照してください。属性エディタを作成するのは、デフォルトの入力スタイルが属性に対して十分でない場合にしてください。

詳細は、次の項を参照してください。

- presentationobject.dtdファイル

- 属性エディタ・アセット

- 属性エディタのエレメント

- 属性エディタのエレメントの規則

9.1.1 presentationobject.dtdファイル

presentationobject.dtdファイルでは、属性エディタを通じて実装できるすべての入力タイプ(プレゼンテーション・オブジェクト)が定義されています。デフォルトのpresentationobject.dtdファイルでは、9個の入力スタイル・タグと、これらのタグによって属性エディタから表示エレメントに渡すことができる引数が定義されています(「属性エディタのエレメント」を参照)。

次に、presentationobject.dtdファイルの全体を示します。これは、WebCenter Sitesのインストール・ディレクトリに配置されています。

<!-- PRESENTATIONOBJECT: An editor
-- PRESENTATIONOBJECT defines the presentation object for
-- instances of Gator attribute types. A presentation object
-- defines the properties of an editor for one of the following
-- controls: Text field, Text area, Pulldown menu
-- For additional information, refer to
-- com.openmarket.gator.interfaces.IPresentationObject.
-- You must specify one of TEXTFIELD, TEXTAREA, or PULLDOWN
-- elements.
-->
<!ELEMENT PRESENTATIONOBJECT (TEXTFIELD | TEXTAREA | PULLDOWN |
RADIOBUTTONS | CHECKBOXES | PICKASSET | FIELDCOPIER | DATEPICKER |
IMAGEPICKER | CKEDITOR | FCKEDITOR | IMAGEEDITOR | TYPEAHEAD |
UPLOADER)>
<!ATTLIST PRESENTATIONOBJECT NAME CDATA #REQUIRED>
<!-- TEXTFIELD: A text field of a specific width
-- You must specify the x dimension; the maximum number of
-- allowable characters defaults to 255.
-->
<!ELEMENT TEXTFIELD ANY>
<!ATTLIST TEXTFIELD XSIZE CDATA #IMPLIED>
<!ATTLIST TEXTFIELD WIDTH CDATA #IMPLIED>
<!ATTLIST TEXTFIELD MAXCHARS CDATA "255">
<!ATTLIST TEXTFIELD BLANKED (YES | NO) "NO">
<!ATTLIST TEXTFIELD MAXVALUES CDATA #IMPLIED>
<!-- TEXTAREA: A text area of a specific size
-- The wrap style defaults to soft.
-->
<!ELEMENT TEXTAREA ANY>
<!ATTLIST TEXTAREA XSIZE CDATA #IMPLIED>
<!ATTLIST TEXTAREA YSIZE CDATA #IMPLIED>
<!ATTLIST TEXTAREA WIDTH CDATA #IMPLIED>
<!ATTLIST TEXTAREA HEIGHT CDATA #IMPLIED><!ATTLIST TEXTAREA WRAPSTYLE (OFF | SOFT | HARD) "SOFT">
<!ATTLIST TEXTAREA DEPTYPE CDATA #IMPLIED>
<!ATTLIST TEXTAREA MAXVALUES CDATA #IMPLIED>
<!ATTLIST TEXTAREA RESIZE CDATA #IMPLIED>
<!-- PULLDOWN: A pulldown menu with an enumeration of items
-- You can specify zero or more list items; the fontsize defaults
-- to relative fontsize 3.
-->
<!ELEMENT PULLDOWN ((ITEM)* | QUERYASSETNAME)>
<!ATTLIST PULLDOWN FONTSIZE CDATA #IMPLIED>
<!-- RADIOBUTTONS: Radio buttons with an enumeration of items
-- You can specify zero or more list items; the fontsize defaults
to relative fontsize 3.
-->
<!ELEMENT RADIOBUTTONS ((ITEM)* | QUERYASSETNAME)>
<!ATTLIST RADIOBUTTONS FONTSIZE CDATA #IMPLIED>
<!ATTLIST RADIOBUTTONS LAYOUT (HORIZONTAL | VERTICAL) "VERTICAL">
<!-- CHECKBOXES: Check boxes with an enumeration of items
-- You can specify zero or more list items; the fontsize defaults
-- to relative fontsize 3.
-->
<!ELEMENT CHECKBOXES ((ITEM)* | QUERYASSETNAME)>
<!ATTLIST CHECKBOXES FONTSIZE CDATA #IMPLIED>
<!ATTLIST CHECKBOXES LAYOUT (HORIZONTAL | VERTICAL) "HORIZONTAL">
<!-- ITEM: A list item
-- You can specify zero or more characters of text.
-->
<!ELEMENT ITEM (#PCDATA)*>
<!-- SQL: Query to populate list of items
-- You can specify zero or more characters of text. Query must
-- return a 'value' column.
-->
<!ELEMENT QUERYASSETNAME (#PCDATA)*>
<!ELEMENT CKEDITOR ANY>
<!ATTLIST CKEDITOR ALLOWEDASSETTYPES CDATA #IMPLIED>
<!ATTLIST CKEDITOR SCRIPT CDATA #IMPLIED>
<!ATTLIST CKEDITOR IMAGEPICKERID CDATA #IMPLIED>
<!ATTLIST CKEDITOR IMAGEASSETTYPE CDATA #IMPLIED>
<!ATTLIST CKEDITOR TOOLBAR CDATA #IMPLIED>
<!ATTLIST CKEDITOR DEPTYPE CDATA #IMPLIED>
<!ATTLIST CKEDITOR WIDTH CDATA #IMPLIED>
<!ATTLIST CKEDITOR HEIGHT CDATA #IMPLIED>
<!ATTLIST CKEDITOR MAXVALUES CDATA #IMPLIED>
<!ATTLIST CKEDITOR RESIZE CDATA #IMPLIED>
<!ATTLIST CKEDITOR CONFIG CDATA #IMPLIED>
<!ATTLIST CKEDITOR CONFIGOBJ CDATA #IMPLIED>
<!-- Deprecated in Oracle WebCenter Sites 11gR1 release. -->
<!ELEMENT FCKEDITOR ANY>
<!ATTLIST FCKEDITOR XSIZE CDATA #IMPLIED>
<!ATTLIST FCKEDITOR YSIZE CDATA #IMPLIED>
<!ATTLIST FCKEDITOR LAZYLOAD CDATA #IMPLIED>
<!ATTLIST FCKEDITOR ALLOWEDASSETTYPES CDATA #IMPLIED>
<!ATTLIST FCKEDITOR SCRIPT CDATA #IMPLIED>
<!ATTLIST FCKEDITOR IMAGEPICKERID CDATA #IMPLIED>
<!ATTLIST FCKEDITOR TOOLBAR CDATA #IMPLIED>
<!ATTLIST FCKEDITOR DEPTYPE CDATA #IMPLIED>
<!ATTLIST FCKEDITOR WIDTH CDATA #IMPLIED>
<!ATTLIST FCKEDITOR HEIGHT CDATA #IMPLIED>
<!ATTLIST FCKEDITOR MAXVALUES CDATA #IMPLIED>
<!-- PICKASSET: When the tree is active, it's the "add from tree"
-- button.
-- When the tree is disabled, it's The Content Centre remember
-- widget. -->
<!ELEMENT PICKASSET ANY>
<!ATTLIST PICKASSET MAXVALUES CDATA #IMPLIED>
<!ATTLIST PICKASSET DISPLAYELEMENT CDATA #IMPLIED>
<!-- TYPEAHEAD: Type And Select the asset. -->
<!ELEMENT TYPEAHEAD ANY>
<!ATTLIST TYPEAHEAD MAXVALUES CDATA #IMPLIED>
<!ATTLIST TYPEAHEAD DISPLAYELEMENT CDATA #IMPLIED>
<!ATTLIST TYPEAHEAD PAGESIZE CDATA #IMPLIED>
<!-- UPLOADER: Upload a file from local disc. -->
<!ELEMENT UPLOADER ANY>
<!ATTLIST UPLOADER MAXVALUES CDATA #IMPLIED>
<!ATTLIST UPLOADER MAXFILESIZE CDATA #IMPLIED>
<!ATTLIST UPLOADER FILETYPES CDATA #IMPLIED>
<!ATTLIST UPLOADER MINWIDTH CDATA #IMPLIED>
<!ATTLIST UPLOADER MAXWIDTH CDATA #IMPLIED>
<!ATTLIST UPLOADER MINHEIGHT CDATA #IMPLIED>
<!ATTLIST UPLOADER MAXHEIGHT CDATA #IMPLIED>
<!-- FIELDCOPIER: A hidden field whose value is set from another
-- field.
-- ex. If you want an attribute whose value is always the name of
-- the asset:
-- <FIELDCOPIER SOURCEFIELD="name"/>
-->
<!ELEMENT FIELDCOPIER ANY>
<!ATTLIST FIELDCOPIER SOURCEFIELD CDATA #REQUIRED>
<!-- This describe the Date Picker -->
<!ELEMENT DATEPICKER ANY>
<!ATTLIST DATEPICKER COMPARETOFIELD CDATA #REQUIRED>
<!ATTLIST DATEPICKER MAXVALUES CDATA #IMPLIED>
<!-- This describe the ImagePicker -->
<!ELEMENT IMAGEPICKER ANY>
<!ATTLIST IMAGEPICKER ASSETTYPENAME CDATA #REQUIRED>
<!ATTLIST IMAGEPICKER ATTRIBUTETYPENAME CDATA #REQUIRED>
<!ATTLIST IMAGEPICKER ATTRIBUTENAME CDATA #REQUIRED>
<!ATTLIST IMAGEPICKER CATEGORYATTRIBUTENAME CDATA #IMPLIED>
<!ATTLIST IMAGEPICKER RESTRICTEDCATEGORYLIST CDATA #IMPLIED>
<!ATTLIST IMAGEPICKER MAXVALUES CDATA #IMPLIED>
<!-- Image Editor -->
<!ELEMENT IMAGEEDITOR ANY>
<!ATTLIST IMAGEEDITOR EDITORTYPE (oie | clarkii) "oie">
<!ATTLIST IMAGEEDITOR HEIGHT CDATA #REQUIRED>
<!ATTLIST IMAGEEDITOR WIDTH CDATA #REQUIRED>
<!ATTLIST IMAGEEDITOR FITIMAGE (true | false) "true">
<!ATTLIST IMAGEEDITOR SNAPSHOTPANEL (true | false) "false">
<!ATTLIST IMAGEEDITOR LIMITCROPPING (true | false) "false">
<!ATTLIST IMAGEEDITOR CROPHEIGHT CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR CROPWIDTH CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR ENABLEOIEFORMAT (true | false) "false">
<!ATTLIST IMAGEEDITOR LIMITSIZE (true | false) "false">
<!ATTLIST IMAGEEDITOR MAXHEIGHT CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR MAXWIDTH CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR MINHEIGHT CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR MINWIDTH CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR AUTORESAMPLE (true | false) "false">
<!ATTLIST IMAGEEDITOR AUTORESAMPLEPROPORTIONAL (true | false)
"false">
<!ATTLIST IMAGEEDITOR DEFAULTTEXTFONT CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR DEFAULTTEXTSIZE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR DEFAULTTEXTCOLOR CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR ASSETTYPE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR ATTRIBUTE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR ATTRIBUTETYPE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR CATEGORYATTRIBUTE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR RESTRICTEDCATEGORYLIST CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR ENABLEIMAGEPICKER (true | false) "false">
<!ATTLIST IMAGEEDITOR OIEASSETTYPE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR OIEATTRIBUTE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR OIEATTRIBUTETYPE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR OIECATEGORYATTRIBUTE CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR OIERESTRICTEDCATEGORYLIST CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR OIEENABLEIMAGEPICKER (true | false) "false">
<!ATTLIST IMAGEEDITOR TAGEDIT (true | false) "false">
<!ATTLIST IMAGEEDITOR BASE64JPEGQUALITY CDATA "95">
<!ATTLIST IMAGEEDITOR ASKTOSAVELOCALLY (true | false) "false">
<!ATTLIST IMAGEEDITOR DEFAULTSAVINGTYPE (gif | jpg | jpe | png |
tif | bmp | oie) "gif">
<!ATTLIST IMAGEEDITOR ENABLEGIFSAVING (true | false) "true">
<!ATTLIST IMAGEEDITOR ENABLEJPEGSAVING (true | false) "true">
<!ATTLIST IMAGEEDITOR ENABLEPNGSAVING (true | false) "true">
<!ATTLIST IMAGEEDITOR ENABLETIFFSAVING (true | false) "true">
<!ATTLIST IMAGEEDITOR ENABLEBMPSAVING (true | false) "true">
<!ATTLIST IMAGEEDITOR GRIDVISIBLE (true | false) "false">
<!ATTLIST IMAGEEDITOR GRIDSNAP (true | false) "true">
<!ATTLIST IMAGEEDITOR GRIDSPACINGX CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR GRIDSPACINGY CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR MAXTHUMBNAILHEIGHT CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR MAXTHUMBNAILWIDTH CDATA #IMPLIED>
<!ATTLIST IMAGEEDITOR THUMBNAILFORMAT (gif | jpg | jpe | png | tif
| bmp | oie) "gif">
<!ATTLIST IMAGEEDITOR MAXVALUES CDATA #IMPLIED>

デフォルトで使用可能になっているもの以外に、カスタム属性エディタを作成する場合は、まずXML入力スタイル・タグであるPRESENTATIONOBJECTタグをpresentationobject.dtdファイル内で定義する必要があります。新しいPRESENTATIONOBJECTタグを定義するには、次の操作を実行する必要があります。

- 新しいタグ(プレゼンテーション・オブジェクト)を<!ELEMENT PRESENTATIONOBJECT...>文内のリストに追加します。

- 新しいタグ(プレゼンテーション・オブジェクト)とこのタグが受け取る引数を定義する<!ELEMENT...>セクションを追加します。.dtdファイルの通常の構文ルールに従うとともに、presentationobject.dtdファイルで使用されている規則に従います。

9.1.2 属性エディタ・アセット

属性エディタ・アセットは、XMLコードを格納しているか、.xmlファイルを参照しています。そのXMLコードは、チェック・ボックス、ラジオ・オプション、ドロップダウン・リストなど、入力タイプのオプションの値を提供します。WebCenter Sitesでは、属性エディタ・アセットを作成するために使用できるサンプル・コードが含まれた9個のテキスト・ファイルが用意されていますが、属性エディタ・アセット自体は用意されていません。開発者は、どのオプションも使用するデータに適したものになるように、これらのサンプル・コードをカスタマイズする必要があるからです。

属性エディタを作成する場合は、本書のHTML版からコードをカット・アンド・ペーストするか(この項の後にいくつかのサンプルを掲載しています)、システム上のインストール・ディレクトリのSamplesサブディレクトリに配置されたテキスト・ファイルを使用します。

この項には次のトピックが含まれます:

- 構文とデフォルト・タグ

- CHECKBOXES

- CKEditor

- PICKASSET

- PULLDOWNの例

- RADIOBUTTONS

- TEXTAREA

- TEXTFIELD

- TYPEAHEAD

- UPLOADER

9.1.2.1 構文とデフォルト・タグ

属性エディタ・アセット内のコードは、次の基本形式に従っています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="SomeName">
...
...
...

</PRESENTATIONOBJECT>

入力スタイル(プレゼンテーション・オブジェクト)の形式を記述しているタグはPRESENTATIONOBJECTタグのペアの間に埋め込まれています。このタグ内には追加のネストされたタグを配置できます。NAME属性はPRESENTATIONOBJECTタグに必須ですが、この属性は将来使用するために予約されています。

属性エディタ・アセットのコード内に含めるすべてのPRESENTATIONOBJECTタグの名前は、presentationobject.dtdファイルで定義されている必要があります。この.dtdファイルでは、次のPRESENTATIONOBJECTタグがデフォルトで定義されています(アルファベット順に示します)。

- CHECKBOXES

- CKEDITOR

- DATEPICKER

- FIELDCOPIER

- IMAGEEDITOR

- IMAGEPICKER

- PICKASSET

- PICKFROMTREE (非推奨のためPICKASSETをかわりに使用)

- PULLDOWN

- RADIOBUTTONS

- TEXTAREA

- TEXTFIELD

- TYPEAHEAD

- UPLOADER

属性エディタのコード内で使用するPRESENTATIONOBJECTタグは、その属性エディタ用に使用する表示エレメントの名前と完全に一致している必要があります。したがって、カスタム属性エディタの新しいタグを定義するには、作成するエレメントにはそのタグと同じ名前を付ける必要があります。

エレメントの詳細は、「属性エディタのエレメント」を参照してください。属性エディタのコード・サンプルは、次の項を参照してください。

- CHECKBOXES

- CKEditor

- PICKASSET

- PULLDOWNの例

- RADIOBUTTONS

- TEXTAREA

- TEXTFIELD

- TYPEAHEAD

- UPLOADER

9.1.2.2 CHECKBOXES

presentationobject.dtdではCHECKBOXESタグが定義されています。このタグを使用する属性エディタはCHECKBOXESエレメントを呼び出し、このエレメントはその属性の一連のチェック・ボックスを作成します。

CHECKBOXESタグは、次のパラメータを受け取ります。

- ITEMまたはQUERYASSETNAME: チェック・ボックスの横に表示される名前のソース。名前を指定するには、ITEMパラメータを使用します。データベース表から動的に名前を取得する問合せアセットを指定するには、QUERYASSETNAMEパラメータを使用します。
次の点に注意してください。

- チェック・ボックスの横にリストされる名前のソースとしてITEMパラメータとQUERYASSETNAMEパラメータのどちらを使用するかとは関係なく、パラメータで複数の値が指定されていることを確認してください。単一の値の場合、チェック・ボックスのかわりにラジオ・ボタンが作成されます。

- 問合せを使用するには、問合せアセットを使用する必要があります。SQL文は使用できません。

- 問合せアセットのSQLでは、value列を返す必要があります。例: select name as value from shippingtype

- 属性エディタを使用する属性のデータ型がassetの場合、問合せではアセットのIDも返す必要があります。例: select name as value, id as assetid from Product where...

- LAYOUT: チェック・ボックスを垂直リストの形式で配置するのか水平方向に一列に並べるのかを指定します。有効なオプションは、HORIZONTALまたはVERTICALです。デフォルトはHORIZONTALです。

- MAXVALUES: 1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

次の属性エディタ・コードでは、CHECKBOXESエレメントがA Prodsという名前の問合せアセットの結果をチェック・ボックスの垂直リストの名前として使用することを指定しています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CheckBox">
<CHECKBOXES LAYOUT="VERTICAL">
<QUERYASSETNAME>A Prods</QUERYASSETNAME>
</CHECKBOXES>
</PRESENTATIONOBJECT>

ITEMパラメータの使用例を示すサンプル・コードについては、「PULLDOWNの例」を参照してください。

データ型に関する注意:

CHECKBOXES属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset (assetの場合、アセット名を返す問合せアセットの名前を指定する必要があります。)

9.1.2.3 CKEditor

presentationobject.dtdではCKEDITORタグが定義されています。このタグを使用する属性エディタはCKEDITORエレメントを呼び出し、このエレメントはCKEditorを起動します。フレックス・アセットの作成者は、属性の値をそのウィンドウで入力します。

- CKEditorアプリケーションをインストールして正しく構成している必要があります。

- CKEditorは、属性のデータ型がblobに設定されている場合にのみ使用することを強くお薦めします。blobデータ型のフィールドのサイズ設定については気にする必要がありません。

CKEDITORタグは、次のパラメータを受け取ります。

次のコードには、幅が400ピクセルで高さが200ピクセルのテキスト・ボックスを作成するCKEDITORタグが含まれています。

- EMBEDDEDLINKS: YES値の場合、ユーザーは他のアセットへのリンクを作成できます。デフォルト値: NO。

- ALLOWEDASSETTYPES: CKEditorを通じて組込み可能またはリンク可能なアセット・タイプを指定できます。デフォルト値: ALL。

- DEPTYPE: メイン・アセットと埋込みアセットの間の承認依存性。有効なオプションは、EXISTSとEXACTです。デフォルト値: EXACT。

- MAXVALUES: このパラメータは、1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

- MAXLENGTH: (CKEditorの「ソース」ボタンをクリックすると表示される) CKEditorのソース・ビュー内の文字数。デフォルト値: -1 (無制限)。

- INSTRUCTION: フィールドのヘルプを提供するために使用されます。

CKEDITORタグは、CKEditorインスタンスの外観をカスタマイズするためのパラメータも受け取ります。1組のパラメータ・セットがWebCenter Sitesに定義されています。他のセットは、CKEditor Webサイトにあります。

WebCenter Sitesに定義されているパラメータは、CKEditorインスタンスのXMLフィールドに直接追加する必要があります。

- TOOLBAR: ツールバーの名前。CONFIGパラメータで指定された構成ファイルから読み取られます。たとえば、CONFIG="myconfig.js"です。

- WIDTH: テキスト・ボックスの幅(ピクセル単位)。WIDTHの値を指定しない場合、WebCenter Sitesによってデフォルトの幅が設定されます。サンプル値: 700px。

- HEIGHT: テキスト・ボックスの高さ(ピクセル単位)。HEIGHTの値を指定しない場合、WebCenter Sitesによってデフォルトの高さが設定されます。サンプル値: 300px。

注意:

WIDTHおよびHEIGHTパラメータは、非推奨のXSIZEおよびYSIZEパラメータに替わるものです。XSIZEおよびYSIZEを設定しても無効です。

- RESIZE: trueの場合、ユーザーはテキスト・エリアをサイズ変更できます。デフォルト値: false。

CKEditor Webサイトに表示されるパラメータは、CONFIGパラメータ内で指定されている構成ファイル、またはCONFIGOBJパラメータで指定されている必要があります。TOOLBARパラメータを除いて、それらがCKEditorのXMLフィールドに追加された場合、認識されません。CONFIGパラメータおよびCONFIGOBJパラメータの説明は次のとおりです。

- CONFIG: デフォルトまたはカスタムのCKEditor構成ファイルへの相対パスを指定します。たとえば、CONFIG="myconfig.js"と設定すると、CKEditorベース・パス(CKEditorソース・フォルダ)からカスタムのmyconfig.jsファイルがロードされます。カスタム構成ファイルの場合、ユーザーはCONFIG属性でconfig.jsファイルのURLを指定することもできます。ベース・パスは、wcs_properties.jsonファイルのxcelerate.ckeditor.basepathプロパティで定義されています。
構成ファイル内にCKEDITOR.editorConfig関数があります。ここで、http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.html#.editorConfigに表示されるCKEditorパラメータを指定します。パラメータのリストには、TOOLBARパラメータが含まれます。

- CONFIGOBJ: JSON文字列を取ります。これには、http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.htmlに表示されるどのパラメータも含めることができます。(このリストには、TOOLBARパラメータが含まれます。)
JSON文字列のフォーマットでは、二重引用符が使用されます。

'{foo1:"value1",foo2:"value2"}' ...

次に例を示します。

CONFIGOBJ='{width:"300px",height:"300px",toolbar:"SITES",fullPage:true}'

注意:

CKEditorパラメータは、次のような階層的順序で認識され、使用されます。

CKEditorのXMLフィールド内のパラメータは、CONFIGOBJ内のパラメータをオーバーライドします。CONFIGOBJ内のパラメータは、CONFIGパラメータで指定されている構成ファイル内のパラメータをオーバーライドします。たとえば、CKEditorのXMLフィールド内のTOOLBARパラメータは、CONFIGOBJ='{toolbar: "SITES",fullPage:true}'内のtoolbarパラメータをオーバーライドします。このtoolbarパラメータは、(CONFIG='myconfig.js'として指定されている)構成ファイルmyconfig.js内のtoolbarパラメータをオーバーライドします。CONFIGOBJ内のfullPageパラメータは、myconfig.js内の同じパラメータをオーバーライドします。

競合が発生する可能性を回避するには、各パラメータを、それが認識される場所(エディタのXMLフィールド、CONFIGOBJパラメータ、またはCONFIGパラメータで指定されている構成ファイルのいずれか)で1回のみ指定します。

次のコードには、幅が400ピクセルで高さが200ピクセルのCKEditorボックスを作成するCKEDITORタグが含まれています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="CKEditorTest">
<CKEDITOR WIDTH="400px" HEIGHT="200px">
</CKEDITOR>
</PRESENTATIONOBJECT>

データ型に関する注意:

CKEDITOR属性エディタを使用する属性のデータ型として最適なのはblobです。stringやtextも使用できますが、その場合は問題があります。個々のHTMLマーカーはサイズ制限の対象としてカウントされるため、属性のフィールドに入力されるデータのサイズを予測するのが難しいからです。stringデータ型は256文字に制限されており、textのデータ型は2000文字に制限されています。そのため、CKEDITORを入力メカニズムとして使用する属性のデータ型にはblobを使用することをお薦めします。

9.1.2.4 PICKASSET

presentationobject.dtdではPICKASSETタグが定義されています。このタグを使用する属性エディタはPICKASSETエレメントを呼び出します。このエレメントは、ユーザーがツリーまたは検索結果リストからアセットをドラッグ・アンド・ドロップできる「ドロップ・ゾーン」フィールドを作成します。アセットが「ドロップ・ゾーン」フィールドにドロップされると、破線の境界線で囲まれたボックス内にアセットの名前が表示されます。アセットの名前をポイントすると、ツールチップが開いて、アセットに関する情報が表示されます。ツールチップのルック・アンド・フィールをカスタマイズするなど、PICKASSET属性エディタの動作を変更するには、「属性エディタの構築」を参照してください。

このタグは、MAXVALUESパラメータをとることができます。MAXVALUESパラメータは、1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

PICKASSET属性エディタのカスタマイズの詳細は、「属性エディタの構築」を参照してください。

次に、PICKASSET属性エディタを作成するためのコードを示します。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="PickAsset">

<PICKASSET>
</PICKASSET>
</PRESENTATIONOBJECT>

データ型に関する注意:

PICKASSET属性エディタは、assetのデータ型の属性にのみ適しています。

9.1.2.5 PULLDOWNの例

presentationobject.dtdではPULLDOWNタグが定義されています。このタグを使用する属性エディタはPULLDOWNエレメントを呼び出し、このエレメントは値のドロップダウン・リストが付随するフィールドを形式設定します。

このタグは、ドロップダウン・リスト内の名前のソースであるITEMまたはQUERYASSETNAMEパラメータをとります。名前を指定するには、ITEMパラメータを使用します。データベース表から動的に名前を取得する問合せアセットを指定するには、QUERYASSETパラメータを使用します。

次の点に注意してください。

- 問合せを使用するには、問合せアセットを使用する必要があります。SQL文は使用できません。

- 問合せアセットのSQLでは、value列を返す必要があります。例: select name as value from shippingtype

- 属性エディタを使用する属性のデータ型がassetの場合、問合せではアセットのIDも返す必要があります。例: select name as value, id as assetid from Product where...

- 日付オプションを含める場合、これらはYYY-MM-DD HH:MM:SSの形式である必要があります。

次の属性エディタ・コードでは、リストにRed、GreenおよびBlueというアイテムが含まれることを指定しています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="PulldownTest">
<PULLDOWN>
<ITEM>Red</ITEM>
<ITEM>Green</ITEM>
<ITEM>Blue</ITEM>
</PULLDOWN>

ITEMのかわりにQUERYASSETNAMEパラメータを使用する方法を示すサンプル・コードについては、「CHECKBOXES」を参照してください。

データ型に関する注意:

PULLDOWN属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset

ドロップダウン・リストは、asset型の属性のデフォルトの入力スタイルです。このリストには、その型のすべてのアセットが表示されます。問合せアセットを使用してドロップダウン・リスト内のアイテムをさらに制限し、リストにその型のすべてのアセットが表示されないようにするには、PULLDOWN属性エディタを使用します。

9.1.2.6 RADIOBUTTONS

presentationobject.dtdではRADIOBUTTONSタグが定義されています。このタグを使用する属性エディタはRADIOBUTTONSエレメントを呼び出し、このエレメントはその属性の一連のラジオ・オプションを作成します。

RADIOBUTTONSタグは、次のパラメータを受け取ります。

- ITEMまたはQUERYASSETNAME: ラジオ・ボタンの横に表示される名前のソース。名前を指定するには、ITEMパラメータを使用します。データベース表から動的に名前を取得する問合せアセットを指定するには、QUERYASSETパラメータを使用します。
次の点に注意してください。

- 問合せを使用するには、問合せアセットを使用する必要があります。SQL文は使用できません。

- 問合せアセットのSQLでは、value列を返す必要があります。例: select name as value from shippingtype

- 属性エディタを使用する属性のデータ型がassetの場合、問合せではアセットのIDも返す必要があります。例: select name as value, id as assetid from Product where...

- LAYOUT: ボタンを垂直リストの形式で配置するのか水平方向に一列に並べるのかを指定します。有効なオプションは、HORIZONTALまたはVERTICALです。デフォルトはHORIZONTALです。

次の属性エディタ・コードでは、RADIOBUTTONSエレメントがA Prodsという名前の問合せアセットの結果をボタンの垂直リストの名前として使用することを指定しています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="RadioButtonTest">
<RADIOBUTTONS LAYOUT="VERTICAL">
<QUERYASSETNAME>A Prods</QUERYASSETNAME>
</RADIOBUTTONS>
</PRESENTATIONOBJECT>

ITEMパラメータの使用例を示すサンプル・コードについては、「PULLDOWNの例」を参照してください。

データ型に関する注意:

RADIONBUTTON属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset (assetの場合、アセット名を返す問合せアセットの名前を指定する必要があります。)

注意:

date型のRadioButton属性エディタは、presentation.dtdのサーバーのタイムゾーン(またはJVMで設定されているタイムゾーン)に入力された日付値を解釈します。この値は、アセット・フォームのレンダリング時に、ユーザーのタイムゾーンに変換されます。

タイムゾーンに関係なく同じ日付値を表示するには、string型の属性エディタの使用を検討してください。

9.1.2.7 TEXTAREA

presentationobject.dtdではTEXTAREAタグが定義されています。このタグを使用する属性エディタはTEXTAREAエレメントを呼び出し、このエレメントは、その属性のテキスト・ボックス・フィールドと、一対のラジオ・ボタンを作成します。ユーザーはこれらのラジオ・ボタンを使用して、その属性によって埋込みリンク・ボタンを表示するかどうかを指定できます。

TEXTAREAタグは、次のパラメータを受け取ります。

- WIDTH: テキスト・ボックスの幅(ピクセル単位)。WIDTHの値を指定しない場合、WebCenter Sitesによってデフォルトの幅が設定されます。サンプル値: 700px。

- HEIGHT: テキスト・ボックスの高さ(ピクセル単位)。HEIGHTの値を指定しない場合、WebCenter Sitesによってデフォルトの高さが設定されます。サンプル値: 300px。

注意:

WIDTHおよびHEIGHTパラメータは、非推奨のXSIZEおよびYSIZEパラメータに替わるものです。XSIZEおよびYSIZEを設定しても無効です。

- RESIZE: trueの場合、ユーザーはテキスト・エリアをサイズ変更できます。デフォルト値はfalseです。

- WRAPSTYLE: ボックス内のテキストを折り返すかどうかを指定します。折り返す場合は、自動的に折り返すのか(ソフト)、ユーザーが[Enter]キーを押したときにのみ折り返すのか(ハード・リターン)を指定します。有効なオプションは、SOFT、HARDおよびOFFです。デフォルトは、OFFです。

- DEPTYPE: メイン・アセットと埋込みアセットの間の承認依存性。有効なオプションは、EXISTSとEXACTです。デフォルトはEXACTです。

- EXISTS: メイン・アセットが編集、承認および再パブリッシュされたときに、いずれかのバージョンの埋込みアセットがパブリッシュ先にすでに存在している場合は、埋込みアセットが承認および再パブリッシュされる必要はありません。

- EXACT: メイン・アセットが編集、承認および再パブリッシュされたときに、埋込みアセットが編集されていた場合は、埋込みアセットも承認および再パブリッシュされる必要があります。

- MAXVALUES: 1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

次の属性エディタ・コードでは、XSIZEを40ピクセルに、YSIZEを5ピクセルに設定し、WRAPSTYLEをOFFに設定してテキストの折返しを無効にし、埋込みアセットの承認依存性をEXISTSに設定しています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="TextAreaTest">
<TEXTAREA XSIZE="40" YSIZE="5" WRAPSTYLE="OFF" DEPTYPE="EXISTS">
</TEXTAREA>
</PRESENTATIONOBJECT>

データ型に関する注意:

TEXTAREA属性エディタは、textおよびblobのデータ型の属性に適しています。2,000文字以下を格納する必要がある場合は、textのデータ型を使用します。2,001文字以上を格納するには、blobのデータ型を使用します。

9.1.2.8 TEXTFIELD

presentationobject.dtdではTEXTFIELDタグが定義されています。このタグを使用する属性エディタは「新規」フォームと「編集」フォームからTEXTFIELDエレメントを呼び出し、その属性のテキスト・フィールドを作成します。ただし、その属性が「調査」フォームに表示される場合は、その属性エディタはDisplayTEXTFIELDエレメントを使用します。

TEXTFIELDタグは、次のパラメータを受け取ります。

- XSIZE: フィールドの長さ(文字数)。

- MAXCHARS: フィールドに入力できる文字数(最大256文字)。

- BLANKED: 属性の値が「調査」フォームに表示される場合に、その値を一連のアスタリスクに置き換えるかどうかを指定します。たとえば、password属性の場合、パスワードの値が「調査」フォームに表示されないようにする必要があります。有効なオプションは、YESおよびNOです。デフォルトはNOです。
BLANKEDパラメータを使用すると自動的に、そのフィールドは「新規」フォームと「編集」フォーム上では「調査」フォーム上とは異なる動作を示すことが必要になるため、TEXTFIELDタグはデフォルトで2つの使用可能なエレメントの両方とともに提供されています。

- MAXVALUES: 1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

次の属性エディタ・コードでは、XSIZEを60に設定して、最大文字数を80に設定しています。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="TextFieldTest">
<TEXTFIELD XSIZE="60" MAXCHARS="80">
</TEXTFIELD>
</PRESENTATIONOBJECT>

データ型に関する注意:

TEXTFIELD属性エディタは、次のデータ型の属性に適しています。

- float

- integer

- money

- string

- url

9.1.2.9 TYPEAHEAD

presentationobject.dtdではTYPEAHEADタグが定義されています。このタグを使用する属性エディタはTYPEAHEADエレメントを呼び出し、このエレメントはドロップダウン・メニュー属性を持つ先行入力の入力ボックスを作成します。属性がアセットの「新規」および「編集」ビューに表示され、ドロップダウン・フィールドの下矢印がクリックされると、ドロップダウン・メニューに、ユーザーが選択できるアセットの名前が表示されます。

TYPEAHEADタグは、次のパラメータを受け取ります。

- PAGESIZE: 先行入力検索でドロップダウン・メニューに一度に表示される結果の数を制限します。たとえば、PAGESIZEが5に設定された場合、ドロップダウン・メニューに一度に表示されるアセットの数は5つのみです。デフォルト値は10です。

- MAXVALUES: 1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

PAGESIZEパラメータを使用して、ドロップダウンに一度に表示される結果の数を制限できます。これにより、ドロップダウン・メニューに表示される結果がページ分けされます。たとえば、PAGESIZEパラメータを、ドロップダウン・メニューに一度に10件のアセットが表示されるように設定した場合、ユーザーは、「次の選択肢」をクリックして次の10件のアセットを表示できます。同様に、表示された直前の10件のアセットに戻るには、「前の選択肢」リンクをクリックします。

結果のリストは、入力ボックスに、アセットの最初の数文字を入力することでフィルタ処理することもできます。たとえば、入力ボックスにSkiと入力すると、ドロップダウン・メニューに表示される結果はすべてSkiで始まります(アルファベット順)。これは、Ski*という問合せの実行に類似しており、Skiという文字または言葉で始まるすべてのアセットが検出されます。先行入力の入力ボックスに入力すると、図9-1に示すように、ドロップダウン・メニューの最初の結果が自動的に入力されます。

図9-1 「関連コンテンツ」ダイアログ

自動的に入力されたアセットを選択するには、キーボードの[Enter]を押します。ユーザーは、(キーボードの上矢印と下矢印を使用してドロップダウン・メニュー内を移動して)アセットを選択し、[Enter]キーを押すか、マウスを使用してアセットをクリックすることで、ドロップダウン・メニューから一度に1つの任意の結果を選択することもできます。アセットを選択すると、ドロップダウン・メニューの下にそのアセットが表示されます。ユーザーが選択したアセットをポイントすると、図9-2に示すように、ツールチップが表示されます。

図9-2 ツールチップ・メッセージ

ツールチップのルック・アンド・フィールをカスタマイズするなど、TYPEAHEAD属性エディタの動作を変更するには、「属性エディタの構築」を参照してください。

データ型に関する注意:

TYPEAHEAD属性エディタは、assetのデータ型の属性にのみ適しています。

9.1.2.10 UPLOADER

presentationobject.dtdではUPLOADERタグが定義されています。このタグを使用する属性エディタはUPLOADERエレメントを呼び出し、このエレメントはアップロード属性を作成します。「アップロード」フィールドは、任意のタイプのファイルをアップロードできます。ただし、アップロードできるファイルのタイプを制限するには、FILETYPESパラメータを使用します。

ユーザーがファイルのアップロードをクリックすると、図9-3に示すように、アップロードの進行状況がアセットのツールバーに表示されます。

図9-3 アップロードの進行状況

アップロードされた各ファイルのサムネイル・イメージがアップローダ・フィールドに表示されます。ユーザーがアップロードされたイメージ・ファイルのサムネイルをクリックすると、イメージは実際のサイズでオーバーレイに表示されます。イメージ以外のファイル・タイプの場合、WebCenter Sitesでは、アップローダ・フィールド内のファイル・タイプに固有のサムネイル・イメージが表示されます。特定のファイル・タイプに固有のサムネイル・イメージが使用できない場合、任意のイメージがかわりに表示されます。

ユーザーがイメージ・ファイルのサムネイル・イメージをポイントすると、そのファイルの名前、タイプおよび大きさがツールチップに表示されます。ファイルの名前およびタイプは、図9-4に示すように、イメージではないファイルのツールチップに表示されます。

図9-4 イメージのツールチップ

UPLOADERタグは、次のパラメータを受け取ります。

- MAXFILESIZE: アップロード可能なファイルの最大サイズを指定します。このパラメータの有効な単位は、B、KB、MBおよびGBです。デフォルト値: 1024KB。デフォルト単位: KB。

- FILETYPES: アップロード可能なファイルのタイプを指定します。たとえば、*.jpg*と指定します。このパラメータの値を指定しない場合、デフォルト値は任意のタイプ(*.*)になります。

- MINWIDTH: アップロード可能なファイルの最小の幅(ピクセル単位)を指定します。たとえば、MINWIDTHを700pxに設定した場合、ユーザーは、700px以上の幅を持つファイルのみをアップロードできます。このパラメータの値を指定しない場合、デフォルト値は任意の幅になります。有効な単位: px。

- MAXWIDTH: アップロード可能なファイルの最大の幅(ピクセル単位)を指定します。たとえば、MAXWIDTHを700pxに設定した場合、ユーザーは、700px以下の幅を持つファイルのみをアップロードできます。このパラメータの値を指定しない場合、デフォルト値は任意の幅になります。有効な単位: px。

- MINHEIGHT: アップロード可能なファイルの最小の高さ(ピクセル単位)を指定します。たとえば、MINHEIGHTを700pxに設定した場合、ユーザーは、700px以上の高さを持つファイルのみをアップロードできます。このパラメータの値を指定しない場合、デフォルト値は任意の高さになります。有効な単位: px。

- MAXHEIGHT: アップロード可能なファイルの最大の高さ(ピクセル単位)を指定します。たとえば、MAXHEIGHTを700pxに設定した場合、ユーザーは、700px以下の高さを持つファイルのみをアップロードできます。このパラメータの値を指定しない場合、デフォルト値は任意の高さになります。有効な単位: px。

- MAXVALUES: 1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです。デフォルト値はありません。

データ型に関する注意:

UPLAODER属性エディタは、blobのデータ型の属性にのみ適しています。

9.1.3 属性エディタのエレメント

対応する属性エディタから渡される入力値を受け取るエレメントは、フォームに表示されるときの対象属性の形式と動作のベースとなるロジックを提供します。たとえば、このロジックは、追加の値をフィールドに入力可能にするために、複数値属性のループ・シーケンスを実行する場合があります。

表9-1に、ElementCatalog表のOpenMarket/Gator/AttributeTypesに配置されているデフォルトのフレックス属性表示エレメントを示します。これらのエレメントの名前は、presentationobject.dtdファイルで定義されているカスタムXMLタグの名前と完全に一致しています。

表9-1 属性エディタのエレメント

エレメント

説明

CHECKBOXES

属性の入力スタイルを一連のチェック・ボックス・オプションとして形式設定します。属性エディタは、これらのオプションの名前を指定するか、これらの名前を取得するために使用する問合せアセットの名前を指定する必要があります。

CKEDITOR

CKEditorテキスト・エディタを呼び出します。属性エディタは、テキスト・ボックスの高さと幅のピクセル数を指定する必要があります。

PULLDOWN

属性の入力スタイルをドロップダウン・リスト付きの選択フィールドとして形式設定します。属性エディタは、リストに表示されるアイテムを指定するか、それらの値を取得するために使用する問合せアセットの名前を指定する必要があります。

RADIOBUTTONS

属性の入力スタイルを一連のラジオ・オプションとして形式設定します。属性エディタは、これらのオプションの名前を指定するか、これらの名前を取得するために使用する問合せアセットの名前を指定する必要があります。

TEXTAREA

属性の入力スタイルをテキスト・ボックスとして形式設定して、このテキスト・ボックスで埋込みリンクが許可されるかどうかをユーザーが指定するためのラジオ・ボタンを表示します。属性エディタは、このボックスのX軸方向とY軸方向のサイズを指定する必要があります。

TEXTFIELD

属性の入力スタイルをテキスト・フィールドとして形式設定します。属性エディタは、このフィールドの長さと入力可能な文字数を指定する必要があります。

DisplayTEXTFIELD

「調査」フォームに表示されるときのテキスト・フィールド属性値の表示形式を設定します。属性エディタがBLANKEDパラメータをYESに設定した場合は、このエレメントはフィールドの値を一連のアスタリスクとして表示します。通常は、パスワード・フィールド用に使用されます。

PICKASSET

属性の入力スタイルを、ユーザーがツリーまたは検索結果リストからアセットをドラッグ・アンド・ドロップできる「ドロップ・ゾーン」フィールドとして形式設定します。

PICKFROMTREE

非推奨。PICKASSETを使用してください。

TYPEAHEAD

属性の入力スタイルをドロップダウン・メニュー付きの先行入力の入力ボックスとして形式設定します。アセットがアセットの「新規」または「編集」ビューに表示され、ドロップダウン・フィールドの下矢印がクリックされると、ドロップダウン・メニューに、ユーザーが選択できるアセットの名前が表示されます。ドロップダウン・メニューに一度に表示される結果の数を制限するには、PAGESIZEパラメータを使用します。

UPLOADER

upload属性を作成します。アップロード・フィールドは、任意のタイプのファイルをアップロードできます。アップロードできるファイルのタイプを制限するには、FILETYPESパラメータを使用します。

9.1.4 属性エディタのエレメントの規則

WebCenter Sitesでは、属性エディタのエレメントが次の規則に従っている場合、このエレメントを使用できます。

- そのエレメントの名前は、属性エディタ・コードからそのエレメントをコールする入力スタイル・タグと同じ名前である必要があります。たとえば、デフォルトのCHECKBOXESタグはデフォルトのCHECKBOXES.xmlエレメントを持っています。

- そのエレメントは、OpenMarket/Gator/AttributeTypes/nameというネーミング規則に従ってElementCatalog内に配置されている必要があります。

カスタム属性エディタの独自の表示エレメントを作成するには、作成する属性エディタ・エレメントに最も類似しているエレメントを見つけてから、そのエレメントのできるかぎり多くの内容をコピーします。参考のために、デフォルトの属性エディタ・エレメント内のコードを調べて、これらのエレメント内の変数と構文に関する次の説明を参照してください。

変数:

WebCenter Sitesは、属性エディタを使用するフォームをロードするときに、そのコンピュータ名を持つエレメントをコールします。次の変数内の情報を表示エレメントに渡します。

- PresInst: 現在のプレゼンテーション・オブジェクトのインスタンス。

- AttrName: 現在の属性の名前。

- AttrType: 現在の属性のデータ型。

- EditingStyle: 属性が複数の値を持つことができるかどうかを指定します(属性の「値の数」フィールドの値に基づく)。この変数は、singleまたはmultipleに設定します。

- RequiredAttr: 属性が現在のアセットに対して必須であるかどうかを指定します。この変数は、trueまたはfalseに設定します。

- MultiValueEntry: 複数の値を持つことができる属性の値を処理する方法をWebCenter Sitesに指示します。
この値をyesに設定した場合、表示エレメントによって作成されたウィジェットはユーザーがそのウィジェット内で複数の値を選択することを可能にするという想定の下で(複数選択ドロップダウン・リストなど)、表示エレメントが1度コールされます。

この値をnoに設定した場合、WebCenter Sitesは、その属性の考えられる値ごとに表示エレメントを1度コールして、格納できる値ごとに1つのウィジェットを表示します。

この値は常にyesに初期設定されています。

- doDefaultDisplay: この型の属性のデフォルトの入力スタイルを使用するかどうかを指定します。リストについては、「属性のデフォルトの入力スタイル」を参照してください。WebCenter Sitesが表示エレメントをコールする場合、この変数は最初にyesに設定されます。エレメントによって作成された入力ウィジェットを使用するには、このエレメントでこの変数をnoにリセットする必要があります。

- AttrValueList: この属性のすべての値のリスト。

- TempVal: 単一属性値の値。

他の必須の構文:

表示エレメント内のコードは、次の規則にも従う必要があります。

- 属性値を検証する方法に関する情報をRequireInfoという名前の変数に格納する必要があります。WebCenter Sitesは、この変数を、JavaScriptを使用して属性値を検証するエレメントに渡します。これらのエレメントは次のとおりです。

OpenMarket/Gator/FlexibleAssets/FlexAssets/ContentForm1
OpenMarket/Gator/FlexibleAssets/FlexGroups/ContentForm1

このJavaScriptは、コントロールのタイプ、データ型および他の予測可能な特性に基づいて既定のエラー・チェックと検証を実行します。RequireInfo変数に格納して渡される情報を通じて、属性エディタのカスタム要件がこのJavaScriptに通知されます。

- 表示エレメント内のウィジェットの名前は(INPUT NAME)、次の規則に従っている必要があります。

- 単一値属性の場合は、この属性の名前と同じである必要があります。

- 複数値属性の場合は、各属性値について1から始まるカウンタ値が属性名の先頭に付加される必要があります(例: 1color、2color、3color)。

例については、「属性エディタのカスタマイズ」を参照してください。

9.2 属性エディタの作成

この章やサンプル・テキスト・ファイルに掲載されているサンプルXMLコードを使用して属性エディタを作成するには:

1. Adminインタフェースを開きます。

2. 「新規」をクリックして、ショートカット・リストから新規属性エディタを選択します。

「属性エディタ」フォームが開きます(図9-5)。

図9-5 「属性エディタ」ダイアログ

3. 「名前」フィールドで、最大64文字(空白は除く)の一意の名前を入力します。

4. 「説明」フィールドで、この属性エディタの目的を簡潔に記述します。

5. 「XML」フィールドで、本書のHTML版から、またはインストール・ディレクトリのSamplesサブディレクトリにあるサンプル・テキスト・ファイルから、適切なサンプルXML属性エディタ・コードを貼り付けます。

6. コードを必要に応じて編集します。たとえば、CHECKBOXESまたはRADIOBUTTONSの属性エディタの場合、これらのチェック・ボックスまたはラジオ・ボタンの名前を指定する必要があります。PULLDOWN属性エディタを作成する場合は、このドロップダウン・リストの値を指定する必要があります。

属性エディタのコーディングの詳細は、「属性エディタ・アセット」を参照してください。

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

注意:

もう1つの方法は、属性エディタのXMLを別個の.xmlファイル内にコーディングすることです。この場合は、コードを「XML」フィールドに直接入力するかわりに、「ファイル内のXML」フィールドの横にある「参照」をクリックして、そのファイルを選択します。

8. この属性エディタを管理システムに対してパブリッシュできるように、この属性エディタを承認します。

注意:

この属性エディタで問合せアセットを使用する場合は、この属性エディタとその問合せアセットの両方を必ず承認してください。

属性エディタとその問合せアセットの間の依存性は、その属性エディタ内のXMLコードで指定されるため、承認システムは、その依存性を検知することはできず、その問合せアセットが管理システム上に存在することを確認できません。

9.3 属性エディタのカスタマイズ

独自のカスタム属性エディタを作成するための最適な方法は、サンプルの属性エディタ・コードとサンプルの表示エレメントからできるかぎり多くの内容をコピーすることです。

新しい入力スタイルを作成するには(いずれのデフォルトPRESENTATIONOBJECTタグも使用できません)、属性エディタを定義するpresentationobject.dtdファイルに新しいPRESENTATIONOBJECTセクションを追加する必要があります。このファイルへの追加の詳細は、「presentationobject.dtdファイル」を参照してください。

カスタムのPRESENTATIONOBJECTタグを作成する場合は、このタグに対して次のような適切な表示エレメントも提供する必要があります。

- 必須: 属性が「新規」フォームまたは「編集」フォームに表示される場合に、その属性を形式設定する(編集メカニズムを表示する)エレメント。

- オプション: 属性が「調査」フォームに表示される場合に、その属性を形式設定するエレメント。

- オプション: データベースに保存される前の属性データを形式設定するエレメント。

属性エディタの表示エレメントで使用される変数と規則については、「属性エディタのエレメント」を参照してください。

ファイルをアップロードできる属性エディタを作成またはカスタマイズするには(たとえば、UPLOADER属性エディタをカスタマイズする場合)、アップロード対象のファイルが有効であることを確認するカスタム・ロジックを属性エディタ・コードに追加します。詳細は、「アップロード対象のファイルを検証するためのカスタム・ロジックの追加」を参照してください。

9.3.1 例: カスタマイズされた属性エディタ

この例では、ユーザーが適切な権限を持っていない場合にテキスト・ボックスを使用不能にする属性エディタを作成するために、presentationobject.dtdファイル内のTEXTAREAタグの記述内容およびTEXTAREAエレメントをカスタマイズする方法を示します。

この作業は次の3つのステップからなります。

- 手順1: presentationobject.dtd内のTEXTAREAタグの記述内容を編集して、PERMISSIONSという名前の新しいパラメータをサポートします。

- 手順2: 属性エディタのコードを記述して、属性エディタを作成します。

- 手順3: PERMISSIONSの値をチェックするようにTEXTAREAエレメントを編集します。

9.3.1.1 手順1: presentationobject.dtdファイルの編集

新しいパラメータをサポートするには、presentationobject.dtd内のTEXTAREAの記述内容に1つのコード行を追加します。

- 次のコードに示すように、TEXTAREAタグのデフォルトの説明の終わりに新しい行を追加します。

<!-- TEXTAREA: A text area of a specific size. You must specify
-- the x and y dimensions; the wrap style defaults to soft.
-->
<!ELEMENT TEXTAREA ANY>
<!ATTLIST TEXTAREA XSIZE CDATA #REQUIRED>
<!ATTLIST TEXTAREA YSIZE CDATA #REQUIRED>
<!ATTLIST TEXTAREA WRAPSTYLE (OFF | SOFT | HARD) "SOFT">
<!ATTLIST TEXTAREA PERMISSION CDATA>

9.3.1.2 手順2: 属性エディタの例に対する権限の指定

ここでは、新しいパラメータを使用したサンプル・コードを示します。

- 次のコードに示すように、フィールドを表示するためにPERMISSIONの値としてAdministratorsがユーザーに割り当てられている必要があることを指定します。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">

<PRESENTATIONOBJECT NAME="TextAreaTest">
<TEXTAREA XSIZE="40" YSIZE="10" WRAPSTYLE="SOFT" PERMISSION="Administrators">
</TEXTAREA>
</PRESENTATIONOBJECT>

9.3.1.3 手順3: TEXTAREAエレメントの編集

3つ目のステップはTEXTAREAエレメントの編集です。

- 次のコードで太字で示されている行を追加し、PERMISSIONパラメータの値に基づいてフィールドを有効または無効にします。

<?XML VERSION="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- OpenMarket/Gator/AttributeTypes/TEXTAREA
--
-- INPUT
--
-- OUTPUT
--
-->

<!-- Display one TEXTAREA per attribute value -->
<IF COND="Variables.MultiValueEntry=no">
<THEN>

<!-- Don't want default display field  -->
<setvar NAME="doDefaultDisplay" VALUE="no"/>

<!-- Get all parameters from Attribute Editor xml -->
<presentation.getprimaryattributevalue
NAME="Variables.PresInst"
ATTRIBUTE="FONTSIZE" VARNAME="FONTSIZE"/>
<if COND="Variables.errno!=0">
<then>
<setvar NAME="FONTSIZE" VALUE="2"/>
</then>
</if>

<presentation.getprimaryattributevalue
NAME="Variables.PresInst"
ATTRIBUTE="WRAPSTYLE" VARNAME="WRAPSTYLE"/>
<if COND="IsVariable.WRAPSTYLE!=true">
<then>
<setvar NAME="WRAPSTYLE" VALUE="OFF"/>
</then>
</if>

<presentation.getprimaryattributevalue
NAME="Variables.PresInst"
ATTRIBUTE="XSIZE" VARNAME="XSIZE"/>
<if COND="IsVariable.XSIZE!=true">
<then>
<setvar NAME="XSIZE" VALUE="24"/>
</then>
</if>

<presentation.getprimaryattributevalue
NAME="Variables.PresInst"
ATTRIBUTE="YSIZE" VARNAME="YSIZE"/>
<if COND="IsVariable.YSIZE!=true">
<then>
<setvar NAME="YSIZE" VALUE="20"/>
</then>
</if>

<setvar NAME="disableTextArea" VALUE="no"/>
<presentation.getprimaryattributevalue
NAME="Variables.PresInst"
ATTRIBUTE="PERMISSION" VARNAME="PERMISSION"/>
<if COND="IsVariable.PERMISSION=true">
<then>
<setvar NAME="errno" VALUE="0"/>
<USERISMEMBER GROUP="Variables.PERMISSION"/>
<IF COND="Variables.errno=0">
<THEN>
<setvar NAME="disableTextArea" VALUE="yes"/>
</THEN>
</IF>
</then>
</if>

<tr>

<!-- Standard element to display attribute name or description
-->
<callelement NAME="OpenMarket/Gator/FlexibleAssets/Common
/DisplayAttributeName"/>
<td></td>
<td>

<!-- Single valued attributes -->
<if COND="Variables.EditingStyle=single">
<then>

<!-- Special case: TEXTAREA for URL attributes -->
<IF COND="Variables.AttrType=url">
<THEN>
<setvar NAME="errno" VALUE="0"/>
<BEGINS STR="AttrValueList.urlvalue"
WHAT="AttrValueList."/>
<IF COND="Variables.errno=1">
<THEN>
<setvar NAME="filename" VALUE="CS.UniqueID.txt"/>
</THEN>
<ELSE>
<setvar NAME="filename"
VALUE="AttrValueList.urlvalue"/>
</ELSE>
</IF>

<INPUT TYPE="hidden" NAME="Variables.AttrName_file"
VALUE="Variables.filename"
REPLACEALL="Variables.AttrName,Variables.filename"/>

<setvar NAME="errno" VALUE="0"/>
<BEGINS STR="AttrValueList.@urlvalue"
WHAT="AttrValueList."/>
<IF COND="Variables.errno=1">
<THEN>
<setvar NAME="MyAttrVal" VALUE="Variables.empty"/>
</THEN>
<ELSE>
<setvar NAME="MyAttrVal"
VALUE="AttrValueList.@urlvalue"/>
</ELSE>
</IF>
</THEN>
</IF>

<!-- Display a TEXTAREA with all parameters from Attribute
--Editor xml -->
<!-- The NAME of the input must be the attribute name -->
<IF COND="Variables.disableTextArea=yes">
<THEN>
<TEXTAREA DISABLED="yes" NAME="Variables.AttrName"
ROWS="Variables.YSIZE" COLS="Variables.XSIZE"
WRAP="Variables.WRAPSTYLE"
REPLACEALL="Variables.AttrName,Variables.XSIZE,
Variables.YSIZE,Variables.WRAPSTYLE,Variables.empty">

<!-- For most single valued attrs, the value is contained in
MyAttrVal -->
<csvar NAME="Variables.MyAttrVal"/>
</TEXTAREA>
</THEN>
<ELSE>
<TEXTAREA NAME="Variables.AttrName"
ROWS="Variables.YSIZE" COLS="Variables.XSIZE"
WRAP="Variables.WRAPSTYLE"
REPLACEALL="Variables.AttrName,Variables.XSIZE,
Variables.YSIZE,Variables.WRAPSTYLE,Variables.empty">
<!-- For most single valued attrs, the value is
contained in MyAttrVal -->
<csvar NAME="Variables.MyAttrVal"/>
</TEXTAREA>
</ELSE>
</IF>
</then>
<else>
<!-- Multiple valued attributes -->
<!-- For single value attributes we can usually use the
default RequireInfo -->
<!-- For multiple value attributes we need to append to
RequireInfo for each value -->
<if COND="Variables.RequiredAttr=true">
<then>
<setvar NAME="RequireInfo"
VALUE="Variables.RequireInfo*Counters.TCounterVariables.
AttrName*ReqTrue*Variables.AttrType!"/>
</then>
<else>
<setvar NAME="RequireInfo"
VALUE="Variables.RequireInfo*Counters.TCounterVariables
.AttrName*ReqFalse*Variables.AttrType!"/>
</else>
</if>

<!-- Display a TEXTAREA with all parameters from Attribute
Editor xml -->
<!-- The NAME of the input must be the attribute name
prepended by the TCounter counter -->
<IF COND="Variables.disableTextArea=yes">
<THEN>
<TEXTAREA DISABLED ="yes" NAME="Counters.TCounterVariables.AttrName"
ROWS="Variables.YSIZE" COLS="Variables.XSIZE"
WRAP="Variables.WRAPSTYLE"
REPLACEALL="Counters.TCounter,
Variables.AttrName,Variables.XSIZE,
Variables.YSIZE,Variables.WRAPSTYLE">
<csvar NAME="Variables.tempval"/> </TEXTAREA>
</THEN>
<ELSE>
<TEXTAREA NAME="Counters.TCounterVariables.AttrName"
ROWS="Variables.YSIZE" COLS="Variables.XSIZE"
WRAP="Variables.WRAPSTYLE"
REPLACEALL="Counters.TCounter,
Variables.AttrName,Variables.XSIZE,
Variables.YSIZE,Variables.WRAPSTYLE">
<csvar NAME="Variables.tempval"/> </TEXTAREA>
</ELSE>
</IF>
</else>
</if>
</td>
</tr>
</THEN>
</IF> <!-- MultiValueEntry -->
</FTCS>

9.3.2 アップロード対象のファイルを検証するためのカスタム・ロジックの追加

アップロード対象のファイルを検証するには、属性エディタのコードにカスタム・ロジックを追加します。

1. パスCustomElements/fatwire/ui/utilにValidateFileUploadという名前のJSPエレメントを作成します。

2. JSPエレメントで、ics.GetCgi("fileBytes")をコールして、リクエスト範囲内のアップロード対象のファイル・データを含むファイル名およびバイト配列を取得します。このコールにより、FTVALが返され、ここから、getBlob()メソッドをコールし、アップロード対象のBLOB用のbyte[]を取得できます。

byte[] fileBytes = null;
if(ics.GetCgi("fileBytes") != null){
fileBytes = ics.GetCgi("fileBytes").getBlob();
}

3. (オプション) アップロード対象のファイル・データが有効であることを確認するためのカスタム・ロジックを記述します。

- ファイル・データが有効な場合、ics.SetVar("fileValidated","true")をコールして、変数fileValidatedをtrueに設定します。これにより、ファイルはWebCenter Sitesサーバーに確実にアップロードされます。

- ファイル・データが無効な場合、ics.SetVar("fileValidated","false")をコールして、変数fileValidatedをfalseに設定します。これにより、ユーザーがアップロードするデータは拒否され、エラー・メッセージが表示されます。

注意:

サンプル・コード(検証ロジックを除く)は、ベース・エレメントfatwire/ui/util/ValidateFileUploadで使用可能です。このエレメントは変更しないでください。また、カスタム・コードは手順1で指定したようにCustomElementsパス内に記述する必要があります。

9.4 属性エディタの編集に関する考慮事項

属性エディタを編集する際は、次のことに留意してください。

- スキーマを変更せずに、「名前」を変更できます。

- データ消失を発生せずに、「説明」を変更できます。

- 属性エディタ内のコードを変更する場合:

- 入力オプションを追加できます。

- 既存のデータがある場合は、入力オプションを削除しないでください。入力オプションを削除すると、一部の既存データが無効になり、データベース内を検索してそれらのデータを修正することが必要になります。

- 入力スタイルを変更した場合は、データの不一致が生じるおそれがあります。

10 付属の属性エディタの構成

WebCenter Sitesでは、CKEditor、Clarkii Online Image Editorおよびイメージ・ピッカーを構成できます。

次の各項目では、WebCenter Sitesに付属している属性エディタのインスタンスを構成する方法について説明します。

- CKEditorの構成

- Clarkii Online Image Editorの構成

- イメージ・ピッカーの構成

10.1 CKEditorの構成

CKEditorは、CKSource社製のオープン・ソースWYSIWYGテキスト・エディタであり、クライアント側にインストールしておく必要はありません。CKEditorは、WebCenter Sitesに付属しています。FirstSiteIIサンプル・サイトでは、WYSIWYG対応のテキスト・フィールドが含まれた特定のアセット・タイプは、デフォルトでCKEditorを使用するように構成されています。

この項には次のトピックが含まれます:

- 開始する前に

- CKEditorインスタンスの作成方法とフィールドに対して有効化する方法

- CKEditorをWebモードで使用可能にする方法

- 選択したアセット・タイプをCKEditorで使用可能にする方法

- 組み込まれたアセットの承認依存性を設定する方法

- CKEditorツールバーをカスタマイズする方法

- CKEditorでスペル・チェック・サポートを構成する方法

10.1.1 始める前に

Internet ExplorerでCKEditorを使用している場合に、WebCenter Sitesがcp1252文字セットを使用するように構成されている場合は、次の手順に従い、CKEditorがInternet Explorerで正しく動作するようにしてください。

1. Adminインタフェースで、プロパティ管理ツールを開いて、cs.contenttypeプロパティの値をメモします。

2. Exploreにログインします。

3. SiteCatalog\OpenMarket\xcelerate\Actions\CKEditorRendererエレメントにアクセスして、そのresargs1フィールドを次の値に設定します。

cs.contenttype=[your content type]; charset=windows-1252

ここで、[your content type]には、プロパティ管理ツールからメモした値を指定します。

10.1.2 CKEditorインスタンスの作成方法とフィールドに対して有効化する方法

この手順では、CKEditorのインスタンスを作成して、FirstSiteIIサンプルに基づいてこのインスタンスをフレックス・アセット属性に対して有効にする方法を説明します。

この例では、新しいCKEditorインスタンスをFSIIAbstractフィールドの入力方法(属性エディタ)として有効にします。(FSIIAbstractは、Contentというサンプル・アセット・タイプのフレックス属性です。)

CKEditorインスタンスを作成して有効にする手順:

1. Adminインタフェースを開きます。

2. CKEditorインスタンスを作成します。

a. ボタン・バーで、「新規」をクリックします。

b. アセット・タイプのリストで、「新規属性エディタ」をクリックします。
WebCenter Sitesに、新規属性エディタ・フォームが表示されます。

c. 「名前」フィールドに、このCKEditorインスタンスを一意に識別する名前を入力します。この例では、CK_FSIIAbstractと入力します。
クライアントは、総称名を使用してCKEditorを作成して、そのCKEditorを複数の属性で使用できます。そのフィールド特有の要件がないかぎり、属性に対してCKEditorインスタンスを一意に識別する必要はありません。たとえば、そのフィールドが他のCKEditorフィールドと異なる場合、そのフィールド内のCKEditorの幅と長さといった要件です。

d. 次のコードを「XML」フィールドに貼り付けます。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CKEDITOR">
<CKEDITOR WIDTH="400" HEIGHT="200"></CKEDITOR>
</PRESENTATIONOBJECT>

e. 「保存」をクリックします。

3. このCKEditorインスタンスをFSIIAbstractフィールドの入力方法として有効にします。「編集」フォームで、FSIIAbstract属性アセットを探して開きます。

a. ボタン・バーで、「検索」をクリックします。

b. アセット・タイプのリストで、「コンテンツ属性の検索」をクリックします。

c. 「検索」フィールドで、FSIIAbstractを入力して、「検索」をクリックします。

d. 検索結果のリストで、FSIIAbstractアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。
WebCenter Sitesの「編集」フォームにアセットが表示されます。

e. CKEditorをこの属性の属性エディタ(入力方法)として設定します。「属性エディタ」ドロップダウン・リストで、CK_FSIIAbstractを選択します。

f. 「保存」をクリックします。

4. 新しいCKEditorインスタンスをテストするには、Oracle WebCenter Sites: Contributorインタフェースに切り替え、任意の「コンテンツ」アセットを探して、そのアセットを「編集」ビューで開きます。

a. 「検索」フィールドで、下矢印をクリックして「検索タイプ」メニューを開きます。「検索タイプ」メニューで、コンテンツの検索を選択します。次に、虫めがねアイコンをクリックします。
「検索」タブが開き、検索結果が表示されます。

b. アセット・タイプのリストで、目的のContentアセットに移動し(この例ではFSIIAbout)、そのアセットを右クリックして、コンテキスト・メニューから「編集」を選択します。
タブが開いて、そのアセットが「編集」ビューに表示されます。

c. 「概要」フィールドに移動して、フィールドをクリックします。
CKEditorが表示されない場合は、属性エディタのXMLコードと、「属性エディタ」ドロップダウン・リストで選択した内容を確認してください。

d. アセットのツールバーで、「調査」アイコンをクリックして、アセットの「調査」ビューを表示します。

10.1.3 CKEditorをWebモードで使用可能にする方法

ユーザーがWebモードでCKEditorを使用してアセットを編集できるようにするには、表10-1に示すように、パラメータeditorとparamsを適切なテンプレート内のinsite:editタグで設定します。編集するコードが含まれたテンプレートは、Webモードで使用するCKEditorが属するアセット用であるか、そのアセットと関連付けられたアセット・タイプ用である必要があります。

表10-1 CKEditorをWebモードで使用可能にするパラメータ

タグ

パラメータ

値

説明

insite:edit

editor

ckeditor

使用するエディタの名前を指定します。

なし

params

editorId

Webモードで使用するCKEditorのIDを指定します。

なし

なし

enableEmbeddedLinks

CKEditorツールバーでリンク・アイコンを有効にします。

例10-1に、CKEditorをWebモードで使用可能にするための必須のパラメータを示します。

例10-1 CKEditorをWebモードで使用可能にするためのコード

<ics:listget listname='BodyList' fieldname="value" output="Body" />
<div id="body">
<insite:edit
assetid='<%=ics.GetVar("cid")%>'
assetfield='<%='Attribute_"+ics.GetVar("BodyAttrName")%>'
assetfieldvalue='<%=ics.GetVar("Body")%>'
assettype='<%=ics.GetVar("c")%>'
editor='ckeditor'
params="{enableEmbeddedLinks:'1'}"/>
</div>

注意:

insite:editタグでCKEditorの幅と高さが指定されていない場合は、CKEditorは、自身のXMLコードで設定されたXSIZEとYSIZEを使用します。詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

insite:editタグは、次のいずれかの方法で編集できます。

- 適切なテンプレート内の「エレメント・ロジック」フィールド。テンプレートの「エレメント・ロジック」フィールドで作業するには:

- Adminインタフェースを開きます。

- 「検索」(ボタン・バー上)をクリックし、テンプレートの検索→「検索」を選択して、テンプレート名を選択します。

- テンプレートの「編集」フォームで、「エレメント」タブを選択して、「エレメント・ロジック」フィールドに移動します。

- Oracle WebCenter Sites Explorer (Explorerを使用したコード編集の手順には、「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」を参照してください)。

- 任意のテキスト・エディタ。

10.1.4 選択したアセット・タイプをCKEditorで使用可能にする方法

ユーザーが使用できるアセット・タイプを限定するには、ALLOWEDASSETTYPESパラメータをCKEditorのXMLコードに追加します。このパラメータの値として、使用可能にするアセット・タイプの名前をカンマ区切りリストの形式で指定します。

アセット・タイプをCKEditorで使用可能にする手順:

1. Adminインタフェースを開きます。

2. 「編集」フォームで属性エディタ(名前はCKEditor)を探して開きます。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「属性エディタの検索」を選択します。

c. 属性エディタの検索フォームで、検索条件(存在する場合)を入力して、「検索」をクリックします。

d. 検索結果のリストで、CKEditorアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。

3. 「XML」フィールドに移動して、ALLOWEDASSETTYPESパラメータを<CKEDITOR>タグに追加します。次に、例10-2に示すように、使用可能にするアセット・タイプの名前をALLOWEDASSETTYPESパラメータの値として指定します。
ALLOWEDASSETTYPESパラメータは、追加のパラメータとして<CKEDITOR>タグに追加されます。このパラメータの値は、ユーザーが新しいアセットを作成できるアセット・タイプを指定します。

4. 「変更の保存」をクリックして、アセットを保存します。

5. ALLOWEDASSETTYPESパラメータをテストします。

a. Contributorインタフェースに切り替えます。

b. CKEditor対応のフィールドを持つアセットを探してWebモードで開きます。

- 「検索」フィールドで、検索条件を指定して、虫めがねアイコンをクリックします。
「検索」タブが開き、検索結果が表示されます。

- アセットの名前をクリックして、そのアセットの「調査」ビューを開きます。

- そのアセットがフォーム・モードで開かれた場合は、アセットのツールバーで「モード」スイッチをクリックして、Webモードに切り替えます。

- アセットのツールバーで、「編集」アイコンをクリックします。

c. いずれかの許可されたアセット・タイプを指定して検索します。許可されたアセットが固定された検索結果リストに表示されたら、その許可されたアセットをCKEditorにドラッグします。
ALLOWEDASSETTYPESパラメータで指定したタイプの許可されたアセットがまったくない場合は、「コンテンツ」→「新規」を選択して、新しいアセットを作成します。そのアセットを指定して検索して、そのアセットをドックからCKEditorにドラッグします。

例10-2 追加されたパラメータを示すXMLコード

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT
SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT
NAME="CKEDITORTEST"><CKEDITOR WIDGET="580"
HEIGHT="200" IMAGEPICKERID="1112668339899"
ALLOWEDASSETTYPES="MEDIA_C,CONTENT_C,PRODUCT_C,DOCUMENT_C">
</CKEDITOR></PRESENTATIONOBJECT>

10.1.5 組み込まれたアセットの承認依存性を設定する方法

「アセットを含む」アイコンと「新規アセットの作成および包含」アイコンを使用すると、ユーザーは単一のアセットを別のアセットのCKEditor対応フィールドに組み込むことができます。組み込まれたアセットは、そのフィールドでプレビュー可能になり、最終的には、メイン・アセットの表示内容にオンラインで埋め込まれます。

メイン・アセットと組み込まれたアセットが初めてパブリッシュされた後に、これらのアセット間の依存性によって、後続の承認とパブリッシュがどのように機能するのかが決定されます。この依存性は、CKEditorのXMLコード内のDEPTYPEパラメータによって定義されます。

DEPTYPEパラメータは、EXISTSまたはEXACTに設定できます。DEPTYPEパラメータが明示的に設定されていない場合は、デフォルトでEXACTが使用されます。

- EXISTS: メイン・アセットが編集、承認および再パブリッシュされたときに、いずれかのバージョンの組み込まれたアセットがパブリッシュ先に存在している場合は、組み込まれたアセットが承認および再パブリッシュされる必要はありません。

- EXACT: メイン・アセットが編集、承認および再パブリッシュされたときに、組み込まれたアセットが編集されていた場合は、組み込まれたアセットも承認および再パブリッシュされる必要があります。

組み込まれたアセットの承認依存性を定義する手順:

1. Adminインタフェースを開きます。

2. 「編集」フォームで属性エディタ(名前はCKEditor)を探して開きます。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「属性エディタの検索」を選択します。

c. 属性エディタの検索フォームで、検索条件(存在する場合)を入力して、「検索」をクリックします。

d. 検索結果のリストで、CKEditorアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。

3. 「XML」フィールドに移動して、例10-3に示すように、DEPTYPEパラメータを<CKEDITOR>タグに追加して、DEPTYPEパラメータの値をEXISTSまたはEXACTに設定します。
DEPTYPEパラメータは、追加のパラメータとして<CKEDITOR>タグに追加されます。

4. 「変更の保存」をクリックして、アセットを保存します。

例10-3 追加された属性を含むXMLコード

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT
SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT
NAME="CKEditorTest"><CKEDITOR
WIDTH="580" HEIGHT="200"
DEPTYPE="EXISTS"></CKEDITOR>
</PRESENTATIONOBJECT>

10.1.6 CKEditorツールバーをカスタマイズする方法

CKEditorのツールバーで使用できる機能と、それらの配置をカスタム構成ファイルでカスタマイズできます。

カスタムのconfig.jsファイルでCKEditorツールバーをカスタマイズする手順:

1. テキスト・エディタで構成ファイルを開きます。
<cs_app>/ckeditor/customconfig.js

<cs_app>は、WebCenter SitesのWebアプリケーションがデプロイされたアプリケーション・サーバーのディレクトリを示します。

2. Contributorインタフェース用にツールバーをカスタマイズする手順(フォーム・モード用とWebモード用):

- ツールバーをContributorインタフェース用にカスタマイズするには、<cs_app>/ckeditor/customconfig.jsのconfig.toolbar_SITESを検索します。

- ツールバーをWebモード用にカスタマイズするには、<cs_app>/ckeditor/customconfig.js fのconfig.toolbar_SITES_WEBを検索します。

3. 変更を加えます。ツールバー定義の構文については、CKEditorのドキュメントを参照してください。

4. 保存してファイルを閉じます。

5. WebCenter Sitesのアプリケーションを再デプロイし、アプリケーション・サーバーを再起動して、変更内容を適用します。

インスタンス単位でCKEditorツールバーをカスタマイズする手順:

1. カスタム・ツールバー定義を作成します。

a. カスタム構成ファイルをテキスト・エディタで開きます。
<cs_app>/ckeditor/config.js

<cs_app>は、WebCenter SitesのWebアプリケーションがデプロイされたアプリケーション・サーバーのディレクトリを示します。

b. 新しいツールバー定義をファイルに追加します。カスタム・ツールバー定義の作成方法については、CKEditorのドキュメントを参照してください。

config.toolbar_<toolbardef> = [
[ 'Cut', 'Copy', 'Paste', 'PasteText', 'PasteFromWord', '-', 'Undo', 'Redo' ],
{ name: 'links', items: [ 'Link', 'Unlink', 'Anchor' ] },
{ name: 'basicstyles', items: [ 'Bold', 'Italic', 'Underline','Strike','-','Subscript','Superscript' ] },
{ name: 'colors', items: [ 'TextColor', 'BGColor' ] },
{ name: 'tools', items: [ 'Maximize', 'ShowBlocks' ] }
];

<toolbarDef>の値は、カスタム・ツールバー定義の名前です。この名前は、このカスタム定義を使用するようにCKEditorインスタンスを変更する際に使用します。

2. カスタム・ツールバー定義を使用するように、CKEditorインスタンスを変更します。

a. Adminインタフェースを開きます。

b. CKEditorインスタンスを検索します。

- ボタン・バーで、「検索」をクリックします。

- アセット・タイプのリストで、「属性エディタの検索」をクリックします。

- 「検索」フィールドに、CKEditorインスタンスが保持されているアセットの名前を入力して、「検索」をクリックします。

- 検索結果のリストで、アセットに移動して、その「編集」(鉛筆)アイコンをクリックします。

c. 「XML」フィールドで、属性エディタ・コードを次のように変更します。

- 次の太字で強調表示されている行を探します。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM
"presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CKEditorCustomized">
<CKEDITOR WIDTH="400" HEIGHT="200">
</CKEDITOR></PRESENTATIONOBJECT>

- TOOLBARパラメータを<CKEDITOR>タグに追加します。

TOOLBAR="<toolbarDef>"

- このTOOLBARパラメータでは、手順1で作成したカスタム・ツールバー定義の名前を指定します。

- 変更後の行は次のようになります。

<CKEDITOR WIDTH="400" HEIGHT="200" TOOLBAR="<toolbarDef>">

d. 「変更の保存」をクリックして、アセットを保存します。

3. WebCenter Sitesのアプリケーションを再デプロイし、アプリケーション・サーバーを再起動して、変更内容を適用します。

CKEditorの構成の詳細は、CKEditorのドキュメントを参照してください。

10.1.7 CKEditorでスペル・チェック・サポートを構成する方法

CKEditorスペル・チェッカの使用および構成の手順は、次のURL (http://docs.cksource.com/CKEditor_3.x/Users_Guide/Spell_Checking)にアクセスしてください。

10.2 Clarkii Online Image Editorの構成

Clarkii Online Image Editor (Clarkii OIE)は、InDis Baltic社が提供しているサード・パーティのイメージ・エディタであり、WebCenter Sitesがサポートされているすべてのブラウザ(Safariを含む)でサポートされています。

FirstSiteIIサンプル・サイトを使用してClarkii OIEインスタンスを作成する場合は、EDITORTYPE="clarkii"タグを追加することで、WebCenter Sitesに付属しているOnline Image Editor (OIE)のコードを変更できます。FirstSiteIIサンプル・サイト以外のサイトを使用する場合は、各アセット・タイプについてフィールドごとに別個のClarkii OIEインスタンスを構成することも、複数のアセット・タイプのフィールドと関連付ける単一のClarkii OIEインスタンスを構成することもできます。

図10-1は、Clarkii OIEの固有コントロールと、Clarkii OIEが有効化されている属性内のイメージを操作するためのWebCenter Sites側の機能を示しています。

図10-1 アセットのフォームのフィールド内にレンダリングされたClarkii Online Image Editor

この機能を構成して有効にする前に、次のことに注意してください。

- Clarkii OIEは、フレックス属性のみに対して有効にできます。この項の説明では、FirstSiteIIサンプル・サイトのMediaフレックス・ファミリを例として使用しています。

- Clarkii OIEは、blob型の属性のみに対して有効にできます。

- Clarkii OIEを有効にしたフィールドでClarkii OIEをレンダリングするためには、Flashがクライアント・ブラウザにインストールされている必要があります。

注意:

Clarkii OIEのツールバーとメニューの機能をカスタマイズできます。これらの機能はClarkii OIEと深く関連しているため、これらの機能については説明していません。Clarkii OIE固有の機能の構成方法については、次のURLにアクセスしてください。

http://www.online-image-editor-clarkii.com/

この項には次のトピックが含まれます:

- Clarkii OIEインスタンスの作成方法とフィールドに対して有効化する方法

- Clarkii OIEのプロパティを構成する方法

- アセットを分類するためにフィールド・コピアー・フィルタを実装する方法

10.2.1 Clarkii OIEインスタンスの作成方法とフィールドに対して有効化する方法

Clarkii OIEのインスタンスを作成して、このインスタンスをフレックス属性アセットに対して有効にします。この手順は、FirstSiteIIサンプル・サイトに基づいています。

この例では、新しいClarkii OIEインスタンスを、FSII_ImageFileフィールドの属性エディタとして有効にします。FSII_ImageFileは、サンプルのMediaアセット・タイプの属性です。

1. Adminインタフェースを開きます。

2. Clarkii OIEインスタンスを作成します。

a. ボタン・バーで、「新規」をクリックします。

b. アセット・タイプのリストで、「新規属性エディタ」をクリックします。
WebCenter Sitesに、新規属性エディタ・フォームが表示されます。

c. 「名前」フィールドに、このClarkii OIEインスタンスを一意に識別する名前を入力します(この例では、ClarkiiOIEと入力します)。

d. 「XML」フィールドで、次のコードを貼り付けます。

注意:

各パラメータの詳細は、「Clarkii OIEのプロパティを構成する方法」の表を参照してください。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="editor">
<IMAGEEDITOR
HEIGHT="600"
WIDTH="800"
EDITORTYPE="clarkii"
FITIMAGE="false"
ENABLEIMAGEPICKER="true"
ASSETTYPE="Media_C"
ATTRIBUTE="FSII_ImageFile"
ATTRIBUTETYPE="Media_A"
CATEGORYATTRIBUTE=""
RESTRICTEDCATEGORYLIST=""
OIEENABLEIMAGEPICKER="true"
OIEASSETTYPE="Media_C"
OIEATTRIBUTE="FSII_ImageFile"
OIEATTRIBUTETYPE="Media_A"
OIECATEGORYATTRIBUTE=""
OIERESTRICTEDCATEGORYLIST="">
</IMAGEEDITOR>
</PRESENTATIONOBJECT>

e. 「保存」をクリックします。

3. Clarkii OIEインスタンスを、特定のアセット・タイプの属性の属性エディタとして有効にします。この例では、Mediaアセット・タイプのFSII_ImageFile属性を使用します。

a. 「編集」フォームで、属性アセットを探して開きます。この例では、FSII_ImageFile属性を探して開きます。

- ボタン・バーで、「検索」をクリックします。

- アセット・タイプのリストで、属性アセットのアセット・タイプをクリックします。この例では、「メディア属性の検索」をクリックします。

- 「検索」フィールドで、変更する属性アセットの名前を入力します。この例では、FSII_ImageFileと入力します。

- 「検索」をクリックします。

- 検索結果のリストで、属性アセット(FSII_ImageFile)に移動し、その「編集」(鉛筆)アイコンをクリックします。
WebCenter Sitesの「編集」フォームにアセットが表示されます。

b. Clarkii OIEをこの属性アセットの属性エディタとして設定します。

- 「値タイプ」フィールドで、blobが選択されていることを確認します。

注意:

Clarkii OIEには、blob型の属性値が必要です。属性アセットを保存すると、その後、「値タイプ」フィールドで選択した値は変更できません。

- 「属性エディタ」ドロップダウン・リストで、手順2で作成したClarkii OIEインスタンスを選択します。

c. 「変更の保存」をクリックします。

4. 新しいClarkii OIEインスタンスをテストする手順:

a. Contributorインタフェースを開きます。

b. 手順3で変更した属性をフィールドとして指定している定義を含む任意のアセットを検索して、そのアセットを「編集」フォームで開きます。この例では、Mediaアセットを選択します。

- 「検索」フィールドに、検索条件を入力します。

- 検索範囲を特定のアセット・タイプに絞り込むには、「検索」フィールドの下矢印をクリックして、「検索タイプ」ドロップダウン・リストを開きます。Clarkii OIEインスタンスに対応したフィールドを使用しているアセット・タイプをクリックします。この例では、「メディアの検索」を選択します。

- 虫めがねアイコンをクリックします。
「検索」タブが開き、検索結果のリストが表示されます。

- 検索結果のリストで、選択するアセットを右クリックします。この例では、FSII AudioCo_iAC-008.jpgメディア・アセットを選択し、「編集」を選択します。
WebCenter Sitesの「編集」フォームにアセットが表示されます。

c. Clarkii OIEで有効なフィールドに移動します。この例では、FSII_ImageFileフィールドになります。これは図10-2のようになります。

図10-2 Clarkii Online Image Editor

Clarkii OIEをフィールドでレンダリングするには、次のいずれかを行います。

- Flashがインストールされていることを確認します。

- 作成したClarkii OIEインスタンスのXMLコードを確認します(手順2のdを参照)。

- Clarkii OIEを属性エディタとして有効にした属性アセットで選択した内容を確認します(手順3のbを参照)。

d. 「取消」をクリックして、このアセットの「調査」フォームに戻ります。

10.2.2 Clarkii OIEのプロパティを構成する方法

表10-2、表10-3および表10-4では、Clarkii OIE属性エディタ・アセットの作成時に指定できるすべてのプロパティを列挙して説明しています。これらの表は、サイトの設計に合せて独自のClarkii OIEインスタンスのプロパティを構成するためのリファレンスとして使用してください。

表10-2 Clarkii OIEの指定

プロパティ

定義

HEIGHT

特定アセットのフォームの属性フィールドに表示される際の、Clarkii OIE領域の高さを指定します。

推奨値: 600

WIDTH

特定アセットのフォームの属性フィールドに表示される際の、Clarkii OIE領域の幅を指定します。

推奨値: 800

EDITORTYPE

使用するイメージ・エディタのタイプを指定します。Clarkii OIEを有効にするには、このプロパティを次のように指定する必要があります。

EDITORTYPE="clarkii"

FITIMAGE

このプロパティをtrueに設定した場合、Clarkii OIEを使用して編集されたイメージは、Clarkii OIEキャンバス内にちょうど収まるようにサイズ調整されます。このプロパティをfalseに設定した場合、Clarkii OIEを使用して編集されたイメージは、そのイメージの実サイズでキャンバス上に表示されます。

可能な値: true|false

表10-3 「イメージの参照」ボタンの指定

プロパティ

定義

ENABLEIMAGEPICKER

「イメージの参照」ボタンを有効にします。ユーザーはこのボタンを使用して、Clarkii OIEキャンバス上の既存のイメージを任意のイメージに置換できます。このボタンをクリックすると、イメージ・ピッカー・ウィンドウが開きます。

可能な値: true|false

注意: このプロパティをfalseに設定した場合は、「イメージの参照」ボタンに関する他のプロパティの値を設定しないでください。

ASSETTYPE

「イメージの参照」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットのアセット・タイプを指定します。

可能な値: イメージを格納するためのblob型の属性を含む定義が存在するアセット・タイプ。

例: "Media_C"

ATTRIBUTE

「イメージの参照」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのイメージ・ファイル属性を指定します。

可能な値: イメージを格納するためのblob型属性。

例: "FSII_ImageFile"

ATTRIBUTETYPE

ATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプを指定します。「イメージ・ピッカー」ではこのアセット・タイプのみの属性を検索し、このアセット・タイプの属性があるイメージのみを表示します。

可能な値: ATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプ。

例: "Media_A"

CATEGORYATTRIBUTE

「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットを(理想的にはそれらの親アセットの名前に基づいて)分類する値が保持されているstring属性を指定します。このプロパティの値により、イメージ・ピッカーの「カテゴリ」ドロップダウン・リストに、指定された属性で見つかった値がすべて移入されます。フィールド・コピアー・フィルタを使用してアセットを分類する方法は、「アセットを分類するためにフィールド・コピアー・フィルタを実装する方法」を参照してください。

「イメージの参照」ボタンをクリックすると、ユーザーは「カテゴリ」ドロップダウン・リストを使用して、これらの属性値のいずれかを選択することで、イメージ・ピッカー・ウィンドウに表示されるイメージをフィルタリングできます。選択された属性値に一致するイメージのみが、「イメージ・ピッカー」ウィンドウにレンダリングされます。

注意: このプロパティの値を指定しない場合は、ASSETTYPEプロパティで指定されたアセット・タイプのすべてのイメージ・アセットがイメージ・ピッカー・ウィンドウに表示され、「カテゴリ」ドロップダウン・リストは表示されません。

RESTRICTEDCATEGORYLIST

カンマ区切りリストの形式で、CATEGORYATTRIBUTEプロパティで指定した属性の個別の値を入力します。ここで指定した値のみが、「イメージの参照」ボタンがクリックされたときにイメージ・ピッカー・ウィンドウの「カテゴリ」ドロップダウン・リストで使用できるようになります。

可能な値: CATEGORYATTRIBUTEプロパティの説明を参照してください。

注意: CATEGORYATTRIBUTEプロパティの値を指定しない場合、このプロパティは無視されます。

表10-4 「イメージの挿入」ボタンの指定

プロパティ

定義

OIEATTRIBUTE

「イメージの挿入」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのイメージ・ファイル属性を指定します。

可能な値: イメージを格納するためのblob型属性。

例: "FSII_ImageFile"

OIEATTRIBUTETYPE

OIEATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプを指定します。「イメージ・ピッカー」ではこのアセット・タイプのみの属性を検索し、このアセット・タイプの属性があるイメージのみを表示します。

可能な値: OIEATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプ。

例: "Media_A"

OIECATEGORYATTRIBUTE

「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットを(理想的にはそれらの親アセットの名前に基づいて)分類する値が保持されているstring属性を指定します。このプロパティの値により、イメージ・ピッカーの「カテゴリ」ドロップダウン・リストに、指定された属性で見つかった値がすべて移入されます。フィールド・コピアー・フィルタを使用してアセットを分類する方法は、「アセットを分類するためにフィールド・コピアー・フィルタを実装する方法」を参照してください。

「イメージの挿入」ボタンをクリックすると、ユーザーは「カテゴリ」ドロップダウン・リストを使用して、これらの属性値のいずれかを選択することで、イメージ・ピッカー・ウィンドウに表示されるイメージをフィルタリングできます。選択された属性値に一致するイメージのみが、「イメージ・ピッカー」ウィンドウにレンダリングされます。

注意: このプロパティの値を指定しない場合は、OIEASSETTYPEプロパティで指定されたアセット・タイプのすべてのイメージ・アセットがイメージ・ピッカー・ウィンドウに表示され、「カテゴリ」ドロップダウン・リストは表示されません。

OIERESTRICTEDCATEGORYLIST

カンマ区切りリストの形式で、OIECATEGORYATTRIBUTEプロパティで指定した属性の個別の値を入力します。ここで指定した値のみが、「イメージの挿入」ボタンがクリックされたときにイメージ・ピッカー・ウィンドウの「カテゴリ」ドロップダウン・リストで使用できるようになります。

可能な値: OIECATEGORYATTRIBUTEプロパティの説明を参照してください。

注意: OIECATEGORYATTRIBUTEプロパティの値を指定しない場合、このプロパティは無視されます。

OIEENABLEIMAGEPICKER

「イメージの挿入」ボタンを有効にします。ユーザーはこのボタンを使用して、Clarkii OIEキャンバス上の既存イメージの最上位層としてイメージを挿入できます。このボタンをクリックすると、イメージ・ピッカー・ウィンドウが開きます。

可能な値: true|false

注意: このプロパティをfalseに設定した場合は、「イメージの挿入」ボタンに関する他のプロパティの値を設定しないでください。

OIEASSETTYPE

「イメージの挿入」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのアセット・タイプを指定します。

可能な値: イメージを格納するためのblob型の属性を含む定義が存在するアセット・タイプ。

例: "Media_C"

10.2.3 アセットを分類するためにフィールド・コピアー・フィルタを実装する方法

イメージ・アセットをその親アセットの名前に基づいて分類するには、フィールド・コピアー・フィルタを使用します。図10-3は、FirstSiteIIサンプル・サイトのMediaフレックス・ファミリを使用して、フィールド・コピアー・フィルタを実装する方法を例示しています。この例のフィールド・コピアー・フィルタは、親アセットのシステム定義のName属性の値をユーザー定義のstring属性にコピーします。

既存の属性の値が上書きされることを防止するには、フィールド・コピアーによってコピーされるシステム定義属性の値を保持するための新しいstring属性(FSII_ImageParentName)を作成します。

注意:

フィールド・コピアー・フィルタの詳細は、「フレックス・フィルタ・クラス」を参照してください。

図10-3 フィールド・コピアー・フィルタのサンプルの概要

フィールド・コピアー・フィルタを使用する手順:

1. Adminインタフェースを開きます。

2. フィールド・コピアー・フィルタの入力として使用する値を持つシステム定義属性を特定するとともに、フィールド・コピアーによってこのシステム定義属性の値がコピーされる先となるユーザー定義のstring属性を特定します。

注意:

既存の属性の値が上書きされないようにするには、string型のフレックス属性を作成します(この例ではFSII_ImageParentName)。新しいフレックス属性の作成の手順は、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

3. FieldCopier型のフィルタを作成します(この例ではFSII_ImageParentNameCopier)。

a. ボタン・バーで、「新規」をクリックします。

b. アセット・タイプのリストで、「新規メディア・フィルタ」をクリックします。
「新規メディア・フィルタ」フォームが表示されます。

c. 「名前」フィールドで、このフィルタの一意の名前を入力します(この例では、FSII_ImageParentNameCopierを使用)。

d. 「フィルタ」フィールドで、ドロップダウン・リストからFieldCopierを選択します。次に「引数の取得」をクリックします。

- 「名前」ドロップダウン・リストで、フィールド・コピアー・フィルタの入力値として使用する値を持つシステム定義属性を選択します(この例では「名前」)。

- 「値」フィールドで、指定したシステム定義属性の値がフィールド・コピアー・フィルタによってコピーされる先となるユーザー定義属性の名前を入力します(この例ではFSII_ImageParentName)。

e. 「追加」をクリックして、フィルタに引数を追加します。

f. 「保存」をクリックして、フィルタを保存します。

4. 親(または子)定義を探して、新しいフィールド・コピアー・フィルタをその定義に追加します(この例では、フィールド・コピアー・フィルタをFSII_ImageCategoryというMedia親定義に追加します)。

a. ボタン・バーで、「検索」をクリックします。

b. アセット・タイプのリストで、「メディア親定義の検索」を選択します。

c. 「検索」フィールドで、フィールド・コピアー・フィルタを追加する先となる親定義の名前を入力します(FSII_ImageCategory)。

d. 「検索」をクリックします。

e. 検索結果のリストで、親(または子)定義に移動して、その「編集」(鉛筆)アイコンをクリックします。

f. 親(または子)定義の「編集」フォームで「フィルタ」セクションに移動して、手順3で作成したフィールド・コピアー・フィルタを選択します。

g. 「変更の保存」をクリックします。

5. フィールド・コピアー・フィルタ(FSII_ImageParentNameCopier)を追加した定義と関連付けられたすべての既存の親(または子)アセットを探して再保存します。これにより、このフィルタはユーザー定義属性(FSII_ImageParentName)に、システム定義属性(「名前」)の値を格納できるようになります。
このフィルタを親定義に追加した場合、関連付けられた親アセットのすべての子は、フィールド・コピアー・フィルタによってユーザー定義属性(この例ではFSII_ImageParentName)にコピーされた値を内部で継承します。

10.3 イメージ・ピッカーの構成

表10-5では、イメージ・ピッカー属性エディタのインスタンスを構成する際にXML定義で値を指定する必要があるパラメータを紹介しています。

表10-5 イメージ・ピッカーのパラメータ

パラメータ

説明

ASSETTYPENAME

このイメージ・ピッカー・インスタンスで表示されるイメージ・アセットのアセット・タイプ。

例: Media_C

ATTRIBUTETYPENAME

選択されたイメージ・アセット・タイプ内のイメージ・ファイル属性のアセット・タイプ。

例: Media_A

ATTRIBUTENAME

選択されたイメージ・アセット・タイプ内のイメージ・ファイル属性の名前。

例: FSII_ImageFile

CATEGORYATTRIBUTENAME

(オプション)選択されたイメージ・アセット・タイプ内のカテゴリ属性の名前。

例: FSII_ImageCategory

RESTRICTEDCATEGORYLIST

選択されたイメージ・アセット・タイプ内のカテゴリ属性の値で構成されるカンマ区切りリストを指定します。このリストに含まれる値は、イメージ・ピッカー・ウィンドウの「カテゴリ」ドロップダウン・リストに表示されます。このパラメータを省略した場合、イメージ・ピッカーは選択されたイメージ・アセット・タイプに属するすべてのアセットを表示します。

例: Audio、Video、Photo

イメージ・ピッカー定義のサンプルXMLコードは「イメージ・ピッカー属性エディタ定義のコードを作成する方法」に記載されています。新しい属性エディタ(イメージ・ピッカーの新規インスタンスなど)の作成手順は、「属性エディタの作成」を参照してください。アセット・フォーム内のフィールドの入力方法(イメージ・ピッカーなど)の選択手順は、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

この項には次のトピックが含まれます:

- イメージ・ピッカーに表示するイメージ・アセットを分類する方法

- イメージ・ピッカー属性エディタ定義のコードを作成する方法

10.3.1 イメージ・ピッカーに表示するイメージ・アセットを分類する方法

前の項で説明したCATEGORYATTRIBUTENAMEパラメータとRESTRICTEDCATEGORYLISTパラメータを使用すると、選択されたイメージ・アセット・タイプに属する選択されたカテゴリのアセットのみがイメージ・ピッカーのインスタンスによって表示されるように制限できます。この作業を実行する前に、次の条件が満たされている必要があります。

- string型のカテゴリ属性を、選択されたアセット・タイプ内の各アセットのカテゴリ記述子を格納することになるフレックス定義または選択されたイメージ・アセット・タイプに追加する必要があります。イメージ・ピッカーはこの属性の値を使用して、自身が表示できるアセット・カテゴリのリストを生成します。属性の作成の手順は、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

- 開発者またはコンテンツ・プロバイダは、選択されたイメージ・アセット・タイプの各アセットのカテゴリ・フィールドに適宜入力する必要があります。カテゴリが割り当てられていないアセットは、カテゴリ制限されたイメージ・ピッカー・インスタンスによって表示されません。

10.3.2 イメージ・ピッカー属性エディタ定義のコードを作成する方法

参考のために、イメージ・ピッカー属性エディタのサンプルXML定義を次に示しています。このサンプルを通じて、システム上でイメージ・ピッカーを構成する方法を理解してください。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT>
<PRESENTATIONOBJECT NAME="ImagePicker">
<IMAGEPICKER>
ASSETTYPENAME="Media_C"
ATTRIBUTETYPENAME="Media_A"
ATTRIBUTENAME="FSII_ImageFile"
CATEGORYATTRIBUTENAME="FSII_ImageCategory"
RESTRICTEDCATEGORYLIST="Audio,Video">
</IMAGEPICKER>
</PRESENTATIONOBJECT>

属性エディタの作成の詳細は、「属性エディタの作成」を参照してください。

11 WebCenter Sitesデータベースでの作業

WebCenter Sites、そのモジュールおよびWebCenter Sites製品のほぼすべては、データベース表に行として表されます。WebCenter Sitesのモジュールおよび製品(たとえばOracle WebCenter Sites: Engage)には、必要な表のほとんどが用意されています。ただし、WebCenter Sitesを使用して独自のアプリケーションを開発している場合、またはアセットを保持しない表(たとえば参照表)を使用する必要がある場合は、この章で説明する方法のいずれかを使用して表を作成します。

この章では、WebCenter Sitesデータベースにおける各種の表および列について説明し、表を作成するための手順を示します。アセットを保持しない表におけるデータの管理については、「アセットを保持しない表内のデータ管理」を参照してください。

注意:

WebCenter Sitesのデータベース表は、以前はカタログと呼ばれており、アプリケーション全体を通じて、表の名前、サーブレットの名前(CatalogManager)、データベース内のデータを操作する際に使用するJavaインタフェースにこの用語がまだ残っています。

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

- データベース表のタイプ

- 列(フィールド)のタイプ

- システム表への追加について

- プロパティ・ファイルおよびデータベースについて

11.1 データベース表のタイプ

WebCenter Sitesデータベースには、次の5つのタイプの表があります。

- オブジェクト表: データをオブジェクトとして保持し、表の各行に一意のIDを自動的に提供します。

- ツリー表: オブジェクト表の中のオブジェクト間の関係についての階層情報を保持します

- コンテンツ表: 水平データを保持しますが、各行に一意のIDを提供することはありません

- 外部表: 次のいずれかとなります。

- WebCenter Sitesデータベースの外側にあるが、そのWebCenter Sitesからアクセスできる表。

- WebCenter Sitesデータベースの中にあるが、そのWebCenter Sitesが作成したのではない表。

- システム表: WebCenter Sitesのコア・アプリケーションの表で、そのスキーマを変更できないもの。

WebCenter Sitesは、外部表を含めたWebCenter Sitesデータベースの任意の表に対する問合せから、結果セットをキャッシュできます。

この項には次のトピックが含まれます:

- オブジェクト表

- ツリー表

- コンテンツ表

- 外部表

- システム表

- 表のタイプの特定

11.1.1 オブジェクト表

オブジェクト表は、データをオブジェクトとして格納するもので、階層で表すことができます。これらのオブジェクトのロード、保存および管理には、CatalogManager APIを使用できます。アセット・タイプの表はオブジェクト表です。

オブジェクト表の主キーは常にID (id)列で変更できません。オブジェクト表を追加するようにWebCenter Sitesに指示すると、その表にID列が作成されます。IDは、表に行が追加されるにつれて、デフォルトで各行に割り当てられる一意の識別子です。たとえば、だれかが新しいアセットを作成すると、WebCenter SitesではIDが決定され、そのアセットのIDとしてその値が割り当てられます。

(アセットなどの)オブジェクトに割り当てられたIDは変更できません。

注意:

AssetMakerまたはフレックス・ファミリ・メーカーで新しいアセット・タイプのオブジェクト表を作成するときには、デフォルトで追加の列がいくつか作成されます。ベーシック・アセット表内のデフォルトの列については、「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

IDの生成はWebCenter Sitesによって処理されるため、オブジェクト表を使用して、格納するデータの各行が一意に識別されることを確認してください。

オブジェクト表(カタログ):の例

- アセットを保持するすべての表

- パブリッシュ表の多く

- 訪問者のデータを保持するEngageの表

11.1.2 ツリー表

ツリー表には、オブジェクト表間の階層関係についての情報が格納されます。言い換えれば、オブジェクト表は階層で表すことができますが、その階層自体はツリー表に格納されます。つまり、階層がツリーであるということです。

たとえば、WebCenter Sitesでは、WebCenter Sitesデータベースに次の表が追加されます。

- AssetRelationTree: アセット間のアソシエーションについての情報を格納します。これらのアソシエーションによって親子関係が作成されます。アセットのアソシエーションの詳細は、「フレックス・アセット・モデル」を参照してください。

- SitePlanTree: ページ・アセットとそれらのアセットから参照されるアセットの間の親子関係についての情報を格納します。この情報は、WebCenter Sitesのインタフェースに提示される「サイト・ナビゲーション」タブにグラフィカルに提示されます。

ツリー表の各行は、そのツリーのノードです。ツリー表の各ノードは、次の2つの場所を指しています。

- オブジェクト表内のオブジェクト、つまりオブジェクト表が表すオブジェクト

- そのツリー表の中の親ノード、ただし最上位のノードで親がない場合は除く

言い換えれば、オブジェクト自体はオブジェクト表に格納されます。データベース内の他のオブジェクトとの関係(ツリーで記述)は、ツリー上のノードとしてツリー表に格納されます。子ノードは親ノードを指しますが、親は子を指しません。

ツリー表を作成すると、表11-1に示す列がデフォルトで設定されます。これらの列を変更したり、新しい列を作成したりすることはできません。

表11-1 デフォルトの列

列

説明

nid

ノードのID。これが主キーです。

nparentid

ノードの親ノードのID。

nrank

対等なノードまたは兄弟関係にあるノードをランク付けした数字。たとえば、AssetRelationTree表はこの列を使用して、コレクションの中にあるアセットの順序を決定します。

otype

ノードのオブジェクト・タイプ。たとえば、SitePlanTree表では、otypeは、pageというアセット・タイプ、またはサイトの名前(publication)です。AssetRelationTree表では、otypeはアセット・タイプであり、そのタイプのアセットのオブジェクト表の名前です。

oid

ノードが参照するオブジェクトのID。

oversion

将来の使用のために予約されています。

ncode

表の用途というコンテキストで、意味のある文字列を保持します。たとえば、SitePlanTreeでは、ノードが参照するページ・アセットが配置されているかどうかに基づいて、ncodeがplacedとunplacedのいずれかに設定されます。AssetRelationTreeでは、ncodeにアソシエーションの名前が保持されます。

11.1.3 コンテンツ表

コンテンツ表には、データが(オブジェクトでなく)水平データとして格納され、その情報は階層に編成できません。コンテンツ表は、簡易参照表として使用します。たとえば、次に示すのは、WebCenter Sitesデータベースに追加するコンテンツ表のほんの一部です。

- Source: 記事またはイメージのアセットのソースを特定するために使用される文字列を格納します。

- Category: 様々な方法でアセットを編成するために使用されるコードを保持します。

- StatusCode: アセットのステータスを表すコードを保持します。

これら3つの表はすべて、アセット・タイプ表(オブジェクト表)の様々な列の値を参照するために製品で使用される参照表です。

別の例では、WebCenter Sitesは、MimeTypeというコンテンツ表も追加します。この表には、スタイルシート・アセット・タイプおよびイメージファイル・アセット・タイプの「Mimetype」フィールドに表示されるMIMEタイプ・コードが保持されます。これらのアセット・タイプの「Mimetype」フィールドは、MimeType表に対し、その表のkeyword列に基づいて、MIMEタイプ・コードを問い合せます。

コンテンツ表の主キーの設定

コンテンツ表を作成したときには、ID列は作成されず、主キーがIDである必要もありません。これも、コンテンツ表とオブジェクト表の大きな違いです。

wcs_properties.json ファイルのcc.contentkeyプロパティは、すべてのコンテンツ表のデフォルトの主キーの名前を指定しています。コンテンツ表を新規作成するときには、cc.contentkeyプロパティで指定された名前の列を定義する責任があります。ただし、特定のコンテンツ表の主キーのIDは、wcs_properties.jsonファイル内にカスタム・プロパティを追加および設定することによってオーバーライドできます。このプロパティは、次のフォーマットを使用する必要があります。

cc.tablenameKey

たとえば、Booksというコンテンツ表を作成し、デフォルトの主キーをオーバーライドして、かわりにISBN列を使用するようにする場合は、cc.BooksKeyというプロパティを追加してISBNに設定します。

11.1.4 外部表

外部表とは、WebCenter Sitesで全面的に管理しているわけではない表です。たとえば、サイト・ページでは、ERPシステムで移入される表に対して問合せが実行され、WebCenter Sitesでは、その情報がサイトの訪問者に表示されます。

WebCenter Sitesは、独自のオブジェクト表やコンテンツ表の場合とまったく同じように、外部表に問い合せて結果セットをキャッシュできます。ただし、まずWebCenter Sitesに対してその外部表を特定することが必要で、そのためには、SystemInfo表にその外部表の行を追加します。これは、SystemInfo表で情報を変更する唯一の機会です。また、問合せ先の表が外部システムによって更新された場合は必ず、CatalogManagerのflushcatalogタグを使用して、WebCenter Sites結果セットのキャッシュをフラッシュしてください。そうしないと、それらの表に対してキャッシュされた結果セットが、最新のものでなくなる可能性があります。

結果セットのキャッシングの詳細は、「結果セットのキャッシングと問合せでの作業」を参照してください。

11.1.5 システム表

システム表はコアで、スキーマが固定されたWebCenter Sitesの表です。それらは独自のクラスによってWebCenter Sitesに実装され、他の表が従う(キャッシングなどの)ルールに従いません。

Explorerツールを使用して一部のシステム表に行を追加できますが、これらの表内の行はどのような方法でも追加または変更できません。データベースにシステム表を追加することもできません。

表11-2では、WebCenter Sitesのシステム表を一覧表示および定義しています。

表11-2 システム表

表

説明

ElementCatalog

システムで使用されるXMLエレメントまたはJSPエレメントをすべて一覧表示します。エレメントとは、コードのうち名前の付いた断片です。ElementCatalog表の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

SiteCatalog

WebCenter Sitesで提供されている各ページまたは各ページレットへのページ参照を一覧表示します。SiteCatalog表の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

SystemACL

WebCenter Sitesシステム用に作成されたアクセス制御リスト(ACL)のそれぞれに行があります。ACLはデータベース表に対する権限のセットです。

ACLの作成の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

ACLの使用によるオンライン・サイトへのユーザー管理の実装については、「管理システムのユーザーの管理」を参照してください。

SystemEvents

WebCenter Sitesで管理されているイベントのそれぞれに行があります。イベントは、あるスケジュールに従って行われるアクションを表しています。

WebCenter Sitesでは、APPEVENTタグとEMAILEVENTタグのいずれかを使用してイベントを設定すると、この表に行が挿入されます。

SystemInfo

WebCenter Sitesデータベースの中にあるすべての表を一覧表示し、さらにWebCenter Sitesで参照する必要のある外部表があればそれも一覧表示します。

SystemItemCache

キャッシュされるページ上にある特定のアイテム(たとえばアセット)に関する情報、具体的には、アイテムのID、アイテムが関連付けられているページ、キャッシュされた時刻を保持します。

SystemPageCache

キャッシュされるページに関する情報、具体的には、キャッシュ先のフォルダ、ファイル名を生成するために使用される問合せ、キャッシュされた時刻、有効期限の切れる時刻を保持します。

SystemSeedAccess

WebCenter Sitesデータベースの外側にあるが、そのWebCenter Sitesからアクセスできる(アクセス制御を含めた)Javaクラスを登録します。

SystemSQL

必要な数のページまたはページレットで再利用できるSQL問合せを保持します。この表にSQL問合せを格納して、ics.CallSQLメソッド、CALLSQL XMLタグ、ics:callsql JSPタグを使用して、それらの問合せを起動できます。次に、SQL問合せを変更する必要がある場合は、一度変更するのみで済みます。

SystemUserAttr

電子メール・アドレスなど、ユーザーに関する属性情報を格納します。この表は、LDAPでは使用されません。

SystemUsers

ページ、機能および表へのアクセスを許可されたすべてのユーザーを一覧表示します。この表は、LDAPでは使用されません。

11.1.6 表のタイプの特定

WebCenter Sitesデータベース内の任意の表の表タイプを判別するには、SystemInfo表を調べます。これは、データベース内のすべての表を一覧表示するシステム表です。

表タイプを判別するには:

1. Explorerを開き、WebCenter Sitesデータベースにログインします。

2. SystemInfo表をダブルクリックします。

3. 表のリストで、systable列を調べます。この列の値によって、表11-3に表される表のタイプが特定されます。

表11-3 表タイプの判別

systable列の値

定義

yes

システム表

no

コンテンツ表

obj

オブジェクト表

tree

ツリー表

fgn

外部表

注意:

自分のユーザー名に割り当てられた適切なACLがない場合、SystemInfo表を開いて調査することはできません。

11.2 列(フィールド)のタイプ

WebCenter Sitesデータベースの表を作成すると、その表にアセットが保持されているかどうかに関係なく、それらの表の列に、一般カテゴリのフィールド(列)タイプとして、次の3つを指定できます。

- 汎用的なフィールド・タイプ

- データベース固有のフィールド・タイプ

- WebCenter SitesのURLフィールド

この項には次のトピックが含まれます:

- 汎用的なフィールド・タイプ

- データベース固有のフィールド・タイプ

- WebCenter SitesのURLフィールドを使用した間接的なデータ格納

11.2.1 汎用的なフィールド・タイプ

汎用的なフィールド・タイプとは、WebCenter SitesでサポートされているいずれのDBMSでも機能するフィールド・タイプのことです。これらは、JDBC規格に準拠するようにマップされます。したがって、WebCenter Sitesシステムが別のDBMSに変わっても、現在使用しているデータベースは引き続き有効となります。

汎用的でJDBCに準拠したフィールド・タイプを使用している場合は、表の中のデータを変更および保持するために、CatalogManager API (CATALOGMANAGERというXMLタグまたはJSPタグ、あるいはics.CatalogManagerというJavaメソッド)を使用します。

表11-4には、WebCenter Sitesの汎用的なフィールド・タイプ、およびそのデータ型を定義する(wcs_properties.jsonファイル内の)データベース・プロパティの詳細なリストが含まれています。ExplorerツールまたはCatalogManager APIを使用して新しい表を作成する場合は常に、このリストを参照します。

表11-4 フィールド・タイプ

フィールド・タイプ

説明

プロパティ

CHAR(n)

文字数が正確にnであることを示す短縮文字列。

cc.char

VARCHAR(n)

文字数が最大でnであることを示す短縮文字列。たとえば、VARCHAR(32)とすると、この列には最大で32文字を保持ができるという意味になります。

cc.varchar

および

cc.maxvarcharsize

(cc.varcharに設定できる最大値は、cc.maxvarcharsizeプロパティの値によって異なります。)

DATETIME

日付と時刻の組合せ。

cc.datetime

TEXT

LONGVARCHAR: 最大2,147,483,647文字の可変長文字列

cc.bigtext

IMAGE

1つのバイナリ・ラージ・オブジェクト(blob)。

cc.blob

SMALLINT

16ビットの整数、つまり、-32,768から+32,767までの整数。

cc.smallint

INTEGER

32ビットの整数、つまり、-2,147,483,648から+2,147,483,647までの整数。

cc.integer

BIGINT

64ビットの整数、つまり、最大で19桁の整数。

cc.bigint

NUMERIC(L,P)

浮動小数点式の数(実数)で、有効桁の合計数がL、そのうちP桁が小数。たとえば、NUMERIC(5,2)は、806.35のような数値を表すことはあっても、25693.2283のような数値は厳密に表せません。

cc.numeric

DOUBLE

倍精度タイプ。

cc.double

列タイプを定義することに加えて、表11-5に示すように、列に対する制約のうち、該当する列に当てはまるものがどれであるかを指定する必要があります。

表11-5 列の制約

制約

説明

NULL

NULL値を保持できます。つまり、空にしておくことができます。

NOT NULL

NULL値を保持できません。つまり、空にしておくことができません。

UNIQUE NOT NULL

この表で間違いなく一意となる値を保持する必要があります。

PRIMARY KEY NOT NULL

コンテンツ表の主キー列にマークを付けます。オブジェクト表では、列に対してこの制約を設定しないでください。

AssetMakerを使用して新規のアセット・タイプのオブジェクト表を作成する場合、またはフレックス属性を作成する場合は、それらのアイテムのデータ型は、ここに一覧表示されているものとは異なります。

ベーシック・アセット・タイプの列のデータ型の詳細は、「列の記憶域のタイプ」を参照してください。フレックス属性のデータ型の詳細は、「属性のデータ型」を参照してください。

11.2.2 データベース固有のフィールド・タイプ

表ではデータベース固有のフィールド(列)タイプを使用できます。ただし、ある種類のDBMSに固有のフィールド・タイプ(つまり、JDBC規格にマップされていないタイプ)を使用する場合は、次の点に注意してください。

- これらの表に対しては、CatalogManager APIを使用できない場合があります。

- DBMSを変更することがあれば、表も変更する必要があります。

使用しているDBMSに固有のフィールド・タイプの詳細なリストについては、そのDBMSのドキュメントを参照してください。

11.2.3 WebCenter SitesのURLフィールドを使用した間接的なデータ格納

WebCenter Sitesデータベース内のオブジェクトおよびコンテンツ表には、列にデータを間接的に格納できるという独特の特性があります。大規模なデータをDBMSに外部的に格納できますが、これはデータ・リポジトリ内です。

そのような列を作成するには、先頭の文字をurlにした列名を使用する必要があります。列名の最初の3文字にurlを使用すると、WebCenter Sitesでは、その列が間接的なデータ列として扱われます。

次の理由に該当する場合は、URLフィールドを使用してください。

- 使用しているDBMSが、そこに格納しようとしているデータのサイズに対応できるほど大きなフィールドをサポートしていないとき

- 使用しているDBMSが、格納しようとしているデータを含めるための個々の表で十分なフィールドをサポートしていない場合

- フィールドのサイズが大きいと、データ選択のパフォーマンスが低下するため

注意:

URL列に格納しようとしているデータのサイズが、wcs_properties.jsonファイルのcc.maxvarcharsizeプロパティに設定された値を超過している場合は、そのデータは、データベース内のポインタによって参照されるファイルとして間接的に格納されるのではなく、データベースに格納されます。

デフォルトのストレージ・ディレクトリ(defdir)

URL列のある表では、デフォルトのストレージ・ディレクトリがその列に指定されている必要があります。このディレクトリは、その列に入力された値が実際に格納される場所です。

デフォルトのストレージ・ディレクトリという言い回しは、製品のいくつかの箇所ではdefdirという言葉に短縮されています。たとえば、SystemInfo表のdefdir列には、URL列のある表のデフォルトのストレージ・ディレクトリの名前が保持されます。AssetMakerユーティリティのフォームのいずれかには、defdirフィールドなどが提示されます。

URLフィールドに入力された値は、表のdefdir設定の値に付加されるため、実質的にはファイルの相対パスです。作成する表のdefdir値をどのように設定するかは、使用しているアプリケーションや作業内容によって異なります。

- CatalogManager APIを使用してWebCenter Sitesの表を新規作成する場合は、uploadDir引数を使用してdefdirの値を設定します。

- ベーシック・アセット・タイプを新規作成する場合は、「AssetMaker」フォームの「defdir」フィールドでdefdirの値を指定します。ベーシック・アセットを保持しているすべての表にはURL列があり、defdirの値が設定されている必要があります。

- フレックス・アセット・タイプを新規作成する場合は、フレックス・アセットの_Mungo表で、URL列のdefdirの値を指定しないでください。この値は、WebCenter Sitesのアプリケーションがインストールされたときに設定されたプロパティから取得されます。そのプロパティの値は変更しないでください。

注意:

URL列のある表が作成された後は、いかなる方法によっても、表のdefdir設定を変更しようとしないでください。変更した場合、ストレージ・ディレクトリとURL列の間のリンクが断たれ、データを取得できなくなります。

URLフィールドの作成については、次の手順と例を参照してください。

- 「フレックス・アセット・ファミリの作成」の例5-3からの、ベーシック・アセット・タイプのアップロード・フィールド例。

- 「フレックス・アセット・ファミリの作成」の(「タイプBlobのフレックス属性(アップロード・フィールド)の作成」)に記述されている、blob型のフレックス属性を作成するためのアップロード・フィールドの例。

11.3 システム表への追加について

システム表は作成できません。Explorerツールを使用して、行の追加先として許可されているシステム表に行を追加します。表11-6で説明するように、各システム表への情報の追加方法は異なります。

表11-6 情報をシステム表に追加する方法

表

情報を追加する方法

SiteCatalog

この表にページ・エントリを追加する方法はいくつかあります。

- Templateアセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するページ・エントリが自動的に作成されます。

- SiteEntryアセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するページ・エントリが自動的に作成されます。

ページ・エントリのページ・キャッシュ設定を設定または変更する場合は、Explorerを使用するよりも、WebCenter Sitesインタフェースでフォームを使用する方が簡単です。

ElementCatalog

この表にエレメントを追加する方法はいくつかあります。

- Templateアセットを作成すると、WebCenter Sitesでは、ElementCatalog表で、そのアセットに対するエントリが自動的に作成されます。

- CSElementアセットを作成すると、WebCenter Sitesでは、ElementCatalog表で、そのアセットに対するエントリが自動的に作成されます。

- Explorerツールを使用して、アセット以外のエレメントを追加できます。

エレメントおよびページのコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

SystemACL

User Access Managementノード内のACLフォーム。

詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

SystemEvents

WebCenter Sitesでは、APPEVENTタグ、EMAILEVENTタグ、またはそれらと同等のJava APIがエレメントから起動されたときに指定されたイベントごとに、この表に行が追加されます。

SystemInfo

この表に情報を追加することも、この表の情報を変更することもしないでください。

このルールに対する唯一の例外は、WebCenter Sitesに外部表を認識させる場合です。

SystemSQL

Explorerツール。

用意されている様々な種類の問合せについては、「結果セットのキャッシングと問合せでの作業」を参照してください。

SystemUsers

User Access Managementノード内のユーザー・フォーム。

詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

SystemUserAttr

User Access Managementノード内のユーザー・フォーム。

詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

11.4 プロパティ・ファイルおよびデータベースについて

wcs_properties.jsonファイルには、WebCenter Sitesデータベースへの接続を制御する様々なプロパティがあります。これらのプロパティによって、データベースの構成が指定され、データベースとアプリケーション・サーバー間に、権限の有無を問わず、ユーザー接続が確立します。

データベース・プロパティのすべては、システムのインストール時にシステムに構成されました。デフォルトでは、wcs_properties.jsonファイルで特定されているすべてのコマンドが、WebCenter Sitesデータベース上で動作します。wcs_properties.jsonファイル内のプロパティにアクセスするには、WebCenter Sites Adminインタフェース内のプロパティ管理ツールを使用します。

12 アセットを保持しない表内のデータ管理

この章では、アセットを保持しないWebCenter Sitesデータベース表とのやり取りについて説明します。カスタムの非アセット表内のデータを操作する方法は2通りあります。1つ目は、(a) CatalogManager API用のタグおよびメソッドを使用して、データの入力および管理用のフォームをプログラムでコーディングする方法です。2つ目は、(b) Explorerツールを使用して行の追加およびこれらの行へのデータの追加を手動で行う方法です。

アセットで作業するには、WebCenter Sitesインタフェースにログインし、WebCenter SitesとOracle WebCenter Sites: Engageアプリケーションで提供されるアセット・フォームを使用する必要があります。大量のアセットをプログラムで追加するには、XMLPostユーティリティを使用します。詳細は、「任意タイプのアセットのインポート」および「フレックス・アセットのインポート」を参照してください。

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

- 非アセット表でのメソッドおよびタグを使用したデータ管理のプログラミング

- データ・エントリ・フォームのコード化

- 非アセット表の削除に関する考慮事項

12.1 非アセット表でのメソッドおよびタグを使用したデータ管理のプログラミング

この項では、アセットを保持しない表のデータ管理とそれらの表との一般的なやり取りに関するプログラミングに使用するタグとメソッドの概要について説明します。

この項には次のトピックが含まれます:

- データの記述と取得について

- データの問合せのメソッド

- リストおよびデータ・リストの作成

12.1.1 データの記述と取得について

CatalogManagerはWebCenter Sitesのサーブレットで、データベースにあるコンテンツとオブジェクトの表を管理します。データベース内のツリー表は、TreeManagerサーブレットが管理します。

- CatalogManagerサーブレットにアクセスするには、ics.CatalogManager Javaメソッド、CATALOGMANAGER XMLタグまたはics:catalogmanager JSPタグを使用します。

- TreeManagerサーブレットにアクセスするには、ics.TreeManager Javaメソッド、TREEMANAGER XMLタグまたはics:treemanager JSPタグを使用します。

これらのメソッドとタグは、実行する操作およびその操作の実行対象である表を指定する引数から、名前と値のペアを取得します。

12.1.1.1 CatalogManagerを介したセキュリティ

ics.CatalogManager Javaメソッド、CATALOGMANAGER XMLタグおよびics:catalogmanager JSPタグは、オブジェクトとコンテンツ表で稼働する複数の属性をサポートします。キー属性はftcmdです。たとえば、ftcmdをaddrowに設定すると、CatalogManagerによりカタログに1行追加されます。

CatalogManagerセキュリティが有効な場合には、DefaultReader ACLを使用してCatalogManagerにアクセスできません。CatalogManagerセキュリティを有効にするには、wcs_properties.jsonファイルのsecure.CatalogManagerプロパティをtrueに設定します。CatalogManagerセキュリティが有効になっているときにCatalogManagerからログアウトを試みると、セッションが削除されるので注意してください。

表12-1に、メインのCATALOGMANAGER XMLタグ属性を示します。これらは、行のコンテンツまたは行内の特定のフィールドを変更する引数の名前と値のペアとして渡されます。

表12-1 CATALOGMANAGER XMLタグ

argument name="ftcmd" value=

説明

addrow

表に単一行を追加します。

addrows

表に複数の行を追加します。

deleterow

表から1行削除します。行の主キー列を指定する必要があります。

deleterows

表から複数の行を削除します。行の主キーを指定する必要があります。

replacerow

表内の既存の行を削除し、指定された情報に従って行を置換します。

replacerows

表の複数行を置換します。列の値が指定されていない場合、列の値は消去されます。

updaterow

指定された表に問合せを実行し、表からのレコードを表示します。表示される列は、パラメータの値で指定された基準と一致します。

updaterow2

updaterowと同様、表内の行の列内の値を更新します。ただし、updaterowを使用して列を消去できない場合には、updaterow2を使用すると指定された列に値がない(フォームに関連付けられたフィールドがないなど)場合でも列を消去できます。

updaterows

表内の複数の行に対するフィールド値を変更します。

updaterows2

updaterowsと同様、表内の複数の行に対するフィールド値を変更します。ただし、updaterowsを使用して列を消去できない場合には、updaterows2を使用すると指定された列に値がない(フォームに関連付けられたフィールドがないなど)場合でも列を消去できます。

コマンド・パラメータ(ftcmd)を持つCatalogManagerへのリクエストは、POSTリクエストまたは次のコマンドのいずれかである必要があります。

- exportlog

- exportForm

- logout

- selectFromTable

- selectCount

- mirrorgetconfig

- listtables

- retrieve

- retrievebinary

- pingdb

- interrogatetbl

- checksession

- history

- retrieverevision

CatalogManagerコマンドの詳細および完全なリストは、Oracle WebCenter Sitesタグ・リファレンスを参照してください。ics.CatalogManager Javaメソッドの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

12.1.1.2 ツリー表を管理するためのTreeManagerコマンド

表12-2に、メインのics.TreeManagerコマンドを示します。これらの操作はツリー表のデータのみをコントロールし、ツリー表のノードが参照するオブジェクトには影響を与えません。

表12-2 TreeManagerのコマンド

名前

説明

addchild

親ノードを指定された場合、子ノードを追加します。

addchildren

複数の子ノードを追加します。

copychild

ノードとその子を別の親にコピーします。コピーされたノードはすべて同じオブジェクトをポイントします。

createtree

ツリー表を作成します。

delchild

ノードとその子ノードを削除します。

delchildren

複数のノードを削除します。

deletetree

ツリー表を削除します。

findnode

ツリーのノードを検索します。

getchildren

すべての子ノードを取得します。

getnode

ノードおよびオブジェクトの属性(オプション)を取得します。

getparent

ノードに親を取得します。

listtrees

すべてのツリー表を取得します。

movechild

ノードとその子ノードを別の親に移動します。

nodepath

親、子のパスをノードに返します。

setobject

異なるオブジェクトをノードに関連付けます。

validatenode

ノードがツリーに存在することを確認します。

verifypath

指定されたパスがツリーに存在することを確認します。

ics.TreeManagerメソッドの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

XMLタグとJSP TREEMANAGERタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

12.1.2 データの問合せのメソッド

表12-3に、コード問合せをサポートしてコンテンツを選択するために一連のXMLおよびJSPのタグを備えた3つのメソッドを示します。

表12-3 データの問合せ

メソッド

XMLタグ

JSPタグ

説明

ics.SelectTo

SELECTTO

ics:selectto

単一の表に対して単一の選択を実行します。

ics.SQL

EXECSQL

ics:sql

インラインSQL文(コードに埋込み済)を実行します。

ics.CallSQL

CALLSQL

ics:callsql

SystemSQL表に行として格納されているSQL文を実行します。

ics.CallSQL(またはタグ)を使用するには、SQL文をコード化してSystemSQL表に貼り付けます。SystemSQL表の実際の問合せを格納し、(ページ名やエレメントをコールする場合と同様に)その問合せを個々のページからコールすることで、コードの外部に問合せが保持されるため、サイトで使用されるSQLが管理しやすくなります。SQLを変更する場合、そのSQLを使用するすべての場所で修正する必要はありません。SystemSQL表でSQLを編集すれば、すべてのエレメントで、編集したバージョンをコールするようになります。

ics.CallSQLメソッドとics.SQLメソッドは、いずれの有効なSQLコマンドも実行できます。SQL文が使用可能なリストを返さない場合、WebCenter Sitesではエラーが生成されます。SQLを使用してデータを更新するか挿入するには、ics.FlushCatalogメソッドを使用して、適切な表に対してキャッシュされた結果セットを明示的にフラッシュするコードを追加する必要があります。

12.1.3 リストおよびデータ・リストの作成

複数のICSメソッドにより、リストが作成されます。たとえば、SelectToメソッドはリスト内の簡単なSQL問合せの結果を返します。このリストの列は、WHAT句内の項目を反映し、行は表に対する一致を反映しています。

IListインタフェースは、Javaからのリストのアクセスに使用されます。リストは、XMLまたはJSPを使用して名前別に利用でき、値はLOOPタグを使用して反復できます。WebCenter Sitesで作成されたリストは、データベースの問合せから作成された基礎となる結果セットをポイントします。リストはリクエスト間で永続的にはなりませんが、結果セットはキャッシュされていれば永続的になります。

注意:

必ず結果セットのキャッシュを適切に構成してください。リストは、問合せのキャッシュされている結果セットのコピーをポイントします。結果セットがキャッシュされていない場合、リストは結果セットを直接ポイントし、データベースの接続リソースに問題を発生することがあります。

IListインタフェースに基づいたクラスを実装することで、XMLまたはJSPでの使用に対応した独自のリストを作成できます。アプリケーションやページでリストの項目を返す前にデータを変換したり、多数のリストから単一のリストを作成できるようになります。表12-4に、リストを管理するメソッドを示します。

表12-4 リストを管理するメソッド

メソッド

説明

ics.GetList

指定されたリスト名のIListを返します。

ics.CopyList

リストをコピーします。

ics.RenameList

既存リストの名前を変更します。

ics.RegisterList

WebCenter Sitesにリストを名前登録して、このリストをXMLまたはJSPエレメントから参照したり、GetListメソッドを使用して参照できるようにします。

IListの導入の例については、WebCenter SitesシステムのSamplesフォルダにあるSampleIList.javaを参照してください。

12.2 データ・エントリ・フォームのコード化

この項では、ユーザーや訪問者が入力した情報を受け入れるフォームのコード化方法、およびWebCenter Sitesメソッドとタグを使用してデータベースに情報を書き込む方法を示すコード・サンプルについて説明します。この項の例は、新しい行の追加、行の削除、既存の行の問合せとその後の編集について説明しています。各例には、XML、JSPおよびJavaのバージョンが示されています。

この項には次のトピックが含まれます:

- 行の追加方法

- 行の削除方法

- 表の問合せ方法

- 埋め込まれたSQL文を使用した表の問合せ方法

12.2.1 行の追加方法

行を追加する単一のアルゴリズムは、次のとおりです。

1. 情報をリクエストするフォームを行内の各フィールドに表示します。

2. フォームのデータを表に書き込みます。

次の例では、表12-5に示す列を使用してEmployeeInfoという名前の架空の表に行を追加します。

表12-5 表への行の追加の例

フィールド

データ型

id

VARCHAR(6)

phone

VARCHAR(16)

name

VARCHAR(32)

この例は、次のエレメントのコードを示しています。

- addrowFORM: 従業員のID番号、電話番号および名前をリクエストするフォームを表示するXMLエレメントです。

- addrowXML、addrowJSPおよびaddrowJAVA: 従業員が入力した情報をEmployeeInfo表に書き込む、3つのバージョンのエレメントです。

12.2.1.1 addrowFORMエレメント

addrowFORMエレメントは、ユーザーに従業員名、IDおよび電話番号の入力を求めるフォームを表示します。

これは、フォームを作成するコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/addrowFORM
-->

<form ACTION="ContentServer" method="post"
REPLACEALL="CS.Property.ft.cgipath">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/addrow"/>

<table>
<tr>
<td>Employee name:</td>
<td><input type="text" value="" name="EmployeeName" size="22" maxlength="32"/></td>
</tr>
<tr>
<td>Employee id number:</td>
<td><input type="text" value="" name="EmployeeID" size="6" maxlength="6"/></td>
</tr>
<tr>
<td>Phone number:</td>
<td><input type="text" value="" name="EmployeePhone" size="12" maxlength="16"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" name="submit" value="Submit"/></td>
</tr>
</table>

</form>
</FTCS>

<INPUT>のmaxlength修飾子は、各入力の長さをスキーマで定義された最大長に制限することに注意してください。

ユーザーはフォームに入力し、「送信」ボタンをクリックします。フォームとaddrowページ(前述のコード・サンプルの最初のinput type文を参照)のページ名で収集された情報がブラウザに送信されます。ブラウザはページ名をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表内が検索され、そのページ・エントリのルート・エレメントが起動されます。

12.2.1.2 addrowページのルート・エレメント

addrowページのルート・エレメントは、addrowFORMエレメントから渡された情報をデータベースに追加します。つまり、EmployeeInfo表に行を追加し、その行に、addrowFORMエレメントから渡された情報を移入します。

WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。この項では、addrowページに対応する次の3つのバージョンのルート・エレメントを示します。

- addrowXML.xml

- addrowJSP.jsp

- addrowJAVA.jsp

addrowXML

これは、ルート・エレメントのXMLバージョンのコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/addrowXML
-->

<SETVAR NAME="errno" VALUE="0"/>
<CATALOGMANAGER>

<ARGUMENT NAME="ftcmd" VALUE="addrow"/>
<ARGUMENT NAME="tablename" VALUE="EmployeeInfo"/>
<ARGUMENT NAME="id" VALUE="Variables.EmployeeID"/>
<ARGUMENT NAME="phone" VALUE="Variables.EmployeePhone"/>
<ARGUMENT NAME="name" VALUE="Variables.EmployeeName"/>

</CATALOGMANAGER>
errno=<CSVAR NAME="Variables.errno"/><br/>
</FTCS>

注意:

サンプル・コードでは、架空の表EmployeeInfoにWebCenter Sitesの汎用フィールド・タイプが備わっているため、CATALOGMANAGERタグを使用できます。EmployeeInfoにデータベース固有のフィールド・タイプが含まれている場合、addrowXMLは機能しません。詳細は、「汎用的なフィールド・タイプ」を参照してください。

addrowJSP

これは、ルート・エレメントのJSPバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%//
// Documentation/CatalogManager/addrowJSP
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<ics:setvar name="errno" value="0"/>
<ics:catalogmanager>

<ics:argument name="ftcmd" value="addrow"/>
<ics:argument name="tablename" value="EmployeeInfo"/>
<ics:argument name="id"
value='<%=ics.GetVar("EmployeeID")%>'/>
<ics:argument name="phone"
value='<%=ics.GetVar("EmployeePhone")%>'/>
<ics:argument name="name" value='<%=ics.GetVar("EmployeeName")%>'/>

</ics:catalogmanager>

errno=<ics:getvar name="errno"/><br/>

</cs:ftcs>

addrowJAVA

これは、ルート・エレメントのJavaバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%//
// Documentation/CatalogManager/addrowJAVA
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<!-- user code here -->
<%
ics.SetVar("errno","0");
FTValList vl = new FTValList();
vl.put("ftcmd","addrow");
vl.put("tablename","EmployeeInfo");
vl.put("id",ics.GetVar("EmployeeID"));
vl.put("phone",ics.GetVar("EmployeePhone"));
vl.put("name",ics.GetVar("EmployeeName"));
ics.CatalogManager(vl);
%>
errno=<%=ics.GetVar("errno")%><br />

</cs:ftcs>

12.2.2 行の削除方法

次の例では、「行の追加方法」で説明されている架空のEmployeeInfo表から行を削除します。

この項では、次のエレメントからのコードを示します。

- deleterowFORM: EmployeeInfo表から削除する従業員名をリクエストするフォームを表示するXMLエレメントです。

- deleterowXML、deleterowJSPおよびdeleterowJAVA: deleterowFORMエレメントから送信された情報に基づいて、EmployeeInfo表から行を削除するエレメントです。

12.2.2.1 deleterowFORMエレメント

deleterowFORMエレメントは、ユーザーに従業員名の入力を求めるフォームを表示します。これは、フォームを作成するコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/deleterowFORM
-->

<form ACTION="ContentServer" method="post" REPLACEALL="CS.Property.ft.cgipath">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/deleterow"/>

<table>
<tr>

<td>Employee name:</td>
<td><input type="text" value="Barton Fooman" name="EmployeeName" size="22" maxlength="32"/></td>

</tr>
<tr>

<td colspan="2"><input type="submit" name="submit" value="submit"/></td>

</tr>
</table>
</form>
</FTCS>

ユーザーは従業員名を入力し、「送信」ボタンをクリックします。従業員名とdeleterowページ(前述のコード・サンプルの最初のinput type文を参照)のページ名がブラウザに送信されます。ブラウザはページ名をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表内が検索され、そのページ・エントリのルート・エレメントが起動されます。

12.2.2.2 deleterowページのルート・エレメント

deleterowページのルート・エレメントは、EmployeeInfo表にdeleterowFORMエレメントから送信された従業員名に基づいて、その表から行を削除します。WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。この項では、deleterowページに対応する次の3バージョンのルート・エレメントを示します。

- deleterowXML.xml

- deleterowJSP.jsp

- deleterowJAVA.jsp

deleterowXML

これは、エレメントのXMLバージョンのコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/deleterowXML
-->
<SETVAR NAME="errno" VALUE="0"/>

<CATALOGMANAGER>

<ARGUMENT NAME="ftcmd" VALUE="deleterow"/>
<ARGUMENT NAME="tablename" VALUE="EmployeeInfo"/>
<ARGUMENT NAME="tablekey" VALUE="name"/>
<ARGUMENT NAME="tablekeyvalue" VALUE="Variables.EmployeeName"/>

</CATALOGMANAGER>

errno=<CSVAR NAME="Variables.errno"/><br/>
</FTCS>

deleterowJSP

これは、エレメントのJSPバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%//
// Documentation/CatalogManager/deleterowJSP
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<!-- user code here -->
<!-- user code here -->
<ics:setvar name="errno" value="0"/>
<ics:catalogmanager>

<ics:argument name="ftcmd" value="deleterow"/>
<ics:argument name="tablename" value="EmployeeInfo"/>
<ics:argument name="name" value='<%=ics.GetVar("EmployeeName")%>'/>

</ics:catalogmanager>

errno=<ics:getvar name="errno"/><br />

</cs:ftcs>

deleterowJAVA

これは、エレメントのJavaバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%//
// Documentation/CatalogManager/deleterowJAVA
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<%
ics.SetVar("errno","0");
FTValList vl = new FTValList();
vl.put("ftcmd","deleterow");
vl.put("tablename","EmployeeInfo");
vl.put("name",ics.GetVar("EmployeeName"));
ics.CatalogManager(vl);
%>
errno=<%=ics.GetVar("errno")%><br />

</cs:ftcs>

12.2.3 表の問合せ方法

次のサンプル・エレメントは、架空のEmployeeInfo表に従業員名を問い合せ、従業員名を抽出してブラウザに表示し、ユーザーに情報を編集するよう要求し、編集済の情報をデータベースに書き込みます。

この項では、次のエレメントからのコードを示します。

- SelectNameForm: 従業員名をリクエストするフォームを表示するXMLエレメントです。

- 3つのバージョンのQueryEditRowFormエレメント(XML、JSPおよびJava): 従業員名を検索し、従業員に関する情報をフォームにロードして、従業員が自分の情報をそのフォームで編集できるようにするエレメントです。

- 3つのバージョンのQueryEditRowエレメント(XML、JSPおよびJava): 新規編集済の情報をデータベースへ書き込むエレメントです。

12.2.3.1 SelectNameFormエレメント

SelectNameFormエレメントは、従業員情報を変更している従業員名をリクエストするシンプル・フォームを表示します。コードは次のとおりです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/SelectNameForm
-->

<form ACTION="ContentServer" method="post">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/QueryEditRowForm"/>
<TABLE>
<TR>
<TD>Employee name: </TD>
<TD><INPUT type="text" value="" name="EmployeeName" size="22" maxlength="32"/></TD>
</TR>
<TR>
<TD COLSPAN="100%" ALIGN="CENTER">
<input type="submit" name="doit" value="Submit"/></TD>
</TR>
</TABLE>
</form>
</FTCS>

従業員が「送信」ボタンをクリックすると、「従業員名」フィールドとQueryEditRowFormページの名前(前述のコード・サンプルの最初のinput type文を参照)で収集された情報がブラウザに送信されます。ブラウザはページ名をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表でページ名が検索され、そのページ・エントリのルート・エレメントQueryEditRowFormが起動されます。

12.2.3.2 QueryEditRowFormページのルート・エレメント

QueryEditRowFormページのルート・エレメントは、EmployeeInfo表で「従業員名」フィールドに入力した文字列と一致する行を検出し、データをその行から新しいフォームにロードします。従業員は自分の名前と電話番号は編集できますが、ID番号は編集できません。

従業員情報の変更フォームは図12-1のようになります。

図12-1 従業員情報の変更フォーム

WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。この項では、QueryEditRowFormページに対応する次の3つのバージョンのルート・エレメントを示します。

- QueryEditRowFormXML.xml

- QueryEditRowFormJSP.jsp

- QueryEditRowFormJAVA.jsp

QueryEditRowFormXML

これは、エレメントのXMLバージョンのコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/QueryEditRowFormXML
-->

<SETVAR NAME="errno" VALUE="0"/>
<SETVAR NAME="name" VALUE="Variables.EmployeeName"/>
<SELECTTO FROM="EmployeeInfo"
WHERE="name"
WHAT="*"
LIST="MatchingEmployees"/>

<IF COND="Variables.errno=0">
<THEN>
<form ACTION="ContentServer" method="post">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/QueryEditRow"/>
<input type="hidden" name="MatchingID" value="MatchingEmployees.id" REPLACEALL="MatchingEmployees.id"/>
<TABLE>
<TR>
<TD COLSPAN="100%" ALIGN="CENTER">
<H3>Change Employee Information</H3>
</TD>
</TR>
<TR>
<TD>Employee id number: </TD>
<TD><CSVAR NAME="MatchingEmployees.id"/></TD>
</TR>
<TR>
<TD>Employee name: </TD>
<TD><INPUT type="text" value="MatchingEmployees.name" name="NewEmployeeName" size="22" maxlength="32" REPLACEALL="MatchingEmployees.name"/></TD>
</TR>
<TR>
<TD>Phone number: </TD>
<TD><INPUT type="text" value="MatchingEmployees.phone" name="NewEmployeePhone" size="12" maxlength="16" REPLACEALL="MatchingEmployees.phone"/></TD>
</TR>
<TR>
<TD colspan="100%" align="center">
<input type="submit" name="doit" value="Change"/></TD>
</TR>
</TABLE>
</form>
</THEN>
<ELSE>
<P>Could not find this employee.</P>
<CALLELEMENT NAME="Documentation/CatalogManager/SelectNameFormXML"/>
</ELSE>
</IF>
</FTCS>

従業員が「変更」ボタンをクリックすると、2つのフィールドから収集された情報とQueryEditRowページの名前がブラウザに送信されます。ブラウザはページ名とフィールド情報をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

QueryEditRowFormJSP

これは、エレメントのJSPバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%//
// Documentation/CatalogManager/QueryEditRowFormJSP
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<ics:setvar name="errno" value="0"/>
<ics:setvar name="name" value='<%=ics.GetVar("EmployeeName")%>'/>
<ics:selectto table="EmployeeInfo"
where="name"
what="*"
listname="MatchingEmployees"/>

<ics:if condition='<%=ics.GetVar("errno").equals("0")%>'>
<ics:then>
<form action="ContentServer" method="post">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/QueryEditRow"/>
<input type="hidden" name="MatchingID" value="<ics:listget listname='MatchingEmployees' fieldname='id'/>"/>
<TABLE>
<TR>
<TD COLSPAN="100%" ALIGN="CENTER">
<H3>Change Employee Information</H3>
</TD>
</TR>
<TR>
<TD>Employee id number: </TD>
<TD><ics:listget listname='MatchingEmployees
fieldname='id'/></TD>
</TR>
<TR>
<TD>Employee name: </TD>
<TD><INPUT type="text" value="<ics:listget
listname='MatchingEmployees' fieldname='name'/>"
name="NewEmployeeName" size="22" maxlength="32"/></TD>
</TR>
<TR>
<TD>Phone number: </TD>
<TD><INPUT type="text" value="<ics:listget
listname='MatchingEmployees' fieldname='phone'/>"
name="NewEmployeePhone" size="12" maxlength="16"/>
</TD>
</TR>
<TR>
<TD colspan="100%" align="center">
<input type="submit" name="doit" value="Change"/></TD>
</TR>
</TABLE>
</form>
</ics:then>
<ics:else>
<P>Could not find this employee.</P>
<ics:callelement element="Documentation/CatalogManager/
SelectNameForm"/>
</ics:else>
</ics:if>

</cs:ftcs>

従業員が「変更」ボタンをクリックすると、2つのフィールドから収集された情報とQueryEditRowページの名前がブラウザに送信されます。ブラウザはページ名とフィールド情報をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

QueryEditRowFormJAVA

これは、エレメントのJavaバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%//
// Documentation/CatalogManager/QueryEditRowFormJAVA
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<!-- user code here -->
<%
ics.SetVar("errno","0");
ics.SetVar("name",ics.GetVar("EmployeeName"));
StringBuffer errstr = new StringBuffer();
IList matchingEmployees = ics.SelectTo("EmployeeInfo",// tablename
*", // what
"name", // where
"name", // orderby
1, // limit
null, // ics list name
true, // cache?
errstr); // error StringBuffer

if ("0".equals(ics.GetVar("errno")) && matchingEmployees!=null && matchingEmployees.hasData())
{
%>
<form action="ContentServer" method="post">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/QueryEditRow"/>
<%
String id = matchingEmployees.getValue("id");
String name = matchingEmployees.getValue("name");
String phone = matchingEmployees.getValue("phone");
%>
<input type="hidden" name="MatchingID" value="<%=id%>"/>
<TABLE>
<TR>
<TD COLSPAN="100%" ALIGN="CENTER">
<H3>Change Employee Information</H3>
</TD>
</TR>
<TR>
<TD>Employee id number: </TD>
<TD><%=id%></TD>
</TR>
<TR>
<TD>Employee name: </TD>
<TD><INPUT type="text" value="<%=name%>" name="NewEmployeeName" size="22" maxlength="32"/></TD>
</TR>
<TR>
<TD>Phone number: </TD>
<TD><INPUT type="text" value="<%=phone%>" name="NewEmployeePhone" size="12" maxlength="16"/></TD>
</TR>
<TR>
<TD colspan="100%" align="center">
<input type="submit" name="doit" value="Change"/></TD>
</TR>
</TABLE>
</form>
<%
}
else
{
%><P>Could not find this employee.</P>
<%
ics.CallElement("Documentation/CatalogManager/SelectNameForm",null);
}
%>
</cs:ftcs>

従業員が「変更」ボタンをクリックすると、2つのフィールドから収集された情報とQueryEditRowページの名前がブラウザに送信されます。ブラウザはページ名とフィールド情報をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

12.2.3.3 QueryEditRowページのルート・エレメント

QueryEditRowページのルート・エレメントは、従業員が「従業員名」フィールドと「電話番号」フィールドに入力した情報を書き込み、データベースの行を更新します。

WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。この項では、QueryEditRowページに対応する次の3つのバージョンのルート・エレメントを示します。

- QueryEditRowXML.xml

- QueryEditRowJSP.jsp

- QueryEditRowJAVA.jsp

QueryEditRowXML

これは、エレメントのXMLバージョンのコードです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/QueryEditRowXML
-->

<SETVAR NAME="errno" VALUE="0"/>

<CATALOGMANAGER>
<ARGUMENT NAME="ftcmd" VALUE="updaterow"/>
<ARGUMENT NAME="tablename" VALUE="EmployeeInfo"/>
<ARGUMENT NAME="id" VALUE="Variables.MatchingID"/>
<ARGUMENT NAME="name" VALUE="Variables.NewEmployeeName"/>
<ARGUMENT NAME="phone" VALUE="Variables.NewEmployeePhone"/>
</CATALOGMANAGER>

<IF COND="Variables.errno=0">
<THEN>
<P>Successfully updated the database.</P>
</THEN>
<ELSE>
<P>Failed to update the information in the database.</P>
</ELSE>
</IF>
</FTCS>

QueryEditRowJSP

これは、エレメントのJSPバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%//
// Documentation/CatalogManager/QueryEditRowJSP
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<ics:setvar name="errno" value="0"/>

<ics:catalogmanager>
<ics:argument name="ftcmd" value="updaterow"/>
<ics:argument name="tablename" value="EmployeeInfo"/>
<ics:argument name="id" value="<%=ics.GetVar("MatchingID")%>"/>
<ics:argument name="name"
value='<%=ics.GetVar("NewEmployeeName")%>'/>
<ics:argument name="phone"
value='<%=ics.GetVar("NewEmployeePhone")%>'/>
</ics:catalogmanager>

<ics:if condition='<%=ics.GetVar("errno").equals("0")%>'>
<ics:then>
<P>Successfully updated the database.</P>
</ics:then>
<ics:else>
<p>failed to update the information in the database. errno=<ics:getvar name='errno'/></p>
</ics:else>
</ics:if>

</cs:ftcs>

QueryEditRowJAVA

これは、エレメントのJavaバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%//
// Documentation/CatalogManager/QueryEditRowJAVA
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<!-- user code here -->
<%
ics.SetVar("errno","0");

FTValList args = new FTValList();
args.put("ftcmd","updaterow");
args.put("tablename","EmployeeInfo");
args.put("id",ics.GetVar("MatchingID"));
args.put("name",ics.GetVar("NewEmployeeName"));
args.put("phone",ics.GetVar("NewEmployeePhone"));

ics.CatalogManager(args);

if("0".equals(ics.GetVar("errno")))
{
%><P>Successfully updated the database.</P><%
}
else
{
%><p>failed to update the information in the database. errno=<ics:getvar name='errno'/></p><%
}
%>
</cs:ftcs>

12.2.4 埋め込まれたSQL文を使用した表の問合せ方法

次の例は、表内の名前を検索するもう1つの方法を示しています。この例ではまた、架空のEmployeeInfo表を検索し、ユーザーによって入力された文字列と一致する行を返します。しかし、今回は、コードで、SELECTTO文ではなくSQL問合せを使用します。

この項では、次のエレメントからのコードを示します。

- QueryInlineSQLForm: 映画のタイトルをリクエストするフォームを表示するXMLエレメントです。

- 3つのバージョンのQueryInlineSQLエレメント(XML、JSPおよびJava): EmployeeInfo表で前述のフォームにユーザーが入力した文字列を含む名前を検索します。

12.2.4.1 QueryInlineSQLForm

QueryInlineSQLエレメントは、EmployeeInfo表で検索するための名前をリクエストするシンプル・フォームを表示します。コードは次のとおりです。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/QueryInlineSQLForm
-->
<form ACTION="ContentServer" method="post">
<input type="hidden" name="pagename" value="Documentation/CatalogManager/QueryInlineSQL"/>

<table>
<tr>
<td>Employee Name:</td>
<td><input type="text" value="Foo,Bar" name="EmployeeName" size="22" maxlength="32"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" name="submit" value="submit"/></td>
</tr>
</table>

</form>
</FTCS>

ユーザーが「送信」ボタンをクリックすると、「従業員名」フィールドで収集された情報と、QueryInlineSQLページの名前がブラウザに送信されます。ブラウザは、QueryInlineSQLページのページ名をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

12.2.4.2 QueryInlineSQLページのルート・エレメント

QueryInlineSQLページのルート・エレメントは、QueryInlineSQLFormエレメントからEmployeeInfo表に送信された文字列と一致するエントリを、その表で検索するインラインSQL文を実行します。WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。この項では、QueryInlineSQLページに対応する次の3つのバージョンのルート・エレメントを示します。

- QueryInlineSQLXML.xml: EXECSQL XMLタグを使用してSQL問合せを作成します。

- QueryInlineSQLJSP.jsp: ics:sql JSPタグを使用してSQL問合せを作成します。

- QueryInlineSQLJAVA.jsp: ics.CallSQL Javaメソッドを使用してSQL問合せを作成します。

QueryInlineSQLXML

これは、エレメントのXMLバージョンのコードです。

<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Documentation/CatalogManager/QueryInlineSQLXML
-->

<SETVAR NAME="tablename" VALUE="EmployeeInfo"/>

<SQLEXP OUTSTR="MySQLExpression"
TYPE="OR"
VERB="LIKE"
STR="Variables.EmployeeName"
COLNAME="name"/>

<EXECSQL
SQL="SELECT id,name,phone FROM Variables.tablename WHERE Variables.MySQLExpression"
LIST="ReturnedList"
LIMIT="5"/>

<table border="1" bgcolor="99ccff">
<tr>
<th>id</th>
<th>name</th>
<th>phone</th>
</tr>

<LOOP LIST="ReturnedList">
<tr>
<td><CSVAR NAME="ReturnedList.id"/></td>
<td><CSVAR NAME="ReturnedList.name"/></td>
<td><CSVAR NAME="ReturnedList.phone"/></td>
</tr>
</LOOP>
</table>

</FTCS>

SQL文は、実際にはEXECSQLタグに埋め込まれていません。かわりに、前述のSQLEXPタグがSQL式を作成し、それが引数としてEXECSQLコールに渡されます。EXECSQLタグは検索を実行し、結果をReturnedListという名前のリスト変数に返します。また、エレメントの本文の最初の行はtablenameという名前の変数を作成し、問い合せられた表の名前であるEmployeeInfoに値を設定します。これにより、CatalogManagerは正確な表に対する結果セットをキャッシュできるようになります。

QueryInlineSQLJSP

これは、エレメントのJSPバージョンのコードです。

<?xml version="1.0" ?>
<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%//
// Documentation/CatalogManager/QueryInlineSQLJSP
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<!-- user code here -->
<ics:setvar name="tablename" value="EmployeeInfo"/>

<%
// no ics:sqlexp tag, must do in Java
String sqlexp = ics.SQLExp("EmployeeInfo","OR","LIKE",ics.GetVar("EmployeeName"),"name");
String sql = "SELECT id,name,phone FROM "+ics.GetVar("tablename")+" WHERE "+sqlexp;
%>
<ics:sqltable='<%=ics.GetVar("tablename")%>'
sql='<%=sql%>'
listname="ReturnedList"
limit="5"/>

<table border="1" bgcolor="99ccff">
<tr>
<th>id</th>
<th>name</th>
<th>phone</th>
</tr>

<ics:listloop listname="ReturnedList">
<tr>
<td><ics:listget listname="ReturnedList" fieldname="id"/></td>
<td><ics:listget listname="ReturnedList" fieldname="name"/></td>
<td><ics:listget listname="ReturnedList" fieldname="phone"/></td>
</tr>
</ics:listloop>

</table>

</cs:ftcs>

SQL文は、実際にはics:sqlタグに埋め込まれていません。かわりに、前述のJava式がSQL式を作成し、それが引数としてics:sql コールに渡されます。(サンプル・コードではJSPに相当するSQLEXPタグがないため、Javaが使用されます。)ics:sqlタグは検索を実行し、結果をReturnedListという名前のリスト変数に返します。また、エレメントの本文の最初の行はtablenameという名前の変数を作成し、問い合せられた表の名前であるEmployeeInfoに値を設定します。これにより、CatalogManagerは正確な表に対する結果セットをキャッシュできるようになります。

QueryInlineSQLJava

これは、エレメントのJavaバージョンのコードです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%//
// Documentation/CatalogManager/QueryInlineSQLJAVA
//%>
<%@ page import="COM.FutureTense.Interfaces.*" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<cs:ftcs>

<%

ics.SetVar("tablename","EmployeeInfo");

String sqlexp = ics.SQLExp(ics.GetVar("tablename"),"OR","LIKE",ics.GetVar("EmployeeName"),"name");
String sql = "SELECT id,name,phone FROM "+ics.GetVar("tablename")+" WHERE "+sqlexp;
StringBuffer errstr = new StringBuffer();

IList list = ics.SQL(ics.GetVar("tablename"),sql,null,5,true,errstr);

%>

<table border="1" bgcolor="99ccff">
<tr>
<th>id</th>
<th>name</th>
<th>phone</th>
</tr>

<%

while (true)
{
%>
<tr>
<td><%=list.getValue("id")%></td>
<td><%=list.getValue("name")%></td>
<td><%=list.getValue("phone")%></td>
</tr>
<%
if (list.currentRow() == list.numRows())
break;
list.moveTo(list.currentRow()+1);
}
%>

</table>
</cs:ftcs>

SQL文は、実際にはics.SQL文に埋め込まれていません。かわりに、前述のics.SQLExp文がSQL式を作成し、それが引数としてEXECSQLコールに渡されます。ics.SQL 文は検索を実行し、結果をReturnedListという名前のリスト変数に返します。このコードは問合せのコードの前にtablenameという名前の変数も作成し、値をEmployeeInfo(問合せ先の表名)に設定します。これにより、CatalogManagerは正確な表に対する結果セットをキャッシュできるようになります。

12.3 非アセット表の削除に関する考慮事項

追跡対象のリビジョンである非アセット表を削除するには、最初に表に対するリビジョン追跡を無効にします。それ以外の場合、表を削除できません。

第III部 Webサイトの開発

この部では、WebCenter Sitesを使用してプログラミングのプロセスを開始する方法について説明します。また、ページレットをWebCenter Sitesのキャッシュに格納したり、Webサイトの訪問者に古いページが表示されないように、これらのキャッシュを管理したりするなど、多くの有用なタスク実行できるようにするWebCenter SitesのタグおよびJavaメソッドについても紹介します。続いて、XMLタグの使用方法、およびCSElementアセット・タイプ、テンプレート・アセットタイプおよびSiteEntryアセット・タイプの作成方法について説明します。テンプレートおよびラッパーの使用に関する情報も紹介します。

この部は、コンテキスト内編集およびプレゼンテーション編集用のテンプレートのコーディングについても説明します。オンライン・サイトの機能を実装するページ、問合せおよびコレクションの各アセットの作成、将来サイト・プレビュー機能の実装、およびテンプレート・アセットおよびCSElementアセット用に作成するエレメントのコーディングの各手順について説明します。ベーシック・アセットの使用例も紹介します。最後に、サイトの多言語サポートの構成について説明します。

この部は、次の章で構成されています。

- MVCフレークワークおよびAPIを使用したWebsサイト開発

- サーバー側Webサイトの開発

- クライアント側Webサイトの開発

- タグ・テクノロジを使用したWebサイト開発

- セッションおよびCookieについて

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成

- テンプレートとラッパーの作成

- コンテキスト内編集およびプレゼンテーション編集用テンプレートのコーディング

- コレクション・アセット、問合せアセットおよびページ・アセットの作成

- 将来サイト・プレビュー・アセットおよびテンプレートを作成するためのベスト・プラクティス

- テンプレートおよびCSElementのエレメントのコーディング

- ベーシック・アセットのテンプレート・エレメント例

- 多言語サポートのサイトの構成

13 MVCフレークワークおよびAPIを使用したWebsサイト開発

Oracle WebCenter Sitesでは、サーバー側Webサイトの開発用のモデル・ビュー・コントローラ(MVC)フレームワークとJava API、およびクライアント側でレンダリングされるWebサイトの構築用REST APIが用意されています。

次の各項では、これらのテクノロジについて説明します。

- サーバー側およびクライアント側の開発方法

- サーバー側MVCフレームワーク

- ページ、ページレットおよびエレメント

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセット

- ページ・アセットおよびサイト・ナビゲーション

- 日付ベースのプレビュー

- 多言語サポート

- MVCフレームワークのキャッシング

- サーバー側Java API

- REST API

- サンプルWebサイト

13.1 サーバー側およびクライアント側の開発方法

Oracle WebCenter Sitesでは、Webページのコンテンツのサーバー側のレンダリング、クライアント側のレンダリング、あるいはその両方の組合せを構築するためのツールが用意されています。各方法には、Webサイト・デザインおよびレンダリングするコンテンツに応じて独自の利点があります。どちらの方法でも、迅速で生産的な開発用に、使いやすく標準化および準拠した方法で、Webサイトを試作および開発できます。

- サーバー側モデル・ビュー・コントローラ(MVC)フレームワークは、サーバー側の堅牢なスクリプト作成をサポートするために、プレゼンテーションとビジネス・ロジックを明確に分離します。
Java開発者は、Groovyを使用してControllerでビジネス・ロジック・コードを記述し、JSPでTemplatesを記述できますが、Web開発者は、HTMLおよびJavaScriptを使用して、互いの作業を干渉することなく、プレゼンテーション・エレメントをビューに作成できます。このMVCフレームワークは、WebCenter Sitesキャッシング、アセット依存性、およびライフサイクル管理の機能と完全に統合されます。

コーディングを効率化するために、フレームワークには、簡素化されたサーバー・サイトJava APIが含まれています。デフォルトのJava APIには、次のタスクなど、Webサイトの構築の一般的なアクティビティの便利なインタフェースが提供されます。

- アセット・データを読み取る

- ページのブレッドクラムをペイントする

- フォーム値にアクセスする

- 検証を実行する

- ControllerをRESTエンドポイントとして使用する

詳細は、「サーバー側Java API」を参照してください。

注意:

「タグ・テクノロジを使用したWebサイト開発」に説明されているように、Java APIとMVCフレームワークの組合せにより、エレメントおよびテンプレートのWebCenter Sites JSPタグ・テクノロジが置き換わります。ただし、WebCenter Sitesタグは引き続きサポートされます。

- REST APIでは、ブラウザ・クライアントで完全に実行されるテクノロジを使用して、クライアント側でレンダリングされるWebサイトを構築できます。このようなWebサイトには、単一ページ・アプリケーションが含まれますが、これに限定されるわけではありません。
WebCenter Sites REST API機能を示すスタンドアロンのサンプルWebサイトは、ダウンロードしたWebCenter Sitesインストールの一部として付属しています。このサンプル・リファレンスの実装方法は、wcsitesディレクトリの指示を参照してください。

クライアント側Webサイトのレンダリングは、高度にインタラクティブなアプリケーション(またはWebサイトの各部分)およびモバイル・サイトで特に便利です。クライアント側のレンダリングでは、一般にクライアント側ライブラリへのマークアップ生成が低下しますが、クライアントとサーバー間の相互作用をデータ要素のみに制限することで、通常はJSONの形式(JavaScript Object Notation)になります。このようなWebサイトでユーザーがページ間を移動すると、特定のデータ・コンポーネントのリクエストがサーバー送信され、マークアップを生成するためのJavaScriptがブラウザにロードされたままになります。

REST APIは、データ・コンポーネントをJSON形式でクライアントに効率的に送信します。これらのAPIは、一般にサーバー側Java APIの機能と似ています。特に重要な点は、これらのサーバーには、集計など、クライアント側のレンダリングの特定のニーズに合せて追加の機能があることです。

REST APIでは、次のような一般的な使用パターンに対応します。

- ナビゲーション・データへのアクセス

- 集計されたアセット・データへのアクセス
たとえば、APIで特定のフィールドの除外、ワイルドカードの使用、またはリストの構築が可能です。

Webサイトへの訪問者のニーズに応じて、完全にサーバー側の方法を使用して構築するか、クライアント側の方法を使用して構築するかを決定します。または、両方の方法を混在させることも可能です。サーバー側でレンダリングされるページへのコントリビュータは、Oracle WebCenter Sites: Contributorインタフェースを使用して、それらをWebモードで構成できますが、クライアント側でレンダリングされるページのエレメントにWebモード編集を使用することはできません。

詳細は、「REST API」を参照してください。

13.2 サーバー側MVCフレームワーク

最も基本的なものとして、MVCのデザイン・パターンには、モデル、ビュー、およびControllerの分離が含まれます。

- モデルはデータを表します。
WebCenter Sitesでは、モデルはキーと値のペアのマップです。ビジネス・ロジックで決定されるアセット・データおよび任意のデータは、モデルの一部になります。

- ビューはプレゼンテーションを表します。
WebCenter Sitesでは、ビューは、ブラウザにレンダリングされるTemplateオブジェクトまたはSiteEntryオブジェクトになります。ビューには、ビジネス・ロジックが含まれず、ユーザーがデータを表示および変更するインタフェースで、モデルデータをレンダリングします。また、ユーザー・アクション(訪問者のクリック操作など)をControllerに送信します。

- Controllerは、モデルおよびビューをリンクします。基礎となるデータでビジネス・ロジックを実行すると、ビューで使用できるようにControllerがモデルを集約します。
WebCenter Sitesでは、Controllerは標準のアセット・インスタンスです。プレゼンテーション・アセット(TemplateまたはSiteEntryアセット・タイプ)は、Controllerにリンクできます。このリンクはオプションです。存在する場合、ビューを起動する前に、リンクされたControllerがWebCenter Sitesによって起動されます。アセット・タイプと同様、タイプControllerのアセットは承認およびパブリッシュ可能です。

Controllersでは、他のControllersの拡張およびインポートが可能です。BaseControllerでは、便利なアクセッサやデバッガなどが提供されます。さらに、「サーバー側Java API」で説明されているように、Java APIをControllerで使用できます。

ControllerをRESTエンドポイントとして使用する方法は、「開発者のサンプルWebサイトに移動し、高度なトピック・メニューから「RESTエンドポイント」を選択します。

注意:

ビュー(TemplateまたはSiteEntryアセット)がControllerに関連付けられていない場合、WebCenter Sitesはそれをスタンドアロン・ビューとして扱います。このようなビューは、「Asset APIの使用: チュートリアル」で説明されているように、WebCenter Sitesのレガシー・ビュー・ベースのレンダリングにフォールバックします。WebCenter Sitesは、下位互換性を完全に維持しているため、MVCフレームワークへの増分的な遷移のオプションが可能です。

注意:

Controllerが別のControllerを拡張およびインポートする場合、拡張された側のControllerを編集しても、デフォルトでは、拡張する側のControllerのキャッシュは無効化されません。拡張する側のControllerまたはControllersのキャッシュを無効化するには、拡張する側の各ControllerをAdminインタフェースから編集または保存するか、「システム・ツール」の「コントローラ・アセット・ユーティリティ」を使用して、依存するすべてのControllersを強制的にコンパイルします。

次の各項では、サーバー側MVCフレームワークの各部分について説明します。

- 開発者のサンプルWebサイト

- WebCenter Sites MVCフレームワークの概要

- コントローラ

- ビュー

13.2.1 開発者のサンプルWebサイト

開発者のサンプルWebサイトでは、新しいMVCフレームワークの概要、開始例、サーバー側Java APIの例、注釈、グラマーの選択、カスタムBean、フォーム検証、RESTエンドポイント、フラグメント、ウォッチャなどの高度なトピックが表示されます。

この参照Webサイトは、Contributorインタフェースのサンプル・サイトに基づいています。

開発者のサンプルWebサイトにアクセスするには、インストールのホスト名とポート番号とともに、次のURLを入力します。

http://hostname:port/sites/samples/overview

13.2.2 WebCenter Sites MVCフレームワークの概要

図13-1に、リクエストの構造(MVCフレームワーク経由でリクエストが渡され、レスポンスを生成)を示します。

図13-1 サーバー側のレンダリングのためのMVCフレームワーク・プロセス

WebCenter Sitesでは、MVCフレームワークにはフロントControllerが含まれます。Oracle WebCenter Content ServerまたはSatellite Serverサーブレットは、フロントControllerとして機能し、様々なディスパッチおよびキャッシュ・サービスを処理します。

クライアントからのリクエストがフロントControllerに到達すると、リクエストURLに応じて、リクエストのビジネス・ロジックが含まれるTemplateに関連付けられている実際のControllerインスタンスを解決します。フロントControllerは、最初にビュー・エレメント(例: Templateアセット)を特定してから、ビューに関連付けられているControllerインスタンスを検索します(TemplateがControllerにリンクされている場合)。

ページのビジネス・ロジックが含まれるControllerインスタンスが検出されると、フロントControllerがそれを実行します。Controllerが実行されると、モデル・インスタンスが作成されます。

その後、モデル・インスタンスをリクエスト・スコープに配置して、フロントControllerがリクエストをビューにディスパッチします。ビュー(JSP)は、JSTLタグを使用してモデル・インスタンスにアクセスし、それに応じてブラウザに表示できるようになります。

ページレット(Webページの部分)で同じプロセスが繰り返されます。Controllerオブジェクトが含まれるページレットは、多くのページ間で再利用可能なコンポーネントになります。

WebCenter Sitesは、WebページやページレットをWebCenter Sitesのキャッシュに格納したり、それらのキャッシュを保持して、Webサイトの訪問者に古いページが表示されないようにするなど、コンテンツを管理するだけでなく、多くの有用なタスクを管理者のかわりに処理します。これらはWebCenter Sites Javaメソッドを使用して実行できます。

様々なエレメント・アセットおよびTemplateアセットにより、WebCenter Sitesページが構成されます。エレメント・アセットとは、WebCenter Sitesデータベースからページのコンテンツを取得したり、古くなったアイテムをデータベースから削除するなどのタスクを実行するコードのブロックです。Templateアセットは一般に、Webページのコンテンツを書式設定するために使用されます。エレメントとTemplatesは、JSPで記述できます。

13.2.3 コントローラ

Controllersには、開発者によって作成されたコードのビジネス・ロジックが含まれます。このようなコードをWebCenter Sites 12cで記述するためのプログラミング言語はGroovyで、Javaに類似しています。Groovyは、Java上に構築され、Javaライブラリと簡単に相互運用します。

Controllersのビジネス・ロジックは、一般にWebサイト実装に固有です。ただし、ページまたはページレットの数が多い場合でも、通常は共通の操作をいくつか実行する必要があります。たとえば、ビューに表示するアセットのリストをページのControllerで決定し、ページレットに各アセットを表示できます。アセットのリスト(特定の記事の問合せなど)を作成するには、カスタム・ビジネス・ロジックが必要になる場合があります。この場合、必要なControllerロジックがアセットを検索することになります。このロジックは、Webサイト全体で同じです。

WebCenter Sitesには、Controllersのセットが同梱されており、アセットの読取りの操作など、一般的な使用パターンで構築済です。Oracleでは、必要に応じて、開発者が次のデフォルトのControllersを使用することをお薦めしています。

- AssetController

- NavigationController

- TableController

- SegmentsController

- ProfileBasedRecommendationController

- SegmentBasedRecommendationController

ページの各部分には、カスタムのControllersと、追加のControllersが含まれたビューがある場合があります。Controllersを拡張できます。

13.2.4 ビュー

WebCenter Sitesでは、TemplateおよびSiteEntryアセットがビューを表します。各TemplateおよびSiteEntryアセットは、Controllerインスタンスにリンクできます。

MVCフレームワークを使用してビューを構築する場合は、モデルのデータにアクセスするために、ビューおよびJSTLを構築するためのスクリプト言語として、JSPを使用することをお薦めします。Templateアセットで使用した場合、アセット・データにアクセスするためのWebCenter Sitesタグは引き続き機能しますが、開発者はかわりにJava APIをControllersで使用し、プレゼンテーションの管理にはビュー・コードのみを使用することをお薦めします。これにより、ロジックとプレゼンテーションが分離されます。詳細は、「サーバー側Java API」を参照してください。

13.3 ページ、ページレットおよびエレメント

WebCenter Sitesのコンテキストでは、オンライン・ページは複数のコンポーネントを表示可能な最終出力に構成したものです。この出力を作成することをレンダリングといいます。出力またはレンダリングされるコンテンツをパブリック・サイトの訪問者が利用できるようにすることを、パブリッシュといいます。

WebCenter Sitesでは、ページは、ページ名に関連付けられたコードを実行してレンダリングされます。ページの名前はブラウザからWebCenter Sitesに渡され、WebCenter Sitesはそのページ名に関連付けられたコードを起動します。コードは実際には名前付きファイルであり、エレメントと呼ばれるコードの個々のチャンクです。

エレメント内のコードはアセットを識別して、ページまたはページレットに表示するために、そのアセットをロードし、その他のページ名とエレメント名をWebCenter Sitesに渡します。WebCenter Sitesがエレメントを呼び出すと、そのエレメント内のすべてのコードが実行されます。他のエレメントへのコールがある場合は、次にそのエレメントが呼び出されます。さらに、結果(イメージ、記事、リンクセットなど、すべてのHTMLタグを含む)がHTMLコード(または、システムの構成によっては、他の出力フォーマット)にレンダリングされます。

Template、CSElementおよびSiteEntryの各アセットは、次のようにエレメントとページレットを表現します。

- Templateアセットは、エレメントおよび、アセットをレンダリングするページまたはページレットの両方になります。

- CSElementアセットはエレメントです。

- SiteEntryアセットはページまたはページレットの名前です。

13.4 テンプレート・アセット、CSElementアセットおよびSiteEntryアセット

アセット・タイプにより、オンライン・サイトを構築するページレットとエレメントが提供されます。これらは、ページ名とエレメントおよび、WebCenter Sitesでページの生成に使用するコンポーネントを表現するアセットです。CSElementアセットの作成時には、エレメントをコーディングします。SiteEntryアセットの作成時には、ページに名前を付けます。Templateの作成時には、エレメントのコーディングとページの名前付けの両方を行います。

- Templateアセットは、1つのアセット・タイプに適用されるのか、どのアセット・タイプにも適用されないのかに応じて、タイプ付きまたはタイプなしに分類されます。

- SiteLauncherを使用している場合(サイトのレプリケートまたはTemplateアセットとCSElementアセットの共有を目的として)、WebCenter Sitesは、アセット、アセット・タイプ、属性名およびTemplate名を間接的に参照するために、エレメント・ロジックが必要になります。そのため、WebCenter Sitesインタフェースには、「マップ」画面が導入されていて、APIにはrender:lookupタグが導入されています。
「マップ」画面を使用して、各値に別名を割り当てます。別名をエレメント・ロジックでハードコード化し、render:lookupタグを使用して、実行時に別名から実際値を取得できます。

- 「キャッシュ規則」フィールドは、エラーを減らすために簡略化されています。Templateの開発者は、「キャッシュ済」、「未キャッシュ」または「詳細を選択できます。「詳細」を選択すると、開発者は、WebCenter SitesとOracle WebCenter Sites: Satellite Serverに対して個別にキャッシュ規則を設定できるようになります。

- Templatesの作成プロセスを簡略化した方法でTemplatesを起動するために、calltemplateタグが新規に導入されました。

- ページ基準フィールドは、「キャッシュ基準」と名前変更されました。これは予約パラメータc、cid、context、p、rendermode、site、sitepfx、ft_ssと、カスタム定義済パラメータを受け入れます。
キャッシュ基準の値は、SiteCatalog表のpagecriteria列に格納されます(旧バージョンでは、SiteCatalog表のresargs列に格納されていました)。

「キャッシュ基準」フィールドは、CKEditorの「その他のパラメータ」セクションを有効化する変数の保持にも使用され、その変数をユーザーがアセット・リンクを含めるダイアログ・ボックスと「アセット・リンクの追加」ダイアログ・ボックスで使用できるようにします。「その他のパラメータ」セクションには、カスタム・パラメータ(イメージ・ディメンションなど)をTemplateに渡す方法が用意されています。詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

- TemplateアセットとCSElementアセットの作成フォームはタブによって細分化されており、フィールドはタブ上で機能別に編成されています。

Templatesの作成の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください

13.5 ページ・アセットおよびサイト・ナビゲーション

ページ・アセットには、他のアセットへの参照が格納され、これらの参照はサイト設計に従って編成されます。サイトのセクションを表す場合、ページ・アセットは、完成済Webサイトと似た便利な構造的構成を提供します。

サイト開発者は、通常はサイトの設計時にページ・アセットを作成します。ページ、記事、その他のタイプのアセットを、関連付けられているアセットを書式設定するページ・アセットおよびコード・テンプレートに関連付けることができます。

ページ・アセットに関連付けられているTemplateには、レンダリングされたページおよびレンダリングされた他のページへのナビゲーションのレイアウトが含まれます。

ページ・アセットのサイト・ナビゲーションを集約するには、WebCenter Sites Java APIまたはREST APIを使用できます。詳細は、「サーバー側Java API」および「REST API」を参照してください。ページ・アセットの詳細は、「ページ・アセットの作成」を参照してください。

13.6 日付ベースのプレビュー

日付ベースのレンダリングを使用すると、コンテンツ・コントリビュータはContributorインタフェースでアセットをプレビューできます。表示の日付に基づいて変更されるWebサイトの構築に関心がある場合は、アセットで使用可能な開始日および終了日を使用できます。このようなWebサイトが将来の日付の時点でどのように表示されるかについて、WebCenter Sitesプレビュー・ツールを使用してプレビューすることもできます。

コンテンツ作成者は、Contributorインタフェースの「編集」画面で開始日と終了日を指定できます。サイトのユーザー・インタフェースでコンテンツをプレビューし、将来の日付に移動して、その日付の時点でサイトがどのように表示されるかを見ることができます。

たとえば、休日用のサイトを構築して、どのように表示されるかをプレビューできます。

詳細は、「アセット・リーダー」(日付別にフィルタできる便利なJava API)を参照してください。

13.7 多言語サポート

多言語サポートのサイトを構成すると、そのサイトのユーザーはロケール(言語バージョン)の指定をアセットに割り当て、アセットの翻訳を作成できるようになります。多言語コンテンツ用のサイト固有の配信ルールを作成するオプションもあり、そのルールによって、どの言語バージョンのアセットをオンライン・サイトで表示するか、訪問者のリクエストがそのコンテンツでまだ用意できていない言語バージョンの場合はどう対処するかが決まります。

WebCenter Sitesのロケール指定は、ディメンションの概念によって実装されます。ディメンションとは、別の点では意味的に同一であるアセットを区別する識別子のことです。ロケール(例: アメリカ英語はen_US)は、同一のコンテンツに対する2つの翻訳を区別するディメンションの1タイプです。

ディメンションは、タイプDimensionのアセットで表されます。このアセット・タイプは、ユーザーがDimensionアセット(サブタイプLocale)を作成できるよう、またコンテンツ・プロバイダがロケール指定を翻訳対象のアセットに割り当てることができるように、開発者がサイト単位で有効にする必要があります。

注意:
ユーザーは、ロケール指定が割り当てられていないアセットの翻訳を作成できません。

各Dimensionアセットは、サイトでロケールを表示します。たとえば、en_US Dimensionアセットはアメリカ英語、fr_CA Dimensionアセットはカナダ仏語を表します。詳細は、「アセット・リーダー」(翻訳されたアセットにアクセスできるJava API)を参照してください。

指定したロケールでコンテンツをパブリッシュするには、ロケールをオンラインサイトで有効にする必要があります。これにより、ロケールを示すDimensionアセットが配信システムに公開され、サイトのDimensionセットにそのロケールが追加されます。

13.8 MVCフレームワークのキャッシング

MVCフレームワークのページ・キャッシング機能は、JSPタグを使用してコーディングされるTemplateアセットと似ています。新しいフレームワークでは、ビジネス・ロジック・コードはControllerアセットに移動し、プレゼンテーション要素のみを処理するTemplateアセットが残ります。ページ・キャッシングでキャッシュされるものは、まだページまたはページレット・マークアップです。ページレットに関連付けられているビジネス・ロジックが実行されるのは、ページレットが未キャッシュの場合のみです。

Templateに関連付けられているControllerアセットは、キャッシュ依存性として、Controllerのビジネス・ロジックで読み取られるすべてのアセットとともに追加されます。ControllerアセットまたはControllerのビジネス・ロジックの一部として読み取られるアセットを更新すると、キャッシュは無効化されます。

Templateアセットのキャッシュ基準の引数は、ページレット・レベルのキャッシュ動作を引き続き決定します。WebCenter Sitesでのキャッシュの仕組みの詳細は、「ページのデザインとキャッシングの理解」を参照してください。

13.9 サーバー側Java API

Webページを集約するには、通常は、WebCenter Sitesで提供される次の種類のサーバー側Java APIの一部を使用します。

- アセット・リーダー

- ナビゲーション・リーダー

- リンク・ビルダー

- BLOBリンク・ビルダー

- 検索

- 推奨リーダー

- 表リーダー

これらのAPIの簡単な説明とサンプルを次に示します。「開発者のサンプルWebサイト」では、追加の説明とサンプルについて示します。

13.9.1 アセット・リーダー

アセット・リーダーAPIは、アセットを読み取り、すべてのデータまたは指定したデータを返します。AssetReaderのメソッドを使用すると、簡素化された方法でアセットを読み取り、必要な関連情報のみを返すことができます。

Controllerは、これらのメソッドと相互に組み合せて使用し、Templateですぐに使用可能なアセットを構築します。例13-1は、アセットの読取りにAssetReaderで使用可能な簡単なControllerを示します。

例13-1 アセット・リーダーController

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
public class AssetController extends BaseController
{
@RequiredParams(query="c,cid")
public void doWork(Map models)
{
Map assetMap = newAssetReader()
.forAsset(getAssetId())
.selectAll(true)
.read();
models.put("asset", assetMap);
}

このassetDataマップは、AssetControllerをそのControllerとして選択するTemplateで使用できます。例13-2は、アセットをレンダリングするTemplateがどのようになるかを示します。

例13-2 アセット・リーダーのテンプレート

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
%><cs:ftcs><%-- AVIArticle/myarticle --%>
<c:forEach var="a" items="$(assetData">
<tbody>
<tr>
<td><h4>$(a.key) : <.h4></td?
<td>$(a.value)</td>
</tr>
</tbody>
</c:forEach>
</cs:ftcs>

Controllerは、アセットIDが'1328196047443'、アセット・タイプが'AVIArticle'のアセットを読み取り、マップ'assetData'に配置します。selectAll(true)メソッドは、そのすべての属性でアセットを構築します。

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューからアセット・リーダーを選択します。

13.9.2 ナビゲーション・リーダー

ナビゲーション・リーダーAPIは、ナビゲーション用のブレッドクラムをペイントします。

例13-3に、アセット用のサンプルのナビゲーションControllerを示します。

例13-3 ナビゲーションController

package oracle.webcenter.sites.controller
import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*

public class NavigationController extends BaseController
{
@RequiredParams(query="c,cid")
public void doWork(Map models)
{
Map assetMap = newNavigationReader()
.forAsset(getAssetId())
.read();
models.put("asset", assetMap);
}
}

例13-4に、ナビゲーションControllerのサンプル・ビュー(テンプレート)を示します。

例13-4 ナビゲーションControllerのビュー

<%@ taglib prefix="render" uri="futuretense_cs/ftcs1_0.tld"

%><%-- Page/avipage --%>

Asset Name : ${asset.name}

Asset Id : ${asset.name}

Asset Parent : ${asset.parents[0].name}

BaseControllerのnewNavigationReader()メソッドは、ナビゲーション・リーダーを返します。前述のサンプルControllerは、サイト・プランのアセットの直接の親をフェッチします。たとえば、avisportsの非タッチSurfingページの階層はNonTouch/Home/Surfingで、その前のTemplateは、次のテキストを出力します。

Asset Name : Surfing
Asset Id : Surfing
Asset Parent : Home

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューからナビゲーション・リーダーを選択します。

13.9.3 リンク・ビルダー

リンク・ビルダーAPIは、アセットへのリンクを生成します。

例13-5に、サンプルControllerを示します。

例13-5 リンク・ビルダーController

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*

public class linfo extends BaseController {

@Override
public void doWork(Map models) {
LinkInfo linkInfo = newAssetLinkInfo();
linkInfo.forAsset(getAssetId());

Map assetMap = newAssetReader()
.forAsset(assetID)
.selectAll(true)
.addAssetLinkInfo(linkInfo)
.build();
models.put("asset", assetMap);
}
}

例13-6に、リンク・ビルダーのサンプルTemplateを示します。

例13-6 リンク・ビルダーTemplate

<%@ taglib prefix="render" uri="futuretense_cs/ftcs1_0.tld"%>

<cs:ftcs><%-- AVIArticle/myarticle --%>
<table border=1>
<tr>
<td><h4> Asset Name : </td>
<td></h4> ${asset.name} </td>
</tr>
<tr>
<td><h4>Link: </td>
<td?</h4><a href="${asset._link_}"> ${asset._link_}</a></td>
</tr>
</table>
</cd:ftcs>

前述のコード・サンプルは、LinkInfoの簡単なControllerおよびTemplateを示します。このコードは、アセットIDが‘1328196047443’のArticleのリンクを生成します。アセット・マップには、キー、_link_(値はアセットのデフォルトのURL)が含まれます。

Templateでは、${asset._link_}でアセットのデフォルトのURLをフェッチする必要があります。リンクは次のようになります。

http://localhost:8080/cs/avi/avisection/baseball.html

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューからリンク・ビルダーを選択します。

13.9.4 BLOBリンク・ビルダー

BLOBリンク・ビルダーAPIは、BLOBへのリンクを生成します。アセットの読取り時にBLOBリンクを表示する場合は、addBlobLinkInfo(BlobLinkInfo blobLinkMaker)メソッドを使用できます。

例13-7に、サンプルControllerを示します。

例13-7 BLOBリンク・ビルダーController

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*

public class bloblink extends BaseController
{
public void doWork(Map models)
{

def mapParams = [:]
mapParams.put("blobheadername1","Content-Type")
mapParams.put("blobheadervalue1","image/gif")
mapParams.put("blobheadername2","Cache-Control")
mapParams.put("blobheadervalue2","no-cache")

BlobLinkInfo blobLink = newBlobLinkInfo();
blobLink.parameters(mapParams)

Map assetMap = newAssetReader().forAsset(getAssetId())
.select("Assoc_Named_Manual.*")
.addBlobLinkInfo(blobLink)
.build();
models.put("asset", assetMap);
}
}

例13-8に、BLOBリンク・ビルダーのサンプルTemplateを示します。

例13-8 BLOBリンク・ビルダーTemplate

<cs:ftcs><%-- Product_C/ptemplate --%>
<table border=1>
<tr>
<td><h4>Link1: </td>
<td></h4><a href='${asset["Assoc_Named_Manual.FSIIDocumentFile_bloblink_"]}'>
${asset["Assoc_Named_Manual.FSIIDocumentFile_bloblink_"]}</a></td>
</tr>
<tr>
<td><h4>Link2: </td>
<td></h4><a href='${asset["Assoc_Named_Manual.FSIIHtmlFile_bloblink_"]}'>
${asset["Assoc_Named_Manual.FSIIHtmlFile_bloblink_"]}</a></td>
</tr>
</table>
</cs:ftcs>

前述のコードは、アセットIDが1114083739596のProduct_ Cに関連付けられているBLOBアセットへのリンクを出力します。このアセットには、FSIIDocumentFileとFSIIHtmlFileの2つのBLOBで構成される、Document_Cアソシエーションが含まれます。コードには、これらのBLOBへのリンクが表示されます。

/sites/BlobServer?blobkey=id&blobnocache=true&blobwhere=1114725604909&blobcol=urldata
&blobtable=MungoBlobs&Content-Type=image/gif&Cache-Control&no-cache

/sites/BlobServer?blobkey=id&blobnocache=true&blobwhere=1114725604910&blobcol=urldata
&blobtable=MungoBlobs&Content-Type=image/gif&Cache-Control&no-cache

バニティURLがある場合は、コードにそれが表示されます。

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューからBLOBリンク・ビルダーを選択します。

13.9.5 検索

検索APIは、アセットに対する検索問合せを構築します

例13-9 検索Controller

例13-9に、検索のサンプルTemplateを示します。

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*

public class SearchController extends BaseController
{
@RequiredParams(query="c,cid")
public void doWork(Map models)
{
def results = newSearcher().searchFor("audio")
models.put("results",results)
}
}

例13-10に、検索のサンプルTemplateを示します。

例13-10 検索Template

<%@ taglib prefix="render" uri="futuretense_cs/ftcs1_0.tld"%>

<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"
%><cs:ftcs><%-- Product_C/ptemplate --%>
<table>
<c:forEach var="result" items="${results}" >
<tr>
<td>
${result.id}
</td>
<td>
${result.name}
</td>
</tr>
</c:forEach>
</table>
</cs:ftcs>

BaseControllerのnewSearcher()メソッドは、検索を返します。Searcherクラスの1つ以上のメソッドをこの検索に適用できます。前述のControllerは、"audio"の語が含まれるすべてのアセットを収集します。語を含み、特定のサイトに属するすべてのアセットを検索するには、inSite(String site)メソッドを使用できます。

def results = newSearcher().inSite("FirstSiteII").searchFor("audio")

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューから検索を選択します。

13.9.6 推奨リーダー

推奨リーダーAPIは、訪問者のセグメンテーションに基づいて、性別や趣味などの属性別に訪問者に対するお薦めを読み取ります。セグメントの訪問者には、1つ以上のアセットが推奨されます。

特定の訪問者が分類されるすべてのセグメントを読み取るには、例13-11に示すように、readSegments()メソッドおよびTemplateを推奨リーダーに使用できます。

例13-11 セグメントを読み取るためのメソッド

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*

public class RecommendationController extends BaseController
{
@RequiredParams(query="c,cid")
public void doWork(Map models)
{
def visitor = [:];
visitor.put("Gender", "male");
List rr =
newRecommendationReader().forVisitorAttributes(visitor).readSegments();
models.put("results", rr);
}
}

Template:

<%@ taglib prefix="render" uri="futuretense_cs/ftcs1_0.tld"%>

%><%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"
%><cs:ftcs><%-- AVIArticle/myarticle --%>
<table>
<c:forEach var="result" items="${results}" >
<tr>
<td>
${result.name}
</td>
</tr>
</c:forEach>
</table>
</cs:ftcs>

前述のコード・サンプルには、訪問者の分類がGender maleのすべてのセグメントが表示されます。avisportsの場合は、Gender maleの訪問者はMaleセグメントに分類されます。

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューから推奨リーダーを選択します。

13.9.7 表リーダー

表リーダーAPIは、WebCenter Sitesによって管理される表を問い合せます。

例13-12に、表リーダーのサンプルControllerを示します。

例13-12 表リーダーController

package oracle.webcenter.sites.controller

import com.fatwire.assetapi.data.*
import com.openmarket.xcelerate.asset.*
import oracle.fatwire.api.TableReader;

public class TableReader extends BaseController
{
public void doWork(Map models)
{
TableReader tr = newTableReader()
def myResult = tr.from("AVIArticle").execute()
models.put("asset", myResult)
}
}

新しいTableReader()メソッドは、BaseControllerのファクトリ・メソッドです。前述のコード・サンプルは、AVIArticle表からすべてのデータをフェッチして、assetという名前のマップに配置します。

select(String select)メソッドでSELECTパラメータを指定できます。

def myResult = tr.select("name").from("AVIArticle").execute()

このコードは、AVIArticle表のname列のすべての値を返します。

詳細は、「開発者のサンプルWebサイト」に移動し、レンダリングAPIメニューから表リーダーを選択します。

13.10 REST API

WebCenter Sitesでは、集約的な方法でコンテンツにアクセスするためのREST APIが用意されています。これらのREST APIの詳細は、『Oracle WebCenter Sites集約REST APIリファレンス』を参照してください。

13.11 サンプルWebサイト

これらのリソースを使用して、WebCenter Sitesフレームワークを理解できます。

- サンプル・サイト
「開発者のサンプルWebサイト」を参照してください。

- avisportsサンプル・サイト
このサイトでは、avisportsは、フォーム・モードおよびWebモードでのアセットの作成や編集など、WebCenter Sites Contributorインタフェースでの機能を示します。また、avisportsでは、アセットの「作成」ビューや「編集」ビューをWebモードでレンダリングするようにコーディングされたサンプルTemplatesが、開発者に提供されます。

- REST-avisportsサンプルWebサイト
このサイトには、REST APIで完全に構築されたavisportsのサンプルの参照実装が含まれます。Webサイトの機能的な面はavisportsと同等で、同じアセット・モデルとコンテンツを使用します。このサンプル・サイトは、REST APIに基づいてWebサイト開発を開始するための適切な参照ポイントです。

14 サーバー側Webサイトの開発

サーバー側Webサイトは、Oracle WebCenter Sites Model-View-Controllerフレームワークで開発できます。組織のデータ・モデルをコーディングするために、Java開発者は、JSPのビュー用にテンプレートを記述し、Groovyを使用して、Controllerでビジネス・ロジックをコーディングできます(WebCenter Sites Java APIで効率化できます)。Web開発者は、ビューにプレゼンテーション・エレメントを追加できます。

次の項では、サーバー側Webサイトの開発について説明します。

- サーバー側Webサイトの開発について

- コントローラの作成

- テンプレートの作成

- ホームページの設定

- サイト・ナビゲーションの追加

14.1 サーバー側Webサイトの開発について

サーバー側Webサイトを開発するには、「サーバー側MVCフレームワーク」で説明しているように、Oracle WebCenter Sites Model-View-Controller (MVC)フレームワークを使用します。このモデルはご使用のデータ・モデルです。ビューについては、TemplateまたはSiteEntryオブジェクトを作成します。即時利用可能なControllerを使用することも、1つ作成してモデルとビューをまとめて結合することもできます。

WebCenter Sitesには、アセットの読取り用のナビゲーションなどの一般的な使用パターンを使用してすでに構築されたControllerが複数用意されています。これらの即時利用可能なControllerの詳細は、「コントローラ」を参照するか、開発者のサンプルWebサイトに移動し、「はじめに」メニューから即時利用可能なコントローラを選択します。

14.2 コントローラの作成

Oracle WebCenter SitesのAdminインタフェース内の新規コントローラを作成ウィザードを使用してControllerを作成できます。

同様に、Eclipse IDE内のOracle Developer Toolsを使用してControllerを作成することもできます。詳細は、「EclipseでのWebCenter Sitesリソースの管理」を参照してください。

Adminインタフェースを介してControllerを作成するには:

1. WebCenter Sites Adminインタフェースの「新規」ページで、アセット・タイプ表内の新規コントローラをクリックします。
新規コントローラの作成ウィザードが開きます。

2. 「名前」フィールドに、新規Controllerの名前を入力します。

3. (オプション)「説明」フィールドに、新規Controllerの説明を入力します。

4. 「コントロール・ロジック」フィールドで、ビジネス・ロジック・コードを追加します。

5. 「保存」アイコンをクリックします。

Controllerの開発の詳細は、開発者のサンプルWebサイトに移動し、サイトのレンダリングメニューから「コントローラ」を選択します。

14.3 テンプレートの作成

Templateアセットは、WebCenter Sites Adminインタフェースを介して作成できます。

Adminインタフェースを使用してTemplateを作成するには:

1. 「新規」をクリックします。

2. 右側の表で、「テンプレート」の隣にある「新規テンプレート」リンクをクリックします。

3. Templateフォームに入力します。

4. Templateを保存します。

Templateの作成の詳細は、「テンプレート・アセットの作成」を参照してください。

14.4 ホームページの設定

Webサイトのホーム・ページの設定の詳細は、次の項を参照してください。

- ベーシック・モジュラ・デザインの作成

- Homeエレメント

14.5 サイト・ナビゲーションの追加

次のJava APIを使用してWebサイトにサイト・ナビゲーションを追加できます。

- ナビゲーション・リーダー

- リンク・ビルダー

- BLOBリンク・ビルダー

これらのJava APIの詳細は、開発者のサンプルWebサイトのレンダリングAPIメニューに移動してください。

15 クライアント側Webサイトの開発

WebCenter Sites REST APIを使用して、クライアント側Webサイトを構築できます。

作業を進める前に、WebCenter Sites集約REST APIサービスに精通しておくことをお薦めします。詳細は、『Oracle WebCenter Sites集約REST APIリファレンス』を参照してください。

次の項で、クライアント側Webサイトの開発について説明します。

- クライアント側Webサイトについて

- REST-avisportsを開発するためのRESTコール: 例

15.1 クライアント側Webサイトについて

REST APIを使用すると、クライアント側でレンダリングされ、完全にブラウザ・クライアント内で実行されるWebサイトを構築できます。このようなWebサイトには、単一ページ・アプリケーションが含まれますが、これに限定されるわけではありません。これらのWebサイトは特に、相互作用性の高いアプリケーション(またはWebサイトのポートフォリオ)やモバイル・サイトの役に立ちます。クライアント側のレンダリングでは、通常、クライアント側ライブラリによってマークアップが生成されますが、これは、クライアントとサーバー間の相互作用をデータ・エレメントのみに制限する上で役に立ちます。この相互作用は通常、JSONの形式で行われます。ユーザーがページ間を移動すると、特定のデータ・コンポーネントに関するリクエストがサーバーに対して実行されると同時に、マークアップを生成するためのJavaScriptがブラウザ内でロードされたままになります。REST APIは通常、サーバー側Java APIの機能をミラーリングします。

WebCenter Sites内のRESTサービスはクライアントに公開され、クライアントはクライアント側フレームワークを使用してデータを取得したりカスタム・サイトを構築したりできるようになります。クライアント側APIを使用すると、サーバー側ロジックまたはJSPを持たないJavaScriptベースのWebアプリケーションを構築できます。これらのAPIは、ページ全体のアセット・データを単一のRESTコールに集約できます。任意のレベルの深さまでのコンテンツ、その関連情報、さらにはWebサイト全体を取得する場合でも、単一のコールで十分です。

RESTサービスに対するレスポンスは潜在的にブラウザ・キャッシュ内にキャッシュできるため、体感的なパフォーマンスを向上させることができます。これらのAPIを使用すると、コンシューマがWebCenter Sitesテンプレートを使用しなくても、サイトからデータを取得し、独自のテンプレートに提示できるようになります。この機能を使用すると、カスタマがWebCenter Sitesをデータ・ストレージとして使用できるようになります。

15.2 REST-avisportsを開発するためのRESTコール: 例

REST-avisportsは、WebCenter Sites REST APIを使用してクライアント側Webサイトの開発を実演するサンプルWebサイトです。このサンプルWebサイトは、WebCenter Sitesインストールのダウンロードに含まれています。このWebサイトを構成するには、『Oracle WebCenter Sitesのインストールと構成』を参照してください。

この項では、avisportsサンプル・サイトに似たREST-avisportsクライアント側Webサイトの開発に使用されるRESTコールの例を示します。これらの例により、RESTコールを使用した本格的なクライアント側Webサイトの効率的な開発方法に関するアイデアをサイト開発者に示します。REST-avisports Webサイトの開発には、次が含まれます。

- ナビゲーション・メニューの取得

- 「Home」ページの取得

- 追加のWebサイト・ページの取得

- ページからの記事のコール

- ページ区切りを使用したコレクション・リソースのコール

- 検索リソースのコール

- ページ・セグメントのコール

15.2.1 ナビゲーション・メニューの取得

次のコールは、avisportsサンプルWebサイトで「Home」および「Skiing」ナビゲーション・メニューをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/navigation/Default?assetDepth=0&fields=Page(children,name,id);SiteNavigation(children)&expand=Page

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

レスポンスは図15-1のようになります。

図15-1 ナビゲーション・レスポンス

図15-2に示すナビゲーションはレンダリングされています。

図15-2 JSONレスポンスからレンダリングされたナビゲーション

15.2.2 「Home」ページの取得

次のコールは、avisportsサンプルWebサイトで「Home」ページ・アセットをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1327351719456?assetDepth=1&fields=Page(banner,teaserImages,teaserText,bannerText);AVIImage(imageFile,width,height)&expand=Page,AVIImage

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

レスポンスは図15-3のようになります。

図15-3 「Home」ページをレンダリングするためのJSONレスポンス

図15-4に示すページはレンダリングされています。

図15-4 JSONレスポンスからレンダリングされたavisportsの「Home」ページ

15.2.3 追加のWebサイト・ページの取得

次のコールは、avisportsサンプルWebサイトで「Skiing」ページをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1329326970440?assetDepth=2&fields=AVIArticle(id,relatedImage,abstract,headline);Page(banner,titleContent1,titleContent2,Assoc_Named_contentList1,Assoc_Named_contentList2);AVIImage(imageFile,smallThumbnail,ClargeThumbnail);YouTube(externalid)&expand=Page,AVIImage,AVIArticle,YouTube

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

レスポンスは図15-5のようになります。

図15-5 「Skiing」ページをレンダリングするためのJSONレスポンス

図15-6に示す「Skiing」ページはavisportsサンプルWebサイトでレンダリングされます。

図15-6 JSONレスポンスからレンダリングされた「Skiing」ページ

15.2.4 ページからの記事のコール

次のコールは、avisportsサンプルWebサイトで「Skiing」ページの「Also In the News」セクションに表示される記事をレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/AVIArticle/1328196047241?assetDepth=2&fields=category,author,postDate,subheadline,relatedLinks,relatedStories,relatedImage,body;AVIArticle(id,headline,abstract,relatedImage);AVIImage(imageFile,caption,width,height,sidebarThumbnail)&expand=AVIArticle,AVIImage

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

レスポンスは図15-7のようになります。

図15-7 「Skiing」ページに表示される記事をレンダリングするためのJSONレスポンス

図15-8に示す記事はレンダリングされています。

図15-8 JSONレスポンスからレンダリングされた記事

15.2.5 ページ区切りを使用したコレクション・リソースのコール

次のコールは、avisportsサンプルWebサイトでページ区切りを使用した(ページの下部にナビゲーション・ボタンがある)コレクション・リソースをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/ContentQuery/1395380847207/items?assetDepth=1&fields=AVIArticle(id,headline,abstract,relatedImage);AVIImage(imageFile,smallThumbnail)&expand=AVIArticle,AVIImage&offset=0&limit=8

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

レスポンスは図15-9のようになります。

図15-9 ページ区切りを使用したコレクション・リソースをレンダリングするためのJSONレスポンス

図15-10に示すページはレンダリングされています。

図15-10 JSONレスポンスからレンダリングされたコレクション・リソース

15.2.6 検索リソースのコール

次のコールは、avisportsサンプルWebサイトで基準「How To」の検索結果(コレクション・リソース)をレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/search/sites/avisports/types/AVIArticle/assets?field:name:startswith=How+to

このコールは、問合せパラメータとしてfield name starts withを使用します。

JSONレスポンスは図15-11のようになります。

図15-11 検索結果をレンダリングするためのJSONレスポンス

図15-12に示すページはレンダリングされています。

図15-12 JSONレスポンスからの検索結果

15.2.7 ページ・セグメントのコール

この項には次のトピックが含まれます:

- セグメントのないページのコール

- 特定の訪問者をターゲットにしたセグメントのあるページのコール

- 異なる訪問者をターゲットにしたセグメントのあるページのコール

- 追加の訪問者をターゲットにしたセグメントのあるページのコール

15.2.7.1 セグメントのないページのコール

次のコールは、avisportsサンプルWebサイトでセグメントのない「Running」ページをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1361217259137?assetDepth=1&fields=AVIArticle(id,relatedImage,abstract,headline);Page(banner,recommendation);AVIImage(imageFile,smallThumbnail,largeThumbnail);AdvCols(items)&expand=Page,AVIImage,AdvCols,AVIArticle

このコールは、問合せパラメータとしてassetDepth、fieldsおよびexpandを使用します。

JSONレスポンスは図15-13のようになります。

図15-13 セグメントのないページをレンダリングするためのJSONレスポンス

図15-14に示すページはレンダリングされています。

図15-14 レンダリングされたセグメントのないページ

15.2.7.2 特定の訪問者をターゲットにしたセグメントのあるページのコール

次のコールは、avisportsサンプルWebサイトで男性をターゲットにしたセグメントのある「Running」ページをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1361217259137?assetDepth=1&fields=AVIArticle(id,relatedImage,abstract,headline);Page(banner,recommendation);AVIImage(imageFile,smallThumbnail,largeThumbnail);AdvCols(items)&expand=Page,AVIImage,AdvCols,AVIArticle&segments=Male

このコールは、問合せパラメータとしてassetDepth、fields、expandおよびsegmentsを使用します。

JSONレスポンスは図15-15のようになります。

図15-15 男性をターゲットにしたセグメントのあるページをレンダリングするためのJSONレスポンス

図15-16に示すページはレンダリングされています。

図15-16 男性をターゲットにしたセグメントのあるレンダリングされたページ

15.2.7.3 異なる訪問者をターゲットにしたセグメントのあるページのコール

次のコールは、avisportsサンプルWebサイトで女性をターゲットにしたセグメントのある「Running」ページをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1361217259137?assetDepth=1&fields=AVIArticle(id,relatedImage,abstract,headline);Page(banner,recommendation);AVIImage(imageFile,smallThumbnail,largeThumbnail);AdvCols(items)&expand=Pag,AVIImage,AdvCols,AVIArticle&segments=Female

このコールは、問合せパラメータとしてassetDepth、fields、expandおよびsegmentsを使用します。

JSONレスポンスは図15-17のようになります。

図15-17 女性をターゲットにしたセグメントのあるページをレンダリングするためのJSONレスポンス

図15-18に示すページはレンダリングされています。

図15-18 女性をターゲットにしたセグメントのあるレンダリングされたページ

15.2.7.4 追加の訪問者をターゲットにしたセグメントのあるページのコール

次のコールは、avisportsサンプルWebサイトで男性と女性の両方をターゲットにしたセグメントのある「Running」ページをレンダリングします。

http://<host>:<port>/<context>/REST/resources/v1/aggregates/avisports/Page/1361217259137?assetDepth=1&fields=AVIArticle(id,relatedImage,abstract,headline);Page(banner,recommendation);AVIImage(imageFile,smallThumbnail,largeThumbnail);AdvCols(items)&expand=Page,AVIImage,AdvCols,AVIArticle&segments=Male,Female

このコールは、問合せパラメータとしてassetDepth、fields、expandおよびsegmentsを使用します。

JSONレスポンスは図15-19のようになります。

図15-19 男性と女性をターゲットにしたセグメントのあるページをレンダリングするためのJSONレスポンス

図15-20に示すページはレンダリングされています。

図15-20 男性と女性をターゲットにしたセグメントのあるレンダリングされたページ

16 タグ・テクノロジを使用したWebサイト開発

下位互換性のため、Oracle WebCenter Sitesでは、Webサイトの開発用に引き続きレガシー・タグ・テクノロジを提供しています。コーディングはWebCenter SitesタグおよびJavaメソッドで可能で、テンプレートにはXMLおよびJSPを使用できます。

レガシーWebCenter Sitesタグ・テクノロジの詳細は、次の項を参照してください。

- コーディング言語の選択について

- Oracle WebCenter Sitesのコンテキストについて

- WebCenter Sites JSPの理解

- WebCenter Sites XMLの理解

- WebCenter Sitesタグの理解

- WebCenter Sitesでサポートされる変数について

- WebCenter Sitesの他の記憶域構成体

- 特殊文字の値について

注意:

新しいテクノロジの詳細は、「MVCフレークワークおよびAPIを使用したWebsサイト開発」を参照してください。

16.1 コーディング言語の選択について

WebCenter Sitesページは、様々なエレメント・アセットとテンプレート・アセットで構成されており、エレメント・アセットとは、WebCenter Sitesデータベースからページのコンテンツを取得したり、古くなったアイテムをデータベースから削除するなどのタスクを実行するコードのブロックで、テンプレート・アセットは一般に、Webページのコンテンツを書式設定するために使用されます。エレメントとテンプレートは、HTML、XML、JSP、CSS、JavaScriptなどの複数のスクリプト言語とマークアップ言語で記述できます。ただし、WebCenter Sitesが解釈できるのはXMLとJSPのみです。

作成するエレメントまたはテンプレートの役割に基づいて、コーディング言語やマークアップ言語を選択してください。たとえば、ページ・レイアウトにはHTMLとXMLを使用し、ロジックにはJSPとJavaを使用するのが一般的です。新聞記事などの動的なコンテンツを表示するエレメントは、通常はXMLまたはJSPで記述してください。その理由は、このようなエレメントはロジックを使用してコンテンツをWebCenter Sitesデータベースから取得するため、WebCenter SitesのXMLタグまたはJSPタグを使用して管理されるからです。

WebCenter SitesではJava APIも用意されており、コーディング言語としてJSPを選択した場合は、このAPIをWebCenter SitesのJSPタグと組み合せて使用します。

表16-1では、各言語の最適な使用ケースを示しています。

表16-1 コーディング言語の使用

コード

使用するケース

XML

エレメントの大部分がテキストで構成されており、ループや条件分岐がほとんど含まれていません。

JSP

- エレメントで条件演算子が必要であるか、=や!=以外の関係演算子が必要です。

- エレメントで多くのループが使用されています。ループのパフォーマンスは、XMLよりもJSPの方が優れています。

- エレメントにJavaコードのコールが含まれています。

XMLまたはJSPで記述されたエレメントは任意のタイプのエレメントをコールできますが、XMLとJSPを同じエレメント内に混在させることはできません。たとえば、XMLまたはJSPで記述されたエレメントは、HTML、XMLまたはJSPで記述された別のエレメントをコールできます。ただし、HTMLで記述されたエレメントは、XMLまたはJSPで記述されたエレメントをコールすることはできません。

16.2 Oracle WebCenter Sitesのコンテキストについて

Oracle WebCenter Sitesプロジェクトのためにコーディングする場合は、Oracle WebCenter Sitesのコンテキスト内でコーディングします。WebCenter Sitesのコンテキストでは、WebCenter Sitesを構成するJavaサーブレットにアクセスできるとともに、WebCenter Sitesの機能へのアクセスを可能にするメソッドとタグを持つWebCenter Sites Javaオブジェクトにアクセスできます。

どの言語を使用してプロジェクトをコーディングする場合でも、WebCenter Sitesのコンテキスト内でコーディングします。WebCenter SitesのXMLタグとJSPタグは、WebCenter SitesのJavaオブジェクト用の簡単に使用できるインタフェースを提供するため、Javaの経験がほとんどまたはまったくないWebデザイナでも、WebCenter SitesのWebページを作成できます。

16.2.1 ICSオブジェクト

Oracle WebCenter Sitesのためにコーディングしている場合は、Interface to WebCenter Sites (ICS)オブジェクトのメソッドとタグに頻繁にアクセスします。ICSオブジェクトは、WebCenter Sitesの中核機能のいくつかをカプセル化して、WebCenter Sitesツリーを制御するサーブレット(TreeManagerサーブレット)と、データベースへのデータ入力を制御するサーブレット(CatalogManagerサーブレット)へのアクセスを可能にします。

ICSのメソッドとタグを使用して、変数を作成および表示したり、if/then文を使用して、指定された条件に基づいてタスクを実行することもできます。ICSオブジェクトのメソッドおよびタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

16.2.2 FTCSタグ

WebCenter Sitesのそれぞれのエレメントやテンプレートの先頭と末尾には、ftcsタグが配置されています。このタグは、WebCenter Sitesのコンテキストを作成し、開始と終了のftcsタグの内側に含まれているコードがWebCenter Sitesのタグを格納してICSメソッドにアクセスすることを、WebCenter Sitesに通知します。

WebCenter Sitesユーザー・インタフェースまたはOracle WebCenter Sites Explorerツールを使用して作成したエレメントとテンプレートには、開始と終了のftcsタグが標準ディレクティブの後ろに追加されます。コーディングは、開始と終了のftcsタグの内側で行う必要があり、これらのタグの外側にコードがあってもWebCenter Sitesでは認識されません。

他の方法を使用してエレメントとテンプレートのコードを作成する場合は、ディレクティブの後ろに開始ftcsタグを追加して、終了ftcsタグをコードの最終行として使用する必要があります。

16.3 WebCenter Sites JSPの理解

JSPプログラマは、ディレクティブ、アクション、JSPオブジェクトなどの一連の標準ツールを自由に使用できます。WebCenter Sites内でJSPを使用してプログラミングする場合は、これらの機能の多くにアクセスできます。ただし、場合によっては、JSPのディレクティブやアクションのかわりにWebCenter Sitesのタグを使用することや、JSPの暗黙オブジェクトのいずれかのかわりにWebCenter Sitesのオブジェクトにアクセスすることが必要になります。

次の各項では、標準のJSPとWebCenter SitesのJSPの違いを詳述しているとともに、標準のJSP機能とWebCenter Sitesのタグやメソッドとの対応関係を示しています。

- WebCenter Sitesの標準先頭部について

- JSPの暗黙オブジェクトについて

- JSP構文について

- JSPアクションについて

- JSP宣言について

- スクリプトレットと式について

- JSPディレクティブについて

- Oracle WebCenter Sitesのタグ・ライブラリについて

16.3.1 WebCenter Sitesの標準先頭部について

WebCenter Sitesユーザー・インタフェースまたはExplorerを使用して作成したテンプレート・アセット、CSElementアセット非アセット・エレメントは、標準先頭部が自動的に追加されます。

Explorer内のJSPエレメントの標準先頭部は次のとおりです。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%@ taglib prefix="satellite" uri="futuretense_cs/satellite.tld" %>
<%//
// elementName
//
// INPUT
//
// OUTPUT
//%>
<%@ page import="COM.FutureTense.Interfaces.FTValList" %>
<%@ page import="COM.FutureTense.Interfaces.ICS" %>
<%@ page import="COM.FutureTense.Interfaces.IList" %>
<%@ page import="COM.FutureTense.Interfaces.Utilities" %>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<cs:ftcs>

<!-- user code here -->

</cs:ftcs>

WebCenter Sitesユーザー・インタフェースを使用して作成したテンプレート・アセットとCSElementアセットには、前述のコード例のような標準先頭部が表示されます。これらのアセットの標準先頭部は、ベーシック・アセットとともに使用するための追加のタグ・ライブラリをインポートして、テンプレート・アセットおよびCSElementアセットとこれらのアセットによってレンダリングされるコンテンツの間の依存関係をログに記録するタグを組み込みます。

ExplorerやWebCenter Sitesユーザー・インタフェース以外のツールを使用してエレメントとテンプレートを作成する場合は、この標準先頭部をコード内にまるごとコピーする必要があります。

次の各項では、Explorerの標準先頭部について説明します。

16.3.1.1 taglibディレクティブ

次のtaglibディレクティブは、WebCenter Sitesで使用するベース・タグ・ライブラリをインポートします。WebCenter Sitesユーザー・インタフェースを使用して作成したテンプレート・アセットとCSElementアセットには、追加のtaglibディレクティブがシード・コード内に表示されます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%@ taglib prefix="satellite" uri="futuretense_cs/satellite.tld" %>

1つ目のディレクティブは、FTCSコンテキストを作成するftcs1_0タグをインポートします。これらのタグは、作成したテンプレートまたはエレメントごとに使用され、それらのタグで囲まれたコードがWebCenter Sitesで制御されることを示します。

2つ目のディレクティブは、WebCenter Sitesの中核機能へのアクセスを可能にするicsタグをインポートします。

3つ目のディレクティブは、Satellite Serverで使用するためのsatelliteタグをインポートします。

これらのタグ・ライブラリの詳細は、「Oracle WebCenter Sitesのタグ・ライブラリについて」を参照してください。

これらのタグ・ライブラリに含まれている一般的なタグについては、「WebCenter Sitesのタグの理解」を参照してください。

これらのデフォルト内容にtaglibディレクティブを追加するには、OpenMarket/Xcelerate/AssetType/Template/ModelJsp.xmlファイルを変更して保存します。

16.3.1.2 pageディレクティブ

次のpageディレクティブは、WebCenter Sitesで使用するベースJavaインタフェースをインポートします。

<%@ page import="COM.FutureTense.Interfaces.FTValList" %>
<%@ page import="COM.FutureTense.Interfaces.ICS" %>
<%@ page import="COM.FutureTense.Interfaces.IList" %>
<%@ page import="COM.FutureTense.Interfaces.Utilities" %>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>

1つ目のpageディレクティブは、FTValListインタフェースをインポートし、このインタフェースは、CatalogManagerやTreeManagerなど、WebCenter Sitesのサブシステムに引数を渡すために使用する名前と値のペアのリストを作成します。

2つ目のpageディレクティブは、ICSインタフェースをインポートし、このインタフェースは、WebCenter Sitesの中核機能へのアクセスを可能にします。

3つ目のpageディレクティブは、IListインタフェースをインポートし、このインタフェースには、WebCenter Sitesの問合せオブジェクトやリスト・オブジェクト内の行にアクセスするためのメソッドが含まれています。このインタフェースには、WebCenter SitesのXMLページ内で使用するためのリスト・オブジェクトを作成および登録しようとする際にサード・パーティが実装する必要があるメソッドも含まれています。

4つ目のpageディレクティブは、Utilitiesインタフェースをインポートします。このインタフェースは、日付の書式設定、ファイルの読み書き、電子メールの送信など、いくつかの一般的なタスクのためのシンプルなインタフェースを提供します。

5つ目のpageディレクティブは、エラー・コードが含まれたftErrorsクラスをインポートします。

6つ目のpageディレクティブは、WebCenter Sitesで使用されるエラー・メッセージが含まれたftMessageクラスをインポートします。

JSPエレメント用の標準ディレクティブにpageディレクティブを追加するには、OpenMarket/Xcelerate/AssetType/Template/ModelJsp.xmlファイルを変更して保存します。

16.3.1.3 cs:ftcsタグ

WebCenter SitesのそれぞれのJSPテンプレートやJSPエレメントでは、最初と最後のタグとしてcs:ftcsタグが使用されている必要があります。このタグは、WebCenter Sitesのコンテキストを作成して、開始と終了のcs:ftcsタグの内側に含まれているコードにWebCenter Sitesのタグが格納されることを、WebCenter Sitesに通知します。

コーディングは、開始と終了のcs:ftcsタグの内側で行う必要があり、これらのタグの外側にコードがあってもWebCenter Sitesでは認識されません。

16.3.2 JSPの暗黙オブジェクトについて

JSPでは、開発者が使用できる暗黙オブジェクトがいくつか用意されています。ただし、WebCenter Sitesのコンテキスト内では、WebCenter Sitesのオブジェクトを扱うことが多いため、JSPの暗黙オブジェクトを使用するかわりにWebCenter SitesのJSPタグとJavaメソッドを使用して、これらのWebCenter Sitesのオブジェクトにアクセスする必要があります。

表16-2では、JSPの暗黙オブジェクトおよびこれらのオブジェクトの主要なメソッドと、これらの代替として使用する必要があるWebCenter Sitesのタグやメソッドの対応関係を示しています。

表16-2 JSPの暗黙オブジェクトのマッピング

オブジェクト

メソッド

WebCenter Sitesのタグやメソッド

request

getParameter

ics:getvarタグ

request

getParameterNames

ICS.GetVars()メソッド

request

getCookie

ics:getCookieタグ

response

addCookie

satellite:cookieタグ

session

getAttribute

ics:getssvarタグ

session

setAttribute

ics:setssvarタグ

out

println

ics:getvarタグまたはrender:streamタグ

16.3.3 JSP構文について

Oracle WebCenter Sitesでは、標準のJSP構文が使用されます。タグをネストする際は(JSPタグのパラメータの値としてJSP式を使用する場合など)、次の例のように必ず一重引用符で式を囲んでください。

name='<%=ics.GetVar("myVariable")%>'

16.3.4 JSPアクションについて

標準のJSPでは、開発者はいくつかの種類のアクションを使用できます。表16-3では、WebCenter Sitesのタグに置き換える必要のあるアクションと、通常どおり使用できるアクションを示しています。

表16-3 JSPのアクションとWebCenter Sitesのタグの比較

アクション

WebCenter Sites

<jsp:forward>

render:satellitepageタグまたはrender:callelementタグをかわりに使用します。

<jsp:getproperty>

これは、カスタムJava Beanに使用し、WebCenter Sitesのプロパティのいずれかの値を探す場合は、<ics:getproperty>タグを使用します。

<jsp:include>

render:satellitepageタグまたはrender:callelementタグをかわりに使用します。

<jsp:setProperty>

これは、カスタムJava Beans内のプロパティを設定する場合に使用します。WebCenter Sitesのプロパティを設定するには、WebCenter Sitesのプロパティ管理ツールを使用します。

<jsp:useBean>

これは、カスタムJava Beanに使用します。

16.3.5 JSP宣言について

標準のJSPでは、通常はJSP宣言内で変数を宣言します。WebCenter Sitesでは、ics:setvarタグを使用して、WebCenter Sitesのコンテキスト内で使用できる変数を宣言します。

WebCenter Sites変数の詳細は、「WebCenter Sitesでサポートされる変数について」を参照してください。

16.3.6 スクリプトレットと式について

スクリプトレットと式は、通常のJSP用法とまったく同じように使用できます。

ただし、WebCenter SitesのJSPタグのパラメータの値として式を使用する場合は、「JSP構文について」で説明しているように、必ず引用符を正しくネストしてください。

16.3.7 JSPディレクティブについて

WebCenter Sitesのコンテキスト内でJSPをコーディングする場合は、表16-4で概略を説明しているように、ディレクティブの使用についていくつかの注意点があります。

表16-4 JSPのディレクティブとWebCenter Sitesのタグの比較

ディレクティブ

WebCenter Sites

IncludeDirective

render:satellitepageタグまたはrender:callelementタグを使用して、他のファイルをJSPページに組み込みます。

pageディレクティブ

WebCenter Sitesユーザー・インタフェースまたはOracle WebCenter Sites Explorerツールを使用して作成したエレメントまたはテンプレートには、標準のpageディレクティブが自動的に追加されます。

標準のディレクティブに加えて、作成するWebCenter Sitesのエレメントやテンプレートごとに、contentTypeを設定するためのもう1つのpageディレクティブを追加する必要があります。

ページのコンテンツ・タイプをtext/htmlに設定して、文字セットをUTF-8に設定するには、WebCenter SitesのすべてのJSPファイルの先頭行として次のpageディレクティブを入力します。

<%@ page contentType="text/html; charset=UTF-8" %>

taglibディレクティブ

WebCenter Sitesでは、作成されるテンプレートとエレメントに使用頻度の高いtaglibディレクティブが自動的に追加されます。

WebCenter Sitesの別のtaglibディレクティブをエレメントやテンプレート・アセットに、必要に応じて追加できます。詳細は、「Oracle WebCenter Sitesのタグ・ライブラリについて」を参照してください。

16.3.8 Oracle WebCenter Sitesのタグ・ライブラリについて

WebCenter Sitesでは、WebCenter SitesのAPIの機能に対応する一連のJSPタグ・ライブラリが用意されています。

表16-5に、WebCenter Sitesのタグ・ライブラリを一覧表示して、これらの機能を説明します。表16-5は、ご使用のJSPにどのタグ・ライブラリをインポートするかを決定する際のリファレンスとして使用してください。

16.3.8.1 ベーシック・アセットとフレックス・アセット両方のタグ・ライブラリ

表16-5 ベーシック・アセットとフレックス・アセット両方のタグ・ライブラリ

タグ・ライブラリ

説明

acl.tld

アクセス制御リストを作成および操作するためのタグ。

date.tld

年、月、日のフィールドと時間、分、午前/午後のオプション・フィールドで構成される日付を、1970年1月1日0:00 GMTから経過したミリ秒数を表すエポック形式の倍長整数に変換するタグ。dateタグは、倍長整数から日付への変換も行います。

dir.tld

ディレクトリ・サービスのタグ。

ftcs1_0.tld

FTCSコンテキストを作成するタグ。これらのタグは、作成したテンプレートまたはエレメントごとに使用され、それらのタグで囲まれたコードがWebCenter Sitesで制御されることを示します。

ics.tld

WebCenter Sitesの中核機能へのアクセスを可能にするタグで、CatalogManagerとTreeManagerのコマンドや、if/then文のような基本的なコーディング構文などがあげられます。

insite.tld

Webモード用のタグ。

localestring.tld

テキスト文字列をローカライズするためのタグ。

name.tld

WebCenter Sitesに現在ログインしているユーザーの名前にアクセスして、ディレクトリ・サービス内のユーザー名を操作するタグ。

object.tld

WebCenter Sitesのオブジェクトを操作するためのタグ。

property.tld

WebCenter Sitesのプロパティ・ファイルから値を取得するためのタグ。

render.tld

ベーシック・アセットをレンダリングするタグ。

Satellite Serverを操作するためのタグ

これらのタグの多くには、同等の機能を持つRENDER版(render.tldで定義)が存在しており、WebCenter Sitesを使用したサイト構築用としては後者が推奨されます。

soap.tld

WebCenter SitesのSOAPタグ。

time.tld

エレメントのパフォーマンスを特定するためのタイミングを取得および設定するタグ。

user.tld

ユーザーをWebCenter Sitesにログインさせたり、WebCenter Sitesからログアウトさせたりするためのタグ。

webservices.tld

特定タイプのパブリックWebサイトをWebCenter Sitesのページの一部として使用することを可能にするWebサービスのタグ。

16.3.8.2 ベーシック・アセット用のタグ・ライブラリ

表16-6 ベーシック・アセット用のタグ・ライブラリ

タグ・ライブラリ

説明

asset.tld

ベーシック・アセットを取得および操作するタグ。

siteplan.tld

サイト・ナビゲーション・ツリーへのアクセスを可能にするタグ。これらのタグは、ベーシック・アセットが使用されるサイトへのナビゲーションを作成するために使用します。

16.3.8.3 フレックス・アセット用のタグ・ライブラリ

表16-7 フレックス・アセット用のタグ・ライブラリ

タグ・ライブラリ

説明

assetset.tld

フレックス・アセットを使用してアセットセットを作成するためのタグ。

blobservice.tld

フレックス・アセットの属性であるBLOBを取得および操作するためのタグ。

calculator.tld

基本的な計算関数とブール関数を提供するタグ。

cart.tld

ショッピング・カート・オブジェクト内のアイテムを追加、削除およびその他の形で操作することを可能にするタグ。

cartset.tld

登録済購入者のショッピング・カート・オブジェクトを保管、取得、削除および一覧表示することを可能にするタグ。

commercecontext.tld

訪問者コンテキスト内のオブジェクトにアクセスするタグ。

currency.tld

浮動小数点値と通貨文字列を変換して、通貨文字列の書式設定と端数処理を実行するタグ。

decimal.tld

浮動小数点値を様々なロケールの小数オブジェクトとして書式設定するタグ。

hash.tld

IListをハッシュ表としてキャストして、キーに基づいてこのハッシュ表内を検索することを可能にするタグ。

listobject.tld

WebCenter Sitesの結果セット・リストを作成するタグで、エレメント全体にわたって他のタグの引数として使用されます。

locale1.tld

ロケール・オブジェクトを生成するタグで、システム内の様々な他のタグのロケールを記述するために使用されます。

misc.tld

各種のタグ(入力リスト内のすべての列の名前を返すタグなど)。

searchstate.tld

フレックス・アセットのグループ(アセットセット)を制約するための検索状態を作成するタグ。

session.tld

指定されたセッションに対して格納されたオブジェクトをすべてフラッシュするタグ。

string.tld

文字列操作を実行するタグ。

textformat.tld

テキストを書式設定するタグ。

vdm.tld

WebCenter Sitesや他のデータベースから、Webサイト訪問者に関する情報を記録および取得することを可能にする訪問者データ管理タグ。

テンプレート開発に使用されるWebCenter Sitesのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

16.4 WebCenter Sites XMLの理解

この項では、WebCenter SitesのXMLの基本事項について説明します。WebCenter SitesのXMLは、標準のXML構文を使用し、futuretense_cs.dtdによって定義されます。WebCenter SitesのJSPタグと同様に、WebCenter SitesのXMLタグは、WebCenter Sitesのサーブレットとオブジェクトへのアクセスを可能にします。

次の各項では、WebCenter SitesのXMLを使用してコーディングする際の注意事項を説明しています。

16.4.1 WebCenter Sitesの標準先頭部

WebCenter Sitesユーザー・インタフェースまたはOracle WebCenter Sites Explorerツールを使用して作成したテンプレートまたはエレメントには、次の標準先頭部が追加されます。

<?xml version="1.0" ?>
<!DOCTYPE ftcs SYSTEM "futuretense_cs.dtd">
<ftcs version="1.2">
</ftcs>

WebCenter Sitesユーザー・インタフェースまたはExplorer以外のツールを使用してエレメントとテンプレートを作成する場合は、これらをコード内にまるごとコピーする必要があります。

次の各項では、この標準先頭部について説明しています。

16.4.1.1 XMLのバージョンとエンコーディング

WebCenter SitesのいずれのXMLテンプレートやXMLエレメントでも、先頭行では次のようにXMLバージョンを設定する必要があります。

<?xml version="1.0"?>

エレメントが実行されるためには、そのエレメントの先頭行は<?xml version="1.0"?>である必要があり、このテキストの前に空白があってはいけません。さらに、この行の末尾に強制改行を入力して、この行を独立した行にする必要もあります。

このテンプレートまたはエレメントのエンコーディングは、次のようにして設定します。

<?xml version="1.0" encoding="utf-8"?>

16.4.1.2 DTDファイル

WebCenter SitesのXMLは、futuretense_cs.dtdファイルによって定義されます。XMLバージョン文の直後に次の行を入力することで、コーディング対象のWebCenter Sitesのエレメントまたはテンプレートのそれぞれにこのファイルをインポートする必要があります。

<!DOCTYPE ftcs SYSTEM "futuretense_cs.dtd">

16.4.1.3 FTCSタグ

WebCenter SitesのそれぞれのXMLテンプレートやXMLエレメントでは、最初と最後のタグとしてftcsタグが使用されている必要があります。このタグは、WebCenter Sitesのコンテキストを作成して、開始と終了のftcsタグの内側に含まれているコードにWebCenter Sitesのタグが格納されることを、WebCenter Sitesに通知します。

コーディングは、開始と終了のftcsタグの内側で行う必要があり、これらのタグの外側にコードがあってもWebCenter Sitesでは認識されません。

16.4.2 XMLのエンティティと予約文字

<や>などの記号はXMLの予約文字であるため、このような記号をコンテンツに入力しないでください。たとえば、次のコードでは、テキスト内で小なり演算子(<)が使用されているため、XMLパーサーが混乱します。

<P>4 < 7</P>

予約文字のかわりに文字エンティティを使用する必要があります。文字エンティティは&#で始まり、セミコロンで終わります。&#とセミコロンの間には、目的の文字の10進Latin-1 (ASCIIのスーパーセット)値を指定します。たとえば、<記号の10進Latin-1値は60であるため、XMLでの前述の行の正しいコーディング法は次のとおりです。

<P>4 &#60; 7</P>

これらの文字エンティティのリストについては、「特殊文字の値について」を参照してください。

注意:

空白を使用すると、JSPを使用してXMLレスポンスを生成する場合に問題が発生することがあります。レスポンスが機能するには、XMLをcontent typeとしてサーバーに追加すればよいという単純なものではありません。空白がXMLファイルの先頭に挿入されないようにJSPを構成する必要があります。

16.4.3 XML解析エラー

WebCenter Sitesのタグを処理するXMLパーサーは、それらのタグが構文的に正しいことを確認します。これにより、タグ付け構文エラーに関する見つけにくい問題を発見することが簡単になります。タグ名のスペルミスはエラーとして報告されません。その理由は、XMLパーサーが、すべてのタグ名がDTD内に存在することを要求しないからです。

WebCenter Sitesシステムに対してページが要求され、XML構文エラーが検知されると、元にストリームされる結果には、問題の所在を突き止めるために役立つ有用な情報が格納されます。これらの結果には、全般的なエラー説明が記載されて、その後にエラーの行と列の位置が示されます。たとえば、次のエラーでは無効なパラメータ名が報告されています。

Illegal attribute name NAM Illegal attribute name NAM
Location: null(6,11)
Context:

次のエラーでは、間違ったタグ・ネストが報告されています。

Close tag IF does not match start tag THEN Close tag IF does not match start tag THEN
Location: null(13,3)
Context:

XMLパーサーは、ランタイム・エラーも検知します。これらのエラーでは、XMLタグは構文的に正しいですが、処理時に構造のエラーが検知されます。たとえば、次のエラーではARGUMENTの無効な使用が報告されています。

Failed to run template:c:\FutureTense\elements\dan.xml Runtime error Argument invalid [Argument 5]
Containing tag: FTCS

16.5 WebCenter Sitesタグの理解

WebCenter Sitesでは、WebCenter Sitesとその製品ファミリの様々な機能へのアクセスを可能にする一連の広範なJSPタグとXMLタグが用意されています。これらのタグを、HTML、Java、JavaScript、および独自に作成するカスタム・タグと組み合せて使用して、Webサイトをコーディングします。

この項では、テンプレート・アセットとエレメントで使用される可能性が高いタグについて、概要を示します。WebCenter Sitesタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

ここで説明するタグは、次のように用途別に分けています。

- WebCenter Sitesのコンテキストを作成するタグ

- 変数を処理するタグ

- ページとエレメントをコールするタグ

- URLを作成するタグ

- キャッシングを制御するタグ

- Cookieを設定するタグ

- プログラミング構文のタグ

- 構成上と承認上の依存関係を管理するタグ

- ベーシック・アセットに関する情報を取得するタグ

- アセットセットを作成するタグ(フレックス・アセット)

- 検索状態を作成するタグ(フレックス・アセット)

16.5.1 WebCenter Sitesのコンテキストを作成するタグ

次のタグは、WebCenter Sitesのコンテキストを作成します(このコンテキスト内でコーディングします)。これらのタグは、記述するすべてのテンプレートやエレメントで使用します。

FTCS (XML)

ftcs1_0:ftcs (JSP)

<FTCS>

</FTCS>

<ftcs1_0:ftcs>

</ftcs1_0:ftcs>

ftcsタグは、WebCenter Sitesのコンテキストを作成します。開始ftcsタグはコード内の最初のタグである必要があり、終了ftcsタグはコード内の最後のタグである必要があります。WebCenter Sitesでは、開始と終了のftcsタグの外側に配置されたコンテンツは認識されません。したがって、これらのタグの外側のコンテンツはキャッシュされず、これらのタグは正しく機能しません。

16.5.2 変数を処理するタグ

次のタグは、WebCenter Sites内の変数を処理します。

CSVAR (XML)

ics:getvar (JSP)

<CSVAR NAME="variableName"/>

<ics:getvar

name="variableName"/>

CSVARは、変数、セッション変数、ビルトインまたはカウンタの値を表示します。

SETVAR (XML)

ics:setvar (JSP)

<SETVAR

NAME="variableName"

VALUE="variableValue"/>

<ics:setvar

name="variableName"

value="variableValue"/>

SETVARは、通常のWebCenter Sites変数の値を設定します。この変数の値は、REMOVEVARを使用して明示的に削除されないかぎり、ページ評価の最中は存続します。

SETSSVAR (XML)

ics:setvar (JSP)

<SETSSVAR

NAME="variableName"

VALUE="variableValue"/>

<ics:setssvar

name="variableName"

value="variableValue"/>

SETSSVARは、セッション変数を設定します。

REPLACEALL (XML)

ics:resolvevariables (JSP)

<REPLACEALL

NAME="variableName"

VALUE="variableValue"/>

<ics:resolvevariables

name="variableName"

[output="variable name"]

[delimited="true|false"]/>

REPLACEALLとics:resolvevariablesは、複数のWebCenter Sites変数を解決します。つまり、WebCenter Sitesの変数をHTMLタグで使用する場合は、これらのタグを使用してそれらの変数を解決します。

WebCenter Sitesの変数の詳細は、「WebCenter Sitesでサポートされる変数について」を参照してください。

16.5.3 ページとエレメントをコールするタグ

次のタグを使用して、エレメントまたはテンプレートをコールします。

注意:

次で使用されているCACHECONTROLは非推奨になりました。

RENDER.SATELLITEPAGE (XML)

render:satellitepage (JSP)

<RENDER.SATELLITEPAGE

PAGENAME="nameOfPageEntry"

[CACHECONTROL="expiration_date_and_time"]

[ARGS_var1="value1"]/>

<render:satellitepage

pagename="nameOfPageEntry"

[cachecontrol="expiration_date_and_time"]>

<[render:argument name="variable1" value="value1"]/>

</render:satellitepage>

RENDER.SATELLITEPAGEは、WebCenter Sitesのページレットを要求して、そのページレットをWebCenter SitesとSatellite Serverの両方でキャッシュします(そのページレットがまだキャッシュ内に存在しない場合)。ページやページレットを個別にキャッシュすることなくコールするには、RENDER.CALLELEMENTタグを使用します。RENDER.SATELLITEPAGEタグはスタックされたスコープを持つため、そのページで使用できる変数は、明示的に渡した変数のみです。

RENDER.CALLELEMENT (XML)

render:callelement (JSP)

<RENDER.CALLELEMENT

ELEMENTNAME="nameOfElement"

[ARGS_var1="value"]/>

<ics:callelement element="element name">

<ics:argument name="argument name" value="arg value"/>

</ics:callelement>

RENDER.CALLELEMENTタグとRENDER.SATELLITEPAGEタグは、どちらのタグも他のWebCenter Sitesコードをコールするという点で似ていますが、前者はエレメント内のコードをコールし、後者はページ内のコードをコールします。ただし、RENDER.CALLELEMENTによってコールされたコードは、個別のページやページレットとしてSatellite Server上でキャッシュされません。

RENDER.CALLELEMENTを使用して、WebCenter Sitesのコンテンツ・アプリケーション用に記述したエレメントのコンテンツを処理します(この場合、そのエレメントのスコープがスタックされることが求められます)。このエレメントはElementCatalog内に存在している必要があります。

16.5.4 URLを作成するタグ

RENDER.GETPAGEURL (XML)

render:getpageurl (JSP)

<RENDER.GETPAGEURL

OUTSTR="myURL"

PAGENAME="SiteCatalogPageEntry"

cid="IDofAsset"

[p="IDofParentPage"]

[c="AssetType"]

[ADDSESSION="true"]

[DYNAMIC="true"]

[PACKEDARGS="stringFromPACKARGStag"]

[ARGS_xxx="y"]/>

<render:getpageurl

outstr="myURL"

pagename="SiteCatalogPageEntry"

cid="IDofAsset"

[p="IDofParentPage"]

[c="AssetType"]

[addsession="true"]

[dynamic="true"]

[packedargs="stringFromPACKARGStag"]>

<[render:argument name="xxx" value="yyy"]/>

</render:getpageurl>

このタグは、アセットのURLを作成して、そのアセットに渡された引数をURLエンコードされた文字列に変換して、その文字列をOUTSTRパラメータで指定された変数として返します。rendermodeがexportに設定されている場合は、このタグは、静的HTMLファイルのファイル名を作成します(ただし、動的URLを求めると指定した場合は除きます)。rendermodeがliveに設定されている場合は、このタグは動的URLを作成します。

RENDER.SATELLITEBLOB (XML)

render:satelliteblob (JSP)

<RENDER.SATELLITEBLOB

SERVICE="HTMLtagName"

BLOBTABLE="blobTable"

BLOBKEY="primaryKeyName"

BLOBWHERE="primaryKeyValue"

BLOBCOL="columnName"

BLOBHEADERNAMEN="headername"

BLOBHEADERVALUEN="mimetype"

[ARGS_format1="5"]

[CACHECONTROL="expirationDateAndTime"]/>

<render:satelliteblob

service="HTMLtagName"

blobtable="blobTable"

blobkey="primaryKeyName"

blobwhere="primaryKeyValue"

blobcol="columnName"

blobheadernameN="headername"

blobheadervalueN="mimetype"

[cachecontrol="expirationDateAndTime"]>

<[render:argument name="format1" value="5"]/>

</render:satelliteblob>

このタグは、BLOBであるアセットのBlobServerのURLが含まれたHTMLタグを作成します。たとえば、イメージ・ファイル・アセットは、WebCenter Sitesデータベースに格納されたBLOBであるため、これらのアセットはBlobServerサーブレットで処理する必要があります。このタグは、指定されたBLOBを検索して書式設定する方法をブラウザに指示するHTMLタグを作成します。

16.5.5 キャッシングを制御するタグ

次のタグを使用すると、現在のテンプレートやエレメントの出力をキャッシュするかどうかを制御できます。

ics.disablecache (XML)

ics:disablecache (JSP)

<ics.disablecache/>

<ics:disablecache/>

ics.disablecacheは、エラー状態の有無をチェックするif/then文と組み合せて使用し、エラーが存在する場合は、結果としてレンダリングされるページはキャッシュされません。ics.disablecacheタグの詳細とコード・サンプルの詳細は、「間違ったページのキャッシングの防止」を参照してください。

16.5.6 Cookieを設定するタグ

次のタグは、WebCenter Sites内のCookieを設定します。

satellite.cookie (XML)

satellite:cookie (JSP)

<satellite.cookie

name="cookie_name"

value="cookie_value"

timeout="timeout"

secure="true|false"

url="URL"

[domain="domain"]/>

<satellite:cookie>

<satellite:parameter name='name' value='cookie_name'/>

<satellite:parameter name='value' value='cookie_value'/>

<satellite:parameter name='timeout' value='cookie_timeout'/>

<satellite:parameter name='secure' value='true|false'/>

<satellite:parameter name='url' value='url'>

</satellite:cookie>

satellite.cookieは、ユーザーのブラウザ上のCookieを設定します。このタグは、XMLまたはJSPでCookieを設定するための唯一の手段です。

16.5.7 プログラミング構文のタグ

次のタグを使用すると、基本的なプログラミング構文を使用できます。

IF/THEN/ELSE (XML)

ics:if/ics:then/ics:else (JSP)

<IF COND="LOGICAL_EXPRESSION">

<THEN>

tags and/or text

</THEN>

<ELSE>

tags and/or text

</ELSE>

</IF>

<ics:if condition="logical expression">

<ics:then>

tags and/or text

</ics:then>

<ics:else>

tags and/or text

</ics:else>

</ics:if>

IF、THEN、ELSEでは、条件を設定します。通常は、これらのタグを使用して変数の値を設定します。

LOOP (XML)

ics:listloop (JSP)

<LOOP [FROM="START"]

[COUNT="LOOP_TIMES"]

[LIST="LIST_NAME"]

[UNTIL="END"]>

...

</LOOP>

<ics:listloop

listname="some list"

[maxrows="number of loops"]

[startrow="start row"]

[endrow="end row"]/>

LOOPとics:listloopは、リスト内のアイテムを反復処理します。すでに述べたように、これらのタグ内に過大な量のコードが含まれている場合は、テンプレートのパフォーマンスが低下します。反復する必要のない文は、できるかぎりLOOPタグの外側に配置してください。

16.5.8 構成上と承認上の依存関係を管理するタグ

構成上と承認上の依存関係の詳細は、「依存性について」を参照してください。

RENDER.LOGDEP (XML)

render:logdep (JSP)

<RENDER.LOGDEP ASSET="asset name"

CID="asset id"

C="asset type"/>

<render:logdep asset="asset name"

cid="asset id"

c="asset type"/>

テンプレートで、アセットをロードすることなくそのアセットのデータを取得するタグ(ASSET.CHILDRENなど)が使用される場合は、RENDER.LOGDEPタグを使用します。

RENDER.UNKNOWNDEPS (XML)

render.unknowndeps (JSP)

<RENDER.UNKNOWNDEPS/>

<render:unknowndeps/>

ページに問合せが含まれているか、そのページの依存アセットに対する他のなんらかの不確定の接続が含まれている場合は、RENDER.UNKNOWNDEPSタグを使用します。このタグは、依存関係を特定できないという理由で、パブリッシュごとにそのページまたはページレットを再生成させます。このため、このタグはできるだけ使用しないでください。

RENDER.FILTER (XML)

render:filter (JSP)

<RENDER.FILTER LIST="list name"

LISTVARNAME="output list name"

LISTDICOL="assetID column"

[LISTTYPECOL="assettype column"]

[TYPE="asset type"]

[ID="asset id"]

[VARNAME="output variable"/>

<render:filter list="list name"

listvarname="output list name"

listidcol="assetID column"

[listtypecol="assettype column"]

[type="asset type"]

[id="asset id"]

[varname="output variable"/>

RENDER.FILTERタグを使用して、未承認アセットの有無を確認して、未承認アセットがエクスポートされるページに含まれることを防止します。このタグは、それぞれのアセットIDをApprovedAssetsデータベース表のassetid列と照合することで、単一のアセットまたはアセットのリストをフィルタリングします。エクスポート・レンダリング時は、このタグは、承認ステータスに基づいてパブリッシュ可能な対象をフィルタリングします。ライブ・レンダリング時は、RENDER.FILTERは何の処理も実行しません。このタグは、テンプレート内のアセットのリストに対するデータベース問合せがある場合は常に使用してください。

16.5.9 ベーシック・アセットに関する情報を取得するタグ

ASSET.LOAD (XML)

asset:load (JSP)

<ASSET.LOAD

NAME="assetName"

TYPE="assetType"

OBJECTID="object.id"

[FIELD="fieldName"]

[VALUE="fieldValue"]

[DEPTYPE="EXACT, EXISTS,

or GREATER"]/>

<asset:load

name="assetName"

type="assetType"

objectid="object.id"

[field="fieldName"]

[value="fieldValue"]

[deptype="exact,exists,or greater"]/>

このタグは、データベースに対して特定のアセットについて問い合せてから、そのアセットのデータをメモリー内にオブジェクトとしてロードします。このオブジェクトは、当該セッションがフラッシュされるかそのオブジェクトに割り当てられた名前が上書きされるまで、エレメントで使用可能になります。

ロードされたアセットに割り当てるオブジェクト名のスコープは、グローバル です。エレメントによってオブジェクトが誤って上書きされることを防止するために、必ず一意のオブジェクト名を使用してください。便利なネーミング規則は、エレメント名をアセット名に含めることです。この規則に従って一意のアセット・オブジェクト名を作成する例については、「ベーシック・モジュラ・デザインの作成」を参照してください。

ASSET.LOADは、このタグを使用するテンプレートやエレメントとこのタグによって取得されるアセット・データとの間の依存関係を自動的にログに記録します。

ASSET.SCATTER (XML)

asset:scatter (JSP)

<ASSET.SCATTER

NAME="assetName"

PREFIX="variablePrefix"/>

<asset:scatter

name="assetName"

prefix="variablePrefix"/>

このタグは、ASSET.LOADタグを使用して取得(ロード)されているアセット・オブジェクトのすべてのフィールドから値を取得して、これらの値をWebCenter Sitesの変数に変換します。たとえば、オンライン記事のヘッドライン、署名行、本文などを表示するには、このタグを使用して、1回のコールでこれらの値をすべて取得できます。

ASSET.GET (XML)

asset:get (JSP)

<ASSET.GET

NAME="assetName"

FIELD="fieldName"

[OUTPUT="outputVariable"]/>

<asset:get

name="assetName"

field="fieldName"

[output="outputVariable"]/>

このタグは、ASSET.LOADタグを使用して取得(ロード)されているアセット・オブジェクトの1つの指定フィールドから値を取得して、その値をWebCenter Sitesの変数に変換します。たとえば、記事のリンクで使用するためにその記事のヘッドラインを使用するには、このタグを使用してその値だけを取得します。

ASSET.CHILDREN (XML)

asset:children (JSP)

<ASSET.CHILDREN

NAME="assetName"

LIST= "listName"

[CODE= "NameOfAssociation"]

[OBJECTTYPE= "typeOfObject"]

[OBJECTID="objectID"]

[ORDER="nrank"]/>

<asset:children

name="assetName"

list="listName"

[code="NameOfAssociation"]

[objectype="typeOfObject"]

[objectid="objectID"]

[order="nrank"]/>

このタグは、AssetRelationTree表に問い合せて、指定されたアセットの子アセットのリストを作成します。このタグを使用して、コレクション内のアセットを取得したり、記事アセットに関連付けられたイメージ・アセットを取得したりします。

RENDER.LOGDEPタグをASSET.CHILDRENと組み合せて使用して、このタグが含まれたエレメントやテンプレートと、ASSET.CHILDRENによって取得されるコンテンツとの間の依存関係をログに記録します。

16.5.9.1 アセット・タグに関するパフォーマンス上の注意事項

- ASSET.LOADとASSET.CHILDRENはデータベース問合せであり、データベースに対する問合せは時間がかかるため、これらのタグは必要な場合にのみ使用してください。たとえば、ASSET.LOADタグとその後続のASSET.CHILDRENタグの間にエラー・チェック・コードを挿入することも可能で、後者のタグは、アセットがASSET.LOADによって返されたかどうかを判定します。アセットが存在しない場合は、ASSET.CHILDRENタグを呼び出さないでください。

- ASSET.SCATTERコールは、単一のASSET.GETコールよりもはるかに長い時間がかかります。

16.5.10 アセットセットを作成するタグ(フレックス・アセット)

アセットセット・タグでは、データベースから取得する1つ以上のフレックス・アセットのセットを指定します。

アセットセットから取得できる情報は次のとおりです。

- アセットセット内の各フレックス・アセットの1つの属性の値

- アセットセット内の各フレックス・アセットの複数の属性の値

- アセットセット内のフレックス・アセットのリスト

- アセットセット内のフレックス・アセットの数

- アセットセット内のすべてのフレックス・アセットの1つの属性の一意の属性値のリスト

- アセットセット内のすべてのフレックス・アセットの属性の一意の属性値の数

使用頻度の高いアセットセット・タグは次のとおりです。

ASSETSET.SETASSET (XML)

assetset:setasset (JSP)

<ASSETSET.SETASSET

NAME="assetsetname"

TYPE="assettype"

ID="assetid"

[LOCALE="localeobject"]

[DEPTYPE="exact|exists|none"]

/>

<assetset:setasset name="assetsetname" type="assettype" id="assetid" [locale="localeobject"] [deptype="exact|exists|none"]/>

ASSETSET.SETASSETは、指定された単一のアセットからアセット・セットを作成して、このタグが含まれたテンプレートやエレメントと、このタグによって取得されるコンテンツとの間の構成上の依存関係を定義します。

ASSETSET.SETSEARCHEDASSETS (XML)

assetset:setsearchedassets (JSP)

<ASSETSET.SETSEARCHEDASSETS

NAME="assetsetname"

[ASSETTYPES="assettype"] [CONSTRAINT="searchstateobject"] [LOCALE="localeobject"] [SITE="siteidentifier"] [DEPTYPE="exact|exists|none"]/>

<assetset:setsearchedassets

name="assetsetname"

[assettypes="assettype"]

[constraint="searchstateobject"]

[locale="localeobject"]

[site="siteidentifier"]

[deptype="exact|exists|none"]/>

ASSETSET.SETSEARCHEDASSETSは、指定された検索条件によって絞り込まれた特定タイプのすべてのアセットを表すアセットセット・オブジェクトを作成します(この検索条件は、constraintパラメータで指定される検索状態オブジェクトによって表されます)。

このタグは、このタグが含まれたテンプレートやエレメントと、アセットセット内の各アセットとの間の構成上の依存関係も規定します。

ASSETSET.GETMULTIPLEVALUES (XML)

assetset:getmultiplevalues (JSP)

<ASSETSET.GETMULTIPLEVALUES

NAME="assetsetname"

LIST="listname"

[BYASSET="true|false"]

PREFIX="prefix"/>

<assetset:getmultiplevalues

name="assetsetname"

list="listname"

[byasset="true|false"]

prefix="prefix"/>

ASSETSET.GETMULTIPLEVALUESは、複数の属性(および場合によっては複数のアセット)の属性値を複数の指定リスト内に分散します。

ASSETSET.GETMULTIPLEVALUESを使用することが推奨されるのは、固定形式のアセット表を表示しようとしている場合や、単一アセットの多くの属性を取得しようとしている場合です(製品詳細ページなどのために)。

ASSETSET.GETMULTIPLEVALUESの制限事項は次のとおりです。

- 非外部属性のみを分散できます。

- テキスト・タイプの属性は分散できません。

ASSETSET.GETATTRIBUTEVALUES (XML)

assetset:getattributevalues (JSP)

<ASSETSET.GETATTRIBUTEVALUES

NAME="assetsetname"

ATTRIBUTE="attribname"

[TYPENAME="assettypename"]

LISTVARNAME="varname"

[ORDERING="ascending|descending"]/>

<assetset:getattributevalues

name="assetsetname"

attribute="attribname"

[typename="assettypename"]

listvarname="varname"

[ordering="ascending|descending"]/>

ASSETSET.GETATTRIBUTEVALUESは、アセットセットによって表されるアセットの指定された属性の値のリストを取得します。

ASSETSET.GETASSETLIST (XML)

assetset:getassetlist (JSP)

<ASSETSET.GETASSETLIST

NAME="assetsetname"

[LIST="attriblist"]

[MAXCOUNT="rowcount"]

[METHOD="random|highest"]

LISTVARNAME="varname/>

<assetset:getassetlist

name="assetsetname"

[list="attriblist"]

[maxcount="rowcount"]

[method="random|highest"]

listvarname="varname"/>

ASSETSET.GETASSETLISTは、オプションのソート条件に基づいて、順序付けられたアセット・リストを取得します。得られるリストはassetidとassettypeという2つの列からなり、これらの列は指定された条件に基づいてソートされます。

16.5.11 検索状態を作成するタグ(フレックス・アセット)

検索状態タグは、assetsetタグを使用して取得されたアセットをフィルタリングする条件を構成します。

検索状態を構築するには、検索状態によって記述されるフレックス・アセットのリストに対して、制約を追加して絞り込むか、または制約を削除して広げます。

使用頻度の高いsearchstateタグは次のとおりです。

SEARCHSTATE.CREATE (XML)

searchstate:create (JSP)

<SEARCHSTATE.CREATE

NAME="ssname"

[OP="and|or"]/>

<searchstate:create

name="ssname"

[op="and|or"]/>

SEARCHSTATE.CREATEは、空の検索状態オブジェクトを作成します。このタグを使用して検索状態の構築を開始する必要があります。

SEARCHSTATE.ADDSTANDARDCONSTRAINT (XML)

searchstate:addstandardconstraint (JSP)

<SEARCHSTATE.ADDSTANDARDCONSTRAINT

NAME="ssname"

[BUCKET="bucketname"]

[TYPENAME="assettype"]

ATTRIBUTE="attribname"

[LIST="listname"]

[IMMEDIATEONLY="true|false"]

[CASEINSENSITIVE="true|false"]/>

<searchstate:addstandardconstraint

name="ssname"

[bucket="bucketname"]

[typename="assettype"]

attribute="attribname"

[list="listname"]

[immediateonly="true|false"]

[caseinsensitive="true|false"]/>

SEARCHSTATE.ADDSTANDARDCONSTRAINTは、属性の名前と値の制約を新規または既存の検索状態オブジェクトに追加します。

listパラメータで指定する値のリストによって、属性を制約できます。

SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT (XML)

searchstate:addsimplestandardconstraint (JSP)

<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT

NAME="ssname"

[BUCKET="bucketname"]

[TYPENAME="assettype"]

ATTRIBUTE="attribname"

VALUE="value"

[IMMEDIATEONLY="true|false"]/>

<searchstate:addsimplestandardconstraint

name="ssname"

[bucket="bucketname"]

[typename="assettype"]

attribute="attribname"

value="value"

[immediateonly="value"]/>

SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINTは、属性の名前と単一値の制約を既存の検索状態に追加します。

このタグは、SEARCHSTATE.ADDSTANDARDCONSTRAINTの簡易版です。NAMEで指定されたオブジェクトは、新しい制約を反映して更新されます。属性名が検索状態内にある場合は、新しい制約によって古い制約が置換されます。

SEARCHSTATE.ADDRANGECONSTRAINT (XML)

searchstate:addrangeconstraint (JSP)

<SEARCHSTATE.ADDRANGECONSTRAINT

NAME="ssname"

[BUCKET="bucketname"]

[TYPENAME="assettype"]

ATTRIBUTE="attribname"

LOWER="lowrange"

UPPER="uprange"

[CASEINSENSITIVE="true|false"]/>

<searchstate:addrangeconstraint

name="ssname"

[bucket="bucketname"]

[typename="assettype"]

attribute="attribname"

lower="lowrange"

upper="uprange"

[caseinsensitive="true|false"]

/>

SEARCHSTATE.ADDRANGECONSTRAINTは、特定の属性名の範囲制約を追加します。

SEARCHSTATE.ADDRICHTEXTCONSTRAINT (XML)

searchstate:addrichtextconstraint (JSP)

<SEARCHSTATE.ADDRICHTEXTCONSTRAINT

NAME="ssname"

[BUCKET="bucketname"]

[TYPENAME="assettype"]

ATTRIBUTE="attribname"

VALUE="criteria"

[PARSER="parsername"]

CONFIDENCE="minlevel"

[MAXCOUNT="number"] />

<searchstate:addrangeconstraint

name="ssname"

[bucket="bucketname"]

[typename="assettype"]

attribute="attribname"

lower="lowrange"

upper="uprange"

[caseinsensitive="true|false"]

/>

SEARCHSTATE.ADDRICHTEXTCONSTRAINTは、属性名とリッチテキスト表現を検索状態内のリッチテキスト制約のリストに追加します。

SEARCHSTATE.TOSTRING (XML)

searchstate:tostring (JSP)

<SEARCHSTATE.TOSTRING

NAME="objname"

VARNAME="varname"/>

<searchstate:tostring

name="objname"

varname="varname"/>

SEARCHSTATE.TOSTRINGは、検索状態オブジェクトをそのオブジェクトの文字列表現に変換し、この文字列表現は、セッション変数に保存したりURLに組み込んだりといった様々な用途に適しています。

SEARCHSTATE.FROMSTRING (XML)

searchstate:fromstring (JSP)

<SEARCHSTATE.FROMSTRING

NAME="objname"

VALUE="stringval"/>

<searchstate:fromstring

name="objname"

value="stringval"/>

SEARCHSTATE.FROMSTRINGを使用すると、検索状態オブジェクトを、その文字列表現から初期化できます。このタグを使用する前に、SEARCHSTATE.CREATEタグを使用して空の検索状態を作成する必要があります。

16.6 WebCenter Sitesでサポートされる変数について

WebCenter Sitesでサポートされている変数の種類は次のとおりです。

- 通常変数: この変数は、明示的に削除されないかぎり、現在のテンプレートやエレメントが存続している間は存続します。通常変数にはグローバル・スコープが設定されています。

- セッション変数: この変数は、現在のセッションが継続している間は存続します。

WebCenter Sitesでは、予約された名前を持ついくつかの標準変数が用意されています。これらの変数の値を取得することはできますが、これらの変数の名前を他の独自に作成した変数の名前として使用することはできません。

この項には次のトピックが含まれます:

- 予約変数

- 標準変数

- セッション変数

- 変数の操作

- 変数と優先順位

- 変数に関するベスト・プラクティス

16.6.1 予約変数

表16-8では、WebCenter Sitesの標準的な変数を説明しています。

注意:
予約変数の変更は許可されていません。

表16-8 予約変数

変数

定義

tablename

execsqlタグが実行可能になる前に、表名に設定される変数。

pagename

呼び出されたWebCenter Sitesページの名前。

ftcmd

CatalogManagerのコールで使用される変数。

username

現行セッションに現在ログインしているユーザーの名前が格納されたセッション変数。

password

現行セッションに現在ログインしているユーザーのパスワードが格納されたセッション変数。

authusername

WebCenter Sitesにログインさせるユーザーのユーザー名に設定できる変数。これは、URLを使用してWebCenter Sitesに送信できます。

authpassword

WebCenter Sitesにログインさせるユーザーのパスワードに設定できる変数。これは、URLを使用してWebCenter Sitesに送信できます。

currentACL

現在のユーザーが属しているACLが格納されたセッション変数。

errno

WebCenter Sitesのタグによって報告されるエラー番号。

context

render:calltemplateタグで将来に使用されるために予約されています。詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

site

Publication表のname列に格納されている、サイトのフルネーム。

site変数は、すべてのテンプレート・アセットとSiteEntryアセット内のresargとして設定されます。このサイトは、このサイト内で作成されたテンプレート・アセットとSiteEntryアセットを所有しています。

sitepfx

Publication表のcs_prefix列に格納されている、サイトの接頭辞(およびサイトの短縮名)。

ft_ss

Satellite Serverとの通信をサポートするためにWebCenter Sitesによって自動的に設定される内部変数。ft_ssがtrueに設定されている場合は、WebCenter Sitesは、要求元がSatellite Serverであると推定します。

c

テンプレートによって書式設定されるアセット・タイプ。WebCenter Sitesは、テンプレート・アセットが保存されるときにデフォルトでこの変数を設定します。

cid

テンプレートによってレンダリングまたは書式設定されるアセットのID。

ct

子テンプレートの値(子テンプレートが存在する場合)。子テンプレートの詳細は、「ct変数の使用」を参照してください。

p

アセットの親ページのID(親ページが存在する場合)。

rendermode

ページ・エントリがライブ、エクスポート済、プレビュー済のいずれの状態で提供されるのかを指定します。デフォルトでは、rendermodeはliveです。ディスクへのエクスポートまたはプレビュー機能を使用する場合は、WebCenter Sitesは自動的にこの変数の値をexportまたはpreviewにオーバーライドします。この値は内部で使用されるため、変更しないでください。

seid

SiteEntryアセットのID。

tid

テンプレート・アセットのID。

eid

CSElementアセットのID。eidは、CSElementのルート・エレメントで使用できます。

16.6.2 標準変数

WebCenter Sitesのテンプレートやエレメントをコーディングする際に使用する変数のほとんどは、通常変数です。通常変数は、WebCenter Sitesのタグを使用して明示的に削除されないかぎり、現在のテンプレートやエレメントが存続している間は存続します。

16.6.2.1 SETVARを使用した変数

WebCenter Sitesのエレメント内では、SETVARというXMLタグやJSPタグをコールし、変数を作成してその初期値を設定できます。たとえば、次のSETVAR XMLタグは、dogという名前の変数を作成して、その値をfidoに設定します。

<SETVAR NAME="dog" VALUE="fido"/>

この変数が存在している場合は、SETVARはその値を新しい値に再設定します。たとえば、次のコマンドは、dogの値をmochaに再設定します。

<SETVAR NAME="dog" VALUE="mocha"/>

16.6.2.2 URLを使用した変数

WebCenter Sitesアプリケーションによって管理されているURLにブラウザがアクセスすると、WebCenter Sitesはページを作成します。各ページは特定のURLに関連付けられています。たとえば、次の形式のURLに関連付けられたページがあるとします。

http://host:port/servlet/ContentServer?pagename=Experiment/Hello

すべてのURLの末尾に、1つ以上の変数を設定できます。たとえば、次のURLは、Helloページ内に3つの変数を作成します。

http://host:port/servlet/ContentServer?pagename=Experiment/Hello&dog=fido&cat=fifi

このURLは、Helloで使用できる次の変数を作成します。

- Experiment/Helloという値が設定されたpagenameという名前の変数

- fidoという初期値が設定されたdogという名前の変数

- fifiという初期値が設定されたcatという名前の変数

16.6.2.3 Explorerを使用したエレメントとテンプレートのデフォルト変数

Explorerを使用してページ内のデフォルト変数を作成するには、それらの変数を次のフィールドのいずれかに入力します。

- SiteCatalogデータベース表のresargs1フィールドまたはresargs2フィールド。

- ElementCatalogデータベース表のresdetails1フィールドまたはresdetails2フィールド。

たとえば、Explorerを使用してSiteCatalog表にアクセスして、図16-1に示すように、resargs1フィールドとresargs2フィールドに名前と値のペアを入力することで、dogとcatという変数を作成できます。

図16-1 SiteCatalogフィールド

この例では、一方の名前と値のペアをresargs1に入力して、もう一方の名前と値のペアをresargs2に入力していることに注意してください。別の方法として、図16-2のように両方の名前と値のペアをresargs1に入力することもできます。

図16-2 SiteCatalogの値

図16-3のように、resdetails1フィールドとresdetails2フィールドに名前と値のペアを入力することで、ElementCatalog表でdogとcatの値を設定することもできます。

図16-3 ElementCatalogフィールド

URLを通じて設定された変数や、POST操作やGET操作を通じて設定された変数は、SiteCatalog表やElementCatalog 表を使用して設定された変数よりも優先されます。たとえば、URLを通じて変数dogがrexに設定されている一方で、SiteCatalogでdogがfidoに設定されている場合は、結果として得られるdogの値はrexになります。

16.6.2.4 HTMLフォームを使用した変数

CGIプログラミングでは、購入者はフォームに入力します。次に、ブラウザはその購入者の入力内容を名前と値のペアとしてエンコードして、これらの名前と値のペアはCGIスクリプトに渡されます。

WebCenter Sitesでは従来のCGIプログラミングは使用されませんが、WebCenter Sitesのエレメントは従来どおりフォームを表示できます。従来のプログラミングの場合と同様に、ブラウザは購入者の入力内容を名前と値のペアとしてエンコードします。ただし、これらの名前と値のペアはCGIプログラムに渡されるかわりに、別のWebCenter Sitesページに渡されます。受取り側のWebCenter Sitesページは、WebCenter Sitesの任意の変数にアクセスするのと同じように、これらの名前と値のペアにアクセスできます。

Cookieの名前と値も変数としてインスタンス化されます。Cookieの詳細は、「セッションおよびCookieについて」を参照してください。

16.6.3 セッション変数

HTTPはステートレスなプロトコルです。この制約に対処するために、WebCenter Sitesは複数の要求にまたがって状態を維持でき、そうすることでセッションを追跡管理できます。

ブラウザをWebCenter Sitesシステムに接続すると、セッションが確立されます。その後は、そのセッションがシステム側で一意に識別されます。WebCenter Sitesは、この一意の識別情報に基づいたコンテンツと動作を備えたページを提供できます。

クライアントが最初にサイトにアクセスすると、一意のセッションが確立されます。WebCenter Sitesは、デフォルトのユーザーIDを新しいセッションに関連付けて、その情報をセッション変数内に保持します。セッション変数に格納された値は、そのセッションが継続する間は使用できます。セッション変数は、ユーザーのセッションの一部として保存されて、変数の値を複数のページ要求にまたがって保持するために使用されます。

クラスタ化された構成では、セッションの状態はすべてのクラスタ・メンバーにまたがって維持されます。セッション変数は慎重に使用してください。使用されるセッション変数の数とサイズに比例して、リソース負荷が増大するからです。

セッションの状態は、次の状況が発生すると失われます。

- クライアントが終了しました。

- セッションがタイムアウトしました。WebCenter Sitesは、一定期間にわたって要求が発行されない場合は任意でセッションを終了させることができます。

- アプリケーション・サーバーが再起動されました。

セッションに関連付けられたサーバー・リソースは、次の状況が発生すると割当て解除されます。

- WebCenter Sitesのタグを使用して、クライアントによってセッションが明示的に終了されました。

- セッションがタイムアウトしました。

- アプリケーション・サーバーが再起動されました。

セッション変数を作成するには、SETSSVARというXMLタグおよびJSPタグを使用します。そのセッション変数が存在している場合は、SETSSVARはその変数の値を再設定します。たとえば、次のSETSSVAR XMLタグは、セッション変数profileの値を10154に設定します。

<SETSSVAR NAME="profile" VALUE="10154"/>

16.6.4 変数の操作

次の各項では、WebCenter Sitesの変数を操作する方法を説明しています。

16.6.4.1 変数の値を読み取るための構文

変数の値を読み取るために使用する構文は、次のように変数のタイプに応じて異なります。

表16-9 変数および構文

変数のタイプ

構文

例

文字列変数

Variables.variable_name

Variables.dog

カウンタ変数

Counters.variable_name

Counters.position

セッション変数

SessionVariables.variable_name

SessionVariables.username

プロパティ

CS.Property.property_name

cs.use.short.jsp.names

WebCenter SitesのXMLでは、リスト変数にアクセスするための多くのメソッドが用意されています。

16.6.4.2 変数の値を表示するためのタグ

CSVAR XMLタグを使用すると、プロパティやセッション変数を含む任意のタイプの変数の値を表示できます。WebCenter Sitesの通常変数の値を表示する際に使用するJSPタグはics:getvarで、セッション変数の値を表示する際に使用するJSPタグはics:getssvarです。たとえば、次のコードがXMLエレメントに含まれているとします。

<SETVAR NAME="mood" VALUE="happy"/>
<p>My dog is <CSVAR NAME="Variables.mood"/>.</p>

この場合は、得られるページでは次のテキストが表示されます。

My dog is happy.

CSVAR XMLタグのNAME引数の一部としてリテラル値を含めることも可能で、たとえば、次のコードによっても「My dog is happy.」というテキストが生成されますが、前述のコードよりも評価に時間がかかります。

<SETVAR NAME="mood" VALUE="happy"/>
<p><CSVAR NAME="My dog is Variables.mood"/>.</p>

16.6.4.3 別の変数への単一変数値の割当て

1つの変数の値を別の変数に割り当てることができます。そのための方法は、XMLでコーディングする場合とJSPでコーディングする場合とで異なります。

JSP

JSPでコーディングする場合は、JSPタグを別のJSPタグ内にネストできないため、ics:getvarタグを使用して変数の値を評価することはできません。この制限を回避するには、次のサンプル・コードで示すように、ics.GetVarというJavaメソッドを使用して変数の値を置換します。

<ics:setvar name="myVar" value="Fred"/>
<ics:setvar name="yourVar" value='<%=ics.GetVar("myVar")%>'/>
<ics:getvar name="yourVar"/>

注意:

変数の値を評価する式は、一重引用符で囲む必要があります(この例では'<%=icsGetVar("myVar")%>')。そうしないと、JSPエレメントによって例外がスローされます。

XML

次のXMLコードは、carambolaという値をyour_favoriteという変数に割り当てます。

<SETVAR NAME="my_favorite" VALUE="carambola"/>
<SETVAR NAME="your_favorite" VALUE="Variables.my_favorite"/>

これをさらに一歩進めて、2つの変数値を連結して、その連結結果を3つ目の変数に割り当てることができます。たとえば、次のコードは、carという変数をred rabbitという値に設定します。

<SETVAR NAME="color" VALUE="red"/>
<SETVAR NAME="model" VALUE="rabbit"/>
<SETVAR NAME="car" VALUE="Variables.color Variables.model"/>

16.6.4.4 HTMLタグの変数

XML変数やJSP変数を従来のHTMLタグ内で使用できますが、そのためのコーディング方法はXMLの場合とJSPの場合とで異なります。

JSP

JSPでコーディングする場合は、ics:getvarタグまたはics.GetVar Javaメソッドを使用して変数の値を評価します。

ics.resolvevariablesタグを使用して、文字列に含まれた変数を解決することもできます。たとえば、次のコードは、「The date is」というフレーズとCS.Date変数の値を組み合せて表示します。

<ics.resolvevariables name="The date is $(CS.Date)." delimited="true"/>

delimitedパラメータは、デリミタ$(および)を使用して、解決対象の変数を明示的にマークしていることを示します。たとえば、変数を使用してリスト名とそのリスト内の列を指定するには、次の構文を使用します。

<ics.resolvevariables name="$(Variables.listname).$(Variables.columnname)" delimited="true"/>

delimitedパラメータがfalseに設定されている場合は、変数を区切るためにデリミタが使用されていません。

XML

適切な属性を使用している場合は、HTMLタグ内でXML変数を使用できます。たとえば、次のコードには適切な属性が含まれていないため、背景色が赤に設定されません。

<SETVAR NAME="color" VALUE="red"/>
<TABLE bgcolor="Variables.color">
...

HTMLタグ内でXML変数の値を使用するには、そのHTMLタグ内でREPLACEALL属性を使用する必要があります。REPLACEALL属性は、このHTMLタグ内のこのXML変数の現行値を置換するようにシステムに指示します。したがって、前述の行の正しいコーディング方法は次のとおりです。

<SETVAR NAME="color" VALUE="red"/>
<TABLE bgcolor="Variables.color" REPLACEALL="Variables.color">
...

1つのREPLACEALL属性内で複数の変数値を組み合せることができます。たとえば、次のHTMLタグTABLEでは、2つのXML変数が使用されています。

<SETVAR NAME="color" VALUE="red"/>
<SETVAR NAME="myborder" VALUE="3"/>
<TABLE bgcolor="Variables.color" border="Variables.myborder"
REPLACEALL="Variables.color,Variables.myborder">
...

<REPLACEALL>タグは、REPLACEALL属性の代替手段です。<REPLACEALL>タグは、そのドメイン内で置換を実行します。次に例を示します。

<SETVAR NAME="highlight" VALUE="red"/>
<SETVAR NAME="diminish"  VALUE="gray"/>
<REPLACEALL LIST="Variables.highlight,Variables.diminish">
<TABLE>
<TR BGCOLOR="Variables.highlight"><TD>Diamonds</TD></TR>
<TR BGCOLOR="Variables.highlight"><TD>Pearls</TD></TR>
<TR><TD>Malachite</TD></TR>
<TR BGCOLOR="Variables.diminish"><TD>Coal</TD></TR>
</TABLE>
</REPLACEALL>

図16-4に、このセクションの出力を示します。

図16-4 サンプル出力

REPLACEALLタグは文字列の検索と置換を実行するため、その処理には長い時間がかかる可能性があります。可能な場合は、REPLACEALL属性を使用してください。REPLACEALLタグを使用する必要がある場合は、このタグで囲むコードの量をできるだけ少なくしてください。

16.6.4.5 IF/THEN/ELSEを使用した変数の評価

WebCenter SitesのXMLとJSPでは、ほとんどのコンピュータ言語で使用可能なIF/THEN/ELSE構文が用意されています。ただし、変数を対象にした唯一の条件付き演算は、2つの値を比較して一致または不一致を判定することのみです。たとえば、2つの値を比較して、一方が他方より大きいかどうかを判定できません。(ただし、この処理を実行するJavaコードは記述できます。)

たとえば、次のコードは、greetingという変数の値に応じて分岐します。

<IF COND="Variables.greeting=Hello">
<THEN>
<p>Welcome.</p>
</THEN>
<ELSE>
<p>So long.</p>
</ELSE>
</IF>

greetingがHelloに設定されている場合は、WebCenter Sitesは次のHTMLを生成します。

<p>Welcome.</p>

greetingがHello以外の値に設定されている場合は、WebCenter Sitesは次のように生成します。

<p>So long.</p>

16.6.5 変数と優先順位

URLを通じて設定された変数や、HTTPのGET操作やPOST操作を通じて設定された変数は、SiteCatalog表やElementCatalog表のresargs列やresdetails列を使用して設定された変数よりも優先されます。

16.6.6 変数に関するベスト・プラクティス

すべての変数はグローバルであり、リスト内のアイテムから変数にアクセスするための構文と他のソースから変数にアクセスするための構文は同じであるため、適切なコーディング手法はエラーを回避するのに役立ちます。例:

- エレメント内でベース名を再利用することは簡単なため、変数の前に接頭辞を付けてそれらの変数を一意に定義してください。推奨される構文は、Variables.assettype:fieldnameです。
たとえば、Variables.Article:descriptionのようにします。

ASSET.SCATTERタグでは、そのPREFIX属性を通じてこの構文を簡単に使用できます。このタグの詳細は、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- RESOLVEVARIABLESタグを使用して変数を解決しようとしている場合は、DELIMITEDパラメータをtrueに設定して、デリミタ$(および)を使用して解決対象の変数を明示的に示してください。

- デバッグを通じてネーミングの競合を検出してください。loggingconfig.xmlのcom.fatwire.logging.csプロパティを設定します。このプロパティを有効にすると、WebCenter Sitesは、作成されたすべての変数のレコードをWebCenter Sitesのログ・ファイルに書き込みます。

WebCenter Sitesのタグによってerrno変数に書き込むことができるエラー値のリストについては、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

16.7 WebCenter Sitesの他の記憶域構成体

通常変数とセッション変数に加えて、WebCenter Sitesはいくつかの記憶域構成体をサポートしています。次の各項では、これらの構成体とこれらの使用法を説明します。

- ビルトイン

- リスト

- カウンタ

16.7.1 ビルトイン

WebCenter Sitesでは、現在日付などの値を返すいくつかのビルトインが用意されています。

ビルトインの一般的な構文は次のとおりです。

CS.builtin

たとえば、UniqueIDは一意のIDを生成するビルトインです。次の構文は、このビルトイン変数を生成または参照します。

CS.UniqueID

WebCenter Sitesのビルトインのリストについては、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

16.7.2 リスト

リストは、行と列で編成された値の表からなります。SETROWタグまたはGOTOROWタグを使用して、適切な行を識別します。

次のエンティティはリストを作成します。

- SELECTTOタグ、EXECSQLタグ、CATALOGDEFタグ、STRINGLISTタグおよびCALLSQLタグ

- CatalogManagerのコマンド。

- TreeManagerのコマンド。

- Customタグ。

現在の行の列値を参照するには、次の構文を使用します。

listname.colname

たとえば、carsという名前のリストにcolorという名前の列が存在する場合、現在の行の値を参照するには次のようにします。

cars.color

16.7.2.1 リストのループ処理

リストを反復処理するには、LOOPというXMLタグまたはics:listloopというJSPタグを使用します。リスト内の各行について、WebCenter Sitesはこれらのループ・タグの内側に配置された命令を実行します。

たとえば、次の行が含まれたMyCarsという名前の表があるとします。

表16-10 行を含むサンプル表

id

モデル

色

年

224

Ford Focus

青

2001

358

VW Rabbit

赤

1998

359

Toyota Corolla

黄

2000

372

Alpha Romeo Spider

赤

1982

401

Porsche 911

赤

1984

423

Dodge Voyager

茶

1991

次のXMLコードは、MyCars内で赤色の車を検索します。SELECTTOというXMLタグおよびJSPタグは、この情報をcarlistという名前のリスト変数に書き込みます。

<SETVAR NAME="color" VALUE="red"/>
<SELECTTO FROM="MyCars" WHERE="color" WHAT="*" LIST="carlist"/>
Red cars: <BR/>
<OL>
<LOOP LIST="carlist">
<LI><CSVAR NAME="carlist.model"/> </LI>
</LOOP>
</OL>

このXMLコードは、次のHTMLを生成します。

Red cars: <BR/>
<OL>
<LI> VW Rabbit </LI>
<LI> Alpha Romeo Spider </LI>
<LI> Porsche 911 </LI>
</OL>

16.7.3 カウンタ

カウンタは、整数値が格納されるXML変数です。カウンタは次の3つのタグによって制御されます。

表16-11 カウンタ

タグ

主な機能

SETCOUNTER

カウンタ変数を初期化します

INCCOUNTER

カウンタの値を、指定された量のみ変更します

REMOVECOUNTER

カウンタ変数を破棄します

カウンタを作成するには、SETCOUNTERをコールします。カウンタの値を変更するには、INCCOUNTERをコールします。たとえば、次のコードを考えてみましょう。

<SETCOUNTER NAME="c" VALUE="10"/>
<INCCOUNTER NAME="c" VALUE="3"/>
<p>Current value is <CSVAR NAME="Counters.c"/></p>

このコードの出力は次のとおりです。

Current value is 13

この例からわかるように、カウンタ変数を参照するには次の構文を使用します。

Counters.name

16.8 特殊文字の値について

XMLやJSPで(英数字以外の)特殊文字を使用するには、それらの16進文字表現を使用します。たとえば、次の行では変数値の一部として空白を指定しています。

<SETVAR NAME="foo" VALUE="foo%20bar"/>

表16-12では、WebCenter Sitesでよく使用される特殊文字の16進値を示しています。

表16-12 特殊文字の値

16進値

文字

%22

二重引用符(")

%20

単一の空白

%3c

小なり記号(<)

%3e

大なり記号(>)

%26

アンパサンド(&)

%09

タブ(\t)

%0a

改行(\n)

%0d

改行(\r)

%25

パーセント(%)

17 セッションおよびCookieについて

セッションには訪問者に関する情報が格納されます。Cookieには、セッションを継続している訪問者に関する情報が格納されます。

セッションおよびCookieの管理の詳細は、次の項を参照してください。

- セッションについて

- セッションのライフタイム

- セッションの例

- Cookieについて

- Cookieの例

- ヒントとコツ

- Satellite Serverのセッション・トラッキング

17.1 セッションについて

mainおよびwaterという2つのページが含まれているWebサイトを考えてみましょう。訪問者は最初にmainを見た後でwaterに移動するとします。HTTPはステートレスなプロトコルです。そのため、標準的なWebサーバーでこのサイトを管理している場合、mainで収集されたナレッジは訪問者がwaterに移動したときに失われてしまいます。つまり、waterでは、訪問者がmainで提供できた可能性のある情報を利用できないことになります。

この制約を回避するために、アプリケーション・サーバーは訪問者が最初にWebサイトに入った時点を検出します。その時点で、アプリケーション・サーバーは訪問者に対してセッションを開始します。前述の例では、訪問者がmainページをリクエストした時点でアプリケーション・サーバーはセッションを開始しています。Webサイト・デザイナはmainを使用して訪問者に関する情報を収集し、その情報をセッション変数に格納できます。セッション変数に格納された情報は、すべての後続ページで利用できます。したがって、たとえばBobが自分の年齢をmainに指定して、mainのデザイナがその年齢をセッション変数に書き込んだ場合、waterではBobの年齢に簡単にアクセスできます。

セッション変数に格納された値は、そのセッションが継続する間は使用できます。セッションが終了すると、アプリケーション・サーバーはそのセッションに関連付けられたセッション変数を破棄します。各セッション変数はアプリケーション・サーバー上でメモリーを消費するため、不必要なセッション変数の作成はパフォーマンスの低下につながります。

WebCenter Sitesでは一部のセッション変数が自動作成されますが、Webサイト開発者はオプションとしてその他のセッション変数を作成できます。アプリケーション・サーバーは、セッションをクラスタ上で保持できます。

17.2 セッションのライフタイム

セッションは、訪問者が初めてWebサイトを訪れたときに始まります。セッションは、次のいずれかが生じたときに終了します。

- 訪問者がブラウザを終了します。

- セッションがタイムアウトしました。WebCenter Sitesは、cs.timeoutプロパティを使用してセッション・タイムアウト値をアプリケーション・サーバーに設定します。このプロパティを300に設定した場合、ユーザー・セッションは300秒、すなわち5分で無効になります。

- システム管理者がアプリケーション・サーバーを停止します。

この項には次のトピックが含まれます:

- WebCenter Sitesによって保持されるセッション変数

- ログインとログアウト

17.2.1 WebCenter Sitesによって保持されるセッション変数

セッションが作成されると、WebCenter Sitesは、表17-1で説明されているセッション変数を自動的に作成します。

表17-1 セッション変数

セッション変数

保持される内容

SessionVariables.currentUser

ログインした訪問者のid。

SessionVariables.currentAcl

この訪問者が属するすべてのACLのカンマ区切りリスト。訪問者が明示的にログインしていない場合、デフォルトACLはBrowserです。

SessionVariables.username

訪問者のログイン時のユーザー名。訪問者が明示的にログインしていない場合、デフォルトのユーザー名はDefaultReaderです。

SessionVariables.iniFile

WebCenter Sitesのプロパティが含まれているファイルの名前。

17.2.2 ログインとログアウト

訪問者が初めてサイトを訪れると、WebCenter Sitesでセッションが作成され、訪問者はDefaultReaderとして暗黙的にログインされます。セッション中に訪問者が明示的にログインした場合、WebCenter SitesはSessionVariables.currentUser, SessionVariables.currentAclおよびSessionVariables.usernameの値を自動的に更新します。ログインによって、その他のセッション変数の値が影響を受けることはありません。つまり、ログイン前にページでセッション変数が作成された場合、その値はログイン後も有効です。訪問者が明示的にログアウトすると、WebCenter Sitesで生成されたセッション変数はログイン前に保持されていた値に自動的に戻ります。たとえば、次の順序を考えてみましょう。

1. 訪問者が初めてページにアクセスした場合、SessionVariables.usernameの値はDefaultReaderです。

2. 訪問者がmarilynとしてログインすると、SessionVariables.usernameの値はmarilynになります。

3. marilynがログアウトすると、SessionVariables.usernameの値はDefaultReaderに戻ります。

ログアウトをトリガーするには、<CATALOGMANAGER>タグをftcmd=logout修飾子と同時に呼び出します。このタグを発行すると、オプションとして、現在のセッションを破棄するkillsession修飾子を指定できます。さらに、<CATALOGMANAGER>タグをftcmd=login修飾子と同時に呼び出すことによって、セッションを新規作成できます。

17.3 セッションの例

次に、3つの非常に短いエレメントで構成される簡単なセッションの例を示します。

表17-2 セッションの例

エレメント

動作

FeelingsForm

訪問者に現在の気分を指定するように依頼します。

SetFeelings

現在の気分をセッション変数に割り当てます。

Meat

セッション変数を評価します。

この項には次のトピックが含まれます:

- FeelingsFormエレメント

- SetFeelingエレメント

- Meatエレメント

17.3.1 FeelingsFormエレメント

フィーリング・フォームは実際にはセッションまたは変数を含んでいません。このエレメントは、単にフォームを生成するのみです。訪問者の選択した気分は、次のようにSetFeelingエレメントに渡されます。

<form action="ContentServer" method="post">
<input type="hidden" name="pagename"
value="CSGuide/Sessions/SetFeelings"/>

<P>How are you feeling right now?</P>
<P>
<select name="Feeling" size="1">
<option>Good</option>
<option>Not so Good</option>
</select>
</P>

<P><input type="submit" name="doit" value="Submit"/></P>
</form>

この結果、図17-1のようなページが生成されます。

図17-1 サンプル・ページ

17.3.2 SetFeelingエレメント

「送信」ボタンをクリックすると、訪問者はSetFeelingに転送されます。このエレメントにより、訪問者の気分はCurrentFeelingという新規のセッション変数に割り当てられます。

<SETSSVAR NAME="CurrentFeeling" VALUE="Variables.Feeling"/>

<P>Welcome to our site.</P>

<P>Now proceed to
<A href="ContentServer?pagename=CSGuide/Sessions/Meat">
some meaty content.
</A></P>

この結果、次のようなページが生成されます。

Welcome to our site.
Now proceed to some meaty content.

このアプリケーションのエレメントが訪問者にログインするよう要求した場合、WebCenter Sitesはusernameセッション変数を自動的に訪問者のログイン名に設定します。その場合は、ようこそメッセージをSetFeelingで次のようにパーソナライズすることもできます。

<P>Welcome to our site, <CSVAR NAME="SessionVariables.username"/>
</P>

17.3.3 Meatエレメント

「some meaty content」をクリックすると、訪問者はMeatページに転送されます。このページでは、セッション変数が評価されます。

<IF COND="SessionVariables.CurrentFeeling=Good">
<THEN>
<P>Sessions are happiness.</P>
</THEN>
<ELSE>
<P>Don't let sessions get you down.</P>
</ELSE>
</IF>

気分のすぐれない訪問者には、次のメッセージが表示されます。

Don't let sessions get you down.

CurrentFeelingがMeatに対してどのように使用可能になったかに注目してください。実際に、CurrentFeelingはセッション内のその他すべてのエレメントでも使用可能です。

17.4 Cookieについて

Cookieは、アプリケーションが訪問者のブラウザに書き込む文字列です。Cookieには、セッションを継続している訪問者に関する情報が格納されます。訪問者のブラウザは、この文字列を訪問者のディスク上の特別なCookieに書き込みます。訪問者がWebサイトに戻ったときに、訪問者のブラウザはCookieを設定したWebサーバーにCookieのコピーを返送します。Cookieは、作成されるとただちに、ページ上のエレメントの変数として使用可能になります。

たとえば、アプリケーションで訪問者のお気に入りのスポーツ・チームがCookieに格納されているとします。その場合は、訪問者が戻ったときにアプリケーションはCookieを取得し、その情報を使用してチーム・ロゴをバナーに表示することもできます。Cookieが不要に成った場合は、削除できます。

この項には次のトピックが含まれます:

- CookieServer

- Cookieのタグ

17.4.1 CookieServer

CookieServerは、ユーザーにかわってCookieを設定するサーブレットです。CookieServerにアクセスするには、satellite.cookieタグを使用してCookieを作成します。

17.4.2 Cookieのタグ

WebCenter Sitesには、Cookieの管理用に次の2つのタグがあります。

表17-3 Cookieのタグ

タグ

使用法

satellite.cookie

クライアントのブラウザにCookieを設定します。

REMOVECOOKIE

クライアントのブラウザからCookieを削除します。

Cookieの値を取得する特殊なタグはありません。かわりに、訪問者がWebサイトに戻ると、WebCenter SitesはCookieの値を標準変数としてロードします。

(satellite.cookieを呼び出すことにより)Cookieを作成するときに、次の属性を指定できます。

表17-4 Cookieの属性

属性

値

name

Cookieの名前。これは、Cookieの値が含まれている受信変数の名前としても機能します。

注意: WebCenter Sitesのページ・コンテキストのCookieは、変数として扱われます。したがって、Cookieとアセット属性の名前が同じであれば、同じ変数として扱われます。

expiration

Cookieが今後Webサーバーに送信されなくなるまでの時間(秒)。

security

オプションとして、Cookieにセキュリティを設定します。

URL

CookieがこのURLのみで送信されるように制限します。

Domain

Cookieが指定されたドメインのURLのみに送信されるように制限します。

一部の訪問者は、Cookieはセキュリティ上の脅威と感じて、Cookieを拒否するようにブラウザを構成することがあります。Cookieの情報が重要である場合に備えて、アプリケーションを構成する必要があります。

任意のタグを使用してコンテンツを訪問者のブラウザに戻す前に、Cookieの設定または削除を行う必要があります。<HTML>タグを使用する前であっても、Cookieの設定または削除が必要です。

17.5 Cookieの例

この例は、非常に短い複数のエレメントで構成されています。

表17-5 Cookieのエレメント

エレメント

動作

Start

Cookieが設定されているかどうかを判別します。Cookieが設定されている場合は、DisplayWelcomeを呼び出します。Cookieが設定されていない場合は、GetColorPreferenceを呼び出します。

ColorForm

訪問者にお気に入りの色を選択するように要求するフォームを表示します。

CreateCookie

この訪問者のブラウザにCookieを作成します。その後で、訪問者をDisplayWelcomeにリダイレクトします。

DisplayWelcome

簡単なようこそメッセージを訪問者のお気に入りの色で表示します。

この項には次のトピックが含まれます:

- Start.xml

- ColorForm

- CreateCookie

- DisplayWelcome

- Cookie例の実行

17.5.1 Start.xml

Start.xmlエレメントは、Cookieが設定されているかどうかを判別します。Cookieが設定されている場合、WebCenter Sitesはその値をVariables.ColorCookieという標準変数に格納します。Start.xmlのコードは次のようになります。

<IF COND="IsVariable.ColorCookie=true">
<THEN>
<CALLELEMENT NAME="CSGuide/Sessions/DisplayWelcome"/>
</THEN>
<ELSE>
<CALLELEMENT NAME="CSGuide/Sessions/ColorForm"/>
</ELSE>
</IF>

17.5.2 ColorForm

ColorForm.xmlエレメントは、訪問者のお気に入りの色を収集するHTMLフォームを表示します。ColorForm.xmlのコードは次のようになります。

<form action="ContentServer" method="post">
<input type="hidden" name="pagename" value="CSGuide/Sessions/CreateCookie"/>

<P>What is your favorite color?</P>
<P>
<select name="FavoriteColor" size="1">
<option>Red</option>
<option>Green</option>
<option>Blue</option>
</select>
</P>

<P><input type="submit" name="doit" value="Submit"/></P>
</form>

17.5.3 CreateCookie

CreateCookie.xmlエレメントは、ColorCookieというCookieを訪問者のブラウザに送信します。訪問者がCookieを無効化した場合、ブラウザはCookieを設定するようにというリクエストを無視します。訪問者がCookieを有効化した場合(デフォルト)、ブラウザはCookieをこのシステムのCookieファイルに書き込みます。

次に、CreateCookie.xmlのコードを示します。

<satellite.cookie NAME="ColorCookie" VALUE="Variables.FavoriteColor"
TIMEOUT="31536000" SECURE="false"/>

<CALLELEMENT NAME="CSGuide/Sessions/DisplayWelcome"/>

このコードでは、Cookieの値が訪問者のお気に入りの色に設定されます。このCookieは1年間(31,536,000秒)継続します。

17.5.4 DisplayWelcome

DisplayWelcomeが呼び出されるときまでに、Cookieが設定されます。次のコードでは、ようこそメッセージを訪問者のお気に入りの色で表示するためにCookieの値が使用されます。

<H1><font color="Variables.ColorCookie"
REPLACEALL="Variables.ColorCookie">
Displaying a Friendly Welcome.
</font></H1>

17.5.5 Cookie例の実行

Cookie例を実行するには、ブラウザを使用してCSGuide/Sessions/Startのページ名に移動します。

この例を初めて実行すると、4つのエレメントがすべて実行されます。2回目以降は、StartとDisplayWelcomeのみが実行されます。

17.6 ヒントとコツ

次の提案が役に立つ場合があります。

- クラスタでは、セッション状態をクラスタ・メンバー全員にレプリケートする必要があります。クラスタでは、セッション・サイズを最小限に抑え、1クライアントにつき2キロバイトを超えるセッションを格納しないようにしてください。

- 妥当なセッション・タイムアウト値を決定します。設定するタイムアウト値が大きすぎると、システム・リソースが拘束されてしまいます。タイムアウト値が小さすぎると、訪問者は何回もログインしなければなりません。

17.7 Satellite Serverのセッション・トラッキング

パーソナライズしたコンテンツを訪問者に提供するWebサイトでは、セッションの追跡が必要です。WebCenter SitesとSatellite Serverはいずれもセッションを追跡します。双方で訪問者のブラウザにCookieが設定されるため、(1つではなく)2つのCookieがそれぞれ独立してセッションを追跡します。Satellite Serverが停止しても、WebCenter Sitesセッションは保持されるため、この冗長性はSatellite Serverが停止した場合に役立ちます。

Satellite Serverはセッション固有のページレットを最初の依頼者に返送するだけですが、ユーザーのログアウトに関するセッション固有の情報を明示的にフラッシュすることで、Satellite Serverキャッシュの領域が確保されます。

次の各セクションでは、Satellite Serverからセッション情報をフラッシュする方法について説明します。

この項には次のトピックが含まれます:

- URLを使用したセッションのフラッシュ

- 現行セッション情報のフラッシュ

- その他のセッション情報のフラッシュ

17.7.1 URLを使用したセッションのフラッシュ

特定のセッションに関連するすべてのデータをフラッシュできます。これは、フォームを次のフォーマットでURLにポストすることで、WebCenter Sitesから実行します。

https://host:port/servlet/FlushServer?reset=true&username=username&password=password&ssid=sessionID

ここで:

表17-6 セッション・パラメータ

パラメータ

値

host

キャッシュがフラッシュの対象となるSatellite Serverホストの名前を指定します。

port

Resinを別のポートで実行するように再構成した場合を除き、80(デフォルト)を指定します。

username

ユーザー名プロパティに割り当てられた値を指定します。

password

パスワード・プロパティに割り当てられた値を使用します。

sessionID

削除対象のセッションを表すセッションID (Satellite Serverではなく、WebCenter Sitesにより保持されているもの)を指定します。

17.7.2 現行セッション情報のフラッシュ

現在使用しているSatellite Serverセッションの情報をフラッシュするには、現行セッションIDを持つFlushServer URLを使用します。現行セッションID (ssid)は、アプリケーション・サーバーに依存する名前を持ったセッション変数に格納されます。この名前を確認するには、セッション変数HTTP_COOKIEを参照します。

- 次のJavaコードは、現行セッションの情報のフラッシュに使用します。

String value;
String name = "WebLogicSession";
value = ics.GetVar(name);

String sFlushSessionUrl ="http://mysatellite:80/servlet/
FlushServer?username=ftuser&password=ftuser&
reset=true&ssid=" + value;"

String sSatTest1Results = Utilities.readURL(sFlushSessionUrl);

17.7.3 その他のセッション情報のフラッシュ

現在使用しているセッション以外のセッションから情報をフラッシュするには、次の手順に従います。

1. フラッシュするページレットが含まれているコンテナ・ページに次のタグを追加します。

<satellite.page
pagename="QA/Satellite/Functional/xml/pagelet4"
cachecontrol="session:0:00:00 */*/*"/>

"session:0:00:00 */*/*"のcachecontrol値は、このページをリクエストするセッションごとに、そのセッションによる後続リクエストのみで表示可能なページレットが作成されることを示します。指定されたページのセッションが失効すると、そのページは二度と表示できなくなります。コンテナ・ページは、毎日の真夜中にキャッシュから失効します。

2. コンテナ・ページに対してcachecontrolパラメータを設定した後で、キー・パラメータを持つInventoryサーブレットを使用してセッションID (ssid)を取得します。ssidは、プロトコルとサーバー名の前の文字列です。たとえば、Inventoryサーブレットが次のように表示されたとします。

OuCOTrh9yporWfgu8Uthttp://myserver:80/servlet/
ContentServer?pagename=QA/Satellite/Functional/xml/pagelet4

この場合、ssidはOuCOTrh9yporWfgu8Uになります。

3. セッションから情報をフラッシュするには、FlushServer URLにあるssidを使用します。例:

http://myserver:80/servlet/
FlushServer?username=ftuser&password=ftuser&reset=true&
ssid=OuCOTrh9yporWfgu8U

注意:

現在使用しているセッション以外のセッションから情報をフラッシュするには、セッション・アフィニティを有効にしておくことをお薦めします。

18 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成

この章では、CSElementアセット・タイプ、テンプレート・アセット・タイプおよびSiteEntryアセット・タイプと、それらの作成方法について説明します。

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

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットについて

- ページ、ページレットおよびエレメントの使用

- CSElementアセット、テンプレート・アセットおよびSiteEntryアセットの使用

- テンプレート・アセットの作成

- CSElementアセットの作成

- SiteEntryアセットの作成

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの管理

- Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集

テンプレートおよびCSElementのコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

注意:
Visitor Servicesで使用するテンプレートを作成する場合、Visitor Service Helperクラスを使用して、現在の訪問者のプロファイル情報を取得し、訪問者のCookieライフ・サイクルを管理できます。詳細は、「訪問者プロファイルのリンク付けおよびCookieの管理」を参照してください。
WebCenter Sitesでは、Visitor Servicesアプリケーションが正しく構成および実行されている場合にのみ、テンプレート開発者が(VisitorsクライアントAPIまたはWebCenter SitesラッパーAPI (クラス VisitorServiceHelper.java)を使用して)、テンプレート・コードがVisitor Servicesをヒットするようにする必要があり、そうしないと、Content Serverエラーが発生する可能性があります。

18.1 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットについて

アセット・タイプにより、オンライン・サイトを構築するページレットとエレメントが提供されます。これらは、ページ名とエレメントおよび、WebCenter Sitesでページの生成に使用するコンポーネントを表現するアセットです。CSElementアセットの作成時には、エレメントをコーディングします。SiteEntryアセットの作成時には、ページに名前を付けます。テンプレートの作成時には、エレメントのコーディングとページの名前付けの両方を行います。

- テンプレート・アセットは、1つのアセット・タイプに適用されるのか、どのアセット・タイプにも適用されないのかに応じて、タイプ付きまたはタイプなしに分類されます。

- SiteLauncherを使用している場合(サイトのレプリケートまたはテンプレート・アセットとCSElementアセットの共有を目的として)、WebCenter Sitesは、アセット、アセット・タイプ、属性名およびテンプレート名を間接的に参照するために、エレメント・ロジックが必要になります。そのため、WebCenter Sitesインタフェースには、「マップ」画面(たとえば、「マップの構成」)が導入されていて、APIにはrender:lookupタグが導入されています。
「マップ」画面を使用して、各値に別名を割り当てます。別名をエレメント・ロジックでハードコード化し、render:lookupタグを使用して、実行時に別名から実際値を取得できます。

- 「キャッシュ規則」フィールドは、エラーを減らすために簡略化されています。テンプレートの開発者は、キャッシュ、未キャッシュ、または詳細を選択できます。「詳細」を選択すると、開発者は、WebCenter SitesとSatellite Serverに対して個別にキャッシュ規則を設定できるようになります。

- テンプレートの作成プロセスを簡略化した方法でテンプレートを起動するために、calltemplateタグが新規に導入されました。

- ページ基準フィールドは、「キャッシュ基準」と名前変更されました。これは予約パラメータc、cid、context、p、rendermode、site、sitepfx、ft_ssと、カスタム定義済パラメータを受け入れます。
キャッシュ基準の値は、SiteCatalog表のpagecriteria列に格納されます(旧バージョンでは、SiteCatalog表のresargs列に格納されていました)。

「キャッシュ基準」フィールドは、CKEditorの「その他のパラメータ」セクションを有効化する変数の保持にも使用され、その変数をユーザーがアセット・リンクを含めるダイアログ・ボックスと「アセット・リンクの追加」ダイアログ・ボックスで使用できるようにします。「その他のパラメータ」セクションには、カスタム・パラメータ(イメージ・ディメンションなど)をテンプレートに渡す方法が用意されています。その他のパラメータについては、「SiteEntryの構成」の手順2を参照してください。詳細は、『WebCenter Sitesの使用』を参照してください。

- テンプレート・アセットとCSElementアセットの作成フォームはタブによって細分化されています。フィールドはタブ上で機能別に編成されています。

18.2 ページ、ページレットおよびエレメントの使用

WebCenter Sitesのコンテキストでは、オンライン・ページは複数のコンポーネントを表示可能な最終出力に構成したものです。この出力を作成することをレンダリングといいます。(出力またはレンダリングされるコンテンツをパブリック・サイトの訪問者が利用できるようにすることを、パブリッシュといいます。)

WebCenter Sitesでは、ページは、ページ名に関連付けられたコードを実行してレンダリングされます。ページの名前はブラウザからWebCenter Sitesに渡され、WebCenter Sitesはそのページ名に関連付けられたコードを起動します。コードは実際には名前付きファイルであり、エレメントと呼ばれるコードの個々のチャンクです。

エレメント内のコードはアセットを識別して、ページまたはページレットに表示するためにそのアセットをロードし、その他のページ名とエレメント名をWebCenter Sitesに渡します。WebCenter Sitesがエレメントを呼び出すと、そのエレメント内のすべてのコードが実行されます。他のエレメントへのコールがある場合は、次にそのエレメントが呼び出されます。さらに、結果(イメージ、記事、リンクセットなど、すべてのHTMLタグを含む)がHTMLコード(または、システムの構成によっては、他の出力フォーマット)にレンダリングされます。

Template、CSElementおよびSiteEntryの各アセットは、次のようにエレメントとページレットを表現します。

- CSElementアセットはエレメントです。

- SiteEntryアセットはページまたはページレットの名前です。

- テンプレート・アセットは、エレメントおよび、アセットをレンダリングするページまたはページレットの両方になります。

この項には次のトピックが含まれます:

- エレメント、ページレットおよびキャッシュ

- ページとエレメントのコール

- ページとページレットの比較

18.2.1 エレメント、ページレットおよびキャッシュ

ページとページレットはキャッシュ可能です。これらには、キャッシュ済であるかどうか、またキャッシュ済の場合はその期間を判別するキャッシュ基準が設定されています。

エレメントには、キャッシュ基準は設定されていません。ページ名を経由することなく、コードからエレメントを名前で直接コールすると、その出力はエレメントの名前をコールしたページに表示され、そのページの一部としてキャッシュされます。

エレメントからの出力を、それをコールしたページからの出力とは別にキャッシュするには、その出力にページ名を指定し、出力をコールするときにはそのページ名を使用する必要があります。テンプレート・アセットのコードには、デフォルトによりページ名が割り当てられています。CSElementアセットに対してページ名を指定するには、SiteEntryアセットを作成し、それに対するCSElementアセットを選択します。

18.2.2 ページとエレメントのコール

WebCenter Sitesページを表示するには、そのページの名前が含まれているURLを指定します。WebCenter SitesのURLは次のようになります。

WebLogicおよびWebSphereの場合:

http://host:port/servlet_context_path/ContentServer?pagename=name_of_page

ここで:

- hostは、WebCenter Sitesシステムをホストするサーバーの名前です

- portは、Webサーバーのポート番号です。

- servlet_context_pathは、アプリケーション・サーバーからWebCenter SitesのWebアプリケーションに渡されるパスです

- name_of_pageは、ページ名です。

この構文によって、ページの名前がContentServerサーブレットに渡され、そこでページがレンダリングされます。

たとえば、サイトのホーム・ページを表示するには、次のようにURLを入力します。

http://site-address/servlet/ContentServer?pagename=
site-name/Page/Home

エレメントをコーディングするときには、サイトに表示するページレットとエレメントをプログラムでコールするタグを使用します。これらのタグは、ちょうどブラウザで入力したURLがページ名をContentServerサーブレットに渡すように、ページとエレメントの名前をContentServerサーブレットに渡します。

ページ名をコールするには、render:satellitepage (RENDER.SATELLITEPAGE)タグを使用します。例:

<render:satellitepage pagename="site-name/Page/Home" />

エレメントを名前で直接コールするには、render:callelement (RENDER.CALLELEMENT)タグを使用します。例:

<render:callelement elementname="site-name/Common/TextOnlyLink" />

テンプレートを名前でコールするには、render:calltemplateタグを使用します。例:

<render:calltemplate
site='<%=ics.GetVar("site")%>'
slotname="Head"
tid='<%=ics.GetVar("tid")%>'
c='<%=ics.GetVar("c")%>'
cid='<%=ics.GetVar("cid")%>'
tname='<%=ics.GetVar("HeadVar")%>'>
<render:argument name="p" value='<%=ics.GetVar("p")%>' />
</render:calltemplate>

注意:

Oracle WebCenter Sites Explorerを使用してSiteCatalogエントリとElementCatalogエントリを調査する場合、これらのエントリは、ページとページレットを視覚的に編成したフォルダおよびサブフォルダとして表示されます。

ただし、これらのエントリはデータベース表内の行にすぎません(実際の階層は存在しません)。そのため、コードでページ・エントリまたはエレメント・エントリをコールする場合は、常にフルネームを使用する必要があります。相対パスは使用できません。

テンプレート、CSElementおよびSiteEntryの各アセットは次のようにコールできます。

- SiteEntryはページレットであるため、render:satellitepageタグを使用して、エレメント・コードの中からSiteEntryアセットをコールします。

- CSElementはエレメントであるため、render:callelementタグを使用して、エレメント・コードの中からCSElementアセットをコールします。

- テンプレートはエレメント名とページ名の両方であるため、前述のいずれかを使用できますが、通常、render:calltemplateタグはテンプレートに使用することを目的としています。これは、render:satellitepageおよびrender:callelementの機能のみでなく、パラメータの検証など、その他の機能もカプセル化します。

18.2.3 ページとページレットの比較

表18-1に、ページという語を含む様々な用語を示し、WebCenter Sites、WebCenter Sitesの各モジュール、およびその他の製品向け各種ドキュメントでの使用を踏まえて、それらの用語を定義します。

表18-1 ページとページレットの比較

用語

定義

ページレット

レンダリングされたページの一部としてブラウザに表示されるHTTPリクエストの結果。これには、エレメント・ファイルが関連付けられています。

ページレットは、WebCenter SitesおよびSatellite Serverのページ・キャッシュにキャッシュできます。

ページ

ブラウザ・ウィンドウに表示されるHTTPリクエストの結果。ページは、ページ(ページレット)の複数の部分を1つの表示済またはレンダリング済の最終ページにコンパイルすることによって作成されます。これには、エレメント・ファイルが関連付けられています。

ページは、WebCenter SitesおよびSatellite Serverのページ・キャッシュにキャッシュできます。

ページ名

ページまたはページレットの完全な名前。例: 開発者のサンプル/ホーム/レンダリングAPI/アセット・リーダー。

ページ・アセット

ページ・アセットはページ名を表現しません。これは、コンテンツ用の論理コンテナを表現します。このコンテナをツリー構造に配置して、サイト・コンテンツのナビゲーションに対応できます。

ページ・アセットを作成し、それをサイト・ナビゲーション・ツリーに配置します(このツリーは、WebCenter Sitesインタフェースの左ペインの「サイト」タブにツリー構造で表示されます)。その他のコンテンツとサイト・デザイン・アセットをページ・アセットに関連付けた後で、パブリッシュします。

18.3 CSElementアセット、テンプレート・アセットおよびSiteEntryアセットの使用

前述したように、CSElementアセットはエレメント、SiteEntryアセットはページ名、そしてテンプレート・アセットはその両方を含みます。

ページ名とエレメントはアセットであるため、作成したコードとページ名をコンテンツの管理方法と同様に管理できます。つまり、ワークフロー、リビジョン追跡、承認およびプレビューが使用できるだけでなく、サーバーへのミラーリングのパブリッシュ方法を使用してコードとページ名を管理システムや配信システムに移動することもできます。

注意:

リビジョン追跡: SiteCatalog表またはElementCatalog表でリビジョン追跡を直接有効にするために、Oracle WebCenter Sites Explorerツールのリビジョン追跡機能を絶対に使用しないでください。

サーバーへのミラーリング: テンプレートまたはCSElementが、テンプレート・アセットまたはCSElementアセットに関連付けられていないエレメントを参照する場合、これに該当するエレメントが自動的にパブリッシュの宛先にミラーリングされることはありません。CatalogMoverユーティリティを使用して、これらのエレメントを手動で移動する必要があります。そのため、CSElementによって折り返されないエレメントの使用はお薦めできません。

CSElementアセットまたはテンプレート・アセットを作成するときには、エレメントを作成します。エレメントは、アセット・フォーム(作成中のアセットのタイプに応じて、「テンプレート」または「CSElement」)を使用することでコーディングできます。

注意:

テンプレート・アセットとCSElementのエレメントは、Oracle WebCenter Sites Explorerでコーディングできます。ただし、ほとんどが構成上の依存性とキャッシュへのアップデートを扱うため、この方法はお薦めできません。Oracle WebCenter Sites Explorerを優先的に使用する開発者は、テンプレート・アセットまたはCSElementアセットの有効性を確保するために、「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」に記載する手順に従う必要があります。

この項には次のトピックが含まれます:

- テンプレート・アセット

- CSElementアセット

- SiteEntryアセット

- 非アセット・エレメント

18.3.1 テンプレート・アセット

テンプレートは、他のアセットをページおよびページレットにレンダリングします。これにより、オンライン・サイトのルック・アンド・フィールが作成されます。同一タイプのアセットがすべて同じ方法で書式設定されるように、テンプレートの標準セット(CSElementアセットおよびSiteEntryアセットを除く)をアセット・タイプ別に作成します。

このプロセスにより、コンテンツ・プロバイダは、自身でコーディングすることを必要としたり、標準の承認済コードを変更できるようにするのではなく、コンテンツの書式設定コードを選択することによってコンテンツのプレビューを実行できます。

テンプレート・アセットを保存すると、 WebCenter Sitesは次の操作を行います。

- アセットの行をTemplate表に作成します。

- エレメント・エントリをElementCatalog表に作成します。エントリの名前には、次の規則が適用されます。

AssetTypeName/TemplateName

ここで:

- AssetTypeNameは、テンプレート・アセットとエレメントによって書式設定されたアセット・タイプです。

- TemplateNameは、テンプレートの名前です。

- SiteCatalog表にページ・エントリを作成します。ページ・エントリの名前には、次の規則が適用されます。

SiteName/AssetTypeName/TemplateName

ここで:

- SiteNameは、テンプレートが属するサイトの名前です。このサイトは、テンプレートの作成時に使用していたサイトです。WebCenter Sitesは、この名前をPublication表から取得します。(この製品の旧バージョンでは、サイトはパブリケーションと呼ばれていました。)

- AssetTypeNameは、テンプレート・アセットとエレメントによって書式設定されたアセット・タイプです。

- TemplateNameは、テンプレートの名前です。

注意:

WebCenter Sitesで作成されたページ・エントリの名前を変更しないでください。

- テンプレート・アセットの操作をサポートするその他の表に行を新規作成します。この表の名前はTemplate_で始まります。

- テンプレートをサイトに関連付けるために新しい行をAssetPublication表に作成します。

18.3.2 CSElementアセット

CSElementアセットの用途は次のとおりです。

- アセットをレンダリングするためのコードではなく、複数か所以上で再使用したり、複数のタイプのテンプレートからコールするコード。たとえば、同じトップ・バナーを使用するテンプレートが6つあり、バナーのコード用にCSElementアセットを作成して、各テンプレートからエレメントをコールする必要があるとします。この場合、バナーの動作方法を変更するときに、1か所で変更するだけで済みます。

- Oracle WebCenter Sites: Engageに対する推奨。動的リスト推奨を作成する場合、動的リストを作成するためにCSElementアセットを作成する必要があります。詳細は、「推奨アセットの理解」を参照してください。これらのアセットは、コンテンツをレンダリングしませんが、ロジック処理のために存在します。

CSElementを保存すると、WebCenter Sitesは次の操作を行います。

- アセットの行をCSElement表に作成します。

- エレメントを「CSElement」フォームにコーディングした場合は、ElementCatalog表にエレメント・エントリを作成します。このエントリの名前には、フォームで「ElementCatalogエントリ名」フィールドに入力した名前が使用されます。

- テンプレートをサイトに関連付けるために新しい行をAssetPublication表に作成します。

18.3.3 SiteEntryアセット

SiteEntryアセットの用途は次のとおりです。

- CS-Designerツールを使用している場合は、SiteEntryアセットを使用してコード・スニペットを表現します。このインタフェースでコード・スニペットをページにドラッグ・アンド・ドロップする場合は、render:satellitepageタグを使用してページ・エントリに対するWebCenter Sitesのコールにドロップしていることになります。

- CSElementアセット内でコードがレンダリングされると、そのコードはコールしたページに表示され、(そのページがキャッシュされる場合に)そのページの一部としてキャッシュされます。CSElementからの出力を別個のページレットとしてキャッシュして、それ専用のキャッシュ基準(タイムアウト値、ページ基準値など)を設定するには、コードでページ名を通してそのエレメントを起動する必要があります。その場合は、CSElementアセットを伴うSiteEntryアセットを作成します。

SiteEntryアセットを作成して保存するときに、それにCSElementアセットを関連付けます。このCSElementアセットのエレメントは、SiteEntryのページ・エントリに対するルート・エレメントになります。

SiteEntryアセットを保存すると、WebCenter Sitesは次の操作を行います。

- アセットの行をSiteEntry表に作成します。

- SiteCatalog表にページ・エントリを作成します。ページ・エントリのルート・エレメントは、指定したCSElementアセットからのエレメントです。

- SiteEntryアセットとCSElementアセット間の承認の依存性を追跡します。SiteEntryアセットとそのCSElementアセットは両方とも、SiteEntryアセットがパブリッシュ可能になる前に承認する必要があります。

注意:

構成の依存性も追跡されます。SiteEntryはページ基準と、依存性情報が含まれているデフォルトの引数を定義します。CSElementは、CSElementコード・スタブに追加されるrender:logdepタグを使用して、SiteEntryアセットとCSElementアセットのIDをレンダリング・エンジンに記録します。

18.3.4 非アセット・エレメント

管理システム上でWebCenter Sitesインタフェースに対してカスタマイズをコーディングする場合は、そのカスタマイズを配信システムにパブリッシュする必要がないため、アセットではないエレメントを作成します。

たとえば、アクションまたは条件を実装するワークフロー・エレメントを作成する場合は、それをCSElementアセットとしては作成しません。かわりに、Oracle WebCenter Sites Explorerツールを使用して、エントリをElementCatalog表に手動で作成します。

配信システム上でワークフローまたはその他のカスタム・エレメントを作成する場合は、CatalogMoverユーティリティを使用して、そのエレメントを管理システム上のElementCatalogにコピーする必要があります。

注意:

ミラー・エンジンを起動するコードを作成して、エレメントをミラーリングできます。このトピックは高度であり、このガイドの適用範囲を超えています。サポートが必要な場合は、Oracleサポート(www.oracle.com/support)に問い合せるか、www.oracle.com/accessibilityにアクセスしてください。

18.4 テンプレート・アセットの作成

テンプレートはアセットをレンダリングします。テンプレート・アセットを作成する場合は、タイプ付きテンプレートまたはタイプなしテンプレートのいずれかとして作成します。

- タイプ付きテンプレートでは、特定のタイプのアセットをレンダリングします。

- タイプなしテンプレートでは、適用されるアセットのタイプを問いません。タイプなしテンプレートは一般に、ページのレイアウトを指定するために使用します。その後、ページではアセットをタイプ付きテンプレートによってレンダリングできます。

注意:

テンプレートをタイプ付きまたはタイプなしに設定する唯一のフィールドは、「対象アセット・タイプ」フィールドです。テンプレートをタイプ付きまたはタイプなしに区別する目的は、開発者がページの構成を管理し、ページ・レイアウトに対応するテンプレートとアセット・レンダリングに対応するテンプレートを追跡しやすいようにするためです。

テンプレート・アセットを作成する前に、「テンプレート・アセットの作成を開始する前に」を完了して、テンプレート・プロパティ(テンプレート名など)の設定方法とテンプレートのエレメント・ロジックのコーディング方法を決定します。次に、「テンプレート・アセットの作成」に進み、Adminインタフェースを使用して次の手順を完了します。

- 「テンプレート」フォームを開く

- テンプレート・アセットの名前付けと記述

- テンプレートのエレメントの構成
(使用方法、ファイル・タイプ、およびロジックを指定する場合。)

- SiteEntryの構成
(ページおよびページレットのキャッシュ・パラメータを指定する場合。)

- マップの構成
(テンプレート共有とサイト・レプリケーションをサポートする場合。)

- (オプション)サムネイルの作成
(テンプレートの「調査」フォームにテンプレートをグラフィックで表示する場合。)

- テンプレートの調査

「テンプレート」フォームに入力する情報は、テンプレートの保存時にデータベース表に書き込まれます。

注意:

テンプレート・アセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。かわりに、「テンプレート」フォームと、この項に示した手順を使用してテンプレート・アセットを作成します。テンプレートのエレメント・ロジック(タイプ付きテンプレートの場合)のコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

この項には次のトピックが含まれます:

- テンプレート・アセットの作成を開始する前に

- テンプレート・アセットの作成

18.4.1 テンプレート・アセットの作成を開始する前に

テンプレート・アセットの作成を開始する前に、次の点を決定してください。

- TemplateName (テンプレート・アセットの名前。「名前」画面の「名前」フィールドの値です。「テンプレート・アセットの名前付けと記述」を参照してください)。

- テンプレート・アセットがタイプ付きまたはタイプなしのいずれであるか。

- テンプレート・アセットを共有するかどうか、また使用中のサイトをレプリケートするかどうか。これらの考慮事項により、テンプレートのエレメント・ロジックのコーディング方法を決定します。

- テンプレートのエレメント・ロジックのコーディングを、「テンプレート」フォームではなくOracle WebCenter Sites Explorerで実行するかどうか。Oracle WebCenter Sites Explorerでのコーディングは慣習化されていますが、「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」で概説している理由によりお薦めできません。

18.4.1.1 テンプレート・アセットの名前付け

- テンプレート・アセットが保存されると、その名前は変更できなくなります。

- WebCenter Sitesにより、テンプレート名はSiteNameに追加されます(タイプ付きテンプレートの場合は、AssetTypeNameにも追加されます)。テンプレート名は、SiteNameおよびAssetTypeNameに関連して意味のあるものにする必要があります。WebCenter Sitesのネーミング規則をオーバーライドしないでください。WebCenter Sitesにより作成された名前は変更しないでください。表18-2に、TemplateNameを使用する規則を示します。
AssetTypeNameはタイプ付きテンプレートにのみ使用し、「名前」画面でのテンプレートの「対象アセット・タイプ」フィールドの値を表します(「テンプレート・アセットの名前付けと記述」を参照)。SiteNameは、テンプレートが属するサイト(テンプレートの作成時に使用しているサイト)の名前です。WebCenter Sitesは、SiteNameをPublication表から取得します。(この製品の旧バージョンでは、サイトはパブリケーションと呼ばれていました。)

表18-2 TemplateNameを使用するネーミング規則

テンプレート

ネーミング規則

説明

タイプ付き

AssetTypeName/TemplateName

タイプ付きテンプレートのルート・エレメントの名前。

この値は、「Rootelement」フィールドに書き込まれます。この値は、変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

注意: ネーミング規則により、ルート・エレメントの名前は一意にする必要があります。複数のテンプレート・アセットが同じルート・エレメントを指さないようにする必要があります。ただし、2つのSiteEntryアセットが同じエレメントを指すように設定できます(たとえば、コール・シナリオに応じて、異なるデフォルト引数または異なるキャッシュ基準を指定したい場合)。

タイプ付き

AssetTypeName/TemplateName.xml_or_jsp_or_html

タイプ付きテンプレートのエレメント・ファイルへのパス。

この値は、ファイル・タイプを選択したときに、「エレメントのストレージ・パス/ファイル名」に書き込まれます。

タイプ付き

SiteName/AssetTypeName/TemplateName

テンプレートがタイプ付きの場合にレンダリングされるページの名前。

この値は、「SiteCatalog Pagename」フィールドに書き込まれます。

タイプなし

/TemplateName

タイプなしテンプレートのルート・エレメントの名前。

この値は、「Rootelement」フィールドに書き込まれます。この値は、変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

注意: このテンプレートは任意のアセット・タイプに適用できるため、AssetTypeNameは省略されています。スラッシュは、テンプレートをタイプなしとして識別するために付けられます。この表の1行目の注意を参照してください。

タイプなし

Typeless/TemplateName.xml_ or_jsp_or_html

タイプなしテンプレートのエレメント・ファイルへのパス。

この値は、ファイル・タイプを選択したときに、「エレメントのストレージ・パス/ファイル名」に書き込まれます。

タイプなし

SiteName/TemplateName

テンプレートがタイプなしの場合にレンダリングされるページの名前。

この値は、「SiteCatalog Pagename」フィールドに書き込まれます。

注意: このテンプレートは任意のアセット・タイプに適用できるため、AssetTypeName/は省略されています。

18.4.1.2 タイプ付きまたはタイプなしとしてのテンプレートの指定

テンプレート・アセットを作成する前に、それをタイプ付きまたはタイプなしのいずれにするかを決定します。テンプレートが保存されると、そのタイプ付きまたはタイプなしのステータスは変更できなくなります。

18.4.1.3 テンプレート共有とサイト・レプリケーション

テンプレートを作成する前に、テンプレートおよび使用中のサイトの使用方法を決定します。この決定によって、テンプレートのエレメント・ロジックをコーディングする方法が決まります(「テンプレートのエレメントの構成」)。

テンプレート・アセットを共有したり、現在のサイトをレプリケート可能にするには、テンプレートのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照していないことを確認してください。かわりに、それらを間接的に参照する必要があります。「マップ」画面(「マップの構成」)を使用して、各値に別名(キー)を割り当ててから、その別名をテンプレート内でハードコード化します。render:lookupタグを使用して、実行時に別名から実際値を取得します。

render:lookupタグは、実行中にマップを参照してキーを検索し、エレメント・ロジックで使用するアセット固有の情報を返します。この動的検索によってテンプレート・アセット(エレメント・ロジックのみではありません)は、安全なレプリケーションとテンプレートの共有を有効にしながら、アセット・データを直接参照できます。

たとえば、テンプレートの名前がFSIILayoutであり、このテンプレートが含まれているサイトにFSIIというサイト接頭辞が割り当てられているとします。新しいサイトの接頭辞がNewになるようにサイトがレプリケートされ、FSIILayoutテンプレートがコピーされると、テンプレートのコピーにはNewLayoutという名前が付けられます。NewLayoutテンプレートをハードコード化された名前(FSIILayout)で参照すると、その参照はテンプレートの実行時に失敗します。かわりに、テンプレート名が検索されます。

<%-- Look up the name of the layout template --%>
<render:lookup
site='<%=ics.GetVar("site")%>'
varname="LayoutVar"
key="Layout"
tid='<%=ics.GetVar("tid")%>'/>

<%-- Look up the name of the wrapper page's site entry.
Note we want the asset name only, so we must specify
the match filter. --%>
<render:lookup
site='<%=ics.GetVar("site")%>'
varname="WrapperVar"
key="Wrapper"
tid='<%=ics.GetVar("tid")%>'
match=":x"/>

エレメント・ロジックをコーディングするには、そのデザインと、参照するマップを明確に理解する必要があります。次の内容を決定する必要があります。

- 作成するキーと各キーに割り当てる名前。

- 検索の対象となるアセット情報のタイプ:

- テンプレート名

- アセット・タイプ

- アセット(タイプ:名前)

- アセット(タイプ:ID)

- 各キーの値。

- マップが適用されるサイト。

render:lookupタグの使用方法に関する追加情報は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

18.4.2 テンプレート・アセットの作成

特定のアセット・タイプまたは任意のアセット・タイプのテンプレート・アセットを作成できます。

注意:

テンプレート・アセットの作成手順を開始する前に、「テンプレート・アセットの作成を開始する前に」を確認してください。

テンプレート・アセットを作成するには、次のタスクを実行する必要があります。

- 「テンプレート」フォームを開く

- テンプレート・アセットの名前付けと記述

- テンプレートのエレメントの構成

- SiteEntryの構成

- マップの構成

- (オプション)サムネイルの作成

- テンプレートの調査

18.4.2.1 「テンプレート」フォームを開く

1. Adminインタフェースを開きます。

2. ボタン・バーで、「新規」をクリックします。

3. アセット・タイプのリストで、「新規テンプレート」を選択します。

注意:

「新規テンプレート」オプションを表示するには、サイトに対してテンプレート・アセット・タイプを有効化し、その「スタート・メニュー」アイテムを作成する必要があります。

4. 図18-1に示すように、「テンプレート」フォームが開きます。「テンプレート・アセットの名前付けと記述」に進みます。

注意:

「テンプレート」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているテンプレート・アセットがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。「テンプレート・アセットの名前付けと記述」に進みます。

図18-1 「新規テンプレート名」フォーム

18.4.2.2 テンプレート・アセットの名前付けと記述

「名前」画面は、タイプ付きまたはタイプなしとしてのテンプレートの識別、カテゴリへのテンプレートの割当て、テンプレートに渡される可能性のある引数の指定、検索ルーチンへのテンプレートの配置に使用できるキーワードの名前付けに使用します。

テンプレート・アセットが保存されると、「名前」画面で指定するフィールド値(適切な引数を除く)が、次の手順に示すように、Template表に書き込まれます。

注意:

テンプレートの作成中はいつでもテンプレートを保存できます。WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。「テンプレート」フォームに戻るには、「編集」リンクをクリックします。

「名前」画面で、次の手順の説明に従ってフィールドに値を入力します。

1. (必須)。「名前」フィールドに、説明的なテンプレートの名前を入力します。この名前は、テンプレートと、そのテンプレートでレンダリングするアセットのタイプに固有なものにします。テンプレートの機能または目的を反映する名前を選択することをお薦めします。
有効なエントリ

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)

注意:

テンプレート・アセットの名前は、「テンプレート・アセットの作成を開始する前に」のガイドラインを使用して決定してください。

2. 「説明」フィールドに、テンプレートの簡単な説明を入力します。最大128文字まで使用できます。

3. 注記が必要なソースからテンプレートを派生している場合は、「ソース」フィールドのドロップダウン・リストからオプションを選択します。

4. テンプレート・アセットを特定のカテゴリに配置する場合は、「カテゴリ」フィールドのドロップダウン・リストからオプションを選択します。

5. (必須)。「対象アセット・タイプ」フィールドで、テンプレートをタイプ付きまたはタイプなしとして特定します。

- タイプなしテンプレートを作成している場合(たとえば、タイプ付きテンプレートにディスパッチする場合)は、「各種アセット・タイプに適用可能」を選択して、手順7に進みます。

- タイプ付きテンプレート(特定のタイプのアセットをレンダリングするもの)を作成している場合は、アセット・タイプを選択します。たとえば、記事アセットをレンダリングするためにテンプレートを作成している場合は、ドロップダウン・リストから「記事」を選択します。

6. (タイプ付きテンプレートに必須)。「サブタイプに適用」フィールドのメニューから、適切なサブタイプを選択します。

注意:

タイプ付きテンプレートは、直前のフィールド(「対象アセット・タイプ」)で選択したアセット・タイプに含まれる特定のサブタイプにのみ使用することをお薦めします。

7. 「適切な引数」フィールドで、次の手順を実行します。

a. テンプレートに渡される可能性のある引数を入力して、「引数の追加」をクリックします。

b. 表示されたフィールドで、次の手順を実行します。

- 引数がオプションか、または必須かを指定します。

- 引数の説明を提供します(作成する引数の目的を把握しやすいようにするため)。

- 引数に対して適切な値(説明を含む)を指定します。

(「引数の追加」ボタンと「適切な値の追加」ボタンをクリックすることで、必要な数の引数と適切な値を指定できます。)

8. 「キーワード」フィールドに、将来このテンプレートを検索するときに「詳細検索」フォームで検索基準として使用できるようにするキーワードを入力します。アセットの検索の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

9. 「続行」をクリックして、「エレメント」画面を開きます。

注意:

テンプレート・アセットを保存するように選択した場合は、WebCenter Sitesによって次の2つのフィールドが追加されます。

- 「ステータス」フィールド: このフィールドには、テンプレート・アセットの編集ステータス(「作成済」、「編集済」など)が事前に移入されています。このフィールドでは、テンプレート・アセットがワークフローに関連付けられているかどうかに関係なく、テンプレート・アセットで最後に実行された操作が特定されます。

- 「ID」フィールド: このフィールドには、WebCenter Sitesが生成する一意の数値が事前に移入されていて、テンプレート・アセットにIDとして割り当てられます。(「ID」フィールドはtid変数に相当します。)

18.4.2.3 テンプレートのエレメントの構成

「エレメント」画面は、テンプレートのエレメントの作成、エレメント・ファイル・タイプ(XML、JSP、またはHTML)の定義、エレメント・ロジックの提供、およびエレメントの名前付けに使用します。例:

- 「テンプレート・エレメントの作成」フィールドには、エレメント・ロジック用に選択可能なファイル・タイプXML、JSP、HTMLが表示され、このフィールドは、「エレメント・ロジック」フィールドに標準スタブ・コード(作成するすべてのエレメントに含める必要がある)をシードする際に使用します。
「テンプレート・エレメントの作成」フィールドを使用して、たとえば.jspファイルを作成すると、WebCenter Sitesは、デフォルトでJSPのtaglib文とRENDER.LOGDEPタグを「エレメント・ロジック」フィールドに追加して、このテンプレート・アセットとこのエレメントからレンダリングされるページ間の構成の依存性のログをWebCenter Sitesで記録できるようにします。その他のファイル・タイプの場合は、WebCenter Sitesによって、それぞれのファイル・タイプに固有のコードが追加されます。独自のコードを「エレメント・ロジック」フィールドに追加します。

依存性の詳細は、「依存性について」を参照してください。エレメント・ロジックのコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- 「エレメントのストレージ・パス/ファイル名」フィールドでは、エレメント・ロジックを保持するファイルの名前を付けて、そのファイルへのパスを指定します。

テンプレート・アセットが保存されると、「エレメント」画面のフィールド値は、ElementCatalog表の(エレメントを表す)行に書き込まれます。

注意:

既存エレメントの選択について

次の手順では、テンプレート・アセットのエレメントを新規作成しているものとします。ただし、旧リリースのWebCenter Sitesからアセットを移行していて、既存エレメントを再使用する場合は、WebCenter Sitesで既存エレメントを検出し、このテンプレート・アセットと関連付けられるようにするために、エレメントを正確に識別する必要があります。

既存のエレメントを選択するには、次を実行します。

1. (オプション)「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。

2. 「エレメントのストレージ・パス/ファイル名」フィールドに、表18-2のネーミング規則に従った値を入力します。

3. 「エレメント・パラメータ」フィールドで、エレメントに渡される可能性のある変数または引数を指定します。詳細は、「テンプレートのエレメントの構成」の手順7を参照してください。

4. テンプレート・アセットを保存し、再度開きます。
WebCenter Sitesは、指定されたエレメントの存在をチェックします。

エレメントに適切な名前が付けられていると、WebCenter Sitesはエレメントを認識して、そのコードを「エレメント・ロジック」フィールドに表示します。

指定されたエレメントが存在しない場合(または、名前が不適切な場合)は、WebCenter Sitesでは何も行われません。テンプレート・アセットを調査または編集するときに、フォームにルート・エレメントがありませんというメッセージがWebCenter Sitesに表示されます。エレメントをコーディングして適切な名前を付けると、WebCenter Sitesでただちに検出され、テンプレートに関連付けられます。

図18-2に示すように、「エレメント」画面で、この手順の説明に従って各フィールドに値を入力します。

図18-2 テンプレート・エレメント・フォーム

1. 「使用」フィールドで、表18-3をガイドラインとして使用して、このテンプレートの用途を指定します。

表18-3 使用オプション

使用オプション

説明

使用は未指定

HTMLを生成するテンプレートを指定します。テンプレートが「本文」テンプレート(この表の2行目を参照)であるか、または「URL」テンプレート(この表の3行目を参照)であるかは不明になります。

エレメントをHTMLページ内で使用

HTMLページの<BODY>...</BODY>タグ内で使用するテンプレートを指定します。このオプションにより、テンプレートは「本文」テンプレートと見なされます。

エレメントをレイアウトとして使用

完全なHTMLページを生成し、Webモードでのアセットのレンダリングに使用される、レイアウト・テンプレートを指定します。

エレメントでHTMLページ全体を定義し、外部でこれをコール可能

完全なHTMLページを生成し、URLで使用可能なテンプレートを指定します。このオプションにより、テンプレートは「URL」テンプレートと見なされます。

エレメントを未加工のデータとしてストリーミング

HTML以外の不明タグの未加工のバイナリ・データを生成するテンプレートを指定します。

2. 「呼び出されたテンプレート」フィールドで、このテンプレートがコールするテンプレートを選択します(存在する場合)。

3. 「テンプレート・エレメントの作成」フィールドで、次のいずれかを実行します。

- .xmlファイルを作成する場合は、「XML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\Template\modelXML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .jspファイルを作成する場合は、「JSP」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\Template\modelJSP.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .htmlファイルを作成する場合は、「HTML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\Template\modelHTML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

WebCenter Sitesによって次のフィールドが移入されます。

- ヘッダーとその他の自動生成コードを持つ「エレメント・ロジック」フィールド。
たとえば、「JSP」ボタンをクリックすると、WebCenter SitesのJSPタグ・ライブラリごとのタグ・ライブラリ・ディレクティブがWebCenter Sitesによって入力されます。また、WebCenter Sitesにより、テンプレート・アセットと、そのテンプレートによってレンダリングされるページまたはページレット間の構成の依存性をマークするために、RENDER.LOGDEP (render:logdep)タグが設定されます。

- 「エレメントのストレージ・パス/ファイル名」フィールド。このフィールドの値は変更しないでください。
このフィールドには、エレメント・ファイルへのパスが先行するエレメント・ファイル名が表示されます。ネーミング規則は、表18-2に記載されています。

テンプレート・アセットを保存すると、「エレメントのストレージ・パス/ファイル名」フィールドの値は、ElementCatalog表のurl列のエレメントを表す行に書き込まれます。

4. 「Rootelement」フィールドには、表18-2に示す値が事前に移入されています。このフィールドの値は変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

5. (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。テンプレート・アセットを保存すると、このフィールドの情報はElementCatalog表のエレメント・エントリに対するdescription列に書き込まれます。

6. (必須)。「エレメント・ロジック」フィールドに、エレメントをコーディングします。2つのcs:ftcsタグの間にすべてのコードを入力します。
JSPを使用している場合は、使用中のタグ・ライブラリを記述するtaglibディレクティブからコメントを削除します。

この手順については、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

注意:

テンプレート共有またはレプリケート可能サイトの確保

テンプレート・アセットを共有したり、現在のサイトをレプリケート可能にするには、テンプレートのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照していないことを確認してください。かわりに、「テンプレート共有とサイト・レプリケーション」で説明するように、render:lookupタグと所定のキーを使用します。「マップの構成」では、同じキーを、エレメント・ロジックで使用するためにアクセスする必要のあるアセット情報にマップすることになります。

テンプレートのコール

テンプレートは常にrender:calltemplateタグでコールするようにし、render:callelementタグまたはrender:satellitepageは絶対に使用しないでください。

7. (オプション)。「エレメント・パラメータ」フィールドと「追加エレメント・パラメータ」フィールドは、エレメントに渡される可能性のある変数または引数を入力するために使用します(それらの変数や引数がサイト・デザインで必要になる場合)。

- 「エレメント・パラメータ」フィールドは、ElementCatalogのresdetails1列に相当します。テンプレートを保存すると、WebCenter Sitesにより、テンプレートID (tid)がこのフィールド(つまり、resdetails1列)に書き込まれます。

- 「追加エレメント・パラメータ」フィールドは、ElementCatalogのresdetails2列に相当します。WebCenter Sitesでは、このフィールドは空白のままになります。

サイト・デザインにより、テンプレート・エレメントでtidに加えて変数も使用する必要がある場合は、その変数を前述のフィールドのいずれか1つに入力します。これは、name=valueのペアとして入力します。複数の引数は、アンパサンド(&)文字で区切ります。例:

MyArgument=value1&YourArgument=value2

各フィールドは255個までの文字をサポートします。

変数の使用の詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

8. 「続行」をクリックして、「SiteEntry」画面を開きます。

18.4.2.4 SiteEntryの構成

「SiteEntry」画面は、このテンプレート・アセットによってレンダリングされるページのキャッシングおよびページレット・パラメータの指定に使用します。

テンプレート・アセットが保存されると、「SiteEntry」画面で指定したフィールド値が、次の手順に示すように、SiteCatalog表に書き込まれます。

図18-3に示すように、「SiteEntry」画面で、次の手順の説明に従って各フィールドに値を入力します。

図18-3 テンプレート・サイト・エントリ・フォーム

1. 「キャッシュ基準」フィールドで、次の手順を実行します。

a. WebCenter Sitesでは、次の予約変数がキャッシュ基準として指定されています。

c,cid,context,p,rendermode,site,sitepfx,ft_ss

注意:

予約されたキャッシュ基準変数は、削除しないでください。予約変数の詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

b. 独自の変数をキャッシュ基準として含める必要がある場合は(たとえば、foo)、その変数を既存のリストに追加します。例:

c,cid,context,foo,p,rendermode,site,sitepfx,ft_ss

注意:

「キャッシュ基準」フィールドでは、「SiteCatalog Pagename」と組み合せてページレットを一意に定義する変数を指定します。変数は、キャッシュされたページの識別に使用されます。つまり、変数はページのキャッシュ・キーで使用されることになります。

キャッシュ基準として指定された変数のみが、キャッシュされたページのキャッシュ・キーを作成するためにキャッシング・システムで使用されます。したがって、サイト・デザインにより、予約変数に加えてページ・レベルの変数を使用する必要がある場合は、この手順で示すように、必ずこれらの変数をキャッシュ基準変数として指定してください。

2. CKEditorの「追加のパラメータ」セクションを使用可能にする場合は、次の手順を実行します。

a. テンプレートの「キャッシュ基準」に追加した「追加のパラメータ」を、テンプレートの「適切な引数」セクションに移動します。

b. パラメータを「適切な引数」セクションに移動すると、そのパラメータには接頭辞fp:を付ける必要がなくなるため、パラメータ名は接頭辞なしで使用します。
たとえば、fp:imageHeightを使用するのではなく、単にimageHeightを使用します。

c. これらのパラメータは、そのパラメータを含むテンプレートで使用できるようになり、<ics:getvar name="imageHeight"/>などの標準的な方法で取得できるようになります。

「その他のパラメータ」セクションには、イメージ・ディメンションなどのカスタム・パラメータをテンプレートに渡す方法が用意されています。このようなその他のパラメータは、「アセット・リンクを含める」および「アセット・リンクの追加」の各ダイアログ・ボックスで使用できるようになります。パラメータ名(この例では、imageHeightとimageWidth)は、「名前」メニューのオプションとして、CKEditorの「その他のパラメータ」セクションに表示されます。「値」フィールドでは、選択したパラメータの値をユーザーが指定できます。その他のパラメータの詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

テンプレート・アセットが保存されると、キャッシュ基準の変数がSiteCatalog表のpagecriteria列に書き込まれます。

3. (オプション)。「アクセス制御リスト」フィールドは、SiteCatalog表のacl列に相当します。特定の訪問者のみがこのページをリクエストできるようにするには、ページを表示するために訪問者が必要とするACLを選択します。ACLの詳細は、「管理システムのユーザーの管理」を参照してください。

4. 「Rootelement」フィールドには、表18-2に示す値が事前に移入されています。

5. 「キャッシュ規則」フィールドは、SiteCatalog表のcscacheinfo列およびsscacheinfo列に相当します。次のいずれかの操作を行います。

- このテンプレートのエレメントでレンダリングするページレットをキャッシュする必要がある場合は、「キャッシュ済」を選択します。ページレットは、永久にキャッシュ済に設定されます。キャッシュは、CacheManagerのアクティブなキャッシュ管理ロジックによってフラッシュされます。このオプションにより、WebCenter SitesとSatellite Server双方のキャッシュ条件が設定されます。

- このテンプレートのエレメントでレンダリングするページレットのキャッシングをオフにするには、「未キャッシュ」を選択します。このオプションにより、WebCenter SitesとSatellite Server双方のキャッシュ条件が設定されます。

- 「詳細」を選択して、WebCenter SitesとSatellite Serverに対して個別にキャッシュ規則を設定します。「詳細」を選択すると、WebCenter Sitesのキャッシュ用と、Satellite Serverキャッシュ用の2つの追加フィールドが表示されます。

注意:

CacheManagerは、WebCenter SitesおよびSatellite Serverの両方でキャッシュされたページのライフサイクルを管理するように作成されています。これは、永久的にキャッシュされるように設定されたページで使用できます。キャッシュがSatellite Serverで失効する前にWebCenter Sitesで失効した場合、CacheManagerはキャッシュを適切にフラッシュできなくなり、無効なページがキャッシュから使用される場合があります。上級ユーザーのみが、これらの設定を手動で構成することをお薦めします。

ページ・キャッシュ設定の詳細は、「ページのデザインとキャッシングの理解」を参照してください。

ページ・キャッシュ設定の詳細は、「ページのデザインとキャッシングの理解」を参照してください。

1. 「SiteCatalog Pagename」フィールド。このフィールドの値は変更しないでください。このページには、ページ・エントリの名前が事前に移入されています。ページのネーミング規則は、表18-2に記載されています。

2. 「ページレット・パラメータ」セクションでは、テンプレートが実行されるたびにテンプレートに渡されるページレット・パラメータ(名前と値のペア)を入力できます。「ページレット・パラメータ」セクションでは、合計510文字をサポートしています。

注意:

「ページレット・パラメータ」セクションには、次のデフォルトのページレット・パラメータ(手順1で指定されている予約変数)が事前に移入されています。これらの値は次のとおりです。

site, sitepfx, rendermode

デフォルトのパラメータ値は、テンプレートがコールされたときに明示的に指定された場合は、上書きされます。

- この手順でページレット・パラメータを指定する場合は、必ずその名前をキャッシュ基準の変数としてリストに追加します(手順1を参照)。

- 独自のキャッシュ基準の変数を(手順1で)指定した場合、その変数は、「ページ・パラメータ」セクションのリストに表示されます。これらのパラメータに対して値を指定しない場合、パラメータはWebCenter Sitesによって無視されます。

テンプレート・アセットが保存されると、ページレット・パラメータとして指定した名前と値のペアは、SiteCatalog表のresargs1列またはresargs2列のいずれかに書き込まれます。書込み先の列は重要ではないため、自動的に管理されます。(各列では、最大255文字をサポートしています。)

3. 「続行」をクリックして、「サムネイル」画面を開きます。

4. 「続行」をクリックして、「マップ」画面を開きます。

注意:

テンプレート・アセットの作成が完了してテンプレート・アセットを保存した後で、「サムネイル」画面に戻ります。

18.4.2.5 マップの構成

マッピングの目的は、「テンプレート共有とサイト・レプリケーション」で説明するように、サイト・レプリケーションとテンプレート・アセットの共有を有効化することです。

注意:

レプリケート不能のサイトを設計している場合は、この手順をスキップしてください。

「マップ」フォームを使用して、次の操作を行います。

- テンプレートのエレメント・ロジックのrender:lookupタグにある各キーを、エレメント・ロジックで使用される値にマップします。

- 各キーの値を、エレメント・ロジックで使用する必要のある情報(アセット、アセット・タイプ、属性名、またはテンプレート名)にマップします。

テンプレート・アセットが保存されると、マップはTemplate_Map表に書き込まれます。

「マップ」フォームで、この手順の説明に従って各フィールドに値を入力します。

1. 「キー」フィールドは、エレメント・ロジックが検索する値を表しています。エレメント・ロジックのrender:lookupタグで指定したキーを入力します。

2. 「タイプ」フィールドでは、アクセス対象のアセット情報のタイプを特定します。次のいずれかのオプションを選択します。

- テンプレート名: テンプレート名をキー値にマップします(この値は、次の手順で「値」フィールドに指定します)。アクセスされる情報は、次の手順で指定する値に一致するテンプレート名です。例として、図18-4 を参照してください。

- アセット・タイプ: アセット・タイプをキー値にマップします。アクセス対象の情報はアセット・タイプであり、次の手順で指定する値と同等です。

- アセット(タイプ: 名前): 属性タイプ:名前をキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

- アセット(タイプ: ID): 属性のタイプ:IDをキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

図18-4 テンプレート・アセット: サンプル・マップ

3. 「値」フィールドに、キーの値を入力します。この値は、テンプレート実行時にエレメント・ロジックにより検索されます。

4. 「サイトID」フィールドで、マッピングを適用するサイトの名前を選択します。

5. キーを追加するには、「さらに追加」をクリックして、この項の手順を繰り返します。

6. テンプレートの作成が完了したら、テンプレートを保存します(「変更の保存」をクリックします)。

WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。

7. テンプレートのサムネイルを作成するには、「(オプション)サムネイルの作成」に進みます。それ以外の場合は、「テンプレートの調査」までスキップします。。

18.4.2.6 (オプション)サムネイルの作成

サムネイルはグラフィック表示されるため、テンプレート・ユーザーがテンプレート・アセットでページをレイアウトしたり、コンテンツをレンダリングする方法を決定する際に役立ちます。作成したサムネイルは、テンプレートの「調査」フォームに表示されます。

テンプレート・アセットが保存されると、サムネイル・ファイルの名前がTemplate_Thumb表のurlthumbnail列に書き込まれます。

サムネイルを作成するには、次の手順を実行します。

1. テンプレート・アセットをプレビューします。手順は、「CSElementアセットとSiteEntryアセットおよびプレビュー」を参照してください。

2. プレビューをイメージ・ファイルとして取得して、ファイル・システムに保存します。

3. 「テンプレート」フォームを開いて、画面上部の「サムネイル」をクリックします。
テンプレート・サムネイル・フォームが開きます(図18-5を参照)。

4. 「サムネイル・イメージ」フィールドに、手順2で作成したイメージ・ファイルへのパスを入力(または参照)します。

図18-5 テンプレート・サムネイル・フォーム

5. サムネイルを「調査」フォームに表示するには、次の手順を実行します。

a. テンプレートを保存します(「保存」アイコンをクリックします)。
WebCenter Sitesによってイメージ・ファイルがWebCenter Sitesデータベースにアップロードされ、テンプレートの「調査」フォームが表示されます。

b. 「調査」フォームで、「サムネイル・イメージ」セクションが現れるまで下へスクロールします。表示されたイメージが大きすぎたり小さすぎる場合は、ソース・ファイルでイメージをサイズ変更して、手順4と5を再実行します。

6. イメージを「サムネイル」画面で操作するには、次の手順を実行します。

a. 「調査」フォームの上部にスクロールして、「編集」リンクをクリックします。

b. 「テンプレート」フォームの上部で、「サムネイル」をクリックします。

7. サムネイル上でコピー、送信、その他の操作を実行するには、サムネイルを右クリックしてオプションを選択します。

8. サムネイルを削除するには、「サムネイル・イメージを削除しますか。」を選択して、「変更の保存」をクリックします。
WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。

18.4.2.7 テンプレートの調査

テンプレート・アセットの作成を終了して、「保存」をクリックすると、WebCenter Sitesは次の操作を行います。

- データベース表に書き込みます。

- Template表にテンプレート・エントリを作成します。

- AssetTypeName/TemplateNameネーミング規則を使用して、ElementCatalog表にエレメント・エントリを作成します。エレメントが(Oracle WebCenter Sites Explorerではなく)テンプレート・フォームにコーディングされた場合は、WebCenter Sitesによってエレメント・ファイルも作成されます。

- テンプレートが属するサイトの名前を判断し、SiteName/AssetTypeName/TemplateNameネーミング規則を使用してSiteCatalog表にページ・エントリを作成します。

- 新しいSiteCatalogページ・エントリのルート・エレメントの名前をElementCatalogエントリの名前に設定します。

- サムネイル・エントリをTemplate_Thumb表に作成します。

- マップ・エントリをTemplate_Map表に作成します。

- 「調査」フォームを表示します(このフォームには、次の種類の情報が表示されます)。

- 「名前」画面の情報(すべてのタイプのアセットに関するアセット名、説明、ステータス、ソース、IDなどの標準的な概要情報)。

- 「エレメント」画面の情報(ルート・エレメント、エレメント・ロジック、エレメント・ファイルへのパス、およびtid)。

- 「SiteEntry」画面の情報(SiteCatalogページ名、ページレット・パラメータ、キャッシュ基準、およびこのページを表示する権限を持つユーザーのACL)。

- 「サムネイル」画面の情報(サムネイル・イメージが選択されている場合はそのイメージ)。

- 「マップ」画面の情報(サイトがレプリケート可能、またはテンプレートが共有可能である場合は、キー-値-アセット情報のマップ)。

- テンプレート・アセットを共有している場合、「調査」フォームには、このテンプレート・アセットに対するSiteCatalogの追加ページ・エントリがすべて一覧表示されます(テンプレートを共有するサイトごとに1つのページ・エントリが存在します)。

図18-6 エレメント・パラメータが表示された「調査」フォーム

図18-7 サイト・エントリとマップが表示された「調査」フォーム

18.5 CSElementアセットの作成

CSElementアセットの作成時には、アセットの作成、アセットに対するエレメントのコーディング、およびキー-値-アセット情報マップ(テンプレート・アセットのマップと同様)の構成という3つの操作を行います。

CSElementアセットを作成するには、まず、「CSElementの作成を開始する前に」」を完了して、CSElementの保存後には変更できない(または、変更してはいけない) CSElementプロパティの設定方法と、CSElementのエレメント・ロジックのコーディング方法を決定する必要があります。次に、「テンプレート・アセットの作成」に進み、Adminインタフェースを使用して次の手順を完了します。

- 「CSElement」フォームを開く

- CSElementアセットの名前付けと記述

- エレメントの構成
(ファイル・タイプおよびロジックを指定する場合。)

- マップの構成
(CSElement共有とサイト・レプリケーションをサポートする場合。)

- CSElementの保存と調査

- ブックマークへのCSElement追加
(CSElementをSiteEntryアセットのルート・エレメントとして使用する場合。「SiteEntryアセットの作成」を参照。)

「CSElement」フォームに入力する情報は、次の手順で示すように、CSElementアセットの保存時にデータベース表に書き込まれます。

注意:

CSElementアセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。そのかわりに、「CSElement」フォームと、この項に示した手順を使用して、CSElementアセットを作成します。CSElementロジックのコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

この項には次のトピックが含まれます:

- CSElementの作成を開始する前に

- SiteEntryアセットの作成

18.5.1 CSElementの作成を開始する前に

CSElementアセットの作成を開始する前に、次のいつくかの点を決定してください。

- CSElementアセットの名前。

- CSElementを共有可能にするかどうか、またサイトのレプリケートを可能にするかどうか。これらの考慮事項により、CSElementのエレメント・ロジックのコーディング方法を決定します。

- CSElementのエレメント・ロジックのコーディングを、「CSElement」フォームではなくOracle WebCenter Sites Explorerで実行するかどうか。この方法は、「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」で概説している理由によりお薦めできません。

18.5.1.1 CSElementの名前付け

- CSElementアセットが保存されると、その名前は変更できなくなります。

- CSElementロジック・ファイルは、CSElementの名前を採用します(次のファイル拡張子が続きます)。

CSElementName.xml_or_jsp_or_html

CSElementロジック・ファイルの名前は変更しないでください。

18.5.1.2 CSElement共有とサイト・レプリケーション

CSElementを作成する前に、CSElementの共有と使用中のサイトのレプリケートが必要かどうかを決定します。必要な場合、CSElementロジックは同じ方法でコーディングされます。共有とレプリケーションが必要でない場合は、キー-値のマッピングを省略してください(「マップの構成」を参照)。

CSElement共有とサイト・レプリケーションをサポートするエレメント・ロジックのコーディングの詳細は、「テンプレート共有とサイト・レプリケーション」を参照してください。この情報は、例外なくCSElementアセットに適用できます。

18.5.2 CSElementアセットの作成

CSElementアセットはWebCenter Sitesインタフェースで作成できます。

注意:

この項の手順を開始する前に、「CSElementの作成を開始する前に」を参照して、CSElementアセットの作成についての情報を確認してください。

- 「CSElement」フォームを開く

- CSElementアセットの名前付けと記述

- エレメントの構成

- マップの構成

- CSElementの保存と調査

- ブックマークへのCSElement追加

18.5.2.1 「CSElement」フォームを開く

1. Adminインタフェースを開きます。

2. ボタン・バーで、「新規」をクリックします。

3. アセット・タイプのリストで、「新規CSElement」を選択します。

「CSElement」フォームが開きます。

注意:

新規CSElementオプションを表示するには、サイトに対してCSElementアセット・タイプを有効化し、その「スタート・メニュー」アイテムを作成する必要があります。

4. 「テンプレート・アセットの名前付けと記述」に進みます。

注意:

「CSElement」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているCSElementアセットがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。「テンプレート・アセットの名前付けと記述」に進みます。

18.5.2.2 CSElementアセットの名前付けと記述

「名前」画面は、CSElementに関するメタデータの定義に使用します。このメタデータにより、開発者はCSElementの動作と、CSElementが機能の実行に使用する引数を識別できます。

注意:

CSElementの作成中はいつでもCSElementを保存できます。WebCenter Sitesにより、CSElementの「調査」フォームが表示されます。「CSElement」フォームに戻るには、「編集」リンクをクリックします。

CSElementに名前を付けて記述するには、「名前」画面(図18-8を参照)で、次の手順の説明に従って各フィールドに値を入力します。

図18-8 CSElement名フォーム

1. (必須)。「名前」フィールドに、CSElementアセットの説明的な一意の名前を入力します。CSElementの動作を説明する名前を使用するのが最適です。
有効なエントリ

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)

注意:

CSElementアセットの名前は、「SiteEntryアセットの作成を開始する前に」のガイドラインを使用して決定してください。

2. 「説明」フィールドに、CSElementアセットの簡単な説明を入力します。128個までの文字を入力できます。

3. 「適切な引数」フィールドで、次の手順を実行します。

a. CSElementに渡される可能性のある引数を入力して、「引数の追加」をクリックします。

b. 表示されたフィールドで、次の手順を実行します。

- 引数がオプションか、または必須かを指定します。

- 引数の説明を提供します(作成する引数の目的を把握しやすいようにするため)。

- 引数に対して適切な値(説明を含む)を指定します。

(「引数の追加」ボタンと「適切な値の追加」ボタンをクリックすることで、必要な数の引数と適切な値を指定できます。)

4. 「続行」をクリックして、「エレメント」画面を開きます。

18.5.2.3 エレメントの構成

「エレメント」フォーム(図18-9)は、CSElementのエレメントの作成、エレメント・ファイル・タイプ(XML、JSP、またはHTML)の定義、エレメント・ロジックの提供、およびエレメントの名前付けに使用します。例:

- 「エレメントの作成」フィールドには、エレメント・ロジック用に選択可能なファイル・タイプXML、JSP、HTMLが表示されま、このフィールドは、「エレメント・ロジック」フィールドに標準スタブ・コード(作成するすべてのエレメントに含める必要がある)をシードする際に使用します。

- 「エレメントの作成」フィールドを使用して、たとえば.jspファイルを作成すると、WebCenter Sitesは、デフォルトでJSPのtaglib文とrender.logdepタグを「エレメント・ロジック」フィールドに追加して、このCSElementアセットと、このエレメントからレンダリングされるページ間の構成の依存性をログ記録できるようにします。その他のファイル・タイプの場合は、WebCenter Sitesによって、それぞれのファイル・タイプに固有のコードが追加されます。独自のコードを「エレメント・ロジック」フィールドに追加します。
依存性の詳細は、「依存性について」を参照してください。エレメント・ロジックのコーディングについては、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- 「エレメントのストレージ・パス/ファイル名」フィールドでは、エレメント・ロジックを保持するファイルの名前を付けて、そのファイルへのパスを指定します。

CSElementが保存されると、「エレメント」画面のフィールド値は、ElementCatalog表の(エレメントを表す)行に書き込まれます。

注意:

既存エレメントの選択について

次の手順では、CSElementアセットのエレメントを新規作成しているものとします。ただし、旧リリースのWebCenter Sitesからアセットを移行していて、既存エレメントを再使用する場合は、WebCenter Sitesで既存エレメントを検出し、このCSElementアセットと関連付けられるようにするために、エレメントを正確に識別する必要があります。

既存のエレメントを選択するには:

- (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。

- 「エレメントのストレージ・パス/ファイル名」フィールドに、「CSElementの名前付け」の規則に従った値を入力します。

- サイト・デザインで必要な場合は、各エレメント・パラメータ・フィールドに適切な引数を入力します。この手順については、手順5を参照してください。

- CSElementアセットを保存し、再度開きます。

WebCenter Sitesは、正しい名前のエレメントの存在をチェックします。

エレメントに適切な名前が付けられていると、WebCenter Sitesはエレメントを認識して、そのコードを「エレメント・ロジック」フィールドに表示します。

指定されたエレメントが存在しない場合(または、名前が不適切な場合)は、WebCenter Sitesでは何も行われません。CSElementアセットを調査または編集するときに、フォームにルート・エレメントがありませんというメッセージがWebCenter Sitesによって表示されます。エレメントをコーディングして適切な名前を付けると、WebCenter Sitesでただちに検出され、CSElementアセットに関連付けられます。

新しいエレメントを構成するには、「エレメント」フォームで、次の手順の説明に従って各フィールドに値を入力します。

図18-9 CSElementエレメント・フォーム

1. 「エレメントを作成しますか。」フィールドで、次のいずれかを実行します。

- .xmlファイルを作成する場合は、「XML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelXML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .jspファイルを作成する場合は、「JSP」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelJSP.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .htmlファイルを作成する場合は、「HTML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelHTML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

WebCenter Sitesによって次のフィールドが移入されます。

- 「エレメントのストレージ・パス/ファイル名」フィールド。このフィールドの値は変更しないでください。
このフィールドには、エレメント・ファイルへのパスが先行するエレメント・ファイル名が表示されます。デフォルトでは、このファイルはCSElementアセットの名前(手順1で入力したもの)を採用し、その後に次のファイル拡張子が続きます。

CSElementName.xml_or_jsp_or_html

CSElementアセットを保存すると、このフィールドの値がElementCatalog表のurl列のエレメントを表す行に書き込まれます。

- ヘッダーとその他の情報を持つ「エレメント・ロジック」フィールド。
たとえば、「JSP」ボタンをクリックすると、共通する複数のWebCenter SitesのJSPタグ・ライブラリ(asset、siteplan、render)に対して1つのタグ・ライブラリ・ディレクティブがWebCenter Sitesで設定されます。また、WebCenter Sitesは、cs:ftcsの開始タグと終了タグも設定し、CSElementアセットと、エレメントによりレンダリングされるページまたはページレット間の構成の依存性をマークするために、RENDER.LOGDEP (render:logdep)タグを設定します。

2. 「Rootelement」フィールドには、エレメント・ファイルの名前((CSElementName.xml_or_jsp_or_html))が事前移入されています。このフィールドの値は変更しないでください。

ルート・エレメントは、この名前でElementCatalog表にリストされます。このエレメント(RENDER.CALLELEMENT)をコールするコードを作成する場合は、この名前を使用してください。これは、デフォルトでは、CSElementアセットの名前を使用しています。

3. (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。

CSElementアセットを保存すると、このフィールドの情報はElementCatalog表のエレメント・エントリに対するdescription列に書き込まれます。

4. (必須)。「エレメント・ロジック」フィールドに、エレメントをコーディングします。cs:ftcs終了タグの前に、すべてのコードを入力する必要があります。

JSPを使用している場合は、使用中のタグ・ファミリを記述するtaglibディレクティブからコメントを削除します。

この手順については、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

注意:

テンプレート共有またはレプリケート可能サイトの確保: CSElementを共有したり、現在のサイトをレプリケート可能にするには、CSElementのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照しないようにしてください。かわりに、「テンプレート共有とサイト・レプリケーション」で説明するように、render:lookupタグと所定のキーを使用します。「マップの構成」では、キーを、エレメント・ロジックで使用するためにアクセスする必要のあるアセット情報にマップすることになります。

テンプレートのコール: テンプレートは常にrender:calltemplateタグでコールするようにしてください。render:callelementタグまたはrender:satellitepageは絶対に使用しないでください。

5. (オプション)。「エレメント・パラメータ」フィールドと「追加エレメント・パラメータ」フィールドは、エレメントに渡される可能性のある変数または引数を入力するために使用します(それらの変数や引数がサイト・デザインで必要になる場合)。

- 「エレメント・パラメータ」フィールド。このフィールドには、WebCenter SitesによりCSElementアセットの一意のIDとして生成されたCSElement ID (eid)がWebCenter Sitesにより移入されています。この値を変更または削除しないでください。
このフィールドは、ElementCatalog表のresdetails1列に相当します。CSElementを保存すると、WebCenter Sitesにより、CSElementを表す行のresdetails1列にCSElement IDが書き込まれます。

- 「追加エレメント・パラメータ」フィールド。WebCenter Sitesでは、このフィールドは空白のままになります。
このフィールドは、ElementCatalog表のresdetails2列に相当します。

サイト・デザインにより、eidに加えて変数を使用する必要がある場合は、その変数を前述のフィールドのいずれか1つに入力します。これは、name=valueのペアとして入力します。複数の引数は、アンパサンド(&)文字で区切ります。例:

MyArgument=value1&YourArgument=value2

各フィールドは255個までの文字をサポートします。

WebCenter Sites変数の詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

6. 「続行」をクリックして、「マップ」画面を開きます。

18.5.2.4 マップの構成

マッピングの目的は、サイト・レプリケーションとCSElementアセットの共有を有効化することです。マッピングの基本コンセプトは、テンプレート・アセットの場合とまったく同じです。これについては、「テンプレート共有とサイト・レプリケーション」で説明しています。

注意:

レプリケート不能のサイト、または共有されないCSElementアセットを設計している場合は、この項をスキップしてください。

「マップ」フォームを使用して、次の操作を行います。

- エレメント・ロジックのrender:lookupタグにある各キーを、エレメント・ロジックで使用する必要のある値にマップします。

- 各キーの値を、エレメント・ロジックで使用する必要のある情報(アセット、アセット・タイプ、属性名、またはテンプレート名)にマップします。

CSElementアセットが保存されると、マップがCSElement_Map表に書き込まれます。

「マップ」フォーム(図18-10)で、この手順の説明に従って各フィールドに値を入力します。

図18-10 CSElementマップ・フォーム

1. 「キー」フィールドは、エレメント・ロジックが検索する値を表します。このフィールドに、エレメント・ロジックのrender:lookupタグで指定したキーを入力します。

2. 「タイプ」フィールドでは、アクセス対象のアセット情報のタイプを特定します。次のいずれかのオプションを選択します。

- テンプレート名: テンプレート名をキー値にマップします(この値は、次の手順で「値」フィールドに指定します)。アクセスされる情報は、次の手順で指定する値に一致するテンプレート名です。(例は、図18-11を参照してください。)

- アセット・タイプ: アセット・タイプをキー値にマップします。アクセス対象の情報はアセット・タイプであり、次の手順で指定する値と同等です。

- アセット(タイプ: 名前): 属性タイプ:名前をキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

- アセット(タイプ: ID): 属性のタイプ:IDをキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

図18-11 CSElementアセット: サンプル・マップ

3. 「値」フィールドに、キーの値を入力します。この値は、CSElementアセットの起動時にエレメント・ロジックにより検索されます。

4. 「サイトID」フィールドで、マッピングを適用するサイトの名前を選択します。

5. キーを追加するには、「さらに追加」をクリックして、この項の手順を繰り返します。

18.5.2.5 CSElementの保存と調査

CSElementアセットの作成が完了したら、「保存」をクリックします。

- WebCenter Sitesにより、データベース表に書き込まれます。

- CSElementアセットの行をCSElement表に作成します(この行には、前述の手順で指定したCSElementの名前と説明が入力されます)。

- 「エレメント」画面で指定した値を使用して、エレメント・エントリをElementCatalog表に作成します。

- 「Rootelement」フィールドの値は、エレメント・ファイルの適切なフォルダへの配置に使用します。

- 「エレメントのストレージ・パス/ファイル名」フィールドの値はurl列に書き込まれます。

- eid変数の値は、resdetails1列のCSElementアセットのIDに設定されます。

- このエレメントをコールする任意のページレットのページキャッシュをフラッシュします。

- 「調査」フォーム(図18-12 )を表示します。このフォームには、次の種類の情報が表示されます。

- 「名前」画面の情報(すべてのタイプのアセットに関するアセット名、説明、ステータス、IDなどの標準的な概要情報)。

- 「エレメント」画面の情報(ルート・エレメント、エレメント・ロジック、エレメント・ファイルへのパス、およびエレメントのeid)。

- 「マップ」画面の情報(サイトがレプリケート可能、またはテンプレートが共有可能である場合は、キー-値-アセット情報のマップ)。

- 「引数を使用したプレビュー」ボタンをクリックすると、SiteEntryアセットによってレンダリングされたページをプレビューできます。

18.5.2.6 ブックマークへのCSElement追加

注意:

CSElementを使用してSiteEntryアセットを作成する場合は、この項の手順を実行してください。この手順では、CSElementをブックマークに追加することで、そのCSElementをWebCenter Sitesのツリーで選択できるようにします。

このセッションでSiteEntryアセットを作成する予定ではなくても、CSElementをブックマークに追加しておくと、検索が容易になります。

CSElementをブックマークに追加するには、次を実行します。

1. 作成したCSElementアセット上で検索を実行します。

2. 結果リストで、右側の列にあるチェック・ボックスを選択して、CSElementを「ブックマーク」に追加します。

このCSElementは、WebCenter Sitesのツリーの「ブックマーク」タブに一覧表示され、このタブでは、そのCSElementはSiteEntryアセットに対して選択可能なオプションになります。

3. SiteEntryアセットを作成します。手順は、「SiteEntryアセットの作成」を参照してください。

図18-12 CSElementアセット: サンプル「調査」フォーム

18.6 SiteEntryアセットの作成

SiteEntryアセットを作成するときには、アセットとページ・エントリの両方をSiteCatalog表に作成します。SiteEntryフォームの最初の部分のフィールドでは、ページ・エントリをアセットとして定義します。その他のフィールドでは、WebCenter Sitesページとしてのページ・エントリに関する情報を指定し、この情報はSiteCatalog表に書き込まれます。

SiteEntryアセットを作成するには、最初に「CSElementの作成を開始する前に」を完了して、そのアセットのルート・エレメントを作成し、SiteEntryプロパティ(SiteEntry名など)の設定方法を決定する必要があります。次に、「SiteEntryアセットの作成」に進み、Adminインタフェースを使用して次の手順を完了します。

- 「SiteEntry」フォームを開く

- SiteEntryアセットの作成

- SiteEntryアセットの保存と調査

「SiteEntry」フォームに入力する情報は、次の手順で示すように、CSElementアセットの保存時にデータベース表に書き込まれます。

注意:

SiteEntryアセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。そのかわりに、「SiteEntry」フォームと、この項に示した手順を使用して、SiteEntryアセットを作成します。

この項には次のトピックが含まれます:

- SiteEntryアセットの作成を開始する前に

- SiteEntryアセットの作成

18.6.1 SiteEntryアセットの作成を開始する前に

SiteEntryアセットの作成を開始する前に、次の手順を実行してください。

1. ページ・エントリのルート・エレメントを次のように作成します。

a. CSElementアセットを作成します。手順は、「CSElementアセットの作成」を参照してください。
(ルート・エレメントは、どのページ・エントリにも必要です。ルート・エレメントは、SiteEntryアセットに対して選択するCSElementのエレメントです。)

b. CSElementを使用可能にします。手順は、「ブックマークへのCSElementの追加」を参照してください。
(SiteEntryアセットに対してCSElementを指定するには、WebCenter Sitesのツリー内にある「ブックマーク」タブからCSElementを選択するか、現在のセッションでCSElementを作成した場合は「履歴」タブからCSElementを選択します)。

2. SiteEntryアセットの名前を決定します。同じ名前がページに割り当てられます。SiteEntryアセットを保存した後は、SiteEntry名とページ名を変更できません。

18.6.2 SiteEntryアセットの作成

SiteEntryアセットはWebCenter Sitesインタフェースで作成できます。

SiteEntryアセットを作成するには、次のタスクを実行します。

- 「SiteEntry」フォームを開く

- SiteEntryアセットの作成

- SiteEntryアセットの保存と調査

注意:

この項の手順を開始する前に、「SiteEntryアセットの作成を開始する前に」を参照して、SiteEntryアセットの作成についての情報を確認してください。

18.6.2.1 「SiteEntry」フォームを開く

1. Adminインタフェースを開きます。

2. ボタン・バーで、「新規」をクリックします。

3. アセット・タイプのリストで、「新規SiteEntry」を選択します。

「SiteEntry」フォームが開きます。

注意:

新規SiteEntryオプションを表示するには、サイトに対してSiteEntryアセット・タイプを有効化し、その「スタート・メニュー」アイテムを作成する必要があります。

4. 「SiteEntryアセットの作成」に進みます。

注意:

「SiteEntry」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているSiteEntryがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。「SiteEntryアセットの作成」に進みます。

18.6.2.2 SiteEntryアセットの作成

「SiteEntry」フォームで、この手順の説明に従って各フィールドに値を入力します。

1. (必須)。「名前」フィールドに、SiteEntryアセットの説明的な名前を入力します。ページの目的を説明する名前を使用するのが最適です。
有効なエントリ

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)。

2. 「説明」フィールドに、SiteEntryアセットの簡単な説明を入力します。128個までの文字を入力できます。

3. (必須)。「Pagename」フィールドをクリックすると、ページ・エントリの名前とページ・エントリへのパス(例: FSIICommon/SideNav/ProductView)が自動的に移入されます。このフィールドの値は変更しないでください。

注意:

このフィールドの値はページ・エントリの名前です(これは、SiteEntryの保存時にSiteCatalog表に格納されます)。このSiteEntryアセット(RENDER.SATELLITEPAGE)をコールするコードを作成する場合は、この名前を使用することをお薦めします。

4. SiteCatalog表にある既存のページ・エントリの行を使用するには、既存のSiteCatalogエントリにマッピングするオプションを選択します。

5. (必須)。「Rootelement」フィールドで、ツリーから適切なCSElementアセットを選択して、「選択したアイテムの追加」をクリックします。

注意:

追加できるCSElementは1つのみです。

6. 「ラッパー・ページ」フィールドでオプションの1つを選択して、作成中のアセットがラッパー・ページであるかどうかを指定します。「いいえ」オプションを選択すると、「ページレットのみ」フィールドが表示されます。

7. 「ページレットのみ」フィールドが表示された場合は、オプションの1つを選択して、作成中のアセットがページレットであるかどうかを指定します。

8. 「ページレット・パラメータ」セクションでは、ページまたはページレットが実行されるたびにページまたはページレットに渡されるページレット・パラメータ(名前と値のペア)を入力します。「ページレット・パラメータ」セクションでは、合計510文字をサポートしています。

注意:

次のことに注意してください。

- 「ページレット・パラメータ」セクションには、デフォルトのパラメータsite、seid、sitepfx、rendermode (デフォルトでは、「キャッシュ基準」フィールド(次の手順)で指定される予約変数)が、それらの値を含めて事前に移入されています
デフォルト値は、ページまたはページレットがコールされたときに明示的に指定された場合は、上書きされます。

- この手順でページレット・パラメータを指定する場合は、次の手順で必ずその名前をキャッシュ基準変数として一覧表示してください。

SiteEntryアセットが保存されると、ページレット・パラメータとして指定した名前と値のペアは、SiteCatalog表のresargs1列またはresargs2列のいずれかに書き込まれます。書込み先の列は重要ではないため、自動的に管理されます。(各列では、最大255文字をサポートしています。)

9. 「キャッシュ基準」フィールドで、次の手順を実行します。

a. WebCenter Sitesでは、次の予約変数がキャッシュ基準として指定されています。

rendermode,seid,site,sitepfx,ft_ss

注意:

予約されたキャッシュ基準変数は、削除しないでください。予約変数の詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

10. 独自の変数をキャッシュ基準として含める必要がある場合は(たとえば、foo)、その変数を既存のリストに追加します。例

foo,rendermode,seid,site,sitepfx,ft_ss

注意:

「キャッシュ基準」フィールドでは、「Pagename」と組み合せてページレットを一意に定義する変数を指定します。変数は、キャッシュされたページの識別に使用されます。つまり、変数はページのキャッシュ・キーで使用されることになります。

キャッシュ基準として指定された変数のみが、キャッシュされたページのキャッシュ・キーを作成するためにキャッシング・システムで使用されます。したがって、サイト・デザインにより、予約変数に加えてページ・レベルの変数を使用する必要がある場合は、この手順で示すように、必ずこれらの変数をキャッシュ基準変数として指定してください。

SiteEntryアセットが保存されると、キャッシュ基準の変数とその値がSiteCatalog表のpagecriteria列に書き込まれます。

11. 「キャッシュ規則」フィールドは、SiteCatalog表のcscacheinfo列およびsscacheinfo列に相当します。次のいずれかの操作を行います。

- このSiteEntryのCSElementでレンダリングするページレットをキャッシュする必要がある場合は、「キャッシュ済」を選択します。ページレットは、永久にキャッシュ済に設定されます。キャッシュは、CacheManagerのアクティブなキャッシュ管理ロジックによってフラッシュされます。このオプションにより、WebCenter SitesとSatellite Server双方のキャッシュ条件が設定されます。

- このSiteEntryのCSElementでレンダリングするページレットのキャッシングをオフにするには、「未キャッシュ」を選択します。このオプションにより、WebCenter SitesとSatellite Server双方のキャッシュ条件が設定されます。

- 「詳細」を選択して、WebCenter SitesとSatellite Serverに対して個別にキャッシュ規則を設定します。「詳細」を選択すると、WebCenter Sitesのキャッシュ用と、Satellite Serverキャッシュ用の2つの追加フィールドが表示されます。

注意:

CacheManagerは、WebCenter SitesおよびSatellite Serverの両方でキャッシュされたページのライフサイクルを管理するように作成されています。これは、永久的にキャッシュされるように設定されたページで使用できます。キャッシュがSatellite Serverで失効する前にWebCenter Sitesで失効した場合、CacheManagerはキャッシュを適切にフラッシュできなくなり、無効なページがキャッシュから使用される場合があります。上級ユーザーのみが、これらの設定を手動で構成することをお薦めします。

ページ・キャッシュ設定の詳細は、「ページのデザインとキャッシングの理解」を参照してください。

12. 「アクセス制御リスト」フィールドは、SiteCatalog表のacl列に相当し、特定の訪問者のみがこのページをリクエストできるようにする場合は、ページを表示するために訪問者が必要とするACLを入力します。ACLの詳細は、「管理システムのユーザーの管理」を参照してください。

18.6.2.3 SiteEntryアセットの保存と調査

SiteEntryアセットの作成が完了したら、「保存」をクリックします。WebCenter Sitesで次の処理が行われます。

- データベース表に書き込みます。

- SiteEntryアセットに対する行をSiteCatalog表に作成します。この行には、前述の手順で指定した値が入力されます。

- 「調査」フォームを表示します。このフォームには、次の情報が表示されます。

- 標準の概要情報(アセット名、説明、ステータス、ID)と、前述の手順で指定したページ・エントリ基準。

- 「引数を使用したプレビュー」ボタンをクリックすると、SiteEntryアセットによってレンダリングされたページをプレビューできます。

18.7 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの管理

この項では、テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの使用に関する追加手順について説明します。

この項には次のトピックが含まれます:

- デフォルトの承認テンプレートの指定(静的パブリッシュのみ)

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの編集

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの共有

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの削除

- テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー

18.7.1 デフォルトの承認テンプレートの指定(静的パブリッシュのみ)

ディスクへのエクスポートのパブリッシュ方法を使用するパブリッシュの宛先に対してアセットが承認されると、承認システムはアセットに割り当てられたテンプレートを調査して、その依存性を判別します。

複数のテンプレート(アセットと同じタイプのテキスト専用バージョン、概要バージョン、フル・バージョンなど)を使用してアセットをレンダリングするようにオンライン・サイトを設計する場合は、すべてのテンプレートの承認依存性を代表するセットが含まれているテンプレートを作成し、そのテンプレートをアセット・タイプに対するデフォルトの承認テンプレートとして指定する必要があります。

承認テンプレートの詳細は、「ディスクへのエクスポート用の承認テンプレート」を参照してください。

テンプレートがデフォルトの承認テンプレートであると指定するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「パブリッシュ」→「宛先」→「静的」を選択します。

2. 静的宛先の名前で、「デフォルトのテンプレートの設定」を選択します。

3. 「デフォルト・テンプレート」フォームで、「編集」をクリックします。

4. 編集フォームで、アセット・タイプ別にデフォルト・テンプレートを選択します。アセット・タイプのいずれかにサブタイプ機能を使用している場合、そのアセット・タイプのサブタイプ別にデフォルトの承認テンプレートを指定できます。サブタイプの詳細は、「ベーシック・アセット・タイプの作成」の「(オプション)サブタイプの追加」を参照してください。

5. 作業の終了後に、「保存」をクリックします。

18.7.2 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの編集

Template、CSElement、およびSiteEntryの各アセットを作成すると、SiteCatalog表またはElementCatalog表(あるいは両方)にもエントリが作成されます。これらのエントリの名前はアセットの名前に基づいており、テンプレート・アセットの場合はアセット・タイプと、テンプレートが属するサイトに基づいています。このようなネーミング依存性があるため、Template、CSElement、またはSiteEntryの各アセットの編集時には次の制約が適用されます。

- Template、CSElementまたはSiteEntryの各アセットを保存した後で名前を変更することはできません。

- Templateアセットの場合は、テンプレート・アセットの保存後、「アセット・タイプ」フィールドで選択したアセット・タイプは変更できません。

- TemplateアセットまたはCSElementアセットの場合、ルート・エレメントの名前は変更できません。

- SiteEntryアセットの場合、ページ・エントリの名前は変更できません。

注意:

Templateを指す1つ以上のサイト・エントリを手動で(Oracle WebCenter Sites Explorerを使用して)作成し、そのTemplateをAdminインタフェースを通して編集した場合、手動で作成されたサイト・エントリは自動的に削除されます。

アセットの編集の基本的な手順は、『Oracle WebCenter Sitesの管理』を参照してください。

18.7.3 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの共有

CSElement、テンプレートまたはSiteEntryの各アセットを共有すると、WebCenter Sitesにより、アセットを共有するサイトごとに1つの行がAssetPublication表に作成されます。

さらに、テンプレート・アセットのみを対象として、WebCenter Sitesは次の操作を行います。

- アセットを共有するサイトごとに、SiteCatalogページ・エントリを新規作成します。ページ・エントリの名前にサイトの名前が使用されます。新規作成されたすべてのページ・エントリは、同じルート・エレメント、テンプレート・エレメントを指します。

注意:

これらのページ・エントリのルート・エレメントを変更しないでください。共有テンプレートのページ・エレメントはすべて、同じルート・エレメントを指す必要があります。

- このルート・エレメントを共有する共有テンプレートのその他のすべてのページ・エントリを、「調査」フォームに一覧表示します。

アセットの共有の基本的な手順は、『Oracle WebCenter Sitesの管理』のブログ・アセットの共有に関する項を参照してください。

注意:

テンプレートとCSElementを共有可能にするには、それぞれのエレメント・ロジックをアセット・タイプ名、属性名、テンプレート名またはIDでハードコード化しないようにしてください。かわりに、render:lookupタグを使用して、render:lookupタグが参照できるマップが作成されているキーをハードコード化して、エレメント・ロジックでの使用にアセット情報を検索できるようにします。

18.7.4 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの削除

WebCenter Sitesでは、別のアセットで使用中のアセットを削除することはできません。ただし、テンプレートまたはCSElementが他のテンプレートまたはCSElementエレメントのコードによって参照されるかどうかはチェックされません。

テンプレート・アセットまたはSiteEntryアセットを削除する前に、そのアセットのページ・エントリに対するページ・コールをすべてエレメントから削除する必要があります。CSElementアセットを削除する前に、そのアセットのルート・エレメントに対するエレメント・コールをすべて他のエレメントから削除する必要があります。

アセットを削除すると、WebCenter Sitesでは次の操作が実行されます。

- Template表、CSElement表、またはSiteEntry表(アセット・タイプによって異なる)のアセットのname列の値を、そのオブジェクトIDに変更します。

- Template表のアセットのstatus列の値を、voidを示すVOに変更します。

- テンプレートの場合、SiteCatalog表のすべてのエントリ(テンプレートが共有されている場合は、テンプレートの共有対象となるサイトの数のページ・エントリが存在する)と、そのテンプレートに対するElementCatalog表エントリを削除します。

- CSElementの場合、アセットに対するElementCatalog表エントリを削除します。

アセットの削除の基本的な手順は、『Oracle WebCenter Sitesの管理』を参照してください。

18.7.5 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー

テンプレート、CSElementおよびSiteEntryの各アセットは他のアセットを書式設定するためのロジックとコードを提供するため、これらのタイプのアセットは、コンテンツ・アセットのプレビューとは別の方法でプレビューします。

18.7.5.1 テンプレートとプレビュー

テンプレートをプレビューするには、アセットをプレビューし、アセットのレンダリングに使用するテンプレートを選択します。WebCenter Sitesはテンプレート内のコードを起動し、アセットをコンテンツとして使用してページをレンダリングします。

18.7.5.2 CSElementアセットとSiteEntryアセットおよびプレビュー

CSElementアセットとSiteEntryアセットは直接プレビューします。コールされるエレメントに自己完結型コンテキストが含まれている場合、バナーでは変数や引数が期待されません。単に、「プレビュー」アイコンをクリックできます。ただし、レンダリングされたエレメントの結果が渡される値によって異なる場合には、アセットをプレビューするために、その値をCSElementフォームまたはSiteEntryフォームで設定する必要があります。

たとえば、FiscalNews/Query/ShowHotTopicsという名前のCSElementアセットは、p変数の値を期待します。値を受け取らなかった場合、pの値のデフォルト値はHomeページ・アセットのオブジェクトIDになります。Homeページ以外のページ・アセットに対してこのCSElementをプレビューするには、そのCSElementアセットに対して、「新規」フォームまたは「編集」フォームの引数フィールドを使用してページ・アセットのIDをp変数の値として渡す必要があります。

CSElementアセットまたはSiteEntryアセットをプレビューする際に引数値を指定する手順:

1. アセットを検索し、「調査」アイコン(文字「i」)をクリックして調査します。

2. 「調査」フォームの下までスクロールします。「引数を使用したプレビュー」の横の「プレビュー」をクリックします。

3. 引数の値を入力します。各フィールドをダブルクリックして、ドロップダウン・リストから選択する方法で値を選択することもできます。

4. 「プレビュー」をクリックします。

5. このSiteEntryアセットによりレンダリングされたページのプレビューのために表示されるリンクをクリックします。

18.8 Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集

注意:

エレメント・ロジックをOracle WebCenter Sites Explorerから直接作成または編集することはお薦めできません。ただし、そうするほうが優先される場合は、テンプレート・アセットおよびCSElementアセットの有効性を確認する必要があります。この項の情報をメモして、その中に含まれている指示に従ってください。

WebCenter Sitesインタフェース(「テンプレート」フォームまたは「CSElement」フォーム)でテンプレート(CSElement)アセットを作成および保存すると、Oracle WebCenter Sites Explorerの使用時には実行されない、いくつかの重要な手順が実行されます。

- このインタフェースでは、構成の依存性を設定するスタブ・コードをエレメントにシードし、JSPを使用している場合は、適切なタグ・ライブラリ・ディレクティブにエレメントをドロップします。構成の依存性については、「依存性について」で説明します。

- WebCenter Sitesインタフェースでテンプレート(CSElement)を保存すると、次の操作が行われます。

- アセットが変更されたという情報を承認システムが受信するため、アセットの承認ステータスが変更可能になります。

- 最も重要なこととして、CacheManagerサーブレットがキャッシュを更新できます(つまり、WebCenter SitesキャッシュおよびSatellite Serverキャッシュからページとページレットをフラッシュできます)。

Oracle WebCenter Sites ExplorerでCSElementアセットを使用するように指定した場合は、eid変数の値を変更したり、誤って削除しないようにしてください。

WebCenter Sitesインタフェースを使用する実際的な理由は、(テンプレート共有およびサイト・レプリケーションをサポートするために)特にアセット情報をマップしている場合に、WebCenter SitesとOracle WebCenter Sites Explorer間での切替えを回避するためです。マッピングはWebCenter Sitesインタフェース(「テンプレート」フォームの「マップ」画面、および「CSElement」フォームの「マップ」画面)のみでサポートされています。

この項には次のトピックが含まれます:

- テンプレートとCSElementの作成

- テンプレートとCSElementの編集

18.8.1 テンプレートとCSElementの作成

Oracle WebCenter Sites Explorerによるエレメント・ロジックのコーディングを優先させる場合は、次の手順を実行します。

1. 「テンプレート」フォーム(または「CSElement」フォーム)を使用してテンプレート(またはCSElement)アセットの作成を開始します。「「テンプレート」フォームを開く」(または「「CSElement」フォームを開く」)から始めて、順番に手順を実行します。

2. 「テンプレートのエレメントの構成」(または、「エレメントの構成」)で、エレメント・タイプ(JSP、XMLまたはHTML)を選択します。自動生成されたエレメント・ロジックは変更しないでください。また、tid変数の値を変更したり、誤って削除しないようにしてください。

3. 選択したフォームを使用して、終了するまで続行します。マップする必要のあるキーとアセット値が判明している場合は、それらを「マップ」フォームに追加します(「マップの構成」)。同じ手順がCSElementアセットにも適用できます)。

4. アセットを保存します。

5. Oracle WebCenter Sites Explorerを開き、エレメントを編集します。変更を保存します。

6. 最後の手順では、「テンプレート」フォーム(または「CSElement」フォーム)でアセットを再度保存します。フォームでデータを変更する必要はありませんが、再度保存する必要があります。こうすることで、機能が迂回されなくなります。

18.8.2 テンプレートとCSElementの編集

Oracle WebCenter Sites Explorerツールでエレメントのロジックを編集する場合は、常にテンプレート(またはCSElement)をWebCenter Sitesインタフェースで開いて保存します(これは、(1)アセットが変更されたことを承認システムが認識し、アセットの承認ステータスを変更できるようにするため、および(2) CacheManagerサーブレットがキャッシュを更新できるようにするためです)。

19 テンプレートとラッパーの作成

この章では、Webサイトを実装する際のテンプレートとラッパーの標準的な使用方法について説明します。

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

- テンプレートの使用

- ラッパーの使用

19.1 テンプレートの使用

この項では、次の3つのタイプのテンプレートについて説明します。

- レイアウト・テンプレート

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

- ページ・テンプレート

19.1.1 レイアウト・テンプレート

レイアウト・テンプレートは、「使用」フィールドが「エレメントはレイアウトとして使用されます。」に設定されているテンプレート・アセットです。レイアウト・テンプレ－トはタイプ付きまたはタイプなしになります(タイプ付きアセットとタイプなしアセットの詳細は、「テンプレート・アセットの作成」を参照)。

レイアウト・テンプレートの3つの主要特性は、次のとおりです。

- レイアウト・テンプレートはブラウザから起動可能

- レイアウト・テンプレートはアセットに割当て可能

- レイアウト・テンプレートは通常、Webページ全体をレンダリングする

この項ではそれぞれの特性を詳述し、複数のセクションにわたって使用するユースケース・シナリオを提供して、それぞれの概念を示します。また、「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」する方法も説明しています。

19.1.1.1 レイアウト・テンプレートはブラウザから起動可能

レイアウト・テンプレートのページ名が指定されると、Satelliteサーブレットをコールし、コンテンツのアセット・タイプ(c)およびアセットID (cid)と一緒にページ名を渡すことによってWebページが取得され、レンダリングが行われます。

http://localhost:8080/cs/Satellite?pagename=
<template_pagename>&c=Article&cid=1234567

指定されたテンプレートに対応するページ名を検索するには、テンプレート・アセットを調査し、「サイト・エントリ」フィールドのSiteCatalog Pagename列を参照します。

19.1.1.2 レイアウト・テンプレートはアセットに割当て可能

すべてのコンテンツ・アセットにはテンプレート・メタデータがあります。このメタデータは、「コンテンツ」タブを選択して表示できます。このフィールドでは、テンプレート名が格納されます。可能な値として、アセット・タイプやサブタイプに適用可能なすべてのレイアウト・テンプレートがあります。

図19-1 コンテンツ・アセットとテンプレート・メタデータ

WebCenter Sitesでは、Oracle WebCenter Sites: ContributorインタフェースのWebモードでアセットを調査および編集する際、「テンプレート」フィールドを使用します。WebCenter Sitesは、割り当てられたレイアウト・テンプレートをデフォルトのテンプレートとして使用し、アセットをレンダリングします(これは、単にアセットをプレビューするのみの場合でもあります)。つまり、Webモードでアセットを使用する際に使用できるのはレイアウト・テンプレートのみです。プレビューする場合、レイアウト・テンプレートは必要ありません。詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー」を参照してください。

Webモードでは、(ツールバーまたはメニューバーから)レイアウト変更機能を使用し、テンプレート・ピッカーを使用してレイアウト・テンプレートをビジュアルに選択することによって、デフォルトのレイアウト・テンプレートを割り当てることもできます。いずれの場合でも、アセットの「テンプレート」フィールドの値は変更されます。

図19-2 ページ・レイアウトの変更ダイアログ

19.1.1.3 レイアウト・テンプレートは通常、Webページ全体をレンダリングする

標準のWebページは、ドキュメント内に区画(通常は次の図に示すように、ヘッダー、フッター、サイド・バーおよびメイン領域)を定義するために<DIV>エレメントを使用して、HTMLコードで作成されます。

図19-3 サンプルのレイアウト・テンプレート

ヘッダー、フッター、サイド・バーおよびメイン領域を持つ標準的なWebページを示す次の例では、avisportsサンプル・サイトで使用するHTML構造が使用されています。

<!DOCTYPE html>
<html>
<head>
</head>
<body class="inner">
<div id="main">
<div id="header">
<!--contains the top menu bar -->
</div>
<div id="container">
<div class="content">
<!--contains the main area -->
</div>
<div class="side-bar">
<!--contains the side nav bar -->
</div>
</div>
<div id="footer">
<!--contains the footer -->
</div>
</div>
</body>
</html>

実際のJSPページには、タグ・ライブラリ・ディレクティブ、開始と終了の<cs:ftcs>タグ、およびキャッシュ・マネージャが使用する<render:logdep>タグが含まれています。詳細は、「タグ・テクノロジを使用したWebサイト開発」を参照してください。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld" %>

<cs:ftcs>
<!DOCTYPE html>

<%
// The render:logdep tag is mandatory. It allows the cache manager
// to automatically flush any page/pagelet generated using this
// template ("tid" is automatically populated with the Template
// asset id)
%>

<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template" />

<html>
<head>
</head>
<body class="inner">
<div id="main">
<div id="header">
<!--contains the top menu bar -->
</div>
<div id="container">
<div class="content">
<!--contains the main area -->
</div>
<div class="side-bar">
<!--contains the side nav bar -->
</div>
</div>
<div id="footer">
<!--contains the footer -->
</div>
</div>
</body>
</html>
</cs:ftcs>

ドキュメントは、<cs:ftcs>タグで囲む必要があります。このタグは、WebCenter Sitesのコンテキストを作成して、開始と終了の<cs:ftcs>タグの内側に含まれているコードにWebCenter Sitesのタグが格納されることを、WebCenter Sitesに通知します。WebCenter Sitesは、これらのタグの外側にあるコードは一切認識しません。<cs:ftcs>タグおよび<render:logdep>タグの詳細は、「WebCenter Sitesタグの理解」を参照してください。

19.1.1.4 ユースケース1: 記事アセット用にレイアウト・テンプレートを作成

この項では、記事アセット用にレイアウト・テンプレートを定義します。

1. EclipseをWebCenter Sites Developer Toolsプラグインと同時に使用して、次の特性を備えたテンプレートをavisportsサンプル・サイトに新規作成します。

- サイト: avisports

- 名前: HelloArticleLayout

- アセット・タイプ: AVIArticle

- サブタイプ: Article

- エレメントの使用: エレメントがレイアウトとして使用されます。

- エレメント・タイプ: JSP

- ルート・エレメント: AVIArticle/HelloArticleLayout

- ストレージ・パス: AVIArticle/HelloArticleLayout.jsp

2. 次のJSPコードを使用します。

標準のavisportsヘッダーとフッター、およびヘッド・セクションをレンダリングするために、avisports用に作成済のコンポーネントをいくつか再使用していることに注意してください(これにより、avisportsスタイルシートをインポートできるようになります)。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld" %>

<cs:ftcs>
<!DOCTYPE html>

<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template" />

<html>
<head>
<!--inserts the standard avisports head -->
<render:calltemplate

tname="/Head"
args="c,cid"
style="element" />
</head>
<body class="inner">
<div id="main">
<div id="header">
<!--inserts the avisports navbar -->
<render:satellitepage
pagename="avisports/navbar" />
</div>
<div id="container" style="height: 350px">
<div class="content">
<!--contains the main area -->
</div>
<div class="side-bar" style="height: 300px">
<!--contains the side nav bar -->
</div>
</div>
<div id="footer">
<!--inserts the avisports footer -->
<render:callelement

elementname="avisports/footer" />
</div>
</div>
</body>
</html>
</cs:ftcs>

3. 新しいタブで任意の記事アセットを開きます。

4. HelloArticleLayoutテンプレートをアセットに割り当てます。図19-4のようなWebページが表示されます。

図19-4 サンプルのWebページ

コンテナとサイド・バーの<DIV>エレメントに一時的なスタイルをいくつか追加して、これらが表示されるようにしています。実際のコンテンツが含まれたときには、これらを削除します。

5. レイアウト・テンプレートにコードを追加して、実際のコンテンツがレンダリングされるようにします。このコードは、ヘッドライン、投稿日、関連イメージと本文の各フィールドをレンダリングします。属性値の詳細は、「アセット・モデルの理解」を参照してください。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>

<%@ taglib prefix="dateformat" uri="futuretense_cs/dateformat.tld"%>

<cs:ftcs>
<!DOCTYPE html>

<render:logdep
cid='<%=ics.GetVar("tid")%>'
c="Template"/>

<%
// load article content
%>
<assetset:setasset

name="article"
type='<%=ics.GetVar("c") %>'
id='<%=ics.GetVar("cid") %>' />

<%
// fetch the headline, relatedImage, and postDate attributes
// from the database
%>
<assetset:getmultiplevalues

name="article"
prefix="article">
<assetset:sortlistentry

attributename="headline"
attributetypename="ContentAttribute" />
<assetset:sortlistentry

attributename="relatedImage"
attributetypename="ContentAttribute" />
<assetset:sortlistentry

attributename="postDate"
attributetypename="ContentAttribute" />
</assetset:getmultiplevalues>

<%
// fetch the body attribute
// body has to be fetched separately, since it is a 'text'
// attribute, and the getmultiplevalues tag does not support
// 'text' attributes
%>
<assetset:getattributevalues

name="article"
listvarname="bodyList"
attribute="body"
typename="ContentAttribute" />

<%
// read the related AVIImage asset id
%>
<ics:listget
listname="article:relatedImage"
fieldname="value"
output="imageId" />

<%
// read the date value and format it
%>
<ics:listget
listname="article:postDate"
fieldname="value"
output="postDate" />

<dateformat:create
name="df"
datestyle="long" />

<dateformat:getdate
name="df"
varname="formattedDate"
valuetype="jdbcdate"
value='<%=ics.GetVar("postDate") %>' />

<html>
<head>
<!--inserts the standard avisports head -->

<render:calltemplate

tname="/Head"
args="c,cid"
style="element" />
</head>

<body class="inner">
<div id="main">
<div id="header">
<render:satellitepage
pagename="avisports/navbar" />
</div>
<div id="container">
<div class="content">
<div class="top-section section-title">
<h1>
<ics:listget
listname="article:headline"
fieldname="value" />
</h1>
<span class="date">
<ics:getvar name="formattedDate" />
</span>
</div>
<div class="article post">
<render:getbloburl
outstr="imageURL"
c="AVIImage"
cid='<%=ics.GetVar("imageId")%>'
field="largeThumbnail" />
<img class="photo left"
src='<%=ics.GetVar("imageURL")%>' />
<render:stream list="bodyList" column="value" />
</div>
</div>
<div class="side-bar" style="height: 300px">
<!--contains the side nav bar -->
</div>
</div>
<div id="footer">
<render:callelement elementname="avisports/footer" />

</div>
</div>
</body>
</html>
</cs:ftcs>

6. HelloArticleLayoutを使用してContributorインタフェースのWebモードでアセットを表示すると、図19-5に示すような記事詳細を載せたWebページがレンダリングされます。サイド・バーは意図的に空にしてあります。

図19-5 記事詳細を載せたサンプルのWebページ

19.1.2 ページレット・テンプレート

ページレット・テンプレートは「使用」フィールドが「エレメント」に設定されているテンプレート・アセットで、HTMLページ内で使用されます。

ページレット・テンプレートの特性は、次のとおりです。

- ページレット・テンプレートはブラウザから直接起動できない

- ページレット・テンプレートはアセットに割り当てできない

- ページレット・テンプレートはページ・フラグメントをレンダリングする

次の項では、それぞれの特性を詳述し、ユースケース例を引き続き拡張しています。また、「ユースケース2: ページレット・テンプレートの使用」についても説明しています。

19.1.2.1 ページレット・テンプレートはブラウザから直接起動できない

ページレット・テンプレートにはページ名がありますが、WCS URLを使用してブラウザから直接ページレット・テンプレートにアクセスしようとすると、403 HTTPエラー・コード(アクセス拒否)が表示されます。

19.1.2.2 ページレット・テンプレートはアセットに割り当てできない

アセットの「テンプレート」フィールドで使用できるのはレイアウト・テンプレートだけです。つまり、ページレット・テンプレートを使用してこれらのアセットを直接プレビューすることはできません。ただし、プレビュー・テンプレートを設定して、編集ユーザーがページレット・テンプレートを簡単にプレビューできる方法を提供することは可能です(詳細は、「ページ・テンプレート」を参照)。

19.1.2.3 ページレット・テンプレートはページ・フラグメントをレンダリングする

ページ・テンプレートは、Webページ全体ではなく、Webページ・フラグメントをレンダリングします。ページレット・テンプレートで再使用可能なページ・フラグメントをレンダリングすることが理想的です。たとえば、ページレット・テンプレートで図19-6のような記事概要ブロックをレンダリングできます。

図19-6 サンプルの記事概要ブロック

その後でレイアウト・テンプレートを使用して複数のページ・フラグメントをアセンブルし、完全なWebページを作成できます。再利用性を最大限に活かすために、ルック・アンド・フィールの観点から中立的なフラグメントをページレット・テンプレートで提供し、その際に、CSSスタイルシート・ルールを使用して見栄えを効果的に制御します(特定のフラグメントをどの位置に使用するかに基づき、明確なスタイルシート・ルールを適用するのみでレンダリングは異なってきます)。

19.1.2.4 ユースケース2: ページレット・テンプレートの使用

これまでの手順については、「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」を参照してください。

記事詳細をレンダリングするコードを複数のコンテキストで再使用する場合は、コードをレイアウト・テンプレートから抽出し、ページレット・テンプレートに変換することをお薦めします。

次の特性を備えたテンプレート・アセットを作成してみましょう。

1. EclipseをWebCenter Sites Developer Toolsプラグインと同時に使用して、次の特性を備えたテンプレートをavisportsサンプル・サイトに作成します。

- サイト: avisports

- 名前: HelloDetail

- アセット・タイプ: AVIArticle

- サブタイプ: Article

- エレメントの使用: エレメントをHTMLページ内で使用します。

- エレメント・タイプ: JSP

- ルート・エレメント: AVIArticle/HelloDetail

- ストレージ・パス: AVIArticle/HelloDetail.jsp

2. <div class="content">エレメント内で記事フィールド値を検索およびレンダリングするコードを抽出して、それを別個のJSPに変換します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>

<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="dateformat" uri="futuretense_cs/dateformat.tld"%>

<cs:ftcs>

<render:logdep
cid='<%=ics.GetVar("tid")%>'
c="Template" />

<assetset:setasset

name="article"
type='<%=ics.GetVar("c") %>'
id='<%=ics.GetVar("cid") %>' />

<assetset:getmultiplevalues

name="article" prefix="article">
<assetset:sortlistentry

attributename="headline"
attributetypename="ContentAttribute" />
<assetset:sortlistentry

attributename="relatedImage"
attributetypename="ContentAttribute" />
<assetset:sortlistentry

attributename="postDate"
attributetypename="ContentAttribute" />
</assetset:getmultiplevalues>

<assetset:getattributevalues

name="article"
listvarname="bodyList"
attribute="body"
typename="ContentAttribute" />
<ics:listget
listname="article:relatedImage"
fieldname="value"
output="imageId" />
<ics:listget
listname="article:postDate"
fieldname="value"
output="postDate" />
<dateformat:create
name="df"
datestyle="long" />
<dateformat:getdate
name="df"
varname="formattedDate"
valuetype="jdbcdate"
value='<%=ics.GetVar("postDate") %>' />

<div class="top-section section-title">
<h1>
<ics:listget
listname="article:headline"
fieldname="value" />
</h1>
<span class="date">
<ics:getvar name="formattedDate" />
</span>
</div>

<div class="article post">
<render:getbloburl
outstr="imageURL"
c="AVIImage"
cid='<%=ics.GetVar("imageId") %>'
field="largeThumbnail" />
<img class="photo left"
src='<ics:getvar name="imageURL" />' />
<render:stream list="bodyList" column="value" />
</div>
</cs:ftcs>

3. さらに、<render:calltemplate>タグを使用して起動したHelloDetailを利用するのみで、レイアウト・テンプレートを変更できます。

<html>
<head>
<render:calltemplate

tname="/Head"
args="c,cid"
style="element" />
</head>
<body class="inner">
<div id="main">
<div id="header">
<render:satellitepage
pagename="avisports/navbar" />
</div>
<div id="container">
<div class="content">
<render:calltemplate

tname="HelloDetail"
args="c,cid" />
</div>
<div class="side-bar" style="height: 300px">
<!-contains the side nav bar -->
</div>
</div>
<div id="footer">
<render:callelement

elementname="avisports/footer" />
</div>
</div>
</body>
</html>

19.1.3 ページ・テンプレート

ページ・テンプレートは、「使用」フィールドが「エレメントはHTMLページ全体を定義するため、外部から呼び出すことができます。」に設定されているテンプレート・アセットです。

ページ・テンプレートの特性は、次のとおりです。

- ページ・テンプレートはブラウザから起動可能

- ページ・テンプレートはアセットに割り当てできない

- ページ・テンプレートはプレビュー用に使用可能

この項では、それぞれの特性を説明し、ページ・テンプレートの実際の使用方法を示します。

19.1.3.1 ページ・テンプレートはブラウザから起動可能

レイアウト・テンプレートと同様に、ページ・テンプレートは、Satelliteサーブレットを通してpagenameを起動することによって、ブラウザでのWebページのレンダリングに使用できます。

19.1.3.2 ページ・テンプレートはアセットに割り当てできない

レイアウト・テンプレートのみが割当て可能です。つまり、編集ユーザーはContributorインタフェースの「Webモード」でページ・テンプレートを使用できないことになり、レイアウト・テンプレートを使用する必要があります。

19.1.3.3 ページ・テンプレートはプレビュー用に使用可能

編集ユーザーはアセットを表示できるのみであり、編集機能は含まれないという点で、アセットのプレビューはContributorインタフェースでWebモードを使用する場合と異なります。アセットをプレビューする場合、デフォルトでは、WebCenter Sitesはアセットの「テンプレート」フィールドに設定されたレイアウト・テンプレートを使用します。

「プレビュー・テンプレートの変更」ダイアログが表示されると、テンプレート・ピッカーは次の有効なオプションを表示します。

- 現在のアセットに適用できるすべてのレイアウト・テンプレート

- 現在のアセットに適用できるすべてのページ・テンプレート

レイアウト変更テンプレート・ピッカーとは異なり、別のプレビュー・テンプレートを選択しても、このテンプレートはアセットの「テンプレート」フィールドに割り当てられません。選択されたプレビュー・テンプレートを使用して現在のアセットがレンダリングされるのみです。

19.2 ラッパーの使用

ラッパーは通常は未キャッシュです。実際のレイアウト・テンプレートをレンダリングする前に実行される予定のビジネス・ロジックが含まれています。これは、セキュリティ・チェックの実装のためにセッション・データにアクセスしたり、設定するロケールを決定したり、フレンドリURLを逆アセンブルするといったアクションを実行する場合に役立ちます。ラッパーは通常、マークアップを一切レンダリングしません。

この項では、ラッパーについて次の内容を説明します。

- ラッパー・ページの作成

- ラッパーのプレビュー

19.2.1 ラッパー・ページの作成

ラッパーは、「ラッパー・ページ」フラグが「はい」に設定されている普通のSiteEntryアセットです。これにより、作成中のアセットがラッパー・ページとして指定されます。「いいえ」フラグを選択すると、「ページレットのみ」フィールドが表示されます。詳細は、「SiteEntryアセットの作成」を参照してください。

19.2.2 ラッパーのプレビュー

実装によっては、レイアウト・テンプレートを使用してアセットをレンダリングする前に、ラッパーを実行する必要もあります。アセットをプレビューする場合、またはContributorインタフェースのWebモードを使用している場合、WebCenter Sitesは、現在のサイトで少なくとも1つのラッパーが有効になっている場合に系統的にラッパーを実行します。

デフォルトのプレビュー・ラッパーが現在の編集サイトに対して構成されている場合、WebCenter Sitesでは、このラッパーが使用されます。そうでない場合は、リストに記載されている最初のラッパーが使用されます。複数のラッパーが使用可能な場合は、「表示」、「ラッパーを使用したプレビュー」を選択して、別のラッパーを変更できます。

WebCenter Sitesは、それぞれテンプレート・ページ名とレンダリング対象のアセットのタイプおよびIDを持つアセット・タイプ(c)とアセットID (cid)のパラメータを使用して、主にページ名を設定する最小限のプレビューURLをデフォルトで生成するため、プレビュー・モードでは、ラッパーは、レイアウト・テンプレートがWebページを正しくレンダリングするために追加の引数を必要とする場合に(たとえば、locale引数が実行できる場合がある)、特に役立ちます。

この場合は、必要に応じて追加の引数を設定し、レイアウト・テンプレートのレンダリングを進めることによって、プレビュー・ラッパーを定義できます。コールされるページ名は、childpagename変数で使用可能です。

<cs:ftcs>

<%
// establish appropriate values for required template arguments
%>
<ics:setvar name="foo" value="bar" />

<render:satellitepage
pagename='<%=ics.GetVar("childpagename")%>'
args="c,cid,foo" />

</cs:ftcs>
...

20 テンプレートおよびCSElementのエレメントのコーディング

この章では、テンプレート・アセットおよびCSElementアセット用に作成するエレメントのコーディング方法について説明します。エレメントは、コンテンツを指定、抽出および表示するコードを提供します。WebCenter Sitesシステムでは、コンテンツはアセットとして保管されます。したがって、エレメント内のXMLコードやJSPコードの多くは、適切なコンテキストの適切なアセットを指定し、そのアセットのデータを抽出および表示するために使用されます。

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

- 依存性について

- 依存性をログに記録するためのコーディングについて

- CSElementアセットとSiteEntryアセットのコール

- ベーシック・アセットを表示するエレメントのコーディング

- フレックス・アセットを表示するエレメントのコーディングについて

- フレックス・アセットを表示するテンプレートのコーディング

- ハイパーリンクのURLの作成

- エラー状態の処理

アセット自体の作成の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

20.1 依存性について

WebCenter Sitesシステムは、次の2種類の依存性を追跡し、それらに基づいて正確に機能します。

- 承認依存性。これらは承認済アセットをパブリッシュできるかどうかを決定する条件です。
承認システムは、アセットの承認時、そのアセットの承認依存性を計算します。同じく承認する必要のある依存アセットが存在する場合、親アセットはパブリッシュされません。

- 構成依存性。これらはページ構成の依存性を表します。これらは、アセットがレンダリングされるページおよびページレットと、そのアセットとの間の依存性であり、ページを再生成する必要があるかどうかを決定します。
WebCenter Sitesサーブレットは、ページをレンダリングする際に構成依存性をログに記録します。CacheManagerは、この依存性ログを調べて、キャッシュされたページをいつ再生成するのかを決定します。ディスクへのエクスポートのパブリッシュ方法は、この依存性ログを調べて、エクスポートされたページ・ファイルをいつ再生成する必要があるのかを決定します。

注意:

開発者はエレメントをコーディングする際、構成依存性が正確にログに記録されるようにする必要があり、静的サイトを設計している場合は、承認依存性が適切に設定されるようにする必要もあります。

この項には次のトピックが含まれます:

- パブリッシュ・システムと承認依存性

- ページの生成と構成依存性

20.1.1 パブリッシュ・システムと承認依存性

管理システム上で作業するパブリッシャ、エディタおよびコンテンツ・プロバイダは、ターゲット宛先にパブリッシュされるアセットを承認します。次にパブリッシュ・システムは、管理チームがWebCenter Sitesシステムに対して設定したスケジュールに従って、バックグラウンド・プロセスとして承認済アセットを自動的にパブリッシュします。

アセットをパブリッシュできるのは、そのアセットがすべての指定された承認依存性を満たしている場合のみです。つまり、すべての関連付けられたアセットが承認済であるか事前にパブリッシュされている必要があります。そうでない場合は、それらの依存性が満たされるまで、つまり依存(関連)アセット自体が同じ宛先へのパブリッシュについて承認されるまで、そのアセットのパブリッシュは保留されます。

この承認プロセスが実行されることで、コンテンツ・チームと編集チームは、アセットの依存性を手動で確認してから大量の関連アセットをパブリッシュするという作業から解放されます。また、アセットのパブリッシュ後にオンライン・サイト上に壊れたリンクが存在している可能性もなくなります。

その後アセットが変更されると、そのアセットは承認済とは見なされなくなるため、再パブリッシュ可能にするには再び承認する必要があります。

この項には次のトピックが含まれます:

- 承認依存性の計算

- Exists、ExactおよびNone

- ディスクへのエクスポート用の承認テンプレート

- サブタイプ、フレックス定義および承認テンプレート

20.1.1.1 承認依存性の計算

承認依存性は、対象アセットの承認時に記録されます。これらの承認依存性は、WebCenter Sitesデータベース内のApprovedAssetDeps表に書き込まれます。

アセットの承認ステータスは、そのアセットの依存性および関連付けられたアイテムの依存性によって決定されます。前者の依存性には、特定のアセット・アイテムと関連付けられたすべてのアセット・アイテムの承認ステータスが含まれます。

依存性の計算は、パブリッシュ方法に依存します。

- ディスクへのエクスポートの場合は、承認システムは、対象アセットに割り当てられたテンプレート、またはそのタイプのアセットのデフォルト承認テンプレート(指定されている場合)を使用して、そのアセットをレンダリングします。テンプレート・コード内のタグによって、承認済アセットの適切な依存アセットを決定する承認依存性が設定されます。現在のアセットをパブリッシュするためには、これらの依存アセットが適切な承認状態になっている必要があります。

- サーバーへのミラーリングまたはXMLへのアセットのエクスポートの場合は、承認プロセスはアセット・タイプ間のデータ関係を調べます。ベーシック・アセットはアソシエーションを持っています。フレックス・アセットはファミリ関係を持っています。これらの関係はどちらも、これらのパブリッシュ方法の承認依存性を作成します。たとえば、フレックス・アセットを承認した場合は、そのフレックス・アセットの親アセットが適切な承認状態になるまでは、そのフレックス・アセットはパブリッシュ・セッションの対象になりません。

20.1.1.2 Exists、ExactおよびNone

承認依存性は、exists、exactおよびnoneのいずれかです。この項では、それぞれの承認タイプについて説明します。

CSElementアセットとSiteEntryアセット、埋込みリンクと埋込みページレットおよびOracle WebCenter Sites: Engage訪問者データ・アセットの承認依存性タイプを変更することはできません。フレックス属性を除いて(フレックス属性の依存性タイプはその属性の作成時に設定する)、フレックス・ファミリ・アセット・タイプの承認依存性タイプも変更できません。ベーシック・アセット・タイプの場合、それらに関連付けられたアセットの承認依存性のタイプは、アソシエーション・フィールドの構成時に設定します。

使用しているパブリッシュ方法がディスクへのエクスポートの場合、ページのレンダリング時に構成依存性を設定するタグは、承認システムがアセットをパブリッシュできるかどうかを計算する際に承認依存性も作成します。記述するコードによって、他のアセット用に生成されたページレットに対する承認依存性が設定される場合は、承認タイプをexists、exactまたはnoneに設定できます。

注意:

様々なタイプのアセット間の関係によって作成される承認依存性のタイプについては、『Oracle WebCenter Sitesの管理』の「パブリッシュ」を参照してください。

exists

exists依存性の場合は、依存アセットがターゲット上に存在していることのみが必要であり、そのアセットのバージョンは問われません。exists依存性の場合は、子アセットが変化した場合でも(すなわちその子アセットが承認済でなくなった場合でも)、その子アセットが以前に承認されて同じ宛先にパブリッシュされていた場合は、承認済の親アセットをパブリッシュできます。

たとえば、次の手順では、コレクション・アセットは自身のランク付けされた子とのexists関係を持っています。

- あるコレクションとそのコレクションのランク付けされた記事すべてが承認されてターゲットにパブリッシュされます。

- ランク付けされた記事のいずれかが再び編集されますが、承認はされません。

- このコレクション全体が再び編集されて、承認されて、宛先にパブリッシュされます。
変更されたが承認されていない記事の前のバージョンが存在(exists)しているため、この記事が原因でこのコレクションのパブリッシュが保留されることはありません。

ただし、次の例では、自身の記事とのexists依存性を持つコレクションをパブリッシュできません。

- あるコレクションとそのコレクションのランク付けされた記事すべてが承認されますが、パブリッシュはされません。

- ランク付けされた記事のいずれかが再び編集されます。

編集された記事は宛先に一度もパブリッシュされなかったため、この記事はその宛先に対してまだ存在しておらず、したがってそのコレクションをパブリッシュできません。このコレクション・アセットは保留されて、このコレクションをパブリッシュするには、このコレクションと編集された記事の両方が承認される必要があります。

exists承認タイプは、一般にリンクに対して有用です。

exact

exact依存性の場合は、依存アセットとターゲット上のアセットのバージョンは一致している必要があります。異なるバージョンの承認済アセットであってはいけません。exact依存性の場合は、宛先上の子アセットのバージョンと親アセットのバージョンが一致しない場合は、親アセットをパブリッシュできません。

次の例では、ページ・アセットは自身の記事アセットとのexact依存性を持っています。

1. あるページ・アセットとそのアセットの記事アセットすべてが承認されて宛先にパブリッシュされます。

2. これらの記事のいずれかが再び編集されますが、再承認はされません。

3. このページ・アセットが編集されて再承認されます。
このページ・アセットは保留されて、WebCenter Sitesインタフェース上で生成されるフォームには、このページ・アセットをパブリッシュ可能にするために承認される必要のあるアセットのリストへのリンクが表示されます。このリストでは、編集されたが再承認されていない記事が表示されます。

4. 編集された記事が承認されます。
このページ・アセットは承認されているため、この時点でパブリッシュできます。この記事とページ・アセットのバージョン・スタンプが一致するからです。

5. このページ・アセットと関連付けられた別の記事アセットが編集されます。

6. このページ・アセットと編集された記事アセットの両方が再承認される必要があります。これら2つのバージョン・スタンプが一致しないからです。

- この記事は編集されたがまだ再承認されていないため、再承認される必要があります。

- このページ・アセットは、この記事の異なるバージョンに対する依存性に基づいてその前に承認されたため、再承認される必要があります。

exact承認タイプは、一般に埋込みコンテンツに対して有用です。

none

none依存性の場合は、依存アセットの承認状態にかかわらず、承認済アセットをパブリッシュできます。承認依存性タイプをnoneに設定するには、承認依存性を設定するタグにDEPTYPEパラメータを追加して、そのパラメータをnoneに設定します。

DEPTYPEのnoneという設定は、承認依存性のみに影響します。ディスクへのエクスポートのプロセスによってページが生成されてタグが呼び出されると、構成依存性がログに記録されます。ただし、承認システムが計算時にタグを呼び出すときは、承認依存性はログに記録されません。

20.1.1.3 ディスクへのエクスポート用の承認テンプレート

ディスクへのエクスポートのパブリッシュ方法を使用するパブリッシュの宛先に対してアセットが承認されると、承認システムはアセットに割り当てられたテンプレートを調査して、その依存性を判別します。

ただし、ディスクへのエクスポートによってアセットが実際にパブリッシュされる際に、必ずしもそのアセットに割り当てられているテンプレートが使用されるわけではありません。なぜでしょうか。なぜなら、別のエレメントのコードによって、特定のケースではそのアセットに別のテンプレートが使用されていると判断される可能性があるからです。

コンテキストに応じて様々なテンプレートでレンダリングできるアセットがあるサイトについて考えてみます。では、このアセットのパブリッシュを承認する場合、承認プロセスで依存性を判断するためにどのテンプレートを使用する必要があるでしょうか。それは、すべてのテンプレートの最も代表的な一連の依存性が含まれるテンプレートです。開発者は、各タイプのアセットのすべての考えられる依存性が含まれた特別なテンプレートを作成できます。

最も代表的な一連の依存性が含まれるテンプレートが、アセットに割り当てることを希望するテンプレートではない場合はどうでしょうか。その場合は、前者のテンプレートをそのタイプのアセットのデフォルト承認テンプレートとして設定してください。

デフォルト承認テンプレートは、アセット・タイプごとおよびパブリッシュ宛先ごとに設定できます。この機能にツリー内でアクセスするには、「管理」タブを選択し、次に「パブリッシュ」→「宛先」→「MyStaticDestinationName」,→「デフォルト・テンプレートの設定」を選択します。

注意:

サーバーへのミラーリングのパブリッシュ方法を使用している宛先上のアセット・タイプのデフォルト承認テンプレートを指定した場合は、そのテンプレートは、「アセットのステータス」画面でそのアセットをプレビューする際に使用されますが、そのアセットが承認またはパブリッシュされる際には使用されません。

20.1.1.4 サブタイプ、フレックス定義および承認テンプレート

静的サイト用にフレックス・アセットを使用している場合は、複数のデフォルト承認テンプレートをファミリ内のそのフレックス・アセット・タイプに割り当てることができます。フレックス定義ごとに異なるデフォルト承認テンプレートを指定できます。

ベーシック・アセットの場合は、サブタイプ機能を使用すると、1つのアセット・タイプのアセットをさらに細かくカテゴリ分けできます。この機能を使用して、他のなんらかの編成構成に基づいて、特定タイプのアセット用に複数のデフォルト承認テンプレートを割り当てることができます。

たとえば、スポーツ記事の承認テンプレートは、海外ニュース記事の承認テンプレートとはおそらく異なるでしょう。この場合は、記事アセット・タイプに対してスポーツのサブタイプと海外ニュースのサブタイプを作成してから、このアセット・タイプの各サブタイプに異なる承認テンプレートを割り当てることができます。

ベーシック・アセットのサブタイプは、通常はアセット・タイプの作成時にアセット記述子ファイル内で作成しますが、アセット・タイプの作成後にサブタイプが必要になった場合は、「一般的な管理」ツリー内の「管理」ノードの下の「アセット・タイプ」オプションを使用して作成します。サブタイプをアセットに割り当てるには、「新規」および「編集」アセット・フォームを使用します。前述のとおり、フレックス・アセットは、それらのフレックス定義というサブタイプを持っています。

ベーシック・アセットのサブタイプの構成の詳細、およびサブタイプ全般の詳細は、「ベーシック・アセット・タイプの設計」を参照してください。

20.1.2 ページの生成と構成依存性

構成依存性は、次のようないくつかの方法で記録されます。

- ディスクへのエクスポートのパブリッシュ方法は、ページをレンダリングするときに、構成依存性を適切なパブリッシュ表に記録します。そうすることで、再パブリッシュが必要になったときに、ディスクへのエクスポートのパブリッシュ方法は、どのアセットがパブリッシュ対象なのかに基づいて、再生成する必要のあるページを特定できます。つまり、これらのアセットを構成上の依存アセットとしてログに記録したすべてのページを生成します。

- WebCenter Sitesは、ページをレンダリングおよびキャッシュする際に、依存性をSystemItemCache表に記録します。この表の各行には、アセットのIDと、そのアセットがレンダリングされた生成済ページのIDまたはキャッシュ・キーが格納されています。

CacheManagerとページ・キャッシュ

CacheManagerは、WebCenter Sitesのページ・キャッシュを管理します。アセットが変更されると、SystemItemCache表を調べて、それらのアセットがレンダリングされたキャッシュ済ページを特定します。次に、SystemPageCache表を処理して、適切なページをフラッシュおよび再生成します。

CacheManagerは、WebCenter Sitesのページ・キャッシュに変更を加えた後に、その情報をWebCenter Sitesシステムに属しているすべてのSatellite Serverに通知するとともに、共存Satellite ServerおよびシステムにインストールされたすべてのリモートSatellite Serverにも通知します。その後、Satellite Serverアプリケーションは、Satelliteページ・キャッシュを更新します。

注意:

適切な権限を持っている場合は、SystemItemCache表とSystemPageCache表内のデータを調べることができますが、WebCenter Sitesデータベース内の他のシステム表と同様に、これらの表に格納されている情報は一切変更しないでください。

20.1.2.1 CacheManagerと動的パブリッシュ・セッション

CacheManagerは、サーバーへのミラーリングのパブリッシュ・セッション時にパブリッシュ・システムと連動します。サーバーへのミラーリングのパブリッシュ・セッションが終了すると、パブリッシュ・システムは、そのパブリッシュ操作の対象に含まれていたすべてのアセットのすべてのIDのリストを、宛先システム上のCacheManagerサーブレットに提供します。

CacheManagerは、そのリストをキャッシュ内のページについてログに記録された構成依存性と照合し、ページ・キャッシュからフラッシュして再生成する必要のあるページおよびページレットを特定します。その結果に応じてWebCenter Sitesのページ・キャッシュを更新してから、ページのリストを共存SatelliteサーブレットとリモートSatelliteサーブレットに送信します。そうすることで、これらのサーブレットはこれらと同じページをフラッシュして、新しいバージョンのページをWebCenter Sitesのページ・キャッシュから取得できます。

20.1.2.2 CacheManagerとプレビュー機能

アセットをプレビューする際は(開発システムまたは管理システム上で)、WebCenter Sitesインタフェースは、そのアセットのテンプレートのページ名を実行します。WebCenter Sitesは、そのページをレンダリングおよびキャッシュして、レンダリングされたページとそのアセットの間の構成依存性をログに記録します。

CacheManagerは、アセットの保存時にプレビュー対象ページのキャッシュ済バージョンを更新します。つまり、ユーザーが「保存」をクリックすると、CacheManagerはそのアセットのオブジェクトIDを、キャッシュ内のそれらのページについてログ記録された構成依存性と照合します。次に、ページ・キャッシュ内の適切なページをクリアおよびリフレッシュして、変更されたページに関する情報をSatelliteサーブレットに通知します。

20.2 依存性をログに記録するためのコーディングについて

エレメントのコーディング時には、依存性を正確にログに記録するコードを記述する必要があります。

構成依存性をログに記録するためのいくつかのタグが存在します。このタグが実行されると、WebCenter Sitesは、レンダリングされたページとアセットの間の依存性をSystemItemCache表に書き込むことで、この依存性情報をログに記録します。

ディスクへのエクスポートのパブリッシュ方法を使用している静的サイトの場合は、構成依存性をログに記録するタグは、承認依存性もログに記録できます。アセットが承認されると、承認システムはそのアセットをレンダリングして、そのアセットをパブリッシュできるかどうかを判断します。承認依存性タイプがnoneに設定されているタグを除いて、承認システムは、これらのタグの結果をApprovedAssetDep表に記録します。依存性タイプnoneの詳細は、「Exists、ExactおよびNone」を参照してください。

この項では、依存性をログに記録するタグをアルファベット順に紹介します。これらのタグおよび他のタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

この項には次のトピックが含まれます:

- ASSET.LOADおよびasset:load

- ASSETSET (assetset)タグ・ファミリ

- RENDER.GETPAGEURLおよびrender:getpageurl

- RENDER.LOGDEP (render:logdep)

- RENDER.FILTERおよびrender:filter

- RENDER.UNKNOWNDEPSおよびrender:unknowndeps

20.2.1 ASSET.LOADおよびasset:load

WebCenter SitesがASSET.LOADタグ(またはasset:load)を実行すると、ロードされたアセットの構成依存性が自動的にログに記録されます。次に例を示します。

<ASSET.LOAD TYPE="Page" NAME="target" FIELD="name" VALUE="Home"/>

このコード行は、Homeという名前のページ・アセットとこのアセットを表示しているレンダリングされたページの間の構成依存性をマークします。

承認依存性タイプの設定

ディスクへのエクスポートの宛先に対してアセットが承認されて、承認システムがこのタグをレンダリングすると、このタグによって、現在使用されているアセット間の承認依存性もログに記録されます。

デフォルトでは、ASSET.LOADの承認依存性はexactに設定されています。DEPTYPEパラメータを使用して、この依存性をexistsまたはnoneに設定できます。次に例を示します。

<ASSET.LOAD TYPE="Page" NAME="target" FIELD="name" VALUE="Home" DEPTYPE="exists"/>

20.2.2 ASSETSET (assetset)タグ・ファミリ

ASSETSETタグ・ファミリを使用して、1つ以上のフレックス・アセットのセットを作成できます。次のタグは、アセットセットを作成して、そのセット内のアセットの構成依存性を定義します。

ASSETSET.SETASSET and assetset:setasset
ASSETSET.SETEMPTY and assetset:setempty
ASSETSET.SETLISTEDASSETS and assetset:setlistedassets
ASSETSET.SETSEARCHEDASSETS and assetset:setsearchedassets

このアセットセット内のアセットがレンダリングされると、構成依存性がログに記録されます。

最初の3つのタグは、次の構成依存性を定義します。

- アセットセット内の各フレックス・アセットとレンダリングされたページの間の依存性。

- フレックス・アセットの親とレンダリングされたページの間の依存性。フレックス・アセットは自身のフレックス親アセットから値を継承するため、親に対する変更はその子であるフレックス・アセットへの変更を意味することがあり、その結果として、そのアセットを保持しているページの正確性が失われる可能性があります。

4つ目のタグassetset:setsearchedassetsは、検索状態の結果に基づいてアセットセットを作成します。検索状態は問合せであるため、このセット内のアセットのIDを予測することはできません。したがって、ASSETSET.SETSEARCHEDASSETSタグは、構成依存性をunknownとして定義します。構成依存性がunknownの場合は、対象ページは、ディスクへのエクスポートのパブリッシュ・セッションが実行されるたびに再生成される必要があり、サーバーへのミラーリングのパブリッシュ・セッションが終了するたびにページ・キャッシュ内で更新される必要があります(更新が必要かどうかにかかわらず)。

IDが変化しないアセットの固定セットを表している検索状態がある場合は、オプションのfixedlistプロパティをtrueに設定することで、そのアセットセット内のアセットの構成依存性を設定するようにWebCenter Sitesに指示します。

次に例を示します。

<assetset:setsearchedassets name=as assettypes=Products constrain=ss fixedlist=true />

この例では、asという名前のアセットセット内の各製品アセットとレンダリングされたページの間に構成依存性が存在することを定義しています。

アセット・セットと検索状態の詳細は、「アセットセット」および「検索状態オブジェクト」を参照してください。

20.2.2.1 承認依存性タイプの設定

静的サイト用にフレックス・アセットを使用している場合は、承認システムがassetsetタグを呼び出すと、承認依存性タイプはデフォルトでnoneに設定されることに注意してください。

この値をexistsまたはexactに変更するには:

- deptypeパラメータを使用します。次に例を示します。

<assetset:setsearchedassets name=as assettypes=Products constrain=ss fixedlist=true deptype=exists />

assetset:setsearchedassetsタグの承認タイプを設定することに意味があるのは、fixedlistパラメータがtrueに設定されている場合のみです。

20.2.3 RENDER.GETPAGEURLおよびrender:getpageurl

RENDER.GETPAGEURLタグは、BLOBではないアセットのURLを作成します。このタグは、承認(レンダリング)対象のアセットとこのタグで指定されているアセットの間のexists承認依存性をログに記録します(構成依存性ではありません)。したがって、このタグが依存性を作成するのは、パブリッシュ方法がディスクへのエクスポートである場合のみです。

この例では、記事ABCに割り当てられたテンプレートには次のコードが含まれています。

<RENDER.GETPAGEURL PAGENAME="<site_name>/Page/Home"
cid="Variables.pageid"
c="Page"
OUTSTR="referURL"/>

このコード部分は、URLを作成して(このURLはOUTSTRパラメータによって作成された変数に格納して返される)、cid変数で指定されたアセットと記事ABCの間のexists承認依存性をログに記録します。

その後、記事ABCが承認されたときに、cid変数で指定されたページが承認されるかすでにパブリッシュされている必要があります。そうでない場合は、記事ABCのパブリッシュは保留されます。

20.2.4 RENDER.LOGDEP (render:logdep)

場合によっては、コード側でアセットを実際にロードすることなく、そのアセットのデータを取得できることがあります。その場合は、render:logdepタグを使用して、必ず手動で構成依存性をログに記録してください。

例1

テンプレート・アセットまたは他のCSElementアセットからCSElementをコールする際は、実行するエレメント・ファイルを識別するためにそのアセットをロードすることはありません。かわりに、RENDER.CALLELEMENTタグまたはrender:callelementタグを使用して、名前を指定してそのエレメントを直接呼び出します。次に例を示します。

<render:callelement name=<site_name>/Common/HeaderText/>

asset:loadタグを使用してCSElementにアクセスしなかったため、CSElementアセットとこのアセットがレンダリングされるページの間の構成依存性は自動的にログに記録されません。かわりに、この構成依存性を手動で設定する必要があります。

各CSElementアセットのエレメントの先頭に、次のコード行を挿入します。

<render:logdep cid="Variables.eid" c="CSElement"/>

テンプレート・アセットのエレメントの先頭では、render.logdep文は次のようになります。

<render:logdep cid="Variables.tid" c="template"/>

WebCenter SitesインタフェースでCSElementフォームまたはテンプレート・フォームを使用してエレメントのコーディングを開始する場合は、WebCenter Sitesは、そのエレメントに自動的に追加するスタブ・コード内に、適切なrender:logdep文を自動的に挿入します。

例2

ベーシック・アセットの場合は、ASSET.LOADタグを親アセット(ベーシック・アセット)で使用してから、ASSET.CHILDRENタグを使用すると、子アセットをロードすることなく子アセットのデータにアクセスできます。この場合は、構成依存性をログに記録するためのRENDER.LOGDEP文を挿入する必要があります。

次に例を示します。

<ASSET.CHILDREN NAME="PlainListCollection" LIST="theArticles"
OBJECTTYPE="Article" ORDER="nrank" CODE=-/>
<LOOP LIST="theArticles">
<RENDER.LOGDEP cid="theArticles.id" c="Article"/>
...

20.2.4.1 承認依存性タイプの設定

ディスクへのエクスポートの宛先に対してアセットが承認されて、承認システムがこのタグを呼び出すと、このタグによって、そのアセットとレンダリングされたページの間のexact承認依存性が作成されます。

- 次の例のように、DEPTYPE引数を設定することにより、承認依存性タイプをexistsまたはnoneに変更できます。

<RENDER.LOGDEP cid="theArticles.id" c="Article" DEPTYPE="exists"/>

20.2.5 RENDER.FILTERおよびrender:filter

RENDER.FILTERタグは、問合せによって作成されたアセットのリストに対して使用します。このタグは、非承認アセットをリストまたは問合せから除外します。また、unknownという構成依存性も設定します。　(unknown構成依存性については、「RENDER.UNKNOWNDEPSおよびrender:unknowndeps」を参照してください。)

このタグを使用するのは、問合せ(コレクション・アセットや問合せアセットなど)によって返されたリスト内に非承認アセットが含まれている場合に、その問合せの結果に対する承認依存性を持つ承認済アセットのパブリッシュが保留されないようにする場合です。たとえば、コレクションに含まれている5つの記事のうち2つのみをパブリッシュできない場合でも問題ないように、エレメントに渡された任意の数の記事アセットの適切な形式設定を実行するようそのエレメントがコーディングされているとします。このタグは、非承認アセットを除外するようにディスクへのエクスポートに指示するため、非承認アセットが未パブリッシュのままでも、この問合せを使用しているページをパブリッシュできます。

このタグは、次の場所で使用することが考えられます。

- 問合せアセットのテンプレート

- コレクション・アセットのテンプレート

- SELECTTO文とEXECSQL問合せ

次に例を示します。

<RENDER.FILTER LIST="ArticlesFromWireQuery" LISTVARNAME="ArticlesFromWireQuery" LISTIDCOL="id"/>

20.2.6 RENDER.UNKNOWNDEPSおよびrender:unknowndeps

RENDER.UNKNOWNDEPSタグは、依存アセットが存在しているが、これらのアセットの出所が問合せであるかこれらのアセットが頻繁に変化するという理由で、これらのアセットのIDを予測できないことを通知します。このタグは、レンダリングされたページのunknownという構成依存性をログに記録します。このタグは、ディスクへのエクスポートのパブリッシュ方法については承認依存性を設定しません。

構成依存性がunknownに設定されている場合は、対象ページは、ディスクへのエクスポートのパブリッシュ・セッションが実行されるたびに再生成される必要があり、サーバーへのミラーリングのパブリッシュ・セッションが終了するたびにページ・キャッシュ内で更新される必要があります(更新が必要かどうかにかかわらず)。

注意:

再生成する必要があるページが多いほど、サイトのパブリッシュにかかる時間が長くなるため、このタグは慎重に使用する必要があります。

このタグは、依存アセットをまったく特定できないコーディング状況に対応するために使用します。たとえば、問合せは動的であるため、実行されるたびに異なる結果セットが取得される可能性があります。いずれかの種類の問合せ(問合せアセット、SELECTTO文、EXECSQLなど)を使用する場合は、RENDER.UNKNOWNDEPSタグを使用する必要があります。

20.3 CSElementアセットとSiteEntryアセットのコール

設計上の要件として、コード側でCSElementアセットまたはSiteEntryアセットをコールする必要がある場合は、そのアセット自体をロードする必要はありません。コーディングの観点からは、開発者の関心対象はアセットとしてのCSElementやSiteEntryではなく、そのアセットが表しているエレメント・エントリやページ・エントリのみです。したがって、コード側で、適切なタグを使用してそのエレメント・エントリやページ・エントリを直接呼び出すことができます。

CSElementが対応するSiteEntryアセットを持たない場合(つまり、そのCSElementの出力はコール側ページに対して設定されたキャッシュ基準に従ってキャッシュされる場合)や、この呼び出し時に別個のページレットが必要ない場合は、RENDER.CALLELEMENT (render:callelement)タグを使用して名前を指定してそのCSElementを呼び出します。次に例を示します。

<render:callelement name="FiscalNews/Common/SetHTMLHeader"/>

CSElementが対応するSiteEntryアセットを持っている場合は、RENDER.SATELLITEPAGE (render:satellitepage)タグを使用してそのSiteEntryアセットのページ名をコールすることで、そのエレメントを呼び出します。次に例を示します。

<render:satellitepage pagename="FiscalNews/Pagelet/Common/SiteBanner"/>

注意:

Oracle WebCenter Sites Explorerを使用してSiteCatalogエントリとElementCatalogエントリを調査する場合、これらのエントリは、ページとページレットを視覚的に編成したフォルダおよびサブフォルダとして表示されます。ただし、これらのエントリは単なるデータベース表内の行であり、実際の階層は存在しません。そのため、コードでページ・エントリまたはエレメント・エントリをコールする場合は、常にフルネームを使用する必要があります。相対パスは使用できません。

また、コール先エレメントのチェーンは、20レベルより深くなってはいけません。20レベルより深い場合は、アセットを表示する際にシステムのパフォーマンスが低下します。

また、Oracle WebCenter Sites Explorerを使用して編集する場合は、アセットをそのアセットの編集フォーム(WebCenter Sitesインタフェース上)に保存することで、編集内容に応じてキャッシュが更新されるようにします。(Oracle WebCenter Sites Explorerはキャッシュを自動的に更新しません。)

20.4 ベーシック・アセットを表示するエレメントのコーディング

テンプレートのエレメントをコーディングするには、そのテンプレートによって形式設定されるアセット・タイプの設計を理解する必要があります。データ設計とサイト設計について事前に理解しておくことで、更新されたアセットを再表示するためにテンプレートを再コーディングする必要がなくなります。(そのために、この開発者ガイドではデータ設計とサイト設計の両方を扱っています。)

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

- ベーシック・アセット・タイプのテンプレートをコーディングする際に留意すべき情報を提供します。

- 様々な状況のコード部分とコード例を紹介します。これには、静的サイトについて承認を正しく計算できるように、および動的サイトについて適切なタイミングでページ・キャッシュをクリアできるように、アセット間の依存性を管理することが含まれます。

開始する前に、このガイドのプログラミングの基本に関する部分の各章、特に「タグ・テクノロジを使用したWebサイト開発」を必ず読んでください。

この章のコード例で使用されているタグについては、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

ベーシック・アセットを表示する他のコード例については、「ベーシック・アセットのテンプレート・エレメント例」を参照してください。

この項には次のトピックが含まれます:

- シンプルなコンテンツを表すアセット

- アソシエーション

- ImageFileアセットまたは他のBLOBアセット

- 埋込みリンクを保持できるベーシック・アセット

- コレクション

- 問合せアセット

- ページ・アセット

20.4.1 シンプルなコンテンツを表すアセット

コンテンツ・アセットのテンプレート・エレメントは通常、1つの特定の記事、広告コピー、特別オファー、イメージなどをデータベースから抽出した後、ヘッドライン、本文、署名行などの関連フィールドから情報を取得して、その情報をオンラインで表示します。

記事アセット用に設計された次のシンプルなテンプレート・エレメントについて見てみましょう。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Article/VeryBasic
-
- INPUT
- Variables.c - asset type (Article)
- Variables.cid - id of the asset to display
- Variables.tid - template used to display the page(let)
- OUTPUT
-
-->
<!-- log the template as a dependent of the pagelet being rendered, so changes to the template will force regeneration of the page(let) -->

<IF COND="IsVariable.tid=true">
<THEN>
<RENDER.LOGDEP cid="Variables.tid" c="Template"/>
</THEN>
</IF>
<!-- asset load will mark the asset as an 'exact' dependent of the pagelet being rendered -->

<ASSET.LOAD NAME="anAsset" TYPE="Variables.c" OBJECTID="Variables.cid"/>

<!-- get all the primary table fields of the asset -->

<ASSET.SCATTER NAME="anAsset" PREFIX="asset"/>

<!-- display the description -->
<ics.getvar name=asset:description/>

<!-- display the contents of the urlbody file -->

<ics.getvar name="asset:urlbody" encoding="default"
output="bodyvar"/>
<RENDER.STREAM VARIABLE="bodyvar" /><br/>

</FTCS>

このテンプレート内のこのコードは、次の処理を実行します。

- RENDER.LOGDEPタグを使用して、このエレメントによってレンダリングされるページとテンプレート・アセットの間の構成依存性をログに記録します。

- 承認システムがディスクへのエクスポートのターゲットについてこのコードを評価している場合は、承認依存性をログに記録します。

- ASSET.LOADタグを使用して記事アセットをロードします。このタグは、レンダリングされるページと記事アセットの間の構成依存性をログに記録します。

- ASSET.SCATTERタグを使用して、記事のすべてのフィールドからすべての値を抽出します。

- CSVARタグを使用して、description列のコンテンツを表示します。description列は、WebCenter Sitesインタフェース上の「新規」または「編集」記事フォーム内の「ヘッドライン」フィールドに対応しています。

- ics.getvarタグとRENDER.STREAMタグを使用して、urlbody列のコンテンツを表示します。urlbody列は、WebCenter Sitesインタフェース上の「新規」または「編集」記事フォーム内の「ヘッドライン」フィールドに対応しています。

description列の値を表示するコードと、urlbody列の値を表示するコードの違いに注意してください。urlbody列には埋込みリンクを格納でき、フィールドに埋込みリンクを格納できる場合は常に、CSVARタグではなくRENDER.STREAMタグを使用して、それらのリンクが正しくレンダリングされるようにします。

20.4.2 アソシエーション

アソシエーション・フィールドを通じて他のアセットと関連付けられているアセットを特定するには、ASSET.CHILDRENタグを使用します。関連付けられたアセットを指定するには、CODEパラメータを使用してアソシエーション・フィールドを指定します。

たとえば、前述のコード例の</FTCS>タグの直前に、次のコード部分が挿入されたとします。

<!-- display the Main Image -->
<ASSET.CHILDREN NAME="anAsset" LIST="associatedImage"
CODE="MainImage"/>
<IF COND="IsList.associatedImage=true">
<THEN>
<RENDER.SATELLITEPAGE PAGENAME="FiscalNews/ImageFile/TeaserSummary" ARGS_cid="associatedImage.oid"/>
</THEN>
</IF>

このコード部分は、次の処理を実行します。

- ASSET.CHILDRENタグと、MainImageという値に設定されたCODEパラメータを使用して、この記事アセット(anAssetという名前)のメイン・イメージ・フィールドで指定されたimagefileアセットを抽出します。

- RENDER.SATELLITEPAGEタグを使用して、そのimagefileのIDをTeaserSummaryテンプレートのページ・エントリに渡します。このページ・エントリはPAGENAMEパラメータで指定され、このimagefileはARGS_cidパラメータで指定されます。TeaserSummaryテンプレートは、このimagefileをページレット内にレンダリングして、そのページレットをこのページに渡して戻し、このページ上でこれが記事とともに表示されます。

20.4.3 ImageFileアセットまたは他のBLOBアセット

imagefileアセット・タイプには、アップロードされたイメージ・ファイルが格納されます。言い換えると、imagefileアセット・タイプは、WebCenter Sitesデータベースから提供されるバイナリ・ラージ・オブジェクト(Binary Large OBject: BLOB)です。イメージファイルなどのBLOBを提供および表示するには、BlobServerサーブレットを使用します。

imagefileなどのBLOBのテンプレート・エレメントは、RENDER.SATELLITEBLOBタグを使用して、そのBLOBにアクセスする方法とそのBLOBを形式設定して表示する方法をブラウザに指示するHTMLタグを作成して返すことができます。BlobServer URLのみが必要な場合は(そのURLがHTMLタグに埋め込まれない状態で)、RENDER.GETBLOBURLタグを使用できます。

BLOBへのリンクのコーディングの詳細は、「ハイパーリンクのURLの作成」を参照してください。

20.4.4 埋込みリンクを保持できるベーシック・アセット

記事アセットおよびTEXTAREAというデータ型のフィールドを持つ他のアセットの「本文」フィールドを使用して、エディタはテキスト・フィールド内の埋込みハイパーリンクを作成できます。これらのリンクが適切にレンダリングされるようにするには、次の例に示すようにRENDER.STREAMタグを使用してそのフィールドのコンテンツを取得できます。

<asset:load name="TestArticle" type="<%=ics.GetVar("c")%>"
objectid='<%=ics.GetVar("cid")%>' />
<asset:scatter name="MainArticle" prefix="articleAsset" />
<!-- display the contents of the urlbody file -->

<ics:getvar name="articleAsset:urlbody" encoding="default"
output="bodyvar"/>
<render:stream variable="bodyvar"/><br/>

管理システム上でWebモードが有効になっている場合は、insite:editタグは、埋込みリンクが含まれたフィールドのコンテンツを取得したときに、埋込みリンクを適切に管理します。

20.4.5 コレクション

コレクション・アセットのテンプレートは通常、ASSET.CHILDRENタグを使用してコレクション内のアセットをデータベースから抽出します。次に例を示します。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid"
NAME="PlainListCollection"/>
<ASSET.SCATTER NAME="PlainListCollection" PREFIX="asset"/>
<ASSET.CHILDREN NAME="PlainListCollection" LIST="theArticles"
OBJECTTYPE="Article"/>

子が特定された後に、テンプレート・コードは、これらのアセットの各部分をレンダリングされたページ上のリストに表示できます。

場合によっては、コレクションのテンプレートは、そのコレクション内の最初のアイテムを残りのアイテムとは異なる形で処理するようにコーディングされていることがあります。コレクション内の最上位ランクのアセットを選出するには、次のように、リスト内のアイテムをそれらのランクに従って順序付けするようにエレメントをコーディングします。

<ASSET.CHILDREN NAME="HomePageStories" LIST="theArticles"
OBJECTTYPE="Article" ORDER="nrank"/>

この項には次のトピックが含まれます:

- コレクション・テンプレートと承認依存性

- コレクション・テンプレートと構成依存性

20.4.5.1 コレクション・テンプレートと承認依存性

ディスクへのエクスポートのパブリッシュ方法を使用している場合は、コレクション・テンプレート内でRENDER.FILTERタグを使用できます。このタグは、承認依存性の計算時とパブリッシュ・プロセスによるサイトのレンダリング時に、すべての非承認アセットをコレクションから除外します。

次のコード部分は、このタグを示します。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid"
NAME="StoryListCollection"/>
<ASSET.SCATTER NAME="StoryListCollection" PREFIX="asset"/>
<ASSET.CHILDREN NAME="StoryListCollection" LIST="theArticles"
ORDER="nrank" CODE="-"/>

<!-- Get only the articles that are approved for export -->

<RENDER.FILTER LIST="theArticles"
LISTVARNAME="ApprovedArticles"
LISTIDCOL="oid"/>

<!-- Display only the articles that are approved-->

<IF COND="IsList.ApprovedArticles=true">
<THEN>
<LOOP LIST="ApprovedArticles">
<RENDER.SATELLITEPAGE
PAGENAME="<site_name>/Article/Summary"
ARGS_cid="ApprovedArticles.oid"
ARGS_p="Variables.p"/>
</LOOP>
</THEN>
</IF>

20.4.5.2 コレクション・テンプレートと構成依存性

RENDER.FILTERタグを例示している前述のコード例では、コレクション内の各子アセットのIDはSummaryテンプレートに渡されます。

Summaryテンプレート内の最初のコード行はASSET.LOAD文であるため、この文によってロードされる記事アセットとSummaryテンプレートによってレンダリングされるページの間の依存性はログに記録されます。

コレクション用のテンプレート内のコードによって子記事も書式設定される場合は、そのコードを慎重に検討して、RENDER.LOGDEPタグを使用して依存性をログに記録する必要があるかどうかを判断する必要があります。

たとえば、ASSET.CHILDRENタグ内でOBJECTYPEパラメータを使用している場合、次の例のように、得られるリストは、AssetRelationTree表と指定されたタイプのアセット表の結合になるため、両方の表内の情報を含んでいます。

<ASSET.CHILDREN NAME="StoryListCollection" LIST="theArticles"
OBJECTTYPE=Article ORDER="nrank" CODE="-"/>

その場合は、後続のASSET.LOADタグを使用することなく、子アセットの情報にアクセスできます。子アセットの情報にアクセスする場合は、必ずそれぞれの子のRENDER.LOGDEPタグを挿入してください。そうすることで、これらのアセットとレンダリングされたページの間の構成依存性を正しく追跡できます。

別の例については、「コレクション・アセット内の記事アセットへのリンクのコーディング」を参照してください。

20.4.6 問合せアセット

問合せアセットはSQLコードを実行することも、問合せコードが含まれたエレメントを実行することもできます。これらは、コレクションやページ・アセットなどのアプリケーションで使用します。

- コレクションを作成するには、「コレクションの作成」フォームで問合せを実行して、得られるリストから希望のアセットを選択して順序付けします。このコレクションは、この問合せの結果セットから選択されたアセットの静的リストです。

- ページ・アセット用の問合せは、名前なし関係またはアソシエーションのいずれかを通じて選択します。記事などのアセット用の問合せは、アソシエーションを通じて選択します。
これらのケースでは、ページ・アセットや記事アセット自体はその問合せを呼び出しません。したがって、OpenMarket/Xcelerate/AssetType/Query/ExecuteQueryという名前の標準WebCenter Sitesエレメントを呼び出すように、問合せテンプレート・エレメントをコーディングします。　このエレメントは、ページ・アセットや記事アセットのレンダリング時に問合せアセットを実行します。

問合せテンプレートのエレメントはExecuteQueryエレメントを呼び出し、通常は、その問合せによって作成されたリスト・オブジェクトに格納して返されるアイテムをループ処理するコードを含んでいます。このコードは、ループ処理を実行した後に、これらのアイテムから情報を抽出してから、その情報を表示します。

次の例では、問合せアセットをロードして、このアセットをExecuteQueryエレメントに渡します。

<ASSET.LOAD TYPE="Query" NAME="Wirefeed" OBJECTID="Variables.id"/>
<CALLELEMENT NAME="OpenMarket/Xcelerate/AssetType/Query/
ExecuteQuery">
<ARGUMENT NAME="list" VALUE="ArticlesFromWireFeed"/>
<ARGUMENT NAME="assetname" VALUE="WireFeed"/>
<ARGUMENT NAME="ResultLimit" VALUE="-1"/>
</CALLELEMENT>

問合せと構成依存性

ExecuteQueryエレメント内のコードの1行目に配置されたRENDER.UNKNOWNDEPSタグは、動的配信システム上のCacheManagerおよびディスクへのエクスポートのパブリッシュ方法に対して、この問合せによって取得されるアセットを予測できないこと、およびその結果として依存性を計算してログに記録できないことを通知します。

他の種類の問合せ(たとえば、SELECTTO文、CALLSQL、EXECSQL)を使用している場合は、RENDER.UNKNOWNDEPSタグを挿入してください。

また、次の例のように、ディスクへのエクスポートのパブリッシュ方法を使用している場合は、問合せによって生成されるアセット・リストが返される先となるエレメント内で、RENDER.FILTERタグを使用する必要があります。

<CALLELEMENT NAME="OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery">
<ARGUMENT NAME="list" VALUE="ArticlesFromTheQuery"/>
<ARGUMENT NAME="assetname" VALUE="PlainListQuery"/>
<ARGUMENT NAME="ResultLimit" VALUE="5"/>
</CALLELEMENT>

<!-- On export - filter out un-approved assets -->
<RENDER.FILTER LIST="ArticlesFromTheQuery" LISTVARNAME="ArticlesFromTheQuery" LISTIDCOL="id"/>

<if COND="ArticlesFromTheQuery.#numRows!=0">
<then>
<LOOP LIST="ArticlesFromTheQuery">
<RENDER.GETPAGEURL PAGENAME="FiscalNews/Article/
Variables.ct"
cid="ArticlesFromTheQuery.id"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>
<A class="wirelink" HREF="Variables.referURL"
REPLACEALL="Variables.referURL"><ics.listget listname=ArticlesFromTheQuery fieldname=subheadline/>
</A><P/>

別の例については、「問合せアセットのテンプレートのコーディング」を参照してください。

20.4.7 ページ・アセット

ページ・アセットのテンプレートには通常、次のタイプのコードが含まれています。

- そのページ・アセットのフレームワーク(そのページ・アセットがレンダリング対象ページである場合)

- レンダリング対象ページのコンテンツを取得するためのロジック

- 他のレンダリング対象ページへのリンクのロジック

コンテンツ・アセットのテンプレートには、個別のコンテンツの形式設定コードが含まれています。ページ・テンプレートは、他のアセットのテンプレートを呼び出して、形式設定されたアセットをこれらのテンプレート・エレメントから受け取ってから、これらの形式設定されたアセットをページ・フレームワークのコンテキスト内に配置します。

次に、ページ・アセットを形式設定するためのシンプルなテンプレートのコードを示します。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!-- Page/CollectionsAndQuery
-
- INPUT
- Variables.c - asset type (Page)
- Variables.cid - id of the asset to display
- Variables.tid - template used to display the page(let)
- OUTPUT
-
-->

<!-- log the template as a dependent of the pagelet being rendered, so changes to the template will force regeneration of the page(let) -->

<IF COND="IsVariable.tid=true">
<THEN>
<RENDER.LOGDEP cid="Variables.tid" c="Template"/>
</THEN>
</IF>

<!-- asset load will mark the asset as an 'exact' dependent of the pagelet being rendered -->

<ASSET.LOAD NAME="anAsset" TYPE="Variables.c"
OBJECTID="Variables.cid"/>

<!-- get all the primary table fields of the asset -->

<ASSET.SCATTER NAME="anAsset" PREFIX="asset"/>

<!-- get a list of id's of the child assets in the collection in order of their rank -->

<!-- get the WireFeed query -->

<ASSET.CHILDREN NAME="HomeTextPage" LIST="WireFeedStories"
CODE="WireFeed"/>
<IF COND="IsList.WireFeedStories=true">
<THEN>
<RENDER.GETPAGEURL PAGENAME="<site_name>/Query/WireFeedFrontText"
cid="WireFeedStories.oid"
c="Query"
p="Variables.asset:id"
OUTSTR="referURL"/>
<P>
<A HREF="Variables.referURL"
REPLACEALL="Variables.referURL">From the Wires...</A>

</P>
<RENDER.SATELLITEPAGE PAGENAME="<site_name>/Query/WireSummaryText"
ARGS_cid="WireFeedStories.oid"
ARGS_ct="WireStoryText"
ARGS_p="Variables.asset:id"/>
</THEN>
</IF>
</FTCS>

この例のコードは、次の処理を実行します。

- RENDER.LOGDEPタグを使用して、レンダリングされるページとテンプレート・アセットの間の構成依存性をログに記録します。

- ASSET.LOADタグを使用してページ・アセットをロードします。このタグは、レンダリングされるページと記事アセットの間の構成依存性をログに記録します。

- ASSET.CHILDRENタグと、WireFeedという値に設定されたCODEパラメータを使用して、WireFeed問合せを抽出します。

- RENDER.GETPAGEURLタグを使用して、WireFeed問合せから得られる記事を表示するページのURLを取得します。PAGENAMEパラメータは、そのページを作成するために使用するテンプレートのページ・エントリを指定するとともに、そのURLの一部を特定します。OUTSTRパラメータは、RENDER.GETPAGEURLによって作成されるURLを保持するための、referURLという名前の変数を作成します。

- referURL変数内のURLを使用して、そのページへの<A HREF>リンクを作成します。

- 問合せアセットのIDをWireSummaryTextテンプレートのページ・エントリに渡します。その後、WireSummaryTextテンプレートは、Wire Feed問合せによって返される各記事のサマリー・テキストを表示するページレットを作成して、そのページレットをこのページに渡して戻し、そのページレットがこのページ上で表示されます。

20.5 フレックス・アセットを表示するエレメントのコーディングについて

ベーシック・アセットのテンプレートをコーディングする際は、WebCenter SitesのASSETタグ・ファミリを使用します。たとえば、ベーシック・アセットを抽出して表示するには、ASSET.LOADタグを使用します。このタグは、そのアセット・タイプのプライマリ記憶域表からデータを抽出します。

フレックス・アセットのデータベース・スキーマはベーシック・アセットのデータベース・スキーマと異なるため、WebCenter Sitesでは、ASSETタグ群のかわりに使用する次のフレックス・アセット用タグ・ファミリが用意されています。

- ASSETSET: このタグ・ファミリを使用して、1つ以上のフレックス・アセットのセットを指定します。

- SEARCHSTATE: このタグ・ファミリを使用して、アセットセット内のアセットをフィルタリングする検索絞込み条件を作成します。

注意:

ASSET.LOADタグは、フレックス・アセットを自動的にロードします。ただし、ASSET.LOADタグをフレックス・アセットに対して使用することはサポートされていません。そのコードをアップグレードできず、アセットをこの方法で抽出すると、ASSETSETタグ・ファミリを使用する場合よりはるかに時間がかかるからです。

フレックス・アセット・モデルを使用してコンテンツを表す場合は、オンライン・サイトでは、フレックス・アセットとベーシック・アセットを組み合せて使用します。ページ・アセット・タイプ(使用される可能性が高い)はベーシック・アセット・タイプであるからです。

この項には次のトピックが含まれます:

- アセットセット

- 検索状態オブジェクト

- アセットセット、検索状態およびフレックス属性アセット・タイプ

- 有効範囲

20.5.1 アセットセット

アセットセットは、1つ以上のフレックス・アセットまたはフレックス親アセットのグループです。各種のASSETSETタグを使用して、アセットのセットを作成したり、表示する属性値を抽出したりします。

アセットセットから取得できる情報は次のとおりです。

- アセットセット内の各フレックス・アセットの1つの属性の値

- アセットセット内の各フレックス・アセットの複数の属性の値

- アセットセット内のフレックス・アセットのリスト

- アセットセット内のフレックス・アセットの数

- アセットセット内のすべてのフレックス・アセットの1つの属性の一意の属性値のリスト

- アセットセット内のすべてのフレックス・アセットの属性の一意の属性値の数

複数のタイプのフレックス・アセットが含まれたアセットセットを作成できますが、そのためには、それらのフレックス・アセットが同じフレックス属性アセット・タイプを使用している必要があります。

使用頻度の高いASSETSETタグは次のとおりです。

ASSETSET.SETASSET
ASSETSET.SETSEARCHEDASSETS
ASSETSET.GETMULTIPLEVALUES
ASSETSET.GETATTRIBUTEVALUES
ASSETSET.GETASSETLIST
ASSETSET.SORTLISTENTRY ...

すべてのASSETSETタグはOracle WebCenter Sitesタグ・リファレンスで説明されており、これらのうちいくつかはこの章のコード例で使用しています。構成依存性とASSETSETタグの詳細は、「ASSETSET (assetset)タグ・ファミリ」を参照してください。

20.5.2 検索状態オブジェクト

検索状態オブジェクトを使用すると、表示するフレックス・アセットのIDを取得できます。

検索状態は、フレックス・アセット・タイプの_Mungo表に格納されている属性値に基づいた一連の検索絞込み条件です。検索状態は、アセットセットに適用します。

検索状態を構築するには、検索状態によって記述されるフレックス・アセットのリストに対して、制約を追加して絞り込むか、または制約を削除して広げます。たとえば、照明器具を販売することが目的であるLightingサイトを運営している場合、検索状態を使用して、訪問者が製品カタログを参照するために使用するドリルダウン検索機能を作成できます。

絞込み条件が指定されていない検索状態をアセットセットに適用すると、そのタイプのすべてのアセットのフィルタリングされないリストが作成されます。たとえば、次のコード例では、Lightingサイトの製品カタログ内のすべての製品が含まれるアセットセットを作成します。

<SEARCHSTATE.CREATE NAME=nolimits/>
<ASSETSET.SETSEARCHEDASSETS NAME=unconstrainedAssetSet
CONSTRAINT=nolimits ASSETTYPES=Products/>

このアセットセット内の製品の数を絞り込むには、絞込み条件を追加します。たとえば、次のコード例では、カタログ内の40ワットの電球のみが含まれたアセットセットを作成します。

<SEARCHSTATE.CREATE NAME=lightbulbs/>
<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME=lightbulbs
ATTRIBUTE=wattage VALUE=40/>
<ASSETSET.SETSEARCHEDASSETS NAME=40WattLightbulbs
CONSTRAINT=lightbulbs ASSETTYPES=Products/>

絞込み条件とは、属性の値または別の検索状態(ネストされた検索状態)に基づいて設定できるフィルタ(制限)です。

検索状態は、そのアセット・タイプのデータベースの_Mungo表内を検索することも、そのアセット・タイプの検索エンジンによって作成された属性索引内を検索することもできます。つまり、データベース検索とリッチテキスト(索引を通じたフルテキスト)検索を同じ問合せ内に混在させることができます。検索エンジンの索引に対して絞込み条件を適用するには、SEARCHSTATE.ADDRICHTEXTCONSTRAINTタグを使用します。

注意:

SEARCHSTATEタグ・ファミリを使用するかわりに、SQLを使用してフレックス・アセットのデータベース表に対する問合せを実行することはサポートされていません。

使用頻度の高いSEARCHSTATEタグは次のとおりです。

SEARCHSTATE.CREATE
SEARCHSTATE.ADDSTANDARDCONSTRAINT
SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT
SEARCHSTATE.ADDRANGECONSTRAINT
SEARCHSTATE.ADDRICHTEXTCONSTRAINT
SEARCHSTATE.TOSTRING
SEARCHSTATE.FROMSTRING

すべてのSEARCHSTATEタグはOracle WebCenter Sitesタグ・リファレンスで説明されており、これらのうちいくつかはこの章のコード例で使用しています。

20.5.3 アセットセット、検索状態およびフレックス属性アセット・タイプ

検索状態は属性値に基づいて特定のアセットをフィルタリングし、アセットセットはデータベース内のアセットに検索状態を適用することで作成されるため、同じ属性アセット・タイプを共有しているフレックス・アセット・タイプのみを同じアセットセット内に含めることができます。

たとえば、フレックス記事アセット・タイプやフレックス・イメージ・アセット・タイプなどの2つのフレックス・アセット・タイプによって共有されるコンテンツ属性がサイトに含まれる場合、フレックス記事とフレックス・イメージの両方が含まれるアセットセットを作成できます。ただし、コンテンツ属性のかわりに製品属性を使用する製品アセット・タイプもこのサイトに含まれる場合、フレックス記事と製品アセットの両方が含まれるアセットセット、またはフレックス・イメージと製品アセットの両方が含まれるアセットセットを作成することはできません。

20.5.4 有効範囲

アセットセットと検索状態のスコープはローカルです。つまり、アセットセットと検索状態は現在のエレメント(レンダリング対象ページ)に対してのみ存在します。

既存の検索状態を維持するには、SEARCHSTATE.TOSTRINGタグを使用して、その検索状態を文字列に変換してから、その文字列を引数として次ページのURLに組み込みます。

次に例を示します。

<SEARCHSTATE.TOSTRING NAME=ss VARNAME=stringss/>
<RENDER.SATELLITEPAGE
pagename= SiteName/Products/Example
ARGS_search=Variables.stringss/>

次に、その文字列を受け取るこのサンプル・ページのルート・エレメント内で、次のように別の検索状態をコーディングします。

<SEARCHSTATE CREATE NAME=ss/>

次に、SEARCHSTATE.FROMSTRINGタグを使用して、サンプル・エレメントに渡された文字列を元の検索状態に復元します。

<SEARCHSTATE.FROMSTRING NAME=ss VALUE= Variables.search/>

20.6 フレックス・アセットを表示するテンプレートのコーディング

フレックス・アセット・モデルを使用するオンライン・サイトのテンプレートをコーディングする際は、開発者の主な関心対象はフレックス属性の値です(フレックス属性自体がアセットです)。

フレックス・アセット(製品など)やフレックス親アセットは、そのアセットを表示するコンテキストで考慮される場合は、実際には属性値を抽象化したものです。

検索状態を使用して、表示するフレックス・アセットのIDを取得して、考慮対象のアセットをそれらの属性値に基づいてフィルタリングします。その結果として、属性値に基づいたフレックス・アセットやフレックス親アセットのアセットセットが得られ、その後、このアセットセット内のアセットの属性値を表示できます。

フレックス・アセットのテンプレート・エレメントのコーディングを開始する前に、使用しているフレックス・ファミリのデータ・モデルを必ず理解してください。詳細は、「アセット・モデルの理解」および「フレックス・アセット・タイプの設計」を参照してください。

この項には次のトピックが含まれます:

- この項の例で使用するサンプル・データ・セット

- 1つの製品(フレックス・アセット)が含まれたアセットセットの例

- 特殊なケース: TEXT型、BLOB型およびURL型のフレックス属性

- 複数の製品(フレックス・アセット)が含まれたアセットセットの例

20.6.1 この項の例で使用するサンプル・データ・セット

この項のコード例は、小規模なデータ・セット例(これらの例の製品フレックス・ファミリ)とやり取りする簡単なアセットセットおよび検索状態から始まります。これらの例で使用する製品ファミリ・セットは、次のとおりです。

フレックス・アセット・タイプ

外部名(WebCenter Sitesインタフェースに表示されます)

内部名(WebCenter Sitesデータベースで使用されます)*

フレックス属性

製品属性

PAttributes

フレックス・アセット

製品

Products

フレックス親

製品親

ProductGroups

ASSETSETタグでASSETTYPESパラメータを使用する場合は、常にアセット・タイプの内部名を使用してください。

該当なし

該当なし

このデータ・セット内のサンプル製品は、次の属性を持つブルー・ジーンズです。

属性

データ型

値の数

sku

string

単一

color

string

複数

price

integer

単一

style

text

単一

次のように定義された4着のブルー・ジーンズがあります。

sku

color

price

style

jeans-1

blue

35

wide

jeans-2

blue、black

30

straight

jeans-3

black、green

25

straight

jeans-4

green

20

wide

20.6.2 1つの製品(フレックス・アセット)が含まれたアセットセットの例

この項のコード・サンプルでは次を実行します。

- sku番号で指定された1着のジーンズが含まれたアセットセットを作成します。

- 製品アセットとレンダリング対象ページ(またはページレット)の間の依存性をログに記録します。

- price属性の値を取得して表示します。

- color属性の値を取得して表示します。

- 同じタグ(ASSETSET.GETMULTIPLEVALUES)を使用して、price属性とcolor属性の両方の値を取得して表示します。

この項には次のトピックが含まれます:

- 検索状態の作成とアセットセットへの適用

- 製品の価格の取得

- 製品の価格の表示

- 製品の色の取得

- 製品の色の表示

- ASSETSET.GETMULTIPLEVALUESタグのリスト・オブジェクトの作成

- ASSETSET.GETMULTIPLEVALUESを使用した価格と色の両方の値の取得

- jeans-2製品の価格と色の値の表示

20.6.2.1 検索状態の作成とアセットセットへの適用

次のコード行は、ssという名前のフィルタリングされない検索状態を作成します。

<SEARCHSTATE.CREATE NAME="ss"/>

次に、サンプル・データ・セット内の特定の1つの製品が検出されるように、ssという名前のフィルタリングされない検索状態を絞り込みます。そのためには、その製品のskuを指定します。

<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME="ss" TYPENAME="PAttributes" ATTRIBUTE="sku" VALUE="jeans-2"/>

次に、asという名前のアセットセットを作成して、ssという名前の検索状態をこのアセットセットに適用します。

<ASSETSET.SETSEARCHEDASSETS NAME="as" ASSETTYPES="Products"CONSTRAINT="ss" FIXEDLIST="true"/>

sku属性の値は各製品アセットに対して一意です。そのため、このアセットセットには1つの製品(skuの値がjeans-2の製品)のみが含まれます。

この検索状態は、ハードコード化された属性値(jeans-2というsku値)を問い合せることで作成されたため、このassetsetの正確なコンテンツがわかります。これが、FIXEDLISTパラメータをtrueに設定した理由です。これで、ASSETSET.SETSEARCHEDASSETタグによって、この製品アセットの構成依存性がログに記録されるようになります。

20.6.2.2 製品の価格の取得

次に、このジーンズの価格を抽出します。

<ASSETSET.GETATTRIBUTEVALUES NAME="as" ATTRIBUTE="price" TYPENAME="PAttributes" LISTVARNAME="pricelist"/>

priceは単一値属性(つまり、この製品の価格は1つのみ)ですが、ASSETSET.GETATTRIBUTEVALUESタグは、price属性の値をリスト変数(LISTVARNAME=pricelist)として返します。

20.6.2.3 製品の価格の表示

次のコード行は、jeans-2製品の価格を表示できます。

Price: <ics.listget listname=pricelist fieldname=value/>
And this is the result:
Price: 30

20.6.2.4 製品の色の取得

次に、このジーンズで用意されている色を確認します。

前述のとおり、color属性は複数値属性です。ASSETSET.GETATTRIBUTEVALUESタグは、属性が単一値属性なのか複数値属性なのかにかかわらず同じように機能するため、ここでも、priceという単一値属性で使用したのとまったく同じ方法でこのタグを使用します。

<ASSETSET.GETATTRIBUTEVALUES NAME="as" ATTRIBUTE="color" TYPENAME="PAttributes" LISTVARNAME="colorlist"/>

20.6.2.5 製品の色の表示

次のコードは、jeans-2製品の色を表示できます。この製品には複数の色が用意されているため、このコードはリストをループ処理します。

Colors: <LOOP LIST="colorlist">
<ics.listget listname=colorlist fieldname=value/>
&nbsp;
</LOOP>

結果は次のようになります。

Colors: black blue

20.6.2.6 ASSETSET.GETMULTIPLEVALUESタグのリスト・オブジェクトの作成

一般に、複数の属性の値を取得するためには、ASSETSET.GETATTRIBUTEVALUESタグを使用しないでください。

ASSETSET.GETMULTIPLEVALUESタグは、アセットセット内のすべてのアセットについて、複数の属性の値を取得して分散します。このタグは、すべての属性値を対象にして1度のみデータベースをコールするため、複数のASSETSET.GETATTRIBUTEVALUESタグを使用する場合よりも効率的に問合せを実行できます。

ただし、このタグを使用する前に、LISTOBJECTタグを使用して、ASSETSET.GETMULTIPLEVALUESタグによって返される属性を表すリスト・オブジェクトを作成する必要があります。このリスト・オブジェクトは、取得する属性ごとに1つの行を必要とします。

次のコード行は、attributetypename、attributenameおよびdirectionという列がある、loという名前のリスト・オブジェクトを作成します。

<LISTOBJECT.CREATE NAME="lo"
COLUMNS="attributetypename,attributename,direction"/>

次のコード行は、colorとpriceという各属性の行を、このリスト・オブジェクトに追加します。

<LISTOBJECT.ADDROW NAME="lo" attributetypename="PAttributes" attributename="color" direction="none"/>
<LISTOBJECT.ADDROW NAME="lo" attributetypename="PAttributes" attributename="price" direction="none"/>

次のコード行は、このリスト・オブジェクトをlolistという名前のリスト変数に変換します。

<LISTOBJECT.TOLIST NAME="lo" LISTVARNAME="lolist"/>

20.6.2.7 ASSETSET.GETMULTIPLEVALUESを使用した価格と色の両方の値の取得

次に、asという名前の元のアセットセットからprice属性とcolor属性の両方の値を取得します。

<ASSETSET.GETMULTIPLEVALUES NAME="as" PREFIX="multi" LIST="lolist" BYASSET="false"/>

20.6.2.8 jeans-2製品の価格と色の値の表示

これらの値はリスト変数(lolist)に格納されているため、次のコードによってすべての属性のすべての値を表示できます。

<LOOP LIST="lolist">
<ics.listget listname=lolist fieldname=attributename output=attrName/>
<ics.getvar name=attrName/> is
<LOOP LIST="multi:Variables.attrName">
<ics.listget listname=multi:Variables.attrNamefieldname=value/>&nbsp;
</LOOP><P/>
</LOOP>

このコードは、lolist変数内のすべての属性をループ処理するネストされたループを構成してから、lolistリスト変数内の各属性のすべての個別属性値をループ処理します。

結果は次のようになります。

color is blue black
price is 30

20.6.3 特殊なケース: TEXT型、BLOB型およびURL型のフレックス属性

text型またはblob型のフレックス属性に保持されている値を表示するには、この項で説明している方法を使用します。

この項には次のトピックが含まれます:

- TEXT型のフレックス属性について

- BLOB型のフレックス属性について

- BlobServer URLの作成

- BLOBフレックス属性の値の取得および表示

20.6.3.1 TEXT型のフレックス属性について

ASSETSET.GETMULTIPLEVALUESタグは、text型の属性の値を取得しません。したがって、この型の属性を対象にした別個のASSETSET.GETATTRIBUTEVALUESタグを挿入する必要があります。

たとえば、これらの例で使用しているサンプル・データ・セット内のcolor属性が、string型ではなくtext型の属性であった場合は、これまでの例でASSETSET.GETMULTIPLEVALUESタグを使用してこの属性の値を取得できなかったはずです。

20.6.3.2 BLOB型のフレックス属性について

「アセット・モデルの理解」で説明したように、フレックス・アセット・タイプの_Mungo表には、そのタイプのフレックス・アセットの属性値が格納され、ASSETSETタグは、そのアセット・タイプの_Mungo表に対して属性値を問い合せます。

blob型の属性は例外です。

- WebCenter Sitesでは、blob型のすべての属性のすべての値がMungoBlobs表に格納されます。

- _Mungo表(たとえば、Products_Mungo)内のblob型属性の行には、MungoBlobs表内のその属性の値が保持されている行のIDのみが格納されます。つまり、_Mungo表内のblob列は、MungoBlobs表に対する外部キーです。

つまり、blob型の属性の場合、ASSETSET.GETATTRIBUTEVALUESタグとASSETSET.GETMULTIPLEVALUESタグは、そのBLOB属性の実際の値を返すのではなく、その値のIDを返します。

属性値のIDが特定されたら、そのIDを使用して次の2つのいずれかの操作を実行できます。

- そのIDを使用してBlobServer URLを取得できます。

- そのIDを使用してBLOBの実際の値を抽出できます。

20.6.3.3 BlobServer URLの作成

フレックス属性BLOBの値のBlobServer URLを取得するには、次の操作を実行します。

- BLOBSERVICEタグを使用して、プログラムによってMungoBlobs表とこの表内の適切な列の名前を取得します。

- URLをHTMLタグに埋め込む場合は、その名前をRENDER.SATELLITEBLOBタグに渡し、HTMLタグなしでURLのみが必要な場合は、その名前をRENDER.GETBLOBURLタグに渡します。

- 次の例に示すように、BLOBSERVICEタグを使用してプログラムによってMungoBlobs表の名前を取得します。この表の名前をコード内にハードコード化するかわりに、BLOBSERVICEタグを使用してこの値を取得することで、当製品の将来のバージョンでこの表の名前が変更された場合でも、コードが正しく機能します。
次のBLOBの例を紹介するために、次の属性をサンプル・データ・セット内のジーンズ製品に追加します。

属性

データ型

値の数

description

blob

単一

- 最初に、アセットセットを作成して、jeans-2製品とレンダリング対象ページの間の依存性をログに記録します。

<SEARCHSTATE.CREATE NAME="ss"/>
<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME="ss" TYPENAME="PAttributes" ATTRIBUTE="sku" VALUE="jeans-2"/>
<ASSETSET.SETSEARCHEDASSETS NAME="as" ASSETTYPES="Products" CONSTRAINT="ss"/>
<ASSETSET.GETASSETLIST NAME="as" LISTVARNAME="aslist"/>
<RENDER.LOGDEP cid="aslist.assetid" c="aslist.assettype"/>
The next line of code gets the ID of the jeans-2 asset's description attribute (that attribute of type blob) and stores it in a list variable called descFile
<ASSETSET.GETATTRIBUTEVALUES NAME="as" TYPENAME="PAttributes" ATTRIBUTE="description" LISTVARNAME="descFile"/>

- 次のコード行は、BLOBSERVICEタグを使用して、BLOB属性の属性値が格納されているWebCenter Sites表から表名と列名を取得し、それらをuTabname、idColumnおよびuColumnという名前の変数に格納します。

<BLOBSERVICE.GETTABLENAME VARNAME="uTabname"/>
<BLOBSERVICE.GETIDCOLUMN VARNAME="idColumn"/>
<BLOBSERVICE.GETURLCOLUMN VARNAME="uColumn"/>

- 次に、descFileというリスト変数と、uTabname、idColumnおよびuColumnという変数をRENDER.SATELLITEBLOBタグに渡します。このタグは、HTMLタグに埋め込まれたBlobServer URLを返します。

<RENDER.SATELLITEBLOB
BLOBTABLE="Variables.uTabname"
BLOBWHERE="descFile.value"
BLOBKEY="Variables.idColumn"
BLOBCOL="Variables.uColumn"
BLOBHEADER="application/pdf"
/> add service=a href ... download link...

RENDER.SATELLITEBLOBタグは、HREFタグに埋め込まれたBlobServer URLを返します。

20.6.3.4 BLOBフレックス属性の値の取得および表示

BLOBフレックス属性のIDが返された後に、このBLOBフレックス属性内のコンテンツまたはデータを取得して表示するには、BLOBSERVICE.READDATAタグを使用します。このタグは、そのBLOBのファイル名とURLデータをロードします。

- 前述のBLOBの例で使用したデータ・セットに関するものと同じ想定に基づいて、アセットセットを作成して、jeans-2アセットとレンダリング対象ページの間の依存性をログに記録して、description属性の値のIDを取得します。

<SEARCHSTATE.CREATE NAME="ss"/>
<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME="ss" TYPENAME="PAttributes" ATTRIBUTE="sku" VALUE="jeans-2"/>
<ASSETSET.SETSEARCHEDASSETS NAME="as" ASSETTYPES="Products" CONSTRAINT="ss"/>
<ASSETSET.GETASSETLIST NAME="as" LISTVARNAME="aslist"/>
<RENDER.LOGDEP cid="aslist.assetid" c="aslist.assettype"/>
<ASSETSET.GETATTRIBUTEVALUES NAME="as" TYPENAME="PAttributes" ATTRIBUTE="description" LISTVARNAME="descFile"/>

ここでは、BLOBSERVICE.READDATAタグを使用して、description属性の値(データ)を取得してから表示します。

<BLOBSERVICE.READDATA ID="descFile.value" LISTVARNAME="descData"/>
<ics.listget listname=descData fieldname=@urldata/>

20.6.4 複数の製品(フレックス・アセット)が含まれたアセットセットの例

この項のコード・サンプルでは次を実行します。

- この章で使用しているサンプル・データ・セット内のすべての製品(ジーンズ)が含まれたアセットセットを作成します。

- このアセットセット内のジーンズの数を取得して表示します。

- このアセットセット内のすべてのジーンズのcolor属性のすべての値を取得して表示します。

- このアセットセット内のジーンズのcolor属性とstyle属性のすべての値を取得して表示します。

- このアセットセット内のジーンズのすべての属性値を取得して表内に表示します。

- このアセットセットから特定の価格範囲に属するジーンズを抽出する検索絞込み条件を追加します。

- price属性に基づいたこの範囲制約を、bという文字で始まる色が用意されているジーンズをこのアセットセットから抽出する検索絞込み条件に置き換えます。

- この色制約を、blueまたはblackのどちらかが用意されているジーンズをこのアセットセットから抽出する絞込み条件に置き換えます。

この項には次のトピックが含まれます:

- 検索状態の作成とアセットセットへの適用

- アセットセット内のアセットの数の表示

- ジーンズで用意されている色の表示

- アセットセット内のジーンズの色とスタイルの表示

- すべてのジーンズとそれらの属性値を表示する表の作成

- 価格範囲に基づいたジーンズの検索

- 色のワイルドカードを使用したジーンズの検索

- 特定の色のジーンズの検索

20.6.4.1 検索状態の作成とアセットセットへの適用

次のコード行は、ssという名前のフィルタリングされない検索状態を作成します。

<SEARCHSTATE.CREATE NAME="ss"/>

フィルタリングされない検索状態をアセットセットに適用すると、指定されたタイプ(この例では製品アセット)のすべてのフレックス・アセットが取得されます。

<ASSETSET.SETSEARCHEDASSETS NAME="as" CONSTRAINT="ss" ASSETTYPES="Products"/>

20.6.4.2 アセットセット内のアセットの数の表示

次のコード行は、アセットセット内のアセットの数を返して表示します(この時点ではこの数はサンプル・カタログ全体を表します)。

<ASSETSET.GETASSETCOUNT NAME="as" VARNAME="count"/>
How many products are in the catalog?
<ics.getvar name=count/>

結果は次のようになります。

How many products are in the catalog? 4

20.6.4.3 ジーンズで用意されている色の表示

次のコード行は、ジーンズの各種の色を取得して表示します。つまり、color属性の重複しない値を取得して表示します。

<ASSETSET.GETATTRIBUTEVALUES NAME="as" ATTRIBUTE="color" TYPENAME="PAttributes" LISTVARNAME="colors"/>
What are the possible colors for any pair of jeans?<BR/>
<LOOP LIST="colors">
<ics.listget listname=colors fieldname=value/>
</LOOP><p/>

結果は次のようになります。

What are the possible colors for any pair of jeans?
black blue green

20.6.4.4 アセットセット内のジーンズの色とスタイルの表示

次に、このアセットセット内のジーンズのcolor属性とstyle属性の値を抽出して表示します。ここでは、ASSETSET.GETMULTIPLEVALUESタグを使用します。

ただし、最初に、ASSETSET.GETMULTIPLEVALUESタグによって返される結果セット用のリスト・オブジェクトを作成する必要があります。このリスト・オブジェクトは、次のように対象の属性ごとに1つの行を必要とします。

<LISTOBJECT.CREATE NAME="lo" COLUMNS="attributename,attributetypename,direction"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="color" attributetypename="PAttributes" direction="none"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="style" attributetypename="PAttributes" direction="none"/>

次のコード行は、このリスト・オブジェクトをlolistという名前のリスト変数に変換します。

<LISTOBJECT.TOLIST NAME="lo" LISTVARNAME="lolist"/>

次に、属性を抽出して、lolistという名前のリスト変数に格納します。

<ASSETSET.GETMULTIPLEVALUES NAME="as" LIST="lolist" PREFIX="distinct" BYASSET="false"/>

このコード行内のBYASSETパラメータに注目してください。このアセットセットには複数のアセットが含まれており、取得しようとしているのは、このアセットセット内の各アセットのすべての属性値ではなく、他と重複しない属性値であるため、BYASSET=falseと設定しています。このように設定することで、すべての属性値ではなく、一意の属性値のみを取得できます。

次のコード行は、リストをループ処理して、各属性の一意の値を表示します。

Here are all the possible colors:
<LOOP LIST="distinct:color">
<ics.listget listname=distinct:color fieldname=value/>
</LOOP><P/>

Here are all the possible styles:
<LOOP LIST="distinct:style">
<ics.listget listname=distinct:style fieldname=value/>
</LOOP><P/>

結果は次のようになります。

Here are all the possible colors: green blue black
Here are all the possible styles: wide straight

20.6.4.5 すべてのジーンズとそれらの属性値を表示する表の作成

ASSETSET.GETMULTIPLEVALUESタグを使用して、アセットセット内の各アセットについて重複しない属性値を取得することもできます。このタグは、すべての製品とそれらの属性値のリストを作成します。このリストを使用して、サンプル・カタログ内のすべての製品を表示するグリッドまたは表を作成できます。

この例では、次の2つの追加操作を実行する必要があります。

- 属性値をその所属先アセットに基づいてグループ化するために、BYASSETパラメータをtrueに設定する必要があります。

- この例では、アセットのIDが必要なため、ASSETSET.GETASSETLISTタグを使用してそれらのIDを取得する必要があります。

最初に、次のコードによってリスト・オブジェクトを作成します。

<LISTOBJECT.CREATE NAME="lo" COLUMNS="attributename,attributetypename,direction"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="color" attributetypename="PAttributes" direction="none"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="style" attributetypename="PAttributes" direction="none"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="price" attributetypename="PAttributes" direction="none"/>
<LISTOBJECT.ADDROW NAME="lo" attributename="sku" attributetypename="PAttributes" direction="none"/>
<LISTOBJECT.TOLIST NAME="lo" LISTVARNAME="lolist"/>

次に、属性値を取得します。

<ASSETSET.GETMULTIPLEVALUES NAME="as" LIST="lolist" PREFIX="grid" BYASSET="true"/>

次に、ASSETSET.GETASSETLISTタグを使用します。

<ASSETSET.GETASSETLIST NAME="as" LISTVARNAME="aslist"/>

このタグは、次の列が含まれたリストを返します。

- assettype

- assetid

両方のリストを使用して、すべての製品とそれらのすべての属性値を表示するグリッドを作成できます。

<TABLE>
<LOOP LIST="aslist">
<TR>
<TD><CSVAR NAME="grid:aslist.assetid:sku.value"/></TD>
<TD><CSVAR NAME="grid:aslist.assetid:price.value"/>
</TD>
<TD><CSVAR NAME="grid:aslist.assetid:style.value"/>
</TD>
<TD>
<IF COND="IsList.grid:aslist.assetid:color=true"><THEN>
<LOOP LIST="grid:aslist.assetid:color">
<CSVAR NAME="grid:aslist.assetid:color.value"/>&nbsp;
</LOOP>
</THEN></IF>
</TD>
</TR>
</LOOP>
</TABLE>

結果は次のようになります。

表20-1 すべてのジーンズとそれらの属性値を表示する表

jeans-1

35

wide

blue

jeans-2

30

straight

black blue

jeans-3

25

straight

black green

jeans-4

20

wide

green

20.6.4.6 価格範囲に基づいたジーンズの検索

ここまでは、この項の2行目のコードで作成された同じアセット(NAME=as)を使用してきました。次に、範囲制約を使用して、price属性に基づいてアセットセットをフィルタリングします。

次のコード行は、この項の1行目のコードで作成された元の検索状態(NAME=ss)に範囲制約を追加します。

<SEARCHSTATE.ADDRANGECONSTRAINT NAME="ss" ATTRIBUTE="price" TYPENAME="PAttributes" LOWER="0" UPPEREQUAL="30"/>

範囲は0から30です。変更した検索状態をアセットセットに適用します。

<ASSETSET.SETSEARCHEDASSETS NAME="as" CONSTRAINT="ss" ASSETTYPES="Products"/>

アセットセットに現在含まれているジーンズの数を取得して表示することで、この検索状態が正常に機能したかどうかを確認します。

<ASSETSET.GETASSETCOUNT NAME="as" VARNAME="count"/>
How many jeans products are less than or equal to $30?
<ics.getvar name=count/>

結果は次のようになります。

How many jeans products are less than or equal to $30? 3

20.6.4.7 色のワイルドカードを使用したジーンズの検索

ここで、price属性に基づいたこの範囲制約を、bという文字で始まる色が用意されているジーンズをこのアセットセットから抽出する検索絞込み条件に置き換えます。

最初に、次のコード行によって価格の範囲制約を削除します。

<SEARCHSTATE.DELETECONSTRAINT NAME="ss" ATTRIBUTE="price"/>

次のコード行では、VALUEパラメータでパーセンテージ(%)記号をワイルドカードとして使用して、色に関する新しい制約を追加します。

<SEARCHSTATE.ADDSIMPLELIKECONSTRAINT NAME="ss" ATTRIBUTE="color" TYPENAME="PAttributes" VALUE="b%"/>

VALUE="b%"文は、bという文字で始まる任意の色が対象になることを指定します。変更した検索状態を同じアセットセット(as)に適用します。

<ASSETSET.SETSEARCHEDASSETS NAME="as" CONSTRAINT="ss" ASSETTYPES="Products"/>

また、アセットセット内のジーンズの数を取得および表示することによって、これが機能していることを確認します。

<ASSETSET.GETASSETCOUNT NAME="as" VARNAME="count"/>
How many jeans have a color that begins with the letter b?
<ics.getvar name=count/>

結果は次のようになります。

How many jeans have a color that begins with the letter b? 3

20.6.4.8 特定の色のジーンズの検索

最後に、この色制約を、blueまたはblackのどちらかが用意されているジーンズをこのアセットセットから抽出する絞込み条件に変更します。

次のコード行によって色制約を検索状態から削除します。

<SEARCHSTATE.DELETECONSTRAINT NAME="ss" ATTRIBUTE="color"/>

次に、color属性の2つの値に基づいてフィルタリングするために、これらの値が含まれたリスト・オブジェクトを作成する必要があります。

<LISTOBJECT.CREATE NAME="lo" COLUMNS="value"/>
<LISTOBJECT.ADDROW NAME="lo" value="blue"/>
<LISTOBJECT.ADDROW NAME="lo" value="black"/>
<LISTOBJECT.TOLIST NAME="lo" LISTVARNAME="colorlist"/>

colorlistという名前のリスト変数を使用して検索状態を作成します。

<SEARCHSTATE.ADDSTANDARDCONSTRAINT NAME="ss" ATTRIBUTE="color" TYPENAME="PAttributes" LIST="colorlist"/>

LIST=colorlist文は、前述の例のVALUE文に相当しますこの文は、colorlistという名前のリスト内のいずれかの色と一致する属性値が対象となることを指定します。変更した検索状態を同じアセットセットに適用します。

<ASSETSET.SETSEARCHEDASSETS NAME="as" CONSTRAINT="ss" ASSETTYPES="Products"/>

また、アセットセット内のジーンズの数を取得および表示することによって、これが機能していることを確認します。

<ASSETSET.GETASSETCOUNT NAME="as" VARNAME="count"/>
How many products have a color that is black or blue?
<ics.getvar name=count/>

結果は次のようになります。

How many products have a color that is black or blue? 3

20.7 ハイパーリンクのURLの作成

動的サイトか静的サイトかにかかわらず、WebCenter Sitesシステムを使用しているということは、コンテンツが定期的に変化するということです。このため、URLをハイパーリンク内にハードコード化できません。ページは、ディスクへのエクスポートのパブリッシュ方法によってまたは動的サイト上の訪問者のブラウザによってレンダリングされる際に、そのページでリンクを提供している、対象のアセットのIDを特定できる必要があります。

WebCenter Sitesでは、URLを作成するために使用できる次の3つのタグが用意されています(それぞれのタグにはXMLバージョンとJSPバージョンがあります)。

- BLOBではないアセットのURLについては、RENDER.GETPAGEURLタグを使用します。

- BLOBであるアセットのURLについては、RENDER.SATELLITEBLOBタグまたはRENDER.GETBLOBURLタグを使用します。

この項には次のトピックが含まれます:

- RENDER.GETPAGEURL (render:getpageurl)

- RENDER.SATELLITEBLOB (render:satelliteblob)

- RENDER.GETBLOBURL (render:getbloburl)

- referURL変数の使用

20.7.1 RENDER.GETPAGEURL (render:getpageurl)

標準アセット(BLOBではないアセット)のURLを取得するには、RENDER.GETPAGEURLタグを使用します。

RENDER.GETPAGEURLタグは、このタグの起動元のエレメントから渡された引数をURLエンコードされた文字列に変換して、この文字列をOUTSTRパラメータで指定された変数として返します。慣例的に、この変数の名前はreferURLです。

rendermodeがexportに設定されている場合は、このタグは静的URLを作成します(ただし動的URLになるように指定している場合は除きます)。rendermodeがliveに設定されている場合、このタグは動的URLを作成します。

次に例を示します。

<RENDER.GETPAGEURL PAGENAME="FiscalNews/Article/Full
cid="Variables.cid"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

これで、referURL変数の値を使用して、<A HREF>タグ付きのハイパーリンクを作成できます。

このタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

20.7.2 RENDER.SATELLITEBLOB (render:satelliteblob)

WebCenter Sitesデータベースに格納されているバイナリ・ラージ・オブジェクト(BLOB)は、WebCenter SitesサーブレットではなくBlobServerサーブレットによって提供されます。RENDER.SATELLITEBLOBタグは、BlobServer URLが埋め込まれたHTMLタグを返します。

このタグは、BLOBを定義する一連の引数と、BLOBの形式設定方法を指定する追加の一連の引数を受け取ります。たとえば、このタグを使用して、次のように<IMG SRC>タグや<A HREF>タグを作成できます。

<RENDER.SATELLITEBLOB
BLOBTABLE=ImageFile
BLOBKEY=id
BLOBCOL=urlpicture
BLOBWHERE=Variables.asset:id
BLOBHEADER=Variables.asset:mimetype
SERVICE=IMG SRC
ARGS_alt=Variables.asset:alttext
ARGS_hspace=5 ARGS_vspace=5/>

blob型のフレックス属性のURLを作成する場合は、追加のコーディング手順が必要になることに注意してください。詳細は、「BLOB型のフレックス属性について」を参照してください。

Satellite Serverを使用していない場合でも、RENDER.SATELLITEBLOBタグを使用してください。このタグは、Satellite Serverが存在しない場合でも、HTMLタグに埋め込まれたBlobServer URLを作成できるからです。

このタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

20.7.3 RENDER.GETBLOBURL (render:getbloburl)

BlobServer URLのみが必要な場合は(そのURLがHTMLタグに埋め込まれない状態で)、RENDER.GETBLOBURLタグを使用します。

たとえば、SetHTMLHeaderという名前の次のエレメントは、RENDER.GETBLOBURLエレメントを使用して、BlobServer URL (referURL変数に格納)を取得してから、クライアント側で実行されるJavaScriptコードにこのBlobServer URLを渡して、訪問者が使用しているブラウザが特定されます。この場合は、クライアント側のJavaScriptは、検知したブラウザに基づいてHTMLタグを作成するため、HTMLタグなしのBlobServer URLを必要とします。

SetHTMLHeaderは、CSElementのエレメントです。これは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェースを使用して、path-name/SetHTMLHeader CSElementを検索して調べます。

- Explorerを使用してpath-name/SetHTMLHeaderエレメントを開きます。

blob型のフレックス属性のURLを作成している場合、追加のコーディング手順があります。詳細は、「BLOB型のフレックス属性について」を参照してください。

RENDER.GETBLOBURLタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

20.7.4 referURL変数の使用

RENDER.GETPAGEURLタグ、RENDER.GETBLOBURLタグおよびRENDER.SATELLITEBLOBタグは、当製品の3.6.xバージョンで導入されました。当製品のこれより前のバージョンでは、GetPageURLおよびGetBlobURLというエレメントを使用してURLを取得していました。これらのエレメントは、URLをreferURLという変数に格納して返すようにコーディングされています。

慣例的に、GetPageURLエレメントとGetBlobURLエレメントの後継として導入されたタグを使用しているサンプル・サイト内のすべてのサンプル・コードでは、URLの値を格納するためにreferURL変数が使用されています。

referURL変数の値や、RENDER.GETPAGEURLタグまたはRENDER.GETBLOBURLタグによって返される他のどの変数の値にも、テキストを一切追加しないでください。このタイプの変数に格納されているURLは完全なもの(URL全体)です。これらのタグによって返されるURLを変更した場合は、そのURLが壊れる可能性があります。

URLに追加の引数を含める必要がある場合は、RENDER.PACKARGSタグを使用してそれらの引数をURLエンコード(パック)してから、それらのエンコードされた引数をPACKEDARGSパラメータを通じてRENDER.GETPAGEURLタグまたはRENDER.GETBLOBURLタグに渡します。

RENDER.PACKARGSタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

20.8 エラー状態の処理

エレメントをコーディングする際に、エラー状態の有無をチェックするコードも含める必要があります。どのエラー状態が重大であるのかを決定して、必要に応じて、解決策や代替アクションをコーディングしてください。場合によっては、わかりやすいエラー・メッセージを記述することが解決策になります。追加のステップとして、壊れたページがキャッシュされることを防止するコードを含めることができます。

注意:

コードをデバッグする際は、commons-logging.propertiesファイルとloggingconfig.xmlファイルを使用してログ出力を有効にできます。これにより、エラー・メッセージとデバッグ・メッセージはWebCenter Sitesのログ・ファイルに書き込まれます。デバッグ・プロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

この項には次のトピックが含まれます:

- errno変数の使用

- 間違ったページのキャッシングの防止

20.8.1 errno変数の使用

標準のWebCenter Sites変数であるerrno変数には、WebCenter SitesのXMLタグやJSPタグによって報告されるエラー番号が格納されます。WebCenter Sitesのタグを正常に実行できない場合は、そのタグによって、その理由を最も適切に示す値にerrnoが設定されます。たとえば、-13004というerrno値は、CURRENCYタグが読み取ろうとした数値が正しい通貨形式でなかったために、その数値を読み取ることができなかったことを示します。すべてのerrno値のリストとそれらの説明については、Oracle WebCenter Sitesタグ・リファレンスのエラー状態に関する項を参照してください。

WebCenter Sitesのモジュールと製品で用意されているタグの実行前にerrnoがクリアされるため、これらのタグでエラーの有無をチェックする際に、errnoを0に設定する必要はありません。次のコード例では、子アセットのロードを試行する前にASSET.LOADが正常に実行されたかどうかを確認します。

<ASSET.LOAD NAME="topArticle" TYPE="Article"
OBJECTID="Variables.cid"/>
<IF COND="IsError.Variables.errno=false">
<THEN>
<ASSET.CHILDREN NAME="topArticle"
LIST="listOfChildren/>
</THEN>
</IF>

WebCenter Sitesで用意されているタグの結果をチェックするには、結果をチェックするタグの前に、errno値をクリアするコードを配置する必要があります。次に例を示します。

<SETVAR NAME=errno VALUE=0/>

次のコード例では、テンプレートの開発プロセス中に使用できるエラー・メッセージを示しています。

<IF rendermode=preview>
<THEN>
<IF COND=IsError.Variables.errno=true>
<THEN>
<FONT COLOR=#FF0000>
Error <ics.geterrno/>
while rendering <ics.getvar name=pagename/>
with asset ID <ics.getvar name=cid/>.
</FONT>
</THEN>
</IF>
</THEN>
</IF>

20.8.2 間違ったページのキャッシングの防止

エレメントの出力が間違っていると判断できる場合は、おそらくWebCenter SitesやSatellite Serverによってそのページがキャッシュされる必要はありません。ics.disablecacheタグを使用して、生成されるページがキャッシュされることを防止できます。

例1: エラー状態

「errno変数の使用」の1つ目の例の続きとして、記事アセットをロードできなかった場合は、そのページをキャッシュする理由もありません。そのコード例のIF条件に、次のELSE文を追加できます。

<ASSET.LOAD NAME="topArticle" TYPE="Article"
OBJECTID="Variables.cid"/>
<IF COND="IsError.Variables.errno=false">
<THEN>
<ASSET.CHILDREN NAME="topArticle"
LIST="listOfChildren/>
</THEN>
<ELSE>
<ics.disablecache/>
</ELSE>
</IF>

例2: アセットのステータスがVOの場合にキャッシュからページをクリア(ベーシック・アセットのみ)

「ページの生成と構成依存性」の「CacheManagerと動的パブリッシュ・セッション」で説明したように、宛先システム上のCacheManagerは、パブリッシュ・セッションの影響を受けたすべてのページとページレットを再生成します。これらの影響を受けたページには、削除された依存アセットが属するページも含まれます。

削除されたアセットのステータスはVOに設定されます。ASSET.LOADタグとasset:loadタグは、実行前にアセットのステータスをチェックしないため、削除されたアセットをロードでき、実際にロードします。通常は、このことは問題ではありません。なぜでしょうか。アセットに対する他のアセットからのすべてのリンクが削除されないかぎり、そのアセットを削除できないからです。したがって、サイトが再生成されたときには、削除されたアセットを表示するページやページレットへのリンクはもう存在しません。しかし、キャッシュ内の削除されたアセットを表示するページやページレットを残しておく必要はありません。

次のコード例は、アセットをロードできない場合やアセットのステータスが削除された場合は、ページがキャッシュされることを防止します。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="WireStoryTextArticle"/>
<!-- if the asset cannot be loaded, then flush the pagelet from cache -->
<if COND="IsError.Variables.errno=true">
<then>
<ics.disablecache/>
</then>
</if>
<ASSET.SCATTER NAME="WireStoryTextArticle" PREFIX="asset"/>
<!-- if the asset is marked as void, then flush the pagelet from cache -->
<if COND="Variables.asset:status=VO">
<then>
<ics.disablecache/>
</then>
</if>

フレックス・アセットのステータスをチェックするコードを含める必要はありません。SEARCHSTATEタグとsearchstateタグは、ステータスがVOのアセットを返しません。また、ASSETSETタグとassetsetタグは、ステータスがVOのアセットを、作成するアセットセット内に含めません。

21 コンテキスト内編集およびプレゼンテーション編集用テンプレートのコーディング

次の項では、コンテキスト内編集およびプレゼンテーション編集用のテンプレートのコーディングについて説明します。

- コンテキスト内コンテンツ編集用テンプレートのコーディング

- プレゼンテーション編集用テンプレートのコーディング

- Webモードでのコンテンツ作成の有効化

この章で使用する新しいタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

21.1 コンテキスト内コンテンツ編集用テンプレートのコーディング

注意:

コンテキスト内とは、Oracle WebCenter Sites: ContributorインタフェースのWebモードを意味します。

この項では、編集ユーザーが、標準コンテンツ・フォームを使用するかわりに、それぞれのWebサイトのコンテキストでコンテンツの編集または作成を行えるようにテンプレートをインストゥルメント化する方法を検討します。

この項では、「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートを変更します。HelloDetailテンプレートに基づいている次の以前の項を参照してください。

- ユースケース1: 記事アセット用にレイアウト・テンプレートを作成

- ユースケース2: ページレット・テンプレートの使用

注意:

DoctypeおよびInternet Explorer: Internet Explorerで不適切なモードを使用してページがレンダリングされている場合、コンテキスト内編集UIが完全に機能しないことがあります。ローカル設定によってユーザー・インタフェースが影響を受けることのないように、ページのレンダリングでは必ず適切なdoctype値を使用するようにしてください。

詳細は、Microsoft Libraryの『HTML/XHTML Reference』(http://msdn.microsoft.com/)にある、DOCTYPEエレメントの説明を参照してください

この項には次のトピックが含まれます:

- 属性のデータ型

- 文字列フィールドの編集可能化

- テキスト・フィールドの編集可能化

- 日付フィールドの編集可能化

- バイナリ・フィールドの編集可能化

- アセット・フィールドの編集可能化

- 数値フィールド

21.1.1 属性のデータ型

アセット・タイプは、次のタイプが指定可能な1つ以上の属性により定義されます。

- string: 短い文字列(通常は、最大255文字)

- text: 長い文字列。通常は、CLOBデータベース・タイプにマップされます(最大サイズは基礎データベースにより異なります)。

- date: 日付フィールド

- binary: BLOB属性。通常は、イメージ・ファイル、PDFなどのバイナリ・ファイルの格納を対象としています。

- asset: 別のアセットに対する参照

- number: integer、floatまたはmoneyデータ型

21.1.2 文字列フィールドの編集可能化

文字列フィールドを編集可能にすることができます。これらのフィールドには長さ制限があり(通常は255文字)、記事ヘッドライン、作成者などのコンテンツ・メタデータの保持に最適です。

次の手順では、「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートを変更し、記事ヘッドライン・フィールドを編集可能にします。

ics:listgetタグを使用して、ヘッドライン・フィールド(article:headlineリストのvalue列に格納されています)の値を出力できます。

<h1>
<ics:listget
listname="article:headline"
fieldname="value" />
</h1>

1. このフィールドをコンテキスト内で編集可能にするには、次のtaglibディレクティブを追加します。

<@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>

また、前出のコードを次のコード・スニペットに置換します。

<h1>
<insite:edit
field="headline"
list="article:headline" column="value"
assetid='<%=ics.GetVar("cid")%>'
assettype='<%=ics.GetVar("c")%>' />
</h1>

ここで:

- このフィールド・パラメータは、アセットのどのフィールドが編集対象かを指定します。

- パラメータlistおよびcolumnは、現在のフィールド値を格納する場所を指定します。

- パラメータassetidおよびassettypeは、編集済アセットを指定します。

この構文は次のように単純化できます。

<h1>
<insite:edit
field="headline"
list="article:headline"
column="value" />
</h1>

編集済アセットはアセット・タイプ(c)変数とアセットID (cid)変数によって指定されるため、WebCenter Sitesはこれらの値をICSスコープから直接取得します。

HelloArticleLayoutを使用してContributorインタフェースのWebモードでアセットを調べてみても、前の表示との明らかな相違点は示されません。実際に、プレビューまたは調査ビューでは、insite:edit タグは置換したばかりのics:listgetタグとまったく同じように動作します。

2. 「ビューの編集」を選択すると、編集可能な領域がすべてアクティブになります。この場合は、図21-1に示すヘッドライン・フィールドです。

図21-1 編集可能な領域がアクティブなサンプルのWebモード・ページ

3. 編集ユーザーは記事詳細Webページのコンテキスト内でヘッドライン・フィールドを編集できるようになり、この変更内容は「保存」をクリックすると永続化できます。このアクションは、記事アセット・フォームに移動して、図21-2に示すように、記事の「ヘッドライン」フィールドを編集し、その後で「保存」をクリックすることと同じです。

図21-2 サンプルの記事アセット・フォーム(「コンテンツ」タブ)

21.1.2.1 <insite:edit/>タグのバリアント

保存済フィールドの値はリスト内に格納されます。これは、assetsetタグが動作する仕組みです。このタグはデータベースに問い合せて、属性が単一値か複数値かにかかわらず、属性値をリスト・オブジェクトで返します。

この値は変数に利用できる場合もあります。その場合は、次のinsite:editのバリアントが使用できます。

<h1>
<insite:edit
variable="headlineVar"
field="headline" />
</h1>

フィールド値が変数またはリストで使用できない場合には、insite:editタグでvalue属性を直接使用して、そのフィールド値を指定できます。

<%String headline = getHeadlineValueFromSomewhere(); %>
<insite:edit
value="<%=headline%>"
field="headline" />

また、insite:editタグは、フィールド値がWebCenter Sitesプロパティ・ファイルまたはセッション変数で使用可能な場合に、それぞれproperty属性とssvariable属性をサポートします。これらのバリアントはほとんど使用されません。

21.1.3 テキスト・フィールドの編集可能化

テキスト・フィールドを編集可能にすることができます。この項は、「テンプレートとラッパーの作成」の章で紹介したHelloDetailテンプレートに基づいています。

文字列フィールドの場合と同様に、HelloDetailテンプレートのrender:streamタグをinsite:editタグに置換できます。HelloDetailテンプレートでの文字列フィールドの使用例については、「文字列フィールドの編集可能化」を参照してください。

前回、これはrender:streamタグでした。

<render:stream
list="bodyList"
column="value" />

このフィールドを編集可能にするには:

1. render:streamタグをinsite:editタグに変更します。

この例では、フィールドとしてbodyを定義し、エディタ・タイプとしてckeditorを定義しています。

<insite:edit
list="bodyList"
column="value"
field="body"
editor="ckeditor" />

2. 本文テキストをクリックすると、図21-3に示すように、CKEditorウィジェットが表示されます。

図21-3 サンプルのCKEditorウィジェット

3. 次のように、CKEditorに追加の引数を渡すことができます。

<insite:edit
list="bodyList"
column="value"
field="body"
editor="ckeditor"
params="{width: '500px', height: '350px',
toolbar: 'MyToolbar'}" />

詳細は、「CKEditorの構成」を参照してください。

21.1.4 日付フィールドの編集可能化

日付フィールドを編集可能にすることができます。この情報は、「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートに基づいています。

日付フィールドをコンテキスト内で編集可能にするには、文字列フィールドまたはテキスト・フィールドに使用したものと同じinsite:editタグを使用します。ただし、日付の書式設定が必要になる場合は、いくつかの追加手順が必要になります。最初にデータベースから取得した日付フィールドの値は、JDBC書式(2012-01-01 00:00:00.0)で表示されます。この書式はWebサイトでのレンダリングには不適切です。通常、Webサイトでは、日付はJanuary 1, 2012というような読みやすい文字列でレンダリングされるためです。

さらに、日付はサーバーのタイムゾーンで解釈されます。この日付は、別のタイムゾーンで表示できます。最初に、java.utilのTimeZone APIを使用して、タイムゾーンIDを取得します。その後で、long日付書式(事前定義された書式)を使用して、日付を書式設定します。

注意:

事前定義された日付書式の詳細は、次を参照してください。

http://docs.oracle.com/javase/tutorial/i18n/format/dateFormat.html

日付を書式設定する場合は、次の項で説明されている、いずれかの日付書式設定APIを使用できます。書式の選択に応じて、日付とカレンダ・ウィジェットは図21-4のサンプルのいずれかの外観になります。

図21-4 日付とカレンダ・ウィジェット

21.1.4.1 日付書式設定API

HelloDetailテンプレートでは、日付の表示にformattedDateを使用しています。詳細は、「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」を参照してください。

<span class="date">
<ics:getvar name="formattedDate" />
</span>

formattedDate変数は、日付書式設定APIのfmt:formatDate、またはWebCenter Sitesのdateformat APIのいずれかを使用して設定する必要があります。

formattedDateは、時間スタイルのパラメータを追加すると、タイムスタンプを使用したレンダリングが可能になります。また、タイムゾーンのパラメータを追加すると、特定のタイムゾーンでのレンダリングが可能になります。タイムゾーンのパラメータを省略すると、その日付は、サーバーのタイムゾーンで解釈されてレンダリングされます。次に、各APIの説明を示します。

- fmt:formatDate (EL式をサポートする)は、該当するAPIの1つです。このAPIは、次に示すように、文字列書式のjava.util.Date()で日付を取得し、timeZoneパラメータをとります。

<fmt:formatDate value="${asset.postDate}" dateStyle="long"
type="both" timeStyle="long" var="formattedDate"
timeZone="US/Eastern" />

- WebCenter Sitesのdateformat APIには、timezoneidという追加パラメータがあります。このAPIは、fmt:formatDateのかわりに使用できます。

<dateformat:create name="dateFormat" datestyle="long"
timestyle="long" timezoneid="US/Eastern" />

タイムスタンプが必要な場合は、次に示すように、dateformat:getdatetimeを使用します。

<dateformat:getdatetime name="dateFormat" value='<%=postDate%>'
valuetype="jdbc" varname="formattedDate"/>

タイムスタンプが必要ない場合は、次に示すように、dateformat:getdateを使用します。

<dateformat:getdate name="dateFormat" value='<%=postDate%>'
valuetype="jdbc" varname="formattedDate"/>

WebCenter Sitesのdateformat APIは、valuetype引数で、millisまたはjdbcをとります。

21.1.4.2 Webモードでの日付フィールの編集の有効化

書式設定された日付をinsite:editタグ内で使用できます。Webモードでの日付フィールドの編集を有効にするには、次の手順を実行します。

1. insite:editタグでは書式設定された値を渡すため、適切なformatLengthパラメータをparams引数に含める必要があります。この例では、次に示すように、formatLengthをlongに設定しています。さらに、日付フィールドにタイムスタンプとタイムゾーンを表示する場合は、次に示すように、2つの追加パラメータtimePicker:trueとtimeZoneID:'US/Eastern'を設定します。

<span class="date">
<insite:edit
field="postDate"
value="formattedDate"
params="{constraints:{formatLength: 'long'},
timePicker:true, timeZoneID:'US/Eastern'}" />
</span>

注意:

編集モードでの日付ウィジェットは、適切に書式設定された日付が渡された場合にのみ正常に動作します。dateformat:createまたはfmt:formatdate APIの引数datestyleとtimestyleは、insite:editタグのformatLength params引数と一致している必要があります。ここに示す例では、日付書式設定APIの引数datestyleとtimestyleは、すべてlongにする必要があります。タイムゾーン・パラメータを使用してformattedDateを構成した場合は、insite:editタグでも同じタイムゾーンIDを使用する必要があります。

2. これで、日付が、指定した書式設定でレンダリングされるようになります。

- タイムスタンプとtimeZoneID:'US/Eastern'を使用した場合:
SEPTEMBER 7, 2011 10:41:14 AM EDT

- タイムスタンプとtimeZoneIDを使用していない場合::
SEPTEMBER 7, 2011

3. これで、日付フィールドが編集可能になりました。「Webモード」→「ビューの編集」を選択して、Contributorインタフェースで記事を表示しているときに日付フィールドをクリックします。これにより、いずれかのカレンダ・ポップアップ・ウィジェットが表示されます。

日付書式は、params属性を使用してinsite:editタグに渡されます。params属性は、JSON文字列として書式設定された追加の構成設定をDojoウィジェットに渡すために使用します。この場合、次のようになります。

{constraints: {formatLength: 'long'}, timePicker : true,
timeZoneID:'US/Eastern' }

使用可能なウィジェット設定の詳細は、Dojoドキュメント(http://dojotoolkit.org/)を参照してください。

21.1.5 バイナリ・フィールドの編集可能化

バイナリ・フィールドは通常、データベースのBLOBフィールドまたはCLOBフィールドに相当します。一般に、バイナリ・フィールドにはイメージまたはダウンロード可能なドキュメントが格納されます。デフォルトでは、insite:editタグはファイル・アップロード・コンポーネントを通じてバイナリ・フィールドを編集可能にします。

注意:

この項は、WebCenter SitesのURL列にも当てはまります。つまり、ファイル・システムに格納されているファイルへの参照を格納したURL列です。

HelloDetailテンプレートは、関連するAVIImageアセットのlargeThumbnailフィールドをレンダリングします。

このフィールドをコンテキスト内で編集可能にするには:

1. BLOB ID (実際のBLOB値ではありません)が含まれるこのフィールドの値を取得します。

<assetset:setasset
name="image"
type="AVIImage"
id='<%=ics.GetVar("imageId")%>' />
<assetset:getattributevalues
name="image"
attribute="largeThumbnail"
typename="ContentAttribute"
listvarname="largeThumbnail" />

2. largeThumbnailフィールド・イメージのURLを生成します。

<render:getbloburl
outstr="imageURL"
c="AVIImage"
cid='<%=ics.GetVar("imageId")%>'
field="largeThumbnail"  />

3. <img>タグをinsite:editの開始タグと終了タグの間に挿入します。

<insite:edit
field="largeThumbnail"
assetid='<%=ics.GetVar("imageId")%>'
assettype="AVIImage"
list="largeThumbnail"
column="value" >

<img class="photo left" src='<%=ics.GetVar("imageURL")%>' />
</insite:edit>

イメージ上にマウス・ポインタを移動すると、コンテンツ・コントリビュータにツールチップが表示されてアップロード・コンポーネントにアクセス可能になり、largeThumbnailフィールドを消去できます。

注意:

HelloDetailテンプレートでは、コントリビュータは同じページで2つの異なるアセット(AVIArticleアセットのheadline、date、body、relatedImageの各フィールドと、関連するAVIImageアセットのlargeThumbnailフィールド)を編集できます。通常は、同じページに複数のアセットをレンダリングして、それらを同時に編集可能にすることができます。

21.1.6 アセット・フィールドの編集可能化

アセット・フィールドには、他のアセットに対する参照が格納されます。アセット・フィールドを編集可能にすることができます。

この手実行は、「テンプレートとラッパーの作成」の「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」で作成した、HelloArticleLayoutテンプレートに基づいています。

HelloArticleLayoutテンプレートを拡張し、relatedStoriesフィールドを通じて記事に関連付けられた記事アセットをレンダリングすることでサイド・バーを移入します。

注意:

relatedStoriesは複数値フィールドですが、この項では単一値フィールドとして扱います。つまり、このフィールドには関連記事コンテンツ・アセットが1つだけ保持されます。したがって、この項に示すコード・サンプルは、すべての単一値フィールドに適用できます。複数値フィールドの処理の詳細は、「複数値フィールド」を参照してください。

1. AVIArticleアセット・タイプとArticleサブタイプに適用可能なHelloSideBarというページレット・テンプレートを作成します。これは、次のコードを使用して、avisports Summary/SideBar記事テンプレートを使用する関連記事アセットをレンダリングします。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>

<cs:ftcs>

<render:logdep
c="Template"
cid='<%=ics.GetVar("tid")%>' />

<assetset:setasset
name="article"
type="AVIArticle"
id='<%=ics.GetVar("cid")%>' />

<assetset:getattributevalues
name="article"
attribute="relatedStories"
listvarname="relatedStories"
typename="ContentAttribute" />

<%-- we are getting the first item in the list --%>
<ics:listget
listname="relatedStories"
fieldname="value"
output="articleId" />

<render:calltemplate
tname="Summary/SideBar"
c="AVIArticle"
cid='<%=ics.GetVar("articleId")%>' />

</cs:ftcs>

2. side-bar divエレメント内でHelloSideBarページレット・テンプレートを呼び出すように、HelloArticleLayoutテンプレートを変更します。

<div class="side-bar">
<render:calltemplate tname="HelloSideBar" args="c,cid" />
</div>

relatedStoriesに1つのアセット参照(図21-5のCold Snap Back on the Scene)が含まれているとすると、関連記事は、テンプレート・コードで指示されたように、Summary/SideBarテンプレートを使用してサイド・バーにレンダリングされます。

図21-5 サンプルの関連記事の参照

図21-6に、関連記事のレンダリング方法を示します。

図21-6 サイドバーでレンダリングされた関連記事

前回は、HelloSideBarページレットでrender:calltemplateタグを使用しました。

<render:calltemplate
tname="Summary/SideBar"
c="Article"
cid='<%=ics.GetVar("articleId")>' />

3. relatedStoriesアセット・フィールドをコンテキスト内で編集可能にするには、アセットが占有している領域をドロップ・ターゲットに変換します。つまり、UIの他の部分(検索結果ペイン、またはコンテンツ・ツリーなど)からドラッグされたアセットを受け入れる領域です。これを行うには、次のtaglibディレクティブを追加します。

<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>

さらに、HelloSideBarページレットのrender:calltemplateタグをinsite:calltemplateタグに置換します。

<insite:calltemplate
tname="Summary/SideBar"
c='AVIArticle'
cid='<%=ics.GetVar("articleId")%>'
field="relatedStories"
assetid='<%=ics.GetVar("cid")%>'
assettype='<%=ics.GetVar("c")%>' />
...

ここで:

- tname (テンプレート)、c (アセット・タイプ)およびcid (アセットID)の各変数は、render:calltemplateタグの場合と同様に動作し、その意味も同じです。

- 変数assetidおよびassettypeは、編集中のアセット(この例では記事アセット)を指定します。

- 変数fieldは、アセットのどのフィールドが編集中であるか(この例ではrelatedStories)を指定します。

この構文は次のように単純化できます。

<insite:calltemplate
tname="Summary/SideBar"
c='AVIArticle'
cid='<%=ics.GetVar("articleId")%>'
field="relatedStories" />

編集済アセットは変数cおよびcidによって指定されたアセットであるため、この簡略化された構造が使用できます。このように、WebCenter SitesはICSコンテキスト内で変数値を直接検索することによって取得します。

4. フィールドが最初に空であれば(articleId変数がNULLの場合)、ContributorインタフェースのWebモードでアセットを表示すると、空のコンテンツ編集可能なスロットが表示されます(ユーザーに対してドロップ可能ゾーンが表示されます)。

5. これで、コンテンツ・ツリーで、またはドッキングされた検索パネルからアセットを選択することによって、記事アセットをコンテンツ編集可能なスロットにドラッグ・アンド・ドロップできるようになりました。

21.1.6.1 アソシエーションの編集

データ型assetのフレックス属性のかわりにアセット・アソシエーションを使用する場合は、field属性を次のように指定する必要があります。

Association-named:<associationName>

たとえば、topStoryというアソシエーションの場合、コードは次のようになります。

<insite:calltemplate
field="Association-named:topStory"
...
/>

21.1.6.2 親アセットの編集

フレックス・アセットの親アセットの編集も可能です。field属性の構文は次のようになります。

Group_<parentDefinitionName>

たとえば、avisportsの場合、記事アセットにはCategory親定義が割り当てられます。

<insite:calltemplate
field="Group_Category"
...
/>

21.1.7 数値フィールド

数値属性(整数、ダブル、金額など)を扱う場合、未加工の値がデータベースから取得され、通常は現在のロケールに従って書式設定されます。

たとえば、priceが金額属性であるとすると、その属性値を読み取って書式設定された文字列としてレンダリングするJSPは、次のように記述できます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

<cs:ftcs>

<assetset:setasset
name="theAsset"
type='<%=ics.GetVar("c")%>'
id='<%=ics.GetVar("cid")%>' />

<assetset:getattributevalues
name="theAsset"
attribute="price"
listvarname="pricelist"
typename="ContentAttribute" />

<ics:listget
listname="pricelist"
fieldname="value"
output="price" />

<fmt:formatNumber
type="currency"
value='<%=ics.GetVar("price")%>'
var="formattedValue"
currencySymbol="&eur;" />

The price is: ${formattedValue}
</cs:ftcs>

未加工の値が123456である場合は、€123,456 (en_USロケール)としてレンダリングされます。この値は、次のようにinsite:editタグを使用すると編集可能になります。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

<cs:ftcs>

<assetset:setasset
name="theAsset"
type='<%=ics.GetVar("c")%>'
id=''<%=ics.GetVar("cid")%> />

<assetset:getattributevalues
name="theAsset"
attribute="price"
listvarname="pricelist"
typename="ContentAttribute" />

<ics:listget
listname="pricelist"
fieldname="value"
output="price" />

<fmt:formatNumber
type="currency"
value='<%=ics.GetVar("price")%>'
var="formattedValue"
currencySymbol="&eur;" />

The price is: <insite:edit field="price"
value="${formattedValue}"
params="{currency: 'EUR'}" />
</cs:ftcs>

編集ウィジェットは書式設定済の値(通貨記号を含む)に渡されます。このため、通貨ISOコードはparamsフィールドを使用して指定されます。

構成オプションの詳細は、Dojoドキュメント(http://dojotoolkit.org/)を参照してください。

21.1.8 複数値フィールド

既存値の編集だけでなく複数値フィールドを扱う場合、次のようなタスクに対してエディタを使用する必要があります。

- 新しい値の追加

- 既存値の削除

- 既存値の並替え

このため、複数値テキスト・フィールドおよび複数値アセット・フィールドは特別に扱う必要があります。

21.1.8.1 例1: 複数値テキスト・フィールドの編集

1. AVIHomeサブタイプのページ・アセットには複数値テキスト・フィールドが1つ設定されています(次のassetset:getattributevaluesタグの属性値teaserTextを参照)。このフィールドの値のみをレンダリングするテスト・レイアウト・テンプレートを作成します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>

<cs:ftcs>

<render:logdep
cid='<%=ics.GetVar("tid")%>'
c="Template" />

<assetset:setasset
name="page"
type="Page"
id='<%=ics.GetVar("cid")%>' />

<assetset:getattributevalues
name="page"
attribute="teaserText"
listvarname="teaserList"
typename="PageAttribute" />

<div style="width: 500px; font-size: small">
<ics:listloop listname="teaserList">
<render:stream list="teaserList" column="value" />
</ics:listloop>
</div>
</cs:ftcs>

図21-7にサンプルのテキスト・レイアウト・テンプレートを示します。

図21-7 サンプルのテキスト・レイアウト・テンプレート

2. このテンプレートを、複数値のteaserTextフィールドが編集可能になるように変更します。

insite taglibディレクティブを追加します。

<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>

さらに、元のコード

<ics:listloop listname="teaserList">
<render:stream list="teaserList" column="value" />
</ics:listloop>

を次のコードに置換します。

<ics:listloop listname="teaserList">
<ics:listget
listname="teaserList"
fieldname="#curRow"
output="currentRowNb" />
<insite:edit
assetid='<%=ics.GetVar("cid")%>'
assettype='<%=ics.GetVar("c")%>'
field="teaserText"
list="teaserList"
column="value"
index='<%=ics.GetVar("currentRowNb")%>'
editor="ckeditor" />
</ics:listloop>

insite:editタグの構文は、次のように単純化できます。

<ics:listloop listname="teaserList">
<ics:listget
listname="teaserList"
fieldname="#curRow"
output="currentRowNb" />
<insite:edit
field="teaserText"
list="teaserList"
column="value"
index='<%=ics.GetVar("currentRowNb")%>'
editor="ckeditor" />
</ics:listloop>

3. Contributorインタフェースで、「Webモード」→「ビューの編集」に切り替えます。これで、CKEditorを使用して既存値を個別に編集できるようになりました。

単一値フィールドとの明白な相違点は、WebCenter Sitesに編集中の値の索引を通知するindex属性を追加したことのみです。

この時点では、既存値の編集のみ実行可能です。既存値の追加、削除、並替えの方法については、次の項を参照してください。

21.1.8.2 例2: 複数値テキスト・フィールドの変更

この例は、「例1: 複数値テキスト・フィールドの編集」に基づいており、値の追加、削除、並替えについて説明します。

1. 前出のコード・サンプルを次のように変更します。

<insite:list
field="teaserText"
editor="ckeditor"
assetid='<%=ics.GetVar("cid")%>'
assettype='<%=ics.GetVar("c")%>'>

<ics:listloop listname="teaserList">
<insite:edit list="teaserList" column="value" />
</ics:listloop>
</insite:list>

insite:editタグがinsite:listタグ内にネストされました。ネストされたinsite:editタグは、field、assetid、assettypeまたはeditorの各属性を指定しません。これらの属性は親のタグ・レベルで指定されているため、デフォルトでは、ネストされた各insite:editタグが、それらの値を継承するからです(ローカルで指定されていない場合)。　これは、insite:editタグのparams属性にも当てはまります。

index属性は不要になります。この場合は、insite:listタグが現在の索引を常に追跡します。このタグは、insite:editタグの出現順序が複数値フィールドの順序と一致するものと想定します。つまり、最初のinsite:editタグが値#1を編集し、続いて順次に編集すると想定します。そうでない場合は、索引を指定する必要があります。詳細は、「異なる順序の指定」を参照してください。

insite:editタグと同様に、insite:listタグの構文は、編集中のアセットが変数c(アセット・タイプ)およびcid(アセットID)によって指定されたアセットである場合に簡略化できます。その場合、assetid属性とassettype属性は省略可能です。

<insite:list field="teaserText" editor="ckeditor" >
<ics:listloop listname="teaserList">
<insite:edit list="teaserList" column="value" />
</ics:listloop>
</insite:list>

2. insite:listタグを追加したため、フィールド値の表示領域にマウス・ポインタを移動するとツールバーが表示されます。

その領域をクリックするとポップアップがレンダリングされて、フィールド値の追加、編集、削除または並替えが可能になります。

この項は、「例1: 複数値テキスト・フィールドの編集」と「例2: 複数値テキスト・フィールド」に基づいています。

アセット参照フィールドの場合は、insite:listタグのかわりにinsite:slotlistタグを使用します。この場合は、insite:editタグをネストするのではなく、ネストされたinsite:calltemplateタグを使用することになります。

この例では、関連記事を1つレンダリングするかわりに、リスト全体を調べて記事を個別にレンダリングします。

3. 前出のコード・サンプルを次のように変更します(当面、このコードではコンテキスト内編集機能をすべて除外します)。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>

<cs:ftcs>

<assetset:setasset
name="article"
type="AVIArticle"
id='<%=ics.GetVar("cid")%>' />

<assetset:getattributevalues
name="article"
attribute="relatedStories"
listvarname="relatedStories"
typename="ContentAttribute" />

<ics:listloop listname="relatedStories">
<ics:listget
listname="relatedStories"
fieldname="value"
output="articleId" />
<render:calltemplate
tname="Summary/SideBar"
c="AVIArticle"
cid='<%=ics.GetVar("articleId")%>' />
</ics:listloop>
</cs:ftcs>

図21-8は、3つの値を持つフィールドを表示しています。

図21-8 3つの例を持つ関連記事

SideBarには、次の3つの記事が表示されます。

図21-9 サイドバーに表示された関連記事

4. 記事リストを編集可能にするには、次の変更を加えます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/ assetset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld"%>

<cs:ftcs>
<render:logdep c="Template" cid='<%=ics.GetVar("tid")%>' />

<assetset:setasset
name="article"
type="AVIArticle"
id='<%=ics.GetVar("cid")%>' />

<assetset:getattributevalues
name="article"
attribute="relatedStories"
listvarname="relatedStories"
typename="ContentAttribute" />

<insite:slotlist field="relatedStories">
<ics:listloop listname="relatedStories">
<ics:listget
listname="relatedStories"
fieldname="value"
output="articleId" />
<insite:calltemplate
tname="Summary/SideBar"
c="AVIArticle"
cid='<%=ics.GetVar("articleId")%>' />
</ics:listloop>
</insite:slotlist>
</cs:ftcs>

リストのすべてのアイテムがコンテンツ編集可能スロット(ドロップ可能ゾーン)になります。

また、この例ではinsite:slotlistタグを使用したため、relatedStories領域上にマウス・ポインタを移動すると、前述の例と同じようなツールバーが表示されます。

21.1.8.3 異なる順序の指定

前述の例では、最初にネストされたinsite:calltemplateタグでarticle #1がレンダリングされ、2番目のinsite:calltemplateタグでarticle #2がレンダリングされるというように、記事は順番にレンダリングされています。

<div class="top-stories">
<div>article #1</div>
<div>article #2</div>
<div>article #3</div>
<div>...</div>
</ul>

サイトで使用するHTMLマークアップの構造によって、構造が異なる場合があります。たとえば、次のような列レイアウトで記事を表示したい場合があります。

article #1  article #2
article #3  article #4
etc.

基礎となるHTMLマークアップは次のようになる場合があります。

<div class="left-column">
<div>article #1</div>
<div>article #3</div>
...
</div>
<div class="right-column">
<div>article #2</div>
<div>article #4</div>
...
</div>

この例では、フィールドの順序とは一致しない順序(#1、#3、#5、その後で#2、#4、#6など)で記事がレンダリングされています。このような場合、WebCenter Sitesでは順序を意識する必要があります。そのためには、「複数値フィールド」で示したように、index属性を使用して、編集中のリスト・アイテムの索引を明示的に指定する必要があります。

21.1.8.4 モードの編集とキャッシング

「Webモード」→「ビューの編集」で作業している場合、キャッシングは無効化されません。したがって、キャッシングできるように構成されたテンプレートは、「ビューの編集」でのレンダリング時にもキャッシングされます。

アセットを使用している場合、WebCenter Sitesは、適切な依存性がログ記録されていることを条件として、キャッシュ・フラッシュを自動的に処理します。たとえば、特定の属性の定義を変更すると(アセット参照フィールドで許可されるタイプの変更など)、その特定の属性にレンダリングが依存しているすべてのページレットが自動的にフラッシュされます。

ただし、次のような場合、ページ・キャッシュは手動でフラッシュする必要があります。

- アソシエーション・フィールドの定義を変更する。

- ロールがroles属性を通じてinsite:calltemplateタグから直接参照される場合、このロールをWebCenter Sitesから削除する

- アセット・タイプまたはサブタイプがclegal属性を通じてinsite:calltemplateタグから直接参照される場合、このアセット・タイプまたはサブタイプをWebCenter Sitesから削除する

21.2 プレゼンテーション編集用テンプレートのコーディング

技術者以外のユーザーがコンテンツのプレゼンテーションを制御できるようにテンプレートをコーディングできます。次の情報では、コンテキストについて、およびプレゼンテーションの変更をローカルにする(指定されたWebページのみで表示可能にする)、またはグローバルにする(1つのページでのプレゼンテーションの変更をサイト上の複数のページに反映させる)方法について説明します。

プレゼンテーションの管理には、Webページ全体のレンダリングに必要なページ・レイアウトの選択機能、Webページの所定の部分でのアセットのレンダリングに必要なコンテンツ・レイアウトの選択機能、およびページレット・テンプレートに送信される引数の選択機能が含まれます。

この項は、「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートと、「コンテキスト内コンテンツ編集用テンプレートのコーディング」の例に基づいています。

この項には次のトピックが含まれます:

- Webページ全体に対する異なるレイアウトの選択

- ページ・フラグメントに対する異なるレイアウトの選択

- プレゼンテーションとコンテンツの同時編集

- コンテキスト・システム変数の理解

- CSElementアセットとSiteEntryアセットによるスロットの使用

- アセット・タイプの制約

- CSSとJavaScriptの競合回避

21.2.1 Webページ全体に対する異なるレイアウトの選択

編集ユーザーは、2つの方法でレイアウト・テンプレートをアセットに割り当てることができます。

- templateフィールドの値をContributorインタフェースのフォーム・モードで直接変更する。

- ツールバーまたはメニュー・バーからレイアウト変更機能を選択する。

図21-10 ページ・レイアウトの変更ダイアログ

アセットに対してレイアウト・テンプレートを選択すると、そのテンプレートは、ContributorインタフェースのWebモードでのアセットの使用時またはアセットのプレビュー時に、デフォルトとして選択されます。

ライブ・サイトで指定されたアセットのレンダリングに使用されたページ・レイアウトをコンテンツ・コントリビュータが管理できるようにするには、次の例に示すように、テンプレート・フィールドの値を検索してアセット・ハイパーリンクの計算に使用する必要があります。

<asset:list
type='<%=ics.GetVar("c")%>'
list="asset"
field1="id"
value1='<%=ics.GetVar("cid")%>' />

<ics:listget
listname="asset"
fieldname="template"
output="template" />

<render:gettemplateurl
outstr="pageURL"
tname='<%=ics.GetVar("template")%>'
args="c,cid" />

21.2.2 ページ・フラグメントに対する異なるレイアウトの選択

この情報は、「コンテキスト内コンテンツ編集用テンプレートのコーディング」で使用したHelloArticleLayoutテンプレートに基づいています。

前回、HelloArticleLayoutレイアウト・テンプレートでは、このコード・スニペットに示すようにHelloDetailテンプレートを使用して、記事ページのメイン領域がレンダリングされました。

<div id="container">
<div class="content">
<render:calltemplate tname="HelloDetail" args="c,cid" />
</div>
<div class="side-bar">
...
</div>
</div>

このテンプレートは、図21-11のような出力をレンダリングします。

図21-11 テンプレートを使用してレンダリングされた記事ページ

注意:

コード・スニペットで使用した構文は、次のとおりです。

<render:calltemplate tname="HelloDetail" args="c,cid" />

これは次のコード・スニペットに対するショートカット(これとまったく同じもの)です。

<render:calltemplate   tname="HelloDetail"   c='<%=ics.GetVar("c")%>'   cid='<%=ics.GetVar("cid")%>' />

avisportsサンプル・サイトは、記事アセットに対するDetailテンプレートも提供します。Detailページレット・テンプレートは、HelloDetailテンプレートと機能的に同じです。つまり、記事の詳細ビューを提供し、図21-12に示すように、ページのメイン領域でレンダリングすることになっています。

図21-12 Detailページレット・テンプレートを使用したレンダリング

21.2.2.1 プレゼンテーション編集用のスロットの定義

技術者以外のユーザーが特定の記事ページのレンダリングに使用するプレゼンテーション(つまり、ページレット・テンプレート)を選択できるようにするには、スロットを定義する必要があります。

HelloArticleLayoutレイアウト・テンプレートの前出のコードでは、HelloDetailテンプレートを使用して記事ページのメイン領域をレンダリングしました。

<div id="container">
<div class="content">
<render:calltemplate
tname="HelloDetail"
args="c,cid" />
</div>
<div class=side-bar>
...
</div>
</div>
...

スロットを定義するには:

1. insite taglibディレクトリを追加します。

<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>

2. 前述のrender:calltemplateタグをinsite:calltemplateタグに置換し、slotname属性とvariant属性を追加します。

<div id="container">
<div class="content">
<insite:calltemplate
slotname="HelloSlot"

tname="HelloDetail"
variant="HelloDetail|Detail"
args="c,cid" />
</div>
<div class=side-bar>
...
</div>
</div>
...

slotname属性を追加することで、スロットを定義しています(この例では、HelloSlotと呼ばれます)。slotname属性値には任意の文字列を使用できますが、特定のサイトのすべてのテンプレートで一意である必要があります。詳細は、「コンテキスト・システム変数の理解」を参照してください。

3. このテンプレートを再実行します。

最初は表立った変更はありません。この記事は、tname属性の指示どおりに、HelloDetailテンプレートを使用してレンダリングされています。

4. 「ビューの編集」に切り替えてメインdivセクション上にマウス・ポインタを移動します。変更内容は次のとおりです。

- メインdiv内のページ・フラグメントが青のオーバーレイでマークされています。

- スロット名が右上隅に指定されています。

- 青のオーバーレイをクリックすると、ツールバーも表示されます。

5. 「コンテンツ・レイアウトの変更」アイコン(図21-13)をクリックします。

図21-13 「コンテンツ・レイアウトの変更」アイコン

「コンテンツ・レイアウトの変更」ダイアログが開きます。

「コンテンツ・レイアウトの変更」オプションを使用すると、別のコンテンツ・レイアウトを選択して、ページのメイン領域にアセットをレンダリングできるようになります。

6. テンプレート・ピッカーは、variant属性により指定されたHelloDetailページレット・テンプレートとDetailページレット・テンプレートを表示します。Detailテンプレートを選択して「適用」をクリックすると、図21-14に示すようなWebページがレンダリングされます。

図21-14 「コンテンツ・レイアウトの変更」ダイアログがある出力ページ

図21-14で定義したスロットはプレゼンテーション編集のみを意図したものであり、コンテンツ編集可能スロット(ドロップ可能ゾーン)ではありません。

このように動作する理由は、次のとおりです。

- insite:calltemplateタグはfield属性を定義しません。つまり、スロットのコンテンツはアセット参照フィールドの値ではありません。
このタグは、c (アセット・タイプ)およびcid (アセットID)に対して明示的に値を指定します。特にこの場合は、受信するcおよびcidリクエスト・パラメータにより指定された記事アセットをこの場所にレンダリングする必要があります。

さらに、variant属性が省略された場合、スロット・レイアウトは編集可能になりません。その理由は、insite:calltemplateタグがtname属性(これは、このスロットにドロップされたすべてのアセットに対するデフォルト・テンプレートとして動作します)に対して明示的な値を指定するためです。

注意:

variant属性には、任意の正規表現を含めることができます。たとえば、variant="Detail.*"と指定すると、テンプレートの使用はDetailで始まる名前のページレット・テンプレートのみに制限されます。

21.2.2.2 スロット・タイトルの調整

slotnameの値を青のオーバーレイに表示するのではなく(これは通常、開発者のみに意味のある技術的な文字列です)、この値を任意の文字列に置き換えることができます。

これを行うには、次の手順を実行します。

- 次のコードに示すように、title属性をinsite:calltemplateタグに追加します。

<insite:calltemplate
slotname="HelloSlot"
tname="HelloDetail"
args="c,cid"
variant="HelloDetail|Detail"
title="Article Detail Area" />

title属性を定義すると、デフォルトのスロット・タイトルがオーバーライドされます。

21.2.2.3 テンプレート引数の管理

この項では、テンプレート引数の管理の例を示します。image-alignという追加の引数を受け入れるように、HelloDetailテンプレートを変更します。この引数は、記事イメージの左揃えまたは右揃えに使用します。

このプロセスは、次のとおりです。

- image-align引数をHelloDetailテンプレートの適切な引数として登録する必要があります。この手順を省略した場合、コントリビュータは編集UIからこの値を設定できません。

- キャッシングが正しく機能するように、新しい引数をキャッシュ基準として宣言する必要があります。

- 最後に、新規定義された引数を使用するようにテンプレート・コードが変更されます。

注意:

Eclipse with the WebCenter Sites Developer Toolsプラグインの使用方法について: Adminインタフェースからテンプレート・アセットを編集する際、このテンプレートがWSDTでも同時に開いている場合には、変更をWSDTワークスペースに同期化することを忘れないでください。そうしないと、WSDTワークスペースに格納されたテンプレート・メタデータによって、Webインタフェースから入力された値がオーバーライドされます。

1. image-alignをHelloDetailテンプレート・アセットの適切な引数として宣言します。

a. Adminインタフェースから、HelloDetailテンプレート・アセットを編集します。

b. 「適切な引数」に対して、image-alignと入力して「引数の追加」をクリックします。

c. 「必須」を選択します。

d. 「引数の説明」に対して、Image Alignmentと入力します。

e. 「有効な値」に対して、次の説明を追加します。

- 「値」がleftの場合は、「値の説明」にAligned Leftと入力します。

- 「値」がrightの場合は、「値の説明」にAligned Rightと入力します。

f. 「保存」をクリックします。

2. WebCenter Sitesで加えた変更を必ずWSDTワークスペースに同期化してください。

3. WebCenter Sites Developer Toolsプラグインを使用して、image-alignをキャッシュ基準セットに追加します。

a. WebCenter SitesワークスペースでHelloDetailテンプレートを右クリックします。

b. 「プロパティ」を選択します。

c. 「キャッシュ基準」フィールドで、リストの末尾にimage-alignを追加します。「キャッシュ基準」値の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

d. 「送信」をクリックします。

4. オプションとして、「追加エレメント・パラメータ」フィールドを使用して、image-align=rightなどの値を指定することで、デフォルト値を定義できます。

5. HelloDetailページレット・テンプレート・コードを変更します。:

<insite:edit
field="largeThumbnail"
assettype="AVIImage"
assetid='<%=ics.GetVar("imageId")%>' >

<img class='photo <ics:getvar name="image-align"/>'
src='<ics:getvar name="imageURL" />' />
</insite:edit>
...

特にこの場合、パラメータの値は別のCSSクラスの設定に使用されています。

スロット・プロパティ・パネルに移動した場合、HelloDetailが現在選択されているレイアウトであるとすると、「詳細」タブには位置合せオプションが表示されます。

21.2.3 プレゼンテーションとコンテンツの同時編集

編集ユーザーは、insite:calltemplateタグの使用によって、関連付けられたコンテンツの編集とレイアウトの編集を行えます。この項では、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの相違点を説明し、この2つの機能を組み合せて編集ユーザーが関連付けられたコンテンツと、そのコンテンツのレンダリングに使用されるテンプレートの両方の編集を行える方法を説明します。

この項には次のトピックが含まれます:

- コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの理解

- コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの組合せ

21.2.3.1 コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの理解

コンテンツ編集可能スロットを使用すると、ユーザーはドロップ可能ゾーンを指定することで、関連付けられたコンテンツを編集できます。プレゼンテーション編集可能スロットを使用すると、別のテンプレートを選択してコンテンツをレンダリングできます。

コンテンツ編集可能スロットを作成(ユーザー用にドロップ可能ゾーンを作成)するには、insite:calltemplateタグを次の定義済パラメータとともに使用します。

- assetid: 編集済アセットID。

- assettype: 編集済アセット・タイプ。

- field: 編集済フィールド。

- cid: コールされたテンプレートによってレンダリングされるアセットのID。

- c: コールされたテンプレートによりレンダリングされるアセット・タイプ。

- tname: 関連付けられたアセットのレンダリングに使用されるページレット・テンプレート。

次のコードでは、ユーザーに対してドロップ可能ゾーンを作成するコンテンツ編集可能スロットが定義されます。

<insite:calltemplate
assetid=" "
assettype=" "
field=" "
cid=" "
c=" "
tname=" "
/>

(ユーザーが別のテンプレートを選択してコンテンツをレンダリングできるようにする)プレゼンテーション編集可能スロットを作成するには、insite:calltemplateタグを次の定義済パラメータとともに使用します。

- slotname: この属性により、コールされたテンプレートで入力中のスロットの識別子が定義されます。これはわかりやすいものとし、すべてのテンプレートで一意である必要があります。

- cid: コールされたテンプレートによってレンダリングされるアセットのID。

- c: コールされたテンプレートによりレンダリングされるアセット・タイプ。

- tname: コールされるデフォルトのページレット・テンプレート。

このコードでは、ユーザーが別のテンプレートを選択してコンテンツをレンダリングできるプレゼンテーション編集可能スロットが定義されます。

<insite:calltemplate
slotname=" "
cid=" "
c=" "
tname=" "
/>

21.2.3.2 コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの組合せ

コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの機能を組み合せて、編集ユーザーが関連付けられたコンテンツとそのコンテンツのレンダリングに使用されるテンプレートの両方を編集することを可能にできます。

コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの機能を組み合せるには、insite:calltemplateタグを、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの両方に必要なすべての属性とともに使用します。

- これらの属性は、(ユーザーに対してドロップ可能ゾーンを作成する)コンテンツ編集可能スロットに必須です。

field, assetid, assettype

- この属性は、(ユーザーが別のテンプレートを選択してコンテンツをレンダリングできる)プレゼンテーション編集可能スロットに必須です。

slotname

このコードでは、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットに対する属性が組み合されます。

<insite:calltemplate
slotname=" "
assetid=" "
assettype=" "
field=" "
cid=" "
c=" "
tname=" "
/>

コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの組合せ

この項は、「コンテキスト内コンテンツ編集用テンプレートのコーディング」で作成したHelloSideBarテンプレートに基づいています。

前回、HelloSideBarテンプレートは次のようにコーディングされました。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld"%>

<cs:ftcs>

<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>
<assetset:setasset name="article"
type='<%=ics.GetVar("c") %>' id='<%=ics.GetVar("cid") %>' />
<assetset:getattributevalues name="article"
listvarname="relatedStories" attribute="relatedStories"
typename="ContentAttribute" />

<insite:slotlist field="relatedStories">
<ics:listloop listname="relatedStories">
<ics:listget listname="relatedStories" fieldname="value"
output="articleId" />

<insite:calltemplate
tname="Summary/SideBar"
c="Article"
cid='<%=ics.GetVar("articleId") %>' />

</ics:listloop>
</insite:slotlist>
</cs:ftcs>
...

このテンプレートでは、関連記事がコンテンツ編集可能スロット(ドロップ・ゾーン)によって編集可能になります。つまり、関連記事は、編集ユーザーが別のテンプレートを選択する可能性を生じずに、Summary/SideBarテンプレートを使用してレンダリングされます。ただし、関連記事のレンダリング方法は変更できません。変更するには、HelloSideBarテンプレートを次のように変更する必要があります。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld"%>

<cs:ftcs>

<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>
<assetset:setasset name="article"
type='<%=ics.GetVar("c") %>' id='<%=ics.GetVar("cid") %>' />
<assetset:getattributevalues name="article"
listvarname="relatedStories" attribute="relatedStories"
typename="ContentAttribute" />

<insite:slotlist
slotname="RelatedStoriesSlot"
field="relatedStories">

<ics:listloop listname="relatedStories">
<ics:listget listname="relatedStories" fieldname="value"
output="articleId" />

<insite:calltemplate
tname="Summary/SideBar"
c="Article"
cid='<%=ics.GetVar("articleId") %>'
variant="Summary.*" />

</ics:listloop>
</insite:slotlist>
</cs:ftcs>

これは、slotname属性およびvariant属性を指定した点を除き、前回使用したコードと同じです(この場合は、使用可能なテンプレートのリストはSummaryで始まるすべてのページレット・テンプレートに制限されます)。

slotnameはinsite:slotlistタグの内側に組み込まれているため、内部のinsite:calltemplateタグ用に追加する必要はありません。この値は、tnameおよびfieldの値と同様に、自動的に継承されます。

次に例を示します。

<insite:slotlist slotname=" " field=" ">
<insite:calltemplate tname=" " c=" " cid=" " />
</insite:slotlist>

これで、Summary/SideBarは関連記事に対してデフォルト・テンプレートとして動作するようになります。任意の関連記事を右クリックし、「コンテンツ・レイアウトの変更」機能を選択すると、代替テンプレートが選択できるようになります。

21.2.4 コンテキスト・システム変数の理解

WebCenter Sitesテンプレートでは、contextは内部で保持されるシステム変数です。その値を取得するには、JSPタグics:getvarまたはics.GetVar()メソッドを使用します。

次に例を示します。

<ics:getvar name=context/>
ics.GetVar(context)

コンテキストの値は、デフォルトで決定済です。最初は空の文字列に設定されています。その後、render:calltemplateまたはinsite:calltemplateを使用してテンプレートをコールするたびに、contextの値は、次のロジックに従って、コールされたテンプレート内で変更されます。

if parent_context is empty
context = <c>:<cid>:<tname>
otherwise
context = <parent_context>;<c>:<cid>:<tname>

この項には次のトピックが含まれます:

- スロットの有効範囲の定義について

- 動作中のコンテキスト変数の使用方法

- コンテキスト値の初期化

- コンテキストのオーバーライド

- コンテキストのキャッシング

21.2.4.1 スロットの有効範囲の定義について

スロットを定義するときに、テンプレート開発者はスロットの有効範囲を決定できます。通常は、このスロットで加えられたプレゼンテーション変更をローカルにするかグローバルにするかを決定します。

- ローカル: 現在編集しているWebページのみに表示されます。

- グローバル: サイト内の複数のWebページ(おそらく、サイト内のすべてのWebページ)にわたります。

これはcontext変数の値を操作することで実行されます。これについては、次の各項で説明します。

21.2.4.2 動作中のコンテキスト変数の使用方法

WebCenter Sitesには、次のアイテムに対して新しく選択されたテンプレートを記録することによってプレゼンテーションの変更が格納されます。

- スロット名

- 現在のサイト名

- コンテキスト

スロット・コンテンツのレイアウトを変更するには:

1. HelloArticleLayoutテンプレートを2つのavisports記事(たとえば、

All 25 Nevada resorts serving great snowおよびCold snap back on the scene)に割り当てます。

2. これら両方の記事をContributorインタフェースのWebモードで観察します。

デフォルトのテンプレートHelloDetailがJSPコードでデフォルトのテンプレートとして指定されているテンプレートであるため、これを使用してメイン・スロットがレンダリングされます。

3. 「コンテンツ・レイアウトの変更」オプションを使用して、DetailテンプレートをAll 25 Nevada resorts serving great snowの記事に割り当てます。

4. このWebページをCold snap back on the sceneの記事でリフレッシュします。メイン・スロットのプレゼンテーションも、Detailテンプレートを使用しているため、このWebページで変更されています。

その結果、スロット・コンテンツ・レイアウトをHelloDetailからDetailに変更したときに、次のプレゼンテーション・データが記録されました。

- site: avisports

- slotname: ArticleDetail

- context: (空)

- tname: Detail

HelloArticleLayoutテンプレートの実行時にコンテキストは最初は空であっため、コンテキストは空であり、スロットがレンダリングされても変更されることはありません。このため、HelloArticleLayoutテンプレートを使用してレンダリングされたavisportsのWebページはすべて、前述の記録されたプレゼンテーション・データと一致します。その結果、すべての記事ページに対してDetailテンプレートが使用できるようになりました。

21.2.4.3 コンテキスト値の初期化

前の項で観察した動作は意図された動作でもあります。しかし、編集ユーザーはローカルなプレゼンテーション変更を必要とする場合もあります。つまり、変更を現在編集中のWebページでのみ表示できるようにすることです。

これを行うには、context変数を、指定されたWebページを一意に識別する値に設定する必要があります。ここでは、コンテキストの初期化に、たとえば、テンプレート名、ID、およびレンダリングされたアセットのタイプを使用するだけで十分です。

<ics:setvar
name="context"
value='<%=ics.GetVar("c")
+ ":" + ics.GetVar("cid")
+ ":HelloArticleLayout"%>' />

意図される結果によっては、その他のパラメータを追加してコンテキストを初期化できます。前述の行をHelloArticleLayoutテンプレートに追加して、プレゼンテーションの変更が記事ページごとにローカルであることを検証できます。

21.2.4.4 コンテキストのオーバーライド

render:calltemplateタグとinsite:calltemplateタグの両方にオプションのcontext属性が割り当てられているため、この属性を使用して現在のコンテキストをオーバーライドできます。

21.2.4.5 コンテキストのキャッシング

コンテキストは、プレゼンテーション編集機能がサイトで有効化されている場合のみ役立ちます。

そうでない場合は、すべてのテンプレートのキャッシュ基準からコンテキストを削除できます(ページ・キャッシュに不要なコピーを作成しないようにするため)。

21.2.5 CSElementアセットとSiteEntryアセットによるスロットの使用

前出の例では、スロットはコンテンツの保持に使用されました。この項では、ナビゲーション・バー、ログイン・ボックス、パブリッシュされた最後の10個の記事をサイトに表示するコード・スニペットなどの機能の保持にスロットを使用する方法を検討します。これらの機能は、CSElementアセットまたはSiteEntryアセットとして使用できます。

CSElementアセットまたはSiteEntryアセットをスロットにドロップできるようにすることで、技術者以外のユーザーは、コードを変更する必要もなく、特定のWebページの動作を変更できるようになります。

この項には次のトピックが含まれます:

- CSElementアセットを含むスロットの定義

- CSElementアセットまたはSiteEntryアセットを使用するタイミング

- 適切な引数の定義について

- ネストされたスロットの使用に関する考慮事項

21.2.5.1 CSElementアセットを含むスロットの定義

CSElementアセットを含めるためのスロットは通常、次のように定義されます。

<insite:calltemplate
slotname="Navbar"
clegal="CSElement"
/>

または、サイトの全ページにわたって同じコンテンツを表示するためのスロットの場合は、次のように定義できます。

<insite:calltemplate
slotname="Navbar"
clegal="CSElement"
context="Global"
/>

CSElementアセットとSiteEntryアセットは、これらのレンダリングを行うJSPエレメントを直接参照しているため、この場合はtname属性を指定する必要はありません。

スロットに許可されるアセット・タイプのリストにSiteEntryまたはCSElementを表示するには、両方のアセット・タイプのCan Be Child AssetフラグがTrueに設定されていることを確認する必要があります(これは、このアセット・タイプがアソシエーション・フィールドで別のアセット・タイプの子アセット・タイプになりえることを意味します)。詳細は、「ベーシック・アセット・タイプの作成」の「アセット・タイプの構成」を参照してください。

注意:

スロットに許可されるアセット・タイプのリストにSiteEntryまたはCSElementを表示するには、両方のアセット・タイプのCan Be Child AssetフラグがTrueに設定されていることを確認する必要があります(これは、このアセット・タイプがアソシエーション・フィールドで別のアセット・タイプの子アセット・タイプになりえることを意味します)。詳細は、「ベーシック・アセット・タイプの設計」を参照してください。

21.2.5.2 CSElementアセットまたはSiteEntryアセットを使用するタイミング

SiteEntryアセットはコードを保持しないで、単にCSElementアセットを指します。この2つのケースの唯一の相違点として、SiteEntryを使用した場合、エレメントはキャッシュ・エンジンを通して呼び出されます。そのため、SiteEntryアセットをドロップしても、それに関連するCSElementアセットをドロップしても結果は同じです。

したがって、SiteEntryまたはCSElementのいずれを使用するかの決定は、実装に依存します。機能をSiteEntryとして表示しても、このコード・スニペットのレンダリングにはキャッシングが使用されることが確認できるだけです。

21.2.5.3 適切な引数の定義について

テンプレートと同様、CSElementアセットに対して適切な引数を定義できます。CSElementがスロットにドロップされると、スロット・プロパティ・パネルから適切な引数が使用できるようになります。

これはSiteEntryアセットをドロップする場合にも当てはまりますが、スロット・プロパティ・パネルに表示される適切な引数は関連のCSElementアセットの適切な引数であることが異なります。(SiteEntryアセットには、専用の適切な引数が割り当てられていません)。

21.2.5.4 ネストされたスロットの使用に関する考慮事項

アセットをコンテンツ編集可能スロットにドロップするときに、このアセットをレンダリングするテンプレートは他のスロットも定義できる可能性があります。1つの領域にレンダリングされるコントロールやスロットが過剰にならないように、ネストされたスロットの動作は単純なドロップ可能領域(ツールバーとオーバーレイのないもの)に自動的に低下されます。Contributorインタフェースがユーザーにとって単純で使いやすいようにするために、通常はネストされたスロットを使用しないことをお薦めします。

21.2.6 アセット・タイプの制約

デフォルトでは、WebCenter Sitesでスロットにドロップできるアセット・タイプは次のとおりです。

- fieldを定義した場合(コンテンツ編集可能スロット): フィールド定義により指定された任意の適切なアセット・タイプ

- fieldが未定義の場合(プレゼンテーション編集可能スロット): Can Be Child AssetフラグがTrueに設定されている任意のアセット・タイプ。詳細は、「ベーシック・アセット・タイプの設計」を参照してください。

次のようにclegal属性を使用して、許可されるアセット・タイプをさらに制限することもできます。

<insite:calltemplate
slotname="Main"
clegal="Article,Product"
...
/>

次の構文では、アセット・サブタイプによってさらに制限できます。

<insite:calltemplate
slotname="Main"
clegal="type1:subtype1,type2:subtype2"
...
/>

注意:

type:*(ワイルドカードとしてアスタリスクを使用)も有効であり、これはtype値のように動作します。

21.2.7 CSSとJavaScriptの競合回避

コンテキスト内UIは、Contributorインタフェースで「Webモード」→「ビューの編集」からレンダリングするときに(この場合のみ)、スタイルとJavaScriptをWebページに挿入します。

この結果、次のようになる場合があります。

- CSS競合: たとえば、サイトCSSルールが適用されるために、スロットが不適切に表示されます。

- JavaScript競合: 編集中ビューのページに挿入されたJavaScriptと競合するJavaScriptがWebページに設定されています。その結果、編集UIまたはページ自体のいずれかが適切に機能しません。

CSS競合は通常、追加のCSSルールを追加することによって解決できます。このルールは、テンプレートが編集モードで、編集UIの中でレンダリングされる場合のみロードされます。これを行うには、JSPテンプレートが編集モードで実行されている場合のみJSPコードの実行を許可するinsite:ifeditタグを使用します。

<insite:ifedit>
<%-- This stylesheet import will only occur in editing mode.
-- It will not have any impact on the actual rendering of the
-- live site.
--%>
<link rel="stylesheet"
type="text/css"
href="/css/editorial.css" />
</insite:ifedit>

追加のCSSクラスをスロットに追加するには、insite:calltemplateタグのcssstyle属性を使用して、スロットに対して特定のCSSルールを指定します。

CSSは通常、フローティングしているエレメントの周りでスロットをレンダリングするときに競合します。この場合、スロット領域をマークする青または緑のオーバーレイのディメンションが不適切であることが考えられます。

JavaScript競合は通常、スクリプトが編集UI機能によって正しく注入されるようにするために、編集モードのみでWebページの動作を低下させることによって解決できます。Contributorインタフェースの「Webモード」→「ビューの編集」でページ機能の一部を無効化する場合もあります。

21.3 Webモードでのコンテンツ作成の有効化

コントリビュータは、コンテキスト内UIからコンテンツを作成できます。これを行うには、タイプinsiteのスタート・メニュー・アイテムと、作成するアセット・タイプに適用可能なレイアウト・テンプレートを少なくとも1つ提供します。

この項には次のトピックが含まれます:

- コンテンツ内作成用のスタート・メニューの定義

- コンテキスト内作成用のレイアウト・テンプレートの提供

- 空の値インジケータの提供

- 編集固有のプレゼンテーション・ロジックの提供

21.3.1 コンテンツ内作成用のスタート・メニューの定義

コンテキスト内作成用に特定のアセット・タイプを有効にするために、タイプinsiteのスタート・メニューを用意する必要があります。つまり、「タイプ」ドロップダウン・メニューで「新規Insite」オプションを選択する必要があります。

さらに、作成中のアセットに1つ以上の必須フィールドを割り当てる場合は、「デフォルト値」メニューを使用してスタート・メニューにデフォルト値を提供する必要があります。

必須値が不足している場合、ユーザーはアセット・フォームに送られます。

ユーザーが「新規Insite」スタート・メニューを選択すると、編集ユーザーは、最初にレイアウト・テンプレートと新規作成したアセット用の名前を選択するよう促されます。

「続行」をクリックすると、ワークフローが構成されていない場合、アセットがバックグラウンドに新規作成され、選択したレイアウト・テンプレートを使用してレンダリングされます。

21.3.2 コンテキスト内作成用のレイアウト・テンプレートの提供

編集に使用したものと同じレイアウト・テンプレートが、コンテキスト内作成にも使用できます。ただし、テンプレートが空のアセットを使用して適切にレンダリングできるように、特別の注意を払う必要があります。

通常、これには次が必要です。

- スタイル調整: 値はレンダリングされませんが、ページ上の各種エレメントは適切な位置にレンダリングされます

- 意味のあるヘルプ・テキスト(値なしインジケータ): 編集可能フィールドが空のときにユーザーに表示されます

- 追加のプレゼンテーション・ロジック: 編集プラットフォーム上で、テンプレートが編集モードで実行しているときのみ実行されます

この項には次のトピックが含まれます:

- スタイルシートの調整

- スロット用のスタイルシート調整

21.3.2.1 スタイルシートの調整

特にコンテンツの作成または編集用にスタイルシートの調整が必要な場合は、次に示すように、対応するimport文をinsite:ifeditタグで囲みます。

// import "delivery" stylesheets
<link type="text/css" rel="stylesheet" href="somecss.css" />
...

// then import "editing only" stylesheets. using the insite:ifedit
// tag ensures that only those stylesheets will be imported
// when rendering the template in create/edit mode.

<insite:ifedit>
<link type="text/css" rel="stylesheet" href="edit.css"  />
...
</insite:ifedit>

21.3.2.2 スロット用のスタイルシート調整

スロットのレンダリング用にスタイルを調整する場合、insite:calltemplateタグのcssstyle属性を使用して追加のクラス名を指定できます。このクラス名は、CSSルールで使用できるようになります。

<insite:calltemplate
slotname="mySlot"
...
cssstyle="myClassName"
...
/>

たとえば、mySlotが空のときにその高さを強制的に50pxに設定する場合は、次のCSSルールを指定できます。

.myClassName .emptyIndicator {height: 50px !important;}

CSSルールは、特定のスタイルシート内でグループ化でき、JSPタグinsite:ifeditを使用してContributorインタフェースの「Webモード」→「ビューの編集」のコンテキストでテンプレートを実行している場合のみ、条件付きでインポートできます。

21.3.3 空の値インジケータの提供

スロットの場合は、insite:calltemplateタグのemptytext属性を使用します。

<insite:calltemplate
slotname="mySlot"
emptytext="Drag an Article here"
...
/>

その他の編集フィールドの場合は、insite:editタグのnoValueIndicatorパラメータを使用します。

<insite:edit
field="headline
params="{noValueIndicator: 'Enter Headline Here'}"
...
/>

21.3.4 編集固有のプレゼンテーション・ロジックの提供

プレゼンテーション・ロジックは、作成/編集モードと比較した場合、配信モードでは若干異なる場合があります。

たとえば、作成/編集モードでコンテキスト内の編集可能な記事リストをレンダリングしているときに、常に5つの追加の空スロットを表示する場合があります。　その場合は、配信モードと編集モードの両方に対応できるロジックが必要になります。このロジックは次のように作成できます。

<%
// assuming that "relatedArticles" contains a list of
// related articles
%>
<insite:slotlist field="someAssetField">
<ics:listloop listname="relatedArticles">
<ics:listget
listname="relatedArticles"
fieldname="value"
output="articleid" />
<div class="post">
<insite:calltemplate
tname="Summary"
c="Article"
cid='<%=ics.GetVar("articleid")%>' />
</div>
</ics:listloop>
</insite:slotlist>

<%
// in this example, we add five extra empty slots
%>
<insite:ifedit>
<%
// To not disrupt rendering in delivery, this code is
// added inside the insite:ifedit tag
%>
<c:forEach begin="0" end="4">
<div class="post">
<%
// no c, cid specified, this renders an empty slot
%>
<insite:calltemplate tname="Summary" />
</div>
</c:forEach>
</insite:ifedit>

明らかに、このコードは特定のロジックを受け入れるように調整できます。たとえば、空かどうかに関係なく、最大5つのスロットを表示する必要があるとします。その場合、コード・スニペットの最後の部分を次のように作成できます。

<%
// get how many articles are in the list
%>
<ics:listget
listname="relatedArticles"
fieldname="#numRows"
output="nbArticles" />

<c:forEach
begin='<%=Integer.valueOf(ics.GetVar("nbArticles"))%>'
end='4'>
<div class="post">
<insite:calltemplate tname='Summary" />
</div>
</c:forEach>

22 ベーシック・アセットのテンプレート・エレメント例

Oracle WebCenter Sitesでは、ベーシック・アセットのTemplatesを使用できます。次の例は、コレクション、問合せおよび記事アセットのTemplatesのコーディング方法およびそれらのサイト・ナビゲーションの作成方法を示します。

次の各項では、ベーシック・アセットのTemplatesエレメントの例について説明します。

- ベーシック・モジュラ・デザインの作成

- コレクション・アセット内の記事アセットへのリンクのコーディング

- ct変数の使用

- 問合せアセットのテンプレートのコーディング

- テンプレートを使用しない記事アセットの表示

- サイト・ナビゲーション情報の表示

- アセット以外の情報の表示

これらのトピックの例では、「テンプレートおよびCSElementのエレメントのコーディング」で示した情報について説明します

22.1 ベーシック・モジュラ・デザインの作成

共通コードを一度のみ作成していくつかの場所やコンテキストで再使用するために、汎用エレメントを利用するモジュラ・サイト・デザインの例です。次に、ホーム・ページ上の1つの領域を5つの異なるエレメントから作成する方法について説明します。

サイトのホーム・ページの次の列には、その日のメイン・ストーリーが表示されます。リスト内のストーリーごとにサマリー段落と署名行があります。ストーリーのタイトルは、そのストーリー全文へのハイパーリンクです。リスト内の最初のストーリーを含むストーリーのいくつかには、図22-1に示すように写真も表示されます。

図22-1 その日のメイン・ストーリー

この例では、リスト内の最初のストーリーの特定、選択、リスト先頭への配置、および書式設定の方法について説明します。

リスト内の最初のストーリーの書式設定に使用されるエレメントは次のとおりです。

- FiscalNews/Page/Home

- FiscalNews/Collection/MainStoryList

- FiscalNews/Article/LeadSummary

- FiscalNews/ImageFile/TeaserSummary

この項には次のトピックが含まれます:

- Homeエレメント

- MainStoryListエレメント

- LeadSummaryエレメント

- TeaserSummaryエレメント

- LeadSummaryの再開

- MainStoryListの再開

- Homeの再開

22.1.1 Homeエレメント

サイトのホーム・ページでは、Homeという名前のTemplateを使用できます。Templateは次の2つの方法で調べることができます。

- Adminインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、Templateエレメントを開きます。

たとえば、Fiscal Newsサイトのホーム・ページのTemplateを次に示します。

ElementCatalog/FiscalNews/Page/Home

開くと、まず、Homeエレメントによって、次のようにHomeページ・アセットがロードされ、そのアセットにHomePageという名前が付けられて、そのアセットのフィールドに情報が分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="HomePage"/>
<ASSET.SCATTER NAME="HomePage" PREFIX="asset"/>

cidの値がFiscal News URLから渡され、cの値が使用可能になりますが、これは、この値がHome TemplateのSiteCatalogページ・エントリ内のresarg1列で変数として設定されているためです。このTemplateには、次のASSET.CHILDRENタグが含まれます。

<ASSET.CHILDREN NAME=HomePage LIST=MainStories CODE=TopStories/>

Homeでは、このコードによって、ページ・アセットのTopStoriesコレクションとして指定されたコレクション・アセットが取得され(CODE=TopStories)、それを保持するリストがMainStoriesという名前で作成されます(LIST=MainStories)。

次に、Homeによって、コレクションが正常に取得されたかどうかが確認され、MainStoryList Templateのページ・エントリがコールされます。

<IF COND = IsList.MainStories=true>
<THEN>
<RENDER.SATELLITEPAGE pagename=FiscalNews/Collection/MainStoryList
ARGS_cid=MainStories.oid
ARGS_p=Variables.asset:id/>
<THEN/>
<IF/>

Homeによって、ARGS_cidを使用してMainStoriesに対するコレクションを保持するリストのIDが渡され、ARGS_p=Variables.asset:idを使用してHomeページ・アセットのIDが渡されます。

22.1.2 MainStoryListエレメント

MainStoryListページ・エントリによって、そのルート・エレメントが呼び出されます。

ElementCatalog/FiscalNews/Collection/MainStoryList.xml

MainStoryListエレメントは、コレクション・アセットを書式設定するMainStoryList Templateアセットのテンプレート(ルート)エレメントです。このエレメントによって、ストーリーのメイン・リストを保持するホーム・ページ列のフレームワークが作成され、その列にTopStoriesコレクションからの記事が挿入されます。MainStoryListでは、それらの記事を書式設定するために、次の2つのテンプレートが使用されます。

- コレクション内の最初の記事(最上位にランクされた記事)に対するLeadSummary

- 残りの記事に対するSummary

この例の目的はリストの最初のストーリーの表示方法を紹介することなので、この例では、LeadSummary Templateエレメントについてのみ説明します。

MainStoryListによって、次のようにHomeから渡されたコレクションがロードされ分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid"
NAME="MainStoryListCollection"/>
<ASSET.SCATTER NAME="MainStoryListCollection" PREFIX="asset"/>

次に、次のようにコレクションから記事が抽出され、それらを保持するリストが作成され、記事がそれぞれのランクに基づいて順序付けされます。

<ASSET.CHILDREN NAME="MainStoryListCollection" LIST="theArticles"
ORDER="nrank" CODE=-/>

続いて、次のようにLeadSummary Templateのページ・エントリがコールされます。

<RENDER.SATELLITEPAGE PAGENAME="FiscalNews/Article/LeadSummary"
ARGS_cid="theArticles.oid"
ARGS_ct="Full"
ARGS_p="Variables.p"/>

再度、このエレメントによって、次のようないくつかの情報が渡されます。

- 記事を保持するリストのID (ARGS_cid)

- 各記事へのリンクの作成時に使用するテンプレートの名前(ARGS_ct)

- 元のページ・アセット(Home)のID (ARGS_p)。

リストはランクに基づいて順序付けされており、このコードによってリストがループされないため、ARGS_cidの値(theArticles.oid)は、コレクション内の最上位にランクされた記事のオブジェクトIDになります。これは、その記事がリスト内の最初の記事であるためです。

22.1.3 LeadSummaryエレメント

LeadSummaryページ・エントリによって、そのルート・エレメント(LeadSummary TemplateのTemplateエレメント)が呼び出されます。

ElementCatalog/FiscalNews/Article/LeadSummary.xml

このエレメントによって、次のようにTopStoriesコレクション内の最初の記事が書式設定されます。

- TeaserImageアソシエーションを使用して最初の記事に関連付けられたイメージ・ファイルを取得します。

- TeaserSummaryエレメントを呼び出して、イメージの書式設定コードを取得します。

- RENDER.GETPAGEURLタグを使用して、コレクション内の最初の記事のURLを取得します。

- imagefileアセット、記事全文へのハイパーリンクである記事のタイトル、サマリー段落および署名行を表示します。

まず、LeadSummaryによって、次のように記事がロードされ、LeadSummaryArticleという名前が付けられます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="LeadSummaryArticle"/>
<ASSET.SCATTER NAME="LeadSummaryArticle" PREFIX="asset"/>

次のように、そのTeaser imagefileアセットとして記事に関連付けられているアセットが取得され、そのファイルのリストがTeaserImageという名前で作成されます。

<ASSET.CHILDREN NAME="LeadSummaryArticle" LIST="TeaserImage" CODE="TeaserImageFile"/>

最後に、次のようにTeaserSummary Templateのページ・エントリがコールされ、それに対してリスト内に保持されているimagefileアセットのIDが渡されます。

<THEN>
<RENDER.SATELLITEPAGE PAGENAME="FiscalNews/ImageFile/TeaserSummary"
ARGS_cid="TeaserImage.oid"/>
</THEN>
</IF>

22.1.4 TeaserSummaryエレメント

TeaserSummaryページ・エントリによって、そのルート・エレメント(TeaserSummary TemplateのTemplateエレメント)が呼び出されます。

ElementCatalog/FiscalNews/ImageFile/TeaserSummary

imagefileアセットは、WebCenter Sitesデータベースに格納されているBLOBであり、データベースに格納されているBLOBは、ContentServerサーブレットではなく、BlobServerサーブレットによって処理される必要があるため、このエレメントによって、BlobServerのURLを使用するHTMLタグが取得されます。

たとえば、TeaserSummary Templateには、次のRENDER.SATELLITEBLOBタグがあります。

<RENDER.SATELLITEBLOB BLOBTABLE=ImageFile BLOBKEY=id BLOBCOL=urlpicture BLOBWHERE=Variables.asset:id BLOBHEADER= Variables.asset:mimetype SERVICE=IMG SRC ARGS_alt= Variables.asset:alttext ARGS_hspace=5 ARGS_vspace=5 />

このタグによって、<IMG SRC>というHTMLタグが作成されます。SRCは、BLOBWHERE=Variables.asset:id,によって渡されたIDを使用して識別されるImageFile表内のBLOBであり、その水平方向と垂直方向の間隔はどちらも5ピクセルです。

TeaserSummaryが終了すると、LeadSummaryに続きます。

22.1.5 LeadSummaryの再開

LeadSummaryの再開時、TopStoriesコレクション内の最初の記事のティーザ・イメージが取得されると、次のようにRENDER.GETPAGEURLを使用してその記事のURLが取得されます。

<RENDER.GETPAGEURL PAGENAME="FiscalNews/Article/Variables.ct"
cid="Variables.cid"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

MainStoryListエレメントによってLeadSummaryのページ・エントリがコールされたときに、Fullに設定されたct変数が渡されたことを思い出してください。そのため、LeadSummaryによってRENDER.GETPAGEURLに渡されるページ名は、実際にはFiscalNews/Article/Fullになります。

RENDER.GETPAGEURLによって、渡された情報に基づいて記事のURLが作成され、OUTSTRパラメータで指定されたとおり、referURLという名前の変数でそのURLがLeadSummaryに返されます。

LeadSummaryによって、次のようにHTML <A HREF>タグ内でreferURL変数が使用され、リンク、記事の概要および署名行が表示されます。

<A class="featurehead" HREF="Variables.referURL" REPLACEALL="Variables.referURL">
<csvar NAME="Variables.asset:description"/></A>
&nbsp;<BR/>
<span class="thumbtext"><csvar NAME="Variables.asset:abstract"/>
</span><BR/>
<span class="thumbcredit"><csvar NAME="Variables.asset:byline"/>
</span><BR/>

REPLACEALLタグが、<A HREF>というHTMLタグで属性として使用されていることに注意してください。HTMLタグ内でXML変数を使用する場合は、このタグを属性として使用する必要があります。

これでLeadSummaryが終了し、MainStoryListに続きます。

22.1.6 MainStoryListの再開

次に、MainStoryListによって、TopStoriesコレクション内の残りの記事がループされ、それらの記事がSummary Templateを使用して書式設定されます。

ElementCatalog/Article/Summary

MainStoryListが終了すると、Homeに続きます。

22.1.7 Homeの再開

Homeが再開され、WireFeedBoxページ・エントリへのコールが行われます。

22.2 コレクション・アセット内の記事アセットへのリンクのコーディング

動的に提供されるWebCenter Sitesページへのハイパーリンクのリストを作成するために、エレメントでURLが必要な場合は、次の例に示すように、RENDER.GETPAGEURLタグを使用して、コレクション・アセットの記事アセットのリンクをコーディングします。

この例で参照されているエレメントは、次のとおりです。

- ElementCatalog/FiscalNews/Page/SectionFront

- ElementCatalog/FiscalNews/Collection/PlainList

この例の目的上、リンクの作成方法に集中できるように、表示されるコードからすべてのエラー・チェックが削除されています。

次の各項では、リンクのコーディング方法について説明します。

- SectionFrontエレメント

- PlainListエレメント

22.2.1 SectionFrontエレメント

SectionFrontは、SectionFront TemplateのTemplateエレメント(ルート・エレメント)であり、ニュース、市場、株式などのメイン・セクション・ページに割り当てられます。

ElementCatalog/FiscalNews/Page/SectionFront.

SectionFrontエレメントによって書式設定されたページの1つのセクションには、図22-2に示すように、そのページ・アセットに関連付けられたSectionHighlightsコレクションからの記事へのリンクのリストが表示されます。

図22-2 記事のリンクのリスト

訪問者がセクションのリンクをクリックすると、SectionFrontエレメントが呼び出されます。まず、SectionFrontによって、次のようにcとcidの各変数を使用してページ・アセットがロードおよび分散され、それに対してSectionFrontPageという名前が付けられます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid"
NAME="SectionFrontPage"/>
<ASSET.SCATTER NAME="SectionFrontPage" PREFIX="asset"/>

cおよびcidの値が、起動元のリンクからSectionFrontエレメントに渡されます。そのリンクは、ホーム・ページまたはその他いくつかの場所のいずれかからのリンクである可能性があります。

SectionFrontには、複数のASSET.CHILDRENタグの後に、SectionHighlightsコレクションを取得する次のタグが含まれます。

<ASSET.CHILDREN NAME="SectionFrontPage" LIST="SectionHighlights" CODE="SectionHighlight"/>

このコードによって、CODE=SectionHighlights文を使用してコレクションが取得され、それがSectionHighlightsという同じ名前でリストとして格納されます。

次に、SectionFrontによって、次のようにPlainListテンプレート(コレクション・テンプレート)のページ・エントリがコールされます。

<RENDER.SATELLITEPAGE
pagename="FiscalNews/Collection/PlainList"
ARGS_cid="SectionHighlights.oid" ARGS_p="Variables.asset:id"/>

このコードによって、SectionHighlightsコレクションのID (cid)と、SectionFrontPageの名前を割り当てたページ・アセットである現在のページ・アセットのID (p)が渡されます。

22.2.2 PlainListエレメント

PlainListページ・エントリによって、そのルート・エレメント(PlainListテンプレートのテンプレート・エレメント)が呼び出されます。

ElementCatalog/FiscalNews/Collection/PlainList.

PlainListによって、コレクションから記事が抽出され、それぞれの記事のランクに基づいて、記事のサブヘッドラインとともにリスト形式で表示されます。このエレメントは、コレクション内のアセットが記事であることを前提にしています。コレクションをロードおよび分散する手順:PlainListによって、次のように(SectionFrontエレメントから渡された) cおよびcidの値を使用してコレクションがロードされ、分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="PlainListCollection"/>
<ASSET.SCATTER NAME="PlainListCollection" PREFIX="asset"/>

次に、PlainListによって、次のようにct変数がFullに設定されますが、これは、この変数の値が渡されなかったためです(Fullとは、記事テンプレートの名前です)。

<IF COND="IsVariable.ct!=true">
<THEN>
<SETVAR NAME="ct" VALUE="Full"/>
</THEN>
</IF>

続いて、PlainListによって、コレクション・アセット内のすべての子記事のリストが作成され、ランクに基づいて一覧表示され、theArticlesという名前が付けられます。

<ASSET.CHILDREN NAME="PlainListCollection" LIST="theArticles" OBJECTTYPE="Article" ORDER="nrank" CODE=-/>

このASSET.CHILDRENタグでは、OBJECTTYPEパラメータが使用されていることに注意してください。このタグでOBJECTTYPEパラメータを使用する場合、結果として得られる子のリストは、AssetRelationTreeおよび指定したタイプのアセット表(この場合は、Article表),間の結合となり、リストには両方の表からのデータが含まれます。

これで、後続のASSET.LOADタグが不要になります。なぜなら、これらの記事へのリンクを作成するためにPlainListエレメントによって使用されるデータが、Article表に格納されているためです。

PlainListによって、この記事のリストがループされ、RENDER.GETPAGEURLタグを使用して記事ごとにURLが作成されます。この場合(コードでは、子アセットごとに後続のASSET.LOADタグが使用されないため)、このエレメントでは次のようにRENDER.LOGDEPタグがループ内に含まれます。

<LOOP LIST="theArticles">
<RENDER.LOGDEP cid="theArticles.id" c="Article"/>
<RENDER.GETPAGEURL PAGENAME="FiscalNews/Article/
Variables.ct"
cid="theArticles.id"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

PlainListによって、RENDER.GETPAGEURLタグに対して、コレクション内の記事ごとにcidとpagenameが渡され、ctypeを使用してアセット・タイプが渡されます。ct変数がFullに設定されたため、このタグに渡されるページ名は、実際にはFiscalNews/Article/Fullになります。

RENDER.GETPAGEURLタグによって、OUTSTRパラメータで指定されたとおり、コレクション内の記事ごとにreferURL変数が返されます。次に、PlainListによって、referURL変数の値が使用され、<A HREF>というHTMLリンクが記事ごとに作成されます。

このコレクションを取得したASSET.CHILDRENタグによって、AssetRelationTreeおよびArticle表間の結合が作成されたため、PlainListでは、次のように記事のサブヘッドライン・フィールドを使用してリンクを作成できます。

<A class="wirelink" HREF="Variables.referURL"
REPLACEALL="Variables.referURL">
<csvar NAME="Variables.theArticles:subheadline"/>
</A>
</LOOP>

REPLACEALLタグが、このHTMLタグの属性として使用されていることに注意してください。HTMLタグ内でXML変数を使用する場合は、このタグをHTML属性として使用する必要があります。REPLACEALLの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

22.3 ct変数の使用

ct変数は、子テンプレートの概念を表します。子テンプレートは、代替テンプレートです。アセットの作成時にアセットにテンプレートが割り当てられるため、アセットのテンプレート(デフォルトの承認テンプレートとは異なる)のIDは、ASSET.LOADタグまたはASSET.CHILDRENタグを使用して取得する情報の一部になります。

ただし、場合によっては、アセットのデフォルトのテンプレートではないテンプレートを使用する必要があります。そのような場合は、ct変数を使用して代替テンプレートの名前を指定します。

たとえば、訪問者がFiscal Newsサイトを閲覧する場合、その訪問者が利用できるサイトの大半にはテキスト専用バージョンが用意されています。テキスト専用フォーマットはデフォルトのフォーマットではなく、コンテンツ・プロバイダがテキスト専用フォーマットを各自のアセットに割り当てることはありません。Fiscal Newsページ・エレメントは、代替のテキスト専用テンプレートのIDを適宜提供するようにコーディングされています。

サイト上のすべてのページで、同じエレメント(TextOnlyLinkエレメント)を使用して、そのページのプレーン・テキスト・リンクに埋め込まれたURLが確認されます。TextOnlyLinkエレメントによって、ページごとに正しいURLが返されます(これは、各ページ上のプレーン・テキスト・リンクからTextOnlyエレメントに対して、次のような必要な情報が渡されるためです)。

- リクエスト元のページのID

- プレーン・テキスト・リンク用の代替のテキスト専用テンプレート(子テンプレート)。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/FiscalNews/Page/SectionFront

- ElementCatalog/FiscalNews/Page/SectionFrontText

- ElementCatalog/FiscalNews/Common/TextOnlyLink

- ElementCatalog/FiscalNews/Page/ColumnistFront

次の各項では、ct変数を使用して、プレーン・テキストを表示するための代替テンプレートを指定する方法について説明します。

- SectionFrontエレメント

- TextOnlyLinkエレメント

- ColumnistFront

22.3.1 SectionFrontエレメント

Fiscal NewsサイトのSectionFrontエレメントを次に示します。

ElementCatalog/FiscalNews/Page/SectionFront.

SectionFrontは、ニュース、通貨、株式など、サイト上の標準のセクション・ページに割り当てられるTemplateアセットのTemplateエレメント(ルート・エレメント)です。

このエレメントにはCALLELEMENTタグが含まれます。

<CALLELEMENT NAME="FiscalNews/Common/TextOnlyLink">
<ARGUMENT NAME="ct" VALUE="SectionFrontText"/>
<ARGUMENT NAME="assettype" VALUE="Page"/>
</CALLELEMENT>

TextOnlyLinkは、プレーン・テキスト・リンクを作成するためのエレメントです。SectionFrontによって、このエレメントに対して、代替テンプレートの名前(ct=SectionFrontText)およびアセット・タイプの名前(assettype=Page)が渡されます。

22.3.2 TextOnlyLinkエレメント

TextOnlyLinkエレメントを次に示します。

ElementCatalog/FiscalNews/Common/TextOnlyLink

TextOnlyLinkが実行されると、ctの値があるかどうかがチェックされます。

<IF COND="IsVariable.ct!=true">
<THEN>
<SETVAR NAME="ct" VALUE="Variables.asset:templateText"/>
</THEN>
</IF>

この例では、SectionFrontエレメントによってct=SectionFrontTextが渡されたため、ctの値が存在します。

次に、TextOnlyLinkによって、RENDER.GETPAGEURLタグを使用してプレーン・テキスト・リンクのURLが取得され、SectionFrontからTextOnlyLinkに渡された変数に基づいて連結することでページ名が渡されます。

<RENDER.GETPAGEURL PAGENAME="FiscalNews/Variables.assettype/Variables.ct"
cid="Variables.asset:id"
c="Variables.assettype"
p="Variables.p"
OUTSTR="referURL"/>

TextOnlyLinkでは、ct=SectionFrontText、assettype=Pageであることを認識しています。そのため、FiscalNews/Variables.assettype/Variables.ctは、FiscalNews/Page/SectionFrontTextを意味します。

TextOnlyLinkには、(OUTSTRパラメータで指定されたreferURL変数内に) URLがあるため、次のように<A HREF>というHTMLタグを使用してプレーン・テキスト・リンクを作成できます。

<A class="contentlink" HREF="Variables.referURL"
REPLACEALL="Variables.referURL">
<img src="/futuretense_cs/bf/images/TextOnly.gif" width="22"
height="14" border="0" HSPACE="3"/>Plain Text</A><BR/>

REPLACEALLタグが、このHTMLタグの属性として使用されていることに注意してください。HTMLタグ内でXML変数を使用する場合は、このタグをHTML属性として使用する必要があります。REPLACEALLの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

続いて、TextOnlyLinkによって、ct変数が消去されます。

<REMOVEVAR NAME="ct"/>

訪問者がプレーン・テキスト・リンクをクリックすると、SectionFrontTextエレメントによって記事が書式設定され、ブラウザに表示されます。

22.3.3 ColumnistFront

ColumnistFrontエレメントを次に示します。

ElementCatalog/FiscalNews/Page/ColumnistFront

このエレメントによって、Fiscal Newsのコラムニストから提供されたストーリーを表示するWebフォーマット・ページが書式設定されます。

セクション・ページの右上隅にプレーン・テキスト・リンクを作成するために、ColumnistFrontによって、次のようにTextOnlyLinkがコールされます。

<CALLELEMENT NAME="FiscalNews/Common/TextOnlyLink">
<ARGUMENT NAME="ct" VALUE="ColumnistFrontText"/>
<ARGUMENT NAME="assettype" VALUE="Page"/>
</CALLELEMENT>

ここで、TextOnlyLinkによって、ColumnistFrontから渡された情報に基づいて、訪問者をFiscalNews/Page/ColumnistFrontTextに誘導するプレーン・テキスト・リンクが作成されます。

22.4 問合せアセットのテンプレートのコーディング

問合せアセットを使用して、表示するアセットを取得する場合は、WebCenter Sitesの標準エレメントであるExecuteQueryを使用して、この問合せアセットを実行できます。

Fiscal Newsでは、いくつかの問合せアセットが使用されています。図22-3に、ホーム・ページにワイヤー・フィード・ストーリーを一覧表示するために使用されている、Home Wire Feedという名前の問合せアセットを示します。

図22-3 ワイヤー・フィード・ストーリーを一覧表示する問合せアセット

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/FiscalNews/Page/Home

- ElementCatalog/FiscalNews/Query/WireFeedBox

- ElementCatalog/OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery

次の各項では、問合せアセットのテンプレートのコーディング方法について説明します。

- Homeエレメント

- WireFeedBoxエレメント

- ExecuteQueryエレメント

- WireFeedBoxの再開

22.4.1 Homeエレメント

HomeページのTemplateエレメントを次に示します。

ElementCatalog/FiscalNews/Page/Home

実行されると、まず、Homeによって、次のようにHomeページ・アセットがロードされ、そのアセットにHomePageという名前が付けられて、そのアセットのフィールドに情報が分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="HomePage"/>
<ASSET.SCATTER NAME="HomePage" PREFIX="asset"/>

cおよびcidの値がFiscal NewsのURLから渡されます。

いくつかのCALLELEMENTタグおよびRENDER.SATELLITEPAGEタグを過ぎて、次のASSET.CHILDRENタグがHomeに含まれます。

<ASSET.CHILDREN NAME="HomePage" LIST="WireFeedStories"
CODE="WireFeed"/>

このコード行では、OBJECTTYPEパラメータが使用されていないことに注意してください。WebCenter Sitesでは、CODE=WireFeedは、WireFeedアソシエーションを使用してHomePageアセットに割り当てられた問合せを検索して取得するうえで十分な情報であり、Homeでは問合せのIDのみが必要なので、AssetRelationTreeおよびQuery表間に結合を作成する必要がありません。WireFeed問合せは取得され、WireFeedStoriesとして格納されます。

次に、Homeによって、次のようにWireFeedBox Templateのページ・エントリがコールされ、それに対してWireFeedStoriesとして格納された問合せのcidが渡されます。

<RENDER.SATELLITEPAGE PAGENAME="FiscalNews/Query/WireFeedBox"
ARGS_cid="WireFeedStories.oid"
ARGS_p=Variables.asset:id/>

Homeによって、いくつかの情報(cid=WireFeedStories.oid文を使用した問合せのIDと、p=Variables.asset:id文を使用した元のページ・アセット(Home)のID)が渡されます。

22.4.2 WireFeedBoxエレメント

WireFeedBoxページ・エントリによって、そのルート・エレメント(WireFeedBoxテンプレートのテンプレート・エレメント)が呼び出されます。

ElementCatalog/FiscalNews/Query/WireFeedBox

このエレメントによって、ExecuteQueryエレメントが呼び出されて問合せが実行され、問合せによって返された記事アセットへのリンクのリストが表示されます。

まず、WireFeedBoxによって、次のようにHomeから渡された問合せアセットがロードされ、それに対してWireFeedBoxQueryという名前が付けられて、ASSET.SCATTER文を使用してそのすべてのフィールドから値が取得されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="WireFeedBoxQuery"/>
<ASSET.SCATTER NAME="WireFeedBox" PREFIX="asset"/>

Variables.cidは、Homeエレメントから渡されたWireFeedStories.oidです。

次に、WireFeedBoxによって、ExecuteQueryエレメントがコールされます。

<CALLELEMENT NAME="OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery">
<ARGUMENT NAME="list" VALUE="ArticlesFromWireQuery"/>
<ARGUMENT NAME="assetname" VALUE="WireFeedBoxQuery"/>
<ARGUMENT NAME="ResultLimit" VALUE="8"/>
</CALLELEMENT>

WireFeedBoxによって、問合せアセット、問合せの結果を保持するために作成するリストの名前、および制限を示す8が渡されます(この数字は、問合せからExecuteQueryエレメントにどれほど多くのアセットが返されても、そのうちの8個のみがExecuteQueryからWireFeedBoxに返されるようにするためです)。

22.4.3 ExecuteQueryエレメント

ExecuteQueryエレメントによって、問合せアセットが実行されます。

ElementCatalog/OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery

ページ・アセットにそのページのWire Feedとして割り当てることが可能な問合せアセットは、アセットのIDのみでなく、フィールド・データも返すようにコーディングされています。そのため、ExecuteQueryによって、WireFeedBoxに対して、最大8個の記事アセットとそれらのフィールドのいくつかからのデータが返されます。

このエレメントの最初のコード行はRENDER.UNKNOWNDEPSですが、これは、どのアセットが返されるかを知る方法がないので、それらの依存性を記録する方法がないためです。

ExecuteQueryが終了すると、WireFeedBoxが再開されます。

22.4.4 WireFeedBoxの再開

WireFeedBoxが再開され、ExecuteQueryから返された記事のリストがループされ、RENDER.GETPAGEURLタグを使用して記事ごとにURLが取得されます。

ExecuteQueryからどの記事アセットが返されるかを知る方法がないため、次のように、パブリッシュ方法がディスクへのエクスポートである場合には、非承認アセットをフィルタで除外するように、ループ内にRENDER.FILTERタグが含められます。

<RENDER.FILTER LIST="ArticlesFromWireQuery" LISTVARNAME="ArticlesFromWireQuery" LISTIDCOL="id"/>
<if COND="ArticlesFromWireQuery.#numRows!=0">
<then>
<LOOP LIST="ArticlesFromWireQuery">
<RENDER.GETPAGEURL PAGENAME="FiscalNews/Article/WireStory"
cid="ArticlesFromWireQuery.id"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>
<A class="wirelink" HREF="Variables.referURL" REPLACEALL="Variables.referURL"><csvar NAME="ArticlesFromWireQuery.subheadline"/></A><P/>
</LOOP>
</then>
</if>

RENDER.GETPAGEURLタグによって、referURLという名前の変数でリスト内の記事ごとのURLが返されます。WireFeedBoxによって、referURL変数からの値を使用して記事へのリンクが作成されます。これには、サブヘッドライン・フィールド(Wire Feed問合せから返されたフィールドの1つ)のコンテンツが、ハイパーリンク化されたテキストとして使用されます。

REPLACEALLタグが、このHTMLタグの属性として使用されていることに注意してください。HTMLタグ内でXML変数を使用する場合は、このタグをHTML属性として使用する必要があります。REPLACEALLの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

22.5 テンプレートを使用しない記事アセットの表示

図22-4に、この記事を友人に電子メールで送信する機能が用意されているFiscal Newsから提供された記事からの電子メール・フォームの例を示します。

図22-4 電子メール・フォーム

明らかに、Fiscal News開発者は、Fiscal Newsのコンテンツ・プロバイダが記事のDisplay Style (Template)として電子メール・フォームを記事に割り当てることを望んでいません。そのため、記事の電子メール・フォームを作成するための電子メール・エレメントをポイントするTemplateアセットは用意されていません。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/FiscalNews/Article/Full

- ElementCatalog/FiscalNews/Article/AltVersionBlock

- ElementCatalog/FiscalNews/Util/EmailFront

次の各項では、テンプレートなしで記事アセットを表示する方法について説明します。

- Fullエレメント

- AltVersionBlockエレメント

- EmailFrontエレメント

22.5.1 Fullエレメント

記事のFull Templateを次に示します。

ElementCatalog/FiscalNews/Article/Full

このエレメントによって、記事の全文が表示される場合に記事の書式設定コードが提供されます。これによって、次のようなアイテムが表示されます。

- サイトのバナー

- 左側のナビゲーション列

- 一連の関連ストーリー

- 記事のテキスト

- 記事の写真

- そのストーリーの印刷用リンク

- そのストーリーの電子メール送信用リンク

いくつかのRENDER.SATELLITEPAGEタグおよびCALLELEMENTタグを過ぎて、次のエレメントがFULLに含まれます。

<CALLELEMENT NAME="FiscalNews/Article/AltVersionBlock"/>

22.5.2 AltVersionBlockエレメント

この例では、記事の印刷バージョンまたは電子メール・バージョンのURLを取得できるAltVersionBlockエレメントを示します。

ElementCatalog/FiscalNews/Article/AltVersionBlock

AltVersionBlockは、2つのRENDER.GETPAGEURLタグで構成される短いエレメントです。最初のRENDER.GETPAGEURLタグによって、記事の印刷バージョンのURLが取得されます。2番目のRENDER.GETPAGEURLタグによって、ストーリーの電子メール・バージョンのURLが取得されます。

Fiscal Newsl開発者は、サイトが静的サイトであっても、ストーリーの電子メール・バージョンには動的URLを望んでいることから、2番目のRENDER.GETPAGEURLタグでDYNAMICパラメータが使用されています。

2番目のRENDER.GETPAGEURLタグには、次のコードが含まれます。

<RENDER.GETPAGEURL PAGENAME="FiscalNews/Util/EmailFront"
cid="Variables.asset:id"
c="Article"
DYNAMIC="true"
OUTSTR="referURL"/>

AltVersionBlockによって、EmailFrontページ・エントリのpagename、cの値、およびcidが渡され、DYNAMICパラメータがtrueに設定されます。このタグによって、(パブリッシュ方法がディスクへのエクスポートである場合でも)記事の動的URLが作成され、OUTSTRパラメータで指定されたとおり、referURLという名前の変数でそのURLが返されます。

22.5.3 EmailFrontエレメント

次の例では、EmailFrontは、AltVersionBlockからRENDER.GETPAGEURLエレメントに渡されるページ名です。EmailFrontには対応するテンプレートがないため、WebCenter Sitesでは、デフォルトでEmailFrontのSiteCatalog内にページ・エントリが作成されません。Fiscal News開発者は、このエレメントのSiteCatalogエントリをOracle WebCenter Sites Explorerから手動で作成しました。

ElementCatalog/FiscalNews/Util/EmailFront

このエレメントによって、訪問者が電子メール送信対象として選択した記事の最初の段落を表示するフォームが作成されます。

まず、EmailFrontによって、次のように記事アセットがロードされます。

<ASSET.LOAD TYPE="Article" OBJECTID="Variables.cid" NAME="EmailFront"/>
<ASSET.SCATTER NAME="EmailFront" PREFIX="asset"/>

次に、電子メール・フォームが作成される前に、HTML FORMタグを使用して、ページのいくつかの部分が書式設定されます。

<FORM NAME="mailform" onSubmit="return checkEmail();" METHOD="POST" ACTION=...

続いて、EmailFrontによって、次のようにLeadSummaryページ・エントリがコールされて、フォーム内の記事のサマリーが表示されます。

<RENDER.SATELLITEPAGE
ARGS_pagename="FiscalNews/Article/LeadSummary"
ARGS_cid="Variables.cid"
ARGS_ct="Full"
ARGS_p="Variables.p"/>

LeadSummaryエレメントの詳細は、「ベーシック・モジュラ・デザインの作成」を参照してください。

22.6 サイト・ナビゲーション情報の表示

Fiscal Newsサイトの開発者は、WebCenter Sitesインタフェースのサイト・ナビゲーション・タブを使用して、Fiscal Newsサイトの基本構造の順序付けを行ったため、SitePlanTree表から情報を抽出して、サイトのナビゲーション機能を作成できます。

たとえば、SitePlanTree表からサイトの構造に関する情報を抽出することで、Fiscal Newsのホーム・ページ上部のナビゲーション・バーが作成されます。

SitePlanTree表から情報を抽出するには、WebCenter SitesのSITEPLANタグ・ファミリを使用します。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/FiscalNews/Article/Home

- ElementCatalog/Pagelet/Common/SiteBanner

- ElementCatalog/FiscalNews/Site/TopSiteBar

次の各項では、サイト・ナビゲーション情報を表示する方法について説明します。

- Homeエレメント

- SiteBannerエレメント

- TopSiteBarエレメント

- SiteBannerの再開

22.6.1 Homeエレメント

Oracle WebCenter Sites Explorerを使用し、Home Templateのテンプレート・エレメントを開いて調べることができます。

ElementCatalog/FiscalNews/Page/Home

このTemplateの最初のRENDER.SATELLITEPAGEタグが続きます。

<RENDER.SATELLITEPAGE PAGENAME="FiscalNews/Pagelet/Common/SiteBanner"/>

22.6.2 SiteBannerエレメント

この例のルート・エレメントを呼び出すSiteBannerページレットを次に示します。

ElementCatalog/FiscalNews/Common/SiteBanner

SiteBannerによって、バナーのイメージ(Fiscal Newsのロゴおよび広告イメージ)が収集され、サイトのメイン・セクションへのナビゲーション・リンクを作成するためのエレメントがコールされます。

SiteBannerエレメントにはCALLELEMENTタグが含まれます。

<CALLELEMENT NAME="Fiscal News/Site/TopSiteBar"/>

22.6.3 TopSiteBarエレメント

この例のTopSiteBarエレメントを次に示します。

ElementCatalog/FiscalNews/Site/TopSiteBar

TopSiteBarが実行され、Fiscal Newsサイトのメイン・セクションへのナビゲーション・リンクが作成されます。

次の各項では、サイト上のページのリンクの作成方法について説明します。

- 「Home」ページのリンクの作成

- 「Home」ページの子ページへのリンクの作成

22.6.3.1 「Home」ページのリンクの作成

「Home」ページのリンクを作成するために、まず、TopSiteBarによって、次のように「Home」ページがロードされ、それに対してtargetという名前が付けられて、そのIDフィールドから値が取得され、その値が出力変数pageidに格納されます。

<ASSET.LOAD TYPE="Page" NAME="target" FIELD="name" VALUE="Home" DEPTYPE="exists"/>
<ASSET.GET NAME="target" FIELD="id" OUTPUT="pageid"/>

ASSET.LOADタグによって、DEPTYPEパラメータを使用して依存性タイプがデフォルトのexactからexistsに変更されることに注意してください。このようなリンク(ナビゲーション・バーのリンク)の場合、依存性がexists依存性である方が適しています。

続いて、TopSiteBarによって、次のようにpageidを使用してRENDER.GETPAGEURLから「Home」ページのURLが取得されます。

<RENDER.GETPAGEURL PAGENAME="FiscalNews/Page/Home"
cid="Variables.pageid"
c="Page"
OUTSTR="referURL"/

次に、TopSiteBarによって、次のようにページ・アセットの名前がそのNameフィールドから抽出され、それがハイパーリンクのテキストとして使用されます。

<ASSET.GET NAME="target" FIELD="name" OUTPUT="thepagename"/>
<A class="sectionlinks" HREF="Variables.referURL" REPLACEALL="Variables.referURL"><csvar NAME="Variables.thepagename"/></A>

REPLACEALLタグが、このHTMLタグの属性として使用されていることに注意してください。HTMLタグ内でXML変数を使用する場合は、このタグをHTML属性として使用する必要があります。REPLACEALLの詳細は、「HTMLタグの変数」を参照してください。

22.6.3.2 「Home」ページの子ページへのリンクの作成

コードの次の部分では、TopSiteBarによって、Homeページの子ページへのリンクが作成されます。Homeページの子ページを特定するには、まず、TopSiteBarでHomeページのノードIDを特定する必要があります。

ページ・アセットのノードIDは、そのオブジェクトIDとは次の点で異なります。

- オブジェクトIDは、アセット表からアセットに関する情報を抽出するために使用します。

- ノードIDは、SitePlanTree表からページ・アセットに関する情報を抽出するために使用します。

まず、TopSiteBarによって、次のようにHomeページのノードIDが特定されます。

<ASSET.GETSITENODE NAME="target" OUTPUT="PageNodeId"/>

続いて、次のように、その情報を使用してHomeページがsiteplanノード・オブジェクトとしてロードされます。

<SITEPLAN.LOAD NAME="ParentNode" NODEID="Variables.PageNodeId"/>

Homeページ・ノードが特定されてロードされると、TopSiteBarによって、次のようにHomeページの子ノードが取得でき、それらがPeerPagesという名前が付けられたリストに格納され、それぞれのランクに基づいて順序付けされます。

<SITEPLAN.CHILDREN NAME="ParentNode" TYPE="PAGE" LIST="PeerPages" CODE="Placed" ORDER="nrank"/>

ここで、TopSiteBarによって、次のように最上位レベルのすべての子ノードがループされ、RENDER.GETPAGEURLタグを使用して各ページへのリンクのURLが作成されます。

<IF COND="IsList.PeerPages=true">
<THEN>
<LOOP LIST="PeerPages">&nbsp;|&nbsp;
<ASSET.LOAD NAME="ThePage" TYPE="Page"
OBJECTID="PeerPages.oid"/>
<ASSET.GET NAME="ThePage" FIELD="name"
OUTPUT="thepagename"/>
<ASSET.GET NAME="ThePage" FIELD="template"
OUTPUT="pagetemplate"/>
<RENDER.GETPAGEURL PAGENAME="FiscalNews/Page/
Variables.pagetemplate"
cid="PeerPages.oid"
c="Page"
OUTSTR="referURL"/>
<A class="sectionlinks" HREF="Variables.referURL"
REPLACEALL="Variables.referURL">
<csvar NAME="Variables.thepagename"/>
</A>

この例でページ名がどのように構成されているかに注目してください。2番目のASSET.GET文によって、ページのTemplateの名前がそのtemplateフィールドから取得されます。

<ASSET.GET NAME="ThePage" FIELD="template"
OUTPUT="pagetemplate"/>

続いて、その情報が、RENDER.GETPAGEURLタグに渡されるPAGENAMEパラメータで次のように使用されます。

PAGENAME="FiscalNews/Page/Variables.pagetemplate"/>

したがって、ページ・アセットのテンプレートがSectionFrontの場合は、この引数文によってpagename=FiscalNews/Page/SectionFrontが渡されることになります。また、ページ・アセットのテンプレートがAboutUsの場合は、この引数文によってpagename=FiscalNews/Page/AboutUsが渡されることになります。

22.6.4 SiteBannerの再開

SiteBannerは、TopSiteBarへのコール後に終了します。SiteBannerエレメントが、サイト内の各ページで呼び出されます。

SiteBannerにはSiteCatalog表にページ・エントリがあるため、訪問者が初めてFiscal Newsサイト上でページを要求すると、TopSiteBarによって作成されるナビゲーション・バーの結果がキャッシュされます。これにより、サイトでは、訪問者がその後訪問するページごとにTopSiteBarエレメントを再度呼び出す必要がなくなるため、パフォーマンスの速度が向上します。

22.7 アセット以外の情報の表示

場合によっては、WebCenter Sitesデータベースにアセットとして格納されていない情報をレンダリングして表示する必要があります。たとえば、Fiscal Newsサイトでは、各ページに今日の日付が表示されます。日付は、アセットとして格納できる情報ではありません。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/FiscalNews/Article/Home

- ElementCatalog/Common/ShowMainDate

次の各項では、アセット以外の情報を表示する方法について説明します。

- Homeエレメント

- ShowMainDateエレメント

22.7.1 Homeエレメント

この例では、Home TemplateのTemplateエレメントを次に示します。

ElementCatalog/FiscalNews/Page/Home

このエレメントの3番目のCALLELEMENTタグは、ShowMainDateエレメントを呼び出します。

<CALLELEMENT NAME=FiscalNews/Common/ShowMainDate/>

22.7.2 ShowMainDateエレメント

この例のShowMainDateエレメントを次に示します。

ElementCatalog/FiscalNews/Common/ShowMainDate

ShowMainDateが実行されます。メインのコード行は次のとおりです。

<span class="dateline"><csvar NAME="CS.Day CS.Mon CS.DDate, CS.Year"/></span>

これによって日付が計算され、その値がHomeエレメントに返され、ページ上部(ナビゲーション・バーの下でストーリーのメイン・リストの上)に表示されます。

このエレメントによって、簡単な計算が実行され、ブラウザのウィンドウにレンダリングされるHTMLコードにその値が出力されます。これによって書式設定されるコンテンツ・アセットも、これをルート・エレメントとして使用するTemplateアセットもありません。また、このエレメントにはSiteCatalogエントリはありません(その結果(日付)が、「Home」ページがレンダリングされるたびに計算される必要があるため)。

23 コレクション・アセット、問合せアセットおよびページ・アセットの作成

次の項では、オンライン・サイトの機能を実装する、ページ、問合せ、コレクションの各アセットの作成方法を説明します。

- アセットの作成について

- コレクション・アセットの作成

- 問合せアセットの作成

- ページ・アセットの作成

23.1 アセットの作成について

WebCenter Sitesで配信されるコア・アセット・タイプは、基本的なサイト・デザイン・ロジックを提供します。テンプレート・アセットの作成方法は、「コンテキスト内編集およびプレゼンテーション編集用テンプレートのコーディング」を参照してください。テンプレート・アセットは他のアセットに割り当てるので、サイト・デザイン・アセット・タイプを作成する前にテンプレートを作成するのが一般的です。

どのタイプのアセットを使用する場合の手順も非常に似ており、『Oracle WebCenter Sitesの使用』で詳しく説明しています。この章では、コレクション、問合せ、ページの各アセット・タイプに固有の手順を紹介します。

23.2 コレクション・アセットの作成

1つのコレクション・アセットには、1つのタイプのアセットの順序付けリストが格納されます。コレクション・アセットを作成(または設計)するには、そのコレクション・アセットに名前を付け、それに対する問合せアセットを選択します。デフォルトでは、問合せアセットを3つまで選択できます。コレクション・アセットに対する問合せが、サイト・デザインでより多く必要な場合は、追加の問合せに対するアソシエーションをさらに作成できます。アソシエーションの作成の詳細は、「ベーシック・アセット・タイプの作成」の「 (オプション)アソシエーション・フィールドの構成」を参照してください。

コレクションでは、問合せアセットを使用して、そのコレクションに使用できるアセットのリストを取得します。コレクションを作成(または移入)するには、その問合せを実行し、問合せの結果からアセットを選択し、選択したアセットをランキングして順序付けます。このランキングされ、順序付けられたリストがコレクションです。

コレクションの使用は、レンダリングされたページに表示されるコンテンツを最新の状態に維持する方法の1つです。たとえば、複数のコレクションを使用するサイトを設定できます。アセットに表示するコレクションを選択する場合、パブリッシャまたはコンテンツ・コントリビュータは、次のいずれかを実行することで、そのアソシエーションによって識別されたコンテンツを変更できます。

- ツリーから別のコレクションを選択します。

- 割り当てられたコレクションを作成し、その中で別のアセットを選択します。

この項には次のトピックが含まれます:

- 開始する前に

- コレクション・アセットの作成

- コレクション・アセットの共有

23.2.1 開始する前に

コレクション・アセットを作成する前に、次の点に注意してください。

- コレクションには少なくとも1つの問合せが必要です。そのため、コレクションを作成する前に、必ず問合せを作成してください。

- コレクションにテンプレートを割り当てるため、コレクション・アセットを作成する前にテンプレート・アセットも作成してください。

コレクションを作成する前に、それに割り当てられるテンプレート・アセットのコーディング方法を決定する必要があります。たとえば、コレクションに対して100個のアセットを選択しても、そのうちの5つのみを表示するようにテンプレートがコーディングされていると、次のようになります。

- それらのアセットを表示するレンダリングされたページには、最初の5つしか表示されません。

- ページには最初の5つしか表示されないにもかかわらず、WebCenter Sitesは100個のアセットをすべてソートする必要があるため、必要以上にページのレンダリングに時間がかかります。

コレクションの構築の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

23.2.2 コレクション・アセットの作成

コレクション・アセットは、Adminインタフェースを介して作成できます。

注意:

この手順を使用するには、作業するサイトに対してコレクション・アセット・タイプを有効にしておく必要があります。有効になっているかどうかは、手順4で確認できます。

1. Adminインタフェースを開きます。

2. 「開始する前に」の手順が完了していることを確認します。

3. ボタン・バーで「新規」をクリックします。

4. アセット・タイプのリストから新規コレクションを選択します。(コレクション・アセット・タイプが有効ではない場合、このオプションは表示されません。)

「コレクション」フォームが開きます。

5. (必須)「名前」フィールドに、ページの説明的な名前を入力します。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

6. 「説明」フィールドに、コレクションの短い説明を入力します。最大で128文字入力できます。

7. (必須)「サブタイプ」フィールドで、このコレクションが保持するアセットのタイプを選択します。

注意:

コレクションのサブタイプは問合せによって制御されます。特定のアセット・タイプに対して問合せを設定すると、そのアセット・タイプが「サブタイプ」フィールドの値になります。そのため、「サブタイプ」フィールドには、問合せが作成されたあらゆるアセット・タイプがリストされます。問合せアセットの作成の詳細は、「問合せアセットの作成」を参照してください。

8. 「テンプレートの選択」フィールドで、ドロップダウン・リストからテンプレート・アセットを選択します。

9. 「カテゴリ」フィールドで、ドロップダウン・リストからカテゴリを選択します。(カテゴリを選択しないと、リスト上の最初のアイテムがデフォルトで選択されます。)

10. 「キーワード」フィールドに、将来このコレクションを検索するときに「詳細検索」フォームで検索条件として使用可能なキーワードを入力します。

11. 「関連する問合せ」セクションで、最大3つの問合せを選択します。このコレクションに対して選択するすべての問合せから、同じタイプのアセットが返される必要があります。

12. 「保存」をクリックします。

23.2.3 コレクション・アセットの共有

コレクション・アセットを共有する前に、次の点を検討してください。

- 1つのサイトでコレクションを作成することによって、そのコレクションが共有先のすべてのサイトで作成されます。サイトによって異なるアセットが含まれるコレクションを作成することはできません。

- 共有コレクションで使用される問合せアセットは、そのコレクションの共有先のすべてのサイトに共有されるアセットのみを返すようにコーディングされる必要があります。

- 他の共有アセットと同様に、コレクションに割り当てられるテンプレートも他のサイトに共有されていることを確認してください。

アセットの共有の基本手順は、『Oracle WebCenter Sitesの管理』のブログ・アセットの共有に関する項を参照してください。

23.3 問合せアセットの作成

問合せアセットには、データベースから他のアセットのリストを取得するデータベース問合せが格納されます。ただし、問合せがコレクションに対して使用される場合、その問合せは1つのタイプのアセットしか返すことができません。

次の項では、問合せアセットについて説明します。

- 問合せアセットとその他のアセットの使用方法

- 問合せの格納方法

- 問合せ用の一般的なフィールド

- 問合せアセットの作成を開始する前に

- 問合せアセットの作成

- 問合せアセットの共有

- 問合せアセットのプレビューと承認

23.3.1 問合せアセットとその他のアセットの使用方法

WebCenter Sitesでは、コレクション・アセットでの問合せの使用方法が、他のアセットの場合とは異なります。

- コレクションを作成(移入)する場合は、1つ以上の問合せアセットを実行し、結果のリストから必要なアセットを選択して順序付けます。そのコレクションは、問合せの結果セットから選択したアセットの静的リストになります。

- ページ・アセットに対する問合せを選択するには、非公式の関係と名前付きアソシエーションのいずれかを使用します。その他のアセット・タイプ(記事など)に対する問合せを選択するには、名前付きアソシエーションを使用します。
アセットがレンダリングされる際に、そのアセットによって問合せが直接呼び出されることはありません。アセットを書式設定するテンプレート・エレメントか、問合せを書式設定するテンプレート・エレメントのいずれかが、次のようなWebCenter Sitesの標準エレメントを呼び出すようにコーディングされます。

OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery

このエレメントが関連付けられているアセットがレンダリングされると、このエレメントによって問合せアセットが実行されます。つまり、その結果セットは動的になります。

23.3.2 問合せの格納方法

問合せアセットは、次の2つの方法のいずれかでそのデータベース問合せを格納できます。

- 直接的。「問合せ」フォームの「SQL問合せ」フィールドに問合せを直接記述できます。問合せに対して標準SQLを使用することもできますが、WebCenter Sitesシステムで外部の検索エンジンを使用している場合は、適した検索エンジン問合せを使用することも可能です。

- 間接的。エレメント内に問合せを記述し、そのエレメントを「問合せ」フォームの「エレメント名」フィールドで指定することによって、問合せアセットにそのエレメントの場所を格納できます。問合せのエレメントには、その他のエレメントと同様に、XML、JSP、JavaScript、HTMLなどを使用できます。

次のコードは、News Wire Feedという名前の問合せの例です。この問合せは直接格納されます。つまり、「問合せ」フォームの「SQL問合せ」フィールドにSQL問合せが直接記述されます。

SELECT DISTINCT Article.id, Article.name, Article.updateddate,
Article.subheadline, Article.abstract, Article.description,
Category.description AS category, StatusCode.description AS
statusdesc FROM Article, Category, AssetPublication, StatusCode
WHERE Article.status!='VO' AND Article.category=Category.category
AND Article.status=StatusCode.statuscode AND Category.assettype='Article'
AND Article.source='WireFeed' AND Article.category='n' AND Article.id =
AssetPublication.assetid AND AssetPublication.pubid = 968251170475
ORDER BY Article.updateddate DESC

23.3.3 問合せ用の一般的なフィールド

問合せで使用する可能性のあるいくつかのWebCenter Sitesフィールドを次に示します。このうちの4つは前述のNews Wire Feed問合せの例で使用されています。

- status

- updateddate

- source

- category

- startdateとenddate

この項の残りの部分では、このリストに含まれるフィールドについて説明します。

status

すべてのアセットには、statusが含まれます。WebCenter Sitesでは、アセットを作成すると、そのタイプのアセットを保持する表に行が追加され、そのステータスは、作成済を示すPLに設定されます。

表23-1では、WebCenter Sitesで使用されるステータス・コードを一覧表示して定義しています。

表23-1 ステータス・コード

ステータス・コード

定義

PL

作成済

ED

編集済

RF

受信済(たとえば、XMLPostから)

UP

Xcelerate 2.2からアップグレード済

VO

削除済(void)

これらのコードは、データベースのStatusCode表に一覧表示されています。

WebCenter Sitesでは、アセットを削除すると、そのステータスがVOに変更され、「名前」フィールド内の文字列がそのオブジェクトIDに変更されます。

ステータスがVOであるアセットを除外するように問合せを記述してください。例: WHERE Article.status!='VO'

updateddate

updateddateフィールドの情報は、statusフィールドの情報が現在の状態に変更された日付を表します。サイトのデザインによっては、この日付に基づいてアセットを返す問合せを使用できます。

source

sourceフィールドは、アセットが最初に作成された場所を特定できる、WebCenter Sitesのデフォルトのフィールドです。これは、必須ではありません。

サイトへのソースの追加は、ツリー内の「管理」タブで行います。「ベーシック・アセット・タイプの作成」の「 (オプション)ソースの構成」を参照してください。

アセットでソースを使用する場合、ソースをパラメータとして使用する問合せを記述できます。前述のNews Wire Feed問合せの例では、AND Article.source='WireFeed'文によって、「ソース」フィールドの値がWireFeedである記事のみがこの問合せによって選択されるようにしています。

category

categoryは、サイトに適用される規則に従ってアセットを分類できる、WebCenter Sitesのデフォルトのフィールドです。これは、必須ではありません。

たとえば、銀行サイトを使用している場合、Personal Finance、Banking and Loans、Rates and Bonds、Newsなどのカテゴリを使用できます。サイトへのカテゴリの追加は、ツリー内の「管理」タブで行います。「ベーシック・アセット・タイプの作成」の「(オプション)カテゴリの構成」を参照してください。

アセットでカテゴリを使用する場合、カテゴリをパラメータとして使用する問合せを記述できます。前述のNews Wire Feed問合せの例では、Article.category='n'文によってニュース・カテゴリからの記事アセットが含まれます。

pubid

pubidは、サイト(以前の用語ではパブリケーション)を識別する一意の値です。WebCenter Sitesでは、アセットを作成すると、そのアセットに関する情報がいくつかのデータベース表に書き込まれます。その1つは、AssetPublication表です。

AssetPublication表のアセットの行には、そのアセットが作成された対象サイトのpubidが含まれます。アセットが共有されている場合、AssetPublication表には、アセットが共有されているサイトごとに1つの行が含まれます。たとえば、記事アセットが2つのサイトで利用できる場合、AssetPublication表のその記事に対して2つの行が存在することになります。

システム上に1つのWebCenter Sitesサイトしかない場合や、問合せ結果がサイト固有になる必要がない場合は、pubidを考慮するように問合せをコーディングする必要はありません。ただし、問合せによって別のサイトからアセットが返されないようにするには、サイトのpubidに基づいてアセットを制限するよう問合せをコーディングします。

startdateとenddate

いずれのサンプル・サイトでも、startdateフィールドとenddateフィールドは使用されていませんが、WebCenter Sitesデータベースにはその情報を格納するための列があります。これらのフィールドは、アセットに時間制限を割り当てることができるように用意されています。アセット・タイプでstartdateフィールドとenddateフィールドを使用すると、それらのフィールドに格納されている日付に基づいてアセットを選択する問合せを作成できます。

23.3.4 問合せアセットの作成を開始する前に

問合せアセットの作成を開始する前に、次の点を検討してください。

- コレクション以外のアセットで使用される問合せアセットでは、テンプレートの使用は必須ではありません。識別、実行および結果の表示を行う問合せアセット専用にテンプレート・エレメントを作成することも、その処理を実行するようにページ・アセットのテンプレート・エレメントをコーディングすることもできます。

- コレクションに対する問合せを記述する場合、そのアセット・タイプに必要なフィールドを選択するようにコーディングしてください。WebCenter Sitesは、アセット・タイプの必須フィールドからの情報を受け取るようにプログラムされているため、その情報をコレクションの作成フォームに表示できます。

- コレクション専用の問合せアセットでは、テンプレートを使用する必要はありません。コレクションに割り当てられるテンプレート・エレメントによって、コレクションのアセット・リスト内のアセットが書式設定されます。

- パフォーマンス上の理由から、効率的な問合せを作成してください。次に例を示します。

- 実行して問合せの結果を表示するエレメントにではなく、問合せにできるだけ多くのロジックを含めてください。たとえば、記事のリストをフィルタまたは制限する場合、リスト全体を返すように問合せをコーディングし、エレメント・コードを使用してそのリストを制限するのではなく、問合せによってフィルタまたは制限ステップが実行されることによって、完成されたリストがエレメントに返されるようにします。

- 問合せでは、エレメントによって表示される情報のみが返されるようにします。

- コレクションに対する問合せアセットは、1つのタイプのアセットしか返すことができません。

23.3.5 問合せアセットの作成

問合せアセットは、Adminインタフェースを介して作成できます。

1. Adminインタフェースを開きます。

2. ボタン・バーで「新規」をクリックします。

3. アセット・タイプのリストから「新規問合せ」を選択します。(問合せアセット・タイプは、サイトに対して有効にする必要があります。)

「問合せ」フォームが開きます。

4. (必須)「名前」フィールドに、問合せアセットの説明的な名前を入力します。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

5. In the 「説明」フィールドに、問合せの短い説明を入力します。最大で128文字入力できます。

6. 「テンプレート」フィールドで、ドロップダウン・リストからテンプレート・アセットを選択します。

7. 「カテゴリ」フィールドで、ドロップダウン・リストからカテゴリを選択します。(カテゴリを選択しないと、リスト上の最初のアイテムがデフォルトで選択されます。)

8. 「問合せの結果」フィールドで、この問合せが返すアセットのタイプを選択します。(問合せは、コレクションによって使用される1つのタイプのアセットのみを返すことができます。)

9. 次のいずれかを行います:

- このアセットに問合せを直接格納するには、「データベース」を選択し、「SQL問合せ」フィールドで問合せを記述します。

- エレメント内に問合せを記述した場合、「エレメント」を選択して、「エレメント名」フィールドにそのエレメントの完全な名前を入力します。

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

23.3.6 問合せアセットの共有

問合せアセットを別のサイトと共有する場合は、次のヒントを検討してください。

- 問合せ結果がサイト固有になるようにする場合は、問合せによってアセットが共有先でないサイトに返されることがないように、pubidにWHERE句を含めてください。

- たとえば、コレクションに対する問合せと静的サイトに対する問合せのいずれかで、次の文を使用できます。
WHERE AssetPublication.pubid = SessionVariables.pubid

これは、コレクションを作成する場合やディスクへのエクスポート機能を使用する場合には、必ずSessionVariables.pubidを設定するためです。

- 問合せが動的サイトで使用される場合も、pubidのIDをExecuteQueryエレメントに渡すようにエレメントをコーディングするか、SessionVariables.pubid変数を設定するようにエレメントをコーディングする場合、同じ文を使用できます。

- ページ・アセットは共有できないため、問合せアセットによってページ・アセットが返される場合、それらの問合せアセットを共有しないでください。

- 他の共有アセットと同様に、問合せでテンプレートを使用する場合、問合せに割り当てられるテンプレートも他のサイトと共有されていることを確認してください。

23.3.7 問合せアセットのプレビューと承認

まず、すべての問合せアセットに独自のテンプレートがあるとはかぎらないことに留意してください。問合せアセットがページ・アセットで使用されるように設計されていて、それが問合せを実際に書式設定するページ・アセットのテンプレートである場合、問合せをプレビューするためにページをプレビューする必要があります。

オンライン・サイトが動的サイトである場合(つまり、サーバーへのミラーリングのパブリッシュ方法を使用する場合)、パブリッシュされたアセットによっては、管理システムで問合せアセットによって返されるアセットが配信システムの場合とは異なる可能性があります。

そのため、問合せをプレビューしてそれを承認するかどうかを決定する場合、(プレビューに使用している)管理システム上でその問合せによって返されるアセットが、配信システムでパブリッシュ後にその問合せによって返されるアセットとは異なる可能性があることに留意してください。

23.4 ページ・アセットの作成

ページ・アセットは、他のアセットに対する参照を格納し、設計者が実装しているデザインに従ってアセットを整理するサイト・デザイン・アセットです。

これらのページ・アセットは、サイトのセクション(基本的に、サイトの構造や構成)を表します。提供される可能性のあるレンダリング対象ページを1つずつすべて表すことはありません。この構造的構成は、主にWebCenter Sitesユーザーのために用意されています。これはサイトを整理するための唯一の方法ではありませんが、完成済のWebサイトに似た構造を編集者が確認する際に便利です。

一般的に、ページ・アセットはサイトの設計時に一度だけ作成します。コレクション、問合せ、記事などをページ・アセットに関連付け、ページ・アセットに関連付けるアセットのタイプを書式設定するテンプレート・エレメントをコーディングします。

ページ・アセットに対して正しいコンテンツを選択するには、サイトが構造化されるしくみと、ページ・アセットのテンプレート・エレメントが何を実行するように設計されているかに精通している必要があります。そのため、サイト開発者(エレメントをコーディングし、テンプレート・アセットを作成する担当者)がサイトのページ・アセットを作成するのが一般的です。

この項には次のトピックが含まれます:

- ページ・アセット・モデルの理解

- ページ属性の設計方法

- ページ・アセットの作成方法

- ページ・アセットの配置方法

- サイト・ツリー内でのページ・アセットの移動方法

- ページ・アセットとワークフローの配置に関する考慮事項

- ページ・アセットの編集に関するヒント

- ページ・アセットの削除に関する考慮事項

23.4.1 ページ・アセット・モデルの理解

ページ・アセット・モデルは、フレックス・アセット・モデルと似ています。これによって、ページ・アセットのデータ構造を変更できます。ページ・アセット・モデルは、次のアセット・タイプで構成されています。

- ページ属性

- ページ定義

- ページ

ページ・アセット・モデルのいくつかの一般的な特性は次のとおりです。

- ページ・アセットは、開発者が選択したページ属性によって表されます。

- ページ・アセットの特性を決定するページ属性は、それ自体もアセットです。つまり、属性は、ワークフローを通じて渡す、編集する、リビジョン追跡によって監視するなど、あらゆるコンテンツ管理操作を対象とすることができます。

- 今後、(製品にはよくあることですが)属性をアセット・タイプに追加する必要が生じた場合は、新しい属性を作成して、それを適切な定義に割り当てるだけで済みます。

- このアセット・モデルでは非常に多くの属性を持つアセットがサポートされているため、大量のデータ・セットをサポートできます。

- ページ・アセット・モデルには、一般的なフレックス・ファミリのような親定義アセット・タイプも親アセット・タイプもなく、また、データの継承はサポートされていません。

23.4.2 ページ属性の設計方法

詳細は、次のリンクを参照してください。

- 属性の設計については、「フレックス属性の設計」を参照してください。
注意: ページ・アセットに対しては、継承は適用されません。

- ページ定義の設計については、「親定義とフレックス定義アセットの設計」を参照してください。
注意: ページ・アセットに対しては、「フレックス親定義」はサポートされていません。また、継承も適用されません。

- ページ属性の作成については、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

- ページ・フィルタ・アセットの作成については、「フレックス・アセット・ファミリの作成」の「(条件付き)フレックス・フィルタ・アセットの作成」を参照してください。

- ページ定義アセットの作成については、「フレックス・アセット・ファミリの作成」の「フレックス定義アセットの作成」を参照してください。

- ページ・アソシエーションの作成については、「フレックス・アセット・ファミリの作成」の「(条件付き)フレックス・アセットのアソシエーションの作成」を参照してください。

23.4.3 ページ・アセットの作成方法

ページ・アセットを作成するには:

1. WebCenter Sitesにログインして、作業するサイトを選択し、Oracle WebCenter Sites: Contributorインタフェースのアイコンを選択します。

2. ページに含めるアセット(記事、問合せ、イメージ、コレクションなど)を見つけてブックマークを付けます。次の手順を実行します。

a. 「検索」フィールドに、アセットを特定する条件を入力して、虫めがねアイコンをクリックします。検索タブが開き、検索結果が表示されます。

b. 検索結果リストで、ブックマークを付けるアセットを選択([Ctrl]キーを押しながらクリック)します。

c. 検索タブのツールバーで、「ブックマーク」アイコンをクリックします。

d. この手順を繰り返し、アセットのすべてにブックマークを付け終わったら次の手順に進みます。

タブが開き、次のような検索結果が表示されます。

WebCenter Sitesに確認メッセージが表示されます。また、「ワーク」ツリーの「ブックマーク」ノードの下に、ブックマークを付けたアセットが一覧表示されます。

3. メニュー・バーで、「コンテンツ」→「新規」→ページ・アセットを選択します。この例では、avisportsサンプル・サイトで「ページ(ホーム)」アセット・タイプを使用します。

注意:

avisportsサンプル・サイトを使用する場合、「ページ」タイプのアセットがWebモードで開くように構成されています。したがって、「ページ(ホーム)」アセットの作成を選択すると、ページ(ホーム)の作成ダイアログ・ボックスが表示されます。

ページ(ホーム)の作成ダイアログ・ボックスで、次の手順を実行します。

a. 「レイアウトの選択」フィールドで、ページに割り当てるレイアウトを選択します。

b. 「名前」フィールドに、ページの名前を入力します。ページの名前付けの詳細は、手順4の4.aを参照してください。次に、「続行」をクリックします。

c. avisportsサンプル・サイトでは、作成するページ・アセットのタイプを選択すると、ページ定義が選択されます。ただし、作業しているサイトでこれが当てはまらない場合は、「ページ定義」フィールドが表示されます。このフィールドを使用して、作成するページのページ定義を指定し、「続行」をクリックします。フォーム・モードに切り替えます。アセットのツールバーで、「モード」スイッチをクリックします。手順4bに進みます。

d. アセットの「作成」ビューがフォーム・モードで表示されます。

4. ページ・アセットを作成します。

a. 「名前」フィールドに、ページの名前を入力します。ページに関する説明的な名前を入力してください。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

b. ページ定義フィールド(該当する場合): avisportsサンプル・サイトでは、作成するページ・アセットのタイプを選択すると、ページ定義が選択されます。ただし、作業しているサイトでこれが当てはまらない場合は、「ページ定義」フィールドが表示されます。このフィールドを使用して、作成するページのページ定義を指定し、「続行」をクリックします。

c. 「テンプレート」フィールドで、ドロップダウン・リストからテンプレートを選択します。

d. アイテムを追加するには、「ワーク」ツリーの「ブックマーク」ノードからアセットを選択し、選択したアイテムをフィールドにドラッグ・アンド・ドロップします。

5. アセットのツールバーで、「保存」をクリックします。
このページが保存されます。これが「未配置ページ」ページ・ノードの下の「サイト・ツリー」に表示されます。ページを配置するには、「ページ・アセットの配置方法」を参照してください。

23.4.4 ページ・アセットの配置方法

ページ・アセットを作成したら、配置機能を使用して、アセットをサイト・ツリー内の適切な場所に配置します。

1. Adminインタフェースを開きます。

2. 「サイト・ナビゲーション」タブをクリックします。「未配置ページ」リストに新しいページ・アセットが追加されたサイト・ツリーが表示されます。

3. ページ・アセットの配置先となるサイト・ナビゲーション・ノードを展開します。

4. 次のいずれかを実行して、配置するページの親を選択します。

- ツリー内の最上位レベルにページを配置するには、サイト・ナビゲーション・ノードを右クリックし、コンテキスト・メニューからページの配置を選択します。

- それ以外の場合は、新しい未配置ページの挿入先となる配置済ページで右クリックして、コンテキスト・メニューからページの配置を選択します。

ページの配置フォームが、右側の作業領域で開きます。その親ページの下に配置されたすべての子ページが一覧表示されます。また、サイト・ツリー内にまだ配置されていないすべてのページも一覧表示されます。

5. ページを配置するには、未配置ページのリストで「ランク」フィールドに数字を入力し、子ページ・アセットのリスト内での新しいページの位置を指定します。位置指定番号の先頭は、リスト最上部の1になります。

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

未配置ページ・アセットが、サイト・ツリーの、割り当てられたランクに移動します。そのページ・アセットを新しい場所に表示するには、サイト・ツリー内で右クリックして、コンテキスト・メニューから「すべてリフレッシュ」を選択する必要がある場合があります。

23.4.5 サイト・ツリー内でのページ・アセットの移動方法

未配置ページを配置するほかに、ページの配置フォームを使用して次の操作も実行できます。

- 同じ親ページ内で子ページの順番を変更します。

- 親ページ間で子ページを移動します。

23.4.5.1 子ページの並替え

同じ親ページの子を並べ替えるには:

1. Adminインタフェースを開きます。

2. 「サイト・ナビゲーション」タブをクリックし、並べ替えるページが含まれるサイト・ナビゲーション・ノードを展開します。

3. 子ページが複数ある配置済ページで右クリックして、コンテキスト・メニューからページの配置を選択します。

ページの配置フォームが、右側の作業領域で開きます。

4. 子ページを並べ替えるために、配置済の子ページのリストで「ランク」列に新しい値を入力します。

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

子ページがサイト・ツリー内のそれぞれの新しい位置に移動します。

23.4.5.2 親ページの変更

親ページ間で子ページを移動するには:

1. Adminインタフェースを開きます。

2. 「サイト・ツリー」で、「サイト・ナビゲーション」ノードを展開し、別の親ページの下に移動する子ページが含まれるサイト・ナビゲーション・ノードを展開します。

3. 次の手順でページ・アセットをその親ページから除去します。

a. 移動対象である子ページが存在する配置済ページで右クリックして、コンテキスト・メニューからページの配置を選択します。
ページの配置フォームが、右側の作業領域で開きます。

b. 配置済の子ページのリストで、移動対象である子ページの横にある「除去」チェック・ボックスを選択します。

c. 「保存」をクリックします。
子ページがサイト・ツリーの「未配置ページ」リストに移動します。

4. 次の手順でページ・アセットをその新しい親ページの下に配置します。

a. サイト・ツリー内で、未配置の子ページの挿入先になる配置済ページで右クリックして、コンテキスト・メニューからページの配置を選択します。
ページの配置フォームが、右側の作業領域で開きます。

b. 子ページ・アセットのリスト内での新しいページの位置を指定するために、未配置ページのリストで「ランク」フィールドに数字を入力します。位置指定番号の先頭は、リスト最上部の1になります。

c. 「保存」をクリックします。
それまで未配置だったページ・アセットが、親アセットが含まれるサイト・ナビゲーション・ノードの下の、割り当てられたランクに移動します。

23.4.6 ページ・アセットとワークフローの配置に関する考慮事項

WebCenter Sitesには、アセットが(たとえば、作成者から、編集者、承認者、パブリッシャへと)チーム・メンバー間で引き継がれる際のアセットのフローを制御するワークフロー機能が用意されています。ワークフロー管理者は、サイト・ツリーにページ・アセットを配置できる人物や、どのワークフロー・ステップでその操作を実行できるかを制御するプロセスを作成できます。次の点に注意してください。

- 「ページの配置」ワークフロー権限によって、すべてのページの配置機能(「ページの配置」、「除去」および「ランク」)を制御します。

- 「ページの配置」の起動に使用する親ページと、「ランク」または「除去」を実行するあらゆる子ページの両方に対して適切な権限を持つ必要があります。

ワークフロー・プロセスの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

23.4.7 ページ・アセットの編集に関するヒント

一般的に、既存のページ・アセットを編集する方法としては、次の2つがあります。

- ページに含まれているアセットを変更しても、アセット・タイプは変更しません。たとえば、新しいアセットを「ブックマーク」から「次を含む」リストに移動する、異なるコレクション、問合せ、または記事を名前付きアソシエーション・フィールドから選択する、ページ・アセットに関連付けられているコレクションを異なるアセットが含まれるように再作成するなどです。

- 新しいアソシエーションを作成する、またはなんらかの方法でページ・アセットの実際の構造を変更します。

一定の間隔でページ上のコレクションまたは問合せ内のコンテンツを頻繁に変更する可能性がありますが、サイトの公開後にはアソシエーション、アセット・タイプ、またはページの構造を変更する可能性は低くなります。これによって、ページを書式設定するテンプレート・エレメント内のコードの編集が必要になることもあります。

23.4.8 ページ・アセットの削除に関する考慮事項

サイトの設計フェーズでは、多くのページ・アセットの作成および削除を行う可能性があります。ただし、パブリッシュ済のサイトからページ・アセットを削除する前に、必ずその結果を理解してください。次に例を示します。

- 他のページ・アセットからそのページへの参照を除去しましたか。

- 他のページ・テンプレートのいずれかが、そのページ・アセットに関する情報をなんらかの形で抽出または使用するようにコーディングされていますか。

ページ・アセットを削除する前に、他のエレメントやページからそのアセットへのあらゆる参照を除去してください。ページ・アセットは、削除前に未配置にすることをお薦めします。

24 将来サイト・プレビュー・アセットおよびテンプレートを作成するためのベスト・プラクティス

この章では、将来サイト・プレビュー機能を正常に実装する方法について説明します。コンテンツ作成者は、時間依存の一連のアセットの作成方法を理解する必要があります。また、開発者は、日付に基づいてアセットをフィルタ処理するタグを、それらのアセットを表示するためのテンプレートに含める必要があります。

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

- 将来サイト・プレビューの実装について

- 一連のアセットの作成

- 将来サイト・プレビューのテンプレートの作成

- キャッシングに関する考慮事項

24.1 将来サイト・プレビューの実装について

将来サイト・プレビュー機能を使用すると、コンテンツ・コントリビュータはOracle WebCenter Sites: Contributorインタフェースで将来の特定の時点に表示されるアセットをプレビューできます。この機能では、アセットの開始日属性および終了日属性を利用します。これら2つの属性によって、そのアセットがWebサイト上で提供される期間が決まります。コンテンツ作成者は、Contributorインタフェースの「編集」画面で開始日と終了日を指定できます。

将来サイト・プレビュー機能を正しく実装するには、次の要件を満たす必要があります。

- コンテンツ・コントリビュータは、適切なアセット・セットを作成する必要があります。詳細は、「一連のアセットの作成」を参照してください。

- 管理者は、asset:filterassetsbydateタグが含まれるように、アセットをレンダリングするためのテンプレートを更新する必要があります。詳細は、「将来サイト・プレビューのテンプレートの作成」を参照してください。

24.2 一連のアセットの作成

日付に応じて同じアイテムの異なるバージョンが表示されるようにする場合、コンテンツ作成者は複数のアセットを作成する必要があります。

たとえば、Webサイト内にページを作成すると仮定します。そのページの特別バージョンを、1日かぎりの元日セール・イベント用に実行するとします。この作業を実行するには、3つの異なるアセットが必要になります。1日かぎりのセール用のページを作成する方法は、次のとおりです。

- 標準ページ・アセットを作成し、その終了日をセール日の前日(12月31日23:59:59)に設定します。

- セール・イベント・アセットを作成し、開始日をセール日の始まり(1月1日00:00:00)、終了日をセール日の終わり(1月1日23:59:59)に設定します。

- 標準ページ・アセットを複製し、開始日をセール日の翌日(1月2日00:00:00)に設定します。

これら3つのアセットを作成したら、それらを入力としてasset:filterassetsbydateタグに渡すことができ(詳細は、「将来サイト・プレビューのテンプレートの作成」を参照)。これにより、指定日に基づいてレンダリング対象となるアセットが返されるようになります。

テンプレートでの編集、パブリッシュおよびフィルタ処理を目的とする関連アセット・グループの検索で使用しやすくするために、関連する時間依存のアセット・セットの作成時にネーミング規則に従ってコンテンツ・コントリビュータが入力する属性(nameなど)を、開発者が指定しておくことをお薦めします。

24.3 将来サイト・プレビューのテンプレートの作成

将来サイト・プレビュー機能では、asset:filterassetsbydateタグを適切に使用することが非常に重要です。このタグによって、アセットが指定日に基づいてフィルタ処理されます。このタグの正しい使用方法については後述します。asset:filterassetsbydateタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

この項には次のトピックが含まれます:

- asset:filterassetsbydateタグ

- 入力リスト

24.3.1 asset:filterassetsbydateタグ

このフィルタ・タグのフォーマットは次のとおりです。

<asset:filterassetsbydate
inputList="inputListName"
outputList="outputListName"
[date="date value in either yyyy-MM-dd HH:mm:ss OR yyyy-MM-dd format"]>

このフィルタ・タグには、次のように2つの入力属性(inputListおよびdate)と、1つの出力属性(outputList)があることに注目してください。

- inputList属性によって、指定日に基づいてフィルタ処理するアセットのリストを指定します。

- date属性はオプションです。date属性は、yyyy-MM-dd HH:mm:ssとyyyy-MM-ddのいずれかのフォーマットで指定します。date属性は、プレビュー画面で日付ピッカーから渡される日付値を受け入れるようにコーディングする必要があります(これには、__insiteDate変数を使用します)。

- このタグによって、開始日と終了日で指定日を囲むアセットを含む出力リスト(outputList)を生成します。

このタグによって実行される手順は次のとおりです。

- コンテンツ管理システム上にテンプレートが格納されているかどうかを確認するために、cs.sitepreviewプロパティがあるかどうかがチェックされます。

- 将来サイト・プレビューがオフになっている場合は、システム日付が日付フィールドに渡されます。

- 将来サイト・プレビューがオンになっている場合は、タグのルーチンによって次の処理が実行されます。

- レンダリングされている現在のページでキャッシングを無効にします(キャッシングの詳細は、「キャッシングに関する考慮事項」を参照)。

- (日付ピッカーから渡された)日付パラメータを受け入れます。

- タグに渡された日付のフォーマットが適切かどうかをチェックします。

- 指定日に基づいてアセットの入力リストをフィルタ処理して、出力リストを生成します。

24.3.2 入力リスト

asset:filterassetsbydateタグには、assetidとassettypeという名前の2つの列が含まれる入力リストが必要です。この入力リストは、様々な方法で構成できます。

入力リストを作成する最も簡単なお薦めの方法は、コンテンツ・コントリビュータが、選択した属性(通常、name属性)を入力する際にネーミング規則に従うことです。これにより、asset:searchタグまたはその他の同様のタグを使用してリスト作成コードを記述して、その決められた文字列の属性を検索し、検索結果からリストを構成できます。

入力リスト内に配置するアセットの別の検索方法には、推奨アセット・タイプを使用して、関心のあるアセットのリストを保持する方法もあります。

フィルタ処理の必要なアセットを決定するうえでどの方法を使用する場合でも、次のサンプル・コードで示すように、listobjectタグを使用して、フィルタ・タグの入力リストを構成します。

このサンプル・コードによって、inputListNameリスト・オブジェクトが作成され、assetidとassettypeの2つの列を含む行が追加されます。次に、listobject:tolistによって、assetInputListという名前の入力リストが作成されます。これにより、このリストを入力としてフィルタ・タグに渡すことができます。

<listobject:create name="inputListName" columns="assetid,assettype" />
<listobject:addrow name="inputListName">
<listobject:argument name="assetid" value='<%=ics.GetVar("assetIdVar")%>' />
<listobject:argument name="assettype" value='<%=ics.GetVar("assetTypeVar")%>' />
</listobject:addrow>
<listobject:tolist name="inputListName" listvarname="assetInputList" />

わかりやすくするために、このコード・スニペットでは、1つの行しか含まれていない入力リストの作成について説明しています。実際には、ユーザーは(通常、asset:searchタグの結果またはその他のリストから読み取られた)複数の行をリストに追加し、各行が指定日に基づいてフィルタ処理される必要のあるアセットを表すことが一般的です。

フィルタ処理の対象となるアセットの入力リストを作成した後で、次のようにasset:filterassetsbydateタグを使用します。

<asset:filterassetsbydate inputList="assetInputList" outputList="assetOutputList" date='<%=ics.GetVar("dateValueVariable")%>' />

将来サイト・プレビューの日付ピッカーから日付属性に入力を渡すには、汎用のdateValueVariableを_insiteDateに置き換えます。

このタグによって、assetOutputList出力リストが生成されます。日付に基づくフィルタ処理テストをクリアするアセットについては、次のリストに目を通してください。

<ics:if condition='<%=ics.GetList("assetOutputList")!=null &&
ics.GetList("assetOutputList").hasData()'%>
<ics:then>
<ics:listloop listname=assetOutputList>
<ics:listget listname=assetOutputList fieldname=assetid output=id />
<ics:listget listname=assetOutputList fieldname=assettype output=type/>

<!--
Perform your usual asset load, asset get and other rendering functions using WebCenter Sites tags here
-->
</ics:listloop>
</ics:then>
</ics:if>

24.4 キャッシングに関する考慮事項

配信システムでは、Webページが現在の日付に応じて正しく表示されるように、アセット・エントリが適切な時点でキャッシュから除去される必要があります。そのため、WebCenter Sitesでは、キャッシュされたページの有効期限を計算するために使用される開始日と終了日がファクタ内に含まれます。

注意:

WebCenter Sitesでは、ディスクへのエクスポートのパブリッシュでの開始日と終了日の使用はサポートされていません。アセットがディスクにエクスポートされる場合、開始日と終了日の各属性もディスクにエクスポートされます。ただし、ディスクへのエクスポートのパブリッシュ方法には、キャッシュのクリーンアップ・プロセスのような(他のパブリッシュ方法では、有効期限切れのアセットがディスクから自動的に除去される)メカニズムは用意されていません。

コンテンツ管理システムでは、ページがプレビューされると、asset:filterassetsbydateタグによってそのページのページ・キャッシングが無効になります。そのため、提供されるページには、将来プレビューの日付ピッカーから渡される日付に基づいてフィルタ処理されたアセットが常に表示されるようになり、別の日付入力を使用して生成された可能性のあるページ・キャッシュからページが提供されることはありません。

25 多言語サポートのサイトの構成

多言語サポートのサイトを構成すると、そのサイトのユーザーはロケール(言語バージョン)の指定をアセットに割り当て、アセットの翻訳を作成できるようになります。多言語コンテンツ用のサイト固有の配信ルールを作成するオプションもあり、そのルールによって、どの言語バージョンのアセットをオンライン・サイトで表示するか、訪問者のリクエストがそのコンテンツでまだ用意できていない言語バージョンの場合はどう対処するかが決まります。

サイトの多言語サポートの構成の詳細は、次の項を参照してください。

- 多言語サポートのサイトの構成について

- ロケール・フィルタリングでの作業

- サイトに対する多言語サポートの計画

- サイトに対する多言語サポートの構成

- WebCenter Sites翻訳メカニズムの使用のヒント

25.1 多言語サポートのサイトの構成について

この項では、サイトの設計の計画作成および実装する場合に考慮する必要のあるトピックについて、多言語サポートの観点から説明します。

この項には次のトピックが含まれます:

- ディメンション

- ディメンション・セット

- サイト間の多言語サポート

- マスター・アセット、翻訳および多言語セット

- 翻訳およびアセット関係

- 承認依存性

25.1.1 ディメンション

WebCenter Sitesのロケール指定は、ディメンションの概念によって実装されます。ディメンションとは、別の点では意味的に同一であるアセットを区別する識別子のことです。ロケール(例: アメリカ英語はen_US)は、同一のコンテンツに対する2つの翻訳を区別するディメンションの1タイプです。

ディメンションは、タイプ「ディメンション」のアセットで表されます。このアセット・タイプは、ユーザーが「ディメンション」アセット(サブタイプ「ロケール」)を作成できるよう、またコンテンツ・プロバイダがロケール指定を翻訳対象のアセットに割り当てることができるように、開発者がサイト単位で有効にする必要があります。

注意:

ユーザーは、ロケール指定が割り当てられていないアセットの翻訳を作成できません。

各「ディメンション」アセットは、サイトでロケールを表示します。たとえば、en_US「ディメンション」アセットはアメリカ英語、fr_CA「ディメンション」アセットはカナダ仏語を表します。コンテンツ・アセットにロケールが割り当てられると、その割当ては対応するアセット・タイプのassetType_Dim表に記録されます。

指定されたロケールでのコンテンツの公開では、オンライン・サイトのロケールを有効にする必要があります。つまり、ロケールを示すディメンション・アセットを配信システムに公開し、サイトのディメンション・セットにそのロケールを加える必要があります。　「ディメンション・セット」を参照してください。

25.1.2 ディメンション・セット

ロケールをすでに作成してある場合には、少なくとも1つのディメンション・セットを作成することをお薦めします。ディメンション・セットとはディメンション・アセット(ロケール)のグループ化のことで、サイト訪問者へのコンテンツの配信に次のような影響を与えます。

- ディメンション・セットは、オンライン・サイトで有効にするロケールの指定を定義します。つまり、ディメンション・セットはコンテンツが訪問者に表示される際の言語を指定します。たとえば、あるディメンション・セットにはヨーロッパ言語が含まれ、他のセットにはアジア言語が含まれるなどです。

- ディメンション・セットは、ロケールに基づくコンテンツのフィルタリング方法を定義します。たとえば、訪問者がリクエストした時点でコンテンツが訪問者の希望言語で存在しない場合の処理方法などです。ディメンション・セットを配信システムに公開しない場合には、ロケールのフィルタリングは機能しません。ロケール・フィルタリングの詳細は、「ロケール・フィルタリングでの作業」を参照してください。

注意:

ディメンション・セットは、WebCenter Sitesのユーザー・インタフェースの操作には影響を与えません。

オンライン・サイトの機能に対するロケール・フィルタリングでは、各ディメンション・セットで参照されている「ディメンション・セット」アセットと「ディメンション」アセットの両方を承認して配信システムに公開する必要があります。(参照されている「ディメンション」アセットは、それを参照する「ディメンション・セット」アセットに依存しているため、どちらもそれぞれの「ディメンション・セット」アセットで承認されている必要があります。)

25.1.3 サイト間の多言語サポート

複数のサイトで多言語サポートを設定している場合、次のいずれかのシナリオの実装を選択できます。

- ロケールは作成するが、ディメンション・セットは作成しない
このオプションを選択すると、コンテンツ・プロバイダは複数の言語でコンテンツを管理できますが、レンダリング時のロケール・フィルタリングは有効になりません。すべての必須言語での翻訳が最初から各アセットに存在している場合にのみ、このオプションを使用します。

- ロケールとディメンション・セットを作成し、それらをサイト間で共有する
このオプションには、複数のサイトで多言語サポートを有効にする最も簡単な方法が用意されています。この方法で設定したサイトでは、ディメンション・セットに格納されたプロパティ(オンライン・サイト上で表示が有効化されたロケール、ロケール・フィルタリング・メソッド、および該当する場合はレンダリング時のアセット翻訳を検索する際における階層フィルタのトラバース経路であるフォールバック階層)を共有します。詳細は、「階層フィルタ」を参照してください。複数のターゲット・サイトにレプリケートする基本となるサイトを作成する場合には、ロケールのターゲット・サイトへの共有が最善の方法です。

- 各サイトに個別のロケールとディメンション・セットを作成する
このオプションでは、構成の複雑さが増加する分だけ、最高の柔軟性を得ることができます。サイトでこの方法を設定すると、ロケール・フィルタ・タイプやフォールバック階層などのプロパティを各サイトに合うよう調整できるというメリットがあります。

注意:

複数サイトで同一の言語を表すために「ディメンション」アセットの複製を作成できますが、不要な複雑さを招くため、お薦めしません。

- 最後の2つのオプションの混在
このオプションは、柔軟性と構成の複雑さのバランスが程よく取れています。可能なベスト・プラクティスとして、一意のロケールのプールを作成し、そのプールから各サイトで必要なロケールを共有し、必要に応じて各サイトでディメンション・セットを共有または作成するという方法があります。

25.1.4 マスター・アセット、翻訳および多言語セット

アセットを初めてロケールに割り当てる際には、アセットはマスター・ステータスまたはディメンションの親ステータスを取得します。マスター・ステータスを使用すると、多言語セット(コンテンツが意味的に同一であっても異なった言語で存在する一連のアセット)を構成できます。(これは、ディメンション・セットとは同一でない点に注意してください。ディメンション・セットはオンライン・サイトとアセットがレンダリングされる方法にのみ影響を及ぼします。)

注意:

マスター・アセットとディメンションの親は同じものです。マスター・アセットはWebCenter Sitesのユーザー・インタフェースに表示され、ディメンションの親はOracle WebCenter Sitesタグ・リファレンス、データベース表の名前(assetType_DimPなど)およびエレメント・コードで使用されます。

たとえば、「記事」アセットをアメリカ英語(en_US)として指定し、いずれかのロケールがサイトで有効になっている翻訳を作成した場合(フランス語(fr_CA)やドイツ語(de_DE)など)、翻訳はそれらのディメンションの親(アメリカ英語のアセット)を指し、それらのロケールとマスターが相互に同等な意味であることを示します。

マスター・ステータスでアセットの翻訳を作成すると、WebCenter Sitesによってアセットがコピーされ、選択したロケールがコピーに割り当てられます。次に、翻訳済のコンテンツを入力して新しいアセットとしてその翻訳を保存します。

この時点で、ソース・アセットとその翻訳は多言語セットにリンクされ、翻訳にそのマスターとしてソース・アセットまたはディメンションの親が採用されます。マスターではないセットのメンバーにマスター・ステータスを指定できますが、マスターになることができるのは一度に1つのセット・メンバーのみです。

リンク付けは、アセット・タイプに対してassetType_DimP表を介して実現されます。この表には次の情報が格納されています。

- マスター(ディメンションの親)アセットのID

- 翻訳アセットのID

- その翻訳に割り当てられたロケール・ディメンション・アセットのID

WebCenter Sitesインタフェースでマスター・アセットまたはいずれかの既存の翻訳から翻訳の作成を開始できますが、多言語セットのすべての翻訳は常にディメンションの親(マスター)アセットを指しています。

注意:

ロケールを意識したアセットがリビジョン追跡されている場合、アセットのロケール・データへの変更(ロケール指定やマスター・ステータスなど)により新しいバージョンのアセットは生成されません。

25.1.5 翻訳およびアセット関係

アセットが翻訳される際にアセット関係を処理する方法の要約は、表25-1のとおりです。

表25-1 アセット関係

関係のタイプ

動作

アソシエーション

アソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

コレクション

コレクション・アセットの翻訳を作成すると、新しいコレクション・アセットはソース・アセットのメンバー・アセットを保持します。次に、メンバー・アセットを翻訳し、翻訳済バージョンを新しいコレクション・アセットに格納して、古いコレクションから引き継いだメンバー・アセットを置き換えることができます。

静的リスト推奨

新しい言語バージョンの静的リスト推奨を作成すると、新しい推奨アセットには、ソース・アセットのメンバー・アセットが保持されます。次に、メンバー・アセットを翻訳し、翻訳済バージョンを新しい推奨アセットに格納して、古いコレクションから引き継いだメンバー・アセットを置き換えることができます。

動的リスト推奨

動的リスト推奨はエレメント・コードで移入されるため、影響を受けません。

関連アイテム推奨

関連アイテムのアソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

アセット・タイプの属性

アセット・タイプの属性によるアソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

埋込みリンク

埋込みリンクは影響を受けません。埋込みリンクを含むアセットが翻訳されるとは、リンク対象のコンテンツの対応する翻訳(存在する場合)を指すように、リンクを手動で更新する必要があります。

レンダリング時のアセット関係の処理の詳細は、「ロケール・フィルタリングでの作業」を参照してください。

25.1.6 承認依存性

あるアセットの編集により別の承認ステータスが変更される場合、2つのアセット間には承認依存性が存在します。ローカライズ済アセットに影響を与える承認依存性の要約は、表25-2のとおりです。

表25-2 承認依存性

依存性

アセット承認への影響

Exists依存性は、ローカライズ済アセットと割り当てられたロケールを示す「ディメンション」アセットの間に存在します。

ローカライズ済アセットの公開を承認するには、対応する「ディメンション」アセットも承認されている必要があります。

多言語セットでは、マスター・アセットとそれにリンクされている各翻訳間にExists依存性が存在します。

アセットの最初の翻訳を作成する場合には、アセットとその翻訳の両方を承認する必要があります。

翻訳を承認するには、マスター・アセットが承認済の場合を除いて、対応するマスター・アセットも承認する必要があります。

次の場合には、すべてのメンバーを再承認する必要があります。

- 新規翻訳をセットに追加したり、既存の翻訳をセットから削除する場合。

- セットのマスター・アセットを編集する場合。

- セットの別のメンバーをマスターとして指定する場合。

Exists依存性は、「ディメンション・セット」アセットとそのディメンション・セットで有効化されているロケールを示す「ディメンション」アセットの間に存在します。

ディメンション・セットを承認するには、対応する「ディメンション」アセットも承認されている必要があります。

25.2 ロケール・フィルタリングでの作業

理想的には、多言語サイトは起動される前にそのコンテンツに関して全部そろっていることが望ましいです。つまり、すべてのアセットとそれらの関連事項が必要な言語ですべて存在しているのが理想です。しかし、多くの場合、そうではありません。そのような場合、ロケール・フィルタを使用して、訪問者が指定した環境と言語プリファレンスに応じて、レンダリング時にサイトに表示されるアセットの言語バージョンを決定します。たとえば、リクエストされたアセットがリクエストされた言語に存在しない場合、ビジネス・ロジックに対応を決定するように指定できます。

ロケール・フィルタリングを使用して、元のコンテンツがオンライン・サイトに公開された後に、リクエストされた翻訳の作成をコンテンツ・プロバイダに許可することで、編集作業を徐々に広げていくことができます。ロケール・フィルタリングにより、欠落した翻訳が配信システムに公開されたらただちにサイトで自動的にそれらをピックアップできます。

ロケール・フィルタリングにより配信システムで追加のロードが取り込まれる点に留意してください。追加のロードの容量は、フィルタリング・ロジックの複雑度に応じて異なります。

この項には次のトピックが含まれます:

- ロケール・フィルタリングによるアセット関係の実装のオプション

- 含まれるロケール・フィルタの理解

- カスタム・ロケール・フィルタの使用について

- 構成依存性の説明

- サイトへのフィルタリング・サポートの追加について

25.2.1 ロケール・フィルタリングによるアセット関係の実装のオプション

ロケール・フィルタリングの実装を選択する方法は、サイトのアセット関係を構造化する方法に影響を与えますし、オンライン・サイトの動作の方法に応じて、その逆もあります。

次のオプションのいずれかの実装を選択できます。

- 各ロケールに対して異なるアセット関係のツリーを保持する
アセットのレンダリング時に、このモデルはリクエストされたアセットに関連付けられたどのようなアセットでもレンダリングします。

たとえば、英語とフランス語のアセットが存在し、バージョンごとに関連付けられたアセットの一意のセットが存在する場合、各バージョンは関連付けられた個別のアセットにレンダリングされます。フィルタリングは、訪問者が指定した言語プリファレンスと一致するリクエスト済アセットのバージョンを検索して配信する場合のみ使用され、関連付けられたアセットは、すべての必要な言語に翻訳されていると見込まれています。

このモデルでは、各言語に対して完全に独立したコンテンツが許可されます。このモデルをFirst Site IIサンプル・サイトで使用します。

- 同じアセット関係ツリーをすべてのロケールに使用する
アセットのレンダリング時に、このモデルは、訪問者が指定する言語プリファレンスとは無関係に、リクエストされたアセットのうち関連付けられたアセットを、リクエストされたアセットの特定言語バージョンと関連付けられたアセットに置換します。

たとえば、英語とフランス語のアセットが存在し、バージョンごとに関連付けられたアセットの一意のセットが存在する場合、訪問者が言語プリファレンスでフランス語を指定すると、フィルタリングはリクエストされたアセットのフランス語バージョンを検索して配信しますが、フランス語バージョンの関連付けられたアセットのかわりに英語バージョンの関連付けられたアセットに置換されます(フィルタリングが関連付けを導出する言語バージョンは英語であるという仮定により)。

このモデルでは、すべての言語間で確実にコンテンツが一貫しています。

- 前述の2つのモデルの混在
サイトに最大量の柔軟性とカスタマイズが許可されます。2つのモデル間の最適の比率は、サイトで対象とする動作に応じて異なります。

25.2.2 含まれるロケール・フィルタの理解

WebCenter Sitesでは次のロケール・フィルタが提供されています。

- 簡易フィルタ

- 簡易参照フィルタ

- 階層フィルタ(フォールバック・フィルタともいう)

必要に応じて、カスタム・ロケール・フィルタ実装のオプションもあります。カスタム・フィルタの詳細は、「カスタムロケール・フィルタの使用について」を参照してください。

実装を選択したフィルタのタイプに応じて、フィルタの対象となるアセットは次の条件のうちの1つまたは両方を満たしている必要があります。

- アセットには、割り当てられたロケールが指定されている必要があります。ロケールの指定がないアセットは、ロケール・フィルタで無視されます。

- 相互の翻訳であるアセットは、多言語セットにリンクされている必要があります(マスター・アセットによって相互の翻訳として指定されます)。そうでない場合は、フィルタは必要な翻訳の検索を実行できません。

25.2.2.1 簡易フィルタ

簡易フィルタは、コンテンツが複数の言語で存在しているサイトで、1つの言語のみでレンダリングされる場合に選択できます。フィルタでは次がチェックされます。

- 要求されたアセットが訪問者によって指定された言語のものであるかどうか

- アセットのロケールがサイトのディメンション・セットにリストされているかどうか

両方の条件に一致していると、フィルタはレンダリング用のテンプレートにアセットを渡します。そうでない場合にはレンダリングされません。

簡易フィルタでは、配信システムのパフォーマンスへの影響は最小になりますが、アセットは必要な言語バージョンで存在する必要があり、そうでないとオンライン・サイトに表示されないため、作業する必要のある編集作業量が増加します。

25.2.2.2 簡易参照フィルタ

簡易参照フィルタは、1言語でのみレンダリングする必要のあるサイトで、複数言語でコンテンツが存在している可能性があっても、レンダリング時にすべての必要な翻訳が存在している保証のないサイトで理想的です。フィルタでは次がチェックされます。

- 要求されたアセットが訪問者によって指定された言語のものであるかどうか

- アセットのロケールがサイトのディメンション・セットにリストされているかどうか

リクエストされたアセットが訪問者の希望した言語で存在しない場合には、フィルタはアセットの翻訳をチェックして適切な代替アセットを検索します。フィルタが一致する翻訳を検出した場合には、それをテンプレートに渡します。そうでない場合には、レンダリングされません。(翻訳のロケールがサイトのディメンション・セットに存在しない場合にも、フィルタは何も返しません。)

このフィルタでは、パフォーマンスと機能性の間の合理的なバランスが提供されます。検索の問合せにより配信システムへの負荷は多少増加しますが、アセット作成のための編集作業の量は軽減されます。必要な翻訳は、元のコンテンツがオンライン・サイトに公開された後で作成できるためです。欠落した翻訳が配信システムに公開されると、検索メカニズムがただちにそれらをピックアップします。

25.2.2.3 階層フィルタ

階層フィルタは、リクエストされたアセットのロケールが訪問者によりリクエストされたロケールと一致しているかどうかをチェックします。ロケールが一致しない場合、フィルタはアセットの翻訳をチェックして、適切な代替の翻訳が存在しないか確認します。フィルタが一致する翻訳を検出した場合、それをテンプレートに渡します。検出しない場合には、サイトのディメンション・セットを構成する際に設定したフォールバック階層に従って、リクエストされたアセットの翻訳に置換します。フォールバック階層では、フィルタがリクエストされたアセット用に置換する必要のある言語バージョンとその順番が指定されます。

たとえば、次の階層について見てみましょう。

- en_US (アメリカ英語)

- de_DE (独語)

- de_CH (スイス独語)

- de_AT (オーストリア独語)

- fr_FR (仏語)

- fr_BE (ベルギー仏語)

- fr_CA (カナダ仏語)

- en_UK (イギリス英語)

この例では、訪問者がスイス独語(de_CH)のアセットをリクエストした場合、フィルタはアセットの翻訳を検索してアセットのスイス独語バージョンを検出すると、そのバージョンをテンプレートに渡します。フィルタがスイス独語バージョンを検出できない場合、階層パス内でその次に最適なロケールの独語(de_DE)にフォールバックします。同様に独語の翻訳が存在しない場合、フィルタはツリーの最上階に達するまで指定されたパスを階層内で追跡します。そのプロセスで一致が検出されない場合は、何もレンダリングされません。

前述の例では、訪問者が単一の希望言語を指定する場合について説明しました。ユーザーが複数の希望言語を指定する場合(通常、順序付けられたリストのフォームで)、フィルタは訪問者の最も希望する言語に対するフォールバック階層で一致する検索を試行します。一致が検出されない場合には、フィルタはフォールバック階層で一致が検出されるまで、訪問者のリストで次の言語をチェックします。その場合、前述のように、フィルタは一致するロケールからフォールバック・ツリーの最上位までパスを追跡して、リクエストされたアセットの翻訳の置換を試行します。

たとえば、ユーザーの希望する言語が日本語、仏語、英語(その順番で希望)だとすると、フィルタはフォールバック階層で日本語の検出を試行します。日本語が階層に存在しない場合には、次に仏語の検出が試行されます。仏語は階層に存在するので、仏語からツリーのルート・ノードへのパスが追跡され、この項で前述した例のように、そのパスに従って置換が施行されます。

階層フィルタは強力で便利ですが、次のような欠点があります。

- 追加のデータベース問合せは、フィルタの負担が配信システムのパフォーマンスにかかります。パフォーマンス・ヒットを最小限にするには、できるだけ多くの必要な言語がコンテンツに存在するように編集して、フィルタのアクティビティを最小限にする必要があります。(別のフィルタの使用を選択することも可能です。)

- オンライン・サイトに表示するアセットに対するコントロールは、もっぱらサイト開発者や管理者の手にゆだねられます。これは、フィルタが、サイトへの訪問者が指定するプリファレンスの順ではなく(各訪問者からの複数言語のプリファレンスを受け入れるようにサイトが設定されていると仮定して)、ディメンション・セットで構成されたフォールバック・ツリーを追跡するためです。

25.2.3 カスタム・ロケール・フィルタの使用について

サイトの設計に応じて、カスタム・フィルタの作成を決定できます。たとえば、サイトの設計により、ディメンション・セットで定義されたフィルタではなく、訪問者が指定するロケールの優先度を優先的に選択する階層(フォールバック)フィルタがコールされるとします。そのような場合は、「ディメンション・セット」アセットの「編集」フォームのフィールドで、カスタム・フィルタ・クラスを指定できます。

25.2.4 構成依存性の説明

サイトにロケール・フィルタリングを組み込むことを決定した場合、結果として導入される追加の構成の依存性を説明する必要があります。構成の依存性によって、ページが配信システムでキャッシュされる方法が指定されます。

この項には次のトピックが含まれます:

- アセットの検索連鎖

- キャッシング・ルール

25.2.4.1 アセットの検索連鎖

ロケール・フィルタリングを使用してアセットの翻訳を検索する場合、検索プロセス時にロードされるアセットに基づいて、次のファクタがページのキャッシュ方法を指定します。

- 採用されるフィルタリング・ロジック

- 検索リクエスト元からのページとアセット

- 訪問者が指定する言語プリファレンス

リクエストされたアセットを含むキャッシュ済ページは、検索プロセス時にロードされたすべてのアセットに依存します。したがって、検索プロセス時にロードされたアセットが変更されると、影響を受けたページがキャッシュからフラッシュされます。

たとえば、簡易参照フィルタと次の多言語セットについて見てみましょう。

- en_US (マスター)

- fr_FR (翻訳)

- de_DE (翻訳)

訪問者が仏語バージョンを含むページをリクエストしているが、その訪問者の言語プリファレンスが独語の場合、検索連鎖は次のようになります。

fr_FR > en_US > de_DE

この例では、フィルタはまず仏語バージョンにリンクされたマスター・アセットをロードし、次にそのマスター・アセットを使用して独語バージョンを検索するため、3つのアセットがすべてロードされます。したがって、これら3通のアセットのいずれかが変更されると、影響を受けたページがキャッシュからフラッシュされます。

他方、ユーザーがセットのマスター・アセットであるアメリカ英語バージョンをリクエストすると、検索連鎖はもっと短くなります。

fr_FR > en_US

この場合、仏語バージョンとアメリカ英語バージョンがロードされますが、独語バージョンはロードされません。したがって、独語バージョンを変更すると、対応するページがキャッシュからフラッシュされますが、仏語バージョンやアメリカ英語バージョンを変更してもフラッシュされません。

WebCenter Sitesに含まれるロケール・フィルタで採用される検索メカニズムの詳細は、「含まれるロケール・フィルタの理解」を参照してください。

「キャッシング・ルール」では、多言語アセットに適用されるキャッシング・ルールについて説明します。

25.2.4.2 キャッシング・ルール

翻訳が検索されて影響を受けるページがキャッシュされると、次のいずれかが発生するたびにページがキャッシュからフラッシュされます。

- 新しい言語が多言語セットに追加された

- ページのレンダリング時に検索連鎖の一部だった翻訳が編集された

- 多言語セットのメンバーの翻訳が削除された

- セットのマスター・アセットが編集された

- セットの別のメンバーがマスターとして指定された

25.2.5 サイトへのフィルタリング・サポートの追加について

ロケール・フィルタリングのサポートをサイトに追加するには、サイトで使用するテンプレートとエレメント・コードを変更する必要があります。

テンプレート・コードがアセットのc/cid値を介してアセットをフェッチすると、ロケール・フィルタは受信c/cid値でのフィルタのビジネス・ロジックを実行し、結果のc/cid値(またはなし)をレンダリング対象のテンプレートに返します。

サイトの構造は、テンプレートへのロケール・フィルタリングの実装方法に影響を及ぼしますし、その逆の場合もあります。また、異なるシナリオで、サイトの動作を指定します。

たとえば、5つの記事があり、それぞれに2つの言語en(英語)とfr(仏語)のバージョンが存在するとします。その記事は、a1en、a1fr、a2en、a2frなどになります。これらの記事をコレクションに配置し、次のいずれかの方法でロケール・フィルタリングを実装します。

- 英語コレクションc1enを作成して、それに英語の記事のすべてを割り当てます。この方法では、コレクションをレンダリングする前に、c1enアセットのc/cidに簡易フィルタを実行し、c/cid値をフィルタリングせずにその子をレンダリングします。c1enコレクションが単一言語であることを信頼しているためです。

- 多言語コレクションを作成し(それにロケールを割り当てないで)、その記事を任意の言語に追加します。次に、各記事をレンダリングする際に、記事のc/cid値をフィルタリングして、記事が訪問者に指定されたロケールでレンダリングされるようにします。

この項の残りの部分では、FirstSiteIIサンプル・サイトに基づいてコードの例を示します。多言語サポートの方法を把握するために、FirstSiteIIのコードを調べることをお薦めします。

この項には次のトピックが含まれます:

- テンプレートへのフィルタリングの追加について

- 訪問者のロケール・プリファレンスの取得と保持について

- 検索結果のフィルタ処理について

25.2.5.1 テンプレートへのフィルタリングの追加について

通常、フィルタリング・コードをユーティリティのエレメントに配置して、そのエレメントをテンプレートの最上部でコールしてc/cid値を処理します。

次の例では、FSIILayoutテンプレートがrender:lookupタグを介してFSIICommon/Multilingual/Filterエレメントのアセットに格納されたフィルタ・コードをコールする方法を示しています。

<%-- Execute the Dimension filter to look up the translated asset that corresponds to the locale that the visitor requested. --%>
<render:lookup site='<%=ics.GetVar("site")%>' varname="Filter" key="Filter" match=":x" tid='<%=ics.GetVar("tid")%>' />
<render:callelement elementname='<%=ics.GetVar("Filter")%>' scoped="global"/>

25.2.5.2 訪問者のロケール・プリファレンスの取得と保持について

フィルタリングを稼働するには、訪問者に希望の言語(ロケール)の指定を許可する必要があります。このプリファレンスは、サイト全体に伝搬される必要があります(すべてのテンプレートに渡される)。

次の例では、これをFSIIWrapperエレメントで実現する方法を示します。この例の最後のセクションでは、セッション変数(例の初めの部分で、セッション変数が存在することを確認します)から値を取得してロケール変数を設定する方法を示しています。

<%-- The session variable locale refers to the id of the dimension with the
subtype of Locale that specifies which language the site is to be rendered in.
Users can select the locale of their choice from a menu on every page of the
site, and once selected, it is stored in session. A default locale is mapped to
this CSElement and is set if it has not already been set. --%>
<ics:if condition='<%=ics.GetSSVar("preferred_locale") == null%>'>
<ics:then>
<render:lookup site='<%=ics.GetVar("site")%>' varname="default:locale:name" key='DefaultLocale' ttype="CSElement" tid='<%=ics.GetVar("eid")%>' match=":x"/>
<asset:load name="defaultLocale" type="Dimension" field="name" value='<%=ics.GetVar("default:locale:name")%>'/>
<asset:get name="defaultLocale" field="id" output="default:locale:id"/>
<ics:setssvar name="preferred_locale" value='<%=ics.GetVar("default:locale:id")%>'/>
</ics:then>
</ics:if>
<%-- Call the wrapped child page. There is no need to look up the template or to enable any special PageBuilder functionality, so we can use the render:satellitepage tag in this situation. --%>
<render:satellitepage pagename='<%=ics.GetVar("childpagename")%>' packedargs='<%=ics.GetVar("packedargs")%>'>
<render:argument name='c' value='<%=ics.GetVar("c")%>'/>
<render:argument name='cid' value='<%=ics.GetVar("cid")%>'/>
<render:argument name='p' value='<%=ics.GetVar("p")%>' />
<render:argument name="locale" value='<%=ics.GetSSVar("preferred_locale")%>'/>
</render:satellitepage>

25.2.5.3 検索結果のフィルタ処理について

オンライン・サイトに検索機能が備わっている場合、訪問者へ返された検索結果を、訪問者の言語プリファレンスに基づいてフィルタリングするように選択できます。

次の例は、Page/SearchDetailViewテンプレートが検索結果のIListをフィルタリングして、問合せがすべての言語に対して実行され、定義した結果のみが返されるようにする方法を示しています。

<%-- look up the dimension set and filter the ProductList results --%>
<asset:load name="GlobalDimSet" type="DimensionSet" field="name" value='<%=ics.GetVar("GlobalDimSet")%>' />
<dimensionset:filter name="GlobalDimSet" tofilter="ProductList" list="ProductList">
<dimensionset:asset assettype="Dimension" assetid='<%=ics.GetVar("locale")%>'/>
</dimensionset:filter>

詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。さらに、FirstSiteIIサンプル・サイトのコードを調べて、多言語サポートを実装する方法を確認してください。

25.3 サイトに対する多言語サポートの計画

多言語サポートのサイトの構成を開始する前に、次の前提条件が満たされているか確認します。これらの決定事項についてサイト管理者と合意しておくことがベストです。

1. 所属する組織のコンテンツ管理のニーズに基づいて、最初にサイト(複数可)に実装する言語の数を決定します。次のいずれかを実行できます。

- サイト(複数可)を作成して最初に単一言語をサポートし、必要に応じてその他の言語のサポートを追加する。

- 前もってすべてのサイトで取り込む言語すべてを計画し、適切なロケールを作成しておく。

2. 既存のロケールとディメンション・セットを新しいサイト(複数可)で共有するか、個別のものを作成するかを決定します。詳細は、「サイト間の多言語サポート」を参照してください。

3. アセット関係をロケールの観点でレンダリング時に処理する方法を決定し、その決定に合ったロケール・フィルタリング・メソッドを選択します。この選択事項は、オートメーションのレベル、配信システムのパフォーマンスおよび編集の作業負荷の間のバランスをうまくとる必要があるため、サイトの管理者と合意しておくことがベストです。詳細は、「ロケール・フィルタリングでの作業」を参照してください。次の点に注意してください。

- 別のフィルタリング・メソッドには、配信システムへのパフォーマンス・ヒットを犠牲にした異なったレベルのオートメーションが用意されています。フィルタが複雑になればなるほど、パフォーマンス・ヒットは高くなります。たとえば、簡易参照フィルタには階層フィルタより高いパフォーマンスが備わっています。

- 実装するフィルタリング・メソッドに応じて、サイト・コンテンツへの編集作業は徐々に広げていくことができます。オリジナル・コンテンツが作成されてライブ・サイトに公表された後で、翻訳を作成できます。実装するフィルタリング・ロジックは、必要とされる言語バージョンで存在していないコンテンツに対して実行する手順を決定します。

4. 単一言語サイトを多言語サイトに変換する場合には、デフォルト・ロケールをサイトのアセットに割り当てる際に使用するエレメント・コードを取得します。FirstSiteIIサンプル・サイトに基づいたサンプル・コードは、「デフォルト・ロケールの一括割当て用サンプル・エレメント・コード」に記載されています。

注意:

多言語セットを備えたサイトをレプリケートする場合、マスター・アセットがターゲット・サイトで(共有またはコピーのいずれかにより)使用できることを確認してください。使用できない場合は、セット・メンバーはターゲット・サイトの相互の翻訳にリンクされなくなります。

25.4 サイトに対する多言語サポートの構成

次の各項では、多言語サポートのサイトを構成する際に必要な手順を説明します。

- 構成のクイック・リファレンス

- 「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプの有効化

- 「ディメンション」アセット・タイプの「ロケール」サブタイプの有効化

- ロケールの作成方法

- 別のサイトでのロケールの共有方法

- ディメンション・セットの作成と構成方法

- 別のサイトでのディメンション・セットの共有方法

- ロケール・フィルタの構成方法

- 階層フィルタのフォールバック階層の構成方法

- デフォルト・ロケールのサイト内アセットへの一括割当て方法

25.4.1 構成のクイック・リファレンス

この項では、サイトの多言語サポートの構成に必要な手順の概要を述べます。構成プロセスの際には、このリストをクイック・リファレンスとして使用してください。

1. 「サイトに対する多言語サポートの計画」の説明に従い、必要な決定と準備を行います。

2. 「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプをサイトで有効にします。手順は、「「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプの有効化」を参照してください。

3. 「ディメンション」アセット・タイプの「ロケール」サブタイプをサイトで有効にします。手順は、「「ディメンション」アセット・タイプの「ロケール」サブタイプの有効化」を参照してください。

4. ロケールを作成または共有します。手順は、次の各項を参照してください。

- 新規ロケールの作成は、「ロケールの作成方法」を参照してください。

- 既存ロケールの共有は、「別のサイトでのロケールの共有方法」を参照してください。

ロケールの作成か既存ロケールの共有のいずれかを決定する際のヘルプは、「サイト間の多言語サポート」を参照してください。

5. ディメンション・セットを作成または共有します。手順は、次の各項を参照してください。

- 新規ディメンション・セットの作成は、「ディメンション・セットの作成と構成方法」を参照してください。

- 既存ディメンション・セットの共有は、「別のサイトでのディメンション・セットの共有方法」を参照してください。

新規ディメンション・セットの作成か既存ディメンション・セットの共有のいずれかを決定する際のヘルプは、「サイト間の多言語サポート」を参照してください。

6. (オプション)既存の単一言語サイトを多言語サイトに変換する場合、デフォルトのロケールをサイトの各アセットに割り当てるエレメント・コードを実行します。手順は、「デフォルト・ロケールのサイト内アセットへの一括割当て方法」を参照してください。この項では、サイト用にカスタマイズ可能なサンプル・コードについて説明します。

7. サイトで使用するテンプレートを変更して、ディメンション・セットの構成時に選択したロケール・フィルタのサポートを追加します。このプロセスの概要は、「サイトへのフィルタリング・サポートの追加について」を参照してください。

注意:

ロケール・フィルタリング以外にも、次のサイト機能を実装する必要があります。

- 訪問者の言語プリファレンスの指定を許可する

- 訪問者の言語プリファレンスをサイト全体に伝搬する(サイトのすべてのテンプレートに渡す)

- セッションの間、訪問者の言語プリファレンスを維持する

25.4.2 「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプの有効化

サイトで「ディメンション」アセットと「ディメンション・セット」アセットを作成する前に、対応するアセット・タイプとサブタイプを有効化する必要があります。この手順では、「ディメンション」アセット・タイプと「ディメンション・セット」アセット・タイプをサイトで有効にする方法を説明します。次の手順では、サイトで「ディメンション」アセット・タイプの「ロケール」サブタイプを有効にする方法を説明します。

1. Adminインタフェースを開きます。

2. 「一般的な管理」ツリーで、「管理」ノードを開きます。

3. 「管理」ノードで、次の階層をドリル・ダウンします。

a. 「サイト」ノードを開きます。

b. 「サイト」ノードで、サイトに対応するノードを開きます。

c. サイト・ノードで、「アセット・タイプ」ノードを開きます。

d. 「アセット・タイプ」ノードで、「有効化」ノードをダブルクリックします。

WebCenter Sitesに「アセット・タイプの有効化」フォームが表示されます。

4. 「アセット・タイプの有効化」フォームで、「ディメンション」アセット・タイプと「ディメンション・セット」アセット・タイプの隣にあるチェック・ボックスを選択します。

5. 「アセット・タイプの有効化」をクリックします。
WebCenter Sitesに「スタート・メニューの選択」フォームが表示されます。

6. 「スタート・メニューの選択」フォームで、すべてのチェック・ボックスを選択し、「アセット・タイプの有効化」をクリックします。
WebCenter Sitesに、アセット・タイプがサイトで有効化されたことを確認するメッセージが表示されます。

25.4.3 「ディメンション」アセット・タイプの「ロケール」サブタイプの有効化

ロケールをサイトのアセットに割り当てる前に、サイトで「ディメンション」アセット・タイプの「ロケール」サブタイプを有効化する必要があります。

1. Adminインタフェースを開きます。

2. 「一般的な管理」ツリーで、「管理」ノードを開きます。

3. 「管理」ノードで、次の階層をドリル・ダウンします。

a. 「アセット・タイプ」ノードを開きます。

b. 「アセット・タイプ」ノードで、「ディメンション」ノードを開きます。

c. 「ディメンション」ノードで、「サブタイプ」ノードをダブルクリックします。

WebCenter Sitesに「アセット・タイプのサブタイプ: ディメンション」フォームが表示されます。

4. フォームで、「ロケール」サブタイプの隣にある「編集」(鉛筆)アイコンをクリックします。
WebCenter Sitesに「ディメンション・サブタイプの編集: ロケール」フォームが表示されます。

5. 「サイト」フィールドで、「ロケール」サブタイプを有効にするサイトを、[Ctrl]キーを押しながらクリックします。

注意:

既存のサイトの選択をそのままにするには、サイト名を[Ctrl]キーを押しながらクリックする必要があり、単にサイト名をクリックした場合は、他の選択済サイト(ある場合)の選択が解除されます。

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

25.4.4 ロケールの作成方法

注意:

作成するロケールがWebCenter Sitesシステムの別のサイトにある「ディメンション」アセットで示されている言語を指定する場合、その言語を示す既存の「ディメンション」アセットを現在のサイトで共有して冗長性を回避します。

新規ロケールをサイトに追加するには、次の手順を実行して、ロケールを示す「ロケール」サブタイプの「ディメンション」アセットを作成します。

1. ボタン・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、「新規ディメンション」をクリックします。

3. WebCenter Sitesに、新規ディメンション・フォームが表示されます。

4. 「新規ディメンション」フォームで、次の手順を実行します。

「名前」フィールドに、そのロケールの説明的な名前を入力します。ベスト・プラクティスとして、次の表記規則を使用することをお薦めします。

xx_YY

ここで:

- xxは2文字のISO 639-1言語コード(仏語の場合はfr)

- YYは2文字のISO国コード(カナダの場合はCA)

前述の例をまとめると、名前fr_CAはカナダ仏語を示します。

5. 「説明」フィールドに、このロケールが表す言語の説明を入力します。

6. 「サブタイプ」ドロップダウン・リストで、「ロケール」を選択します。

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

25.4.5 別のサイトでのロケールの共有方法

ロケールを別のサイトで共有するには、対応する「ディメンション」アセットを共有する必要があります。

1. Adminインタフェースを開き、共有するロケールに対する「ディメンション」アセットが存在するサイトを選択します。

2. 「ディメンション」アセットを検索し、その「調査」フォームを開きます。

a. ボタン・バーで、「検索」をクリックします。

b. アセット・タイプのリストで、「ディメンションの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、アセットに移動して名前をクリックします。
WebCenter Sitesによってアセットが「調査」フォームに表示されます。

3. アクション・バーで、「ディメンションの共有」を選択します。
WebCenter Sitesに、ディメンションの共有フォームが表示されます。

4. 「ディメンションの共有」フォームで、「ディメンション」アセットを共有するサイトの隣にあるチェック・ボックスを選択します。(アセットをWebCenter Sitesシステム上のすべてのサイトで共有するには、「すべてのサイト」チェック・ボックスを選択します。)

5. 「変更の保存」をクリックします。
選択したサイトでアセットが使用可能になったことを示すメッセージがWebCenter Sitesに表示されます。

25.4.6 ディメンション・セットの作成と構成方法

ディメンション・セットを作成して構成する手順:

1. 次の手順に従って、ディメンション・セットに追加する「ディメンション」アセット(ロケール)をブックマークに追加します。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「ディメンションの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、「ディメンション」アセットに移動して、チェック・ボックスを選択します。

e. 「ブックマークに追加」をクリックします。

2. 次の手順に従って、ディメンション・セットを作成して構成します。

a. ボタン・バーで、「新規」をクリックします。

b. 「新規」アセット・リストで、「新規ディメンション・セット」をクリックします。
WebCenter Sitesに、新規ディメンション・セット・フォームが表示されます。

c. 「名前」フィールドに、そのディメンション・セットを説明する名前を入力します。

d. ツリーで、「ブックマーク」タブを選択します。

e. 「ブックマーク」タブで、ディメンション・セットに追加するロケールを選択し、「選択したアイテムの追加」をクリックします。追加するロケールごとに、この手順を繰り返します。

f. 「ディメンション・フィルタ・クラス」フィールドで、ロケール・フィルタ・タイプを選択します。「詳細」オプションを選択すると、カスタム・フィルタ・クラスを指定できます。
ロケール・フィルタ・タイプの詳細は、「ロケール・フィルタリングでの作業」を参照してください。

g. (オプション)手順2で「詳細」を選択した場合は、表示されたテキスト・ボックスにカスタム・フィルタ・クラスの名前を入力します。

h. 終了したら、「変更の保存」をクリックします。

i. (オプション)手順2で「階層」フィルタを選択した場合は、「階層フィルタのフォールバック階層の構成方法」の手順を完了して、フィルタのフォールバック階層を構成します。

25.4.7 別のサイトでのディメンション・セットの共有方法

ディメンション・セットを別のサイトへ共有させるには、対応する「ディメンション・セット」アセットを共有する必要があります。

1. Adminインタフェースを開き、共有するロケールに対する「ディメンション・セット」アセットが存在するサイトを選択します。

2. 「ディメンション・セット」アセットを検索し、その「調査」フォームを開きます。

a. ボタン・バーで、「検索」をクリックします。

b. アセット・タイプのリストで、「ディメンション・セットの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、アセットに移動して名前をクリックします。
WebCenter Sitesに、アセットの「調査」フォームが表示されます。

3. アクション・バーで、「ディメンション・セットの共有」を選択します。
WebCenter Sitesに、ディメンション・セットの共有フォームが表示されます。

4. 「ディメンション・セットの共有」フォームで、「ディメンション・セット」アセットを共有するサイトの隣にあるチェック・ボックスを選択します。(アセットをWebCenter Sitesシステム上のすべてのサイトで共有するには、「すべてのサイト」チェック・ボックスを選択します。)

5. 「変更の保存」をクリックします。

6. 選択したサイトでアセットが使用可能になったことを示すメッセージがWebCenter Sitesに表示されます。

25.4.8 ロケール・フィルタの構成方法

通常、サイトにディメンション・セットを作成する際にロケール・フィルタを構成します。既存のディメンション・セットのロケール・フィルタの構成を変更するには、次の手順を実行します。

1. 構成するロケール・フィルタのディメンション・セットを検索して、「調査」フォームで開きます。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「ディメンション・セットの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、アセットに移動して名前をクリックします。
WebCenter Sitesによってアセットが「調査」フォームに表示されます。

2. 「ディメンション・フィルタ・クラス」フィールドで、フィルタ・タイプの隣にあるオプションを選択します。「詳細」オプションを選択すると、カスタム・フィルタ・クラスを指定できます。

ロケール・フィルタの詳細は、「ロケール・フィルタリングでの作業」を参照してください。

3. (オプション)手順2で「詳細」を選択した場合は、表示されたテキスト・フィールドにカスタム・フィルタ・クラスの名前を入力します。

4. 「変更の保存」をクリックします。

5. (オプション)手順2で「階層」フィルタを選択した場合は、「階層フィルタのフォールバック階層の構成方法」の手順を完了して、フィルタのフォールバック階層を構成します。

25.4.9 階層フィルタのフォールバック階層の構成方法

ディメンション・セットの構成時に階層(フォールバック)ロケール・フィルタを選択した場合は、次の手順を実行して、フィルタのフォールバック階層を構成します。

1. 新規ロケールを追加したり、既存ロケールをフォールバック階層で並べ替える場合、次の手順に従って、階層に追加するロケールを表す「ディメンション」アセットをブックマークに追加します。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「ディメンションの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、「ディメンション」アセットに移動して、チェック・ボックスを選択します。

e. 「ブックマークに追加」をクリックします。

2. 「調査」フォームで、構成する階層フィルタが存在するディメンション・セットを検索して開きます。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、「ディメンション・セットの検索」をクリックします。

c. 検索条件を入力し(存在する場合)、「検索」をクリックします。

d. 検索結果のリストで、「ディメンション・セット」アセットに移動して、ハイパーリンク名をクリックします。
WebCenter Sitesに、「ディメンション・セット」アセットの「調査」フォームが表示されます。

3. フォールバック階層を構成するときには、次の点に注意してください。

- ロケールは、フォールバック階層に1回のみ表示できます。

- 階層からロケールを削除する必要がある場合は、ロケール・ノードの隣にある「削除」(ゴミ箱)アイコンをクリックします。

- 階層内のロケールの位置を変更する必要がある場合は、そのロケールを削除して、親ノードの下に追加します。

ローカル階層を構成する手順:

1. 「ディメンション・フィルタ・クラス」フィールドで、「ロケール階層の構成」をクリックします。
WebCenter Sitesに「ロケール階層の構成」フォームが表示されます。

2. 「ロケール階層の構成」フォームで、「編集」をクリックします。
WebCenter Sitesにフォームの編集可能バージョンが表示されます。

3. ツリーで、「ブックマーク」タブを選択します。

4. (オプション)階層が空白の場合には、「ブックマーク」タブでフォールバック階層の最上位ノードとして指定するロケールを選択し、「選択したアイテムの追加」をクリックします。

5. 階層に追加するロケールの親ノードを選択します。

スクラッチから階層を作成する場合は、選択できるのは、手順4で追加した最上位レベルのノードのみです。

階層作成時には、フォールバック・プロセスが発生していく方向(最も特殊なものから最も特殊でないものへという方向、つまりツリーのルート・ノード方向)に注意してください。

6. 「ブックマーク」タブで、手順5で選択した親ノードの下に表示するロケールを選択して、「選択したアイテムの追加」をクリックします。

7. 階層に追加するロケールごとに、手順5と6を繰り返します。

8. フォールバック階層が完了したら、「変更の保存」をクリックします。

25.4.10 デフォルト・ロケールのサイト内アセットへの一括割当て方法

単一言語サイトから多言語サイトへ変換している場合、デフォルト・ロケールをサイト内のすべてのアセットに割り当てる必要があります。これを迅速に実現させるには、デフォルト・ロケールをアセットに割り当てるエレメントを実行します。

作業を容易にするために、この手順のサンプル・エレメント・コードは、「デフォルト・ロケールの一括割当て用サンプル・エレメント・コード」に記載されています。サンプル・コードは例として記載されているため、実際のサイトではカスタマイズする必要があります。

1. CSElementアセットを作成して、デフォルト・ロケールをアセットに割り当てるエレメント・コードを保持します。

2. 手順1で作成したCSElementアセットを参照する、SiteEntryアセットを作成します。

3. 手順2で作成したSiteEntryアセットを、次のURLでコールします。

http://<host>:<port>/<context>/ContentServer?pagename=
<siteentry_name>

ここで:

- <host>は、ご使用のWebCenter Sitesシステムのホストです

- <port>は、WebCenter Sitesが接続をリスニングするポート番号です

- <context>は、WebCenter Sitesアプリケーションに割り当てられたアプリケーション・コンテキストのルートです。

- <siteentry_name>は、手順2で作成したSiteEntryアセットの名前です。

エレメント・コードが実行を完了したら、アセットにロケールが割り当てられていることを確認してください。割り当てられていない場合は、エレメント・コードの考えられるエラーをチェックします。

25.4.10.1 デフォルト・ロケールの一括割当て用サンプル・エレメント・コード

この項には、FirstSiteIIサンプル・サイトに記述されたサンプル・エレメント・コードが記載されています。このコードは、次の操作を実行します。

1. en_USという名前の「ディメンション」アセットを作成して、サイト内のデフォルト・ロケール指定を示します(この例ではアメリカ英語)。

2. このデフォルト・ロケールをサイト内の「ページ」アセットに割り当てます。

注意:

この項のコードは、例として提供されています。これを使用すると決定したら、実際のサイトに対してカスタマイズしてください。デプロイ前にコードをテストしてください。この例には、エラー・チェック機能は含まれていません。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="asset" uri="futuretense_cs/asset.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="user" uri="futuretense_cs/user.tld"%>

<cs:ftcs>

<%-- Record dependencies for the SiteEntry and the CSElement --%>
<ics:if condition='<%=ics.GetVar("seid")!=null%>'>
<ics:then>
<render:logdep cid='<%=ics.GetVar("seid")%>' c="SiteEntry"/>
</ics:then>
</ics:if>

<ics:if condition='<%=ics.GetVar("eid")!=null%>'>
<ics:then>
<render:logdep cid='<%=ics.GetVar("eid")%>' c="CSElement"/>
</ics:then>
</ics:if>

<%-- log in as firstsite--%>
<user:login username="firstsite" password="firstsite"/>
<%-- create the Dimension asset (this can be done manually) --%>
<asset:create name="en_US" type="Dimension"/>
<asset:setsubtype name="en_US" value="Locale"/>
<asset:set name="en_US" field="name" value='en_US'/>
<asset:set name="en_US" field="description" value='US English'/>
<%-- enter your site's pubid below --%>
<ics:setvar name="primarypubid" value="1112198287026"/>
<asset:save name="en_US"/>

<%-- look up the id of the Dimension asset you just created --%>
<asset:get name="en_US" field="id" output="en_US.id"/>

<%-- get a list of all Content_C assets in the site, and assign a dimension to each of them --%>
<asset:list type="Content_C" list="allContentAssets" pubid="1112198287026"/>
<ics:listloop listname="allContentAssets">
<ics:listget listname="allContentAssets" fieldname="id" output="id"/>
<asset:load type="Content_C" objectid='<%=ics.GetVar("id")%>' name="tempName" editable="true"/>
<asset:adddimension name="tempName" dimensionid='<%=ics.GetVar("en_US.id")%>'/>
<asset:save name="tempName"/>
</ics:listloop>
</cs:ftcs>

25.5 WebCenter Sites翻訳メカニズムの使用のヒント

一般的な2つのシナリオを次に示します。

- 編集チームが最初に一次言語でコンテンツを作成およびパブリッシュしてから、必要に応じて臨機応変に翻訳し、翻訳/ローカライズ版をパブリッシュします。

- 編集チームは、コンテンツの作成と翻訳をパッケージとして一緒に行います。完了したら、パッケージを一斉にパブリッシュします。

25.5.1 顧客が希望すること

- マスター言語でコンテンツを作成して、関連する他のコンテンツに接続してから(マスター言語でない場合もあります)、パブリッシュして後で翻訳できるようにする

- コンテンツと、関連する他の部分を最初に翻訳してから、全体を1つのパッケージとしてパブリッシュする。

- レンダリングされるコンテンツに国に固有のルールを柔軟に適用する。

25.5.2 顧客の要件を効率的に満たすためのWebCenter Sites翻訳メカニズムの使用

WebCenter Sitesには、ディメンション・セットと呼ばれるアセット・タイプを使用するビルトイン翻訳メカニズムがあります。実際、翻訳済バージョン同じコンテンツはすべて、同じディメンション・セット・インスタンスに属します。この機能では、ロケールのフォールバック・ツリーの設計も可能です。翻訳されたコンテンツが現在のロケールでロケールにない場合、使用可能な別の翻訳がフォールバック・バージョンとして表示されます。1つのディメンション・セットに含めることができるロケールは、それぞれ1回のみです。国ごとに異なるシーケンスで同じロケールを使用することはできません。

複数のディメンション・セットを使用した翻訳の作成

この状況を改善するために、開発者は国ごとに異なるディメンション・セットを作成して、それぞれに独立したフォールバック・ロジックを定義できるようにします。たとえば、顧客が、フランス語のコンテンツなどのサイトに英語のコンテンツを表示したくないと考える場合があります。一方、オランダを拠点にする顧客が、オランダ語のコンテンツに加えて、英語のコンテンツを自社のサイトに掲載したいと考える場合もあります。つまり、必要となるフォールバック・メカニズムは国ごとに異なります。

そのため、サイトの対象が20か国の場合は、ディメンション・セットは20 (おそらく合計で30から40以上のロケール)になります。複数のディメンション・セットをサポートするには、レンダリングするテンプレート・コードで、使用するディメンション・セットを決定できるようにする必要があります。翻訳タグには、現在の翻訳のディメンション・セット名が必要です。次の2つのプロパティでは、複数のディメンション・セットを使用できます。

- ディメンション・セットの名前は、国コードの値です。たとえば、ukは英国、deはドイツなどです。

- すべてのWeb参照可能アセットには、国コードを明示的に含むURLパス(例: www.mysite.com/uk/helloworldおよびwww.mysite.com/de/helloworld)が含まれ、またはuk.mysite.com/helloworldなどの異なるサブドメインをサポートできます。

注意:

Accept-Language値またはIPジオロケーションに基づいて、ユーザーごとに同じURLの異なるコンテンツをレンダリングすることは、一般的には不適切な行為です。その理由は、Googleなどの検索エンジンが、このような戦略をおとり商法の形態と判断する場合があるため、SEOランキングが低くなる可能性があるためです。

前述の2つの機能が配置されている場合、開発者は、URLリクエストを解析して国の値を抽出し、追加の引数として国の値を渡します(この値はテンプレートで使用され、現在のアセットに使用するディメンション・セットを指定できます)。(デフォルトと想定できる国コードのないプライマリ・サイトを選択することは、一部の顧客にとって一般的です。)

別のオプションは、訪問者がブラウザに設定した可能性のある優先ロケールCookieをコードで優先することです。

他の言語が使用されるWebサイトで顧客が同じコンテンツを希望するタイミング

一部の顧客は、アセットを…/us/helloworldとしてパブリッシュ可能な仮想URLのサポートを希望しています。これらの顧客は、同じコンテンツが(翻訳する必要なく)他の英語のサイト(例: …/uk/helloworld、…/ca/helloworld、…/au/helloworldなど)でレンダリングされることも希望しています。後者の要件は、グローバル(またはマスター)バージョンのアセットを作成することで処理できます。そのため、ISOロケールのみをディメンション・セットに階層的に含めるのではなく、開発者は構成済のロケール必要に応じて含めることができます。次のCH (スイス)のディメンション・セットの例では、グローバルディメンション・セットの使用について説明します。

global
en_GLOBAL
en_CH
de_GLOBAL
de_CH
fr_GLOBAL
fr_CH

前述の階層ディメンション・セットは次のように機能できます。

- エディタでロケール固有の差異が必要な場合、必要に応じてローカライズ済のアドホック翻訳を行うことができます。例: en_CH、de_CHまたはfr_CH。

- 言語固有の差異を別のディメンション・セットで使用可能にする必要がある場合、開発者は、アドホック・グローバル翻訳をかわりに行うことができます。例: en_GLOBAL、global-de、fr_GLOBAL。

前述のような固定階層では、フォールバック・ロジックの例外を含めることができません。

前述の例は、地域のフォールバックも含まれるように拡張できます(例: 中南米スペイン語es_LADおよび南アジア英語en_AS)。これにより、マーケティングで、中南米の対象者向けにローカライズされたコンテンツを作成し、en_GLOBALが使用されている場合のように、他の国際サイトに表示することなく、そのコンテンツを多くの国のサイトに配信できます。

ロケール固有のコンテンツの検索の有効化

様々なフォールバック・ロジックをすべて考慮しながら、問合せベースの検索でロケール単位アセットのリストをどのようにまとめ、レンダリングすればよいでしょうか。たとえば、訪問者がフランス語のWebサイトにいる場合、その訪問者が希望するのは、おそらくfr_FRまたはfr_GLOBALのコンテンツを閲覧することです。同じディメンション・セットで重複する翻訳は回避する必要があります。

解決策

検索可能な属性に基づいて動的リストを問合せで返すには、検索を特定のロケールに制約するのに使用可能な属性がアセットに必要です。これを有効にするには、カスタム・フレックス・フィルタを介して、各アセットの選択済ロケール(このような属性ではありません)を、SearchableLocaleという名前の複数値属性に変換する必要があります。たとえば、ほとんどのクライアントでは、fr_FRがフランス語のフォールバック階層のリーフ・ノードになるため、ロケールがfr_FRのアセットには、SearchableLocale=fr_FRの単一の値が格納されます。ただし、ロケールがfr_GLOBALのアセットには、fr_FRおよびすべてのフランス語圏の国のその他のフランス語ロケールを格納する必要があります。これにより、制約された問合せを介して、このグローバルフランス語アセットを複数のフランス語サイトに表示できます。たとえば、ヨーロッパのみのWebサイトの場合、fr_GLOBALアセットでは、そのフレックス・フィルタを介して保存時にfr_FRおよびfr_CH SearchableLocale値が作成されるため、フランス(FR)およびスイス(CH)のサイトに表示されます。

注意:

前述のアセット属性へのフォールバック値の非正規化により、実行時に少ない問合せを実行できます。マーケティングでフォールバック・ロジックの変更が必要な場合、すべてのデータ値を再計算する必要があります。ソリューションの設計時には、注意して進めてください。

特定の国のサイトでのグローバルアセットの非表示

多くの顧客は、グローバル・アセットを特定の国で非表示にしたいと考えています。したがって、翻訳可能なアセットごとに、HideFromTheseCountries属性を定義に追加する必要があります。編集インタフェース(選択したロケールに基づいて、現在のアセットの非表示が可能)に表示される国のリストを制限するには、カスタム属性エディタを作成する必要もあります。つまり、現在のロケールがfr_FRの場合、非表示にする国のリストはNULLになります。一方、選択したロケールがfr_GLOBALの場合、国のリストには、すべての国のサイトをサポートするために作成されるディメンション・セットの数に応じてFR、CHなどが含まれます。

カスタムHideFromTheseCountries属性/属性エディタと、最適化されたロケールを複数値SearchableLocale属性として非正規化するカスタム・フレックス・フィルタの組合せにより、テンプレートのレンダリングの問合せでは、現在のロケールを制約として追加するだけで済みます。たとえば、ロケールがfr_FRのWebページでは、最新ニュースを右側のページレットに表示できます。このページレットでは、locale=fr_FRのNewsアセットを問い合せて、日付別にリストをソートします。fr_GLOBALアセットもfr_FRに翻訳され、それにより両方がリストに返されるため、重複する場合があります。重複を削除するには、重複を除外する制約された問合せからiListを取得する、翻訳タグ<dimensionset:filter>を使用します。

キャッシングの問題の処理

すべての翻訳を一度にパブリッシュする場合、既存の翻訳を変更すると、そのアセットに依存するページレットは、パブリッシュ時に失効します。グローバル・バージョンの言語をパブリッシュしてから、そのアセットのローカライズ済バージョンを後で作成すると、ページレットの最後のレンダリング時に依存関係が記録されないため、システムが更新を認識する方法がありません。

簡単な例として、フランス語ページの最新のプレス・リリースのリストを取り上げ、すべてのアセットがfr_GLOBALとしてレンダリングされていると想定します。さらに、リンクが名前付きアソシエーションとして明示的に定義され、すべての依存関係がレンダリング/キャッシュ時に認識されることも想定します。これらのアセットのいずれかを翻訳してパブリッシュする場合、希望する動作は、リンクがグローバル・バージョンではなく、ローカライズ済の翻訳になることです。しかし、ページレットの最後のレンダリング時に存在していないアセットへの依存関係をロギングする方法はないため、システムがそのリンクの更新を認識する方法はありません。このため、新規翻訳のパブリッシュ時に何も未キャッシュされません。

簡単な解決策は、新しい子がディメンション・セットに追加されたら常にマスター・アセットを更新することです。そのためには、既存のディメンション・セットに影響する可能性のある新規アセットがパブリッシュされたら常に、これらのタスクをバックグラウンドで実行するカスタム・パブリッシュ・リスナーを実装する必要があります。アセットの承認およびパブリッシュまでは数日から数週間かかる場合があるため、新規翻訳の作成時にマスター・セットを更新する必要はありません。

また、マスター・アセットがチェックされたか、まだ承認されていない可能性のある状況については、自動承認メカニズムで処理する必要もあることに注意してください。

第IV部 モバイル用Webサイトの開発

この部では、Mobilityについて説明します。Mobilityのユーザーは、携帯電話やタブレットなどの様々なモバイル・デバイスにWebサイトを作成、プレビューおよび配信できます。

この部は、次の章で構成されています。

- モバイルWebサイトをサポートするためのWebCenter Sitesの構成

26 モバイルWebサイトをサポートするためのWebCenter Sitesの構成

Mobilityのユーザーは、携帯電話やタブレットなどの様々なモバイル・デバイスにWebサイトを作成、プレビューおよび配信できます。モバイルが最適化されたWebサイトをサポートするようにMobilityを実装するには、そのフレームワークを構成する必要があります。

Mobilityフレームワークの詳細は、次の項を参照してください。

- 開発者の前提条件

- 主要なMobilityの概念の理解

- Mobility機能を構成するための前提条件

- Mobility機能の構成

- 配信システムへのデバイス・リポジトリのミラー・パブリッシュ

- テンプレートの作成

- モバイルWebサイトのイメージの最適化

- デバイス検出の仕組み

26.1 開発者の前提条件

Mobilityフレームワークを構成するには、サイト・ナビゲーションやテンプレートなど、WebCenter Sitesのコア機能の使用経験が必要です。また、モバイル・デバイスおよびそのユーザー・エージェントに対する理解が必要です。

26.2 主要なMobilityの概念の理解

WebCenter Sitesは、組込みのデバイス検出メカニズムを使用して、Webサイトのコンテンツを要求するデバイスを識別します。デバイスが識別されると、WebCenter Sitesは適切なサイト・ナビゲーション(以前のリリースではサイト・ナビゲーションと呼ばれていました)を検索し、適切なテンプレートを呼び出してWebサイトをレンダリングします。

このデバイス検出プロセスのメカニズムには、デバイス・リポジトリ、デバイス・グループおよび接尾辞、デバイス・アセット、テンプレート・バリアント、サイト・ナビゲーション(モバイルWebサイトをサポートできるように拡張されている)などの新機能が関係しています。この項では、これらの新機能の背後にある概念について説明します。その後、モバイルWebサイトをサポートする機能の構成手順も示します。

機能が構成されたら、Oracle WebCenter Sites: Contributorインタフェースで、図26-1に示すようなモバイル・サイトを作成、プレビューおよび配信できます。この図では、avisportsサンプル・サイトのホームページが、3つのデバイスのコンテキストで表示されます(マルチデバイス・プレビュー)。

図26-1 Contributorインタフェースの複数デバイスのコンテキストのavisportサイト・ホームページのプレビュー

この項には次のトピックが含まれます:

- デバイス・リポジトリについて

- デバイス・グループおよび接尾辞について

- デバイス・アセットについて

- サイト・ナビゲーションについて

- モバイル・テンプレートについて

26.2.1 デバイス・リポジトリについて

デバイス・リポジトリは、WebCenter Sitesでモバイル・デバイスの検出に使用するファイルです。デバイス・リポジトリには、デバイスのプロパティが含まれ、そのユーザー・エージェントに基づいて各デバイスを一意に識別します。WebCenter Sitesは、デバイス・リポジトリで指定されるユーザー・エージェントにデバイスのユーザー・エージェントを一致させることにより、デバイスを検出します。

注意:

ユーザー・エージェントは、ユーザーの代理として機能するソフトウェア・エージェントです。ユーザー・エージェント文字列のフォーマットは、オプションのコメントを持つ製品トークン(キーワード)のリストです。ほとんどのブラウザは、次のフォーマットを指定します。

Mozilla[version] (system and browser information]) [ platform] ([platform details]) [extensions]

次に例を示します。

Mozilla/so(iPad;u;CPUOS 3.2.1 like Mac OSx;en-us)ppleWebkit/531.21.10(KHTML,like Gecko) Mobile/7B405

次の2つのタイプのデバイス・リポジトリがあります。

- devices.xml: これは、WebCenter Sitesに含まれているデフォルトのリポジトリです。このリポジトリは、製品リリース時に更新され、ポピュラーなデバイスのみが含まれています。必要に応じて、このリポジトリにデータを追加できます。

- WURFL: これは、ScientiaMobileのサード・パーティ・デバイス情報データベースです。WURFLはdevices.xmlよりも包括的で、ScientiaMobileによって定期的にアップデートされます。WURFLを使用して、常に最新のデバイスを保持することをお薦めします。ライセンス・コピーは、ScientiaMobileから取得できます。WebCenter Sitesには組み込まれていません。

デバイス・リポジトリの使用手順については、「デバイス・リポジトリの構成方法」を参照してください。

26.2.2 デバイス・グループおよび接尾辞について

デバイス・グループでは、デバイスの機能ベースのグループ化が可能です。デバイス・グループは、共通のWebサイトが配信可能な、共通の特徴を持つデバイスのコレクションを定義するアセットです。たとえば、図26-2 に示すように、すべてのタッチフォンはあるグループに属することができ、ノンタッチ(QWERTY)フォンは別のグループに属することができます。このため、1つのWebサイトがすべてのタッチ・デバイスに配信されます。また、別のWebサイトがすべてのノンタッチ(QWERTY)デバイスに配信されます。そのため、2セットのテンプレートをコーディングする必要があります。1セットはタッチ・デバイス・グループ用で、もう1セットはノンタッチ・デバイス・グループ用です。

図26-2 デバイス・タイプベースのグループ化

テンプレート・バリアントをサポートするために、接頭辞の概念が導入されています。接尾辞は、正しいデバイス・グループにテンプレートを関連付けるために使用します。テンプレートおよびデバイス・グループが、_Touch(または_NonTouch)などの、同じ接尾辞を持つ場合に関連付けが行われます。たとえば、基本テンプレートHomeLayoutがデスクトップWebサイトのレンダリングに使用される場合は、テンプレートのバリアント、つまり、HomeLayout_suffixという名前のテンプレートを作成します。この例では、タッチ・デバイス・グループ内のデバイスのコンテンツをレンダリングするためにHomeLayout_Touchテンプレートを作成します。また、ノンタッチ・デバイス・グループ内のデバイスのコンテンツをレンダリングするためにHomeLayout_NonTouchテンプレートも作成します。

実行時に、WebCenter Sitesは、テンプレート・バリアントの名前に対してデバイス・グループの接頭辞を照合します。タッチ・デバイスからHomeLayoutがリクエストされると、WebCenter Sitesは、HomeLayout_Touchテンプレートを使用してWebサイトをレンダリングします。これはデバイス検出の一環です。

注意:

接尾辞のないテンプレートは、基本テンプレートと呼ばれます。接尾辞のあるテンプレートは、基本テンプレートのバリアントと呼ばれます。基本テンプレートは、そのバリアントが作成される前に存在している必要があります。

接尾辞は、デバイス・グループをナビゲーション・プランに関連付けるためにも使用されます。これにより、異なるデバイス・グループ内のデバイスに対して異なるWebサイト・ナビゲーションを実装できます。テンプレートは、配信システムにおけるWebサイト・ナビゲーションを指定するために、device:siteplanタグを使用してコーディングされます。

デバイス・グループを作成するには、タイプDeviceGroupのアセットを作成します。その過程で、次のものを指定します。

- 接尾辞。

- 登録されているデバイス名、またはデバイスを作成対象のグループに関連付けるためにWebCenter Sitesで使用される基準のいずれか。

注意:

デバイスの検出中に、デバイス・グループへのデバイスの照合が適切に行われるように、複数のデバイス・グループに優先順位を付ける必要があります。

デバイス・グループの構成手順については、「デバイス・グループの構成方法」を参照してください。デバイス・グループの優先順位付け手順については、「デバイス・グループの優先順位付け方法」を参照してください。

26.2.3 デバイス・アセットについて

モバイル・デバイスは、デバイス・アセットで表すことができ、Contributorインタフェースにおけるモバイル・デバイスのコンテキストで、モバイルWebサイト・コンテンツのプレビューが行えます。デバイス・アセットは、プレビューをサポートする目的でのみ使用されます。デバイス・アセットは、デバイスが同じデバイス・グループで収集されるほど類似している場合でも、バリエーションを示します(画面サイズなど)。デバイス・アセットのコンテキストでプレビューすることにより、コンテンツ・コントリビュータは、対応する実デバイス上でコンテンツが正しくレンダリングされることを確認できます。

デバイス・アセットは、イメージとユーザー・エージェントで構成されます。ユーザー・エージェントは、デバイス・アセットを(1)デバイス・リポジトリの実デバイスおよび(2)基準に一致するデバイス・グループに関連付けるために使用します。デバイス・グループとデバイス・アセットの関係を示す関連付けの例については、図26-3 を参照してください。

図26-3 デバイス・グループに関連付けられたデバイス

デバイス・アセットは、デバイス検出によってデバイス・グループに関連付けられます。デバイス・アセットが2つ以上のデバイス・グループで指定される基準に一致する場合、希望する(優先順位が最も高い)デバイス・グループに自動的に関連付けられます。デバイスがすべてのデバイス・グループの基準に一致しない場合、デフォルトのデバイス・グループ(デスクトップ・ブラウザへのWebサイトの提供に使用される)に自動的に割り当てられます。デバイスがデバイス・グループに関連付けられたら、そのデバイス・グループに関連付けられているテンプレートがプレビュー・モードでWebサイト・コンテンツをレンダリングできます。コンテンツは、デバイス・イメージ上で上書きされます。

注意:

コンテンツ・コントリビュータが次のプレビュー動作を認識していることを確認してください。

- モバイル・デバイスのWebページのプレビューがすべてのブラウザで機能しているときに、ブラウザとユーザー・エージェント間で不一致がある場合には、一部の機能が正しく表示されません。たとえば、ユーザー・エージェントがAndroid上のFireFoxであるときに、Internet ExplorerでContributorインタフェースを開くと、ブラウザはInternet Explorerエンジンを使用してHTMLをレンダリングします。したがって、Contributorインタフェースのプレビューは、実モバイル・デバイス上の実際のページ表示とは異なる可能性あります。

- プレビューでは、実デバイス上のフルスクリーン・モード表示でページがレンダリングされます。

デバイスの作成手順については、「デバイス・アセットの作成方法」を参照してください。

26.2.4 サイト・ナビゲーションについて

サイト・ナビゲーションは、Webサイトのナビゲーショナル階層を定義します。たとえば、図26-4に、Contributorインタフェース内のavisportsサンプル・サイト用の「デフォルト」、タッチおよびノンタッチ・サイト・ナビゲーションを示します。

図26-4 Contributorインタフェースのサイト・ナビゲーション

サイト・ナビゲーションを作成する場合、共有接尾辞を選択することによって、デバイス・グループをそのサイト・ナビゲーションに関連付けます。サイト・ナビゲーションは、それらのデバイス・グループのデバイスに提供されます。(選択すると、その接尾辞は他のサイト・ナビゲーションに対して使用できなくなります。)

サイト・ナビゲーションの作成には、次の2つの基本的な方法があります。

- すべてのデバイス・グループのすべてのデバイスの単一サイト・ナビゲーションを作成します。

- 異なるデバイス・グループ用に異なるサイト・ナビゲーションを作成します。コンテンツはサイト・ナビゲーション間で再利用することもできれば、サイト・ナビゲーションごとに変えることもできます。

サイト・ナビゲーションの構成手順については、「サイト・ナビゲーションの作成方法」を参照してください。

26.2.5 モバイル・テンプレートについて

モバイルWebサイトをレンダリングするテンプレートを作成するには、次の2つの基本的な方法があります。

- すべてのモバイル・デバイス(つまり、すべてのデバイス・グループ)に適応する単一セットのテンプレートを作成します。Adaptiveテンプレートは、デバイスの画面解像度に適応し、コンテンツを適切にレンダリングします。このシナリオでは、接尾辞の付いたテンプレートを作成する必要はありません。

- 異なるデバイス・グループ用に異なるテンプレートを作成します。(その例が「デバイス・グループと接尾辞について」で説明されています。)このシナリオでは、2セットのテンプレートを作成する必要があります。1つのセットには基本テンプレート(接尾辞なし)を含めます。他のセットには、テンプレート・バリアント(接尾辞付きテンプレート)を含めます。テンプレート・バリアントを作成するには、基本テンプレートの名前に_suffixを追加します。
たとえば、接尾辞がTouchであるiPhonesというデバイス・グループのテンプレート名は、BaseTemplateName_Touchになります。このネーミング規則、およびデバイス・グループとテンプレートの接尾辞の照合により、WebCenter Sitesで、モバイル・デバイスから適切なテンプレート・バリアントへリクエストがルーティングされるようになります。特定のデバイス・グループにモバイル・テンプレート・バリアントが存在しない場合は常に、基本テンプレートが使用されます。

注意:

WebCenter Sitesは、2つの接頭辞(_Touch_NonTouchなど)を持つテンプレートは認識しません。これらは既存のテンプレートのバリアントだとはみなされません。このようなテンプレートはContributorインタフェース内のアセット・ツール・バー上のページ・レイアウトの選択オプションを介して使用できないため、アセットのレンダリングには使用されません。2つの接頭辞を持つテンプレートのかわりに基本テンプレートが使用されます。

デバイス・グループを作成して接尾辞を把握したら、いつでもテンプレートを作成できます。テンプレートの作成の詳細は、「テンプレートの作成」を参照してください。

26.3 Mobility機能を構成するための前提条件

Mobility機能の構成を開始する前に、次の資格証明と情報を持っていることを確認します。

- Adminインタフェースの「モビリティ」タブへのアクセスを自動的に付与されるユーザーは、GeneralAdminロールが割り当てられているユーザーのみです。

注意:

MobileSitesDeveloperロールは現在使用できません。11.1.1.8.0リリースからアップグレードした場合、MobileSitesDeveloperロールはユーザー定義のロールとして機能し、特に重要ではないことに注意してください。したがって、「モビリティ」タブへのアクセス権をGeneralAdminロールに付与する必要があります。

- 使用するデバイス・リポジトリに対する理解。オプションおよび手順の詳細は、「デバイス・リポジトリの構成方法」を参照してください。

- 構成するデバイス・グループに関する情報。

- 異なるデバイスを編成する対象デバイス・グループの名前。

- デバイスを特定し、グループ化するのに使用する機能(ユーザー・エージェント、タッチ、タブレット、画面解像度など)。どのデータを提供するかの詳細は、「デバイス・グループの構成方法」を参照してください。

- どの接尾辞を各デバイス・グループで使用するか。接尾辞は、各デバイス・グループに必要です。(これらのデバイス・グループのテンプレート・バリアントの名前に接尾辞を追加します。サイト・ナビゲーションに対しても同じ接尾辞を選択します。)

- デフォルトではリストされない機能に条件を適用するためにカスタム・フィルタを使用するかどうか。詳細は、「デバイス・グループ基準に対するカスタム・フィルタの作成方法」を参照してください。

- コントリビュータがモバイルWebサイトのプレビューで使用するデバイスのリスト。WebCenter Sitesは、一般的に使用されている多くのデバイスを表す複数のデバイス・アセットを備えています。
独自のデバイス・アセットを作成するには、最初に実デバイスの独自のイメージを作成して、その実デバイスのユーザー・エージェントを検索します。これらのイメージとユーザー・エージェント情報を使用して、デバイス・アセットを作成します。また、Contributorインタフェースのデバイス・セレクタ・パネルで使用するためにサムネイル・イメージも作成します。

- Webサイトのモバイル・バージョン用の効果的なサイト・ナビゲーション。

26.4 Mobility機能の構成

モバイルWebサイト用のインフラストラクチャを作成するには、次の項で説明する手順を実行します。

- デバイス・リポジトリの構成方法

- デバイス・グループ基準に対するカスタム・フィルタの作成方法

- デバイス・リポジトリのアクティブ化方法

- デバイス・グループの構成方法

- デバイス・グループの優先順位付け方法

- デバイス・アセットの作成方法

- サイト・ナビゲーションの作成方法

- サイト・ナビゲーションの編成方法

26.4.1 デバイス・リポジトリの構成方法

devices.xml (デフォルトのリポジトリ)とWURFLのどちらかのデバイス・リポジトリを使用するオプションが用意されています。

- devices.xmlを使用するには、次の手順を実行します。

1. ファイルに必要なデバイス名とユーザー・エージェントが含まれていることを確認します。DeviceRepositoryディレクトリ内でファイルを検索し、必要な変更を行います。

2. devices.xmlをWebCenter Sitesにアップロードすることによってアクティブ化します。手順は、「デバイス・リポジトリのアクティブ化方法」を参照してください。

- devices.xmlファイルに現在登録されているものより多くの機能およびデバイスをサポートするには、WURFLをデバイス・リポジトリとして使用します。次の手順を実行します。

1. 次のいずれかのフォーマットでWURFLリポジトリを取得します。

- WURFL.zip

- WURFL.xml (WURFLパッチ・ファイルと一緒に)。パッチ・ファイルは、WURFL.xmlのコンテンツをオーバーライドするために使用します。パッチ・ファイルの詳細は、http://wurfl.sourceforge.net/を参照してください。

注意:

WURFLは、サード・パーティのデバイス・リポジトリです。このリポジトリを使用するには、ScientiaMobileからライセンスを購入する必要があります。WebCenter Sitesには組み込まれていません。

2. wurfl.xmlファイルとパッチを使用する場合は、他の手順に進む前にパッチ・ファイルを構成します。

3. WURFLリポジトリをWebCenter Sitesにアップロードすることによってアクティブ化します。手順は、「デバイス・リポジトリのアクティブ化方法」を参照してください。

26.4.2 デバイス・グループ基準に対するカスタム・フィルタの作成方法

WebCenter Sitesでは、入力としてXMLファイルをとる、デフォルトのカスタム・フィルタ実装(DefaultCustomFilter.java)を提供しています。独自のカスタム・フィルタを作成するには、CustomDeviceFilter.javaインタフェースの実装を記述します。カスタム・フィルタ用のXMLファイルは、「デバイス・グループの構成方法」で説明するように、「デバイス・グループ」構成ページからアップロードされます。

この項には、次の項目が含まれます。

- WebCenter Sitesに付属するデフォルトのDefaultCustomFIlter.javaカスタム・フィルタの使用

- 独自のDeviceGroupFilter実装の作成

注意:

カスタム・フィルタの使用方法の詳細は、「デバイス・グループの構成方法」を参照してください。

26.4.2.1 WebCenter Sitesに付属するデフォルトのDefaultCustomFIlter.javaカスタム・フィルタの使用

カスタム・フィルタのデフォルト実装クラスは、COM.FutureTense.Mobility.Filter.DefaultCustomFilterと呼ばれています。XML形式の入力を受け入れます。WebCenter Sitesが提供するデフォルトのカスタム・フィルタ実装では、すべての属性が渡された場合にのみ、フィルタが渡されます。同様に、そのすべてのフィルタが渡されると、カスタム・フィルタ全体が渡されます。そのため、どのシナリオでも、フィルタ条件を機能させるために、すべての引数を渡す必要があります。

次の例は、WURFLリポジトリからデバイス・プロパティ名をとるサンプル・フィルタXMLを示しています。

<?xml version="1.0" encoding="UTF-8"?>
<devicefilters>
<filter name="tabletFilter" classname="COM.FutureTense.Mobility.Filter.DefaultCustomFilter"> //Filter 1
<argument name="is_tablet" value="true" datatype="boolean"/> //argument 1 of filter 1
<argument name="pointing_method" value="touchscreen" datatype="string" operator="equals"/> //argument 2 of filter 1
</filter>
<filter name="flashFilter" classname="COM.FutureTense.Mobility.Filter.DefaultCustomFilter"> //Filter 2
<argument name=" full_flash_support" value="false" datatype="boolean"/> //argument 1 of filter 1
</filter>
</devicefilters>

前述のサンプルでは、tabletFilterは2つの引数を持ちます。argument 1は、is_tabletプロパティの値がtrueである必要があり、argument 2は、pointing_methodプロパティの値がtouchscreenである必要があります。flashFilterは、full_flash_supportプロパティの値がfalseである必要がある、1つの引数のみを持ちます。各引数はルールで、完全なフィルタです。すべての引数の条件が満たされる場合にのみ、前述のカスタム・フィルタを含むデバイス・グループとデバイスが一致します。

このサンプルXMLでは、WURFLリポジトリからのデバイス・プロパティ名を使用します。デフォルト・デバイス・リポジトリ(devices.xml) XMLは、次の例のようになります(プロパティ名が変更されていることに注意してください)。このフィルタXMLには、tabletFilterおよびflashFilterという、2つのフィルタがあります。

<?xml version="1.0" encoding="UTF-8"?>
<devicefilters>
<filter name="tabletFilter" classname="COM.FutureTense.Mobility.Filter.DefaultCustomFilter"> //Filter 1
<argument name="tablet" value="true" datatype="boolean"/> //argument 1 of filter 1
<argument name="touch" value="true" datatype="string" operator="equals"/> //argument 2 of filter 1
</filter>
<filter name="flashFilter" classname="COM.FutureTense.Mobility.Filter.DefaultCustomFilter"> //Filter 2
<argument name="flash" value="false" datatype="boolean" /> //argument 1 of filter 1
</filter></devicefilters>

DefaultCustomFIlter.javaに基づいてカスタム・フィルタを作成する場合は、次の点を考慮してください。

- カスタム・フィルタでは、datatype引数属性の可能な値は、string、number、booleanです。デフォルト値はstringです。

- datatype = numberの場合、operator属性の可能な値は、<>、notequals、<、lt、>、gt、=、equalsです。デフォルト値はequalsです。

- datatype = booleanの場合、operator属性の可能な値は、=、equalsです。他の値は、equalsの逆の値として処理されます。デフォルト値はequalsです。

- datatype = stringの場合、operator属性の可能な値は、=、equals、%、like、!=、notequals、!%、notlikeです。デフォルト値はequalsです。次のスニペットは、operator属性のlikeまたは%値の使用を示しています。

<argument name="pointing_method" value="touch" datatype="string" operator="like"/>

ここでは、pointing_methodプロパティの値には、touchがサブ文字列または単語全体として含まれている必要があります。

- プロパティ属性の値は、現在のデバイス・リポジトリのプロパティ名どおりである必要があります(devices.xmlまたはWURFL.xmlのいずれか)。

26.4.2.2 独自のDeviceGroupFilter実装の作成

次の例は、DeviceGroupFilterインタフェースを実装し、matchesメソッドを使用するJavaクラスを示しています。カスタム・フィルタは1つ以上のフィルタで構成できます。各フィルタには0以上の引数を含めることができます。カスタム・フィルタ実装は、ORルールまたはカスタム・ロジックを使用できます。

public class UserDefinedCustomFilter implements DeviceGroupFilter
{
public boolean matches(DeviceContext context)
{
// Logic that returns true/false depending on whether criteria matched or not.
}
}

26.4.3 デバイス・リポジトリのアクティブ化方法

デバイス・リポジトリをアクティブ化するには:

1. Adminインタフェースで、General Adminツリーを開き、「モビリティ」ノードを展開し、「デバイス・リポジトリ」をダブルクリックします。

2. 「デバイス・リポジトリ・アップローダ」フォームで、デフォルトのリポジトリ(devices.xml)またはWURFLリポジトリ(WURFL.zipまたはwurfl.xmlおよび現在のパッチ・ファイル)をアップロードします。

注意:

デバイス・リポジトリを切り替える場合、すべてのデバイス・グループにわたってdevices.xmlで変更したデバイス名を更新するよう注意されます。

WURFL.patchファイルは、デバイス・リポジトリ表のWURFL.patchのレコードがまだActive=F (false)に設定されていることとは関係なく、WURFL.xmlファイルと一緒に使用されます。

図26-5 「デバイス・リポジトリ・アップローダ」フォーム

3. 「保存」アイコンをクリックします。

26.4.4 デバイス・グループの構成方法

デバイス・グループを構成するには:

1. 「モビリティ」ノードで、「デバイス・グループ」ノードを開きます。

2. 図26-6 に示すように、「デバイス・グループの追加」をクリックします。

図26-6 デバイス・グループの追加

「デバイス・グループ」フォームが開きます。

3. 「デバイス・グループ」フォームで「コンテンツ」タブを選択して、次の操作を実行します。

a. 「名前」フィールドに、作成しているデバイス・グループのわかりやすい名前を入力します。

b. 「接尾辞」セクションで、このデバイス・グループ(図26-6 )用に作成するテンプレートで使用する接尾辞を入力します。または、既存の接尾辞がある場合は、それを選択します。

注意:

この接尾辞は編集できません。後で変更するには、このデバイス・グループを再作成して、この接尾辞を変更する必要があります。

c. 「アクティブ」フィールドで「はい」を選択すると、このデバイス・グループのデバイス検出が有効になります。

注意:

デバイス・グループはグローバルです。有効化すると、すべてのサイトで利用できるようになります。同様に、無効化すると、すべてのサイトで利用不可になり、デバイス検出で使用されなくなります。

4. 「基準」タブ(図26-7)を選択し、適切なテンプレート・バリアントに関連付けることのできる、実デバイスの照合用のルール・セットを作成します。
1つ以上のデバイス名を入力するか(残りのフォームは無効になる。図26-7を参照)、デバイス名を省略して残りのフォームに記入します。

図26-7 デバイス名の追加

a. デバイス名を入力する場合は、「デバイス・リポジトリの構成方法」で説明されている手順を実行したときに選択したデバイス・リポジトリに登録されているのと同じ名前を入力します。devices.xmlをアップロードした場合は、デバイス・エントリ名を入力します。WURFLをアップロードした場合は、デバイスのmodel_nameを入力します。
「デバイス名」フィールドには先行入力機能が用意されているため、使用可能なデバイスのリストから登録済のデバイス名を選択できます。デバイス・モデル番号の入力を開始すると、一般的な文字から始まる登録済のデバイスがすべて表示されます。最初の50のデバイスをスクロールしてこの中から簡単に選択できます。これ以外のデバイスを表示するには、検索フィルタを絞り込みます。

デバイスは、一度に1つのデバイス・グループにしか属することができません。

「デバイス・グループの優先順位付け方法」に進みます。

b. デバイス名を省略する場合は、次のように、残りのフォームを記入します。

i. 「ユーザーエージェント」セクション: このセクションは、デバイス名を指定する場合は無効になります。
このフィールドには、デバイス名のリスト、またはユーザー・エージェント、画面ディメンション、機能およびカスタム・フィルタの組合せを入力します。ユーザー・エージェントregex、機能、画面ディメンションおよびカスタム・フィルタの組合せでは、デバイスは、デバイス・グループとの照合に使用されるすべてのルールを満たす必要があります。

受信リクエストの送信元のブラウザと一致するユーザー・エージェントを入力します。または、ユーザー・エージェントのセットと照合する正規表現や部分文字列を入力します。たとえば、すべてのiPhoneユーザー・エージェントを照合するには、ユーザー・エージェントreg expを(m|M)ozilla/5.0(| )\(i(p|P)(hone|od|rod).*として指定します。この式は、iPhone Java regexを含むすべてのユーザー・エージェント文字列に一致します。または、すべてのiPhoneに一致する部分文字列iPhone;を使用します。

注意:

デバイス・リポジトリ内で入力したユーザー・エージェント用として使用可能なデバイスの数を確認するには、「一致しているデバイス」セクションで「リフレッシュ」アイコンをクリックします。

ii. 「機能」セクション: このセクションは、デバイス名を指定する場合は無効になります。その機能は、「タッチ・スクリーン」、「JavaScript」、「縦横方向」および「タブレット」です。各機能には、「はい」、「いいえ」、「評価しない」というオプションがあります。
たとえば、このデバイス・グループでJavaScriptをサポートしないタブレット・デバイスのみを照合するには、「タブレット」機能で「はい」を、「JavaScript」機能で「いいえ」を、残りの機能で「評価しない」を選択します。

iii. 「画面解像度」セクション: このセクションは、デバイス名を指定する場合は無効になります。表示領域の最大と最小の幅および高さ(単位はピクセル)を入力します。たとえば、最大幅が640である場合、画面解像度の幅が640以下であるすべてのデバイスにこのデバイス・グループが一致します。

iv. 「カスタム・デバイス・フィルタ」セクションで「参照」をクリックして、「デバイス・グループ」の「基準」タブにリストされていない機能に対して条件を適用するために作成した可能性のあるカスタム・フィルタを選択します。カスタム・フィルタを作成してデバイス基準を設定する方法については、「デバイス・グループ基準に対するカスタム・フィルタの作成方法」を参照してください。

5. 「保存」アイコンをクリックして、デバイス・グループを保存します。
新しいデバイス・グループが「モビリティ」タブで、「デバイス・グループ」ノードの最下部にリストされます(図26-8)。

図26-8 新しいデバイス・グループ

注意:

デバイス・グループに優先順位を付けてデバイス・アセットを作成したら、デバイス・グループとデバイス・アセットがデバイス検出によって正しく関連付けられていることを確認します。デバイス・グループを開いて「デバイス」タブを選択し、そのデバイス・グループに関連付けられているデバイス・アセットのリストを表示します。

デバイス・グループの優先順位付け手順については、「デバイス・グループの優先順位付け方法」を参照してください。

デバイス・アセットの作成手順については、「デバイス・アセットの作成方法」を参照してください。

26.4.5 デバイス・グループの優先順位付け方法

実行時のデバイス検出で、優先順位が最も高いデバイス・グループに実デバイスが自動的に関連付けられるように、複数のデバイス・グループに優先順位を付ける必要があります。

デバイス・グループに優先順位を付けるには:

1. 「モビリティ」ノードの下で、「デバイス・グループ」ノードを開きます。

2. 「デバイス・グループの並替え」(図26-9 )をダブルクリックします。

図26-9 デバイス・グループの並替え

3. 「デバイス・グループの並替え」ページで、希望する優先順位順にデバイス・グループをドラッグ・アンド・ドロップします(図26-10)。

図26-10 デバイス・グループのドラッグ・アンド・ドロップ

デバイス・グループを並べ替えたら、「デバイス・グループの並替え」ページに新しい順序でデバイス・グループが表示されます(図26-11)。

図26-11 並べ替えられたデバイス・グループ

4. 「優先順位の保存」をクリックします。

「デバイス・グループの優先順位の再設定が正常に行われました」メッセージが表示されます。

26.4.6 デバイス・アセットの作成方法

デバイス・アセット作成するには:

1. 「モビリティ」ノードで、「デバイス」ノードを開きます。

2. 「デバイスの追加」(図26-12 )をクリックします。

図26-12 デバイスの追加

図26-13に示すように、「デバイス」フォームが開きます。

図26-13 「デバイス」フォーム - 「コンテンツ」タブ

3. 「コンテンツ」タブ(図26-13 )で、次の操作を実行します。

a. 「名前」フィールドに、このデバイス・アセットの名前を入力します。
この名前はContributorインタフェースに表示されます。デバイス・リポジトリ内の名前と一致している必要はありません。

b. (オプション)。「製造業者」フィールドに、デバイス・メーカーの名前を入力します。

c. 「ユーザー・エージェント」フィールドで、イメージを追加するデバイスの登録済ユーザー・エージェントを指定します。ユーザー・エージェントは、デバイス・リポジトリからコピーできます。

注意:

「ユーザー・エージェント」フィールドは、このデバイス・アセットが表す実デバイスを識別します。このフィールドは、優先順位が一番高い、一致するデバイス・グループにこのデバイスを関連付けするために、デバイス検出ロジックで使用します。

d. 「ユーザー・エージェントのテスト」をクリックしてデバイス検出を実行し、このデバイスが特定のデバイス・グループに一致していることを確認します。

e. このデバイス・アセットをデバイス検出メカニズムでデバイス・グループに関連付けることができるように、「有効化」オプションを選択します。

f. 「デバイス・イメージ」フィールドの隣にある「参照」をクリックして、イメージの保存先ディレクトリからデバイス・イメージを選択します。

g. (オプション)。「サムネイル・イメージ」フィールドの横で、Contributorインタフェースのプレビュー機能に関連付けられているデバイス・セレクタ・パネルに表示するサムネイル・イメージをアップロードします。サムネイルを選択すると、デバイス・イメージのページ・プレビューが表示されます。

4. 「画面ディメンション」タブで、「高さ」、「幅」、「上」および「左」の各フィールドに必要なピクセルを入力し、「ピクセル率」フィールドにピクセル率を入力して、画面領域の適切なディメンションを決定します。
各フィールドにピクセルを入力すると、デバイス・イメージの画面領域もそれに応じてリセットされ始めます。この機能により、デバイス表示領域の正確なディメンションをその場で決定できます。

図26-14 「画面ディメンション」タブ

5. フォーム上の「保存」アイコンをクリックして、新しいデバイスを作成します。
成功メッセージが表示されます。

26.4.7 サイト・ナビゲーションの作成方法

複数のサイト・ナビゲーションと単一のサイト・ナビゲーションのどちらが必要かは、設計方法により異なります。サイト・ナビゲーションを作成している場合、共通の接尾辞を選択することによって、デバイス・グループをこのナビゲーションに関連付けます。選択した接尾辞は、他のサイト・ナビゲーションで使用できなくなります。

サイト・ナビゲーションを作成するには:

1. Adminインタフェースで「一般的な管理」ツリーを開き、「管理」ノード、「サイト」ノード、およびサイト・ナビゲーションの作成場所であるサイトの順に開きます。

2. 「サイト・ナビゲーション」ノードを開きます。

3. 「新規追加」(図26-15 )をダブルクリックします。

図26-15 「管理」タブの「サイト・ナビゲーション」ノード

「サイト・ナビゲーションの追加」フォームが開きます。

4. 「名前」フィールドに、サイト・ナビゲーションのわかりやすい名前を入力します。

5. (オプション)「説明」フィールドに、サイト・ナビゲーションの説明を入力します。

6. デバイス・グループをこのサイト・ナビゲーションに関連付けるには、「接尾辞」セクションに移動して、これらのデバイス・グループによって使用される接尾辞を選択します。

注意:

「接尾辞」セクションには、サイト・ナビゲーションに割り当てられていない接尾辞のみがリストされます。

「関連付けられたデバイス・グループ」パネル(図26-16)に、選択した接尾辞に関連付けられているデバイス・グループがリストされます。

図26-16 「関連付けられたデバイス・グループ」パネル

7. サイト・ナビゲーションにわかりやすい名前のアイコンを追加し、ウェブ・モードまたはフォーム・モードで開いているページがこのサイト・ナビゲーションに属するかどうかをコンテンツ・コントリビュータが識別しやすくします。この機能は、複数のサイト・ナビゲーションを操作する場合に非常に役に立ちます。アイコンを追加するには、「アイコン」フィールドの横で、「参照」をクリックし、アイコンが配置されているディレクトリに移動します。推奨されるアイコン・イメージのサイズは16ピクセル * 16ピクセルです。

Contributorインタフェースでは、このアイコンは、Webモードまたはフォーム・モードで開かれたときに、サイト・ナビゲーションの左側およびページの左側に表示されます。図26-17 に示す例を参照してください。

図26-17 「ナビゲーション」アイコン

8. 「追加」をクリックして、サイト・ナビゲーションを完了します。

図26-18のようなページが開きます。

図26-18 作成された新しいサイト・ナビゲーション

9. 「サイト・ナビゲーション」タブをクリックして、新しく作成されたサイト・ナビゲーションを表示します。

サイト・ナビゲーションを修正するには、「管理」タブ上のサイト・ノードの下にあるサイト・ナビゲーションをダブルクリックします。「サイト・ナビゲーションの変更」ページで、変更を行ってから、「修正」をクリックします。

26.4.8 サイト・ナビゲーションの編成方法

AdminおよびContributorインタフェースでサイト・ナビゲーションを特定の順序で表示するには、これらを並べ替えます。

サイト・ナビゲーションを編成するには:

1. Adminインタフェースの「一般的な管理」ツリーの下で、「管理」ノード、「サイト」ノード、およびサイト・ナビゲーションを優先順位を付ける場所であるサイトの順に開きます。

注意:

SiteAdminロールが割り当てられている場合は、かわりに「サイト管理者」タブを使用します。

2. 「サイト・ナビゲーション」の下で、「サイト・ナビゲーションの並替え」をダブルクリックします。

図26-19 サイト・ナビゲーションの並替え

3. 「サイト・ナビゲーションの並替え」ページ(図26-20)で、サイト・ナビゲーションをドラッグ・アンド・ドロップして、希望の順序に並べ替えます。

図26-20 サイト・ナビゲーションのドラッグ・アンド・ドロップ

サイト・ナビゲーションを並べ替えたら、「サイト・ナビゲーションの並替え」ページが図26-21のように表示されます。

図26-21 並べ替えられたサイト・ナビゲーション

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

「修正に成功しました。」メッセージが表示されます。

26.5 配信システムへのデバイス・リポジトリのミラー・パブリッシュ

モバイル・サイトのインフラストラクチャを構成した後、デバイス・リポジトリを配信システムにミラー・パブリッシュする必要があります。

注意:
デバイス・リポジトリを変更およびミラーリングした後は、必ずしも値を変更せずに、編集および保存を目的としてデバイス・グループを開くことにより、ターゲット・システム上のデバイス・グループへのデバイスの再関連付けをトリガーできます。

WURFLデバイス・リポジトリをミラー・パブリッシュするには:

1. 「モビリティ」ノードの下で、「デバイス・グループ」ノードをダブルクリックします。

2. デバイス・アップローダ画面の「WURFL」の下で、「単一Zipのアップロード」オプションを選択し、wurfl.zipファイルをアップロードします。

3. 「保存」アイコンの横にある「ミラー」アイコンをクリックします。

使用可能な宛先オプションが表示されます。

起動し稼働している宛先は「緑」アイコンで、現在稼働していない宛先は「赤」アイコンです。宛先のアイコンが「赤」である場合、チェック・ボックスは無効です。

4. 目的のアセット・オプションのチェック・ボックスを選択します。

注意:

次の手順を実行する前に、宛先マシンでWURFL.jarがすでに使用可能であることを確認します。WURFL.jarのコピーを配信システムに配置せずにWURFLデバイス・リポジトリをミラーリングすると、デバイス・グループが正常に機能しなくなります。

5. 「ミラー」をクリックします。

選択したデバイス・リポジトリが選択した宛先にミラーリングされます。成功メッセージが表示されます。

リポジトリがミラーリングされた後、選択した宛先のインジケータが緑になります。

26.6 テンプレートの作成

モバイルWebサイトをレンダリングするテンプレートを作成するには、次の2つの基本的な方法があります。

- すべてのモバイル・デバイス(つまり、すべてのデバイス・グループ)に適応する単一セットのテンプレートを作成します。

- 異なるデバイス・グループ用に異なるテンプレートを作成します。このシナリオには接尾辞を使用する必要があります。この項では、この2番目の方法について説明します。

この項には次のトピックが含まれます:

- テンプレート・バリアントを作成するための基本ガイドライン

- Mobilityタグの理解

- デバイス検出とページ・レンダリングをサポートするために変更されるタグ

- テンプレート・バリアントの作成

26.6.1 テンプレート・バリアントを作成するための基本ガイドライン

異なるデバイス・グループ用の異なるテンプレートを作成する際には、次の要件に注意してください。

1. 基本テンプレート(デスクトップWebサイトをレンダリングするテンプレート)を作成します。

2. 基本テンプレートの名前を使用し、_suffixを追加して、テンプレート・バリアントを作成します。

3. テンプレートに基づいてページをキャッシュする場合は、キャッシュ基準の1つとして接尾辞(dパラメータ)を使用します。

26.6.2 Mobilityタグの理解

表26-1では、テンプレートの作成時に使用するMobilityのタグについて説明しています。このタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

表26-1 Mobilityのタグ

タグ

説明

<device:load name="<Name of Current Device>" />

現在のデバイスを検出して、デバイス情報をロードします。asset:loadと同様。

<device:get name="<Name of Current Device>" property="useragent|devicegroup|suffix" [output="propName"] />

このタグは、ロードされたデバイスに対してuseragent、devicegroupまたはsuffixプロパティのいずれかの値を返します。オプション属性outputが指定されている場合、プロパティの値をoutput変数に設定します。output属性がない場合、プロパティの値を、そのプロパティの名前を持つ変数に設定します。

<device:if name="<Name of Current Device>" property="touch" value="true" [datatype="boolean"] [operator="equals"] > ... conditional code for touch devices only ... </device:if>

このタグでは、現在ロードされているデバイスに対して特定の条件や、その条件が満たされると実行されるコードを指定できます。オプション属性datatypeのデフォルト値はStringで、オプション属性operatorのデフォルト値は"="です。

<device:hascapability name="<Name of the Device Loaded Earlier>" capability="<WURFL_CAPABILITY_NAME>" > conditional code </device:hascapabiilty>

このタグは、現在ロードされているデバイスが、このタグで指定された機能をサポートしているかどうかをチェックします。タグ内のコードが実行されるのは、デバイスがこの機能をサポートしている場合です。

<device:capability name="<Name of the Device Loaded Earlier>" capability="<WURFL_CAPABILITY_NAME>" output="capabilityValue" />

このタグは、現在ロードされているデバイスに対して、icsスコープ内の指定された機能の値を設定します。

<device:siteplan output=<NAME_OF_VARIABLE_HOLDING_RESULTING_SITEPLAN_ID> [pubid = <%=ics.GetVar("pubid")%>] [site=<%=ics.GetVar("site")%>] [d= <%=ics.GetVar("d")%>] />

device:siteplanタグを使用して、デバイスのサイト・ナビゲーションを検索します。タグは、デバイス・グループの接尾辞である、dパラメータをとります。

実行時に、WebCenter Sitesではデバイス検出を使用して、dパラメータの値を計算します。タグは、dパラメータ(つまり、接尾辞)の値を使用して、同じ接尾辞を持つサイト・ナビゲーションを検索し、そのサイト・ナビゲーションのIDを返します。サイト・ナビゲーションIDは、Webサイト・ナビゲーションを構築するために他のタグによって使用されます。

26.6.3 デバイス検出とページ・レンダリングをサポートするために変更されるタグ

次のタグには、Mobility固有の属性が含まれます。

- render:getpageurl

- render:calltemplate

- render:gettemplateurl

- render:gettemplateurlparameters

- insite:calltemplate

- satellite:page

- satellite:link

属性は次のとおりです。

- d: デバイス・グループの接尾辞。

- resolvetemplatefordevice: テンプレート名にデバイス・グループ接尾辞を追加します。デフォルト値はtrue。値がfalseに設定される場合、接尾辞がテンプレート名に追加されず、基本テンプレートがロードされます。

dパラメータは、前述の各タグからなるチェーンで、自動的に下流に伝達されます。タグは、渡されたd属性に基づいて、適切なテンプレート・バリアントをコールします。

avisportsサンプル・サイトの次の例で、c=PageおよびTestSiteは現在のサイトです。

<render:calltemplate tname='Detail' args="c,cid,p,d,locale,form-to-render" />
(i) for d=Desktop (default) or blank, the following template is called:
TestSite/Page/Detail
(ii) for d=Touch, the following template is called:
TestSite/Page/Detail_Touch

d属性の使用方法の詳細は、「デバイス検出の仕組み」を参照してください。

26.6.4 テンプレート・バリアントの作成

テンプレート・バリアントを作成するには、接頭辞をコピー、変更、および基本テンプレートに追加します。この接頭辞機能を使用して、バリアントが存在しない接頭辞に対して単一のテンプレート・バリアントの作成とテンプレート・バリアントのバルク作成の両方を行うことができます。

この項には次のトピックが含まれます:

- 単一のテンプレートのバリアントの作成方法

- テンプレート・バリアントのバルク作成方法

注意:

接頭辞ベースの検索を使用すると、特定の接頭辞のテンプレートを簡単に検索できます。つまり、メニュー・バーの「検索」をクリックし、「検索」表からテンプレートの検索を選択します。「検索対象: テンプレート」画面で、「検索」ドロップダウン・リストから「接尾辞」を選択し、「検索文字列」ドロップダウン・リストから目的の接頭辞を選択します。検索結果には、非アクティブ化されたテンプレートまたは削除されたテンプレートも含まれます。(これらのタイプをサイトから削除し、検索結果に再表示されないようにしてください。)

26.6.4.1 単一のテンプレートのバリアントの作成方法

テンプレート・バリアントを作成するには:

1. テンプレートのバリアントがすでに存在するかどうかを確認します。テンプレートの「調査」モードの「テンプレート・バリアント」セクションに移動します。

図26-22に示すように、特定の接頭辞に対してテンプレート・バリアントが存在する場合は「アクション」列の下に「表示」列が表示され、それ以外の場合は「作成」リンクが表示されます。

図26-22 テンプレート・バリアント

2. テンプレートのバリアントを作成するには、「作成」リンクをクリックします。

図26-23に示すように、テンプレート・フォームが表示されます。

図26-23 テンプレート・フォーム

3. 「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」の「テンプレート・アセットの名前付けと記述」を実行します。

26.6.4.2 テンプレート・バリアントのバルク作成方法

複数のテンプレートのテンプレート・バリアントを作成するには:

1. デバイス・タブで、「テンプレート」を開き、「一括コピー・テンプレート」をダブルクリックします。

2. 「一括コピー・テンプレート」ページで、「接尾辞」ドロップダウン・リストから必要な接頭辞を選択します。

3. 「アセット・タイプ」ボックスで、テンプレートをコピーするアセットを選択します。

これにより、関連する基本テンプレートが「使用可能な基本テンプレート(n)」ボックスに表示されます。

4. コピーするテンプレートを選択します。必要に応じて、「使用可能な基本テンプレート」ボックスに表示されているテンプレートを1つ、複数またはすべて選択します。

「選択された基本テンプレート」ボックスに、選択したテンプレートが移入されます。

図26-24 一括コピー・テンプレート

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

「テンプレートは正常に生成されました: <name>」メッセージが表示されます。

26.7 モバイルWebサイトのイメージの最適化

Mobilityには、モバイルWebサイトのイメージを最適化できるイメージ最適化フィルタが用意されています。また、独自のイメージ最適化実装をプラグインし、イメージをカスタム手法で最適化することもできます。次の各項では、これら両方の方法について説明します。

- イメージ最適化フィルタを使用したイメージの最適化方法

- プラガブル・インタフェースを使用したイメージの最適化方法

26.7.1 イメージ最適化フィルタを使用したイメージの最適化方法

WebCenter Sitesのイメージ最適化機能は、フレックス・アセット・ファミリに対して使用できます。フルサイズのイメージを最適化し、様々なタイプのモバイル・デバイスで適切に表示できます。この機能を使用すると、様々な接頭辞に対してイメージを最適化し、様々な画面ディメンションをサポートできます。たとえば、一部のデバイスでは、表示されるイメージはフルサイズのイメージの50%にする必要がありますが、他のデバイスでは、実際のサイズの50%より小さく表示する必要があります。

イメージ最適化フィルタを使用してイメージを最適化するには:

- ImageOptimizationFilterタイプのフレックス・フィルタの作成

- サイトのイメージ定義へのフィルタの追加

- blobタイプ属性アセットのインスタンスの作成

- 最適化用のイメージ・プロパティの設定

- 既存のイメージへのイメージ最適化フィルタの適用

- イメージ最適化フィルタが適用されているかどうかの確認

- サイトでの最適化されたイメージの使用

26.7.1.1 ImageOptimizationFilterタイプのフレックス・フィルタの作成

1. メニュー・バーの「新規」をクリックします。

2. オプションのリストから、「新規フィルタ」をクリックします。

「新規フィルタ」フォームが表示されます。

3. 「名前」フィールドで、新しいフィルタの名前を入力します。

4. dropdown list, choose ImageOptimizationFilter, then click Get Arguments.

図26-25 ImageOptimizationFilter

5. 「引数」セクションの下で、「値」フィールドに、サイトの既存のblobタイプ属性アセットの名前を入力します。たとえば、avisportsサンプル・サイトの場合、このアセットはimageFileで、フレックス・ファミリはcontentです。この値を適用するには、「追加」をクリックします。

6. 「保存」アイコンをクリックします。

26.7.1.2 サイトのイメージ定義へのフィルタの追加

手順1で作成したフィルタをサイトのイメージ定義に追加するには、次の手順を実行します(たとえば、avisportsサンプル・サイトで、Image定義を検索できます)。

1. 編集するためにImage定義を開きます。

2. 「属性」セクションの「使用可能」の下で、フレックス・ファミリを選択し、「必須」をクリックします。avisportsの場合、フレックス・ファミリはすでに選択されています。

3. 「フィルタ」セクションの「使用可能」の下で、前の手順で作成したイメージ最適化フィルタ(この例ではmyImageOptimizationFilter)を選択し、「選択」をクリックします。

図26-26 イメージ定義

4. 「保存」アイコンをクリックします。

26.7.1.3 blobタイプ属性アセットのインスタンスの作成

WebCenter Sitesでは、単一値と複数値の両方のblobタイプ属性がサポートされています。すべてのテンプレート・バリアントにイメージ最適化フィルタを適用するには、サイトの接頭辞の数と同じ数のblobタイプ属性アセットのインスタンスを作成します。たとえば、avisportsサンプル・サイトでは、既存のblobタイプ属性はimageFileです。このため、この場合、Touch接頭辞に対してこの属性アセットのインスタンスを作成し、NonTouch接頭辞に対して別のインスタンスを作成します。

1. メニュー・バーの「新規」をクリックします。

2. オプションのリストから、「新規属性」をクリックします。

「新規属性」フォームが表示されます。

3. 「名前」フィールドで、フォーマット<blob_attribute_name>_<Suffix>で名前を入力します。このため、avisportsサイトの場合は、imageFile_TouchおよびimageFile_NonTouchになります。

4. 「属性タイプ」ドロップダウン・リストから、「BLOB」を選択します。

5. 「保存」アイコンをクリックします。

26.7.1.4 最適化用のイメージ・プロパティの設定

1. 「モビリティ」タブの下で、「イメージのプロパティ」ノードをダブルクリックします。

2. 必要な接頭辞については、次のプロパティを設定します。

- preferredFormats: オプションのプロパティ。様々なタイプのイメージ・フォーマット。たとえば、avisportsサイトの場合、Touch接頭辞とNonTouch接頭辞の両方で、フォーマットはjpg、png、bmp、gifです。様々なフォーマットを使用する目的は、最も小さいイメージを得ることです。フォーマットは、優先順位の順に提供されます。最初のフォーマットであるjpgにより、最適化されたイメージを実現できる場合、このフォーマットが使用されます。それ以外の場合、次の優先順位のフォーマットが使用されます。必要なサイズを実現する上でサポートされているフォーマットが1つも役に立たない可能性がある場合は、デバイス上でフルサイズのイメージがレンダリングされます。
省略すると、最適化されたイメージのフォーマットは元/フルサイズのイメージと同じになります。

- targetSize: デバイス上のイメージの平均サイズ。これはパーセンテージである必要があります。たとえば、フルサイズのイメージの40%などです。

- maxsize: デバイス上のイメージの最大サイズ。これはパーセンテージである必要があります。たとえば、フルサイズのイメージの50%などです。最適化されたイメージがmaxsizeを超える場合、レンディションとして格納されません。最適化されたイメージのサイズ(バイト単位)がmaxSizeを超える場合、メイン・イメージが使用されます。

26.7.1.5 既存のイメージへのイメージ最適化フィルタの適用

イメージを作成または編集する場合は、イメージ最適化フィルタが機能します。このため、このフィルタを既存のイメージに適用するには、これらのイメージを編集して保存する必要があります。

1. イメージを編集モードで開きます。

2. 「保存」アイコンをクリックし、フィルタを適用します。

26.7.1.6 イメージ最適化フィルタが適用されているかどうかの確認

1. Contributorインタフェースを開きます。

2. イメージを検索して開きます。

イメージの「コンテンツ」タブには、各接頭辞のサムネイルが含まれます。図26-27に、フルサイズのイメージ(デフォルトのサイト用)用、Touch接頭辞用、およびNonTouch接頭辞用の3つのサムネイルが表示されたサンプル・イメージの「コンテンツ」タブを示します。

図26-27 サンプル・イメージのコンテンツ

3. 各接頭辞の最適化されたイメージを表示するには、「URL」タブ(図26-28)上で使用可能な各URLをクリックします。

図26-28 サンプル・イメージのURL

26.7.1.7 サイトでの最適化されたイメージの使用

1. render:getbloburlタグのoptimize属性をtrueに設定します(<render:getbloburl c=... cid=.. optimize='true' /)。このタグの詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

26.7.2 プラガブル・インタフェースを使用したイメージの最適化方法

モバイルWebサイトのイメージを最適化するには、次のように、イメージ最適化API ImageOptimizer.javaのカスタム実装をプラグインします。

1. 抽象クラスImageOptimizer.javaを拡張するクラスを作成します。たとえば、WebCenter Sitesに含まれるImagePercentScaler.javaクラスのデフォルトの実装com.fatwire.mobility.image.impl.ImagePercentScalerを参照してください。

2. 必要に応じて、抽象クラスTargetImageProperties.javaを拡張するクラスを作成します。たとえば、WebCenter Sitesに含まれるDefaultTargetImageProperties.javaクラスのデフォルトの実装com.fatwire.mobility.image.impl.DefaultTargetImagePropertiesを参照してください。または、デフォルトの実装で許可されているプロパティ以外のプロパティが使用されない場合、既存のデフォルトの実装クラス自体を再使用します。

注意:

デフォルトのターゲット・プロパティを使用する場合、手順3に示すXMLスニペットの最初の行を変更しないでください。

3. <WebCenter Sites_HOME>/config/にあるMobilityService.xml構成ファイル内で、属性クラスの値をTargetImageProperties.javaおよびImageOptimizer.java抽象クラスの各実装(COM.FutureTense.Mobility.Image.TargetImagePropertiesおよびCOM.FutureTense.Mobility.Image.ImageOptimizer)に置き換えます。

<bean id="TargetImageProperties" class="com.fatwire.mobility.image.impl.DefaultTargetImageProperties" singleton="false"/>
<bean id="ImageOptimizationService" class="com.fatwire.mobility.image.impl.ImagePercentScaler" singleton="true" >
<constructor-arg ref="TargetImageProperties"/>
</bean>

これで、実装の使用を開始できます。同様の実装については、次のコードを参照してください。

ImageOptimizer srv = ServiceLocator.getService( "ImageOptimizationService", ImageOptimizer.class );
TargetImageProperties targetImageProperties = srv.getTargetImageProperties();
targetImageProperties.putAll( customPropertnValues );
//'customPropertnValues' is a map that contains custom property names and values as required by userimplementation ofimageoptimization API

26.8 デバイス検出の仕組み

WebCenter Sitesは、組込みのデバイス検出メカニズムを使用して、Webサイトのコンテンツを要求するデバイスを識別します。デバイスが特定されると、WebCenter Sitesは一致するデバイス・グループを検索して、その接尾辞を読み取ります。接尾辞を使用して、サイト・ナビゲーションを見つけ、テンプレート・バリアントを呼び出してそのコンテンツをレンダリングします。

詳細な手順は次のとおりです。

1. リモートSatellite Serverは、実デバイスからページ・リクエストを受信します。このリクエストのヘッダーには、デバイスのユーザー・エージェントが含まれます。

2. リモートSatellite Serverは独自のキャッシュ内でそのページを検索します。ページの検索に失敗すると、リモートSatellite ServerはWebCenter Sitesにページ・リクエストを送信します。

3. WebCenter Sitesは次のように応答します。

a. リクエスト・ヘッダーのユーザー・エージェントによってデバイスを識別します。

b. デバイス・リポジトリでユーザー・エージェントを検索します。

c. デバイス・リポジトリで一致するデバイスを見つけると、WebCenter Sitesはそのデバイスの機能も検索します。

d. WebCenter Sitesはユーザー・エージェント機能とデバイス機能を使用して、基準に合ったデバイス・グループを検索します。

e. そのデバイスを優先順位の一番高いデバイス・グループに関連付けます。

f. このデバイス・グループの接尾辞を読み取ります。

g. その接尾辞をicsスコープ内のdパラメータに割り当てます。

h. _suffixをURLで要求されたテンプレート名に追加します。

i. d=suffixを要求されたページのURLに追加します。
次に例を示します。

接尾辞がTouchの場合、WebCenter Sitesでは、元のURL pagename=avisports/HomeLayout1&c=Page&cid=1482760932をURL pagename=avisports/HomeLayout1_Touch&c=Page&cid=1482760932&d=Touch に変換します

j. テンプレート・バリアントが存在する場合、WebCenter Sitesは新しいURLを実行してそのページをキャッシュし、それをリモートSatellite Serverに送信します。
テンプレート・バリアントが存在しない場合、WebCenter Sitesは元のURLを実行してそのページをキャッシュし、それをリモートSatellite Serverに送信します。

4. リモートSatellite Serverはそのページをキャッシュして、デバイスにレスポンスを送信します。

5. リモートSatellite Serverは、デバイス検出情報もキャッシュして、それを同じデバイスからの後続のリクエストを処理するために使用します。これにより、WebCenter Sitesでのデバイス検出の再実行が回避されます。

第V部 Developer Toolsを使用したコーディング

この部では、DeveloperToolsについて説明します。このツールキットは、Oracle WebCenter SitesとEclipse統合開発環境(IDE)を統合するために使用します。Developer Toolsキットを使用すると、開発者は、Eclipse IDEとバージョン・コントロール・システム(VCS)を使用して分散環境で作業できるようになります。

この部は、次の章で構成されています。

- Developer Toolsについて

- Developer Toolsのインストールおよび構成

- EclipseのDeveloper Tools機能の概要

- Developer Toolsを使用したJSPの開発

- Developer Toolsを使用したモバイルWebサイト用テンプレートの作成

- Developer Toolsを使用した同期および交換

- Developer Toolsのワークスペースの使用

- Developer Toolsコマンドライン・ツールの使用

- Developer Toolのワークスペースとバージョン・コントロール・システムとの統合

- Developer Toolsを使用したリソースの管理および交換

- Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成

27 Developer Toolsについて

Oracle Developer Toolsでは、WebCenter SitesとEclipse IDEを統合して、個人用の柔軟な開発環境を作成できます。

Developer Toolsについては、次の項を参照してください。

- Developer Toolsアーキテクチャの概要

- IDE統合

- Developer Toolsワークスペース

- WebCenter Sitesインスタンスへの接続

- 同期

- JSPの管理

- コマンドライン・ツール

- バージョン・コントロール・システムの使用について

27.1 Developer Toolsアーキテクチャの概要

Developer Toolsを実行している任意のコンピュータ(ローカルまたはリモート)を使用すると、WebCenter SitesとEclipse IDEを統合して、個人用の柔軟な開発者環境を作成できます。開発者は、主にEclipseを通じてDeveloper Toolsと対話し(結果的に、WebCenter Sitesと対話することになります)、Eclipseには、WebCenter Sitesのリソースを管理するための機能が豊富に備わっています。　EclipseとWebCenter Sitesのどちらで管理しているリソースでも、Developer Toolsキットを使用して自動または手動で同期できます。

たとえば、Eclipseで管理されるリソースはファイル・システムのファイルとして格納されるため、開発者は、任意のバージョン・コントロール・システムと統合するというオプションを選択できます。リソースが変更されたときに、WebCenter Sitesを実行していると、リソースは自動的に同期され、WebCenter Sitesにデータベースのネイティブ表現形式でリソースがインポートされます。手動の同期は、双方向に実行できます。

この図は、Developer Toolsの概要を示しています。

図27-1 Developer Toolsプロセスのフロー

27.2 IDE統合

Eclipse統合を使用すると、開発者は次の作業を行えます。

- CSElementアセット、テンプレート・アセット、Controllerアセット、SiteEntryアセットと、SiteCatalogエントリおよびElementCatalogエントリの作成、編集、および削除。

- タグの補完、構文の強調表示、デバッグなどのEclipseの標準機能を使用したJSPエレメントの開発

- アセット、アセット・タイプ、フレックス・ファミリ、サイト、ロール、ツリー・タブ、およびスタート・メニュー・アイテムのエクスポートとインポート

- 埋込みのプレビュー・ブラウザを使用した、Eclipse IDEでのWebCenter Sitesのページのプレビュー。

- 動的にリフレッシュされるパネルでのWebCenter Sitesログ・ファイルの表示。

- バージョン・コントロール・システムとの統合

注意:

Developer ToolsをEclipseと統合すると、EclipseにAdminインタフェースとOracle WebCenter Sites: Contributorインタフェースが埋め込まれるため、開発者は簡単にアクセスできるようになります。Adminインタフェースは、このガイドの多くの部分で使用されます(例: フレックス・ファミリを作成する場合)。Contributorインタフェースの使用方法の詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

27.3 Developer Toolsワークスペース

Eclipseで管理するWebCenter Sitesのリソースは、メインDeveloper Toolsワークスペースと呼ばれるファイル・システム構造のファイルとして格納されます。この構造により、WebCenter Sitesのインスタンスでのリソースの管理および交換が簡単になります。メインDeveloper Toolsワークスペースは、Eclipseからアクセスできる唯一のワークスペースです。

注意:

カスタム・ワークスペースの作成はオプションです。ほとんどの分散環境では、メインDeveloper Toolsワークスペースのみで十分です。カスタム・ワークスペースは、Eclipseからはアクセスできません。カスタム・ワークスペースの作成方法は、「Developer Toolsのワークスペースの使用」を参照してください。このガイドのその他のDeveloper Toolsに関するトピックでは、メインDeveloper Toolsワークスペースについて説明します。

27.4 WebCenter Sitesインスタンスへの接続

Developer Toolsでは、ローカルまたなリモートの任意のWebCenter Sitesインスタンスに接続できます。Eclipseと統合する各WebCenter SitesインスタンスにはEclipseプロジェクトが割り当てられ、各プロジェクトはメインDeveloper Toolsワークスペースに表示されます。Eclipseプロジェクトでは、そのWebCenter Sitesインスタンスに格納されているWebCenter Sitesリソースを追跡します。

必要に応じて、任意の数のWebCenter Sitesインスタンスに(ローカルまたはリモートで)接続可能で、接続先のインスタンスごとにEclipseプロジェクト・フォルダが作成されます。Eclipseプロジェクトの詳細は、「Eclipseのプロジェクトとワークスペースの理解」を参照してください。

27.5 同期

Developer Toolsキットを使用すると、EclipseのリソースとWebCenter Sitesのリソースの同期が可能になり、Developer ToolsワークスペースとWebCenter Sitesデータベースには、同一のコンテンツが格納されるようになります。手動の同期は双方向で、WebCenter Sitesデータベースにリソースをインポートすることも、Developer Toolsワークスペースにリソースをエクスポートすることもできます。

Eclipseにリソースをエクスポートすると、そのリソースはファイルに変換されます。WebCenter Sitesにリソースをインポートすると、そのリソースはWebCenter Sitesのネイティブ形式(データベース表現)に変換されます。

注意:

自動同期は、WebCenter SitesのリソースがEclipseで編集、作成、または削除されたときに行われますが、WebCenter Sitesのインスタンスが実行中の場合にかぎられます。この同期には、WebCenter Sitesのページ・キャッシュおよび結果セット・キャッシュの透過的なフラッシュ操作も含まれます。

27.6 JSPの管理

Developer Toolsキットは、WebCenter SitesのJSPを個別のファイルとしてDeveloper Toolsワークスペースに公開します。開発者は、これらのJSPを、その他のJSPファイルと同じように管理(作成、編集、およびデバッグ)できます。

27.7 コマンドライン・ツール

Developer Toolsキットのコマンドライン・ユーティリティを使用すると、インポートおよびエクスポートのタスクの自動化、大規模なリソースの移動、カスタム・ワークスペースの作成、任意のワークスペースとのリソースの同期などが可能になります(これは、メインDeveloper Toolsワークスペースに格納されたリソースに対してのみ作業できるEclipse統合とは異なります)。

27.8 バージョン・コントロール・システムの使用について

Developer Toolsキットは、バージョン・コントロール・システムの実装をサポートしています。ワークスペースからバージョン・コントロール・システムにリソースをチェックインすると、WebCenter Sitesのインスタンスと開発者間でリソースを交換できるようになります。また、他の開発者がバージョン・コントロール・システムにチェックインしたリソースでワークスペースを更新することもできます。バージョン・コントロール・システムを使用すると、テスト用サーバー、管理WebCenter Sitesシステム、他の開発者のWebCenter Sitesインスタンスなどのターゲット・システムにリソースをチェックアウトして、それらの機能(パブリッシュなど)を使用できるようになります。

図27-2 は、Developer Toolsとバージョン・コントロール・システムを併用する例を示しています。この例では、専用のWebCenter Sitesインスタンスを使用して、リソースを管理WebCenter Sitesインスタンスにパブリッシュしています。そのため、WebCenter Sitesに備わった承認/パブリッシュの機能を使用して、バージョン・コントロール・システムからチェックアウトしたリソースをパブリッシュできます。この例は、Developer Toolsとバージョン・コントロール・システムを併せて使用する場合に推奨される方法ですが、必須だというわけではありません。

図27-2 Developer Toolsとバージョン・コントロール・システムの使用

28 Developer Toolsのインストールと構成

EclipseでWebCenter Sitesリソースの管理を開始するには、マシンでDeveloper Toolsを設定して、WebCenter SitesのインスタンスとEclipseを統合します。

Developer Toolsのインストール、構成および更新、およびEclipseでのWebCenter Sitesリソースの管理の詳細は、次の項を参照してください。

- 前提条件

- Developer Toolsの設定

- Developer Toolsの更新

- EclipseでのWebCenter Sitesリソースの管理

- Developer Toolsのアンインストール

28.1 前提条件

Developer Toolsを設定する前に、次の点に注意してください。

- Eclipse IDEとの統合に必要なDeveloper Toolsプラグインと、コマンドライン・ツールの実行可能JARファイルは、どちらもWebCenter Sitesインストールの${Oracle Home}/wcsites/clientsディレクトリにあります。

- ローカルまたはリモートのどちらのWebCenter Sitesインスタンスに接続するかを決定します。

- EclipseとWebCenter Sitesの統合が完了すると、WebCenter Sitesへのログインには、一般管理者の資格証明(fwadmin/xceladminなど)が必要になります。このユーザーは、RestAdminグループに属している必要があります。

- コマンドライン・ツール機能を使用する手順:

- Developer Toolsでは、接続先のWebCenter SitesインスタンスのCAS内部URLへのアクセス権が必要です。CAS内部URLは、Oracle WebCenter Sitesのインストール中に指定されます。Developer Toolsでアクセスできるように、内部URLへのアクセスを公開する必要があります。
詳細は、『Oracle WebCenter Sitesのインストールと構成』を参照してください。

- Developer Toolsについての高度な知識が必要です。コマンドライン・ツールの実行および使用方法の詳細は、「Developer Toolsコマンドライン・ツールの使用」を参照してください。

28.2 Developer Toolsの設定

Developer Toolsを設定するには、Developer Toolsプラグインをインストールして、WebCenter Sitesと統合し、リモート・ホストでコード補完を有効にします。Developer Toolsを使用した既存のリソースの使用方法およびリソースの管理方法の知識が必要です。

- Developer Toolsプラグインのインストール方法

- Developer Toolsプラグインのインストールを確認する方法

- WebCenter SitesとEclipse IDEを統合する方法

- リモート・ホストでコード補完を有効にする方法

- Developer Toolsを使用して既存のリソースを操作する方法

- WebCenter Sitesリソースを管理する方法

- Eclipseで既存のプロジェクトを使用する方法

28.2.1 Developer Toolsプラグインのインストール方法

1. 開発の要件に適したEclipseパッケージをダウンロードします。WebCenter Sitesの開発には、Eclipse IDE for Java EE Developersが推奨されています。Eclipseは、次のURLからダウンロードしてください。

http://www.eclipse.org/downloads/

2. WebCenter Sitesのインストール・ディレクトリ(${Oracle Home}/wcsites/clients)のclientsフォルダを探します。このフォルダには、次のzipファイルが含まれます。

- com.oracle.sites.developer-tools-xyz.zip: Developer Toolsプラグイン。

- developer-tools-command-line.zip: コマンドライン・ツールのzipファイル(コマンドライン・ツールの実行可能JARファイルが含まれます)。

3. Eclipseを起動します(eclipse.exeを実行します)。

注意:

Eclipseは、ローカル・ファイル・システム(またはアーカイブ)の場所とリモートの場所からプラグインをインストールします。プラグインの場所は、ソフトウェア・サイトと呼ばれています。Developer Toolsプラグインの場合、ソフトウェア・サイトは、ファイル・システム上のDeveloper Toolsプラグインへのパスになります。

4. Eclipseのメニューから、「ヘルプ」を選択して、新規ソフトウェアのインストールを選択します。

インストール・ウィザードが開始され、使用可能なソフトウェアが表示されます。

5. 使用可能なソフトウェア・ページで、「追加」をクリックします(使用」フィールドの右側)。

6. リポジトリの追加ダイアログで、次のフィールドに入力して、「OK」をクリックします。

- 「Name」フィールドに、Developer Toolsプラグインの一意の名前を入力します。

- 「場所」フィールドで、「アーカイブ」をクリックして、clientフォルダにあるDeveloper Toolsプラグインの場所(ソフトウェア・サイト)を指定します。

インストール・ウィザードは、指定された場所(ソフトウェア・サイト)からDeveloper Toolsプラグインを選択して、使用可能なソフトウェアページにプラグインの名前をリストします。

7. 使用可能なソフトウェアページで、「Oracle WebCenter Sites Developer Tools」を選択して、「次」をクリックします(図28-1を参照)。

図28-1 インストール・ウィザード: Developer Toolsプラグインがリストされた使用可能なソフトウェア

「インストールの詳細」ページが開きます。

8. 「インストールの詳細」ページで、「終了」をクリックします(図28-2)。

図28-2 インストール・ウィザード: 「インストールの詳細」ウィンドウ

9. インストール・プロセス中に、「セキュリティ警告」ダイアログが開きます。「OK」をクリックして、イントールを続行してください。

10. インストールが正常に完了すると、「ソフトウェアの更新」ダイアログが開きます。

WebCenter Sitesが稼働していることを確認するには、${base_url}/HelloCSにアクセスします(${base_url}はWebCenter SitesインスタンスのベースURLです)。たとえば、ベースURLがhttp://example:8080/csの場合、http://example:8080/cs/HelloCSがWebCenter Sitesインスタンスの検証URLとなります。

11. 「ソフトウェアの更新」ダイアログで「はい」をクリックして、Eclipseを再起動します。

Eclipseを再起動すると、プラグイン・キャッシュがリフレッシュされ、EclipseでDeveloper Toolsプラグインが使用できるようになります。

28.2.2 Developer Toolsプラグインのインストールを確認する方法

1. Eclipseの再起動後に、Developer Toolsプラグインが正常にインストールされていることを検証します。Eclipseのメニューから、「ヘルプ」を選択して、Eclipseのバージョン情報を選択します。

Eclipseのバージョン情報ダイアログが開き、インストール済プラグインのリストにDeveloper Toolsアイコンが表示されます(図28-3)。

図28-3 Eclipseのバージョン情報ダイアログ

2. Eclipse IDEの右上にあるパースペクティブを開くアイコンをクリックして、「Oracle WebCenter Sites」パースペクティブを開きます。パースペクティブを開くダイアログで、「Oracle WebCenter Sites」を選択して(図28-4)、「OK」をクリックします。

図28-4 パースペクティブを開く: Oracle WebCenter Sites

28.2.3 WebCenter SitesとEclipse IDEを統合する方法

初めてDeveloper Toolsを設定する場合は、構成フォームが自動的に表示されます。

WebCenter Sitesインスタンスに接続しており、別のインスタンスに接続するには、「WebCenter Sites」ツールバーに移動して、プリファレンスの構成ウィザードをクリックして構成フォームを開きます。

WebCenter SitesとEclipse IDEを統合するには、次のように、接続先のWebCenter Sitesインスタンスの情報を構成フォームに入力します。

図28-5 構成フォーム

1. 「インスタンス」フィールドでは、ローカル・ホストとリモート・ホストのどちらに接続するかに応じて、次のいずれかの操作を実行します。

注意:

リモート接続では、同一のリモート・ホスト上で複数のプロジェクトの作成がサポートされます。ローカル接続では、同時にサポートされるプロジェクトは1つのみになります。

- ローカル・ホストに接続する場合は、「参照」をクリックして、config (WebCenter Sitesインスタンスのwcs_properties.jsonファイルを含む)の場所を選択します。

- リモート・ホスト(たとえば、http://example:8080/cs)に接続する場合は、ホストへのパスを[host]:[port]/[path]の書式で入力します。(http://またはhttps://を先頭に付ける必要があります。)

「インスタンス」フィールドに値を入力すると、次の各フィールドには自動的に値が入力されます。これらのフィールドの値は、「インスタンス」フィールドでローカル・ホストとリモート・ホストのどちらを指定したかに応じて異なります。

- Remote Connection: リモート・ホストに接続する場合、この値はtrueに設定されます。ローカル・ホストに接続する場合、この値はfalseに設定されます。

- Host IP Address: 接続するホストのIPアドレスを指定します。

- Port: 接続するホストのポート番号を指定します。

- Web Context Path: ホストへのコンテキスト・パスを指定します。

- Workspace: Developer Toolsワークスペース(Eclipseプロジェクト)の場所を指定します。

- Sites Context Root: ローカル・ホストに接続する場合、このフィールドには、WebCenter Sites Webアプリケーションのパスが含まれます。リモート・ホストに接続する場合、このフィールドは空欄になります。

2. 「プロジェクト名」フィールドに、作業するプロジェクトの名前を入力します。

3. 「ユーザー名」フィールドに、一般管理者のユーザー名を入力します。このユーザーは、RestAdminグループのメンバーである必要があります。

4. 「パスワード」フィールドに、ユーザー名のパスワードを入力します。

5. オンラインにするチェック・ボックスを選択して、サーバーにアクセスし、EclipseでWebCenter Sitesリソースを使用します。

6. 「接続のテスト」をクリックします。
ダイアログが開き、接続が成功したことが表示されます。

7. ダイアログ・ボックスで「OK」をクリックします。

8. 確認フォームで「OK」をクリックします。

「Oracle WebCenter Sites」パースペクティブが開きます。次の図に、「Oracle WebCenter Sites」パースペクティブの外観を示します(WebCenter Sitesが統合されたEclipseに初めてアクセスする場合)。

注意:

WebCenter Sitesリソースを使用する場合、「Oracle WebCenter Sites」パースペクティブを開く必要はありません。

図28-6 「Oracle WebCenter Sites」パースペクティブ

Oracleパースペクティブが、前述の図に示すようにレンダリングされた場合は、Developer Toolsの設定に成功しています。WebCenter SitesがEclipseと統合されている場合、WebCenter Sitesリソースを使用するのに、「Oracle WebCenter Sites」パースペクティブを開く必要はありません。

注意:

EclipseビューとDeveloper Toolsビューを格納しているパネルは、相互に交換できます。別のパネルにビューを移動するには、ビューのタブをクリックして、そのタブをパネルにドラッグします。

28.2.4 リモート・ホストでコード補完を有効にする方法

1. リモート・コンピュータからローカル・ファイル・システムにWEB-INFディレクトリをコピーします。EclipseとWebCenter Sitesを最初に統合したときに作成したワークスペース・フォルダにあるEclipseプロジェクト・フォルダにコピーすることをお薦めします。

2. Eclipseの「プロジェクト」ビューで、WEB-INFフォルダを右クリックし、「プロパティ」を選択します。
WEB-INFのプロパティ・ウィンドウが開きます。

図28-7 WEB-INFのプロパティ・ウィンドウ

3. 「場所」フィールドで、「編集」をクリックします。
リンクの場所の編集ウィンドウが開きます。

図28-8 リンクの場所の編集ウィンドウ

4. 「場所」フィールドで、「フォルダ」をクリックして、手順1でコピーしたWEB-INFフォルダの場所に移動します。その後、「OK」をクリックします。

5. WEB-INFのプロパティ・ウィンドウで、「OK」をクリックします。
これにより、Eclipseでのタグ補完と、構文の適切な強調表示が可能になります。詳細は、「タグおよびJava APIの補完」を参照してください。

注意:

ローカル・インスタンスの場合、コード補完は自動的に有効化されます。

28.2.5 Developer Toolsを使用して既存のリソースを操作する方法

WebCenter Sitesシステムをアップグレードしていて、このリリースより前に作成したリソース(既存のリソース)に対してDeveloper Toolsを使用する場合は、「既存のリソースとDeveloper Toolsの併用について把握すべき内容」を参照してください。

28.2.6 WebCenter Sitesリソースを管理する方法

「Oracle WebCenter Sites」パースペクティブでWebCenter Sitesリソースの管理をすぐに開始するには、「EclipseでのWebCenter Sitesリソースの管理」に進んでください。

28.2.7 Eclipseで既存のプロジェクトを使用する方法

EclipseをWebCenter Sitesインスタンスと統合する場合、ワークスペースの名前と場所を指定します。後でこのワークスペースにアクセスする場合は、最初にWebCenter SitesをEclipse IDEに統合したときに「構成」フォームで指定した資格証明を使用してログインする必要があります。そうしないと、オフラインで作業することになり、EclipseでWebCenter Sitesリソースにアクセスできません。

Eclipse IDEで既存のプロジェクトを使用する手順:

1. Eclipse IDEを開き、使用するWebCenter Sitesインスタンスに関連付けられているワークスペースを選択します。
Eclipseが開きますが、オフライン・モードで操作している状態です。

2. オンラインに切り替えてWebCenter Sitesインスタンスにアクセスするには、次のいずれかを実行します。

- Eclipseで任意のWebCenter Sitesコンポーネントを選択します。
例:

a. 「新規テンプレートの作成」アイコンをクリックします。
Errorダイアログが開き、現在のプロジェクトが現在オフラインである旨のメッセージが表示されます。

b. 「はい」をクリックします。
「資格証明」ダイアログが開きます。

c. 「資格証明」ダイアログで、接続先のWebCenter Sitesインスタンスのユーザー名とパスワードを入力して、オンラインにするをクリックします。

- 「構成」フォームを開き、次のように、接続先のWebCenter Sitesインスタンスの資格証明を入力します。

a. 「WebCenter Sites」ツールバーで、プリファレンスの構成アイコンをクリックします。
「構成」フォームが開きます。

b. 「構成」フォームで、資格証明を「ユーザー名」フィールドと「パスワード」フィールドに入力します。

c. オンラインにするチェック・ボックスを選択します。

図28-9 構成フォーム

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

オンライン状態になり、EclipseでWebCenter Sitesリソースを作成および管理できます。

28.3 Developer Toolsの更新

WebCenter Sitesインストールをアップグレードしたら、次の手順を実行します。

- Developer Toolsプラグインの場所を更新する方法

- 既存のプラグインの更新のチェック方法

- Developer Toolsプラグインが更新されていることを確認する方法

28.3.1 Developer Toolsプラグインの場所を更新する方法

1. 更新したDeveloper Toolsプラグイン(com.oracle.sites.developer-tools-xyz.zip)が{$Oracle Home}/wcsites/clientsディレクトリにあることを確認します。

注意:

Developer Toolsが最新バージョンであるかどうかを確認するには、zipファイルの名前に追加されているバージョン番号(xyz)を調べてください。

2. Eclipseを起動します(eclipse.exeを実行します)。

3. Eclipseのメニューから、「ヘルプ」を選択して、新規ソフトウェアのインストールを選択します。

使用可能なソフトウェア・ダイアログが開きます。

4. 使用可能なソフトウェア・ダイアログ・ボックスで、「追加」をクリックします。

5. リポジトリの追加ダイアログで、次のフィールドに入力して、「OK」をクリックします。

- 「名前」フィールドに、Developer Toolsプラグインの名前を入力します

- 「場所」フィールドで、「アーカイブ」をクリックして、更新したプラグインの場所を指定して、「OK」をクリックします(図28-10)。

図28-10 「リポジトリの追加」ダイアログ

6. 使用可能なソフトウェア・ダイアログ・ボックス(図28-11を参照)で、Developer Toolsプラグインの更新を選択して、「次」をクリックします。

図28-11 使用可能なソフトウェア: 更新したプラグインの選択

「インストールの詳細」ダイアログが開き、更新したプラグインが正常にインストールされたことが表示されます。

7. 「インストールの詳細」ダイアログで、「終了」をクリックします。

8. Eclipseを再起動して、変更を有効にします。

28.3.2 既存のプラグインの更新のチェック方法

1. Eclipseのメニューから、「ヘルプ」を選択して、「更新の確認」を選択します。

「使用可能な更新」ダイアログが開きます。

2. 「Oracle WebCenter Sites Developer Tools」を選択して、「Next」をクリックします。

更新の詳細ダイアログが開きます。

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

4. 更新プロセス中に、「セキュリティ警告」ダイアログが開きます。「OK」をクリックして、更新を続行してください。

5. 更新が正常に完了すると、「ソフトウェアの更新」ダイアログが開きます。次の手順に進む前に、ローカルのWebCenter Sitesインスタンスを開始し、「ソフトウェアの更新」ダイアログで「はい」をクリックして、Eclipseを再起動します。

28.3.3 Developer Toolsプラグインが更新されていることを確認する方法

Eclipseが再起動されたら、Developer Toolsプラグインが最新バージョンに正常に更新されていることを検証します。

1. Eclipseのメニューから、「ヘルプ」を選択して、Eclipseのバージョン情報を選択します。

Eclipseのバージョン情報ダイアログが開き、インストール済プラグインのリストにDeveloper Toolsアイコンが表示されます(図28-12)。

図28-12 Eclipseのバージョン情報ダイアログ

2. Eclipseのバージョン情報ダイアログで、Developer Toolsアイコンをクリックします。

Eclipse機能についてウィンドウが開き、Developer Toolsプラグインのバージョン詳細が表示されます(図28-13)。

図28-13 Eclipse機能についてウィンドウ

28.4 EclipseでのWebCenter Sitesリソースの管理

コード・ベースのWebCenter Sitesリソースの作成、編集、および他の方法による管理が可能です。

- テンプレート・アセット

- Controllerアセット

- SiteEntryアセット

- CSElementアセット

- ElementCatalogエントリ

- SiteCatalogエントリ

次の項では、Eclipseでリソースを管理するための手順の概要を示します。

- リソースの作成方法

- Developer Toolsビューをパネルに表示する方法

- WebCenter SitesとDeveloper Toolsの間でデータをエクスポートおよびインポートする方法

28.4.1 リソースの作成方法

1. ローカルのWebCenter Sitesを開始します。

2. Eclipseを起動します。

3. 「Oracle WebCenter Sites」パースペクティブを開きます。

Eclipseのメニューで、「ウィンドウ」→「パースペクティブ」→パースペクティブを開く→「その他」→「Oracle WebCenter Sites」を選択します。

4. 次のリソースのいずれかまたはすべてを作成します。

- テンプレート・アセットを作成するには、「新規テンプレートの作成」アイコンをクリックして、フォームに入力します。

- 新規Controllerアセットを作成するには、新規Controllerの作成アイコンをクリックして、フォームに入力します。

- 新規CSElementアセットを作成するには、新規エレメントの作成アイコンをクリックして、フォームに入力します。

- SiteEntryアセットを作成するには、新規サイト・エントリの作成アイコンをクリックして、フォームに入力します。

- ElementCatalogエントリを作成するには、新規エレメント・カタログ・エントリの作成アイコンをクリックして、フォームに入力します。

- SiteCatalogエントリを作成するには、新規SiteCatalogエントリの作成アイコンをクリックして、フォームに入力します。

フィールド定義、およびテンプレート・アセット、CSElementアセット、SiteEntryアセット、SiteCatalogエントリおよびElementCatalogエントリの詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。フィールド定義およびControllerアセットの詳細は、「コントローラの作成」を参照してください。

5. 「保存」をクリックすると、作成したリソースがWebCenter Sitesに自動的にインポートされます。

6. 作成、編集、削除または他のサイトと共有するリソースを管理するには、サイト・ワークスペース・エレメント・ビューを使用します。リソースを右クリックし、オプションを選択します。使用可能なオプションの詳細は、「ワークスペース」を参照してください。

28.4.2 Developer Toolsビューをパネルに表示する方法

1. ローカルのWebCenter Sitesを開始します。

2. Eclipseを起動します。

3. 「Oracle WebCenter Sites」パースペクティブを開きます。

Eclipseのメニューで、「ウィンドウ」→パースペクティブを開く→「その他」→「Oracle WebCenter Sites」を選択します。

4. 「Window」→「Show View」→「Other」の順に選択します。

5. 「ビューの表示」ダイアログで、ビュー(Oracle WebCenter Sitesフォルダ内にあるビュー)を選択します。

- サイトUIには、組込みのAdminインタフェースとOracle WebCenter Sites: Contributorインタフェースが表示されます。

- サイト・ログ・ビューには、WebCenter Sitesのログ・ファイルが表示されます。

- 開発者参照には、Oracle WebCenter Sitesタグ・リファレンスおよびOracle WebCenter Sites Java APIリファレンスが表示されます(タグ・リファレンスとJavadocを現在のWebCenter Sitesインスタンスに関連付けている場合のみ)。

- 「Sites Workspace Elements」では、コード関連のリソースにアクセスできます。このビューでは、ツリーにリソースが表示され、各リソースはサイト・アフィリエーションに従ってグループ化されます。

- 「ロギング構成」には、動的に更新されるログODL構成のビューが表示されます。このビューでは、各WebCenter Sitesログ出力のログ・レベルを設定できます。

- プレビュー・ブラウザには、組込みのプレビュー・ブラウザが表示されます。

- テンプレート・ビューには、Eclipsで作成されたすべてのテンプレート・アセットと、WebCenter SitesからEclipseにエクスポートしたテンプレート・アセットが表示されます。

Developer Toolsのビューの詳細は、「Developer Toolsのビューについて」を参照してください。

28.4.3 WebCenter SitesとDeveloper Toolsの間でデータをエクスポートおよびインポートする方法

1. ローカルのWebCenter Sitesを開始します。

2. Eclipseを起動します。

3. 「Oracle WebCenter Sites」パースペクティブを開きます。

Eclipseのメニューで、「ウィンドウ」→パースペクティブを開く→「その他」→「Oracle WebCenter Sites」を選択します。

4. SynchUpアイコンを選択します。同期ツールを使用すると、WebCenter SitesからDeveloper Toolsワークスペースにデータをエクスポートしたり、Developer ToolsワークスペースからWebCenter Sitesにデータをインポートできます。

- 同期ツールの使用方法の概要は、「データ同期(エクスポート/インポート)ツール」を参照してください。

- リソースの同期の詳細は、「Developer Toolsを使用した同期および交換」を参照してください。

28.5 Developer Toolsのアンインストール

この項では、Developer Toolsをアンインストールする手順について説明します。

Developer Toolsをアンインストールする手順は次のとおりです。:

1. 「Oracle WebCenter Sites」パースペクティブを閉じます(「Oracle WebCenter Sites」パースペクティブに関連付けられたすべてのビューも同時に閉じます)。

2. Eclipseのメニューから、「ウィンドウ」を選択して、「プリファレンス」を選択します。

「プリファレンス」ダイアログが開きます。

3. 「インストール/更新」を選択して、アンインストールまたは更新リンクをクリックします(図28-14)。

図28-14 プリファレンス: アンインストールまたは更新

4. Eclipseインストールの詳細ページで、Developer Toolsプラグインを選択して、「アンインストール」をクリックします(図28-15)。

図28-15 Eclipseインストールの詳細

5. アンインストールの詳細ページで、「終了」をクリックして、Developer Toolsプラグインのアンインストール・プロセスを続行します。

6. 更新が正常に完了すると、「ソフトウェアの更新」ダイアログが開きます。「Yes」をクリックして、Eclipseを再起動します。

Eclipseを再起動すると、プラグイン・キャッシュがリフレッシュされ、EclipseからDeveloper Toolsプラグインが完全に削除されます。

29 EclipseのDeveloper Tools機能の概要

WebCenter Sitesが統合されたEclipse IDEのDeveloper Tools機能には、プロジェクト、ワークスペース、各種ビュー、データのエクスポート/インポートなどが含まれています。

EclipseのDeveloper Tools機能の詳細は、次の項を参照してください。

- 「Oracle WebCenter Sites」パースペクティブについて

- 構成フォームの理解

- Eclipseのプロジェクトとワークスペースの理解

- Developer Toolsのビューについて

- データ同期(エクスポート/インポート)ツール

29.1 「Oracle WebCenter Sites」パースペクティブについて

EclipseでのDeveloper Toolsの機能は、すべて「Oracle WebCenter Sites」パースペクティブ内にグループ化されています。ただし、EclipseがWebCenter Sitesインスタンスと統合されているかぎり使用可能な、EclipseのWebCenter Sitesコンポーネントで作業するためにパースペクティブを開く必要がありません。「Oracle WebCenter Sites」パースペクティブを開くには、「ウィンドウ」→パースペクティブを開く→「その他」→「Oracle WebCenter Sites」を選択します。

次の図に、「Oracle WebCenter Sites」パースペクティブを示します。

図29-1 「Oracle WebCenter Sites」パースペクティブ

次のビューは、Developer ToolsがWebCenter Sitesと正常に統合されるとEclipseで使用できます。

- プロジェクト・エクスプローラとSites作業(左側のナビゲーション・ペインに表示)

- テンプレート・ビュー(左側のナビゲーション・ペインに表示)

- エラー・ログ、Sites UIおよびサイト・プレビュー・ブラウザ(Eclipse IDEの下部に表示)

- ウィザード(Eclipse IDEの上部のWebCenter Siteツールバーに表示)

- Sitesログ

- Sitesロギング構成

- Sites開発者参照

Developer Toolsのビューの詳細は、「Developer Toolsのビューについて」を参照してください。「プロジェクト」フォルダの詳細は、「Eclipseのプロジェクトとワークスペースの理解」を参照してください。

29.2 構成フォームの理解

構成フォーム(図29-2)は、WebCenter Sitesと統合されたEclipseに初めてアクセスしたときに自動的に開かれます。それ以降のアクセスでは、WebCenter Sitesツールバーのプリファレンスの構成ウィザードを選択して、構成フォームを開くことができます。このフォームでは、作業対象にするWebCenter Sitesインスタンスを指定できます。

図29-2 構成フォーム

構成フォームでは、WebCenter Sitesのインストール・ディレクトリへのパス、RestAdminグループに属するWebCenter SitesユーザーおよびWebCenter Sitesインスタンスのプロジェクト名が必須項目です。必須情報をすべて入力すると、Developer Toolsは、そのWebCenter Sitesインスタンスに応じて、他の複数のパラメータを決定し、それらのパラメータの情報を読取り専用フィールドに表示します。また、「接続のテスト」ボタンで、Developer Toolsが指定のWebCenter Sitesインスタンスに接続しているかどうかを判断できます。オンラインにするチェック・ボックスは、オンラインで作業するか、オフラインで作業するかを指定するオプションです。このチェック・ボックスの選択を解除しても、EclipseのすべてのWebCenter Sitesビューにはアクセスできますが、WebCenter Sitesリソースの作成または編集はできなくなります。「OK」をクリックして、プロジェクトを作成します。オンラインでの作業を選択する場合は、「OK」をクリックしても、WebCenter Sitesインスタンスにログインし、すべてのWebCenter Sitesビューがリフレッシュされます。

29.3 Eclipseのプロジェクトとワークスペースの理解

Eclipseからアクセスする各WebCenter Sitesインスタンスには、Eclipseプロジェクトが割り当てられます。Eclipseプロジェクトのフォルダは、「プロジェクト・エクスプローラ」ビューに表示されます。このプロジェクトは、Developer Toolsワークスペースのアイテムを追跡するために必要になります。デフォルトでは、WebCenter Sitesインスタンスごとにプロジェクトが1つのみ作成され、1つのプロジェクトで対応できるWebCenter Sitesインスタンスは1つのみになります。

注意:

プロジェクトの主な目的は、情報の追跡を円滑にすることと、Eclipseイベントを処理することです。プロジェクトはDeveloper Toolsプラグインで管理されます。プロジェクトは、開いたり、閉じたり、変更したりしないでください 。

各Eclipseプロジェクトには、次のエレメントが含まれます。

- datasource: このフォルダは、すべてのデータのエクスポート先の場所にリンクされています。ローカル接続の場合、このフォルダは、ファイル・システムの<sites-home>にあるconfigフォルダに直接リンクされます。リモート接続の場合、このフォルダはプロジェクト(envision)フォルダ内部に作成され、接続先のWebCenter Sitesインスタンスのデータストアにリンクされます。

- src: Developer Toolsでは、デフォルトで1つのsrcフォルダが提供され、このフォルダには、WebCenter SitesからエクスポートしたすべてのControllerアセットが格納されます。このフォルダ内のリソースは、バージョン・コントロール・システムにチェックインできます。このフォルダは、ControllerをWebCenter SitesからEclipseワークスペースにエクスポートするまでは空のままです。

- WEB-INF: このフォルダには、現在のWebCenter SitesインスタンスのWEB-INFフォルダへのリンクが含まれています。リモート接続の場合は、このフォルダを接続先のWebCenter SitesインスタンスのWEB-INFフォルダに手動でリンクする必要があります。手順は、「リモート・ホストでコード補完を有効にする方法」を参照してください。

図29-3に、サンプルのEclipseプロジェクト・フォルダを示します。

図29-3 サンプルのEclipseプロジェクト

29.4 Developer Toolsのビューについて

次の各項目では、Developer Toolsで使用可能なビューについて説明します。

- ワークスペース

- ログ・ビューア

- テンプレート・ビュー

- プレビュー・ビュー

- Sitesビュー

- Controllerビュー

- ロギング構成ビュー

- 開発者参照ビュー

- ウィザード

29.4.1 ワークスペース

このビューでは、コード関連のリソースにアクセスできます。リソースは、それぞれのサイト・アフィリエーションに応じてグループ化されます。リソースを選択すると、このビューの下側にあるテキスト・ボックスに、そのリソースについての簡単な概要が表示されます(図29-4)。

図29-4 ワークスペース・ビュー

ツリー内のリソースを右クリックすると、選択可能な管理オプションが表示されます。表示されるオプションは、選択したリソースに応じて異なります。

- Show Metadata: .main.xmlファイルへのショートカットです。このファイルには、選択したアイテムのメタデータが含まれています。

- Site Entry: リソースのサイト・エントリを表示したり、サイト・エントリを別のサイトと共有したり、新しいサイト・エントリを作成したり、サイト・エントリを削除したりします。

- Share: このリソースが関連付けられているサイトを管理します。

- Properties: このリソースのプロパティ(キャッシュ基準やデフォルトの引数など)を管理します。

- Delete: このリソースを削除します。

29.4.2 ログ・ビューア

このビューには、動的に更新されるWebCenter Sitesログ・ファイルのレコードが表示されます(図29-5)。このビューを使用すると、Eclipseと統合されたWebCenter Sitesインスタンスの動作を監視できます。

図29-5 ログ・ファイル

29.4.3 テンプレート・ビュー

このビューには、Eclipsで作成したテンプレート・アセットの階層ビューと、WebCenter SitesからEclipseにエクスポートしたテンプレート・アセットが表示されます。「ソート」オプションをクリックして、関連付けられているデバイス・グループまたはサイト別にテンプレートをグループ化します。

次の図に、Eclipse IDEのテンプレート・ビューを示します。

図29-6 テンプレート・ビュー

29.4.4 プレビュー・ビュー

このビューでは、ページをすばやくプレビューできます(図29-7)。このビューでWebページをプレビューするには、アドレス・バーにページのURLを入力して、[Enter]を押すか、「Go」をクリックします。現在のページをリフレッシュするには、キーボード・ショートカットの[Ctrl] + [R]を使用するか、「Go」をクリックします。

図29-7 Sitesプレビュー・ブラウザ・ビュー

29.4.5 Sitesビュー

このビューには、組込みブラウザのAdminおよびOracle WebCenter Sites: Contributorインタフェースが表示されます(図29-8)。これは、スタンドアロンのブラウザで使用するAdminインタフェースまたはContributorインタフェースと同じです。

図29-8 Sitesビュー

29.4.6 Controllerビュー

このビューには、Controllerアセットの表示および管理に使用される「コントローラ・アセット・ユーティリティ」フォームが表示されます。

このフォームは、Adminインタフェース(「一般的な管理」ツリーを選択して「システム・ツール」を開き、「コントローラ」をダブルクリックします)でも使用できます。

図29-9 Controllerビュー

29.4.7 ロギング構成ビュー

WebCenter SitesシステムでODLを使用している場合、このビューには、動的に更新される「ログODLの構成」フォームが表示されます(図29-10)。「ログODLの構成」フォームでは、現在のログ出力の表示、ログ出力レベルの変更、新しいログ出力の追加、およびログの検索が可能です。

図29-10 「ログODLの構成」フォーム

「ログODLの構成」フォームの使用の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

29.4.8 開発者参照ビュー

このビューには、Oracle WebCenter Sitesタグ・リファレンス、Oracle WebCenter Sites Java APIリファレンスおよびOracle WebCenter Sites Java APIリファレンスのVisitor Servicesのタブが表示されます。

29.4.9 ウィザード

ウィザードは、OracleメニューまたはWebCenter Sitesツールバーから起動できます。コード・ベースのWebCenter Sitesリソースを作成できます。

図29-11 ウィザード

使用できるウィザードは、「新規テンプレートの作成」、新規コントローラの作成、新規エレメントの作成、新規SiteEntryの作成、新規エレメント・カタログ・エントリの作成および新規SiteCatalogエントリの作成です。

ウィザードを使用したWebCenter Sitesリソースの作成の詳細は、「リソースの作成方法」を参照してください。

29.5 データ同期(エクスポート/インポート)ツール

WebCenter SitesツールバーのSynchUpウィザードからアクセス可能なデータ同期ツールでは、次の2つのタブが表示されます。

- エクスポート(WebCenter Sitesからワークスペースにリソースを同期)

- インポート(ワークスペースからWebCenter Sitesにリソースを同期)

29.5.1 エクスポート(WebCenter Sitesからワークスペースにリソースを同期)

「エクスポート」タブは、IDEと統合されたWebCenter SitesからDeveloper Toolsワークスペースにデータをエクスポートするために使用します。このプロセスでは、Developer Toolsは、選択されたリソースをシリアライズ(データベース表現をファイルに変換)して、シリアライズした表現をDeveloper Toolsワークスペースにコピーします。これにより、そのリソースをEclipseで変更できるようになります。

次の図は、データの同期フォームの「エクスポート」タブを示します。

図29-12 SynchUpアイコン/「エクスポート」タブ

WebCenter Sitesからワークスペースにアイテムをエクスポートする手順:

1. エクスポートするアイテムを選択します。アイテムのリストを絞り込むには、正規表現検索バーに移動して、検索するアセット・タイプの名前を入力します。複数のアセット・タイプを検索するには、カンマ区切りのリストを入力します。

2. エクスポートして閉じるをクリックします。

Developer Toolsワークスペースにエクスポートしたアセットは、Sites作業ツリー・タブにリストされます。

29.5.2 インポート(ワークスペースからWebCenter Sitesにリソースを同期)

「インポート」タブは、IDEと統合されたWebCenter SitesにDeveloper Toolsワークスペースからのリソースをインポートするために使用します。このプロセスでは、Developer Toolsは、選択されたリソースをWebCenter Sitesのネイティブ表現に変換して、WebCenter Sitesデータベースにコピーします。

次の図は、データの同期フォームの「インポート」タブを示します。

図29-13 SynchUpアイコン/「インポート」タブ

ワークスペースからWebCenter Sitesにアイテムをインポートする手順:

1. インポートするアイテムを選択します。アイテムのリストを絞り込むには、正規表現検索バーに移動して、検索するアセット・タイプの名前を入力します。

2. インポートして閉じるをクリックします。

30 Developer Toolsを使用したJSPの開発

Developer Toolsキットを使用してネイティブのEclipse JSPエディタを使用することにより、WebCenter Sites JSPを開発できます。

Developer Toolsを使用したJSPの開発の詳細は、次の項を参照してください。

- Developer Toolsを使用したJSPの開発

- タグおよびJava APIの補完

- デバッグ

30.1 Developer Toolsを使用したJSPの開発

Developer Toolsキットでは、ネイティブのEclipse JSPエディタを使用したWebCenter Sites JSPの開発がサポートされています。Eclipse JSPエディタには、WebCenter SitesタグとJava API補完、構文の強調表示およびデバッグのサポートが含まれています。

次の図に、EclipseエディタでのWebCenter Sites JSPの例を示します。

図30-1 Eclipse JSPエディタ

WebCenter Sites JSPには、ページのキャッシング、結果セットのキャッシングおよび関連メタデータ(テンプレート・アセット、CSElementアセットまたはElementCatalogエントリなど)を含めることができます。JSPのメタデータを使用すると、WebCenter SitesでJSPを追跡および管理できます。Developer Toolsは、JSPの基礎となるWebCenter Sitesプロセスを透過的に処理します。このプロセスには、JSPおよび対応するメタデータの追跡も含まれます。WebCenter Siteインスタンスの実行中に、EclipseでJSPを保存する場合、Developer Toolsキットはこれらの変更を自動的に、WebCenter Sitesインスタンスと同期します。JSPに関連付られているメタデータも、WebCenter Sitesと同期されます。これにより、EclipseでJSPを保存すると同時に、WebCenter Sitesで変更を表示できます。

30.2 タグおよびJava APIの補完

Eclipseには、タグおよびJava APIの補完機能があります。Eclipseでは、現在のWebCenter Sitesインスタンスに属するタグ・ライブラリとJARファイルを使用して、WebCenter Sites関連タグおよびJava APIの適切なコード補完を提供します。ローカル・ホストの場合、WebCenter Sitesタグ・ライブラリとJARファイルは、Eclipseプロジェクトに自動的にリンクされ、Eclipseプロジェクト・フォルダ(Project Explorerビュー内)に含まれます。リモート・ホストの場合、WebCenter Sitesタグ・ライブラリとJARファイルは、リモート・ホストからEclipseプロジェクトに手動でコピーする必要があります。手順については、「Developer Toolsの設定」を参照してください。

- タグ・ライブラリは、WEB-INFフォルダの下のfuturetense_csフォルダに含まれています。

- JARファイルは、WEB-INF/libフォルダに含まれています。

注意:

タグおよびJava APIの補完機能を使用する場合は、次の点に注意してください。

- コードがアプリケーション・サーバーにデプロイできるようにするために、厳密なJSPコーディング標準に従っていることを確認してください。

- Eclipseコード補完により、WebCenter Sites JAR内に含まれているパブリックJavaメソッドがすべて表示されます。WebCenter Sitesドキュメントで説明されているAPIのみを使用してください。ドキュメントに記載されていない機能の使用は、リスクが高く、サポートされていません。

Eclipseでは、タグおよびJava API補完機能により、WebCenter Sites JSPを管理する際に使用する各タグおよびJavaコードに関する情報が表示されます。たとえば、WebCenter Sites JSPでの作業中に、タグの名前の入力を開始すると、コード補完の提案をリストするウィンドウが表示されます。この場合、各提案に関する情報が含まれる2番目のダイアログが開きます(図30-2)。

図30-2 タグおよびJava APIの補完機能

コード補完機能以外に、Javadoc、Visitor Services APIおよびタグ・リファレンスがSites開発者リファレンス・ビューでアクセス可能です。詳細は、「Sites開発者リファレンス・ビュー」を参照してください。

30.3 デバッグ

Developer ToolsでJavaおよびJSPコードをデバッグするには、最初に、WebCenter Sitesを実行するJVMプロセスにデバッガをアタッチする必要があります。これはリモート・デバッグで実行することをお薦めします。WebCenter Sites JVMをアタッチするには、次のURLに記載されている、Eclipseが提供する手順に従ってください。

http://www.ibm.com/developerworks/library/os-ecbug/

JVMがデバッガにアタッチされると、JSPおよびJavaコード、ビュー変数などでブレークポイントを設定できます。

31 Developer Toolsを使用したモバイルWebサイト用テンプレートの作成

Developer Toolsを使用すると、モバイル・サイト用のテンプレートを作成できます。

モバイルWebサイト用のテンプレートの作成の詳細は、次の項を参照してください。

- Developer ToolsのMobilityサポートについて

- サイト・ワークスペース・タブからのモバイル・テンプレートの作成

- サイトおよびデバイス・グループ・ビューでのモバイル・テンプレートの作成

31.1 Developer ToolsのMobilityサポートについて

Developer Toolsは、Mobilityフレームワークをサポートしています。Mobility機能を使用すると、モバイル・デバイス用のWebサイトを作成できます。Mobility機能の詳細は、「モバイルWebサイトをサポートするためのWebCenter Sitesの構成」を参照してください。

31.2 サイト・ワークスペース・タブからのモバイル・テンプレートの作成

ワークスペースには、WebCenter SitesインスタンスからEclipseにエクスポートしたテンプレート(デフォルトおよびモバイル)が表示されます。モバイル・テンプレートは、開発者定義の接尾辞で識別できます。たとえば、タッチスクリーン・デバイス用に作成したテンプレートの場合は、_Touchのようになります。既存のテンプレートからモバイル・テンプレートを作成できます。この項の残りの部分では、モバイル・テンプレートの作成手順について説明します。

モバイルWebサイト用のテンプレートを作成する手順は次のとおりです。:

1. サイト・ワークスペース・エレメント・タブ(左パネル内)で、モバイル・テンプレートを作成するサイトのノードを開きます。

注意:

モバイル・テンプレートには、開発者定義の接尾辞ごとに1つ以上のデバイス・グループ(同様の機能を備えたデバイスのグループ)が関連付けられます。デバイス・グループの詳細は、「モバイルWebサイトをサポートするためのWebCenter Sitesの構成」を参照してください。

図31-1は、MarketingSiteツリーを開いた状態を示しており、このツリーには、デフォルト・デバイス・グループ用(デスクトップおよびラップトップ・デバイス用)のHome.jspテンプレートが含まれています。

図31-1 MarketingSiteノードの下に表示されたHome.jspテンプレート・エレメント

2. モバイル・テンプレートの基にするテンプレートを右クリックします。コンテキスト・メニューから、デバイス・グループ・テンプレートの作成を選択して、テンプレートを作成するデバイス・グループの名前を選択します(図31-2)。

注意:

複数のデバイス・グループで、同一の接尾辞を共有できます。リスト内にデバイス・グループが見つからない場合は、作成されているデバイス・グループと同じ接尾辞でテンプレートを定義できます。開発者定義の接尾辞の詳細は、「モバイルWebサイトをサポートするためのWebCenter Sitesの構成」を参照してください。

図31-2 「Create Device Group Template」のコンテキスト・メニュー

「新規テンプレートの作成」ダイアログが開き、固定および変更可能なプロパティの値を保持するフィールドが表示されます(これらの値は、ソース・テンプレート(この例では、MarketingSiteのHome_Touchテンプレート)から、テンプレート・ウィザードによってコピーされた値です)。

3. 変更可能フィールドのプロパティをモバイル・テンプレートの要件に合せて編集して、「終了」をクリックします。

図31-3 Home_Touchモバイル・テンプレートの「新規テンプレートの作成」フォーム

モバイル・テンプレートのファイル名は、サイト・ワークスペース・エレメント・タブにリストされています(図31-4)。

図31-4 サイト・ワークスペース・エレメント・タブに表示されたHome_Touch.jsp

モバイル・テンプレートには、Home_Touchという名前が付けられており、Homeはテンプレートの名前、_Touchは、このテンプレートが作成されたデバイス・グループに定義した接尾辞です。

4. 新しいモバイル・テンプレートのコードを変更するには、ネイティブのEclipse JSPエディタを使用してください。詳細は、「Developer Toolsを使用したJSPの開発」を参照してください。

31.3 サイトおよびデバイス・グループ・ビューでのモバイル・テンプレートの作成

サイトまたは接尾辞別にテンプレートをグループ化して、テンプレート・バリアントを表示できます。「サイト」ビューでは、テンプレートは各アセット・タイプの下に表示され、テンプレート・バリアントが各テンプレートの下に作成されます。これにより、様々なテンプレートで作業する開発者が、他の開発者が作業を完了するのを待機することなく、必要に応じてテンプレート・バリアントを作成できます。「デバイス・グループ」(接尾辞)ビューでは、かわりに各デバイス・グループの下に、アセット・タイプが表示されます。これにより、各接尾辞またはデバイス・グループの開発者がテンプレート・バリアントで同時に作業できます。

「サイト」ビューでテンプレート・バリアントを作成する手順:

1. ツールバーで、ドロップダウン矢印をクリックし、グループ基準を選択して、コンテキスト・メニューから「サイト」を選択します(図31-5)。

図31-5 サイト別のグループ化

2. サイトで、図31-6に示すように、バリアントを作成するテンプレートを開きます。たとえば、非タッチ・デバイス・グループのテンプレート・バリアントを作成する場合、非タッチと完全に似ているTouchテンプレートを選択して、そのバリアントを作成できます。次に。必要に応じて、非タッチのこの新しいバリアントを編集できます。

図31-6 接尾辞を表示するために展開したサイト・ツリー

3. 必要に応じて、次のいずれかを実行します。

- 単一のデバイス・グループのテンプレート・バリアントを作成するには、図31-7に示すように、テンプレートの下にある同様のバリアントを右クリックして、デバイス・グループ・テンプレートの作成を選択し、テンプレート・バリアントを作成するデバイス・グループを選択します。

図31-7 デバイス・グループ・テンプレートの作成

図31-8に示すように、ターゲット・バリアントに対応する値が事前に移入された「新規テンプレートの作成」ダイアログが表示されます。

図31-8 単一のテンプレートの作成

変更がある場合は変更を行い、「終了」をクリックします。新しいバリアントを作成したテンプレートの下に、そのバリアントが表示されます。

- 複数のデバイス・グループからテンプレート・バリアントを作成するには、テンプレートを右クリックして、デバイス・グループ・テンプレートのバルク生成を選択します。図31-9に示すように、複数選択のダイアログでデバイス・グループを選択して、そのテンプレート・バリアントを対応する接尾辞に作成します。

図31-9 複数バリアントの選択

「OK」をクリックします。新しいバリアントを作成したテンプレートの下に、そのバリアントが表示されます。

4. 必要に応じて、テンプレート・コードを編集して、変更を保存します。

デバイス・グループのテンプレート・バリアントを作成する手順:

1. ツールバーで、ドロップダウン矢印をクリックし、グループ基準選択して、コンテキスト・メニューから「デバイス・グループ」を選択します。

2. デバイス・グループ別にテンプレートを開きます。

3. テンプレートを作成するアセット・タイプで、必要に応じて次のいずれかを実行します。

- テンプレートのバリアントを作成するには、アセット・タイプ・ノードの下にあるテンプレートを右クリックして、デバイス・グループ・テンプレートの作成を選択し(図31-10)、テンプレート・バリアントを作成するデバイス・グループを選択します。

図31-10 テンプレート・バリアントのコンテキスト・メニュー

ターゲット・バリアントに対応する値が事前に移入された「新規テンプレートの作成」ダイアログが表示されます。

- テンプレートの複数のバリアントを作成するには、テンプレートを右クリックして、デバイス・グループ・テンプレートのバルク生成を選択します。複数選択のダイアログでデバイス・グループを選択して、そのテンプレート・バリアントを対応する接尾辞に作成します。

4. 必要に応じて、テンプレート・コードを編集して、変更を保存します。

32 Developer Toolsを使用した同期および交換

Developer Toolsのエクスポート/インポート機能を使用すると、データを同期および交換できます。Developer ToolsキットはIDとサイト・マッピング・プロセスを使用して、開発者がWebCenter Sitesインスタンス間のリソースを交換できるようにします。

Developer Toolsを使用したデータの同期および交換の詳細は、次の項を参照してください。

- Developer Toolsを使用した同期

- 同期シナリオ

- 依存性の解決について

- IDマッピング

- サイト・マッピングの使用

32.1 Developer Toolsを使用した同期

同期はWebCenter Sitesインスタンスとその関連ワークスペース間のリソースの双方向フローです。Developer Toolsを使用して、次の同期操作を実行できます。

- 組込み依存性解決とIDマッピングを持つアセットをエクスポートおよびインポートします。

- フレックス・ファミリやAssetMakerアセット・タイプなどの、アセット・タイプをエクスポートおよびインポートします。

- サイト定義、ロール、スタート・メニュー・アイテムおよびツリー・タブをエクスポートおよびインポートします。

- SiteCatalogエントリおよびElementCatalogエントリをエクスポートおよびインポートします。

- サイトの再マッピングを実行します。たとえば、WebCenter Sites CMサイトにインポート可能な再使用可能なモジュールを作成します(コマンドライン・ツールの操作)

指定されたサイトのすべてのリソースをエクスポートまたはインポートすると、バージョン・コントロール・システムでサイト全体を追跡できます。上級開発者はコマンドライン・ツールを使用して、再使用可能なモジュール(カスタム・ワークスペース)を作成することにより、あるサイトのリソースを別のサイトに再マッピングできます。

32.2 同期シナリオ

シナリオによって、リソースは自動または手動のいずれかで同期されます。

WebCenter Sitesを実行している場合、WebCenter SitesとEclipse間のリソースは、次のアクションがEclipseで実行されるときに自動的に同期されます。

- コード・ベースのリソース(テンプレート、CSElement、SiteEntry、ElementCatalogエントリおよびSiteCatalogエントリ)が、EclipseでDeveloper Toolsのウィザードを使用して作成されます。

- Developer Toolsワークスペースに格納されたコード・ベースのリソース(テンプレート、CSElementおよびElementCatalogエントリ)が、Eclipseで編集されます。これには、JSPファイル、XMLファイル、メタデータおよびリソースに関連付けられている他のファイルの編集が含まれます。
たとえば、リソースの関連付けられたJSPファイルをEclipseエディタで編集する場合、Developer Toolsキットでは、変更内容がWebCenter Sitesインスタンスに自動的に同期されます。また、上級開発者はEclipseエディタを使用して、フレックス定義のメタデータ・ファイル(.main.xml)を編集でき、その変更内容はWebCenter Sitesに自動的に同期されます。ただし、フレックス定義を変更するには、Adminインタフェースを使用することをお薦めします。

場合によっては、Eclipse IDEの同期ツールまたはコマンドライン・ツール(上級開発者の場合)のいずれかを使用して、リソースを手動で同期する必要があります。手動同期は次の場合に必要です。

- Eclipseエディタは、Developer Toolsワークスペースに格納されているリソースの編集には使用されません。たとえば、リソースが共有ネットワーク・ファイル・システムまたはバージョン・コントロール・システムからDeveloper Toolsワークスペースにコピーされる場合などです。

- WebCenter Sitesのリソースが、WebCenter Sitesインタフェースで変更される場合。

注意:

Eclipse IDEは埋込みのAdminインタフェースを提供します。ただし、Eclipseはこのインタフェースを使用して行われる変更を検出しません。したがって、埋込みのAdminインタフェースでの作業は、Adminインタフェースを実行しているスタンドアロン・ブラウザでの作業と同じになります。

- WebCenter Sitesは、Eclipse IDEでリソースを作成または編集している間は実行されません。WebCenter Sitesが再起動したら、作成または編集したリソースを手動で同期する必要があります。

リソースの同期にコマンドライン・ツールを使用するのは、サーバーをテストするためにデプロイされるナイトリー・ビルドなど、主にデプロイメントのためです。たとえば、上級開発者は、自動化されたデプロイメント手順用のスクリプトに同期コマンドを埋め込むことができます。コマンドライン・ツールの実行および使用方法の詳細は、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。

32.3 依存性の解決について

WebCenter Sitesのリソースは、多くの場合、他のリソースに依存します。たとえばフレックス・アセットは、そのアセットが作成される前に、関連付けられたフレックス定義が存在している必要があります。また、フレックス定義は属性セットに依存したり、他のリソースに依存する可能性もあります。したがって、すべてのフレックス構造では、システム上にフレックス・ファミリが存在している必要があります。フレックス・アセットを空のWebCenter Sitesシステムにインポートするには、まずフレックス・アセットが関連付けられるフレックス・ファミリを作成する必要があります。その後、次の手順を実行します。

1. 名前、住所および年齢などのフレックス属性を作成します。

2. フレックス親定義を作成します。

3. フレックス定義を作成します。

4. フレックス親を作成します。

5. フレックス・アセットを作成します。

フレックス・アセットをエクスポートすると、Developer Toolsキットによって、そのアセットのすべての依存性が解決され、その依存性がすべて自動的にエクスポートされます。したがって、リソース(フレックス・アセットなど)を選択するだけで、Developer Toolsキットによって、アセットの依存性がすべて計算されます。

注意:

Developer Toolsキットは、サイト定義上でリソースの依存性を解決しません。これにより、サイト全体またはサイトのサブセットをエクスポートまたはインポートするか、あるいはサイト定義を完全に無視するかどうか(たとえば、コマンドライン・ツールを使用して、任意のサイトにインポートできる再使用可能なモジュールを作成している場合)を選択できます。再使用可能なモジュールの作成の詳細な例は、「Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。

32.4 IDマッピング

WebCenter Sitesで作成された各リソースには、一意のローカルIDが割り当てられます。リソースのローカルIDは、作成されたWebCenter Sitesインスタンスに対してのみ一意です。リソースの作成には複数のWebCenter Sitesインスタンスが使用されるため、別個のWebCenter Sitesインスタンス上の2つの異なるリソースが同じローカルIDを持つことができます。

この項には次のトピックが含まれます:

- IDマッピングについて

- リソースのfw_uidのオーバーライド

- 既存のリソースとDeveloper Toolsの併用について把握すべき内容

32.4.1 IDマッピングについて

リソースを一意に識別するために、Developer Toolsキットは、すべてのWebCenter Sitesインスタンス間で一意のグローバル一意識別子(fw_uid)を各リソースに割り当てます。さらに、リソースをWebCenter Sitesインスタンスにインポートすると、そのインスタンス上のそのリソースに新しいローカル識別子が割り当てられます。リソースが他のアセット(アソシエーション、アセット・ポインタ、フレックス定義など)を参照している場合は、それらのアセットごとに新しいローカル識別子が生成されます。そのWebCenter Sitesインスタンスに対するそれ以降のインポートでは、同じローカル識別子がリソースに割り当てられます。Developer Toolsキットでは、すべてのWebCenter Sitesインスタンス間でリソースのfw_uid値が保持されます。リソースとその参照されたアセットが元のWebCenter Sitesインスタンスに再度インポートされると、Developer Toolsキットはローカル識別子をその元の値に再度マッピングします。

注意:

テンプレート・アセット、フレックス属性およびツリー・タブなど、特定のWebCenter Sitesのリソースには、一意の名前の制約があります。名前が競合しないように、各リソースがすべてのWebCenter Sitesインスタンス間で、一意の名前が付けられていることを確認してください。

たとえば、開発者AはCS1という名前のWebCenter Sitesインスタンスを使用し、開発者BはCS2という名前のWebCenter Sitesインスタンスを使用しているとします。両方の開発者は完全に異なるテンプレート・アセットを作成しました。開発者AはテンプレートAを作成し、開発者BはテンプレートBを作成しました。2つのテンプレート・アセットは、fw_uid値も名前も異なります。ただし、ローカルIDがランダムに割り当てられているため、両方のテンプレート・アセットに、偶然同じローカルID (12345)が割り当てられています。開発者AとBは、お互いのWebCenter Sitesインスタンス間で、テンプレート・アセットを交換しようと考えています。開発者AはテンプレートBをCS1インスタンスに、開発者BはテンプレートAをCS2インスタンスにインポートしようと考えています。

図32-1は、両方の開発者がWebCenter Sitesインスタンス間でテンプレート・アセットを交換するために行う手順を説明しています。両方のテンプレート・アセットのローカルIDは、別の開発者のWebCenter Sitesインスタンスにインポートされるときに再マップされます。テンプレートAがCS2インスタンスにインポートされるときに、システムによってローカルID 52563が割り当てられます。テンプレートBがCS1インスタンスにインポートされるときに、システムによってローカルID 22342が割り当てられます。いずれの場合にも、両方のテンプレート・アセットのfw_uid値は同じままです。

注意:

この例の開発者は、WebCenter Sitesインスタンス間でのリソース交換にVCSまたは共有ファイル・システムを使用します。VCSの使用方法の詳細は、「Developer Toolのワークスペースとバージョン・コントロール・システムとの統合」を参照してください。

図32-1 同じローカルIDを持つ2つの異なるアセットの2つのWebCenter Sitesインスタンス間での交換

図32-2では、開発者AはテンプレートAをDeployment WebCenter Sitesインスタンス(システム管理者によって管理される)にデプロイしようと考えており、開発者BはテンプレートBを同じインスタンスにデプロイしようと考えています。両方のテンプレート・アセットには、同じローカルID (12345)があります。

開発者AとBは、各自のテンプレートを、WebCenter Sitesインスタンスの、メインのDeveloper Toolsワークスペースにエクスポートします。その後、各自のテンプレートをVCSまたは共有ファイル・システムにコピーします。ここから、システム管理者は両方のテンプレート・アセットを、Deployment WebCenter Sitesの、メインのDeveloper Toolsワークスペースにコピーします。次にシステム管理者は、2つのテンプレート・アセットを、ワークスペースからDeployment WebCenter Sitesにインポートします。インポート時に、システムによって両方のテンプレートに新しいローカルIDが割り当てられます。テンプレートAにはローカルID 45678,が割り当てられ、テンプレートBにはローカルID 98765が割り当てられます。アセットのfw_uid値は変わりません。

図32-2 同じローカルIDを持つ2つの異なるアセットの、3番目のWebCenter Sitesインスタンスへのデプロイ

リソースがワークスペースにエクスポートされた場合は、fw_uidによって識別されます。ElementCatalogエントリとSiteCatalogエントリはエレメント名によって一意に識別されているため、fw_uidは割り当てられません。

32.4.2 リソースのfw_uidのオーバーライド

リソースが作成されると、グローバルな一意識別子としてUUID値が自動的に生成され、fw_uidという名前のアセット属性に格納されます。上級開発者はアセットAPIを使用してfw_uid属性を変更することにより、デフォルトのfw_uidスキームを独自のスキームでオーバーライドできます。アセットAPIの使用の詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

注意:

デフォルトのWebCenter Sites fw_uidスキームの使用をお薦めします。リソースのデフォルトfw_uid値をオーバーライドする場合は、値がWebCenter Sitesインスタンス全体で一意であることを確認してください。リソースのfw_uid属性を設定したら、その後は値を変更しないでください。

32.4.3 既存のリソースとDeveloper Toolsの併用について把握すべき内容

使用するOracle WebCenter SitesシステムがFatWire Content Serverのアップグレードの場合は、既存のリソースの一部でfw_uid値がCSSystem:[type]:idに設定されている場合があります。ただし、Content Serverのバージョン7.6以降では、リソースのfw_uidはUUID値として生成されます。Developer Toolsは、リソースのfw_uid値がグローバルで一意であるかぎり、fw_uid値のいずれかのタイプでリソースをマップできます。したがって、既存のリソースの現在のfw_uid値を(CSSystem:[type]:idの形式で)引き続き使用できます。

Developer Toolsを既存のリソースと併用する場合は、次のいずれか(または両方)を実行してください。

- 既存のリソースの、CSSystem:[type]:idのfw_uid値を引き続き使用することをお薦めします。ただし、他のWebCenter Sitesインスタンスが、異なるリソースに同じfw_uid値を生成していないことを確認する必要があります。たとえば、WebCenter Sitesの開発インスタンスがあり、管理インスタンスにリソースをパブリッシュしている場合、パブリッシュされたリソースのfw_uid値は両方のインスタンスに対して同じままになります。したがって、Developer Toolsを使用した、これらの2つのインスタンス間のリソースの同期によって、ID競合が発生することはありません。

- 異なるFatWire Content Serverインスタンス上で作成されたがfw_uid値が同じである既存のリソースが存在する場合は、これらの各リソースに新しい一意のfw_uid値を割り当てる必要があります。ID競合を避けるために、現在のfw_uid値を削除して、WebCenter Sitesインスタンスからリソースをエクスポートする際にDeveloper Toolsが新しいUUID値を生成できるようにするか、または独自の一意IDをリソースに割り当てることができます。手順については、「リソースのfw_uidのオーバーライド」を参照してください。

注意:

リソースに新しいfw_uidを割り当てる場合は、そのリソースのすべてのインスタンスに新しいfw_uid値を割り当てる必要があります。たとえば、リソースを別のWebCenter Sitesインスタンスにパブリッシュした後でfw_uid値を変更する場合は、必ずそのリソースの両方のコピーに、同じfw_uidを割り当ててください。

32.5 サイト・マッピングの使用

アセットなどの大半のWebCenter Sitesリソースは、少なくとも1つのサイトに関連付けられています。リソースがWebCenter Sitesインスタンスからワークスペースへエクスポートされると、関連付けられているサイトの完全な(正規の)リストが.main.xmlファイル内に格納されます。新しいサイト・アフィリエーションの追加、現在のサイト・アフィリエーションの削除、または(上級開発者の場合)コマンドライン・ツールを使用したリソースのナチュラル・サイト・マッピングのオーバーライドを実行しないかぎり、リソースの正規リストはすべてのWebCenter Sitesインスタンス間で同じです。

この項には次のトピックが含まれます:

- ナチュラル・サイト・マッピングについて

- コマンドライン・ツールを使用したナチュラル・サイト・マッピングのオーバーライドについて

32.5.1 ナチュラル・サイト・マッピングについて

デフォルトでは、Developer Toolsは、リソースの.main.xmlファイルに格納された正規リストを参照することによって、関連サイトにリソースをマップします。リソースがインポートされるWebCenter Sitesインスタンス上に、このリストで参照されるサイトが存在する場合、Developer Toolsはそれらのサイトにリソースをマップします。WebCenter Sitesインスタンス上に、リソースの正規リストで参照されるサイトが存在しない場合、インポートは失敗します。

たとえば、開発者Aが2つのサイト(NewsとSports)をインストールします。別のWebCenter Sitesインスタンス上で、開発者Bも2つのサイト(NewsとWeather)をインストールします。両方の開発者は同じテンプレート・アセットを、それぞれのWebCenter Sitesインスタンスにインポートします。このテンプレート・アセットは、SportsとWeatherの両方のサイトに関連付けられます(両方のサイトがアセットの正規リストで参照されます)。インポート時に、Developer Toolsはテンプレート・アセットの正規リストを参照し、そのアセットを開発者Aの環境のSportsサイトと、開発者Bの環境のWeatherサイトにマップします。

開発者AとBがテンプレート・アセットに加えられた変更を互いに共有している場合、Developer Toolsは、両方のWebCenter Sitesインスタンスの適切なサイトにアセットをマッピングします。Developer Toolsは正規リストを使用して、テンプレート・アセットが関連付けられたサイトを認識します。これらのサイトの一部がインストールされていないインスタンスに、アセットをエクスポートした場合でも認識できます。

32.5.2 コマンドライン・ツールを使用したナチュラル・サイト・マッピングのオーバーライドについて

上級開発者はコマンドライン・ツールを使用して、正規リストで参照されていないサイトにリソースをインポートできます。コマンドライン・ツールを使用すると、再利用可能なモジュールを作成できます。このモジュールは、任意のサイトにインポート可能なリソースを含むワークスペースです。

たとえば、開発者がFirstSiteIIサンプル・サイト内にブログ・ソリューションを作成するとします。このソリューションには、フレックス・ファミリ、アセット、テンプレートなどのリソースが含まれます。開発者は、まだ存在しないサイトも含め、様々なサイトにリソースをインポートすることを望んでいます。上級開発者であるため、コマンドライン・ツールを使用してリソースを空のワークスペースにエクスポートしてから、このワークスペースのコンテンツを(.zipまたは.tar形式を使用して)アーカイブします。その後、他の開発者はコマンドライン・ツールを使用して、このモジュールに含まれるリソースのサイト・マッピングをカスタマイズし、モジュールのインポート先サイトを手動で指定します。

コマンドライン・ツールの使用方法の詳細は、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。再使用可能なモジュールの作成の詳細なシナリオは、「Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。

33 Developer Toolsのワークスペースの使用

Developer Toolsには、統合されたWebCenter Sitesインスタンスからエクスポートされたリソースが格納されます。

Developer Toolsのワークスペースを使用したリソースの格納の詳細は、次の項を参照してください。

- ワークスペースの概要

- ワークスペースの構造

- アセット記憶域の構造

- コード・ベースのリソース記憶域の構造

- 属性エディタ記憶域の構造

- アセット・タイプ記憶域の構造

33.1 ワークスペースの概要

ワークスペースとは、シリアライズされたWebCenter Sitesデータのディスクベースのリポジトリです。このデータは、ワークスペースのWebCenter Sitesインスタンスからのリソース、または別のインスタンスのワークスペースからのリソースを表します。ワークスペースには、アセット、フレックス・ファミリ、サイトなどのあらゆるタイプのWebCenter Sitesリソースを格納できます。各ワークスペースは、1つのWebCenter Sitesインスタンスに関連付けられています。

デフォルトでは、Eclipseは、WebCenter Sitesインスタンスごとに1つのメインDeveloper Toolsワークスペース(Eclipseプロジェクト・フォルダ内に配置される)を提供します。これは、Eclipse IDEで作業する際の継続的な開発に使用されます。カスタム・ワークスペースは、上級開発者がDeveloper Toolsのコマンドライン・ツールを使用して作成できます。カスタム・ワークスペースは、モジュールの作成などの特殊なプロジェクトに使用できます。カスタム・ワークスペースの作成方法の詳細は、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。

バージョン・コントロール・システム(Subversionなど)や共有ファイル・システムと併用することで、あるワークスペースに格納されたリソースを別のワークスペースと交換できるようになります。あるWebCenter Sitesインスタンスから関連ワークスペースにエクスポートされたリソースは、別のWebCenter Sitesインスタンスのワークスペースにコピーできます。これにより、そのリソースは、2番目のワークスペースの関連WebCenter Sitesインスタンスにインポートできるようになります。異なるワークスペース間でのリソース共有の詳細は、「Developer Toolのワークスペースとバージョン・コントロール・システムとの統合」を参照してください。

33.2 ワークスペースの構造

ワークスペースは、WebCenter Sitesのインストール・ディレクトリ内にあるexport/envisionフォルダに作成されます。メインDeveloper Toolsワークスペースは、export/envision/cs_workspaceフォルダ内に配置されます。メインDeveloper Toolsワークスペースは、Eclipseのプロジェクト・フォルダで表示可能な唯一のワークスペースです。

ワークスペースの構造は、どれも同じです。ワークスペースに含まれる各リソースは、単一のファイルまたは相関する複数のファイルとして格納されます。各リソースのメイン・ファイルの末尾には、.main.xmlが付きます。このファイルには、リソース固有のメタデータが含まれます。また、メイン・ファイルには、そのリソースに関連付けられた他のファイル(添付されたドキュメント、JSPファイル、BLOBなど)へのリンクも含まれます。これにより、各リソースは、リソースの関連ファイルがすべてワークスペース内に格納されている場合、完全な自己完結型リソースになります。それ以外の場合、リソースは不完全になります。

リソースの複数のファイルは、.main.xmlファイルの最後のセクションに、storable0、storable1などの形でリストされます。どのリソースの関連ファイルにも、同様の名前が付けられます。このようにすることで、リソースに関連するすべてのファイルが、まとめて表示されるようになります。ただし、元のルート・パスを保持するために個別に格納されるElementCatalogのエントリを除きます。

ワークスペースに含まれるリソースのファイルの場所は、リソースのタイプに応じて異なります。ワークスペースは、次の各セクションに分割されています。

- src/_metadata: アセット、アセット・タイプ、サイト、ロールなどを含む特定のリソースのメタデータ・セクション。また、レガシーXMLコードは、ELEMENTS/サブフォルダ内に格納されます。

- src/jsp/cs_deployed: このセクションには、リソースのJSPファイルが適切なパスの下に格納されます。

ワークスペースの構造は高度に一貫性が保たれているため、あるワークスペースから別のワークスペースにリソースをコピーできます。どのファイル・システムのコピー操作にも当てはまることですが、同じ名前のファイルを上書きしないように注意してください。

33.3 アセット記憶域の構造

アセットは、src/_metadata/ASSET/asset typeという名前のフォルダ内に格納されます。この構造には、アセット・データを含む2レベルのハッシュベースの階層があります。アセット・ファイルの名前は、アセット名と、そのアセットのfw_uid値に応じて決まります。アセットに添付ファイルやBLOBが含まれている場合、そのファイル名は、アセット名、属性名、fw_uid値、およびドキュメントまたはBLOB (存在する場合)の名前に基づいて決定されます。

たとえば、FSII IES_Manual.pdfという名前のDocument_Cアセットには、IES_MDPlayer_Manual.pdfという添付ドキュメントが含まれているとします。その場合、このアセットは、次に示す2つの個別のファイルに格納されることになります。

- 最初のファイルは、.main.xmlファイルです。このファイルには、アセットのメタデータと、アセットに関連付けられたファイルへのリンクが含まれます。

.src/_metadata/ASSET/Document_C/8/0/FSII IES_MDPlayer_
Manual.pdf(aa0b47b5-f558-49d4-a6ac2ee012d1b75).main.xml

- 2番目のファイルは、実際のドキュメントです。この例では、PDFファイルになります。

.src/_metadata/ASSET/Document_C/8/0/FSII IES_MDPlayer_
Manual.pdf.FSIIDocumentFile(aa0b47b5-f558-49d4-8a6a-
c2ee012d1b75).IES_MDPlayer_Manual.pdf

注意:

アセットに関連するすべてのファイルは、アセットの名前に基づいているため、アセット名の変更がファイル名の変更につながります。アセットをVCSで追跡している場合は、古い名前のファイルを削除してください。

33.4 コード・ベースのリソース記憶域の構造

テンプレート、CSElement、およびElementCatalogのエントリは、それらのコード・エレメントで必要になるストレージ・パスの下に格納されます。コード・ベースのリソースに関連付けられたJSPファイルは、src/jsp/cs_deployed,の下のワークスペースに格納され、XMLエレメントはsrc/_metadata/ELEMENTSの下に格納されます。コード・ベースのリソースのメタデータ・ファイルは、そのリソースのJSPと同じ名前に拡張子.main.xmlが追加されたファイル名で格納されます。これにより、コード・ベースのリソースのメタデータ・ファイル、JSPファイル、およびXMLファイルは、ワークスペース内でグループ化されます。

33.5 属性エディタ記憶域の構造

属性エディタはアセットとして追跡されますが、ElementCatalogエントリのセットに対する暗黙の参照も含まれています。属性エディタのElementCatalogエントリは、個別に追跡されます。

たとえば、TextAreaエディタは、OpenMarket/Gator/AttributeTypes/TEXTAREA ElementCatalogエントリを使用します(このエントリは、依存性として登録されています)。Developer Toolsは、TextAreaエディタ用に次のファイルを維持します。

- .main.xmlファイル:

src/_metadata/ASSET/AttrTypes/9/10/TextArea(e64f983d-9c7c-489baedb-
476d56f8121e).main.xml

- urlxmlメタデータ・ファイル:

src/_metadata/ASSET/AttrTypes/9/10/TextArea.urlxml(e64f983d-9c7c-
489b-aedb-476d56f8121e).1095346398911.txt

- ElementCatalogエントリ(個別のリソースとして追跡されます):

- ElementCatalogエントリの.main.xmlファイル:

src/_metadata/ELEMENTS/OpenMarket/Gator/AttributeTypes/TEXTAREA
.xml.main.xml

- 属性エディタのエレメント・コード:

src/_metadata/ELEMENTS/OpenMarket/Gator/AttributeTypes/
TEXTAREA.xml

33.6 アセット・タイプ記憶域の構造

アセット・タイプには、メイン・メタデータの部分とエレメントのセットが含まれます。たとえば、Pageアセット・タイプの構造は、次のようになります。

- ページのメイン・メタデータは、.main.xmlファイルに格納されます。

src/_metadata/Asset_Type/Page(b8d8ae9-14cc-4554-b80e-0c22e39a3ec8).main.xml

- 関連エレメントは個別に追跡されます(各エレメントに独自の.main.xmlファイルが存在します)。

src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
SearchForm.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
CheckDelete.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ContentForm.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ContentDetails.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
LoadSiteTree.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexReplace.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
LoadTree.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexAdd.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
SearchForm.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexReplace.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
PreviewPage.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
LoadTree.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
PreUpdate.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
Tile.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
SimpleSearch.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
SimpleSearch.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ContentForm.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
AppendSelectDetailsSE.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
LoadSiteTree.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
AppendSelectDetails.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ManageSchVars.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
PreviewPage.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
CheckDelete.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ManageSchVars.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/
Page/PreUpdate.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
AppendSelectDetails.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexCreateVerity.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
ContentDetails.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
PostUpdate.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexAdd.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
IndexCreateVerity.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
Tile.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
AppendSelectDetailsSE.xml.main.xml
src/_metadata/ELEMENTS/OpenMarket/Xcelerate/AssetType/Page/
PostUpdate.xml.main.xml

34 Developer Toolsコマンドライン・ツールの使用

Developer Toolsのコマンドライン・ツールは、デプロイメントやその他のリソースの移動操作に使用できます。作業対象がDeveloper ToolsのワークスペースにかぎられるEclipse統合とは異なり、コマンドライン・ツールでは、どのワークスペースも作業対象にできます。また、コマンドライン・ツールには、Eclipse IDEでの作業時には使用できないインポート機能とエクスポート機能があります。たとえば、開発者は、任意のサイトにインポート可能なリソースを含むワークスペース(再利用可能なモジュール)を作成できます。

コマンドライン・ツールの実行および使用の詳細は、次の項を参照してください。

- コマンドライン・ツールの実行と使用

- コマンド例

- モジュールのインポートについて

34.1 コマンドライン・ツールの実行と使用

コマンドライン・ツールを実行する手順は次のとおりです。

1. WebCenter Sitesのインストール・ディレクトリ(${Oracle Home}/wcsites/clients)のclientsフォルダにあるdeveloper-tools-command-line-x.y.z.zipファイルを解凍します。

2. developer-tools-command-line-x.y.z.jarファイルを実行し、次のようにJava EEライブラリ(例: サーブレットAPI実装)をクラスパスに含めます。

java -Xbootclasspath/a:lib/servlet-api.jar -jar developer-tools-command-line.jar
http://<hostname>:<port>/<context-path>/ContentServer username=<username> password=<password>
cmd=export|import|listcs|listds [options]

プレースホルダのパラメータは、自分の開発環境に関する情報と、実行する必要のあるコマンドに置き換えてください。

- http://<hostname>:<port>/<context-path>: ローカルのWebCenter SitesインスタンスのURLで、ContentServerサーブレットも含まれます(例: http://localhost:8080/cs/ContentServer)

- usernameとpassword: WebCenter Sitesの一般管理者のユーザー名とパスワードです。このユーザーは、RestAdminグループのメンバーである必要があります(例: fwadmin/xceladmin)。

- cmd: 実行するコマンドです。次のコマンドを使用できます。

- export: WebCenter Sitesからワークスペースにデータをエクスポートします。

- import: ワークスペースからWebCenter Sitesにデータをインポートします。

- listcs: WebCenter Sitesのコンテンツをリストします。

- listds: ワークスペースのコンテンツをリストします

- options: importまたはexportには、次のいずれかを指定します。

- resources: インポートまたはエクスポートするリソースを、リソース・タイプとリソースIDをセミコロンで区切ったリストで指定します。複数のリソースを指定する場合は、カンマ区切りのリストを使用します。特定のタイプのリソースをすべて指定する場合は、*記号を使用します。リソースを(ワークスペースに)エクスポートするには、そのリソースのローカルIDを指定します。たとえば、resources=Content_C:12345;Product_C:*を使用すると、特定のContent_CアセットとすべてのProduct_Cアセットがエクスポートされます。
リソースを(WebCenter Sitesインスタンスに)インポートする場合は、そのリソースのfw_uidを指定します。リソースのfw_uidを取得するには、listdsオプションを使用します。

すべてのリソース・セレクタを次に示します。

@SITE: サイトを指定します。

@ROLE: ロールを指定します。

@ASSET_TYPE: アセット・タイプを指定します。

@TREETAB: ツリー・タブを指定します。

@STARTMENU: スタート・メニュー・アイテムを指定します。

@ELEMENTCATALOG: ElementCatalogエントリを指定します。

@SITECATALOG: サイト・カタログ・エントリを指定します。

@ALL_NONASSETS: この簡略表記を使用すると、すべての非アセット・リソースが選択されます

@ALL_ASSETS: この簡略表記を使用すると、すべての使用可能なアセットが選択されます

asset type: 特定のタイプのアセットを指定します。

注意:

インポートまたはエクスポートの前に、セレクタが適切なリソースを選択するかどうかを確認するには、エクスポート操作にlistcsを使用し、インポート操作にlistdsを使用します。これらのコマンドにより、移動されるリソースのリストを表示して、実行前にセレクタを微調整します。

リソースの依存性は自動的にエクスポートおよびインポートされます。ただし、listcsコマンドおよびlistdsコマンドを使用しても、依存性はリストされません。

- fromSites: 指定したサイトのリソースのみを選択します。

- toSites: (インポート専用)インポート時に、ナチュラル・サイト・アフィリエーションをサイトのカンマ区切りリストでオーバーライドします。指定するサイトは、ターゲット・システムに存在している必要があります。

- modifiedSince: (アセット専用)指定した日付以降に変更されたリソースのみを選択します。日付書式は、yyyy-mm-dd hh:MM:ssです。

- datastore: WebCenter Sitesリソースのエクスポート先にするワークスペース、またはWebCenter Sitesリソースのインポート元にするワークスペースを指定します。このパラメータの値の指定を省略すると、メインDeveloper Toolsワークスペースがデフォルトで指定されます。リソースをエクスポートするときに、指定のワークスペースが存在しない場合は、そのワークスペースがコマンドライン・ツールにより自動的に作成され、リソースがエクスポートされます。

34.2 コマンド例

コマンドライン・ツールを使用して実行できるコマンド例のリストを、次に示します。

- このコマンドは、FirstSiteIIに属しているアセットのうち、指定した日付以降に変更された特定のContent_CアセットとすべてのProduct_Cアセットをエクスポートします。ワークスペースを指定していないため、Developer Toolsワークスペースがデフォルトで使用されます。

java -Xbootclasspath/a:lib/servlet-api.jar -jar developer-tools-command-line-x.y.z.jar http://localhost:8080/cs/ContentServer username=bob password=password resources=Content_C:123432123423,11234234212,111234341234;Product_C:* fromSites=FirstSiteII modifiedSince=2010-08-08 19:14:00 cmd=export

- このコマンドは、ワークスペースに含まれる特定のContent_CアセットとすべてのProduct_Cアセットをインポートします。ワークスペースを指定していないため、Developer Toolsワークスペースがデフォルトで使用されます。

java -Xbootclasspath/a:lib/servlet-api.jar -jar developer-tools-command-line-x.y.z.jar  http://localhost:8080/cs/ContentServer username=bob password=password resources=Content_C:aad618e9-f04e-4ee4-b902-076224bb6f7b;Product_C:* fromSites=FirstSiteII cmd=import

- このコマンドは、サイトSecondSiteIIのすべてのリソースをTheOutputという名前のワークスペースにエクスポートします。

java -Xbootclasspath/a:lib/servlet-api.jar -jar developer-tools-command-line-x.y.z.jar  http://localhost:8080/cs/ContentServer username=bob password=password resources=@ALL_ASSETS:*;@ALL_NONASSETS:*  fromSites=SecondSiteII  datastore=TheOutput cmd=export

- このコマンドは、TheInputという名前のワークスペースに含まれるすべてのアセットとツリー・タブをサイトMySiteにインポートします。

java -Xbootclasspath/a:lib/servlet-api.jar -jar developer-tools-command-line-x.y.z.jar  http://localhost:8080/cs/ContentServer username=bob password=password resources=@ALL_ASSETS:*;@TREETAB:* toSites=MySite  datastore=TheInput cmd=import

34.3 モジュールのインポートについて

モジュールは、WebCenter Sitesインスタンスから特定のワークスペースにエクスポートされる関連リソースのセットです。datastoreパラメータを使用すると、WebCenter Sitesリソースのエクスポート先にするワークスペース、またはWebCenter Sitesリソースのインポート元にするワークスペースを指定できます。存在していないワークスペースにWebCenter Sitesリソースをエクスポートすると、そのワークスペースがコマンドライン・ツールにより自動的に作成され、リソースがエクスポートされます。

モジュールは再利用可能であり、モジュールに含まれるコンテンツは任意のCMサイトにインポートできます(そのサイトが、リソースのサイトに関する正規リストに示されていない場合でもインポートできます)。モジュールをCMサイトにインポートするには、importコマンドを実行する必要があります。datastoreパラメータでは、リソースが含まれているワークスペースを指定し、toSitesパラメータでは、それらのリソースをインポートするサイトを指定します。これにより、ワークスペースのコンテンツは、指定したCMサイトにインポートされます。

35 Developer Toolのワークスペースとバージョン・コントロール・システムとの統合

Developer Toolsワークスペースに含まれるリソースは、バージョン・コントロール・システム(VCS)に保存されます。これらのリソースは、他の開発者とも共有できます。

Developer ToolsワークスペースとVCSとの統合の詳細は、次の項を参照してください。

- バージョン・コントロールとDeveloper Toolsについて

- Developer ToolsとVCSの統合について

- Developer Toolsが統合されたVCSの使用: 例

35.1 バージョン・コントロールとDeveloper Toolsについて

バージョン・コントロール・システム(VCS)は、ソース・コード・リポジトリを作成する機能を提供します。VCSは、ソース・ファイルをバージョニング、ブランチ化および管理するための高度なツールを提供できます。Developer ToolsワークスペースがWebCenter Sitesリソースを格納するファイル・システム構造によって、それらのリソースを任意のVCS上に格納でき、VCS内で完全なCMサイトを追跡できます。

35.2 Developer ToolsとVCSの統合について

Developer Toolsワークスペースは、Eclipseプロジェクトのsrcフォルダにあります。このフォルダには、WebCenter Sitesのインストール・ディレクトリ(export/envision/cs_workspace/srcの下)から直接アクセスできます。Developer ToolsワークスペースのフォルダのコンテンツをVCSにコピーするには、最初に、使用するVCSを決める必要があります。次に、Developer Toolsワークスペースに格納されているリソースをVCSにチェックインします。使用するために選択したVCSによって、Eclipse IDEからのリソースのチェックインに必要な手順が決まります。

使用するために選択したVCSは、リソースをEclipseからVCSに直接チェックインできるプラグインを提供することで、Eclipseによってサポートされる場合があります。たとえば、Subversionリポジトリを使用してDeveloper Toolsワークスペースのコンテンツを格納する場合、Eclipse IDEはSubclipseプラグインをサポートします。そのため、リソースをEclipse IDEからSubversionディレクトリに直接チェックインできます。

Developer Toolsワークスペースは、リソースのタイプに応じて、すべてのリソースを1つ以上のファイルとして格納します。リソースをVCSにチェックインする場合、そのリソースの関連するファイルもすべてチェックインする必要があります。たとえば、添付ドキュメント(PDFなど)を含むアセットは、メタデータ・ファイル(.main.xml)や関連ドキュメント・ファイルで表されます。アセットの関連ファイルはすべてVCSにチェックインする必要があります。そうしないと、チェックインに失敗します。Developer Toolsワークスペースのレイアウトの詳細や、リソースをワークスペースのファイルにマップする方法については、「Developer Toolsのワークスペースの使用」を参照してください。

注意:

Developer ToolsワークスペースからVCSにデータをチェックインする場合、Developer Toolsワークスペースのファイル構造を詳しく理解する必要はありません。かわりに、ほとんどのVCSクライアントは、Developer Toolsワークスペースのフォルダへの増分変更を検出し、それらの変更をVCSコミット操作時に示します。

35.3 Developer Toolsが統合されたVCSの使用: 例

WebCenter SitesのリソースをDeveloper ToolsワークスペースからVCSにチェックインする場合、これらのリソースを他の開発者とやり取りして、時間の経過に伴うリソースへの変更を追跡できます。VCSを使用してWebCenter Sitesのリソースを共有する開発チームの例を次に示します。

開発者AがWebCenter Sitesにリソースを作成し、それをDeveloper Toolsワークスペースにエクスポートします。次に、開発者AはそのリソースをVCSにチェックインします。開発者Bは、そのリソースをVCSから自分のDeveloper Toolsワークスペースにチェックアウトできます。この開発者は、リソースを変更してその変更をVCSにチェックインできます。開発者Aと、開発チームの別の開発者は、リソースに加えられた変更をVCSから確認できます。これにより、開発チームのメンバーは、自分のDeveloper Toolsワークスペースと、リソースに加えられた最新の変更を同期させることができます。また、他の開発者は、リソースをVCSから各自のDeveloper Toolsワークスペースにチェックアウトすることで、グループに参加できます。プロジェクトの進行に応じて、リソースの追加および変更のサイクルも続きます。

注意:

WebCenter Sitesには、指定のWebCenter Sitesインスタンス内で保持される、リソースのリビジョン追跡システムがあります。WebCenter Sitesリビジョン追跡システムは、VCSに統合できません。

36 Developer Toolsを使用したリソースの管理および交換

開発者のチームは、Developer Toolsを使用してCMサイトおよびリソースを作成します。開発チームは、Developer Toolsにより提供される同期ツールを使用して、複数のWebCenter Sitesインスタンス間でリソースの管理および交換を行います。コマンドライン・ツールを使用して、CMサイトとそのリソースをナイトリー・ビルドとしてデプロイします。

このシナリオの詳細は、次の項を参照してください。

- 今日: サイトおよび関連付けられたリソースの開発

- 3日後...デプロイメント

36.1 今日: サイトおよび関連付けられたリソースの開発

次のタスク例には、サイトおよび関連付けられたリソースの開発が含まれます。

午前7時14分: 新しいプロジェクトの割当て

Artie (アーキテクト)が起床し、自分が新しいWebベースのプロジェクトのリーダーに任命されたことを知ります。

午前7時34分: Developer Toolsの設定

Artieはコーヒーを飲み、自分のラップトップにWebCenter Sitesインスタンスをインストールします。その後、Eclipse IDEを起動して、Developer Toolsキットを構成します(図36-1)。

注意:

EclipseとWebCenter Sitesインスタンスを正常に統合するために、Artieは一般管理者のユーザー名とパスワードを入力する必要があります。このユーザーは、RestAdminグループのメンバーである必要があります。

図36-1 Eclipse IDE

午前7時45分: サイト定義の作成

ArtieはEclipseの、組込みのAdminインタフェース・ビューを使用して、サイト定義を作成します(サイトの名前はAcceptanceとします) (図36-2)。

図36-2 サイト定義の作成

Artieは、Adminインタフェースを実行する別のブラウザ・ウィンドウを使用して、サイト定義を作成することもできました。ただし、Artieは相当なEclipseの愛好家なので、Eclipseから離れることなく完全なWebCenter SitesのCMサイトを作成できるという事実に病み付きになっています。

午前7時46分: サイトのリソースの作成

Artieは、次のリソースを使用してサイトに情報を入力します。

- アセット・タイプを有効にします。

- 権限を割り当てます。

- フレックス・ファミリを作成し、有効にして、サイトの情報アセット(このシナリオでは作成者情報アセット)を格納します。

- フレックス属性: Author_A

- フレックス親定義: Author_PD

- フレックス定義: Author_CD

- フレックス親: Author_P

- フレックス・アセット: Author_C

- フレックス・フィルタ: Author_F

- フレックス属性(authorNameおよびauthorBio)とフレックス定義(fictionAuthor)を作成します。次に、属性をフレックス定義に追加します。

図36-3はこの構成を示しています。

図36-3 サイトのリソースの作成

午前8時12分: VCSについての話し合い

Artieはオフィスに着き、開発チームの他のメンバー(プログラマのSonoko、プログラマのMatthäus、システム・エンジニアのYogesh)とミーティングを行います。プロジェクトにバージョン・コントロール・システムを使用するかどうかについて、話し合います。

Yogesh: 社内にバージョン・コントロール・システムを設定することは可能です。でも、余分な作業はしたくありません。バージョン・コントロール・システムは本当に必要なのですか。

Artie: うーん。このプロジェクトは、何か月も続く予定なんだ。そこで、ネットワークに共有フォルダを作って、そこに僕らの作業を全部同期させたいと思うんだ。ただ、お互いの作業を上書きしないように気をつけないといけない。2人のメンバーが同じテンプレート・アセットで作業している場合なんかだと、お互いに待たなければいけないことになるんだ。

Sonoko: Artieさん、憶えてるかしら。前回のプロジェクトでは、終盤に相当ハードな状況になったわよね。他の人の作業が終わるのを待っているなんて、気が滅入ってしまうわよ。こんな管理のプレッシャーを全部抱えているときに。私は断然、バージョン・コントロール・システムを使用する方がよいと思うわ。あと、今回はリポジトリをWeb上に置いて、暇なときにStellarbucksから作業できるようにならないかしら。

Matthäus: Sonokoのいうとおりだよ。SVNホスティングなんて、ただ同然で入手できるんだし。不安があるなら、SVNはSSLでも入手できる。

Yogesh: 社内SVNを設定する時間がない場合でも、SVNホスティングのサブスクリプションくらいは入手できます。

Artie: わかったよ。SVNにしよう。他に何かあるかい。

Artieと開発チームのメンバーは、SVNを使用して、彼らのサイトのリソースを追跡することに決定しました。

午前9時42分: ワークスペースとVCSの同期

Artieと彼のチームは、http://subclipse.tigris.org/からSubclipseプラグインをインストールします。ここで、Artieは、先に作成したサイトとリソースをチェックインする必要があります。

1. Artieは、Eclipseの「Developer Tools Synchronization」を使用して「Export」タブにアクセスし、「Search」フィールドに@Siteセレクタを入力して、自分のWebCenter Sitesインスタンス上にあるすべてのサイトのリストを取得します(図36-4)。

図36-4 WebCenter Sitesインスタンス上のサイトのリスト

Artieは、先に作成したサイト(Acceptanceサイト)を選択し、「Export」ボタンをクリックして、自分のWebCenter Sitesインスタンスからワークスペースに、サイト定義をエクスポートします。

2. 次に、Artieはサイトに関連付けられたフレックス・ファミリをワークスペースにエクスポートします(図36-5)。@ASSET_TYPEセレクタを使用して、自分のWebCenter Sitesインスタンス上にある、すべてのアセットをリストします。結果を絞り込むには、検索文字列Author_を使用します。次に、リストされているすべてのアイテムを選択し、「Export」をクリックします。

図36-5 ワークスペースへのフレックス・ファミリの関連付け

フレックス・ファミリのタイプはワークスペースにシリアライズされます。これには、タイプ固有のElementCatalogエントリも含まれます。

3. ここで、Artieは自分のワークスペースにフレックス定義をエクスポートします(図36-6)。ArtieはAuthor_CDセレクタを使用します。このセレクタは、そのタイプの使用可能な定義をすべてリストします。この場合、定義は1つ(fictionAuthor)のみです。

図36-6 ワークスペースへのフレックス定義のエクスポート

注意:

Artieは、サイト定義が依存するフレックス属性(Author_Aインスタンス)を選択しませんでした。フレックス属性は、Developer Toolsキットによって自動的に定義と同期されることを知っていたからです。

4. Artieは、Eclipseの「Project Explorer」ビューで自分のワークスペースにさっと目を通して、自分の作業内容をすべて確認します(図36-7)。上から下まで見て、次の内容がプロジェクトのsrcフォルダにあることを確認します。

- Artieが同期したアセット・タイプごとの_metadata.ASSET_TYPEエントリ

- 両方のAuthor_A属性の_metadata.ASSET.Author_Aファイル

- シリアライズした定義の_metadata.ASSET.Author_CDファイル

- シリアライズした各アセット・タイプに関連するElementCatalogエントリの_metadata.ELEMENTSエントリ

- サイト定義の_metadata.SITEエントリ

図36-7 「Project Explorer」ビュー内のワークスペース

注意:

Artieは、自分のWebCenter Sitesインストール・ディレクトリのexport/envision/cs_workspaceフォルダで同じデータを確認することもできました。

Artieのワークスペース内には、すべてのリソースがあるように見えます。ただし、これはすべてArtieのラップトップ上にあり、チームはアクセスできません。ここで、チェックインが必要になります。

5. ArtieはSubclipseを使用して開発チームのSVNリポジトリに接続し、自分のメインDeveloper Toolsワークスペースのフォルダ(srcフォルダ)をSVNリポジトリにコミットして、自分のDeveloper Toolsプロジェクトを共有します(図36-8)。

図36-8 SVNへのプロジェクトのコミット

注意:

メインDeveloper Toolsワークスペースは、Eclipseの「Project Explorer」ビューのsrcフォルダにあります。srcフォルダ内にあるファイルのみをコミットします。その他のファイルはすべて補助ローカル・リソースです。これらはコミットしないでください。

午前10時12分: 他のチーム・メンバーのワークスペースとSVNリポジトリの同期

SonokoとMatthäusは、各自のEclipse統合WebCenter Sitesインスタンスの設定を完了したところです。2人は各自のEclipseプロジェクトをSVNリポジトリに接続します。

先にArtieがサイトとそのリソースをSVNリポジトリにチェックインしているため、Subclipseはターゲットの場所が存在していることを検出します(図36-9)。

図36-9 「Remote Project Exists」ダイアログ

SonokoとMatthäusは、自分のメインDeveloper Toolsワークスペースとリソースを同期します。このリソースは、ArtieがSVNリポジトリで使用可能にしたものです。これで、SonokoとMatthäusのメインDeveloper Toolsワークスペースから、それらのリソースにアクセスできるようになります(図36-10)。

図36-10 同期したワークスペース

ただし、リソースはまだ、SonokoやMatthäusのWebCenter Sitesインスタンスと同期されていません。

午前10時18分: ワークスペースとWebCenter Sitesインスタンスの同期

Sonokoは「Developer Tools Synchronization」を開いて、「Import」タブを選択します。SonokoのメインDeveloper Toolsワークスペースに含まれる、すべてのリソースがリストされます。

必要に応じて、Sonokoは最初にサイト定義をインポートし、次にフレックス・ファミリ、その次にアセットを個別にインポートして、次の説明のように実行します。

注意:

Matthäusは、マーケティングとのミーティング終了後に同じ作業を行います。

1. サイト定義(このシナリオではAcceptance)をインポートします。
Sonokoは最初にサイト定義をインポートします。検索フィールドでSite.*Accepta式を使用して、検索を絞り込みます。次に、サイト(Acceptance)を選択し、「Sync to WebCenter Sites」をクリックして、そのサイトと自分のWebCenter Sitesインスタンスを同期します(図36-11)。

図36-11 サイト定義のインポート

Sonokoは「Sites Log」ビューを使用して、サイトが正常にインポートされていることを確認します(図36-12)。

図36-12 サイトのインポートの確認

2. もう一度同期構成を開いて、サイトのフレックス・ファミリをインポートします。インポートはフレックス属性(このシナリオではAuthor_A)から始めます。
SonokoはAcceptanceサイトのフレックス・ファミリを自分のWebCenter Sitesインスタンスで設定しなかったので、まず自分のWebCenter Sitesインスタンスにフレックス属性(Author_A)をインポートする必要があります(図36-13)。フレックス属性をインポートすると、サイトのフレックス・ファミリを構成する残りのアセット・タイプを、自分のWebCenter Sitesインスタンスに同期できます。

図36-13 フレックス属性のインポート

3. 最後の手順として、Sonokoはフレックス定義を同期します。これにより、必要な属性が自動的にインポートされます。
サイトのすべてのリソースのローカル・アセットIDは、新しいWebCenter Sitesインスタンスにインポートされると、再マップされます。これが「Sites Log」ビューに表示されます(図36-14)。

図36-14 フレックス定義の同期

午前10時21分: サイト権限の割当て

Sonokoはリソースと自分のWebCenter Sitesインスタンスの同期した後、自分にサイト権限を割り当てます(図36-15)。これらの権限により、Adminインタフェースから、サイトやそのリソースにアクセスできるようになります。

注意:

新しいサイトのツリー・アプレットにアクセスするために、Sonokoは少なくとも1つのツリー・タブをサイトに割り当てる必要があります。

図36-15 サイト権限の割当て

午前10時22分: スタート・メニューの問題

Sonokoはサイトにログインして、「New」オプションをクリックします。しかし、利用できるスタート・メニュー・アイテムがないことに気付きます(図36-16)。Artieがサイトのスタート・メニュー・アイテムをSVNリポジトリにチェックインしていなかったので、当然です。

図36-16 利用できるスタート・メニュー・アイテムがない

午前10時24分: スタート・メニューの問題の解決

SonokoはArtieに、新しいサイトのスタート・メニュー・アイテムのチェックインを忘れていることを知らせるIMを送ります。

1. Artieはサイトのスタート・メニュー・アイテムを、自分のメインDeveloper Toolsワークスペースと同期します(図36-17)。

図36-17 Developer Toolsワークスペースへのスタート・メニュー・アイテムの同期

2. 次に、Artieはサイトのスタート・メニュー・アイテムをSVNリポジトリにチェックインします(図36-18)。

図36-18 SVNへのスタート・メニュー・アイテムのコミット

3. Sonokoは、Artieがスタート・メニュー・アイテムをSVNにコミットしたことに気付きます。Sonokoは自分のEclipseプロジェクトを更新します。SVNリポジトリにアクセスして、スタート・メニュー・アイテムを自分のメインDeveloper Toolsワークスペースに同期します。次に、これらのスタート・メニュー・アイテムを、自分のWebCenter Sitesインスタンスにインポートします(図36-19)。

図36-19 次に、WebCenter Sitesインスタンスへのスタート・メニュー・アイテムのインポート

4. Sonokoは自分のWebCenter Sitesインスタンスを再起動しないで、「Search」をクリックします。
自分のWebCenter Sitesインスタンスにインポートしたスタート・メニュー・アイテムがリストされます(図36-20)。

図36-20 スタート・メニュー・アイテムのリスト

午前11時17分: マーケティング・リクエストの変更

Subject: Proposed Author Definition Changes

Date: Wed, 16 Feb 2011 11:17:39

From: matthäus.companynone.com

To: Tech-Development

Team,

I just synchronized your changes into my system. As per my meeting with Marketing, we must have date of birth and birthplace attributes in the Author Definition. I noticed these attributes do not exist, so I will add them. Artie, can you review the changes I make when you have the chance?

Regards,

Matthäus

午前11時22分: Author定義への新しい属性の追加

Matthäusは、マーケティングからリクエストされた属性を作成し、それらをフレックス定義(このシナリオではAuthor定義)に追加します。次に、新しい属性とフレックス定義を自分のメインDeveloper Toolsワークスペースにエクスポートして、それらをSVNリポジトリにコミットします(図36-21)。

図36-21 新しい属性とフレックス定義のエクスポート

午前11時25分: サイトへの変更の確認

Artieは、変更されたAuthor定義をSVNから取得して、自分のWebCenter Sitesインスタンスにインポートします(図36-22)。

図36-22 サイトへの変更の確認

Subject: RE: Proposed Author Definition Changes

Date: Wed, 16 Feb 2011 11:37:31

From: artie.companynone.com

To: matthäus.companynone.com

Matthäus,

Thank you for taking care of this. Corporate standards require us to capitalize the first letter of each subsequent word. I will delete the birthplace attribute and add birthPlace instead.

Thank you,

Artie

午前11時44分: Author定義の属性の変更

1. ArtieはbirthPlace属性を作成して、フレックス定義に追加します。次に、元のbirthplace属性をサイト定義から削除します。

2. Artieは、新しい属性とAuthor定義の変更をSVNリポジトリにコミットします。次に、birthplace属性のステータスがVOになっていることを確認します。これは属性が無効であることを示します。
SonokoとMatthäusが自分のWebCenter Sitesインスタンスを更新すると、それに応じて、birthplace属性がSonoko達のワークスペースで無効になります(図36-23)。

図36-23 Author定義の属性の変更

午前11時53分: チームのワークスペースとWebCenter Sitesインスタンスの更新

1. SonokoとMatthäusは、自分のメインDeveloper Toolsワークスペースを、ArtieがSVNリポジトリにチェックインしたリソースで更新します。

2. 次に、「Import」タブを開いて、自分のワークスペースのリソースを、各自のWebCenter Sitesインスタンスにインポートします(図36-24)。使い勝手がよいように、リソースは「Modified Date」列でソートしておきます。これで、最新の変更が一番上に表示されます。
無効の属性(Artieが無効にしたbirthplace属性など)の「Name」列には、ステータスのヒント(status=VO)が表示されます。

図36-24 ワークスペースとWebCenter Sitesインスタンスの更新

3. SonokoとMatthäusは、自分のワークスペースから各自のWebCenter Sitesインスタンスに、これらの変更をインポートします。これで、ワークスペースとWebCenter Sitesインスタンスは最新の状態になります。

午後12時27分: サイトのテンプレート・アセットの作成

1. (午後12時27分) Matthäusはサイトの「Welcome」ページのテンプレート・アセットを作成します(図36-25)。

図36-25 サイトのテンプレート・アセットの作成

2. (午後12時34分) Matthäusはテンプレート・アセットを編集し、変更を「Sites Preview Browser」ビューでプレビューします。テンプレート・アセットのJSPに加えた変更を保存し、すぐにキーボード・コマンドの[Ctrl] + [R]を使用してプレビュー・ブラウザを更新します(図36-26)。

図36-26 「Sites Preview Browser」の編集

3. (午後12時39分) Matthäusはテンプレートの.jspファイルと.main.xmlファイルをSVNリポジトリにコミットします(図36-27)。
Subclipseはプロジェクトの変更をすべて検出し、それらの変更を開発者に提示します。テンプレート・アセット以外に新しいアセットがないため、Matthäusは、.main.xmlファイルがテンプレートのメタデータであり、JSPファイルがテンプレートのコードであると推測できます。

図36-27 コミットしたテンプレート・ファイル

4. (午後12時44分) Sonokoは自分のワークスペースで、テンプレートのJSPファイルを一部修正します(図36-28).。

図36-28 ワークスペース内のテンプレートのJSPファイルの編集

5. SonokoはJSPファイルの変更を確認し、その変更をSVNにコミットします(図36-29)。

図36-29 SVNへの変更のコミット

注意:

万一、Sonokoと同時に別のチーム・メンバーがこのファイルを修正してチェックインすると、SVNからSonokoに対して、別バージョンのファイルがすでにチェックインされていることが通知されます。Sonokoはそれらの変更を自分の変更と統合して、想定外の上書きを回避できます。

36.2 3日後...デプロイメント

Yogeshはコマンドライン・ツールを使用してサイトをデプロイします。この項で使用するコマンドについては、「Developer Toolsのコマンドライン・ツールの使用」を参照してください。

午前9時32分: デプロイメントの準備

Yogeshはテスト環境の設定を開始し、コマンドライン・ツールを使用して、現在のビルドのデプロイを準備しています。彼は本番で使用される環境に適したWebCenter Sitesシステムをハードウェアにインストールしました。

Developer Toolsのインポートを、完全に自動化されたナイトリー・スクリプトに追加する前にテストする手順は次のとおりです。:

1. Yogeshはコマンドライン・ツールを使用してAcceptanceサイトとそのリソースをSVNからチェックアウトし、ターゲットのWebCenter Sitesインスタンスのワークスペースにチェックインします。
コマンド:

## go to the workspace location under export/envision/
cs_workspace in the ${sites-shared}/config directory

## checkout site from svn
${sites-shared}/config/export/envision/cs_workspace$ svn checkout   svn://
yoursvnhost/projects/mysite/src

出力:

A    mysite/src
A    mysite/src/_metadata
A    mysite/src/_metadata/ASSET
A    mysite/src/_metadata/ASSET/Author_A
A    mysite/src/_metadata/ASSET/Author_A/10
A    mysite/src/_metadata/ASSET/Author_A/10/14
A    mysite/src/_metadata/ASSET/Author_A/10/14/authorName(cbf4d8aa-d23a-4f0d-b55d-a87a0e9bbf33).main.xml
A    mysite/src/_metadata/ASSET/Author_A/11
A    mysite/src/_metadata/ASSET/Author_A/11/79
A    mysite/src/_metadata/ASSET/Author_A/11/79/birthPlace(42afd458-e90c-4e18-a4b6-47d322b46414).main.xml
A    mysite/src/_metadata/ASSET/Author_A/5
A    mysite/src/_metadata/ASSET/Author_A/5/64
A    mysite/src/_metadata/ASSET/Author_A/5/64/birthplace(49d63312-c74d-4ccd-bb7f-4dc698a9da22).main.xml
A    mysite/src/_metadata/ASSET/Author_A/15
A    mysite/src/_metadata/ASSET/Author_A/15/76
A    mysite/src/_metadata/ASSET/Author_A/15/76/DOB(9fe04c6e-36e7-4ee3-8c76-8c02edf74136).main.xml
A    mysite/src/_metadata/ASSET/Author_A/71
A    mysite/src/_metadata/ASSET/Author_A/71/74
A    mysite/src/_metadata/ASSET/Author_A/71/74/authorBio(ada2d6be-ef14-4766-b446-911bfa838835).main.xml
A    mysite/src/_metadata/ASSET/Author_CD
A    mysite/src/_metadata/ASSET/Author_CD/76
A    mysite/src/_metadata/ASSET/Author_CD/76/4
A    mysite/src/_metadata/ASSET/Author_CD/76/4/fictionAuthor(71d6067b-35f6-47f4-ae97-3876303abb37).main.xml
A    mysite/src/_metadata/ASSET_TYPE
A    mysite/src/_metadata/ASSET_TYPE/Author_F(5f9b4964-e9be-4f25-a413-877e8a5c7469).main.xml
A    mysite/src/_metadata/ASSET_TYPE/Author_P(1552d907-5f38-400b-9460-36e46d14abc3).main.xml
A    mysite/src/_metadata/ASSET_TYPE/Author_A(162d0b70-7e69-4266-acca-2f472e3d71bd).main.xml
A    mysite/src/_metadata/ASSET_TYPE/Author_CD(33faf87e-9e8f-4f49-97cd-424810408938).main.xml
A    mysite/src/_metadata/ASSET_TYPE/Author_PD(7c748df3-d149-4b71-802a-64b11360e74b).main.xml
A    mysite/src/_metadata/ASSET_TYPE/Author_C(d1497b50-665c-4b0c-80a7-d25f61566be4).main.xml
A    mysite/src/_metadata/STARTMENU
A    mysite/src/_metadata/STARTMENU/Find+Author+Attribute(2f6b2552-efde-493b-995f-ff13287f95e0).main.xml
...

2. Yogeshはワークスペースのリスト(cmd=listds)を実行して、サイトとそのリソースがすべてWebCenter Sitesインスタンスにインポートされることを確認します。@ALL_ASSETSと@ALL_NONASSETSセレクタを使用して、ワークスペースにあるアセット・リソースと非アセット・リソースすべてのリストを生成します。

- @ALL_ASSETSセレクタを使用するためのコマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@ALL_ASSETS cmd=listds

出力:

Resource Type |||    Resource Id   |||    Name     |||
Description   ||| Modified On
-----------------------------------------------------------------
Author_A ||| cbf4d8aa-d23a-4f0d-b55d-a87a0e9bbf33 ||| authorName
( status=ED ) ||| author name ||| 2011-02-17 15:26:34.000
Author_A ||| 42afd458-e90c-4e18-a4b6-47d322b46414 ||| birthPlace
( status=PL ) ||| place of birth ||| 2011-02-17 15:26:34.000
Author_A ||| 9fe04c6e-36e7-4ee3-8c76-8c02edf74136 ||| DOB
( status=PL ) ||| date of birth ||| 2011-02-17 15:26:34.000
Author_CD ||| 71d6067b-35f6-47f4-ae97-3876303abb37 |||
fictionAuthor ( status=ED ) ||| authors who write fiction |||
2011-02-17 15:26:34.000
Author_A ||| ada2d6be-ef14-4766-b446-911bfa838835 ||| authorBio
( status=ED ) ||| author biography ||| 2011-02-17 15:26:34.000
Author_A ||| 49d63312-c74d-4ccd-bb7f-4dc698a9da22 ||| birthplace
( status=VO ) ||| author birthplace ||| 2011-02-17 15:12:43.000
Template ||| 89b05c0f-227b-4dcb-961e-2ab6e6af2dae ||| welcome
(Typeless status=PL) ||| welcome page ||| 2011-02-17 23:18:18.000

- @ALL_NONASSETSセレクタを使用するためのコマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@ALL_NONASSETS cmd=listds

出力:

Resource Type |||    Resource Id   |||    Name     |||
Description  ||| Modified On
-----------------------------------------------------------------
@STARTMENU ||| 66edea6d-218e-41b7-b5ac-ec3453bd53b7 ||| New
Author ( ) ||| null ||| 2011-02-18 11:02:23.000
@STARTMENU ||| c416c0d6-98a7-4ebf-babb-78d0699698de ||| Find
Author Filter ( ) ||| null ||| 2011-02-18 11:02:23.000
@ASSET_TYPE ||| 162d0b70-7e69-4266-acca-2f472e3d71bd ||| Author_A
( ) ||| Author Attribute ||| 2011-02-18 11:02:23.000
@STARTMENU ||| 2821ef28-39a2-4008-9a94-296fc0fd4f29 ||| Find
Author Definition ( ) ||| null ||| 2011-02-18 11:02:23.000
@STARTMENU ||| d45be3de-a8e0-4479-a909-f79e9320e84f ||| Find
Author ( ) ||| null ||| 2011-02-18 11:02:23.000
@STARTMENU ||| 2f6b2552-efde-493b-995f-ff13287f95e0 ||| Find
Author Attribute ( ) ||| null ||| 2011-02-18 11:02:23.000
@ASSET_TYPE ||| 7c748df3-d149-4b71-802a-64b11360e74b ||| Author_
PD ( ) ||| Author Parent Def ||| 2011-02-18 11:02:23.000
@STARTMENU ||| 208aee2a-ad16-433a-9ee8-6658ce8f3abf ||| New
Author Attribute ( ) ||| null ||| 2011-02-18 11:02:23.000
@STARTMENU ||| 8428e490-b99c-4bea-b5a1-1c1768fa9d7d ||| Find
Author Parent ( ) ||| null ||| 2011-02-18 11:02:23.000
@ASSET_TYPE ||| d1497b50-665c-4b0c-80a7-d25f61566be4 ||| Author_C
( ) ||| Author ||| 2011-02-18 11:02:23.000
…

3. 次にYogeshは、@ASSET_TYPE:*セレクタを使用して、必要なアセット・タイプがすべてインポートされることを確認します。
コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@ASSET_TYPE:* cmd=listds

出力:

Resource Type |||    Resource Id   |||    Name     |||   Description   ||| Modified On
----------------------------------------------------------------------------------------
Author_A ||| cbf4d8aa-d23a-4f0d-b55d-a87a0e9bbf33 ||| authorName ( status=ED ) ||| author name ||| 2011-02-17 15:26:34.000
Author_A ||| 42afd458-e90c-4e18-a4b6-47d322b46414 ||| birthPlace ( status=PL ) ||| place of birth ||| 2011-02-17 15:26:34.000
Author_A ||| 9fe04c6e-36e7-4ee3-8c76-8c02edf74136 ||| DOB ( status=PL ) ||| date of birth ||| 2011-02-17 15:26:34.000
Author_CD ||| 71d6067b-35f6-47f4-ae97-3876303abb37 ||| fictionAuthor ( status=ED ) ||| authors who write fiction ||| 2011-02-17 15:26:34.000
Author_A ||| ada2d6be-ef14-4766-b446-911bfa838835 ||| authorBio ( status=ED ) ||| author biography ||| 2011-02-17 15:26:34.000
Author_A ||| 49d63312-c74d-4ccd-bb7f-4dc698a9da22 ||| birthplace ( status=VO ) ||| author birthplace ||| 2011-02-17 15:12:43.000
Template ||| 89b05c0f-227b-4dcb-961e-2ab6e6af2dae ||| welcome (Typeless status=PL) ||| welcome page ||| 2011-02-17 23:18:18.000

4. Yogeshは、サイトに必要なリソースがすべてビルドにインポートされることを確認します。

午前10時04分: サイトとそのリソースのデプロイ

Yogeshはコマンドライン・ツールを使用して、インポート・シーケンスを実行します。

1. 最初にサイトをインポートします。
コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@SITE:Acceptance cmd=import

出力:

*** Importing batch 1297868431526
Importing DSKEY @SITE-Acceptance (batch 1297868431526)
Saved Acceptance (batch 1297868431526)
*** Completed importing batch 1297868431526

2. 次にフレックス・ファミリをインポートします。
コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@ASSET_TYPE:* cmd=import

出力:

*** Importing batch 1298064678765
Importing DSKEY @ASSET_TYPE-162d0b70-7e69-4266-acca-2f472e3d71bd (batch 1298064678765)
Importing DSKEY @ELEMENTCATALOG-OpenMarket/Xcelerate/AssetType/Author_A/LoadTree (batch 1298064678765)
Saved OpenMarket/Xcelerate/AssetType/Author_A/LoadTree (batch 1298064678765)
…

3. 次にアセットをインポートします。
コマンド:

${sites-shared}/config/export/envision/cs_workspace
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@ALL_ASSETS cmd=import

出力:

*** Importing batch 1298064679760
Importing DSKEY Author_A-cbf4d8aa-d23a-4f0d-b55d-a87a0e9bbf33 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1295889071437 (batch 1298064679760)
Importing DSKEY Author_A-42afd458-e90c-4e18-a4b6-47d322b46414 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1295889071441 (batch 1298064679760)
Importing DSKEY Author_A-9fe04c6e-36e7-4ee3-8c76-8c02edf74136 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1295889071445 (batch 1298064679760)
Importing DSKEY Author_CD-71d6067b-35f6-47f4-ae97-3876303abb37 (batch 1298064679760)
Importing DSKEY Author_A-ada2d6be-ef14-4766-b446-911bfa838835 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1295889071449 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_C already exists, skipping.
Dependency @ASSET_TYPE-Author_P already exists, skipping.
Dependency @ASSET_TYPE-Author_CD already exists, skipping.
Dependency @ASSET_TYPE-Author_PD already exists, skipping.
Dependency @ASSET_TYPE-Author_F already exists, skipping.
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_CD:1295889071453 (batch 1298064679760)
Importing DSKEY Author_A-49d63312-c74d-4ccd-bb7f-4dc698a9da22 (batch 1298064679760)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1295889071460 (batch 1298064679760)
Importing DSKEY Template-89b05c0f-227b-4dcb-961e-2ab6e6af2dae (batch 1298064679760)
Saved Template:1295889071461 (batch 1298064679760)
*** Completed importing batch 1298064679760

4. これは配布インストールです。そのため、スタート・メニュー・アイテムはオプションになります。ただし、Yogeshはスタート・メニュー・アイテムをインポートします。Adminインタフェースを使用して、すべてのリソースが正常にインポートされることを確認するためです。
コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@STARTMENU:* cmd=import

出力:

*** Importing batch 1298064681075
Importing DSKEY @STARTMENU-66edea6d-218e-41b7-b5ac-ec3453bd53b7 (batch 1298064681075)
Saved 1297720502210 (batch 1298064681075)
Importing DSKEY @STARTMENU-c416c0d6-98a7-4ebf-babb-78d0699698de (batch 1298064681075)
Saved 1297720502230 (batch 1298064681075)
Importing DSKEY @STARTMENU-2821ef28-39a2-4008-9a94-296fc0fd4f29 (batch 1298064681075)
Saved 1297720502222 (batch 1298064681075)
Importing DSKEY @STARTMENU-d45be3de-a8e0-4479-a909-f79e9320e84f (batch 1298064681075)
Saved 1297720502206 (batch 1298064681075)
Importing DSKEY @STARTMENU-2f6b2552-efde-493b-995f-ff13287f95e0 (batch 1298064681075)
Saved 1297720502214 (batch 1298064681075)
Importing DSKEY @STARTMENU-208aee2a-ad16-433a-9ee8-6658ce8f3abf (batch 1298064681075)
Saved 1297720502218 (batch 1298064681075)
Importing DSKEY @STARTMENU-8428e490-b99c-4bea-b5a1-1c1768fa9d7d (batch 1298064681075)
Saved 1297720502238 (batch 1298064681075)
Importing DSKEY @STARTMENU-2d31208a-4053-4fc1-a0d4-3789b23bd897 (batch 1298064681075)
Saved 1297720502226 (batch 1298064681075)
Importing DSKEY @STARTMENU-480cc5d1-3e73-4a92-85ef-48d0e44b81ef (batch 1298064681075)
Saved 1297720502242 (batch 1298064681075)
Importing DSKEY @STARTMENU-84309e2b-54ed-4e08-9244-84d331a60742 (batch 1298064681075)
*** Completed importing batch 1298064681075

午前10時55分: デプロイメントの成功

Yogeshは、インポート・シーケンスが成功したと判断します。彼は次のスクリプトを記述して、このシステムへの毎日のインストールが自動的に実行されるよう計画します。

## Reinstall ContentServer to start with a clean slate.
## Optionally skip this and just do an update
Reinstall_CS()

## Bring in the latest source from SVN
SVN_Update()

## Prepare for import: compile any Java code such as url assemblers and flex filters, and so on.
## Prepare the database with any custom settings, and so on.
preImport()

## Run the CSDT import sequence
CSDT_Import()

## Run the test suite – sanity, performance, acceptance tests
runTestSuite()

## Report results to the team by email so they know about any failures first thing in the morning
runReports()

このスクリプトはcronジョブとして、毎晩0時5分に実行されます。

37 Developer Toolsのコマンドライン・ツールを使用した再利用可能モジュールの作成

Developer Toolsキットを使用すると、モジュールの形式でリソースを再利用および共有できるようになります。モジュールは、サイトに固有ではないワークスペースです。このワークスペースには、テンプレート、フレックス・ファミリ、ElementCatalogエントリなどのリソースが含まれています。ナチュラル・マッピングを使用してアセットがサイトに追加される標準のエクスポート/インポートとは異なり、モジュールでは、どのサイトにでもインポートできるように、通常はサイトのオーバーライドを使用します。

Developer Toolsのコマンドライン・ツールの詳細は、次の項を参照してください。

- 再利用可能なモデルの作成

- WebCenter Sitesインスタンスでのリソースのリスト

- スタート・メニュー・アイテムのリスト

- ワークスペースへのすべてのリソースのエクスポート

- モジュールのコンテンツの調査

- モジュールのアーカイブ

- WebCenter Sitesインスタンスへのモジュールのインポート

37.1 再利用可能なモデルの作成

Artieはフレックス定義のあるフレックス・ファミリを所有しています。このフレックス定義は、他のサイトで再利用する予定です。また、そのフレックス定義に関連付られたテンプレート・アセットも所有しています。次のシナリオでは、Artieがこれらのリソースを含むモジュールを作成します。このシナリオでは、コマンドライン・ツールを使用して、Artieとチームが「Developer Toolsを使用したリソースの管理および交換」で開発したリソースを含むモジュールを作成します。

注意:

コマンドライン・ツールを使用するために、Artieはコマンドを実行するたびに、一般管理者のユーザー名とパスワードを指定する必要があります。このユーザーは、RestAdminグループのメンバーである必要があります。このシナリオでは、Artieはfwadmin/xceladminを使用します。

次の項を参照してください。

- WebCenter Sitesインスタンスでのリソースのリスト

- スタート・メニュー・アイテムのリスト

- ワークスペースへのすべてのリソースのエクスポート

- モジュールのコンテンツの調査

- モジュールのアーカイブ

- WebCenter Sitesインスタンスへのモジュールのインポート

37.2 WebCenter Sitesインスタンスでのリソースのリスト

Artieはコマンドライン・ツールを使用して、自分のWebCenter Sitesインスタンスを参照します。resources=@ALL_ASSETSセレクタとfromSites=Acceptanceセレクタを使用して、Artieは「Acceptance」サイトのすべてのアセットをリストします。Artieはlistcsコマンドを使用して、自分のWebCenter Sitesインスタンス上のリソースをすべてリストします。

コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@ALL_ASSETS fromSites=Acceptance cmd=listcs

出力:

Resource Type ||| Resource Id ||| Name ||| Description ||| Modified On
--------------------------------------------------------------------------------
Author_CD ||| 1297720502271 ||| fictionAuthor (status=ED) ||| authors who write fiction ||| 2011-02-17 15:10:41
Author_A ||| 1297720502260 ||| authorName (status=ED) ||| author name ||| 2011-02-17 14:46:40
Author_A ||| 1297720502265 ||| authorBio (status=ED) ||| author biography ||| 2011-02-17 14:46:40
Author_A ||| 1297720502289 ||| 1297720502289 (status=VO) ||| author birthplace ||| 2011-02-17 15:12:35
Author_A ||| 1297720502293 ||| DOB (status=PL) ||| date of birth ||| 2011-02-17 14:46:40
Author_A ||| 1297720502305 ||| birthPlace (status=PL) ||| place of birth ||| 2011-02-17 15:10:22
Template ||| 1297720502331 ||| welcome (Typeless, status=ED) ||| welcome page ||| 2011-02-17 23:18:18

Artieは、5つのAuthor_Aフレックス属性インスタンス(そのうちの1つは無効)と1つのAuthor_CDフレックス定義、および1つのテンプレート・アセットがあることを確認します。

37.3 スタート・メニュー・アイテムのリスト

Artieはもう一度コマンドライン・ツールを使用して、「Acceptance」サイトに割り当てられたスタート・メニュー・アイテムを参照します。

コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@STARTMENU:* fromSites=Acceptance cmd=listcs

出力:

Resource Type ||| Resource Id ||| Name ||| Description ||| Modified On
--------------------------------------------------------------------------------
@STARTMENU ||| 1297720502206 ||| Find Author ||| null ||| -
@STARTMENU ||| 1297720502214 ||| Find Author Attribute ||| null ||| -
@STARTMENU ||| 1297720502222 ||| Find Author Definition ||| null ||| -
@STARTMENU ||| 1297720502230 ||| Find Author Filter ||| null ||| -
@STARTMENU ||| 1297720502238 ||| Find Author Parent ||| null ||| -
@STARTMENU ||| 1297720502246 ||| Find Author Parent Def ||| null ||| -
@STARTMENU ||| 1297720494070 ||| Find CSElement, FirstSiteII ||| Find CSElement ||| -
@STARTMENU ||| 1297720494086 ||| Find Page, FirstSiteII ||| Find Page ||| -
@STARTMENU ||| 1297720494078 ||| Find SiteEntry, FirstSiteII ||| Find SiteEntry ||| -
@STARTMENU ||| 1297720494066 ||| Find Template, FirstSiteII ||| Find Template ||| -
@STARTMENU ||| 1297720502210 ||| New Author ||| null ||| -
@STARTMENU ||| 1297720502218 ||| New Author Attribute ||| null ||| -
@STARTMENU ||| 1297720502226 ||| New Author Definition ||| null ||| -
@STARTMENU ||| 1297720502234 ||| New Author Filter ||| null ||| -
@STARTMENU ||| 1297720502242 ||| New Author Parent ||| null ||| -
@STARTMENU ||| 1297720502250 ||| New Author Parent Def ||| null ||| -
@STARTMENU ||| 1297720501427 ||| New CSElement ||| null ||| -
@STARTMENU ||| 1297720494052 ||| New Page, FirstSiteII ||| New Page ||| -
@STARTMENU ||| 1297720501431 ||| New SiteEntry ||| null ||| -
@STARTMENU ||| 1297720501435 ||| New Template ||| null ||| -

37.4 ワークスペースへのすべてのリソースのエクスポート

Artieは、「WebCenter Sitesインスタンスでのリソースのリスト」および「スタート・メニュー・アイテムのリスト」にリストされているすべてのリソースを使用してモジュールを作成したいと考えています。このため、次のコンテンツを実行して、指定されたワークスペースにすべてのリソースを一度にエクスポートします。

コマンド:

${sites-shared}/config/export/envision/cs_workspace$
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@STARTMENU:*;@ALL_ASSETS fromSites=Acceptance cmd=export
datastore=authorModule

出力:

*** Exporting batch 1298385511005
Exporting ASSETDATA Author_CD:1297720502271 (batch 1298385511005)
Exporting ASSETDATA Author_A:1297720502260 (batch 1298385511005)
Exporting ASSET_TYPE Author_A (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/LoadSiteTree (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetails (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetailsSE (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/IndexAdd (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/IndexReplace (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/IndexCreateVerity (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/ContentDetails (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/ContentForm (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/PostUpdate (batch 1298385511005)
Exporting ELEMENTCATALOG OpenMarket/Xcelerate/AssetType/Author_A/PreUpdate (batch 1298385511005)
...

エクスポートには、フレックス・ファミリのアセット・タイプがすべて含まれています。また、これらのタイプに属するエレメントもすべて含まれています。この情報は通常変更されませんが、Artieが作成しているモジュールを別のWebCenter Sitesインスタンスで再利用可能にするために必要になります。

37.5 モジュールのコンテンツの調査

Artieは、自分のファイル・システムのauthorModuleワークスペースを調べます(図37-1)。

図37-1 authorModule

Artieは自分のファイル・システムのワークスペースに、テンプレート・アセット、フレックス・ファミリのメンバー、アセット・タイプおよびスタート・メニュー・アイテムがすべてエクスポートされていることを確認します。

37.6 モジュールのアーカイブ

ArtieはauthorModuleワークスペースの.zipファイル・アーカイブを作成して、そのアーカイブを保存します。

37.7 WebCenter Sitesインスタンスへのモジュールのインポート

Artieは、FirstSiteIIサンプル・サイトにモジュールをインポートすることにしました。

1. Artieは、ターゲットのWebCenter Sitesインスタンスの、ワークスペースの場所にモジュールを解凍します(図37-2)。

図37-2 ワークスペースの場所内のauthorModule

2. コマンドライン・ツールを使用して、Artieはアセット・タイプとスタート・メニュー・アイテムを、ターゲットのWebCenter Sitesインスタンスにインポートします。

コマンド:

${sites-shared}/config/JSKdemo/ContentServer>
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<hots>:<port>/
<context>/ContentServer username=fwadmin password=xceladmin
resources=@ALL_NONASSETS cmd=import datastore=authorModule
toSites=FirstSiteII

出力:

*** Importing batch 1298052933085
Importing DSKEY @STARTMENU-4340b65d-a9e4-4131-ac7f-51185a79b18d (batch 1298052933085)
Saved 1297720494070 (batch 1298052933085)
Importing DSKEY @STARTMENU-0a2decd4-b6be-418c-9992-a4332480bb20 (batch 1298052933085)
Saved 1297720501435 (batch 1298052933085)
Importing DSKEY @STARTMENU-66edea6d-218e-41b7-b5ac-ec3453bd53b7 (batch 1298052933085)
Saved 1297720502210 (batch 1298052933085)
Importing DSKEY @STARTMENU-c416c0d6-98a7-4ebf-babb-78d0699698de (batch 1298052933085)
Saved 1297720502230 (batch 1298052933085)
Importing DSKEY @ASSET_TYPE-162d0b70-7e69-4266-acca-2f472e3d71bd (batch 1298052933085)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Importing DSKEY @ELEMENTCATALOG-OpenMarket/Xcelerate/AssetType/Author_A/LoadSiteTree (batch 1298052933085)
Saved OpenMarket/Xcelerate/AssetType/Author_A/LoadSiteTree (batch 1298052933085)
Importing DSKEY @ELEMENTCATALOG-OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetails (batch 1298052933085)
Saved OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetails (batch 1298052933085)
Importing DSKEY @ELEMENTCATALOG-OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetailsSE (batch 1298052933085)
Saved OpenMarket/Xcelerate/AssetType/Author_A/AppendSelectDetailsSE (batch 1298052933085)
Importing DSKEY @ELEMENTCATALOG-OpenMarket/Xcelerate/AssetType/Author_A/IndexAdd (batch 1298052933085)
Saved OpenMarket/Xcelerate/AssetType/Author_A/IndexAdd (batch 1298052933085)
...

3. Artieは、FirstSiteIIサンプル・サイトのAdminインタフェースを開き、アセット・タイプとスタート・メニュー・アイテムが正常にインポートされていることを確認します(図37-3)。

図37-3 FirstSiteIIのスタート・メニュー

4. ここでArtieは、アセットをインポートします。

コマンド:

${sites-shared}/config/JSKdemo/ContentServer>
java - Xbootclasspath/a:lib/servlet-api.jar -jar
developer-tools-command-line.jar http://<host><:port>/
<context>/ContentServer username=fwadmin
password=xceladmin resources=@ALL_ASSETS cmd=import datastore=authorModule
toSites=FirstSiteII

出力:

*** Importing batch 1298480206533
Importing DSKEY Author_A-cbf4d8aa-d23a-4f0d-b55d-a87a0e9bbf33 (batch 1298480206533)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1297837451977 (batch 1298480206533)
Importing DSKEY Author_A-42afd458-e90c-4e18-a4b6-47d322b46414 (batch 1298480206533)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1297837451981 (batch 1298480206533)
Importing DSKEY Author_A-9fe04c6e-36e7-4ee3-8c76-8c02edf74136 (batch 1298480206533)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1297837451985 (batch 1298480206533)
Importing DSKEY Author_CD-71d6067b-35f6-47f4-ae97-3876303abb37 (batch 1298480206533)
Importing DSKEY Author_A-ada2d6be-ef14-4766-b446-911bfa838835 (batch 1298480206533)
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_A:1297837451989 (batch 1298480206533)
Dependency @ASSET_TYPE-Author_C already exists, skipping.
Dependency @ASSET_TYPE-Author_P already exists, skipping.
Dependency @ASSET_TYPE-Author_CD already exists, skipping.
Dependency @ASSET_TYPE-Author_PD already exists, skipping.
Dependency @ASSET_TYPE-Author_F already exists, skipping.
Dependency @ASSET_TYPE-Author_A already exists, skipping.
Saved Author_CD:1297837451993 (batch 1298480206533)
Importing DSKEY Template-89b05c0f-227b-4dcb-961e-2ab6e6af2dae (batch 1298480206533)
Saved Template:1297837452000 (batch 1298480206533)
*** Completed importing batch 1298480206533

5. Artieは、FirstSiteIIサンプル・サイトにフレックス定義が正常にインポートされていることを確認します(図37-4)。

図37-4 Author定義の調査

6. コマンドライン・ツールを使用して、Artieはテンプレート・アセットをインポートします。次に、もう一度Adminインタフェースを開き、テンプレート・アセットが正しくインポートされていることを確認します(図37-5)。

図37-5 テンプレートの初期画面

モジュール全体が、FirstSiteIIサンプル・サイトに正常にインポートされています。このモジュールは再利用可能であり、任意のWebCenter Sitesインスタンスにインポートできます。

第VI部 キャッシングの管理

この部は、WebCenter Sitesのキャッシングの仕組みの説明から始めます。ここでは、結果セットのキャッシングについて、および結果セットのキャッシングとキャッシュからの結果セットのフラッシュを正確に行う方法について説明します。次に、レンダリング・エンジン・キャッシュとそのコンポーネントについて説明します。また、すべてのキャッシュをクリアするためにCacheManagerを有効にする方法についても説明します。最後に、レンダリングされたオブジェクトのキャッシングがWebCenter Sitesプラットフォームでどのように行われるかについて説明します。

次の項で、キャッシングについて説明します。

- ページのデザインとキャッシングの理解

- 結果セットのキャッシングと問合せでの作業

- WebCenter Sitesでのキャッシュ管理の使用

- ページ・キャッシングの高度な手法の使用

38 ページのデザインとキャッシングの理解

Webページをキャッシュすると、サイトのパフォーマンスを向上させることができます。サイトが静的か動的かに関係なく、指定されたページの一部または全体がキャッシングされるようにサイトをデザインする必要があります。

ページのデザインとキャッシングの詳細は、次の項を参照してください。

- モジュラ・ページ・デザインについて

- キャッシングについて

- 二重バッファ・キャッシング

38.1 モジュラ・ページ・デザインについて

モジュラ・ページ・デザイン戦略は、複数のエレメントで構成されています。モジュラ・ページ・デザインには次のようないくつかの利点があります。

- 効率的なキャッシュ戦略を策定可能にすることで、システム・パフォーマンスを向上させます。

- ナビゲーション・バーのような一般的なデザイン・エレメントを1回コーディングするのみで、複数のWebページで利用できます。

図38-1では、シンプルなモジュラ・ページを示しています。

図38-1 モジュラ・ページ

それぞれの四角形は、生成された1つ以上のエレメントの出力を表し、これらはページレットと呼ばれます。これらのページレットは、それを含むプロジェクトによってコールされ、これらを使用して次のことが可能になります。

- 完成したページにページレットを表示する方法をレイアウトします。

- カスタムアクセス制御リスト(ACL)チェック・コードなど、ページが表示されるたびに評価する必要があるコードを定義します。

この戦略を使用すると、エレメントを1回コーディングのみで、そのエレメントをWebサイトの様々な場所で利用できます。

38.2 キャッシングについて

WebCenter Sitesでは、Webページ全体をキャッシュしたり、それらのWebページを構成しているコンポーネントをキャッシュしたりできます。効率的なページ・キャッシング戦略を使用すると、負荷を軽減してシステム・パフォーマンスを向上させることができます。

WebCenter Sites製品ファミリの次の2つのメンバーではページ・キャッシングが実装されています。

- WebCenter Sitesでは、WebCenter Sitesシステム上でページがキャッシュされます。

- Satellite Serverは、WebCenter Sitesシステム用の第2レベルのキャッシングを提供し、Webページのリモート・キャッシュとしても使用できます。

WebCenter Sitesは、WebCenter SitesとSatellite Serverの両方のキャッシュを利用して、効率的なキャッシュ戦略を実現します。

38.2.1 WebCenter Sitesのキャッシング

ContentServerサーブレットへの要求によって生成されたページレットをディスク上でキャッシュできる場合、処理速度が上がります。アクセス頻度の高いページのコンテンツが少数のパラメータに依存している場合は、そのページはディスクにキャッシュする対象の有力な候補です。

ページレットをディスクにキャッシュするには、次のタグのいずれかを使用します。

表38-1 キャッシングのタグ

JSPタグ

XMLタグ

satellite:page

SATELLITE.PAGE

render:satellitepage

RENDER.SATELLITEPAGE

キャッシュしようとしているページレットがまだディスク・キャッシュ内にない場合は、ContentServerはそのページレットをキャッシュに追加してから、そのページレットを処理します。

ディスクにキャッシュされたページレットは、徐々に有効期限が切れ、wcs_properties.jsonファイル内のプロパティとともにSiteCatalog表のcscacheinfoおよびsscacheinfo列に設定された値によって制御されます。cscacheinfo列はWebCenter Sitesサーブレットに対応し、sscacheinfo列はSatellite Serverサーブレットに対応します。キャッシュ済ページが要求されると、その有効期限(キャッシュ・タイムアウト)がSystemPageCache表のetime列に格納されます。WebCenter Sitesサーブレットを通じて要求されたキャッシュ済ページの有効期限は、cscachinfoの値に基づいて計算され、Satellite Serverサーブレットを通じて要求されたキャッシュ済ページの有効期限は、sscacheinfoの値に基づいて計算されます。キャッシュ内のアイテムは、キャッシュされていないページと同じセキュリティ・ルールの制約を受けます。WebCenter SitesのACLは、エレメントに対して適用されるのとまったく同じように、キャッシュされたページレットにも適用されます。

38.2.2 BlobServerとキャッシング

BLOBという用語は、Binary Large OBjectの頭字語です。BLOBは通常はイメージ・ファイルですが、Microsoft Wordファイルやスプレッドシートを含むどのようなバイナリ・オブジェクトであってもかまいません。ほとんどのWebサイトではいくつかのBLOBが処理されます。

WebCenter Sitesには、BlobServerという特殊なサーブレットが用意されています。BlobServerは、表からBLOBを収集して、すべての関連するセキュリティ・チェックを実行します。

次に示すBlobServerのタグを使用してBlobServerにアクセスできます。

- satellite:blob

- render:satelliteblob

これらのタグはどちらも、WebCenter SitesとSatellite ServerのキャッシュにBLOBを格納します。BlobServerのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

WebCenter Sitesのメモリー・キャッシュからのBLOBの削除

WebCenter Sitesのキャッシュから特定のBLOBを削除するには、BlobServerのURLを編集する必要があります。

- blobtableパラメータの名前をflushblobtableに変更します

- authusernameパラメータとpasswordパラメータを通じて資格証明を渡すことで、SiteGod権限を持つユーザーとして認証を受けます

次に例を示します。

http://hostname:port/servlet/BlobServer?blobcol=urlpicture&blobheader=image%2Fgif&blobkey=id&flushblobtable=NewPortalImage&blobwhere=22&authusername=username&authpassword=password

すべてのBLOBを削除するには、blobtableパラメータの名前をflushblobtables (語尾のsに注意)に変更して、これをtrueに設定します。

38.2.3 Satellite Serverのキャッシング

Satellite Serverは、WebCenter Sitesとともに自動的にインストールされて、追加のキャッシング層を提供します。WebCenter Sitesシステムのパフォーマンスを向上させるために、リモートのSatellite Serverシステムを追加して、コンテンツの配置場所を対象ユーザーに近づけることができます。

Satellite Serverは、ページ、ページレットおよびBLOBをディスクやメモリーにキャッシュします。Inventoryサーブレットを使用すると、メモリー・キャッシュやディスク・キャッシュのコンテンツを、様々な度合いで詳細に確認できます。Satellite Server上でキャッシュされたアイテムは、WebCenter SitesのAPIによって保護されないことに注意してください。この制限に対処するには、「ページレットのキャッシュ戦略」で概述しているキャッシュ戦略を使用します。

Satellite Serverは、小さいアイテムをメモリーにキャッシュして、大きいアイテムをディスクにキャッシュします。大小の定義は、file_sizeプロパティで制御します。Satellite Serverのプロパティの設定の詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

訪問者が多いサイトでは、各Satellite Serverシステムのキャッシュは、アクセス頻度の高いページによってすぐに一杯になります。キャッシュが一杯になると、Satellite Serverは古いページを削除して、新しいページ用のスペースを確保します。Satellite Serverは、最低使用頻度アルゴリズム(LRU)を使用して、キャッシュから削除するアイテムを決定します。つまり、新しいページをキャッシュする必要がある場合は、Satellite Serverは最も長い時間にわたってアクセスされていないページを削除します。

38.2.3.1 キャッシュの有効期限

Satellite Server上のページとページレットの有効期限は、SiteCatalog表のsscacheinfo列で指定します。ページまたはページレットがSatellite Serverを通じて呼び出されるたびに、Satellite Serverはsscacheinfoフィールドの値を処理して、そのページまたはページレットの有効期限を特定します。sscacheinfoフィールドの詳細は、「ページ・キャッシングの高度な手法の使用」の「CacheInfo文字列の構文」を参照してください。

注意:

satellite.pageタグとrender.satellitepageタグでcachecontrol属性を指定することで、ページレットのsscachinfo有効期限情報をオーバーライドできます。ただし、この方法は、予期しない動作の原因となる可能性があるため、推奨されません。一部のページレットはデフォルトの方法(cachecontrol属性なし)を介してアクセスできる場合がありますが、他のプランニング・ユニット階層はオーバーライドを使用してアクセスできる場合があります。呼び出される1つ目のメソッドは、Satellite Serverに対する有効期限を設定し、2つ目のメソッドは有効期限に影響を与えません。

Satellite Server上でキャッシュされているBLOBは、次のアルゴリズムに応じて失効します。

- Satellite Serverのタグを使用して、BLOBごとにデフォルトの有効期限をオーバーライドできます。

- デフォルトの有効期限をオーバーライドするためのSatelliteのタグが存在しない場合は、Satellite Serverは、satellite.blob.cachecontrol.defaultプロパティの値から有効期限を取得します。このプロパティの詳細は、「ページ・キャッシング・プロパティ」を参照してください。

- satellite.blob.cachecontrol.defaultプロパティの値が設定されていない場合は、Satellite Serverは、expirationプロパティの値から有効期限を取得します。このプロパティについては、「Satellite Serverのプロパティ」を参照してください。

38.2.3.2 Satelliteサーブレットを使用したキャッシング

この項では、SatelliteサーブレットでWebページをキャッシングする方法と、Satelliteサーブレットによるキャッシングをモジュラ・ページ・デザインと組み合せて実装して高速で効率的なWebサイトを作成する方法について説明します。

Satelliteサーブレットによるページのキャッシュ方法

Satelliteサーブレットを使用すると、ページレット・レベルのキャッシングが可能になります。Satelliteサーブレットを使用したキャッシングを実装するには、Satellite ServerのXMLタグまたはJSPタグをWebCenter Sitesページで使用して、Satelliteの特殊なURLを使用してページにアクセスします。

たとえば、Satelliteサーブレットを使用して、myPageという名前のWebページ上にページレットレベルのキャッシングを実装したとします。図38-2は、このページが格納ページと3つのページレットA、BおよびCで構成されていることを示しています。格納ページとページレットAおよびBは、Satellite Serverシステム上でキャッシュされていますが、ページレットCはキャッシュされていません。

図38-2 myPageという名前のWebページ

ユーザーがmyPageを要求すると、次の処理が行われます。

1. Satellite ServerがそのURLを調べます。それがSatelliteのURLである場合は、Satelliteサーブレットは格納ページのキャッシュされたコピーを取得します。次にサーブレットは、現在自身のキャッシュ内にないページレットへのポインタを検索して、それらのページレットをWebCenter Sitesに対して要求します。したがって、この例では、Satelliteサーブレットは格納ページを取得して、ページレットAおよびBを自身のキャッシュから取得します。

2. Satelliteサーブレットが、WebCenter Sitesに対してページレットCを要求します。

3. WebCenter Sitesが、適切なXMLを解析して、ページレットCを作成してSatelliteサーブレットに送信します。

4. Satelliteサーブレットが、ページレットA、BおよびCを組み合せてページを作成して、作成したページを要求元に送信します。同時に、このサーブレットはページレットCをキャッシュします。

Satelliteサーブレットを使用したキャッシングの実装

Satelliteサーブレットを使用したページレットレベルのキャッシングを実装するには、WebCenter SitesのテンプレートにSatelliteのタグを追加します。Satellite Serverシステム上では、XML、JSPおよびJavaのコードはまったく記述しません。実際には、Satellite ServerはXMLを解析できません。

エレメント内のSatelliteタグは、Satellite Serverの一部としてインストールしたJavaコードによって解釈されます。このコードがSatellite URLを使用してコールされる場合は、このコードによって、Satelliteサーブレットがページレットをキャッシュおよび作成するために使用する情報が生成されます。Satelliteタグが含まれたエレメントを、SatelliteのURLを使用してコールしない場合は、作成されるページは、これらのSatelliteのタグがWebCenter Sitesのタグであるかのように機能します。

SatelliteのURLは、次の例のような形式になります。

http://host:port/servlet/Satellite?pagename=page

ここで、hostとportは、ご使用のSatellite Serverコンピュータのホスト名とポート番号であり、pageは、要求するページの名前です。SatelliteのURLには、コール対象のページに渡す名前と値のペアを含めることもできます。

ページレットのキャッシング

この後に示しているサンプル・コードでは、render:satellitepageタグを使用してページレットをコールしています。このページレットがSatellite Serverのキャッシュ内にない場合は、Satelliteサーブレットはそのページをロードしてキャッシュします。このページレットの処理時にエラーが発生して、このページレットを評価できない場合は、このページレットはキャッシュされません。

render:satellitepageタグ(およびsatellite:pageタグとこれらと同等の機能を持つXMLタグ)は、このタグに渡された名前と値のペアおよびページ名に基づいてキャッシュ済ページレットを識別します。パラメータや名前と値のペアが呼出し間で異なる場合は、生成されるコンテンツが同じであっても、異なるページレットがキャッシュされます。これらのタグを通じてページレットに引数を渡すために、名前と値のペアを使用することが重要です。

ICSオブジェクト・プール、ICSリスト・プール、ページ属性コンテキストおよびセッション(セッション変数を含む)を通じて渡された値は、すべてのキャッシュ済ページレットで使用できるとはかぎりません。ネストされたページレットは、常に親と同時にコールされるとはかぎりません。さらに、セッションやコンテキストのデータに依存しているページレットは、いずれにしてもキャッシュ可能であることはまれなため、これらのページレットをキャッシュしようとすると、予期しない動作が生じる可能性があります。

render:satellitepageタグ(およびsatellite:pageタグとこれらと同等の機能を持つXMLタグ)を通じてネストされたページレットに渡されるすべてのパラメータは、SiteCatalog内でページ基準として指定される必要があります。これにより、キャッシュ対象のページレットを作成する際に該当するパラメータが特定されます。SiteCatalogにリストされているもの以外のパラメータは使用できません(このことを示すエラーがログに書き込まれます)。

<cs:ftcs>
<html>
<body>
<render:satellitepage pagename="My/Sample/Page" />
</body>
</html>
</cs:ftcs>

BLOBのキャッシング

Satelliteタグを使用したBLOBのロードとキャッシュは、Satelliteタグを使用してページレットをロードおよびキャッシュする方法と似ています。次のサンプル・コードでは、BLOBとページレットをコールすることで、前述の例を拡張しています。

<html>
<body>
<!-- NOTE: This will fail if list has no content (== null) -->

<ics:setvar name="category" value="logo"/>
<ics:setvar name="errno" VALUE="0"/>
<ics:selectto from="SmokeImage" list="imagelist" where="category" limit="1"/>

<ics:then>
<!-- Test a blob -->

<render:satelliteblob service="img src"blobtable="SmokeImage" blobkey="id" blobwhere="imagelist.id" blobcol="urlpicture" blobheader="image/gif"cachecontrol="*:30:0 */*/*"alt="imagelist.alttext" border="0" />
</ics:then>

<render:satellitepage pagename="QA/Satellite/Functional/xml/"pagelet1"cachecontrol="never"/>
</body>
</html>

前述のコードでは、次のアクションが定義されています。

- ics:selecttoタグは、データベースからBLOBを取得するシンプルなSQL問合せを実行します。結果は、imagelistという名前のIListの形式で返されます。

- satellite:blobタグは、データベースから取得されたBLOBをロードします。satellite.pageタグの場合と同様に、このBLOBがSatelliteのキャッシュ内にない場合は、SatelliteはこのBLOBをロードした後にキャッシュします。cachecontrolパラメータは、このBLOBが、指定された時刻(この例では30分ごと)に失効するように設定されています。

有効期限のないBLOB

会社のロゴなど、ほとんどまたはまったく変化しないバイナリ・ファイル(BLOB)がサイト上に存在していて、Satelliteサーブレットを使用してページレット・レベルでキャッシュしている場合は、代替の方法を使用してこれらのBLOBを処理することで、パフォーマンスを向上させることができます。

有効期限のないBLOBを処理するには::

1. 有効期限のないイメージをすべてのSatellite Serverホストにコピーします。これらは、Webサーバーのdocルートの下に配置します。

2. これらのイメージには、satellite:blobというSatelliteタグではなく、 <img src="pathname">というHTMLタグを通じてアクセスします。

たとえば、CorporateLogo.gifという名前の、有効期限のない会社のロゴ・ファイルがあるとします。BLOBを処理するための代替方法を使用するには、まずこのファイルをすべてのSatellite Serverホスト上のWebサーバーのdocルートにコピーします。次に、satellite.blobタグを通じてこのロゴを処理するかわりに、エレメントで単に次のようなタグを使用できます。

<img src="CorporateLogo.gif">

注意:

このメカニズムを使用して有効期限のないイメージを処理する場合は注意してください。たとえば、いずれかのSatellite Serverホストに他のホストと同じイメージ・ファイルが保持されていない場合でも、Satellite Serverはそのことを警告できません。

http://myloadbalancer:1234/servlet/ContentServer?pagename=myPage

ページの有効期限は、expirationプロパティによって制御されます。expirationプロパティの詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

38.2.3.3 Satellite Serverキャッシュのコンテンツの表示

Inventoryサーブレットを使用すると、キャッシュに格納された様々なアイテムを表示できます。Inventoryサーブレットを呼び出すには、次のURLを使用します。

http://host:port/servlet/Inventory?username=username&password=passwordword&detail=value

これらのパラメータは、表38-2に定義されています。

表38-2 Inventoryサーブレットのパラメータ

パラメータ

説明

host:port (必須)

キャッシュを表示するSatellite Serverホストのホスト名とポート番号。

username (必須)

そのSatellite Serverホストにログインするために入力するユーザー名。

password (必須)

そのSatellite Serverホストにログインするために入力するパスワード。

detail (任意指定)

Inventoryサーブレットによって表示する情報のタイプ。有効な値は次のとおりです。

- names: ヘッダー情報に加えて、キャッシュ内のページのページ名を表示します。

- keys: ヘッダー情報に加えて、キャッシュ内のアイテムのキーとページ名を表示します。

detailパラメータを指定しない場合や、このパラメータをnameやkeys以外の値に設定した場合は、ヘッダー情報が表示されます。

ヘッダーには、表38-3に定義されている情報タイプが含まれます。

表38-3 情報タイプ

情報タイプ

説明

リモート・ホスト

このSatellite Serverシステムが要求を転送する先となるホスト。

最大キャッシュ・オブジェクト数

キャッシュに格納できるアイテムの最大数。

現在のサイズ

キャッシュに現在格納されているアイテムの数。

キャッシュのチェック間隔

失効したアイテムがキャッシュに格納されているかどうかをチェックする間隔(分単位)。

デフォルトのキャッシュ有効期限

expirationプロパティの値。

最小ファイル・サイズ(バイト単位)

この値より大きいアイテムはファイルに格納されます。この値より小さいアイテムはRAMに格納されます。

38.2.3.3.1 CacheManager

CacheManagerオブジェクトは、WebCenter SitesとSatellite Serverの両方のキャッシュを管理します。CacheManagerは、次の機能を実行できます。

- ページレットをキャッシュ追跡表に記録します。

- キャッシュ依存性アイテムをキャッシュ追跡表に記録することで、ページやページレットに含まれたコンテンツ(アセット)の記録を保持します。キャッシュ依存性アイテムとは、そのアイテムが変更されると、そのアイテムが格納されているキャッシュ内のページやページレットを無効化するアイテムのことです。キャッシュ依存性アイテムは、現在のページとすべての親ページの依存性としてログに記録されます。

- 無効なアイテムが含まれたページやページレットをWebCenter SitesとSatellite Serverのキャッシュから削除します。

- 無効なページが削除された後に、更新されたページやページレットを使用してWebCenter SitesとSatellite Serverのキャッシュを再構築します。

CacheManagerの使用の詳細は、「WebCenter Sitesでのキャッシュ管理の使用」を参照してください。

38.2.3.3.2 SiteCatalog表

WebCenter Sitesの SiteCatalog表には、WebCenter Sitesによって生成されたページとページレットが一覧表示されます。エレメントがWebCenter SitesやSatellite Serverでキャッシュされるためには、そのエレメントのエントリがSiteCatalog表に含まれている必要があります。

SiteCatalog表内のフィールドは、WebCenter Sitesのページのデフォルト動作(デフォルトのキャッシング動作を含む)を設定します。SiteCatalog表とそのフィールドの詳細は、「テンプレート・アセットの作成」および「SiteEntryアセットの作成」を参照してください。

38.2.3.3.3 キャッシュ・キー

WebCenter SitesやSatellite Serverのキャッシュに格納されたアイテムには、キャッシュ・キーが割り当てられます。キャッシュ・キーは、キャッシュ内の各アイテムを一意に識別します。CacheManagerは、キャッシュ・キーを使用してキャッシュ内のアイテムを検索します。WebCenter SitesとSatellite Serverは、SiteCatalog表のpagename、resargs、pagecriteriaの各フィールドの値と他の内部データに基づいて、自動的にキャッシュ・キーを生成します。

38.2.3.3.3.1 pagecriteriaとキャッシュ・キー

ページで使用される変数をキャッシュ・キーに含めるには、SiteCatalog表のpagecriteriaフィールドでそれらの値をカンマ区切りリストの形で指定します。たとえば、redとblueという値が使用されるmyPageという名前のページがあるとします。

redとblueをmyPageのキャッシュ・キーに含めるには、次のように入力します。

- favoritecolor,second_favoritecolorをpagecriteria列に

- favoritecolor=red&second_favoritecolor=blueをresargsl列に

WebCenter SitesとSatellite Serverでは、キャッシュされたページに渡されたパラメータおよびpagecriteriaに基づいてキャッシュ・キーを生成します。これらのパラメータが呼出し間で異なる場合は、生成されるコンテンツが同じであっても、異なるページがキャッシュされます。次に例を示します。

http://mysatellite:1234/servlet/ContentServer?pagename=myPage&favoritecolor=red

このアドレスでは、次のアドレスとは異なるページがコールされます。

http://mysatellite:1234/servlet/ContentServer?pagename=myPage&second_favoritecolor=blue

このことは、生成されるコンテンツが同じかどうかに関係なく当てはまります。URLを通じて渡された値は、pagecriteriaで設定された値をオーバーライドします。たとえば、myPageのpagecriteriaをred,blueに設定した場合は、次のようになります。

- URLを通じてgreenという値が渡された場合は、(red,blueでなく) green,blueがmyPageのキャッシュ・キーに組み込まれます。

- URLを通じてgreen,violetという値が渡された場合は、(red,blueでなく) green,violetがmyPageのキャッシュ・キーに組み込まれます。

- URLを通じてgreen,violet,yellowという値が渡された場合は、エラーが発生します。

ページにpagecriteriaが設定されていない場合は、resargsフィールドの値がキャッシュ・キーに組み込まれます。pagecriteriaの場合と同様に、URLを通じて渡された値はresargsフィールドで指定された値をオーバーライドします。

38.2.3.3.4 キャッシング・プロパティ

WebCenter SitesとSatellite Serverのデフォルトのキャッシュ設定は、wcs_properties.jsonファイルに含まれています。これらのプロパティは、プロパティ管理ツールを使用して変更できます。プロパティおよびプロパティ管理ツールの詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

Satellite Serverの追加プロパティは、configディレクトリの下にあるリモートSatellite Serverのwcs_properties.jsonファイルに含まれており、手動で変更する必要があります。

38.2.3.3.5 ページ・キャッシング・プロパティ

wcs_properties.json内の次のプロパティは、ディスク・キャッシングを制御します。

- cs.pgCacheTimeout: キャッシュ内のページのデフォルト・タイムアウトを指定します。

- cs.freezeCache: 失効したエントリをキャッシュから削除するためにキャッシュ削除スレッドを実行するかどうかを制御します。

- cs.nocache: ページのキャッシュ全体を無効にします。

- cc.SystemPageCacheTimeout: キャッシュされたページがメモリー内に保持される時間を分単位で指定します。

- cs.alwaysUseDisk: SiteCatalog内で、キャッシュ・オーバーライドのプロパティが指定されていないページ・エントリのデフォルト動作を指定します。

- cc.SystemPageCacheCSz: メモリー内にキャッシュできるページの最大数を指定します。

38.2.3.3.6 Satellite Serverのプロパティ

Satellite Serverには、wcs_properties.jsonファイル内に2つのプロパティ・セットが用意されています(Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照)。

- wcs_properties.jsonファイル内の1つのプロパティは、Cacheの下に分類されています。
satellite.blob.cachecontrol.default: satellite.blobタグとRENDER.SATELLITEBLOBタグ(およびこれらと同等の機能を持つJSPタグ)のcachecontrolパラメータのデフォルト値を指定します。

- wcs_properties.jsonファイル内の他のプロパティは、Satelliteの下に分類されています。

- cache_folder: Satellite Serverがページレットをディスクにキャッシュする際のキャッシュ先ディレクトリを指定します。

- file_size: サイズを基準にして、ディスクにキャッシュされるページレットおよびBLOBを、メモリーにキャッシュされるページレットおよびBLOBから分離します。

- expiration: BLOBがSatellite Serverのキャッシュ内に保持される期間のデフォルト値を設定します。

- cache_check_interval: キャッシュ・クリーナ・スレッドの実行間隔を制御します。これにより、失効したオブジェクトがキャッシュから削除されるタイミングを定義します。

- cache_max: 一度にキャッシュできるオブジェクト(ページレットとBLOB)の最大数を指定します(メモリー・キャッシュとディスク・キャッシュの両方の合計)。

38.3 二重バッファ・キャッシング

WebCenter SitesとOracle WebCenter Sites: Engageでは、WebCenter SitesとSatellite Serverのキャッシュを同時に使用するという二重バッファ・キャッシュ戦略が実装されます。この二重バッファ・キャッシュ戦略により、ページが常にキャッシュ内に保持されるようになります。

CacheManager Java APIを使用して同様のキャッシュ戦略を実装することもできます。このことが該当するのは、他のCSモジュールやCS製品を使用せずにWebCenter SitesコアおよびSatellite Serverを実行している場合のみです。CacheManager Java APIの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

WebCenter SitesコアとSatellite Serverのキャッシュはどちらも、WebCenter SitesのCacheManagerオブジェクトによって管理されます。CacheManagerは、エレメントとこれらのエレメントによってコールされるアセットをキャッシュ追跡表に記録することで、コンテンツが変化するタイミングを追跡管理します。

アセットが更新およびパブリッシュされると、WebCenter SitesとSatellite Serverのキャッシュは図38-3に示す順序で自動的にフラッシュおよび更新されます。

図38-3 キャッシュ・フラッシュの順序1

- 図38-4では、コンテンツ・プロバイダは、更新されたアセットを配信システムにパブリッシュします。CacheManagerは、キャッシュ追跡表をチェックして、どのキャッシュ済アイテムがこれらの更新されたアセットの影響を受けるのかを確認します。

図38-4 キャッシュ・フラッシュの順序2

- 図38-5では、CacheManagerは、古いPage1をWebCenter Sitesのキャッシュからフラッシュして、更新されたPage1をWebCenter Sitesのキャッシュに再ロードします。Page1が要求された場合は、Satellite Serverのキャッシュ内にある古いバージョンのPage1がその要求元に渡されます。これにより、WebCenter Sitesコンピュータでは、キャッシュを削除して再構築する際の過剰な負荷が防止されます。

図38-5 キャッシュ・フラッシュの順序3

- 図38-6では、CacheManagerは、古いアイテムをSatellite Serverのキャッシュからフラッシュします。訪問者がこのWebサイトにアクセスしてPage1を要求すると、Satellite Serverは検索を実行して、Page1が自身のキャッシュに存在するかどうかを確認します。Page1はSatellite Serverのキャッシュ内には存在しないため、この要求はWebCenter Sitesに転送されます。

図38-6 キャッシュ・フラッシュの順序4

- Satellite Serverシステムのキャッシュは、WebCenter Sitesのキャッシュから取得された更新バージョンのPage1で一杯になります。この更新されたページは、要求元に提供されます。Page1が再び要求された場合は、このページはSatellite Serverのキャッシュから提供されます。

38.3.1 二重バッファ・キャッシングの実装について

Webサイトに二重バッファ・キャッシングを実装するための最初の手順は、「モジュラ・ページ・デザインについて」で説明しているように、モジュラ・ページを設計することです。モジュラ・ページ・デザインを開発したら、二重バッファ・キャッシング戦略を次の3つの手順で実装します。

- ページレットのキャッシュ戦略を策定します。

- SiteCatalog表のpagecriteriaフィールドを使用して、個別のページとページレットのキャッシング方法を設定します。

- Satelliteのタグを使用してエレメントをコーディングします。

38.3.1.1 ページレットのキャッシュ戦略

モジュラ・ページ・デザインの場合、キャッシングはページレット・レベルで行われます。キャッシュされたページレットが常にACLによって保護されるように、格納ページがキャッシュされることはありません。ページレットの更新頻度に基づいて、キャッシュ対象にするページレットを選択します。

表38-4では、ページレットのキャッシングに関するガイドラインを要約しています。

表38-4 ページレットのキャッシングに関するガイドライン

ページレットをキャッシュすべきケース

ページレットをキャッシュすべきでないケース

- コンテンツがめったに変化しない場合。

- 評価が機能することを必要とするロジックがページレットに含まれていない場合。

- コンテンツが頻繁に変化する場合。

- コンテンツのリアルタイム性が要求される場合。

- ACLの有無をチェックするコードや、評価が機能することを必要とする他のロジックがページレットに含まれている場合。

モジュラ・ページの例を図38-7に示します。

図38-7 モジュラ・ページ

格納ページは絶対にキャッシュしないでください。キャッシングのパフォーマンス上の利点を通常どおり得られるとともに、WebCenter Sitesによる評価を必要とするロジックをページに配置することが可能になります。また、WebCenter SitesのACLによってページを保護することも可能になります。

この例のヘッダーとフッターのページレットは、ディスクにキャッシュされる必要があります。これらはめったに更新されないため、そのことを考慮してデザインする必要があります。ヘッダーとフッターは、テンプレート内に書き込まれた静的HTMLであっても、WebCenter Sitesのディスクにキャッシュされたコンテンツであってもかまいません。

サイドバーもディスク・キャッシング対象の有力な候補です。サイドバーにはわずかなバリエーションしかなく、そのコンテンツは少数のパラメータによって決定されるからです。

本文ページレットのキャッシュ方法を決定することはさらに複雑です。本文ページレットのコンテンツは、Webサイトの訪問者がサイト内のどこにいるのかによって変化する場合があります。本文ページレットのコンテンツとしては、次の3つのタイプが考えられます。

- Webサイトの訪問者が実行する検索の結果

- 頻繁に実行される問合せの結果

- 記事

キャッシング戦略では、次の点を検討する必要があります。

- 本文ページレットのコンテンツが、Webサイトの訪問者が入力するパラメータに基づいた検索の結果である場合は、そのコンテンツをキャッシュしないでください。このようなページは訪問者ごとに変化するため、これらをキャッシュすることの利点はほとんどありません。

- コンテンツが訪問者によって頻繁に使用される標準問合せの結果である場合は、結果セットのキャッシングを使用してください。頻繁に実行される問合せをメモリーにキャッシュすると、パフォーマンスが向上します。結果セットのキャッシングの詳細は、「結果セットのキャッシングと問合せでの作業」を参照してください。

- 本文ページレットのコンテンツが記事のテキストである場合は、そのページレットをディスクにキャッシュしてください。

38.3.2 cscacheinfoの設定

SiteCatalog表のcscacheinfoフィールドの値によって、WebCenter Sites上のページのキャッシュ方法を制御できます。

- これらのプロパティは、Webサイト内のページごとおよびページレットごとに変更できます。たとえば、格納ページのエレメントがWebCenter Sitesでキャッシュされないようにするには、cscacheinfoの値をfalseに設定します。

cscacheinfoフィールドの詳細は、「テンプレート・アセットの作成」を参照してください。

38.3.3 キャッシングのためのコーディング

- 二重バッファ・キャッシングを実装するには、Satellite Serverのタグを使用してエレメントをコーディングします。WebCenter SitesとSatellite Serverのみを実行している場合は、Oracle WebCenter Sitesタグ・リファレンスのSatellite Serverに関する項に記載されているSatelliteタグを使用してください。

自動キャッシュ・メンテナンスが機能するためには、アセットがキャッシュ追跡表に記録される必要があります。ASSET.LOADタグを使用してアセットをロードする場合は、そのアセットは自動的にキャッシュ追跡表に記録されます。ASSET.LOADタグが使用されないセクションについては、RENDER.LOGDEPタグを使用してコンテンツをキャッシュ追跡表に記録してください。

注意:

キャッシュの依存関係がログに記録されるのは、ページまたはページレットがWebCenter Sites上でキャッシュされている場合のみです。あるページが、WebCenter SitesではキャッシュされていないがSatellite Serverではキャッシュされている場合は、そのページのコンテンツが更新されたときに、そのページはキャッシュから自動的にフラッシュされません。

38.3.4 キャッシングとセキュリティ

キャッシュされるページレットについては、サイトを設計してキャッシュ戦略を策定する際に、セキュリティに関して特別な考慮が必要となります。次の各項では、WebCenter SitesとSatellite Serverでキャッシュされるページのセキュリティ考慮事項を概述しています。

- WebCenter Sitesのセキュリティ

- Satellite Serverのセキュリティ

38.3.4.1 WebCenter Sitesのセキュリティ

WebCenter Sitesでディスクにキャッシュされるページレットは、WebCenter SitesのACLによって制約されるため、これらのACLを使用してページへの不正なアクセスを防止できます。

ただし注意点として、WebCenter Sitesは格納ページのACLをチェックしますが、格納ページによってコールされるページレットのACLはチェックしません。たとえば、Open、Secret、TopSecretの3つのACLをサイトで使用しているとします。格納ページはOpen ACLのメンバーが表示できますが、格納ページによってコールされるページレットは、Secret ACLとTopSecret ACLのメンバーのみが表示できるようにする必要があります。WebCenter Sitesでは、訪問者の格納ページのACLのみがチェックされるため、Open ACLのメンバーである訪問者は、Secret ACLとTopSecret ACLのメンバー向けのコンテンツを表示できます。

関連するACLがすべてチェックされるようにするには::

1. 次のサンプル・コードに示すように、保護するページのACLをそのページのキャッシュ基準に含めます。

<render.satellitepage pagename="innerwrapper" userAcl="SessionVariables.member" c="Article" cid="123">

2. 次のサンプルに示すように、ページレット内で、ACLをチェックするコードを挿入します。

<asset.load name="art" type="Variables.c" OBJECTID="Variables.cid"/>
<ASSET.GET NAME="art" FIELD="myACL"/> <!-- note you need a column in your db to support this -->
<IF COND="Variables.userACL=Variables.myACL">
<THEN>
<render.satellitepage pagename="protected_art_tmpl1" c="Variables.c" cid="Variables.cid"/>
</THEN>
<ELSE>
<render.satellitepage pagename="accessDenied"/>
</ELSE>
</IF>

38.3.4.2 Satellite Serverのセキュリティ

Satellite Server上でキャッシュされるページレットは、次の場合にのみWebCenter SitesのACLによって制約されます。

- WebCenter Sitesのキャッシュから取得された場合。

- ページ要求に応えるために、WebCenter Sitesによって生成される必要がある場合。

ページレットがSatellite Serverのキャッシュから提供される場合は、そのページレットはWebCenter SitesのACLによって保護されなくなります。

Satellite Serverページのコンテンツのセキュリティを確保するには、格納ページをいっさいキャッシュせずに、キャッシュされないコンテナにACLチェック・メカニズムを必ず組み込んでください。

エレメントがSatelliteのタグを使用してコーディングされているが、Satellite Serverをまだインストールしていない場合は、「WebCenter Sitesのセキュリティ」で概述されているページ・デザイン考慮事項が当てはまります。ただし、Satellite Serverをインストールしたら、WebCenter Sitesは、格納ページからコールされるキャッシュ対象外ページレットのACLをチェックします。Satellite Server上でキャッシュされるページレットのACLはチェックされません。

39 結果セットのキャッシングと問合せでの作業

結果セットのキャッシングは、システムのパフォーマンスを向上させるもう1つの手段です。CatalogManagerを使用して結果セットを適切にキャッシュして、キャッシュからそれらの結果セットをフラッシュできるようにする問合せを作成できます。

結果セットのキャッシングと問合せの詳細は、次の項を参照してください。

- 結果セットのキャッシングと問合せについて

- キャッシング・フレームワーク

- データベース問合せ

- 結果セットのキャッシングの仕組み

- データベースのロードの削減

- 表名の指定

- 結果セットのキャッシュのフラッシュ

- キャッシング・フレームワーク間の切替え

- 結果セットのキャッシングの戦略およびプロパティについて

39.1 結果セットのキャッシングと問合せについて

結果セットのキャッシュは、CatalogManagerサーブレットによって保持されます。開発者やシステム管理者は、3つのシステム(開発、管理および配信)すべてで結果セットのキャッシングを設定します。

データベースに問い合せるたびに、WebCenter Sitesではキャッシュ済または未キャッシュのいずれかの結果セットが処理されます。結果セットのキャッシングは、ご使用のデータベースの負荷を軽減し、問合せに対するレスポンス時間を改善します。

wcs_properties.jsonファイルには、すべての結果セットのサイズとタイムアウトの期間を設定するグローバル・プロパティが用意されています。表ごとのデフォルト設定をオーバーライドする、表固有のプロパティをwcs_properties.jsonファイルに追加できます。これらのカスタム・プロパティを使用すると、ピーク・パフォーマンスのシステムを微調整できます。

結果セットのキャッシングは、ご使用のデータベースの負荷を軽減し、問合せに対するレスポンス時間を改善します。必ず次の手順に従ってください。

- wcs_properties.jsonファイルのデフォルト結果セットのキャッシング・プロパティを、開発、管理、テストおよび配信の各システムで意味のある値に設定します。

- 表固有の結果セットのキャッシング・プロパティをwcs_properties.jsonファイルに追加し、開発、管理、テストおよび配信のすべてのシステムのパフォーマンスを微調整します。

- すべての問合せに対して適切な表名を付け、結果セットが正しくキャッシュされ、正しくフラッシュされるようにします。

39.2 キャッシング・フレームワーク

デフォルトでは、WebCenter Sitesは、結果セットをinCacheフレームワークに格納します。「キャッシング・フレームワーク間の切替え」の説明に従い、ハッシュ表のキャッシングに切り替えるオプションを使用できます。

inCacheによる結果セット・キャッシングが有効になると、「システム・ツール」ノード(Adminインタフェースの「管理」タブにある)には、結果セットのキャッシュとそのコンテンツに関する統計情報を提供するinCacheツールによって結果セットが表示されます。inCacheによる結果セットのキャッシュは、inCacheによるページとアセットのキャッシュとは関係なく機能することに注意してください。inCacheフレームワーク、そのキャッシュ・モデルおよびシステム・ツールの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

39.3 データベース問合せ

次の例は、WebCenter Sitesデータベースに情報を問い合せるいくつかの方法を示しています。

- ics.SelectTo Javaメソッド、SELECTTO XMLタグまたはics:selectto JSPタグを使用する。

- ics.CatalogManager Javaメソッド、CATALOGMANAGER XMLタグおよびics:catalogmanager JSPタグのselectrowコマンドを使用する。

- ics.SQL Javaメソッド、EXECSQL XMLタグまたはics:sql JSPタグを使用する。

- ics.CallSQL Javaメソッド、CALLSQL XMLタグまたはics:callsql JSPタグを使用する。

- WebCenter Sitesインタフェースの「検索」フォームを使用する。

- 問合せアセットを使用する。

- SEARCHSTATE XMLまたはJSPタグ(フレックス・アセットのみ)を使用する。

39.4 結果セットのキャッシングの仕組み

データベースに問合せがある場合、結果セットのキャッシングを有効にしてあると、問合せからの結果セットがキャッシュされます(関連プロパティの詳細は、「デフォルト・プロパティ」および「表固有のプロパティ」を参照)。その場合、同じ問合せが別に実行され、最新の問合せが実行されてから表内のデータが変更されないままだと、WebCenter Sitesは、データベースに再び問い合せるのではなく、結果セットのキャッシュから情報を提供します。キャッシュからの結果セットの提供の方が、別のデータベース検索の実行より迅速に実行されます。

wcs_properties.json内のrsCacheOverInCacheプロパティの構成方法に応じて、結果セットのキャッシュはハッシュ表またはinCacheフレームワークのいずれかになります。結果セットは、結果セットを生成した問合せに関連付けられた表名ごとに編成されています。つまり、結果セットは表名に対してキャッシュされます。

表が更新されるたびに(WebCenter Sitesインタフェースから、またはカスタム・エレメントのCatalogManagerコマンドにより)、その表に対するキャッシュ内のすべての結果セットがフラッシュされます。結果セットは単一のJava VMと関連してキャッシュされます。Java VM間では結果セットを共有しませんが、同期機能がクラスタ内のすべてのサーバーで有効になっていれば、WebCenter Sitesではクラスタ内のすべてのJava VMにシグナルが送信され、結果セットは無効になったときにフラッシュされます。

39.5 データベースのロードの削減

結果セットのキャッシングは、次の方法でデータベースのロードを軽減します。

- キャッシュ済の結果セットの処理では、データベース接続がオープンされません。WebCenter Sitesは、データベースに接続する前にキャッシュから結果セットの取得を試行します。適切な結果セットが存在すれば、データベースとの接続は実行されません。

- 結果セットのキャッシングが有効になっているのに適切な結果セットがキャッシュされない場合には、WebCenter Sitesでは結果セットが取得され、キャッシュ内にオブジェクトとして格納され、データベースとの接続が解放されます。

- 結果セットのキャッシングが有効でない場合、WebCenter Sitesではオンライン・ページが完全にレンダリングされるか、未キャッシュの結果セットがflushタグを持つスコープから明示的にフラッシュされるまで、データベースの接続をクローズできません。このような事態が発生すると、有効なデータベース接続はすぐに使い尽くされる可能性があります(比較的シンプルなページであっても)。

通常、結果セットのキャッシングはすべてのデータベース表で有効にする必要があります。キャッシュする結果セットの数やキャッシュする時間の長さを制限する必要がある場合でも、結果セットのキャッシングを全部まとめて無効にすることは逆効果になりかねません。

注意:

ElementCatalog表の結果セットのキャッシングを無効にしないでください。無効にした場合、いずれかのエレメントでJSPを使用する場合は特に、システム・パフォーマンスが大きく低下します。

39.6 表名の指定

該当する表に対して結果セットをキャッシュできるように、表名は常に問合せと関連付けられている必要があります。それにより、表がWebCenter Sitesインタフェースや独自のカスタム・エレメントで更新されるたびに、その表に関連付けられたすべての結果セットがCatalogManagerによってフラッシュされます。

表名を結果セットに対して指定する方法は、実行している問合せのタイプに応じて異なります。次の項では、最も一般的に使用されるデータベースへの問合せ方法とそのような問合せに対する表名の指定方法について説明します。

- SELECTTO

- EXECSQL

- CALLSQL

- WebCenter Sitesインタフェースのフォームの検索

- 問合せアセット

- SEARCHSTATE

39.6.1 SELECTTO

ics.SelectTo Javaメソッド、SELECTTO XMLタグまたはics:selectto JSPタグを使用する場合、FROMパラメータ(句)を使用して表名を指定する必要があります。次に例を示します。

<SELECTTO FROM="EmployeeInfo"
WHERE="name"
WHAT="*"
LIST="MatchingEmployees"/>

この場合、EmployeeInfoは問合せ先の表名であり、結果セットをキャッシュした表の名前です。EmployeeInfo表が更新されるたびに、CatalogManagerではその表に対してキャッシュされたすべての結果セットがフラッシュされます。

39.6.2 EXECSQL

EXECSQLにより、インラインSQL文を実行できます。TABLEパラメータを使用して、結果セットをキャッシュする表(複数可)を指定します。複数の表を指定すると(カンマ区切りリストを使用して)、結果セットはリストの最初の表に対してキャッシュされます。つまり、結果セットは、タイムアウトや最大サイズなど最初の表に指定された結果セットのキャッシュの設定に基づいてキャッシュされます。

CatalogManagerでは、指定された表が更新されると古くなった結果セットが削除されます。

たとえば、次の問合せは記事の表に対する結果セットをキャッシュします。

<EXECSQL SQL="SELECT article.headline, images.imagefile FROM article,images WHERE article.id='FTX1EE17FWB' AND images.id='FTK9384FWW'" LIST="sqlresult" TABLE="article,images"/>

39.6.3 CALLSQL

ics.CallSQL Javaメソッド、CALLSQL XMLタグまたはics:callsql JSPタグを使用して、SystemSQL表内に格納されているSQL問合せを呼び出すと、表名はSystemSQL表内の問合せのエントリ(行)によって設定されます。

SystemSQL表にはdeftable列があり、問合せからの結果セットをキャッシュする表名を識別します。複数の表を指定するには、deftable列に表のカンマ区切りリストを追加します。リストの最初の表は、問合せがキャッシュされる表です。

表に格納された各問合せでは、deftable列に値が存在する必要があります。値がないと、CatalogManagerで結果セットを適切に保存できなくなり、必要な場合に結果セットをフラッシュできなくなります。表名は既存の表を識別する必要があります。存在しない表名を入力したり、表名のスペルを間違えると、結果セットを適切にキャッシュできません。

39.6.4 WebCenter Sitesインタフェースのフォームの検索

WebCenter Sitesインタフェースのアセットを検索する際に使用する「検索」フォームは、アセットをそのタイプに基づいて検索します。検索フォームの問合せからの結果セットは、該当するタイプのアセットのプライマリ記憶域表に対して格納されます。

たとえば、avisportsサンプル・サイトで、記事という名前のアセット・タイプの結果セットはAVIArticle表に対してキャッシュされ、ページのアセットの場合はPage表に対してキャッシュされます。

39.6.5 問合せアセット

問合せアセットが返すことができるアセットは、1タイプのアセットのみです。問合せアセットを作成する際には、問合せアセットが「問合せの結果」フィールドに返すアセットの種類を、記事、イメージファイルなどのように指定します。

該当する問合せアセットがオンライン・サイトのページで使用されると、WebCenter Sitesでは問合せアセットが返すアセット・タイプ(ArticleやImagefileなど)のプライマリ記憶域表の表名に対する結果セットが格納されます。

39.6.6 SEARCHSTATE

SEARCHSTATE XMLタグおよびJSPタグは、一連のフレックス・アセット(ASSETSETタグにより作成される)に適用される一連の検索絞込み条件を作成します。絞込み条件として、属性値または別のsearchstate(ネストされたsearchstate)のいずれかに基づいたフィルタ(制限)を使用できます。

SEARCHSTATEタグとASSETSETタグを使用して、フレックス・アセットまたはフレックス親アセット(定義やフレックス属性ではない)を抽出し、オンライン・ページで訪問者に表示できます。

WebCenter Sitesでは、検索状態の結果セットがフレックス・アセット・タイプの_Mungo表に対してキャッシュされます。たとえば、検索状態によって記事という名前のavisportsサンプル・サイトのフレックス・アセットが返される場合、結果セットはAVIArticle_Mungo表に対してキャッシュされます。

配信システムを構成する際には、必ずすべての_Mungo表に対する結果セットのキャッシング・プロパティを追加してください。

39.7 結果セットのキャッシュのフラッシュ

ほとんどの場合、データはCatalogManager APIによってデータベースに書き込まれ、必要に応じて結果セットのキャッシュがフラッシュされます。次に例を示します。

- WebCenter Sites Explorerを使用して表(SiteCatalog表、ElementCatalog表など)に行を追加する場合、該当する表に対してキャッシュされたすべての結果セットがフラッシュされます。

- WebCenter Sitesインタフェース内のフォームを使用してアセット、ソース、カテゴリ、ワークフロー・プロセス、ユーザー、ACLなどを追加または編集する場合、書き込まれた表に対してキャッシュされた結果セットがフラッシュされます。

- 自分のエレメント内にあるCatalogManagerのコマンドを使用して単一の表を更新する場合、該当する表に対してキャッシュされた結果セットは自動的にフラッシュされます。

- 自分のエレメント内にあるCatalogManagerのコマンドを使用して複数の(結合された)表を更新する場合、その結合された表に対してキャッシュされた結果セットは自動的にフラッシュされます。

- CALLSQLタグを使用してSystemSQL表に格納されているSQL文を実行すると、deftable列で指定された表(複数可)に対してキャッシュされた結果セットが自動的に更新されます。

39.8 キャッシング・フレームワーク間の切替え

inCacheに関する結果セットのキャッシングは、次の条件に一致すると有効になります。

- linked-cache.xml構成ファイルがアプリケーション・サーバーのクラスパス(WEB-INF/classesディレクトリ)に格納されている場合。

- rsCacheOverInCacheプロパティ(wcs_properties.json内)がtrueに設定されている場合。

そのうえでinCacheおよびハッシュ表のフレームワークを切り替えるには、rsCacheOverInCacheプロパティをtrueまたはfalseに設定します。

39.9 結果セットのキャッシングの戦略およびプロパティについて

次のトピックでは、すべての表と特定の表について結果セットのキャッシング・プロパティを計画して使用するプロセスについて説明します。

- 結果セットのキャッシング戦略の計画作成

- デフォルト・プロパティ

- 表固有のプロパティ

39.9.1 結果セットのキャッシング戦略の計画作成

データベースに対して結果セットのキャッシングを構成する前に、WebCenter Sitesデータベース内のすべての表のスプレッドシートを作成し、開発者とデータベース管理者のチームを作り、開発、管理、テストおよび配信のすべてのシステムについての設定内容を検討します。戦略の1つとして、類似表の大きなグループに対してデフォルトのプロパティを特定し、例外の表固有のプロパティを追加します。ただし、配信システムを調整して最高のパフォーマンスを得るには、データベース内の各表でカスタム・プロパティを作成する必要があると考えられます。

注意:

com.fatwire.logging.cs.cache.resultsetプロパティを設定すると、結果セットのキャッシュに関するデバッグ・メッセージがWebCenter Sitesログ・ファイルに書き込まれます。logging-config.xmlでプロパティを設定します。

39.9.2 デフォルト・プロパティ

表39-1は、すべての表に割り当てられる、WebCenter Sitesのwcs_properties.jsonの結果セットのキャッシング・プロパティについて説明しています。表固有のキャッシング・プロパティが表に割り当てられていなければ、これらのプロパティが表の結果セットのキャッシュを制御します。同一のプロパティが、inCacheとハッシュ表の両方で結果セットのキャッシングに有効となります。Adminインタフェース内のプロパティ管理ツールを使用して、WebCenter Sitesのwcs_properties.jsonファイル内のプロパティの値を変更します。プロパティ管理ツールの使用の詳細は、「WebCenter Sitesのツールおよびユーティリティの概要」を参照してください。

表39-1 結果セットのキャッシュを制御するデフォルト・プロパティ

プロパティ

説明

cc.cacheResults

メモリーにキャッシュする結果セットのデフォルトの数を指定します。これは結果セットのレコードの数ではなく、結果セットの数を意味する点に注意してください。

重要: デバッグする場合を除き、このプロパティを0または-1に設定しないでください。その値に設定すると、WebCenter Sitesインタフェースはアセットを適切に保存できなくなります。(このプロパティを0または-1に設定すると、独自のキャッシング・プロパティを構成していないすべての表で結果セットのキャッシングが無効になります。)

cc.cacheResultsTimeout

キャッシュされる結果セットをメモリー内に保持する時間を分単位で指定します。

このプロパティを-1に設定すると、独自のキャッシング・プロパティを構成していない表のタイムアウト値がなくなります。

cc.cacheResultsAbs

結果セットのキャッシュ内にある有効期限の計算方法を指定します。

- このプロパティがtrueに設定すると、有効期限が絶対となります。たとえば、cc.cacheResultsTimeoutが5分に設定されていると、結果セットがキャッシュされた5分後に、結果セットはキャッシュからフラッシュされます。

- このプロパティをfalseに設定すると、有効期限はそのアイドル時間に基づきます。たとえば、cc.cacheResultsTimeoutを5分に設定する場合、結果セットが最初にキャッシュされた後の5分ではなく、最後にリクエストされた後の5分で、結果セットはキャッシュからフラッシュされます。

39.9.3 表固有のプロパティ

表固有のプロパティは、デフォルト・プロパティをオーバーライドし、システムをピーク・パフォーマンスで微調整できるようにします。CatalogManagerでは、表39-1で説明したデフォルト・プロパティを使用して、表固有の結果セットのキャッシング・プロパティが含まれているかどうかを確認するためにwcs_properties.jsonファイルがチェックされます。

WebCenter Sitesデータベースの各表について3つの結果セットのキャッシング・プロパティを作成できます。表固有のプロパティは、デフォルト・プロパティと同様に動作します(詳細は表39-1)。

表固有のプロパティの構文は、次のとおりです。

cc.<tablename>CSz=<number of resultsets>
cc.<tablename>Timeout=<number of minutes>
cc.<tablename>Abs=<true or false>

注意:

アセット・タイプがリビジョン追跡で有効になっていたり、アセット・バージョンの結果セットをキャッシュしたりする場合、前述のプロパティを使用しますが、<tablename>の後に_tを追加します。

cc.<tablename>_tCSz=<number of resultsets>
cc.<tablename>_tTimeout=<number of minutes>
cc.<tablename>_tAbs=<true or false>

結果セットのキャッシングの詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

プロパティ管理ツールを開き、制御する各表に表固有のプロパティを追加します。プロパティ管理ツールの使用の詳細は、「プロパティ管理ツール」を参照してください。

40 WebCenter Sitesでのキャッシュ管理の使用

サイトを構築するときは常に、コンポーネントのすべてが協調して動作するようにレンダリング・エンジン・キャッシュを適切に構成することが不可欠です。この章では、レンダリング・エンジン・キャッシュとそのコンポーネントについて説明します。また、基盤となるコンテンツの変更が原因で古くなったオブジェクトのすべてのキャッシュ(ContentServer、BlobServerおよびSatellite Serverのキャッシュ)をCacheManagerでクリアできるキャッシュ構成プロパティについても説明します。

キャッシュ管理の詳細は、次の項を参照してください。

- WebCenter Sitesのレンダリング・エンジン・キャッシュについて

- CacheManagerについて

- CacheManagerの有効化

40.1 WebCenter Sitesのレンダリング・エンジン・キャッシュについて

WebCenter Sitesのレンダリング・エンジン・キャッシュは2層構造のキャッシュです。

- 第1層はContentServerとBlobServerで構成されています。

- 第2層はSatellite Serverで構成されています。

各コンポーネントは独立した構成が可能で、キャッシュ・サイズ、キャッシュ・タイムアウトおよび依存性管理の動作を最適化するように微調整できます。

コンポーネントが適切に構成されている場合、WebCenter Sitesは、キャッシュされていないコンテンツをユーザーに表示することを、ほぼ常時、効果的に防ぐことが可能です。ただし、これらのコンポーネントの構成が適切でない場合は、WebCenter Sitesの動作はわかりにくく予期しないものになる可能性があります。キャッシングが不適切だとパフォーマンスが低下し、キャッシュ・インベントリが不適切に連係されると、無効なコンテンツがレンダリングされる場合があります。これに対処するため、WebCenter SitesにはCacheManagerと呼ばれるモジュールが組み込まれており、これにより、システム全体にかわって、キャッシュを有効に管理できます。

40.2 CacheManagerについて

CacheManagerでは、レンダリング・エンジンによりキャッシュされるオブジェクトに対し、構成依存関係の存在を記録できます。たとえば、ページレットがアセットをレンダリングすると、そのアセットはそのページで構成依存関係になります。アセットが変化した場合、ページは無効になり、キャッシュからフラッシュする必要があります。

CacheManagerを利用してキャッシュをフラッシュするには、レンダリング・エンジンのキャッシュ・オブジェクトのライフサイクルに対する完全制御をCacheManagerに譲る必要があります。それには、オブジェクトがキャッシュから失効しないように指定します。基となるコンテンツ(つまり、各オブジェクトに対して記録されている構成依存関係のいずれか)の変更によりオブジェクトが古くなったとCacheManagerにより判断された場合、それらのオブジェクトはキャッシュから削除されます。

注意:

有効期限を無期限に指定すると、キャッシュされたすべてのオブジェクトと、オブジェクトに対してどの依存関係が記録されているかについて、CacheManagerがレコードに残します。このレコードはWebCenter Sitesに格納されており、第1層にキャッシュされたオブジェクトとリンクしています。このレコードにより、第2層のキャッシュのオブジェクトの有無をCacheManagerが推測して、第2層のキャッシュからオブジェクトをフラッシュできるようになります。

オブジェクトがキャッシュから失効するようになっていると、レコードが削除され、第2層のキャッシュからオブジェクトを適切にフラッシュするために必要となる情報が、CacheManagerに伝わらないままになります。

CacheManagerの機能の有効化は、ほぼ完全に自動で行われます。

- デフォルトでは、キャッシュはオブジェクトが失効しないよう構成されています。

- 構成依存性は、下位層のBLOBおよびページ・キャッシュに対して記録されます。<asset:loadや<render:sateliteblobなどのタグを使用すると、構成依存性が自動的に記録される(詳細なリストについては、Oracle WebCenter Sitesタグ・リファレンスを参照)のに対し、<portal:logdepと<render:logdepという2つのタグを使用すると、構成依存性が明示的に記録されます。

- アセットが変更またはパブリッシュされた場合は、WebCenter SitesによりCacheManagerが自動的に起動され、キャッシュから古いコンテンツを消去し、パブリッシュの場合は、第2層のキャッシュをフラッシュする前にバックグラウンドで新しいコンテンツをあらかじめキャッシュするように、WebCenter SitesからCacheManagerに指示されます。

サイトの訪問者は、キャッシュされているコンテンツのみを表示する場合に、最高のキャッシュ・パフォーマンスを得られます。構成依存関係の記録の詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

40.3 CacheManagerの有効化

次の各項では、第1層および第2層のキャッシュ構成プロパティと、CacheManagerを有効化するためにそれらのプロパティをどのように設定する必要があるかについて説明します。

- 第1層のキャッシュ構成プロパティ

- 第2層のキャッシュ構成プロパティ

40.3.1 第1層のキャッシュ構成プロパティ

この項に記載する表では、ページ・キャッシュおよびBlobServerのBLOBキャッシュを調整するプロパティについて説明します。

詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

表40-1では、ページ・キャッシュ・プロパティについて説明します。

表40-1 WebCenter Sitesのページ・キャッシュ・プロパティ

プロパティ

説明

cs.pgCacheTimeout

このプロパティでは、ページがページ・キャッシュに存在する期間を指定します。

デフォルトでは、このプロパティは0 (ゼロ)に設定されており、この場合、ページはこのキャッシュに永久に存在し、これらのページの削除は明示的に行われる必要があります。CacheManagerが適切に動作するには、このプロパティを0 (ゼロ)に設定する必要があります。0に設定しない場合、ページの有効期限が切れ、CacheManagerによる第2層キャッシュからの対応ページの削除ができなくなるため、ユーザーには失効したデータが表示されます。

このプロパティに正の整数を設定すると、整数で指定された時間(単位は分)後にページが期限切れになります。

cs.IItemList

このプロパティでは、IItemListインタフェースを実装するクラスを指定します。

IItemListインタフェースは、ページ・キャッシュに複合依存性を記録する場合に使用されます。このプロパティを有効なクラスに設定すると、依存性項目は、SystemItemCache表のページIDに対して記録されます。これで、CacheManagerが有効になります。

無効な値を設定するとCacheManagerは無効になります。

cc.SystemPageCacheCSz

cc.SystemPageCacheTimeout

cs.alwaysusedisk

cs.freezeCache

cs.nocache

cs.requiresessioncookies

これらのプロパティはページ・キャッシュの構成に使用されますが、CacheManagerには影響しません。プロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

表40-2では、BlobServerのキャッシュ・プロパティについて説明します。

表40-2 BlobServerのキャッシュ・プロパティ

プロパティ

説明

bs.bCacheTimeout

このプロパティでは、BlobServerによりキャッシュにBLOBが保持される秒数を指定します。

構成依存関係がSystemItemCache表のBLOBに対して記録されている場合、この構成依存関係は、BLOBがキャッシュから失効した後に表から削除されるように構成されています。これにより、SystemItemCache表の肥大化が防止されます。ただし、表からエントリを削除すると、対応するBLOBをCacheManagerが第2層のキャッシュから削除できなくなり、失効したデータが表示されることになります。

bs.bCacheSize

このプロパティでは、BlobServerのキャッシュに格納するBLOBの個数を指定します。CacheManagerには影響しません。

bs.bCacheTimeoutプロパティと異なり、キャッシュが一杯になったためにBLOBがBLOBメモリー・キャッシュから削除された場合は、対応する行はSystemItemCache表から削除されません。したがって、このプロパティはCacheManagerには影響しません。

cs.recordBlobInventory

このプロパティでは、BLOBに対して構成依存関係を記録するかどうかを指定します。

このプロパティは、CacheManagerでBLOBを操作するように、true(デフォルト)に設定する必要があります。

bs.security

このプロパティでは、BlobServerのセキュリティ機能を制御します。

BlobServerのセキュリティが有効な場合は、キャッシングが無効になります。したがって、BlobServerのセキュリティは、CacheManagerのインテリジェント・キャッシュ管理機能とは両立しません。

デフォルトでは、このセキュリティのレベルは無効です。

BlobServerのセキュリティの詳細は、「ページのデザインとキャッシングの理解」および「ページ・キャッシングの高度な手法の使用」を参照してください。

cs.manage.expired.blob.inventory

このプロパティでは、BLOBがBLOBキャッシュから失効した後に、SystemItemCache表からBLOB依存性レコードを削除することを制御します。CacheManagerへの影響は、bs.bCacheTimeoutの値に依存します。

- bs.bCacheTimeoutが0 (ゼロ)以下に設定されている場合、このプロパティは無効です。

- bs.bCacheTimeoutが正の整数に設定されている場合、このプロパティにtrueを設定すると、CacheManagerはそのまま正常に動作しますが、SystemItemCache表は肥大します。デフォルト値はfalseです。

40.3.2 第2層のキャッシュ構成プロパティ

第2層のキャッシュ構成プロパティは、Satellite Serverのページ・キャッシュとBLOBキャッシュの両方を扱います。

第2層のプロパティは、CacheManagerの正常動作に一切影響しません。ただし、CacheManagerが正常に動作しなくなった場合には、重要な診断支援機能を果します。第2層のキャッシュ・プロパティのタイムアウト値および構成値は、予期しない動作のトラブルシューティングにとって重要です。

通常の場合、オブジェクトが第2層のキャッシュにはキャッシュされているのに、第1層のキャッシュにはキャッシュされていないと、依存アセットの保存またはパブリッシュ時に、オブジェクトが有効にフラッシュされないため、予期しない動作が起こります。構成の詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

予期しない動作は、キャッシュされたオブジェクトに対して構成依存関係が記録されていない場合にも起こります。その場合、キャッシュ上の該当オブジェクトに対するあらゆる有効な管理ができなくなります。構成依存関係を自動的に記録するタグ、また:logdepタグのいずれかを使用して明示的な記録と組み合せて使用する必要のあるタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

注意:

ページまたはBLOB上の余分な構成依存関係を記録しないでください。これにより、キャッシュの不必要なフラッシュが発生し、特定の状況で、パブリッシュ中にパフォーマンスの深刻な問題を引き起こす可能性があります。不明な構成依存関係を記録する場合は特に注意してください。構成依存関係の詳細は、「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

41 ページ・キャッシングの高度な手法の使用

ページ・キャッシングの高度な手法には、ページとBLOBのキャッシング、どこにキャッシングされるか、WebCenter SitesとSatellite Server両方のシステムでどのようにキャッシュから取得されるかが含まれます。

ページ・キャッシングの高度な手法の詳細は、次の項を参照してください。

- 高度なページ・キャッシングについて

- WebCenter Sitesキャッシュの構成

- BlobServerキャッシュの構成

- Satellite Serverキャッシュの構成

- CacheInfo文字列の構文

- キャッシングのベスト・プラクティス

41.1 高度なページ・キャッシングについて

キャッシングにより、ページの処理速度が上がります。レンダリングされたコンテンツをキャッシュすることにより、コンテンツが要求されるたびにレンダリングする必要がなくなります。これにより、レスポンス時間が短縮されます。

キャッシング・システムには、複数のレイヤーがあります。これにより、キャッシュされたオブジェクトを1つのキャッシュ・レベルで再生成でき、その一方で、別のキャッシュ・レベルにキャッシュされたコンテンツがクライアントに提供されます。WebCenter Sitesは内部レベルのキャッシュであり、Satellite Serverは外部レイヤーのキャッシュです。

41.2 WebCenter Sitesキャッシュの構成

WebCenter SitesとSatellite Serverでは両方とも、ページ、ページレットおよびBLOBがキャッシュされます。WebCenter Sitesには、CSページ・キャッシュ、BlobServerキャッシュ、SSキャッシュという3種類のレンダリング・エンジン・キャッシュが用意されています。すべてのキャッシュを次のように構成したり、空にしたりできます。

- WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュの最大キャッシュ・サイズの構成の詳細は、「キャッシュの最大サイズの構成」を参照してください。

- WebCenter SitesキャッシュおよびBlobServerキャッシュの有効期限の設定の詳細は、「個々のエントリの有効期限の設定」を参照してください。

- WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュのキャッシュからのオブジェクトの削除の詳細は、「キャッシュからのエントリの明示的削除」を参照してください。

WebCenter Sitesページ・キャッシュには、2つのレベルのキャッシングがあります。

- データベース内。

- メモリー内。メモリー・キャッシュは、データベース・キャッシュの透過的なサブセットですが、単独での構成が可能です。

この項には次のトピックが含まれます:

- キャッシュの最大サイズの構成

- 個々のエントリの有効期限の設定

- キャッシュからのエントリの明示的削除

41.2.1 キャッシュの最大サイズの構成

WebCenter Sitesのデータベース・キャッシュには、最大サイズ構成オプションはありません。ページ・キャッシュのメモリー・サブセットを使用すると、存在するエントリの最大数を指定できます。

- wcs_properties.jsonファイル内のcc.SystemPageCacheCSzプロパティに正の整数を設定し、キャッシュ内に存在できるエントリの最大数を指定します。

注意:

値を0に設定すると、すべてのエントリが追加され、即座に削除されます。ただし、これは避ける必要があります。

cc.SystemPageCacheCSzプロパティは-1に設定しないでください。

キャッシュでは、最低使用頻度(LRU)アルゴリズムを使用して、最大数に達したときにプルーニングするエントリを識別します。

最大サイズには、キャッシュに格納される総バイト数は反映されません。

41.2.2 個々のエントリの有効期限の設定

ページ・キャッシュ内のエントリのライフタイムは、cscacheinfo設定により決定されます。CacheInfoオブジェクトは、cscacheinfoフィールドに明示的に設定されていない値を構成ファイルから取得します。CacheInfoの構文については、「CacheInfo文字列の構文」を参照してください。

41.2.3 キャッシュからのエントリの明示的削除

WebCenter Sitesには、キャッシュからエントリを削除する方法が2つ用意されています。1つは手動、もう1つはCacheManagerを使用した自動的な方法です。

41.2.3.1 手動削除

CacheServerサーブレットを使用して、ページ・キャッシュからエントリを手動で削除できます。CacheServerには、次の2つのオプションが用意されています。

- キャッシュ全体をフラッシュします。

- 有効期限が切れた時点で、すべてのページのフラッシュを強制します。CacheServerのすべてフラッシュする機能を起動するためには、SiteCatalog表を破棄する権限を持つユーザーとしてログインし、CacheServerサーブレットの起動時にパラメータall=trueを指定する必要があります。パラメータを指定しないと、有効期限が切れたエントリ(有効期限が過去であるエントリ)がすべて、キャッシュからただちにクリアされます。有効期限がまだ切れていないエントリはクリアされません。

注意:

有効期限が切れたエントリは、たとえまだデータベース表の中にあったとしても、キャッシュから提供されることはありません。WebCenter Sitesでは、ページを表示する前に、キャッシュから取得されたすべてのページの有効期限がチェックされます。有効期限が切れたページをWebCenter Sitesが表示しようとすると、そのページはただちにキャッシュから削除され、新しいページが生成されます。

41.2.3.2 自動削除

CacheManagerは、WebCenter SitesのページおよびBLOBのキャッシュ・メカニズムと密接に結び付いているモジュールです。これにより、ページにロードされたアイテム、ページの有効期限、またはページに渡されるパラメータに基づいて、すべてのレンダリング・キャッシュのコンテンツを管理できるようになります。

CacheManagerのみが、完全に独立したドキュメントの対象になる場合もあります。その機能の概要はここで説明します。メソッドおよび必要な引数の詳細は、COM.FutureTense.Cache.CacheManager Javadocを参照してください。

1. CacheManagerは、2つのコンストラクタのうちのいずれかを使用してインスタンス化されます。そのうちの1つのコンストラクタは、現在登録されているすべてのSatellite ServerでCacheManagerを設定します。もう1つのコンストラクタでは、このCacheManagerのインスタンスが管理するSatellite Serverを指定できます。

2. 次に、ページとBLOBをCacheManagerに移入する必要があります。これは、次のメソッドのいずれかを使用して実行します。

setByCachedDate(ICS ics, boolean before, String timestamp)
setByItemDate(ICS ics, boolean before, String timestamp)
setPagesByArg(ICS ics, String paramName, String paramValue)
setPagesByID(ICS ics, String[] ids)

ページ・キャッシュ、BLOBキャッシュおよびSatelliteキャッシュのコンテンツは、互いに密接に結びついています。構成エラーがないかぎりは、Satellite Serverにキャッシュされたオブジェクトは、WebCenter Sitesキャッシュにも常に存在します。つまり、WebCenter Sitesでは、すべてのレンダリング・エンジン・キャッシュにすべてのエントリのレコードがあります。CacheManagerは、各キャッシュに情報を明示的に直接問い合せることなく、各キャッシュのコンテンツを管理するために、このレコードを使用します。

setByCachedDate(ICS ics, boolean before, String timestamp)

このメソッドでは、エントリが最後にキャッシュに追加された日付に基づいて、CacheManagerにエントリを移入できます。指定された日の前または後に変更されたエントリのすべてを移入するかどうかを選択できます。

setByItemDate(ICS ics, boolean before, String timestamp)

このメソッドでは、エントリのアイテムが最後に変更された日付に基づいて、CacheManagerにエントリを移入できます。setByCachedDate(ICS, boolean, String)と同様、指定された日の前または後にアイテムが変更されたエントリのすべてを移入するかどうかを選択できます。

setPagesByArg(ICS ics, String paramName, String paramValue)

このメソッドでは、(pagenameを含む)キャッシュ・キーにある名前と値のペアに基づいて、CacheManagerにエントリを移入できます。

setPagesByID(ICS ics, String[] ids)

このメソッドでは、キャッシュ内のページまたはBLOBに格納されたアイテムの正確なアイテムIDに基づいて、CacheManagerにエントリを移入できます。

完全に移入されると、CacheManagerはキャッシュのコンテンツを管理できるようになります。これは、次の4つの主なサービス・メソッドのうちのいずれかを使用して実行します。

- flushCSEngine(ICS ics, int mode)
このメソッドでは、WebCenter Sitesのページ・キャッシュとBLOBキャッシュから、CacheManagerに現在移入されているページとBLOBのすべてをフラッシュします。

- flushSSEngines(ICS ics)
このメソッドでは、Satellite Serverキャッシュから、CacheManagerに現在移入されているページとBLOBのすべてをフラッシュします。これは、適切な<page>タグおよび<blob>タグが埋め込まれたHTTPリクエストを、FlushServerサーブレットに送信することにより実行されます。Satellite Serverはこれらのタグを解釈し、キャッシュ・キーに変換して、対応するページをキャッシュからフラッシュします。

- refreshCSEngine(ICS ics, int mode)
このメソッドでは、オブジェクトを再生成してキャッシュに自動的に再移入するリクエストを、(ICS.ReadPageまたはICS.BlobServerを使用して)送信します。

- refreshSSEngines(ICS ics)
このメソッドでは、HTTPを使用してSatellite Serverにリクエストを送信して、ページを読み込ませます。返されたバイトは無視されますが、結果として、Satellite Serverキャッシュに再移入されます。

これらのメソッドを使用すると、パフォーマンスがきわめて高い動的サイトを可能にするツールである、二重バッファ・キャッシングを利用できます。二重バッファ・キャッシングの詳細は、「ページのデザインとキャッシングの理解」を参照してください。

41.3 BlobServerキャッシュの構成

BlobServerキャッシュは、オール・オア・ナッシングのキャッシュです。つまり、エントリはグローバルにキャッシュされるか、グローバルにキャッシュされないかのどちらかです。

セキュリティが有効な場合、またはbs.security=trueである場合、BlobServerキャッシングが無効になります。

この項には次のトピックが含まれます:

- 最大キャッシュ・サイズの構成に関する考慮事項

- 個々のエントリの有効期限の設定

- キャッシュからのエントリの明示的削除

41.3.1 最大キャッシュ・サイズの構成に関する考慮事項

WebCenter Sitesのwcs_properties.jsonファイル内のbs.bCacheSizeプロパティは、BLOBキャッシュに含まれるエントリの数を指定します。サイズに負の数が設定されると、BLOBキャッシュを無制限に増大することが許可されます。

41.3.2 個々のエントリの有効期限の設定

BlobServerは、キャッシュされたエントリの有効期限をサポートしていません。キャッシュされたオブジェクトはすべて、WebCenter Sitesのwcs_properties.jsonファイル内のbs.bCacheTimeoutプロパティで決められたタイムアウトの期間、キャッシュ内に存在します。負のタイムアウト値は、エントリがタイムアウトしないことを示します。正の整数は、オブジェクトがキャッシュ内に存在する期間(単位は分)を指定します。

41.3.3 キャッシュからのエントリの明示的削除

BlobServerを使用すると、個々のエントリまたはすべてのエントリをキャッシュからフラッシュできます。

41.3.3.1 手動削除

キャッシュからエントリを手動で削除するには、blobtableパラメータの名前をflushblobtableに変更します。これにより、残りのパラメータに対応するエントリがキャッシュから削除されます。

キャッシュからすべてのエントリを手動で削除するには、2つのオプションがあります。

- パラメータflushblobtables (sに注意)でBlobServerサーブレットを起動します。

- 前述のようにCacheServerサーブレットを起動します。この場合、すべてのページとすべてのBLOBがキャッシュからフラッシュされることに注意してください。

41.3.3.2 自動削除

BLOB依存アイテムはBLOBリンクが生成されたときに記録されるため、BLOBおよびページを管理するためにCacheManagerを起動できます。CacheManagerは常にBLOBとページを一緒に管理します。詳細は、「CacheManager」、「CacheManagerについて」および「CacheManagerの有効化」を参照してください。

注意:

BLOBを提供する前に、開発者はアセットのステータスをチェックする必要があります。これにより、アセットが無効化された後に、BlobServerによってBLOBが提供されるという問題を回避できます(この動作は、ベーシック・アセットでのみ発生します)。

41.4 Satellite Serverキャッシュの構成

汎用的なSatellite Serverキャッシュ構成は、wcs_properties.jsonファイル内で行われます。ただし、キャッシュ構成は多くの場合、オブジェクト単位でオーバーライドされます。

41.4.1 キャッシュの最大サイズの構成

- wcs_properties.jsonファイル内のcache_maxプロパティを、キャッシュ内に一度に格納できるエントリの最大数に更新します。
このプロパティに負の整数を設定すると、キャッシュのサイズは制限されません。正の整数は、キャッシュに格納できるエントリの最大数を指定します。

41.4.2 キャッシュからのエントリの明示的削除

この項で説明しているように、個々のエントリは、手動で、またはCacheManagerを使用して、Satellite Serverキャッシュから削除できます。

- 手動削除: Satellite Serverには、FlushServerと呼ばれるサーブレットがあります。(username、password、resetの各パラメータを指定して)このサーブレットにGETリクエストを送信することにより、Satellite Serverキャッシュのコンテンツのすべてをフラッシュできます。GETを使用して個々のエントリはフラッシュできません。

- 自動削除: CacheManagerを使用してSatellite Serverキャッシュをフラッシュできます。対応するオブジェクトがWebCenter Sitesにキャッシュされた場合、CacheManagerはSatellite Serverのエントリのみをフラッシュすることができます。これは、WebCenter SitesがSatellite Serverキャッシュのコンテンツを追跡する方法によるものです。
CacheManagerを使用してSatellite Serverキャッシュがフラッシュされる場合、対応するオブジェクトがWebCenter Sitesにキャッシュされます。対応するオブジェクトが必要となるのは、WebCenter SitesがSatellite Serverキャッシュのコンテンツを追跡する方法によるものです。

Satellite Serverキャッシュを処理するための該当するCacheManagerメソッドは、flushSSEngines()およびrefreshSSEngines()です。メソッドの詳細は、「キャッシュからのエントリの明示的削除」を参照してください。

41.5 CacheInfo文字列の構文

SiteCatalogのcscacheinfoフィールドおよびsscacheinfoフィールドには、CacheInfo文字列が移入されます。この項では、2つの部分で構成されたカンマ区切り文字列のフォーマットにより、ページをキャッシュするかどうか、およびページがいつ期限切れになるかを決定する方法について説明します。

サンプル値は次のとおりです。

false
true
true,*
true,~4
true,@1987-06-05 04:32:10
true,#00:00:00 */*/*
*
(blank)

CacheInfo文字列: 最初の部分

CacheInfoの最初の部分は、次の値のいずれかである必要があります。

false
true
(blank)*

- 値がfalseの場合、ページはキャッシュされません。

- 値がtrueの場合、2番目のエレメントに指定された情報に従って、ページがキャッシュされます。

- 値が空白の場合、wcs_properties.jsonのcs.alwaysusediskプロパティがチェックされます。このプロパティがyesに設定されている場合、空白値はtrueと同じ動作をするものと解釈されます。この値がno (デフォルト値)に設定されている場合、空白値はfalseと同じ動作をするものと解釈されます。

- 値が*の場合、これは空白として処理されます。

CacheInfo文字列: 2番目の部分

これは、キャッシュされるページをキャッシュからいつ削除するかを記述します。最初のエレメントがfalseの場合(またはfalseと解釈される場合)、2番目のエレメントは無視されます。

ページの有効期限を指定する方法には、次の3つがあります。

page timeout (in minutes)
instant in time expiration
cron-like TimePattern expiration

使用可能な値は次のとおりです。

~<number of minutes>
@<date in JDBC format>
#<COM.FutureTense.Util.TimePattern format>
*
(blank)

ページ・タイムアウト

2番目のエレメントがチルダ(~)で始まる場合、続く値は整数である必要があります。この整数の値は、ページが最初に作成されてからキャッシュ内に残る期間(単位は分)です。負の値または0は、ページの有効期限が切れない(ページが永久にキャッシュ内に残る)ことを示します。

絶対時間

2番目のエレメントがアット記号(@)で始まる場合、続く値はJDBC日付文字列フォーマット、つまりYYYY-MM-DD HH:MM:SSのフォーマットで表現される日付である必要があります。その日付が過ぎると、キャッシュされたページはキャッシュからフラッシュされ、そのページはキャッシュされていない状態になります。

TimePattern

TimePatternフォーマットは、ページ・キャッシュの有効期限の記述のためにサポートされています。2番目のエレメントがハッシュタグ(#)で始まる場合、続く値は、パブリック・クラスCOM.FutureTense.Util.TimePatternで定義された有効なTimePattern文字列である必要があります。

一般的に、TimePattern構文は、ほとんどのUNIX cron表で使用されるフォーマットに対応しています。これにより、特定の時間または毎日、毎月、毎週、毎曜日および毎年で、有効期限を指定できます。

TimePatternフォーマットは、ページ有効期限のために最も広く使用されるフォーマットになると考えられています。

ワイルドカード

2番目のエレメントが*である場合、「ページ・タイムアウト」で記述したように、ページはタイムアウトによる有効期限切れの動作になります。タイムアウト値は、wcs_properties.jsonファイルのcs.pgCacheTimeoutプロパティから読み込まれます。

空白

2番目のエレメントが空白の場合、*と同じ動作が適用されます。

41.6 キャッシングのベスト・プラクティス

WebCenter SitesのWebページには、リモートSatellite Serverによって処理されるキャッシュ済プライマリ・ページレットが最大で6から10含まれることが理想的です。これは、キャッシュ済ページレットが多すぎると、キャッシュの容量オーバーになり、システムのパフォーマンスに悪影響を及ぼすからです。

次の項では、キャッシュの容量オーバーを阻止し、レスポンス時間とスループットを向上させる方法について説明します。

- ページ当たりのページレット数の削減

- ページ間でのキャッシュの共有

41.6.1 ページ当たりのページレット数の削減

- ページ当たりの未キャッシュ・ページレットの数が少なくなるようにページ・テンプレートを設計します。<render:calltemplate>タグのデフォルトのstyle=pageletが常に最善の選択肢であるとはかぎりません。ページ当たりのページレットの数を削減すると、レスポンス時間とスループットが向上します。

- すでにページ・テンプレートがあり、これらの再設計が実現可能でない場合は、リモートSatellite Serverから、共存しているSatellite Serverに切り替えます。WebCenter Sitesサーブレットと、共存しているSatellite Serverの間のラウンドトリップは必要ありません。ページ上に存在する未キャッシュ・ページレットの数が多いほど、共存しているSatelliteServerの方がリモートSatellite Serverよりレスポンス時間が向上する可能性が高くなります。

- キャッシュ済ページレットを結合してこれらの数を削減します。最初に、各<render:calltemplate>コールでpageletのデフォルトのスタイル属性値を使用しているかどうかをチェックします。<render:calltemplate>コールをエレメント・コールとしてインライン化(style=element)することにより、ページレットの数を削減します。
style="element"を指定する場合の一般的なユースケースは、外部のコール元のテンプレート(ページまたはページレット)が内部のコール先のページレット・テンプレートと同じc、cidを共有する場合です。キャッシュ済オブジェクトは両方とも同時に期限切れになる(つまり、これらのアセットの依存性は同じである)ため、これらを個別にキャッシュするメリットはありません。

- サブページレットをリモートSatellite Server上で直接キャッシュするかわりに、style="embedded"バリアントを使用してContentServerサーブレット上でページレット・キャッシュを介してサブページレットをバックアップします。つまり、<render:calltemplate>コールをContentServerページ・フラグメントとしてインライン化(style=embedded)します。
たとえば、Webページ内の製品サマリーのリストに10のアイテムが含まれる場合、これは、これらの各アイテムにデフォルトのstyle="pagelet"が適用されることを意味します。ページレットのスタイルが原因で、このリストをレンダリングするためにWebCenter SitesサーブレットとリモートSatellite Server間で10回のラウンドトリップが必要になります。ただし、外部リスト・テンプレート自体をキャッシュするようにしながら、サブページレットに対する既存の<render:calltemplate>コールがstyle="embedded"を使用するよう設定されている場合は、製品リスト・ページレット全体に対して必要なのは1回のラウンドトリップのみです。これは、外部テンプレートのみがリモートSatellite Serverによって処理され、残りのサブページレットはContentServerサーブレット上でのみ処理されるからです。

41.6.2 ページ間でのキャッシュの共有

キャッシュ済ページレットすべてに対してcidが渡される場合、キャッシュはWebページ間で共有されません。たとえば、1つのサイトに5,000のWebページが含まれ、これらすべてによってcidがleftnavに渡される場合があります。また、コール元のWebページとは関係なく5,000のleftnavがキャッシュされます。このシナリオの場合、次の2つの状況が考えられます。

- サイト・ナビゲーション・ツリー内の単一のページ・アセットが編集およびパブリッシュされる場合、5000のleftnavはすべてキャッシュされません。これは、パブリッシュされたばかりのページ・アセットにより、すべてのleftnavページレットに対して依存性が記録されるからです。

- 単一の記事アセットが編集およびパブリッシュされる場合、キャッシュ済外部Webページ(通常はレイアウト・テンプレート)とleftnavがキャッシュされず、再評価が必要になります。cidはleftnavに渡されるため、Content Serverは、外部Webページだけでなくleftnavもキャッシュしません。記事はサイト・ナビゲーション階層とは関係ないため、このアプローチは効率的ではありません。

これらの状況でキャッシュの容量オーバーを回避するには、cidのみではなくページのcidも常に使用されるようleftnavを変更します。コール元のテンプレートが所属先のページを確認することにより、これをキャッシュ引数として渡すことができるようにする必要があります。ページのcidのみがキャッシュ依存性をページレットに記録し、他のページ・アセットは記録しないようにする必要があります。擬似コードは、次のとおりです。

If c is not "Page"
then
Calculate the site navigation PageNode by doing a reverse look up of the Page from the current asset's cid.
Alternatively, have the site navigation Page as an attribute of the current asset and simply fetch it.
then calculate the PageNode from that
else
Calculate the PageNode from the current Page cid.

この方法により、このページレットのキャッシュ済バージョンが所有者の関連ページ・アセットのみにバインドされます。サイト・ナビゲーション・ツリー内の単一のページ・アセットが編集およびパブリッシュされる場合、cid=<the current Page asset>である単一のleftnavのみがキャッシュされません。単一の記事アセットが編集およびパブリッシュされる場合、キャッシュ済外部Webページ(通常はレイアウト・テンプレート)のみの再評価が必要になります。

編集者がシステムを毎日更新および変更する場合、開発者の選択内容がシステムの効率性に多大な影響を及ぼします。提案された改善を行わない場合、単一のアセットを編集するだけでも、パブリッシュ時にシステムが行う処理が必要以上に増える原因となる可能性があります。各ページレットに明示的に渡される引数は、パフォーマンス全体に直接影響を及ぼします。

第VII部 コンテンツ管理システムへの作業内容の移行

次の項では、XMLPostユーティリティ、およびXMLPostユーティリティとBulkLoaderユーティリティ用として使用される用のポスト・エレメントを使用してアセットをインポートする一般的なプロセスについて説明します。

- 任意タイプのアセットのインポート

- フレックス・アセットのインポート

- BulkLoaderユーティリティによるフレックス・アセットのインポート

42 任意タイプのアセットのインポート

XMLPostユーティリティを使用すると、すべてのタイプのアセットをWebCenter Sitesデータベースにインポートできます。

アセットのインポートの詳細は、次の項を参照してください。

- XMLPostユーティリティを使用したアセットのインポートについて

- XMLPost構成ファイルの使用

- XMLPostソース・ファイルの使用

- XMLPostユーティリティの使用

- RemoteContentPostとPreUpdateのカスタマイズ

- XMLPostのトラブルシューティング

フレックス・アセット・データ・モデルの使用時のアセットのインポートの詳細は、「フレックス・アセットのインポート」を参照してください。

42.1 XMLPostユーティリティを使用したアセットのインポートについて

データ設計を決定し、アセット・タイプを作成し、これらを開発システムでテストし、管理システムに移動したら、次の手順は、アセット(コンテンツ)を現在のソースから管理システム上のデータベースにインポートすることです。たとえば、リモートで生成されたコンテンツ(Wire Feedサービスまたは他のソースを使用して生成されたコンテンツ)を管理システム上のWebCenter Sitesデータベースにインポートします。

XMLPostユーティリティを使用して、データをWebCenter Sitesデータベースにインポートします。このユーティリティは、WebCenter SitesのFormPoster Javaクラスに基づき、WebCenter Sitesベースの製品で提供されます。これは、HTTP POSTプロトコルを使用してデータをインポートします。アセットをインポートするには、WebCenter Sitesで用意されているインポート(ポスト)・エレメントのいずれかをそのアセット・タイプに応じて呼び出すように、XMLPostユーティリティに指示します。

このプロセスでは次の4つのものが必要です。

- WebCenter Sitesに付属しているXMLPostユーティリティ。

- ポスト・エレメント。WebCenter Sitesには、RemoteContentPostという名前のポスト・エレメントが用意されています。WebCenter Sitesには、「フレックス・アセットのインポート」で説明している3つの追加のポスト・エレメントも用意されています。

- ファイル拡張子が.iniの構成ファイル。インポートする予定のアセット・タイプごとに1つの構成ファイルを作成します。このファイルには、ソース・ファイルに含まれていると想定されるもの(XMLPostによって検出されるタグの種類)、提供されたデータの処理方法、およびデータをインポートするために使用するインポート(ポスト)・エレメントが記述されています。

- ソース・ファイル。インポートするアセットごとに個別のソース・ファイルを用意します(整形式XMLファイル)。ファイル内の各タグは、そのアセット・タイプのフィールドを指定します。このタグに含まれている情報は、その列に書き込まれるデータです。

XMLPostユーティリティは、アセット・タイプに提供されるデータを解釈する方法を確認するために構成ファイルを解析します。また、ソース・ファイルを解析して、各フィールド値の名前と値のペアを作成し、これらの名前と値のペアをICS変数としてRemoteContentPostエレメントに渡します。RemoteContentPostエレメントは、これらの変数に基づいてアセットを作成します。

XMLPostユーティリティと組み合せて機能する独自のポスト・エレメントを作成することもできます。ただし、アセットをインポートする場合は、WebCenter Sitesに用意されているポスト・エレメントで十分です。

注意:

セキュリティを向上するために、RemoteContentPostページの名前を変更してシステムへのハッキング試行を防止する必要があります。

42.1.1 開発者が実行する手順

この項では、XMLPostユーティリティを起動する前に開発者が実行する手順と、XMLPostユーティリティが実行する処理について概述します。

WebCenter Sitesデータベースにアセットをインポートするときに実行する一般的な手順は、次のとおりです。

1. インポートするアセットのタイプとソース・ファイル内で使用されているタグを指定する構成ファイルを作成します。
このファイルでは、いくつかの構成プロパティも設定します。これには、XMLPostで使用するポスト・エレメントのSiteCatalogエントリの名前が含まれます。すべてのアセットについて、このポスト・エレメントの名前はRemoteContentPostになります。フレックス・アセットのポスト・エレメントについては、「フレックス・アセットのインポート」を参照してください。

構成ファイルはこのアセット・タイプに固有のものです。アセット・タイプごとに別個の構成ファイルを用意する必要があります。

2. インポートするデータのソース・ファイルを作成します。アセットごとに別個のソース・ファイルを作成します。

3. ソース・ファイルと構成ファイルを管理システム上のディレクトリ内に配置します。

4. そのディレクトリから、ソース・ファイルとこれらのソース・ファイル用に使用する構成ファイルを指定して、XMLPostユーティリティを起動します。

42.1.2 XMLPostとWebCenter Sitesが実行する処理

XMLPostユーティリティを起動してソース・ファイルをインポートした後に、図42-1およびこの図に続く手順に示すプロセスが開始されます。

図42-1 XMLPostユーティリティのプロセス図

1. XMLPostユーティリティは構成ファイルを解析します。

2. XMLPostはソース・ファイルを解析して、ソース・ファイルで指定された各フィールド値の名前と値のペアを作成します。

3. XMLPostは、構成ファイルから渡されたページ名にこれらの名前と値のペアをICS変数としてポスト(HTTP POST)することで、FormPoster Javaクラスを呼び出します。ベーシック・アセット・タイプをインポートする際のページ名は次のとおりです。

OpenMarket/Xcelerate/Actions/RemoteContentPost

4. WebCenter Sitesは、そのページをSiteCatalog表内で検索し、RemoteContentPostページのルート・エレメントを呼び出します。このルート・エレメントはデフォルトで同じ名前(RemoteContentPost)を持ちます。

5. RemoteContentPostエレメントは、ソース・ファイル内のデータを変数として、該当するタイプのアセットのPreUpdateエレメントに渡します。

6. PreUpdateエレメントは、そのアセットの変数値を設定してRemoteContentPostエレメントに戻ります。

7. RemoteContentPostエレメントはそのアセットを作成します。

8. WebサーバーはHTMLのストリームをXMLPostに返し、XMLPostはそのストリームを解析してインポート操作が成功したかどうかを判断して、結果を構成ファイルで指定されたテキスト・ファイルに記録します。

9. インポートするアセットのアセット・タイプが検索エンジンを使用する場合、RemoteContentPostは新しいエレメントを索引付けします。

10. 構成ファイルで特定のパラメータを設定した場合、RemoteContentPostは正常にインポートされたアセットのソース・ファイルを削除します。

42.2 XMLPost構成ファイルの使用

XMLPostの構成ファイル内には、次の3つのタイプのプロパティがあります。

- データベースと環境に関する情報をXMLPostに提供するプロパティ。これらのプロパティは、独自のポスト・エレメントを作成した場合でも変化しません。

- ポスト(インポート)・プロセスの構成値を提供するプロパティ。この章では、RemoteContentPostエレメントが正常に機能するために指定する必要のあるプロパティについて説明します。
プロパティの例としてあげられるのは、RemoteContentPostを呼び出すページのURL、データベース内のアセット・タイプ表に対する書込み権限をXMLPostに付与するユーザー名とパスワード、インポートするアセット・タイプの名前、エラーのログ記録方法、インポートするすべてのアセットについて同じであるデータ値などです。

- ソース・ファイル内で使用されているタグを指定するプロパティ。

特定の情報は、構成ファイルのRemoteContentPostセクションまたはソース・ファイル・セクションで構成できます。これらの情報としては、アセットが所属するサイトや、アセットに割り当てられるワークフローなどがあります。

たとえば、1つのコンテンツ管理サイトで作業している場合や、同じサイトに属している新しいをインポートする場合は、そのサイトの名前を構成セクションで指定することにより、その情報を各ソース・ファイルで繰り返し指定する必要がないようにします。複数のコンテンツ管理サイトがある場合は、アセットが属するサイトを個別のソース・ファイル内で指定します。

この項には次のトピックが含まれます:

- XMLPostのプロパティの構成

- ポスト・エレメントの構成プロパティ

- ソース・ファイルの構成プロパティ

- XMLPostのサンプル構成ファイル

42.2.1 XMLPostの構成プロパティ

表42-1では、XMLPostユーティリティが必要とするデータベース接続情報や他の一般的な構成指示内容を指定するプロパティを示しています。

表42-1 XMLPostの構成プロパティ

プロパティ

説明

xmlpost.xmlfilenamefilter

必須。

ソース・ファイルのファイル拡張子。通常はxmlに設定します。

例:

xmlpost.xmlfilenamefilter: .xml

xmlpost.proxyhost

オプション。

アセットのインポート先にするWebCenter Sitesデータベースと開発者のマシンの間にファイアウォールが配置されている場合は、このプロパティを使用してプロキシ・サーバーのホスト名を指定します。

例:

xmlpost.proxyhost: nameOfServer

xmlpost.proxyport

オプション。

アセットのインポート先となるWebCenter Sitesデータベースと開発者のマシンの間にファイアウォールが配置されている場合は、このプロパティを使用して、XMLPostの接続先となるプロキシ・サーバー上のポート番号を指定します。

例:

xmlpost.proxyport: 80

xmlpost.url

必須。

ポスト・エレメントのページ・エントリのURLの最初の部分。

XMLPostは、このプロパティで指定された値をページ名postargname(後述)で指定された値の前に付加することで、ポスト・エレメントのURLを作成します。

このプロパティで指定する値は、次の規則に従う必要があります。

- WebCenter Sitesデータベースが配置されているサーバーの名前。

- サーバー上にインストールされたアプリケーション・サーバー・ソフトウェアに適したCGIパス。WebLogicとWebSphereの場合は、このパスは/servlet/です。

- ContentServerサーブレットの名前。

例:

xmlpost.url: http://servername/servlet/ContentServer

xmlpost.logfile

オプション。

各ソース・ファイルのインポート(ポスト)結果を記録するファイルの名前。

各ソース・ファイルは、ポスト・リクエストを通じてWebCenter Sitesデータベースにポストされます。ポスト要求がWebサーバーから戻ってくると、XMLPostはWebサーバーが返したHTMLストリームを解析して、postsuccessパラメータとpostfailureパラメータを探します。次にXMLPostは、このパラメータで指定されたファイルに結果を書き込みます。

例:

xmlpost.logfile: ArticlePost.txt

xmlpost.success

オプション。

ポストが成功したかどうかを判断するために応答内で検索する文字列。

例:

xmlpost.success: Success!

xmlpost.failure

オプション。

ポストが失敗したかどうかを判断するために応答内で検索する文字列。

例:

xmlpost.failure: Error

xmlpost.deletefile

オプション。

WebCenter Sitesデータベースに正常にインポートされたソース・ファイルを削除するかどうか。有効な値はy (yes)またはn (no)です。デフォルトでは、ソース・ファイルは削除されません。

例:

xmlpost.deletefile: y

42.2.2 ポスト・エレメントの構成プロパティ

表42-2は、RemoteContentPostページにポストされる必要のある(およびRemoteContentPostエレメントに渡される必要のある)情報を指定する引数を示しています。これらの引数の値は、RemoteContentPostページにポストされるURLに付加されます。これらの引数は構成ファイル内でどのような順序でもかまいません。

表42-2 ポスト・エレメントの構成プロパティ

プロパティ

説明

xmlpost.numargs

必須。

ページ名は、URLに付加される名前と値のペアとして構成ファイルからXMLPostに渡されるいくつかの必須の変数内の主な変数です。このプロパティ(xmlpost.numargs)を使用して、構成ファイルによって渡される変数の数をXMLPostに通知します。

例:

xmlpost.numargs: 7

これらの名前と値のペアで独自のカスタム変数を指定することもできます。

xmlpost.argname1: pagename

必須。

RemoteContentPostエレメントのページ名。通常は、pagename引数はxmlpost.argname1として指定します。

例:

xmlpost.argname1: pagenamexmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost

xmlpost.argname2: AssetType

必須。

ソース・ファイル内で定義されているアセットのアセット・タイプ。通常は、AssetTypeはxmlpost.argname2として指定します。

例:

xmlpost.argname2: AssetType

xmlpost.argvalue2: Collection

AssetType引数の値は、このタイプのアセットが格納されている表の表名と完全に一致している必要があります。

xmlpost.argname3: authusername

必須。

アセットのインポート先になるWebCenter Sitesデータベースにログインするために、XMLPostが使用するユーザー名。通常は、authusernameはxmlpost.argname3として指定します。

例:

xmlpost.argname3: authusername

xmlpost.argvalue3: editor

指定するユーザー名は、インポートするタイプのアセットが格納されている表に対する書込み権限を持っている必要があります。(つまり、そのユーザー名には適切なACLが割り当てられている必要があります。)

xmlpost.argname4: authpassword

必須。

アセットのインポート先となるWebCenter SitesデータベースにログインするためにXMLPostが使用するユーザーのパスワード。通常は、authpasswordはxmlpost.argname4として指定します。

例:

xmlpost.argname4: authpassword

xmlpost.argvalue4: xceleditor

xmlpost.argname5: xmlpostdebug

オプション

xmlpost.logfileプロパティで指定されたXMLPostログ・ファイルに書き込まれる結果情報にデバッグ情報を含めるかどうか。

このプロパティは任意の値に設定できます。例:

xmlpost.argname5: xmlpostdebug

xmlpost.argvalue5: on

注意: デバッグを有効にする場合は、xmlpost.logfileプロパティの値を必ず含めてください。

xmlpost.argname6: inifile

オプション。

WebCenter Sitesデータベースに接続する際に使用するiniファイルの名前。通常は、inifileはxmlpost.argname5として指定します。

例:

xmlpost.argname6: inifile

xmlpost.argvalue6: futuretense.ini

xmlpost.argname7: publication

オプション。

このプロパティは必須ではありませんが、インポートする各アセットのサイトを指定する必要があります。

システムで単一のコンテンツ管理サイト(パブリケーション),を使用している場合や、このタイプのすべてのアセットを同じサイト上で有効にする必要がある場合は、この引数を使用してそのサイトの名前を指定します。

例:

xmlpost.argname7: publicationxmlpost.argvalue7: Fiscal News

複数のコンテンツ管理サイトを使用する場合、個別のソース・ファイル内でアセットごとにサイトの値を指定する必要があります。詳細は、「ソース・ファイルの構成プロパティ」を参照してください。

xmlpost.argname8:startmenu

オプション。

ワークフローを使用している場合に、インポートするアセットのすべてに同じワークフローを割り当てる場合は、この引数を使用してそれらのアセットのスタート・メニュー・ショートカットを設定します。(これはワークフローIDを新しいアセットに割り当てるスタート・メニュー・ショートカットです。)

例:

xmlpost.argname8: startmenu

xmlpost.argvalue8: New Article

このタイプのアセット用の複数のワークフローがある場合は、各アセットのスタート・メニュー・ショートカットの値を個別のソース・ファイル内で指定する必要があります。詳細は、「ソース・ファイルの構成プロパティ」を参照してください。

42.2.3 ソース・ファイルの構成プロパティ

構成ファイル内のソース・ファイル・セクションでは、ソース・ファイル内で使用されているタグが指定されます。タグは、このタイプのアセットが格納されている表の列名を表します。タグのペアの内側にあるコンテンツは、その列に書き込まれる情報です。構成ファイルには、アセット・タイプのプライマリ記憶域表の列ごとにタグをリストする必要があるため、アセット・タイプごとに別個の構成ファイルを用意する必要があります。

この項には次のトピックが含まれます:

- サイトのプロパティ

- アセット・タイプのプロパティ

42.2.3.1 サイトのプロパティ

アセット・タイプに対して使用可能なタグに加えて、表42-3では、アセットを関連付けるサイトやアセットで使用するワークフローを指定できる別のタグについて説明します。

表42-3 サイトのプロパティ

サイト・タグのプロパティ

値

説明

postpublication

yまたはn

(yesまたはno)

オプション。

アセットが属するサイトを指定するサイト名をソース・ファイルで示すことを指定します。

例:

postpublication: y

ソース・ファイル内でpublicationタグを使用して指定されたサイト(パブリケーション)値は、構成ファイルのXMLPostセクションのpublication引数で指定された値よりも優先されます。

postprimarypubid

yまたはn

(yesまたはno)

オプション。

アセットが属するサイトを指定するpubid (サイトの一意のID)の値をソース・ファイルで示すことを指定します。

例:

postprimarypubid: y

postpublist

yまたはn

(yesまたはno)

オプション。

アセットを共有するサイトのリストをソース・ファイルで示すことを指定します。

例:

postpublist: y

poststartmenu

yまたはn

(yesまたはno)

オプション。

アセットをワークフロー・プロセス内に配置するスタート・メニュー・ショートカットの値をソース・ファイルで示すことを指定します。

例:

poststartmenu: y

インポートするすべてのアセットについてサイトまたはワークフローが同じである場合は、サイトまたはワークフローの値を引数として構成ファイルのXMLPostセクションで指定できます。そうすることで、同じ情報をすべてのソース・ファイルで繰り返し指定する必要がなくなります。

42.2.3.2 アセット・タイプのプロパティ

アセット・タイプに固有のタグを設定するには、そのタイプのアセットのデータベース表の各列のタグを指定します。ただし、構成ファイル内のすべてのタグでタグ付けされたデータをソース・ファイルに含める必要はありません。(当然ながら、ソース・ファイルには必須フィールドのデータを含める必要があります。)

フィールド(列)を表す各タグについて、そのタグの名前を指定するとともに、必要に応じてそのタグの追加の処理プロパティを指定します。タグの名前は、対応するフィールド(列)の名前です。追加のプロパティについては、タグの名前の前に単語を付加するという規則に従う必要があります。

表42-4では、アセット・タイプに固有のタグを指定する方法を説明しています。

表42-4 アセット・タイプのプロパティ

タグのプロパティ

値

説明

posttagname

yまたはn

(yesまたはno)

必須。

タグの名前を指定します。この名前は、そのタグが表しているフィールドの名前と完全に一致している必要があります。

たとえば、nameフィールドには、このタグのプロパティを次のように指定します。

postname: y

trunctagname

N

(integer)

オプション。

このタグでマークされたソース・ファイル内のデータを途中で切り捨てるかどうか。

例:

truncname: 64

XMLPostが<name>タグ内で64文字を超える文字列を検出した場合は、64文字を超える部分を切り捨てて、残った64文字の文字列を変数に格納します。

notrimtagname

yまたはn

(yesまたはno)

オプション。

このタグの先頭または末尾の空白を削除するかどうか。

空白を保持するには、このプロパティをy (yes)に設定します。

例:

notrimname: y

このプロパティを空白のままにすると、XMLPostはデフォルトでこのタグの空白を削除します。

multitagname

combine

または

separate

このプロパティは、単一のソース・ファイル内で同じタグが複数回使用されている場合は必須です。

ソース・ファイル内で同一のタグが複数回使用されている場合に、これらのタグのデータを格納する変数の数を決定します。

これをcombineに設定した場合、すべてのタグのデータは、各値がカンマで区切られた形で(カンマ区切り文字列として)同じ変数に格納されます。

このプロパティをseparateに設定した場合、各タグのデータは別々の変数に格納されます。これらの変数を識別するために、seedtagnameで指定した値が変数名の後ろに付加されます。

たとえば、keywordフィールド(列)の場合は、次のようになります。

- multikeyword: combineと設定した場合、XMLPostは、keywordタグでマークされたすべての値を同じkeyword変数に格納します。

- multikeyword: separateおよび seedkeyword: 1と設定した場合、XMLPostは各値を別々の変数に格納します。最初に検出された値は、keyword1という名前の変数に格納されます。2番目に検出された値は、keyword2という名前の変数に格納され、それ以降の値も同様です。

seedtagname

seed value

このプロパティは、multitagnameがseparateに設定されている場合は必須です。

同一のタグが複数回使用されていて、これらのタグ内のデータを別々の変数に格納する場合に、その変数名の末尾に付加される連続番号の最初の番号を指定します。multitagnameの説明を参照してください。

例:

multikeyword: separate

seedkeyword: 1

filetagname

yまたはn

(yesまたはno)

このプロパティは、タグがアップロード・フィールド(URL列またはBLOB)を表している場合は必須です。

タグがURL列を持つフィールドを表している場合は、このプロパティを使用する必要があるとともに、ソース・ファイルでは、RemoteContentPostによってその列にアップロードするファイルの名前を指定する必要があります。

たとえば、imagefileアセット・タイプは、urlpictureという名前のアップロード・フィールドを備えています。このimagefileアセット・タイプの構成ファイルには、次のプロパティが含まれます。

posturlpicture: y

fileurlpicture: y

この場合は、imagefileアセットのソース・ファイルでは、urlpictureフィールドの値を次のように指定します。

<urlpicture>relative_path_to/filename.jpg

</urlpicture>

ファイルの場所は、XMLPostユーティリティを実行しているディレクトリを基準にした相対パスで指定する必要があります。

42.2.4 XMLPostのサンプル構成ファイル

ここでは、Fiscal Newsという名前のサイトのimagefileアセットをインポートするために使用するimagefile.iniという名前のサンプル構成ファイルを示します。

xmlpost.xmlfilenamefilter: xml
#xmlpost.xmlproxypost: Future
#xmlpost.xmlproxyport: 80
xmlpost.url: http://localhost/servlet/ContentServer
xmlpost.numargs: 6
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost
xmlpost.argname2: AssetType
xmlpost.argvalue2: ImageFile
xmlpost.argname3: authusername
xmlpost.argvalue3: user_author
xmlpost.argname4: authpassword
xmlpost.argvalue4: user
xmlpost.argname5: inifile
xmlpost.argvalue5: futuretense.ini
xmlpost.argname6: publication
xmlpost.argvalue6: FiscalNews

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: ImageFilePost.txt

postpublication: y
postprimarypubid: y
postpublist: y

postcategory: y
truncategory: 4

postpath: y
truncpath: 255

postname: y
truncname: 32

posttemplate: y
trunctemplate: 32

postsubtype: y
truncsubtype: 24

postfilename: y
truncfilename: 64

poststartdate: y

postdescription: y
truncdescription: 128

postsource: y

posturlpicture: y
fileurlpicture: y

posturlthumbnail: y
fileurlthumbnail: y

postmimetype: y
postwidth: y
postheight: y
postalign: y
postalttext: y

postkeywords: y
multikeywords: combine
trunckeywords: 128

postimagedate: y

42.3 XMLPostソース・ファイルの使用

ソース・ファイルは、Document Type Definition (DTD)ファイルを必要としない整形式XMLで構成されている必要があります。実際には、構成ファイルは、ソース・ファイル内で処理されるタグを定義することでDTDファイルのような役割を果します。

ソース・ファイル内のデータは、そのタイプのアセットが格納されている表の列名と一致する名前を持つタグによってタグ付けされている必要があります。たとえば、imagefileアセットのソース・ファイルでは、name、caption、picutureurlなどの名前を持つタグが使用されています。

この項では、ソース・ファイルに含める必要のある内容と、XMLPostがソース・ファイルに対して実行する処理について説明します。ここでは、XMLソース・ファイルの生成を自動化する方法は説明しません。ソース・ファイルの作成方法は、データのソースと、そのデータをXMLファイルに変換するために使用するツールによって異なります。

この項には次のトピックが含まれます:

- XMLPostのサンプル・ソース・ファイル

- XMLPostとファイル・エンコード方式

42.3.1 XMLPostのサンプル・ソース・ファイル

ここでは、imagefileアセットのサンプル・ソース・ファイルを示します。このファイル内のタグは、「XMLPostのサンプル構成ファイル」に示したサンプル構成ファイルで定義されています。

<document>
<name>High Five 25</name>
<keyword>Five</keyword>
<category>a</category>
<artist>by Ann. Artist</artist>
<alttext>Congratulations</alttext>
<align>CENTER</align>
<caption>A man extends <keyword>congratulations</keyword> with a boy.</caption>
<pictureurl>/images/eZine/highfive.jpg</pictureurl>
</document>

データを渡す(ポストする)方法

ソース・ファイル内のXMLタグのペアの内側にあるすべてのテキストは、Variables.tagnameという構文規則に従った変数として、XMLPostからRemoteContentPostエレメントに渡されます。

たとえば、次のコードでは、

<name>High Five 25</name>

このコード行は、Variables.nameとしてRemoteContentPostに送信され、nameの値はHigh Fiveという文字列になります。

42.3.2 XMLPostとファイル・エンコード方式

ソース・ファイル内のデータに使用されているファイル・エンコード方式が、WebCenter Sitesシステムのデフォルト・ファイル・エンコード方式ではないが、データベースがその文字セットに対応している場合は、ソース・ファイルの先頭のXMLバージョン文で、その代替のファイル・エンコード方式を指定します。次に例を示します。

<?xml version= "1.0" encoding="UTF-8" ?>

42.4 XMLPostユーティリティの使用

XMLPostユーティリティは、次のいずれかの方法で起動できます。

- コマンドラインから

- スクリプト・ファイルまたはバッチ・ファイルから

- プログラムから

どの方法でXMLPostを起動する場合でも、次の情報を提供する必要があります。

- 使用する構成ファイルの名前。

- ソース・ファイル。ソース・ファイルは、単一のファイルとして、ファイルのリストとしてまたはファイルのディレクトリとして指定できます。

この項には次のトピックが含まれます:

- 開始する前に

- コマンドラインからのXMLPostの実行

- ソース・ファイルの識別

- バッチ・プロセスとしてのXMLPostの実行

- プログラムからのXMLPostの実行

42.4.1 開始する前に

- XMLPostユーティリティを使用する前に、次の条件が満たされている必要があります。

- 使用するアセット・タイプが作成されていること。(作成されていない場合は、アセットをインポートする先となるデータベース表がありません。)

- 使用するコンテンツ管理サイトが作成されており、適切なアセット・タイプが各サイトに対して有効化されていること。

- ワークフローを使用する場合は、使用するワークフロー・プロセスが作成されていること。

- スタート・メニュー・ショートカットが作成されていること。ワークフローを使用する場合は、これらのショートカットによって適切なワークフロー・プロセスが適切なアセット・タイプに割り当てられていること。

- 使用するアセット・タイプのテンプレートが作成されていること。

- 使用するアセット・タイプのアソシエーション・フィールドが作成されていること。ただし、XMLPostを使用してアソシエーション・フィールドの値を設定するには、カスタム・コードが必要です。詳細は、「RemoteContentPostとPreUpdateのカスタマイズ」を参照してください。

- XMLPostを起動する際は、UTF-8エンコード方式が確実に使用されるようにするために、クラスパスの前に-Dfile.encoding=UTF-8というコマンドを挿入してください。

注意:

- すべての.jarファイルのバージョン番号を確認してください。バージョン番号は、WebCenter Sitesのパッチ間で異なる可能性があります。

- XML Postインポート用としてUTF-8を使用してエンコードされたファイルを作成する場合、UTF-8ではBOMが必要なく推奨もされないため、BOMを使用せずに作成するようにしてください。ただし、BOMを使用する他のエンコード・フォームからUTF-8データを変換する場合や、BOMをUTF-8署名として使用する場合、BOMの使用が発生する可能性があります。

42.4.2 コマンドラインからのXMLPostの実行

XMLPostを実行するには:

1. 構成ファイルとソース・ファイルを、WebCenter Sitesがインストールされているシステム上のディレクトリに配置します。

2. XMLPostを起動し稼働するには、クラスパスに<ORACLE_HOME>\wcsites\webcentersites\sites-home\lib\*および<ORACLE_HOME>\oracle_common\modules\clients\*ディレクトリを設定します。

3. そのディレクトリから次のコマンドを(単一のコマンドラインで)実行します。

この例では、LinuxおよびSolarisを含むUNIXベースのシステム用に、Windowsの構文を使用します。区切りには、スラッシュ(/)およびコロン(:)を使用します。

注意:

iniファイルにユーザー資格証明を指定できなくなりました。これらを指定する唯一の方法は、コマンドラインを使用する方法です。

java -Xmx512m -Dfile.encoding=UTF-8 -classpath
<cs_app_dir>\WEB-INF\lib\apache-mime4j-0.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang-2.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.4.jar;
<cs_app_dir>\WEB-INF\lib\cs.jar;
<cs_app_dir>\WEB-INF\lib\cs-core.jar;
<cs_app_dir>\WEB-INF\lib\httpclient-4.1.2.jar;
<cs_app_dir>\WEB-INF\lib\httpcore-4.1.2.jar;
<cs_app_dir>\WEB-INF\lib\httpmime-4.1.2.jar;
<cs_app_dir>\WEB-INF\lib\MSXML.jar;
<cs_app_dir>\WEB-INF\lib\servlet-api.jar;
<cs_app_dir>\WEB-INF\lib\spring-2.5.5.jar;
<cs_app_dir>\WEB-INF\lib\sites-security-11.1.1.8.0.jar;
<cs_app_dir>\WEB-INF\lib\esapi-2.0.1.jar;
<cs_app_dir>\WEB-INF\lib\ojdl-1.1.0-150521.1418.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir><cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sSourcefile.xml -cConfigfile.ini

ここで:

- -Xmx512mは、使用する最大メモリーを設定します。これは、大きな挿入操作に必要です。

- <cs_install_dir>は、WebCenter Sitesのインストール先ディレクトリです。

- <cs_app_dir>は、WebCenter Sitesアプリケーションが配置されているアプリケーション・サーバー上のディレクトリです。

ソース・ファイルを指定するには複数の方法があります。詳細は、「ソース・ファイルの識別」を参照してください。

注意:

j2ee.jarファイルは、J2EE SDKに含まれています。XMLPostを実行する前に、このSDKをインストールする必要があります。

コマンドラインで、作業ディレクトリ内にないソース・ファイルおよび構成ファイルへのパスを指定します。例: -s/products/product.xml。

42.4.3 ソース・ファイルの識別

XMLPostユーティリティに対してソース・ファイルを指定するためのソース・パラメータでは、次のいずれかを指定できます。

- 単一のファイル。

- ファイルのディレクトリ。そのディレクトリ内のファイルのうち、構成ファイルで指定されたファイル拡張子(通常は.xml)を持つすべてのファイルがポスト(インポート)されます。

- インポートするすべてのファイルのリストが記述されたリスト・ファイル。このファイルは.iniファイルと似ていますが、ファイル拡張子は.lstです。

42.4.3.1 単一のファイル

単一のファイルの内容をポストするには、そのファイルの名前をコマンドラインで指定します。次の例では、articlepost.iniという名前の構成ファイルとarticle.xmlという名前のソース・ファイルを使用するようにXMLPostに指示しています。

この例では、LinuxおよびSolarisを含むUNIXベースのシステム用に、Windowsの構文を使用します。区切りには、スラッシュ(/)およびコロン(:)を使用します。

java -Xmx512m -Dfile.encoding=UTF-8 -classpath
<cs_app_dir>\WEB-INF\lib\apache-mime4j-0.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang-2.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang3-3.1.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.7.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.3.jar;
<cs_app_dir>\WEB-INF\lib\cs.jar;
<cs_app_dir>\WEB-INF\lib\cs-core.jar;
<cs_app_dir>\WEB-INF\lib\httpclient-4.3.6.jar;
<cs_app_dir>\WEB-INF\lib\http_client-1.0.0-150521.1418.jar;
<cs_app_dir>\WEB-INF\lib\httpcore-4.3.3.jar;
<cs_app_dir>\WEB-INF\lib\httpmime-4.3.6-12.1.4.0.1-SNAPSHOT.jar;
<cs_app_dir>\WEB-INF\lib\MSXML.jar;
<cs_app_dir>\WEB-INF\lib\servlet-api.jar;
<cs_app_dir>\WEB-INF\lib\spring-core-3.2.6.RELEASE.jar;
<cs_app_dir>\WEB-INF\lib\sites-security.jar;
<cs_app_dir>\WEB-INF\lib\esapi-2.0.1.jar;
<cs_app_dir>\WEB-INF\lib\ojdl-1.1.0-150521.1418.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sarticle.xml -carticlepost.ini

42.4.3.2 ファイルのディレクトリ

ディレクトリ内のすべてのファイルをポストするには、そのディレクトリのパスをコマンドラインで指定します。次の例では、xmlpostfilesディレクトリ内のファイルをインポートするようにXMLPostに指示しています。

この例では、LinuxおよびSolarisを含むUNIXベースのシステム用に、Windowsの構文を使用します。区切りには、スラッシュ(/)およびコロン(:)を使用します。

java -Xmx512m -Dfile.encoding=UTF-8 -classpath
<cs_app_dir>\WEB-INF\lib\apache-mime4j-0.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang-2.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang3-3.1.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.7.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.3.jar;
<cs_app_dir>\WEB-INF\lib\cs.jar;
<cs_app_dir>\WEB-INF\lib\cs-core.jar;
<cs_app_dir>\WEB-INF\lib\httpclient-4.3.6.jar;
<cs_app_dir>\WEB-INF\lib\http_client-1.0.0-150521.1418.jar;
<cs_app_dir>\WEB-INF\lib\httpcore-4.3.3.jar;
<cs_app_dir>\WEB-INF\lib\httpmime-4.3.6-12.1.4.0.1-SNAPSHOT.jar;
<cs_app_dir>\WEB-INF\lib\MSXML.jar;
<cs_app_dir>\WEB-INF\lib\servlet-api.jar;
<cs_app_dir>\WEB-INF\lib\spring-core-3.2.6.RELEASE.jar;
<cs_app_dir>\WEB-INF\lib\sites-security.jar;
<cs_app_dir>\WEB-INF\lib\esapi-2.0.1.jar;
<cs_app_dir>\WEB-INF\lib\ojdl-1.1.0-150521.1418.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sxmlpostfiles -carticlepost.ini

42.4.3.3 リスト・ファイル

ディレクトリを指定するかわりに、次のプロパティが含まれた.iniファイル形式のリスト・ファイルを作成できます。

- numfiles: リストに含まれるファイルの数を指定します。

- fileN: ファイルのパスとファイル名を指定します。Nは、リスト・ファイル内のそのファイルの順番を表します。リストの1番目のファイルはfile1、2番目のファイルはfile2というようになります。
リストの最後のfileNのNの値は、numfilesプロパティで指定された値と一致する必要があります。XMLPostは、numfilesプロパティで指定された数のファイルをインポートした時点で、インポートを終了します。XMLPostは、numfiles状態の値よりも多くのファイルはインポートしません。

リスト・ファイルのファイル拡張子は、.lstにする必要があります。

次のサンプル・リスト・ファイルはxmlpostfiles.lstという名前です。

numfiles: 3
file1: c:\xmlpost\article1.xml
file2: c:\xmlpost\article2.xml
file3: c:\xmlpost\article3.xml

このファイル・リストで指定されたファイルをポストするには、このリスト・ファイルの名前をコマンドラインで指定します。次の例では、xmlpostfiles.lstファイルで指定されたファイルをインポートするようにXMLPostに指示しています。

この例では、LinuxおよびSolarisを含むUNIXベースのシステム用に、Windowsの構文を使用します。区切りには、スラッシュ(/)およびコロン(:)を使用します。

java -Xmx512m -Dfile.encoding=UTF-8 -classpath
<cs_app_dir>\WEB-INF\lib\apache-mime4j-0.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang-2.5.jar;
<cs_app_dir>\WEB-INF\lib\commons-lang3-3.1.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.7.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.3.jar;
<cs_app_dir>\WEB-INF\lib\cs.jar;
<cs_app_dir>\WEB-INF\lib\cs-core.jar;
<cs_app_dir>\WEB-INF\lib\httpclient-4.3.6.jar;
<cs_app_dir>\WEB-INF\lib\http_client-1.0.0-150521.1418.jar;
<cs_app_dir>\WEB-INF\lib\httpcore-4.3.3.jar;
<cs_app_dir>\WEB-INF\lib\httpmime-4.3.6-12.1.4.0.1-SNAPSHOT.jar;
<cs_app_dir>\WEB-INF\lib\MSXML.jar;
<cs_app_dir>\WEB-INF\lib\servlet-api.jar;
<cs_app_dir>\WEB-INF\lib\spring-core-3.2.6.RELEASE.jar;
<cs_app_dir>\WEB-INF\lib\sites-security.jar;
<cs_app_dir>\WEB-INF\lib\esapi-2.0.1.jar;
<cs_app_dir>\WEB-INF\lib\ojdl-1.1.0-150521.1418.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sc:\xmlpostfiles.lst -carticlepost.ini

42.4.4 バッチ・プロセスとしてのXMLPostの実行

複数のタイプのアセットをインポートする場合は、アセット・タイプごとに個別にXMLPostを実行することにより、タイプごとに固有の構成ファイルを指定します。XMLPostは、手動で実行することも、バッチ・ファイルから自動的に実行することもできます。このバッチ・ファイル内には、アセット・タイプごとに1つのコマンドライン文を記述します(この文では構成ファイルと、ソース・ファイルの場所を指定します)。前の項で説明した方法のいずれかを使用してソース・ファイルを指定できます。

42.4.5 プログラムからのXMLPostの実行

XMLPostユーティリティをプログラムから起動するには、XMLPostオブジェクトを作成して、doItメソッドのdoIt(String[] args)をコールします(このメソッドの入力は文字列配列です)。この配列のエレメントは、XMLPostをコマンドラインから実行する場合に使用するのと同じフラグです。

次に例を示します。

String args [] = {"-sSourcefile.xml","-cConfigfile.ini"};
COM.FutureTense.XML.Post.XMLPost poster = new
COM.FutureTense.XML.Post.XMLPost();
try {
poster.doIt(args);
} catch (Exception e) {
e.printStackTrace();("error in XMLPost under program control");
}

ソース・ファイルと構成ファイルの完全パスを指定する必要があります。

42.5 RemoteContentPostとPreUpdateのカスタマイズ

必要に応じて、アセット・タイプのRemoteContentPostエレメントやPreUpdateエレメント内のコードを追加または変更することで、XMLPostプロセスをカスタマイズできます。アセットに関する情報を他の表にインポートするには、そのアセット・タイプのPreUpdateエレメントを変更する必要があります。

この項では、次の2つのカスタマイズ例を紹介します。

- Articleアセット・タイプのPreUpdateエレメントをカスタマイズして、このエレメントで説明フィールド内のヘッドライン情報が設定されるようにします。Article表にはdescription列がありますが、「新規」記事フォームや「編集」記事フォーム内のフィールドの名前は「ヘッドライン」になります。

- Articleアセット・タイプのPreUpdateエレメントをカスタマイズして、このエレメントが記事にアソシエーションを追加できるようにします。

この項には次のトピックが含まれます:

- プログラムによるフィールド値の設定

- アセットのアソシエーションの設定

42.5.1 プログラムによるフィールド値の設定

記事アセット・タイプは、「ヘッドライン」と呼ばれる「新規」および「編集」フォーム内にフィールドを持ち、その値はArticle表内のdescription列に格納されます。Articleアセットのインポート時にヘッドライン・テキストが正しい列(description列)に書き込まれるようにするために、Articleアセット・タイプのPreUpdateエレメントが変更されます。

まず、WebCenter Sites製品キット内のXcelerate/Samples/XMLPostディレクトリに配置されたArticlePost.iniという名前のサンプル構成ファイルを調べます。このファイルには、次のように「ヘッドライン」フィールドに対して指定されたタグが含まれています。

# headline gets stored in the description field
postheadline: y

記事アセット・タイプのPreUpdateエレメント内の次のコードは、RemoteContentPostがVariable.headlineとして渡すデータを正しいデータベース列に書き込みます。

<if COND="IsVariable.headline=true">
<then>
<ASSET.SET NAME="theCurrentAsset"
FIELD="description"
VALUE="Variables.headline"/>
</then>
</if>

この例では、ASSET.SETというタグを使用しています。このタグは、現在メモリー内にあるアセットのフィールド内のデータを設定します。このタグでは次の3つのパラメータを指定できます。

- NAME: (必須)。メモリーに格納されているアセット・オブジェクトの名前です。このアセット・オブジェクトは、ASSET.LOADタグかASSET.CREATEタグで、あらかじめインスタンス化されている必要があります。WebCenter Sitesでは慣例的にtheCurrentAssetという名前を使用して、現在のアセット・オブジェクトを参照します。

- FIELD: (必須)。値を設定しようとしているフィールドの名前。このフィールドの名前は、このタイプのアセットの記憶域表内の列の名前と完全に一致している必要があります。

- VALUE: (必須)。列に挿入するデータ。

42.5.2 アセットのアソシエーションの設定

アセット間のアソシエーションに関する情報は、AssetRelationTree表に書き込まれます。XMLPostの標準動作では、アセットの情報はそのアセット・タイプのプライマリ記憶域表にのみ書き込まれるため、アセットのアソシエーションを指定するには、そのアセット・タイプのPreUpdateエレメントを変更する必要があります。たとえば、Articleアセット・タイプにはMainImageFileという名前のアソシエーション・フィールドがあります。コンテンツ・プロバイダは記事アセットを作成する際に、適切なイメージファイル・アセットをこのフィールドで選択します。

WebCenter Sites製品キット内のXcelerate/Samples/XMLPostディレクトリに配置されたArticlePost.iniという名前のサンプル構成ファイルを調べてください。このファイルには、次のようにMainImageFileアソシエーション・フィールドに対して指定されたタグが含まれています。

postMainImageFile-name: y

記事アセット・タイプのPreUpdateエレメント内の次のコードは、RemoteContentPostがVariable.mainimagefileとして渡すデータを正しいデータベース表に書き込みます。

<if COND="IsVariable.MainImageFile-name=true">
<then>
<ASSET.LOAD NAME="anAssociatedImage" TYPE="ImageFile"
FIELD="name" VALUE="Variables.MainImageFile-name"/>
<if COND="IsError.Variables.errno=false">
<then>
<ASSET.GET NAME="anAssociatedImage" FIELD="id" OUTPUT="imageid"/>
<ASSET.ADDCHILD NAME="theCurrentAsset" TYPE="ImageFile"
CHILDID="Variables.imageid" CODE="MainImageFile"/>
</then>
</if>
</then>
</if>

注意:

ASSET.ADDCHILDタグは、2つのアセット間のリンクのみを作成します。関連付けられたアセットは作成しません。このコードが正常に機能するためには、CHILDIDパラメータで指定されたアセットが、WebCenter Sitesデータベース内に存在している必要があります。

この例では、ASSET.ADDCHILDというタグを使用しています。このタグは、子アセットを、現在メモリー内に保持されているアセットと関連付けます。このタグでは次の5つのパラメータを指定できます。

- NAME (必須)。メモリーに格納されているアセット・オブジェクトの名前です。このアセット・オブジェクトは、ASSET.LOADタグかASSET.CREATEタグで、あらかじめインスタンス化されている必要があります。WebCenter Sitesでは慣例的にtheCurrentAssetという名前を使用して、現在のアセット・オブジェクトを参照します。

- TYPE (必須)。子アセットのアセット・タイプ。

- CHILDID (必須)。子アセットのID。

- CODE (オプション)。アソシエーションの名前。この値は、AssetRelationTree表のncode列に書き込まれます。

- RANK (オプション)。子アセットの順番を設定するための数値。この値は、AssetRelationTree表のnrank列に書き込まれます。

ASSET.GETおよびASSET.LOADの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

42.6 XMLPostのトラブルシューティング

ここでは、XMLPostユーティリティの実行時に発生する可能性のあるいくつかの問題について簡単に説明します。

42.6.1 XMLPostが実行されず、ログ・ファイル・メッセージが作成されない

XMLPostが起動しない理由としては次の2つが考えられます。

- 構成ファイル内のxmlpost.URLプロパティの設定で無効なサーバー名が指定されています。

- インポート先のシステム上でWebCenter Sitesが実行されていません。それを起動してください。

42.6.2 XMLPostでエラーが発生して、ログ・ファイルにエンティティの欠落というメッセージが記録されている

このメッセージは、ソース・ファイル内に無効なXMLがあることを意味します。このような場合は通常、XMLにHTMLコードが含まれており、そのコードに含まれている特殊なHTML文字がそれらのHTML文字の文字エンティティ・コードで参照されていません。最適なコーディング手法として、すべてのHTMLコードを<![CDATA[...]]>タグ内に埋め込んでください。

42.6.3 XMLPostがアセットを保存しようとするとエラー105が発生する

アセットの保存時にデータベース・エラーが発生する理由はいくつか存在します。105エラーの一般的な理由の1つは、XMLPostが保存しようとしているデータが大きすぎて列(フィールド)に収まらないことです。この問題の解決方法は目的に応じて異なります。列に収まらないデータが途中で切り捨てられてもかまわない場合は、trunctagプロパティを構成ファイルに追加することで解決できます。たとえば、truncbody: 2000と指定します。

このエラー・コードのもう1つの一般的な理由は、同じ名前を持つそのタイプのアセットが存在していることです。そのアセットの名前を変更してから、そのアセットをもう一度インポートしてみてください。

42.6.4 ポスト・エレメントのデバッグ

RemoteContentPostエレメントを変更した場合、または独自のポスティング・エレメントを作成した場合、XML Debuggerユーティリティを使用してこのエレメントをテストします。XML Debuggerを使用するには、xmlpost.urlプロパティの設定でContentServerをDebugServerに置き換えます。たとえば、xmlpost.url: http://6ipjk/servlet/ContentServerをxmlpost.url: http://6ipjk/servlet/DebugServerに変更します

XML Debuggerユーティリティの詳細は、「WebCenter Sitesのツールおよびユーティリティの概要」を参照してください。

43 フレックス・アセットのインポート

WebCenter Sitesでは、BulkLoaderという名前のバルク処理ユーティリティとXMLPostユーティリティ用のポスト・エレメントが用意されています。

XMLPostユーティリティを使用したフレックス・アセットのインポートの詳細は、次の項を参照してください。

- フレックス・アセットのインポートについて

- XMLPostとフレックス・アセット・モデルの理解

- フレックス・モデル内の構造アセット・タイプのインポートについて

- XMLPostを使用したフレックス・アセットのインポート

- XMLPostを使用したフレックス・アセットの編集

- XMLPostを使用したアセットの削除

この章では、BulkLoaderユーティリティを取り上げていますが、このユーティリティの実行方法の詳細は、「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

43.1 フレックス・アセットのインポートについて

WebCenter Sitesでは、次の2つの方法で、フレックス・データ・モデルを使用するアセットをWebCenter Sitesデータベースにインポートできます。

- XMLPost。WebCenter Sitesには、XMLPostと組み合せて機能する3つの追加のポスト・エレメントaddData、modifyDataおよびdeleteDataがあります。

- BulkLoaderユーティリティ。

この項には次のトピックが含まれます:

- データ構造フレックス・アセット・タイプのインポートを開始する前に

- フレックス・アセットのインポートについて

- フレックス・アセットのインポートのプロセスの概要

- カスタムのデータ・デリミタについて

43.1.1 データ構造フレックス・アセット・タイプのインポートを開始する前に

どちらの方法を使用する場合でも、その前に、WebCenter Sites製品に付属しているRemoteContentPostという標準のポスト・エレメントとXMLPostを使用して、データ設計またはデータ構造のアセット・タイプを作成するか、そのアセット・タイプをフレックス・ファミリにインポートする必要があります。つまり、標準のXMLPostポスト・エレメントを使用して、最初に属性エディタ、フレックス属性、フレックス定義およびフレックス親定義を作成またはインポートする必要があります。

BulkLoaderユーティリティを使用するには、フレックス親もXMLPostを使用してインポートするか作成する必要があります。

43.1.2 フレックス・アセットのインポートについて

データ構造アセット・タイプをインポートしたら、次の2つのいずれかのインポート方法を使用してフレックス・アセットをインポートします。

- 大量(数千から数十万)のフレックス・アセットをインポートする場合は、BulkLoaderを使用します。

- 中程度の数(数百)のフレックス・アセットとフレックス親アセットをロードする場合は、ポスト・エレメントを使用します。

43.1.2.1 BulkLoaderを使用する場合

ベーシック・アセット・モデル内で作業している場合は、通常はXMLPostを使用して、管理システム上のデータベースにアセットをインポートしてから、これらのアセットを配信システムにパブリッシュします。フレックス・アセット・データ・モデルで必要なデータの量は、ベーシック・アセット・モデルの場合よりもはるかに多い傾向にあるため、この方法はフレックス・アセットに応じて変化します。

BulkLoaderユーティリティは、WebCenter Sitesシステムの初期セットアップ時に使用します。「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

43.1.2.2 XMLPostを使用する場合

WebCenter Sitesシステムの初期セットアップ後に通常更新や増分更新を実行するには(たとえば、データの一部またはすべてがERPシステムで生じている場合など)、XMLPostユーティリティとaddDataポスト・エレメントを使用します。

43.1.3 フレックス・アセットのインポートのプロセスの概要

フレックス・モデルを使用しているアセットは相互に依存性があるため、フレックス・アセット・タイプは特定の順序でインポートする必要があります。そして、ベーシック・アセットの場合と同様に、XMLPostを使用してアセットをインポートする前に、該当するアセット・タイプが存在していることや、サイト作成されていることなどが必要になります。

すべてのアセット・タイプ(両方のアセット・モデル)に当てはまる、XMLPostを使用するための基本的な前提条件は、「開始する前に」を参照してください。

これらの基本的な要件が満たされた後に、次の順序でフレックス・アセット・タイプを管理システム上のWebCenter Sitesデータベースにインポートする必要があります。

1. 属性エディタはオプションです。属性エディタを使用するには、それらをインポートまたは作成してからフレックス属性をインポートします。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、「属性エディタ」を参照してください。

2. フレックス属性。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、「フレックス属性」を参照してください。

3. フレックス親定義。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、「フレックス定義とフレックス親定義: サンプル・ファイル」を参照してください。

注意:

フレックス親定義を適切な順序でインポートする必要があります。別の親定義によって参照される親定義アセットは、データベース内に存在している必要があります。

通常は、親定義を階層レベルごとにインポートします(最上位レベルの親定義を最初にインポート)。

4. フレックス定義。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、「フレックス定義とフレックス親定義: サンプル・ファイル」を参照してください。

5. フレックス親アセット。次のいずれかの操作を行います。

- フレックス親を個別にインポートするか、XMLPostを使用して、フレックス・アセットのフレックス・ファミリ・ツリーの一部としてフレックス親をインポートします。

- BulkLoaderユーティリティを使用してフレックス・アセットをインポートするには、まずXMLPostを使用してフレックス親アセットをインポートします。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。フレックス・アセットのファミリ・ツリー全体を含めずに親をインポートするため、構成ファイルではaddDataエレメントを指定できません。

詳細は、「フレックス親」を参照してください。

6. (オプション)まずすべての構造アセット(属性エディタ、フレックス属性、フレックス定義、親定義およびフレックス親)を承認して、管理システムから配信システムにパブリッシュし、BulkLoaderユーティリティを使用してフレックス・アセットを両方のシステムにインポートします。

7. フレックス・アセット。次のいずれかの操作を行います。

- BulkLoaderユーティリティを使用します。「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

- XMLPostを使用します。「XMLPostを使用したフレックス・アセットのインポート」を参照してください。

フレックス・アセット・ファミリのデータ構造には依存性が組み込まれているため、前述の手順で示した順序に従う必要があります。また、次の依存性にも留意してください。

- フレックス親またはフレックス・アセットにasset型の属性がある場合、その属性フィールドの値として指定するアセットを作成またはインポートしている必要があります。

- asset型の属性の値として設定するアセットは、正しいアセット・タイプのものである必要があります。

43.1.4 カスタムのデータ・デリミタについて

カスタムのデータ・デリミタは、デフォルトのデリミタがコンテンツで使用されている場合に使用されます。XMLPostを使用してインポート、編集または削除するデータで、WebCenter Sitesのデフォルト・スキーマとは異なるデータ区切りスキーマが使用されている場合は(CSのデフォルト・デリミタ文字については次の表を参照してください)、表43-1の説明に従ってカスタム・デリミタを指定できます。

表43-1 カスタムのデータ・デリミタ

タグ

プロパティ

説明

<_xmlnamevaldelim_>

post_xmlnamevaldelim_

オプション。

名前と値のペアを別のペアと区切るためのカスタム文字を指定できます。

カスタム・デリミタを指定するには:

1.構成ファイルでプロパティをyに設定します。

2.XMLファイルでタグを使用して、カスタム・デリミタを定義します。たとえば、次のようにアットマークをデリミタとして使用できます。

<_xmlnamevaldelim_>@</_xmlnamevaldelim_>

デフォルト・デリミタはコロン(:)です。

<_xmlpostequaldelim_>

post_xmlpostequaldelim_

オプション。

属性の名前と値を区切るためのカスタム文字を指定できます。

カスタム・デリミタを指定するには:

1.構成ファイルでプロパティをyに設定します。

2.XMLファイルでタグを使用して、カスタム・デリミタを定義します。たとえば、次のように2つの等号をデリミタとして使用できます。

<_xmlpostequaldelim_>==</_xmlpostequaldelim_>

デフォルト・デリミタは等号(=)です。

<_xmlpostmulvaldelim_>

post_xmlpostmulvaldelim_

オプション。

複数値属性をそれぞれ区切るためのカスタム文字を指定できます。

カスタム・デリミタを指定するには:

1.構成ファイルでプロパティをyに設定します。

2.XMLファイルでタグを使用して、カスタム・デリミタを定義します。たとえば、次のようにハイフンをデリミタとして使用できます。

<_xmlpostmulvaldelim_>-</_xmlpostmulvaldelim_>

デフォルト・デリミタはセミコロン(;)です。

43.2 XMLPostとフレックス・アセット・モデルの理解

使用しているアセット・モデルやWebCenter Sites製品にかかわらず、XMLPostユーティリティは同じように動作します。ただし、フレックス・アセットのデータは複数のデータベース表に格納されるため(これとは対称的に、ベーシック・アセット・タイプでは1つのデータベース表しか使用されません)、WebCenter Sitesでは、XMLPostをサポートするために、フレックス・アセット・タイプの一部の標準エレメント内に追加の処理ロジックが用意されています。

また、WebCenter Sitesには、XMLPostを使用してフレックス・アセットを編集可能にするポスト・エレメント(modifyData)と、XMLPostを使用して任意タイプのアセットを削除可能にするポスト・エレメント(deleteData)の両方が用意されています。

この章では、フレックス・ファミリ内のアセット・タイプ(および属性エディタ)専用の構成ファイルとソース・ファイルの作成に関する追加情報を提供します。必ず「任意タイプのアセットのインポート」も参照して、XMLPostのすべての構成ファイルとソース・ファイルに関する基本情報を確認してください。

フレックス・アセット・モデルでは、次のカテゴリのアセット・タイプに基づいて異なるポスト・エレメントを指定します。

- フレックス・アセット・タイプとフレックス親アセット・タイプにデータ構造を付与する構造アセット・タイプ。つまり、属性エディタ、属性、フレックス定義およびフレックス親定義です。
構造アセット・タイプをインポートするには、WebCenter Sitesの標準のポスト・エレメントであるRemoteContentPostを使用してください。(これらのタイプのアセットには、addDataエレメントを使用できません。)

- フレックス・アセット・タイプとフレックス親アセット・タイプ(製品タイプと製品親タイプなど)。
状況に応じて、フレックス・アセット・タイプとフレックス親アセット・タイプをインポートするaddDataポスト・エレメントを使用するか、RemoteContentPostポスト・エレメントを使用します。(どちらのポスト・エレメントを使用するかについては、「フレックス親」と「XMLPostを使用したフレックス・アセットのインポート」を参照してください。)

どちらの場合も、最初に構成ファイルとソース・ファイルを作成し(「フレックス・アセットのインポートについて」の説明と、この章の補足説明を参照)、その後で、XMLPostユーティリティを起動します(「XMLPostユーティリティの使用」を参照)。

注意:

参考用として、XMLPostのサンプル・コードが用意されており、このサンプル・コードは、WebCenter Sitesインストーラ・パッケージの/Xcelerate/Samples/XMLPostディレクトリ内にあります。同じフォルダに、サンプル・ファイルの説明が記載されたreadme.txtファイルも含まれています。

内部名と外部名

アセット・タイプのフレックス・ファミリを作成するときには(「フレックス・アセット・ファミリの作成」の「フレックス・ファミリの作成」を参照)、アセット・タイプの内部名と外部名の両方を指定します。

内部名は、データベース内のプライマリ記憶域表で使用されます。外部名は、「新規」フォーム、「編集」フォーム、「調査」フォーム、検索結果リストなどで使用されます。たとえば、属性エディタ・アセット・タイプの内部名はAttrTypesですが、この名前はユーザー・インタフェースでは使用されません。

XMLPostはデータベースと通信するため、構成ファイルとソース・ファイルでは常にアセット・タイプの内部名を使用する必要があります。たとえば、属性エディタの構成ファイルでは、次のように指定します。

postargname2: AssetType
postargvalue2: AttrTypes

43.3 フレックス・モデル内の構造アセット・タイプのインポートについて

「任意タイプのアセットのインポート」に記載しているベーシック・アセットの構成ファイルとソース・ファイルに関するすべての情報は、フレックス・アセット・タイプの構成ファイルとソース・ファイルにも当てはまります。

さらにこの項では、構造フレックス・アセット・タイプのサンプル構成ファイルとサンプル・ソース・ファイルを掲載しています。

この項には次のトピックが含まれます:

- 属性エディタ

- フレックス属性

- フレックス定義とフレックス親定義: サンプル・ファイル

- フレックス親

43.3.1 属性エディタ

属性エディタのデータは、AttrTypesという名前の1つの表に格納されます。AttrTypesは、属性エディタ・アセット・タイプの内部名です。属性エディタの構成ファイルでは、必ずこの名前を使用してください。

表43-2では、属性エディタで使用する構成ファイル・プロパティとソース・ファイル・タグを説明しています。

表43-2 属性エディタのタグとプロパティ

タグ

プロパティ

説明

<name>

postname

すべてのアセット・タイプで必須。

属性エディタ・アセットの名前。属性名は64文字に制限され、空白は指定できません。

<description>

postdescription

オプション。

属性の使用方法や機能に関する説明。

<AttrTypeText>

postAttrTypeText

必須。

属性エディタのXMLコードが含まれたファイルの名前、または実際のコード。

このタグは、WebCenter Sitesインタフェースの「新規」および「編集」属性エディタ・フォームにある「XML」フィールドと、「参照」ボタンおよび「ファイル内のXML」フィールドに対応しています。

43.3.1.1 サンプル構成ファイル: 属性エディタ

ここでは、属性エディタ・アセット・タイプのサンプル構成ファイルを示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

xmlpost.xmlfilenamefilter: .xml
xmlpost.url: http://izod19/servlet/ContentServer
xmlpost.numargs: 6
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost
xmlpost.argname2: AssetType
xmlpost.argvalue2: AttrTypes
# notice that you use the internal name of the asset type

xmlpost.argname3: authusername
xmlpost.argvalue3: user_editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: user
xmlpost.argname5: inifile
xmlpost.argvalue5: futuretense.ini
xmlpost.argname6: startmenu
xmlpost.argvalue6: New Attribute Editor

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: attreditorpostlog.txt

xmlpost.deletefile: y

postpublication: y

postname: y
postdescription: y
postAttrTypeText: y

43.3.1.2 サンプル・ソース・ファイル: 属性エディタ

次に示すソース・ファイルは、チェック・ボックス属性エディタ(プレゼンテーション・オブジェクト)をインポートするためのタグが記述されています。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>AA Illumination</publication>
<name>Editor4-CheckBoxes</name>
<description>Attribute Type Four Check Box</description>
<AttrTypeText>
<![CDATA[
<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CheckBoxTest">
<CHECKBOXES LAYOUT="VERTICAL">
<ITEM>Red</ITEM>
<ITEM>Green</ITEM>
<ITEM>Blue</ITEM>
</CHECKBOXES>
</PRESENTATIONOBJECT>
]]>
</AttrTypeText>
</document>

43.3.2 フレックス属性

フレックス属性は複数の表がありますが、XMLPostはこれらのうち2つの表(メイン記憶域表と、属性アセット・タイプの_Extension表)にのみ書込みを行います。

このため、構成ファイルのソース・ファイル・セクションでは両方の表の列を表すタグを指定する必要があり、ソース・ファイル自体ではこれらのタグを使用する必要があります。表43-3では、これらのソース・ファイル・タグと構成ファイル・プロパティを説明しています。

表43-3 フレックス属性のタグとプロパティ

タグ

プロパティ

説明

<name>

postname

すべてのアセット・タイプで必須。

属性の名前。属性名は64文字に制限され、空白は指定できません。

<description>

postdescription

オプション。

属性の使用方法や機能に関する説明。

<valuestyle>

postvaluestyle

オプション。

この属性が単一の値を保持できるのか(S)、複数の値を保持できるのか(M)。このタグを使用しない場合は、この属性はデフォルトで単一の値を保持するように設定されます。

<type>

posttype

必須。

属性のデータ型。有効なオプションは、asset、date、float、int、money、string、textまたはblobです。これらのデータ型の定義については、「属性のデータ型」を参照してください。

<assettypename>

postassettypename

<type>がassetに設定されている場合は必須。

この属性で保持されているアセット・タイプの名前。

<upload>

postupload

<type>がblobに設定されている場合は必須。

この属性の値を格納するディレクトリのパス。このフィールドに入力した値は、wcs_properties.jsonファイルのcc.urlattrpathプロパティで属性表のデフォルトの記憶域ディレクトリ(defdir)として設定された値の後ろに付加されます。

<attributetype>

postattributetype

オプション。

使用する属性エディタの名前(該当する場合)。

<enginename>

postenginename

オプション。

管理システムで使用している検索エンジンの名前。

<charsetname>

postcharsetname

オプション。

使用する検索エンジンの文字セット。デフォルトでは、ISO 8859-1に設定されています。

<editing>

postediting

外部属性のみ。

外部属性は、WebCenter Sitesのフォームを通じて編集可能(L)になるのか、またはサード・パーティ・ツールを使用して外部で編集可能(R)になるのか。Lがデフォルトです。

<storage>

poststorage

外部属性のみ。

外部属性の値は、WebCenter Sitesデータベース内の_Mungo表に格納(L)されるのか、外部表に格納(R)されるのか。Lがデフォルトです。

<externalid>

postexternalid

外部属性のみ。

この外部属性を保持している表の主キーとして機能する列の名前。つまりこの属性を一意に識別する列の名前。

<externalcolumn>

postexternalcolumn

外部属性のみ。

この属性の値を保持している外部表の列の名前。

<externaltable>

postexternaltable

外部属性のみ。

externalidとexternalcolumで指定された列が含まれている外部表の名前。

<publication>

postpublication

オプション。

この属性を使用できるすべてのサイトの名前。

43.3.2.1 サンプル構成ファイル: フレックス属性

ここでは、この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能する、製品属性アセット・タイプのサンプル構成ファイルを示します。

xmlpost.xmlfilenamefilter: .xml

xmlpost.url: http://izod19/servlet/ContentServer
xmlpost.numargs: 6
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost
xmlpost.argname2: AssetType
xmlpost.argvalue2: PAttributes
# Notice that this is the internal name of the asset
# type. The external name of this asset type is
# Product Attribute.

xmlpost.argname3: authusername
xmlpost.argvalue3: user_editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: user
xmlpost.argname5: inifile
xmlpost.argvalue5: futuretense.ini
xmlpost.argname6: startmenu
xmlpost.argvalue6: New Product Attribute

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: attributespostlog.txt

xmlpost.deletefile: y

postpublication: y
postname: y
postattributetype: y
postdescription: y
postvaluestyle: y
posttype: y
postediting: y
poststorage: y
postenginename: y
poststatus: y
postassettypename: y
postupload: y
postexternalid: y
postexternalcolumn: y
postexternaltable: y
postcharsetname: y

43.3.2.2 サンプル・ソース・ファイル: 属性

ここでは、footnotesという名前の製品属性をインポートするためのサンプル・ソース・ファイルを示します。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>AA Illumination</publication>
<name>footnotes</name>
<description>Footnotes</description>
<valuestyle>S</valuestyle>
<type>URL</type>
<editing>L</editing>
<storage>L</storage>
</document>

注意:

前述したように、フレックス属性のデータ型に関するすべての依存性と制約事項は、WebCenter Sitesインタフェース(「新規」または「編集」フレックス属性フォーム)を通じて属性を作成する場合でも、XMLPostを使用して属性を作成する場合でも同じように当てはまります。詳細は、「フレックス・アセット・ファミリの作成」の「フレックス属性の作成」を参照してください。

43.3.3 フレックス定義とフレックス親定義: サンプル・ファイル

フレックス定義とフレックス親定義のアセット・タイプはよく似ているため、これらのアセット・タイプの構成ファイルとソース・ファイルはほぼ同じように記述します。これらのアセット・タイプは、各自のソース・ファイル内でいくつかの同じタグを必要とし、各自の構成ファイル内でいくつかの同じプロパティを必要とします。それぞれのファイルには1つの追加のプロパティ/タグが含まれます。

この項には次のトピックが含まれます:

- サンプル構成ファイル: フレックス定義

- サンプル・ソース・ファイル: フレックス定義

表43-4では、フレックス定義とフレックス親定義のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されます。

表43-4 フレックス定義とフレックス親定義のタグとプロパティ

フレックス定義とフレックス親定義のタグとプロパティ

説明

タグ:

<internalname>

プロパティ:

postinternalname

必須。

アセットの名前。これはすべてのアセット・タイプについて必須の値です。フレックス定義とフレックス親定義の名前は64文字に制限され、空白は指定できません。

タグ:

<internaldescription>

プロパティ:

postinternaldescription

オプション。

アセットの用途または機能の説明。

タグ:

<renderid>

プロパティ:

postrenderid

オプション。フレックス定義専用。

このフレックス定義を使用して作成されるすべてのフレックス・アセットに割り当てられるテンプレート・アセットのID。

タグ:

<parentselectstyle>

プロパティ:

postparentselectstyle

オプション。フレックス親定義専用。

ユーザーがこの定義を使用してフレックス・アセットを作成する場合のフレックス親の選択方法を指定します。

このプロパティ/タグは、「新規」および「編集」親定義フォームの「親選択スタイル」フィールドを表しています。

このタグをソース・ファイル内で使用している場合、有効なオプションはtreepickとselectboxesです。

次の4つのタグとプロパティは、親定義とフレックス定義の「新規」フォームと「編集」フォームの「製品親定義」セクションにあるボタンおよびフィールドと同じ機能を実行します。「フレックス・アセット・ファミリの作成」の「(条件付き)フレックス・フィルタ・アセットの作成」および「フレックス定義アセットの作成」を参照してください。

なし

タグ:

<OptionalSingleParentList>

プロパティ:

postOptionalSingleParentList

このタグを使用して、単一のオプションの親定義を指定します。

タグ:

<RequiredSingleParentList>

プロパティ:

postRequiredSingleParentList

このタグを使用して、単一の必須の親定義を指定します。

タグ:

<RequiredMultipleParentList>

プロパティ:

postRequiredMultipleParentList

このタグを使用して、複数の必須の親定義を指定します。

タグ:

<OptionalMultipleParentList>

プロパティ:

postOptionalMultipleParentList

このタグを使用して、複数のオプションの親定義を指定します。

次の3つのタグとプロパティは、フレックス定義とフレックス親定義の「新規」フォームと「編集」フォームの「属性」セクションにあるボタンおよびフィールドと同じ機能を実行します。「フレックス・アセット・ファミリの作成」の「(条件付き)フレックス・フィルタ・アセットの作成」および「フレックス定義アセットの作成」を参照してください。

なし

タグ:

<RequiredAttrList>

プロパティ:

postRequiredAttrList

この定義を使用するフレックス親またはフレックス・アセットの必須の属性のリスト。

タグ:

<OptionalAttrList>

プロパティ:

postOptionalAttrList

この定義を使用するフレックス親またはフレックス・アセットのオプションの属性のリスト。

タグ:

<OrderedAttrList>

プロパティ:

postOrderedAttrList

「新規」、「編集」、「調査」などのフォームですべての属性(必須とオプションの両方)が表示される順序。

このタグは、他の属性タグを置き換えます。この項のサンプル・ソース・ファイルでは、このタグをソース・ファイル内で使用する方法を例示しています。

構成ファイルには、その構成ファイルが連係するタイプのアセットのいずれかで使用される可能性のあるすべてのプロパティが含まれている必要があります。個別のソース・ファイルには、それらの個別のアセットを定義するために必要なタグのみが含まれています。

43.3.3.1 サンプル構成ファイル: フレックス定義

次に、製品定義をインポートするための構成ファイルの例を示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

xmlpost.url: http://izod19/servlet/ContentServer
xmlpost.numargs: 6
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost
xmlpost.argname2: AssetType
xmlpost.argvalue2: ProductTmpls
# Notice that this is the internal name of the asset type.
# The external name of this asset type is
# Product Definition.

xmlpost.argname3: authusername
xmlpost.argvalue3: user_editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: user
xmlpost.argname5: inifile
xmlpost.argvalue5: futuretense.ini
xmlpost.argname6: startmenu
xmlpost.argvalue6: New Product Definition

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: productdefpostlog.txt
xmlpost.deletefile: y

postpublication: y
postinternalname: y
postinternaldescription: y

postparentselectstyle: y

postOptionalSingleParentList: y
postRequiredSingleParentList: y
postRequiredMultipleParentList: y
postOptionalMultipleParentList: y

postRequiredAttrList: y
postOptionalAttrList: y
postOrderedAttrList: y

postrenderid: y

43.3.3.2 サンプル・ソース・ファイル: フレックス定義

次のソース・ファイル(lighting.xml)は、Lightingという名前の製品定義のソースです。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>AA Illumination</publication>
<internalname>Lighting</internalname>
<internaldescription>Generic Lighting Template</internaldescription>
<RequiredAttrList>sku</RequiredAttrList>
<OptionalAttrList>
productdesc;caseqty;bulbshape;bulbsize;basetype;
colortemp;meanlength;lightcenterlength;reducedwattage;beamspread;
fixturetype;ballasttype;colorrenderingindex;minstarttemp;powerfactor;
totalharmonicdist;spreadbeam10h;spreadbeam10v;spreadbeam50h;
spreadbeam50v;halogen;operatingposition;filamenttype;bulbimage;
baseimage;filamentimage;footnotes;price;life;voltage;wattage
</OptionalAttrList>
<parentselectstyle>treepick</parentselectstyle>
<OptionalMultipleParentList>SubCategory</OptionalMultipleParentList>
</document>

前述の属性のリストを調べてください。1つのタグに複数の値を含める場合は、それぞれの値をセミコロン(;)で区切ります。

オプション/複数の親モデルが使用されていますが、次に示す他の構成も可能です。

<OptionalSingleParentList>flexparentdefinition</OptionalSingleParentList>
<RequiredSingleParentList>flexparentdefinition</RequiredSingleParentList>
<RequiredMultipleParentList>flexparentdefinition</RequiredMultipleParentList>

順序付き属性のリストの指定

属性を特定の順序で表示する必要があるために、<OrderedAttrList>タグを使用するには、<RequiredAttrList>タグと<OptionalAttrList>タグを一緒に使用しないでください。<OrderedAttrList>タグに含まれた文字列で、どの属性が必須でどの属性がオプションなのかを次のように指定します。

- 必須の属性については、その属性名の前にR (required)を付加します。

- オプションの属性については、その属性名の前にO (optional)を付加します。

- これらの属性を必ず順に列記します。

- それぞれの値を必ずセミコロン(;)で区切ります。

例:

<OrderedAttrList>Rsku;Oproductdesc;Ocaseqty;Obulbshape;Obulbsize;Obasetype;Ocolortemp;Omeanlength;Olightcenterlength;Oreducedwattage;<OrderedAttrList>

43.3.4 フレックス親

XMLPostを使用して、次の2つの方法でフレックス親アセットをインポートできます。

- 個別にインポートできます。フレックス親ごとに別個のXMLPostソース・ファイルを記述して、標準のRemoteContentPostポスト・エレメントのページ名とアセット・タイプを指定する1つのXMLPost構成ファイルを記述します。BulkLoaderユーティリティを使用するには、まずXMLPostを使用してこの方法でフレックス親アセットをインポートします。

- フレックス・アセットのフレックス・ファミリ・ツリーの一部としてインポートできます。BulkLoaderではなくXMLPostを使用してフレックス・アセットをインポートするには、フレックス親をフレックス・アセットと結合して、フレックス親をフレックス・ファミリ・ツリーの一部としてインポートします(特定のフレックス・アセットのコンテキスト内で)。フレックス・アセットごとに別個のXMLPostソース・ファイルを記述して、そのフレックス・アセットのすべての親をそのソース・ファイル内で指定します。XMLPostは、ソース・ファイルの解析時に、1つのフレックス・アセットと複数のフレックス親の変数を作成します(これらの変数がまだ存在しない場合)。

この項では、フレックス親アセットを個別にインポートするためのソース・ファイルと構成ファイルを紹介します。フレックス・アセットとともにそれらをインポートする方法の詳細は、「XMLPostを使用したフレックス・アセットのインポート」を参照してください。

この項には次のトピックが含まれます:

- サンプル構成ファイル: 個別のフレックス親

- サンプル・ソース・ファイル: 個別のフレックス親

43.3.4.1 サンプル構成ファイル: 個別のフレックス親

次に、製品親をインポートするための構成ファイルの例を示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

xmlpost.xmlfilenamefilter: .xml

xmlpost.url: http://izod19/servlet/ContentServer
xmlpost.numargs: 6
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost
xmlpost.argname2: AssetType
xmlpost.argvalue2: ProductGroups
# notice that you use the internal name of the asset type

xmlpost.argname3: authusername
xmlpost.argvalue3: user_editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: user
xmlpost.argname5: inifile
xmlpost.argvalue5: futuretense.ini
xmlpost.argname6: startmenu
xmlpost.argvalue6: New Product Parent

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: productdefpostlog.txt
xmlpost.deletefile: y

postpublication: y
postinternalname: y
postinternaldescription: y
postflexgrouptemplateid: y
postfgrouptemplatename: y
postParentList: y
postcat1: y
postcat2: y

43.3.4.2 サンプル・ソース・ファイル: 個別のフレックス親

次のソース・ファイルは、Halogenという名前の製品親(フレックス親)を作成します。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>AA Illumination</publication>
<internalname>Halogen</internalname>
<fgrouptemplatename>Category</fgrouptemplatename>
<cat1>Halogen</cat1>
</document>

前述のとおり、RemoteContentPostポスト・エレメントを使用する場合は、親アセットごとに1つのソース・ファイルを用意する必要があります。

43.4 XMLPostを使用したフレックス・アセットのインポート

XMLPostを使用してフレックス・アセットをインポートする前に、構造アセット・タイプ(属性、フレックス定義およびフレックス親定義)をインポートしている必要があります。

フレックス・アセットには、RemoteContentPostとaddDataのポスト・エレメントを使用します。

- addDataポスト・エレメントは、フレックス・アセットの親アセットを作成します(親アセットがまだ存在していない場合)。たとえば、BulkLoaderユーティリティを使用していない場合は、このポスト・エレメントをフレックス・アセットの初期インポート用に使用します。
addDataポスト・エレメントを使用する場合は、ソース・ファイルでフレックス・アセットのファミリ・ツリー全体を指定する必要があります。フレックス・アセットごとに別個のソース・ファイルが必要ですが、そのソース・ファイル内ではそのフレックス・アセットの親をいくつでも指定可能であり、XMLPostはそのフレックス・アセットとその親を作成します(親がまだ存在していない場合)。

- RemoteContentPostエレメントは、フレックス・アセットを作成して、それらの親の値を設定します。これらの親は存在している必要があります。たとえば、BulkLoaderを使用して初期インポートを実行してから、XMLPostを使用する場合は、このポスト・エレメントを使用します。
RemoteContentPostを使用してフレックス・アセットをインポートする場合は、ソース・ファイルで、そのアセットの直接の親のみを指定する必要があります(その結果としてソース・ファイル内で必要なコード行が少なくなります)。ただし、その新しいフレックス・アセットの新しいフレックス親を作成するには、addDataポスト・エレメントを使用して、ソース・ファイル内でファミリ・ツリー全体を指定します。

この項には次のトピックが含まれます:

- フレックス・アセットの構成ファイル・プロパティとソース・ファイル・タグ

- addDataのサンプル・フレックス・アセット構成ファイル

- 構成ファイル・プロパティとBLOB (またはURL)型の属性

- addDataのサンプル・フレックス・アセット・ソース・ファイル

- RemoteContentPostのサンプル・フレックス・アセット構成ファイル

- RemoteContentPostのサンプル・フレックス・アセット・ソース・ファイル

43.4.1 フレックス・アセットの構成ファイル・プロパティとソース・ファイル・タグ

構造アセット・タイプの場合と同様に、構成ファイルとソース・ファイル内ではフレックス・アセット・タイプとフレックス親アセット・タイプの内部名を使用する必要があります。ただし、構造アセット・タイプの場合とは異なり、アセット・タイプの引数を構成ファイルに記述する必要はありません。フレックス・アセットのソース・ファイルにはそのアセット・タイプを指定する必須タグが含まれているため、この情報を構成ファイル内で繰り返し指定する必要はありません。

この項には次のトピックが含まれます:

- addDataポスト・エレメントの場合

- RemoteContentPostポスト・エレメントの場合

- RemoteContentPostポスト・エレメントの場合

43.4.1.1 addDataポスト・エレメントの場合

表43-5は、addDataポスト・エレメントを使用している場合の、フレックス・アセット(およびそれらのフレックス親)のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されることに注意してください。

表43-5 addDataポスト・エレメント

タグ

プロパティ

説明

<_ASSET_>

post_ASSET_

必須。

アセット・タイプの内部名。例: Products、AArticlesおよびAImages。

<_TYPE_>

post_TYPE_

必須。

このフレックス・アセットが使用しているフレックス定義の名前。

<_ITEMNAME_>

post_ITEMNAME_

必須。

アセットの名前。

<_ITEMDESCRIPTION_>

post_ITEMDESCRIPTION_

オプション。

アセットの説明。

<_GROUP_parentDefinitionName>

post_GROUP_parentDefinitionName

オプション。

フレックス・アセットの親。構成ファイルには、それぞれの考えられる親定義のタグが含まれている必要があります。たとえば、フレックス・アセットがDivisionおよびDepartmentという名前の2つの親定義のいずれかを使用する親を持っている可能性がある場合は、構成ファイルには、次のようにそれぞれの親定義のタグを定義する2つのプロパティが含まれている必要があります。

post_Group_Department

post_Group_Division

このタグとプロパティの使用方法の詳細は、「フレックス・アセットの親の指定」を参照してください。

<_GROUPDESCRIPTIONS_>

post_GROUPDESCRIPTIONS_

オプション。

指定する親が新規の場合は、親定義の説明を含めます。

<displaytype>

postdisplaytype

オプション。

フレックス・アセットのTemplateアセットの名前。

<AttributeName>

postAttributeName

タイプのアセットが持つことのできる属性(必須とオプションの両方)ごとに構成ファイルにプロパティを含めます。そして、そのアセットに適用する必須属性とオプション属性ごとにソース・ファイルで値を指定する必要があります。

たとえば、SKUという名前の属性の場合は、ソース・ファイルにpostSKUというプロパティと次のようなコード行を含めます。

<SKU>123445</SKU>

43.4.1.2 RemoteContentPostポスト・エレメントの場合

表43-6は、RemoteContentPostポスト・エレメントを使用している場合の、フレックス・アセット(およびそれらのフレックス親)のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されます。

表43-6 RemoteContentPostポスト・エレメント

タグ

プロパティ

説明

<_DEFINITION_>

post_DEFINITION_

必須。

このフレックス・アセットが使用しているフレックス定義の名前。

(post_TYPEも使用できます。)

<_ITEMNAME_>

post_ITEMNAME_

必須。

アセットの名前。

<_ITEMDESCRIPTION_>

post_ITEMDESCRIPTION_

オプション。

アセットの説明。

<ParentList>

post_ParentList

オプション。

フレックス・アセットの直接の親。

<template>

posttemplate

オプション。

フレックス・アセットのTemplateアセットの名前。

(postdisplaytypeも使用できます。)

<AttributeName>

postAttributeName

タイプのアセットが持つことのできる属性(必須とオプションの両方)ごとに構成ファイルにプロパティを含めます。そして、そのアセットに適用する必須属性とオプション属性ごとにソース・ファイルで値を指定する必要があります。

たとえば、SKUという名前の属性の場合は、ソース・ファイルにpostSKUというプロパティと次のようなコード行を含めます。

<SKU>123445</SKU>

43.4.2 addDataのサンプル・フレックス・アセット構成ファイル

ここでは、製品アセット・タイプのサンプル構成ファイルを示します。このファイルは、addDataポスト・エレメントを呼び出して、このサンプル・ファイルのすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

xmlpost.xmlfilenamefilter: .xml

#xmlpost.proxyhost: Future
#xmlpost.proxyport: 80

xmlpost.url: http://wally9:80/servlet/ContentServer

# notice that it uses addData
# rather than RemoteContentPost
xmlpost.numargs: 5

xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Gator/XMLPost/addData

# Notice that you do not need to provide
# the name of the asset type because that information
# is required in the source files for flex assets.

xmlpost.argname2: inifile
xmlpost.argvalue2: futuretense.ini
xmlpost.argname3: authusername
xmlpost.argvalue3: editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: xceleditor
xmlpost.argname5: startmenu
xmlpost.argvalue5: New Product

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: productdatalog.txt

xmlpost.postdeletefile: y

post_ASSET_: y
post_ITEMNAME_: y
post_TYPE_: y
post_GROUP_Category: y
post_GROUP_SubCategory: y
postpublication: y
postsku: y
postproductdesc: y
postcaseqty: y
postbulbshape: y
postbulbsize: y
postbasetype: y
postcolortemp: y
postmeanlength: y
postlightcenterlength: y
postreducedwattage: y
postbeamspread: y
postfixturetype: y
postballasttype: y
postcolorrenderingindex: y
postminstarttemp: y
postpowerfactor: y
posttotalharmonicdist: y
postspreadbeam10h: y
postspreadbeam10v: y
postspreadbeam50h: y
postspreadbeam50v: y
posthalogen: y
postoperatingposition: y
postfilamenttype: y
postbulbimage: y
postbaseimage: y
postfilamentimage: y
postfootnotes: y
postcat1: y
postcat2: y
postprice: y
postvoltage: y
postwattage: y
postlife: y

43.4.3 構成ファイル・プロパティとBLOB (またはURL)型の属性

アセット・タイプがblob(またはurl)型の属性を持っている場合は、構成ファイルには、その属性を参照するタグのエントリが2つ含まれている必要があります(1つはその属性を指定するエントリ、もう1つは、その属性(アップロード・フィールド)の内容が含まれているファイルの名前、またはテキスト・フィールド(blob型またはURL型のテキスト・フィールド)に直接入力されたテキストから作成されるファイルにWebCenter Sitesが付与する名前のいずれかを指定するエントリ)。

43.4.3.1 アップロード・フィールドとしてのBLOB (またはURL)型の属性

blob型の属性はアップロード・フィールドにすることができます。たとえば、footnotesという名前のblob型の属性は、テキストを入力するためのテキスト・フィールドのかわりに、ファイルを探すための「参照」ボタンが付いているアップロード・フィールドです。したがって、これは次の2つのプロパティを持ちます。

- posttag: この例では、postfootnotes: y

- filetag: この例では、filefootnotes: y

この属性の値をソース・ファイルに含める場合は、次の書式に従ってください。

<footnotes>FileName.txt</footnotes>

このタイプのフィールド(属性)を持つアセットをインポートする場合、そのフレックス・アセットの属性値として保管するテキストが含まれているファイルは、そのアセットのソース・ファイルと同じディレクトリに配置されている必要があります。

43.4.3.2 テキスト・フィールドとしてのBLOB (またはURL)型の属性

仮定のfootnotes属性が、ファイルではなくテキスト入力を直接受け付けるフィールドである場合は、構成ファイルで次のプロパティを指定する必要があります。

- postfootnotes: y

- postfootnotes_file: y

また、この属性の値をソース・ファイルに含める場合は、次の書式に従ってください。

<footnotes>lots and lots of text</footnotes>
<footnotes_file>FileNameYouWantUsed.txt</footnotes_file>

43.4.4 addDataのサンプル・フレックス・アセット・ソース・ファイル

次のソース・ファイルは、前の項で紹介したサンプルのフレックス・アセット構成ファイルと連係して機能します。

この項には次のトピックが含まれます:

- サンプル・ファイル

- 特殊文字の処理

- フレックス・アセットとそれらの親

- フレックス・アセットの親の指定

- 親の属性値の設定

- フレックス・ソース・ファイル内の複数値の設定

43.4.4.1 サンプル・ファイル

このソース・ファイルでは、10004という名前の電球製品を、Lightingという名前の製品定義から作成します。

<document>

# the first three tags are required
<_ASSET_>Products</_ASSET_>
<_ITEMNAME_>10004</_ITEMNAME_>
<_TYPE_>Lighting</_TYPE_>

# This tag is required because the publication is
# not set in the configuration file
<publication>AA Illumination</publication>

# This tag assigns a Template asset to the product
<displaytype>Lighting Detail</displaytype>

# The rest of these tags set flex attribute values for the product
<price>5</price>
<sku>10004</sku>
<productdesc>F4T5/CW</productdesc>
<caseqty>24</caseqty>
<bulbshape>T</bulbshape>
<bulbsize>5</bulbsize>
<basetype>Miniature Bipin (G5)</basetype>
<colortemp>4100</colortemp>
<meanlength></meanlength>
<lightcenterlength></lightcenterlength>
<reducedwattage></reducedwattage>
<beamspread></beamspread>
<fixturetype></fixturetype>
<ballasttype></ballasttype>
<colorrenderingindex>60</colorrenderingindex>
<minstarttemp></minstarttemp>
<powerfactor></powerfactor>
<totalharmonicdist></totalharmonicdist>
<spreadbeam10h></spreadbeam10h>
<spreadbeam10v></spreadbeam10v>
<spreadbeam50h></spreadbeam50h>
<spreadbeam50v></spreadbeam50v>
<halogen></halogen>
<operatingposition></operatingposition>
<filamenttype></filamenttype>
<bulbimage>BLB-260.gif</bulbimage>
<baseimage>BLB-250.gif</baseimage>
<filamentimage></filamentimage>
<footnotes>
</footnotes>
<life>6000</life>
<voltage></voltage>
<wattage>4</wattage>
<cat1>Fluorescent</cat1>
<cat2>Preheat Lamps</cat2>

<!-- GROUP tags that specify the parents. Remember that you have to
specify the entire family tree for the flex asset when using the addData posting element-->

<_GROUP_Category>Fluorescent</_GROUP_Category>
<_GROUP_SubCategory>Preheat Lamps</_GROUP_SubCategory>
</document>

このソース・ファイルは、製品の親をPreheat Lampsに設定して、Preheat Lampsの親をFluorescentに設定しています。

43.4.4.2 特殊文字の処理

XMLPostはHTTP POSTプロトコルを使用するため、データをHTTPストリームとして送信します。したがって、特定の文字は特殊文字として扱われ、これらの特殊文字はURLに含まれるため、これらの特殊文字をエンコードする必要があります。

ソース・ファイルで、属性値に特殊文字のいずれかが含まれている場合は、その特殊文字のすべてを対応するURLエンコード・シーケンス(「特殊文字の値について」を参照)に置換します。

43.4.4.3 フレックス・アセットとそれらの親

GROUPタグは、ファミリ・ツリー内の親を指定します。XMLPostは、addDataポスト・エレメントを使用して、ソース・ファイルのGROUPセクションを解析する際に、次の操作を実行します。

1. このフレックス定義を使用しているアセットに対して適正な親定義を特定します。

2. それぞれの適正な親定義について、その定義の親がソース・ファイルで指定されているかどうかを確認します。

- 指定されている場合は、親を設定します。親がまだ存在していない場合は、その親を作成します。

- 指定されていない場合は、その親を設定しません。ただし、その定義の親が必須である場合は、エラーを返します。

43.4.4.4 フレックス・アセットの親の指定

フレックス・アセットの親を指定するには、その親の名前を<_GROUP_parentDefinitionName>タグ内にネストした形で指定します。例:

<_GROUP_subcategory>Blacklights</_GROUP_subcategory>

このsubcategoryは、Blacklightsという親(製品親)の親定義の名前です。

前述のとおり、フレックス・アセットのファミリ・ツリー全体を指定する必要があります。たとえば、電球(Blacklight)の親を指定するだけでなく、祖父母も指定します。

<_GROUP_subcategory>Blacklights</_GROUP_subcategory>

<_GROUP_category>Fluorescent</_GROUP_category>

43.4.4.5 親の属性値の設定

ある属性が複数の親に属することができる場合は、XMLPostで、その属性が属する親を指定します。たとえば、bulbshape属性が製品ではなく親に割り当てられているとします。この場合は、次のようなコード行を含めます。

<bulbshape>Halogen=T</bulbshape>

43.4.4.6 フレックス・ソース・ファイル内の複数値の設定

親を設定するすべてのタグと、属性を指定するすべてのタグは(その属性が複数の値を受け付けるように構成されている場合)、複数の値を扱うことができます。これらのタグは次のとおりです。

- _GROUP_parentDefinitionName

- _GROUPDESCRIPTIONS_

- 属性タグ

1つのフレックス・アセットの同じ定義に基づいた複数の親がある場合は、それらの親の名前をすべて同じ_GROUP_parentDefinitionName タグで指定して、これらの親の名前をセミコロン(;)で区切ります。

例:

<_GROUP_Cateogry>Incandescent;Halogen</_GROUP_Category>

XMLPostはこのアセットをインポートする際に、その親をIncandescentおよびHalogenとして設定します(これらは両方ともCategory親定義のものです)。IncandescentとHalogenがまだ存在していない場合は、XMLPostはこれらを作成します。

複数の親の複数の属性値を設定するには、同様の構文を使用します。再び仮定として、Category定義では、この定義の親がbulbshape属性の値を保持していることが必要だとします。この場合は、<_GROUP_Category>タグで指定された両方の親のbulbshape属性の値を次のように設定できます。

<bulbshape>Incandescent=E;K:Halogen=T</bulbshape>

この構文について、次のことに注意してください。

- parentName=attributeValueという形式の名前と値のペアを使用して属性値を設定します(Halogen=T)。

- コロンを使用して、それぞれの親を区切ります。(Incandescent=S:Halogen=T)。

- 親が複数の属性値を持っている場合は、セミコロンを使用してその親の属性値を区切ります(Incandescent=E;K:Halogen=T)。

前述のとおり、同じタグで指定する親の説明を指定します。例:

<_GROUPDESCRIPTIONS>
Incandescent=From Detroit:Halogen=From Chicago
</_GROUPDESCRIPTIONS>

43.4.5 RemoteContentPostのサンプル・フレックス・アセット構成ファイル

ここでは、製品アセット・タイプのサンプル構成ファイルを示します。この例のすぐ後に掲載しているソース・ファイルと連係して機能します。

xmlpost.xmlfilenamefilter: .xml

#xmlpost.proxyhost: Future
#xmlpost.proxyport: 80

xmlpost.url: http://wally9:80/servlet/ContentServer
xmlpost.numargs: 5

xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Xcelerate/Actions/RemoteContentPost

# Notice that you do not need to provide
# the name of the asset type because that information
# is required in the source files for flex assets.

xmlpost.argname2: inifile
xmlpost.argvalue2: futuretense.ini
xmlpost.argname3: authusername
xmlpost.argvalue3: editor
xmlpost.argname4: authpassword
xmlpost.argvalue4: xceleditor
xmlpost.argname5: startmenu
xmlpost.argvalue5: New Product

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: productdatalog.txt

xmlpost.postdeletefile: y

postpublication: y

post_ASSET_: y
post_ITEMNAME_: y
post_DEFINITION_: y
posttemplate: y

postsku: y
postproductdesc: y
postcaseqty: y
postbulbshape: y
postbulbsize: y
postbasetype: y
postcolortemp: y
postmeanlength: y
postlightcenterlength: y
postreducedwattage: y
postbeamspread: y
postfixturetype: y
postballasttype: y
postcolorrenderingindex: y
postminstarttemp: y
postpowerfactor: y
posttotalharmonicdist: y
postspreadbeam10h: y
postspreadbeam10v: y
postspreadbeam50h: y
postspreadbeam50v: y
posthalogen: y
postoperatingposition: y
postfilamenttype: y
postbulbimage: y
postbaseimage: y
postfilamentimage: y
postfootnotes: y
postcat1: y
postcat2: y
postprice: y
postvoltage: y
postwattage: y
postlife: y

postParentList: y

43.4.6 RemoteContentPostのサンプル・フレックス・アセット・ソース・ファイル

次のソース・ファイルは、前の項で紹介したサンプル構成ファイルと連係して機能します。このソース・ファイルでは、10004という名前の電球製品を、Lightingという名前の製品定義から作成します。

<document>

# the first three tags are required
<_ASSET_>Products</_ASSET_>
<_ITEMNAME_>10004</_ITEMNAME_>
<_DEFINITION_>Lighting</_DEFINITION_>

# This tag is required because the publication is
# not set in the configuration file
<publication>AA Illumination</publication>

# This tag assigns a Template asset to the product
<template>Lighting_Detail</template>

# The rest of these tags set flex attribute values for the product
<price>5</price>
<sku>10004</sku>
<productdesc>F4T5/CW</productdesc>
<caseqty>24</caseqty>
<bulbshape>T</bulbshape>
<bulbsize>5</bulbsize>
<basetype>Miniature Bipin (G5)</basetype>
<colortemp>4100</colortemp>
<colorrenderingindex>60</colorrenderingindex>
<bulbimage>BLB-260.gif</bulbimage>
<baseimage>BLB-250.gif</baseimage>
<filamentimage></filamentimage>
<life>6000</life>
<voltage></voltage>
<wattage>4</wattage>
<cat1>Fluorescent</cat1>
<cat2>Preheat Lamps</cat2>

# this tag sets the immediate parents only
<ParentList>Preheat Lamps</ParentList>

</document>

このソース・ファイルでは、製品のいくつかの属性値を設定して、その直接の親をPreheat Lampsに設定しています。この親は存在している必要があります。

43.5 XMLPostを使用したフレックス・アセットの編集

XMLPostを使用して、フレックス・アセットとフレックス親アセットに関する次の情報を編集できます。

- 属性の値

- アセットの親(フレックス・アセットの親またはその親の親)

属性アセット、フレックス定義アセットおよびフレックス親定義アセットは、XMLPostを使用して編集することはできません。

フレックス・アセットの属性値を編集するには、ソース・ファイルには、変更する属性とそのアセットの名前のみが含まれている必要があります。

フレックス親の属性値を編集するには、フレックス・アセットのコンテキストを提供する必要があります。ソース・ファイルでは、そのフレックス・アセットの名前が指定されている必要があり、そうすることで、変更する親属性と親のみを参照できます。ただし、XMLPostが最初に扱うフレックス・アセットを指定する必要があります。その結果として、XMLPostはファミリ・ツリー内を移動できるようになります。

この項には次のトピックが含まれます:

- フレックス・アセットを編集するための構成ファイル

- フレックス・アセットを編集するためのソース・ファイル

43.5.1 フレックス・アセットを編集するための構成ファイル

フレックス・アセットを編集するための構成ファイルには、pagename引数と追加のタグおよびプロパティという2つの相違点があります。

pagename引数

pagename引数は、OpenMarket/Gator/XMLPost/modifyDataに設定する必要があります。

例:

xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Gator/XMLPost/modifyData

構成ファイルとソース・ファイルを指定して、XMLPostをコマンドラインから通常どおりに起動します。

追加のタグとプロパティ

フレックス・アセットの編集時には、次のオプションのタグとプロパティを使用できます。

- タグ: <_REMOVE_parentDefinitionName>

- プロパティ: post_REMOVE_parentDefinitionName

これにより、そのフレックス・アセットから親が削除されます。

同じ名前(_ITEMNAME_)、同じアセット・タイプ(_ASSET_)および同じサブタイプ(_TYPE_)の別のアセットが同じサイトにある場合は、次のオプションのタグとプロパティを使用して、変更するアセットを指定できます。

- タグ: <_ID_>

- プロパティ: post_ID_

43.5.2 フレックス・アセットを編集するためのソース・ファイル

編集対象のフレックス・アセットのソース・ファイルには、そのアセットのすべての情報が含まれている必要はなく、変更する情報のみを指定する必要があります。指定されていない属性は一切変更されません。

この項には次のトピックが含まれます:

- 属性の値の変更

- 属性値の削除

- 親関係の編集

43.5.2.1 属性の値の変更

属性の値を変更するには、その属性の新しい値をソース・ファイル内で指定します。XMLPostはインポートの実行時に、ソース・ファイルで指定された値によって古い値を上書きします。

次のサンプル・ソース・ファイルでは、「addDataのサンプル・フレックス・アセット・ソース・ファイル」で定義された10004という名前の製品の2つの属性値(bulbshapeとbulbsize)を変更します。

<document>
<!-- predefined xml tags (required) -->

<_ASSET_>Products</_ASSET_>
<_ITEMNAME_>10004</_ITEMNAME_>
<_TYPE_>Lighting</_TYPE_>

<!-- attribute xml tags -->

<bulbshape>E</bulbshape>
<bulbsize>9</bulbsize>

</document>

43.5.2.2 属性値の削除

- 属性値を削除して空のままにするには、その属性の名前を指定する行を記述して、その属性の値として_EMPTY_を指定します。
例:

<bulbsize>_EMPTY_</bulbsize>

注意:
複数値属性を空にするには、_EMPTY_のかわりに、複数値デリミタ(デフォルトで;文字)を設定します。  例: <someattribute>;</someattribute>。

親の属性値を編集することもできます。たとえば、bulbsize属性が親レベルで設定されているとします。その場合は、次のコード行によって2つの親が設定されて、それぞれの親のbulbsizeの値が指定されます。

<_GROUP_SubCategory>All-Weather Lamps;Appliance Lamps
</GROUP_SubCategory>
<bulbsize>All-Weather Lamps=10:Appliance Lamps=8</bulbsize>

オプション1

次のコード行は、All-Weather Lampsという親のbulbsizeをクリアします。

<bulbsize>All-Weather Lamps=_EMPTY_:Appliance Lamps=8</bulbsize>

オプション2

別の方法として、次のコード行のみを使用して、Appliance Lampsの値を繰り返し指定することを回避できます。

<bulbsize>All-Weather Lamps=_EMPTY_</bulbsize>

43.5.2.3 親関係の編集

XMLPostを使用して、フレックス・アセットの親関係を次のように編集できます。

- 既存の親に別の親を追加できます。

- 親を別の親に変更できます。

GROUP_parentDefinitionNameタグの動作は、属性タグの動作とは異なります。

- 属性タグを使用している場合は、XMLPostは古い値を新しい値によって上書きします。

- GROUP_parentDefinitionNameタグを使用すると、親定義名が同じであっても、XMLPostは古い親を新しい親で上書きしません。アセットの親のリストに新しい親が追加されますが、これは目的の処理ではない可能性があります。

1. 既存の親のリストに別の親を追加するには、そのためのコード行をソース・ファイルに含めます。例:

<_GROUP_SubCategory>Blacklights</_GROUP_SubCategory>

2. 親を削除するには、<_REMOVE _>タグを使用します。親を置換する場合を除いて、必要な親を削除しないように十分に注意してください。例:

<_REMOVE_Processor>Appliance Lamps</_REMOVE_Processor>

43.6 XMLPostを使用したアセットの削除

XMLPostを使用して、任意のタイプの任意のアセットを削除するための要件は次のとおりです。

- 構成ファイルでは、deleteDataエレメントをコールするようにXMLPostに指示する必要があります。
例:

xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Gator/XMLPost/deleteData

- 次の2つのソース・ファイル・タグと構成ファイル・プロパティを使用する必要があります。
<_ASSET_>/post_ASSET_: 削除するアセットのアセット・タイプを指定します。

<_ITEMNAME>/post_ITEMNAME_: 削除するアセットを指定します。

XMLPostがこのポスト・エレメントを使用する場合、XMLPostはそのアセットのStatus列の値をvoidを意味するVOに変更します。(このアセットをデータベースから物理的に削除するわけではありません)。

この項には次のトピックが含まれます:

- アセットを削除するための構成ファイル

- アセットを削除するためのソース・ファイル

43.6.1 アセットを削除するための構成ファイル

次に、サンプル構成ファイルを示します。

xmlpost.xmlfilenamefilter: .xml

xmlpost.url: http://izod19/servlet/ContentServer
xmlpost.numargs: 4
xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Gator/XMLPost/deleteData
xmlpost.argname2: authusername
xmlpost.argvalue2: user_editor
xmlpost.argname3: authpassword
xmlpost.argvalue3: user
xmlpost.argname4: inifile
xmlpost.argvalue4: futuretense.ini

xmlpost.success: Success
xmlpost.failure: Error
xmlpost.logfile: productdefpostlog.txt
xmlpost.deletefile: y

postpublication: y
post_ASSET_: y
post_ITEMNAME_: y

XMLPostを通常どおりコマンドラインから起動します。

43.6.2 アセットを削除するためのソース・ファイル

アセットを削除するためのソース・ファイルは小さくてシンプルです。例:

<document>

<_ASSET_>Products</_ASSET_>
<_ITEMNAME_>Pentium 90</_ITEMNAME_>
<publication>my publication</publication>

</document>

このコードは、Pentium 90という名前の製品アセットを削除するようにXMLPostに指示します(XMLPostはPentium 90のステータスをvoidを意味するVOに変更します)。

44 BulkLoaderユーティリティによるフレックス・アセットのインポート

WebCenter Sitesシステムの初期設定時には、BulkLoaderユーティリティを使用してフレックス・アセットをインポートします。

BulkLoaderユーティリティを使用したフレックス・アセットのインポートの詳細は、次の項を参照してください。

- BulkLoaderユーティリティについて

- カスタム抽出メカニズムを使用したフレックス・アセットのインポート

- BulkApproverユーティリティによるフレックス・アセットの承認

44.1 BulkLoaderユーティリティについて

BulkLoaderユーティリティを使用することにより、大量のフレックス・アセット・データをユーザー自身のデータソースからユーザーが定義した方法で迅速に抽出し、任意のシステム(開発、管理、テスト、または配信システム)上のWebCenter Sitesデータベースにインポートできます。

抽出メカニズムは、顧客が実装可能なJavaインタフェースを使用して引き出されます。BulkLoaderは、このインタフェース上でメソッドを呼び出して、データソースから入力データを抽出します。下位機能互換性とデータ互換性を確保するためにWebCenter SitesにはこのJavaインタフェースの実装も組み込まれているため、BulkLoaderはJDBC互換のデータソースからデータを抽出することも可能です。

次の各項では、BulkLoaderユーティリティについて説明します。

- BulkLoader機能の理解

- BulkLoaderの仕組み

- BulkLoaderユーティリティの使用について

- フラット表からのフレックス・アセットのインポート

- XMLPostを使用して構造アセットをインポートするタイミング

- 入力表(データソース)の作成

- マッピング表の作成

- BulkLoader構成ファイルの作成

- BulkLoaderユーティリティの実行

- Contributorインタフェースでのインポート済アセットへのアクセスの有効化

- フィードバック情報の確認

- アセットの承認と配信システムへのパブリッシュ

44.1.1 BulkLoader機能の理解

BulkLoaderには次の機能があります。

- ユーザー定義の抽出メカニズムに対するJava APIの使用によるサポート。ユーザーは、この抽出インタフェースをカスタム実装するか、JDBCデータソースからの抽出用の組込みサポートを使用できます。

- フレックス・アセットおよびグループ・データに対する挿入、無効化、更新のサポート。

- 増分挿入、増分無効化、増分更新に対するサポート。

- データ抽出中にマルチスレッド・インポート操作を同時実行することによる、スループットを高めるためのパフォーマンス向上。

- 入力データのチャンク(スライス)処理に対するサポート。

- 複数のフレックス・ファミリに属するアセット・データのインポートに対するサポート。

- 下位機能互換性およびデータ互換性。外部JDBCソースからのアセット・データのインポートをサポートします。

44.1.2 BulkLoaderの仕組み

BulkLoaderの再設計により、パフォーマンス、スループットおよびスケーラビリティの向上を実現しました。すべての入力データを読み取った後に出力SQLファイルを生成するのではなく、BulkLoaderは入力データをチャンクとして読み取ります。1つのチャンクが読み取られると即時にインポート・スレッドに渡されると同時に、BulkLoaderスレッドは次のチャンクを読み取るために戻ります。インポート・スレッドは、WebCenter SitesデータベースとJDBCの直接接続を利用します。この方法によって読取りとインポートが並行して実行されるため、スループットの向上が達成されます。スケーラビリティについては、データベース・コンピュータのハードウェアの追加CPUと、同時実行性の高度化に対応するI/O構成を使用して、BulkLoaderのインポート・スレッド数を増加できます。

BulkLoaderユーティリティは、処理中スレッド数を指定するパラメータ、データ抽出インタフェースを実装するJavaクラスの名前、コミット頻度、アセットIDとして使用する一意の開始IDなどが含まれている構成ファイルを必要とします。

図44-1および図44-2に、クライアント固有の実装と、WebCenter Sitesにより提供される、組込みの使用準備済の実装を示します。

図44-1 BulkLoaderのクライアント固有の実装

図44-2 BulkLoaderの組込みOOTB (out of the box: すぐに使用可能な)実装

44.1.3 BulkLoaderユーティリティの使用について

WebCenter Sitesデータベースにインポートする入力データの提供方法に応じて、BulkLoaderは2通りの方法で使用できます。

- 外部JDBCデータソースからの入力データをBulkLoaderでインポートする場合は、入力データをフラット表またはフラット・ビューで提供します。

- 入力データを独自の方法でBulkLoaderに提供する場合は、抽出インタフェースIDataExtractを実装するJavaオブジェクトを使用します。

注意:

参照用に、サンプルのBulkLoaderコードがWebCenter Sitesのインストール・メディア(Samplesフォルダ)に収録されています。同じフォルダに、サンプル・ファイルの説明が記載されたreadme.txtファイルも含まれています。

44.1.4 フラット表からのフレックス・アセットのインポート

この項では、BulkLoaderによるフレックス・アセットのインポートに使用する一般手順について説明し、後続の各項では手順ごとに詳しく説明します。このモデルを使用して、新規フレックス・アセットと親をインポートしたり、以前にインポートしたアセットを無効化します。このモデルは、既存アセットの属性値の変更および削除もサポートしています。

44.1.4.1 基本手順

BulkLoaderユーティリティを使用してフレックス・アセットをインポートするには:

1. 管理システムで、XMLPostを使用して構造アセットをWebCenter Sitesデータベースにインポートします。構造フレックス・アセットとして、属性エディタ、フレックス属性、フレックス親定義、フレックス定義およびフレックス親アセットがあります。

2. WebCenter Sitesデータベースにフラット表としてインポートするソース・データベースのビューを提供するビューまたはストアド・プロシージャを書き込みます。このフラット表がソース表になります。

3. 同じソース・データベース内に2つの列を持つマッピング表を作成します。1つの列にはソース・ファイルの列名を示し、もう1つの列にはWebCenter Sitesデータベースに格納されている属性の名前を示します。

4. ソース表とマッピング表を識別する構成ファイルをコーディングします。

5. 管理システム上のWebCenter Sitesデータベースとソース・データベースの両方へのアクセスに使用したシステムに構成ファイルを配置します。

6. 管理システム上のアプリケーション・サーバーを停止します。

7. BulkLoaderユーティリティを実行します。BulkLoaderはフレックス・アセット・データをインポートして、入力データソースで作成されたbulk_feedbackという表にフィードバックを提供します。

8. 管理システムでアプリケーション・サーバーを再起動します。

9. BulkApproverユーティリティを使用して、ロードされたすべてのアセットを承認します。

注意:

BulkLoaderユーティリティは高速化を図って作成されているため、属性、フレックス親定義またはフレックス定義の有無のチェックは行いません。BulkLoaderユーティリティを実行する前に、すべての構造アセット・タイプをインポートしておく必要があります。

44.1.4.2 ドライバ要件

BulkLoaderには、Oracle Corporationによって提供されていないJDBC (またはJava DataBase Connectivity)ドライバが必要です。ソース・データベースと宛先データベース(つまり、WebCenter Sitesデータベース)の両方に対してJDBCドライバを取得する必要があります。ODBC互換のソース・データベースの場合は、Java SDKの一部として付属するJDBC-ODBCブリッジを使用します。

44.1.4.3 DB2の要件

BulkLoaderを使用する前に、クライアント・コンピュータ上でusejdbc2.batファイルを実行します。バッチ・ファイルを1回実行してから、BulkLoaderを通常どおりに実行します。

44.1.5 XMLPostを使用して構造アセットをインポートするタイミング

管理システムで、XMLPostとRemoteContentPostポスト・エレメントを使用して、構造アセットをWebCenter Sitesデータベースにインポートします。次のタイプのアセットをインポートします。

- 属性エディタ

- フレックス属性

- フレックス親定義

- フレックス定義

- フレックス親アセット

詳細は、「フレックス・モデル内の構造アセット・タイプのインポートについて」を参照してください。

44.1.6 入力表(データソース)の作成

すべての新規アセット・データと更新データを保持するために、入力フラット表(データソース)を作成する必要があります。これらのフラット表/フラット・ビューでは、各行が1つのフレックス・アセット・アイテムに相当し、各列がBulkLoaderユーティリティ用のフレックス属性アセットに相当します。

データソースの列名に関して特に要件はありませんが、「マッピング表の作成」で説明するマッピング表を別途作成する必要があります。

この項には次のトピックが含まれます:

- 挿入

- 更新

44.1.6.1 挿入

データソース表の名前は、構成ファイル内のinputTableパラメータによって指定されます。

ソース表には、次のプロパティを使用して構成ファイルに指定した次の4つの列名も含める必要があります。

- inputTableTemplateColumn: ソース表でフレックス定義の名前を保持する列の名前。

- inputTableNameColumn: ソース表でフレックス・アセットの名前を保持する列の名前。この列の名前は64文字を超えることはできません。

- inputTableDescriptionColumn: ソース表でフレックス・アセットの説明を保持する列の名前。

- inputTableGroupsColumn: 親名を保持するソース表内の列の名前。この列の各値には、複数のフレックス親名を、構成ファイルに定義されているmultivalueDelimeter文字で区切って含めることができます。

オプションとして、構成ファイル内のパラメータinputTableUniqueIdColumnを使用すると、入力アイテム別に一意のIDとして機能する列の名前を指定できます。このパラメータに値が割り当てられていない場合、BulkLoaderは入力アイテム別に一意のIDを生成し、そのIDをWebCenter Sitesデータベース内のマッピング表(bulkloader_ids)に格納します。

図44-3に、ソース表(入力表)の例を示します。

図44-3 ソース入力表のサンプル

ソース表の列名に基づいて、対応する構成ファイル内のソース表プロパティが次のように設定されます。

inputTableTemplateColumn=SNSTEMPLATE
inputTableNameColumn=SNSNAME
inputTableDescriptionColumn=SNSDESCRIPTION
inputTableGroupsColumn=SNSGROUPS

44.1.6.2 更新

既存アセットに対して新規の親を追加したり既存の親を削除するために既存アセットの属性データを更新するには、更新パラメータを使用します。

構成ファイル内のinputTableForUpdatesパラメータを使用して、データソース表の名前を指定します。ソース表には、次のプロパティを使用して構成ファイルに指定した次の3つの列名も含める必要があります。

- inputTableForUpdatesUniqueIdColumn: ソース表でWebCenter Sitesデータベース内のフレックス・アセットまたはフレックス親を一意に識別する列の名前。

- inputTableForUpdatesDeleteGroupsColumn : ソース表で現在のフレックス・アセットに対して削除する親のリストを指定する列の名前。

- inputTableForUpdatesAddGroupsColumn : ソース表で現在のフレックス・アセットに対して追加する親のリストを指定する列の名前。

属性に更新を適用した場合、BulkLoaderは列値を次のように解釈します。

- 特定の属性列に表示されたNULL値は、現在のフレックス・アセットの属性が削除の対象であることを示します。たとえば、deletegroups列のNULL値は、親を削除する必要がないことを示します。addgroups列のNULL値は、親を追加する必要がないことを示します。

- 非NULL値は、既存の属性値を指定された値で置換する必要があることを示します。たとえば、deletegroups列の非NULL値は、削除する親のリストを指定します。addgroupsの非NULL値は、新規の親が指定されたフレックス・アセットに追加されることを示します。

44.1.7 マッピング表の作成

また、BulkLoaderユーティリティに対してマッピング表を作成し、次の2つの列を設定する必要があります。

- フラット・データソースにフレックス属性列の名前を保持する列。

- WebCenter Sitesデータベースにそれぞれの対応する名前を保持する列。

マッピング表では、この2つの列は1対1で対応しています。たとえば、ソース表では、A96714328445のように自動生成された名前を持つベンダー名の列が、単にVENDOR_IDという名前の製品属性アセットにマッピングされている場合があります。

マッピング表には、次の構成ファイルのプロパティを含めます。

- inputAttributeMapTable: マッピング表ファイルの名前

- inputAttributeMapTableKeyCol: マッピング表でソース表に属性名を一覧表示する列の名前

- inputAttributeMapTableValCol: WebCenter Sitesデータベース内で対応する属性アセット名を一覧表示する列の名前。

図44-4に、マッピング表の例を示します。

図44-4 マッピング表のサンプル

ソース表の列名に基づいて、対応する構成ファイル内のソース表プロパティが次のように設定されます。

inputAttributeMapTable=93ATTR_MAP
inputAttributeMapTableKeyCol=SOURCENAME
inputAttributeMapTableValCol=ATTRIBUTENAME

44.1.8 BulkLoader構成ファイルの作成

BulkLoaderユーティリティを作成するには、この項で説明するプロパティを持つ構成ファイルを作成します。このファイルには任意の名前を付けることができます。

次の構文に従ってファイルにプロパティを設定します。

property=value

注意:

構成ファイルのプロパティ名および値はすべて、大文字と小文字を区別します。

この項には次のトピックが含まれます:

- BulkLoader構成ファイルのプロパティ

- initIDパラメータの設定

- 構成ファイルの例

44.1.8.1 BulkLoader構成ファイルのプロパティ

表44-1に、BulkLoader構成ファイルのプロパティを説明します。

表44-1 BulkLoader構成ファイルのプロパティ

プロパティ名

必須/オプション

コメント

maxThreads

必須

同時処理スレッドの最大数。これは、WebCenter Sitesデータベース・サーバーへのデータベース接続数でもかまいません。データベース・ホスト上のCPU数に相当するスレッド数を使用します。CPUデータベース・ホストが1つの場合は、2に設定します。

例: 4

dataSliceSize

必須

1回の読取りリクエストで取得されるアイテム数。この数も1つの処理スレッドによって処理されます。

例: 2000

dataExtractionImplClass

必須

データ抽出APIに対応するユーザー固有の実装クラス。(String configFilename)シグネチャのあるコンストラクタが必要です。ここに示すものは、後方互換性のための参照実装クラスです。フラット表のデータ。

デフォルト値(使用準備済): com.openmarket.gatorbulk.objects.DataExtractImpl

initId

必須

開始WebCenter Sites IDを使用すると、最初のBulkLoaderが動作します。その後は、idSyncFileの値が使用されます。

例: 800000000000

詳細は、「initIDパラメータの設定」を参照してください。

idSyncFile

必須

次に使用可能なWebCenter Sites IDがこのファイルに保存されます。BulkLoaderのセッション中に更新されます。

例: C:\FutureTense\BulkLoaderId.txt

idPoolSize

必須

BulkLoaderがWebCenter Sites IDを生成する必要が生じるたびに、その数のIDが収集されてメモリーにキャッシュされます。(アセット数*属性の平均数*2)が、妥当な推定値です。

例: 1000

commitFrequency

必須

データベース・トランザクションの一部とするフレックス・アセット・グループの数。

例: 100

outputJdbcDriver

必須

WebCenter SitesデータベースにアクセスするためのJDBCドライバ・クラスの名前。ここに示す値はOracle 9.0ドライバを反映しています。

例: oracle.jdbc.driver.OracleDriver

outputJdbcURL

必須

JDBC URL。次の例に示す値は、代表的なtype2 oracle JDBCドライバのURLです。

Jdbc:oracle:oci8:@foo

outputJdbcUsername

必須

WebCenter Sitesデータベースのユーザー名。

outputJdbcPassword

必須

WebCenter Sitesデータベースのユーザー・パスワード。

inputTable

必須

新規アセット・データの挿入元であるフラット入力表の名前。

inputAttributeMapTable

必須

ソース表の列と対応する属性名を一覧表示するマッピング表の名前。

inputAttributeMapTableKeyCol

必須

マッピング表でソース表の列名を一覧表示する列の名前。

例:

inputAttributeMapTableKeyCol=SOURCENAME

inputAttributeMapTableValCol

必須

マッピング表で対応する属性名を一覧表示する列の名前。

例:

inputAttributeMapTableValCol=ATTRIBUTENAME

inputTableDescriptionColumn

必須

ソース表でフレックス・アセットの説明を含めた列の名前。

例:

inputTableDescriptionColumn=SNSDESCRIPTION

inputTableGroupsColumn

必須

ソース表で親の名前を含めた列の名前。

各値には、複数の親を、構成ファイルに定義されているmultivalueDelimeter文字で区切って含めることができます。

例:

inputTableGroupsColumn=SNSGROUP

inputTableNameColumn

必須

ソース表で行ごとに製品(または詳細記事または詳細イメージ)の名前を含めた列の名前。

例:

inputTableNameColumn=SNSNAME

inputTableTemplateColumn

必須

ソース表でフレックス定義を含めた列の名前。

例:

inputTableTemplateColumn=SNSTEMPLATE

createdby

必須

フレックス・アセット用にcreatedbyフィールドに入力する必要のあるユーザー名。

例:

createdby=editor

multivalueDelimeter

必須

複数の属性値を区切るデリミタ。デフォルト値はセミコロン(;)です。

例:

multivalueDelimiter=;

siteName

必須

サイトの名前。すべての製品は、このサイトで作成されたかのように動作します。

例:

siteName=AA Illumination

status

必須

インポートされたすべてのフレックス・アセットのステータス・コード。インポート済のものに対してこれをPLに設定してください。

例:

status=PL

tableProducts

必須

WebCenter Sitesデータベースに定義されたフレックス・アセット・タイプの名前。

inputTableUniqueIdColumn

必須

ソース表で新規フレックス・アセットのインポート時に一意のIDとして機能する列の名前。これは、後続のすべての更新操作および無効化操作に使用されます。

BulkLoaderが一意の識別子を生成できるようにするには、この値を空白にします。

targetName

必須

WebCenter Sitesに定義されたパブリッシュ・ターゲットの名前。

renderTemplate

オプション

フレックス・アセットのレンダリングに使用されるテンプレートの名前(非推奨)

inputFeedbackTable

必須

処理された入力アイテムごとに処理中フィードバックを記録するためにBulkLoaderが作成して使用する表の名前。この表は入力データソースに作成されます。

inputTableForUpdates

オプション

BulkLoaderユーティリティの実行時に更新アクションが指定された場合のみ必要です。それ以外の場合、この値は空にできます。これは、更新を必要とする属性と親を含めたソース表の名前です。

inputTableForUpdatesUniqueIdColumn

オプション

BulkLoaderユーティリティの実行時に更新アクションが指定された場合のみ必要です。これは、ソース表でフレックス・アセットに対して一意のIDを指定する列の名前です。

inputTableForUpdatesDeleteGroupsColumn

オプション

更新アクションが指定されていて、1つ以上のフレックス・アセットで1つ以上の親を削除する必要がある場合のみ必要です。

これは、ソース表で削除する親のリストを指定する列の名前です。

inputTableForUpdatesAddGroupsColumn

オプション

更新アクションが指定されていて、1つ以上のフレックス・アセットで1つ以上の親を追加する必要がある場合のみ必要です。これは、ソース表で追加する親のリストを指定する列の名前です。

inputLimitRows

オプション

テストのみに必要です。アクション(挿入、無効化または更新)ごとに処理される入力アイテムの数が制限されます。

updatedby

オプション

フレックス・アセット用にcreatedbyフィールドに入力する必要のあるユーザー名。例: updateby=editor

updatedstatus

オプション

更新されたすべてのフレックス・アセットのステータス・コード。これはEDに設定する必要があります。

例: updatestatus=ED

44.1.8.2 initIDパラメータの設定

initIDパラメータはBulkLoaderがこの値から開始するシード値であり、アセット別に一意のアセットIDを作成する際に増分されます。WebCenter Sitesにより生成される、既存の(または将来の)アセットID番号とのID競合を起こさないID番号の連続ブロックを、BulkLoaderで作成できるようにするシード値番号を選択する必要があります。

現在、WebCenter Sitesで作成されるアセットIDに対して1兆から始まります。競合を避けるために、BulkLoaderユーティリティの実行時に十分に低い数字を選択して、最も高いID番号が900,000,000,000を超えないようにしてください。

BulkLoaderは、データソース表の行/列ごとに1つのアセットを作成します。出力表の各行には専用の一意のアセットIDが必要です。

次のガイドラインを使用して、BulkLoaderユーティリティで作成されるアセットIDの適切な数を決定してください。

- フレックス・アセットごとに5行、さらに

- フレックス・アセットごとに属性1つにつき2行

たとえば、データソース表の内容が次の場合:

- 10,000製品アセット

- 製品ごとに20の属性(製品定義で決定されたとおり)

- 製品ごとに10の継承属性(製品親定義で決定されたとおり)

さらに、次の数のIDを許可する必要があります。

(5 x 10,000) + (2 x 30 x 10,000) = 50,000 + 600,000 = 650,000アセットID

initIDの値が800,000,000,000の場合、BulkLoaderは800,000,000,000から約800,000,650,000までのID番号を作成します。

44.1.8.3 構成ファイルの例

BulkLoader構成ファイルの例を次に示します。

# New BulkLoader configuration for backward compatibility
#
# input datasource configuration
inputJdbcDriver=sun.jdbc.odbc.JdbcOdbcDriver
inputJdbcURL=jdbc:odbc:access-db-conn
inputJdbcUsername=
inputJdbcPassword=
#
# Source tables
#
inputTable=PRD_FLAT_50000
inputAttributeMapTable=PRD_FLAT_ATTRIBUTE_MAP
inputAttributeMapTableKeyCol=SOURCENAME
inputAttributeMapTableValCol=ATTRIBUTENAME
#
# input column names
#
inputTableTemplateColumn=CCTemplate
inputTableNameColumn=CCName
inputTableDescriptionColumn=CCDescription
inputTableGroupsColumn=CCGroups
#
# WebCenter Sites database
#
#  This database is always used for looking up Attributes, #  Product Types and Product Group Types. #  Data is imported into this database.
#
outputJdbcDriver=oracle.jdbc.driver.OracleDriver
outputJdbcURL=jdbc:oracle:oci8:@foo
outputJdbcUsername=csuser
outputJdbcPassword=csuser
#
# Data-specific settings
#
siteName=AA Illumination
targetName=Mirror Publish to burst37
initId=800000000000
createdby=user_designer
status=PL
renderTemplate=CLighting Detail
MAX_ATTRIBUTES=100
multivalueDelimiter=;
commitFrequency=50
#
# The following denotes the flex asset type that we are importing.
tableProducts=Products
#
# Additional information needed for BulkLoader
maxThreads=2
# dataSliceSize 0 means read all input data in one slice.
dataSliceSize=500
dataExtractionImplClass=com.openmarket.gatorbulk.objects.DataExtractImpl
idSyncFile=C:\\FutureTense50\\bulk_uniqueid.dat
idPoolSize=50000
# For inserts
inputTableUniqueIdColumn=
inputFeedbackTable=bulk_feedback
# For updates
inputTableForUpdates=prod_flat_2_upd
inputTableForUpdatesUniqueIdColumn=input_id
inputTableForUpdatesDeleteGroupsColumn=CCGroups
inputTableForUpdatesAddGroupsColumn=
inputLimitRows=1000
############################################################

44.1.9 BulkLoaderユーティリティの実行

開始する前に、ソース・データベースとターゲットWebCenter Sitesデータベースの両方に適切なJDBCドライバが指定されていることを確認してください。

BulkLoaderユーティリティを実行するには:

1. Adminインタフェースで、Lucene検索エンジンの索引付けを無効にします。手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの管理』を参照してください。

2. 管理システム上のWebCenter Sitesデータベースとソース・データベースの両方へのアクセスに使用したシステムに構成ファイルを配置します。

3. 管理システム上のアプリケーション・サーバーを停止します。

4. Bulkloaderを起動し稼働するには、クラスパスに<ORACLE_HOME>\wcsites\webcentersites\sites-home\lib\*および<ORACLE_HOME>\oracle_common\modules\clients\*ディレクトリを設定します。
WebCenter SitesでSQL Serverデータベースを使用している場合は、クラスパスにOracle_Home\oracle_common\modules\*を含めます。

5. すべての単一行に、次のコマンドをそれぞれのインストールに適したパスとともに入力します。

UNIXの場合

java -ms16m -mx256m -cp <ORACLE_HOME>/wcsites/webcentersites/sites-home/lib/*:<ORACLE_HOME>/oracle_common/modules/clients/* com.openmarket.gatorbulk.objects.BulkLoader config=bulkloader.ini action=<insert|void|update> validate=<yes|no>

Windowsの場合

java -ms16m -mx256m -cp <ORACLE_HOME>\wcsites\webcentersites\sites-home\lib\*:<ORACLE_HOME>\oracle_common\modules\clients\* com.openmarket.gatorbulk.objects.BulkLoader config=bulkloader.ini action=<insert|void|update> validate=<yes|no>

アクション・パラメータは、BulkLoaderが実行する必要のあるアクションとしてinsert、voidまたはupdateを指定します。検証パラメータをyesに設定すると、BulkLoaderは更新および無効化の際に追加の検証を実行します。入力データのサイズによっては、JVM用にメモリーを増設する必要もあります。

6. 画面出力を調べて、BulkLoaderユーティリティが適切なデータベースに接続できていることを確認してください。

44.1.10 Contributorインタフェースでのインポート済アセットへのアクセスの有効化

BulkLoaderユーティリティを使用してインポートしたアセットにOracle WebCenter Sites: Contributorインタフェースからアクセスするには、次の手順を実行します。

1. Lucene検索エンジンの索引付けを再度有効にします。手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの管理』を参照してください。

2. BulkLoaderユーティリティを使用してインポートしたアセットを検索索引に追加します。手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの管理』を参照してください。

3. BulkLoaderユーティリティを使用してインポートしたアセットに対してContributorインタフェースで検索を実行することにより、Contributorインタフェースからアセットにアクセスできることを確認します。Contributorインタフェースでの検索の実行の詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの使用』を参照してください。

44.1.11 フィードバック情報の確認

BulkLoaderユーティリティの操作完了後、入力データソースに配置されているbulk_feedback表でフィードバック情報を確認します。この表には、BulkLoaderによって処理されたすべての入力アイテムに関する情報が含まれています。

この情報を確認した後で、必要に応じて修正アクションを実行します。入力データを修正する場合は、BulkLoaderを再実行してエラーが修正されていることを確認します。

44.1.12 アセットの承認と配信システムへのパブリッシュ

BulkApproverユーティリティを使用して、ロードしたばかりのアセットを承認します。BulkApproverの使用手順は、「BulkApproverの使用」を参照してください。

44.2 カスタム抽出メカニズムを使用したフレックス・アセットのインポート

入力アセット・データをBulkLoaderに提供するために、代替メカニズムが必要になる場合があります。このような場合は、XMLドキュメント、ファイル、レガシー・データベースなど、複数のタイプのソースからデータを集める必要が生じることがあります。これを実行するには、WebCenter Sitesで提供するJavaインタフェースcom.openmarket.bulkloader.interfaces.IDataExtractを使用してユーザー独自のメカニズムを実装し、BulkLoaderにデータを提供できます。

ユーザーは、IDataExtractをサポートするJavaオブジェクトを実装して、BulkLoader構成ファイルにJavaオブジェクトを指定できます。BulkLoaderはこのインタフェース上で読取りリクエストを初期化するメソッドを呼び出して、入力データのチャンクを繰り返し読み取り、読取りリクエスト終了の信号を送ります。このインタフェースにはBulkLoaderユーティリティからのインポート・フィードバックを提供するメソッドもあり、入力プロバイダはこのメソッドを使用してインポートのステータスと、インポート中に発生した可能性のあるエラーを把握できます。

IDataExtractのカスタム実装に役立つ3つのJavaインタフェースがあります。

- IDataExtract: すべてのカスタム抽出に必須です。

- IPopulateDataSlice: BulkLoaderユーティリティにデータを提供します。このインタフェースをサポートするコンテナ・オブジェクトがBulkLoaderによって作成され、クライアントに渡されます。

- IFeedback: BulkLoaderによって処理された各入力アイテムのステータスを提供します。BulkLoaderインポート・スレッドによって作成され、移入されたフィードバック・オブジェクトがクライアントに渡されます。

これらのインタフェースについて、次の各項で説明します。

- IDataExtractインタフェース

- IPopulateDataSlice

- IFeedbackインタフェース

44.2.1 IDataExtractインタフェース

このインタフェースは、すべてのカスタム抽出に必須です。

次に、このインタフェースを実装するサンプル・コードを示します。

com.openmarket.gatorbulk.interfaces.IDataExtract

package com.openmarket.gatorbulk.interfaces;
import java.util.Iterator;

/**
* To be implemented by input data provider.
* Interface for extracting data from an input source
* for BulkLoader.
* BulkLoader loads an object supporting this interface and invokes
* the GetNextInputDataSet() method on this interface repeatedly to
* fetch data in batches.
*/

public interface IDataExtract {

public  final int HAS_DATA    = 100;
public  final int NO_DATA = 101;

public  final int SUCCESS = 0;
public  final int ERROR = -1;

public  final int INSERT_ASSETS = 1000;
public  final int VOID_ASSETS = 1010;
public  final int UPDATE_ASSETS = 1020;
public  final int NONE_ASSETS = 1030;

/**
* Begin requesting input data; tells the client to
* start the database query, get a cursor, etc.
* @param requestType
*    IDataExtract.INSERT_ASSETS,
*    IDataExtract.VOID_ASSETS,
*    IDataExtract.UPDATE_ASSETS
* @param sliceOrNot  true/false
* true - if data will be requested in batches
* false - data will be requested all in one attempt
* @param sliceSize  >0 number of rows to be
* retrieved in one data set
* @return none
* @exception java.lang.Exception
*/

public void InitRequestInputData(int requestType,
boolean sliceOrNot, int sliceSize) throws Exception ;

/**
* Get a set/slice of input data records.
* @param dataSlice object to be populated using the
* methods from IPopulateDataSlice
* @return IDataExtract.HAS_DATA when dataSlice has some data,
*    IDataExtract.NO_DATA when there is no data,
*    IDataExtract.ERROR when there is an error
* @exception java.lang.Exception
*/

public int  GetNextInputDataSet(IPopulateDataSlice dataSlice)
throws Exception;

/**
* Signal the end of extracting data for given request type
* @param requestType
*    IDataExtract.INSERT_ASSETS,
*    IDataExtract.VOID_ASSETS,
*    IDataExtract.UPDATE_ASSETS
* @return none
* @exception java.lang.Exception
*/

public void EndRequestInputData(int requestType)
throws Exception;

/**
* Update the client as to what happened to input data
* processing. Note that this method would be called by multiple
* threads, with each thread passing its own IFeedback
* handle. The implementor of this method should write
* thread-safe code.
* @param requestType
*    IDataExtract.InsertAsset,
*    IDataExtract.VoidAsset,
*    IDataExtract.UpdateAsset
* @param processingStatus - An object containing processing
* status for all items in one dataset. The implementor of this
* interface should invoke the IFeedback interface
* methods on processingStatus to get status for individual
* rows. This method will be invoked by multiple BulkLoader
* threads, so make sure this method is implemented in a
* thread-safe way.
* @return none
* @exception java.lang.Exception
*/

void UpdateStatus(int requestType, IFeedback  processingStatus)
throws Exception;
}

IDataExtractの実装上の注意点

IDataExtractを実装するJavaオブジェクトには、文字列パラメータのあるコンストラクタが指定されている必要があります。BulkLoaderは、このオブジェクトをインスタンス化するときに、構成ファイルの名前をコンストラクタに渡します。

メソッドUpdateStatus(..)は複数のBulkLoaderスレッドによって呼び出されるため、このメソッドの実装はスレッド・セーフである必要があります。

表44-2に、カスタム・データ抽出メソッドの使用時におけるBulkLoaderユーティリティの構成パラメータを一覧表示して説明します。

表44-2 BulkLoaderの構成パラメータ

プロパティ名

必須/オプション

コメント

maxThreads

必須

同時処理スレッドの最大数。これは、WebCenter Sitesデータベース・サーバーへのデータベース接続数でもかまいません。データベース・ホスト上のCPU数に相当するスレッド数を使用します。CPUデータベース・ホストが1つの場合は、2に設定します。

例: 4

dataSliceSize

必須

1回の読取りリクエストで取得されるアイテム数。この数も1つの処理スレッドによって処理されます。

例: 2000

dataExtractionImplClass

必須

データ抽出APIに対応するユーザー固有の実装クラス。(String configFilename)シグネチャのあるコンストラクタが必要です。ここに示すものは、後方互換性のための参照実装クラスです。フラット表のデータ。

デフォルト値(使用準備済): com.openmarket.gatorbulk.objects.DataExtractImpl

initId

必須

開始WebCenter Sites IDを使用すると、最初のBulkLoaderが動作します。その後は、idSyncFileの値が使用されます。

例: 800000000000

idSyncFile

必須

次に使用可能なWebCenter Sites IDがこのファイルに保存されます。BulkLoaderのセッション中に更新されます。

例: C:\FutureTense\BulkLoaderId.txt

idPoolSize

必須

BulkLoaderがWebCenter Sites IDを生成する必要が生じるたびに、その数のIDが収集されてメモリーにキャッシュされます。(アセット数*属性の平均数*2)が、妥当な推定値です。

例: 1000

commitFrequency

必須

必須。

COMMIT文が生成済SQLファイルに挿入される時期を指定します。ゼロ値はCOMMIT文が50行ごとに挿入されることを意味し(デフォルト)、正の整数は各COMMIT文の間の行数を指定します。

例:

commitFrequency=5

(COMMIT文は、5行のSQLコードごとに挿入されます。)

outputJdbcDriver

必須

WebCenter SitesデータベースにアクセスするためのJDBCドライバ・クラスの名前。ここに示す値はOracle 9.0ドライバを反映しています。

例: oracle.jdbc.driver.OracleDriver

outputJdbcURL

必須

JDBC URL。次の例に示す値は、代表的なtype2 oracle JDBCドライバのURLです。

Jdbc:oracle:oci8:@foo

outputJdbcUsername

必須

WebCenter Sitesデータベースのユーザー名。

outputJdbcPassword

必須

WebCenter Sitesデータベースのユーザー・パスワード。

44.2.2 IPopulateDataSlice

次に、このインタフェースを実装するサンプル・コードを示します。

com.openmarket.gatorbulk.interfaces.IPopulateDataSlice

package com.openmarket.gatorbulk.interfaces;

import java.sql.Timestamp;

/**
* To be implemented by Oracle Corporation
* Interface to populate a dataSlice by the client.
* BulkLoader creates an object implementing this interface and then
* hands it over to the client, which uses this interface's methods
* to populate that object with input data records.
*/

public interface IPopulateDataSlice {

/**
* Creates a new input data object to hold all the data for a
* flex asset and makes it the current object. This method is
* invoked repetitively to populate this object with flex asset
* input data. Each invocation is to be followed by Set..()
* methods and AddAttribute..() methods to supply data for one
* flex asset.
*/

public void AddNewRow();

/**
* Specify a unique identifier for flex asset input data
* @param id  user-specific unique identifier
* @exception java.lang. Exception thrown if any unique-id
* validation is enabled.
*/

public voidSetAssetUniqueId(String id);

/**
* Specify the name of the site with which the current flex
* asset is created or to be created under.
* @param sitename  name of the site
*/

public void SetSiteName(String sitename);

/**
* Set the asset type for the flex asset.
* @param flexAssetType asset type as defined in WebCenter Sites system
*/

public void SetFlexAssetType(String flexAssetType);

/**
* Specify the name of the parent for the current flex asset.
* Use this method repeatedly to add a list of parent names.
* @param groupName  name of a parent that the current asset
* inherits some of its attributes from.
*/

public void AddParentGroup(String groupName);

/**
* Specify the name of the parent to be deleted for the current
* flex asset.
* Use this method repeatedly to add a list of parent names.
* @param groupName - name of a parent that the current asset
* inherited some of its attributes from.
*/

public void AddParentGroupForDelete(String groupName);

/**
* Specify definition asset name for the current flex asset.
* @param definitionAssetName name of the flex definition asset
*/

public void SetDefinitionAssetName(String definitionAssetName);

/**
* Specify name of the flex asset.
* @param name - name of the flex asset.Should be unique in
* a flex asset family
*/

public voidSetAssetName(String name);

/**
* Specify description for the flex asset
* @param description  description
*/

public void SetAssetDescripiton(String description);

/**
* Specify WebCenter Sites username with which this flex asset is being
* processed
* @param username WebCenter Sites username
*/

public void SetCreatedByUserName(String userName);

/**
* Set WebCenter Sites status code for this asset
* @param status
*/

public void SetAssetStatus(String status);

/**
* Set template name
* @param template  WebCenter Sites template name
*/

public void SetRenderTemplateName(String template);

/**
* Specify startMenu for workflow participation
* @param startMenuName  start menu name for this flex asset
*/

public void SetStartMenuName(String startMenuName);

/**
* WebCenter Sites
* Specify publish approval target name
* @param targetName  approval target name
*/

public void SetApprovalTargetName(String targetName);

/**
* Add a name/value pair to specify a WebCenter Sites attribute
* of type 'text' for the current input object.
* Call this method more than once, if this is a
* multi-valued attribute.
* @param attrName  attribute name as defined in the WebCenter Sites
* database for the flex asset being processed
* @param value java.lang.String
*/

public void AddAttributeValueString(String attrName, String value);

/**
* Add a name/value pair to specify a WebCenter Sites attribute
* of type 'date' for the current input object.
* Call this method more than once, if this is a
* multi-valued attribute.
* @param attrName  attribute name as defined in the WebCenter Sites
* database for the flex asset being processed
* @param value  java.sql.Timestamp
*/

public void AddAttributeValueDate(String attrName, Timestamp value);

/**
* Add a name/value pair to specify an attribute for the current
* input object.
* Call this method more than once, if this is a multi-valued *attribute
* @param attrName  attribute name as defined in WebCenter Sites database
* for the flex asset being processed
* @param value  java.lang.Double
*/

public void AddAttributeValueDouble(String attrName, Double value);

/**
* Add a name/value pair to specify a WebCenter Sites attribute
* of type 'money' for the current input object
* Call this method more than once if this is a
* multi-valued attribute
* @param attrName  attribute name as defined in WebCenter Sites database
* for the flex asset being processed
* @param value  java.lang.Float
*/

public void AddAttributeValueFloat(String attrName, Float value);

/**
* Add a name/value pair to specify a WebCenter Sites attribute
* of type 'int' for the current input object.
* Call this method more than once, if this is a
* multi-valued attribute.
* @param attrName  attribute name as defined in WebCenter Sites
* database for the flex asset being processed
* @param value  java.lang.Integer
*/

public void AddAttributeValueInteger(String attrName,
Integer value);

/**
* Add a name/value pair to specify any WebCenter Sites attribute for the
* current input object.
* Use the datatype-specific methods above instead of this
* method, as this one is for
* supporting any other new types in future.
* Call this method more than once, if this is a
* multi-valued attribute
* @param attrName  attribute name as defined in the WebCenter Sites
* database for the flex asset being processed.
* @param value  java.lang.Object
*/

public void AddAttributeValueObject(String attrName,
Object value);
}

44.2.3 IFeedbackインタフェース

次に、このインタフェースを実装するサンプル・コードを示します。

com.openmarket.gatorbulk.interfaces.IFeedback

package com.openmarket.gatorbulk.interfaces;

import java.util.Iterator;

/**
* To be implemented by Oracle Corporation
* Interface for the BulkLoader client to get the status of
* processing request to insert/void/update flex assets.
*/

public interface IFeedback {
public final int ERROR=-1;
public final int SUCCESS=0;
public final int NOT_PROCESSED=1;

/**
* Get a list of keys from input data slice that has
* been processed
* @return java.util.Iterator
*/

public Iterator GetInputDataKeyValList();

/**
* Get WebCenter Sites asset ID for given input identifier
* @param inputDataKeyVal key value of the unique identifier
* in the input data record
* @return Get the associated asset ID from the WebCenter Sites system.
* null if missing.
*/

public String GetWebCenter SitesAssetId(String inputDataKeyVal);

/**
* Get the processing status for the input data record
* identified by a key
* @param inputDataKeyVal key value of the unique identifier
* column in the input data record
* @return ERROR - processed but failed, SUCCESS - processed
* successfully, NOT_PROCESSED - unknown item or not part of
* the processing dataset.
*/

public int GetStatus(String inputDataKeyVal);

/**
* Get the associated error message for a given key,
* unique identifier in input data
* @param inputDataKeyVal  unique identifier for input data
* @return error message, if GetStatus() returned ERROR
* or NOT_PROCESSED
*/

public String GetErrorDescription(String inputDataKeyVal);

注意:

カスタム抽出メソッドを実装するときには、前に説明したBulkLoaderの実行手順と同じ手順を使用します。詳細は、「BulkLoaderユーティリティの使用について」を参照してください。

44.3 BulkApproverユーティリティによるフレックス・アセットの承認

BulkApproverは、BulkLoader経由でシステムにロードされた多数のフレックス・アセットを迅速かつ簡単に承認するユーティリティです。

BulkApproverは次のタスクを実行できます。

- 前のBulkLoaderセッションで行われたすべての更新と削除を承認システムに通知します。

- 1つ以上のパブリッシュ・ターゲットに対して新規にロードされたすべてのフレックス・アセットを承認します。

- 実際にアセットをパブリッシュすることなく、新規にロードされたすべてのフレックス・アセットを指定されたミラー定義に対してパブリッシュ済としてマークします。たとえば、長いミラー・パブリッシュ・セッションを迂回するには、選択したアセットをコンテンツ管理データベースから配信システム上のミラー宛先にコピーし、BulkApproverを使用してミラー宛先に対してアセットをパブリッシュ済とマークします。

注意:

xceladminロールが割り当てられているユーザーのみがBulkApproverを実行できます。

この項には次のトピックが含まれます:

- BulkApproverの構成

- BulkApproverの使用

44.3.1 BulkApproverの構成

BulkApproverを初めて実行する前に、このユーティリティ用の構成ファイルを作成する必要があります。WebCenter Sitesのデータベースにアクセスできるシステム上でBulkApprover.iniファイルを別途作成するか、BulkLoaderの.iniファイルの1つにBulkApproverの構成情報を追加できます。

表44-3に、必須およびオプションの構成パラメータを示します。

表44-3 BulkApproverの構成パラメータ

パラメータ

説明

bulkApprovalURL

(必須)

BulkLoaderでデータをインポートしたホスト・サーバー上のURL。

正確な値は次のようになります。

http://<myServer>/cs/ContentServer?pagename=OpenMarket/Xcelerate/Actions/BulkApproval

<myServer>は、ホスト・サーバーの名前です。

adminUserName

(必須)

xceladminロールが割り当てられているユーザーのWebCenter Sitesユーザー名。

adminUserPassword

(必須)

adminUserNameのパスワード。

approvalTargetList

(必須)

アセットの承認が必要な宛先のリスト。宛先名については、「管理」タブの「パブリッシュ」オプション、またはpubtarget表の名前列を参照してください。それぞれの宛先を、multiValueDelimiterパラメータに指定したデリミタで区切ります。構文は次のとおりです。

name1<multiValueDelimiter>name2<multiValueDelimiter>name3

multiValueDelimiter (必須)

選択したデリミタ。このデリミタを使用して、appovalTargetListパラメータに指定した承認ターゲットを区切ります。

assetIdSqlFilter

(オプション)

アセットIDをフィルタするためにSQLのWHERE句に追加できる文。

例:

asset_id%20=0

または

asset_id%20!=0

debug

(オプション)

BulkApproverのデバッグをオンおよびオフにします。

値trueはデバッグをオンにします。デバッグを行わない場合は、このパラメータを空白にします。

デバッグ・メッセージは、コマンドラインのoutput_fileパラメータに指定したファイルに書き込まれます。

assetschunksize

(オプション)

1回のトランザクションで承認されるアセットの数を指定します。たとえば、このプロパティを20に設定すると、アセットは20のグループで承認されることになります。

このプロパティを設定すると、セッションのタイムアウトが回避されます。

デフォルト値: 25

outputJdbcDriver

(必須)

WebCenter SitesデータベースにアクセスするためのJDBCドライバ・クラスの名前。

例: oracle.jdbc.driver.OracleDriver

outputJdbcURL

(必須)

JDBC URL。次の例に示す値は、代表的なtype 2 oracle JDBCドライバのURLです。

Jdbc:oracle:oci8:@foo

outputJdbcUsername

(必須)

WebCenter Sitesデータベースのユーザー名。

outputJdbcPassword

(必須)

WebCenter Sitesデータベースのユーザー・パスワード。

BulkApprover.iniファイルの例

次のサンプルは、BulkApprover構成パラメータの正しい構文を示したものです。

bulkApprovalURL=http://MyServer/cs/ContentServer?pagename=OpenMarket/Xcelerate/Actions/BulkApproval
multiValueDelimiter=;;;;;;
assetIdSqlFilter=
assetsChunkSize=3
debug=true
outputJdbcDriver=oracle.jdbc.driver.OracleDriver
outputJdbcURL=jdbc:oracle:thin:@19zln:1521:MyServer
#outputJdbcUsername=izod10
outputJdbcUsername=ftuser3
outputJdbcPassword=ftuser3

44.3.2 BulkApproverの使用

BulkApproverユーティリティの構成後にこれを使用して、BulkLoaderユーティリティ経由でデータベースにインポートされたアセットを承認します。

BulkApproverは、コマンドラインから実行します。パラメータについては表44-4で説明します。これらのパラメータは次の例に含まれています。

表44-4 BulkApproverパラメータ

コマンドライン・パラメータ

説明

config

BulkApprover構成情報を格納するファイルの名前(例: BulkApprover.ini)。

action

BulkApproverで実行するアクション。このパラメータはnotifyまたはapproveに設定する必要があります。必要に応じて、他のアクションを追加します。BulkApproverで複数のアクションを実行するには、カンマ区切りリストにアクション名を指定します。

有効な値:

- notify: 前のBulkLoaderセッションで処理されたすべての更新と無効化を承認システムに通知します。

- approve: 指定されたパブリッシュの宛先に対して処理したすべてのアセットを承認するよう、BulkApproverに指示します。

- mark_publish: 実際にアセットをパブリッシュすることなく、処理したすべてのアセットを指定されたミラー宛先に対してパブリッシュ済としてマークします。BulkApprover構成ファイル内のapprovalTargetListパラメータでパブリッシュ・ターゲットを指定します(「BulkApproverの構成」を参照)。アセットをパブリッシュ済としてマークしない場合は、このパラメータを含めないでください。

output_file

サーバーからのすべての出力が含まれているログ・ファイルの名前(例: bulkapprover.txt)。

BulkApproverを実行するには、次の例に示すようにパスを設定します。

次の例では、Windowsの構文を使用します。LinuxおよびSolarisを含むUNIXベースのシステムの場合は、区切り用としてスラッシュ(/)およびコロン(:)を使用します。

java -ms16m -mx64m -cp <ORACLE_HOME>\wcsites\webcentersites\sites-home\lib\*;<ORACLE_HOME>\oracle_common\modules\clients\*;<path to jtds-1.2.2.jar>\jtds-1.2.2.jar;<path to servlet-api.jar>\servlet-api.jar; com.openmarket.gatorbulk.objects.BulkApprover config=bulkapprover.ini action=<notify|approve|mark_publish> output_file=<out.txt>  target_list=Dynamic;;;;;;testdest username=<adminUserName(fwadmin)> password=<adminUserPassword(xceladmin)>

第VIII部 セキュリティ: コンテンツ管理ユーザーの管理

次の項では、ユーザーを管理するためのユーザー管理メカニズムとセキュリティ・メカニズムについて説明します。

- 管理システムのユーザーの管理

45 管理システムのユーザーの管理

WebCenter Sitesでは、USERタグによる認証機能、DIRタグによるユーザー・プロファイル管理が用意されており、アクセス制御リスト(ACL)によりデータベース表およびレンダリングされたページのセキュリティが強化されています。これらのユーザー管理とセキュリティのメカニズムを使用して、ユーザーを管理し、配信システムおよびWebCenter Sitesの開発システムと管理システムに対するユーザーのアクセスを制御します。

管理システムでのユーザーの管理の詳細は、次の項を参照してください。

- ディレクトリ・サービスAPIについて

- ユーザー・アクセスの制御

45.1 ディレクトリ・サービスAPIについて

ディレクトリ・サービスAPIは、WebCenter Sitesシステムで認証情報、ユーザー情報などが格納されているディレクトリ・サーバーへの接続を有効化します。

WebCenter Sitesは3つのディレクトリ・サービスのプラグインを配信しており、そのうちの1つはWebCenter Sitesシステムとともにインストールされます。

- WebCenter Sitesディレクトリ・サービス・プラグイン: ネイティブのWebCenter Sitesユーザー管理表(SystemUsers表およびSystemUserAttrs表)を使用します。

- LDAPプラグイン: 任意のJNDIサーバーをサポートします。

- NTプラグイン: ユーザー資格証明とログイン名はNTディレクトリから取得しますが、その他のすべてのユーザー情報はSystemUserAttrs表から取得します。

プラグインはWebCenter Sitesシステムのインストール時にインストールされ、構成するにはwcs_properties.jsonファイルでプロパティを設定します。ユーザー管理との構成の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

この項には次のトピックが含まれます:

- エントリ

- 階層

- グループ

- ディレクトリ・サービス・タグ

- ディレクトリの操作

- エラー処理

- ディレクトリ・サービス・アプリケーションのトラブルシューティング

45.1.1 エントリ

ディレクトリのエントリは、割り当てられた属性(特にユーザーおよびグループ・タイプのエントリ)を備えた名前付きオブジェクトです。

- ユーザー・タイプ・オブジェクトには、識別名および一連の属性として一般名、ユーザー名、パスワード、電子メールなどが備わっています。

- WebCenter Sites ACLと同様、グループ・タイプ・オブジェクトにも識別名と一連の属性があります。

名前には、名前が関連付けられた階層が反映されます。ディレクトリ実装での移植性を確保するために、名前は不透明な文字列として処理する必要があります。

45.1.2 階層

一部のディレクトリ・データベースは、階層構造を使用してエントリを編成します。WebCenter Sitesのディレクトリ・サービスAPIでは、エントリの属性と階層内でのその場所は個別になっています。その結果、エントリの属性の取得によってその子の情報は発生しません。

階層に対するサポートは、基礎となるディレクトリの実装に応じて異なります。たとえば、LDAPディレクトリは階層構造をサポートしますが、WebCenter Sitesのネイティブ・ディレクトリ・データベースは階層構造をサポートしません。ディレクトリ実装での移植性を確保するために、コードは階層データのサポートを想定していません。

注意:

グループ階層は、内部のWebCenter Sitesの権限に影響を及ぼしません。

45.1.3 グループ

WebCenter Sitesのディレクトリ・サービスAPIは、参照整合性を実行しません。ディレクトリ・タグを持つユーザーを削除する場合は最初に、ユーザーが関連付けられているグループからユーザーを削除します。これにより、グループのメンバーシップも削除されるようにします。

メンバーがグループに追加されるたびに、JNDI実装では、addmemberタグに渡される名前とは関係なく、uniquemember属性の値に対して完全に識別される名前が作成されます。

45.1.4 ディレクトリ・サービス・タグ

表45-1に示すように、DIRタグ・ファミリをXMLおよびJSPの両バージョンで使用して、ディレクトリ・サービスAPIを起動できます。

表45-1 ディレクトリ・サービス・タグ

タグ

説明

DIR.ADDATTRS

dir:addattrs

属性を既存のエントリ(ユーザーまたはグループのいずれか)に追加します。

DIR.ADDGROUPMEMBER

dir:addgroupmember

メンバーをグループ(通常はユーザー)に追加します。

DIR.CHILDREN

dir:children

リスト変数の特定の親に対する子エントリを取得します。

DIR.CREATE

dir:create

ディレクトリ・エントリを作成します。

DIR.DELETE

dir:delete

ディレクトリ・エントリを削除します。

DIR.GETATTRS

dir:getattrs

リスト変数の特定のエントリに対する属性値を取得します。

DIR.GROUPMEMBERS

dir:groupmembers

指定されたグループのメンバーのリストを作成します。

DIR.GROUPMEMBERSHIPS

dir:groupmemberships

エントリ(グループまたはユーザーのいずれか)が属するすべてのグループのリストを作成します。

DIR.LISTUSERS

dir:listusers

ディレクトリ内のすべてのユーザーのリストを返します。

DIR.REMOVEATTRS

dir:removeattrs

エントリの属性値を削除します。

DIR.REMOVEGROUPMEMBER

dir:removegroupmember

グループのエントリを削除します。

DIR.REPLACEATTRS

dir.replaceattrs

エントリ(ユーザーまたはグループのいずれか)の属性値を置換します。

DIR.SEARCH

dir:search

指定された検索基準と一致するエントリのディレクトリを検索します。

ディレクトリがLDAP、WebCenter Sitesのみのいずれを使用して実装しているかに関係なく、DIRタグで記述するコードは酷似しています。

これらのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。コード・サンプルは、「ディレクトリ・サービスのコード・サンプル」を参照してください。

45.1.5 ディレクトリの操作

一部のWebCenter Sitesディレクトリ・サービスのタグは、データベースに情報を書き込みます。データベース管理者が、データベースへのユーザー情報の追加など、Webサイトへの書込み操作をすべて処理している場合、ディレクトリ・タグの使用を読取り専用の操作に制限します。このポリシーによって、サードバーティのディレクトリ管理ツールとの同期化に関する問題が回避されます。

読取り専用操作については、この項で説明します。現在の認証済ユーザーの資格証明と読取り権限を使用して、これらの操作を実行します。

この項には次のトピックが含まれます:

- 検索

- ユーザーの検索

- ユーザーのリスト作成

- ディレクトリ・サービスのコード・サンプル

45.1.5.1 検索

一部のディレクトリ・サーバーの制限のため、組織の最上位レベルからの検索は許可されていません。移植性の問題を回避するために、DIR.SEARCHタグのコンテキスト属性を必ず指定してください。

45.1.5.2 ユーザーの検索

ユーザーのルックアップには、通常、次の2つの手順を実行します。

1. エントリ名を取得するには、useridのDIR.SEARCHをコールします。

2. 問題のユーザーの属性を取得するには、DIR.GETATTRSをコールします。

45.1.5.3 ユーザーのリスト作成

ユーザーのリストを作成するには、次の3つの方法のいずれかを使用することをお薦めします。

- 小規模のユーザー・データベースの場合、DIR.LISTUSERSタグを使用します。これは、peopleParentプロパティに従ってすべてのユーザーのリストを再帰的に作成します。このタグの使用は、より大規模なユーザー・データベースでは非効率的です。

- より大規模なユーザー・データベースの場合、階層の移動にはDIR.CHILDRENタグを使用します。DIR.CHILDRENタグはグループ・タイプには最適ですが、ユーザー・タイプには適していません。

- フラットな階層を持つユーザー・データベースの場合、検索結果を絞り込みます。

45.1.5.4 ディレクトリ・サービスのコード・サンプル

次のJSPコード・サンプルは、可能なディレクトリ操作を示しています。

<%
String sMainTestUserName = "user name";
String sMainTestUserPW="password";

String sPeopleParent = ics.GetProperty("peopleparent", "dir.ini", true);
String sGroupParent = ics.GetProperty("groupparent", "dir.ini", true);
String sUsername = ics.GetProperty("username", "dir.ini", true);
String sCommonName = ics.GetProperty("cn", "dir.ini", true);
IList mylist;
%>

<user:su username='<%=sMainTestUserName%>' password='<%=sMainTestUserPW%>'>

<H2>List All Users</H2>

<ics:clearerrno/>
<dir:listusers list='mylist'/>
<br>
<b>dir:listusers errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist'>
<br><ics:listget listname='mylist' fieldname='NAME'/>
</ics:listloop>

<H2>Look Up the ContentServer User by Username</H2>

<ics:clearerrno/>
<dir:search list='mylist' context='<%=sPeopleParent%>'>
<dir:argument name='<%=sUsername%>' value='ContentServer'/>
</dir:search>
<br><b>dir:search errno: <ics:getvar name='errno'/></b>

<%
mylist = ics.GetList("mylist");
if(mylist.numRows() != 1) {
out.print("<br>Error finding entry.");
}
mylist.moveTo(1);
ics.SetVar("ContentServerDn", mylist.getValue("NAME"));
%>

<H2>Show ContentServer Attributes</H2>

<ics:clearerrno/>
<dir:getattrs list='mylist'
name='<%=ics.GetVar("ContentServerDn")%>'/>
<br><b>dir:getattrs errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist'>
<br>
<ics:listget listname='mylist' fieldname='NAME'/>=
<ics:listget listname='mylist' fieldname='VALUE'/>
</ics:listloop>

<H2>Show Group Memberships for ContentServer</H2>

<ics:clearerrno/>
<dir:groupmemberships name='<%=ics.GetVar("ContentServerDn")%>'
list='mylist'/>
<br><b>dir:groupmemberships errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist'>
<br>
<ics:listget listname='mylist' fieldname='NAME'/>
</ics:listloop>

<H2>Lookup the SiteGod Group by CommonName</H2>

<ics:clearerrno/>
<dir:search list='mylist' context='<%=sGroupParent%>'>
<dir:argument name='<%=sCommonName%>' value='SiteGod'/>
</dir:search>
<br><b>dir:search errno: <ics:getvar name='errno'/></b>

<%
mylist = ics.GetList("mylist");
if(mylist.numRows() != 1) {
out.print("<br>Error finding entry.");
}
mylist.moveTo(1);
ics.SetVar("SiteGodDn", mylist.getValue("NAME"));
%>

<H2>Show SiteGod Attributes</H2>

<ics:clearerrno/>
<dir:getattrs list='mylist' name='<%=ics.GetVar("SiteGodDn")%>'/>
<br>
<b>dir:getattrs errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist'>
<br>
<ics:listget listname='mylist' fieldname='NAME'/>=
<ics:listget listname='mylist' fieldname='VALUE'/>
</ics:listloop>

<H2>Show SiteGod Group Members</H2>

<ics:clearerrno/>
<dir:groupmembers name='<%=ics.GetVar("SiteGodDn")%>' list='mylist2'/>
<br>
<b>dir:groupmembers errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist2'>
<br>
<ics:listget listname='mylist2' fieldname='NAME'/>
</ics:listloop>

<H2>Children of groupparent </H2>

<ics:clearerrno/>
<dir:children name='<%=sGroupParent%>' list='mylist'/>
<br>
<b>dir:children errno: <ics:getvar name='errno'/></b>
<ics:listloop listname='mylist'>
<br>
<ics:listget listname='mylist' fieldname='NAME'/>
</ics:listloop>

</user:su>

45.1.6 エラー処理

どのディレクトリ・タグでも、設定時に様々なディレクトリ・エラーが発生する可能性があります。ディレクトリ・サービスのエラー・メッセージの包括的なリストは、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

ディレクトリ・サービスのコードによって、指定されたタグ・コールでリストされたそれぞれのエラー・コードが処理される必要があります。これは、J2EE JNDIインタフェースをサポートするために必要です。

45.1.7 ディレクトリ・サービス・アプリケーションのトラブルシューティング

ディレクトリ・サービス・アプリケーションのトラブルシューティングの最初の手順は、エラー・ログ(WebCenter Sitesのログ・ファイル内の)のチェックです。

ディレクトリ・サービスのロギングを有効にするには、log.filterLevelプロパティ(logging.iniプロパティ・ファイル内にある)を設定します。次のように、7レベルのエラー・メッセージがあります。

- fatal: 致命的なレベルのメッセージを記録します。

- severe: 重度および致命的なレベルのメッセージを記録します。

- error: エラーおよび致命的なレベルのメッセージを記録します。

- warning: 警告および致命的なレベルのメッセージを記録します。

- info: 警告、エラー、重度および致命的なレベルのメッセージを記録します。

- trace: トレース・メッセージを記録します。

- 詳細: すべてのタイプのメッセージを記録します。

トラブルシューティング時には、traceが最も詳細な設定であり、そのためパフォーマンスへの影響は最も高くなります。

ディレクトリ・サービスは、エントリの使用を次の書式で記録します。

[<timestamp>][Directory-<severity>-<errno>]
[<class>:<method>][<message>][<session id>]

次に例を示します。

[Jan 17, 2002 1:49:44 PM][Directory-T]
[BaseFactory:instantiateImplementation(ICS,String,Class[],
Object[])][Instantiating:com.openmarket.directory.common.Factory]
[PEccxyF1Ueh7zYvjNgg4D6bqZzf0llfWMaiBimIN9H1Z9KomDcPy]

前のメッセージはトレース(T)であるため、関連付けられたerrno値はありません。

エラー・ロギングの詳細は、「エラーのロギングおよびデバッグ」を参照してください。

LDAP実装の共通の問題は、ディレクトリ・サーバーで誤って指定される権限です。エラー・ログが権限問題を示している場合には、ディレクトリ・サーバーの権限の設定をチェックして、認証されたユーザーがリクエストされた操作を実行する権限を持っていることを確認します。ディレクトリ・サーバーに直接ログインして(WebCenter Sites外)、権限が正しく設定されていることを確認するために同じアクションを実行します。ログと権限をチェックした後は、プロパティ・ファイルを調べることで、多くの場合構成エラーを解決できます。

プロパティの説明および値については、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

45.2 ユーザー・アクセスの制御

WebCenter Sitesは、アクセス制御リスト(ACL)でユーザーを管理します。ACLを使用すると、WebCenter Sitesデータベース内の表と、WebCenter Sitesによりサイトで処理したレンダリング済ページへのアクセスを制限できます。ユーザーがユーザー名およびパスワードを使用してログインするサイトの1つ以上のACLに登録済ユーザーを関連付ける必要があります。

ユーザーが最初にサイトを訪れると、WebCenter Sitesではセッションが作成され、そのユーザーは標準デフォルト・ユーザーDefaultReaderとして暗黙的にログインされます。USER.LOGINコマンドが使用されてユーザーがパスワードで認証されると、ユーザーのIDが更新されます(関連付けられたACLが有効になります)。

この項には次のトピックが含まれます:

- ACLタグ

- USERタグ

- WebCenter Sitesおよび暗号化

45.2.1 ACLタグ

WebCenter Sitesには、ACLの作成に使用できる一連のアクセス制御リストのタグ(XMLおよびJSPの両バージョン)が用意されています。管理システムのWebCenter SitesインタフェースかWebCenter Sites ACLタグのいずれかを使用して、管理システムのユーザー・アカウントで必要なACLを作成できます。表45-2は、ACLタグのリストです。

表45-2 ACLタグ

タグ

説明

ACL.CREATE acl: create

ACLを作成します。

ACL.DELETE acl:delete

ACLを削除します

ACL.GATHER acl:gather

ACLにフィールドを収集します

ACL.GET acl:get

ACLからフィールドをコピーします

ACL.LIST acl:list

ACLのリストを取得します

ACL.LOAD acl:load

ACLをロードします。

ACL.SAVE acl:save

ACLを保存します。

ACL.SCATTER acl:scatter

ACLからフィールドを散布します

ACL.SET acl:set

ACL内のフィールドを設定します

関連項目:

- ACLタグ: Oracle WebCenter Sitesタグ・リファレンスを参照してください。

- 一般的なACL: 『Oracle WebCenter Sitesの管理』を参照してください。

45.2.2 USERタグ

WebCenter Sitesでは、表45-3で説明するUSERタグ(XMLおよびJSPの両バージョン)タグも用意されています。これらのタグは、ユーザーをログインおよびログアウトさせるページ上で使用します。

表45-3 ユーザー・タグ

タグ

説明

USER.LOGIN

user:login

ユーザーをログインさせます。

USER.LOGOUT

user:logout

ユーザーをログアウトさせます。

USER.SU

user:su

アカウント作成、ユーザー・プロファイルの編集などの操作を実行するために、特定のユーザーとしてユーザーをログインさせます。

これらのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

45.2.3 WebCenter Sitesおよび暗号化

WebCenter Sitesには、パスワードやその他の機密関係の情報を暗号化するデフォルト・キーが用意されています。独自の暗号化キーを指定するには、UtilitiesクラスのencryptStringメソッドを使用します。暗号化を処理するJavaメソッドの情報は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

また、WebCenter SitesではSecure Sockets Layer (SSL)もサポートされており、これによってWebサーバーを出入りする情報の暗号化が許可されます。WebCenter SitesおよびSSLの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

第IX部 サイトのパブリッシュ

次の項では、WebCenter Sitesに用意されているパブリッシュ方法について説明します。

- コンテンツ管理サイトをオンラインで使用可能にするためのパブリッシュ

46 コンテンツ管理サイトをオンラインで使用可能にするためのパブリッシュ

パブリッシュ・システムは、サイトおよびそのコンテンツをシステムから別のシステムに移行する手段を提供します。WebCenter Sitesには、リアルタイム、サーバーへのミラーリング、ディスクへのエクスポート、およびXMLへのエクスポートというパブリッシュ方法が用意されています。サイトの構造(つまり、データベース・スキーマ)は、サーバーへのミラーリングまたはリアルタイムのいずれかのパブリッシュ方法で移行されます。コンテンツ自体は、管理者の裁量でパブリッシュできます。

様々なパブリッシュの使用方法の詳細は、『Oracle WebCenter Sitesの管理』の次の項を参照してください。

- Oracle WebCenter Sitesを使用したパブリッシュ

- ディスクへのエクスポートのパブリッシュ・プロセス

- サーバーへのミラーリングのパブリッシュ・プロセス

- XMLへのアセットのエクスポートのパブリッシュ・プロセス

- リアルタイム・パブリッシュ・プロセスの構成

- リアルタイム・パブリッシュ・モードの使用

第X部 Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発

この部では、最初に、サイト訪問者のセグメントへのグループ化を可能にする、訪問者のデータ・アセットの作成について説明します。次に、製品アセットとコンテンツ・アセットの収集、評価およびソート後に、最も適切なフレックス・アセットを推奨する、推奨アセットの設定方法について説明します。また、メモリー中心の訪問者追跡について説明するほか、このメソッドの実装に必要な条件を概説します。最後に、訪問者情報を収集して、訪問者ごとの販促用メッセージをパーソナライズするオンライン・サイトの設計について説明します。

Engageでのパーソナライズおよびターゲット設定されたWebサイトの開発の詳細は、次の項を参照してください。

- 訪問者データ・アセットの作成

- 推奨アセットの理解

- メモリー中心の訪問者追跡の使用

- Engageページのコーディング

47 訪問者データ・アセットの作成

Oracle WebCenter Sites: Engageを使用すると、サイトの訪問者および顧客に関する情報を収集するオンライン・サイトを設計し、その情報を使用して、表示する製品の配置や販促用の提供品を訪問者別にパーソナライズできます。訪問者に関する情報は、訪問者データ・アセットに格納されます。訪問者データ・アセットには、訪問者属性、履歴属性および履歴タイプの3種類があります。WebCenter Sitesデータベースでは、訪問者データのタイプの定義をアセットとして扱います。

訪問者データ・アセットの作成の詳細は、次の項を参照してください。

- 訪問者データ・アセットについて

- 訪問者データ・アセットの作成

- 訪問者データ・アセットの確認

- 訪問者データ・アセットの承認

47.1 訪問者データ・アセットについて

訪問者データ・アセットを作成すると、そのアセットを使用してサイト訪問者をセグメントにグループ化できます。これには次の3種類があります。

- 訪問者属性

- 履歴属性

- 履歴タイプ

訪問者データ・アセットを作成するには、WebCenter Sitesデータベース内の訪問者データ表にエントリを作成し、該当するサイト訪問者に関する情報を格納する場所をデータベース内に確保します。

この項には次のトピックが含まれます:

- 訪問者属性

- 履歴属性と履歴定義

- セグメント

- 訪問者データ・アセットの開発: プロセスの概要

47.1.1 訪問者属性

訪問者属性には、1つの特性のみ(スカラー値)を指定する情報のタイプが保持されます。たとえば、経験年数、職務内容、子供の数のような名前の訪問者属性を作成できます。

訪問者がデータを変更すると、新しいデータによって以前のデータが上書きされます。Engageでは、訪問者属性として格納されたデータおよびリビジョンを格納していないデータにはタイムスタンプが割り当てられません。たとえば、訪問者の職務内容のエントリが肉屋からパン屋に変更された場合、肉屋であった以前の訪問者情報は上書きされます。「かつて肉屋であったパン屋」に基づくセグメントを作成することはできません。

履歴データには、履歴タイプを使用する必要があります。

47.1.2 履歴属性と履歴定義

履歴属性は、Engageで単一レコードとして扱われる情報のベクターを作成するためにグループ化した個々の情報タイプです。このレコードが、履歴定義です。たとえば、購買という履歴定義は、SKU、アイテム名、数量および価格という履歴属性で構成できます。

Engageでは、履歴定義として格納されているデータを全体または集約として参照します。記録済定義の各インスタンスにタイムスタンプを割り当て、それらの各レコードを保持します。つまり、履歴定義を合計または計数でき、訪問者に関して履歴定義が記録された最初の時刻または最終時刻を判別できます。前の段落の例を使用すると、訪問者が設定された一定期間に特定のアイテムに費やした金額の合計に基づいてセグメントを作成できます。

履歴定義には履歴データが格納されます。

47.1.3 セグメント

セグメントは、共通の特徴に基づいて訪問者をグループ分けするアセットです。セグメントを作成するには、セグメントのベースとなる訪問者データ・アセットを決定し、その基準の条件を満たす値を設定します。

訪問者データ・アセットを作成するには、次の2つの場所で使用できるフィールドを作成します。

- セグメントの基準として。つまり、Engageのセグメント・フィルタ・フォームの構成オプションとして使用します(訪問者データ・アセットを使用してセグメントを定義するため)。言い換えると、属性のデータ型に関する選択結果によって、セグメント・フォームでの外観や動作が決定されます。これらのアセットを作成すると、セグメント・フォームがカスタマイズされます。

- 一般のサイト・ページで。つまり、登録ページやその他のページのフォーム・フィールドまたは非表示のフィールドとして使用します。

セグメントは、Engageで販促用メッセージをパーソナライズする際のキーとなります。訪問者がサイトを参照すると、訪問者の送信情報を使用して、訪問者をセグメントのメンバーに認定します。サイトで推奨やプロモーションを含むページを開く場合は、Engageによって訪問者が属するセグメントが決定され、そのセグメント向けの製品の推奨または販売促進メッセージが開きます。

47.1.4 訪問者データ・アセットの開発: プロセスの概要

訪問者データ・アセット(フィールド)の作成および使用には、一般的に次の5つの手順があります。

1. 開発者およびマーケティング担当者で構成されるクロスファンクショナルな設計チームによって、サイト訪問者について収集するデータの種類が決定されます。

2. 開発者は、Engage内のフォームを使用して、必要な訪問者属性、履歴属性および履歴定義を作成および定義します。

3. マーケティング担当者は、Engage内のセグメント・フィルタ・フォームを使用して、訪問者属性、履歴属性および履歴定義をベースに訪問者のグループを編成します。

4. 開発者は、EngageのXMLまたはJSPオブジェクト・メソッドを使用して適切なサイト・ページをプログラムし、データの収集と格納を行い、サーバー側の検証またはJavascriptのいずれかを使用してページ上の入力を検証します。たとえば、JavaScriptを使用して、入力を検証する訪問者入力用のオンライン登録フォームを作成し、EngageのXMLまたはJSPタグを使用して、その情報を処理およびWebCenter Sitesデータベースに格納できます。

5. 訪問者がサイトを参照すると、訪問者の送信情報を使用して、訪問者をセグメントのメンバーに認定します。サイトでセグメントに基づいてプロモーションと推奨を使用している場合、訪問者に表示されるメッセージは、訪問者が所属するセグメントに基づいてパーソナライズされます。

47.2 訪問者データ・アセットの作成

訪問者データ・アセットの作成を始める前に、次のタスクが完了していることを確認します。

- マーケティング・チームや設計チームと話し合い、訪問者について収集するデータの種類を決定します。

- セグメント・フィルタ・フォームを調べて、作成する訪問者データ・アセットをマーケティング担当者が使用する背景を理解しておきます。さらに、訪問者データ・アセットは、セグメント・フィルタ・フォーム内の名前ではなく、説明を基準としてリストされることに注意してください。

訪問者属性および履歴属性の定義には、次のデータ定義を使用できます。

- string: 255文字まで保持できます。

- boolean: trueおよびfalseのみが有効な値です。

- short: 0から255までが有効な値の範囲です。

- integer: 0から65,535までが有効な値の範囲です。

- long: 0から65,535までが有効な値の範囲です。

- double: 0から4,294,967,295までが有効な値の範囲です。

- date: 形式はyyyy-mm-dd hh:mm:ss.sです。

- money: 形式は通貨で、有効な値の範囲に制限はありません。

- binary: 訪問者属性のみで、イメージ・ファイルまたはカート・オブジェクトなどのバイナリ・データに使用されます。

注意:

バイナリ訪問者属性では、個々の訪問者のバイナリ・データを記録できます。このタイプの訪問者属性は、セグメント・フィルタ・フォームでは表示されないほか、セグメントの定義にも使用できません。WebCenter Sitesネームスペースのオブジェクトをバイナリ・フォームに変換するXMLオブジェクト・メソッドのVDM.SAVESCALAROBJECTまたはJSPオブジェクト・メソッドのvdm:savescalarobjectを使用して、バイナリ・タイプの属性を作成することで、オブジェクトの格納に使用するWebCenter Sitesデータベースの容量が確保されます。

この項には次のトピックが含まれます:

- 訪問者属性の作成

- 履歴属性の作成

- 履歴定義の作成

47.2.1 訪問者属性の作成

Engageフォームを使用して訪問者属性を作成します。

新しいビジター属性を作成するには:

1. Adminインタフェースを開きます。

2. ボタン・バーで「新規」をクリックします。

3. アセット・タイプのリストから、新規訪問者属性を選択します。(サイト訪問者属性のアセット・タイプは、サイトに対して有効にする必要があります。)

サイト訪問者属性フォーム(図47-1)が開きます。

図47-1 サイト訪問者属性

注意:

ログイン/パスワードの組合せに管理者権限がない場合、訪問者属性はメニューに表示されません。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

4. 「名前」フィールドで、属性(フィールド)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字である必要があります。

5. 「説明」フィールドで、属性(フィールド)の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(属性は、セグメント・フィルタ・フォーム内の名前ではなく、この説明によってリストされます)。

6. 「カテゴリ」フィールドで、属性のカテゴリを入力します。このフィールドに入力するテキストによって、セグメント・フィルタ・フォームで属性がリストされる場所が決定されます。最大32文字の英数字を入力できます。

注意:

訪問者属性のカテゴリは、履歴定義のカテゴリとは別にする必要があります。

47.2.1.1 データ型の構成

データ型を構成するには:

1. 「タイプ」ドロップダウン・リストから、データ型を選択します。

2. 「string」を選択した場合は、「長さ」フィールドで、その属性(フィールド)に入力可能な最大の文字数を入力します。255までの値を入力できます。

3. 「NULL値を許可」ドロップダウン・リストから、「true」を選択するとNULL値が許可され、「false」を選択すると属性の入力が使用時に要求されます。たとえば、booleanデータ型の属性はNULL値を許可できません。

4. 「NULL値を許可」ドロップダウン・リストで「false」を選択した場合は、「デフォルト値」フィールドで、その属性のデータ型に適合するデフォルト値を入力します。たとえば、integerデータ型の場合は、デフォルト値を数値にする必要があります。

注意:

データ型に「binary」を選択した場合、その属性のデフォルト値は指定できません。

47.2.1.2 制約基準の構成

属性への入力の検証に使用可能な制約オプションは、その属性に指定したデータ型によって異なります。

オプション1: フリーフォーム・テキストを受け入れる属性の構成

「制約タイプ」ドロップダウン・リストから、「なし」を選択します。たとえば、string型のresidenceという訪問者属性で、制約のないテキストを入力として受け入れる場合があります。

オプション2: 値の範囲から入力を受け入れる属性の構成

特定の値の範囲を受け入れる属性を構成するには、データ型をinteger、short、long、doubleまたはmoneyにする必要があります。

1. 「制約タイプ」ドロップダウン・リストから、「範囲」を選択します。
フォームに「範囲」フィールドが表示されます。

2. 「下限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最小値を指定します。この値を負の数値にはできません。

3. 「上限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最大値を入力します。(データ型がshortでは255まで、integerでは65,535まで、doubleでは4,294,967,295まで、moneyでは無制限に値を入力できます。)
たとえば、Ageという名前の属性で、1から110の間の値のみを受け入れるように制限できます。

オプション3: ドロップダウン・リストに値のリストを提供する属性の構成

1. 「制約タイプ」ドロップダウン・リストから、「列挙」を選択します。

このフォームでは、オプション追加用のテキスト・ボックスが表示されます。

2. 「列挙値の追加」フィールドで、最初のオプションの名前を入力します。たとえば、genderという名前の属性に、オプションとしてfemaleを含めることができます。

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

オプションがリストに移動します。

図47-2 列挙の制約

4. この属性(フィールド)で使用可能にするオプションごとに、この手順を繰り返します。

47.2.1.3 属性の保存

1. (オプション)複数のサイトにアクセスできる場合は、この属性をこれらと共有するかどうかを指定します。「調査」フォームの「詳細」メニューで、訪問者属性の共有を選択します。

2. 訪問者属性の構成が終了したら、「保存」をクリックします。

Engageにより、WebCenter Sitesデータベースの訪問者データ・アセット表にこの属性に対するエントリが作成され、該当するサイト訪問者の型に関する情報を格納する場所がデータベースに確保されます。

Engageにより、「調査」フォームの属性の概要が開きます。

これで、この訪問者属性をセグメント内で使用できるようになります。

注意:

訪問者属性を使用してセグメントを定義した後、属性を削除するとセグメントが無効になります。属性を削除した場合は、セグメントを必ず修正してください。

47.2.2 履歴属性の作成

訪問者属性とは異なり、履歴属性は履歴定義で使用するために作成します。それらを使用して履歴定義を定義するまで、セグメント・フィルタ・フォームでそれらを使用できません。

Engageフォームを使用して履歴属性を作成するには、この項の手順を実行します。

注意:

履歴定義の定義に使用している履歴属性は、編集または削除できません。履歴定義から削除することもできません。したがって、履歴属性が変更されている履歴定義の使用を中止してください。新しい履歴属性を作成し、新しい履歴定義を作成した後、その新しい履歴定義を使用するようにしてください。

新しい履歴属性を作成するには:

1. Adminインタフェースを開きます。

2. ボタン・バーの「新規」をクリックして、リストから新規履歴属性を選択します。

「履歴属性」フォーム(図47-3)が開きます。

図47-3 「履歴属性」フォーム

注意:

「履歴属性」がメニュー・リストに表示されない場合は、ログイン/パスワードの組合せでは管理者権限が付与されないことを意味します。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

3. 「履歴属性」フォームの「名前」フィールドで、属性(フィールド)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字である必要があります。

4. 「説明」フィールドで、属性(フィールド)の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(属性は、セグメント・フィルタ・フォーム内の名前ではなく、この説明によってリストされます)。

5. 「タイプ」ドロップダウン・リストから、データ型を選択します。

6. 「string」を選択した場合は、「長さ」フィールドで、その属性(フィールド)に入力可能な最大の文字数を入力します。

7. セグメントを定義する履歴定義でこの属性を必須フィールドにする場合は、「指定が必要」フィールドで、「true」を選択します。

8. 「フィルタ」ドロップダウン・リストから、「true」を選択します。

「フィルタ条件」を「true」に設定しない場合は、マーケティング担当者がセグメントを作成する際に、その属性(フィールド)が所属するいずれの履歴定義に対してもその属性を制約として使用できません。

この属性のデータ型が数値の場合は、「フィルタ条件」をtrueまたはfalseのいずれに設定しても、セグメント内の合計制約に選択可能な属性のリストにデフォルトでこの属性が追加されます。ただし、その他の方法で制約として数値属性を使用するには、「フィルタ条件」をtrueに設定する必要があります。

9. 「NULL値を許可」ドロップダウン・リストから、「true」を選択するとNULL値が許可され、「false」を選択すると属性の入力が使用時に要求されます。たとえば、booleanデータ型の属性はNULL値を許可できません。

10. 「NULL値を許可」ドロップダウン・リストで「false」を選択した場合は、「デフォルト値」フィールドで、その属性のデータ型に適合するデフォルト値を入力します。たとえば、integerデータ型のデフォルト値は、数値にする必要があります。

47.2.2.1 制約基準の構成

属性への入力の検証に使用可能な制約オプションは、その属性に指定したデータ型によって異なります。

フリーフォーム・テキストを受け入れる属性の構成

「制約タイプ」ドロップダウン・リストから、「なし」を選択します。たとえば、string型のStreet Nameという履歴属性で、制約のないテキストを入力として受け入れる場合があります。

値の範囲から入力を受け入れる属性の構成

特定の値の範囲を受け入れる属性を構成するには、データ型をinteger、short、long、doubleまたはmoneyにする必要があります。図47-4に、範囲の制約と関連フィールドを示します。

図47-4 範囲の制約と関連フィールド

1. 「制約タイプ」ドロップダウン・リストから、「範囲」を選択します。
フォームに「範囲」フィールドが表示されます。

2. 「下限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最小値を指定します。この値を負の数値にはできません。

3. 「上限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最大値を入力します。(データ型がshortでは255まで、integerでは65,535まで、doubleでは4,294,967,295まで、moneyでは無制限に値を入力できます。)
たとえば、項目数という名前の属性で、1から50の間の値のみを受け入れるように制限できます。

固有の値のドロップダウン・リストを提供する属性の構成

1. 図47-5に示すように、「制約タイプ」フィールドから「列挙」を選択します。

このフォームでは、オプション追加用のテキスト・ボックスが表示されます。

図47-5 列挙の制約のフィールド

2. 「列挙値の追加」フィールドで、最初のオプションの名前を入力します。

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

4. この属性で使用可能にするオプションごとに、この手順を繰り返します。

47.2.2.2 履歴属性の保存

履歴属性の構成が終了したら、「保存」をクリックします。

Engageにより、WebCenter Sitesデータベースの訪問者データ・アセット表にこの属性に対するエントリが作成され、該当するサイト訪問者の型に関する情報を格納する場所がデータベースに確保されます。

これで、履歴属性を使用して、履歴定義を定義できるようになります。

47.2.3 履歴定義の作成

履歴定義は履歴属性で構成されます。したがって、履歴定義を作成するには、少なくとも1つの履歴属性が必要になります。

Engageフォームを使用して履歴定義を作成するには:

1. Adminインタフェースにログインします。

2. 「新規」をクリックして、リストから履歴定義を選択します。

履歴定義フォーム(図47-6)が開きます。

図47-6 履歴定義のフィールド

注意:

ログイン/パスワードの組合せに管理者権限がない場合、履歴定義はメニューに表示されません。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

3. 「名前」フィールドで、履歴定義(レコード)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字である必要があります。

4. 「説明」フィールドで、履歴定義の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(履歴定義は、セグメント・フィルタ・フォーム内の名前ではなく、この説明によってリストされます)。

5. 「カテゴリ」フィールドで、履歴定義のカテゴリを入力します。このフィールドに入力するテキストによって、セグメント・フィルタ・フォームでの履歴定義のソート方法および表示方法が決定されます。最大32文字の英数字を入力できます。

注意:

履歴定義のカテゴリは、訪問者属性のカテゴリとは別にする必要があります。

6. 「フィールド」領域で、この履歴定義を構成する履歴属性を選択します。属性を選択して右矢印をクリックすることで、その属性が右のリストに移動します。[Ctrl]を押しながらクリックすると、複数の属性を同時に選択できます。

注意:

履歴定義の定義に使用した履歴属性を編集または削除することはできません。

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

Engageにより、WebCenter Sitesデータベースの訪問者データ・アセット表にこの履歴定義(記録)に対するエントリが作成され、該当するサイト訪問者の型に関する情報を格納する場所がデータベースに確保されます。

次に、Engageにより、「調査」フォームの履歴定義の概要が開きます。

これで、この履歴定義をセグメント内で使用できるようになります。

47.3 訪問者データ・アセットの確認

訪問者属性、履歴属性および履歴定義が正しく設定されていることを確認するには、セグメント・フィルタ・フォームを調査して、作成した訪問者アセットが正しく構成されているかどうかを判断します。

- 作成した訪問者属性および履歴定義のそれぞれを使用するセグメントを作成します。

- 制限の定義が正しいこと、および入力範囲が正しい入力の範囲で使用できることを確認します。

47.4 訪問者データ・アセットの承認

訪問者データ・アセットの準備が整ったら、それを承認して配信システムにパブリッシュできるようにします。

履歴定義がパブリッシュされると、その定義に使用される履歴属性もパブリッシュされます。つまり、履歴定義をパブリッシュできるようにするには、履歴定義内のすべての履歴属性を承認する必要があります。

すべてのアセットを承認するには、そのアセットの「編集」フォームまたは「調査」フォームのアイコン・バーにあるドロップダウン・リストから「パブリッシュの承認」を選択します。

48 推奨アセットの理解

推奨は、レンダリングされたページで注目または推奨する必要のある製品またはコンテンツを決定するアセットです。これらのアセットは、訪問者の所属するセグメントや、製品アセットまたはコンテンツ・アセット、もしくはその両方の間の関係に基づいた一連のルールで構成されています。この章では、推奨アセットと推奨されるアセットの開発方法について説明します。また、推奨されるアセットを返すカスタム・エレメントの作成方法についても説明します。

推奨アセットの詳細は、次の項を参照してください。

- 推奨アセットについて

- 推奨の設定の開発プロセス

- 動的リスト・エレメントの作成について

48.1 推奨アセットについて

推奨アセットは、製品アセットとコンテンツ・アセットの収集、評価およびソートを行った後ら、最も適切なフレックス・アセット(現在の訪問者のアセットなど)を推奨します。最適なアセットは、訪問者が所属するセグメントのリストを参照することによって判断されます。

製品アセットおよびコンテンツ・フレックス・アセットは、各セグメントに対する重要度に応じて評価されます。テンプレートから推奨アセットがコールされると、Oracle WebCenter Sites: Engageでは、現在の訪問者が所属するセグメントが決定され、それらのセグメントで最も評価の高いアセットの中から推奨で特定されたものが選択されます。これらが、訪問者に対して推奨されるアセットです。

推奨には次の3種類があります。

- 静的リスト: 推奨されるアイテムの静的リストを返します。

- 動的リスト: 作成する動的リスト・エレメントにより生成された推奨アイテムのリストを返します。

- 関連アイテム: 製品など、フレックス・アセット間の関係に基づいて推奨されるアイテムのリストを返します。

Engageでは、リスト内のアイテムがテンプレートにプログラムされた表示数を超えた場合、推奨の構成オプションとそのアセット評価を使用してリストを制限します。関連アイテムの推奨の場合、Engageでは、アセットの関係もリストの制限に使用します。すべての推奨において、Engageでは、現在の訪問者で評価が0のアセットを除外します。

推奨アセットは、テンプレートを割り当てることのできる唯一のEngageアセットです。推奨テンプレートをコーディングし、レンダリングされたページ上で、推奨によって返されるアイテムを適切にレンダリングします。

このテンプレートによって、返すアセットの数が推奨に指示されます。推奨アセットは、どのアセットを選択してテンプレートに返す必要があるのかを、テンプレートに構成された方法および現在の訪問者が所属するセグメントに基づいて決定します。

推奨用テンプレートのコーディングに使用できるいくつかのXMLオブジェクト・メソッドおよびJSPオブジェクト・メソッド(タグ)があります。Engageを使用したテンプレートのコーディングの詳細は、「Engageページのコーディング」を参照してください。すべてのEngageタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

48.2 推奨の設定の開発プロセス

次の基本手順に従って、推奨を設定します。

1. 開発者および設計者がマーケティング・チームと話し合い、サイトに表示するすべてのマーチャンダイジング・メッセージを定義し、推奨アセットおよびプロモーション・アセットを使用したメッセージの表示方法について計画します。

2. 開発者および設計者が、XMLオブジェクト・メソッドまたはJSPオブジェクト・メソッドを使用して推奨用テンプレートを設計およびコーディングします。これらのテンプレートのコーディング方法については、「Engageページのコーディング」で説明しています。

3. Webサイトで動的リスト推奨を使用する場合、開発者は、推奨するアセットを返す動的リスト・エレメントをコーディングします。動的リスト・エレメントのコーディング方法については、「動的リスト・エレメントの作成について」で説明しています。

4. マーケティング・チームが、Engageの推奨ウィザードを使用して推奨を作成し、構成します。その際、適切なテンプレートを適切な推奨に割り当てます。

5. マーケティング担当者は、Engageの製品フォームとコンテンツ・アセット・フォームを使用して、各セグメントに対するアセットの重要度を評価することで、そのセグメントのメンバーである個々の訪問者に対するアセットの重要度を評価します。(通常は、個々のアセットではなく、製品の親などのフレックス親に評価を割り当てます。)

6. 関連アイテムの各推奨について、マーケティング担当者は、フレックス・アセットまたはフレックス親フォームの関連アセットを割り当てることにより、それらの推奨で維持される関係を構成します。(通常は、個々のアセットではなく、製品の親などのフレックス親の間の関係が構成されます。)

48.3 動的リスト・エレメントの作成について

Webサイトで動的リスト推奨を使用する場合は、推奨されるアセットのリストを返す動的リスト・エレメントをコーディングする必要があります。動的リスト・エレメントはCSElementアセット・タイプのインスタンスです。これにより、配信システムを使用するWebサイトがパブリッシュされた場合に、動的リスト・エレメントが配信システムに転送されるようになります。

動的リスト・エレメントは、AssetListという名前のリストを返す必要があります。AssetListになるアセット・セットには、次の特性が必要です。

- 推奨するアセット・タイプのみを含める必要があります。

- 推奨するアセットIDを含める必要があります。

- アセットの確信度評価を含める必要があります(オプション)。

次のコード例は、動的リスト・エレメントから抜粋したものです。次のコードの2行目では、検索状態のssprodに制約が追加され、Fund Typeの参照カテゴリを持つアイテムを検索するようにフィルタ処理が行われます。3行目では、検索状態のssprodに別の制約が追加され、Productアセットで全体が構成されるアセット・セットが作成されます。最後の4行目では、3行目で作成されたアセット・セットがAssetListリストに変換されます。

<SEARCHSTATE.CREATE NAME="ssprod"/>
<SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME="ssprod" TYPENAME="PAttributes" ATTRIBUTE="BrowseCategory" VALUE="Fund Type"/>
<ASSETSET.SETSEARCHEDASSETS NAME="asprod" CONSTRAINT="ssprod" ASSETTYPES="Products"/>
<ASSETSET.GETASSETLIST NAME="asprod" LISTVARNAME="AssetList"/>

動的リスト・エレメントのコーディングが完了したら、そのエレメントの名前と、動的リスト・エレメントが返すコンテンツの種類について、推奨アセットを作成するユーザーに情報を提供します。

49 メモリー中心の訪問者追跡の使用

Oracle WebCenter Sites: Engageアセットを閲覧するサイト訪問者は通常、個人プロファイルを使用して自身の情報を提供します。また、訪問者が閲覧することで統計情報が収集されます。大量の訪問者データによるWebCenter Sitesデータベースの過負荷を防ぎ、さらにパフォーマンスを改善するため、メモリー中心の訪問者追跡がEngageアセット用に開発されました。

メモリー中心の訪問者追跡のメソッドおよびこのメソッドの実装に必要な条件は、次の項を参照してください。

- メモリー中心の訪問者追跡

- メモリー中心の訪問者追跡の有効化

- メモリー中心の訪問者追跡の機能

49.1 メモリー中心の訪問者追跡

多数の訪問者がWebサイトを閲覧する場合、単一リポジトリにすべての個人情報を格納すると配信システムのパフォーマンスが低下します。そのため、訪問者の統計情報を収集するサイトでは、多くの場合、サイトのパフォーマンスを改善するためにリポジトリの追加が必要になります。さらにパフォーマンスを向上させるには、WebCenter Sitesデータベースでロードを行わないようにします。

WebCenter Sitesによりアドオン・リポジトリがサポートされるため、Engage開発者が独自のリポジトリを実装して訪問者のスカラー属性値を格納できます。そのリポジトリで訪問者情報を格納および取得するには、カスタム・コードを記述する必要があります。さらに、WebCenter Sitesでメモリー中心の訪問者追跡メソッドを有効化する必要があります。この概要では、メモリー中心のメソッドとデータベース中心のメソッドの違いについて説明します。メモリー中心の追跡の有効化に関する情報は、この章の後半に記載している、メモリー中心の訪問者追跡機能について説明した図を参照してください。

この項には次のトピックが含まれます:

- データベース中心のモデル

- メモリー中心のモデル

49.1.1 データベース中心のモデル

データベース中心の訪問者追跡では、次の理由により、Engage対応のWebサイト上でパフォーマンスの問題が発生します。

- WebCenter Sitesデータベースにすべての訪問者情報が格納されます。情報を格納および取得するには、複数のデータベース・アクセスが必要になります。

- 動的な推奨が使用されて大量のデータが返される場合、WebCenter Sitesに大量のSystemItemCacheエントリが記録されるためパフォーマンスが低下します。パフォーマンスをリストアするため、render:overridedepsタグで、WebCenter Sitesデータベースに記録される依存性の数を制限します。このタグは、データベース中心のモデルとメモリー中心のモデルの両方に適用されます。

49.1.2 メモリー中心のモデル

メモリー中心の追跡では、WebCenter Sitesデータベースの負荷を減らすことによってシステム・パフォーマンスを改善します。

- すべての計算はメモリー内で実行されます。

- カスタム・コードによりアドオン・リポジトリから訪問者のスカラー属性値(年齢、性別など)が取得されると、メモリー中心のモデルでは、取得された値がメモリー内に格納され、その値を履歴属性値とともに使用することで訪問者が所属するセグメントが計算されます。

- メモリー中心の追跡では、メモリー内で様々な履歴属性値に関する統計が計算され、その統計がキャッシュされます。統計には、合計、数、最も古い値および最新の値が含まれます。

- 別名および履歴属性値はWebCenter Sitesデータベースに格納されます。それにより、訪問者情報の量およびその情報にアクセスするためのコール数がともに少なくなります。

データベース中心の追跡と同様に、開発者は、render:overridedepsタグを使用して、WebCenter SitesデータベースにログインするためのEngageアセットの依存性の数およびタイプを指定できます。メモリー中心の追跡を有効化するには、wcs_properties.jsonのプロパティを設定して、サポート・テンプレート・コードを記述する必要があります。

49.2 メモリー中心の訪問者追跡の有効化

この項には次のトピックが含まれます:

- 訪問者追跡のプロパティ

- サポート・コード

- バッチを使用したデータベースへの履歴属性の保存

49.2.1 訪問者追跡のプロパティ

メモリー中心の訪問者追跡は、vis.useSessionVisitorConnectionプロパティで有効化し、このプロパティは、配信システム上で、(プロパティ管理ツールを使用して)WebCenter Sitesのwcs_properties.jsonファイルに手動で追加する必要があります。

- vis.useSessionVisitorConnection=trueを設定すると、メモリー中心の訪問者追跡が有効になります。また、Engage訪問者を適切に追跡するには、サポート・テンプレート・コードが配信システム上に存在する必要があり、その際には既存のコードを再利用できます。詳細は、「サポート・コード」を参照してください。

- vis.useSessionVisitorConnection=falseを設定したり、空白のままにしたり、それをwcs_properties.jsonから省略すると、データベース中心のメソッドが有効になります。

注意:

訪問者属性は、メモリー・モードを使用している場合はデータベースに格納されます。したがって、すべてのコンテンツ管理システムで、vis.useSessionVisitorConnectionをfalseに設定するか、省略する必要があり、それによって、訪問者属性を作成するか、それ以外では管理できるデータベース中心のメソッドを有効化します。(訪問者属性の管理は、データベース中心のトラッキングが有効なコンテンツ管理システムでのみサポートされます。配信システムはサポートされません。訪問者属性を配信システムに公開する必要があります。)

49.2.2 サポート・コード

この項のスケルトン・テンプレートでは、メモリー中心の追跡をサポートするために記述する必要のあるコードのタイプを示しています。

注意:

テンプレート・コードの実行方法は、vis.useSessionVisitorConnectionプロパティの値によって異なります。値がfalseに設定されている場合は、データベース中心の訪問者追跡が使用されます。値がtrueに設定されている場合は、メモリー中心の追跡が有効化されます。

vdm:setalias
retrieve visitor scalar attributes from add-on repository
vdm:setscalar
commercecontext:calculatesegments
commercecontext:getrecommendations
render Engage assets
vdm:recordhistory
...
render:overridedeps

このテンプレートの詳細は、「メモリー中心の訪問者追跡の機能」を参照してください。

49.2.3 バッチを使用したデータベースへの履歴属性の保存

WebCenter Sites 7.5パッチ2では、履歴属性はまずメモリーに保存され、次にファイル・システム、そして最後はバッチとしてWebCenter Sitesデータベースに保存されます。バッチを使用した保存によってメモリーの過度な使用を回避できます(メモリーの過度な使用は、データベースへの保存速度よりも早くデータが生成される場合に発生します)。バッチによる保存プロセスでは、ファイルから一度に1つずつHistoryAttributeDef表をバッチ化し、まとめてデータベースに保存します。

バッチを使用してデータベースに保存するには、Engageからデータベース情報にアクセスできる必要があります。データベース・アクセスを有効化するには、<dataSourceName>.propertiesという名前のファイルをクラスパスに追加して、driver、url、userおよびpasswordの情報を指定します。たとえば、データソース名がcsDataSourceの場合は、csDataSource.propertiesという名前のファイルをクラスパスに配置します。この例では、ファイル内のプロパティを次のように設定します。

driver=com.jnetdirect.jsql.JSQLDriver
url=jdbc:JSQLConnect://localhost:1433/database=TomcatDB
user=tomcatuser
password=tomcatuser

ファイル・システムを使用してメモリーからWebCenter Sitesデータベースにバッチで保存される非同期の履歴属性に対しては、スレッドを生成する時間間隔を次のJava JVMパラメータで制御します。

-Dvisitor.SyncInterval=<seconds>

指定しない場合、パラメータの値はデフォルトの30秒に設定されます。

49.3 メモリー中心の訪問者追跡の機能

この章の残りの部分の図は、メモリー中心の追跡の機能を示しています。

注意:

次の図のアドオン・リポジトリは独自に選択可能なシステムであり、訪問者のスカラー属性値を格納および取得するために使用されます。値を格納および取得するにはカスタム・コードを記述する必要があります。

この項には次のトピックが含まれます:

- 訪問者の検出

- スカラー値の取得

- 履歴属性値の収集

- 合計および数の計算

- セグメントの計算

- 推奨されるアセットの表示

- 依存性の記録

49.3.1 訪問者の検出

サイトへの初回ログイン時、訪問者は個人プロファイルを作成します。次のイベントが発生します。

1. テンプレート・コード内のvdm:setaliasタグを使用して、訪問者の別名がWebCenter Sitesデータベースに記録されます。後続のセッションでは、訪問者が自動的に認識されます。その結果、データベースには訪問者に一意の単一IDが保持され、パフォーマンスが向上します。
メモリー中心の訪問者追跡では訪問者ごとに一意のIDが記録される一方、既存のデータベース中心のメソッドでは訪問ごとに一意のID(再度訪問する訪問者に対しても)が記録されます。必要のないIDによってデータベースに余分な負荷がかかり、パフォーマンスが低下します。

2. 訪問者のスカラー値(年齢、性別などの個人情報)がアドオン・リポジトリに(カスタム・コードごとに)格納されます。

残りの手順では、訪問者のセグメントを決定し、訪問者に表示するEngageアセットを決定するために必要な情報がWebCenter Sitesによって収集および計算されます。

図49-1に、訪問者検出のフローを示します。

図49-1 訪問者の検出のフロー

49.3.2 スカラー値の取得

WebCenter Sitesで訪問者のセグメントの計算が開始され、次のスカラー値で開始されます。

1. WebCenter Sitesによってアドオン・リポジトリから(カスタム・コードを使用して)スカラー値が取得されます。

2. WebCenter Sitesでは、vdm:setscalarタグを使用して、取得したスカラー値がメモリーに設定されます。
セッション・ベースの実装により、訪問者情報(スカラー値)はhttpセッションにのみ格納されます。したがって、新しいセッションが始まると、訪問者情報はWebCenter Sitesデータベースではなくアドオン・リポジトリを介して使用可能になります。訪問者のスカラー値の問合せパフォーマンスを最適化するために、新しいレベルのキャッシュが追加されています。

図49-2に、スカラー値の取得のフローを示します。

図49-2 スカラー値の取得のフロー

49.3.3 履歴属性値の収集

訪問者のセグメントの計算には履歴属性値も必要になります。セッション中、履歴属性値が周期的に収集されます。

1. 履歴属性値を1分間隔でメモリーに収集するには、vdm:recordhistoryタグを使用します。

2. 履歴属性値は、ファイル・システムに格納された後、数回に分けてバッチでWebCenter Sitesデータベースに書き込まれます。メモリーが消去され、再度このサイクルが開始されます。
訪問者の履歴属性値を最初にメモリーに収集することによって、コールごとにデータベース接続を取得する必要がなくなります。これらをファイル・システムに格納し、バッチによるデータベースへの保存を可能にすることで、メモリーおよびデータベース接続の使用が最小化され、履歴属性値の可用性が高まります。

履歴属性値がデータベースにコミットされると、「合計および数の計算」に示すように、合計と数の計算が始まります。

図49-3に、履歴属性値のフローを示します。

図49-3 履歴属性値のフロー

49.3.4 合計および数の計算

履歴属性値の最初のセットが収集され、データベースに書き込まれると、WebCenter Sitesでは、1分間隔でデータベースを読み込み、合計と数を計算して、その結果をメモリーに格納します。

合計および数のキャッシュによってデータベース問合せが著しく減少するとともに、1分間隔にすることで1分以内の正確な合計と数が計算されます。

図49-4に、合計および数の計算のフローを示します。

図49-4 合計および数の計算のフロー

49.3.5 セグメントの計算

この時点で、WebCenter Sitesには訪問者のセグメントを計算するのに十分な情報が保持されています。WebCenter Sitesは、commercecontext:calculatesegmentsタグを使用して次を実行します。

1. メモリー内の訪問者のスカラー値をセグメント・ルール内のものと比較します。

2. データベース内の履歴属性値をセグメント・ルール内のものと比較します。

3. メモリー内の合計と数をセグメント・ルール内の合計または数と比較します。

この比較によって、WebCenter Sitesでは訪問者のセグメントが決定されます。

図49-5に、セグメントの計算のフローを示します。

図49-5 セグメントの計算のフロー

49.3.6 推奨されるアセットの表示

訪問者のセグメントを決定した後、WebCenter Sitesでは、commercecontext:getrecommendationsタグを使用して訪問者に最も関心のあるEngageアセットが決定されます。Engageアセットのテンプレートによって、推奨されるアセットが訪問者に表示されます。

さらにパフォーマンスを向上するには、render:overridedepsタグを「依存性の記録」で説明するように使用します。

図49-6に、推奨されるアセットの表示のフローを示します。

図49-6 推奨されるアセットの表示のフロー

49.3.7 依存性の記録

render:overridedepsタグを使用して、記録されるSystemItemCacheエントリの数を減らします。ページに記録された既存の依存性をすべて削除して、render:overridedepsタグにより指定された依存性を記録するには、テンプレート(またはCSElement)の、</cs:ftcs>タグの直前にこのタグを挿入する必要があります。使用可能な依存性を次に示します。

- 不明な依存性

- 固有の単一アセットにおける依存性

- 固有のアセット・タイプの不明な依存性

render:overridedeps タグは、次のパラメータを使用します。

- cid: タイプcのアセットのID。cと組み合せるとアセットのように機能し、cおよびcidによって決定されたアセットに対する依存性を記録します。

- c: アセットのタイプ。

- deptype: 依存性のタイプ。

使用するパラメータとその設定方法によって、記録される依存性が決定されます。

- deptypeのみがunknowndepsに指定および設定されている場合は、render:overridedepsによって不明な依存性が記録されます。

- cおよびcidの両方が指定されると、render:overridedepsによって、cおよびcidが指定するアセット上の依存性が記録されます。

- cおよびdeptype='unknowndeps'の両方が指定されると、render:overridedepsによって、cが指定するアセット・タイプ上の不明な依存性が記録されます。

注意:

render:overridedepsは十分注意して使用してください。ページ・キャッシュをフラッシュする唯一の方法は、依存性が記録されているアセットを編集することです。たとえば、単一アセット(またはアセット・タイプ)の依存性を記録している場合は、依存性が記録されているアセットを編集することでキャッシュをフラッシュします。ユーザーは、編集が必要なアセットを把握しておく必要があります。

50 Engageページのコーディング

Oracle WebCenter Sites: Engageを使用すると、訪問者情報を収集し、その情報に基づいて訪問者ごとの販促用メッセージをパーソナライズするオンライン・サイトを設計できます。

Engageページのコーディングの詳細は、次の項を参照してください。

- 商用コンテキストおよび訪問者コンテキスト

- 訪問者の識別およびセッションのリンク

- 訪問者データの収集

- 訪問者データを収集するサイト・ページのコーディング

- テンプレートおよび推奨

- ショッピング・カートおよびEngageについて把握する必要がある内容

- サイト・ページのデバッグ

注意:

この章では、説明するタスクを実行するために固有のXMLタグを参照します。また、そのすべてのケースには対応するJSPタグが存在します。XMLタグおよびJSPタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

50.1 商用コンテキストおよび訪問者コンテキスト

Engageサイトでの訪問者セッション中、その訪問者用の訪問者コンテキストが作成されます。この訪問者コンテキストには、次の5種類のセッション・オブジェクトがあります。

- 現在のショッピング・カート。

- 訪問者が所属するセグメントのリスト

- 訪問者に適したプロモーションのリスト

- セグメントおよびプロモーションに対する時間ベースのルールの計算に使用される時間オブジェクト

- 開発者に製品属性へのアクセス権を付与するユーティリティ・オブジェクト

商用コンテキストには訪問者コンテキストが含まれており、開発者に訪問者コンテキストへのアクセス権を付与します。

これらのコンテキストのインタフェースとして機能するXMLおよびJSPオブジェクト・メソッドには、次の2つのセットがあります。

- 商用コンテキスト・メソッド。訪問者コンテキストにオブジェクトを配置するために使用されます。

- 訪問者データ・マネージャ・メソッド。訪問者データを収集、格納および取得するほか、訪問者データを適切な訪問者に関連付けるために使用されます。

50.2 訪問者の識別およびセッションのリンク

Engageでは、各セッションの各訪問者に対して一意の訪問者IDが作成されます。これらのIDは、WebCenter SitesデータベースのVMVISITOR表に格納されます。そのセッション中に訪問者に関して収集されたデータは、訪問者IDで識別されます。あるセッションから収集されたデータを別のセッションからのデータにリンクするには、サイト・ページでそれらの訪問者IDをリンクする別名を割り当てる必要があります。

別名を作成するには、訪問者データ・マネージャの次のオブジェクト・メソッドを使用します。

<VDM.SETALIAS KEY="keyvalue" VALUE="aliasvalue"/>

このタグを使用すると、Engageでは訪問者セッションIDと別名が関連付けられ、その両方がVMVISITORALIAS表に書き込まれます。

図50-1 VMVISITORALIAS表

この表の値は、別々のセッションで収集されたデータを同一の訪問者にリンクします。別名によって、その訪問者に対して記録されている訪問者IDへのリンクが提供されるためです。上の図では、訪問者ID 973717492772に関連付けられたセッションに記録されているデータは、訪問者ID 973717564355に関連付けられたデータにリンクされています。これらは、同一のキー/値ペアの別名を保持しているからです。

訪問者情報はすべて、共通の別名を通じてリンクされたセッションに関連付けられます。つまり、現在のセッション中に、同一のキー/値ペアを持つ別名にアクセスできます。これは、現在の訪問者の情報と見なされます。Cookie、ログインIDまたはその他の一意の識別子を持つ別名を作成して、サイトでの訪問者の識別に使用できます。

VMVISITORALIAS表はすぐに大きくなります。この表およびその他の訪問者データ表の管理の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

50.3 訪問者データの収集

訪問者データを収集するには、その収集および検証のほか、WebCenter Sitesデータベースへの書込みを行うためのオンライン・ページをプログラムする必要があります。

訪問者データ・マネージャには、データベースにその情報を書き込む3つのオブジェクト・メソッドがあります。

- <VDM.SETSCALAR ATTRIBUTE="attribute" VALUE="value"/>は、訪問者属性を記録します。

- <VDM.RECORDHISTORY ATTRIBUTE="attribute" LIST="valuelist"/>は、履歴定義を記録します。

- <VDM.SAVESCALAROBJECT ATTRIBUTE="attribute" OBJECT="objectname"/>は、バイナリ・タイプの訪問者属性を記録します。Engageにより配信されたデモ・サイトでは、このメソッドを使用して、セッション間のショッピング・カートが格納されるほか、訪問者用に保存された検索が格納されます。

注意:

これらのタグによってデータベースに情報が書き込まれるため、配信システムのパフォーマンスに影響を与える可能性があります。これらは効率的に使用してください。

表50-1に、訪問者データが格納される表を示します

表50-1 訪問者データが格納される表

XMLまたはJSPオブジェクト・メソッド

書込み対象のデータベース表

VDM.SETSCALAR

vdm:setscalar

VMVISITORSCALARVALUE

VDM.SAVESCALAROBJECT

vdm:savescalarobject

VMVISITORSCALARBLOB

VDM.RECORDHISTORY

vdm:recordhistory

VMz------------

(これらの表は履歴定義ごとに動的に生成されます。Engageによってそれぞれに一意の表が作成されます。)

これらの表はすぐに大きくなります。これらの管理の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

訪問者データ・マネージャには、WebCenter Sitesデータベースからこの情報を取得する複数のオブジェクト・メソッドもあります。「エラーのロギングおよびデバッグ」を参照してください。

これらの詳細、および他のEngageのXMLタグとJSPタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

50.4 訪問者データを収集するサイト・ページのコーディング

訪問者データを収集するためにサイト・ページをコーディングする一般的な手順は、次のとおりです。

1. 訪問者が入力したデータを取得するためのフォームを作成します。作成した属性と同じ名前のフォーム・フィールドを作成することをお薦めします。詳細は、「訪問者データ・アセットの作成」を参照してください。
Engageセグメント・フォームでは、名前ではなく説明によって属性がリストされます。フォーム・フィールドを作成する場合、あるいはWebCenter Sitesデータベースに値を書き込む場合には、属性の名前と説明を混同しないように気を付けてください。

2. 訪問者がフィールドに入力したデータを検証する送信ページを作成します(JavaScriptまたはサーバー側の検証メソッドを使用)。入力データは、属性に設定された制約に準拠する必要があります。たとえば、訪問者の文字列型の属性の長さが30である場合、長さ31でフォーム・フィールドからデータが送信されないようにする必要があります。

3. 検証済データをWebCenter Sitesデータベースに書き込む送信ページをプログラムします。属性および履歴定義の名前を使用し、それらの説明は使用しないようにします。いくつか例を挙げます。

この項には次のトピックが含まれます:

- 例1: 訪問者属性

- 例2: 履歴定義

- 例3: バイナリ・タイプの訪問者属性

50.4.1 例1: 訪問者属性

次の例では、属性名を使用して登録情報がデータベースに書き込まれます。

<!-- Write the registration information to the database.-->
<VDM.SETSCALAR ATTRIBUTE="name" VALUE="Variables.name"/>
<VDM.SETSCALAR ATTRIBUTE="age" VALUE="Variables.age"/>
<VDM.SETSCALAR ATTRIBUTE="jobdesc" VALUE="Variables.jobdesc"/>

50.4.2 例2: 履歴定義

履歴定義には複数の値が集約して保持されているため、そのデータのリストを作成してからデータベースに書き込む必要があります。次の例では、フォームのオーダーがWebCenter Sitesデータベースに書き込まれます。

<!-- Write the order details to a list. -->
<!-- assume that Variables.order_id is set to the order id -->
<!-- assume that Variables.wasCouponUsed is set to 1 (yes) or 0 (no) -->
<!-- assume that Variables.shippingtype is set to UPS or FedEx -->
<!-- assume that Variables.order_price is set to the total amount of the
order -->

<LISTOBJECT.CREATE NAME="histList" COLUMNS="orderid, shippingtype, price, couponUsed"/>
<LISTOBJECT.ADDROW NAME="histList" orderid="Variables.order_id"
shippingtype="Variables.shippingtype" price="Variables.order_price" couponUsed="Variables.wasCouponUsed"/>
<LISTOBJECT.TOLIST NAME="histList" LISTVARNAME="itemList"/>

<!-- Write the list to the history definition named visitorOrderHistory in the WebCenter Sites database.-->
<VDM.RECORDHISTORY ATTRIBUTE="visitorOrderHistory" LIST="itemList"/>

この記録を使用して、訪問者のオーダー数、初回または最後の購入日時、および支払い総額に関する情報を確認できます。

50.4.3 例3: バイナリ・タイプの訪問者属性

バイナリ訪問者属性では、WebCenter Sitesネームスペースからのオブジェクトをバイナリ・フォームに変換できます。次の手順では、バイナリ・タイプの2つの訪問者属性を使用します。1つは複数のセッション間でショッピング・カートを格納するための属性で、もう1つは保存済検索を格納するための属性です。

1. 訪問者の動作(クリックストリーム情報など)に関するデータを収集するには、入力フォームを使用せずにデータを収集するページをプログラムします。
たとえば、訪問者がサイトを閲覧した回数を記録するために履歴定義を使用できます。

2. 訪問者データがデータベースに書き込まれるたびに、セグメントおよびプロモーションも変更される可能性があります。訪問者データに変更があった場合は必ず、セグメント・リストおよびプロモーション・リストを再計算するようにします。商用コンテキストには、使用可能な2つのオブジェクト・メソッドがあります。

- COMMERCECONTEXT.CALCULATEPROMOTIONS

- COMMERCECONTEXT.CALCULATESEGMENTS

COMMERCECONTEXT.CALCULATEPROMOTIONSでは、訪問者が所属するセグメントとそのセグメントに適用されるプロモーションの両方が再計算されます。

3. 訪問者データがデータベースに書き込まれるたびに、アセットの評価も変更される可能性があります。訪問者データに変更があった場合は必ず、既存のアセット・セットにあるすべてのアセットの評価をリフレッシュするようにします。
1つのセットにあるアセットのアセット評価をリフレッシュするには、ASSETSET.ESTABLISHRATINGSタグを使用します。

注意:

これらの詳細、および他のEngageのXMLオブジェクト・メソッドとJSPオブジェクト・メソッドの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

50.5 テンプレートおよび推奨

次のコードは、商用コンテキストで推奨アセットを起動する主要なオブジェクト・メソッドです。

<COMMERCECONTEXT.GETRECOMMENDATIONS COLLECTION="recommendationname" [LIST="inputlist" VALUE="rating" MAXCOUNT="assetcount"] LISTVARNAME="assetlist"/>

このメソッドでは、メソッドに渡される推奨制限に一致するアセットが取得され、リストされます。ここでは次の引数が使用されます。

- COLLECTION: 推奨の名前。複数の推奨に同じTemplateを使用する場合は、変数を使用して推奨IDを指定するようにこれをコーディングします。

- LIST: アセットのリストの名前。これは、計算の入力として使用する名前です。
COLLECTIONにより名付けられた推奨がコンテキストベースの推奨である場合は、この引数を使用します。列には、assettypeとassetidがあります。このリストを作成するには、リスト・オブジェクトを作成し、入力に使用するアセットごとに行を追加します。

- VALUE: 値を持たないアセットのデフォルトの評価。値を宣言しない場合、評価されていないアセットには、0から100のスケールのうちデフォルト評価の50が割り当てられます。この値は50に設定したままにしておくことをお薦めします。

- MAXCOUNT: (オプション。)返されるアセットの最大数。この値を使用して、推奨アセットのリストを制限します。

- LISTVARNAME: アセット・リストに割り当てる名前。列には、assettypeおよびassetidがあります。

セグメント・リストとプロモーション・リストが訪問者コンテキスト内で作成および配置されていない場合、このオブジェクト・メソッドによって、それらを計算するメソッドが呼び出されます。プロモーションにはテンプレートがなく、推奨が使用しているTemplateをオーバーライドすることに注意してください。プロモーションが現在の訪問者に適用され、COLLECTION引数によって指定された推奨をオーバーライドする場合、オブジェクト・メソッドは、推奨アセットによって識別されるアイテムではなく、プロモーション・アセットのIDを返します。

注意:

COMMERCECONTEXT.GETSINGLERECOMMENDATIONオブジェクト・メソッドでは、そのメソッドに渡された推奨基準に基づいて推奨されたアセットが1つ返されます。このメソッドは通常、1つの製品に注目を集めるか、1つの製品を販売する場合に使用されます。このオブジェクト・メソッドおよびこれと同等のJSPオブジェクト・メソッドの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

推奨のTemplatesのコーディングを始める前に、次のタスクを完了しておきます。

- マーケティング・チームと話し合い、サイトに表示するすべてのマーチャンダイジング・メッセージを定義し、推奨およびプロモーションでそれらのメッセージを表示する方法について計画します。たとえば、他の製品へのリンクのリストを表示しますか。リンクにどの情報を含める必要がありますか。製品名のみを表示しますか、それとも価格も含めますか。推奨がアセットのリストではなくプロモーションを返す場合、何を表示しますか。

- 各推奨から推奨されたアセットが表示される場所とページを決定します。

50.5.1 推奨のテンプレートの作成

推奨アセットによって返されたアイテムをレンダリングするテンプレートを使用するには、少なくとも次の基本手順を完了する必要があります。

1. 推奨アセットを起動するテンプレート・エレメントを作成します。前述の項で説明したオブジェクト・メソッドを使用します。

2. 推奨によって返されたアイテムを表示するテンプレートをコーディングします。返されたアイテムは、LISTVARNAME引数によって指定された変数に格納されます。このリストには、アセットIDとそれらのアイテムのアセット・タイプが含まれます。この情報を使用して、表示するアセット属性(Name、PriceおよびSKUなど)を抽出します。

ASSETSET.SETLISTEDASSETSオブジェクト・メソッドおよびASSETSET.GETASSETLISTオブジェクト・メソッドを使用することで、返されたアセットとその属性をソートして表示できます。

3. Engageを開きます。「新規」の下で、「テンプレート」を選択します。このTemplateエレメントに対応するTemplateアセットを作成します。エレメントの実行内容を説明する名前を入力することで、推奨アセットの作成時、そのアセットに割り当てられるTemplateを把握できます。「エレメント名」フィールド内のエレメント(そのエレメント・カタログ内の場所)へのパスを特定します。

4. 他のアセットがパブリッシュされたら、Templateアセットをパブリッシュします。

5. 適切なサイト・ページに推奨をレンダリングします。

50.5.2 Oracle Real-Time Decisionsを使用した推奨のテンプレートの作成

Oracle Real-Time Decisions (RTD)は、サイトの訪問者が選択を行うときに、最適な選択肢を推奨することで意思決定を支援するエンジンです。commercecontext:getrecommendationsタグが呼び出されると、このタグは、推奨のリストと特定の訪問者のプロファイル情報をOracle RTDに送信します。Oracle RTDは、推奨をランク付けし、maxcount="<n>"パラメータを使用して、訪問者のプロファイルに最適なn個の精選された推奨のリストを返します。

注意:

このリリースのWebCenter Sitesでは、Oracle Real-Time Decisions (RTD)バージョン3.0シリーズをサポートしています。RTD 11gはサポートしていません。

Oracle RTD(およびその他のエンジン)は、次のタグを使用することで、WebCenter Sitesに統合できます。

- commercecontext:getrecommendationsタグ。engineおよびengineparametersは、エンジンを呼び出すために設定できる汎用パラメータです。Oracle RTDとの統合の場合、エンジン・パラメータはrtdに設定する必要があり、engineparametersでは、advisor (統合点)、attributes (訪問者のプロファイル)、sessionkey、assetattributesなど、Oracle RTD固有の各パラメータのリストを指定する必要があります。

- commercecontext:informタグ。このタグもパラメータengineとengineparametersを受け入れます。このタグの場合、engineparametersでinformant (統合点)、attributes (訪問者のプロファイル)およびsessionkeyの各パラメータのリストを指定する必要があります。

注意:

choicesパラメータ(推奨の選択)は、このタグから削除されました。選択肢のリストは、リストのtag属性によって、RTDに渡されるようになりました。

Oracle RTDでcommercecontext:getrecommendationsタグの属性リストが認識されたら、開発者は、sessionkeyパラメータを使用して、後続のcommercecontext:informコール用に、訪問者をそのプロファイルにマップできます。たとえば、Oracle RTDに対してcommercecontext:getrecommendationsコールが行われた後の、同じ訪問者からの次回のコールでは、属性を空の文字列として渡すことで、同一のsessionkeyを使用して推奨を取得できるようになります。

注意:

commercecontext:getrecommendationsタグとcommercecontext:informタグを使用してOracle RTDを呼び出す場合、rtd.inline.service.nameプロパティとrtd.hostプロパティをwcs_properties.jsonファイルに追加する必要があります。

commercecontextタグ、パラメータ定義、およびOracle RTDとの統合の詳細とサンプル・コードは、Oracle WebCenter Sitesタグ・リファレンスを参照してください。rtd.inline.service.nameプロパティ、rtd.hostプロパティおよびrtd.choiceId.patternプロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

50.6 ショッピング・カートおよびEngageについて把握する必要がある内容

Engageとのショッピング・カート・インタフェースを使用してショッピング・カート・ページをコーディングする場合は、次の情報とヒントを考慮してください。

- サイトでプロモーションを使用する場合は、プロモーションによる割引きが適用されるようにカート・ページをコーディングする必要があります。
COMMERCECONTEXT.DISCOUNTCARTオブジェクト・メソッドおよびCOMMERCECONTEXT.DISCOUNTTEMPCARTオブジェクト・メソッドを使用して、プロモーションによる割引きをショッピング・カートに適用します。

- カートの既存の割引きを消去した後に、再び割引きを適用することをお薦めします。

- セッション間でカートを格納するには、それらをバイナリ・タイプの訪問者属性(スカラー・オブジェクト)としてデータベースに書き込みます。カートが変更されるたびにカート・オブジェクトをデータベースに書き込むようにします。

- サイトで訪問者のログイン機能を使用する場合は、ショッピング・カートをマージする条件を設定できます。たとえば、ある訪問者は製品をカートに追加してから、ログインします。ログイン後に、Engageにより、アイテムも含む格納済のカートが検出されます。このような場合は、カートをマージします。

CARTオブジェクト・メソッドおよびこれと同等のJSPオブジェクト・メソッドの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

50.7 サイト・ページのデバッグ

開発フェーズの間は、セッション・リンクが正しく設定されていること、特定の属性によって期待どおりの値が取得されること、さらに推奨で目的のアイテムが返されることを確認する必要があります。Engageには、ブラウザ・ウィンドウやJREログに情報を書き込むことで、情報と値の取得および確認を可能にする複数のオブジェクト・メソッドが存在します。

この項では、最も使用する可能性が高い訪問者データ・マネージャのオブジェクト・メソッドをリストします。これらの詳細、および他のXMLオブジェクト・メソッドとJSPオブジェクト・メソッドの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

この項には次のトピックが含まれます:

- セッション・リンク

- 訪問者データの収集

- 推奨およびプロモーション

50.7.1 セッション・リンク

訪問者データ・マネージャの次のオブジェクト・メソッドを使用して、セッション・リンクを処理するページでその別名が正しく作成されることを確認します。

- <VDM.GETALIAS KEY="keyvalue" VARNAME="varname"/>
別名を取得します。

- <VDM.GETCOMMERCEID VARNAME="varname"/>
セッション・データから訪問者のコマースIDを取得します。

- <VDM.GETACCESSID KEY="pluginname" VARNAME="varname"/>
セッション・データから訪問者のアクセスIDを取得します。

50.7.2 訪問者データの収集

訪問者データ・マネージャの次のオブジェクト・メソッドを使用して、特定の訪問者属性、履歴属性および履歴定義(記録)について格納されている値を取得します。

- <VDM.GETSCALAR ATTRIBUTE="attribute" VARNAME="varname"/>
特定の訪問者属性を取得します。

- <VDM.LOADSCALAROBJECT ATTRIBUTE= "attribute" VARNAME= "varname"/>
バイナリ・タイプの訪問者属性として格納されているオブジェクトを取得(実体化)します。

- <VDM.GETHISTORYCOUNT ATTRIBUTE="attribute"VARNAME="varname"[STARTDATE="date1" ENDDATE="date2"LIST="constraints"]/>
指定された基準に一致する訪問者について記録された履歴定義の記録回数を取得します。

- <VDM.GETHISTORYSUM ATTRIBUTE="attribute" VARNAME="varname"[STARTDATE="date1" ENDDATE="date2" LIST="constraints"]FIELD="fieldname"/>
指定された履歴定義に対する特定のフィールド内のエントリを合計します。

- <VDM.GETHISTORYEARLIEST VARNAME="varname" [STARTDATE="date1"ENDDATE="date2" LIST="constraints"]/>
この訪問者について、指定された履歴定義が初めて記録されたときのタイムスタンプを取得します。

- <VDM.GETHISTORYLATEST VARNAME="varname"[STARTDATE="date1"ENDDATE="date2" LIST="constraints"] />
この訪問者について、指定された履歴定義が最後に記録されたとき(つまり最新)のタイムスタンプを取得します。

50.7.3 推奨およびプロモーション

商用コンテキストの次のオブジェクト・メソッドを使用して、推奨およびプロモーションを表示するページを確認します。

- <COMMERCECONTEXT.CALCULATESEGMENTS/>
訪問者が所属するセグメントをリストします。ここでは、使用可能な訪問者データを調査し、それをセグメントを定義するデータ型と比較して、一致するセグメントをリストします。

- <COMMERCECONTEXT.GETPROMOTIONS LISTVARNAME="promotionlist"/>
現在の訪問者を対象とするプロモーションのリストを作成します。

- <COMMERCECONTEXT.GETRATINGS ASSETS="assetlist" LISTVARNAME="ratinglist" DEFAULTRATING="defaultrating"/>
名前付きリスト内のアセットの評価を、訪問者が所属するセグメントに基づき、この訪問者に対するアセットの重要度に従って計算します。

- <COMMERCECONTEXT.GETSEGMENTS LISTVARNAME="segmentlist"/>
現在の訪問者が所属するセグメントのリストを取得します。

第XI部 A/B Testingの実行

この部では、Oracle WebCenter Sites: A/B Testingにおける開発者の役割について説明します。最後には、ROIを測定するための変換の追跡を開発する方法について説明します。

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

- A/B Testingの開発

51 A/B Testingの開発

Oracle WebCenter Sites: A/B Testing機能では、マーケティング担当者がWebサイト・ページのデザインとコンテンツのバリエーションを試行して、Webサイトに恒久的な変更を加える前に、最適な結果となるバリエーションを判断できます。

マーケティング担当者によるA/Bテストの作成および実行の詳細は、『Oracle WebCenter Sitesの使用』のA/B Testingの使用に関する項を参照してください。

A/B Testingでの開発の詳細は、次の項を参照してください。

- A/B Testingの要件

- A/B Testingのスクリプト・テンプレート

- A/B Testingのキャッシュ基準の更新

- JSONとしてのA/Bテストの詳細の表示

- 確信度アルゴリズムの理解

51.1 A/B Testingの要件

注意:
このOracle WebCenter Sites製品のA/Bテスト機能は、Google Analyticsとの統合を介して提供されます。 このOracle製品のA/Bテスト機能を使用するには、"A/B"テストのパフォーマンスの測定が可能なGoogle Analyticsアカウントを最初にGoogleで登録します。 また、"A/B"テストの一部として、匿名エンド・ユーザー情報(テスト用Webサイトにアクセスするエンド・ユーザーの情報)が、その情報を管理するGoogleに配信され、Googleの条件に従いGoogleが使用する場合があることを承認します。

A/B Testing機能を使用できるようにするには、開発者は次を実行する必要があります。

1. A/Bテストが実行されるテンプレートにA/Bコード・エレメントを含めます。詳細は、「A/B Testingのスクリプト・テンプレート」を参照してください。

2. A/Bテスト・バリアントをサイト訪問者に配信するインスタンスである、配信インスタンスでプロパティabtest.delivery.enabledをtrueに設定します。このプロパティは、A/Bテストの作成のみに使用するインスタンスには設定しないでください。なぜなら、誤った結果が生成されるからです。abtest.delivery.enabledプロパティは、wcs_properties.jsonファイルのABTestカテゴリ内にあります。
詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のA/Bテスト・プロパティに関する項を参照してください。

3. すべてのGoogle Analytics IDを取得して構成に追加します。

A/Bテストの前提条件として、その他のアクションをユーザーおよび管理者が実行する必要があります。完全なリストは、『Oracle WebCenter Sitesの使用』のA/B Testingを開始する前にに関する項を参照してください。

51.2 A/B Testingのスクリプト・テンプレート

A/B Testingを機能させるには、単一行のコードのコール・エレメントを追加する必要があります。含まれるエレメント・コードにより、JavaScriptコードがページに生成されます。テスト済ページがブラウザにロードされると、サーバーにコールバックされ、このページにA/Bテストがあるかどうかを確認します。

この行は、A/B Testingで使用されるページのテンプレートに追加する必要があります。多くのサイトでは、すべてのページの共有テンプレートを含む設計が組み込まれています。この設計をサイトで使用する場合、コール・エレメントを単一のテンプレートに追加するだけで済みます。avisportsサンプルWebサイトでは、Headという名前のテンプレートにコール・エレメントが含まれます。

テンプレートを編集するには、A/B Testingを使用するサイトごとに次の手順に従います。

1. Adminインタフェースで、テンプレートを検索して開きます。

2. 「編集」アイコンをクリックして、テンプレート・フォームを開いて編集します。「エレメント」を選択します。

「エレメント」フォームがテンプレート内に表示されます。

図51-1 Headテンプレートの「エレメント」フィールド

3. 「エレメント・ロジック」フィールドで、次の行を追加します。

<render:callelement elementname="fatwire/includeABTesting" args="c,cid,pagename"/>

これはコードの上部に追加することをお薦めします。これにより、ページのレンダリング前に、このJavaScriptがアクティブになります。

注意:
前述のサンプル・コードでは、テンプレートのrender:callelementタグを使用してincludeABTestingエレメントを含める方法を説明しています。または、ControllerでFragment APIを使用してエレメントを含めることもできます。Fragment APIの詳細は、「開発者のサンプルWebサイト」を参照してください。

4. テンプレートを保存します。

ここから、サイトで使用されるページ・テンプレートのキャッシュ基準にabを追加します。

51.3 A/B Testingのキャッシュ基準の更新

注意:
新規テンプレートを作成すると、デフォルトでabがキャッシュ基準に追加されます。

A/B Testingで使用される各テンプレートにコール・エレメント・コードを追加した後に、テスト済ページで使用されるページ・テンプレートのキャッシュ基準にabを追加する必要があります。avisportsサンプルWebサイトでは、使用されるページ・テンプレートはSectionLayoutGreenとSectionLayoutOrangeの2つです。この変更は、A/B Testingで使用されるサイトで使用するすべてのページ・テンプレートで行う必要があります。

ページ・テンプレートを更新する手順:

1. Adminインタフェースで、A/B TestingのWebサイトで使用されるページ・テンプレートを検索して開きます。

2. 「編集」アイコンをクリックして、ページ・テンプレートを開いて編集します。「サイト・エントリ」画面を選択します。

テンプレートの「サイト・エントリ」フォームが表示されます。

図51-2 A/B Testingテンプレートのサイト・エントリ

3. 「キャッシュ基準」フィールドで、カンマ区切りアイテムのリストの先頭にabを入力します。他のエントリは削除しないでください。

4. テンプレートを保存します。

A/B Testingのページで使用されるすべてのページ・テンプレートで、これらの手順を繰り返します。

51.4 JSONとしてのA/Bテストの詳細の表示

各A/B Testingアセットは、WCS_ABTestアセット・タイプ経由で使用され、オリジナルのWebページ(Aページ)とテスト・ページ(Bページ)の間での変更を個別にリストしたフィールドが含まれます。これら変更は差分データと呼ばれ、JSON形式でバリエーション(JSON)フィールドに格納されます。

差分データを表示する手順:

1. Contributorインタフェースで、A/B Testingアセットをフォーム・モードで開きます。

2. 「コンテンツ」タブを選択します。

アセットがフォーム・モードで表示されます。

3. 使用されるJSONがバリエーション(JSON)フィールドに表示されます。ここでは、AとB (使用されている場合は、その他のテスト・ページ)のテスト・ページ間のすべての差分について説明します。

コントリビュータには推奨されませんが、必要に応じて、JSONに格納される差分データを直接編集できます。JSONを適切なJSONエディタにコピーして、必要な変更を加えてから、バリエーション(JSON)フィールドに貼り付けます。

51.5 確信度アルゴリズムの理解

マーケティング担当者がA/Bテストを作成する場合、その結果の確信度レベルを選択できます。この数値により、テスト結果の重要度に関する確信度が決まり、これは特に、『Oracle WebCenter Sitesの使用』のA/Bテストの確信度レベルの選択に関する項で説明されているように、変換の違いが、ランダムな訪問者のバリエーションではなく、バリアントの差異自体に原因がある場合です。この項では、変換の確信度の計算方法の詳細を説明します。

変換率は、変換イベントの件数を閲覧の件数で割ったものです。通常はpで表されます。変換率の変化の割合は、ページAのpをページBのpから引き、ページAのpで割ったものです。これはユーザーごとに計算されます。たとえば、1000000回変換されたしたユーザーは1回としかカウントされません。確信度の判断に使用されるアルゴリズムはZスコアです。

このコンテキストで使用される"確信度"は、訪問者間のランダム・バリエーションだけでなく、ページのバリエーションによってAの結果とBの結果の違いが実際に発生する確信度を判断するのに使用される、統計的計算を指すのに使用されます。

確信度の間隔は、二項分布のWald検定を使用して計算されます。

図51-3 二項分布の確信度の間隔を決定するためのWald検定

サンプルが大きいほど、結果の確信度は高くなります。A/B Testingで使用される一般的なしきい値は、最終スコアから3%の範囲の確信度の間隔です。ただし、これは単なる一般的な使用例であり、任意の範囲の使用が可能です。標準の正規分布の百分位数範囲の標準誤差を掛けることにより、変換率(p)に対する確信度の間隔が決まります。

この時点で、結果が重要である、つまり、ランダムなバリエーションに基づいて変換率に差異がないことを確認する必要があります。Zスコアは次の方法で計算されます。

図51-4 Zスコアの計算

Zスコアは、コントロールとテストの平均値の間における正の標準偏差値の数です。前述の標準的な確信度間隔を使用すると、ビュー・イベントの数が1000を超えており、Zスコアの確度が95%を超えているか5%を下回る場合、統計的重要度は95%であると判断できます。

第XII部 ブログのカスタマイズ

次の部では、ブログ・データ・モデルのカスタマイズ手順について説明します。また、テンプレート・コードと、各種のCMサイトにおけるブログ機能開発のガイドラインについても説明します。

- ブログ・コンポーネントのカスタマイズ

52 ブログ・コンポーネントのカスタマイズ

デフォルトのブログ・コンポーネントは、カスタム・ページをレンダリングできるようにカスタマイズできます。

ブログ・コンポーネントのカスタマイズの詳細は、次の項を参照してください。

- ブログ・アセット・フォームのカスタマイズ

- CMサイトへのブログ機能の追加

- RSSフィードのURLのカスタマイズ

52.1 ブログ・アセット・フォームのカスタマイズ

Blogフレックス・ファミリの階層は、要件にあわせて変更できます。属性をブログ・アセット・フォーム内のフィールドとして表示するには、最初に新しいブログ属性を作成し、その属性をブログ・アセット定義に追加します。

注意:

ブログ・カテゴリとブログ・アセットの階層関係を参照するには、ツリー・タブを作成します。ツリー・タブの作成手順は、『Oracle WebCenter Sitesの管理』を参照してください。

この項には次のトピックが含まれます:

- ブログ属性の作成

- ブログ・アセット定義へのブログ属性の追加

52.1.1 ブログ属性の作成

ブログ属性を作成してブログ・アセット定義に追加すると、その属性はブログ・アセット・フォームにフィールドとして表示されます。

ブログ属性を作成するには:

1. 一般管理者としてAdminインタフェースにログインします。

2. Blogsコンポーネントが有効になっているサイトを選択します。

3. ボタン・バーで、「新規」をクリックします。

4. 「新規ブログ属性」をクリックします。

5. 図52-1に示すブログ属性フォームで、フィールドに入力します。

図52-1 「ブログ属性」フォーム

注意:

フィールドは、属性に対して選択したデータ型に応じて大きく異なる場合があります。

- 名前: 最大64文字の名前を入力します(空白文字を含めることはできません)。

- 説明: 属性の使用方法や機能について説明した、簡潔なサマリーを入力します。

- 値タイプ: この属性のデータ型を選択します。

- アセット・タイプ: 属性のタイプがassetの場合、ドロップダウン・リストからアセットを選択します。

- 依存性タイプのミラーリング: 属性のタイプがassetの場合、依存性タイプを選択します。

- フォルダ: (オプション)属性のタイプがblobの場合、属性値を保存するディレクトリのパスを入力します。

- 埋込みリンクの許可: 属性のタイプがtext、blobまたはURLの場合、属性のコンテンツ・フィールドに他のページまたはWebサイトへのリンクを埋め込むことが可能かどうかを選択します。

- 値の数: 「値タイプ」フィールドで選択したデータ型に応じて、ドロップダウン・リストから「単一」または「複数」のいずれかを選択します。

- 属性エディタ: (オプション)デフォルト以外の入力タイプを使用するには、「属性エディタ」フィールドで、フィールドに適した属性エディタを選択します。

- (オプション)文字セット: デフォルトのISO文字セット(ISO-8859-1)をオーバーライドするには、この属性で使用する文字セットを入力します。

外部属性を作成する(外部システムでデータを保持する)場合は、次のフィールドに入力します。

- 編集スタイル: この属性を外部システムのネイティブ表として利用できるようにするには、「外部」を選択します。

- ストレージ・スタイル: 「外部」を選択します。詳細は、「外部フレックス属性の作成」を参照してください。

- 外部ID:この外部属性を格納する表の主キーとなる列(この属性を一意に識別する列)の名前を指定します。

- 外部表: この属性を格納する表の名前を入力します。

- 外部列: 「外部表」フィールドで指定した表の、この属性の値が格納される列の名前を入力します。

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

属性を作成したら、その属性をブログ・アセット定義に追加します。手順は、次の項を参照してください。

52.1.2 ブログ・アセット定義へのブログ属性の追加

ブログ・アセット・フォームに属性を追加するには、その属性をブログ・アセット定義に追加する必要があります。

ブログ・アセット定義に属性を追加するには:

1. 一般管理者としてAdminインタフェースにログインし、Blogsコンポーネントが有効になっているサイトを選択します。

2. ブログ・アセット定義の「調査」フォームにアクセスします。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」フォームで、ブログ・アセット定義の検索をクリックし、「検索」をクリックします。

c. 「BlogAssetDef」を選択します。

3. 「調査」フォームで、「編集」をクリックします。

図52-2 「ブログ属性」フォーム

4. 「属性」フィールドで、「使用可能」リストから属性を選択し、「必須」ボタンまたは「オプション」ボタンを使用して属性を「選択済」リストに移動します。選択したボタンによって、ブログ・アセット・フォームでこの属性が必須またはオプションのいずれになるかが決定されます。

5. 「保存」をクリックします。
選択した属性が、ブログ・アセット・フォームにフィールドとして含まれるようになります。ユーザーがブログ・アセットを作成するときに、新しい属性が必須またはオプションのフィールドとして表示されます。

52.2 CMサイトへのブログ機能の追加

各種のCMサイトでBlogsコンポーネントを使用するには、それらのサイト用のブログ・ページを作成する必要があります。

Webサイトにブログ機能を追加するには:

1. コンテンツ管理サイトに、Webサイトでのブログ・アセットのレンダリングに使用されるページを作成します。

2. デフォルトのブログ・テンプレートおよびCSElementから、ご使用のサイトのテンプレートおよびCSElementにブログ・コードをコピーします。テンプレートおよびCSElementに挿入した後で、デフォルトのコードに加える必要のある変更内容は、サイトの設定方法によって決まります。

3. BlogsコンポーネントのSiteEntryアセットで指定されているblogsperpageパラメータを、ご使用のサイトのSiteEntryアセットに追加します。

この項には次のトピックが含まれます:

- ブログ・ページの作成

- ブログ・コードの追加

- サイトのSiteEntryアセットへのブログ・パラメータの追加

52.2.1 ブログ・ページの作成

ブログ・ページを作成する前に、メイン・ブログ・ページ(BlogsコンポーネントではFW_RecentBlogsページ)、カテゴリ・ページなど、ページのタイプについて構想を練ります。また、ご使用のWebサイトのレイアウトに合致するブログ・ページを作成するため、サイトのグラフィック、ナビゲーション、機能を決定します。

ブログ・ページを作成するには:

1. 一般管理者としてWebCenter Sitesにログインし、Webサイトの訪問者にブログを表示するページの作成場所であるサイトを選択します。その後、Oracle WebCenter Sites: Contributorインタフェースのアイコンを選択します。

2. メニュー・バーで、「コンテンツ」→「新規」→「新規ページ」を選択します。

タブが開き、図52-3に示す「新規ページ」フォームが表示されます。

図52-3 「新規ページ」フォーム

3. 「新規ページ」フォームで、次のようにフィールドに入力します。

- 名前: 最大64文字の名前を入力します。

- タグ: ページに追加する1つの語句またはフレーズを入力します。

- テンプレート: ページをレンダリングするテンプレートを選択します。

- 関連付けられたアイテム: このフィールドの「ドロップ・ゾーン」にコンテンツ(関連する記事など)を追加します。

4. 「保存」アイコンをクリックします。

ブログ・アセットを表示するページを作成したら、ご使用のWebサイトで新しいページを呼び出してブログの機能をレンダリングするためのサイトのテンプレートおよびCSElementをコーディングします。詳細は、「ブログ・コードの追加」を参照してください。

52.2.2 ブログ・コードの追加

Blogsコンポーネントは、サンプル・ブログ・ページをレンダリングするように構成されています。ただし、ほとんどの場合、ご使用のサイトのレイアウトはサンプル・ブログ・ページのレイアウトとは異なるでしょう。たとえば、サンプル・ブログ・ページでは右のナビゲーションを呼び出しますが、ご使用のサイトでは左のナビゲーションを呼び出す場合があります。テンプレートを初めからコーディングしてブログ機能を組み込むのではなく、サンプル・コードを再利用して自身のテンプレートやCSElementに挿入し、必要に応じてコードを再構成します。

注意:

サイトのレイアウトはサイトのラッパー・エレメントによってレンダリングされます。既存のページに加えて、ブログ・ページもラッパー・エレメントによってレンダリングされるようにするには、デフォルトのFW_Wrapperエレメントからサイトのラッパー・エレメントに該当するブログ・コードをコピーします。

サイトのレイアウト・テンプレートにブログ・コードを追加するには:

1. 一般管理者としてAdminインタフェースにログインします。

2. Blogsコンポーネントがインストールされているサイトを選択します。

3. FW_BlogLayoutテンプレートにアクセスします。

a. ボタン・バーで、「検索」をクリックします。

b. 「検索」リストで、テンプレートの検索を選択します。

c. 「検索」フィールドにFW_BlogLayoutと入力し、「検索」をクリックします。

d. 「FW_BlogLayout」をクリックします。

4. レイアウト・テンプレートの「調査」フォームで、「編集」をクリックします。

5. Blogsコンポーネントのレイアウト・テンプレートから必要なコードをコピーし、自身のレイアウト・テンプレートに挿入します。
次の行は、ラッパーからサイトの説明を取得し、サイトをロードします。

<ics:if condition='<%=ics.GetVar("tid")!=null%>'>
<ics:then>
<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>
</ics:then>
</ics:if>

<publication:load name='Publication' field="name"
value='<%=ics.GetVar("site")%>'/>
<publication:get name='Publication' field="id" output="spubid"/>
<publication:get name='Publication' field="description" output="pubdesc"/>

次の行は、ページの本文を取得します。

String sContainerTName = "FW_BlogContainer";

次の行は、サイト、ページおよびアセットの説明をロードします。

String sTitle = "";
if (!"Page".equals(ics.GetVar("c")))
{
%><asset:load name='t2' type='<%=ics.GetVar("c")%>'
objectid='<%=ics.GetVar("cid")%>' /><%
%><asset:get name='t2' field='name' output='t2Name' /><%
%><asset:get name='t2' field='description' output='t2Desc' /><%
sTitle += ": "+(Utilities.goodString(ics.GetVar("t2Desc")) ?
ics.GetVar("t2Desc") : ics.GetVar("t2Name"));
} else if (Utilities.goodString( ics.GetVar("p") )) {
%><asset:load name='t1' type='Page' objectid='<%=ics.GetVar("p")%>' /><%
%><asset:get name='t1' field='name' output='t1Name' /><%
%><asset:get name='t1' field='description' output='t1Desc' /><%
sTitle += ": "+(Utilities.goodString(ics.GetVar("t1Desc")) ?
ics.GetVar("t1Desc") : ics.GetVar("t1Name"));
}

次の行は、ブログ・レイアウト・テンプレートのスタイル・シートを呼び出します。このスタイル・シートは、サンプル・ブログ・ページのルック・アンド・フィールを定義します。サイトには独自のスタイル・シートが存在するため、Blogsコンポーネントのスタイル・シートから必要なパラメータをコピーして、独自のスタイル・シートに挿入します。Blogsコンポーネントのスタイル・シートと独自のスタイル・シートの間の競合を解決する必要があります。

<render:callelement elementname="FW_Blogs/CSS/blogsCSS/">

次の行は、「ブログのアーカイブ」ページの「詳細」リンクを取得するためのJavaScriptメソッドです。

<script type="text/javascript">
function getMoreBlogs(url) {
var xhtReq = getXMLHttpRequest();
xhtReq.open(GET, url, true);
xhtReq.onreadystatechange = function() {
if(xhtReq.readyState==3) {
document.getElementById('moreLink').innerHTML =
' <img src="<%=ics.GetSSVar("baseurl")%>images/wait_ax_tiny.gif/>';
}
else if(xhtReq.readyState==4) {
document.getElementById('archiveDiv').innerHTML = xhtReq.responseText;
}
};
xhtReq.send(null);
}

function getXMLHttpRequest() {
try { return new XMLHttpRequest(); } catch(e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
alert("XMLHttpRequest not supported");
return null;
}
</script>

次の行は、メイン・ブログ・ページまたは指定されたアセットの本文を呼び出します。また、これらの行はブログ・サンプル・ページのヘッダーとフッターも呼び出します。サイトには独自のヘッダーとフッターが存在するため、サイトのブログ機能で必要なコードのみをコピーし、独自のヘッダーとフッターはそのまま残します。

<!--main start-->
<div id="main">

<!--header start-->
<%-- <div id="header">
<!--Call header from here-->
</div> --%>

<!--header end container start-->
<div id="container">
<!--Body -->
<%-- Call the container template for the current page subtype --%>
<render:calltemplate
tname='<%=sContainerTName%>'
site='<%=sSite%>'
tid='<%=ics.GetVar("tid")%>'
slotname="BlogBodyContainer"
c='<%=ics.GetVar("c")%>'
cid='<%=ics.GetVar("cid")%>'
ttype="Template">
<render:argument name=p
value='<%=ics.GetVar("p")%>' />
<render:argument name=locale
value='<%=ics.GetVar("locale")%>'/>
<render:argument name=packedargs
value='<%=ics.GetVar("packedargs")%>'/>
<render:argument name=site
value='<%=ics.GetVar("site")%>'/>
<render:argument name=spubid
value='<%=ics.GetVar("spubid")%>'/>
<render:argument name=blogsperpage
value='<%=ics.GetVar("blogsperpage")%>'/>
</render:calltemplate>
</div><!-- End of container -->
</div><!-- End of main -->

<!-- Footer -->
<%-- <div id="footer">
<!--Call footer from here-->
</div> --%>
</body>

6. サイトのレイアウト・テンプレートに挿入したブログ・コードを要件にあわせて再構成します。

7. 他のデフォルト・ブログ・テンプレートおよびCSElementのコードを調べ、該当するセクションを自身のテンプレートおよびCSElementにコピーします。

52.2.3 サイトのSiteEntryアセットへのブログ・パラメータの追加

BlogsコンポーネントのSiteEntryアセットは、一度に1つのWebページ上に表示可能なブログ・アセットの数を指定できるblogsperpageパラメータを指定します。このパラメータはユーザー専用サイトのSiteEntryアセットで指定できます。

注意:

ご使用のサイトのSiteEntryアセットにblogsperpageパラメータを指定しない場合、1ページ当たりのブログ数としてデフォルトの10が使用されます。

カスタムのSiteEntryアセットにblogsperpageパラメータを追加するには:

1. 一般管理者としてAdminインタフェースにログインします。

2. ブログ機能を追加するサイトを選択します。

3. ボタン・バーで「検索」をクリックし、サイトのSiteEntryアセットを検索します。

a. 「検索」フォームで、SiteEntryの検索をクリックします。

b. 「検索」をクリックします。

c. サイトのSiteEntryアセットを選択します。

4. SiteEntryアセットの「調査」フォームで、「編集」をクリックします。

5. 「ページレット・パラメータ」フィールドで、次の項目を追加します。

- 名前: blogsperpageと入力します。

- 値: ページに一度に表示可能なブログの数を入力します。

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

52.3 RSSフィードのURLのカスタマイズ

サンプル・ブログ・ページの右側のナビゲーション・パネルには、RSSフィードのリンクが含まれています。訪問者がRSSフィードのリンクをクリックすると、サンプル・ブログ・ページで公開されているブログ・アセットのタイトルとサマリーの最新のリストがレンダリングされます。訪問者がブログのタイトルをクリックすると、選択されたブログのコンテンツ全体がレンダリングされます。RSSフィードに含まれるブログ・アセットの外部URLは、GetExternalURL CSElementによって作成されます。デフォルトでは、このエレメントはローカルのWebCenter SitesのURLを作成します。

http://<host name>:<port number>/<application context>/<path to file>

<host name>は、RSSフィードのアセットにアクセス可能なWebCenter Sitesインストールのホスト名です。<port number>は、WebCenter Sitesアプリケーションのポート番号です。<application context>は、Blogsコンポーネントが実行されているWebCenter Sitesアプリケーションのコンテキストです。

- ご使用のサイトの外部URLでRSSフィードを使用するには、GetExternalURLエレメントのURL文字列を変更し、表52-1にリストされているパラメータをfuturetense_xcel.iniファイルに追加して、ホスト情報およびサイトのコンテキストの値を設定する必要があります。GetExternalURLエレメントは、futuretense_xcel.iniファイルからこれらのパラメータを読み取ることで、サイトのRSSフィードにリストされているブログ・アセットの外部URLを作成します。

表52-1 GetExternalURLエレメントが外部URLを作成する際に読み取るパラメータ

パラメータ

説明

fwblogs.hostscheme

URL命名構造の最上位レベルを指定します。たとえば、httpと指定します。

fwblogs.hostname

RSSフィードのアセットにアクセス可能なWebCenter Sitesインストールのホスト名を指定します。

fwblogs.portnumber

WebCenter Sitesアプリケーションのポート番号を指定します。

fwblogs.contextinfo

Blogsコンポーネントが実行されているWebCenter Sitesインストールのコンテキストを指定します。

第XIII部 WebCenter Sites: Visitor Servicesの開発

次の項では、Oracle WebCenter Sites: Visitor Servicesの概要を示し、Visitor Servicesの構成について説明します。

- WebCenter Sites: Visitor Servicesの開発

53 WebCenter Sites: Visitor Servicesの開発

Oracle WebCenter Sites: Visitor Servicesでは、訪問者プロファイル情報をフェッチおよびコンパイルし、要求時に提供します。Visitor Servicesプロファイル管理システムを使用して、製品情報やマーケティング・キャンペーンなど、訪問者のニーズに合せてWebサイト・コンテンツを表示します。

Visitor Servicesの詳細は、次の項を参照してください。

- Visitor Servicesの概要

- Visitor Services URLの構成

- アイデンティティ・プロバイダの構成

- アクセス・プロバイダの構成

- 1つ以上のプロファイル・プロバイダの構成

- 1つ以上の集計テンプレートの作成

- Visitor Servicesデータを使用した操作性の最適化

- Visitor Servicesリファレンス

注意:

Visitor Services固有の用語の詳細は、Visitor Servicesの「用語集」を参照してください。

53.1 Visitor Servicesの概要

訪問者のプロファイル情報は、一般に顧客のオンライン・プレゼンス内の様々なシステムで取得されます。ある訪問者が最近、Eloqua電子メールの閲覧、CRMホワイト・ペーパーのダウンロード、またはFacebookやGoogleを介したログインなどを実行した場合が考えられます。各オンライン・アクティビティでは、一連の異なる訪問者属性が収集されます。

Visitor Servicesコンポーネントでは、WebCenter Sitesのターゲット設定に使用可能な検出、集計および問合せ機能が提供されます。訪問者プロファイル情報は、様々なリポジトリから収集され、訪問者プロファイルにリンクされて、集計テンプレートを通して提供されます。組織では、集計済テンプレートを必要な数だけ作成して、選択した属性を様々な訪問者プロファイルから選択し、それらを使用して、WebCenter Sitesの配信ページでコンテンツをターゲット設定できます。

開発者用のVisitor Servicesタスク

Visitor Services構成では、次に示すように、Adminインタフェース「訪問者の管理」ノードで構成される開発者のタスクが主に含まれます。マーケティング担当者の観点からのVisitor Servicesの詳細は、『Oracle WebCenter Sitesの使用』のWebCenter Sites: Visitor Servicesの理解に関する項を参照してください。

開発者タスクは次のとおりです。

- Visitor Services URLを構成する(「Visitor Services URLの構成」を参照)。
WebCenter SitesでVisitor Servicesを構成するには、インストール時に構成されるVisitor Services URLを識別する必要があります。詳細は、『Oracle WebCenter Sitesのインストールと構成』のVisitor Services URLの構成およびVisitor Servicesのデプロイに関する項を参照してください。

- シングル・サインオン(SSO)システム用のアイデンティティ・プロバイダを実装および構成し、Visitor Servicesへのサイト訪問者を認証する。「アイデンティティ・プロバイダの構成」を参照してください。
Visitor Servicesには、Oracle Access Managerと統合できるようにOracle Access Managerアイデンティティ・プロバイダが同梱されています。「カスタム・アイデンティティ・プロバイダの作成: 例」で説明されているように、カスタム・アイデンティティ・プロバイダを作成することもできます。

- プロファイル情報リクエストを認証するようにアクセス・プロバイダを構成する。「アクセス・プロバイダの構成」を参照してください。
アクセス・プロバイダは、アプリケーションとVisitor Services間で行われたRESTコールを認証します。Visitor ServicesとWebCenter Sites間でセキュアな接続を保持するためのアクセス・プロバイダを使用することをお薦めします。

- プロファイル・プロバイダを作成して、訪問者プロバイダをコンパイルおよびエンリッチする。
プロファイル・プロバイダを使用すると、訪問者アイデンティティを訪問者プロファイルに関連付けることができます。Visitor Services内の特定のリポジトリ用のプロファイル・プロバイダを実装および構成し、すべてのプロファイル・プロバイダから訪問者情報を収集するためのエンリッチメント・ルールを作成します。Visitor Servicesには、Eloqua Cloud Marketing Serviceと統合するためのEloquaプロファイル・プロバイダ、Oracle Access Managerと統合するためのOracle Access Managerプロファイル・プロバイダ、およびFacebookプロファイル・プロバイダが同梱されています。「1つ以上のプロファイル・プロバイダの構成」および「プロファイル・プロバイダおよびエンリッチメント・サービスについて」を参照してください。

- 訪問者プロファイルに基づいてサイト訪問者に返されるデータを決定する集計テンプレートを作成する。「1つ以上の集計テンプレートの作成」および「アイデンティティ・プロバイダについて」を参照してください。
集計テンプレートにより、訪問者プロファイルがリンクされ、様々な訪問者プロファイルからの情報を結合できるようになります。開発者は、訪問者プロファイルからのプロファイル情報を欠落する集計ルールおよびタイプを作成します。

- Visitor Servicesからの訪問者プロファイルがどのようにリクエストおよび使用されるかを構成する。
訪問者プロファイルを使用するには、実行時にWebCenter SitesコンポーネントによってVisitor Services API (REST、JAVAまたはJavaScript)を介してこれらがリクエストされる必要があります。Visitor Servicesは、次と統合されます。

- Engage: 訪問者プロファイルを使用して、Engageセグメントを決定し、推奨を提供します。たとえば、マーケティング担当者は、年齢や収入などの訪問者プロファイル属性を使用して、セグメントを作成し、推奨を提供できます。匿名ユーザーについては、サイトへのアクセスに使用されたデバイス、タイムゾーン、ロケール、ブラウザ、リファラ(Facebook、Twitter、Bing)またはIPアドレスなどの属性に基づいてこれらのユーザー用のセグメントを作成します。詳細は、『Oracle WebCenter Sitesの使用』のEngageアセットの使用に関する項を参照してください。

- A/B Testing: セグメントを決定するための訪問者プロファイルを使用し、これらのセグメントを使用してA/Bテスト用の訪問者をターゲット設定します。詳細は、『Oracle WebCenter Sitesの使用』のA/B Testingの使用に関する項を参照してください。

Visitor Services APIリファレンス

- Visitor Services Java API: Visitor Servicesのクライアント開発者がカスタム・アイデンティティ・プロバイダ、アクセス・プロバイダ、およびプロファイル・プロバイダ・インタフェース実装を記述するためのJava APIドキュメントを提供します。

- Visitor Services Client Java API: Oracle WebCenter SitesやEngageなど、Visitor Servicesと通信して訪問者プロファイル情報を取得するアプリケーションの開発者向けのJava APIドキュメントを提供します。

53.2 Visitor Services URLの構成

WebCenter SitesでVisitor Servicesのインスタンスを構成する手順:

1. Adminインタフェースにログインします。

2. ツリーで「管理」ノードを開き、「システム・ツール」ノードを開きます。

3. 「プロパティ管理」ノードをダブルクリックします。

「プロパティ管理ツール」ページが表示されます。

4. 「カテゴリ」ドロップダウン・リストから、「訪問者」を選択して、「検索」をクリックします。

「プロパティ管理ツール」ページの「プロパティ」セクションに、「訪問者」カテゴリのプロパティが移入されます。

5. 「キー」列で、visitors.rest.urlをクリックします。

6. 図53-1に示すように、「値」フィールドに、Visitor ServicesインスタンスのURLをhttp://<visitorserviceshost>:<visitorservicesport>/visitors-webappの書式で入力します。

図53-1 「プロパティ管理ツール」ページの「プロパティ」セクション

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

図53-2に示すように、Visitor Servicesインスタンスが構成されています。

図53-2 「プロパティ」セクションに構成されたvisitors.rest.urlプロパティ

53.3 アイデンティティ・プロバイダの構成

アイデンティティ・プロバイダは、Visitor Servicesへの訪問者認証のステータスを検索します。次のいずれかでアイデンティティ・プロバイダを構成できます。

- Visitor Servicesで提供されているOracle Access Managerアイデンティティ・プロバイダ(OSGiバンドル)を使用して、Oracle Access Manager (OAM)とVisitor Servicesを統合する。「アイデンティティ・プロバイダ設定の構成」および「Oracle Access Manager (OAM)とVisitor Servicesの統合」を参照してください。

- 独自のカスタム・アイデンティティ・プロバイダをOSGiバンドルとして開発して、Visitor Servicesに構成する。「カスタム・アイデンティティ・プロバイダの作成: 例」を参照してください。

Visitor Servicesでは、次のように認証済および未認証の訪問者をサポートすることに注意してください。

- 認証済訪問者: これらの訪問者は、アイデンティティ・プロバイダで認証されます。たとえば、有効なOAMユーザーは、リクエスト・コールでVisitor Servicesに到達するOAMユーザーを識別するために作成された、アイデンティティ・プロバイダによって認証できます。

- 未認証/匿名の訪問者: このタイプの訪問者はサインインしないため、Visitor Servicesには、このユーザーの属性がありません。Visitor Servicesは匿名の訪問者を識別できませんが、クライアント・アプリケーション(WebCenter Sitesなど)がそれらの登録を明示的に決定すると。これらの訪問者は、登録後に認証済訪問者になります。クライアント・アプリケーションは、後で登録できるように属性を保存できます。Webサイトでは、Visitor Servicesが生成した訪問者IDをCookieに格納して、ユーザー・セッションの関連付けに使用します。

53.3.1 アイデンティティ・プロバイダ設定の構成

デフォルトのアイデンティティ・プロバイダを使用するか、独自のプロバイダを作成するかに関係なく、このトピックで説明されているアイデンティティ・プロバイダの設定をAdminインタフェースで設定する必要があります。

アイデンティティ・プロバイダを構成する手順:

1. Adminインタフェースにログインします。

2. ツリーで、「訪問者の管理」ノードを開きます。

3. 「アイデンティティ・プロバイダ」オプションをダブルクリックします。

「アイデンティティ・プロバイダ・リスト」ページが表示されます。

4. 「新規追加」をクリックします。

訪問者アイデンティティ・プロバイダ・フォームが表示されます。

5. 「名前」フィールドに、わかりやすい名前を入力します。

6. 「実装」ボックスで、実装OSGiバンドルを「ファイルをここにドロップします」リージョンにドロップするか、「参照」をクリックしてアップロードします。たとえば、OAMアイデンティティ・プロバイダを構成するには、Visitor Servicesアプリケーションで提供されているOAMIdentityProvider実装を使用します。

7. 「構成」ボックスで、作成するアイデンティティ・プロバイダの構成パラメータを入力します。たとえば、OAMアイデンティティ・プロバイダを構成している場合、パラメータは次のようになります。

- 訪問者アイデンティティ・ヘッダー名: oam.headers.dn=OAM_REMOTE_USER

- アイデンティティ記憶域ヘッダー名: oam.headers.identityStorage=OAM_IDENTITY_DOMAIN

- 匿名訪問者アイデンティティ・ヘッダー値: oam.guest=Anonymous

図53-3 訪問者アイデンティティ・プロバイダ・フォーム

OAMに埋込みのLDAPが停止し、OAM経由のリクエストがVisitor Servicesに到達しない場合、Visitor Servicesアプリケーションは、LDAPが使用不可である旨のレスポンスを返しません。

8. 「保存」アイコンをクリックします。

新しいアイデンティティ・プロバイダは、「アイデンティティ・プロバイダ・リスト」ページに表示されます。

このサイトでアイデンティティ・プロバイダを有効にするには、最初に、左側のAdminツリーの「アイデンティティ・プロバイダ」ノードをダブルクリックして、「アイデンティティ・プロバイダ・リスト」に移動します。次に、有効にするプロバイダの「有効化」ラジオ・ボタンを選択します。サイトで一度に有効にできるアイデンティティ・プロバイダは1つのみです。

53.3.2 Oracle Access Manager (OAM)とVisitor Servicesの統合

この項で説明する手順を実行する前に、Visitor Servicesで提供されているOAMIdentityProviderを構成していることを確認します。OAMアイデンティティ・プロバイダでは、Visitor ServicesがOAMと通信できるようにします。このプロバイダの構成手順は、「アイデンティティ・プロバイダの構成」を参照してください。

この項で説明するOAMとVisitor Servicesの統合後:

- Visitor ServicesでOAMプロファイル・プロバイダを構成します。このプロファイル・プロバイダは、実際のデータをOAM記憶域から取得します。プロファイル・プロバイダの構成手順は、「1つ以上のプロファイル・プロバイダの構成」を参照してください。

- 統合が成功したことを確認します。

注意:

OAMとVisitor Servicesの統合は、標準の実装である必要があります。

OAM Mobile & SocialとVisitor Servicesを統合する手順:

1. OAM管理コンソール(http://host:port/oamconsole)にアクセスします。

2. 図53-4に示すように、「アプリケーション・ドメイン」タブをクリックして、アプリケーション・ドメインを作成します。

図53-4 アプリケーション・ドメイン

3. 保護ポリシーを作成するには、次のようにします。

- 図53-5に示すように、「アプリケーション・ドメイン」ページの「認証ポリシー」タブで、「認証ポリシーの作成」をクリックします。

図53-5 認証ポリシー

- 「認証ポリシー」ページで、「認証スキーム」ドロップダウン・リストから、LDAPSchemaを選択し、OAMでLDAPがAuthenticationModuleとして使用されるようにします。

図53-6 「認証ポリシー」 - 「認証スキーム」

- 「起動パッド」から、「認証モジュール」を開きます。次に、LDAPモジュールに使用されるアイデンティティ記憶域を確認します(Oracle Acceses Managerの管理者ガイドを参照)。この記憶域は、LDAPプロファイル・プロバイダの構成時に使用されます。

4. 「検索」で、「リソース・タイプ」ドロップダウン・リストから「HTTP」を選択して、「検索」をクリックします。次のリソースが検索結果で返されない場合は、それらを追加します。

- /visitors-webapp/rest/*/visitor/current/**の場合は、次のように「保護」を選択します。

- 保護レベル: 非保護

- 認証ポリシー: パブリック・リソース・ポリシー

- 認可ポリシー: 保護リソース・ポリシー

- /visitors-webapp/rest/*/visitor/**の場合は、保護レベルとして「除外」を選択します。

- /visitors-webapp/rest/*/visitor/**の場合は、保護レベルとして「非保護」を選択します。

図53-7 HTTPリソース・タイプ

5. SSOエージェントを作成します。

- 「起動パッド」で、「SSOエージェント登録」をクリックします。

- 「11g Webゲート」を選択します。

- 図53-8に示すように、フォームに入力します。

図53-8 svsSSOAgent

6. Oracle HTTP Server (OHS)を構成します。

a. Enterprise Manager (http://host:port/em)にアクセスします。

b. ナビゲーション・ツリーで「Web層」を開いてから、OHSインスタンスを選択します。

c. 新しい仮想ホストを作成するには、図53-9に示すように、「管理」を選択して、「Oracle HTTP Server」ドロップダウン・メニューから「mod_wl_ohs構成」を選択します。

図53-9 mod_wl_ohs構成

d. 「場所」セクションで、Visitor Servicesホスト、ポートおよびコンテキストを指定します。

e. OHSを再起動します。

7. Mobile and Socialを構成します。:

a. 「起動パッド」から、「ソーシャル・アイデンティティ」を開きます。

b. アプリケーション・ドメインの作成中に指定したものと同じ名前でアプリケーション・プロファイルを作成します。

c. 図53-10に示すように、アプリケーション・ユーザー属性とインターネット・アイデンティティ・プロバイダ・ユーザー属性をマップします。

図53-10 アプリケーション・ユーザー属性とインターネット・アイデンティティ・プロバイダ・ユーザー属性のマッピング

「1つ以上のプロファイル・プロバイダの構成」の説明に従い、プロファイル・プロバイダを構成します。

OAMとVisitor Servicesの統合の確認

1. Visitor Services JavaScriptクライアントを使用して訪問者IDを取得します。この場合、WebCenter Sitesのページはポリシー'protected'によりOAMで保護され、OHS経由でコールできます(これにより、ユーザー・ログインがOAMから要求されます)。ユーザーは、各自の資格証明を指定し、JavaScriptクライアント・コードが存在するページにランディングできます。JavaScriptクライアントによって受信される訪問者IDは、OAM認証済の訪問者IDです。Visitor Servicesのホストとポートではなく、OHS仮想ホストとポートを使用します。OAMIdentityProviderによってリクエストから取得されるため、外部IDは指定しないでください。コールごとに訪問者IDを生成します。

2. 外部ユーザーを使用してVisitor Servicesにログインします。

3. 手順1の説明に従い、訪問者IDを取得します。ユーザーIDは、最初のコールで生成し、コールごとに同じにならないようにする必要があります。

4. 手順3で生成したユーザーに対して、Visitor Services REST APIを使用して、訪問者のリンク済プロファイルの取得を試みます。

53.3.3 カスタム・アイデンティティ・プロバイダの作成: 例

OAMアイデンティティ・プロバイダは、デフォルトでVisitor Servicesで提供されます。この項では、例を利用したカスタム・アイデンティティ・プロバイダの実装について説明します。

次のポイントでは、サンプル・アイデンティティ・プロバイダの実装について説明します。

- すべてのアイデンティティ・プロバイダはOSGiバンドルである必要があり、プロバイダをFelixランタイムに登録するには、このバンドルをプロバイダ実装とアクティベータで構成する必要があります。

- 実装クラスでは、最初にアイデンティティ・プロバイダ・インタフェースを実装してから、プロファイル・プロバイダ・インタフェースを実装する必要があります。アイデンティティ・プロバイダ・インタフェースは、完全に実装された次のメソッドの少なくとも1つを使用して実装する必要があります。

- getVisitorIdentity(String externalId);を特定します

- getVisitorIdentity(HttpServletRequest request);を特定します

- 次の例に示すメソッドでは、アイデンティティ(識別名(dn)のみ)を返し、このアイデンティティは、プロファイル情報をフェッチするためにプロファイル・プロバイダに渡されます。

package com.oracle.sites.visitors.api.providers;

import ...
public interface IdentityProvider
{
String getProviderName();
void setProviderConfig(Properties config);
Identity getVisitorIdentity(HTTPServletRequest request);
}

- アイデンティティ・プロバイダを実装するサンプル・コードを次に示します。この実装では、プロバイダ名およびユーザーdnで構成される外部IDを使用します。

public class SampleIdentityProvider implements IdentityProvider
{
private static final String PARAMETER_EXTERNAL_ID_NAME = "parameter.external_id";
private static final String COOKIE_NAME_ATTRIBUTE_NAME = "cookie.external_id";

@override
public Identity getVisitorIdentity)HttpServletRequest request)
{
String externalId = getExternalIdFromCookie(request);

if (null ==externalId || externalId.isEmpty())
{
externalId = getExternalIdFromParams(request);
}
//Returns an identity object based on external id
return getVisitorIdentity(externalId);
}

システムは、前述で返されたアイデンティティ・オブジェクトでプロファイル・プロバイダをコールします。ユーザーが訪問者IDをリクエストするたびに、将来使用できるように、外部ID (プロバイダおよびdn)がCookieに格納されます。

- OSGiバンドルでは、バンドルに含まれるコードのアクティブ化にアクティベータ・クラスが必要です。サンプル・アイデンティティ・プロバイダを登録できるアクティベータ・クラスを記述します。

public class Activator implements BundleActivator {
/**
* Implements BundleActivator.start(). Prints
* a message and adds itself to the bundle context as a service listener.
* @param context the framework context for the bundle.
**/
public void start(BundleContext context)
{
context.registerService (ProfileProvider.class.getName(),
new SampleProfileProvider(context.getBundle().getLocation()), null);
}

/**
*Implements BundleActivator.stop().Prints a message
*and removes itself from the bundle context as a service listener.
*@param context the framework context for the bundle.
**/
public void stop(BundleContext context)
{
}
}

- 「アイデンティティ・プロバイダの構成」で説明されている次の手順に従い、アイデンティティ・プロバイダを構成します。

53.4 アクセス・プロバイダの構成

アクセス・プロバイダでは、どのアプリケーションで訪問者プロファイルから情報にアクセスできるかを制御します。アクセス・プロバイダ・サービスは、RESTクライアントと組み合せて機能します。たとえば、コンテナ保護認証の場合、Visitor Servicesの基本認証設定でアクセス・プロバイダ・バンドルをアップロードし、同じ認証タイプをRESTクライアントで設定する必要があります。詳細は、「アクセス・プロバイダ・リファレンス」を参照してください。

Visitor Servicesには、LDAPディレクトリに対する認証を行うために基本的なLDAPアクセス・プロバイダが同梱されています。

この項の手順に従い、アクセス・プロバイダとVisitor Servicesを一緒に使用できるようにします。

アクセス・プロバイダを構成する手順:

1. Adminインタフェースにログインします。

2. ツリーで、「訪問者の管理」ノードを開きます。

3. 「アクセス・プロバイダ」オプションをダブルクリックします。

「アクセス・プロバイダ・リスト」ページが表示されます。

4. 「新規追加」をクリックします。

図53-11に示すように、訪問者アクセス・プロバイダ・フォームが表示されます。

図53-11 訪問者アクセス・プロバイダ・フォーム

5. 「名前」フィールドに、わかりやすい名前を入力します。

6. 「実装」ボックスで、実装OSGiバンドル(例: ContainerBasicAccessProvider)を「ファイルをここにドロップします」リージョンにドロップするか、「参照」をクリックしてアップロードします。

アクセス・プロバイダは、Visitor Servicesで必要となるファイルを含むOSGiバンドルです。このOSGiバンドルは、Visitor Servicesと目的の記憶域の間で必要となる通信の実際のJavaベースの実装です。アクセス・プロバイダOSGiバンドルは、次で構成されます。

- Activatorクラス: OSGiフレームワークのエントリ・ポイントです。

- MANIFEST.mfファイルとOSGiヘッダー(表53-1を参照)。

表53-1 MANIFEST.mfファイル内のOSGiヘッダー

ヘッダー名

説明

Bundle-Name

アクセス・プロバイダの名前。

Bundle-SymbolicName

com.sample

Bundle-Description

アクセス・プロバイダの説明

Bundle-ManifestVersion

1

Bundle-Version

1.0.0

Bundle-Activator

com.sample.Activator

Import-Package

org.osgi.framework;version=4.2.1,org.json、com.oracle.sites.visitors.api.providers、com.oracle.sites.visitors.api.providers.beans

- 構成ファイルの名前は同じ(accessProviderConfig.properties)にする必要があります。このファイルには、アクセス・プロバイダの現在の実装に必要なプロパティのkey=valueのペアが含まれている必要があります。構成ファイルは、空白の場合でも常にOSGiバンドルに存在する必要があります。

7. 「構成」ボックスで、作成するアクセス・プロバイダの構成を入力します。たとえば、ContainerBasicAccessProviderの場合は、role=role Configured In Container for Visitors Servicesを入力します。
Sitewrapperapiが使用されている場合は、wcsites.visitors.auth.password、visitors.rest.authalias、visitors.rest.authtype、visitors.rest.authheaderのプロパティをプロパティ管理ツールで設定する必要もあります。

8. 「保存」アイコンをクリックします。
新しいアクセス・プロバイダは、訪問者アクセス・プロバイダ・ページに表示されます。

9. このサイトでこのアクセス・プロバイダを有効にするには、最初に、左側のAdminツリーの「アクセス・プロバイダ」ノードをダブルクリックして、「アクセス・プロバイダ・リスト」に移動します。次に、有効にするプロバイダの「有効化」ラジオ・ボタンを選択します。サイトで一度に有効にできるアクセス・プロバイダは1つのみです。

53.5 1つ以上のプロファイル・プロバイダの構成

プロファイル・プロバイダを使用すると、訪問者アイデンティティを訪問者プロファイルに関連付けることができます。Visitor Servicesには、Eloquaと統合するためのEloquaプロファイル・プロバイダ、Oracle Access Managerと統合するためのOracle Access Managerプロファイル・プロバイダ、およびサンプル・プロファイル・プロバイダが同梱されています。詳細は、「プロファイル・プロバイダ・リファレンス」を参照してください。

次の方法でプロファイル・プロバイダを構成できます。

- Visitor Servicesで提供されているEloquaを使用する。「Eloquaプロファイル・プロバイダの構成について」を参照してください。

- Visitor Servicesで提供されているOracle Access Managerプロファイル・プロバイダ(OSGiバンドル)を使用する。「プロファイル・プロバイダ設定およびエンリッチメント・ルールの構成」を参照してください。

- 独自のカスタム・プロファイル・プロバイダをOSGiバンドルとして開発して、Visitor Servicesに構成する。「カスタム・プロファイル・プロバイダの作成: 例」を参照してください。

注意:
プロファイル・プロバイダの属性を設定したら、その名前を変更しないでください。

53.5.1 プロファイル・プロバイダ設定およびエンリッチメント・ルールの構成

プロファイル・プロバイダおよびエンリッチメント・ルールを構成する手順:

1. Adminインタフェースにログインします。

2. ツリーで、「訪問者の管理」ノードを開きます。

3. 「プロファイル・プロバイダ」オプションをダブルクリックします。

図53-12に示すように、「プロファイル・プロバイダ・リスト」ページが表示されます。

図53-12 プロファイル・プロバイダ・リスト

4. 「新規追加」をクリックします。

訪問者プロファイル・プロバイダ・フォームが表示されます。

5. 「名前」フィールドに、構成するプロファイル・プロバイダのわかりやすい名前を入力します。OAMアイデンティティ・プロバイダの場合は、プロファイル・プロバイダの名前と埋込みLDAPストアの名前が同じになるようにしてください。

6. 「実装」フィールドの横の「参照」をクリックして、プロファイル・プロバイダOSGiバンドルをアップロードします。LDAPが使用されている場合は、Visitor Servicesで提供されているLDAPプロファイル・プロバイダをアップロードし、それ以外の場合は、カスタム実装を使用します。

プロファイル・プロバイダOSGiバンドルは、次で構成されます。

- Activatorクラス: OSGiフレームワークのエントリ・ポイントです。

- MANIFEST.mfファイルとOSGiヘッダー(表53-2を参照)。

表53-2 MANIFEST.mfファイル内のOSGiヘッダー

ヘッダー名

説明

Bundle-Name

プロファイル・プロバイダの名前。

Bundle-SymbolicName

com.sample

Bundle-Description

プロファイル・プロバイダの説明

Bundle-ManifestVersion

1

Bundle-Version

1.0.0

Bundle-Activator

com.sample.Activator

Import-Package

org.osgi.framework;version=4.2.1,org.json、com.oracle.sites.visitors.api.providers、com.oracle.sites.visitors.api.providers.beans

- 構成ファイルの名前は同じ(profileProviderConfig.properties)にする必要があります。このファイルには、プロファイル・プロバイダの現在の実装に必要なプロパティのkey=valueのペアが含まれている必要があります。構成ファイルは、ファイルが空白の場合でも常にOSGiバンドルに存在する必要があります。

7. 「構成」ボックスで、プロファイル・プロバイダの構成パラメータを入力します。LDAPプロファイル・プロバイダを使用している場合は、表53-3を参照してください。

表53-3 LDAPプロファイル・プロバイダの構成パラメータ

パラメータ

値

LDAPアドレス

書式: ldap://<host>:<port>/。

ユーザーの基本識別名

BaseUserDN=cn=Users,dc=com

管理者(admin)の識別名

AdminDN=cn=admin,dc=com

パスワード

管理者(admin)のパスワード。AdminPassword=password

ユーザー・ログイン名として使用されるLDAP属性

デフォルトはuidです。LoginUserAttribute=uid。

サポートされているLDAP objectClasses

ObjectClasses=top;inetOrgPerson

LDAPプロファイル属性

ProfileAttributes=cn,sn,displayName,mail,title,givenName,name

図53-13 訪問者プロファイル・プロバイダ・フォーム

8. 「エンリッチメント・ルール」ボックスで、訪問者プロファイルに適用するエンリッチメント・ルールを入力します。エンリッチメント・ルールには、訪問者プロファイルを定義するルールが含まれます。これらのルールは、様々な記憶域で使用可能な複数の訪問者プロファイル、およびVisitor Servicesによって収集され、アプリケーションに提供される、訪問者データに顧客が追加する任意の属性に基づいています。

LDAP、CRMおよびEloquaプロファイル・プロバイダのエンリッチメント・ルールを構成するには、LDAPプロファイラ・プロバイダで使用されるdnがCRMプロファイル・プロバイダのnameと同じである必要があり、CRMプロファイル・プロバイダにはemail属性、Eloquaプロファイル・プロバイダにはId属性が含まれます。したがって、エンリッチメント・プロセスを実行できるようにするには、プロファイル・プロバイダを次のように構成する必要があります。

- dn=CRM:nameのエンリッチメント・ルールをLDAPプロファイル・プロバイダに追加します。

- 次のエンリッチメント・ルールをCRMプロファイル・プロバイダに追加します。

- name=LDAP:dn

- Id=ELOQUA:Id

- Id属性に基づいて、Eloquaプロファイル・プロバイダのエンリッチメント・ルールを記述できます。例:
LDAPのEloquaエンリッチメント・ルール:

Id=eloqua:Id

不明のプロファイル・プロバイダのEloquaエンリッチメント・ルール:

dn=eloqua:id

次を考慮してください。

- LDAPプロファイル・プロバイダの場合、OAMに埋込みのLDAPは、homePhone、employeetype、departmentnumber、homepostaladdress、c、l、employeenumberなどの一部の属性の検索をサポートしていません。したがって、これらの属性に基づいたエンリッチメント・ルールは機能しない場合があります。

- Oracle Virtual Directoryの検索機能では、ASCII文字を使用する属性のみをサポートしています。

9. 「保存」アイコンをクリックします。

新しい行がプロバイダ表に作成されます。Visitor Servicesログが更新され、新しいプロバイダが追加されたことを確認できます。

新しいプロファイル・プロバイダは、「プロファイル・プロバイダ・リスト」ページで編集できます(図53-12)。

10. このプロファイル・プロバイダを有効にするには、最初に、左側のAdminツリーの「プロファイル・プロバイダ」ノードをダブルクリックして、「プロファイル・プロバイダ・リスト」に移動します。次に、有効にするプロバイダの「有効化」チェック・ボックスを選択します。複数のプロファイル・プロバイダを同時に有効にできます。

53.5.1.1 Eloquaプロファイル・プロバイダの構成について

Eloquaプロファイル・プロバイダを使用するには、次を実行する必要があります。

1. 「プロファイル・プロバイダ設定およびエンリッチメント・ルールの構成」に説明されている手順に従い、Eloquaのプロファイル・プロバイダを作成します。
Eloquaプロバイダ・インスタンスの詳細を「構成」ボックスに入力していることを確認します。

例:

###################################################################################################
#### ELOQUA SETTINGS
###################################################################################################

## Auth Settings
#######################################
#
# Client's Company name
#
company = OraclePOC

#
# Client's user name
#
user =  username

#
# Client's user password
#
password =  password

## Proxy Settings
#######################################
#
# Use proxy in provider
#
useProxy = true

#
# Proxy server host
#
proxyHost = www-proxy.us.oracle.com

#
# Proxy server port
#
proxyPort = 80

#
# Proxy server type
# This can be "DIRECT", "HTTP", or "SOCKS"
#
proxyType = HTTP

## Search Settings
#######################################
#
# Eloqua REST URL
#
restUrl = https://secure.eloqua.com/API/REST/1.0

#
# Depth or level of visitor detail returned.
# This can be "minimal", "partial", or "complete".
#
searchDepth = partial

2. Eloquaプロファイル・プロバイダを有効にするには、最初に、左側のAdminツリーの「プロファイル・プロバイダ」ノードをダブルクリックして、「プロファイル・プロバイダ・リスト」に移動します。次に、Eloquaプロファイル・プロバイダの「有効化」チェック・ボックスを選択します。

注意:
Eloquaでは、電子メール・ベースの検索をサポートしていません。したがって、Eloquaの電子メール・フィールドに基づいたエンリッチメント・ルールは機能しません。サポートされるのは、IDベースの検索のみです。EloquaのユーザーIDが識別され、プロファイル・プロバイダが訪問者プロファイルの詳細をフェッチできるように、アイデンティティ・プロバイダが構成されていることを確認します。

53.5.2 カスタム・プロファイル・プロバイダの作成: 例

Visitor Servicesには、LDAPプロファイル・プロバイダ、Eloquaプロファイル・プロバイダおよびサンプル・プロファイル・プロバイダがパッケージされています。次のポイントでは、カスタムCSVプロファイル・プロバイダの実装について説明します。

- すべてのプロバイダはOSGiバンドルである必要があり、プロバイダをFelixランタイムに登録するには、このバンドルをプロバイダ実装とアクティベータで構成する必要があります。

- 実装クラスでは、最初にアイデンティティ・プロバイダ・インタフェースを実装してから、プロファイル・プロバイダ・インタフェースを実装する必要があります。

- 次の例に示すプロファイル・プロバイダ・メソッドは、プロファイル情報をフェッチします。

public interface ProfileProvider
{
String getProviderName();
RawProfile getProfile(String dn);
List<RawProfile> search(String attribute, String value);
void setProviderConfig(Properties config);

- サンプル・プロファイル・プロバイダを登録できるアクティベータ・クラスを記述します。

public class Activator implements BundleActivator {
/**
* Implements BundleActivator.start(). Prints
* a message and adds itself to the bundle context as a service listener.
* @param context the framework context for the bundle.
**/
public void start(BundleContext context)
{
context.registerService (ProfileProvider.class.getName(),
new SampleProfileProvider(context.getBundle().getLocation()), null);
}

/**
*Implements BundleActivator.stop().Prints a message
*and removes itself from the bundle context as a service listener.
*@param context the framework context for the bundle.
**/
public void stop(BundleContext context)
{
}
}

- 次のサンプル実装では、アイデンティティ・オブジェクトに渡されるdnを使用して、未加工のプロファイル情報を取得できます。プロファイルは*.csvファイルからロードされます。

ID,Name,Email,Address,Country,City
1,Alek,Alek.Z@mycompany.com,Kyiv,Ukraine,Kyiv
2,Avi,avi.n@mycompany.com,Gachibowli,India,Hyderabad
3,Joe,Joe.d@mycompany.com,Miyapur,India,Hyderabad
4,Reva,reva.p@mycompany.com,Kukatpally,India,Hyderabad

@Override
public RawProfile getProfile(String dn) {
List<CSVProfile> profiles = csvManager.getProfiles();
CSVProfile selected = null;
for (CSVProfile p : profiles) {
if (p.getName().equalsIgnoreCase(dn)) {
selected = p;
break;
}
}

if (selected == null)
return null;
RawProfile rawProfile = new RawProfile();
rawProfile.setUserId(selected.getId());
rawProfile.setProviderId(getProviderName());
rawProfile.setAttributes (getAttributes (selected));
return rawProfile;
}

private JsonObject getAttributes(CSVProfile csvProfile)
{
JsonObject attributes = new JsonObject();

attributes.addProperty("email", csvProfile.getEmail());
attributes.addProperty("address", csvProfile.getAddress());
attributes.addProperty("country", csvProfile.getCountry());
attributes.addProperty("city", csvProfile.getCity());
return attributes;
}

- サンプル・プロファイル・プロバイダを登録できるアクティベータ・クラスを記述します。

public class Activator implements BundleActivator {
@Override
public void start(BundleContext bundleContext) throws Exception {
bundleContext.registerService(ProfileProvider.class.getName(),
new CSVProfileProvider(bundleContext.getBundle().getLocation()), null);
}

@Override
public void stop(BundleContext bundleContext) throws Exception {

}
}

- 「1つ以上のプロファイル・プロバイダの構成」で説明されている手順に従い、プロファイル・プロバイダを構成します。

53.6 1つ以上の集計テンプレートの作成

集計テンプレートにより、訪問者のプロファイルに基づいて、サイトの訪問者に返されるデータが決定します。たとえば、集計テンプレートをEngageからコールして、推奨に使用する属性を特定できます。集計テンプレートは、VelocityまたはJavaScriptを使用して作成できます。

詳細は、「集計テンプレート・リファレンス」を参照してください。

集計テンプレートを構成する手順:

1. Adminインタフェースにログインします。

2. ツリーで、「訪問者の管理」ノードを開きます。

3. 「集計テンプレート」オプションをダブルクリックします。

図53-14に示すように、「集計テンプレート・リスト」ページが表示されます。

図53-14 集計テンプレート・リスト

4. 「新規追加」をクリックします。

訪問者集計テンプレート・フォームが表示されます。

5. 「名前」フィールドに、構成するテンプレートのわかりやすい名前を入力します。

6. 「言語」フィールドで、Velocityまたは「JavaScript」のいずれかを選択します。

7. 「テンプレート」ボックスで、集計テンプレート・コードを入力します。次の例に、複数のプロファイル記憶域から訪問者情報をまとめたサンプルの集計テンプレートを示します。このサンプルはVelocityコードです。

集計テンプレートを作成するためのサンプルのVelocityコード

#set( $sn ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).sn} != "null")
#set( $sn = ${profiles.LDAPProfileProvider.get(0).sn.getAsString()})
#end

#set( $displayName ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).displayName} != "null")
#set( $displayName = ${profiles.LDAPProfileProvider.get(0).displayName.getAsString()})
#end

#set( $mail ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).mail} != "null")
#set( $mail = ${profiles.LDAPProfileProvider.get(0).mail.getAsString()})
#end

#set( $homePhone ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).homePhone} != "null")
#set( $homePhone = ${profiles.LDAPProfileProvider.get(0).homePhone.getAsString()})
#end

#set( $name ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).name} != "null")
#set( $name = ${profiles.LDAPProfileProvider.get(0).name.getAsString()})
#end

#set( $description ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).description} != "null")
#set( $description = ${profiles.LDAPProfileProvider.get(0).description.getAsString()})
#end

#else
#set( $otherProvider = "other profile provider used.")
#end

#if (${profiles.has("LDAPProfileProvider")})
{
"Name ": "$name",
"displayName ": "$displayName",
"description ": "$description",
"sn ": "$sn",
"mail ": "$mail",
"homePhone ": "$homePhone"
}
#else
{
"otherProvider ": "$otherProvider"
}
#end

次の例に、複数のプロファイル記憶域から訪問者情報をまとめたサンプルの集計テンプレートを示します。このサンプルは、前述のVelocityコードと同じように機能するJavaScriptコードです。

集計テンプレートを作成するためのサンプルのJavaScriptコード

function aggregate()
{
var result={};
if(profiles.get("LDAPProfileProvider"))
{
var NOT_PROVIDED_LABEL = "Not Provided";
var internalAttrs = JSON.parse(profiles.get("LDAPProfileProvider").get(0).getAttributes());

result.Name = internalAttrs.name || NOT_PROVIDED_LABEL;
result.displayName = internalAttrs.displayName || NOT_PROVIDED_LABEL;
result.description = internalAttrs.description || NOT_PROVIDED_LABEL;
result.sn = internalAttrs.sn || NOT_PROVIDED_LABEL;
result.mail =internalAttrs.mail || NOT_PROVIDED_LABEL;
result.homePhone = internalAttrs.homePhone || NOT_PROVIDED_LABEL;

}
else
{
result.otherProvider = "other profile provider used.";
}
return result;
}

図53-15 訪問者集計テンプレート・フォーム

8. 「保存」アイコンをクリックします。

新しい集計テンプレートは、「集計テンプレート」ページに表示されます(図53-14)。

53.7 Visitor Servicesデータを使用した操作性の最適化

操作性を最適化するには、拡張属性およびアクティビティを使用して、訪問者の複数のプロファイルから訪問者情報を取得します。Visitor ServicesとEngageを統合して、訪問者情報をEngageに提供することもできます。WebCenter Sitesでは、ページ作成者がこの情報を使用して、セグメントと推奨を設計し、関連するコンテンツを対象ユーザーに表示します。マーケティング担当者は、Visitor Servicesデータをターゲット設定、テストおよび分析に使用できます。

訪問者情報のリクエストには、次の2つの手順が含まれます。

- 訪問者IDをリクエストする。

- 指定した集計テンプレートを使用して、訪問者プロファイルをリクエストする。
集計済テンプレートと指定した属性を返します。

この項には次のトピックが含まれます:

- WebCenter SitesコンポーネントでのVisitor Servicesプロファイル情報のリクエスト方法

- EngageでのVisitor Servicesの構成

- 拡張属性およびアクティビティの追加情報の格納

53.7.1 WebCenter SitesコンポーネントでのVisitor Servicesプロファイル情報のリクエスト方法

Visitor ServicesとWebCenter Sitesなどのクライアント・アプリケーション間の通信を有効にするために、Visitor Servicesでは、Visitor Servicesをヒットするためにクライアント・アプリケーションで実行されるクライアントAPI (JavaおよびJavaScript)を提供しています。Visitor Servicesでは、サーバー側およびクライアント側のJavaScript用のJavaクライアントをデフォルトで提供しています。Javaクライアントは、Visitor Servicesおよびアプリケーションがサーバー側からプロファイル情報にアクセスしようとした場合に使用されます。JavaScriptクライアントAPIは、訪問者がブラウザからアプリケーションを使用して、Visitor Servicesと通信しようとした場合に使用されます。JavaクライアントAPIとJavaScriptクライアントAPIの違いは、JavaクライアントAPIが、WebCenter Sitesのサーバー側コードなど、信頼できるアプリケーション内部で実行することを想定していることです。したがって、これらのアプリケーションには、訪問者データに対する一部の機密操作(更新操作)を処理する前に、訪問者自身の認証に使用可能な資格証明が含まれます。JavaScriptクライアントはブラウザの内部で実行されるため、十分にセキュリティ保護されません。したがって、現在の訪問者の情報の読取りしかできないようになっています。Visitor Servicesでは、信頼できるアプリケーションにすべての訪問者のプロファイルの情報を提供します。訪問者には、自身の情報のみが提供されます。

JavaおよびJavaScriptクライアントAPIには、これらの関数が共通して含まれます。ただし、JavaScriptの場合、この関数は現在/ログインしている訪問者を対象にします。

- GetVisitorId: SSOソリューションに格納されている外部IDを使用して、訪問者のIDをVisitor Servicesから取得します。JavaScript APIでは、この関数はGetCurrentVisitorIdと呼ばれます。現在のユーザーの訪問者IDをVisitor Servicesから取得します。

- GetAggregatedProfile: 既存の訪問者のIDを使用して、集計済プロファイルをVisitor Servicesから取得します。JavaScript APIでは、この関数はGetCurrentAggregatedProfileと呼ばれます。現在のユーザーの集計済プロファイルをVisitor Servicesから取得します。
0日から任意の正数(1 = 1日)でプロファイルの有効期間を設定できます。有効期間により、外部記憶域からフェッチしたプロファイル情報リフレッシュされるまで、この情報がVisitor Services内に保持される日数が決定されます。有効期間を指定しない場合、プロファイル情報はリフレッシュされません。「一般構成」ページ(「訪問者の管理」ノードの「一般構成」ノードからアクセス)には、プロファイル更新期間構成が表示されます。この情報を編集して、有効期間を設定します。

- IsExists: 訪問者IDがデータベースに存在するかどうかを確認します。ゲストまたは一部のプロファイルが登録されたユーザーが存在しているかどうかに関係なく、訪問者IDがデータベースに存在している場合は、レスポンスがtrueになります。JavaScript APIでは、この関数はIsCurrentExistsと呼ばれます。訪問者IDがデータベースに存在するかどうかを確認します。ゲストまたは一部のプロファイルが登録されたユーザーがデータベースに存在しているかどうかに関係なく、訪問者IDがデータベースに存在している場合は、レスポンスがtrueになります。

- IsGuest: 訪問者のプロファイルがデータベースにないことを確認します。訪問者情報が存在するかどうかに関係なく、いずれの場合も、レスポンスがtrueになります。JavaScript APIでは、この関数はIsCurrentGuestと呼ばれます。このゲスト訪問者の訪問者プロファイルがデータベースに存在しないことを確認します。ゲスト訪問者がデータベースに格納されているかどうかに関係なく、いずれの場合も、レスポンスがtrueになります。

Javaクライアントはサーバーで実行されますが、JavaScriptはWebブラウザから実行されます。両方のURLは、構造が異なります。例:

- 信頼できるアプリケーションに対するJava REST関数: http://visitorserviceshost:visitorservicesport/visitors-webapp/rest/v1/visitor/id/690b507b-efb6-4c35-9e6e-0c9f2a28b37d/profile/aggregated/arrg
このURLでは、id/690b507b-efb6-4c35-9e6e-0c9f2a28b37dになることに注意してください。これは、指定した訪問者ID (次のポイントに示すように、ログインしている訪問者のcurrentがその場所で使用されます)。

- 信頼できない訪問者に対するJavaScript REST関数: http://visitorserviceshost:visitorservicesport/visitors-webapp/rest/v1/visitor/current/profile/aggregated/arrg
前述のURLでは、訪問者IDパスがcurrentコンテキスト(信頼できない訪問者は自身の情報しか参照できないことを示す)で置き換えられます。信頼できない顧客に対するすべてのRESTコールには、currentコンテキストが含まれます。

すべてのアプリケーションがOAMにデプロイされると、Oracle HTTP Protectionが「除外」セキュリティ・タイプに設定されます。データがすでに準備されているプロファイル情報をクライアント・アプリケーションがリクエストすると、Visitor Services JavaクライアントAPIの送信リクエスト(準備済のデータがこれらのアプリケーションに提供されます)をVisitor Servicesの独自の保護によって保護できます。

- コンテナ保護: ユーザーに関するすべての情報はコンテナ記憶域に格納され、Visitor Servicesはユーザーのロールのみをチェックします。クライアントのWebサーバーで基本認証が可能な場合は、コンテナ保護を使用することをお薦めします。

- Visitor Services保護: クライアントのWebサーバーが基本認証メカニズムをサポートしていない場合は、Visitor Services保護を使用します。

Visitor Services APIを使用して独自のアクセス・プロバイダを実装して、Adminインタフェースでプロバイダをアップロードすることもできます。

注意:updatedパラメータ・セットをfalseに設定して、集計済またはリンク済プロファイルのリクエストが処理されると、期限切れのプロファイルに対するVisitor Servicesの動作は次のようになります。

- Visitor Services用に構成されたJMS: 現在のリクエストで古いプロファイル・データが返され、その間にVisitor Servicesがプロファイルをバックグラウンドで更新して、プロファイル・データを随時リフレッシュします。

- Visitor Services用に更新されていないJMS: バックグランド処理機能はJMSに依存しているため、更新されたプロファイルをリクエスト・コールで返します。

各アプリケーションには、REST APIにアクセスするための独自の資格証明をそれぞれ含めることをお薦めします。Visitor Servicesは、このアクセスを自身で確認します。信頼できないアプリケーションのVisitor Services REST APIは、SSOによってセキュリティ保護され、OAMでは、保護レベルが「非保護」に設定されます。Visitor Servicesには、保護されているRESTリソースはありません。コンテナ保護を使用することをお薦めします。

Visitor Servicesの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

53.7.2 EngageでのVisitor Servicesの構成

Visitor ServicesとEngageを統合し、セグメントと推奨に使用できるように、訪問者情報を収集してEngageに提供できます。WebCenter Sitesでは、ページ作成者がこの情報を使用して、セグメントと推奨を設計し、関連するコンテンツを対象ユーザーに表示します。Visitor Servicesからプロファイル情報を取得するために、開発者またはページ作成者は、訪問者情報を収集して属性として格納されるように設計された、訪問者属性フォームの「値ソース」フィールドを使用します。

1. プロパティ管理ツールで、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』に説明されているVisitor Servicesプロパティが設定されていることを確認します。

2. AdminインタフェースのVisitor Servicesノードで、推奨またはセグメン分けに使用する集計テンプレートを構成します。「1つ以上の集計テンプレートの作成」を参照してください。

3. Contributorインタフェースで、式言語(EL)を使用して集計済テンプレートのデータを参照し、訪問者属性の値を移入することで、訪問者属性フォームの「値ソース」フィールドを構成します。訪問者属性は、セグメント分けと推奨の評価に使用されます。たとえば、「値ソース」フィールドのEL式は、${Agg_Temp.Address.PostalCode},${AnotherAggregatedTemplate["My City"].ZipCode}のようになります(Agg_Tempは、訪問者の住所、街路番号/名前および家の住所を収集する集計済テンプレート、AnotherTemplateは、2番目の集計済テンプレートを識別、My Cityは、訪問者が居住している都市、Zip Codeは、その都市の郵便番号)。ELの詳細は、https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.htmlを参照してください。

4. 推奨リーダーAPIで、集計テンプレートで設定されたものと同じ属性が含まれる実装オブジェクトを作成します。実行中、推奨リーダーAPIはVisitor Servicesと対話して、次のメソッドを使用して、集計済テンプレートを取得します。

- readSegments: 提供または計算されたユーザーの訪問者属性を評価した後に、ユーザーが属するEngageセグメントを決定します。このメソッドでは、マップ・アイテムのキー/値のペアがセグメントを示すマップ・アイテムのリストを返します。

- retainSegments: 提供または計算されたユーザーの訪問者属性を評価した後に、指定したセグメントのユーザーのメンバーシップを決定します。このメソッドでは、マップ・アイテムのキー/値のペアがセグメントを示すマップ・アイテムのリストを返します。このメソッドは、readSegmentsメソッドと似ていますが、使用可能なすべてのセグメントではなく、指定したセグメントのリストのみが考慮されます。

- readRecommendations: 提供または計算されたユーザーの訪問者属性に基づいて、指定されたEngage推奨を評価します。このメソッドでは、マップのキー/値のペアが、推奨によって生成されるアセットを示すマップ・アイテムのリストを返します。

5. readSegments、retainSegments、およびreadRecommendations APIは、コールの送信に使用されるメタデータがVisitor Servicesから取得された場合に、svsvisitorid Cookieを設定します。Visitor Servicesを使用せずにセグメントまたは推奨を計算できる場合、Cookieは設定されません。ユーザーがVisitor Servicesにログインしていない場合、svsvisitoridはゲストIDに設定されます。このゲストIDは、後続のセグメントまたは推奨の計算コールに使用されます。ユーザーがログインしている場合、開発者は正しいsvsvisitorid Cookieをそのユーザーに設定する必要があります。同様に、ユーザーがログアウトすると、svsvisitorid Cookieのリセットが必要になる場合があります。

53.7.3 訪問者プロファイルのリンク付けおよびCookieの管理

oracle.fatwire.integrations.svs.VisitorServiceHelperクラスを使用して、現在の訪問者のプロファイル情報を取得し、訪問者のCookieライフ・サイクルを管理できます。

Webサイトに「ホーム」ページと「マイ・アカウント」ページがあるとします。訪問者が、Visitor Servicesアイデンティティ・プロバイダ・サービスを使用して「ホーム」ページにログインしていない場合、ページ内部のヘルパーAPIコード(helper.getProfile(ics,aggregationTemplateName,..))がブラウザのゲストIDをCookieとして設定します。(ゲストIDにはプロファイル情報がないことに注意してください。)「マイ・アカウント」ページへのリンクが認証メカニズムで保護されており、「マイ・アカウント」ページにアクセスする前に、アイデンティティ・プロバイダ・サービスを使用して訪問者がログインしている場合、その訪問者は認証済訪問者になります。ただし、ヘルパーAPIは「ホーム」ページのブラウザCookieにすでにゲストIDを設定しているため、「マイ・アカウント」ページ・コード内でupdateNowパラメータをtrue (helper.getProfile(ics,aggregationTemplateName,true))として渡すことで、ブラウザのCookieを更新する必要があります。Cookieが更新されていない場合、「マイ・アカウント」ページは認証済訪問者IDと関連のプロファイル情報を受け取らず、Cookieからゲスト訪問者IDを使用し続けます。

この例では、「マイ・アカウント」ページで次のコードを使用します。

VisitorServiceHelper helper = VisitorServiceHelper.getInstance();
Helper. getProfile(ics,<someAggregationTemplateName>,true);

前述のコードでは、ブール・パラメータのtrue値は次のようになります。

- ブラウザCookieからの訪問者IDがNULLの場合、訪問者が認証済ページに直接ランディングしたことを示します。それ以外の場合は、ゲストIDになり、IDがVisitor Servicesに存在せず、ローカル・ブラウザのみにキャッシュされたことを示します。この場合は、新しい訪問者IDを生成して、Cookieの値を置き換えます。

- Cookieからの訪問者IDがVisitor Servicesに存在する場合は、Cookieが2つのIDをリンクするため、このIDを使用し続けます。これは、CookieのゲストIDが「マイ・アカウント」ページで使用される前に、明示的に登録されると発生します。「ホーム」ページのコードは、このAPIをコールするか(ブール・パラメータをfalseとして渡す)か、2つのパラメータ(ヘルパー、getProfile(ics,<someAggregationTemplateName>)、このパラメータはデフォルトでfalseと想定)のみを指定する別のメソッドをコールします。

53.7.4 拡張属性およびアクティビティの追加情報の格納

この項では、拡張属性およびアクティビティと、それらがVisitor Servicesでどのように機能するかについて説明します。この項には、次の項目が含まれます。

- 拡張属性およびアクティビティについて

- Visitor Servicesで拡張属性およびアクティビティを使用する方法

53.7.4.1 拡張属性およびアクティビティについて

拡張属性は、言語、ロケール、性別などの訪問者の特性に基づきます。拡張属性は、訪問者ID別に訪問者に関連付けられ、名前および値が含まれます。これらの属性は、アプリケーションに固有です。アプリケーションの承認により、これらの属性はVisitor Servicesに格納され、他のアプリケーションによって使用されます。たとえば、Engageからの拡張属性が承認されると、他のアプリケーションで使用できます。

拡張アクティビティは、Webサイト上での訪問者のアクティビティに基づきます。たとえば、ページを開く、検索の実行、入札など、アクティビティは訪問者ID別に関連付けられ、タイプ、データ、タイムスタンプおよび評価が含まれます。これらのアクティビティは、アプリケーションに固有です。アプリケーションの承認により、これらのアクティビティはVisitor Servicesに格納され、他のアプリケーションによって使用されます。

拡張アクティビティおよび属性は、訪問者のすべてのプロファイルから収集されます。つまり、訪問者に複数のリンク済プロファイルがある場合、get rated(latest)関数はすべてのプロファイルで同じ結果を返します。

Javaクライアントを使用したRESTでのアクティビティの追加: 例

VisitorsClient client = new VisitorsClient(..);
Map<String,String> acts = new HashMap<>();
acts.put("product", " dell v560"); // type,data
acts.put("catalog", " laptops");
acts.put("web_page", "http://online.store.com/dell/v560");
client.addActivity("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", acts);

Javaクライアントを使用したRESTでのアクティビティの取得: 例

can get activities using two types:
getRated: fetches most rated activities
getLatest: fetches latest activities

getRated Method:
VisitorsClient client = new VisitorsClient(..);
List<Activity> res = client.getRated("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);

getLatest Method:
VisitorsClient client = new VisitorsClient(..);
List <Activity>res = client.getLatest("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);

5 - count. How many activities are needed

Javaクライアントを使用したRESTでの拡張属性の追加: 例

VisitorsClient client = new VisitorsClient(..);
Map<String,String> attrs = new HashMap<>();
attrs.put("language", "en"); // name,value
attrs.put("gender", "male");
client. saveExtendedAttributes ("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", attrs);

53.7.4.2 Visitor Servicesで拡張属性およびアクティビティを使用する方法

拡張属性は、Visitor Servicesで集計およびエンリッチメントに使用できます。

- 集計: リンクされたプロファイルには、extendedという名前の追加のプロファイルがあり、訪問者のすべての拡張属性が含まれます。

- エンリッチメント: 拡張属性構成の値として、拡張属性のエンリッチメント・ルールを追加できます。Visitor Servicesでは、これらのエンリッチメント・ルールを使用して、訪問者プロファイルをエンリッチします。拡張属性の例は、訪問者がWebサイトでコールバック用に残す電話番号です。この番号は、訪問者のプロファイルを他のプロファイル・ストアから検索するために、訪問者の拡張属性としてVisitor Servicesで使用できます。したがって、この例のエンリッチメント・ルールは、callback_phone=LDAP:Personal_Phoneになります。

次のプロセス・フローには、サンプルのオンライン・ストア、訪問者およびVisitor Servicesアクティビティ機能が含まれます。

1. 訪問者がブラウザを開き、http://online.store.com/dell/v560にアクセスしてDell v560ラップトップを選択します。

2. URLがhttp://online.store.com/dell/v560のページのリクエストをブラウザがWebサーバーに送信します

3. 必要なデータをWebサーバーが計算し、次の操作を実行します。

- (オプション)データベースからデータをフェッチします。

- (オプション)Visitor Servicesに訪問者の興味をリクエストし、最も関連性のある/関心(評価)のある商品に関する広告を表示できるようにします。
サンプル・コード: List<Activity> res = client.getRated("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);

この訪問者はLenovoラップトップに関心があることをVisitor Servicesが返します(この情報は前のアクティビティに基づきます)。

- Lenovoラップトップに関連する広告を表示します。

- (オプション)訪問者の最近のアクティビティを保存し、アクティビティを追加するようにVisitor Servicesにリクエストします。
最初: visited page = 'http://online.store.com/dell/v560'

2番目: product = 'dell v560'

サンプル・コード:

Map<String,String> acts = new HashMap<>();
acts.put("product", " dell v560'");
acts.put("web_page", "http://online.store.com/dell/v560");
client.addActivity("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", acts);

53.8 Visitor Servicesリファレンス

この項では、Visitor Servicesの参照情報について説明します。

- Visitor Servicesアーキテクチャについて

- アイデンティティ・プロバイダ・リファレンス

- アクセス・プロバイダ・リファレンス

- プロファイル・プロバイダ・リファレンス

- 集計テンプレート・リファレンス

- Visitor Servicesデータ・モデルについて

- 用語集

53.8.1 Visitor Servicesアーキテクチャについて

Visitor Servicesは、様々なプロファイル記憶域から訪問者のプロファイルをフェッチし、開発者が訪問者プロファイル情報(都市、教育、興味、ジョブ・プロファイルなど)を様々なプロファイル属性としてリポジトリに格納します。Visitor Servicesでは、使用状況の追跡および効果的なコンテンツ・ターゲット設定のための訪問者プロファイルの問合せ、エンリッチ、格納およびリンクを開発者が行うこことができます。

Visitor Servicesは、アプリケーションによってリクエストされたユーザー・データを収集するプロファイル・プロバイダ経由でプロファイル記憶域と通信します。ユーザー情報にアクセスするために、Visitor Servicesは顧客のシングル・サインオン(SSO)ソリューションを利用します。Visitor Servicesでは、アイデンティティ・プロバイダを使用して、SSOソリューションと通信します。

図53-16に、Visitor Servicesアーキテクチャを示します。Visitor Servicesには、次の統合レイヤーが含まれます。

- プロファイル・プロバイダ: Visitor Servicesとプロファイル記憶域間の通信を可能にします。

- アイデンティティ・プロバイダ: Visitor ServicesとSSOソリューション間の通信を可能にします。

- RESTサービス: Visitor ServicesとそのクライアントAPI間の通信を可能にします。

図53-16 Visitor Servicesアーキテクチャ

これらの統合レイヤーは、Visitor Servicesでカスタムのアイデンティティ・プロバイダおよびプロファイル・プロバイダをサポートするように設計されています。

53.8.2 アイデンティティ・プロバイダ・リファレンス

このリファレンスの内容は次のとおりです。

- アイデンティティ・プロバイダについて

- Visitor ServicesがWebサイトの訪問者を識別する方法

53.8.2.1 アイデンティティ・プロバイダについて

アイデンティティ・プロバイダ・サービスでは、Visitor Servicesと顧客のSSOシステムの統合を可能にし、Visitor ServicesとSSOシステム間の通信メカニズムを提供します。ブラウザがRESTサービスに訪問者のプロファイルをリクエストすると、RESTサービスはアイデンティティ・プロバイダからアイデンティティ・オブジェクトを要求します。アイデンティティ・プロバイダは、アイデンティティ・オブジェクト(DNとプロバイダで構成)をプロファイル・プロバイダに渡します。ユーザーが記憶域に存在する場合、プロファイル・プロバイダは一意のIDを返します。それ以外の場合、ユーザーはゲスト・ユーザーとして扱われるため、新しい一意のIDが返されます。次に、RESTサービスが訪問者IDをブラウザに返します。

アイデンティティ・プロバイダは、ブラウザCookieチケットなどの一部の識別子を使用して、リクエストされた訪問者に関する次の情報(Visitor Servicesのアイデンティティと呼ばれます)を提供します。

- 訪問者のログイン名(記憶域の一意の名前)。

- 訪問者情報が格納される記憶域の名前。

アイデンティティ・プロバイダ機能は、Visitor Servicesアプリケーションの不可欠な部分であり、直接アクセスすることはできません。したがって、訪問者のIDの取得に関するすべてのリクエストは、RESTサービスを介してアイデンティティ・プロバイダに送信されます。一部のSSOソリューションは、Cookieチケットなどの外部IDと連動しますが、HTTPリクエストを入力パラメータとして受け入れるSSOソリューションもあります。アイデンティティ・プロバイダ実装では両方の状況をサポートする必要があることに注意してください。

53.8.2.2 Visitor ServicesがWebサイトの訪問者を識別する方法

Visitor Servicesでは、それぞれに一意の訪問者IDを提供することで、Webサイトを識別できます。訪問者は、次のいずれかのタイプとして識別されます。

- 認証済: Webサイトに登録され、Oracle Access Manager (OAM)やSiteMinderなどのSSOソリューションで自身を認証できる訪問者をVisitor Servicesで識別します。

- 未認証/匿名: このタイプの訪問者はサインインしないため、Visitor Servicesには、このユーザーの属性がありません。Visitor Servicesは匿名の訪問者を識別できませんが、クライアント・アプリケーション(WebCenter Sitesなど)がそれらの登録を明示的に決定すると。これらの訪問者は、登録後に認証済訪問者になります。クライアント・アプリケーションは、後で登録できるように属性を保存できます。Webサイトでは、Visitor Servicesが生成した訪問者IDをCookieに格納して、ユーザー・セッションの関連付けに使用します。

認証済訪問者プロファイルを処理するために、Visitor Servicesは、OAM MobileやSocialを含む、Oracle Access Manager (OAM)とデフォルトで統合します。他のSSOソリューションの場合、開発者は拡張機能を作成して、カスタム・アイデンティティ・プロバイダを構成できます。

詳細は、「アイデンティティ・プロバイダの構成」を参照してください。

53.8.3 アクセス・プロバイダ・リファレンス

このサービスは、Visitor Servicesとアプリケーション間の接続の保護に使用されます。Visitor Servicesと対話するクライアントの認証性を確認できるように、基本認証、LDAPベースの認証、その他の認証を構成できます。アクセス・プロバイダ・サービスで認証が構成されていない場合、すべてのリソースはパブリックとみなされ、だれもアクセスできなくなります。本番システムではアクセス・プロバイダを設定することを強くお薦めします。

注意:

クライアント側でアプリケーションとVisitor Servicesの接続に使用されるJavaScript APIは、パブリックAPIとみなされ、アクセス・プロバイダ・サービスではサポートされません。

このリファレンスの内容は次のとおりです。

- コンテナ保護およびVisitor Services保護について

- コンテナ保護の仕組み

- Visitor Services保護の仕組み

53.8.3.1 コンテナ保護およびVisitor Services保護について

アクセス・プロバイダ・サービスでは、次のタイプの保護が提供されます。

- コンテナ保護: ユーザーに関するすべての情報はコンテナ記憶域に格納され、Visitor Servicesはユーザーのロールのみをチェックします。クライアントのWebサーバーで基本認証の構成が可能な場合は、コンテナ保護を使用することをお薦めします。基本認証では次が必要です。

- Webサーバー: user = "username", password="pass", role="svsclient"

- アクセス・プロバイダ: access-provider-container-basic.jarバンドルをアップロードします。構成: role= svsclient

- RESTクライアント: new HttpAuthentication("username "," pass ")でクライアントを初期化します

- Visitor Services保護: ユーザーに関する情報はLDAPやデータベースなどに格納できます。クライアントのWebサーバーで基本認証メカニズムがサポートされていない場合は、Visitor Services保護を使用します。
Visitor Servicesからの基本LDAP保護では、次が必要です。

- アクセス・プロバイダ: access-provider-ldap-basic.jarバンドルをアップロードします。
構成:

- LDAP接続設定はLDAPプロファイル・プロバイダと同じです。

- 認可タイプの設定: HeaderName=Visitors-AuthorizationおよびAuthAlias=Visitors-Basic

- ユーザーのusernameとpasswordがともにあるLDAP。

- RESTクライアント: new VisitorsHttpAuthentication("username","pass")でクライアントを初期化します

53.8.3.2 コンテナ保護の仕組み

1. クライアントがプロファイル情報リクエストをVisitor Servicesに送信します。このリクエストには、必要な認証(認証ヘッダーの認証トークン)が含まれます。

2. Webサーバーがこのリクエストを停止し、認証ヘッダーをチェックします。

3. ユーザーを認証できない場合、Webサーバーは401エラーを返します。

4. ユーザーが正常に認証されると、Webサーバーがユーザー・ロールをリクエストに追加します。

5. リクエストがアクセス・プロバイダに到達します。

6. 関数boolean check(HttpServletRequest request)がリクエストをチェックして、必要なロールを確認します。

7. ロール・チェックが成功すると、Visitor Servicesがリクエストを処理します。

53.8.3.3 Visitor Services保護の仕組み

1. クライアントがプロファイル情報リクエストをVisitor Servicesに送信します。このリクエストには、必要な認証情報が含まれます。

2. リクエストがアクセス・プロバイダ・サービスに到達すると、関数boolean check(HttpServletRequest request)がリクエストをチェックして認証情報を確認します。

3. アクセス・プロバイダがその記憶域をチェックして、リクエストに含まれる認証情報を確認します。

4. Visitor Servicesがリクエストを処理します。

53.8.4 プロファイル・プロバイダ・リファレンス

このリファレンスの内容は次のとおりです。

- プロファイル・プロバイダおよびエンリッチメント・サービスについて

- Visitor Servicesが訪問者属性を複数のチャネルから収集およびエンリッチする仕組み

53.8.4.1 プロファイル・プロバイダおよびエンリッチメント・サービスについて

プロファイル・プロバイダでは、Visitor Servicesが訪問者情報をそれぞれのリポジトリからフェッチできます。エンリッチメント・サービスでは、プロファイル・プロバイダが存在するすべてのリポジトリから、訪問者のプロファイル情報をVisitor Servicesでフェッチできます。

- プロファイル・プロバイダ

- エンリッチメント・サービス

- プロファイル・プロバイダおよびエンリッチメント・サービスの仕組み

53.8.4.1.1 プロファイル・プロバイダ

Visitor Servicesの主要タスクは、訪問者情報を外部記憶域から取得することです。これらの記憶域は、構造化データ、LDAP、または一部のデータベース上に構築されている外部Webサービスが含まれるテキスト・ファイルにできます。訪問者データをプロファイル記憶域からフェッチするために、開発者はカスタム・プロファイル・プロバイダを実装して、それらをVisitor Servicesに接続できます。プロファイル記憶域ごとに、1つのプロファイル・プロバイダが可能です。

LDAPおよびEloquaを使用する顧客の場合、プロファイル・プロバイダをデフォルトで使用できます。これらのプロファイル・プロバイダは、Adminインタフェースを使用してインストールされるOSGiバンドルとして使用可能です。これらのOSGiバンドルは、目的の記憶域で必要となる通信の実際のJavaベースの実装です。

注意:

Eloquaプロファイル・プロバイダを使用して訪問者IDを取得するには、-DUseSunHttpHandler=true パラメータをVisitor Services管理対象サーバーに設定する必要があります(使用中のアプリケーション・サーバーがWebLogicサーバーの場合)。

53.8.4.1.2 エンリッチメント・サービス

エンリッチメント・サービスでは、プロファイル・プロバイダを使用する様々なプロファイル記憶域で、訪問者情報をVisitor Servicesで検索できます。各プロファイル・プロバイダは、すべてのプロファイル・プロバイダが検索する情報をVisitor Servicesで検索できるようにする単一のルール・セットで構成できます。したがって、エンリッチメント・ルールでは、訪問者情報をすべてのプロファイル・プロバイダから収集します。これらのルールには、AttributeNameInCurrentProfileProvider=DifferentProfileProviderName:AttributeNameInThatProfileProviderの構造が含まれます。

Visitor Servicesがリクエストを受信して、訪問者のプロファイルをLDAPから取得すると、Visitor Servicesは、バックグラウンドで、対応するプロファイルに指定したエンリッチメント・ルールに従い、この訪問者のプロファイルをCRMで検索します。訪問者プロファイルがCRMに見つかると、電子メール・アドレスを検索基準として使用して、Eloquaを検索します。エンリッチメント・プロセスには時間がかかります。したがって、プロファイル・プロバイダを使用して、訪問者のプロファイルが記憶域から初めて取得されると、プロセスが個別のフローとしてバックグラウンドで実行されます。

Visitor Servicesが訪問者情報を複数の記憶域から収集した場合、Engageなどのアプリケーション用に、(集計テンプレートに基づいて)それらをコンパイルします。

53.8.4.1.3 プロファイル・プロバイダおよびエンリッチメント・サービスの仕組み

図53-17に、未加工のプロファイルをプロファイル記憶域から取得して、エンリッチメント・ルールをプロファイルに適用するために、Visitor Servicesがプロファイル・プロバイダとどのように通信するかを示します。

図53-17 Visitor Servicesとプロファイル・プロバイダ間のプロセス・フロー

図53-17に示すプロセス・フローに基づく手順:

1. 訪問者がFacebookにログインを試みます。

2. ログイン・リクエストがSSOソリューション経由でFacebookログイン・ページに渡されます。

3. 訪問者の資格証明がSSOソリューションに渡されます。

4. セッションが起動します。

5. WebサイトがVisitor Servicesに訪問者IDをリクエストします。

6. SSOソリューションが訪問者のIDをVisitor Servicesに渡します。

7. Visitor ServicesがFacebookプロファイル・プロバイダに訪問者のFacebookプロファイルをリクエストします。

8. Facebookプロファイル・プロバイダが訪問者のFacebookプロファイルをFacebookプロファイル記憶域から取得します。

9. Facebookプロファイル・プロバイダが未加工のFacebookプロファイルをVisitor Servicesに返します。

10. 未加工のFacebookプロファイルがVisitor Servicesデータベースに保存されます。

11. Visitor ServicesがFacebookプロファイル・プロバイダのエンリッチメント・ルールを取得します。

12. Visitor ServicesがGoogleプロファイル・プロバイダにGoogleプロファイルをリクエストします。

13. Googleプロファイル・プロバイダが訪問者のGoogleプロファイルをGoogleプロファイル記憶域から取得します。

14. Googleプロファイル・プロバイダが未加工のGoogleプロファイルをVisitor Servicesに返します。

15. GoogleプロファイルおよびFacebookプロファイルがリンクされ、Visitor Servicesデータベースに保存されます。

16. Visitor ServicesがGoogleプロファイル・プロバイダのエンリッチメント・ルールを取得します。

17. Visitor Servicesが訪問者IDをWebサイトに送信します。

53.8.4.2 Visitor Servicesが訪問者属性を複数のチャネルから収集およびエンリッチする仕組み

Visitor Servicesは、プロファイル・プロバイダを使用して、LDAP、Facebook、Eloqua、CRMなどの複数のプロファイル・ストアから訪問者データを検索してフェッチします。LDAPおよびEloquaのプロファイル・プロバイダが提供されます。他のプロファイル・ストアの場合、開発者はカスタム・プロファイル・プロバイダを作成および構成できます。

Visitor Servicesは、プロファイル・プロバイダが検索する訪問者ごとに、検索された訪問者IDと属性で未加工の訪問者プロファイルを作成します。たとえば、訪問者の名前と電子メールがLDAPプロファイル・プロバイダから、その配送先住所がCRMプロバイダから取得される場合があります。

包括的な訪問者ビューを構築するために、Visitor Servicesでは、プロファイル・プロバイダからプロファイル・エンリッチメントを介して訪問者の属性を検索および収集し、訪問者プロファイルをリンクできます。たとえば、OAM経由でログインしている訪問者の場合、Visitor Servicesは電子メール・アドレスをLDAPプロバイダ・プロファイルで検索して、一致する電子メール・アドレスをEloquaプロファイルで検索できます。

詳細は、「1つ以上のプロファイル・プロバイダの構成」を参照してください。

53.8.5 集計テンプレート・リファレンス

このリファレンスの内容は次のとおりです。

- 集計テンプレートについて

- Visitor Servicesが未加工の訪問者プロファイルを単一の集計済プロファイルにマージする仕組み

- Visitor Servicesが集計済訪問者プロファイルをターゲット設定、テストおよび分析に使用できるようにする仕組み

53.8.5.1 集計テンプレートについて

集計テンプレートは、Visitor Servicesで定義されている1つ以上のプロファイル・プロバイダからプロファイル属性を集計するのに使用されます。たとえば、同じ属性でプロファイル記憶域ごとに異なる名前が使用されます。訪問者の名前および電子メールIDがGoogle+とFacebookで異なる場合があります。Visitor Services集計サービスでは、様々なプロファイルでの命名方法に関係なく、同じタイプの属性を識別するために、次のパラメータを含む集計テンプレートが用意されています。

- プロファイルのメタデータ(属性のリスト)

- 様々なプロファイルからの情報を結合するためのルールのセット

集計サービスへのリクエストは、クライアントが訪問者IDと集計テンプレートを送信するVisitor Services APIを経由します。各クライアントには、Visitor Servicesで現在使用可能な訪問者プロファイルに関係なく、それぞれ独自のプロファイル構造があります。集計サービスは、アプリケーションのテンプレートを使用してプロファイルを構築します。集計テンプレートは、必要な属性のセットで、未加工の様々なプロファイルからどの属性を収集してコンパイルするかというルールが使用されます。集計済プロファイルの構造は、その訪問者がVisitor Servicesで使用可能なプロファイルのリストに関係なく常に同じであり、様々なプロファイル・プロバイダからの未加工のプロファイルの構造に関係ありません。

53.8.5.1.1 集計サービスの仕組み

図53-18に、リンクされているすべてのプロファイルとリクエスト時に必要なテンプレートを集計サービスがどのように取得するかを示します。

図53-18 プロセス・フロー: 集計サービスの仕組み

図53-18に示すプロセス・フローに基づく手順:

1. 特定の属性の訪問者の集計済プロファイルを取得するために、Webサイトが訪問者IDおよび集計テンプレート名をRESTサービスに提供します。

2. RESTサービスが訪問者IDと襲名テンプレート名を集計サービスに送信します。

3. 訪問者IDに使用可能なすべてのリンク済プロファイルを集計サービスがVisitor Servicesデータベースから取得します。

4. RESTサービスによって提供された集計テンプレート名の集計テンプレートを集計サービスが取得します。

5. 集計済テンプレートに基づいて、集計済プロファイルを集計サービスがRESTサービスに送信します。

6. RESTサービスが集計済プロファイルをWebサイトに送信します。

53.8.5.2 Visitor Servicesが未加工の訪問者プロファイルを単一の集計済プロファイルにマージする仕組み

プロファイル集計では、集計テンプレートを使用して、複数の訪問者プロファイルから集計済プロファイルに訪問者属性を統合します。(未加工の訪問者プロファイルは分離されたままです。)ビジネス・ニーズに応じて様々な集計テンプレートを作成できます。たとえば、マーケティング部門が、名前と電子メール・アドレスをLDAPから、電話番号をCRMから提供するテンプレートをリクエストしたり、名前をLDAPから、メーリング・アドレス・データをCRMプロファイルから提供するテンプレートをリクエストしたりできます。

集計テンプレートを使用すると、様々なソースからの訪問者プロファイルを結合するだけでなく、格納済のプロファイル情報を使用する、検索された値を計算する(例: 前年の注文数の合計)、および計算された値をプロファイル属性として追加することもできます。

詳細は、「1つ以上の集計テンプレートの作成」を参照してください。

53.8.5.3 Visitor Servicesが集計済訪問者プロファイルをターゲット設定、テストおよび分析に使用できるようにする仕組み

Visitor Servicesでは、属性を収集してリンクし、集計済訪問者プロファイルに格納します。プロファイルを使用するには、実行時にVisitor Services API (JavaクライアントおよびJavaScript)を介して、WebCenter Sitesコンポーネントでそれらをリクエストする必要があります。

マーケティング担当者は、訪問者プロファイルをVisitor Servicesから使用して、Engageセグメントを決定および作成できます。たとえば、マーケティング担当者は、年齢や収入などの訪問者プロファイル属性をVisitor Servicesから使用し、セグメントを作成して推奨を提供することができます。

未認証および不明の訪問者の場合、マーケティング担当者は、サイトへのアクセスに使用されたデバイス、タイム・ゾーン、ロケール、ブラウザ、リファラ(Facebook、Twitter、Bing)、IPアドレスなどの属性に基づいて、それらのセグメントを作成できます。

53.8.6 Visitor Servicesデータ・モデルについて

アイデンティティ・プロバイダ、プロファイル・プロバイダおよびアクセス・プロバイダの構成は、WebCenter Sitesデータベースに格納され、Sites REST APIを介してVisitor Servicesによって取得されます。訪問者の未加工のプロファイル、属性およびアクティビティは、ローカルのVisitor Servicesデータベースに格納されます。

WebCenter Sitesデータベースには、表53-4で説明されている表が含まれます。これらの表は、WebCenter Sitesのインストール中に作成されます。

表53-4 WebCenter Sitesデータベースの表

表名

説明

WCS_ProfileProviders

プロファイル・プロバイダの実装、構成およびエンリッチメント・ルールが含まれます。

WCS_IdentityProviders

アイデンティティ・プロバイダの実装および構成が含まれます。

WCS_AccessPrividers

アクセス・プロバイダの実装および構成が含まれます。

WCS_AggregatedTemplates

集計テンプレートが含まれます。

WCS_VisitorsConfig

Visitor Servicesの一般構成が含まれます。

ローカルVisitor Servicesデータベースには、表53-5で説明されている表が含まれます。

表53-5 ローカルVisitor Servicesデータベースの表

表名

説明

WCS_VIS_Profiles

プロファイル記憶域からの未加工のプロファイルが含まれ、プロファイル・プロバイダによって提供されます。

WCS_VIS_Attributes

アプリケーションによって登録されたアクティビティが含まれます。

WCS_VIS_Activity

アプリケーションによって保存された拡張属性が含まれます。

図53-19に、Visitor Servicesデータ・モデルおよび各データベースに含まれる表を示します。

図53-19 Visitor Servicesデータ・モデル

53.8.7 用語集

集計

Visitor Servicesで定義されている集計ルールに基づいて、未加工のプロファイルから集計済プロファイルを取得するプロセス。

集計済プロファイル

リンクされている訪問者の様々なプロファイルからVisitor Servicesによってコンパイルされる一意のプロファイル属性。

集計テンプレート

集計済プロファイルを作成するために、未加工のプロファイルからプロファイル属性を取得するための構成。

エンリッチメント

Visitor Servicesで定義されているエンリッチメント・ルールに基づいて、すべてのプロファイル記憶域から訪問者の未加工のプロファイルを取得するプロセス。

外部ID

SSOソリューションによって提供される外部ユーザー識別子。

アイデンティティ

値のペア: 訪問者のプロファイル・プロバイダ名と識別名(DN)。このペアはアイデンティティ・プロバイダからのものです。

アイデンティティ・プロバイダ

プロファイル・プロバイダ名とユーザーDNのペアを対応するアイデンティティ・ストアからVisitor Servicesに提供するために、externalIDを受け入れる開発者によって実装されるエンティティ。

アイデンティティ・ストア

訪問者の情報を含む記憶域。LDAPまたはデータベースになります。

リンクされているプロファイル

リンクされている未加工のすべてのプロファイルを数行の形式でVisitor Servicesデータベースに格納し、Visitor Servicesによって提供されるデータ。

プロファイル・プロバイダ

特定のプロファイル・ストアから訪問者プロファイルを受け取るために、開発者によって実装されるエンティティ。一般には、プロファイル・ストアごとに1つのプロバイダが実装されます。

プロファイル記憶域

訪問者のプロファイルの情報が含まれる外部記憶域。

未加工のプロファイル

プロファイル・プロバイダによって、そのプロファイル・ストアから提供される訪問者データ。

格納済プロファイル

RawProfile、ID、LinkId、およびVisitorIdの形式の処理済プロファイル・データを含む内部Visitor Servicesエンティティ。

SSOソリューション

Visitor Servicesとアプリケーション間のシングル・サインオンを提供する認証システム。Visitor Servicesには、OAM SSOシステムがパッケージされています。

Visitor Servicesデータベース

集計ルールやマッピング・ルールなど、訪問者のプロファイル・データと設定を格納するために、Visitor Servicesによって使用されるローカル・データベース。

第XIV部 サイト・キャプチャ・プロセスの制御

次の項では、BaseConfiguratorクラスのメソッドおよびインタフェースを実装することにより、クローラのサイト・キャプチャ・プロセスを制御する方法について説明します。

- クローラ構成ファイルのコーディング

54 クローラ構成ファイルのコーディング

BaseConfiguratorクラスとそのメソッド、およびインタフェースでは、クローラのサイト・キャプチャ・プロセスを制御します。サンプル・コードは、FirstSiteIIクローラのSite Captureインストールに使用できます。

クローラ構成の詳細は、次の項を参照してください。

- クローラの制御について

- BaseConfiguratorのメソッド

- クローラのカスタマイズ・メソッド

- getSocketTimeout

- getPostExecutionCommand

- getNumWorkers

- getUserAgent

- createResourceRewriter

- createMailer

- getProxyHost

- getProxyCredentials

- インタフェース

- メソッドとインタフェースの概要

54.1 クローラの制御について

クローラを制御するには、少なくとも開始URIとリンク抽出ロジックを使用してCrawlerConfigurator.groovyファイルをコーディングする必要があります。どちらの情報もgetStartUri()およびcreateLinkExtractor()メソッドを通じて提供されます。必要に応じてコードを追加して、たとえば、クロールするリンク数、クロールの深さ、クロール後イベントの呼出し(ダウンロードされたファイルのWebサーバーのドキュメント・ベースへの静的コピーなど)を指定できます。

使用するメソッドとインタフェースは、BaseConfiguratorクラスに用意されています。デフォルトの実装は、ターゲット・サイトの構造と収集するデータに適した方法でクロール・プロセスをカスタマイズおよび制御するためにオーバーライドできます。

この章では、最初にBaseConfiguratorのメソッド(「BaseConfiguratorのメソッド」を参照)と単純なCrawlerConfigurator.groovyファイル(「createLinkExtractor」を参照)を取り上げ、必要なメソッドの使用方法を示します。さらに、クローラのカスタマイズ方法について説明した後、Site CaptureのJavaインタフェース(デフォルト実装とカスタム実装を含む)について説明します。

54.2 BaseConfiguratorのメソッド

CrawlerConfigurator.groovyファイルには、CrawlerConfiguratorクラスのコードが含まれています。このクラスでは、クローラのデフォルト実装を提供する抽象クラスのBaseConfiguratorを拡張する必要があります。

表54-1に、BaseConfiguratorクラスのメソッドおよびインタフェースを示します。

表54-1 BaseConfiguratorクラスのメソッド

メソッド・タイプ

メソッド

メモ

必須

getStartUri

なし

必須

createLinkExtractor

LinkExtractorインタフェースのファクトリ・メソッド。[1]、[2]

クローラのカスタマイズ

getMaxLinks

なし

クローラのカスタマイズ

getMaxCrawlDepth

なし

クローラのカスタマイズ

getConnectionTimeout

なし

クローラのカスタマイズ

getSocketTimeout

なし

クローラのカスタマイズ

getPostExecutionCommand

なし

クローラのカスタマイズ

getNumWorkers

なし

クローラのカスタマイズ

getUserAgent

なし

クローラのカスタマイズ

createResourceRewriter

ResourceRewriterインタフェースのファクトリ・メソッド。

この項には次のトピックが含まれます:

- getStartUri

- createLinkExtractor

基本的なサンプルのCrawlerConfigurator.groovyファイルについては、「createLinkExtractor」を参照してください。

BaseConfiguratorの2つの抽象メソッドは、CrawlerConfiguratorでオーバーライドする必要があります。該当するメソッドは、getStartUri()とcreateLinkExtractor()です。

54.2.1 getStartUri

このメソッドは、クローラの開始URIを挿入します。URIが同一サイトに属している場合は、1つ以上のURIをクロールに構成します。複数の開始点を指定すると、複数のクロールが並行に開始されます。

www.example.comサイトの開始URIを指定するには:

/**
* The method is used to configure the site url which needs to be crawled.
*/
public String[] getStartUri()
{
return ["http://www.example.com/home"]; //Groovy uses brackets for an array.
}

サイトに複数の開始URIを指定するには、カンマ区切りの配列を入力します。

/**
* The method is used to configure the site url which needs to be crawled.
*/
public String[] getStartUri()
{
return ["http://www.example.com/product","http://www.example.com/support"]; //Groovy uses brackets for an array.
}

54.2.2 createLinkExtractor

このメソッドは、クロールしたページからリンクを抽出するロジックを構成します。抽出したリンクは、巡回の対象になります。createLinkExtractorメソッドは、LinkExtractorインタフェースのファクトリ・メソッドです。

- たとえば、LinkExtractorインタフェースを実装し、HTMLパーサーを使用してページを解析し、クロールに利用するリンクを抽出します。

- リンクを抽出するには、正規表現を使用するデフォルト実装のPatternLinkExtractorを使用します。たとえば、PatternLinkExtractorを使用すると、「基本の構成ファイル」のサンプル・コードに示すように、/home/products形式のリンクを、<a href="/home/product">Products</a>のような式で抽出できます。
www.example.comサイトの<a href="/home/product">Products</a>からリンクを抽出する正規表現を使用するには:

/**
* The method is used to define the link extraction
* algorithm from the crawled pages.
* PatternLinkExtractor is a regex based extractor
* which parses the links on the web page
* based on the pattern configured inside the constructor.
*/
public LinkExtractor createLinkExtractor()
{
return new PatternLinkExtractor("['\"\\(](/[^\\s<'\"\\)]*)",1);
}

- 正規表現とPatternLinkExtractorの詳細は、「LinkExtractorのデフォルト実装の使用」を参照してください。

- LinkExtractorインタフェースの実装方法の詳細は、「カスタム・リンク・エクストラクタの作成とデプロイ」を参照してください。

基本の構成ファイル

次に示す、簡単なCrawlerConfigurator.groovyファイルの例では、必須のメソッドgetStartUri()とcreateLinkExtractor()がオーバーライドされています。

この例では、追加のメソッドgetMaxLinks()をオーバーライドしていますが、これは「getMaxLinks」で説明されています。サンプルでは、テストが短時間で完了するように、150を返しています。

CrawlerConfigurator.groovyというファイルは、依存性を挿入するために使用しています。そのため、この名前は変更しないでください。

package com.fatwire.crawler.sample

import java.text.DateFormat;
import java.text.SimpleDateFormat;

import java.util.regex.Pattern;

import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;

import com.fatwire.crawler.*;
import com.fatwire.crawler.remote.*;
import com.fatwire.crawler.remote.di.*;
import com.fatwire.crawler.impl.*;
import com.fatwire.crawler.util.FileBuilder;

import org.apache.commons.lang.SystemUtils;
import org.apache.http.HttpHost;
import org.apache.http.auth.*;
import org.apache.http.client.*;
import org.apache.http.impl.client.*;
/**
* Configurator for the crawler.
* This is used to inject the dependency inside the crawler
* to control the crawling process
*/

public class CrawlerConfigurator extends BaseConfigurator {

public CrawlerConfigurator(GlobalConfigurator delegate){
super(delegate);
}

/**
* The method is used to configure the site url which needs to be crawled.
*/
public String[] getStartUri() {
return ["http://www.fatwire.com/home"]; //Groovy uses brackets for an array.
}

/**
* The method is used to define the link extraction algorithm
* from the crawled pages.
* PatternLinkExtractor is a regex based extractor which parses
* the links on the web page
* based on the pattern configured inside the constructor.
*/
public LinkExtractor createLinkExtractor() {
return new PatternLinkExtractor("['\"\\(](/[^\\s<'\"\\)]*)",1);
}

/**
* The method is used to control the maximum number of links
* to be crawled as part of this crawl session.
*/
public int getMaxLinks()
{
150;
}

54.3 クローラのカスタマイズ・メソッド

BaseConfiguratorクラスには、必須のメソッド以外にも、デフォルト実装を備えたメソッドが含まれており、これらのメソッドをオーバーライドすると、ターゲット・サイトの構造と収集する必要のあるデータに適する方法でクロールのプロセスをカスタマイズできます。

この項には次のトピックが含まれます:

- getMaxLinks

- getMaxCrawlDepth

- getConnectionTimeout

54.3.1 getMaxLinks

このメソッドは、クロールするリンクの数を制御します。リンクの数は正の整数にする必要があります。それ以外の場合は、同一ドメイン内で開始URIから到達可能な、すべてのリンクをクロールでスキャンするようになります。

クロールに500のリンクを指定するには:

/**
* default: -1; crawler will crawl over all the links reachable from the start URI
* @return the maximum number of links to download.
*/
public int getMaxLinks()
{
return 500;
}

54.3.2 getMaxCrawlDepth

このメソッドは、クロールするサイトの最大の深さを制御します。指定した深さを超えるリンクは無視されます。開始ページの深さは、0です。

/**
* default: -1. Indicates infinite depth for a site.
* @return the maximum depth to which we need to crawl the links.
*/
public int getMaxCrawlDepth()
{
return 4;
}

54.3.3 getConnectionTimeout

このメソッドでは、ターゲット・サイトへの接続を確立するまでにクローラが待機する時間を決定します。指定した時間内に接続が確立されない場合、クローラは、そのリンクを無視して後続のリンクに進みます。

接続タイムアウトに50,000ミリ秒を設定するには:

/**
* default: 30000 ms
* @return Connection timeout in milliseconds.
*/
public int getConnectionTimeout()
{
return 50000; // in milliseconds
}

54.4 getSocketTimeout

このメソッドでは、クロール対象のリンクに対して、クローラが行ったリクエストのソケット・タイムアウトを制御します。

ソケット・タイムアウトに30,000ミリ秒を設定するには:

/**
* default: 20000 ms
* @return Socket timeout in milliseconds.
*/
public int getSocketTimeout()
{
return 30000; // in milliseconds
}

54.5 getPostExecutionCommand

このメソッドは、カスタムのクロール後ロジックを挿入します。このメソッドは、クローラがクロール・セッションを終了したときに呼び出されます。このメソッドでは、スクリプトの絶対パス、またはコマンドとパラメータ(パラメータがある場合)を返す必要があります。

たとえば、getPostExecutionCommand()を使用すると、取得したファイルをクロール・セッションの終了後に静的にコピーするようなバッチやシェル・スクリプトを起動して、Webサーバーのドキュメント・ベースへのデプロイメントを自動化できます。

注意:

- スクリプトやコマンドは、Site Captureをホストするすべてのサーバー上の同じ場所に存在している必要があります。

- サイト・キャプチャ・インタフェースからは(250MBを超える)大きなアーカイブ・ファイルをダウンロードしないでください。Site Captureファイル・システムから目的の場所にファイルをコピーする場合は、getPostExecutionCommandを使用してください。アーカイブのサイズは、「ジョブの詳細」フォームに示されるクローラ・レポートから取得できます。

Site Captureサーバー上のcopy.batというバッチ・スクリプトを実行する手順:

/**
* default: null.
* @return the command string for post execution.
* Null if there is no such command.
*/
public String getPostExecutionCommand()
{
// The file is supposed to be at the path C:\\commands folder
// on the computer where the site capture server is running
return "C:\\commands\\copy.bat";
}

54.6 getNumWorkers

このメソッドでは、クロール・プロセスに使用するワーカー・スレッドの数を制御します。クロール・セッション用に生成する並列スレッドの理想的な数は、Site Captureをホストするコンピュータのアーキテクチャに応じて異なります。

1つのクローラ・プロセスに対して10個のワーカー・プロセスを開始するには:

/**
* default: 4.
* @return the number of workers to start.
* Workers will concurrently downloads resources.
*/
public int getNumWorkers()
{
// Start 10 worker threads which is involved in the crawl process.
return 10;
}

54.7 getUserAgent

このメソッドは、クローラがサイトを巡回するときに利用するユーザー・エージェントを構成します。このメソッドは、ブラウザでのレンダリングと異なる方法で、サイトをレンダリングするときに使用する必要があります(モバイル・デバイスでサイトをレンダリングする場合など)。

FireFox 3.6.17のユーザー・エージェントを構成するには:

/**
* default: publish-crawler/1.1 (http://www.fatwire.com)
* @return the user agent identifier
*/
public String getUserAgent()
{
return "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ";
}

54.8 createResourceRewriter

このメソッドは、クロールしたHTMLページ内のURLをリライトします。たとえば、WebCenter Sitesの動的なWebサイトを静的に配信できるようにするために、URLをリライトします。

createResourceRewriterメソッドは、ResourceRewriterインタフェースのファクトリ・メソッドです。

- ResourceRewriterインタフェースは、たとえば、動的URLを静的URLに変換したり、絶対URLを相対URLに変換したりするように実装します。

- また、次に示すデフォルト実装を使用することもできます。

- NullResourceRewriter: どのURLもリライトしません。

- PatternResourceRewriter: 正規パターンを検索して、指定に従ってリライトします。

PatternResourceRewriterを使用して、http://www.site.com/home.htmlのようなURLを/home.htmlにリライトするには:

/**
* Factory method for a ResourceRewriter.
* default: new NullResourceRewriter();
* @return the rewritten resource modifies the html before it is saved to disk.
*/
public ResourceRewriter createResourceRewriter()
{
new PatternResourceRewriter("http://www.site.com/([^\\s'\"]*)", '/$1');
}

- デフォルト実装の詳細は、「ResourceRewriterのデフォルト実装の使用」を参照してください。

- ResourceRewriterインタフェースの実装方法の詳細は、「カスタムResourceRewriterの作成」を参照してください。

54.9 createMailer

このメソッドは、クロール後に電子メールを送信するための実装を提供します。createMailerメソッドは、Mailerインタフェースのファクトリ・メソッドです。

- Site Captureには、静的またはアーカイブのキャプチャ・セッションが終了したときに、クローラ・レポートを電子メールで送信する、SMTP over TLSの実装が用意されています(クローラ・レポートは、report.txtファイルです。詳細は、『Oracle WebCenter Sitesの管理』を参照してください)。

- SMTP-TLS以外のメール・サーバー(認証なしのSMTPやPOP3など)を使用している場合は、独自の実装を用意する必要があります。

電子メールを送信するには:

/**
* Factory method for a Mailer.
* <p/>
* default: new NullMailer().
* @return mailer holding configuration to send an email at the end of the crawl.
* Should not be null.
*/
public Mailer createMailer()
{
return new NullMailer();
}

- デフォルト実装の詳細は、「Mailerのデフォルト実装の使用」を参照してください。

- ResourceRewriterインタフェースの実装方法の詳細は、「カスタムMailerの作成」を参照してください。

54.10 getProxyHost

このメソッドは、クロール先のサイトがプロキシ・サーバーの背後にある場合に、オーバーライドする必要があります。プロキシ・サーバーは、このメソッドで構成できます。

注意:

getProxyHostを使用するときには、getProxyCredentialsも使用します(「getProxyCredentials」を参照)。

プロキシ・サーバーを構成するには:

/**
* default: null.
* @return the host for the proxy,
* null when there is no proxy needed
*/
public HttpHost getProxyHost()
{
//using the HTTPClient library return a HTTPHost
return new HttpHost("www.myproxyserver.com", 883);
}

54.11 getProxyCredentials

このメソッドは、getProxyHostメソッドで構成されるプロキシ・サーバーの資格証明を挿入します(「getProxyHost」を参照)。

sampleuserという名前のプロキシ・サーバーのユーザーを認証するには:

/**
* default: null.
* example: new UsernamePasswordCredentials(username, password);
* @return user credentials for the proxy.
*/
public Credentials getProxyCredentials()
{
return new UsernamePasswordCredentials("sampleuser", "samplepassword");
//using the HTTPClient library return credentials
}

54.12 インタフェース

Site Captureに用意されている、デフォルト実装のあるインタフェースは、次のとおりです。

- LinkExtractor

- ResourceRewriter

- Mailer

54.12.1 LinkExtractor

リンク・エクストラクタは、クロール・セッションでSite Captureの巡回先にするリンクを指定します。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入されます。この実装は、クロール・セッションの一環としてダウンロードされたマークアップからリンクを抽出するために、クロール・セッション中にSite Captureフレームワークによってコールされます。

Site Captureには、LinkExtractorの実装が1つ用意されています。カスタムのリンク抽出ロジックを作成して、デプロイすることもできます。詳細は、次の項を参照してください。

- LinkExtractorインタフェース

- LinkExtractorのデフォルト実装の使用

- カスタム・リンク・エクストラクタの作成とデプロイ

54.12.1.1 LinkExtractorインタフェース

このインタフェースに含まれるメソッドは、1つのみです(extract)。このメソッドは、ダウンロードしたマークアップからリンクを抽出するアルゴリズムを提供するように実装する必要があります。

package com.fatwire.crawler;
import java.util.List;
import com.fatwire.crawler.url.ResourceURL;

/**
* Extracts the links out of a WebResource.
*/

public interface LinkExtractor
{
/**
* Parses the WebResource and finds a list of links (if possible).
* @param resource the WebResource to inspect.
* @return a list of links found inside the WebResource.
*/
List<ResourceURL> extract(final WebResource resource);
}

54.12.1.2 LinkExtractorのデフォルト実装の使用

PatternLinkExtractorは、LinkExtractorインタフェースのデフォルト実装です。PatternLinkExtractorは、正規表現に基づいてリンクを抽出します。正規表現を入力として受け取り、その正規表現に一致するリンクのみを返します。

一般的な使用方法のシナリオは、動的URLのサイトにPatternLinkExtractorを使用する方法と、静的URLのサイトにPatternLinkExtractorを使用する方法です。

- 動的URLのサイトにPatternLinkExtractorを使用する方法:
たとえば、www.example.comのリンクには、/home、/support、および/cs/Satellite/というパターンがあるとします。この種のリンクを抽出して巡回するには、次に示すように、PatternLinkExtractorを使用します。

/**
* The method is used to define the link extraction algorithm
* from the crawled pages.
* PatternLinkExtractor is a regex based extractor which parses
* the links on the web page
* based on the pattern configured inside the constructor.
*/
public LinkExtractor createLinkExtractor()
{
return new PatternLinkExtractor("['\"\\(](/[^\\s<'\"\\)]*)",1);
}

パターン['\"\\(] (/[^\\s<'\"\\)]*)を使用して、リンクを抽出します。:

- 最初の文字は、次のいずれかになります。

- 一重引用符( ' )

- 二重引用符( " )

- 左カッコ (

- その後に、スラッシュ( / )文字が続きます

- 最後の文字は、次のいずれかになります。

- 空白(\s)

- 小なり記号(<)

- 一重引用符( ' )

- 二重引用符( " )

- 右カッコ )

次に示すマークアップ内のURLを例に説明します。

<a href='/home'>Click Me</a>

抽出の対象は、/homeリンクのみです。このリンクは、一重引用符(')で始まり一重引用符(')で終わっているため、前述の正規表現パターンと一致します。グループ1は、結果として/homeを返します。

- 静的URLのサイトにPatternLinkExtractorを使用する方法。
たとえば、www.example.comのマークアップに、次のようなリンクがあるとします。

<a href="http://www.example.com/home/index.html">Click Me</a>

この種のリンクを抽出して巡回するために、次に示す方法でPatternLinkExtractorを使用します。:

/**
* The method is used to define the link extraction algorithm
* from the crawled pages.
* PatternLinkExtractor is a regex based extractor which parses
* the links on the web page
* based on the pattern configured inside the constructor.
*/
public LinkExtractor createLinkExtractor()
{
return new PatternLinkExtractor(Pattern.compile("http://www.example.com/[^\\s<'\"]*"));
}

前述の例では、http://www.example.comで始まり、空白(\s)、小なり記号(<)、一重引用符(')または二重引用符(")で終わるリンクを抽出するように、クローラに指示しています。

注意:

グループとパターンの詳細は、Javaドキュメントで、PatternクラスとMatcherクラスの説明を参照してください。

54.12.1.3 カスタム・リンク・エクストラクタの作成とデプロイ

Site Captureには、サンプルのリンク・エクストラクタ(およびリソース・リライタ)があり、FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。詳細は、次のフォルダにあるFSIILinkExtractorクラスのソース・コードを参照してください。

<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/src

カスタム・リンク・エクストラクタを作成するには::

1. Java IDEで、プロジェクトを作成します。

2. ファイルfw-crawler-core.jarを、<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/libフォルダから、プロジェクトのビルド・パスにコピーします。

3. extract()の実装を提供するために、LinkExtractorインタフェースを実装します。(LinkExtractorインタフェースについては、「LinkExtractorインタフェース」を参照してください。)

カスタム実装を示す擬似コードは、次のとおりです。

package com.custom.crawler;
import java.util.List;
import com.fatwire.crawler.url.ResourceURL;
import com.fatwire.crawler.LinkExtractor;
/**
* Extracts the links out of a WebResource.
*/
public class CustomLinkExtractor implements LinkExtractor
{
/**
* A sample constructor for CustomLinkExtractor
*/
public CustomLinkExtractor(String .......)
{
// Initialize if there are private members.
// User's custom logic
}

/**
* Parses the WebResource and finds a list of links (if possible).
* @param resource the WebResource to inspect.
* @return a list of links found inside the WebResource.
*/
List<ResourceURL> extract(final WebResource resource)
{
// Your custom code for extraction Algorithm.
}
}

4. カスタム実装用のjarファイルを作成して、そのファイルを次のフォルダにコピーします。

<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/lib

5. Site Captureアプリケーション・サーバーを再起動します。

6. カスタム・リンク・エクストラクタ・クラス(この例では、CustomLinkExtractor)を含めるように、CrawlerConfigurator.groovyをコーディングして依存性を挿入します。

/**
* User's custom link extractor mechanism to extract the links from the
* web resource downloaded as part of the crawl session.
* The code below is only a pseudo code for an example.
* User is free to implement their own custom constructor
* as shown in the next example.
*/
public LinkExtractor createLinkExtractor()
{
return new CustomLinkExtractor("Custom Logic For Your Constructor");
}

54.12.2 ResourceRewriter

リソース・リライタは、クロール・セッション中にダウンロードしたマークアップ内のURLをリライトします。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入する必要があります。

次に示すようなユースケースで、リソース・リライタが必要になります。

- 動的サイトをクローリングして、静的コピーを作成する。

- 絶対URLを相対URLに変換する。たとえば、http://www.example.com/abc.htmlのようなURLがマークアップに含まれている場合、クローラは、このURLからhttp://www.example.comを削除する必要があり、これにより、ダウンロードしたファイルが保存されているホストから、リソースを提供できるようになります。

Site Captureには、ResourceRewriterの実装が2つ用意されています。また、カスタムの実装を作成することもできます。詳細は、次の項を参照してください。

- ResourceRewriterインタフェース

- ResourceRewriterのデフォルト実装の使用

- カスタムResourceRewriterの作成

54.12.2.1 ResourceRewriterインタフェース

rewriteメソッドは、クロール・セッション中にダウンロードしたマークアップ内のURLをリライトします。

package com.fatwire.crawler;
import java.io.IOException;

/**
* Service for rewriting a resource. The crawler will use the implementation for
* rewrite method to rewrite the resources that are downloaded as part of crawl
* session.
*/
public interface ResourceRewriter
{
/**
* @param resource
* @return the bytes after the rewrite.
* @throws IOException
*/
byte[] rewrite(WebResource resource) throws IOException;

}

54.12.2.2 ResourceRewriterのデフォルト実装の使用

Site Captureに用意されているResourceRewriterの実装は、次のとおりです。

- NullResourceRewriter: デフォルトで、リンクのリライトを省略するように構成されています。CrawlerConfigurator.groovyファイルでResourceRewriterが構成されていない場合は、デフォルトで、NullResourceRewriterが挿入されます。

- PatternResourceRewriter: 正規表現に基づいてURLをリライトするために使用します。PatternResourceRewriterは、マークアップ内のリンクと一致する正規表現を入力として受け取り、一致したリンクをコンストラクタで指定した文字列に置き換えます。
絶対URLを相対URLにリライトするには:

リライト前:

<a href="http://www.example.com/about/index.html">Click Me</a>

リライト後:

<a href="/about/index.html">Click Me</a>

/**
* Factory method for a ResourceRewriter.
* default: new NullResourceRewriter();
* @return the rewritten resource modifies the html before it is saved to disk.
*/
public ResourceRewriter createResourceRewriter()
{
new PatternResourceRewriter("http://www.example.com/([^\\s'\"]*)", '/$1');
}

PatternResourceRewriterのコンストラクタは、1つのみです。このコンストラクタは、次に示すように、正規表現と置換文字列を1つずつ受け取ります。

PatternResourceRewriter(final String regex, final String replacement)

54.12.2.3 カスタムResourceRewriterの作成

Site Captureには、サンプルのリソース・リライタ(およびリンク・エクストラクタ)があり、FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。詳細は、次のフォルダにあるFSIILinkExtractorクラスのソース・コードを参照してください。

<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/src

カスタム・リソース・リライタを作成するには::

1. IDEで、プロジェクトを作成します。

2. fw-crawler-core.jarファイルを、<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/libフォルダからプロジェクトのビルド・パスにコピーします。

3. rewriteメソッドの実装を提供するために、ResourceRewriterインタフェースを実装します。ResourceRewriterインタフェースの詳細は、「ResourceRewriterインタフェース」を参照してください。

カスタム実装を示す擬似コードは、次のとおりです。

package com.custom.crawler;
import com.fatwire.crawler.WebResource;
import com.fatwire.crawler.ResourceRewriter;

/**
* Rewrite the links inside the markup downloaded as part of
* crawl session.
*/
public class CustomResourceRewriter implements ResourceRewriter
{
/**
* A sample constructor for CustomResourceRewriter
*/
public CustomResourceRewriter(String .......)
{
// Initialize if there are private members.
// User's custom logic
}

/**
* @param resource
* @return the bytes after the rewrite.
* @throws IOException
*/
byte[] rewrite(WebResource resource) throws IOException
{
// Your custom code for re-writing Algorithm.
}
}

4. カスタム実装用のjarファイルを作成して、そのファイルを<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/libフォルダにコピーします。

5. Site Captureアプリケーション・サーバーを再起動します。

6. カスタムのresource rewriterクラス(この例では、CustomResourceRewriter)を含めるように、CrawlerConfigurator.groovyファイルをコーディングして依存性を挿入します。

/*
* User's custom resource rewriting mechanism to rewrite the links from the
* web resource downloaded as part of the crawl session.
*
* The code below is only a pseudo code for an example.
* User is free to implement their own custom constructor
* as shown in the next example.
*/
public ResourceRewriter createResourceRewriter()
{
new CustomResourceRewriter("User's custom logic to initialize the things");
}

54.12.3 Mailer

メーラーは、クロールの終了後に電子メールを送信します。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入する必要があります。

Site Captureには、SMTPTlsMailerの実装が用意されています。これを使用して、SMTP-TLSメール・サーバーからクローラ・レポートを送信できます。また、Mailerインタフェースを実装して、SMTP-TLS以外のサーバー(認証なしのSMTP、POP3など)から電子メールを送信するためのカスタム・ロジックを提供できます。カスタム・ロジックでは、電子メールを、クローラ・レポート以外のオブジェクトとして指定することもできます。CrawlerConfigurator.groovyファイルでMailerが構成されていない場合は、デフォルトでNullMailerが挿入されます。

この項には次のトピックが含まれます:

- Mailerインタフェース

- Mailerのデフォルト実装の使用

- カスタムMailerの作成

54.12.3.1 Mailerインタフェース

sendMailは、MailerがCrawlerConfigurator.groovyファイルで構成されていると、自動的にコールされます。

package com.fatwire.crawler;
import java.io.IOException;
import javax.mail.MessagingException;

/**
* Service to send an email.
*/
public interface Mailer
{
/**
* Sends the mail.
*
* @param subject
* @param report
* @throws MessagingException
* @throws IOException
*/
void sendMail(String subject, String report)
throws MessagingException, IOException;
}

54.12.3.2 Mailerのデフォルト実装の使用

Site Captureには、静的またはアーカイブのクロール・セッションが終了したときにクローラ・レポートを送信するSMTP-TLSサーバー・ベースの電子メールの実装が用意されています。(クローラ・レポートは、report.txtファイルです。詳細は、『Oracle WebCenter Sitesの管理』を参照)。

- デフォルトのメーラーは、次に示すように、CrawlerConfigurator.groovyファイルに挿入することで使用します。

/**
* Factory method for a Mailer.
* <p/>
* default: new NullMailer().
* @return mailer holding configuration to send an email
* at the end of the crawl.
* Should not be null.
*/
public Mailer createMailer()
{
try
{
// Creating a SmtpTlsMailer Object
SmtpTlsMailer mailer = new SmtpTlsMailer();

InternetAddress from;
// Creating an internet address from whom the mail
// should be sent from = new InternetAddress("example@example.com");

// Setting the mail address inside the mailer object mailer.setFrom(from);

// Setting the email address of the recipient inside
// mailer.mailer.setTo(InternetAddress.parse("example@example.com"));

// Setting the email server host for to be used for email.
// The email server should be SMTP-TLS enabled.
mailer.setHost("smtp.gmail.com", 587);

// Setting the credentials of the mail account
// mailer.setCredentials("example@example.com", "examplepassword");

return mailer;
}
catch (AddressException e)
{
log.error(e.getMessage());
}
}

54.12.3.3 カスタムMailerの作成

この項では、カスタムMailerの作成手順について説明します。

カスタム・メーラーを作成するには::

1. IDEで、プロジェクトを作成します。

2. fw-crawler-core.jarファイルを、<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/libフォルダから、プロジェクトのビルド・パスにコピーします。

3. sendMailメソッドを含むMailerインタフェースを実装します。

カスタム実装を示す擬似コードは、次のとおりです。

package com.custom.crawler;
import java.io.IOException;
import javax.mail.MessagingException;
import com.fatwire.crawler.Mailer;

/**
* Implements an interface to implement the logic for sending emails
* when the crawl session has been completed.
*/
public class CustomMailer implements Mailer
{
/**
* A sample constructor for CustomMailer
*/
public CustomMailer()
{
// Initialize if there are private members.
// User's custom logic
}

/**
* Sends the mail.
*
* @param subject
* @param report
* @throws MessagingException
* @throws IOException
*/
void sendMail(String subject, String report)
throws MessagingException, IOException
{
// User's custom logic to send the emails.
}
}

4. カスタム実装用のjarファイルを作成して、そのファイルを<SC_INSTALL_DIR>/fw-site-capture/webapps/ROOT/WEB-INF/libフォルダにコピーします。

5. Site Captureアプリケーション・サーバーを再起動します。

6. カスタム・メーラー・クラス(この例では、CustomMailer)を含めるように、CrawlerConfigurator.groovyファイルをコーディングして依存性を挿入します。

/**
* Factory method for a Mailer.
* <p/>
* default: new NullMailer().
* @return mailer holding configuration to send an email
* at the end of the crawl.
* Should not be null.
*/
public Mailer createMailer()
{
CustomMailer mailer = new CustomMailer();
// Do some of the initilization stuffs
return mailer;
}
package com.custom.crawler;
import java.io.IOException;
import javax.mail.MessagingException;
import com.fatwire.crawler.Mailer;

/**
* Implements an interface to implement the logic for sending emails
* when the crawl session has been completed.
*/
public class CustomMailer implements Mailer
{
/**
* A sample constructor for CustomMailer
*/
public CustomMailer()
{
// Initialize if there are private members.
// User's custom logic
}
/**
* Sends the mail.
*
* @param subject
* @param report
* @throws MessagingException
* @throws IOException
*/
void sendMail(String subject, String report)
throws MessagingException, IOException
{
// User's custom logic to send the emails.
}
}

この実装では、sendMailメソッドのString report引数でクローラ・レポートが指定されている場合(デフォルト)、クローラ・レポート(report.txtファイル。『Oracle WebCenter Sitesの管理』を参照)を電子メールで送信します。ロジックをカスタマイズすることで、クローラ・レポート以外のオブジェクトを電子メール送信できるようになります。

54.13 メソッドとインタフェースの概要

この項で説明した、Site CaptureのBaseConfiguratorクラスに含まれるメソッドとインタフェースは、クローラのサイト・キャプチャ・プロセスを制御するためのものです。ここでは、メソッドとインタフェース、およびそれらのデフォルト実装についての概要を示します。

この項には次のトピックが含まれます:

- メソッド

- インタフェース

54.13.1 メソッド

Site CaptureのBaseConfiguratorクラスで使用されているインタフェースは、次のとおりです。

- getStartUri

- createLinkExtractor

- getMaxLinks

- getMaxCrawlDepth

- getConnectionTimeout

- getSocketTimeout

- getPostExecutionCommand

- getNumWorkers

- getUserAgent

- createResourceRewriter

- createMailer

- getProxyHost

- getProxyCredentials

ファクトリ・メソッドは、次に示すインタフェースに含まれています。

- createLinkExtractorは、LinkExtractorインタフェースに含まれています。

- createResourceRewriterは、ResourceRewriterインタフェースに含まれています。

- createMailerは、Mailerインタフェースに含まれています。

54.13.2 インタフェース

Site CaptureのBaseConfiguratorクラスで使用されているインタフェースは、次のとおりです。

- LinkExtractor
デフォルト実装は、正規表現に基づいてリンクを抽出する、PatternLinkExtractorです。

また、Site Captureには、サンプルのリンク・エクストラクタ(およびサンプルのリソース・リライタ)があり、FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。ソース・コードは、フォルダ<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/srcから入手可能です。

カスタムのリンク・エクストラクタ・ロジックを作成して、デプロイできます。

- ResourceRewriter
デフォルト実装は、リンクのリライトを省略するNullResourceRewriterと、正規表現に基づいてURLをリライトするPatternResourceRewriterです。

Site Captureには、サンプルのリソース・リライタ(およびサンプルのリンク・エクストラクタ)があり、FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。ソース・コードは、フォルダ<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/srcから入手可能です。

URLをリライトする独自のロジックを作成して、デプロイできます。

- Mailer
デフォルト実装は、クローラ・レポートをSMTP-TLSメール・サーバーから送信するSMTPTlsMailerです。これとは別のタイプのサーバーから別のタイプのオブジェクトを電子メールで送信するように、ロジックをカスタマイズできます。

[1]
一覧に示したインタフェースには、この章で説明するデフォルトの実装があります。

[2]
Site Captureには、サンプルのリンク・エクストラクタとリソース・リライタがあり、どちらもFirstSiteIIサンプル・クローラによって使用されます。「カスタム・リンク・エクストラクタの作成とデプロイ」および「カスタムResourceRewriterの作成」を参照してください。

第XV部 サードパーティ・コンテンツ・ソースとの統合

次のトピックでは、Content Integration Platformを拡張して、任意のシステムからOracle WebCenter Sitesへパブリッシュする方法について説明します。

- プロキシ・アセットを使用したサードパーティ・コンテンツ・ソースの統合

55 プロキシ・アセットを使用したサードパーティ・コンテンツ・ソースの統合

WebCenter Sitesによって配信される外部Webコンテンツは、プロキシ・アセット・タイプのフレームワークを使用してサイトに統合できます。

プロキシ・アセットを使用したサード・パーティのコンテンツ・ソースの統合の詳細は、次の項を参照してください。

- プロキシ・アセットのアーキテクチャおよびContributorインタフェース

- サンプル・プロキシ・アセットのインストール

- Contributorインタフェースの外部コンテンツの統合

- YouTubeプロキシ・アセットの設定

- ユーザー・インタフェースのカスタマイズ

- Webページへのプロキシ・アセットの埋込みについて

55.1 プロキシ・アセットのアーキテクチャおよびContributorインタフェース

この項では、プロキシ・アセットのアーキテクチャおよびOracle WebCenter Sites: Contributorインタフェースのカスタマイズについて説明します。

プロキシ・アセットのアーキテクチャ

プロキシ・アセットとは、リモートの場所に保管され、その場所で管理されているコンテンツを表します。図55-1に、プロキシ・アセットのアーキテクチャを示します。

図55-1 プロキシ・アセットのアーキテクチャ

このアーキテクチャの内容は、次のとおりです。

- サード・パーティのコンテンツ・リポジトリは、パブリックの読取りAPIを通じて、編集用インスタンスと配信インスタンスの両方からアクセスできると想定されています。

- Contributorインタフェースは、外部コンテンツをUIに表示するために、サード・パーティ・リポジトリにアクセスするようにカスタマイズされています。

- プロキシ・アセットは、UIにレンダリングされる外部コンテンツごとに実行時に作成されます。プロキシ・アセットには、メタデータは格納されません。このメタデータは、サード・パーティのサービスが提供するパブリックの読取りAPIを通じてアクセスできると想定されています。

- ライブ・インスタンスでは、プロキシ・アセット用に作成されたテンプレートで同一のリポジトリとAPIにアクセスして、ライブ・サイトに外部コンテンツをレンダリングします。

注意:

プロキシ・アセットは、使用されるもののみがWebCenter Sitesデータベースに永久的に格納されます。たとえば、検索結果のレンダリング中に作成されるプロキシ・アセットは、その後、専用のクリーニング・イベントで消去されます。

Contributorインタフェース

WebCenter Sitesデータベースに新しいプロキシ・アセット・タイプを登録した後で、開発者は、適切なUIカスタマイズを提供して、コントリビュータが外部コンテンツとの対話を始められるようにする必要があります。

実装するUIカスタマイズの特性は、コントリビュータに固有の要件に応じて異なります。たとえば、Contributorインタフェースの検索機能は、多くの場合、外部リポジトリに固有の検索サービスにフックされることになります。

これが行われていて、外部コンテンツがプロキシ・アセットの形式でContributorインタフェースに表示されていると、それらのアセットは標準アセットとほとんど同じように機能します。つまり、コントリビュータは、次の操作を実行できるようになります。

- 外部コンテンツ・リポジトリの検索(同じアセット検索タブを使用し、結果をドッキングまたはドッキング解除されたリスト表示またはサムネイル表示に示します)

- 検索またはツリーからのドラッグ・アンド・ドロップの使用。

- 外部コンテンツの別のアセットへの関連付け(フォーム・ビューまたはWebビュー)

- 外部コンテンツのプレビュー(WebCenter Sitesのテンプレートを使用)。

- ブックマーク、タグのワークフローでの設定、承認およびパブリッシュ。

注意:

次の制限があります。

- 外部コンテンツのライフサイクルは、サード・パーティのUIで全体的に管理することを想定しています。つまり、WebCenter Sitesには、外部リポジトリへの読取りアクセスのみが必要になります。そのため、編集やバージョニングなどのUIアクションは、すべてのプロキシ・アセットタイプに対してデフォルトで無効化されています。

- プロキシ・アセットには、関連アセットまたはサブタイプを含めることができません。

- 外部コンテンツ・リポジトリは、コントリビューションと配信の両方のWebCenter Sitesインスタンスからアクセスできるようにする必要があります。

55.2 サンプル・プロキシ・アセットのインストール

この項では、Oracle WebCenter Sitesでサンプル・プロキシ・アセットをインストールする方法について説明します。

- プロキシ・アセット・ディレクトリの設定

- プロキシ・アセットの作成

- プロキシ・アセットへの検索機能の追加

- プロキシ・アセットへのサムネイル・グリッド機能の追加

- プロキシ・アセットへのツリー機能の追加

注意:
詳細は、「Contributorインタフェースの外部コンテンツの統合」も参照してください。

55.2.1 プロキシ・アセット・ディレクトリの設定

プロキシ・アセット・ディレクトリを設定するには:

1. Oracle WebCenter Sitesインストールで、sites-home\bootstrap\samples\miscellaneous\SampleProxy\proxy_sampleに移動します。後続の手順では、このディレクトリを${WCS_PROXY}と呼びます。

2. サーバーのWebアプリケーションのルートの下にproxy_samplesディレクトリをコピーします。たとえば、sites-webapp-server\webapps\sites\proxy_samplesのようになります。
このディレクトリには、サード・パーティのAPIをシミュレートするためのサンプルのJSONおよびイメージが含まれています。

3. proxy_samplesディレクトリをテストするには、サーバーを起動し、http://localhost:8080/sites/proxy_samples/search/ski.jsonに移動します。次に、ブラウザ内のファイルの1つをクリックし、JSONテキストを表示します。

55.2.2 プロキシ・アセットの作成

プロキシ・アセットを作成するには:

1. WebCenter Sitesにログインし、Adminインタフェースを起動します。

2. 「管理」、「プロキシ・アセット・メーカー」の順に開き、「新規追加」をダブルクリックします。

3. フォームで、プロキシ・アセットの「名前」 (ProxyTestなど)、「説明」および「複数形」 (ProxyTestsなど)の各フィールドに値を入力します。

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

5. サイト内のProxyTestアセットを有効にします。これを行うには、ProxyTestの「検索」スタート・メニューを作成します。
ContributorではまだProxyTestの「Search」スタート・メニューにはアクセスできません。

55.2.3 プロキシ・アセットへの検索機能の追加

検索機能を追加するには:

1. Sites Explorerを開き、WebCenter Sitesインスタンスにログインします。

2. Sites Explorerで、Tables/ElementCatalog/CustomElementsの下で、次のディレクトリ構造ProxyTest/UI/Data/Searchを作成します。

3. ProxyTest/UI/Data/Searchの下で、2つの新しい行を追加します。

4. ${WCS_PROXY}\src\jsp\cs_deployed\CustomElements\ProxyTest\UI\Data\Search内の対応するファイルからコンテンツをコピーして貼り付けます。

- SearchAction

- elementname: SearchAction

- url: CustomElements\ProxyTest\UI\Data\Search\SearchAction.jsp

- SearchJson

- elementname: SearchJson

- url: CustomElements\ProxyTest\UI\Data\Search\SearchJson.jsp

5. Sites Explorerで、ElementCatalogの下に、ProxyTest: Tables\ElementCatalog\ProxyTestを追加します。

6. Tables\ElementCatalog\ProxyTestの下で、${WCS_PROXY}\src\jsp\cs_deployed\ProxyTest\GetData.jsp : GetData (elementname: GetData, url: ProxyTest/GetData.jsp)からコンテンツをコピーして貼り付けて新しいエントリを作成し、これらの変更を保存します。

7. Contributorインタフェースで、ProxyTestの「Search」フィールドに、「ski」または「surfing」を入力するか、何も入力しません。
プロキシ・アセットが移入されたリストが表示されます。

55.2.4 プロキシ・アセットへのサムネイル・グリッド機能の追加

サムネイル・グリッド機能を追加するには:

1. Sites Explorerで、Tables\ElementCatalog\CustomElements\ProxyTest\UIの下で、次のフォルダ構造\Layout\CenterPane\Search\Viewを作成します。

2. ${WCS_PROXY}\src\jsp\cs_deployed\CustomElements\ProxyTest\UI\Layout\CenterPane\Search\View内の対応するファイルからコンテンツをコピーして貼り付けて次のエントリを追加します。

- ThumbnailViewConfig:

- elementname: ThumbnailViewConfig

- url: CustomElements\ProxyTest\UI\Layout\CenterPane\Search\View\ThumbnailViewConfig.jsp

- DockedThumbnailViewConfig:

- elementname: DockedThumbnailViewConfig

- url: CustomElements\ProxyTest\UI\Layout\CenterPane\Search\View\DockedThumbnailViewConfig.jsp

3. Contributorインタフェースで、ProxyTestアセットの有効な検索条件を入力します。
グリッド・モードでサムネイル・イメージが表示されます。

55.2.5 プロキシ・アセットへのツリー機能の追加

ツリー機能を追加するには:

1. Sites Explorerで、Tables\ElementCatalog\ProxyTestの下で、Treeという名前のディレクトリを作成します。

2. ${WCS_PROXY}\src\jsp\cs_deployed\ProxyTest\Tree内の対応するファイルからコンテンツをコピーして貼り付けて次のエントリを追加します。

- Load

- elementname: Load

- url: ProxyTest\Tree\Load.jsp

- Root

- elementname: Root

- url: ProxyTest\Tree\Root.jsp

3. Adminインタフェースに切り替えます。

4. ツリー・タブを追加します。

a. 「管理」ノードを開きます。

b. ツリーで「ツリー」をダブルクリックします。
「ツリー・タブ」ページが表示されます。

c. 「新規ツリー・タブの追加」をクリックします。

d. 次を入力します。

- 「タイトル」フィールドに、ProxyTestTreeTabと入力します。

- 「サイト」ボックスで、avisports (または使用している任意のサイト)を選択します。

- 「必須ロール」ボックスで、「任意」を選択します。

- 「タブ・コンテンツ」ボックスで、「ProxyTest」を選択し、「選択したアイテムの追加」をクリックします。

- 選択したボックスで、「ProxyTest」をクリックします。

- 「セクション名」フィールドに、ProxyTestと入力します。

- 「エレメント名」フィールドに、ProxyTest/Tree/Rootと入力します(スラッシュのみを使用します)。

- 「セクションの編集」をクリックし、「保存」をクリックします。

5. Contributorインタフェースに切り替えます。

6. 「コンテンツ・ツリー」で、「ProxyTestTreeTab」ツリー・タブを開きます。
カテゴリskiおよびsurfingが各アセットとともにドラッグ・アンド・ドロップが可能になっていることがわかります。

55.3 Contributorインタフェースの外部コンテンツの統合

コントリビュータが外部コンテンツを使用して作業できるようにするには、開発者が、それに必要なUI統合コードを実装しておく必要があります。

この項では、事例を示すためにProxyTestコンテンツ・リポジトリを使用して、次の項目と統合するための手順について説明します。

- 検索: 標準のWebCenter Sites検索のかわりに、リポジトリ検索サービスを使用します。

- コンテンツ・ツリー: カスタム・コンテンツ・ツリーで、コントリビュータがリポジトリのコンテンツを参照できるようにします。

この項には次のトピックが含まれます:

- 事例: ProxyTestリポジトリ

- 新しいプロキシ・アセット・タイプの登録

- UI統合コードの実装について

- 検索のカスタマイズ

- カスタム・ツリーの実装

55.3.1 事例: ProxyTestリポジトリ

この項では、サンプル・データの設定およびProxyTestリポジトリからのデータの取得について説明します。

サンプル・データの設定

WebCenter Sites Webアプリケーションに直接デプロイされている静的なJSONファイルのセットを使用して、ProxyTestコンテンツ・リポジトリをエミュレートします。ProxyTestのコンテンツは、メディア・コンテンツ(イメージ)であると想定します。

これらのJSONファイルでは、次のサービスをシミュレートします。

- 特定の用語に対するリポジトリの検索(すべて、skiまたはsurfingについて検索すると、実際の結果が返されます): http://localhost:7001/sites/proxy_samples/search/<searchterm>.json

- すべてのコンテンツ・カテゴリの取得(SkiおよびSurfing): http://localhost:7001/sites/proxy_samples/browse/categories.json

- 特定のカテゴリに対するすべてのProxyTestコンテンツの取得: http://localhost:7001/sites/proxy_samples/browse/<category>.json

- 特定のコンテンツIDに対するメタデータの取得: http://localhost:7001/sites/proxy_samples/content/<id>.json

たとえば、/proxy_samples/search/ski.jsonは、次のサンプル・コンテンツを返します。

{
"items": [
{
"id": "1001",
"title": "Yellow Skier",
"foo": "bar1",
"lastModified": "1354735336444",
"thumbnail": "proxy_samples/images/image7_thumbnail.png"
},
{
"id": "1002",
"title": "Female Skier",
"foo": "bar2",
"lastModified": "1354735336444",
"thumbnail": "proxy_samples/images/image8_thumbnail.png"
},
{
"id": "1003",
"title": "Ski Jump",
"foo": "bar3",
"lastModified": "1354735336444",
"thumbnail": "proxy_samples/images/image9_thumbnail.png"
}
]
}

注意:

サンプル・コードは、/misc/proxy_samples/フォルダ内に格納されています。このフォルダは、sites-home\bootstrap\proxy_samples\miscellaneous\SampleProxy内にあります。プロキシ・アセットに固有のサンプル・コードは、sites-home\bootstrap\samples\miscellaneous\SampleProxy\proxy_samples\内にあります。

ProxyTestリポジトリからのデータの取得

コードの重複を避けるために、外部コンテンツ・ソースの問合せに必要なロジックは、ProxyTest/GetDataという専用エレメントにカプセル化します。この例では、データはJSON形式で返されます。そのため、この例では、jersey (http://jersey.java.net/)とjettison (http://jettison.codehaus.org/)ライブラリを使用します。これらのライブラリは、受信JSONデータを取得してデシリアライズするために、WebCenter SitesのWebアプリケーションにデプロイされています。

このエレメントは、serviceURLというICS変数で問合せ(たとえば、/search/ski.json)を受け取り、ics.SetObj(String, Object)を使用してICSスコープ内に格納されたJSONArrayオブジェクトを返します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"
%><%@ page import="javax.ws.rs.client.*"
%><%@ page import="javax.ws.rs.core.*"
%><%@ page import="org.codehaus.jettison.json.*"
%><cs:ftcs>
<%
//
// get data from proxytest repository
//
//

Client client = ClientBuilder.newClient();
Response resp = null;
WebTarget res = null;

String host = request.getServerName();
String port = Integer.toString(request.getServerPort());
String contextPath = request.getContextPath();
String urlPath = "http://"+host+":"+port+"/"+contextPath+"/proxy_samples" + ics.GetVar("serviceURL");

try {
res = client.target(urlPath);
resp = res.request(MediaType.APPLICATION_JSON).get();
}
catch(Exception e) {
e.printStackTrace();
throw e;
}

JSONArray list = new JSONArray();

if (resp.getStatus() == 200) {
String jsonString = resp.readEntity(String.class);
JSONObject json = new JSONObject(jsonString);
list = json.getJSONArray("items");
}

ics.SetObj("items", list);

%>

</cs:ftcs>

55.3.2 新しいプロキシ・アセット・タイプの登録

WebCenter SitesリポジトリでProxyTestのコンテンツを表すには、新しいプロキシ・アセット・タイプを定義します。

プロキシ・アセット・タイプを作成するには:

1. 「管理」ノードで、プロキシ・アセット・マネージャを開き、「新規追加」をダブルクリックします。

「新規プロキシ・アセット・タイプの追加」ページが開きます(図55-2)。

図55-2 「新規プロキシ・アセット・タイプの追加」ページ

2. 「名前」フィールドに、プロキシ・アセット・タイプの名前を入力します。同様に、「説明」フィールドに説明を入力して、「複数形」フィールドに名前の複数形を入力します。

注意:

Contributorインタフェースでは、プロキシ・アセットを作成または編集できません。そのため、この手順では、「検索」スタート・メニューのみを有効化する必要があります。

この例では(さらに、このドキュメントの後続部分で使用するために)、「名前」フィールドにProxyTest、「説明」フィールドにProxyTest、「複数形」フィールドにProxyTestと入力します。

3. 「保存」をクリックします。

注意:

プロキシ・アセット・メーカーは、新しいアセット・タイプを登録して、それと同じ名前で単一の表を作成します。プロキシ・アセット表は、標準アセット・メタデータのサブセットのみを保持し、唯一の固有列externalidを定義します。この列は、外部リポジトリに含まれる外部コンテンツの識別子を保管するためのものです。

55.3.3 UI統合コードの実装について

アセットは、Contributorインタフェースの様々な場所に表示されます。たとえば、次のような場所が該当します。

- アセット・フォーム(アセット参照を含むフィールド)

- 検索結果

- コンテンツ・ツリー・パネル

それぞれの場合で、実際の統合コードは、要件と利用可能なカスタマイズ・フックに応じて様々に異なります。ただし、どの場合でも、「Contributorインタフェースに表示される外部コンテンツは、すべてプロキシ・アセットとして登録されている必要がある」という原則に従う必要があります。

実際には、外部コンテンツ・ソース内のコンテンツ識別子をexternalidで参照する、プロキシ・アセットを作成(または再使用)するということです。これは、通常のAsset APIのクラスとメソッドを使用することで実現できます。ただし、これを簡単にするために、プロキシJSPタグ・ライブラリが用意されています。

これには、次に示すユーティリティ・タグが含まれています。このタグは、特定の外部コンテンツをプロキシ・アセット・タイプとして登録するためのものです。

- <proxy:register />

さらに、データ・グリッド・ウィジェット(検索など)のJSONデータストアを生成するためのユーティリティ・タグも含まれています。これらのタグは、次のとおりです。

- <proxy:createstore />: 新しいストアを初期化します。

- <proxy:addstoreitem />: アイテムを特定のストアに追加します。

- <proxy:tojson />: ストアをJSONにシリアライズします。

詳細は、Oracle WebCenter Sitesタグ・リファレンスおよび「検索のカスタマイズ」のコード例を参照してください。

55.3.4 検索のカスタマイズ

「検索スタート・メニューのカスタマイズ」で説明したように、ProxyTestアセット・タイプのコントローラ・エレメントUI/Data/Search/Searchをオーバーライドするために、次のエレメントを作成します。

\sites-home\bootstrap\samples\miscellaneous\SampleProxy\proxy_sample\src\jsp\cs_deployed\CustomElements\ProxyTest\UI\Data\Search\SearchAction.jsp
\sites-home\bootstrap\samples\miscellaneous\SampleProxy\proxy_sample\src\jsp\cs_deployed\CustomElements\ProxyTest\UI\Data\Search\SearchAction.jsp\SearchJson

図55-3に、検索ドロップダウンの「ProxyTest」オプションを示します。ProxyTest(つまり、作成したプロキシ・アセット・タイプの名前)を選択すると、Luceneベースの検索ではなく、カスタムの検索コードが実行されます。

図55-3 ProxyTestアセットを示す検索ドロップダウン

完全なカスタム検索を実装するために、このセクションの残りのトピックを完了してください。

この項には次のトピックが含まれます:

- 提供済のサード・パーティAPIを使用した検索結果の取得

- 検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集

- グリッド・ウィジェット用のデータ・ストアの作成

- カスタム検索のテスト

- 追加のカスタマイズ

55.3.4.1 提供済のサード・パーティAPIを使用した検索結果の取得

1. CustomElements/ProxyTest/UI/Data/Search/SearchActionで、「事例: ProxyTestリポジトリ」に記載されているエレメントを使用して、JSONデータを取得します。

取得では次のコード例を使用します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="proxy" uri="futuretense_cs/proxy.tld"%>
<%@ page import="org.codehaus.jettison.json.*"%>
<%@ page import="COM.FutureTense.Interfaces.Utilities"%>
<cs:ftcs>

<%
// in this ProxyTest example, only the empty search string, 'ski' or 'surfing' will
// return results String searchTerm = ics.GetVar("searchText");
if (!Utilities.goodString(searchTerm)) searchTerm = "all";
%>
<ics:setvar name="serviceURL" value='<%="/search/" + searchTerm + ".json" %>' />
<ics:callelement element="ProxyTest/GetData" />
<%
JSONArray list = (JSONArray)ics.GetObj("items");

//
// ...to be continued in the next section
//
%>

</cs:ftcs>

2. この時点で、listには、外部コンテンツ・ソースから取得したJSONデータが格納されています。

55.3.4.2 検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集

この手順では、一連の段階を通じてコードを作成します。

1. 新しいデータ・ストアを作成します。

<proxy:createstore store="<storeName>" />

この<storeName>は、データ・ストアを指定する任意の文字列です。

2. その次に、受信外部コンテンツ・アセットごとに、現在のアセットをプロキシ・アセットとして登録します。

<proxy:register
externalid="<external_content_identifier>"
type="<proxy_asset_type>"
name="<proxy_asset_name>"
varname="<variable_name>" />

ここで:

- <external_content_identifier>は、サード・パーティ・リポジトリに含まれる現在の外部コンテンツ・アイテムの識別子です。この例のProxyTestリポジトリの場合、この識別子は受信JSONデータのidフィールドで返されます。

- <proxy_asset_type>は、プロキシ・アセット・タイプの名前です。この例では、ProxyTestです。

- <proxy_asset_name>は、Contributorインタフェース全体で名前として使用される、判読可能な文字列です。この例では、受信JSONデータで返されるtitleです。

- <variable_name>は、WebCenter Sitesの変数名です。この変数には、現在の外部コンテンツ・アイテムに対応するプロキシ・アセットのIDが格納されます。

3. その次に、受信登録済プロキシ・アセットごとに、アセットをデータ・ストアに追加します。

<proxy:addstoreitem
store="<storeName>"
id="<proxy_asset_id>"
type="<proxy_asset_type>" />

ここで:

- <storeName>は、<proxy:createstore />で定義したデータ・ストアです。

- <id>は、プロキシ・アセットの識別子です。

- <type>は、プロキシ・アセット・タイプです。

次に、ProxyTestプロキシ・アセット・タイプの完全なコードを示します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="proxy" uri="futuretense_cs/proxy.tld"%>
<%@ page import="org.codehaus.jettison.json.*"%>
<%@ page import="COM.FutureTense.Interfaces.Utilities"%>
<cs:ftcs>

<%
// in this ProxyTest example, only the empty search string, 'ski' or 'surfing' will
// return results
String searchTerm = ics.GetVar("searchText");
if (!Utilities.goodString(searchTerm)) searchTerm = "all";
%>
<ics:setvar name="serviceURL" value='<%="/search/" + searchTerm + ".json" %>' />
<ics:callelement element="ProxyTest/GetData" />
<%
JSONArray list = (JSONArray)ics.GetObj("items");
%>

<%-- create a new data store --%>
<proxy:createstore store="assets" />
<%
// go through each incoming item
for (int i = 0; i < list.length(); i++) {
JSONObject item = (JSONObject)list.get(i);%>

<%-- Register the current external content item as a proxy asset --%>
<proxy:register externalid='<%=item.getString("id") %>'
type="ProxyTest"
name='<%=item.getString("title") %>'
varname="internalid" />

<%-- Add the proxy asset to the datastore --%>
<proxy:addstoreitem store="assets"
id='<%=ics.GetVar("internalid") %>'
type="ProxyTest" />
<%
}
// put store name in request scope
request.setAttribute("store", "assets");
request.setAttribute("total", Integer.valueOf(list.length()));
%>
</cs:ftcs>

55.3.4.3 グリッド・ウィジェット用のデータ・ストアの作成

この手順では、UIウィジェットに送り返すJSONをレンダリングします。

CustomElements/ProxyTest/UI/Data/Search/SearchJson内で、次の例に示すように、proxy:tojsonユーティリティを使用してこの処理を実行します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="proxy" uri="futuretense_cs/proxy.tld"%>
<cs:ftcs>
<proxy:tojson store="${store}" total="${total}" />
</cs:ftcs>

55.3.4.4 カスタム検索のテスト

JSONのスクリプトを記述したら、検索機能が完全に動作することをテストします。検索をテストするには:

Contributorインタフェースで、検索ボックスから検索タイプとしてProxyTestを選択します。「検索」アイコンをクリックします。

「検索」タブが開き、関連データが表示されます(図55-4)。

図55-4 検索結果

図55-5に、同じコンテンツをサムネイル表示で示します。

図55-5 サムネイル表示の検索結果

「検索」タブは、ドッキング・モードでも機能します。図55-6に、デフォルトのデータが入力されたツールチップを示します。

図55-6 ドッキングされたパネル内の検索結果

55.3.4.5 追加のカスタマイズ

追加のカスタマイズを実装できます。ただし、これらを使用してカスタム検索を実装する必要はありません。

サムネイルのレンダリング

この例では、ProxyTestリポジトリは、各コンテンツ・アイテムのサムネイル・イメージへのURLを返します。サムネイルをレンダリングするために、ProxyTestリポジトリから送信されるサムネイルのURLを取得するように変更を加えます。これが行われるようにするには、サムネイル表示(ドッキングされている場合とドッキングされていない場合)のグリッドをカスタマイズする必要があります。つまり、次の構成エレメントをオーバーライドすることになります。

UI/Layout/CenterPane/Search/View/ThumbnailView
UI/Layout/CenterPane/Search/View/DockedThumbnailView

それぞれの構成ファイルは、次のように作成する必要があります。

CustomElements/ProxyTest/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig
CustomElements/ProxyTest/UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

ThumbnailViewConfig構成ファイルには、次のXML構成が含まれます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="xlat" uri="futuretense_cs/xlat.tld" %>
<cs:ftcs>
<thumbnailviewconfig>
<formatter>fw.ui.GridFormatter.simpleThumbnailFormatter</formatter>
</thumbnailviewconfig>
</cs:ftcs>

これにより、ProxyTestのサムネイル表示用のformatter設定をオーバーライドしていることがわかります(その他のグローバル構成エレメントの設定は維持されます)。このformatterは、サムネイル・イメージを表示する検索結果ごとのデフォルト・ビューと、名前フィールド(調査リンク)をレンダリングします。

同様に、ドッキングされたサムネイル表示の設定は、CustomElements/ProxyTest/UI/Layout/CenterPane/Search/View/に、次のXMLを含むDockedThumbnailViewConfigを作成することでオーバーライドする必要があります。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<cs:ftcs>
<ics:callelement element=
"[CustomElements/ProxyTest/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig]" />
</cs:ftcs>

注意:

検索構成の詳細は、「Contributorインタフェースの検索ビューのカスタマイズ」を参照してください。

エレメント名を囲む大カッコは、そこに指定されているエレメント名のカスタマイズ済バージョンを、ics:callelementタグで検索する必要がないことを示しています。

グリッド・コンテキスト・メニューの構成

アセット操作の一部は、プロキシ・アセットには適用されません。そのため、デフォルトのグリッド・コンテキスト・メニュー設定をオーバーライドする必要があります。エレメントUI/Config/GlobalHtmlをオーバーライドするために、新しいエレメントMyConfigをUI/Configに作成します。MyConfigの作成方法の詳細は、「コンテキスト・メニューのカスタマイズ」を参照してください。

このようにすることで、グローバル設定はオーバーライドした設定にマージされないようになります。

フィールド別のプロキシ・アセットのソート

プロキシ・アセットのソートは、外部コンテンツ・ソースAPIによって行われます(WebCenter Sitesでは結果が内部でソートされません)。このため、すべてのフィールドのソートがサポートされる場合とされない場合があります。ユーザーは、「ソート」アイコンをクリックしてソート・オプションから選択することにより、プロキシ・アセットのソート検索を実行できます。

注意:
ProxyTestアセットの例はソートをサポートしていません。

ソート・オプションは、CustomElements/ProxyTest/UI/Layout/CenterPane/Search/View/SearchTopBarConfigに設定されています。ソート・オプションに対しては次を定義する必要があります。

- fieldname: リクエスト・オプションとともにSearchActionに渡されるsort変数の値。これは、ソート対象のフィールド(dateなど)を示す必要があります。

- displayname: 「ソート」ドロップダウン・メニューに表示される文字列(View Count(Most-Least)など)。

- sortorder:descendingまたはascending。descendingの場合、fieldname値の前にマイナス記号(-)が追加されます。

YouTubeプロキシ・アセットの場合、次のコードが記述されます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@ taglib prefix="xlat" uri="futuretense_cs/xlat.tld"
%><cs:ftcs>
<!-- Here the field name is the index column on which the sort is performed.-->
<sortconfig>
<sortfields>
<sortfield id="title">
<fieldname>title</fieldname>
<displayname><xlat:stream key="UI/UC1/Layout/NameSort1" escape="true"/></displayname>
<sortorder>ascending</sortorder>
</sortfield>
<sortfield id="updateddate_dsc">
<fieldname>date</fieldname>
<displayname><xlat:stream key="UI/UC1/Layout/ModifiedSort1" escape="true"/></displayname>
<sortorder>descending</sortorder>
</sortfield>
<sortfield id="viewCount">
<fieldname>viewCount</fieldname>
<displayname><xlat:stream key="UI/UC1/Layout/ViewCountSort" escape="true"/></displayname>
<sortorder>descending</sortorder>
</sortfield>
</sortfields>
</sortconfig>
</cs:ftcs>

ソート・フィールドが選択された後、新しいソート検索が開始され、SearchActionがコールされます。ソート・パラメータは、requestオブジェクト内にあります。これは、ソート基準のフィールドを提供します。たとえば、YouTubeプロキシ・アセットのSearchActionでは、ソート・パラメータは問合せパラメータ値として取得および使用されます。

...

String sort = request.getParameter("sort");
if(sort != null && StringUtils.isNotEmpty(sort)){
// incase of descending sort, UI sends the field with a -ve sign,
// YouTube doesn't take as is, so remove the -ve sign if any
sort.trim();
if(sort.startsWith("-")){
sort = sort.substring(1,sort.length());
}
}else{
sort = "relevance";
}

...

// build YouTube URL
String baseYtURL = "https://www.googleapis.com/youtube/v3/";
StringBuffer ytQuery = new StringBuffer(baseYtURL);
ytQuery.append("search?part=snippet");
ytQuery.append("&maxResults=" + maxResults); // number of results per page
ytQuery.append("&type=video"); //only return videos, no channels or playlists
ytQuery.append("&order=" + sort); // ordering
ytQuery.append("&key=" + apiKey); // add user's API public access key
ytQuery.append("&q=").append(URLEncoder.encode(searchTerm));

...

SearchTopBarConfigエレメントとContextMenuConfigエレメントは、図55-7 に示すように、どちらもエレメントのresdetails1 (またはresdetails2)フィールドにmerge=falseを設定しておく必要があります。

図55-7 構成ファイルのエレメントの詳細値フィールド

55.3.5 カスタム・ツリーの実装

カスタム・ツリーを使用すると、図55-8 に示すように、ユーザーはカテゴリごとに簡単に外部コンテンツを参照できるようになります。

図55-8 カスタム・ツリー

ツリーをレンダリングするために、次の2つのエレメントを作成します。

- ProxyTest/Tree/Root: ツリーのルート・ノードをレンダリングします。これらのノードは、コンテンツの各カテゴリになります。

- ProxyTest/Tree/Load: 特定のカテゴリに属するコンテンツをすべてレンダリングします。

カスタム・ツリーを実装するには、最初にカスタム・ツリー・タブを登録してから、カスタム・ツリーのコードを実装する必要があります。

この項には次のトピックが含まれます:

- カスタム・ツリー・タブの登録

- ツリーのコードの実装

55.3.5.1 カスタム・ツリー・タブの登録

カスタム・ツリー・タブは、「新規ツリー・タブの追加」ページで定義します。この例で作成するタブでは、Proxy Assetsという新しいコンテンツ・ツリーを作成します。このツリーには、ProxyTest/Tree/Rootを参照する単一のカスタム・セクション(ProxyTest)を含めます。

この例のカスタム・ツリー・タブを登録するには:

1. Adminインタフェースで、「管理」ノードを開き、「ツリー」をダブルクリックします。

「ツリー・タブ」ページが開きます。

2. 「ツリー・タブ」ページの下側にある、「新規ツリー・タブの追加」をクリックします。

「新規ツリー・タブの追加」ページが開きます。

3. 必要に応じて、各フィールドに入力します。この例では、次のようにフィールドに入力します(図55-9)。

- タイトル: タブのタイトルとしてProxy Assetsを入力します。

- サイト: リストから「プロキシ」を選択します。

- 必須ロール: リストから「任意」を選択します。

- タブ・コンテンツ: 「ProxyTest」を選択してから、「選択したアイテムの追加」をクリックして、その項目を「選択済」列に移動します。「選択済」列の項目は、「ProxyTest」のみにする必要があります。

- セクション名: フィールドに、ProxyTestと入力します。

- エレメント名: フィールドに、ProxyTest/Tree/Rootと入力します。

図55-9 「新規ツリー・タブの追加」ページ

4. 各フィールドに適切な値を入力したら、「保存」をクリックしてアセットを保存します。

55.3.5.2 ツリーのコードの実装

1. ProxyTest/Tree/Rootでは、外部リポジトリを問い合せてツリーのルート・ノード(この例では、カテゴリのリスト)を取得します。

2. 各カテゴリのツリー・ノードのデータを生成します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="satellite" uri="futuretense_cs/satellite.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ page import="org.codehaus.jettison.json.*"%>
<cs:ftcs>

<%-- Retrieve all categories from ProxyTest repository --%>
<ics:setvar name="serviceURL" value="/browse/categories.json" />
<ics:callelement element="ProxyTest/GetData" />

<%
JSONArray list = (JSONArray)ics.GetObj("items");
for (int i = 0; i < list.length(); i++) {
String category = (String)list.get(i);
// 1) build a tree node id - needs to be unique
// Note: we need to make sure that AssetType is not present in the scope
// (BuildTreeNodeID is otherwise assuming the tree node to be an asset node)
%>
<ics:removevar name="AssetType" />
<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNodeID" >
<ics:argument name="AdHoc" value='<%=category %>' />
</ics:callelement>
<%
// 2) build the 'LoadURL' that is, the URL to call to load this node's children
// OpenMarket/Gator/UIFramework/LoadTab is a standard element.
// Required input is:
// - populate: the element rendering tree nodes to execute
// - op: must be set to 'load'
//
// We're also passing 'category' which is required by our custom logic in
// ProxyTest/Tree/Load
//
%>
<satellite:link assembler="query"
pagename="OpenMarket/Gator/UIFramework/LoadTab"
outstring="LoadURL">
<satellite:argument name="populate" value="ProxyTest/Tree/Load"/>
<satellite:argument name="op" value="load"/>
<satellite:argument name="category" value='<%=category %>' />
</satellite:link>

<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNode">
<ics:argument name="Label" value='<%=category %>' />
</ics:callelement>
<%}%>
</cs:ftcs>

図55-10に、このコードを使用して生成されたツリーを示します。

図55-10 生成されたカスタム・ツリー

注意:

OpenMarket/Gator/UIFramework/BuildTreeNodeIDエレメントとOpenMarket/Gator/UIFramework/BuildTreeNodeエレメントは、どちらもICSスコープ内の変数を利用します。<ics:callelement />タグはグローバル・スコープを持つため、<ics:removevar />を使用して、特定の変数をICSスコープから明示的に削除(永久的または一時的)することが必要になる場合があります。

3. ProxyTest/Tree/Loadでは、外部サービスを問い合せて、特定のカテゴリに含まれるすべてのコンテンツを取得して、コンテンツ・アイテムごとにノードをレンダリングします。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="proxy" uri="futuretense_cs/proxy.tld"%>
<%@ page import="org.codehaus.jettison.json.*"%>
<cs:ftcs>

<%-- Retrieve all content for a given category --%>
<ics:setvar name="serviceURL" value='<%="/browse/" + ics.GetVar("category") +
".json"%>' />
<ics:callelement element="ProxyTest/GetData" />

<%
JSONArray list = (JSONArray)ics.GetObj("items");

for (int i = 0; i < list.length(); i++) {
JSONObject item = (JSONObject)list.get(i);%>

<proxy:register externalid='<%=item.getString("id") %>'
type="ProxyTest"
name='<%=item.getString("title") %>'
varname="internalid" />

<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNodeID">
<ics:argument name="AssetType" value="ProxyTest" />
<ics:argument name="ID" value='<%=ics.GetVar("internalid") %>' />
</ics:callelement>

<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNode">
<ics:argument name="Label" value='<%=item.getString("title") %>' />
<ics:argument name="Description" value='<%=item.getString("title") %>' />
<ics:argument name="executeFunction" value="inspect" />
</ics:callelement>
<%
}
%>
</cs:ftcs>

図55-11 に示すように、各カテゴリを参照できるようになります。

図55-11 カスタム・ツリーのオブジェクトの参照

4. ノードをダブルクリックすると、そのノードについてのデフォルトのプロキシ・アセット調査ページが開きます。

55.4 YouTubeプロキシ・アセットの設定

YouTubeプロキシ・アセットにアクセスするには、APIキーを追加する必要があります。次に、WebLogic ServerにWebCenter Sitesをインストールする場合は、プロキシ・サーバーまたはWebLogic Serverも設定する必要があります。

YouTubeプロキシ・アセットを設定するには:

1. Google DevelopersのYouTube APIキーを取得します。

a. Google Developers Consoleにプロジェクトを登録します。

b. YouTube Data API v3を有効にします。

c. パブリックAPIサーバー・キーを生成します。

2. 生成されたキーをプロパティ・ファイルにコピーします。

a. wcs_properties.jsonファイルを開きます。

b. wcsites.youtube.api.keyキーを検索し、生成されたAPIキーをその値に追加します。

{
"key" : "wcsites.youtube.api.key",
"value" : "AIzaSyBnYqexNhlvU6QaJ2emS829bF...",
"valid_values" : [ "" ],
"defaultValue" : "",
"category" : "Core",
"subcategory" : "",
"global" : true,
"localServerValues" : { },
"hide" : false,
"readonly" : false,
"restart_required" : false,
"deprecated" : false,
"description" : "YouTube public API access key used to search Youtube videos (proxy assets). Created by registering project in the Google Developers Console, enabling YouTube Data API v3, and generating a public API server key."
}

3. YouTube API v3を利用するYouTubeプロキシ・アセットを検索して使用します。

a. avisportsサイトに切り替えます。

b. Contributorインタフェースに移動します。

c. 検索バーで、検索タイプとしてYouTube Videoを設定します。

d. 検索語を入力し、「検索」アイコンをクリックします。
YouTubeビデオが表示されます。

4. プロキシ・サーバーを使用している場合、次の手順を実行し、YouTubeプロキシ・アセット用として構成します。

a. Sites Explorerで、「Tables」→「ElementCatalog」→「CustomElements」→「YouTube」→「UI」→「Data」→「Search」の順に移動します。

b. SearchAction.jspの行を編集します。

- resdetails1列で、プロキシ・ホストを入力します。たとえば、proxyHost=my-proxy.company.comです。

- resdetails2列で、プロキシ・ポートを入力します。たとえば、proxyPort=80です。

5. WebCenter SitesがインストールされているWebLogic Serverを使用している場合、次の手順を実行し、YouTubeプロキシ・アセット用としてWebLogic Serverを構成します。

a. Adminコンソールhost:admin port/consoleを開きます。

b. 「ドメイン構造」、「環境」、「サーバー」の順に開きます。

c. WebCenter Sitesが実行されている管理対象サーバーをクリックします。

d. 「SSL」タブの下で、「詳細」を開きます。

- 「ホスト名の検証」の下で、「カスタム・ホスト名の検証」を選択します。

- 「カスタム・ホスト名の検証」には、weblogic.security.utils.SSLWLSWildcardHostnameVerifierを入力します。

e. WebLogic Serverのトラストストアがgoogleapis.comを信頼していることを確認します。WebLogicのデフォルト設定では、次が可能です。

- 「キーストア」タブの下の「キーストア」で、「変更」をクリックし、「デモ・アイデンティティとデモ信頼」を選択します。

- 「キーストア」の下で、「パスフレーズ」にJava標準信頼キーストアが含まれることを確認します(デフォルトはchangeit)。

6. サーバーを再起動します。

55.5 ユーザー・インタフェースのカスタマイズ

WebCenter Sitesの使用感を向上するために、Contributorインタフェースは様々な方法でカスタマイズできます。この項では、サード・パーティ・ソフトウェアと同期するためにインタフェースの一部をカスタマイズする方法について説明します。

この項には次のトピックが含まれます:

- 検索スタート・メニューのカスタマイズ

- コンテンツ・ツリーのカスタマイズ

55.5.1 検索スタート・メニューのカスタマイズ

Contributorインタフェースで、ユーザーは、「検索」スタート・メニューを選択することにより、特定のアセット・タイプに制限された検索を実行します。図55-12に、「検索タイプ」リストを示します。

図55-12 「検索タイプ」スタート・メニューの選択

特定のアセット・タイプに応じて検索をカスタマイズするには、次のエレメントを作成して、コントローラ・エレメントUI/Data/Search/Searchをオーバーライドします。

CustomElements/<AssetType>/UI/Data/Search/SearchAction
CustomElements/<AssetType>/UI/Data/Search/SearchJson

コントローラ・エレメントと、エレメントのオーバーライドの詳細は、「Contributorインタフェースの検索ビューのカスタマイズ」を参照してください。

UI/Data/Search/Searchは、検索コードを実行し、グリッド・ウィジェット(ドッキングまたはドッキング解除された、リスト表示またはサムネイル表示)での利用に適したJSONデータを生成します。このJSONデータは、有効なDojoデータストアにする必要があります。実装の例については、「コンテンツ・ツリーのカスタマイズ」を参照してください。

55.5.2 コンテンツ・ツリーのカスタマイズ

コンテンツ・ツリーは、新規または既存のツリー・タブに含めるカスタムのツリー・セクションを定義することでカスタマイズできます。カスタム・ツリー・タブのセクションの詳細は、ツリーへのアクセスの管理のためのオプション(Adminインタフェースのみ)を参照してください。

カスタム・ツリー・タブのセクションは、なんらかのレンダリング・ロジック(最終的にはツリー・ウィジェットで使用される)に基づいてデータを生成するJSPエレメントを参照します。ツリー・データは、次のユーティリティ・エレメントを使用して生成されます。

- OpenMarket/Gator/UIFramework/BuildTreeNodeId: ツリー・ノードIDを生成します。

- OpenMarket/Gator/UIFramework/BuildTreeNode: 適切に書式設定されたツリー・ノード・データを生成します。

次の例では、ツリー・ノードがアセットを表しているかどうかに応じたツリー・ノードの作成方法を示しています(アセット・ノードと非定型ノードの比較)。詳細は、「Adminインタフェースのツリーのカスタマイズ」を参照してください。

例1: アセットを表すツリー・ノードの作成

この例は、単一のアセット・ノードを表すツリー・ノードを生成する方法を示しています。このノードは、ダブルクリックされたときにinspectアクションを実行します(executeFunctionパラメータを参照)。つまり、アセットのデフォルト調査ビューが新しいタブにレンダリングされるようになります(そのアセットがタブ内で開かれている場合は、フォーカスが移動します)。

<%--
- Generates a tree node id.
- The element expects the asset id and type to be passed in parameters
- called respectively "ID" and "AssetType".
- The generated id is stored in a WebCenter Sites variable called "TreeNodeID"
--%>
<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNodeID">
<ics:argument name="AssetType" value="Article" />
<ics:argument name="ID" value="1234567890" />
</ics:callelement>

<%--
- Generates a tree node for this asset.
- Note that this element implicitly consumes variables
- currently present in the ICS scope, including "TreeNodeID"
--%>
<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNode">
<ics:argument name="Label" value="Node Label, for example asset name or other
readable string" />
<ics:argument name="Description" value="Some optional tooltip text" />
<ics:argument name="executeFunction" value="inspect" />
</ics:callelement>

例2: 非定型ツリー・ノードの作成

ツリー・ノードには、アセットを表さないものがあります。そのようなノードを、非定型ノードと呼びます。次の例は、親ノードを表す非定型ノードの生成方法を示しています。親ノードとは、子を持つノードで、開いたり閉じたりできます。

<%--
- Generates a tree node id.
- For adhoc nodes, the expected parameter is called "AdHoc",
- and can be any arbitrary string, which must be unique across tree nodes
--%>
<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNodeID" >
<ics:argument name="AdHoc" value="SomeUniqueString" />
</ics:callelement>

<%--
- Generates a "LoadURL", that is the URL to be called when a tree node
- is expanded. In this case, we're calling the default utility SiteCatalog entry
- (OpenMarket/Gator/UIFramework/LoadTab) which, in turn, will invoke
- a custom element ("Some/Other/Element" in our example), in charge
- of generating the child nodes, based on some custom logic.
--%>
<satellite:link
assembler="query"
pagename="OpenMarket/Gator/UIFramework/LoadTab"
outstring="LoadURL">
<satellite:argument name="populate" value="Some/Other/Element"/>
<satellite:argument name="op" value="load"/>
</satellite:link>

<%--
- Generates the corresponding tree node data
- Note that this element consumes the "LoadURL" variable previously generated.
- The presence of LoadURL indicates whether a node should be marked as expandable
or not.
--%>
<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNode">
<ics:argument name="Label" value="Some meaningful node label" />
</ics:callelement>

55.6 Webページへのプロキシ・アセットの埋込みについて

この項には次のトピックが含まれます:

- プロキシ・アセット用テンプレートの作成

- プロキシ・アセットのスロットでの使用

- プロキシ・アセットのキャッシングについて

55.6.1 プロキシ・アセット用テンプレートの作成

プロキシ・アセット用のテンプレートは、その他のアセット・タイプのテンプレートと同じように定義できます。

テンプレートを使用してプロキシ・アセットをレンダリングするには:

1. Adminインタフェースで、メニュー・バーの「新規」をクリックし、「新規テンプレート」を選択します。
「テンプレート」フォームが表示されます。

2. 「名前」フィールドに、ProxyTestSummaryと入力します。

3. 「対象アセット・タイプ」ドロップダウン・リストから、「ProxyTest」を選択します。

4. 「サブタイプに適用」ボックスで、「任意」がまだ選択されていない場合はこれを選択します。

5. 「エレメント」タブで、次を実行します。

- 「使用」ドロップダウン・リストから、「エレメントはレイアウトとして使用されます。」を選択します。

- 「テンプレート・エレメントを作成しますか。」セクションで、「JSP」をクリックします。

- 「エレメント・ロジック」ボックスで、${WCS_PROXY}\templates\ProxyTestSummary.jspから次のコードを入力します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"
%><%@ taglib prefix="render" uri="futuretense_cs/render.tld"
%><%@ taglib prefix="fragment" uri="futuretense_cs/fragment.tld"
%><%@ page import="javax.ws.rs.client.*"
%><%@ page import="javax.ws.rs.core.*"
%><%@ page import="org.codehaus.jettison.json.*"
%><%@ page import="com.fatwire.cs.ui.framework.UIException"
%><%@ taglib prefix="asset" uri="futuretense_cs/asset.tld"%>

<cs:ftcs>
<%-- ProxyTest/ProxyTestSummary    --%>

<%-- Record dependencies for the Template --%>
<ics:if condition='<%=ics.GetVar("tid")!=null%>'>
<ics:then><render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>
</ics:then>
</ics:if>

<%-- Set the urlPath to proxy_samples --%>
<%
String host = request.getServerName();
String port = Integer.toString(request.getServerPort());
String contextPath = request.getContextPath();
String urlPath = "http://"+host+":"+port+"/"+contextPath+"/proxy_samples/content/";
%>

<%-- first, retrieve the external id --%>
<asset:load name="asset" type='<%=ics.GetVar("c") %>'
objectid='<%=ics.GetVar("cid") %>' />
<asset:get name="asset" field="name" />
<asset:get name="asset" field="externalid" />

<%
// given the external content id, invoke the  third-party repository API
// to retrieve content metadata
Client client = ClientBuilder.newClient();
Response resp = null;
WebTarget res = null;

try {
res = client.target(urlPath + ics.GetVar("externalid") + ".json");
resp = res.request(MediaType.APPLICATION_JSON).get();
} catch (Exception e) {
// propagate exception to client-side
request.setAttribute(UIException._UI_EXCEPTION_, e);
e.printStackTrace();
throw e;
}

String jsonString = resp.readEntity(String.class);
JSONObject data = new JSONObject(jsonString);
%>

<%-- finally render content --%>
<h4><%=data.getString("title") %></h4>
<p><%=data.getString("foo") %></p>
<img src="<%=data.getString("image") %>" alt="<%=data.getString("title") %>" />

</cs:ftcs>

6. Contributorインタフェースで、「検索」フィールドは空白のままにして、ProxyTestアセットを検索します。

7. アセットの詳細が含まれるProxyTestアセットをクリックします(YellowSkierなど)。

8. 「プレビュー」をクリックし、ProxyTestSummaryレイアウトを選択し、「適用」をクリックします。

ProxyTestアセットのタイトル、メタデータおよびイメージが表示されます。

55.6.2 プロキシ・アセットのスロットでの使用

プロキシ・アセットは、標準アセットに適用されるものとまったく同じタグと原則を使用して、ページ内に埋込みできます。

1. ページ属性を作成します。

a. 「名前」フィールドに、ProxyTestAttributeと入力します。

b. 「属性タイプ」ドロップダウン・リストから、「アセット」を選択します。

c. 「対象アセット・タイプ」ドロップダウン・リストから、「ProxyTest」を選択します。

d. 「Save」アイコンをクリックします。

2. ページ定義を作成します。

a. 「名前」フィールドに、ProxyTestPageDefと入力します。

b. 「属性」セクションで、ProxyTest属性を選択し、「オプション」をクリックします。

c. 「保存」アイコンをクリックします。

3. ページ・アセットのテンプレートを作成します。

a. 「名前」フィールドに、ProxyTestSlotTemplateと入力します。

b. 「対象アセット・タイプ」ドロップダウン・リストから、「ページ」を選択します。

c. 「サブタイプに適用」ボックスで、「任意」がまだ選択されていない場合はこれを選択します。

d. 「エレメント」タブで、次を実行します。

- 「使用」ドロップダウン・リストから、「エレメントはレイアウトとして使用されます。」を選択します。

- 「テンプレート・エレメントを作成しますか。」セクションで、「JSP」をクリックします。

- 「エレメント・ロジック」ボックスで、${WCS_PROXY}\templates\ProxyTestSlotTemplate.jspから次のコードを入力します

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
<%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld"%>
<%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
<cs:ftcs><render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>
<html>
<head>
<title>ProxyTest Slots Example</title>
</head>
<body>
<assetset:setasset name="page" id='<%=ics.GetVar("cid") %>'
type='<%=ics.GetVar("c") %>' />
<assetset:getattributevalues attribute="ProxyTestAttribute" listvarname="ProxyTest"
name="page" typename="PageAttribute" />
<ics:listget listname="ProxyTest" fieldname="value" output="id" />
<h3>ProxyTest Slots Example</h3>
<insite:calltemplate field="ProxyTestAttribute" c='ProxyTest'
cid='<%=ics.GetVar("id") %>' tname="ProxyTestSummary" />
</body>
</html>
</cs:ftcs>

4. ページ・アセットを作成します。

a. Contributorインタフェースで、メニュー・バーから、「コンテンツ」、「新規」、「ページ (セクション)」の順に選択します。

b. 「追加」フィールドに、ProxyTestPageと入力します。

c. 「ページ定義」ドロップダウン・リストから、「ProxyTestPageDef」を選択します。

d. 「テンプレート」ドロップダウン・リストから、「ProxyTestSlotTemplate」を選択します。

e. フォーム・モードおよびWebモードで、ProxyTestアセットをProxyTestAttributeスロットにドラッグ・アンド・ドロップします。
Webモードでは、ProxyTestアセットはProxyTestSummaryテンプレートを使用してレンダリングされます。

55.6.3 プロキシ・アセットのキャッシングについて

レンダリング済のコンテンツは独立したリポジトリで保管および管理されるため、コンテンツが変更されたときに(コンテンツが変更された後でも)、その変更をWebCenter Sitesが認識する方法がありません。プロキシ・アセットをレンダリングするテンプレート(「プロキシ・アセット用テンプレートの作成」で定義したSummaryテンプレートなど)には、期間が限られたキャッシュ有効期限を設定するようにしてください。

第XVI部 Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発

次の項では、アプリケーション開発に関連するWebエクスペリエンス管理(WEM)フレームワークについて説明します。WEMフレームワークの概要から始めた後、アプリケーションおよびRepresentational State Transfer (REST)のカスタム・リソースの開発プロセスについて説明します。また、シングル・サインオン(SSO)の実装とカスタマイズについても説明します。

- Webエクスペリエンス管理(WEM)フレームワークについて

- WEMフレームワークとサービスの理解

- Articlesサンプル・アプリケーションでの作業

- WEMフレームワークでのアプリケーションの開発

- WEMフレームワークを使用したカスタムRESTリソースの開発

- 本番サイトでのシングル・サインオンの使用

- WEMフレームワークでのRESTリソースの使用

- WEMフレームワークへのCustomizable Single Sign-Onファシリティの導入

- WEMフレームワークでのバッファリング

- WEMフレームワークでのアプリケーションの手動登録

56 Webエクスペリエンス管理(WEM)フレームワークについて

Webエクスペリエンス管理(WEM)フレームワークは、アプリケーションを開発し、そのアプリケーションをOracle WebCenter Sitesと統合するためのテクノロジを備えています。単一の管理インタフェースであるWEM Adminは、アプリケーション管理およびユーザー認可の一元化をサポートします。また、シングル・サインオンを使用することによって、ユーザーは1回のログインで、セッション中に許可されているすべてのアプリケーションにアクセスできるようになります。

WEMフレームワークの詳細は、次の項を参照してください。

- WEMフレームワークについて

- アプリケーション開発の前提条件

- はじめに

56.1 WEMフレームワークについて

WEMフレームワークを使用するには、コンテンツ管理プラットフォームが必要です。WEMフレームワークはOracle WebCenter Sites上で稼働し、図56-1に示すように、WebCenter Sites Representational State Transfer (REST) APIが同梱されています。サイト、ユーザーおよびデータ・モデルなど、WebCenter Sitesデータベース内のオブジェクトは、WEMフレームワークでRESTリソースにマッピングされます。

図56-1 WEMフレームワーク

WEMフレームワーク上に実装されたアプリケーションは、RESTサービスを介してWebCenter Sitesデータベースと通信します。このアプリケーションは、WEM Adminで「アプリケーション」ページ(図56-2)のリスト項目として表示されます。管理者はユーザーの認可を行う際に、アプリケーションおよびそのリソースへのアクセスも構成します。そのため、WEM Adminインタフェースでは、メニュー・バー上のリンクを介してから認可アイテムが(アプリケーションとともに)公開されます。

図56-2 WEM Adminの「アプリケーション」ページ

図56-3 に示すようにアイテムを結合することによって、ユーザーにアプリケーションの使用を許可します。

図56-3 認可モデル

結合処理が完了すると、ユーザーはデータベース・レベル、RESTレベルおよびアプリケーション・レベル(図56-4)で認可されます。

図56-4 ロール、グループおよびACL

習熟したWebCenter Sites開発者であれば、WEMフレームワークによって、アプリケーションへのアクセスを制御するためのサイトおよびロールの用途が拡張されることがわかります。ただし、WebCenter Sitesとは異なり、WEM Adminインタフェースはデータ・モデルを公開しません。REST APIが公開します。この点においてWEM Adminは厳密な意味での認可インタフェースとみなすことができ、(ACLおよびグループの構成用に) Adminインタフェースでサポートされます。

開発者がWEM Adminを使用することはほとんどありませんが、ユーザー認可の背後にある概念を理解しておくことにより、アプリケーション開発に役立つ場合があります。以降の各章では、アプリケーション開発に関係するWEMフレームワークについて説明し、アプリケーション・コードの例を示します。

56.2 アプリケーション開発の前提条件

アプリケーション開発には、アプリケーション・ロジックのコーディング、アプリケーションのデプロイに加え、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、アプリケーションを登録してWEM Adminで公開することも含まれます。この情報は、アプリケーション開発のチュートリアルではなく、経験を積んだアプリケーション開発者がWEMフレームワークの使用方法を習熟できるようにするためのリファレンスです。これらの章のユーザーは、WebCenter Sitesに習熟し、この項に記載されているテクノロジについて実践的な知識を持った開発者である必要があります。

この項には次のトピックが含まれます:

- テクノロジ

- WebCenter Sitesインタフェース、オブジェクトおよびAPI

- ドキュメント

- サンプル・アプリケーションおよびファイル

- アプリケーション・アクセス

56.2.1 テクノロジ

- Representational State Transfer (REST)。WebCenter Sitesプラットフォームとの通信に使用されます

- Central Authentication Service (CAS)。WebCenter Sitesのインストール時にデプロイされ、WEMのシングル・サインオンをサポートします

- Java Server Pages Standard Tag Library (JSTL)、Java、JavaScript、JerseyおよびSpring MVCフレームワーク。WEMに付属のArticlesサンプル・アプリケーションのコードを実行します

56.2.2 WebCenter Sitesインタフェース、オブジェクトおよびAPI

開発者は次に関する実践的な知識を持っている必要があります。

- WebCenter Sites Admin (管理インタフェース)

- WebCenter Sitesのベーシック・アセット・モデルおよびフレックス・アセット・モデル

- アセットAPI

- ACL。データベース表を保護し、表に対して実行可能な操作のタイプを定義します。

- サイトおよびロールの概念

56.2.3 ドキュメント

この項では、次のドキュメントについて説明します。

- 『Oracle WebCenter Sites REST APIリソース・リファレンス』

- Oracle WebCenter Sites Java APIリファレンス

ACL、サイト、ロールの詳細およびこれらのWebCenter Sitesでの使用方法については、『Oracle WebCenter Sitesの管理』を参照してください。

56.2.4 サンプル・アプリケーションおよびファイル

- このガイドのこの部分では、次のサンプル・アプリケーションを使用します。

- Articles。軽量なコンテンツ管理アプリケーションです。

- SSOサンプル・アプリケーション。本番サイト用のサイズの小さい認証アプリケーション。アプリケーションは、wem-sso-api-cas-sample.warとしてパッケージ化されます。

- Recommendations。RESTリソースの作成プロセスを示します。

- このガイドでは、ログイン動作のカスタマイズについて説明する際に、Customizable Single Sign-Onファシリティを使用します。

- WEMフレームワークには、弊社のAPIを使用したクロスドメインの実装方法およびRESTを介したアセットの管理方法を示すサンプル・ファイルが同梱されています。

すべてのサンプル・アプリケーションおよびファイルは、WebCenter Sitesインストール・ディレクトリ内のMisc/Samples/WEM Samplesフォルダにあります。

56.2.5 アプリケーション・アクセス

このガイドのこの部分の情報を使用する場合、または開発およびテストを行う場合は、次のように、WEM Adminインタフェースにアクセスし、アプリケーション登録プロセスの結果をテストします。

1. Webブラウザで、次のURLにアクセスします。
http://wcs-server:wcs-port/wcs-context-root/

2. fwadmin(または同等のユーザー)でログインします。

3. 表示されたページで、AdminSite、「管理」 (最初のアイコン)の順に選択します。

4. WEM Adminの「サイト」ページが表示されます(図56-5)。登録済アプリケーションが「アプリケーション」ページに一覧表示されます。

図56-5 「サイト」ページ

56.3 はじめに

このガイドのこの部分は、順序に関係なくお読みいただけます。

- WEMフレームワークの詳細は、「WEMフレームワークとサービスの理解」を参照してください。

- Articlesアプリケーションのデモについては、「Articlesサンプル・アプリケーションでの作業」を参照してください。

- Articlesアプリケーション・コード、プログラムによるアプリケーション登録、およびクロスドメイン実装の詳細は、「WEMフレームワークでのアプリケーションの開発」を参照してください。手動でのアプリケーション登録の例については、「WEMフレームワークでのアプリケーションの手動登録」を参照してください。

- RESTリソースの作成の詳細は、「WEMフレームワークを使用したカスタムRESTリソースの開発」を参照してください。

- SSOサンプル・アプリケーションのデモについては、「本番サイトでのシングル・サインオンの使用」を参照してください。

- システム・セキュリティの詳細は、「WEMフレームワークでのRESTリソースの使用」を参照してください。

- WEMフレームワークのログイン動作のカスタマイズの詳細は、「WEMフレームワークへのCustomizable Single Sign-Onファシリティの導入」を参照してください。

- バッファリングの詳細は、「WEMフレームワークでのバッファリング」を参照してください。

57 WEMフレームワークとサービスの理解

アプリケーション開発者の環境は、RESTサービスを使用してWebCenter Sites上で実行されるWEMフレームワークで構成されます。WebCenter SitesへのRESTコールは、アプリケーションで任意の言語で記述することで実行できます。カスタム構築アプリケーションは、プラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイ可能であるため、プラットフォームのデプロイメント・インフラストラクチャとは別に記述できます。

WEMフレームワークとサービスの詳細は、次の項を参照してください。

- アプリケーション開発のサポート

- RESTサービス

- UIコンテナ

- シングル・サインオン

- 認可モデル

- カスタム・アプリケーション

- RESTリソースの要件

57.1 アプリケーション開発のサポート

アプリケーション開発のサポートは、次のコンポーネントで行われます(この章のそれぞれの項も参照してください)。

- RESTサービス: WebCenter Sitesオブジェクトへのアクセスを提供する一連のプログラム・インタフェース。

- UIコンテナ: 登録済アプリケーションを公開します。登録によって、アプリケーションのインタフェースのレンダリングが可能になります。また、UIコンテナは、ログイン済ユーザーや現在のサイトに関する詳細情報をWEMフレームワークから取得するためにアプリケーションで使用する、WEMコンテキスト・オブジェクトもサポートしています。

- シングル・サインオン(SSO): 認証されたユーザーが1回ログインするのみで、そのセッション中に許可されるすべてのアプリケーションにアクセスできるようになります。(WebCenter Sitesインストール・プロセスでは、WEMのシングル・サインオンをサポートするCentral Authentication Service Webアプリケーションがインストールされます。)

- REST認可モデル: グループ・メンバーシップに基づいて、RESTリソースへの詳細なアクセス制御を提供します。アプリケーション開発は、事前定義済ユーザーがコードで指定されている場合を除き、(WEM AdminおよびAdminインタフェースでグラフィカルに構成されている)認可には直接関係していません。

WEM AdminもWEMフレームワークの一部ですが、アプリケーション開発に使用されることはほとんどなく、主に、アプリケーション登録プロセスの結果をテストしたり、サイト、ユーザー、グループ、ロールに関する管理情報を取得したりするために使用されます。WEM AdminおよびWebエクスペリエンス管理フレームワークの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

57.2 RESTサービス

REST APIでは、次のWebCenter Sitesデータ・モデルが公開されます。

- ベーシック・アセット・タイプおよびベーシック・アセット(読取り/書込み)

- フレックス・アセット・タイプおよび定義(読取り専用)

- フレックスの子と親(読取り/書込み)

- 索引付けによるアセット検索のサポート

次のオブジェクトも、REST APIで公開されます。これらは、主に認可プロセスで管理者が使用します(オブジェクトはWEM Adminインタフェースに表示されます)。

- サイト(読取り/書込み)

- ユーザー(読取り/書込み)

- ロール(読取り/書込み)

- ACL (読取り専用)

- グループ(読取り専用): RESTレイヤーへのアクセスを制御するためにこのリリースで導入されました。

- 補助サービス: ユーザー・ロケールおよびサーバーのタイムゾーン

(サイト、ロールおよびユーザーはWEM Adminで構成できます。ACLおよびグループは、読取り専用アイテムとしてWEM Admin (「ユーザー」の下)に公開されます。それらは、Adminインタフェースで構成する必要があります。)

WebCenter Sitesのオブジェクトは、WEM内のRESTリソースにマップされます。パブリッシュ、ワークフロー、データベース管理ツール、ページのキャッシングなど、他のすべての機能には、Adminインタフェースから、またはJSPやXMLタグを介してアクセスする必要があります。

一般管理者が管理する認可オブジェクトの中で、サイトおよびロールが、要件によってはアプリケーション管理の候補となる可能性が高いです。また、管理者の認可タスクを簡素化するために、事前定義済ユーザーを指定することもできます。

- サイト: アプリケーション・コードでのサイトの使用は、アプリケーションのアセット・タイプとアセットをプログラムでインストールする必要がある場合の要件です。コードでアセット・タイプを有効にするサイトを1つ以上指定する必要があります(アセットへのサイト固有のアクセスを行うには、それらのアセット・タイプが1つ以上のサイトで有効になっている必要があります)。そうでない場合は、サイトを指定しないで、アセット・タイプを単にインストールします。その後、管理者は、Adminインタフェースを使用して、独自に選択したサイト上でアセット・タイプとアセットを有効にします。

- ロール: WEMでは、ロールはアプリケーションへのアクセスを管理するために使用します。同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。アプリケーション・コードでロールを使用すると、Editなどの、インタフェース機能を保護できます。Adminインタフェースは、ロールで保護されたインタフェース機能を備えたアプリケーションの一例です。

- ユーザー: アプリケーション・コードで指定する可能性のある唯一のユーザーは、管理者の認可プロセスを簡略化するための事前定義済ユーザーです。ユーザーの指定には、ユーザー名とパスワードのコーディングが含まれます。管理者は、すべてのアプリケーション・ユーザーをRESTレベルで個別に認可するかわりに、事前定義済ユーザーを認可します。事前定義済ユーザーに付与された権限は、ユーザーがアプリケーションにアクセスするとログイン済ユーザーに引き継がれます。事前定義済ユーザーおよび認可モデルの詳細は、「認可モデル」を参照してください。

システム全体においてサイトとロールがどのように使用されているかを追跡するのは管理者のタスクですが、これにはアプリケーション開発者によるサポートが必要です。トラッキングは、WebCenter Sitesプラットフォームがステージング・システムとしても機能する場合に特に重要ですが、これは、WEMフレームワークがWebCenter Sitesデータベースを使用しているからです。たとえば、WEM Adminで作成されたサイトはデータベースに格納されます。それらはステージング用にWebCenter Sitesで使用されるとはかぎりませんが、Adminインタフェースで専用のCMサイトと一緒に公開されます。反対に、CM用途でAdminインタフェースで作成されたサイトは、WEM Adminで公開され、その他のアプリケーションをそれらのサイトに割り当てることができます。ユーザーが適切に認可されるには、開発者はカスタム構築アプリケーションの性質を管理者に伝達する必要があります。そのような性質には、ユーザーが使用するリソース、ロールで保護されたインタフェース機能、事前定義済ユーザー(存在する場合)などが含まれます。

57.3 UIコンテナ

UIコンテナでは、登録済アプリケーションが公開され、WEMフレームワークから情報を取得するためにアプリケーションで使用されるコンテキスト・オブジェクトがサポートされます。

この項には次のトピックが含まれます:

- 登録

- WEMコンテキスト・オブジェクト

57.3.1 登録

アプリケーションを登録する目的は、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、WEM Adminでアプリケーションを公開することです。登録を行うと、そのアプリケーションがアセットとして認識され、次のことが実行されます。:

- WEM Adminの「アプリケーション」ページにアプリケーションが一覧表示されます(図57-1)

- アプリケーションを表すために選択したアイコンが配置されます

- WebCenter Sitesのログイン・ページ、およびアプリケーションが割り当てられている各サイトのアプリケーション・バー(図57-1)にアプリケーションのアイコンが表示されます

- アプリケーションのアイコンが選択された際にアプリケーションのインタフェースがレンダリングされます

図57-1 UIコンテナの登録済アプリケーション

アプリケーションの登録には、そのビューの登録が含まれています。複数の共有ビューがサポートされますが、単一の非共有ビューを使用するアプリケーションが一般的です(ガイドのこの部分でも使用しています)。iframe、HTMLおよびJavaScriptタイプのビューを使用できます。

登録をサポートするために、WEMフレームワークには、ベーシック・アセット・タイプFW_ApplicationとFW_Viewが付属しています。いずれも、WebCenter Sitesインストール・プロセスでWEMオプションを選択した場合に作成されます。これらは、AdminSiteにおいてデフォルトで有効になります(WebCenter Sitesのインストール・プロセスでも作成されます)。

アプリケーションを登録するには(デプロイされている場合)、FW_Applicationのインスタンスの作成、各ビュー用のFW_Viewインスタンスの作成、およびFW_ApplicationインスタンスへのFW_Viewインスタンスの関連付けが必要です。他のサイトでアプリケーションを使用する場合でも、そのアプリケーションをAdminSiteで登録する必要があります。登録すると、アプリケーションを他のサイトに割り当てることができます。

アプリケーションは、REST APIのapplicationsサービスを介してプログラムで登録することも、Adminインタフェースから手動で登録することもできます。プログラムによる登録をお薦めします。一般的な手順は、「様々なビューを使用したアプリケーションの登録」を参照してください。手動登録の例は、「WEMフレームワークでのアプリケーションの手動登録」を参照してください。

57.3.2 WEMコンテキスト・オブジェクト

UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、ログイン・ユーザーやサイトに関する詳細情報をWEMフレームワークから取得する際にアプリケーションで使用されます(たとえば、UIコンテナからの現在のサイトの名前など)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する様々なユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。詳細は、「WEMフレームワークからのパラメータへのアクセス」を参照してください。

57.4 シングル・サインオン

シングル・サインオンは、Central Authentication Service (http://www.jasig.org/cas)を使用して実装されます。サンプルArticlesの例で示すように、WEMフレームワークに付属するサーブレット・フィルタは、Java Webアプリケーションとしてデプロイされたアプリケーションに対してすぐに使用できます。アプリケーションが別のテクノロジを使用して開発されている場合は、次のURLにある、選択したテクノロジに固有のCASクライアントを参照してください。

http://www.ja-sig.org/wiki/display/CASC/Official+Clients

ユーザーがCASで保護されているアプリケーションにアクセスしようとすると、認証システムが次の手順で応答します。

1. 初回アクセス

a. ユーザーがCASで保護されているアプリケーションに最初にアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。

b. ログインが成功すると、ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。CASログイン・ページのCookieが保存されます。

c. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。(コンテンツ管理システムでは、CASはデフォルトでWebCenter Sitesデータベースに対して認証を行います。)

図57-2 CASで保護されているアプリケーションへのアクセス

2. 2回目以降のアクセス

a. CASで保護された別のアプリケーションにユーザーがアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。

b. リクエストからCookieが取得されて暗黙的ログインが実行され、ログイン・ページは省略されます。

c. ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。

d. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。

57.5 認可モデル

認可とは、アプリケーションへのアクセスをユーザーに付与するプロセスです。一般管理者は、図57-3に示すようにWEM Adminを使用してオブジェクトを結合することにより、認可を行う必要があります。開発者は、アプリケーションで事前定義済ユーザーをコーディングすることにより、管理者のタスクを簡素化できます。以降では、ユーザーを認可モデルに適合させる方法について説明します。

図57-3のサイト、アプリケーション、ユーザーおよびロールには、それぞれに対応するWEM Adminのメニュー・オプションがあります。ACLおよびグループは、各ユーザーのページで公開されます。

図57-3 認可モデル

図57-4 WEM Adminメニュー・バー

認可は3つのレベル(アプリケーション、RESTおよびデータベース)で管理されます。

- アプリケーション・レベルの認可では、同じサイト上のユーザーとアプリケーションでロールを共有する必要があります。これにより、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。ロールで保護されているインタフェース機能のロールは、アプリケーション・ユーザーと共有されている必要があります。

- RESTレベルの認可では、ユーザーがアプリケーションのリソースを操作するための権限を制限します(ACLが正しく割り当てられていることが前提です)。 RESTレベルの認可では、RESTリソースにマップされるオブジェクトへの操作権限を持つグループを構成する必要があります。グループに割り当てられたユーザーにはグループの権限が付与されます。
開発者は、ログイン済ユーザーのプロキシとして動作するユーザーをアプリケーションで定義できます(ユーザー名とパスワードを指定する)。これにより、管理者がログイン済ユーザーごとにRESTセキュリティを構成する必要がなくなります。アプリケーションがデプロイおよび登録されると、一般管理者は次の方法で事前定義済ユーザーを認可します。1) WEM Adminで、アプリケーションにアクセスするための事前定義済ユーザーを構成し、2)アプリケーションのリソースの操作権限を持つグループを(Adminインタフェースで)構成して、3)事前定義済ユーザーを(WEM AdminまたはAdminインタフェースのいずれかを使用して)そのグループに割り当てます。グループの権限は事前定義済ユーザーに渡され、ログイン済ユーザーがアプリケーションにアクセスする際に、そのログイン済ユーザーに渡されます。サポートされているセキュリティ構成は、「REST認可」に説明およびリストされています。WEMフレームワークで提供されているArticlesサンプル・アプリケーションでは、事前定義済ユーザーを指定します。

- データベース・レベルでは、そのユーザーのグループ・メンバーシップにかかわらず、ACLによって個々のユーザーのシステムへのアクセス(つまり、ログイン権限、データベースの操作権限)が決定されます。グループのメンバーシップでは、適切なACLが割り当てられていないユーザー、およびデータベース表への権限を付与しません。
デフォルトのACLでは、多くのデータベース表のオブジェクトに対してほぼ無制限の操作権限(手段ではない)がユーザーに提供されます。それらの権限を調整するには、RESTレベルで、ユーザーのグループ・メンバーシップによって直接調整するか(事前定義済ユーザーが存在しない場合)、アプリケーションの事前定義済ユーザーとそのユーザーのグループ・メンバーシップによって間接的に調整します。オブジェクトに対するグループの操作権限を変更すると、そのグループ・メンバーのリソースに対する操作権限も変更されます。WebCenter Sites側の同一ユーザーはグループ・メンバーシップによる影響は受けません。コンテンツに対する権限は、引き続きACLによって制限され、サイトとロールによって機能します。

57.6 カスタム・アプリケーション

WEMで開発されるカスタム・アプリケーションは、通常、コンテンツ管理プラットフォームに対して疎結合された形で実装されます。カスタム・アプリケーションは、WEMフレームワークで有効化されたREST API WebサービスとSSOメカニズムを利用するため、一般的にプラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイされます。そのため、開発者はプラットフォームのデプロイメント・インフラストラクチャから完全に切り離してカスタム・アプリケーションを作成できます。ほとんどのカスタム・アプリケーションはリモートでデプロイされます(図57-5 )。

図57-5 リモートでのアプリケーションのデプロイメント

カスタム・アプリケーションは、コンテンツ管理アプリケーションまたは配信アプリケーションとして実装できます。一般的に、コンテンツ管理側ではパフォーマンス・チューニングの手間がそれほどかからないため、コンテンツ管理側から着手することをお薦めします。

WEMフレームワークには、いくつかの軽量のサンプル・アプリケーションが付属しており、それぞれ専用アプリケーションを開発するためのモデルとして起動および分析できます。Articlesは、コンテンツ管理アプリケーションを示しています。仕様については、「WEMフレームワークでのアプリケーションの開発」を参照してください(ソース・コードはWebCenter Sites Misc/Samplesフォルダにあり、その他のサポート情報はREST APIリソースおよびBeanリファレンスに記載されています)。SSOサンプル・アプリケーションはライブ・サイトでの認証用で、RecommendationsアプリケーションはRESTリソースの作成方法を示しています。

57.7 RESTリソースの要件

すべてのREST POST/PUT/DELETEリクエストを有効であると認証するには、各リクエストには、X-CSRF-Tokenキーを持つヘッダーと、CASチケット(マルチまたはシングル)またはsessionidのいずれかの値が必要です。

58 Articlesサンプル・アプリケーションでの作業

Articlesサンプル・アプリケーションは、記事アセットの管理を可能にする単純なコンテンツ管理アプリケーションです。このアプリケーションは、詳細に文書化されたソース・コードと自己インストール・プロセスを備えており、アプリケーション開発に最も重要な情報を素早く習得する上で役に立ちます。

Articlesサンプル・アプリケーションでの作業の詳細は、次の項を参照してください。

- Articlesサンプル・アプリケーションについて

- Articlesサンプル・アプリケーションの起動

- Articlesアプリケーションのテスト

58.1 Articlesサンプル・アプリケーションについて

Articlesホーム・ページには、図58-1で示したカスタム・インタフェースから、WEMで直接編集可能な2つの記事が表示されます。このアプリケーションでは、WebCenter Sites REST APIを使用して、Javaコードから検索問合せを実行し、JavaScriptコードからアセット変更問合せを実行する方法を示します。ArticlesアプリケーションとRESTサービスは、別々のアプリケーション・サーバーで実行させることができます。JavaScriptのクロスドメイン制限により、ArticlesアプリケーションからRESTサービスに対してAJAXを直接コールできません。したがって、JavaScriptからのコールをWEM REST Webサービスにリダイレクトするために単純なProxyControllerが導入されています。このコントローラ実装はカスタム実装で再利用できます。

アプリケーションのホーム・ページは、図58-1に示すように表示されます。

図58-1 「Home」ページ

Articlesアプリケーションは、Spring MVCフレームワークに基づいています。Articlesには、fwadminという名前でxceladminというパスワードを持つ事前定義済管理ユーザーが含まれます。このユーザーはRestAdminというRESTグループに割り当てられています。　アプリケーションの自己インストーラには、Articlesアプリケーションを登録し、そのアセット・モデルとサンプル記事をインストールするための仕様が含まれます。このアプリケーションには、内部的に構成されたサイトやロールで保護された機能は存在せず、単一のiframeビューがあります。その他の仕様については、「Articlesサンプル・アプリケーションでの作業」を参照してください。

58.2 Articlesサンプル・アプリケーションの起動

次の項では、Articlesアプリケーションの作成およびデプロイに続き、インストーラの実行について説明します。

- Articlesアプリケーションのビルドおよびデプロイ

- Articlesサンプル・アプリケーションの登録

58.2.1 Articlesアプリケーションのビルドおよびデプロイ

1. サンプルのArticlesアプリケーションの割当て先となるサイトを選択または作成します。デフォルトのサイトはFirstSiteII (WebCenter SitesのサンプルのCMサイト)です。FirstSiteIIはシステムにインストールされていない場合があります。

サイトを選択または作成するには、次のURLにアクセスしてWEM Adminにログインします。

http://<server>:<port>/<cs_application_context>/login

このとき、一般管理者の資格証明(デフォルト値はfwadmin/xceladmin)を使用します。

注意:

手順5では、ここで選択したサイトを指定します。これにより、インストーラを実行した際に、指定したサイトでアプリケーションのアセット・モデルとアセットが有効になります。

2. Java Development Kit 8 Update 51 (以降)をダウンロードおよびインストールします。

3. 最新のApache Antをhttp://ant.apache.org/からダウンロードして、AntのbinディレクトリをシステムのPATHに置きます。

4. servlet-api.jarをArticlesアプリケーションのlibフォルダにコピーします。このjarファイルはアプリケーション・サーバーのホーム・ディレクトリから取得できます(たとえば、Tomcatのservlet-api.jarはhome libディレクトリにあります)。

5. applicationContext.xmlファイル(src\articles\src\main\webapp\WEB-INF\)で次のパラメータを設定します。

- casUrl: CASアプリケーションのURLを指定します。http://<server>:<port>/<context_path>

- csSiteName: 手順1で選択したサイトの名前を指定します。

- csUrl: WebCenter Sitesプラットフォームが実行されているURLを指定します: http://<server>:<port>/<context>

- csUserName: デフォルト値はfwadminです。これはアプリケーションの事前定義済ユーザーで、RestAdminグループにメンバーシップを持つ一般管理者です。このグループのRESTサービスへの権限は制限されていません。別のユーザーを指定する場合は、fwadminと同等のユーザーを指定する必要があります。一般管理者の作成手順は、『Oracle WebCenter Sitesの管理』を参照してください。

- csPassword: 事前定義済ユーザーのパスワードを指定します。

- articlesUrl: サンプル・アプリケーションにアクセスする際のURLを指定します。

6. デフォルトのターゲットを指定してAntビルドを実行します(コマンド・ラインでantと入力します)。

7. 生成されたtarget/articles-1.0.warをアプリケーション・サーバーにデプロイします。

デプロイメント時に、次のコンテンツがソースからターゲットにコピーされます。libフォルダの内容は/WEB-INF/lib/にコピーされます。resourcesフォルダの内容は/WEB-INF/classes/にコピーされます。ソース・アプリケーションの構造の詳細は、「WEMフレームワークでのアプリケーションの開発」を参照してください。

注意:

cas-cache.xmlのmcastポートはインストーラによって置換されません。mcastポートは@casCacheMultiCastGroupPort@として残され、手動で編集しないかぎり、デプロイは失敗します。

この解決策は、cas-cache.xmlをWebCenter SitesからArticlesアプリケーションにコピーすることです。これにより、mcastアドレスおよびポートの手動更新に関連する問題を解消できます。

8. customBeans.xmlファイル(sitesinstall/configフォルダ内にあります)で、信頼できるURLを指定します。正常にログインした訪問者は、CASによってこのURLにリダイレクトされます。たとえば、次のURLをcustomBeans.xmlファイルに追加します。

<value>http://<hostname>:<portnumber>/articles-1.0/*</value>

58.2.2 Articlesサンプル・アプリケーションの登録

Articlesアプリケーションには自己インストーラが用意されており、install.appページにログインすると実行されます。インストーラによってサンプル・アプリケーション(ビューを含む)が登録され、そのデータ・モデルとアセットがWebCenter Sitesデータベースに作成されます。

注意:

登録アセット・タイプFW_ViewおよびFW_Applicationの仕様は、Oracle WebCenter Sites Java APIリファレンスおよび「WEMフレームワークでのアプリケーションの手動登録」を参照してください。

Articlesインストーラを実行するには::

1. 次のようにinstall.appページに移動します。

http://<hostname>:<portnumber>/<context_path>/install.app

次に例を示します。

http://localhost:9080/articles-1.0/install.app

2. 任意の資格証明を使用してログインします。
csUserNameおよびcsPasswordで指定した(「Articlesアプリケーションのビルドおよびデプロイ」を参照)、アプリケーションの事前定義済ユーザーにはアプリケーションに対する権限が付与されています。サンプル・アプリケーションではロールを使用しないため、認可チェックは実行されません。

3. 自己インストール・プロセスによってInstallController.javaが起動されます。まずアプリケーション(アプリケーションBeanのビューを含む)が登録され、続いてサンプルのアセット・タイプとアセットがデータベースに書き込まれます。

a. InstallController.javaは、次のようにArticlesアプリケーションをWEMフレームワークに登録します。

- InstallController.javaは、Articlesというアプリケーション・アセット(アセット・タイプFW_Application)をWebCenter Sitesデータベースに作成します。
iconurl属性は、アプリケーションを表すアイコンが配置されるURLを示します。

layouturl属性は、layout.appページ(LayoutController.javaで実装される)のURLを指定します。layout.appページにはアプリケーションのレイアウトを定義します。

layouttype属性は、デフォルト値layoutrendererのみをとります。layoutrenderer値を使用すると、アプリケーションに関連するビューがUIコンテナでレンダリングされる際に、layouturlで指定されているlayout.appページが使用されます。

- InstallController.javaは、ArticlesViewというビュー・アセット(アセット・タイプはFW_View)をWebCenter Sitesデータベースに作成します。ビュー・アセットとアプリケーション・アセットとの関連付けは、FW_Applicationアセット・タイプのviews属性によって行われます。

b. InstallController.javaは、次のようにアプリケーションのアセット・モデルとサンプル・アセットをインストールします。

- アプリケーションのFW_Articleアセット・タイプをWebCenter Sitesデータベースに作成します。(FW_Articleは、InstallController.javaで定義されているベーシック・アセット・タイプです。)

- applicationContext.xmlのcsSiteNameパラメータ(「Articlesアプリケーションのビルドおよびデプロイ」の手順5)で指定されているサイトでFW_Articleアセット・タイプを有効にします。

- 記事アセットの2つのサンプルをFW_Articleアセット・タイプ表に書き込みます。(記事のテキストとイメージは、/sample app/articles/src/main/resources/installに格納されます)

c. InstallController.javaは、アセット・タイプFW_Articleの検索をサポートするアセット・タイプに基づいた索引を作成します。(コントローラは、索引構成データを指定します。)

4. インストール・プロセスが正常に完了すると、InstallController.javaにより、サンプル・データが正常にインポートされたこと、およびホーム・ページ(home.app)にリダイレクトされることの確認が(http://<server>:<port>/articles/install.app)に)表示されます。

58.3 Articlesアプリケーションのテスト

Articlesアプリケーションをテストするには:

1. 次のようにhome.appページに移動します。

http://<hostname>:<portnumber>/<context_path>/home.app

次に例を示します。

http://localhost:8080/articles-1.0/home.app

2. 任意の資格証明を使用してログインします。

csUserNameおよびcsPasswordで指定した(「Articlesアプリケーションのビルドおよびデプロイ」を参照)、アプリケーションの事前定義済ユーザーにはアプリケーションに対する権限が付与されています。サンプル・アプリケーションではロールを使用しないため、認可チェックは実行されません。

アプリケーションのホーム・ページがWEMに表示されます。

3. このアプリケーションを使用して実験を行う場合(たとえば、別のサイトに割り当てて、ユーザーを追加する場合)、WEM Adminを使用します。Webエクスペリエンス管理フレームワークの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

59 WEMフレームワークでのアプリケーションの開発

Articlesサンプル・アプリケーションは、RESTコールを実行するアプリケーションの基本アーキテクチャについて説明するために使用されます。

WEMフレームワークでのアプリケーションの開発の詳細は、次の項を参照してください。

- Articlesサンプル・アプリケーションの構造について

- Articlesサンプル・アプリケーションの構成ファイルについて

- RESTコールの実行

- バイナリ・データを処理するURLの作成

- WEMフレームワークからのパラメータへのアクセス

- 様々なビューを使用したアプリケーションの登録

59.1 Articlesサンプル・アプリケーションの構造について

図59-1は、Articlesサンプル・アプリケーションのソース構造を示しています。デプロイメント時に、次のディレクトリはソースからターゲットにコピーされます。libディレクトリの内容は/WEB-INF/lib/にコピーされます。resourcesディレクトリの内容は、/WEB-INF/classes/にコピーされます。

図59-1 Articlesサンプル・アプリケーションのソース構造

Articlesは、Spring MVCで開発されたJava Webアプリケーションです。次のページを使用できます。

- /install.appは、Articlesのインストール・ページで、また、アプリケーションが正常にインストールされた場合に確認メッセージが表示されます。

- /home.appは、Articlesアプリケーションのホーム・ページです(図59-3)。

59.2 Articlesサンプル・アプリケーションの構成ファイルについて

- applicationContext.xml(/WEB-INF/)には、SSO構成およびアプリケーション固有の構成(事前定義済ユーザーや、データ・モデルおよびアセットが有効化されるサイトなど)が保持されます。

- spring-servlet.xml (/WEB-INF/)は、デフォルトのSpring構成ファイルです。このファイルはSpring構成を格納し、次のコントローラを参照します(「ソース・ファイル」を参照)。

- HomeController

- InstallController

- LayoutController

- ProxyController

- loggingconfig.xml (/<sitesshared>/config内)は、ロギング構成ファイルです。アプリケーションのデプロイ時に、/<sitesshared>/configからwebcentersites\sites-home\template\configにコピーされます。

ソース・ファイル

/sample app/articles/src/main/java/

/sample/フォルダには、次に示すソース・ファイルが含まれます。

- Configuration.javaは、(Springフレームワークによって)applicationContext.xmlファイルから移入されます(「Articlesサンプル・アプリケーションの構成ファイルについて」を参照)。

- HomeController.javaは、単一のホーム・ページをレンダリングするホーム・ページ・コントローラです。このコントローラは、REST APIを使用してWebCenter Sitesプラットフォームからサンプル記事のリストを読み込み、それらをホーム・ページに表示します。
サンプル記事は、/sample app/articles/src/main/resources/installに格納されているイメージとテキストで構成されます。サンプル記事は、InstallController.javaによって、WebCenter Sitesデータベースにインストールされます。

- InstallController.javaはArticlesアプリケーションを登録し、アプリケーションのアセット・モデルとサンプル・アセットをデータベースに書き込みます。

- LayoutController.javaは、WEM UIフレームワークで使用されるアプリケーションのレイアウト・ページ(layout.app)を表示します。LayoutController.javaは、アプリケーションの登録時にも使用されます。

- ProxyController.javaは、AJAXリクエストをWebCenter Sites RESTサーブレットに委任します。

- TldUtil.javaユーティリティ・クラスにはTLD機能の実装が含まれます。

インストーラのリソース

/sample app/articles/src/main/resources/install

/install/フォルダには次のリソースが含まれます。これらのリソースはホーム・ページを構成する際に、InstallControllerで使用されます(図59-3)。

- strategies.png

- strategies.txt

- tips.png

- tips.txt

ホーム・ページ・ファイル

/sample app/articles/src/main/webapp/images

/images/フォルダには次のファイルが含まれます。

- articles.pngアイコン(図59-2)。アプリケーション・バーでArticlesアプリケーションを表します

- 次に、図59-3について説明します。

- edit.pngは、「編集」機能用のアイコンです。

- save.pngは、「保存」機能用のアイコンです。

- cancel.pngは、「取消」機能用のアイコンです。

スクリプト

/sample app/articles/src/main/webapp/scripts

/scripts/フォルダには、文字列とJSONオブジェクトとの変換に使用されるjson2.jsユーティリティ・スクリプトが含まれます。

スタイル

/sample app/articles/src/main/webapp/styles

/styles/フォルダには、このWebアプリケーションで使用されるCSSスタイルを指定するためのmain.cssが含まれます。

ビュー

/sample app/articles/src/main/WEB-INF/jsp

/jsp/フォルダには次のファイルが含まれます。

- home.jsp。Articlesアプリケーションのホーム・ページ・ビューをレンダリングする際に使用されます(図59-3)。

- layout.jsp。アプリケーションのレイアウトを定義します。

WEB-INF

/sample app/articles/src/main/WEB-INF

/WEB-INF/フォルダには次のファイルが含まれます。

- articles.tld。TLD宣言ファイルです。

- spring-servlet.xml。Spring構成ファイルです。

- web.xml。Webアプリケーションのデプロイメント・ディスクリプタです。

図59-2 Articlesのアイコン(articles.png)

図59-3 Articlesのホーム・ページ

59.3 RESTコールの実行

WebCenter Sites RESTリソースは、XMLおよびJSONという2種類の入出力フォーマットをサポートしています。特定の戻りフォーマットを取得するには、MIMEタイプapplication/xmlまたはapplication/jsonを指定するHTTPヘッダーを設定する必要があります。たとえば、入力フォーマットをXMLに指定する場合は、Content-Typeをapplication/xmlに設定します。出力フォーマットを指定する場合は、Accept (予期されるフォーマット)をapplication/xmlに設定します。その他の出力フォーマットを指定すると、それらは無視されます。Content-TypeまたはAcceptで何も指定されていない場合のデフォルトはXMLです(サンプル・コードについては、「JavaScriptからのRESTコールの実行」を参照)。

RESTコールの詳細は、この項の次のトピックを参照してください。

- JavaScriptからのRESTコールの実行

- JavaからのRESTコールの実行

59.3.1 JavaScriptからのRESTコールの実行

- 次のコード(home.jsp内)を使用して、アセットのRESTサービスに対してAJAXコールを実行し、アセット・データを保存します。実際には、プロキシ・コントローラに対してリクエストが実行され、プロキシ・コントローラから宛先のRESTサービスにリクエストがリダイレクトされます。

注意:

JSONのstringifyライブラリ(http://json.org/js.html)を使用して、JavaScriptオブジェクトを文字列としてシリアライズします。文字列のかわりにJSONオブジェクトを記述する方が便利です。

// Form the URL pointing to the asset service
// to the proxy controller, which will redirect this request to the CS REST servlet.
var idarr = assetId.split(":");
var assetUrl = "${pageContext.request.contextPath}/REST/sites/${config.csSiteName}/types/" + idarr[0] + "/assets/" + idarr[1];

// For the data object to be posted.
var data =
{
"attribute" :
[
{
"name" : "source",
"data" :
{
"stringValue" : document.getElementById("source_e_" + assetId).value
}
},
{
"name" : "cat",
"data" :
{
"stringValue" : document.getElementById("cat_e_" + assetId).value
}
}
],
"name" : document.getElementById("name_e_" + assetId).value,
"description" : document.getElementById("desc_e_" + assetId).value,
// This should be removed.
"publist" : "${config.csSiteName}"
};
// Convert JSON data to string.
var strdata = JSON.stringify(data);

// Perform AJAX request.
var req = getXmlHttpObject();
req.onreadystatechange = function ()
{
if (req.readyState == 4)
{
if (req.status == 200)
{
// On successful result
// update the view controls with new values and switch the mode to 'view'.
for (c in controls)
{
document.getElementById(controls[c] + "_v_" + assetId).innerHTML =
document.getElementById(controls[c] + "_e_" + assetId).value;
}
switchMode(assetId, false);
}
else
{
// Error happened or the session timed out,
// reload the current page to re-acquire the session.
alert("Failed to call " + assetUrl + ", " + req.status + " " + req.statusText);
window.location.reload( false );
}
}
};
// We put Content-Type and Accept headers
// to tell CS REST API which format we are posting
// and which one we are expecting to get.
req.open("POST", assetUrl, true);
req.setRequestHeader("Content-Type", "application/json;charset=utf-8");
req.setRequestHeader("Content-Length", strdata.length);
req.setRequestHeader("Accept", "application/json");
req.send(strdata);
}

59.3.2 JavaからのRESTコールの実行

- 次のコード(HomeController.java)を使用して、アセット検索サービスをコールし、FW_Articleタイプのすべてのアセットをリストします。このコードでは、Jersey Clientライブラリを使用して、WEMフレームワークが提供するrest-api-<version>.jarライブラリからオブジェクトを渡します。この方法を利用すると、Javaでの入力が強化されます。
SSOAssertion.get().createToken()メソッドをコールして、トークンをJavaコードから取得する必要がある点に注意してください。JavaScript側ではWEMのSSOに対してすでに認証が行われているため、同様の処理を行う必要はありません。

// Use Jersey client to query CS assets.
Client client = Client.create();
String url = config.getRestUrl() + "/types/FW_Article/search";
WebResource res = client.resource( url );

// Construct URL and add token (for authentication purposes)
// and fields (specify which fields to retrieve back) parameters.
res = res.queryParam("fields", URLEncoder.encode("name,description,content,cat,source", "UTF-8"));
res = res.queryParam("ticket", SSO.getSSOSession().getTicket(res.getURI().toString(), config.getCsUsername(), config.getCsPassword()));
// Put Pragma: auth-redirect=false to avoid redirects to the CAS login page.
Builder bld = res.header("Pragma", "auth-redirect=false");

// Make a network call.
AssetsBean assets = bld.get(AssetsBean.class);

注意:

カスタム・ヘッダーPragma: auth-redirect=falseは、CAS SSOフィルタにCASサインイン・ページにリダイレクトしないように指示しますが、チケットが指定されていない場合または指定されたチケットが無効の場合は403エラーが返されます。

59.4 バイナリ・データを処理するURLの作成

Articlesアプリケーションは、WebCenter SitesのBlobサーバーを使用してBLOBデータを処理します。

- 次のユーティリティ関数は、特定のアセットの特定の属性のバイナリ・データを指すURLを作成する場合に使用し、blobUrlには、Blobサーバー(デフォルトはhttp://localhost:8080/cs/BlobServer)を指定します。

public String getBlobUrl(String assetType, String assetId, String attrName, String contentType)
throws Exception
{
String contentTypeEnc = URLEncoder.encode(contentType, "UTF-8");

return blobUrl + "?" +
"blobkey=id" +
"&blobnocache=true" +
"&blobcol=thumbnail" +
"&blobwhere=" + assetId +
"&blobtable=" + assetType +
"&blobheader=" + contentTypeEnc +
"&blobheadername1=content-type" +
"&blobheadervalue1=" + contentTypeEnc;
}

- バイナリ・データを取得する別の方法は、リソース/sites/{sitename}/types/{assettype}/assets/{id}を使用してアセットをロードすることです。ロードされたアセットには、BLOBサーバーを指すURLが格納されます。

59.5 WEMフレームワークからのパラメータへのアクセス

UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、ログイン済ユーザーやサイトに関する詳細情報をWEMフレームワークから取得するためにアプリケーションで使用します(通常は、UIコンテナから現在のサイトの名前を取得します)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する各種ユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。

注意:

wemcontext.htmlファイルには公開されるメソッドがリストされています(「コンテキスト・オブジェクトで使用可能なメソッド」でまとめられています)。

この項には次のトピックが含まれます:

- サンプル・ドメイン内のコンテキスト・オブジェクトの初期化および使用

- クロスドメイン・アプリケーションのコンテキスト・オブジェクトの初期化および使用

- コンテキスト・オブジェクトで使用可能なメソッド

59.5.1 サンプル・ドメイン内のコンテキスト・オブジェクトの初期化および使用

WebCenter Sitesドメイン内にあるアプリケーションのコンテキスト・オブジェクトを初期化して使用する手順:

1. wemcontext.jsを含めます。

2. WemContextオブジェクトのインスタンスを取得します。

3. WemContextのメソッドを使用します。

<script src='http://<csinstalldomain>/<contextpath>/wemresources/js/WemContext.js'></script>
<script type="text/javascript">
var wemContext = WemContext.getInstance(); // Instantiate Context Object
var siteName = wemContext.getSiteName(); // Get Site Name
var userName = wemContext.getUserName(); // Get UserName
</script>

59.5.2 クロスドメイン・アプリケーションのコンテキスト・オブジェクトの初期化および使用

クロスドメイン・アプリケーションのコンテキスト・オブジェクトを初期化して使用するには:

1. wemxdm.js、json2.jsおよびhash.htmlを(Misc/Samplesフォルダから)アプリケーションにコピーします。

2. クロスドメイン・コールを実行するために、sample.html ファイルを開いて、次のように変更します。

- wemxdm.js、json.jsおよびhash.htmlのパスを、アプリケーション内でのそれぞれのパスに変更します(手順dの後の例を参照)。

- wemcontext.htmlのパスを、WebCenter Sites内でのこのファイルの場所に変更します(wemcontext.htmlは/wemresources/wemcontext.htmlにあります。WebCenter Sitesのホスト名とコンテキスト・パスを使用します。)

- インタフェース宣言で、フレームワークで使用するメソッドを指定します。

- これらのメソッドをローカル・スコープに実装し、リモート・メソッドを起動します。

<script type="text/javascript" src="../js/wemxdm.js"></script>
<script type="text/javascript">
//  Request the use of the JSON object
WemXDM.ImportJSON("../js/json2.js");
var remote;
window.onload = function() {
// When the window is finished loading start setting up the interface
remote = WemXDM.Interface(/** The channel configuration */
{
// Register the url to hash.html.
local: "../hash.html",
// Register the url to the remote interface
remote: "http://localhost:8080/cs/wemresources/wemcontext.html"
}, /** The interface configuration */
{
remote: {
getSiteName :{},
...

}
},/**The onReady handler*/ function(){
// This function will be loaded as soon as the page is loaded
populateAttributes();
});
}
</script>

<script type="text/javascript">
/** Define local methods for accessing remote methods  */
function getSiteName(){
remote.getSiteName(function(result){
alert("result = " + result);
});
}
...
</script>

59.5.3 コンテキスト・オブジェクトで使用可能なメソッド

表59-1に、コンテキスト・オブジェクトで使用可能なメソッドのリストと説明を示します。

表59-1 コンテキスト・オブジェクトで使用可能なメソッド

戻り型

メソッド名および説明

Object

getAttribute(attributename)

指定された属性名の属性値を返します。

Object

getAttributeNames()

すべての属性名を返します。

Object

getCookie(name)

指定された名前のCookie値を返します。通常のブラウザのCookieの制限がすべて適用されます。

Object

getCookies()

すべてのCookieを返します。

Object

getLocale()

ロケールを返します。

Object

getSiteId()

サイトIDを返します。

Object

getSiteName()

サイト名を返します。

Object

getUser()

ユーザー・オブジェクトを返します。

Object

getUserName()

ユーザー名を返します。

void

removeCookie(name, properties)

Cookieを削除します。

void

setAttribute(attributename, attributevalue)

属性を設定します。これらの属性には、他のアプリケーションからアクセスできます。

void

setCookie(name,value,expiredays,properties)

Cookieを設定します。

59.6 様々なビューを使用したアプリケーションの登録

「認可モデル」で説明しているように、アプリケーションは登録することによってWEMフレームワークで公開されます。アプリケーションを登録すると、FW_Applicationタイプのアセットと、アプリケーションに関連付けられた各ビューに対してFW_Viewタイプのアセットが作成されます。アセット・タイプは、AdminSiteで有効になります。これらの属性は、Oracle WebCenter Sites Java APIリファレンスに定義されています。プログラムによる登録をお薦めします。手動登録の例は、「WEMフレームワークでのアプリケーションの手動登録」を参照してください。

この項には次のトピックが含まれます:

- iframeビューを使用したアプリケーションの登録

- JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録

59.6.1 iframeビューを使用したアプリケーションの登録

この項では、Articlesサンプル・アプリケーションのコードを使用して登録プロセスについて説明します。Articlesには、iframeタイプの単一ビューが含まれます。JavaScriptおよびHTMLのビューにも同じ手順が適用されます。

アプリケーションを登録するには::

1. アプリケーションを表すアイコンを作成または取得します。(アイコンは、アプリケーション・バーに表示されます。)

(Articlesサンプル・アプリケーションは、/sample app/articles/src/main/webapp/images/にあるarticles.pngイメージ・ファイルを使用します。)

2. アプリケーションのレイアウト(つまり各ビュー)をHTMLで指定するファイルを作成し、ビューでレンダリングされるコンテンツを保持するためのプレースホルダ・エレメントを作成します。図59-4 に、アプリケーションとビューの関係を示します。

たとえば、Articlesサンプル・アプリケーションのlayout.jspには次の行が含まれます。

<div id="articles" style="float:left;height:100%;width:100%" class="wemholder"></div>

ビューのコンテンツは、アプリケーションが表示される際にプレースホルダ・エレメント内にレンダリングされます(layout.appがアプリケーションのレイアウトをレンダリングし、home.appがビューをレンダリングします)。

注意:

レイアウト・ファイルの作成時に、プレースホルダ・エレメントに一意のidを指定します。viewオブジェクトをコーディングする際には、同じidをparentnode属性に指定します。プレースホルダ・エレメントにclass="wemholder"を使用します。

図59-4 アプリケーションとビュー

アプリケーションとビューは、多対多の関係にあります(図59-4 )。1つのアプリケーションで複数のビューを使用でき、各ビューは複数のアプリケーションで使用できます。登録済のビューは(ビューのアセットIDによって)共有可能です。アセットIDが省略されている場合は、そのアプリケーションのコンテキスト内にビューが作成されます。ベーシックの場合、1つのアプリケーションに関連付けられるビューは1つのみです。

3. PUT wem/applications/{applicationid} RESTサービスを起動して、アプリケーションBeanを指定します。

4. Beanにビュー・アセットとアプリケーション・アセットに移入します。

iframeビューの場合、Articlesサンプル・アプリケーションのコード(InstallController.java)を使用します(コメント行// Create a new view objectおよび// Create a new application objectを見つけます)。layouturl属性を設定して、アプリケーションのレイアウト・ページのURLを指定します。

Articlesアプリケーションで、次のように、layouturl属性をlayout.app (LayoutController.javaで実装)のURLに指定します。

app.setLayouturl(config.getArticlesUrl() + "/layout.app");

5. 登録プロセスの結果をテストするには、WEM Adminインタフェースに一般管理者としてログインし、メニュー・バーで「アプリケーション」を選択します。このページにアプリケーションが一覧表示されるはずです。

59.6.2 JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録

HTMLビューおよびJavaScriptビューを使用するアプリケーションの場合、「iframeビューを使用したアプリケーションの登録」の手順に従いますが、次の各項に示すサンプル・コードと属性を使用します。

- JavaScriptビューのレンダリング

- HTMLビューのレンダリング

59.6.2.1 JavaScriptビューのレンダリング

注意:

ビューで指定したJavaScriptは、アプリケーションがレンダリングされるときにレンダリング(実行)されます。JavaScriptが他のビューと競合しないようにしてください。

サンプル・コード:

window.onload = function () {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById("map_canvas"));
map.setCenter(new GLatLng(37.4419, -122.1419), 13);
map.setUIToDefault();
}
}

- ソースURLからのJavaScriptビューのレンダリング
次の属性を設定します。

- name: ビューの名前

- parentnode: (「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.ScriptRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- sourceurl: .jsファイルのパス。ビューのコンテンツを提供します。例: http://example.com:8080/js/drawTree.js

- ソース・コードからのJavaScriptビューのレンダリング
次の属性を設定します。

- name: ビューの名前

- parentnode: (「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.ScriptRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- javascriptcontent: JavaScriptコード(前述のサンプル)。<script>タグはコードに含めないでください。

59.6.2.2 HTMLビューのレンダリング

注意:

ビューで指定したHTMLは、アプリケーションがレンダリングされるときにレンダリング(実行)されます。

サンプル・コード:

<object width="480" height="385">
<param name="movie" value="http://www.localhost:8080/jspx/flash_slider_main.swf"></param>
<param name="allowFullScreen" value="true"></param>
<embed src=" http://www.localhost:8080/jspx/flash_slider_main.swf"
type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true"
width="480" height="385">
</embed>
</object>

- ソースURLからのHTMLビューのレンダリング
次の属性を設定します。

- name: ビューの名前

- parentnode: (「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.IncludeRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- sourceurl: ビューのコンテンツを提供するHTMLファイルのパスです。例: http://example.com:8080/js/drawTree.jsp

- ソース・コードからのHTMLビューのレンダリング
次の属性を設定します。

- view: ビューの名前

- parentnode: (「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.IncludeRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- includecontent: HTMLコンテンツ(前述のサンプル。<html>または<body>タグはコードに含めないでください。)

60 WEMフレームワークを使用したカスタムRESTリソースの開発

カスタムRESTリソースはWEMフレームワーク内で開発できます。

WEMフレームワークを使用したカスタムRESTリソースの開発の詳細は、次の項を参照してください。

- WebCenter SitesおよびSatellite Server用のRESTリソースの作成: 例

- RESTリソースの作成

60.1 WebCenter SitesおよびSatellite Server用のRESTリソースの作成: 例

Recommendationsサンプル・アプリケーションは、WebCenter SitesおよびSatellite ServerのRESTリソースを作成する方法を示しています。アプリケーションは、GETおよびPOST操作で、新しいRESTリソースsample/recommendations/<id>を登録します。これによって、静的リスト推奨を取得し変更できます。また、アプリケーションは、Satellite Serverキャッシング・システムをどのように活用できるかについても示しています。

この項には次のトピックが含まれます:

- Recommendationsサンプル・アプリケーションのビルドおよびデプロイ

- Recommendationsサンプル・アプリケーションのテスト

60.1.1 Recommendationsサンプル・アプリケーションのビルドおよびデプロイ

1. Recommendationsサンプル・アプリケーションは、WebCenter Sitesインストール・ディレクトリ内のMisc/Samplesフォルダにあります。recommendationsに移動し、build.propertiesファイルを編集します。cs.webapp.dirおよびss.webapp.dir プロパティに適切なパスを指定します。

2. recommendationsフォルダでApache antを実行します。

これにより、サンプル・アプリケーションのビルドとデプロイが行われます。

3. catalogmoverアプリケーションを起動します。「サーバー」→「接続」メニューを使用して、WebCenter Sitesに接続します。「カタログ」→「カタログの自動インポート」に移動し、src\main\schema\elements.zipファイルを選択します。ACLのリストを指定する場合は、xceladmin、xceleditorを追加します。

4. WebCenter Sites Webアプリケーション・フォルダに移動します。WEB-INF/classes/custom/RestResource.xmlファイルを編集します。recommendationService、recommendationConfigおよびresourceConfigsの各Beanを非コメント化します。

5. Satellite Server Webアプリケーション・フォルダに移動します。WEB-INF/classes/custom/RestResource.xmlファイルを編集します。recommendationService、recommendationConfigおよびresourceConfigsの各Beanを非コメント化します。

6. WebCenter SitesとSatellite Serverの両方を再起動します。

60.1.2 Recommendationsサンプル・アプリケーションのテスト

Recommendationsサンプル・アプリケーションは、次の方法でテストできます。

- URL http://<hostname>:<port>/<contextpath>/REST/sample/recommendations/<recommendationid>に対する既存の静的リスト推奨IDを使用します(または新しい推奨を作成します)。

- WebCenter SitesおよびSatellite Serverの各インストールで同じURLを使用します。たとえば、http://localhost:8080/cs/REST/sample/recommendations/1266874492697を使用します。WebCenter SitesとSatellite Serverの両方のXMLレスポンスを確認します。

60.2 RESTリソースの作成

この項には次のトピックが含まれます:

- Recommendationsサンプル・アプリケーションの構造について

- カスタムRESTリソースの実装

60.2.1 Recommendationsサンプル・アプリケーションの構造について

Recommendationsサンプル・アプリケーション(図60-1)は、独自のRESTリソースを作成する過程を通じて手順を説明することを目的に作成されています。

図60-1 Recommendationsサンプル・アプリケーション

- スキーマ・ファイル: src/main/schema

- elements.zipには、サンプル・エレメントが含まれます。Satellite Serverでキャッシュ目的に使用されます。

- jaxb.bindingは、JAXBデフォルト・バインディングのカスタマイズです。Beanの生成プロセスで使用されます。

- recommendation.xsdは、RecommendationService BeanのXMLスキーマです。

- Javaソース・ファイル: src/main/java/ ... /sample

- RecommendationResourceには、RESTリソース実装が含まれます。これは、WebCenter SitesとSatellite Serverの両方で使用されます。

- RecommendationServiceは、RecommendationResourceクラスの機能を提供するインタフェースです。これは、リソースがローカル(WebCenter Sites上)またはリモート(Satellite Server上)のいずれでホストされているかによって、異なる方法で実装されます。

- beans/*クラスは、Java xjcコンパイラを使用して生成されます。これらのクラスは、アプリケーションに事前にパッケージされています。Beanを再生成(recommendation.xsdファイルを変更)するには、build.xmlのgenerate Antタスクを実行します。

- LocalRecommendationServiceは、RecommendationServiceインタフェースのローカル(WebCenter Sites)実装です。

- RemoteRecommendationServiceは、RecommendationServiceインタフェースのリモート(Satellite Server)実装です。

60.2.2 カスタムRESTリソースの実装

1. RESTサービスを記述したXSDファイル(recommendations.xsdファイル)を作成します。

2. JAXB xjcユーティリティ(generate Antタスク)を使用してBeanを生成します。

3. RESTインタフェースを作成します。WebCenter SitesとSatellite Serverとでは実装が異なります。

4. クラスcom.fatwire.rest.BaseLocalServiceおよびcom.fatwire.rest.BaseRemoteServiceを拡張して、RESTインタフェースを実装します。

5. 次の手順は、Satellite Serverキャッシュを利用する場合のオプションです。

WebCenter Sites側でエレメントを作成します。このエレメントは、ローカル実装と同じアセットをロードします。

6. com.fatwire.rest.BaseResourceクラスを拡張して、RESTリソース・クラスを作成します。

7. WebCenter Sites側およびSatellite Server側の両方で、RESTサービスと構成をWEB-INF/classes/custom/RestResources.xmlファイルに登録します。

custom/RestResources.xmlファイルには次のコンポーネントが含まれます。

- resourceConfigs IDを含むBeanのみが必須Beanです。resourceConfigsプロパティには、使用されるすべてのREST構成への参照が含まれます。

注意:

カスタムresourceConfigsが非コメント化されている場合は、Beanを参照する必要があります。そうしないと、WEMインストールで提供されるデフォルトのRESTリソースが登録されません。

- リソース構成は、タイプcom.fatwire.rest.ResourceConfigにする必要があります。通常は、このクラスの1つのインスタンスのみが登録されます(構成ごとに複数のサービスを登録できます)。

注意:

複数のサービスの場合は、RESTサービスの非結合グループごとに新しい構成を作成します。通常は個別のXSDファイルで指定します。

- resourceClassesプロパティには、使用されるすべてのリソースのリストが含まれます。

- beanPackageには、xjcユーティリティの実行時に出力Beanに指定したJavaパッケージ名が含まれます。

- schemaLocationは、RESTサービスで生成されるすべての出力XMLファイルに配置されるxsi:schemaLocation属性です。

61 本番サイトでのシングル・サインオンの使用

使用準備済のCASをアプリケーションの保護に使用できないライブ・サイトでアプリケーションのシングル・サインオンおよびサインアウトを有効にする簡単な例を使用して、本番サイトでのシングル・サインオンについて説明します。

本番サイトでのシングル・サインオンの使用の詳細は、次の項を参照してください。

- SSOサンプル・アプリケーションのデプロイ

- SSOサンプル・アプリケーションの構造の理解

- シングル・サインオンの実装

- シングル・サインアウトの実装

61.1 SSOサンプル・アプリケーションのデプロイ

1. wem-sso-api-cas-sample.warファイルを(/sso-sampleフォルダなどに)解凍します。アプリケーションは、Misc/Samples/WEM Samples/WEM Sample applications/ディレクトリのWebCenter Sitesインストール・ディレクトリにあります。

2. 次のプロパティを設定して、WEB-INFフォルダにあるapplicationContext.xmlファイルを変更します。

- casUrl: 次のように、CASサーバーのベース・パスを指定します。

http://localhost:8080/cas

- casLoginPath: 次のように、SSOサンプル・アプリケーションでホストされるログイン・フォーム・テンプレートを含めます。

/login?wemLoginTemplate=http%3A%2F%2Flocalhost%3A9080%2Fsso-cas-sample%2Ftemplate.html

3. 変更したSSOサンプル・アプリケーションをアプリケーション・サーバーにデプロイします。

4. アプリケーションにアクセスします。

SSOサンプル・アプリケーションは、次のページで構成されています。

- 保護されている領域: WEM SSOフィルタで保護されているページ。このページには、シングル・サインアウト用の2つのリンクがあります(図61-1)。

図61-1 シングル・サインアウト用のリンクを含む保護付きページ

1つ目のリンク(リダイレクトありのシングル・サインアウト)は、CAS側でシングル・サインアウトを実行し、ユーザーをホーム・ページにリダイレクトするHTMLリンクです。2つ目のリンク(リダイレクトなしのシングル・サインアウト)もHTMLリンクですが、CAS側でシングル・サインアウトを実行しても、現在のページから遷移したり、再ロードが発生したりすることはありません。

- 公開領域: 保護フィルタから除外されるページ。

- ログイン・フォームを含む公開領域: このページは保護フィルタから除外されますが、ページ内にログイン・フォーム(図61-2)があります(ログイン・フォームではサインイン操作を実行できますが、現在のページから遷移したり、再ロードが発生したりすることはありません)。

図61-2 「サインイン」リンクを含む公開領域

注意:

ログインに成功すると、ユーザーは、CASによって、リクエストされたサービスにリダイレクトされます。セキュリティ目的で、ユーザーをリダイレクトする前に、リクエストされたサービスを検証できます。それには、Adminインタフェースの「システム・ツール」ノードのプロパティ管理ツールを使用して、信頼できるURLおよび許可されたURLのリストを指定します。信頼できるURL (カンマ区切り)をvalid.urlsプロパティに追加します。このプロパティでは、WebCenter Sitesにアクセスするために、信頼できるURLのユーザーが使用を許可されるように指定します。このプロパティのデフォルト値は、<wcsites.app.protocol>://<wcsites.app.host>:<wcsites.app.port>/<wcsites.app.contextroot>/*です。詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

URLは、次の書式のいずれかにできます。

- 完全なURL。例:
http://hostname:port/cs/wem/fatwire/wem/Welcome

- 一致するURL。例:
http://hostname:port/SitesWebapp/*

ここで、末尾の/*は、指定した接頭辞と同じ接頭辞が含まれるURLを示します

IPを使用した信頼できるURLも同様のURLを指定する必要があります。

61.2 SSOサンプル・アプリケーションの構造の理解

SSOサンプル・アプリケーション(図61-3)には、本番サイトでシングル・サインオンおよびサインアウト機能を使用して、アプリケーションを保護するための基本コードが用意されています。次のコンポーネントを使用して、SSOサンプル・アプリケーションにアクセスします。

- index.jsp: 開始ページ。このページには、保護されている領域、公開領域およびログイン・フォームを含む公開領域の各ページ(「SSOサンプル・アプリケーションのデプロイ」を参照)へのリンクがあります。

- template.html: CAS用のカスタム・サインイン・フォームを指定する際に使用します。このファイルへのパスは、applicationContext.xmlファイルのcasLoginPathにあるwemLoginTemplateパラメータで参照します。

図61-3 sso-sample

/sso-sample/WEB-INFの構成ファイル

WEB-INFには、次の構成ファイルが含まれます。

- applicationContext.xml: Spring Webアプリケーション構成ファイル。SSOサブシステムを構成します。

- web.xml: Webアプリケーションのデプロイメント・ディスクリプタ。

/sso-sample/protected/jspの保護付きファイル

この領域のファイルは、SSOフィルタで保護されています。デフォルトでは、このフォルダに次のファイルが含まれています。

- protected.jsp: SSOフィルタで保護されているページ。このページには、シングル・サインアウトを実行するための2つのリンクがあります。1つ目のリンクをクリックすると、CASサインアウト・ページに遷移し、サインアウトが完了するとアプリケーションのホーム・ページにリダイレクトされます。2つ目のリンクをクリックすると、このページにiframeが埋め込まれ、signoutCallback.jspページにリダイレクトされるCASサインアウト・ページがコールされます。また、protected.jspページには、現在のログイン済ユーザーを表すAssertionオブジェクトのすべての属性も表示されます。

- protected/jsp/protectedSection.jsp: 埋込みiframeの「サインイン」リンクがクリックされた場合に、public.jspページから参照されるページです。このページは保護されているため、埋込みiframeにログイン画面が表示されます。

/sso-sample/public/jspの公開ファイル

この領域のファイルは、SSOフィルタで保護されていません。デフォルトでは、/public/jsp/フォルダに次のサンプル・ファイルが含まれています。

- public.jsp: このページは、CASフィルタで保護されていません。

- publicWithAuth.jsp: このページには、「サインイン」リンクが表示されます。このリンクをクリックすると、publicWithAuth.jspに、protectedSection.jspページを指すiframeが埋め込まれます。このページは保護されているため、埋込みiframeにログイン画面が表示されます。

- signoutCallback.jsp: このページは、iframeを使用する場合にサイトアウトが完了すると、protected.jspページからコールされます。

61.3 シングル・サインオンの実装

Webサイトでシングル・サインオンを実装する場合、サインイン・フォームを実装することになります。サインイン・フォームは、次の2つのいずれかの方法でサイト訪問者に表示できます。

- 保護付きページに訪問者がアクセスしようとすると、サインイン・フォーム(図61-4)が表示されます。これは、デフォルトのサインイン実装です。このサインイン・フォームには、CASに付属のデフォルト・サインイン・フォームまたはアプリケーションが提供するカスタム・フォームを指定できます。

図61-4 サインイン・フォーム

- サインイン・フォームを公開ページ(図61-5)に埋め込むと、ユーザーが現在のページから遷移することなくサインイン機能が実行されます。この動作を実装するには、保護付きページを指すiframeを埋め込みます。そのページは保護されているので、訪問者にはサインイン・フォームが表示されます。

図61-5 サインイン・フォーム

61.4 シングル・サインアウトの実装

シングル・サインアウトをWebページで実装する場合、次のいずれかの方法で実行します。

- 次のメソッドを起動して、single sign-out URLを取得します。
com.fatwire.wem.sso.SSO.getSSOSession()オブジェクトのgetSignoutUrl()またはgetSignoutUrl(String callbackUrl)メソッド。

シングル・サインアウト後に、必要に応じて、訪問者が指定したURLにCASからリダイレクトできます(これは、callbackUrlパラメータで設定します)。

- 現在のページから遷移せずにシングル・サインアウトを実行するには、iframeの埋込み手法を使用します。この手法では、ソースにシングル・サインアウトURLを含むiframeを埋め込む必要があります。iframeがロードされると、サインアウトURLがコールされます(この方法は主に、ブラウザでのクロスドメイン制限を回避する場合に使用されます)。

62 WEMフレームワークでのRESTリソースの使用

RESTリソースはWEMフレームワーク内で使用できます。

RESTリソースの使用の詳細は、次の項を参照してください。

- RESTリソースの認証

- CASの構成について

- REST認可

- RESTを介したアセットの管理

62.1 RESTリソースの認証

WEMフレームワークでは、CAS (http://www.jasig.org/cas)上に構築されたSSOメカニズムを認証の際に使用します。このシステムの動作は、REST APIをブラウザから使用するか、プログラムから使用するかによって異なります。

ブラウザからREST APIにアクセスすると、ユーザーはCASログイン・ページにリダイレクトされ、ログインに成功すると、ユーザーのアイデンティティを確立するために検証されるticketパラメータによって、元の位置に戻されます。プログラムでREST APIにアクセスする場合は、開発者がticketパラメータまたはmultiticketパラメータのいずれかを指定する必要があります。

ticketおよびmultiticketパラメータを取得するにはいずれも、Oracle SSO APIを使用するか(Javaでコールする場合)、単にHTTPプロトコルを使用します(他の言語でコールする場合)。ticketとmulticketの違いは、ticketはRESTリソースごとに取得され、1回しか使用できないのに対し(名前からわかるように、列車や劇場のチケットが1回の乗車あるいは1回の鑑賞のみに有効であることを想像してください)、multiticketは任意のリソースに対して複数回使用できます。ticketおよびmultiticketパラメータはいずれも回数に制限がありますが、一般的な使用パターンが異なります。チケットはコールごとに取得されるので、有効期限はありません。一方、同じmultiticketを再利用すると最終的に期限切れとなり、HTTP 403エラーが発生します。期限切れになった場合、アプリケーションでこのような動作を認識して、そのmultiticketを再取得できる必要があります。ticketとmultiticketのどちらを使用するかは、アプリケーション開発者が決定します。

この項には次のトピックが含まれます:

- Javaコードからのチケットの取得

- 他のプログラミング言語からのチケットの取得(HTTPを経由)

- チケットおよびマルチチケットの使用

- スタンドアロン・アプリケーションのSSO構成

62.1.1 Javaコードからのチケットの取得

Oracle SSO APIは、認証プロバイダに依存しない方法で実装されています。ただし、ユーザーは独自のSSO認証プロバイダを登録できません。新しい認証プロバイダのサポートは、Oracleでのみ実装できます。プロバイダの切替えは、SSO構成ファイルを変更するのみで済みます。

すべてのSSOコールは、SSOフロントエンド・クラスSSOで開始します。これは、SSOSessionオブジェクトの取得に使用されます。SSOSessionは、SSO構成ごとに取得されます。Webアプリケーションの場合はSpring Webアプリケーション・ローダーを使用してロードされた単一の構成、またはスタンドアロン・アプリケーションの場合は構成ファイルからロードされた構成となります。

- Webアプリケーションでチケットを取得するには:

SSO.getSession().getTicket(String service, String username, String password)
SSO.getSession().getMultiTicket(String username, String password)

- スタンドアロン・アプリケーションでチケットを取得するには:

SSO.getSession(String configName).getTicket
(String service, String username, String password)
SSO.getSession(String configName).getMultiTicket
(String username, String password)

62.1.2 他のプログラミング言語からのチケットの取得(HTTPを経由)

CAS REST APIは、チケットまたはマルチチケット(あるいはその両方)を配信環境で取得するために使用します。チケットまたはマルチチケットのいずれかを取得するには、2つのHTTP POSTコールを実行する必要があります。チケットとマルチチケットとの違いは、マルチチケットの場合はserviceパラメータが*(アスタリスク)であるのに対し、ticketパラメータの場合は、実際にアクセスするRESTリソースである点です。

次の例では、CASサーバーに対して実行されるコールを示します。このコールでは、資格証明fwadmin/xceladminを使用してhttp://localhost:8080/cs/REST/sitesサービスのチケットを取得します。

1. Ticket Granting Ticket を取得するためのコール

リクエスト

POST /cas/v1/tickets HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 35

username=fwadmin&password=xceladmin

レスポンス

HTTP/1.1 201 Created
Location: http://localhost:8080/cas/v1/tickets/TGT-1-ej2biTUFoCNBwA5X4lJn4PjYLRcLtLYg2QhLHclInfQqUk3au0-cas
Content-Length: 441
...

2. サービス・チケットを取得するためのコール

リクエスト

POST /cas/v1/tickets/TGT-1-ej2biTUFoCNBwA5X4lJn4PjYLRcLtLYg2QhLHclInfQqUk3au0-cas  HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 57

service=http%3A%2F%2Flocalhost%3A8080%2Fcs%2FREST%2Fsites

レスポンス

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 29

ST-1-7xsHEMYR9ZmKdyNuBz6W-cas

プロトコルは、非常に単純です。最初に、ユーザー名およびパスワード・パラメータをapplication/x-www-form-urlencoded POSTリクエストで渡すことで、Ticket Granting Ticket (TGT)を取得するためのコールを実行します。レスポンスにはLocation HTTPヘッダーが含まれます。これを使用して、serviceパラメータを指定する2番目のapplication/x-www-form-urlencoded POSTリクエストを発行します。レスポンス本文には実際のチケットが含まれます。

62.1.3 チケットおよびマルチチケットの使用

生成されたチケット/マルチチケット(図62-1)を使用するには、ticket/multiticket URL問合せパラメータを指定します。次に例を示します。

http://localhost:8080/cs/REST/sites?ticket=ST-1-7xsHEMYR9ZmKdyNuBz6W-cas
http://localhost:8080/cs/REST/sites?multiticket=ST-2-Bhen7VnZBERxXcepJZaV-cas

図62-1 チケットおよびマルチチケット

1. アプリケーションが、チケット/マルチチケットを取得するためのコールを実行します。

- 入力: サービス、ユーザー名、パスワード

- 出力: チケット/マルチチケット

2. アプリケーションが、リソースを取得するためのコールをリモートSatellite Serverに対して実行します。

- 入力: チケット、リソース入力データ

- 出力: リソース出力データ

3. リモートSatellite Serverは、結果のアサーションを検証するためのコールを実行します。アサーションにはユーザー情報が含まれます。また、Satellite Serverはマルチチケットの時間ベースのキャッシュを保持しているため、後続のコールでは検証によるコストは発生しません。

- 入力: チケット/マルチチケット

- 出力: アサーション

4. この手順は省略可能です。Satellite Server側で、SSOConfig.xmlファイルのproxyTicketsパラメータがtrueに設定されている場合は、チケットのプロキシも行われます。

- 入力: チケット

- 出力: プロキシされたチケット

5. リモートSatellite Serverが、WebCenter Sitesに対してコールを実行します。

- 入力: アサーション(シリアライズ形式)、リソース入力データ

- 出力: リソース出力データ

6. この手順は省略可能です。WebCenter Sites側でセキュリティが有効な場合は、チケットを検証するためのコールが実行されます。

- 入力: チケット/マルチチケット

- 出力: アサーション

デフォルトでは、WebCenter SitesとリモートSatellite Server間の通信チャネルは信頼されていません。リモートSatellite ServerのSSOConfig.xmlファイルのproxyTicketsパラメータがtrueに設定されているため、アクセスしているアプリケーションで指定されたチケットが、リモートSatellite Serverによって強制的にプロキシされます。

最適なパフォーマンスを得るために、システムをSatellite Serverのみによって認証するように構成できます。REST APIによって使用されるRESTおよびWebCenter SitesエレメントをSSOフィルタから除外することにより、WebCenter Sites側でセキュリティ・チェックを無効にする必要があります。Satellite Server側で、SSOConfig.xmlファイルのproxyTicketsパラメータをfalseに設定する必要があります。このモードではマルチチケットを活用できます。このモードでは、WebCenter Sitesのインストールはプライベート・ネットワーク内でホストする必要があること、およびWebCenter SitesとリモートSatellite Server間の通信チャネルの信頼性を確保する必要があることに注意してください。

62.1.4 スタンドアロン・アプリケーションのSSO構成

シングル・サインオン・モジュールはSpring構成に基づいています。唯一必要なBeanはssoproviderで、これはssoconfig Beanを参照しています。

この項には次のトピックが含まれます:

- Beanおよびプロパティ

- SSOフィルタで処理される問合せパラメータ

62.1.4.1 Beanおよびプロパティ

表62-1では、ssolistener Beanおよびプロパティを説明します。

id="ssolistener", class="com.fatwire.wem.sso.cas.listener.CASListener"

表62-1 id="ssolistener"

プロパティ

説明

このBeanにはプロパティはありません。

該当なし

表62-2では、ssofilter Beanおよびプロパティを説明します。

id="ssofilter",
class="com.fatwire.wem.sso.cas.filter.CASFilter"

表62-2 id="ssofilter"

プロパティ

説明

config

必須。SSO構成参照です。

サンプル値: ssoconfig

provider

必須。SSOプロバイダ参照です。

サンプル値: ssoprovider

表62-3では、provider Beanおよびプロパティを説明します。

id="provider",
class="com.fatwire.wem.sso.cas.CASProvider"

表62-3 id="provider"

プロパティ

説明

config

SSO構成参照です。

サンプル値: ssoconfig

表62-4では、config Beanおよびプロパティを説明します。

id="config",
class="com.fatwire.wem.sso.cas.conf.CASConfig"

表62-4 id="config"

プロパティ

説明

applicationProxyCallbackPath

プロキシ・コールバックのパス(casUrlからの相対パス)。

サンプル値: /proxycallback

authRedirect

このプロパティは、保護されているページへの未認証アクセスに対するデフォルト動作を指定するために使用します。trueを指定すると、ユーザーがCASログイン・ページにリダイレクトされます。falseを指定すると、ユーザーが未認証の場合は403エラーが表示されます。この設定は、Pragma: auth-redirect HTTPヘッダーによってオーバーライドできます。

サンプル値: true

casLoginPath

ログイン・ページのパス(casUrlからの相対パス)。

次の追加の問合せパラメータを受け取ることができます。

- wemLoginTemplateは、デフォルト・テンプレートのかわりに使用されるHTMLログイン・テンプレートを含むページを指します。このテンプレートには2つの入力フィールド(usernameおよびpassword)を含める必要があります。このテンプレートでは、HTML <form>タグは使用しないでください。

- wemLoginCss。ログイン・フォームで使用されるスタイル宣言を含むCSSページを指します。

サンプル値: /login

casRESTPath

CAS RESTサーブレットのパス(casUrlからの相対パス)。

サンプル値: /v1

casSignoutPath

ログアウト・ページのパス(casUrlからの相対パス)。

サンプル値: /logout

casUrl

必須プロパティ。CAS URLの接頭辞です。

URLは内部と外部の両方で解決する必要があります。

例: http://localhost:8080/cas

gateway

trueの場合、保護されているページへのリクエストはCASにリダイレクトされます。チケット発行Cookieが存在する場合は、ユーザーは暗黙的に認証されます。存在しない場合は、ユーザーは元の位置にリダイレクトされます。これは主に、ユーザーが別のアプリケーションにログインしている場合に、暗黙的な認証を許可するために使用されます。

gateway (続き)

デフォルトでリダイレクトの動作が行われるようにする場合は次の点に注意してください。クライアントがリダイレクトを追従できることを確認してください。そうでない場合は、gateway=false URL問合せパラメータを使用して、デフォルトの動作をオーバーライドする必要があります。たとえば、wemLoginTemplateおよびwemLoginCssパラメータの処理中は、CASがリダイレクトを追従しないため、この設定をオンにするときに、gateway=falseをURLに付加する必要があります。

デフォルト値: false

multiticketTimeout

マルチチケットのタイムアウト(ミリ秒単位)。

デフォルト値: 600000

protectedMappingExcludes

除外されるマッピングのリスト。正規表現を使用できます。

許可値: protectedMappingIncludesを参照してください。

protectedMappingIncludes

保護されるマッピングのリスト。正規表現を使用できます。

許可値: path?[name=value,#]

pathはURLパスの一部です。アスタリスクを含めることができます(*および**)。単一のアスタリスク*は、スラッシュ(/)までの文字シーケンスを表し、**は、パス全体に適用されます。

例

/folder1/folder2は/folder1/*と一致しますが、/folder1/folder2/folder3は一致しません。

/folder1/folder2と/folder1/folder2/folder3は、/folder1/**と一致します。

?[..]ブロックはオプションです。問合せパラメータはブロック内で指定できます。パラメータはカンマで区切られます。特殊文字#は、指定されたパラメータがリクエストの内容のサブセットであることを意味しています。#を省略するには、指定されたパラメータに正確に一致するリクエスト・パラメータが必要です。

パラメータには、nameのみを含めることができます。照合は、nameに対してのみ、またはname=value (つまり、nameとvalueの両方)に対して実行されます。パラメータには、複数の値を指定できます。この場合、指定したパラメータ値のいずれかが、対応するリクエストのパラメータ値と一致すると照合テストに合格します。

例

/file1[size=1|2] matches against /file1?size=2, but not against /file1?size=2&author=admin

/file1[size=1|2,name=file1,#] matches against /file1?size=2 and /file1?size=2&author=admin,but not against /file1?size=3

protectedMappingIncludes (続き)

リモートSatellite Serverを介してアプリケーションのカスタムRESTリソースを使用可能にするには、次の値を指定します。

/ContentServer?[pagename=rest/<path toCSElement>,#]

例

「WebCenter SitesおよびSatellite Server用のRESTリソースの作成: 例」のカスタムRESTリソースに指定する場合は、/ContentServer?[pagename=rest/sample/recommendation,#]です。

proxyTickets

チケットをプロキシするかどうかを指定します。

コール・チェーンの最後のサーバーに対してこのプロパティをfalseに設定すると、パフォーマンスが最適化されます。

現在のログイン済ユーザーの代理としてこのアプリケーションからCASで保護された別のアプリケーションをコールする必要がある場合は、このプロパティをtrueに設定します。これにより、メソッドSSO.getSSOSession().getTicket(String service, String username, String password)をコールできるようになります。

デフォルト値: true

useMultiTickets

マルチチケットを使用するかどうかを指定します。

デフォルト値: true

62.1.4.2 SSOフィルタで処理される問合せパラメータ

表62-5で、SSOフィルタで処理される問合せパラメータについて説明します。

表62-5 SSOフィルタで処理される問合せパラメータ

プロパティ名

説明

ticket

ユーザーIDを検証するために使用します。あるかぎられた期間内で、1つのリソースに対して1回のみ使用できます。

タイプ: <query parameter>

値: <random string>

multiticket

ユーザーIDを検証するために使用します。あるかぎられた期間内で、任意のリソースに対して複数回使用できます。

タイプ: <query parameter>

値: <random string>

gateway

このプロパティがtrueに設定されている場合は、パブリック・ページのリクエストはCASにリダイレクトされます。チケット発行Cookieが存在する場合は、ユーザーは暗黙的に認証されます。存在しない場合は、ユーザーは元の位置にリダイレクトされます。これは主に、ユーザーが別のアプリケーションにログインしている場合に、暗黙的な認証を許可するためです。

タイプ: <query parameter>

値: true | false

auth-redirect

保護されているページへの未認証アクセスに対するデフォルトの動作を指定するために使用します。このプロパティがtrueに設定されている場合は、ユーザーはCASログイン・ページにリダイレクトされます。falseに設定されている場合は、403エラーが表示されます。

タイプ: <Pragma HTTP header>

値: true | false

62.2 CASの構成の概要

CASクラスタリングに関する情報は、次のソースを参照してください。

- CASアーキテクチャの詳細は、次のリンクを使用してください。
http://www.jasig.org/cas/about

- WebCenter Sitesのインストール時にCASクラスタリングを構成する方法の詳細は、『Oracle WebCenter Sitesのインストールと構成』を参照してください。

- LDAPプロバイダでCASを構成する方法の詳細は、次のリンクを使用してください。
http://www.jasig.org/cas/server-deployment/authentication-handler

62.3 REST認可

REST認可は、アプリケーションのリソース(WebCenter Sites内のオブジェクトにマップされる)に対してRESTの各操作を実行するための権限を付与するプロセスです。REST認可は、デフォルトではすべてを拒否するモデルを使用します。権限が特定のグループに対して明確に付与されていない場合、その権限は拒否されます。

この項には次のトピックが含まれます:

- セキュリティ・モデル

- RESTリソースへのセキュリティ・モデルを使用したアクセス

- RESTセキュリティの構成について

- 権限解決アルゴリズム

62.3.1 セキュリティ・モデル

WEMセキュリティ・モデルはオブジェクト、グループおよびアクションに基づいています。セキュリティは、図62-2に示すように、Adminインタフェースでオブジェクト・タイプごとに構成する必要があります。特定のタイプのオブジェクトにユーザーがアクセスできるのは、特定のタイプのオブジェクトに対して指定されたアクションを実行する権限を持つグループの少なくとも1つにこのユーザーが属する場合のみです。

図62-2 新規セキュリティ構成の追加

- オブジェクトは、サイト、ユーザー、アセットなど、WEMフレームワーク内のエンティティを示す総称です。保護オブジェクトには次のタイプがあります。

- アセット・タイプ

- アセット

- 索引

- サイト

- ロール

- ユーザー

- ユーザー・ロケール

- ACL

- アプリケーション

- セキュリティ・グループは、ユーザーを集約して、ユーザーの(オブジェクトへの操作)権限を同時に管理するために使用します。

- アクションは、LIST、READ、UPDATE、CREATE、DELETEの各セキュリティ権限です。LISTはオブジェクトをリストするサービス(/typesなど)に対するGET権限を提供し、READは個々のオブジェクトの詳細を取得するサービス(/types/{assettype}など)に対するGET権限を提供します。
権限は、許可されたオブジェクトを操作するためにグループに割り当てられます。ACLなど一部のオブジェクトは読取り専用です(WebCenter Sitesで直接作成できますが、RESTを介して作成できません)。

前述のように、セキュリティ構成とは1つの配列です。セキュリティ構成では次を指定します。

- 保護されているオブジェクト・タイプおよびオブジェクト

- オブジェクトにアクセス可能なグループ

- グループ(およびそのメンバー)がオブジェクトに実行できるアクション

可能なセキュリティ構成およびWebエクスペリエンス管理フレームワークの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

62.3.2 RESTリソースへのセキュリティ・モデルを使用したアクセス

WebCenter Sites内のオブジェクト・タイプとオブジェクトは、WEMフレームワーク内のRESTリソースにマップされます。たとえば、Asset Typeオブジェクトは次のリソースにマップされます。

- <BaseURI>/types/リソース(システム内のすべてのアセット・タイプを一覧表示します)

- <BaseURI>/types/<assettype>リソース(選択されたアセット・タイプに関する情報を表示します)など。

WebCenter Sitesのアクションは、WEMフレームワークのRESTメソッドにマップされます。たとえば、アセット・タイプContent_Cを操作するためのREAD権限をグループEditorに付与すると、Editorグループのユーザーには、RESTリソース/types/Content_Cに対してGETおよびHEADメソッドを使用する権限が付与されます。

- LISTアクションでは、グループ・メンバーがRESTリソースに対してGETメソッドを使用できます。

- READアクションでは、グループ・メンバーがRESTリソースに対してGETおよびHEADメソッドを使用できます。

- UPDATEアクションでは、グループ・メンバーがRESTリソースに対してPOSTメソッドを使用できます。

- CREATEアクションでは、グループ・メンバーがRESTリソースに対してPUTメソッドを使用できます。

- DELETEアクションでは、グループ・メンバーがRESTリソースに対してDELETEメソッドを使用できます。

詳細は、『Oracle WebCenter Sites REST APIリソース・リファレンス』を参照してください。

62.3.3 RESTセキュリティの構成について

RESTセキュリティの構成およびWebエクスペリエンス管理フレームワークの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

62.3.4 権限解決アルゴリズム

セキュリティ権限を構成する際に、特定のタイプのすべてのオブジェクトまたは特定のタイプの単一のオブジェクトに権限が適用されるように指定します。たとえば、任意のサイトに対するUPDATE (POST)権限を付与すると、グループ内のユーザーはすべてのサイトの詳細をWEMフレームワークで変更できるようになります。

Assetオブジェクト・タイプでは、セキュリティ設定の適用先サイトを指定する必要があります。アセットは、常に特定のサイトからアクセスされるからです。AssetTypeオブジェクトはサブタイプを指定することで拡張でき、セキュリティ構成をより詳細に設定するために使用されます。たとえば、アセット・タイプContent_CにDELETE権限を設定すると、RESTリソース/types/Content_CでのDELETEリクエストの実行(つまり、システムからContent_Cアセット・タイプを削除するための)が許可されます。

権限はグループにのみ付与できるため、ユーザーの全体的な権限は、そのユーザーの全グループを通じて権限が算出されるまで明確になりません。WEMフレームワークには、権限解決アルゴリズムが用意されています。その基本的な手順を次に示します。

1. RESTによって、ユーザーがメンバーシップを持つグループが検索されます。

2. RESTによって、各グループが実行できるREST操作およびその対象となるRESTリソースが判別されます。サイトまたはサブタイプが指定されている場合は、個々に考慮されます。

3. RESTによって、手順1および2の結果が比較されます。手順1の1つ以上のグループが、手順2のグループのリストで該当する場合、アクセスが許可されます。そうでない場合は、アクセスが拒否されます。

62.4 RESTを介したアセットの管理

WebCenter Sites REST APIを介したアセットの管理を示すサンプル・コードは、WebCenter Sitesのインストール・ディレクトリの次のパスにあります。

Misc/Samples/WEM Samples/REST API samples/Basic Assets/com/fatwire/rest/samples/basic/
Misc/Samples/WEM Samples/REST API samples/Basic Assets/com/fatwire/rest/samples/flex/

サブフォルダbasicおよびflexには、それぞれ次のファイルが含まれます。

- CreateAsset.java

- DeleteAsset.java

- ReadAsset.java

- UpdateAsset.java。

コードは、段階を追った説明によって詳細に文書化されています。

63 WEMフレームワークへのCustomizable Single Sign-Onファシリティの導入

WEMフレームワーク認証は、CASフレームワーク上に構築され、Oracle Customizable Single Sign-On (CSSO)ファシリティというカスタマイズ・レイヤーが備わっています。CSSOファシリティには、カスタムSSOソリューションを作成するために使用可能な認証の拡張が含まれているため、CAS構成を直接変更する必要はありません。かわりに、Spring構成でこれらの拡張をCAS構成に直接注入して、ログイン動作を実装します。

WEMフレームワーク内のCustomizable Single Sign-Onファシリティの詳細は、次の項を参照してください。

- WEMフレームワークのログイン動作のカスタマイズについて

- デフォルトCSSO実装のコンポーネントについて

- カスタムSSO動作の構成およびデプロイ

- CSSOサンプル実装の実行

63.1 WEMフレームワークのログイン動作のカスタマイズについて

CSSOファシリティには、カスタムSSOソリューションを実装するために拡張できる事前にパッケージされたクラスが用意されています。また、Springにインスタンス化するクラスを特定する、デフォルトSpring構成ファイルも提供しています。WEM SSOをカスタマイズすることで、別のログイン画面の使用、ユーザー名/パスワードのペア以外の資格証明の要求、または外部認証局を使用したWebCenter Sitesユーザーの認証が可能になります。カスタムSSO実装の構成は次のとおりです。

- 3つのJavaクラス(デフォルト・クラスを拡張します)

- フレームワークに新しいクラスを公開する構成ファイル

デフォルトCSSOクラスは、標準のWEM SSO実装に従って、すべての資格証明の検出と認証を行います。これらのクラスは、customdefaultWEMSSObean.xml Spring構成ファイルでインスタンス化されます。デフォルトCSSOクラスを拡張することにより、カスタムSSOソリューションの動作を指定するメソッドを定義できます。たとえば、ブラウザ・アクセス、RESTまたはシック・クライアント認証(あるいはその両方)に異なる認証を作成できます。デフォルトCSSOクラスを拡張する場合は、カスタム・クラスを指定し、それらのクラスをWEMフレームワークに公開するカスタムSpring構成ファイルを作成する必要があります。

CSSOファシリティでは、デフォルトWEMログイン動作をカスタム・ログイン動作で置き換える完全なSSOサンプル(Javaソース・ファイルを含む)が用意されています。サンプルSSO実装では、2種類の異なる認証(ユーザー名/パスワードのペア(追加のドメイン・フィールドを含む)および外部ユーザー識別子)が示されます。外部識別子は、外部認証局で認証されたユーザーをWebCenter Sitesシステム・ユーザーにマップします。

この章の残りの部分では、CSSOファシリティのデフォルト・コンポーネントおよびカスタムSSOソリューションの実装手順について説明します。カスタムSSOソリューションの例を確認する場合は、この章の最後に記載されているCSSOサンプルに関する情報およびこのサンプルの実行手順を参照してください。

63.2 デフォルトCSSO実装のコンポーネントについて

CSSOファシリティによって提供されるデフォルト・コンポーネントは、独自のSSO実装をカスタマイズするための開始ポイントになります。

com.fatwire.wem.sso.cas.custom.basisパッケージ(表63-1を参照)には、CSSOファシリティに含まれているデフォルト・クラスがあります。デフォルトSpring構成ファイル(customdefaultWEMSSObeans.xml)は、デフォルトWEMログイン動作を実装するためにこれらのクラスをインスタンス化します。

注意:

CSSOファシリティでは、デフォルトWEMログイン動作をカスタム・ログイン動作で置き換える完全なSSOサンプルが用意されています。詳細は、「CSSOサンプル実装の実行」を参照してください。

表63-1 com.fatwire.wem.sso.cas.custom.basis

クラス

説明

CustomAuthenticator.java

CustomAuthenticationインタフェースを実装します。このクラスは、ログイン・シーケンスの動作を制御し、認証リクエストを処理します。デフォルトでは、標準のWEMログイン・フォームを表示して、認証を完了するためにWEMフレームワークに戻ります。

このクラスの拡張の詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

CustomConfiguration.java

デフォルトSpring構成ファイルで設定されているプロパティへのアクセスを提供します。追加のプロパティがカスタムSSO実装に必要な場合にはこのクラスを拡張できます。

このクラスの拡張の詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

CustomCredentials.java

カスタム認証に対して資格証明値の標準セットを提供します。追加の属性がカスタムSSO実装に必要な場合にはこのクラスを拡張できます。

このクラスの拡張の詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

com.fatwire.wem.sso.cas.custom.interfacesパッケージ(表63-2 を参照)では、カスタム認証インタフェースを定義します。

表63-2 com.fatwire.wem.sso.cas.custom.interfaces

クラス

説明

CustomAuthentication.java

カスタムSSOソリューションで実装する必要があるインタフェースを定義します。

詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

CustomRestCodec.java

ユーザー名/パスワード・ベースではないカスタムREST認証トークンをエンコードおよびデコードするために実装する必要のあるインタフェースを定義します。

63.3 カスタムSSO動作の構成およびデプロイ

カスタムSSO動作を構成およびデプロイするには、最初にCSSOファシリティに含まれているデフォルトのクラスを拡張する必要があります。その後、クラスをインスタンス化するカスタムSpring構成ファイルを作成し、それらのクラスをCSSOフレームワークに公開して、Springに新しいJavaクラスを指定します。

カスタムSSO動作を構成してデプロイするには:

1. デフォルトCSSOクラスを次のように拡張します。CustomAuthenticator.java、CustomConfiguration.javaおよびCustomCredentials.java (com.fatwire.wem.sso.cas.custom.basisパッケージ内に含まれます)。

a. デフォルトCSSOクラスを拡張するJavaクラスを作成します。

b. 作成したJavaクラスをjarファイルにパッケージ化し、そのjarファイルをCASサーブレット(cas/WEB-INF/lib)のクラスパスに配置します。

詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

2. spring-configurationフォルダ(cas/WEB-INF内)にあるcustomResolverCredential.xmlファイルにusernameおよびpasswordプロパティを設定します。手順については、「リゾルバ資格証明の設定」を参照してください。

3. Springにインスタンス化する新しいJavaクラスを次のように指定します。

a. SSO実装用のカスタム・クラス名およびプロパティのすべてを含むSpring構成ファイルを作成します。

b. カスタムSpring構成ファイルをspring-configurationフォルダ(cas/WEB-INF/)に配置します。

c. デフォルトSpring構成ファイル(customDefaultWEMSSObeans.xml)から.xml拡張子を削除します。

詳細は、「Springへのインスタンス化するJavaクラスの指定について」を参照してください。

4. 外部認証局がユーザーの認証に使用される場合は、外部ユーザー識別子を適切なWebCenter Sitesシステムのユーザー名、一意の識別子およびACLにマップします。手順については、「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

5. CAS Webアプリケーションを再起動します。詳細は、「CAS Webアプリケーションの再起動」を参照してください。

この項の残りの部分では、前述の手順の詳細を説明します。

63.3.1 デフォルトCSSOクラスの拡張について

SSO実装は、デフォルトCSSOクラスCustomAuthenticator.java、CustomConfiguration.javaおよびCustomCredentials.javaで指定される一連のコールされたメソッドです。デフォルトWEMログイン動作をカスタム動作で置き換えるには、デフォルトCSSOクラスを拡張するJavaクラスを作成する必要があります。CSSOクラスを拡張することにより、デフォルトCSSOクラスで指定されたメソッドは、変更する機能に対するカスタム・クラスで指定されたメソッドで置き換えられます。

カスタムSSOソリューションを実装するために拡張する必要のある(com.fatwire.wem.sso.cas.custom.basisパッケージにある) 3つのクラスは次のとおりです。

- CustomConfiguration.java: デフォルトSpring構成ファイルで指定される外部に定義されたプロパティへのアクセスを提供します。デフォルトでは、このクラスはSpring構成ファイルからSSO構成にプロパティを注入するためのプレースホルダとしてのみ存在します。カスタムSSO実装に固有のURLや他の構成情報など、追加のプロパティを含めるには、このクラスを拡張します。

- CustomCredentials.java: カスタム認証の資格証明値の標準セットを提供します。このクラスは、web-flowハンドラまたはカスタムRESTオーセンティケータによって作成されて移入されます。デフォルトでは、このクラスは標準UsernamePasswordCredentialsオブジェクト(CASによって提供される)を定義します。このオブジェクトは、username、userIdおよびcurrentACLの各プロパティで、ユーザー認証を完了するために必要なすべての情報を収集します。これらのプロパティの値によって、オーセンティケータ(CustomAuthenticator.java)が実際のユーザー認証を実行する際に使用する属性マップが移入されます。
カスタムSSOソリューションに追加の資格情報が必要な場合はこのクラスを拡張します。このクラスがユーザー情報をオーセンティケータに渡してユーザー認証を完了する方法の例については、(Misc/Samples/WEM/Samples/CustomizableSSO/libフォルダにある)サンプルCSSOクラスSampleCredentials.javaのコードを参照してください。

- CustomAuthenticator.java: CustomAuthenticationインタフェースを実装します。このクラスは、ログイン・シーケンスの動作を制御し、認証リクエストを処理します。デフォルトでは、標準のWEMログイン・フォームを表示して、認証を完了するためにWEMフレームワークに戻ります。

注意:

デフォルトのCustomAuthenticator.javaクラスは、SSO実装のすべての認証メソッドを含んでいるため、最も重要なクラスです。

すべての認証の決定およびCAS Webフロー・アクションは、アクションが実行されるようにこのクラスに送られます。CAS Webフローでは、複数の手順を実行し、それらの手順の1つによりperformLoginActionメソッドが起動します。このメソッドは、ログイン・フォームを表示するか、または外部認証局と通信します。

このクラスは、WebCenter Sitesユーザーに外部ユーザーをマップする静的メソッドcallCsResolverPageも定義します。カスタムSSO実装で外部認証局を使用してユーザーを認証する場合は、callCsResolverPageメソッドでCSSOオーセンティケータに対する一意の名前を定義する必要があります。詳細は、「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

このクラスが実装するメソッドの完全なインタフェースの記述は次のとおりです。

static final int SUCCESS  = 0;
static final int GOTOWEM  = 1;
static final int FAILURE  = 2;
static final int REDIRECT = 3;
static final int ERROR    = 4;
static final int REPEAT   = 5;

/**
* Called from UserAuthentication handler to check for alternate
* credentials and validate appropriately.
* @param userCredentials
* @return
*/
public int authenticate(com.fatwire.wem.sso.cas.custom.basis.CustomCredentials userCredentials);

/**
* Called from CSAuthenticationHandler to check for REST user
* credentials and validate appropriately.
*/
public int authenticateRest(UsernamePasswordCredentials restCredentials);

/**
* Called from CSAuthenticationHandler to check is username/password
* combination is detected.
*/
public boolean checkRestCredentials(String token);

/**
* Called from CSAttributeDAO to check for encoded credentials and
* if so then return the correct username for DAO processing.
* @param username
* @return
*/
public String resolveRestUsername(String username);

/**
* Called from LoginViewAction to handle login view processing. This
* method allows the calling of internal CAS methods.
* @param context
* @param userAuthentication
* @param centralAuthenticationService
* @return
*/
public int performLoginAction(RequestContext context,
CustomAuthentication userAuthentication,
CentralAuthenticationService centralAuthenticationService);

/**
* Called from casLogoutView to perform sign in cleanup
* @param request
* @param response
*/
public void performLogoutAction(HttpServletRequest request, HttpServletResponse response);

63.3.2 リゾルバ資格証明の設定

spring-configurationフォルダ(cas/WEB-INF内)にあるcustomResolverCredentials.xmlファイルは、リゾルバ資格証明を外部で定義します。このため、資格証明はカスタムSSO Bean定義とは関係なく暗号化されます。外部認証局を使用してユーザーを認証する場合、customResolverCredential.xmlファイルにusernameおよびpasswordプロパティを設定し、このファイルをSpring構成ファイルで参照する必要があります。(Spring構成ファイルの詳細は、「Spring構成ファイルの作成について」を参照してください。)

リゾルバ資格証明を設定するには:

1. spring-configurationフォルダ(cas/WEB-INF内)にあるcustomResolverCredentials.xmlファイルを編集するために開きます。ファイルは次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<description>This defines the SitesCS username/password credentials needed for identity resolution</description>
<bean id="resolverCredential" class="com.fatwire.security.common.SecurityCredential">
<property name="username" value="theUsername" />
<property name="password" value="theUserpassword" />
<property name="csfKeyname" value="passwordkey" />
</bean>
</beans>

2. usernameおよびpasswordプロパティを設定します。

- username – 外部認証局がユーザーの認証に使用される場合、このプロパティは、SystemAttr表を読み取る権限を持つWebCenter Sitesユーザーのユーザー名を指定する必要があります。このユーザー名は、customCsResolverページでWebCenter Sitesデータベースを問い合せて登録済WebCenter Sitesユーザーに外部ユーザー識別子を解決する場合に使用されます。

- password – 外部認証局がユーザーの認証に使用される場合、このプロパティはusernameプロパティで指定されたユーザーのパスワードを指定する必要があります。

次に例を示します。

<property name="username" value="fwadmin" />
<property name="password" value="xceladmin" />

マッピングの実装の詳細は、「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

63.3.3 Springへのインスタンス化するJavaクラスの指定について

SSO実装のすべてのカスタマイズ設定は、spring-configurationフォルダ(cas/WEB-INF)にある、単一のSpring構成ファイルで指定されます。

この項には次のトピックが含まれます:

- Spring構成ファイルの作成について

- Spring構成ファイルの配置について

63.3.3.1 Spring構成ファイルの作成について

デフォルトSSO実装のクラスとプロパティは、Spring構成ファイルcustomDefaultWEMSSObeans.xmlで定義されています。このファイルは、spring-configurationフォルダ(cas/WEB-INF)にあります。CSSOをカスタマイズする場合は、新しいSpring構成ファイルを作成するか、またはデフォルトSpring構成ファイルで参照されるクラスとプロパティをカスタマイズします。この項の残りの部分では、2番目のオプションを中心に説明します。

デフォルトSpring構成ファイルには、デフォルトSSO実装に必要なクラスおよびプロパティを参照するいくつかのBean識別子が含まれます。customUserConfiguration BeanはCustomConfiguration.javaクラスを参照し、customUserAuthenticator BeanはCustomAuthenticator.javaクラスを参照します。これらのクラスは、Spring構成ファイルでインスタンス化され、SSO実装の認証プロセスで永続オブジェクトを作成する際に使用されます。カスタムSSOソリューションを作成するには、これらのBean内でカスタムJavaクラスを参照する必要があります。

注意:

CustomCredentials.javaクラスは、Spring構成ファイルで参照されません。かわりに、デフォルトCSSO CustomAuthenticator.javaクラスで定義されている、performLoginActionメソッドでこのオブジェクトをインスタンス化するコードを提供します。このメソッドは、すべてのログイン・リクエストに対してカスタム資格証明オブジェクトを作成し、そのオブジェクトを認証用にCASに渡します。

customUserConfiguration Beanには、デフォルトSSO実装にシステム情報を提供する構成プロパティも指定します。これらのプロパティには、SSO実装をデプロイする環境の値を設定します。Spring構成ファイルをカスタマイズする場合は、カスタムSSO実装の環境に一致するようにプロパティの値を変更するか、またはカスタムSSO実装に必要な追加のプロパティを含める必要があります。

CustomConfiguration.javaクラスを拡張することにより、Spring構成ファイルのcustomUserConfiguration Beanに追加のプロパティを定義できます。たとえば、SSO実装に対してカスタム・ログイン・フォームを提供するJSPファイルを作成した場合、CustomConfiguration.javaクラスを拡張することにより、そのJSPファイルの場所を指定するプロパティを作成します。

この項の残りの部分では、デフォルトSpring構成ファイル(customDefaultWEMSSObean.xml)で参照されるクラスおよびプロパティを分析します。

デフォルトSpring構成ファイル

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flow="http://www.springframework.org/schema/webflow-config"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/webflow-config http://www.springframework.org/schema/webflow-config/spring-webflow-config-1.0.xsd">
<!--  Custom SSO Bean definitions. This file defines either the default CAS/SSO configuration or a special user implementation. No other CAS configuration files are modified for a custom implementation    -->
<!--  This file defines the resolver credentials externally so the credentials can be encrypted independent from the custom SSO bean definitions    -->
<import resource="customResolverCredential.xml" />
<!--  This bean is never modified. It defines the web-flow controller which always passes control into the custom authenticator    -->
<bean id="customUserLoginAction"   class="com.fatwire.wem.sso.cas.web.CustomLoginViewAction"
p:centralAuthenticationService-ref="centralAuthenticationService"
p:customAuthentication-ref="customUserAuthenticator" />
<!--  This bean is usually not modified. Override it when there needs to be a custom encoding for information passed between the web-flow and any external component    -->
<bean id="customRestCoder" class="com.fatwire.wem.sso.cas.custom.basis.CustomRestTokenCoding" />
<!--  Modify this bean with a custom configuration implementation class when additional parameters are needed for a custom implementation    -->
<bean id="customUserConfiguration" class="com.fatwire.wem.sso.cas.custom.basis.CustomConfiguration"
p:casLoginUrl="@CSConnectPrefix@://@hostname@:@portnumber@/cas/login"
p:resolverUrl="@CSConnectPrefix@://@hostname@:@portnumber@/@context-path@/custom/customCsResolver.jsp" p:resolverCredential-ref="resolverCredential" p:traceFlag="false" />
<!--  Modify this bean with a customAuthentication class for a custom implementation.   -->
<bean id="customUserAuthenticator" class="com.fatwire.wem.sso.cas.custom.basis.CustomAuthenticator"
p:customConfiguration-ref="customUserConfiguration"
p:customRestCoder-ref="customRestCoder" />
</beans>

デフォルトSpring構成ファイルの分析

- リゾルバ資格証明を外部で指定したcustomResolverCredentials.xmlファイルがインポートされます。このファイルの詳細は、「リゾルバ資格証明の設定」を参照してください。

- デフォルトCSSO customConfiguration.javaクラスを参照する、customUserConfiguration Bean。このクラスの詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

- resolverURLプロパティおよびtraceflagプロパティが参照されます。

- resolverURL: 外部認証局がユーザーの認証に使用される場合、このプロパティは、WebCenter Sitesにある、customCsResolverページへの完全なURLを指定する必要があります。customCsResolverページは、ユーザーの外部識別子を取得し、WebCenter Sitesデータベースに問い合せてユーザーのWebCenter Sites資格証明を取得します。このプロパティで指定されるドメインとポート番号は、指定された値がWebCenter Sitesインストールの値と異なる場合は変更する必要があります。
マッピングの実装の詳細は、「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

- traceflag: このプロパティは、カスタムSSOレイヤーに関する情報を提供するトレース・ログを有効にするかかどうかを指定します。このプロパティは、 TrueまたはFalseのいずれかに設定できます。

- customUserAuthenticator Beanは、デフォルトCSSO CustomAuthenticator.javaクラスを参照します。このクラスの詳細は、「デフォルトCSSOクラスの拡張について」を参照してください。

63.3.3.2 Spring構成ファイルの配置について

デフォルトWEMログイン動作のためのクラスとプロパティを指定するデフォルトSpring構成ファイルは、spring-configurationフォルダ(cas/WEB-INF)にあります。独自のファイルを同じ場所に配置するには、デフォルトのファイルを非アクティブ化する必要があります(ファイルの.xml拡張子を削除するか変更します)。これは、Springではspring-configurationフォルダ(cas/WEB-INF)に含まれるすべてのSpring構成ファイルがロードされ、これらのファイルが単一の構成にマージされるためです。カスタムおよびデフォルトの両ファイルは同じBean識別子を指定するため、これらのファイルの一方のみをSpring構成で認識できます。Bean識別子が重複すると、初期化が失敗します。

注意:

customDefaultWEMSSObeans.xmlを削除しないでください。かわりに、ファイルの.xml拡張子を削除するか変更してください。こうすると、デフォルトWEMログイン画面の使用に戻るためにファイルをリストアできます。

63.3.4 外部ユーザー識別子のWebCenter Sites資格証明へのマッピング

CSSOファシリティでは、WebCenter Sitesユーザーの認証に外部認証局を使用できます。外部認証局では、ユーザーの資格証明を検証するときに、一意の外部識別子をそのユーザーに関連付けます。WEM認証を完了するには、(デフォルトCSSOクラスCustomAuthenticator.javaの静的メソッドとして定義される)メソッドcallCsResolverPageを使用して、ユーザーの外部識別子を対応するWebCenter Sitesのシステム・ユーザー名、一意の識別子およびACLにマップする必要があります。

外部識別子をWebCenter Sitesシステム・ユーザーにマップするには、customResolverCredentials.xmlファイルで外部認証プロパティを設定していることを確認してください(「リゾルバ資格証明の設定」を参照)。外部識別子から適切なWebCenter Sitesシステム資格証明へのマッピングを実装するには、次の操作を実行します。

マッピングを実装するには:

1. (拡張されたCustomAuthenticator.javaクラスで定義された) callCsResolverPageメソッドでカスタムSSO実装の外部認証局に一意のCSSOオーセンティケータ名を定義します。

たとえば、(サンプルCSSOクラスSampleAutheticator.javaで定義される)次のcallCsResolverPageメソッドは、一意のオーセンティケータ名としてsamplessoを定義します。

Map<String,String>csTokens=callCsResolverPage(externalUserId, "samplesso")

2. 一般管理者(たとえば、fwadmin/xceladmin)としてAdminインタフェースにアクセスします。

3. 「管理」ノードの下で、「ユーザー・アクセス管理」ノードを開き、「ユーザー」をダブルクリックします。

4. 外部識別子をWebCenter Sites資格証明にマップするユーザーを次のように選択します。

a. 「ユーザー名の入力」フィールドで、ユーザーの名前を入力します。

b. 「操作の選択」セクションで、「ユーザー属性の修正」オプションを選択します。

c. 「OK」をクリックします。
図63-1に示すとおり、「ユーザーの修正」フォームが開きます。

図63-1 「ユーザーの修正」フォーム

5. 「ユーザー名」列で、外部識別子をWebCenter Sites資格証明にマップするユーザーの名前をクリックします。
図63-2に示すとおり、「ユーザー属性」フォームが開きます。

図63-2 「ユーザー属性」フォーム

6. フォームで、次のようにフィールドに入力します。

- 「属性名」フィールドに、一意のCSSOオーセンティケータ名(外部認証局を特定するために使用する名前)を入力します。この名前は、(手順1の) callCsResolverPageメソッドで定義したCSSOオーセンティケータの一意の名前に一致する必要があります。

- 「属性値」フィールドに、外部認証局によって提供されたユーザーの外部識別子を入力します。

7. 「修正」をクリックして、WebCenter SitesのSystemUserAttrデータベース表に新しい属性と値を格納します。

8. 外部識別子に関連付けられているすべてのユーザーに対して手順3から7を繰り返します。

マッピング・プロセスの分析

callCsResolverPageメソッドがWebCenter Sitesシステム・ユーザーに外部識別子をマップするためにコールされる場合は、カスタムSSO実装に対して一意のCSSOオーセンティケータ名が定義されます。このメソッドは、外部識別子と一意のCSSOオーセンティケータ名を使用して、外部ユーザーをWebCenter Sitesシステム・ユーザーにマップします。このマップには、CustomCredentialsオブジェクトの関連プロパティに配置される、次のアイテムが含まれます。

- username: ユーザーのWebCenter Sitesユーザー名。

- currentUser: ユーザーのWebCenter Sitesの一意の識別子。

- currentACL: ユーザーのACL

CustomCredentialsオブジェクトは、username、currentUserおよびcurrentACLの値をCustomAuthenticator.javaクラスで定義されたauthenticateメソッドに渡します。authenticateメソッドは、これらの値を使用して、WebCenter Sitesユーザーを特定する、レスポンス・マップを作成します。

63.3.5 CAS Webアプリケーションの再起動

- カスタムSSO実装をデプロイするには、CAS Webアプリケーションを再起動します。
CASが再起動したら、spring-configurationフォルダ(cas/WEB-INF)にある、カスタムSpring構成ファイルで定義されたクラスを使用して、カスタム・ログイン動作を提供します。

63.4 CSSOサンプル実装の実行

CSSOファシリティには、カスタムSSO実装(Javaソース・ファイルを含む)の実行例が用意されています。サンプルでは、デフォルトのWEMログイン動作をカスタム・ログイン動作で置き換えています。これには、標準のユーザー名フィールドとパスワード・フィールド、ドメイン名を指定するためのユーザー用の追加フィールド、外部ユーザー識別子のフィールドが含まれます。ここでは、2種類の異なる認証、つまりユーザー名/パスワードのペア(追加のドメイン・フィールドを含む)と、外部認証局を通じたユーザー認証を示しています。

注意:

CSSOサンプルでは、ログイン・フォーム上のフィールドに適用される検証ルールは実行されません。フィールドに対する完全性はチェックされず、不正な値もレポートされません。認証が失敗すると、フォームはコメントなしに再度表示されます。本番環境でこのフォームを実装する場合、エラーが発生したら、適切な診断メッセージを使用してすべてのルールが実施されるようにします。

CSSOファシリティに含まれるすべてのサンプル・コンポーネントの詳細は、「サンプルCSSOコンポーネント」を参照してください。

サンプルSSO実装を実行するには::

1. CASクラスパス(cas/WEB-INF/libフォルダ)に配置して、customizable-sso-1.0.jar (Misc/Samples/WEM Samples/CustomizableSSO)をデプロイします。このファイルには、サンプルCSSOクラスが含まれます。
サンプル・クラスの詳細は、「サンプルCSSOクラス」を参照してください。

2. CAS Webアプリケーション・コンテキスト・フォルダ内にfatwireフォルダを作成します。SampleLoginform.jspファイルをfatwireフォルダにコピーします。

3. customizable-sso-1.0.jarファイルに含まれるクラスがインスタンス化されるように、Springに対して次のように指定します。

a. customSampleSSObeans.xml構成ファイルをspring-configurationフォルダにコピーします。

b. customSampleSSObeans.xmlファイルのプロパティを操作環境に一致するように変更します。

c. spring-configurationフォルダにあるcustomDefaultWEMSSObeans.xml構成ファイルの名前から.xml拡張子を削除します。

サンプルSpring構成ファイルの詳細は、「サンプルSpring構成ファイル」を参照してください。

4. 外部識別子の資格証明を使用してユーザーを検証する場合は、SystemUserAttr表に適切なエントリを追加して、外部ユーザー識別子とユーザーのWebCenter Sitesシステム資格証明とのマッピング関係を定義します。
手順については、「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

5. CAS Webアプリケーションを再起動します。
図63-3に示すとおり、サンプル・ログイン・フォームが開きます。

図63-3 サンプルCASログイン・フォーム

63.4.1 サンプルCSSOクラス

CSSOサンプルには、サンプルSSO実装のログイン動作のためのメソッドを提供する、デフォルトCSSOクラスを拡張する3つのJavaクラスが含まれています。

- SampleConfiguration.java: このクラスは、ユーザーがログイン・フォームでこのフィールドの値を提供する場合に、外部認証局によって検証されるドメイン・プロパティ(sampleDomain)を含むようにデフォルトCSSOCustomConfiguration.javaクラスを拡張します。sampleDomainプロパティは、SpringによってCSSO構成に注入されます。
このクラスには、ユーザーの資格証明を取得するためにコールされるサンプル・ログイン・フォームを定義するsampleFormURLプロパティも含まれます。このクラスの標準およびカスタム・プロパティは、サンプルSpring構成ファイルから提供されます。

- SampleCredentials.java: このクラスは、デフォルトCSSO CustomCredentials.javaクラスを拡張し、ユーザー認証の完了に必要なすべての情報を収集します。SampleAuthenticatorクラスは、ユーザーがログイン・フォームでユーザー名とパスワードを指定する場合に、UsernamePasswordCredentialsオブジェクトを使用します。ユーザーがユーザー名とパスワードの資格証明のかわりにログイン・フォームで外部識別子を指定する場合、SampleCredentialsオブジェクトが作成され、オーセンティケータ(この例では、サンプルSSOクラスSampleAuthenticator.java)にその情報が提供されます。
CASでは、作成される資格証明オブジェクトのタイプにより、使用されるオーセンティケータ(標準またはカスタム)が制御されます。ログイン・フォームでユーザー名とパスワードの資格証明が指定された場合、WEMの標準のユーザー名およびパスワードのオーセンティケータが自動的に使用されます。ログイン・フォームで外部識別子が指定される場合、カスタム・オーセンティケータがコールされ、SampleCredentialsオブジェクトを認証します。

- SampleAuthenticator.java: このクラスは、デフォルトCSSO CustomAuthenticator.javaクラスを拡張し、CSSOフレームワークでコールされるすべての認証メソッドを含みます。サンプルがデプロイされる場合、CAS認証時のすべての認証決定とWebフロー・アクションは、アクションが実行されるようにこのクラスに送られます。
(このクラスで拡張された) performLoginActionメソッドは、同じログイン・フォームを表示します。ユーザーがフォーム上で資格証明を送信する場合、CASはこのメソッドに戻って入力フィールドを処理します。検証が必要な資格証明に応じて、このメソッドは、ユーザーに割り当てられた資格証明が移入された、UsernamePasswordCredentialsオブジェクトまたはSampleCredentialsオブジェクトのいずれかを作成します。資格証明オブジェクトは、(CASで提供される) CASコンテキストに挿入され、TGTが要求されます。TGTリクエストは資格証明オブジェクトの認証をトリガーします。認証が拒否されたら、チケット例外によってログイン・フォームが再表示されます。認証が完了したら、Webフローの次のアクションが行われます。たとえば、チケットの取得、元のサービスURL (WebCenter Sites URL)へのチケットの追加、元のサービスへのリダイレクトが行われます。

このクラスには、2つの認証メソッドがあります。一方では、SampleCredentialsを使用して認証を処理し、他方では、通常はユーザー名/パスワード・ベースでRESTリクエストを認証します。サンプルでは、認証される新しい値としてsampleDomain値が導入されています。この場合、performLoginActionメソッドは、ユーザーによって提供されたユーザー名、パスワードおよびsampleDomain値をエンコードし、そのエンコードされた値をUsernamePasswordCredentialsオブジェクトに渡します。デフォルトWEM認証ハンドラは、sampleDomain値を検出し、authenticationRestメソッドへその資格証明を渡します。このメソッドは、他の値からsampleDomain値をデコードして、正しいドメインが指定されているかどうかを確認します。値が間違っている場合は、認証が失敗します。値が正しい場合は、このメソッドによってユーザー名およびパスワードが資格証明オブジェクトにエンコードし戻され、デフォルトWEM認証ハンドラによってユーザー名およびパスワードが検証されます。

63.4.2 サンプルSpring構成ファイル

サンプルSSO実装のクラスおよびプロパティは、(Misc/Samples/WEM Samples/CustomizableSSO/src/main/webapp/WEB-INF/spring-configurationにある)サンプルSpring構成ファイルcustomSampleSSObeans.xmlで定義されています。

この項には次のトピックが含まれます:

- サンプルSpring構成ファイルの分析

- サンプルSpring構成ファイルの配置

63.4.2.1 サンプルSpring構成ファイルの分析

サンプルSpring構成ファイルには、デフォルトSpring構成ファイルと同じBean識別子が含まれます(「Spring構成ファイルの作成について」を参照)。ただし、サンプルのログイン動作を実装するには、プロパティ値を変更します。たとえば、customUserConfiguration BeanはSampleConfiguration.javaクラスを参照し、customUserAuthenticator BeanはSampleAuthenticator.javaクラスを参照します。

また、customUserConfiguration Beanには、サンプルSSO実装にシステム情報を提供する構成プロパティも指定します。たとえば、SampleLoginForm.jspファイルでは、ユーザーの資格証明を取得するためにサンプルで使用されるブラウザ・フォームが提供されるため、SampleConfiguration.javaクラスを拡張して、sampleFormURLプロパティを含めます。このプロパティには、サンプルSSO実装用のログイン・ページの完全なURLを指定します。ドメイン名とポート番号は、CASサーバー・インストールに一致させ、パスは、設定中にこのページが配置された場所を指します。

次に、サンプルSpring構成ファイルのコードを示します。このファイルで参照されるプロパティの詳細は、「Spring構成ファイルの作成について」の「デフォルトSpring構成ファイルの分析」を参照してください。

サンプルSpring構成ファイル

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flow="http://www.springframework.org/schema/webflow-config"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd        http://www.springframework.org/schema/webflow-config http://www.springframework.org/schema/webflow-config/spring-webflow-config-1.0.xsd">

<!-- Custom SSO Bean definitions. This file defines either the default CAS/SSO configuration or a special user implementation. No other CAS configuration files are modified for a custom implementation -->

<!-- This file defines the resolver credentials externally so the credentials can
be encrypted independent from the custom SSO bean definitions -->
<import resource="customResolverCredential.xml" />

<!-- This bean is never modified. It defines the web-flow controller which always
passes control into the custom authenticator -->
<bean id="customUserLoginAction" class="com.fatwire.wem.sso.cas.web.CustomLoginViewAction"
p:centralAuthenticationService-ref="centralAuthenticationService"
p:customAuthentication-ref="customUserAuthenticator"
/>
<!-- This bean is usually not modified. Override it when there needs to be a
custom encoding for information passed between the web-flow and any external
component -->
<bean id="customRestCoder" class="com.fatwire.wem.sso.cas.custom.basis.
CustomRestTokenCoding"
/>
<!-- Modify this bean with a custom configuration class when additional parameters are needed for a custom implementation -->
<bean id="customUserConfiguration" class="com.fatwire.wem.sso.cas.sample.SampleConfiguration"
p:casLoginUrl="http://localhost:8080/cas/login"
p:resolverUrl="http://localhost:8080/cs/custom/customCsResolver.jsp"
p:resolverCredential-ref="resolverCredential"
p:traceFlag="false"
p:sampleDomain="mydomain"
p:sampleFormUrl="http://localhost:8080/cas/fatwire/SampleLoginForm.jsp"
/>
<!-- Modify this bean with a customAuthentication class for a custom implementation. -->
<bean id="customUserAuthenticator" class="com.fatwire.wem.sso.cas.sample.SampleAuthenticator"
p:customConfiguration-ref="customUserConfiguration"
p:customRestCoder-ref="customRestCoder"
/>

</beans>

63.4.2.2 サンプルSpring構成ファイルの配置

サンプル・クラスをインスタンス化するには、サンプルSpring構成ファイルをspring-configurationフォルダ(cas/WEB-INF)に配置して、デフォルトSpring構成ファイルから.xml拡張子を削除します。

詳細は、「Spring構成ファイルの配置について」を参照してください。

63.4.3 サンプルCSSOコンポーネント

サンプルCSSO実装のコンポーネントは、/WEM Samples/CustomizableSSOフォルダにあります。表63-3で説明されているフォルダがサンプルCSSO実装に含まれています。

表63-3 サンプルCSSOコンポーネント

フォルダ

説明

Misc/Samples/WEM Samples/CustomizableSSO

customizable-sso-1.0.jarファイルが含まれます。このjarファイルは、サンプルで実行可能なコードのクラスを提供します。サンプルSSO実装をデプロイする場合は、CASクラスパス(cas/WEB-INF/libフォルダ)にこのjarファイルを配置します。

Misc/Samples/WEM Samples/CustomizableSSO/lib

サンプルSSO実装でJavaソース・ファイルをコンパイルするために必要なすべてのサード・パーティのjarファイルが含まれます。

Misc/Samples/WEM Samples/CustomizableSSO/src/main/dist

個々のソース・コンポーネントとサンプル実装の操作を説明するWordドキュメントが含まれます。

注意: サンプルのソース・コードを表示する前に、これらのドキュメントを確認することをお薦めします。

Misc/Samples/WEM Samples/CustomizableSSO/src/main/java

Javaソース・ファイルのルート・フォルダ。

Misc/Samples/WEM Samples/CustomizableSSO/src/main/webapp/fatwire

SampleLoginForm.jspが含まれます。JSPは、ユーザーのログイン資格証明を取得するためにサンプルで使用されるブラウザ・フォームを提供します。サンプルを実装するには、CASアプリケーション・コンテキスト・フォルダにfatwireフォルダを作成し、そのフォルダにSampleLoginForm.jspをコピーする必要があります。

Misc/Samples/WEM Samples/CustomizableSSO/src/main/webapp/WEB-INF/spring-configuration

サンプルSpring構成ファイルcustomSampleSSObeans.xmlが含まれます。このファイルは、サンプルSSO実装に必要なSpring Bean定義を定義します。このファイルは、spring-configurationフォルダ(cas/WEB-INF)に配置する必要があります。spring-configurationフォルダに存在するファイル(customDefaultWEMSSObeans.xml)には、.xml以外の拡張子を付けるか、削除する必要があります。

注意: customDefaultWEMSSObeans.xmlファイルのコピーを保存し、標準のWEMログイン画面に戻る場合にそのコピーをリストアできるようにします。

64 WEMフレームワークでのバッファリング

アセットの作成、更新、削除操作は、読取り操作と比べるとはるかに低速です。場合によっては、これらの操作を遅延させて、最終的に一貫性が保証される形で後で操作が行われるようにすることも可能です。つまり、遅延(バッファ済)操作を実行すると、有限で不確定な時間にWebCenter Sitesプラットフォームが変更を受け取ることが保証されます。バッファリング操作はきわめて高速ですが、プラットフォームでのアセットの作成、更新、削除に必要な合計時間が短縮されるわけではありません。

WEMフレームワーク内のバッファリングの詳細は、次の項を参照してください。

- バッファリング・システムのアーキテクチャ

- バッファリングの使用

64.1 バッファリング・システムのアーキテクチャ

バッファリング・サブシステム(図64-1)の現在の実装は、Java Messaging Service (JMS)テクノロジに依存しています。

図64-1バッファリング・システムのアーキテクチャ

バッファリングは次のコンポーネントで構成されます。

- バッファリング・プロデューサ。メッセージを生成し、それをメッセージング・キュー(MQ)に入れます。

- バッファリング・コンシューマ。MQからメッセージを取得し、それをプラットフォームで維持します。

バッファリング・プロデューサは、アセットRESTサービス<BaseURI>/sites/<sitename>/types/<assettype>/assets/<id>が使用可能な場合は、WebCenter SitesとリモートSatellite Serverの両方で使用できます。リモートSatellite Serverで使用する場合、バッファリング・プロデューサはWebCenter Sitesと通信しないため、システム全体の線形スケーラビリティが確保されます。

注意:

バッファリング・コンシューマは、WebCenter Sitesでのみ使用できます。バッファリング・コンシューマは、プライマリ・クラスタ・メンバーのみで有効にすることをお薦めします。複数のクラスタ・メンバーで有効にすると、CRUD操作の順序が保証されません。

64.2 バッファリングの使用

1. JMSプロバイダがまだインストールされていない場合はインストールします。サポート対象のプロバイダについては、Oracle Technology Network (http://otn.oracle.com)から入手可能なOracle Fusion Middleware WebCenter Sites動作保証マトリックスを参照してください。

2. WebCenter Sites (およびオプションでリモートSatellite Server)でBufferingConfig.xml (表64-1)を構成します。

id="bufferingManager" class=
"com.fatwire.cs.core.buffering.jms.JmsBufferingManager"

表64-1 BufferingConfig.xmlのプロパティ

プロパティ名

説明

jmsConnectionFactory

必須。javax.jms.ConnectionFactoryのインスタンス

jmsDestination

必須。javax.jms.Destinationのインスタンス

messageConsumers

com.fatwire.cs.core.buffering.IMessageConsumer実装のリスト。

注意:

BufferConfig.xmlを構成する際には、activemq-all.jarをWebCenter Sites Webアプリケーションのクラスパス(例: WEB-INF/lib)に追加します。

3. RESTアセット・サービス<BaseURI>/sites/ <sitename>/types/<assettype>/assets/<id>を起動する場合は、buffer=trueを指定します。

注意:

バッファリングを使用すると、PUTおよびPOST操作の結果がレスポンスで返されません。かわりに、空のペイロードが送信されます。開発者は、クライアント・アプリケーションをコーディングする際にこの動作を覚えておく必要があります。

WebCenter Sitesに用意されているデフォルトのBufferingConfig.xmlファイルには、Apache ActiveMQ用のサンプル構成が含まれています。BufferingConfig.xmlファイルは、リモートSatellite Serverのメッセージ・コンシューマのリストが空である点を除いて、WebCenter SitesとリモートSatellite Serverで同じです。

65 WEMフレームワークでのアプリケーションの手動登録

アプリケーションを手動で登録するには、Adminインタフェースを使用してアプリケーションのアセットを作成し、アセットの各ビューにアセットを作成して、ビュー・アセットをアプリケーション・アセットに関連付ける必要があります。登録アセット・タイプFW_ApplicationおよびFW_ViewがAdminSite有効化されます。

WEMフレームワークでのアプリケーションの手動登録の詳細は、次の項を参照してください。

- WEMフレームワークでのアプリケーションの登録

- リファレンス: 登録アセット・タイプ

65.1 WEMフレームワークでのアプリケーションの登録

この項では、Articlesサンプル・アプリケーション(「Articlesサンプル・アプリケーションでの作業」を参照)のコードを使用して登録プロセスについて説明します。Articlesには、iframeタイプの単一ビューが含まれます。JavaScriptおよびHTMLのビューにも同じ手順が適用されます。

アプリケーションおよびビューを手動で登録するには::

1. アプリケーションを表すアイコンを作成または取得します。(アイコンは、アプリケーション・バーに表示されます。)
Articlesサンプル・アプリケーションは、次の場所にあるarticles.pngイメージ・ファイルを使用します: /sample app/articles/src/main/webapp/images/

2. アプリケーションのレイアウト(つまり各ビュー)をHTMLで指定するファイルを作成し、ビューでレンダリングされるコンテンツを保持するためのプレースホルダ・エレメントを作成します。図59-4 に、アプリケーションとビューの関係を示します。

たとえば、Articlesサンプル・アプリケーションのlayout.jspには次の行が含まれます。

<div id="articles" style="float:left;height:100%;width:100%"
class="wemholder"></div>

ビューのコンテンツは、アプリケーションが表示される際にプレースホルダ・エレメント内にレンダリングされます(layout.appがアプリケーションのレイアウトをレンダリングし、home.appがビューをレンダリングします)。

注意:

レイアウト・ファイルの作成時に、プレースホルダ・エレメントに一意のIDを指定します。ビュー・アセットを作成する際には、同じIDを親ノード属性に指定します。プレースホルダ・エレメントにclass="wemholder"を使用します。

3. ビューおよびアプリケーションを登録します。

a. 一般管理者としてAdminインタフェースにログインし、AdminSiteに移動して「管理」ノードを展開します。このノードでは、FW_ViewおよびFW_Applicationアセット・タイプが有効になります。
(ここでは、ビューおよびアプリケーションのアセットを同一セッション内で作成することを想定しています。この場合、「履歴」タブに両方のアセットが一覧表示されます。アプリケーション・アセットの作成時に、「履歴」タブからビュー・アセットを選択し、アプリケーション・アセットに関連付けます。「履歴」タブの情報は一時的なものであるため、ユーザーのセッションの後にクリアされます。アクティブ・リスト・タブでは、アセットを永続的に配置できます。手順の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。)

b. 次のように、FW_Viewアセット・タイプのインスタンスを作成します。
「新規」をクリックして新規FW_Viewを選択し、図65-1に示すように属性を設定します。(図65-1には、Articlesサンプル・アプリケーションのビュー・アセットの属性値が表示されています。)

図65-1 ビュー・アセットの属性値

名前: このビュー・アセットの短くてわかりやすい名前を入力します。

親ノード: (「WEMフレームワークでのアプリケーションの登録」の手順2で定義した)プレースホルダ・エレメントのidを入力します。プレースホルダ・エレメントには、ビューでレンダリングされたコンテンツが保持されます。

ビュー・タイプ: 次のいずれかのオプションを選択して、ビューのコンテンツをプレースホルダでレンダリングする方法を指定します。

- Iframe: プレースホルダ・エレメントにiframeのビューをレンダリングします。

- IncludeHTML: プレースホルダ・エレメントにHTMLをレンダリングします。

- IncludeJavaScript: プレースホルダ・エレメントにJavaScriptをレンダリングします。

ソースURL: ビューのコンテンツを提供するURLを入力します。たとえば、Articlesサンプル・アプリケーションの「ソースURL」の値は次のようになります: http://localhost:9080/articles-1.0/home.app

c. 次のように、FW_Applicationアセット・タイプのインスタンスを作成します。
「新規」をクリックして新規FW_Applicationを選択し、図65-2に示すように属性を設定します。(図65-2には、Articlesサンプル・アプリケーションのアプリケーション・アセットの属性値が表示されています。)

図65-2 アプリケーション・アセットの属性値

名前: このアプリケーション・アセットの短くてわかりやすい名前を入力します。

ツールチップ: ユーザーがアプリケーションのアイコンにマウスを重ねたときにアイコン上に表示されるテキストを入力します。

アイコンURL: アプリケーションを表すアイコンのURLを入力します。アイコンは、ログイン・ページおよびWEMインタフェースの上部に表示されます。たとえば、Articlesサンプル・アプリケーションの「アイコンURL」の値は次のようになります: http://localhost:9080/articles-1.0/images/articles.png

ホバー・アイコンのURL: ユーザーがアイコンにマウスを重ねたときにそのアプリケーションを表すアイコンのURLを入力します。

クリック・アイコンのURL: ユーザーがアイコンをクリックしたときにそのアプリケーションを表すアイコンのURLを入力します。

アクティブ・アイコンのURL: アプリケーションが使用中のときにそのアプリケーションを表すアイコンのURLを入力します。

レイアウト・タイプ: LayoutRenderer(デフォルトかつ唯一の値)。レイアウト・タイプは、(次のレイアウトURL属性で指定された)アプリケーションのレイアウト・ページを使用してアプリケーションのビューをレンダリングする際にUIコンテナで使用されます。

レイアウトURL: アプリケーションのレイアウトを表示するページのURLを入力します。レイアウト・ページには、ビューを配置するためのHTMLプレースホルダ・エレメント(divなどの)のみが含まれます。

たとえば、Articlesサンプル・アプリケーションのレイアウトURL値は次のようになります: "http://localhost:9080/articles-1.0/layout.app"(Spring MVCフレームワークで指定した".../layout.jsp"ではありません)。

関連: 関連付けられたFW_View: ビュー: 「WEMフレームワークでのアプリケーションの登録」の手順3で作成したビュー・アセットを選択します(「履歴」タブをクリックしてビュー・アセットを選択し、「選択したアイテムの追加」をクリックします)。

65.2 リファレンス: 登録アセット・タイプ

この項には次のトピックが含まれます:

- FW_Viewアセット・タイプ

- FW_Applicationアセット・タイプ

65.2.1 FW_Viewアセット・タイプ

このアセット・タイプはアプリケーションのビューを登録する際に使用します。各ビューに対してFW_Viewのインスタンスを作成します。Adminインタフェースに表示されるFW_Viewの属性は、表65-1およびOracle WebCenter Sites REST API Beanリファレンスを参照してください。このアセット・タイプは、AdminSiteという名前のサイトで有効になります。

表65-1 FW_View アセット・タイプの属性

属性: WebCenter Sitesインタフェース

属性: REST API

説明

名前

name

このビュー・アセットの短くてわかりやすい名前。

説明

description

このビュー・アセットの説明。

親ノード

parentnode

アプリケーションのレイアウト・ファイルにおけるプレースホルダ・エレメントのID。プレースホルダ・エレメントには、ビューでレンダリングされるコンテンツが保持されます。レイアウト・ファイルには、ビューを配置するためのHTMLプレースホルダ・エレメント(divなど)のみが含まれます。

ビュー・タイプ

viewtype

ビューをレンダリングする方法。次のビュー・タイプを使用できます。

Iframe: プレースホルダ・エレメントにiframeのビューをレンダリングします。

IncludeHTML: プレースホルダ・エレメントにHTMLをレンダリングします。

IncludeJavaScript: プレースホルダ・エレメントにJavaScriptをレンダリングします。

ソースURL

sourceurl

ビューのコンテンツを提供するURL。

JavaScript

javascriptcontent

ビュー・タイプがIncludeJavaScriptで、「ソースURL」を指定しない場合は必須です。

ビュー・タイプでIncludeJavaScriptを指定した場合、この属性で指定した内容がスクリプト・タグに組み込まれます。ビュー・タイプでIncludeJavaScriptを指定した場合は、「ソースURL」を指定するか、「JavaScript」属性でコードを指定する必要があります。

コンテンツ

includecontent

ビュー・タイプがIncludeHTMLで、「ソースURL」を指定しない場合は必須です。ビュー・タイプでIncludeHTMLを指定した場合、この属性で指定した内容がプレースホルダ・エレメント・タグに組み込まれます。ビュー・タイプでIncludeHTMLを指定した場合は、「ソースURL」を指定するか、「コンテンツ」属性でコードを指定する必要があります。

65.2.2 FW_Applicationアセット・タイプ

このアセット・タイプはアプリケーションを登録する際に使用します。アセット・タイプは、AdminSiteで有効になります。Adminインタフェースに表示されるFW_Applicationの属性は、表65-2およびOracle WebCenter Sites REST API Beanリファレンスを参照してください。

表65-2 FW_Applicationアセット・タイプの属性

属性: WebCenter Sitesインタフェース

属性: REST API

説明

名前

name

このアプリケーション・アセットの短くてわかりやすい名前。

説明

description

このアプリケーション・アセットの説明。

ツールチップ

tooltip

ユーザーがアプリケーションのアイコンにマウスを重ねたときにアイコン上に表示されるテキスト。

アイコンURL

iconurl

WEMフレームワークでこのアプリケーションを表すアイコンのURL。

ホバー・アイコンのURL

iconurlhover

ユーザーがアイコンにマウスを重ねたときにこのアプリケーションを表すアイコンのURL。

クリック・アイコンのURL

clickiconurl

ユーザーがアイコンをクリックしたときにこのアプリケーションを表すアイコンのURL。

アクティブ・アイコンのURL

iconurlactive

このアプリケーションが使用中のときにアプリケーションを表すアイコンのURL。

レイアウト・タイプ

layouttype

レイアウトのタイプ。値はLayoutRendererです。

レイアウト・タイプは、(レイアウトURL属性で指定された)アプリケーションのレイアウト・ページを使用してアプリケーションのビューをレンダリングする際に使用されます。

レイアウトURL

layouturl

アプリケーションのレイアウトが表示されるページのURL。このページには、ビューを配置するためのHTMLプレースホルダ・エレメント(divなど)のみが含まれます。

関連: 関連付けられたFW_Application: 拡張

parentnode

現在のアプリケーションを拡張する親アプリケーション。

関連: 関連付けられたFW_View: ビュー

views

このアプリケーションで使用されるビュー・アセットのリスト。

第XVII部 Oracle WebCenter Sitesのカスタマイズ

この部では、Oracle WebCenter Sites: Contributorインタフェースをカスタマイズするための開発環境について説明するとともに、カスタマイズ可能なインタフェース・コンポーネント、カスタマイズ方法、およびサポート用のコードについて説明します。この部のサンプル・コードは、バンドルされていないWebCenter Sites配布ファイルのmisc\Samples\UICustomization\ディレクトリにあります。

- 検索ビューとダッシュボードをカスタマイズするためのコードは、CustomAttrEditor.zipファイルで提供されます。

- アセット・フォームをカスタマイズするためのコードは、sample_elements.zipファイルで提供されます。

この部は、次の章で構成されています。

- Adminインタフェースのツリーのカスタマイズ

- Contributorインタフェースのコンポーネントのカスタマイズについて

- Contributorインタフェース・フレームワークおよびUIコントローラの理解

- Contributorインタフェースのダッシュボードのカスタマイズ

- Contributorインタフェースの検索ビューのカスタマイズ

- Contributorインタフェースでのグローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ

- Contributorインタフェースのアセット・フォームのカスタマイズ

- ワークフローのカスタマイズ

- カスタマイズ・フックのリアルタイム・パブリッシュの使用

- WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベントの理解

66 Adminインタフェースのツリーのカスタマイズ

WebCenter Sitesの管理ユーザーおよび編集ユーザーは、Adminインタフェースに表示される様々なツリーと対話します。こうしたツリーの変更により、Adminインタフェースをカスタマイズできます。

Adminインタフェースのツリーのカスタマイズの詳細は、次の項を参照してください。

- Adminインタフェースのツリーについて

- ツリーおよびセキュリティについて

- ツリーのエラー・ロギングについて

66.1 Adminインタフェースのツリーについて

ツリーは、図66-1に示すように、Adminインタフェースの左ペインに一連のタブとして表示されます。

図66-1 Adminインタフェース

WebCenter Sitesのツリー・タブは、ツリー・アプレットにより作成されます。ツリー・アプレットに渡される様々なパラメータを設定することにより、独自のツリーの作成または変更が可能です。ツリー・アプレットは、次に示す各種のパラメータを受け入れます。

- アプレット全体のパラメータ: アプレットの全体的な外観および動作を制御します。

- ツリー固有のパラメータ: ツリーの外観および動作を制御します。

- ノードのパラメータ: ツリーの個別ノードの外観および動作を制御します。

- OpURLノードのパラメータ: ツリーとWebCenter Sitesの通信を可能にします。

データベースにある一連のツリー・タブ表には、タブ名、どのロールがタブへのアクセス権を持つか、およびツリー・タブにデータを移入するエレメントへのパスなど、ツリー構成に関する情報が格納されます。これらの表には「ツリー・タブ」画面を介して情報を入力します。Adminインタフェースで、「管理」タブを選択して、「ツリー」ノードをクリックします。

66.1.1 ツリー・タブのロード

WebCenter Sitesで提供されているデフォルトのツリー・タブのほとんどでは、ツリー・データに対するリクエストはOpenMarket/Gator/UIFramework/LoadTabエレメントを通して渡されます。LoadTabエレメントは、セッション・タイムアウトのチェックなど、複数の基本タスクを実行します。

たとえば、「Product」タブは、ロード時に次のステップを完了します。

1. 「Product」タブにあるJavaコードにより、LoadTabエレメントがコールされます。

2. LoadTabエレメントにより、TreeTabデータベース表に問合せが行われます。これにより、「Product」ツリーの最上位ノードにデータをロードするエレメントが取得されます。この場合のエレメントは、OpenMarket/Xcelerate/ProductGroups/LoadTreeエレメントおよびOpenMarket/Xcelerate/Product/LoadTreeエレメントです。

3. OpenMarket/Xcelerate/ProductGroups/LoadTreeエレメントおよびOpenMarket/Xcelerate/Product/LoadTreeエレメントにより、データベースに対して、ツリーのノードに対応するアセットの問合せが行われ、元のツリー・アプレットにノードのデータがストリームされます。

4. ツリー・アプレットにより、ノード・データが解析され、ノードが開きます。

5. 「Product」タブのJavaコードにより、グローバル・コンテキスト・メニューを初期化するためのエレメント、つまりOpenMarket/Gator/UIFramework/LoadGlobalPopupエレメントがコールされます。このエレメントにより、「Product」タブからコールされた、各ツリーをロードするエレメントに対して、GetTypesコマンドが送信されます。ツリーをロードするエレメントにより、このコマンドが受信されると、スタート・メニュー・アイテムをグローバル・コンテキスト・メニューに表示する、アセット・タイプのリストが返されます。

6. OpenMarket/Gator/UIFramework/LoadGlobalPopupエレメントにより、指定されたアセット・タイプのスタート・メニュー・アイテムが検索され、その情報が元のツリーにストリームされます。

システムの各アセット・タイプには、LoadTreeエレメントが必要なことに注意してください。LoadTreeエレメントは、実際にツリーをロードする、別のエレメントへのポインタです。アセット・タイプが子を持つことが可能な場合、それぞれの子は、LoadTreeエレメントを持つ必要があります。LoadTreeエレメントのパスは次のとおりです。

OpenMarket/Xcelrate/AssetType/MyAssetType/LoadTree

MyAssetTypeは、LoadTreeエレメントにより参照されるアセット・タイプの名前です。

LoadTreeエレメントは、「ツリーの管理」フォームの「セクション」フィールドに設定されたアセット・タイプに基づいてコールされます。

表66-1には、ツリーをロードするためにコア・アセット・タイプによって使用される複数のエレメントのリストが含まれます。

表66-1 アセット・タイプのエレメント

アセット・タイプ

場所

説明

フレックス・グループ

OpenMarket/Gator/UIFramework/LoadGroupNodes

FlexGroupの親階層およびFlexAssetの子を表示します

フレックス・アセット

OpenMarket/Gator/UIFramework/LoadOrphanNodes

フレックス・グループに属さないフレックス・アセットを表示します

サイト・ナビゲーション・ツリー

OpenMarket/Xcelerate/AssetType/Page/LoadSiteTree

サイト・プラン・ツリーを表示します

サイト・ナビゲーション・アソシエーション

OpenMarket/Gator/UIFramework/LoadChildren

サイト・プラン・ツリーにおけるアセットのアソシエーションを表示します

ブックマーク

OpenMarket/Gator/UIFramework/LoadActiveList

ブックマーク・ツリーを表示します

管理ツリー

OpenMarket/Gator/UIFramework/LoadAdminTree

管理ツリーを表示します

管理ツリーのヘルパー・エレメント

OpenMarket/Gator/UIFramework/Admin

管理ツリー用のヘルパー・エレメントをロードします

アセット・タイプ

OpenMarket/Gator/UIFramework/LoadAdministrationAsset

ツリーの最上位レベルのアセット・タイプのノード、およびそのタイプのすべてのアセットの名前を、ツリーの下位レベルに表示します

ツリー内のノードの外観または動作を変更するには、これらの標準エレメントのいずれかに基づいて、ツリーをロードする新しいエレメントを作成します。その後、Webサイトの管理者がエレメント名およびそのエレメントへのパスを指定できるようになります。これは、「ツリー・タブ」フォームとは違う場所にある新規ツリー・フォームの「セクション名」フィールドおよび「エレメント名」フィールドで指定します。

ツリーの追加の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

注意:

デフォルトのJREインストールの一部では、ツリー内の一部のアイテムがUTF-8文字ではなく、名前の中にボックスが含まれる状態で表示される場合があります。このフォントに関する問題を解決する方法は2通りあります。

- サポートされているフォント・ファイルを$JRE_HOME/lib/fonts/fallbackにコピーします

- http://docs.oracle.com/javase/8/docs/technotes/guides/intl/fontconfig.htmlで説明されているとおりに、フォント構成プロパティファイルの1つを介したマッピングを使用してローカル・フォントを物理フォントに構成します。

ツリー・ノードの変更の詳細は、「ノードのパラメータ」を参照してください。

66.1.1.1 アプレット全体のパラメータ

アプレット全体のパラメータは、TreeAppletParams.xmlエレメントに設定されています。ツリー・アプレットの動作を変更するには、表66-2に示すように、パラメータ値を変更します。

表66-2 アプレット全体のパラメータ

パラメータ

説明

Debug

デバッグのオン/オフを切り替えます。有効な値は、trueおよびfalseです。Debugがtrueに設定されていると、Javaコンソールのデバッグおよびエラー・メッセージングがオンになります。

ServerBaseURL

すべてのノード・データのURL文字列が付加されるベース文字列を設定します。たとえば、ServerBaseURLがfile://localhostに設定され、LoadURLパラメータの値がNodeReader.testである場合、ツリーの子ノードをロードするために使用されるURLは次のようになります。

file://localhost/NodeReader.test

BackgroundColor

ツリーの背景色を、10進数のRGB値を使用して設定します。このパラメータが設定されていない場合、背景色は、ツリーが埋め込まれているHTMLフレームの色にデフォルトで設定されます。

TotalPanes

表示されるツリー・タブの数を設定します。この値は自動的に設定されます。

URLTarget

ノードのリンクを表示する対象のフレームです。デフォルト値は、XcelAction(ブラウザのウィンドウの右側にあるペインの名前)です。

66.1.1.2 ツリー固有のパラメータ

ツリー固有のパラメータは、「新規ツリー・タブの追加」フォームと「新規ツリー・タブの追加」フォームを作成するOpenMarket\Gator\UIFramework\TreeTabAdd.xmlエレメントにより設定されます。ツリーの外観または動作を変更するには、表66-3に示すパラメータ値を変更します。パラメータ値を変更するには、フォームを使用するか、TreeTabAddエレメントを変更します。

表66-3 ツリー固有のパラメータ

パラメータ

説明

Title

タブに表示されるテキストを設定します。

この値は、「管理」タブにある、「ツリーの管理」フォームのTitleフィールドで設定されます。

ToolTip

マウス・ポインタがタブ索引上にあるときに表示されるテキストを設定します。

この値は、「管理」タブにある、「ツリーの管理」フォームのTool Tipフィールドで設定されます。

LoadURI

ノードの子を取得するためにコールするページのURIです。

この値は、TreeTabAddエレメントで設定されます。

ActionURL

ツリー内のノードに対するコンテキスト・メニュー・アクションを実行するページのURLです。デフォルト値は、OpURL.xmlエレメントを示します。

この値は、TreeTabAddエレメントで設定されます。

OpenIcon

展開されたノードを表すときに使用するアイコンへのパスです。デフォルトは、プラス記号(+)です。

この値は、TreeTabAddエレメントで設定されます。

CloseIcon

展開されていないノードを表すときに使用するアイコンへのパスです。デフォルトは、マイナス記号(-)です。

この値は、TreeTabAddエレメントで設定されます。

LineStyle

ツリーのノードを線でつなぐかどうかを設定します。有効な値はAngledと空白です(デフォルトはAngled)。パラメータがAngledに設定されている場合は、ノードが線でつながれます。値を空白にしておくと、ノードは線でつながれません。

この値は、TreeTabAddエレメントで設定されます。

RootID

ルート・ノードのIDを設定します。この文字列は、ノード・パスの指定に使用されます。デフォルトで、Titleパラメータの値が設定されます。

この値は、TreeTabAddエレメントで設定されます。

GlobalItems

この値は、「管理」タブにある、「ツリーの管理」フォームのGlobalItemsフィールドで設定されます。

NodeItems

この値は、「管理」タブにある、「ツリーの管理」フォームのNodeItemsフィールドで設定されます。

66.1.1.3 ノードのパラメータ

ノードのパラメータにより、ツリーのノードの外観および動作が決定されます。これらのノードの外観および動作を定義するには、エレメントを記述します。そのエレメントによって、表66-4に示すノードのパラメータを設定し、ツリーのノードを作成するBuildTreeNode.xmlエレメントに値を渡します。

表66-4 ノードのパラメータ

パラメータ

説明

Label

このノードに表示されるテキストを指定します。値が一意である必要はありません。デフォルト値は""です。

ID

ツリー内で一意の文字列識別子です。WebCenter Sitesで選択中のパスの表現に使用されます。このIDは、WebCenter Sitesにより指定されます。

ExecuteURL

Executeアクションの完了時に表示するページのURI値です。この値の先頭には、ServerBaseURLの値が付加されます。

ノードが実行不可の場合は、このパラメータをノード・データに含めないでください。

URLTarget

ExecuteURLの対象のフレームです。ノード・データにExecuteURLが含まれていない場合は、アプレット全体のパラメータで指定された対象がデフォルトで設定されます。

Description

ツリー全体のコンテキスト・メニューでこのオプションを選択した場合、Labelで指定された文字列にかわるものです。デフォルト値は""です。

Level

このノードの相対レベルで、>= 0という数字で表されます。値が0(ゼロ)の場合は、このノードが、データを要求しているノードの直接の子であることを示します。

一度に複数レベルのノードをロードするには、この値に0 (ゼロ)より大きい数字を設定します。デフォルト値は0です。

Image

ラベルの先頭に付加されるイメージのURIです。このフィールドがノード・データに含まれていない場合は、そのノードにイメージが表示されません。

LoadURL

サブツリー階層のURIです。このフィールドがノード・データに含まれていない場合、このノードは追加のロードを必要としません。

このパラメータに指定されるURLには、ツリー・アプレットがノードの子を検索できるよう、十分な情報が含まれている必要があります。たとえば、階層が次のような場合、

「Product」タブ/Reebok/Running Shoes

LoadURLの値は次のようになります。

ContentServer?pagename=OpenMarket/Gator/UIFramework/
LoadTab&AssetType=ProductGroups&populate=OpenMarket/
Xcelerate/AssetType/ProductGroups/LoadTree&op=
load&parent=Variables.parentid

parentidは、Running ShoesアセットのアセットIDであり、opとpopulateは、ツリーをロードするエレメントをルーティングするためにLoadTabで使用されます。

OKAction

ノードのコンテキスト・メニューに表示されるアクションです。この文字列は、同一ノードのデータ・セットに複数回出現することがあります。

OpURL

サーバーに対して、指定されたアクションを実行するためのURLです。この値の先頭には、ServerBaseURLパラメータの値が付加されます。

NodeItemsパラメータの値がNULL文字列で、そのためOKActionが指定されていない場合でないかぎり、このパラメータをノード・データに含めてください。

RefreshKeys

ツリーのリフレッシュに使用できる、1つまたは一連のキーを作成します。この値を、現在のノードのIDに設定します。

LoadAdministrationAssetエレメントの抜粋を次に示します。この抜粋では、ノードのパラメータの値が設定され、その値がBuildTreeNodeエレメントに渡されます。

この抜粋で参照されているListofAssetリストは、指定されたタイプのアセットに関する情報のリストです。このリストは、エレメントの別の場所で実行される、SQL問合せにより生成されたものです。

<CALLELEMENT NAME="OpenMarket/Gator/UIFramework/BuildTreeNode">
<ARGUMENT NAME="Label"
VALUE="ListofAsset.name"/>
<ARGUMENT NAME="Description"
VALUE="ListofAsset.description"/>
<ARGUMENT NAME="ID"
VALUE="Variables.TreeNodeID"/>
<ARGUMENT NAME="OpURL"
VALUE="ContentServer?pagename=
OpenMarket/Gator/UIFramework/TreeOpURL&#38;
AssetType=Variables.AssetType"/>

<ARGUMENT NAME="ExecuteURL"
VALUE="ContentServer?pagename=
OpenMarket/Gator/UIFramework/TreeOpURL&#38;
AssetType=Variables.AssetType&#38;n0_=
Variables.packedTreeNodeID&#38;op=displayNode"/>

<ARGUMENT NAME="OKActions"
VALUE="Status;Inspect;Edit;Delete;refresh"/>
<ARGUMENT NAME="Image"
VALUE="Xcelerate/OMTree/TreeImages/AssetTypes/Variables.AssetType.gif"/>
<ARGUMENT NAME="RefreshKeys"
VALUE="ListofAsset.id"/>
</CALLELEMENT>

ツリーのノードの外観または動作をカスタマイズするには、標準エレメントの1つをコピーし、ノードの引数を変更します。ツリーをロードするエレメントには、次の変数が渡されていることに注意してください。そのため、作成またはカスタマイズした、ツリーをロードするすべてのエレメントでは、次の変数を考慮する必要があります。

LoadTreeエレメントにより渡された変数

- AssetType: 新規ツリーフォームを使用して作成されたセクション名に設定されています

- op: initに設定されています

LoadGlobalPopupエレメントにより渡された変数

- command: GetTypesに設定されています

- AssetType: 新規ツリーフォームを使用して作成されたセクション名に設定されています

- varname: スタート・メニュー・アイテムの表示対象とするアセット・タイプのカンマ区切りのリストとともに、これを設定します

- popupvar: グローバル・コンテキスト・メニューにアイテムを追加する場合はtrue、コンテキスト・メニューにアイテムを追加する必要のない場合はfalseに設定します

66.1.1.4 コマンド・ノードのコンテキスト・メニューの追加

ツリーの各ノードには、ユーザーがマウスで右クリックすると表示されるメニューがあります。このメニューのコマンドを使用すると、ノードをリフレッシュしたり、ブラウザのウィンドウの右側にページをロードできます。ノードのコンテキスト・メニューには、コマンドが追加できます。これにより、状態フォームやパブリッシュ・フォームなどのフォームのロードが可能になります。アセット・タイプおよびIDを使用してコールされるフォームはいずれも、ノードのコンテキスト・メニュー・コマンドからコールされる可能性が高いものです。

次の手順を完了することによって、ノードのコンテキスト・メニューにコマンドを追加します。

1. ノードのOKActionsフィールドに、新規コマンドを実際の表示どおりに追加します。

2. ノードのOpURLで参照されるエレメント(通常はTreeOpURLエレメント)に、ロード対象のフォームをコールする新規のIF文を追加します。

たとえば、次のTreeOpURLエレメントのコードにより、ノードが開きます。

<IF COND="Variables.op=displayNode">
<THEN>
<callelement NAME="OpenMarket/Gator/UIFramework/TreeIDFromPath">
<argument NAME="TreePath" VALUE="Variables.TreeNodePath"/>
</callelement>
<setvar NAME="id" VALUE="Variables.ID"/>
<callelement NAME="OpenMarket/Xcelerate/UIFramework/ApplicationPage">
<argument NAME="ThisPage" VALUE="ContentDetailsFront"/>
<argument NAME="contentfunctions" VALUE="true"/>
<argument NAME="AssetType" VALUE="Variables.AssetType"/>
</callelement>
</THEN>

66.1.2 ツリーのリフレッシュ

ツリーを変更可能なエレメントでは、ツリーが現在のデータを表示するようにリフレッシュする必要があります。指定可能なリフレッシュ・アクションには、次の3種類があります。

- Self: 指定されたノードの子をリフレッシュします

- Parent: 指定されたノードおよびその子をリフレッシュします

- Root: ツリー全体をリフレッシュします

ツリーをリフレッシュする手順には次の2つがあります。

1. ツリーをカスタマイズするエレメントをコーディングし、リフレッシュ対象のツリー・ノードがRefreshKeysを保持するようにします。RefreshKeysは通常、現在のノードのアセットIDで、リフレッシュの発生を許可します。

2. OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTreeエレメントをコールして_TreeRefreshKeys_変数を渡し、目的のリフレッシュのタイプを可変の値で指定します。

ノードのRefreshKeysは、BuildTreeNodeエレメントにRefreshKeys引数を渡して設定します。「ノードのパラメータ」にコードのサンプルを示します。

ツリーをリフレッシュするには、OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTreeエレメントを、次の例に示すとおりにコールします。

<CALLELEMENT NAME="OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTree">
<ARGUMENT NAME= "_TreeRefreshKeys_" VALUE= "Root:ActiveList"/>
</CALLELEMENT>

66.2 ツリーおよびセキュリティについて

WebCenter Sitesでは、WebCenter SitesのAdminインタフェースでツリーへのアクセスを制御するためにセキュリティ・ロールを使用します。システム定義の「管理」タブ、「サイト管理者」タブ、および「ワークフロー」タブについても、それらのタブのユーザーはxceladmin ACLを持っている必要があります。

追加の制御を使用できるようにするには、wcs_properties.jsonのプロパティを設定します。たとえば、xcelerate.showSiteTreeでは、デフォルトでツリーを表示するかどうかを決定します。また、xcelerate.restrictSiteTreeでは、どのユーザーがツリーを表示または非表示にできるかを決定します。ツリーおよびセキュリティの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

66.3 ツリーのエラー・ロギングについて

ツリー関連のエラーおよびデバッグ・メッセージは、すべてJavaコンソールにログ出力されます。ツリーの作成時にDebugパラメータに値を指定することで、デバッグのオン/オフを切り替えることができます。

デバッグを有効にするとパフォーマンスに影響するため、配信システムでは通常、エラー・ロギングをオフにしておいてください。

67 Contributorインタフェースのコンポーネントのカスタマイズについて

ダッシュボード、検索ビューおよびアセット・フォームなどのOracle WebCenter Sites: Contributorインタフェースのコンポーネントは、カスタマイズ可能です。

Contributorインタフェースのカスタマイズ可能なコンポーネントの詳細は、次の項を参照してください。

- 開始する前に

- Contributorインタフェースでカスタマイズできる内容

- サンプル・コードの検索場所

- 開始する場所

注意:

Contributorインタフェースは、開発者ではなく、コンテンツ・プロバイダによって使用されるように設計されています。そのため、次のシステム定義のアセット・タイプをContributorインタフェースで表示(検査)できますが、それらをContributorインタフェースで作成(または編集)できません: Template、CSElement、SiteEntry、DimensionSet、Dimension、Attribute Editor、Parent Definitions、AttributesおよびFlex Definitions。

同様に、次のシステム定義のアセット・タイプはContributorインタフェースからアクセスできません: FW_ApplicationおよびFW_View。これらのタイプのアセットは、Adminインタフェースでのみ作成(または編集)できます。

67.1 開始する前に

このガイドを使用する開発者は、Contributorインタフェースに関する実践的な知識を持っている必要があります。また、Java、JavaScriptおよびHTMLの使用経験があって、WebCenter Sites開発ツールに熟知している必要があります。

Contributorインタフェースの詳細は、『Oracle WebCenter Sitesの使用』および『Oracle WebCenter Sitesの管理』を参照してください。

67.2 Contributorインタフェースでカスタマイズできる内容

次のリストは、Contributorインタフェースでカスタマイズできるコンポーネントを要約しています。

- ダッシュボード。「Contributorインタフェースのダッシュボードのカスタマイズ」を参照してください。

- 検索ビュー。「Contributorインタフェースの検索ビューのカスタマイズ」を参照してください。

- グローバルおよびサイト固有の構成プロパティ、ツールバーおよびメニュー・バー。「Contributorインタフェースでのグローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ」を参照してください。

- アセット・フォーム。「Contributorインタフェースのアセット・フォームのカスタマイズ」を参照してください。

67.3 サンプル・コードの検索場所

このガイドでは、インタフェースのカスタマイズを例示するためにサンプル・コードの一部が提供されています。その他のコードもWebCenter Sitesに同梱されているか、個別に提供されています。このようなコードへのパスは、このガイドの個々の章でリストされています。

67.4 開始する場所

Contributorインタフェース・フレームワークには、UIコントローラというコンポーネントが含まれており、アセット・フォーム関連以外のほとんどのインタフェース関連リクエストを処理します。UIコントローラは、「Contributorインタフェース・フレームワークおよびUIコントローラの理解」で説明されています。

- ダッシュボード、検索ビュー、構成プロパティ、ツールバーまたはメニュー・バーをカスタマイズする場合、「Contributorインタフェース・フレームワークおよびUIコントローラの理解」から始め、カスタマイズ・プロセスの概念とコードに関する基本情報を取得する必要があります。

- アセット・フォームをカスタマイズする場合は、アセット・フォーム・ヘッダーの変更および属性エディタの構築について、「Contributorインタフェースのアセット・フォームのカスタマイズ」を参照してください。

68 Contributorインタフェース・フレームワークおよびUIコントローラの理解

Oracle WebCenter Sites: Contributorインタフェース・フレームワークでは、特にUIコントローラによってすべてのインタフェース・リクエストが処理され、エレメントが実行されます。

Contributorインタフェース・フレームワークおよびUIコントローラの詳細は、次の項を参照してください。

- Contributorインタフェース・フレームワークについて

- UIコントローラ

- カスタム・エレメント

68.1 Contributorインタフェース・フレームワークについて

Contributorインタフェースのフレームワークは、サービス・レイヤーの上位にあり、クライアント・リクエストを処理します。図68-1に、プレゼンテーション・レイヤーとUIコントローラで構成されたフレームワークを示します。

図68-1 Contributorインタフェース・フレームワーク

プレゼンテーション・レイヤーは、ビューをレンダリングするエレメントとレスポンスを生成するエレメントで構成されます。「UIコントローラ」で説明するように、UIコントローラは、Contributorインタフェースから受信したリクエストを処理します。

注意:

アセット・フォームContributorフレームワークの外部に存在する場合、UIコントローラはアセット・フォーム関連のリクエストの処理には使用されません。アセット・フォームの詳細は、「Contributorインタフェースのアセット・フォームのカスタマイズ」を参照してください。

68.2 UIコントローラ

図68-1に示されているUIコントローラは、Contributorインタフェースから受信したリクエストを処理します。この項では、UIコントローラのリクエスト処理フェーズ、各フェーズのエレメントのネーミング規則、およびUIコントローラにおけるカスタム・エレメントのチェック・プロセスについて説明します。

この項には次のトピックが含まれます:

- UIコントローラでリクエストを処理する方法

- エレメント・リクエストを処理するUIコントローラ: 例

68.2.1 UIコントローラでリクエストを処理する方法

UIコントローラに到達するには、fatwire/ui/controller SiteCatalogエントリを呼び出します。UIコントローラは、受信リクエストに対して少なくとも1つのパラメータ(elementName)の提供を求めます。このパラメータは、実行されるコントローラ・エレメントを決定します。たとえば、次のURLはコントローラ・エレメントFoo/Barを呼び出します。

http://localhost:7001/sites/ContentServer?pagename=fatwire/ui/controller/controller&elementName=Foo/Bar

コントローラ・エレメントは、次の3つのフェーズで処理されます。

1. 構成フェーズ

2. アクション・フェーズ

3. プレゼンテーション・フェーズ

各フェーズでは、個別のエレメントが実行されます。各フェーズの対応するエレメント名は、次で説明するように、ネーミング規則によって決定されます。

注意:

コントローラ・エレメントは、UIコントローラから呼び出すことができるエレメントです。

各フェーズで、UIコントローラはまず、そのフェーズに固有のカスタム・エレメントのテストを行います。このプロセス・フローについては、「エレメント・リクエストを処理するUIコントローラ: 例」の手順を参照してください。

1.構成フェーズ

このフェーズは、構成エレメントの評価からなります。構成エレメントには、呼び出されたコントローラ・エレメントによって使用される構成設定が含まれます。期待されるエレメント名は、<controllerElementName>Configです。<controllerElementName>は、elementNameパラメータの値です。たとえば、この例では、コントローラ・エレメント名がFoo/Barであるため、構成エレメントの期待される名前はFoo/BarConfigです。

構成フェーズは、Apache Commons構成に基づいており、構成データを有効なXMLとして書式設定する必要があります。次に例を示します。

<myconfig>
<foo>123</foo>
<bar>foobar</bar>
</myconfig>

XML構成データは、構成オブジェクトとして評価されます。つまり、XMLルート・エレメントの名前によって特定されてリクエスト範囲内で保持される、org.apache.commons.configuration.beanutils.ConfigurationDynaBeanのインスタンスとして評価されます。この例では、構成オブジェクトは、次のようにアクション・フェーズまたはプレゼンテーション・フェーズでアクセスできます。

ConfigurationDynaBean configBean = (ConfigurationDynaBean)request.getAttribute("myconfig");

ここで、myconfigは、構成エレメントの最上位レベルのXMLエレメントの名前になります。Apache Commons構成の詳細は、http://commons.apache.org/configurationで取得できます。

注意:

構成フェーズの構成エレメントについて:

1. 構成フェーズは条件付きです。エレメント<controllerElementName>Configが存在しない場合、UIコントローラはこのフェーズをスキップして、構成オブジェクトを作成することなく、次のフェーズに移動します。

2. 他の2つのフェーズとは異なり、構成エレメントは、(たとえば、ics.callElementを使用して)直接評価されません。かわりに、ics.ReadPage()を使用して、fatwire/ui/controller/readConfiguration SiteCatalogエントリから呼び出されます(これにより、その出力を取得できる)。

3. 構成オブジェクトの作成中に、コントローラは、CustomElementsの下のリクエストされたエレメントに対して、使用可能なカスタム構成があるかどうかをチェックします。カスタム構成がある場合、デフォルトでは、カスタム構成が対応するシステム構成とマージされます。これはデフォルトの動作です。カスタム構成をシステム構成とマージしない場合は、カスタム構成エレメントのElementCatalogエントリのフィールドresdetails1またはresdetails2に対してmerge=falseを指定します。
たとえば、システム構成

<myconfig>
<foo>123</foo>
<bar>foobar</bar>
</myconfig>

と、カスタム構成

<myconfig>
<foo1>456</foo1>
<bar1>foo1bar1<bar1>
</myconfig>

が存在する場合、コントローラは、システム構成とカスタム構成を次のようにマージします。

<myconfig>
<foo>123</foo>
<bar>foobar</bar>
<foo1>456</foo1>
<bar1>foo1bar1</bar1>
</myconfig>

2.アクション・フェーズ

このフェーズでは、UIコントローラはアクション・エレメントを評価します。アクション・エレメントの期待される名前は、<controllerElementName>Actionです。この例では、アクション・エレメント名はFoo/BarActionです。

アクション・エレメントは、任意のビジネス・ロジックを含みます。通常は、次のフェーズで消費されるように、リクエスト範囲内のJavaオブジェクトを構築します。

注意:

アクション・フェーズは条件付きです。エレメント<controllerElementName>Actionが存在しない場合、UIコントローラはこのフェーズをスキップして、プレゼンテーション・フェーズに移動します。

3.プレゼンテーション・フェーズ

この最後のフェーズでは、UIコントローラは、生成された出力のコンテンツ・タイプによって名前が異なるプレゼンテーション・エレメントを評価します。UIコントローラは、HTML(デフォルト動作)またはJSONのいずれかを処理できます。つまり、エレメント名は、<controllerElementName>Htmlまたは<controllerElementName>Jsonになります。

この例では、UIコントローラは、Foo/BarHtmlを評価しようとします。HTMLがデフォルトのコンテンツ・タイプであるからです。かわりにJSONデータを生成するには、次のようにレスポンス・タイプを明示的に指定する必要があります。

http://localhost:7001/sites/ContentServer?pagename=fatwire/ui/controller/controller&elementName=Foo/Bar&responseType=json

この場合、UIコントローラは、Foo/BarJsonというプレゼンテーション・エレメントを評価しようとします。

68.2.2 エレメント・リクエストを処理するUIコントローラ: 例

UIコントローラがエレメント・リクエストを処理する場合、次のようにカスタム・エレメントをテストします。

前述の各フェーズ(構成、アクションおよびプレゼンテーション)で、UIコントローラはまず、そのフェーズに固有のカスタム・エレメントのテストを検索します(詳細は、「UIコントローラでエレメントを検索する方法」を参照)。カスタム・エレメントが見つからない場合、UIコントローラはデフォルトのエレメントを検索します。デフォルトのエレメントが見つからない場合、UIコントローラはそのフェーズをスキップして、次のフェーズに移動します。

次の手順では、UIコントローラがエレメント・リクエストを処理する方法を、例をあげて説明しています。この例では、リクエストはUI/Layout/LeftNavigationという名前の既存のエレメントに対するもので、レスポンス・タイプはHtmlです。

1. 構成フェーズ。UIコントローラは、LeftNavigationエレメントの構成を検索します。つまり、UIコントローラは、CustomElements (ElementCatalog内にある)の下のLeftNavigationConfig.jspという名前のエレメントを検索します。エレメントが存在する場合、UIコントローラはこのエレメントを読み取ります。存在しない場合は、デフォルトのエレメントLeftNavigationConfig.jsp (UI/Layout/内にある)を読み取ります。UIコントローラは構成オブジェクトを生成し、このオブジェクトをリクエスト範囲内で保持します。
別の方法は、UIコントローラ・コールに引数として構成ファイル名を渡すことです。渡されたパラメータには、configNameという名前が付けられます。configNameが渡されると、UIコントローラは、そのパラメータで指定されたエレメントを検索します。

2. アクション・フェーズ。UIコントローラは、エレメントLeftNavigationAction.jspを検索します。CustomElementsの下でエレメントを見つけると、UIコントローラはこのエレメントを実行します。そうでない場合は、デフォルトのLeftNavigationAction.jspエレメント(UI/Layout/内にある)を実行します。

3. プレゼンテーション・フェーズ。この例のレスポンス・タイプはHtmlです。つまり、UIコントローラはエレメントLeftNavigationHtml.jspを検索します。CustomElementsの下でエレメントを見つけると、UIコントローラはこのエレメントを実行して、Htmlレスポンスを生成します。そうでない場合は、デフォルトのLeftNavigationHtml.jspエレメント(UI/Layout/内にある)を実行します。

68.3 カスタム要素

Contributorインタフェースをカスタマイズする場合、この項の説明に従って、推奨される場所にカスタム・エレメントを保存します。UIコントローラがそれらのエレメントをどのように検索するかを十分に理解しておいてください。

この項には次のトピックが含まれます:

- エレメント・ストレージ

- UIコントローラでエレメントを検索する方法

- エレメントの命名規則

68.3.1 エレメント・ストレージ

Contributorインタフェースのフレームワークにより、開発者はベスト・プラクティスに従って、カスタム・エレメントをシステムのデフォルト・エレメントから切り離しておくことができます。

注意:

システムのデフォルト構成を変更しないことをお薦めします。かわりに、独自のカスタム・エレメントを作成して、ElementCatalogのCustomElementsの下に保存することで、アップグレード時でも保持されるようにします。

カスタム・エレメントへのパスは、そのエレメントがグローバル、サイト固有、サイト固有およびアセット・タイプ固有、またはアセット・タイプ固有であるかどうかによって異なります。図68-2に、カスタム・エレメントへのパスを示します。

図68-2 カスタム・エレメントへのパス

68.3.2 UIコントローラでエレメントを検索する方法

UIコントローラがエレメントを検索する場合

1. UIコントローラは、まず、次の順序でCustomElementsの下にあるすべてのパスを横断することによって、エレメントのカスタマイズされたバージョンを検索します。

a. サイト固有およびアセット・タイプ固有のパス

b. アセット・タイプ固有のパス

c. サイト固有のパス

d. グローバル・パス

(パスの例として、図68-2 を参照してください。)

2. カスタム・エレメントが見つからない場合、UIコントローラはシステム定義のエレメントを使用します。

注意:

UIコントローラがアセット・タイプ固有のエレメントを使用する場合、assetTypeParamパラメータの値として有効なアセット・タイプを指定してから、そのパラメータを渡す必要があります。

68.3.3 エレメントの命名規則

WebCenter Sitesでパッケージ化されたシステム定義のエレメントまたはサンプル・エレメントを参照している場合、このガイドでは、そのエレメントへのフル・パスが提供されます。フル・パスは常にUI/Layout/で始まります。たとえば、このガイドでは、システム定義エレメントDashBoardContentsConfig.jspは、次のように表示されます。

UI/Layout/CenterPane/DashBoardContentsConfig

作成するカスタム定義のエレメントを参照する場合、パスが不明であるため、このガイドでは、エレメント(JSP)の名前のみが提供されます。次に例を示します。

DashBoardContentsConfig.jsp

カスタム・エレメントは、CustomElementsの下に保存されているものと想定されます。

69 Contributorインタフェースのダッシュボードのカスタマイズ

Oracle WebCenter Sites: Contributorインタフェースのダッシュボードをカスタマイズするには、ダッシュボードの構成に精通している必要があります。また、サンプル・コードを使用してダッシュボードのカスタマイズを試してみることもできます。

Contributorインタフェースのダッシュボードのカスタマイズの詳細は、次の項を参照してください。

- ダッシュボードのカスタマイズについて

- ダッシュボードのカスタマイズ

- ダッシュボードのカスタマイズの例

69.1 ダッシュボードのカスタマイズについて

Contributorインタフェースにログインすると、ダッシュボードが表示されます。デフォルトでは、図69-1に示すような使用準備済のウィジェット(「ブックマーク」、「SmartLists」、「チェックアウト」および「割当て」)がダッシュボードに開きます。

図69-1 デフォルトのウィジェットが表示されたダッシュボード

ダッシュボードおよびそのウィジェットの次の部分をカスタマイズできます。

- 列の数

- 列幅

- 表示名、高さおよびダッシュボード位置

- ウィジェットの数

69.2 ダッシュボードのカスタマイズ

システム定義のダッシュボードは、コントローラ・エレメントUI/Layout/CenterPane/DashboardContentsConfigによって生成されます。このエレメントをオーバーライドできます。

ダッシュボード構成は、グローバルまたはサイト固有にすることができます。デフォルトのウィジェットのカスタマイズ、新しいウィジェットの追加、および必要でないウィジェットの削除が行えます。

- ダッシュボードをカスタマイズするには、CustomElementsの下に独自のDashBoardContentsConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/DashBoardContentsConfigをオーバーライドします。

注意:

新しいウィジェットが追加されるか、既存のウィジェットが更新される場合、変更が行われるようにWEM UIのユーザー・プリファレンスを消去する必要があります。

次に、UI/Layout/CenterPane/DashBoardContentsConfigエレメントを示します。表69-1のプロパティの説明が続きます。

エレメントUI/Layout/CenterPane/DashboardContentsConfig

<dashboardconfig>
<dashboardlayout>
<numberofcolumns></numberofcolumns>
<columnwidths></columnwidths>
</dashboardlayout>
<components>
<component id="widgetId">
<name>widgetName</name>
<url>widgetURL</url>
<height>height_in_px</height>
<dragRestriction>true | false </dragRestriction>
<column>number_of_column_in_which_to_display_widget</column>
</component>
…
…
…
</components>
</dashboardconfig>

表69-1 UI/Layout/CenterPane/DashBoardContentsConfig.jspのプロパティ

プロパティ

説明

値

<numberofcolumns>

ダッシュボード表示の列数。

0より大きい整数。

システム・デフォルトは2です。

<columnwidths>

列のカンマ区切りの幅。

たとえば、<numberofcolumns>に3列ある場合、<columnwidths>を30、30、40にすることができます。

<components>

このセクションを使用して、ダッシュボード・ウィジェットを定義します。

該当なし

<component>

単一ウィジェットの定義に使用します。

該当なし

<id>

ウィジェットのID。

ウィジェット間で一意な英数字値。特殊文字は使用できません。

<name>

ウィジェットの表示名。

任意の文字列。

<url>

コントローラURL。

UI/Layout/CenterPane/DashBoard/<Your_Element>/ディレクトリにあるウィジェットのファイルの場所。

<height>

ウィジェットの高さ。

高さ(ピクセル単位)。たとえば、300pxです。

<dragRestriction>

ウィジェットのドラッグを制限します。

true | false

<column>

ウィジェットが表示される列。

1からn。ここで、nは<numberofcolumns>で指定された値です。

69.3 ダッシュボードのカスタマイズの例

Contributorダッシュボードに新しいウィジェットを追加できます。新しいウィジェットを追加するには、次の手順を実行します。

1. ウィジェット・エレメントを作成します。

2. カスタムDashBoardContentsConfig.jspエレメントに新しいウィジェットを登録します。

この項では、ダッシュボードにウィジェットを追加するプロセスについて説明します。

69.3.1 Hello World'ウィジェットの追加

次の手順では、図69-2に示す、単純なウィジェットを作成および登録する方法を示します。

図69-2 Hello Worldウィジェット

ダッシュボードにウィジェットを追加するには、次のようにウィジェットを作成します。

1. CustomElementsの下にJSPエレメントを作成します。この例では、エレメントにHelloWorldHtmlという名前を付けます。

2. ウィジェット・コードについては、このガイドで提供されているサンプル・ファイルに移動して、その内容をコピーできます。

ウィジェットを登録(ダッシュボードに追加)するには:

1. カスタムDashBoardContentsConfig.jspを開き、<components>セクションを見つけて、新しく作成されたウィジェットの仕様を追加します。次に例を示します。

<component id="helloworld">
<name>Hello World</name>
<url>Path_to_your_widget_under_CustomElements</url>
<height>300px</height>
<closable>false</closable>
<open>true</open>
<dragRestriction>true</dragRestriction>
<style>checkoutPortlet</style>
<column>2</column>
</component>

2. <applicationServer_install_directory>/webapps/<cs_context>/WEB-INF/classes/ReqAuthConfig.xmlファイルに移動して、excludedControllerElementsリストの下にあるサンプル・エレメントへのパスを追加します。この例では、パスは次のとおりです。

<property name="excludedControllerElements">
<list>
<value>UI/Layout/CenterPane/DashBoard/HelloWorld</value>
</list>
</property>

3. Contributorインタフェースのホームページをリフレッシュします。新しいウィジェットがダッシュボードに表示されます(図69-2 )。

69.3.2 最近変更されたアセットを表示するウィジェットの追加

この項では、前の週に変更されたアセットを表示するウィジェットを作成します。この項の手順を完了したら、ダッシュボードに図69-3のようなウィジェットが表示されます。

図69-3 「最近変更されたアセット」ウィジェット

ダッシュボードにウィジェットを追加するには、次のようにウィジェットを作成します。

1. CustomElementsの下にAction JSPエレメントを作成します。この例では、エレメントにRecentlyModifiedAssetsAction.jspという名前を付けます。ウィジェット・コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。

2. 前の手順で作成したアクション・エレメントのJson JSPエレメントを作成します。この例では、エレメントにRecentlyModifiedAssetsJson.jspという名前を付けます。コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。このエレメントをRecentlyModifiedAssetsAction.jspエレメントと同じ場所にエレメントを置きます。

3. ウィジェットのCustomElementsの下にプレゼンテーション・エレメントを作成します。ウィジェット・エレメントと同じ名前を付けます。この例では、表示エレメントにRecentlyModifiedAssetsHtml.jspという名前を付けます。コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。

注意:

プレゼンテーション・エレメントはRecentlyModifiedAssetsAction.jspエレメントをコールします。そのエレメントへのパスを入力します。

ウィジェットを登録(ダッシュボードに追加)するには:

1. カスタムDashBoardContentsConfig.jspを開き、<components>セクションを見つけて、新しく作成されたウィジェットの仕様を追加します。次に例を示します。

<component id="myrecent">
<!-- a unique identifier for the component. This must be unique among all the components. It can be alpha numeric but no special characters allowed -->
<name>Recently Modified Assets</name>
<url>Path_to_your_custom_widget's presentation_element</url>
<height>300px</height>
<closable>false</closable>
<open>true</open>
<dragRestriction>false</dragRestriction>
<style>checkoutPortlet</style>
<column>2</column>
</component>

2. <applicationServer_install_directory>/webapps/<cs_context>/WEB-INF/classes/ReqAuthConfig.xmlファイルに移動して、excludedControllerElementsリストの下にあるサンプル・エレメントへのパスを追加します。この例では、パスは次のとおりです。

<property name="excludedControllerElements">
<list>
<value>UI/Layout/CenterPane/DashBoard/RecentlyModifiedAssets</value>
</list>
</property>

3. ダッシュボードをリフレッシュして、新しく構成されたウィジェットを表示します。図69-3 に示す例を参照してください。

70 Contributorインタフェースの検索ビューのカスタマイズ

Oracle WebCenter Sites: Contributorインタフェースでは、様々なタイプの検索ビューを使用できます。検索ビューをカスタマイズするには、これらのビューおよびその構成エレメントに精通している必要があります。

Contributorインタフェースの検索ビューのカスタマイズの詳細は、次の項を参照してください。

- 検索ビューのカスタマイズについて

- カスタマイズ・プロセス

- ドッキングされていないビューのカスタマイズ

- ドッキングされたビューのカスタマイズについて

- ソート・メニューおよびツールチップのカスタマイズ

70.1 検索ビューのカスタマイズについて

ユーザーがContributorインタフェースにログインして、サイトにアクセスする場合、簡易検索または詳細検索を実行して、必要なアセットを検索できます。検索結果は、「リスト表示」または「サムネイル表示」のいずれかに表示されます。この項では、様々な検索ビュー、そのカスタマイズ可能な機能、および検索ビューの構成を制御するエレメントについて説明します。検索機能とビューの詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

この項には次のトピックが含まれます:

- 検索ビューのタイプ

- 検索ビューでカスタマイズ可能な内容

- ビューレンダリング・プロセス

- 検索ビューの構成エレメント

70.1.1 検索ビューのタイプ

検索結果パネルはドッキングされている状態またはドッキングされていない状態で、リスト表示またはサムネイル表示として表示できます。したがって、Contributorインタフェースには、次のビューが含まれます。

- ドッキングされていないリスト

- ドッキングされたリスト

- ドッキングされていないサムネイル

- ドッキングされたサムネイル

編集用にオープンになっているアセットが存在しない場合にのみ、ドッキングされていないビューが開きます。ドッキングされたビューは、編集モードのアセットにアタッチされるため、アセットが編集モードでオープンになっている場合にのみ開きます。

70.1.2 検索ビューでカスタマイズ可能な内容

図70-1は、リスト表示でカスタマイズ可能な機能を示しています。図70-2は、サムネイル表示でカスタマイズ可能な機能を示しています。詳細は、「ドッキングされていないビューのカスタマイズ」を参照してください。これはドッキングされたビューにも適用されます。

ソート・メニューとツールチップは個別にカスタマイズされます。詳細は、「ソート・メニューおよびツールチップのカスタマイズ」を参照してください。

どのビューが指定のモードでデフォルトで開くかは、構成設定とユーザーの検索習慣にかかっています。たとえば、ドッキング解除済モードでのデフォルト・ビューとしてサムネイル表示を設定した場合、ユーザーがドッキング解除済モードで最初に検索を実行するときにサムネイル表示が開き、リスト表示に切り替えるまでサムネイル表示が開かれたままになります。(ブラウザのCookieが消去されるまで、検索によりユーザーの選択内容が記憶されます。)

図70-1に、リスト表示のカスタマイズ可能な機能を示します。

図70-1 リスト表示のカスタマイズ可能な機能

リスト表示のカスタマイズ可能な機能は次のとおりです。

- 返されるアイテムの最大数

- ページ当たりの行数

- 表示するフィールド(列)

- 列の表示名

- 列幅

- 日付とその他のフィールドのフォーマット

- デフォルトのソート・フィールドとソート順

- ソート・メニュー(ドッキング・モード)

- コンテキスト(右クリック)メニュー

- ツールチップ(ドッキング・モード)

図70-2に、サムネイル表示のカスタマイズ可能な機能を示します。

図70-2 サムネイル表示のカスタマイズ可能な機能

サムネイル表示のカスタマイズ可能な機能は次のとおりです。

- 返されるアイテムの最大数

- ページ当たりの行数

- 特殊なサムネイルを表示するアセット・タイプ

- 表示するフィールド

- 日付とその他のフィールドのフォーマット

- デフォルトのソート・フィールドとソート順

- ソート・メニュー

- コンテキスト(右クリック)メニュー

- ツールチップ(ドッキング・モード)

70.1.3 ビューレンダリング・プロセス

システム定義およびカスタム定義のビューは、同様のプロセスでレンダリングされます。このことを例示するために、まず、システム定義ビューをレンダリングします。

システム定義ビューは、次のエレメント(JSP)によってレンダリングされます。ドッキングされていないビューとドッキングされたビューの名前はDocked接頭辞のみが異なります。

ドッキングされていない場合:

- リスト表示は、エレメントUI/Layout/CenterPane/Search/View/ListViewHtmlによってレンダリングされます。

- サムネイル表示は、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewHtmlによってレンダリングされます。

ドッキングされた場合:

- リスト表示は、エレメントUI/Layout/CenterPane/Search/View/DockedListViewHtmlによってレンダリングされます。

- サムネイル表示は、エレメントUI/Layout/CenterPane/Search/View/DockedThumbnailViewHtmlによってレンダリングされます。

ドッキングされていないビューとドッキングされたビューのレンダリングは似ています(ドッキングされたビューのエレメントの名前がDockedで始まることを除く)。次の手順は、ドッキングされていないビューのレンダリングを示しています。

1. ユーザーが検索ルーチンを実行する場合、検索機能によってユーザーの現在のビューが決まります。これはデフォルト・ビューか、それ以降に選択されたビューのいずれかです。

注意:

デフォルト・ビューは、初めて検索が実行されるときにシステムがレンダリングするビューです。(リスト表示は、ドッキング解除済モードとドッキング・モードの両方のシステム定義のデフォルト・ビューです。)ユーザーが別のビューに切り替える場合、ブラウザのCookieが消去されるまで、ユーザーの選択内容が記憶され、表示され続けます。

2. 検索機能により、UI/Layout/CenterPane/Search/SearchResultsConfigが読み取られ、ビューのレンダリングを開始するエレメントへのパスが取得されます。

- ユーザーが初めて検索を実行しているか、またはデフォルト・ビューを使用し続けている場合、検索により、<defaultview>プロパティの値が読み取られます。

- ユーザーのビューがデフォルト・ビュー以外の場合、検索により、(手順1で決定されたビューに応じて)<listview>または<thumbnailview>プロパティのいずれかの値が読み取られます。

3. 検索により、リスト表示がレンダリングされる必要があることが決定される場合、エレメントUI/Layout/CenterPane/Search/View/ListViewConfigが読み取られ、UI/Layout/CenterPane/Search/View/ListViewHtmlが呼び出されて、リスト表示がレンダリングされます。検索により、サムネイル表示がレンダリングされる必要があることが決定される場合は、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigが読み取られ、UI/Layout/CenterPane/Search/View/ThumbnailViewHtmlが呼び出されて、サムネイル表示がレンダリングされます。

前述のシステム定義のエレメントは、すべてオーバーライドできます。同じ名前を付けた独自のエレメントをカスタマイズして、それらをCustomElementsの下に配置して、図70-1および図70-2の変更を実現してください。エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfigおよびUI/Layout/CenterPane/Search/View/SearchToolTipHtmlをそれぞれ使用して、ソート・メニューやツールチップなどの、個々の機能をカスタマイズすることもできます。

エレメントの包括的なリストについては、「検索ビューの構成エレメント」を参照してください。

70.1.4 検索ビューの構成エレメント

この項では、検索ビューのカスタマイズに使用するJSPエレメントについて概説します。

- システム定義の構成エレメント: 検索ビューおよびグローバルな検索、またはサイト、アセット・タイプ、サイトとアセット・タイプの両方に固有の検索をカスタマイズするには、同じ名前を付けたエレメントを構成します。カスタマイズしたエレメントのすべてをCustomElementsの下に格納する必要があります(例については、図70-3を参照してください)。エレメントの概要については、次の表を参照してください。

- 表70-1に、使用準備済のドッキングされていないビューを定義するシステム定義の構成エレメント(エレメント名のすべてがConfigで終わる)を示します。

- 表70-2 に、使用準備済のドッキングされたビューを定義するシステム定義の構成エレメント(エレメント名のすべてがConfigで終わる)を示します。

- 表70-3 に、ソート・メニューやツールチップなど、検索ビューの個々の機能をカスタマイズするためのシステム定義のエレメント(エレメント名がConfigまたはHtmlで終わる)を示します。

- カスタム・エレメント: 表70-4に、WebCenter Sitesに同梱されている、カスタマイズ・コードを例示するためのサンプル・カスタム・エレメントを示します。

表70-1 ドッキングされていない検索ビューの構成エレメント

構成エレメント(JSP)へのパス

説明

参照

UI/Layout/CenterPane/Search/SearchResultsConfig

ドッキング解除済モードにあるデフォルトの検索ビュー(リスト表示またはサムネイル表示)を設定するエレメント。

デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

UI/Layout/CenterPane/Search/View/ListViewConfig

ドッキングされていないリスト表示を構成するエレメント。

ドッキングされていないリスト表示のカスタマイズ

UI/Layout/CenterPane/Search/View/ThumbnailViewConfig

ドッキングされていないサムネイル表示を構成するエレメント。

ドッキングされていないサムネイル表示のカスタマイズ

表70-2 ドッキングされた検索ビューの構成エレメント

構成エレメント(JSP)へのパス

説明

参照

UI/Layout/CenterPane/Search/DockedSearchResultsConfig

ドッキング・モードにあるデフォルトの検索ビュー(リスト表示またはサムネイル表示)を設定するエレメント。

カスタマイズ・プロセス

UI/Layout/CenterPane/Search/View/DockedListViewConfig

ドッキングされたリスト表示を構成するエレメント。

カスタマイズ・プロセス

UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

ドッキングされたサムネイル表示を構成するエレメント。

カスタマイズ・プロセス

表70-3 検索ビューの他の機能の構成およびプレゼンテーション・エレメント

構成エレメント(JSP)へのパス

説明

参照

UI/Layout/CenterPane/Search/View/SearchTopBarConfig

ドッキングされたリスト、ドッキングされていないサムネイルおよびドッキングされたサムネイル表示のソート・ドロップダウン・メニューのソート・オプションとしてフィールドを構成するエレメント。

ソート・メニューのカスタマイズ

UI/Layout/CenterPane/Search/View/SearchToolTipHtml

ドッキングされたビュー(リストおよびサムネイル)のツールチップを構成するエレメント。このエレメントにより、ツールチップの外観とカスタム・メッセージを構成できます。

検索結果のツールチップのカスタマイズ

UI/Config/GlobalHtml

コンテキスト(右クリック)メニューを構成するエレメント。このエレメントは、すべての検索ビューに対して有効です。

コンテキスト・メニューのカスタマイズ

表70-4 検索ビューのカスタム・サンプル・エレメント

サンプル・エレメントへのパス

説明

CustomElements/avisports/AVIArticle/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig

avisportsサンプル・サイトにあるAVIArticleアセット・タイプのドッキングされていないサムネイル表示の構成エレメント。

CustomElements/avisports/AVIArticle/UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

avisportsサイトにあるAVIArticleアセット・タイプのドッキングされたサムネイル表示の構成エレメント。

CustomElements/avisports/AVIImage/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig

avisportsサンプル・サイトにあるAVIImageアセット・タイプのドッキングされていないサムネイル表示の構成エレメント。

CustomElements/avisports/AVIImage/UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

avisportsサンプル・サイトにあるAVIImageアセット・タイプのドッキングされたサムネイル表示の構成エレメント。

CustomElements/avisports/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig

avisportsサンプル・サイトのドッキングされていないサムネイル表示の構成エレメント。

CustomElements/avisports/UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

avisportsサンプル・サイトのドッキングされたサムネイル表示の構成エレメント。

70.2 カスタマイズ・プロセス

ドッキング解除済モードおよびドッキング・モードでビューをカスタマイズする場合、類似した手順を実行します。主な違いは次のとおりです。

- ドッキングされてないビューおよびドッキングされたビューのカスタマイズ:
ドッキングされていないビューをカスタマイズする場合は、「ドッキングされていないビューのカスタマイズ」の手順に従い、その項で示すように構成エレメント(JSP)に名前を付けます(表70-1にも記載されています)。ドッキングされたビューをカスタマイズする場合も、「ドッキングされていないビューのカスタマイズ」の手順に従いますが、表70-2に示すように構成エレメントに名前を付けます(つまり、Docked接頭辞を付けます)。

- 検索ビューのソート・メニューおよびツールチップのカスタマイズ:
ソート・メニューおよびツールチップを作成するエレメントは、ドッキング解除済モードおよびドッキング・モードの両方に適用されます。モードに関係なく、表70-3(および「ソート・メニューおよびツールチップのカスタマイズ」)に示すように、エレメントに名前を付けます。

- ドッキングされたリスト表示またはドッキングされたサムネイル表示でフィールドを表示する場合:
デフォルトで、UI/Layout/CenterPane/Search/View/DockedListViewConfigエレメントは、UI/Layout/CenterPane/Search/View/ListViewConfigエレメントを指し、最初のリストされたフィールドのみを取得して、ドッキングされたリスト表示でその名前を表示します。フィールドは、最初の<field>プロパティで、次のように定義されます。

<field>
<fieldname>fieldname</fieldname>
<displayname>DisplayName</displayname>

ドッキングされたリスト表示で他のフィールド名を表示する場合は、カスタムDockedListViewConfig.jspエレメントでその名前を指定します。同じロジックは、ドッキングされたサムネイル表示のフィールド名の表示に適用されます(構成エレメントがThumbnailViewConfigおよびDockedThumbnailViewConfigと名付けられることを除く)。

70.3 ドッキングされていないビューのカスタマイズ

ドッキングされていないリスト表示およびサムネイル表示のカスタマイズには、同じ名前を付けた独自のエレメントを構成し、それらをCustomElementsの下に配置して、表70-1に示されているシステム定義のエレメントをオーバーライドすることが関係しています。

この項には次のトピックが含まれます:

- ドッキングされていないビューのカスタマイズの基本手順

- デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

- ドッキングされていないリスト表示のカスタマイズ

- ドッキングされていないサムネイル表示のカスタマイズ

70.3.1 ドッキングされていないビューのカスタマイズの基本手順

ドッキングされていないビューをカスタマイズするには、次の手順の任意の組合せを実行します。

- すべてのアセット・タイプまたは選択したアセット・タイプに対して、デフォルトのドッキングされていないビューをリストまたはサムネイルとなるように設定します。ビューを設定するには、「デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定」に示すように、エレメントUI/Layout/CenterPane/Search/SearchResultsConfigをオーバーライドします。

- ドッキングされていないリスト表示またはサムネイル表示(あるいはその両方)を構成します。ビューに表示される列数の指定、列名と列幅の構成、返されるアイテムのソート順の指定などを行います(図70-1および図70-2を参照)。

- リスト表示を構成するには、「ドッキングされていないリスト表示のカスタマイズ」で説明しているように、エレメントUI/Layout/CenterPane/Search/View/ListViewConfigをオーバーライドします。

- サムネイル表示を構成するには、「ドッキングされていないサムネイル表示のカスタマイズ」で説明しているように、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigをオーバーライドします。

- ビューのソート・メニューなど、追加機能を構成します。この手順では、ビュー自体ではなく、ビューの機能(ソート・メニューなど)に固有のJSPエレメントを構成します。詳細は、「ソート・メニューおよびツールチップのカスタマイズ」を参照してください。

70.3.2 デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

デフォルトの検索ビュー(リストまたはサムネイル)を設定する場合、すべてのアセット・タイプに対してグローバルに設定します。選択したアセット・タイプに対してデフォルトの検索ビューを指定することもできます。

- デフォルトの検索ビューを設定するには、CustomElementsの下に独自のSearchResultsConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/SearchResultsConfigをオーバーライドします。
エレメントUI/Layout/CenterPane/Search/SearchResultsConfigが次に表示されます。表70-5では、これらのプロパティについて説明します。

エレメントUI/Layout/CenterPane/Search/SearchResultsConfig

<searchconfig>
<listview>UI/Layout/CenterPane/Search/View/ListView</listview>
<thumbnailview>UI/Layout/CenterPane/Search/View/ThumbnailView</thumbnailview>
<defaultview>listview</defaultview>
<assettypeviews>
<assettype id="Page" name="Page">listview</assettype>
…
…
…
</assettypeviews>
</searchconfig>

表70-5 UI/Layout/CenterPane/Search/SearchResultsConfigのプロパティ

プロパティ

説明

値

<listview>

ListViewコントローラ・エレメントへのパス

UI/Layout/CenterPane/Search/View/ListView

このプロパティの値を変更しないでください。

<thumbnailview>

ThumbnailViewコントローラ・エレメントへのパス

UI/Layout/CenterPane/Search/View/ThumbnailView

このプロパティの値を変更しないでください。

<defaultview>

リストまたはサムネイルがデフォルト・ビューであるかどうかを指定します。

デフォルト・ビューは、初めて検索を実行するときに開くビューです。ユーザーがビューを切り替える場合は、ブラウザのCookiesが消去されるまで、ユーザーの選択内容が記憶されます。

listview | thumbnailview

このプロパティの値は、大文字と小文字が区別されます。

<assettypeviews>

1つ以上のアセット・タイプに対してデフォルト・ビューを選択的に構成するために使用します。

N/A

<assettype id= name= >

アセット・タイプおよびそのデフォルト・ビューの指定に使用します(ユーザーが別のビューに切り替えるか、またはブラウザのCookiesを消去するまで、そのままの状態になります)。

必要な数のアセット・タイプを指定できます(<assettype>当たり1つ)。

<assettype id="unique_identifier" name="AssetTypeName"> listview | thumbnailview </assettype>

70.3.3 ドッキングされていないリスト表示のカスタマイズ

リスト表示をカスタマイズする場合は、返されるコンテンツのタイプとそのプレゼンテーションを設定できます。

- ドッキングされていないリスト表示をカスタマイズするには、CustomElementsの下に独自のListViewConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/View/ListViewConfigをオーバーライドします。
エレメントUI/Layout/CenterPane/Search/View/ListViewConfigが次に表示されます。表70-6では、これらのプロパティについて説明します。

エレメントUI/Layout/CenterPane/Search/View/ListViewConfig

<listviewconfig>
<numberofitems>1000</numberofitems>
<numberofitemsperpage>100</numberofitemsperpage>
<defaultsortfield>  </defaultsortfield>
<defaultsortorder>  </defaultsortorder>
<fields>
<field id="name">
<fieldname>name</fieldname>
<displayname>Name</displayname>
<width>350px</width>
<formatter>fw.ui.GridFormatter.nameFormatter</formatter>
<displayintooltip>true</displayintooltip>
</field>
<field id="updateDate">
<fieldname>updateddate</fieldname>
<displayname>Modified</displayname>
<!-- <dateformat>MM/dd/yyyy hh:mm a z </dateformat> -->
<javadateformat>SHORT</javadateformat>
<width>auto</width>
<formatter></formatter>
<displayintooltip>true</displayintooltip>
</field>
…
…
…
</fields>
</listviewconfig>

表70-6 UI/Layout/CenterPane/Search/View/ListViewConfigのプロパティ

プロパティ

説明

値

<numberofitems>

検索によって返されるアイテムの最大数。

0より大きい整数。

-1を入力した場合は、検索基準に一致するすべての結果が返されます。

<numberofitemsperpage>

検索結果に必要なページ当たりの行数。

100がデフォルトです。

<defaultsortfield>

検索結果をフェッチする場合に検索によってソートされる必要があるデフォルト・フィールド。

デフォルトは空です。したがって、検索結果は関連性を基準に表示されます。他のフィールドをソート用にデフォルトとして設定する必要がある場合は、このエレメントを構成します。

<defaultsortorder>

検索で使用されるソート順。

ascending | descending

<defaultsortfield>が指定されている場合に必要です。

<fields>

リスト表示で表示される列。これらの列は、<fields>にリストされているのと同じ順序で表示されます。

アセット・タイプ固有の構成を作成し、検索結果にアセット・タイプ固有の属性を表示する場合は、アセット・タイプ索引と属性検索を有効にする必要があります。詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

この手順をスキップする場合は、検索によりグローバル索引が使用されます。

N/A

<field id= >

リスト表示に表示される列を定義します。

<field id="unique_identifier">

<fieldname>

列にレンダリングするアセットのフィールド名。

この名前は、Lucene索引の列名と一致している必要があります。

localeがフィールド名として追加される場合、サイト・ディメンションが有効な場合にのみ表示されます。

<displayname>

列ヘッダーに表示される表示名。

英数字文字列

<width>

ピクセル単位の列幅。

px単位の幅(例: 350px)。

最後のフィールドの幅をautoに設定することをお薦めします。

<formatter>

希望のフォーマットで列の値を表示するDojoフォーマッタ機能。

フォーマッタは、Dojoモジュールで使用できる必要があります。UI/Config/GlobalHtmlのmodulesプロパティを参照してください。

<displayintooltip>

関連するフィールドがドッキングされたリスト表示のツールチップでリストされる必要があるかどうかを示します。

エレメントUI/Layout/CenterPane/Search/View/ SearchToolTipHtmlは、ツールチップをレンダリングし、このプロパティの値を使用して、そのツールチップに関連するフィールド名をリストするかどうか(フィールド値もリストされる)を決定します。ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。手順は、「検索結果のツールチップのカスタマイズ」を参照してください。

true | false

<dateformat>

日付フィールドにのみ適用されます。これは、日付がjavadateformat以外のフォーマットで表示される必要がある場合にカスタム日付フォーマットを指定するオプションです。

有効な日付フォーマット文字列。

<dateformat>が使用される場合は、<javadateformat>より優先されます。

<javadateformat>

日付フィールドにのみ適用されます。

有効な値は、SHORT、MEDIUM、LONGおよびFULLです。

<javadateformat>が省略されるか、空白のままにされる場合、デフォルトでSHORTが使用されます。<dateformat>が使用される場合は、<javadateformat>より優先されます。

70.3.4 ドッキングされていないサムネイル表示のカスタマイズ

サムネイル表示をカスタマイズする場合は、返されるコンテンツのタイプとそのプレゼンテーションを設定できます。

ドッキングされていないサムネイル表示をカスタマイズするには、CustomElementsの下に独自のThumbnailViewConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigをオーバーライドします。

エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigが次に表示されます。表70-7では、これらのプロパティについて説明します。

注意:

<formatter>および<assettypes>は、特に注意を要します。エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigはUI/Layout/CenterPane/Search/View/ListViewConfigとほとんど同じですが、<formatter>プロパティは異なる方法で定義されます。また、<assettypes>はThumbnailViewConfigの専用のプロパティで、サムネイルのレンダリングに使用されます。

<assettypes>プロパティは、その使用法が例示されている、「ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細」で詳しく説明されています。例の1つでは、ビデオ・プレーヤを表示するカスタム・エレメントでビデオ・アセットを補足する方法を示しています。

エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfig

<thumbnailviewconfig>
<numberofitems>1000</numberofitems>
<defaultsortfield></defaultsortfield>
<defaultsortorder></defaultsortorder>
<numberofitemsperpage>12</numberofitemsperpage>
<formatter>fw.ui.GridFormatter.thumbnailFormatter</formatter>
<fields>
<field id="name">
<fieldname>name</fieldname>
<displayname>Name</displayname>
<displayintooltip>true</displayintooltip>
</field>
<field id="updateDate">
<fieldname>updateddate</fieldname>
<displayname>Modified</displayname>
<!-- <dateformat>MM/dd/yyyy hh:mm a z </dateformat> -->
<javadateformat>SHORT</javadateformat>
<displayintooltip>true</displayintooltip>
</field>
…
…
…
</fields>
<assettypes>
<assettype id="unique_identifier">
<type>AVIImage</type>
<subtype>Image</subtype>
<element>UI/Layout/CenterPane/Search/View/ImageThumbnail</element>
<attribute>imageFile</attribute>
</assettype>
…
…
…
</assettypes>
</thumbnailviewconfig>

表70-7 UI/Layout/CenterPane/Search/View/ThumbnailViewConfigのプロパティ

プロパティ

説明

値

<numberofitems>

検索によって返されるアイテムの最大数。

0より大きい整数。

-1を入力した場合は、検索基準に一致するすべての結果が返されます。

<numberofitemsperpage>

検索結果に必要なページ当たりの行数。

100がデフォルトです。

<formatter>

希望のフォーマットで値を表示するDojoフォーマッタ機能。

フォーマッタは、Dojoモジュールで使用できる必要があります。UI/Config/GlobalHtmlのmodulesプロパティを参照してください。

<defaultsortfield>

検索結果をフェッチする場合に検索によりソートされる必要があるデフォルトのソート・フィールド。

デフォルトは空です。したがって、検索結果は関連性を基準に表示されます。他のフィールドをソート用にデフォルトとして設定する必要がある場合は、このエレメントを構成します。

<defaultsortorder>

検索で使用されるソート順。

ascending | descending

これは、<defaultsortfield>が指定される場合に必要です。

<fields>

サムネイル表示のサムネイルの下に表示されるフィールド。これらのフィールドは、<fields>にリストされているのと同じ順序で表示されます。

アセット・タイプ固有の構成を作成し、検索結果にアセット・タイプ固有の属性を表示する場合は、アセット・タイプ索引と属性検索を有効にする必要があります。詳細は、『Oracle WebCenter Sitesの管理』の次の項を参照してください。

- 検索索引へのアセット・タイプの追加

- アセット・タイプ索引に対する属性の構成

この手順をスキップする場合は、検索によりグローバル索引が使用されます。

N/A

<field id= >

サムネイルの下のフィールドを記述します。

<field id="unique_identifier">

<fieldname>

サムネイルの下にレンダリングされるアセットのフィールド名。

この名前は、Lucene索引の列名と一致している必要があります。

localeがフィールド名として追加される場合、サイト・ディメンションが有効な場合にのみ表示されます。

<displayname>

サムネイルの下にレンダリングされる表示名。

英数字文字列

<dateformat>

日付フィールドにのみ適用されます。これは、日付がjavadateformat以外のフォーマットで表示される必要がある場合にカスタム日付フォーマットを指定するオプションです。

有効な日付フォーマット文字列。

<dateformat>が使用される場合は、<javadateformat>より優先されます。

<javadateformat>

日付フィールドにのみ適用されます。

有効な値は、SHORT、MEDIUM、LONGおよびFULLです。

<javadateformat>が省略されるか、空白のままにされる場合、デフォルトでSHORTが使用されます。<dateformat>が使用される場合は、<javadateformat>より優先されます。

<displayintooltip>

関連するフィールドがドッキングされているサムネイル表示のツールチップでリストされる必要があるかどうかを示します。

エレメントUI/Layout/CenterPane/Search/View/SearchToolTipHtmlは、ツールチップをレンダリングし、<displayintooltip>プロパティの値を使用して、そのツールチップに関連するフィールドをリストするかどうか(フィールド値もリストされる)を決定します。ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。手順は、「検索結果のツールチップのカスタマイズ」を参照してください。

true | false

<assettypes>

このセクションでは、特殊なサムネイルが表示されるアセット・タイプを指定します。各アセット・タイプには、コンテンツがサムネイルとしてレンダリングされる属性がある必要があります。

このセクションをいつカスタマイズする必要があるかの詳細は、「ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細」を参照してください。

N/A

<assettype id= >

特殊なサムネイルが表示されるアセット・タイプを記述します。

<assettype id="unique_identifier">

<type>

サムネイルがレンダリングされるアセット・タイプの名前。

詳細は、「システム定義のイメージ・サムネイル・エレメントの再使用」および「カスタム・サムネイル・レンダリング・エレメントの使用」を参照してください。

<subtype>

アセット・タイプのサブタイプ。

詳細は、「システム定義のイメージ・サムネイル・エレメントの再使用」および「カスタム・サムネイル・レンダリング・エレメントの使用」を参照してください。

<element>

<attribute>で指定されるコンテンツをサムネイルとしてレンダリングするコントローラ・エレメントへのパス。

詳細は、「システム定義のイメージ・サムネイル・エレメントの再使用」および「カスタム・サムネイル・レンダリング・エレメントの使用」を参照してください。

エレメントを指定しない場合は、images/searchディレクトリに保存されている静的なアイコンのレンダリングに、システム定義のエレメントUI/Layout/CenterPane/Search/View/GlobalThumbnailが使用されます。詳細は、「静的アイコンの使用」を参照してください。

<attribute>

コンテンツがサムネイルとして表示される属性。

詳細は、「システム定義のイメージ・サムネイル・エレメントの再使用」および「カスタム・サムネイル・レンダリング・エレメントの使用」を参照してください。

70.3.4.1 ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細

表70-7に記載されている<assettypes>セクションは、カスタマイズを選択した機能によっては、構成する必要がある場合があります。次の様々な<assettypes>構成シナリオでは、最も一般的に実行されるカスタマイズを対象に説明します。

この項には次のトピックが含まれます:

- 静的アイコンの使用

- システム定義のイメージ・サムネイル・エレメントの再使用

- カスタム・サムネイル・レンダリング・エレメントの使用

70.3.4.1.1 静的アイコンの使用

(ファイル・システムに格納される)独自の静的サムネイルを使用する場合は、次の規則に従っているかぎり、UI/Layout/CenterPane/Search/View/ThumbnailViewConfigエレメントの<assettypes>セクションをカスタマイズする必要はありません。

- サムネイル・アイコンの名前には空白を入れないでください(アンダースコアで置き換えられます)。名前は、サムネイルのサイズによって、次のいずれかのフォーマットである必要があります。

- <assettypename>.pngまたは<assettypename>-<subtype>.png(小さなサムネイル、96x96、ドッキングされたビュー)

- <assettypename>_large.pngまたは<assettypename>-<subtype>_large.png(大きなサムネイル、170x170、ドッキングされていないビュー)

- アイコンの保存場所は、ファイル・システムの/images/searchディレクトリです。

前述の規則に従う場合、UI/Layout/CenterPane/Search/View/ThumbnailViewConfigエレメントによってアイコンがサムネイルとして自動的にレンダリングされます。このエレメントは、/images/searchディレクトリでアイコンを検索するようにコード化されています。アセット・タイプおよびサブタイプに基づいたアイコンの名前を付けると、そのタイプおよびサブタイプのアセットにアイコンが自動的に関連付けられます。

70.3.4.1.2 システム定義のイメージ・サムネイル・エレメントの再使用

ThumbnailViewConfig.jspエレメントの<assettypes>セクションのカスタマイズは、システム定義のエレメントImageThumbnailHtml.jspを再使用して、カスタム・イメージをサムネイルとして動的にレンダリングする場合に必要です。このエレメントは、特定のアセット・タイプまたはサブタイプ(あるいはその両方)に属するイメージ属性に関連付けられているイメージを処理します。

カスタムThumbnailViewConfig.jsp内のシステム定義のImageThumbnailHtml.jspを再使用するには、次の操作を実行します。

1. カスタム・イメージ・サムネイルが必要なアセット・タイプを指定します。各アセット・タイプにはイメージ属性が必要です。

<assettypes>
<assettype>
<type>Name_of_AssetType_containing_the_image_attribute</type>
<subtype>Name_of_subtype_containing_the_image_attribute</subtype>
<element>UI/Layout/CenterPane/Search/View/ImageThumbnail</element>
<attribute>Name_of_imageAttribute_containing_the_image</attribute>
</assettype>
…
…
</assettypes>

2. <element>の場合、前述のサンプル・コードで示されているように、システム定義のエレメントImageThumbnailHtml.jspへのパスを指定します。

70.3.4.1.3 カスタム・サムネイル・レンダリング・エレメントの使用

ThumbnailViewConfig.jspの<assettypes>セクションのカスタマイズは、アセット・タイプ(またはサブタイプ)のblob属性のコンテンツをサムネイルとして動的にレンダリングするカスタム・エレメントを使用する場合に必要です。

後述の例では、ビデオ・サムネイルのレンダリングで一緒に使用するエレメントを作成します。図70-3に、この項の手順に従って再現できる、サンプル・ビデオ・サムネイル表示を示します。

図70-3 サンプル・ビデオのサムネイル表示

次の手順では、(1)ビデオ・サムネイルを動的にレンダリングするために一緒に使用するエレメントの作成用ガイドライン、(2) ThumbnailViewConfig エレメントの<assettypes>セクションのカスタマイズ用ガイドラインを示します。

注意:

このサンプルを正しく動作させるため、blob属性を持つアセットが存在していること、またそのblob属性のビデオ・ファイルがサイトのディレクトリにアップロードされていることを確認します。

ビデオ・ファイルを再生するには、ブラウザ・プラグインを使用可能にしておく必要があります。

ビデオ・サムネイルをレンダリングするエレメントを作成するには::

1. AssetAPIを使用するビデオ・サムネイルActionエレメントを記述して、そのエレメントで指定されるビデオ属性のBlobUtilを使用して、blobのURLを取得します。(エレメントには任意の名前を付けることができますが、Actionで終わる必要があります。エレメントは、CustomElementsの下のディレクトリに格納される必要があります。)

VideoThumbnailAction.jspという名前のサンプル・エレメントは、このガイドを含むzipファイルで提供されています。

2. ビデオ・サムネイルHtmlエレメントを記述します。このエレメントは前の手順で作成したURLをとり、サムネイルの下にビデオおよび他のアセット詳細をレンダリングします。(エレメントには任意の名前を付けることができますが、Htmlで終わる必要があります。エレメントは、CustomElementsの下のディレクトリに格納される必要があります。)このHtmlエレメントは、Actionエレメントをコールします。

VideoThumbnailHtml.jspという名前のサンプル・エレメントは、このガイドを含むzipファイルで提供されています。

3. ビデオ・サムネイルHtmlエレメントを使用するには、次のように、カスタムThumbnailViewConfig.jspエレメントの<assettype>プロパティを構成します。

<assettype>
<type>Name_of_AssetType_containing_blob_attribute</type>
<subtype>Name_of_asset_subtype</subtype>
<element>CustomElements/path_to_your_element/Element</element>
<attribute>Name_of_attribute_containing_video</attribute>
</assettype>

ThumbnailViewConfig.jspという名前のサンプル・エレメントは、このガイドを含むzipファイルで提供されています。

70.4 ドッキングされたビューのカスタマイズについて

ドッキングされたビューをカスタマイズする方法は、ドッキングされていないビューをカスタマイズする方法と類似しています。主な違いは、「プロセスのカスタマイズ」で概述されています。

70.5 ソート・メニューおよびツールチップのカスタマイズ

この項で説明される機能は、表70-8 に示すように、ドッキングされていないビュー、ドッキングされたビュー、またはその両方に対してカスタマイズできます。

表70-8 検索ビューの他の機能のカスタマイズ

カスタマイズ・オプション

ドッキングされていないリスト

ドッキングされていないサムネイル

ドッキングされたリスト表示

ドッキングされたサムネイル

参照

ソート・メニュー

不可

可

可

可

ソート・メニューのカスタマイズ

検索結果のツールチップ

不可

不可

可

可

検索結果のツールチップのカスタマイズ

コンテキスト・メニュー

可

可

可

可

コンテキスト・メニューのカスタマイズ

この項には次のトピックが含まれます:

- ソート・メニューのカスタマイズ

- 検索結果のツールチップのカスタマイズ

- コンテキスト・メニューのカスタマイズ

70.5.1 ソート・メニューのカスタマイズ

ソート・メニューは、表70-8 にリストされているビューに対してのみカスタマイズできます。ソート・メニューにどのソート・フィールドを表示するかを指定できます。各フィールドのソート順序を指定することもできます。

- ソート・メニューをカスタマイズするには、CustomElementsの下に独自のSearchTopBarConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfigをオーバーライドします。
エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfigが次に表示されます。表70-9では、これらのプロパティについて説明します。

エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfig

<sortconfig>>
<sortfields>
<sortfield id="unique_identifier">
<fieldname>name</fieldname>
<displayname>Name(A-Z)</displayname>
<sortorder>ascending</sortorder>
</sortfield>
<sortfield id="unique_identifier">
<fieldname>name</fieldname>
<displayname>Name(Z-A)</displayname>
<sortorder>descending</sortorder>
</sortfield>
<sortfield id="unique_identifier">
<fieldname>AssetType_Description</fieldname>
<displayname>Asset Type</displayname>
<sortorder>ascending</sortorder>
</sortfield>
…
…
</sortfields>
</sortconfig>

表70-9 UI/Layout/CenterPane/Search/View/SearchTopBarConfigのプロパティ

プロパティ

説明

値

<sortfield id= >

検索結果をソートする検索索引フィールドを記述します。

id=unique_identifier

<fieldname>

検索索引フィールドの名前。

複数のソート順序を提供するために、同じフィールドを複数回繰り返すことができます。

前述のコードのnameなど。

<displayname>

ユーザーが読取り可能なフィールドの表示名。

前述のコードのNameなど。

<sortorder>

ソート順序。

ascending | descending

70.5.2 検索結果のツールチップのカスタマイズ

ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。ドッキングされたビューは、制限されたスペース内に表示されるため、検索結果として返されるアセットに関する情報量が限定されます。ツールチップは、返されたアセットに関する詳細情報を表示する方法です。たとえば、図70-4に示すように、ドッキング・モードで表示されている内容に加え、フィールド名と値を表示するためにツールチップをカスタマイズできます。カスタム・メッセージを表示するためにツールチップをカスタマイズしたり、ツールチップの外観を変更することもできます。

図70-4 ドッキングされていないリスト表示のツールチップ

ドッキングされた検索結果のデフォルトのツールチップは、エレメントUI/Layout/CenterPane/Search/View/SearchToolTipHtmlでレンダリングされます。このエレメントは、(図70-4 に示すように)ツールチップをボックスとしてレンダリングします。ボックス内で、UI/Layout/CenterPane/Search/View/ListViewConfig(またはUI/Layout/CenterPane/Search/View/ThumbnailViewConfig)の<fields>セクションの各フィールドの名前をレンダリングしますが、これはフィールドの<displayintooltip>プロパティがtrueに設定されている場合にのみ実行されます。たとえば、<displayintooltip>がtrueに設定されている場合は、次のListViewConfig.jspのName、TypeおよびModifiedフィールドが、図70-4 のツールチップの一部として表示されます。

<fields>
<field>
<fieldname>name</fieldname>
<displayname>Name</displayname>
<width>350px</width>
<formatter>fw.ui.GridFormatter.nameFormatter</formatter>
<displayintooltip>true</displayintooltip>
</field>
<field>
<fieldname>type</fieldname>
<displayname>Type</displayname>
<width>auto</width>
<formatter></formatter>
<displayintooltip>true</displayintooltip>
</field>
<field>
<fieldname>updateddate</fieldname>
<displayname>Modified</displayname>
<javadateformat>SHORT</javadateformat>
<width>auto</width>
<formatter></formatter>
<displayintooltip>true</displayintooltip>
</field>

注意:

UI/Layout/CenterPane/Search/View/SearchToolTipHtmlエレメントは、フィールド値もレンダリングします。ただし、カスタマイズされたメッセージおよびツールチップ表示への変更は、カスタムSearchToolTipHtml.jspエレメントでコード化される必要があります。

ツールチップを作成したり、ツールチップにフィールドを追加するには::

1. ツールチップを作成するには、CustomElementsの下に独自のSearchToolTipHtml.jspを作成して、エレメントUI/Layout/CenterPane/Search/View/SearchToolTipHtmlをオーバーライドします。

2. ツールチップにフィールドを追加するには、カスタムListViewConfig.jspまたはThumbnailViewConfig.jspにフィールドを追加して、各フィールドの<displayintooltip>プロパティをtrueに設定します。

3. ツールチップ(カスタムまたはシステム定義)にカスタム・メッセージを表示したり、ツールチップ表示を変更するには、カスタムSearchToolTipHtml.jspエレメントをコーディングします。次に例を示します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"
%><cs:ftcs>
<style>
.customSearchTooltip {
font-weight: bold;
color: #333;
font-style: italic;
}
</style>

<div class='customSearchTooltip'>
You are Viewing a Custom Tooltip
</div>
</cs:ftcs>

70.5.3 コンテキスト・メニューのカスタマイズ

コンテキスト・メニューは、すべての検索ビューでカスタマイズ可能です。

コンテキスト・メニューをカスタマイズするには、次のコードで独自のMyConfig.jspを作成して、エレメントUI/Config/GlobalHtmlをオーバーライドします。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<cs:ftcs>
webcenter.sites['${param.namespace}'] = function (config) {
config.contextMenus = {
"default":["bookmark"],
"asset":["edit","preview", "share", "bookmark", "tagasset"],
"asset/Page":["edit", "preview", "delete", "bookmark"],
"proxy":["preview", "bookmark", "tagasset"],
;
}
</cs:ftcs>

71 Contributorインタフェースでのグローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ

グローバル・エレメントでOracle WebCenter Sites: Contributorインタフェースに対して定義した機能をカスタマイズするには、UI/Config/GlobalHtmlグローバル構成エレメントを使用する必要があります。

Contributorインタフェースでグローバル・プロパティ、ツールバーおよびメニュー・バーをカスタマイズする方法は、次の項を参照してください。

- グローバル構成プロパティのカスタマイズ

- ツールバーのカスタマイズ

- メニュー・バーのカスタマイズ

- コンテキスト・メニューのカスタマイズ

71.1 グローバル構成プロパティのカスタマイズ

グローバル構成プロパティは、コンテンツ管理サイト全体にContributorインタフェースの表示条件を設定するために使用します。

この項には次のトピックが含まれます:

- 構成プロパティについて

- 変更可能なデフォルトの構成プロパティ

- カスタム構成プロパティの追加

71.1.1 構成プロパティについて

クライアント側のフレームワークにより、サーバー側のコントローラ・エレメントUI/Config/GlobalHtmlからその主要な構成設定が取得されます。このプレゼンテーション・エレメントは、起動時にクライアント側アプリケーションで実行される、JavaScriptコードを提供します。JavaScriptコードはJavaScript関数を定義し、その名前がクライアント側アプリケーションによってリクエスト・パラメータとして指定されます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<cs:ftcs>
webcenter.sites['${param.namespace}'] = function (config) {
config.maxTabCount = 50;
config.defaultView =  …;
… merge
}
</cs:ftcs>

configオブジェクトには、クライアント側アプリケーションが期待するプロパティを設定することにより、関数本体で自由に操作できます。

また、次に説明するように、クライアント側アプリケーションはサーバー側から追加の構成プロパティを取得できるため、複数の場所にグローバル・プロパティを重複させることなく、複数のソースから設定をマージできます。

71.1.2 変更可能なデフォルトの構成プロパティ

表71-1は、システム定義の構成プロパティについて説明し、どのプロパティが変更可能であるかを示しています。

表71-1 UI/Config/GlobalHtmlの構成プロパティ

プロパティ名

説明

値および例

maxTabCount

同時に開いたままにできるタブの最大数。タブとは、開かれたアセットのタブのことです。

0より大きい整数。

例:

config.maxTabCount = 30;

enableContextMenu

ユーザーがWebモードで作業する場合に、デフォルトのブラウザ・コンテキスト(右クリック)メニューを有効にする必要があるかどうかを示します。

true | false

例:

config.enableContextMenu = true;

enableWebMode

Webモードを有効にする必要があるかどうかを示します。このプロパティをfalseに設定すると、フォーム・モードでのみアセットが操作可能になり、プレビュー機能が使用できます。

デフォルトでは、このプロパティは、wcs_properties.jsonにあるxcelerate.enableinsiteプロパティの値をとります。

true | false

例:

config.enableWebMode = true;

enableDatePreview

日付ベースのプレビューを有効にする必要があるかどうかを示します。

デフォルトでは、このプロパティは、wcs_properties.jsonにあるcs.sitepreviewプロパティの値をとります。

true | false

例:

config.enableDatePreview = false;

enablePreview

プレビューが許可されるかどうかを示します。

デフォルトでは、このプロパティは、「サイトの編集」フォームの「プレビュー方法」属性の値をとります(Adminインタフェースからアクセス可能: 「管理」タブを選択して「サイト」を開き、「SampleSite」をダブルクリックして「編集」を選択します)。

true | false

例:

config.enablePreview = true;

defaultView

アセットを使用するための優先ビューを定義します(アセットがデフォルトでは、フォーム・モードまたはWebモードのどちらで表示されるかなど)。

注意: アセットはデフォルト・テンプレートに関連付けられている場合にのみ、Webモードで開かれます。

予想される値は次のいずれかです。

- "default": "form" | "web"

- "assetType" : "form" | "web"

- "assetType/subtype": "form" | "web"

assetTypeは有効なアセット・タイプ名で、subtypeは有効なサブタイプまたは定義名です。例:

config.defaultView = {
"default": "form",
"AVIArticle": "web",
"Page/AVISection": "web"
}

toolbars

ビューのタイプごとに、使用可能なツールバー・アクションのリストを定義します。

「ツールバーのカスタマイズ」を参照してください。

toolbarButtons

特定のツールバー・ボタンの動作の定義に使用します。

「カスタム・アクションを使用したツールバーのカスタマイズ」を参照してください。

menubar

メニュー・バーで使用可能なアクションのリストを定義します。

「メニュー・バーのカスタマイズ」を参照してください。

documents

ドキュメントの使用可能な実装を登録します。

このプロパティの値は変更しないでください。

サポートされる値はassetのみです。

views

ビューの実装を登録します。

このプロパティの値は変更しないでください。

controllers

コントローラの実装、および各コントローラでサポートされるアクションのセットを登録します。

このプロパティの値は変更しないでください。

roles

現在ログインしているユーザーのロールのリストが含まれます。

このプロパティの値は変更しないでください。

supportedTypes

Contributorインタフェースから編集可能なアセット・タイプのリストが含まれます。

このプロパティの値は変更しないでください。

searchableTypes

Contributorインタフェースから検索可能なアセット・タイプのリストが含まれます。

このプロパティの値は変更しないでください。

token

バイナリ・ファイルをアップロードする際のセキュリティ保護に使用します。

このプロパティの値は変更しないでください。

sessionid

バイナリ・ファイルをアップロードする際のセキュリティ保護に使用します。

このプロパティの値は変更しないでください。

contextMenus

コンテキスト・メニューで使用可能なアクションのリストを定義します。

「コンテキスト・メニューのカスタマイズ」を参照してください。

71.1.3 カスタム構成プロパティの追加

UI/Config/GlobalHtmlに格納されているグローパル・プロパティを取得するほかに、Contributorアプリケーションは、UI/Config/SiteConfigの追加設定およびUI/Configに存在するエレメントを取得しようとします。要件によっては、UI/Config/GlobalHtmlに定義されているすべてのプロパティをレプリケートせずに、グローパル・プロパティまたはサイト固有のプロパティを設定できます。

この項には次のトピックが含まれます:

- カスタム・グローバル・プロパティの追加

- サイト固有のプロパティの追加

71.1.3.1 カスタム・グローバル・プロパティの追加

カスタム・グローバル・プロパティは、指定されたコンテンツ管理システム上のすべてのサイトで共有されます。推奨されるアプローチは、次のように定義されたカスタム構成エレメントを作成することです。

- プレゼンテーション・エレメント名は、UI/Config/SiteConfigHtmlである必要があります。

- エレメント・コードは、「構成プロパティについて」に示すパターンに従う必要があります。

たとえば、次のような操作を一時的に行う場合があります。

- すべてのサイトのmaxTabCountの値をオーバーライドします。

- ページ・アセットのデフォルト・ビューをオーバーライドします。

- また、fooという追加のカスタム・プロパティを定義します。

そのためには、次のコードを含む、CustomElements/UI/Config/SiteConfigHtmlというエレメントを作成します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<cs:ftcs>
webcenter.sites['${param.namespace}'] = function (config) {
// override existing properties
config.maxTabCount = 60;
config.defaultView.Page = "form";

// add custom properties
config.foo = "bar";

}
</cs:ftcs>

71.1.3.2 サイト固有のプロパティの追加

Contributorインタフェースは、コンテンツ管理サイトごとに異なる方法で構成する必要がある場合があります。UI/Config/SiteConfigというコア・コントローラ・エレメントをオーバーライドすることをお薦めします。

UI/Config/SiteConfigコア・エレメントをオーバーライドするには、次のようにエレメントを作成します。

CustomElements/siteName/UI/Config/SiteConfigHtml

ここで、siteNameは、コンテンツ管理サイトの名前です(avisportsなど)。

たとえば、avisportsデモ・サイトでは、PageおよびAVIArticleアセット・タイプに対してデフォルト・モードとしてWebモードが実行されます。これは、JSPエレメントCustomElements/avisports/UI/Config/SiteConfigHtmlを定義し、次の設定を提供することによって実行されます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<cs:ftcs>
webcenter.sites['${param.namespace}'] = function (config) {
// default view modes for avisports
config.defaultView.Page = "web";
config.defaultView.AVIArticle = "web";
}
</cs:ftcs>

構成エレメントのロード

グローバル構成エレメントは常に最初にロードされます。追加の構成エレメントは、アルファベット順にロードされます。たとえば、前述の例を使用すると、構成プロパティは次の順序でロードされます。

1. UI/Config/GlobalHtml

2. UI/Config/SiteConfigHtml

プロパティ値

ある場合、一部のプロパティの値はオブジェクトになります。つまり、次のようになります。

config.someProperty = {
foo: "bar",
x: 123
};

このプロパティを部分的にオーバーライドする場合、次の2つのタイプのコードの違いを見極める必要があります。

config.someProperty = {
x: 3456
};

と

config.someProperty.x = 3456;

最初のコードでは、プロパティfooが未定義としてオーバーライドされますが、2番目のコードでは、fooの元の値が保持されます。

71.2 ツールバーのカスタマイズ

ツールバーは、Webモードまたはフォーム・モードのアセット上で動作するアクションをリストするようにカスタマイズできます。ツールバーは、アセット・タイプおよびサブタイプごとに詳細にカスタマイズできます。

この項には次のトピックが含まれます:

- ツールバーのカスタマイズについて

- ツールバー・カスタマイズの例

71.2.1 ツールバーのカスタマイズについて

グローバル構成エレメント(UI/Config/GlobalHtml)は、各ビュー・タイプ(Webモード調査、Webモード編集、フォーム・モード編集、フォーム・モード調査など)について、ツールバーで表示されるアクションのリストを示します。これは、toolbarsプロパティで行えます。その値は、次の構文を持つオブジェクトです。

config.toolbars = {
"viewAlias": [action_1, action_2,  …],
or:
"viewAlias": {
"view_mode_1": [action_1, action_2,  …],
"view_mode_2": [action_1, action_2,  …]
}
…
}

ここで:

viewAliasは、このツールバーをどのビュー・タイプで使用する必要があるかを示します。別名は、config.viewsセクションで定義されるビューの別名のいずれかに一致する必要があります。

action_iはアクション名です。save、approveなどの標準アクションの場合、アクション名は、指定されたアイコン、タイトル、代替テキストなどに自動的にマッピングされます。標準アクション、カスタム・アクション、またはカスタム・ボタンの外観のカスタマイズ方法の詳細は、「ツールバー・カスタマイズの例」を参照してください。

view_mode_iは、ビューによってサポートされているモードのいずれかです(通常はeditまたはview)。

71.2.2 ツールバー・カスタマイズの例

この項には次のトピックが含まれます:

- Webモード用の標準アクションを使用したツールバーのカスタマイズ

- アセット・タイプおよびサブタイプ用の標準アクションを使用したツールバーのカスタマイズ

- カスタム・アクションを使用したツールバーのカスタマイズ

71.2.2.1 Webモード用の標準アクションを使用したツールバーのカスタマイズ

- 次の構成を使用して、すべてのアセット・タイプに対してWebモードで使用可能なツールバー・アクションが決定します。

config.toolbars = {
( …)

"web": {
"edit": ["form-mode", "inspect", "separator", "save", "preview",
"approve", "delete", "separator", "changelayout",
"separator", "checkincheckout", "refresh"],
"view": ["form-mode", "edit", "separator", "preview", "approve",
"delete", "separator", "checkincheckout", "refresh"]

( …)

}

前述の構成により、アセットのビュー(「編集」および「調査」)に対応する2つのアクションのリスト(editおよびview)が定義されます。

注意:

標準アクションのセットを検索するには、controllersプロパティの下にある次のプロパティで指定されているアクションのリストを参照してください。

- fw.ui.document.AssetDocument(アセットによってサポートされているすべてのアクション)

- fw.ui.controller.InsiteController (ビュー・コントローラによってサポートされているすべてのアクション)。

71.2.2.2 アセット・タイプおよびサブタイプ用の標準アクションを使用したツールバーのカスタマイズ

各ツールバー構成は、次の名前のプロパティを追加することによって、アセット・タイプおよびサブタイプ別にカスタマイズできます。

- viewAlias/assetType

- viewAlias/assetType/assetSubtype

たとえば、Webモードでページ・アセットの「ブックマーク」/「ブックマーク解除」ボタンを追加します。

- カスタム構成エレメント(CustomElements/avisports/UI/Config/SiteConfigHtmlなど)で、次のプロパティを追加します。

config.toolbars["web/Page/AVISection"] = {
"edit": config.toolbars.web.edit, // reuse default for edit mode
"view": ["form-mode", "edit", "separator", "preview", "approve", "delete",
"bookmark", "unbookmark", "separator",
"checkincheckout",  "refresh"]
}

Surfingページ・アセットを調査すると、図71-1に示すツールバーが表示されます。

図71-1 Surfingページ・アセット・ツールバー

注意:

次のことに注意してください。

- viewモードのみをカスタマイズします。Page/AVISectionアセットがWebモードで編集されている場合、標準ツールバーが表示されます。

- 「ブックマーク」および「ブックマーク解除」ボタンは、両方ともアセットの現在の状態(すでにブックマークを付けているかどうか)に依存しているため、同時には表示されません。

71.2.2.3 カスタム・アクションを使用したツールバーのカスタマイズ

- カスタム・アクションを定義するには、次のように、config.toolbarButtonsプロパティに新しいエントリを追加します。

config.toolbarButtons.<customActionName> = {
src: <path_to_icon>,
onClick: <click_handler>
}

- たとえば、次のhelloWorldカスタム・アクションを定義します。

config.toolbarButtons.helloWorld = {
src: 'js/fw/images/ui/ui/toolbarButton/smartlist.png',
onClick: function () {
alert('Hello World!!');
}
}

helloWorldアクションは、次のように、ツールバー構成から参照できます(前の項の例を再使用します)。

config.toolbars["web/Page/AVISection"] = {
"view":
["form-mode", "edit", "separator", "preview", "approve",
"bookmark", "unbookmark", "separator",
"checkincheckout", "separator", "helloWorld", "refresh"],

"edit": config.toolbars.web.edit // reuse default web mode toolbar
}

注意:

この例では、図71-2に示すように、セパレータ(垂直線)とカスタム・ボタンをツールバーの末尾に追加しています。

図71-2 セパレータおよびツールバー・ボタン

より複雑な例として、アセットのidおよびタイプを出力するCSElementを作成し、クリックしたときにエレメントをコールするツールバー・オプションを作成する操作があります。例:

1. アセットのidおよびタイプを出力するCSElement (この例ではHelloAsset)を作成します。CSElementの作成の詳細は、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

2. ここで、次のように、新しいエントリをconfig.toolbarButtonsプロパティ(SitesConfigHTML.jsp内)に追加して、helloAssetカスタム・アクションを定義します。

config.toolbarButtons.helloAsset = {
src: 'js/fw/images/ui/ui/toolbarButton/smartlist.png',
onClick: function () {
/* current active document which holds the asset*/
var doc = SitesApp.getActiveDocument();
var asset = doc.get('asset');
var id = asset.get("id");
var type = asset.get("type");
/* make an ajax call to call an element */
dojo.xhrGet({
url: "url of element to call", /*url of the element*/
/*pass any parameters that need to be passed to the element */
content:{"id":id,"type":type}
/*handleAs:"json" */ /* this is needed only if the element returns json response */
}).then(function(response) {
console.log("Response:", response);
/*handle response from the element here */
alert(response);
},
function(err){
/*handle error*/
console.log("error on ajax call");
});
}
};

3. カスタム・ボタン(手順2で定義)をconfig.toolbars ={ }のツールバーに追加します。例:

/*add the custom button in web mode for AVIArticle*/
config.toolbars["web/AVIArticle"] = {
"view" : ["form-mode", "edit", "separator", "preview", "approve", "delete",
"bookmark", "unbookmark", "separator", "checkincheckout", "helloAsset",
"separator", "refresh",]
};

図71-3に、ツールバーのカスタム・オプションを示します。

図71-3 カスタムhelloAssetツールバー・ボタン

カスタムhelloAssetボタンをクリックすると、図71-4に示すように、CSElement (手順1で作成)がコールされ、ダイアログ・ボックスが開き、アセット名、idおよびタイプが表示されます。

図71-4 アセット名、IDおよびタイプを示すダイアログ・ボックス

71.3 メニュー・バーのカスタマイズ

メニュー・バーは、特定のタイプまたはタイプ/サブタイプのアセット上で動作するメニューをサポートするようにカスタマイズできます。サブメニューには、アクション可能なアイテム、追加メニューまたはメニュー・セパレータを指定できます。

この項には次のトピックが含まれます:

- メニュー・バーのカスタマイズについて

- カスタム・アクションのメニュー・バーへの追加

71.3.1 メニュー・バーのカスタマイズについて

メニュー・バーの構成は、config.menubarプロパティによって定義されます。

config.menubar = {
"key_i": [
//menu_i
{
"id": "menu_id",
"label": "menu_label",
"children": [
//submenus
//- actionable menu item
{
label: 'menu_item_label',
action: 'action_name' | click_handler
},
//- deferred pop-up menu
{
label: 'menu_item_label',
deferred: 'controller_element',
cache: true|false
},
//- pop-up menu
{
label: 'menu_item_label',
children: [
// submenu_1
{
label: 'menu_item_label',
action: 'action_name' | click_handler
}'
// submenu_2
{
label: 'menu_item_label',
action: 'action_name' | click_handler
},
…
…
…
]
},
//- menu item separator
{separator: true}

//additional menu_i
…
…
…
]
}

ここで:

key_iは次のいずれかです。

- default: デフォルトのメニュー・バーを定義します。

- assetType: タイプassetTypeのすべてのアセットに対するカスタマイズされたメニュー・バーを定義します。

- assetType/subtype: タイプassetTypeおよびサブタイプsubtypeのすべてのアセットに対するカスタマイズされたメニュー・バーを定義します。

//menu_iは、各トップ・メニューを示すセクションを開始します。

- menu_idは、メニューの識別子です。

- menu_labelは、メニューの表示名です。

- submenusは、次のいずれかとなります。

- アクション可能なメニュー・アイテム(メニュー・アイテムをクリックすると、アクションが生成される)。

- labelは、メニュー・アイテムの表示名を指定します。

- actionには、editおよびinspectなどの、コントローラによってサポートされるアクションまたはカスタム・クリック・ハンドラを指定できます(「カスタム・アクションのメニュー・バーへの追加」のカスタマイズ例を参照)。

注意:

指定されたアクションが現在のドキュメント/ビューでサポートされていない場合、メニューでは無効になります(グレー表示されます)。

たとえば、saveアクションをトリガーするメニュー・アイテムは、次のように定義されます。

{
label: "Save",
action: "save"
}

- 遅延ポップアップ・メニュー(ポップアップ・メニューは、サーバー側でコントローラ・エレメントを実行することによって動的に決定される)。

- labelは、メニュー・アイテムの表示名を指定します。

- deferredは、UI/Data/StartMenu/Newなど、コントローラのエレメント名を指定します。

- cacheは、コントローラ・エレメントの出力がキャッシュされる必要があるかどうかを示すブール値です。

たとえば、現在のサイト/ユーザーのすべての使用可能なスタート・メニュー・アイテムを読み取る「新規」ポップアップ・メニューは、次のように定義されます。

{
label: New,
deferred: "UI/Data/StartMenu/New",
cache: true
}

- ポップアップ・メニュー(子メニュー・アイテムが構成自体にハード・ワイヤリングされる)。

- メニュー・アイテム・セパレータ(横線、メニュー・エントリをグループ化するために使用する)。

71.3.2 カスタム・アクションのメニュー・バーへの追加

この例では、(カスタムonClickハンドラを実行するため)「カスタム・アクションを使用したツールバーのカスタマイズ」で定義したhelloWorldカスタム・アクションをメニュー・バーに追加します。このアクションを追加するには、カスタム・アクションをトリガーする、Hello Worldという単一メニュー・アイテムを使用して、カスタム・メニューというメニュー・バーに新しいエントリを追加します。この手順は次のとおりです。

1. 最初に、デフォルトのメニュー・バーを再利用して、それに追加します。これを行う最も簡単な方法は、元の配列のコピーを作成することです。

config.menubar["Page/AVISection"] = config.menubar["default"].slice(0);

2. 次のように、メニューを追加します。

config.menubar["Page/AVISection"].push(
"id": "myCustomMenu",
"label": "Custom Menu",
"children": [
// Children go here
]
);

3. 子メニュー・アイテムを定義します。

config.menubar["Page/AVISection"].push({
"id": "myCustomMenu",
"label": "Custom Menu",
"children": [{
"label": "Hello World",
"action": function () {
alert("Hello from the top menubar!");
}
}]
});

カスタム・メニューが、AVISectionページ・セクションと一緒に表示されるようになります(図71-5)。

図71-5 カスタム・メニュー

Hello Worldメニュー・アイテムを選択すると、図71-6に示すようなカスタムonClickハンドラが実行されるはずです。

図71-6 カスタムonClickハンドラ

4. メニュー・バーとツールバーのどちらからクリックする場合でも、まったく同じコードを実行するには、次のようにコーディングします。

// define the helloWorld code once
config.myActions = {
hello: function (args) {
var doc = SitesApp.getActiveDocument(),
asset = doc.get('asset'),
view = SitesApp.getActiveView();

view.info('Hello World!! The asset is a ' + asset.type +     ' with id:
+ asset.id);
}
};

// attach it to the helloWorld button
config.toolbarButtons['helloworld'] = {
src: 'js/fw/images/ui/ui/toolbarButton/smartlist.png',
onClick: config.myActions.hello
};

config.toolbars["web/Page/AVISection"] = {
"edit": config.toolbars.web.edit, // reuse default for edit mode
"view": [  "form-mode", "edit", "separator", "preview", "approve",
"delete", "bookmark", "unbookmark", "separator",
"checkincheckout","separator","helloworld", "refresh"]
}

// attach it to the menubar, under "Custom Menu">"Hello World"
config.menubar['Page/AVISection'] = config.menubar['default'].slice(0);

config.menubar["Page/AVISection"].push({
"id": "myCustomMenu",
"label": "Custom Menu",
"children": [{
"label": "Hello World",
"action": config.myActions.hello
}]
});

71.4 コンテキスト・メニューのカスタマイズ

コンテキスト・メニューは右クリックで開き、右クリックされたオブジェクトを操作できるメニューが表示されます。コンテキスト・メニューで使用可能な特定のアイテムおよびオブジェクトが表示される順序は、カスタマイズできます。

コンテキスト・メニューを定義するには、config.contextMenusプロパティを使用します。

config.contextMenus = {
"default": ["action_1", "action_2", … "action_n"]
"asset": ["action_1", "action_2", … "action_n"],
"asset/assetType": ["action_1", "action_2", … "action_n"],
}

値は、次のように定義されます。

- default: コンテキスト・メニューのデフォルトのリストを定義します。リストに表示される各メニュー・アイテムは、actionです。

- asset: すべてのアセットのコンテキスト・メニューのカスタマイズされたリストを定義します。リストに表示される各メニュー・アイテムは、actionです。

- asset/assetType: タイプassetTypeのアセットのコンテキスト・メニュー・アイテムのカスタマイズされたリストを定義します。リストに表示される各メニュー・アイテムは、actionです。

アセット・タイプPageのコンテキスト・メニュー構成の例は次のとおりです。

"asset/Page":["edit", "copy", "preview", "delete", "bookmark", "tagasset"]

72 Contributorインタフェースのアセット・フォームのカスタマイズ

Oracle WebCenter Sites: Contributorインタフェースのアセット・フォームをカスタマイズする場合、アセット・フォーム・ヘッダーの変更が可能で、サポートされている一部のデータ型の単一値属性エディタおよび複数値属性エディタの構築も可能です。

Contributorインタフェースのアセット・フォームのカスタマイズの詳細は、次の項を参照してください。

- アセット・フォームのカスタマイズについて

- アセット・フォームのヘッダーの変更

- 属性エディタの構築

72.1 アセット・フォームのカスタマイズについて

Contributorインタフェースのアセット・フォームでは、2つのタイプのカスタマイズがあります。

- アセット・フォームのヘッダーを変更する。

- 既存の属性エディタをカスタマイズする(「属性エディタのカスタマイズ」で説明)、またはWebCenter Sitesによってサポートされているデータ型のカスタム属性エディタを構築する(「属性エディタの構築」で説明)。

注意:

Contributorインタフェースの他のコンポーネントとは異なり、アセット・フォームは、Contributorフレームワークにはありません。そのため、アセット・フォームのリクエストは、UIコントローラによって処理されません。

72.2 アセット・フォームのヘッダーの変更

アセット・フォームのヘッダーを変更するには、OpenMarket/Xcelerate/AssetType/<AssetTypeName>/ディレクトリのカスタムassettype固有のエレメントを作成します。

HTMLページの本文を変更するのではなく、追加のスタイルシートまたはJavaScriptコードを含めることができます。エレメントの名前はHeaderにする必要があります。

72.3 属性エディタの構築

「属性エディタのカスタマイズ」の説明に従って、使用準備済の既存の属性エディタの一部のルック・アンド・フィールをカスタマイズできます。WebCenter Sitesでサポートされているデータ型のカスタム属性エディタを作成することもできます。

この項では、データ型text、string、integerまたはmoneyの単一値をサポートするカスタム属性エディタを構築する方法について説明します。また、この項では、同じデータ型の複数値属性エディタを実装するためのポインタおよびサンプル・コードも提供します。

注意:

blobまたはassetデータ型のカスタム属性エディタを作成するには、blob型はUPLOADER属性エディタを、assetデータ型はPICKASSET属性エディタを実装の基準にします。

属性エディタを構築する手順は次のとおりです。

- Dojoウィジェットとそのテンプレートの作成

- プレゼンテーション・オブジェクトとしての属性エディタの定義

- 属性エディタ・エレメントの作成

- 属性エディタの作成

- 複数値属性エディタの実装

72.3.1 Dojoウィジェットとそのテンプレートの作成

この項では、データ型text、string、integerまたはmoneyの単一値を処理するDojoウィジェットを作成する方法について説明します。

この項には次のトピックが含まれます:

- Dojoウィジェットのテンプレートの作成

- Dojoウィジェットの作成

72.3.1.1 Dojoウィジェットのテンプレートの作成

DojoウィジェットのHTMLテンプレートを作成するには:

1. WebCenter Sitesインストール・ディレクトリで、<context_root>/js/ディレクトリに移動します。

2. jsディレクトリの下に、新しいディレクトリ構造extensions/dijit/templatesを作成します。

3. <context_root>/js/extensions/dijit/templatesディレクトリで、HTMLテンプレート・ファイルを作成し、それにわかりやすい名前を付けます(例: MyWidget.html)。

4. HTMLテンプレート・ファイルで、新しいDojoウィジェットのルック・アンド・フィールを定義します。このHTMLテンプレートの内容は次のようになります。

<div>
<div>
<input type="text" dojoAttachPoint='inputNode'
name='${name}'size='60' class='valueInputNode'>
</input>
</div>
</div>

このコードをテンプレートで使用する場合、エンド・ユーザーからの入力を入力ノードが受け取った後、その入力ノードの値は、「Dojoウィジェットの作成」で作成するDojoウィジェットで保持されます。

5. テンプレート・ファイルを保存します。

72.3.1.2 Dojoウィジェットの作成

Dojoウィジェットを作成するには:

1. WebCenter Sitesインストールのjs/extensions/dijitディレクトリに移動します。

2. 次の必須機能を実装することにより、dojoウィジェット、たとえば、MyWidget.jsを作成します(次の例を参照)。

- _setValueAttr: このsetterメソッドは、属性の値を設定します。

- _getValueAttr: このgetterメソッドは、属性値を取得します。

- isValid: このメソッドは、指定された値が有効かどうかを確認するために検証を実行します。

- focus: これは、属性エディタにフォーカスを設定します。

- onChange: このメソッドは、ユーザーが属性の値を更新するたびにコールされます。

- onBlur: このメソッドは、属性値がユーザーによって入力されるときに、ウィジェットを更新します。ユーザーが別のフィールドを選択すると、更新がトリガーされます。

dojo.provide('extensions.dijit.MyWidget');
dojo.require('dijit._Widget');
dojo.require('dijit._Templated');
dojo.declare('extensions.dijit.MyWidget', [dijit._Widget, dijit._Templated], {
//string.
//The value of the attribute.
value: '',
//int
//The Attribute editor's MAXALLOWEDCHARS should be assigned to this variable.
//maxAllowedLength: 15,
//string
//   This variable is required only for single valued instance.
//   The server should recieve information from input element with this name.
name: '',
//HTMLElement
//   This stores the cached template of the widget's representation.
templateString: dojo.cache('extensions.dijit', 'templates/MyWidget.html'),
//string
//   This class will be applied to the top div of widget.
//   It will help in managing css well.
baseClass: 'MyWidget',
postCreate: function() {
var self = this;
// Do not allow typing characters more than allowed length.
dojo.connect(this.inputNode, 'onkeypress', function(e) {
if (this.value.length >= self.maxAllowedLength && e.keyCode !=
dojo.keys.BACKSPACE)
e.preventDefault();
});
},
// Start -  Mandatory functions
_setValueAttr: function(value) {
//  summary:
//     Set the value to 'value' attribute and input node
if (value === undefined || !this._isValid(value)) return;
this.value = value;
this._setInputNode(value);
},
_getValueAttr: function() {
// summary:
//Get the latest value and return it.
return this.value;
},
_isValid: function(newVal) {
//summary:
//Verify if the given value is as per the expectation or not.
if (newVal.length > this.maxAllowedLength) {
return false;
}
return true;
},
focus: function() {
//summary:
//Set the focus to the representation node, that is, input node here.
if (typeof this.inputNode.focus === 'function')
this.inputNode.focus();
},
onBlur: function() {
//summary:
//Custom selected browser event when the value should be updated
//Any activity which leads to value change should update
//the widget value as well.
this.updateValue();
},
_onChange: function(newValue) {
//summary:
//Internal onChange method
this.onChange(newValue);
},
onChange: function(newValue) {
//summary:
//A public hook for onChange.
},
// End -  Mandatory functions
// Extra functions used in Mandatory functions
_setInputNode: function(value) {
//summary:
//Sets the value to input node.
this.inputNode.value = value;
},
updateValue: function() {
//summary:
//Validate the newly entered value and if it is successful
//then update widget's value.
var newVal = this.inputNode.value;
if (!this._isValid(newVal)) return;
if (this.value != newVal)
this._onChange(newVal);
this.set('value', newVal);
}
});

注意:

Dojoウィジェットの作成の詳細は、次を参照してください。

http://dojotoolkit.org/

3. js/extensions/themes/ディレクトリで、このウィジェット用のCSS(たとえば、MyWidget.css)を作成します。CSSファイルの次のコードを使用するか、または独自のコードを記述します。

.fw .MyWidget .valueInputNode {
color: blue;
}

4. js/extensions/themes/ディレクトリで、DojoウィジェットのCSS用のimport文を使用してUI.cssを更新します。例: @import url("MyWidget.css");。

5. 作業を保存します。

72.3.2 プレゼンテーション・オブジェクトとしての属性エディタの定義

この項では、フレックス属性の入力タグ(プレゼンテーション・オブジェクト)を定義する方法について説明します。また、入力タグが属性エディタから表示エレメントへ渡すことができる引数を割り当てる方法を説明します。

属性エディタを定義するには:

1. WebCenter Sitesインストールで、Sites\11gR1\Sites\11.1.1.6.1\presentationobject.dtdファイルに移動します。

2. presentationobject.dtdファイルで、次を実行します。

- 新しいタグ(プレゼンテーション・オブジェクト)を<!ELEMENT PRESENTATIONOBJECT …>文内のリストに追加します。この例では、新しいタグにはMYATTREDITORという名前が付けられます。
次の行では、MYATTREDITORは、その名前が「属性エディタ・エレメントの作成」で作成するエレメントの名前に一致するカスタム属性エディタです。他のすべてのタグは使用準備済の属性エディタです。

<!ELEMENT PRESENTATIONOBJECT (TEXTFIELD | TEXTAREA | PULLDOWN | RADIOBUTTONS | CHECKBOXES | PICKFROMTREE | EWEBEDITPRO | REMEMBER |
PICKASSET | FIELDCOPIER | DATEPICKER | IMAGEPICKER | REALOBJECT |
CKEDITOR | DATEPICKER | IMAGEPICKER | REALOBJECT | CKEDITOR | FCKEDITOR | UPLOAD | MAGEEDITOR | RENDERFLASH | PICKORDERASSET | TYPEAHEAD | UPLOADER |
MYATTREDITOR)>

- 新しいタグ(プレゼンテーション・オブジェクト)とそれが取得する引数を定義する<!ELEMENT...… >セクションを追加します。この新しいタグには、フォームに表示されるときの対象属性の形式と動作のベースとなるロジックを提供するエレメントが含まれます。MAXALLOWEDCHARSが必須属性としてマークされていることを確認します。

<!ELEMENT MYATTREDITOR ANY>
<!ATTLIST MYATTREDITOR MAXALLOWEDCHARS CDATA #REQUIRED>
<!ATTLIST MYATTREDITOR MAXVALUES CDATA #IMPLIED>

- presentationobject.dtdファイルを保存して閉じます。

72.3.3 属性エディタ・エレメントの作成

この項では、「新規」または「編集」フォームに表示されるときに、属性(単一値)の「編集」ビューを表示するエレメントの作成方法について説明します。このエレメントは、ElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリに配置される必要があります。エレメント名は、タグで起動できるように、「プレゼンテーション・オブジェクトとしての属性エディタの定義」で定義したタグの名前と正確に一致している必要があります(この例では、MYATTREDITOR)。

1. ElementCatalogのOpenMarket/Gator/AttributeTypesディレクトリに移動します。

2. 新しいエディタの属性エレメントを作成します(この例では、MYATTREDITOR.jsp。)このエレメントの名前がpresentationobject.dtdファイル(「プレゼンテーション・オブジェクトとしての属性エディタの定義」)で定義したタグ名に一致していることを確認します。

3. 属性エディタがデフォルトでレンダリングされないようにするには、doDefaultDisplay変数をnoに設定します。

4. 属性名を表示するには、エレメントOpenMarket/Gator/FlexibleAssets/Common/DisplayAttributeNameをコールします。コードは次のとおりです。

<ics:callelement
element="OpenMarket/Gator/FlexibleAssets/Common/DisplayAttributeName"/>

5. ウィジェットをレンダリングするには、次のパラメータを使用して、エレメントOpenMarket/Gator/AttributeTypes/CustomTextAttributeEditorをコールします。

- editorName: 「Dojoウィジェットの作成」で作成したウィジェットの名前。この例では、extensions.dijit.MyWidgetです。

- editorParams: この引数は、パラメータのJSON文字列をウィジェットに渡します。この例では、maxAllowedLength値を渡しています。たとえば、値は次のようになります。{ maxAllowedLength: "10" }

- maximumValues: 複数値ウィジェットでのみ必要です。これは、複数値ウィジェットでレンダリング可能な値の最大数です。
単一値ウィジェットの場合、初期化パラメータおよびフォーマット・スタイルを使用した完全なコードは、次のコード例のコードのようになります。複数値ウィジェットの実装の詳細は、「複数値属性エディタの実装」を参照してください。

次の例で指定されるコードを使用する場合、単一値属性エディタは図72-1のエディタのようになります。

図72-1 単一値属性エディタ

注意:

次の例では、新規属性エディタを使用して単一値属性をレンダリングするために、次のコア・ロジックが実装されます。

<ics:if condition='<%= "no".equals(ics.GetVar("MultiValueEntry")) %>'>
<ics:then>
<div dojoType='<%= ics.GetVar("editorName") %>'
name='<%= ics.GetVar("cs_SingleInputName") %>'
value='<%= attributeValue %>'
>
</div>
</ics:then>

Dojoテンプレートの入力ノードが同じ名前になるように、エレメントでコード化される名前はics.GetVar("cs_SingleInputName")にする必要があります。この入力ノード値は、属性を保存するためにサーバーに送信されます。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%@ taglib prefix="satellite" uri="futuretense_cs/satellite.tld" %>
<%//
// OpenMarket/Gator/AttributeTypes/MYATTREDITOR
//
// INPUT
//
// OUTPUT
//%>
<%@ page import="COM.FutureTense.Interfaces.FTValList" %>
<%@ page import="COM.FutureTense.Interfaces.ICS" %>
<%@ page import="COM.FutureTense.Interfaces.IList" %>
<%@ page import="COM.FutureTense.Interfaces.Utilities" %>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<cs:ftcs>
<ics:setvar name="doDefaultDisplay" value="no" />
<script>
dojo.require('extensions.dijit.MyWidget');
</script>
<link href="<%=ics.GetVar("cs_imagedir")%>/../js/extensions/themes/MyWidget.css"
rel="stylesheet" type="text/css"/>
<%
FTValList args = new FTValList();
args.setValString("NAME", ics.GetVar("PresInst"));
args.setValString("ATTRIBUTE", "MAXALLOWEDCHARS");
args.setValString("VARNAME", "MAXALLOWEDCHARS");
ics.runTag("presentation.getprimaryattributevalue", args);
args.setValString("NAME", ics.GetVar("PresInst"));
args.setValString("ATTRIBUTE", "MAXVALUES");
args.setValString("VARNAME", "MAXVALUES");
ics.runTag("presentation.getprimaryattributevalue", args);
String maximumValues = ics.GetVar("MAXVALUES");
maximumValues = null == maximumValues ? "-1" : maximumValues;
String editorParams = "{ maxAllowedLength: "
+ ics.GetVar("MAXALLOWEDCHARS") + " }";
%>
<tr>
<ics:callelement
element="OpenMarket/Gator/FlexibleAssets/Common/DisplayAttributeName"/>
<td></td>
<td>
<ics:callelement
element="OpenMarket/Gator/AttributeTypes/CustomTextAttributeEditor">
<ics:argument name="editorName" value="extensions.dijit.MyWidget" />
<ics:argument name="editorParams" value='<%= editorParams %>' />
<ics:argument name="maximumValues" value="<%= maximumValues %>" />
</ics:callelement>
</td>
</tr>
</cs:ftcs>

72.3.4 属性エディタの作成

この項では、属性エディタ・アセットを作成して、コンテンツ・コントリビュータがコンテンツ管理サイトで使用できるようにする方法について説明します。このアセットは、「属性エディタ・エレメントの作成」で定義した入力タイプ、たとえば、チェック・ボックス、ラジオ・オプションおよびドロップダウン・リストをサポートします。開発者は、属性を作成または変更する際にこのエディタを選択します。

1. サイトのAdminインタフェースを開きます。

2. 「名前」列の「新規」ページで、「新規属性エディタ」をクリックします。

3. 「名前」に、エディタのわかりやすい名前を入力します。たとえば、MyAttrEditorです。

4. 「XML」で、属性エディタのXMLコードを入力します。このコードの属性エディタの名前が、エレメント名とまったく同じであることを確認します。例:

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT >
<PRESENTATIONOBJECT NAME="MYATTREDITOR">
<MYATTREDITOR MAXALLOWEDCHARS="10"> </MYATTREDITOR> </PRESENTATIONOBJECT>

5. 「属性タイプ」で、適切な値を受け入れます。

6. 「保存」アイコンをクリックします。

図72-2のエディタに類似した属性エディタが作成されます。

図72-2 サイトのサンプル属性エディタ

72.3.5 複数値属性エディタの実装

「属性エディタ・エレメントの作成」の2番目の例には、単一値属性エディタの実装が示されています。

- text、integer、stringまたはmoneyデータ型の複数値属性エディタを実装するには、次の例のコードに類似したコードを記述します。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld" %>
<%@ taglib prefix="ics" uri="futuretense_cs/ics.tld" %>
<%@ taglib prefix="satellite" uri="futuretense_cs/satellite.tld" %>
<%//
// OpenMarket/Gator/AttributeTypes/CustomTextAttributeEditor
//
// INPUT
//
// OUTPUT
//%>
<%@ page import="COM.FutureTense.Interfaces.FTValList" %>
<%@ page import="COM.FutureTense.Interfaces.ICS" %>
<%@ page import="COM.FutureTense.Interfaces.IList" %>
<%@ page import="COM.FutureTense.Interfaces.Utilities" %>
<%@ page import="COM.FutureTense.Util.ftErrors" %>
<%@ page import="COM.FutureTense.Util.ftMessage"%>
<cs:ftcs>
<%
IList attributeValueList = ics.GetList("AttrValueList", false);
boolean hasValues = null != attributeValueList && attributeValueList.hasData();
String attributeValue = hasValues ? attributeValueList.getValue("value") : "";
%>
<ics:if condition='<%= "no".equals(ics.GetVar("MultiValueEntry")) %>'>
<ics:then>
<div dojoType='<%= ics.GetVar("editorName") %>'
name='<%= ics.GetVar("cs_SingleInputName") %>'
value='<%= attributeValue %>'
>
</div>
</ics:then>
<ics:else>
<ics:callelement
element="OpenMarket/Gator/AttributeTypes/RenderMultiValuedTextEditor">
<ics:argument name="editorName"
value='<%= ics.GetVar("editorName") %>' />
<ics:argument name="editorParams"
value='<%= ics.GetVar("editorParams") %>' />
<ics:argument name="multiple"
value="true" />
<ics:argument name="maximumValues"
value='<%= ics.GetVar("maximumValues") %>' />
</ics:callelement>
</ics:else>
</ics:if>
</cs:ftcs>

前述の例のコードを使用すると、複数値属性エディタは、図72-3のエディタのようになります。

図72-3 複数値属性エディタ

コードの例に関する次の点に注意してください。

- 単一値ウィジェットを使用して複数値表現をレンダリングする、複数値ウィジェットをインスタンス化できます。

- no値を指定したMultiValueEntry変数は、属性エディタが単一値をレンダリングすることを示します。この変数値をyesに変更すると、属性エディタが複数値をレンダリングできるようになります。

- JSONオブジェクトまたは他の任意の形式の値を受け入れる複数値ウィジェットを実装できます。

- 複数値属性エディタの場合、RenderMultiValuedTextEditorエレメントは、Saveロジックに必要な非表示入力ノードを作成します。各ノードの値はサーバーに送信されます。

- 複数値ウィジェットは、前述の例の次のコードを使用して、OpenMarket/Gator/AttributeTypes/RenderMultiValuedTextEditorエレメントをコールしてレンダリングされます。

<ics:else>
<ics:callelement
element="OpenMarket/Gator/AttributeTypes/RenderMultiValuedTextEditor">
<ics:argument name="editorName"
value='<%= ics.GetVar("editorName") %>' />
<ics:argument name="editorParams"
value='<%= ics.GetVar("editorParams") %>' />
<ics:argument name="multiple"
value="true" />
<ics:argument name="maximumValues"
value='<%= ics.GetVar("maximumValues") %>' />
</ics:callelement>
</ics:else>
</ics:if>

- blobまたはassetデータ型のカスタム属性エディタを作成するには、blob型はUPLOADER属性エディタを、assetデータ型はPICKASSET属性エディタを実装の基準にします。

73 ワークフローのカスタマイズ

WebCenter Sitesのワークフロー・プロセスは、アセットがパブリッシュの過程で通過する一連の状態です。アセットはワークフロー・ステップを進み、ある状態から次の状態へ移行します。ワークフロー・ステップの条件エレメントを作成し、アセットが次の状態へ移行するために満たす必要のある条件を指定する必要があります。また、アセットがある状態から次の状態へ移行するときに、様々なアクションを行う、ワークフロー・アクションのエレメントを作成する必要があります。

ワークフローのカスタマイズの詳細は、次の項を参照してください。

- ワークフロー・ステップ条件

- ワークフロー・アクション

73.1 ワークフロー・ステップ条件

ワークフロー・プロセスは、1つ以上のワークフロー状態で構成されます。ワークフロー・ステップにより、アセットはあるワークフロー状態から次の状態へ移行します。アセットの各ワークフロー・ステップは、アセットが割り当てられるときに、電子メールをユーザーに送信するなど、時間指定アクションに関連付けたり、ワークフロー・ステップ条件に関連付けて、一定の条件が満たされていない場合、アセットが次のステップへ進むのを防いだりすることができます。場合によっては、アセットが次のワークフロー状態に移行しないようにする条件があります。アセットが次の状態に移行しないようにする条件(複数可)を定義したエレメントを作成する必要があります。

このエレメントは、コールされると次のデータを受信します。

- ObjectというIWorkflowableオブジェクト: 状態が変更されているアセットを表します。

- StepというIWorkflowStepオブジェクト: 現在のワークフロー・ステップを表します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- WebCenter Sitesのユーザー・インタフェースにStepConditionが定義されている場合、変数は名前と値のペアとして指定されます。StepConditionの定義の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

ワークフロー・ステップ条件のエレメントは、条件をチェックし、ブール値を返します。値がfalseの場合は、次のステップへ進みません。

次の例は、ワークフロー・ステップ条件エレメントのサンプルから抜粋したものです。

<?xml version="1.0" ?>

<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

<FTCS Version="1.1">

<!-- OpenMarket/Xcelerate/Actions/Workflow/StepConditions/ExampleStepCondition

-

- INPUT

-

- OUTPUT

-

-->

<csvar NAME="This step condition will check if step can be taken"/><br/>

次の例の1行目では、空のReturnVal変数を設定しています。

<setvar NAME="ReturnVal" VALUE="Variables.empty"/>

<!--change the value of ReturnVal to a non-empty string later on, if you want to stop the step --> <!-- most of the stuff below are debugging statements and also show you some items available to you to set up a condition for stopping the step-->

次の例の2行目では、WORKFLOWABLEASSET.GETDISPLAYABLENAMEタグを使用してワークフロー内のアセットの名前を取得します。

<!-- get asset -->

<WORKFLOWABLEOBJECT.GETDISPLAYABLENAME OBJECT="Object" VARNAME="assetdisplayablename"/>

Object:<csvar NAME="Variables.assetdisplayablename"/><br/>

次の例の2行目では、StepUserという変数を作成し、ステップを進めようとするユーザーのIDを格納します。3行目では、USERMANAGER.GETUSERタグを使用して、ユーザーのIDをStepUser変数にロードします。4行目では、CCUSER.GETNAMEタグを使用して、判読可能なユーザー名を取得し、5行目では、csvarタグを使用して、そのユーザー名を表示します。

<!-- get userid -->

Userid: <csvar NAME="Variables.StepUser"/><br/>

<USERMANAGER.GETUSER OBJVARNAME="myUserObj" USER="Variables.StepUser"/>

<CCUSER.GETNAME NAME="myUserObj" VARNAME="uname"/>

Username: <csvar NAME="Variables.uname"/><br/>

次の例の2行目では、WORKFLOWSTEP.GETIDタグを使用して現在のワークフロー・ステップのIDを取得します。4行目で使用されているWORKFLOWSTEP.GETNAMEタグにより、指定された名前のステップがロードされます。

<!-- getstep -->

<WORKFLOWSTEP.GETID NAME="Step" VARNAME="sid"/>

Stepid: <csvar NAME="Variables.sid "/>

<WORKFLOWSTEP.GETNAME NAME="Step" VARNAME="sname"/>

Stepname: <csvar NAME="Variables.sname"/><br/><br/>

次の例では、ステップの変更を停止する条件を定義します。forcestop変数およびnotalloweduser変数は条件チェックであり、WebCenter Sitesのインタフェースに、サンプルのステップ条件が定義された場合は、引数として設定されます。実際のステップ条件では、ここで任意の条件(たとえば、記事アセットに関連付けられたイメージがないか確認する)を設定してテストします。

<!-- This is the actual condition to stop the step. The following is just an example. -->

<if COND="Variables.forcestop=true">

<then>

<setvar NAME="ReturnVal" VALUE="You can not take this step because forcestop=true"/>

</then>

<else>

<if COND="Variables.uname=Variables.notalloweduser">

<then>

<setvar NAME="ReturnVal" VALUE="You are not allowed to take this step"/>

</then>

</if>

</else>

</if>

</FTCS>

73.2 ワークフロー・アクション

アセットはワークフロー間を移動するときに、ワークフロー・アクションをトリガーできます。ワークフロー・アクションでは、電子メールの送信から、指定された時間の経過後に、デッドロックの解除を評価する必要がある新しいアセットがあるというユーザーへの警告まで、あらゆるアクションが可能です。ワークフロー・アクションには、次の5つの種類があります。

- ステップ・アクション。ワークフロー状態間の遷移の一部として実行されます。

- 時間指定アクション。アセットが特定の状態になると、期限によりトリガーされます。たとえば、アセットが固有の割当てに関連付けられます。

- デッドロック・アクション。次の状態に移行するために、アセットが全員一致の票決を要する場合に実行されますが、アセットがどのステップに進むかによって投票者が異なります。デッドロック・アクションは、アセットの移行先として、ユーザーが別々のステップを選択した場合に実行されます。

- グループ・デッドロック時のアクション。次の状態に移行するために、ワークフロー・グループ内のアセットが全員一致の票決を要する場合に実行されますが、投票者が別々のステップを選択した場合、デッドロックが発生します。

- 委任アクション。アセットが委任された場合に実行されます。委任済のアセットは現在のワークフロー状態のままですが、新しいユーザーに割り当てられます。

最初に、ワークフローの管理者が、WebCenter Sitesのユーザー・インタフェースを使用して、ワークフロー・アクションを定義する必要があります。その後、これらのワークフロー・アクションを実行するエレメントを作成する必要があります。WebCenter Sitesでは、参照用に複数のワークフロー・アクション定義のサンプルが提供されています。ワークフロー・アクションの定義の詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

次の各項では、ワークフロー・アクションのサンプル・エレメントについて説明します。

- ステップ・アクションのエレメント

- 時間指定アクションのエレメント

- デッドロック・アクションのエレメント

- グループ・デッドロック時のアクションのエレメント

- 委任アクションのエレメント

73.2.1 ステップ・アクションのエレメント

ステップ・アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- ObjectTotal変数: 状態が変更されているアセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: 状態が変更されているアセットを表し、nnnは、0 (ゼロ)とObjectTotal -1の間の数です。

- StepというIWorkflowStepオブジェクト: 検討対象になっているワークフロー・ステップを表します。

- StepTargetUser変数: ステップのターゲット・ユーザーのカンマ区切りリストです。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- Group変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこのステップ・アクションの定義中に作成した任意の変数。

次の例では、ステップ・アクションのエレメントにより、アセットのパブリッシュが承認され、その他のほとんどのステップ・アクションのエレメントは、割当て先に電子メールを送信するものです。

<?xml version="1.0" ?>

<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

<FTCS Version="1.1">

<!-- OpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublish

-

- INPUT

- Variables.ObjectTotal - number of loaded workflowasset objects

- Object[n] - loaded workflowasset objects, where n = 0 - Variables.ObjectTotal

-targets - one or more comma separated names of PubTargets for which to approve the asset

-

- OUTPUT

-

-->

<!-- This is an action element called by step actions ApproveForPublish-->

This step action element will approve an asset for publish.<br/>

次の例の2行目では、SETCOUNTERタグを使用して、承認するアセットの数を記録するカウンタを作成します。3行目から9行目では、LOOPタグを使用し、アセット間をループしてアセット・タイプとIDを取得します。

<!-- get the id and assettype of the asset(s) to approve -->

<SETCOUNTER NAME="count" VALUE="0"/>

<LOOP COUNT="Variables.ObjectTotal">

<WORKFLOWASSET.GETASSETTYPE OBJECT="ObjectCounters.count" VARNAME="assettype"/>

<WORKFLOWASSET.GETASSETID OBJECT="ObjectCounters.count" VARNAME="assetid"/>

<SETVAR NAME="idCounters.count" VALUE="Variables.assetid"/>

<SETVAR NAME="typeCounters.count" VALUE="Variables.assettype"/>

<INCCOUNTER NAME="count" VALUE="1"/>

</LOOP>

次の例では、STRINGLISTタグを使用して、パブリッシュ・ターゲット名のカンマ区切りリストを作成します。PUBTARGET.LOADタグとPUBTARGET.GETタグは、パブリッシュ・ターゲットに関する情報をPubTarget表からロードするのに使用されます。この情報および承認されるアセットに関する情報は、ApprovePostエレメントに渡され、さらに処理されます。

<!-- approve for each destination -->

<STRINGLIST NAME="publishTargets" STR="Variables.targets" DELIM=","/>

<if COND="IsList.publishTargets=true">

<then>

<LOOP LIST="publishTargets">

<PUBTARGET.LOAD NAME="pubtgt" FIELD="name" VALUE="publishTargets.ITEM"/>

<if COND="IsError.Variables.errno=false">

<then>

Approving for publish to <CSVAR NAME="publishTargets.ITEM"/><br/>

<PUBTARGET.GET NAME="pubtgt" FIELD="id" OUTPUT="pubtgt:id"/>

<CALLELEMENT NAME="OpenMarket/Xcelerate/PrologActions/ApprovePost">

<ARGUMENT NAME="targetid" VALUE="Variables.pubtgt:id"/>

<ARGUMENT NAME="assetTotal" VALUE="Counters.count"/>

</CALLELEMENT>

</then>

<else>

Cannot approve for publish to destination: <CSVAR NAME="publishTargets.ITEM"/>, Error: <CSVAR NAME="Variables.errno"/>

</else>

</if>

</LOOP>

</then>

<else>

Cannot approve for publish. This step action requires a targets argument with one or more comma separated publishing destination names.

</else>

</if>

</FTCS>

73.2.2 時間指定アクションのエレメント

時間指定アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- WorkflowAssignmentTotal変数: このアクションが適用される割当ての総数を格納します。

- WorkflowAssignmentnnnというIWorkflowAssignmentオブジェクト: アクションの適用先の割当てを表します。nnnは、0(ゼロ)より大きい数です。

- オプションのGroup変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこの時間指定アクションの定義中に作成した任意の変数。

電子メールを送信する、時間指定アクション・エレメントの一部を次に示します。この電子メールの件名および本文のテキストは、「ワークフロー電子メール」フォームに設定され、このフォームには、Adminインタフェースにある「管理」ノードからアクセスします。本文テキストに予想される変数は次のとおりです。

- Variables.assetname: 現在のアセットの名前を格納します。

- Variables.assigner: ワークフロー・プロセス内で1つ前の状態を完了したユーザーの名前。

- Variables.instruction: 割当て者が割当ての完了時に、「実行するアクション」テキスト・ボックスに入力するテキスト。

次の例では、電子メール・オブジェクトの変数であるsubjectおよびbodyが、その値に置換されます。

<!-- translate subject -->
<EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="assetname=Variables.assetname" VARNAME="subject"/>
<!-- translate body -->
<EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="assetname=Variables.assetname&#38;time=Variables.time" VARNAME="body"/>
<!-- send mail -->
<sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>
</THEN>
<ELSE>
Email address: None<br/>
</ELSE>
</IF>
<inccounter NAME="COUNT" VALUE="1"/>
</loop>
</then>
</if>
</FTCS>

73.2.3 デッドロック・アクションのエレメント

デッドロック・アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineオブジェクト。

- ObjectTotal変数: デッドロック済アセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: デッドロック済アセットを表します。

- StepというIWorkflowStepオブジェクト: ワークフロー・ステップを表します。

- StepTotal変数: 個々のユーザーによって選択されたステップの数を格納します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- オプションのGroup変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこのデッドロック・アクションの定義中に作成した任意の変数。

次のデッドロック・アクション・エレメントは、アセットを承認するユーザーに電子メールを送信します。

この電子メールの件名および本文のテキストは、管理ユーザー・インタフェースにある「ワークフロー電子メール」フォームに設定されています。本文テキストに予想される変数は次のとおりです。

<?xml version="1.0" ?>

<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

<FTCS Version="1.1">

<!-- OpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/SendEmailToAssignees

-

- INPUT

-

- OUTPUT

-

-->

<!-- This is an action element called by step actions SendAssignmentEmail and SendRejectionEmail-->

<csvar NAME="This deadlock action element will send emails"/><br/>

次の例の2行目では、EMAILMANAGER.LOADタグを使用して、電子メール・オブジェクトをロードします。

<!-- load email object -->

<EMAILMANAGER.LOAD NAME="Variables.emailname" OBJVARNAME="emailobject"/>

次の例の1行目から9行目では、NumOfSteps変数を作成し、この変数には、委任されているアセットの総数または0 (ゼロ)のいずれかが格納されます。

<!-- get total steps -->

<if COND="IsVariable.StepTotal=true">

<then>

<setvar NAME="NumOfSteps" VALUE="Variables.StepTotal"/>

</then>

<else>

<setvar NAME="NumOfSteps" VALUE="0"/>

</else>

</if>

<removevar NAME="Step"/>

<setvar NAME="Header" VALUE="The following users have chosen the corresponding steps that has resulted in a deadlock. Please take appropriate actions to resolve deadlock:"/>

<setvar NAME="Message" VALUE="Variables.empty"/>

次の3つの例のコードでは、アセットをデッドロック状態にしたユーザーのリスト内をループして、ユーザーごとに電子メールを作成します。次に示すコードの10行目では、USERMANAGER.GETUSERタグを使用して、IDで指定されたユーザーのユーザー情報をロードします。11行目と12行目では、CCUSERタグを使用して、ユーザーの名前と電子メール・アドレスを取得します。

<!-- For each assignment object, get asignee -->

<setcounter NAME="COUNT" VALUE="0"/>

<if COND="Variables.NumOfSteps!=0">

<then>

<loop FROM="0" COUNT="Variables.NumOfSteps">

<!-- get assigner -->

<setvar NAME="userid" VALUE="Variables.StepUserCounters.COUNT"/>

<!-- get email address --->

<USERMANAGER.GETUSER USER="Variables.userid" OBJVARNAME="userobj"/>

<CCUSER.GETNAME NAME="userobj" VARNAME="user_name"/>

<CCUSER.GETEMAIL NAME="userobj" VARNAME="EmailAddress"/>

次の例の1行目から6行目では、WORKFLOWSTEPタグとWORKFLOWSTATEタグを使用して、アセットの開始および終了のステップと状態を取得します。

<WORKFLOWSTEP.GETNAME NAME="StepCounters.COUNT" VARNAME="stepname"/>

<WORKFLOWSTEP.GETSTARTSTATE NAME="StepCounters.COUNT" VARNAME="startstate"/>

<WORKFLOWSTEP.GETENDSTATE NAME="StepCounters.COUNT" VARNAME="endstate"/>

<WORKFLOWSTATE.GETSTATENAME NAME="Variables.startstate" VARNAME="startstatename"/>

<WORKFLOWSTATE.GETSTATENAME NAME="Variables.endstate" VARNAME="endstatename"/>

<setvar NAME="Message" VALUE="Variables.Message Variables.user_name: Variables.stepname - "/>

<!--

user:<csvar NAME="Variables.user_name"/><br/>

step name:<csvar NAME="Variables.stepname"/><br/>

startstate name:<csvar NAME="Variables.startstate"/><br/>

endstate name:<csvar NAME="Variables.endstate"/><br/>

-->

<!-- get asset -->

<WORKFLOWABLEOBJECT.GETDISPLAYABLENAME NAME="Variables.ObjectCounters.COUNT" VARNAME="assetname"/>

次の例の3行目と6行目では、電子メール・オブジェクトの変数であるsubjectおよびbodyが、その値に置換されます。

<!-- translate subject -->

<SETVAR NAME="params" VALUE="username=Variables.user_name&#38;header=Variables.Header&#38;message=Variables.Message&#38;assetname=Variables.assetname"/>

<EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="Variables.params" VARNAME="subject"/>

<!-- translate body -->

<EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="Variables.params" VARNAME="body"/>

<!-- send mail -->

<sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>

<inccounter NAME="COUNT" VALUE="1"/>

</loop>

</then>

</if>

email message:<csvar NAME="Variables.Header Variables.Message"/><br/>

</FTCS>

73.2.4 グループ・デッドロック時のアクションのエレメント

グループ・デッドロック時のアクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- ObjectTotal変数: デッドロック済アセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: デッドロック済アセットを表します。nnnは、0(ゼロ)より大きい数です。

- StepというIWorkflowStepオブジェクト: ワークフロー・ステップを表します。

- StepTotal変数: 個々のユーザーによって選択されたステップの数を格納します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- Group変数: デッドロックされたワークフロー・グループのIDを格納します。

- ワークフローの管理者がこのグループ・デッドロック時のアクションの定義中に作成した任意の変数。

次のグループ・デッドロック時のアクション・エレメントは、アセットを承認するユーザーに電子メールを送信します。

この電子メールの件名および本文のテキストは、管理ユーザー・インタフェースにある「ワークフロー電子メール」フォームに設定されています。本文テキストに予想される変数は次のとおりです。

<?xml version="1.0" ?>

<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

<FTCS Version="1.1">

<!-- OpenMarket/Xcelerate/Actions/Workflow/GroupActions/SendEmailToAssignees

-

- INPUT

-

- OUTPUT

-

-->

<!-- user code goes here -->

<csvar NAME="This group deadlock action element will send emails"/><br/>

<!-- load email object -->

<EMAILMANAGER.LOAD NAME="Variables.emailname" OBJVARNAME="emailobject"/>

<!-- get group -->

<WORKFLOWENGINE.GETGROUPID ID="Variables.Group" OBJVARNAME="grpobj"/>

<WORKFLOWGROUP.GETNAME NAME="grpobj" VARNAME="GroupName"/>

<!-- get total steps -->

<if COND="IsVariable.StepTotal=true">

<then>

<setvar NAME="NumOfSteps" VALUE="Variables.StepTotal"/>

</then>

<else>

<setvar NAME="NumOfSteps" VALUE="0"/>

</else>

</if>

<removevar NAME="Step"/>

<setvar NAME="Header" VALUE="The following users have chosen the corresponding steps that has resulted in a deadlock for the group: Variables.GroupName. Please take appropriate actions to resolve deadlock:"/>

<setvar NAME="Message" VALUE="Variables.empty"/>

<!-- For each assignment object, get asignee -->

<setcounter NAME="COUNT" VALUE="0"/>

<if COND="Variables.NumOfSteps!=0">

<then>

<loop FROM="0" COUNT="Variables.NumOfSteps">

<!-- get assigner -->

<setvar NAME="userid" VALUE="Variables.StepUserCounters.COUNT"/>

<!-- get email address --->

<USERMANAGER.GETUSER USER="Variables.userid" OBJVARNAME="userobj"/>

<CCUSER.GETNAME NAME="userobj" VARNAME="user_name"/>

<CCUSER.GETEMAIL NAME="userobj" VARNAME="EmailAddress"/>

<WORKFLOWSTEP.GETNAME NAME="StepCounters.COUNT" VARNAME="stepname"/>

<WORKFLOWSTEP.GETSTARTSTATE NAME="StepCounters.COUNT" VARNAME="startstate"/>

<WORKFLOWSTEP.GETENDSTATE NAME="StepCounters.COUNT" VARNAME="endstate"/>

<WORKFLOWSTATE.GETSTATENAME NAME="Variables.startstate" VARNAME="startstatename"/>

<WORKFLOWSTATE.GETSTATENAME NAME="Variables.endstate" VARNAME="endstatename"/>

<!-- get asset -->

<WORKFLOWABLEOBJECT.GETDISPLAYABLENAME NAME="Variables.ObjectCounters.COUNT" VARNAME="assetname"/>

<!-- set message -->

<setvar NAME="Message" VALUE="Variables.Message Asset: Variables.assetname, User: Variables.user_name, Step: Variables.stepname -- "/>

<!-- translate subject -->

<SETVAR NAME="params" VALUE="username=Variables.user_name&#38;header=Variables.Header&#38;message=Variables.Message&#38;assetname=Variables.assetname"/>

<EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="Variables.params" VARNAME="subject"/>

<!-- translate body -->

<EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="Variables.params" VARNAME="body"/>

<!-- send mail -->

<sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>

<inccounter NAME="COUNT" VALUE="1"/>

</loop>

</then>

</if>

email message:<csvar NAME="Variables.Header Variables.Message"/><br/>

</FTCS>

73.2.5 委任アクションのエレメント

委任アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- CurrentUser変数: アセットを委任しているユーザーのIDを格納します。

- オプションのGroup変数: ワークフロー・グループのIDを格納します。委任されるオブジェクトはすべて、同一のワークフロー・グループに存在する必要があります。

- DelegateUser変数: アセットが委任されているユーザーのIDを格納します

- DelegateComment変数: DelegateUser変数に格納されているユーザーIDに送信されるコメントを格納します

- ObjectTotal変数: 委任されているアセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: 委任されているアセットを表します。nnnは、0(ゼロ)より大きい数を表します。

委任アクションのエレメントは、ワークフロー・アクションの他のエレメント同様のコーディングをする必要があります。

74 カスタマイズ・フックのリアルタイム・パブリッシュの使用

リアルタイム・パブリッシュには、独自のトランスポータの作成、実装の詳細、ヘルパー・メソッド、トランスポータの実装例、完全なコードのリスト、境界状況のシナリオ、および管理インスタンスでのアセット・パブリッシュ・イベントのインターセプトなどがあります。

顧客のビジネス・ニーズに従って、リアルタイム・パブリッシュをカスタマイズできます。詳細は、「カスタマイズ・フックのリアルタイム・パブリッシュの使用」および「WebCenter Sitesのアセットおよびパブリッシュ・イベントの理解」を参照してください。

リアルタイム・パブリッシュ環境は、advpub.xmlファイルでWebCenter Sitesに構成されます。次のリストは、パブリッシュ・コンポーネントの説明に使用されるいくつかの用語を示します。

- リソース: 承認済アセットおよび表などの非アセット・データを示すのに使用される一般的な用語です。

- リソース・グループ: なんらかの関係のあるリソースのグループです。

カスタマイズ・フックのリアルタイム・パブリッシュの使用の詳細は、次の項を参照してください。

- リアルタイム・パブリッシュについて

- カスタム・トランスポータの作成

74.1 リアルタイム・パブリッシュについて

リアルタイム・パブリッシュとは、いくつかのジョブで構成されるパイプラインのことです。一部のジョブは管理インスタンスで実行され、その他のジョブはターゲット・インスタンスで実行されます。リアルタイム・パブリッシュのパラメータは、advpub.xmlファイルにあります。次に、各ジョブについて簡単に説明します。

- Gatherer: パブリッシュ可能なアセットのリストを作成して、そのリストを追加のリソース(アセット・タイプ、表の行)で装飾します。これらを合せて、パブリッシュするデータの正規セットを構成します。これらは、基礎となる承認グループ化戦略に依存しながら、相互依存のリソースのグループを作成することで実行されます。グループ化戦略では、承認済リソースのリストを取得して、それらをグループに編成します。使用可能なグループ化戦略は次のとおりです。

- ApprovalAggregatingGroupingStrategy – デフォルトのグループ化戦略で、この戦略を保持することをお薦めします。リソース・グループのコレクションを作成します。リソース・グループでは、そのグループ内で同じタイプの大部分のアセットが含まれるのもが主要なアセット・タイプになります。リソース・グループの作成中に、この戦略によって、同じアセット・タイプのアセットの数が維持されます。そのグループの主要なアセット・タイプが最大数が含まれるものになります。同様に、リソース・グループ・コレクションの作成中に、この戦略によって、同じ主要アセット・タイプのグループが一緒に収集されます。この戦略では、同じタイプのアセットのロードと保存が一括で高速に機能するため、同様のグループを集約できます。この戦略では、グループのサイズが相対的に小さくなり、グループの数が多くなります。

- ApprovalAccumulatingGroupingStrategy – この戦略では、リソース・グループを収集するだけで、追加の処理が実行されません。グループのサイズは相対的に大きくなり、グループの数が少なくなります。

- DataSerializer and DataDeserializer: XStream実装を使用してデータをシリアライズおよびデシリアライズします。

- Packager: Packagerは、Gathererで作成したリソースのリストを指定すると、各リソースのシリアライズされたレンディションを作成して、そのレンディションをローカルのfw_PubDataStore表に保存します。

- Transporter: Packagerで作成したfw_PubDataStoreに含まれるシリアライズされたデータを受け取り、そのデータをターゲット側のfw_PubDataStore表にコピーします。シリアライズされたデータは、開発者ガイドで説明されているように、カスタマイズされたマルチトランスポータを提供することで、複数の宛先に送信できます。wcs_properties.jsonファイルのプロパティxcelerate.concurrenttransportunpackerでは、(デフォルトで)DataTransporterおよびDataUnpackerを同時に実行するかどうかが記載されています。リアルタイム・パブリッシュ・トランスポータを記述するためのコードの詳細は、「リアルタイム・パブリッシュ・トランスポータを記述するためのコード」を参照してください。

- Unpacker: ターゲット側のfw_PubDataStore表に含まれるシリアライズされたデータを受け取り、そのデータをデシリアライズしてターゲット・データベースに保存します。DataTransporterおよびDataUnpackerが同時に実行されますが、DataUnpackerは、主要なパッケージ化が完了し、特定の優先度グループ情報が取得されるまで待機します。
実行に必要なDataUnpackerスレッドの数は、numParalleltasksを使用して構成できます。実行するためのDataUnpackerスレッド数のデフォルト値またはnumParallelTasksは、MSSQLサーバーおよびDB2データベースの場合は1、Oracleデータベースの場合は3です。デフォルト値は変更しないことをお薦めします。

- Monitor: パブリッシュ・セッション内のすべての参加者から受信されるすべてのメッセージを追跡して通知します。これらのメッセージは、PubMessageおよびPubProgress表に格納されます。PubSessionMonitorは、非同期メッセージ・システムのコンポーネントです。
ポーリング頻度またはpollFreqMillisはミリ秒で測定され、デフォルト値は5000です。

ミリ秒の時間またはtimeoutMillisは、参加者がクラッシュまたはハングしたと推定されるまでPubSessionMonitorがメッセージを待機する秒数です。デフォルト値は100000ミリ秒(100秒)です。

- CacheUpdater: CacheUpdaterは、Unpackerで正常に保存されたアセットのリストを指定すると、ページ・キャッシュの関連部分をフラッシュして、必要な場合は再生成します。
指定したページの再生成は、numThreadsPerServerの値に基づいて複数のスレッドで実行できます。numThreadsPerServerのデフォルト値は3です。コンポーネントregenServersでは、ページが再生成されるサーバーにURLのリストを提供します。URLが指定されていない場合、PageCacheUpdaterのデフォルト値は、(ユーザー・リクエストに基づいて)標準の再生成にデフォルトで設定されます。

リアルタイム・パブリッシュは、非同期メッセージングを使用して、各ジョブのステータスを追跡します。メッセージング・フレームワークの詳細を理解する必要はありませんが、ターゲット・システムとの通信がトランスポータによって円滑化されることは理解しておく必要があります。これには、アセットが保存されていることを管理システムに通知するために、Unpackerが発行するメッセージも含まれます。このメッセージにより、そのアセットにパブリッシュ済のマークを付けるように管理ロジックに指示します。

74.2 カスタム・トランスポータの作成

トランスポータには、次に示すいくつかのカスタマイズ・オプションが用意されています。

- HTTPに基づくOOTB (デフォルトまたは設定済)トラスポートを、別のプロトコルを使用するトランスポートに置き換える。

- 同一のパブリッシュ・セッションで複数のターゲットにパブリッシュする。

この項には次のトピックが含まれます:

- 独自のトランスポータの作成

- AbstractTransporterメソッドのオーバーライドの考慮事項

- AbstractTransporterのヘルパー・メソッド

- トランスポータの実装: 例

- リアルタイム・パブリッシュ・トランスポータを記述するためのコード

- 境界状況のシナリオの理解

- 管理インスタンスでのアセット・パブリッシュ・イベントのインターセプト

- UnpackersとCacheUpdatesの区別

74.2.1 独自のトランスポータの作成

独自のトランスポータを作成するには、次の手順を実行します。

1. com.fatwire.realtime.AbstractTransporterクラスのサブクラスを作成します。

2. メソッドping、sendBatch、listTransports、toString、およびremoteExecuteをオーバーライドします。

3. 管理側のclasses/AdvPub.xmlファイルを編集して、トランスポータをインストールします。

次の行:

<bean id="DataTransporter"
class="com.fatwire.realtime.MirrorBasedTransporterImpl"
singleton="false">

次の行に置き換えます

<bean id="DataTransporter"
class="[your transporter class]"
singleton="false">

74.2.2 AbstractTransporterメソッドのオーバーライドの考慮事項

AbstractTransporterのメソッドをオーバーライドするときには、次の点に注意してください。

- ping()には、ターゲットが稼働しているか、停止しているかを確認するロジックを含めます。最もわかりやすい使用法は、パブリッシュ・コンソールに緑色/赤色の診断インジケータを点灯させることです。パブリッシュ・セッションの起動には、pingの成功が必ずしも必要なわけではありませんが、接続の問題を診断するにはpingが便利なツールになります。
ターゲットへの接続にhttpを使用している場合は、デフォルトの実装を使用できます。このとき、オーバーライドや独自の実装は必要ありません。

- sendBatch()は、リモートfw_PubDataStoreにデータをアップロードする役割を果たします。これは、ローカルのfw_PubDataStoreから、IList形式のデータの小さなバッチで複数回呼び出されます。バッチ処理によりメモリーの使用量を抑えられ、バッチ処理は、気付かないうちに実行されています。

- remoteExecute()は、リモート・システムとの通信の役割を果たします。通信は双方向で行われ、管理側はリモートのジョブと取消しのリクエストをディスパッチするコマンドを送信し、ターゲット側はステータスを示すメッセージを送り返します。これらのメッセージの内容は、remoteExecuteには重要ではありません。このメソッドに必要な動作は、該当するリクエストを送信して応答を返すことのみです。

- listTransports()は、ターゲットが複数ある場合に、基になるトランスポートのリストになります。ターゲットが1つのみの場合、このメソッドは、現在のトランスポートのtoString()レンディションを返します。

- toString()は、このトランスポートのわかりやすい記述子です。たとえば、一般的な値は、http://mytarget:8081/cs/です。ただし、targetDataCenter-Virginia、serverOn8080などの別の文字列も受け入れられます。

74.2.3 AbstractTransporterのヘルパー・メソッド

AbstractTransporterには、いくつかのヘルパー・メソッドがあります。

- protected void writeLog(String msg)は、パブリッシュ・ログにメッセージを書き込みます。

- protected AbstractTransporter getStandardTransporterInstance()は、標準のHTTPベース・トランスポータの新しいインスタンスを取得します。これは、複数のターゲットにトランスポートを実装する際に役立ちます。

- protected String getParam(String param)は、パブリッシュ・コンソールで構成された、パブリッシュ・パラメータの値を取得します。

74.2.4 トランスポータの実装: 例

次に、複数のターゲットに対して動作する、トランスポータの実装例を示します。ターゲットは、次のように構成します。

1. 「宛先アドレス」には、宛先URLをカンマで区切って指定します。

例:

http://tgt1:9030/cs/
http://virginia:9040/cs/

2. 「他の引数」には、アンパサンドで区切ったユーザー名とパスワードを指定し、必要に応じて、1から始まるインデックスを接尾辞に使用して、追加サーバーのプロキシ情報を指定します。

追加ターゲットが1つある場合の例を示します。

REMOTEUSER1=fwadmin&REMOTEPASS1=xceladmin&PROXYSERVER1=proxy.com&PROXYPORT1=9090&PROXYUSER1=pxuser&PROXYPASSWORD1=pxpass

3. AdvPub.xmlで、DataTransporter Beanのエントリを、次のエントリに置換します。

<bean id="DataTransporter"
class="my.sample.MultiTransporter"
singleton="false">
<property name="id" value="Transporter"/>
</bean>

74.2.5 リアルタイム・パブリッシュ・トランスポータを記述するためのコード

package my.sample;
import COM.FutureTense.Interfaces.*;
import com.fatwire.cs.core.realtime.TransporterReply;
import java.net.URL;
import java.util.*;
/**
* RealTime Publishing transporter to multiple targets.
*/
public class MultiTransporter extends AbstractTransporter
{
private boolean initialized = false;
List<AbstractTransporter>  transporters  = new ArrayList();
/**
* Ping each underlying target and return true if all of them are up.
*/
@Override
public boolean ping(StringBuilder sbOut)
{
init();
boolean ret = true;
for(AbstractTransporter  t : transporters)
{
boolean thisret = t.ping(sbOut);
sbOut.append(t.getRemoteUrl() + (thisret ? " OK" : " Not reachable"));
sbOut.append(" ||| ");
ret &= thisret;
}
return ret;
}
/**
* Send the batch to each underliyng transport.
*/
@Override
protected int sendBatch(ICS ics, IList iList, StringBuffer outputMsg)
{
init();
for(AbstractTransporter  t : transporters)
{
int res = t.sendBatch(ics, iList, outputMsg);
if(res != 0)
{
// Just log the error for now, but this is an
// indication that the target may be down
// and other notifications may also be appropriate.
writeLog("Transporter " + t + " failed with " + res   + " " + outputMsg);
}
}
return 0;
}
/**
* Execute the remote command on each transporter and
* accumulate their responses.
*/
@Override
protected List<TransporterReply> remoteExecute(ICS ics, String s,
Map<String, String> stringStringMap)
{
init();
List<TransporterReply> res = new ArrayList<TransporterReply>();
for(AbstractTransporter  t : transporters)
{
List<TransporterReply> tres = t.remoteExecute(ics, s, stringStringMap);
res.addAll(tres);
}
return res;
}
/**
* Do some initialization by parsing out the configuration
* settings and instantiating a standard http transport
* to each target.
*/
private void init()
{
if(!initialized)
{
String remoteURLs = getRemoteUrl();
int count = 0;
for(String remoteUrl : remoteURLs.split(","))
{
String suffix = (count == 0) ? "" : String.valueOf(count);
AbstractTransporter t1 =
AbstractTransporter.getStandardTransporterInstance();
URL url;
try
{
url = new  URL(remoteUrl);
}
catch(Exception e)
{
throw new RuntimeException(e);
}
t1.setRemoteUrl(remoteUrl);
t1.setHost(url.getHost());
t1.setUsername(getParam("REMOTEUSER" + suffix));
t1.setPassword(getParam("REMOTEPASS" + suffix));
t1.setUseHttps("https".equalsIgnoreCase(url.getProtocol()));
t1.setContextPath(url.getPath());
t1.setPort(url.getPort());
t1.setProxyserver(getProxyserver());
t1.setProxyport(getProxyport());
t1.setProxyuser(getProxyuser());
t1.setProxypassword(getProxypassword());
t1.setHttpVersion(getHttpVersion());
t1.setTargetIniFile(getTargetIniFile()); transporters.add(t1);
++count;
}
initialized = true;
writeLog("Initialized transporters: " + toString());
}
}
/**
* Provide a full listing of all underlying transports. This is
* can be used by other components to determine
* whether they need to perform special actions depending on
* the number of targets. For example, asset publishing
* status processing may need to buffer responses until they're
* received from all targets before marking assets published.
* @return
*/
@Override
public List<String> listTransports()
{
init();
List<String> list = new ArrayList();
for(AbstractTransporter  t : transporters)
{
list.add(t.toString());
}
return list;
}
/**
* Just a human-friendly description of the transport. This may  show
* up in the  logs, so make it descriptive enougn.
*/
@Override
public String toString()
{
List<String> transs = listTransports();
StringBuilder sb = new StringBuilder();
for(String t : transs)
sb.append(t + " ");
return sb.toString();
}
}

74.2.6 境界状況のシナリオの理解

「リアルタイム・パブリッシュ・トランスポータを記述するためのコード」に示した例は、すべてのターゲットが実行しているという最適な状況では動作しますが、あるターゲットが短時間または長時間停止しているときもあります。あるターゲットにのみパブリッシュしているときに、アセットにパブリッシュ済としてのマークが付けられると、停止したターゲットは同期されなくなります。このようなシナリオには、次に示す方法で対応できます。

- ターゲットが短時間停止している場合は、アセットにパブリッシュ済のマークを付けないようにして、実行中のターゲットにはパブリッシュを続けます。別のターゲットが再起動されたときには、その時点より前のすべてのアセットがパブリッシュ用のキューに入れられた状態になります。これらのアセットは、最初のターゲットにも重複してパブリッシュされることになりますが、短時間の場合、このオーバーヘッドは無視できます。

- ターゲットが長時間停止したままになる場合は、そのターゲットを宛先構成のターゲットのリストからから削除することが最善策になるといえます(この例では、パブリッシュ構成の「宛先アドレス」から2番目のターゲットを削除します)。このようにすると、アクティブなターゲットが1つしかない場合でも、アセットはパブリッシュ済としてマークされ続けます。2番目のターゲットが再起動されたときには、最初にデータベースとファイル・システムの同期を実行して、その後で2番目のターゲットを宛先アドレスのリストに戻します。

74.2.7 管理インスタンスでのアセット・パブリッシュ・イベントのインターセプト

前述の最初の状況では、すべてのターゲットに保存されたアセットにのみにパブリッシュ済としてのマークを付けること必要になります。これを行うには、次に示すように、カスタムの通知ロジックを実装します。

1. com.fatwire.realtime.messaging.AssetPublishCallbackを開きます。

2. notify()メソッドをオーバーライドし、必要に応じて、progressUpdate()メソッドもオーバーライドします。

詳細な実装例は、後述の「手順1および2の実装例」を参照してください。

3. 管理側で、AdvPub.xmlのコールバックを有効にします。

- AssetCallback Beanを追加します。

- このBeanをPubsessionMonitorに登録します。

コードについては、後述の「手順3のコールバックBeanの有効化」を参照してください。

手順1および2の実装例

package my.sample;
import com.fatwire.assetapi.data.AssetId;
import java.util.HashMap;
import java.util.Map;
/**
* Buffer asset save notifications until we've received one
* from each target. Then mark asset published.
*/
public class AssetPublishCallbackMulti extends AssetPublishCallback
{
Map<String, Integer> saveEventsCount  = new HashMap<String, Integer>();
/**
* Receive notifications about the asset status.
* Currently the only available status is SAVED.
*/
@Override
public void notify(AssetId assetId, String status, String from)
{
String assetIdStr = String.valueOf(assetId);
writeLog("Got " + status + " notification from "
+ from + " for " + assetIdStr);
if("SAVED".equals(status))
{
Integer numNotifications;
if((numNotifications = saveEventsCount.get(assetIdStr)) == null)
{
numNotifications = 0;
}
numNotifications = numNotifications + 1;
saveEventsCount.put(assetIdStr, numNotifications);
if(numNotifications == this.getTargets().size())
{
super.notify(assetId, status, from);
writeLog("Marked " + assetIdStr  + " published");
}
}
}
/**
* Intercept progress update messages. Can be used for
* monitoring the health of the system but is not required.
*/
@Override
public void progressUpdate(String sessionId, String job,
String where, String progress, String lastAction, char status)
{
super.progressUpdate(sessionId, job, where, progress, lastAction, status);
}
}

手順3のコールバックBeanの有効化

AssetCallback Beanを追加するには:

<bean id="AssetCallback"
class="my.sample.AssetPublishCallbackMulti"
singleton="false"/>

このBeanをPubsessionMonitorに登録するには:

<bean id="PubsessionMonitor"
class="com.fatwire.realtime.messaging.PubsessionMonitor"
singleton="false">

<constructor-arg index="0">
<ref local="DataTransporter" />
</constructor-arg>

<constructor-arg index="1">
<ref local="AssetCallback" />
</constructor-arg>

<property name="pollFreqMillis" value="5000" />
<property name="timeoutMillis" value="100000" />
</bean>

74.2.8 UnpackersとCacheUpdatesの区別

複数の宛先にパブリッシュする場合は、それぞれの宛先ごとのUnpackerとCacheUpdaterを区別すると便利になります。これは、RTパブリッシュ・コンソールでプログレス・バーを調べるときや、ログを調べるときに役立ちます。

このような区別を行うために、ターゲット側のAdvPub.xmlファイルを編集して、DataUnpacker BeanとPageCacheUpdater BeanのID値を変更します。

例:

<bean id="DataUnpacker"
class="com.fatwire.realtime.ParallelUnpacker"
singleton="false">
<property name="id" value="Unpacker-Virginia2"/>
...
</bean>

<bean id="PageCacheUpdater"
class="com.fatwire.realtime.regen.ParallelRegeneratorEh"
singleton="false">
<property name="id" value="CacheFlusher-Virginia2"/>
...
</bean>

75 WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベントの理解

WebCenter Sitesでは現在、アセット・イベントおよびパブリッシュ・イベントの2つのイベント・タイプがサポートされています。

アセットおよびパブリッシュ・イベントの詳細は、次の項を参照してください。

- アセット・イベント

- パブリッシュ・イベント

75.1 アセット・イベント

アセット・イベントは、ユーザーまたはプログラムのいずれかによってアセットが追加、変更または削除された際に発生するイベントです。このイベントの発生時、構成済の一連のイベントがイベント・フレームワークによって参照および実行されます。この項では、アセット・イベント・リスナーの記述および登録方法について説明します。

- アセット・イベント・リスナーの記述

- アセット・イベント・リスナーの登録

75.1.1 アセット・イベント・リスナーの記述

アセット・リスナーでは、AssetEventListenerを拡張して、アセットの変更が通知されるようにする必要があります。WebCenter Sitesには、AbstractAssetEventListenerという便利なベース・クラスが用意されています。このクラスから拡張することで、イベントにつながる特定タイプのアクション(追加/変更/削除)が認識しやすくなります。

サンプル・コードを使用して、カスタム・アセット・リスナーを実装します。このコードでは、アセットIDを出力し、カスタム・ビジネス・ロジックをプラグインすることもできます。

package com.mycompany
public final class CustomAssetEventListener extends AbstractAssetEventListener
{
public void assetAdded(AssetId id)
{
System.out.println("Asset " + id + " added");
}
public void assetUpdated(AssetId id)
{
System.out.println("Asset " + id + " added");
}
public void assetDeleted(AssetId id)
{
System.out.println("Asset " + id + " added");
}
}

アセット・イベント・リスナーはアセット操作の発生後に起動され、データのコミット前には起動されません。

75.1.2 アセット・イベント・リスナーの登録

この項では、アセット・イベント・リスナーの登録方法について説明します。

注意:

WebCenter Sitesは、検索の索引付けに使用する標準リスナーを実装した状態で出荷されます。変更または削除は行わないでください。

アセット・イベント・リスナーは、AssetListener_regデータベース表に登録されます(表75-1)。

表75-1 AssetListener_regデータベース表

ID (整数)

行の一意のID

listener(String)

AssetEventListenerを実装する完全修飾されたクラス名。たとえば、com.mycompany.CustomAssetEventListenerなどです。

blocking(YまたはN)

'Yは、リスナーがブロッキング状態であることを示します(イベントを生成したスレッドと同時に実行されます)。

'N'は、リスナーがブロッキング状態でないことを示します(別のスレッドで実行されます)。

75.2 パブリッシュ・イベント

パブリッシュ・イベントは、パブリッシュ・プロセスの各手順でリアルタイム・パブリッシュ・フレームワークが生成するイベントです。この機能は、システム監視(SNMPなど)やその他のハウスキーピング・プロセスの促進を目的としています。この項には次のトピックが含まれます:

- パブリッシュ・イベント・リスナーの記述

- パブリッシュ・イベント・リスナーの登録

75.2.1 パブリッシュ・イベント・リスナーの記述

パブリッシュ・リスナーはPublishingEventListenerを実装する必要があります。リスナーに渡されるPublishingEventは、起動の要因となった特定のイベントを示します。

次の例は、pubsession IDをコンソールに出力するカスタム・イベント・リスナーの実装に使用します。

package com.mycompany;
public class CustomPublishingEventListener implements PublishingEventListener
{
public void onEvent( PublishingEvent event ) throws EventException
{
System.out.println( "Publishing event fired for     pubsession: " + event.getPubSessionId());
System.out.println( "Publishing task : " + event.getTaskName());
System.out.println( "Status of the task :  " + event.getStatus());
System.out.println( "Message associated with the task : " + event.getMessage() );
}
}

パブリッシュは複数のタスク(データ収集、パッケージ化、転送など)で構成され、それぞれがイベントを生成します。PublishingEventクラスは、パブリッシュ・タスクのイベントを表します。実装では、前述のようにイベントからタスクおよびそのステータスを問い合せることができます。

次の状態になった場合に、各タスクでイベントが生成されます。

- STARTED

- DONE

- CANCELLED

- SUBTASK_FINISHED

- FAILED

75.2.2 パブリッシュ・イベント・リスナーの登録

- パブリッシュ・イベント・リスナーをFW_PublishingEventRegistryデータベース表に登録します(表75-2)。

表75-2 FW_PublishingEventRegistryデータベース表

ID (整数)

行の一意のID

listener(String)

PublishingEventListenerを実装する完全修飾されたクラス名。例: com.mycompany.CustomPublishingEventListener

blocking(YまたはN)

'Yは、リスナーがブロッキング状態であることを示します(イベントを生成したスレッドと同時に実行されます)。

'N'は、リスナーがブロッキング状態でないことを示します(別のスレッドで実行されます)。

第XVIII部 トラブルシューティング

この部では、WebCenter Sitesのエラー・ロギングおよびソース・コード・デバッグのオプションについて説明します。また、一般的なエラー・ロギングおよびデバッグ手法の情報についても説明します。

この部は、次の章で構成されています。

- エラーのロギングおよびデバッグ

76 エラーのロギングおよびデバッグ

WebCenter Sitesには、エラー・メッセージのロギングとソース・コードのデバッグについていくつかのオプションが用意されています。WebCenter Sitesではアクティビティをログ・ファイルに記録できますが、ログ・ファイルは新規インストールではsites.logという名前でlogsフォルダに配置されます。ログ・ファイルに書き込まれる情報のタイプとボリュームは、有効化または定義に選択したログ出力により管理されます。WebCenter Sitesには、JSPタグとXMLタグがタスクを完了できなかった場合にエラー・コードを返すために使用する予約済変数もあります。

エラーのロギングおよびデバッグの詳細は、次の項を参照してください。

- WebCenter Sitesログ・ファイルへのカスタム・メッセージの書込みについて

- タグによるエラー・コードの使用方法

76.1 WebCenter Sitesログ・ファイルへのカスタム・メッセージの書込みについて

新規のWebCenter Sitesインストールでは、ログODLがWebCenter Sitesロギング・システムになります。ログODLが設定されると、情報のロギング方法とロギングの対象となる情報を指定するloggingconfig.xmlファイルが作成されます。また、Adminインタフェースは、「管理」タブ上の「システム・ツール」ノードに「ログODLの構成」ツールを用意しています。「ログODLの構成」の使用によって、現在のログ出力をAdminインタフェースから直接表示できます。また、新規ログ出力の追加とログ出力レベルの変更も動的に行えます。ログ出力のテキスト・バージョンをこのインタフェースからloggingconfig.xmlファイルにコピーしておくと、システムの再起動時でも変更は削除されません。「ログODLの構成」ツールの詳細は、『Oracle WebCenter Sitesの管理』を参照してください。

独自のログ出力を定義したり、独自のメッセージをWebCenter Sitesのログ・ファイルに書き込むには、ics:logmsgタグを使用します。次の例では、WebCenter Sitesのログ・ファイルに警告メッセージが書き込まれます。

<ics:logmsg msg="This is a warning message"
name="com.fatwire.logging.cs.jsp" severity="warn"/>

ics:logmsgの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

注意:

ロギングが実装されているシステムのタイプに一致するレベルでログ出力を設定することをお薦めします。開発システムおよびコンテンツ管理システムでは、大量の情報を提供する高重大度(INFOまたはDEBUGなど)にログ出力レベルを設定できます。配信システムでは、ログ出力を無効にするか低重大度(WARNまたはERROR)に設定することで、パフォーマンスの低下を回避し、公開された環境でシステム情報を利用できます。

76.2 タグによるエラー・コードの使用方法

WebCenter Sitesには、ほとんどのJSPタグとXMLタグがタスクを完了できなかった場合にエラー・コード(通常はerrnoという)を返すために使用するVariables.errnoという名前の予約済変数があります。

たとえば、<CALLELEMENT> XMLタグはVariables.errnoを次のように設定します。

- -10: 存在しないエレメントを指定した場合。

- -12: WebCenter Sitesが評価できない既存エレメントを指定した場合。

成功した場合、<CALLELEMENT>はVariables.errnoの値を変更しません。

注意:

リビジョン追跡操作の場合は、Variable.errdetailsという予約済変数によってエラーに関する追加情報が提供されます。

次の戦略をVariables.errnoを使用するタグと併用します。

1. タグを呼び出す前に、Variables.errnoを0に初期化します。

2. タグを呼び出します。

3. Variables.errnoを評価します。

エラー・コードを使用するタグの例

たとえば、次のコードは3つの手順をすべて実行します。

<SETVAR NAME="errno" VALUE="0"/>
<SETCOUNTER NAME="pi" VALUE="3.14159"/>
<IF COND="Variables.errno=-501">
<THEN>
<p>Bad value of pi</p>
</THEN>
</IF>

このコードを実行すると次のHTMLが生成されますが、これはSETCOUNTERでは浮動小数点値を処理できないためです。

<p>Bad value of pi</p>

ASSET、RENDERおよびSITEPLANの各タグは、実行前にerrnoをクリアします。これらのタグを使用する場合、errnoを0に設定する必要はありません。たとえば、ASSETタグの使用後にerrnoの値をチェックして、値が変更されたかどうかを判別するのみで十分です。

<ASSET.LOAD NAME="topArticle" TYPE="Article"
OBJECTID="Variables.cid"/>
<IF COND="IsError.Variables.errno=false">
<THEN>
<ASSET.CHILDREN NAME="topArticle" LIST="listOfChildren"/>
</THEN>
</IF>

テンプレート・エレメントの終わりに、次のようなエラー・チェッキング・コードを含めます。

<IF rendermode="preview">
<THEN>
<IF COND="IsError.Variable.errno=true">
<THEN>
<FONT COLOR="#FF0000">
Error <CSVAR NAME="Variables.errno"/>
while rendering <CSVAR NAME="pagename"/>
with asset ID <CSVAR NAME ="Variables.cid"/>.
</FONT>
</THEN>
</IF>
</THEN>
</IF>

Javaインタフェース

WebCenter Sitesのコール後に文字列変数errnoを取得して、成功または失敗のテストを行うことができます。次に例を示します。

cs.clearErrno();

IList rslt = cs.SelectTo(SYSTEMUSERS_TABLE, ALL_FIELDS, USERNAME,
null, NO_LIMIT, null, CACHE_RESULTS, errstr);

errno = cs.GetVar("errno");

if (errno.compareTo(ERRNO_SUCCESS) == 0)
{
...

エラー番号ルール

エラー番号には必ず整数を使用します。表76-1に、Variables.errnoのエラー番号ルールの概要を示します。

それぞれのタグ固有のエラー番号については、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

表76-1 エラー番号ルール

番号

重要度

負の整数

失敗

0 (ゼロ)

成功

リビジョン追跡タグ以外のタグの正の整数

情報

リビジョン追跡タグの正の整数

失敗

第XIX部 リファレンス

この部では、最初にチュートリアルのヘルプを使用したアセットAPIについて説明します。次に、検索索引を管理するための検索フレームワーク、パブリック・サイト検索の作成に使用可能な検索APIの使用方法について説明します。

この部は、次の章で構成されています。

- Asset APIの使用: チュートリアル

- パブリック・サイト検索の使用

77 Asset APIの使用: チュートリアル

Asset APIチュートリアルはクイックリファレンスであり、Oracle WebCenter Sites Java APIリファレンスの代替ではありません。このチュートリアル全体を通じて取り上げられているコードサンプルは、Asset APIの使用方法を示しています。

Asset APIチュートリアルの使用の詳細は、次の項を参照してください。

- Asset APIの理解

- 主要インタフェース

- はじめに

- Asset APIによる読取り

- Asset APIによる書込み

- 開発戦略

- オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定

77.1 Asset APIの理解

Asset APIは、WebCenter Sitesのアセットにアクセスしてこれらのアセットを操作するためのJava APIです。その主な目的は、アセットを扱うことができるコンテキストを拡大することです。その主な特長は次のとおりです。

- Asset APIは、非サーブレット・コンテキストでWebCenter Sitesをサポートしています。
Asset APIが導入される前は、WebCenter Sitesでは、WebページやWebアプリケーションを作成するための手段として使用されるタグ(XMLとJSPの両方)という形で、プログラミング用の主要インタフェースが公開されていました。この意味において、WebCenter Sitesは、サーブレット・モデルを中核として厳密に構築されていたため、スタンドアロンJavaプログラム(EJBなど)などの他のコンテキストでは使用できませんでした。したがって、サーブレット・フレームワークに依存することなく、どのような環境でも使用できるAPIを作成する必要がありました。

- Asset APIは、ベーシックとフレックスという2つのアセット・ファミリの取得操作、作成操作および変更操作を統一しています。

- Asset APIは、AssetDataとAttributeDataで両方のアセット・ファミリを表しています。

- Asset APIは、フレックス・アセットとベーシック・アセットのどちらに対しても汎用のConditionオブジェクトとQueryオブジェクトを使用します。

- Asset APIは、Javaオブジェクトという形でベーシック・アセット、フレックス・アセットおよびフレックス親アセットの作成と編集をサポートしています。

注意:

Asset APIでは、ロード対象のアセット以外の依存性が一切ログに記録されません。

77.2 主要インタフェース

Asset APIを使用すると、WebCenter Sitesのアセットのデータと定義の両方にアクセスできます。

- com.fatwire.assetapi.dataパッケージには、データの読取りに役立つクラスが含まれています。

- com.fatwire.assetapi.defの下のクラスは、アセットの定義用です。

- com.fatwire.assetapi.queryパッケージには、問合せを作成するために必要な構成体が含まれています。詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

Asset APIでは、次の主要インタフェースが定義されています。

- Session: APIからWebCenter Sitesへの主要なエントリ・ポイントです。Asset APIでなんらかの処理を実行するためには、セッションを取得する必要があります。

- AssetDataManager: アセット・データを読み取るためのマネージャです。開発者は、ここで情報を問い合せることができるとともに、アセットのアソシエーションなどの情報を検索できます。

- AssetTypeDefManager: アセット・タイプの定義を読み取るためのマネージャ。「定義」は、フレックス・アセットが重要となるWebCenter Sitesでロードされる条件です。ここでは、アセット・タイプの構造を定義するものと同様に、一般的な意味で使用されます。その結果、ベーシック・アセット・タイプにも定義があります。

- AssetData: アセットのデータです。基本的には、AttributeDataインスタンスおよびアセット自体に関するその他の情報のコレクションです。

- AssetId: アセット・タイプとIDの組合せです。

- DimensionableAssetManager: 特定のアセットの翻訳を取得することで多言語アセットをサポートするマネージャです。

77.3 はじめに

このチュートリアルで満たす必要がある前提条件を次に示します。

- このチュートリアルの例を実行するには、FirstSiteII (FSII)が必要です。tools.jarファイル(JDK 1.5以降に付属)がクラスパス内に存在している必要があります。

注意:

Asset APIは、スタンドアロンJavaプログラムから使用できます。そのためには、いくつかの設定が必要です。詳細は、「オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定」を参照してください。

- この章の例に取り組むには、jspエレメントに関する知識と、これらのエレメントがWebCenter Sites環境でどのように作成されるのかに関する知識が必要です。詳細および手順については、「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

77.4 Asset APIによる読取り

ここまでの簡単な背景情報に基づいて、FSIIデータに基づいたいくつかのコードを記述してみましょう。

この項には次のトピックが含まれます:

- 簡単な例: フィールド値の読取り

- AssetIdの読取り

- アセットIDに基づいた属性の読取り

- 問合せの実行

- 複雑な問合せの実行

- ソートによる結果の取得

- BlobObjectの読取り

- 複数値属性の取得

- 多言語アセット: 翻訳の取得

- アセットと属性の定義の読取り

- キーと値のマッピングの読取り

77.4.1 簡単な例: フィールド値の読取り

FSII記事内の「FSIIHeadline」フィールドのすべての値を読み取ってみましょう。実行する手順は、次のとおりです。

1. セッションを取得します。

2. AssetDataManagerのハンドルを取得します。

3. 問合せを作成します。

4. 読取りを実行して、結果を出力します。

次に、これらの手順を実装するコードを示します(jspエレメント内)。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr =(AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
Query q = new SimpleQuery("Content_C", "FSII Article", null, Collections.singletonList("FSIIHeadline") );
for( AssetData data : mgr.read( q ) )
{
out.println( data.getAttributeData("FSIIHeadline").getData() );
out.println( "<br/>" );
}
%>
</cs:ftcs>

1. SessionFactory.newSession()によって、指定されたユーザーのセッションが作成されます。それ以降は、このセッション・インスタンスを使用して読み取られたすべてのデータは、そのユーザーのACL権限に準拠します。単にnewSession( null, null )をコールして、仮定ユーザーであるDefaultReaderに属するセッションを取得することもできます。WebCenter Sitesによって稼働するWebアプリケーションは通常、実行時にこのユーザーとして実行されます。ただし、間違ったユーザー名とパスワードが指定された場合、エラーが発生します。

2. このセッションを使用して、AssetDataManager.getManagerのハンドルを取得します。(AssetDataManager.class.getName()メソッドによってこの処理が実行されます。)

3. Queryは、このユーザーの検索条件に基づいた結果を表しています。この例では、シンプルなバージョンのQueryを使用して、アセット・タイプ(Content_C)、サブタイプ(FSII Article)、および取得する属性のリスト(この場合は単にFSIIHeadline)を指定しています。すべてのアセットが目的であるため、3つ目のパラメータ(Conditionインスタンスを受け取ります)はnullです。Conditionsの使用方法の詳細は、「複雑な問合せの実行」を参照してください。

4. AssetDataManagerのread()メソッドは、AssetDataに対するIterableを返します。それぞれのアセット・データには、属性名に対するAttributeDataのインスタンスが含まれています。AttributeData.getData()は、属性自体の実際のデータを返します。

77.4.2 AssetIdの読取り

- これらすべてのアセットのIDを把握するには、AssetIdインスタンスを返すAssetData.getAssetId()を使用します。

- AssetIdを出力するには、次に示すように、「簡単な例: フィールド値の読取り」のコードを変更します。

for( AssetData data : mgr.read( q ) )
{
AssetId id = data.getAssetId();
out.println( data.getAttributeData("FSIIHeadline").getData() + " id=" + id );
out.println( "<br/>" );
}

このコードは、次の行を出力します(AssetIdは、id番号とタイプを含むコンポジットです)。AssetId.getId()とAssetId.getType()はそれぞれIDとタイプを返します。

AudioCo. America Announces H300 series id=Content_C:1114083739888
AudioCo. New Portable Media Player Offers Full Video Experience id=Content_C:1114083739926
AudioCo.'s First Under Water MP3 Player id=Content_C:1114083739951
...

77.4.3 アセットIDに基づいた属性の読取り

また、アセットIDの属性を読み取ることもできます(テンプレートに渡されるか、プログラムによって取得されます)。

- ここでは、AssetId (Content_C:1114083739888という「AssetIdの読取り」で使用したコードで示したものなど)を例として取り上げて、次のコードを使用して、名前、説明およびFSIIBodyを出力してみます。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<%@ page import="com.openmarket.xcelerate.asset.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr =(AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
AssetId id = new AssetIdImpl( "Content_C", 1114083739888L );
List attrNames = new ArrayList();
attrNames.add( "name" );
attrNames.add( "description" );
attrNames.add( "FSIIBody" );

AssetData data = mgr.readAttributes( id, attrNames );
AttributeData attrDataName = data.getAttributeData( "name" );
AttributeData attrDataDescr = data.getAttributeData( "description" );
AttributeData attrDataBody = data.getAttributeData("FSIIBody");

out.println( "name:" + attrDataName.getData() );
out.println( "<br/>" );
out.println( "description:" + attrDataDescr.getData() );
out.println( "<br/>" );
out.println( "FSII Body:" + attrDataBody.getData() );
out.println( "<br/>" );
%>
</cs:ftcs>

ここでは、特定のIDについて、読み取る属性を指定しています。このコード例からわかるように、ベーシック・フィールド(nameやdescriptionなど)とフレックス属性を指定できます(どちらも属性として扱われます)。

- かわりに、AssetDataManager.read( List<AssetId> ids)を使用して、特定のIDのすべての属性をロードすることもできます。次のコードでは、単一のAssetIdについてこの処理を実行する方法を示しています。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<%@ page import="com.openmarket.xcelerate.asset.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr =(AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
AssetId id = new AssetIdImpl( "Content_C", 1114083739888L );

Iterable<AssetData> dataItr = mgr.read( Collections.singletonList( id ) );

for( AssetData data : dataItr )
{
for(AttributeData atrData : data.getAttributeData() )
{
out.println( "<br/>" );
out.println( "attribute name:" + atrData.getAttributeName() );
out.println( "data: " + atrData.getData() );
}
}
%>
</cs:ftcs>

77.4.4 問合せの実行

Queryは、検索対象のデータに基づいた条件を指定します。

- SKUがiAC-008である製品を検索するには、名前およびIDも出力する次のコードを使用します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
Condition c = ConditionFactory.createCondition( "FSIISKU", OpTypeEnum.EQUALS, "iAC-008" );
Query query = new SimpleQuery( "Product_C", "FSII Product", c, Collections.singletonList( "name" ) );

for( AssetData data : mgr.read( query ) )
{
AttributeData attrData = data.getAttributeData( "name" );
out.println( "name:" + attrData.getData() );
out.println( "<br/>" );
out.println( "id:" + data.getAssetId() );
}
%>
</cs:ftcs>

Queryは、1つのCondition、取得対象の一連の属性および1つのSortOrderで構成されています。前述の例では、iAC-008とEQUALになるFSIISKU属性値に基づいて構成された条件を使用しています。前述の例と同じように、生成されるAssetDataのコレクションに格納された状態で取得する属性名のリストを渡しています。

- 問合せ可能な属性の型とその方法について、いくつかの考慮事項が存在します。各種の問合せアルゴリズムの詳細は、「問合せのタイプ」を参照してください。
簡単に言うと、一部のタイプの問合せは特定のアルゴリズムで実行できますが、他のアルゴリズムでは実行できません。これは、Assetタグ・ファミリとAssetSetタグ・ファミリにおける動作とまったく同じです。このことを例示するために、たとえば、価格(FSIIPrice)が179より高いすべての製品を読み取るとします。

FSIIPriceは、MONEY型です。「データ型と有効な問合せ演算」の表77-2を参照すると、GREATER_THAN演算がこのデータ型について許可されているのは、ベーシック/汎用アルゴリズムのみということがわかります。次のコードでは、このアルゴリズムを使用して、価格が179より高いすべての製品を取得します。問合せアルゴリズムの選択は、このコード内の強調表示された行で行っています。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>

<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
Condition c = ConditionFactory.createCondition( "FSIIPrice", OpTypeEnum.GREATER_THAN, 179.0f );
Query query = new SimpleQuery( "Product_C", "FSII Product", c, Arrays.asList( "name", "FSIIPrice" ) );
query.getProperties().setIsBasicSearch( true );

for( AssetData data : mgr.read( query ) )
{
AttributeData name = data.getAttributeData( "name" );
AttributeData price = data.getAttributeData( "FSIIPrice" );

out.println( "name:" + name.getData() );
out.println( "id:" + data.getAssetId() );
out.println( "price:" + price.getData() );

out.println( "<br/>" );
}
%>
</cs:ftcs>

77.4.5 複雑な問合せの実行

複雑な問合せを作成するには、ネストされた複数のConditionを使用します。選択した問合せアルゴリズムに応じて、問合せは「問合せのタイプ」に列記している制約を受けます。

次のコードを使用して、FSIIPrice属性が179.0より大きいという条件と、名前がFSIIに類似しているという条件の両方または一方を満たしているすべてのProduct_Cアセットを取得します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
Condition c1 = ConditionFactory.createCondition( "FSIIPrice", OpTypeEnum.GREATER_THAN, 179.0f );
Condition c2 = ConditionFactory.createCondition( "name", OpTypeEnum.LIKE, "FSII" );
Condition c = c1.and( c2 ); // c1.or( c2 );

Query query = new SimpleQuery( "Product_C", "FSII Product", c, Arrays.asList( "name", "FSIIPrice" ) );
query.getProperties().setIsBasicSearch( true );

for( AssetData data : mgr.read( query ) )
{
AttributeData name = data.getAttributeData( "name" );
AttributeData price = data.getAttributeData( "FSIIPrice" );

out.println( "name:" + name.getData() );
out.println( "id:" + data.getAssetId() );
out.println( "price:" + price.getData() );

out.println( "<br/>" );
}
%>
</cs:ftcs>

77.4.6 ソートによる結果の取得

次に示すように、フィールドをソートして結果を取得したり、ソート順を逆にしたりできます。

- 価格によってソートされた結果を取得するには、次のコードを使用します(この例では、SortOrderとして昇順を指定しています)。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );

SortOrder so = new SortOrder( "FSIIPrice", true );
Query query = new SimpleQuery( "Product_C", "FSII Product",
null, Collections.singletonList( "FSIIPrice" ), Collections.singletonList( so ) );

for( AssetData data : mgr.read( query ) )
{
AttributeData price = data.getAttributeData( "FSIIPrice" );

out.println( "id:" + data.getAssetId() );
out.println( "price:" + price.getData() );

out.println( "<br/>" );
}
%>
</cs:ftcs>

The above code sorts and prints asset ids and price in the ascending order of FSIIPrice,

id:Product_C:1114083739851 price:89.99
id:Product_C:1114083739757 price:99.95
id:Product_C:1114083739696 price:129.99
id:Product_C:1114083739301 price:129.99
id:Product_C:1114083739471 price:179.95
id:Product_C:1114083739350 price:189.95
id:Product_C:1114083739225 price:399.99
id:Product_C:1114083739596 price:899.95
id:Product_C:1114083739804 price:1399.99
id:Product_C:1114083739549 price:3799.95
id:Product_C:1114083739663 price:6999.99

- ソート順序を逆にするには、このコードの強調表示された行でtrueをfalseに変更します。

77.4.7 BlobObjectの読取り

Asset APIでは、データ(バイナリ・ファイルとして保管されるデータ)のファイル・タイプを表すための特別なクラスが定義されています。たとえば、FirstSiteIIのFSIIDocumentFile属性はblob型です。

- 次のコードを使用して、すべてのDocument_CインスタンスからFSIIDocumentFileを読み取って、アセットID、ファイル名およびファイル・サイズを出力します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );

Query query = new SimpleQuery( "Document_C", "FSII Document", null, Collections.singletonList( "FSIIDocumentFile" ) );

for( AssetData data : mgr.read( query ) )
{
AttributeData docAttr = data.getAttributeData("FSIIDocumentFile");
BlobObject fileObj = (BlobObject)docAttr.getData();
byte [] d = new byte[fileObj.getBinaryStream().available()];
fileObj.getBinaryStream().read(d);

out.println( "id:" + data.getAssetId() );
out.println( "file name:" + fileObj.getFilename() );
out.println( "file size:" + d.length );

out.println( "<br/>" );
}
%>
</cs:ftcs>

77.4.8 複数値属性の取得

Asset APIは、単一値属性をサポートしているのと同じように複数値属性をサポートしています。AttributeDataには、複数の値を取得するためのgetDataAsList()という付随メソッドが含まれています。

次のコードを使用して、FSIIKeywordという複数値属性に含まれているデータを出力します。

注意:

FirstSiteIIに付属しているサンプル・データには、FSIIKeyword属性のデータは含まれていないため、このサンプル・コードではキーワードはまったく出力されません。このコードを実行する前に、一部のFSIIDocumentインスタンスを編集して、この属性のデータを追加します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );

Query query = new SimpleQuery( "Document_C", "FSII Document",
null, Collections.singletonList( "FSIIKeyword" ) );

for( AssetData data : mgr.read( query ) )
{
AttributeData attrData = data.getAttributeData( "FSIIKeyword" );
List retData = attrData.getDataAsList();
out.println( "id:" + data.getAssetId() );

for( Object o : retData )
{
out.println( "data:" + o );
}

out.println( "<br/>" );
}
%>
</cs:ftcs>

77.4.9 多言語アセット: 翻訳の取得

Asset APIでは、多言語アセットを扱うためのインタフェースとメソッドも用意されています。基本的に、多言語アセットを扱うためのメソッドはDimensionableAssetManager内にあります。これらのメソッドは、特定のアセットのすべてのロケールを取得したり、アセットの特定の翻訳を取得したりできます。

次の例を使用して、グループをLocaleに設定したDimensionableAssetManager内のgetRelativesメソッドを使用して、まずアセットPage: 1118867611403の翻訳を取得してから、getRelativeメソッドを使用してこのアセットのfr_FR翻訳を取得します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.mda.DimensionableAssetManager"%>
<%@ page import="com.openmarket.xcelerate.asset.*"%>
<%@ page import="java.util.*"%>

<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
DimensionableAssetManager mgr = (DimensionableAssetManager)ses.getManager(DimensionableAssetManager.class.getName());

AssetId page_asset = new AssetIdImpl("Page", 1118867611403L);

for( AssetId id : mgr.getRelatives( page_asset, null, "Locale" ))
{
out.println( id );
}
out.println( "<br/>" );

AssetId fr_translation = mgr.getRelative( page_asset, "fr_FR" );
out.println( fr_translation );

%>
</cs:ftcs>

77.4.10 アセットと属性の定義の読取り

Asset APIを使用すると、アセットのデータだけでなくアセットの定義にもアクセスできます。アセットの定義を構成している属性や各属性の型などの情報を取得するには、AssetTypeDefManagerというマネージャを使用します。

次の例を使用して、Document_Cからすべての定義情報を読み取って、ブラウザに出力します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.def.*"%>
<%@ page import="java.util.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetTypeDefManager mgr = (AssetTypeDefManager) ses.getManager( AssetTypeDefManager.class.getName() );

AssetTypeDef defMgr = mgr.findByName( "Document_C", "FSII Document" );

out.println( "Asset type description: " + defMgr.getDescription() );
out.println( "<br/>" );

for( AttributeDef attrDef : defMgr.getAttributeDefs() )
{
out.println( "Attribute name: " + attrDef.getName() );
out.println( "Attribute description: " + attrDef.getDescription() );
out.println( "is required: " + attrDef.isDataMandatory() );
out.println( "Attribute type: " + attrDef.getType() );
out.println( "<br/>" );
}

%>
</cs:ftcs>

77.4.11 キーと値のマッピングの読取り

Asset APIを使用すると、特定のCSElementやテンプレートのキーと値のマッピング・ペアにアクセスできます。

次の例を使用して、CSElementからすべてのマッピング・ペアを読み取ります。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager mgr = (AssetDataManager)(ses.getManager(AssetDataManager.class.getName()));
Condition c = ConditionFactory.createCondition("name", OpTypeEnum.LIKE, "FSIICommon/Nav/LocaleForm");
Query query = new SimpleQuery("CSElement", null, c, null);
query.getProperties().setReadAll(true);
for (AssetData data : mgr.read(query))
{
List<AttributeData>  mappingArray = (List<AttributeData>)data.getAttributeData("Mapping"). getData();
for (int i=0; i<mappingArray.size(); i++)
{
HashMap mappingMap = (HashMap)mappingArray.get(i).getData();
String key = (String)((AttributeData)mappingMap.get("key")).getData();
String type =(String)((AttributeData)mappingMap.get("type")).getData();
String value = (String)((AttributeData)mappingMap.get("value")).getData();
String siteid = (String)((AttributeData)mappingMap.get("siteid")).getData();

out.println("Mapping Entry #"+String.valueOf(i+1));
out.println("<br/>");
out.println("Key: "+key);
out.println("Type: "+type);

out.println("Value: "+value);

out.println("Siteid: "+siteid);
out.println("<br/>");
}
}
%>
</cs:ftcs>

77.5 Asset APIによる書込み

Asset APIは、ベーシック・アセットおよび特定タイプのフレックス・アセットに対する書込み操作をサポートしています。サポートされている書込み操作は、アセットの作成、変更および削除です。サポートされているアセットは、ベーシック・アセット、フレックス・アセットおよびフレックス親です。これら以外のすべてのアセット・タイプ(フレックス親定義、フレックス・アセット定義、フレックス・フィルタおよびフレックス属性)は、現在サポートされていません。これらのアセット・タイプに対するいずれかの書込み操作(挿入または更新)が試行された場合は、UnsupportedOperationExceptionがスローされます。

この項には次のトピックが含まれます:

- 新規アセットの作成

- 既存のアセットの更新

- 既存のアセットの削除

- 多言語アセット

77.5.1 新規アセットの作成

Asset APIは、AssetDataManager.insert( List<AssetData> data )メソッドを使用して、WebCenter Sites内で新規アセットを作成します。このメソッドは、AssetDataのリストを受け取って、これらのAssetDataを使用してWebCenter Sites内でアセットを作成します。正常に実行された場合、このメソッドは、受け取ったAssetDataにこれらの新規作成したアセットのIDを移入します。

Asset APIは、AssetDataManager.newAssetData メソッドとinsertメソッドを組み合せることで、新規フレックス・アセットを作成できます。newAssetDataメソッドは、nullまたは空のリスト/コレクションが移入されたすべてのAttributeDataオブジェクトとともに、空のAssetDataを返します。正しいサブタイプが指定されている場合は、flextemplateid (フレックス・アセット用)またはflexgroupid (フレックス親用)に値が自動的に移入されます。

- 新しいフレックス・アセットを作成するには、次のコードを使用します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="com.openmarket.xcelerate.asset.AssetIdImpl"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager adm = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
MutableAssetData d = adm.newAssetData( "Content_C", "FSII Article" );
d.getAttributeData( "name" ).setData( New Content" );
d.getAttributeData( "FSIIHeadline" ).setData( "headline" );
d.getAttributeData( "FSIIAbstract" ).setData( "abstract" );
d.getAttributeData( "FSIIBody" ).setData( "body" );
d.getAttributeData( "Publist" ).setData( Arrays.asList( "FirstSiteII" ) );
d.setParents( Arrays.<AssetId>asList( new AssetIdImpl( "Content_P", 1112192431478L)) );
adm.insert( Arrays.<AssetData>asList( d ));
out.println( d.getAssetId() );
%>
</cs:ftcs>

- Asset APIは、新規ベーシック・アセットを作成することもできます。新しい基本アセットを作成するには、次のコードを使用します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager adm = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
MutableAssetData d = adm.newAssetData( "HelloArticle", "" );
d.getAttributeData( "name" ).setData( New Hello Article" );
d.getAttributeData( "headline" ).setData( "headline" );
d.getAttributeData( "byline" ).setData( "abstract" );
d.getAttributeData( "category" ).setData( "g" );
BlobObject b = new BlobObjectImpl( "filename.txt", null, "body".getBytes() );
d.getAttributeData( "urlbody" ).setData( b );
d.getAttributeData( "Publist" ).setData( Arrays.asList( "HelloAssetWorld" ) );
adm.insert( Arrays.<AssetData>asList( d ));
out.println( d.getAssetId() );
%>
</cs:ftcs>

77.5.2 既存のアセットの更新

Asset APIでは、挿入に加えて、更新の操作もサポートされています。挿入と同様に、更新操作では、AssetDataのデータがWebCenter Sites内に保存されますが、既存のアセットが対象になります。そのアセットが存在しない場合は、更新操作により、例外がスローされます。

既存のアセットを更新するには、次のコードを使用します。

<%@ page import="com.openmarket.xcelerate.asset.AssetIdImpl"%>
<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager adm = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
Iterable<AssetData> assets = adm.read( Arrays.<AssetId>asList( new AssetIdImpl( "HelloArticle", 1238171255471L), new AssetIdImpl( "Content_C", 1238171254486L)) );
List<AssetData> sAssets = new ArrayList<AssetData>();
for ( AssetData a : assets )
{
sAssets.add( a );
a.getAttributeData( "name" ).setData( "Changed Name" );
}
adm.update( sAssets );
%>
</cs:ftcs>

77.5.3 既存のアセットの削除

Asset APIは、WebCenter Sitesからのアセットの削除もサポートしています。

WebCenter Sitesアセットを削除するには、次のコードを使用します。

2つのアセットに対するすべての参照を削除した後に、adm.deleteによって両方のアセットをWebCenter Sitesから削除できます。いずれかのアセットが他のアセットによって参照されている場合や、そのアセットが無効な場合は、例外がスローされます。例外がスローされると、削除プロセスは停止します。

<%@ page import="com.openmarket.xcelerate.asset.AssetIdImpl"%>
<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.assetapi.query.*"%>
<%@ page import="java.util.*"%>
<cs:ftcs>
<%
Session ses = SessionFactory.getSession();
AssetDataManager adm = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
adm.delete( Arrays.<AssetId>asList( new AssetIdImpl( "HelloArticle", 1238171255471L), new AssetIdImpl( "Content_C", 1238171254486L)) );
%>
</cs:ftcs>

77.5.4 多言語アセット

Asset APIは、多言語アセットの作成をサポートしています。多言語アセットを作成するには、2段階のプロセスを実行する必要があります。まず、そのアセットを作成して保存します。次に、ロケール情報を追加します。

次の例を使用して、新しいContent_Cアセットを作成して、そのロケールをen_USに設定します。

<%@ page import="com.fatwire.system.*"%>
<%@ page import="com.fatwire.assetapi.data.*"%>
<%@ page import="com.fatwire.mda.*"%>
<%@ page import="com.fatwire.mda.DimensionableAssetInstance.
DimensionParentRelationship"%>
<%@ page import="java.util.*"%>
<%@ page import="com.openmarket.xcelerate.asset.*"%>
<%@ page import="com.openmarket.xcelerate.common.*"%>
<cs:ftcs>

<%
Session ses = SessionFactory.getSession();

AssetDataManager adm = (AssetDataManager) ses.getManager( AssetDataManager.class.getName() );
MutableAssetData d = adm.newAssetData( "Content_C", "FSII Article" );
d.getAttributeData( "name" ).setData( New Content" );
d.getAttributeData( "FSIIHeadline" ).setData( "headline" );
d.getAttributeData( "FSIIAbstract" ).setData( "abstract" );
d.getAttributeData( "FSIIBody" ).setData( "body" );
d.getAttributeData( "Publist" ).setData( Arrays.asList( "FirstSiteII" ) );
d.setParents( Arrays.<AssetId>asList( new AssetIdImpl( "Content_P", 1112192431478L)) );
adm.insert( Arrays.<AssetData>asList( d ));
DimensionManager dam = (DimensionManager)ses.getManager(DimensionManager.class.getName());
Dimension dim = dam.loadDimension("en_US");
d.getAttributeData("Dimension") .setData(Arrays.asList(new Dimension[]{dim}));
DimensionParentRelationship dpr = new DimParentRelationshipImpl("Locale", d.getAssetId());
d.getAttributeData("Dimension-parent").setData(Arrays.asList(new DimensionParentRelationship[]{dpr}));
adm.update( Arrays.<AssetData>asList( d ));
%>
</cs:ftcs>

77.6 開発戦略

この項では、データ型と属性データ(これにより、WebCenter Sitesデータ型をJava型にマップします)とともに、問合せのタイプ(問合せのタイプ、それらの使用方法、およびサポートされている演算を比較します)について説明します。

この項には次のトピックが含まれます:

- データ型と属性データ

- 問合せのタイプ

- データ型と有効な問合せ演算

77.6.1 データ型と属性データ

AttributeDataには、データ型(WebCenter Sites固有の型)に関する情報と実際のデータが含まれています。これらの型は、AttributeTypeEnumで定義されています。AttributeData.getData()とAttributeData.getDataAsList()は、特定のJava型のデータ・オブジェクトを返します。

表77-1に、WebCenter Sitesの型と対応するJava型のマッピングを示します。

表77-1 WebCenter Sitesのデータ型とJava型

WebCenter Sitesのデータ型

Java型

INT

Integer

FLOAT

Double

STRING

String

DATE

Date

MONEY

Double

LONG

Long

LARGE_TEXT

String

ASSET

AssetId

BLOB

BlobObject

77.6.2 問合せのタイプ

Asset APIを使用すると、汎用/ベーシックとフレックスという2種類の問合せを実行できます。

2種類のアルゴリズムが存在し、一方では汎用アセット・インフラストラクチャが使用され(汎用/ベーシック問合せ)、もう一方ではアセットセットと検索状態が使用されます(フレックス問合せ)。汎用/ベーシック問合せは、フレックス・アセットとベーシック・アセットの両方に使用できますが、フレックス問合せはフレックス・アセットにしか使用できません。

これらの各アルゴリズムには、メリットとデメリットがあります。Asset APIの目標は、問合せメカニズムを統一して、最終的にはAsset APIのユーザーがアルゴリズムを選択する必要性をなくすことです。ただし現時点では、これらのアルゴリズムは同等ではないため、ユーザーはこれら2つのアルゴリズムのうち一方で提供されている特定の機能を希望する場合は、そのアルゴリズムを選択する必要があります。

QueryProperties.setIsBasicSearch( true )は、この問合せの汎用/基本検索を行うための問合せアルゴリズムを設定します。デフォルトではfalseに設定されます。ベーシック・アセットの場合、設定は問題になりません。

どちらのタイプの問合せを選択すればよいでしょうか。簡単に言うと、フレックス・アセットのベーシック属性を検索する場合は、ベーシック問合せを使用します。そうでない場合は、デフォルト問合せを使用します。これは、一般に使用されるほとんどの問合せに対応できます。状況はこれよりもやや微妙です。次に、各タイプの問合せに対する他の制約事項を示しています。

ベーシック/汎用問合せ

- サブタイプを指定しない場合は、フレックス属性に基づいて検索することはできません。

- フレックス定義に含まれていないフレックス属性に基づいて検索することはできません。

- フレックス属性に基づいてソートすることはできません。

- 大文字と小文字が区別されることは保証されません(データベースに依存します)。

- AND演算は、異なるフィールド間のみで許可されます(たとえばname=name1 AND description=descr1 は許可されますが、name=name1 AND name=name2は許可されません)。

- OR演算は、同じフィールド名が使用された2つの条件についてのみ許可されます。OR条件は、フレックス属性については無効です。

フレックス問合せ

- 条件にベーシック属性を含めることはできません(id、name、descriptionなど)。

- ベーシック属性に基づいてソートすることはできません。

- フレックス問合せは、サブタイプが指定されていなくても機能します。その場合は、すべてのサブタイプのデータが検索対象になります。

- 条件で使用できる演算子は、LIKE、EQUALS、BETWEENおよびRICHTEXTのみです。

77.6.3 データ型と有効な問合せ演算

実行する問合せのタイプに応じて、特定のデータ型について許可される演算のタイプに関するさらなる制約が存在します。

一般に、フレックス・タイプ問合せ(フレックス・アセットのデフォルト問合せ)で許可されるOpTypeEnumsは、LIKE、EQUALS、BETWEENおよびRICHTEXTのみです。AssetSet/SearchStateタグからも同じ操作を実行できる点に注意してください。

他のOpTypeEnumsを使用するには、ベーシック/汎用問合せを使用する必要があります(そのためにはQueryProperties.setIsBasicSearch( true )を設定します)。このような問合せは、当然ながら、前述のベーシック問合せのルールに従う必要があります。

表77-2では、ベーシック/汎用問合せで各データ型(単一値または複数値)について許可されている演算を示しています。

表77-2 許可される演算のセット

データ型

EQUALS

NOT_EQUALS

LIKE

GREATER

LESSTHAN

BETWEEN

RICHTEXT

INT

可

可

不可

可

可

–

不可

FLOAT

可

可

不可

可

可

–

不可

STRING

可

可

可

可

可

–

不可

DATE

可

可

不可

可

可

–

不可

MONEY

可

可

不可

可

可

–

不可

LONG

可

可

不可

可

可

–

不可

LARGE_TEXT

不可

不可

可

不可

不可

–

不可

ASSET

可

可

不可

不可

不可

–

不可

BLOB

不可

不可

不可

不可

不可

–

不可

表77-3では、フレックス・タイプ問合せで各データ型(単一値または複数値)について許可されている演算を示しています。

表77-3 データ型ごとに許可される演算のセット

データ型

EQUALS

NOT_EQUALS

LIKE

GREATER

LESS THAN

BETWEEN

RICHTEXT

INT

可

–

不可

–

–

可

不可

FLOAT

可

–

不可

–

–

可

不可

STRING

可

–

可

–

–

可

不可

DATE

可

–

不可

–

–

可

不可

MONEY

可

–

不可

–

–

可

不可

LONG

可

–

不可

–

–

可

不可

LARGE_TEXT

不可

–

可

–

–

不可

可

ASSET

可

–

不可

–

–

可

不可

BLOB

不可

–

不可

–

–

不可

可

77.7 オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定

このチュートリアルでは、JSPテンプレートからAsset APIを使用する方法を紹介していますが、スタンドアロンJavaプログラムからAsset APIを使用することもできます。そのためには、単一のデータベース接続または接続プールを設定します(WebCenter Sitesの外部で)。

注意:

次の手順では、すべてのコンポーネントがインストール済のWebCenter Sitesに対してローカルであると想定しています。

単一のデータベース接続またはデータベース接続プールを設定する前に:

1. 次のファイルがJavaプログラムのクラスパス内に存在していることを確認します。

- javaee.jarとtools.jar (どちらもJDK 1.5以降に付属しています)。

- ServletRequest.properties。このファイルは、WEB-INF/classesフォルダからコピーできます。

- SSOConfig.xml。ただし、WebCenter SitesインストールにWEMがインストールされており、シングル・サインオン(wcs_properties.json内)がtrueに設定されていることが前提です。SSOConfig.xmlファイルは、WEB-INF/classesフォルダからコピーできます。

- cs-cache.xml、ss-cache.xml、linked-cache.xmlおよびcas-cache.xml。

- SitesSecurityContext.xml。このファイルは、WEB-INF/classesフォルダからコピーできます。

- WebCenter Sitesのすべてのバイナリ・ファイル(WEB-INF/libフォルダ内のjarファイル)。

2. 次のどちらかの手順に進みます。

- 単一のデータベース接続を設定するには::

- データベース接続プールを設定するには::

単一のデータベース接続を設定するには::

1. Javaプログラムの次のシステム・プロパティを設定します。

cs.dburl=<JDBC_URL_to_connect_to_DB>
cs.dbdriver=<driverClass>
cs.dbuid=<dbUserName>
cs.dbpwd=<dbPassword>

2. WebCenter Sitesのインストール・フォルダを確認して、そのフォルダ名をJVM引数として渡します。

-Dcs.installDir=<install_dir>

データベース接続プールを設定するには::

1. 次のjarファイルをクラスパスに追加します。commons-dbcp.jarファイル(WebCenter Sitesに付属)、およびcommons-pool.jarファイル(Apache Webサイトから入手可能)。

2. データ・ソースと同じ名前のプロパティ・ファイルを作成します。

次の点に注意してください。

- データ・ソースの名前は、cs.dsnプロパティ(wcs_properties.json内)の値です。

- cs.dbconnpictureの値(同じくwcs_properties.json内)は、cs.dsnを参照している必要があります(cs.dbconnpictureとcs.dsnの組合せによって有効なリソースを得る必要があります)。
たとえば、次の組合せによって

cs.dsn= csDataSourceおよび

cs.dbconnpicture= java\:comp/env/$dsn

次の有効なリソースが得られます。

java:/csDataSource

したがって、プロパティ・ファイルにはcsDataSource.properties (cs.dsnの値)という名前を付けます。

- 作成するプロパティ・ファイルは、必ずJavaプログラムのクラスパス内に配置してください。

3. プロパティ・ファイルを作成したら、このファイルに次のキーを追加します。

driver=<driverClass>
url=<JDBC_URL_to_connect_to_DB>
maxconnections=<number_of_connections_to_pool>
user=<dbUserName>
password=<dbPassword>

4. WebCenter Sitesのインストール・フォルダを確認して、そのフォルダ名をJVM引数として渡します。

-Dcs.installDir=<install_dir>

78 パブリック・サイト検索の使用

WebCenter Sitesには、検索索引の管理用に新しいフレームワークがあります。このフレームワークは、編集インタフェースとライブ・サイトの両方における検索の基盤を構成します。ライブ・サイトとは訪問者側のことです。そのため、パブリック・サイト検索という名前が付いています。

パブリック・サイト検索の詳細は、次の項を参照してください。

- 検索フレームワークについて

- 索引タイプ

- 検索APIについて

- 詳細構成

78.1 検索フレームワークについて

注意:

主に検索APIの使用方法に関心がある場合は、この項を省略できます。

図78-1は、検索エンジンの統合フレームワークが、WebCenter Sitesの他の部分とどのように連携するかを表しています。

図78-1 検索エンジンの統合

検索フレームワークは、検索API、特別なアセット・イベント・リスナー、キューのポーリング・システムで構成されています。このフレームワークは、イベント管理フレームワークおよびキュー管理フレームワークと共同で使用されます。このドキュメントでは、主に検索フレームワークについて説明します。

1. アセット・フレームワークは、アセットへの変更や追加を検出し、イベントを送信します。

2. 登録されているリスナーは、永続キューの実装を使用して、変更をキューに入れます。任意のイベントは、1つまたは多数の永続キューに入れることができます。各キューは、検索索引用データのソースと見なすことができます。

3. アセット・イベントがキューに入れられると、バックグラウンド・プロセスがキューの内容を空にして検索APIにルーティングします。

4. 検索APIは、適切な(構成可能な)検索エンジン・ベンダーの実装を選択し、索引付けプロセスを開始します。

78.2 索引タイプ

WebCenter Sitesでは、Global索引とAssetType索引という2つのタイプの索引が作成されます。Global索引は、すべてのデータ(Global索引に対して有効化されたすべてのアセット・タイプ)の索引です。複数のアセット・タイプでフレーズや式を検索する場合(Googleのような検索インタフェースの作成を試みるなど)、Global索引はより適切です。

Global索引には、索引のすべてのフィールドのデータが含まれますが、パラメータ検索に適した形式ではデータは格納されません。AssetType索引には、特定のアセット・タイプの索引付けされた情報が、パラメータで検索可能な方法で格納されています。Adminインタフェースは、アセット・タイプ検索の構成をサポートしています(索引付け可能なアセット・タイプの属性ベース検索を含む)。検索構成オプションの詳細は、『Oracle WebCenter Sitesの管理』参照してください。

この項には次のトピックが含まれます:

- Global索引

- アセット・タイプ索引

78.2.1 Global索引

Global索引は、グローバル検索のUIを作成するためにOracle WebCenter Sites: Contributorインタフェースで使用されます。索引のインスタンスは配信サーバーにも存在します。配信サーバーの索引はパブリック・サイト検索の作成に使用できます。

検索が構成された後に、ライブ・サイトにパブリッシュされたアセットのみを検索できます。データは、パブリッシュ時に索引付けされます。検索が構成される前にライブ・サイト上に存在していたすべてのアセットは、(アセットがライブ・サイトで再度索引付けされるまで)Global索引には反映されません。

検索索引機能はおおむねデータベース表に類似しています。

表78-1では、Global索引のフィールドについて説明します。

注意:

フィールド名では、大文字と小文字が区別されます。

表78-1 Global索引のフィールド

フィールド名

説明

defaultSearchField

これには、索引が付けられたアセットのデータがすべて含まれます。これは、全文検索で検索対象とするフィールドです。

これには、アセットのすべての属性の索引データが含まれます(バイナリ・フィールド・データも含む)。すべての属性のデータがこの単一フィールドにマージされ、索引が付けられます。索引自体にはこのフィールドのデータは格納されませんが、全文検索は可能です。

注意: 検索文字列は、大文字ではなく、小文字のみで入力する必要があります。

id

これにはアセットIDが含まれます。

AssetType

これにはアセット・タイプ(Content_C/Product_P)が含まれます。

locale

これには、ロケール文字列(たとえば、en_US)が含まれます。

name

これには、アセットの名前が含まれます。

description

アセットに関連付けられた説明。

subtype

サブタイプの名前(フレックス定義名)。

subtypeid

サブタイプのID (フレックス定義ID)。

updateddate

索引付けの時点で検出された最終更新日。

siteid

このアセットが使用できるすべてのサイトのID。

startdate

アセット表の開始日フィールド。

enddate

アセット表の終了日フィールド。

78.2.2 アセット・タイプ索引

アセット・タイプ索引は、Adminインタフェースから「管理」タブ→「検索」→「アセット・タイプ検索の構成」を選択して有効化されると作成されます。アセット・タイプが有効化されると、/shared/lucene/<アセット・タイプ名>の下に索引が作成されます。この索引には、索引のフィールドとして指定されたタイプの属性がすべて含まれます。

表78-2では、Content_C索引のフィールドについて説明します。

注意:

フィールド名では、大文字と小文字が区別されます。

表78-2 アセット・タイプ索引のフィールド

フィールド名

説明

DefaultSearchField

これには、索引が付けられたアセットのデータがすべて含まれます。これは、全文検索で検索対象とするフィールドです。

これには、アセットのすべての属性の索引データが含まれます(バイナリ・フィールド・データも含む)。すべての属性のデータがこの単一フィールドにマージされ、索引が付けられます。

索引自体にはこのフィールドのデータは格納されませんが、全文検索は可能です。

注意: 検索文字列は、大文字ではなく、小文字のみで入力する必要があります。

id

これにはアセットIDが含まれます

AssetType

これにはアセット・タイプ(Content_C/Product_P)が含まれます

locale

ロケール文字列(例、en_US)が含まれます

name

アセットの名前

description

アセットに関連付けられた説明

subtype

サブタイプの名前(フレックス定義名)

subtypeid

サブタイプのID (フレックス定義ID)

updateddate

索引付けの時点で検出された最終更新日。

siteid

このアセットが使用できるすべてのサイトのID

startdate

アセット表の開始日フィールド

enddate

アセット表の終了日フィールド

Dimension

ディメンションのID

Dimension-parent

ディメンション親のID

createdby

このアセットを作成したユーザー名

createddate

アセットが作成された日付

Publist

このアセットが属するサイト名のリスト

Relationships

関連アイテムのアセットID(フレックスのみ)

externaldoctype

未使用

filename

静的パブリッシュで使用されるファイル名

flextemplateid

フレックス定義のID(フレックスのみ)

fw_uid

このアセットのグローバルに一意のID

path

静的パブリッシュで使用されるパス

renderid

フレックス・アセットに割り当てられたテンプレート・アセットのオブジェクトID。

ruleset

ルールセットのXML文書

status

アセットに関連付けられたステータス

subtype

サブタイプ名

subtypeid

サブタイプのID (フレックスのみ)

template

テンプレート名

updatedby

このアセットを最終更新したユーザー名

updateddate

最終更新日

urlexternaldoc

未使用

urlexternaldocxml

未使用

FSIIAbstract

フレックス属性

FSIIBody

フレックス属性

FSIIByline

フレックス属性

FSIIDescriptionAttr

フレックス属性

FSIIHeadline

フレックス属性

FSIINameAttr

フレックス属性

FSIIPostDate

フレックス属性

FSIISubheadline

フレックス属性

FSIITemplateAttr

フレックス属性

どのフィールドが索引で使用できるかを視覚化するには、次に示すアドレスから入手できるツールLukeを使用します。

http://www.getopt.org/luke/

このツールを起動すると、ツールの参照機能を使用して、索引(例: ../shared/lucene/Content_C)を含むフォルダを検索するだけで索引をロードできます。

78.3 検索APIについて

この項には次のトピックが含まれます:

- SearchEngine

- QueryExpression

- 問合せ式の構成

78.3.1 SearchEngine

SearchEngineインタフェースは、検索エンジンの実装の重要な機能である索引付けと検索を定義します。使用可能なSearchEngineの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

- 検索データのソースはSearchEngineに提供されます。SearchEngineは、索引付けリクエストに応じて検索索引を作成し(作成されていない場合)、IndexSourceのアクセッサに基づいてコンテンツを更新します。

- index()は、任意のIndexSourceインスタンスから操作します。検索エンジンの実装詳細に応じて、IndexSourceから取得する新規データ、修正データ、削除データを操作します(ほとんどの検索エンジンでは、修正されるすべてのものは最初に削除し、再度索引を付ける必要があります)。
index()は、IndexSourceの任意のインスタンスで索引ライフサイクル・メソッド(startIndexing()とendIndexing())も起動します。

- search()は、1つまたは多数の索引(IndexSources)に対してQueryExpressionで動作します。1つの結果セットが得られ、関連性(または、指定されている場合や複数の索引で使用可能な場合はSortOrder)を基準にソートされます。

- 必要に応じて、構成検索インタフェース(IndexSourceConfig)が、IndexSourceのプロパティを検索できるSearchEngineインスタンスに提供されます。

- QueryConverterインタフェースがSearchEngineに提供されます。このインタフェースはQueryExpressionをネイティブ・フォームに変換します(特定の検索エンジンで認識できます)。これにより、検索エンジンが外部で使用する問合せ言語を制御できます。

- SearchResultは、検索エンジンから返される結果を抽象化したものです。SearchResultは、IndexRowのサブクラスであるResultRowのイテレータで、関連性情報が含まれています。getRelavence()メソッドは倍精度実数を返します。値が大きいほど、特定の問合せに対するこのResultRowの関連性は高くなります。

78.3.2 QueryExpression

QueryExpressionインタフェースは、検索条件を定義するための汎用インタフェースです。すべての検索エンジンが、問合せを作成するためのネイティブ・フォーマットをサポートしています。ネイティブ・フォームにはワイルドカードの定義、関連性のヒントなどが含まれます。これらは、検索エンジンごとに固有となる傾向があります。

検索エンジンは基本の問合せ構成も提供し、プログラム的に作成できます(フィールド一致に関するAND & OR)。制限はありますが、これらは一般化されたプログラム可能なインタフェースという観点で考えることができます。

QueryExpressionは、次に示す、検索エンジンの問合せの4種類の特性をカプセル化します。

- ネイティブ・テキスト検索フォーマット: ほとんどの検索エンジンは、検索用の非常に高度なネイティブ・フォーマット(ワイルド・カードや特別なヒントなどを含む)をサポートします。これは、getStringFormat()を通じて使用できます。

- 論理積と論理和: and()メソッドとor()メソッドを使用する条件のANDとOR。

- ページ区切り: getStartIndex()メソッドとgetMaxResults()メソッドを使用。

- ソート: getSortOrder()を使用。

78.3.3 問合せ式の構成

1. 検索索引付けが有効化されていることを確認します。

SystemEvents表で、SearchIndexEventが有効である(enabled field =1)ことを確認します。これはバックグラウンドで常に実行されるように構成されます(*:*:* */*/*)。実際には、約30秒ごとに実行されます。

2. アセット・リスナーが登録されていることを確認します。

アセットは、アセット・イベントを使用して検索フレームワークで処理するためにキューに入れられます。アセット・イベントは、AssetListener_reg表に登録されています。エントリが表78-3に存在していることを確認します。存在していない場合は追加します。

表78-3 AssetListener_reg表

ID

リスナー

ブロッキング

1153937286234

com.openmarket.basic.event.SearchAssetIdEventListener

はい

IndexSourceMetaDataConfig: IndexSource用の構成情報を格納する表。これは索引自体の構造と性質を説明します。これには、デフォルトでGlobal用の行が必要です。アセット・タイプ索引用に有効化されたどのアセット・タイプも、この表に行を追加します。

SearchEngineMetaDataConfig: 検索エンジンの構成を格納します。この表には、デフォルトではLucene用の行が必要です。

これらはインストーラで正しく構成され、Adminインタフェースで管理されます。

デフォルトはこれで十分です。構成の正確な定義と意味の詳細は、「詳細構成」を参照してください。

78.4 詳細構成

次の各項では、特定の状況で必要になる詳細構成の側面を説明します。ただし、ほとんどの場合、デフォルトで十分です。

この項には次のトピックが含まれます:

- Luceneパラメータの構成

- カスタムAnalyzerFactoryの構成

78.4.1 Luceneパラメータの構成

注意:

一部のパラメータは、索引が実行時に行う方法で重大な変更を引き起こす可能性があります。Luceneのドキュメントを参照し、検証を信頼して、サイトの最適な設定を決定します。デフォルトを変更する特別な理由がない場合は、デフォルトのままにしておくことを強くお薦めします。

Lucene検索エンジンでは、索引の作成方法と実行方法を決定する特定の一連のパラメータで索引を作成できます。Luceneのデフォルトのパラメータは合理的ですが、WebCenter Sitesには、それらを変更する方法が管理者用に用意されています。

SearchEngineMetaDataConfig表では、索引ごとに1行が含まれます。各行には、コンテンツがLuceneパラメータの構成に使用される、propertiesという名前のフィールドがあります。次に示すように、パラメータ値のペアはセミコロン(;)で区切られます。

param1=value1;param2=value2

表78-4では、WebCenter Sitesでサポートされているパラメータについて説明します。

表78-4 WebCenter Sitesでサポートされているパラメータ

パラメータ

型

説明

mergeFactor

Integer

セグメント索引がマージされる頻度を決定します。

値が小さければ、索引付け中に使用されるRAMは少なく、最適化されていない索引の検索は速くなりますが、索引付けのスピードは遅くなります。

値が大きければ、索引付け中に使用されるRAMは多く、最適化されていない索引の検索は遅くなりますが、索引付けは速くなります。そのため、より大きい値(> 10)がバッチ索引作成に適しており、より小さい値(< 10)は対話型で維持される索引に適しています。

これは2より小さくしないでください。デフォルト値は10です。

maxMergeDocs

Integer

これまでにマージされたドキュメントの最大数を決定します。小さい値(たとえば、10000より小さい)が対話形式の索引付けに最適なのは、これが索引付けの一時停止の長さを数秒に制限するためです。大きい値はバッチ索引付けと高速検索に最適です。

デフォルトは最大整数値(231-1)。

maxBufferedDocs

Integer

バッファされたインメモリー・ドキュメントのマージ中や新規のセグメントが作成される前に必要とされるドキュメントの最小数を決定します。

デフォルトは10。

optimizeInterval

Integer

optimize()コール間の時間間隔(秒単位)を決定します。デフォルト値は30秒です。これは、ほとんどのシステムでの推奨値です。大幅にデータを変更する場合は、このパラメータを300から600秒までの範囲の値に設定します。

commitLockTimeout

Long

コミット・ロックまで待機する最大時間を設定します(ミリ秒単位)。

デフォルトは10000。

maxFieldLength

Integer

ドキュメントの1つのフィールドに索引付けされる用語の最大数。これは索引付けに必要なメモリーの容量を制限します。これにより、非常に大きなファイルのコレクションの索引付けプロセスがメモリー不足によってクラッシュする事態を防げます。

これは大きなドキュメントを効果的に切り捨て、ドキュメントにさらに付けられる索引用語から削除することに注意してください。大きいソース・ドキュメントをサポートするには、見込まれるサイズを格納できるようにこの値を大きく設定します。それを整数の最大値(231-1)に設定する場合、制限があるのはメモリーのみであるため、OutOfMemoryErrorを想定しておく必要があります。

デフォルトでは、10000より多い用語はフィールドに索引付けされません。

termIndexInterval

Integer

索引付けされた用語間の間隔を設定します。大きい値ではIndexReaderで使用されるメモリーが少なくなりますが、用語へのランダムアクセスは遅くなります。小さい値ではIndexReaderで使用されるメモリーが多くなるため、用語へのランダムアクセスが速くなります。

このパラメータは、問合せ用語を含むドキュメントの数に関係なく、問合せ用語ごとに必要な計算量を決定します。特に、用語を特定して、その頻度と位置の情報を処理する前に、スキャンする必要のあるその他の用語の最大数となります。

ユーザー入力の問合せ用語を指定したサイズの大きい索引では、問合せ処理時間の大半が、用語参照ではなく、頻度データと位置データの処理によって占められる可能性があります。サイズの小さい索引の場合、または一般的でない問合せ用語が多数生成される場合(ワイルドカード問合せなど)は、処理時間の大半が用語参照によって占められます。特に、IndexReaderではnumUniqueTerms/interval(一意の用語数/時間間隔)用語がメモリーに読み込まれ、平均すると、ランダムな用語アクセスごとにinterval/2terms(時間間隔/2つの用語)をスキャンする必要があります。

デフォルト値は128。

useCompoundFile

String (yesまたはnoである必要があります)

複合ファイルの使用をオンにするための設定。オンの場合、セグメントの作成が終了すると、各セグメントの複数のファイルが1つのファイルにマージされます。

writeLockTimeout

Long

書込みロックまで待機する最大時間を設定します。

デフォルト値は1000。

78.4.2 カスタムAnalyzerFactoryの構成

Luceneでは、アナライザがテキストから索引用語を抽出するためのポリシーを表します。アナライザは、索引付け時や、中止語句の削除や空白の削除などの様々なタスクの検索時に使用されます。

異なるアナライザが、様々なロケールを処理するためにLuceneリポジトリに存在します。多くの場合、アナライザはシノニムの注入やアクセント付き文字の正常な処理に使用されます。また、Luceneの標準アナライザのいずれかをベースに使用して、独自のアナライザを構築することもできます。

WebCenter SitesのLuceneの実装は、英語用の汎用目的アナライザであるStandadAnalyzerを使用します。ただし、WebCenter Sitesはプラグイン・インタフェースのAnalyzerFactoryを通じてカスタム・アナライザをサポートします。構成されたAnalyzerFactoryは、索引付けまたは検索のプロセスで必要な場合にアナライザの検索に使用されます。AnalyzerFactory は、次の場合にアナライザを検索します。

- 索引全体の作成時

- 問合せの解析時

- 個々の行の索引付け時

カスタムAnalyzerFactoryをプラグインするには、AnalyzerFactoryインタフェースを実装して登録する必要があります。登録は、SearchEngineMetaDataConfig表で行を変更して実行します。「名前」フィールドがLuceneに設定されている行のpropertiesフィールドに、次のものを追加します。

AnalyzerFactory=<fully qualified class name of your custom AnalyzerFactory>

第XX部 Oracle WebCenter Sitesコアの付録

この部では、Webサイトの開発および保持を行う際に、WebCenter Sitesのブラウザ・ベースのインタフェースとともに使用できるWebCenter Sitesのツールとユーティリティについて最初に説明します。次に、不要な空白を圧縮して、レスポンスのサイズおよび帯域幅の消費量どのように減らすことかできるかについて説明します。最後に、WebCenter SitesのURLアセンブラを使用して、URLアセンブリとURL逆アセンブリを管理し、URLの表示の定義にどのように使用できるかについて説明します。

この部は、次の付録で構成されています。

- WebCenter Sitesのツールおよびユーティリティの概要

- 空白と圧縮の理解

- WebCenter SitesのURLアセンブラの使用

79 WebCenter Sitesのツールおよびユーティリティの概要

WebCenter Sitesには、Webサイトの開発および保持を行う際に、WebCenter Sitesのブラウザ・ベースのインタフェースとともに使用する各種ツールおよびユーティリティが用意されています。

WebCenter Sitesのツールおよびユーティリティの詳細は、次の項を参照してください。

- Oracle WebCenter Sites Explorer

- WebCenter Sitesデータベースへの接続

- CatalogMover

- プロパティ管理ツール

- XMLPostを使用したインポートについて

79.1 Oracle WebCenter Sites Explorer

Oracle WebCenter Sites Explorerツールは、Microsoft Windowsのアプリケーションで、WebCenter Sitesデータベースにおける表および行の表示と編集を行ったり、XMLまたはJSPで記述された実行可能エレメント(またはファイル)の作成と編集を行ったりするためのものです。Oracle WebCenter Sites Explorerは、次の処理のために使用します。

- 表にエントリを追加する

- 表内の行を編集する

- 表の行のリビジョンを追跡する

- WebCenter Sitesの表を作成および削除する

- 表およびフォルダをプロジェクトに編成する

- ブラウザでSiteCatalogレコードをページとしてプレビューする

- 統合された.cseタイプのファイルとしてレコードをエクスポートおよびインポートする

- .zipファイルで表およびプロジェクトをエクスポートおよびインポートする

Oracle WebCenter Sites Explorerは、WebCenter Sitesとともにインストールされます。

79.2 WebCenter Sitesデータベースへの接続

WebCenter SitesがインストールされているコンピュータにあるOracle WebCenter Sites Explorerディレクトリ(<domain home>/wcsites/clients/oracle.wcsites.explorer.zip)をリモート・コンピュータ上のディレクトリにコピーするのみで、いずれのリモートMicrosoft WindowsコンピュータでもOracle WebCenter Sites Explorerを使用できます。次に、oracle.wcsites.explorer.zipを解凍し、Oracle WebCenter Sites Explorer実行可能ファイル(ContentServerExplorer.exe)を実行します。ユーザー名、パスワード、ホスト名、ポートおよびプロトコル情報を指定してWebCenter Sitesにログインします。

WebCenter Sitesを実行しているシステムに接続するには:

1. Oracle WebCenter Sites Explorerを起動します。

2. 「ファイル」→「WebCenter Sitesを開く」を選択すると、「ログイン」ダイアログ・ボックスが表示されます。

3. 次の値を入力します。

名前: WebCenter Sitesのユーザー名。

パスワード: WebCenter Sitesのパスワード。(サイトのセキュリティによっては、名前とパスワードの入力が不要な場合もあります。)

ホスト名: ホスト名またはIPアドレス。このフィールドは空白にできません。

ポート: ポート番号(デフォルトは80)。

プロトコル: 通常はHTTP。WebサーバーがSSLを実行している場合はHTTPSを選択できます。

アプリケーション・サーバーのURLパス: サイトのアプリケーション・サーバーのタイプ。

4. 「OK」をクリックしてログインします。

Oracle WebCenter Sites Explorerユーティリティが開きます(図79-1)。

図79-1 Oracle WebCenter Sites Explorer

Oracle WebCenter Sites ExplorerへのショートカットをWindowsデスクトップに作成することもできます。Oracle WebCenter Sites Explorerの使用手順は、Oracle WebCenter Sites Explorerのオンライン・ヘルプ、およびこのマニュアルでOracle WebCenter Sites Explorerを必要とする具体的なタスクを記述している項を参照してください。

79.3 CatalogMover

CatalogMoverツールは、ElementCatalog表やSiteCatalog表など、WebCenter Sitesデータベースの表をエクスポートおよびインポートするために使用します。たとえば、CatalogMoverを使用すると、ページ・エレメントおよびコンテンツ・アセットを1つのシステムにエクスポートし、同じエレメントおよびアセットを別のシステム上のデータベースにロードできます。エクスポートおよびインポートするデータベース表は、HTMLファイルとZIPファイルのいずれにしてもかまいません。

CatalogMoverは、次の各項で説明するWindowsインタフェースを通じて使用することも、「コマンドライン・インタフェース」で説明するコマンドライン・インタフェースを通じて使用することもできます。

注意:

以前のバージョンのWebCenter Sitesでは、WebCenter Sitesデータベースの表はカタログと呼ばれていました。この用語は引き続き、一部のデータベース表の名前、およびCatalogMoverツール自体に該当しています。

この項には次のトピックが含まれます:

- CatalogMoverの起動

- WebCenter Sitesへの接続

- CatalogMoverのメニュー・コマンド

- 「カタログ」メニュー

- 表のエクスポート

- 表のインポート

- コマンドライン・インタフェース

79.3.1 CatalogMoverの起動

CatalogMoverを起動するには、MS DOSプロンプトまたはUNIXシェルで次のスクリプトを実行します。

- Windows: catalogmover.bat

- Solaris: catalogmover.sh
CatalogMoverユーティリティが開きます(図79-2 )。

図79-2 CatalogMover

79.3.2 WebCenter Sitesへの接続

CatalogMoverを使用する前に、まずWebCenter Sitesのシステムに接続しておく必要があります。

1. WebCenter Sitesに接続するには、「サーバー」、「接続」の順に選択します。

「サーバーに接続」ダイアログが開きます(図79-3)。

図79-3 「サーバーに接続」ダイアログ

2. 「サーバー」フィールドに、接続するHTTPサーバーの名前を入力します。

3. 「保護」オプションで、「いいえ」(デフォルト・ポート80)または「はい」(デフォルト・ポート443)を選択します。ポート・フィールドに、サーバーが実行されているポート(デフォルトでない場合)を入力します。

4. 「名前」フィールドに、ユーザー名を入力します。

5. 「パスワード」フィールドに、パスワードを入力します。

6. 次のいずれかのオプションを選択します。

- 標準サーブレット: WebSphereまたはWebLogicを使用してシステムに接続する場合。

- IAS 6.0: NAS-Appシステムに接続する場合。

- CSベースのサーブレット: CSベースのサーブレットに接続する場合。

- カスタム: 別のアプリケーション・サーバーに接続する場合は、フィールドに次の値を入力します(.shスクリプトまたは.batスクリプトを参照)。
<ft.approot><ft.cgipath>/catalogmanager.

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

79.3.3 CatalogMoverのメニュー・コマンド

CatalogMoverに含まれているメニュー・コマンドは次のとおりです。

「ファイル」メニュー

- 終了: WebCenter Sitesとの接続を切断してCatalogMoverを閉じます。

「サーバー」メニュー

- 接続: 「サーバーに接続」ダイアログを表示します。

- 再接続: 「サーバーに接続」ダイアログを表示して、WebCenter Sitesの現在の接続を更新します。

- 切断: WebCenter Sitesとの接続を切断します。

- 一時表のパージ: インポート済の表をコミットする前にパージします。

- 個別の表のコミット: インポート済の表をデータベースにコミットします。

- エクスポート時にファイル名を正規化: CatalogMoverのファイル名の正規化動作を有効にします。その動作では、移動中のファイルの名前が、対応するID番号と一致する名前に変更されます。この機能が有効でない場合、ファイル名は変更されません。

「CatalogList」メニュー

- ロード: データベース内のすべての表のリストを表示します。

79.3.4 「カタログ」メニュー

- ロード: リストから表をローカル・メモリーにロードします。
図79-4は、ロードされたElementCatalog表を示しています。

図79-4 CatalogMover内のElementCatalog表

「ElementCatalog」タブを選択して、その表の中の行をすべて表示し、エクスポートする特定の行を選択します。

- リフレッシュ: WebCenter Sitesデータベースからロードされた表を更新します。

- カタログの自動インポート: 以前にエクスポートされたZIPファイルをインポートします。

- カタログのインポート: 別のWebCenter Sitesデータベースからエクスポートされた表をローカル・データベースにインポートします。

- カタログの行のエクスポート: ロードされた表に、選択した行をエクスポートします。

「選択」メニュー

- すべての行を選択: 現在表示されている表ですべての行を選択します。

- すべての行を選択解除: 現在表示されている表ですべての行を選択解除します。

- 部分文字列で行を選択: 一連の行を一意に識別する、フィールド値の任意の文字列の部分を入力することによって、現在表示されている表で行を選択します。

「ヘルプ」メニュー

- バージョン情報: インストールされているWebCenter Sitesのバージョン情報を表示します。

79.3.5 表のエクスポート

エクスポートとは、表の行およびその内容をデータベースから取得し、ローカルHTMLファイル、および関連付けられたデータ・ディレクトリに保存するプロセスです。CatalogMoverでは、表当たり1つのHTMLファイルが作成されます。

この項には次のトピックが含まれます:

- 選択した表の行のエクスポート

- エクスポート対象の行の選択

- ZIPファイルへのエクスポート

79.3.5.1 選択した表の行のエクスポート

選択した表の行をエクスポートするには、次の手順を実行します。

1. 「WebCenter Sitesへの接続」で説明しているように、WebCenter Sitesに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、「エクスポート対象の行の選択」で説明しているように行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。

ダイアログが開き、エクスポートされた行を含むHTMLファイルに対し、ディレクトリを指定するように求められます。

5. 選択したディレクトリに移動し、「保存」をクリックします。

CatalogMoverによって、選択した行が、選択したディレクトリにエクスポートされます。

79.3.5.2 エクスポート対象の行の選択

ロードされた表でエクスポート対象の具体的な行をクリックして選択することも、部分文字列を指定して具体的な行を検索することもできます。

部分文字列に従って、行を検索および選択するには::

1. 「選択」→「部分文字列で行を選択」を選択します。

Catalog Moverダイアログが開きます(図79-5)。

図79-5 Catalog Moverダイアログ

2. テキスト・フィールドに、検索する部分文字列を入力します。たとえば、主キーElementCatalogを対象として、エレメント名にfolderという文字があるすべての行を検索するには、folderと入力して「OK」をクリックします。

CatalogMoverでは、図79-6に示すように、表を検索し、その表の主キーに対する部分文字列問合せと一致する行を選択します。

図79-6 CatalogMoverの結果

注意:

部分文字列による行選択の対象となるのは、表の中で最も左にある列のみです。ただし、列の位置は変更可能なので、どの列でも最も左にある列になり得ます。そのためには、列ヘッダーをクリック・アンド・ドラッグするだけです。

79.3.5.3 ZIPファイルへのエクスポート

複数の表から複数の行を選択し、CatalogMoverの実行元であるローカル・コンピュータ上のZIPファイルにエクスポートできます。ZIPファイルを作成したら、そのファイルの内容をサーバーの表にインポートします。

CatalogMoverを使用してZIPファイルをエクスポートするには::

1. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

2. 「カタログ」→「ロード」を選択して表をロードし、「エクスポート対象の行の選択」で説明しているように行を選択します。

3. 「カタログ」→「カタログの行のエクスポート」を選択します。

「エクスポート対象のベース・ディレクトリの選択」ダイアログが開きます(図79-7)。

図79-7 「エクスポート対象のベース・ディレクトリの選択」ダイアログ

4. ZIPファイルを保存するディレクトリに移動します。

5. 「ファイル名」フィールドに、ファイルの名前を入力し、ファイル拡張子.ZIPを入力します。

6. 「保存」をクリックします。表のすべてから選択した行が、選択したディレクトリ内のZIPファイルにエクスポートされます。

79.3.6 表のインポート

インポートとは、ローカルに格納されたHTMLファイルおよび関連付けられたデータをサーバーに送信するプロセスです。インポートする特定のHTMLファイルを選択することも、HTMLファイルをすべてインポートするように選択することもできます。

この項には次のトピックが含まれます:

- 以前にエクスポートされたHTMLファイルのインポート

- 以前にエクスポートされたZIPファイルのインポート

- CatalogMoverの既存のファイルのマージ

- CatalogMoverの既存のファイルの置換

79.3.6.1 以前にエクスポートされたHTMLファイルのインポート

以前に別の表からエクスポートされたHTMLファイルをインポートするには::

1. 「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「カタログのインポート」を選択します。

4. 以前にエクスポートされた表の行を含むHTMLファイルに移動します。

5. 目的のHTMLファイルを選択して、「開く」をクリックします。

「エクスポート対象のベース・ディレクトリの選択」ダイアログが開きます(図79-7)。

6. 現在存在していない新しい表の行をインポートするには、「データ・ディレクトリのカタログ化」フィールドと「ACLリストのカタログ化」フィールドに情報を入力します。

既存の表の行をインポートされた表の行に置換する場合は、これらのフィールドを空白にしておきます。

7. 「OK」をクリックします。以前にエクスポートされたHTMLファイルに含まれている表の行が、接続先のWebCenter Sitesデータベースにインポートされます。

ダイアログが開き、インポートされた表の行が一覧表示されます。

注意:

新しい表は、接続先のサーバー上に存在しない表をインポートすると自動的に作成されます。

79.3.6.2 以前にエクスポートされたZIPファイルのインポート

CatalogMoverを使用して、エクスポートされたZIPファイルに格納されている表の行をサーバーにインポートできます。

以前にエクスポートされたZIPファイルをインポートするには::

1. データベースに接続しているときに、「カタログ」→「カタログの自動インポート」を選択します。

2. ダイアログで、表の行を以前にエクスポートしたディレクトリに移動します。ZIPファイルを表示するには、「タイプ別ファイル」メニューを「すべてのファイル」に変更します。

3. 目的のZIPファイルを選択して、「保存」をクリックします。ZIPファイルに含まれている行が、データベースに自動的にインポートされます。

79.3.6.3 CatalogMoverの既存のファイルのマージ

CatalogMoverファイルをマージするには、次のようにします。

1. 「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、「エクスポート対象の行の選択」で説明しているように、別のファイルにマージする行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。

5. 行をマージするHTMLファイルに移動します。「保存」をクリックします。

「上書き」ダイアログが開きます。

6. 「エクスポートされた既存のデータの更新」をクリックします。CatalogMoverによって、エクスポートされた行が、選択したHTMLファイルにマージされます。

79.3.6.4 CatalogMoverの既存のファイルの置換

CatalogMoverファイルを置換するには、次のようにします。

1. 「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、「エクスポート対象の行の選択」で説明しているように、別のファイルにマージする行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。

5. 行をマージするHTMLファイルに移動し、「保存」をクリックします。

「上書き」ダイアログが開きます。

6. 「エクスポートされた既存のデータの置換」をクリックします。

CatalogMoverによって、選択したHTMLファイルの行が、既存の行にマージされます。

79.3.7 コマンドライン・インタフェース

CatalogMoverでは、表79-1で説明するパラメータによって、GUIを表示しないで機能を実行できます。パラメータには、空白、さらに値を続けます。

表79-1 コマンドライン・インタフェースのパラメータ

パラメータ

説明

-h

コマンドライン・パラメータを表示します

-u username

ユーザー名

-p password

パスワード

-s servername

接続先のサーバー名

-b baseurl

次のいずれかのベースURL

http://($host)/cgi-bin/gx.cgi/AppLogic+FTCatalogManager (NAS)

または

http://($host)/servlet/CatalogManager(WebLogic)

-t table

表名: エクスポートする際に、エクスポート対象の表を指定するために使用し、複数の表をエクスポートする場合は-tパラメータを複数使用します。

-x function

実行する機能: 有効な値はimport、import_all、export、export_all。

-d directory

ディレクトリ: エクスポートの場合は、エクスポートされた表を含むディレクトリ。すべてインポートする場合は、インポートする表をすべて含むディレクトリ。

-f filename

インポートする表を含むファイル: HTMLファイルでも、エクスポートによって生成されるZIPファイルでもかまいません。

-c directory

表を作成する場合に使用されるアップロード・ディレクトリ。

-a aclone,acltwo,...

ACLリスト: 表を作成する場合に使用されるACLのカンマ区切りリスト

79.4 プロパティ管理ツール

プロパティ管理ツールには、wcs_properties.jsonファイル内のプロパティを検索、表示、変更および追加できる使いやすいフォームが用意されています。

この項には次のトピックが含まれます:

- プロパティ管理ツールへのアクセス

- プロパティの設定

- wcs_properties.jsonファイルへのプロパティの追加

79.4.1 プロパティ管理ツールへのアクセス

1. WebCenter Sitesにログインし、サイトの名前を選択し、Adminインタフェース・アイコンを選択します。

2. 「一般的な管理」ツリーで、「システム・ツール」ノードを開きます。

3. 「システム・ツール」ノードで、「プロパティ管理」をダブルクリックします。

「プロパティ管理ツール」が開きます(図79-8)。

図79-8 プロパティ管理ツール

「プロパティ管理ツール」の「検索条件」セクションを使用して、プロパティの完全名または部分名を検索できます。また、wcs_properties.jsonファイル内のプロパティに割り当てられたカテゴリ別に検索することもできます。

「検索」をクリックすると、フォームの「プロパティ」セクションに、フォームの「検索条件」セクションに入力した検索条件と一致するプロパティがすべてリストされます。

「キー」列には、プロパティの名前が表示され、「カテゴリ」列には、プロパティに割り当てられたカテゴリが表示され、「サブカテゴリ」列には、プロパティに割り当てられたサブカテゴリ(存在する場合)が表示され、「値」列には、プロパティの現在の設定先の値が表示され、「デフォルト値」列には、プロパティの推奨値が表示されます。

注意:

wcs_properties.jsonファイルには、リリース番号の文字列ft.versionが含まれており、この文字列には、4.0.0.など、WebCenter Sitesによって設定された値が含まれます。

このプロパティは変更しないでください。これは参照のみを目的としたものです。

79.4.2 プロパティの設定

システムにWebCenter Sitesのプロパティを設定するには:

1. 必要に応じて、プロパティ管理ツールを開きます。

2. 「検索条件」セクションで、次のいずれかの操作を行います。

- 「名前」フィールドに、変更するリソースの名前を入力します。

- 「カテゴリ」ドロップダウン・メニューで、wcs_properties.jsonファイル内のプロパティに割り当てられたカテゴリを選択します。

3. 「検索」をクリックします。

4. 「キー」列で、プロパティの名前を選択します。

5. 「値」フィールドで、新しい値を入力します。

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

7. 変更するすべてのプロパティに対して、手順2から6を繰り返します。

8. アプリケーション・サーバーを停止してから再起動して、変更内容を適用します。

79.4.3 wcs_properties.jsonファイルへのプロパティの追加

場合によっては、wcs_properties.jsonファイルにプロパティを追加する必要があることがあります。このような場合は、プロパティ管理ツールを使用してこのファイルにプロパティを追加します。

1. プロパティ管理ツールを開きます。

2. フォームの「検索条件」セクションで、「追加」をクリックします。

3. 新しいプロパティの値を入力します。フィールドの詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

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

5. 新しいプロパティが有効になるように、アプリケーション・サーバーを停止して再起動します。

79.5 XMLPostを使用したインポートについて

XMLPostユーティリティは、WebCenter Sitesデータベースにデータをインポートします。このユーティリティは、WebCenter SitesのFormPoster Javaクラスに基づき、WebCenter Sitesベースの製品で提供されます。これは、HTTP POSTプロトコルを使用してデータをインポートします。

アセットをインポートするには、WebCenter Sitesに付属している、ポストするエレメントとともにXMLPostを使用します。

XMLPostの使用によるアセットのインポートの詳細は、次の各章を参照してください。

- 任意タイプのアセットのインポート

- フレックス・アセットのインポート

80 空白と圧縮の理解

WebCenter Sitesでテキスト・ページがストリームされると、かなりの量の空白(スペース、改行およびタブ)がページに含まれることがあります。この空白は、クライアントで消費されたデータには影響しません。ソース・コードがコンシューマに表示されるときに空白が可視状態になります。さらに、過剰な空白はレスポンスのサイズを不必要に増加し、これが最終的に帯域幅の使用を増加します。したがって、可能なかぎり空白を削除することが効果的です。

空白と圧縮の詳細は、次の項を参照してください。

- 空白とJSP

- 空白とXML

- 圧縮

- JSPの設計

80.1 空白とJSP

JSP仕様では、すべての空白を保持する必要があります。したがって次のようなページの場合

<%@ page import="my class name"%>
<%@ page import="my class 2"%>
<cs:ftcs>
<p>Hello world!</p>
</cs:ftcs>

JSPの解析後、3行目にテキストが表示されるため、改行が3つと<p>の前のタブが1つあります。さらに複雑なページでは、問題は複雑になります。

80.2 空白とXML

WebCenter SitesのXML処理言語は、独自のXML対応タグのセットであり、JSPの空白保持ルールにこだわりません。このため、次のようなWebCenter Sites XMLページの場合

<? XML version 1.0 ?>
<FTCS>
<p>Hello World!</p>
</FTCS>

出力の最初の文字として<p>が表示されます。なぜなら、XMLパーサーによって空白がすべて取り除かれるからです。(例外は、XMLデバッグが有効である場合です。この場合、空白がすべて保持されます。)

80.3 圧縮

空白は十分に整えられたフォーマットでコードを記述するためのアーティファクトであるため、その存在は開発者にメリットをもたらすプログラミング・プラクティスの残念な副作用です。コンシューマとカスタマへの影響は、帯域幅を除いて最小です。帯域幅の問題を解消するために、すべてのテキストベースのページの出力を圧縮できます。出力の圧縮はサーバー側で実行され、解凍はコンシューマのユーザー・エージェント(ブラウザ)で実行されます。圧縮/解凍は、エンド・ユーザーには完全に透過的に実行されます。この種の圧縮は、帯域幅の使用量を最大80%削減できます。

一般に使用されている圧縮メカニズムの1つに、Apache Webサーバーのmod-gzip拡張機能があります。このモジュールは、ユーザー・エージェントで解凍可能であれば、ユーザー・エージェントに対するすべての出力を自動的にgzipします。構成は最小であり、その有効性は非常に高いです。これは、SourceForge (http://sourceforge.net/projects/mod-gzip/)から取得できます。類似したツールを、IISなどのその他の一般的なWebサーバーで入手できます。

また、アプリケーション・サーバー・レイヤーでの圧縮を実行し、Webサーバーはそのままにしておくことも可能です。この操作を実行するには、標準サーブレット・フィルタをSatellite Server (またはSatellite Serverが使用されない場合にはWebCenter Sites)に接続します。このサーブレット・フィルタは、指定されたサーブレットの起動の前または後(またはその両方)に所定の順序で起動され、起動中に、mod-gzipの仕組みとまったく同じ方法で、出力を互換性のあるUser-Agentに送信する前に圧縮できます。このような圧縮フィルタは、SourceForge (http://sourceforge.net/projects/pjl-comp-filter/)で検索できます。

圧縮に支援が必要な場合には、Oracleコンサルティング・サービスにお問い合せください。

80.4 JSPの設計

圧縮がオプションでない場合には、JSPページの変更を検討して、圧縮を必要とせずに空白による問題を対処できるようにします。これを実行するには、前述のコードを次のように変更します。

<%@ page import="my class name"
%><%@ page import="my class 2"
%><cs:ftcs><p>Hello world!</p></cs:ftcs>

これは簡潔ではありません(または読みやすくもありません)が、<p>タグの前にいかなる空白も含まれていないページが出力されます。中間の解決策として、次のようなものが考えられます。

<%@ page import="my class name"
%><%@ page import="my class 2"
%><cs:ftcs>
<p>Hello world!</p>
</cs:ftcs>

JSPの空白問題の対処法に関する例の詳細は、ElementCatalogのWebServicesエレメントを参照してください。それらは、WebCenter Sitesに含まれています。

81 WebCenter SitesのURLアセンブラの使用

WebCenter SitesのURLアセンブラは、URLアセンブリとURL逆アセンブリを管理し、URLの表示の定義に使用できるインタフェースを提供します。

WebCenter SitesのURLアセンブラの使用の詳細は、次の項を参照してください。

- WebCenter SitesのURLアセンブラについて

- WebCenter Sitesとともにインストールされるアセンブラ

- アセンブラの使用

- WebページのバニティURLリンク

81.1 WebCenter SitesのURLアセンブラについて

URLアセンブラは、URL生成タグとともに、WebCenter SitesのURLの生成や、URLアセンブラが生成するURLの逆アセンブルに使用されます。

URLアセンブラは、URL管理のレガシー・メソッドです。バニティURLが現在のメソッドであることを確認します。詳細は、「WebページのバニティURLリンク」および『Oracle Fusion Middleware Oracle WebCenter Sitesの管理』を参照してください。

この項には次のトピックが含まれます:

- URLアセンブリ

- アセンブラ検出と逆アセンブリ

- GETリクエストとPOSTリクエストを使用するURLアセンブリとURL逆アセンブリ

81.1.1 URLアセンブリ

WebCenter SitesのURL生成タグ(<satellite.link>、<satellite.blob>、<render.getpageurl>、<render.getbloburl>、<render.satelliteblob>、<rendergettemplateurl>)は、ページやBLOBなど、WebCenter Sitesのリソースへのリンクの構成に使用されます。タグの使用時に指定するタグ属性やネストされた引数タグなどのデータは、URL定義と呼ばれる抽象オブジェクトに変換されます。URL定義はURLアセンブラに渡されます。次に、URLアセンブラはその定義を、返される文字列URLに変換します。

2つのアセンブラはWebCenter Sitesとともにインストールされますが、URLの外観を直接制御するために独自のアセンブラを作成するというオプションがあります。作成するアセンブラを使用できるようにするには、まずWebCenter Sitesにアセンブラを登録しておく必要があります。

デフォルトとして構成されているアセンブラは、WebCenter SitesのすべてのURLの作成に使用されます。デフォルトのアセンブラは変更できます。個々のリンク・タグで、このデフォルトのアセンブラの使用をオーバーライドすることもできます。

81.1.2 アセンブラ検出と逆アセンブリ

アセンブラは、アセンブラの作成者が求めるいずれのフォームでもURLを作成できるため、アセンブルされたリンクが要求される場合は、アプリケーション・サーバーによってURLをパラメータにデコードできない場合があります。デコードを実行するには、アセンブラが文字列URLをその定義に逆アセンブルできる必要があります。したがって、アセンブラは可逆性であり、アセンブルしたどのURLも逆アセンブルできます。

URLがデフォルトのアセンブラ以外のアセンブラを使用して作成されている場合は、デフォルトのアセンブラはそのURLを逆アセンブルできません。その時点で、次の上位ランクのアセンブラがそのURLの逆アセンブルを試みます。定義の作成に成功した場合は、アセンブラ・エンジンがそのアセンブラを検出しており、定義がパラメータに変換されて処理されます。次の上位ランクのアセンブラがそのURLの逆アセンブルに失敗した場合は、3番目の上位ランクのアセンブラがコールされ、そのURLを逆アセンブルします。このプロセスは、URLが逆アセンブルに成功するまで続行します。このプロセスでは、アセンブラが、アセンブルしたURLを自己のものであると認識し、他のすべてのURLを外部のものであると認識できることが必要です。

アセンブラの作成、登録、ランク付けの詳細は、「アセンブラの作成」および「アセンブラの登録とランク付け」を参照してください。

81.1.3 GETリクエストとPOSTリクエストを使用するURLアセンブリとURL逆アセンブリ

URLアセンブラは、GETリクエストでのみ呼び出されます。これらはPOSTリクエストでは呼び出されません。たとえば、GETリクエストでページにアクセスする際、URLアセンブラが呼び出され、URLを逆アセンブルします。その後、WebCenter Sitesがそのページを開くために必要な適切なパラメータ(c、cid、pagenameなど)を定義に追加することで提供します(定義に存在しない場合)。ただし、method=postを使用したフォームなどのリクエストがPOSTされる場合は、URLアセンブラはURLの逆アセンブルには呼び出されません。したがって、WebCenter Sitesがページを開くために必要なパラメータは、postリクエスト自体の一部である必要があります。

これは、ページのテンプレートまたはエレメントに次のタグをエンコードすることで実行できます(サンプル値を、WebCenter SitesがページのURLに必要とするパラメータに置換)。

<satellite:form method="post" id="assetid">
<render:gettemplateurlparameters list="args" ... /><!-- add all parameters that are normally part of a URL -->
<ics:listloop listname="args">
<input type="hidden" name="<string:stream list="args" column="name"/>" value="<string:stream list="args" column="value"/>"/>
</ics:listloop>

81.2 WebCenter Sitesとともにインストールされるアセンブラ

WebCenter Sitesとともにインストールされる2つのアセンブラは、QueryアセンブラとQueryAsPathInfoアセンブラです。

この項には次のトピックが含まれます:

- Queryアセンブラ

- QueryAsPathInfoアセンブラ

81.2.1 Queryアセンブラ

Queryアセンブラは、問合せ文字列でURLを作成します。これはデフォルトのアセンブラで、WebCenter Sitesに自動的に登録されています。したがって、(デフォルトのアセンブラの変更やリンク・タグにおけるデフォルトのオーバーライドなどを)変更するまで、QueryアセンブラはすべてのURLの生成に使用されます。

81.2.2 QueryAsPathInfoアセンブラ

QueryAsPathInfoアセンブラは問合せ文字列を使用しません。かわりに、QueryAsPathInfoアセンブラは問合せ文字列をエンコードし、サーブレット名の末尾に付加します。このアセンブラの利点は、検索エンジンで索引付けできるURLを作成することです。QueryAsPathInfoアセンブラは、WebCenter Sitesに自動的には登録されていません。

81.3 アセンブラの使用

この項では、独自のアセンブラの作成と登録の方法について説明します。この項では、デフォルトのアセンブラの使用をオーバーライドするようにリンク・タグを変更する方法も説明します。

この項には次のトピックが含まれます:

- アセンブラの作成

- アセンブラの登録とランク付け

- リンク・タグの変更

81.3.1 アセンブラの作成

WebCenter SitesのURLアセンブリ・モジュールを使用して、独自のアセンブラを作成できます。このオプションにより、URLの外観を直接制御できます。

アセンブラを作成するには::

1. com.fatwire.cs.core.uri.Assemblerインタフェースを実装するJavaクラスを記述します。このクラスの詳細は、Oracle WebCenter Sites Java APIリファレンスを参照してください。

2. このクラスを.jarファイルにコンパイルします。

3. WebCenter SitesのWebアプリケーション、およびインストールしたリモートの各Satellite ServerのWebアプリケーションにクラスをデプロイします。

これは通常、作成した.jarファイルを、WebアプリケーションのWEB-INF/libフォルダにコピーするという意味です。リモートのSatellite Serverの場合は、resin/webapp/ROOT/WEB-INF/libフォルダにコピーするという意味です。

4. WebCenter SitesとリモートのSatellite Serverすべての両方で、wcs_properties.jsonファイルに新規のアセンブラを登録します。(手順については、「アセンブラの登録とランク付け」を参照。)

5. WebCenter SitesとリモートのSatellite Serverすべてを再起動します。

81.3.2 アセンブラの登録とランク付け

URLの作成にアセンブラを使用できるようにするには、まずWebCenter Sitesに登録しておく必要があります。登録は、ショート・フォームに対応するアセンブラ・クラス名をプロパティ・ファイルに列記することで実行されます。登録には、アセンブラの使用順序を示すランキングも含まれます。

アセンブラを登録するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「カテゴリ」ドロップダウン・メニューで、ServletRequestを選択して、アセンブラのプロパティにアクセスします。

3. 「検索」をクリックします。

4. 登録するアセンブラのclassnameとshortformを指定します。

プロパティ名の3番目のエレメントは、アセンブラのランキングを示しています。ランキング0のアセンブラは最上位ランク(およびデフォルト)のアセンブラ、ランキング1のアセンブラは次の上位ランクです。以降も同様になります。

デフォルトのアセンブラとして新規のアセンブラを構成する場合は、ランキング1のプロパティにclassnameとshortformの値を入力します。

たとえば、デフォルトのアセンブラとしてQueryAsPathInfoアセンブラを登録するための構文は、次のようになります。

表81-1 アセンブラのプロパティ

プロパティ名

プロパティ値

uri.assembler.0.classname

com.fatwire.cs.core.uri.QueryAsPathInfoAssembler

uri.assembler.0.shortform

pathinfo

uri.assembler.1.classname

com.fatwire.cs.core.uri.QueryAssembler

uri.assembler.1.shortform

query

注意:

ランキングを下げた場合でも、Queryアセンブラが常に登録されていることを確認します。Queryアセンブラは、shortformの値をqueryとして登録する必要があります。

5. 新規のアセンブラのランキングに応じて、その他のアセンブラのランキングの調整が必要になる場合もあります。すべてのアセンブラがプロパティ・ファイルで正しく構成され、ランク付けされていることを確認します。そうでない場合は、必要な変更を実行します。

6. アセンブラの値を変更したら、別のアセンブラの値を変更する前に「保存」をクリックします。

7. インストールしたリモートのSatellite Serverごとに、手順5から6を繰り返します。

8. WebCenter SitesとリモートのSatellite Serverすべてを再起動します。

81.3.3 リンク・タグの変更

WebCenter Sitesのリンク・タグは、デフォルトのアセンブラ以外のアセンブラを使用するように変更できます。リンク・タグは属性assemblerを受け入れ、値としてアセンブラのショート・フォームを取ります。たとえば、個々のリンク・タグで、デフォルトのアセンブラをオーバーライドしてQueryAsPathInfoアセンブラにするための構文は、次のようになります。

<satellite:link pagename=example assembler=pathinfo />

81.4 WebページのバニティURLリンク

アセットに、name引数で渡されたテンプレートのバニティURLが含まれていると、タグはバニティURLを返すようになります。アセットにバニティURLが含まれていない場合、タグはSitesのURLを返します。<render:gettemplateurl>タグは、バニティURLリンクの生成に使用できます。これにより、リダイレクトされるURLは、常にバニティURL (存在する場合)を返すようになります。このような場合に既存のリンクにアクセスすると(たとえば、ブックマークから)、それ以降のすべてのURLはバニティURLになります。

特定のWebRootに対するバニティURLを作成するには、hostparamという追加のパラメータをrender: gettemplateurlに渡す必要があります。hostparamの値は、WebRootのhostname属性と一致する必要があります。これを使用すると、別のWebサイトや、同一Webサイト内のサブドメインへのリンクを生成できます。例:

<render:gettemplateurl outstr="pageURL" webrootname=<name of WebRoot used for retrieving URL> tname='<%=ics.GetVar("template")%>' args="c,cid" />

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。