Oracle® Fusion Middleware

WebCenter Sites開発者ガイド

11gリリース1 (11.1.1.8.0)

E49681-03(原本部品番号:E29634-03)

2014年6月

Oracle Fusion Middleware WebCenter Sites開発者ガイド, 11gリリース1 (11.1.1.8.0)

E49681-03

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

原本主著者: Promila Chitkara

原本協力者: Melinda Rubenau、Sean Cearley、Tatiana Kolubayev

協力者: Avadhani Chandrashekar、Joseph Granato、Kannan Appachi、Patrice Palau、Ravi Khanuja、Saikat Chaudhuri、Vijayalakshmi Rajan

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

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

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

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

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(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の登録商標です。

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

- 11gリリース1 (11.1.1.8.0)の新機能と変更された機能

- 非推奨に関する注意点

第I部 Oracle WebCenter Sitesの開発

1 Oracle WebCenter Sitesの概要

- 1.1 コンテンツ・エントリ・フォームからWebサイトまで

- 1.2 動的Webサイトの開発

- 1.3 WebCenter Sitesのデータ設計

- 1.4 プレゼンテーション・ロジック

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

- 1.4.2 APIおよびJSPタグ

- 1.4.3 セッションおよびCookie

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

- 1.4.5 Webサイト・ナビゲーション

- 1.5 WebCenter Sitesのシステム

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

- 1.7 パフォーマンス: キャッシング

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

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

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

- 1.7.4 Satellite Server

- 1.7.4.1 HTTPリクエストの処理

- 1.7.4.2 Satellite Serverのサーブレット

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

- 1.9 サンプル・サイト

- 1.9.1 avisportsサンプル・サイト

- 1.9.2 FirstSiteIIサンプル・サイト

- 1.9.3 WebCenter Sites Demo JSKでのみ使用可能

2 コンテンツ管理サイトについて

- 2.1 コンテンツ管理サイト

- 2.2 オンライン・サイト

- 2.3 開発者とコンテンツ管理サイト

- 2.4 サイトとサイト・プラン

- 2.4.1 Burlington Financialサンプル・サイト

- 2.5 サイトとデータベース

3 Oracle 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: 配信システムにパブリッシュする

4 Oracle WebCenter Sitesを使用したプログラミング

- 4.1 コーディング言語の選択

- 4.2 Oracle WebCenter Sitesのコンテキスト

- 4.2.1 ICSオブジェクト

- 4.2.2 FTCSタグ

- 4.3 WebCenter SitesのJSP

- 4.3.1 WebCenter Sitesの標準先頭部

- 4.3.1.1 taglibディレクティブ

- 4.3.1.2 ページ・ディレクティブ

- 4.3.1.3 cs:ftcsタグ

- 4.3.2 JSPの暗黙オブジェクト

- 4.3.3 構文

- 4.3.4 アクション

- 4.3.5 宣言

- 4.3.6 スクリプトレットと式

- 4.3.7 JSPのディレクティブ

- 4.3.8 Oracle WebCenter Sitesのタグ・ライブラリ

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

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

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

- 4.4 WebCenter SitesのXML

- 4.4.1 WebCenter Sitesの標準先頭部

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

- 4.4.1.2 DTDファイル

- 4.4.1.3 FTCSタグ

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

- 4.4.3 XML解析エラー

- 4.5 WebCenter Sitesのタグ

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

- 4.5.2 変数を処理するタグ

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

- 4.5.4 URLを作成するタグ

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

- 4.5.6 Cookieを設定するタグ

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

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

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

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

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

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

- 4.6 変数

- 4.6.1 予約変数

- 4.6.2 通常変数の設定

- 4.6.2.1 SETVARを使用した変数の設定

- 4.6.2.2 URLを通じた変数の設定

- 4.6.2.3 Oracle WebCenter Sites Explorerを使用したエレメントとテンプレートのデフォルト変数の設定

- 4.6.2.4 HTMLフォームを使用した変数の設定

- 4.6.3 セッション変数の設定

- 4.6.4 変数の操作

- 4.6.4.1 変数の値の取得

- 4.6.4.2 変数の値の表示

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

- 4.6.4.4 HTMLタグでの変数の使用

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

- 4.6.5 変数と優先順位

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

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

- 4.7.1 ビルトイン

- 4.7.2 リスト

- 4.7.2.1 リストのループ処理

- 4.7.3 カウンタ

- 4.8 特殊文字の値

5 ページのデザインとキャッシング

- 5.1 モジュラ・ページ・デザイン

- 5.2 キャッシング

- 5.2.1 WebCenter Sitesのキャッシング

- 5.2.2 BlobServerとキャッシング

- 5.2.3 Satellite Serverのキャッシング

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

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

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

- 5.3.1 CacheManager

- 5.3.2 SiteCatalog表

- 5.3.3 キャッシュ・キー

- 5.3.3.1 pagecriteriaとキャッシュ・キー

- 5.3.4 キャッシングのプロパティ

- 5.3.4.1 WebCenter Sitesページのキャッシングのプロパティ

- 5.3.4.2 Satellite Serverのプロパティ

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

- 5.4.1 二重バッファ・キャッシングの実装

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

- 5.4.2 cscacheinfoの設定

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

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

- 5.4.4.1 WebCenter Sitesのセキュリティ

- 5.4.4.2 Satellite Serverのセキュリティ

6 WebCenter Sitesのインテリジェント・キャッシュ管理

- 6.1 WebCenter Sitesのレンダリング・エンジン・キャッシュ

- 6.2 CacheManager

- 6.3 CacheManagerの有効化

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

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

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

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

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

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

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

- 7.2 BlobServerキャッシュの構成

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

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

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

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

- 7.4 CacheInfo文字列の構文

8 WebCenter Sitesのツールおよびユーティリティ

- 8.1 Oracle WebCenter Sites Explorer

- 8.2 WebCenter Sitesデータベースへの接続

- 8.3 CatalogMover

- 8.3.1 CatalogMoverの起動

- 8.3.2 WebCenter Sitesへの接続

- 8.3.3 CatalogMoverのメニュー・コマンド

- 8.3.4 「カタログ」メニュー

- 8.3.5 表のエクスポート

- 8.3.5.1 選択した表の行のエクスポート

- 8.3.5.2 エクスポート対象の行の選択

- 8.3.5.3 ZIPファイルへのエクスポート

- 8.3.6 表のインポート

- 8.3.6.1 以前にエクスポートされたHTMLファイルのインポート

- 8.3.6.2 以前にエクスポートされたZIPファイルのインポート

- 8.3.6.3 CatalogMoverの既存のファイルのマージ

- 8.3.6.4 CatalogMoverの既存のファイルの置換

- 8.3.7 コマンドライン・インタフェース

- 8.4 プロパティ・エディタ

- 8.4.1 プロパティ・エディタの起動

- 8.4.2 プロパティの設定

- 8.4.3 プロパティ・ファイルのマージ

- 8.5 XMLPost

9 セッションおよびCookie

- 9.1 セッションの理解

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

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

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

- 9.3セッションの例

- 9.3.1 FeelingsFormエレメント

- 9.3.2 SetFeelingエレメント

- 9.3.3 Meatエレメント

- 9.4 Cookieとは

- 9.4.1 CookieServer

- 9.4.2 Cookieのタグ

- 9.5 Cookieの例

- 9.5.1 Start.xml

- 9.5.2 ColorForm

- 9.5.3 CreateCookie

- 9.5.4 DisplayWelcome

- 9.5.5 Cookie例の実行

- 9.6 ヒントとコツ

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

- 9.7.1 URLによるセッションのフラッシュ

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

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

10 エラー・ロギングおよびデバッグ

- 10.1 WebCenter Sitesログ・ファイルへのロギング

- 10.2 タグによるエラー・コードの使用方法

11 データ・デザイン: アセット・モデル

- 11.1 アセット・タイプとアセット・モデル

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

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

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

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

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

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

- 11.2.1 Burlington Financialサンプル・サイトからのベーシック・アセット・タイプ

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

- 11.2.2.1 アソシエーション

- 11.2.2.2 名前なし関係

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

- 11.2.3.1 カテゴリ

- 11.2.3.2 ソース

- 11.2.3.3 サブタイプ

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

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

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

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

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

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

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

- 11.3.2.1 製品ファミリ

- 11.3.2.2 コンテンツ・ファミリ

- 11.3.3 フレックス属性

- 11.3.3.1 属性のデータ型

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

- 11.3.3.3 外部属性

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

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

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

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

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

- 11.3.6.2 _Mungo表

- 11.3.6.3 MungoBlobs表

- 11.3.6.4 _AMap表

- 11.4 assetsetおよびsearchstate

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

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

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

- 11.8 要約: アセット・タイプ

12 WebCenter Sitesデータベース

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

- 12.1.1 オブジェクト表

- 12.1.2 ツリー表

- 12.1.3 コンテンツ表

- 12.1.4 外部表

- 12.1.5 システム表

- 12.1.6 表のタイプの特定

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

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

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

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

- 12.3 データベース表の作成

- 12.3.1 オブジェクト表の作成

- 12.3.2 ツリー表の作成

- 12.3.2.1 ツリー表内のデータの管理

- 12.3.3 コンテンツ表の作成

- 12.3.4 外部表の登録

- 12.4 情報はシステム表にどのように追加されるか

- 12.5 プロパティ・ファイルとデータベース

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

- 13.1 メソッドとタグ

- 13.1.1 データの記述と取得

- 13.1.1.1 CatalogManager

- 13.1.1.2 ツリー・マネージャ

- 13.1.2 データの問合せ

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

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

- 13.2.1 行の追加

- 13.2.1.1 addrowFORMエレメント

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

- 13.2.2 行の削除

- 13.2.2.1 deleterowFORMエレメント

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

- 13.2.3 表の問合せ

- 13.2.3.1 SelectNameFormエレメント

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

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

- 13.2.4 埋め込まれたSQL文を持つ表の問合せ

- 13.2.4.1 QueryInlineSQLForm

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

- 13.3 データの手動管理

- 13.4 アセットを保持しない表の削除

14 結果セットのキャッシングと問合せ

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

- 14.2 データベースの問合せ

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

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

- 14.5 表名の指定

- 14.5.1 SELECTTO

- 14.5.2 EXECSQL

- 14.5.3 CALLSQL

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

- 14.5.5 問合せアセット

- 14.5.6 SEARCHSTATE

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

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

- 14.8 結果セットのキャッシングの構成

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

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

- 14.8.3 表固有のプロパティ

- 14.9 まとめ

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

- 15.1 AssetMakerユーティリティ

- 15.1.1 AssetMakerの仕組み

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

- 15.1.2.1 アセット記述子ファイルとは

- 15.1.2.2 フォーマットと構文

- 15.1.2.3 AssetMakerのタグの概要

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

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

- 15.1.3.2 列の記憶域のタイプ

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

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

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

- 15.1.4.1 エレメント

- 15.1.4.2 SQL文

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

- 15.2.1 新しいアセット・タイプの作成と構成の概要

- 15.2.2 始める前に

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

- 15.2.2.2 開発システムの設定

- 15.2.3 手順1: アセット記述子ファイルのコーディング

- 15.2.3.1 サンプルのアセット記述子ファイル: ImageFile.xml

- 15.2.3.2 例: ソース列とフィールドの追加

- 15.2.3.3 アップロードの例1: 標準アップロード・フィールド

- 15.2.3.4 アップロードの例2: テキスト・ボックス・フィールド

- 15.2.3.5 アップロードの例2: テキスト・ボックス・フィールド

- 15.2.3.6 アップロードの例3: CKEditorのフィールド

- 15.2.3.7 アップロードの例4: バイナリ・ファイルをアップロードするフィールド

- 15.2.3.8 例: パス、ファイル名、開始日および終了日の有効化

- 15.2.3.9 例: 問合せを使用したドロップダウン・リストのオプションの取得

- 15.2.3.10 例: 問合せを使用したラジオ・ボタンのラベルの取得

- 15.2.3.11 例: ELEMENT入力タイプを使用したフィールドの作成

- 15.2.4 手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード

- 15.2.5 手順3: アセット表の作成

- 15.2.6 手順4: アセット・タイプの構成

- 15.2.7 手順5: サイトのアセット・タイプの有効化

- 15.2.8 手順6: アセット記述子ファイルの微調整

- 15.2.9 手順7: (オプション)アセット・タイプのエレメントのカスタマイズ

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

- 15.2.10 手順8: (オプション)サブタイプの構成

- 15.2.10.1 サブタイプの追加

- 15.2.10.2 サブタイプの削除

- 15.2.11 手順9: (オプション)アソシエーション・フィールドの構成

- 15.2.11.1 アソシエーション・フィールドの追加

- 15.2.11.2 アソシエーション・フィールドの削除

- 15.2.12 手順10: (オプション)カテゴリの構成

- 15.2.12.1 カテゴリの追加

- 15.2.12.2 カテゴリの削除

- 15.2.13 手順11: (オプション)ソースの構成

- 15.2.13.1 ソースの追加

- 15.2.13.2 ソースの削除

- 15.2.14 手順12: (条件付き)MIMEタイプの追加

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

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

- 15.2.17 手順15: アセット・タイプのテンプレートのコーディング

- 15.2.18 手順16: 他のシステムへのアセット・タイプの移動

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

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

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

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

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

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

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

- 16.1.4.1 データ型

- 16.1.4.2 属性エディタの使用

- 16.1.4.3 各属性の使用場所

- 16.1.4.4 階層による依存性

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

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

- 16.1.6.1 階層の配置の指定

- 16.1.6.2 属性継承の指定

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

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

- 16.1.7 まとめ

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

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

- 16.3.1 新しいフレックス・アセット・タイプまたはフレックス・アセット・タイプのファミリの作成の概要

- 16.3.2 始める前に

- 16.3.3 手順1: フレックス・ファミリの作成

- 16.3.4 手順2: (オプション)追加のフレックス・ファミリ・メンバーの作成

- 16.3.5 手順3: 新規のフレックス・アセット・タイプの有効化

- 16.3.6 手順4: フレックス属性の作成

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

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

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

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

- 16.3.7 手順5: (オプション)フレックス・フィルタ・アセットの作成

- 16.3.8 手順6: 親定義アセットの作成

- 16.3.9 手順7: フレックス定義アセットの作成

- 16.3.10 手順8: フレックス親アセットの作成

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

- 16.3.12 手順10: フレックス・アセットのテンプレートのコード化

- 16.3.13 手順11: 設計のテスト(テスト用フレックス・アセットの作成)

- 16.3.14 手順12: (オプション)フレックス・アセットのアソシエーションの作成

- 16.3.15 手順13: 他のシステムへのアセット・タイプの移動

- 16.4 フレックス属性、親および定義の編集

- 16.4.1 属性の編集

- 16.4.2 親定義とフレックス定義の編集

- 16.4.3 親およびフレックス・アセットの編集

- 16.5 製品セットの使用

- 16.5.1 製品セットとは

- 16.5.2 製品セットの作成

17 フレックス・フィルタ

- 17.1 フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットの理解

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

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

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

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

- 17.2.1.1 AbstractFlexFilterクラスの拡張

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

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

- 17.3 ドキュメント変換

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

- 17.3.2 カスタム・ソリューション

- 17.3.3 ドキュメント変換のカスタマイズ

- 17.3.3.1 ドキュメント・トランスフォーマの作成とデプロイ

- 17.3.3.2 変換エンジンの登録

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

- 17.3.4 次の手順

18 属性エディタの設計

- 18.1 属性エディタの理解

- 18.1.1 presentationobject.dtdファイル

- 18.1.1.1 presentationobject.dtdファイルの規則

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

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

- 18.1.2.2 CHECKBOXESの例

- 18.1.2.3 CKEditorの例

- 18.1.2.4 PICKASSETの例

- 18.1.2.5 PULLDOWNの例

- 18.1.2.6 RADIOBUTTONSの例

- 18.1.2.7 TEXTAREAの例

- 18.1.2.8 TEXTFIELDの例

- 18.1.2.9 TYPEAHEADの例

- 18.1.2.10 UPLOADERの例

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

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

- 18.2 属性エディタの作成

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

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

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

- 18.4 属性エディタの編集

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

- 19.1 CKEditorの構成

- 19.1.1 始める前に

- 19.1.2 CKEditorインスタンスの作成とフィールドに対する有効化

- 19.1.3 CKEditorのWebモードでの使用可能化

- 19.1.4 特定のアセット・タイプのCKEditorでの使用可能化

- 19.1.5 組み込まれたアセットの承認依存性の設定

- 19.1.6 CKEditorでのイメージ・ピッカーの使用可能化

- 19.1.7 CKEditorツールバーのカスタマイズ

- 19.1.7.1 システム全体レベルのCKEditorツールバーのカスタマイズ

- 19.1.7.2 インスタンス単位のCKEditorツールバーのカスタマイズ

- 19.1.8 CKEditorでのスペル・チェック・サポートの構成

- 19.2 Clarkii Online Image Editorの構成

- 19.2.1 Clarkii OIEインスタンスの作成とフィールドに対する有効化

- 19.2.2 Clarkii OIEのプロパティの構成

- 19.2.3 アセットを分類するためのフィールド・コピアー・フィルタの実装

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

- 19.3.1 イメージ・ピッカーに表示するイメージ・アセットのカテゴリ分け

- 19.3.2 イメージ・ピッカー属性エディタ定義のサンプル・コード

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

- 20.1 XMLPostユーティリティ

- 20.2 XMLPostの構成ファイル

- 20.2.1 XMLPostの構成プロパティ

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

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

- 20.2.3.1 サイトのプロパティ

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

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

- 20.3 XMLPostのソース・ファイル

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

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

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

- 20.4.1 始める前に

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

- 20.4.3 ソース・ファイルを指定するための方法

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

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

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

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

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

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

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

- 21.1 フレックス・アセットの理解

- 21.1.1 データ構造フレックス・アセット・タイプのインポート

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

- 21.1.3 フレックス・アセットのインポート: プロセス

- 21.1.4 カスタムのデータ・デリミタの使用

- 21.2 XMLPostとフレックス・アセット・モデル

- 21.3 フレックス・モデル内の構造アセット・タイプのインポート

- 21.3.1 属性エディタ

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

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

- 21.3.2 フレックス属性

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

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

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

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

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

- 21.3.4 フレックス親

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

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

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

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

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

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

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

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

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

- 21.4.4.1 サンプル・ファイル

- 21.4.4.2 特殊文字の処理

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

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

- 21.4.4.5 親の属性値の設定

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

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

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

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

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

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

- 21.5.2.1 属性の値の変更

- 21.5.2.2 属性値の削除

- 21.5.2.3 親関係の編集

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

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

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

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

- 22.1 BulkLoaderユーティリティの概要

- 22.1.1 BulkLoaderの機能

- 22.1.2 BulkLoaderの仕組み

- 22.1.3 BulkLoaderユーティリティの使用

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

- 22.1.5 手順1: XMLPostの使用による構造アセットのインポート

- 22.1.6 手順2: 入力表(データソース)の作成

- 22.1.6.1 挿入

- 22.1.6.2 更新

- 22.1.7 手順3: マッピング表の作成

- 22.1.8 手順4: BulkLoader構成ファイルの作成

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

- 22.1.8.2 initIDパラメータの設定

- 22.1.8.3 構成ファイルの例

- 22.1.9 手順5: BulkLoaderユーティリティの実行

- 22.1.10 手順6: フィードバック情報の確認

- 22.1.11 手順7: アセットの承認と配信システムへのパブリッシュ

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

- 22.2.1 IDataExtractインタフェース

- 22.2.2 IPopulateDataSlice

- 22.2.3 IFeedbackインタフェース

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

- 22.3.1 BulkApproverの構成

- 22.3.2 BulkApproverの使用方法

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

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

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

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

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

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

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

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

- 23.3.2 CSElementアセット

- 23.3.3 SiteEntryアセット

- 23.3.4 非アセット・エレメントとは

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

- 23.4.1 前提条件

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

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

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

- 23.4.2 テンプレート・アセットの作成手順

- 23.4.2.1 手順1: 「テンプレート」フォームを開く

- 23.4.2.2 手順2: テンプレート・アセットの名前付けと記述

- 23.4.2.3 手順3: テンプレートのエレメントの構成

- 23.4.2.4 手順4: SiteEntryの構成

- 23.4.2.5 手順5: マップの構成

- 23.4.2.6 手順6: (オプション)サムネイルの作成

- 23.4.2.7 手順7: テンプレートの調査

- 23.5 CSElementアセットの作成

- 23.5.1 前提条件

- 23.5.1.1 CSElementの名前付け

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

- 23.5.2 CSElementアセットの作成手順

- 23.5.2.1 手順1: 「CSElement」フォームを開く

- 23.5.2.2 手順2: CSElementアセットの名前付けと記述

- 23.5.2.3 手順3: エレメントの構成

- 23.5.2.4 手順4: マップの構成

- 23.5.2.5 手順5: CSElementの保存と調査

- 23.5.2.6 手順6: ブックマークへのCSElementの追加

- 23.6 SiteEntryアセットの作成

- 23.6.1 前提条件

- 23.6.2 SiteEntryアセットの作成手順

- 23.6.2.1 手順1: 「SiteEntry」フォームを開く

- 23.6.2.2 手順2: SiteEntryアセットの作成

- 23.6.2.3 手順3: SiteEntryアセットの保存と調査

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

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

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

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

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

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

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

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

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

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

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

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

- 24.1 テンプレートの使用

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

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

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

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

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

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

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

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

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

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

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

- 24.2 ラッパーの使用

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

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

- 25.1.1 属性データ型

- 25.1.2 文字列フィールド

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

- 25.1.3 テキスト・フィールド

- 25.1.4 日付フィールド

- 25.1.5 バイナリ・フィールド

- 25.1.6 アセット・フィールド

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

- 25.1.6.2 親アセットの編集

- 25.1.7 数値フィールド

- 25.1.8 複数値フィールド

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

- 25.1.8.2 例2: 複数値テキスト・フィールド

- 25.1.8.3 異なる順序の指定

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

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

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

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

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

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

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

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

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

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

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

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

- 25.2.4.1 スロットの有効範囲の定義

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

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

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

- 25.2.4.5 コンテキストとキャッシング

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

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

- 25.2.5.2 CSElementアセットまたはSiteEntryアセットの使用

- 25.2.5.3 適切な引数の使用

- 25.2.5.4 ネストされたスロットの使用

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

- 25.2.7 CSSとJavaScriptの競合回避

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

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

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

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

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

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

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

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

- 26.1 コレクション・アセット

- 26.1.1 始める前に

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

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

- 26.2 問合せアセット

- 26.2.1 問合せアセットとその他のアセット

- 26.2.2 問合せの格納方法

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

- 26.2.4 始める前に

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

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

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

- 26.3 ページ・アセット

- 26.3.1 ページ・アセット・モデル

- 26.3.2 ページ属性の設計

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

- 26.3.4 ページ・アセットの配置

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

- 26.3.6 ページ・アセットとワークフローの配置

- 26.3.7 ページ・アセットの編集

- 26.3.8 ページ・アセットの削除

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

- 27.1 将来サイト・プレビューを実装する場合の考慮事項

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

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

- 27.3.1 asset:filterassetsbydateタグ

- 27.3.2 入力リスト

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

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

- 28.1 依存性について

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

- 28.1.1.1 承認依存性の計算

- 28.1.1.2 Exists、ExactおよびNone

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

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

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

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

- 28.2.1 ASSET.LOADおよびasset:load

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

- 28.2.3 RENDER.GETPAGEURLおよびrender:getpageurl

- 28.2.4 RENDER.LOGDEP (render:logdep)

- 28.2.5 RENDER.FILTERおよびrender:filter

- 28.2.6 RENDER.UNKNOWNDEPSおよびrender:unknowndeps

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

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

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

- 28.4.2 アソシエーション

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

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

- 28.4.5 コレクション

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

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

- 28.4.6 問合せアセット

- 28.4.7 ページ・アセット

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

- 28.5.1 アセットセット

- 28.5.2 検索状態

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

- 28.5.4 スコープ

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

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

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

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

- 28.6.2.2 製品の価格の取得

- 28.6.2.3 製品の価格の表示

- 28.6.2.4 製品の色の取得

- 28.6.2.5 製品の色の表示

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

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

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

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

- 28.6.3.1 TEXT型のフレックス属性

- 28.6.3.2 BLOB型のフレックス属性

- 28.6.3.3 BlobServer URLの作成

- 28.6.3.4 BLOBの値の取得と表示

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

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

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

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

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

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

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

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

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

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

- 28.7.1 RENDER.GETPAGEURL (render:getpageurl)

- 28.7.2 RENDER.SATELLITEBLOB (render:satelliteblob)

- 28.7.3 RENDER.GETBLOBURL (render:getbloburl)

- 28.7.4 referURL変数の使用

- 28.8 エラー状態の処理

- 28.8.1 errno変数の使用

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

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

- 29.1 例1: ベーシック・モジュラ・デザイン

- 29.1.1 最初のエレメント: Home

- 29.1.2 2番目のエレメント: MainStoryList

- 29.1.3 3番目のエレメント: LeadSummary

- 29.1.4 4番目のエレメント: TeaserSummary

- 29.1.5 LeadSummaryの再開

- 29.1.6 MainStoryListの再開

- 29.1.7 Homeの再開

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

- 29.2.1 最初のエレメント: SectionFront

- 29.2.2 2番目のエレメント: PlainList

- 29.3 例3: ct変数の使用

- 29.3.1 最初のエレメント: SectionFront

- 29.3.2 2番目のエレメント: TextOnlyLink

- 29.3.3 ColumnistFront

- 29.4 例4: 問合せアセットのテンプレートのコーディング

- 29.4.1 最初のエレメント: Home

- 29.4.2 2番目のエレメント: WireFeedBox

- 29.4.3 3番目のエレメント: ExecuteQuery

- 29.4.4 WireFeedBoxの再開

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

- 29.5.1 最初のエレメント: Full

- 29.5.2 2番目のエレメント: AltVersionBlock

- 29.5.3 3番目のエレメント: EmailFront

- 29.6 例6: サイト・プラン情報の表示

- 29.6.1 最初のエレメント: Home

- 29.6.2 2番目のエレメント: SiteBanner

- 29.6.3 3番目のエレメント: TopSiteBar

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

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

- 29.6.4 SiteBannerの再開

- 29.7 例7: アセット以外の情報の表示

- 29.7.1 最初のエレメント: Home

- 29.7.2 2番目のエレメント: ShowMainDate

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

- 30.1 多言語サポートのサイトの構成の概要

- 30.1.1 ディメンション

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

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

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

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

- 30.1.6 承認依存性

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

- 30.2.1 ロケール・フィルタリングによるアセット関係の処理

- 30.2.2 含まれるロケール・フィルタ

- 30.2.2.1 簡易フィルタ

- 30.2.2.2 簡易参照フィルタ

- 30.2.2.3 階層フィルタ

- 30.2.3 カスタム・ロケール・フィルタ

- 30.2.4 構成依存性

- 30.2.4.1 アセットの検索連鎖

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

- 30.2.5 サイトへのフィルタリング・サポートの追加

- 30.2.5.1 テンプレートへのフィルタリングの追加

- 30.2.5.2 訪問者のロケール・プリファレンスの取得と保持

- 30.2.5.3 検索結果のフィルタリング

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

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

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

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

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

- 30.4.4 ロケールの作成

- 30.4.5 ロケールの別のサイトへの共有

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

- 30.4.7 ディメンション・セットの別のサイトへの共有

- 30.4.8 ロケール・フィルタの構成

- 30.4.9 階層フィルタのフォールバック階層の構成

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

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

31 配信システムにおけるユーザー管理

- 31.1 ディレクトリ・サービスAPI

- 31.1.1 エントリ

- 31.1.2 階層

- 31.1.3 グループ

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

- 31.1.5 ディレクトリの操作

- 31.1.5.1 検索

- 31.1.5.2 ルックアップ

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

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

- 31.1.6 エラーの処理

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

- 31.2 訪問者のオンライン・サイトへのアクセスの制御

- 31.2.1 ACLタグ

- 31.2.2 USERタグ

- 31.2.3 WebCenter Sitesおよび暗号化

- 31.3 ログイン・フォームの作成

- 31.3.1 ログインのプロンプト(PromptForLogin.xml)

- 31.3.2 ログイン・ページのルート・エレメント

- 31.4 ユーザー・アカウント作成フォームの作成

- 31.4.1 PromptForNewAccount

- 31.4.2 CreateAccount Pageのルート・エレメント

- 31.5 Burlington Financialサンプル・サイトにおける訪問者のアクセス

- 31.5.1 メンバーシップ表

- 31.5.2 ユーザーとパスワード

- 31.5.3 メンバー・アカウント

- 31.5.4 メンバーシップ処理エレメント

32 HelloAssetWorldサンプル・サイト

- 32.1 HelloAssetWorldサンプル・サイトの概要

- 32.1.1 HelloAssetWorldテンプレート

- 32.1.2 HelloAssetWorldアセット・タイプ

- 32.2 変更されたアセット・タイプ

- 32.2.1 HelloArticleアセット・タイプ

- 32.2.2 HelloImageアセット・タイプ

- 32.3 HelloAssetWorldテンプレート

- 32.3.1 HelloArticleテンプレート

- 32.3.2 HelloCollectionテンプレート

- 32.3.3 HelloPageテンプレート

- 32.4 HelloQueryアセット

33 Burlington Financialサンプル・サイト

- 33.1 Burlington Financialサンプル・サイトの概要

- 33.2 ナビゲーション機能

- 33.2.1 BurlingtonFinancial/Site/TopSiteBar.xml

- 33.2.2 BurlingtonFinancial/Site/LeftSideSiteBar.xml

- 33.2.3 BurlingtonFinancial/Site/BottomNavFooter.xml

- 33.2.4 ブレッドクラム

- 33.3 ベスト・プラクティス

- 33.3.1 検索

- 33.3.2 キーワード

- 33.3.3 Hot Topics

- 33.3.4 Topic Directory

- 33.3.5 Related Stories

- 33.3.6 テキストのみのバージョン

- 33.3.7 プレーン・テキストのパラレル・サイト

- 33.3.8 Email This Story

- 33.3.9 AssetMakerアセット・タイプ

- 33.3.10 MIMEタイプ

- 33.3.11 コレクションのコレクション

- 33.3.12 メンバーシップ

- 33.3.13 Wire Feed

- 33.3.14 Featured Funds

- 33.3.15 Fund Finder

- 33.3.16 ページ・キャッシュ・パラメータ

34 WebCenter SitesのAdminインタフェースのカスタマイズ

- 34.1 ツリーの概要

- 34.1.1 ツリー・タブのロード

- 34.1.1.1 アプレット全体のパラメータ

- 34.1.1.2 ツリー固有のパラメータ

- 34.1.1.3 ノードのパラメータ

- 34.1.1.4 ノードのコンテキスト・メニューのコマンド

- 34.1.2 ツリーのリフレッシュ

- 34.2 ツリーとセキュリティ

- 34.3 ツリーのエラー・ロギング

35 ワークフローのカスタマイズ

- 35.1 ワークフロー・ステップ条件

- 35.2 ワークフロー・アクション

- 35.2.1 ステップ・アクションのエレメント

- 35.2.2 時間指定アクションのエレメント

- 35.2.3 デッドロック・アクションのエレメント

- 35.2.4 グループ・デッドロック時のアクションのエレメント

- 35.2.5 委任アクションのエレメント

36 Webサービスの理解

- 36.1 Webサービスとは

- 36.2 SOAPとWebサービス

- 36.3 サポートされているSOAPバージョン

- 36.4 サポートされているWSDLバージョン

- 36.5 関連プログラミング・テクノロジ

37 Webサービスの作成と消費

- 37.1 事前定義されたWebサービスの使用

- 37.1.1 アクセス可能な情報

- 37.1.2 WSDLファイルの場所

- 37.1.3 事前定義されたWebサービスのプロセス・フロー

- 37.1.4 事前定義されたWebサービスに対するデータの検討

- 37.1.5 クライアント・インタフェースの生成

- 37.1.6 クライアント・コールの記述

- 37.2 カスタムWebサービスの作成

- 37.2.1 カスタムWebサービスの作成のプロセス・フロー

- 37.2.2 カスタムWebサービスに対するデータの検討

- 37.2.3 WebCenter Sitesページの作成

- 37.2.4 WebCenter Sitesエレメントの記述

- 37.2.5 WSDLファイルの作成

- 37.2.5.1 WSDLファイルのエレメントの記述

- 37.2.5.2 WSDLファイルの例

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

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

- 38.1.1 訪問者属性

- 38.1.2 履歴属性と履歴定義

- 38.1.3 セグメント

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

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

- 38.2.1 訪問者属性の作成

- 38.2.1.1 データ型の構成

- 38.2.1.2 制約基準の構成

- 38.2.1.3 属性の保存

- 38.2.2 履歴属性の作成

- 38.2.2.1 制約基準の構成

- 38.2.2.2 履歴属性の保存

- 38.2.3 履歴定義の作成

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

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

39 推奨アセット

- 39.1 推奨アセットの概要

- 39.2 開発プロセス

- 39.3 動的リスト・エレメントの作成

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

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

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

- 40.3 訪問者データの収集

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

- 40.4.1 例1: 訪問者属性

- 40.4.2 例2: 履歴定義

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

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

- 40.6 ショッピング・カートおよびEngage

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

- 40.7.1 セッション・リンク

- 40.7.2 訪問者データの収集

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

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

- 41.1 メモリー中心の訪問者追跡の概要

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

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

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

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

- 41.2.2 サポート・コード

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

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

- 41.3.1 訪問者の検出

- 41.3.2 スカラー値の取得

- 41.3.3 履歴属性値の収集

- 41.3.4 合計および数の計算

- 41.3.5 セグメントの計算

- 41.3.6 推奨されるアセットの決定および表示

- 41.3.7 依存性の記録

42 Asset APIのチュートリアル

- 42.1 Asset APIの理解

- 42.2 主要インタフェース

- 42.3 はじめに

- 42.4 Asset APIによる読取り

- 42.4.1 簡単な例: フィールド値の読取り

- 42.4.2 AssetIdの読取り

- 42.4.3 アセットIDに基づいた属性の読取り

- 42.4.4 問合せ

- 42.4.5 複雑な問合せ

- 42.4.6 ソート

- 42.4.7 BlobObjectの読取り

- 42.4.8 複数値属性の取得

- 42.4.9 多言語アセット: 翻訳の取得

- 42.4.10 アセットと属性の定義の読取り

- 42.4.11 キーと値のマッピングの読取り

- 42.5 Asset APIによる書込み

- 42.5.1 新規アセットの作成

- 42.5.2 既存のアセットの更新

- 42.5.3 既存のアセットの削除

- 42.5.4 多言語アセット

- 42.6 開発戦略

- 42.6.1 データ型と属性データ

- 42.6.2 問合せのタイプ

- 42.6.3 データ型と有効な問合せ演算

- 42.7 オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定

43 パブリック・サイト検索

- 43.1 検索フレームワークの概要

- 43.2 索引タイプ

- 43.2.1 Global索引

- 43.2.2 アセット・タイプ索引

- 43.3 検索APIの概要

- 43.3.1 SearchEngine

- 43.3.2 QueryExpression

- 43.3.3 構成

- 43.4 詳細構成

- 43.4.1 Luceneパラメータの構成

- 43.4.2 カスタムAnalyzerFactoryの構成

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

- 44.1 階層組織

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

- 44.3 手順

- 44.3.1 手順1: フレックス・ファミリの作成

- 44.3.2 手順2: 新規のフレックス・アセット・タイプの有効化

- 44.3.3 手順3: 「フレックス・ファミリ」タブのWebCenter Sitesのツリーへの追加

- 44.3.4 手順5: 親定義アセットの作成

- 44.3.5 手順6: フレックス親アセットの作成

- 44.3.6 手順7: フレックス定義アセットの作成

- 44.3.7 手順8: フレックス・アセットの作成

- 44.3.8 手順9: 定型データ・モデルを現実世界のデータ・モデルに変換

- 44.3.9 手順10: 現実世界のモデルの開発

- 44.4 次の手順

45 WebCenter SitesのURLアセンブラ

- 45.1 WebCenter SitesのURLアセンブラの概要

- 45.1.1 URLアセンブリ

- 45.1.2 アセンブラ検出と逆アセンブリ

- 45.1.3 GETリクエストとPOSTリクエストを使用するURLアセンブリとURL逆アセンブリ

- 45.2 WebCenter Sitesとともにインストールされるアセンブラ

- 45.2.1 Queryアセンブラ

- 45.2.2 QueryAsPathInfoアセンブラ

- 45.3 アセンブラの使用

- 45.3.1 アセンブラの作成

- 45.3.2 アセンブラの登録とランク付け

- 45.3.3 リンク・タグの変更

- 45.4 WebページでのバニティURLリンクの生成

46 空白と圧縮

- 46.1 空白とJSP

- 46.2 空白とXML

- 46.3 圧縮

- 46.4 JSPの設計

47 WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベント

- 47.1 イベントのタイプ

- 47.2 アセット・イベント

- 47.2.1 アセット・イベント・リスナーの記述

- 47.2.2 アセット・イベント・リスナーの登録

- 47.3 パブリッシュ・イベント

- 47.3.1 パブリッシュ・イベント・リスナーの記述

- 47.3.2 パブリッシュ・イベント・リスナーの登録

48 プロキシ・アセット: サード・パーティ・コンテンツ・ソースの統合

- 48.1 概要

- 48.2 ユーザー・インタフェースのカスタマイズ

- 48.2.1 検索スタート・メニューのカスタマイズ

- 48.2.2 コンテンツ・ツリーのカスタマイズ

- 48.3 WebCenter Sites Contributorインタフェースへの外部コンテンツの統合

- 48.3.1 事例: ダミー・リポジトリ

- 48.3.2 新しいプロキシ・アセット・タイプの登録

- 48.3.3 UI統合コードの実装

- 48.3.4 検索のカスタマイズ

- 48.3.4.1 提供済のサード・パーティAPIを使用した検索結果の取得

- 48.3.4.2 検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集

- 48.3.4.3 グリッド・ウィジェット用のデータ・ストアの作成

- 48.3.4.4 カスタム検索のテスト

- 48.3.4.5 追加のカスタマイズ

- 48.3.5 カスタム・ツリーの実装

- 48.3.5.1 カスタム・ツリー・タブの登録

- 48.3.5.2 ツリーのコードの実装

- 48.4 Webページへのプロキシ・アセットの埋込み

- 48.4.1 プロキシ・アセット用テンプレートの作成

- 48.4.2 プロキシ・アセットのスロットでの使用

- 48.4.3 プロキシ・アセットのキャッシング

49 カスタマイズ・フックのリアルタイム・パブリッシュ

- 49.1 リアルタイム・パブリッシュの概要

- 49.2 カスタム・トランスポータの作成

- 49.2.1 独自のトランスポータの作成

- 49.2.2 実装の詳細

- 49.2.3 ヘルパー・メソッド

- 49.2.4 トランスポータの実装例

- 49.2.5 完全なコードのリスト

- 49.2.6 境界状況のシナリオ

- 49.2.7 管理インスタンスでのアセット・パブリッシュ・イベントのインターセプト

- 49.2.8 最終工程

50 クローラ構成ファイルのコーディング

- 50.1 クローラ制御の概要

- 50.2 BaseConfiguratorのメソッド

- 50.2.1 getStartUri

- 50.2.2 createLinkExtractor

- 50.3 クローラのカスタマイズ・メソッド

- 50.3.1 getMaxLinks

- 50.3.2 getMaxCrawlDepth

- 50.3.3 getConnectionTimeout

- 50.4 getSocketTimeout

- 50.5 getPostExecutionCommand

- 50.6 getNumWorkers

- 50.7 getUserAgent

- 50.8 createResourceRewriter

- 50.9 createMailer

- 50.10 getProxyHost

- 50.11 getProxyCredentials

- 50.12 インタフェース

- 50.12.1 LinkExtractor

- 50.12.1.1 LinkExtractorインタフェース

- 50.12.1.2 LinkExtractorのデフォルト実装の使用

- 50.12.1.3 カスタム・リンク・エクストラクタの作成とデプロイ

- 50.12.2 ResourceRewriter

- 50.12.2.1 ResourceRewriterインタフェース

- 50.12.2.2 ResourceRewriterのデフォルト実装の使用

- 50.12.2.3 カスタムResourceRewriterの作成

- 50.12.3 Mailer

- 50.12.3.1 Mailerインタフェース

- 50.12.3.2 Mailerのデフォルト実装の使用

- 50.12.3.3 カスタムMailerの作成

- 50.13 メソッドとインタフェースの概要

- 50.13.1 メソッド

- 50.13.2 インタフェース

第II部 Developer Toolsの使用

51 Oracle WebCenter Sites: Developer Toolsについて

- 51.1 Developer Toolsのアーキテクチャ

- 51.2 IDE統合

- 51.3 Developer Toolsワークスペース

- 51.4 同期

- 51.5 JSPの管理

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

- 51.7 バージョン・コントロール・システムの使用

- 51.8 次の手順

52 Developer Tools: インストールと構成

- 52.1 前提条件

- 52.2 Developer Toolsの設定

- 52.3 Developer Toolsの更新

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

- 52.5 WebCenter Sites Developer Toolsのアンインストール

53 Developer Tools: EclipseでのWebCenter Sites機能

- 53.1 Oracle WebCenter Sitesパースペクティブ

- 53.2 構成画面

- 53.3 Eclipseのプロジェクトとワークスペース

- 53.4 Developer Toolsのビュー

- 53.4.1 Sites Work

- 53.4.2 Sites Logビュー

- 53.4.3 Sites Preview Browserビュー

- 53.4.4 Sites UIビュー

- 53.4.5 Sites Logging Configurationビュー

- 53.4.6 Sites Developer Referenceビュー

- 53.4.7 ウィザード

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

- 53.5.1 Sync to Workspace (WebCenter Sitesからのエクスポート)

- 53.5.2 Sync to WebCenter Sites (WebCenter Sitesへのインポート)

- 53.6 次の手順

54 Developer Tools: JSPの開発

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

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

- 54.3 デバッグ

55 Developer Tools: モバイルWebサイト用テンプレートの作成

- 55.1 Developer ToolsのMobilityサポートの概要

- 55.2 Developer Toolsを使用したモバイル・テンプレートの開発

56 Developer Tools: 同期とデータ交換

- 56.1 Developer Toolsを使用した同期

- 56.2 同期シナリオ

- 56.3 依存性の解決

- 56.4 IDマッピング

- 56.4.1 IDマッピングの概要

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

- 56.4.3 既存のリソースとDeveloper Toolsの併用

- 56.5 サイト・マッピング

- 56.5.1 ナチュラル・サイト・マッピング

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

57 Developer Tools: ワークスペース

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

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

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

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

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

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

58 Developer Tools: コマンドライン・ツール

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

- 58.2 コマンド例

- 58.3 モジュールの作成

59 Developer Tools: バージョン・コントロール・システムとの統合

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

- 59.2 Developer ToolsとVCSの統合

- 59.3 Developer Toolsが統合されたVCSでの作業

60 Developer Tools: 開発チーム統合のユースケース

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

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

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

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

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

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

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

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

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

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

第III部 Contributorインタフェースのカスタマイズ

62 Oracle WebCenter Sites Contributorインタフェースのカスタマイズについて

- 62.1 始める前に

- 62.2 Contributorインタフェースでカスタマイズできる内容

- 62.3 サンプル・コードの検索場所

- 62.4 開始する場所

63 Contributorインタフェース: フレームワークおよびUIコントローラについて

- 63.1 Contributorフレームワークの概要

- 63.2 UIコントローラ

- 63.2.1 UIコントローラでリクエストを処理する方法

- 63.2.2 例: エレメント・リクエストを処理するUIコントローラ

- 63.3 カスタム・エレメント

- 63.3.1 エレメント・ストレージ

- 63.3.2 UIコントローラでエレメントを検索する方法

- 63.3.3 このガイドのエレメント・ネーミング規則

64 Contributorインタフェース: ダッシュボードのカスタマイズ

- 64.1 ダッシュボード・カスタマイズの概要

- 64.2 ダッシュボードのカスタマイズ

- 64.3 ダッシュボードのカスタマイズの例

- 64.3.1 'Hello World'ウィジェットの追加

- 64.3.2 最近変更されたアセットを表示するウィジェットの追加

65 Contributorインタフェース: 検索ビューのカスタマイズ

- 65.1 検索ビューのカスタマイズの概要

- 65.1.1 検索ビューのタイプ

- 65.1.2 検索ビューでカスタマイズ可能な内容

- 65.1.3 ビューレンダリング・プロセス

- 65.1.4 検索ビューの構成エレメント

- 65.2 カスタマイズ・プロセス

- 65.3 ドッキングされていないビューのカスタマイズ

- 65.3.1 ドッキングされていないビューのカスタマイズの基本手順

- 65.3.2 デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

- 65.3.3 ドッキングされていないリスト表示のカスタマイズ

- 65.3.4 ドッキングされていないサムネイル表示のカスタマイズ

- 65.3.4.1 ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細

- 65.3.4.1.1 静的アイコンを使用する場合

- 65.3.4.1.2 システム定義のイメージ・サムネイル・エレメントを再使用する場合

- 65.3.4.1.3 カスタム・サムネイルレンダリング・エレメントを使用する場合

- 65.4 ドッキングされたビューのカスタマイズ

- 65.5 ソート・メニューおよびツールチップのカスタマイズ

- 65.5.1 ソート・メニューのカスタマイズ

- 65.5.2 検索結果のツールチップのカスタマイズ

- 65.5.3 コンテキスト・メニューのカスタマイズ

66 Contributorインタフェース: グローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ

- 66.1 グローバル構成プロパティのカスタマイズ

- 66.1.1 構成プロパティの概要

- 66.1.2 デフォルト構成プロパティの変更

- 66.1.3 カスタム構成プロパティの追加

- 66.1.3.1 カスタム・グローバル・プロパティの追加

- 66.1.3.2 サイト固有のプロパティの追加

- 66.2 ツールバーのカスタマイズ

- 66.2.1 ツールバー・カスタマイズの概要

- 66.2.2 ツールバー・カスタマイズの例

- 66.2.2.1 Webモード用の標準アクションを使用したツールバーのカスタマイズ

- 66.2.2.2 アセット・タイプおよびサブタイプ用の標準アクションを使用したツールバーのカスタマイズ

- 66.2.2.3 カスタム・アクションを使用したツールバーのカスタマイズ

- 66.3 メニュー・バーのカスタマイズ

- 66.3.1 メニュー・バー・カスタマイズの概要

- 66.3.2 カスタム・アクションのメニュー・バーへの追加

- 66.4 コンテキスト・メニューのカスタマイズ

67 Contributorインタフェース: アセット・フォームのカスタマイズ

- 67.1 アセット・フォームのカスタマイズの概要

- 67.2 アセット・フォームのヘッダーの変更

- 67.3 属性エディタの構築

- 67.3.1 Dojoウィジェットとそのテンプレートの作成

- 67.3.1.1 Dojoウィジェットのテンプレートの作成

- 67.3.1.2 Dojoウィジェットの作成

- 67.3.2 プレゼンテーション・オブジェクトとしての属性エディタの定義

- 67.3.3 属性エディタ・エレメントの作成

- 67.3.4 属性エディタの作成

- 67.3.5 複数値属性エディタの実装

第IV部 Oracle WebCenter Sites: Mobilityの構成

68 モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成

- 68.1 開発者の前提条件

- 68.2 主要なMobilityの概念

- 68.2.1 デバイス・リポジトリ

- 68.2.2 デバイス・グループおよび接尾辞

- 68.2.3 デバイス・アセット

- 68.2.4 サイト・プラン

- 68.2.5 モバイル・テンプレート

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

- 68.4 Mobility機能の構成

- 68.4.1 手順1: 「モビリティ」タブの有効化

- 68.4.2 手順2: デバイス・リポジトリの設定

- 68.4.2.1 どのデバイス・リポジトリがアクティブかの判別

- 68.4.2.2 デフォルトのデバイス・リポジトリの変更

- 68.4.2.3 サード・パーティのデバイス・リポジトリのアップロード

- 68.4.3 手順3: デバイス・グループの構成

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

- 68.4.4 手順4: デバイス・グループの優先順位付け

- 68.4.5 手順5: デバイス・アセットの作成

- 68.4.6 手順6: サイト・プランの作成

- 68.4.7 手順7: サイト・プランの編成

- 68.4.8 手順8: テンプレートの作成

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

- 68.4.8.2 Mobilityのタグ

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

- 68.5 デバイス検出

第V部 Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発

69 Webエクスペリエンス管理(WEM)フレームワークについて

- 69.1 WEMフレームワークの概要

- 69.2 アプリケーション開発の前提条件

- 69.2.1 テクノロジ

- 69.2.2 WebCenter Sitesインタフェース、オブジェクトおよびAPI

- 69.2.3 ドキュメント

- 69.2.4 サンプル・アプリケーションおよびファイル

- 69.2.5 アプリケーション・アクセス

- 69.3 はじめに

70 WEMフレームワーク: フレームワークとサービスについて

- 70.1 アプリケーション開発のサポート

- 70.2 RESTサービス

- 70.3 UIコンテナ

- 70.3.1 登録

- 70.3.2 WEMコンテキスト・オブジェクト

- 70.4 シングル・サインオン

- 70.5 認可モデル

- 70.6 カスタム・アプリケーション

- 70.7 RESTリソースの要件

71 WEMフレームワーク: Articlesサンプル・アプリケーション

- 71.1 サンプル・アプリケーションの概要

- 71.2 Articlesサンプル・アプリケーションの起動

- 71.2.1 Articlesアプリケーションのビルドおよびデプロイ

- 71.2.2 Articlesサンプル・アプリケーションの登録

- 71.3 Articlesアプリケーションのテスト

72 WEMフレームワーク: アプリケーションの開発

- 72.1 アプリケーションの構造

- 72.2 構成ファイル

- 72.3 RESTコールの実行

- 72.3.1 JavaScriptからのRESTコールの実行

- 72.3.2 JavaからのRESTコールの実行

- 72.4 バイナリ・データを処理するURLの作成

- 72.5 コンテキスト・オブジェクト: WEMフレームワークからのパラメータへのアクセス

- 72.5.1 同一ドメイン用の実装

- 72.5.2 クロスドメイン用の実装

- 72.5.3 コンテキスト・オブジェクトで使用可能なメソッド

- 72.6 登録コード

- 72.6.1 iframeビューを使用したアプリケーションの登録

- 72.6.2 JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録

- 72.6.2.1 JavaScriptビュー

- 72.6.2.2 HTMLビュー

73 WEMフレームワーク: カスタムRESTリソースの開発

- 73.1 Recommendationsサンプル・アプリケーション

- 73.1.1 アプリケーションのビルドおよびデプロイ

- 73.1.2 アプリケーションのテスト

- 73.2 RESTリソースの作成

- 73.2.1 アプリケーションの構造

- 73.2.2 カスタムRESTリソースの実装手順

74 WEMフレームワーク: 本番サイトでのシングル・サインオン

- 74.1 SSOサンプル・アプリケーションのデプロイ

- 74.2 アプリケーションの構造

- 74.3 シングル・サインオンの実装

- 74.4 シングル・サインアウトの実装

75 WEMフレームワーク: RESTリソースの使用

- 75.1 RESTリソースの認証

- 75.1.1 Javaコードからのチケットの取得

- 75.1.2 他のプログラミング言語からのチケットの取得(HTTPを経由)

- 75.1.3 チケットおよびマルチチケットの使用

- 75.1.4 スタンドアロン・アプリケーションのSSO構成

- 75.1.4.1 Beanおよびプロパティ

- 75.1.4.2 SSOフィルタで処理される問合せパラメータ

- 75.2 CASの構成

- 75.3 REST認可

- 75.3.1 セキュリティ・モデル

- 75.3.2 RESTリソースへのセキュリティ・モデルを使用したアクセス

- 75.3.3 RESTセキュリティの構成

- 75.3.4 権限解決アルゴリズム

- 75.4 RESTを介したアセットの管理

76 WEMフレームワーク: Customizable Single Sign-Onファシリティ

- 76.1 WEMフレームワークのログイン動作のカスタマイズ

- 76.2 デフォルトCSSO実装のコンポーネント

- 76.3 カスタムSSO動作の構成およびデプロイ

- 76.3.1 デフォルトCSSOクラスの拡張

- 76.3.2 Springへのインスタンス化するJavaクラスの指定

- 76.3.2.1 Spring構成ファイルの作成

- 76.3.2.2 Spring構成ファイルの配置

- 76.3.3 外部ユーザー識別子のWebCenter Sites資格証明へのマッピング

- 76.3.4 CAS Webアプリケーションの再起動

- 76.4 CSSOサンプル実装の実行

- 76.4.1 サンプルCSSOクラス

- 76.4.2 サンプルSpring構成ファイル

- 76.4.2.1 サンプルSpring構成ファイルの分析

- 76.4.2.2 サンプルSpring構成ファイルの配置

- 76.4.3 サンプルCSSOコンポーネント

77 WEMフレームワーク: バッファリング

- 77.1 アーキテクチャ

- 77.2 バッファリングの使用

78 WEMフレームワーク: アプリケーションの手動登録

- 78.1 登録手順

- 78.2 リファレンス: 登録アセット・タイプ

- 78.2.1 FW_Viewアセット・タイプ

- 78.2.2 FW_Applicationアセット・タイプ

第VI部 Community-Gadgetsアプリケーションの開発

79 Oracle WebCenter Sites: Community-Gadgetsについて

- 79.1 Oracle WebCenter Sites: Community-Gadgetsの概要

- 79.2 Community-Gadgetsの管理コンポーネントおよび本番コンポーネント

- 79.3 Oracle WebCenter Sites: Community-Gadgetsの技術概要

- 79.4 前提条件

80 Community-Gadgets: ソーシャル・ネットワーキング・サービスとの統合

- 80.1 認証プラグインについて

- 80.2 Facebookとの統合

- 80.2.1 Community-Gadgets用のFacebookアプリケーションの作成

- 80.2.2 Community-Gadgets WebアプリケーションでのFacebookアプリケーション認証設定の構成

- 80.3 Twitterとの統合

- 80.3.1 Community-Gadgets用のTwitterアプリケーションの作成

- 80.3.2 Community-GadgetsでのTwitterアプリケーション認証設定の構成

- 80.4 Googleとの統合

- 80.4.1 Community-Gadgets用のGoogleアプリケーションの作成

- 80.4.2 Community-GadgetsでのGoogleアプリケーション認証設定の構成

- 80.5 Janrainとの統合

- 80.5.1 Community-Gadgets用のJanrainアプリケーションの作成

- 80.5.2 Community-GadgetsでのJanrainアプリケーション認証設定の構成

- 80.6 Oracle Internet Access Serviceとの統合

- 80.6.1 Mobile and Socialアイデンティティ・プロバイダをサポートするためのWebLogic Serverの構成

- 80.6.2 OAM上のMobile and Socialサービスの有効化

- 80.6.3 OMSASに対するインターネット・アイデンティティ・プロバイダの定義

- 80.6.4 新しいMobile and Socialアプリケーション・プロファイルの作成

- 80.6.4.1 OAMコンソール・アプリケーションを使用したMobile and Socialアプリケーション・プロファイルの作成

- 80.6.4.2 WebLogicスクリプティング・ツール(WLST)スクリプトを使用したアプリケーション・プロファイルの作成

- 80.6.5 Community-GadgetsとOMSASの統合の有効化

- 80.7 WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化

- 80.7.1 セキュリティ証明書のエクスポート

- 80.7.2 セキュリティ証明書のWebSphereへのインポート

81 Community-Gadgets: 機能のカスタマイズ

- 81.1 Community-Gadgetsのデータ・モデルの概要

- 81.1.1 コメント

- 81.1.1.1 CommentFeed

- 81.1.1.2 CommentRecord

- 81.1.2 レビュー

- 81.1.2.1 ReviewFeed

- 81.1.2.2 ReviewRecord

- 81.1.3 評価

- 81.1.3.1 RatingFeed

- 81.1.3.2 RatingRecord

- 81.1.4 投票

- 81.1.5 トピック

- 81.1.6 訪問者

- 81.1.6.1 User

- 81.1.6.2 UserIdentity

- 81.1.6.3 UserLink

- 81.1.7 ガジェットとダッシュボード

- 81.1.7.1 Gadget

- 81.1.7.2 OpenSocialDescriptor

- 81.1.7.3 SingleGadgetData

- 81.1.7.4 GadgetSet

- 81.2 CSSおよびウィジェット・テンプレートのカスタマイズ

- 81.2.1 CSSのカスタマイズ: カラー・スキーマとスキニング

- 81.2.1.1 「コメント」ウィジェットおよび「レビュー」ウィジェットのカスタマイズ

- 81.2.1.2 他のウィジェットのカスタマイズ

- 81.2.2 ウィジェット・テンプレートのカスタマイズ

- 81.2.2.1 Communityウィジェットのテンプレートの理解

- 81.2.2.1.1 コンテキスト変数のアクセス・ポイント

- 81.2.2.1.2 動的スクリプティング

- 81.2.2.1.3 ウィジェットのソースとテンプレート

- 81.2.2.1.4 Model-View-Controllerパターン

- 81.2.2.1.5 Model-View-Controllerのリージョン

- 81.2.2.1.6 ネストされたテンプレート

- 81.2.2.1.7 カスタマイズのワークフロー

- 81.2.2.1.8 ウィジェット・テンプレート構造におけるアタッチ・ポイント

- 81.2.2.2 サンプル・テンプレートの作成

- 81.2.2.3 カスタム・データ・セットのロード

- 81.3 カスタム・ワード・フィルタの作成

- 81.4 CAPTCHAジェネレータの作成

- 81.5 ダッシュボード・テーマのカスタマイズ

- 81.6 Community-Gadgetsのイベント処理

- 81.6.1 イベントのエンティティ

- 81.6.1.1 CommentEventエンティティ

- 81.6.1.2 ReviewEventエンティティ

- 81.6.1.3 RatingEventエンティティ

- 81.6.1.4 ExternalAuthEventエンティティ

- 81.6.2 イベントのリスナー

- 81.6.2.1 単純なリスナーの作成

- 81.6.2.2 イベント通知リスナーの開発 - processメソッド

- 81.6.2.3 イベント通知リスナーの開発 - 電子メールの送信

82 Community-Gadgets: 機能のローカライズ

- 82.1 ローカライズについて

- 82.1.1 Community-Gadgetsインタフェースの言語検出

- 82.1.2 Community-Gadgetsの言語検出

- 82.2 Community-Gadgetsへの新しい言語の追加

- 82.3 Community-Gadgetsへの新しい言語の登録

83 Community-Gadgets: パフォーマンスの監視

- 83.1 キャッシュについて

- 83.2 Community-Gadgetsとキャッシュ

- 83.2.1 Community-Gadgetsの理解

- 83.2.2 標準キャッシング

- 83.2.3 失効キャッシング

- 83.2.4 キャッシングの依存関係

- 83.3 Community-Gadgetsのキャッシュの構成

- 83.4 Communityアプリケーションでのユーザー生成コンテンツ(UGC)の最適化

84 Community-Gadgets: アプリケーションのメンテナンスに関するガイドライン

- 84.1 ウィジェットのデプロイメントのガイドライン

- 84.2 ロギング・レベルの調整

- 84.2.1 log4jログ出力の構成

- 84.2.2 SEOウィジェットのJARファイルのロギングの有効化

- 84.3 問題の報告

85 Community-Gadgets: Communityのウィジェット・タグの分析

- 85.1 「コメント」のウィジェット・タグ

- 85.1.1 「コメント」ウィジェット・タグ

- 85.1.2 「コメント・サマリー」ウィジェット・タグ

- 85.1.3 「トピックへのリンク」ウィジェット・タグ

- 85.1.3.1 「トピックへのリンク」ウィジェット・タグ(「コメント」用)のデプロイ

- 85.1.4 「最近コメントされた」ウィジェット・タグ

- 85.1.5 「最もコメントが多い」ウィジェット・タグ

- 85.2 「レビュー」のウィジェット・タグ

- 85.2.1 「レビュー」ウィジェット・タグ

- 85.2.2 「レビュー・サマリー」ウィジェット・タグ

- 85.2.3 「トピックへのリンク」ウィジェット・タグ

- 85.2.3.1 「トピックへのリンク」ウィジェット・タグ(「レビュー」用)のデプロイ

- 85.2.4 「平均評価のレビュー」ウィジェット・タグ

- 85.2.5 「上位ランクのレビュー」ウィジェット・タグ

- 85.2.6 「最近レビューされた」ウィジェット・タグ

- 85.2.7 「最もレビューされている」ウィジェット・タグ

- 85.3 「評価」のウィジェット・タグ

- 85.3.1 「星評価」ウィジェット・タグ

- 85.3.2 「サムズ・アップ/ダウン評価」ウィジェット・タグ

- 85.3.3 「Like評価」ウィジェット・タグ

- 85.3.4 「お薦め評価」ウィジェット・タグ

- 85.3.5 「評価の平均評価」ウィジェット・タグ

- 85.3.6 「最近評価された」ウィジェット・タグ

- 85.3.7 「最も評価が高い」ウィジェット・タグ

- 85.4 「ログイン・バー」のウィジェット・タグ

- 85.5 「投票」のウィジェット・タグ

- 85.5.1 メインの「投票」ウィジェット・タグ

- 85.5.2 「投票結果」ウィジェット・タグ

86 Community-Gadgets: CommunityウィジェットでのSEOサポートの有効化

- 86.1 概要

- 86.2 SEOサポートの有効化

87 Community-Gadgets: CSSタグのデプロイ

- 87.1 概要

- 87.2 CSSタグのデプロイ

第VII部 Community Blogsの開発

88 Community Blogs: データ・モデル

- 88.1 Blogフレックス・ファミリの概要

- 88.2 フレックス・ファミリのメンバー

- 88.2.1 デフォルトのブログ属性

- 88.2.2 デフォルトのブログ・カテゴリ定義およびブログ・カテゴリ

- 88.2.3 デフォルトのブログ・アセット定義およびブログ・アセット

- 88.2.4 デフォルトのブログ作成者カテゴリ定義およびブログ作成者カテゴリ

- 88.2.5 デフォルトのブログ作成者定義およびブログ作成者

- 88.2.6 デフォルトのブログ・フィルタ

89 Community Blogs: サンプル・ブログ・ページ

- 89.1 サンプル・ブログ・ページの概要

- 89.2 サンプル・ブログ・ページのコンポーネント

- 89.2.1 デフォルトのブログのCSElement

- 89.2.2 デフォルトのブログのSiteEntryアセット

- 89.2.3 デフォルトのブログのテンプレート

- 89.2.4 ブログ・アーカイブの「詳細」リンク機能

- 89.3 次の手順

90 Community Blogs: ブログ・コンポーネントのカスタマイズ

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

- 90.1.1 ブログ属性の作成

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

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

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

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

- 90.2.3 Community-Gadgetsの機能の追加

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

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

第VIII部 ガジェットの開発

91 ガジェットの開発について

- 91.1 始める前に

- 91.2 ガジェットの仕様

- 91.2.1 アセット・モデルとテンプレート

- 91.2.2 サンプル・アセット

- 91.2.3 補助ファイル

- 91.3 サンプル・ガジェット

- 91.3.1 Listガジェット

- 91.3.2 ThumbListガジェット

- 91.3.3 Slideshowガジェット

- 91.3.4 RSS Feedガジェット

- 91.4 アセットの構造

92 Gadgets: テンプレート・フロー

- 92.1 Listガジェットのテンプレート・フロー

- 92.2 テンプレート・フローの違い

- 92.2.1 ThumbListとSlideshow

- 92.2.2 RSS

- 92.3 サーバー・コールが個別に行われる理由

93 Gadgets: 独自のガジェットの作成

- 93.1 別のCMサイトでのガジェットの作成

- 93.2 カスタム・ガジェット

- 93.2.1 新しいガジェット、WebCenter SitesはXMLのみを生成

- 93.2.2 新しいガジェット、WebCenter SitesはXMLおよびフィールドの追加リクエストを生成

- 93.2.3 同じガジェット・ロジック、異なるコンテンツ

- 93.2.4 サンプルのRSSFeedガジェットの分析

- 93.3 ガジェット登録の前提条件

第IX部 CIP用のJavaコネクタおよびプラグインの開発

94 カスタム・ソース・システムとの統合

- 94.1 WebCenter Sites: Content Integration Platformのカスタマイズ

- 94.2 Content Integration Agent

95 アダプタおよびプラグインの作成

- 95.1 アダプタおよびプラグインの作成の概要

- 95.2 Javaソース・アダプタの作成

- 95.3 Javaプラグインの作成

- 95.4 javafacilityの有効化

- 95.5 トラブルシューティングとデバッグ

はじめに

このガイドでは、Oracle WebCenter Sitesを開発して、コンテンツ・コントリビュータおよび管理者向けの高度にインタラクティブなデスクトップ用およびモバイル用のWebサイトを作成、管理、配信する方法について説明します。

対象読者

このガイドは、主に開発者を対象としています。開発者は、会社のビジネス・ニーズを把握しており、オンライン・サイトおよびそのバック・エンドの開発における各自の役割を基本的に理解していることが前提です。このガイドは、開発者と協力して、コンテンツ管理サイト、サイト・ユーザー、ワークフロー・プロセス、公開方法およびOracle WebCenter Sitesクライアント・オプションを設定する管理者にとっても役立ちます。

開発者には、Java、JavaServer Pages (JSP)、XMLおよびHTMLの知識が必要です。管理者にはプログラミングの経験は必要ありませんが、技術的なバックグラウンドはあると見なされます。

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

オラクル社のアクセシビリティについての詳細情報は、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 WebCenter Sites動作保証マトリックス

- Oracle WebCenter Sitesリリース・ノート

- Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド

- Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド

- Oracle Fusion Middleware WebCenter Sites管理者ガイド

- Oracle Fusion Middleware WebCenter Sitesタグ・リファレンス

- Oracle Fusion Middleware WebCenter Sites Java APIリファレンス

- Oracle Fusion Middleware WebCenter Sites: サポート・ソフトウェアのインストールと構成

- Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス

- Oracle Fusion Middleware WebCenter Sites REST APIリソース・リファレンス

- Oracle Fusion Middleware WebCenter Sites REST API Beanリファレンス

表記規則

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

規則

意味

太字

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

イタリック体

イタリックは、ドキュメントのタイトルまたは強調を示します。または、ユーザーが特定の値を指定するプレースホルダや変数を示します。

固定幅フォント

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

このガイドの新機能

ここでは、WebCenter Sites 11gリリース1 (11.1.1.8.0)の新機能と変更された機能、およびこのガイドで説明されている重要な変更について説明し、詳細情報の参照先を示します。また、非推奨の機能についてもリストします。

11gリリース1 (11.1.1.8.0)の新機能と変更された機能

WebCenter Sites 11gリリース1 (11.1.1.8.0)には、このガイドで説明されている次の新機能と変更された機能が含まれます。

- 新機能

- WebCenter Sites: Mobility。この機能では、モバイル・デバイス(携帯電話やタブレットなど)用のWebサイトの作成、プレビューおよび配信がサポートされます。詳細は、第IV部「Oracle WebCenter Sites: Mobilityの構成」の第68章「モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成」を参照してください。
モバイルWebサイトのレンダリング用のテンプレート作成機能もWebCenter Sites: Developer Toolsに追加されました。詳細は、第55章「Developer Tools: モバイルWebサイト用テンプレートの作成」を参照してください。

- プロキシ・アセット・タイプ・フレームワーク。この機能は、WebCenter Sitesで提供されるWebサイトへの外部Webコンテンツの統合を有効にします。詳細は、第48章「プロキシ・アセット: サード・パーティ・コンテンツ・ソースの統合」を参照してください。

- バニティURL。この機能を使用すると、ユーザーは、WebページにユーザーフレンドリなURLを作成できます。開発者はrender:gettemplateurlを使用して、バニティURLリンクを作成します。詳細は、第45章「WebCenter SitesのURLアセンブラ」の第45.4項「WebページでのバニティURLリンクの生成」を参照してください。バニティURLの追加情報については、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』および『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- Oracle Real-Time Decisionsとの統合。この機能では、サイトの訪問者にとって最適なオプションを動的に推奨することにより、訪問者の決定を支援します。詳細は、第40章「Engageページのコーディング」の「Oracle Real-Time Decisionsを使用した推奨のテンプレートの作成」を参照してください。

- 変更された機能

- 「新機能」で説明しているように、WebCenter Sites: Developer ToolsでWebCenter Sites: Mobilityがサポートされるようになりました。第52章「Developer Tools: インストールと構成」には、このリリースでのWebCenter Sites: Developer Toolsのインストール手順が記載されています。

- WebCenter SitesのContributorインタフェースのカスタマイズ。コンテキスト・メニューの構成が、config.contextMenusプロパティによって定義されるようになりました。詳細は、第66.4項「コンテキスト・メニューのカスタマイズ」を参照してください。

- WebCenter SitesのCommunity-Gadgetsアプリケーションのパッケージ化。これらのアプリケーションは、独自のインタフェースを持つWebエクスペリエンス管理(WEM)フレームワークのアプリケーションとしてそのまま残されますが、WebCenter Sites: Community-GadgetsというWebアプリケーションとして一緒にパッケージ化されるようになりました。この変更を反映するため、第VI部「Community-Gadgetsアプリケーションの開発」の内容が更新されました。

- ドキュメントの統合
このガイドの内容は、個別のドキュメントとして提供されていた開発者向けのドキュメントを統合したものです。このガイドには、次のトピックが追加されています。

- WebCenter Sites: Site Captureクローラ・コード。詳細は、第50章「クローラ構成ファイルのコーディング」を参照してください。この章では、BaseConfiguratorクラスに関する情報と、このクラスのメソッドおよびインタフェースを実装してクローラのサイト・キャプチャ・プロセスを制御する方法について説明します。また、FirstSiteIIクローラのSite Captureインストールに使用できるサンプル・コードについても説明します。

- 第II部「Developer Toolsの使用」。この部では、Eclipse統合開発環境(IDE)にOracle WebCenter Sitesを統合するために使用されるツールキットについて説明します。Developer Toolsキットを使用すると、開発者は、Eclipse IDEとバージョン・コントロール・システム(VCS)を使用して分散環境で作業できるようになります。

- 第III部「Contributorインタフェースのカスタマイズ」。この部では、ダッシュボード、検索ビュー、グローバル・プロパティ、ツールバー、メニュー・バー、コンテキスト・メニュー、アセット・フォームなどのContributorインタフェース機能のカスタマイズ・プロセスについて説明します。

- 第IV部「Oracle WebCenter Sites: Mobilityの構成」

注意:

この部は新規箇所です。ここでは、新機能であるWebCenter Sites: Mobilityについて説明します。また、そのフレームワークを構成してモバイルWebサイトの開発をサポートする方法を示します。

- 第V部「Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発」。この部では、WEMフレームワークの概要、アプリケーションおよびRepresentational State Transfer (REST)のカスタム・リソースの開発プロセス、シングル・サインオン(SSO)の実装およびカスタマイズ方法について説明します。

- 第VI部「Community-Gadgetsアプリケーションの開発」。この部では、Community-Gadgetsアプリケーションと、Facebook、Twitter、Google、Janrainとのアプリケーションの統合プロセスについて説明します。この部では、Community-Gadgetsのカスタマイズ方法、その機能の各種言語への翻訳方法、およびCommunity-Gadgets Webサイトのプレゼンスの管理方法についても説明します。

- 第VII部「Community Blogsの開発」。この部では、ブログ・データ・モデルをカスタマイズするための手順が記載されています。また、テンプレート・コードについて説明し、様々なコンテンツ管理サイトのブログ機能の開発に関するガイドラインを示します。

- 第VIII部「ガジェットの開発」。この部では、テンプレート開発者向けに、Oracle WebCenter Sites: Gadgetsアプリケーションのガジェット作成プロセスについて紹介します。この部を通じて、Gadgetsアプリケーションに同梱されているサンプル・ガジェットが、開発タスクを説明するために使用されます。

- 第IX部「CIP用のJavaコネクタおよびプラグインの開発」では、Oracle WebCenter Sites: Content Integration Platformをどのように拡張して、選択したシステムからOracle WebCenter Sitesへパブリッシュするかを開発者に示します。

非推奨に関する注意点

次の機能は、WebCenter Sites 11gリリース1 (11.1.1.8.0)で非推奨になりました。

- SOAPベースのWebサービス。この機能は、RESTサービスに置き換えられました。

- ミラー・パブリッシュ。この機能は、リアルタイム・パブリッシュに置き換えられました。

- 静的パブリッシュ

- ページ・デバッグ

- WebCenter Sitesデスクトップ

- WebCenter Sites: DocLink

第I部

Oracle WebCenter Sitesの開発

この部では、Oracle WebCenter Sites開発者の環境について説明します。はじめにOracle WebCenter Sitesの概要と、コンテンツ管理(CM)フレームワークを作成するために実行する開発プロセスを示します。以降は、オンライン・サイトのフレームワークを構築する主要タスクについて説明します。

オンライン・サイトのフレームワークを構築するには、データ・モデルを開発し、さらに組織の業務を最適に表すルック・アンド・フィールでコンテンツを配信するようにコードの設計と作成を行う必要があります。また、ページ・キャッシング、セキュリティおよびセッション管理の技術を実装し、オプション機能(アドオン製品で提供されるWebサービスや機能など)を実装する必要があります。

この部では、WebCenter Sitesの開発方法について説明します。この部は、次の章で構成されています。

- 第1章「Oracle WebCenter Sitesの概要」

- 第2章「コンテンツ管理サイトについて」

- 第3章「Oracle WebCenter Sitesの開発プロセス」

- 第4章「Oracle WebCenter Sitesを使用したプログラミング」

- 第5章「ページのデザインとキャッシング」

- 第6章「WebCenter Sitesのインテリジェント・キャッシュ管理」

- 第7章「ページ・キャッシングの高度な手法」

- 第8章「WebCenter Sitesのツールおよびユーティリティ」

- 第9章「セッションおよびCookie」

- 第10章「エラー・ロギングおよびデバッグ」

- 第11章「データ・デザイン: アセット・モデル」

- 第12章「WebCenter Sitesデータベース」

- 第13章「アセットを保持しない表内のデータ管理」

- 第14章「結果セットのキャッシングと問合せ」

- 第15章「ベーシック・アセット・タイプの設計」

- 第16章「フレックス・アセット・タイプの設計」

- 第17章「フレックス・フィルタ」

- 第18章「属性エディタの設計」

- 第19章「付属の属性エディタの構成」

- 第20章「任意タイプのアセットのインポート」

- 第21章「フレックス・アセットのインポート」

- 第22章「BulkLoaderユーティリティによるフレックス・アセットのインポート」

- 第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」

- 第24章「テンプレートとラッパーの作成」

- 第25章「コンテキスト内編集およびプレゼンテーション編集用テンプレートのコーディング」

- 第26章「コレクション・アセット、問合せアセットおよびページ・アセットの作成」

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

- 第28章「テンプレートおよびCSElementのエレメントのコーディング」

- 第29章「ベーシック・アセットのテンプレート・エレメント例」

- 第30章「多言語サポートのサイトの構成」

- 第31章「配信システムにおけるユーザー管理」

- 第32章「HelloAssetWorldサンプル・サイト」

- 第33章「Burlington Financialサンプル・サイト」

- 第34章「WebCenter SitesのAdminインタフェースのカスタマイズ」

- 第35章「ワークフローのカスタマイズ」

- 第36章「Webサービスの理解」

- 第37章「Webサービスの作成と消費」

- 第38章「訪問者データ・アセットの作成」

- 第39章「推奨アセット」

- 第40章「Engageページのコーディング」

- 第41章「メモリー中心の訪問者追跡」

- 第42章「Asset APIのチュートリアル」

- 第43章「パブリック・サイト検索」

- 第44章「階層的なフレックス・ファミリの作成」

- 第45章「WebCenter SitesのURLアセンブラ」

- 第46章「空白と圧縮」

- 第47章「WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベント」

- 第48章「プロキシ・アセット: サードパーティ・コンテンツ・ソースの統合」

- 第49章「カスタマイズ・フックのリアルタイム・パブリッシュ」

- 第50章「クローラ構成ファイルのコーディング」

1 Oracle WebCenter Sitesの概要

Oracle WebCenter Sitesは、パフォーマンスの優れた大規模なコンテンツ管理および配信システムです。ユーザーとユーザーの開発チームは、Oracle WebCenter Sitesを使用して、大規模で複雑なWebサイトや業務を実行するサイト、およびその他のタイプのサイトを作成および管理します。これらのサイトはすべて、オンライン・サイトまたはWebサイトと総称されます。

次の各項では、WebCenter Sitesの概要について説明します。

- 第1.1項「コンテンツ・エントリ・フォームからWebサイトまで」

- 第1.2項「動的Webサイトの開発」

- 第1.3項「WebCenter Sitesのデータ設計」

- 第1.4項「プレゼンテーション・ロジック」

- 第1.5項「WebCenter Sitesのシステム」

- 第1.6項「承認およびパブリッシュ」

- 第1.7項「パフォーマンス: キャッシング」

- 第1.8項「WebCenter Sitesのインタフェース」

- 第1.9項「サンプル・サイト」

注意:

WebCenter Sites 11gリリース1 (11.1.1.8.0)では、サイト・デスクトップ、サイトDocLink、静的パブリッシュの機能が非推奨になりました。

1.1 コンテンツ・エントリ・フォームからWebサイトまで

WebCenter Sitesの開発者の仕事はコンテンツ・エントリ・フォームを作成することであり、そのフォームは、Webサイトのコンテンツを作成するために、後でコントリビュータが使用します。　また、JSPの開発も行います。これは、コンテンツ・エントリ・フォームをWebモードでレンダリングし、Webサイトにパブリッシュされたコンテンツをレンダリングするものです。コンテンツを世間に配信する準備ができたら、動的と静的のいずれかのパブリッシングを使用してWebサイトにパブリッシュできます。

図1-1 コンテンツ・エントリ・フォーム

図1-2 Webサイト(オンライン・サイト)

1.2 動的Webサイトの開発

WebCenter Sitesでは、静的と動的両方のページがサポートされています。動的ページの生成はその主な機能であり、このガイドのこの項のテーマです。

WebCenter Sitesの動的ページと典型的なHTMLページの違いは、次の表に示すとおりです。

表1-1 静的ページと動的ページの比較

静的ページ(HTMLページ)

動的ページ(WebCenter Sitesページ)

単一のディスク・ファイルで、Webサーバーを介してサイトが提供されます。

要求時に構成および作成されます。

HTMLページと、訪問者のWebブラウザに表示されるページの間での、1対1の関連付。

訪問者の画面に表示されるWebページは、WebCenter Sites内から作成されるページレットという複数のコンポーネントで構成できます。

プレゼンテーションとコンテンツは分離されません。そのため、プレゼンテーションとコンテンツをお互いと無関係に変更することは困難です。

プレゼンテーションとコンテンツは分離されます。そのため、プレゼンテーションとコンテンツをお互いと無関係に変更して保持することができます。

1.3 WebCenter Sitesのデータ設計

開発者は、WebCenter Sitesによって提供されるデータ・モデルを使用して、(図1-1に示す)コンテンツ・エントリ・フォームを作成し、そのフォームは、Webサイトのコンテンツを作成するためにコントリビュータが使用します。コンテンツ・エントリ・フォームの各フィールドは、1つのデータベース表(または複数の表)で対応する列にマップされます。

WebCenter Sitesでサポートされているデータ・モデルは次のとおりです。

- WebCenter Sitesベーシック・アセット・モデル。水平なデータ構造をサポートします。これは、ベーシック・アセットはお互いのプロパティ(このガイドでは属性と呼称)を継承できないという意味です。コンテンツはWebCenter Sitesのユーザーによって入力され、アセットというオブジェクトとしてWebCenter Sitesデータベースに格納されます。アセットの各タイプは、データベース内の1つのプライマリ記憶域表に格納されるので、あるタイプのベーシック・アセットを別のタイプのベーシック・アセットに関連付けることができます。

- WebCenter Sitesフレックス・アセット・モデル。総合的なデータ・モデルで、それぞれのアセット・タイプは複数の記憶域表を使用できるので、階層的なデータ構造が作成でき、子アセットは親アセットから属性値を継承します。フレックス・アセット・モデルでは、その独自フレームワーク内で水平データ構造もサポートされます。(フレックス・アセット・モデルはベーシック・アセット・モデルと無関係に機能し、2つのモデル内で作成された表は交差しません。)

フレックス・アセット・モデルとベーシック・アセット・モデルのどちらを選択するかは、訪問者へのサービス提供を計画しているデータの複雑さによって決まります。フレックス・アセット・モデルはこれまで、製品の大規模なオンライン・カタログの作成に使用されてきました。ただし、あまり複雑でない状況で使用することもできます。特に使用することが好ましいのは、水平データ構造を階層構造に最終的に変換することを意図している場合です。この変換プロセスでは、データの再作成は不要です。

1.4 プレゼンテーション・ロジック

開発者は、Webサイト上のコンテンツのレンダリングに使用されるコード・テンプレートおよびエレメントに、APIとJSPタグを使用します。この項では、コーディングのプロセスで使用するプログラミング・コンポーネントの概要について説明します。

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

- 第1.4.1項「エレメントのファイル」

- 第1.4.2項「APIおよびJSPタグ」

- 第1.4.3項「セッションおよびCookie」

- 第1.4.4項「WebCenter Sitesのユーティリティ」

- 第1.4.5項「Webサイト・ナビゲーション」

1.4.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.BurlingtonFinancial.com/servlet/ContentServer?pagename=BurlingtonFinancial/Home

WebCenter SitesのURLの最後にあるテキストはページ名と呼ばれます。この例では、ページ名はBurlingtonFinancial/Homeです。

3. WebCenter SitesはSiteCatalog表でページ名を調べ、そのルート・エレメントを判別し、そのエレメントをElementCatalog表の中で検索して、そのエレメントを起動します。

4. エレメントが実行されます。ルート・エレメント内から他のエレメントへのコールがある場合は、次にそれらのエレメントが実行されます。

5. イメージや記事など、HTMLタグを含めた結果がHTMLコードにレンダリングされ、訪問者のブラウザに返されます。

その結果は、要求時に動的にレンダリングされるページです。

1.4.2 APIおよびJSPタグ

WebCenter Sitesには、エレメントのコーディングに使用するタグ・ファミリがいくつか含まれています。このタグ・ファミリを使用すると、アセットを特定し、抽出してWebサイトに表示できます。WebCenter SitesにはJavaメソッドとJavaユーティリティも用意されており、それらは、Webサイトの設計、独自のコンテンツ管理アプリケーションの開発、およびWebCenter Sitesのモジュール/製品のカスタマイズに使用できます。

注意:

ベーシック・データ・モデルを使用するアセットを表示するページのコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。カスタム・タグのすべてについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

WebCenter Sitesオペレーティング・システムは、アプリケーション・サーバーのさらに上で稼働する複数のサーブレットで構成されています。それぞれのサーブレットは、必要に応じて、不連続なタスクを実行するために起動されます。それぞれのサーブレットには、対応するJava APIとJavaメソッドおよびJSPタグがあり、それらは、使用する必要のある機能を起動するために使用します。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およびページへのリンクのコーディングについては、第4章「Oracle WebCenter Sitesを使用したプログラミング」および第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

1.4.3 セッションおよびCookie

WebCenter Sitesでは、初めてWebサイトを訪問したときに、その訪問者のセッションが自動的に作成されます。その訪問者の情報は、WebCenter Sitesコアでタグおよびメソッドを使用することによって、セッション変数に格納できます。後続のエレメントは、その後それらの変数にアクセスし、条件付きで応答できます。

ただし、セッション変数は変化しやすいものです。これらは、セッションが持続している間、つまり次のイベントのいずれかが発生するまで持続するにすぎません。

- 訪問者が自分のブラウザを閉じます。

- 非アクティブになっている期間が経過してセッションがタイムアウトします。futuretense.iniファイル内のcs.timeoutプロパティを通じて、セッション・タイムアウトを制御します。

- アプリケーション・サーバーが再起動されます(クラスタ内にある場合は除く)。

- セッションが他のなんらかのやり方で無効になります。

情報をより永続的に格納するには、Cookieを使用します。訪問者の情報をその人のブラウザに格納するCookieを記述するようにエレメントをコーディングできます。次に、格納された情報を使用し、ページをカスタマイズして、該当する訪問者がWebサイトに戻ってきたときに適切なバージョンのページを表示するようにできます。

セッションとCookieの詳細は、第9章「セッションおよびCookie」を参照してください。

1.4.4 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データベースに大量のデータを高速インポートします。

- プロパティ・エディタ: プロパティ・ファイル(システム構成ファイル)の表示と整理を行います。

1.4.5 Webサイト・ナビゲーション

現在ログインしているコンテンツ管理サイトのWebサイト・ナビゲーションは、WebCenter SitesのAdminインタフェースの「サイト・プラン」タブで表されます。

コンテンツ管理サイトと「サイト・プラン」タブについては、第2章「コンテンツ管理サイトについて」を参照してください。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

1.5 WebCenter Sitesのシステム

コンテンツ管理ニーズについてWebCenter Sitesを操作するときには、チームの人間が協力して、最大で次に示す4種類のシステムを操作します。

- 開発システム: 開発者と設計者が、Webサイトの計画立案と作成を行います。
購入したWebCenter Sites製品のすべてが、このシステムにインストールされています。

- 管理システム: ライター、編集者、グラフィック・アーティスト、マーケッターなどのコンテンツ・プロバイダには、Webサイトの訪問者に配信されるコンテンツを開発するために、コンテンツ管理サイトが割り当てられます。リビジョン追跡機能とワークフロー機能では、アセット(コンテンツ)に対する変更が追跡され、配信システムへのパブリッシュが承認されるまでアセット(コンテンツ)が監視されます。
コンテンツ管理サイトは、実際のWebサイトを表しています。たとえば、Webサイトの別々のセクションに対して、別々のコンテンツ管理サイトを作成できます。各セクションにコンテンツを提供するチームは、お互いにまったく別々であり、そのセクション(コンテンツ管理サイト)にアクセスできるのはそのチームのメンバーのみとなるからです。または、avisportsのサンプル・サイトと同様の、Webサイト全体を表すコンテンツ管理サイトを作成することもできます。コンテンツ管理サイトの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- 配信システム: 使用可能にしているコンテンツまたは販売している製品が、訪問者または顧客に提供されます。
コンテンツを動的に配信する場合、購入したWebCenter Sites製品のすべてが、このシステムにインストールされています。コンテンツを静的に配信する場合、つまり、静的なHTMLページを提供する場合は、配信システムはWebサーバーのみであり、そのシステムには、WebCenter Sites製品のいずれもインストールする必要はありません。

- テスト・システム: 開発者またはQAエンジニアが、管理システムと配信システムの両方のパフォーマンスをテストします。専用のテスト・システムが使用できない場合は、テストは開発システムで実行できます。

開発者は、時間の大部分を開発システムでの作業に費やします。開発するアセット・タイプおよび設計したサイトの準備ができたら、できあがったものを開発システムから管理システムに移行(パブリッシュ)します。管理システムでコンテンツ・プロバイダによってアセットが作成、変更および承認されると、管理システムから配信システムにパブリッシュされます。

1.6 承認およびパブリッシュ

前の項で説明したように、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 Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

エレメントをコーディングして依存関係を適切にログに記録する処理、および承認依存関係をWebCenter Sitesがどのように計算するかについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

アセットの承認については、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』および『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

1.7 パフォーマンス: キャッシング

開発者は、WebCenter Sitesでサポートされている多様なキャッシング・フレームワークを実装して、自社のWebサイトのパフォーマンスを最適化します。WebCenter Sitesでは、Satellite Serverキャッシングの使用もサポートされています。このキャッシングでは、WebCenter Sitesシステムの第2レベルのキャッシングが実現し、Webページのリモート・キャッシュとして使用することもできます。デフォルトでは、WebCenter SitesとSatellite Serverは、ページのキャッシング・フレームワークとしてinCacheを使用します。

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

- 第1.7.1項「ページのキャッシング」

- 第1.7.2項「結果セットのキャッシング」

- 第1.7.3項「アセットのキャッシング」

- 第1.7.4項「Satellite Server」

1.7.1 ページのキャッシング

ページのキャッシングはテンプレート・レベルで実装され、WebCenter Sitesシステムでページをキャッシュするために使用されます。ページのキャッシングは、システム・パフォーマンスにおいて重大な役割を果たしています。エレメントが変更されず、かつ起動されるたびに同じページが生成されるのであれば、エレメントがコールされるたびにWebCenter Sitesにエレメントを処理させる必要などありません。生成されたページがキャッシュされる場合、最初に生成を必要とする場合に比べて、ずっと迅速に提供できます。

(Satellite Serverと無関係に) WebCenter Sitesのみで、SiteCatalog表のページ・エントリによって特定される各ページまたは各ページレットを別々にキャッシュできます。その表におけるそのページ・エントリの値を指定することによって、キャッシュ内の任意のページレットの有効期限をマークすることができます。

ページのキャッシングは、Satellite Serverを追加することで特に有効になります。Satellite Serverのアプリケーションをインストールすると、Satellite Serverをホストするサーバーにページ・キャッシュをインストールすることになり、それによってWebCenter Sitesページ・キャッシュが拡張されます。

- ページのキャッシングについては、第5章「ページのデザインとキャッシング」を参照してください。

- inCacheページのキャッシングについては、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- Satellite Serverについては、第1.7.4項「Satellite Server」を参照してください。

1.7.2 結果セットのキャッシング

結果セットのキャッシングは、システム・パフォーマンスを大幅に拡張できる別の機能です。WebCenter Sitesデータベースに対して、任意のメカニズムによって問合せが行われると、WebCenter Sitesアプリケーションは、返す結果セットをキャッシュできます。WebCenter Sitesアプリケーションは、データベース内のすべての表を追跡します。表が変更されると常に、その表のためにキャッシュされた結果セットがすべてフラッシュされます。

結果セットのキャッシングの詳細は、第14章「結果セットのキャッシングと問合せ」を参照してください。

1.7.3 アセットのキャッシング

アセットのキャッシングは、inCacheフレームワーク上に構築された、メモリーをベースにしたシステムで、そのままではデータベースに影響を与えるような負荷を占有することによって、WebCenter Sitesのパフォーマンスを最適化します。WebCenter Sitesでは、アセットのプログラム的な使用は、その属性のローディングとレンダリングで構成されます。アセットは、WebCenter Sitesデータベースに格納されているテンプレートによってロードされるため、AssetCacheはWebCenter Sitesノードでのみ使用されます。アセットのキャッシングにはAssetCacheコンテナ・コンポーネントが含まれており、そのコンポーネントは、アセットをキャッシュして既存のinCacheコンポーネントと対話することによって機能します。

inCacheフレームワークとアセットのキャッシングの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

1.7.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.7.4.1 HTTPリクエストの処理

ページに対するHTTPリクエストをロード・バランサがSatellite Serverにルーティングすると、Satellite Serverは、ページがキャッシュの中にあるとそのページを提供し、ページがキャッシュされていないとHTTPリクエストをWebCenter Sitesに転送します。イベントのベーシックなチェーンは次のとおりです。

1. Satellite Serverがそのキャッシュをチェックします。

2. 次に何を行うかは、Satellite Serverキャッシュにページが格納されているかどうかによって異なります。

表1-2 Satellite Serverキャッシュにページが格納されている場合とSatellite Serverキャッシュにページが格納されていない場合の比較

Satellite Serverキャッシュにページが格納されている

Satellite Serverキャッシュにページが格納されていない

Satellite Serverが、訪問者のブラウザにページを提供します。

この場合は、Satellite ServerはWebCenter Sitesデータベースにリクエストを転送する必要がないため、WebCenter Sitesデータベースにかかる負荷は軽減します。

- Satellite Serverが、WebCenter Sitesにリクエストを転送します。

- WebCenter Sitesでは、キャッシュにページが格納されている場合は、そのキャッシュされたページがSatellite Serverに返されます。WebCenter Sitesのキャッシュにページが格納されていない場合は、ページがレンダリングされ、コピーがキャッシュされてSatellite Serverに送信されます。

- Satellite Serverが、ページをキャッシュして訪問者のブラウザに提供します。再度要求されたら、ページはSatellite Serverキャッシュから提供され、WebCenter Sitesデータベースにかかる負荷は軽減します。

各Satellite Serverアプリケーションは、それ以外のあらゆるSatellite Serverアプリケーションと無関係です。個々のSatellite Serverアプリケーションには、次のような特徴があります。

- 独自のキャッシュを保持します。

- 別のSatellite Serverアプリケーションからは、ページもページレットも要求できません。ページまたはページレットを要求できるのは、WebCenter Sitesコアからのみです。

1.7.4.2 Satellite Serverのサーブレット

Satellite Serverはいくつかのサーブレットで構成されています。次に示すように、ページのキャッシュと提供を行うサーブレットが1つ、キャッシュを管理するサーブレットが2つです。

- Satellite: ページレット・レベルでページをキャッシュします。Satelliteのエレメント内にあるXMLタグまたはJSPタグは、どのページレットをキャッシュする必要があるかを示し、Satellite Serverの各種設定を制御します。

- Inventory: Satellite Serverキャッシュを調べ、必要に応じて、キャッシュから個々のページまたはページレットを手動でフラッシュするために必要な情報を入手できるようにします。

- FlushServer: すべてのタイプのキャッシュ・フラッシュを処理します。FlushServerでは、キャッシュ全体をフラッシュすることも、キャッシュ内の個々のアイテムをフラッシュすることもできます。

Satellite Serverのタグおよびページのキャッシングを使用したページのコーディング全般については、第5章「ページのデザインとキャッシング」を参照してください。

1.8 WebCenter Sitesのインタフェース

この項では、WebCenter Sitesのインタフェースの概要について説明します。開発者は主に、WebCenter SitesのAdminインタフェースで作業します。

- Adminインタフェースは、開発者および管理者向けに設計されています。このインタフェースでは、管理者はWebCenter Sitesの管理と構成ができます。

左側のツリー・パネルには、開発者と管理者が操作する必要のあるコンテンツ管理エレメントがすべて含まれています。右側の作業領域は、すべてのタスクと操作が実行される場所です。

Adminインタフェースではコードをベースにした操作がサポートされており、ベーシック・アセット・タイプの作成をグラフィカルに完了できます。たとえば、ベーシック・アセット・タイプを作成する手順は次のとおりです。

1. (アセット記述子ファイルと呼ばれる) XMLファイルを記述して、ベーシック・アセット・タイプを定義します。

2. このファイルをWebCenter Sitesにアップロードします。

3. WebCenter Sitesのこのインタフェースを使用して、AssetMakerユーティリティを起動します。このインタフェース(AssetMaker)の機能の1つは、アセット記述子ファイルを読み取り、そこからこのアセット・タイプの記憶域表を作成します。このインタフェースで他の機能を使用すると、アセット・タイプを構成できます(たとえば、その認可されたユーザーの名前を付ける)。

管理者は同じインタフェースを使用して、コンテンツ管理サイトの作成、システム・ユーザーの管理、それらシステム・ユーザーのコンテンツに対する権限の制御、ワークフロー・プロセスの確立、およびWebCenter Sitesの機能(サイト・デスクトップなど)の構成ができます。

- Contributorインタフェースは特に、コンテンツ・プロバイダおよびビジネス・ユーザー向けに設計されています。Contributorインタフェースでは、アセットのプレビュー、作成、編集、削除、承認など、WebCenter Sitesのコンテンツ管理機能のほとんどが使いやすくなり、迅速にアクセスできます。

Contributorインタフェースでアセットを操作するときには、次のWYSIWYGエディタに対応したフィールドが表示される場合があります。

- CKEditorは、CKSource社製のオープン・ソースWYSIWYGテキスト・エディタで、クライアント側にインストールしておく必要はありません。開発者はCKEditorを使用して、テキスト入力フィールドでフィールドの入力メカニズムとしてCKEditorを使用するベーシック・アセットを作成できます。開発者はまた、入力手段としてCKEditorを使用するフレックス属性に対する属性エディタを作成することもできます。

- Clarkii Online Image Editor (Clarkii OIE)は、InDis Baltic社製の広く普及したサード・パーティ・イメージ・エディタです。開発者はClarkii OIEを有効にして、ユーザーがWebCenter SitesのContributorインタフェースのフォーム・モードでイメージを直接編集することができるようにします。これによって、外部のイメージ・エディタが不要になります。

- WEMのAdminインタフェースは特に、ロールを介してアプリケーションおよびユーザーのサイトへの割当てを管理者が管理できるように設計されています。

WEMのAdminインタフェースの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および第V部「Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発」を参照してください。

WebCenter Sitesでは、MS Wordなどのクライアント(オプションのインタフェース)も、Windows ExplorerやWindows Desktopと同様の機能を提供するアプリケーションもサポートされています。そのクライアントは次のとおりです。

- WebCenter Sitesデスクトップは、WebCenter Sitesのインタフェースの代替として、馴染みのあるMicrosoft Wordインタフェースをコンテンツ作成者に提供します。作成者は、そのコンテンツをWordドキュメントで直接作成できます。ただし、サイト・デスクトップでは、Wordドキュメントのコンテンツは構造化される必要があります。コンテンツがデータベース表に解析されるからです。
たとえば、サイト・デスクトップを使用してコンテンツを作成する際、ユーザーはWordドキュメントを開き、コンテンツを入力して、WebCenter Sitesが提供する同等なコンテンツ・エントリ・フォームで定義されるものと同じフィールド名でタグ付けすることによりコンテンツを構造化します。タグ付けユーティリティはWordインタフェースに組み込まれ、フィールドの選択はWebCenter Sites管理者によって決定されます。Wordドキュメントが保存されると、そのフィールド内のコンテンツは適切なデータベース表内のフィールドに解析されます。Wordドキュメントは、引き続き編集可能です。

注意:

サイト・デスクトップは、クライアント・コンピュータに手動でインストールする必要があります。

- サイトDocLinkは、フレックス・アセット・ファミリの構造化されていないコンテンツをサポートします。
サイトDocLinkは、フレックス・アセットとして管理される、構造化されていないタイプのコンテンツ(ドキュメント、グラフィックまたはその他の単一バイナリ・ファイル)をアップロードおよびダウンロードするドラッグ・アンド・ドロップ・インタフェースを提供します。また、サイトDocLinkは、WebCenter Sitesデータベース内のフレックス・アセット・ファミリの階層構造を、Windows Explorerアプリケーションのフォルダおよびファイルとして表します。

注意:

サイトDocLinkは、クライアント・コンピュータに手動でインストールする必要があります。

特定のユーザー向けのサイト・デスクトップおよびサイトDocLinkの構成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

1.9 サンプル・サイト

WebCenter Sitesには、この項で説明するサイトが用意されています。avisportsおよびFirstSiteIIコードを再利用し、組織のビジネス・ニーズに適合するように変更できます。開発者ガイドのこの項では、これらのサンプル・サイトの両方を使用して、コーディングのベスト・プラクティスを図示します。

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

- 第1.9.1項「avisportsサンプル・サイト」

- 第1.9.2項「FirstSiteIIサンプル・サイト」

- 第1.9.3項「WebCenter Sites Demo JSKでのみ使用可能」

1.9.1 avisportsサンプル・サイト

avisportsはスポーツを中心としサンプル・サイトで、イメージを添えたスポーツ記事が掲載されています。avisportsは、フォーム・モードおよびWebモードでのアセットの作成や編集など、WebCenter SitesのContributorインタフェースでの機能を示すために使用します。また、avisportsでは、アセットの「作成」ビューや「編集」ビューをWebモードでレンダリングするようにコーディングされたサンプル・テンプレートが、開発者に提供されます。

1.9.2 FirstSiteIIサンプル・サイト

FirstSiteIIは電子機器の小売サイトで、記事、イメージ、いくつかのエントリが記載された製品カタログ、ドキュメントおよびサンプル・ユーザー・アカウントが含まれます。FirstSiteIIは、WebCenter Sitesのサイト開発でベスト・プラクティスを利用したもので、開発者にとっては優れた開始点となります。

1.9.3 WebCenter Sites Demo JSKでのみ使用可能

次のサンプル・サイトは、WebCenter Sitesのダウンロード・ページにあるOracle Technology Networkに配置されているWebCenter Sites Demo JSKでのみ使用可能です。

Burlington Financialサンプル・サイト

WebCenter Sitesには、Burlington Financialという、機能をフル装備したサンプル・サイトが用意されています。開発者ガイドのこの項では、ベーシック・アセット・モデル、WebCenter Sitesの機能、およびコーディング作業を示す例のソースとしてこのサイトが使用されます。それらの例は、この本でも、実際のサイトのコンテキストにおけるオンラインでも調べることができます。

Burlington Financialサイトには、サンプルのアセット・タイプ、エレメント、SiteCatalogのエントリ、ワークフロー・プロセスなどが含まれています。Burlington Financialサンプル・サイトについては、第33章「Burlington Financialサンプル・サイト」を参照してください。

HelloAssetWorldサンプル・サイト

WebCenter Sitesには、Burlington Financialサンプル・サイトに加え、HelloAssetWorldというサンプル・サイトが用意されています。このサイトには、WebCenter SitesのWebサイトを作成するための簡略な手引きが記載されています。

HelloAssetWorldを構成するテンプレートは、第32章「HelloAssetWorldサンプル・サイト」に記述されています。サイトの構成およびユーザーの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』に記載されています。

2 コンテンツ管理サイトについて

Oracle WebCenter Sites環境では、コンテンツ管理サイトとは、WebCenter Sitesのインタフェースで、オンライン・サイトを設計し、アセットへのアクセスを管理するための補助として使用するオブジェクトです。Burlington Financialサンプル・サイトはコンテンツ管理サイトです。GE Lightingサンプル・サイトも同様です。

最初に、開発システム上にコンテンツ管理サイトを作成します。サイトがテストされ、使用の承認がなされたら、管理システムと配信システムにサイトを(まったく同じ名前で)複製する必要があります。

この章には次の項が含まれます。

- 第2.1項「コンテンツ管理サイト」

- 第2.2項「オンライン・サイト」

- 第2.3項「開発者とコンテンツ管理サイト」

- 第2.4項「サイトとサイト・プラン」

- 第2.5項「サイトとデータベース」

2.1 コンテンツ管理サイト

コンテンツ管理(CM)サイトとは、WebCenter Sites配信システムから配信するオンライン・サイト向けの設計補助または組織構成メンバーとして使用するオブジェクトです。コンテンツ管理サイトは、オンライン・サイトを表しています。

注意:

このガイドでは、コンテンツ管理サイトをCMサイトまたは単にサイトと呼ぶこともあります。

WebCenter Sitesのモジュールおよび製品のいずれかを実行しているWebCenter Sitesにログインするときには、コンテンツ管理サイトにログインしています。複数のサイトにアクセスする権限がある場合、ログイン後に最初に行うべき意思決定は、どのサイトで作業するかです。その時点以後、完了するタスクのすべては、そのサイトのコンテキストで完了されます(サイトを切り替えるまで)。

コンテンツ管理サイトは、次に示すように、3種類のユーザーがそれぞれのやり方で使用します。

- 開発者は、コンテンツ管理サイトを使用して、次のようにオンライン・サイトを設計します。

- データ・モデルを作成します(データ・モデルとは、オンライン・サイトにコンテンツを提供するためにビジネス・ユーザーが使用するコンテンツ・エントリ・フォームまたは編集フォームのソース)

- 選択したコンテンツ管理サイトでデータ・モデルを有効にします

- データベースからコンテンツを抽出し、コンテンツを書式設定して、コンテンツをオンライン・サイトに配信するコード・テンプレート。「サイト・プラン」タブを使用して、オンライン・サイトの設計フレームワークを作成します。それぞれのコンテンツ管理サイトには別々のサイト・プランがあり、そのサイト・プランはSitePlanTree表に格納されています。

- コンテンツ管理サイトでテンプレートを有効にします

- ページのキャッシングを実装します

- セッション・データを利用します

- サイト訪問者に関する情報を収集するコードを記述します

- セキュリティを確立します

注意:

データ(たとえば、アセット・タイプやテンプレート)を作成すると、ログイン先として選択したコンテンツ管理サイトに関係なく、そのデータはシステム全体のプールに入力されます。

ログインしているサイト(およびそれ以外のあらゆるサイト)でデータを有効にすると、そのデータはそのサイトにリンクされ、そのサイトのユーザーがアクセスできるようになります。

- WebCenter Sites管理者は、コンテンツ管理サイトを使用して、コンテンツに対するユーザーのアクセスを次のように制御します。

- WebCenter Sites管理者は、WebCenter Sitesシステム上で、特定のアセットおよびアセット・タイプへのユーザーのアクセスを制限できます。
アセット・タイプは、コンテンツ管理サイトで有効にする必要があります。そのため、管理者が、あるコンテンツ管理サイトでアセット・タイプを有効にしないことにした場合、そのコンテンツ管理サイトにログインするユーザーには、そのタイプのアセットに対するアクセス権限が付与されません。WebCenter Sites管理者は、コンテンツ管理サイトへのユーザーのアクセスを制限することもできます。

- WebCenter Sites管理者は、コンテンツ管理サイト間で個々のアセットを共有できます(共有サイトで特定のアセット・タイプが有効になっていて、同じユーザーが共通している場合に限る)。
WebCenter Sites管理者は、特定のアセットを共有しないことによって、そのアセットへのアクセスを制限することもできます。特定のアセット・タイプが複数のサイトにわたって有効になっていても、あるサイトで作成されたアセットは、別のサイトでは使用できません。ただし、アセットがそのサイトで共有されている場合は除きます。

- コンテンツ管理サイトが開発されたら、認可されたコンテンツ・プロバイダはそのサイトを使用することによって、電子機器アセットを作成し、そのアセットを管理して、アセットを利用者にデプロイします。コンテンツ・プロバイダは、コンテンツ・エントリ・フォームやその他オーサリング・ツールにリンクされ、特定の編集権限も与えられ、オンライン・サイトの一部としてコンテンツをブラウザに表示するためのパブリッシュ・システムおよび配信システムへのアクセス権限が与えられます。

コンテンツ管理サイトは、実際のオンライン・サイトを表しています。ただし、それらのオンライン・サイトは、状況に応じてどれだけの数の方法でも表せます。例:

- 1つのコンテンツ管理サイトは、1つの完全なオンライン(パブリック)サイトを表す場合もあります。

- 複数のコンテンツ管理サイトは、1つの大きなオンライン・サイトの別々のセクションを表す場合もあります。たとえば、カタログの場合、家庭用品のデータを入力する人が、園芸用品のデータを入力することはおそらくありません。したがって、それらの分野を表す別々のサイトがあります。また、パブリケーションを例にすると、スポーツ・ライターはスポーツ・ニュース・セクションを表示する別のサイトを持ち、ファイナンシャル・ライターは金融関係のニュース・セクションを表示する別のサイトを持ちます。

- 複数のコンテンツ管理サイトが同じオンライン・サイトを表すこともありますが、その場合は、アセット・タイプに対するユーザーのアクセスをロール別に制限するために存在します。たとえば、サイト1では、記事とイメージのアセット・タイプが有効になっていて、このサイトにアクセスできるのはコンテンツ・プロバイダのみとします。また、サイト2では、テンプレートを含めてすべてのアセット・タイプが有効になっていて、このサイトにアクセスできるのは少数の開発者のみとします。

2.2 オンライン・サイト

オンライン・サイトは、組織が顧客、クライアントおよび一時的な訪問者といったターゲットとなる読者に表示するページのセットです。オンライン・サイトは、Webサイトの場合もポータルの場合もあります。これは、だれでもアクセスできるようにすることも、パスワードで保護されたサイトにすることもできます。プライベート・ドメイン内で厳密に運用し、企業イントラネットや部門内ネットワークなどのように完全に排他的なサイトにすることもできます。

その性質に関係なく、オンライン・サイトは、選択するモデルに応じて、単一のCMサイトまたは多数のCMサイトに由来します。すべての製品ガイドにおいて、オンライン・サイトという用語は汎用的に、Webサイトとポータル(どちらも今回のリリースでサポート)を指すために使用されています。

2.3 開発者とコンテンツ管理サイト

WebCenter Sitesのモジュールおよび製品を使用するときにはコンテンツ管理サイトにログインする必要があるため、アセット開発はすべて、コンテンツ管理サイトのコンテキストで行われます。アセット・タイプの開発、オンサイト・サイト・ページの設計およびテンプレート・アセットのコーディングを行うときには、次の点を検討してください。

- テンプレート・アセットを作成すると、WebCenter Sitesでは、SiteCatalog表とElementCatalog表の両方で、そのアセットに対するエントリが作成されます。SiteCatalog表でページ・エントリに割り当てられる名前には、テンプレート・アセット作成時にログインしていたサイトの名前が含まれます。

- 複数のコンテンツ管理サイトで1つのテンプレート・アセットを共有する場合、WebCenter Sitesでは、共有する各サイトのSiteCatalogにページ・エントリが作成されます。共有テンプレートに追加されるページ・エントリの名前には、テンプレートが共有されたサイトの名前が含まれます。

したがって、オンライン・サイトが正しく機能するためには、管理システムおよび配信システムで使用するのと同じコンテンツ管理サイト名を開発システムで使用する必要があります。

コンテンツ管理サイトは、設計上の問題とアクセス上の問題の両方をカバーするので、コンテンツ管理サイトの使用方法や、システムにサイトがいくつ必要かを判断する際には、システム管理者と協力する必要があります。

設計とアクセス制御両方の理由で、管理システムにコンテンツ管理サイトがいくつ必要かを判断した後で、開発者またはシステム管理者は、適切なコンテンツ管理サイトを作成し、すべてのシステム上のこれらのサイトに対して、適切なアセット・タイプを有効にすることができます。次に、開発システムと管理システムで、開発者またはシステム管理者は、コンテンツ・プロバイダなどのユーザー(開発者など)のいずれが、どのサイトにアクセスできるかを構成します。

コンテンツ管理サイトを構成するには、「管理」タブで「サイト」オプションを使用します。

2.4 サイトとサイト・プラン

ページ・アセットは、他のアセットに対する参照を格納し、開発者が実装しているデザインに従ってアセットを整理するサイト・デザイン・アセットです。オンライン・サイトの設計フェーズで、ページ・アセットを作成し、そのアセットに他のアセットを関連付けて、WebCenter Sitesウィンドウの左側のツリーにある「サイト・プラン」タブ上のツリー内にページ・アセットを配置します。

「サイト・プラン」タブ上のツリー内にページ・アセットが配置されたら、そのツリー内の各ページ・アセットの位置に関する情報が、SitePlanTree表に書き込まれます。このタブに配置されているページ・アセットが、パブリッシュされたページに対して作成するようにテンプレートとエレメントでコーディングされているものと同じ階層を表している場合は、WebCenter SitesのSITEPLANタグ・ファミリを使用してナビゲーショナル機能を構築できます。詳細は、第29.6項「例6: サイト・プラン情報の表示」を参照してください。

「サイト・プラン」タブには、現在ログインしているコンテンツ管理サイトであるオンライン・サイトのレイアウトが、ツリーとしてグラフィカルに表されます。まず、SitePlanTree表に問い合せて、どのページ・アセットが配置されているかを判別します。次に、ページ・アセットがツリー上の適切なレベルに表示され、それらのページ・アセットに関連付けられているアセットが後続の階層レベルに表示されます。

2.4.1 Burlington Financialサンプル・サイト

「サイト・プラン」タブ上のツリーには、レンダリングされたサイト・ページでなくアセットが表示されます。つまり、実際のオンライン・サイトで配信される可能性のあるオンライン・ページを、すべて表しているわけではありません。たとえば、次に示すのは、「サイト・プラン」ツリーのうち、Burlington Financialサンプル・サイトの「Home」ページ・アセットを示すセクションです。

オンライン・サイトと「サイト・プラン」タブの関係をさらに理解するために、次のようにして、レンダリングされたBurlington Financialの「News」ページ・アセットをブラウザに表示します。

1. Burlington Financialサンプル・サイトにログインします。

2. 「サイト・プラン」タブを選択します。

3. ツリーから「News」ページ・アセットを選択し、マウスの右ボタンをクリックして「プレビュー」を選択します。

ブラウザでレンダリングされている「News」Webページと「サイト・プラン」タブのこのセクションを比較します。このとき、次の点に注意してください。

- 「News」ページ・アセットは、訪問者がオンラインのBurlington Financialのホーム・ページから「News」リンクを選択した場合に、レンダリングされる実際のページを表しています。これは、「News」ページに割り当てられているテンプレートが、ページ・アセットをWebページとして表示するようにコーディングされているからです。

- ツリーの「News」ページ・アセットに表示されているコレクション・アセットは、実際にレンダリングされたページを表していません。「News」ページのテンプレートは、オンラインの「News」ページでのリンクとして「News」ページに関連付けられている、コレクションに格納されている記事の見出しを表示するようにコーディングされています。

- NewsTopコレクションに格納されている記事アセットは、実際のオンライン・ページを表しています。これは、記事へのリンクをクリックしたときに記事を表示するテンプレートが、別のWebページに記事を表示するようにコーディングされているからです。

オンライン・サイトにアセットがどのように表示されるかを決定するのはテンプレート内のコードであるため、「サイト・プラン」ツリーでページ・アセットとして表されないオンライン・ページが数多くある可能性があります。

ページ・アセットに対して正しいアセットを選択するには、アセットに対して選択するようにコーディングされているテンプレート・エレメントが何であるかを認識しておく必要があります。そのために、ページ・アセットの作成と配置が開発者の担当になっており、それはテンプレート・エレメントをコーディングする際に完了するタスクです。

ページ・アセットは、ゲートウェイ・ページまたは索引ページの役割を果たしており、このページは、実際のオンライン・ページを表すのみでなく、コンテンツを表す他のアセットにアクセスできます。

2.5 サイトとデータベース

サイトを作成すると、WebCenter Sitesでは、それに関する情報が次のデータベース表に書き込まれます。

- Publication表: システムに作成されたすべてのサイト(パブリケーション)の名前、説明およびpubid (ID)を保持します。

- PublicationTree表: どのサイトでどのアセット・タイプが有効になっているかに関する情報を格納します。

- SitePlanTree表: サイトおよびそのページ・アセットの階層構造に関する情報を格納します。システムに作成されたサイトごとに、トップレベルのノードがあります。この表には、サイトとページ・アセットが一覧表示されています。
開発者は、(たとえば、オンライン・サイトの主なセクションへのリンクを作成するために)SitePlanTree表から情報を抽出および表示するようにエレメントをコーディングできます。

注意:

以前のバージョンのWebCenter Sitesでは、サイトという用語よりパブリケーションという用語を使用していました。また、WebCenter Sitesデータベースにおけるデータベース表のいくつかでは、今でもサイトをパブリケーションと呼称しています。

3 Oracle WebCenter Sitesの開発プロセス

WebCenter Sitesのコンテンツ管理システムから配信されることになるオンライン・サイトを開発すると、実際には次の2つのサイトを設計することになります。

- 配信システムから訪問者のブラウザに配信されるオンライン・サイト

- コンテンツ・プロバイダが配信システムにパブリッシュするデータを入力する際に使用するコンテンツ管理サイト

言い換えると、次の2種類のエンド・ユーザーのユーザー作業環境を担当します。

- 配信システムを使用するサイト訪問者

- 管理システムを使用するコンテンツ・プロバイダ

これら2つの、緊密につながってはいるが別々のサイトを作成する際には、開発チームは、計画立案、開発、テストという一連の手順を実行します。この章では、1つの考えられるイベントの流れで、そして一般的な用語で、開発プロセスについて説明します。実際のワークフローは、作業環境とビジネス・ニーズに応じて異なります。

この章には次の項が含まれます。

- 第3.1項「手順1: チームを発足する」

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

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

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

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

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

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

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

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

最初の手順は開発チームを結成することであり、チームは次のような人たちで構成します。

- サイト・デザイナ

- XMLおよびJSP開発者

- Javaアプリケーション開発者

- データベース管理者

- システム・ネットワーク管理者

- マーケティング担当者および広告担当者

- 製品マネージャ(商用サイトを開発している場合)

- コンテンツ・プロバイダ

開発チームには、データベース管理者、システム管理者、コンテンツ・プロバイダなどの人たちが必要であり、(開発者のように)次のような様々な理由で実際のコーディングを行う人たちも必要です。

- WebCenter Sitesのシステムを使用するには、ページ・デザインを作成することに加えて、データ・モデルを設計することが必要です。つまり、各システム上のデータベースをサポートするデータベース管理者から、早めに情報を入手する必要があります。

- WebCenter Sitesのシステムを使用するというのは、複数の別々のシステム(そのうちのいくつかはクラスタ化されている可能性が高い)で、コードとデータをあちこち動かすということです。つまり、システム管理者およびネットワーク管理者から、早めに情報を入手する必要があります。

- コンテンツ・プロバイダの作業環境が管理システムの設計に実際に反映されている場合を除き、WebCenter Sitesのシステムを実装することは最適ではありません。つまり、管理システムを使用する人たちから、早めに情報を入手する必要があります。

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

Oracle WebCenter Sitesのコンテンツ管理システムから配信されるオンライン・サイトは、すべてを包括した構成体で、その中ではすべてのものが他のすべてのものと対話、交差および作業します。したがって、2番目の手順は、機能仕様とデザイン仕様を作成すること、すなわちオンライン・サイトを紙上で設計することです。

何かのコーディングを始める前に、この手順のなんらかのバージョンを完了する必要があります(デザイン仕様を作業する際に、なんらかの概念検証コーディングを行う場合もあり)。

3.2.1 機能要件

デザインの指定を開始する前に、製品管理とマーケティングでは、オンライン・サイトに機能要件を提供する必要があります。

3.2.2 ページ・デザイン

マーケティング担当者からの機能要件の入手後、最初に行う作業としては、オンライン・サイトに提示するすべてのタイプのページを策定することをお薦めします。たとえば、ホーム・ページ、セクション・ページ、コラムニスト・ページ、検索ページ、記事ページです。商用ページを設計する場合は、登録ページ、製品カテゴリ・ページ、製品の説明ページ、記事ページ、FAQページ、請求書ページなど、他の種類のページが必要です。

各ページおよびサイト全体のグラフィック、ナビゲーション、機能の各面での特徴を決定します。具体的には、ナビゲーション・バー、購入ボタンとショッピング・カート、詳細ボタン、検索機能、ロゴの配置、アニメーション化されたグラフィックなどです。

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サーバーで提供します。

どちらの方法も有効なオプションです。イメージ・ファイルをWebサーバーに保持する場合、WebCenter Sitesタグを使用して、それらのファイルへのリンクを作成できます。また、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 アセット・タイプをサポートする補助表

システムに実装するデータ・デザインは、アセットを保持しているデータベース表を越えています。提供する情報の種類によっては、アセット・タイプをサポートする補助表を作成することが必要になる場合もあります。

たとえば、Burlington Financialサンプル・サイトには、「Mimetype」フィールドの付いたアセット・タイプがあります。「Mimetype」フィールドはドロップダウン・フィールドで、ユーザーはドロップダウン・リストから値を選択する必要があります。これらの値は、MimeTypeという名前の参照表から引き出されます。ニーズによっては、使用システムで同様の表を作成することが必要になる場合もあります。

作成する予定のあるアセット・タイプおよび補助表についての議論にはデータベース管理者にも参加してもらい、管理システムと配信システムで発生する可能性のある種類のデータベース・チューニング問題を理解してもらってください。

3.2.6.3 訪問者データ

Engageを使用している場合は、訪問者のどのようなデータを収集する予定があるのかを判別する必要もあります。これらのデータ型は、Engageの訪問者データ・アセットで表され、訪問者のIDに基づいてサイトをパーソナライズする際にセグメントを作成するために使用します。(たとえば、人口統計、購入履歴、クリックストリームなどの情報。)

WebCenter Sitesシステムが本番稼働し、訪問者のデータ収集を開始したら、そのデータを格納する表はすぐに大きくなります。これも、データベース管理者と相談しておく必要のある分野です。

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

コーディングを開始する前に、管理システムをどのように編成するかを知っておく必要があります。デザインはコンテンツ管理サイトに応じて異なるため、これらの意思決定がデザインに影響を与えます。

コンテンツ管理サイトとは、実際のオンライン・サイト向けの組織構成メンバーとして、またアクセス制御ツールとして使用するオブジェクトです。テンプレート・アセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するエントリが作成されます。テンプレートのページ・エントリにWebCenter Sitesで使用されるネーミング規則には、テンプレートの作成対象となるコンテンツ管理サイトの名前が含まれます。つまり、コンテンツ管理システム全体(開発システム、管理システムおよび配信システム)で整合性を維持する必要があり、コーディングを開始する前に、使用しているサイトの名前を知っておく必要があります。

第1の関心事は各サイトの名前ですが、システム管理者とビジネス・マネージャは次の点も決定する必要があります。

- 必要なユーザーおよびACL(アクセス制御リスト)の数(オンライン・サイトの訪問者に割り当てるACLを作成する必要がある場合もあることに注意)

- 必要なサイト・ロール数

- どのアセット・タイプがワークフロー・プロセスを必要とするか

- リビジョン追跡を使用する必要があるアセット・タイプ

- どのユーザーがどのサイトのどのアセット・タイプへのアクセス権を持つ必要があるか

これらの決定には、このドキュメントと『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の両方を使用してください。

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

デザイン仕様を作成し、管理システムの構成を理解したら、データ・デザインを実装できます。

開発システムで、次の種類のタスクを完了します。

- 管理システムで使用される名前と同じ名前でコンテンツ管理サイトを作成します。

- アセット・タイプを設計して作成します。

- アセット・タイプに対して参照表などの補助表を追加します。

- 各タイプのサンプル・アセットを作成します。

この手順と次の手順(第3.5項「手順5: オンライン・サイトを構築する」)は反復作業であり、多くの部分が重複する可能性が高いと考えられます。アセット・タイプを作成して、テンプレート作成前にアセットを作成できるようにする必要がある一方、データ・デザインに改良が必要な領域が明らかになるのは、テンプレートのコーディングとコードのテストを行った後のみになる可能性が高いと思われます。

オンライン・サイトのデータ・デザインを実装する際には、第11章「データ・デザイン: アセット・モデル」を参照してください。

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

たった1つのタイプでもサンプル・アセットを開発システム上に作成したら、テンプレートのコーディングおよびオンライン・サイトの構築を開始できます。(実際は、デザイン仕様を作成した後であれば、アセットを表示しないエレメントのコーディングをいつでも開始できます。)

この手順では、次の種類のタスクを完了します。

- オンライン・サイトの機能を実装した、ページ、問合せ、コレクションの各アセットを作成します。

- Engageを使用している場合は、訪問者データ・アセット、サンプル・セグメント、推奨事項およびサンプル・プロモーションを作成します。

- アセット・タイプのすべてに対し、テンプレート・アセットを登録(してテンプレート・エレメントをコーディング)します。

- コンテンツ・コントリビュータがContributorインタフェースのWebモード機能を使用している場合は、insiteファミリのタグを使用してテンプレートをコーディングします。

- 基礎となる機能を実装する(アセットを表示しない) CSElementをコーディングします。

- 商用サイトを開発している場合は、ショッピング・カートを実装するページをコーディングします。

- Engageを使用している場合は、訪問者データを収集するページをコーディングします。

- すべてのテスト: ほとんどの場合、オンライン・サイトに対して操作性と市場性に関する両方のテストを実行します。

オンライン・サイトを構築する際には、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

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

オンライン・サイトが開発システムで稼働するようになったら、オンライン・サイトを管理システムに移動します。

開発者は、次の種類のタスクを完了します。

- サイトを作成します。

- アセット・タイプを再作成します。

- アセット・タイプ表および補助表を開発システムから管理システムにミラーリングします。

- 開発システムに作成されたサイト・デザイン・アセットおよびデータ構造アセットを、管理システムにミラー・パブリッシュします。

次にシステム管理者は、次の種類のタスクを完了します。

- ユーザー、ACLおよびロールを作成します。コンテンツ管理サイトごとに、ユーザーにロールを割り当てます。

- サイト・デスクトップ機能を使用している場合は、そのユーザーを構成します。

- ワークフロー・プロセスを作成します。

- StartMenuショートカットを作成します。

- リビジョン追跡を有効にします。

管理システムの設定については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

コンテンツは、使用するなんらかの非アセット・フォーマットになっていると考えられます。このコンテンツをWebCenter Sitesデータベースにアセットとしてインポートするには、XMLPostユーティリティを使用します。

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

フレックス・アセット・モデルを使用していて、これから使用するデータが前もって大量に存在している場合は、BulkLoaderユーティリティを使用してインポートできます。ただし、システム化された更新の場合は、XMLPostユーティリティを使用します。

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

編集チームがオンライン・サイトを正常に維持できるようにするには、デザインを理解しておく必要があります。たとえば、コレクションをどのくらいの頻度で再構築するかなどがあります。

ベーシック・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

- 該当する問合せおよびコレクション別にアセットが検索されるようにするには、アセットにどのカテゴリおよびソースを割り当てるべきか。

- どのテンプレートをどのアセットに割り当てるべきか。

- サイト・ページ上のリンクが正常に機能するようにするには、どのアソシエーション・フィールドにデータを入力する必要があるか。

アセット・タイプごとに開発者とシステム管理者が作成する「スタート・メニュー」ショートカットに、できるだけ多くの情報をプログラムすることをお薦めします。

フレックス・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

- フレックス・アセットに定めた一般的な階層または分類。

- フレックス・アセットが何の情報を継承するかについての情報。

- どのテンプレートをどのアセットに割り当てるべきか。

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

配信システムを設定するときには、管理システムに対して完了したのと同じ手順をいくつか完了します。例:

- サイトを再作成します。

- アセット・タイプを再作成します(ただし、「スタート・メニュー」ショートカットはなし)。

- アセット・タイプ表および補助表を開発システムから管理システムにミラーリングします。

次に、管理システム上のアセットのすべてを配信システムにパブリッシュします。

また、このシステムは管理システムでないため、次の手順も完了します。

- セキュリティ戦略を実装します。

- Webサーバーで、自分のサイトのURL (www.example.com)を、ホーム・ページのWebCenter Sites URLにマップします。

配信システムの設定については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』のパブリッシュに関する項を参照してください。

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

管理システム上のコンテンツが準備できたら、配信システムにパブリッシュします。パフォーマンスと負荷の両面で集中的なテストを実施した後で、サイトを世間に公開します。

4 Oracle WebCenter Sitesを使用したプログラミング

Oracle WebCenter Sitesは、コンテンツを管理するのみでなく、多くの有用なタスクを管理者のかわりに処理します。これらのタスクとしては、WebページやWebページの断片(ページレット)をWebCenter Sitesのキャッシュに格納することや、Webサイトの訪問者に古いページが表示されないようにこれらのキャッシュを管理することがあげられます。WebCenter Sitesがこれらの処理を実行できるためには、WebCenter SitesのタグとJavaメソッドを使用してコーディングする必要があります。

WebCenter Sitesページは、様々なエレメント・アセットとテンプレート・アセットで構成されています。エレメント・アセットとは、WebCenter Sitesデータベースからのパッケージのコンテンツを取得したり、古くなったアイテムをデータベースから削除するなどのタスクを実行するコードのブロックです。テンプレート・アセットは一般に、Webページのコンテンツを書式設定するために使用されます。エレメントとテンプレートは、HTML、XML、JSP、CSS、JavaScriptなどのいくつかのスクリプト言語とマークアップ言語で記述できます。ただし、WebCenter Sitesが解釈できるのはXMLとJSPのみです。

この章では、WebCenter Sitesを使用したプログラミングの概要を示します。次の項で構成されます。

- 第4.1項「コーディング言語の選択」

- 第4.2項「Oracle WebCenter Sitesのコンテキスト」

- 第4.3項「WebCenter SitesのJSP」

- 第4.4項「WebCenter SitesのXML」

- 第4.5項「WebCenter Sitesのタグ」

- 第4.6項「変数」

- 第4.7項「WebCenter Sitesの他の記憶域構成体」

- 第4.8項「特殊文字の値」

注意:

WebCenter Sites 11gリリース1 (11.1.1.8.0)では、SOAPベースのWebサービスの機能が非推奨になりました。この機能は、RESTサービスに置き換えられました。

4.1 コーディング言語の選択

作成するエレメントまたはテンプレートの役割に基づいて、コーディング言語やマークアップ言語を選択してください。たとえば、ページ・レイアウトにはHTMLとXMLを使用し、ロジックにはJSPとJavaを使用するのが一般的です。新聞記事などの動的なコンテンツを表示するエレメントは、通常はXMLまたはJSPで記述してください。その理由は、このようなエレメントはロジックを使用してコンテンツをWebCenter Sitesデータベースから取得するため、WebCenter SitesのXMLタグまたはJSPタグを使用して管理されるからです。

WebCenter SitesではJava APIも用意されており、コーディング言語としてJSPを選択した場合は、このAPIをWebCenter SitesのJSPタグと組み合せて使用します。

次の表では、各言語の最適な使用ケースを示しています。

表4-1 コーディング言語の使用

コード

使用するケース

XML

エレメントの大部分がテキストで構成されており、ループや条件分岐がほとんど含まれていません。

JSP

- エレメントで条件演算子が必要であるか、=や!=以外の関係演算子が必要です。

- エレメントで多くのループが使用されています。ループのパフォーマンスは、XMLよりもJSPの方が優れています。

- エレメントにJavaコードのコールが含まれています。

XMLまたはJSPで記述されたエレメントは任意のタイプのエレメントをコールできますが、XMLとJSPを同じエレメント内に混在させることはできません。たとえば、XMLまたはJSPで記述されたエレメントは、HTML、XMLまたはJSPで記述された別のエレメントをコールできます。ただし、HTMLで記述されたエレメントは、XMLまたはJSPで記述されたエレメントをコールすることはできません。

4.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ページを作成できます。

4.2.1 ICSオブジェクト

Oracle WebCenter Sitesのためにコーディングしている場合は、Interface to WebCenter Sites (ICS)オブジェクトのメソッドとタグに頻繁にアクセスします。ICSオブジェクトは、WebCenter Sitesの中核機能のいくつかをカプセル化して、WebCenter Sitesツリーを制御するサーブレット(TreeManagerサーブレット)と、データベースへのデータ入力を制御するサーブレット(CatalogManagerサーブレット)へのアクセスを可能にします。

ICSのメソッドとタグを使用して、変数を作成および表示したり、if/then文を使用して、指定された条件に基づいてタスクを実行することもできます。ICSオブジェクトのメソッドとタグの詳細なリストについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

4.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タグをコードの最終行として使用する必要があります。

4.3 WebCenter SitesのJSP

JSPプログラマは、ディレクティブ、アクション、JSPオブジェクトなどの一連の標準ツールを自由に使用できます。WebCenter Sites内でJSPを使用してプログラミングする場合は、これらの機能の多くにアクセスできます。ただし、場合によっては、JSPのディレクティブやアクションのかわりにWebCenter Sitesのタグを使用することや、JSPの暗黙オブジェクトのいずれかのかわりにWebCenter Sitesのオブジェクトにアクセスすることが必要になります。

次の各項では、標準のJSPとWebCenter SitesのJSPの違いを詳述しているとともに、標準のJSP機能とWebCenter Sitesのタグやメソッドとの対応関係を示しています。

- 第4.3.1項「WebCenter Sitesの標準先頭部」

- 第4.3.2項「JSPの暗黙オブジェクト」

- 第4.3.3項「構文」

- 第4.3.4項「アクション」

- 第4.3.5項「宣言」

- 第4.3.6項「スクリプトレットと式」

- 第4.3.7項「JSPのディレクティブ」

- 第4.3.8項「Oracle WebCenter Sitesのタグ・ライブラリ」

4.3.1 WebCenter Sitesの標準先頭部

WebCenter Sitesユーザー・インタフェースまたはOracle WebCenter Sites Explorerを使用して、テンプレート・アセット、CSElementアセットまたは非アセット・エレメントを作成する場合は、WebCenter Sitesによってそのエレメントまたはテンプレートに標準先頭部が自動的に追加されます。

Oracle WebCenter Sites 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アセットとこれらのアセットによってレンダリングされるコンテンツの間の依存関係をログに記録するタグを組み込みます。

Oracle WebCenter Sites ExplorerやWebCenter Sitesユーザー・インタフェース以外のツールを使用してエレメントとテンプレートを作成する場合は、この標準先頭部をコード内にまるごとコピーする必要があります。

次の各項では、Oracle WebCenter Sites Explorerの標準先頭部について説明します。

4.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タグをインポートします。

これらのタグ・ライブラリの詳細は、第4.3.8項「Oracle WebCenter Sitesのタグ・ライブラリ」を参照してください。

これらのタグ・ライブラリに含まれている一般的なタグについては、第4.5項「WebCenter Sitesのタグ」を参照してください。

これらのデフォルト内容にtaglibディレクティブを追加するには、OpenMarket/Xcelerate/AssetType/Template/ModelJsp.xmlファイルを変更して保存します。

4.3.1.2 ページ・ディレクティブ

次の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ファイルを変更して保存します。

4.3.1.3 cs:ftcsタグ

WebCenter SitesのそれぞれのJSPテンプレートやJSPエレメントでは、最初と最後のタグとしてcs:ftcsタグが使用されている必要があります。このタグは、WebCenter Sitesのコンテキストを作成して、開始と終了のcs:ftcsタグの内側に含まれているコードにWebCenter Sitesのタグが格納されることを、WebCenter Sitesに通知します。

コーディングは、開始と終了のcs:ftcsタグの内側で行う必要があり、これらのタグの外側にコードがあってもWebCenter Sitesでは認識されません。

4.3.2 JSPの暗黙オブジェクト

JSPでは、開発者が使用できる暗黙オブジェクトがいくつか用意されています。ただし、WebCenter Sitesのコンテキスト内では、WebCenter Sitesのオブジェクトを扱うことが多いため、JSPの暗黙オブジェクトを使用するかわりにWebCenter SitesのJSPタグとJavaメソッドを使用して、これらのWebCenter Sitesのオブジェクトにアクセスする必要があります。

次の表では、JSPの暗黙オブジェクトおよびこれらのオブジェクトの主要なメソッドと、これらの代替として使用する必要があるWebCenter Sitesのタグやメソッドの対応関係を示しています。

表4-2 JSPの暗黙オブジェクトのマッピング

オブジェクト

メソッド

WebCenter Sitesのタグやメソッド

request

getParameter

ics:getvarタグ

request

getParameterNames

ICS.GetVars()メソッド

request

getCookie

ics:getCookieタグ

response

addCookie

satellite:cookieタグ

セッション

getAttribute

ics:getssvarタグ

セッション

setAttribute

ics:setssvarタグ

out

println

ics:getvarタグまたはrender:streamタグ

4.3.3 構文

Oracle WebCenter Sitesでは、標準のJSP構文が使用されます。タグをネストする際は(JSPタグのパラメータの値としてJSP式を使用する場合など)、次の例のように必ず一重引用符で式を囲んでください。

name='<%=ics.GetVar("myVariable")%>'

4.3.4 アクション

標準のJSPでは、開発者はいくつかの種類のアクションを使用できます。次の表では、WebCenter Sitesのタグに置き換える必要のあるアクションと、通常どおり使用できるアクションを示しています。

表4-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>

これは、カスタムJavaBean内のプロパティを設定する場合に使用します。WebCenter Sitesのプロパティを設定するには、WebCenter Sitesのプロパティ・エディタを使用します。

<jsp:useBean>

これは、カスタムJava Beanに使用します。

4.3.5 宣言

標準のJSPでは、通常はJSP宣言内で変数を宣言します。WebCenter Sitesでは、ics:setvarタグを使用して、WebCenter Sitesのコンテキスト内で使用できる変数を宣言します。

WebCenter Sitesの変数の詳細は、第4.6項「変数」を参照してください。

4.3.6 スクリプトレットと式

スクリプトレットと式は、通常のJSP用法とまったく同じように使用できます。

ただし、WebCenter SitesのJSPタグのパラメータの値として式を使用する場合は、第4.3.3項「構文」で説明しているように、必ず引用符を正しくネストしてください。

4.3.7 JSPのディレクティブ

Oracle WebCenter Sitesのコンテキスト内でJSPをコーディングする場合は、次の表で概略を説明しているように、ディレクティブの使用についていくつかの注意点があります。

表4-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ディレクティブをエレメントやテンプレート・アセットに、必要に応じて追加できます。この表の後に、WebCenter Sitesのタグ・ライブラリを一覧表示しています。

4.3.8 Oracle WebCenter Sitesのタグ・ライブラリ

WebCenter Sitesでは、WebCenter SitesのAPIの機能に対応する一連のJSPタグ・ライブラリが用意されています。

次の表に、WebCenter Sitesのタグ・ライブラリを一覧表示して、これらの機能を説明します。この表は、ご使用のJSPにどのタグ・ライブラリをインポートするかを決定する際のリファレンスとして使用してください。

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

表4-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サービスのタグ。

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

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

タグ・ライブラリ

説明

asset.tld

ベーシック・アセットを取得および操作するタグ。

siteplan.tld

サイト計画ツリーへのアクセスを可能にするタグ。これらのタグは、ベーシック・アセットが使用されるサイトへのナビゲーションを作成するために使用します。

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

表4-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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

4.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を使用してコーディングする際の注意事項を説明しています。

4.4.1 WebCenter Sitesの標準先頭部

WebCenter Sitesユーザー・インタフェースまたはOracle WebCenter Sites Explorerツールを使用してテンプレートやエレメントを作成した場合は、WebCenter Sitesによってそのエレメントに次の標準先頭部が自動的に追加されます。

<?xml version="1.0" ?>
<!DOCTYPE ftcs SYSTEM "futuretense_cs.dtd">
<ftcs version="1.2">
</ftcs>

他のツールを使用してエレメントやテンプレートを作成する場合は、それらにこのコードをまるごとコピーする必要があります。

次の各項では、この標準先頭部について説明しています。

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

WebCenter SitesのいずれのXMLテンプレートやXMLエレメントでも、先頭行では次のようにXMLバージョンを設定する必要があります。

<?xml version="1.0"?>

エレメントが実行されるためには、そのエレメントの先頭行は<?xml version="1.0"?>である必要があり、このテキストの前に空白があってはいけません。さらに、この行の末尾に強制改行を入力して、この行を独立した行にする必要もあります。

このテンプレートまたはエレメントのエンコーディングを設定する必要がある場合は、次のようにして設定できます。

<?xml version="1.0" encoding="utf-8"?>

4.4.1.2 DTDファイル

WebCenter SitesのXMLは、futuretense_cs.dtdファイルによって定義されます。XMLバージョン行の直後に次の行を入力することで、コーディング対象のWebCenter Sitesのエレメントまたはテンプレートのそれぞれにこのファイルをインポートする必要があります。

<!DOCTYPE ftcs SYSTEM "futuretense_cs.dtd">

4.4.1.3 FTCSタグ

WebCenter SitesのそれぞれのXMLテンプレートやXMLエレメントでは、最初と最後のタグとしてftcsタグが使用されている必要があります。このタグは、WebCenter Sitesのコンテキストを作成して、開始と終了のFTCSタグの内側に含まれているコードにWebCenter Sitesのタグが格納されることを、WebCenter Sitesに通知します。

コーディングは、開始と終了のftcsタグの内側で行う必要があり、これらのタグの外側にコードがあってもWebCenter Sitesでは認識されません。

4.4.2 XMLのエンティティと予約文字

<や>などの記号はXMLの予約文字であるため、このような記号をコンテンツに入力しないでください。たとえば、次のコードでは、テキスト内で小なり記号(<)が使用されているため、XMLパーサーが混乱します。

<P>4 < 7</P>

予約文字のかわりに文字エンティティを使用する必要があります。文字エンティティは&#で始まり、セミコロンで終わります。&#とセミコロンの間には、目的の文字の10進Latin-1 (ASCIIのスーパーセット)値を指定します。たとえば、<記号の10進Latin-1値は60であるため、XMLでの前述の行の正しいコーディング法は次のとおりです。

<P>4 &#60; 7</P>

これらの文字エンティティのリストについては、第4.8項「特殊文字の値」を参照してください。

4.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

4.5 WebCenter Sitesのタグ

WebCenter Sitesでは、WebCenter Sitesとその製品ファミリの様々な機能へのアクセスを可能にする一連の広範なJSPタグとXMLタグが用意されています。これらのタグを、HTML、Java、JavaScript、および独自に作成するカスタム・タグと組み合せて使用して、Webサイトをコーディングします。

この項では、テンプレート・アセットとエレメントで使用される可能性が高いタグについて、概要を示します。WebCenter Sitesのすべてのタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

ここで説明するタグは、次のように用途別に分けています。

- 第4.5.1項「WebCenter Sitesのコンテキストを作成するタグ」

- 第4.5.2項「変数を処理するタグ」

- 第4.5.3項「ページとエレメントをコールするタグ」

- 第4.5.4項「URLを作成するタグ」

- 第4.5.5項「キャッシングを制御するタグ」

- 第4.5.6項「Cookieを設定するタグ」

- 第4.5.7項「プログラミング構文のタグ」

- 第4.5.8項「構成上と承認上の依存関係を管理するタグ」

- 第4.5.9項「ベーシック・アセットに関する情報を取得するタグ」

- 第4.5.10項「アセットセットを作成するタグ(フレックス・アセット)」

- 第4.5.11項「検索状態を作成するタグ(フレックス・アセット)」

4.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タグの外側に配置されたコンテンツは認識されません。したがって、これらのタグの外側のコンテンツはキャッシュされず、これらのタグは正しく機能しません。

4.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の変数の詳細は、第4.6項「変数」を参照してください。

4.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内に存在している必要があります。

4.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タグを作成します。たとえば、Burlington Financialのサンプル・サイトのイメージ・ファイル・アセットは、WebCenter Sitesデータベースに格納されたBLOBであるため、これらのアセットはBlobServerサーブレットで処理する必要があります。このタグは、指定されたBLOBを検索して書式設定する方法をブラウザに指示するHTMLタグを作成します。

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

次のタグを使用すると、現在のテンプレートやエレメントの出力をキャッシュするかどうかを制御できます。

ics.disablecache (XML)

ics:disablecache (JSP)

<ics.disablecache/>

<ics:disablecache/>

ics.disablecacheは、エラー状態の有無をチェックするif/then文と組み合せて使用します。エラーが存在する場合は、結果としてレンダリングされるページはキャッシュされません。ics.disablecacheタグの詳細とコード・サンプルについては、第28.8.2項「間違ったページのキャッシングの防止」を参照してください。

4.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を設定するための唯一の手段です。

4.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タグの外側に配置してください。

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

構成上と承認上の依存関係の詳細は、第28.1項「依存性について」を参照してください。

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は何の処理も実行しません。このタグは、テンプレート内のアセットのリストに対するデータベース問合せがある場合は常に使用してください。

4.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"]/>

このタグは、データベースに対して特定のアセットについて問い合せてから、そのアセットのデータをメモリー内にオブジェクトとしてロードします。このオブジェクトは、当該セッションがフラッシュされるかそのオブジェクトに割り当てられた名前が上書きされるまで、エレメントで使用可能になります。

ロードされたアセットに割り当てるオブジェクト名のスコープは、グローバルです。エレメントによってオブジェクトが誤って上書きされることを防止するために、必ず一意のオブジェクト名を使用してください。便利なネーミング規則は、エレメント名をアセット名に含めることです。この規則に従って一意のアセット・オブジェクト名を作成する例については、第29.1項「例1: ベーシック・モジュラ・デザイン」を参照してください。

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によって取得されるコンテンツとの間の依存関係をログに記録します。

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

- ASSET.LOADとASSET.CHILDRENはデータベース問合せであり、データベースに対する問合せは時間がかかるため、これらのタグは必要な場合にのみ使用してください。たとえば、ASSET.LOADタグとその後続のASSET.CHILDRENタグの間にエラー・チェック・コードを挿入することもできます。後者のタグは、アセットがASSET.LOADによって返されたかどうかを判定します。アセットが存在しない場合は、ASSET.CHILDRENタグを呼び出す理由はありません。

- ASSET.SCATTERコールは、単一のASSET.GETコールよりもはるかに長い時間がかかります。

4.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つの列からなり、これらの列は指定された条件に基づいてソートされます。

4.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タグを使用して空の検索状態を作成する必要があります。

4.6 変数

WebCenter Sitesでサポートされている変数の種類は次のとおりです。

- 通常変数: この変数は、明示的に削除されないかぎり、現在のテンプレートやエレメントが存続している間は存続します。通常変数にはグローバル・スコープが設定されています。

- セッション変数: この変数は、現在のセッションが継続している間は存続します。

WebCenter Sitesでは、予約された名前を持ついくつかの標準変数が用意されています。これらの変数の値を取得することはできますが、これらの変数の名前を他の独自に作成した変数の名前として使用することはできません。

この項で説明するトピックは次のとおりです。

- 第4.6.1項「予約変数」

- 第4.6.2項「通常変数の設定」

- 第4.6.3項「セッション変数の設定」

- 第4.6.4項「変数の操作」

- 第4.6.5項「変数と優先順位」

- 第4.6.6項「変数に関するベスト・プラクティス」

4.6.1 予約変数

次の表では、WebCenter Sitesの標準的な変数を説明しています。特に明記しないかぎり、これらは通常変数です。

表4-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 Fusion Middleware 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

子テンプレートの値(子テンプレートが存在する場合)。子テンプレートの詳細は、第29.3項「例3: ct変数の使用」を参照してください。

p

アセットの親ページのID(親ページが存在する場合)。

rendermode

ページ・エントリがライブ、エクスポート済、プレビュー済のいずれの状態で提供されるのかを指定します。デフォルトでは、rendermodeはliveです。ディスクへのエクスポートまたはプレビュー機能を使用する場合は、WebCenter Sitesは自動的にこの変数の値をexportまたはpreviewにオーバーライドします。この値は内部で使用されるため、変更しないでください。

seid

SiteEntryアセットのID。

tid

テンプレート・アセットのID。

eid

CSElementアセットのID。eidは、CSElementのルート・エレメントで使用できます。

4.6.2 通常変数の設定

WebCenter Sitesのテンプレートやエレメントをコーディングする際に使用する変数のほとんどは、通常変数です。通常変数は、WebCenter Sitesのタグを使用して明示的に削除されないかぎり、現在のテンプレートやエレメントが存続している間は存続します。

4.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"/>

4.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という名前の変数

4.6.2.3 Oracle WebCenter Sites Explorerを使用したエレメントとテンプレートのデフォルト変数の設定

Oracle WebCenter Sites Explorerを使用してページ内のデフォルト変数を作成するには、それらの変数を次のフィールドのいずれかに入力します。

- SiteCatalogデータベース表のresargs1フィールドまたはresargs2フィールド

- ElementCatalogデータベース表のresdetails1フィールドまたはresdetails2フィールド

たとえば、Oracle WebCenter Sites Explorerを使用してSiteCatalog表にアクセスして、次のようにresargs1フィールドとresargs2フィールドに名前と値のペアを入力することで、dogとcatという変数を作成できます。

この例では、一方の名前と値のペアをresargs1に入力して、もう一方の名前と値のペアをresargs2に入力していることに注意してください。別の方法として、次の図のように両方の名前と値のペアをresargs1に入力することもできます。

次のようにresdetails1フィールドとresdetails2フィールドに名前と値のペアを入力することで、ElementCatalog表でdogとcatの値を設定することもできます。

URLを通じて設定された変数や、POST操作やGET操作を通じて設定された変数は、SiteCatalog表やElementCatalog表を使用して設定された変数よりも優先されます。たとえば、URLを通じて変数dogがrexに設定されている一方で、SiteCatalogでdogがfidoに設定されている場合は、結果として得られるdogの値はrexになります。

4.6.2.4 HTMLフォームを使用した変数の設定

CGIプログラミングでは、購入者はフォームに入力します。次に、ブラウザはその購入者の入力内容を名前と値のペアとしてエンコードして、これらの名前と値のペアはCGIスクリプトに渡されます。

WebCenter Sitesでは従来のCGIプログラミングは使用されませんが、WebCenter Sitesのエレメントは従来どおりフォームを表示できます。従来のプログラミングの場合と同様に、ブラウザは購入者の入力内容を名前と値のペアとしてエンコードします。ただし、これらの名前と値のペアはCGIプログラムに渡されるかわりに、別のWebCenter Sitesページに渡されます。受取り側のWebCenter Sitesページは、WebCenter Sitesの任意の変数にアクセスするのと同じように、これらの名前と値のペアにアクセスできます。

Cookieの名前と値も変数としてインスタンス化されます。Cookieの詳細は、第9章「セッションおよびCookie」を参照してください。

4.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"/>

4.6.4 変数の操作

次の各項では、WebCenter Sitesの変数を操作する方法を説明しています。

4.6.4.1 変数の値の取得

変数の値を読み取るために使用する構文は、次のように変数のタイプに応じて異なります。

表4-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では、リスト変数にアクセスするための多くのメソッドが用意されています。

4.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>

4.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"/>

4.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>

このセクションの出力は次のとおりです。

REPLACEALLタグは文字列の検索と置換を実行するため、その処理には長い時間がかかる可能性があります。可能な場合は、REPLACEALL属性を使用してください。REPLACEALLタグを使用する必要がある場合は、このタグで囲むコードの量をできるだけ少なくしてください。

4.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は次のHTMLを生成します。

<p>So long.</p>

4.6.5 変数と優先順位

URLを通じて設定された変数や、HTTPのGET操作やPOST操作を通じて設定された変数は、SiteCatalog表やElementCatalog表のresargs列やresdetails列を使用して設定された変数よりも優先されます。

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

すべての変数はグローバルであり、リスト内のアイテムから変数にアクセスするための構文と他のソースから変数にアクセスするための構文は同じであるため、適切なコーディング手法はエラーを回避するのに役立ちます。例:

- エレメント内でベース名を再利用することは簡単なため、変数の前に接頭辞を付けてそれらの変数を一意に定義してください。推奨される構文は、Variables.assettype:fieldnameです。
たとえば、Variables.Article:descriptionのようにします。

ASSET.SCATTERタグでは、そのPREFIX属性を通じてこの構文を簡単に使用できます。このタグの詳細は、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- RESOLVEVARIABLESタグを使用して変数を解決しようとしている場合は、DELIMITEDパラメータをtrueに設定して、デリミタ$(および)を使用して解決対象の変数を明示的に示してください。

- デバッグを通じてネーミングの競合を検出してください。プロパティ・エディタを使用してcom.fatwire.logging.csプロパティを設定してください(このプロパティは、commons-logging.propertiesファイルまたはlog4j.propertiesファイル内にありますが、どちらのファイルにあるかは、使用しているロギング・フレームワークによって決まります)。このプロパティを有効にすると、WebCenter Sitesは、作成されたすべての変数のレコードをWebCenter Sitesのログ・ファイルに書き込みます。

WebCenter Sitesのタグによってerrno変数に書き込むことができるエラー値のリストについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

4.7 WebCenter Sitesの他の記憶域構成体

通常変数とセッション変数に加えて、WebCenter Sitesはいくつかの記憶域構成体をサポートしています。次の各項では、これらの構成体とこれらの使用法を説明します。

- 第4.7.1項「ビルトイン」

- 第4.7.2項「リスト」

- 第4.7.3項「カウンタ」

4.7.1 ビルトイン

WebCenter Sitesでは、現在日付などの値を返すいくつかのビルトインが用意されています。

ビルトインの一般的な構文は次のとおりです。

CS.builtin

たとえば、UniqueIDは一意のIDを生成するビルトインです。次の構文は、このビルトイン変数を生成または参照します。

CS.UniqueID

WebCenter Sitesのビルトインのリストについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

4.7.2 リスト

リストは、行と列で編成された値の表からなります。SETROWタグまたはGOTOROWタグを使用して、適切な行を識別します。

次のエンティティはリストを作成します。

- SELECTTOタグ、EXECSQLタグ、CATALOGDEFタグ、STRINGLISTタグおよびCALLSQLタグ

- CatalogManagerのコマンド

- TreeManagerのコマンド

- カスタム・タグ

現在の行の列値を参照するには、次の構文を使用します。

listname.colname

たとえば、carsという名前のリストにcolorという名前の列が存在する場合、現在の行の値を参照するには次のようにします。

cars.color

4.7.2.1 リストのループ処理

リストを反復処理するには、LOOPというXMLタグまたは ics:listloopというJSPタグを使用します。リスト内の各行について、WebCenter Sitesはこれらのループ・タグの内側に配置された命令を実行します。

たとえば、次の行が含まれたMyCarsという名前の表があるとします。

表4-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>

4.7.3 カウンタ

カウンタは、整数値が格納されるXML変数です。カウンタは次の3つのタグによって制御されます。

表4-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

4.8 特殊文字の値

XMLやJSPで(英数字以外の)特殊文字を使用する必要がある場合は、それらの16進文字表現を使用する必要があります。たとえば、次の行では変数値の一部として空白を指定しています。

<SETVAR NAME="foo" VALUE="foo%20bar"/>

次の表では、WebCenter Sitesでよく使用される特殊文字の16進値を示しています。

表4-12 特殊文字の値

16進値

文字

%22

二重引用符(")

%20

単一の空白

%3c

小なり記号(<)

%3e

大なり記号(>)

%26

アンパサンド(&)

%09

タブ(\t)

%0a

改行(\n)

%0d

改行(\r)

%25

パーセント(%)

5 ページのデザインとキャッシング

この章では、WebCenter Sitesのキャッシングの仕組みについて説明します。Webページをキャッシュすると、サイトのパフォーマンスを向上させることができます。サイトが静的か動的かに関係なく、指定されたページの一部または全体がキャッシュされるようにサイトをデザインする必要があります。

この章には次の項が含まれます。

- 第5.1項「モジュラ・ページ・デザイン」

- 第5.2項「キャッシング」

- 第5.3項「Satellite Serverキャッシュのコンテンツの表示」

- 第5.4項「二重バッファ・キャッシング」

5.1 モジュラ・ページ・デザイン

Webページのデザインには、モジュラ・ページ・デザイン戦略をとることをお薦めします。モジュラ・ページ・デザイン戦略とは、Webサイトの訪問者に表示される各Webページが複数のエレメントで構成されるというものです。モジュラ・ページ・デザインには次のようないくつかの利点があります。

- 効率的なキャッシュ戦略を策定可能にすることで、システム・パフォーマンスを向上させます。

- ナビゲーション・バーのような一般的なデザイン・エレメントを1回コーディングするのみで、複数のWebページで利用できます。

次の図では、シンプルなモジュラ・ページを示しています。

図5-1 モジュラ・ページ

それぞれの四角形は、1つ以上のエレメントの出力として生成されたページレットを表しています。これらのページレットは、格納ページによってコールされます。格納ページは、完成ページ上でこれらのページレットがどのように表示されるかというレイアウトを決定し、その格納ページが表示されるたびに評価される必要のあるコードを含んでいます(カスタムのACLチェック・コードなど)。この戦略を使用すると、エレメントを1回コーディングのみで、そのエレメントをWebサイトの様々な場所で利用できます。

5.2 キャッシング

WebCenter Sitesでは、Webページ全体をキャッシュしたり、それらのWebページを構成しているコンポーネントをキャッシュしたりできます。効率的なページ・キャッシング戦略を使用すると、負荷を軽減してシステム・パフォーマンスを向上させることができます。

WebCenter Sites製品ファミリの次の2つのメンバーではページ・キャッシングが実装されています。

- WebCenter Sitesでは、WebCenter Sitesシステム上でページがキャッシュされます。

- Satellite Serverは、WebCenter Sitesシステム用の第2レベルのキャッシングを提供し、Webページのリモート・キャッシュとしても使用できます。

WebCenter Sitesは、WebCenter SitesとSatellite Serverの両方のキャッシュを利用して、効率的なキャッシュ戦略を実現します。

5.2.1 WebCenter Sitesのキャッシング

ContentServerサーブレットへの要求によって生成されたページレットは、ディスク上でキャッシュできます。アクセス頻度の高いページのコンテンツが少数のパラメータに依存している場合は、そのページはディスクにキャッシュする対象の有力な候補です。

ページレットをディスクにキャッシュするには、次のタグのいずれかを使用します。

表5-1 キャッシングのタグ

JSPタグ

XMLタグ

satellite:page

SATELLITE.PAGE

render:satellitepage

RENDER.SATELLITEPAGE

キャッシュしようとしているページレットがまだディスク・キャッシュ内にない場合は、ContentServerはそのページレットをキャッシュに追加してから、そのページレットを処理します。指定されたページレットがすでにディスク・キャッシュ内にある場合は、ContentServerは単にそのページレットを処理します。

ディスクにキャッシュされたページレットの有効期限は時間ベースであり、futuretense.iniファイル内のプロパティと、SiteCatalog表のcscacheinfo列とsscacheinfo列で設定された値によって制御されます(cscacheinfoはWebCenter Sitesサーブレットに対応し、sscacheinfoはSatellite Serverサーブレットに対応します)。キャッシュ済ページが要求されると、その有効期限(キャッシュ・タイムアウト)がSystemPageCache表のetime列に格納されます。WebCenter Sitesサーブレットを通じて要求されたキャッシュ済ページの有効期限は、cscachinfoの値に基づいて計算され、Satellite Serverサーブレットを通じて要求されたキャッシュ済ページの有効期限は、sscacheinfoの値に基づいて計算されます。キャッシュ内のアイテムは、キャッシュされていないページと同じセキュリティ・ルールの制約を受けます。WebCenter SitesのACLは、エレメントに対して適用されるのとまったく同じように、キャッシュされたページレットにも適用されます。

5.2.2 BlobServerとキャッシング

BLOBという用語は、Binary Large OBject(バイナリ・ラージ・オブジェクト)の頭字語です。BLOBは通常はイメージ・ファイルですが、Microsoft Wordファイルやスプレッドシートを含むどのようなバイナリ・オブジェクトであってもかまいません。ほとんどのWebサイトではいくつかのBLOBが処理されます。

BLOBを処理するために、WebCenter Sitesには、BlobServerという特殊なサーブレットが用意されています。BlobServerは、表からBLOBを収集して、すべての関連するセキュリティ・チェックを実行します。

BlobServerにアクセスするには、次に示すBlobServerのタグを使用します。

- satellite:blob

- render:satelliteblob

これらのタグはどちらも、WebCenter SitesとSatellite ServerのキャッシュにBLOBを格納します。BlobServerのタグの詳細は、Oracle Fusion Middleware 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に設定します。

5.2.3 Satellite Serverのキャッシング

Satellite Serverは、WebCenter Sitesとともに自動的にインストールされて、追加のキャッシング層を提供します。WebCenter Sitesシステムのパフォーマンスを向上させるために、リモートのSatellite Serverシステムを追加して、コンテンツの配置場所を対象ユーザーに近づけることができます。

Satellite Serverは、ページ、ページレットおよびBLOBをディスクやメモリーにキャッシュします。Inventoryサーブレットを使用すると、メモリー・キャッシュやディスク・キャッシュのコンテンツを、様々な度合いで詳細に確認できます。Satellite Server上でキャッシュされたアイテムは、WebCenter SitesのAPIによって保護されないことに注意してください。この制限に対処するには、第5.4.1.1項「ページレットのキャッシュ戦略」で概述しているキャッシュ戦略を使用します。

Satellite Serverは、小さいアイテムをメモリーにキャッシュして、大きいアイテムをディスクにキャッシュします。大小の定義は、file_sizeプロパティで制御します。Satellite Serverのプロパティの設定の詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

訪問者が多いサイトでは、各Satellite Serverシステムのキャッシュは、アクセス頻度の高いページによってすぐに一杯になります。キャッシュが一杯になると、Satellite Serverは古いページを削除して、新しいページ用のスペースを確保します。Satellite Serverは、最低使用頻度アルゴリズム(LRU)を使用して、キャッシュから削除するアイテムを決定します。つまり、新しいページをキャッシュする必要がある場合は、Satellite Serverは最も長い時間にわたってアクセスされていないページを削除します。たとえば、キャッシュ内に、36時間アクセスされていないページと2時間アクセスされていないページの2つがあるとします。この場合、Satellite Serverは36時間アクセスされていないページを削除します。

5.2.3.1 キャッシュの有効期限

Satellite Server上のページとページレットの有効期限は、SiteCatalog表のsscacheinfo列で指定します。ページまたはページレットがSatellite Serverを通じて呼び出されるたびに、Satellite Serverはsscacheinfoフィールドの値を処理して、そのページまたはページレットの有効期限を特定します。sscacheinfoフィールドの詳細は、第7章「ページ・キャッシングの高度な手法」の第7.4項「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プロパティの値から有効期限を取得します。このプロパティについては、第5.3.4.1項「WebCenter Sitesページのキャッシングのプロパティ」を参照してください。

- satellite.blob.cachecontrol.defaultプロパティの値が設定されていない場合は、Satellite Serverは、expirationプロパティの値から有効期限を取得します。このプロパティについては、第5.3.4.2項「Satellite Serverのプロパティ」を参照してください。

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

次の各項では、SatelliteサーブレットによるWebページのキャッシュ方法と、サイトでSatellite Serverのキャッシングを実装する方法を説明しています。Satelliteサーブレットによるキャッシングをモジュラ・ページ・デザインと組み合せて使用すると、高速で効率的なWebサイトを作成できます。

Satelliteサーブレットによるページのキャッシュ方法

Satelliteサーブレットを使用すると、ページレット・レベルのキャッシングが可能になります。Satelliteサーブレットを使用したキャッシングを実装するには、Satellite ServerのXMLタグまたはJSPタグをWebCenter Sitesページで使用して、Satelliteの特殊なURLを使用してページにアクセスします。

たとえば、Satelliteサーブレットを使用して、myPageという名前のWebページ上にページレットレベルのキャッシングを実装したとします。図5-2で示すように、このページは、格納ページと3つのページレットA、BおよびCで構成されています。格納ページとページレットAおよびBは、Satellite Serverシステム上ですでにキャッシュされていますが、ページレットCはキャッシュされていません。

図5-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_name:port/servlet/Satellite?pagename=page

ここで、host_nameとportは、ご使用のSatellite Serverコンピュータのホスト名とポート番号であり、pageは、要求するページの名前です。SatelliteのURLには、コール対象のページに渡す名前と値のペアを含めることもできます。

ページレットのキャッシング

この後に示しているサンプル・コードでは、render:satellitepageタグを使用してページレットをコールしています。このページレットがSatellite Serverのキャッシュ内にまだない場合は、Satelliteサーブレットはそのページをロードしてキャッシュします。このページレットの処理時にエラーが発生して、このページレットを評価できない場合は、このページレットはキャッシュされません。

render:satellitepageタグ(およびsatellite:pageタグとこれらと同等の機能を持つXMLタグ)は、このタグに渡された名前と値のペアおよびページ名に基づいてキャッシュ済ページレットを識別します。パラメータや名前と値のペアが呼出し間で異なる場合は、生成されるコンテンツが同じであっても、異なるページレットがキャッシュされます。これらのタグを通じてページレットに引数を渡すために、名前と値のペアを使用することが重要です。

ICSオブジェクト・プール、ICSリスト・プール、ページ属性コンテキストおよびセッション(セッション変数を含む)を通じて渡された値は、すべてのキャッシュ済ページレットで使用できるとはかぎりません。ネストされたページレットが、常に親と同時にコールされるとはかぎらないからです。さらに、セッションやコンテキストのデータに依存しているページレットは、いずれにしてもキャッシュ可能であることはまれなため、これらのページレットをキャッシュしようとすると、不確定的な動作が生じる可能性があります。

render:satellitepageタグ(およびsatellite:pageタグとこれらと同等の機能を持つXMLタグ)を通じてネストされたページレットに渡されるすべてのパラメータは、SiteCatalog内でページ基準として指定される必要があります。WebCenter Sitesでは、このようにして、キャッシュ対象のページレットを作成する際に該当するパラメータが特定されます。SiteCatalogにリストされているもの以外のパラメータは使用できません(このことを示すエラーがログに書き込まれます)。

<cs:ftcs>
<html>
<body>
<render:satellitepage pagename="My/Sample/Page" />
</body>
</html>
</cs:ftcs>

BLOBのキャッシング

Satelliteタグを使用したBLOBのロードとキャッシュは、Satelliteタグを使用してページレットをロードおよびキャッシュする方法と似ています。次のサンプル・コードでは、BLOBとページレットをコールすることで、前述の例を拡張しています。

7行目では、ics:selecttoタグを使用して、データベースからBLOBを取得するシンプルなSQL問合せを実行します。結果は、imagelistという名前のIListの形式で返されます。

12行目では、satellite:blobタグを使用して、データベースから取得されたBLOBをロードします。satellite.pageタグの場合と同様に、このBLOBがSatelliteのキャッシュ内にない場合は、SatelliteはこのBLOBをロードした後にキャッシュします。cachecontrolパラメータは、このBLOBが、指定された時刻(この例では30分ごと)に失効するように設定されています。

1. <html>

2. <body>

3. <!-- NOTE: This will fail if list has no content (== null) -->

4. <ics:setvar name="category" value="logo"/>

5. <ics:setvar name="errno" VALUE="0"/>

6. <ics:selectto from="SmokeImage" list="imagelist" where="category" limit="1"/>

7. <ics:then>

8. <!-- Test a blob -->

9. <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" />

10. <ics:then>

11. <render:satellitepage pagename="QA/Satellite/Functional/xml/"pagelet1"cachecontrol="never"/>

12. </body>

13. </html>

有効期限のない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 Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

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

Inventoryサーブレットを使用すると、キャッシュに格納された様々なアイテムを表示できます。Inventoryサーブレットを呼び出すには、次のURLを使用します。

http://host:port/servlet/Inventory?username=username&password=passwordword&detail=value

ここで:

表5-2 Inventoryサーブレットのパラメータ

パラメータ

説明

host:port(必須)

キャッシュを表示するSatellite Serverホストのホスト名とポート番号。

username(必須)

そのSatellite Serverホストにログインするために入力するユーザー名。

password(必須)

そのSatellite Serverホストにログインするために入力するパスワード。

detail(任意指定)

Inventoryサーブレットによって表示する情報のタイプ。有効な値は次のとおりです。

- names: ヘッダー情報に加えて、キャッシュ内のページのページ名を表示します。

- keys: ヘッダー情報に加えて、キャッシュ内のアイテムのキーとページ名を表示します。

detailパラメータを指定しない場合や、このパラメータをnameやkeys以外の値に設定した場合は、ヘッダー情報が表示されます。

ヘッダーには次の情報が含まれています。

表5-3 情報タイプ

情報タイプ

説明

リモート・ホスト

このSatellite Serverシステムが要求を転送する先となるホスト。

最大キャッシュ・オブジェクト数

キャッシュに格納できるアイテムの最大数。

現在のサイズ

キャッシュに現在格納されているアイテムの数。

キャッシュのチェック間隔

失効したアイテムがキャッシュに格納されているかどうかをチェックする間隔(分単位)。

デフォルトのキャッシュ有効期限

expirationプロパティの値。

最小ファイル・サイズ(バイト単位)

この値より大きいアイテムはファイルに格納されます。この値より小さいアイテムはRAMに格納されます。

5.3.1 CacheManager

WebCenter Sites CacheManagerオブジェクトは、WebCenter SitesとSatellite Serverの両方のキャッシュを管理します。CacheManagerの役割は次のとおりです。

- ページレットをキャッシュ追跡表に記録します。

- キャッシュ依存性アイテムをキャッシュ追跡表に記録することで、ページやページレットに含まれたコンテンツ(アセット)の記録を保持します。キャッシュ依存性アイテムとは、そのアイテムが変更されると、そのアイテムが格納されているキャッシュ内のページやページレットを無効化するアイテムのことです。キャッシュ依存性アイテムは、現在のページとそのページのすべての親ページの依存要素としてログに記録されます。

- 無効なアイテムが含まれたページやページレットをWebCenter SitesとSatellite Serverのキャッシュから削除します。

- 無効なページが削除された後に、更新されたページやページレットを使用してWebCenter SitesとSatellite Serverのキャッシュを再構築します。

5.3.2 SiteCatalog表

WebCenter SitesのSiteCatalog表には、WebCenter Sitesによって生成されたページとページレットが一覧表示されます。エレメントがWebCenter SitesやSatellite Serverでキャッシュされるためには、そのエレメントのエントリがSiteCatalog表に含まれている必要があります。

SiteCatalog表内のフィールドは、WebCenter Sitesのページのデフォルト動作(デフォルトのキャッシング動作を含む)を設定します。SiteCatalog表とそのフィールドの詳細は、第23.4項「テンプレート・アセットの作成」および第23.6項「SiteEntryアセットの作成」を参照してください。

5.3.3 キャッシュ・キー

WebCenter SitesやSatellite Serverのキャッシュに格納されたアイテムには、キャッシュ・キーと呼ばれる名前が付与されます。キャッシュ・キーは、キャッシュ内の各アイテムを一意に識別します。CacheManagerは、キャッシュ・キーを使用してキャッシュ内のアイテムを検索します。WebCenter SitesとSatellite Serverは、SiteCatalog表のpagename、resargs、pagecriteriaの各フィールドの値と他の内部データに基づいて、自動的にキャッシュ・キーを生成します。

5.3.3.1 pagecriteriaとキャッシュ・キー

ページで使用される変数をキャッシュ・キーに含めるには、SiteCatalog表のpagecriteriaフィールドでそれらの値をカンマ区切りリストの形で指定します。たとえば、redとblueという値が使用されるmyPageという名前のページがあるとします。redとblueをmyPageのキャッシュ・キーに含めるには、次のように入力します。

pagecriteria列にはfavoritecolor,second_favoritecolor、resargsl列にはfavoritecolor=red&second_favoritecolor=blue。

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フィールドで指定された値をオーバーライドします。

5.3.4 キャッシングのプロパティ

WebCenter SitesとSatellite Serverのデフォルトのキャッシュ設定は、futuretense.iniファイルに含まれています。追加のSatellite Serverプロパティは、satellite.propertiesに含まれています。すべてのプロパティは、プロパティ・エディタを使用して変更できます。

この項では、WebCenter SitesとSatellite Serverのキャッシングのプロパティについて概述します。プロパティとプロパティ・エディタの詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

5.3.4.1 WebCenter Sitesページのキャッシングのプロパティ

futuretense.ini内の次のプロパティは、WebCenter Sites上のディスク・キャッシングを制御します。

- cs.pgCacheTimeout: WebCenter Sitesのキャッシュ内のページのデフォルト・タイムアウトを指定します。

- cs.freezeCache: 失効したエントリをキャッシュから削除するためにキャッシュ削除スレッドを実行するかどうかを制御します。

- cs.nocache: WebCenter Sitesページのキャッシュ全体を無効にします。

- cc.SystemPageCacheTimeout: キャッシュされたページがメモリー内に保持される時間を分単位で指定します。

- cs.alwaysUseDisk: SiteCatalog内で、キャッシュ・オーバーライドのプロパティが指定されていないページ・エントリのデフォルト動作を指定します。

- cc.SystemPageCacheCSz: メモリー内にキャッシュできるページの最大数を指定します。

5.3.4.2 Satellite Serverのプロパティ

Satellite Serverには、2つのプロパティ・セットが用意されています(詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照)。

- 1つ目のプロパティ・セットは、WebCenter Sitesシステム上のfuturetense.iniファイルに含まれており、このセットに含まれるものは次のとおりです。

- satellite.page.cachecontrol.default: satellite.pageタグとRENDER.SATELLITEPAGEタグ(およびこれらと同等の機能を持つJSPタグ)のcachecontrolパラメータのデフォルト値を指定する非推奨のプロパティです。

- satellite.blob.cachecontrol.default: satellite.blobタグとRENDER.SATELLITEBLOBタグ(およびこれらと同等の機能を持つJSPタグ)のcachecontrolパラメータのデフォルト値を指定します。

- もう1つのプロパティ・セットは、各Satellite Serverホスト上のsatellite.propertiesファイルに含まれており、このセットを構成するものは次のとおりです。

- cache_folder: Satellite Serverがページレットをディスクにキャッシュする際のキャッシュ先ディレクトリを指定します。

- file_size: 指定されたサイズを基準にして、ディスクにキャッシュされるページレットおよびBLOBを、メモリーにキャッシュされるページレットおよびBLOBから分離します。

- expiration: BLOBがSatellite Serverのキャッシュ内に保持される期間のデフォルト値を設定します。

- cache_check_interval: キャッシュ・クリーナ・スレッドの実行間隔を制御します。これにより、失効したオブジェクトがキャッシュから削除されるタイミングが制御されます。

- cache_max: 一度にキャッシュできるオブジェクト(ページレットとBLOB)の最大数を指定します(メモリー・キャッシュとディスク・キャッシュの合計)。

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

WebCenter SitesとEngageでは、ライブWebサイト上でWebCenter SitesとSatellite Serverのキャッシュを同時に使用するという二重バッファ・キャッシュ戦略が実装されます。この二重バッファ・キャッシュ戦略により、WebCenter SitesまたはSatellite Server上で、ページが常にキャッシュ内に保持されます。

他のCSモジュールやCS製品を使用せずに、WebCenter SitesコアおよびSatellite Serverを実行している場合は、CacheManager Java APIを使用して同様のキャッシュ戦略を実装できます。CacheManager Java APIの詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

WebCenter SitesコアとSatellite Serverのキャッシュはどちらも、WebCenter SitesのCacheManagerオブジェクトによって管理されます。CacheManagerは、エレメントとこれらのエレメントによってコールされるアセットをキャッシュ追跡表に記録することで、コンテンツが変化するタイミングを追跡管理します。

アセットが更新およびパブリッシュされると、WebCenter SitesとSatellite Serverのキャッシュは次の順序で自動的にフラッシュおよび更新されます。

- コンテンツ・プロバイダは、更新されたアセットを配信システムにパブリッシュします。CacheManagerは、キャッシュ追跡表をチェックして、どのキャッシュ済アイテムがこれらの更新されたアセットの影響を受けるのかを確認します。

- CacheManagerは、古いPage1をWebCenter Sitesのキャッシュからフラッシュして、更新されたPage1をWebCenter Sitesのキャッシュに再ロードします。
Page1が要求された場合は、Satellite Serverのキャッシュ内にある古いバージョンのPage1がその要求元に渡されます。これにより、WebCenter Sitesコンピュータでは、キャッシュを削除して再構築する際の過剰な負荷が防止されます。

- CacheManagerは、古いアイテムをSatellite Serverのキャッシュからフラッシュします。訪問者がこのWebサイトにアクセスしてPage1を要求すると、Satellite Serverは検索を実行して、Page1が自身のキャッシュに存在するかどうかを確認します。Page1はSatellite Serverのキャッシュ内には存在しないため、この要求はWebCenter Sitesに転送されます。

- Satellite Serverシステムのキャッシュは、WebCenter Sitesのキャッシュから取得された更新バージョンのPage1で一杯になります。この更新されたページは、要求元に提供されます。Page1が再び要求された場合は、このページはSatellite Serverのキャッシュから提供されます。

5.4.1 二重バッファ・キャッシングの実装

二重バッファ・キャッシングを実装するため最初のステップは、第5.1項「モジュラ・ページ・デザイン」の説明に従ってモジュラ・ページをデザインすることです。モジュラ・ページ・デザインが完成したら、次の3つのステップによって二重バッファ・キャッシュ戦略を実装します。

- ページレットのキャッシュ戦略を策定します。

- SiteCatalog表のpagecriteriaフィールドを使用して、個別のページとページレットのキャッシング方法を設定します。

- Satelliteのタグを使用してエレメントをコーディングします。

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

モジュラ・ページ・デザインでは、キャッシングはページレット・レベルで行われます。格納ページは一切キャッシュされないため、すべてのキャッシュ済ページレットは常にACLによって保護されます。ページレットの更新頻度に基づいて、キャッシュ対象にするページレットを選択します。

次の表では、ページレットのキャッシングに関するガイドラインを要約しています。

表5-4 ページレットのキャッシングに関するガイドライン

ページレットをキャッシュすべきケース

ページレットをキャッシュすべきでないケース

- コンテンツがめったに変化しない場合。

- 評価が機能することを必要とするロジックがページレットに含まれていない場合。

- コンテンツが頻繁に変化する場合。

- コンテンツのリアルタイム性が要求される場合。

- ACLの有無をチェックするコードや、評価が機能することを必要とする他のロジックがページレットに含まれている場合。

次の図では、モジュラ・ページの例を示しています。

図5-3 モジュラ・ページ

格納ページは絶対にキャッシュしないでください。キャッシュしないことにより、キャッシングのパフォーマンス上の利点を通常どおり得られるとともに、WebCenter Sitesによる評価を必要とするロジックをページに配置することが可能になります。また、WebCenter SitesのACLによってページを保護することも可能になります。

この例のヘッダーとフッターのページレットは、ディスクにキャッシュされる必要があります。これらのページレットはめったに更新されないため、そのことを考慮してデザインする必要があります。ヘッダーとフッターは、テンプレート内に書き込まれた静的HTMLであっても、WebCenter Sitesのディスクにキャッシュされたコンテンツであってもかまいません。

サイドバーもディスク・キャッシング対象の有力な候補です。サイドバーにはわずかなバリエーションしかなく、そのコンテンツは少数のパラメータによって決定されるからです。

本文ページレットのキャッシュ方法を決定することはさらに複雑です。本文ページレットのコンテンツは、多くの場合、Webサイトの訪問者がサイト内のどこにいるのかによって変化します。本文ページレットのコンテンツとしては、次の3つのタイプが考えられます。

- Webサイトの訪問者が実行する検索の結果

- 頻繁に実行される問合せの結果

- 記事

キャッシュ戦略は次のような内容にする必要があります。

- 本文ページレットのコンテンツが、Webサイトの訪問者が入力するパラメータに基づいた検索の結果である場合は、そのコンテンツをキャッシュしないでください。このようなページは訪問者ごとに変化するため、これらをキャッシュすることの利点はほとんどありません。

- コンテンツが訪問者によって頻繁に使用される標準問合せの結果である場合は、結果セットのキャッシングを使用してください。頻繁に実行される問合せをメモリーにキャッシュすると、パフォーマンスが向上します。結果セットのキャッシングの詳細は、第14章「結果セットのキャッシングと問合せ」を参照してください。

- 本文ページレットのコンテンツが記事のテキストである場合は、そのページレットをディスクにキャッシュしてください。

5.4.2 cscacheinfoの設定

SiteCatalog表のcscacheinfoフィールドの値によって、WebCenter Sites上のページのキャッシュ方法をページごとに制御できます。

これらのプロパティは、Webサイト内のページごとおよびページレットごとに変更できます。たとえば、格納ページのエレメントがWebCenter Sitesでキャッシュされないようにするには、cscacheinfoの値をfalseに設定します。

cscacheinfoフィールドの詳細は、第23.4項「テンプレート・アセットの作成」を参照してください。

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

二重バッファ・キャッシングを実装するには、Satellite Serverのタグを使用してエレメントをコーディングします。WebCenter SitesとSatellite Serverのみを実行している場合は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスのSatellite Serverに関する項に記載されているSatelliteタグを使用してください。

自動キャッシュ・メンテナンスが機能するためには、アセットがキャッシュ追跡表に記録される必要があります。ASSET.LOADタグを使用してアセットをロードする場合は、そのアセットは自動的にキャッシュ追跡表に記録されます。ASSET.LOADタグが使用されないセクションについては、RENDER.LOGDEPタグを使用してコンテンツをキャッシュ追跡表に記録してください。

注意:

キャッシュの依存関係がログに記録されるのは、ページまたはページレットがWebCenter Sites上でキャッシュされている場合のみです。あるページが、WebCenter SitesではキャッシュされていないがSatellite Serverではキャッシュされている場合は、そのページのコンテンツが更新されたときに、そのページはキャッシュから自動的にフラッシュされません。

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

キャッシュされるページレットについては、サイトを設計してキャッシュ戦略を策定する際に、セキュリティに関して特別な考慮が必要となります。次の各項では、WebCenter SitesとSatellite Serverでキャッシュされるページのセキュリティ考慮事項を概述しています。

5.4.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>

5.4.4.2 Satellite Serverのセキュリティ

Satellite Server上でキャッシュされるページレットは、次の場合にのみWebCenter SitesのACLによって制約されます。

- WebCenter Sitesのキャッシュから取得された場合

- ページ要求に応えるために、WebCenter Sitesによって生成される必要がある場合

ページレットがSatellite Serverのキャッシュから提供される場合は、そのページレットはWebCenter SitesのACLによって保護されなくなります。

Satellite Serverページのコンテンツのセキュリティを確保するには、格納ページをいっさいキャッシュせずに、キャッシュされないコンテナにACLチェック・メカニズムを必ず組み込んでください。

エレメントがSatelliteのタグを使用してコーディングされているが、
Satellite Serverをまだインストールしていない場合は、第5.4.4.1項「WebCenter Sitesのセキュリティ」で概述されているページ・デザイン考慮事項が当てはまります。ただし、Satellite Serverをインストールしたら、WebCenter Sitesは、格納ページからコールされるキャッシュ対象外ページレットのACLをチェックします。Satellite Server上でキャッシュされるページレットのACLはチェックされません。

6 WebCenter Sitesのインテリジェント・キャッシュ管理

サイトを構築するときは常に、コンポーネントのすべてが協調して動作するようにレンダリング・エンジン・キャッシュを適切に構成することが不可欠です。この章では、レンダリング・エンジン・キャッシュとそのコンポーネントについて説明します。また、基盤となるコンテンツの変更が原因で古くなったオブジェクトのすべてのキャッシュ(ContentServer、BlobServerおよびSatellite Serverのキャッシュ)をCacheManagerでクリアできるキャッシュ構成プロパティについても説明します。

この章には次の項が含まれます。

- 第6.1項「WebCenter Sitesのレンダリング・エンジン・キャッシュ」

- 第6.2項「CacheManager」

- 第6.3項「CacheManagerの有効化」

6.1 WebCenter Sitesのレンダリング・エンジン・キャッシュ

WebCenter Sitesのレンダリング・エンジン・キャッシュは2層構造のキャッシュです。第1層はContentServerとBlobServerで構成されており、第2層はSatellite Serverで構成されています。各コンポーネントは独立した構成が可能で、キャッシュ・サイズ、キャッシュ・タイムアウトおよび依存性管理の動作を最適化するように微調整できます。

サイトを構築するときは常に、コンポーネントのすべてが協調して動作するようにレンダリング・エンジン・キャッシュを適切に構成することが不可欠です。コンポーネントが適切に構成されている場合、WebCenter Sitesは順調に動作し、キャッシュされていないコンテンツをユーザーに表示することを、ほぼ常時、効果的に防ぐことが可能です。ただし、これらのコンポーネントの構成が適切でない場合は、WebCenter Sitesの動作はわかりにくく予期しないものになる可能性があります。キャッシングが不適切だとパフォーマンスが低下し、キャッシュ・インベントリが不適切に連係されると、無効なコンテンツが無期限にレンダリングされる場合があります。これに対処するため、WebCenter SitesにはCacheManagerと呼ばれるモジュールが組み込まれており、これにより、システム全体にかわって、キャッシュを有効に管理できます。

6.2 CacheManager

CacheManagerを使用したサイトでは、レンダリング・エンジンによりキャッシュされるオブジェクトに対し、構成依存関係の存在を記録できます。たとえば、ページレットがアセットをレンダリングすると、そのアセットはそのページで構成依存関係になります。アセットが変化した場合、ページは無効になり、キャッシュからフラッシュする必要があります。

CacheManagerを利用してキャッシュをフラッシュするには、オブジェクトがキャッシュから失効しないように指定することにより、レンダリング・エンジンのキャッシュ・オブジェクトのライフサイクルに対する完全制御をCacheManagerに譲る必要があります。基となるコンテンツ(つまり、各オブジェクトに対して記録されている構成依存関係のいずれか)の変更によりオブジェクトが古くなったとCacheManagerにより判断された場合、それらのオブジェクトはキャッシュから削除されます。

注意:

有効期限を無期限に指定する理由は、オブジェクトに対してどの依存関係が記録されているかだけでなく、キャッシュされたすべてのオブジェクトについて、CacheManagerがレコードに残すようにするためです。このレコードはWebCenter Sitesに格納されており、第1層にキャッシュされたオブジェクトの有無とリンクしています。このレコードにより、第2層のキャッシュのオブジェクトの有無をCacheManagerが推測して、第2層のキャッシュからオブジェクトをフラッシュできるようになります。

ただし、オブジェクトがキャッシュから失効するようになっていると、レコードが削除され、第2層のキャッシュからオブジェクトを適切にフラッシュするために必要となる情報が、CacheManagerに伝わらないままになります。

CacheManagerの機能の有効化は、次のとおりほぼ完全に自動で行われます。

- デフォルトでは、キャッシュはオブジェクトが失効しないよう構成されています。

- 構成依存性は、下位層のBLOBおよびページ・キャッシュに対して記録されます。<asset:loadや<render:sateliteblobなどのタグを使用すると、構成依存性が自動的に記録されます(詳細なリストについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照)。それに対し、<portal:logdepと<render:logdepという2つのタグを使用すると、構成依存性が明示的に記録されます。

- アセットが変更またはパブリッシュされた場合は、WebCenter SitesではCacheManagerが自動的に起動され、キャッシュから古いコンテンツが消去されます。また、パブリッシュの場合は、第2層のキャッシュをフラッシュする前にバックグラウンドで新しいコンテンツをあらかじめキャッシュするように、WebCenter SitesからCacheManagerに指示されます。

サイトの訪問者は、キャッシュされていないコンテンツを表示する必要がなく、最高のキャッシュ・パフォーマンスを得られます。構成依存関係の記録の詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

6.3 CacheManagerの有効化

この項では、第1層および第2層のキャッシュ構成プロパティと、CacheManagerを有効化するためにそれらのプロパティをどのように設定する必要があるかについて説明します。

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

- 第6.3.1項「第1層のキャッシュ構成プロパティ」

- 第6.3.2項「第2層のキャッシュ構成プロパティ」

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

この項に記載する表では、WebCenter Sitesのページ・キャッシュおよびBlobServerのBLOBキャッシュを調整するプロパティについて説明します。

- 表6-1「WebCenter Sitesのページ・キャッシュ・プロパティ」

- 表6-2「BlobServerのキャッシュ・プロパティ」

詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

表6-1 WebCenter Sitesのページ・キャッシュ・プロパティ

プロパティ

説明

cs.pgCacheTimeout

このプロパティでは、ページがWebCenter Sitesのページ・キャッシュに存在する期間を指定します。また、CacheManagerには次のような影響が発生します。

デフォルトでは、このプロパティは0に設定されます。この場合、ページはこのキャッシュに永久に存在し、これらのページの削除は明示的に行われる必要があります。CacheManagerが適切に動作するには、このプロパティを0に設定してください。0に設定しない場合、ページの有効期限が切れ、CacheManagerによる第2層キャッシュからの対応ページの削除ができなくなるため、ユーザーには失効したデータが表示されます。

このプロパティに正の整数を設定すると、整数で指定された時間(単位は分)後にページが期限切れになります。

cs.IItemList

このプロパティでは、IItemListインタフェースを実装するクラスを指定します。また、CacheManagerには次のような影響が発生します。

IItemListインタフェースは、ページ・キャッシュに複合依存性を記録する場合に使用されます。このプロパティを有効なクラスに設定すると、依存性項目は、SystemItemCache表のページIDに対して記録されます。これで、CacheManagerが有効になります。

無効な値を設定するとCacheManagerは無効になります。

cc.SystemPageCacheCSz

cc.SystemPageCacheTimeout

cs.alwaysusedisk

cs.freezeCache

cs.nocache

cs.requiresessioncookies

これらのプロパティはページ・キャッシュの構成に使用されますが、CacheManagerには影響しません。これらのプロパティの詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

表6-2 BlobServerのキャッシュ・プロパティ

プロパティ

説明

bs.bCacheTimeout

このプロパティでは、BlobServerによりキャッシュにBLOBが保持される秒数を指定します。また、CacheManagerには次のような影響が発生します。

構成依存関係が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のセキュリティ機能を制御します。また、CacheManagerには次のような影響が発生します。

BlobServerのセキュリティが有効な場合は、キャッシングが無効になります。したがって、BlobServerのセキュリティは、CacheManagerのインテリジェント・キャッシュ管理機能とは両立しません。

デフォルトでは、このセキュリティのレベルは無効です。

BlobServerのセキュリティの詳細は、第5章「ページのデザインとキャッシング」および第7章「ページ・キャッシングの高度な手法」を参照してください。

cs.manage.expired.blob.inventory

このプロパティでは、BLOBがBLOBキャッシュから失効した後に、SystemItemCache表からBLOB依存性レコードを削除することを制御します。CacheManagerへの影響は、bs.bCacheTimeoutの値に依存します。

- bs.bCacheTimeoutが0以下に設定されている場合、このプロパティは無効です。

- bs.bCacheTimeoutが正の整数に設定されている場合、このプロパティにtrueを設定すると、CacheManagerはそのまま正常に動作しますが、SystemItemCache表は肥大します。デフォルト値はfalseです。

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

第2層のキャッシュ構成プロパティは、Satellite Serverのページ・キャッシュとBLOBキャッシュの両方を扱います。

第2層のプロパティは、CacheManagerの正常動作に一切影響しません。ただし、CacheManagerが正常に動作しなくなった場合には、重要な診断支援機能を果たします。第2層のキャッシュ・プロパティのタイムアウト値および構成値は、予期しない動作のトラブルシューティングにとって重要です。

通常の場合、オブジェクトが第2層のキャッシュにはキャッシュされているのに、第1層のキャッシュにはキャッシュされていないと、依存アセットの保存またはパブリッシュ時に、オブジェクトが有効にフラッシュされないため、予期しない動作が起こります。構成の詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

予期しない動作は、キャッシュされたオブジェクトに対して構成依存関係が記録されていない場合にも起こります。その場合、キャッシュ上の該当オブジェクトに対するあらゆる有効な管理ができなくなります。構成依存関係を自動的に記録するタグ、また:logdepタグのいずれかを使用した明示的な記録と組み合せて使用する必要のあるタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

注意:

ページまたはBLOB上の余分な構成依存関係を記録しないでください。これを行うと、キャッシュの不必要なフラッシュが発生し、特定の状況で、パブリッシュ中にパフォーマンスの深刻な問題を引き起こす可能性があります。不明な構成依存関係を記録する場合は特に注意してください。構成依存関係の詳細は、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

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

キャッシングにより、WebCenter Sitesのページ提供のパフォーマンスが向上します。レンダリングされたコンテンツをキャッシュすることにより、コンテンツが要求されるたびにレンダリングする必要がなくなります。これにより、WebCenter Sitesシステムのハードウェア要件が軽減され、キャッシュされていないコンテンツをクライアントが要求する回数が減り、最終的に応答時間が短縮します。

キャッシング・システムには複数のレイヤーがあります。これにより、キャッシュされたオブジェクトの再生成を1つのキャッシュ・レベルで実行でき、その一方で、別のキャッシュ・レベルにキャッシュされたコンテンツがクライアントに提供されます。WebCenter Sitesは内部レベルのキャッシュで構成され、Satellite Serverは外部レイヤーのキャッシュで構成されます。

この章では、レンダリングされたオブジェクトのキャッシングがWebCenter Sitesプラットフォームでどのように行われるかについて説明します。ページとBLOBがどのようにキャッシュされるか、どこにキャッシュされるか、WebCenter SitesとSatellite Server両方のシステムでどのようにキャッシュから取得されるかについて説明します。

この章には次の項が含まれます。

- 第7.1項「WebCenter Sitesキャッシュの構成」

- 第7.2項「BlobServerキャッシュの構成」

- 第7.3項「Satellite Serverキャッシュの構成」

- 第7.4項「CacheInfo文字列の構文」

7.1 WebCenter Sitesキャッシュの構成

WebCenter SitesとSatellite Serverでは両方とも、ページ、ページレットおよびBLOBがキャッシュされます。WebCenter Sitesには、CSページ・キャッシュ、BlobServerキャッシュ、SSキャッシュという3種類のレンダリング・エンジン・キャッシュが用意されています。これらのキャッシュはみな制御可能です。次のように構成したり、空にしたりできます。

- キャッシュの最大サイズを構成できます。詳細および手順は、第7.1.1項「キャッシュの最大サイズの構成」を参照してください(WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュ)。

- オブジェクトは有効期限情報とともにキャッシュに格納できるので、キャッシュでオブジェクトの有効期限が切れると、そのオブジェクトは削除されます。詳細および手順は、第7.1.2項「個々のエントリの有効期限の設定」を参照してください(WebCenter SitesキャッシュおよびBlobServerキャッシュ)。

- オブジェクトは手動で、またはCacheManagerを使用して自動的に、キャッシュから明示的に削除できます。詳細および手順は、第7.1.3項「キャッシュからのエントリの明示的削除」を参照してください(WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュ)。

WebCenter Sitesページ・キャッシュには、2つのレベルのキャッシングがあります。

- データベース内。

- メモリー内。メモリー・キャッシュは、データベース・キャッシュの透過的なサブセットですが、単独での構成が可能です。

この項では、各キャッシュの主な構成設定について説明します。この項は、次のトピックで構成されています。

- 第7.1.1項「キャッシュの最大サイズの構成」

- 第7.1.2項「個々のエントリの有効期限の設定」

- 第7.1.3項「キャッシュからのエントリの明示的削除」

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

- WebCenter Sitesのデータベース・キャッシュには、最大サイズ構成オプションはありません。

- ページ・キャッシュのメモリー・サブセットにより、futuretense.iniファイルのcs.SystemPageCacheCSzプロパティを使用して、キャッシュできるエントリの最大数を指定できます。正の整数を設定すると、キャッシュ二存在できるエントリの最大数が指定されます(キャッシュでは、最大サイズに達したときに削除されるエントリを特定するために、最低使用頻度(LRU)アルゴリズムが使用されます)。

注意:

値を0に設定すると、すべてのエントリが追加され、即座に削除されます。ただし、これは避ける必要があります。

cs.SystemPageCacheCSzプロパティは-1に設定しないでください。

最大サイズは、キャッシュに格納される総バイト数とは関係ありません。

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

WebCenter Sitesページ・キャッシュ内での個々のエントリのライフタイムは、各エントリのcscacheinfo設定により決定されます。CacheInfoオブジェクトは、cscacheinfoフィールドに明示的に設定されていなければ、構成ファイルから値が取得されます。CacheInfoの構文については、第7.4項「CacheInfo文字列の構文」を参照してください。

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

WebCenter Sitesには、キャッシュからエントリを削除する方法が2つ用意されています。1つは手動、もう1つはCacheManagerを使用した自動的な方法です。

手動削除

ページ・キャッシュからエントリを手動で削除できます。CacheServerサーブレットを使用できます。CacheServerには、次の2つのオプションが用意されています。

- キャッシュ全体をフラッシュします。

- 有効期限が切れた時点で、すべてのページのフラッシュを強制フラッシュします。CacheServerのすべてフラッシュする機能を起動するためには、SiteCatalog表を破棄する権限を持つユーザーとしてログインし、CacheServerサーブレットの起動時にパラメータall=trueを指定する必要があります。パラメータを指定しないと、有効期限が切れたエントリ(有効期限が過去であるエントリ)がすべて、キャッシュからただちにクリアされます。有効期限がまだ切れていないエントリはクリアされません。

注意:

有効期限が切れたエントリは、たとえまだデータベース表の中にあったとしても、キャッシュから提供されることはありません。WebCenter Sitesでは、ページを表示する前に、キャッシュから取得されたすべてのページの有効期限がチェックされます。有効期限が切れたページをWebCenter Sitesが表示しようとすると、そのページはただちにキャッシュから削除され、新しいページが生成されます。

自動削除

CacheManagerは、WebCenter SitesのページおよびBLOBのキャッシュ・メカニズム内部と密接に結びついているモジュールです。このツールにより、ページにロードされたアイテム、ページの有効期限、またはページに渡されるパラメータに基づいて、すべてのレンダリング・キャッシュのコンテンツを管理できるようになります。

CacheManager自体は、完全に独立したドキュメントの対象になる場合もあります。ただし、その機能の概要はここで説明します。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キャッシュに再移入されます。

これらのメソッドを使用すると、パフォーマンスがきわめて高い動的サイトを可能にするツールである、二重バッファ・キャッシングを利用できます。二重バッファ・キャッシングの詳細は、第5章「ページのデザインとキャッシング」を参照してください。

7.2 BlobServerキャッシュの構成

BlobServerキャッシュは、オール・オア・ナッシングのキャッシュです。つまり、エントリはグローバルにキャッシュされるか、グローバルにキャッシュされないかのどちらかです。

セキュリティが有効な場合は、BlobServerキャッシングが無効になります。したがって、bs.security=trueである場合、キャッシングは無効化されます。

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

- 第7.2.1項「キャッシュの最大サイズの構成」

- 第7.2.2項「個々のエントリの有効期限の設定」

- 第7.2.3項「キャッシュからのエントリの明示的削除」

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

futuretense.ini内のプロパティbs.bCacheSizeは、BLOBキャッシュが収容するエントリの数を指定します。サイズに負の数が設定されると、BLOBキャッシュを無制限に増大することが許可されます。

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

BlobServerは、キャッシュされたエントリに対して、個々のエントリの有効期限をサポートしていません。キャッシュされたオブジェクトはすべて、futuretense.ini内のbs.bCacheTimeoutプロパティで決められたタイムアウトの期間、キャッシュ内に存在します。負のタイムアウト値は、エントリがタイムアウトしないことを示します。正の整数は、オブジェクトがキャッシュ内に存在する期間(単位は分)を指定します。

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

BlobServerは、個々のエントリおよびすべてのエントリのキャッシュからのフラッシュをサポートします。

手動削除

キャッシュからエントリを手動で削除するには、blobtableパラメータの名前をflushblobtableに変更するのみです。これにより、残りのパラメータに対応するエントリがキャッシュから削除されます。

キャッシュからすべてのエントリを手動で削除するには、2つのオプションがあります。1つは、パラメータflushblobtables (sに注意)でBlobServerサーブレットを起動する方法です。もう1つは、前述のようにCacheServerサーブレットを起動する方法です。ただし、すべてのページとすべてのBLOBがキャッシュからフラッシュされます。

自動削除

BLOB依存アイテムはBLOBリンクが生成されたときに記録されるため、ページと同様に、BLOBを管理するためにCacheManagerを起動できます。(実際、CacheManagerは常にBLOBとページを一緒に管理します)。CacheManagerの使用の詳細は、CacheManagerおよびWebCenter Sitesに関する項を参照してください。

注意:

BLOBを提供する前に、開発者はアセットのステータスをチェックする必要があります。これにより、アセットが無効化された後に、BlobServerによってBLOBが提供されるという問題を回避できます(この動作は、ベーシック・アセットでのみ発生します)。

7.3 Satellite Serverキャッシュの構成

Satellite Serverの汎用キャッシュ構成は、satellite.propertiesファイルで行います。ただし、キャッシュ構成は通常、オブジェクトごとにオーバーライドされます。

この項では、キャッシュの最大サイズの構成方法と、キャッシュからのエントリの明示的な削除方法(手動削除および自動削除)について説明します。

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

一度にキャッシュに格納できるエントリの最大数は、satellite.propertiesファイルのcache_maxプロパティを使用して構成できます。このプロパティに負の整数を設定すると、キャッシュのサイズは制限されません。正の整数は、キャッシュに格納できるエントリの最大数を指定します。

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

この項で説明しているように、個々のエントリは、手動で、または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キャッシュのコンテンツを追跡する方法によるものです。

前述のように、対応するオブジェクトがWebCenter Sitesにキャッシュされているかぎりは、CacheManagerを使用してSatellite Serverキャッシュをフラッシュすることができます。対応するオブジェクトが必要となるのは、WebCenter SitesがSatellite Serverキャッシュのコンテンツを追跡する方法によるものです。

Satellite Serverキャッシュを処理するための該当するCacheManagerメソッドは、flushSSEngines()およびrefreshSSEngines()です。メソッドの詳細は、第7.1.3項「キャッシュからのエントリの明示的削除」を参照してください。

7.4 CacheInfo文字列の構文

SiteCatalogのcscacheinfoフィールドおよびsscacheinfoフィールドには、CacheInfo文字列が移入されます。この項では、文字列のフォーマットについて説明します。これは、2つの部分をカンマで区切った文字列です。最初の部分は、ページがキャッシュされるかどうかを示します。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番目のエレメントに指定された情報に従って、ページがキャッシュされます。

- 値が空白の場合、WebCenter Sitesはfuturetense.iniのプロパティcs.alwaysusediskを参照します。このプロパティがyesに設定されている場合、空白値はtrueと同じ動作をするものと解釈されます。この値がno(デフォルト値)に設定されている場合、空白値はfalseと同じ動作をするものと解釈されます。

- 値が*の場合、これは空白として処理されます。

CacheInfo文字列: 2番目の部分

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番目のエレメントが*である場合、前のタイムアウトで記述したように、ページはタイムアウトによる有効期限切れの動作になります。タイムアウト値は、futuretense.iniファイルのcs.pgCacheTimeoutプロパティから読み込まれます。

空白

2番目のエレメントが空白の場合、*と同じ動作が適用されます。

8 WebCenter Sitesのツールおよびユーティリティ

WebCenter Sitesには、Webサイトの開発および保持を行う際に、WebCenter Sitesのブラウザ・ベースのインタフェースとともに使用する各種ツールおよびユーティリティが用意されています。この章では、これらのユーティリティを簡潔に説明し、その起動方法を示します。

この章には次の項が含まれます。

- 第8.1項「Oracle WebCenter Sites Explorer」

- 第8.2項「WebCenter Sitesデータベースへの接続」

- 第8.3項「CatalogMover」

- 第8.4項「プロパティ・エディタ」

- 第8.5項「XMLPost」

8.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とともにインストールされます。

8.2 WebCenter Sitesデータベースへの接続

WebCenter SitesがインストールされているコンピュータにあるOracle WebCenter Sites Explorerディレクトリ(tools/ContentServerExplorer)をMicrosoft Windowsのリモート・コンピュータ上のディレクトリにコピーするのみで、いずれのリモート・コンピュータでもSites Explorerを使用できます。次に、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ユーティリティが表示されます。

Oracle WebCenter Sites ExplorerへのショートカットをWindowsデスクトップに作成することもできます。Oracle WebCenter Sites Explorerの使用手順は、オンライン・ヘルプ、およびこのマニュアルでOracle WebCenter Sites Explorerを必要とする具体的なタスクを記述している項を参照してください。Oracle WebCenter Sites Explorerおよびその機能の詳細は、Oracle WebCenter Sites Explorerのオンライン・ヘルプを参照してください。

8.3 CatalogMover

CatalogMoverツールは、ElementCatalog表やSiteCatalog表など、WebCenter Sitesデータベースの表をエクスポートおよびインポートするために使用します。たとえば、CatalogMoverを使用すると、ページ・エレメントおよびコンテンツ・アセットを1つのシステムにエクスポートし、同じエレメントおよびアセットを別のシステム上のデータベースにロードできます。エクスポートおよびインポートするデータベース表は、HTMLファイルとZIPファイルのいずれにしてもかまいません。

CatalogMoverは、次の各項で説明するWindowsインタフェースを通じて使用することも、第8.3.7項「コマンドライン・インタフェース」で説明するコマンドライン・インタフェースを通じて使用することもできます。

注意:

以前のバージョンのWebCenter Sitesでは、WebCenter Sitesデータベースの表はカタログと呼ばれていました。この用語は引き続き、一部のデータベース表の名前、およびCatalogMoverツール自体に該当しています。

この項は、次のトピックで構成されています。

- 第8.3.1項「CatalogMoverの起動」

- 第8.3.2項「WebCenter Sitesへの接続」

- 第8.3.3項「CatalogMoverのメニュー・コマンド」

- 第8.3.4項「「カタログ」メニュー」

- 第8.3.5項「表のエクスポート」

- 第8.3.6項「表のインポート」

- 第8.3.7項「コマンドライン・インタフェース」

8.3.1 CatalogMoverの起動

CatalogMoverを起動するには:

MS DOSプロンプトまたはUNIXシェルで次のスクリプトを実行します。

- Windows: catalogmover.bat

- Solaris: catalogmover.sh

次のJARファイルは、クラスパスの中にあるか、または-classpathスイッチで指定されている必要があります。

cs.jar
swingall.jar
commons-logging.jar
cs-core.jar

次に示すCatalogMoverユーティリティが表示されます。

8.3.2 WebCenter Sitesへの接続

CatalogMoverを使用する前に、まずWebCenter Sitesのシステムに接続しておく必要があります。

WebCenter Sitesに接続するには:

1. 「サーバー」→「接続」を選択します。「サーバーに接続」ダイアログ・ボックスが表示されます。

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. 「接続」をクリックします。

8.3.3 CatalogMoverのメニュー・コマンド

CatalogMoverに含まれているメニュー・コマンドは次のとおりです。

「ファイル」メニュー

- 終了: WebCenter Sitesとの接続を切断してCatalogMoverを閉じます。

「サーバー」メニュー

- 接続: 「サーバーに接続」ダイアログ・ボックスを表示します。

- 再接続: 「サーバーに接続」ダイアログ・ボックスを表示して、WebCenter Sitesの現在の接続を更新します。

- 切断: WebCenter Sitesとの接続を切断します。

- 一時表のパージ: インポート済の表をコミットする前にパージします。

- 個別の表のコミット: インポート済の表をデータベースにコミットします。

- エクスポート時にファイル名を正規化: CatalogMoverのファイル名の正規化動作を有効にします。その動作では、移動中のファイルの名前が、対応するID番号と一致する名前に変更されます。この機能が有効でない場合は、ファイル名は変更されません。

「CatalogList」メニュー

- ロード: データベース内のすべての表のリストを表示します。

8.3.4 「カタログ」メニュー

- ロード: リストから表をローカル・メモリーにロードします。次の図は、ロードされたElementCatalog表を示しています。

「ElementCatalog」タブをクリックして、その表の中の行をすべて表示し、エクスポートする特定の行を選択します。

- リフレッシュ: WebCenter Sitesデータベースからロードされた表を更新します。

- カタログの自動インポート: 以前にエクスポートされたZIPファイルをインポートします。

- カタログのインポート: 別のWebCenter Sitesデータベースからエクスポートされた表をローカル・データベースにインポートします。

- カタログの行のエクスポート: ロードされた表に、選択した行をエクスポートします。

「選択」メニュー

- すべての行を選択: 現在表示されている表ですべての行を選択します。

- すべての行を選択解除: 現在表示されている表ですべての行を選択解除します。

- 部分文字列で行を選択: 一連の行を一意に識別する、フィールド値の任意の文字列の部分を入力することによって、現在表示されている表で行を選択します。

「ヘルプ」メニュー

- バージョン情報: インストールされているWebCenter Sitesのバージョン情報を表示します。

8.3.5 表のエクスポート

エクスポートとは、表の行およびその内容をデータベースから取得し、ローカルHTMLファイル、および関連付けられたデータ・ディレクトリに保存するプロセスです。CatalogMoverでは、表当たり1つのHTMLファイルが作成されます。

この項は、次のトピックで構成されています。

- 第8.3.5.1項「選択した表の行のエクスポート」

- 第8.3.5.2項「エクスポート対象の行の選択」

- 第8.3.5.3項「ZIPファイルへのエクスポート」

8.3.5.1 選択した表の行のエクスポート

選択した表の行をエクスポートするには:

1. 第8.3.2項「WebCenter Sitesへの接続」で説明しているように、WebCenter Sitesに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、次の第8.3.5.2項「エクスポート対象の行の選択」で説明しているように行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。
ダイアログ・ボックスが表示され、エクスポートされた行を含むHTMLファイルに対し、ディレクトリを指定するように求められます。

5. 選択したディレクトリに移動し、「保存」をクリックします。
CatalogMoverによって、選択した行が、選択したディレクトリにエクスポートされます。

8.3.5.2 エクスポート対象の行の選択

ロードされた表でエクスポート対象の具体的な行をクリックして選択することも、部分文字列を指定して具体的な行を検索することもできます。

部分文字列に従って、行を検索および選択するには:

1. 「選択」→「部分文字列で行を選択」を選択します。
次のダイアログ・ボックスが表示されます。

2. テキスト・フィールドに、検索する部分文字列を入力します。たとえば、主キーElementCatalogを対象として、エレメント名にfolderという文字があるすべての行を検索する場合は、folderと入力して「OK」をクリックします。
CatalogMoverでは、次の図に示すように、表を検索し、その表の主キーに対する部分文字列問合せと一致する行を選択します。

注意:

部分文字列による行選択の対象となるのは、表の中で最も左にある列のみです。ただし、列の位置は変更可能なので、どの列でも最も左にある列になり得ます。そのためには、列ヘッダーをクリック・アンド・ドラッグするだけです。

8.3.5.3 ZIPファイルへのエクスポート

複数の表から複数の行を選択し、CatalogMoverの実行元であるローカル・コンピュータ上のZIPファイルにエクスポートできます。ZIPファイルを作成したら、そのファイルの内容をサーバーの表にインポートできます。

CatalogMoverを使用してZIPファイルをエクスポートするには:

1. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

2. 「カタログ」→「ロード」を選択して表をロードし、第8.3.5.2項「エクスポート対象の行の選択」で説明しているように行を選択します。

3. 「カタログ」→「カタログの行のエクスポート」を選択します。次のダイアログ・ボックスが表示されます。

4. ZIPファイルを保存するディレクトリに移動します。

5. 「ファイル名」フィールドに、ファイルの名前を入力し、ファイル拡張子.ZIPを入力します。

6. 「保存」をクリックします。表のすべてから選択した行が、選択したディレクトリ内のZIPファイルにエクスポートされます。

8.3.6 表のインポート

インポートとは、ローカルに格納されたHTMLファイルおよび関連付けられたデータをサーバーに送信するプロセスです。インポートする特定のHTMLファイルを選択することも、HTMLファイルをすべてインポートするように選択することもできます。

この項は、次のトピックで構成されています。

- 第8.3.6.1項「以前にエクスポートされたHTMLファイルのインポート」

- 第8.3.6.2項「以前にエクスポートされたZIPファイルのインポート」

- 第8.3.6.3項「CatalogMoverの既存のファイルのマージ」

- 第8.3.6.4項「CatalogMoverの既存のファイルの置換」

8.3.6.1 以前にエクスポートされたHTMLファイルのインポート

以前に別の表からエクスポートされたHTMLファイルをインポートするには:

1. 第8.3.2項「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「カタログのインポート」を選択します。

4. 以前にエクスポートされた表の行を含むHTMLファイルに移動します。

5. 目的のHTMLファイルを選択して、「開く」をクリックします。次のダイアログ・ボックスが表示されます。

6. 現在存在していない新しい表の行をインポートする場合は、「データ・ディレクトリのカタログ化」フィールドと「ACLリストのカタログ化」フィールドに情報を入力します。
既存の表の行をインポートされた表の行に置換する場合は、これらのフィールドを空白にしておきます。

7. 「OK」をクリックします。以前にエクスポートされたHTMLファイルに含まれている表の行が、接続先のWebCenter Sitesデータベースにインポートされます。
ダイアログ・ボックスが表示され、インポートされた表の行が一覧表示されます。

注意:

接続先のサーバーに存在していない表をインポートする場合は、インポート時に表が自動的に新規作成されます。

8.3.6.2 以前にエクスポートされたZIPファイルのインポート

CatalogMoverを使用して、エクスポートされたZIPファイルに格納されている表の行をサーバーにインポートできます。

以前にエクスポートされたZIPファイルをインポートするには:

1. データベースに接続しているときに、「カタログ」→「カタログの自動インポート」を選択します。

2. 結果として表示されるダイアログ・ボックスで、表の行を以前にエクスポートしたディレクトリに移動します。ZIPファイルを表示するには、「タイプ別ファイル」メニューを「すべてのファイル」に変更します。

3. 目的のZIPファイルを選択して、「保存」をクリックします。ZIPファイルに含まれている行が、データベースに自動的にインポートされます。

8.3.6.3 CatalogMoverの既存のファイルのマージ

CatalogMoverのファイルをマージするには:

1. 第8.3.2項「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、第8.3.5.2項「エクスポート対象の行の選択」で説明しているように、別のファイルにマージする行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。

5. 行をマージするHTMLファイルに移動します。「保存」をクリックします。「上書き」ダイアログ・ボックスが表示されます。

6. 「エクスポートされた既存のデータの更新」をクリックします。CatalogMoverによって、エクスポートされた行が、選択したHTMLファイルにマージされます。

8.3.6.4 CatalogMoverの既存のファイルの置換

CatalogMoverのファイルを置換するには:

1. 第8.3.2項「WebCenter Sitesへの接続」で説明しているように、HTMLファイルのインポート先とするWebCenter Sitesインストールに接続します。

2. 「CatalogList」→「ロード」を選択して、データベース内のすべての表のリストを表示します。

3. 「カタログ」→「ロード」を選択して表をロードし、第8.3.5.2項「エクスポート対象の行の選択」で説明しているように、別のファイルにマージする行を選択します。

4. 「カタログ」→「カタログの行のエクスポート」を選択します。

5. 行をマージするHTMLファイルに移動します。「保存」をクリックします。「上書き」ダイアログ・ボックスが表示されます。

6. 「エクスポートされた既存のデータの置換」をクリックします。CatalogMoverによって、選択したHTMLファイルの行が、既存の行にマージされます。

8.3.7 コマンドライン・インタフェース

CatalogMoverでは、次のパラメータによって、GUIを表示しないで機能を実行できます。パラメータには、空白、さらに値を続けます。

表8-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のカンマ区切りリスト

8.4 プロパティ・エディタ

プロパティ・エディタ・ツールには簡単に使用できるWindowsインタフェースが用意されており、WebCenter Sitesのfuturetense.iniファイル内でプロパティの表示、変更および追加ができます。

この項は、次のトピックで構成されています。

- 第8.4.1項「プロパティ・エディタの起動」

- 第8.4.2項「プロパティの設定」

- 第8.4.3項「プロパティ・ファイルのマージ」

8.4.1 プロパティ・エディタの起動

プロパティ・エディタを起動するには:

次のスクリプトを実行します。

- Windows NTの場合: propeditor.bat

- Solarisの場合: propeditor.sh

次に示すプロパティ・エディタが表示されます。

プロパティ・エディタでは、データベースやキャッシングなど、機能グループのプロパティがウィンドウの左側に表示されます。

「アイテム」ペインには、選択した機能グループのプロパティが一覧表示されます。

「値」ペインには、選択したアイテムの現在値、アイテムの簡単な説明、およびアイテムで受け入れられる値が一覧表示されます。

注意:

futuretense.iniファイルには、リリース番号の文字列ft.versionが含まれており、この文字列には、4.0.0.など、WebCenter Sitesによって設定された値が含まれます。

このプロパティは変更しないでください。これは参照のみを目的としたものです。

8.4.2 プロパティの設定

システムにWebCenter Sitesのプロパティを設定するには:

1. 必要に応じて、プロパティ・エディタを起動します。

2. 「ファイル」→「検索」を選択して、編集する.iniファイルを開きます。

3. ウィンドウの左側にあるタブからプロパティ・グループを選択します。プロパティがプロパティ・エディタの「アイテム:」ペインに表示されます。

4. 「アイテム:」ペインからプロパティを選択します。現在のプロパティ値および簡潔な説明がプロパティ・エディタの「値:」ペインに表示されます。

5. 「値:」ペインのテキスト・フィールドに新規の値を入力します。

6. 「値:」ペインで、「受入れ」ボタンをクリックします。

7. 変更するすべてのプロパティに対して、手順3から6を繰り返します。

8. 終了したら、「ファイル」→「保存」を選択して変更内容を保存します。

9. 確認メッセージ・ボックスで「OK」をクリックします。

10. 「ファイル」→「保存」を選択して変更内容を保存し、プロパティ・エディタを閉じます。

11. アプリケーション・サーバーを停止してから再起動して、変更内容を適用します。

8.4.3 プロパティ・ファイルのマージ

プロパティ・エディタは通常、futuretense.iniプロパティ・ファイルを変更するために使用します。接続しているサーバー上のプロパティ・ファイルにあるプロパティを、プロパティ・ファイルに追加することもできます。同じプロパティで様々な値が複数のINIファイルに定義されている場合、WebCenter Sitesでは、ロードした最後のプロパティ・ファイルの値が使用されます。

プロパティ・ファイルをfuturetense.iniファイルにマージするには、WebCenter Sitesに接続するときに、2つのプロパティ・ファイルの名前をセミコロンで区切って「iniファイル」フィールドに入力します。プロパティ・ファイルをマージしない場合は、このフィールドを空白のままにします。

たとえば、次の「サーバーに接続」ダイアログ・ボックスは、futuretense.iniとalt.iniがマージされていることを示します。

8.5 XMLPost

XMLPostユーティリティは、WebCenter Sitesデータベースにデータをインポートします。このユーティリティは、WebCenter SitesのFormPoster Javaクラスに基づくもので、WebCenter Sitesの基本製品とともに配布されます。これは、HTTP POSTプロトコルを使用してデータをインポートします。

アセットをインポートするには、WebCenter Sitesに付属している、ポストするエレメントとともにXMLPostを使用します。XMLPostの使用によるアセットのインポートの詳細は、次の各章を参照してください。

- 第20章「任意タイプのアセットのインポート」

- 第21章「フレックス・アセットのインポート」

9 セッションおよびCookie

この章では、XMLタグを使用したセッションとCookieの管理方法について説明します。

この章には次の項が含まれます。

- 第9.1項「セッションの理解」

- 第9.2項「セッションのライフタイム」

- 第9.3項「セッションの例」

- 第9.4項「Cookieとは」

- 第9.5項「Cookieの例」

- 第9.6項「ヒントとコツ」

- 第9.7項「Satellite Serverのセッション・トラッキング」

9.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サイト開発者はオプションとしてその他のセッション変数を作成できます。

アプリケーション・サーバーは、セッションをクラスタ上で保持できます。

9.2 セッションのライフタイム

セッションは、訪問者が初めてWebサイトを訪れたときに始まります。セッションは、次のいずれかが生じたときに終了します。

- 訪問者がブラウザを終了します。

- セッションがタイムアウトしました。WebCenter Sitesは、cs.timeoutプロパティを使用してセッション・タイムアウト値をアプリケーション・サーバーに設定します。このプロパティを300に設定した場合、ユーザー・セッションは300秒、すなわち5分で無効になります。

- システム管理者がアプリケーション・サーバーを停止します。

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

- 第9.2.1項「WebCenter Sitesによって保持されるセッション変数」

- 第9.2.2項「ログインとログアウト」

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

セッションが作成されると、WebCenter Sitesは自動的に次のセッション変数を作成します。

表9-1 セッション変数

セッション変数

保持される内容

SessionVariables.currentUser

ログインした訪問者のid。

SessionVariables.currentAcl

この訪問者が属するすべてのACLのカンマ区切りリスト。訪問者が明示的にログインしていない場合、デフォルトACLはBrowserです。

SessionVariables.username

この訪問者のログイン時のユーザー名。訪問者が明示的にログインしていない場合、デフォルトのユーザー名はDefaultReaderです。

SessionVariables.iniFile

WebCenter Sitesのプロパティが含まれているファイルの名前。

9.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修飾子と同時に呼び出すことによって、セッションを新規作成できます。

9.3セッションの例

次に、3つの非常に短いエレメントで構成される簡単なセッションの例を示します。

表9-2 セッションの例

エレメント

動作

FeelingsForm

訪問者に現在の気分を指定するように依頼します。

SetFeelings

現在の気分をセッション変数に割り当てます。

Meat

セッション変数を評価します。

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

- 第9.3.1項「FeelingsFormエレメント」

- 第9.3.2項「SetFeelingエレメント」

- 第9.3.3項「Meatエレメント」

9.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>

この結果、次のようなページが生成されます。

9.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>

9.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はセッション内のその他すべてのエレメントでも使用可能です。

9.4 Cookieとは

Cookieは、アプリケーションが訪問者のブラウザに書き込む文字列です。Cookieには、セッションを継続している訪問者に関する情報が格納されます。訪問者のブラウザは、この文字列を訪問者のディスク上の特別なCookieに書き込みます。訪問者がWebサイトに戻ったときに、訪問者のブラウザはCookieを設定したWebサーバーにCookieのコピーを返送します。Cookieは、作成されるとただちに、ページ上のエレメントの変数として使用可能になります。

たとえば、アプリケーションで訪問者のお気に入りのスポーツ・チームがCookieに格納されているとします。その場合は、訪問者が戻ったときにアプリケーションはCookieを取得し、その情報を使用してチーム・ロゴをバナーに表示することもできます。

Cookieが不要に成った場合は、削除できます。

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

- 第9.4.1項「CookieServer」

- 第9.4.2項「Cookieのタグ」

9.4.1 CookieServer

CookieServerは、ユーザーにかわってCookieを設定するサーブレットです。CookieServerにアクセスするには、satellite.cookieタグを使用してCookieを作成します。

9.4.2 Cookieのタグ

WebCenter Sitesには、Cookieの管理用に次の2つのタグがあります。

表9-3 Cookieのタグ

タグ

使用法

satellite.cookie

クライアントのブラウザにCookieを設定します。

REMOVECOOKIE

クライアントのブラウザからCookieを削除します。

Cookieの値を取得する特殊なタグはありません。かわりに、訪問者がWebサイトに戻ると、WebCenter SitesはCookieの値を標準変数としてロードします。

(satellite.cookieを呼び出すことにより)Cookieを作成するときに、次の属性を指定できます。

表9-4 Cookieの属性

属性

値

name

Cookieの名前。これは、Cookieの値が含まれている受信変数の名前としても機能します。

重要: WebCenter Sitesのページ・コンテキストのCookieは、変数として扱われます。したがって、Cookieとアセット属性の名前が同じであれば、同じ変数として扱われます。

有効期限

Cookieが今後Webサーバーに送信されなくなるまでの時間(秒)。

security

オプションとして、Cookieにセキュリティを設定します。

URL

CookieがこのURLのみで送信されるように制限します。

Domain

Cookieが指定されたドメインのURLのみに送信されるように制限します。

一部の訪問者は、Cookieはセキュリティ上の脅威と感じて、Cookieを拒否するようにブラウザを構成することがあります。Cookieの情報が重要である場合に備えて、アプリケーションを構成する必要があります。

任意のタグを使用してコンテンツを訪問者のブラウザに戻す前に、Cookieの設定または削除を行う必要があります。<HTML>タグを使用する前であっても、Cookieの設定または削除が必要です。

9.5 Cookieの例

この例は、非常に短い複数のエレメントで構成されています。

表9-5 Cookieのエレメント

エレメント

動作

Start

Cookieが設定されているかどうかを判別します。Cookieが設定されている場合は、DisplayWelcomeを呼び出します。Cookieが設定されていない場合は、GetColorPreferenceを呼び出します。

ColorForm

訪問者にお気に入りの色を選択するように要求するフォームを表示します。

CreateCookie

この訪問者のブラウザにCookieを作成します。その後で、訪問者をDisplayWelcomeにリダイレクトします。

DisplayWelcome

簡単なようこそメッセージを訪問者のお気に入りの色で表示します。

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

- 第9.5.1項「Start.xml」

- 第9.5.2項「ColorForm」

- 第9.5.3項「CreateCookie」

- 第9.5.4項「DisplayWelcome」

- 第9.5.5項「Cookie例の実行」

9.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>

9.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>

9.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秒)継続します。

9.5.4 DisplayWelcome

DisplayWelcomeが呼び出されるときまでに、Cookieが設定されます。次のコードでは、ようこそメッセージを訪問者のお気に入りの色で表示するためにCookieの値が使用されます。

<H1><font color="Variables.ColorCookie"
REPLACEALL="Variables.ColorCookie">
Displaying a Friendly Welcome.
</font></H1>

9.5.5 Cookie例の実行

Cookie例を実行するには、ブラウザを使用して次のページ名に移動します。

CSGuide/Sessions/Start

この例を初めて実行すると、4つのエレメントがすべて実行されます。2回目以降は、StartとDisplayWelcomeのみが実行されます。

9.6 ヒントとコツ

次の提案が役に立つ場合があります。

- クラスタでは、セッション状態をクラスタ・メンバー全員にレプリケートする必要があります。クラスタでは、セッション・サイズを最小限に抑え、1クライアントにつき2キロバイトを超えるセッションを格納しないようにしてください。

- 妥当なセッション・タイムアウト値を決定します。設定するタイムアウト値が大きすぎると、システム・リソースが拘束されてしまいます。タイムアウト値が小さすぎると、訪問者は何回もログインしなければなりません。

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

パーソナライズしたコンテンツを訪問者に提供するWebサイトでは、セッションの追跡が必要です。WebCenter SitesとSatellite Serverはいずれもセッションを追跡します。双方で訪問者のブラウザにCookieが設定されるため、(1つではなく)2つのCookieがそれぞれ独立してセッションを追跡します。この冗長性はSatellite Serverが停止した場合に役立ちます。Satellite Serverが停止しても、WebCenter Sitesセッションは保持されるためです。

Satellite Serverはセッション固有のページレットを最初の依頼者に返送するだけですが、ユーザーのログアウト時にセッション固有の情報を明示的にフラッシュすることで、Satellite Serverキャッシュの領域が確保されます。

次の各セクションでは、Satellite Serverからセッション情報をフラッシュする方法について説明します。

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

- 第9.7.1項「URLによるセッションのフラッシュ」

- 第9.7.2項「現行セッション情報のフラッシュ」

- 第9.7.3項「その他のセッション情報のフラッシュ」

9.7.1 URLによるセッションのフラッシュ

特定のセッションに関連するすべてのデータをフラッシュできます。これは、フォームを次のフォーマットでURLにポストすることで、WebCenter Sitesから実行します。

https://host:port/servlet/

FlushServer?reset=true&username=username&password=password&
ssid=sessionID

ここで:

表9-6 セッション・パラメータ

パラメータ

値

host

キャッシュがフラッシュの対象となるSatellite Serverホストの名前を指定します。

port

Resinを別のポートで実行するように再構成した場合を除き、80(デフォルト)を指定します。

username

ユーザー名プロパティに割り当てられた値を指定します。

password

パスワード・プロパティに割り当てられた値を使用します。

sessionID

削除対象のセッションを表すセッションID (Satellite Serverではなく、WebCenter Sitesにより保持されているもの)を指定します。

9.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);

9.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

注意:

現在使用しているセッション以外のセッションから情報をフラッシュする場合は、セッション・アフィニティを有効にしておくことをお薦めします。

10 エラー・ロギングおよびデバッグ

WebCenter Sitesには、エラー・メッセージのロギングとソース・コードのデバッグについていくつかのオプションが用意されています。この章では、WebCenter Sitesの開発環境全体で適用される一般的なエラー・ロギングとデバッグの方法について説明します。

WebCenter Sitesではアクティビティをログ・ファイルに記録できますが、ログ・ファイルは新規インストールではsites.logという名前でlogsフォルダに配置されます。ログ・ファイルに書き込まれる情報のタイプとボリュームは、有効化または定義に選択したログ出力により管理されます。ログ出力の詳細は、第10.1項「WebCenter Sitesログ・ファイルへのロギング」を参照してください。

WebCenter Sitesには、JSPタグとXMLタグがタスクを完了できなかった場合にエラー・コードを返すために使用する予約済変数があります。詳細は、第10.2項「タグによるエラー・コードの使用方法」を参照してください。

この章には次の項が含まれます。

- 第10.1項「WebCenter Sitesログ・ファイルへのロギング」

- 第10.2項「タグによるエラー・コードの使用方法」

10.1 WebCenter Sitesログ・ファイルへのロギング

ロギングは、commons-loggingフレームワーク(commons-logging.propertiesファイルを使用)またはApache log4jフレームワークのいずれかに基づいています。

新規のWebCenter Sitesインストールでは、log4jがWebCenter Sitesロギング・システムになります。log4jが設定されると、情報のロギング方法とロギングの対象となる情報を指定するlog4j.propertiesファイルが作成されます。また、WebCenter Sites Adminインタフェースは、「管理」タブ上の「システム・ツール」ノードに「log4jの構成」ツールを用意しています。「log4jの構成」の使用によって、現在のログ出力をAdminインタフェースから直接表示できます。また、新規ログ出力の追加とログ出力レベルの変更も動的に行えます。ログ出力のテキスト・バージョンをこのインタフェースからlog4j.propertiesファイルにコピーしておくと、システムの再起動時でも変更は削除されません。「log4jの構成」ツールの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

log4j.propertiesファイルおよびcommons-logging.propertiesファイルの詳細は、『Oracle Fusion Middleware 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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

注意:

ロギングが実装されているシステムのタイプに一致するレベルでログ出力を設定することをお薦めします。開発システムおよびコンテンツ管理システムでは、大量の情報を提供する高重大度(INFOまたはDEBUGなど)にログ出力レベルを設定できます。配信システムでは、ログ出力を無効にするか低重大度(WARNまたはERROR)に設定することで、パフォーマンスの低下を回避し、公開された環境でシステム情報を利用できます。

10.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)
{
...

エラー番号ルール

エラー番号には必ず整数を使用します。次の表に、Variables.errnoのエラー番号ルールの概要を示します。

それぞれのタグ固有のエラー番号については、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

表10-1 エラー番号ルール

番号

意味

負の整数

失敗

0(ゼロ)

成功

リビジョン追跡タグ以外のタグの正の整数

情報

リビジョン追跡タグの正の整数

失敗

11 データ・デザイン: アセット・モデル

WebCenter Sitesサーブレットは、WebCenter Sitesのコンテンツ管理システムを実行するオペレーティング・システムですが、WebCenter Sitesデータベースはシステムのブレーンです。ここには、WebCenter Sitesアプリケーションを実行させるシステム情報、WebCenter Sitesアプリケーションを使用して管理するコンテンツ(つまりアセット)、およびオンライン・サイトの訪問者にコンテンツを表示するためのフォーマットとビジネス・ロジックを提供する構造的情報が格納されています。

ほとんどの場合、データ・デザインはアセット・デザインを意味します。ただし、開発者はアセットの基礎データを保持する表を頻繁に作成する必要があります。これらの表の必要性を決定し、表を設計する作業もデータ・デザインの一部です。

この章には次の項が含まれます。

- 第11.1項「アセット・タイプとアセット・モデル」

- 第11.2項「ベーシック・アセット・モデル」

- 第11.3項「フレックス・アセット・モデル」

- 第11.4項「assetsetおよびsearchstate」

- 第11.5項「検索エンジンと2つのアセット・モデル」

- 第11.6項「タグと2つのアセット・モデル」

- 第11.7項「要約: ベーシック・アセット・モデルとフレックス・アセット・モデル」

- 第11.8項「要約: アセット・タイプ」

注意:

アセットを保持しない表の設計と作成については、第12章「WebCenter Sitesデータベース」で説明します。

11.1 アセット・タイプとアセット・モデル

アセットとは、WebCenter Sitesデータベースに格納されているオブジェクトで、作成、編集、調査、削除、複製、ワークフローへの配置、リビジョン追跡による追跡、検索、および配信(ライブ)サイトへのパブリッシュが可能なオブジェクトのことです。

アセット・タイプとは、該当するタイプのアセット・オブジェクトの特性を決定する定義または仕様です。

開発者は、アセット・タイプの設計および作成を行うと同時に、コンテンツ管理システムとオンライン・サイトの設計も行います。コンテンツ・プロバイダは、これらのタイプのアセットを作成および編集します。

一般的に、アセットは次の3つのロールのいずれかを実行します。

- 訪問者がオンライン・サイトで読み取ったり調べたりするコンテンツの提供

- コンテンツ表示用の書式設定ロジックまたはコードの提供

- WebCenter Sitesデータベースへのコンテンツ格納用のデータ構造の提供

開発者の仕事は、コンテンツ・プロバイダにとって管理システムで操作しやすく、配信システムから訪問者に効率的に配信可能なアセット・タイプを設計することです。

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

- 第11.1.1項「2つのデータ・モデル」

- 第11.1.2項「デフォルトのコアなアセット・タイプ」

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

11.1.1 2つのデータ・モデル

WebCenter Sitesには、設計したアセット・タイプ用に、ベーシックとフレックスという2つのデータ・モデルが用意されています。

- ベーシック・アセット・タイプは単純データ構造になっています。つまり、1つのプライマリ記憶域表と、お互いの間に単純な親子関係が設定されています。
ベーシック・アセット・タイプは独立したスタンドアロン・アセット・タイプであり、記事、イメージ・ファイル、ページ、問合せなど、個別の種類のコンテンツを表しています。(WebCenter Sitesインタフェースの「管理」タブにある)AssetMakerユーティリティを使用して、ベーシック・アセット・タイプを新規作成します。

- フレックス・アセット・タイプは、複数のデータベース表を備えた複合データ構造になっていて、ベーシック・アセット・タイプよりも多くのフィールドをサポートできます。さらに、複数の親や任意の数の祖父母などを割り当て、そこから属性値を継承することもできます。
フレックス・アセット・タイプは、相互に定義したり、相互に属性値を割り当てるアセット・タイプのファミリで構成されます。(「管理」タブにある)Family Makerユーティリティを使用して、フレックス・アセット・タイプのファミリを作成します。

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

WebCenter SitesとEngageにより、複数のコア・アセット・タイプが配信されます。WebCenter Sitesはスタック・アーキテクチャで構成されているため、コアなアセット・タイプは次の方法で利用可能になります。

- WebCenter Sitesからテンプレート、問合せ、コレクション、SiteEntry、CSElement、リンク、およびページのアセット・タイプが配信されます。その他のモジュールおよび製品はすべて、テンプレートおよびページのアセット・タイプを使用します。

- WebCenter Sitesから属性エディタのアセット・タイプが配信されます。作成したフレックス属性アセット・タイプはいずれもサポートされます。

- Engageから訪問者属性、履歴属性、履歴定義、セグメント、推奨、およびプロモーションのアセット・タイプが配信されます。

これらのタイプのアセットは、アセットの取得、順序付け、編成、書式設定によって、コンテンツを保持しているアセット・タイプの表示用にフォーマットまたはロジックを提供します。つまり、コアなアセット・タイプを使用してオンライン・サイト上でコンテンツの編成と書式設定を行います。

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

WebCenter Sitesで配信されるアセット・タイプは、基本的なサイト・デザイン・ロジックを提供します。これらのタイプのアセットは必要に応じていくつでも作成できますが、アセット・タイプ自体は変更できません。

- 問合せには、選択したパラメータまたは基準に基づいてアセットのリストを取得する問合せが格納されます。問合せアセットはページ・アセット、コレクション、および推奨で使用します。データベース問合せは、問合せアセットに対してSQL問合せとして「新規」フォームまたは「編集」フォームに直接書き込むか、「新規」フォームまたは「編集」フォームで特定されたエレメント(WebCenter Sitesの問合せタグが付いているもの、または検索エンジン問合せ)に書き込むことができます。

- コレクションには、1つのタイプのアセットの順序付けリストが格納されます。コレクションの構築は、1つ以上の問合せを実行し、その結果セットからアイテムを選択し、選択したアイテムをランキングする(順序付ける)ことによって行います。このランキングされ、順序付けられたリストがコレクションです。たとえば、前夜の選挙結果に関する記事が1位になるように政治関連記事のコレクションをランキングできます。

- ページには、他のアセットに対する参照が格納されます。ページ・アセットの配置と設計によって、組織の表示方法やサイトのデザインが決まります。ページ・アセットの設計は、適切なコレクション、記事、イメージ・ファイル、問合せなどをページ・アセット用に選択して行います。さらに、WebCenter Sitesインタフェースの左側にサイトをツリー表示する「サイト・プラン」タブにページ・アセットを配置します。
ページ・アセットと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のコンテンツ管理システムを使用する各組織のデータ・ニーズはそれぞれ異なるため、コンテンツを表示するデフォルトのアセット・タイプは用意されていません。ただし、サンプル・コンテンツのアセット・タイプがサンプル・サイトから配信されるため、そのアセット・タイプを調べて、各自のサイトに応じて変更できます。

Oracle WebCenter Sites: Engage

Engageアプリケーションから配信される複数のコアなアセット・タイプを使用して訪問者情報を収集し、訪問者別に表示される製品の配置や販促用の提供品をパーソナライズできます。

- 訪問者属性には、1つの特性のみ(スカラー値)を指定する情報のタイプが保持されます。たとえば、「経験年数」、「肩書き」、「子供の数」のような名前の訪問者属性を作成できます。

- 履歴属性は、Engageで単一レコードとして扱われる情報のベクターを作成するためにグループ化した個々の情報タイプです。データのこのベクターが履歴定義です。たとえば、「購買」という履歴タイプは、「SKU」、「アイテム名」、「数量」および「価格」という履歴属性で構成できます。

- セグメントは、共通の特性(訪問者属性および履歴タイプ)に基づいて訪問者をグループに分けるアセットです。セグメントの作成は、セグメントの基となる訪問者データ・アセットを決定し、その基準に対して適格値を設定することによって行います。たとえば、アラスカの住民でフライ・フィッシングの道具一式を所有している人々や、過去6か月以内にパソコンを購入した人々などをセグメントで定義できます。

収集する訪問者データを定義して分類した後、次のアセット・タイプを使用して、オンライン・サイトにコンテンツを表示するフレックス・アセットの選択、編成、表示を行います。

- 推奨は、コレクションの拡張版のようなものです。これは、フレックス・アセット(製品や記事など)を収集、評価、ソートし、現在の訪問者が属するセグメントに基づいて、その訪問者に最適なものを推奨します。

- プロモーションは、サイト訪問者が購入しようとしているフレックス・アセット(製品など)と訪問者が資格を有するセグメントに基づいて、ある種の価値または割引を訪問者に提供するマーチャンダイジング・アセットです。

注意:

Oracle WebCenter Sites: Engageは、フレックス・アセット・モデルのみを使用して作成されたアセットと対話します。推奨とプロモーションをプログラミングして、ベーシック・アセット・モデルを使用するアセットを操作することはできません。

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

WebCenter Sitesのコンテンツ管理システムによるオンライン・サイトの設計中に、開発チーム全員でサイト用にコンテンツを表示する必要のあるアセット・タイプを作成します。WebCenter Sitesのテンプレートおよびページ・アセット・タイプにより、ベーシック・データ・モデルとフレックス・データ・モデルのいずれを使用しているかに関係なく、データを表すアセット・タイプに対して書式設定フレームワークが提供されます。

オンライン・サイトに表示するデータを表すために選択する必要のあるアセット・データ・モデル(ベーシックまたはフレックス)は、次の2つの項で説明するように、そのデータの特性に依存します。

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

データに次の特性が備わっている場合は、ベーシック・モデルを選択します。

- 固定していて、予測可能です。つまり、アセット・タイプに属性を追加する必要はありません。

- 同種です。つまり、同一タイプのアセットはすべて類似属性を持っています。

- 適度な数の属性を持っています。ベーシック・アセット用にアセット・タイプに割当て可能な列/属性の数に関して、データベースによる制限があります。

- 静的なパブリッシュ方法を使用したい場合。静的なパブリッシュ方法の使用が合理的と見なされるフレックス・アセット・モデルのアプリケーションは非常に限られています。

- 訪問者は、リンク間を移動してオンライン・サイトを参照します。

アセット・タイプのデータがスプレッドシートと推測でき、そのタイプの各アセットが単一レコードであり、すべてのレコードに同じ列が含まれている単純なフラット・テーブルと推測できる場合には、そのアセット・タイプにベーシック・アセット・モデルを使用する必要があります。

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

データに次の特性が備わっている場合は、フレックス・モデルを選択します。

- 数多くの属性を持ちます。たとえば、製品には数百もの属性を割り当てられる可能性があります。フレックス・ファミリ・メンバーの属性値は、列ではなく行として格納されるため、フレックス・アセットは物理的にベーシック・アセットよりも多くの属性を持つことができます。

- これは、アセットが親アセットから属性値を継承する階層で表すことができます。

- 属性が将来必要になるか、また、データに定期的に属性を追加する必要があるかは予測できません。

- 同一タイプのアセット・インスタンスは大幅に変動する可能性があります。つまり、同一タイプのアセットがすべて同じ属性を持っている必要はありません。たとえば、バスタオル製品アセットには、トースタ製品アセットにはない属性が割り当てられますが、バスタオルもトースタもともに製品アセットです。

- 訪問者は、ドリルダウン、つまりデータの属性値に基づく検索を通して移動することによって、オンライン・サイトを参照します。

- Oracle WebCenter Sites: Engageを使用する場合。

たとえば、マーケットは絶えず変動しているため、製品はフレックス・アセット・モデルに適合します。翌年にどの製品が売れるか、または製品にどの属性が割り当てられるかを常に予測できるとはかぎりません。

ビジネスでアセット・タイプの属性を追加または変更するなど、アセット・タイプに変更を加える必要が生じる場合には、フレックス・データ・モデルを選択することをお薦めします。フレックス・アセット・モデルは、予測不能な特性を持つデータを表す必要がある場合に幅広く対応できます。

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

WebCenter Sitesからベーシック・アセット・モデルが配信されます。一般的には、ベーシック・アセット・タイプのデータ・モデルでは、アセット・タイプごとにデータベース表が1つずつ用意されます。同じタイプのベーシック・アセットには完全に同一のフィールド(プロパティ)があり、単一タイプのアセットはすべて、同じデータベース表に格納されます。WebCenter Sitesのコアなアセット・タイプのほとんどで、ベーシック・データ・モデルが使用されます。

ベーシック・アセット・タイプを新規作成するには、AssetMakerユーティリティを使用します。PROPERTYというカスタム・タグを使用してアセット記述子ファイルと呼ばれるXMLファイルをコーディングし、AssetMakerを使用してファイルをアップロードします。プロパティは列にもフィールドにもなります。PROPERTY文では、該当するタイプのアセットを格納する表に列を定義し、WebCenter Sitesのフォームでその列に対応するフィールドへのデータ入力方法を定義します。

アセット記述子ファイルのコーディングとベーシック・アセット・タイプの新規作成の詳細は、第15章「ベーシック・アセット・タイプの設計」を参照してください。

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

- 第11.2.1項「Burlington Financialサンプル・サイトからのベーシック・アセット・タイプ」

- 第11.2.2項「ベーシック・アセット間の関係」

- 第11.2.3項「カテゴリ、ソースおよびサブタイプ」

- 第11.2.4項「ベーシック・アセット・タイプとデータベース」

11.2.1 Burlington Financialサンプル・サイトからのベーシック・アセット・タイプ

Burlington Financialサンプル・サイトをインストールしている場合、WebCenter Sitesではコンテンツを表す5つのアセット・タイプがインストールされます。これらのサンプル・サイトのアセット・タイプは、WebCenter Sitesによって配信されるベーシック・アセット・モードを使用します。

- 記事には、記事のテキストと関連情報が格納されます。ヘッドライン、署名行、クレジット行、本文などのフィールドがあります。これは、AssetMakerによって作成されたものではないカスタム・アセット・タイプです。

- イメージ・ファイルには、アップロードされたバイナリ・ラージ・オブジェクト(BLOB)としてイメージ・ファイルが格納されます。これらのイメージ・ファイルは、ページや記事など、他のアセットに関連付けることができます。このアセット・タイプは、AssetMakerで作成されました。

このサンプル・サイトでは、必要に応じて、追加の書式設定アセット・タイプの作成方法の例を、次のアセット・タイプとともに提供します。

- スタイルシートには、任意のフォーマット(CSSやXSLなど)のスタイルシート・ファイルが格納されます。スタイルシートをテキスト・エディタで作成し、それをスタイルシート・アセットとしてWebCenter Sitesにアップロードします。スタイルシートをアセットとして格納すると、ワークフローの割当てやリビジョン追跡の使用などが実行できます。このアセット・タイプは、AssetMakerで作成されました。

Burlington Financialでは次のアセット・タイプがインストールされますが、使用されることはありません。

- リンクセットには、関連アセットのURL、または外部WebサイトのURLとのリンクのグループが格納されます。このタイプのアセットは、ページや記事など、他のアセットに関連付けることができます。

- イメージには、ページや記事など、他のアセットに関連付けできるイメージ・ファイルのURLが格納されます。

これらのアセット・タイプは、前のサンプル・サイトで使用されたものです。これらは後方互換性のために含まれています。

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

ベーシック・アセット・タイプは、非常に単純な親子関係を備えています。この関係を使用して、アセットの相互関連付けやリンクを実行します。さらに、オンライン・サイト用にオンライン・ページを設計する際に、アセットの子または親アセットを識別し、抽出して、適切な方法で表示するテンプレート・エレメントをコーディングします。

ベーシック・アセットで相互に割当て可能な関係をアソシエーションおよび名前なし関係といいます。個々のアセット間でこのような関係が発生する場合、その関係はAssetRelationTree表に書き込まれます。

11.2.2.1 アソシエーション

アソシエーションは定義済のアセット・タイプ固有の関係であり、WebCenter Sitesのアセット・フォームにフィールドとして表されます。AssetMakerを使用してアセット・タイプを作成した後、そのアセット・タイプの「アソシエーション」フォームを使用してアソシエーション・フィールドを作成します。

アソシエーションを使用して、システム内でアセット・タイプにとって意味のある関係を設定し、その関係の名前を使用して関連アセットを識別し、それをサイト・ページに適切な方法で表示します。

たとえば、Burlington Financialサンプル・アセットの名前付き記事には、イメージ・ファイル・アセット・タイプとのアソシエーションとして、Main Imagefile、Teaser ImageFile、SpotImageFileという3つのアソシエーションが割り当てられています。Burlington Financial記事テンプレートは、これらのアソシエーションを通して記事にリンクされるイメージ・ファイルを表示するようにコーディングされています。アソシエーションによって、テンプレートは個々の記事アセットの表示に適切なイメージ・ファイルを決定できます。

コンテンツ・プロバイダが「新規」記事フォームおよび「編集」記事フォームのメイン・イメージ・フィールドでイメージ・アセットを選択すると、選択されたイメージ・ファイル・アセットが記事アセットの子になります。(この同じイメージ・ファイル・アセットが、他の記事の子になる場合もあることに注意してください。)

アセット・タイプ間のアソシエーションを新規作成すると、WebCenter Sitesではそのタイプのアソシエーションに対する行がAssociation表に作成されます。さらに、アセットを作成して別のアセットの名前をアソシエーション・フィールドに指定すると、その関係がAssetRelationTree表に書き込まれます。

11.2.2.2 名前なし関係

名前なし関係はコレクション作成時に発生し、コレクション内のアイテムはコレクションの子となります。

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

ベーシック・アセットを編成または分類する方法として、このほかにカテゴリ、ソース、サブタイプの3つがあります。カテゴリとサブタイプはアセット・タイプに固有のものです。ただしソースは、コンテンツ管理サイトのすべてのアセット・タイプに当てはまります。したがって、ソースはサイト固有になります。

11.2.3.1 カテゴリ

categoryは、サイトに適用される規則に従ってアセットを分類する際に使用できるデフォルトの列およびフィールドです。すべてのベーシック・アセット・タイプには、category列がデフォルトで設定されていますが、これを使用する必要はありません(これは必須フィールドではありません)。

たとえば、Burlington Financialサンプル・サイトには、Personal Finance、Banking and Loans、Rates and Bonds、Newsなどのカテゴリがあります。これらのカテゴリによって識別された記事は、選択基準としてカテゴリを使用する問合せによって選択され、特定のサイト・ページに適宜表示されます。

ベーシック・アセット・タイプを新規作成すると、そのタイプのアセットに対するカテゴリ・コードがAssetMakerによって作成されます。さらに、この機能を使用する必要のある場合は、新規アセット・タイプに対して「カテゴリ」フォームを使用し、カテゴリを追加作成します。

新規カテゴリはCategory表に書き込まれます。この表は、ベーシック・アセット・モデルを使用するアセット・タイプに対する「新規」アセット・フォームおよび「編集」アセット・フォームの「カテゴリ」フィールドに対する参照表として機能します。

「カテゴリ」フィールドおよび列は、サイト・デザインを目的としています。オンライン・サイトの問合せおよび問合せアセットにカテゴリを使用できますが、使用しなくても差し支えありません。WebCenter Sitesアプリケーションの機能はいずれも、カテゴリ・コードに基づいてはいません。(例外として、このフィールドを使用している場合は、それに基づいてアセットを検索できます。)

11.2.3.2 ソース

sourceは、アセットが最初に作成された場所の特定に使用できる列およびフィールドです。WebCenter Sitesは、オンライン・サイトの設計でこの機能が使用できるように(「ソース」フォームを通して)管理サポートを提供していますが、デフォルトでは、source列は、記事以外のベーシック・アセット・タイプのプライマリ記憶域表には存在しません。ベーシック・アセット・タイプでソースを使用するには、ソースのアセット記述子ファイルにプロパティ文を含める必要があります。

たとえば、Burlington Financialサンプル・サイトには、WireFeed、Asia Pulse、UPIなどのソースがあります。一部のオンライン・ページでは、ソース列の値に基づいて記事を検索する問合せの結果に基づいて表示するようにストーリーが選択されます。

ベーシック・アセット・タイプを新規作成した後で、必要に応じて、「管理」タブの「ソース」フォームで新規ソースを追加します。新規ソースはSource表に書き込まれます。この表は、ベーシック・スタイル・アセットに対する「新規」アセット・フォームおよび「編集」アセット・フォームの「ソース」フィールドに対する参照表として機能します。

11.2.3.3 サブタイプ

サブタイプという概念から、アセット・タイプをさらに分類する方法が生まれました。フレックス・アセット・データ・モデルでは、定義アセット・タイプによってフレックス・アセットおよびフレックス親アセットのサブタイプが作成されます。ベーシック・アセット・データ・モデルでは、サブタイプの概念は、アセット・タイプに対するプライマリ記憶域表のsubtype列を通して実現されます。

WebCenter Sitesアプリケーションでは、アセットの「サブタイプ」の値を様々な方法で使用します。

- テンプレート・アセットの場合、サブタイプは、テンプレートが書式設定するアセットのタイプを意味します。記事を書式設定するテンプレートは、イメージを書式設定するテンプレートとはサブタイプが異なるテンプレートです。記事アセットを作成する場合は、記事を書式設定するテンプレートのみが、そのアセットの「新規」フォームまたは「編集」フォームの「テンプレート」フィールドにオプションとして表示されます。
また、WebCenter Sites Contributorインタフェースを使用して、所定のテンプレートを使用して表示されるサブタイプを指定することもできます。たとえば、Webサイトでスポーツおよびニュースという2つのサブタイプの記事アセットを使用する場合、スポーツ・サブタイプの記事のみを表示するテンプレートを作成できます。

- 問合せアセットの場合、サブタイプは、問合せが返すアセットのタイプを意味します。記事を返す問合せアセットは、イメージ・ファイルを返すものとは異なるサブタイプの問合せアセットです。

- コレクション・アセットの場合、サブタイプは、コレクションが保持するアセットのタイプを意味します。記事を保持するコレクションは、イメージ・ファイルを保持するものとは異なるサブタイプのコレクション・アセットです。

- 設計したベーシック・アセット・タイプの場合、サブタイプはレンダリングされた方法に基づいてアセットを分類するように機能します。パブリッシュ先それぞれで、アセット・タイプの各サブタイプにデフォルトのテンプレートを定義できます。

特定のタイプのアセットに対して、パブリッシュ先に基づいてそのアセットに別のテンプレートを割り当てる必要がない場合は、サブタイプを新規作成する必要はありません。

アセット・タイプに対して任意のサブタイプを作成すると、そのタイプのアセットに対する「新規」フォームおよび「編集」フォームに「サブタイプ」というフィールドが表示されます。このフィールドのドロップダウン・リストに、そのアセット・タイプに用意されているサブタイプがすべて表示されます。

注意:

フレックス・アセット・モデルでは、定義アセット・タイプがサブタイプとして機能します。たとえば、GE Lightingサンプル・サイトには、照明という1つの製品定義があります。つまり、製品アセットの1つのサブタイプとして、照明サブタイプがあります。

アセット・タイプの中には、サブタイプが暗黙的に設定されていて変更できないものもあります。また、ユーザーがWebCenter Sites Contributorインタフェースを使用してアセットのサブタイプを選択できるアセット・タイプもあります。次の表に、WebCenter Sitesのアセット・タイプを、構成可能なサブタイプがあるかどうかに応じて一覧表示します。

暗黙的なサブタイプ

構成可能なサブタイプ

- すべてのフレックス・アセット

- 問合せアセット

- コレクション・アセット

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

- すべてのカスタム・ベーシック・アセット(AssetMakerで作成)

- 記事アセット

- イメージ・アセット

- リンクセット・アセット

- 推奨アセット

- リンク・アセット

- ページ・アセット

構成可能なサブタイプの設定の詳細は、第15章「ベーシック・アセット・タイプの設計」を参照してください。

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

ベーシック・アセット・タイプにはプライマリ記憶域表が1つありますが、WebCenter Sitesでは、ベーシック・アセットの基本情報は他の表に保持されています。ベーシック・タイプのアセットを新規作成すると、WebCenter Sitesでは次のデータベース表に書き込まれます。

- そのタイプのアセットを保持するプライマリ・データベース表。たとえば、各ページ・アセットではPage表に1行が表示され、各記事アセットではArticle表に1行が表示されます。
これらの表には、アセットの名前、そのオブジェクトID、作成者、使用するテンプレートなど、アセットの属性またはフィールド値がすべて格納されます。この表の名前は、アセット・タイプの名前と常に一致します。

ベーシック・アセット・タイプを新規作成すると、このプロセスの一環として、アセット・タイプに対するプライマリ記憶域表(WebCenter Sitesのオブジェクト表の1つ)がAssetMakerユーティリティによって作成されます。

- アセットに他のアセットとのアソシエーションが設定されている場合は、AssetRelationTree表。ベーシック・アセットに設定可能な関係は、第11.2.2項「ベーシック・アセット間の関係」で説明しています。

- アセットへのアクセスを許可するコンテンツ管理サイト(パブリケーション)を指定するAssetPublication表。サイト(パブリケーション)間でアセットが共有される場合は、pubidごとに行エントリがあります。pubidは、サイト(パブリケーション)を識別する一意の値です。

- アセットがページ・アセットの場合は、SitePlanTree表。この表には、サイト・プランにおけるページ・アセットの階層位置に関する情報が格納されます。

コンテンツを表すアセットを表示するテンプレートを開発する場合、先行リストの表から情報を抽出して表示するエレメントを、XMLタグまたはJSPタグを使用してコーディングします。

各種サンプル・アセット・タイプに対して「新規」フォームおよび「編集」フォームを調べ、Oracle WebCenter Sites Explorerツールを使用してWebCenter Sitesデータベース内の表を調べてください。

注意:

これらの表のいずれでも、データの変更にはOracle WebCenter Sites Explorerツールを使用しないでください。アセットとそれに関連する表の編集すべてには、WebCenter Sitesインタフェースのみを使用してください。

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

テンプレート・アセット・タイプはコアのアセット・タイプですが、ベーシック・アセット・モデルを使用しません。これは、次のデータベース表にエントリを持つコンプレックス・アセット・タイプです。

- Template表、そのプライマリ記憶域表

- SiteCatalog表

- ElementCatalog表

テンプレート・アセットを新規作成すると、WebCenter Sitesでは、SiteCatalog表とElementCatalog表の両方で、そのアセットに対するエントリが自動的に作成されます。

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

WebCenter Sitesは基本機能用にデフォルトの列を複数必要とするため、該当するアセット・タイプに対してアセット記述子ファイルに定義された列のほかに、(次の表に示すように)次の列がAssetMakerによってアセット・タイプのプライマリ記憶域表に作成されます。

このリストの列に対してプロパティ文を含めるようにアセット記述子ファイルをコーディングする必要はありません。

表11-1 アセット・タイプのプライマリ記憶域表の列

デフォルトの列(フィールド)名

説明

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フィールドを使用する場合は、第15.2.3.8項「例: パス、ファイル名、開始日および終了日の有効化」を参照してください。

フォーム:

- プロモーション・アセットに対する「期間」、「編集」および「調査」。

- 他のアセット・タイプに対して有効化する場合は、「新規」、「編集」、「調査」および「ステータス」。

enddate

プロモーション・アセット(Engageアセット)の場合、この列には、プロモーションの期間の終了時刻が格納されます。

プロモーション・アセット・タイプのみが、この列を使用するデフォルトのアセット・タイプです。

フォーム:

- プロモーション・アセットに対する「期間」、「編集」および「調査」

- 他のアセット・タイプに対して有効化する場合は、「新規」、「編集」、「調査」および「ステータス」

subtype

アセットのサブタイプの値。サブタイプは、アセットごとに異なる方法で設定されます。詳細は、第11.2.3.3項「サブタイプ」を参照してください。

フォーム:

- テンプレート・アセット(「アセット・タイプ」フィールド)の場合は、「新規」および「編集」

- 問合せアセット(「問合せの結果」フィールド)の場合は、「新規」および「編集」

- サブタイプが構成されているアセット・タイプの場合は、「新規」および「編集」

- デフォルトのテンプレートの設定

filename

ディスクへのエクスポートのパブリッシュ方法の使用中に、このアセットに作成されたファイルに使用する名前。

ページ・アセット・タイプおよび記事アセット・タイプのみが、デフォルトでこのフィールドが有効になっているアセット・タイプです。

アセット・タイプにfilename名フィールドを使用する場合は、第15.2.3.8項「例: パス、ファイル名、開始日および終了日の有効化」を参照してください。

フォーム:

- ページ・アセットおよび記事アセットの場合は、デフォルトで「新規」および「編集」

- このフィールドが有効になっている他のアセット・タイプの場合は、「新規」および「編集」

path

ディスクへのエクスポートのパブリッシュ方法でアセットをファイルにレンダリングする際、そのアセットの子アセットから生成されるエクスポート済ページ・ファイルに使用するディレクトリ・パス。

ページ・アセット・タイプおよび記事アセット・タイプのみが、デフォルトでこのフィールドが有効になっているアセット・タイプです。

アセット・タイプにfilename名フィールドを使用する場合は、第15.2.3.8項「例: パス、ファイル名、開始日および終了日の有効化」を参照してください。

フォーム:

- ページ・アセットおよび記事アセットの場合は、デフォルトで「新規」および「編集」

- このフィールドが有効になっている他のアセット・タイプの場合は、「新規」および「編集」

テンプレート

アセットのテンプレート。

これは、ディスクへのエクスポートを使用してパブリッシュされるか、ライブのダイナミック配信システムでレンダリングする際に、アセットのレンダリングに使用されるテンプレートです。

このテンプレートは、アセットがディスクへのエクスポートのパブリッシュ方法で承認されている場合の依存性の計算にも使用されます。ただし、アセット・タイプにサブタイプが設定されていて、そのサブタイプに基づいてデフォルトの承認テンプレートがアセットに割り当てられている場合を除きます。

フォーム:

- 新規

- 編集

- 調査

- ステータス

category

アセットに割り当てられたカテゴリがある場合は、そのカテゴリのカテゴリ・コード。

categoryフィールドを使用してアセットを編成する場合は、「管理」タブの「アセット・タイプ」フォームでカテゴリ・コードを追加します。

フォーム:

- 新規

- 編集

- 調査

- ステータス

urlexternaldoc

アセットが、WebCenter Sitesインタフェースでなくサイト・デスクトップ・インタフェースで入力された場合、そのアセットのソースである外部ドキュメントを格納します。

このフィールドの値はWebCenter Sitesで制御され、手動では編集できません。

該当なし

externaldoctype

urlexternaldocフィールドに保持されているファイルのMIMEタイプ。

このフィールドの値はWebCenter Sitesで制御され、手動では編集できません。

該当なし

urlexternaldocxml

将来の使用に備えて予約されています。

該当なし

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

フレックス・アセット・モデルの主な特徴は次のとおりです。

- フレックス・アセットは、フレックス定義によって、つまり個々のフレックス・アセットをどのフレックス属性で構成するかを決定するアセット・タイプによって定義されます。フレックス定義により、フレックス・アセット・タイプのサブタイプが作成されます。

- 定義アセット・タイプによってフレックス・アセットおよびフレックス親アセットのサブタイプが作成されるため、フレックス・アセット・タイプまたはフレックス親アセット・タイプの個々のインスタンスのバリエーションを広げることができます。

- フレックス属性はアセットです。フレックス・データ・モデルによって、フレックス属性を既存のフレックス・アセット・タイプに随時追加(または削除)できます。

- フレックス・フィルタは1つのフレックス属性からデータを取り込み、それを変換または評価し、フレックス・アセットの保存時に別のフレックス属性に結果を格納できます。フレックス・フィルタのアクションによって得られた値を、導出された属性値といいます。フレックス・フィルタの詳細は、第17章「フレックス・フィルタ」を参照してください。

- フレックス・アセットは属性値を(導出値でさえも)フレックス親から継承できるため、データを階層で表すことが可能になります。

ベーシック・アセット・タイプの場合とは異なり、個々のフレックス・アセット・タイプは作成せず、かわりにアセット・タイプのフレックス・ファミリを作成します。

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

- 第11.3.1項「フレックス・ファミリ」

- 第11.3.2項「サンプル・サイトのフレックス・ファミリ」

- 第11.3.3項「フレックス属性」

- 第11.3.4項「フレックス親とフレックス親定義」

- 第11.3.5項「フレックス・アセットとフレックス定義アセット」

- 第11.3.6項「フレックス・ファミリとデータベース」

11.3.1 フレックス・ファミリ

フレックス・アセット・データ・モデルは、アセット・タイプのファミリの観点から考えることができます。フレックス・ファミリには6つのアセット・タイプがあります。次の表に示すように、5つは必須であり、6つ目はオプションです。

表11-2 フレックス・ファミリのメンバー

フレックス・ファミリのメンバー

ファミリ当たりの数

フレックス属性アセット・タイプ

1つ

フレックス親定義アセット・タイプ

1つ以上

フレックス定義アセット・タイプ

1つ以上

フレックス親アセット・タイプ

1つ以上

フレックス・アセット・タイプ

1つ以上

フレックス・フィルタ・アセット・タイプ

ゼロまたはそれ以上

アセット・タイプの中には、開発者がデータ・モデルに他のアセット・タイプを作成するために排他的に使用されるものがありますが、フレックス・アセット・タイプは常に、コンテンツ・プロバイダが当該タイプのアセットを作成するために使用します。(必要に応じて、認証ユーザーに、追加のフレックス・ファミリ・メンバーへのアクセス権を与えることができます。)

フレックス・ファミリを作成するには、WebCenter SitesのAdminインタフェースの「フレックス・ファミリ・メーカー」ノードの「管理」タブにある「新規ファミリの追加」をダブルクリックして、「新規フレックス・ファミリの追加」フォームにアクセスします。「新規フレックス・ファミリの追加」フォームで、ファミリ内の各アセット・タイプに名前を付けます。たとえば、GE Lightingサンプル・サイトのフレックス・ファミリの1つが製品ファミリだとします。フレックス・アセットは製品アセット、フレックス属性は製品属性というように呼ばれます。

フレックス・ファミリのキー・メンバーはフレックス・アセットです。フレックス・アセットは、データベースから抽出してオンライン・サイト(配信システム)の訪問者に表示するデータの単位です。ファミリ内の他のメンバーのすべては、なんらかの点でフレックス・アセット・メンバーの一部となります。

フレックス・アセットがキーであるのに対し、属性はフレックス・アセット・モデルの基盤です。属性は情報の個々のコンポーネントです。たとえば、色、高さ、作成者、ヘッドラインなどがあります。属性は、フレックス・アセットおよびフレックス親の定義に使用します。フレックス・アセットは親から属性値を継承し、親はその親から属性値を継承する、となります。

どの属性がどのフレックス・アセットおよびフレックス親を記述するかを決定するには、フレックス定義およびフレックス親定義のアセット・タイプを使用してテンプレートを作成します。フレックス親とその定義によって、属性値の継承が実装されます。

フレックス親もフレックス・アセットも、2つのタイプの属性で定義することはできません。GEサンプル・サイトには、製品属性およびコンテンツ属性という2種類の属性があります。製品アセット(製品フレックス・ファミリのフレックス・アセット・メンバー)は製品属性のみで定義できます。その定義にコンテンツ属性を含めることはできません。

フレックス・フィルタによって、属性値に対してなんらかのアクションを実行し、フレックス・アセットの保存時にアクションの結果を保存するように構成できます。たとえば、WordファイルのテキストをHTMLコードに変換するフィルタを構成できます。

要するに、フレックス・ファミリのフレックス・アセット・メンバーはファミリの理由であり、表示するコンテンツの単位です。フレックス・ファミリのその他のメンバーはフレックス・アセットのデータ構造を提供します。ただし、ファミリのメンバーはすべてアセットであるため、リビジョン追跡、ワークフロー、検索など、WebCenter Sitesの標準機能が利用できます。

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

フレックス・アセット・データ・モデルを使用している場合、親子関係という語句は、フレックス・アセットとそのフレックス親アセットの関係を指します。この親子関係は、ベーシック・アセットがアセット・アソシエーションを通して得る親子関係とは異なります。

フレックス・アセットがベーシック・アセットと同種の親子関係を持つことは可能ですが、次の理由により、現実に行われるとは考えられません。

- WebCenter Sitesにはタグ・ファミリASSETSETおよびSEARCHSTATEがあり、表示するフレックス・アセットを選択する場合は、コレクション・アセット・タイプおよび問合せアセット・タイプのかわりに使用します。このタグ・ファミリの詳細は、第11.4項「assetsetおよびsearchstate」を参照してください。

- フレックス・アセットはアソシエーションを必要としません。たとえば、製品などのフレックス・アセットにイメージ・ファイルを割り当てる場合、イメージ・ファイルを特定する属性を作成して、それをフレックス・アセットの定義に割り当てることができます。

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

開発システムにGEサンプル・サイトをインストールしている場合は、調査可能な2つのフレックス・アセット・ファミリとして製品ファミリおよびコンテンツ・ファミリがあります。

サンプル・フレックス・アセット・タイプの次の説明を理解しやすくするためにこの項をお読みになる際には、WebCenter Sitesインタフェースの製品アセット、記事アセット、イメージ・アセットをいくつか調査してください。

11.3.2.1 製品ファミリ

製品ファミリには、GE Lightingサンプル・サイトから販売される照明製品のデータ構造が用意されています。これによって、照明製品のオンライン・カタログが作成されます。

次に、製品ファミリのアセット・タイプを示します。

- 製品属性は、GE Lightingサンプル・カタログで製品および製品親の定義に使用するフレックス属性アセット・タイプです。たとえば、ワット数、電圧、電球サイズ、安定器タイプなどの製品属性があります。

- 製品は、製品ファミリのフレックス・アセット・メンバーです。製品アセットは、GE Lightingサンプル・サイトから販売される照明製品を表現します。このオンライン・カタログでは、製品名はSKU番号と同様の番号で表されます。

- 製品定義は、製品ファミリのフレックス定義アセット・タイプです。これは、製品の1つのサブタイプ、ここでは照明の作成に使用します。照明の定義によって、このオンライン・カタログのすべての電球が書式設定(定義)されます。

- 製品親は、製品ファミリのフレックス親アセット・タイプです。製品親は、Compact Fluorescent、fluorescent、Halogenなどの製品のカテゴリを表します。

- 製品親定義は、製品ファミリのフレックス親定義アセット・タイプです。これは、製品親のサブタイプの作成に使用します。カテゴリおよびサブカテゴリという2つのサブタイプがあります。

製品属性、製品定義、製品親定義の各アセットはデータ・デザインに使用するため、「デザイン」タブに一覧表示されます。製品と製品親の各アセットは、サンプル・サイトの「製品」タブに表示されます。

製品アセットは、GE Lightingサンプル・サイトで製品を販売するという製品ファミリの理由です。

11.3.2.2 コンテンツ・ファミリ

コンテンツ・ファミリには、GE Lightingサンプル・サイトから販売される製品を記述する記事と、製品を描画するイメージのデータ構造が用意されています。

次に、コンテンツ・ファミリを示します。

- コンテンツ属性は、GE Lightingサンプル・サイトから販売される製品の記事(フレックス)およびイメージ(フレックス)の定義に使用するフレックス属性アセット・タイプです。

- 記事(フレックス)は、記事のテキストと関連情報を格納するフレックス・アセット・タイプです。署名行、ヘッドライン、サブヘッドライン、本文などの属性があります。

- イメージ(フレックス)は、イメージ・ファイルのURLを格納するフレックス・アセット・タイプです。このアセット・タイプはGE Lightingで使用可能とされていますが、実際には使用されません。

- コンテンツ定義は、コンテンツ・ファミリのフレックス定義アセット・タイプです。これは、ストーリーと呼ばれる、記事(フレックス)アセット・タイプの1つのサブタイプの作成に使用します。

- コンテンツ親は、コンテンツ・ファミリのフレックス親アセット・タイプです。このアセット・タイプはGE Lightingで使用可能とされていますが、実際には使用されません。

- コンテンツ親定義は、コンテンツ・ファミリのフレックス親定義アセット・タイプです。このアセット・タイプはGE Lightingで使用可能とされていますが、実際には使用されません。

GEサンプル・サイトのコンテンツ・ファミリには2つのフレックス・アセット・タイプがあります。これらは、属性、親、定義および親定義を共有します。

コンテンツ属性、コンテンツ定義、コンテンツの親定義の各アセットはデータ・デザインに使用するため、「デザイン」タブに一覧表示されます。イメージ(フレックス)、記事(フレックス)、コンテンツの親の各アセットは、サンプル・サイトの「コンテンツ」タブに表示されます。

11.3.3 フレックス属性

フレックス属性はフレックス・アセット・モデルの基盤です。属性は、情報の1単位を表します。属性アセットは、フレックス・アセットおよびフレックス親の定義に使用します。これらは、フレックス・アセットおよびその親に対して、「新規」フォームおよび「編集」フォームでフィールドとして表示されます。

属性は、ベーシック・アセットのプロパティに似ています。プロパティと同様に、属性はWebCenter Sitesデータベース表の列に格納できるデータの種類を定義し、フォーム内のフィールドを記述します。ただし、プロパティがアセット・タイプのデータベース表に列を定義するのに対し、属性は専用のデータベース表を持つアセットです。

このデータ構造(列としてではなく、アセットとしての属性)は、フレックス・アセットの柔軟性が高い理由の1つです。

繰り返しますが、フレックス親もフレックス・アセットも、2つのタイプの属性で定義することはできません。たとえば、GE Lightingサンプル・サイトの製品アセットは製品属性のみで定義できますが、その定義にコンテンツ属性を含めることはできません。

注意:

フレックス属性をフレックス定義から削除する場合、これらの属性によって格納されたデータはデータベースから削除されないことに注意してください(このデータは問合せによって引き続き返されます)。

11.3.3.1 属性のデータ型

属性のデータ型は、futuretense.iniファイルに配置されているWebCenter Sitesデータベースのプロパティによって定義されます。ただし、例外として、moneyデータ型はgator.iniファイル(.iniファイルの名前)のプロパティによって定義されます。

表11-3に、フレックス属性のデータ型、データ型を定義するプロパティ、およびプロパティが配置されているファイルを一覧表示します。

表11-3 フレックス属性のデータ型

型

プロパティ

.iniファイル

date

cc.datetime

futuretense.ini

float

cc.double

futuretense.ini

integer

cc.integer

futuretense.ini

money

cc.money

gator.ini

string

cc.varchar

futuretense.ini

text

cc.bigtext

futuretense.ini

asset

cc.bigint

futuretense.ini

blob

cc.bigint

futuretense.ini

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

フレックス属性は、「新規」フォームまたは「編集」フォームにフィールドとして表示されるときに、そのデータ型に基づいたデフォルトの入力スタイルが設定されます。次のリストに、フレックス属性のデフォルトの入力スタイルを示します。

- Date: 次のように表示される入力ボックス。

- Float: 小数部の桁を強制表示したテキスト・フィールド。

- Integer: テキスト・フィールド。

- Money: 通貨フォーマットを強制表示したテキスト・フィールド。

- String: 最大255文字を受け入れるテキスト・フィールド。

- Text: テキスト・ボックス。受け入れられる文字数は、使用しているデータベースおよびデータベース・ドライバによって異なります。

- Asset: 指定されたタイプの全アセットを示したドロップダウン・リスト。

- Blob: 「参照」ボタンが設定されたテキスト・フィールド。

フレックス属性にデフォルトの入力スタイルを使用しない場合は、属性エディタを作成して、それを属性に割り当てることができます。属性エディタはアセットですが、属性フィールドへのデータ入力方法を指定するという点で、ベーシック・アセットに対するアセット記述子ファイル内のINPUTFORM文にも似ています。属性エディタの詳細は、第18章「属性エディタの設計」を参照してください。

11.3.3.3 外部属性

外部表に格納されるフレックス属性、つまり外部属性を設定できます。外部属性は、次の制約を受けます。

- 外部表をWebCenter Sitesで登録する必要があります。つまり、外部表はSystemInfo表でWebCenter Sitesに対して識別される必要があります。詳細は、第12.3.4項「外部表の登録」を参照してください。

- 外部表には、各行を一意に識別する識別子が保持される列を設定する必要があります。識別子は20文字未満とします。

- 外部表には、任意の適切なデータ型が使用可能な属性データ値用に予約された列を設定する必要があります。たとえば、属性の型がstringの場合は、文字列に適切なデータ型を使用する必要があります。

11.3.4 フレックス親とフレックス親定義

フレックス親とそのフレックス親定義は編成構造であり、次の2つのアクションを実行します。

- 属性値の継承を実装します。親定義は継承ルールを設定(記述)し、親はこれらの継承ルールに従って属性値をフレックス・アセットに渡します。

- WebCenter Sitesインタフェースでアセットを表示するタブにおけるフレックス・アセットの位置を決定します。タブ上にツリー形式で表示される親とフレックス・アセットの階層は、親定義を使って設定された階層に基づきます。

それぞれの親アセット・タイプには、親定義で指定されたように、専用の属性セットがあります。親定義によって、WebCenter Sitesインタフェースに表示されるフォームが作成されます。

親を使用してフレックス・アセットを編成または管理するには、親の子アセットごとに変更する必要のない標準の属性値を渡します。

親アセット・タイプは、WebCenter Sitesインタフェース内で、開発者やコンテンツ・プロバイダがデータを表示する方法と、データと対話する方法に影響します。

たとえば、GE Lightingサンプル・サイトには、カテゴリおよびサブカテゴリという2つの親定義があります。これらは、(WebCenter Sitesインタフェース内の)ツリーでサンプル・サイトの「製品」タブに構造体を作成することのみを目的としています。

GE Lightingサイトでは、製品親の定義がカテゴリの場合、製品親は「製品」タブの最上位レベルに表示されます。製品親の定義がサブカテゴリの場合、製品親は第2レベルに表示され、専用の親が指定されます。

たとえば、GEサンプル・サイトには、Compact Fluorescent、Halogenなど、最上位レベルの製品親が複数あります。これらはカテゴリ定義を使用して作成されています。Double BIAX and 2-Pin、Double BIAX and 4-pinなどの次レベルの製品親は、サブカテゴリ定義を使用して作成されています。

11.3.4.1 ビジネス・ルールと分類

親定義および親アセットの目的は、データの分類を表現することのみでなく、エンド・ユーザーによる入力エラーのリスクなしで、ビジネス・ルール(ロジック)を適用できるようにすることです。特定の定義のフレックス・アセットを作成することによって、継承する必要のある依存性が存在する場合、そのフレックス・アセットには親を設定する必要があります。

たとえば、次の5つの属性を持つトースタという単純な製品があるとします。

- SKU = 1234

- 説明 = トースタ

- 価格 = 20

- CAT1 = キッチン

- CAT2 = 電化製品

CAT2の値が「電化製品」の場合、CAT1の値には「キッチン」のみを指定できます。つまり、CAT1の値とCAT2の値の間にはビジネス・ルールの依存性が存在します。

このような場合、コンテンツ・プロバイダは両方のフィールドを入力する必要はありません。データを手動入力しなければならないフィールドはすべて、入力エラーによって不正なデータが保持される可能性があるため、継承を使用してビジネス・ルールを適用することをお薦めします。

- CAT1とCAT2を親定義にします。

- キッチンをCAT1の定義で作成された親にして、電化製品をCAT2の定義で作成された親にします。

- キッチンを電化製品のフレックス親にします。

コンテンツ・プロバイダが製品を作成するときに、CAT2に対して電化製品を選択した場合、CAT1の値は継承によって自動的に設定されます。

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

フレックス・アセットは、フレックス・ファミリの理由です。これは、製品、表示されるコンテンツの一部など、最終目標を表すアセット・タイプです。たとえば、GEサンプル・サイトには次の3つのフレックス・アセット・タイプがあります。

- 製品: 個々の販売可能な単位を表します

- 記事(フレックス): テキストを保持するアセット

- イメージ(フレックス): 画像ファイルのURLを保持するアセット

ファミリ内の他のメンバーのすべては、なんらかの点でフレックス・アセット・メンバーの一部となります。

フレックス定義アセットは、靴、トースタ、ボーリングのボール、パンフレット、ニュースレター、記事など、フレックス・ファミリ内で1種類のフレックス・アセットを記述します。フレックス定義アセットは、WebCenter Sitesインタフェースで表示されるフォームに直接影響するテンプレートです。

GEサンプル・サイトでは、製品(照明)のフレックス定義が1つだけ、記事とイメージのフレックス定義が1つだけですが、フレックス定義は必要に応じていくつでも作成できます。

たとえば、トースタとリネンの両方を提供する製品カタログを設計している場合は、トースタ用にフレックス定義アセットを作成し、リネン用に別のフレックス定義アセットを作成します。

個々のフレックス・アセットは、1つのフレックス定義アセットのみに従って作成します。トースタ定義とリネン定義の両方を使用した製品を作成することはできません。

フレックス・アセットには、作成時に直接割り当てられた属性のみでなく、親から継承する属性も割り当てられます。フレックス・アセットには複数のフレックス親を割り当てることができ、親に親があるかどうかは設計した階層構造によって異なります。たとえば、GEサンプル・サイトの製品には、次のように3レベルの階層があります。

Other Compact Fluorescent製品親には専用の親(Compact Fluorescent)と複数の子(10576、10578など)が割り当てられています。

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

フレックス・ファミリ内のアセット・タイプには、それぞれ複数のデータベース表があります。たとえば、フレックス・アセット・メンバーには6つの表、フレックス親タイプには5つの表があります。このデータ・モデルでは、フレックス・ファミリ内のフレックス・メンバーは、ベーシック・アセット・モデルの場合よりも多くのフィールドをサポートできます。

フレックス・モデルで最も重要な4つの表のタイプは次のとおりです。

- アセット・タイプのプライマリ表

- _Mungo表: フレックス・アセットおよびフレックス親アセットのみの属性値を保持します。

- MungoBlobs表: BLOB型のすべてのフレックス属性の値を保持します。

- _AMap表: フレックス・アセットおよびフレックス親のみの属性値の継承に関する情報を保持します。

その他にも複数の表があり、これらの表にはフレックス・アセット間の関係に関する基礎データだけでなく、追加の構成情報(検索エンジンの詳細、外部属性の場所、パブリッシュ情報、リビジョン追跡が有効になっている場合はバージョン情報)も格納されています。

さらに、特定の種類のサイト情報は、ベーシック・アセットで使用される表と同じ表に保持されます。たとえば、AssetPublication表では、アセット・タイプが有効化されているコンテンツ管理サイトを指定します。

コンテンツを表すフレックス・アセットを表示するテンプレートを開発する場合、_Mungo表およびMungoBlobs表から情報を抽出して表示するエレメントをコーディングします。

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

ベーシック・アセット・タイプと同様に、各フレックス・アセット・タイプには、アセット・タイプの名前を採用したプライマリ記憶域表があります。たとえば、GEサンプル・サイトで、製品という名前のアセット・タイプのプライマリ表はProductsとなります。製品属性アセット・タイプのプライマリ表はPAttributesとなります。

ベーシック・アセット・タイプのプライマリ表と異なり、フレックス・アセット・タイプのプライマリ表には、デフォルトの列のみが設定されます。これは、属性値を持つフレックス・アセット・タイプが、属性値をプライマリ表に格納しないためです。属性値は、このアセット・タイプの_Mungo表に格納されます。

一般的に、フレックス・アセット・タイプに対するプライマリ表のデフォルトの列タイプは、ベーシック・アセット・タイプに対するプライマリ記憶域表のデフォルトの列と同じです。デフォルトの列タイプの全般的なリストは、第11.2.4.2項「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

ただし、次の表に示すように、例外や追加事項は当然ながら存在します。

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

列

説明

category

カテゴリはフレックス・アセット・モデルでは使用されないため、フレックス・アセット・タイプのプライマリ表にはcategory列は存在しません。

フレックス・アセットに対する問合せがそのフレックス属性の値に基づいているため、フレックス・アセットはカテゴリ機能を必要としません。

テンプレート

この列では、製品、記事(フレックス)、イメージ(フレックス)などのフレックス・ファミリ内のフレックス・アセット・メンバーに対する表のみに値が保持されます。これは、ファミリ内のフレックス・アセット・メンバーのみにテンプレート・アセットを割り当てて、オンライン・サイトで表示できるためです。

renderid

フレックス・アセットに割り当てられたテンプレート・アセットのオブジェクトIDを保持します。

attributetype

フレックス属性タイプに対するプライマリ表の追加列です。属性が「新規」フォームおよび「編集」フォームに表示されるときに、その属性の入力スタイルを書式設定する属性エディタの名前を保持します(属性エディタが存在する場合)。

flextemplateid

フレックス・アセット・タイプ(フレックス・ファミリのフレックス・アセット・メンバー)に対するプライマリ表の追加列です。フレックス・アセットの作成に使用したフレックス定義のIDを保持します。

flexgrouptemplateid

フレックス親アセット・タイプに対するプライマリ表の追加列です。フレックス親アセットの作成に使用した親定義のオブジェクトIDを保持します。

11.3.6.2 _Mungo表

フレックス・アセット・タイプおよびフレックス親アセット・タイプには、AssetType_Mungo表があります。この場合、AssetTypeはフレックス・アセット・タイプの名前です(また、メイン記憶域表の名前と一致します)。その目的は、アセットの作成時にそのタイプのアセットに割り当てられた属性値を格納することです。たとえば、GEサンプル・サイト表のProducts_Mungoには、製品アセットの属性値が保持されています。

各属性値には、別々の行が割り当てられます。

_Mungo表の各行には、次の各列の値が表示されます。

表11-5 _Mungo表の行

列

説明

id

フレックス・アセットが保存され、行が作成されたときに、WebCenter Sitesによって自動生成される、各属性値の一意のID。

これは、表の主キーです。

ownerid

属性値が属するフレックス・アセットのID。(フレックス・アセットの表、たとえばProductのもの。)

attrid

属性のID。(属性の表、たとえばPAttributesのもの。)

assetgroupid

属性値が継承された場合は、値を渡した親のID。(親の表、たとえばProductGroupsのもの。)

_Mungo表の各行には次の列もすべて含まれますが、値(データ)は属性のデータ型に応じて1つの列のみに指定されます。

表11-6 _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列があるため(第12.2.3項「WebCenter SitesのURLフィールドを使用した間接的なデータ格納」を参照)、その列に対してデフォルトのストレージ・ディレクトリ(defdir)を設定する必要があります。_Mungo表に対してdefdirを設定するには、gator.iniファイルのcc.urlattrpathプロパティを使用します。

11.3.6.3 MungoBlobs表

MungoBlobs表が1つ存在します。これには、システム内のすべてのフレックス属性タイプに対して、blob型のすべてのフレックス属性の値が保持されています。各属性値には、表の別々の行が割り当てられます。

11.3.6.4 _AMap表

フレックス・アセット・タイプおよびフレックス親アセット・タイプには、AssetType_AMap表があります。その目的は、親から継承した属性にアセットをマップすることです。これにより、オンライン・サイトのページにアセットを表示するテンプレートを作成するときに、属性が継承されたか直接割り当てられたかどうかに関係なく、属性のいずれかに基づいてアセットを問い合せたり、それらの属性のいずれかを表示できます。

_AMap表では、継承された属性の値を持つフレックス・アセットごとに行が1つ割り当てられます。(ただし、属性が複数の値を持っている場合、_Mungo表では値ごとに行が1つ割り当てられます。)

_AMap表には次の列が割り当てられます。

表11-7 _AMap表の列

列

説明

id

フレックス・アセットが保存され、行が作成されたときに、WebCenter Sitesによって自動生成される、各行の一意のID。これは、表の主キーです。

inherited

属性が継承された場合は、その継承元である親のID。(親の表、たとえばProductGroupsのもの。)

attributeid

属性のID。(属性の表、たとえばPAttributesのもの。)

ownerid

属性値が属するフレックス・アセットのID。(フレックス・アセットの表、たとえばProductのもの。)

11.4 assetsetおよびsearchstate

WebCenter Sitesには、オンライン・ページに表示する個々のフレックス・アセットを識別するために、メソッド・ファミリASSETSETおよびSEARCHSTATEがあります。

assetset

assetsetはフレックス・アセットまたはフレックス親アセットのみのグループであり、フレックス属性、フレックス定義またはフレックス親定義は含まれません。たとえば、GEサンプル・サイトでは、製品、記事(詳細)またはイメージ(詳細)を含めたassetsetを作成できます。サイト・ページのコーディング時には、assetsetを作成して、その中にアセットを表示する文をコーディングします。

searchstate

フレックス・アセットのテンプレートでSEARCHSTATEメソッド・ファミリを使用して、assetsetに含める必要のあるフレックス・アセットを特定します。searchstateは、フレックス・アセットのリストまたはセットに適用される検索絞込み条件のセットです。絞込み条件として、属性値または別のsearchstate(ネストされたsearchstate)のいずれかに基づいたフィルタ(制限)を使用できます。

searchstateは、データベース内の_Mungo表でも、検索エンジンで作成された属性索引のいずれでも検索できます。つまり、データベース検索とリッチテキスト(索引を通じたフルテキスト)検索を同じ問合せ内に混在させることができます。

これらのタグは、_Mungo表または属性索引のみでフレックス・アセット・タイプを検索するため、これらのタグを使用してフレックス・アセットを抽出することは、ASSETタグまたは問合せアセットを使用するよりもはるかに効率的です。

assetsetと属性アセット・タイプ

WebCenter Sitesでは、属性アセット・タイプ全体の検索は実行できません。assetsetは属性値に基づいて作成されるため、同じassetsetに含められるのは同じ属性アセット・タイプを共有するアセットのみです。これは、フレックス・ファミリの設計する際の重要な考慮点です。共通の属性アセット・タイプを共有しないフレックス・アセット・タイプを作成する場合は、データを分離して、異なるタイプのアセットが共通assetsetに含まれないようにする必要があります。また、assetsetを表示することは、配信システム上でフレックス・アセットを表示するためのメカニズムです。

たとえば、同じフレックス・ファミリに2つのタイプのフレックス・アセットを持つことができます。これらのフレックス・アセットが同じタイプの属性を使用するかぎり、両方のタイプのアセットを含むassetsetを作成できます。ただし、2つのタイプのフレックス・アセットにわたって検索すると、それぞれの_Mungo表の間に結合が生じるため、パフォーマンスが低下する可能性があることに留意してください。

GEサンプル・サイトには、記事(詳細)およびイメージ(詳細)という2つのフレックス・アセット・タイプがあります。これらは、同じ属性アセット・タイプ(コンテンツ属性)と同じ定義(コンテンツ定義およびコンテンツ親定義)を共有します。ただし、これは共有の属性アセット・タイプであるため、2つの異なるフレックス・アセット・タイプの場合であっても、同じassetsetに含めることができます。

ただし、記事とイメージはGE製品アセット・タイプと属性アセット・タイプを共有しないため、製品と記事を含めたassetsetは作成できません。

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

この2つのアセット・モデルのデータ構造は非常に異なるため、アセット・モデルが検索エンジンと対話する方法も大きく異なります。

- ベーシック・アセット・タイプはアセット記述子ファイルによって定義され、そのプライマリ記憶域表にはすべてのプロパティが列として含まれます。ベーシック・アセット・タイプで索引付けするフィールドを指定するには、そのアセット・タイプの特定のエレメントをカスタマイズする必要があります。第15章「ベーシック・アセット・タイプの設計」を参照してください。

- フレックス・アセットのフィールドはフレックス属性であり、これはアセットであるため、リッチテキスト検索に対してどのフィールドを索引付けするかを、属性別に決定します。また、WebCenter Sitesアプリケーションでは、属性の「新規」フォームと「編集」フォームで「検索エンジン」フィールドを使用してどの属性を索引付けするかを指定できます。この機能を有効化するためにエレメントをカスタマイズする必要はありません。

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

アセットの作成と管理の最終目標は、アセットを配信システムに移動して、配信システム上でエレメントに組み込んだコードによってアセットをデータベースから抽出し、それをサイトの訪問者に表示することです。WebCenter Sitesアプリケーションは、様々なツールセット(カスタム・タグ・セット)をXMLとJSPの両方で提供しています。

テンプレート内でデータベースからのアセット抽出に使用するツールセットは、使用しているアセットの種類によって異なります。

- ベーシック・アセット・モデルのあるアセットには、ASSETメソッド・ファミリを使用します。

- フレックス・ファミリ内のフレックス・アセット・メンバーには、ASSETSETおよびSEARCHSTATEのメソッド・ファミリを使用します。フレックス・ファミリ内のフレックス・アセット・メンバー(製品、記事、イメージなど)には、ASSET.LOADタグを使用しないでください。フレックス・アセットに対してASSET.LOADタグを使用すると、アセットのすべての表からそのアセットに関する全情報を取得するため、効率がきわめて悪くなります。SEARCHSTATEメソッドは、フレックス・アセットのアセット・タイプに対する_Mungo表とMungoBlobs表のみを問い合せます。

- 推奨アセットには、COMMERCECONTEXTメソッド・ファミリを使用します。

これらの製品ではさらに多くのメソッド・ファミリが使用できるだけでなく、WebCenter Sitesおよび複数のAPIからも多数のカスタム・タグが使用できます。

すべてのタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

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

この項では、この2つのアセット・モデルの類似点と相違点を要約します。

アセット・モデルの共通点

ベーシック・アセット・モデルとフレックス・アセット・モデルの機能方法には多くの相違点がありますが、いくつかの共通点も見られます。

- ベーシックとフレックスどちらのアセット・モデルを使用する場合でも、WebCenter Sitesアプリケーションに付属しているテンプレート・アセット・タイプとページ・アセット・タイプを使用します。

- すべてのアセット・タイプにはステータス・コードが割り当てられています。つまり、フレックスかベーシックかに関係なく、すべてのアセットはステータスに基づく問合せを使用して検索できます。

- すべてのアセット・タイプは、フレックスかベーシックかに関係なく、次の構成または管理特性を共通して備えています。

- サイト別に有効化する必要があります。

- これらのタイプの個々のインスタンスを作成できるようにするには、スタート・メニュー・アイテムをあらかじめ構成しておく必要があります。

- 個々のインスタンスはXMLPostユーティリティを使用してインポートできます。

アセット・モデルの相違点

次の表に、これらのアセット・モデルの主な相違点を要約します。

表11-8 アセット・モデルの主な相違点

機能

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

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

データベース表の数

1つ

複数

アセット・タイプへのフィールドの追加

スキーマ変更が必要です。

スキーマ変更は必要ありません。

他のアセットへのリンク

アソシエーションと名前なし関係を使用します。

フレックス・ファミリの関係を使用します。

サブタイプ

通常は「管理」タブの「サブタイプ」アイテムを使用します。サブタイプの設定方法の詳細は、第11.2.3.3項「サブタイプ」を参照してください。

フレックス定義とフレックス親定義を使用します。

検索エンジンの索引付け

アセット・タイプの特定のエレメントをカスタマイズする必要があります。

フレックス属性フォームで「検索エンジン」フィールドを使用します。

主なタグ・ファミリ

ASSET、SITEPLANおよびRENDER

ASSETSET、SEARCHSTATEおよびRENDER

パブリッシュ方法

ディスクにエクスポート

サーバーへのミラーリング

「サーバーにエクスポート」も使用できますが、フレックス・モデルには標準ではありません。

サーバーへのミラーリング

11.8 要約: アセット・タイプ

次の表に、WebCenter Sitesのモジュール、製品およびサンプル・サイトに付属しているアセット・タイプをすべて一覧表示します。

表11-9 アセット・タイプ

アセット・タイプの名前

製品またはサンプル・サイト

ページ

WebCenter Sites

テンプレート

WebCenter Sites

コレクション

WebCenter Sites

問合せ

WebCenter Sites

CSElement

WebCenter Sites

SiteEntry

WebCenter Sites

リンク

WebCenter Sites

記事

WebCenter Sites、Burlington Financial

イメージ・ファイル

WebCenter Sites、Burlington Financial

スタイルシート

WebCenter Sites、Burlington Financial

リンクセット

WebCenter Sites、Burlington Financial(後方互換性のためのみ)

イメージ

WebCenter Sites、Burlington Financial(後方互換性のためのみ)

HelloArticle

WebCenter Sites、HelloAssetWorld

HelloImage

WebCenter Sites、HelloAssetWorld

属性エディタ

WebCenter Sites

製品

WebCenter Sites、GE Lighting

製品属性

WebCenter Sites、GE Lighting

製品定義

WebCenter Sites、GE Lighting

製品親

WebCenter Sites、GE Lighting

製品親定義

WebCenter Sites、GE Lighting

記事(フレックス)

WebCenter Sites、GE Lighting

イメージ(フレックス)

WebCenter Sites、GE Lighting

コンテンツ属性

WebCenter Sites、GE Lighting

コンテンツ定義

WebCenter Sites、GE Lighting

コンテンツ親

WebCenter Sites、GE Lighting

コンテンツ親定義

WebCenter Sites、GE Lighting

訪問者属性

Engage

履歴属性

Engage

履歴定義

Engage

セグメント

Engage

推奨

Engage

プロモーション

Engage

DrillHierarchy

Engage、Burlington Financial Extension

PDF

Engage、Burlington Financial Extension

12 WebCenter Sitesデータベース

WebCenter Sites、そのモジュールおよびWebCenter Sites製品のほぼすべては、データベース表に行として表されます。

この章では、WebCenter Sitesデータベースにおける各種の表および列について説明し、表を作成するための手順を示します。WebCenter Sitesのモジュールおよび製品(たとえばEngage)には、必要な表のほとんどが用意されています。ただし、WebCenter Sitesを使用して独自のアプリケーションを開発している場合、またはアセットを保持しない表(たとえば参照表)を使用する必要がある場合は、この章で説明する方法のいずれかを使用して表を作成します。

この章には次の項が含まれます。

- 第12.1項「データベース表のタイプ」

- 第12.2項「列(フィールド)のタイプ」

- 第12.3項「データベース表の作成」

- 第12.4項「情報はシステム表にどのように追加されるか」

- 第12.5項「プロパティ・ファイルとデータベース」

アセットを保持しない表におけるデータの管理については、第13章「アセットを保持しない表内のデータ管理」を参照してください。

注意:

WebCenter Sitesのデータベース表は、以前はカタログと呼ばれており、アプリケーション全体を通じて、表の名前、サーブレットの名前(CatalogManager)、データベース内のデータを操作する際に使用するJavaインタフェースにこの用語がまだ残っています。

12.1 データベース表のタイプ

WebCenter Sitesデータベースには、次の5つのタイプの表があります。

- オブジェクト表: データをオブジェクトとして保持し、表の各行に一意のIDを自動的に提供します

- ツリー表: オブジェクト表の中のオブジェクト間の関係についての階層情報を保持します

- コンテンツ表: 水平データを保持しますが、各行に一意のIDを提供することはありません

- 外部表: 次のいずれかとなります。

- WebCenter Sitesデータベースの外側にあるが、そのWebCenter Sitesからアクセスできる表。

- WebCenter Sitesデータベースの中にあるが、そのWebCenter Sitesが作成したのではない表。

- システム表: WebCenter Sitesのコア・アプリケーションの表で、そのスキーマを変更できないもの

WebCenter Sitesは、外部表を含めたWebCenter Sitesデータベースの任意の表に対する問合せから、結果セットをキャッシュできます。

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

- 第12.1.1項「オブジェクト表」

- 第12.1.2項「ツリー表」

- 第12.1.3項「コンテンツ表」

- 第12.1.4項「外部表」

- 第12.1.5項「システム表」

- 第12.1.6項「表のタイプの特定」

12.1.1 オブジェクト表

オブジェクト表は、データをオブジェクトとして格納するもので、階層で表すことができます。これらのオブジェクトのロード、保存および管理には、CatalogManager APIを使用できます。アセット・タイプの表はオブジェクト表です。

オブジェクト表の主キーは常にID (id)列で変更できません。オブジェクト表を追加するようにWebCenter Sitesに指示すると、その表にID列が作成されます。IDは、表に行が追加されるにつれて、WebCenter Sitesがデフォルトで各行に割り当てる一意の識別子です。たとえば、だれかが新しいアセットを作成すると、WebCenter SitesではIDが決定され、そのアセットのIDとしてその値が割り当てられます。

(アセットなどの)オブジェクトにWebCenter Sitesが割り当てるIDは変更できません。

注意:

AssetMakerまたはフレックス・ファミリ・メーカーで新しいアセット・タイプのオブジェクト表を作成するときには、デフォルトで追加の列がいくつか作成されます。ベーシック・アセット表内のデフォルトの列については、第11.2.4.2項「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

データを格納する必要があり、そのデータの各行が一意に識別されるようにする場合は必ず、オブジェクト表を使用してください。それは、IDの生成はWebCenter Sitesが処理してくれるからです。

オブジェクト表(カタログ)の例

- アセットを保持するすべての表

- パブリッシュ表の多く

- 訪問者のデータを保持するEngageの表

12.1.2 ツリー表

ツリー表には、オブジェクト表間の階層関係についての情報が格納されます。言い換えれば、オブジェクト表は階層で表すことができますが、その階層自体はツリー表に格納されます。つまり、階層がツリーであるということです。

たとえば、WebCenter Sitesでは、WebCenter Sitesデータベースに次の表が追加されます。

- AssetRelationTree: アセット間のアソシエーションについての情報を格納します。これらのアソシエーションによって親子関係が作成されます。アセットのアソシエーションの詳細は、第11.3項「フレックス・アセット・モデル」を参照してください。

- SitePlanTree: ページ・アセットとそれらのアセットから参照されるアセットの間の親子関係についての情報を格納します。この情報は、WebCenter Sitesのインタフェースに提示される「サイト・プラン」タブにグラフィカルに提示されます。

ツリー表の各行は、そのツリーのノードです。ツリー表の各ノードは、次の2つの場所を指しています。

- オブジェクト表内のオブジェクト、つまりオブジェクト表が表すオブジェクト

- そのツリー表の中の親ノード、ただし最上位のノードで親がない場合は除く

言い換えれば、オブジェクト自体はオブジェクト表に格納されます。オブジェクトとデータベース内の他のオブジェクトとの関係(ツリーで記述)は、ツリー上のノードとしてツリー表に格納されます。

子ノードは親ノードを指しますが、親は子を指さないことに注意してください。

ツリー表を作成すると、デフォルトで次の列が設定されます。これらの列に対しては、追加も変更もできません。

表12-1 デフォルトの列

列

説明

nid

ノードのID。これが主キーです。

nparentid

ノードの親ノードのID。

nrank

対等なノードまたは兄弟関係にあるノードをランク付けした数字。たとえば、AssetRelationTree表はこの列を使用して、コレクションの中にあるアセットの順序を決定します。

otype

ノードのオブジェクト・タイプ。たとえば、SitePlanTree表では、otypeは、ページというアセット・タイプ、またはサイトの名前(パブリケーション)です。AssetRelationTree表では、otypeはアセット・タイプであり、そのタイプのアセットのオブジェクト表の名前です。

oid

ノードが参照するオブジェクトのID。

oversion

将来の使用に備えて予約されています。

ncode

表の用途というコンテキストで、意味のある文字列を保持します。たとえば、SitePlanTreeでは、ノードが参照するページ・アセットが配置されているかどうかに基づいて、ncodeが「placed」と「unplaced」のいずれかに設定されます。AssetRelationTreeでは、ncodeにアソシエーションの名前が保持されます。

12.1.3 コンテンツ表

コンテンツ表には、データが(オブジェクトでなく)水平データとして格納され、その情報は階層に編成できません。コンテンツ表は、簡易参照表として使用します。たとえば、次に示すのは、WebCenter Sitesデータベースに追加するコンテンツ表のほんの一部です。

- Source: 記事またはイメージのアセットのソースを特定するために使用される文字列を格納します

- Category: 様々な方法でアセットを編成するために使用されるコードを保持します

- StatusCode: アセットのステータスを表すコードを保持します

これら3つの表はすべて、アセット・タイプ表(オブジェクト表)の様々な列の値を参照するために製品で使用される参照表です。

別の例では、WebCenter Sitesは、MimeTypeというコンテンツ表も追加します。この表には、Burlington Financialサンプル・サイトの、スタイルシートおよびイメージファイルというアセット・タイプの「Mimetype」フィールドに表示されるMIMEタイプ・コードが保持されます。これらのアセット・タイプの「Mimetype」フィールドは、MimeType表に対し、その表のkeyword列に基づいて、MIMEタイプ・コードを問い合せます。

コンテンツ表の主キーの設定

コンテンツ表を作成したときには、ID列は作成されず、主キーがIDである必要もありません。これも、コンテンツ表とオブジェクト表の大きな違いです。

futuretense.iniファイルのcc.contentkeyプロパティは、すべてのコンテンツ表のデフォルトの主キーの名前を指定しています。コンテンツ表を新規作成するときには、cc.contentkeyプロパティで指定された名前の列を定義する責任があります。

ただし、特定のコンテンツ表の主キーのIDは、futuretense.iniファイル内にカスタム・プロパティを追加および設定することによってオーバーライドできます。このプロパティは、次のフォーマットを使用する必要があります。

cc.tablenameKey

たとえば、Booksというコンテンツ表を作成し、デフォルトの主キーをオーバーライドして、かわりにISBN列を使用するようにする場合は、cc.BooksKeyというプロパティを追加してISBNに設定します。

12.1.4 外部表

外部表とは、WebCenter Sitesで全面的に管理しているわけではない表です。たとえば、サイト・ページでは、ERPシステムで移入される表に対して問合せが実行され、WebCenter Sitesでは、その情報がサイトの訪問者に表示されると思われます。

WebCenter Sitesは、独自のオブジェクト表やコンテンツ表の場合とまったく同じように、外部表に問い合せて結果セットをキャッシュできます。ただし、まずWebCenter Sitesに対してその外部表を特定することが必要で、そのためには、SystemInfo表にその外部表の行を追加します。これは、SystemInfo表で情報を変更する唯一の機会です。

また、問合せ先の表が外部システムによって更新された場合は必ず、CatalogManagerのflushcatalogタグを使用して、WebCenter Sites結果セットのキャッシュをフラッシュしてください。そうしないと、それらの表に対してキャッシュされた結果セットが、最新のものでなくなる可能性があります。

結果セットのキャッシングの詳細は、第14章「結果セットのキャッシングと問合せ」を参照してください。

12.1.5 システム表

システム表はコアで、スキーマが固定されたWebCenter Sitesの表です。それらは独自のクラスによってWebCenter Sitesに実装され、他の表が従う(キャッシングなどの)ルールに従いません。

(WebCenter Sitesインタフェースの「管理」タブにあるWebCenter Sitesの「管理ツール」フォーム、またはOracle WebCenter SitesのExplorerツールを使用して)システム表のいくつかに行を追加できますが、それらの表の列は追加も変更も一切できません。データベースにシステム表を追加することもできません。

次の表では、WebCenter Sitesのシステム表を一覧表示および定義しています。

表12-2 システム表

表

説明

ElementCatalog

システムで使用されるXMLエレメントまたはJSPエレメントをすべて一覧表示します。エレメントとは、コードのうち名前の付いた断片です。ElementCatalog表の詳細は、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

SiteCatalog

WebCenter Sitesで提供されている各ページまたは各ページレットへのページ参照を一覧表示します。SiteCatalog表の詳細は、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

SystemACL

WebCenter Sitesシステム用に作成されたアクセス制御リスト(ACL)のそれぞれに行があります。ACLはデータベース表に対する権限のセットです。

ACLの作成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

ACLの使用によるオンライン・サイトへのユーザー管理の実装については、第31章「配信システムにおけるユーザー管理」を参照してください。

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を使用している場合、この表は使用されないことに注意してください。

12.1.6 表のタイプの特定

WebCenter Sitesデータベース内の任意の表の表タイプを判別するには、SystemInfo表を調べます。これは、データベース内のすべての表を一覧表示するシステム表です。

表タイプを判別するには:

1. Oracle WebCenter Sites Explorerを開き、WebCenter Sitesデータベースにログインします。

2. SystemInfo表をダブルクリックします。

3. 表のリストで、systable列を調べます。この列の値によって、行に表される表のタイプが特定されます。

表12-3 表タイプの判別

systable列の値

定義

yes

システム表

no

コンテンツ表

obj

オブジェクト表

tree

ツリー表

fgn

外部表

注意:

ユーザー名に適切なACLが割り当てられていないと、SystemInfo表を開いて調べることはできません。

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

WebCenter Sitesデータベースの表を新規作成すると、その表にアセットが保持されているかどうかに関係なく、それらの表の列に、一般カテゴリのフィールド(列)タイプとして、次の3つを指定できます。

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

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

- WebCenter SitesのURLフィールド

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

- 第12.2.1項「汎用的なフィールド・タイプ」

- 第12.2.2項「データベース固有のフィールド・タイプ」

- 第12.2.3項「WebCenter SitesのURLフィールドを使用した間接的なデータ格納」

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

汎用的なフィールド・タイプとは、WebCenter SitesでサポートされているいずれのDBMSでも機能するフィールド・タイプのことです。これらは、JDBC規格に準拠するようにマップされます。したがって、WebCenter Sitesシステムが別のDBMSに変わっても、現在使用しているデータベースは引き続き有効となります。

汎用的でJDBCに準拠したフィールド・タイプを使用している場合は、表の中のデータを変更および保持するために、CatalogManager API (CATALOGMANAGERというXMLタグまたはJSPタグ、あるいはics.CatalogManagerというJavaメソッド)を使用できます。

次の表には、WebCenter Sitesの汎用的なフィールド・タイプ、およびそのデータ型を定義する(futuretense.iniファイル内の)データベース・プロパティの詳細なリストが含まれています。WebCenter Sitesのインタフェースの「管理」ツリーにあるWebCenter Sitesの「管理ツール」フォームまたはCatalogManager APIを使用して表を新規作成するときには必ず、このリストを参照してください。

表12-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

列タイプを定義することに加えて、列に対する次の制約のうち、該当する列に当てはまるものがどれであるかを指定する必要があります。

表12-5 列の制約

制約

説明

NULL

NULL値を保持できます。つまり、空にしておくことができます。

NOT NULL

NULL値を保持できません。つまり、空にしておくことができません。

UNIQUE NOT NULL

この表で間違いなく一意となる値を保持する必要があります。

PRIMARY KEY NOT NULL

コンテンツ表の主キー列にマークを付けます。オブジェクト表では、列に対してこの制約を設定しないでください。

AssetMakerを使用して新規のアセット・タイプのオブジェクト表を作成する場合、またはフレックス属性を新規作成する場合は、それらのアイテムのデータ型は、ここに一覧表示されているものとは異なります。

ベーシック・アセット・タイプの列のデータ型の詳細は、第15.1.3.2項「列の記憶域のタイプ」を参照してください。フレックス属性のデータ型については、第11.3.3.1項「属性のデータ型」を参照してください。

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

表ではデータベース固有のフィールド(列)タイプを使用できます。ただし、ある種類のDBMSに固有のフィールド・タイプ(つまり、JDBC規格にマップされていないタイプ)を使用する場合は、次の点に注意してください。

- これらの表に対しては、CatalogManager APIを使用できない場合があります。

- DBMSを変更することがあれば、表も変更する必要があります。

使用しているDBMSに固有のフィールド・タイプの詳細なリストについては、そのDBMSのドキュメントを参照してください。

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

WebCenter Sitesデータベースのオブジェクト表とコンテンツ表には、その列にデータを間接的に格納できるという独特の特徴があります。これは、大量のデータを外部のDBMSに格納できますが、その格納先はデータ・リポジトリ内にかぎられるという意味です。

そのような列を作成するには、先頭の文字をurlにした列名を使用する必要があります。列名の最初の3文字にurlを使用すると、WebCenter Sitesでは、その列が間接的なデータ列として扱われます。

URLフィールドを使用するのはなぜでしょうか。その理由は次のとおりです。

- 使用しているDBMSが、そこに格納しようとしているデータのサイズに対応できるほど大きなフィールドをサポートしていないとき

- 使用しているDBMSが、格納しようとしているデータを含めるための個々の表で十分なフィールドをサポートしていない場合

- フィールドのサイズが大きいと、データ選択のパフォーマンスが低下するため

注意:

URL列に格納しようとしているデータのサイズが、futuretense.iniファイルのcc.maxvarcharsizeプロパティに設定された値を超過している場合は、そのデータは、データベース内のポインタによって参照されるファイルとして間接的に格納されるのではなく、データベースに格納されます。

デフォルトのストレージ・ディレクトリ(defdir)

URL列のある表では、デフォルトのストレージ・ディレクトリがその列に指定されている必要があります。このディレクトリは、その列に入力された値が実際に格納される場所です。

デフォルトのストレージ・ディレクトリという言い回しは、製品のいくつかの箇所ではdefdirという言葉に短縮されています。たとえば、SystemInfo表のdefdir列には、URL列のある表のデフォルトのストレージ・ディレクトリの名前が保持されます。AssetMakerユーティリティのフォームのいずれかには、defdirフィールドなどが提示されます。

URLフィールドに入力される値は、ファイルへの相対パスです。なぜ相対パスなのでしょうか。URLフィールドの値が、表のdefdir設定の値に付加されるからです。

作成する表のdefdir値をどのように設定するかは、使用しているアプリケーションや作業内容によって異なります。

- WebCenter Sitesのユーザー・インタフェースの「管理」ツリーにあるWebCenter Sitesの「管理ツール」フォームを使用してWebCenter Sitesの表を新規作成し、その表にURLフィールドがある場合は、「カタログの追加」(表)フォームの「ファイル・ストレージ・ディレクトリ」フィールドにdefdirの値を入力します。

- CatalogManager APIを使用してWebCenter Sitesの表を新規作成する場合は、uploadDir引数を使用してdefdirの値を設定します。

- ベーシック・アセット・タイプを新規作成する場合は、「AssetMaker」フォームのdefdirフィールドでdefdirの値を指定します。(ベーシック・アセットを保持しているすべての表にはURL列があり、defdirの値が設定されている必要があります。)

- フレックス・アセット・タイプを新規作成する場合は、フレックス・アセットの_Mungo表で、URL列のdefdirの値を指定しないでください。この値は、WebCenter Sitesのアプリケーションがインストールされたときに設定されたプロパティから取得されます。そのプロパティの値は変更しないでください。

重要:

URL列のある表が作成された後は、いかなる方法によっても、表のdefdir設定を変更しようとしないでください。変更した場合、ストレージ・ディレクトリとURL列の間のリンクが断たれます。つまり、データを取得できなくなります。

URLフィールドの作成については、次の手順と例を参照してください。

- 第12.3項「データベース表の作成」

- 第15.2.3.3項「アップロードの例1: 標準アップロード・フィールド」からの、ベーシック・アセット・タイプのアップロード・フィールド例

- 第16.3.6.2項「タイプBlobのフレックス属性(アップロード・フィールド)の作成」に記述されている、BLOB型のフレックス属性の作成手順

12.3 データベース表の作成

この項では、オブジェクト表、ツリー表およびコンテンツ表の作成方法、および外部表の登録(すなわち、WebCenter Sitesに対してこれらを特定する)方法について説明します。システム表は、作成も変更もできません。

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

- 第12.3.1項「オブジェクト表の作成」

- 第12.3.2項「ツリー表の作成」

- 第12.3.3項「コンテンツ表の作成」

- 第12.3.4項「外部表の登録」

12.3.1 オブジェクト表の作成

オブジェクト表の作成方法には、次の3つがあります。

- ベーシック・アセット・タイプを保持する表を作成します。AssetMakerを使用する必要があります。これは、「管理」タブにあるWebCenter Sitesのユーティリティです。AssetMakerでは、アセット・タイプのオブジェクト表、およびそのタイプのアセットを作成するときに使用するフォームが作成されます。詳細は、第15章「ベーシック・アセット・タイプの設計」を参照してください。

- フレックス・アセット・タイプを保持する表を作成します。フレックス・ファミリ・メーカーを使用する必要があります。これは、「管理」タブにあるユーティリティです。詳細は、第16章「フレックス・アセット・タイプの設計」を参照してください。

- アセットを保持しないオブジェクト表を作成します。「管理」インタフェースにあるWebCenter Sites管理ツール(またはOracle WebCenter Sites Explorer)を使用します。

アセットを保持しないオブジェクト表を作成するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「管理」タブを選択し、「管理ツール」→「サイト・データベース」を選択します。

5. 「サイト・データベース」ウィンドウで「表の追加」を選択し、「OK」をクリックします。
「表の追加」フォームが表示されます。

6. 「表名」フィールド内をクリックし、名前を入力します。すでに存在している表名は使用できません。64文字までの英数字を入力できます。アンダースコア(_)文字は使用できますが、空白を含めることはできません。

7. 「表のタイプ」フィールド内をクリックし、「コンテンツ表」を選択します。

8. 表にURL列(アップロード列)を入れる場合は、「ファイル・ストレージ・ディレクトリ」フィールド(すなわちdefdir)内をクリックして、URL列のデータを格納するファイル・ディレクトリへのパスを入力します。ディレクトリが存在しない場合は、WebCenter Sitesによって自動的に作成されます。

9. 「アクセス権限」フィールド内をクリックし、この表にアクセスするユーザーに必要なACL (アクセス制御リスト)を選択します。ACLの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

10. 「フィールド名」列内をクリックして、フィールドの名前を入力します。外部ディレクトリにあるファイルとしてデータを格納するURL列を作成するには、フィールド名をurlで始める必要があることに留意してください。URL列を作成する場合は、このフィールドに格納されるデータ用のファイル・ストレージ・ディレクトリ(defdir)を指定していることを確認してください(この手順の手順7を参照)。

11. 「フィールド・タイプ」列内をクリックし、その列のデータ型および列の制約を指定します。データ型および列の制約の間にはスペースを含めます。
例: VARCHAR(32) NULLまたはINTEGER NOT NULL。

有効なデータ型および列の制約のリストについては、第12.2.1項「汎用的なフィールド・タイプ」を参照してください。

12. 新しい表内の列ごとに手順9および10を繰り返します。

13. 「追加」ボタンをクリックします。
表がデータベースに追加されます。

表が追加されたことを検証するには、Oracle WebCenter Sites Explorerを開いてSystemInfo表を調べます。新しい表がリストに追加され、そのsystable列がobjに設定されている必要があります。ファイル・ストレージ・ディレクトリを指定している場合は、そのディレクトリがdefdir列に表示されます。

オブジェクト表内のデータの管理

オブジェクト表内のデータを変更および管理する方法はいくつかあります。

アセットの作成と変更を行うには、WebCenter SitesアプリケーションとEngageアプリケーションを使用します。データベースからアセットを抽出して、配信システムの訪問者に表示するには、WebCenter Sites、EngageのXMLタグおよびJSPタグを使用します。

アセットを保持しないオブジェクト表に、次の方法のいずれかでデータを入力できます。

- プログラム的には、ics.CatalogManagerというJavaメソッド、またはCATALOGMANAGERというXMLタグおよびJSPタグ、OBJECTというXMLタグおよびJSPタグ、WebCenter SitesのSQLメソッドおよびSQLタグを使用してフォームをコーディングすると、ユーザーは、情報を入力してその情報をデータベースに書き込むように求められます。

- 手動で、Oracle WebCenter Sites Explorerツールと、WebCenter Sitesの「管理ツール」フォームにおけるフォームのいずれかを使用して、表に行を追加します。

第13章「アセットを保持しない表内のデータ管理」では、CatalogManager APIに関する情報、およびアセットを保持していない表に行を追加する例について説明します。

12.3.2 ツリー表の作成

WebCenter Sitesのモジュールまたは製品を使用している場合は、ツリー表を作成する必要が生じることはほとんどありません。

ツリー表は、TreeManagerサーブレットで管理されています。ツリー表(カタログ)を作成するには、ICS.TreeManagerというJavaメソッド、あるいはTREEMANAGERというXMLタグまたはJSPタグを使用します。ツリー表(カタログ)は、WebCenter Sites管理ツールでは作成できません。

例:

<TREEMANAGER>

<ARGUMENT NAME="ftcmd" VALUE="createtree"/>
<ARGUMENT NAME="treename" VALUE="ExampleTree"/>

</TREEMANAGER>

ツリー表に作成された列のリストについては、第12.1.2項「ツリー表」を参照してください。TreeManagerのメソッドおよびタグについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

12.3.2.1 ツリー表内のデータの管理

WebCenter Sitesのモジュールおよび製品では、ツリー表内のすべてのデータを管理します。どのようなツリー表でも、情報を手動で変更しようとしないでください。

独自のオブジェクト表(つまり、アセットを格納しないオブジェクト表)の間の関係を管理するために作成したツリー表があれば、ICS.TreeManagerというJavaメソッド、あるいはTREEMANAGERというXMLタグまたはJSPタグを使用します。これらのタグとメソッドは、実行するツリー操作を記述したFTValListパラメータを使用します。

次の章(第13章「アセットを保持しない表内のデータ管理」)では、CatalogManager APIに関する情報、およびアセットを保持していない表に行を追加する例について説明します。

12.3.3 コンテンツ表の作成

コンテンツ表を作成するには、WebCenter Sites管理ツールを使用します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「管理」タブを選択し、「管理ツール」→「サイト・データベース」を選択します。

5. 「サイト・データベース」ウィンドウで「表の追加」を選択し、「OK」をクリックします。
「表の追加」フォームが表示されます。

6. 「表名」フィールド内をクリックし、名前を入力します。すでに存在している表名は使用できません。64文字までの英数字を入力できます。アンダースコア(_)文字は使用できますが、空白を含めることはできません。

7. 「表のタイプ」フィールド内をクリックし、「コンテンツ表」を選択します。

8. 表にURL列を入れる場合は、「ファイル・ストレージ・ディレクトリ」フィールド内をクリックして、URL列のデータを格納するファイル・ディレクトリへのパスを入力します。ディレクトリが存在しない場合は、WebCenter Sitesによって自動的に作成されます。

9. 「アクセス権限」フィールド内をクリックし、この表にアクセスするユーザーに必要なACL (アクセス制御リスト)を選択します。ACLの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

10. 「フィールド名」フィールド内をクリックして、フィールドの名前を入力します。外部ディレクトリにあるファイルとしてデータを格納するURL列を作成するには、フィールド名をurlで始める必要があることに留意してください。URL列を作成する場合は、このフィールドに格納されるデータ用のファイル・ストレージ・ディレクトリ(defdir)を指定していることを確認してください(この手順の手順7を参照)。

11. 「フィールド・タイプ」列内をクリックし、その列のデータ型および列の制約を指定します。データ型および列の制約の間にはスペースを含めます。
例: VARCHAR(32) NULLまたはINTEGER NOT NULL。

主キー列を指定する必要があること、またその主キー列が、cc.contentkeyプロパティの設定、またはfuturetense.iniファイルでこの表に指定されたカスタム・プロパティの設定と完全一致している必要があることに注意してください。

例: INTEGER PRIMARY KEY NOT NULL

12. 新しい表内の列ごとに手順9および10を繰り返します。

13. 「追加」ボタンをクリックします。
表がデータベースに追加されます。

表が追加されたことを検証するには、Oracle WebCenter Sites Explorerツールを開いてSystemInfo表を調べます。新しい表がリストに追加され、そのsystable列の値がnoに設定されている必要があります。ファイル・ストレージ・ディレクトリを指定している場合は、そのディレクトリがdefdir列に表示されます。

サイトの一部の機能を促進するためにアセットを保持しない表を追加したら、WebCenter Sitesでアセットのフォームをカスタマイズするか、または独自のフォームを作成してそのデータを入力および操作することが必要です。

コンテンツ表内のデータの管理

コンテンツ表内のデータを変更および管理する方法はいくつかあります。

WebCenter Sitesのコンテンツ表のほとんどでは、「管理」タブに、データの編集または追加に使用できるWebCenter Sitesのフォームが用意されています。たとえば、SourceとCategoryです。(ただし、MimeTypeには用意されていません。)

カスタム・コンテンツ表に、次の方法のいずれかでデータを入力できます。

- 表が作成され、その表に書き込まれるデータをユーザーまたは訪問者が提供する場合は、ics.CatalogManagerというJavaメソッド、またはCATALOGMANAGERというXMLタグおよびJSPタグを、WebCenter SitesのSQLメソッドおよびSQLタグとともにコーディングします。ユーザーは、情報を入力してその情報をデータベースに書き込むようにプログラムで求められます。

- サイトの一部の機能を促進する簡易参照表の場合は、Oracle WebCenter Sites ExplorerユーティリティとWebCenter Sitesの「管理ツール」ウィンドウのいずれかを使用することによって、データを手動で入力して、表に行を追加します。

第13章「アセットを保持しない表内のデータ管理」では、CatalogManager APIに関する情報、およびアセットを保持していない表に行を追加する例について説明します。

12.3.4 外部表の登録

外部表の登録とは、WebCenter Sitesに対してその表を特定することで、そのためには、SystemInfo表にその表の行を追加します。これは、SystemInfo表に行を追加したり、SystemInfo表に保持されている情報を変更する際の唯一の条件です。

外部表を登録するには:

1. Oracle WebCenter Sites Explorerを開き、WebCenter Sitesデータベースにログインします。

2. SystemInfo表をダブルクリックします。

3. tblname列のヘッダーを右クリックして、コンテキスト・メニューから「新規」を選択します。
新しい行が表示されます。

4. 新しい行で、tblname列内をクリックして、表の名前を入力します。

5. defdir列内をクリックして、表へのパスを入力します。

6. systable列内をクリックして、fgnと入力します。

7. acl列内をクリックして、表にアクセスできるACLの名前を入力します。

8. 「ファイル」→「すべて保存」を選択します。

外部表内のデータの管理

外部表との対話には、ics.CatalogManagerというJavaメソッド、またはCATALOGMANAGERというXMLタグおよびJSPタグ、およびWebCenter SitesのSQLメソッドおよびSQLタグを使用できます。これらのメソッドまたはタグを使用して外部表内のデータを更新すると、WebCenter Sitesでは、必要に応じてその結果セットのキャッシュをフラッシュできます。

WebCenter Sitesにとっては外部のメソッドを使用して外部表を更新する場合は、CATALOGMANGERのコマンドであるflushcatalogを使用して、その表の結果セットのキャッシュをフラッシュするようにWebCenter Sitesに指示する必要があります。

12.4 情報はシステム表にどのように追加されるか

一部の例外を除いて、システム表は作成できません。行の追加が許可されているシステム表に行を追加するには、WebCenter Sites管理ツールを必ず使用してください。次の表で説明するように、各システム表への情報の追加方法は異なります。

表12-6 情報をシステム表に追加する方法

表

情報を追加する方法

SiteCatalog

この表にページ・エントリを追加する方法はいくつかあります。

- テンプレート・アセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するページ・エントリが自動的に作成されます。

- SiteEntryアセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するページ・エントリが自動的に作成されます。

- Oracle WebCenter Sites Explorerツール、またはWebCenter Sitesの「管理ツール」インタフェースの「サイト」フォームを使用できます。

ページ・エントリのページ・キャッシュ設定を設定または変更する場合は、Oracle WebCenter Sites Explorerを使用するよりも、WebCenter Sitesインタフェースでフォームを使用する方が簡単です。

ElementCatalog

この表にエレメントを追加する方法はいくつかあります。

- テンプレート・アセットを作成すると、WebCenter Sitesでは、ElementCatalog表で、そのアセットに対するエントリが自動的に作成されます。

- CSElementアセットを作成すると、WebCenter Sitesでは、ElementCatalog表で、そのアセットに対するエントリが自動的に作成されます。

- Oracle WebCenter Sites Explorerツールを使用して、アセット以外のエレメントを追加できます。

エレメントおよびページのコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

SystemACL

「WebCenter Sites管理ツール」ノードの「ACL」フォーム。

詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

SystemEvents

WebCenter Sitesでは、APPEVENTタグ、EMAILEVENTタグ、またはそれらと同等のJava APIがエレメントから起動されたときに指定されたイベントごとに、この表に行が追加されます。

SystemInfo

この表に情報を追加することも、この表の情報を変更することもしないでください。

このルールに対する唯一の例外は、WebCenter Sitesに外部表を認識させる場合です。

SystemSQL

Oracle WebCenter Sites Explorerツール。

用意されている様々な種類の問合せについては、第14章「結果セットのキャッシングと問合せ」を参照してください。

SystemUsers

「WebCenter Sites管理ツール」ノードの「ユーザー」フォーム。

SystemUserAttr

「WebCenter Sites管理ツール」ノードの「ユーザー」フォーム。

12.5 プロパティ・ファイルとデータベース

futuretense.iniファイルには、WebCenter Sitesデータベースへの接続を制御する様々なプロパティがあります。これらのプロパティによって、データベースの構成が指定され、データベースとアプリケーション・サーバー間に、権限の有無を問わず、ユーザー接続が確立します。

データベース・プロパティのすべては、システムのインストール時にシステムに構成されました。デフォルトでは、すべてのコマンドは、futuretense.iniファイルで特定されているWebCenter Sitesデータベース上で動作します。futuretense.iniファイルが格納されているディレクトリは次のとおりです。

<installation_directory>/ContentServer/11.1.1.6.0/

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

この章では、アセットを保持しないWebCenter Sitesデータベース表とのやり取りについて説明します。

アセットを保持しないカスタムの表でデータを使用して作業をするには、次の2つの方法があります。

- プログラム上で: CatalogManager APIのタグとメソッドを使用して、データ・エントリと管理のためのフォームをコード化します。

- 手動で: Oracle WebCenter Sites ExplorerツールまたはWebCenter Sites管理ツールの「コンテンツ」フォームを使用して、表に行とその行に対するデータを手動で追加します。

アセットで作業するには、WebCenter Sitesインタフェースにログインし、WebCenter SitesとEngageのアプリケーションで提供されるアセット・フォームを使用する必要があります。

大量のアセットをプログラムで追加するには、XMLPostユーティリティを使用します。詳細は、第20章「任意タイプのアセットのインポート」および第21章「フレックス・アセットのインポート」を参照してください。

この章には次の項が含まれます。

- 第13.1項「メソッドとタグ」

- 第13.2項「データ・エントリ・フォームのコード化」

- 第13.3項「データの手動管理」

- 第13.4項「アセットを保持しない表の削除」

13.1 メソッドとタグ

この項では、アセットを保持しない表のデータ管理とそれらの表との一般的なやり取りに関するプログラミングに使用するタグとメソッドの概要について説明します。

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

- 第13.1.1項「データの記述と取得」

- 第13.1.2項「データの問合せ」

- 第13.1.3項「リストおよびデータ・リストの作成」

13.1.1 データの記述と取得

CatalogManagerはWebCenter Sitesのサーブレットで、データベースにあるコンテンツとオブジェクトの表を管理し、TreeManagerサーブレットがデータベース内のツリー表を管理します。

- CatalogManagerサーブレットにアクセスするには、ics.CatalogManager Javaメソッド、CATALOGMANAGER XMLタグまたはics:catalogmanager JSPタグを使用します。

- TreeManagerサーブレットにアクセスするには、ics.TreeManager Javaメソッド、TREEMANAGER XMLタグまたはics:treemanager JSPタグを使用します。

これらのメソッドとタグは、実行する操作およびその操作の実行対象である表を指定する引数から名前と値のペアを取得します。

13.1.1.1 CatalogManager

ics.CatalogManager javaメソッド、CATALOGMANAGER XMLタグおよびics:catalogmanager JSPタグは、オブジェクトとコンテンツ表で稼働する多数の属性をサポートします。キー属性はftcmdです。たとえば、ftcmdをaddrowに設定すると、CatalogManagerによりカタログに1行追加されます。

CatalogManagerセキュリティが有効な場合には、DefaultReader ACLを使用してCatalogManagerにアクセスできません。CatalogManagerセキュリティを有効にするには、futuretense.iniファイルのsecure.CatalogManagerプロパティをtrueに設定します。CatalogManagerセキュリティが有効になっているときにCatalogManagerからログアウトを試みると、セッションが削除されるので注意してください。

主要なCATALOGMANAGER XMLタグの属性は、次のとおりです。これらの属性は、名前/値の引数ペアとして渡され、行のコンテンツや行の特定のフィールドを変更します。

表13-1 CATALOGMANAGER XMLタグ

argument name="ftcmd" value=

説明

addrow

表に単一行を追加します。

addrows

表に複数行を追加します。

deleterow

表から1行削除します。行の主キー列を指定する必要があります。

deleterows

表から複数行を削除します。行の主キーを指定する必要があります。

replacerow

表内の既存の行を削除し、指定された情報に従って行を置換します。

replacerows

表の複数行を置換します。列の値が指定されていない場合、列の値は消去されます。

updaterow

指定された表に問合せを実行し、表からのレコードを表示します。表示される列は、パラメータの値で指定された基準と一致します。

updaterow2

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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。ics.CatalogManager Javaメソッドの詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

13.1.1.2 ツリー・マネージャ

主要なics.TreeManagerコマンドは、次のとおりです。これらの操作はツリー表のデータのみをコントロールし、ツリー表のノードが参照するオブジェクトには影響を与えません。

表13-2 TreeManagerのコマンド

名前

説明

addchild

親ノードを指定され、子ノードを追加します。

addchildren

複数の子ノードを追加します。

copychild

任意のノードとその子(複数も可)を別の親にコピーします。コピーされたノードはすべて同じオブジェクトをポイントします。

createtree

ツリー表を作成します。

delchild

ノードとその子ノードを削除します。

delchildren

複数のノードを削除します。

deletetree

ツリー表を削除します。

findnode

ツリーのノードを検索します。

getchildren

すべての子ノードを取得します。

getnode

ノードおよびオブジェクトの属性(オプション)を取得します。

getparent

ノードに親を取得します。

listtrees

すべてのツリー表を取得します。

movechild

ノードとその子ノードを別の親に移動します。

nodepath

親; 子のパスをノードに返します。

setobject

異なるオブジェクトをノードに関連付けます。

validatenode

ノードがツリーに存在することを確認します。

verifypath

指定されたパスがツリーに存在することを確認します。

ics.TreeManagerメソッドの詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

XMLタグとJSP TREEMANAGERタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

13.1.2 データの問合せ

コード問合せをサポートしてコンテンツを選択するには、一連のXMLおよびJSPのタグを使用する次の3つのメソッドがあります。

表13-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メソッドを使用して、適切な表に対してキャッシュされた結果セットを明示的にフラッシュするコードを追加する必要があります。

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

多くのICSメソッドにより、リストが作成されます。たとえば、SelectToメソッドはリスト内の簡単なSQL問合せの結果を返します。このリストの列は、WHAT句内の項目を反映し、行は表に対する一致を反映しています。

IListインタフェースは、Javaからのリストのアクセスに使用できます。リストは、XMLまたはJSPを使用して名前別に利用でき、値はLOOPタグを使用して反復できます。

WebCenter Sitesで作成されたリストは、データベースの問合せから作成された基礎となる結果セットをポイントします。リストはリクエスト間で永続的にはなりませんが、結果セットはキャッシュされていれば永続的になります。

注意:

必ず結果セットのキャッシュを適切に構成してください。問合せの結果セットがキャッシュされている場合、リストは結果セットのコピーをポイントします。結果セットがキャッシュされていない場合、リストは結果セットを直接ポイントし、データベースの接続リソースに問題を発生することがあります。

IListインタフェースに基づいたクラスを実装することで、XMLまたはJSPでの使用に対応した独自のリストを作成できます。それにより、アプリケーションやページでリストの項目を返す前にデータを変換したり、多数のリストから単一のリストを作成できるようになります。

リストを管理するメソッドは、次のとおりです。

表13-4 リストを管理するメソッド

メソッド

説明

ics.GetList

指定されたリスト名のIListを返します。

ics.CopyList

リストをコピーします。

ics.RenameList

既存リストの名前を変更します。

ics.RegisterList

WebCenter Sitesにリストを名前登録して、このリストをXMLまたはJSPエレメントから参照したり、GetListメソッドを使用して参照できるようにします。

IListの例の導入については、WebCenter SitesシステムのSamplesフォルダにあるSampleIList.javaを参照してください。

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

この項では、ユーザーや訪問者が入力した情報を受け入れるフォームのコード化方法、およびそのうえでWebCenter Sitesメソッドとタグを使用してデータベースに情報を書き込む方法を示すコード・サンプルについて説明します。

この項の例は、新しい行の追加、行の削除、既存の行の問合せとその後の編集について説明しています。各例には、XML、JSPおよびJavaのバージョンが示されています。

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

- 第13.2.1項「行の追加」

- 第13.2.2項「行の削除」

- 第13.2.3項「表の問合せ」

- 第13.2.4項「埋め込まれたSQL文を持つ表の問合せ」

13.2.1 行の追加

行を追加する単一のアルゴリズムは、次のとおりです。

1. 情報をリクエストするフォームを行内の各フィールドに表示します。

2. フォームのデータを表に書き込みます。

次の例では、EmployeeInfoという名前の架空の表に行を追加します。この表にある列は、次のとおりです。

表13-5 表への行の追加の例

フィールド

データ型

id

VARCHAR(6)

phone

VARCHAR(16)

name

VARCHAR(32)

この例は、次のエレメントのコードを示しています。

- addrowFORM: 従業員のID番号、電話番号および名前をリクエストするフォームを表示するXMLエレメントです。

- addrowXML、addrowJSPおよびaddrowJAVA: 従業員が入力した情報をEmployeeInfo表に書き込む、3つのバージョンのエレメントです。

13.2.1.1 addrowFORMエレメント

addrowFORMエレメントは、ユーザーに情報の入力を求めるフォームを表示します。これは次のようになります。

これは、フォームを作成するコードです。

<?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>の最大長修飾子は、各入力の長さをスキーマで定義された最大長の長さに制限することに注意してください。

ユーザーはフォームに入力し、「送信」ボタンをクリックします。フォームとaddrowページ(前述のコード・サンプルの最初のinput type文を参照)のページ名で収集された情報がブラウザに送信されます。ブラウザはページ名をWebCenter Sitesに送信します。WebCenter SitesではSiteCatalog表内が検索され、そのページ・エントリのルート・エレメントが起動されます。

13.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は機能しません。詳細は、第12.2.1項「汎用的なフィールド・タイプ」を参照してください。

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>

13.2.2 行の削除

次の例では、第13.2.1項「行の追加」で説明されている架空のEmployeeInfo表から行を削除します。

この項では、次のエレメントからのコードを示します。

- deleterowFORM: EmployeeInfo表から削除する従業員名をリクエストするフォームを表示するXMLエレメントです。

- deleterowXML、deleterowJSPおよびdeleterowJAVA: deleterowFORMエレメントから送信された情報に基づいて、EmployeeInfo表から行を削除するエレメントです。

13.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表内が検索され、そのページ・エントリのルート・エレメントが起動されます。

13.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>

13.2.3 表の問合せ

次のサンプル・エレメントは、架空のEmployeeInfo表に従業員名を問い合せ、従業員名を抽出してブラウザに表示し、ユーザーに情報を編集するよう要求し、編集済の情報をデータベースに書き込みます。

この項では、次のエレメントからのコードを示します。

- SelectNameForm: 従業員名をリクエストするフォームを表示するXMLエレメントです。

- 3つのバージョンのQueryEditRowFormエレメント(XML、JSPおよびJava): 従業員名を検索し、従業員に関する情報をフォームにロードして、従業員が自分の情報をそのフォームで編集できるようにするエレメントです。

- 3つのバージョンのQueryEditRowエレメント(XML、JSPおよびJava): 新規編集済の情報をデータベースへ書き込むエレメントです。

13.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が起動されます。

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

QueryEditRowFormページのルート・エレメントは、EmployeeInfo表で「従業員名」フィールドに入力した文字列と一致する行を検出し、データをその行から新しいフォームにロードします。従業員は自分の名前と電話番号は編集できますが、IDは編集できません。表示されるフォームは次のとおりです。

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表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

13.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>

13.2.4 埋め込まれたSQL文を持つ表の問合せ

次の例は、表内の名前を検索するもう1つの方法を示しています。この例でも架空のEmployeeInfo表を検索し、ユーザーが入力した文字列と一致する行を返しますが、今回のコードでは、SELECTTO文ではなくSQL問合せが使用されます。

この項では、次のエレメントからのコードを示します。

- QueryInlineSQLForm: 映画のタイトルをリクエストするフォームを表示するXMLエレメントです。

- 3つのバージョンのQueryInlineSQLエレメント(XML、JSPおよびJava): EmployeeInfo表で前述のフォームにユーザーが入力した文字列を含む名前を検索します。

13.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表でページ名が検索され、そのページ・エントリのルート・エレメントが起動されます。

13.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は正確な表に対する結果セットをキャッシュできるようになります。

13.3 データの手動管理

Oracle WebCenter Sites ExplorerツールまたはWebCenter Sites管理ツール内のフォームのいずれかを使用して、データを手動で表に追加できます。

次のような場合には、Oracle WebCenter Sites Explorerを選択することをお薦めします。

- 新しいページのページ・エントリをSiteCatalog表で作成する場合。

- ElementCatalog表内のエレメントに行を作成し、そのエレメントをOracle WebCenter Sites Explorerのエディタでコード化している場合。

- サイトの機能の一部をサポートするために作成した表に少量のデータを追加する必要がある場合。つまり、アセットを保持していない表に少量のデータを追加する必要がある場合です。(MimeType表への行の追加など。)

Oracle WebCenter Sites Explorerには、行の追加、編集または削除に関する情報が必要な場合に使用できるオンライン・ヘルプが用意されています。さらに、第4章「Oracle WebCenter Sitesを使用したプログラミング」には、SiteCatalog表へのページ・エントリの追加とElementCatalog表へのエレメントの追加方法が説明されています。

次のような場合には、WebCenter Sites管理ツールを選択することをお薦めします。

- ユーザーまたはACLをシステムに追加する場合。

- SiteCatalog表のページ・エントリのキャッシュ設定を変更する場合。このタスクは、通常、ContentManagementフォームで実行する方が、Oracle WebCenter Sites Explorerを使用して情報を列に直接入力するより簡単です。

WebCenter Sites管理ツールの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

13.4 アセットを保持しない表の削除

データベースからのリビジョン追跡を実行中のアセットを保持しない表を削除した場合でも、追跡表は削除されないことに注意してください。そのような結果を避けるには、削除する前にリビジョン追跡を必ず無効化してください。

14 結果セットのキャッシングと問合せ

CatalogManagerサブレット(およびそのAPI)は、WebCenter Sitesシステムの結果セット・キャッシュを維持します。この章では、結果セットのキャッシングについて、またCatalogManagerを使用して結果セットを適切にキャッシュして、キャッシュからそれらの結果セットをフラッシュできるようにする問合せの作成方法について説明します。開発者やシステム管理者は、3つのシステム(開発、管理および配信)すべてで結果セットのキャッシングを設定します。

データベースに問い合せるたびに、WebCenter Sitesではキャッシュ済の結果セットまたは未キャッシュの結果セットのいずれかの結果セットが処理されます。結果セットのキャッシングは、ご使用のデータベースの負荷を軽減し、問合せに対するレスポンス時間を改善します。

futuretense.iniファイルには、すべての結果セットのサイズとタイムアウトの期間を設定するグローバル・プロパティが用意されています。表ごとのデフォルト設定をオーバーライドする、表固有のプロパティをfuturetense.iniファイルに追加できます。これらのカスタム・プロパティを使用すると、ピーク・パフォーマンスのシステムを微調整できます。

この章には次の項が含まれます。

- 第14.1項「キャッシング・フレームワーク」

- 第14.2項「データベースの問合せ」

- 第14.3項「結果セットのキャッシングの仕組み」

- 第14.4項「データベースのロードの削減」

- 第14.5項「表名の指定」

- 第14.6項「結果セットのキャッシュのフラッシュ」

- 第14.7項「キャッシング・フレームワーク間の切替え」

- 第14.8項「結果セットのキャッシングの構成」

- 第14.9項「まとめ」

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

デフォルトでは、WebCenter Sitesは、結果セットをinCacheフレームワークに格納します。第14.7項「キャッシング・フレームワーク間の切替え」の説明に従い、ハッシュ表のキャッシングに切り替えるオプションを使用できます。

inCacheによる結果セット・キャッシングが有効になると、「システム・ツール」ノード(Adminインタフェースの「管理」タブにある)には、結果セットのキャッシュとそのコンテンツに関する統計情報を提供するinCacheツールによって結果セットが表示されます。inCacheによる結果セットのキャッシュは、inCacheによるページとアセットのキャッシュとは関係なく機能することに注意してください。inCacheフレームワーク、そのキャッシュ・モデルおよびシステム・ツールの詳細は、Oracle Fusion Middleware WebCenter Sites管理者ガイドを参照してください。

14.2 データベースの問合せ

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タグ(フレックス・アセットのみ)を使用する

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

データベースに問合せがある場合、結果セットのキャッシングを有効にしてあると、問合せからの結果セットがキャッシュされます(関連プロパティの詳細は、第14.8.2項「デフォルト・プロパティ」および第14.8.3項「表固有のプロパティ」を参照)。その場合、同じ問合せが別に実行され、最新の問合せが実行されてから表内のデータが変更されないままだと、データベースに再び問い合せるのではなく、結果セットのキャッシュからの情報が提供されます。キャッシュからの結果セットの提供の方が、別のデータベース検索の実行より迅速に実行されます。

futuretense.ini内のrsCacheOverInCacheプロパティの構成方法に応じて、結果セットのキャッシュはハッシュ表またはinCacheフレームワークのいずれかになります。結果セットは、結果セットを生成した問合せに関連付けられた表名ごとに編成されています。つまり、結果セットは表名に対してキャッシュされます。

表が更新されるたびに(WebCenter Sitesインタフェースから、またはカスタム・エレメントのCatalogManagerコマンドにより)、その表に対するキャッシュ内のすべての結果セットがフラッシュされます。結果セットは単一のJava VMと関連してキャッシュされます。Java VM間では結果セットを共有しませんが、同期機能がクラスタ内のすべてのサーバーで有効になっていれば、WebCenter Sitesではクラスタ内のすべてのJava VMにシグナルが送信され、結果セットは無効になったときにフラッシュされます。

14.4 データベースのロードの削減

結果セットのキャッシングは、次の2つの方法でデータベースのロードを軽減します。

- キャッシュ済の結果セットの処理では、データベース接続がオープンされません。WebCenter Sitesは、結果セットがデータベースに接続する前にキャッシュから結果セットの取得を試行します。適切な結果セットが存在すれば、データベースとの接続は実行されません。

- 結果セットのキャッシングが有効になっているのに適切な結果セットがキャッシュされない場合には、WebCenter Sitesでは結果セットが取得され、キャッシュ内にオブジェクトとして格納され、データベースとの接続が解放されます。
結果セットのキャッシングが有効でない場合、WebCenter Sitesではオンライン・ページが完全にレンダリングされるか、未キャッシュの結果セットがflushタグを持つスコープから明示的にフラッシュされるまで、データベースの接続をクローズできません。このような事態が発生すると、有効なデータベース接続はすぐに使い尽くされる可能性があります(比較的シンプルなページであっても)。

通常、結果セットのキャッシングはすべてのデータベース表で有効にする必要があります。キャッシュする結果セットの数やキャッシュする時間の長さを制限する必要がある場合でも、結果セットのキャッシングを全部まとめて無効にすることは逆効果になりかねません。

注意:

ElementCatalog表の結果セットのキャッシングを無効にしないでください。無効にした場合、いずれかのエレメントでJSPを使用する場合は特に、システム・パフォーマンスが大きく低下します。

14.5 表名の指定

該当する表に対して結果セットをキャッシュできるように、表名は常に問合せと関連付けられている必要があります。それにより、表がWebCenter Sitesインタフェースや独自のカスタム・エレメントで更新されるたびに、その表に関連付けられたすべての結果セットがCatalogManagerによってフラッシュされます。

表名を結果セットに対して指定する方法は、実行している問合せのタイプに応じて異なります。次の項では、最も一般的に使用されるデータベースへの問合せ方法とそのような問合せに対する表名の指定方法について説明します。

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

- 第14.5.1項「SELECTTO」

- 第14.5.2項「EXECSQL」

- 第14.5.3項「CALLSQL」

- 第14.5.4項「WebCenter Sitesインタフェースのフォームの検索」

- 第14.5.5項「問合せアセット」

- 第14.5.6項「SEARCHSTATE」

14.5.1 SELECTTO

ics.SelectTo Javaメソッド、SELECTTO XMLタグまたはics:selectto JSPタグを使用する場合、FROMパラメータ(句)を使用して表名を指定する必要があります。例:

<SELECTTO FROM="EmployeeInfo"
WHERE="name"
WHAT="*"
LIST="MatchingEmployees"/>

この場合、EmployeeInfoは問合せ先の表名であり、結果セットをキャッシュした表の名前です。EmployeeInfo表が更新されるたびに、CatalogManagerではその表に対してキャッシュされたすべての結果セットがフラッシュされます。

14.5.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"/>

14.5.3 CALLSQL

ics.CallSQL Javaメソッド、CALLSQL XMLタグまたはics:callsql JSPタグを使用して、SystemSQL表内に格納されているSQL問合せを呼び出すと、表名はSystemSQL表内の問合せのエントリ(行)によって設定されます。

SystemSQL表にはdeftable列があり、問合せからの結果セットをキャッシュする表名を識別します。複数の表を指定するには、deftable列に表のカンマ区切りリストを追加します。リストの最初の表は、問合せがキャッシュされる表です。

表に格納された各問合せでは、deftable列に値が存在する必要があります。値がないと、CatalogManagerで結果セットを適切に保存できなくなり、必要な場合に結果セットをフラッシュできなくなります。表名は既存の表を識別する必要があります。存在しない表名を入力したり、表名のスペルを間違えると、結果セットを適切にキャッシュできません。

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

WebCenter Sitesインタフェースのアセットを検索する際に使用する「検索」フォームは、アセットをそのタイプに基づいて検索します。検索フォームの問合せからの結果セットは、該当するタイプのアセットのプライマリ記憶域表に対して格納されます。

たとえば、Burlington Financialサンプル・サイトで、記事という名前のアセットの結果セットはArticle表に対してキャッシュされ、ページのアセットはPage表に対してキャッシュされます。

14.5.5 問合せアセット

問合せアセットが返すことができるアセットは、1タイプのアセットのみです。問合せアセットを作成する際には、問合せアセットが「問合せの結果」フィールドに返すアセットの種類を、記事、イメージファイルなどのように指定します。

該当する問合せアセットがオンライン・サイトのページで使用されると、WebCenter Sitesでは問合せアセットが返すアセット・タイプ(ArticleやImagefileなど)のプライマリ記憶域表の表名に対する結果セットが格納されます。

14.5.6 SEARCHSTATE

SEARCHSTATE XMLタグおよびJSPタグは、一連のフレックス・アセット(ASSETSETタグにより作成される)に適用される一連の検索絞込み条件を作成します。絞込み条件として、属性値または別のsearchstate(ネストされたsearchstate)のいずれかに基づいたフィルタ(制限)を使用できます。

SEARCHSTATEタグとASSETSETタグを使用して、フレックス・アセットまたはフレックス親アセット(定義やフレックス属性ではない)を抽出し、オンライン・ページで訪問者に表示します。

WebCenter Sitesでは、検索状態の結果セットがフレックス・アセット・タイプの_Mungo表に対してキャッシュされます。たとえば、検索状態が製品と名付けられたGE Lightingのサンプル・サイトのフレックス・アセットを返した場合、その結果セットはProducts_Mungo表に対してキャッシュされます。

配信システムを構成する際には、必ずすべての_Mungo表に対する結果セットのキャッシング・プロパティを追加してください。

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

ほとんどの場合、データはCatalogManager APIによってデータベースに書き込まれ、必要に応じて結果セットのキャッシュがフラッシュされます。例:

- WebCenter Sites Explorerを使用して表(SiteCatalog表、ElementCatalog表など)に行を追加する場合、該当する表に対してキャッシュされたすべての結果セットがフラッシュされます。

- WebCenter Sitesインタフェース内のフォームを使用してアセット、ソース、カテゴリ、ワークフロー・プロセス、ユーザー、ACLなどを追加または編集する場合、書き込まれた表に対してキャッシュされた結果セットがフラッシュされます。

- 自分のエレメント内にあるCatalogManagerのコマンドを使用して単一の表を更新する場合、該当する表に対してキャッシュされた結果セットは自動的にフラッシュされます。

- 自分のエレメント内にあるCatalogManagerのコマンドを使用して複数の(結合された)表を更新する場合、その結合された表に対してキャッシュされた結果セットは自動的にフラッシュされます。

- CALLSQLタグを使用してSystemSQL表に格納されているSQL文を実行すると、deftable列で指定された表(複数可)に対してキャッシュされた結果セットが自動的に更新されます。

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

inCacheに関する結果セットのキャッシングは、次の条件に一致すると有効になります。

1. linked-cache.xml構成ファイルがアプリケーション・サーバーのクラスパス(WEB-INF/classesディレクトリ)に格納されている場合。

2. rsCacheOverInCacheプロパティ(futuretense.ini内の)がtrueに設定されている場合。

そのうえでinCacheおよびハッシュ表のフレームワークを切り替えるには、rsCacheOverInCacheプロパティをtrueまたはfalseに設定します。

14.8 結果セットのキャッシングの構成

この項では、すべての表と特定の表について結果セットのキャッシング・プロパティを計画して使用するプロセスについて説明します。

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

- 第14.8.1項「結果セットのキャッシング戦略の計画作成」

- 第14.8.2項「デフォルト・プロパティ」

- 第14.8.3項「表固有のプロパティ」

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

データベースに対して結果セットのキャッシングを構成する前に、WebCenter Sitesデータベース内のすべての表のスプレッドシートを作成し、開発者とデータベース管理者のチームを作り、開発、管理、テストおよび配信のすべてのシステムについての設定内容を検討します。戦略の1つとして、デフォルトのプロパティを使用できる類似表の大きなグループを1つ特定し、例外の表固有のプロパティを追加します。ただし、配信システムを調整して最高のパフォーマンスを得るには、配信システムのデータベース内の各表で最低でも50から100個のカスタム・プロパティを作成する必要があると考えられます。

注意:

com.fatwire.logging.cs.cache.resultsetプロパティを設定すると、結果セットのキャッシュに関するデバッグ・メッセージがWebCenter Sitesログ・ファイルに書き込まれます。(使用しているロギング・フレームワークに応じて、commons-logging.propertiesファイルまたはlog4j.propertiesのいずれかでプロパティを設定します。)

14.8.2 デフォルト・プロパティ

表14-1は、すべての表に割り当てられる、futuretense.iniの結果セットのキャッシング・プロパティについて説明しています。表固有のキャッシング・プロパティが表に割り当てられていなければ、これらのプロパティが表の結果セットのキャッシュを制御します。同一のプロパティが、inCacheとハッシュ表の両方で結果セットのキャッシングに有効となります。これらのプロパティを変更するには、futuretense.iniファイルをプロパティ・エディタ・ユーティリティで開いて変更します。プロパティ・エディタの使用の詳細は、第8章「WebCenter Sitesのツールおよびユーティリティ」を参照してください。

表14-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分後にキャッシュからフラッシュされます。

14.8.3 表固有のプロパティ

表固有のプロパティは、デフォルト・プロパティをオーバーライドし、システムをピーク・パフォーマンスで微調整できるようにします。CatalogManagerでは、表14-1で説明したデフォルト・プロパティを使用して、表固有の結果セットのキャッシング・プロパティが含まれているかどうかを確認するためにfuturetense.iniファイルがチェックされます。

WebCenter Sitesデータベースの各表について3つの結果セットのキャッシング・プロパティを作成できます。表固有のプロパティは、デフォルト・プロパティと同様に動作します(詳細は表14-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 Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

futuretense.iniファイルをプロパティ・エディタ・ユーティリティで開き、制御する各表に表固有のプロパティを追加します。プロパティ・エディタ・ユーティリティの使用の詳細は、第8章「WebCenter Sitesのツールおよびユーティリティ」を参照してください。

14.9 まとめ

結果セットのキャッシングは、ご使用のデータベースの負荷を軽減し、問合せに対するレスポンス時間を改善します。必ず次の操作を実行してください。

- futuretense.iniファイルのデフォルト結果セットのキャッシング・プロパティを、開発、管理、テストおよび配信の各システムで意味のある値に設定します。

- 表固有の結果セットのキャッシング・プロパティをfuturetense.iniファイルに追加し、開発、管理、テストおよび配信のすべてのシステムのパフォーマンスを微調整します。

- すべての問合せに対して適切な表名を付け、結果セットが正しくキャッシュされ、正しくフラッシュされるようにします。

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

第11章「データ・デザイン: アセット・モデル」で説明されているように、ベーシック・アセット・タイプのデータ・モデルとはアセット・タイプごとに用意された1つのデータベース表を意味します。その表には、該当するタイプの各アセットが格納されています。

AssetMakerユーティリティを使用して、ベーシック・アセット・タイプを新規作成します。これらは通常、開発システム上で作成し、準備が整ったら開発システムから管理システムと配信システムに移行します。

この章には次の項が含まれます。

- 第15.1項「AssetMakerユーティリティ」

- 第15.2項「ベーシック・アセット・タイプの作成」

- 第15.3項「ベーシック・アセット・タイプの削除」

15.1 AssetMakerユーティリティ

AssetMakerは、新しいベーシック・アセット・タイプを作成する際に使用するユーティリティです。

最初に、ベーシック・アセット・タイプをWebCenter Sitesの外で定義します。それには、AssetMakerのXMLタグを使用して、アセット記述子ファイルというxmlファイルをコーディングします。アセット記述子ファイルでは、新しいアセット・タイプのプロパティが定義されます。プロパティという用語は、データベース表の列とWebCenter Sitesの入力フォームのフィールドの両方を意味します。

次に、ファイルをWebCenter SitesにアップロードしてAssetMakerで2つのアイテムを作成します。1つは、新しいアセット・タイプのデータベース表、もう1つは、新しいタイプのアセットで作業(作成、編集、コピーなど)する際に使用するフォームを生成するWebCenter Sitesエレメントです。図15-1に、データベース表のフォーム(この例のコンテンツ入力フォームなど)との関係、およびフォームがレンダリングされる際に列がフィールドとして認識される方法を示します。

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

- 第15.1.1項「AssetMakerの仕組み」

- 第15.1.2項「アセット記述子ファイル」

- 第15.1.3項「アセット・タイプのデータベース表の列」

- 第15.1.4項「アセット・タイプに対応したエレメントとSQL文」

15.1.1 AssetMakerの仕組み

AssetMakerを使用して新しいベーシック・アセット・タイプを作成するには、次の4つの一般的な手順に従います。

1. アセット記述子ファイルをコーディングします。
この章では、アセット記述子ファイルとそのコーディングについて説明します。Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスには、すべてのAssetMakerのタグを説明している情報があります。

2. ファイルをアップロードします。
アセット記述子ファイルをアップロードする際に、AssetMakerによってAssetType表に行が作成され、その行にアセット記述子ファイルがコピーされます。

3. 表を作成します。
「アセット表の作成」ボタンをクリックすると、AssetMakerによって次の操作が実行されます。

- アセット記述子ファイルを解析します。

- 該当するタイプのアセットに対応するプライマリ記憶域表を作成します。表の名前は、アセット記述子ファイルで特定されたアセット・タイプの名前と一致します。各列のデータ型もファイルに記述される文で定義されます。
アセット記述子ファイルで定義された列に加えて、WebCenterが正常に機能するために必要なデフォルトの列が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表に配置されます。

WebCenter Sitesをこのタイプのアセット(作成、編集、調査など)で稼働させる場合、AssetMakerによってAssetType表に配置されているアセット記述子ファイルが解析され、このフォームがアセット・タイプに固有になるよう、WebCenter Sitesにその値が渡されます。アセット記述子ファイル内の文により、フィールドの入力タイプが決まり、フィールドの長さの制限が指定され、フィールドを検索フォームと検索結果フォームに表示するかどうかが決まります。

アセット・タイプを作成して使用できるようにするには、このアセット・タイプを使用する必要のあるサイトでのアセット・タイプの有効化やスタート・メニューのショートカットの作成など、いくつかの構成手順を実行しておく必要があります。

図15-2のフロー・チャートには、AssetMakerの仕組みや、ベーシック・アセット・タイプが作成される際に使用するデータベース表がまとめてあります。

図15-1 アセット・タイプ: データベース表とWebCenter Sitesのフォーム

図15-2 AssetMakerの仕組み

15.1.2 アセット記述子ファイル

AssetMaker XMLタグを使用して、システムに設計するアセット・タイプを定義するアセット記述子ファイルをコーディングします。

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

- 第15.1.2.1項「アセット記述子ファイルとは」

- 第15.1.2.2項「フォーマットと構文」

- 第15.1.2.3項「AssetMakerのタグの概要」

15.1.2.1 アセット記述子ファイルとは

アセット記述子ファイルとは、開発者がAssetMakerのタグを使用してベーシック・アセット・タイプを定義した有効なXML文書のことです。アセット記述子ファイルは、次の2つの事項を行います。

- データ構造の観点からアセット・タイプを説明します。データベース表名、列名、列のデータ型、WebCenter Sitesフォームのフィールド・サイズを指定します。

- 指定されたタイプのアセットをユーザーが操作する際に、WebCenter Sitesによって表示されるHTMLフォームの書式設定を行います。HTMLフォームの書式設定とは、フォーム上のフィールドに名前を付け、必要なフォーマットでフィールド(チェック・ボックス、ラジオ・ボタン、ドロップダウン・リストなど)を表示し、フィールドの仕様(テキスト・フィールドに入力できる文字数など)を指定することなどです。

AssetMakerはアセット記述子ファイルを使用して、新しいアセット・タイプのデータベース表を作成します。指定されたタイプのアセットをコンテンツ・プロバイダが操作(作成や編集など)すると、AssetMakerはアセット記述子ファイルを解析し、ファイル内のデータを使用して、WebCenter Sitesが表示するフォームをカスタマイズします。

注意:

参照用に、AssetMakerのサンプル記述子コードがWebCenter Sitesインストール媒体に提供され、「Samples」フォルダに格納されます。同じフォルダには、サンプル記述子ファイルを説明するreadme.txtファイルが格納されています。

15.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>

アセット記述子ファイルのタグの概要については、ガイドのこの項に記載されています。タグとそのパラメータの詳細情報は、サンプル・コードとともにOracle Fusion Middleware WebCenter Sitesタグ・リファレンスに記載されています。

15.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に設定しないでください。

これらのタグとそのパラメータの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスのAssetMakerのタグに関する項を参照してください。その項には、STORAGE TYPE、INPUTFORM TYPEおよびSEARCHFORM TYPEの各パラメータ間の依存性や制限についても記載されています。

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

AssetMakerにより新しいアセット・タイプに対してデータベース表が作成されると、アセット記述子ファイルのPROPERTYタグで定義されたすべてのプロパティに対して列が作成され、その基本的な機能についてWebCenter Sitesで必要となるデフォルトの列が作成されます。各アセット・タイプの表内のデフォルトの列のリストについては、第11.2.4.2項「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください。

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

- 第15.1.3.1項「ソース列: 特殊な場合」

- 第15.1.3.2項「列の記憶域のタイプ」

- 第15.1.3.3項「フィールドの入力タイプ」

- 第15.1.3.4項「標準アセット・フィールドのデータ型」

15.1.3.1 ソース列: 特殊な場合

すべてのアセット・タイプ表には、source列を入れることも可能です。WebCenter Sitesには、Source表に行を追加する際に使用する「管理」タブに、Source表と「ソース」フォームが用意されています。この機能を使用して、アセットが最初に作成された場所を特定できます。たとえば、Burlington Financialのサンプル・サイトではSourceを使用して記事アセットを提供したワイヤー・フィード・サービスを特定します。

ただし、前述の表に記載された列とは異なり、source列はAssetMakerによるアセット・タイプ表の作成時に自動的に作成されません。ソース列を表に追加してアセット・フォームに表示させるには、そのPROPERTYの説明をアセット記述子ファイルに追加する必要があります。例については、第15.2.3.2項「例: ソース列とフィールドの追加」を参照してください。

15.1.3.2 列の記憶域のタイプ

STORAGE TYPEパラメータは列のデータ型を指定します。このデータ型は、futuretense.iniファイルに格納されたWebCenter Sitesデータベース・プロパティによって定義されています。

次の表は、アセット・タイプの表の列に対応できるデータ型を示しています。

表15-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

BLOB

cc.blob

LONGVARCHAR

cc.bigtext

15.1.3.3 フィールドの入力タイプ

INPUT TYPEパラメータは、WebCenter Sitesのフォームにデータが表示される際にフィールドへ入力する方法を指定します。次の表は、すべての入力タイプを示しています。フィールドへの入力タイプは、列のデータ型に対応している必要があることに注意してください。

表15-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など、どのような記憶域のタイプでも指定できます。

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

WebCenter Sitesの標準アセット・フィールドの外観をカスタマイズできます。その他の変更内容はすべて下記のとおりフィールドのタイプに対応しています。

- すべての標準フィールド。表示名を変更できます。

- システム・フィールドではない標準フィールド。次の例外を除いて、データ型を変更しないでください。例外: データ型がVARCHARの場合には、その長さのみを変更できます。

- システム・フィールド。データ型(VARCHARタイプのフィールドの長さも含めて)を変更しないでください。
次の表は、標準フィールドのデータ型を示しています(フィールドがシステム・フィールドであるかどうかも示しています)。

表15-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

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

アセット記述子ファイルをアップロードした後、エレメントを「登録」します。エレメントを登録すると、AssetMakerによりAssetStubElementCatalog表のエレメントがElementCatalog表内のこのアセット・タイプに対応するディレクトリにコピーされます。

さらに、このタイプのアセットに対する「簡易検索」フォームと「詳細検索」フォームに、WebCenter Sites検索を実装する複数のSQL文がコピーされます。

必要に応じて、SQL文、アセット・タイプ固有のエレメント、また場合によってはAssetStubElementCatalog表のエレメントをカスタマイズできます。

注意:

いかなる状況においても、その他のWebCenter Sitesエレメントを変更しないでください。

エレメントのカスタマイズの詳細は、第15.2.9項「手順7: (オプション)アセット・タイプのエレメントのカスタマイズ」を参照してください。

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

- 第15.1.4.1項「エレメント」

- 第15.1.4.2項「SQL文」

15.1.4.1 エレメント

AssetMakerによって、次のネーミング規則に従って新しいアセット・タイプのエレメントがElementCatalog表に格納されます。

OpenMarket/Xcelerate/AssetType/YourNewAssetType

たとえば、サンプル・アセット・タイプImageFileのエレメントは、次の場所にあります。

OpenMarket/Xcelerate/AssetType/ImageFile

次の表にAssetMakerによって各アセット・タイプについてコピーされたエレメントを示します。

表15-4 AssetMakerのエレメント

エレメント

説明

ContentForm

このタイプのアセットに対する「新規」フォームと「編集」フォームをレンダリングします。

この機能が起動されると、AssetMakerによってアセット記述子ファイルでINPUTFORM文を使用してこれらのフォームが書式設定されます。

ContentDetails

このタイプのアセットに対する「調査」フォームを書式設定します。

この機能が呼び出されると、アセット記述子ファイルでINPUTFORM文を使用してこれらのフォームがカスタマイズされます。

SimpleSearch

このタイプのアセットに対する「簡易検索」フォームをレンダリングします。

この機能が呼び出されると、AssetMakerでは、アセット記述子ファイル内のSEARCHFORM文を使用して、これらのフォームを書式設定します。

SearchForm

このタイプのアセットに対する「詳細検索」フォームを書式設定します。

この機能が呼び出されると、AssetMakerでは、アセット記述子ファイル内のSEARCHFORM文を使用して、これらのフォームを書式設定します。

AppendSelectDetails

「詳細検索」フォームの個々のフィールドにSQL問合せを作成します。

「詳細検索」フォームがレンダリングされると、アセット記述子ファイルでSEARCHFORM文を使用してそのフォームがカスタマイズされます。

AppendSelectDetailsSE

システムで外部の検索エンジンが使用されると、「詳細検索」フォームの個々のフィールドでSQL文が作成されます。

この機能が呼び出されると、アセット記述子ファイルでSEARCHFORM文を使用してSQL問合せが作成されます。

IndexAdd

IndexAddエレメントとIndexReplaceエレメントは、検索エンジンの使用時に検索エンジンで索引付されるフィールド(列)を設置します。デフォルトでは、標準フィールドのみが索引付されます。その他のフィールドを索引付するには、これらのフォームをカスタマイズする必要があります。詳細は、第15.2.9項「手順7: (オプション)アセット・タイプのエレメントのカスタマイズ」を参照してください。

IndexReplace

IndexAddの説明を参照してください。

Tile

「検索結果」ページを書式設定します。このページには、このタイプのアセットに対して、検索基準に適合するアセットが示されています。

このページがレンダリングされると、アセット記述子ファイルでSEARCHRESULTS文を使用してこの結果が表示されます。

LoadTree

このタイプのアセットが、「サイト・プラン」タブ以外の、ツリーの任意のタブに表示される際の外観を決定します。

LoadSiteTree

このタイプのアセットが「サイト・プラン」タブに表示される際の外観を決定します。

PreUpdate

データベースに書き込む機能が完了する前にコールされます。つまり、アセットが保存される前の作成、編集、削除またはXMLPostの機能が稼働中に、このエレメントがコールされます。

このエレメントは、アセット記述子ファイルからは何も入力しません。ただし、直接カスタマイズできます。

PostUpdate

データベースへの書込みが終了した後でコールされます。つまり、XMLPostでアセットが作成、編集、削除またはインポートされた後、このエレメントがコールされます。

このエレメントをカスタマイズできます。

15.1.4.2 SQL文

AssetMakerによって、次のネーミング規則に従ってSQL文がSystemSQL表に格納されます。

OpenMarket/Xcelerate/AssetType/YourNewAssetType

たとえば、サンプル・アセット・タイプImageFileのエレメントは、次の場所にあります。

OpenMarket/Xcelerate/ImageFile

次の表は、AssetMakerによって作成されるSQLエレメントを示しています。

表15-5 SQLのエレメント

文

説明

SelectSummary

このタイプのアセットに対する「簡易検索」フォームと「詳細検索」フォームで使用される問合せを定義するSQL文です。

SelectSummarySE

使用されません。

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

新しいアセット・タイプの作成にかかる時間の長さは、アセット・タイプの複雑さに応じて幅広い範囲に及びます。

単純なアセット・タイプでは、1つの単純なアセット記述子ファイルをコーディングしてアップロードする必要があります。より複雑なアセット・タイプでは、アセット・タイプに対して作成されたエレメント内のコードを変更するか、ドロップダウン・リストに表示する情報を保持するためにデータベース表を追加する必要があります。

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

- 第15.2.1項「新しいアセット・タイプの作成と構成の概要」

- 第15.2.2項「始める前に」

- 第15.2.3項「手順1: アセット記述子ファイルのコーディング」

- 第15.2.4項「手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード」

- 第15.2.5項「手順3: アセット表の作成」

- 第15.2.6項「手順4: アセット・タイプの構成」

- 第15.2.7項「手順5: サイトのアセット・タイプの有効化」

- 第15.2.8項「手順6: アセット記述子ファイルの微調整」

- 第15.2.9項「手順7: (オプション)アセット・タイプのエレメントのカスタマイズ」

- 第15.2.10項「手順8: (オプション)サブタイプの構成」

- 第15.2.11項「手順9: (オプション)アソシエーション・フィールドの構成」

- 第15.2.12項「手順10: (オプション)カテゴリの構成」

- 第15.2.13項「手順11: (オプション)ソースの構成」

- 第15.2.14項「手順12: (条件付き)MIMEタイプの追加」

- 第15.2.15項「手順13: (オプション)索引付き検索を有効にするための検索エレメントの編集」

- 第15.2.16項「手順14: アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)」

- 第15.2.17項「手順15: アセット・タイプのテンプレートのコーディング」

- 第15.2.18項「手順16: 他のシステムへのアセット・タイプの移動」

15.2.1 新しいアセット・タイプの作成と構成の概要

新しいアセット・タイプの作成と構成のプロセスに関する概要は、次のとおりです。この章では、下記の場合を除き、各手順を説明してあります。

1. アセット記述子ファイルをコーディングします。第15.2.3項「手順1: アセット記述子ファイルのコーディング」を参照してください。

2. WebCenter Sitesの「管理」タブでAssetMakerを使用して、アセット記述子ファイルをアップロードします。第15.2.4項「手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード」を参照してください。

3. データベース表を作成し、アセット・タイプのエレメントをAssetStubElementCatalog表からElementCatalog表の適切なディレクトリにコピーして登録します。第15.2.5項「手順3: アセット表の作成」を参照してください。

4. アセット・タイプを構成します。第15.2.6項「手順4: アセット・タイプの構成」を参照してください。

5. アセット・タイプをアセットの開発に使用しているサイトで有効にし、「スタート・メニュー」のショートカットを作成してアセット・タイプを使用できるようにします。第15.2.7項「手順5: サイトのアセット・タイプの有効化」を参照してください。

6. 「新規」、「編集」、「調査」、「検索」および「検索結果」の各フォームを調べます。必要に応じて、アセット記述子ファイルを微調整してアセット・タイプのエレメントを再登録します。第15.2.8項「手順6: アセット記述子ファイルの微調整」を参照してください。

7. (オプション)必要に応じて、アセット・タイプのエレメントをカスタマイズします。第15.2.9項「手順7: (オプション)アセット・タイプのエレメントのカスタマイズ」を参照してください。

8. (オプション)新しいアセット・タイプに「サブタイプ」エントリを追加します。第15.2.10項「手順8: (オプション)サブタイプの構成」を参照してください。

9. (オプション)新しいアセット・タイプにアセットの「アソシエーション」フィールドを作成します。第15.2.11項「手順9: (オプション)アソシエーション・フィールドの構成」を参照してください。

10. (オプション)新しいアセット・タイプに「カテゴリ」エントリを追加します。第15.2.12項「手順10: (オプション)カテゴリの構成」を参照してください。

11. (オプション)新しいアセット・タイプに「ソース」エントリを追加します。第15.2.13項「手順11: (オプション)ソースの構成」を参照してください。

12. (オプション)新しいアセット・タイプに「MIMEタイプ」を追加します。第15.2.14項「手順12: (条件付き)MIMEタイプの追加」を参照してください。

13. (オプション) WebCenter Sitesデータベース検索ユーティリティではなく検索エンジンを使用して検索フォームの背後にある論理を実行し、新しいアセット・タイプにそれを使用する場合、検索エレメントを編集して索引付された検索機能を有効にします。第15.2.15項「手順13: (オプション)索引付き検索を有効にするための検索エレメントの編集」を参照してください。

14. Contributorインタフェースのナビゲーション・ツリー(「サイト・ツリー」、「コンテンツ・ツリー」および「ワーク」ツリー)でアセット・タイプを表すアイコンを作成して割り当てます。第15.2.16項「手順14: アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)」を参照してください。

15. このタイプのアセットのテンプレートをコーディングします。第15.2.17項「手順15: アセット・タイプのテンプレートのコーディング」および第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

16. アセット・タイプを管理や配信など他のシステムに移動します。第15.2.18項「手順16: 他のシステムへのアセット・タイプの移動」を参照してください。これにより、管理者は、ワークフローの設定、スタート・メニューの項目の作成など、アセット・タイプ作成の最後の手順を完了できます。

15.2.2 始める前に

アセット記述子ファイルのコーディングを開始する前に、設計プランを立て、開発システムを設定する必要があります。詳細は、次の各項を参照してください。

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

- 第15.2.2.1項「アセット・タイプの設計の立案」

- 第15.2.2.2項「開発システムの設定」

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

必ずアセット・タイプを紙上で設計してから、アセット記述子ファイルのコーディングを開始してください。下記のような詳細を考慮します。

- 必要なフィールドは何か。
通常、情報を便利な単位にまとめて、使用するフィールド数を最小限にします。その単位を決定する際には、オンライン・サイトに表示する予定の情報と、データを入力するコンテンツ・プロバイダのデータ入力の必要性の両方を考慮します。

- 各フィールドに対する適切なデータ型は何か。

- オプションのあるフィールドの場合、どのようにオプションを表示するか。アセット記述子ファイルでコーディングされた静的リストにするか、または有効なオプションを記載した参照表にするか。

- どのWebCenter Sitesの機能を使用して、このタイプのアセットを編成したりカテゴリ分けするか。(ソース、カテゴリ、アセットのアソシエーションなど。)それぞれについて、その名前、および管理システムとオンライン・サイトの設計の両方で使用する方法を決定します。

- サイト設計の実装にはこのタイプのアセットに、パブリッシュ先の公開ターゲットに基づいて異なるデフォルトのテンプレートを使用する必要があるのか。必要な場合には、「サブタイプ」機能を使用する必要があります。このタイプのアセットに必要なサブタイプの名前を決定します。

15.2.2.2 開発システムの設定

また、開始する前に必ず開発システムを設定してください。このような準備手順の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- 適切なサイトを作成します。

- 管理者権限を持つ管理者専用のユーザー名を作成し、開発システムのすべてのサイトでそのユーザー名を有効にします。(テーブル・エディタACLがユーザー名に割り当てられていることを確認してください。確認できないと、新しいアセット・タイプの作成はできなくなります。)

注意:

管理者権限がないと、「管理」タブにアクセスできず、この章に記載した手順を実行できません。便宜上、ユーザー名に「デザイナ」ロールと「GeneralAdmin」ロールを割り当てます。そうすることで、すべてのタブと、サンプル・サイト内のアセットへのすべての既存の「スタート・メニュー」ショートカットにアクセスできるようになります。

15.2.3 手順1: アセット記述子ファイルのコーディング

第15.1.2項「アセット記述子ファイル」で説明されているとおり、次に示すのがアセット記述子ファイルの基本的な書式です。

<?xml version="1.0" ?>
<ASSET NAME="assetName"...>
<PROPERTIES>
<PROPERTY.../>
<STORAGE.../>
<INPUTFORM.../>
<SEARCHFORM.../>
<SEARCHRESULTS.../>
</PROPERTY>
<PROPERTY... />
<STORAGE.../>
<INPUTFORM.../>
<SEARCHFORM.../>
<SEARCHRESULTS.../>
</PROPERTY>
</PROPERTIES>
</ASSET>

アセット記述子ファイルをコーディングするには、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスのAssetMakerのタグに関する項を参照し、その説明に従ってタグを使用してファイルをコーディングします。ファイルをコーディングするにはOracle WebCenter Sites ExplorerのネイティブXMLエディタを使用するか、その他のXMLエディタを使用します。

標準アセット・フィールドをアセット記述子ファイルに追加すると、標準アセット・フィールドの外観をカスタマイズできます。フィールドの記憶域タイプの変更は、条件付きとなります。たとえば、フィールドがシステム・フィールドの場合、その記憶域タイプは変更できません。標準フィールドのリスト、それらの記憶域タイプ、および記憶域タイプに許可された変更の詳細は、第15.1.3.4項「標準アセット・フィールドのデータ型」を参照してください。

この項では、サンプルのアセット記述子ファイルとコーディング固有のプロパティの例を示します。

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

- 第15.2.3.1項「サンプルのアセット記述子ファイル: ImageFile.xml」

- 第15.2.3.2項「例: ソース列とフィールドの追加」

- 第15.2.3.3項「アップロードの例1: 標準アップロード・フィールド」

- 第15.2.3.4項「アップロードの例2: テキスト・ボックス・フィールド」

15.2.3.1 サンプルのアセット記述子ファイル: ImageFile.xml

Burlington Financialのサンプル・サイトをシステムにインストールすると、AssetType表にImageFile.xmlアセット記述子ファイルが表示されます。Oracle WebCenter Sites Explorerを起動してファイルを開くか、次のコードで調べます。

<!-- 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>

このアセット記述子ファイルを調べて、システムにBurlington Financialがインストールされている場合には、WebCenter Sitesを起動してBurlington Financialサイトを選択します。WebCenter Sitesフォームでimagefileアセット・タイプを調べ、アセット記述子ファイルと比較します。

ImageFileアセット記述子ファイルについて、次の事項に注意してください。

- ASSETタグにより、DEFDIRパラメータに対応する値が導き出されます。すべてのアセット表にはデフォルトで最低2つのURL列(アップロード・フィールド)があるため、どの新しいアセット・タイプについてもデフォルトの記憶域ディレクトリ(defdir)の値を設定する必要があります。(imagefileアセット・タイプには2つの追加URL列、urlpictureとurlthumbnailがあります。)
defdir値の設定には、ASSETタグのDEFDIRパラメータを使用するか、AssetMakerの「アセット表の作成」フォームの「defdir」フィールドを使用します。

注意:

「アセット表の作成」フォームで設定されたdefdirは、アセット記述子ファイルで設定されているdefdirをオーバーライドします。

URL列の詳細は、第12.2.3項「WebCenter SitesのURLフィールドを使用した間接的なデータ格納」を参照してください。

- AssetMakerによってアセット・タイプのデータベース表に作成されたデフォルトの列のいずれにも、PROPERTY文はありません。それらの列は、第11.2.4.2項「ベーシック・アセット・タイプのデータベース表のデフォルトの列」に一覧表示されています。

- SEARCHFORM文を備えたすべてのプロパティに、一致するSEARCHRESULTS文が備わっているわけではありません。つまり、「詳細検索」フォームにフィールドを設置する場合、そのフィールドからのデータを「検索結果」フォームに表示する必要はないということです。

15.2.3.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>

15.2.3.3 アップロードの例1: 標準アップロード・フィールド

「参照」ボタンを備えたアップロード・フィールドを作成するには、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に制限されています。

15.2.3.4 アップロードの例2: テキスト・ボックス・フィールド

(ファイルの選択に使用する「参照」ボタンでなく)テキストを入力できるテキスト・ボックスを使用してアップロード・フィールドを作成するには、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>

15.2.3.5 アップロードの例2: テキスト・ボックス・フィールド

(ファイルの選択に使用する「参照」ボタンでなく)テキストを入力できるテキスト・ボックスを使用してアップロード・フィールドを作成するには、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>

15.2.3.6 アップロードの例3: 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フィールドが破損する恐れがあります。

15.2.3.7 アップロードの例4: バイナリ・ファイルをアップロードするフィールド

次のコードは、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>

15.2.3.8 例: パス、ファイル名、開始日および終了日の有効化

パス、ファイル名、開始日および終了日の列は特殊な例です。

AssetMakerにより、PROPERTY文を使用しないでパス、ファイル名、開始日および終了日の列が作成されます。ただし、アセット記述子ファイルにそれらの列に対するPROPERTY文を記述しないと、列は存在してもそれらのフィールドはアセット・フォームに表示されません。

これらの列について、次の事項に注意してください。

- 「パス」では、STORAGE TYPEをVARCHARに、LENGTHを255に設定する必要があります。

- 「ファイル名」では、STORAGE TYPEをVARCHARに、LENGTHを128に設定する必要があります。

- 「開始日」では、STORAGE TYPEをTIMESTAMPに設定する必要があります。

- 「終了日」では、STORAGE TYPEをTIMESTAMPに設定する必要があります。

注意:

これらの標準列のいずれかをアセット記述子ファイルに追加しても、記憶域タイプがこのリストに指定されているものと一致しない場合には、AssetMakerでアセット・タイプを作成できません。

例:

<PROPERTY NAME="path" DESCRIPTION="Path">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM DESCRIPTION="Path" TYPE="TEXT" LENGTH="255"/>
</PROPERTY>

15.2.3.9 例: 問合せを使用したドロップダウン・リストのオプションの取得

プロパティの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問合せによってデータベース表から返される項目をさらに制限するフィールドも示しています。

15.2.3.10 例: 問合せを使用したラジオ・ボタンのラベルの取得

プロパティのINPUTFORM TYPEがRADIOの場合、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>

15.2.3.11 例: 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入力タイプを使用して必要な数のフィールドをカスタマイズできますが、変更するフィールドごとに個別のエレメントを記述する必要があります。

15.2.4 手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード

アセット・タイプに対応したアセット記述子ファイルをコーディングした後、AssetMakerを使用してそれをアップロードして新しいエレメントを登録します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「管理」タブを選択します。

5. 「AssetMaker」を開いて、「新規追加」をクリックします。
「新規AssetMakerアセット・タイプの追加」フォームが表示されます。

6. 「名前」フィールド内をクリックして、新しいアセット・タイプの名前を入力します。このフィールドに入力する文字列は、アップロードするアセット記述子ファイルのASSET NAMEで指定された文字列と完全に一致している必要があります。

7. 「記述子ファイル」フィールドの隣にある「参照」ボタンをクリックして、アセット記述子ファイルを選択します。

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

AssetMakerでは、ファイルがAssetType表に入力され(つまり、アセット記述子ファイルがAssetType表のデフォルトのストレージ・ディレクトリにアップロードされ)、「アセット・タイプ」フォームが表示されます。

15.2.5 手順3: アセット表の作成

この手順は、前述の項の手順8(第15.2.4項「手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード」)からの続きです。

1. 「アセット表の作成」を選択します。

2. 「Defdir」フィールドの値を調べて、必要に応じて変更します。AssetMakerはこの値をアセット記述子ファイルから読み取ります。次のいずれかの条件がある場合には、このフィールドに値を入力する必要があります。

- アセット記述子のASSETタグに対応するDEFDIRパラメータを使用して値を入力しなかった場合。

- デフォルトのストレージ・ディレクトリを変更しようとする場合。これは、アセット・タイプを別のシステムに移行する際の典型的な状況です。

「「一般」カテゴリの追加」オプションを選択した場合は、AssetMakerによってCategory表に、新しいアセット・タイプに対応する行が1つ追加され、そのカテゴリにGeneralという名前が付けられます。

3. 「アセット表の作成」をクリックします。
AssetMakerでは、表が作成されます。

終了すると、次のような確認が表示されます。

4. 「アセット・エレメントの登録」を選択して、「アセット・エレメントの登録」ボタンをクリックします。
エレメントがAssetStubElementCatalog表からElementCatalog表のアセット・タイプのディレクトリにコピーされ、SQL文がSystemSQL表にコピーされます。終了すると、次のような確認が表示されます。

15.2.6 手順4: アセット・タイプの構成

AssetMakerで新しいアセット・タイプが作成されると(第15.2.4項「手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード」)、アイコンと新しいアセット・タイプを構成するための管理フォームも作成され、「管理」タブに配置されます。

次の構成手順を実行します。

1. 「管理」タブで、「アセット・タイプ」アイコンを展開します。

2. 「アセット・タイプ」で、新しいアセット・タイプを選択します。(リストに新しいアセット・タイプが表示されていない場合、右クリックし、コンテキスト・メニューから「リフレッシュ」を選択して、新しいアセット・タイプを選択します。)

3. 「編集」をクリックします。
次のフォームが表示されます。

4. (オプション)「説明」フィールド内をクリックして、必要に応じて変更します。このフィールドのテキストには、フォームのこのアセット・タイプに対してWebCenter Sitesで使用される名前とWebCenter Sitesインタフェースのリストが記述されています。デフォルトでは、「説明」はアセット記述子ファイルのASSET DESCRIPTION文の値に設定されています。

5. (オプション)「複数形」フィールド内をクリックして、必要に応じて変更します。このフィールドのテキストには、複数形でアセット・タイプを参照するのが適切な場合にWebCenter Sitesインタフェースで使用するテキストが記述されています。デフォルトでは、「複数形」はアセット記述子ファイルのASSET DESCRIPTION文の値に「s」を追加して設定されています。アセット記述子ファイルの複数形を独自で指定するには、ASSETタグのPLURALパラメータの値を設定します。

6. (オプション)子アセットに設定可能フィールド内をクリックして、必要に応じて変更します。デフォルトでは、このフィールドは「True」に設定されています。つまり、このアセット・タイプは別のアセット・タイプのアソシエーション・フィールドで子アセット・タイプである可能性があります。その名前は、「新規アソシエーションの追加」フォームの「子アセット」フィールドにあるアセット・タイプのリストに表示されます。

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

15.2.7 手順5: サイトのアセット・タイプの有効化

新しいエレメントがアセット・タイプにレンダリングするフォームを調べる前に、作業するサイトでアセットを有効にし、それに対して簡単な「スタート・メニュー」の項目を作成する必要があります。

アセット・タイプを有効にして、それらにスタート・メニューの項目を作成する手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

15.2.8 手順6: アセット記述子ファイルの微調整

新しいタイプの新しいアセットを作成し、「新規」、「編集」、「調査」および「検索」の各フォームを調べます。このタイプの新しいアセットを作成するには、ツールバーの「新規」をクリックし、前述の手順で作成した「スタート・メニュー」ショートカットを選択します。

フォームを調べた後、アセット記述子ファイルを変更する必要が生じることがあります。

次のいずれかの項目を比較的少ない手順で変更できます。

- アセット・タイプのWebCenter Sitesフォームに表示されるフィールドの並替え

- フィールド名(PROPERTY DESCRIPTIONの値)の変更

- INPUTFORM、SEARCHFORM、SEARCHRESULTSいずれかの文におけるなんらかの変更

前述のリストになんらかの変更を加える場合には、次の手順を実行します。

1. 第15.2.4項「手順2: アセット記述子ファイルのWebCenter Sitesへのアップロード」でアップロードしたアセット記述子ファイルを開いて変更するには、Oracle WebCenter Sites Explorerを使用します。

2. 変更を保存します。

3. アセット・タイプのエレメントを登録しなおします。

アセット・タイプのデータベース表の作成後は、そのスキーマを変更できません。次の変更内容は、スキーマの変更内容です。

- 列名(既存のPROPERTY文のNAMEパラメータ)の変更

- 列のデータ型(既存のPROPERTY文のSTORAGE TYPEまたはLENGTH)の変更

- 新しいプロパティ(新しいPROPERTY文)の追加。これにより表に新しい列が追加されます。

- プロパティ(既存のPROPERTY文)の削除。これにより表から列が削除されます。

したがって、前述のリストのいずれかの変更を実行する場合は、まずアセット・タイプを削除し、アセット記述子ファイルを変更し、アセット・タイプを再び作成します。

AssetStubElementCatalog表からElementCatalog表のアセット・タイプのディレクトリにコピーしたエレメントをカスタマイズした場合、変更内容はエレメントを再登録した時点で上書きされることに注意してください。

15.2.9 手順7: (オプション)アセット・タイプのエレメントのカスタマイズ

コンテンツ管理システムでアセット・タイプのエレメントをカスタマイズする方法は2つあります。

- 特定のアセット・タイプに固有な変更が必要な場合、Oracle WebCenter Sites Explorerを使用して、そのアセット・タイプのエレメントをElementCatalog表で変更できます。エレメントの変更の詳細は、第15.2.9.1項「PreUpdateエレメントとPostUpdateエレメントについて」を参照してください。

- すべてのタイプのアセットに同じ変更が必要な場合、Oracle WebCenter Sites Explorerを使用して、AssetStubElementCatalog表のソース・エレメントを変更してから、アセット・タイプを作成します。その方法では、一度だけカスタマイズする必要があります。

注意:

AssetStubElementCatalog表のソース・エレメントのカスタマイズが必要な場合もありますが、サポートされていません。スタブ・エレメントをカスタマイズする場合には、次の条件で上書きされることを考慮してください。

- スタブ・エレメントを変更する場合には、新しい変更内容を取得する必要があるすべてのアセット・エレメントを再登録する必要があります。アセット・エレメントの再登録では、AssetMakerはエレメントの新しいコピーをAssetStubElementCatalog表からElementCatalog表内のアセット・タイプのディレクトリに移動し(パスはElementCatalog\OpenMarket\Xcelerate\AssetType)、このプロセスで既存のエレメントを上書きします。AssetTypeディレクトリにあるカスタマイズ済のエレメントは上書きされます。

- WebCenter Sitesアップグレード・プロセスでは、通常、新しいエレメントはAssetStubElementCatalog表にインストールされます。スタブ・エレメントのコードの変更は、アップグレード後にアセット・タイプを再登録すると上書きされます。

すべてのカスタマイズのトラッキングについては、常に細心の注意を払ってください。その方法で、必要に応じて作業を作成しなおすことができます。

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

アセットで実行できるアクションや手順を機能と呼びます。たとえば、新規、編集および削除は、Adminインタフェースと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インタフェースで、「新規」、「編集」、「削除」の各機能を起動するとき、アセットがSites Desktopに保存されるとき、またはアセットがXMLPostを使用してインポートされるときに、常にコールされます。操作がPreUpdateエレメントとPostUpdateエレメントによって実行されるかどうかは、それらのエレメントのコード方法によります。デフォルトでは、アクションなしに設計されています。

PreUpdateエレメントとPostUpdateエレメントには、次のパスで、Oracle WebCenter Sites Explorerからアクセスできます。

ElementCatalog\OpenMarket\Xcelerate\AssetType

表15-6は、updatetype変数の値について定義しています。

注意:

Adminインタフェースで新規アセットまたは編集済のアセットを保存すると、PreUpdateエレメントは2回コールされます。

最初のコールは、「新規」フォームまたは「編集」フォームがレンダリングされる前に実行されます。2回目のコールは、「新規」フォームまたは「編集」フォームで「保存」がクリックされた後に行われますが、この時点でWebCenter Sitesではアセット情報がデータベースに書き込まれていません。

前述の条件により、新規機能または編集機能が呼び出されると、PreUpdateによる操作を1箇所または数箇所で実行できるようになります。それは、エレメントのupdatetype変数の値に応じて、「新規」フォームか「編集」フォームがレンダリングされる前、アセット情報がデータベースに書き込まれる前、またはその両方のタイミングで発生します。

表15-6 UpdateType変数の値

updatetype =

説明

setformdefaults

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが「新規」機能を起動した場合:

- PreUpdateエレメントは、「新規」フォームがレンダリングされる前にコールされます。

- PostUpdateでは、setformdefaultsはupdatetype変数に対する適切な値ではありません。

create

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが新しいアセットを保存した場合:

- PreUpdateエレメントは、新しいアセットがデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、新しいアセットがデータベースに書き込まれた後でコールされます。

editfront

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが「編集」機能を起動した場合:

- 「編集」フォームがレンダリングされる前に、PreUpdateエレメントがコールされます。

- PostUpdateでは、editfrontはpdatetype変数に対する適切な値ではありません。

edit

Adminインタフェースで、またはContributorインタフェースのフォーム・モードでユーザーが編集済のアセットを保存した場合:

- PreUpdateエレメントは、編集内容がデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、編集内容がデータベースに書き込まれた後でコールされます。

delete

Adminインタフェースからユーザーがアセットを削除した場合:

- PreUpdateエレメントは、WebCenter Sitesによってアセットが削除される前にコールされます。

- PostUpdateエレメントは、WebCenter Sitesによってアセットが削除された後で実行されます。

remotepost

ユーザーがXMLPost機能を呼び出してアセットをインポートする場合:

- アセットがインポートされる前に、PreUpdateエレメントがコールされます。

- アセットがインポートされた後に、PostUpdateエレメントがコールされます。

MSWord

Microsoft Wordで作成または編集されたアセットをSites Desktopのユーザーが保存した場合:

- 新しいアセットまたは編集済のアセットがデータベースに書き込まれる前に、PreUpdateエレメントがコールされます。

- 新しいアセットまたは編集済のアセットがデータベースに書き込まれた後に、PostUpdateエレメントがコールされます。

InSite

Webモードから保存された場合、servicesUpdateTypeと呼ばれる変数があり、ユーザーの操作に応じて作成、編集または削除を実行します。

表15-7は、servicesUpdateType変数の値について定義しています。

表15-7 servicesUpdateType変数の値(Contributorインタフェース)

servicesUpdateType =

説明

create

Contributorインタフェースでユーザーが新しいアセットを保存した場合:

- PreUpdateエレメントは、新しいアセットがデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、新しいアセットがデータベースに書き込まれた後でコールされます。

edit

Contributorインタフェースでユーザーが編集済のアセットを保存した場合:

- PreUpdateエレメントは、編集内容がデータベースに書き込まれる前にコールされます。

- PostUpdateエレメントは、編集内容がデータベースに書き込まれた後でコールされます。

delete

Contributorインタフェースでユーザーがアセットを削除した場合:

- PreUpdateエレメントは、WebCenter Sitesによってアセットが削除される前にコールされます。

- PostUpdateエレメントは、WebCenter Sitesによってアセットが削除された後でコールされます。

15.2.10 手順8: (オプション)サブタイプの構成

AssetMakerで設計するベーシック・アセット・タイプの場合、サブタイプとはアセットがレンダリングされる方法に基づいたアセット・タイプのサブクラスのことです。サブタイプを使用して、各公開ターゲットでそのタイプおよびサブタイプのアセットに対する個々のデフォルトの承認テンプレートを定義できます。

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

- 第15.2.10.1項「サブタイプの追加」

- 第15.2.10.2項「サブタイプの削除」

15.2.10.1 サブタイプの追加

サブタイプを作成する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」オプションを開きます。

2. 「アセット・タイプ」オプションの下で、サブタイプの作成対象とするアセット・タイプを選択します。

3. 「サブタイプ」オプションを選択します。
次のような「サブタイプ」フォームが表示されます。

4. 「新規サブタイプの追加」をクリックします。

5. 次のフォームで、「名前」列の最初のフィールド内をクリックし、サブタイプの名前を入力します。

6. 「サイト」列の対応するフィールドで、このサブタイプに必要なサイト名を選択します。

7. 最大5つのサブタイプまでこれらの手順を繰り返します。

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

15.2.10.2 サブタイプの削除

サブタイプを削除する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」オプションを開きます。

2. 「アセット・タイプ」オプションの下で、サブタイプの作成対象とするアセット・タイプを選択します。

3. 「サブタイプ」オプションを選択します。

4. 「サブタイプ」フォームで、「削除」(ゴミ箱の)アイコンをクリックします。

5. 「サブタイプの削除」をクリックします。

15.2.11 手順9: (オプション)アソシエーション・フィールドの構成

アソシエーションについては、第11.2項「ベーシック・アセット・モデル」を参照してください。要するに、アソシエーションとは親子関係を説明する定義済のアセット・タイプ固有の関係、または個々のアセットやアセットのサブタイプ間のリンクのことです。テンプレート・エレメントをコーディングする際に、これらの関係の名前を使用して個々のアセットやサブタイプを特定するため、オブジェクト名でオブジェクトを参照する必要はありません。

たとえば、Burlington Financialサンプル・サイトではイメージファイル・アセットが記事アセットに関連付けられています。テンプレート・エレメントは、アセットの名前ではなくアソシエーションの名前で関連付けられたイメージファイル・アセットを抽出するようにコーディングされます。その場合、記事に異なるイメージファイルを選択すると、テンプレートは新しいイメージファイルを表示するため、テンプレートをコーディングしなおす必要はありません。

アソシエーションは、アセット・フォームのフィールドとして表されます。これらのフィールドはアセット記述子ファイルからは作成されません。かわりに、「管理」タブの「アセットのアソシエーション」フォームを使用します。

Burlington Financialサンプル・サイトのアソシエーション・フィールドの例には、記事アセットとイメージファイル・アセットの間のメイン・イメージ・アソシエーションとティーザー・イメージ・アソシエーションが含まれています。Burlington Financialの記事アセットを作成する際には、「メイン・イメージ」フィールドと「ティーザー・イメージ」フィールドからイメージ・アセットを選択できます。

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

- 第15.2.11.1項「アソシエーション・フィールドの追加」

- 第15.2.11.2項「アソシエーション・フィールドの削除」

15.2.11.1 アソシエーション・フィールドの追加

アソシエーション・フィールドを追加する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」を選択します。

2. 「アセット・タイプ」オプションで、アソシエーションを作成するアセット・タイプを選択します。

3. 選択したアセット・タイプで、「アセットのアソシエーション」→「新規追加」を選択します。
次のような「新規アソシエーションの追加」フォームが表示されます。

4. 「名前」フィールド内をクリックして、スペース、小数点または引用符を使用せずにアソシエーション・フィールド名を入力します。

5. 「説明」フィールド内をクリックして、フィールドの簡単な説明を入力します。WebCenter Sitesでは、新しいアセット・フォームに表示される際このフィールドに入力したテキストがフィールド名として使用されるため、説明は簡潔にします。

6. 「子アセット」フィールド内をクリックして、このフィールドに表示されるアセット・タイプの種類を選択します。(「子アセット」フィールドと呼ばれるのは、アソシエーションがアセット間の親子関係を作成しているためです。)このフィールドでは、テンプレートやページ・アセット・タイプを指定できません。

7. このアソシエーションに対する1つまたは複数のサブタイプを選択するには、「サブタイプ」フィールド内のそのサブタイプを強調表示します。複数のサブタイプを選択するには、選択内容をマウスでクリックしながら[Ctrl]キーを押します。

8. このアセット・アソシエーションに対応する「依存性タイプ」を選択します。デフォルトでは、「存在」に設定されています。ここで指定された依存性タイプは、公開方法がサーバーに対してミラーの場合、承認システムで使用されます。依存性タイプの詳細は、第28.2項「依存性をログに記録するためのコーディングについて」を参照してください。

9. 「追加」をクリックします。
WebCenter Sitesでは、このアソシエーションの「アソシエーション」表に行が作成されます。この行で使用される名前は、手順4で「名前」フィールドに入力したテキストです。

15.2.11.2 アソシエーション・フィールドの削除

アソシエーション・フィールドを削除する前に、必ずのフィールドを使用するアセットはないか検索してフィールド内の値を消去します。そうしないと、アソシエーション・フィールドを削除した時点でそれらのアセットはアソシエーションを保持したままになりますが、WebCenter Sitesインタフェースには表示されなくなるため、それを変更できなくなります。

アソシエーション・フィールドを削除する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」を選択します。

2. 「アセット・タイプ」オプションで、アソシエーション・フィールドを削除するアセット・タイプを選択します。

3. 選択したアセット・タイプで、削除するアソシエーションを選択します。

4. 右のフォームで、「削除」をクリックします。

アソシエーション・フィールドは、このアセット・タイプのフォームには表示されなくなります。

15.2.12 手順10: (オプション)カテゴリの構成

カテゴリを使用して、サイト設計に対応した一部の表記規則に従ってアセット・タイプを編成できます。たとえば、Burlington Financialサンプル・サイトではカテゴリに基づいた問合せを使用して、オンライン・サイトの様々なセクションで選択する記事を決定できます。

すべてのベーシック・アセット・タイプに「カテゴリ」フィールド(列)がデフォルトで備わっていますが、それは必須フィールドではなく、使用する必要はありません。

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

- 第15.2.12.1項「カテゴリの追加」

- 第15.2.12.2項「カテゴリの削除」

15.2.12.1 カテゴリの追加

カテゴリを追加する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」を選択します。

2. 「アセット・タイプ」オプションで、カテゴリを作成するアセット・タイプを選択します。(たとえば、「記事」を選択します。)

3. 該当するアセット・タイプで、「カテゴリ」→「新規追加」を選択します。
次のフォームが表示されます。

4. 「説明」フィールド内をクリックして、カテゴリの簡単な説明を入力します。WebCenter Sitesではこのフィールドに入力したテキストがサイト・ツリーと、このタイプのアセットに対するフォームの「カテゴリ」フィールドのドロップダウン・リストで使用されるため、説明は簡潔にします。

5. 「カテゴリ・コード」フィールドに、新しいカテゴリの2文字コードを入力します。

6. 「追加」ボタンをクリックします。

7. 必要に応じて、手順2から6を繰り返し、このアセット・タイプのカテゴリの作成を終了します。

作成したカテゴリは、「新規」フォームと「編集」フォームの「カテゴリ」フィールドのドロップダウン・リストに表示されます。

15.2.12.2 カテゴリの削除

カテゴリを削除する手順は次のとおりです。

1. 「管理」タブで、「アセット・タイプ」を選択します。

2. 「アセット・タイプ」オプションで、カテゴリを削除するアセット・タイプを選択します。

3. そのアセット・タイプで、削除するカテゴリを選択します。

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

15.2.13 手順11: (オプション)ソースの構成

ソースは、システムのすべてのサイトのすべてのアセット・タイプに適用します。したがって、ソースを使用している場合、ソースを一度のみ追加する必要があります(各アセット・タイプに追加するのではなく)。

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

- 第15.2.13.1項「ソースの追加」

- 第15.2.13.2項「ソースの削除」

15.2.13.1 ソースの追加

ソースを作成する手順は次のとおりです。

1. 「管理」タブで、「ソース」→「新規追加」を選択します。

次のような「ソースの追加」フォームが表示されます。

2. 「ソース」フィールド内をクリックし、ソース名を入力します。

3. 「説明」フィールド内をクリックして、ソースの簡単な説明を入力します。WebCenter Sitesでは、アセットに対するフォームの「ソース」フィールドのドロップダウン・リストで、このフィールドに入力したテキストが使用されます。

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

ソースがSource表に書き込まれます。

5. アセット・タイプに必要な各ソースに対して、手順1から4を繰り返します。

15.2.13.2 ソースの削除

ソースを削除する手順は次のとおりです。

1. 「管理」フォームで、「ソース」を選択します。

2. 「ソース」オプションで、削除するソース名を選択します。

3. このソースのフォームで、「削除」をクリックします。

15.2.14 手順12: (条件付き)MIMEタイプの追加

MimeType表には、MIMEタイプのフィールドに表示できるMIMEタイプ・コードが保持されています。MimeType表をアセット記述子ファイルで参照する場合、アセットにMIMEタイプを追加する必要があります。

たとえば、イメージファイルとスタイルシートの両方のアセット・タイプで、横に「参照」ボタンのあるフィールドをアップロードしてあるとします。アップロード・フィールドでファイルを選択したら、「MIMEタイプ」フィールドから選択したファイルのMIMEタイプを指定します。

イメージファイル・アセット・タイプとスタイルシート・アセット・タイプの「MIMEタイプ」フィールドは、keyword列に基づいたMIMEタイプ・コードのMIMEタイプ表を問い合せます。

- keywordがstylesheetに設定されているMIMEタイプ・コードが、「スタイルシート」フォームの「MIMEタイプ」フィールドのドロップダウン・リストに表示されます。

- keywordがimageに設定されているMIMEタイプ・コードが、「イメージ・ファイル」フォームの「MIMEタイプ」フィールドのドロップダウン・リストに表示されます。

デフォルトでは、スタイルシートのファイルはCSSファイル、イメージファイルのファイルはGIFファイルまたはJPEGファイルになります。これらのアセット・タイプ、独自のカスタム・アセット・タイプ、またはその他の理由に対するMIMEタイプ・コードを追加できます。

「MIMEタイプ」ドロップダウン・リストにMIMEタイプを追加する手順は次のとおりです。

1. Oracle WebCenter Sites Explorerを開きます。

2. 「MIMEタイプ」表を開きます。

3. 次のいずれかを行います。

- イメージファイル・アセット・タイプにMIMEタイプを追加する場合、「MIMEタイプ」表で「イメージ」フォルダを選択します。

- スタイルシート・アセット・タイプにMIMEタイプを追加する場合、「MIMEタイプ」表で「テキスト」フォルダを選択します。

- アップロード・フィールドまたはその他の理由に対してMIMEタイプをカスタム・アセット・タイプに追加する場合、「MIMEタイプ」表の適切な場所を選択します。

4. 右のフレーム内を右クリックし、ドロップダウン・リストから「新規」を選択します。
Oracle WebCenter Sites 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. 「ファイル」→「すべて保存」を選択します。
Oracle WebCenter Sites Explorerで行が保存されます。

keywordがimageに設定されているMIMEタイプを追加した場合、そのMIMEタイプは「イメージ・ファイル」フォームの「MIMEタイプ」フィールドに表示されます。keywordがstylesheetに設定されているMIMEタイプのコードを追加した場合、そのMIMEタイプは「スタイルシート」フォームの「MIMEタイプ」フィールドに表示されます。

15.2.15 手順13: (オプション)索引付き検索を有効にするための検索エレメントの編集

WebCenter SitesとEngageには、標準検索と詳細検索を実行する独自のデータベースSQL検索メカニズムが備わっています。ただし、サポートされているサード・パーティの検索エンジンのいずれかに管理システムを設定することも可能です。構成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

管理システムで検索エンジンを使用する場合、各アセットは作成後または編集後に保存される際に索引付けされます。デフォルトでは、デフォルト・フィールドのみが索引付けされます(リストは、第11.2.4.2項「ベーシック・アセット・タイプのデータベース表のデフォルトの列」を参照してください)。アセット記述子ファイル内のPROPERTY文で作成したフィールドを索引付けする場合には、次のエレメントでフィールド用の文を追加する必要があります。

- OpenMarketXcelerate/AssetType/YourAssetType/IndexAdd.xml

- OpenMarketXcelerate/AssetType/YourAssetType/IndexReplace.xml

アセット・タイプのカスタム・フィールドをこれらのエレメントに追加するには、WebCenter Sites INDEXタグを使用してこれらのエレメント用の表記規則に従います。

15.2.16 手順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インタフェースの「サイト・ツリー」、「コンテンツ・ツリー」および「ワーク」ツリーに表示されるアイコンのアプリケーション・サーバーを再起動します。

15.2.17 手順15: アセット・タイプのテンプレートのコーディング

アセット・タイプの作成と該当するタイプのアセットに対応するテンプレートのコーディングは、反復プロセスです。アセット・タイプを作成して、テンプレート作成前に該当するタイプのアセットに対応するテンプレートを作成する必要がありますが、データ設計の微調整の必要がある領域は、テンプレートをコーディングしてコードをテストした後にのみ明らかになる可能性が高いようです。

テンプレートのコーディングの詳細は、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

15.2.18 手順16: 他のシステムへのアセット・タイプの移動

すべての新しいアセット・タイプの作成(それらに対するテンプレートの作成も含む)が終了したら、管理システムと配信システムへ移行します。次に、システム管理者が管理システムのアセット・タイプを構成します。管理者は、必要に応じてリビジョン追跡の有効化、ワークフロー・プロセスの作成、スタート・メニューのショートカットの作成などを実行します。

この手順の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

AssetMakerで作成したアセット・タイプを削除するには、選択したアセット・タイプのコンポーネントを削除するか、データベースからアセット・タイプのすべてのトレースを削除します。アセット・タイプのコンポーネントは次のとおりです。

- データベース表およびその中のすべてのデータ

- ElementCatalog表のエレメント

- SystemSQL表のSQL文

- AssetType表の行

- Association表の行(オプション)

- Category表の行(オプション)

- AssetPublication表の行

- AssetRelationTree表の行

AssetMakerで作成したアセット・タイプを削除する手順は次のとおりです。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「管理」タブを選択します。

5. 「AssetMaker」を開いて、削除するアセット・タイプを選択します。
「アセット・タイプ」フォームが表示されます。

6. 「アセットの削除」オプションを選択して、「送信」をクリックします。
WebCenter Sitesに確認メッセージが表示されます。

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

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

第11章「データ・デザイン: アセット・モデル」で説明したとおり、フレックス・アセット・タイプのデータ・モデルは、ファミリ内のアセット・タイプごとに複数のデータベース表を持つ、アセット・タイプのファミリの観点から検討できます。

フレックス・ファミリ・メーカー・ユーティリティを使用して、フレックス・アセット・タイプを新規作成します。ただし、フレックス・アセット・モデルで作業する際には、開発者はフレックス・アセット・タイプ以外にも、フレックス属性、フレックス親定義、フレックス定義、フレックス親アセットなどのタイプの個々のデータ構造のアセットも作成します。

通常、フレックス・アセット・タイプを設計し、開発システムでデータ構造アセットを作成します。データ・モデルの準備ができたら、それを管理システムと配信システムに移行します。

この章には次の項が含まれます。

- 第16.1項「フレックス・ファミリの設計ヒント」

- 第16.2項「フレックス・ファミリ・メーカー・ユーティリティ」

- 第16.3項「フレックス・アセット・ファミリの作成」

- 第16.4項「フレックス属性、親および定義の編集」

- 第16.5項「製品セットの使用」

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

フレックス・ファミリ設計時には、開発者は次の2つの対象読者のニーズを満たすデータ構造を作成します。

- オンライン・サイトへの訪問者(配信システムのユーザー)

- WebCenter Sitesデータベースにデータを入力するコンテンツ・プロバイダ(管理システムのユーザー)

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

- 第16.1.1項「配信システムへの訪問者」

- 第16.1.2項「管理システムのユーザー」

- 第16.1.3項「作成する属性タイプの数」

- 第16.1.4項「フレックス属性の設計」

- 第16.1.5項「作成する定義タイプの数」

- 第16.1.6項「親定義とフレックス定義アセットの設計」

- 第16.1.7項「まとめ」

16.1.1 配信システムへの訪問者

オンライン・サイトへの訪問者が参照する画面は、次のアセット・タイプに基づいています。

- フレックス・アセット

- フレックス属性

オンライン・サイトのページには、属性値(searchstates)に基づいた問合せによる訪問者向けフレックス・アセット(assetsets)が表示されます。詳細は、第11.4項「assetsetおよびsearchstate」を参照してください。それが意図したルック・アンド・フィールであれば、ドリルダウン検索の基準として属性値を使用し、オンライン・サイトの階層の外観を指定できます。

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

管理システムのユーザーは、次のフレックス・アセット・タイプで作成したビジュアルな階層構造により移動します。

- フレックス親定義

- フレックス定義

- フレックス親

これらのアセット・タイプを使用して作成する組織構造はデータに影響を及ぼしますが(どの属性値をどのフレックス・アセットが継承するかを決定する)、最大の影響を受けるのは管理システムのユーザーです。

フレックス親とフレックス親定義の使用は必須ではありませんが、それらの継承プロパティはオンライン・カタログなどの大量のデータを維持するユーザーには有効なツールとなります。

- 親レベルの属性値を変更すると、その親の子供であるフレックス・アセットはすべてその値に変更されるため、値を一度変更するだけで済みます。

- 継承された属性値はデータの入力中に発生したユーザーのエラーの影響を受けない値であるため、データのクリーンアップの必要が少なくなります。

コンテンツ・プロバイダ用に作成する継承ツリーは、設計中のオンライン・サイトをサイト訪問者が移動する方法とは何の関係もありません。たとえば、なんらかの完全に自動化されたプロセスで管理システムにコンテンツが入力された場合(ERPシステムからバルク・ロードされた場合など)、親アセット・タイプをまったく必要とせずに、オンライン・サイトでドリルダウン検索を作成できます。

16.1.3 作成する属性タイプの数

第11.4項「assetsetおよびsearchstate」で説明されているとおり、共通の属性タイプを共有するフレックス・アセットのみが同一のassetsetに所属できます。問合せ(searchstates)は属性に基づいており、親定義やフレックス定義の組織構造に基づいていないからです。

したがって、データ構造を設計する際に、個別の属性タイプを使用するようにデータを編成すると、管理システムでは非常に明確なインタフェースを作成できることがありますが、配信システムではそのデータが適切に合成されないため、目的にかなうことはほとんどありません。

通常、システムに対して1タイプの属性を作成する必要があります。必要に応じて、その他のファミリ・メンバーを複数バージョン作成できますが(フレックス・アセット・タイプ、フレックス定義タイプ、フレックス親タイプおよびフレックス親定義タイプ)、その場合でも属性の同一プールを共有する必要があります。

たとえば、製品ファミリとコンテンツ・ファミリが同一の属性タイプを共有するようにGE Lightingサンプル・サイトを設計した場合、製品とその製品に関する対応記事が含まれたassetsetを作成できるようになります。

16.1.4 フレックス属性の設計

属性の作成を開始する前に、それを紙上で設計します。必要な属性をすべて指定し、フレックス・アセットまたはフレックス親を使用してそれらを表示する場所を決定します。

まず、階層の最下位レベル(製品などのフレックス・アセット・タイプの個々のインスタンス)を計画し、そのレベルの各アイテムに必要な属性を指定します。たとえば、フレックス・フィルタ・アセットの作成を計画する場合、フィルタに対して入力と出力の属性として作成して定義に割り当てる必要のある属性を指定します。

必要なフレックス属性をすべて指定してから作成を開始する必要があります。それらの使用を計画する方法に応じて、作成時に説明する必要のある依存性が作成されるためです。

16.1.4.1 データ型

属性に対して有効なデータ型とそれらのデータ型のデフォルト入力タイプを評価します。どのデータ型がどの属性に最も効果的に機能するか確認します。属性に対するデフォルトの入力スタイルを変更する場合、そのための属性エディタを作成してから属性を作成します。第18章「属性エディタの設計」を参照してください。

タイプblobの属性を使用するフレックス・アセットを作成する場合、「調査」フォームに入力する属性値の書式はそのタイプに応じて異なります。たとえば、テキスト・ファイルではファイルの最初の200バイトが表示されます。イメージ・ファイルはサムネイル・イメージとして表示されます。一部のファイルはまったく表示できません。この場合、WebCenter Sitesではファイル名は表示できませんというメッセージが表示されますが、ファイルの場所は正常に記録されています。

16.1.4.2 属性エディタの使用

属性に対するデフォルトの入力タイプは、選択するデータ型に応じて異なります。デフォルト入力タイプを使用しない場合には、属性用属性エディタを作成できます。

フレックス・アセットとその属性エディタの作成は、反復プロセスになります。まず属性エディタを作成するか、最初に属性を作成して、戻って属性エディタを作成した後に属性エディタに属性を割り当てます。属性エディタの作成プロセスは、第18章「属性エディタの設計」を参照してください。

タイプBlobの属性

タイプblobの属性のデフォルト入力スタイルは、「参照」ボタンの付いたテキスト・フィールドです。「参照」ボタンを使用して、ファイルを検索して選択すると、デフォルトのストレージ・ディレクトリにアップロードされます。WebCenter Sitesフォームを使用してファイルのコンテンツを編集できません。

WebCenter Sitesフォームを使用して外部ファイルに直接コンテンツを入力できるようにするには、属性エディタを属性に割り当てる必要があります。

- TEXTAREA入力スタイルを使用する属性エディタの場合、最大2,000文字を入力できるフィールド(フォームを使用して入力)を作成でき、保存するとそのコンテンツがデフォルトのストレージ・ディレクトリに書き込まれます。

- CKEditorがあれば、CKEDITORフィールドを使用して属性が表現する外部ファイルのコンテンツを編集できます。

タイプAssetの属性

タイプAssetの属性に対するデフォルトの入力スタイルは、指定されたタイプのすべてのアセットのドロップダウン・リストです。該当するタイプのアセットが20を超える場合、フィルタのないドロップダウン・リストはお薦めしません。

通常、タイプ・アセットの属性を作成するたびに、それに属性エディタを割り当てる必要があります。

- PICKASSETスタイルを使用する属性エディタは、ツリーがWebCenter Sitesインタフェースのオン/オフで切り替えられるかどうかを確認します。ツリーがオンの場合、ユーザーはツリーのタブからアセットを選択できます。ツリーをオフに切り替えると、属性エディタの「ブックマーク」タブと「履歴」タブで、アセットのリストを表示するダイアログ・ボックスが表示されます。

- もう1つのオプションは、PULLDOWNスタイルの使用ですが、リストに表示されるオプションを制限する問合せアセットを入力するものです。

- 有効な選択肢となるアセット数が少ない場合、CHECKBOXES入力スタイルまたはRADIOBUTTONS入力スタイルを使用することも可能です。両方ともアセットを識別する問合せアセットを必要とします。

16.1.4.3 各属性の使用場所

属性のリストを指定した後、それらをフレックス定義またはフレックス親定義のどちらで使用するかを指定します。次のガイドラインに従って、論理的にソートします。

- 属性の値が個々のフレックス・アセット(製品、記事、イメージなど)で一意の場合、その属性はフレックス・アセットのツリーの最下位に属します。

- 属性値が複数のフレックス・アセットで同一の場合、その属性は親に属します。(もちろん、常に例外があります。たとえば、トースタの費用がボーリングのボールと同額であっても、共通の親からその値段を継承しているとは思えません。)

- その属性の配置に基づいて、必要なフレックス定義の数と親定義の数を指定できます。

個々のフレックス・アセットまたはフレックス親に使用できる、または使用する必要のある属性の数に関しては、物理的制限(DBMSに基づく)と心理的制限(ユーザーの満足度)の両方があることに注意してください。誰かがそのすべての値を入力する必要があります。必ず、実際に使用する予定がある属性のみを作成し、定義に割り当てます。今後、追加の属性が必要だと判断した場合には、非常に簡単に属性を追加できます。

16.1.4.4 階層による依存性

属性を使用する場所を確認したら、階層関係で属性に追加する要件があるかかどうかを確認します。たとえば、属性がフレックス親で使用され、データ構造がフレックス・アセットに複数の親を追加できる場合、フレックス・アセットは複数の値を継承することがあるため、属性は複数の値を保持するように構成する必要があります。

通常は、継承構造を複雑にしすぎないようにします。

16.1.5 作成する定義タイプの数

管理システムのデータの外観と入力は、フレックス・アセット定義とフレックス親定義に基づいています。親とフレックス・アセットは、定義によって作成する階層に基づいてWebCenter Sitesインタフェース内のツリーのタブに表示されます。

通常、最も望ましいのは、ファミリ内の各フレックス・アセット・メンバーに対して個々の定義タイプを作成することです。

たとえば、GE Lightingのサンプル・サイトには、コンテンツ・ファミリに記事(フレックス)とイメージ(フレックス)の2つのフレックス・アセット・メンバーがあるとします。これらは親、親定義およびフレックス定義を共有します。つまり、一部の属性は適用されないという理由でイメージ・アセットで空白のままにし、別の属性は適用されないという理由で記事アセットで空白のままにします。

イメージ親、イメージ定義およびイメージ親定義と異なる記事親、記事定義および記事親定義があることが好ましいでしょう。ただし、それらは同一の属性タイプを確実に共有する必要があり、実際に共有します。

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

WebCenter Sitesインタフェース内のツリーのタブの階層は、フレックス親定義とフレックス定義を介して作成されます。

- 階層を3レベルの深さに設定するには、少なくとも2つの親定義と少なくとも1つのフレックス定義が必要です。

- 階層を2レベルの深さに設定するには、少なくとも1つの親定義と少なくとも1つのフレックス定義が必要です。

構造的階層をフレックス定義とフレックス親定義を使用して設定する際には、必ず、ユーザビリティの基本的な原則を考慮してください。例:

- コンテンツ・プロバイダがツリーで所在位置が分からなくなるまでの階層の深さ。

- 入力中にユーザーのエラーの可能性を軽減するために継承できる属性値の数。

- ドロップダウン・リスト内に無理なく表示できるオプションの数。

非常に使用し難いシステムを作成すると、コンテンツ・プロバイダはエラーを発生します。

16.1.6.1 階層の配置の指定

WebCenter Sitesを開いてGE Lightingのサンプル・サイトにログインし、新しい製品の親定義または新しい製品の定義に対するフォームを調べます。

これらのフォームの「親定義」セクションで、次の2つの項目を指定します。

- この定義を使用して指定するアセットの階層での位置

- 属性の継承元の親

階層位置が管理システムのContributorインタフェース内のみを対象としていても、継承される属性は管理システムとオンライン・サイトの両方を対象としている点に注意してください。

「使用可能」テキスト・ボックスには、既存の親定義がすべて表示されます。フォームのこのセクションを使用して、可能な親数を指定します。「使用可能」リストから親定義を選択して、「選択済」リストに移動してください。

親アセットまたはフレックス・アセットを作成すると、新しい親やフレックス・アセットを作成する際に使用する定義を作成してある場合、「使用可能」リストから選択した各定義のドロップダウン・フィールドに「新規」フォームが表示されます。「新規」フォームのドロップダウン・リストには、該当する定義で作成されたすべての親が表示されます。

「新規」フォームで選択された親に属性値がある場合、アセットはそれらを継承します。

許可する必要のある親の数はいくつでしょうか。通常は、単純なままにしておいてください。「使用可能」リストから親定義を選択すると、その分、新しいフレックス・アセットを作成する際にコンテンツ・プロバイダが入力するフィールドが増えます。

「使用可能」リストで親定義を選択しない場合、この定義で作成されたアセットが、フレックス・アセットを表示するタブのツリーで最上位に配置されるようになります。

親定義、フレックス定義、親アセットおよびフレックス・アセットが相互作用する方法を理解するには、GE Lightingのサンプル・サイトで配信されるアセットを調べてください。

16.1.6.2 属性継承の指定

親定義フォームの「属性」セクションで属性継承を構成します。そのセクションを使用して、この定義で作成された親を定義する属性を指定します。

この定義で親を作成すると、これらの属性に入力された値は親アセットの子のフレックス・アセットに渡されます。

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

簡潔に言えば、必要なだけ作成できます。必要なフレックス親定義アセット数、およびそれらの定義の親アセット数を決定する際には必ずユーザビリティを考慮してください。

多くの親定義を作成する場合、それは各定義で作成された親を少なくすることを意味しており、それにより新しい親と新しいフレックス・アセット・フォームのドロップダウン・リストは短くなります。短いドロップダウン・リストにより、コンテンツ・プロバイダが容易にリストから正しい親を選択できるようになります。

しかし、データが少数の親定義と多数の親を必要とする場合、すべての親を表示するタブを作成してコンテンツ・プロバイダがタブから正しい親を選択できるようにします。

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

通常、フィールド(属性)が「新規」フレックス・アセット・フォームと「編集」フレックス・アセット・フォームで空白のままにならないよう、十分な数のフレックス定義を作成します。

作成する定義が少なすぎると、多くの属性フィールドを持つ長いフォームを作成し、そのすべてが各アセットに適用されない恐れがあります。多くの属性フィールドを持つ長いフォームがあると、現在作成中のアセットに適用する属性を決定するために、コンテンツ・プロバイダがフォームをソートする必要があるのみでなく、フォームがユーザーのブラウザでレンダリングされる時間が長くなります。

16.1.7 まとめ

データ構造をオンライン・サイトのフレックス・ファミリを使用して設計する際には、次のルールに注意してください。

- 慎重な計画に従った、使用しやすいアセット設計(データ設計)は、コンテンツ・プロバイダを満足させます。

- 使用可能なレイアウトと効率的なコードは、サイト訪問者を満足させます。

どちらのユーザー・グループも、適切に実行する効率的なシステムを必要としています。

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

フレックス・ファミリ・メーカーを使用してフレックス・ファミリを作成すると、次の操作が実行されます。

- 複数のデータベース表を作成します(数は作成するフレックス・アセット・タイプの応じて異なります)。

- 新しいフレックス・ファミリの情報を次の表に書き込みます。

- FlexAssetTypes: 各フレックス・アセット・メンバー・タイプの行を保持します。

- FlexGrpTmplTypes: 各フレックス親定義タイプの行を保持します。

- FlexGrpTypes: 各フレックス親タイプの行を保持します。

- FlexTmplTypes: 各フレックス定義タイプの行を保持します。

- 次のネーミング規則を使用して、ElementCatalog表に新しいディレクトリを作成します。
OpenMarket/Xcelerate/AssetType/NameOfYourAssetType

- ElementCatalog表からのエレメントを、アセット・タイプに作成されたディレクトリにコピーします。WebCenter Sitesでは、これらのエレメントを使用して、該当するタイプのアセットの「新規」フォーム、「編集」フォーム、「調査」フォーム、「検索」フォームおよび「検索結果」フォームが書式設定されます。

フレックス・アセットとフレックス親アセットのメイン・データベース表の詳細は、第11.3.6項「フレックス・ファミリとデータベース」を参照してください。フレックス・ファミリのすべてのデータベース表の詳細は、Oracle Fusion Middleware WebCenter Sitesデータベース・スキーマ・ガイドを参照してください。

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

新しいアセット・タイプを作成すると、フレックス・ファミリ・メーカーによってエレメントがElementCatalog表の次の場所にコピーされます。

OpenMarket/Xcelerate/AssetType/NameOfAssetType

たとえば、GEのサンプル・サイトの製品アセット・エレメントは次の場所にあります。

OpenMarket/Xcelerate/AssetType/Products

新しいアセット・タイプは、検索エレメントが使用し、OpenMarket/Xcelerate/AssetType/NameOfAssetTypeのSystemSQL表に配置されるSQL文も作成します。

エレメントの説明と、フレックス・ファミリ・メーカーによってコピーされるSQL文は、第15.1.4項「アセット・タイプに対応したエレメントとSQL文」を参照してください。フレックス・アセットのエレメントは、AppendSelectDetailsSEエレメントを除いてベーシック・アセット・エレメントと同じです。

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

開発者がオンライン・サイトに表示するコンテンツを表現するフレックス・アセットのデータ・モデルを使用している場合、フレックス・アセット・タイプのみを作成しているのではありません。それらのタイプ(フレックス属性、フレックス親定義、フレックス定義およびフレックス親アセット)の個々のデータ構造のアセットも作成します。

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

- 第16.3.1項「新しいフレックス・アセット・タイプまたはフレックス・アセット・タイプのファミリの作成の概要」

- 第16.3.2項「始める前に」

- 第16.3.3項「手順1: フレックス・ファミリの作成」

- 第16.3.4項「手順2: (オプション)追加のフレックス・ファミリ・メンバーの作成」

- 第16.3.5項「手順3: 新規のフレックス・アセット・タイプの有効化」

- 第16.3.6項「手順4: フレックス属性の作成」

- 第16.3.7項「手順5: (オプション)フレックス・フィルタ・アセットの作成」

- 第16.3.8項「手順6: 親定義アセットの作成」

- 第16.3.9項「手順7: フレックス定義アセットの作成」

- 第16.3.10項「手順8: フレックス親アセットの作成」

- 第16.3.11項「手順9: アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)」

- 第16.3.12項「手順10: フレックス・アセットのテンプレートのコード化」

- 第16.3.13項「手順11: 設計のテスト(テスト用フレックス・アセットの作成)」

- 第16.3.14項「手順12: (オプション)フレックス・アセットのアソシエーションの作成」

- 第16.3.15項「手順13: 他のシステムへのアセット・タイプの移動」

16.3.1 新しいフレックス・アセット・タイプまたはフレックス・アセット・タイプのファミリの作成の概要

新しいフレックス・アセット・タイプまたはフレックス・アセット・タイプのファミリを作成するためのプロセスの概要は、次のとおりです。プロセスのどの部分から開始するかは、設計する必要のあるアセット・タイプの数に応じて異なります。データ構造の基準としてサンプル・サイトのフレックス・ファミリのいずれかを使用できる場合、フレックス・ファミリ全体を作成する必要はなく、必要な新しいメンバーのみを作成できます。

この章では、指定する場合を除き、プロセスの次の各手順を説明してあります。

1. 新しいフレックス・ファミリを作成します(第16.3.3項「手順1: フレックス・ファミリの作成」)。

2. 必要に応じて、追加のフレックス・ファミリ・メンバーを作成します(第16.3.4項「手順2: (オプション)追加のフレックス・ファミリ・メンバーの作成」)。

3. 開発システムのすべてのWebCenter Sitesのサイトで新しいアセット・タイプを有効化し(第16.3.5項「手順3: 新規のフレックス・アセット・タイプの有効化」)、すべての新しいアセット・タイプについて「スタート・メニュー」ショートカットを作成します。また、新しいフレックス定義、フレックス親定義および属性タイプを「デザイン」タブに配置し、新しいフレックス親とフレックス・アセット・タイプにタブを作成します。

4. フレックス属性を作成して、属性エディタを設計します(第16.3.6項「手順4: フレックス属性の作成」)。属性エディタの詳細は、第18章「属性エディタの設計」を参照してください。

5. (オプション)フレックス・フィルタ・アセットを作成します(第16.3.7項「手順5: (オプション)フレックス・フィルタ・アセットの作成」)。フレックス・フィルタの詳細は、第17章「フレックス・フィルタ」を参照してください。

6. フレックス親定義を作成します(第16.3.8項「手順6: 親定義アセットの作成」)。

7. フレックス定義アセットを作成します(第16.3.9項「手順7: フレックス定義アセットの作成」)。

8. フレックス親アセットを作成します(第16.3.10項「手順8: フレックス親アセットの作成」)。

9. 「サムネイル」ビューで表示される検索結果リストにフレックス・ファミリのメンバーを表すアイコンを作成して割り当てます(第16.3.11項「手順9: アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)」)。

10. フレックス・アセット、フレックス・ファミリのフレックス・メンバーにテンプレートを作成します(第16.3.12項「手順10: フレックス・アセットのテンプレートのコード化」)。

11. 設計をテストするには、設計したデータ構造を確認するために十分なフレックス・アセットを作成します(第16.3.13項「手順11: 設計のテスト(テスト用フレックス・アセットの作成)」)。

12. (オプション)。フレックス・アセットのアソシエーションを作成します(第16.3.14項「手順12: (オプション)フレックス・アセットのアソシエーションの作成」)。

13. アセット・タイプを管理や配信など他のシステムに移動します(第16.3.15項「手順13: 他のシステムへのアセット・タイプの移動」)。この手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

16.3.2 始める前に

開発システムを設定して、それにアクセスするには、次の手順を実行します。

- 適切なWebCenter Sitesサイトを作成します。

- 管理者権限を持つ独自のユーザー名を作成し、開発システムのすべてのサイトでそのユーザー名を有効にします。管理者権限がないと、「管理」タブにアクセスできず、この章に記載した手順を実行できません。
便宜上、ユーザー名に「デザイナ」ロールと「GeneralAdmin」ロールを割り当てます。そうすることで、WebCenter Sitesインタフェース内のすべてのタブと、サンプル・サイト内のアセットへのすべての既存の「スタート・メニュー」ショートカットにアクセスできるようになります。(TableEditor ACLがユーザー名に割り当てられていることを確認してください。)

これらのタスクの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

16.3.3 手順1: フレックス・ファミリの作成

新規フレックス・ファミリを作成するには

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「管理」タブを選択します。

5. 「フレックス・ファミリ・メーカー」を開いて、「新規ファミリの追加」をクリックします。
「新規フレックス・ファミリの追加」フォームが表示されます。

6. 「フレックス属性」に、新規フレックス属性のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規属性のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

7. 「フレックス親定義」に、新規フレックス親定義のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規親定義のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

8. 「フレックス定義」に、新規フレックス定義のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス定義のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

9. 「フレックス親」に、新規フレックス親のアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規親のアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

10. 「フレックス・アセット」に、新規フレックス・アセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス・アセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

11. 「フレックス・フィルタ」に、新規フレックス・フィルタのアセット・タイプの名前を入力します。
このフィールドに入力する名前は、新規フレックス・フィルタのアセット・タイプの内部名です。それがこのアセット・タイプに対応するコア表の名前およびすべての補助表の接頭辞になります。

12. 「続行」をクリックします。
フレックス・ファミリ・メーカーには、次のようなフォームが表示されます。

13. ファミリの各新規メンバーについて、「説明」フィールド内でクリックし、アセット・タイプの外部名、つまりWebCenter Sitesに表示される際のアセット・タイプの名前を入力します。これは、フォーム(「新規」、「編集」、「調査」など)に表示される名前です。

14. ファミリの各新規メンバーでは、「複数」フィールドをクリックして名前の複数バージョンを入力します。このバージョンは、必要に応じてステータス・メッセージなどで使用されます。

15. 「新規フレックス・ファミリの追加」をクリックします。
フレックス・ファミリ・メーカーにより、これらのタイプのアセットを格納するデータベース表が作成されます。アセットの表の詳細は、第11.3.6項「フレックス・ファミリとデータベース」を参照してください。

また、これらのタイプのアセットでフォームの書式を設定するエレメントが、ElementCatalog表とSystemSQL表のアセット・タイプの名前を持つディレクトリにコピーされます。

16.3.4 手順2: (オプション)追加のフレックス・ファミリ・メンバーの作成

追加のフレックス・ファミリ・メンバーを作成する必要がある場合(メンバー・カテゴリごとに複数のフレックス・アセット・タイプが必要な場合など)、次の手順を実行します。

1. 「管理」タブで、作成したフレックス・ファミリを開きます。

2. 別のメンバーを作成するためのカテゴリ(フレックス親など)に到達するまで、フレックス・ファミリ・ツリーをドリルダウンします。

3. 必要なメンバー・カテゴリで、「新規メンバー・カテゴリのアセット・タイプの追加」をダブルクリックします。

4. WebCenter Sitesに「新規メンバー・カテゴリのアセット・タイプ」フォームが表示されます。

5. フォームで、必要なフィールドに入力して「保存」をクリックします。
WebCenter Sitesに、アセット・タイプが作成されたことを確認するメッセージが表示されます。

6. 作成する追加のフレックス・ファミリ・メンバーごとに、この手順を繰り返します。

16.3.5 手順3: 新規のフレックス・アセット・タイプの有効化

アセット(属性、フレックス親定義など)の作成を開始する前に、「管理」タブで必要な手順を完了して、それらのアセットにアクセスできるようにします。ログインでは、「管理」タブにアクセスするための管理者権限が付与される必要があります。

次の手順を実行します。

1. 「管理」タブで、「サイト」アイコンをクリックして次の手順を実行します。

1. このアセット・タイプで作業するのに使用するサイトを選択します。

2. そのサイトで、「アセット・タイプ」→「アセット・タイプの有効化」を選択します。

3. リストから新しいアセット・タイプを選択して、「アセット・タイプの有効化」をクリックします。

4. WebCenter Sitesでは、有効にしたアセット・タイプで「新規スタート・メニュー・アイテム」や「スタート・メニュー・アイテムの検索」が自動的に作成されます。WebCenter Sitesに作成する、任意の使用可能な「スタート・メニュー・アイテム」の隣にあるボックスを選択します。

この時点でこれらのメニュー・アイテムを生成しない場合には、開発者またはサイト管理者がそれらを後から手動で作成する必要があります(有効化されたアセット・タイプに対してスタート・メニュー・アイテムが作成されるまでは、そのアセット・タイプのアセットを作成できません)。

5. 該当する各サイトで手順aからdを繰り返します。

2. 「アセット・タイプの有効化」をクリックします。

3. これでアセット・タイプはサイトに対して有効になります。スタート・メニュー・アイテムを生成する際にWebCenter Sitesを使用しなかった場合には、この時点では手動で作成する必要があります。アセット・タイプの開発者およびオンライン・サイトのデザイナには、管理者が意味のあるスタート・メニュー・アイテムを構成できるように、アセットとサイト設計について十分な情報を知らせる責任があります。
開発者は、サイト管理者とシステム管理者がコンテンツ・プロバイダに対して意味のあるスタート・メニュー・アイテムを作成できるように、オンライン・サイトに対する問合せ、コレクション、その他のデザイン・エレメントで使用するフィールドについて知らせる必要があります。スタート・メニュー・アイテムの作成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

開発者または管理者が新規アセット・タイプに「スタート・メニュー」アイテムを作成した後は、それらのタイプのアセットを作成できるようになります。アセット・タイプをタブに追加しても、それらに「スタート・メニュー」ショートカットを作成するまで新規アセットは作成できません。

16.3.6 手順4: フレックス属性の作成

手順は属性に選択するデータ型に応じて大きく異なるため、この項では次のような手順について説明します。

- 大半のデータ型に対する属性作成の基本的な手順

- タイプblobの属性の作成

- タイプassetの属性の作成

- 外部属性(外部表に格納された属性)の作成。フレックス属性として使用するデータが格納された外部表を登録する必要があります。詳細は、第12.3.4項「外部表の登録」を参照してください。

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

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。
Adminインタフェースを選択します。

3. 「新規」をクリックして、ショートカットのリストから属性タイプの名前を選択します。たとえば、「新規製品属性」を選択したとします。このアセットとのワークフローの関連付けで割当て先を選択する必要がある場合、各ロールから少なくとも1人のユーザーを選択して「割当て先の設定」をクリックします。
新規属性フォームが表示されます。

4. 「名前」フィールドをクリックして、最大64文字(空白は除く)の名前を入力します。

5. 「説明」フィールド内でクリックして、この属性の使用や機能について簡潔に記述します。

6. 「値タイプ」フィールド内でクリックして、この属性に対してデータ型を選択します。

- blobを選択した場合、第16.3.6.2項「タイプBlobのフレックス属性(アップロード・フィールド)の作成」を参照して、手順3から開始します。

- assetを選択した場合、第16.3.6.3項「タイプAssetのフレックス属性の作成」を参照してください。

- 外部属性を作成する場合、assetまたはblob以外の値を選択し、手順7を実行して、第16.3.6.4項「外部フレックス属性の作成」の手順3を続行します。

- textを選択した場合、WebCenter Sites Adminインタフェースはtext以外のすべてのタイプの属性値の検索に対応します。属性値の検索実行に関する情報は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

属性に適切なデータ型の決定が必要な場合、第11.3.3.1項「属性のデータ型」を参照してください。

7. 「値の数」フィールドをクリックし、必要に応じて「値タイプ」フィールドで選択したデータ型に対して、「単一」または「複数」のいずれかをドロップダウン・リストから選択します。

この属性がフレックス親で使用され、データ構造がフレックス・アセットに複数のフレックス親を許可する場合、この属性の値を継承するフレックス・アセットが複数の親から値を継承するため、「複数」を選択する必要があります。

注意:

属性が複数の値を受け入れるように構成されている場合、その属性はフレックス親フォームとフレックス・アセット・フォームに「別の属性名を追加」ボタンが備わったフィールドとして表示されます。

継承の理由から属性が複数の値を受け入れるが、コンテンツ・プロバイダが個々の親またはフレックス・アセットに対して属性を複数選択しないようにするには、その属性を単一値のフィールドとして表示する属性エディタをその属性に割り当てます(「値タイプ」フィールドで複数選択)。

WebCenter Sitesでは、textタイプの属性のデータベースへの格納方法の制限により、これらの属性が複数の値を持つことは許可されていません。そのような方法で構成した属性を保存しようとすると、この制限を意味するメッセージが表示されます。

8. (オプション)この属性にデフォルト入力タイプ(「値タイプ」フィールドで選択したデータ型に基づいている)を使用しない場合、「属性エディタ」フィールドをクリックしてドロップダウン・リストから1つ選択します。

詳細は、次の情報を参照してください。

デフォルト入力タイプのリスト(かわりに属性エディタを使用するかどうかを指定できる)は、第11.3.3.2項「属性のデフォルトの入力スタイル」を参照してください。

属性エディタの作成の詳細は、第18章「属性エディタの設計」を参照してください。

該当する属性のデータ型に適切な属性エディタの詳細は、第18.1.2項「属性エディタ・アセット」を参照してください。

9. (オプション)デフォルトISO文字セット(ISO 8859-1)をオーバーライドする必要がある場合、「ISO文字セット」フィールドをクリックして、該当する属性に使用する文字セットを入力します。

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

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

タイプblobの属性を作成するには

1. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順1から4を実行します。

2. 「値タイプ」フィールドをクリックし、「blob」を選択します。

3. (オプション)「フォルダ」フィールドをクリックし、属性値を格納するディレクトリへのパスを入力します。このフィールドに入力する値はMungoBlobs表に対するデフォルトのストレージ・ディレクトリ(defdir)として値セットに追加されることに注意してください。

4. 「値の数」フィールドをクリックし、必要に応じて「単一」または「複数」を選択します。このフィールドの詳細は、第16.3.6.1項「フレックス属性の作成: 基本的な手順」を参照してください。

5. (オプション)デフォルトの入力タイプ(「参照」ボタン)を使用しない場合、「属性エディタ」フィールドをクリックして次のうちのいずれかを選択します。

- TEXTAREA入力スタイルを指定する属性エディタ。属性エディタの詳細は、第18.1.2項「属性エディタ・アセット」を参照してください。

- システムがCKEditorを使用するように構成されている場合には、CKEDITOR入力スタイルを指定する属性エディタ。

6. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順8から9を実行します。

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

タイプassetの属性を作成するには

1. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順1から4を実行します。

2. 「値タイプ」フィールドをクリックし、「asset」を選択します。

3. 「アセット・タイプ」フィールドをクリックして、ドロップダウン・リストからオプションを選択します。

4. 「依存性タイプのミラーリング」フィールドをクリックして、依存性タイプを選択します。

5. 「値の数」フィールドをクリックし、必要に応じて「値タイプ」フィールドで選択したデータ型に対して、「単一」または「複数」のいずれかをドロップダウン・リストから選択します。
この属性がフレックス親で使用され、データ構造がフレックス・アセットに複数のフレックス親を許可する場合、この属性の値を継承するフレックス・アセットが複数の親から値を継承するため、「複数」を選択する必要があります。

6. (オプション)「値の数」フィールドで選択したタイプのアセットの数が20を超えた場合、「属性エディタ」フィールドをクリックして選択します。適切な属性エディタの詳細は、第16.1.4.2項「属性エディタの使用」を参照してください。

7. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順8から9を実行します。

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

フレックス・アセットでも使用する別のシステム内のデータ(価格リストなど)を保持する場合、フレックス属性として使用するデータの外部表の列を指す外部属性を作成できます。

外部属性を作成するには

1. フレックス属性として使用するデータが格納された外部表を登録します。詳細は、第12.3.4項「外部表の登録」を参照してください。

2. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順1から6を実行します。「値タイプ」フィールドでは、assetまたはblob(またはURL)のいずれも選択できません。

3. (オプション) WebCenter Sitesのフレックス・アセット・フォームを使用して外部表に属性値を入力する場合、「値タイプ」フィールドで選択したデータ型のデフォルト入力タイプを使用しないときは、「属性エディタ」フィールドをクリックして適切なオプションを選択します。

4. 「編集スタイル」フィールドをクリックし、次のいずれかを実行します。

- WebCenter Sitesフォームを使用して、属性を使用するフレックス・アセットのこの属性のフィールドに値を入力する場合、「ローカル」を選択します。

- ユーザーがWebCenter Sitesフォームでこの表に値を書き込めないようにするには、「外部」を選択します。

5. 「ストレージ・スタイル」フィールドをクリックして、ドロップダウン・リストから「外部」を選択します。

6. 「外部ID」フィールドをクリックして、この外部属性を保持する表の主キーとして処理する列、つまり属性を一意で識別する列の名前を指定します。

7. 「外部表」フィールドをクリックして、この属性が格納されている表名を記入します。

8. 「外部列」をクリックし、該当する属性の値を保持する「外部表」で指定された表の列名を入力します。

9. 第16.3.6.1項「フレックス属性の作成: 基本的な手順」の手順8から9を実行します。

16.3.7 手順5: (オプション)フレックス・フィルタ・アセットの作成

この項では、フレックス・フィルタ・アセットの中で機能がいずれかのデフォルトWebCenter Sitesフィルタ・クラスで定義されているものの作成について一般的な手順を説明します。フレックス・フィルタ・クラスの情報と、フレックス・フィルタ・アセットの作成手順の詳細は、第17章「フレックス・フィルタ」を参照してください。

フレックス・フィルタ・アセットの作成前に、入力および出力の属性として使用するフレックス属性を作成しておく必要があります。適切なフレックス属性が存在しない場合には作成します。次の要件に注意してください。

- フレックス・フィルタがDocument Transformationフィルタ・タイプを使用している場合、入力と出力の属性はタイプblobである必要があります。

- どのフレックス・フィルタでも、入力属性、出力属性およびフレックス・フィルタ・アセットはすべて同一のフレックス・ファミリに属している必要があります。

フレックス・フィルタ・アセットを作成するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. スタート・メニューのオプションから「新規」をクリックします。

5. アセット・タイプのリストで、作成するフィルタのタイプを選択します。たとえば、「新規メディア・フィルタ」を選択したとします。このアセットに関連付けられているワークフローで割当て先を選択する必要がある場合、各ロールから最低1人のユーザーを選択して「割当て先の設定」をクリックします。
次のような新規フィルタ・フォームが表示されます。

6. 新しいフォームでは、次のフィールドに入力します。

- 名前: 該当するフィルタ・アセットの一意の名前を入力します。

- 説明: フィルタ機能を要約した簡単な説明を入力します。

- フィルタ: 作成するフレックス・フィルタ・アセットの機能を定義するフィルタ・クラスを選択します。デフォルトでは、フィルタのオプションは「Doc-Type」、「ドキュメント変換」、「フィールド・コピアー」および「サムネイル・クリエータ」です。

注意:

システムにカスタム・フィルタが作成されている場合には、それもこのリストに表示されます。カスタム・フレックス・フィルタ・クラスを作成する場合は、第17.2項「フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成」を参照してください。

7. 「引数の取得」をクリックします。「引数」フィールドで、フレックス・フィルタ・アセットに対する入力および出力の引数を指定します。「追加」をクリックして、フィルタに引数を追加します。

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

16.3.8 手順6: 親定義アセットの作成

次の手順を実行します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. スタート・メニューのオプションから「新規」をクリックします。

5. 製品の定義アセットの名前をショートカットのリストから選択します。たとえば、「新規製品の親定義」を選択したとします。このアセットに関連付けられているワークフローで割当て先を選択する必要がある場合、各ロールから最低1人のユーザーを選択して「割当て先の設定」をクリックします。
次のような新しいフォームが表示されます。

6. 「名前」フィールドをクリックして、最大64文字の名前を入力します。

7. 「説明」フィールドをクリックして、親定義を説明する簡単なフレーズを入力します。

8. 「親選択スタイル」フィールドをクリックして、該当する定義を使用するフレックス親が親アセット・フォームで選択される方法を指定します。次のいずれかを行います。

- 該当するタイプの親数が少ない場合には、「選択ボックス」を選択します。それにより、このタイプのすべての親がフレックス・アセット・フォームのドロップダウン・フィールドにオプションとして表示されます。

- 該当するタイプの親数が多い場合には、「ツリーからの選択」を選択します。そのうえで、フレックス・アセット・フォームでこのタイプの親を選択する場合は、カタログ・データが表示されたタブのツリーから選択します。たとえば、GEサンプル・サイトでは、カタログ・データは「カタログ」タブのツリーに表示されます。

9. 「使用可能」リストから親定義を選択します。親定義の選択の詳細は、第16.1.6.1項「階層の配置の指定」を参照してください。

10. 次の表の説明に従って、適切な矢印をクリックします。

表16-1 親定義フォームのボタン

親定義フォームのボタン

新規親フォームで次の操作を実行するフィールドの作成

単一値(必須)

フィールドに対して1つの親を強制的に選択します。

単一値(オプション)

フィールドに対して親を1つのみ選択できます。

複数値(必須)

フィールドに対して少なくとも1つの親アセットを強制的に選択します。

複数値(オプション)

フィールドに対して複数の親アセットを選択できます。

WebCenter Sitesによって、親定義が「使用可能」リストから「選択済」リストに移動されます。

1. 必要な回数だけ、手順6と7を繰り返します。対応する「新規」親フォームには、その親の定義フォームの「使用可能」リストで選択する各アイテムのフィールドが追加されます。

2. 「属性」セクションで、適切な属性を選択します。フレックス・フィルタ・アセットを該当する親定義に割り当てる場合、そのフレックス・フィルタで使用される入力と出力の属性を追加する必要があります。

3. 次のいずれかを行います。

- 「必須」ボタンをクリックして、その属性が必須であることを指定します。つまり、該当する定義で作成されたすべてのフレックス親にはその属性の値が存在する必要があります。

- 「オプション」ボタンをクリックして、その属性がオプションであることを指定します。

4. (オプション)該当するタイプの親の親フォームに表示する順番で属性を選択していない場合には、「選択済」ボックスの右の矢印を使用して、属性を並べ替えます。

5. (オプション)「フィルタ」セクションで、親定義に適切な任意のフレックス・フィルタ・アセットを選択します。

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

7. この手順を、作成する必要のある親定義アセットごとに繰り返します。

16.3.9 手順7: フレックス定義アセットの作成

次の手順を実行します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. スタート・メニューのオプションから「新規」をクリックします。

5. フレックス定義アセット・タイプの名前をショートカットのリストから選択します。たとえば、「新規製品の定義」を選択したとします。このアセットに関連付けられているワークフローで割当て先を選択する必要がある場合、各ロールから最低1人のユーザーを選択して「割当て先の設定」をクリックします。

次のような新しいフォームが表示されます。

6. 「名前」フィールドをクリックして、最大64文字の名前を入力します。

7. 「説明」フィールドをクリックして、親定義を説明する簡単なフレーズを入力します。

8. 「使用可能」リストから親定義を選択します。親定義の選択の詳細は、第16.1.6.1項「階層の配置の指定」を参照してください。

9. 次の表の説明に従って、適切な矢印をクリックします。

表16-2 フレックス定義フォームのボタン

フレックス定義フォームのボタン

新規フレックス・アセット・フォームで次の操作を実行するフィールドの作成

単一値(必須)

フィールドで親を1つのみ強制的に選択します。

単一値(オプション)

フィールドで親を1つのみ選択できます。

複数値(必須)

フィールドで少なくとも1つの親アセットを強制的に選択します。

複数値(オプション)

フィールドで複数の親アセットを選択できます。

WebCenter Sitesによって、親定義が「使用可能」リストから「選択済」リストに移動されます。

1. 必要な回数だけ、手順5と6を繰り返します。対応する「新規」フレックス・アセット・フォームには、そのフレックス定義フォームの「使用可能」リストで選択する各アイテムのフィールドが追加されます。

2. 「属性」セクションで、属性を1つ選択します。フレックス・フィルタ・アセットを該当するフレックス定義に割り当てる場合、そのフレックス・フィルタで使用される入力と出力の属性を追加する必要があります。

3. 次のいずれかを行います。

- 「必須」ボタンをクリックして、その属性が必要であることを指定します。つまり、該当する定義で作成されたすべてのフレックス・アセットにはその属性の値が存在する必要があります。

- 「オプション」ボタンをクリックして、その属性がオプションであることを指定します。

4. (オプション)この定義で作成したフレックス・アセットの「新規」フォームと「編集」フォームに表示する順番で属性を選択していない場合には、「選択済」ボックスの右の矢印を使用して並べ替えます。

5. (オプション)「フィルタ」セクションで、フレックス定義に適切な任意のフレックス・フィルタ・アセットを選択します。

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

7. この手順を、作成する必要のあるフレックス定義ごとに繰り返します。

16.3.10 手順8: フレックス親アセットの作成

フレックス親アセットを作成するには

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. 「コントリビュータ」インタフェースを選択します。

4. メニュー・バーで、「コンテンツ」→「新規」→作成するフレックス親アセットのタイプを選択します。
作成するフレックス親アセットの「作成」ビューを表示したタブが開きます。

5. 「名前」フィールドに、最大64文字の名前を入力します。

6. 「親定義」フィールドで、必要な親定義をドロップダウン・リストから選択します。選択する定義により、フォームの次のセクション(この親アセットを定義する際に入力するセクション)の書式が設定されます。
フォームの「コンテンツ」セクションが表示されます。

7. フォームの「コンテンツ」セクションで、フィールドに入力します。
このセクションに表示されるフィールドの種類について、次の点に注意してください。

- フィールドの隣にアスタリスク(*)が表示されている場合、そのフィールドは必須です。

- この例では、親アセットを指定するフィールドはFSIIProductTopLevelと呼ばれます。このフィールドにドラッグ・アンド・ドロップした親は、この手順で作成中の親の子として指定するフレックス・アセットの祖父母になります。このフィールドが必須ではなく、親(祖父母)を選択しない場合、作成中の親が「コンテンツ・ツリー」のトップレベルの親になります。

- フィールドを単一値または複数値のいずれにするかを決めるには、フィールドに関連付けられたドロップ・ゾーンを指します。このフィールドが受け入れるタイプを示したツールチップが、フィールドを単一値または複数値のいずれに指定するかに関する情報とともに表示されます。

8. フォーム・セクション・セレクタを使用して、フォームの次のセクションに切り替えます(「マーケティング」セクションと「メタデータ」セクション)。フィールドの横にアスタリスク(*)がある場合、それは必須フィールドです。
これらのセクションに表示されたフィールドは、この親に選択した親定義に基づいています。これらのフィールドに入力する値は、この親アセットを親として持っているすべてのフレックス・アセットによって継承されます。

9. アセットのツールバーで、「保存」アイコンをクリックします。
WebCenter Sitesでは、新しい親がデータベースに書き込まれます。属性値以外のすべての情報が、FlexParent表、FlexParent_AMap表およびFlexParent_Extension表に書き込まれます。ここで、FlexParentは、フレックス親の内部名を表します。属性値は、FlexParent_Mungo表に書き込まれます。

16.3.11 手順9: アセット・タイプのアイコンの作成と割当て(Contributorインタフェースのみ)

ユーザーがContributorインタフェースで検索を実行し、「サムネイル」ビューに検索結果が表示されると、検索結果リストの各アセットはサムネイル・イメージで表されます。デフォルトでは、検索結果リストのアセットの名前、アセット・タイプ、変更日およびロケールが、アセットまたはアセットのタイプを表すサムネイル・イメージの下に表示されます。イメージは、アセットごとまたはアセット・タイプごとに割り当てることができます。このセクションでは、各アセット・タイプへのサムネイル・イメージの割当てについて重点的に説明します。

下記の手順を実行して、新規フレックス・ファミリのメンバーを一意に識別するイメージを作成して割り当てる必要があります。

1. 各フレックス・ファミリ・メンバーに対して、次の操作を実行します。

1. タイプがJPGの2つのイメージ・ファイルを作成します。1つはドッキングされた検索結果リストに表示され、もう1つはドッキングされていない検索結果リストに表示されます。ドッキングされた検索結果リストに表示されるイメージの標準サイズは、96x96ピクセルです。ドッキングされていない検索結果リストに表示されるイメージの標準サイズは、170x170ピクセルです。

2. イメージ・ファイルは、次のとおり名前を付けます。

- ドッキングされた検索結果リストのアセット・タイプに表示されるイメージの名前を付けるには、構文assetType.jpgを使用します。

- ドッキングされていない検索結果リストのアセット・タイプに表示されるイメージの名前を付けるには、構文assetType_large.jpgを使用します。
イメージをJPGとして保存する必要があります。ファイル名は、アイコンが表示されるアセット・タイプを決定します。この名前では、大文字と小文字が区別されます。

3. イメージ・ファイルを適切なディレクトリに配置します。
<cs_app_dir>/images/search

ここで、<cs_app_dir>はアプリケーション・サーバーのデプロイ済WebCenter Sitesアプリケーションのディレクトリです。

2. アプリケーション・サーバーを再起動すると、Contributorインタフェースの検索結果リストの「サムネイル」ビューにアイコンが表示されます。

16.3.12 手順10: フレックス・アセットのテンプレートのコード化

フレックス・アセット定義の作成、およびこれらの定義を使用するフレックス・アセットのテンプレートのコード化は、反復作業となります。アセット・タイプにテンプレートを作成する前に、定義とフレックス・アセットを作成する必要がありますが、データ設計の微調整の必要がある領域は、テンプレートをコード化してコードをテストした後にのみ明らかになる可能性が高いようです。

テンプレートのエレメントのコード化については、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」および第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

16.3.13 手順11: 設計のテスト(テスト用フレックス・アセットの作成)

設計を十分テストするには、複数のフレックス・アセットを作成してツリー上で表示される場所、フォームの外観、フォームへのロード時間などを調査できるようにする必要があります。

16.3.14 手順12: (オプション)フレックス・アセットのアソシエーションの作成

ほとんどの場合、フレックス・アセットの属性を使用してアソシエーションを形成する必要があります。アソシエーションをフレックス定義間で稼働する必要があることがまれにあり、その場合には次の手順を実行してフレックス・アセット間のアソシエーションを作成します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. ツリーの 「管理」タブで、「アセット・タイプ」ノードをクリックします。

5. アソシエーションを作成するアセット・タイプの横のプラス記号をクリックします。

6. 「アセットのアソシエーション」ノードのプラス記号をクリックします。

7. 「新規追加」をクリックします。次の画面が表示されます。

8. 「名前」フィールドをクリックして、名前を入力します。

9. 「説明」フィールドをクリックして、アソシエーションの説明を入力します。

10. 「子アセット」ドロップダウンの選択ボックスを使用して、このアセットに関連付ける子アセットを選択します。

11. 「サブタイプ」フィールドを使用して、1つまたは複数のサブタイプを選択します。

12. 「依存性タイプのミラーリング」オプションを使用して、関連付けられたフレックス・アセットの依存性タイプを選択します。

13. 「新規アソシエーションの追加」をクリックし、フレックス・アセット・タイプを関連付けます。

16.3.15 手順13: 他のシステムへのアセット・タイプの移動

フレックス・ファミリの作成が終了している場合、それらを管理システムおよび配信システムに移動します。フレックス・ファミリの作成には、フレックス・ファミリ・メーカーを使用した新規フレックス・アセット・タイプの作成、データ構造アセット(属性エディタを含む)の作成、フレックス・アセット・タイプのテンプレートのコード化が含まれます。

次に、システム管理者が管理システムのアセット・タイプを構成します。管理者は、必要に応じてリビジョン追跡の有効化、ワークフロー・プロセスの作成、スタート・メニューのショートカットの作成などを実行します。

アセット・タイプの管理システムおよび配信システムへの移動の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

16.4 フレックス属性、親および定義の編集

フレックス・アセット・タイプの編集には、通常、慎重な計画が必要です。特定の編集でスキーマの変更が生じ、スキーマの変更がデータ消失の原因となるためです。

この項では、フレックス・ファミリのアセット・タイプの編集に関するヒントとアドバイスを述べます。この項は、次のトピックで構成されています。

- 第16.4.1項「属性の編集」

- 第16.4.2項「親定義とフレックス定義の編集」

- 第16.4.3項「親およびフレックス・アセットの編集」

16.4.1 属性の編集

フレックス属性の編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをWebCenter Sitesデータベースにインポートしている場合、属性名を変更するにはXMLPostファイルを編集する必要があります。

- データ消失を発生せずに、「説明」を変更できます。

- 「値タイプ」フィールドでデータ型を変更すると、この属性タイプを使用する_Mungo表の属性に関連付けられたすべてのデータが消失します。

- 属性のデータ型がassetの場合、そのアセット・タイプを変更すると、その属性に対するすべての既存データが無効になります。

- blob属性の「フォルダ」フィールドを変更すると、WebCenter Sitesではその属性の既存データを検索できなくなります。この値をどうしても変更する必要がある場合は、設定した新しい値に一致させるためにファイル・システムを移動する必要があります。

- データ消失や困難な事態を発生せずに、「値の数」を単一から複数に変更できます。

- 「値の数」を複数から単一に変更すると、既存の行のどの値が保持すべき値であるかを指定できなくなります。

- 「検索エンジン」と「ISO文字セット」は、データ消失を発生せずに変更できます。

16.4.2 親定義とフレックス定義の編集

親定義またはフレックス定義の編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをご使用のWebCenter Sitesデータベースにインポートしている場合、親定義の名前を変更したらXMLPostファイルを編集する必要があります。

- 「説明」フィールドと「親選択スタイル」フィールドは、データ消失を発生せずに変更できます。

- 親の選択肢を変更する場合:

- 親の追加は許可されます。

- 親の削除は、アセットが有効なデータを消失させる原因となることがあります。

- 親をオプションから必須に変更すると、新しく必須となった親のいずれかが存在しない親またはフレックス・アセットが有効でなくなるため、問題を発生する可能性があります。

- 親の必須からオプションへの変更は許可されます。

- 親の単一力複数値への変更は許可されます。

- 親を複数値から単一値に変更すると、WebCenter Sitesで以前に受け入れられていた複数値を保持するか削除するかを決定できなくなるため、予測できない結果が発生します。

- 属性の選択内容を変更する場合:

- オプションの属性の追加は許可されます。

- 必須の属性を追加すると、その属性を保持しない既存の親やフレックス・アセットを無効にします。

- 属性を削除すると、削除された属性の属性値を持つ既存の親やフレックス・アセットを無効にします。

16.4.3 親およびフレックス・アセットの編集

フレックスまたは親アセットの編集時には、次の点に注意してください。

- スキーマを変更せずに、「名前」を変更できます。ただし、XMLPostを使用してフレックス・アセットをご使用のWebCenter Sitesデータベースにインポートしている場合、親定義の名前を変更したらXMLPostファイルを編集する必要があります。

- データ消失を発生せずに、「説明」を変更できます。

- 親を変更すると、継承された属性値すべてが修正されます。

- 親またはフレックス・アセットを作成する際に使用した定義を変更できません。

- 属性値の変更は許可されます。親の属性値を変更すると、該当する親から属性値を継承するすべてのアセットの属性が修正されます。フレックス・アセットの属性値の変更は許可されます。

16.5 製品セットの使用

WebCenter Sitesを使用してオンライン・カタログを管理すると、製品セットという製品アセットで使用できる特殊な機能があります。製品セットを使用すると、別々に梱包され販売されるものを除いて、実際には同じ製品になる製品をグループ化できます。

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

- 第16.5.1項「製品セットとは」

- 第16.5.2項「製品セットの作成」

16.5.1 製品セットとは

たとえば、本はペーパーバック版でもハードカバー版でも同じ本です。ソフト・ドリンクは、個別の缶、6パック、2リットルのボトル、またはケースのいずれで販売されても同じソフト・ドリンクです。

製品セットでは、このように製品をまとめてグループ化できるため、管理システムで一緒に(同一のフォームに)表示でき、個々の販売単位のままSKU(最小在庫管理単位)などで識別されます。

販売セット機能のモデルは、次のとおりです。

- 製品セットは、製品アセットの特性を帯びる製品の親です。製品セット(親)には、コア製品を定義するすべての属性が備わっています。

- 製品セットは最小在庫管理単位です。つまり、製品セットにはパッケージを説明する属性、またはセットのメンバーの一意の識別子(SKU、ボトル・サイズなど)のみが含まれます。

- 製品セット(親)には、製品セットとマークする属性があり、この属性の値はすべての製品セットで一意です。この属性はGAProductSetと呼ばれ、予約ネームとなります。セット内の製品はこの属性を継承し、この継承により、その製品セットのメンバー(その製品の親の子)としてマークされます。

16.5.2 製品セットの作成

製品セットを作成するには

1. GAProductSetと名付けられた製品の属性を作成します。これは予約ネームであり、属性名はそれに完全に一致している必要があります。

2. 新しい製品の親定義を作成し、GAProductSet属性を選択します。

3. 新しい製品の定義を作成し、手順2で作成した定義を使用して作成された親がこの製品定義で作成された製品の親になることができるように指定します。

4. 手順2で作成した定義から新しい製品の親を作成します。

5. 手順3で作成した製品の定義を使用し、セットの製品を作成して手順4で作成した親がそれらの製品の親になるよう指定します。

ここで、製品セット(製品の親)を調査または編集すると、セット内の各製品(SKU)は製品セットの関係を表して、「製品の親」フォームにリストされます。

WebCenter Sitesデータベースに存在できるのは、1つのGAProductSet属性のみです。複数のWebCenter Sitesサイトがあり、複数のサイトで製品セットを作成する場合、GAProductSet属性を使用するサイトに対してその属性を共有する必要があります。

17 フレックス・フィルタ

この章では、フレックス・フィルタについて説明します。フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成の手順も含まれています。

この章には次の項が含まれます。

- 第17.1項「フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットの理解」

- 第17.2項「フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成」

- 第17.3項「ドキュメント変換」

17.1 フレックス・フィルタ・クラスおよびフレックス・フィルタ・アセットの理解

フレックス・フィルタでは、そのフィルタが割り当てられたフレックス・アセットに対して、処理後の操作を行います。フィルタは、関連付けられたアセットが保存されたときにコールされます。フィルタは、アセットの編集操作が取り消されるとコールされません。

1つのフレックス・アセットに、複数のフレックス・フィルタを割り当てることができます。アセットが保存されると、アセットの定義の「フィルタ」セクションで定義された順番で、フィルタは指定されたタスクを実行します。フレックス・フィルタが実行するタスクは、フィルタを定義するフレックス・フィルタ・クラスにより決まります。たとえば、Doc-Typeフィルタ・クラスで定義されるフレックス・フィルタは、そのクラスにより有効化され、アセットのMIMEタイプを決定したり、URLパスからファイル・タイプを抽出したりします。

各フレックス・フィルタは、属性に関連付けられており、アセット用に処理したデータでこの属性を更新します。これらの属性は導出属性と呼ばれます。導出属性は、フィルタが割り当てられているのと同じフレックス・ファミリに作成する必要があります。ただし、導出属性は厳密にはフレックス・フィルタの出力であり、アセットが保存されたときにのみアセットに追加されるので、アセット定義には指定しないでください。1つのアセットに複数のフィルタが割り当てられる場合、どのフィルタも、そのアセットに関連付けられた他のフィルタが出力した属性に依存しないようにしてください。

(WebCenter SitesのデータベースのFilters表に)フィルタが定義されている場合、そのフィルタは任意のアセット・タイプの子定義に適用できます。(フィルタは、アセット・タイプの親定義に適用することはできません。)特定のアセット・タイプに関連した特定の目的のためにフィルタが作成された場合、そのフィルタはそのアセット・タイプの子定義にのみ関連付ける必要があります。たとえば、「Media」アセットのイメージ・タイプを処理するようにフィルタが設計されている場合、そのフィルタは、テキストをベースにしたアセットに適用すると機能しません。

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

- 第17.1.1項「フレックス・フィルタ・クラス」

- 第17.1.2項「フレックス・フィルタ・アセット」

17.1.1 フレックス・フィルタ・クラス

フレックス・フィルタ・クラスには、フレックス・フィルタ・アセットの機能が実装されます。これらのクラスは、WebCenter SitesデータベースのFilters表に一覧表示されます。フレックス・フィルタ・アセットを作成する場合には、対象となるフレックス・フィルタ・クラスを選択します。

WebCenter Sitesに用意されているフレックス・フィルタ・クラスは次のとおりです。

- Doc-Type: 1つ以上のMIMEファイル・タイプを含むアセットからコンポーネントを抽出し、各ファイル・タイプを個々に名付けられた属性にマップします。

- サムネイル・クリエータ: イメージをサムネイルに変換します。

- フィールド・コピアー: システム定義された属性の内容をユーザー定義の属性にコピーします。

- ドキュメント変換: 登録された変換エンジン(SystemTransforms表で指定されたエンジン)を起動して、あるファイル・タイプのドキュメントを別のファイル・タイプのドキュメントに変換します。変換エンジンは、ドキュメント・トランスフォーマにコールを転送してドキュメントの変換を行うラッパーとして機能します。

WebCenter SitesのFiltersデータベース表に定義することにより、カスタム・フレックス・フィルタ・クラスを作成できます。カスタム・フレックス・フィルタ・クラスの作成方法については、第17.2.2項「カスタム・フレックス・フィルタ・クラスの定義」を参照してください。

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: システム定義された属性の値のコピー先とするフレックス属性の名前。

図19-2は、FirstSiteIIサンプル・サイトのメディア・フレックス・ファミリを使用して、フィールド・コピアー・フィルタを実装する方法の詳細な例を示しています。フィールド・コピアー・フィルタのこの例での目的は、親アセットの名前によりイメージ・アセットを分類することです。

ドキュメント変換フィルタ・クラス

ドキュメント変換フィルタ・クラスを定義する引数は次のとおりです。

- Document Transformer Name: SystemTransforms表に一覧表示されているとおりの、登録された変換エンジンの名前。デフォルトでは、SystemTransforms表に次の4つの値が一覧表示されています。

- CS: Convert to HTML
バイナリ・ファイルからHTMLへの変換を開始します。

- CS: Convert to HTML fragment
バイナリ・ファイルから、ヘッダー・タグなしのHTMLコーディングのファイルへの変換を開始します。

- CS: Convert to XML
バイナリ・ファイルからXMLへの変換を開始します。

- CS: Convert to Raw Text
バイナリ・ファイルからテキスト・フォーマットへの変換を開始します。

注意:

WebCenter Sitesでは、次のドキュメント・トランスフォーマを使用できます。

com.fatwire.transformer.tika.DocumentTransformerImpl

ドキュメント・トランスフォーマは、CS: Convert to Raw Textエンジンによって起動されたときに、ドキュメントを未加工のテキスト・ファイルに変換するようにコーディングされています。他のファイル・タイプに変換するには、そのファイル・タイプ用にドキュメント・トランスフォーマを作成して、(すでに登録されていないかぎりは)対応する変換エンジンに登録し、そのドキュメント・トランスフォーマをWebCenter Sitesに登録する必要があります。デフォルトの実装およびドキュメント変換ソリューションについては、第17.3項「ドキュメント変換」を参照してください。

- Input Attribute Name: フレックス・フィルタによって内容が変換されるフレックス属性の名前。ドキュメント変換フィルタについては、入力属性はblobタイプである必要があります。これは、ドキュメント変換フィルタがこの属性のファイルを検索するためです。

- Fail on Transform Error: 変換が正常終了しなかった場合に、エラー・メッセージが表示されるようにするかどうかを選択します。

- Output Attribute Name: ドキュメント変換の結果を格納するフレックス属性の名前。ドキュメント変換フィルタについては、出力属性はblobタイプである必要があります。これは、変換結果がファイルとして格納されるためです。
出力属性(フィールド)に格納されるデータは、入力属性のデータに由来するため、読取り専用です。このデータは、アセットが保存されるたびに、入力属性のソース・データから再生成されます。

- Output Document Extension: 結果として生成されるファイルに割り当てられるファイル拡張子。選択したDocument Transformer Nameに適したドキュメント拡張子を入力してください。たとえば、ドキュメント変換エンジンをCS: Convert to HTMLに指定した場合、ドキュメント拡張子はhtmまたはhtmlにする必要があります。

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

フレックス・フィルタ・アセットは、次の基準のすべてで定義されます。

- Filters表に登録されたフレックス・フィルタ・クラス。

- そのフィルタ・クラスに(引数を介して)渡された情報。これらの引数は、使用するデータ、フィルタのアクションに対する制約、およびアセットが保存されたときにフィルタリング・プロセスの結果を格納する場所を指定します。

フレックス・フィルタ・アセットを作成する場合、使用するフレックス・フィルタ・クラスを選択し、フィルタ・クラスのアクションに必要な引数の値を入力します。

フレックス・フィルタ・アセットを作成した後、それを適切なフレックス定義アセットに割り当てます。その後、コンテンツ・プロバイダがその定義のフレックス・アセットを保存するたびに、フィルタは割り当てられたアクションを自動的に実行します。手順の詳細は、第17.2.3項「フレックス・フィルタ・アセットの作成」を参照してください。

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

フレックス・フィルタを使用するには、まず、WebCenter Sitesデータベースにカスタム・フレックス・フィルタ・クラスを定義する必要があります。次に、そのクラスで機能が定義されているフレックス・フィルタ・アセットを作成することにより、カスタム・フレックス・フィルタ・クラスをアクティブ化します。

基本的な手順は次のとおりです。

1. カスタム・フレックス・フィルタ・クラス用の実装コードを提供するJavaクラスを作成します。手順は、第17.2.1項「フレックス・フィルタ・クラスの実装」を参照してください。

2. 新規フレックス・フィルタ・クラスを、WebCenter SitesデータベースのFilters表に定義します。手順は、第17.2.2項「カスタム・フレックス・フィルタ・クラスの定義」を参照してください。

3. カスタム・フレックス・フィルタ・クラスで定義されたフレックス・フィルタ・アセットを作成します。

1. フィルタの引数として参照される属性を作成します。

2. フレックス・フィルタ・アセットを作成し、目的のフレックス・フィルタ・クラスに割り当てます。

3. 新規フィルタ・アセットを子定義に追加します。

4. フィルタ・アセットを追加した定義に関連付けられたすべての関連アセットを再度保存します。

手順は、第17.2.3項「フレックス・フィルタ・アセットの作成」を参照してください。

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

- 第17.2.1項「フレックス・フィルタ・クラスの実装」

- 第17.2.2項「カスタム・フレックス・フィルタ・クラスの定義」

- 第17.2.3項「フレックス・フィルタ・アセットの作成」

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

カスタム・フレックス・フィルタを実装するには、AbstractFlexFilterクラスを拡張することにより、そのための新規Javaクラスを作成します。このフィルタ・クラスには、フィルタ要求の処理に必要なデフォルト機能がすべて含まれています。AbstractFlexFilterクラスを拡張し、フレックス属性にアクセスして導出属性値を設定することを目的とするカスタム・フレックス・フィルタ・クラスの実行例は、ソース・ファイルSampleFlexFilter.javaに提供されています。

フレックス・フィルタの機能は、抽象化インタフェースと呼ばれるパラメータにより実装されます。フレックス・フィルタは、フィルタリングしているアセットの特定の側面についてのみ知る必要があるため、抽象化インタフェースは、指定されたフレックス・アセットに対して機能を実行するために必要なアセット情報にのみフィルタがアクセスできるようにしています。表17-1に、フレックス・フィルタの実装に必要な抽象化インタフェース、および各抽象化インタフェースがフィルタに渡すアセット情報の一覧を示します。カスタム・フレックス・フィルタ・クラスの実装に使用される様々な抽象化インタフェースの詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

表17-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となります。

17.2.1.1 AbstractFlexFilterクラスの拡張

フレックス・フィルタ・クラスの実装を作成するために、AbstractFlexFilterクラスを拡張できます。このクラスはcom.openmarket.gator.flexfiltersパッケージ内にあります。新規フレックス・フィルタのJavaクラスを作成する場合、AbstractFlexFilterクラスのJavaコードからフィルタ機能に必要なメソッドをコールできます。これにより、カスタム実装の作成に必要なコードの量が簡略化されます。

メソッドがコールされると、フィルタのアセット識別子である、引数String filterIdentifierが提供されます。同じフィルタを異なるフレックス・アセット・ファミリに関連付けると、フィルタ識別子に、関連付けられたファミリのフィルタ定義が反映されます。この引数は、異なるアセット・ファミリが使用するフィルタを実装している場合に便利です。フィルタは、起動された時点でどのフレックス・ファミリの関連付けが使用されているかを知ることができます。

カスタム・フレックス・フィルタ・クラスの実装に使用される様々な抽象化メソッドの詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

必要な抽象化メソッド

すべてのフレックス・フィルタ実装で必要となる抽象化メソッドは次のとおりです。

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インタフェースはドロップダウン・リストを埋めるために、フィルタの作成または編集中にこのメソッドをコールします。

オプションの抽象化メソッド

次の抽象化メソッドは、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の場合、どんな値でも許容されます。このメソッドは、フィルタ・アセットに指定された引数値を有効化するために、フィルタ・アセットが作成または編集されているときに、WebCenter Sites Adminインタフェースによってコールされます。

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

この項では、カスタム・フレックス・フィルタ・クラスをWebCenter SitesデータベースのFilters表に定義する手順を説明します。この例では、CustomFilterという名前のフレックス・フィルタ・クラスを作成します。

カスタム・フレックス・フィルタ・クラスを定義するには:

1. カスタム・フレックス・フィルタ・クラス用の実装コードを含む.jarファイルまたはclassファイルを、WebCenter Sites製品のjarsを保持しているディレクトリにコピーします。

注意:

カスタム・フレックス・フィルタ・クラス用の実装コードを提供するJavaクラスの作成の詳細は、第17.2.1項「フレックス・フィルタ・クラスの実装」を参照してください。

- WebLogicの場合: app-server-install-dir/bea/path-to-domain/domain-name/applications/WEB-INF/lib

- WebSphereの場合: WebSphere-Installation-Directory/InstalledApps/WEB-INF/lib

2. Sites Explorerを開き、新規フィルタ・クラス用の行をFilters表に追加します。

1. ツリーで、「表」ノードを展開し、Filters表を選択します。

2. 「ファイル」→「新規」→「レコード」の順に選択します。

3. データベースで次の列に入力して、フィルタを定義します。

- name: WebCenter Sitesインタフェースに表示させるフィルタの名前を入力します。

- description: (オプション) フィルタ・クラスの目的についての短い要約を入力します。

- classname: フィルタ・クラスの実装の正確なクラス名(例: com.fatwire.firstsite.filter.SampleFlexFilter)を入力します。この名前は、WebCenter Sitesのクラスパスにロード可能である必要があります。

- args: (オプション) フィルタ用の入出力引数を入力します。引数のキー/値のペアは、アンパサンド(&)文字で区切られます (例: arg1=argument1&arg2=argument2)。これらの引数は、フィルタ・コンストラクタに渡され、その使用はフィルタの開発者に任されます。

注意:

フレックス・フィルタ・クラスの入出力引数をFilters表に定義しない場合、それらの引数はフレックス・フィルタ・クラスのコードに定義できます。詳細は、第17.2.1項「フレックス・フィルタ・クラスの実装」を参照してください。

4. 「ファイル」→「保存」の順に選択します。
新規フィルタ・エントリは次のようになります。

フィルタ・クラスは、フィルタ・アセットの「新規」フォームおよび「編集」フォームの「フィルタ」ドロップダウン・リスト内のオプションとして表示されます。

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

この項では、フレックス・フィルタ・アセット作成の手順を説明します。この例では、FirstSiteIIサンプル・サイトの「Media」フレックス・ファミリに対して、FSII_CustomFlexFilterという名前のフレックス・フィルタ・アセットを作成します。

フィルタ・アセットの作成前に、入出力の属性として使用するフレックス属性が存在している必要があります。既存の属性の値が上書きされないようにするために、カスタム・フレックス・フィルタの引数が参照する属性を新規作成できます。この例では、タイプstringのMedia属性を2つ作成しました。入力属性として使用するFSII_CustomInputと、出力属性として使用するFSII_CustomOutputです。

フレックス・フィルタ・アセットを作成するには:

1. 一般管理者としてAdminインタフェースにログインし、フレックス・フィルタ・アセットを作成するサイトを選択します(この例ではFirstSiteIIサンプル・サイト)。

2. フィルタの入出力属性が参照する属性を作成します(まだ定義されていない場合)。次の要件に注意してください。

- フレックス・フィルタがドキュメント変換フィルタ・クラスを使用している場合、入出力属性のタイプはblobである必要があります。

- どのフレックス・フィルタでも、入力属性、出力属性、フレックス・フィルタはすべて、同一のフレックス・ファミリに属している必要があります。

フレックス属性の作成方法については、第16.3.6項「手順4: フレックス属性の作成」を参照してください。

3. 関連付けられたフレックス・ファミリ(この例では「Media」フレックス・ファミリ)に対するフレックス・フィルタ・アセットを作成します。

1. スタート・メニュー項目から「新規」をクリックします。

2. アセット・タイプのリストで、作成するフィルタのタイプを選択します。この例では、New Media Filterです。
「新規」フィルタ・フォームが表示されます。

3. 次のフィールドに入力します。

1. 「名前」フィールドで、このフィルタの一意の名前を入力します(この例ではFSII_CustomFlexFilterを使用)。

2. 「説明」フィールドに、フィルタの機能を要約した短い説明を入力します。

3. 「フィルタ」ドロップダウン・リストで、カスタム・フィルタに割り当てた名前と一致するフィルタ定義を選択します(この例では、CustomFilterを選択)。次に「引数の取得」をクリックします。

4. 「引数」フィールドで、フレックス・フィルタ・アセットに対する入力および出力の引数を指定します。「追加」をクリックして、フィルタに引数を追加します。

4. 「保存」をクリックして、フィルタを保存します。

4. 新規フィルタ・アセットを追加する先の子定義を検索します(この例では、フィルタを「Media」子定義FSII_Imageに追加します)。

1. スタート・メニュー項目から「検索」をクリックします。

2. アセット・タイプのリストで、フィルタを追加する先のアセット定義の目的タイプを選択します(この例ではFind Media Definition)。

3. 検索フィールドに、フィルタを追加する先の定義の名前を入力します(この例ではFSII_ImageCategory)。

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

5. 検索結果のリストで目的の定義に移動して、その「編集」アイコンをクリックします(この例ではFSII_Image)。
定義の「編集」フォームが開きます。

5. 「編集」フォームで、フィルタと入力引数を定義に追加します。

1. 「属性」フィールドで、「使用可能」リスト内の入力属性を強調表示して、「選択済」リストに移動します(この例ではFSII_CustomInput)。

2. 「フィルタ」フィールドで、「使用可能」リスト内の目的のフレックス・フィルタを強調表示して、「選択済」リストに移動します(この例ではFSII_CustomFlexFilter)。

注意:

新規フィルタを追加します。新規フィルタが依存または共有する属性を作成または変更するフィルタがほかにあれば、そのフィルタの後に追加します。

3. 「保存」をクリックします。

6. フィルタを追加した定義に関連付けられたすべての既存アセットを検索し、再度保存します。これにより、フィルタは出力属性(FSII_CustomOutput)に、入力属性(FSII_CustomInput)からの導出値を移入できます。例:

1. アプリケーション・バーで、「Contributor」アイコンをクリックし、WebCenter SitesのContributorインタフェースに切り替えます。

2. 「検索」フィールドで、下矢印をクリックして「検索タイプ」メニューを開きます。「検索タイプ」メニューで、手順5で変更した定義に関連付けられたアセットのタイプを選択します(この例ではFind Media)。虫めがねボタンをクリックします。
「検索」タブが開き、検索結果が表示されます。

3. アセットを再度保存します。アセットのツールバーで、「保存」アイコンをクリックします。

4. アセットを調査します。アセットのツールバーで、「調査」アイコンをクリックします。

前述のイメージは、この項で作成したフィルタを含む、複数のフィルタを起動するフレックス・アセットの編集結果です。デフォルトでは、「Media」アセットは「FSII_FieldCopier」フィルタ、「FSII_ImageType」フィルタおよび「FSII_ThumbnailExtractor」フィルタをコールします。この例では、「Media」アセットも、入力属性(MediaCustomInput)の値をとるFSII_CustomFlexFilterフィルタをコールし、導出文字列値を出力属性(MediaCustomOutput)に挿入します。

17.3 ドキュメント変換

ドキュメント変換フレックス・フィルタの実装に必要なコンポーネントは次のとおりです。

- SystemTransforms表に登録され、目的のファイル・タイプを示す名前が付けられた変換エンジン。たとえば、CS:Convert to Raw Textのようになります。

- ドキュメント変換(たとえば、バイナリ・ファイルを未加工のテキスト・ファイルに変換する)を行うカスタム・クラスである、ドキュメント・トランスフォーマ。ドキュメント・トランスフォーマ・クラスは、com.fatwire.transformer.common.DocumentTransformerインタフェースを実装します。

- 変換エンジンのドキュメント・トランスフォーマへの関連付けに使用されるtransformer-formats.xmlファイル。WebCenter SitesのWEB-INF/classesフォルダにあるこのファイルは、目的のファイル・タイプとドキュメント・トランスフォーマを指定します。

ドキュメント変換フレックス・フィルタが起動されると、変換エンジンはラッパーとして機能します。エンジンは(transformer-formats.xmlファイル経由で)ドキュメント・トランスフォーマへコールを転送し、ドキュメント・トランスフォーマがファイル変換を実行します。

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

- 第17.3.1項「デフォルトのソリューション」

- 第17.3.2項「カスタム・ソリューション」

- 第17.3.3項「ドキュメント変換のカスタマイズ」

- 第17.3.4項「次の手順」

17.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のインタフェースからドキュメント変換オプションとしてアクセスできるようになります。

17.3.2 カスタム・ソリューション

前述したデフォルトのソリューション以外のドキュメント変換のソリューションが必要な場合は、次のコンポーネントの作成とカスタマイズが必要です。

1. 目的のファイル・タイプ用のドキュメント・トランスフォーマを作成して、デプロイします。

2. 目的のファイル・タイプ用の変換エンジンを登録します。

3. ドキュメント・トランスフォーマと目的のファイル・タイプを指定するようにtransformer-formats.xmlファイルを構成します。(このxmlファイルは、複数のドキュメント・トランスフォーマをサポートします。)

4. この章で記述しているように、ドキュメント変換フレックス・フィルタを実装します。

手順の詳細は、第17.3.3項「ドキュメント変換のカスタマイズ」を参照してください。

17.3.3 ドキュメント変換のカスタマイズ

WebCenter Sitesには、デフォルトのドキュメント・トランスフォーマとしてcom.fatwire.transformer.tika.DocumentTransformerImplが用意されています。これは、CS:Convert to Raw Textエンジンによって起動されたときに、未加工のテキスト・ファイルを出力するようにコーディングされています。目的のファイル・タイプが未加工のテキスト以外であることが必要な場合は、次の手順を実行して、フレックス・フィルタがサポートするコンポーネントを作成し、登録する必要があります。

ドキュメント・トランスフォーマ・フレックス・フィルタを実装する前に:

- 第17.3.3.1項「ドキュメント・トランスフォーマの作成とデプロイ」

- 第17.3.3.2項「変換エンジンの登録」

- 第17.3.3.3項「ドキュメント・トランスフォーマの登録」

17.3.3.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の場合:

app-server-install-dir/bea/path-to-domain/domain-name/applications/WEB-INF/lib

- WebSphereの場合:

WebSphere-Installation-Directory/InstalledApps/WEB-INF/lib

3. 第17.3.3.2項「変換エンジンの登録」に進みます。

17.3.3.2 変換エンジンの登録

注意:

ドキュメント・トランスフォーマをHTML、HTMLフラグメント、XML以外の出力ファイルに書き込む場合は、この注意の下の手順1に進んでください。それ以外の場合は、この注意を読み進めてください。

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

WebCenter Sitesには、CS:Convert to Raw Textに加えて、次の変換エンジンが用意されています。

- CS: Convert to HTML

- CS: Convert to HTML fragment

- CS: Convert to XML

これらのエンジンはすべて、デフォルトでSystemTransforms表に登録されます。ドキュメント・トランスフォーマをHTML、HTMLフラグメントまたはXMLの出力ファイルに書き込む場合は、対応するエンジンを使用してください。次を実行します。

- Sites Explorerを開きます。

- SystemTransforms表を選択します。

- 必要なエンジンを見つけます。たとえば、CS:Convert to HTMLです。
エンジンのtargetフィールドの値をメモします。この値を、第17.3.3.3項「ドキュメント・トランスフォーマの登録」に記載されているtransformer-formats.xmlファイルの<mime-type>に入力します。argsフィールドで、この変換エンジンに適した引数を設定します。たとえば、exporttype=HTMLと入力します。

- 第17.3.3.3項「ドキュメント・トランスフォーマの登録」に進みます。

変換エンジンを登録するには:

1. Sites Explorerを開き、次のように、新規変換エンジン用の行をSystemTransforms表に追加します。

1. SystemTransforms表を選択して、表の作業領域をクリックします。

2. 「ファイル」→「新規」→「レコード」の順に選択して、新規の行に次のように入力します。

1. name列に、変換エンジンの名前を入力します。たとえば、ConvertToPDFと入力します。

2. description列に、エンジンの説明を入力します。たとえば、Convert to PDFと入力します。

3. target列に、text/<filetype>と入力します。たとえば、text/PDFと入力します。

注意:

次の項(第17.3.3.3項「ドキュメント・トランスフォーマの登録」)では、<mime-type>のターゲット値を使用します。

4. classname列に、エンジンのデフォルトのクラス名com.fatwire.transformer.common.FWTransformerを入力します。

5. この変換エンジンに適した引数があれば、argsフィールドで設定します。たとえば、exporttype=PDFと設定します。

3. 変更を保存します。

2. 次の手順(第17.3.3.3項「ドキュメント・トランスフォーマの登録」)に進みます。

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

ドキュメント・トランスフォーマを、WebCenter SitesのWEB-INF/classesフォルダにあるtransformer-formats.xmlファイルに登録します。参考のため、デフォルトのファイルを次に示します。

注意:

<mime-type>を、変換エンジンのtargetフィールドの値 (第17.3.3.2項「変換エンジンの登録」で設定されたtargetの値)に設定します。

(第17.3.3.1項「ドキュメント・トランスフォーマの作成とデプロイ」で作成した)ドキュメント・トランスフォーマのクラス名を指定します。

複数のドキュメント・トランスフォーマを指定するには、各トランスフォーマに対してエントリを繰り返します。<mime-type>の値によって、変換エンジンによってどのドキュメント・トランスフォーマが起動されるかが決まります。

例17-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>

17.3.4 次の手順

第17.3.3項「ドキュメント変換のカスタマイズ」に示すように、ドキュメント変換コンポーネントを作成して登録すると、対応するドキュメント変換フレックス・フィルタを実装できるようになります。この章に掲載している手順を使用してください。

18 属性エディタの設計

属性エディタは、管理システム上のWebCenter Sitesインタフェースでフレックス・アセットまたはフレックス親アセットの「新規」フォームまたは「編集」フォームに属性が表示される場合に、その属性のデータの入力方法を指定します。

属性エディタを属性に割り当てると、その属性用として通常使用されるデフォルトの入力メカニズム(スタイル)のかわりに、その属性エディタが使用されます。デフォルトの入力スタイルは、その属性のデータ型に基づいています。

属性エディタによって属性の入力メカニズムの形式が設定されるため、フレックス属性を設計するのと同じように属性エディタを設計します。属性エディタはアセットであるため、ワークフローとリビジョンの追跡機能を使用して、他のタイプのアセットと同じように属性エディタを管理できます。

この章には次の項が含まれます。

- 第18.1項「属性エディタの理解」

- 第18.2項「属性エディタの作成」

- 第18.3項「属性エディタのカスタマイズ」

- 第18.4項「属性エディタの編集」

18.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では、属性のデータ型に基づいてその属性のデフォルトの入力スタイルが使用されます。デフォルト・スタイルのリストについては、第11.3.3.2項「属性のデフォルトの入力スタイル」を参照してください。デフォルトの入力スタイルが属性にとって十分な場合は、属性エディタを作成する必要はありません。

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

- 第18.1.1項「presentationobject.dtdファイル」

- 第18.1.2項「属性エディタ・アセット」

- 第18.1.3項「属性エディタのエレメント」

- 第18.1.4項「属性エディタのエレメントの規則」

18.1.1 presentationobject.dtdファイル

presentationobject.dtdファイルでは、属性エディタを通じて実装できるすべての入力タイプ(プレゼンテーション・オブジェクト)が定義されています。デフォルトのpresentationobject.dtdファイルでは、9個の入力スタイル・タグと、これらのタグによって属性エディタから表示エレメントに渡すことができる引数が定義されています(第18.1.3項「属性エディタのエレメント」を参照)。

次に、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 Web Center 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>

18.1.1.1 presentationobject.dtdファイルの規則

デフォルトで使用可能になっているもの以外に、カスタム属性エディタを作成する場合は、まずXML入力スタイル・タグであるPRESENTATIONOBJECTタグをpresentationobject.dtdファイル内で定義する必要があります。新しいPRESENTATIONOBJECTタグを定義するには、次の操作を実行する必要があります。

- 新しいタグ(プレゼンテーション・オブジェクト)を<!ELEMENT PRESENTATIONOBJECT...>文内のリストに追加します。

- 新しいタグ(プレゼンテーション・オブジェクト)とこのタグが受け取る引数を定義する<!ELEMENT...>セクションを追加します。.dtdファイルの通常の構文ルールに従うとともに、presentationobject.dtdファイルで使用されている規則に従います。

18.1.2 属性エディタ・アセット

属性エディタ・アセットは、XMLコードを格納しているか、.xmlファイルを参照しています。

そのXMLコードは1つのことを実行します。つまり、入力タイプがオプション(チェック・ボックス、ラジオ・オプション、ドロップダウン・リストなど)を提供するものである場合は、これらのオプションの値を提供します。

WebCenter Sitesでは、新しい属性エディタ・アセットを作成するために使用できるサンプル・コードが含まれた9個のテキスト・ファイルが用意されていますが、属性エディタ・アセット自体は用意されていません。開発者は、どのオプションも使用するデータに適したものになるように、これらのサンプル・コードをカスタマイズする必要があるからです。

属性エディタを作成する場合は、本書のHTML版からコードをカット・アンド・ペーストすることも(この項の後にいくつかのサンプルを掲載しています)、システム上のインストール・ディレクトリのSamplesサブディレクトリに配置されたテキスト・ファイルを使用することもできます。

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

- 第18.1.2.1項「構文とデフォルト・タグ」

- 第18.1.2.2項「CHECKBOXESの例」

- 第18.1.2.3項「CKEditorの例」

- 第18.1.2.4項「PICKASSETの例」

- 第18.1.2.5項「PULLDOWNの例」

- 第18.1.2.6項「RADIOBUTTONSの例」

- 第18.1.2.7項「TEXTAREAの例」

- 第18.1.2.8項「TEXTFIELDの例」

- 第18.1.2.9項「TYPEAHEADの例」

- 第18.1.2.10項「UPLOADERの例」

18.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タグは、その属性エディタ用に使用する表示エレメントの名前と完全に一致している必要があります。したがって、カスタム属性エディタの新しいタグを定義する場合は、作成するエレメントにはそのタグと同じ名前を付ける必要があります。

エレメントの詳細は、第18.1.3項「属性エディタのエレメント」を参照してください。属性エディタのコード・サンプルについては、次の各項を参照してください。

- 第18.1.2.2項「CHECKBOXESの例」

- 第18.1.2.3項「CKEditorの例」

- 第18.1.2.4項「PICKASSETの例」

- 第18.1.2.5項「PULLDOWNの例」

- 第18.1.2.6項「RADIOBUTTONSの例」

- 第18.1.2.7項「TEXTAREAの例」

- 第18.1.2.8項「TEXTFIELDの例」

- 第18.1.2.9項「TYPEAHEADの例」

- 第18.1.2.10項「UPLOADERの例」

18.1.2.2 CHECKBOXESの例

presentationobject.dtdではCHECKBOXESタグが定義されています。このタグを使用する属性エディタはCHECKBOXESエレメントを呼び出し、このエレメントはその属性の一連のチェック・ボックスを作成します。

CHECKBOXESタグは、次のパラメータを受け取ります。

- 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です。

次の属性エディタ・コードでは、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パラメータの使用例を示すサンプル・コードについては、第18.1.2.5項「PULLDOWNの例」を参照してください。

データ型に関する注意

CHECKBOXES属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset (assetの場合、アセット名を返す問合せアセットの名前を指定する必要があります)

18.1.2.3 CKEditorの例

presentationobject.dtdではCKEDITORタグが定義されています。このタグを使用する属性エディタはCKEDITORエレメントを呼び出し、このエレメントはCKEditorを起動します。フレックス・アセットの作成者は、属性の値をそのウィンドウで入力します。

- CKEditorアプリケーションをインストールして正しく構成している必要があります。

- CKEditorは、属性のデータ型がblobに設定されている場合にのみ使用することを強くお薦めします。blobをデータ型として使用している場合は、フィールドのサイズ設定について心配する必要はありません。

CKEDITORタグは、次のパラメータを受け取ります。

次のコードには、幅が400ピクセルで高さが200ピクセルのテキスト・ボックスを作成するCKEDITORタグが含まれています。

- EMBEDDEDLINKS: YESに設定されている場合、ユーザーは他のアセットへのリンクを作成できます。デフォルト値: NO

- ALLOWEDASSETTYPES: CKEditorを通じて組込み可能またはリンク可能なアセット・タイプを指定できます。デフォルト値: ALL

- IMAGEASSETTYPE: イメージ・ピッカーが使用するイメージのアセット・タイプを指定します。

- DEPTYPE: メイン・アセットと埋込みアセットの間の承認依存性。有効なオプションは、EXISTSとEXACTです。デフォルト値: EXACT

- MAXVALUES: このパラメータは、1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、追加できる値は10個のみです(「追加」ボタンを使用)。デフォルト値はありません。

- SCRIPT: エディタ内でスクリプトを実行可能にします。true/false値をとります。デフォルト値: false

- MAXLENGTH: (CKEditorの「ソース」ボタンをクリックすると表示される)CKEditorのソース・ビュー内の文字数。デフォルト値: -1 (無制限)

- INSTRUCTION: フィールドのヘルプを提供するために使用されます。

CKEDITORタグは、CKEditorインスタンスの外観をカスタマイズするためのパラメータも受け取ります。1組のパラメータ・セットがWebCenter Sitesに定義されています。他のセットは、CKEditor Webサイトにあります。

WebCenter Sitesに定義されているパラメータは、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フィールドに追加された場合、WebCenter Sitesでは認識されません。CONFIGパラメータおよびCONFIGOBJパラメータの説明は次のとおりです。

- CONFIG: デフォルトまたはカスタムのCKEditor構成ファイルへの相対パスを指定します。たとえば、CONFIG="myconfig.js"と設定すると、CKEditorベース・パス(CKEditorソース・フォルダ)からカスタムのmyconfig.jsファイルがロードされます。ベース・パスは、futuretense_xcel.iniファイルの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を使用することをお薦めします。

18.1.2.4 PICKASSETの例

presentationobject.dtdではPICKASSETタグが定義されています。このタグを使用する属性エディタはPICKASSETエレメントを呼び出します。このエレメントは、ユーザーがツリーまたは検索結果リストからアセットをドラッグ・アンド・ドロップできる「ドロップ・ゾーン」フィールドを作成します。アセットが「ドロップ・ゾーン」にドロップされると、破線の境界線で囲まれたボックス内にアセットの名前が表示されます。アセットの名前をポイントすると、ツールチップが開いて、アセットに関する情報が表示されます。ツールチップのルック・アンド・フィールをカスタマイズするなど、PICKASSET属性エディタの動作を変更するには。

このタグは、MAXVALUESパラメータをとることができます。MAXVALUESパラメータは、1つの複数値属性に追加できる値の数を制限します。たとえば、MAXVALUESが10に設定された場合、「追加」ボタンを使用して追加できる値は10個のみです。デフォルト値はありません。PICKASSET属性エディタをカスタマイズする場合は、第III部「Contributorインタフェースのカスタマイズ」を参照してください。

次に、PICKASSET属性エディタを作成するためのコードを示します。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="PickAsset">

<PICKASSET>
</PICKASSET>
</PRESENTATIONOBJECT>

データ型に関する注意

PICKASSET属性エディタは、assetのデータ型の属性にのみ適しています。

18.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...

次の属性エディタ・コードでは、リストに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パラメータを使用する方法を示すサンプル・コードについては、第18.1.2.2項「CHECKBOXESの例」を参照してください。

データ型に関する注意

PULLDOWN属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset

ドロップダウン・リストは、asset型の属性のデフォルトの入力スタイルです。このリストには、その型のすべてのアセットが表示されます。問合せアセットを使用してドロップダウン・リスト内のアイテムをさらに制限し、リストにその型のすべてのアセットが表示されないようにするには、PULLDOWN属性エディタを使用します。

18.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パラメータの使用例を示すサンプル・コードについては、第18.1.2.5項「PULLDOWNの例」を参照してください。

データ型に関する注意

RADIONBUTTON属性エディタは、次のデータ型の属性に適しています。

- date

- float

- integer

- money

- string

- asset (assetの場合、アセット名を返す問合せアセットの名前を指定する必要があります)

注意:

date型のRadioButton属性エディタは、presentation.dtdのサーバーのタイムゾーン(またはJVMで設定されているタイムゾーン)に入力された日付値を解釈します。この値は、アセット・フォームのレンダリング時に、ユーザーのタイムゾーンに変換されます。

タイムゾーンに関係なく同じ日付値が表示されるようにしたい場合は、string型の属性エディタの使用を検討してください。

18.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: メイン・アセットが編集、承認および再パブリッシュされたときに、埋込みアセットが編集されていた場合は、埋込みアセットも承認および再パブリッシュされる必要があります。

次の属性エディタ・コードでは、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のデータ型を使用します。

18.1.2.8 TEXTFIELDの例

presentationobject.dtdではTEXTFIELDタグが定義されています。このタグを使用する属性エディタは「新規」フォームと「編集」フォームからTEXTFIELDエレメントを呼び出し、このエレメントはその属性のテキスト・フィールドを作成します。ただし、その属性が「調査」フォームに表示される場合は、その属性エディタはDisplayTEXTFIELDエレメントを使用します。

TEXTFIELDタグは、次のパラメータを受け取ります。

- XSIZE: フィールドの長さ(文字数)。

- MAXCHARS: フィールドに入力できる文字数(最大256文字)。

- BLANKED: 属性の値が「調査」フォームに表示される場合に、その値を一連のアスタリスクに置き換えるかどうかを指定します。たとえば、password属性を作成した場合は、パスワードの値が「調査」フォームに表示されないことが望ましいです。有効なオプションは、YESおよびNOです。デフォルトはNOです。
BLANKEDパラメータを使用すると自動的に、そのフィールドは「新規」フォームと「編集」フォーム上では「調査」フォーム上とは異なる動作を示すことが必要になるため、TEXTFIELDタグはデフォルトで2つの使用可能なエレメントの両方とともに提供されています。

次の属性エディタ・コードでは、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

18.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」という文字または言葉で始まるすべてのアセットが検出されます。先行入力の入力ボックスに入力すると、(次に示すように)ドロップダウン・メニューの最初の結果が自動的に入力されます。

自動入力されたアセットを選択する場合は、キーボードの[Enter]を押します。ユーザーは、(キーボードの上矢印と下矢印を使用してドロップダウン・メニュー内を移動して)目的のアセットを選択し、[Enter]キーを押すか、マウスを使用して目的のアセットをクリックすることで、ドロップダウン・メニューから一度に1つの任意の結果を選択することもできます。アセットを選択すると、ドロップダウン・メニューの下にそのアセットが表示されます。ユーザーが選択したアセットをポイントすると、(次に示すように)ツールチップが表示されます。

たとえばツールチップのルック・アンド・フィールをカスタマイズするなど、TYPEAHEAD属性エディタの動作を変更するには、第III部「Contributorインタフェースのカスタマイズ」を参照してください。

データ型に関する注意

TYPEAHEAD属性エディタは、assetのデータ型の属性にのみ適しています。

18.1.2.10 UPLOADERの例

presentationobject.dtdではUPLOADERタグが定義されています。このタグを使用する属性エディタはUPLOADERエレメントを呼び出し、このエレメントはアップロード属性を作成します。アップロード・フィールドは、任意のタイプのファイルをアップロードできます。ただし、アップロードできるファイルのタイプを制限するには、FILETYPESパラメータを使用します。

ユーザーがファイルのアップロードをクリックすると、(次に示すように)アップロードの進行状況がアセットのツールバーに表示されます。

アップロードされた各ファイルのサムネイル・イメージがアップローダ・フィールドに表示されます。ユーザーがアップロードされたイメージ・ファイルのサムネイルをクリックすると、イメージは実際のサイズでオーバーレイに表示されます。アップロードされたファイルがイメージでない場合、アップローダ・フィールドにそのファイル・タイプに固有のサムネイル・イメージが表示されます。WebCenter Sitesに特定のファイル・タイプのサムネイル・イメージがない場合、かわりに任意のイメージが表示されます。

ユーザーがイメージ・ファイルのサムネイル・イメージをポイントすると、そのファイルの名前、タイプおよび大きさがツールチップに表示されます。ユーザーがイメージではないファイルのサムネイルをポイントすると、そのファイルの名前とタイプがツールチップに表示されます。

UPLOADERタグは、次のパラメータを受け取ります。

- MAXFILESIZE: アップロード可能なファイルの最大サイズを指定します。このパラメータの有効な単位は、B、KB、MBおよびGBです。デフォルト値: 1024MB。デフォルト単位: 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のデータ型の属性にのみ適しています。

18.1.3 属性エディタのエレメント

対応する属性エディタから渡される入力値を受け取るエレメントは、フォームに表示されるときの対象属性の形式と動作のベースとなるロジックを提供します。たとえば、このロジックは、追加の値をフィールドに入力可能にするために、複数値属性のループ・シーケンスを実行する場合があります。

次に、ElementCatalog表のOpenMarket/Gator/AttributeTypesに配置されているデフォルトのフレックス属性表示エレメントを示します。これらのエレメントの名前は、presentationobject.dtdファイルで定義されているカスタムXMLタグの名前と完全に一致しています。

表18-1 属性エディタのエレメント

エレメント

説明

CHECKBOXES

属性の入力スタイルを一連のチェック・ボックス・オプションとして形式設定します。属性エディタは、これらのオプションの名前を指定するか、これらの名前を取得するために使用する問合せアセットの名前を指定する必要があります。

CKEDITOR

CKEditorテキスト・エディタを呼び出します。属性エディタは、テキスト・ボックスの高さと幅のピクセル数を指定する必要があります。

PULLDOWN

属性の入力スタイルをドロップダウン・リスト付きの選択フィールドとして形式設定します。属性エディタは、リストに表示されるアイテムを指定するか、それらの値を取得するために使用する問合せアセットの名前を指定する必要があります。

RADIOBUTTONS

属性の入力スタイルを一連のラジオ・オプションとして形式設定します。属性エディタは、これらのオプションの名前を指定するか、これらの名前を取得するために使用する問合せアセットの名前を指定する必要があります。

TEXTAREA

属性の入力スタイルをテキスト・ボックスとして形式設定して、このテキスト・ボックスで埋込みリンクが許可されるかどうかをユーザーが指定するためのラジオ・ボタンを表示します。属性エディタは、このボックスのX軸方向とY軸方向のサイズを指定する必要があります。

TEXTFIELD

属性の入力スタイルをテキスト・フィールドとして形式設定します。属性エディタは、このフィールドの長さと入力可能な文字数を指定する必要があります。

DisplayTEXTFIELD

「調査」フォームに表示されるときのテキスト・フィールド属性値の表示形式を設定します。属性エディタがBLANKEDパラメータをYESに設定した場合は、このエレメントはフィールドの値を一連のアスタリスクとして表示します。通常は、パスワード・フィールド用に使用されます。

PICKASSET

属性の入力スタイルを、ユーザーがツリーまたは検索結果リストからアセットをドラッグ・アンド・ドロップできる「ドロップ・ゾーン」フィールドとして形式設定します。

PICKFROMTREE

非推奨です。PICKASSETを使用してください。

TYPEAHEAD

属性の入力スタイルをドロップダウン・メニュー付きの先行入力の入力ボックスとして形式設定します。アセットがアセットの「新規」または「編集」ビューに表示され、ドロップダウン・フィールドの下矢印がクリックされると、ドロップダウン・メニューに、ユーザーが選択できるアセットの名前が表示されます。ドロップダウン・メニューに一度に表示される結果の数を制限するには、PAGESIZEパラメータを使用します。

UPLOADER

アップロード属性を作成します。アップロード・フィールドは、任意のタイプのファイルをアップロードできます。アップロードできるファイルのタイプを制限するには、FILETYPESパラメータを使用します。

18.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: この型の属性のデフォルトの入力スタイルを使用するかどうかを指定します。リストについては、第11.3.3.2項「属性のデフォルトの入力スタイル」を参照してください。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)。

例については、第18.3項「属性エディタのカスタマイズ」を参照してください。

18.2 属性エディタの作成

この章やサンプル・テキスト・ファイルに掲載されているサンプルXMLコードを使用して属性エディタを作成するには、次の手順を実行します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「新規」をクリックして、ショートカット・リストから「新規属性エディタ」を選択します。
「新規属性エディタ」フォームが表示されます。

5. 「名前」フィールドをクリックして、最大64文字(空白は除く)の一意の名前を入力します。

6. 「説明」フィールドをクリックして、この属性エディタの目的を簡潔に記述します。

7. 「XML」フィールドをクリックします。本書のHTML版から、またはインストール・ディレクトリのSamplesサブディレクトリにあるサンプル・テキスト・ファイルから、適切なサンプルXML属性エディタ・コードをカット・アンド・ペーストします。

8. コードを必要に応じて編集します。たとえば、CHECKBOXESまたはRADIOBUTTONSの属性エディタを作成する場合は、これらのチェック・ボックスまたはラジオ・ボタンの名前を指定する必要があります。PULLDOWN属性エディタを作成する場合は、このドロップダウン・リストの値を指定する必要があります。
属性エディタのコーディングの詳細は、第18.1.2項「属性エディタ・アセット」を参照してください。

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

注意:

もう1つの方法は、属性エディタのXMLを別個の.xmlファイル内にコーディングすることです。この場合は、コードを「XML」フィールドに直接入力するかわりに、「ファイル内のXML」フィールドの横にある「参照」ボタンをクリックして、そのファイルを選択します。

10. この属性エディタを管理システムに対してパブリッシュする前に、この属性エディタを承認する必要があります。

注意:

この属性エディタで問合せアセットを使用する場合は、この属性エディタとその問合せアセットの両方を必ず承認してください。

属性エディタとその問合せアセットの間の依存性は、その属性エディタ内のXMLコードで指定されるため、承認システムは、その依存性を検知することはできず、その問合せアセットが管理システム上に存在することを確認できません。

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

独自のカスタム属性エディタを作成するための最適な方法は、サンプルの属性エディタ・コードとサンプルの表示エレメントからできるかぎり多くの内容をコピーすることです。

新しい入力スタイルを作成する必要がある場合は(いずれのデフォルトPRESENTATIONOBJECTタグも使用できません)、属性エディタを定義するpresentationobject.dtdファイルに新しいPRESENTATIONOBJECTセクションを追加する必要があります。このファイルへの追加の詳細は、第18.1.1項「presentationobject.dtdファイル」を参照してください。

カスタムのPRESENTATIONOBJECTタグを作成する場合は、このタグに対して次のような適切な表示エレメントも提供する必要があります。

- 必須: 属性が「新規」フォームまたは「編集」フォームに表示される場合に、その属性を形式設定する(編集メカニズムを表示する)エレメント。

- 属性が「調査」フォームに表示される場合に、その属性を形式設定するエレメント。

- オプション: データベースに保存される前の属性データを形式設定するエレメント。

属性エディタの表示エレメントで使用される変数と規則については、第18.1.3項「属性エディタのエレメント」を参照してください。

ファイルをアップロードできる属性エディタを作成またはカスタマイズする場合(たとえば、UPLOADER属性エディタをカスタマイズする場合)は、アップロード対象のファイルが有効であることを確認するカスタム・ロジックを属性エディタ・コードに追加できます。詳細は、第18.3.2項「アップロード対象のファイルを検証するためのカスタム・ロジックの追加」を参照してください。

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

この例では、ユーザーが適切な権限を持っていない場合にテキスト・ボックスを使用不能にする属性エディタを作成するために、presentationobject.dtdファイル内のTEXTAREAタグの記述内容およびTEXTAREAエレメントをカスタマイズする方法を示します。

この作業は次の3つのステップからなります。

- 手順1: presentationobject.dtd内のTEXTAREAタグの記述内容を編集して、PERMISSIONSという名前の新しいパラメータをサポートします。

- 手順2: 属性エディタのコードを記述して、属性エディタを作成します。

- 手順3: PERMISSIONSの値をチェックするようにTEXTAREAエレメントを編集します。

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

新しいパラメータをサポートするには、presentationobject.dtd内のTEXTAREAの記述内容に1つのコード行を追加します。新たに追加したコード行は8行目です。1行目から7行目は、TEXTAREAタグのデフォルトの記述内容です。

1. <!-- TEXTAREA: A text area of a specific size. You must specify

2. -- the x and y dimensions; the wrap style defaults to soft.

3. -->

4. <!ELEMENT TEXTAREA ANY>

5. <!ATTLIST TEXTAREA XSIZE CDATA #REQUIRED>

6. <!ATTLIST TEXTAREA YSIZE CDATA #REQUIRED>

7. <!ATTLIST TEXTAREA WRAPSTYLE (OFF | SOFT | HARD) "SOFT">

8. <!ATTLIST TEXTAREA PERMISSION CDATA>

手順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>

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

3つ目のステップはTEXTAREAエレメントの編集です。56行目から70行目、123行目から125行目、および172行目から174行目は、PERMISSIONパラメータの値に基づいてフィールドを使用可能または使用不能にする新しいコードです。

1. <?XML VERSION="1.0"?>

2. <!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

3. <FTCS Version="1.1">

4. <!-- OpenMarket/Gator/AttributeTypes/TEXTAREA

5. --

6. -- INPUT

7. --

8. -- OUTPUT

9. --

10. -->

11. <!-- Display one TEXTAREA per attribute value -->

12. <IF COND="Variables.MultiValueEntry=no">

13. <THEN>

14. <!-- Don't want default display field -->

15. <setvar NAME="doDefaultDisplay" VALUE="no"/>

16. <!-- Get all parameters from Attribute Editor xml -->

17. <presentation.getprimaryattributevalue

18. NAME="Variables.PresInst"

19. ATTRIBUTE="FONTSIZE" VARNAME="FONTSIZE"/>

20. <if COND="Variables.errno!=0">

21. <then>

22. <setvar NAME="FONTSIZE" VALUE="2"/>

23. <then>

24. </if>

25. <presentation.getprimaryattributevalue

26. NAME="Variables.PresInst"

27. ATTRIBUTE="WRAPSTYLE" VARNAME="WRAPSTYLE"/>

28. <if COND="IsVariable.WRAPSTYLE!=true">

29. <then>

30. <setvar NAME="WRAPSTYLE" VALUE="OFF"/>

31. <then>

32. </if>

33. <presentation.getprimaryattributevalue

34. NAME="Variables.PresInst"

35. ATTRIBUTE="XSIZE" VARNAME="XSIZE"/>

36. <if COND="IsVariable.XSIZE!=true">

37. <then>

38. <setvar NAME="XSIZE" VALUE="24"/>

39. <then>

40. </if>

41. <presentation.getprimaryattributevalue

42. NAME="Variables.PresInst"

43. ATTRIBUTE="YSIZE" VARNAME="YSIZE"/>

44. <if COND="IsVariable.YSIZE!=true">

45. <then>

46. <setvar NAME="YSIZE" VALUE="20"/>

47. <then>

48. </if>

49. <setvar NAME="disableTextArea" VALUE="no"/>

50. <presentation.getprimaryattributevalue

51. NAME="Variables.PresInst"

52. ATTRIBUTE="PERMISSION" VARNAME="PERMISSION"/>

53. <if COND="IsVariable.PERMISSION=true">

54. <then>

55. <setvar NAME="errno" VALUE="0"/>

56. <USERISMEMBER GROUP="Variables.PERMISSION"/>

57. <IF COND="Variables.errno=0">

58. <THEN>

59. <setvar NAME="disableTextArea" VALUE="yes"/>

60. </THEN>

61. </IF>

62. <then>

63. </if>

64. <tr>

65. <!-- Standard element to display attribute name or description

66. -->

67. <callelement NAME="OpenMarket/Gator/FlexibleAssets/Common

68. /DisplayAttributeName"/>

69. <td></td>

70. <td>

71. <!-- Single valued attributes -->

72. <if COND="Variables.EditingStyle=single">

73. <then>

74. <!-- Special case: TEXTAREA for URL attributes -->

75. <IF COND="Variables.AttrType=url">

76. <THEN>

77. <setvar NAME="errno" VALUE="0"/>

78. <BEGINS STR="AttrValueList.urlvalue"

79. WHAT="AttrValueList."/>

80. <IF COND="Variables.errno=1">

81. <THEN>

82. <setvar NAME="filename" VALUE="CS.UniqueID.txt"/>

83. </THEN>

84. <ELSE>

85. <setvar NAME="filename"

86. VALUE="AttrValueList.urlvalue"/>

87. </ELSE>

88. </IF>

89. <INPUT TYPE="hidden" NAME="Variables.AttrName_file"

90. VALUE="Variables.filename"

91. REPLACEALL="Variables.AttrName,Variables.filename"/>

92. <setvar NAME="errno" VALUE="0"/>

93. <BEGINS STR="AttrValueList.@urlvalue"

94. WHAT="AttrValueList."/>

95. <IF COND="Variables.errno=1">

96. <THEN>

97. <setvar NAME="MyAttrVal" VALUE="Variables.empty"/>

98. </THEN>

99. <ELSE>

100. <setvar NAME="MyAttrVal"

101. VALUE="AttrValueList.@urlvalue"/>

102. </ELSE>

103. </IF>

104. </THEN>

105. </IF>

106. <!-- Display a TEXTAREA with all parameters from Attribute

107. --Editor xml -->

108. <!-- The NAME of the input must be the attribute name -->

109. <IF COND="Variables.disableTextArea=yes">

110. <THEN>

111. <TEXTAREA DISABLED="yes" NAME="Variables.AttrName"

112. ROWS="Variables.YSIZE" COLS="Variables.XSIZE"

113. WRAP="Variables.WRAPSTYLE"

114. REPLACEALL="Variables.AttrName,Variables.XSIZE,

115. Variables.YSIZE,Variables.WRAPSTYLE,Variables.empty">

116. <!-- For most single valued attrs, the value is contained in

117. MyAttrVal -->

118. <csvar NAME="Variables.MyAttrVal"/>

119. </TEXTAREA>

120. </THEN>

121. <ELSE>

122. <TEXTAREA NAME="Variables.AttrName"

123. ROWS="Variables.YSIZE" COLS="Variables.XSIZE"

124. WRAP="Variables.WRAPSTYLE"

125. REPLACEALL="Variables.AttrName,Variables.XSIZE,

126. Variables.YSIZE,Variables.WRAPSTYLE,Variables.empty">

127. <!-- For most single valued attrs, the value is

128. contained in MyAttrVal -->

129. <csvar NAME="Variables.MyAttrVal"/>

130. </TEXTAREA>

131. </ELSE>

132. </IF>

133. <then>

134. <else>

135. <!-- Multiple valued attributes -->

136. <!-- For single value attributes we can usually use the

137. default RequireInfo -->

138. <!-- For multiple value attributes we need to append to

139. RequireInfo for each value -->

140. <if COND="Variables.RequiredAttr=true">

141. <then>

142. <setvar NAME="RequireInfo"

143. VALUE="Variables.RequireInfo*Counters.TCounterVariables.

144. AttrName*ReqTrue*Variables.AttrType!"/>

145. <then>

146. <else>

147. <setvar NAME="RequireInfo"

148. VALUE="Variables.RequireInfo*Counters.TCounterVariables

149. .AttrName*ReqFalse*Variables.AttrType!"/>

150. <else>

151. </if>

152. <!-- Display a TEXTAREA with all parameters from Attribute

153. Editor xml -->

154. <!-- The NAME of the input must be the attribute name

155. prepended by the TCounter counter -->

156. <IF COND="Variables.disableTextArea=yes">

157. <THEN>

158. <TEXTAREA DISABLED ="yes" NAME="Counters.TCounterVariables.AttrName"

159. ROWS="Variables.YSIZE" COLS="Variables.XSIZE"

160. WRAP="Variables.WRAPSTYLE"

161. REPLACEALL="Counters.TCounter,

162. Variables.AttrName,Variables.XSIZE,

163. Variables.YSIZE,Variables.WRAPSTYLE">

164. <csvar NAME="Variables.tempval"/> </TEXTAREA>

165. </THEN>

166. <ELSE>

167. <TEXTAREA NAME="Counters.TCounterVariables.AttrName"

168. ROWS="Variables.YSIZE" COLS="Variables.XSIZE"

169. WRAP="Variables.WRAPSTYLE"

170. REPLACEALL="Counters.TCounter,

171. Variables.AttrName,Variables.XSIZE,

172. Variables.YSIZE,Variables.WRAPSTYLE">

173. <csvar NAME="Variables.tempval"/> </TEXTAREA>

174. </ELSE>

175. </IF>

176. <else>

177. </if>

178. </td>

179. </tr>

180. </THEN>

181. </IF> <!-- MultiValueEntry -->

182. </FTCS>

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

次の手順では、アップロード対象のファイルを検証するために、属性エディタのコードにカスタム・ロジックを追加する方法について説明します。

アップロード対象のファイルを検証するために、属性エディタのコードにカスタム・ロジックを追加する手順は次のとおりです。

1. パスCustomElements/fatwire/ui/utilにValidateFileUploadという名前のJSPエレメントを作成します。

2. JSPエレメントで、ics.GetVar("filename")およびics.GetVar("filebytes")をコールして、リクエスト範囲内のアップロード対象のファイル・データを含むファイル名およびバイト配列を取得します。

3. (オプション) アップロード対象のファイル・データが有効であることを確認するためのカスタム・ロジックを記述します。

- ファイル・データが有効な場合、ics.SetVar("fileValidated","true")をコールして、変数fileValidatedをtrueに設定します。これにより、ファイルはWebCenter Sitesサーバーに確実にアップロードされます。

- ファイル・データが無効な場合、ics.SetVar("fileValidated","false")をコールして、変数fileValidatedをfalseに設定します。これにより、ユーザーがアップロードするデータは拒否され、エラー・メッセージが表示されます。

注意:

サンプル・コード(検証ロジックを除く)は、ベース・エレメントfatwire/ui/util/ValidateFileUploadで使用可能です。このエレメントは変更しないでください。また、カスタム・コードは手順1で指定したようにCustomElementsパス内に記述する必要があります。

18.4 属性エディタの編集

属性エディタを編集する際は、次のことに留意してください。

- スキーマを変更せずに、「名前」を変更できます。

- データ消失を発生せずに、「説明」を変更できます。

- 属性エディタ内のコードを変更する場合:

- 入力オプションを追加できます。

- 既存のデータがある場合は、入力オプションを削除しないでください。入力オプションを削除すると、一部の既存データが無効になり、データベース内を検索してそれらのデータを修正することが必要になります。

- 入力スタイルを変更した場合は、データの不一致が生じるおそれがあります。

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

この章では、WebCenter Sitesに付属している属性エディタのインスタンスを構成する方法を説明します。

この章には次の項が含まれます。

- 第19.1項「CKEditorの構成」

- 第19.2項「Clarkii Online Image Editorの構成」

- 第19.3項「イメージ・ピッカーの構成」

19.1 CKEditorの構成

CKEditorは、CKSource社製のオープン・ソースWYSIWYGテキスト・エディタであり、クライアント側にインストールしておく必要はありません。CKEditorは、WebCenter Sitesに付属しています。FirstSiteIIサンプル・サイトでは、WYSIWYG対応のテキスト・フィールドが含まれた特定のアセット・タイプは、デフォルトでCKEditorを使用するように構成されています。

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

- 第19.1.1項「始める前に」

- 第19.1.2項「CKEditorインスタンスの作成とフィールドに対する有効化」

- 第19.1.3項「CKEditorのWebモードでの使用可能化」

- 第19.1.4項「特定のアセット・タイプのCKEditorでの使用可能化」

- 第19.1.5項「組み込まれたアセットの承認依存性の設定」

- 第19.1.6項「CKEditorでのイメージ・ピッカーの使用可能化」

- 第19.1.7項「CKEditorツールバーのカスタマイズ」

- 第19.1.8項「CKEditorでのスペル・チェック・サポートの構成」

19.1.1 始める前に

Internet ExplorerでCKEditorを使用している場合に、WebCenter Sitesがcp1252文字セットを使用するように構成されている場合は、次の手順を実行して、CKEditorがInternet Explorerで正しく動作するようにしてください。

1. futuretense.iniプロパティ・ファイルを開いて、cs.contenttypeプロパティの値をメモします。

2. Oracle WebCenter Sites Explorerにログインします。

3. SiteCatalog\OpenMarket\xcelerate\Actions\CKEditorRendererエレメントにアクセスして、そのresargs1フィールドを次の値に設定します。

cs.contenttype=[your content type]; charset=windows-1252

ここで、[your content type]には、futuretense.iniファイルで設定されている値を指定します。

19.1.2 CKEditorインスタンスの作成とフィールドに対する有効化

この手順では、CKEditorのインスタンスを作成して、FirstSiteIIサンプルに基づいてこのインスタンスをフレックス・アセット属性に対して有効にする方法を説明します。

この例では、新しいCKEditorインスタンスをFSIIAbstractフィールドの入力方法(属性エディタ)として有効にします。(FSIIAbstractは、"コンテンツ"というサンプル・アセット・タイプのフレックス属性です。)

CKEditorインスタンスを作成して有効にするには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. CKEditorインスタンスを作成します。

1. ボタン・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、「新規属性エディタ」をクリックします。
WebCenter Sitesに「新規属性エディタ」フォームが表示されます。

3. 「名前」フィールドに、このCKEditorインスタンスを一意に識別する名前を入力します。この例では、CK_FSIIAbstractと入力します。
クライアントは、総称名を使用してCKEditorを作成して、そのCKEditorを複数の属性で使用できます。そのフィールド特有の要件がないかぎり、属性に対してCKEditorインスタンスを一意に識別する必要はありません。たとえば、そのフィールドが他のCKEditorフィールドと異なる場合、そのフィールド内のCKEditorの幅と長さといった要件です。

4. 次のコードを「XML」フィールドに貼り付けます。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM "presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CKEDITOR">
<CKEDITOR WIDTH="400" HEIGHT="200"></CKEDITOR>
</PRESENTATIONOBJECT>

1. 「保存」をクリックします。

5. このCKEditorインスタンスをFSIIAbstractフィールドの入力方法として有効にします。

1. 「編集」フォームで、FSIIAbstract属性アセットを探して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、「コンテンツ属性の検索」をクリックします。

3. 検索フィールドで、FSIIAbstractと入力します。「検索」をクリックします。

4. 検索結果のリストで、FSIIAbstractアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。
そのアセットが「編集」フォームに表示されます。

2. CKEditorをこの属性の属性エディタ(入力方法)として設定します。「属性エディタ」ドロップダウン・リストで、CK_FSIIAbstractを選択します。

3. 「保存」をクリックして変更内容を保存します。

6. 新しいCKEditorインスタンスをテストします。

1. Contributorインタフェースに切り替えます。

2. 任意の「コンテンツ」アセットを探して、そのアセットを「編集」ビューで開きます。

1. 「検索」フィールドで、下矢印をクリックして「検索タイプ」メニューを開きます。「検索タイプ」メニューで、コンテンツの検索を選択します。次に、虫めがねボタンをクリックします。「検索」タブが開き、検索結果が表示されます。

2. アセット・タイプのリストで、目的の「コンテンツ」アセットに移動し(この例ではFSIIAbout)、そのアセットを右クリックして、コンテキスト・メニューから「編集」を選択します。
タブが開いて、そのアセットが「編集」ビューに表示されます。

3. 「概要」フィールドに移動して、フィールドをクリックします。これは次のようになっています。

CKEditorが表示されない場合は、属性エディタのXMLコードと、前述の手順5で、「属性エディタ」ドロップダウン・リストで選択した内容を確認してください。

4. アセットのツールバーで、「調査」アイコンをクリックして、アセットの「調査」ビューを表示します。

19.1.3 CKEditorのWebモードでの使用可能化

ユーザーがWebモードでCKEditorを使用してアセットを編集できるようにするには、パラメータeditorとparamsを適切なテンプレート内のinsite:editタグで設定する必要があります。編集するコードが含まれたテンプレートは、Webモードで使用するCKEditorが属するアセット用であるか、そのアセットと関連付けられたアセット・タイプ用である必要があります。

表19-1 CKEditorをWebモードで使用可能にするパラメータ

タグ

パラメータ

値

説明

insite:edit

editor

ckeditor

使用するエディタの名前を指定します。

なし

params

editorId

Webモードで使用するCKEditorのIDを指定します。

なし

なし

enableEmbeddedLinks

CKEditorツールバーでリンク・アイコンを有効にします。

注意:

insite:editタグでCKEditorの幅と高さが指定されていない場合は、CKEditorは、自身のXMLコードで設定されたXSIZEとYSIZEを使用します。詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

insite:editタグは、次のいずれかの場所で編集できます。

- 適切なテンプレート内の「エレメント・ロジック」フィールド。テンプレートの「エレメント・ロジック」フィールドで作業するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「検索」(ボタン・バー上)をクリックし、「テンプレートの検索」→「検索」を選択して、テンプレート名を選択します。

5. テンプレートの「編集」フォームで、「エレメント」タブを選択して、「エレメント・ロジック」フィールドに移動します。

- Sites Explorer (Oracle WebCenter Sites Explorerを使用したコード編集の手順については、第23.8項「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」を参照してください)。

- 任意のテキスト・エディタ。

19.1.4 特定のアセット・タイプのCKEditorでの使用可能化

ユーザーが使用できるアセット・タイプを限定するには、ALLOWEDASSETTYPESパラメータをCKEditorのXMLコードに追加します。このパラメータの値として、使用可能にするアセット・タイプの名前をカンマ区切りリストの形式で指定します。

アセット・タイプをCKEditorで使用可能にするには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「編集」フォームで属性エディタ(名前はCKEditor)を探して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「属性エディタの検索」を選択します。

3. 「属性エディタの検索」フォームで、必要に応じて検索条件を入力して、「検索」をクリックします。

4. 検索結果のリストで、CKEditorアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。

5. 「XML」フィールドに移動して、ALLOWEDASSETTYPESパラメータを<CKEDITOR>タグに追加します。次に、使用可能にするアセット・タイプの名前をALLOWEDASSETTYPESパラメータの値として指定します。

6. 「変更の保存」をクリックして、アセットを保存します。

7. ALLOWEDASSETTYPESパラメータをテストします。

1. Contributorインタフェースに切り替えます。

2. CKEditor対応のフィールドを持つアセットを探してWebモードで開きます。

1. 「検索」フィールドで検索条件を指定して、虫めがねボタンをクリックします。
「検索」タブが開き、検索結果が表示されます。

2. 目的のアセットの名前をクリックして、そのアセットの「調査」ビューを開きます。

3. そのアセットがフォーム・モードで開かれた場合は、アセットのツールバーで「モード」スイッチをクリックして、Webモードに切り替えます。

4. アセットのツールバーで、「編集」アイコンをクリックします。

3. いずれかの許可されたアセット・タイプを指定して検索します。許可されたアセットが固定された検索結果リストに表示されたら、その許可されたアセットをCKEditorにドラッグします。
ALLOWEDASSETTYPESパラメータで指定したタイプの許可されたアセットがまったくない場合は、「コンテンツ」→「新規」を選択して、新しいアセットを作成します。そのアセットを指定して検索して、そのアセットをドックからCKEditorにドラッグします。

19.1.5 組み込まれたアセットの承認依存性の設定

「アセットを含む」アイコンと「新規アセットの作成および包含」アイコンを使用すると、ユーザーは単一のアセットを別のアセットのCKEditor対応フィールドに組み込むことができます。組み込まれたアセットは、そのフィールドでプレビュー可能になり、最終的には、メイン・アセットの表示内容にオンラインで埋め込まれます。

メイン・アセットと組み込まれたアセットが初めてパブリッシュされた後に、これらのアセット間の依存性によって、後続の承認とパブリッシュがどのように機能するのかが決定されます。この依存性は、CKEditorのXMLコード内のDEPTYPEパラメータによって定義されます。

DEPTYPEパラメータは、EXISTSまたはEXACTに設定できます。DEPTYPEパラメータが明示的に設定されていない場合は、デフォルトでEXACTが使用されます。

- EXISTS: メイン・アセットが編集、承認および再パブリッシュされたときに、いずれかのバージョンの組み込まれたアセットがパブリッシュ先にすでに存在している場合は、組み込まれたアセットが承認および再パブリッシュされる必要はありません。

- EXACT: メイン・アセットが編集、承認および再パブリッシュされたときに、組み込まれたアセットが編集されていた場合は、組み込まれたアセットも承認および再パブリッシュされる必要があります。

組み込まれたアセットの承認依存性を定義するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「編集」フォームで属性エディタ(名前はCKEditor)を探して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「属性エディタの検索」を選択します。

3. 「属性エディタの検索」フォームで、必要に応じて検索条件を入力して、「検索」をクリックします。

4. 検索結果のリストで、CKEditorアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。

5. 「XML」フィールドに移動して、DEPTYPEパラメータを<CKEDITOR>タグに追加して、DEPTYPEパラメータの値をEXISTSまたはEXACTに設定します。

6. 「変更の保存」をクリックして、アセットを保存します。

19.1.6 CKEditorでのイメージ・ピッカーの使用可能化

ユーザーは、アセットのCKEditor対応フィールドからイメージ・ピッカーを起動する場合があります。ユーザーは、CKEditorツールバーの「含めるイメージの選択」アイコンをクリックして、イメージ・ピッカーを起動できます。ただし、このアイコンはデフォルトでは無効になっています。このアイコンを有効にするには、IMAGEPICKERIDパラメータをCKEditorのXMLコードに追加して、このパラメータの値を、「含めるイメージの選択」アイコンがクリックされたときに起動するイメージ・ピッカーのIDに設定します。

CKEditorからイメージ・ピッカーを使用可能にするには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「編集」フォームで属性エディタ(名前はCKEditor)を探して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「属性エディタの検索」を選択します。

3. 「属性エディタの検索」フォームで、必要に応じて検索条件を入力して、「検索」をクリックします。

4. 検索結果のリストで、CKEditorアセットに移動し、その「編集」(鉛筆)アイコンをクリックします。

5. 「XML」フィールドに移動して、IMAGEPICKERIDパラメータを<CKEDITOR>タグに追加して、このパラメータの値を、「含めるイメージの選択」アイコンがクリックされたときに起動するイメージ・ピッカーのIDに設定します。

6. 「変更の保存」をクリックして、アセットを保存します。

7. IMAGEPICKERIDパラメータをテストします。

1. Contributorインタフェースに切り替えます。

2. フォーム・モードで、IMAGEPICKERIDパラメータをテストするために使用するアセットの「編集」ビューを開きます。選択するアセットは、CKEditor対応フィールドを備えている必要があります。

3. CKEditorツールバーで、「含めるイメージの選択」アイコンをクリックします。

IMAGEPICKERIDパラメータの値で指定したIDを持つイメージ・ピッカーが開いて、そのイメージ・ピッカーと関連付けられたイメージ・アセットがウィンドウにレンダリングされます。

19.1.7 CKEditorツールバーのカスタマイズ

CKEditorのツールバーで使用できる機能と、それらの配置をカスタマイズできます。CKEditorツールバーのカスタマイズは、システム全体のレベルで行うこともインスタンス単位で行うこともできます。

19.1.7.1 システム全体レベルのCKEditorツールバーのカスタマイズ

1. 次のファイルをテキスト・エディタで開きます。
<cs_app>/ckeditor/config.js

<cs_app>は、WebCenter SitesのWebアプリケーションがデプロイされたアプリケーション・サーバーのディレクトリを示します。

2. ツールバーは、Adminインタフェース用およびContributorインタフェース用にカスタマイズできます(フォーム・モード用とWebモード用)。

- ツールバーをAdminインタフェース用にカスタマイズするには、<cs_app>/ckeditor/config.jsのconfig.toolbar_CSを検索します。

- ツールバーをContributorインタフェース用にカスタマイズするには、<cs_app>/ckeditor/config.jsのconfig.toolbar_SITESを検索します。

- ツールバーをWebモード用にカスタマイズするには、<cs_app>/ckeditor/config.jsのconfig.toolbar_SITES_WEBを検索します。

3. 変更を加えます。ツールバー定義の構文については、CKEditorのドキュメントを参照してください。

4. ファイルを保存して閉じます。

5. WebCenter Sitesのアプリケーションを再デプロイし、アプリケーション・サーバーを再起動して、変更内容を適用します。

19.1.7.2 インスタンス単位のCKEditorツールバーのカスタマイズ

1. カスタム・ツールバー定義を作成します。

1. 次のファイルをテキスト・エディタで開きます。
<cs_app>/ckeditor/config.js

<cs_app>は、WebCenter SitesのWebアプリケーションがデプロイされたアプリケーション・サーバーのディレクトリを示します。

2. 新しいツールバー定義をファイルの末尾に追加します。カスタム・ツールバー定義の作成方法については、CKEditorのドキュメントを参照してください。

config.toolbar_<toolbardef> = [
['Bold','Italic','Underline'],'/',
['Cut','Copy','Paste'],'/',
['FitWindow','-','Preview','Source','-','About']
];

<toolbarDef>の値は、カスタム・ツールバー定義の名前です。この名前は、手順dのbで、このカスタム定義を使用するように目的のCKEditorインスタンスを変更する際に使用します。

2. カスタム・ツールバー定義を使用するように、目的のCKEditorインスタンスを変更します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 目的のCKEditorインスタンスを検索します。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、「属性エディタの検索」をクリックします。「検索」フィールドに、目的のCKEditorインスタンスが保持されているアセットの名前を入力して、「検索」をクリックします。

3. 検索結果のリストで、目的のアセットに移動して、その「編集」(鉛筆)アイコンをクリックします。

5. 「XML」フィールドで、属性エディタ・コードを次のように変更します。

1. 次の太字で強調表示されている行を探します。

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT SYSTEM
"presentationobject.dtd">
<PRESENTATIONOBJECT NAME="CKEditorCustomized">
<CKEDITOR WIDTH="400" HEIGHT="200">
</CKEDITOR></PRESENTATIONOBJECT>

2. TOOLBARパラメータを<CKEDITOR>タグに追加します。

TOOLBAR="<toolbarDef>"

このTOOLBARパラメータでは、手順1で作成したカスタム・ツールバー定義の名前を指定します。

変更後の行は次のようになります。

<CKEDITOR WIDTH="400" HEIGHT="200" TOOLBAR="<toolbarDef>">

6. 「変更の保存」をクリックして、アセットを保存します。

3. WebCenter Sitesのアプリケーションを再デプロイし、アプリケーション・サーバーを再起動して、変更内容を適用します。

CKEditorの構成の詳細は、CKEditorのドキュメントを参照してください。

19.1.8 CKEditorでのスペル・チェック・サポートの構成

CKEditorは、次のスペル・チェック・ソフトウェアと統合できます。

- ieSpell: Microsoft Internet Explorer用のクライアント側のスペル・チェッカー・プラグイン

- Spell Pages: サーバー側のオープン・ソースのスペル・チェッカー・アプリケーション

これらのスペル・チェッカーをサポートするようにCKEditorを構成する方法については、次のURLにアクセスしてください。

http://docs.cksource.com/

19.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インスタンスを構成することもできます。

図19-1は、Clarkii OIEの固有コントロールと、Clarkii OIEが有効化されている属性内のイメージを操作するためのWebCenter Sites側の機能を示しています。

図19-1 アセットのフォームのフィールド内にレンダリングされたClarkii Online Image Editor

この機能を構成して有効にする前に、次のことに注意してください。

- Clarkii OIEは、フレックス属性のみに対して有効にできます。この項の説明では、FirstSiteIIサンプル・サイトのメディア・フレックス・ファミリを例として使用しています。

- Clarkii OIEは、blob型の属性のみに対して有効にできます。

- Clarkii OIEを有効にしたフィールドでClarkii OIEをレンダリングするためには、Flashがクライアント・ブラウザにインストールされている必要があります。

注意:

Clarkii OIEのツールバーとメニューの機能をカスタマイズできます。これらの機能はClarkii OIEと深く関連しているため、これらの機能については説明していません。Clarkii OIE固有の機能の構成方法については、次のURLにアクセスしてください。

http://www.online-image-editor-clarkii.com/

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

- 第19.2.1項「Clarkii OIEインスタンスの作成とフィールドに対する有効化」

- 第19.2.2項「Clarkii OIEのプロパティの構成」

- 第19.2.3項「アセットを分類するためのフィールド・コピアー・フィルタの実装」

19.2.1 Clarkii OIEインスタンスの作成とフィールドに対する有効化

この手順では、Clarkii OIEのインスタンスを作成して、このインスタンスをフレックス属性アセットに対して有効にする方法を説明します。この手順は、FirstSiteIIサンプル・サイトに基づいています。

この例では、新しいClarkii OIEインスタンスを、FSII_ImageFileフィールドの属性エディタとして有効にします。FSII_ImageFileは、サンプルのメディア・アセット・タイプの属性です。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. Clarkii OIEインスタンスを作成します。

1. ボタン・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、「新規属性エディタ」をクリックします。
WebCenter Sitesに「新規属性エディタ」フォームが表示されます。

3. 「名前」フィールドに、このClarkii OIEインスタンスを一意に識別する名前を入力します(この例では、ClarkiiOIEと入力します)。

4. 次のコードを「XML」フィールドに貼り付けます。

注意:

各パラメータの詳細は、第19.2.2項「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>

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

5. Clarkii OIEインスタンスを、特定のアセット・タイプの属性の属性エディタとして有効にします。この例では、メディア・アセット・タイプのFSII_ImageFile属性を使用します。

1. 「編集」フォームで、目的の属性アセットを探して開きます。この例では、FSII_ImageFile属性を探して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、目的の属性アセットのアセット・タイプをクリックします。この例では、「メディア属性の検索」をクリックします。

3. 検索フィールドで、変更する属性アセットの名前を入力します。この例では、FSII_ImageFileと入力します。

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

5. 検索結果のリストで、目的の属性アセット(FSII_ImageFile)に移動し、その「編集」(鉛筆)アイコンをクリックします。
そのアセットが「編集」フォームに表示されます。

2. Clarkii OIEをこの属性アセットの属性エディタとして設定します。

1. 「値タイプ」フィールドで、blobが選択されていることを確認します。

注意:

Clarkii OIEには、blob型の属性値が必要です。属性アセットを保存すると、その後、「値タイプ」フィールドで選択した値は変更できません。

2. 「属性エディタ」ドロップダウン・リストで、手順4で作成したClarkii OIEインスタンスを選択します。

3. 「変更の保存」をクリックします。

6. 新しいClarkii OIEインスタンスをテストします。

1. Contributorインタフェースに切り替えます。

1. アプリケーション・バーを開いていない場合は、メニュー・バーの右側で下矢印アイコンをクリックして開きます。

2. アプリケーション・バーで、Contributorインタフェース・アイコンを選択します。
Contributorインタフェースが表示されます。

2. 手順5で変更した属性をフィールドとして指定している定義を含む任意のアセットを検索して、そのアセットを「編集」フォームで開きます。この例では、メディア・アセットを選択します。

1. 「検索」フィールドに、必要な検索条件を入力します。

2. 検索範囲を特定のアセット・タイプに絞り込む場合は、「検索」フィールドの下矢印をクリックして、「検索タイプ」ドロップダウン・リストを開きます。Clarkii OIEインスタンスに対応したフィールドを使用しているアセット・タイプをクリックします。この例では、「メディアの検索」を選択します。

3. 虫めがねボタンをクリックします。
「検索」タブが開き、検索結果のリストが表示されます。

4. 検索結果のリストで、選択するアセットを右クリックします。この例では、FSII AudioCo_iAC-008.jpgメディア・アセットを選択し、「編集」を選択します。
そのアセットが「編集」フォームに表示されます。

3. Clarkii OIEで有効なフィールドに移動します。この例では、FSII_ImageFileフィールドになります。これは次のようになります。

Clarkii OIEがこのフィールドでレンダリングされていない場合は、次のいずれかを行います。

- Flashがインストールされていることを確認します。

- 作成したClarkii OIEインスタンスのXMLコードを確認します(手順4のdを参照)。

- Clarkii OIEを属性エディタとして有効にした属性アセットで選択した内容を確認します(手順5のfを参照)。

4. 「取消」をクリックして、このアセットの「調査」フォームに戻ります。

19.2.2 Clarkii OIEのプロパティの構成

この項の表では、Clarkii OIE属性エディタ・アセットの作成時に指定できるすべてのプロパティを列挙して説明しています。この表は、サイトの設計に合せて独自のClarkii OIEインスタンスのプロパティを構成するためのリファレンスとして使用してください。

表19-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

表19-3 「イメージの参照」ボタンの指定

プロパティ

定義

ENABLEIMAGEPICKER

「イメージの参照」ボタンを有効にします。ユーザーはこのボタンを使用して、Clarkii OIEキャンバス上の既存のイメージを任意のイメージに置換できます。このボタンをクリックすると、イメージ・ピッカー・ウィンドウが開きます。

可能な値: true|false

注意: このプロパティをfalseに設定した場合は、「イメージの参照」ボタンに関する他のプロパティの値を設定しないでください。

ASSETTYPE

「イメージの参照」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットのアセット・タイプを指定します。

可能な値: イメージを格納するためのblob型の属性を含む定義が存在するアセット・タイプ。

例: "Media_C"

ATTRIBUTE

「イメージの参照」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのイメージ・ファイル属性を指定します。

可能な値: イメージを格納するためのblob型属性。

例: "FSII_ImageFile"

ATTRIBUTETYPE

ATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプを指定します。「イメージ・ピッカー」ではこのアセット・タイプのみの属性を検索し、このアセット・タイプの属性があるイメージのみを表示します。

可能な値: ATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプ。

例: "Media_A"

CATEGORYATTRIBUTE

「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットを(理想的にはそれらの親アセットの名前に基づいて)分類する値が保持されているstring属性を指定します。このプロパティの値により、「イメージ・ピッカー」の「カテゴリ」ドロップダウン・リストが、指定された属性で見つかった値すべてで移入されます。フィールド・コピアー・フィルタを使用してアセットを分類する方法については、第19.2.3項「アセットを分類するためのフィールド・コピアー・フィルタの実装」を参照してください。

「イメージの参照」ボタンをクリックすると、ユーザーは「カテゴリ」ドロップダウン・リストを使用して、これらの属性値のいずれかを選択することで、「イメージ・ピッカー」ウィンドウに表示されるイメージをフィルタリングできます。選択された属性値に一致するイメージのみが、「イメージ・ピッカー」ウィンドウにレンダリングされます。

注意: このプロパティの値を指定しない場合は、ASSETTYPEプロパティで指定されたアセット・タイプのすべてのイメージ・アセットが「イメージ・ピッカー」ウィンドウに表示され、「カテゴリ」ドロップダウン・リストは表示されません。

RESTRICTEDCATEGORYLIST

カンマ区切りリストの形式で、CATEGORYATTRIBUTEプロパティで指定した属性の個別の値を入力します。ここで指定した値のみが、「イメージの参照」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウの「カテゴリ」ドロップダウン・リストで使用できるようになります。

可能な値: CATEGORYATTRIBUTEプロパティの説明を参照してください。

注意: CATEGORYATTRIBUTEプロパティの値を指定しない場合、このプロパティは無視されます。

表19-4 「イメージの挿入」ボタンの指定

プロパティ

定義

OIEATTRIBUTE

「イメージの挿入」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのイメージ・ファイル属性を指定します。

可能な値: イメージを格納するためのblob型属性。

例: "FSII_ImageFile"

OIEATTRIBUTETYPE

OIEATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプを指定します。「イメージ・ピッカー」ではこのアセット・タイプのみの属性を検索し、このアセット・タイプの属性があるイメージのみを表示します。

可能な値: OIEATTRIBUTEプロパティで指定したイメージ・ファイル属性のアセット・タイプ。

例: "Media_A"

OIECATEGORYATTRIBUTE

「イメージ・ピッカー」ウィンドウに表示されるイメージ・アセットを(理想的にはそれらの親アセットの名前に基づいて)分類する値が保持されているstring属性を指定します。このプロパティの値により、「イメージ・ピッカー」の「カテゴリ」ドロップダウン・リストが、指定された属性で見つかった値すべてで移入されます。フィールド・コピアー・フィルタを使用してアセットを分類する方法については、第19.2.3項「アセットを分類するためのフィールド・コピアー・フィルタの実装」を参照してください。

「イメージの挿入」ボタンをクリックすると、ユーザーは「カテゴリ」ドロップダウン・リストを使用して、これらの属性値のいずれかを選択することで、「イメージ・ピッカー」ウィンドウに表示されるイメージをフィルタリングできます。選択された属性値に一致するイメージのみが、「イメージ・ピッカー」ウィンドウにレンダリングされます。

注意: このプロパティの値を指定しない場合は、OIEASSETTYPEプロパティで指定されたアセット・タイプのすべてのイメージ・アセットが「イメージ・ピッカー」ウィンドウに表示され、「カテゴリ」ドロップダウン・リストは表示されません。

OIERESTRICTEDCATEGORYLIST

カンマ区切りリストの形式で、OIECATEGORYATTRIBUTEプロパティで指定した属性の個別の値を入力します。ここで指定した値のみが、「イメージの挿入」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウの「カテゴリ」ドロップダウン・リストで使用できるようになります。

可能な値: OIECATEGORYATTRIBUTEプロパティの説明を参照してください。

注意: OIECATEGORYATTRIBUTEプロパティの値を指定しない場合、このプロパティは無視されます。

OIEENABLEIMAGEPICKER

「イメージの挿入」ボタンを有効にします。ユーザーはこのボタンを使用して、Clarkii OIEキャンバス上の既存イメージの最上位層としてイメージを挿入できます。このボタンをクリックすると、イメージ・ピッカー・ウィンドウが開きます。

可能な値: true|false

注意: このプロパティをfalseに設定した場合は、「イメージの挿入」ボタンに関する他のプロパティの値を設定しないでください。

OIEASSETTYPE

「イメージの挿入」ボタンがクリックされたときに「イメージ・ピッカー」ウィンドウに表示される、イメージ・アセットのアセット・タイプを指定します。

可能な値: イメージを格納するためのblob型の属性を含む定義が存在するアセット・タイプ。

例: "Media_C"

19.2.3 アセットを分類するためのフィールド・コピアー・フィルタの実装

イメージ・アセットをその親アセットの名前に基づいて分類するには、フィールド・コピアー・フィルタを使用します。図19-2は、FirstSiteIIサンプル・サイトのメディア・フレックス・ファミリを使用して、フィールド・コピアー・フィルタを実装する方法を例示しています。この例のフィールド・コピアー・フィルタは、親アセットのシステム定義の「名前」属性の値をユーザー定義のstring属性にコピーします。

既存の属性の値が上書きされることを防止するには、フィールド・コピアーによってコピーされるシステム定義属性の値を保持するための新しいstring属性(FSII_ImageParentName)を作成します。

注意:

フィールド・コピアー・フィルタの詳細は、第17.1.1項「フレックス・フィルタ・クラス」を参照してください。

図19-2 フィールド・コピアー・フィルタの使用に関する概要(FirstSiteIIサンプル・サイトのメディア・フレックス・ファミリを例として使用)

フィールド・コピアー・フィルタを使用するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. フィールド・コピアー・フィルタの入力として使用する値を持つシステム定義属性を特定するとともに、フィールド・コピアーによってこのシステム定義属性の値がコピーされる先となるユーザー定義のstring属性を特定します。

注意:

既存の属性の値が上書きされないようにするには、string型のフレックス属性を作成します(この例ではFSII_ImageParentName)。新しいフレックス属性の作成方法については、第16.3.6項「手順4: フレックス属性の作成」を参照してください。

5. FieldCopier型のフィルタを作成します(この例ではFSII_ImageParentNameCopier)。

1. ボタン・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、「新規メディア・フィルタ」をクリックします。
「新規メディア・フィルタ」フォームが表示されます。

3. 「名前」フィールドで、このフィルタの一意の名前を入力します(この例ではFSII_ImageParentNameCopierを使用)。

4. 「フィルタ」フィールドで、ドロップダウン・リストからFieldCopierを選択します。次に「引数の取得」をクリックします。

- 「名前」ドロップダウン・リストで、フィールド・コピアー・フィルタの入力値として使用する値を持つシステム定義属性を選択します(この例では「名前」)。

- 「値」フィールドで、フィールド・コピアー・フィルタによって指定したシステム定義属性の値がコピーされる先となるユーザー定義属性の名前を入力します(この例ではFSII_ImageParentName)。

5. 「追加」をクリックして、フィルタに引数を追加します。

6. 「保存」をクリックして、フィルタを保存します。

6. 目的の親(または子)定義を探して、新しいフィールド・コピアー・フィルタをその定義に追加します(この例では、フィールド・コピアー・フィルタをFSII_ImageCategoryというメディア親定義に追加します)。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、「メディア親定義の検索」を選択します。

3. 検索フィールドで、フィールド・コピアー・フィルタを追加する先となる親定義の名前を入力します(FSII_ImageCategory)。

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

5. 検索結果のリストで、目的の親(または子)定義に移動して、その「編集」(鉛筆)アイコンをクリックします。

6. 親(または子)定義の「編集」フォームで「フィルタ」セクションに移動して、手順5で作成したフィールド・コピアー・フィルタを選択します。

7. 「変更の保存」をクリックします。

7. フィールド・コピアー・フィルタ(FSII_ImageParentNameCopier)を追加した定義と関連付けられたすべての既存の親(または子)アセットを探して再保存します。これにより、このフィルタはユーザー定義属性(FSII_ImageParentName)に、システム定義属性(「名前」)の値を格納できるようになります。
このフィルタを親定義に追加した場合、関連付けられた親アセットのすべての子は、フィールド・コピアー・フィルタによってユーザー定義属性(この例ではFSII_ImageParentName)にコピーされた値を内部で継承します。

19.3 イメージ・ピッカーの構成

この項では、イメージ・ピッカー属性エディタのインスタンスを構成する際にXML定義で値を指定する必要があるパラメータを紹介しています。

表19-5 イメージ・ピッカーのパラメータ

パラメータ

説明

ASSETTYPENAME

このイメージ・ピッカー・インスタンスで表示されるイメージ・アセットのアセット・タイプ。

例: Media_C

ATTRIBUTETYPENAME

選択されたイメージ・アセット・タイプ内のイメージ・ファイル属性のアセット・タイプ。

例: Media_A

ATTRIBUTENAME

選択されたイメージ・アセット・タイプ内のイメージ・ファイル属性の名前。

例: FSII_ImageFile

CATEGORYATTRIBUTENAME

(オプション)選択されたイメージ・アセット・タイプ内のカテゴリ属性の名前。

例: FSII_ImageCategory

RESTRICTEDCATEGORYLIST

選択されたイメージ・アセット・タイプ内のカテゴリ属性の値で構成されるカンマ区切りリストを指定します。このリストに含まれる値は、「イメージ・ピッカー」ウィンドウの「カテゴリ」ドロップダウン・リストに表示されます。このパラメータを省略した場合、イメージ・ピッカーは選択されたイメージ・アセット・タイプに属するすべてのアセットを表示します。

例: Audio、Video、Photo

イメージ・ピッカー定義のサンプルXMLコードは、第19.3.2項「イメージ・ピッカー属性エディタ定義のサンプル・コード」に記載されています。新しい属性エディタ(イメージ・ピッカーの新規インスタンスなど)の作成方法については、第18.2項「属性エディタの作成」を参照してください。アセット・フォーム内のフィールドの入力方法(イメージ・ピッカーなど)の選択方法については、第16.3.6項「手順4: フレックス属性の作成」を参照してください。

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

- 第19.3.1項「イメージ・ピッカーに表示するイメージ・アセットのカテゴリ分け」

- 第19.3.2項「イメージ・ピッカー属性エディタ定義のサンプル・コード」

19.3.1 イメージ・ピッカーに表示するイメージ・アセットのカテゴリ分け

前の項で説明したCATEGORYATTRIBUTENAMEパラメータとRESTRICTEDCATEGORYLISTパラメータを使用すると、選択されたイメージ・アセット・タイプに属する選択されたカテゴリのアセットのみがイメージ・ピッカーのインスタンスによって表示されるように制限できます。この作業を実行する前に、次の条件が満たされている必要があります。

1. string型のカテゴリ属性を、選択されたアセット・タイプ内の各アセットのカテゴリ記述子を格納することになるフレックス定義または選択されたイメージ・アセット・タイプに追加する必要があります。イメージ・ピッカーはこの属性の値を使用して、自身が表示できるアセット・カテゴリのリストを生成します。属性の作成方法については、第16.3.6項「手順4: フレックス属性の作成」を参照してください。

2. 開発者またはコンテンツ・プロバイダは、選択されたイメージ・アセット・タイプの各アセットのカテゴリ・フィールドに適宜入力する必要があります。カテゴリが割り当てられていないアセットは、カテゴリ制限されたイメージ・ピッカー・インスタンスによって表示されません。

19.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>

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

データ設計を決定し、アセット・タイプを作成し、これらを開発システムでテストして管理システムに移動したら、次のステップとして、アセット(コンテンツ)をそれらの現在のソースから管理システム上のデータベースにインポートします。たとえば、ワイヤー・フィード・サービスを使用したり、リモート生成されるコンテンツの他のソースを使用したりすることがありますが、そのコンテンツを管理システム上のWebCenter Sitesデータベースにインポートする必要があります。

任意のデータをWebCenter Sitesデータベースにインポートする場合は、XMLPostユーティリティを使用します。このユーティリティは、WebCenter SitesのFormPoster Javaクラスに基づき、WebCenter Sitesベースの製品で提供されます。これは、HTTP POSTプロトコルを使用してデータをインポートします。

この章では、XMLPostユーティリティを使用してアセットをインポートする一般的なプロセスを説明します。この章の情報に基づいて、あらゆるタイプのアセットをインポートできます。第21章「フレックス・アセットのインポート」では、フレックス・アセット・データ・モデルの使用時にアセットをインポートするために必要となる追加情報について説明しています。

この章には次の項が含まれます。

- 第20.1項「XMLPostユーティリティ」

- 第20.2項「XMLPostの構成ファイル」

- 第20.3項「XMLPostのソース・ファイル」

- 第20.4項「XMLPostユーティリティの使用」

- 第20.5項「RemoteContentPostとPreUpdateのカスタマイズ」

- 第20.6項「XMLPostのトラブルシューティング」

20.1 XMLPostユーティリティ

アセットをインポートするには、WebCenter Sitesで用意されているインポート(ポスト)・エレメントのいずれかをそのアセット・タイプに応じて呼び出すように、XMLPostユーティリティに指示する必要があります。

このプロセスでは次の4つのものが必要です。

- WebCenter Sitesに付属しているXMLPostユーティリティ。

- ポスト・エレメント。WebCenter Sitesには、RemoteContentPostという名前のポスト・エレメントが用意されています。WebCenter Sitesには、第21項「フレックス・アセットのインポート」で説明している3つの追加のポスト・エレメントも用意されています。

- ファイル拡張子が.iniの構成ファイル。インポートする予定のアセット・タイプごとに1つの構成ファイルを作成します。このファイルには、ソース・ファイルに含まれていると想定されるもの(XMLPostによって検出されるタグの種類)、提供されたデータの処理方法、およびデータをインポートするために使用するインポート(ポスト)・エレメントが記述されています。

- ソース・ファイル。インポートするアセットごとに個別のソース・ファイルを用意します(整形式XMLファイル)。ファイル内の各タグは、そのアセット・タイプのフィールドを指定します。このタグに含まれている情報は、その列に書き込まれるデータです。

XMLPostユーティリティは、構成ファイルを解析してアセット・タイプに対して提供されているデータの解釈方法を決定し、ソース・ファイルを解析して各フィールド値の名前と値のペアを作成し、これらの名前と値のペアをICS変数としてRemoteContentPostエレメントに渡します。RemoteContentPostエレメントは、これらの変数に基づいてアセットを作成します。

XMLPostユーティリティと組み合せて機能する独自のポスト・エレメントを作成することもできます。ただし、アセットをインポートする場合は、WebCenter Sitesに用意されているポスト・エレメントで十分です。

注意:

セキュリティを向上するために、RemoteContentPostページの名前を変更すると、システムへのハッキング試行を防止できます。

開発者が実行する手順

この項では、XMLPostユーティリティを起動する前に開発者が実行する手順と、XMLPostユーティリティが実行する処理について概述します。

WebCenter Sitesデータベースにアセットをインポートする際は、次の4つの一般的な手順を実行します。

1. インポートするアセットのタイプとソース・ファイル内で使用されているタグを指定する構成ファイルを作成します。
このファイルでは、いくつかの構成プロパティも設定します。これには、XMLPostで使用するポスト・エレメントのSiteCatalogエントリの名前が含まれます。すべてのアセットについて、このポスト・エレメントの名前はRemoteContentPostになります。フレックス・アセットのポスト・エレメントについては、第21章「フレックス・アセットのインポート」を参照してください。

構成ファイルはこのアセット・タイプに固有のものです。アセット・タイプごとに別個の構成ファイルを用意する必要があります。

2. インポートするデータのソース・ファイルを作成します。アセットごとに別個のソース・ファイルを作成します。

3. ソース・ファイルと構成ファイルは、管理システム上のディレクトリ内に配置します。

4. そのディレクトリから、ソース・ファイルとこれらのソース・ファイル用に使用する構成ファイルを指定して、XMLPostユーティリティを起動します。

XMLPostとWebCenter Sitesが実行する処理

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は正常にインポートされたアセットのソース・ファイルを削除します。

20.2 XMLPostの構成ファイル

XMLPostの構成ファイル内には、次の3つのタイプのプロパティがあります。

- データベースと環境に関する情報をXMLPostに提供するプロパティ。これらのプロパティは、独自のポスト・エレメントを作成した場合でも変化しません。

- ポスト(インポート)・プロセスの構成値を提供するプロパティ。この章では、RemoteContentPostエレメントが正常に機能するために指定する必要のあるプロパティについて説明します。
プロパティの例としてあげられるのは、RemoteContentPostを呼び出すページのURL、データベース内のアセット・タイプ表に対する書込み権限をXMLPostに付与するユーザー名とパスワード、インポートするアセット・タイプの名前、エラーのログ記録方法、インポートするすべてのアセットについて同じであるデータ値などです。

- ソース・ファイル内で使用されているタグを指定するプロパティ。

特定の情報は、構成ファイルのRemoteContentPostセクションまたはソース・ファイル・セクションで構成できます。これらの情報としては、アセットが所属するサイトや、アセットに割り当てられるワークフローなどがあります。

たとえば、1つのコンテンツ管理サイトしかない場合や、インポートするすべてのアセットが同じサイトに属している場合は、そのサイトの名前を構成セクションで指定してください。そうすることで、その情報を各ソース・ファイルで繰り返し指定する必要がなくなります。システムに複数のコンテンツ管理サイトがある場合は、アセットが属するサイトを個別のソース・ファイル内で指定します。

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

- 第20.2.1項「XMLPostの構成プロパティ」

- 第20.2.2項「ポスト・エレメントの構成プロパティ」

- 第20.2.3項「ソース・ファイルの構成プロパティ」

- 第20.2.4項「XMLPostのサンプル構成ファイル」

20.2.1 XMLPostの構成プロパティ

次の表では、XMLPostユーティリティが必要とするデータベース接続情報や他の一般的な構成指示内容を指定するプロパティを示しています。

表20-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

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

次の表は、RemoteContentPostページにポストされる必要のある(およびRemoteContentPostエレメントに渡される必要のある)情報を指定する引数を示しています。これらの引数の値は、RemoteContentPostページにポストされるURLに付加されます。これらの引数は構成ファイル内でどのような順序でもかまいません。

表20-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: Burlington Financial

システムで複数のコンテンツ管理サイトを使用している場合は、各アセットのサイトの値を個別のソース・ファイル内で指定する必要があります。詳細は、第20.2.3項「ソース・ファイルの構成プロパティ」を参照してください。

xmlpost.argname8:startmenu

オプション。

ワークフローを使用している場合に、インポートするアセットのすべてに同じワークフローを割り当てる場合は、この引数を使用してそれらのアセットのスタート・メニュー・ショートカットを設定します。(これはワークフローIDを新しいアセットに割り当てるスタート・メニュー・ショートカットです。)

例:

xmlpost.argname8: startmenu

xmlpost.argvalue8: New Article

このタイプのアセット用の複数のワークフローがある場合は、各アセットのスタート・メニュー・ショートカットの値を個別のソース・ファイル内で指定する必要があります。詳細は、第20.2.3項「ソース・ファイルの構成プロパティ」を参照してください。

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

構成ファイル内のソース・ファイル・セクションでは、ソース・ファイル内で使用されているタグが指定されます。

タグは、このタイプのアセットが格納されている表の列名を表します。タグのペアの内側にあるコンテンツは、その列に書き込まれる情報です。構成ファイルには、アセット・タイプのプライマリ記憶域表の列ごとにタグをリストする必要があるため、アセット・タイプごとに別個の構成ファイルを用意する必要があります。

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

- 第20.2.3.1項「サイトのプロパティ」

- 第20.2.3.2項「アセット・タイプのプロパティ」

20.2.3.1 サイトのプロパティ

アセット・タイプに関連するタグに加えて、特定のサイト構成プロパティを指定するためにすべてのアセット・タイプで使用できる4つのタグがあります。これらのプロパティでは、アセットを関連付けるサイトやアセットで使用するワークフローを指定します。次の表では、これらのサイト・タグを示しています。

表20-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セクションで指定できます。そうすることで、同じ情報をすべてのソース・ファイルで繰り返し指定する必要がなくなります。

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

アセット・タイプに固有のタグを設定するには、そのタイプのアセットのデータベース表の各列のタグを指定します。ただし、構成ファイル内のすべてのタグでタグ付けされたデータをソース・ファイルに含める必要はありません。(当然ながら、ソース・ファイルには必須フィールドのデータを含める必要があります。)

フィールド(列)を表す各タグについて、そのタグの名前を指定するとともに、必要に応じてそのタグの追加の処理プロパティを指定します。タグの名前は、対応するフィールド(列)の名前です。追加のプロパティについては、タグの名前の前に単語を付加するという規則に従う必要があります。

次の表では、アセット・タイプに固有のタグを指定する方法を説明しています。

表20-4 アセット・タイプのプロパティ

タグのプロパティ

値

説明

posttagname

yまたはn

(yesまたはno)

必須。

タグの名前を指定します。この名前は、そのタグが表しているフィールドの名前と完全に一致している必要があります。

たとえば、nameフィールドには、このタグのプロパティを次のように指定します。

postname: y

trunctagname

N

(整数)

オプション。

このタグでマークされたソース・ファイル内のデータを途中で切り捨てるかどうか。

例:

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は各値を別々の変数に格納します。XMLPostによって最初に検出された値は、keyword1という名前の変数に格納されます。2番目に検出された値は、keyword2という名前の変数に格納され、それ以降の値も同様です。

seedtagname

seed value

このプロパティは、multitagnameがseparateに設定されている場合は必須です。

同一のタグが複数回使用されていて、これらのタグ内のデータを別々の変数に格納する場合に、その変数名の末尾に付加される連続番号の最初の番号を指定します。multitagnameの説明を参照してください。

例:

multikeyword: separate

seedkeyword: 1

filetagname

yまたはn

(yesまたはno)

このプロパティは、タグがアップロード・フィールド(URL列またはBLOB)を表している場合は必須です。

タグがURL列を持つフィールドを表している場合は、このプロパティを使用する必要があるとともに、ソース・ファイルでは、RemoteContentPostによってその列にアップロードするファイルの名前を指定する必要があります。

たとえば、Burlington Financialサンプル・サイトのイメージファイル・アセット・タイプは、urlpictureという名前のアップロード・フィールドを備えています。このイメージファイル・アセット・タイプの構成ファイルには、次のプロパティが含まれます。

posturlpicture: y

fileurlpicture: y

この場合は、イメージファイル・アセットのソース・ファイルでは、urlpictureフィールドの値を次のように指定します。

<urlpicture>relative_path_to/filename.jpg

</urlpicture>

ファイルの場所は、XMLPostユーティリティを実行しているディレクトリを基準にした相対パスで指定する必要があります。

20.2.4 XMLPostのサンプル構成ファイル

ここでは、Burlington Financialサンプル・サイトのイメージファイル・アセットをインポートするために使用する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: BurlingtonFinancial

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

20.3 XMLPostのソース・ファイル

ソース・ファイルは、Document Type Definition (DTD)ファイルを必要としない整形式XMLで構成されている必要があります。実際には、構成ファイルは、ソース・ファイル内で処理されるタグを定義することでDTDファイルのような役割を果たします。

ソース・ファイル内のデータは、そのタイプのアセットが格納されている表の列名と一致する名前を持つタグによってタグ付けされている必要があります。たとえば、Burlington Financialのイメージファイル・アセットのソース・ファイルでは、name、caption、picutureurlなどの名前を持つタグが使用されています。

この章では、XMLソース・ファイルの生成を自動化する方法は説明しません。ソース・ファイルの作成方法は、データのソースと、そのデータをXMLファイルに変換するために使用するツールによって異なります。この章では、ソース・ファイルに含める必要のある内容と、XMLPostがソース・ファイルに対して実行する処理について説明します。

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

- 第20.3.1項「XMLPostのサンプル・ソース・ファイル」

- 第20.3.2項「XMLPostとファイル・エンコード方式」

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

ここでは、Burlington Financialのイメージファイル・アセットのサンプル・ソース・ファイルを示します。このファイル内のタグは、第20.2.4項「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という文字列になります。

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

ソース・ファイル内のデータに使用されているファイル・エンコード方式が、WebCenter Sitesシステムのデフォルト・ファイル・エンコード方式ではないが、データベースがそのファイル・エンコード方式に対応している場合は、ソース・ファイルの先頭のXMLバージョン文で、その代替のファイル・エンコード方式を指定できます。

例:

<?xml version= "1.0" encoding="UTF-8" ?>

20.4 XMLPostユーティリティの使用

XMLPostユーティリティは、次のいずれかの方法で起動できます。

- コマンドラインから

- スクリプト・ファイルまたはバッチ・ファイルから

- プログラムから

どの方法でXMLPostを起動する場合でも、次の情報を提供する必要があります。

- 使用する構成ファイルの名前。

- ソース・ファイル。ソース・ファイルは、単一のファイルとして、ファイルのリストとしてまたはファイルのディレクトリとして指定できます。

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

- 第20.4.1項「始める前に」

- 第20.4.2項「コマンドラインからのXMLPostの実行」

- 第20.4.3項「ソース・ファイルを指定するための方法」

- 第20.4.4項「バッチ・プロセスとしてのXMLPostの実行」

- 第20.4.5項「プログラムからのXMLPostの実行」

20.4.1 始める前に

- XMLPostユーティリティを使用する前に、次の条件が満たされている必要があります。

- 使用するアセット・タイプが作成されていること。(作成されていない場合は、アセットをインポートする先となるデータベース表がありません。)

- 使用するコンテンツ管理サイトが作成されており、適切なアセット・タイプが各サイトに対して有効化されていること。

- ワークフローを使用する場合は、使用するワークフロー・プロセスが作成されていること。

- スタート・メニュー・ショートカットが作成されていること。ワークフローを使用する場合は、これらのショートカットによって適切なワークフロー・プロセスが適切なアセット・タイプに割り当てられていること。

- 使用するアセット・タイプのテンプレートが作成されていること。

- 使用するアセット・タイプのアソシエーション・フィールドが作成されていること。ただし、XMLPostを使用してアソシエーション・フィールドの値を設定するには、カスタム・コードが必要です。詳細は、第20.5項「RemoteContentPostとPreUpdateのカスタマイズ」を参照してください。

- XMLPostを起動する際は、UTF-8エンコード方式が確実に使用されるようにするために、クラスパスの前に-Dfile.encoding=UTF-8というコマンドを挿入してください。

注意:

すべての.jarファイルのバージョン番号を確認してください。バージョン番号は、WebCenter Sitesのパッチ間で異なる可能性があります。

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

次の手順を実行します。

1. 構成ファイルとソース・ファイルを、WebCenter Sitesがインストールされているシステム上のディレクトリに配置します。

2. そのディレクトリから次のコマンドを(単一のコマンドラインで)実行します。
この例では、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.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.1.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\log4j-1.2.16.jar;<j2eeSDK_dir>\j2ee.jar;
<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アプリケーションが配置されているアプリケーション・サーバー上のディレクトリです。

- <j2eeSDK_dir>は、J2EE SDKのインストール先ディレクトリです。

ソース・ファイルを指定するには複数の方法があります。詳細は、第20.4.3項「ソース・ファイルを指定するための方法」を参照してください。

注意:

j2ee.jarファイルは、J2EE SDKに含まれています。XMLPostを実行する前に、このSDKをインストールする必要があります。

ソース・ファイルと構成ファイルが作業中のディレクトリ内に存在しない場合は、これらのファイルのパスをコマンドラインで指定する必要があります。例: -s/products/product.xml。

20.4.3 ソース・ファイルを指定するための方法

XMLPostユーティリティに対してソース・ファイルを指定するためのソース・パラメータでは、次のいずれかを指定できます。

- 単一のファイル。

- ファイルのディレクトリ。そのディレクトリ内のファイルのうち、構成ファイルで指定されたファイル拡張子(通常は.xml)を持つすべてのファイルがポスト(インポート)されます。

- インポートするすべてのファイルのリストが記述されたリスト・ファイル。このファイルは.iniファイルと似ていますが、ファイル拡張子は.lstです。

単一のファイル

単一のファイルの内容をポストするには、そのファイルの名前をコマンドラインで指定します。次の例では、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.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.1.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\log4j-1.2.16.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sarticle.xml -carticlepost.ini

ファイルのディレクトリ

ディレクトリ内のすべてのファイルをポストするには、そのディレクトリのパスをコマンドラインで指定します。次の例では、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.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.1.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\log4j-1.2.16.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sxmlpostfiles -carticlepost.ini

リスト・ファイル

ディレクトリを指定するかわりに、次のプロパティが含まれた.iniファイル形式のリスト・ファイルを作成できます。

- numfiles: リストに含まれるファイルの数を指定します。

- fileN: ファイルのパスとファイル名を指定します。Nは、リスト・ファイル内のそのファイルの順番を表します。リストの1番目のファイルはfile1、2番目のファイルはfile2というようになります。
リストの最後のfileNのNの値は、numfilesプロパティで指定された値と一致する必要があります。XMLPostは、numfilesプロパティで指定された数のファイルをインポートした時点で、インポートを終了します。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.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-codec-1.4.jar;
<cs_app_dir>\WEB-INF\lib\commons-logging-1.1.1.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\log4j-1.2.16.jar;<j2eeSDK_dir>\j2ee.jar;
<cs_app_dir>\WEB-INF\classes
COM.FutureTense.XML.Post.XMLPostMain-sc:\xmlpostfiles.lst -carticlepost.ini

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

複数のタイプのアセットをインポートする場合は、アセット・タイプごとに固有の構成ファイルを指定する必要があり、その結果としてアセット・タイプごとに個別にXMLPostを実行する必要があります。XMLPostは、手動で実行することも、バッチ・ファイルから自動的に実行することもできます。このバッチ・ファイル内には、アセット・タイプごとに1つのコマンドライン文を記述します(この文では構成ファイルと、ソース・ファイルの場所を指定します)。前の項で説明した方法のいずれかを使用してソース・ファイルを指定できます。

20.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");
}

ソース・ファイルと構成ファイルの完全パスを指定する必要があります。

20.5 RemoteContentPostとPreUpdateのカスタマイズ

必要に応じて、アセット・タイプのRemoteContentPostエレメントやPreUpdateエレメント内のコードを追加または変更することで、XMLPostプロセスをカスタマイズできます。

アセットに関する情報を他の表にインポートするには、そのアセット・タイプのPreUpdateエレメントを変更する必要があります。

この項では、次の2つのカスタマイズ例を紹介します。

- 記事アセット・タイプのPreUpdateエレメントをカスタマイズして、このエレメントで説明フィールド内のヘッドライン情報が設定されるようにします。Article表にはdescription列がありますが、「新規」記事フォームや「編集」記事フォーム内のフィールドの名前は「ヘッドライン」になります。

- 記事アセット・タイプのPreUpdateエレメントをカスタマイズして、このエレメントが記事にアソシエーションを追加できるようにします。

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

- 第20.5.1項「プログラムによるフィールド値の設定」

- 第20.5.2項「アセットのアソシエーションの設定」

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

記事アセット・タイプには特別な条件があります。このアセット・タイプには、「新規」フォームと「編集」フォーム内に「ヘッドライン」という名前のフィールドがありますが、「ヘッドライン」の値は、Article表のdescription列に格納されています。　記事アセットのインポート時にヘッドライン・テキストがArticle表の正しい列(description列)に書き込まれるようにするために、記事アセット・タイプの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(必須)。列に挿入するデータ。

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

あるアセットが別のアセットとのアソシエーションを持っている場合、その情報はAssetRelationTree表に書き込まれます。XMLPostの標準動作では、アセットの情報はそのアセット・タイプのプライマリ記憶域表にのみ書き込まれるため、アセットのアソシエーションを指定するには、そのアセット・タイプのPreUpdateエレメントを変更する必要があります。

たとえば、記事アセット・タイプには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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

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

ここでは、XMLPostユーティリティの実行時に発生する可能性のあるいくつかの問題について簡単に説明します。

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

XMLPostが起動しない理由としては次の2つが考えられます。

- 構成ファイル内のxmlpost.URLプロパティの設定で無効なサーバー名が指定されています。

- インポート先のシステム上でWebCenter Sitesが実行されていません。それを起動してください。

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

このメッセージがログ・ファイルに記録されている場合は、ソース・ファイル内に無効なXMLが含まれているということです。このような場合は通常、XMLにHTMLコードが含まれており、そのコードに含まれている特殊なHTML文字がそれらのHTML文字の文字エンティティ・コードで参照されていません。最適なコーディング手法として、すべてのHTMLコードを<![CDATA[...]]>タグ内に埋め込んでください。

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

アセットの保存時にデータベース・エラーが発生する理由はいくつか存在します。

105エラーの一般的な理由の1つは、XMLPostが保存しようとしているデータが大きすぎて列(フィールド)に収まらないことです。この問題の解決方法は目的に応じて異なります。列に収まらないデータが途中で切り捨てられてもかまわない場合は、truncタグのプロパティを構成ファイルに追加することで解決できます。たとえば、truncbody: 2000と指定します。

このエラー・コードのもう1つの一般的な理由は、同じ名前を持つそのタイプのアセットがすでに存在していることです。そのアセットの名前を変更してから、そのアセットをもう一度インポートしてみてください。

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

RemoteContentPostエレメントになんらかの変更を加えた場合や、独自のポスト・エレメントを作成した場合は、XML Debuggerユーティリティを使用してそのポスト・エレメントを使用前にテストできます。

XML Debuggerを使用するには、xmlpost.urlプロパティの設定でContentServerをDebugServerに置き換えます。

たとえば、xmlpost.url: http://6ipjk/servlet/ContentServerを

xmlpost.url: http://6ipjk/servlet/DebugServerに変更します。

XML Debuggerユーティリティの詳細は、第8章「WebCenter Sitesのツールおよびユーティリティ」を参照してください。

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

この章では、XMLPostユーティリティ用のポスト・エレメントについて説明します。

第20章「任意タイプのアセットのインポート」では、XMLPostユーティリティの使用に関する中核的な情報について説明しています。フレックス・アセット・データ・モデルを使用している場合は、アセットをインポートするためのその他のツールを利用できます。WebCenter Sitesでは、BulkLoaderという名前のバルク処理ユーティリティとXMLPostユーティリティ用のポスト・エレメントが用意されています。

この章には次の項が含まれます。

- 第21.1項「フレックス・アセットの理解」

- 第21.2項「XMLPostとフレックス・アセット・モデル」

- 第21.3項「フレックス・モデル内の構造アセット・タイプのインポート」

- 第21.4項「XMLPostを使用したフレックス・アセットのインポート」

- 第21.5項「XMLPostを使用したフレックス・アセットの編集」

- 第21.6項「XMLPostを使用したアセットの削除」

この章では、BulkLoaderユーティリティを取り上げていますが、このユーティリティの実行方法の詳細は、第22章「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

21.1 フレックス・アセットの理解

WebCenter Sitesでは、次の2つの方法で、フレックス・データ・モデルを使用するアセットをWebCenter Sitesデータベースにインポートできます。

- XMLPost。WebCenter Sitesには、XMLPostと組み合せて機能する3つの追加のポスト・エレメントaddData、modifyDataおよびdeleteDataがあります。

- BulkLoaderユーティリティ。

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

- 第21.1.1項「データ構造フレックス・アセット・タイプのインポート」

- 第21.1.2項「フレックス・アセットのインポート」

- 第21.1.3項「フレックス・アセットのインポート: プロセス」

- 第21.1.4項「カスタムのデータ・デリミタの使用」

21.1.1 データ構造フレックス・アセット・タイプのインポート

どちらの方法を使用する場合でも、その前に、WebCenter Sites製品に付属しているRemoteContentPostという標準のポスト・エレメントとXMLPostを使用して、データ設計またはデータ構造のアセット・タイプを作成するか、そのアセット・タイプをフレックス・ファミリにインポートする必要があります。つまり、標準のXMLPostポスト・エレメントを使用して、最初に属性エディタ、フレックス属性、フレックス定義およびフレックス親定義を作成またはインポートする必要があります。BulkLoaderユーティリティを使用する場合は、フレックス親もXMLPostを使用してインポートするか作成する必要があります。

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

データ構造アセット・タイプをインポートしたら、状況に応じて次の2つのいずれかのインポート方法を使用してフレックス・アセットをインポートできます。

- 大量(数千から数十万)のフレックス・アセットをインポートする場合は、BulkLoaderを使用します。

- 中程度の数(数百)のフレックス・アセットとフレックス親アセットをロードする場合は、ポスト・エレメントを使用します。

BulkLoaderを使用する場合

ベーシック・アセット・モデル内で作業している場合は、通常はXMLPostを使用して、管理システム上のデータベースにアセットをインポートしてから、これらのアセットを配信システムにパブリッシュします。フレックス・アセット・データ・モデルで必要なデータの量は、ベーシック・アセット・モデルの場合よりもはるかに多い傾向にあるため、この方法はフレックス・アセットに応じて変化します。

BulkLoaderユーティリティは、WebCenter Sitesシステムの初期セットアップ時に使用します。第22章「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

XMLPostを使用する場合

WebCenter Sitesシステムの初期セットアップ後に通常更新や増分更新を実行するには(たとえば、データの一部またはすべてがERPシステムで生じている場合など)、XMLPostユーティリティとaddDataポスト・エレメントを使用します。

21.1.3 フレックス・アセットのインポート: プロセス

フレックス・モデルを使用しているアセットは相互に依存性があるため、フレックス・アセット・タイプは特定の順序でインポートする必要があります。そして、ベーシック・アセットの場合と同様に、XMLPostを使用してアセットをインポートする前に、該当するアセット・タイプが存在していることや、作成済のサイトが存在していることなどが必要になります。

すべてのアセット・タイプ(両方のアセット・モデル)に当てはまる、XMLPostを使用するための基本的な前提条件については、第20.4.1項「開始する前に」を参照してください。

これらの基本的な要件が満たされた後に、次の順序でフレックス・アセット・タイプを管理システム上のWebCenter Sitesデータベースにインポートする必要があります。

1. 属性エディタは必須ではありませんが、属性エディタを使用する予定の場合は、それらをインポートまたは作成してからフレックス属性をインポートする必要があります。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、第21.3.1項「属性エディタ」を参照してください。

2. フレックス属性。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、第21.3.2項「フレックス属性」を参照してください。

3. フレックス親定義。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、第21.3.3項「フレックス定義とフレックス親定義」を参照してください。
フレックス定義。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。詳細は、第21.3.3項「フレックス定義とフレックス親定義」を参照してください。

注意:

フレックス親定義を適切な順序でインポートする必要があります。つまり、親定義が別の親定義アセットを参照している場合は、参照先のアセットはデータベース内にすでに存在している必要があります。通常は、親定義を階層レベルごとにインポートします(最上位レベルの親定義を最初にインポート)。

1. フレックス親アセット。次のいずれかを行います。

- XMLPostを使用してフレックス・アセットをインポートする場合は、フレックス親を個別にインポートすることも、フレックス・アセットのフレックス・ファミリ・ツリーの一部としてフレックス親をインポートすることもできます。

- BulkLoaderユーティリティを使用してフレックス・アセットをインポートする場合は、まずXMLPostを使用してフレックス親アセットをインポートする必要があります。構成ファイルでは、RemoteContentPostエレメントをコールするようにXMLPostに指示する必要があります。フレックス・アセットのファミリ・ツリー全体を含めずに親をインポートするため、構成ファイルではaddDataエレメントを指定できません。

詳細は、第21.3.4項「フレックス親」を参照してください。

2. (オプション)BulkLoaderユーティリティを使用してフレックス・アセットを管理システムと配信システムの両方にインポートする予定の場合は、まずすべての構造アセット(属性エディタ、フレックス属性、フレックス定義、親定義およびフレックス親)を承認して、管理システムから配信システムにパブリッシュする必要があります。

3. フレックス・アセット。次のいずれかを行います。

- BulkLoaderユーティリティを使用します。第22章「BulkLoaderユーティリティによるフレックス・アセットのインポート」を参照してください。

- XMLPostを使用します。第21.4項「XMLPostを使用したフレックス・アセットのインポート」を参照してください。

フレックス・アセット・ファミリのデータ構造には依存性が組み込まれているため、前述の手順で示した順序に従う必要があります。また、次の依存性にも留意してください。

- asset型の属性があるときに、そのような属性をフレックス親またはフレックス・アセットが持っている場合は、その属性フィールドの値として指定するアセットは、あらかじめ作成またはインポートされている必要があります。

- asset型の属性の値として設定するアセットは、正しいアセット・タイプのものである必要があります。

21.1.4 カスタムのデータ・デリミタの使用

XMLPostを使用してインポート、編集または削除するデータで、WebCenter Sitesのデフォルト・スキーマとは異なるデータ区切りスキーマが使用されている場合は(CSのデフォルト・デリミタについては次の表を参照してください)、次の表の説明に従ってカスタム・デリミタを指定できます。

表21-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_>

デフォルト・デリミタはセミコロン(;)です。

21.2 XMLPostとフレックス・アセット・モデル

使用しているアセット・モデルやWebCenter Sites製品にかかわらず、XMLPostユーティリティは同じように動作します。ただし、WebCenter Sitesでは、XMLPostをサポートするために、フレックス・アセット・タイプの一部の標準エレメント内に追加の処理ロジックが用意されています。フレックス・アセットのデータは複数のデータベース表に格納されるからです(これとは対称的に、ベーシック・アセット・タイプでは1つのデータベース表しか使用されません)。

また、WebCenter Sitesには、XMLPostを使用してフレックス・アセットを編集可能にするポスト・エレメント(modifyData)と、XMLPostを使用して任意タイプのアセットを削除可能にするポスト・エレメント(deleteData)の両方が用意されています。

この章では、フレックス・ファミリ内のアセット・タイプ(および属性エディタ)専用の構成ファイルとソース・ファイルの作成に関する追加情報を提供します。必ず第20章「任意タイプのアセットのインポート」も参照して、XMLPostのすべての構成ファイルとソース・ファイルに関する基本情報を確認してください。

フレックス・アセット・モデルでは、次のカテゴリのアセット・タイプに基づいて異なるポスト・エレメントを指定します。

- フレックス・アセット・タイプとフレックス親アセット・タイプにデータ構造を付与する構造アセット・タイプ。つまり、属性エディタ、属性、フレックス定義およびフレックス親定義です。
構造アセット・タイプをインポートするには、WebCenter Sitesの標準のポスト・エレメントであるRemoteContentPostを使用してください。(これらのタイプのアセットには、addDataエレメントを使用できません。)

- フレックス・アセット・タイプとフレックス親アセット・タイプ(GE Lightingサンプル・サイトの製品タイプと製品親タイプなど)。
状況に応じて、フレックス・アセット・タイプとフレックス親アセット・タイプをインポートするaddDataポスト・エレメントを使用するか、RemoteContentPostポスト・エレメントを使用します。(どちらのポスト・エレメントを使用するかについては、第21.3.4項「フレックス親」と第21.4項「XMLPostを使用したフレックス・アセットのインポート」を参照してください。)

どちらの場合も、最初に構成ファイルとソース・ファイルを作成します(第21.1項「フレックス・アセットの理解」の説明と、この章の補足説明を参照)。その後で、XMLPostユーティリティを起動します(第20.4項「XMLPostユーティリティの使用」を参照)。

注意:

参考用として、XMLPostのサンプル・コードが用意されています。このサンプル・コードは、WebCenter Sitesインストーラ・パッケージの/Xcelerate/Samples/XMLPostディレクトリ内にあります。同じフォルダに、サンプル・ファイルの説明が記載されたreadme.txtファイルも含まれています。

内部名と外部名

アセット・タイプのフレックス・ファミリを作成するときには(第16.3.3項「手順1: フレックス・ファミリの作成」を参照)、アセット・タイプの内部名と外部名の両方を指定します。

内部名は、データベース内のプライマリ記憶域表で使用されます。外部名は、「新規」フォーム、「編集」フォーム、「調査」フォーム、検索結果リストなどで使用されます。たとえば、属性エディタ・アセット・タイプの内部名はAttrTypesですが、この名前はユーザー・インタフェースでは使用されません。また、GE Lightingサンプル・サイトの記事アセット・タイプの内部名はAArticlesですが、この名前はユーザー・インタフェースでは使用されません。

XMLPostはデータベースと通信するため、構成ファイルとソース・ファイルでは常にアセット・タイプの内部名を使用する必要があります。たとえば、属性エディタの構成ファイルでは、次のように指定します。

postargname2: AssetType
postargvalue2: AttrTypes

21.3 フレックス・モデル内の構造アセット・タイプのインポート

第20章「任意タイプのアセットのインポート」に記載しているベーシック・アセットの構成ファイルとソース・ファイルに関するすべての情報は、フレックス・アセット・タイプの構成ファイルとソース・ファイルにも当てはまります。

さらにこの項では、構造フレックス・アセット・タイプのサンプル構成ファイルとサンプル・ソース・ファイルを掲載しています。

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

- 第21.3.1項「属性エディタ」

- 第21.3.2項「フレックス属性」

- 第21.3.3項「フレックス定義とフレックス親定義」

- 第21.3.4項「フレックス親」

21.3.1 属性エディタ

属性エディタのデータは、AttrTypesという名前の1つの表に格納されます。AttrTypesは、属性エディタ・アセット・タイプの内部名です。属性エディタの構成ファイルでは、必ずこの名前を使用してください。

次の表では、属性エディタで使用する構成ファイル・プロパティとソース・ファイル・タグを説明しています。

表21-2 属性エディタのタグとプロパティ

属性エディタのタグとプロパティ

説明

タグ:

<name>

プロパティ:

postname

必須。

属性エディタ・アセットの名前。これはすべてのアセット・タイプについて必須の値です。属性名は64文字に制限され、空白は指定できません。

タグ:

<description>

プロパティ:

postdescription:

オプション。

属性の使用方法や機能に関する説明。

タグ: <AttrTypeText>

プロパティ: postAttrTypeText

必須。

属性エディタのXMLコードが含まれたファイルの名前、または実際のコード。

このタグは、WebCenter Sitesインタフェースの「新規」および「編集」属性エディタ・フォームにある「XML」フィールドと、「参照」ボタンおよび「ファイル内のXML」フィールドに対応しています。

21.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

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

次に示すソース・ファイルは、GE Lightingサンプル・カタログのチェック・ボックス属性エディタ(プレゼンテーション・オブジェクト)をインポートするためのタグが記述されています。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>GE Lighting</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>

21.3.2 フレックス属性

フレックス属性はいくつかの表を持っていますが、XMLPostはこれらのうち2つの表にのみ書き込みを行います。1つはメイン記憶域表であり(GE Lightingサンプル・サイトの場合は、PAttributes表)、もう1つは属性アセット・タイプの_Extension表です(PAttributes_Extension)。

このため、構成ファイルのソース・ファイル・セクションでは両方の表の列を表すタグを指定する必要があり、ソース・ファイル自体ではこれらのタグを使用する必要があります。次の表では、これらのソース・ファイル・タグと構成ファイル・プロパティを説明しています。

表21-3 フレックス属性のタグとプロパティ

フレックス属性のタグとプロパティ

説明

タグ:

<name>

プロパティ:

postname

必須。

属性の名前。これはすべてのアセット・タイプについて必須の値です。属性名は64文字に制限され、空白は指定できません。

タグ:

<description>

プロパティ:

postdescription:

オプション。

属性の使用方法や機能に関する説明。

タグ:

<valuestyle>

プロパティ: postvaluestyle

オプション。

この属性が単一の値を保持できるのか(S)、複数の値を保持できるのか(M)。このタグを使用しない場合は、この属性はデフォルトで単一の値を保持するように設定されます。

タグ:

<type>

プロパティ:

posttype

必須。

この属性のデータ型。有効なオプションは、asset、date、float、int、money、string、textまたはblobです。これらのデータ型の定義については、第11.3.3.1項「属性のデータ型」を参照してください。

タグ: <assettypename>

プロパティ: postassettypename

<type>がassetに設定されている場合は必須。

この属性で保持されているアセット・タイプの名前。

タグ:

<upload>

プロパティ:

postupload

<type>がblobに設定されている場合は必須。

この属性の値を格納するディレクトリのパス。このフィールドに入力した値は、gator.iniファイルのcc.urlattrpathプロパティで属性表のデフォルト・ストレージ・ディレクトリ(defdir)として設定された値の後ろに付加されます(このディレクトリはデフォルトではFutureTense/futuretense_cs/ccurl/です)。

タグ: <attributetype>

プロパティ:

postattributetype

オプション。

使用する属性エディタの名前(該当する場合)。

タグ:

<enginename>

プロパティ:

postenginename

オプション。

管理システムで検索エンジンを使用している場合は、その検索エンジンの名前。

タグ:

<charsetname>

プロパティ:

postcharsetname

オプション。

使用する検索エンジンの文字セット。デフォルトでは、ISO 8859-1に設定されています。

タグ:

<編集>

プロパティ:

postediting

外部属性のみ。

外部属性は、WebCenter Sitesのフォームを通じて編集可能(L)になるのか、またはサード・パーティ・ツールを使用して外部で編集可能(R)になるのか。Lがデフォルトです。

タグ:

<storage>

プロパティ:

poststorage

外部属性のみ。

外部属性の値は、WebCenter Sitesデータベース内の_Mungo表に格納(L)されるのか、外部表に格納(R)されるのか。Lがデフォルトです。

タグ:

<externalid>

プロパティ:

postexternalid

外部属性のみ。

この外部属性を保持している表の主キーとして機能する列の名前。つまりこの属性を一意に識別する列の名前。

タグ:

<externalcolumn>

プロパティ:

postexternalcolumn

外部属性のみ。

この属性の値を保持している外部表の列の名前。

タグ:

<externaltable>

プロパティ:

postexternaltable

外部属性のみ。

externalidとexternalcolumで指定された列が含まれている外部表の名前。

タグ:

<publication>

プロパティ:

postpublication

オプション。

この属性を使用できるすべてのサイトの名前。

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

ここでは、GE Lightingサンプル・サイトの製品属性アセット・タイプのサンプル構成ファイルを示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

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

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

ここでは、GE Lightingサンプル・サイトのfootnotesという名前の製品属性をインポートするためのサンプル・ソース・ファイルを示します。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>GE Lighting</publication>
<name>footnotes</name>
<description>Footnotes</description>
<valuestyle>S</valuestyle>
<type>URL</type>
<editing>L</editing>
<storage>L</storage>
</document>

注意:

前述したように、フレックス属性のデータ型に関するすべての依存性と制約事項は、WebCenter Sitesインタフェース(「新規」または「編集」フレックス属性フォーム)を通じて属性を作成する場合でも、XMLPostを使用して属性を作成する場合でも同じように当てはまります。詳細は、第16.3.6項「手順4: フレックス属性の作成」を参照してください。

21.3.3 フレックス定義とフレックス親定義

フレックス定義とフレックス親定義のアセット・タイプはよく似ているため、これらのアセット・タイプの構成ファイルとソース・ファイルはほぼ同じように記述します。これらのアセット・タイプは、各自のソース・ファイル内でいくつかの同じタグを必要とし、各自の構成ファイル内でいくつかの同じプロパティを必要とします。それぞれのファイルには1つの追加のプロパティ/タグが含まれます。

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

- 第21.3.3.1項「サンプル構成ファイル: フレックス定義」

- 第21.3.3.2項「サンプル・ソース・ファイル: フレックス定義」

次の表では、フレックス定義とフレックス親定義のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されます。

表21-4 フレックス定義とフレックス親定義のタグとプロパティ

フレックス定義とフレックス親定義のタグとプロパティ

説明

タグ:

<internalname>

プロパティ:

postinternalname

必須。

アセットの名前。これはすべてのアセット・タイプについて必須の値です。フレックス定義とフレックス親定義の名前は64文字に制限され、空白は指定できません。

タグ:

<internaldescription>

プロパティ:

postinternaldescription

オプション。

アセットの用途または機能の説明。

タグ:

<renderid>

プロパティ:

postrenderid

オプション。フレックス定義専用。

このフレックス定義を使用して作成されるすべてのフレックス・アセットに割り当てられるテンプレート・アセットのID。

タグ:

<parentselectstyle>

プロパティ:

postparentselectstyle

オプション。フレックス親定義専用。

ユーザーがこの定義を使用してフレックス・アセットを作成する場合のフレックス親の選択方法を指定します。

このプロパティ/タグは、「新規」および「編集」親定義フォームの「親選択スタイル」フィールドを表しています。

このタグをソース・ファイル内で使用している場合、有効なオプションはtreepickとselectboxesです。

次の4つのタグとプロパティは、親定義とフレックス定義の「新規」フォームと「編集」フォームの「製品親定義」セクションにあるボタンおよびフィールドと同じ機能を実行します。第16.3.7項「手順5: (オプション)フレックス・フィルタ・アセットの作成」および第16.3.9項「手順7: フレックス定義アセットの作成」を参照してください。

なし

タグ:

<OptionalSingleParentList>

プロパティ:

postOptionalSingleParentList

このタグを使用して、単一のオプションの親定義を指定します。

タグ:

<RequiredSingleParentList>

プロパティ:

postRequiredSingleParentList

このタグを使用して、単一の必須の親定義を指定します。

タグ:

<RequiredMultipleParentList>

プロパティ:

postRequiredMultipleParentList

このタグを使用して、複数の必須の親定義を指定します。

タグ:

<OptionalMultipleParentList>

プロパティ:

postOptionalMultipleParentList

このタグを使用して、複数のオプションの親定義を指定します。

次の3つのタグとプロパティは、フレックス定義とフレックス親定義の「新規」フォームと「編集」フォームの「属性」セクションにあるボタンおよびフィールドと同じ機能を実行します。第16.3.7項「手順5: (オプション)フレックス・フィルタ・アセットの作成」および第16.3.9項「手順7: フレックス定義アセットの作成」を参照してください。

なし

タグ:

<RequiredAttrList>

プロパティ:

postRequiredAttrList

この定義を使用するフレックス親またはフレックス・アセットの必須の属性のリスト。

タグ:

<OptionalAttrList>

プロパティ:

postOptionalAttrList

この定義を使用するフレックス親またはフレックス・アセットのオプションの属性のリスト。

タグ:

<OrderedAttrList>

プロパティ:

postOrderedAttrList

「新規」、「編集」、「調査」などのフォームですべての属性(必須とオプションの両方)が表示される順序。

このタグを使用した場合は、他の属性タグがこのタグに置き換えられます。この項のサンプル・ソース・ファイルでは、このタグをソース・ファイル内で使用する方法を例示しています。

構成ファイルには、その構成ファイルが連係するタイプのアセットのいずれかで使用される可能性のあるすべてのプロパティが含まれている必要があります。個別のソース・ファイルには、それらの個別のアセットを定義するために必要なタグのみが含まれています。

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

次に、GE Lightingサンプル・サイトの製品定義をインポートするために使用する構成ファイルの例を示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

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

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

次のソース・ファイル(lighting.xml)は、GE Lightingサンプル・サイトのLightingという名前の製品定義のソースです。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>GE Lighting</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つのタグに複数の値を含める場合は、それぞれの値をセミコロン(;)で区切ります。

GE Lightingではオプション/複数の親モデルが使用されていますが、次に示す他の構成も可能です。

<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>

21.3.4 フレックス親

XMLPostを使用して、次の2つの方法でフレックス親アセットをインポートできます。

- 個別にインポートできます。フレックス親ごとに別個のXMLPostソース・ファイルを記述して、標準のRemoteContentPostポスト・エレメントのページ名とアセット・タイプを指定する1つのXMLPost構成ファイルを記述します。BulkLoaderユーティリティを使用する予定の場合は、まずXMLPostを使用してこの方法でフレックス親アセットをインポートする必要があります。

- フレックス・アセットのフレックス・ファミリ・ツリーの一部としてインポートできます。BulkLoaderではなくXMLPostを使用してフレックス・アセットをインポートする場合は、フレックス親をフレックス・アセットと結合して、フレックス親をフレックス・ファミリ・ツリーの一部としてインポートできます(特定のフレックス・アセットのコンテキスト内で)。フレックス・アセットごとに別個のXMLPostソース・ファイルを記述して、そのフレックス・アセットのすべての親をそのソース・ファイル内で指定します。XMLPostは、ソース・ファイルの解析時に、1つのフレックス・アセットと複数のフレックス親の変数を作成します(これらの変数がまだ存在しない場合)。

この項では、フレックス親アセットを個別にインポートするためのソース・ファイルと構成ファイルを紹介します。フレックス・アセットとともにフレックス親アセットをインポートする方法の詳細は、第21.4項「XMLPostを使用したフレックス・アセットのインポート」を参照してください。

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

- 第21.3.4.1項「サンプル構成ファイル: 個別のフレックス親」

- 第21.3.4.2項「サンプル・ソース・ファイル: 個別のフレックス親」

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

次に、GE Lightingサンプル・サイトの製品親をインポートするために使用する構成ファイルの例を示します。この例のすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

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

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

次のソース・ファイルは、GE LightingサンプルのHalogenという名前の製品親(フレックス親)を作成します。前述のサンプル構成ファイルと連係して機能します。

<document>
<publication>GE Lighting</publication>
<internalname>Halogen</internalname>
<fgrouptemplatename>Category</fgrouptemplatename>
<cat1>Halogen</cat1>
</document>

前述のとおり、RemoteContentPostポスト・エレメントを使用する場合は、親アセットごとに1つのソース・ファイルを用意する必要があります。

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

XMLPostを使用してフレックス・アセットをインポートする前に、構造アセット・タイプ(属性、フレックス定義およびフレックス親定義)をすでにインポートしている必要があります。

フレックス・アセットには、RemoteContentPostとaddDataという2つのポスト・エレメントを使用できます。

- addDataポスト・エレメントは、フレックス・アセットの親アセットを作成します(親アセットがまだ存在していない場合)。たとえば、BulkLoaderユーティリティを使用していない場合は、このポスト・エレメントをフレックス・アセットの初期インポート用に使用します。
addDataポスト・エレメントを使用する場合は、ソース・ファイルでフレックス・アセットのファミリ・ツリー全体を指定する必要があります。フレックス・アセットごとに別個のソース・ファイルが必要ですが、そのソース・ファイル内ではそのフレックス・アセットの親をいくつでも指定可能であり、XMLPostはそのフレックス・アセットとその親を作成します(親がまだ存在していない場合)。

- RemoteContentPostエレメントは、フレックス・アセットを作成して、それらの親の値を設定します。これらの親はすでに存在している必要があります。たとえば、BulkLoaderを初期インポート用に1度だけ使用して、それ以降はXMLPostを使用する予定の場合は、このポスト・エレメントを使用することをお薦めします。
RemoteContentPostを使用してフレックス・アセットをインポートする場合は、ソース・ファイルで、そのアセットの直接の親のみを指定する必要があります(その結果としてソース・ファイル内で必要なコード行が少なくなります)。ただし、その新しいフレックス・アセットの新しいフレックス親を作成する必要がある場合は、addDataポスト・エレメントを使用して、ソース・ファイル内でファミリ・ツリー全体を指定する必要があります。

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

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

- 第21.4.2項「addDataのサンプル・フレックス・アセット構成ファイル」

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

- 第21.4.4項「addDataのサンプル・フレックス・アセット・ソース・ファイル」

- 第21.4.5項「RemoteContentPostのサンプル・フレックス・アセット構成ファイル」

- 第21.4.6項「RemoteContentPostのサンプル・フレックス・アセット・ソース・ファイル」

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

構造アセット・タイプの場合と同様に、構成ファイルとソース・ファイル内ではフレックス・アセット・タイプとフレックス親アセット・タイプの内部名を使用する必要があります。

ただし、構造アセット・タイプの場合とは異なり、アセット・タイプの引数を構成ファイルに記述する必要はありません。フレックス・アセットのソース・ファイルにはそのアセット・タイプを指定する必須タグが含まれているため、この情報を構成ファイル内で繰り返し指定する必要はありません。

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

- 第21.4.1.1項「addDataポスト・エレメントの場合」

- 第21.4.1.2項「RemoteContentPostポスト・エレメントの場合」

- 第21.4.1.2項「RemoteContentPostポスト・エレメントの場合」

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

次の表は、addDataポスト・エレメントを使用している場合の、フレックス・アセット(およびそれらのフレックス親)のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されます。

表21-5 addDataポスト・エレメント

タグとプロパティ

説明

タグ:

<_ASSET_>

プロパティ:

post_ASSET_

必須。

アセット・タイプの内部名。たとえば、GE Lightingサンプル・サイトのフレックス・アセットの内部アセット・タイプ名は、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

このタグとプロパティの使用方法の詳細は、第21.4.4.4項「フレックス・アセットの親の指定」を参照してください。

タグ:

<_GROUPDESCRIPTIONS_>

プロパティ:

post_GROUPDESCRIPTIONS_

オプション。

指定する親が新規の場合は、親定義の説明を含めることもできます。

タグ:

<displaytype>

プロパティ:

postdisplaytype

オプション。

フレックス・アセットのTemplateアセットの名前。

タグ:

<AttributeName>

プロパティ:

postAttributeName

タイプのアセットが持つことのできる属性(必須とオプションの両方)ごとに構成ファイルにプロパティを含めます。そして、そのアセットに適用する必須属性とオプション属性ごとにソース・ファイルで値を指定する必要があります。

たとえば、SKUという名前の属性がある場合は、postSKUというプロパティを含めて、ソース・ファイルには次のようなコード行を含めます。

<SKU>123445</SKU>

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

次の表は、RemoteContentPostポスト・エレメントを使用している場合の、フレックス・アセット(およびそれらのフレックス親)のソース・ファイル・タグと構成ファイル・プロパティを示しています。大文字と小文字が区別されます。

表21-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>

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

ここでは、GE Lightingサンプル・サイトの製品アセット・タイプのサンプル構成ファイルを示します。この構成ファイルは、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

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

アセット・タイプがblob(またはurl)型の属性を持っている場合は、構成ファイルには、その属性を参照するタグのエントリが2つ含まれている必要があります。1つはその属性を指定するエントリであり、もう1つは、次のいずれかのファイルの名前を指定するエントリです。その属性(アップロード・フィールド)の内容が含まれているファイルの名前、またはテキスト・フィールド(blob型またはURL型のテキスト・フィールド)に直接入力されたテキストから作成されるファイルにWebCenter Sitesが付与する名前です。

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

GE Lightingサンプル・サイトには、blob型の属性はありません。説明のために、footnotesという名前のblob型の属性があると仮定します。これは、テキストを入力するためのテキスト・フィールドのかわりに、ファイルを探すための「参照」ボタンが付いているアップロード・フィールドです。したがって、この属性は次の2つのプロパティを持ちます。

- posttag: この例では、postfootnotes: y

- filetag: この例では、filefootnotes: y

この属性の値をソース・ファイルに含める場合は、次の書式に従ってください。

<footnotes>FileName.txt</footnotes>

このタイプのフィールド(属性)を持つアセットをインポートする場合、そのフレックス・アセットの属性値として保管するテキストが含まれているファイルは、そのアセットのソース・ファイルと同じディレクトリに配置されている必要があります。

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

仮定のfootnotes属性が、ファイルではなくテキスト入力を直接受け付けるフィールドである場合は、構成ファイルで次のプロパティを指定する必要があります。

- postfootnotes: y

- postfootnotes_file: y

また、この属性の値をソース・ファイルに含める場合は、次の書式に従ってください。

<footnotes>lots and lots of text</footnotes>
<footnotes_file>FileNameYouWantUsed.txt</footnotes_file>

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

次のソース・ファイルは、前の項で紹介したサンプルのフレックス・アセット構成ファイルと連係して機能します。

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

- 第21.4.4.1項「サンプル・ファイル」

- 第21.4.4.2項「特殊文字の処理」

- 第21.4.4.3項「フレックス・アセットとそれらの親」

- 第21.4.4.4項「フレックス・アセットの親の指定」

- 第21.4.4.5項「親の属性値の設定」

- 第21.4.4.6項「フレックス・ソース・ファイル内の複数値の設定」

21.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>GE Lighting</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に設定しています。

21.4.4.2 特殊文字の処理

XMLPostはHTTP POSTプロトコルを使用するため、データをHTTPストリームとして送信します。したがって、特定の文字は特殊文字として扱われ、これらの特殊文字はURLに含まれるため、これらの特殊文字をエンコードする必要があります。

ソース・ファイル内の属性値に、次の表で示す特殊文字のいずれかが含まれている場合は、その特殊文字のすべてを対応するURLエンコード・シーケンス(第4.8項「特殊文字の値」を参照)に必ず置換してください。

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

GROUPタグは、ファミリ・ツリー内の親を指定します。XMLPostは、addDataポスト・エレメントを使用して、ソース・ファイルのGROUPセクションを解析する際に、次の操作を実行します。

1. このフレックス定義を使用しているアセットに対して適正な親定義を特定します。

2. それぞれの適正な親定義について、その定義の親がソース・ファイルで指定されているかどうかを確認します。

- 指定されている場合は、その親を設定し、その親がまだ存在していない場合は、その親を作成します。

- 指定されていない場合は、その親を設定しません。ただし、その定義の親が必須である場合は、エラーを返します。

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

フレックス・アセットの親を指定するには、その親の名前を<_GROUP_parentDefinitionName>タグ内にネストした形で指定します。例:

<_GROUP_subcategory>Blacklights</_GROUP_subcategory>

このsubcategoryは、Blacklightsという親(製品親)の親定義の名前です。

前述のとおり、フレックス・アセットのファミリ・ツリー全体を指定する必要があります。GE Lightingサンプル・サイトでは、製品アセットは1つの親と1つの祖父母を持ちます。電球(Blacklight)の親を指定するだけでなく、祖父母を指定する必要があります。例:

<_GROUP_subcategory>Blacklights</_GROUP_subcategory>

<_GROUP_category>Fluorescent</_GROUP_category>

21.4.4.5 親の属性値の設定

XMLPostは、属性値が属している親をどのようにして知るのでしょうか。XMLPostにとってはその親は不明です。したがって、ある属性が複数の親に属することができる場合は、その属性が属する親を指定する必要があります。たとえば、bulbshape属性が製品ではなく親に割り当てられているとします。この場合は、次のようなコード行を含めます。

<bulbshape>Halogen=T</bulbshape>

21.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>

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

ここでは、GE Lightingサンプル・サイトの製品アセット・タイプのサンプル構成ファイルを示します。この構成ファイルは、このサンプル・ファイルのすぐ後に掲載しているサンプル・ソース・ファイルと連係して機能します。

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

21.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>GE Lighting</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に設定しています。この親はすでに存在している必要があります。

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

XMLPostを使用して、フレックス・アセットとフレックス親アセットに関する次の情報を編集できます。

- 属性の値

- アセットの親(フレックス・アセットの親またはその親の親)

属性アセット、フレックス定義アセットおよびフレックス親定義アセットは、XMLPostを使用して編集することはできません。

フレックス・アセットの属性値を編集するには、ソース・ファイルには、変更する属性とそのアセットの名前のみが含まれている必要があります。

フレックス親の属性値を編集するには、フレックス・アセットのコンテキストを提供する必要があります。ソース・ファイルでは、そのフレックス・アセットの名前が指定されている必要があり、そうすることで、変更する親属性と親のみを参照できます。ただし、XMLPostが最初に扱うフレックス・アセットを指定する必要があります。その結果として、XMLPostはファミリ・ツリー内を移動できるようになります。

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

- 第21.5.1項「フレックス・アセットを編集するための構成ファイル」

- 第21.5.2項「フレックス・アセットを編集するためのソース・ファイル」

21.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

これにより、そのフレックス・アセットから親が削除されます。

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

編集対象のフレックス・アセットのソース・ファイルには、そのアセットのすべての情報が含まれている必要はありません。変更する情報のみを指定する必要があります。指定されていない属性は一切変更されません。

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

- 第21.5.2.1項「属性の値の変更」

- 第21.5.2.2項「属性値の削除」

- 第21.5.2.3項「親関係の編集」

21.5.2.1 属性の値の変更

属性の値を変更するには、その属性の新しい値をソース・ファイル内で指定します。XMLPostはインポートの実行時に、ソース・ファイルで指定された値によって古い値を上書きします。

次のサンプル・ソース・ファイルでは、第21.4.4項「addDataのサンプル・フレックス・アセット・ソース・ファイル」で定義された10004という名前のGE Lighting製品の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>

21.5.2.2 属性値の削除

属性値を削除して空のままにするには、その属性の名前を指定する行を記述して、その属性の値として_EMPTY_を指定します。

例:

<bulbsize>_EMPTY_</bulbsize>

親の属性値を編集することもできます。たとえば、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>

21.5.2.3 親関係の編集

XMLPostを使用して、フレックス・アセットの親関係を次のように編集できます。

- 既存の親に別の親を追加できます。

- 親を別の親に変更できます。

GROUP_parentDefinitionNameタグの動作は、属性タグの動作とは異なります。

- 属性タグを使用している場合は、XMLPostは古い値を新しい値によって上書きします。

- GROUP_parentDefinitionNameタグを使用すると、親定義名が同じであっても、XMLPostは古い親を新しい親で上書きしません。かわりに、XMLPostはアセットの親のリストに新しい親を追加しますが、これは開発者の目的の処理ではない可能性があります。

既存の親のリストに別の親を追加するには、そのためのコード行をソース・ファイルに含めます。例:

<_GROUP_SubCategory>Blacklights</_GROUP_SubCategory>

親を削除するには、<_REMOVE_>タグを使用します。親を置換する場合を除いて、必要な親を削除しないように十分に注意してください。

<_REMOVE_Processor>Appliance Lamps</_REMOVE_Processor>

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

XMLPostを使用して、任意のタイプの任意のアセットを削除できます。そのためには、次の2つの要件が満たされる必要があります。

- 構成ファイルでは、deleteDataエレメントをコールするようにXMLPostに指示する必要があります。
例:

xmlpost.argname1: pagename
xmlpost.argvalue1: OpenMarket/Gator/XMLPost/deleteData

- 次の2つのソース・ファイル・タグと構成ファイル・プロパティを使用する必要があります。
<_ASSET_>/post_ASSET_: 削除するアセットのアセット・タイプを指定します。

<_ITEMNAME>/post_ITEMNAME_: 削除するアセットを指定します。

XMLPostがこのポスト・エレメントを使用する場合、XMLPostはそのアセットのStatus列の値をvoidを意味するVOに変更します。(XMLPostはこのアセットをデータベースから物理的に削除するわけではありません)。

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

- 第21.6.1項「アセットを削除するための構成ファイル」

- 第21.6.2項「アセットを削除するためのソース・ファイル」

21.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を通常どおりコマンドラインから起動します。

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

アセットを削除するためのソース・ファイルは小さくてシンプルです。例:

<document>

<_ASSET_>Products</_ASSET_>
<_ITEMNAME_>Pentium 90</_ITEMNAME_>
<publication>my publication</publication>

</document>

このコードは、Pentium 90という名前の製品アセットを削除するようにXMLPostに指示します(XMLPostはPentium 90のステータスをvoidを意味するVOに変更します)。

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

この章では、WebCenter Sitesシステムの初期設定時においてフレックス・アセットのインポートに使用するBulkLoaderユーティリティについて説明します。

この章には次の項が含まれます。

- 第22.1項「BulkLoaderユーティリティの概要」

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

- 第22.3項「BulkApproverユーティリティによるフレックス・アセットの承認」

22.1 BulkLoaderユーティリティの概要

BulkLoaderユーティリティを使用することにより、大量のフレックス・アセット・データをユーザー自身のデータソースからユーザーが定義した方法で迅速に抽出し、任意のシステム(開発、管理、テスト、または配信システム)上のWebCenter Sitesデータベースにインポートできます。

抽出メカニズムは、顧客が実装可能なJavaインタフェースを使用して引き出されます。BulkLoaderは、このインタフェース上でメソッドを呼び出して、データソースから入力データを抽出します。下位機能互換性とデータ互換性を確保するためにWebCenter SitesにはこのJavaインタフェースの実装も組み込まれているため、BulkLoaderはJDBC互換のデータソースからデータを抽出することも可能です。

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

- 第22.1.1項「BulkLoaderの機能」

- 第22.1.2項「BulkLoaderの仕組み」

- 第22.1.3項「BulkLoaderユーティリティの使用」

- 第22.1.4項「フラット表からのフレックス・アセットのインポート」

- 第22.1.5項「手順1: XMLPostの使用による構造アセットのインポート」

- 第22.1.6項「手順2: 入力表(データソース)の作成」

- 第22.1.7項「手順3: マッピング表の作成」

- 第22.1.8項「手順4: BulkLoader構成ファイルの作成」

- 第22.1.9項「手順5: BulkLoaderユーティリティの実行」

- 第22.1.10項「手順6: フィードバック情報の確認」

- 第22.1.11項「手順7: アセットの承認と配信システムへのパブリッシュ」

22.1.1 BulkLoaderの機能

BulkLoaderには次の機能があります。

- ユーザー定義の抽出メカニズムに対するJava APIの使用によるサポート。ユーザーは、この抽出インタフェースをカスタム実装するか、JDBCデータソースからの抽出用の組込みサポートを使用できます。

- フレックス・アセットおよびグループ・データに対する挿入、無効化、更新のサポート。

- 増分挿入、増分無効化、増分更新に対するサポート。

- データ抽出中にマルチスレッド・インポート操作を同時実行することによる、スループットを高めるためのパフォーマンス向上。

- 入力データのチャンク(スライス)処理に対するサポート。

- 複数のフレックス・ファミリに属するアセット・データのインポートに対するサポート。

- 下位機能互換性およびデータ互換性。外部JDBCソースからのアセット・データのインポートをサポートします。

22.1.2 BulkLoaderの仕組み

BulkLoaderの再設計により、パフォーマンス、スループットおよびスケーラビリティの向上を実現しました。すべての入力データを読み取った後に出力SQLファイルを生成するのではなく、BulkLoaderは入力データをチャンクとして読み取ります。1つのチャンクが読み取られると即時にインポート・スレッドに渡されると同時に、BulkLoaderスレッドは次のチャンクを読み取るために戻ります。インポート・スレッドは、WebCenter SitesデータベースとJDBCの直接接続を利用します。この方法によって読取りとインポートが並行して実行されるため、スループットの向上が達成されます。スケーラビリティについては、データベース・コンピュータのハードウェアにCPUが追加され、同時実行性の高度化に対応するI/O構成が行われた場合、ユーザーはBulkLoaderのインポート・スレッド数を増加できます。

BulkLoaderユーティリティは、処理中スレッド数を指定するパラメータ、データ抽出インタフェースを実装するJavaクラスの名前、コミット頻度、アセットIDとして使用する一意の開始IDなどが含まれている構成ファイルを必要とします。

次の図に、クライアント固有の実装と、WebCenter Sitesにより提供される、組込みの使用準備済の実装を示します。

図22-1 BulkLoaderのクライアント固有の実装

図22-2 BulkLoaderの組込みOOTB (out of the box: すぐに使用可能な)実装

22.1.3 BulkLoaderユーティリティの使用

WebCenter Sitesデータベースにインポートする入力データの提供方法に応じて、BulkLoaderは2どおりの方法で使用できます。

- 外部JDBCデータソースからの入力データをBulkLoaderでインポートする場合は、入力データをフラット表またはフラット・ビューで提供します。

- 入力データを独自の方法でBulkLoaderに提供する場合は、抽出インタフェースIDataExtractを実装するJavaオブジェクトを使用します。

注意:

参照用に、サンプルのBulkLoaderコードがWebCenter Sitesのインストール・メディア(Samplesフォルダ)に収録されています。同じフォルダに、サンプル・ファイルの説明が記載されたreadme.txtファイルも含まれています。

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

この項では、BulkLoaderによるフレックス・アセットのインポートに使用する一般手順について説明し、後続の各項では手順ごとに詳しく説明します。このモデルを使用して、新規フレックス・アセットと親をインポートしたり、以前にインポートしたアセットを無効化できます。このモデルは、既存アセットの属性値の変更および削除もサポートしています。

基本手順

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ユーティリティを実行する前に、すべての構造アセット・タイプをインポートしておく必要があります。

ドライバ要件

BulkLoaderではJDBC (Java DataBase Connectivity)ドライバが必要です。このドライバは、Oracle社からは提供されません。JDBCドライバは、ソース・データベースおよび宛先データベース(WebCenter Sitesデータベース)の両方に対して取得する必要があります。ODBC互換のソース・データベースがある場合、Java SDKの一部として付属するJDBC-ODBCブリッジを使用できます。

DB2の要件

WebCenter SitesシステムでDB2データベースを使用している場合は、クライアント・コンピュータ上でusejdbc2.batファイルを実行して、BulkLoaderを使用可能にする必要があります。バッチ・ファイルを1回実行するだけで、BulkLoaderを通常どおりに実行できるようになります。

22.1.5 手順1: XMLPostの使用による構造アセットのインポート

管理システムで、XMLPostとRemoteContentPostポスティング・エレメントを使用して、構造アセットをWebCenter Sitesデータベースにインポートします。次のタイプのアセットをインポートします。

- 属性エディタ

- フレックス属性

- フレックス親定義

- フレックス定義

- フレックス親アセット

この手順の詳細は、第21.3項「フレックス・モデル内の構造アセット・タイプのインポート」を参照してください。

22.1.6 手順2: 入力表(データソース)の作成

すべての新規アセット・データと更新データを保持するために、入力フラット表(データソース)を作成する必要があります。これらのフラット表/フラット・ビューでは、各行が1つのフレックス・アセット・アイテムに相当し、各列がBullkLoaderユーティリティ用のフレックス属性アセットに相当します。

データソースの列名に関して特に要件はありませんが、第22.1.7項「手順3: マッピング表の作成」で説明するマッピング表を別途作成する必要があります。

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

- 第22.1.6.1項「挿入」

- 第22.1.6.2項「更新」

22.1.6.1 挿入

データソース表の名前は、構成ファイル内のinputTableパラメータによって指定されます。

ソース表には、次のプロパティを使用して構成ファイルに指定した次の4つの列名も含める必要があります。

- inputTableTemplateColumn: ソース表でフレックス定義の名前を保持する列の名前。

- inputTableNameColumn: ソース表でフレックス・アセットの名前を保持する列の名前。この列の名前は64文字を超えることはできません。

- inputTableDescriptionColumn: ソース表でフレックス・アセットの説明を保持する列の名前。

- inputTableGroupsColumn: ソース表で親定義の名前を保持する列の名前。この列の各値には、複数のフレックス親定義名を、構成ファイルに定義されているmultivalueDelimeter文字で区切って含めることができます。

オプションとして、構成ファイル内のパラメータinputTableUniqueIdColumnを使用すると、入力アイテム別に一意のIDとして機能する列の名前を指定できます。このパラメータに値が割り当てられていない場合、BulkLoaderは入力アイテム別に一意のIDを生成し、そのIDをWebCenter Sitesデータベース内のマッピング表(bulkloader_ids)に格納します。

次に、ソース表(入力表)の例を示します。

ソース表の列名に基づいて、対応する構成ファイル内のソース表プロパティが次のように設定されます。

inputTableTemplateColumn=SNSTEMPLATE
inputTableNameColumn=SNSNAME
inputTableDescriptionColumn=SNSDESCRIPTION
inputTableGroupsColumn=SNSGROUPS

22.1.6.2 更新

既存アセットに対して新規の親を追加したり既存の親を削除するために既存アセットの属性データを更新する場合は、更新パラメータを使用する必要があります。

構成ファイル内のinputTableForUpdatesパラメータを使用して、データソース表の名前を指定します。ソース表には、次のプロパティを使用して構成ファイルに指定した次の3つの列名も含める必要があります。

- inputTableForUpdatesUniqueIdColumn: ソース表でWebCenter Sitesデータベース内のフレックス・アセットまたはフレックス親を一意に識別する列の名前。

- inputTableForUpdatesDeleteGroupsColumn : ソース表で現在のフレックス・アセットに対して削除する親のリストを指定する列の名前。

- inputTableForUpdatesAddGroupsColumn : ソース表で現在のフレックス・アセットに対して追加する親のリストを指定する列の名前。

属性に更新を適用した場合、BulkLoaderは列値を次のように解釈します。

- 特定の属性列に表示されたNULL値は、現在のフレックス・アセットの属性が削除の対象であることを示します。たとえば、deletegroups列のNULL値は、親を削除する必要がないことを示します。addgroups列のNULL値は、親を追加する必要がないことを示します。

- 非NULL値は、既存の属性値を指定された値で置換する必要があることを示します。たとえば、deletegroups列の非NULL値は、削除する親のリストを指定します。addgroupsの非NULL値は、新規の親が指定されたフレックス・アセットに追加されることを示します。

22.1.7 手順3: マッピング表の作成

また、BulkLoaderユーティリティに対してマッピング表を作成し、次の2つの列を設定する必要があります。

- フラット・データソースにフレックス属性列の名前を保持する列。

- WebCenter Sitesデータベースにそれぞれの対応する名前を保持する列。

マッピング表では、この2つの列は1対1で対応しています。たとえば、ソース表では、A96714328445のように自動生成された名前を持つベンダー名の列が、単にVENDOR_IDという名前の製品属性アセットにマッピングされている場合があります。

マッピング表には、次の構成ファイルのプロパティを含めます。

- inputAttributeMapTable: マッピング表ファイルの名前

- inputAttributeMapTableKeyCol: マッピング表でソース表に属性名を一覧表示する列の名前

- inputAttributeMapTableValCol: WebCenter Sitesデータベース内で対応する属性アセット名を一覧表示する列の名前

次に、マッピング表の例を示します。

ソース表の列名に基づいて、対応する構成ファイル内のソース表プロパティが次のように設定されます。

inputAttributeMapTable=93ATTR_MAP
inputAttributeMapTableKeyCol=SOURCENAME
inputAttributeMapTableValCol=ATTRIBUTENAME

22.1.8 手順4: BulkLoader構成ファイルの作成

BulkLoaderユーティリティを作成するには、この項で説明するプロパティを持つ構成ファイルを作成します。このファイルには任意の名前を付けることができます。

次の構文に従ってファイルにプロパティを設定します。

property=value

注意:

構成ファイルのプロパティ名および値はすべて、大文字と小文字を区別します。

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

- 第22.1.8.1項「BulkLoader構成ファイルのプロパティ」

- 第22.1.8.2項「initIDパラメータの設定」

- 第22.1.8.3項「構成ファイルの例」

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

次の表に、BulkLoader構成ファイルのプロパティを説明します。

表22-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

詳細は、第22.1.8.2項「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=GE Lighting

status

必須

インポートされたすべてのフレックス・アセットのステータス・コード。インポート済のものに対してこれをPLに設定してください。

例:

status=PL

tableProducts

必須

WebCenter Sitesデータベースに定義されたフレックス・アセット・タイプの名前。

inputTableUniqueIdColumn

必須

ソース表で新規フレックス・アセットのインポート時に一意のIDとして機能する列の名前。これは、後続のすべての更新操作および無効化操作に使用されます。

BulkLoaderで一意のIDを生成する場合は、この値を空にします。

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

22.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番号を作成します。

22.1.8.3 構成ファイルの例

次に、GE Lightingサンプル・サイトで使用可能な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=GE Lighting
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
############################################################

22.1.9 手順5: BulkLoaderユーティリティの実行

開始する前に、ソース・データベースとターゲットWebCenter Sitesデータベースの両方に適切なJDBCドライバが指定されていることを確認してください。

次の手順を実行します。

1. 管理システム上のWebCenter Sitesデータベースとソース・データベースの両方へのアクセスに使用したシステムに構成ファイルを配置します。

2. 管理システム上のアプリケーション・サーバーを停止します。

3. すべての単一行に、次のコマンドをそれぞれのインストールに適したパスとともに入力します。
UNIXの場合

java -ms16m -mx256m -cp <path to gatorbulk.jar>/gatorbulk.jar:<path to commons-logging-1.1.1.jar>/commons-logging-1.1.1.jar:<path to cs-core.jar>/cs-core.jar:<path to cs.jar>/cs.jar:<path to commons-codec-1.4.jar>/commons-codec-1.4.jar:<path to httpclient-4.1.2.jar>/httpclient-4.1.2.jar:<path to httpcore-4.1.2.jar>/httpcore-4.1.2.jar:<path to httpmime-4.1.2.jar>/httpmime-4.1.2.jar:<path to jtds-1.2.2.jar>/jtds-1.2.2.jar:<path to commons-lang-2.4.jar>/commons-lang-2.4.jar com.openmarket.gatorbulk.objects.BulkLoader config=bulkloader.ini action=<insert|void|update> validate=<yes|no>

Windowsの場合

java -ms16m -mx256m -cp <path to gatorbulk.jar>\gatorbulk.jar;<path to commons-logging-1.1.1.jar>\commons-logging-1.1.1.jar;<path to cs-core.jar>\cs-core.jar;<path to cs.jar>\cs.jar;<path to commons-codec-1.4.jar>\commons-codec-1.4.jar;<path to httpclient-4.1.2.jar>\httpclient-4.1.2.jar;<path to httpcore-4.1.2.jar>\httpcore-4.1.2.jar;<path to httpmime-4.1.2.jar>\httpmime-4.1.2.jar;<path to jtds-1.2.2.jar>\jtds-1.2.2.jar;<path to commons-lang-2.4.jar>\commons-lang-2.4.jar com.openmarket.gatorbulk.objects.BulkLoader config=bulkloader.ini action=<insert|void|update> validate=<yes|no>

アクション・パラメータは、BulkLoaderが実行する必要のあるアクションとしてinsert、voidまたはupdateを指定します。検証パラメータをyesに設定すると、BulkLoaderは更新および無効化の際に追加の検証を実行します。入力データのサイズによっては、JVM用にメモリーを増設する必要もあります。

4. 画面出力を調べて、BulkLoaderユーティリティが適切なデータベースに接続できていることを確認してください。

22.1.10 手順6: フィードバック情報の確認

BulkLoaderユーティリティの操作完了後、入力データソースに配置されているbulk_feedback表でフィードバック情報を確認します。この表には、BulkLoaderによって処理されたすべての入力アイテムに関する情報が含まれています。

この情報を確認した後で、必要に応じて修正アクションを実行します。入力データを修正する場合は、BulkLoaderを再実行してエラーが修正されていることを検証する必要があります。

22.1.11 手順7: アセットの承認と配信システムへのパブリッシュ

BulkApproverユーティリティを使用して、ロードしたばかりのアセットを承認します。BulkApproverの使用手順は、第22.3.2項「BulkApproverの使用方法」を参照してください。

22.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インポート・スレッドによって作成され、移入されたフィードバック・オブジェクトがクライアントに渡されます。

これらのインタフェースについて、次の各項で説明します。

注意:

カスタム抽出メソッドを実装するときには、前に説明したBulkLoaderの実行手順と同じ手順を使用します。

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

- 第22.2.1項「IDataExtractインタフェース」

- 第22.2.2項「IPopulateDataSlice」

- 第22.2.3項「IFeedbackインタフェース」

22.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スレッドによって呼び出されるため、このメソッドの実装はスレッド・セーフである必要があります。

次の表に、カスタム・データ抽出メソッドの使用時におけるBulkLoaderの構成パラメータを一覧表示して説明します。

表22-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データベースのユーザー・パスワード

22.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);
}

22.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);
}

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

BulkApproverは、BulkLoader経由でシステムにロードされた多数のフレックス・アセットを迅速かつ簡単に承認するユーティリティです。

BulkApproverは次のタスクを実行できます。

- 前のBulkLoaderセッションで行われたすべての更新と削除を承認システムに通知します。

- 1つ以上のパブリッシュ・ターゲットに対して新規にロードされたすべてのフレックス・アセットを承認します。

- 実際にアセットをパブリッシュすることなく、新規にロードされたすべてのフレックス・アセットを指定されたミラー定義に対してパブリッシュ済としてマークします。たとえば、長いミラー・パブリッシュ・セッションを迂回するには、選択したアセットをコンテンツ管理データベースから配信システム上のミラー宛先にコピーし、BulkApproverを使用してミラー宛先に対してアセットをパブリッシュ済とマークします。

注意:

xceladminロールが割り当てられているユーザーのみがBulkApproverを実行できます。

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

- 第22.3.1項「BulkApproverの構成」

- 第22.3.2項「BulkApproverの使用」

22.3.1 BulkApproverの構成

BulkApproverを初めて実行する前に、このユーティリティ用の構成ファイルを作成する必要があります。WebCenter Sitesのデータベースにアクセスできるシステム上でBulkApprover.iniファイルを別途作成するか、BulkLoaderの.iniファイルの1つにBulkApproverの構成情報を追加できます。

次の表に、必須およびオプションの構成パラメータを示します。

表22-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
adminUserName=admin
adminUserPassword=xceladmin
approvalTargetList=Dynamic;;;;;;testdest
multiValueDelimiter=;;;;;;
assetIdSqlFilter=
assetsChunkSize=3
debug=true
outputJdbcDriver=oracle.jdbc.driver.OracleDriver
outputJdbcURL=jdbc:oracle:thin:@19zln:1521:MyServer
#outputJdbcUsername=izod10
outputJdbcUsername=ftuser3
outputJdbcPassword=ftuser3

22.3.2 BulkApproverの使用方法

BulkApproverユーティリティの構成後にこれを使用して、BulkLoaderユーティリティ経由でデータベースにインポートされたアセットを承認できます。

BulkApproverは、コマンドラインから実行します。パラメータについては次の表で説明します。これらのパラメータは次の例に含まれています。

表22-4 BulkApproverのパラメータ

コマンドライン・パラメータ

説明

config

BulkApprover構成情報を格納するファイルの名前(例: BulkApprover.ini)。

action

BulkApproverで実行するアクション。このパラメータはnotifyまたはapproveに設定する必要があります。必要に応じて、他のアクションを追加します。BulkApproverで複数のアクションを実行するには、カンマ区切りリストにアクション名を指定します。

有効な値:

- notify: 前のBulkLoaderセッションで処理されたすべての更新と無効化を承認システムに通知します。

- approve: 指定されたパブリッシュの宛先に対して処理したすべてのアセットを承認するよう、BulkApproverに指示します。

- mark_publish: 実際にアセットをパブリッシュすることなく、処理したすべてのアセットを指定されたミラー宛先に対してパブリッシュ済としてマークします。BulkApprover構成ファイル内のapprovalTargetListパラメータでパブリッシュ・ターゲットを指定します(第22.3.1項「BulkApproverの構成」を参照)。アセットをパブリッシュ済とマークする必要がない場合は、このパラメータを含めません。

output_file

サーバーからのすべての出力が含まれているログ・ファイルの名前(例: bulkapprover.txt)。

BulkApproverを実行するには、次の例に示すようにパスを設定します。

この例では、LinuxおよびSolarisを含むUnixベースのシステム用に、Windowsの構文を使用します。区切りには、スラッシュ(/)およびコロン(:)を使用します。

java -ms16m -mx256m -cp <path to gatorbulk.jar>\gatorbulk.jar;<path to commons-logging-1.1.1.jar>\commons-logging-1.1.1.jar;<path to cs-core.jar>\cs-core.jar;<path to cs.jar>\cs.jar;<path to commons-codec-1.4.jar>\commons-codec-1.4.jar;<path to httpclient-4.1.2.jar>\httpclient-4.1.2.jar;<path to httpcore-4.1.2.jar>\httpcore-4.1.2.jar;<path to httpmime-4.1.2.jar>\httpmime-4.1.2.jar:<path to wem-sso-api-1.2.jar>\wem-sso-api-1.2.jar;<path to apache-mime4j-0.5.jar>\apache-mime4j-0.5.jar;<path to jtds-1.2.2.jar>\jtds-1.2.2.jar;<path to servlet-api.jar>\servlet-api.jar;<path to commons-lang-2.4.jar>\commons-lang-2.4.jar com.openmarket.gatorbulk.objects.BulkApprover config=bulkapprover.ini action=<notify|approve|mark_publish> output_file=<out.txt>

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

CSElement、TemplateおよびSiteEntryの各アセット・タイプにより、オンライン・サイトを構築するページレットとエレメントが提供されます。これらは、ページ名とエレメントおよび、WebCenter Sitesでページの生成に使用するコンポーネントを表現するアセットです。

CSElementアセットの作成時には、エレメントをコーディングします。SiteEntryアセットの作成時には、ページに名前を付けます。テンプレートの作成時には、エレメントのコーディングとページの名前付けの両方を行います。

この章ではこの3つのアセット・タイプについて説明し、その作成方法に関する情報を提供します。テンプレートとCSElementのコーディングに関する追加情報は、第28章「テンプレートおよびCSElementのエレメントのコーディング」に記載されています。

この章には次の項が含まれます。

- 第23.1項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの理解」

- 第23.2項「ページ、ページレットおよびエレメント」

- 第23.3項「CSElementアセット、テンプレート・アセットおよびSiteEntryアセット」

- 第23.4項「テンプレート・アセットの作成」

- 第23.5項「CSElementアセットの作成」

- 第23.6項「SiteEntryアセットの作成」

- 第23.7項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの管理」

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

23.1 テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの理解

この章では、テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成手順を示します。

- テンプレート・アセットは、1つのアセット・タイプに適用されるのか、どのアセット・タイプにも適用されないのかに応じて、タイプ付きまたはタイプなしに分類されます。

- SiteLauncherを使用している場合(サイトのレプリケートまたはテンプレート・アセットとCSElementアセットの共有を目的として)、WebCenter Sitesは、アセット、アセット・タイプ、属性名およびテンプレート名を間接的に参照するために、エレメント・ロジックが必要になります。そのため、WebCenter Sitesインタフェースには、「マップ」画面(たとえば、第23.4.2.5項「手順5: マップの構成」)が導入されていて、APIにはrender:lookupタグが導入されています。
「マップ」画面を使用して、各値に別名を割り当てます。別名をエレメント・ロジックでハードコード化し、render:lookupタグを使用して、実行時に別名から実際値を取得できます。

- 「キャッシュ規則」フィールドは、エラーを減らすために簡略化されています。テンプレートの開発者は、キャッシュ、未キャッシュ、または詳細を選択できます。「詳細」を選択すると、開発者は、WebCenter SitesとSatellite Serverに対して個別にキャッシュ規則を設定できるようになります。

- テンプレートの作成プロセスを簡略化した方法でテンプレートを起動するために、calltemplateタグが新規に導入されました。

- ページ基準フィールドは、「キャッシュ基準」と名前変更されました。これは予約パラメータc、cid、context、p、rendermode、site、sitepfx、ft_ssと、カスタム定義済パラメータを受け入れます。
キャッシュ基準の値は、SiteCatalog表のpagecriteria列に格納されます(旧バージョンでは、SiteCatalog表のresargs列に格納されていました)。

「キャッシュ基準」フィールドは、CKEditorの「その他のパラメータ」セクションを有効化する変数の保持にも使用され、その変数をユーザーが「アセット・リンクを含める」ダイアログ・ボックスと「アセット・リンクの追加」ダイアログ・ボックスで使用できるようにします。「その他のパラメータ」セクションには、カスタム・パラメータ(イメージ・ディメンションなど)をテンプレートに渡す方法が用意されています。その他のパラメータの詳細は、第23.4.2.4項「手順4: SiteEntryの構成」の手順2に含まれる手順3を参照してください。詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

- テンプレート・アセットとCSElementアセットの作成フォームはタブによって細分化されています。フィールドはタブ上で機能別に編成されています。

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

WebCenter Sitesのコンテキストでは、オンライン・ページは複数のコンポーネントを表示可能な最終出力に構成したものです。この出力を作成することをレンダリングといいます。(出力またはレンダリングされるコンテンツをパブリック・サイトの訪問者が利用できるようにすることを、パブリッシュといいます。)

WebCenter Sitesでは、ページは、ページ名に関連付けられたコードを実行してレンダリングされます。ページの名前はブラウザからWebCenter Sitesに渡され、WebCenter Sitesはそのページ名に関連付けられたコードを起動します。コードは実際には名前付きファイルであり、エレメントと呼ばれるコードの個々のチャンクです。

エレメント内のコードはアセットを識別し、ページまたはページレットに表示するためにそのアセットをロードします。また、その他のページ名とエレメント名をWebCenter Sitesに渡します。WebCenter Sitesがエレメントを呼び出すと、そのエレメント内のすべてのコードが実行されます。他のエレメントへのコールがある場合は、次にそのエレメントが呼び出されます。さらに、結果(イメージ、記事、リンクセットなど、すべてのHTMLタグを含む)がHTMLコード(または、システムの構成によっては、他の出力フォーマット)にレンダリングされます。

Template、CSElementおよびSiteEntryの各アセットは、次のようにエレメントとページレットを表現します。

- CSElementアセットはエレメントです。

- SiteEntryアセットはページまたはページレットの名前です。

- テンプレート・アセットは、エレメントおよび、アセットをレンダリングするページまたはページレットの両方になります。

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

- 第23.2.1項「エレメント、ページレットおよびキャッシュ」

- 第23.2.2項「ページとエレメントのコール」

- 第23.2.3項「ページとページレットの比較」

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

ページとページレットはキャッシュ可能です。これらには、キャッシュ済であるかどうか、またキャッシュ済の場合はその期間を判別するキャッシュ基準が設定されています。

エレメントには、キャッシュ基準は設定されていません。ページ名を経由することなく、コードからエレメントを名前で直接コールすると、その出力はエレメントの名前をコールしたページに表示され、そのページの一部としてキャッシュされます。

エレメントからの出力を、それをコールしたページからの出力とは別にキャッシュする場合は、その出力にページ名を指定し、出力をコールするときにはそのページ名を使用する必要があります。テンプレート・アセットのコードには、デフォルトによりページ名が割り当てられています。CSElementアセットに対してページ名を指定するには、SiteEntryアセットを作成し、それに対するCSElementアセットを選択します。

23.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サーブレットに渡され、そこでページがレンダリングされます。

たとえば、Burlington Financialサンプル・サイトのホームページを表示するには、次のように入力します。

http://127.0.0.1:7001/servlet/ContentServer?pagename=
BurlingtonFinancial/Page/Home

エレメントをコーディングするときには、サイトに表示するページレットとエレメントをプログラムでコールするタグを使用します。これらのタグは、ちょうどブラウザで入力したURLがページ名をContentServerサーブレットに渡すように、ページとエレメントの名前をContentServerサーブレットに渡します。

ページ名をコールするには、render:satellitepage (RENDER.SATELLITEPAGE)タグを使用します。例:

<render:satellitepage pagename="BurlingtonFinancial/Page/Home" />

エレメントを名前で直接コールするには、render:callelement (RENDER.CALLELEMENT)タグを使用します。例:

<render:callelement elementname="BurlingtonFinancial/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>

注意:

Sites Explorerを使用してSiteCatalogエントリとElementCatalogエントリを調査する場合、これらのエントリは、ページとページレットを視覚的に編成したフォルダおよびサブフォルダとして表示されます。

ただし、これらのエントリはデータベース表内の行にすぎません(実際の階層は存在しません)。そのため、コードでページ・エントリまたはエレメント・エントリをコールする場合は、常にフルネームを使用する必要があります。相対パスは使用できません。

コードによってテンプレート、CSElementおよびSiteEntryの各アセットをコールする方法は、次のとおりです。

- SiteEntryはページレットであるため、render:satellitepageタグを使用して、エレメント・コードの中からSiteEntryアセットをコールします。

- CSElementはエレメントであるため、render:callelementタグを使用して、エレメント・コードの中からCSElementアセットをコールします。

- テンプレートはエレメント名とページ名の両方であるため、前述のいずれかを使用できます。ただし、通常、render:calltemplateタグはテンプレートに使用することを目的としています。これは、render:satellitepageおよびrender:calleelementの機能のみでなく、パラメータの検証など、その他の機能もカプセル化します。

23.2.3 ページとページレットの比較

理解を深めるために、次の表に、ページという語を含む様々な用語を示し、WebCenter Sites、WebCenter Sitesの各モジュール、およびその他の製品向け各種ドキュメントでの使用を踏まえて、それらの用語を定義します。

用語

定義

ページレット

レンダリングされたページの一部としてブラウザに表示されるHTTPリクエストの結果。これには、エレメント・ファイルが関連付けられています。

ページレットは、WebCenter SitesおよびSatellite Serverのページ・キャッシュにキャッシュできます。

ページ

ブラウザ・ウィンドウに表示されるHTTPリクエストの結果。ページは、ページ(ページレット)の複数の部分を1つの表示済またはレンダリング済の最終ページにコンパイルすることによって作成されます。これには、エレメント・ファイルが関連付けられています。

ページは、WebCenter SitesおよびSatellite Serverのページ・キャッシュにキャッシュできます。

ページ名

ページまたはページレットの完全な名前。例: BurlingtonFinancial/Article/Full。

ページ・アセット

ページ・アセットはページ名を表現しません。これは、コンテンツ用の論理コンテナを表現します。このコンテナをツリー構造に配置して、サイト・コンテンツのナビゲーションに対応できます。

ページ・アセットを作成し、それを「サイト・プラン」ツリーに配置します。このツリーは、WebCenter Sitesインタフェースの左ペインの「サイト」タブにツリー構造で表示されます。その他のコンテンツとサイト・デザイン・アセットをページ・アセットに関連付けた後で、パブリッシュします。

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

前述したように、CSElementアセットはエレメント、SiteEntryアセットはページ名、そしてテンプレート・アセットはその両方を含みます。

ページ名とエレメントはアセットであるため、作成したコードとページ名をコンテンツの管理方法と同様に管理できます。つまり、ワークフロー、リビジョン追跡、承認およびプレビューが使用できるだけでなく、サーバーへのミラーリングのパブリッシュ方法を使用してコードとページ名を管理システムや配信システムに移動することもできます。

注意:

リビジョン追跡。SiteCatalog表またはElementCatalog表でリビジョン追跡を直接有効にするために、Site Explorerツールのリビジョン追跡機能を絶対に使用しないでください。

サーバーへのミラーリング。テンプレートまたはCSElementが、テンプレート・アセットまたはCSElementアセットに関連付けられていないエレメントを参照する場合、これに該当するエレメントが自動的にパブリッシュの宛先にミラーリングされることはありません。CatalogMoverユーティリティを使用して、これらのエレメントを手動で移動する必要があります。そのため、CSElementによって折り返されないエレメントの使用はお薦めできません。

CSElementアセットまたはテンプレート・アセットを作成するときには、エレメントを作成します。エレメントは、アセット・フォーム(作成中のアセットのタイプに応じて、「テンプレート」または「CSElement」)を使用することでコーディングできます。

注意:

テンプレート・アセットとCSElementのエレメントは、Sites Explorerでコーディングできます。ただし、ほとんどが構成上の依存性とキャッシュへのアップデートを扱うため、この方法はお薦めできません。Sites Explorerを優先的に使用する開発者は、テンプレート・アセットまたはCSElementアセットの有効性を確保するために、第23.8項「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」に記載する手順に従う必要があります。

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

- 第23.3.1項「テンプレート・アセット」

- 第23.3.2項「CSElementアセット」

- 第23.3.3項「SiteEntryアセット」

- 第23.3.4項「非アセット・エレメントとは」

23.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表に作成します。

23.3.2 CSElementアセット

CSElementアセットの用途は次のとおりです。

- アセットをレンダリングするためのコードではなく、1か所以上で再使用したり、1つ以上のタイプのテンプレートからコールするコード。たとえば、同じトップ・バナーを使用するテンプレートが6つあり、バナーのコード用にCSElementアセットを作成して、各テンプレートからエレメントをコールする必要があるとします。この場合、バナーの動作方法を変更するときに、1か所で変更するだけで済みます。

- Engageに対する推奨。動的リスト推奨を作成する場合、動的リストを作成するためにCSElementアセットを作成する必要があります。詳細は、第39章「推奨アセット」を参照してください。これらのアセットはコンテンツをレンダリングしませんが、ロジック処理のために存在します。

CSElementを保存すると、WebCenter Sitesは次の操作を行います。

- アセットの行をCSElement表に作成します。

- エレメントを「CSElement」フォームにコーディングした場合は、ElementCatalog表にエレメント・エントリを作成します。このエントリの名前には、フォームで「ElementCatalogエントリ名」フィールドに入力した名前が使用されます。

- テンプレートをサイトに関連付けるために新しい行をAssetPublication表に作成します。

23.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をレンダリング・エンジンに記録します。

23.3.4 非アセット・エレメントとは

管理システム上でWebCenter Sitesインタフェースに対してカスタマイズをコーディングする場合は、そのカスタマイズを配信システムにパブリッシュする必要がないため、アセットではないエレメントを作成します。

たとえば、アクションまたは条件を実装するワークフロー・エレメントを作成する場合は、それをCSElementアセットとしては作成しません。かわりに、Sites Explorerツールを使用してエントリをElementCatalog表に手動で作成します。

配信システム上でワークフローまたはその他のカスタム・エレメントを作成する場合は、CatalogMoverユーティリティを使用して、そのエレメントを管理システム上のElementCatalogにコピーする必要があります。

注意:

ミラー・エンジンを起動するコードを作成して、エレメントをミラーリングできます。このトピックは高度であり、このガイドの適用範囲を超えています。サポートが必要な場合は、Oracleサポート(www.oracle.com/support)にお問い合せください。聴覚に障害のある方は、www.oracle.com/accessibilityにアクセスしてください。

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

テンプレートはアセットをレンダリングします。テンプレート・アセットを作成する場合は、次のいずれかとして作成します。

- タイプ付きテンプレート: 特定のタイプのアセットをレンダリングする場合。

- タイプなしテンプレート: 適用されるアセットのタイプを問いません。タイプなしテンプレートは一般に、ページのレイアウトを指定するために使用します。その後、ページではアセットをタイプ付きテンプレートによってレンダリングできます。

注意:

テンプレートをタイプ付きまたはタイプなしに設定する唯一のフィールドは、「対象アセット・タイプ」フィールドです。テンプレートをタイプ付きまたはタイプなしに区別する目的は、開発者がページの構成を管理し、ページ・レイアウトに対応するテンプレートとアセット・レンダリングに対応するテンプレートを追跡しやすいようにするためです。

テンプレート・アセットを作成する前に、第23.4.1項「前提条件」を完了して、テンプレート・プロパティ(テンプレート名など)の設定方法とテンプレートのエレメント・ロジックのコーディング方法を決定します。その後で、WebCenter Sitesインタフェースを使用して次の手順を実行します。

- 手順1: 「テンプレート」フォームを開く

- 手順2: テンプレート・アセットの名前付けと記述

- 手順3: テンプレートのエレメントの構成(使用法、ファイル・タイプ、およびロジックの指定。)

- 手順4: SiteEntryの構成(ページおよびページレットのキャッシュ・パラメータの指定。)

- 手順5: マップの構成(テンプレート共有とサイト・レプリケーションのサポートが必要な場合。)

- 手順6: (オプション)サムネイルの作成(テンプレートの「調査」フォームにテンプレートをグラフィックで表示する。)

- 手順7: テンプレートの調査

「テンプレート」フォームに入力する情報は、テンプレートの保存時にデータベース表に書き込まれます。

注意:

テンプレート・アセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。かわりに、「テンプレート」フォームと、この項に示した手順を使用してテンプレート・アセットを作成します。テンプレートのエレメント・ロジック(タイプ付きテンプレートの場合)のコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

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

- 第23.4.1項「前提条件」

- 第23.4.2項「テンプレート・アセットの作成手順」

23.4.1 前提条件

テンプレート・アセットの作成を開始する前に、次の点を決定してください。

- TemplateName(テンプレート・アセットの名前。「名前」画面の「名前」フィールドの値です。「テンプレート・アセットの名前付けと記述を行うには」を参照してください)。

- テンプレート・アセットがタイプ付きまたはタイプなしのいずれであるか。

- テンプレート・アセットを共有するかどうか、また使用中のサイトをレプリケートするかどうか。これらの考慮事項により、テンプレートのエレメント・ロジックのコーディング方法を決定します。

- テンプレートのエレメント・ロジックのコーディングを、「テンプレート」フォームではなくSite Explorerで実行するかどうか。Sites Explorerでのコーディングは慣習化されていますが、第23.8項「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」で概説している理由によりお薦めできません。

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

- テンプレート・アセットが保存されると、その名前は変更できなくなります。

- WebCenter Sitesにより、テンプレート名はSiteNameに追加されます(タイプ付きテンプレートの場合は、AssetTypeNameにも追加されます)。テンプレート名は、SiteNameおよびAssetTypeNameに関連して意味のあるものにする必要があります。WebCenter Sitesのネーミング規則をオーバーライドしないでください。WebCenter Sitesにより作成された名前は変更しないでください。表23-1に、TemplateNameを使用する規則を示します。
AssetTypeNameはタイプ付きテンプレートにのみ使用し、「名前」画面でのテンプレートの「対象アセット・タイプ」フィールドの値を表します(「テンプレート・アセットの名前付けと記述を行うには」を参照)。SiteNameは、テンプレートが属するサイト(テンプレートの作成時に使用しているサイト)の名前です。WebCenter Sitesは、SiteNameをPublication表から取得します。(この製品の旧バージョンでは、サイトはパブリケーションと呼ばれていました。)

表23-1 TemplateNameを使用するネーミング規則

テンプレート

ネーミング規則

説明

タイプ付き

AssetTypeName/TemplateName

タイプ付きテンプレートのルート・エレメントの名前。

この値は、手順4で「Rootelement」フィールドに書き込まれます。この値は、変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

注意: ネーミング規則により、ルート・エレメントの名前は一意にする必要があります。複数のテンプレート・アセットが同じルート・エレメントを指さないようにする必要があります。ただし、2つのSiteEntryアセットが同じエレメントを指すように設定できます(たとえば、コール・シナリオに応じて、異なるデフォルト引数または異なるキャッシュ基準を指定したい場合)。

なし

AssetTypeName/TemplateName.xml_or_jsp_or_html

タイプ付きテンプレートのエレメント・ファイルへのパス。

この値は、手順3でファイル・タイプを選択したときに、「エレメントのストレージ・パス/ファイル名」に書き込まれます。

なし

SiteName/AssetTypeName/TemplateName

テンプレートがタイプ付きの場合にレンダリングされるページの名前。

この値は、第23.4.2.4項「手順4: SiteEntryの構成」で「SiteCatalog Pagename」フィールドに書き込まれます。

タイプなし

/TemplateName

タイプなしテンプレートのルート・エレメントの名前。

この値は、手順4で「Rootelement」フィールドに書き込まれます。この値は、変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

注意: このテンプレートは任意のアセット・タイプに適用できるため、AssetTypeNameは省略されています。スラッシュは、テンプレートをタイプなしとして識別するために付けられます。この表の1行目の注意を参照してください。

なし

Typeless/TemplateName.xml_
or_jsp_or_html

タイプなしテンプレートのエレメント・ファイルへのパス。

この値は、手順3でファイル・タイプを選択したときに、「エレメントのストレージ・パス/ファイル名」に書き込まれます。

なし

SiteName/TemplateName

テンプレートがタイプなしの場合にレンダリングされるページの名前。

この値は、第23.4.2.4項「手順4: SiteEntryの構成」で「SiteCatalog Pagename」フィールドに書き込まれます。

注意: このテンプレートは任意のアセット・タイプに適用できるため、AssetTypeName/は省略されています。

タイプ付き

AssetTypeName/TemplateName

タイプ付きテンプレートのルート・エレメントの名前。

この値は、手順4で「Rootelement」フィールドに書き込まれます。この値は、変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

注意: ネーミング規則により、ルート・エレメントの名前は一意にする必要があります。複数のテンプレート・アセットが同じルート・エレメントを指さないようにする必要があります。ただし、2つのSiteEntryアセットが同じエレメントを指すように設定できます(たとえば、コール・シナリオに応じて、異なるデフォルト引数または異なるキャッシュ基準を指定したい場合)。

なし

AssetTypeName/TemplateName.xml_or_jsp_or_html

タイプ付きテンプレートのエレメント・ファイルへのパス。

この値は、手順3でファイル・タイプを選択したときに、「エレメントのストレージ・パス/ファイル名」に書き込まれます。

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

テンプレート・アセットを作成する前に、それをタイプ付きまたはタイプなしのいずれにするかを決定します。テンプレートが保存されると、そのタイプ付きまたはタイプなしのステータスは変更できなくなります。

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

テンプレートを作成する前に、テンプレートおよび使用中のサイトの使用方法を決定します。この決定によって、テンプレートのエレメント・ロジックをコーディングする方法が決まります(第23.4.2.3項「手順3: テンプレートのエレメントの構成」)。

テンプレート・アセットを共有したり、現在のサイトをレプリケート可能にする場合は、テンプレートのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照していないことを確認してください。かわりに、それらを間接的に参照する必要があります。「マップ」画面(第23.4.2.5項「手順5: マップの構成」)を使用して、各値に別名(キー)を割り当ててから、その別名をテンプレート内でハードコード化します。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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

23.4.2 テンプレート・アセットの作成手順

この項では、WebCenter Sitesインタフェースを使用したテンプレート・アセットの作成方法を示します。

注意:

この項の手順を開始する前に、第23.4.1項「前提条件」を参照して、テンプレート・アセットの作成についての情報を確認してください。

23.4.2.1 手順1: 「テンプレート」フォームを開く

1. Adminインタフェースを開きます。

2. ボタン・バーで、「新規」をクリックします。

3. アセット・タイプのリストで、「新規テンプレート」を選択します。

注意:

「新規テンプレート」オプションを表示するには、サイトに対してテンプレート・アセット・タイプを有効化し、そのスタート・メニュー・アイテムを作成する必要があります。

4. 「テンプレート」フォームが表示されます。第23.4.2.2項「手順2: テンプレート・アセットの名前付けと記述」に進みます。

注意:

「テンプレート」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているテンプレート・アセットがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。第23.4.2.2項「手順2: テンプレート・アセットの名前付けと記述」に進みます。

23.4.2.2 手順2: テンプレート・アセットの名前付けと記述

「名前」画面は、タイプ付きまたはタイプなしとしてのテンプレートの識別、カテゴリへのテンプレートの割当て、テンプレートに渡される可能性のある引数の指定、検索ルーチンへのテンプレートの配置に使用できるキーワードの名前付けに使用します。

テンプレート・アセットが保存されると、「名前」画面で指定するフィールド値(適切な引数を除く)が、次の手順に示すように、Template表に書き込まれます。

注意:

テンプレートの作成中はいつでもテンプレートを保存できます。WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。「テンプレート」フォームに戻るには、「編集」リンクをクリックします。

テンプレート・アセットの名前付けと記述を行うには

「名前」画面で、次の手順の説明に従ってフィールドに値を入力します。

1. (必須)。「名前」フィールドに、説明的なテンプレートの名前を入力します。この名前は、テンプレートと、そのテンプレートでレンダリングするアセットのタイプに固有なものにします。テンプレートの機能または目的を反映する名前を選択することをお薦めします。
有効なエントリ:

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)

注意:

テンプレート・アセットの名前は、第23.4.1項「前提条件」のガイドラインを使用して決定してください。

2. 「説明」フィールドに、テンプレートの簡単な説明を入力します。最大128文字まで使用できます。

3. 注記が必要なソースからテンプレートを派生している場合は、「ソース」フィールドのドロップダウン・リストからオプションを選択します。

4. テンプレート・アセットを特定のカテゴリに配置する場合は、「カテゴリ」フィールドのドロップダウン・リストからオプションを選択します。

5. (必須)。「対象アセット・タイプ」フィールドで、テンプレートをタイプ付きまたはタイプなしとして特定します。

- タイプなしテンプレートを作成している場合(たとえば、タイプ付きテンプレートにディスパッチする場合)は、「各種アセット・タイプに適用可能」を選択して、手順7に進みます。

- タイプ付きテンプレート(特定のタイプのアセットをレンダリングするもの)を作成している場合は、アセット・タイプを選択します。たとえば、記事アセットをレンダリングするためにテンプレートを作成している場合は、ドロップダウン・リストから「記事」を選択します。

6. (タイプ付きテンプレートに必須)。「サブタイプに適用」フィールドのメニューから、適切なサブタイプを選択します。

注意:

タイプ付きテンプレートは、直前のフィールド(「対象アセット・タイプ」)で選択したアセット・タイプに含まれる特定のサブタイプにのみ使用することをお薦めします。

7. 「適切な引数」フィールドで、次の手順を実行します。

1. テンプレートに渡される可能性のある引数を入力して、「引数の追加」をクリックします。

2. 表示されたフィールドで、次の手順を実行します。

- 引数がオプションか、または必須かを指定します。

- 引数の説明を提供します(作成する引数の目的を把握しやすいようにするため)。

- 引数に対して適切な値(説明を含む)を指定します。

(「引数の追加」ボタンと「適切な値の追加」ボタンをクリックすることで、必要な数の引数と適切な値を指定できます。)

8. 「キーワード」フィールドに、将来このテンプレートを検索するときに「詳細検索」フォームで検索基準として使用できるようにするキーワードを入力します。アセットの検索の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

9. 「続行」をクリックして、その次の画面「エレメント」を開きます。

注意:

テンプレート・アセットを保存するように選択した場合は、次の2つのフィールドが追加されます。

- 「ステータス」フィールド: このフィールドには、テンプレート・アセットの編集ステータス(「作成済」、「編集済」など)が事前に移入されています。このフィールドでは、テンプレート・アセットがワークフローに関連付けられているかどうかに関係なく、テンプレート・アセットで最後に実行された操作が特定されます。

- 「ID」フィールド: このフィールドには、WebCenter Sitesが生成する一意の数値が事前に移入されていて、テンプレート・アセットにIDとして割り当てられます。(「ID」フィールドはtid変数に相当します。)

23.4.2.3 手順3: テンプレートのエレメントの構成

「エレメント」画面は、テンプレートのエレメントの作成、エレメント・ファイル・タイプ(XML、JSP、またはHTML)の定義、エレメント・ロジックの提供、およびエレメントの名前付けに使用します。例:

- 「$Template$エレメントを作成しますか。」フィールドにはエレメント・ロジック用に選択可能なファイル・タイプXML、JSP、HTMLが表示されます。このフィールドは、「エレメント・ロジック」フィールドに標準スタブ・コード(作成するすべてのエレメントに含める必要がある)をシードする際に使用します。
テンプレート・エレメントの作成フィールドを使用して、たとえば.jspファイルを作成すると、WebCenter Sitesは、デフォルトでJSPのtaglib文とRENDER.LOGDEPタグを「エレメント・ロジック」フィールドに追加して、このテンプレート・アセットとこのエレメントからレンダリングされるページ間の構成の依存性のログ記録できるようにします。その他のファイル・タイプの場合は、それぞれのファイル・タイプに固有のコードが追加されます。独自のコードを「エレメント・ロジック」フィールドに追加します。

依存性の詳細は、第28.1項「依存性について」を参照してください。エレメント・ロジックのコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- 「エレメントのストレージ・パス/ファイル名」フィールドでは、エレメント・ロジックを保持するファイルの名前を付けて、そのファイルへのパスを指定します。

テンプレート・アセットが保存されると、「エレメント」画面のフィールド値は、次の手順で示すように、ElementCatalog表の(エレメントを表す)行に書き込まれます。

注意:

既存エレメントの選択

次の手順では、テンプレート・アセットのエレメントを新規作成しているものとします。ただし、旧リリースのWebCenter Sitesからアセットを移行していて、既存エレメントを再使用する場合は、WebCenter Sitesで既存エレメントを検出し、このテンプレート・アセットと関連付けられるようにするために、エレメントを正確に識別する必要があります。

既存のエレメントを選択するには:

1. (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。

2. 「エレメントのストレージ・パス/ファイル名」フィールドに、表23-1のネーミング規則に従った値を入力します。

3. 「エレメント・パラメータ」フィールドで、エレメントに渡される可能性のある変数または引数を指定します。詳細は、「新しいエレメントを構成するには」の項の手順7を参照してください。

4. テンプレート・アセットを保存し、再度開きます。

WebCenter Sitesは、指定されたエレメントの存在をチェックします。

エレメントに適切な名前が付けられていると、WebCenter Sitesはエレメントを認識して、そのコードを「エレメント・ロジック」フィールドに表示します。

指定されたエレメントが存在しない場合(または、名前が不適切な場合)は、何も行われません。テンプレート・アセットを調査または編集するときに、フォームにルート・エレメントがありませんというメッセージが表示されます。エレメントをコーディングして適切な名前を付けるとただちに検出され、テンプレートに関連付けられます。

新しいエレメントを構成するには:

「エレメント」画面で、この項の説明に従って各フィールドに値を入力します。

1. 「使用」フィールドで、次の表をガイドラインとして使用して、このテンプレートの用途を指定します。

使用オプション

説明

使用は未指定

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エレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

次のフィールドが移入されます。

- ヘッダーとその他の自動生成コードを持つ「エレメント・ロジック」フィールド。
たとえば、「JSP」ボタンをクリックすると、WebCenter SitesのJSPタグ・ライブラリごとのタグ・ライブラリ・ディレクティブが入力されます。また、WebCenter Sitesにより、テンプレート・アセットと、そのテンプレートによってレンダリングされるページまたはページレット間の構成の依存性をマークするために、RENDER.LOGDEP (render:logdep)タグが設定されます。

- 「エレメントのストレージ・パス/ファイル名」フィールド。このフィールドの値は変更しないでください。
このフィールドには、エレメント・ファイルへのパスが先行するエレメント・ファイル名が表示されます。ネーミング規則は、表23-1に記載されています。

テンプレート・アセットを保存すると、「エレメントのストレージ・パス/ファイル名」フィールドの値は、ElementCatalog表のurl列のエレメントを表す行に書き込まれます。

4. 「Rootelement」フィールドには、表23-1に示す値が事前に移入されています。このフィールドの値は変更しないでください。デフォルト値が変更されると、デフォルト値を予想しているタグ(たとえば、style属性がelementに設定されているrender:calltemplateタグなど)が失敗します。

5. (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。テンプレート・アセットを保存すると、このフィールドの情報はElementCatalog表のエレメント・エントリに対するdescription列に書き込まれます。

6. (必須)。「エレメント・ロジック」フィールドに、エレメントをコーディングします。2つのcs:ftcsタグの間にすべてのコードを入力します。
JSPを使用している場合は、使用中のタグ・ライブラリを記述するtaglibディレクティブからコメントを削除します。

この手順については、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

注意:

テンプレート共有またはレプリケート可能サイトの確保
テンプレート・アセットを共有したり、現在のサイトをレプリケート可能にする場合は、テンプレートのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照しないようにしてください。そのかわりに、第23.4.1.3項「テンプレート共有とサイト・レプリケーション」で説明するように、render:lookupタグと所定のキーを使用します。第23.4.2.5項「手順5: マップの構成」では、これと同じキーを、エレメント・ロジックで使用するためにアクセスする必要のあるアセット情報にマップすることになります。

テンプレートのコール
テンプレートは常に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個までの文字をサポートします。

変数の使用方法の詳細は、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

8. 「続行」をクリックして、その次の画面「SiteEntry」を開きます。

23.4.2.4 手順4: SiteEntryの構成

「SiteEntry」画面は、このテンプレート・アセットによってレンダリングされるページのキャッシングおよびページレット・パラメータの指定に使用します。

テンプレート・アセットが保存されると、「SiteEntry」画面で指定したフィールド値が、次の手順に示すように、SiteCatalog表に書き込まれます。

SiteEntryを構成するには:

1. 「SiteEntry」画面で、この項の説明に従って各フィールドに値を入力します。

2. 「キャッシュ基準」フィールドで、次の手順を実行します。

1. WebCenter Sitesでは、次の予約変数がキャッシュ基準として指定されています。

c,cid,context,p,rendermode,site,sitepfx,ft_ss

注意:

予約されたキャッシュ基準変数は、削除しないでください。予約変数の詳細は、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

2. 独自の変数をキャッシュ基準として含める必要がある場合は(たとえば、foo)、その変数を既存のリストに追加します。例:

c,cid,context,foo,p,rendermode,site,sitepfx,ft_ss

注意:

「キャッシュ基準」フィールドでは、「SiteCatalog Pagename」と組み合せてページレットを一意に定義する変数を指定します。変数は、キャッシュされたページの識別に使用されます。つまり、変数はページのキャッシュ・キーで使用されることになります。

キャッシュ基準として指定された変数のみが、キャッシュされたページのキャッシュ・キーを作成するためにキャッシング・システムで使用されます。したがって、サイト・デザインにより、予約変数に加えてページ・レベルの変数を使用する必要がある場合は、この手順で示すように、必ずこれらの変数をキャッシュ基準変数として指定してください。

3. CKEditorの「追加のパラメータ」セクションを使用可能にする場合は、次の手順を実行します。

1. テンプレートの「キャッシュ基準」に追加した「追加のパラメータ」を、テンプレートの「適切な引数」セクションに移動します。

2. パラメータを「適切な引数」セクションに移動すると、そのパラメータには接頭辞fp:を付ける必要がなくなるため、パラメータ名は接頭辞なしで使用します。
たとえば、fp:imageHeightを使用するのではなく、単にimageHeightを使用します。

3. これらのパラメータは、そのパラメータを含むテンプレートで使用できるようになり、<ics:getvar name="imageHeight"/>などの標準的な方法で取得できるようになります。

「その他のパラメータ」セクションには、イメージ・ディメンションなどのカスタム・パラメータをテンプレートに渡す方法が用意されています。このようなその他のパラメータは、「アセット・リンクを含める」および「アセット・リンクの追加」の各ダイアログ・ボックスで使用できるようになります。パラメータ名(この例では、imageHeightとimageWidth)は、「名前」メニューのオプションとして、CKEditorの「その他のパラメータ」セクションに表示されます。「値」フィールドでは、選択したパラメータの値をユーザーが指定できます。その他のパラメータの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

テンプレート・アセットが保存されると、キャッシュ基準の変数がSiteCatalog表のpagecriteria列に書き込まれます。

4. (オプション)。「アクセス制御リスト」フィールドは、SiteCatalog表のacl列に相当します。特定の訪問者のみがこのページをリクエストできるようにする場合は、ページを表示するために訪問者が必要とするACLを選択します。ACLの詳細は、第31章「配信システムにおけるユーザー管理」を参照してください。

5. 「Rootelement」フィールドには、表23-1に示す値が事前に移入されています。

6. 「キャッシュ規則」フィールドは、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はキャッシュを適切にフラッシュできなくなり、無効なページがキャッシュから使用される場合があります。上級ユーザーのみが、これらの設定を手動で構成することをお薦めします。

ページ・キャッシュ設定の詳細は、第5章「ページのデザインとキャッシング」を参照してください。

ページ・キャッシュ設定の詳細は、第5章「ページのデザインとキャッシング」を参照してください。

1. 「SiteCatalog Pagename」フィールド。このフィールドの値は変更しないでください。このページには、ページ・エントリの名前が事前に移入されています。ページのネーミング規則は、表23-1に記載されています。

2. 「ページレット・パラメータ」セクションでは、テンプレートが実行されるたびにテンプレートに渡されるページレット・パラメータ(名前と値のペア)を入力できます。(「ページレット・パラメータ」セクションでは、合計510文字をサポートしています。)

注意:

「ページレット・パラメータ」セクションには、次のデフォルトのページレット・パラメータ(手順2で指定されている予約変数)が事前に移入されています。これらの値は次のとおりです。

site, sitepfx, rendermode

デフォルトのパラメータ値は、テンプレートがコールされたときに明示的に指定された場合は、上書きされます。

- この手順でページレット・パラメータを指定する場合は、必ずその名前をキャッシュ基準の変数としてリストに追加します(手順2を参照)。

- 独自のキャッシュ基準の変数を(手順2で)指定した場合、その変数は、「ページ・パラメータ」セクションのリストに表示されます。これらのパラメータに対して値を指定しない場合、パラメータは無視されます。

テンプレート・アセットが保存されると、ページレット・パラメータとして指定した名前と値のペアは、SiteCatalog表のresargs1列またはresargs2列のいずれかに書き込まれます。書込み先の列は重要ではないため、自動的に管理されます。(各列では、最大255文字をサポートしています。)

3. 「続行」をクリックして、その次の画面「サムネイル」を開きます。

4. 「続行」をクリックして、その次の画面「マップ」を開きます。

注意:

テンプレート・アセットの作成が完了してテンプレート・アセットを保存した後で、「サムネイル」画面に戻ります。

23.4.2.5 手順5: マップの構成

マッピングの目的は、第23.4.1.3項「テンプレート共有とサイト・レプリケーション」で説明するように、サイト・レプリケーションとテンプレート・アセットの共有を有効化することです。

注意:

レプリケート不能のサイトを設計している場合は、この項をスキップしてください。

「マップ」フォームを使用して、次の操作を行います。

- テンプレートのエレメント・ロジックのrender:lookupタグにある各キーを、エレメント・ロジックで使用される値にマップします。

- 各キーの値を、エレメント・ロジックで使用する必要のある情報(アセット、アセット・タイプ、属性名、またはテンプレート名)にマップします。

テンプレート・アセットが保存されると、マップはTemplate_Map表に書き込まれます。

マップを構成するには:

「マップ」フォームで、この項の説明に従って各フィールドに値を入力します。

1. 「キー」フィールドは、エレメント・ロジックが検索する値を表しています。エレメント・ロジックのrender:lookupタグで指定したキーを入力します。

2. 「タイプ」フィールドでは、アクセス対象のアセット情報のタイプを特定します。次のいずれかのオプションを選択します。

- テンプレート名: テンプレート名をキー値にマップします(この値は、次の手順で「値」フィールドに指定します)。アクセスされる情報は、次の手順で指定する値に一致するテンプレート名です。例は、図23-1を参照してください。

- アセット・タイプ: アセット・タイプをキー値にマップします。アクセス対象の情報はアセット・タイプであり、次の手順で指定する値と同等です。

- アセット(タイプ: 名前): 属性タイプ:名前をキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

- アセット(タイプ: ID): 属性のタイプ:IDをキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

図23-1 テンプレート・アセット: サンプル・マップ

3. 「値」フィールドに、キーの値を入力します。この値は、テンプレート実行時にエレメント・ロジックにより検索されます。

4. 「サイトID」フィールドで、マッピングを適用するサイトの名前を選択します。

5. キーを追加するには、「さらに追加」をクリックして、この項の手順を繰り返します。

6. テンプレートの作成が完了したら、テンプレートを保存します(「変更の保存」をクリックします)。
WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。

7. テンプレートのサムネイルを作成する場合は、第23.4.2.6項「手順6: (オプション)サムネイルの作成」に進みます。それ以外の場合は、第23.4.2.7項「手順7: テンプレートの調査」に進みます。

23.4.2.6 手順6: (オプション)サムネイルの作成

サムネイルはグラフィック表示されるため、テンプレート・ユーザーがテンプレート・アセットでページをレイアウトしたり、コンテンツをレンダリングする方法を決定する際に役立ちます。作成したサムネイルは、テンプレートの「調査」フォームに表示されます。

テンプレート・アセットが保存されると、サムネイル・ファイルの名前がTemplate_Thumb表のurlthumbnail列に書き込まれます。

サムネイルを作成するには

1. テンプレート・アセットをプレビューします。手順は、第23.7.5.2項「CSElementアセットとSiteEntryアセットおよびプレビュー」を参照してください。

2. プレビューをイメージ・ファイルとして取得して、ファイル・システムに保存します。

3. 「テンプレート」フォームを開いて、画面上部の「サムネイル」をクリックします。

4. 「サムネイル・イメージ」フィールドに、手順2で作成したイメージ・ファイルへのパスを入力(または参照)します。

5. サムネイルを「調査」フォームに表示するには、次の手順を実行します。

1. テンプレートを保存します(「保存」アイコンをクリックします)。
イメージ・ファイルがWebCenter Sitesデータベースにアップロードされ、テンプレートの「調査」フォームが表示されます。

2. 「調査」フォームで、「サムネイル・イメージ」セクションが現れるまで下へスクロールします。表示されたイメージが大きすぎたり小さすぎる場合は、ソース・ファイルでイメージをサイズ変更して、手順4と5を再実行します。

6. イメージを「サムネイル」画面で操作するには、次の手順を実行します。

1. 「調査」フォームの上部にスクロールして、「編集」リンクをクリックします。

2. 「テンプレート」フォームの上部で、「サムネイル」をクリックします。

7. サムネイル上でコピー、送信、その他の操作を実行するには、サムネイルを右クリックしてオプションを選択します。

8. サムネイルを削除する場合は、「サムネイル・イメージを削除しますか。」を選択して、「変更の保存」をクリックします。
WebCenter Sitesにより、テンプレートの「調査」フォームが表示されます。

23.4.2.7 手順7: テンプレートの調査

テンプレート・アセットの作成を終了して、「保存」をクリックすると、WebCenter Sitesは次の操作を行います。

- データベース表に書き込みます。

- Template表にテンプレート・エントリを作成します。

- AssetTypeName/TemplateNameネーミング規則を使用して、ElementCatalog表にエレメント・エントリを作成します。エレメントが(Sites Explorerではなく)テンプレート・フォームにコーディングされた場合は、エレメント・ファイルも作成されます。

- テンプレートが属するサイトの名前を判断し、SiteName/AssetTypeName/TemplateNameネーミング規則を使用してSiteCatalog表にページ・エントリを作成します。

- 新しいSiteCatalogページ・エントリのルート・エレメントの名前をElementCatalogエントリの名前に設定します。

- サムネイル・エントリをTemplate_Thumb表に作成します。

- マップ・エントリをTemplate_Map表に作成します。

- 「調査」フォーム(図23-5)を表示します。このフォームには、次の種類の情報が表示されます。

- 「名前」画面の情報(すべてのタイプのアセットに関するアセット名、説明、ステータス、ソース、IDなどの標準的な概要情報)。

- 「エレメント」画面の情報(ルート・エレメント、エレメント・ロジック、エレメント・ファイルへのパス、およびtid)。

- 「SiteEntry」画面の情報(SiteCatalogページ名、ページレット・パラメータ、キャッシュ基準、およびこのページを表示する権限を持つユーザーのACL)。

- 「サムネイル」画面の情報(サムネイル・イメージが選択されている場合はそのイメージ)。

- 「マップ」画面の情報(サイトがレプリケート可能、またはテンプレートが共有可能である場合は、キー-値-アセット情報のマップ)。

- テンプレート・アセットを共有している場合、「調査」フォームには、このテンプレート・アセットに対するSiteCatalogの追加ページ・エントリがすべて一覧表示されます(テンプレートを共有するサイトごとに1つのページ・エントリが存在します)。

図23-2 テンプレート・アセット: サンプル「調査」フォーム

23.5 CSElementアセットの作成

CSElementアセットの作成時には、アセットの作成、アセットに対するエレメントのコーディング、およびキー-値-アセット情報マップ(テンプレート・アセットのマップと同様)の構成という3つの操作を行います。

CSElementアセットを作成するには、まず、第23.5.1項「前提条件」」を完了して、CSElementの保存後には変更できない(または、変更してはいけない) CSElementプロパティの設定方法と、CSElementのエレメント・ロジックのコーディング方法を決定する必要があります。その後で、WebCenter Sitesインタフェースを使用して次の手順を実行します。

- 手順1: 「CSElement」フォームを開く

- 手順2: CSElementアセットの名前付けと記述

- 手順3: エレメントの構成(ファイル・タイプとロジックの指定。)

- 手順4: マップの構成(CSElement共有とサイト・レプリケーションのサポートが必要な場合。)

- 手順5: CSElementの保存と調査

- 手順6: ブックマークへのCSElementの追加(CSElementをSiteEntryアセットのルート・エレメントとして使用する場合。第23.6項「SiteEntryアセットの作成」を参照。)

「CSElement」フォームに入力する情報は、次の手順で示すように、CSElementアセットの保存時にデータベース表に書き込まれます。

注意:

CSElementアセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。そのかわりに、「CSElement」フォームと、この項に示した手順を使用して、CSElementアセットを作成します。CSElementロジックのコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

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

- 第23.5.1項「前提条件」

- 第23.5.2項「CSElementアセットの作成手順」

23.5.1 前提条件

CSElementアセットの作成を開始する前に、次のいつくかの点を決定してください。

- CSElementアセットの名前。

- CSElementを共有可能にするかどうか、またサイトのレプリケートを可能にするかどうか。これらの考慮事項により、CSElementのエレメント・ロジックのコーディング方法を決定します。

- CSElementのエレメント・ロジックのコーディングを、「CSElement」フォームではなくSite Explorerで実行するかどうか。この方法は、第23.8項「Oracle WebCenter Sites Explorerの使用によるエレメント・ロジックの作成と編集」で概説している理由によりお薦めできません。

23.5.1.1 CSElementの名前付け

- CSElementアセットが保存されると、その名前は変更できなくなります。

- CSElementロジック・ファイルは、CSElementの名前を採用します(次のファイル拡張子が続きます)。

CSElementName.xml_or_jsp_or_html

CSElementロジック・ファイルの名前は変更しないでください。

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

CSElementを作成する前に、CSElementの共有と使用中のサイトのレプリケートが必要かどうかを決定します。必要な場合、CSElementロジックは同じ方法でコーディングされます。共有とレプリケーションが必要でない場合は、キー-値のマッピングを省略してください(第23.5.2.4項「手順4: マップの構成」を参照)。

CSElement共有とサイト・レプリケーションをサポートするエレメント・ロジックのコーディングの詳細は、第23.4.1.3項「テンプレート共有とサイト・レプリケーション」を参照してください。この情報は、例外なくCSElementアセットに適用できます。

23.5.2 CSElementアセットの作成手順

この項では、WebCenter Sitesインタフェースを使用したCSElementアセットの作成方法を示します。

注意:

この項の手順を開始する前に、第23.5.1項「前提条件」を参照して、CSElementアセットの作成についての情報を確認してください。

23.5.2.1 手順1: 「CSElement」フォームを開く

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. ボタン・バーで、「新規」をクリックします。

5. アセット・タイプのリストで、「新規CSElement」を選択します。

注意:

「新規CSElement」オプションを表示するには、サイトに対してCSElementアセット・タイプを有効化し、そのスタート・メニュー・アイテムを作成する必要があります。

6. 「CSElement」フォームが表示されます。第23.5.2.2項「手順2: CSElementアセットの名前付けと記述」に進みます。

注意:

「CSElement」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているCSElementアセットがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。第23.5.2.2項「手順2: CSElementアセットの名前付けと記述」に進みます。

23.5.2.2 手順2: CSElementアセットの名前付けと記述

「名前」画面は、CSElementに関するメタデータの定義に使用します。このメタデータにより、開発者はCSElementの動作と、CSElementが機能の実行に使用する引数を識別できます。

注意:

CSElementの作成中はいつでもCSElementを保存できます。WebCenter Sitesにより、CSElementの「調査」フォームが表示されます。「CSElement」フォームに戻るには、「編集」リンクをクリックします。

CSElementの名前付けと記述を行うには:

1. 「名前」画面で、この項の説明に従って各フィールドに値を入力します。

2. (必須)。「名前」フィールドに、CSElementアセットの説明的な一意の名前を入力します。CSElementの動作を説明する名前を使用するのが最適です。

有効なエントリ:

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)

注意:

CSElementアセットの名前は、第23.6.1項「前提条件」のガイドラインを使用して決定してください。

1. 「説明」フィールドに、CSElementアセットの簡単な説明を入力します。128個までの文字を入力できます。

2. 「適切な引数」フィールドで、次の手順を実行します。

1. CSElementに渡される可能性のある引数を入力して、「引数の追加」をクリックします。

2. 表示されたフィールドで、次の手順を実行します。

- 引数がオプションか、または必須かを指定します。

- 引数の説明を提供します(作成する引数の目的を把握しやすいようにするため)。

- 引数に対して適切な値(説明を含む)を指定します。

(「引数の追加」ボタンと「適切な値の追加」ボタンをクリックすることで、必要な数の引数と適切な値を指定できます。)

3. 「続行」をクリックして、その次の画面「エレメント」を開きます。

23.5.2.3 手順3: エレメントの構成

「エレメント」画面(手順1)は、CSElementのエレメントの作成、エレメント・ファイル・タイプ(XML、JSP、またはHTML)の定義、エレメント・ロジックの提供、およびエレメントの名前付けに使用します。例:

- 「エレメントの作成」フィールドにはエレメント・ロジック用に選択可能なファイル・タイプのXML、JSP、またはHTMLが表示されます。このフィールドは、「エレメント・ロジック」フィールドに標準スタブ・コード(作成するすべてのエレメントに含める必要がある)をシードする際に使用します。

- 「エレメントの作成」フィールドを使用して、たとえば.jspファイルを作成すると、WebCenter Sitesは、デフォルトでJSPのtaglib文とrender.logdepタグを「エレメント・ロジック」フィールドに追加して、このCSElementアセットと、このエレメントからレンダリングされるページ間の構成の依存性をログ記録できるようにします。その他のファイル・タイプの場合は、それぞれのファイル・タイプに固有のコードが追加されます。独自のコードを「エレメント・ロジック」フィールドに追加します。
依存性の詳細は、第28.1項「依存性について」を参照してください。エレメント・ロジックのコーディングについては、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

- 「エレメントのストレージ・パス/ファイル名」フィールドでは、エレメント・ロジックを保持するファイルの名前を付けて、そのファイルへのパスを指定します。

CSElementアセットが保存されると、「エレメント」画面のフィールド値は、次の手順で示すように、ElementCatalog表の(エレメントを表す)行に書き込まれます。

注意:

既存エレメントの選択

次の手順では、CSElementアセットのエレメントを新規作成しているものとします。ただし、旧リリースのWebCenter Sitesからアセットを移行していて、既存エレメントを再使用する場合は、WebCenter Sitesで既存エレメントを検出し、このCSElementアセットと関連付けられるようにするために、エレメントを正確に識別する必要があります。

既存のエレメントを選択するには:

- (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。

- 「エレメントのストレージ・パス/ファイル名」フィールドに、第23.5.1.1項「CSElementの名前付け」の規則に従った値を入力します。

- サイト・デザインで必要な場合は、各エレメント・パラメータ・フィールドに適切な引数を入力します。この手順については、手順1を参照してください。

- CSElementアセットを保存し、再度開きます。

WebCenter Sitesは、正しい名前のエレメントの存在をチェックします。

エレメントに適切な名前が付けられていると、WebCenter Sitesはエレメントを認識して、そのコードを「エレメント・ロジック」フィールドに表示します。

指定されたエレメントが存在しない場合(または、名前が不適切な場合)は、何も行われません。CSElementアセットを調査または編集するときに、フォームにルート・エレメントがありませんというメッセージが表示されます。エレメントをコーディングして適切な名前を付けるとただちに検出され、CSElementアセットに関連付けられます。

新しいエレメントを構成するには:

1. 「エレメント」画面で、この項の説明に従って各フィールドに値を入力します。

2. 「エレメントを作成しますか。」フィールドで、次のいずれかを実行します。

- .xmlファイルを作成する場合は、「XML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelXML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .jspファイルを作成する場合は、「JSP」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelJSP.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

- .htmlファイルを作成する場合は、「HTML」をクリックします。貼り付けられるコードはOpenMarket\Xcelerate\AssetType\CSElement\modelHTML.xmlエレメントから派生し、カスタム・デフォルト・ロジックを使用するように変更できます。

次のフィールドが移入されます。

- 「エレメントのストレージ・パス/ファイル名」フィールド。このフィールドの値は変更しないでください。
このフィールドには、エレメント・ファイルへのパスが先行するエレメント・ファイル名が表示されます。デフォルトでは、このファイルはCSElementアセットの名前(手順2で入力したもの)を採用し、その後に次のファイル拡張子が続きます。

CSElementName.xml_or_jsp_or_html

CSElementアセットを保存すると、このフィールドの値がElementCatalog表のurl列のエレメントを表す行に書き込まれます。

- ヘッダーとその他の情報を持つ「エレメント・ロジック」フィールド。
たとえば、「JSP」ボタンをクリックすると、共通する複数のWebCenter SitesのJSPタグ・ライブラリ(asset、siteplan、render)に対して1つのタグ・ライブラリ・ディレクティブが設定されます。また、WebCenter Sitesは、cs:ftcsの開始タグと終了タグも設定し、CSElementアセットとエレメントによりレンダリングされるページまたはページレット間の構成の依存性をマークするために、RENDER.LOGDEP (render:logdep)タグを設定します。

3. 「Rootelement」フィールドには、エレメント・ファイルの名前(CSElementName.xml_or_jsp_or_html)が事前移入されています。このフィールドの値は変更しないでください。
ルート・エレメントは、この名前でElementCatalog表にリストされます。このエレメント(RENDER.CALLELEMENT)をコールするコードを作成する場合は、この名前を使用してください。これは、デフォルトでは、CSElementアセットの名前を使用しています。

4. (オプション)。「ElementCatalogの説明」フィールドに、エレメントの説明を入力します。
CSElementアセットを保存すると、このフィールドの情報はElementCatalog表のエレメント・エントリに対するdescription列に書き込まれます。

5. (必須)。「エレメント・ロジック」フィールドに、エレメントをコーディングします。cs:ftcs終了タグの前に、すべてのコードを入力する必要があります。
JSPを使用している場合は、使用中のタグ・ファミリを記述するtaglibディレクティブからコメントを削除します。

この手順については、第28章「テンプレートおよびCSElementのエレメントのコーディング」を参照してください。

注意:

テンプレート共有またはレプリケート可能サイトの確保
CSElementを共有したり、現在のサイトをレプリケート可能にする場合は、CSElementのエレメント・ロジックがアセット、アセット・タイプ、属性名またはテンプレート名を直接参照しないようにしてください。そのかわりに、第23.4.1.3項「テンプレート共有とサイト・レプリケーション」で説明するように、render:lookupタグと所定のキーを使用します。第23.5.2.4項「手順4: マップの構成」では、エレメント・ロジックで使用するためにアクセスする必要のあるアセット情報にキーをマップします。

テンプレートのコール
テンプレートは常にrender:calltemplateタグでコールするようにしてください。render:callelementタグまたはrender:satellitepageは絶対に使用しないでください。

6. (オプション)。「エレメント・パラメータ」フィールドと「追加エレメント・パラメータ」フィールドは、エレメントに渡される可能性のある変数または引数を入力するために使用します(それらの変数や引数がサイト・デザインで必要になる場合)。

- 「エレメント・パラメータ」フィールド。このフィールドには、WebCenter SitesによりCSElementアセットの一意のIDとして生成されたCSElement ID (eid)が移入されています。この値を変更または削除しないでください。
このフィールドは、ElementCatalog表のresdetails1列に相当します。CSElementを保存すると、CSElement IDは、CSElementを表す行のresdetails1列に書き込まれます。

- 「追加エレメント・パラメータ」フィールド。WebCenter Sitesでは、このフィールドは空白のままになります。
このフィールドは、ElementCatalog表のresdetails2列に相当します。

サイト・デザインにより、eidに加えて変数を使用する必要がある場合は、その変数を前述のフィールドのいずれか1つに入力します。これは、name=valueのペアとして入力します。複数の引数は、アンパサンド(&)文字で区切ります。例:

MyArgument=value1&YourArgument=value2

各フィールドは255個までの文字をサポートします。

WebCenter Sitesの変数と、その範囲および優先順位の詳細は、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

7. 「続行」をクリックして、その次の画面「マップ」を開きます。

23.5.2.4 手順4: マップの構成

マッピングの目的は、サイト・レプリケーションとCSElementアセットの共有を有効化することです。マッピングの基本コンセプトは、テンプレート・アセットの場合とまったく同じです。これについては、第23.4.1.3項「テンプレート共有とサイト・レプリケーション」で説明しています。

注意:

レプリケート不能のサイト、または共有されないCSElementアセットを設計している場合は、この項をスキップしてください。

「マップ」画面を使用して、次の操作を行います。

- エレメント・ロジックのrender:lookupタグにある各キーを、エレメント・ロジックで使用する必要のある値にマップします。

- 各キーの値を、エレメント・ロジックで使用する必要のある情報(アセット、アセット・タイプ、属性名、またはテンプレート名)にマップします。

CSElementアセットが保存されると、マップがCSElement_Map表に書き込まれます。

マップを構成するには:

1. 「マップ」フォームで、この項の説明に従って各フィールドに値を入力します。

2. 「キー」フィールドは、エレメント・ロジックが検索する値を表します。このフィールドに、エレメント・ロジックのrender:lookupタグで指定したキーを入力します。

3. 「タイプ」フィールドでは、アクセス対象のアセット情報のタイプを特定します。次のいずれかのオプションを選択します。

- テンプレート名: テンプレート名をキー値にマップします(この値は、次の手順で「値」フィールドに指定します)。アクセスされる情報は、次の手順で指定する値に一致するテンプレート名です。(例は、図23-1を参照してください。)

- アセット・タイプ: アセット・タイプをキー値にマップします。アクセス対象の情報はアセット・タイプであり、次の手順で指定する値と同等です。

- アセット(タイプ: 名前): 属性タイプ:名前をキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

- アセット(タイプ: ID): 属性のタイプ:IDをキー値にマップします。アクセス対象の情報は、そのタイプと名前が次の手順で指定する値と一致するアセットです。

図23-3 CSElementアセット: サンプル・マップ

4. 「値」フィールドに、キーの値を入力します。この値は、CSElementアセットの起動時にエレメント・ロジックにより検索されます。

5. 「サイトID」フィールドで、マッピングを適用するサイトの名前を選択します。

6. キーを追加するには、「さらに追加」をクリックして、この項の手順を繰り返します。

23.5.2.5 手順5: CSElementの保存と調査

CSElementアセットの作成が完了したら、「保存」をクリックします。

WebCenter Sitesでは、次の操作が実行されます。

- データベース表に書き込みます。

- CSElementアセットの行をCSElement表に作成します。この行には、前述の手順で指定したCSElementの名前と説明が入力されます。

- 「エレメント」画面で指定した値を使用して、エレメント・エントリをElementCatalog表に作成します。

1. 「Rootelement」フィールドの値は、エレメント・ファイルの適切なフォルダへの配置に使用します。

2. 「エレメントのストレージ・パス/ファイル名」フィールドの値はurl列に書き込まれます。

3. eid変数の値は、resdetails1列のCSElementアセットのIDに設定されます。

- このエレメントをコールする任意のページレットのページキャッシュをフラッシュします。

- 「調査」フォーム(図23-5)を表示します。このフォームには、次の種類の情報が表示されます。

- 「名前」画面の情報(すべてのタイプのアセットに関するアセット名、説明、ステータス、IDなどの標準的な概要情報)。

- 「エレメント」画面の情報(ルート・エレメント、エレメント・ロジック、エレメント・ファイルへのパス、およびエレメントのeid)。

- 「マップ」画面の情報(サイトがレプリケート可能、またはテンプレートが共有可能である場合は、キー-値-アセット情報のマップ)。

- 「引数を使用したプレビュー」ボタンをクリックすると、SiteEntryアセットによってレンダリングされたページをプレビューできます。

23.5.2.6 手順6: ブックマークへのCSElementの追加

注意:

CSElementを使用してSiteEntryアセットを作成する場合は、この項の手順を実行してください。この手順では、CSElementをブックマークに追加することで、そのCSElementをWebCenter Sitesのツリーで選択できるようにします。

このセッションでSiteEntryアセットを作成する予定ではなくても、CSElementをブックマークに追加しておくと、検索が容易になります。

CSElementをブックマークに追加するには:

1. 作成したCSElementアセット上で検索を実行します。

2. 結果リストで、右側の列にあるチェック・ボックスを選択して、CSElementを「ブックマーク」に追加します。
このCSElementは、WebCenter Sitesのツリーの「ブックマーク」タブに一覧表示されます。このタブでは、そのCSElementはSiteEntryアセットに対して選択可能なオプションになります。

3. SiteEntryアセットを作成します。手順は、第23.6項「SiteEntryアセットの作成」を参照してください。

図23-4 CSElementアセット: サンプル「調査」フォーム

「図23-4 CSElementアセット: サンプル「調査」フォーム」の説明

23.6 SiteEntryアセットの作成

SiteEntryアセットを作成するときには、アセットとページ・エントリの両方をSiteCatalog表に作成します。SiteEntryフォームの最初の部分のフィールドでは、ページ・エントリをアセットとして定義します。その他のフィールドでは、WebCenter Sitesページとしてのページ・エントリに関する情報を指定します。この情報はSiteCatalog表に書き込まれます。

SiteEntryアセットを作成するには、最初に第23.5.1項「前提条件」を完了して、そのアセットのルート・エレメントを作成し、SiteEntryプロパティ(SiteEntry名など)の設定方法を決定する必要があります。その後で、WebCenter Sitesインタフェースを使用して次の手順を実行します。

- 第23.6.2.1項「手順1: 「SiteEntry」フォームを開く」

- 第23.6.2.2項「手順2: SiteEntryアセットの作成」

- 第23.6.2.3項「手順3: SiteEntryアセットの保存と調査」

「SiteEntry」フォームに入力する情報は、次の手順で示すように、CSElementアセットの保存時にデータベース表に書き込まれます。

注意:

SiteEntryアセットをデータベース表に直接作成しないでください。直接作成すると複数の表への書込みが必要になり、その結果、依存性の追跡が不正確になる可能性があります。そのかわりに、「SiteEntry」フォームと、この項に示した手順を使用して、SiteEntryアセットを作成します。

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

- 第23.6.1項「前提条件」

- 第23.6.2項「SiteEntryアセットの作成手順」

23.6.1 前提条件

SiteEntryアセットの作成を開始する前に、次の手順を実行してください。

- ページ・エントリのルート・エレメントを次のように作成します。

1. CSElementアセットを作成します。手順は、第23.5項「CSElementアセットの作成」を参照してください。
(ルート・エレメントは、どのページ・エントリにも必要です。ルート・エレメントは、SiteEntryアセットに対して選択するCSElementのエレメントです。)

2. CSElementを使用可能にします。手順は、第23.5.2.6項「手順6: ブックマークへのCSElementの追加」を参照してください。
(SiteEntryアセットに対してCSElementを指定するには、WebCenter Sitesのツリー内にある「ブックマーク」タブからCSElementを選択するか、現在のセッションでCSElementを作成した場合は「履歴」タブからCSElementを選択します)。

- SiteEntryアセットの名前を決定します。同じ名前がページに割り当てられます。SiteEntryアセットを保存した後は、SiteEntry名とページ名を変更できません。

23.6.2 SiteEntryアセットの作成手順

この項では、WebCenter Sitesインタフェースを使用したSiteEntryアセットの作成方法を示します。

注意:

この項の手順を開始する前に、第23.6.1項「前提条件」を参照して、SiteEntryアセットの作成についての情報を確認してください。

23.6.2.1 手順1: 「SiteEntry」フォームを開く

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. ボタン・バーで、「新規」をクリックします。

5. アセット・タイプのリストで、「新規SiteEntry」を選択します。

注意:

「新規SiteEntry」オプションを表示するには、サイトに対してSiteEntryアセット・タイプを有効化し、そのスタート・メニュー・アイテムを作成する必要があります。

6. 「SiteEntry」フォームが表示されます。第23.5.2.2項「手順2: CSElementアセットの名前付けと記述」に進みます。

注意:

「SiteEntry」フォームではなく、「割当て先の選択」画面が表示された場合は、作成しようとしているSiteEntryがワークフローに関連付けられていることを意味します。「ユーザー」列から名前を選択して、「割当て先の設定」をクリックします。第23.5.2.2項「手順2: CSElementアセットの名前付けと記述」に進みます。

23.6.2.2 手順2: SiteEntryアセットの作成

1. 「SiteEntry」フォームで、この項の説明に従って各フィールドに値を入力します。

2. (必須)。「名前」フィールドに、SiteEntryアセットの説明的な名前を入力します。ページの目的を説明する名前を使用するのが最適です。
有効なエントリ:

- 最大64個の英数字(先頭は文字にする必要があります)

- アンダースコア(_)

- ハイフン(-)

- 空白(テンプレートのSiteCatalogページ名で使用されるときに、アンダースコアに変換されます)。

3. 「説明」フィールドに、SiteEntryアセットの簡単な説明を入力します。128個までの文字を入力できます。

4. (必須)。「Pagename」フィールドをクリックすると、ページ・エントリの名前とページ・エントリへのパス(例: FSIICommon/SideNav/ProductView)が自動的に移入されます。このフィールドの値は変更しないでください。

注意:

このフィールドの値はページ・エントリの名前です(これは、SiteEntryの保存時にSiteCatalog表に格納されます)。このSiteEntryアセット(RENDER.SATELLITEPAGE)をコールするコードを作成する場合は、この名前を使用することをお薦めします。

5. SiteCatalog表にある既存のページ・エントリの行を使用する場合は、「このページ名の既存のSiteCatalogエントリにマッピングします。」チェック・ボックスを選択します。

6. (必須)。「Rootelement」フィールドで、ツリーから適切なCSElementアセットを選択して、「選択したアイテムの追加」をクリックします。

注意:

追加できるCSElementは1つのみです。

7. 「ラッパー・ページ」フィールドでオプションの1つを選択して、作成中のアセットがラッパー・ページであるかどうかを指定します。「いいえ」オプションを選択すると、「ページレットのみ」フィールドが表示されます。

8. 「ページレットのみ」フィールドが表示された場合は、オプションの1つを選択して、作成中のアセットがページレットであるかどうかを指定します。

9. 「ページレット・パラメータ」セクションでは、ページまたはページレットが実行されるたびにページまたはページレットに渡されるページレット・パラメータ(名前と値のペア)を入力します。(「ページレット・パラメータ」セクションでは、合計510文字をサポートしています)。

注意:

「ページレット・パラメータ」セクションには、デフォルトのパラメータsite, seid, sitepfx, rendermode(デフォルトでは、「キャッシュ基準」フィールド(次の手順)で指定される予約変数)が、それらの値を含めて事前に移入されています。

デフォルト値は、ページまたはページレットがコールされたときに明示的に指定された場合は、上書きされます。

- この手順でページレット・パラメータを指定する場合は、次の手順で必ずその名前をキャッシュ基準変数として一覧表示してください。

SiteEntryアセットが保存されると、ページレット・パラメータとして指定した名前と値のペアは、SiteCatalog表のresargs1列またはresargs2列のいずれかに書き込まれます。書込み先の列は重要ではないため、自動的に管理されます。(各列では、最大255文字をサポートしています。)

10. 「キャッシュ基準」フィールドで、次の手順を実行します。

1. WebCenter Sitesでは、次の予約変数がキャッシュ基準として指定されています。

rendermode,seid,site,sitepfx,ft_ss

注意:

予約されたキャッシュ基準変数は、削除しないでください。予約変数の詳細は、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

11. 独自の変数をキャッシュ基準として含める必要がある場合は(たとえば、foo)、その変数を既存のリストに追加します。次に例を示します。

foo,rendermode,seid,site,sitepfx,ft_ss

注意:

「キャッシュ基準」フィールドでは、「Pagename」と組み合せてページレットを一意に定義する変数を指定します。変数は、キャッシュされたページの識別に使用されます。つまり、変数はページのキャッシュ・キーで使用されることになります。

キャッシュ基準として指定された変数のみが、キャッシュされたページのキャッシュ・キーを作成するためにキャッシング・システムで使用されます。したがって、サイト・デザインにより、予約変数に加えてページ・レベルの変数を使用する必要がある場合は、この手順で示すように、必ずこれらの変数をキャッシュ基準変数として指定してください。

SiteEntryアセットが保存されると、キャッシュ基準の変数とその値がSiteCatalog表のpagecriteria列に書き込まれます。

12. 「キャッシュ規則」フィールドは、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はキャッシュを適切にフラッシュできなくなり、無効なページがキャッシュから使用される場合があります。上級ユーザーのみが、これらの設定を手動で構成することをお薦めします。

ページ・キャッシュ設定の詳細は、第5章「ページのデザインとキャッシング」を参照してください。

13. 「アクセス制御リスト」フィールドは、SiteCatalog表のacl列に相当します。特定の訪問者のみがこのページをリクエストできるようにする場合は、ページを表示するために訪問者が必要とするACLを入力します。ACLの詳細は、第31章「配信システムにおけるユーザー管理」を参照してください。

23.6.2.3 手順3: SiteEntryアセットの保存と調査

SiteEntryアセットの作成が完了したら、「保存」をクリックします。WebCenter Sitesでは、次の操作が実行されます。

- データベース表に書き込みます。

- SiteEntryアセットに対する行をSiteCatalog表に作成します。この行には、前述の手順で指定した値が入力されます。

- 「調査」フォームを表示します。このフォームには、次の情報が表示されます。

- 標準の概要情報(アセット名、説明、ステータス、ID)と、前述の手順で指定したページ・エントリ基準。

- 「引数を使用したプレビュー」ボタンをクリックすると、SiteEntryアセットによってレンダリングされたページをプレビューできます。

図23-5 アセットの調査

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

この項では、テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの使用に関する追加手順について説明します。この項は、次のトピックで構成されています。

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

- 第23.7.2項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの編集」

- 第23.7.3項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの共有」

- 第23.7.4項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの削除」

- 第23.7.5項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー」

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

ディスクへのエクスポートのパブリッシュ方法を使用するパブリッシュの宛先に対してアセットが承認されると、承認システムはアセットに割り当てられたテンプレートを調査して、その依存性を判別します。

1つ以上のテンプレート(アセットと同じタイプのテキスト専用バージョン、概要バージョン、フル・バージョンなど)を使用してアセットをレンダリングするようにオンライン・サイトを設計する場合は、すべてのテンプレートの承認依存性を代表するセットが含まれているテンプレートを作成し、そのテンプレートをアセット・タイプに対するデフォルトの承認テンプレートとして指定する必要があります。

承認テンプレートの詳細は、第28.1.1.3項「ディスクへのエクスポート用の承認テンプレート」を参照してください。デフォルトの承認テンプレートとして使用できるテンプレートの例については、Fullという記事アセットのBurlington Financialテンプレートを参照してください。

テンプレートがデフォルトの承認テンプレートであると指定するには:

1. 「管理」タブで、「パブリッシュ」→「宛先」→「静的」の順に選択します。

2. 静的宛先の名前で、「デフォルトのテンプレートの設定」を選択します。

3. 「デフォルト・テンプレート」フォームで、「編集」をクリックします。

4. 編集フォームで、アセット・タイプ別にデフォルト・テンプレートを選択します。アセット・タイプのいずれかにサブタイプ機能を使用している場合、そのアセット・タイプのサブタイプ別にデフォルトの承認テンプレートを指定できます。サブタイプの詳細は、第15.2.10項「手順8: (オプション)サブタイプの構成」を参照してください。

5. 終了したら、「保存」をクリックします。

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

テンプレート、CSElement、およびSiteEntryの各アセットを作成すると、SiteCatalog表やElementCatalog表にもエントリが作成されます。これらのエントリの名前はアセットの名前に基づいており、テンプレート・アセットの場合はアセット・タイプと、テンプレートが属するサイトに基づいています。このようなネーミング依存性があるため、テンプレート、CSElement、またはSiteEntryの各アセットの編集時には次の制約が適用されます。

- テンプレート、CSElementまたはSiteEntryの各アセットを保存した後で名前を変更することはできません。

- テンプレートの場合は、テンプレート・アセットの保存後、「アセット・タイプ」フィールドで選択したアセット・タイプは変更できません。

- テンプレートとCSElementの場合、ルート・エレメントの名前は変更できません。

- SiteEntryの場合、ページ・エントリの名前は変更できません。

注意:

テンプレートを指す1つ以上のサイト・エントリを手動で(Sites Explorerを使用して)作成し、そのテンプレートをAdminインタフェースを通して編集した場合、手動で作成されたエントリは自動的に削除されます。

アセットの基本的な編集手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

CSElement、テンプレートまたはSiteEntryの各アセットを共有すると、WebCenter Sitesにより、アセットを共有するサイトごとに1つの行がAssetPublication表に作成されます。

さらに、テンプレート・アセットのみを対象として、WebCenter Sitesは次の操作を行います。

- アセットを共有するサイトごとに、SiteCatalogページ・エントリを新規作成します。ページ・エントリの名前にサイトの名前が使用されます。新規作成されたすべてのページ・エントリは、同じルート・エレメント、テンプレート・エレメントを指します。

注意:

これらのページ・エントリのルート・エレメントを変更しないでください。共有テンプレートのページ・エレメントはすべて、同じルート・エレメントを指す必要があります。

- このルート・エレメントを共有する共有テンプレートのその他のすべてのページ・エントリを、「調査」フォームに一覧表示します。

アセットの基本的な共有手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

注意:

テンプレートとCSElementを共有可能にするには、それぞれのエレメント・ロジックをアセット・タイプ名、属性名、テンプレート名またはIDでハードコード化しないようにしてください。かわりに、render:lookupタグを使用して、render:lookupタグが参照できるマップが作成されているキーをハードコード化して、エレメント・ロジックでの使用にアセット情報を検索できるようにします。

23.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 Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

テンプレート、CSElementおよびSiteEntryの各アセットは他のアセットを書式設定するためのロジックとコードを提供するため、これらのタイプのアセットは、コンテンツ・アセットのプレビューとは別の方法でプレビューします。

23.7.5.1 テンプレートとプレビュー

テンプレートをプレビューするには、アセットをプレビューし、アセットのレンダリングに使用するテンプレートを選択します。WebCenter Sitesはテンプレート内のコードを起動し、アセットをコンテンツとして使用してページをレンダリングします。

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

CSElementアセットとSiteEntryアセットは直接プレビューします。コールされるエレメントに自己完結型コンテキストが含まれている場合、バナーでは変数や引数が期待されません。単に、「プレビュー」アイコンをクリックできます。ただし、レンダリングされたエレメントの結果が渡される値によって異なる場合には、アセットをプレビューするために、その値を「CSElement」フォームまたは「SiteEntry」フォームで設定する必要があります。

たとえば、BurlingtonFinancial/Query/ShowHotTopicsという名前のBurlington Financial CSElementアセットは、p変数の値を期待します。値を受け取らなかった場合、pの値のデフォルト値はHomeページ・アセットのオブジェクトIDになります。Homeページ以外のページ・アセットに対してこのCSElementをプレビューする場合は、そのCSElementアセットに対して、「新規」フォームまたは「編集」フォームの引数フィールドを使用してページ・アセットのIDをp変数の値として渡す必要があります。

CSElementアセットまたはSiteEntryアセットをプレビューする際に引数値を指定するには:

1. アセットを検索して、それを調査します(文字「i」のアイコンをクリックします)。

2. 「調査」フォームの下までスクロールします。「引数を使用したプレビュー」の横の「プレビュー」をクリックします。CSElementアセットに対して次のフォームが表示されます。

3. 引数の値を入力します。各フィールドをダブルクリックして、ドロップダウン・リストから選択する方法で値を選択することもできます。

4. 「プレビュー」をクリックします。

5. このSiteEntryアセットによりレンダリングされたページのプレビューのために表示されるリンクをクリックします。

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

注意:

エレメント・ロジックをSites Explorerから直接作成または編集することはお薦めできません。ただし、直接実行する方が優先される場合は、テンプレート・アセットおよびCSElementアセットの有効性を確認する必要があります。この項の情報をメモして、その中に含まれている指示に従ってください。

WebCenter Sitesインタフェース(「テンプレート」フォームまたは「CSElement」フォーム)でテンプレート(CSElement)アセットを作成および保存すると、Sites Explorerの使用時には実行されない、いくつかの重要な手順が実行されます。

- このインタフェースでは、構成の依存性を設定するスタブ・コードをエレメントにシードし、JSPを使用している場合は、適切なタグ・ライブラリ・ディレクティブにエレメントをドロップします。構成の依存性については、第28.1項「依存性について」で説明します。

- WebCenter Sitesインタフェースでテンプレート(CSElement)を保存すると、次の操作が行われます。

- アセットが変更されたという情報を承認システムが受信するため、アセットの承認ステータスが変更可能になります。

- 最も重要なこととして、CacheManagerサーブレットがキャッシュを更新できます(つまり、WebCenter SitesキャッシュおよびSatellite Serverキャッシュからページとページレットをフラッシュできます)。

Sites ExplorerでCSElementアセットを使用するように指定した場合は、eid変数の値を変更したり、誤って削除しないようにしてください。

WebCenter Sitesインタフェースを使用する実際的な理由は、(テンプレート共有およびサイト・レプリケーションをサポートするために)特にアセット情報をマップしている場合に、WebCenter SitesとSites Explorer間での切替えを回避するためです。マッピングはWebCenter Sitesインタフェース(「テンプレート」フォームの「マップ」画面、および「CSElement」フォームの「マップ」画面)のみでサポートされています。

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

- 第23.8.1項「テンプレートとCSElementの作成」

- 第23.8.2項「テンプレートとCSElementの編集」

23.8.1 テンプレートとCSElementの作成

Sites Explorerによるエレメント・ロジックのコーディングを優先させる場合は、次の手順を実行します。

1. 「テンプレート」フォーム(または「CSElement」フォーム)を使用してテンプレート(またはCSElement)アセットの作成を開始します。第23.4.2.1項「手順1: 「テンプレート」フォームを開く」(または第23.5.2.1項「手順1: 「CSElement」フォームを開く」)から始めて、順番に手順を実行します。

2. 第23.4.2.3項「手順3: テンプレートのエレメントの構成」(または第23.5.2.3項「手順3: エレメントの構成」)で、エレメント・タイプ(JSP、XML、またはHTML)を選択します。自動生成されたエレメント・ロジックは変更しないでください。また、tid変数の値を変更したり、誤って削除しないようにしてください。

3. 選択したフォームを使用して、終了するまで続行します。マップする必要のあるキーとアセット値が判明している場合は、それらを「マップ」フォームに追加します(第23.4.2.5項「手順5: マップの構成」)。同じ手順がCSElementアセットにも適用できます)。

4. アセットを保存します。

5. Sites Explorerを開いて、エレメントを編集します。変更を保存します。

6. 最後の手順では、「テンプレート」フォーム(または「CSElement」フォーム)でアセットを再度保存します。フォームでデータを変更する必要はありませんが、再度保存する必要があります。こうすることで、機能が迂回されなくなります。

23.8.2 テンプレートとCSElementの編集

Sites Explorerツールでエレメントのロジックを編集する場合は、常にテンプレート(またはCSElement)をWebCenter Sitesインタフェースで開いて保存します。これは、(1)アセットが変更されたことを承認システムが認識し、アセットの承認ステータスを変更できるようにするため、および(2) CacheManagerサーブレットがキャッシュを更新できるようにするためです。

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

この章では、Webサイトを実装する際のテンプレートとラッパーの標準的な使用方法について説明します。

この章には次の項が含まれます。

- 第24.1項「テンプレートの使用」

- 第24.2項「ラッパーの使用」

24.1 テンプレートの使用

この項では、3つのタイプのテンプレートの相違点と、実際に実装された場合のそれぞれの使用方法を検討します。

- 第24.1.1項「レイアウト・テンプレート」

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

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

24.1.1 レイアウト・テンプレート

レイアウト・テンプレートは、「使用」フィールドが「エレメントはレイアウトとして使用されます。」に設定されているテンプレート・アセットです。レイアウト・テンプレ－トはタイプ付きまたはタイプなしになります(タイプ付きアセットとタイプなしアセットの詳細は、第23.4項「テンプレート・アセットの作成」を参照)。

レイアウト・テンプレートの3つの主要特性は、次のとおりです。

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

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

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

この項ではそれぞれの特性を詳述し、複数のセクションにわたって使用するユースケース・シナリオを提供して、それぞれの概念を示します。また、「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」する方法も説明しています。

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

レイアウト・テンプレートのページ名が指定されると、Satelliteサーブレットをコールし、コンテンツのアセット・タイプ(c)およびアセットID (cid)と一緒にページ名を渡すことによってWebページが取得され、レンダリングが行われます。

http://localhost:8080/cs/Satellite?pagename=
<template_pagename>&c=Article&cid=1234567

指定されたテンプレートに対応するページ名を検索するには、テンプレート・アセットを調査し、「サイト・エントリ」フィールドのSiteCatalog Pagename列を参照します。次のスクリーン・キャプチャでは、ページ名はavisports/HelloLayoutです。

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

すべてのコンテンツ・アセットにはテンプレート・メタデータがあります。このメタデータは、「コンテンツ」タブを選択して表示できます。このフィールドでは、テンプレート名が格納されます。可能な値として、アセット・タイプやサブタイプに適用可能なすべてのレイアウト・テンプレートがあります。

WebCenter Sitesはどのようにテンプレート・フィールドを使用するのでしょうか。基本的に、ContributorインタフェースのWebモードでアセットを調査または編集する際、WebCenter Sitesは割り当てられたレイアウト・テンプレートをデフォルトのテンプレートとして使用し、アセットをレンダリングします(これは、単にアセットをプレビューするのみの場合でもあります)。つまり、Webモードでアセットを使用する際に使用できるのはレイアウト・テンプレートのみです。プレビューする場合、レイアウト・テンプレートは必要ありません。詳細は、第23.7.5項「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットのプレビュー」を参照してください。

Webモードを使用している場合は、(ツールバーまたはメニューバーから)レイアウト変更機能を使用し、テンプレート・ピッカーを使用してレイアウト・テンプレートをビジュアルに選択することによって、デフォルトのレイアウト・テンプレートを割り当てることもできます。いずれの場合でも、アセットのテンプレート・フィールドの値は変更されます。

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

標準のWebページは、ドキュメント内に区画(通常は次の図に示すように、ヘッダー、フッター、サイド・バーおよびメイン領域)を定義するために<DIV>エレメントを使用して、HTMLコードで作成されます。

ヘッダー、フッター、サイド・バーおよびメイン領域を持つ標準的な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>タグが含まれています。詳細は、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

<%@ 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>タグの詳細は、第4.5項「WebCenter Sitesのタグ」を参照してください。

24.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>

1. 新しいタブで任意の記事アセットを開きます。

2. HelloArticleLayoutテンプレートをアセットに割り当てます。次のようなWebページが表示されます。

コンテナとサイド・バーの<DIV>エレメントに一時的なスタイルをいくつか追加して、これらが表示されるようにしています。実際のコンテンツが含まれたときには、これらを削除します。

1. レイアウト・テンプレートにコードを追加して、実際のコンテンツがレンダリングされるようにします。このコードは、ヘッドライン、投稿日、関連イメージと本文の各フィールドをレンダリングします。属性値の詳細は、第11章「データ・デザイン: アセット・モデル」を参照してください。

<%@ 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>

2. HelloArticleLayoutを使用してContributorインタフェースのWebモードでアセットを表示すると、次に示すような記事詳細を載せたWebページがレンダリングされます。サイド・バーは意図的に空にしてあります。

24.1.2 ページレット・テンプレート

ページレット・テンプレートは「使用」フィールドが「エレメント」に設定されているテンプレート・アセットで、HTMLページ内で使用されます。

ページレット・テンプレートの特性は、次のとおりです。

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

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

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

次の項では、それぞれの特性を詳述し、ユースケース例を引き続き拡張しています。また、「ユースケース2: ページレット・テンプレートの使用」についても説明しています。

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

ページレット・テンプレートにはページ名がありますが、WCS URLを使用してブラウザから直接ページレット・テンプレートにアクセスしようとすると、403 HTTPエラー・コード(アクセス拒否)が表示されます。

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

アセットのテンプレート・フィールドで使用できるのはレイアウト・テンプレートだけです。つまり、ページレット・テンプレートを使用してこれらのアセットを直接プレビューすることはできません。ただし、プレビュー・テンプレートを設定して、編集ユーザーがページレット・テンプレートを簡単にプレビューできる方法を提供することは可能です(詳細は、第24.1.3項「ページ・テンプレート」を参照)。

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

ページ・テンプレートは、Webページ全体ではなく、Webページ・フラグメントをレンダリングします。ページレット・テンプレートで再使用可能なページ・フラグメントをレンダリングすることが理想的です。たとえば、ページレット・テンプレートで次のような記事概要ブロックをレンダリングできます。

その後でレイアウト・テンプレートを使用して複数のページ・フラグメントをアセンブルし、完全なWebページを作成できます。再利用性を最大限に活かすために、ルック・アンド・フィールの観点から中立的なフラグメントをページレット・テンプレートで提供します。その際に、CSSスタイルシート・ルールを使用して見栄えを効果的に制御します(特定のフラグメントをどの位置に使用するかに基づき、明確なスタイルシート・ルールを適用するのみでレンダリングは異なってきます)。

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

これまでの手順については、第24.1.1.4項「ユースケース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>

24.1.3 ページ・テンプレート

ページ・テンプレートは、「使用」フィールドが「エレメントはHTMLページ全体を定義するため、外部から呼び出すことができます。」に設定されているテンプレート・アセットです。

ページ・テンプレートの特性は、次のとおりです。

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

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

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

この項では、それぞれの特性を説明し、ページ・テンプレートの実際の使用方法を示します。

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

レイアウト・テンプレートと同様に、ページ・テンプレートは、Satelliteサーブレットを通してページ名を起動することによって、ブラウザでのWebページのレンダリングに使用できます。

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

レイアウト・テンプレートのみが割当て可能です。つまり、編集ユーザーはContributorインタフェースの「Webモード」でページ・テンプレートを使用できないことになります。したがって、レイアウト・テンプレートを使用する必要があります。

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

編集ユーザーはアセットを表示できるのみであり、編集機能は含まれないという点で、アセットのプレビューはContributorインタフェースでWebモードを使用する場合と異なります。アセットをプレビューする場合、デフォルトでは、WebCenter Sitesはアセットのテンプレート・フィールドに設定されたレイアウト・テンプレートを使用します。

「プレビュー・テンプレートの変更」ダイアログが表示されると、テンプレート・ピッカーは次の有効なオプションを表示します。

- 現在のアセットに適用できるすべてのレイアウト・テンプレート

- 現在のアセットに適用できるすべてのページ・テンプレート

レイアウト変更テンプレート・ピッカーとは異なり、別のプレビュー・テンプレートを選択しても、このテンプレートはアセットのテンプレート・フィールドに割り当てられません。選択されたプレビュー・テンプレートを使用して現在のアセットがレンダリングされるのみです。

24.2 ラッパーの使用

ラッパーは通常、マークアップを一切レンダリングしません。かわりに、ラッパーは通常は未キャッシュであり、実際のレイアウト・テンプレートをレンダリングする前に実行される予定のビジネス・ロジックが含まれています。これは、セキュリティ・チェックの実装のためにセッション・データにアクセスしたり、設定するロケールを決定したり、フレンドリURLを逆アセンブルするといったアクションを実行する場合に役立ちます。

この項では、ラッパーについて次の内容を説明します。

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

- ラッパーとプレビュー

ラッパー・ページの作成

ラッパーは、「ラッパー・ページ」フラグが「はい」に設定されている普通のSiteEntryアセットです。これにより、作成中のアセットがラッパー・ページとして指定されます。「いいえ」フラグを選択すると、「ページレットのみ」フィールドが表示されます。詳細は、第23.6項「SiteEntryアセットの作成」を参照してください。

ラッパーとプレビュー

実装によっては、レイアウト・テンプレートを使用してアセットをレンダリングする前に、ラッパーを実行する必要もあります。アセットをプレビューする場合、またはContributorインタフェースのWebモードを使用している場合、WebCenter Sitesは、現在のサイトで少なくとも1つのラッパーが有効になっている場合に系統的にラッパーを実行します。

デフォルトのプレビュー・ラッパーが現在の編集サイトに対して構成されている場合は、このラッパーが使用されます。そうでない場合は、リストに記載されている最初のラッパーが使用されます。複数のラッパーが使用可能な場合は、「表示」、「ラッパーを使用したプレビュー」を選択して、別のラッパーを変更できます。

プレビュー・モードでは、ラッパーは、レイアウト・テンプレートがWebページを正しくレンダリングするために追加の引数を必要とする場合に(たとえば、locale引数が実行できる場合がある)、特に役立ちます。これは、デフォルトで、WebCenter Sitesが、それぞれテンプレート・ページ名とレンダリング対象のアセットのタイプおよびIDを持つアセット・タイプ(c)とアセットID (cid)を使用して主にページ名を設定する最小限のプレビューURLを生成するためです。

この場合は、必要に応じて追加の引数を設定し、レイアウト・テンプレートのレンダリングを進めることによって、プレビュー・ラッパーを定義できます。コールされるページ名は、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>
...

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

この章では、コンテキスト内編集およびプレゼンテーション編集用のテンプレートのコーディングについて説明します。この章で使用する新しいタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

この章には次の項が含まれます。

- 第25.1項「コンテキスト内コンテンツ編集用テンプレートのコーディング」

- 第25.2項「プレゼンテーション編集用テンプレートのコーディング」

- 第25.3項「Webモードでのコンテンツ作成の有効化」

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

注意:

コンテキスト内とは、WebCenter Sites ContributorインタフェースのWebモードを意味します。

この項では、編集ユーザーが、標準コンテンツ・フォームを使用するかわりに、それぞれのWebサイトのコンテキストでコンテンツの編集または作成を行えるようにテンプレートをインストゥルメント化する方法を検討します。

この項では、第24章「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートに変更を加えます。HelloDetailテンプレートで作成する前出のトピックを参照してください。

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

- 第24.1.2.4項「ユースケース2: ページレット・テンプレートの使用」

注意:

DoctypeおよびInternet Explorer: IEで不適切なモードを使用してページがレンダリングされている場合、コンテキスト内編集UIが完全に機能しないことがあります。ローカル設定によってUIが影響を受けることのないように、ページのレンダリングでは必ず適切なDoctypeを使用するようにしてください。

詳細は、Microsoft Libraryの『HTML/XHTML Reference』(http://msdn.microsoft.com/)にある、DOCTYPEエレメントの説明を参照してください。

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

- 第25.1.1項「属性データ型」

- 第25.1.2項「文字列フィールド」

- 第25.1.3項「テキスト・フィールド」

- 第25.1.4項「日付フィールド」

- 第25.1.5項「バイナリ・フィールド」

- 第25.1.6項「アセット・フィールド」

- 第25.1.7項「数値フィールド」

25.1.1 属性データ型

アセット・タイプは、次のタイプが指定可能な1つ以上の属性により定義されます。

- string: 短い文字列(通常は、最大255文字)

- text: 長い文字列。通常は、CLOBデータベース・タイプにマップされます(最大サイズは基礎データベースにより異なります)。

- date: 日付フィールド

- binary: BLOB属性。通常は、イメージ・ファイル、PDFなどのバイナリ・ファイルの格納を対象としています。

- asset: 別のアセットに対する参照

- number: integer、floatまたはmoneyデータ型

25.1.2 文字列フィールド

この項では、文字列フィールドを編集可能にする方法を検討します。これらのフィールドには長さ制限があり(通常は255文字)、記事ヘッドライン、作成者などのコンテンツ・メタデータの保持に最適です。

この項では、記事ヘッドライン・フィールドを編集可能にするために、第24章「テンプレートとラッパーの作成」で紹介した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. 「ビューの編集」を選択すると、すべての編集可能領域がアクティブになります。この例では、次のスクリーン・キャプチャに示すようにヘッドライン・フィールドが表示されます。

3. 編集ユーザーは記事詳細Webページのコンテキスト内でヘッドライン・フィールドを編集できるようになり、この変更内容は「保存」をクリックすると永続化できます。このアクションは、記事アセット・フォームに移動して、記事のヘッドライン・フィールドを編集し、その後で「保存」をクリックすることと同じです。

25.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属性をサポートします。これらのバリアントはほとんど使用されません。

25.1.3 テキスト・フィールド

この項では、テキスト・フィールドを編集可能にする方法を検討します。この項は、第24章「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートに基づいています。

文字列フィールドと同様に、HelloDetailテンプレートのrender:streamタグをinsite:editタグに置換できます。HelloDetailテンプレートでの文字列フィールドの使用例については、第25.1.2項「文字列フィールド」を参照してください。

前回は、render:streamタグを使用しました。

<render:stream
list="bodyList"
column="value" />

このフィールドを編集可能にするには、render:streamタグをinsite:editタグに変更します。この例では、フィールドとしてbodyを定義し、エディタ・タイプとしてckeditorを定義しています。

<insite:edit
list="bodyList"
column="value"
field="body"
editor="ckeditor" />

本文テキストをクリックすると、このスクリーン・キャプチャに示すようなCKEditorウィジェットが表示されます。

追加の引数を、次のようにCKEditorに渡せることに留意してください。

<insite:edit
list="bodyList"
column="value"
field="body"
editor="ckeditor"
params="{width: '500px', height: '350px',
toolbar: 'MyToolbar'}" />

詳細は、第19.1項「CKEditorの構成」を参照してください。

25.1.4 日付フィールド

この項では、日付フィールドを編集可能にする方法を検討します。この項は、第24章「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートに基づいています。

日付フィールドをコンテキスト内で編集可能にするには、文字列フィールドまたはテキスト・フィールドに使用したものと同じinsite:editタグを使用します。ただし、日付の書式設定が必要になる場合は、いくつかの追加手順が必要になります。最初にデータベースから取得した日付フィールドの値は、JDBC書式(2012-01-01 00:00:00.0)で表示されます。この書式はWebサイトでのレンダリングには不適切です。通常、Webサイトでは、日付はJanuary 1, 2012というような読みやすい文字列でレンダリングされるためです。

さらに、日付はサーバーのタイムゾーンで解釈されます。この日付は、別のタイムゾーンで表示できます。最初に、java.utilのTimeZone APIを使用して、タイムゾーンIDを取得します。その後で、長い日付書式(事前定義された書式)を使用して、日付を書式設定します。

注意:

事前定義された日付書式の詳細は、次を参照してください。

http://docs.oracle.com/javase/tutorial/i18n/format/dateFormat.html

日付を書式設定する場合は、次の項で説明されている、いずれかの日付書式設定APIを使用できます。書式の選択に応じて、日付とカレンダ・ウィジェットは次のいずれかの外観になります。

日付書式設定API

HelloDetailテンプレートでは、日付の表示にformattedDateを使用しています。詳細は、第24.1.1.4項「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」を参照してください。

<span class="date">
<ics:getvar name="formattedDate" />
</span>

formattedDate変数は、日付書式設定APIのfmt:formatDate、または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" />

- 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"/>

Sitesのdateformat APIは、valuetype引数で、millisまたはjdbcをとります。

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'を使用した場合

- タイムスタンプとtimeZoneIDを使用していない場合

3. これで、日付フィールドが編集可能になりました。「Webモード」→「ビューの編集」を選択して、Contributorインタフェースで記事を表示しているときに日付フィールドをクリックすると、次のいずれかのカレンダ・ポップアップ・ウィジェットが表示されます。

日付書式は、params属性を使用してinsite:editタグに渡されます。params属性は、JSON文字列として書式設定された追加の構成設定をDojoウィジェットに渡すために使用します。この場合は、次のようになります。

{constraints: {formatLength: 'long'}, timePicker : true,
timeZoneID:'US/Eastern' }

使用可能なウィジェット設定の詳細は、Dojoドキュメント(http://dojotoolkit.org/)を参照してください。

25.1.5 バイナリ・フィールド

バイナリ・フィールドは通常、データベースのBLOBフィールドまたはCLOBフィールドに相当します。一般に、バイナリ・フィールドにはイメージまたはダウンロード可能なドキュメントが格納されます。デフォルトでは、insite:editタグはファイル・アップロード・コンポーネントを通じてバイナリ・フィールドを編集可能にします。

注意:

この項は、WebCenter SitesのURL列にも当てはまります。つまり、ファイル・システムに格納されているファイルへの参照を格納したURL列です。

HelloDetailテンプレートでは、関連するAVIImageアセットのlargeThumbnailフィールドをレンダリングしています。このフィールドをコンテキスト内で編集可能にするには、最初に、BLOB ID(実際のBLOB値ではありません)が含まれているフィールドの値を取得する必要があります。

<assetset:setasset
name="image"
type="AVIImage"
id='<%=ics.GetVar("imageId")%>' />
<assetset:getattributevalues
name="image"
attribute="largeThumbnail"
typename="ContentAttribute"
listvarname="largeThumbnail" />

<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>

BLOB IDのinsite:editタグへの受渡しは主に、バイナリ・フィールドが空であるかどうかの判別に使用します。空の場合、insite:editタグはデフォルトの空の値インジケータを表示します。

<img>タグは、insite:editタグの中に挿入される唯一のHTMLタグになるようにしてください。<img>タグは、inside:editタグの中に挿入できる唯一のタグです。insite:editタグは、<a>タグ(通常は、ダウンロード可能なドキュメントへのハイパーリンクの作成に使用する)の処理にも対応できます。その他のタイプのバイナリも処理可能ですが、特定のカスタマイズが必要な場合があります。

イメージ上にマウス・ポインタを移動すると、コンテンツ・コントリビュータにツールチップが表示されてアップロード・コンポーネントにアクセス可能になり、largeThumbnailフィールドを消去できます。

注意:

HelloDetailテンプレートでは、コントリビュータは同じページで2つの異なるアセット(AVIArticleアセットのheadline、date、body、relatedImageの各フィールドと、関連するAVIImageアセットのlargeThumbnailフィールド)を編集できます。通常は、同じページに複数のアセットをレンダリングして、それらを同時に編集可能にすることができます。

25.1.6 アセット・フィールド

アセット・フィールドには、他のアセットに対する参照が格納されます。この項では、アセット・フィールドを編集可能にする方法を検討します。

この項は、第24章「テンプレートとラッパーの作成」の第24.1.1.4項「ユースケース1: 記事アセット用にレイアウト・テンプレートを作成」で作成した、HelloArticleLayoutテンプレートに基づいています。

この項では、HelloArticleLayoutテンプレートを拡張し、relatedStoriesフィールドを通じて記事に関連付けられた記事アセットをレンダリングすることでサイド・バーを移入します。

注意:

relatedStoriesは複数値フィールドですが、この項では単一値フィールドとして扱います。つまり、このフィールドには関連記事コンテンツ・アセットが1つだけ保持されると考えます。したがって、この項に示すコード・サンプルは、すべての単一値フィールドに適用できます。複数値フィールドの扱い方の詳細は、第25.1.8項「複数値フィールド」を参照してください。

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つのアセット参照(この例では、Cold Snap Back on the Scene)が含まれているとすると、関連記事は、テンプレート・コードで指示されたように、Summary/SideBarテンプレートを使用してサイド・バーにレンダリングされます。

前回は、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. これで、コンテンツ・ツリーで、またはドッキングされた検索パネルからアセットを選択することによって、記事アセットをコンテンツ編集可能なスロットにドラッグ・アンド・ドロップできるようになりました。

25.1.6.1 アソシエーションの編集

データ型assetのフレックス属性のかわりにアセット・アソシエーションを使用する場合は、field属性を次のように指定する必要があります。

Association-named:<associationName>

たとえば、topStoryというアソシエーションの場合、コードは次のようになります。

<insite:calltemplate
field="Association-named:topStory"
...
/>

25.1.6.2 親アセットの編集

フレックス・アセットの親アセットの編集も可能です。field属性の構文は次のようになります。

Group_<parentDefinitionName>

たとえば、avisportsの場合、記事アセットにはCategory親定義が割り当てられます。

<insite:calltemplate
field="Group_Category"
...
/>

25.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/)を参照してください。

25.1.8 複数値フィールド

前出の例はすべて、単一値フィールドを対象としたものです。既存値の編集だけでなく複数値フィールドを扱う場合、エディタは次のような機能も利用できる必要があります。

- 新しい値の追加

- 既存値の削除

- 既存値の記録

このため、複数値フィールドは特別に扱う必要があります。この項では、複数値テキスト・フィールドと複数値アセット・フィールドの使用法について説明します。

25.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>

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属性を追加したことのみです。

この時点では、既存値の編集のみ実行可能です。既存値の追加、削除、並替えの方法については、次の項を参照してください。

25.1.8.2 例2: 複数値テキスト・フィールド

この項は、この章の第25.1.8.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を編集し、続いて順次に編集すると想定します。そうでない場合は、索引を指定する必要があります。詳細は、第25.1.8.3項「異なる順序の指定」を参照してください。

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>

1. insite:listタグを追加したため、フィールド値の表示領域にユーザーがマウス・ポインタを移動するとツールバーが表示されます。

2. その領域をクリックするとポップアップがレンダリングされて、フィールド値の追加、編集、削除または並替えが可能になります。

この項は、第25.1.8.1項「例1: 複数値テキスト・フィールドの編集」と第25.1.8.2項「例2: 複数値テキスト・フィールド」に基づいています。

アセット参照フィールドの場合は、insite:listタグのかわりにinsite:slotlistタグを使用します。この場合は、insite:editタグをネストするのではなく、ネストされたinsite:calltemplateタグを使用することになります。

この例では、関連記事を1つレンダリングするかわりに、リスト全体を調べて記事を個別にレンダリングします。

前出のコード・サンプルを次のように変更します(当面、このコードではコンテキスト内編集機能をすべて除外します)。

<%@ 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>

次のスクリーン・キャプチャは、3つの値を持つフィールドを表示しています。

SideBarには、次の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"%>
<%@ 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領域上にマウス・ポインタを移動すると、前述の例と同じようなツールバーが表示されます。

25.1.8.3 異なる順序の指定

前述の例では、最初にネストされたinsite:calltemplateタグで記事#1がレンダリングされ、2番目のinsite:calltemplateタグで記事#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では順序を意識する必要があります。

そのためには、第25.1.8項「複数値フィールド」で示したように、index属性を使用して、編集中のリスト・アイテムの索引を明示的に指定する必要があります。

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

「Webモード」→「ビューの編集」で作業している場合、キャッシングは無効化されません。したがって、キャッシングできるように構成されたテンプレートは、「ビューの編集」でのレンダリング時にもキャッシングされます。

アセットを使用している場合、WebCenter Sitesは、適切な依存性がログ記録されていることを条件として、キャッシュ・フラッシュを自動的に処理します。たとえば、特定の属性の定義を変更すると(アセット参照フィールドで許可されるタイプの変更など)、その特定の属性にレンダリングが依存しているすべてのページレットが自動的にフラッシュされます。

ただし、次のように、ページ・キャッシュの手動でのフラッシュが必要になる場合もあります。

- アソシエーション・フィールドの定義を変更する。

- ロールがroles属性を通じてinsite:calltemplateタグから直接参照される場合、このロールをWebCenter Sitesから削除する。

- アセット・タイプまたはサブタイプがclegal属性を通じてinsite:calltemplateタグから直接参照される場合、このアセット・タイプまたはサブタイプをWebCenter Sitesから削除する。

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

この項では、コンテキスト内UIのその他の側面について検討し、技術者以外のユーザーがコンテンツのプレゼンテーションを管理できるようにするためのテンプレートのコーディング方法を説明します。また、コンテキストに関する情報と、プレゼンテーションの変更をローカルにする(指定されたWebページのみで表示可能にする)、またはグローバルにする(1つのページでのプレゼンテーションの変更をサイト上の複数のページに反映させる)方法に関する情報について説明します。

プレゼンテーションの管理には、Webページ全体のレンダリングに必要なページ・レイアウトの選択機能、Webページの所定の部分でのアセットのレンダリングに必要なコンテンツ・レイアウトの選択機能、およびページレット・テンプレートに送信される引数の選択機能が含まれます。

この項は、第24章「テンプレートとラッパーの作成」で紹介したHelloDetailテンプレートと、第25.1項「コンテキスト内コンテンツ編集用テンプレートのコーディング」の例に基づいています。

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

- 第25.2.1項「Webページ全体に対する異なるレイアウトの選択」

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

- 第25.2.3項「プレゼンテーションとコンテンツの同時編集」

- 第25.2.4項「コンテキスト・システム変数の理解」

- 第25.2.5項「CSElementアセットとSiteEntryアセットによるスロットの使用」

- 第25.2.6項「アセット・タイプの制約」

- 第25.2.7項「CSSとJavaScriptの競合回避」

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

編集ユーザーは、次のいずれかの方法でレイアウト・テンプレートをアセットに割り当てることができます。

- templateフィールドの値をContributorインタフェースのフォーム・モードで直接変更する。

- または、ツールバーまたはメニュー・バーからレイアウト変更機能を選択する。

アセットに対してレイアウト・テンプレートを選択すると、そのテンプレートは、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" />

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

この項は、第25.1項「コンテキスト内コンテンツ編集用テンプレートのコーディング」で使用したHelloArticleLayoutテンプレートに基づいています。

前回、HelloArticleLayoutレイアウト・テンプレートでは、このコード・スニペットに示すようにHelloDetailテンプレートを使用して、記事ページのメイン領域がレンダリングされました。

<div id="container">
<div class="content">
<render:calltemplate tname="HelloDetail" args="c,cid" />
</div>
<div class="side-bar">
...
</div>
</div>

これは次のようにレンダリングされます(次のスクリーン・キャプチャを参照)。

注意:

コード・スニペットで使用した構文は、次のとおりです。

<render:calltemplate tname="HelloDetail" args="c,cid" />

これは次のコード・スニペットに対するショートカット(これとまったく同じもの)です。

<render:calltemplate
tname="HelloDetail"
c='<%=ics.GetVar("c")%>'
cid='<%=ics.GetVar("cid")%>' />

avisportsサンプル・サイトは、記事アセットに対するDetailテンプレートも提供します。Detailページレット・テンプレートは、HelloDetailテンプレートと機能的に同じです。つまり、記事の詳細ビューを提供し、次のスクリーン・キャプチャに示すように、ページのメイン領域でレンダリングすることになっています。

25.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>
...

スロットを定義するには、insite taglibディレクティブを追加します。

<%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>

さらに、前述の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属性値には任意の文字列を使用できますが、特定のサイトのすべてのテンプレートで一意である必要があります。詳細は、第25.2.4項「コンテキスト・システム変数の理解」を参照してください。

このテンプレートを再実行しても、最初は目立った変化がありません。この例の記事は、tname属性の指示どおりに、HelloDetailテンプレートを使用してレンダリングされています。「ビューの編集」に切り替えてメインdivセクション上にマウス・ポインタを移動すると、変更内容が明らかになります。

- メインdiv内のページ・フラグメントが青のオーバーレイでマークされています。

- スロット名が右上隅に指定されています。

青のオーバーレイをクリックした場合も、(次のスクリーン・キャプチャに示すように)ツールバーが表示されます。

「コンテンツ・レイアウトの変更」オプションを選択すると、別のコンテンツ・レイアウトを選択して、ページのメイン領域にアセットをレンダリングできるようになります。

「コンテンツ・レイアウトの変更」アイコン:

「コンテンツ・レイアウトの変更」ダイアログ:

テンプレート・ピッカーは、variant属性により指定されたHelloDetailページレット・テンプレートとDetailページレット・テンプレートを表示します。Detailテンプレートを選択して「適用」をクリックすると、次のスクリーン・キャプチャに示すようなWebページがレンダリングされます。

前述の例で定義したスロットはプレゼンテーション編集のみを意図したものであり、コンテンツ編集可能スロット(ドロップ可能ゾーン)ではありません。

このように動作する理由は、次のとおりです。

- insite:calltemplateタグはfield属性を定義しません。つまり、スロットのコンテンツはアセット参照フィールドの値ではありません。

- このタグは、c (アセット・タイプ)およびcid (アセットID)に対して明示的に値を指定します。特にこの場合は、受信するcおよびcidリクエスト・パラメータにより指定された記事アセットをこの場所にレンダリングする必要があります。

さらに、variant属性が省略された場合、スロット・レイアウトは編集可能になりません。その理由は、insite:calltemplateタグがtname属性(これは、このスロットにドロップされたすべてのアセットに対するデフォルト・テンプレートとして動作します)に対して明示的な値を指定するためです。

注意:

variant属性には、任意の正規表現を含めることができます。たとえば、variant="Detail.*"と指定すると、テンプレートの使用はDetailで始まる名前のページレット・テンプレートのみに制限されます。

25.2.2.2 スロット・タイトルの調整

slotnameの値を青のオーバーレイに表示するのではなく(これは通常、開発者のみに意味のある技術的な文字列です)、この値を任意の文字列に置き換えることができます。これを行うには、次のコードに示すように、title属性をinsite:calltemplateタグに追加します。

<insite:calltemplate
slotname="HelloSlot"
tname="HelloDetail"
args="c,cid"
variant="HelloDetail|Detail"
title="Article Detail Area" />

title属性を定義すると、デフォルトのスロット・タイトルがオーバーライドされます。

25.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テンプレート・アセットの適切な引数として宣言します。

1. Adminインタフェースから、HelloDetailテンプレート・アセットを編集します。

2. 「適切な引数」に対して、image-alignと入力して「引数の追加」をクリックします。

3. 「必須」を選択します。

4. 「引数の説明」に対して、Image Alignmentと入力します。

5. 「有効な値」に対して、次の説明を追加します。

- 「値」がleftの場合は、「値の説明」にAligned Leftと入力します。

- 「値」がrightの場合は、「値の説明」にAligned Rightと入力します。

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

2. WebCenter Sitesで加えた変更を必ずWSDTワークスペースに同期化してください。

3. WebCenter Sites Developer Toolsプラグインを使用して、image-alignをキャッシュ基準セットに追加します。

1. SitesワークスペースでHelloDetailテンプレートを右クリックします。

2. 「プロパティ」を選択します。

3. 「キャッシュ基準」で、リストの末尾にimage-alignを追加します。キャッシュ基準値の詳細は、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

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

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が現在選択されているレイアウトであるとすると、「詳細」には次のオプションが表示されます。

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

編集ユーザーは、insite:calltemplateタグの使用によって、関連付けられたコンテンツの編集とレイアウトの編集を行えます。この項では、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの相違点を説明し、この2つの機能を組み合せて編集ユーザーが関連付けられたコンテンツと、そのコンテンツのレンダリングに使用されるテンプレートの両方の編集を行える方法を説明します。

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

- 第25.2.3.1項「コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの理解」

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

25.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=" "
/>

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

この項では、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの機能を組み合せて、編集ユーザーが関連付けられたコンテンツとそのコンテンツのレンダリングに使用されるテンプレートの両方の編集を行える方法を説明します。

コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの機能を組み合せるには、insite:calltemplateタグを、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットの両方に必要なすべての属性とともに使用します。

- これらの属性は、(ユーザーに対してドロップ可能ゾーンを作成する)コンテンツ編集可能スロットに必須です。

field, assetid, assettype

- この属性は、(ユーザーが別のテンプレートを選択してコンテンツをレンダリングできる)プレゼンテーション編集可能スロットに必須です。

slotname

このコードでは、コンテンツ編集可能スロットとプレゼンテーション編集可能スロットに対する属性が組み合されます。

<insite:calltemplate
slotname=" "
assetid=" "
assettype=" "
field=" "
cid=" "
c=" "
tname=" "
/>

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

この項は、第25.1項「コンテキスト内コンテンツ編集用テンプレートのコーディング」で作成した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は関連記事に対してデフォルト・テンプレートとして動作するようになります。任意の関連記事を右クリックし、「コンテンツ・レイアウトの変更」機能を選択すると、代替テンプレートが選択できるようになります。

25.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>

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

- 第25.2.4.1項「スロットの有効範囲の定義」

- 第25.2.4.2項「動作中のコンテキスト変数の使用方法」

- 第25.2.4.3項「コンテキスト値の初期化」

- 第25.2.4.4項「コンテキストのオーバーライド」

- 第25.2.4.5項「コンテキストとキャッシング」

25.2.4.1 スロットの有効範囲の定義

スロットを定義するときに、テンプレート開発者はスロットの有効範囲を決定できます。通常は、このスロットで加えられたプレゼンテーション変更をローカルにするかグローバルにするかを決定します。

- ローカル: 現在編集しているWebページのみに表示されます。

- グローバル: サイト内の複数のWebページ(おそらく、サイト内のすべてのWebページ)にわたります。

これはcontext変数の値を操作することで実行されます。これについては、次の各項で説明します。

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

1. HelloArticleLayoutテンプレートを2つのavisports記事(たとえば、All 25 Nevada resorts serving great snowおよびCold snap back on the scene)に割り当てます。

2. ContributorインタフェースのWebモードでこれらの記事を観察してみると、メイン・スロットがデフォルト・テンプレートHelloDetailでレンダリングされていることが分かります。これは、HelloDetailがJSPコードでデフォルト・テンプレートとして指定されたテンプレートであるためです。

3. 「コンテンツ・レイアウトの変更」オプションを使用して、DetailテンプレートをAll 25 Nevada resorts serving great snowの記事に割り当てます。このページは、次のスクリーン・キャプチャのように表示されます。

4. このWebページをCold snap back on the sceneの記事でリフレッシュします。メイン・スロットのプレゼンテーションも、Detailテンプレートを使用しているため、このWebページで変更されています。

どのように処理されたかを理解するために、最初に、新規選択されたテンプレートを次の項目に関して記録することによって、WebCenter Sitesがプレゼンテーション変更を格納したことを知っておく必要があります。

- スロット名

- 現在のサイト名

- コンテキスト

その結果、スロット・コンテンツ・レイアウトをHelloDetailからDetailに変更したときに、次のプレゼンテーション・データが記録されました。

- site: avisports

- slotname: ArticleDetail

- context: (空)

- tname: Detail

HelloArticleLayoutテンプレートの実行時にコンテキストは最初は空であっため、コンテキストは空であり、スロットがレンダリングされても変更されることはありません。このため、HelloArticleLayoutテンプレートを使用してレンダリングされたavisportsのWebページはすべて、前述の記録されたプレゼンテーション・データと一致します。その結果、すべての記事ページに対してDetailテンプレートが使用できるようになりました。

25.2.4.3 コンテキスト値の初期化

前の項で観察した動作は意図された動作でもあります。しかし、編集ユーザーはローカルなプレゼンテーション変更を必要とする場合もあります。つまり、変更を現在編集中のWebページでのみ表示できるようにすることです。

これを行うには、context変数を、指定されたWebページを一意に識別する値に設定する必要があります。ここでは、コンテキストの初期化に、たとえば、テンプレート名、ID、およびレンダリングされたアセットのタイプを使用するだけで十分です。

<ics:setvar
name="context"
value='<%=ics.GetVar("c")
+ ":" + ics.GetVar("cid")
+ ":HelloArticleLayout"%>' />

意図される結果によっては、その他のパラメータを追加してコンテキストを初期化できます。前述の行をHelloArticleLayoutテンプレートに追加して、プレゼンテーションの変更が記事ページごとにローカルであることを検証できます。

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

render:calltemplateタグとinsite:calltemplateタグの両方にオプションのcontext属性が割り当てられているため、この属性を使用して現在のコンテキストをオーバーライドできます。

25.2.4.5 コンテキストとキャッシング

コンテキストは、プレゼンテーション編集機能がサイトで有効化されている場合のみ役立ちます。

そうでない場合は、すべてのテンプレートのキャッシュ基準からコンテキストを削除できます(ページ・キャッシュに不要なコピーを作成しないようにするため)。

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

前出の例では、スロットはコンテンツの保持に使用されました。この項では、ナビゲーション・バー、ログイン・ボックス、パブリッシュされた最後の10個の記事をサイトに表示するコード・スニペットなどの機能の保持にスロットを使用する方法を検討します。これらの機能は、CSElementアセットまたはSiteEntryアセットとして使用できます。

CSElementアセットまたはSiteEntryアセットをスロットにドロップできるようにすることで、技術者以外のユーザーは、コードを変更する必要もなく、特定のWebページの動作を変更できるようになります。

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

- 第25.2.5.1項「CSElementアセットを含むスロットの定義」

- 第25.2.5.2項「CSElementアセットまたはSiteEntryアセットの使用」

- 第25.2.5.3項「適切な引数の使用」

- 第25.2.5.4項「ネストされたスロットの使用」

25.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に設定されていることを確認する必要があります(これは、このアセット・タイプがアソシエーション・フィールドで別のアセット・タイプの子アセット・タイプになりえることを意味します)。詳細は、第15.2.6項「手順4: アセット・タイプの構成」を参照してください。

注意:

スロットに許可されるアセット・タイプのリストにSiteEntryまたはCSElementを表示するには、両方のアセット・タイプのCan Be Child AssetフラグがTrueに設定されていることを確認する必要があります(これは、このアセット・タイプがアソシエーション・フィールドで別のアセット・タイプの子アセット・タイプになりえることを意味します)。詳細は、第15章「ベーシック・アセット・タイプの設計」を参照してください。

25.2.5.2 CSElementアセットまたはSiteEntryアセットの使用

SiteEntryアセットはコードを保持しないで、単にCSElementアセットを指します。この2つのケースの唯一の相違点として、SiteEntryを使用した場合、エレメントはキャッシュ・エンジンを通して呼び出されます。そのため、SiteEntryアセットをドロップしても、それに関連するCSElementアセットをドロップしても結果は同じです。

したがって、SiteEntryまたはCSElementのいずれを使用するかの決定は、実装に依存します。機能をSiteEntryとして表示しても、このコード・スニペットのレンダリングにはキャッシングが使用されることが確認できるだけです。

25.2.5.3 適切な引数の使用

テンプレートと同様、CSElementアセットに対して適切な引数を定義できます。CSElementがスロットにドロップされると、スロット・プロパティ・パネルから適切な引数が使用できるようになります。

これはSiteEntryアセットをドロップする場合にも当てはまりますが、スロット・プロパティ・パネルに表示される適切な引数は関連のCSElementアセットの適切な引数であることが異なります(SiteEntryアセットには、専用の適切な引数が割り当てられていません)。

25.2.5.4 ネストされたスロットの使用

アセットをコンテンツ編集可能スロットにドロップするときに、このアセットをレンダリングするテンプレートは他のスロットも定義できる可能性があります。1つの領域にレンダリングされるコントロールやスロットが過剰にならないように、ネストされたスロットの動作は単純なドロップ可能領域(ツールバーとオーバーレイのないもの)に自動的に低下されます。Contributorインタフェースがユーザーにとって単純で使いやすいようにするために、通常はネストされたスロットを使用しないことをお薦めします。

25.2.6 アセット・タイプの制約

デフォルトでは、WebCenter Sitesでスロットにドロップできるアセット・タイプは次のとおりです。

- fieldを定義した場合(コンテンツ編集可能スロット): フィールド定義により指定された任意の適切なアセット・タイプ

- fieldが未定義の場合(プレゼンテーション編集可能スロット): Can Be Child AssetフラグがTrueに設定されている任意のアセット・タイプ。詳細は、第15.2項「ベーシック・アセット・タイプの作成」を参照してください。

次のようにclegal属性を使用して、許可されるアセット・タイプをさらに制限することもできます。

<insite:calltemplate
slotname="Main"
clegal="Article,Product"
...
/>

次の構文では、アセット・サブタイプによってさらに制限できます。

<insite:calltemplate
slotname="Main"
clegal="type1:subtype1,type2:subtype2"
...
/>

注意:

type:*(ワイルドカードとしてアスタリスクを使用)も有効であり、これはtype値のように動作します。

25.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モード」→「ビューの編集」でページ機能の一部を無効化する場合もあります。

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

コントリビュータは、コンテキスト内UIからコンテンツを作成できます。これを行うには、タイプinsiteのスタート・メニュー・アイテムと、作成するアセット・タイプに適用可能なレイアウト・テンプレートを少なくとも1つ提供します。

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

- 第25.3.1項「コンテンツ内作成用のスタート・メニューの定義」

- 第25.3.2項「コンテキスト内作成用のレイアウト・テンプレートの提供」

- 第25.3.3項「空の値インジケータの提供」

- 第25.3.4項「編集固有のプレゼンテーション・ロジックの提供」

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

コンテキスト内作成用に特定のアセット・タイプを有効にするために、タイプinsiteのスタート・メニューを用意する必要があります。つまり、「タイプ」ドロップダウン・メニューで「新規Insite」オプションを選択する必要があります。

さらに、作成中のアセットに1つ以上の必須フィールドを割り当てる場合は、「デフォルト値」メニューを使用してスタート・メニューにデフォルト値を提供する必要があります。

必須値が不足している場合、ユーザーはアセット・フォームに送られます。

ユーザーが「新規Insite」スタート・メニューを選択すると、どうなるでしょうか。編集ユーザーは、最初にレイアウト・テンプレートと新規作成したアセット用の名前を選択するよう促されます。

「続行」をクリックすると、ワークフローが構成されていないと想定した場合、アセットがバックグラウンドに新規作成され、選択したレイアウト・テンプレートを使用してレンダリングされます。

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

編集に使用したものと同じレイアウト・テンプレートが、コンテキスト内作成にも使用できます。ただし、テンプレートが空のアセットを使用して適切にレンダリングできるように、特別の注意を払う必要があります。

通常、これには次のことが必要になります。

- スタイル調整: 値はレンダリングされませんが、ページ上の各種エレメントは適切な位置にレンダリングされます。

- 意味のあるヘルプ・テキスト(値なしインジケータ): 編集可能フィールドが空のときにユーザーに表示されます。

- 追加のプレゼンテーション・ロジック: 編集プラットフォーム上で、テンプレートが編集モードで実行しているときのみ実行されます。

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

- 第25.3.2.1項「スタイルシートの調整」

- 第25.3.2.2項「スロット用のスタイルシート調整」

25.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>

25.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モード」→「ビューの編集」のコンテキストでテンプレートを実行している場合のみ、条件付きでインポートできます。

25.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'}"
...
/>

25.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>
<%
// in order 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>

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

WebCenter Sitesで配信されるコア・アセット・タイプは、基本的なサイト・デザイン・ロジックを提供します。この章では、オンライン・サイトの機能を実装する、ページ、問合せ、コレクションの各アセットの作成方法を説明します。また、Burlington Financialサンプル・サイトで提供されるサンプル・アセット・タイプであるスタイルシート・アセット・タイプに関する項も含まれています。

前章では、テンプレート・アセットの作成方法を説明しました。テンプレート・アセットは他のアセットに割り当てるので、サイト・デザイン・アセット・タイプを作成する前にテンプレートを作成するのが一般的です。

どのタイプのアセットを使用する場合の手順も非常に似ており、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』で詳しく説明しています。この章では、コレクション、問合せ、スタイルシート、ページの各アセット・タイプに固有の手順を紹介します。

この章には次の項が含まれます。

- 第26.1項「コレクション・アセット」

- 第26.2項「問合せアセット」

- 第26.3項「ページ・アセット」

26.1 コレクション・アセット

1つのコレクション・アセットには、1つのタイプのアセットの順序付けリストが格納されます。コレクション・アセットを作成(または設計)するには、そのコレクション・アセットに名前を付け、それに対する問合せアセットを選択します。デフォルトでは、問合せアセットを3つまで選択できます。コレクション・アセットに対する問合せが、サイト・デザインでより多く必要な場合は、追加の問合せに対するアソシエーションをさらに作成できます。アソシエーションの作成の詳細は、第15.2.11項「手順9: (オプション)アソシエーション・フィールドの構成」を参照してください。

コレクションでは、問合せアセットを使用して、そのコレクションに使用できるアセットのリストを取得します。コレクションを作成(または移入)するには、その問合せを実行し、問合せの結果からアセットを選択し、選択したアセットをランキングして順序付けます。このランキングされ、順序付けられたリストがコレクションです。

コレクションの使用は、レンダリングされたページに表示されるコンテンツを最新の状態に維持する方法の1つです。Burlington Financialサンプル・サイトでは、いくつかのコレクションが使用されています。たとえば、Burlington Financialページ・アセットに対して、「上位ストーリー」フィールド内のコレクションを選択できます。さらに、パブリッシャまたはコンテンツ・プロバイダは、次のいずれかを実行することで、そのアソシエーションによって識別されたコンテンツを変更できます。

- ツリーから別のコレクションを選択します。

- 割り当てられたコレクションを作成し、その中で別のアセットを選択します。

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

- 第26.1.1項「始める前に」

- 第26.1.2項「コレクション・アセットの作成」

- 第26.1.3項「コレクション・アセットの共有」

26.1.1 始める前に

コレクション・アセットを作成する前に、次の点に注意してください。

- コレクションには少なくとも1つの問合せが必要です。そのため、コレクションを作成する前に、必ず問合せを作成してください。

- コレクションにテンプレートを割り当てるため、コレクション・アセットを作成する前にテンプレート・アセットも作成してください。

コレクションを作成する前に、それに割り当てられるテンプレート・アセットのコーディング方法を決定する必要があります。たとえば、コレクションに対して100個のアセットを選択しても、そのうちの5つのみを表示するようにテンプレートがコーディングされていると、次のようになります。

- それらのアセットを表示するレンダリングされたページには、最初の5つしか表示されません。

- ページには最初の5つしか表示されないにもかかわらず、WebCenter Sitesは100個のアセットをすべてソートする必要があるため、必要以上にページのレンダリングに時間がかかります。

コレクションの作成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

コレクション・アセットを作成するには:

注意:

この手順を使用するには、作業するサイトに対してコレクション・アセット・タイプを有効にしておく必要があります。有効になっているかどうかは、手順6で確認できます。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 第26.1.1項「開始する前に」の手順を完了していることを確認します。

5. ボタン・バーで「新規」をクリックします。

6. アセット・タイプのリストから新規コレクションを選択します。(コレクション・アセット・タイプが有効ではない場合、このオプションは表示されません。)

次のような「コレクション」フォームが表示されます。

7. (必須)「名前」フィールドに、ページの説明的な名前を入力します。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

8. 「説明」フィールドに、コレクションの短い説明を入力します。128個までの文字を入力できます。

9. (必須)「サブタイプ」フィールドで、このコレクションが保持するアセットのタイプを選択します。

注意:

コレクションのサブタイプは問合せによって制御されます。特定のアセット・タイプに対して問合せを設定すると、そのアセット・タイプが「サブタイプ」フィールドの値になります。そのため、「サブタイプ」フィールドには、問合せが作成されたあらゆるアセット・タイプがリストされます。問合せアセットの作成の詳細は、第26.2.5項「問合せアセットの作成」を参照してください。

10. 「テンプレートの選択」フィールドで、ドロップダウン・リストからテンプレート・アセットを選択します。

11. 「カテゴリ」フィールドで、ドロップダウン・リストからカテゴリを選択します。(カテゴリを選択しないと、リスト上の最初のアイテムがデフォルトで選択されます。)

12. 「キーワード」フィールドに、将来このコレクションを検索するときに「詳細検索」フォームで検索条件として使用可能なキーワードを入力します。

13. 「関連する問合せ」セクションで、最大3つの問合せを選択します。このコレクションに対して選択するすべての問合せから、同じタイプのアセットが返される必要があります。

14. 「保存」をクリックします。

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

コレクション・アセットを共有する前に、次の点を検討してください。

- 1つのサイトでコレクションを作成することによって、そのコレクションが共有先のすべてのサイトで作成されます。サイトによって異なるアセットが含まれるコレクションを作成することはできません。

- 共有コレクションで使用される問合せアセットは、そのコレクションの共有先のすべてのサイトに共有されるアセットのみを返すようにコーディングされる必要があります。

- 他の共有アセットと同様に、コレクションに割り当てられるテンプレートも他のサイトに共有されていることを確認してください。

26.2 問合せアセット

問合せアセットには、データベースから他のアセットのリストを取得するデータベース問合せが格納されます。ただし、問合せがコレクションに対して使用される場合、その問合せは1つのタイプのアセットしか返すことができません。

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

- 第26.2.1項「問合せアセットとその他のアセット」

- 第26.2.2項「問合せの格納方法」

- 第26.2.3項「問合せ用の一般的なフィールド」

- 第26.2.4項「始める前に」

- 第26.2.5項「問合せアセットの作成」

- 第26.2.6項「問合せアセットの共有」

- 第26.2.7項「問合せアセットのプレビューと承認」

26.2.1 問合せアセットとその他のアセット

WebCenter Sitesでは、コレクション・アセットでの問合せの使用方法が、他のアセットの場合とは異なります。

- コレクションを作成(移入)する場合は、1つ以上の問合せアセットを実行し、結果のリストから必要なアセットを選択して順序付けます。そのコレクションは、問合せの結果セットから選択したアセットの静的リストになります。

- ページ・アセットに対する問合せを選択するには、非公式の関係と名前付きアソシエーションのいずれかを使用します。その他のアセット・タイプ(記事など)に対する問合せを選択するには、名前付きアソシエーションを使用します。
アセットがレンダリングされる際に、そのアセットによって問合せが直接呼び出されることはありません。アセットを書式設定するテンプレート・エレメントか、問合せを書式設定するテンプレート・エレメントのいずれかが、次のようなWebCenter Sitesの標準エレメントを呼び出すようにコーディングされます。

OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery

このエレメントが関連付けられているアセットがレンダリングされると、このエレメントによって問合せアセットが実行されます。つまり、その結果セットは動的になります。

26.2.2 問合せの格納方法

問合せアセットは、次の2つの方法のいずれかでそのデータベース問合せを格納できます。

- 直接的。「問合せ」フォームの「SQL問合せ」フィールドに問合せを直接記述できます。問合せに対して標準SQLを使用することもできますが、WebCenter Sitesシステムで外部の検索エンジンを使用している場合は、適した検索エンジン問合せを使用することも可能です。

- 間接的。エレメント内に問合せを記述し、そのエレメントを「問合せ」フォームの「エレメント名」フィールドで指定することによって、問合せアセットにそのエレメントの場所を格納できます。問合せのエレメントには、その他のエレメントと同様に、XML、JSP、JavaScript、HTMLなどを使用できます。

Burlington Financialの問合せのほとんどには、問合せが直接格納されています。つまり、「問合せ」フォームの「SQL問合せ」フィールドにSQL問合せが直接記述されています。たとえば、次のコードはNews Wire Feed問合せからの引用です。

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

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

問合せで使用する可能性のあるいくつかのWebCenter Sitesフィールドを次に示します。このうちの4つは前述のNews Wire Feed問合せの例で使用されています。

- status

- updateddate

- source

- category

- startdateとenddate

この項の残りの部分では、このリストに含まれるフィールドについて説明します。

status

すべてのアセットには、statusが含まれます。WebCenter Sitesでは、アセットを作成すると、そのタイプのアセットを保持する表に行が追加され、そのステータスは、作成済を示すPLに設定されます。

次の表では、WebCenter Sitesで使用されるステータス・コードを一覧表示して定義しています。

ステータス・コード

定義

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のデフォルトのフィールドです。これは、必須ではありません。

たとえば、Burlington Financialサンプル・サイトには、WireFeed、Asia Pulse、UPIなどのソースがあります。サイトへのソースの追加は、ツリー内の「管理」タブで行います。第15.2.13項「手順11: (オプション)ソースの構成」を参照してください。

アセットでソースを使用する場合、ソースをパラメータとして使用する問合せを記述できます。前述のNews Wire Feed問合せの例では、AND Article.source='WireFeed'文によって、「ソース」フィールドの値がWireFeedである記事のみがこの問合せによって選択されるようにしています。

category

categoryは、サイトに適用される規則に従ってアセットを分類できる、WebCenter Sitesのデフォルトのフィールドです。これは、必須ではありません。

たとえば、Burlington Financialサンプル・サイトには、Personal Finance、Banking and Loans、Rates and Bonds、Newsなどのカテゴリがあります。サイトへのカテゴリの追加は、ツリー内の「管理」タブで行います。第15.2.12項「手順10: (オプション)カテゴリの構成」を参照してください。

アセットでカテゴリを使用する場合、カテゴリをパラメータとして使用する問合せを記述できます。前述のNews Wire Feed問合せの例では、Article.category='n'文によってニュース・カテゴリからの記事アセットが含まれます。

pubid

pubidは、サイト(以前の用語ではパブリケーション)を識別する一意の値です。WebCenter Sitesでは、アセットを作成すると、そのアセットに関する情報がいくつかのデータベース表に書き込まれます。その1つは、AssetPublication表です。

AssetPublication表のアセットの行には、そのアセットが作成された対象サイトのpubidが含まれます。アセットが共有されている場合、AssetPublication表には、アセットが共有されているサイトごとに1つの行が含まれます。たとえば、記事アセットが2つのサイトで利用できる場合、AssetPublication表のその記事に対して2つの行が存在することになります。

システム上に1つのWebCenter Sitesサイトしかない場合や、問合せ結果がサイト固有になる必要がない場合は、pubidを考慮するように問合せをコーディングする必要はありません。ただし、Burlington Financialの問合せは、それらの問合せによって別のサイトからアセットが返されないようにするために、Burlington Financialのpubid (AssetPublication.pubid = 968251170475)に基づいてアセットを制限するようにコーディングされています。

startdateとenddate

いずれのサンプル・サイトでも、startdateフィールドとenddateフィールドは使用されていませんが、WebCenter Sitesデータベースにはその情報を格納するための列があります。これらのフィールドは、アセットに時間制限を割り当てることができるように用意されています。アセット・タイプでstartdateフィールドとenddateフィールドを使用すると、それらのフィールドに格納されている日付に基づいてアセットを選択する問合せを作成できます。

26.2.4 始める前に

問合せアセットの作成を開始する前に、次の点を検討してください。

- コレクション以外のアセットで使用される問合せアセットでは、テンプレートの使用は必須ではありません。識別、実行および結果の表示を行う問合せアセット専用にテンプレート・エレメントを作成することも、その処理を実行するようにページ・アセットのテンプレート・エレメントをコーディングすることもできます。

- コレクションに対する問合せを記述する場合、そのアセット・タイプに必要なフィールドを選択するようにコーディングしてください。WebCenter Sitesは、アセット・タイプの必須フィールドからの情報を受け取るようにプログラムされているため、その情報を「コレクションの作成」フォームに表示できます。
たとえば、Burlington Financial記事の場合、「名前」フィールドと「説明」フィールドが必須フィールドです。(「説明」フィールドは名前が変更され、フォームでは「ヘッドライン」として表示されます。)そのため、Burlington Financial記事を保持するBurlington Financialコレクションに対する問合せでは、「名前」フィールドと「説明」フィールドが選択されます。これらの問合せではその他いくつかのフィールドも選択されますが、WebCenter Sitesでは、問合せによって返されたアセットをコレクションの作成フォームに正しく表示するために、少なくとも「名前」フィールドと「説明」フィールドが必要です。

- コレクション専用の問合せアセットでは、テンプレートを使用する必要はありません。コレクションに割り当てられるテンプレート・エレメントによって、コレクションのアセット・リスト内のアセットが書式設定されます。

- パフォーマンス上の理由から、効率的な問合せを作成してください。例:

- 実行して問合せの結果を表示するエレメントにではなく、問合せにできるだけ多くのロジックを含めてください。たとえば、記事のリストをフィルタまたは制限する場合、リスト全体を返すように問合せをコーディングし、エレメント・コードを使用してそのリストを制限するのではなく、問合せによってフィルタまたは制限ステップが実行されることによって、完成されたリストがエレメントに返されるようにします。

- 問合せでは、エレメントによって表示される情報のみが返されるようにします。

- コレクションに対する問合せアセットは、1つのタイプのアセットしか返すことができません。

26.2.5 問合せアセットの作成

問合せアセットを作成するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. ボタン・バーで「新規」をクリックします。

5. アセット・タイプのリストから「新規問合せ」を選択します。(問合せアセット・タイプは、サイトに対して有効にする必要があります。)
次のような「問合せ」フォームが表示されます。

6. (必須)「名前」フィールドに、問合せアセットの説明的な名前を入力します。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

7. In the 「説明」フィールドに、問合せの短い説明を入力します。128個までの文字を入力できます。

8. 「テンプレート」フィールドで、ドロップダウン・リストからテンプレート・アセットを選択します。

9. 「カテゴリ」フィールドで、ドロップダウン・リストからカテゴリを選択します。(カテゴリを選択しないと、リスト上の最初のアイテムがデフォルトで選択されます。)

10. 「問合せの結果」フィールドで、この問合せが返すアセットのタイプを選択します。(問合せは、コレクションによって使用される1つのタイプのアセットのみを返すことができます。)

11. 次のいずれかを行います。

- このアセットに問合せを直接格納する場合は、「データベース」を選択し、「SQL問合せ」フィールドをクリックして、問合せを記述します。

- エレメント内に問合せを記述した場合、「エレメント」を選択して、「エレメント名」フィールドにそのエレメントの完全な名前を入力します。

12. 「保存」をクリックします。

26.2.6 問合せアセットの共有

問合せアセットを別のサイトと共有する場合は、次のヒントを検討してください。

- 問合せ結果がサイト固有になるようにする場合は、問合せによってアセットが共有先でないサイトに返されることがないように、pubidにWHERE句を含めてください。

- たとえば、コレクションに対する問合せと静的サイトに対する問合せのいずれかで、次の文を使用できます。
WHERE AssetPublication.pubid = SessionVariables.pubid

これは、コレクションを作成する場合やディスクへのエクスポート機能を使用する場合には、必ずSessionVariables.pubidを設定するためです。

- 問合せが動的サイトで使用される場合も、pubidのIDをExecuteQueryエレメントに渡すようにエレメントをコーディングするか、SessionVariables.pubid変数を設定するようにエレメントをコーディングするかぎり、同じ文を使用できます。

- ページ・アセットは共有できないため、問合せアセットによってページ・アセットが返される場合、それらの問合せアセットを共有しないでください。

- 他の共有アセットと同様に、問合せでテンプレートを使用する場合、問合せに割り当てられるテンプレートも他のサイトと共有されていることを確認してください。

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

まず、すべての問合せアセットに独自のテンプレートがあるとはかぎらないことに留意してください。問合せアセットがページ・アセットで使用されるように設計されていて、それが問合せを実際に書式設定するページ・アセットのテンプレートである場合、問合せをプレビューするためにページをプレビューする必要があります。

オンライン・サイトが動的サイトである場合(つまり、サーバーへのミラーリングのパブリッシュ方法を使用する場合)、パブリッシュされたアセットによっては、管理システムで問合せアセットによって返されるアセットが配信システムの場合とは異なる可能性があります。

そのため、問合せをプレビューしてそれを承認するかどうかを決定する場合、(プレビューに使用している)管理システム上でその問合せによって返されるアセットが、配信システムでパブリッシュ後にその問合せによって返されるアセットとは異なる可能性があることに留意してください。

26.3 ページ・アセット

ページ・アセットは、他のアセットに対する参照を格納し、設計者が実装しているデザインに従ってアセットを整理するサイト・デザイン・アセットです。

WebCenter Sitesを開き、Burlington Financialサンプル・サイトのサイト・ツリーに一覧表示されている次のようなページ・アセットを調べます。

これらのページ・アセットは、サイトのセクション(基本的に、サイトの構造や構成)を表します。提供される可能性のあるレンダリング対象ページを1つずつすべて表すことはありません。この構造的構成は、主にWebCenter Sitesユーザーのために用意されています。これはサイトを整理するための唯一の方法ではありませんが、完成済のWebサイトに似た構造を編集者が確認する際に便利です。

一般的に、ページ・アセットはサイトの設計時に一度だけ作成します。コレクション、問合せ、記事などをページ・アセットに関連付け、ページ・アセットに関連付けるアセットのタイプを書式設定するテンプレート・エレメントをコーディングします。

ページ・アセットに対して正しいコンテンツを選択するには、サイトが構造化されるしくみと、ページ・アセットのテンプレート・エレメントが何を実行するように設計されているかに精通している必要があります。そのため、サイト開発者(エレメントをコーディングし、テンプレート・アセットを作成する担当者)がサイトのページ・アセットを作成するのが一般的です。

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

- 第26.3.1項「ページ・アセット・モデル」

- 第26.3.2項「ページ属性の設計」

- 第26.3.3項「ページ・アセットの作成」

- 第26.3.4項「ページ・アセットの配置」

- 第26.3.5項「サイト・ツリー内でのページ・アセットの移動」

- 第26.3.6項「ページ・アセットとワークフローの配置」

- 第26.3.7項「ページ・アセットの編集」

- 第26.3.8項「ページ・アセットの削除」

26.3.1 ページ・アセット・モデル

ページ・アセット・モデルは、フレックス・アセット・モデルと似ています。これによって、ページ・アセットのデータ構造を変更できます。ページ・アセット・モデルは、次のようなアセット・タイプのファミリで構成されます。

- ページ属性

- ページ定義

- ページ

ページ・アセット・モデルのいくつかの一般的な特性は次のとおりです。

- ページ・アセットは、開発者が選択したページ属性によって表されます。

- ページ・アセットの特性を決定するページ属性は、それ自体もアセットです。つまり、属性は、ワークフローを通じて渡す、編集する、リビジョン追跡によって監視するなど、あらゆるコンテンツ管理操作を対象とすることができます。

- 今後、(製品にはよくあることですが)属性をアセット・タイプに追加する必要が生じた場合は、新しい属性を作成して、それを適切な定義に割り当てるだけで済みます。

- このアセット・モデルでは非常に多くの属性を持つアセットがサポートされているため、大量のデータ・セットをサポートできます。

ページ・アセット・モデルには、一般的なフレックス・ファミリのような親定義アセット・タイプも親アセット・タイプもなく、また、データの継承はサポートされていません。

26.3.2 ページ属性の設計

第16.1.4項「フレックス属性の設計」を参照してください。

注意: ページ・アセットに対しては、継承は適用されません。

ページ定義の設計

第16.1.6項「親定義とフレックス定義アセットの設計」を参照してください。

注意: ページ・アセットに対しては、「フレックス親定義」はサポートされていません。また、継承も適用されません。

ページ属性の作成

第16.3.6項「手順4: フレックス属性の作成」を参照してください。

(オプション)ページ・フィルタ・アセットの作成

第16.3.7項「手順5: (オプション)フレックス・フィルタ・アセットの作成」を参照してください。

ページ定義アセットの作成

第16.3.9項「手順7: フレックス定義アセットの作成」を参照してください。

(オプション)ページ・アソシエーションの作成

第16.3.14項「手順12: (オプション)フレックス・アセットのアソシエーションの作成」を参照してください。

26.3.3 ページ・アセットの作成

ページ・アセットを作成するには、次の手順に従ってください。

1. WebCenter Sitesにログインして、作業するサイトを選択し、WebCenter SitesのContributorインタフェースのアイコンを選択します。

2. ページに含めるアセット(記事、問合せ、イメージ、コレクションなど)を見つけてブックマークを付けます。次を実行します。

1. 「検索」フィールドに、目的のアセットを特定する条件を入力して、虫めがねボタンをクリックします。検索タブが開き、検索結果が表示されます。

2. 検索結果リストで、ブックマークを付けるアセットを選択([Ctrl]キーを押しながらクリック)します。

3. 検索タブのツールバーで、「ブックマーク」アイコンをクリックします。

4. この手順を繰り返し、目的のアセットのすべてにブックマークを付け終わったら次の手順に進みます。

タブが開き、次のような検索結果が表示されます。

WebCenter Sitesに確認メッセージが表示されます。また、「ワーク」ツリーの「ブックマーク」ノードの下に、ブックマークを付けたアセットが一覧表示されます。

3. メニュー・バーで、「コンテンツ」→「新規」→「ページ・アセット」を選択します。この例では、avisportsサンプル・サイトで「ページ(ホーム)」アセット・タイプを使用します。

注意:

avisportsサンプル・サイトを使用する場合、「ページ」タイプのアセットがWebモードで開くように構成されています。したがって、「ページ(ホーム)」アセットの作成を選択すると、「ページ(ホーム)の作成」ダイアログ・ボックスが表示されます。この手順に従い、「ページ(ホーム)」アセットをフォーム・モードで作成するには、次の手順を実行します。

「ページ(ホーム)の作成」ダイアログ・ボックスで、次の手順を実行します。

1. 「レイアウトの選択」フィールドで、ページに割り当てるレイアウトを選択します。

2. 「名前」フィールドに、ページの名前を入力します。ページの名前付けの詳細は、手順5のaを参照してください。次に「続行」をクリックします。

3. avisportsサンプル・サイトでは、作成するページ・アセットのタイプを選択すると、ページ定義が選択されます。ただし、作業しているサイト(たとえば、FirstSiteII)でこれが当てはまらない場合は、「ページ定義」フィールドが表示されます。このフィールドを使用して、作成するページのページ定義を指定し、「続行」をクリックします。フォーム・モードに切り替えます。アセットのツールバーで、「モード」スイッチをクリックします。手順5のbに進みます。

4. アセットの「作成」ビューがフォーム・モードで表示されます。

4. ページ・アセットを作成します。

1. 「名前」フィールドに、ページの名前を入力します。ページに関する説明的な名前を入力してください。64個までの英数字を入力できますが、先頭は文字にする必要があります。アンダースコア(_)とハイフン(-)は受け入れられますが、タブ文字と空白文字は受け入れられません。

2. ページ定義(該当する場合): avisportsサンプル・サイトでは、作成するページ・アセットのタイプを選択すると、ページ定義が選択されます。ただし、作業しているサイト(たとえば、FirstSiteII)でこれが当てはまらない場合は、「ページ定義」フィールドが表示されます。このフィールドを使用して、作成するページのページ定義を指定し、「続行」をクリックします。

3. 「テンプレート」フィールドで、ドロップダウン・リストからテンプレートを選択します。

4. 項目を追加するには、「ワーク」ツリーの「ブックマーク」ノードから目的のアセットを選択し、選択したアイテムを目的のフィールドにドラッグ・アンド・ドロップします。

5. アセットのツールバーで、「保存」アイコンをクリックします。
このページが保存されます。これが「未配置ページ」ページ・ノードの下の「サイト・ツリー」に表示されます。ページを配置するには、第26.3.4項「ページ・アセットの配置」を参照してください。

26.3.4 ページ・アセットの配置

ページ・アセットを作成したら、配置機能を使用して、アセットをサイト・ツリー内の適切な場所に配置します。

ページ・アセットを配置するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「サイト・プラン」タブをクリックします。次のように、「未配置ページ」リストに新しいページ・アセットが追加されたサイト・ツリーが表示されます。

5. サイト・ツリーの「配置済ページ」リストを展開します。

6. 次のいずれかを実行して、配置するページの親を選択します。

- ツリー内の最上位のページを配置する場合は、「配置済ページ」アイコンを右クリックします。

- それ以外の場合は、新しい未配置ページの挿入先となる配置済ページで右クリックして、コンテキスト・メニューから「ページの配置」を選択します。

ページの配置フォームが、右側の作業領域に表示されます。その親ページの下に配置されたすべての子ページが一覧表示されます。また、サイト・ツリー内にまだ配置されていないすべてのページも一覧表示されます。

7. 次の手順でページを配置します。
子ページ・アセットのリスト内での新しいページの位置を指定するために、未配置ページのリストで「ランク」フィールドに数字を入力します。位置指定番号の先頭は、リスト最上部の1になります。(この例では、「1」と入力するのが適切です。)

8. 「保存」をクリックします。
未配置ページ・アセットが、サイト・ツリーの、割り当てられたランクに移動します。(そのページ・アセットを新しい場所に表示するには、サイト・ツリー内で右クリックして、コンテキスト・メニューから「すべてリフレッシュ」を選択する必要がある場合があります。)

9. 親ページと配置した子ページの両方をプレビューします。手順については、第26.1項「コレクション・アセット」を参照してください。

26.3.5 サイト・ツリー内でのページ・アセットの移動

未配置ページを配置するほかに、ページの配置フォームを使用して次の操作も実行できます。

- 同じ親ページ内で子ページの順番を変更します。

- 親ページ間で子ページを移動します。

子ページの並替え

同じ親ページの子を並べ替えるには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「サイト・プラン」タブをクリックし、サイト・ツリーの「配置済ページ」のリストを開きます。

5. 子ページが複数ある配置済ページで右クリックして、コンテキスト・メニューから「ページの配置」を選択します。
ページの配置フォームが、右側の作業領域に表示されます。

6. 子ページを並べ替えるために、配置済の子ページのリストで「ランク」列に新しい値を入力します。

7. 「保存」をクリックします。
子ページがサイト・ツリー内のそれぞれの新しい位置に移動します。

親ページの変更

親ページ間で子ページを移動するには:

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. 「サイト・プラン」タブをクリックし、サイト・ツリーの「配置済ページ」のリストを開きます。

5. 次の手順でページ・アセットをその親ページから除去します。

1. 移動対象である子ページが存在する配置済ページで右クリックして、コンテキスト・メニューから「ページの配置」を選択します。
ページの配置フォームが、右側の作業領域に表示されます。

2. 配置済の子ページのリストで、移動対象である子ページの横にある「除去」チェック・ボックスを選択します。

3. 「保存」をクリックします。
子ページがサイト・ツリーの「未配置ページ」リストに移動します。

6. 次の手順でページ・アセットをその新しい親ページの下に配置します。

1. サイト・ツリー内で、未配置の子ページの挿入先になる配置済ページで右クリックして、コンテキスト・メニューから「ページの配置」を選択します。
ページの配置フォームが、右側の作業領域に表示されます。

2. 子ページ・アセットのリスト内での新しいページの位置を指定するために、未配置ページのリストで「ランク」フィールドに数字を入力します。位置指定番号の先頭は、リスト最上部の1になります。(この例では、「1」と入力するのが適切です。)

3. 「保存」をクリックします。
それまで未配置だったページ・アセットが、サイト・ツリーの、割り当てられたランクに移動します。

26.3.6 ページ・アセットとワークフローの配置

WebCenter Sitesには、アセットが(たとえば、作成者から、編集者、承認者、パブリッシャへと)チーム・メンバー間で引き継がれる際のアセットのフローを制御するワークフロー機能が用意されています。ワークフロー管理者は、サイト・ツリーにページ・アセットを配置できる人物や、どのワークフロー・ステップでその操作を実行できるかを制御するプロセスを作成できます。次のことに注意してください。

- 「ページの配置」ワークフロー権限によって、すべてのページの配置機能(「ページの配置」、「除去」および「ランク」)を制御します。

- 「ページの配置」の起動に使用する親ページと、「ランク」または「除去」を実行するあらゆる子ページの両方に対して適切な権限を持つ必要があります。

ワークフロー・プロセスの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

26.3.7 ページ・アセットの編集

一般的に、既存のページ・アセットを編集する方法としては、次の2つがあります。

- ページに含まれているアセットを変更しても、アセット・タイプは変更しません。たとえば、新しいアセットを「ブックマーク」から「次を含む」リストに移動する、異なるコレクション、問合せ、または記事を名前付きアソシエーション・フィールドから選択する、ページ・アセットにすでに関連付けられているコレクションを異なるアセットが含まれるように再作成するなどです。

- 新しいアソシエーションを作成する、またはなんらかの方法でページ・アセットの実際の構造を変更します。

一定の間隔でページ上のコレクションまたは問合せ内のコンテンツを頻繁に変更する可能性がありますが、サイトの公開後にはアソシエーション、アセット・タイプ、またはページの構造を変更する可能性は低くなります。これによって、ページを書式設定するテンプレート・エレメント内のコードの編集が必要になることもあります。

26.3.8 ページ・アセットの削除

サイトの設計フェーズでは、多くのページ・アセットの作成および削除を行う可能性があります。ただし、パブリッシュ済のサイトからページ・アセットを削除する前に、必ずその結果を理解してください。例:

- 他のページ・アセットからそのページへの参照を除去しましたか。

- 他のページ・テンプレートのいずれかが、そのページ・アセットに関する情報をなんらかの形で抽出または使用するようにコーディングされていますか。

ページ・アセットを削除する前に、他のエレメントやページからそのアセットへのあらゆる参照を除去してください。ページ・アセットは、削除前に未配置にすることをお薦めします。

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

将来サイト・プレビュー機能を正常に実装するには、時間依存の一連のアセットの作成方法をコンテンツ作成者が理解する必要があります。また、開発者は、日付に基づいてアセットをフィルタ処理するタグを、それらのアセットを表示するためのテンプレートに含める必要があります。

この章には次の項が含まれます。

- 第27.1項「将来サイト・プレビューを実装する場合の考慮事項」

- 第27.2項「一連のアセットの作成」

- 第27.3項「将来サイト・プレビューのテンプレートの作成」

- 第27.4項「キャッシングに関する考慮事項」

27.1 将来サイト・プレビューを実装する場合の考慮事項

将来サイト・プレビュー機能を使用すると、コンテンツ・コントリビュータはContributorインタフェースで将来の特定の時点に表示されるアセットをプレビューできます。この機能では、アセットの開始日属性および終了日属性を利用します。これら2つの属性によって、そのアセットがWebサイト上で提供される期間が決まります。コンテンツ作成者は、Contributorインタフェースの「編集」画面で開始日と終了日を指定できます。

将来サイト・プレビュー機能を正しく実装するには、次の要件を満たす必要があります。

- コンテンツ・コントリビュータは、適切なアセット・セットを作成する必要があります。詳細は、第27.2項「一連のアセットの作成」を参照してください。

- 管理者は、asset:filterassetsbydateタグが含まれるように、アセットをレンダリングするためのテンプレートを更新する必要があります。詳細は、第27.3項「将来サイト・プレビューのテンプレートの作成」を参照してください。

27.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タグに渡すことができます(詳細は、第27.3項「将来サイト・プレビューのテンプレートの作成」を参照)。これにより、指定日に基づいてレンダリング対象となるアセットが返されるようになります。

テンプレートでの編集、パブリッシュおよびフィルタ処理を目的とする関連アセット・グループの検索で使用しやすくするために、関連する時間依存のアセット・セットの作成時にネーミング規則に従ってコンテンツ・コントリビュータが入力する属性(nameなど)を、開発者が指定しておくことをお薦めします。

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

将来サイト・プレビュー機能では、asset:filterassetsbydateタグを適切に使用することが非常に重要です。このタグによって、アセットが指定日に基づいてフィルタ処理されます。このタグの正しい使用方法については後述します。asset:filterassetsbydateタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

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

- 第27.3.1項「asset:filterassetsbydateタグ」

- 第27.3.2項「入力リスト」

27.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)を生成します。

このタグによって実行される手順は次のとおりです。

1. コンテンツ管理システム上にテンプレートが格納されているかどうかを確認するために、cs.sitepreviewプロパティがあるかどうかがチェックされます。

2. 将来サイト・プレビューがオフになっている場合は、システム日付が日付フィールドに渡されます。

3. 将来サイト・プレビューがオンになっている場合は、タグのルーチンによって次の処理が実行されます。

- レンダリングされている現在のページでキャッシングを無効にします(キャッシングの詳細は、「キャッシングに関する考慮事項」を参照)。

- (日付ピッカーから渡された)日付パラメータを受け入れます。

- タグに渡された日付のフォーマットが適切かどうかをチェックします。

- 指定日に基づいてアセットの入力リストをフィルタ処理して、出力リストを生成します。

27.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>

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

配信システムでは、Webページが現在の日付に応じて正しく表示されるように、アセット・エントリが適切な時点でキャッシュから除去される必要があります。そのため、WebCenter Sitesでは、キャッシュされたページの有効期限を計算するために使用される開始日と終了日がファクタ内に含まれます。

注意:

WebCenter Sitesでは、ディスクへのエクスポートのパブリッシュでの開始日と終了日の使用はサポートされていません。アセットがディスクにエクスポートされる場合、開始日と終了日の各属性もディスクにエクスポートされます。ただし、ディスクへのエクスポートのパブリッシュ方法には、キャッシュのクリーンアップ・プロセスのような(他のパブリッシュ方法では、有効期限切れのアセットがディスクから自動的に除去される)メカニズムは用意されていません。

コンテンツ管理システムでは、ページがプレビューされると、asset:filterassetsbydateタグによってそのページのページ・キャッシングが無効になります。そのため、提供されるページには、将来プレビューの日付ピッカーから渡される日付に基づいてフィルタ処理されたアセットが常に表示されるようになり、別の日付入力を使用して生成された可能性のあるページ・キャッシュからページが提供されることはありません。

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

エレメントは、コンテンツを指定、抽出および表示するコードを提供します。WebCenter Sitesシステムでは、コンテンツはアセットとして保管されます。したがって、エレメント内のXMLコードやJSPコードの多くは、適切なコンテキストの適切なアセットを指定し、そのアセットのデータを抽出および表示するために使用されます。

この章では、テンプレート・アセットおよびCSElementアセット用に作成するエレメントのコーディング方法について説明します。アセット自体の作成については、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

この章には次の項が含まれます。

- 第28.1項「依存性について」

- 第28.2項「依存性をログに記録するためのコーディングについて」

- 第28.3項「CSElementアセットとSiteEntryアセットのコール」

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

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

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

- 第28.7項「ハイパーリンクのURLの作成」

- 第28.8項「エラー状態の処理」

28.1 依存性について

WebCenter Sitesシステムは、次の2種類の依存性を追跡し、それらに基づいて正確に機能します。

- 承認依存性。これらは承認済アセットをパブリッシュできるかどうかを決定する条件です。
承認システムは、アセットの承認時、そのアセットの承認依存性を計算します。同じく承認する必要のある依存アセットが存在する場合、親アセットはパブリッシュされません。

- 構成依存性。これらはページ構成の依存性を表します。これらは、アセットがレンダリングされるページおよびページレットと、そのアセットとの間の依存性であり、ページを再生成する必要があるかどうかを決定します。
ContentServerサーブレットは、ページをレンダリングする際に構成依存性をログに記録します。CacheManagerは、この依存性ログを調べて、キャッシュされたページをいつ再生成するのかを決定します。ディスクへのエクスポートのパブリッシュ方法は、この依存性ログを調べて、エクスポートされたページ・ファイルをいつ再生成する必要があるのかを決定します。

注意:

開発者はエレメントをコーディングする際、構成依存性が正確にログに記録されるようにする必要があり、静的サイトを設計している場合は、承認依存性が適切に設定されるようにする必要もあります。

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

- 第28.1.1項「パブリッシュ・システムと承認依存性」

- 第28.1.2項「ページの生成と構成依存性」

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

管理システム上で作業するパブリッシャ、エディタおよびコンテンツ・プロバイダは、ターゲット宛先にパブリッシュされるアセットを承認します。次にパブリッシュ・システムは、管理チームがWebCenter Sitesシステムに対して設定したスケジュールに従って、バックグラウンド・プロセスとして承認済アセットを自動的にパブリッシュします。

アセットをパブリッシュできるのは、そのアセットがすべての指定された承認依存性を満たしている場合のみです。つまり、すべての関連付けられたアセットが承認済であるか事前にパブリッシュされている必要があります。そうでない場合は、それらの依存性が満たされるまで、つまり依存(関連)アセット自体が同じ宛先へのパブリッシュについて承認されるまで、そのアセットのパブリッシュは保留されます。

この承認プロセスが実行されることで、コンテンツ・チームと編集チームは、アセットの依存性を手動で確認してから大量の関連アセットをパブリッシュするという作業から解放されます。また、アセットのパブリッシュ後にオンライン・サイト上に壊れたリンクが存在している可能性もなくなります。

その後アセットが変更されると、そのアセットは承認済とは見なされなくなるため、再パブリッシュ可能にするには再び承認する必要があります。

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

- 第28.1.1.1項「承認依存性の計算」

- 第28.1.1.2項「Exists、ExactおよびNone」

- 第28.1.1.3項「ディスクへのエクスポート用の承認テンプレート」

- 第28.1.1.4項「サブタイプ、フレックス定義および承認テンプレート」

28.1.1.1 承認依存性の計算

承認依存性は、対象アセットの承認時に記録されます。これらの承認依存性は、WebCenter Sitesデータベース内のApprovedAssetDeps表に書き込まれます。

アセットの承認ステータスは、そのアセットの依存性および関連付けられたアイテムの依存性によって決定されます。前者の依存性には、特定のアセット・アイテムと関連付けられたすべてのアセット・アイテムの承認ステータスが含まれます。

依存性の計算のベースとなるのは何でしょうか。それは次のようにパブリッシュ方法に依存します。

- ディスクへのエクスポートの場合は、承認システムは、対象アセットに割り当てられたテンプレート、またはそのタイプのアセットのデフォルト承認テンプレート(指定されている場合)を使用して、そのアセットをレンダリングします。テンプレート・コード内のタグによって、承認済アセットの適切な依存アセットを決定する承認依存性が設定されます。現在のアセットをパブリッシュするためには、これらの依存アセットが適切な承認状態になっている必要があります。

- サーバーへのミラーリングまたはXMLへのアセットのエクスポートの場合は、承認プロセスはアセット・タイプ間のデータ関係を調べます。ベーシック・アセットはアソシエーションを持っています。フレックス・アセットはファミリ関係を持っています。これらの関係はどちらも、これらのパブリッシュ方法の承認依存性を作成します。たとえば、フレックス・アセットを承認した場合は、そのフレックス・アセットの親アセットが適切な承認状態になるまでは、そのフレックス・アセットはパブリッシュ・セッションの対象になりません。

28.1.1.2 Exists、ExactおよびNone

承認依存性は、exists、exactおよびnoneのいずれかです。この項では、それぞれの承認タイプについて説明します。

CSElementアセットとSiteEntryアセット、埋込みリンクと埋込みページレットおよびEngage訪問者データ・アセットの承認依存性タイプを変更することはできません。フレックス属性を除いて(フレックス属性の依存性タイプはその属性の作成時に設定する)、フレックス・ファミリ・アセット・タイプの承認依存性タイプも変更できません。ベーシック・アセット・タイプの場合、それらに関連付けられたアセットの承認依存性のタイプは、アソシエーション・フィールドの構成時に設定します。

使用しているパブリッシュ方法がディスクへのエクスポートの場合、ページのレンダリング時に構成依存性を設定するタグは、承認システムがアセットをパブリッシュできるかどうかを計算する際に承認依存性も作成します。記述するコードによって、他のアセット用に生成されたページレットに対する承認依存性が設定される場合は、承認タイプをexists、exactまたはnoneに設定できます。

注意:

様々なタイプのアセット間の関係によって作成される承認依存性のタイプについては、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の「パブリッシュ」を参照してください。

Exists

exists依存性の場合は、依存アセットがターゲット上に存在していることのみが必要であり、そのアセットのバージョンは問われません。exists依存性の場合は、子アセットが変化した場合でも(すなわちその子アセットが承認済でなくなった場合でも)、その子アセットが以前に承認されて同じ宛先にパブリッシュされていた場合は、承認済の親アセットをパブリッシュできます。

たとえば、次の手順では、コレクション・アセットは自身のランク付けされた子とのexists関係を持っています。

1. あるコレクションとそのコレクションのランク付けされた記事すべてが承認されてターゲットにパブリッシュされます。

2. ランク付けされた記事のいずれかが再び編集されますが、承認はされません。

3. このコレクション全体が再び編集されて、承認されて、宛先にパブリッシュされます。
変更されたが承認されていない記事の前のバージョンがすでに存在(exists)しているため、この記事が原因でこのコレクションのパブリッシュが保留されることはありません。

ただし、次の例では、自身の記事とのexists依存性を持つコレクションをパブリッシュできません。

1. あるコレクションとそのコレクションのランク付けされた記事すべてが承認されますが、パブリッシュはされません。

2. ランク付けされた記事のいずれかが再び編集されます。

編集された記事は宛先に一度もパブリッシュされなかったため、この記事はその宛先に対してまだ存在しておらず、したがってそのコレクションをパブリッシュできません。このコレクション・アセットは保留されて、このコレクションをパブリッシュするには、このコレクションと編集された記事の両方が承認される必要があります。

exists承認タイプは、一般にリンクに対して有用です。

Exact

exact依存性の場合は、依存アセットとターゲット上のアセットのバージョンは一致している必要があります。異なるバージョンの承認済アセットであってはいけません。exact依存性の場合は、宛先上の子アセットのバージョンと親アセットのバージョンが一致しない場合は、親アセットをパブリッシュできません。

次の例では、ページ・アセットは自身の記事アセットとのexact依存性を持っています。

1. あるページ・アセットとそのアセットの記事アセットすべてが承認されて宛先にパブリッシュされます。

2. これらの記事のいずれかが再び編集されますが、再承認はされません。

3. このページ・アセットが編集されて再承認されます。
このページ・アセットは保留されて、WebCenter Sitesインタフェース上で生成されるフォームには、このページ・アセットをパブリッシュ可能にするために承認される必要のあるアセットのリストへのリンクが表示されます。このリストでは、編集されたが再承認されていない記事が表示されます。

4. 編集された記事が承認されます。
このページ・アセットはすでに承認されているため、この時点でパブリッシュできます。この記事とページ・アセットのバージョン・スタンプが一致するからです。

5. このページ・アセットと関連付けられた別の記事アセットが編集されます。

6. このページ・アセットと編集された記事アセットの両方が再承認される必要があります。これら2つのバージョン・スタンプが一致しないからです。

- この記事は編集されたがまだ再承認されていないため、再承認される必要があります。

- このページ・アセットは、この記事の異なるバージョンに対する依存性に基づいてその前に承認されたため、再承認される必要があります。

exact承認タイプは、一般に埋込みコンテンツに対して有用です。

None

none依存性の場合は、依存アセットの承認状態にかかわらず、承認済アセットをパブリッシュできます。承認依存性タイプをnoneに設定するには、承認依存性を設定するタグにDEPTYPEパラメータを追加して、そのパラメータをnoneに設定します。

DEPTYPEのnoneという設定は、承認依存性のみに適用されます。ディスクへのエクスポートのプロセスによってページが生成されてタグが呼び出されると、構成依存性がログに記録されます。ただし、承認システムが計算時にタグを呼び出すときは、承認依存性はログに記録されません。

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

ディスクへのエクスポートのパブリッシュ方法を使用するパブリッシュの宛先に対してアセットが承認されると、承認システムはアセットに割り当てられたテンプレートを調査して、その依存性を判別します。

ただし、ディスクへのエクスポートによってアセットが実際にパブリッシュされる際に、必ずしもそのアセットに割り当てられているテンプレートが使用されるわけではありません。なぜでしょうか。なぜなら、別のエレメントのコードによって、特定のケースではそのアセットに別のテンプレートが使用されていると判断される可能性があるからです。

Burlington Financialサンプル・サイトについて考えます。このサンプル・サイトの記事のアセットは、コンテキストに応じて、様々なテンプレートでレンダリングできます。

では、Burlington Financialサンプル・サイトの記事アセットを承認する場合、承認プロセスでは記事の依存性を判別するためにどのテンプレートを使用する必要があるでしょうか。それは、すべてのテンプレートの最も代表的な一連の依存性が含まれるテンプレートです。たとえば、Burlington FinancialのFullという名前のテンプレート記事を参照してください。開発者は、各タイプのアセットのすべての考えられる依存性が含まれた特別なテンプレートを作成できます。

最も代表的な一連の依存性が含まれるテンプレートが、アセットに割り当てることを希望するテンプレートではない場合はどうでしょうか。その場合は、前者のテンプレートをそのタイプのアセットのデフォルト承認テンプレートとして設定してください。

デフォルト承認テンプレートは、アセット・タイプごとおよびパブリッシュ宛先ごとに設定できます。この機能にツリー内でアクセスするには、「管理」タブを選択し、次に「パブリッシュ」→「宛先」→「MyStaticDestinationName」→「デフォルト・テンプレートの設定」を選択します。

注意:

サーバーへのミラーリングのパブリッシュ方法を使用している宛先上のアセット・タイプのデフォルト承認テンプレートを指定した場合は、そのテンプレートは、「アセットのステータス」画面でそのアセットをプレビューする際に使用されますが、そのアセットが承認またはパブリッシュされる際には使用されません。

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

静的サイト用にフレックス・アセットを使用している場合は、複数のデフォルト承認テンプレートをファミリ内のそのフレックス・アセット・タイプに割り当てることができます。フレックス定義ごとに異なるデフォルト承認テンプレートを指定できます。

ベーシック・アセットの場合は、サブタイプ機能を使用すると、1つのアセット・タイプのアセットをさらに細かくカテゴリ分けできます。この機能を使用して、他のなんらかの編成構成に基づいて、特定タイプのアセット用に複数のデフォルト承認テンプレートを割り当てることができます。

たとえば、スポーツ記事の承認テンプレートは、海外ニュース記事の承認テンプレートとはおそらく異なるでしょう。この場合は、記事アセット・タイプに対してスポーツのサブタイプと海外ニュースのサブタイプを作成してから、このアセット・タイプの各サブタイプに異なる承認テンプレートを割り当てることができます。

ベーシック・アセットのサブタイプは、通常はアセット・タイプの作成時にアセット記述子ファイル内で作成しますが、アセット・タイプの作成後にサブタイプが必要になった場合は、「管理」タブ上の「アセット・タイプ」オプションを使用して作成します。サブタイプをアセットに割り当てるには、「新規」および「編集」アセット・フォームを使用します。前述のとおり、フレックス・アセットは、それらのフレックス定義というサブタイプをすでに持っています。

ベーシック・アセットのサブタイプの構成の詳細、およびサブタイプ全般の詳細は、第15章「ベーシック・アセット・タイプの設計」を参照してください。

28.1.2 ページの生成と構成依存性

構成依存性は、次のようないくつかの方法で記録されます。

- ディスクへのエクスポートのパブリッシュ方法は、ページをレンダリングするときに、構成依存性を適切なパブリッシュ表に記録します。そうすることで、再パブリッシュが必要になったときに、ディスクへのエクスポートのパブリッシュ方法は、どのアセットがパブリッシュ対象なのかに基づいて、再生成する必要のあるページを特定できます。つまり、これらのアセットを構成上の依存アセットとしてログに記録したすべてのページを生成します。

- WebCenter Sitesは、ページをレンダリングおよびキャッシュする際に、依存性をSystemItemCache表に記録します。この表の各行には、アセットのIDと、そのアセットがレンダリングされた生成済ページのIDまたはキャッシュ・キーが格納されています。

CacheManagerとページ・キャッシュ

CacheManagerは、WebCenter Sitesのページ・キャッシュを管理します。アセットが変更されると、CacheManagerはSystemItemCache表を調べて、それらのアセットがレンダリングされたキャッシュ済ページを特定します。次に、CacheManagerはSystemPageCache表を処理して、適切なページをフラッシュおよび再生成します。

CacheManagerは、WebCenter Sitesのページ・キャッシュに変更を加えた後に、その情報をWebCenter Sitesシステムに属しているすべてのSatellite Serverに通知するとともに、共存Satellite ServerおよびシステムにインストールされたすべてのリモートSatellite Serverにも通知します。その後、Satellite Serverアプリケーションは、Satelliteページ・キャッシュを更新します。

注意:

適切な権限を持っている場合は、SystemItemCache表とSystemPageCache表内のデータを調べることができますが、WebCenter Sitesデータベース内の他のシステム表と同様に、これらの表に格納されている情報は一切変更しないでください。

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

CacheManagerは、サーバーへのミラーリングのパブリッシュ・セッション時にパブリッシュ・システムと連動します。サーバーへのミラーリングのパブリッシュ・セッションが終了すると、パブリッシュ・システムは、そのパブリッシュ操作の対象に含まれていたすべてのアセットのすべてのIDのリストを、宛先システム上のCacheManagerサーブレットに提供します。

CacheManagerは、そのリストをキャッシュ内のページについてログに記録された構成依存性と照合し、ページ・キャッシュからフラッシュして再生成する必要のあるページおよびページレットを特定します。CacheManagerは、その結果に応じてWebCenter Sitesのページ・キャッシュを更新してから、ページのリストを共存SatelliteサーブレットとリモートSatelliteサーブレットに送信します。そうすることで、これらのサーブレットはこれらと同じページをフラッシュして、新しいバージョンのページをWebCenter Sitesのページ・キャッシュから取得できます。

CacheManagerとプレビュー機能

アセットをプレビューする際は(開発システムまたは管理システム上で)、WebCenter Sitesインタフェースは、そのアセットのテンプレートのページ名を実行します。ContentServerは、そのページをレンダリングおよびキャッシュして、レンダリングされたページとそのアセットの間の構成依存性をログに記録します。

CacheManagerは、アセットの保存時にプレビュー対象ページのキャッシュ済バージョンを更新します。つまり、ユーザーが「保存」をクリックすると、CacheManagerはそのアセットのオブジェクトIDを、キャッシュ内のそれらのページについてログ記録された構成依存性と照合します。次にCacheManagerは、ページ・キャッシュ内の適切なページをクリアおよびリフレッシュして、変更されたページに関する情報をSatelliteサーブレットに通知します。

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

エレメントのコーディング時には、依存性を正確にログに記録するコードを記述する必要があります。

構成依存性をログに記録するためのいくつかのタグが存在します。このタグが実行されると、WebCenter Sitesは、レンダリングされたページとアセットの間の依存性をSystemItemCache表に書き込むことで、この依存性情報をログに記録します。

ディスクへのエクスポートのパブリッシュ方法を使用している静的サイトの場合は、構成依存性をログに記録するタグは、承認依存性もログに記録できます。アセットが承認されると、承認システムはそのアセットをレンダリングして、そのアセットをパブリッシュできるかどうかを判断します。承認依存性タイプがnoneに設定されているタグを除いて、承認システムは、これらのタグの結果をApprovedAssetDep表に記録します。依存性タイプnoneの詳細は、第28.1.1.2項「Exists、ExactおよびNone」を参照してください。

この項では、依存性をログに記録するタグをアルファベット順に紹介します。これらおよび他のタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

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

- 第28.2.1項「ASSET.LOADおよびasset:load」

- 第28.2.2項「ASSETSET (assetset)タグ・ファミリ」

- 第28.2.3項「RENDER.GETPAGEURLおよびrender:getpageurl」

- 第28.2.4項「RENDER.LOGDEP (render:logdep)」

- 第28.2.5項「RENDER.FILTERおよびrender:filter」

- 第28.2.6項「RENDER.UNKNOWNDEPSおよびrender:unknowndeps」

28.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"/>

28.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という名前のアセットセット内の各製品アセットとレンダリングされたページの間に構成依存性が存在することを定義しています。

アセット・セットと検索状態の詳細は、第28.5.1項「アセットセット」および第28.5.2項「検索状態」を参照してください。

承認依存性タイプの設定

静的サイト用にフレックス・アセットを使用している場合は、承認システムがassetsetタグを呼び出すと、承認依存性タイプはデフォルトでnoneに設定されることに注意してください。この値をexistsまたはexactに変更するには、deptypeパラメータを使用します。

例:

<assetset:setsearchedassets name=as assettypes=Products constrain=ss fixedlist=true deptype=exists />

assetset:setsearchedassetsタグの承認タイプを設定することに意味があるのは、fixedlistパラメータがtrueに設定されている場合のみです。

28.2.3 RENDER.GETPAGEURLおよびrender:getpageurl

RENDER.GETPAGEURLタグは、BLOBではないアセットのURLを作成します。このタグは、承認(レンダリング)対象のアセットとこのタグで指定されているアセットの間のexists承認依存性をログに記録します(構成依存性ではありません)。したがって、このタグが依存性を作成するのは、パブリッシュ方法がディスクへのエクスポートである場合のみです。

この例では、記事ABCに割り当てられたテンプレートには次のコードが含まれています。

<RENDER.GETPAGEURL PAGENAME="BurlingtonFinancial/Page/Home"
cid="Variables.pageid"
c="Page"
OUTSTR="referURL"/>

このコード部分は、URLを作成して(このURLはOUTSTRパラメータによって作成された変数に格納して返される)、cid変数で指定されたアセットと記事ABCの間のexists承認依存性をログに記録します。

その後、記事ABCが承認されたときに、cid変数で指定されたページが承認されるかすでにパブリッシュされている必要があります。そうでない場合は、記事ABCのパブリッシュは保留されます。

28.2.4 RENDER.LOGDEP (render:logdep)

場合によっては、コード側でアセットを実際にロードすることなく、そのアセットのデータを取得できることがあります。その場合は、render:logdepタグを使用して、必ず手動で構成依存性をログに記録してください。

例1:

テンプレート・アセットまたは他のCSElementアセットからCSElementをコールする際は、実行するエレメント・ファイルを識別するためにそのアセットをロードすることはありません。かわりに、RENDER.CALLELEMENTタグまたはrender:callelementタグを使用して、名前を指定してそのエレメントを直接呼び出します。例:

<render:callelement name=BurlingtonFinancial/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"/>
...

承認依存性タイプの設定

ディスクへのエクスポートの宛先に対してアセットが承認されて、承認システムがこのタグを呼び出すと、このタグによって、そのアセットとレンダリングされたページの間のexact承認依存性が作成されます。

DEPTYPE引数を設定することで、承認依存性タイプをexistsまたはnoneに変更できます。例:

<RENDER.LOGDEP cid="theArticles.id" c="Article" DEPTYPE="exists"/>

28.2.5 RENDER.FILTERおよびrender:filter

RENDER.FILTERタグは、問合せによって作成されたアセットのリストに対して使用します。このタグは、非承認アセットをリストまたは問合せから除外します。また、unknownという構成依存性も設定します。　(unknown構成依存性については、第28.2.6項「RENDER.UNKNOWNDEPSおよびrender:unknowndeps」を参照してください。)

このタグを使用するのは、問合せ(コレクション・アセットや問合せアセットなど)によって返されたリスト内に非承認アセットが含まれている場合に、その問合せの結果に対する承認依存性を持つ承認済アセットのパブリッシュが保留されないようにする場合です。たとえば、コレクションに含まれている5つの記事のうち2つのみをパブリッシュできない場合でも問題ないように、エレメントに渡された任意の数の記事アセットの適切な形式設定を実行するようそのエレメントがコーディングされているとします。このタグは、非承認アセットを除外するようにディスクへのエクスポートに指示するため、非承認アセットが未パブリッシュのままでも、この問合せを使用しているページをパブリッシュできます。

このタグは、次の場所で使用することが考えられます。

- 問合せアセットのテンプレート

- コレクション・アセットのテンプレート

- SELECTTO文とEXECSQL問合せ

例:

<RENDER.FILTER LIST="ArticlesFromWireQuery" LISTVARNAME="ArticlesFromWireQuery" LISTIDCOL="id"/>

28.2.6 RENDER.UNKNOWNDEPSおよびrender:unknowndeps

RENDER.UNKNOWNDEPSタグは、依存アセットが存在しているが、これらのアセットの出所が問合せであるかこれらのアセットが頻繁に変化するという理由で、これらのアセットのIDを予測できないことを通知します。このタグは、レンダリングされたページのunknownという構成依存性をログに記録します。このタグは、ディスクへのエクスポートのパブリッシュ方法については承認依存性を設定しません。

構成依存性がunknownに設定されている場合は、対象ページは、ディスクへのエクスポートのパブリッシュ・セッションが実行されるたびに再生成される必要があり、サーバーへのミラーリングのパブリッシュ・セッションが終了するたびにページ・キャッシュ内で更新される必要があります(更新が必要かどうかにかかわらず)。

注意:

再生成する必要があるページが多いほど、サイトのパブリッシュにかかる時間が長くなるため、このタグは慎重に使用する必要があります。

このタグは、依存アセットをまったく特定できないコーディング状況に対応するために使用します。たとえば、問合せは動的であるため、実行されるたびに異なる結果セットが取得される可能性があります。いずれかの種類の問合せ(問合せアセット、SELECTTO文、EXECSQLなど)を使用する場合は、RENDER.UNKNOWNDEPSタグを使用する必要があります。

28.3 CSElementアセットとSiteEntryアセットのコール

設計上の要件として、コード側でCSElementアセットまたはSiteEntryアセットをコールする必要がある場合は、そのアセット自体をロードする必要はありません。コーディングの観点からは、開発者の関心対象はアセットとしてのCSElementやSiteEntryではなく、そのアセットが表しているエレメント・エントリやページ・エントリのみです。したがって、コード側で、適切なタグを使用してそのエレメント・エントリやページ・エントリを直接呼び出すことができます。

CSElementが対応するSiteEntryアセットを持たない場合(つまり、そのCSElementの出力はコール側ページに対して設定されたキャッシュ基準に従ってキャッシュされる場合)や、この呼び出し時に別個のページレットが必要ない場合は、RENDER.CALLELEMENT (render:callelement)タグを使用して名前を指定してそのCSElementを呼び出します。例:

<render:callelement name="BurlingtonFinancial/Common/SetHTMLHeader"/>

CSElementが対応するSiteEntryアセットを持っている場合は、RENDER.SATELLITEPAGE (render:satellitepage)タグを使用してそのSiteEntryアセットのページ名をコールすることで、そのエレメントを呼び出します。例:

<render:satellitepage pagename="BurlingtonFinancial/Pagelet/Common/SiteBanner"/>

注意:

Sites Explorerを使用してSiteCatalogエントリとElementCatalogエントリを調査する場合、これらのエントリは、ページとページレットを視覚的に編成したフォルダおよびサブフォルダとして表示されます。ただし、これらのエントリは単なるデータベース表内の行であり、実際の階層は存在しません。そのため、コードでページ・エントリまたはエレメント・エントリをコールする場合は、常にフルネームを使用する必要があります。相対パスは使用できません。

また、コール先エレメントのチェーンは、20レベルより深くなってはいけません。20レベルより深い場合は、アセットを表示する際にシステムのパフォーマンスが低下します。

また、Sites Explorerを使用して編集する場合は、アセットをそのアセットの編集フォーム(WebCenter Sitesインタフェース上)に保存することで、編集内容に応じてキャッシュが更新されるようにします。(Sites Explorerはキャッシュを自動的に更新しません。)

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

テンプレートのエレメントをコーディングするには、そのテンプレートによって形式設定されるアセット・タイプの設計を理解する必要があります。データ設計とサイト設計について事前に理解しておくことで、更新されたアセットを再表示するためにテンプレートを再コーディングする必要がなくなります。(そのために、この開発者ガイドではデータ設計とサイト設計の両方を扱っています。)

たとえば、Burlington FinancialサイトのHomeページ・アセットには、名前付きアソシエーションを通じて次の4つのコレクションと1つの問合せが割り当てられています。

- TopStoryコレクション

- SideBarTopコレクション

- SideBarMiddleコレクション

- SideBarBottomコレクション

- Wirefeed問合せ

Homeページ・アセットには、同じくHomeという名前のテンプレートが割り当てられています。このHomeテンプレートは、これらの名前付きアソシエーションを通じてHomeページに関連するこれらのコレクションと問合せを識別するようにコーディングされているとともに、これらのコレクション内のアセットおよびこの問合せによって返されるアセットを表示するようにコーディングされています。

Homeテンプレートは、これらのアソシエーションを通じてHomeページと関連付けられた任意のコレクションまたは問合せを処理するようにコーディングされているため(特定の記事を抽出するようにハードコード化されているのではなく)、このページに表示されるアセットを必要な頻度で更新できますが、このコードを変更する必要はありません。

コンテンツ・プロバイダはこれらのコレクション内の記事を変更でき、ワイヤー・フィード・サービスはWirefeed問合せによって取得される記事を毎日更新できます。これらのコレクション内でどの記事が選択されているのかや、この問合せによってどの記事が返されるのかにかかわらず、これらの記事は常に同じように形式設定されます。

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

- ベーシック・アセット・タイプのテンプレートをコーディングする際に留意すべき情報を提供します。

- 様々な状況のコード部分とコード例を紹介します。これには、静的サイトについて承認を正しく計算できるように、および動的サイトについて適切なタイミングでページ・キャッシュをクリアできるように、アセット間の依存性を管理することが含まれます。

開始する前に、このガイドの「プログラミングの基本事項」の各章を必ず参照してください。特に、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

この章のコード例で使用されているタグについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

ベーシック・アセットを表示する他のコード例については、第29章「ベーシック・アセットのテンプレート・エレメント例」を参照してください。

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

- 第28.4.1項「シンプルなコンテンツを表すアセット」

- 第28.4.2項「アソシエーション」

- 第28.4.3項「ImageFileアセットまたは他のBLOBアセット」

- 第28.4.4項「埋込みリンクを保持できるベーシック・アセット」

- 第28.4.5項「コレクション」

- 第28.4.6項「問合せアセット」

- 第28.4.7項「ページ・アセット」

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

コンテンツ・アセットのテンプレート・エレメントは通常、1つの特定の記事、広告コピー、特別オファー、イメージなどをデータベースから抽出した後、ヘッドライン、本文、署名行などの関連フィールドから情報を取得して、その情報をオンラインで表示します。

Burlington Financialの記事アセット用に設計された次のシンプルなテンプレート・エレメントについて見てみましょう。

<?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タグを使用して、それらのリンクが正しくレンダリングされるようにします。

さらに複雑な記事テンプレートの例については、Burlington FinancialのFullという名前のテンプレートを調べてください。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/Article/Full.

このテンプレート・エレメントは、ブラウザ上のページに全体表示される際の記事の形式を提供します。

28.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="BurlingtonFinancial/ImageFile/TeaserSummary" ARGS_cid="associatedImage.oid"/>
</THEN>
</IF>

このコード部分は、次の処理を実行します。

- ASSET.CHILDRENタグと、MainImageという値に設定されたCODEパラメータを使用して、この記事アセット(anAssetという名前)の「メイン・イメージ」フィールドで指定されたイメージファイル・アセットを抽出します。

- RENDER.SATELLITEPAGEタグを使用して、そのイメージファイルのIDをTeaserSummaryテンプレートのページ・エントリに渡します。このページ・エントリはPAGENAMEパラメータで指定され、このイメージファイルはARGS_cidパラメータで指定されます。TeaserSummaryテンプレートは、このイメージファイルをページレット内にレンダリングして、そのページレットをこのページに渡して戻し、このページ上でこのイメージファイルが記事とともに表示されます。

28.4.3 ImageFileアセットまたは他のBLOBアセット

イメージファイル・アセット・タイプには、アップロードされたイメージ・ファイルが格納されます。言い換えると、イメージファイル・アセット・タイプは、WebCenter Sitesデータベースから提供されるバイナリ・ラージ・オブジェクト(Binary Large OBject: BLOB)です。イメージファイルなどのBLOBを提供および表示するには、BlobServerサーブレットを使用します。

イメージファイルなどのBLOBのテンプレート・エレメントは、RENDER.SATELLITEBLOBタグを使用して、そのBLOBにアクセスする方法とそのBLOBを形式設定して表示する方法をブラウザに指示するHTMLタグを作成して返すことができます。BlobServer URLのみが必要な場合は(そのURLがHTMLタグに埋め込まれない状態で)、RENDER.GETBLOBURLタグを使用できます。

BLOBへのリンクのコーディングの詳細は、第28.7項「ハイパーリンクのURLの作成」を参照してください。

28.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タグは、埋込みリンクが含まれたフィールドのコンテンツを取得したときに、埋込みリンクを適切に管理します。

28.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"/>

より長いコード例については、Burlington FinancialのMainStory Listという名前のテンプレートを調べてください。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/Collection/MainStoryList

このテンプレート・エレメントは、他の2つのテンプレートの2つのページ・エントリをコールします。これら2つのうち1つ目のページ・エントリのルート・エレメントは、コレクション内の最上位ランクの記事を表示します。2つ目のページ・エントリのルート・エレメントは、残りの記事を表示します。

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

- 第28.4.5.1項「コレクション・テンプレートと承認依存性」

- 第28.4.5.2項「コレクション・テンプレートと構成依存性」

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

ディスクへのエクスポートのパブリッシュ方法を使用している場合は、コレクション・テンプレート内でRENDER.FILTERタグを使用できます。このタグは、承認依存性の計算時とパブリッシュ・プロセスによるサイトのレンダリング時に、すべての非承認アセットをコレクションから除外します。

次のコード部分は、Burlington FinancialのStoryListテンプレートから抜粋したものであり、このタグを例示しています。

<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="BurlingtonFinancial/Article/Summary"
ARGS_cid="ApprovedArticles.oid"
ARGS_p="Variables.p"/>
</LOOP>
</THEN>
</IF>

28.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タグを挿入してください。そうすることで、これらのアセットとレンダリングされたページの間の構成依存性を正しく追跡できます。

別の例については、第29.2項「例2: コレクション・アセット内の記事アセットへのリンクのコーディング」を参照してください。

28.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>

より長いコード例については、Burlington FinancialのPlainListという名前の問合せテンプレートを調べてください。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/Query/PlainList.

このエレメントは、PlainListQuery問合せアセットを実行するためのExecuteQueryエレメントを呼び出して、パブリッシュ方法がディスクへのエクスポートの場合はすべての非承認アセットを除外してから、得られるリストをループ処理して、そのリスト内の各アイテムの動的URLを取得して、そのURLのハイパーリンクを作成します。

ハイパーリンクの詳細は、第28.7項「ハイパーリンクのURLの作成」を参照してください。

問合せと構成依存性

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="BurlingtonFinancial/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/>

別の例については、第29.4項「例4: 問合せアセットのテンプレートのコーディング」を参照してください。

28.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="BurlingtonFinancial/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="BurlingtonFinancial/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テンプレートは、WireFeed問合せによって返される各記事のサマリー・テキストを表示するページレットを作成して、そのページレットをこのページに渡して戻し、そのページレットがこのページ上で表示されます。

さらに複雑なページ・アセット・テンプレートの例については、Burlington FinancialのSectionFrontという名前のテンプレートを調べてください。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/Page/SectionFront

このエレメントは、SectionFrontページを作成します。このページは、上部に配置されたナビゲーション・バー、左側に配置されたリンク付きのナビゲーション領域、記事のリストなどで構成されています。

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

ベーシック・アセットのテンプレートをコーディングする際は、WebCenter SitesのASSETタグ・ファミリを使用します。たとえば、ベーシック・アセットを抽出して表示するには、ASSET.LOADタグを使用します。このタグは、そのアセット・タイプのプライマリ記憶域表からデータを抽出します。

フレックス・アセットのデータベース・スキーマはベーシック・アセットのデータベース・スキーマと異なるため、WebCenter Sitesでは、ASSETタグ群のかわりに使用する次のフレックス・アセット用タグ・ファミリが用意されています。

- ASSETSET: このタグ・ファミリを使用して、1つ以上のフレックス・アセットのセットを指定します。

- SEARCHSTATE: このタグ・ファミリを使用して、アセットセット内のアセットをフィルタリングする検索絞込み条件を作成します。

注意:

ASSET.LOADタグは、フレックス・アセットを自動的にロードします。ただし、ASSET.LOADタグをフレックス・アセットに対して使用することはサポートされていません。そのコードをアップグレードできず、アセットをこの方法で抽出すると、ASSETSETタグ・ファミリを使用する場合よりはるかに時間がかかるからです。

フレックス・アセット・モデルを使用してコンテンツを表す場合は、オンライン・サイトでは、フレックス・アセットとベーシック・アセットを組み合せて使用します。ページ・アセット・タイプ(使用される可能性が高い)はベーシック・アセット・タイプであるからです。

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

- 第28.5.1項「アセットセット」

- 第28.5.2項「検索状態」

- 第28.5.3項「アセットセット、検索状態およびフレックス属性アセット・タイプ」

- 第28.5.4項「スコープ」

28.5.1 アセットセット

アセットセットは、1つ以上のフレックス・アセットまたはフレックス親アセットのグループです。各種のASSETSETタグを使用して、アセットのセットを作成したり、表示する属性値を抽出したりします。

アセットセットから取得できる情報は次のとおりです。

- アセットセット内の各フレックス・アセットの1つの属性の値

- アセットセット内の各フレックス・アセットの複数の属性の値

- アセットセット内のフレックス・アセットのリスト

- アセットセット内のフレックス・アセットの数

- アセットセット内のすべてのフレックス・アセットの1つの属性の一意の属性値のリスト

- アセットセット内のすべてのフレックス・アセットの属性の一意の属性値の数

複数のタイプのフレックス・アセットが含まれたアセットセットを作成できますが、そのためには、それらのフレックス・アセットが同じフレックス属性アセット・タイプを使用している必要があります。

使用頻度の高いASSETSETタグは次のとおりです。

ASSETSET.SETASSET
ASSETSET.SETSEARCHEDASSETS
ASSETSET.GETMULTIPLEVALUES
ASSETSET.GETATTRIBUTEVALUES
ASSETSET.GETASSETLIST
ASSETSET.SORTLISTENTRY ...

すべてのASSETSETタグはOracle Fusion Middleware WebCenter Sitesタグ・リファレンスで説明されており、これらのうちいくつかはこの章のコード例で使用しています。構成依存性とASSETSETタグの詳細は、第28.2.2項「ASSETSET (assetset)タグ・ファミリ」を参照してください。

28.5.2 検索状態

表示するフレックス・アセットのIDをどのようにして取得しますか。そのためには、検索状態オブジェクトを使用します。

検索状態は、フレックス・アセット・タイプの_Mungo表に格納されている属性値に基づいた一連の検索絞込み条件です。検索状態は、アセットセットに適用します。

検索状態を構築するには、検索状態によって記述されるフレックス・アセットのリストに対して、制約を追加して絞り込むか、または制約を削除して広げます。たとえば、GE Lightingサンプル・サイトでは検索状態を使用して、訪問者が製品カタログを参照するために使用するドリルダウン検索機能を作成します。

絞込み条件が指定されていない検索状態をアセットセットに適用すると、そのタイプのすべてのアセットのフィルタリングされないリストが作成されます。たとえば、次のコード例では、GE 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 Fusion Middleware WebCenter Sitesタグ・リファレンスで説明されており、これらのうちいくつかはこの章のコード例で使用しています。

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

検索状態は属性値に基づいて特定のアセットをフィルタリングし、アセットセットはデータベース内のアセットに検索状態を適用することで作成されるため、同じ属性アセット・タイプを共有しているフレックス・アセット・タイプのみを同じアセットセット内に含めることができます。

たとえば、GE Lightingサンプル・サイトでは、フレックス記事とフレックス・イメージの両方が含まれたアセットセットを作成できます。これらはコンテンツ・アセット属性という同じ属性アセット・タイプを使用しているからです。ただし、フレックス記事はコンテンツ属性アセット・タイプを使用しており、製品は製品属性アセット・タイプを使用しているため、フレックス記事と製品アセットの両方が含まれたアセットセットを作成することはできません。

28.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/>

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

フレックス・アセット・モデルを使用するオンライン・サイトのテンプレートをコーディングする際は、開発者の主な関心対象はフレックス属性の値です(フレックス属性自体がアセットです)。

フレックス・アセット(製品など)やフレックス親アセットは、そのアセットを表示するコンテキストで考慮される場合は、実際には属性値を抽象化したものです。

検索状態を使用して、表示するフレックス・アセットのIDを取得して、考慮対象のアセットをそれらの属性値に基づいてフィルタリングします。その結果として、属性値に基づいたフレックス・アセットやフレックス親アセットのアセットセットが得られ、その後、このアセットセット内のアセットの属性値を表示できます。

フレックス・アセットのテンプレート・エレメントのコーディングを開始する前に、使用しているフレックス・ファミリのデータ・モデルを必ず理解してください。詳細は、第11章「データ・デザイン: アセット・モデル」および第16章「フレックス・アセット・タイプの設計」を参照してください。

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

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

- 第28.6.2項「1つの製品(フレックス・アセット)が含まれたアセットセットの例」

- 第28.6.3項「特殊なケース: TEXT型、BLOB型およびURL型のフレックス属性」

- 第28.6.4項「複数の製品(フレックス・アセット)が含まれたアセットセットの例」

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

GE Lightingサンプル・サイトと、Burlington Financialサンプル・サイトに対するEngage拡張では、WebCenter Sitesに付属しているコーディング・ツールセットとフレックス・アセット・データ・モデルの最大限の機能を示しています。これらのサンプル・サイト内のテンプレートとエレメントでは、実環境とほぼ同じ量のデータを表示するフル機能を備えたオンライン・サイトのコードを示しています。

この項に記載されているコード例は、サンプル・サイト内のエレメントよりも簡単です。これらの例として最初に紹介するのは、小さいサンプル・データ・セットを操作するシンプルなアセットセット(hello assetset)と検索状態(hello searchstate)です。

これらの例で使用するサンプル・データ・セットは、次のように製品フレックス・ファミリに基づいています。

フレックス・アセット・タイプ

外部名(WebCenter Sitesインタフェースに表示されます)

内部名(WebCenter Sitesデータベースで使用されます)*

フレックス属性

製品属性

PAttributes

フレックス・アセット

製品

Products

フレックス親

製品親

ProductGroups

ASSETSETタグでASSETTYPESパラメータを使用する場合は、常にアセット・タイプの内部名を使用してください。

なし

なし

このサンプル・データ・セット内のサンプル製品は、次の属性を持つブルー・ジーンズです。

属性

データ型

値の数

sku

string

single

color

string

multiple

price

integer

single

style

text

single

次のように定義された4着のブルー・ジーンズがあります。

sku

color

price

style

jeans-1

青

35

wide

jeans-2

blue、black

30

straight

jeans-3

black、green

25

straight

jeans-4

green

20

wide

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

この項のコード・サンプルでは次を実行します。

- sku番号で指定された1着のジーンズが含まれたアセットセットを作成します。

- 製品アセットとレンダリング対象ページ(またはページレット)の間の依存性をログに記録します。

- price属性の値を取得して表示します。

- color属性の値を取得して表示します。

- 同じタグ(ASSETSET.GETMULTIPLEVALUES)を使用して、price属性とcolor属性の両方の値を取得して表示します。

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

- 第28.6.2.1項「検索状態の作成とアセットセットへの適用」

- 第28.6.2.2項「製品の価格の取得」

- 第28.6.2.3項「製品の価格の表示」

- 第28.6.2.4項「製品の色の取得」

- 第28.6.2.5項「製品の色の表示」

- 第28.6.2.6項「ASSETSET.GETMULTIPLEVALUESタグのリスト・オブジェクトの作成」

- 第28.6.2.7項「ASSETSET.GETMULTIPLEVALUESを使用した価格と色の両方の値の取得」

- 第28.6.2.8項「jeans-2製品の価格と色の値の表示」

28.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値)を問い合せることで作成されたため、このアセットセットの正確なコンテンツがわかります。これが、FIXEDLISTパラメータをtrueに設定した理由です。これで、ASSETSET.SETSEARCHEDASSETタグによって、この製品アセットの構成依存性がログに記録されるようになります。

28.6.2.2 製品の価格の取得

次に、このジーンズの価格を抽出します。

<ASSETSET.GETATTRIBUTEVALUES NAME="as" ATTRIBUTE="price" TYPENAME="PAttributes" LISTVARNAME="pricelist"/>

priceは単一値属性(つまり、この製品の価格は1つのみ)ですが、ASSETSET.GETATTRIBUTEVALUESタグは、price属性の値をリスト変数(LISTVARNAME=pricelist)として返します。

28.6.2.3 製品の価格の表示

次のコード行は、jeans-2製品の価格を表示できます。

Price: <ics.listget listname=pricelist fieldname=value/>
And this is the result:
Price: 30

28.6.2.4 製品の色の取得

次に、このジーンズで用意されている色を確認します。

前述のとおり、color属性は複数値属性です。ASSETSET.GETATTRIBUTEVALUESタグは、属性が単一値属性なのか複数値属性なのかにかかわらず同じように機能するため、ここでも、priceという単一値属性で使用したのとまったく同じ方法でこのタグを使用します。

<ASSETSET.GETATTRIBUTEVALUES NAME="as" ATTRIBUTE="color" TYPENAME="PAttributes" LISTVARNAME="colorlist"/>

28.6.2.5 製品の色の表示

次のコードは、jeans-2製品の色を表示できます。この製品には複数の色が用意されているため、このコードはリストをループ処理します。

Colors: <LOOP LIST="colorlist">
<ics.listget listname=colorlist fieldname=value/>
&nbsp;
</LOOP>

結果は次のようになります。

Colors: black blue

28.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"/>

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

次に、asという名前の元のアセットセットからprice属性とcolor属性の両方の値を取得します。

<ASSETSET.GETMULTIPLEVALUES NAME="as" PREFIX="multi" LIST="lolist" BYASSET="false"/>

28.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.attrName
fieldname=value/>&nbsp;
</LOOP><P/>
</LOOP>

このコードは、lolist変数内のすべての属性をループ処理するネストされたループを構成してから、lolistリスト変数内の各属性のすべての個別属性値をループ処理します。

結果は次のようになります。

color is blue black
price is 30

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

text型またはblob型のフレックス属性に保持されている値を表示するには、この項で説明している方法を使用します。

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

- 第28.6.3.1項「TEXT型のフレックス属性」

- 第28.6.3.2項「BLOB型のフレックス属性」

- 第28.6.3.3項「BlobServer URLの作成」

- 第28.6.3.4項「BLOBの値の取得と表示」

28.6.3.1 TEXT型のフレックス属性

ASSETSET.GETMULTIPLEVALUESタグは、text型の属性の値を取得しません。したがって、この型の属性を対象にした別個のASSETSET.GETATTRIBUTEVALUESタグを挿入する必要があります。

たとえば、これらの例で使用しているサンプル・データ・セット内のcolor属性が、string型ではなくtext型の属性であった場合は、これまでの例でASSETSET.GETMULTIPLEVALUESタグを使用してこの属性の値を取得できなかったはずです。

28.6.3.2 BLOB型のフレックス属性

第11章「データ・デザイン: アセット・モデル」で説明したように、フレックス・アセット・タイプの_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の実際の値を抽出できます。

28.6.3.3 BlobServer URLの作成

フレックス属性BLOBの値のBlobServer URLを取得するには、次の操作を実行します。

- BLOBSERVICEタグを使用して、プログラムによってMungoBlobs表とこの表内の適切な列の名前を取得します。

- URLをHTMLタグに埋め込む場合は、その名前をRENDER.SATELLITEBLOBタグに渡し、HTMLタグなしでURLのみが必要な場合は、その名前をRENDER.GETBLOBURLタグに渡します。

- 注意:
次の例に示すように、必ずBLOBSERVICEタグを使用してプログラムによってMungoBlobs表の名前を取得してください。この表の名前をコード内にハードコード化するかわりに、BLOBSERVICEタグを使用してこの値を取得することで、当製品の将来のバージョンでこの表の名前が変更された場合でも、コードが正しく機能します。

次のBLOBの例を紹介するために、次の属性をサンプル・データ・セット内のジーンズ製品に追加します。

属性

データ型

値の数

説明

blob

single

最初に、アセットセットを作成して、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を返します。

28.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"/>

ここでは、description属性の値(データ)を取得してから表示するため、BLOBSERVICE.READDATAタグを使用する必要があります。

<BLOBSERVICE.READDATA ID="descFile.value" LISTVARNAME="descData"/>
<ics.listget listname=descData fieldname=@urldata/>

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

この項のコード・サンプルでは次を実行します。

- この章で使用しているサンプル・データ・セット内のすべての製品(ジーンズ)が含まれたアセットセットを作成します。

- このアセットセット内のジーンズの数を取得して表示します。

- このアセットセット内のすべてのジーンズのcolor属性のすべての値を取得して表示します。

- このアセットセット内のジーンズのcolor属性とstyle属性のすべての値を取得して表示します。

- このアセットセット内のジーンズのすべての属性値を取得して表内に表示します。

- このアセットセットから特定の価格範囲に属するジーンズを抽出する検索絞込み条件を追加します。

- price属性に基づいたこの範囲制約を、bという文字で始まる色が用意されているジーンズをこのアセットセットから抽出する検索絞込み条件に置き換えます。

- この色制約を、blueまたはblackのどちらかが用意されているジーンズをこのアセットセットから抽出する絞込み条件に置き換えます。

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

- 第28.6.4.1項「検索状態の作成とアセットセットへの適用」

- 第28.6.4.2項「アセットセット内のアセットの数の表示」

- 第28.6.4.3項「ジーンズで用意されている色の表示」

- 第28.6.4.4項「アセットセット内のジーンズの色とスタイルの表示」

- 第28.6.4.5項「すべてのジーンズとそれらの属性値を表示する表の作成」

- 第28.6.4.6項「価格範囲に基づいたジーンズの検索」

- 第28.6.4.7項「色のワイルドカードを使用したジーンズの検索」

- 第28.6.4.8項「特定の色のジーンズの検索」

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

次のコード行は、ssという名前のフィルタリングされない検索状態を作成します。

<SEARCHSTATE.CREATE NAME="ss"/>

フィルタリングされない検索状態をアセットセットに適用すると、指定されたタイプ(この例では製品アセット)のすべてのフレックス・アセットが取得されます。

<ASSETSET.SETSEARCHEDASSETS NAME="as" CONSTRAINT="ss" ASSETTYPES="Products"/>

28.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

28.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

28.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

28.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>

結果は次のようになります。

jeans-1

35

wide

blue

jeans-2

30

straight

black blue

jeans-3

25

straight

black green

jeans-4

20

wide

green

28.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

28.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

28.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

28.7 ハイパーリンクのURLの作成

動的サイトか静的サイトかにかかわらず、WebCenter Sitesシステムを使用しているということは、コンテンツが定期的に変化するということです。このため、URLをハイパーリンク内にハードコード化できません。ページは、ディスクへのエクスポートのパブリッシュ方法によってまたは動的サイト上の訪問者のブラウザによってレンダリングされる際に、そのページでリンクを提供している、対象のアセットのIDを特定できる必要があります。

WebCenter Sitesでは、URLを作成するために使用できる次の3つのタグが用意されています(それぞれのタグにはXMLバージョンとJSPバージョンがあります)。

- BLOBではないアセットのURLについては、RENDER.GETPAGEURLタグを使用します。

- BLOBであるアセットのURLについては、RENDER.SATELLITEBLOBタグまたはRENDER.GETBLOBURLタグを使用します。

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

- 第28.7.1項「RENDER.GETPAGEURL (render:getpageurl)」

- 第28.7.2項「RENDER.SATELLITEBLOB (render:satelliteblob)」

- 第28.7.3項「RENDER.GETBLOBURL (render:getbloburl)」

- 第28.7.4項「referURL変数の使用」

28.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="BurlingtonFinancial/Article/Full
cid="Variables.cid"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

これで、referURL変数の値を使用して、<A HREF>タグ付きのハイパーリンクを作成できます。

このタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

28.7.2 RENDER.SATELLITEBLOB (render:satelliteblob)

WebCenter Sitesデータベースに格納されているバイナリ・ラージ・オブジェクト(BLOB)は、ContentServerサーブレットではなく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を作成する場合は、追加のコーディング手順が必要になることに注意してください。詳細は、第28.6.3.2項「BLOB型のフレックス属性」を参照してください。

より長いコード例については、Burlington FinancialのTeaserSummaryという名前のイメージファイル・テンプレートを調べてください。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/ImageFile/TeaserSummary.

Satellite Serverを使用していない場合でも、RENDER.SATELLITEBLOBタグを使用してください。このタグは、Satellite Serverが存在しない場合でも、HTMLタグに埋め込まれたBlobServer URLを作成できるからです。

このタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

28.7.3 RENDER.GETBLOBURL (render:getbloburl)

BlobServer URLのみが必要な場合は(そのURLがHTMLタグに埋め込まれない状態で)、RENDER.GETBLOBURLタグを使用します。

たとえば、Burlington FinancialのSetHTMLHeaderという名前のエレメントは、RENDER.GETBLOBURLエレメントを使用して、BlobServer URL (referURL変数に格納)を取得してから、クライアント側で実行されるJavaScriptコードにこのBlobServer URLを渡して、訪問者が使用しているブラウザが特定されます。この場合は、クライアント側のJavaScriptは、検知したブラウザに基づいてHTMLタグを作成するため、HTMLタグなしのBlobServer URLを必要とします。

SetHTMLHeaderエレメントは、CSElementのエレメントです。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェースを使用して、BurlingtonFinanical/Common/SetHTMLHeader CSElementを検索して調べます。

- Oracle WebCenter Sites Explorerを使用して次のエレメントを開きます。

ElementCatalog/BurlingtonFinancial/Common/SetHTMLHeader

blob型のフレックス属性のURLを作成する場合は、追加のコーディング手順が必要になることに注意してください。詳細は、第28.6.3.2項「BLOB型のフレックス属性」を参照してください。

RENDER.GETBLOBURLタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

28.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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

28.8 エラー状態の処理

エレメントをコーディングする際に、エラー状態の有無をチェックするコードも含める必要があります。どのエラー状態が重大であるのかを決定して、必要に応じて、解決策や代替アクションをコーディングしてください。場合によっては、わかりやすいエラー・メッセージを記述することが解決策になります。追加のステップとして、壊れたページがキャッシュされることを防止するコードを含めることができます。

注意:

コードをデバッグする際は、commons-logging.propertiesファイルとlog4j.propertiesファイルを使用してログ出力を有効にできます。ログ出力を有効にすると、エラー・メッセージとデバッグ・メッセージはWebCenter Sitesのログ・ファイルに書き込まれます。デバッグ・プロパティの詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

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

- 第28.8.1項「Errno変数の使用」

- 第28.8.2項「間違ったページのキャッシングの防止」

28.8.1 errno変数の使用

標準のWebCenter Sites変数であるerrno変数には、WebCenter SitesのXMLタグやJSPタグによって報告されるエラー番号が格納されます。WebCenter Sitesのタグを正常に実行できない場合は、そのタグによって、その理由を最も適切に示す値にerrnoが設定されます。たとえば、-13004というerrno値は、CURRENCYタグが読み取ろうとした数値が正しい通貨形式でなかったために、その数値を読み取ることができなかったことを示します。すべてのerrno値のリストとそれらの説明については、Oracle Fusion Middleware 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/>

より長いコード例については、Burlington FinancialのBurlingtonFinancial/Util/Account/SignUpという名前のCSElementを参照してください。このCSElementは、サイトにメンバーを追加して既存メンバーの情報を更新するコードを提供します。このCSElementは、いくつかのエラー状態の有無をチェックして、それらに対する適切な対応を提供します。

次のコード例では、テンプレートの開発プロセス中に使用できるエラー・メッセージを示しています。

<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>

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

エレメントの出力が間違っていると判断できる場合は、おそらくWebCenter SitesやSatellite Serverによってそのページがキャッシュされる必要はありません。ics.disablecacheタグを使用して、生成されるページがキャッシュされることを防止できます。

例1: エラー状態

第28.8.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の場合にキャッシュからページをクリア(ベーシック・アセットのみ)

第28.1.2項「ページの生成と構成依存性」の「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のアセットを、作成するアセットセット内に含めません。

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

この章では、Burlington Financialサンプル・サイトからの例を使用して、第28章「テンプレートおよびCSElementのエレメントのコーディング」で示した情報について説明します。

この章には次の項が含まれます。

- 第29.1項「例1: ベーシック・モジュラ・デザイン」

- 第29.2項「例2: コレクション・アセット内の記事アセットへのリンクのコーディング」

- 第29.3項「例3: ct変数の使用」

- 第29.4項「例4: 問合せアセットのテンプレートのコーディング」

- 第29.5項「例5: テンプレートを使用しない記事アセットの表示」

- 第29.6項「例6: サイト・プラン情報の表示」

- 第29.7項「例7: アセット以外の情報の表示」

この項で説明されているエレメントはすべて、Burlington Financialサンプル・サイトからのものです。

29.1 例1: ベーシック・モジュラ・デザイン

Burlington Financialサンプル・サイトは、共通コードを一度のみ作成していくつかの場所やコンテキストで再使用するために、汎用エレメントを利用するモジュラ・サイト・デザインの例です。次に、Burlington Financialのホームページ上の1つの領域を5つの異なるエレメントから作成する方法について説明します。

まず、WebCenter Sitesインタフェースを開き、Burlington Financialサイトを選択して、Homeページ・アセットをプレビューします。アセットを検索してアイコン・バーのドロップダウン・リストから「プレビュー」を選択することも、「Burlington Financial」ノードの下の「サイト・プラン」タブで「配置済ページ」アイコンを展開し、「Home」ページを選択して、右クリック・メニューから「プレビュー」を選択することもできます。

WebCenter Sitesによって、ブラウザにBurlington Financialのホームページが表示されます。

日付のすぐ下に、その日のメイン・ストーリーが表示される列があります。リスト内のストーリーごとにサマリー段落と署名行があります。ストーリーのタイトルは、そのストーリー全文へのハイパーリンクです。リスト内の最初のストーリーを含むストーリーのいくつかには、次のように写真も表示されます。

この例では、リスト内の最初のストーリーの特定、選択、リスト先頭への配置、および書式設定の方法について説明します。

リスト内の最初のストーリーの書式設定に使用されるエレメントは次のとおりです。

- BurlingtonFinanical/Page/Home

- BurlingtonFinancial/Collection/MainStoryList

- BurlingtonFinancial/Article/LeadSummary

- BurlingtonFinancial/ImageFile/TeaserSummary

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

- 第29.1.1項「最初のエレメント: Home」

- 第29.1.2項「2番目のエレメント: MainStoryList」

- 第29.1.3項「3番目のエレメント: LeadSummary」

- 第29.1.4項「4番目のエレメント: TeaserSummary」

- 第29.1.5項「LeadSummaryの再開」

- 第29.1.6項「MainStoryListの再開」

- 第29.1.7項「Homeの再開」

29.1.1 最初のエレメント: Home

Burlington Financialサンプル・サイトの「Home」ページでは、同様にHomeという名前のテンプレートが使用されています。それは、次の2つの方法で調べることができます。

- WebCenter Sitesインタフェース内で検索して検査します。

- Oracle WebCenter Sites Explorerを使用し、次の名前のテンプレート・エレメントを開きます。

ElementCatalog/BurlingtonFinancial/Page/Home

まず、Homeエレメントによって、次のようにホームページ・アセットがロードされ、そのアセットにHomePageという名前が付けられて、そのアセットのフィールドに情報が分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="HomePage"/>
<ASSET.SCATTER NAME="HomePage" PREFIX="asset"/>

cidの値がBurlington Financial URLから渡され、cの値が使用可能になります。これは、この値がHomeテンプレートのSiteCatalogページ・エントリ内のresarg1列で変数として設定されているためです。

いくつかのcallelementタグおよびRENDER.SATELLITEPAGEタグを過ぎて、次に示すASSET.CHILDRENタグまで下にスクロールしてください。

<ASSET.CHILDREN NAME=HomePage LIST=MainStories CODE=TopStories/>

Homeでは、このコードによって、ページ・アセットのTopStoriesコレクションとして指定されたコレクション・アセットが取得され(CODE=TopStories)、それを保持するリストがMainStoriesという名前で作成されます(LIST=MainStories)。

次に、Homeによって、コレクションが正常に取得されたかどうかが確認され、MainStoryListテンプレートのページ・エントリがコールされます。

<IF COND = IsList.MainStories=true>
<THEN>
<RENDER.SATELLITEPAGE pagename=BurlingtonFinanical/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が渡されます。

29.1.2 2番目のエレメント: MainStoryList

MainStoryListページ・エントリによって、そのルート・エレメントが呼び出されます。Oracle WebCenter Sites Explorerを使用し、このエレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Collection/MainStoryList.xml

MainStoryListエレメントは、コレクション・アセットを書式設定するテンプレートであるMainStoryList Templateアセットのテンプレート・エレメント(ルート・エレメント)です。

このエレメントによって、ストーリーのメイン・リストを保持する「Home」ページ列のフレームワークが作成され、その列にTopStoriesコレクションからの記事が挿入されます。それらの記事を書式設定するために、次の2つのテンプレートが使用されます。

- コレクション内の最初の記事(最上位にランクされた記事)に対するLeadSummary

- 残りの記事に対するSummary

この例の目的はリストの最初のストーリーの表示方法を紹介することなので、この例では、LeadSummaryテンプレート・エレメントについてのみ説明します。

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テンプレートのページ・エントリがコールされます。

<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/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になります。これは、その記事がリスト内の最初の記事であるためです。

29.1.3 3番目のエレメント: LeadSummary

LeadSummaryページ・エントリによって、そのルート・エレメント(LeadSummaryテンプレートのテンプレート・エレメント)が呼び出されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/Article/LeadSummary.xml

このエレメントによって、TopStoriesコレクション内の最初の記事が書式設定されます。このガイドには、次のような役割があります。

- TeaserImageアソシエーションを使用して最初の記事に関連付けられたイメージ・ファイルを取得します。

- TeaserSummaryエレメントを呼び出して、イメージの書式設定コードを取得します。

- RENDER.GETPAGEURLタグを使用して、コレクション内の最初の記事のURLを取得します。

- イメージ・ファイル・アセット、記事全文へのハイパーリンクである記事のタイトル、サマリー段落および署名行を表示します。

まず、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テンプレートのページ・エントリがコールされ、それに対してリスト内に保持されているイメージ・ファイル・アセットのIDが渡されます。

<THEN>
<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/ImageFile/TeaserSummary"
ARGS_cid="TeaserImage.oid"/>
</THEN>
</IF>

29.1.4 4番目のエレメント: TeaserSummary

TeaserSummaryページ・エントリによって、そのルート・エレメント(TeaserSummaryテンプレートのテンプレート・エレメント)が呼び出されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/ImageFile/TeaserSummary

イメージ・ファイル・アセットは、WebCenter Sitesデータベースに格納されているBLOBであり、データベースに格納されているBLOBは、ContentServerサーブレットではなく、BlobServerサーブレットによって処理される必要があります。そのため、このエレメントによって、BlobServerのURLを使用するHTMLタグが取得されます。

次に示す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に続きます。

29.1.5 LeadSummaryの再開

LeadSummaryの再開時、TopStoriesコレクション内の最初の記事のティーザー・イメージが取得されると、次のようにRENDER.GETPAGEURLを使用してその記事のURLが取得されます。

<RENDER.GETPAGEURL PAGENAME="BurlingtonFinancial/Article/Variables.ct"
cid="Variables.cid"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

MainStoryListエレメントによってLeadSummaryのページ・エントリがコールされたときに、Fullに設定されたct変数が渡されたことを思い出してください。そのため、LeadSummaryによってRENDER.GETPAGEURLに渡されるページ名は、実際にはBurlingtonFinancial/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に続きます。

29.1.6 MainStoryListの再開

次に、MainStoryListによって、TopStoriesコレクション内の残りの記事がループされ、それらの記事がSummaryテンプレートを使用して書式設定されます。

関心がある場合は、Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/Article/Summary

MainStoryListが終了すると、Homeに続きます。

29.1.7 Homeの再開

Homeが再開され、WireFeedBoxページ・エントリへのコールが行われます。

29.2 例2: コレクション・アセット内の記事アセットへのリンクのコーディング

動的に提供されるWebCenter Sitesページへのハイパーリンクのリストを作成するために、エレメントでURLが必要な場合は、RENDER.GETPAGEURLタグを使用します。

この例で参照されているエレメントは、次のとおりです。

- ElementCatalog/BurlingtonFinancial/Page/SectionFront

- ElementCatalog/BurlingtonFinancial/Collection/PlainList

この例の目的上、リンクの作成方法に集中できるように、表示されるコードからすべてのエラー・チェックが削除されています。

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

- 第29.2.1項「最初のエレメント: SectionFront」

- 第29.2.2項「2番目のエレメント: PlainList」

29.2.1 最初のエレメント: SectionFront

SectionFrontは、SectionFrontテンプレートのテンプレート・エレメント(ルート・エレメント)であり、ニュース、市場、株式などのメイン・セクション・ページに割り当てられます。これはセクションへのリンクを訪問者がクリックしたときに呼び出されます。

SectionFrontエレメントによって書式設定されたページの1つのセクションには、そのページ・アセットに関連付けられたSection Highlightsコレクションからの記事へのリンクのリストが表示されます。

Oracle WebCenter Sites Explorerを使用し、SectionFrontエレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/SectionFront.

まず、SectionFrontによって、次のようにcとcidの各変数を使用してページ・アセットがロードおよび分散され、それに対してSectionFrontPageという名前が付けられます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid"
NAME="SectionFrontPage"/>
<ASSET.SCATTER NAME="SectionFrontPage" PREFIX="asset"/>

cおよびcidの値が、起動元のリンクからSectionFrontエレメントに渡されます。そのリンクは、ホームページまたはその他いくつかの場所のいずれかからのリンクである可能性があります。

Oracle WebCenter Sites Explorerで、いくつかのASSET.CHILDRENタグを過ぎて、次に示すSection Highlightsコレクションを取得するタグまで下にスクロールしてください。

<ASSET.CHILDREN NAME="SectionFrontPage" LIST="SectionHighlights" CODE="SectionHighlight"/>

このコードによって、CODE=SectionHighlights文を使用してコレクションが取得され、それがSectionHighlightsという同じ名前でリストとして格納されます。

次に、SectionFrontによって、次のようにPlainListテンプレート(コレクション・テンプレート)のページ・エントリがコールされます。

<RENDER.SATELLITEPAGE
pagename="BurlingtonFinancial/Collection/PlainList"
ARGS_cid="SectionHighlights.oid" ARGS_p="Variables.asset:id"/>

このコードによって、Section HighlightsコレクションのID (cid)と、SectionFrontPageの名前を割り当てたページ・アセットである現在のページ・アセットのID (p)が渡されます。

29.2.2 2番目のエレメント: PlainList

PlainListページ・エントリによって、そのルート・エレメント(PlainListテンプレートのテンプレート・エレメント)が呼び出されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/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="BurlingtonFinancial/Article/
Variables.ct"
cid="theArticles.id"
c="Article"
p="Variables.p"
OUTSTR="referURL"/>

PlainListによって、RENDER.GETPAGEURLタグに対して、コレクション内の記事ごとにcidとpagenameが渡され、ctypeを使用してアセット・タイプが渡されます。ct変数がFullに設定されたため、このタグに渡されるページ名は、実際にはBurlingtonFinancial/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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

29.3 例3: ct変数の使用

ct変数は、子テンプレートの概念を表します。子テンプレートは、代替テンプレートです。アセットの作成時にアセットにテンプレートが割り当てられるため、アセットのテンプレート(デフォルトの承認テンプレートとは異なる)のIDは、ASSET.LOADタグまたはASSET.CHILDRENタグを使用して取得する情報の一部になります。

ただし、場合によっては、アセットのデフォルトのテンプレートではないテンプレートを使用する必要があります。そのような場合は、ct変数を使用して代替テンプレートの名前を指定します。

たとえば、訪問者がBurlington Financialサイトを閲覧する場合、その訪問者が利用できるサイトの大半にはテキスト専用バージョンが用意されています。テキスト専用フォーマットはデフォルトのフォーマットではなく、コンテンツ・プロバイダがテキスト専用フォーマットを各自のアセットに割り当てることはありません。Burlington Financialページ・エレメントは、代替のテキスト専用テンプレートのIDを適宜提供するようにコーディングされています。

WebCenter Sitesインタフェースを開き、Burlington Financialのコラムニスト・ページとニュース・ページの両方をプレビューします。これらのページの右上隅に、プレーン・テキスト・リンクが表示されます。

コラムニスト・ページでプレーン・テキスト・リンクをクリックします。続いて、ニュース・ページで次のようなプレーン・テキスト・リンクをクリックします。

サイト上のすべてのページで、同じエレメント(TextOnlyLinkエレメント)を使用して、そのページのプレーン・テキスト・リンクに埋め込まれたURLが確認されます。TextOnlyLinkエレメントによって、ページごとに正しいURLが返されます。これは、各ページ上のプレーン・テキスト・リンクからTextOnlyエレメントに対して、次のような必要な情報が渡されるためです。

- リクエスト元のページのID

- プレーン・テキスト・リンク用の代替のテキスト専用テンプレート(子テンプレート)

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/BurlingtonFinancial/Page/SectionFront

- ElementCatalog/BurlingtonFinancial/Page/SectionFrontText

- ElementCatalog/BurlingtonFinancial/Common/TextOnlyLink

- ElementCatalog/BurlingtonFinancial/Page/ColumnistFront

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

- 第29.3.1項「最初のエレメント: SectionFront」

- 第29.3.2項「2番目のエレメント: TextOnlyLink」

- 第29.3.3項「ColumnistFront」

29.3.1 最初のエレメント: SectionFront

Oracle WebCenter Sites Explorerを使用し、SectionFrontエレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/SectionFront.

SectionFrontは、ニュース、通貨、株式など、サイト上の標準のセクション・ページに割り当てられるテンプレート・アセットのテンプレート・エレメント(ルート・エレメント)です。

このエレメントの約3分の2の位置にある、次に示すCALLELEMENTタグまで下にスクロールしてください。

<CALLELEMENT NAME="BurlingtonFinancial/Common/TextOnlyLink">
<ARGUMENT NAME="ct" VALUE="SectionFrontText"/>
<ARGUMENT NAME="assettype" VALUE="Page"/>
</CALLELEMENT>

TextOnlyLinkは、プレーン・テキスト・リンクを作成するためのエレメントです。SectionFrontによって、このエレメントに対して、代替テンプレートの名前(ct=SectionFrontText)およびアセット・タイプの名前(assettype=Page)が渡されます。

29.3.2 2番目のエレメント: TextOnlyLink

TextOnlyLinkエレメントが実行されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/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="BurlingtonFinancial/Variables.assettype/Variables.ct"
cid="Variables.asset:id"
c="Variables.assettype"
p="Variables.p"
OUTSTR="referURL"/>

TextOnlyLinkでは、ct=SectionFrontText、assettype=Pageであることを認識しています。そのため、BurlingtonFinancial/Variables.assettype/Variables.ctは、BurlingtonFinancial/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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

続いて、TextOnlyLinkによって、ct変数が消去されます。

<REMOVEVAR NAME="ct"/>

訪問者がプレーン・テキスト・リンクをクリックすると、SectionFrontTextエレメントによって記事が書式設定され、ブラウザに表示されます。

注意:

セクション・ページのプレーン・テキスト・バージョンのフォーマットに関心がある場合は、Oracle WebCenter Sites Explorerを使用し、SectionFrontTextを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/SectionFrontText

29.3.3 ColumnistFront

Oracle WebCenter Sites Explorerを使用し、ColumnistFrontエレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/ColumnistFront

このエレメントによって、Burlington Financialのコラムニストから提供されたストーリーを表示するWebフォーマット・ページが書式設定されます。

セクション・ページの右上隅にプレーン・テキスト・リンクを作成するために、ColumnistFrontによって、次のようにTextOnlyLinkがコールされます。

<CALLELEMENT NAME="BurlingtonFinancial/Common/TextOnlyLink">
<ARGUMENT NAME="ct" VALUE="ColumnistFrontText"/>
<ARGUMENT NAME="assettype" VALUE="Page"/>
</CALLELEMENT>

ここで、TextOnlyLinkによって、ColumnistFrontから渡された情報に基づいて、訪問者をBurlingtonFinancial/Page/ColumnistFrontTextに誘導するプレーン・テキスト・リンクが作成されます。

29.4 例4: 問合せアセットのテンプレートのコーディング

問合せアセットを使用して、表示するアセットを取得する場合は、WebCenter Sitesの標準エレメント名であるExecuteQueryを使用して、この問合せアセットを実行します。

Burlington Financialでは、いくつかの問合せアセットが使用されています。この例では、「Home」ページにワイヤー・フィード・ストーリーを一覧表示するために使用されている、Home Wire Feedという名前の問合せアセットについて説明します。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/BurlingtonFinancial/Page/Home

- ElementCatalog/BurlingtonFinancial/Query/WireFeedBox

- ElementCatalog/OpenMarket/Xcelerate/AssetType/Query/ExecuteQuery

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

- 第29.4.1項「最初のエレメント: Home」

- 第29.4.2項「2番目のエレメント: WireFeedBox」

- 第29.4.3項「3番目のエレメント: ExecuteQuery」

- 第29.4.4項「WireFeedBoxの再開」

29.4.1 最初のエレメント: Home

Oracle WebCenter Sites Explorerを使用し、「Home」ページのテンプレート・エレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/Home

まず、Homeによって、次のようにホームページ・アセットがロードされ、それに対してHomePageという名前が付けられて、そのフィールド内の情報が分散されます。

<ASSET.LOAD TYPE="Variables.c" OBJECTID="Variables.cid" NAME="HomePage"/>
<ASSET.SCATTER NAME="HomePage" PREFIX="asset"/>

cおよびcidの値がBurlington FinancialのURLから渡されます。

いくつかのCALLELEMENTタグおよびRENDER.SATELLITEPAGEタグを過ぎて、次に示すASSET.CHILDRENタグまで下にスクロールしてください。

<ASSET.CHILDREN NAME="HomePage" LIST="WireFeedStories"
CODE="WireFeed"/>

このコード行では、OBJECTTYPEパラメータが使用されていないことに注意してください。WebCenter Sitesでは、CODE=WireFeedは、WireFeedアソシエーションを使用してHomeページ・アセットに割り当てられた問合せを検索して取得するうえで十分な情報であり、Homeでは問合せのIDのみが必要なので、AssetRelationTreeおよびQuery表間に結合を作成する必要がありません。WireFeed問合せは取得され、WireFeedStoriesとして格納されます。

次に、Homeによって、次のようにWireFeedBoxテンプレートのページ・エントリがコールされ、それに対してWireFeedStoriesとして格納された問合せのcidが渡されます。

<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/Query/WireFeedBox"
ARGS_cid="WireFeedStories.oid"
ARGS_p=Variables.asset:id/>

Homeによって、いくつかの情報(cid=WireFeedStories.oid文を使用した問合せのIDと、p=Variables.asset:id文を使用した元のページ・アセット(Home)のID)が渡されます。

29.4.2 2番目のエレメント: WireFeedBox

WireFeedBoxページ・エントリによって、そのルート・エレメント(WireFeedBoxテンプレートのテンプレート・エレメント)が呼び出されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/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に返されるようにするためです。

29.4.3 3番目のエレメント: ExecuteQuery

ExecuteQueryエレメントによって、問合せアセットが実行されます。

ページ・アセットにそのページのWire Feedとして割り当てることが可能な問合せアセットは、アセットのIDのみでなく、フィールド・データも返すようにコーディングされています。そのため、ExecuteQueryによって、WireFeedBoxに対して、最大8個の記事アセットとそれらのフィールドのいくつかからのデータが返されます。

このエレメントに関心がある場合は、Oracle WebCenter Sites Explorerを使用し、ElementCatalog/OpenMarket/Xcelerate/AssetType/Query/ExecuteQueryを開いて調べます。このエレメントの最初のコード行が、RENDER.UNKNOWNDEPSであることに注意してください。これは、どのアセットが返されるかを知る方法がないので、それらの依存性を記録する方法がないためです。

ExecuteQueryが終了すると、WireFeedBoxが再開されます。

29.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="BurlingtonFinancial/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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

29.5 例5: テンプレートを使用しない記事アセットの表示

Burlington Financialには、この記事を友人に電子メールで送信する機能が用意されています。記事の電子メール・フォームは次のとおりです。

明らかに、Burlington Financial開発者は、Burlington Financialのコンテンツ・プロバイダが記事の表示スタイル(テンプレート)として電子メール・フォームを割り当てることを望んでいません。そのため、記事の電子メール・フォームを作成するための電子メール・エレメントをポイントするTemplateアセットは用意されていません。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/BurlingtonFinancial/Article/Full

- ElementCatalog/BurlingtonFinancial/Article/AltVersionBlock

- ElementCatalog/BurlingtonFinancial/Util/EmailFront

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

- 第29.5.1項「最初のエレメント: Full」

- 第29.5.2項「2番目のエレメント: AltVersionBlock」

- 第29.5.3項「3番目のエレメント: EmailFront」

29.5.1 最初のエレメント: Full

Oracle WebCenter Sites Explorerを使用し、Fullテンプレートのテンプレート・エレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Article/Full

このエレメントによって、記事の全文が表示される場合に記事の書式設定コードが提供されます。これによって、次のようなアイテムが表示されます。

- サイトのバナー

- 左側のナビゲーション列

- 一連の関連ストーリー

- 記事のテキスト

- 記事の写真

- そのストーリーの印刷用リンク

- そのストーリーの電子メール送信用リンク

いくつかのRENDER.SATELLITEPAGEタグおよびCALLELEMENTタグを過ぎて、次に示すタグまで下にスクロールしてください。

<CALLELEMENT NAME="BurlingtonFinancial/Article/AltVersionBlock"/>

29.5.2 2番目のエレメント: AltVersionBlock

Oracle WebCenter Sites Explorerを使用し、このエレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Article/AltVersionBlock

AltVersionBlockは、2つのRENDER.GETPAGEURLタグで構成される短いエレメントです。最初のRENDER.GETPAGEURLタグによって、記事の印刷バージョンのURLが取得されます。2番目のRENDER.GETPAGEURLタグによって、ストーリーの電子メール・バージョンのURLが取得されます。

Burlington Financial開発者は、サイトが静的サイトであっても、ストーリーの電子メール・バージョンには動的URLを望んでいることから、2番目のRENDER.GETPAGEURLタグでDYNAMICパラメータが使用されています。

次に示す2番目のRENDER.GETPAGEURLタグまで下にスクロールしてください。

<RENDER.GETPAGEURL PAGENAME="BurlingtonFinancial/Util/EmailFront"
cid="Variables.asset:id"
c="Article"
DYNAMIC="true"
OUTSTR="referURL"/>

AltVersionBlockによって、EmailFrontページ・エントリのページ名、cの値およびcidが渡され、DYNAMICパラメータがtrueに設定されます。このタグによって、(パブリッシュ方法がディスクへのエクスポートである場合でも)記事の動的URLが作成され、OUTSTRパラメータで指定されたとおり、referURLという名前の変数でそのURLが返されます。

29.5.3 3番目のエレメント: EmailFront

EmailFrontは、AltVersionBlockからRENDER.GETPAGEURLエレメントに渡されるページ名です。EmailFrontには対応するテンプレートがないため、デフォルトではEmailFrontのSiteCatalog内にページ・エントリが作成されませんでした。Burlington Financial開発者は、このエレメントのSiteCatalogエントリをOracle WebCenter Sites Explorerから手動で作成しました。

Oracle WebCenter Sites Explorerを使用し、そのルート・エレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Util/EmailFront

このエレメントによって、訪問者が電子メール送信対象として選択した記事の最初の段落を表示するフォームが作成されます。

まず、EmailFrontによって、次のように記事アセットがロードされます。

<ASSET.LOAD TYPE="Article" OBJECTID="Variables.cid" NAME="EmailFront"/>
<ASSET.SCATTER NAME="EmailFront" PREFIX="asset"/>

次に、電子メール・フォームが作成される前に、ページのいくつかの部分が書式設定されます。次に示すFORMというHTMLタグまで下にスクロールしてください。

<FORM NAME="mailform" onSubmit="return checkEmail();" METHOD="POST" ACTION=...

続いて、EmailFrontによって、次のようにLeadSummaryページ・エントリがコールされて、フォーム内の記事のサマリーが表示されます。

<RENDER.SATELLITEPAGE
ARGS_pagename="BurlingtonFinancial/Article/LeadSummary"
ARGS_cid="Variables.cid"
ARGS_ct="Full"
ARGS_p="Variables.p"/>

LeadSummaryエレメントの詳細は、第29.1項「例1: ベーシック・モジュラ・デザイン」を参照してください。または、Oracle WebCenter Sites Explorerを使用して、このエレメントを開いて調べてください。

29.6 例6: サイト・プラン情報の表示

Burlington Financialサンプル・サイトの開発者は、WebCenter Sitesインタフェースの「サイト・プラン」タブを使用して、Burlington Financialサイトの基本構造の順序付けを行ったため、SitePlanTree表から情報を抽出して、サイトのナビゲーション機能を作成できます。

たとえば、SitePlanTree表からサイトの構造に関する情報を抽出することで、Burlington Financialのホームページ上部のナビゲーション・バーが作成されます。

SitePlanTree表から情報を抽出するには、WebCenter SitesのSITEPLANタグ・ファミリを使用します。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/BurlingtonFinancial/Article/Home

- ElementCatalog/Pagelet/Common/SiteBanner

- ElementCatalog/BurlingtonFinancial/Site/TopSiteBar

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

- 第29.6.1項「最初のエレメント: Home」

- 第29.6.2項「2番目のエレメント: SiteBanner」

- 第29.6.3項「3番目のエレメント: TopSiteBar」

- 第29.6.4項「SiteBannerの再開」

29.6.1 最初のエレメント: Home

Oracle WebCenter Sites Explorerを使用し、Homeテンプレートのテンプレート・エレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/Home

次に示す最初のRENDER.SATELLITEPAGEタグまで下にスクロールしてください。

<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/Pagelet/Common/SiteBanner"/>

29.6.2 2番目のエレメント: SiteBanner

SiteBannerページレットによって、そのルート・エレメントが呼び出されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/Common/SiteBanner

SiteBannerによって、バナーのイメージ(Burlington Financialのロゴおよび広告イメージ)が収集され、サイトのメイン・セクションへのナビゲーション・リンクを作成するためのエレメントがコールされます。

次に示すCALLELEMENTタグまで下にスクロールしてください。

<CALLELEMENT NAME="BurlingtonFinancial/Site/TopSiteBar"/>

29.6.3 3番目のエレメント: TopSiteBar

TopSiteBarが実行され、サイトのメイン・セクションへのナビゲーション・リンクが作成されます。Oracle WebCenter Sites Explorerを使用し、TopSiteBarを開いて調べます。

ElementCatalog/BurlingtonFinancial/Site/TopSiteBar

29.6.3.1 「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="BurlingtonFinancial/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の詳細は、第4.6.4.4項「HTMLタグでの変数の使用」を参照してください。

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

コードの次の部分では、TopSiteBarによって、「Home」ページの子ページへのリンクが作成されます。「Home」ページの子ページを特定するには、まず「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="BurlingtonFinancial/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文によって、ページのテンプレートの名前がそのテンプレート・フィールドから取得されます。次に、その部分を再度示します。

<ASSET.GET NAME="ThePage" FIELD="template"
OUTPUT="pagetemplate"/>

続いて、その情報が、RENDER.GETPAGEURLタグに渡されるPAGENAMEパラメータで次のように使用されます。

PAGENAME="BurlingtonFinancial/Page/Variables.pagetemplate"/>

したがって、ページ・アセットのテンプレートがSectionFrontの場合は、この引数文によってpagename=BurlingtonFinancial/Page/SectionFrontが渡されることになります。また、ページ・アセットのテンプレートがAboutUsの場合は、この引数文によってpagename=BurlingtonFinancial/Page/AboutUsが渡されることになります。

29.6.4 SiteBannerの再開

SiteBannerは、TopSiteBarへのコール後に終了します。SiteBannerエレメントが、サイト内の各ページで呼び出されます。

SiteBannerにはSiteCatalog表にページ・エントリがあるため、訪問者が初めてBurlington Financialサイト上でページを要求すると、TopSiteBarによって作成されるナビゲーション・バーの結果がキャッシュされます。これにより、サイトでは、訪問者がその後訪問するページごとにTopSiteBarエレメントを再度呼び出す必要がなくなるため、パフォーマンスの速度が向上します。

29.7 例7: アセット以外の情報の表示

場合によっては、WebCenter Sitesデータベースにアセットとして格納されていない情報をレンダリングして表示する必要があります。たとえば、Burlington Financialサイトでは、各ページに今日の日付が表示されます。日付は、アセットとして格納できる情報ではありません。

この例で使用されるエレメントは次のとおりです。

- ElementCatalog/BurlingtonFinancial/Article/Home

- ElementCatalog/Common/ShowMainDate

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

- 第29.7.1項「最初のエレメント: Home」

- 第29.7.2項「2番目のエレメント: ShowMainDate」

29.7.1 最初のエレメント: Home

Oracle WebCenter Sites Explorerを使用し、Homeテンプレートのテンプレート・エレメントを開いて調べます。

ElementCatalog/BurlingtonFinancial/Page/Home

3番目のCALLELEMENTタグ(ShowMainDateエレメントを呼び出すタグ)まで下にスクロールしてください。

<CALLELEMENT NAME=BurlingtonFinancial/Common/ShowMainDate/>

29.7.2 2番目のエレメント: ShowMainDate

ShowMainDateが実行されます。Oracle WebCenter Sites Explorerを使用し、これを開いて調べます。

ElementCatalog/BurlingtonFinancial/Common/ShowMainDate

メインのコード行は次のとおりです。

<span class="dateline"><csvar NAME="CS.Day CS.Mon CS.DDate, CS.Year"/></span>

これによって日付が計算され、その値がHomeエレメントに返され、ページ上部(ナビゲーション・バーの下でストーリーのメイン・リストの上)に表示されます。

このエレメントによって、簡単な計算が実行され、ブラウザのウィンドウにレンダリングされるHTMLコードにその値が出力されます。これによって書式設定されるコンテンツ・アセットも、これをルート・エレメントとして使用するTemplateアセットもありません。また、このエレメントにはSiteCatalogエントリはありません。これは、その結果(日付)が、「Home」ページがレンダリングされるたびに計算される必要があるためです。

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

この章では、サイトの多言語サポートの構成について説明します。

この章には次の項が含まれます。

- 第30.1項「多言語サポートのサイトの構成の概要」

- 第30.2項「ロケール・フィルタリングでの作業」

- 第30.3項「サイトに対する多言語サポートの計画」

- 第30.4項「サイトに対する多言語サポートの構成」

30.1 多言語サポートのサイトの構成の概要

多言語サポートのサイトを構成すると、そのサイトのユーザーはロケール(言語バージョン)の指定をアセットに割り当て、アセットの翻訳を作成できるようになります。多言語コンテンツ用のサイト固有の配信ルールを作成するオプションもあり、そのルールによって、どの言語バージョンのアセットをオンライン・サイトで表示するか、訪問者のリクエストがそのコンテンツでまだ用意できていない言語バージョンの場合はどう対処するかが決まります。

この章では、サイトの設計の計画作成および実装する場合に考慮する必要のあるトピックについて、多言語サポートの観点から説明します。そのうえで、多言語アセットと関連機能をサポートするためにサイトの構成に必要な手順について説明します。

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

- 第30.1.1項「ディメンション」

- 第30.1.2項「ディメンション・セット」

- 第30.1.3項「サイト間の多言語サポート」

- 第30.1.4項「マスター・アセット、翻訳および多言語セット」

- 第30.1.5項「翻訳およびアセット関係」

- 第30.1.6項「承認依存性」

30.1.1 ディメンション

WebCenter Sitesのロケール指定は、ディメンションの概念によって実装されます。ディメンションとは、別の点では意味的に同一であるアセットを区別する識別子のことです。ロケール(アメリカ英語はen_US)は、同一のコンテンツに対する2つの翻訳を区別するディメンションの1タイプです。

ディメンションは、タイプ「ディメンション」のアセットで表されます。このアセット・タイプは、ユーザーが「ディメンション」アセット(サブタイプ「ロケール」)を作成できるよう、またコンテンツ・プロバイダがロケール指定を翻訳対象のアセットに割り当てることができるように、開発者がサイト単位で有効にする必要があります。

注意:

ユーザーは、ロケール指定が割り当てられていないアセットの翻訳を作成できません。

各「ディメンション」アセットは、サイトでロケールを表示します。たとえば、en_US「ディメンション」アセットはアメリカ英語、fr_CA「ディメンション」アセットはカナダ仏語を表します。コンテンツ・アセットにロケールが割り当てられると、その割当ては対応するアセット・タイプのassetType_Dim表に記録されます。

指定されたロケールでのコンテンツの公開では、オンライン・サイトのロケールを有効にする必要があります。つまり、ロケールを示すディメンション・アセットを配信システムに公開し、サイトのディメンション・セットにそのロケールを加える必要があります。　第30.1.2項「ディメンション・セット」を参照してください。

30.1.2 ディメンション・セット

ロケールをすでに作成してある場合には、少なくとも1つのディメンション・セットを作成することをお薦めします。ディメンション・セットとはディメンション・アセット(ロケール)のグループ化のことで、サイト訪問者へのコンテンツの配信に次のような影響を与えます。

- ディメンション・セットは、オンライン・サイトで有効にするロケールの指定を定義します。つまり、ディメンション・セットはコンテンツが訪問者に表示される際の言語を指定します。たとえば、あるディメンション・セットにはヨーロッパ言語が含まれ、他のセットにはアジア言語が含まれるなどです。

- ディメンション・セットは、ロケールに基づくコンテンツのフィルタリングを定義します。たとえば、訪問者がリクエストした時点でコンテンツが訪問者の希望言語で存在しない場合の処理方法などです。ディメンション・セットを配信システムに公開しない場合には、ロケールのフィルタリングは機能しません。ロケール・フィルタリングの詳細は、第30.2項「ロケール・フィルタリングでの作業」を参照してください。

注意:

ディメンション・セットは、WebCenter Sitesのユーザー・インタフェースの操作には影響を与えません。

オンライン・サイトの機能に対するロケール・フィルタリングでは、各ディメンション・セットで参照されている「ディメンション・セット」アセットと「ディメンション」アセットの両方を承認して配信システムに公開する必要があります。(参照されている「ディメンション」アセットは、それを参照する「ディメンション・セット」アセットに依存しているため、どちらもそれぞれの「ディメンション・セット」アセットで承認されている必要があります。)

30.1.3 サイト間の多言語サポート

複数のサイトで多言語サポートを設定している場合、次のいずれかのシナリオの実装を選択できます。

- ロケールは作成するが、ディメンション・セットは作成しない
このオプションを選択すると、コンテンツ・プロバイダは複数の言語でコンテンツを管理できますが、レンダリング時のロケール・フィルタリングは有効になりません。すべての必須言語での翻訳が最初から各アセットに存在している場合にのみ、このオプションを使用します。

- ロケールとディメンション・セットを作成し、それらをサイト間で共有する
このオプションには、複数のサイトで多言語サポートを有効にする最も簡単な方法が用意されています。この方法で設定したサイトでは、ディメンション・セットに格納されたプロパティ(オンライン・サイト上で表示が有効化されたロケール、ロケール・フィルタリング・メソッド、および該当する場合はレンダリング時のアセット翻訳を検索する際における階層フィルタのトラバース経路であるフォールバック階層)を共有します。詳細は、第30.2.2.3項「階層フィルタ」を参照してください。複数のターゲット・サイトにレプリケートする基本となるサイトを作成する場合には、ロケールのターゲット・サイトへの共有が最善の方法です。

- 各サイトに個別のロケールとディメンション・セットを作成する
このオプションでは、構成の複雑さが増加する分だけ、最高の柔軟性を得ることができます。サイトでこの方法を設定すると、ロケール・フィルタ・タイプやフォールバック階層などのプロパティを各サイトに合うよう調整できるというメリットがあります。

注意:

複数サイトで同一の言語を表すために「ディメンション」アセットの複製を作成できますが、不要な複雑さを招くため、お薦めしません。

- 最後の2つのオプションの混在
このオプションは、柔軟性と構成の複雑さのバランスが程よく取れています。可能なベスト・プラクティスとして、一意のロケールのプールを作成し、そのプールから各サイトで必要なロケールを共有し、必要に応じて各サイトでディメンション・セットを共有または作成するという方法があります。

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

アセットを初めてロケールに割り当てる際には、アセットはマスター・ステータスまたはディメンションの親ステータスを取得します。マスター・ステータスを使用すると、多言語セット(コンテンツが意味的に同一であっても異なった言語で存在する一連のアセット)を構成できます。(これは、ディメンション・セットとは同一でない点に注意してください。ディメンション・セットはオンライン・サイトとアセットがレンダリングされる方法にのみ影響を及ぼします。)

注意:

マスター・アセットとディメンションの親は同じものです。マスター・アセットはWebCenter Sitesのユーザー・インタフェースに表示されます。ディメンションの親はOracle Fusion Middleware WebCenter Sitesタグ・リファレンス、データベース表の名前(assetType_DimPなど)およびエレメント・コードで使用されます。

たとえば、「記事」アセットをアメリカ英語(en_US)として指定し、いずれかのロケールがサイトで有効になっている翻訳を作成した場合(フランス語(fr_CA)やドイツ語(de_DE)など)、翻訳はそれらのディメンションの親(アメリカ英語のアセット)を指し、それらのロケールとマスターが相互に同等な意味であることを示します。

マスター・ステータスでアセットの翻訳を作成すると、アセットがコピーされ、選択したロケールがコピーに割り当てられます。次に、翻訳済のコンテンツを入力して新しいアセットとしてその翻訳を保存します。

この時点で、ソース・アセットとその翻訳は多言語セットにリンクされ、翻訳にそのマスターとしてソース・アセットまたはディメンションの親が採用されます。マスターではないセットのメンバーにマスター・ステータスを指定できますが、マスターになることができるのは一度に1つのセット・メンバーのみです。

リンク付けは、アセット・タイプに対してassetType_DimP表を介して実現されます。この表には次の情報が格納されています。

- マスター(ディメンションの親)アセットのID

- 翻訳アセットのID

- その翻訳に割り当てられたロケール・ディメンション・アセットのID

WebCenter Sitesインタフェースでマスター・アセットまたはいずれかの既存の翻訳から翻訳の作成を開始できますが、多言語セットのすべての翻訳は常にディメンションの親(マスター)アセットを指しています。

注意:

ロケールを意識したアセットがリビジョン追跡されている場合、アセットのロケール・データへの変更(ロケール指定やマスター・ステータスなど)により新しいバージョンのアセットは生成されません。

30.1.5 翻訳およびアセット関係

アセットが翻訳される際にアセット関係を処理する方法の要約は、次の表のとおりです。

関係のタイプ

動作

アソシエーション

アソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

コレクション

コレクション・アセットの翻訳を作成すると、新しいコレクション・アセットはソース・アセットのメンバー・アセットを保持します。次に、メンバー・アセットを翻訳し、翻訳済バージョンを新しいコレクション・アセットに格納して、古いコレクションから引き継いだメンバー・アセットを置き換えることができます。

静的リスト推奨

新しい言語バージョンの静的リスト推奨を作成すると、新しい推奨アセットには、ソース・アセットのメンバー・アセットが保持されます。次に、メンバー・アセットを翻訳し、翻訳済バージョンを新しい推奨アセットに格納して、古いコレクションから引き継いだメンバー・アセットを置き換えることができます。

動的リスト推奨

動的リスト推奨はエレメント・コードで移入されるため、影響を受けません。

関連アイテム推奨

関連アイテムのアソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

アセット・タイプの属性

アセット・タイプの属性によるアソシエーションが含まれているアセットを翻訳すると、ソース・アセットに関連付けられているすべてのアセットが、自動的に翻訳と関連付けられます。その後、関連付けられたアセットを翻訳して、その翻訳済のバージョンを翻訳済の親アセットと関連付けるかどうかを選択できます。

埋込みリンク

埋込みリンクは影響を受けません。埋込みリンクを含むアセットが翻訳されるとは、リンク対象のコンテンツの対応する翻訳(存在する場合)を指すように、リンクを手動で更新する必要があります。

レンダリング時のアセット関係の処理の詳細は、第30.2項「ロケール・フィルタリングでの作業」を参照してください。

30.1.6 承認依存性

あるアセットの編集により別の承認ステータスが変更される場合、2つのアセット間には承認依存性が存在します。ローカライズ済アセットに影響を与える承認依存性の要約は、次の表のとおりです。

依存性

アセット承認への影響

Exists依存性は、ローカライズ済アセットと割り当てられたロケールを示す「ディメンション」アセットの間に存在します。

ローカライズ済アセットの公開を承認するには、対応する「ディメンション」アセットも承認されている必要があります。

多言語セットでは、マスター・アセットとそれにリンクされている各翻訳間にExists依存性が存在します。

アセットの最初の翻訳を作成する場合には、アセットとその翻訳の両方を承認する必要があります。

翻訳を承認するには、マスター・アセットが承認済の場合を除いて、対応するマスター・アセットも承認する必要があります。

次の場合には、すべてのメンバーを再承認する必要があります。

- 新規翻訳をセットに追加したり、既存の翻訳をセットから削除する場合。

- セットのマスター・アセットを編集する場合。

- セットの別のメンバーをマスターとして指定する場合。

Exists依存性は、「ディメンション・セット」アセットとそのディメンション・セットで有効化されているロケールを示す「ディメンション」アセットの間に存在します。

ディメンション・セットを承認するには、対応する「ディメンション」アセットも承認されている必要があります。

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

理想的には、多言語サイトは起動される前にそのコンテンツに関して全部そろっていることが望ましいです。つまり、すべてのアセットとそれらの関連事項が必要な言語ですべて存在しているのが理想です。しかし、多くの場合、そうではありません。そのような場合、ロケール・フィルタを使用して、訪問者が指定した環境と言語プリファレンスに応じて、レンダリング時にサイトに表示されるアセットの言語バージョンを決定します。たとえば、リクエストされたアセットがリクエストされた言語に存在しない場合、ビジネス・ロジックに対応を決定するように指定できます。

ロケール・フィルタリングを使用して、元のコンテンツがオンライン・サイトに公開された後に、リクエストされた翻訳の作成をコンテンツ・プロバイダに許可することで、編集作業を徐々に広げていくことができます。ロケール・フィルタリングにより、欠落した翻訳が配信システムに公開されたらただちにサイトで自動的にそれらをピックアップできます。

ロケール・フィルタリングにより配信システムで追加のロードが取り込まれる点に留意してください。追加のロードの容量は、フィルタリング・ロジックの複雑度に応じて異なります。

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

- 第30.2.1項「ロケール・フィルタリングによるアセット関係の処理」

- 第30.2.2項「含まれるロケール・フィルタ」

- 第30.2.3項「カスタム・ロケール・フィルタ」

- 第30.2.4項「構成依存性」

- 第30.2.5項「サイトへのフィルタリング・サポートの追加」

30.2.1 ロケール・フィルタリングによるアセット関係の処理

ロケール・フィルタリングの実装を選択する方法は、サイトのアセット関係を構造化する方法に影響を与えますし、オンライン・サイトの動作の方法に応じて、その逆もあります。

次のオプションのいずれかの実装を選択できます。

- 各ロケールに対して異なるアセット関係のツリーを保持する
アセットのレンダリング時に、このモデルはリクエストされたアセットに関連付けられたどのようなアセットでもレンダリングします。

たとえば、英語とフランス語のアセットが存在し、バージョンごとに関連付けられたアセットの一意のセットが存在する場合、各バージョンは関連付けられた個別のアセットにレンダリングされます。フィルタリングは、訪問者が指定した言語プリファレンスと一致するリクエスト済アセットのバージョンを検索して配信する場合のみ使用されます。関連付けられたアセットは、すべての必要な言語に翻訳されていると見込まれています。

このモデルでは、各言語に対して完全に独立したコンテンツが許可されます。このモデルをFirst Site IIサンプル・サイトで使用します。

- 同じアセット関係ツリーをすべてのロケールに使用する
アセットのレンダリング時に、このモデルは、訪問者が指定する言語プリファレンスとは無関係に、リクエストされたアセットのうち関連付けられたアセットを、リクエストされたアセットの特定言語バージョンと関連付けられたアセットに置換します。

たとえば、英語とフランス語のアセットが存在し、バージョンごとに関連付けられたアセットの一意のセットが存在する場合、訪問者が言語プリファレンスでフランス語を指定すると、フィルタリングはリクエストされたアセットのフランス語バージョンを検索して配信しますが、フランス語バージョンの関連付けられたアセットのかわりに英語バージョンの関連付けられたアセットに置換されます(フィルタリングが関連付けを導出する言語バージョンは英語であるという仮定により)。

このモデルでは、すべての言語間で確実にコンテンツが一貫しています。

- 上記の2つのモデルの混在
サイトに最大量の柔軟性とカスタマイズが許可されます。2つのモデル間の最適の比率は、サイトで対象とする動作に応じて異なります。

30.2.2 含まれるロケール・フィルタ

WebCenter Sitesでは次のロケール・フィルタが提供されています。

- 簡易フィルタ

- 簡易参照フィルタ

- 階層フィルタ(フォールバック・フィルタともいう)

必要に応じて、カスタム・ロケール・フィルタ実装のオプションもあります。カスタム・フィルタの詳細は、第30.2.3項「カスタム・ロケール・フィルタ」を参照してください。

実装を選択したフィルタのタイプに応じて、フィルタの対象となるアセットは次の条件のうちの1つまたは両方を満たしている必要があります。

- アセットには、割り当てられたロケールが指定されている必要があります。ロケールの指定がないアセットは、ロケール・フィルタで無視されます。

- 相互の翻訳であるアセットは、多言語セットにリンクされている必要があります(マスター・アセットによって相互の翻訳として指定されます)。そうでない場合は、フィルタは必要な翻訳の検索を実行できません。

30.2.2.1 簡易フィルタ

簡易フィルタは、コンテンツが複数の言語で存在しているサイトで、1つの言語のみでレンダリングされる場合に選択できます。フィルタでは次がチェックされます。

- 要求されたアセットが訪問者によって指定された言語のものであるかどうか

- アセットのロケールがサイトのディメンション・セットにリストされているかどうか

両方の条件に一致していると、フィルタはレンダリング用のテンプレートにアセットを渡します。そうでない場合にはレンダリングされません。

簡易フィルタでは、配信システムのパフォーマンスへの影響は最小になりますが、作業する必要のある編集作業量が増加します。アセットは必要な言語バージョンで存在する必要があり、そうでないとオンライン・サイトに表示されないためです。

30.2.2.2 簡易参照フィルタ

簡易参照フィルタは、1言語でのみレンダリングする必要のあるサイトで、複数言語でコンテンツが存在している可能性があっても、レンダリング時にすべての必要な翻訳が存在している保証のないサイトで理想的です。フィルタでは次がチェックされます。

- 要求されたアセットが訪問者によって指定された言語のものであるかどうか

- アセットのロケールがサイトのディメンション・セットにリストされているかどうか

リクエストされたアセットが訪問者の希望した言語で存在しない場合には、フィルタはアセットの翻訳をチェックして適切な代替アセットを検索します。フィルタが一致する翻訳を検出した場合には、それをテンプレートに渡します。そうでない場合には、レンダリングされません。(翻訳のロケールがサイトのディメンション・セットに存在しない場合にも、フィルタは何も返しません。)

このフィルタでは、パフォーマンスと機能性の間の合理的なバランスが提供されます。検索の問合せにより配信システムへの負荷は多少増加しますが、アセット作成のための編集作業の量は軽減されます。必要な翻訳は、元のコンテンツがオンライン・サイトに公開された後で作成できるためです。欠落した翻訳が配信システムに公開されると、検索メカニズムがただちにそれらをピックアップします。

FirstSiteIIサンプル・サイトでは、このフィルタがデフォルト・ロケール・フィルタとして使用されています。

30.2.2.3 階層フィルタ

階層フィルタは、リクエストされたアセットのロケールが訪問者によりリクエストされたロケールと一致しているかどうかをチェックします。ロケールが一致しない場合、フィルタはアセットの翻訳をチェックして、適切な代替の翻訳が存在しないか確認します。フィルタが一致する翻訳を検出した場合、それをテンプレートに渡します。検出しない場合には、サイトのディメンション・セットを構成する際に設定したフォールバック階層に従って、リクエストされたアセットの翻訳に置換します。フォールバック階層では、フィルタがリクエストされたアセット用に置換する必要のある言語バージョンとその順番が指定されます。

たとえば、次の階層について見てみましょう。

- · en_US(アメリカ英語)

- · de_DE(独語)

- · de_CH(スイス独語)

- · de_AT(オーストリア独語)

- · fr_FR(仏語)

- · fr_BE(ベルギー仏語)

- · fr_CA(カナダ仏語)

- · en_UK(イギリス英語)

この例では、訪問者がスイス独語(de_CH)のアセットをリクエストした場合、フィルタはアセットの翻訳を検索してアセットのスイス独語バージョンを検出すると、そのバージョンをテンプレートに渡します。フィルタがスイス独語バージョンを検出できない場合、階層パス内でその次に最適なロケールの独語(de_DE)にフォールバックします。同様に独語の翻訳が存在しない場合、フィルタはツリーの最上階に達するまで指定されたパスを階層内で追跡します。そのプロセスで一致が検出されない場合は、何もレンダリングされません。

前述の例では、訪問者が単一の希望言語を指定する場合について説明しました。ユーザーが複数の希望言語を指定する場合(通常、順序付けられたリストのフォームで)、フィルタは訪問者の最も希望する言語に対するフォールバック階層で一致する検索を試行します。一致が検出されない場合には、フィルタはフォールバック階層で一致が検出されるまで、訪問者のリストで次の言語をチェックします。その場合、前述のように、フィルタは一致するロケールからフォールバック・ツリーの最上位までパスを追跡して、リクエストされたアセットの翻訳の置換を試行します。

たとえば、ユーザーの希望する言語が日本語、仏語、英語(その順番で希望)だとすると、フィルタはフォールバック階層で日本語の検出を試行します。日本語が階層に存在しない場合には、次に仏語の検出が試行されます。仏語は階層に存在するので、仏語からツリーのルート・ノードへのパスが追跡され、この項で前述した例のように、そのパスに従って置換が施行されます。

階層フィルタは強力で便利ですが、次のような欠点があります。

- 追加のデータベース問合せは、フィルタの負担が配信システムのパフォーマンスにかかります。パフォーマンス・ヒットを最小限にするには、できるだけ多くの必要な言語がコンテンツに存在するように編集して、フィルタのアクティビティを最小限にする必要があります。(別のフィルタの使用を選択することも可能です。)

- オンライン・サイトに表示するアセットに対するコントロールは、もっぱらサイト開発者や管理者の手にゆだねられます。これは、フィルタが、サイトへの訪問者が指定するプリファレンスの順ではなく(各訪問者からの複数言語のプリファレンスを受け入れるようにサイトが設定されていると仮定して)、ディメンション・セットで構成されたフォールバック・ツリーを追跡するためです。

30.2.3 カスタム・ロケール・フィルタ

サイトの設計に応じて、カスタム・フィルタの作成を決定できます。たとえば、サイトの設計により、ディメンション・セットで定義されたフィルタではなく、訪問者が指定するロケールの優先度を優先的に選択する階層(フォールバック)フィルタがコールされるとします。そのような場合は、「ディメンション・セット」アセットの「編集」フォームのフィールドで、カスタム・フィルタ・クラスを指定できます。

30.2.4 構成依存性

サイトにロケール・フィルタリングを組み込むことを決定した場合、結果として導入される追加の構成の依存性を説明する必要があります。構成の依存性によって、ページが配信システムでキャッシュされる方法が指定されます。

30.2.4.1 アセットの検索連鎖

ロケール・フィルタリングを使用してアセットの翻訳を検索する場合、検索プロセス時にロードされるアセットに基づいて、次のファクタがページのキャッシュ方法を指定します。

- 採用されるフィルタリング・ロジック

- 検索リクエスト元からのページとアセット

- 訪問者が指定する言語プリファレンス

リクエストされたアセットを含むキャッシュ済ページは、検索プロセス時にロードされたすべてのアセットに依存します。したがって、検索プロセス時にロードされたアセットが変更されると、影響を受けたページがキャッシュからフラッシュされます。

たとえば、簡易参照フィルタと次の多言語セットについて見てみましょう。

· en_US(マスター)

- · fr_FR(翻訳)

- · de_DE(翻訳)

訪問者が仏語バージョンを含むページをリクエストしているが、その訪問者の言語プリファレンスが独語の場合、検索連鎖は次のようになります。

fr_FR > en_US > de_DE

この例では、フィルタはまず仏語バージョンにリンクされたマスター・アセットをロードし、次にそのマスター・アセットを使用して独語バージョンを検索するため、3つのアセットがすべてロードされます。したがって、これら3通のアセットのいずれかが変更されると、影響を受けたページがキャッシュからフラッシュされます。

他方、ユーザーがセットのマスター・アセットであるアメリカ英語バージョンをリクエストすると、検索連鎖はもっと短くなります。

fr_FR > en_US

この場合、仏語バージョンとアメリカ英語バージョンがロードされますが、独語バージョンはロードされません。したがって、独語バージョンを変更すると、対応するページがキャッシュからフラッシュされますが、仏語バージョンやアメリカ英語バージョンを変更してもフラッシュされません。

WebCenter Sitesに含まれるロケール・フィルタで採用される検索メカニズムの詳細は、第30.2.2項「含まれるロケール・フィルタ」を参照してください。

第30.2.4.2項「キャッシング・ルール」では、多言語アセットに適用されるキャッシング・ルールについて説明します。

30.2.4.2 キャッシング・ルール

翻訳が検索されて影響を受けるページがキャッシュされると、次のいずれかが発生するたびにページがキャッシュからフラッシュされます。

- 新しい言語が多言語セットに追加された

- ページのレンダリング時に検索連鎖の一部だった翻訳が編集された

- 多言語セットのメンバーの翻訳が削除された

- セットのマスター・アセットが編集された

- セットの別のメンバーがマスターとして指定された

30.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のコードを調べることをお薦めします。

30.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"/>

30.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>

30.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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。さらに、FirstSiteIIサンプル・サイトのコードを調べて、多言語サポートを実装する方法を確認してください。

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

多言語サポートのサイトの構成を開始する前に、次の前提条件が満たされているか確認します。これらの決定事項についてサイト管理者と合意しておくことがベストです。

1. 所属する組織のコンテンツ管理のニーズに基づいて、最初にサイト(複数可)に実装する言語の数を決定します。次のいずれかを実行できます。

- サイト(複数可)を作成して最初に単一言語をサポートし、必要に応じてその他の言語のサポートを追加する。

- 前もってすべてのサイトで取り込む言語すべてを計画し、適切なロケールを作成しておく。

2. 既存のロケールとディメンション・セットを新しいサイト(複数可)で共有するか、個別のものを作成するかを決定します。詳細は、第30.1.3項「サイト間の多言語サポート」を参照してください。

3. アセット関係をロケールの観点でレンダリング時に処理する方法を決定し、その決定に合ったロケール・フィルタリング・メソッドを選択します。この選択事項は、必要とするレベルのオートメーション、配信システムのパフォーマンスおよび編集の作業負荷の間のバランスをうまくとる必要があるため、サイトの管理者と合意しておくことがベストです。詳細は、第30.2項「ロケール・フィルタリングでの作業」を参照してください。次の事項に注意してください。

- 別のフィルタリング・メソッドには、配信システムへのパフォーマンス・ヒットを犠牲にした異なったレベルのオートメーションが用意されています。フィルタが複雑になればなるほど、パフォーマンス・ヒットは高くなります。たとえば、簡易参照フィルタには階層フィルタより高いパフォーマンスが備わっています。

- 実装するフィルタリング・メソッドに応じて、サイト・コンテンツへの編集作業は徐々に広げていくことができます。オリジナル・コンテンツが作成されてライブ・サイトに公表された後で、翻訳を作成できます。実装するフィルタリング・ロジックは、必要とされる言語バージョンで存在していないコンテンツに対して実行する手順を決定します。

4. 単一言語サイトを多言語サイトに変換する場合には、デフォルト・ロケールをサイトのアセットに割り当てる際に使用するエレメント・コードを取得します。FirstSiteIIサンプル・サイトに基づいたサンプル・コードは、第30.4.10.1項「デフォルト・ロケールの一括割当て用サンプル・エレメント・コード」に記載されています。

注意:

多言語セットを備えたサイトをレプリケートする場合、マスター・アセットがターゲット・サイトで(共有またはコピーのいずれかにより)使用できることを確認してください。使用できない場合は、セット・メンバーはターゲット・サイトの相互の翻訳にリンクされなくなります。

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

この項では、多言語サポートのサイトを構成する際に必要な手順を説明します。

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

- 第30.4.1項「構成のクイック・リファレンス」

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

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

- 第30.4.4項「ロケールの作成」

- 第30.4.5項「ロケールの別のサイトへの共有」

- 第30.4.6項「ディメンション・セットの作成と構成」

- 第30.4.7項「ディメンション・セットの別のサイトへの共有」

- 第30.4.8項「ロケール・フィルタの構成」

- 第30.4.9項「階層フィルタのフォールバック階層の構成」

- 第30.4.10項「デフォルト・ロケールのサイト内アセットへの一括割当て」

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

この項では、サイトの多言語サポートの構成に必要な手順の概要を述べます。構成プロセスの際には、このリストをクイック・リファレンスとして使用してください。

サイトの多言語サポートを構成するには

1. 必要な決定と準備を行います。詳細は、第30.3項「サイトに対する多言語サポートの計画」を参照してください。

2. 「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプをサイトで有効にします。手順は、第30.4.2項「「ディメンション」アセット・タイプおよび「ディメンション・セット」アセット・タイプの有効化」を参照してください。

3. 「ディメンション」アセット・タイプの「ロケール」サブタイプをサイトで有効にします。手順は、第30.4.3項「「ディメンション」アセット・タイプの「ロケール」サブタイプの有効化」を参照してください。

4. 目的のロケールを作成または共有します。手順は、次の各項を参照してください。

- 新規ロケールの作成は、第30.4.4項「ロケールの作成」を参照してください。

- 既存ロケールの共有は、第30.4.5項「ロケールの別のサイトへの共有」を参照してください。

新規ロケールの作成か既存ロケールの共有のいずれかを決定する際のヘルプは、第30.1.3項「サイト間の多言語サポート」を参照してください。

5. ディメンション・セットを作成または共有します。手順は、次の各項を参照してください。

- 新規ディメンション・セットの作成は、第30.4.6項「ディメンション・セットの作成と構成」を参照してください。

- 既存ディメンション・セットの共有は、第30.4.7項「ディメンション・セットの別のサイトへの共有」を参照してください。

新規ディメンション・セットの作成か既存ディメンション・セットの共有のいずれかを決定する際のヘルプは、第30.1.3項「サイト間の多言語サポート」を参照してください。

6. (オプション)既存の単一言語サイトを多言語サイトに変換する場合、デフォルトのロケールをサイトの各アセットに割り当てるエレメント・コードを実行します。手順については、第30.4.10項「デフォルト・ロケールのサイト内アセットへの一括割当て」を参照してください。この項には、サイトでカスタマイズできるサンプル・コードが記載されています。

7. サイトで使用するテンプレートを変更して、ディメンション・セットの構成時に選択したロケール・フィルタのサポートを追加します。このプロセスの概要は、第30.2.5項「サイトへのフィルタリング・サポートの追加」を参照してください。

注意:

ロケール・フィルタリング以外にも、次のサイト機能を実装する必要があります。

- 訪問者の言語プリファレンスの指定を許可する

- 訪問者の言語プリファレンスをサイト全体に伝搬する(サイトのすべてのテンプレートに渡す)

- セッションの間、訪問者の言語プリファレンスを維持する

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

サイトで「ディメンション」アセットと「ディメンション・セット」アセットを作成する前に、対応するアセット・タイプとサブタイプを有効化する必要があります。この手順では、「ディメンション」アセット・タイプと「ディメンション・セット」アセット・タイプをサイトで有効にする方法を説明します。次の手順では、サイトで「ディメンション」アセット・タイプの「ロケール」サブタイプを有効にする方法を説明します。

サイトで「ディメンション」アセット・タイプと「ディメンション・セット」アセット・タイプを有効にするには

1. WebCenter Sitesインタフェースにログインして、アセット・タイプを有効化するサイトを選択します。

2. Adminインタフェースを選択します。

3. ツリーで、「管理」タブを選択します。

4. 「管理」タブで、次の階層をドリル・ダウンします。

1. 「サイト」ノードを開きます。

2. 「サイト」ノードで、目的のサイトに対応するノードを開きます。

3. 必要なサイト・ノードで、「アセット・タイプ」ノードを開きます。

4. 「アセット・タイプ」ノードで、「有効化」ノードをダブルクリックします。

WebCenter Sitesに「アセット・タイプの有効化」フォームが表示されます。

5. 「アセット・タイプの有効化」フォームで、「ディメンション」アセット・タイプと「ディメンション・セット」アセット・タイプの隣にあるチェック・ボックスを選択します。

6. 「アセット・タイプの有効化」をクリックします。
WebCenter Sitesに「スタート・メニューの選択」フォームが表示されます。

7. 「スタート・メニューの選択」フォームで、すべてのチェック・ボックスを選択し、「アセット・タイプの有効化」をクリックします。
WebCenter Sitesにアセット・タイプがサイトで有効化されたことを確認するメッセージが表示されます。

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

ロケールをサイトのアセットに割り当てる前に、サイトで「ディメンション」アセット・タイプの「ロケール」サブタイプを有効化する必要があります。

サイトで「ディメンション」アセット・タイプの「ロケール」サブタイプを有効化するには

1. WebCenter Sitesインタフェースにログインして、サブタイプを有効化するサイトを選択します。

2. Adminインタフェースを選択します。

3. ツリーで、「管理」タブを選択します。

4. 「管理」タブで、次の階層をドリル・ダウンします。

1. 「アセット・タイプ」ノードを開きます。

2. 「アセット・タイプ」ノードで、「ディメンション」ノードを開きます。

3. 「ディメンション」ノードで、「サブタイプ」ノードをダブルクリックします。

WebCenter Sitesに「アセット・タイプのサブタイプ: ディメンション」フォームが表示されます。

5. フォームで、「ロケール」サブタイプの隣にある「編集」(鉛筆)アイコンをクリックします。
WebCenter Sitesに「ディメンション・サブタイプの編集: ロケール」フォームが表示されます。

6. 「サイト」フィールドで、「ロケール」サブタイプを有効にするサイトを、[Ctrl]キーを押しながらクリックします。

注意:

既存のサイトの選択をそのままにするには、サイト名を[Ctrl]キーを押しながらクリックする必要があります。単にサイト名をクリックした場合は、他の選択済サイト(ある場合)の選択が解除されます。

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

30.4.4 ロケールの作成

新規ロケールをサイトに追加するには、次の手順を実行して、目的のロケールを示す「ロケール」サブタイプの「ディメンション」アセットを作成します。

注意:

作成するロケールがWebCenter Sitesシステムの別のサイトにある「ディメンション」アセットで示されている言語を指定する場合、その言語を示す既存の「ディメンション」アセットを現在のサイトで共有して冗長性を回避します。

ロケールを作成するには

1. ボタン・バーで、「新規」をクリックします。

2. アセット・タイプのリストで、「新規ディメンション」を選択します。

3. WebCenter Sitesに「新規ディメンション」フォームが表示されます。

4. 「新規ディメンション」フォームで、次の手順を実行します。

1. 「名前」フィールドに、そのロケールの説明的な名前を入力します。ベスト・プラクティスとして、次の表記規則を使用することをお薦めします。
xx_YY

ここで:

- xxは2文字のISO 639-1言語コード(仏語の場合はfr)

- YYは2文字のISO国コード(カナダの場合はCA)

前述の例をまとめると、名前fr_CAはカナダ仏語を示します。

1. 「説明」フィールドに、このロケールが表す言語の説明を入力します。

2. 「サブタイプ」ドロップダウン・リストで、「ロケール」を選択します。

3. 「保存」をクリックします。

30.4.5 ロケールの別のサイトへの共有

ロケールを別のサイトで共有するには、対応する「ディメンション」アセットを共有する必要があります。

ロケールを別のサイトで共有するには

1. WebCenter Sitesインタフェースにログインして、共有するロケールに対する「ディメンション」アセットが存在するサイトを選択します。

2. Adminインタフェースを選択します。

3. 目的の「ディメンション」アセットを検索し、その「調査」フォームを開きます。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、「ディメンションの検索」を選択します。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的のアセットに移動して名前をクリックします。
アセットが「調査」フォームで表示されます。

4. アクション・バーで、「ディメンションの共有」を選択します。
WebCenter Sitesに「ディメンションの共有」フォームが表示されます。

5. 「ディメンションの共有」フォームで、「ディメンション」アセットを共有するサイトの隣にあるチェック・ボックスを選択します。(アセットをWebCenter Sitesシステム上のすべてのサイトで共有するには、「すべてのサイト」チェック・ボックスを選択します。)

6. 「変更の保存」をクリックします。

7. 選択したサイトでアセットが使用可能になったことを示すメッセージが表示されます。

30.4.6 ディメンション・セットの作成と構成

新規ディメンション・セットを作成して構成するには

1. 次の手順に従って、ディメンション・セットに追加する「ディメンション」アセット(ロケール)をブックマークに追加します。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「ディメンションの検索」をクリックします。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的の「ディメンション」アセットに移動して、チェック・ボックスを選択します。

5. 「ブックマークに追加」をクリックします。

2. 次の手順に従って、ディメンション・セットを作成して構成します。

1. ボタン・バーで、「新規」をクリックします。

2. 「新規」アセット・リストで、「新規ディメンション・セット」を選択します。
WebCenter Sitesに「新規ディメンション・セット」フォームが表示されます。

3. 「名前」フィールドに、そのディメンション・セットを説明する名前を入力します。

4. ツリーで、「ブックマーク」タブを選択します。

5. 「ブックマーク」タブで、ディメンション・セットに追加するロケールを選択し、「選択したアイテムの追加」をクリックします。追加するロケールごとに、この手順を繰り返します。

6. 「ディメンション・フィルタ・クラス」フィールドで、目的のロケール・フィルタ・タイプを選択します。「詳細」オプションを選択すると、カスタム・フィルタ・クラスを指定できます。
ロケール・フィルタ・タイプの詳細は、第30.2項「ロケール・フィルタリングでの作業」を参照してください。

7. (オプション)手順2で「詳細」を選択した場合は、表示されたテキスト・ボックスにカスタム・フィルタ・クラスの名前を入力します。

8. 終了したら、「変更の保存」をクリックします。

9. (オプション)手順2で階層フィルタを選択した場合は、第30.4.9項「階層フィルタのフォールバック階層の構成」の手順を完了して、フィルタのフォールバック階層を構成します。

30.4.7 ディメンション・セットの別のサイトへの共有

ディメンション・セットを別のサイトへ共有させるには、対応する「ディメンション・セット」アセットを共有する必要があります。

ディメンション・セットを別のサイトへ共有させるには

1. WebCenter Sitesにログインし、共有する「ディメンション・セット」アセットが存在するサイトを選択します。

2. Adminインタフェースを選択します。

3. 目的の「ディメンション・セット」アセットを検索し、その「調査」フォームを開きます。

1. ボタン・バーで、「検索」をクリックします。

2. アセット・タイプのリストで、「ディメンション・セットの検索」を選択します。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的のアセットに移動して名前をクリックします。
アセットが「調査」フォームで表示されます。

4. アクション・バーで、「ディメンション・セットの共有」を選択します。
WebCenter Sitesに「ディメンション・セットの共有」フォームが表示されます。

5. 「ディメンション・セットの共有」フォームで、「ディメンション・セット」アセットを共有するサイトの隣にあるチェック・ボックスを選択します。(アセットをWebCenter Sitesシステム上のすべてのサイトで共有するには、「すべてのサイト」チェック・ボックスを選択します。)

6. 「変更の保存」をクリックします。

7. 選択したサイトでアセットが使用可能になったことを示すメッセージが表示されます。

30.4.8 ロケール・フィルタの構成

通常、サイトにディメンション・セットを作成する際にロケール・フィルタを構成します。既存のディメンション・セットのロケール・フィルタの構成を変更するには、次の手順を実行します。

ロケール・フィルタを構成するには

1. 構成するロケール・フィルタのディメンション・セットを検索して、「調査」フォームで開きます。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「ディメンション・セットの検索」をクリックします。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的のアセットに移動して名前をクリックします。
アセットが「調査」フォームで表示されます。

2. 「ディメンション・フィルタ・クラス」フィールドで、目的のフィルタ・タイプの隣にあるオプションを選択します。「詳細」オプションを選択すると、カスタム・フィルタ・クラスを指定できます。

ロケール・フィルタの詳細は、第30.2項「ロケール・フィルタリングでの作業」を参照してください。

3. (オプション)手順2で「詳細」を選択した場合は、表示されたテキスト・フィールドにカスタム・フィルタ・クラスの名前を入力します。

4. 「変更の保存」をクリックします。

5. (オプション)手順2で階層フィルタを選択した場合は、第30.4.9項「階層フィルタのフォールバック階層の構成」の手順を完了して、フィルタのフォールバック階層を構成します。

30.4.9 階層フィルタのフォールバック階層の構成

ディメンション・セットの構成時に階層(フォールバック)ロケール・フィルタを選択した場合は、次の手順を実行して、フィルタのフォールバック階層を構成します。

階層ロケール・フィルタのフォールバック階層を構成するには

1. 新規ロケールを追加したり、既存ロケールをフォールバック階層で並べ替える場合、次の手順に従って、階層に追加するロケールを表す「ディメンション」アセットをブックマークに追加します。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「ディメンションの検索」をクリックします。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的の「ディメンション」アセットに移動して、チェック・ボックスを選択します。

5. 「ブックマークに追加」をクリックします。

2. 「調査」フォームで、構成する階層フィルタが存在するディメンション・セットを検索して開きます。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「ディメンション・セットの検索」をクリックします。

3. 目的の検索条件(ある場合)を指定して、「検索」をクリックします。

4. 検索結果のリストで、目的の「ディメンション・セット」アセットに移動して、ハイパーリンク名をクリックします。
「調査」フォームに「ディメンション・セット」アセットが表示されます。

3. フォールバック階層を構成します。

注意:

フォールバック階層を構成するときには、次の点に注意してください。

- ロケールは、フォールバック階層に1回のみ表示できます。

- 階層からロケールを削除する必要がある場合は、ロケール・ノードの隣にある「削除」(ゴミ箱)アイコンをクリックします。

- 階層内のロケールの位置を変更する必要がある場合は、そのロケールを削除して、目的の親ノードの下に追加します。

1. 「ディメンション・フィルタ・クラス」フィールドで、「ロケール階層の構成」をクリックします。
WebCenter Sitesに「ロケール階層の構成」フォームが表示されます。

2. 「ロケール階層の構成」フォームで、「編集」をクリックします。
WebCenter Sitesにフォームの編集可能バージョンが表示されます。

3. ツリーで、「ブックマーク」タブを選択します。

4. (オプション)階層が空白の場合には、「ブックマーク」タブでフォールバック階層の最上位ノードとして指定するロケールを選択し、「選択したアイテムの追加」をクリックします。

5. 階層に追加するロケールの親ノードを選択します。

スクラッチから階層を作成する場合は、選択できるのは、手順dで追加した最上位レベルのノードのみです。

階層作成時には、フォールバック・プロセスが発生していく方向(最も特殊なものから最も特殊でないものへという方向、つまりツリーのルート・ノード方向)に注意してください。

6. 「ブックマーク」タブで、手順eで選択した親ノードの下に表示するロケールを選択して、「選択したアイテムの追加」をクリックします。

7. 階層に追加するロケールごとに、手順eとfを繰り返します。

8. フォールバック階層が完了したら、「変更の保存」をクリックします。

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

単一言語サイトから多言語サイトへ変換している場合、デフォルト・ロケールをサイト内のすべてのアセットに割り当てる必要があります。これを迅速に実現させるには、デフォルト・ロケールをアセットに割り当てるエレメントを実行します。

注意:

この手順のサンプル・エレメント・コードは、第30.4.10.1項「デフォルト・ロケールの一括割当て用サンプル・エレメント・コード」を参照してください。サンプル・コードは例として記載されているため、実際のサイトではカスタマイズする必要があります。

デフォルト・ロケールをサイト内アセットへ一括して割り当てるには

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アセットの名前です。

エレメント・コードが実行を完了したら、アセットに目的のロケールが割り当てられていることを確認してください。割り当てられていない場合は、エレメント・コードの考えられるエラーをチェックします。

30.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>

31 配信システムにおけるユーザー管理

WebCenter Sitesでは、USERタグによる認証機能、DIRタグによるユーザー・プロファイル管理が用意されており、アクセス制御リスト(ACL)によりデータベース表およびレンダリングされたページのセキュリティが強化されています。これらのユーザー管理とセキュリティのメカニズムを使用して、ユーザーを管理し、配信システムおよびWebCenter Sitesの開発システムと管理システムに対する訪問者のアクセスを制御します。

この章には次の項が含まれます。

- 第31.1項「ディレクトリ・サービスAPI」

- 第31.2項「訪問者のオンライン・サイトへのアクセスの制御」

- 第31.3項「ログイン・フォームの作成」

- 第31.4項「ユーザー・アカウント作成フォームの作成」

- 第31.5項「Burlington Financialサンプル・サイトにおける訪問者のアクセス」

31.1 ディレクトリ・サービスAPI

ディレクトリ・サービスAPIは、WebCenter Sitesシステムで認証情報、ユーザー情報などが格納されているディレクトリ・サーバーへの接続を有効化します。

WebCenter Sitesは3つのディレクトリ・サービスのプラグインを配信しており、そのうちの1つはWebCenter Sitesシステムがインストールされたときにインストールされています。

- WebCenter Sitesディレクトリ・サービス・プラグイン: ネイティブのWebCenter Sitesユーザー管理表(SystemUsers表およびSystemUserAttrs表)を使用します。

- LDAPプラグイン: 任意のJNDIサーバーをサポートします。

- NTプラグイン: ユーザー資格証明とログイン名はNTディレクトリから取得しますが、その他のすべてのユーザー情報はSystemUserAttrs表から取得します。

プラグインはWebCenter Sitesシステムのインストール時にインストールされ、構成するにはdir.iniファイルでプロパティを設定します。ユーザー管理設定の構成の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

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

- 第31.1.1項「エントリ」

- 第31.1.2項「階層」

- 第31.1.3項「グループ」

- 第31.1.4項「ディレクトリ・サービス・タグ」

- 第31.1.5項「ディレクトリの操作」

- 第31.1.6項「エラーの処理」

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

31.1.1 エントリ

ディレクトリのエントリは、割り当てられた属性(特にユーザーおよびグループ・タイプのエントリ)を備えた名前付きオブジェクトです。

- ユーザー・タイプ・オブジェクトには、識別名および一連の属性として一般名、ユーザー名、パスワード、電子メールなどが備わっています。

- WebCenter Sites ACLと同様、グループ・タイプ・オブジェクトにも識別名と一連の属性があります。

名前は関連付けられている階層を反映しています。ディレクトリ実装での移植性を確保するために、名前は不透明な文字列として処理する必要があります。

31.1.2 階層

一部のディレクトリ・データベースは、階層構造を使用してエントリを編成します。WebCenter Sitesのディレクトリ・サービスAPIでは、エントリの属性と階層内でのその場所は個別になっています。その結果、エントリの属性の取得によってその子の情報は発生しません。

階層に対するサポートは、基礎となるディレクトリの実装に応じて異なります。たとえば、LDAPディレクトリは階層構造をサポートしますが、WebCenter Sitesのネイティブ・ディレクトリ・データベースは階層構造をサポートしません。

ディレクトリ実装での移植性を確保するために、コードは階層データのサポートを想定していません。

グループ階層は、内部のWebCenter Sitesの権限に影響を及ぼしません。

31.1.3 グループ

WebCenter Sitesのディレクトリ・サービスAPIは、参照整合性を実行しません。ディレクトリ・タグを持つユーザーを削除する場合、アプリケーションでは、関連付けられたグループからの最初のユーザー削除によってグループ・メンバーシップも確実に削除される必要があります。

メンバーがグループに追加されるたびに、JNDI実装では、addmemberタグに渡される名前とは関係なく、uniquemember属性の値に対して完全に識別される名前が作成されます。

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

WebCenter Sitesでは、XMLおよびJSPの両バージョンで、ディレクトリ・サービスAPIの起動に使用できるDIRタグ・ファミリが配信されます。

DIRタグは、次のとおりです。

タグ

説明

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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。コード・サンプルは、第31.1.5.4項「ディレクトリ・サービスのコード・サンプル」を参照してください。

31.1.5 ディレクトリの操作

一部のWebCenter Sitesディレクトリ・サービスのタグは、データベースに情報を書き込みます。データベース管理者が、データベースへのユーザー情報の追加など、Webサイトへの書込み操作をすべて処理している場合、ディレクトリ・タグの使用を読取り専用の操作に制限します。
このポリシーによって、サードバーティのディレクトリ管理ツールとの同期化に関する問題が回避されます。

読取り専用操作については、この項で説明します。資格証明と現在の認証済ユーザーの読取り権限を使用して、操作を実行します。

31.1.5.1 検索

一部のディレクトリ・サーバーの制限のため、組織の最上位レベルからの検索は許可されていません。移植性の問題を回避するために、DIR.SEARCHタグのコンテキスト属性を必ず指定してください。

31.1.5.2 ルックアップ

ユーザーのルックアップには、通常、次の2つの手順を実行します。

1. エントリ名を取得するには、useridのDIR.SEARCHをコールします。

2. 問題のユーザーの属性を取得するには、DIR.GETATTRSをコールします。

31.1.5.3 ユーザーのリスト作成

ユーザーのリストを作成するには、次の3つの方法のいずれかを使用することをお薦めします。

- 小規模のユーザー・データベースの場合、DIR.LISTUSERSタグを使用します。これは、peopleParentプロパティに従ってすべてのユーザーのリストを再帰的に作成します。このタグの使用は、より大規模なユーザー・データベースでは非効率的です。

- より大規模なユーザー・データベースの場合、階層の移動にはDIR.CHILDRENタグを使用します。DIR.CHILDRENタグはグループ・タイプには最適ですが、ユーザー・タイプには適していません。

- フラットな階層を持つユーザー・データベースの場合、検索結果を絞り込みます。

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

次のJSPコード・サンプルは、可能なディレクトリ操作を示しています。

<%
String sMainTestUserName = "ContentServer";
String sMainTestUserPW="FutureTense";

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>

31.1.6 エラーの処理

どのディレクトリ・タグでも、設定時に様々なディレクトリ・エラーが発生する可能性があります。ディレクトリ・サービスのエラー・メッセージの包括的なリストは、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

ディレクトリ・サービスのコードによって、指定されたタグ・コールでリストされたそれぞれのエラー・コードが処理される必要があります。これは、J2EE JNDIインタフェースをサポートするために必要です。

31.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値はありません。

エラー・ロギングの詳細は、第10章「エラー・ロギングおよびデバッグ」を参照してください。

LDAP実装の共通の問題は、ディレクトリ・サーバーで誤って指定される権限です。エラー・ログが権限問題を示している場合には、ディレクトリ・サーバーの権限の設定をチェックして、認証されたユーザーがリクエストされた操作を実行する権限を持っていることを確認します。ディレクトリ・サーバーに直接ログインして(WebCenter Sites外)、権限が正しく設定されていることを確認するために同じアクションを実行します。ログと権限をチェックした後は、プロパティ・ファイルを調べることで、多くの場合構成エラーを解決できます。

プロパティの説明と値は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

31.2 訪問者のオンライン・サイトへのアクセスの制御

WebCenter Sitesは、アクセス制御リスト(ACL)でユーザーを管理します。ACLを使用すると、WebCenter Sitesデータベース内の表と、WebCenter Sitesによりサイトで処理したレンダリング済ページへのアクセスを制限できます。

訪問者がユーザー名とパスワードを使用してログインするオンライン・サイトを設計する場合、登録済訪問者を1つまたは複数のACLに関連付けることができます。

訪問者が最初にサイトを訪れると、WebCenter Sitesではセッションが作成され、その訪問者は標準デフォルト・ユーザーDefaultReaderとして暗黙的にログインされます。USER.LOGINコマンドが使用されて訪問者がパスワードで認証されると、訪問者のIDが更新されます(関連付けられたACLが有効になります)。

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

- 第31.2.1項「ACLタグ」

- 第31.2.2項「USERタグ」

- 第31.2.3項「WebCenter Sitesおよび暗号化」

31.2.1 ACLタグ

WebCenter Sitesには、ACLの作成に使用できる一連のアクセス制御リストのタグ(XMLおよびJSPの両バージョン)が用意されています。配信システムのWebCenter SitesインタフェースかWebCenter Sites ACLタグのいずれかを使用して、配信システムの訪問者アカウントで必要なACLを作成できます。

次の表は、ACLタグのリストです。

タグ

説明

ACL.CREATE

acl:create

ACLを作成します

ACL.DELETE

acl:delete

ACLを削除します

ACL.GATHER

acl:delete

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 Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

- ACL全般: 『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

31.2.2 USERタグ

WebCenter Sitesでは、ページでユーザーのログインおよびログアウトに使用する、次のUSERタグ(XMLおよびJSPの両バージョン)タグも用意されています。

USERタグは、次のとおりです。

タグ

説明

USER.LOGIN

user:login

ユーザーをログインさせます。

USER.LOGOUT

user:logout

ユーザーをログアウトさせます。

USER.SU

user:su

アカウント作成、ユーザー・プロファイルの編集などの操作を実行するために、特定のユーザーとしてユーザーをログインさせます。

これらのタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

31.2.3 WebCenter Sitesおよび暗号化

WebCenter Sitesには、パスワードやその他の機密関係の情報を暗号化するデフォルト・キーが用意されています。独自の暗号化キーを指定するには、UtilitiesクラスのencryptStringメソッドを使用します。暗号化を処理するJavaメソッドの情報は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

また、WebCenter SitesではSecure Sockets Layer (SSL)もサポートされており、これによってWebサーバーを出入りする情報の暗号化が許可されます。WebCenter SitesおよびSSLの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

31.3 ログイン・フォームの作成

この項では、訪問者にログインをプロンプトしてユーザー名とパスワードを認証するログイン・フォームのコード化の方法を示す、簡単なコード・サンプルについて説明します。

この例は、次のエレメントのコードを示しています。

- PromptForLogin: ユーザー名とパスワードをリクエストするフォームを表示するXMLエレメントです。

- Login: PromptForLoginエレメントから渡されるユーザー名とパスワードの組合せを認証するXMLエレメントです。

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

- 第31.3.1項「ログインのプロンプト(PromptForLogin.xml)」

- 第31.3.2項「ログイン・ページのルート・エレメント」

31.3.1 ログインのプロンプト(PromptForLogin.xml)

PromptForLoginエレメントは、訪問者にユーザー名とパスワードという2つの情報の入力を求めるフォームを表示します。

フォームを作成するコードは、次のとおりです。

<DIV ALIGN="center">
<FORM ACTION="ContentServer" METHOD="post">
<INPUT TYPE="hidden" NAME="pagename" VALUE="CSGuide/Security/Login"/>

<TABLE CELLPADDING="5" CELLSPACING="5">

<TR>
<TH ALIGN="right">Name</TH>
<TD><INPUT TYPE="text" NAME="username" SIZE="16"/></TD>
</TR>

<TR>
<TH ALIGN="right">Password</TH>
<TD><INPUT TYPE="password" NAME="password" SIZE="16"/></TD>
</TR>

<TR>
<TD>&nbsp;</TD>
<TD ALIGN="center"><INPUT TYPE="submit" NAME="doit" VALUE="Login"/></TD>
</TR>

</TABLE>

</FORM>
</DIV>

訪問者はフォームに記入して、「送信」ボタンをクリックします。フォームとLoginページ(前述の最初のinput type文を参照)のページ名で収集された情報がブラウザに送信されます。ブラウザからWebCenter Sitesにページ名が送信されると、WebCenter Sitesはその名前をSiteCatalog表で検索し、そのページ・エントリのルート・エレメントを起動します。

31.3.2 ログイン・ページのルート・エレメント

WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。Login pageのルート・エレメントは、Login.xmlエレメントです。

Loginエレメントは訪問者のログインを試行し、次に訪問者がいずれかの必須ACLを持っているかどうかを確認するUSERISMEMBERタグを使用して、訪問者を認証します。

このエレメントは、次の操作を実行します。

- USER.LOGINタグで訪問者をログインさせ、エラーがなかったかチェックします。

- ACLのリストを保持する変数リストを設定し、訪問者の資格証明を比較します。

- リスト変数に対する訪問者のACL割当てを、USERISMEMBERタグを使用してチェックします。

次のサンプル・コードは、訪問者を認証します。

<SETVAR NAME="errno" VALUE="0"/>

<USER.LOGIN USERNAME="Variables.username" PASSWORD="Variables.password"/>

<IF COND="Variables.errno=0">
<THEN>
<H3>Welcome <CSVAR NAME="Variables.username"/></H3>

<!-- Next, create a variable named aclToCheck and set it to hold the ACLs that the visitor needs to progress any further on the site. This variable can be set to one ACL or to a comma-separated list of ACLs, as in this example-->

<SETVAR NAME="aclToCheck" VALUE="ContentCustomer,SiteGod"/>
<SETVAR NAME="errno" VALUE="0"/>

<USERISMEMBER GROUP="Variables.aclToCheck"/>
<IF COND="Variables.errno=1">
<THEN>
<P>You are a member of the at least one of the following acls:
<CSVAR NAME="Variables.aclToCheck"/></P>
</THEN>
<ELSE>
<P>Sorry, you are not a member of any of the following acls:
<CSVAR NAME="Variables.aclToCheck"/></P>
</ELSE>
</IF>

</THEN>
<ELSE>

<H3>Sorry, can't find your credentials.</H3>

</ELSE>
</IF>

31.4 ユーザー・アカウント作成フォームの作成

この項では、訪問者に登録するようプロンプトするフォームのコード化の方法を示す簡単なコード・サンプルについて説明します。

この例は、次のエレメントのコードを示しています。

- PromptForNew Account: 使用するユーザー名とパスワードの入力を訪問者にリクエストするフォームを表示するXMLエレメント

- CreateAccount: 新規アカウントを作成するJSPエレメント

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

- 第31.4.1項「PromptForNewAccount」

- 第31.4.2項「CreateAccount Pageのルート・エレメント」

31.4.1 PromptForNewAccount

PromptForNewAccountエレメントは、ユーザー名とパスワードの入力と確認のためのパスワードの再入力を訪問者に求めるフォームを表示します。

フォームを作成するコードは、次のとおりです。

<div align="center">
<h3>Create a New Account</h3>
<FORM ACTION="ContentServer" METHOD="post">
<input type="hidden" name="pagename" value="CSGuide/Security/CreateAccount"/>

<table cellpadding="5" cellspacing="5">

<tr>
<th align="right">Pick a username</th>
<td><input type="text" name="username" size="16"/></td>
</tr>

<tr>
<th align="right">Pick a password</th>
<td><input type="password" name="password" size="16"/></td>
</tr>

<tr>
<th align="right">Confirm your new password</th>
<td><input type="password" name="confirm_password" size="16"/></td>
</tr>

<tr>
<td>&nbsp;</td>
<td><input type="submit" name="doit" value="Create Account"/></td>
</tr>
</table>

</FORM>
</div>

訪問者はフォームに記入して、「送信」ボタンをクリックします。フォームとCreateAccountページ(前述の最初のinput type文を参照)のページ名で収集された情報がブラウザに送信されます。

ブラウザからWebCenter Sitesにページ名が送信されると、WebCenter Sitesはその名前をSiteCatalog表で検索し、そのページ・エントリのルート・エレメントを起動します。

31.4.2 CreateAccount Pageのルート・エレメント

WebCenter Sitesページのルート・エレメントは1つ(つまり、SiteCatalog表内のエントリ)のみです。CreateAccount pageのルート・エレメントは、CreateAccount.jspエレメントです。

SiteGodまたはContentEditor ACLを持つユーザーのみが、新規ユーザー・アカウントを作成できます。この制限があるため、CreateAccountエレメントは次の操作を実行します。

- 訪問者に気付かれずに、権限を持つユーザーとして訪問者をログインさせます。

- アカウントを作成します。

- 新規ユーザーに適切なACLを割り当てます(どのユーザーも最低1つのACLに属す必要があります)

新規ユーザー・アカウントを作成するコードは、次のとおりです。

<SETVAR NAME="errno" VALUE="0"/>

<!-- switch temporarily to a privileged user -->
<!-- The username and password for the privileged user should be encrypted in a property file. You should obtain them from the property file, decrypt them, then pass them it. For this example, they are hard-coded. -->

<USER.SU USERNAME="jumpstart" PASSWORD="jumpstart">

<USERISMEMBER GROUP="UserEditor"/>
<IF COND="Variables.errno!=1">
<THEN>
<h3>An error has occurred creating the account (no UserEditor
privs).  Contact the webmaster</h3>
</THEN>
<ELSE>
<IF COND="Variables.password!=Variables.confirm_password">
<THEN>
<h3>Your passwords do not match. Click the Back button and
try again.</h3>
</THEN>
<ELSE>

<!-- Get the parameters from the property file -->

<ics.getproperty name="username" file="dir.ini"
output="unameattr"/>
<ics.getproperty name="password" file="dir.ini"
output="passattr"/>

<!-- create the user's name in the right format for the dir tags -->

<ics.getproperty name="peopleparent" file="dir.ini"
output="namebase"/>
<name.makechild context="Variables.namebase" output="iname">
<name.argument name="Variables.unameattr"
value="Variables.username"/>
</name.makechild>

<!-- create the user -->

<dir.create name="Variables.iname">
<dir.argument name="Variables.unameattr"
value="Variables.username"/>
<dir.argument name="Variables.passattr"
value="Variables.password"/>

<!-- additional parameters can be added here but for the example we won't -->
<!-- In particular, if you are using LDAP, you will have to spin through and set the values of the properties in the property requiredPeopleAttrs in dir.ini. -->

</dir.create>

<IF COND="Variables.errno=0">
<THEN>

<!-- give the new user an acl and format it correctly for dir.addgroupmember -->

<ics.getproperty name="groupparent" file="dir.ini"
output="groupparent"/>
<ics.getproperty name="cn" file="dir.ini" output="cn"/>
<name.makechild context="Variables.groupparent"
output="groupid">
<name.argument name="Variables.cn" value="Browser"/>
</name.makechild>

<!-- add the acl -->

<dir.addgroupmember name="Variables.groupid"
member="Variables.iname"/>

<IF COND="Variables.errno=0">
<THEN>
<h3>Success!</h3>
</THEN>
<ELSE>
<h3>User created but error adding user to group.
Contact the webmaster</h3>
</ELSE>
</IF>

</THEN>
<ELSE>
<h3>Error creating user!  Contact the webmaster.</h3>
</ELSE>
</IF> <!-- create success check -->

</ELSE>
</IF> <!-- passwords match -->

</ELSE>
</IF>

</USER.SU>

31.5 Burlington Financialサンプル・サイトにおける訪問者のアクセス

Burlington Financialサンプル・サイトには、新規メンバーのサインアップおよび既存メンバーのログインを実行するエレメントを使用するメンバーシップ・コンポーネントが用意されています。

これらの訪問者登録エレメントは、実際のWebサイトで使用できるほど強力ではありませんが、独自のデザインの開始ポイントとして使用できます。たとえば、Burlington Financialには訪問者アカウントのサンプル画面があり、これを使用すると、訪問者はそれぞれのプリファレンスを登録して設定できます。ただし、この情報を使用して、特定のWebページに対する訪問者のアクセスを制限したり、メンバーのプロファイルに基づいて推奨したりすることはありません。

この項の内容は、次のとおりです。

- 第31.5.1項「メンバーシップ表」

- 第31.5.2項「ユーザーとパスワード」

- 第31.5.3項「メンバー・アカウント」

- 第31.5.4項「メンバーシップ処理エレメント」

31.5.1 メンバーシップ表

Burlington Financialでは、bfmembersという名前の表を使用して、メンバーシップ・コンポーネントを実装します。(この表は、インストール時にサンプル・サイトに対して作成されたものです。WebCenter Sitesモジュールや製品によってこの表が使用されることはありません。)メンバーシップ・エレメントによって、新規登録のメンバーのプロファイル情報ごとに行がbfmembersデータベース表に追加されますが、SystemUsers表には行が追加されません。

31.5.2 ユーザーとパスワード

すべてのBurlington Financialメンバーに対して1人の一般ユーザー(BFUser)がいます。名前とパスワードは同じもの(BFUser/BFUser)であり、変更できません。Burlington Financialのメンバー・ログイン・コードは訪問者のセッション変数を設定し、その訪問者の識別に使用されます。

Burlington Financialはサンプル・サイトのため、メンバーのパスワードはbfmembers表にプレーン・テキストとして保存されます。実際のWebサイトでは、パスワードは暗号化された形式で保存されます。Burlingtonでは、訪問者、BFメンバーおよびブラウザACLの権限がbfmembers表に追加されたエントリに付与されます。

31.5.3 メンバー・アカウント

現在は、Burlington Financialアカウントを管理するエレメントは存在しません。メンバーのアカウントの編集や削除を試行する場合には、Oracle WebCenter Sites Explorerを使用してbfmembers表を変更します。

31.5.4 メンバーシップ処理エレメント

Burlington Financialメンバーへの処理リクエストに対応するエレメントが複数あります。Burlington Financialサンプル・サイトをインストールしてあれば、Oracle WebCenter Sites Explorerを使用して開き、調べることができます。1つを除いて、すべてが次の場所にあります。

ElementCatalog/BurlingtonFinancial/Util/Account

AccountAccessScriptエレメントは、次の場所にあります。

ElementCatalog/BurlingtonFinancial/Util

AccountAccess.xml

これは、ヘッダー、フッター、ナビゲーション・メニューおよびアカウント・コンテンツのページレット・エレメントをコールするページ・テンプレートです。

AccountAccessScript.xml

このファイルには3つのJavaScriptルーチン(checkSignupForm、checkProfileFormおよびcheckLoginForm)が含まれており、HTMLアカウント・フォームで基本エラー・チェックを実行します。これは、Login.xmlエレメント、Profile.xmlエレメントおよびSignUp.xmlエレメントからコールされます。

Benefits.xml

このページは、Block.xml記事テンプレートをコールし、Burlington Financialサイトに関するテキストの記事をレンダリングします。実際のWebサイトでは、記事には役立つ情報が掲載されます。

Login.xml

このページでは、登録されたメンバーのログイン画面が表示され、ログイン・フォーム入力を処理するLoginPost.xmlがコールされます。また、Benefits.xmlをコールし、メンバー以外にはSignUp.xmlをコールします。

LoginPost.xml

このページレット・エレメントはProcessLogin.xmlをコールして、ログイン・メッセージを表示します。

Profile.xml

訪問者が登録されていれば、このページに編集可能なプロファイル・フォームが表示され、訪問者が未登録の場合はSignUp.xmlがコールされます。

ProcessLogin.xml

このページレット・エレメントは、フォームを送信した訪問者が登録済メンバーかどうかに応じて、適切なログイン・メッセージを表示します。

SignUp.xml

このページでは、未登録訪問者向けサインアップ画面が表示され、the catalogmanagerがコールされ、新規ユーザーに対してはbfmembers表に行が追加され、既存ユーザーに対してはbfmembers表が更新されます。

32 HelloAssetWorldサンプル・サイト

HelloAssetWorldサンプル・サイトは、WebCenter Sitesを使用して構築されるサンプルWebサイトです。WebCenter Sitesを使用してWebサイトを構築するプロセスに、簡単なエントリ・ポイントを提供するということになります。この章では、この簡易的なWebサイトの作成で開発者が実行する手順に焦点を当てて説明します。HelloAssetWorldの構成とユーザーの詳細は、Oracle Fusion Middleware WebCenter Sites管理者ガイドを参照してください。

この章には次の項が含まれます。

- 第32.1項「HelloAssetWorldサンプル・サイトの概要」

- 第32.2項「変更されたアセット・タイプ」

- 第32.3項「HelloAssetWorldテンプレート」

- 第32.4項「HelloQueryアセット」

32.1 HelloAssetWorldサンプル・サイトの概要

HelloAssetWorldのサイトのデザインはシンプルです。次のスクリーン・キャプチャで示すように、1ページで構成されています。

このWebサイトに表示される記事の内容は表示を選択した記事に応じて変化しますが、ページのレイアウトは同じです。

HelloAssetWorldサンプル・サイトを表示するには、次のURLをご使用のWebブラウザに入力します。

http://server_name/servlet/ContentServer?pagename=HelloAssetWorld/Page/HelloPageTemplate

この項の内容は、次のとおりです。

- 第32.1.1項「HelloAssetWorldテンプレート」

- 第32.1.2項「HelloAssetWorldアセット・タイプ」

32.1.1 HelloAssetWorldテンプレート

HelloAsset World Webページは、次の3つのテンプレートで構成されています。

- HelloArticleテンプレート: 選択した記事とその記事に関連付けられたイメージを表示します。

- HelloCollectionテンプレート: 表示できる記事のコレクションへのハイパーリンクを表示します。

- HelloPageテンプレート: 格納ページです。HelloAssetWorldバナーがグラフィック表示され、HelloArticleテンプレートとHello Collectionテンプレートがコールされます。

32.1.2 HelloAssetWorldアセット・タイプ

HelloAssetWorldサイトで使用されるアセット・タイプは、Burlington Financialサンプル・サイトで使用されるアセット・タイプから変更されます。詳細は、第33章「Burlington Financialサンプル・サイト」を参照してください。HelloAssetWorldで使用されるアセット・タイプのリストは、次のとおりです。

- Pageアセット・タイプ: 複数の機能を実行します。

- ページを配置してサイトの階層を作成できます。ページを配置するとSitePlanTree表のエントリが追加され、「サイト・プラン」ツリーの「配置済ページ」ノードの下に表示されます。

- 様々なタイプのアセットをそれに関連付けることができます。たとえば、CollectionアセットとArticleアセットをPageアセットに関連付けることができます。
HelloAssetWorldサイト、HelloPageで使用されているPageアセットのインスタンスには、それに関連付けられたHelloCollectionHelloと呼ばれるコレクションがあります。Pageアセット・タイプはWebCenter Sitesで提供されるコア・アセット・タイプで、変更されていません。

- HelloArticleアセット・タイプ: 記事を格納しています。HelloArticleアセットには、それに関連付けられたHelloImageアセットを格納できます。HelloArticleアセット・タイプは、Burlington Financialに用意されたArticleアセット・タイプから変更されています。

- HelloImageアセット・タイプ: イメージを格納しています。HelloImageアセット・タイプは、Burlington Financialに用意されたImageFileアセット・タイプから変更されています。

- Queryアセット・タイプ: データベースに問い合せて、Webサイトに表示するHelloArticleアセットを返します。これはWebCenter Sitesで提供されているコア・アセット・タイプで、変更されていません。

- Collectionアセット・タイプ: 問合せアセットが返す結果を順序付けます。これはWebCenter Sitesで提供されているコア・アセット・タイプで、変更されていません。

- Templateアセット・タイプ: 様々なアセット・タイプをレンダリングします。これはWebCenter Sitesで提供されているコア・アセット・タイプで、変更されていません。

32.2 変更されたアセット・タイプ

HelloAssetWorldサンプル・サイトで使用されるほとんどのアセット・タイプはコア・アセット・タイプであるため、変更できません。ただし、HelloArticleアセット・タイプとHelloImageアセット・タイプは、WebCenter Sitesに用意されたArticleアセット・タイプとImageFileアセット・タイプの簡略化バージョンです。
各アセット・タイプには、Articleアセット・タイプと ImageFileアセット・タイプのアセット・ディスクリプタ・ファイルに基づいた新規アセット・ディスクリプタ・ファイルが備わっています。簡略化アセット・ディスクリプタ・ファイルに関しては、これ以降の項で述べます。

この項の内容は、次のとおりです。

- 第32.2.1項「HelloArticleアセット・タイプ」

- 第32.2.2項「HelloImageアセット・タイプ」

32.2.1 HelloArticleアセット・タイプ

次のコードのASSETタグは、すべてのアセット・ディスクリプタ・ファイルの標準的な開始を意味します。特に、新しいアセット・タイプに名前を付け、そのアセットのDEFDIR(アップロードされたアイテムを格納するデフォルト・ディレクトリ)を指定します。

<ASSET NAME="HelloArticle" DESCRIPTION="HelloArticle" MARKERIMAGE="/Xcelerate/data/help16.gif" PROCESSOR="4.0" DEFDIR="c:\FutureTense\Storage\HelloArticle">

次のコード・セクションによって、記事のヘッドラインのテキスト・フィールドが作成されます。

<PROPERTIES>
<PROPERTY NAME="Headline" DESCRIPTION="Headline">
<STORAGE TYPE="VARCHAR" LENGTH="255" />
<INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" REQUIRED="YES" />
<SEARCHFORM DESCRIPTION="Headline contains" TYPE="TEXT" WIDTH="48" MAXLENGTH="255" />
</PROPERTY>

次のコード・セクションによって、記事の署名行のテキスト・フィールドが作成されます。

<PROPERTY NAME="Byline" DESCRIPTION="Byline">
<STORAGE TYPE="VARCHAR" LENGTH="100" />
<INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="100" REQUIRED="YES" />
<SEARCHFORM DESCRIPTION="Byline contains" TYPE="TEXT" WIDTH="48" MAXLENGTH="100" />
</PROPERTY>

次のコードによって、コンテンツ・エディタと作成者が記事本文のコンテンツに入力できるアップロード・フィールドが作成されます。このコンテンツは、ASSETタグで指定されたDEFDIRに格納されます。

<PROPERTY NAME="urlBody" DESCRIPTION="Body">
<STORAGE TYPE="VARCHAR" LENGTH="2000" />
<INPUTFORM TYPE="TEXTAREA" COLS="300" ROWS="300" REQUIRED="YES" />
</PROPERTY>
</PROPERTIES>
</ASSET>

32.2.2 HelloImageアセット・タイプ

次のASSETタグは、すべてのアセット・ディスクリプタ・ファイルの標準的な開始を意味します。特に、新しいアセット・タイプに名前を付け、そのアセットのDEFDIR(アップロードされたアイテムを格納するデフォルト・ディレクトリ)を指定します。

<ASSET NAME="HelloImage" DESCRIPTION="HelloImage" MARKERTEXT="*" PROCESSOR="4.0" DEFDIR="c:\FutureTense\Storage\HelloImage">

次のコード・セクションにより、イメージ・ファイルのアップロード・フィールドが作成されます。

<PROPERTIES>
<PROPERTY NAME="urlfile" DESCRIPTION="Image File">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="UPLOAD" WIDTH="36" REQUIRED="NO" LINKTEXT="HelloImage"/>
</PROPERTY>

次のコードにより、ドロップダウンの選択肢が作成され、MIMEタイプの検索フィールドを「詳細検索」フォームで表示する方法が指定されます。INPUTFORMタグに対するSQLパラメータの値として指定されるSQL文は、ドロップダウンのテキストにMIMEタイプを指定するようにデータベースに問い合せます。

<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"/>

次のコード・セクションは、MIMEタイプ・フィールドが「詳細検索」フォームで表示される方法を指定します。前述のように、ここで指定されたSQLはドロップダウンの選択肢を入力するMIMEタイプをデータベースに問い合せます。

<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>

次のコードは、管理システムのユーザーがイメージの代替テキストを入力するテキスト・フィールドを作成します。SEARCHFORMタグによって、「代替テキストに次を含む」フィールドが「詳細検索」フォームに表示される方法が指定されます。

<PROPERTY NAME="alttext" DESCRIPTION="Alt Text">
<STORAGE TYPE="VARCHAR" LENGTH="255"/>
<INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" REQUIRED="NO"/>
<SEARCHFORM DESCRIPTION="Alt Text contains" TYPE="TEXT" WIDTH="48" MAXLENGTH="255"/>
</PROPERTY>

</PROPERTIES>
</ASSET>

32.3 HelloAssetWorldテンプレート

HelloAssetWorldサンプル・サイトは3つのTemplateアセットを使用して、事前に記述されているアセットをレンダリングします。次の項で、これらのTemplateアセットについて説明します。

この項の内容は、次のとおりです。

- 第32.3.1項「HelloArticleテンプレート」

- 第32.3.2項「HelloCollectionテンプレート」

- 第32.3.3項「HelloPageテンプレート」

32.3.1 HelloArticleテンプレート

HelloArticleTemplateはHelloArticleアセットをレンダリングします。このテンプレートは、次の変数を使用します。

表32-1 HelloArticleテンプレート

変数

値

ソース

tid

現在のテンプレートのIDです。

tid変数は、SiteCatalog表のresargs1フィールドに設定されます。この値はテンプレート作成時に自動的に設定されます。

c

テンプレートに表示されるコンテンツのタイプです。

c変数は、SiteCatalog表のresargs1フィールドに設定されます。この値は、「新規テンプレート」フォームの「アセット・タイプ」フィールドを使用して設定されます。

cid

ロードするアセットのIDです。

cid変数は、HelloPageテンプレートによって渡されます。

picture:oid

HelloArticleアセットに関連付けられたHelloImageアセットのオブジェクトIDです。

picture:oid変数を取得するには、現在のHelloArticleアセットをロードし、ASSET.CHILDRENタグを使用して、関連付けられたHelloImageアセットの情報を検索します。

picture:alttext

関連付けられたHelloImageアセットの代替テキストです。

picture:alttext変数を取得するには、現在のHelloArticleアセットをロードし、ASSET.CHILDRENタグを使用して、関連付けられたHelloImageアセットの情報を検索します。

picture:mimetype

関連付けられたHelloImageアセットのMIMEタイプです。

picture:mimetype変数を取得するには、現在のHelloArticleアセットをロードし、ASSET.CHILDRENタグを使用して、関連付けられたHelloImageアセットの情報を検索します。

asset:headline

このHelloArticleアセットのHeadlineフィールドの値です。

asset:headline変数は、HelloArticleアセットの情報を散布することで取得されます。

asset:byline

このHelloArticleアセットのBylineフィールドの値です。

asset:headline変数は、HelloArticleアセットの情報を散布することで取得されます。

artID

HelloArticleテンプレートに表示する記事のIDです。

最初のページ・ビューでは、ElementCatalogエントリのresdetailsフィールドに設定されます。以降のビューでは、HelloCollectionテンプレートによって渡されます。

次のコードは、記事テンプレートの標準的な開始です。WebCenter Sitesユーザー・インタフェースで「新規テンプレート」フォームの「XML」ボタンまたは「JSP」ボタンをクリックすると表示されます。

<?xml version="1.0" ?>
<!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.1">
<!--  HelloArticle/HelloArticleTemplate
-
- INPUT
-
- OUTPUT
-
-->

RENDER.LOGDEPタグは、テンプレートにキャッシュ依存性項目としてマークを付けます。つまり、テンプレートが変更された場合、以前のテンプレートのコピーがWebCenter SitesキャッシュとSatellite Serverキャッシュから削除され、最新のバージョンに自動的に置換されます。

<IF COND="IsVariable.tid=true">
<THEN>
<RENDER.LOGDEP   cid="Variables.tid" c="Template"/>
</THEN>
</IF>

<table border="0" cellspacing="2" cellpadding="2">

<tr>
<td>

次のASSET.LOADタグは、Variables.cidに保存されているアセットのIDを使用して、HelloArticleアセットをロードします。この値は、HelloPageテンプレートによってHelloArticleテンプレートに渡されます。

<!-- asset load will mark the asset as an 'exact' dependent of the pagelet being rendered -->

<ASSET.LOAD NAME="helloArticleAsset" TYPE="Variables.c" OBJECTID="Variables.cid"/>

次のコード・セクションは、ASSET.CHILDRENタグを使用して、記事に関連付けられているHelloImageアセットをロードします。ASSET.CHILDRENは、HelloImageアセットを表示するために必要な情報を格納するリストを作成します。

<ASSET.CHILDREN NAME="helloArticleAsset" LIST="picture" TYPE="HelloImage"/>

このコードは、最新の記事に関連付けられているHelloImageアセットがあるかどうかをチェックします。関連付けられたHelloImageアセットがない場合、テンプレートは記事のテキストのみを表示します。

<!--Check to see if the list (which contains information to display an image) exists--if the list doesn't exist, display the article text only. -->
<IF COND="IsList.picture=true">
<THEN>
<!--Log the image as a dependency.-->
<RENDER.LOGDEP   cid="picture.oid" c="HelloImage"/>

このコードはRENDER.SATELLITEBLOBタグを使用して、関連付けられたイメージを表示します。

<!--Display the image.-->
<RENDER.SATELLITEBLOB BLOBTABLE="HelloImage" BLOBKEY="id" BLOBCOL="urlfile" BLOBWHERE="picture.oid" BLOBHEADER="picture.mimetype" SERVICE="IMG SRC" ARGS_ALT="picture.alttext" ARGS_ALIGN="left"/>
</THEN>
</IF>
</td>
</tr>

<tr>
<td>

次に、このASSET.SCATTERタグがすべてのHelloArticleアセットのプライマリ・フィールドを取得します。

<!-- get all the primary table fields of the asset -->
<ASSET.SCATTER NAME="helloArticleAsset" PREFIX="asset"/>

次のCSVARタグが、アセットのフィールドのコンテンツを表示します。

<!-- display the headline-->

<h3><CSVAR NAME="Variables.asset:headline"/></h3>
</td>
</tr>

<tr>
<td>
<CSVAR NAME="Variables.asset:byline"/>
</td>
</tr>

<tr>
<td>

「本文」フィールドに埋込みリンクが格納されている可能性があるため、次のコードに示すように、ics.getvarタグを使用して取得し、RENDER.STREAMタグを使用して表示する必要があります。

<!-- display the body-->
<ics.getvar name="asset:urlbody" encoding="default" output="bodyvar"/>
<RENDER.STREAM VARIABLE="bodyvar" /><br/>
</td></tr>
</table>

</FTCS>

32.3.2 HelloCollectionテンプレート

コレクション・テンプレートには、HelloCollectionHelloコレクションが表示されます。このテンプレートは、次の変数を使用します。

表32-2 HelloCollectionテンプレート

変数

値

ソース

tid

現在のテンプレートのIDです。

tid変数は、SiteCatalog表のresargs1フィールドに設定されます。この値はテンプレート作成時に自動的に設定されます。

c

テンプレートに表示されるコンテンツのタイプです。

c変数は、SiteCatalog表のresargs1フィールドに設定されます。この値は、「新規テンプレート」フォームの「アセット・タイプ」フィールドを使用して設定されます。

cid

ロードするアセットのIDです。

cid変数は、HelloPageテンプレートによって渡されます。

tid

現在のテンプレートのIDです。

tid変数は、SiteCatalog表のresargs1フィールドに設定されます。この値はテンプレート作成時に自動的に設定されます。

p

ハイパーリンクを生成するページのIDです。この場合は、最新のテンプレートになります。

なし

ApprovedArticles:id

コレクション内の最新のHelloArticleのIDです。

なし

ApprovedArticles:name

コレクション内の最新のHelloArticleの名前です。

なし

artID

artID変数には、HelloArticleTemplateにより表示されたHelloArticleのIDが記述されています。値は、コレクション内の最新記事のIDになります。

リスト内の最新記事がHelloArticleテンプレートで表示されている記事でない場合、URLが生成されてその記事へのハイパーリンクが作成されます。URLはRENDER.GETPAGEURLタグで作成され、そのタグが作成するURLにartID変数を追加します。この変数には、表示に使用する記事のIDが含まれます。

pageID

HelloPageアセットのIDです。

なし

referURL

RENDER.GETPAGEURLタグによって生成されたURLです。

なし

<IF COND="IsVariable.tid=true">
<THEN>
<RENDER.LOGDEP   cid="Variables.tid" c="Template"/>
</THEN>
</IF>

次のASSET.LOADタグは、Variables.cidに記述されているIDの値に基づいて、HelloCollectionHelloアセットをロードします。Variables.cidはHelloPageテンプレートによって渡されます。ASSET.LOADは、HelloCollectionアセットも名付けます。これはデータベース内のアセット名を変更するのではなく、テンプレート内の残りのコードがコレクションのアセットを参照する際に使用する名前を設定します。

<ASSET.LOAD NAME="HelloCollection" TYPE="Collection" OBJECTID="Variables.cid"/>
<ASSET.SCATTER NAME="HelloCollection" PREFIX="asset"/>

次のASSET.CHILDRENタグは、コレクションを構成するHelloArticlesが格納されたリストをロードします。

<ASSET.CHILDREN NAME="HelloCollection" LIST="theArticles" OBJECTTYPE="HelloArticle"/>

次のコード・セクションは、RENDER.FILTERタグを使用してディスク公開へのエクスポートが承認されていない記事をフィルタで除外します。これにより、テンプレートがミラー公開およびディスク公開へのエクスポートの両方で使用できるようになります。

<!--Filter out assets which aren't approved for export to disk publishing.-->
<RENDER.FILTER LIST="theArticles"LISTVARNAME="ApprovedArticles" LISTIDCOL="oid"/>

次のコードでは、LOOPタグが承認された記事のリストをループ処理し、RENDER.LOGDEPタグがリストの各アイテムをキャッシュ依存性として記録します。

<LOOP LIST="ApprovedArticles">
<RENDER.LOGDEP cid="ApprovedArticles.id" c="Article"/>

次のコードは、IFタグを使用して、リストの最新の記事がHelloArticleテンプレートで表示されている記事であるかどうかをチェックします。HelloArticleテンプレートで表示されている記事のIDは、Variables.artIDに含まれています。この変数は、HelloPageテンプレートによって渡されます。記事のIDが同一の場合、記事の名前はハイパーリンクではなく太字テキストで表示されます。

<IF COND="Variables.artID=ApprovedArticles.id">
<THEN>
<B><CSVAR NAME="ApprovedArticles.name"/></B><P/>
</THEN>

リスト内の最新記事がHelloArticleテンプレートで表示されている記事でない場合、URLが生成されてその記事へのハイパーリンクが作成されます。URLは、次のコードのRENDER.GETPAGEURLタグで作成されます。RENDER.GETPAGEURLタグはartID変数を、その変数が作成するURLに追加します。この変数には、表示に使用する記事のIDが含まれます。

<ELSE>
<RENDER.GETPAGEURL PAGENAME="HelloAssetWorld/Page/HelloPageTemplate"
cid="Variables.pageID"
c="Page"
p="Variables.p"
OUTSTR="referURL"
ARGS_artID="ApprovedArticles.id"/>

次のコード例では、ハイパーリンクを表示します。REPLACEALL引数は、ハイパーリンクのURLが記載されたVariables.referURLを評価します。次に示すCSVARタグは、ハイパーリンクのリンク先の記事の名前を表示します。

<A HREF="Variables.referURL" REPLACEALL="Variables.referURL">
<CSVAR NAME="ApprovedArticles.name"/>
</A><P/>
</ELSE>
</IF>
</LOOP>
</FTCS>

32.3.3 HelloPageテンプレート

HelloPageテンプレートは格納ページとして機能します。終了ページのレイアウトを作成する際に、HelloPageアセットをレンダリングし、ヘッダーをグラフィック表示して、HelloCollectionテンプレートとHelloArticleテンプレートをコールします。

HelloPageテンプレートは、次の変数を使用します。

表32-3 HelloPageテンプレート

変数

値

ソース

tid

現在のテンプレートのIDです。

tid変数は、SiteCatalog表のresargs1フィールドに設定されます。この値はテンプレート作成時に自動的に設定されます。

c

テンプレートに表示されるコンテンツのタイプです。

c変数は、SiteCatalog表のresargs1フィールドに設定されます。この値は、「新規テンプレート」フォームの「アセット・タイプ」フィールドを使用して設定されます。

cid

ロードするアセットのIDです。

cid変数は、テンプレートのSiteCatalogエントリのresargs1フィールドに設定されます。

topImg:ID

TopImage ImageFileアセットのIDです。

topImg:ID変数を取得するには、TopImageイメージ・ファイル・アセットの情報を散布します。

topImg:alttext

TopImageアセットの代替テキストです。

topImg:alttext変数を取得するには、TopImageイメージ・ファイル・アセットの情報を散布します。

topImg:mimetype

TopImageアセットのMIMEタイプです。

topImg:mimetype変数を取得するには、TopImageイメージ・ファイル・アセットの情報を散布します。

asset:ID

このテンプレートがレンダリングしているPageアセットのIDです。

asset:ID変数を取得するには、HelloPageアセットの情報を散布します。

theCollection.oid

表示のためにHelloCollectionテンプレートに渡される、HelloCollectionHelloコレクションのIDです。

コレクションとそのIDはPageアセットに関連付けられています。

artID

HelloArticleテンプレートに表示する記事のIDです。

最初のページ・ビューでは、ElementCatalogエントリのresdetailsフィールドに設定されます。以降のビューでは、HelloCollectionテンプレートによって渡されます。

HelloPageテンプレートのコードとそれに伴う動作の記述は、次のとおりです、

<IF COND="IsVariable.tid=true">
<THEN>
<RENDER.LOGDEP cid="Variables.tid" c="Template"/>
</THEN>
</IF>

<!--Table for formatting-->
<table border="1" cellpadding="5" cellspacing="5">

<tr>
<td colspan="2">

このコードはHelloImageアセットをロードして、RENDER.SATELLITEBLOBタグを使用してアセットを表示します。

<!--Embedded Image Asset-->

<!-- The following two lines of code load the image file and scatter the information in its fields. -->
<ASSET.LOAD NAME="TopImage" TYPE="HelloImage" OBJECTID="1024605735822"/>
<ASSET.SCATTER NAME="TopImage" PREFIX="topImg"/>

<!-- This code creates a URL to display the image file.-->
<RENDER.SATELLITEBLOB BLOBTABLE="HelloImage" BLOBKEY="id" BLOBCOL="urlfile" BLOBWHERE="Variables.topImg:id" BLOBHEADER="Variables.topImg:mimetype" SERVICE="IMG SRC" ARGS_alt="Variables.topImg:alttext" ARGS_WIDTH="600" ARGS_HEIGHT="90"/>
</td>
</tr>

<tr>
<td>

次に、Variables.cidの値に基づいたHelloPageアセットがロードされます。この値は、テンプレートのSiteCatalogエントリのresargs1フィールドに設定されます。

<!-- This loads the HelloPage asset and names it HelloPage. -->
<ASSET.LOAD NAME="HelloPage" TYPE="Variables.c" OBJECTID="Variables.cid"/>

<!-- This scatters the fields of the HelloPage asset for use later in the element. -->
<ASSET.SCATTER NAME="HelloPage" PREFIX="asset"/>

<!-- This finds the collection asset associated with the HelloPage asset and puts the information the collection into a list. -->
<ASSET.CHILDREN NAME="HelloPage" LIST="theCollection" />
<RENDER.LOGDEP C="Collection" CID="theCollection.oid"/>
<!-- This checks to see whether ASSET.CHILDREN really generated a list. -->
<IF COND = "IsList.theCollection=true">

<THEN>
<!-- This displays the HelloCollectionTemplate template and passes the template the ID of the collection to display and the ID of the current page. -->
<RENDER.SATELLITEPAGE PAGENAME="HelloAssetWorld/Collection/HelloCollectionTemplate" ARGS_cid="theCollection.oid" ARGS_p="Variables.asset:id" ARGS_artID="Variables.artID"/>
</THEN>

</IF>
</td>

<td>
<!-- This displays the HelloArticleTemplate template and passes the template the ID of the article to display and the ID of the current page. The artID variable is passed in by the URL.-->
<RENDER.SATELLITEPAGE PAGENAME="HelloAssetWorld/HelloArticle/HelloArticleTemplate" ARGS_cid="Variables.artID" ARGS_p="Variables.asset:ID"/>
</td>
</tr>
</table>
</FTCS>

32.4 HelloQueryアセット

HelloAssetWorldサイトでは、HelloQueryと名付けられた問合せアセットを使用して、データベースからHelloArticlesが取得されます。それによって、コンテンツ・プロバイダでは、表示される順番でHelloQueryアセットが返す項目にランクが付けられ、コレクションが作成され構築されます。

33 Burlington Financialサンプル・サイト

Burlington Financialサンプル・サイトでは、WebCenter Sitesのアセットを使用したサイト・デザインのベスト・プラクティスを実際に使用してみます。

コンテンツ管理は、アセット、問合せおよびテンプレートの観点から記述されている場合は特に、非常に抽象的である可能性があります。Burlington Financialは、アプリケーションの最終的な成果の内容(ライブで機能するWebサイト)を理解するうえで役立ちます。開発者とコンテンツ・マネージャは、直接、簡単にサンプル・サイトのコードと問合せにアクセスできます。

この章には次の項が含まれます。

- 第33.1項「Burlington Financialサンプル・サイトの概要」

- 第33.2項「ナビゲーション機能」

- 第33.3項「ベスト・プラクティス」

33.1 Burlington Financialサンプル・サイトの概要

Burlington Financialは架空の金融情報のサイトです。このサイトでは、セクション間の移動、サイトの階層、サイトとアセット・タイプの連動方法、および実際のルックアンドフィールが重視されています。また、Burlington Financialには約500の記事と100以上のイメージがあり、複数のセクションに移入できる実在のコンテンツも十分に備わっています。

Burlington Financialは、次の機能が備わった完全に動作するサンプルです。

- 検索、メンバー・ログイン、プリンタ対応の記事、友人への電子メール、トピック・ディレクトリおよびスタイルシート

- Webサイト・セクションの階層のデモ

- コンポーネントのキャッシュおよびSatellite Serverのサポート

- AssetMakerで作成されたアセットの使用のデモ

- フレックス・アセットおよびEngageセグメント・アセットの使用のデモ

- 十分な量のコンテンツ

- 開発者が学べる実在のサイトの近似機能

Burlington Financialのホーム・ページは、次の図のとおりです。

Burlington Financialはキャッシュ可能なページレットを活用しています。これらの個々のページレットは個別にキャッシュして管理でき、開発の際にはサイトのパフォーマンスと柔軟性が高まります。

キャッシュ可能なページレットを使用してサイトを設計するようお薦めします。詳細は、第5章「ページのデザインとキャッシング」を参照してください。

33.2 ナビゲーション機能

Burlington Financialでは、プライマリ・ナビゲーション・バーを表示するために、次の3つのエレメントを使用しています(Oracle WebCenter Sites Explorerの使用時に確認できます)。

この項の内容は、次のとおりです。

- 第33.2.1項「BurlingtonFinancial/Site/TopSiteBar.xml」

- 第33.2.2項「BurlingtonFinancial/Site/LeftSideSiteBar.xml」

- 第33.2.3項「BurlingtonFinancial/Site/BottomNavFooter.xml」

- 第33.2.4項「ブレッドクラム」

33.2.1 BurlingtonFinancial/Site/TopSiteBar.xml

このエレメントは、ホームページと、Burlington Financialのロゴのすぐ下にあるページの最上部にあるトップレベルの子にハイパーリンクを作成します。

「Home」ページのトップレベルの子のみを意図的に表示して、ハイパーリンクの行が折り返されてページのデザインを損なわないようにします。「Home」ページは最初に表示され、その子と同じレベルになります。

33.2.2 BurlingtonFinancial/Site/LeftSideSiteBar.xml

このエレメントでは、Webサイトのメジャー・セクションの詳細マップを作成し、「Home」ページの子ページおよび孫ページを確認します。このエレメントは2レベルより深く進むように変更できます。ただし、サイトのグラフィック・デザインが使用できるスペースは制限されます。

TopSiteBarにはリストされていなかった2つの別のメジャー・ページがここにリストされることに注目してください。「Wire Feed」ページおよび「Columnists」ページは「Home」ページとその子からは独立していて、個別に表示されます。

33.2.3 BurlingtonFinancial/Site/BottomNavFooter.xml

このエレメントは、すべてのページの下部にハイパーリンクを作成します。LeftSideSiteBarと同様に、BottomNavFooterエレメントも「Home」ページの子ではないページへのリンクが含まれます。

注意:

別のPageアセットをサイトに追加した場合、それがHome Pageアセットの子でないと、Burlington Financialで使用されるどのナビゲーション・バーにも自動的に表示されません。

これらのナビゲーション・バーは動的に算出されますが、実際のWebサイトでは、それほど頻繁な変更はありません。最大パフォーマンスを得るために、エレメント内の動的コードをトップレベル・ページへのハードコード化されたリンクの静的リストと置換できます。後からサイトの変更および新規トップレベル・セクションの追加が必要になった場合、少数のエレメントを変更するだけで済みます。

動的ナビゲーション・バーのエレメントを使用する場合、ナビゲーション・バーのページレットに対して長期のキャッシュ・タイムアウトを設定する必要があります。

33.2.4 ブレッドクラム

Webサイト内のこの共通機能は、特定項目へのパスを示す小さなマップです。Burlington Financialでは、これはアクセスしたページの実際の履歴ではなく概念的なパスで、トップ・ナビゲーション・バーのすぐ下に配置されています。

WebCenter Sitesではアセットを同時に複数の親に割り当てることができるため、同じ記事が同時に「Home」ページと「News」ページのコレクションのメンバーとして表示される可能性があります。記事の真の親を識別する方法がないため、Burlington Financialでは、親Pageで子へのハイパーリンクを作成するたびに親Pageのidを渡しています。それにより、子アセットを単独で作成するときには、該当する親のIDがすでに備わっています。この値は変数pで渡されます。

テンプレートがpに対する異なった値に基づいて異なったHTMLを生成するため、それらのバージョンは個別にキャッシュされる必要があります。そのため、変数pは、そのテンプレートのSiteCatalog内のページ・エントリにリストされているページの基準変数の一部である必要があります。これは、共通的な技法といえるため、WebCenter Sitesでは、TemplateアセットのSiteCatalogページ・エントリに対応するページの基準変数のリストに、自動的にpを含めます。

pをオーバーライドして異なる親アセットを使用する必要が出てくることがあります。たとえば、次の寄稿者の記事へのリンクをBurlington Financialの「Home」ページに設定するとします。

ただし、これらの記事は概念的には「Home」ページに属しているのではなく、「Columnists」ページに属しています。したがって、Columnists PageアセットのIDをこれらのハイパーリンクの親としてロードし、渡すことができます。これにより、訪問者がそれらをクリックした際に、ブレッドクラムはColumnistsを親として識別します。この動作は、Columnistsリンクをナビゲーション・バーでクリックし、そこにあるいずれかの記事をクリックすることと同じです。

他の場合には、どのアセットが親であるかがすぐには明確になりません。たとえば、Burlington Financialで「From the Wires」ボックスの記事が現在のページの付属として処理されるとします。メインの「Wire Feed」セクション・ページにリストされたストーリーは「Wire Feed」セクションに属しており、それらの親として「Wire Feed」を示しています。

33.3 ベスト・プラクティス

Burlington Financialサンプル・サイトでは、実際のWebサイトで使用されているその他のいくつかの重要な機能について、WebCenter Sitesのベスト・プラクティスを示しています。

この項の内容は、次のとおりです。

- 第33.3.1項「検索」

- 第33.3.2項「キーワード」

- 第33.3.3項「Hot Topics」

- 第33.3.4項「Topic Directory」

- 第33.3.5項「Related Stories」

- 第33.3.6項「テキストのみのバージョン」

- 第33.3.7項「プレーン・テキストのパラレル・サイト」

- 第33.3.8項「Email This Story」

- 第33.3.9項「AssetMakerアセット・タイプ」

- 第33.3.10項「MIMEタイプ」

- 第33.3.11項「コレクションのコレクション」

- 第33.3.12項「メンバーシップ」

- 第33.3.13項「Wire Feed」

- 第33.3.14項「Featured Funds」

- 第33.3.15項「Fund Finder」

- 第33.3.16項「ページ・キャッシュ・パラメータ」

33.3.1 検索

Burlington Financialのデータベース検索コードは、WebCenter Sitesのアプリケーション自体の検索コードに酷似しています。この検索コードは動的配信で機能しますが、エクスポートされた静的HTMLでは機能しません。この場合、静的HTMLファイルの索引付けに別の検索メカニズムが必要になります。

BurlingtonFinancial/Util/SearchPostエレメントでは、Article表に対してSQL検索を使用します。また、検索エンジンの索引がインストールされていて、Articleアセット・タイプに対して有効化されている場合には、この索引を使用することもできます。SQL検索は大/小文字を区別します。検索エンジンにより、大/小文字を区別しない検索、単語のバリアント、ステミングなどのさらに高度な検索機能が使用できるようになります。

33.3.2 キーワード

Articleアセット・タイプには、keywordというフィールドがあります。このフィールドを使用すると、エディタは、特定の用語をArticleに関連付けて、Articleアセット・タイプの検索機能を向上できます。Burlington Financial Articleアセットには、カンマで区切られた1つ以上のキーワード(例: Energy, Shell Oil, OPEC)があります。Burlington Financialでは、キーワードを使用してHot Topicsのリストを表示します。

33.3.3 Hot Topics

Burlington Financialの「Hot Topics」は、問合せアセットの1つの使用方法を示しています。

大半のページの左側に、サイトの特定のセクションを示す「Hot Topics」のリストがあります。「Hot Topics」は、Pageアセットによって指定されたとおり、訪問者が表示するセクションに従ってリストされます。

次の例では、「News」セクションの「Hot Topics」は「Human Genome」、「History」、「Sanctions」、「Energy」および「California」となっています。

エレメントBurlingtonFinancial/Common/LeftNavColumnには、ページレットBurlingtonFinancial/Query/ShowHotTopicsが含まれています。このエレメントは、変数pを通じて渡される、ページ・アセットのIDを受け取ります。pの値が検出できない場合には、デフォルトでは「Home」ページが使用されます。そのページ・アセットがロードされ、ページに関連付けられたトップ・ストーリーのコレクションが検索されてロードされます。次に、コレクション内の各記事をループさせ、記事のキーワード・フィールドからプルされたキーワードのリストを作成します(1つの記事に対する複数のキーワードはカンマで区切る必要があります)。キーワードのリストが作成されると、エレメントはHotTopicsと名付けられた問合せアセットをレンダリングして、そのキーワードに対する問合せを実行するページへのハイパーリンクとして各キーワードをリストして、そのリストをループします。

訪問者がリンクをクリックすると、HotTopicFrontテンプレートを使用して、問合せアセットHotTopicsをレンダリングするページに移動します。HotTopics問合せは、選択されたキーワードを含む記事に対して完全なSQL一致を実行します。キーワード検索には、まったく制約がありません。特定のセクションやカテゴリにある記事のみでなく、Burlington Financialサイト内のすべての記事を検索します。

HotTopics問合せで返された各記事は、訪問者が最初にキーワードで検索を開始したページ・アセットの親IDを継承します。「News」ページの「Energy stories」のリストから「Shell Oil story」をクリックすると、「News」を親ページとして表示されます。同じ「Shell Oil story」を「World News」ページの「Energy stories」のリストからクリックすると、「World News」を親として表示されます。

この設計は動的ライブ・サイトでは問題ありませんが、静的配信サイトへエクスポートする際にファイルの重複の原因となります。

33.3.4 Topic Directory

「Topic Directory」へのハイパーリンクは、左側のナビゲーション・コラムの下部、および各ページの下部にあるナビゲーション・リンクにあります。

このページは、セクションごとのHot Topicsのページレットで構成されています。ここで使用されているページレットは左のナビゲーション・コラムでも使用されているため、ブラウザで非常に素早く表示されます。各トピックはその親ページを継承し、それを問合せが返す記事のリストに渡します。

33.3.5 Related Stories

記事の「Related Stories」リストに使用される問合せアセットは、前述したHotTopics問合せと似ていますが、キーワードを他のページから取得するのではなく、問合せが関連付けられている記事から取得します。Articleテンプレートの「Full」にはRelated Storiesのページレットが用意されていて、記事の最初のキーワードを問合せアセットに渡します。Related Storiesの問合せが実行されると、同じキーワードを持つその他の記事が検索されます。

たとえば、「Home」ページから「Hot Topic」の「Microsoft」をクリックし、「Microsoft launches worldwide campaign against counterfeit software」を選択します。この記事(cid=984156689788)のkeywordフィールドには、Microsoftという単語が含まれます。また、記事に関連付けられた関連キーワードの問合せもあります。この問合せがレンダリング時に実行されると、SQLはkeywordフィールドに「Microsoft」という用語が含まれているその他の記事を5つ検索します。問合せは、その問合せに関連付けられた記事は除外するよう指定されているため、「Related Stories」のサブヘッドラインには「Microsoft Campaigns Against Counterfeit Software」が表示されません。

動的な環境では、この問合せから返される記事のリストはサイトに追加される記事として変更できます。

33.3.6 テキストのみのバージョン

Webページのテキストのみのバージョン作成(印刷用に)は、非常に簡単にWebCenter Sitesで実装できます。WebCenter Sitesのレンダリング・モデルを使用すると、レンダリングに使用するページ名を変更するだけで指定されたアセットを表示するテンプレートをオーバーライドできます。オーバーライド・テンプレートを個別のパラメータとして渡す必要はありません。ページのプリンタ優先バージョンは、該当するテンプレートのプレーン・テキスト・バージョンを使用するハイパーリンクを追加するだけで作成できます。

たとえば、記事をポイントする場合は、次のURLにアクセスします。

http://myserver/servlet/ContentServer?pagename=BurlingtonFinancial/Article/Full&cid=987654321

ページのテキストのみのバージョンを変更するには、テンプレートのテキスト・バージョンをポイントします。

http://myserver/servlet/ContentServer?pagename=BurlingtonFinancial/Article/FullText&cid=987654321

Burlington Financialでは、Templateアセット名の最後にTextを追加する表記規則を使用して、別のスタイルのテンプレートとエレメントを指定します。その例は、次のとおりです。

- Webフォーマット: BurlingtonFinancial/Article/Summary

- プレーン・テキスト: BurlingtonFinancial/Article/SummaryText

- Webフォーマット: BurlingtonFinancial/Page/SectionFront

- プレーン・テキスト: BurlingtonFinancial/Page/SectionFrontText

33.3.7 プレーン・テキストのパラレル・サイト

ほとんどのWebサイトでは、テキストのみのページにはフル・フォーマットのWebページに戻るハイパーリンクが備わっています。そうでない場合は、プリンタ優先ページにナビゲートするリンクはありません。ただし、Burlington Financialのテンプレートは訪問者にサイトのプレーン・テキスト・バージョン全体を表示するために設計されています。

プレーン・テキスト・バージョンに切り替えた後は、プレーン・テキスト・ページのままで移動できます。しかし、Burlington Financialサイトのすべての単独ページがサイトのプレーン・テキスト・バージョンで表示されるわけではありません。さらに、プレーン・テキスト・ページはグラフィック・バージョンと同じコンテンツやハイパーリンクを備えていない場合もあります。これは、プレーン・テキストの訪問者は複雑でないサイトのバージョンを好むと考えられるため、意図的に処理されたものです。Burlington Financialを拡張してその他のパラレル・スタイル(WAPテンプレート、WebTV、PDF、XML)を追加することは、非常に簡単です。

33.3.8 Email This Story

Webサイトのもう1つの一般的な機能は、ストーリーの電子メール送信機能です。Burlington Financialでは、この機能は比較的簡単です。

注意:

ユーザーに電子メールを送信するには、電子メール機能を使用するためにWebCenter SitesとContent Centreを構成する必要があります。

まず、futuretense.iniファイルで、次の2つのプロパティを設定します。

cs.emailreturnto=<your email address>
cs.emailhost=po-1.example.com (or the emailhost is)

次に、futuretense_xcel.iniで次のプロパティを設定します。

xcelerate.emailnotification=true

BurlingtonFinancial/Util/EmailFrontエレメントとBurlingtonFinancial/Util/EmailPostエレメントは、記事のページレットBurlingtonFinancial/Article/Summaryをコールし、サマリー・フォームにそのストーリーを表示します。このコードのさらに強力なバージョンでは、訪問者がフォームを送信する前に、有効な電子メール・アドレスが入力されていることが確認されます。実際のサイトでも、電子メールで送信されたストーリー、送信者の電子メール・アドレス、および受信者の電子メール・アドレスの記録が保存されます。

33.3.9 AssetMakerアセット・タイプ

AssetMakerは、ベーシック・アセット・タイプを構成するWebCenter Sitesユーティリティです。Burlington Financialには、ImageFileとStylesheetの2つのサンプルAssetMakerアセット・タイプが用意されています。これらのアセット・タイプは、AssetMakerからの標準エレメントを変更せずに使用します。どちらにもデータベース内にファイルを格納するためのファイル・アップロード・フィールドが備わっています。

Burlington Financialには各ページの上部にJavaScriptが備わっており、クライアント側のブラウザを検出し、該当する4つのStylesheetアセットの1つをロードします。エレメントBurlingtonFinancial/Common/SetHTMLHeaderは、各ページ全体のテンプレートの最上部でコールされ、WebCenter SitesのエレメントGetBlobURLを使用して4つの異なるBlobServer URLを取得します。これは、Burlington Financialで使用される4つの異なる各Stylesheetアセットに対するURLです。Stylesheetアセットからの実際の.cssファイルは、バイナリ・データではない場合でも、BlobServerを介して提供されます。

33.3.10 MIMEタイプ

イメージ・ファイル・アセット・タイプおよびスタイルシート・アセット・タイプのどちらも、BlobServerサーブレットを使用してブラウザに提供されます。ブラウザがコンテンツの任意の部分の処理方法を認識できるように、MIMEタイプ・コードが保存され、ブラウザに渡されます。WebCenter Sitesには、これらのコードを格納するためのMimeType表が用意されています。

AssetMakerでは、アセット・タイプによって独自のMIMEタイプ・フィールドを定義できます。ImageFileアセット・タイプとStylesheetアセット・タイプのどちらにも、アセット記述子ファイルの一部としてMIMEタイプ・フィールドが含まれています。Oracle WebCenter Sites Explorerまたはその他のデータベース・ツールを使用して、独自のMIMEタイプ・コードと拡張子をMimeType表に追加できます。

33.3.11 コレクションのコレクション」

コレクション・アセット・タイプでは、WebCenter Sitesでコンテンツを管理可能なグループに配置する方法を指定します。Burlington Financialでは、子アセット・タイプがコレクションであるコレクションもデモで使用して確認できます。これにより、エディタはコレクションをランク付けしなおすだけで、Webページ上のコンテンツのグループを簡単に再配置できます。これらのサブコレクションを使用して、お気に入りのストーリーのライブラリ、ニュース速報、ホット・トピックなどを作成できます。

Burlington Financialでは、HomeStoryGroupsという名前付きアセット・アソシエーションが、ページ・アセット・タイプからコレクション・アセット・タイプに作成済です。ページ・テンプレートSectionFrontは、StoryGroupsスロットのコレクションを検索します。コレクションは、BurlingtonFinancial/Collection/StoryGroupsテンプレートを使用して強制的に表示されます。

<ASSET.CHILDREN NAME="SectionFrontPage" LIST="StoryGroups" CODE="HomeStoryGroups"/
<IF COND="IsList.StoryGroups=true"
<THEN
<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/Collection/StoryGroups"
ARGS_cid="StoryGroups.oid"
ARGS_p="Variables.asset:id"/
</THEN
</IF
The StoryGroups template then loops over each collection in the asset:
<LOOP LIST="theGroups"
<RENDER.SATELLITEPAGE PAGENAME="BurlingtonFinancial/Collection/PlainList"
ARGS_cid="theGroups.oid"
ARGS_p="Variables.p"/
<img src="/futuretense_cs/bf/images/dot_rule_125.gif" width="125" height="1"/<P/
</LOOP

これはニュース・ページで確認できます。ニュース・ページに関連付けられたNewsGroupというコレクションがあります。このコレクションには、それ自体が3つの記事を持つ、Energy Listと呼ばれる子コレクションが1つ含まれています。これにより、エディタはNewsGroupコレクションのランク付けをしなおして、アイテムを「News」ページに追加したり、「News」ページから削除したりできます。

33.3.12 メンバーシップ

Burlington Financialサンプル・サイトには、新規メンバーのサインアップおよび既存メンバーのログインを実行するエレメントが含まれたメンバーシップ・コンポーネントが用意されています。これらの訪問者登録エレメントは、実際のWebサイトで使用できるほど強力ではありませんが、独自のデザインの開始ポイントとして使用できます。たとえば、Burlington Financialには訪問者アカウントのサンプル画面があり、これを使用すると、訪問者はそれぞれのプリファレンスを登録して設定できます。ただし、この情報を使用して、特定のWebページに対する訪問者のアクセスを制限したり、メンバーのプロファイルに基づいて推奨したりすることはありません。

Burlington Financialの訪問者の登録と一般的なセキュリティの詳細は、第31章「配信システムにおけるユーザー管理」を参照してください。

33.3.13 Wire Feed

ホームページ・テンプレートおよびセクション・フロント・ページ・テンプレートのどちらにも、「From the Wires」というストーリーのリストが用意されています。これは、自動的に取り込まれるコンテンツを表しています。大きなサイトでは、通常、ワイヤー・フィード・サービスやその他のコンテンツ・アグリゲータをサブスクライブします。これらのソースからのストーリーは、人の手をほとんど介さずサイトに移動します。

Burlington Financialの主要セクションを構成する各ページ・アセットは、問合せアセットに関連付けられています。ワイヤー・フィード・セクションの場合、この問合せアセットにはソース・フィールドがWireFeedに設定されている記事アセットを検索するための問合せが含まれています。これらの問合せも各記事のカテゴリ・フィールドを確認します。Burlington Financialの各セクションにはストーリーの特定のカテゴリが含まれているため、ワイヤー・フィードの問合せではそれらのカテゴリとの一致が試行されます。

WireFeedと名付けられたページ・アセットには、それらのカテゴリとは無関係にワイヤー・フィード・ストーリーを返す問合せが含まれてます。

33.3.14 Featured Funds

資金セクションのフロント・ページ・テンプレートには、Featured Fundsという資金のリストが用意されています。このリストには、Engageセグメント・アセットを使用して選択された資金が記載されています。セグメント・アセットは、訪問者を共通した特徴に基づいてグループ化します。

セグメント・アセットを作成するには、まず訪問者のデータ・アセットを作成します。訪問者のデータ・アセットには、Webサイトへの訪問者に関する郵便番号などの情報が格納されます。セグメントを作成するには、セグメントの基となる訪問者データ・アセットを選択し、その基準の条件を満たす値を設定します。たとえば、郵便番号の訪問者データ・アセット内の値を使用して、地元企業の広告を表示する郵便番号セグメントを作成できます。

「Featured Funds」リストは、Webサイトの訪問者がBFfrequentvisitorセグメントまたはHighriskinvestorセグメントのいずれに属しているかに基づいて資金を表示します。

33.3.15 Fund Finder

Fund Finderは、選択した基準に基づいて資金を検索できるフォームです。一部の「Fund Finder」フォームのドロップダウンはフォームにハードコード化されます。ただし、フォームが検索するFund Familiesは、assetsetおよびsearchstateの概念を使用して動的にリストに記入されます。

searchstateは、属性値に基づく一連の検索絞込み条件です。

<SEARCHSTATE.CREATE NAME="ss"/>
<ASSETSET.SETSEARCHEDASSETS
NAME="as" ASSETTYPES="ProductGroups"
CONSTRAINT="ss"/>
<ASSETSET.GETATTRIBUTEVALUES
NAME="as" TYPENAME="PAttributes"
ATTRIBUTE="FundFamily"
LISTVARNAME="fflist"/>

<P>
<SELECT name="FundFamily" SIZE="3" MULTIPLE="1">
<OPTION SELECTED="" VALUE="NoPreference"/>No Preference
<LOOP LIST="fflist"><OPTION/><csvar NAME="fflist.value"/>
</LOOP>
</SELECT>
</P>

33.3.16 ページ・キャッシュ・パラメータ

デフォルトでは、Templateアセットを保存する際に作成されるどのSiteCatalogページ・エントリにも、cacheinfoプロパティがcs.pgcachefolder,*に設定されます。ただし、ページをキャッシュしない選択もあります。

BurlingtonFinancial/Util/LoginPostやBurlingtonFinancial/Page/AccountAccessなどのページは、特にcs.nevercacheに設定されます。それらのページは訪問者専用であるため、この設定は必要です。また、特定の訪問者に別の訪問者のキャッシュ済ページの結果を表示しない必要があります。実際のお客様サイトでは、キャッシュを各ページで微調整する必要があります。

WebCenter Sitesには、SiteCatalogエントリの作成に対応した一連のデフォルト・ページ基準が用意されています。その他のページ基準の変数を追加することも可能ですが、デフォルト値は削除できません。キャッシュおよびページ基準の詳細は、第5章「ページのデザインとキャッシング」を参照してください。

34 WebCenter SitesのAdminインタフェースのカスタマイズ

WebCenter Sitesの管理ユーザーおよび編集ユーザーは、Adminインタフェースに表示される様々なツリーを通して製品と対話します。こうしたツリーの変更により、WebCenter SitesのAdminインタフェースをカスタマイズできます。

この章では、ツリーの変更方法について説明します。この章は、次の項で構成されています。

- 第34.1項「ツリーの概要」

- 第34.2項「ツリーとセキュリティ」

- 第34.3項「ツリーのエラー・ロギング」

34.1 ツリーの概要

次のスクリーン・キャプチャに示すように、ツリーは一連のタブとして、WebCenter SitesのAdminインタフェースの左側のペインに表示されます。

WebCenter Sitesのツリー・タブは、ツリー・アプレットにより作成されます。ツリー・アプレットに渡される様々なパラメータを設定することにより、独自のツリーの作成または変更が可能です。ツリー・アプレットは、次に示す各種のパラメータを受け入れます。

- アプレット全体のパラメータ: アプレットの全体的な外観および動作を制御します。

- ツリー固有のパラメータ: ツリーの外観および動作を制御します。

- ノードのパラメータ: ツリーの個別ノードの外観および動作を制御します。

- OpURLノードのパラメータ: ツリーとWebCenter Sitesの通信を可能にします。

データベースにある一連のツリー・タブ表には、タブ名、どのロールがタブへのアクセス権を持つか、およびツリー・タブにデータを移入するエレメントへのパスなど、ツリー構成に関する情報が格納されます。これらの表には、「ツリー・タブ」画面を使用して情報を入力します。この画面には、Adminインタフェースを使用して「管理」タブを選択し、「ツリー」ノードをクリックしてアクセスします。

この項の内容は、次のとおりです。

- 第34.1.1項「ツリー・タブのロード」

- 第34.1.2項「ツリーのリフレッシュ」

34.1.1 ツリー・タブのロード

WebCenter Sitesで提供されているデフォルトのツリー・タブのほとんどは、OpenMarket/Gator/UIFramework/LoadTabエレメントを通して渡されるツリー・データを要求します。LoadTabエレメントは、セッション・タイムアウトのチェックなど、複数の基本タスクを実行します。

たとえば、GEサンプル・サイトにある「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エレメントがコールされます。このエレメントにより、「Products」タブからコールされた、各ツリーをロードするエレメントに対して、GetTypesコマンドが送信されます。ツリーをロードするエレメントにより、このコマンドが受信されると、スタート・メニュー・アイテムをグローバル・コンテキスト・メニューに表示する、アセット・タイプのリストが返されます。

6. OpenMarket/Gator/UIFramework/LoadGlobalPopupエレメントにより、指定されたアセット・タイプのスタート・メニュー・アイテムが検索され、その情報が元のツリーにストリームされます。

システムの各アセット・タイプには、LoadTreeエレメントが必要なことに注意してください。LoadTreeエレメントは、実際にツリーをロードする、別のエレメントへのポインタです。アセット・タイプが子を持つことが可能な場合、それぞれの子は、LoadTreeエレメントを持つ必要があります。LoadTreeエレメントのパスは次のとおりです。

OpenMarket/Xcelrate/AssetType/MyAssetType/LoadTree

MyAssetTypeは、LoadTreeエレメントにより参照されるアセット・タイプの名前です。

LoadTreeエレメントは、「ツリーの管理」フォームのSectionフィールドに設定されたアセット・タイプに基づいてコールされます。

コア・アセット・タイプでは、複数あるエレメントの1つを使用することで、ツリーがロードされます。次の表は、これらのエレメントのリストで構成されています。

表34-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 Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

ツリー・ノードの変更の詳細は、第34.1.1.3項「ノードのパラメータ」を参照してください。

34.1.1.1 アプレット全体のパラメータ

アプレット全体のパラメータは、TreeAppletParams.xmlエレメントに設定されています。ツリー・アプレットの動作を変更するには、そこに設定されているパラメータ値を、次の表に示すとおりに変更します。

表34-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(ブラウザのウィンドウの右側にあるペインの名前)です。

34.1.1.2 ツリー固有のパラメータ

ツリー固有のパラメータは、「新規ツリー・タブの追加」フォームと「新規ツリー・タブの追加」フォームを作成するOpenMarket\Gator\UIFramework\TreeTabAdd.xmlエレメントにより設定されます。ツリーの外観または動作を変更するには、次の表に示すパラメータ値を変更します。パラメータ値を変更するには、フォームを使用するか、TreeTabAddエレメントを変更します。

表34-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フィールドで設定されます。

34.1.1.3 ノードのパラメータ

ノードのパラメータにより、ツリーのノードの外観および動作が決定されます。これらのノードの外観および動作を定義するには、エレメントを記述します。そのエレメントによって、次の表に示すノードのパラメータを設定し、ツリーのノードを作成するBuildTreeNode.xmlエレメントに値を渡します。

表34-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には、ツリー・アプレットがノードの子を検索できるよう、十分な情報が含まれている必要があります。たとえば、階層が次のような場合、

製品タブ/Reebok社/ランニング・シューズ

LoadURLの値は次のようになります。

ContentServer?pagename=OpenMarket/Gator/UIFramework/LoadTab&AssetType=ProductGroups&populate=OpenMarket/Xcelerate/AssetType/ProductGroups/LoadTree&op=load&parent=Variables.parentid

parentidは、ランニング・シューズ・アセットのアセット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に設定します

34.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>

34.1.2 ツリーのリフレッシュ

ツリーを変更可能なエレメントでは、ツリーが現在のデータを表示するようにリフレッシュする必要があります。指定可能なリフレッシュ・アクションには、次の3種類があります。

- Self: 指定されたノードの子をリフレッシュします

- Parent: 指定されたノードおよびその子をリフレッシュします

- Root: ツリー全体をリフレッシュします

ツリーをリフレッシュする手順には次の2つがあります。

1. ツリーをカスタマイズするエレメントをコーディングし、リフレッシュ対象のツリー・ノードがRefreshKeysを保持するようにします。RefreshKeysは、リフレッシュの発生を許可するキー(通常は現在のノードのアセットID)です。

2. OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTreeエレメントをコールして_TreeRefreshKeys_変数を渡し、目的のリフレッシュのタイプを可変の値で指定します。

ノードのRefreshKeysは、BuildTreeNodeエレメントにRefreshKeys引数を渡して設定します。第34.1.1.3項「ノードのパラメータ」にコードのサンプルを示します。

ツリーをリフレッシュするには、OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTreeエレメントを、次の例に示すとおりにコールします。

<CALLELEMENT NAME="OpenMarket/Xcelerate/UIFramework/UpdateTreeOMTree">
<ARGUMENT NAME= "_TreeRefreshKeys_" VALUE= "Root:ActiveList"/>
</CALLELEMENT>

34.2 ツリーとセキュリティ

WebCenter Sitesでは、SitesのAdminインタフェースでツリーへのアクセスを制御するためにロールを使用します。システム定義の「管理」タブ、「サイト管理者」タブ、および「ワークフロー」タブについても、それらのタブのユーザーはxceladmin ACLを持っている必要があります。

追加の制御を使用できるようにするには、futuretense_xcel.iniのプロパティを設定します。たとえば、xcelerate.showSiteTreeでは、デフォルトでツリーを表示するかどうかを決定します。また、xcelerate.restrictSiteTreeでは、どのユーザーがツリーを表示または非表示にできるかを決定します。ツリーとセキュリティの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

34.3 ツリーのエラー・ロギング

ツリー関連のエラーおよびデバッグ・メッセージは、すべてJavaコンソールにログ出力されます。ツリーの作成時にDebugパラメータに値を指定することで、デバッグのオン/オフを切り替えることができます。

デバッグを有効にするとパフォーマンスに影響するため、配信システムでは通常、エラー・ロギングをオフにしておいてください。

35 ワークフローのカスタマイズ

WebCenter Sitesのワークフロー・プロセスは、アセットがパブリッシュの過程で通過する一連の状態です。アセットはワークフロー・ステップを進み、ある状態から次の状態へ移行します。アセットの各ステップは、時間指定アクションに関連付けできます。たとえば、アセットが割り当てられるときに、電子メールをユーザーに送信する場合です。また、ワークフロー・ステップ条件に関連付けて、一定の条件が満たされていない場合、アセットが次のステップへ進むのを防ぐことが可能です。

ワークフロー・ステップの条件エレメントを作成し、アセットが次の状態へ移行するために満たす必要のある条件を指定する必要があります。また、アセットがある状態から次の状態へ移行するときに、様々なアクションを行う、ワークフロー・アクションのエレメントを作成する必要があります。この章では、これらのエレメントについてさらに詳細に説明し、各エレメント・タイプのサンプル・コードを示します。

この章には次の項が含まれます。

- 第35.1項「ワークフロー・ステップ条件」

- 第35.2項「ワークフロー・アクション」

35.1 ワークフロー・ステップ条件

ワークフロー・プロセスは、1つ以上のワークフロー状態で構成されます。ワークフロー・ステップにより、アセットはあるワークフロー状態から次の状態へ移行します。ただし、場合によっては、アセットが次のワークフロー状態に移行しないようにする条件があります。アセットが次の状態に移行しないようにする条件(複数可)を定義したエレメントを作成する必要があります。

このエレメントは、コールされると次のデータを受信します。

- ObjectというIWorkflowableオブジェクト: 状態が変更されているアセットを表します。

- StepというIWorkflowStepオブジェクト: 現在のワークフロー・ステップを表します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- WebCenter Sitesのユーザー・インタフェースにステップ条件が定義されている場合、変数は名前と値のペアとして指定されます。ステップ条件の定義の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

ワークフロー・ステップ条件のエレメントは、条件をチェックし、ブール値を返します。値がfalseの場合は、次のステップへ進みません。

次のコードは、ワークフロー・ステップ条件エレメントのサンプルから抜粋したものです。

例35-1

1. <?xml version="1.0" ?>

2. <!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

3. <FTCS Version="1.1">

4. <!-- OpenMarket/Xcelerate/Actions/Workflow/StepConditions/ExampleStepCondition

5. -

6. - INPUT

7. -

8. - OUTPUT

9. -

10. -->

11. <csvar NAME="This step condition will check if step can be taken"/><br/>

次に示すコードの1行目では、空のReturnVal変数を設定しています。例35-6の4行目と9行目では、この変数に、次のステップに進めない理由が設定されます。

例35-2

1. <setvar NAME="ReturnVal" VALUE="Variables.empty"/>

2. <!--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タグを使用してワークフロー内のアセットの名前を取得します。

例35-3

1. <!-- get asset -->

2. <WORKFLOWABLEOBJECT.GETDISPLAYABLENAME OBJECT="Object" VARNAME="assetdisplayablename"/>

3. Object:<csvar NAME="Variables.assetdisplayablename"/><br/>

次に示すコードの2行目では、StepUserという変数を作成し、ステップを進めようとするユーザーのIDを格納します。3行目では、USERMANAGER.GETUSERタグを使用して、ユーザーのIDをStepUser変数にロードします。4行目では、CCUSER.GETNAMEタグを使用して、判読可能なユーザー名を取得します。また、5行目では、csvarタグを使用して、そのユーザー名を表示します。

例35-4

1. <!-- get userid -->

2. Userid: <csvar NAME="Variables.StepUser"/><br/>

3. <USERMANAGER.GETUSER OBJVARNAME="myUserObj" USER="Variables.StepUser"/>

4. <CCUSER.GETNAME NAME="myUserObj" VARNAME="uname"/>

5. Username: <csvar NAME="Variables.uname"/><br/>

次に示すコードの2行目では、WORKFLOWSTEP.GETIDタグを使用して現在のワークフロー・ステップのIDを取得します。4行目で使用されているWORKFLOWSTEP.GETNAMEタグにより、指定された名前のステップがロードされます。

例35-5

1. <!-- getstep -->

2. <WORKFLOWSTEP.GETID NAME="Step" VARNAME="sid"/>

3. Stepid: <csvar NAME="Variables.sid "/>

4. <WORKFLOWSTEP.GETNAME NAME="Step" VARNAME="sname"/>

5. Stepname: <csvar NAME="Variables.sname"/><br/><br/>

次に示すコードでは、ステップの変更を停止する条件を定義します。forcestop変数およびnotalloweduser変数は条件チェックであり、WebCenter Sitesのインタフェースに、サンプルのステップ条件が定義された場合は、引数として設定されます。実際のステップ条件では、ここで任意の条件(たとえば、記事アセットに関連付けられたイメージがないか確認する)を設定してテストします。

例35-6

1. <!-- This is the actual condition to stop the step. The following is just an example. -->

2. <if COND="Variables.forcestop=true">

3. <then>

4. <setvar NAME="ReturnVal" VALUE="You can not take this step because forcestop=true"/>

5. <then>

6. <else>

7. <if COND="Variables.uname=Variables.notalloweduser">

8. <then>

9. <setvar NAME="ReturnVal" VALUE="You are not allowed to take this step"/>

10. <then>

11. </if>

12. <else>

13. </if>

14. </FTCS>

35.2 ワークフロー・アクション

アセットはワークフロー間を移動するときに、ワークフロー・アクションをトリガーできます。ワークフロー・アクションでは、電子メールの送信から、指定された時間の経過後に、デッドロックの解除を評価する必要がある新しいアセットがあるというユーザーへの警告まで、あらゆるアクションが可能です。ワークフロー・アクションには、次の5つの種類があります。

- ステップ・アクション。ワークフロー状態間の遷移の一部として実行されます。

- 時間指定アクション。アセットが特定の状態になると、期限によりトリガーされます。たとえば、アセットが固有の割当てに関連付けられます。

- デッドロック・アクション。次の状態に移行するために、アセットが全員一致の票決を要する場合に実行されますが、アセットがどのステップに進むかによって投票者が異なります。デッドロック・アクションは、アセットの移行先として、ユーザーが別々のステップを選択した場合に実行されます。

- グループ・デッドロック時のアクション。次の状態に移行するために、ワークフロー・グループ内のアセットが全員一致の票決を要する場合に実行されますが、投票者が別々のステップを選択した場合、デッドロックが発生します。

- 委任アクション。アセットが委任された場合に実行されます。委任済のアセットは現在のワークフロー状態のままですが、新しいユーザーに割り当てられます。

最初に、ワークフローの管理者が、WebCenter Sitesのユーザー・インタフェースを使用して、ワークフロー・アクションを定義する必要があります。その後、これらのワークフロー・アクションを実行するエレメントを作成する必要があります。WebCenter Sitesでは、参照用に複数のワークフロー・アクション定義のサンプルが提供されています。ワークフロー・アクションの定義の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

次の各項では、ワークフロー・アクションのサンプル・エレメントについて説明します。

- 第35.2.1項「ステップ・アクションのエレメント」

- 第35.2.2項「時間指定アクションのエレメント」

- 第35.2.3項「デッドロック・アクションのエレメント」

- 第35.2.4項「グループ・デッドロック時のアクションのエレメント」

- 第35.2.5項「委任アクションのエレメント」

35.2.1 ステップ・アクションのエレメント

ステップ・アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- ObjectTotal変数: 状態が変更されているアセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: 状態が変更されているアセットを表します。nnnは、0(ゼロ)とObjectTotal -1の間の数です。

- StepというIWorkflowStepオブジェクト: 検討対象になっているワークフロー・ステップを表します。

- StepTargetUser変数: ステップのターゲット・ユーザーのカンマ区切りリストです。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- Group変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこのステップ・アクションの定義中に作成した任意の変数。

次のステップ・アクションのエレメントにより、アセットのパブリッシュが承認されます。その他のほとんどのステップ・アクションのエレメントは、割当て先に電子メールを送信するものです。

例35-7

1. <?xml version="1.0" ?>

2. <!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

3. <FTCS Version="1.1">

4. <!-- OpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublish

5. -

6. - INPUT

7. - Variables.ObjectTotal - number of loaded workflowasset objects

8. - Object[n] - loaded workflowasset objects, where n = 0 - Variables.ObjectTotal

9. -targets - one or more comma separated names of PubTargets for which to approve the asset

10. -

11. - OUTPUT

12. -

13. -->

14. <!-- This is an action element called by step actions ApproveForPublish-->

15. This step action element will approve an asset for publish.<br/>

次に示すコードの2行目では、SETCOUNTERタグを使用して、承認するアセットの数を記録するカウンタを作成します。3行目から9行目では、LOOPタグを使用し、アセット間をループしてアセット・タイプとIDを取得します。

例35-8

1. <!-- get the id and assettype of the asset(s) to approve -->

2. <SETCOUNTER NAME="count" VALUE="0"/>

3. <LOOP COUNT="Variables.ObjectTotal">

4. <WORKFLOWASSET.GETASSETTYPE OBJECT="ObjectCounters.count" VARNAME="assettype"/>

5. <WORKFLOWASSET.GETASSETID OBJECT="ObjectCounters.count" VARNAME="assetid"/>

6. <SETVAR NAME="idCounters.count" VALUE="Variables.assetid"/>

7. <SETVAR NAME="typeCounters.count" VALUE="Variables.assettype"/>

8. <INCCOUNTER NAME="count" VALUE="1"/>

9. </LOOP>

次に示すコードの2行目では、STRINGLISTタグを使用して、パブリッシュ・ターゲット名のカンマ区切りリストを作成します。6行目から21行目では、このリスト内をループし、PUBTARGET.LOADタグとPUBTARGET.GETタグを使用して、パブリッシュ・ターゲットに関する情報をPubTarget表からロードします。この情報および承認されるアセットに関する情報は、12行目でApprovePostエレメントに渡され、さらに処理されます。

例35-9

1. <!-- approve for each destination -->

2. <STRINGLIST NAME="publishTargets" STR="Variables.targets" DELIM=","/>

3. <if COND="IsList.publishTargets=true">

4. <then>

5. <LOOP LIST="publishTargets">

6. <PUBTARGET.LOAD NAME="pubtgt" FIELD="name" VALUE="publishTargets.ITEM"/>

7. <if COND="IsError.Variables.errno=false">

8. <then>

9. Approving for publish to <CSVAR NAME="publishTargets.ITEM"/><br/>

10. <PUBTARGET.GET NAME="pubtgt" FIELD="id" OUTPUT="pubtgt:id"/>

11. <CALLELEMENT NAME="OpenMarket/Xcelerate/PrologActions/ApprovePost">

12. <ARGUMENT NAME="targetid" VALUE="Variables.pubtgt:id"/>

13. <ARGUMENT NAME="assetTotal" VALUE="Counters.count"/>

14. </CALLELEMENT>

15. <then>

16. <else>

17. Cannot approve for publish to destination: <CSVAR NAME="publishTargets.ITEM"/>, Error: <CSVAR NAME="Variables.errno"/>

18. <else>

19. </if>

20. </LOOP>

21. <then>

22. <else>

23. Cannot approve for publish. This step action requires a targets argument with one or more comma separated publishing destination names.

24. <else>

25. </if>

26. </FTCS>

35.2.2 時間指定アクションのエレメント

時間指定アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- WorkflowAssignmentTotal変数: このアクションが適用される割当ての総数を格納します。

- WorkflowAssignmentnnnというIWorkflowAssignmentオブジェクト: アクションの適用先の割当てを表します。nnnは、0(ゼロ)より大きい数です。

- オプションのGroup変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこの時間指定アクションの定義中に作成した任意の変数。

電子メールを送信する、時間指定アクション・エレメントの一部を次に示します。この電子メールの件名および本文のテキストは、「ワークフロー電子メール」フォームに設定されています。このフォームには、WebCenter Sitesのユーザー・インタフェースにある「管理」タブからアクセスします。本文テキストに予想される変数は次のとおりです。

- Variables.assetname: 現在のアセットの名前を格納します。

- Variables.assigner: ワークフロー・プロセス内で1つ前の状態を完了したユーザーの名前。

- Variables.instruction: 割当て者が割当ての完了時に、「実行するアクション」テキスト・ボックスに入力するテキスト。

次に示すコードの2行目と5行目では、電子メール・オブジェクトの変数であるsubjectおよびbodyが、その値に置換されます。

例35-10

1. <!-- translate subject -->

2. <EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="assetname=Variables.assetname" VARNAME="subject"/>

3. <!-- translate body -->

4. <EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="assetname=Variables.assetname&#38;time=Variables.time" VARNAME="body"/>

5. <!-- send mail -->

6. <sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>

7. </THEN>

8. <ELSE>

9. Email address: None<br/>

10. </ELSE>

11. </IF>

12. <inccounter NAME="COUNT" VALUE="1"/>

13. </loop>

14. <then>

15. </if>

16. </FTCS>

35.2.3 デッドロック・アクションのエレメント

デッドロック・アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineオブジェクト。

- ObjectTotal変数: デッドロック済アセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: デッドロック済アセットを表します。

- StepというIWorkflowStepオブジェクト: ワークフロー・ステップを表します。

- StepTotal変数: 個々のユーザーによって選択されたステップの数を格納します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- オプションのGroup変数: アセットの所属先ワークフロー・グループのIDを格納します(ワークフロー・グループを使用している場合)。

- ワークフローの管理者がこのデッドロック・アクションの定義中に作成した任意の変数。

次のデッドロック・アクション・エレメントは、アセットを承認するユーザーに電子メールを送信します。

この電子メールの件名および本文のテキストは、WebCenter Sitesの管理ユーザー・インタフェースにある「ワークフロー電子メール」フォームに設定されています。本文テキストに予想される変数は次のとおりです。

- Variables.assetname: 現在のアセットの名前を格納します。

- Variables.headerとVariables.message: 電子メールの本文のテキストを格納します。

例35-11

1. <?xml version="1.0" ?>

2. <!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

3. <FTCS Version="1.1">

4. <!-- OpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/SendEmailToAssignees

5. -

6. - INPUT

7. -

8. - OUTPUT

9. -

10. -->

11. <!-- This is an action element called by step actions SendAssignmentEmail and SendRejectionEmail-->

12. <csvar NAME="This deadlock action element will send emails"/><br/>

次に示すコードの2行目では、EMAILMANAGER.LOADタグを使用して、電子メール・オブジェクトをロードします。

例35-12

1. <!-- load email object -->

2. <EMAILMANAGER.LOAD NAME="Variables.emailname" OBJVARNAME="emailobject"/>

次に示すコードの1行目から9行目では、NumOfSteps変数を作成します。この変数には、委任されているアセットの総数または0(ゼロ)のいずれかが格納されます。

例35-13

1. <!-- get total steps -->

2. <if COND="IsVariable.StepTotal=true">

3. <then>

4. <setvar NAME="NumOfSteps" VALUE="Variables.StepTotal"/>

5. <then>

6. <else>

7. <setvar NAME="NumOfSteps" VALUE="0"/>

8. <else>

9. </if>

10. <removevar NAME="Step"/>

11. <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:"/>

12. <setvar NAME="Message" VALUE="Variables.empty"/>

次に示す3つのコード例(例35-14、例35-15、および例35-16)では、アセットをデッドロック状態にしたユーザーのリスト内をループして、ユーザーごとに電子メールを作成します。次に示すコードの10行目では、USERMANAGER.GETUSERタグを使用して、IDで指定されたユーザーのユーザー情報をロードします。11行目と12行目では、CCUSERタグを使用して、ユーザーの名前と電子メール・アドレスを取得します。

例35-14

1. <!-- For each assignment object, get asignee -->

2. <setcounter NAME="COUNT" VALUE="0"/>

3. <if COND="Variables.NumOfSteps!=0">

4. <then>

5. <loop FROM="0" COUNT="Variables.NumOfSteps">

6. <!-- get assigner -->

7. <setvar NAME="userid" VALUE="Variables.StepUserCounters.COUNT"/>

8. <!-- get email address --->

9. <USERMANAGER.GETUSER USER="Variables.userid" OBJVARNAME="userobj"/>

10. <CCUSER.GETNAME NAME="userobj" VARNAME="user_name"/>

11. <CCUSER.GETEMAIL NAME="userobj" VARNAME="EmailAddress"/>

次に示すコードの1行目から6行目では、WORKFLOWSTEPタグとWORKFLOWSTATEタグを使用して、アセットの開始および終了のステップと状態を取得します。

例35-15

1. <WORKFLOWSTEP.GETNAME NAME="StepCounters.COUNT" VARNAME="stepname"/>

2. <WORKFLOWSTEP.GETSTARTSTATE NAME="StepCounters.COUNT" VARNAME="startstate"/>

3. <WORKFLOWSTEP.GETENDSTATE NAME="StepCounters.COUNT" VARNAME="endstate"/>

4. <WORKFLOWSTATE.GETSTATENAME NAME="Variables.startstate" VARNAME="startstatename"/>

5. <WORKFLOWSTATE.GETSTATENAME NAME="Variables.endstate" VARNAME="endstatename"/>

6. <setvar NAME="Message" VALUE="Variables.Message Variables.user_name: Variables.stepname - "/>

7. <!--

8. user:<csvar NAME="Variables.user_name"/><br/>

9. step name:<csvar NAME="Variables.stepname"/><br/>

10. startstate name:<csvar NAME="Variables.startstate"/><br/>

11. endstate name:<csvar NAME="Variables.endstate"/><br/>

12. -->

13. <!-- get asset -->

14. <WORKFLOWABLEOBJECT.GETDISPLAYABLENAME NAME="Variables.ObjectCounters.COUNT" VARNAME="assetname"/>

次に示すコードの3行目と6行目では、電子メール・オブジェクトの変数であるsubjectおよびbodyが、その値に置換されます。

例35-16

1. <!-- translate subject -->

2. <SETVAR NAME="params" VALUE="username=Variables.user_name&#38;header=Variables.Header&#38;message=Variables.Message&#38;assetname=Variables.assetname"/>

3. <EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="Variables.params" VARNAME="subject"/>

4. <!-- translate body -->

5. <EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="Variables.params" VARNAME="body"/>

6. <!-- send mail -->

7. <sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>

8. <inccounter NAME="COUNT" VALUE="1"/>

9. </loop>

10. <then>

11. </if>

12. email message:<csvar NAME="Variables.Header Variables.Message"/><br/>

13. </FTCS>

35.2.4 グループ・デッドロック時のアクションのエレメント

グループ・デッドロック時のアクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- ObjectTotal変数: デッドロック済アセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: デッドロック済アセットを表します。nnnは、0(ゼロ)より大きい数です。

- StepというIWorkflowStepオブジェクト: ワークフロー・ステップを表します。

- StepTotal変数: 個々のユーザーによって選択されたステップの数を格納します。

- StepUser変数: ステップを進めようとするユーザーのIDを格納します。

- Group変数: デッドロックされたワークフロー・グループのIDを格納します。

- ワークフローの管理者がこのグループ・デッドロック時のアクションの定義中に作成した任意の変数。

次のグループ・デッドロック時のアクション・エレメントは、アセットを承認するユーザーに電子メールを送信します。

この電子メールの件名および本文のテキストは、WebCenter Sitesの管理ユーザー・インタフェースにある「ワークフロー電子メール」フォームに設定されています。本文テキストに予想される変数は次のとおりです。

- Variables.assetname: 現在のアセットの名前を格納します。

- Variables.headerとVariables.message: 電子メールの本文のテキストを格納します。

例35-17

1. <?xml version="1.0" ?>

2. <!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">

3. <FTCS Version="1.1">

4. <!-- OpenMarket/Xcelerate/Actions/Workflow/GroupActions/SendEmailToAssignees

5. -

6. - INPUT

7. -

8. - OUTPUT

9. -

10. -->

11. <!-- user code goes here -->

12. <csvar NAME="This group deadlock action element will send emails"/><br/>

13. <!-- load email object -->

14. <EMAILMANAGER.LOAD NAME="Variables.emailname" OBJVARNAME="emailobject"/>

15. <!-- get group -->

16. <WORKFLOWENGINE.GETGROUPID ID="Variables.Group" OBJVARNAME="grpobj"/>

17. <WORKFLOWGROUP.GETNAME NAME="grpobj" VARNAME="GroupName"/>

18. <!-- get total steps -->

19. <if COND="IsVariable.StepTotal=true">

20. <then>

21. <setvar NAME="NumOfSteps" VALUE="Variables.StepTotal"/>

22. <then>

23. <else>

24. <setvar NAME="NumOfSteps" VALUE="0"/>

25. <else>

26. </if>

27. <removevar NAME="Step"/>

28. <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:"/>

29. <setvar NAME="Message" VALUE="Variables.empty"/>

30. <!-- For each assignment object, get asignee -->

31. <setcounter NAME="COUNT" VALUE="0"/>

32. <if COND="Variables.NumOfSteps!=0">

33. <then>

34. <loop FROM="0" COUNT="Variables.NumOfSteps">

35. <!-- get assigner -->

36. <setvar NAME="userid" VALUE="Variables.StepUserCounters.COUNT"/>

37. <!-- get email address --->

38. <USERMANAGER.GETUSER USER="Variables.userid" OBJVARNAME="userobj"/>

39. <CCUSER.GETNAME NAME="userobj" VARNAME="user_name"/>

40. <CCUSER.GETEMAIL NAME="userobj" VARNAME="EmailAddress"/>

41. <WORKFLOWSTEP.GETNAME NAME="StepCounters.COUNT" VARNAME="stepname"/>

42. <WORKFLOWSTEP.GETSTARTSTATE NAME="StepCounters.COUNT" VARNAME="startstate"/>

43. <WORKFLOWSTEP.GETENDSTATE NAME="StepCounters.COUNT" VARNAME="endstate"/>

44. <WORKFLOWSTATE.GETSTATENAME NAME="Variables.startstate" VARNAME="startstatename"/>

45. <WORKFLOWSTATE.GETSTATENAME NAME="Variables.endstate" VARNAME="endstatename"/>

46. <!-- get asset -->

47. <WORKFLOWABLEOBJECT.GETDISPLAYABLENAME NAME="Variables.ObjectCounters.COUNT" VARNAME="assetname"/>

48. <!-- set message -->

49. <setvar NAME="Message" VALUE="Variables.Message Asset: Variables.assetname, User: Variables.user_name, Step: Variables.stepname -- "/>

50. <!-- translate subject -->

51. <SETVAR NAME="params" VALUE="username=Variables.user_name&#38;header=Variables.Header&#38;message=Variables.Message&#38;assetname=Variables.assetname"/>

52. <EMAIL.TRANSLATESUBJECT NAME="emailobject" PARAMS="Variables.params" VARNAME="subject"/>

53. <!-- translate body -->

54. <EMAIL.TRANSLATEBODY NAME="emailobject" PARAMS="Variables.params" VARNAME="body"/>

55. <!-- send mail -->

56. <sendmail TO="Variables.EmailAddress" SUBJECT="Variables.subject" BODY="Variables.body"/>

57. <inccounter NAME="COUNT" VALUE="1"/>

58. </loop>

59. <then>

60. </if>

61. email message:<csvar NAME="Variables.Header Variables.Message"/><br/>

62. </FTCS>

35.2.5 委任アクションのエレメント

委任アクションのエレメントは、コールされると次のデータを受信します。

- WorkflowEngineというWorkflowEngineオブジェクト。

- CurrentUser変数: アセットを委任しているユーザーのIDを格納します。

- オプションのGroup変数: ワークフロー・グループのIDを格納します。委任されるオブジェクトはすべて、同一のワークフロー・グループに存在する必要があります。

- ObjectTotal変数: 委任されているアセットの総数を表します。

- ObjectnnnというIWorkflowableオブジェクト: 委任されているアセットを表します。nnnは、0(ゼロ)より大きい数を表します。

委任アクションのエレメントは、ワークフロー・アクションの他のエレメント同様のコーディングをする必要があります。

36 Webサービスの理解

この章では、Webサービスの概要を示し、WebCenter Sitesで作業する方法について説明します。また、提供されている機能についても説明します。Webサービスは、WebCenter Sites製品の標準部分であり、追加のインストールや構成は必要ありません。

この章には次の項が含まれます。

- 第36.1項「Webサービスとは」

- 第36.2項「SOAPとWebサービス」

- 第36.3項「サポートされているSOAPバージョン」

- 第36.4項「サポートされているWSDLバージョン」

- 第36.5項「関連プログラミング・テクノロジ」

注意:

WebCenter Sites 11gリリース1 (11.1.1.8.0)では、SOAPベースのWebサービスの機能が非推奨になりました。この機能は、RESTサービスに置き換えられました。

36.1 Webサービスとは

WebCenter Sitesでは、独自のWebサービスを作成、配布および公開できるだけでなく、他のアプリケーションからのWebサービスを消費することもできます。Webサービスはインターネットで標準XMLメッセージングを介してアクセスできる操作のコレクションで、このサービスを使用するとプログラミング言語、オペレーション・システム、指定されたターゲット・システムで使用されるハードウェアからは独立して、データを交換できます。WebCenter Sitesでは、WebサービスによりERP (エンタープライズ・リソース・プランニング)、CRM (カスタマ・リレーションシップ・マネジメント)、商取引システムなど、リモート・アプリケーションによる消費に対するコンテンツや機能を公開する標準的な手段が提供されます。

36.2 SOAPとWebサービス

WebCenter Sitesとその他のアプリケーション間の統合は、HTTPデータ・フォームとXMLデータ・フォームを使用したデータの変換により達成されます。Webサービスの主要なXMLフォーマットは、SOAP(シンプル・オブジェクト・アクセス・プロトコル)です。SOAPは、HTTPを拡張したW3Cの仕様で、分散されたアプリケーションでのインターネットを経由したリモート・プロシージャ・コール(RPC)が可能になります。言語として、SOAPは、RPCスタイルのやり取りで必要なパラメータの説明、値の返しなどに使用されるXMLエレメントを定義します。SOAPメッセージはPoint-to-Pointで送信され、リクエスト・レスポンス方式で処理されます。WebCenter SitesはSOAPをサポートし、SOAPインタフェースが備わったどのアプリケーションともデータを交換できます。SOAPのリクエストを処理する際に、WebCenter SitesではXMLのネイティブなサポート、効率的なページ評価、および配信メカニズムが活用されます。

注意:

WebCenter Sitesでは、WebサービスにJWSDP (Sun)実装が使用されています。WebCenter Sitesがインストールされているアプリケーション・サーバーでも独自のWebサービスが実装されていると、SOAP MessageFactoryと競合が発生します。競合を解決するには、アプリケーション・サーバーを起動する前にVMパラメータ経由でデフォルトのMessageFactoryを設定する必要があります。このデフォルトの設定で、WebCenter SitesのWebサービスに使用する MessageFactoryが指定されます。

例:

JBossは独自のWebサービスを備えています。JBossのMessageFactoryを別の理由で使用し、WebCenter SitesのWebサービスも使用する場合、デフォルトのMessageFactoryを次のようにJBossのものに設定する必要があります。

-Djavax.xml.soap.MessageFactory=org.jboss.ws.core.soap.MessageFactoryImpl

WebCenter SitesのWebサービスのみが必要な場合には、デフォルトのMessageFactoryを次のように設定します。

-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl

36.3 サポートされているSOAPバージョン

WebCenter Sitesは、SOAP 1.1をサポートしています。WebCenter SitesのWebサービスを記述するには、SOAPプロトコルの機能と制限を知る必要があります。SOAP標準の構文の詳細は、次のW3C Webサイトを参照してください。

http://www.w3.org

36.4 サポートされているWSDLバージョン

WSDL (Webサービス記述言語)は、インターネット上で配信されるサービスを記述するXML形式です。WSDLファイルには、特定の操作に対するメッセージで渡されるサービスとデータの場所が記述されています。WebCenter Sitesに関しては、これらのメッセージにプロシージャ向けの情報が記載されています。

WebCenter SitesはWSDL 1.1をサポートしています。WebCenter SitesのWebサービスを記述し、WebCenter Sitesに付属の事前定義済WSDLファイルを使用するには、Webサービスの記述用のWebサービス記述言語について理解しておく必要があります。SOAPの標準構文の詳細は、次のW3C Webサイトを参照してください。

http://www.w3.org/TR/wsdl.html

36.5 関連プログラミング・テクノロジ

WebCenter SitesのWebサービスを記述するには、次の関連テクノロジの一部またはすべてを基本的に理解しておく必要があります。

- XML

- SOAP

- WSDL

- JSP

- Java

- J2EE (Java 2)

- .Net

37 Webサービスの作成と消費

この章では、Webサービス・プロトコルを使用して、WebCenter Sitesをインターネット経由でリモート・アプリケーションと統合する方法について説明します。ここでは、WebCenter Sitesの開発フレームワークと照らし合せて、基本的なWebサービスの作成および消費方法について述べます。

この章には次の項が含まれます。

- 第37.1項「事前定義されたWebサービスの使用」

- 第37.2項「カスタムWebサービスの作成」

注意:

WebCenter Sites 11gリリース1 (11.1.1.8.0)では、SOAPベースのWebサービスの機能が非推奨になりました。この機能は、RESTサービスに置き換えられました。

37.1 事前定義されたWebサービスの使用

WebCenter Sitesには、Webサービスとして実装されている一連の充実したアセット配信機能が付属しています。これらのサービスには、Webサービスを有効化するクライアントを作成できるテクノロジを使用してればアクセスできます。用意されたWebサービス機能は、既存のWebCenter Sites API (XML、JSP、JavaおよびCOM)に匹敵します。

提供されている各サービスは、複数のWebサービスの操作に関して記述されている事前定義されたWSDL (Webサービス記述言語)ファイルに記載されています。個々のWSDLファイルは、WebCenter Sitesの機能に関連したWebサービスの操作に関するインタフェースとメソッドを定義しています。関連した操作はグループ化され、機能に応じて、まとめて説明されています。

WSDLを使用して、クライアント・アプリケーションからのWebCenter Sitesとのやり取りに必要なコードを生成します。WSDLファイルを読み取る様々なサードバーティのアプリケーションを使用してクライアント・コードを自動的に生成するか、WSDLの説明を調べてスクラッチからクライアント・コードを記述して手動でクライアント・コードを生成します。その結果生成されたクライアント・スタブが、WebCenter Sitesとのやり取りで使用できる適切なインタフェースを構成します。実行時にはコードにより、WSDL操作に基づいてリクエストされたSOAPが作成されます。

通常は、クライアントとWebCenter Sitesとのやり取りを制御できます。ただし、潜在的に未知のクライアント・アプリケーションがアクセスした場合、提供されているWSDLファイルによりURLにポストし、リモート・アクセス用のUDDI (ユニバーサル・ディスクリプション、ディスカバリー、インテグレーション)を介して登録することも可能です。

この項の内容は、次のとおりです。

- 第37.1.1項「アクセス可能な情報」

- 第37.1.2項「WSDLファイルの場所」

- 第37.1.3項「事前定義されたWebサービスのプロセス・フロー」

- 第37.1.4項「事前定義されたWebサービスに対するデータの検討」

- 第37.1.5項「クライアント・インタフェースの生成」

- 第37.1.6項「クライアント・コールの記述」

37.1.1 アクセス可能な情報

SOAPをサポートし、事前定義されたWSDL仕様に従っているWebサービスであれば、WebCenter Sitesデータベースの次の情報にアクセスできます。

- コンテンツ管理サイトのサイト・マップ

- PDFファイルなどのBlobデータ

- コンテンツ管理サイトにおけるすべての有効なアセット・タイプとアセット・サブタイプのリスト

- 指定された検索基準に一致するアセットのリスト

- 特定のアセットに関連付けられたメタデータ

37.1.2 WSDLファイルの場所

WebCenter Sitesの事前定義されたWSDLファイルは、WebCenter Sitesアプリケーションを使用して次の場所に自動的にインストールされます。

http://install_dir/futuretense_cs/Xcelerate/wsdl/*.wsdl

37.1.3 事前定義されたWebサービスのプロセス・フロー

次の一般的な手順は、Webサービスのクライアント・プログラムからのリクエストを、提供されたWSDLファイルを使用して処理する方法を説明しています。

1. 提供されるWSDLファイルには、リクエスト(WebCenter Sitesで想定される入力データ)に対するフォーマットの説明、およびリターン・データのフォーマットが記載されています。WSDLファイルは、Java、Visual Basic、その他のプログラミング言語で記述されたアプリケーションの標準データ型をXMLスキーマ・データ型にマッピングします。

2. クライアント・プログラムはWSDLに記載された手順を使用して、データを入力ソース(構造化ファイルなど)から、WebCenter Sites Webサービス・インタフェースによる想定と一貫性のあるXMLスキーマに変換します。

3. クライアントは、必要なデータを格納するSOAPエンベロープを生成し、それをコンテンツ管理サイトに送信します。

4. WebCenter SitesはSOAPメッセージを受信します。

5. XMLパーサーと変換ユーティリティがSOAPメッセージ内のデータをWebCenter Sitesで要求されたフォーマットにマッピングします。

6. WebCenter Sitesでは、適切なシード・クラスが起動されます。

7. シードは特定のWebCenter Sitesアクションを起動します。

8. WebCenter Sitesによって、WSDLファイルで定義された出力フォーマットでリクエストされたデータ(名前/値のペア)がクライアント・アプリケーションに返されます。

9. クライアント・アプリケーションに対するSOAPプロセッサは、XMLスキーマ・データ型を、特定のプログラミング言語の使用に対応したネイティブのデータ型にマッピングします。

37.1.4 事前定義されたWebサービスに対するデータの検討

事前定義されたWSDL操作のデータは、RPCスタイルの相互作用(XMLドキュメント全体の交換と対比して)を使用してご使用のプログラムに渡されます。これらは通常文字列ですが、WebCenter Sitesには複雑なデータ型(たとえば、SearchStatesやILists)を使用したネイティブ・オブジェクトを処理するクラスも用意されています。

37.1.5 クライアント・インタフェースの生成

WSDLファイルを使用して、クライアント・アプリケーションのインタフェースを生成します。WSDLファイルからクライアント・コードを生成する様々なツールが使用できます。これらのツールは異なるプログラミング言語の出力をサポートしています。クライアント・アプリケーションのターゲット言語でコードを生成するツールを選択し、必要な操作が記述されているWSDLファイルでそれを実行します。その結果生成されるクライアント・スタブによって、すべてのWebCenter Sites操作が各クライアント・プログラムで使用できるようになります。

37.1.6 クライアント・コールの記述

WSDLファイルから生成されたコードにより、WebCenter Sites機能にインタフェースが提供されます。使用可能になると、必要に応じて、アプリケーションからこの機能をコールできるようになります。

37.2 カスタムWebサービスの作成

WebCenter Sitesを使用して、公開する任意のWebCenter Sites機能からのデータをマッピングするWebサービスを作成できます。XML、JavaおよびJSPがサポートされているため、既存のWebCenter Sites開発環境ではWebサービスの開発で使用しやすいプラットフォームが提供されています。提供されたタグ・セットにより、SOAPレスポンス、およびアプリケーションに対してデータをカプセル化するストリームSOAPを作成できるようになります。あらかじめ同梱されたWebサービスと同様、WebCenter Sites配信機能とページ評価パイプラインはSOAPリクエストの処理に使用されます。Webサービスでは、クライアントはブラウザではなく、プログラムです。

この項の内容は、次のとおりです。

- 第37.2.1項「Webサービス作成のプロセス・フロー」

- 第37.2.2項「カスタムWebサービスに対するデータの検討」

- 第37.2.3項「WebCenter Sitesページの作成」

- 第37.2.4項「WebCenter Sitesエレメントの記述」

- 第37.2.5項「WSDLファイルの作成」

37.2.1 Webサービス作成のプロセス・フロー

次の一般的な手順では、Webサービス・クライアント・プログラムからのリクエストを処理する方法について説明します。

1. クライアント・プログラムはSOAPで必要な入力すべてをラップし、WebCenter Sitesに渡します。

2. クライアントはWSDLファイルの手順を使用して、データを入力ソース(構造化ファイルなど)からWebCenter SitesのWebサービス・インタフェースによる想定と一貫性のあるXMLスキーマに変換します。

3. クライアントは、必要なデータを格納するSOAPエンベロープを生成し、それをコンテンツ管理サイトに送信します。

4. WebCenter SitesはSOAPメッセージを受信します。

5. XMLパーサーと変換ユーティリティがSOAPメッセージ内のデータをWebCenter Sitesで要求されたフォーマットにマッピングします。

6. WebCenter Sitesでは、適切なシード・クラスが起動されます。

7. シードは特定のWebCenter Sitesアクションを起動します。

8. WebCenter Sitesによって、WSDLファイルで定義された出力フォーマットでリクエストされたデータ(名前/値のペア)がクライアント・アプリケーションに返されます。

9. クライアント・アプリケーションに対するSOAPプロセッサは、使用される特定のプログラミング言語に対応したネイティブのデータ型にXMLスキーマ・データ型をマッピングします。

37.2.2 カスタムWebサービスに対するデータの検討

データは、RPCスタイルの相互作用(XMLドキュメント全体の交換と対比して)を使用して各プログラムに渡されます。データを検討し、単純XSIデータ型による処理を検証します。WebCenter Sitesでは、すべてのW3C XSIのプリミティブ・データ型を変更せずに使用できます。

注意:

複雑なWebサービスのデータ型はWebCenter Sitesでサポートできますが、独自のJavaクラスを作成してアプリケーション・サーバーでそれらを配布する必要があります。独自のデータ型を作成する場合には、事前にWebCenter Sitesテクニカル・サポートにお問い合せください。

37.2.3 WebCenter Sitesページの作成

各Webサービスは、SiteCatalog表にページ・エントリが必要です。SiteCatalogに対するページ・エントリは、Webサービスで記述されたWebCenter Sites機能をコールするエレメントを指す名前です。SiteCatalogには、Webサービスを起動するページなど、サイトにおけるページの有効なエントリが格納されています。

このページはクライアントからのリクエストによって起動されます。次に、WebCenter SitesからのレスポンスはSOAPでカプセル化され、クライアントに返されます。Webサービスではクライアントはプログラムで(ブラウザではない)、レスポンスはXMLです(HTMLではない)。

Webサービスに対応したWebCenter Sitesページを作成するには

1. Oracle WebCenter Sites Explorerを起動し、WebCenter Sitesにログインします。手順は、オンライン・ヘルプかこのガイドの手順を参照してください。

2. 左ペインで、SiteCatalog表を開きます。

3. サイトのフォルダを選択します。

4. 「Pagename」フィールドで、SiteCatalog表内にWebサービス向けページ名の最後の部分のエントリを作成します。

5. 「ルート・エレメント」フィールドで、Webサービスのルート・エントリを作成します。(SiteCatalogルートにSiteCatalogエントリを追加すると表のルックアップが回避され、最初の子エレメントのエレメント名が特定のページ名に確実にマッピングされます。)

6. いずれかの「resargs」フィールドで、適切な場合には、次のオプションの引数を追加します。

- cs.session=falseは、SOAPリクエストのライフに対するアプリケーション・サーバーのセッション管理を回避します。その際、既存のセッション・オブジェクトを使用したり、現在のリクエストのかわりに新規セッション・オブジェクトを作成しません。これにより、ネイティブ・リクエストおよびセッションの永続性を必要としないクライアントからのリクエストに対するアプリケーション・サーバーのロードが軽減され、パフォーマンスが向上します。どのページでもサポートされていますが、cs.session=false resargは、主にSOAPサービスでの使用を対象としています。

- cs.contenttype=text/xmlは、処理用ルート・エレメントを準備します。特に、これによりXMLエンジンがタグ上の名前空間を適切に順守し、デフォルトHTMLの圧縮が回避されます。これが必要となるのは、ブラウザ経由のリクエストを想定する場合のみです。Webサービス・リクエストが常にSOAPリクエストとして受信される場合を除いて、このresargを各SiteCatalogエントリに追加してHTML圧縮をオーバーライドする必要があります。ご使用の入力XMLが整形式であれば、コンテンツの出力は間違いなく適切なXMLになると考えられます。

7. 「csstatus」フィールドに、Liveと入力するか、この場合の適切なステータスを入力します。

8. 「ファイル」→「すべて保存」を選択するか、ツールバー・ボタンの「すべて保存」をクリックして作業内容を保存します。

37.2.4 WebCenter Sitesエレメントの記述

WebCenter Sitesエレメントには、公開する機能のコードが記述されています。このエレメントはデータを処理し、SOAPレスポンスをフォーマットします。SOAPレスポンスをフォーマットするには、WebCenter Sitesで提供されたSOAP XMLタグをコードに追加します。WebCenter Sitesは、自動的にSOAPエンベロープに対するXMLを生成します。

XMLおよびJSPでWebサービスに対して記述されたWebCenter Sitesエレメントには、別の空白やコメントを追加できません。これは、HTMLとは異なり、XMLやそのSOAPの実装では解析の要件が厳しいためです。XMLおよびJSPのページはHTMLページと同じ方法で処理され、WebCenter Sitesでフィルタされないため、空白やコメントを追加するとSOAPメッセージが破損する可能性があります。コメント(XMLまたはJSP)が表示されるのは、soap.messageタグの後のみです。

Webサービスのエレメントを記述するには

1. Oracle WebCenter Sites Explorerを起動してWebCenter Sitesにログインします(まだログインしていない場合)。手順は、オンライン・ヘルプかこのガイドを参照してください。

2. 左ペインで、ElementCatalog表を選択してハイライトします。

3. ElementCatalog表で新規フォルダを作成します(「ファイル」→「新規フォルダ」を選択します)。

4. 新規フォルダを選択してハイライトし、右ペイン内の任意の場所で右クリックして、コンテキスト・メニューから「新規」を選択します。
表内に新しい行が表示されます。

5. 「エレメント名」フィールドに、エレメント名として適切なWebサービス名を入力します。

6. 「説明」フィールドに、エレメントの短い説明を入力します。

7. 「url」フィールド内でクリックして、表示されたボタンをクリックします。
「新規ファイル」ダイアログ・ボックスが表示されます。

8. 「タイプ/拡張子」フィールドで、ドロップダウン・リストからファイル・タイプの「XML」または「JSP」を選択します。

9. 「OK」をクリックします。Oracle WebCenter Sites Explorerでは、デフォルトのエディタが開きます。WebCenter Sitesでは、すべてのXMLエレメントまたはJSPエレメントで必要なスケルトン・コードが記述されているファイルが作成されます。必要なWebCenter Sites SOAPタグを含む、エレメント・コードを入力します。たとえば、次のXML用のコードを使用します。

<?xml version="1.0" ?><!DOCTYPE FTCS SYSTEM "futuretense_cs.dtd">
<FTCS Version="1.2">
<!-- WebServices/helloworld
-
- INPUT
-
- OUTPUT--->
<soap.message  ns="mynamespace">
<soap.body tagname="HelloWorldOut">
<echoStringOut xsi:type="xsd:string">
<csvar NAME="Variables.echoString"/>
</echoStringOut>
</soap.body>
</soap.message>

</FTCS>

10. 「ファイル」→「すべて保存」を選択して、作業内容を保存します。

注意:

「ファイル」→「すべて保存」のかわりに、「ファイル」→「保存」を選択してもファイルは保存されますが、アプリケーション・サーバーで使用できなくなります。

37.2.5 WSDLファイルの作成

WSDL (Webサービス記述言語)ファイルではWebサービスが記述されているため、基本的なWebサービス・クライアントがその情報に基づいて自動的に生成されます。WebCenter Sitesで提供されている事前定義サービスを使用しない場合には、オプションで独自のWSDLファイルを作成してWebサービスを記述できます。

WSDLファイルには、SOAPアドレス、SOAPアクション、リクエスト(WebCenter Sitesで想定される入力データ)に対するフォーマットの説明、およびリターン・データのフォーマットが記述されています。WSDLファイルは、Java、Visual Basic、その他のプログラミング言語で記述されたアプリケーションの標準データ型をXMLスキーマ・データ型にマッピングします。WebCenter Sites機能に対応した任意の事前定義されたWSDLファイルをテンプレートとして使用して開始します。

37.2.5.1 WSDLファイルのエレメントの記述

WSDLには、次の4つのセクションがあります。

- Types: データ・フォーマットおよび操作のスキーマ定義を指定します。タイプは、リターン・データと関連付けられています。

- Message: 入力および出力を名付けます。これには、WebCenter Sitesページが返信する必要のある事項が記述されています。

- Operation: 入力および出力を記述します。

- Binding: SOAPのアクションと操作を指定します。

- Service: 関連付けられたポートおよびURLとのバインドを記述します。

これらのセクションでは、次の主要なXMLエレメントを指定します。

- ターゲット名前空間

- サービス名

- ポート名

- 操作名

- 操作の入力パラメータ(単純データ型に対応)。単純XSIデータ型(文字列、整数、浮動小数点数など)は単一値を返します。

37.2.5.2 WSDLファイルの例

各WSDLファイルは、WebCenter Sites機能に応じて論理的にグループ化された、相互関連のある操作のコレクションです。完了したWebサービスは、SOAPのカプセル化レスポンスのフォームでXMLを返します。WebCenter SitesのWebサービスを記述するには、Webサービス記述言語を理解する必要があります。WebCenter SitesはWSDL 1.1をサポートしています。

<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://FatWire.com/someuri/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://FatWire.com/someuri/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
</types>
<message name="HelloWorldIn">
<part name="echoString" type="s:string"/>
</message>
<message name="HelloWorldOut">
<part name="echoStringOut" type="s:string"/>
</message>
<portType name="HelloWorldPortType">
<operation name="helloworld">
<documentation>FOR LATER</documentation>
<input message="s0:HelloWorldIn"/>
<output message="s0:HelloWorldOut"/>
</operation>
</portType>
<binding name="HelloWorldBinding" type="s0:HelloWorldPortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/
http" style="rpc"/>
<operation name="helloworld">
<soap:operation soapAction="WebServices/" />
<input>
<soap:body use="encoded"/>
</input>
<output>
<soap:body use="encoded"/>
</output>
</operation>
</binding>
<service name="HelloWorld">
<port name="HelloWorldPort" binding="s0:HelloWorldBinding">
<soap:address location="http://localhost:8080/servlet/ContentServer"/>
</port>
</service>
</definitions>

38 訪問者データ・アセットの作成

Engageを使用すると、サイトの訪問者および顧客に関する情報を収集するオンライン・サイトを設計し、その情報を使用して、表示する製品の配置や販促用の提供品を訪問者別にパーソナライズできます。

オンライン・サイトのカスタマイズは、訪問者データから始まります。WebCenter Sitesデータベースでは、訪問者データのタイプの定義をアセットとして扱います。訪問者データ・アセットには、訪問者属性、履歴属性および履歴タイプの3種類があります。

この章では、訪問者データ・アセット、およびチームの作成手順について説明します。次の項で構成されます。

- 第38.1項「訪問者データ・アセットについて」

- 第38.2項「訪問者データ・アセットの作成」

- 第38.3項「訪問者データ・アセットの確認」

- 第38.4項「訪問者データ・アセットの承認」

38.1 訪問者データ・アセットについて

訪問者データ・アセットを作成すると、そのアセットを使用してサイト訪問者をセグメントにグループ化できます。これには次の3種類があります。

- 訪問者属性

- 履歴属性

- 履歴タイプ

訪問者データ・アセットを作成すると、WebCenter Sitesデータベース内の訪問者データ表にエントリが作成され、該当するサイト訪問者に関する情報を格納する場所がデータベース内に確保されます。

この項の内容は、次のとおりです。

- 第38.1.1項「訪問者属性」

- 第38.1.2項「履歴属性と履歴定義」

- 第38.1.3項「セグメント」

- 第38.1.4項「訪問者データ・アセットの開発: プロセスの概要」

38.1.1 訪問者属性の作成

訪問者属性には、1つの特性のみ(スカラー値)を指定する情報のタイプが保持されます。たとえば、「経験年数」、「職務内容」、「子供の数」のような名前の訪問者属性を作成できます。

訪問者がデータを変更すると、新しいデータによって以前のデータが上書きされます。Engageでは、訪問者属性として格納されたデータおよびリビジョンを格納していないデータにはタイムスタンプが割り当てられません。たとえば、訪問者の「職務内容」のエントリが「肉屋」から「パン屋」に変更された場合、肉屋であった以前の訪問者情報は上書きされます。「かつて肉屋であったパン屋」に基づくセグメントを作成することはできません。

履歴データには、履歴タイプを使用する必要があります。

38.1.2 履歴属性と履歴定義

履歴属性は、Engageで単一レコードとして扱われる情報のベクターを作成するためにグループ化した個々の情報タイプです。このレコードが、履歴定義です。たとえば、「購買」という履歴定義は、「SKU」、「アイテム名」、「数量」および「価格」という履歴属性で構成できます。

履歴定義として格納されている参照データを全体または集約として使用します。記録済定義の各インスタンスにタイムスタンプを割り当て、それらの各レコードを保持します。つまり、履歴定義を合計または計数でき、訪問者に関して履歴定義が記録された最初の時刻または最終時刻を判別できます。前の段落の例を使用すると、訪問者が設定された一定期間に特定のアイテムに費やした金額の合計に基づいてセグメントを作成できます。

履歴定義には履歴データが格納されます。

38.1.3 セグメント

セグメントは、共通の特徴に基づいて訪問者をグループ分けするアセットです。セグメントを作成するには、セグメントのベースとなる訪問者データ・アセットを決定し、その基準の条件を満たす値を設定します。

訪問者データ・アセットを作成するとフィールドが作成されます。このフィールドは次の2つの場所で使用できます。

- セグメントの基準として。つまり、Engageの「セグメント・フィルタ」フォームの構成オプションとして使用します(訪問者データ・アセットを使用してセグメントを定義するため)。言い換えると、属性のデータ型に関する選択結果によって、セグメント・フォームでの外観や動作が決定されます。これらのアセットを作成すると、セグメント・フォームがカスタマイズされます。

- 一般のサイト・ページで。つまり、登録ページやその他のページのフォーム・フィールドまたは非表示のフィールドとして使用します。

セグメントは、Engageで販促用メッセージをパーソナライズする際のキーとなります。訪問者がサイトを参照すると、訪問者の送信情報を使用して、訪問者をセグメントのメンバーに認定します。サイトに推奨やプロモーションを含むページを表示する場合は、Engageによって訪問者が属するセグメントが決定され、そのセグメント向けの製品の推奨または販売促進メッセージが表示されます。

38.1.4 訪問者データ・アセットの開発: プロセスの概要

訪問者データ・アセット(フィールド)の作成および使用には、一般的に次の5つの手順があります。

1. 開発者およびマーケティング担当者で構成されるクロスファンクショナルな設計チームによって、サイト訪問者について収集するデータの種類が決定されます。

2. 開発者は、Engage内のフォームを使用して、必要な訪問者属性、履歴属性および履歴定義を作成および定義します。

3. マーケティング担当者は、Engage内の「セグメント・フィルタ」フォームを使用して、訪問者属性、履歴属性および履歴定義をベースに訪問者のグループを編成します。

4. 開発者は、EngageのXMLまたはJSPオブジェクト・メソッドを使用して適切なサイト・ページをプログラムし、データの収集と格納を行い、サーバー側の検証またはJavascriptのいずれかを使用してページ上の入力を検証します。たとえば、JavaScriptを使用して、入力を検証する訪問者入力用のオンライン登録フォームを作成し、EngageのXMLまたはJSPタグを使用して、その情報を処理およびWebCenter Sitesデータベースに格納できます。

5. 訪問者がサイトを参照すると、訪問者の送信情報を使用して、訪問者をセグメントのメンバーに認定します。サイトでセグメントに基づいてプロモーションと推奨を使用している場合、訪問者に表示されるメッセージは、訪問者が所属するセグメントに基づいてパーソナライズされます。

38.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データベースの容量が確保されます。

この項の内容は、次のとおりです。

- 第38.2.1項「訪問者属性の作成」

- 第38.2.2項「履歴属性の作成」

- 第38.2.3項「履歴定義の作成」

38.2.1 訪問者属性の作成

Engageフォームで訪問者属性を作成するには、この項の手順を使用します。

新しい訪問者属性を作成するには、次の手順を実行します。

1. 管理者としてWebCenter Sitesにログインします。

2. 作業場所とするサイトを選択します。

3. Adminインタフェースを選択します。

4. ボタン・バーで「新規」をクリックします。

5. アセット・タイプのリストから「新規訪問者属性」を選択します。(サイト訪問者属性のアセット・タイプは、サイトに対して有効にする必要があります。)
「サイト訪問者属性」フォームが表示されます。

図38-1 サイト訪問者属性

注意:

「訪問者属性」がメニュー・リストに表示されない場合は、入力したログイン/パスワードの組合せでは管理者権限が付与されないことを意味します。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

1. 「名前」フィールドで、属性(フィールド)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字にする必要があります。

2. 「説明」フィールドで、属性(フィールド)の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(属性は、「セグメント・フィルタ」フォーム内の名前ではなく、この説明によってリストされます)。

3. 「カテゴリ」フィールドで、属性のカテゴリを入力します。このフィールドに入力するテキストによって、「セグメント・フィルタ」フォームで属性がリストされる場所が決定されます。最大32文字の英数字を入力できます。

注意:

訪問者属性のカテゴリは、履歴定義のカテゴリとは別にする必要があります。

38.2.1.1 データ型の構成

1. 「タイプ」フィールドでデータ型を選択します。

2. 「string」を選択した場合は、「長さ」フィールドで、その属性(フィールド)に入力可能な最大の文字数を入力します。255までの値を入力できます。

3. 「NULL値を許可」フィールドでは、「true」を選択するとNULL値が許可され、「false」を選択すると属性の入力が使用時に要求されます。たとえば、booleanデータ型の属性はNULL値を許可できません。

4. 「NULL値を許可」フィールドで「false」を選択した場合は、「デフォルト値」フィールドで、その属性のデータ型に適合するデフォルト値を入力します。たとえば、データ型がintegerの場合は、デフォルト値を数値にする必要があります。

注意:

データ型に「binary」を選択した場合、その属性のデフォルト値は指定できません。

38.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では無制限に値を入力できます。)
たとえば、「年齢」という名前の属性で、1から110の間の値のみを受け入れるように制限できます。

図38-2 「制約タイプ」の各範囲フィールド

オプション3: ドロップダウン・リストに値のリストを提供する属性の構成

1. 「制約タイプ」フィールドで、「列挙」を選択します。
このフォームでは、オプション追加用のテキスト・ボックスが表示されます。

2. 「列挙値の追加」フィールドで、最初のオプションの名前を入力します。たとえば、「性別」という名前の属性に、オプションとして「女性」を含めることができます。

3. 「追加」をクリックします。
オプションがリストに移動します。

図38-3 列挙の制約

4. この属性(フィールド)で使用可能にするオプションごとに、この手順を繰り返します。

38.2.1.3 属性の保存

1. (オプション)2つ以上のサイトを設定していて、それらのサイトにもアクセスできる場合は、この属性を他のサイトで共有するかどうかを指定します。「調査」フォームの「詳細」メニューで、「訪問者属性の共有」を選択します。

2. 訪問者属性の構成が終了したら、「保存」をクリックします。
WebCenter Sitesデータベースの訪問者データ・アセット表にこの属性に対するエントリが作成され、該当するサイト訪問者に関する情報を格納する場所がデータベースに確保されます。

Engageにより、「調査」フォームの属性の概要が表示されます。

これで、この訪問者属性をセグメント内で使用できるようになります。

注意:

訪問者属性を使用してセグメントを定義した後、属性を削除するとセグメントが無効になります。属性を削除した場合は、セグメントを必ず修正してください。

38.2.2 履歴属性の作成

訪問者属性とは異なり、履歴属性は履歴定義で使用するために作成します。それらを使用して履歴定義を定義するまで、「セグメント・フィルタ」フォームでそれらを使用できません。

Engageフォームを使用して履歴属性を作成するには、この項の手順を使用します。

注意:

履歴定義の定義に使用している履歴属性は、編集または削除できません。履歴定義から削除することもできません。履歴定義の定義に使用した履歴属性を変更する場合は、該当する履歴定義の使用を停止することお薦めします。新しい履歴属性を作成し、新しい履歴定義を作成した後、その新しい履歴定義を使用するようにしてください。

新しい履歴属性を作成するには、次の手順を実行します。

1. 作業場所とするサイトを選択します。

2. Adminインタフェースを選択します。

3. ボタン・バーの「新規」をクリックして、リストから「新規履歴属性」を選択します。
「履歴属性」フォームが表示されます。

図38-4 「履歴属性」フォーム

注意:

「履歴属性」がメニュー・リストに表示されない場合は、入力したログイン/パスワードの組合せでは管理者権限が付与されないことを意味します。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

1. 管理者としてWebCenter Sitesにログインします。

2. 「名前」フィールドで、属性(フィールド)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字にする必要があります。

3. 「説明」フィールドで、属性(フィールド)の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(属性は、「セグメント・フィルタ」フォーム内の名前ではなく、この説明によってリストされます)。

4. 「タイプ」フィールドでデータ型を選択します。

5. 「string」を選択した場合は、「長さ」フィールドで、その属性(フィールド)に入力可能な最大の文字数を入力します。

6. セグメントの定義に使用する履歴定義でこの属性を必須フィールドにする場合は、「指定が必要」フィールドで、「true」を選択します。

7. 「フィルタ条件」フィールドをクリックして、「true」を選択します。
「フィルタ条件」を「true」に設定しない場合は、マーケティング担当者がセグメントを作成する際に、その属性(フィールド)が所属するいずれの履歴定義に対してもその属性を制約として使用できません。

この属性のデータ型が数値の場合は、「フィルタ条件」をtrueまたはfalseのいずれに設定しても、セグメント内の合計制約に選択可能な属性のリストにデフォルトでこの属性が追加されます。ただし、その他の方法で制約として数値属性を使用する場合は、「フィルタ条件」をtrueに設定する必要があります。

8. 「NULL値を許可」フィールドをクリックして「true」を選択するとNULL値が許可され、「false」を選択すると属性の入力が使用時に要求されます。たとえば、booleanデータ型の属性はNULL値を許可できません。

9. 「NULL値を許可」フィールドで「false」を選択した場合は、「デフォルト値」フィールドで、その属性のデータ型に適合するデフォルト値を入力します。たとえば、データ型がintegerの場合は、デフォルト値を数値にする必要があります。

38.2.2.1 制約基準の構成

属性への入力の検証に使用可能な制約オプションは、その属性に指定したデータ型によって異なります。

フリーフォーム・テキストを受け入れる属性の構成

「制約タイプ」フィールドをクリックして、ドロップダウン・リストから「なし」を選択します。たとえば、string型のStreet Nameという履歴属性で、制約のないテキストを入力として受け入れる場合があります。

値の範囲から入力を受け入れる属性の構成

特定の値の範囲を受け入れる属性を構成するには、データ型をinteger、short、long、doubleまたはmoneyにする必要があります。

1. 「制約タイプ」フィールドで、「範囲」を選択します。
フォームに「範囲」フィールドが表示されます。

2. 「下限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最小値を指定します。この値を負の数値にはできません。

3. 「上限域制限」フィールドで、フィールドとして使用される際に属性で受入れ可能な最大値を入力します。(データ型がshortでは255まで、integerでは65,535まで、doubleでは4,294,967,295まで、moneyでは無制限に値を入力できます。)
たとえば、「項目数」という名前の属性で、1から50の間の値のみを受け入れるように制限できます。

図38-5 範囲の制約と関連フィールド

固有の値のドロップダウン・リストを提供する属性の構成

1. 「制約タイプ」フィールドで、「列挙」を選択します。
このフォームでは、オプション追加用のテキスト・ボックスが表示されます。

2. 「列挙値の追加」フィールドで、最初のオプションの名前を入力します。.

3. 「追加」をクリックします。

図38-6 列挙の制約のフィールド

4. この属性で使用可能にするオプションごとに、この手順を繰り返します。

38.2.2.2 履歴属性の保存

履歴属性の構成が終了したら、「保存」をクリックします。

WebCenter Sitesデータベースの訪問者データ・アセット表にこの属性に対するエントリが作成され、該当するサイト訪問者に関する情報を格納する場所がデータベースに確保されます。

これで、履歴属性を使用して、履歴定義を定義できるようになります。

38.2.3 履歴定義の作成

履歴定義は履歴属性で構成されます。したがって、履歴定義を作成するには、少なくとも1つの履歴属性が必要になります。

Engageフォームを使用して履歴定義を作成するには、次の手順を使用します。

1. Engageが開いていない場合は、ログインします。

2. 「新規」をクリックして、リストから「履歴定義」を選択します。
次のような「履歴定義」フォームが表示されます。

図38-7 履歴定義のフィールド

注意:

「履歴定義」がメニュー・リストに表示されない場合は、入力したログイン/パスワードの組合せでは管理者権限が付与されないことを意味します。サイト管理者に問い合せて、使用するユーザー名に管理ユーザー・プロファイルを割り当てるよう依頼してください。

3. 「名前」フィールドで、履歴定義(レコード)を説明する一意の名前を入力します。最大32文字の英数字(スペースを含む)を入力できます。最初の文字は英字にする必要があります。

4. 「説明」フィールドで、履歴定義の説明を入力します。属性を簡単に特定できる値(英数字)を入力します(履歴定義は、「セグメント・フィルタ」フォーム内の名前ではなく、この説明によってリストされます)。

5. 「カテゴリ」フィールドで、履歴定義のカテゴリを入力します。このフィールドに入力するテキストによって、「セグメント・フィルタ」フォームでの履歴定義のソート方法および表示方法が決定されます。最大32文字の英数字を入力できます。

注意:

履歴定義のカテゴリは、訪問者属性のカテゴリとは別にする必要があります。

6. 「フィールド」領域で、この履歴定義を構成する履歴属性を選択します。属性を選択して右矢印をクリックすることで、その属性が右のリストに移動します。Ctrlを押しながらクリックすると、2つ以上の属性を同時に選択できます。

注意:

履歴定義の定義に使用した履歴属性を編集または削除することはできません。

7. 「保存」をクリックします。
WebCenter Sitesデータベースの訪問者データ・アセット表にこの履歴定義(記録)に対するエントリが作成され、該当するサイト訪問者に関する情報を格納する場所がデータベースに確保されます。

次に、「調査」フォームの履歴定義の概要が表示されます。

これで、この履歴定義をセグメント内で使用できるようになります。

38.3 訪問者データ・アセットの確認

訪問者属性、履歴属性および履歴定義が正しく設定されていることを確認するには、「セグメント・フィルタ」フォームを調査して、作成した訪問者アセットが正しく構成されているかどうかを判断します。

- 作成した訪問者属性および履歴定義のそれぞれを使用するセグメントを作成します。

- 制限の定義が正しいこと、および入力範囲が正しい入力の範囲で使用できることを確認します。

38.4 訪問者データ・アセットの承認

訪問者データ・アセットの準備が整ったら、それを承認して配信システムにパブリッシュできるようにします。

履歴定義がパブリッシュされると、その定義に使用される履歴属性もパブリッシュされます。つまり、履歴定義をパブリッシュできるようにするには、履歴定義内のすべての履歴属性を承認する必要があります。

すべてのアセットを承認するには、そのアセットの「編集」フォームまたは「調査」フォームのアイコン・バーにあるドロップダウン・リストから「パブリッシュの承認」を選択します。

39 推奨アセット

推奨は、レンダリングされたページで注目または推奨する必要のある製品またはコンテンツを決定するアセットです。これらのアセットは、訪問者の所属するセグメントや、製品アセットまたはコンテンツ・アセット、もしくはその両方の間の関係に基づいた一連のルールで構成されています。

この章では、推奨のしくみおよび推奨されるアセットを返すカスタム・エレメントの作成方法について説明します。

この章には次の項が含まれます。

- 第39.1項「推奨アセットの概要」

- 第39.2項「開発プロセス」

- 第39.3項「動的リスト・エレメントの作成」

39.1 推奨アセットの概要

推奨アセットは、製品アセットとコンテンツ・アセットの収集、評価およびソートを行った後ら、最も適切なフレックス・アセット(現在の訪問者のアセットなど)を推奨します。最適なアセットはどのように判断されるのでしょうか。訪問者が所属するセグメントのリストを参照することによってです。

製品アセットおよびコンテンツ・フレックス・アセットは、各セグメントに対する重要度に応じて評価されます。テンプレートから推奨アセットがコールされると、Engageでは、現在の訪問者が所属するセグメントが決定され、それらのセグメントで最も評価の高いアセットの中から推奨で特定されたものが選択されます。これらが訪問者に推奨されるアセットになります。

推奨には次の3種類があります。

- 静的リスト: 推奨されるアイテムの静的リストを返します。

- 動的リスト: 作成する動的リスト・エレメントにより生成された推奨アイテムのリストを返します。

- 関連アイテム: 製品など、フレックス・アセット間の関係に基づいて推奨されるアイテムのリストを返します。

Engageでは、リスト内のアイテムがテンプレートにプログラムされた表示数を超えた場合、推奨の構成オプションとそのアセット評価を使用してリストを制限します。関連アイテムの推奨でも、アセットの関係がリストの制限に使用されます。すべての推奨において、現在の訪問者で評価が0のアセットは除外されます。

推奨アセットは、テンプレートを割り当てることのできる唯一のEngageアセットです。推奨テンプレートをコーディングし、レンダリングされたページ上で、推奨によって返されるアイテムを適切にレンダリングします。

このテンプレートによって、返すアセットの数が推奨に指示されます。推奨アセットは、どのアセットを選択してテンプレートに返す必要があるのかを、テンプレートに構成された方法および現在の訪問者が所属するセグメントに基づいて決定します。

推奨用テンプレートのコーディングに使用できるいくつかのXMLオブジェクト・メソッドおよびJSPオブジェクト・メソッド(タグ)があります。Engageを使用する場合の、テンプレートのコーディングの詳細は、第40章「Engageページのコーディング」を参照してください。すべてのEngageタグについては、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

39.2 開発プロセス

次の基本手順に従って、推奨を設定します。

1. 開発者および設計者がマーケティング・チームと話し合い、サイトに表示するすべてのマーチャンダイジング・メッセージを定義し、推奨アセットおよびプロモーション・アセットを使用したメッセージの表示方法について計画します。

2. 開発者および設計者が、XMLオブジェクト・メソッドまたはJSPオブジェクト・メソッドを使用して推奨用テンプレートを設計およびコーディングします。これらのテンプレートのコーディング方法については、第40章「Engageページのコーディング」で説明しています。

3. Webサイトで動的リスト推奨を使用する場合、開発者は、推奨するアセットを返す動的リスト・エレメントをコーディングします。動的リスト・エレメントのコーディング方法については、第39.3項「動的リスト・エレメントの作成」で説明しています。

4. マーケティング・チームが、Engageの推奨ウィザードを使用して推奨を作成し、構成します。その際、適切なテンプレートを適切な推奨に割り当てます。

5. マーケティング担当者は、Engageの製品フォームとコンテンツ・アセット・フォームを使用して、各セグメントに対するアセットの重要度を評価することで、そのセグメントのメンバーである個々の訪問者に対するアセットの重要度を評価します。(通常は、個々のアセットではなく、製品の親などのフレックス親に評価を割り当てます。)

6. 関連アイテムの各推奨について、マーケティング担当者は、フレックス・アセットまたはフレックス親フォームの関連アセットを割り当てることにより、それらの推奨で維持される関係を構成します。(通常は、個々のアセットではなく、製品の親などのフレックス親の間の関係を構成します。)

39.3 動的リスト・エレメントの作成

Webサイトで動的リスト推奨を使用する場合は、推奨されるアセットのリストを返す動的リスト・エレメントをコーディングする必要があります。動的リスト・エレメントはCSElementアセット・タイプのインスタンスです。これにより、配信システムを使用するWebサイトがパブリッシュされた場合に、動的リスト・エレメントが配信システムに転送されるようになります。

動的リスト・エレメントは、AssetListという名前のリストを返す必要があります。AssetListになるアセット・セットには、次の特性が必要です。

- 推奨するアセット・タイプのみを含める必要があります。

- 推奨するアセットIDを含める必要があります。

- アセットの確信度評価を含める必要があります(オプション)。

次のコード例は、動的リスト・エレメントから抜粋したものです。次のコードの2行目では、検索状態のssprodに制約が追加され、Fund Typeの参照カテゴリを持つアイテムを検索するようにフィルタ処理が行われます。3行目では、検索状態のssprodに別の制約が追加され、Productアセットで全体が構成されるアセット・セットが作成されます。最後の4行目では、3行目で作成されたアセット・セットがAssetListリストに変換されます。

1. <SEARCHSTATE.CREATE NAME="ssprod"/>

2. <SEARCHSTATE.ADDSIMPLESTANDARDCONSTRAINT NAME="ssprod" TYPENAME="PAttributes" ATTRIBUTE="BrowseCategory" VALUE="Fund Type"/>

3. <ASSETSET.SETSEARCHEDASSETS NAME="asprod" CONSTRAINT="ssprod" ASSETTYPES="Products"/>

4. <ASSETSET.GETASSETLIST NAME="asprod" LISTVARNAME="AssetList"/>

動的リスト・エレメントのコーディングが完了したら、そのエレメントの名前と、動的リスト・エレメントが返すコンテンツの種類について、推奨アセットを作成するユーザーに情報を提供します。

40 Engageページのコーディング

この章では、訪問者情報を収集し、その情報に基づいて訪問者ごとの販促用メッセージをパーソナライズするオンライン・サイトの設計について説明しています。

この章には次の項が含まれます。

- 第40.1項「商用コンテキストおよび訪問者コンテキスト」

- 第40.2項「訪問者の識別およびセッションのリンク」

- 第40.3項「訪問者データの収集」

- 第40.4項「訪問者データを収集するサイト・ページのコーディング」

- 第40.5項「テンプレートおよび推奨」

- 第40.6項「ショッピング・カートおよびEngage」

- 第40.7項「サイト・ページのデバッグ」

注意:

この章では、説明するタスクを実行するために固有のXMLタグを参照します。また、そのすべてのケースには対応するJSPタグが存在します。これらのXMLタグおよびJSPタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

40.1 商用コンテキストおよび訪問者コンテキスト

Engageサイトでの訪問者セッション中、その訪問者用の訪問者コンテキストが作成されます。この訪問者コンテキストには、次の5種類のセッション・オブジェクトがあります。

- 現在のショッピング・カート

- 訪問者が所属するセグメントのリスト

- 訪問者に適したプロモーションのリスト

- セグメントおよびプロモーションに対する時間ベースのルールの計算に使用される時間オブジェクト

- 開発者に製品属性へのアクセス権を付与するユーティリティ・オブジェクト

商用コンテキストには訪問者コンテキストが含まれており、開発者に訪問者コンテキストへのアクセス権を付与します。

これらのコンテキストのインタフェースとして機能するXMLおよびJSPオブジェクト・メソッドには、次の2つのセットがあります。

- 商用コンテキスト・メソッド。訪問者コンテキストにオブジェクトを配置するために使用されます。

- 訪問者データ・マネージャ・メソッド。訪問者データを収集、格納および取得するほか、訪問者データを適切な訪問者に関連付けるために使用されます。

40.2 訪問者の識別およびセッションのリンク

Engageでは、各セッションの各訪問者に対して一意の訪問者IDが作成されます。これらのIDは、WebCenter SitesデータベースのVMVISITOR表に格納されます。そのセッション中に訪問者に関して収集されたデータは、訪問者IDで識別されます。あるセッションから収集されたデータを別のセッションからのデータにリンクするには、サイト・ページでそれらの訪問者IDをリンクする別名を割り当てる必要があります。

別名を作成するには、訪問者データ・マネージャの次のオブジェクト・メソッドを使用します。

<VDM.SETALIAS KEY="keyvalue" VALUE="aliasvalue"/>

このタグを使用すると、Engageでは訪問者セッションIDと別名が関連付けられ、その両方がVMVISITORALIAS表に書き込まれます。

図40-1 VMVISITORALIAS表

この表の値は、別々のセッションで収集されたデータを同一の訪問者にリンクします。別名によって、その訪問者に対して記録されている訪問者IDへのリンクが提供されるためです。上の図では、訪問者ID 973717492772に関連付けられたセッションに記録されているデータは、訪問者ID 973717564355に関連付けられたデータにリンクされています。これらは、同一のキー/値ペアの別名を保持しているからです。

セッションに関連付けられたすべての訪問者情報は、共通の別名を通じてリンクされます。つまり、現在のセッション中に、同一のキー/値ペアを持つ別名にアクセスできます。これは、現在の訪問者の情報と見なされます。

Cookie、ログインIDまたはその他の一意の識別子を持つ別名を作成して、サイトでの訪問者の識別に使用できます。

VMVISITORALIAS表はすぐに大きくなります。この表およびその他の訪問者データ表の管理の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

40.3 訪問者データの収集

訪問者データを収集するには、その収集および検証のほか、WebCenter Sitesデータベースへの書込みを行うためのオンライン・ページをプログラムする必要があります。

訪問者データ・マネージャには、データベースにその情報を書き込む3つのオブジェクト・メソッドがあります。

- <VDM.SETSCALAR ATTRIBUTE="attribute" VALUE="value"/>は、訪問者属性を記録します。

- <VDM.RECORDHISTORY ATTRIBUTE="attribute" LIST="valuelist"/>は、履歴定義を記録します。

- <VDM.SAVESCALAROBJECT ATTRIBUTE="attribute" OBJECT="objectname"/>は、バイナリ・タイプの訪問者属性を記録します。Engageにより配信されたデモ・サイトでは、このメソッドを使用して、セッション間のショッピング・カートが格納されるほか、訪問者用に保存された検索が格納されます。

注意:

これらのタグによってデータベースに情報が書き込まれるため、配信システムのパフォーマンスに影響を与える可能性があります。これらは効率的に使用してください。

訪問者データが格納される表には次のものがあります。

表40-1 オブジェクト・メソッドおよびデータベース表

XMLまたはJSPオブジェクト・メソッド

書込み対象のデータベース表

VDM.SETSCALAR

vdm:setscalar

VMVISITORSCALARVALUE

VDM.SAVESCALAROBJECT

vdm:savescalarobject

VMVISITORSCALARBLOB

VDM.RECORDHISTORY

vdm:recordhistory

VMz------------

(これらの表は履歴定義ごとに動的に生成されます。Engageによってそれぞれに一意の表が作成されます。)

これらの表はすぐに大きくなります。これらの管理の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

訪問者データ・マネージャには、WebCenter Sitesデータベースからこの情報を取得する複数のオブジェクト・メソッドもあります。第10章「エラー・ロギングおよびデバッグ」を参照してください。

注意:

これらの詳細、およびその他のEngageのXMLタグとJSPタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

40.4 訪問者データを収集するサイト・ページのコーディング

この項では、サイト・ページをコーディングして訪問者データを収集するための一般的な手順について説明します。

1. 訪問者が入力したデータを取得するためのフォームを作成します。作成した属性と同じ名前のフォーム・フィールドを作成することをお薦めします。詳細は、第38章「訪問者データ・アセットの作成」を参照してください。
Engageセグメント・フォームでは、名前ではなく説明によって属性がリストされます。フォーム・フィールドを作成する場合、あるいはWebCenter Sitesデータベースに値を書き込む場合には、属性の名前と説明を混同しないように気をつけてください。

2. 訪問者がフィールドに入力したデータを検証する送信ページを作成します(JavaScriptまたはサーバー側の検証メソッドを使用)。入力データは、属性に設定された制約に準拠する必要があります。たとえば、訪問者の文字列型の属性を長さ30で作成した場合、長さ31でフォーム・フィールドからデータを送信しないようにします。

3. 検証済データをWebCenter Sitesデータベースに書き込む送信ページをプログラムします。属性および履歴定義の名前を使用し、それらの説明は使用しないようにします。いくつかの例を次に示します。

この項の内容は、次のとおりです。

- 第40.4.1項「例1: 訪問者属性」

- 第40.4.2項「例2: 履歴定義」

- 第40.4.3項「例3: バイナリ・タイプの訪問者属性」

40.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"/>

40.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"/>

この記録を使用して、訪問者のオーダー数、初回または最後の購入日時、および支払い総額に関する情報を確認できます。

40.4.3 例3: バイナリ・タイプの訪問者属性

バイナリ訪問者属性では、WebCenter Sitesネームスペースからのオブジェクトをバイナリ・フォームに変換できます。Engageにより配信されたサンプル・サイトでは、バイナリ・タイプの2つの訪問者属性を使用します。1つは複数のセッション間でショッピング・カートを格納するための属性で、もう1つは保存済検索を格納するための属性です。

これらの例を参照するには、Oracle WebCenter Sites Explorerを使用して、ElementCatalog/OpenMarket/Demos/CatalogCentre/GE/Navigation/stylesheet.xmlおよびElementCatalog/OpenMarket/Demos/CatalogCentre/GE/myge.xmlを調べてください。

1. 訪問者の動作(クリックストリーム情報など)に関するデータを収集する場合は、入力フォームを使用せずにデータを収集するページをプログラムできます。たとえば、Engageにより配信されたデモ・サイトでは、訪問者がサイトを閲覧した回数を記録するために履歴定義が使用されます。
この例については、Oracle WebCenter Sites Explorerを使用して、ElementCatalog/OpenMarket/Demos/CatalogCentre/GE/Navigation/stylesheet.xmlを調べてください。

2. 訪問者データがデータベースに書き込まれるたびに、セグメントおよびプロモーションも変更される可能性があります。したがって、訪問者データに変更があった場合は必ず、セグメント・リストおよびプロモーション・リストを再計算するようにします。商用コンテキストには、使用可能な2つのオブジェクト・メソッドがあります。
COMMERCECONTEXT.CALCULATEPROMOTIONS

COMMERCECONTEXT.CALCULATESEGMENTS

COMMERCECONTEXT.CALCULATEPROMOTIONSでは、訪問者が所属するセグメントとそのセグメントに適用されるプロモーションの両方が再計算されます。

3. 訪問者データがデータベースに書き込まれるたびに、アセットの評価も変更される可能性があります。したがって、訪問者データに変更があった場合は必ず、既存のアセット・セットにあるすべてのアセットの評価をリフレッシュするようにします。
1つのセットにあるアセットのアセット評価をリフレッシュするには、ASSETSET.ESTABLISHRATINGSタグを使用します。

注意:

これらの詳細、およびその他のEngageのXMLオブジェクト・メソッドとJSPオブジェクト・メソッドの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

40.5 テンプレートおよび推奨

次のコードは、商用コンテキストで推奨アセットを起動する主要なオブジェクト・メソッドです。

<COMMERCECONTEXT.GETRECOMMENDATIONS COLLECTION="recommendationname" [LIST="inputlist" VALUE="rating" MAXCOUNT="assetcount"] LISTVARNAME="assetlist"/>

このメソッドでは、メソッドに渡される推奨制限に一致するアセットが取得され、リストされます。ここでは次の引数が使用されます。

- COLLECTION: 推奨の名前。複数の推奨に同じテンプレートを使用する場合は、変数を使用して推奨IDを指定するテンプレートをコーディングします。

- LIST: アセットのリスト名。この名前を計算の入力に使用します。
COLLECTIONにより名付けられた推奨がコンテキストベースの推奨である場合は、この引数を使用します。列には、assettypeとassetidがあります。このリストを作成するには、リスト・オブジェクトを作成し、入力に使用するアセットごとに行を追加します。この例については、Oracle WebCenter Sites Explorerを使用して、ElementCatalog/OpenMarket/Demos/CatalogCentre/GE/cart.xmlを調べてください。

- VALUE: 値を持たないアセットのデフォルトの評価。値を宣言しない場合、評価されていないアセットには、0から100のスケールのうちデフォルト評価の50が割り当てられます。この値は50に設定したままにしておくことをお薦めします。

- MAXCOUNT: (オプション。)返されるアセットの最大数。この値を使用して、推奨アセットのリストを制限します。

- LISTVARNAME: アセット・リストに割り当てる名前。列には、assettypeおよびassetidがあります。

セグメント・リストとプロモーション・リストが訪問者コンテキスト内で作成および配置されていない場合、このオブジェクト・メソッドによって、それらを計算するメソッドが呼び出されます。プロモーションにはテンプレートがなく、推奨が使用しているテンプレートをオーバーライドすることに注意してください。現在の訪問者に適したプロモーションで、COLLECTION引数によって指定された推奨をオーバーライドするものがある場合、オブジェクト・メソッドは、推奨アセットによって特定されるアイテムではなく、プロモーション・アセットのIDを返します。

注意:

COMMERCECONTEXT.GETSINGLERECOMMENDATIONオブジェクト・メソッドでは、そのメソッドに渡された推奨基準に基づいて推奨されたアセットが1つ返されます。このメソッドは通常、1つの製品に注目を集めるか、1つの製品を販売する場合に使用されます。このオブジェクト・メソッドおよびJSPオブジェクト・メソッドの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

推奨のテンプレートのコーディングを始める前に、次のタスクを完了しておきます。

- マーケティング・チームと話し合い、サイトに表示するすべてのマーチャンダイジング・メッセージを定義し、推奨およびプロモーションでそれらのメッセージを表示する方法について計画します。
たとえば、他の製品へのリンクのリストを表示しますか。リンクにどの情報を含める必要がありますか。製品名のみを表示しますか、それとも価格も含めますか。推奨がアセットのリストではなくプロモーションを返す場合、何を表示しますか。

- 各推奨から推奨されたアセットが表示される場所とページを決定します。

推奨のテンプレートの作成

推奨アセットによって返されたアイテムをレンダリングするテンプレートを使用するには、少なくとも次の基本手順を完了する必要があります。

1. 推奨アセットを起動するテンプレート・エレメントを作成します。前述の項で説明したオブジェクト・メソッドを使用します。

2. 推奨によって返されたアイテムを表示するテンプレートをコーディングします。返されたアイテムは、LISTVARNAME引数によって指定された変数に格納されます。このリストには、アセットIDとそれらのアイテムのアセット・タイプが含まれます。その情報を使用して、表示するアセット属性を抽出します。(名前、価格、SKUなど。)
ASSETSET.SETLISTEDASSETSオブジェクト・メソッドおよびASSETSET.GETASSETLISTオブジェクト・メソッドを使用することで、返されたアセットとその属性をソートして表示できます。

この例については、Oracle WebCenter Sites Explorerを使用して、ElementCatalog/OpenMarket/Demos/CatalogCentre/Templates/GE/recommendation.xmlを調べてください。

3. Engageを開きます。「新規」で「テンプレート」を選択します。このテンプレート・エレメントに対応するテンプレート・アセットを作成します。エレメントの実行内容を説明する名前を入力することで、推奨アセットの作成時、そのアセットに割り当てられるテンプレートを把握できます。「エレメント名」フィールド内のエレメント(そのElementCatalog内の場所)へのパスを特定します。

4. 他のアセットがパブリッシュされたら、テンプレート・アセットをパブリッシュします。

5. 適切なサイト・ページに推奨をレンダリングします。

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プロパティをfuturetense_xcel.iniファイルに追加する必要があります。

commercecontextタグ、パラメータ定義、およびOracle RTDとの統合の詳細とサンプル・コードは、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。rtd.inline.service.nameプロパティ、rtd.hostプロパティおよびrtd.choiceId.patternプロパティの詳細は、『Oracle Fusion Middleware WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

40.6 ショッピング・カートおよびEngage

Engageでショッピング・カート・インタフェースを使用する場合は、ショッピング・カート・ページをコーディングする際に注意すべき追加事項とヒントがいくつかあります。

- サイトでプロモーションを使用する場合は、プロモーションによる割引きが適用されるようにカート・ページをコーディングする必要があります。
COMMERCECONTEXT.DISCOUNTCARTオブジェクト・メソッドおよびCOMMERCECONTEXT.DISCOUNTTEMPCARTオブジェクト・メソッドを使用して、プロモーションによる割引きをショッピング・カートに適用します。

- カートの既存の割引きを消去した後に、再び割引きを適用することをお薦めします。

- セッション間でカートを格納するには、それらをバイナリ・タイプの訪問者属性(スカラー・オブジェクト)としてデータベースに書き込みます。カートが変更されるたびにカート・オブジェクトをデータベースに書き込むようにします。

- サイトで訪問者のログイン機能を使用する場合は、ショッピング・カートをマージする条件を設定できます。たとえば、ある訪問者は製品をカートに追加してから、ログインします。ログイン後に、アイテムを含む格納済のカートが検出されます。このような場合、カートをマージできます。

CARTオブジェクト・メソッドの詳細およびJSPオブジェクト・メソッドの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

Engageショッピング・カートの例については、Oracle WebCenter Sites Explorerを使用して、ElementCatalog/OpenMarket/Demos/CatalogCentre/GE/cart.xmlを調べてください。

40.7 サイト・ページのデバッグ

開発フェーズの間は、セッション・リンクが正しく設定されていること、特定の属性によって期待どおりの値が取得されること、さらに推奨で目的のアイテムが返されることを確認する必要があります。Engageには、ブラウザ・ウィンドウやJREログに情報を書き込むことで、情報と値の取得および確認を可能にする複数のオブジェクト・メソッドが存在します。

この項では、最も使用する可能性が高い訪問者データ・マネージャのオブジェクト・メソッドをリストします。これらの詳細、およびその他のXMLオブジェクト・メソッドとJSPオブジェクト・メソッドの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

この項の内容は、次のとおりです。

- 第40.7.1項「セッション・リンク」

- 第40.7.2項「訪問者データの収集」

- 第40.7.3項「推奨およびプロモーション」

40.7.1 セッション・リンク

訪問者データ・マネージャの次のオブジェクト・メソッドを使用して、セッション・リンクを処理するページでその別名が正しく作成されることを確認します。

- <VDM.GETALIAS KEY="keyvalue" VARNAME="varname"/>
別名を取得します。

- <VDM.GETCOMMERCEID VARNAME="varname"/>
セッション・データから訪問者のコマースIDを取得します。

- <VDM.GETACCESSID KEY="pluginname" VARNAME="varname"/>
セッション・データから訪問者のアクセスIDを取得します。

40.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"] />
この訪問者について、指定された履歴定義が最後に記録されたとき(つまり最新)のタイムスタンプを取得します。

40.7.3 推奨およびプロモーション

商用コンテキストの次のオブジェクト・メソッドを使用して、推奨およびプロモーションを表示するページを確認します。

- <COMMERCECONTEXT.CALCULATESEGMENTS/>
訪問者が所属するセグメントをリストします。ここでは、使用可能な訪問者データを調査し、それをセグメントを定義するデータ型と比較して、一致するセグメントをリストします。

- <COMMERCECONTEXT.GETPROMOTIONS LISTVARNAME="promotionlist"/>
現在の訪問者を対象とするプロモーションのリストを作成します。

- <COMMERCECONTEXT.GETRATINGS ASSETS="assetlist" LISTVARNAME="ratinglist" DEFAULTRATING="defaultrating"/>
名前付きリスト内のアセットの評価を、訪問者が所属するセグメントに基づき、この訪問者に対するアセットの重要度に従って計算します。

- <COMMERCECONTEXT.GETSEGMENTS LISTVARNAME="segmentlist"/>
現在の訪問者が所属するセグメントのリストを取得します。

41 メモリー中心の訪問者追跡

Engageアセットを閲覧するサイト訪問者は通常、個人プロファイルを使用して自身の情報を提供します。また、訪問者が閲覧することで統計情報が収集されます。大量の訪問者データによるWebCenter Sitesデータベースの過負荷を防ぎ、さらにパフォーマンスを改善するため、メモリー中心の訪問者追跡がEngageアセット用に開発されました。

この章では、メモリー中心の訪問者追跡について説明するほか、このメソッドの実装に必要な条件を概説します。

この章には次の項が含まれます。

- 第41.1項「メモリー中心の訪問者追跡の概要」

- 第41.2項「メモリー中心の訪問者追跡の有効化」

- 第41.3項「メモリー中心の訪問者追跡の機能」

41.1 メモリー中心の訪問者追跡の概要

多数の訪問者がWebサイトを閲覧する場合、単一リポジトリにすべての個人情報を格納すると配信システムのパフォーマンスが低下します。そのため、訪問者の統計情報を収集するサイトでは、多くの場合、サイトのパフォーマンスを改善するためにリポジトリの追加が必要になります。さらにパフォーマンスを向上させるには、WebCenter Sitesデータベースでロードを行わないようにします。

WebCenter Sitesによりアドオン・リポジトリがサポートされるため、Engage開発者が独自のリポジトリを実装して訪問者のスカラー属性値を格納できます。そのリポジトリで訪問者情報を格納および取得するには、カスタム・コードを記述する必要があります。さらに、WebCenter Sitesでメモリー中心の訪問者追跡メソッドを有効化する必要があります。この概要では、メモリー中心のメソッドとデータベース中心のメソッドの違いについて説明します。メモリー中心の追跡の有効化に関する情報は、この章の後半に記載している、メモリー中心の訪問者追跡機能について説明した図を参照してください。

この項の内容は、次のとおりです。

- 第41.1.1項「データベース中心のモデル」

- 第41.1.2項「メモリー中心のモデル」

41.1.1 データベース中心のモデル

データベース中心の訪問者追跡では、次の理由により、Engage対応のWebサイト上でパフォーマンスの問題が発生します。

- WebCenter Sitesデータベースにすべての訪問者情報が格納されます。情報を格納および取得するには、複数のデータベース・アクセスが必要になります。

- 動的な推奨が使用されて大量のデータが返される場合、WebCenter Sitesに大量のSystemItemCacheエントリが記録されるためパフォーマンスが低下します。パフォーマンスをリストアするため、WebCenter Sitesデータベースに記録される依存性の数を制限する方法としてrender:overridedepsタグが導入されました。このタグは、データベース中心のモデルとメモリー中心のモデルの両方に適用されます。

41.1.2 メモリー中心のモデル

メモリー中心の追跡では、WebCenter Sitesデータベースの負荷を減らすことによってシステム・パフォーマンスを改善します。

- すべての計算はメモリー内で実行されます。

- カスタム・コードによりアドオン・リポジトリから訪問者のスカラー属性値(年齢、性別など)が取得されると、メモリー中心のモデルでは、取得された値がメモリー内に格納され、その値を履歴属性値とともに使用することで訪問者が所属するセグメントが計算されます。

- メモリー中心の追跡では、メモリー内で様々な履歴属性値に関する統計が計算され、その統計がキャッシュされます。統計には、合計、数、最も古い値および最新の値が含まれます。

- 別名および履歴属性値はWebCenter Sitesデータベースに格納されますが、それによって訪問者情報の量およびその情報にアクセスするためのコール数がともに少なくなります。

データベース中心の追跡と同様に、開発者は、render:overridedepsタグを使用して、WebCenter SitesデータベースにログインするためのEngageアセットの依存性の数およびタイプを指定できます。メモリー中心の追跡を有効化するには、visitor.iniのプロパティを設定して、サポート・テンプレート・コードを記述する必要があります。

41.2 メモリー中心の訪問者追跡の有効化

この項の内容は、次のとおりです。

- 第41.2.1項「訪問者追跡のプロパティ」

- 第41.2.2項「サポート・コード」

- 第41.2.3項「バッチを使用したデータベースへの履歴属性の保存」

41.2.1 訪問者追跡のプロパティ

メモリー中心の訪問者追跡は、vis.useSessionVisitorConnectionプロパティで有効化します。このプロパティは、配信システム上で、WebCenter Sitesのvisitor.iniファイルに手動で追加する必要があります。

- vis.useSessionVisitorConnection=trueを設定すると、メモリー中心の訪問者追跡が有効になります。また、Engage訪問者を適切に追跡するには、サポート・テンプレート・コードが配信システム上に存在する必要があり、その際には既存のコードを再利用できます。詳細は、第41.2.2項「サポート・コード」を参照してください。

- vis.useSessionVisitorConnection=falseを設定したり、空白のままにしたり、それをvisitor.iniから省略すると、データベース中心のメソッドが有効になります。

注意:

すべてのコンテンツ管理システムで、vis.useSessionVisitorConnectionをfalseに設定するか、省略する必要があります。それによって、訪問者属性を作成するか、それ以外では管理できるデータベース中心のメソッドを有効化します。(訪問者属性の管理は、データベース中心のトラッキングが有効なコンテンツ管理システムでのみサポートされます。配信システムではサポートされません。訪問者属性を配信システムに公開する必要があります。)

41.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

このテンプレートの詳細は、第41.3項「メモリー中心の訪問者追跡の機能」を参照してください。

41.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秒に設定されます。

41.3 メモリー中心の訪問者追跡の機能

この章の残りの部分の図は、メモリー中心の追跡の機能を示しています。

注意:

次の図のアドオン・リポジトリは独自に選択可能なシステムであり、訪問者のスカラー属性値を格納および取得するために使用されます。値を格納および取得するにはカスタム・コードを記述する必要があります。

この項の内容は、次のとおりです。

- 第41.3.1「訪問者の検出」

- 第41.3.2項「スカラー値の取得」

- 第41.3.3項「履歴属性値の収集」

- 第41.3.4項「合計および数の計算」

- 第41.3.5項「セグメントの計算」

- 第41.3.6項「推奨されるアセットの決定および表示」

- 第41.3.7項「依存性の記録」

41.3.1 訪問者の検出

サイトへの初回ログイン時、訪問者は個人プロファイルを作成します。次のイベントが発生します。

1. テンプレート・コード内のvdm:setaliasタグを使用して、訪問者の別名がWebCenter Sitesデータベースに記録されます。後続のセッションでは、訪問者が自動的に認識されます。その結果、データベースには訪問者に一意の単一IDのみが保持され、パフォーマンスが向上します。
メモリー中心の訪問者追跡では訪問者ごとに一意のIDが記録される一方、既存のデータベース中心のメソッドでは訪問ごとに一意のID(再度訪問する訪問者に対しても)が記録されます。必要のないIDによってデータベースに余分な負荷がかかり、パフォーマンスが低下します。

2. 訪問者のスカラー値(年齢、性別などの個人情報)がアドオン・リポジトリに(カスタム・コードごとに)格納されます。

残りの手順では、訪問者のセグメントを決定し、訪問者に表示するEngageアセットを決定するために必要な情報がWebCenter Sitesによって収集および計算されます。

図41-1 訪問者の検出のフロー

41.3.2 スカラー値の取得

WebCenter Sitesで訪問者のセグメントの計算が開始されます。次のスカラー値で開始されます。

1. WebCenter Sitesによってアドオン・リポジトリから(カスタム・コードを使用して)スカラー値が取得されます。

2. WebCenter Sitesでは、vdm:setscalarタグを使用して、取得したスカラー値がメモリーに設定されます。
セッション・ベースの実装により、訪問者情報(スカラー値)はhttpセッションにのみ格納されます。したがって、新しいセッションが始まると、訪問者情報はWebCenter Sitesデータベースではなくアドオン・リポジトリを介して使用可能になります。訪問者のスカラー値の問合せパフォーマンスを最適化するために、新しいレベルのキャッシュが追加されています。

図41-2 スカラー値の取得のフロー

41.3.3 履歴属性値の収集

訪問者のセグメントの計算には履歴属性値も必要になります。セッション中、履歴属性値が周期的に収集されます。

1. 履歴属性値を1分間隔でメモリーに収集するには、vdm:recordhistoryタグを使用します。

2. 履歴属性値は、ファイル・システムに格納された後、数回に分けてバッチでWebCenter Sitesデータベースに書き込まれます。メモリーが消去され、再度このサイクルが開始されます。
訪問者の履歴属性値を最初にメモリーに収集することによって、コールごとにデータベース接続を取得する必要がなくなります。これらをファイル・システムに格納し、バッチによるデータベースへの保存を可能にすることで、メモリーおよびデータベース接続の使用が最小化され、履歴属性値の可用性が高まります。

履歴属性値がデータベースにコミットされると、第41.3.4項「合計および数の計算」に示すように、合計と数の計算が始まります。

図41-3 履歴属性値のフロー

41.3.4 合計および数の計算

履歴属性値の最初のセットが収集され、データベースに書き込まれると、WebCenter Sitesでは次が実行されます。

1. 1分間隔でデータベースを読み込み、合計と数を計算して、その結果をメモリーに格納します。

合計および数のキャッシュによってデータベース問合せが著しく減少するとともに、1分間隔にすることで1分以内の正確な合計と数が計算されます。

図41-4 合計および数の計算のフロー

41.3.5 セグメントの計算

この時点で、WebCenter Sitesには訪問者のセグメントを計算するのに十分な情報が保持されています。WebCenter Sitesは、commercecontext:calculatesegmentsタグを使用して次を実行します。

1. メモリー内の訪問者のスカラー値をセグメント・ルール内のものと比較します。

2. データベース内の履歴属性値をセグメント・ルール内のものと比較します。

3. メモリー内の合計と数をセグメント・ルール内の合計または数と比較します。

この比較によって、WebCenter Sitesでは訪問者のセグメントが決定されます。

図41-5 セグメントの計算のフロー

41.3.6 推奨されるアセットの決定および表示

訪問者のセグメントを決定した後、WebCenter Sitesでは、commercecontext:getrecommendationsタグを使用して訪問者に最も関心のあるEngageアセットが決定されます。Engageアセットのテンプレートによって、推奨されるアセットが訪問者に表示されます。

さらにパフォーマンスを向上するには、render:overridedepsタグを第41.3.7項「依存性の記録」で説明するように使用します。

図41-6 推奨されるアセットの表示のフロー

41.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は十分注意して使用してください。ページ・キャッシュをフラッシュする唯一の方法は、依存性が記録されているアセットを編集することです。たとえば、単一アセット(またはアセット・タイプ)の依存性を記録している場合は、依存性が記録されているアセットを編集することでキャッシュをフラッシュできます。ユーザーは、編集が必要なアセットを把握しておく必要があります。

42 Asset APIのチュートリアル

このチュートリアルの目的は、開発者を対象に、Asset APIの概要を説明することです。つまり、クイックリファレンスであり、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスの代替ではありません。このチュートリアル全体を通じて取り上げられているコードサンプルは、Asset APIの使用方法を示しています。

この章には次の項が含まれます。

- 第42.1項「Asset APIの理解」

- 第42.2項「主要インタフェース」

- 第42.3項「はじめに」

- 第42.4項「Asset APIによる読取り」

- 第42.5項「Asset APIによる書込み」

- 第42.6項「開発戦略」

- 第42.7項「オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定」

42.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では、ロード対象のアセット以外の依存性が一切ログに記録されません。

42.2 主要インタフェース

Asset APIを使用すると、WebCenter Sitesのアセットのデータと定義の両方にアクセスできます。

- com.fatwire.assetapi.dataパッケージには、データの読取りに役立つクラスが含まれています。

- com.fatwire.assetapi.defの下のクラスは、アセットの定義用です。

- com.fatwire.assetapi.queryパッケージには、問合せを作成するために必要な構成体が含まれています。詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

Asset APIでは、次の主要インタフェースが定義されています。

- Session: APIからWebCenter Sitesへの主要なエントリ・ポイントです。Asset APIでなんらかの処理を実行するためには、セッションを取得する必要があります。

- AssetDataManager: アセット・データを読み取るためのマネージャです。開発者は、ここで情報を問い合せることができるとともに、アセットのアソシエーションなどの情報を検索できます。

- AssetTypeDefManager: アセット・タイプの定義を読み取るためのマネージャ。「定義」は、フレックス・アセットが重要となるWebCenter Sitesでロードされる条件です。ここでは、アセット・タイプの構造を定義するものと同様に、一般的な意味で使用されます。その結果、ベーシック・アセット・タイプにも定義があります。

- AssetData: アセットのデータです。基本的には、AttributeDataインスタンスおよびアセット自体に関するその他の情報のコレクションです。

- AssetId: アセット・タイプとIDの組合せです。

- DimensionableAssetManager: 特定のアセットの翻訳を取得することで多言語アセットをサポートするマネージャです。

42.3 はじめに

- このチュートリアルの例を実行するには、FirstSiteII (FSII)が必要です。tools.jarファイル(JDK 1.5以降に付属)がクラスパス内に存在している必要があります。

注意:

Asset APIは、スタンドアロンJavaプログラムから使用できます。そのためには、いくつかの設定が必要です。詳細は、第42.7項「オプション: スタンドアロンJavaプログラムからAsset APIを使用するための設定」を参照してください。

- この章の例に取り組むには、jspエレメントに関する知識と、これらのエレメントがWebCenter Sites環境でどのように作成されるのかに関する知識が必要です。詳細および手順については、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

42.4 Asset APIによる読取り

ここまでの簡単な背景情報に基づいて、FSIIデータに基づいたいくつかのコードを記述してみましょう。

この項の内容は、次のとおりです。

- 第42.4.1項「簡単な例: フィールド値の読取り」

- 第42.4.2項「AssetIdの読取り」

- 第42.4.3項「アセットIDに基づいた属性の読取り」

- 第42.4.4項「問合せ」

- 第42.4.5項「複雑な問合せ」

- 第42.4.6項「ソート」

- 第42.4.7項「BlobObjectの読取り」

- 第42.4.8項「複数値属性の取得」

- 第42.4.9項「多言語アセット: 翻訳の取得」

- 第42.4.10項「アセットと属性の定義の読取り」

- 第42.4.11項「キーと値のマッピングの読取り」

42.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に属するセッションを取得することもできます。CS駆動型のWebアプリケーションは通常、実行時にこのユーザーとして実行されます。ただし、ユーザー名とパスワードが指定された場合に、それらが間違っていた場合は、例外が返されます。

2. このセッションを使用して、AssetDataManager.getManagerのハンドルを取得します。(AssetDataManager.class.getName()メソッドによってこの処理が実行されます。)

3. Queryは、このユーザーの検索条件に基づいた結果を表しています。この例では、シンプルなバージョンのQueryを使用して、アセット・タイプ(Content_C)、サブタイプ(FSII Article)、および取得する属性のリスト(この場合は単にFSIIHeadline)を指定しています。すべてのアセットが目的であるため、3つ目のパラメータ(Conditionインスタンスを受け取ります)はnullです。Conditionの使用法は、後述の第42.4.5項「複雑な問合せ」で示します。

4. AssetDataManagerのread()メソッドは、AssetDataに対するIterableを返します。それぞれのアセット・データには、属性名に対するAttributeDataのインスタンスが含まれています。AttributeData.getData()は、属性自体の実際のデータを返します。

42.4.2 AssetIdの読取り

これらすべてのアセットのIDを取得するにはどうすればいいでしょうか。AssetData.getAssetId()は、AssetIdインスタンスを返します。

第42.4.1項「簡単な例: フィールド値の読取り」のコードは、次に示すように変更すると、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
...

42.4.3 アセットIDに基づいた属性の読取り

なんらかの手段によってアセットのidをすでに取得している場合はどうでしょうか。(テンプレートに渡されたかプログラムを通じて取得した。)そのアセットの属性をどのようにして読み取ることができるでしょうか。ここでは、第42.4.2項「AssetIdの読取り」で使用したコードのAssetId (Content_C:1114083739888を例として取り上げて、このアセットの名前、説明および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>

42.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のコレクションに格納された状態で取得する属性名のリストを渡しています。

問合せ可能な属性の型とその方法について、いくつかの考慮事項が存在します。各種の問合せアルゴリズムの詳細は、第42.6.2項「問合せのタイプ」を参照してください。簡単に言うと、一部のタイプの問合せは特定のアルゴリズムで実行できますが、他のアルゴリズムでは実行できません。これは、Assetタグ・ファミリとAssetSetタグ・ファミリにおける動作とまったく同じです。このことを例示するために、たとえば、価格(FSIIPrice)が179より高いすべての製品を読み取るとします。

FSIIPriceは、MONEY型です。第42.6.3項「データ型と有効な問合せ演算」の表42-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>

42.4.5 複雑な問合せ

複雑な問合せを作成するには、ネストされた複数のConditionを使用します。選択した問合せアルゴリズムに応じて、第42.6.2項「問合せのタイプ」に列記している制約を受けます。

次のコードでは、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>

42.4.6 ソート

価格に基づいてソートされた結果を取得するにはどうすればいいでしょうか。次のコードでは、SortOrderを指定することで(この例では昇順)、この処理を実行します。ソート順序を逆にするには、このコードの強調表示された行でtrueをfalseに変更します。

<%@ 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

42.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>

42.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>

42.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>

42.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>

42.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>

42.5 Asset APIによる書込み

Asset APIは、ベーシック・アセットおよび特定タイプのフレックス・アセットに対する書込み操作をサポートしています。サポートされている書込み操作は、アセットの作成、変更および削除です。サポートされているアセットは、ベーシック・アセット、フレックス・アセットおよびフレックス親です。これら以外のすべてのアセット・タイプ(フレックス親定義、フレックス・アセット定義、フレックス・フィルタおよびフレックス属性)は、現在サポートされていません。これらのアセット・タイプに対するいずれかの書込み操作(挿入または更新)が試行された場合は、UnsupportedOperationExceptionがスローされます。

この項の内容は、次のとおりです。

- 第42.5.1項「新規アセットの作成」

- 第42.5.2項「既存のアセットの更新」

- 第42.5.3項「既存のアセットの削除」

- 第42.5.4項「多言語アセット」

42.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>

42.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>

42.5.3 既存のアセットの削除

Asset APIは、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>

42.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>

42.6 開発戦略

この項では、データ型と属性データ(これにより、WebCenter Sitesデータ型をJava型にマップします)とともに、問合せのタイプ(問合せのタイプの比較、それらの使用方法、およびサポートされている演算)について説明します。

この項の内容は、次のとおりです。

- 第42.6.1項「データ型と属性データ」

- 第42.6.2項「問合せのタイプ」

- 第42.6.3項「データ型と有効な問合せ演算」

42.6.1 データ型と属性データ

AttributeDataには、データ型(WebCenter Sites固有の型)に関する情報と実際のデータが含まれています。これらの型は、AttributeTypeEnumで定義されています。AttributeData.getData()とAttributeData.getDataAsList()は、特定のJava型のデータ・オブジェクトを返します。次の表では、WebCenter Sitesのデータ型とそれぞれに対応するJava型を示しています。

表42-1 WebCenter Sitesのデータ型とJava型

WebCenter Sitesのデータ型

Java型

INT

整数

FLOAT

倍精度

STRING

文字列

DATE

日付

MONEY

倍精度

LONG

Long型

LARGE_TEXT

文字列

ASSET

AssetId

BLOB

BlobObject

42.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、名前、説明など)。

- ベーシック属性に基づいてソートすることはできません。

- フレックス問合せは、サブタイプが指定されていなくても機能します。その場合は、すべてのサブタイプのデータが検索対象になります。

- 条件で使用できる演算子は、LIKE、EQUALS、BETWEENおよびRICHTEXTのみです。

42.6.3 データ型と有効な問合せ演算

実行する問合せのタイプに応じて、特定のデータ型について許可される演算のタイプに関するさらなる制約が存在します。

一般に、フレックス・タイプ問合せ(フレックス・アセットのデフォルト問合せ)で許可されるOpTypeEnumsは、LIKE、EQUALS、BETWEENおよびRICHTEXTのみです。AssetSet/SearchStateタグからも同じ操作を実行できる点に注意してください。

他のOpTypeEnumsを使用するには、ベーシック/汎用問合せを使用する必要があります(そのためにはQueryProperties.setIsBasicSearch( true )を設定します)。このような問合せは、当然ながら、前述のベーシック問合せのルールに従う必要があります。

次の表では、ベーシック/汎用問合せで各データ型(単一値または複数値)について許可されている演算を示しています。

表42-2 許可される演算のセット

データ型

等しい

NOT_EQUALS

LIKE

GREATER

LESSTHAN

間

RICHTEXT

INT

はい

はい

N

はい

はい

–

N

FLOAT

はい

はい

N

はい

はい

–

N

STRING

はい

はい

はい

はい

はい

–

N

DATE

はい

はい

N

はい

はい

–

N

MONEY

はい

はい

N

はい

はい

–

N

LONG

はい

はい

N

はい

はい

–

N

LARGE_TEXT

N

N

はい

N

N

–

N

ASSET

はい

はい

N

N

N

–

N

BLOB

N

N

N

N

N

–

N

次の表では、フレックス・タイプ問合せで各データ型(単一値または複数値)について許可されている演算を示しています。

表42-3 データ型ごとに許可される演算のセット

データ型

等しい

NOT_EQUALS

LIKE

GREATER

未満

間

RICHTEXT

INT

はい

–

N

–

–

はい

N

FLOAT

はい

–

N

–

–

はい

N

STRING

はい

–

はい

–

–

はい

N

DATE

はい

–

N

–

–

はい

N

MONEY

はい

–

N

–

–

はい

N

LONG

はい

–

N

–

–

はい

N

LARGE_TEXT

N

–

はい

–

–

N

はい

ASSET

はい

–

N

–

–

はい

N

BLOB

N

–

N

–

–

N

はい

42.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フォルダからコピーできます。

- wem_sso.xml: インストール済のWebCenter SitesにWEMがインストールされており、かつシングル・サインオンが(futuretense.ini内で)trueに設定されている場合に必要です。wem_sso.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プロパティ(futuretense.ini内)の値です。

- cs.dbconnpictureの値(同じくfuturetense.ini内)は、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>

43 パブリック・サイト検索

WebCenter Sitesには、検索索引の管理用に新しいフレームワークがあります。このフレームワークは、編集インタフェースとライブ・サイトの両方における検索の基盤を構成します。ライブ・サイトとは訪問者側のことです。そのため、パブリック・サイト検索という名前が付いています。

この章では、検索フレームワークを紹介し、パブリック・サイト検索を作成する際のAPIの使用方法について説明します。

この章には次の項が含まれます。

- 第43.1項「検索フレームワークの概要」

- 第43.2項「索引タイプ」

- 第43.3項「検索APIの概要」

- 第43.4項「詳細構成」

43.1 検索フレームワークの概要

注意:

主に検索APIの使用方法に関心がある場合は、この項を省略できます。

図43-1は、検索エンジンの統合フレームワークが、WebCenter Sitesの他の部分とどのように連携するかを表しています。

図43-1 検索エンジンの統合

検索フレームワークは、検索API、特別なアセット・イベント・リスナー、キューのポーリング・システムで構成されています。このフレームワークは、イベント管理フレームワークおよびキュー管理フレームワークと共同で使用されます。このドキュメントでは、主に検索フレームワークについて説明します。

1. アセット・フレームワークは、アセットへの変更や追加を検出し、イベントを送信します。

2. 登録されているリスナーは、永続キューの実装を使用して、変更をキューに入れます。任意のイベントは、1つまたは多数の永続キューに入れることができます。各キューは、検索索引用データのソースと見なすことができます。

3. アセット・イベントがキューに入れられると、バックグラウンド・プロセスがキューの内容を空にして検索APIにルーティングします。

4. 検索APIは、適切な(構成可能な)検索エンジン・ベンダーの実装を選択し、索引付けプロセスを開始します。

43.2 索引タイプ

WebCenter Sitesでは、Global索引とAssetType索引という2つのタイプの索引が作成されます。Global索引は、すべてのデータ(Global索引に対して有効化されたすべてのアセット・タイプ)の索引です。複数のアセット・タイプでフレーズや式を検索する場合(Googleのような検索インタフェースの作成を試みるなど)、Global索引はより適切です。

Global索引には、索引のすべてのフィールドのデータが含まれますが、パラメータ検索に適した形式ではデータは格納されません。AssetType索引には、特定のアセット・タイプの索引付けされた情報が、パラメータで検索可能な方法で格納されています。WebCenter Sites Adminインタフェースは、アセット・タイプ検索の構成をサポートしています(索引付け可能なアセット・タイプの属性ベース検索を含む)。検索構成オプションの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

この項の内容は、次のとおりです。

- 第43.2.1項「Global索引」

- 第43.2.2項「アセット・タイプ索引」

43.2.1 Global索引

Global索引は、グローバル検索のUIを作成するためにContributorインタフェースで使用されます。索引のインスタンスは配信サーバーにも存在します。配信サーバーの索引はパブリック・サイト検索の作成に使用できます。

検索が構成された後に、ライブ・サイトにパブリッシュされたアセットのみを検索できる点に注意してください。データは、パブリッシュ時に索引付けされます。検索が構成される前にライブ・サイト上に存在していたすべてのアセットは、(アセットがライブ・サイトで再度索引付けされるまで)Global索引には反映されません。

検索索引機能はおおむねデータベース表に類似しています。Global索引を構成するフィールドは次のとおりです。

注意:

フィールド名では、大文字と小文字が区別されます。

表43-1 Global索引のフィールド

フィールド名

説明

defaultSearchField

このフィールドには、索引が付けられたアセットのデータがすべて含まれます。これは、全文検索で検索対象とするフィールドです。

defaultSearchFieldには、アセットのすべての属性の索引データが含まれます(バイナリ・フィールド・データも含む)。すべての属性のデータがこの単一フィールドにマージされ、索引が付けられます。索引自体にはこのフィールドのデータは格納されませんが、全文検索は可能です。

id

このフィールドには、アセットIDが含まれます。

AssetType

このフィールドには、アセット・タイプ(Content_C/Product_P)が含まれます。

locale

このフィールドには、ロケール文字列(たとえば、en_US)が含まれます。

name

このフィールドには、アセットの名前が含まれます。

description

アセットに関連付けられた説明。

subtype

サブタイプの名前(フレックス定義名)。

subtypeid

サブタイプのID(フレックス定義ID)。

updateddate

索引付けの時点で検出された最終更新日。

siteid

このアセットが使用できるすべてのサイトのID。

startdate

アセット表の開始日フィールド。

enddate

アセット表の終了日フィールド。

43.2.2 アセット・タイプ索引

アセット・タイプ索引は、Adminインタフェースから「管理」タブ→「検索」→「アセット・タイプ検索の構成」を選択して有効化されると作成されます。アセット・タイプが有効化されると、/shared/lucene/<アセット・タイプ名>の下に索引が作成されます。この索引には、索引のフィールドとして指定されたタイプの属性がすべて含まれます。たとえば、Content_Cの索引には次のフィールドが含まれます。

注意:

フィールド名では、大文字と小文字が区別されます。

表43-2 アセット・タイプ索引のフィールド

フィールド名

説明

DefaultSearchField

このフィールドには、索引が付けられたアセットのデータがすべて含まれます。これは、全文検索で検索対象とするフィールドです。

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(フレックスのみ)

テンプレート

テンプレート名

updatedby

このアセットを最終更新したユーザー名

updateddate

最終更新日

urlexternaldoc

未使用

urlexternaldocxml

未使用

FSIIAbstract

フレックス属性

FSIIBody

フレックス属性

FSIIByline

フレックス属性

FSIIDescriptionAttr

フレックス属性

FSIIHeadline

フレックス属性

FSIINameAttr

フレックス属性

FSIIPostDate

フレックス属性

FSIISubheadline

フレックス属性

FSIITemplateAttr

フレックス属性

どのフィールドが索引で使用できるかを視覚化するには、次に示すアドレスから入手できるツールLukeを使用します。

http://www.getopt.org/luke/

このツールを起動すると、ツールの参照機能を使用して、索引(例: ../shared/lucene/Content_C)を含むフォルダを検索するだけで索引をロードできます。

43.3 検索APIの概要

この項の内容は、次のとおりです。

- 第43.3.1項「SearchEngine」

- 第43.3.2項「QueryExpression」

- 第43.3.3項「構成」

43.3.1 SearchEngine

SearchEngineインタフェースは、検索エンジンの実装の重要な機能である索引付けと検索を定義します。SearchEngineの詳細は、Oracle Fusion Middleware 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の関連性は高くなります。

43.3.2 QueryExpression

QueryExpressionインタフェースは、検索条件を定義するための汎用インタフェースです。すべての検索エンジンが、問合せを作成するためのネイティブ・フォーマットをサポートしています。ネイティブ・フォームにはワイルドカードの定義、関連性のヒントなどが含まれます。これらは、検索エンジンごとに固有となる傾向があります。

検索エンジンは基本の問合せ構成も提供し、プログラム的に作成できます(フィールド一致に関するAND & OR)。制限はありますが、これらは一般化されたプログラム可能なインタフェースという観点で考えることができます。

QueryExpressionは、次に示す、検索エンジンの問合せの4種類の特性をカプセル化します。

- ネイティブ・テキスト検索フォーマット: ほとんどの検索エンジンは、検索用の非常に高度なネイティブ・フォーマット(ワイルド・カードや特別なヒントなどを含む)をサポートします。これは、getStringFormat()を通じて使用できます。

- 論理積と論理和: and()メソッドとor()メソッドを使用する条件のANDとOR。

- ページ区切り: getStartIndex()メソッドとgetMaxResults()メソッドを使用。

- ソート: getSortOrder()を使用。

43.3.3 構成

1. 検索索引付けが有効化されていることを確認します。
SystemEvents表で、SearchIndexEventが有効である(対応フィールド=1)ことを確認します。これはバックグラウンドで常に実行されるように構成されます(*:*:* */*/*)。実際には、約30秒ごとに実行されます。

2. アセット・リスナーが登録されていることを確認します。
アセットは、アセット・イベントを使用して検索フレームワークで処理するためにキューに入れられます。アセット・イベントは、AssetListener_reg表に登録されています。次のエントリがこの表に存在していることを確認します(存在していない場合は追加します)。

表43-3 AssetListener_reg表

ID

リスナー

ブロッキング

1153937286234

com.openmarket.basic.event.SearchAssetIdEventListener

はい

IndexSourceMetaDataConfig: IndexSource用の構成情報を格納する表。これは索引自体の構造と性質を説明します。これには、デフォルトでGlobal用の行が必要です。アセット・タイプ索引用に有効化されたどのアセット・タイプも、この表に行を追加します。

SearchEngineMetaDataConfig: 検索エンジンの構成を格納します。この表には、デフォルトではLucene用の行が必要です。

これらはインストーラで正しく構成され、Adminインタフェースで管理されます。

デフォルトはこれで十分です。構成の正確な定義と意味は、このチュートリアルの後ろの箇所で、ある程度詳しく説明します(第43.4項「詳細構成」を参照)。

43.4 詳細構成

次の各項では、特定の状況で必要になる詳細構成の側面を説明します。ただし、ほとんどの場合、デフォルトで十分です。

この項の内容は、次のとおりです。

- 第43.4.1項「Luceneパラメータの構成」

- 第43.4.2項「カスタムAnalyzerFactoryの構成」

43.4.1 Luceneパラメータの構成

注意:

これらのパラメータの一部は、索引が実行時に行う方法で重大な変更を引き起こす可能性があります。Luceneのドキュメントを参照し、検証を信頼して、サイトの最適な設定を決定します。デフォルトを変更する特別な理由がない場合は、デフォルトのままにしておくことを強くお薦めします。

Lucene検索エンジンでは、索引の作成方法と実行方法を決定する特定の一連のパラメータで索引を作成できます。Luceneのデフォルトのパラメータは合理的ですが、WebCenter Sitesには、それらを変更する方法が管理者用に用意されています。

IndexSourceMetaDataConfig表では、システムで検索する索引ごとに1行が含まれます。各行には、コンテンツがLuceneパラメータの構成に使用される、propertiesという名前のフィールドがあります。次に示すように、パラメータ値のペアはセミコロン(;)で区切られます。

param1=value1;param2=value2

表43-4は、WebCenter Sitesでサポートされているパラメータのリストです。

表43-4 WebCenter Sitesでサポートされているパラメータ

パラメータ

型

説明

mergeFactor

整数

セグメント索引がマージされる頻度を決定します。

値が小さければ、索引付け中に使用されるRAMは少なく、最適化されていない索引の検索は速くなりますが、索引付けのスピードは遅くなります。

値が大きければ、索引付け中に使用されるRAMは多く、最適化されていない索引の検索は遅くなりますが、索引付けは速くなります。そのため、より大きい値(> 10)がバッチ索引作成に適しており、より小さい値(< 10)は対話型で維持される索引に適しています。

これは2より小さくしないでください。デフォルト値は10です。

maxMergeDocs

整数

これまでにマージされたドキュメントの最大数を決定します。小さい値(たとえば、10000より小さい)が対話形式の索引付けに最適なのは、これが索引付けの一時停止の長さを数秒に制限するためです。大きい値はバッチ索引付けと高速検索に最適です。

デフォルトは最大整数値(231-1)。

maxBufferedDocs

整数

バッファされたインメモリー・ドキュメントのマージ中や新規のセグメントが作成される前に必要とされるドキュメントの最小数を決定します。

デフォルトは10。

optimizeInterval

整数

optimize()コール間の時間間隔(秒単位)を決定します。デフォルト値は30秒です。これは、ほとんどのシステムでの推奨値です。大幅にデータを変更する場合は、このパラメータを300から600秒までの範囲の値に設定します。

commitLockTimeout

Long型

コミット・ロックまで待機する最大時間を設定します(ミリ秒単位)。

デフォルトは10000。

maxFieldLength

整数

ドキュメントの1つのフィールドに索引付けされる用語の最大数。これは索引付けに必要なメモリーの容量を制限します。これにより、非常に大きなファイルのコレクションの索引付けプロセスがメモリー不足によってクラッシュする事態を防げます。

これは大きなドキュメントを効果的に切り捨て、ドキュメントにさらに付けられる索引用語から削除することに注意してください。ソース・ドキュメントが大きい場合は、見込まれるサイズを格納できるようにこの値を大きく設定します。それを整数の最大値(231-1)に設定する場合、制限があるのはメモリーのみであるため、OutOfMemoryErrorを想定しておく必要があります。

デフォルトでは、10000より多い用語はフィールドに索引付けされません。

termIndexInterval

整数

索引付けされた用語間の間隔を設定します。大きい値ではIndexReaderで使用されるメモリーが少なくなりますが、用語へのランダムアクセスは遅くなります。小さい値ではIndexReaderで使用されるメモリーが多くなるため、用語へのランダムアクセスが速くなります。

このパラメータは、問合せ用語を含むドキュメントの数に関係なく、問合せ用語ごとに必要な計算量を決定します。特に、用語を特定して、その頻度と位置の情報を処理する前に、スキャンする必要のあるその他の用語の最大数となります。ユーザー入力の問合せ用語を指定したサイズの大きい索引では、問合せ処理時間の大半が、用語参照ではなく、頻度データと位置データの処理によって占められる可能性があります。サイズの小さい索引の場合、または一般的でない問合せ用語が多数生成される場合(ワイルドカード問合せなど)は、処理時間の大半が用語参照によって占められます。特に、IndexReaderではnumUniqueTerms/interval(一意の用語数/時間間隔)用語がメモリーに読み込まれ、平均すると、ランダムな用語アクセスごとにinterval/2terms(時間間隔/2つの用語)をスキャンする必要があります。

デフォルト値は128。

useCompoundFile

String (yesまたはnoである必要があります)

複合ファイルの使用をオンにするための設定。オンの場合、セグメントの作成が終了すると、各セグメントの複数のファイルが1つのファイルにマージされます。

writeLockTimeout

Long型

書込みロックまで待機する最大時間を設定します。

デフォルト値は1000。

43.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>

44 階層的なフレックス・ファミリの作成

この章では、フレックス・ファミリの作成に役立つチュートリアルを示します。このフレックス・ファミリは、値が1つの定義に基づいた3つのレベルによる単純な階層です(また、ここでは当面、属性とそれを継承したものは無視します)。このチュートリアルを完了すると、フレックス・アセット・モデルについて、またWebCenter Sitesで階層的なコンテンツを作成するためにフレックス・アセット・モデルをどのように使用するかについて、基本的なことが理解できるようになります。同様の階層の作成元となるモデルも得られます。

第44.1項「階層組織」および第44.2項「フレックス・ファミリの仕様」では、これから作成するフレックス・ファミリについて説明します。第44.3項「手順」はチュートリアルです。ここでは、小さなフレックス・ファミリを作成し、そのファミリ・メンバーに汎用的な名前を付けます。

この章には次の項が含まれます。

- 第44.1項「階層組織」

- 第44.2項「フレックス・ファミリの仕様」

- 第44.3項「手順」

- 第44.4項「次の手順」

44.1 階層組織

このチュートリアルで作成するフレックス・ファミリは、次の3つのレベルで構成されています。

- 最上位レベルの親(ここに示す例ではParent 1 [Level 1])。

- 2番目のレベルの親(ここに示す例ではParent 2 [Level 2])。

- 3番目のレベルのアセット。あるアセットは、そのレベル1の親の直下に配置され、別のアセットは、そのレベル2の親の直下に配置され、3番目のアセットは、レベル1とレベル2両方の親の下に配置されます。

WebCenter Sitesインタフェースでは、階層は図Aに示したとおりになります。そこに表されているのは定型的なものであり、図Bは、それが、avisportsサンプル・サイトで表される現実世界のモデルにどのように変換されるかを示しています。

サンプル・サイトでは(図B):

- 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の、両方の下に表示されます。

44.2 フレックス・ファミリの仕様

表44-1には、このチュートリアルで作成するフレックス・ファミリのメンバーが一覧表示されています。フレックス・ファミリはオプションのコンポーネントであり、このチュートリアルには含まれていないことに注意してください。

表44-1 フレックス・ファミリのメンバー

フレックス・ファミリのメンバー

名前

インスタンス

親定義がベース

フレックス定義がベース

フレックス属性タイプ

My Attribute

Attribute_1注 1

Attribute_2

なし

なし

フレックス親定義タイプ

My Parent Definition

Level 1 Def

Level 2 Def

なし

Level 1 Def

なし

フレックス定義タイプ

マイ・フレックス定義

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

フレックス・フィルタ・タイプ

なし

なし

なし

なし

注 1 接尾辞の1、2および_12は、階層のレベルのことです(_12は、レベル1とレベル2の両方を指しています)。たとえば、Asset 1はレベル1の下に配置されているアセットを指しています。Asset_12はレベル1とレベル2の、両方の下に配置されているアセットを指しています。

44.3 手順

このチュートリアルでは、小さなフレックス・ファミリを作成し、そのファミリ・メンバーに汎用的な名前を付けます。このアプローチでは、階層構築の公式を視覚化しやすくなります。

このチュートリアルの終了時には、定型的なデータ・モデルがビジネス関連のデータ・モデルにどのように変換されるかを理解するために、選択したファミリ・メンバーの名前を現実世界の名前に変更します。また、さらに多くの親とアセットを階層に追加し、作成する際に現実世界の名前を付けます。

この項の内容は、次のとおりです。

- 第44.3.1項「手順1: フレックス・ファミリの作成」

- 第44.3.2項「手順2: 新規のフレックス・アセット・タイプの有効化」

- 第44.3.3項「手順3: 「フレックス・ファミリ」タブのWebCenter Sitesのツリーへの追加」

- 第44.3.4項「手順5: 親定義アセットの作成」

- 第44.3.5項「手順6: フレックス親アセットの作成」

- 第44.3.6項「手順7: フレックス定義アセットの作成」

- 第44.3.7項「手順8: フレックス・アセットの作成」

- 第44.3.8項「手順9: 定型データ・モデルを現実世界のデータ・モデルに変換」

- 第44.3.9項「手順10: 現実世界のモデルの開発」

44.3.1 手順1: フレックス・ファミリの作成

この手順では、フレックス・ファミリを作成し、その必須メンバーに名前を付けます。

フレックス・ファミリを作成するには:

1. WebCenter SitesのAdminインタフェースを起動します。

2. 「管理」タブで、「フレックス・ファミリ・メーカー」を開き、「新規ファミリの追加」をダブルクリックします。

3. 「フレックス・ファミリ・メーカー」フォームのフィールドに、次に示すように入力します。

表44-2 「フレックス・ファミリ・メーカー」フォーム

フィールド名

入力値

コメント

フレックス属性

MyAttribute

この手順では、フレックス・ファミリに対してWebCenter Sitesが作成するデータベース表に名前を付けます。この名前には空白を入れないでください。

フレックス親定義

MyParentDefinition

なし

フレックス定義

MyFlexDefinition

なし

フレックス親

MyParent

なし

フレックス・アセット

MyAsset

なし

フレックス・フィルタ

なし

なし

4. 「続行」をクリックします。

5. 次のフォームで、ファミリの新規メンバーごとに、各フィールドに次のように入力します。

1. 「説明」フィールドをクリックして、手順3と同じ名前を入力します。ただし、名前の中の単語は空白で区切ります。
ここで入力する名前は、アセット・タイプを識別するために、WebCenter Sitesインタフェース全体で使用されます。

2. 「複数」フィールド内をクリックして、前の手順で使用した名前の複数形を入力します。

3. 「新規フレックス・ファミリの追加」をクリックします。

6. WebCenter Sitesがフレックス・ファミリを作成し、フレックス・ファミリ・メンバー(アセット・タイプ)が正常にインストールされたことを示すメッセージを返すまで待ってください。

7. 次の手順に進みます。

44.3.2 手順2: 新規のフレックス・アセット・タイプの有効化

この手順では、avisportsサンプル・サイトに対してフレックス・ファミリ・メンバーを有効化します。また、メンバーのスタート・メニュー・アイテムも作成し、後続の手順でインスタンスの作成および検索ができるようにします。

注意:

avisportsサンプル・サイトがシステムにインストールされていない場合は、サイトを選択し、それに対してフレックス・ファミリを有効化できます。

新規のフレックス・アセット・タイプを有効化するには:

1. 「管理」タブで、「サイト」ノードを開き、次の手順を実行します。

1. avisports (フレックス・ファミリが有効にされるサンプル・サイト)、または選択したサイトを開きます。

2. そのサイトで「アセット・タイプ」を開き、「有効化」をダブルクリックします。

1. リストから、先ほど作成したアセット・タイプ(MyAsset、MyAttribute、MyFlexDefinition、MyParent、MyParentDefinition)を選択します。

2. 「アセット・タイプの有効化」をクリックします。

3. 「アセット・タイプの有効化」フォームで次の操作を行います。

1. 「スタート・メニュー」のオプションがすべて選択されていることを確認します(後でファミリ・メンバーのインスタンスの作成および検索ができるようにするため。)

2. 「アセット・タイプの有効化」をクリックします。

2. アセット・タイプがサイトで有効化されたことを示すメッセージをWebCenter Sitesが表示するまで待ってください。

3. 次の手順に進みます。

44.3.3 手順3: 「フレックス・ファミリ」タブのWebCenter Sitesのツリーへの追加

この手順では、フレックス・ファミリの作成を追跡するタスクを追加します。このタブは、フレックス・ファミリのメンバーの作成を終了したら、選択したそのメンバーが表示されるようにするために設定します。

ツリー・タブを追加するには:

1. 「管理」タブで、「ツリー」ノードをダブルクリックします。

2. 「ツリー・タブ」フォームで、一番下までスクロールして「新規ツリー・タブの追加」をクリックします。

3. 「新規ツリー・タブの追加」フォームで、フィールドに次のように入力します。

表44-3 「新規ツリー・タブの追加」フォーム

フィールド名

入力または選択する値

コメント

タイトル

Sample Flex Family

タブの名前。

ツールチップ

Sample Flex Family

タブの説明。

サイト

avisports (または第44.3.2項「手順2: 新規のフレックス・アセット・タイプの有効化」で選択したサイト)

フレックス・ファミリを有効化するサイト。

必須ロール

任意

なし

タブ・コンテンツ

My Parent Definition

My Parent

My Flex DefinitionMy Asset

注意: 「選択したアイテムの追加」をクリックし、「表示の順序」矢印を使用して、前述の順にメンバーを並べ替えます。

なし

4. 「保存」をクリックします。

5. 画面をリフレッシュします。

6. 「Sample Flex Family」タブをクリックして、そのコンテンツが、次の表示と同一のものになっていることを確認してください。

7. 次の手順に進みます。

44.3.4 手順5: 親定義アセットの作成

この手順では、2つの親定義を作成します。最初の親定義では階層の最上位レベルが確立され、2番目の親定義では2番目のレベルが確立されます。

最初の親定義アセットを作成するには:

1. メニュー・バーで、「新規」をクリックします。

2. 表示されるオプションのリストで、「新規のマイ親定義」を選択します。

3. 次のフォームで、次の操作を行います。

1. 次のようにフィールドに入力します。

表44-4 「新規のマイ親定義」フォーム

フィールド名

入力または選択する値

コメント

名前

Level 1 Def

これは、階層の最初のレベルの定義に付けた名前です。

説明

Level 1 Def

なし

親選択スタイル

選択ボックス

なし

マイ親定義

なし

このフィールドでは、親定義が選択されていません(または使用できません)。そのため、この親定義では階層の最初のレベルが確立されます。

2. 「保存」アイコンをクリックします。

2番目の親定義アセットを作成するには:

1. メニュー・バーで、「新規」をクリックします。

2. 表示されるオプションのリストで、「新規のマイ親定義」を選択します。

3. 次のフォームで、次の操作を行います。

1. 次のようにフィールドに入力します。

表44-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をベースにした親の下位に置かれます。

2. 「保存」アイコンをクリックします。

4. 画面をリフレッシュします。

5. 「Sample Flex Family」タブをクリックして、そのコンテンツを開き、次の表示と同一のものになっていることを確認してください。

6. 次の手順に進みます。

44.3.5 手順6: フレックス親アセットの作成

この手順では、2つのフレックス親アセットを作成し、前の手順で作成したフレックス親アセットをベースにします。最初の親アセットは、階層の最上位レベルを占めます。2番目の親アセットは、階層の2番目のレベルを占めます。

階層の最上位レベルの親を作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-6 「新規のマイ親」フォーム

フィールド名

入力または選択する値

コメント

名前

Parent 1 [Level 1]

これは、階層内のレベル1の親に付けた名前です(ここに示す例では、名前は、レベルを識別しやすくするためにのみ汎用化されています)。

注意: このチュートリアルの終了時には、この名前をビジネス固有の名前(この例ではOutdoor Sports Equipment。これは、スポーツ用品を扱う会社の在庫を記述しています)に変更します。

My Parent Definition

Level 1 Def

「Level 1 Def」を選択すると、作成中の親が階層の最上位レベルに置かれます。

4. フォームの最上部で、「保存」アイコンをクリックします。

階層の2番目のレベルの親を作成するには:

1. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

2. 表示されたフォームで、フィールドに次のように入力します。

表44-7 「新規のマイ親」フォーム

フィールド名

入力または選択する値

コメント

名前

Parent 2 [Level 2]

これは、階層内のレベル2の親に付けた名前です(ここに示す例では、名前は、レベルを識別しやすくするためにのみ汎用化されています)。

注意: このチュートリアルの終了時には、この名前をビジネス固有の名前(この例ではMountain Climbing)に変更します(これは、Parent 1 [Level 1]がSports Equipmentであれば適切な名前です)。

My Parent Definition

Level 2 Def

「Level 2 Def」を選択すると、作成中の親が階層の2番目のレベルに置かれます。

Level 1 Def

デフォルトでは、Parent 1 [Level 1]が選択されます。

なし

3. 「保存」アイコンをクリックします。

4. コンテンツ・ツリーで「Sample Flex Family」を開き、そのコンテンツが次の表示と同一のものになっていることを確認してください。

注意:

次の手順に進む前に、図44-1を確認してください。この図は、作成したオブジェクト(親定義、および定義をベースにした親)が、お互いどのように関連しているかをまとめたものです。

図44-1 親および親定義

44.3.6 手順7: フレックス定義アセットの作成

この手順では、3つのフレックス定義アセットを作成します。

- 最初のフレックス定義アセットは、アセットをParent 1 [Level 1]の下に配置するために使用します。

- 2番目のフレックス定義アセットは、アセットをParent 2 [Level 2]の下に配置するために使用します。

- 3番目のフレックス定義アセットは、アセットを階層の両方のレベルの下に配置するために使用します。

最初のフレックス定義アセットを作成するには:

1. アプリケーション・バーにある「管理」アイコンをクリックして、Adminインタフェースに切り替えます。

2. メニュー・バーで、「新規」をクリックします。

3. 表示されるオプションのリストで、「新規のマイ・フレックス定義」を選択します。

4. 表示されたフォームで、フィールドに次のように入力します。

表44-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. 表示されたフォームで、フィールドに次のように入力します。

表44-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. 表示されたフォームで、フィールドに次のように入力します。

表44-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」タブをクリックしてそのコンテンツを開き、次の表示と同一のものになっていることを確認してください。

注意:

次の手順に進む前に、図44-2を確認してください。この図には、Sample Flex Familyの構造が、Contributorアプリケーションで表示されるとおりに描かれています。この図は、作成したオブジェクト(フレックス定義)とベースの親定義の関連をまとめたものです。

44.3.7 手順8: フレックス・アセットの作成

この手順では、階層の3番目のレベル(フレックス・アセット)を追加して、フレックス・ファミリを完成します。作成するアセットは次の3つです。

- Parent 1 [Level 1]の下に配置する最初のアセット。

- Parent 2 [Level 2]の下に配置する2番目のアセット。

- Parent 1 [Level 1]とParent 2 [Level 2]の、両方の下に配置する3番目のアセット。

最初のフレックス・アセットを作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから、「新規」→「新規のマイ・アセット」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-11 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset 1

なし

マイ・フレックス定義

Flex Def 1

Flex Def 1を選択すると、作成中のアセットがParent 1 [Level 1]の下に配置されます。

4. 「保存」アイコンをクリックします。

2番目のフレックス・アセットを作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから、「新規」→「新規のマイ・アセット」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-12 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset 2

なし

マイ・フレックス定義

Flex Def 2

Flex Def 2を選択すると、作成中のアセットがParent [Level 2]の下に配置されます。

4. 次のフォームで、「保存」をクリックします。

2番目のフレックス・アセットを作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから、「新規」→「新規のマイ・アセット」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-13 「新規のマイ・アセット」フォーム

フィールド名

入力または選択する値

コメント

名前

Asset_12

なし

フレックス定義

Flex Def_12

Flex Def_12を選択すると、作成中のアセットがParent [Level 1]とParent [Level 2]の、両方の下に配置されます。

4. 次のフォームで、「保存」アイコンをクリックします。

5. 画面をリフレッシュします。

6. 「Sample Flex Family」タブをクリックして、そのコンテンツを開き、次の表示と同一のものになっていることを確認してください。

図44-2 Sample Flex Familyの構造

注意:

次の図は、作成したオブジェクト(アセット)が、ベースとなるフレックス定義とどのように関連しているかをまとめたものです。

44.3.8 手順9: 定型データ・モデルを現実世界のデータ・モデルに変換

この手順では、作成した定型データ・モデルを現実世界のモデルに変換するために、親定義、親およびアセットの名前を変更します。(実際には、フレックス・ファミリ・メンバーの名前を変更するのではなく、フレックス・ファミリ・メンバーの作成時に、ビジネス・コンテキストにおいて直接名前を付けます。)

ここに示す例では、現実世界のモデルは、スポーツ用品を扱う企業を記述しています。フレックス親とアセットは、名前変更の終了後に、次の図に示すように、「コンテンツ・ツリー」タブに一覧表示されます。

現実世界のモデルを作成するには:

1. 次のようにして、親定義の名前を変更します。

1. Adminアプリケーションを開きます。

2. Sample Flex Familyのツリーで「Level 1 Def」を右クリックし、コンテキスト・メニューから「編集」を選択します。

3. 親の名前を「Level 1 Def (Type of Sports Equipment)」に置換し、「保存」アイコンをクリックします。

4. 同じようにして、「Level 2 Def」の名前をLevel 2 Def (Sport)に置換します。

2. 次のようにして、親の名前を変更します。

1. Contributorアプリケーションに切り替えます。

2. 「コンテンツ・ツリー」をクリックして、そのコンテンツを表示します。

3. Sample Flex Familyのツリーで「Parent 1 [Level 1]」を右クリックし、コンテキスト・メニューから「編集」を選択します。

4. 親の名前をOutdoor Sports Equipmentに置換して、「保存」アイコンをクリックします。

5. 同じようにして、「Parent 2 [Level 2]」の名前をMountain Climbingに置換します。Sample Flex Familyのツリーは、次のようになります。

3. 次のようにして、アセットの名前を変更します。

1. Sample Flex Familyのツリーで、「Outdoor Sports Equipment」を開きます。

2. 「Asset 1」を右クリックし、「編集」を選択します。

3. アセットの名前をOur Awesome Catalogに置換し、「保存」アイコンをクリックします。

4. 同じようにして、「Mountain Climbing」を開いて「Asset 2」の名前をHigh Altitude Gearに置換します。

5. 「Asset_12」の名前をSpecial Ordersに置換します。名前変更後のアセットは、次のようになります。

44.3.9 手順10: 現実世界のモデルの開発

この手順では、親およびそのアセットを新規作成し、それぞれに現実世界の名前を指定することによって、データ・モデルを開発します。次の操作を行います。

- レベル2の2番目の親を作成し、White Wateringという名前を付けます。

- 親のアセット(カタログ)を作成し、Rafts, Canoes, and Kayaksという名前を付けます。「White Watering」を開いて、そのアセットを表示します。

注意:

この手順を完了すると、高度な手法を用いて、現実世界のモデルをさらに開発できるようになります。ここに示す例では、値が複数ある親定義とフレックス定義を使用することを通じた、n:1の親子関係の作成を示します。開発プロセスを進めやすくし、プロセスをどの程度理解しているかをテストできるようにするため、手順を追った説明ではなくガイドラインが用意されています。

モデル開発の指示が必要な場合は、次の手順に従ってください。

レベル2の親を作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから「新規」→「新規のマイ親」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-14 「新規のマイ親」フォーム

フィールド名

値

名前

White Watering

My Parent Definition

Level 2 Def (Sports)

4. 「保存」アイコンをクリックします。

親のアセットを作成するには:

1. 最上位で「コントリビュータ」アイコンをクリックして、Contributorアプリケーションに切り替えます。

2. 「コンテンツ」メニューから、「新規」→「新規のマイ・アセット」を選択します。

3. 表示されたフォームで、フィールドに次のように入力します。

表44-15 「新規のマイ・アセット」フォーム

フィールド名

値

名前

Rafts, Canoes, and Kayaks

マイ・フレックス定義

Flex Def 2

4. 「Level 2 Def」ドロップダウン・リストから、「White Watering」を選択します。

5. 「保存」アイコンをクリックします。

6. 画面をリフレッシュして、Sample Flex Familyのツリー・タブを表示します。そのコンテンツは、次の表示されるものと同一になります。

44.4 次の手順

この時点では、基礎的なデータ・モデルを作成しています。ここからは、指定されたレベルを占める追加の親を作成したり、(フレックス親定義をつないで)追加のレベルを作成するなどして、データ・モデルを開くことができます。アセット間にアソシエーションを作成したり、テンプレート・コードを記述してアセットを書式設定したり、サイト訪問者にアセットを表示するパブリッシュ・オプションをテストしたりすることもできます。これらの操作の詳細は、第16章「フレックス・アセット・タイプの設計」を参照してください。

45 WebCenter SitesのURLアセンブラ

この章では、WebCenter SitesのURLアセンブラについて説明します。これは、URLアセンブリとURL逆アセンブリを管理し、URLの表示の定義に使用できるインタフェースを提供します。

この章には次の項が含まれます。

- 第45.1項「WebCenter SitesのURLアセンブラの概要」

- 第45.2項「WebCenter Sitesとともにインストールされるアセンブラ」

- 第45.3項「アセンブラの使用」

- 第45.4項「WebページでのバニティURLリンクの生成」

45.1 WebCenter SitesのURLアセンブラの概要

URLアセンブラは、URL生成タグとともに、WebCenter SitesのURLの生成や、URLアセンブラが生成するURLの逆アセンブルに使用されます。

この項の内容は、次のとおりです。

- 第45.1.1項「URLアセンブリ」

- 第45.1.2項「アセンブラ検出と逆アセンブリ」

- 第45.1.3項「GETリクエストとPOSTリクエストを使用するURLアセンブリとURL逆アセンブリ」

45.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の作成に使用されます。デフォルトのアセンブラは変更できます。個々のリンク・タグで、このデフォルトのアセンブラの使用をオーバーライドすることもできます。

45.1.2 アセンブラ検出と逆アセンブリ

アセンブラは、アセンブラの作成者が求めるいずれのフォームでもURLを作成できるため、アセンブルされたリンクが要求される場合は、アプリケーション・サーバーによってURLをパラメータにデコードできない場合があります。デコードを実行するには、アセンブラが文字列URLをその定義に逆アセンブルできる必要があります。したがって、アセンブラは可逆性であり、アセンブルしたどのURLも逆アセンブルできます。

URLがデフォルトのアセンブラ以外のアセンブラを使用して作成されている場合は、デフォルトのアセンブラはそのURLを逆アセンブルできません。その時点で、次の上位ランクのアセンブラがそのURLの逆アセンブルを試みます。定義の作成に成功した場合は、アセンブラ・エンジンがそのアセンブラを検出したと言われ、定義がパラメータに変換されて処理されます。次の上位ランクのアセンブラがそのURLの逆アセンブルに失敗した場合は、3番目の上位ランクのアセンブラがコールされ、そのURLを逆アセンブルします。このプロセスは、URLが逆アセンブルに成功するまで続行します。このプロセスでは、アセンブラが、アセンブルしたURLを自己のものであると認識し、他のすべてのURLを外部のものであると認識できることが必要です。

アセンブラの作成、登録、ランク付けの詳細は、第45.3.1項「アセンブラの作成」および第45.3.2項「アセンブラの登録とランク付け」を参照してください。

45.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>

45.2 WebCenter Sitesとともにインストールされるアセンブラ

WebCenter Sitesとともにインストールされる2つのアセンブラは、QueryアセンブラとQueryAsPathInfoアセンブラです。

この項の内容は、次のとおりです。

- 第45.2.1項「Queryアセンブラ」

- 第45.2.2項「QueryAsPathInfoアセンブラ」

45.2.1 Queryアセンブラ

Queryアセンブラは、問合せ文字列でURLを作成します。これはデフォルトのアセンブラで、WebCenter Sitesに自動的に登録されています。したがって、(デフォルトのアセンブラの変更やリンク・タグにおけるデフォルトのオーバーライドなどを)変更するまで、QueryアセンブラはすべてのURLの生成に使用されます。

45.2.2 QueryAsPathInfoアセンブラ

QueryAsPathInfoアセンブラは問合せ文字列を使用しません。かわりに、QueryAsPathInfoアセンブラは問合せ文字列をエンコードし、サーブレット名の末尾に付加します。このアセンブラの利点は、検索エンジンで索引付けできるURLを作成することです。QueryAsPathInfoアセンブラは、WebCenter Sitesに自動的には登録されていません。

注意:

サンプルURLアセンブラの実装は、FirstSiteIIのサンプル・サイトに付属しています。ソース・コードは、WebCenter Sites CDの次の場所に格納されています。

/ContentServer/FirstSiteII/PrettyURL/src/com/fatwire/firstsite/uri/FSIIAssembler.java

詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。関係のあるクラスは次のとおりです。

- Definiton

- Definiton.AppType

- Definiton.ContainerType

- AbstractAssembler

- AbstractAssembler.AssemblyContext

- AbstractAssembler.DisAssemblyContext

- Assembler

- DisAssembler

これは、コードを1ステップずつ実行できるようにFSIIAssembler.javaでデバッグ環境を設定する際に役立つこともあります。

45.3 アセンブラの使用

この項では、独自のアセンブラの作成と登録の方法について説明します。この項では、デフォルトのアセンブラの使用をオーバーライドするようにリンク・タグを変更する方法も説明します。

この項の内容は、次のとおりです。

- 第45.3.1項「アセンブラの作成」

- 第45.3.2項「アセンブラの登録とランク付け」

- 第45.3.3項「リンク・タグの変更」

45.3.1 アセンブラの作成

WebCenter SitesのURL Assemblyモジュールを使用して、独自のアセンブラを作成できます。このオプションにより、URLの外観を直接制御できます。

アセンブラを作成するには:

1. com.fatwire.cs.core.uri.Assemblerインタフェースを実装するjavaクラスを記述します。このクラスの詳細は、Oracle Fusion Middleware 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すべての両方で、ServletRequest.propertiesファイルに新規のアセンブラを登録します(手順については、第45.3.2項「アセンブラの登録とランク付け」を参照)。

5. WebCenter SitesとリモートのSatellite Serverすべてを再起動します。

45.3.2 アセンブラの登録とランク付け

URLの作成にアセンブラを使用できるようにするには、まずWebCenter Sitesに登録しておく必要があります。登録は、ショート・フォームに対応するアセンブラ・クラス名をプロパティ・ファイルに列記することで実行されます。登録には、アセンブラの使用順序を示すランキングも含まれます。

アセンブラを登録するには:

1. プロパティ・エディタを起動します。

2. ServletRequest.propertiesファイルを開きます。

3. 「URIアセンブラ」タブをクリックして、アセンブラのプロパティにアクセスします。

4. 登録するアセンブラのclassnameとshortformを指定します。
プロパティ名の3番目のエレメントは、アセンブラのランキングを示しています。ランキング0のアセンブラは最上位ランク(およびデフォルト)のアセンブラ、ランキング1のアセンブラは次の上位ランクです。以降も同様になります。

デフォルトのアセンブラとして新規のアセンブラを構成する場合は、ランキング1のプロパティにclassnameとshortformの値を入力します。

たとえば、デフォルトのアセンブラとしてQueryAsPathInfoアセンブラを登録するための構文は、次のようになります。

表45-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アセンブラは、shortformの値をqueryとして登録する必要があります。

1. 新規のアセンブラのランキングに応じて、その他のアセンブラのランキングを調整する必要がある場合もあります。すべてのアセンブラがプロパティ・ファイルで正しく構成され、ランク付けされていることを確認します。そうでない場合は、必要な変更を実行します。

2. 「ファイル」→「保存」を選択して変更内容を保存し、プロパティ・エディタを閉じます。

3. インストールしたリモートのSatellite Serverごとに、手順1から2を繰り返します。

4. WebCenter SitesとリモートのSatellite Serverすべてを再起動します。

45.3.3 リンク・タグの変更

WebCenter Sitesのリンク・タグは、デフォルトのアセンブラ以外のアセンブラを使用するように変更できます。リンク・タグは属性assemblerを受け入れ、値としてアセンブラのショート・フォームを取ります。

たとえば、個々のリンク・タグで、デフォルトのアセンブラをオーバーライドしてQueryAsPathInfoアセンブラにするための構文は、次のようになります。

<satellite:link pagename=example assembler=pathinfo />

45.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" hostparam=<hostname of the WebRoot asset> tname='<%=ics.GetVar("template")%>' args="c,cid" />

46 空白と圧縮

WebCenter Sitesでテキスト・ページがストリームされると、かなりの量の空白(スペース、改行およびタブ)がページに含まれることがあります。この空白は、クライアントで消費されたデータには影響しません。ソース・コードがコンシューマに表示されるときに空白が可視状態になりますが、これは望ましくありません。さらに、過剰な空白はレスポンスのサイズを不必要に増加し、これが最終的に帯域幅の使用を増加します。したがって、可能なかぎり空白を削除することが効果的です。

この章には次の項が含まれます。

- 第46.1項「空白とJSP」

- 第46.2項「空白とXML」

- 第46.3「圧縮」

- 第46.4項「JSPの設計」

46.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つあります。さらに複雑なページでは、問題は複雑になります。

46.2 空白とXML

WebCenter SitesのXML処理言語は、独自のXML対応タグのセットであり、JSPの空白保持ルールにこだわりません。このため、次のようなWebCenter Sites XMLページの場合

<? XML version 1.0 ?>
<FTCS>
<p>Hello World!</p>
</FTCS>

<p>を出力の最初の文字として表示します。XML Parserはすべての空白を削除するためです(XMLデバッグが有効になっていて、すべての空白が保持されている場合を除く)。

46.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 Consulting Servicesにお問い合せください。

46.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に含まれています。

47 WebCenter Sitesでのアセット・イベントおよびパブリッシュ・イベント

WebCenter Sitesのイベント・フレームワークによって、開発者は、WebCenter Sites内の特定のイベントに対して実行するカスタム・ビジネス・ロジックを記述できます。カスタム・ビジネス・ロジックは、事前定義済のインタフェースを実装するクラスパスに、Javaクラスの形式で実装する必要があります。このチュートリアルでは、リスナーの作成手順について説明します。

この章では、イベント・リスナーの作成手順について説明します。この章は、次の項で構成されています。

- 第47.1項「イベントのタイプ」

- 第47.2項「アセット・イベント」

- 第47.3項「パブリッシュ・イベント」

47.1 イベントのタイプ

WebCenter Sitesでは現在、アセット・イベントおよびパブリッシュ・イベントの2つのイベント・タイプがサポートされています。

- アセット・イベントは、ユーザーまたはプログラムのいずれかによってアセットが追加、変更または削除された際に発生するイベントです。このイベントの発生時、構成済の一連のイベントがイベント・フレームワークによって参照および実行されます。

- パブリッシュ・イベントは、パブリッシュ・プロセスの各手順でリアルタイム・パブリッシュ・フレームワークが生成するイベントです。この機能は、システム監視(SNMPなど)やその他のハウスキーピング・プロセスの促進を目的としています。

47.2 アセット・イベント

この項の内容は、次のとおりです。

- 第47.2.1項「アセット・イベント・リスナーの記述」

- 第47.2.2項「アセット・イベント・リスナーの登録」

47.2.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");
}
}

アセット・イベント・リスナーはアセット操作の発生後に起動され、データのコミット前には起動されません。

47.2.2 アセット・イベント・リスナーの登録

注意:

WebCenter Sitesは、検索の索引付けに使用する標準リスナーを実装した状態で出荷されます。変更または削除は行わないでください。

アセット・イベント・リスナーは、AssetListener_regデータベース表に登録されます。テーブルの構造は次のとおりです。

表47-1 AssetListener_regデータベース表

ID (整数)

行の一意のID

listener(String)

AssetEventListenerを実装する完全修飾されたクラス名。たとえば、com.mycompany.CustomAssetEventListenerなどです。

blocking(YまたはN)

'Yは、リスナーがブロッキング状態であることを示します(イベントを生成したスレッドと同時に実行されます)。

'Nは、リスナーがブロッキング状態でないことを示します(別のスレッドで実行されます)。

47.3 パブリッシュ・イベント

この項の内容は、次のとおりです。

- 第47.3.1項「パブリッシュ・イベント・リスナーの記述」

- 第47.3.2項「パブリッシュ・イベント・リスナーの登録」

47.3.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

47.3.2 パブリッシュ・イベント・リスナーの登録

パブリッシュ・イベント・リスナーは、FW_PublishingEventRegistryデータベース表に登録されます。テーブルの構造は次のとおりです。

表47-2 FW_PublishingEventRegistryデータベース表

ID (整数)

行の一意のID

listener(String)

AssetEventListenerを実装する完全修飾されたクラス名。たとえば、com.mycompany.CustomPublishingEventListenerなどです。

blocking(YまたはN)

'Yは、リスナーがブロッキング状態であることを示します(イベントを生成したスレッドと同時に実行されます)。

'Nは、リスナーがブロッキング状態でないことを示します(別のスレッドで実行されます)。

48 プロキシ・アセット: サード・パーティ・コンテンツ・ソースの統合

この章では、プロキシ・アセット・タイプ・フレームワークを使用して、WebCenter Sitesで配信したサイトに外部Webコンテンツを統合する方法について説明します。

この章には次の項が含まれます。

- 第48.1項「概要」

- 第48.2項「ユーザー・インタフェースのカスタマイズ」

- 第48.3項「WebCenter Sites Contributorインタフェースへの外部コンテンツの統合」

- 第48.4項「Webページへのプロキシ・アセットの埋込み」

48.1 概要

原則

プロキシ・アセットとは、リモートの場所に保管され、その場所で管理されているコンテンツを表します。これについては、図48-1を参照してください。

図48-1 プロキシ・アセットのアーキテクチャ

このアーキテクチャの内容は、次のとおりです。

- サード・パーティのコンテンツ・リポジトリは、パブリックの読取りAPIを通じて、編集用インスタンスと配信インスタンスの両方からアクセスできると想定されています。

- Contributorインタフェースは、外部コンテンツをUIに表示するために、サード・パーティ・リポジトリにアクセスするようにカスタマイズされています。

- プロキシ・アセットは、UIにレンダリングされる外部コンテンツごとに実行時に作成されます。プロキシ・アセットには、メタデータは格納されません。このメタデータは、サード・パーティのサービスが提供するパブリックの読取りAPIを通じてアクセスできると想定されています。

- ライブ・インスタンスでは、プロキシ・アセット用に作成されたテンプレートで同一のリポジトリとAPIにアクセスして、ライブ・サイトに外部コンテンツをレンダリングします。

注意:

プロキシ・アセットは、使用されるもののみがSitesデータベースに永久的に格納されます。たとえば、検索結果のレンダリング中に作成されるプロキシ・アセットは、その後、専用のクリーニング・イベントで消去されます。

Contributorインタフェース

WebCenter Sitesデータベースに新しいプロキシ・アセット・タイプを登録した後で、開発者は、適切なUIカスタマイズを提供して、コントリビュータが外部コンテンツとの対話を始められるようにする必要があります。

実装するUIカスタマイズの特性は、コントリビュータに固有の要件に応じて異なります。たとえば、Contributorインタフェースの検索機能は、多くの場合、外部リポジトリに固有の検索サービスにフックされることになります。

これが行われていて、外部コンテンツがプロキシ・アセットの形式でContributorインタフェースに表示されていると、それらのアセットは標準アセットとほとんど同じように機能します。つまり、コントリビュータは、次の操作を実行できるようになります。

- 外部コンテンツ・リポジトリの検索(同じアセット検索タブを使用し、結果をドッキングまたはドッキング解除されたリスト表示またはサムネイル表示に示します)

- 検索またはツリーからのドラッグ・アンド・ドロップの使用

- 外部コンテンツの別のアセットへの関連付け(フォーム・ビューまたはWebビュー)

- 外部コンテンツのプレビュー(WebCenter Sitesのテンプレートを使用)

- ブックマーク、タグのワークフローでの設定、承認およびパブリッシュ

デフォルトの調査画面は、すべてのプロキシ・タイプに使用できます。

注意:

次の制限が適用されます。

- 外部コンテンツのライフサイクルは、サード・パーティのUIで全体的に管理することを想定しています。つまり、WebCenter Sitesには、外部リポジトリへの読取りアクセスのみが必要になります。そのため、編集やバージョニングなどのUIアクションは、すべてのプロキシ・アセットタイプに対してデフォルトで無効化されています。

- プロキシ・アセットには、関連アセットまたはサブタイプを含めることができません。

- 外部コンテンツ・リポジトリは、コントリビューションと配信の両方のWebCenter Sitesインスタンスからアクセスできるようにする必要があります。

48.2 ユーザー・インタフェースのカスタマイズ

WebCenter Sitesの使用感を向上するために、ユーザー・インタフェースは様々な方法でカスタマイズできます。この項では、サード・パーティ・ソフトウェアと同期するように、UI部分をカスタマイズする方法の詳細について説明します。

この項の内容は、次のとおりです。

- 第48.2.1項「検索スタート・メニューのカスタマイズ」

- 第48.2.2項「コンテンツ・ツリーのカスタマイズ」

48.2.1 検索スタート・メニューのカスタマイズ

WebCenter SitesのUIでは、ユーザーは、図48-2に示す検索スタート・メニューを選択して、特定のアセット・タイプに限定した検索を実行します。

図48-2 「検索タイプ」スタート・メニューの選択

特定のアセット・タイプに応じて検索をカスタマイズするには、次のエレメントを作成して、コントローラ・エレメントUI/Data/Search/Searchをオーバーライドします。

CustomElements/<AssetType>/UI/Data/Search/SearchAction
CustomElements/<AssetType>/UI/Data/Search/SearchJson

コントローラ・エレメントと、エレメントのオーバーライドの詳細は、第III部「Contributorインタフェースのカスタマイズ」を参照してください。

UI/Data/Search/Searchは、検索コードを実行し、グリッド・ウィジェット(ドッキングまたはドッキング解除された、リスト表示またはサムネイル表示)での利用に適したJSONデータを生成します。

このJSONデータは、有効なdojoデータストアにする必要があります。第48.3.4項「検索のカスタマイズ」、第48.2.2項「コンテンツ・ツリーのカスタマイズ」に、実際の実装例を示しています。

48.2.2 コンテンツ・ツリーのカスタマイズ

コンテンツ・ツリーは、新規または既存のツリー・タブに含めるカスタムのツリー・セクションを定義することでカスタマイズできます。カスタム・ツリー・タブのセクションの詳細は、『WebCenter Sites管理者ガイド』を参照してください。

カスタム・ツリー・タブのセクションは、なんらかのレンダリング・ロジック(最終的にはツリー・ウィジェットで使用される)に基づいてデータを生成するJSPエレメントを参照します。ツリー・データは、次のユーティリティ・エレメントを使用して生成されます。

- OpenMarket/Gator/UIFramework/BuildTreeNodeId: ツリー・ノードIDを生成します

- OpenMarket/Gator/UIFramework/BuildTreeNode: 適切に書式設定されたツリー・ノード・データを生成します

次の例では、ツリー・ノードがアセットを表しているかどうかに応じたツリー・ノードの作成方法を示しています(アセット・ノードと非定型ノードの比較)。詳細は、第34章「WebCenter Sitesの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 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>

48.3 WebCenter Sites Contributorインタフェースへの外部コンテンツの統合

コントリビュータが外部コンテンツを使用して作業できるようにするには、開発者が、それに必要なUI統合コードを実装しておく必要があります。

この項では、事例を示すためにダミーのコンテンツ・リポジトリを使用して、次の項目を統合するための手順について説明します。

- 検索: 標準のSites検索のかわりに、リポジトリ検索サービスを使用します

- コンテンツ・ツリー: カスタム・コンテンツ・ツリーで、コントリビュータがリポジトリのコンテンツを参照できるようにします

この項の内容は、次のとおりです。

- 第48.3.1項「事例: ダミー・リポジトリ」

- 第48.3.2項「新しいプロキシ・アセット・タイプの登録」

- 第48.3.3項「UI統合コードの実装」

- 第48.3.4項「検索のカスタマイズ」

- 第48.3.5項「カスタム・ツリーの実装」

48.3.1 事例: ダミー・リポジトリ

サンプル・データの設定

WebCenter Sites Webアプリケーションに直接デプロイされている静的なJSONファイルのセットを使用して、ダミーのコンテンツ・リポジトリをエミュレートします。ダミーのコンテンツは、メディア・コンテンツ(イメージ)であると想定します。

これらのJSONファイルでは、次のサービスをシミュレートします。

- 特定の用語に対するリポジトリの検索(すべて、"ski"または"surfing"について検索すると、実際の結果が返されます): http://localhost:7001/sites/samples/search/<searchterm>.json

- すべてのコンテンツ・カテゴリの取得("Ski"および"Surfing"): http://localhost:7001/sites/samples/browse/categories.json

- 特定のカテゴリに対するすべてのダミー・コンテンツの取得: http://localhost:7001/sites/samples/browse/<category>.json

- 特定のコンテンツIDに対するメタデータの取得: http://localhost:7001/sites/samples/content/<id>.json

たとえば、/samples/search/ski.jsonは、次のサンプル・コンテンツを返します。

{
"items": [
{
"id": "1001",
"title": "Yellow Skier",
"foo": "bar1",
"lastModified": "1354735336444",
"thumbnail": "samples/images/image7_thumbnail.png"
},
{
"id": "1002",
"title": "Female Skier",
"foo": "bar2",
"lastModified": "1354735336444",
"thumbnail": "samples/images/image8_thumbnail.png"
},
{
"id": "1003",
"title": "Ski Jump",
"foo": "bar3",
"lastModified": "1354735336444",
"thumbnail": "samples/images/image9_thumbnail.png"
}
]
}

このタイプのJSONデータを利用するJSPエレメントの例については、このガイドで後述します。

注意:

サンプル・コードは、/misc/Samples/フォルダ内に格納されています。このフォルダは、WebCenter Sitesに配置されています。プロキシ・アセットに固有のサンプル・コードは、/misc/Samples/SampleProxy/proxy_sample.zip内にあります。

ダミー・リポジトリからのデータの取得

コードの重複を避けるために、外部コンテンツ・ソースの問合せに必要なロジックは、Dummy/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"%>
<%@ page import="com.sun.jersey.api.client.*" %>
<%@ page import="com.sun.jersey.api.client.config.*" %>
<%@ page import="org.codehaus.jettison.json.*"%>
<cs:ftcs>
<%
//
// Gets data from dummy repository
// This element expects an ICS variable "serviceURL"
//
Client client = Client.create();
//
// Host, port and webapp prefix are hardcoded for simplicity, modify as
// appropriate.
// In a real-world scenario, the base service URL would probably be stored in
// a configuration file.
//
WebResource res = client.resource("http://localhost:7001/sites/samples" +
ics.GetVar("serviceURL"));
ClientResponse resp = res.accept("application/json").get(ClientResponse.class);
JSONArray list;
if (resp.getStatus() != 200) {
list = new JSONArray(); // empty array
}
else {
JSONObject json = new JSONObject(resp.getEntity(String.class));
list = json.getJSONArray("items");
}

// store the object in the ICS scope
ics.SetObj("items", list);
%>
</cs:ftcs>

48.3.2 新しいプロキシ・アセット・タイプの登録

WebCenter Sitesリポジトリで、この例でのダミー・コンテンツを表すには、新しいプロキシ・アセット・タイプを定義する必要があります。

プロキシ・アセット・タイプを作成するには、次の手順を実行します。

1. 「管理」タブで、「プロキシ・アセット・マネージャ」を開きます。「新規追加」をダブルクリックします。
「新規プロキシ・アセット・タイプの追加」ページが表示されます。

図48-3 「新規プロキシ・アセット・タイプの追加」ページ

2. 「名前」フィールドに、プロキシ・アセット・タイプの名前を入力します。同様に、「説明」フィールドに説明を追加して、「複数形」フィールドに名前の複数形を入力します。

注意:

Contributorインタフェースでは、プロキシ・アセットを作成または編集できません。そのため、この手順では、「検索」スタート・メニューのみを有効化する必要があります。

この例では(さらに、このドキュメントの後続部分で使用するために)、「名前」フィールドにDummy、「説明」フィールドにDummy、「複数形」フィールドにDummiesと入力します。

3. 「保存」をクリックします。

注意:

「プロキシ・アセット・メーカー」は、新しいアセット・タイプを登録して、それと同じ名前で単一の表を作成します。プロキシ・アセット表は、標準アセット・メタデータのサブセットのみを保持し、唯一の固有列externalidを定義します。このフィールドは、外部リポジトリに含まれる外部コンテンツの識別子を保管するためのものです。

48.3.3 UI統合コードの実装

アセットは、Contributorインタフェースの様々な場所に表示されます。たとえば、次のような場所が該当します。

- アセット・フォーム(アセット参照を含むフィールド)

- 検索結果

- コンテンツ・ツリー・パネル

それぞれの場合で、実際の統合コードは、要件と利用可能なカスタマイズ・フックに応じて様々に異なります。ただし、どの場合でも、「Contributorインタフェースに表示される外部コンテンツは、すべてプロキシ・アセットとして登録されている必要がある」という原則に従う必要があります。

実際には、外部コンテンツ・ソース内のコンテンツ識別子をexternalidフィールドで参照する、プロキシ・アセットを作成(または再使用)するということです。これは、通常のAsset APIのクラスとメソッドを使用することで実現できます。ただし、これを簡単にするために、プロキシJSPタグ・ライブラリが用意されています。

これには、次に示すユーティリティ・タグが含まれています。このタグは、特定の外部コンテンツをプロキシ・アセット・タイプとして登録するためのものです。

- <proxy:register />

さらに、データ・グリッド・ウィジェット(検索など)のJSONデータストアを生成するためのユーティリティ・タグも含まれています。これらのタグは、次のとおりです。

- <proxy:createstore />: 新しいストアを初期化します

- <proxy:addstoreitem />: アイテムを特定のストアに追加します

- <proxy:tojson />: ストアをJSONにシリアライズします

詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。また、コード例は、第48.3.4項「検索のカスタマイズ」を参照してください。

48.3.4 検索のカスタマイズ

第48.2.1項「検索スタート・メニューのカスタマイズ」で説明したように、Dummyアセット・タイプのコントローラ・エレメントUI/Data/Search/Searchをオーバーライドするために、次のエレメントを作成します。

CustomElements/Dummy/UI/Data/Search/SearchAction
CustomElements/Dummy/UI/Data/Search/SearchJson

図48-4 Dummyアセットを表示する検索ドロップダウン

図に示すように、検索ドロップダウンにDummyが表示されます。Dummyを選択すると(このプロキシ・アセット・タイプの名前はすでに作成されていることを意味します)、Luceneベースの検索ではなく、カスタムの検索コードが実行されます。

完全なカスタム検索を実装するために、このセクションの残りのトピックを完了してください。

この項の内容は、次のとおりです。

- 第48.3.4.1項「提供済のサード・パーティAPIを使用した検索結果の取得」

- 第48.3.4.2項「検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集」

- 第48.3.4.3項「グリッド・ウィジェット用のデータ・ストアの作成」

- 第48.3.4.4項「カスタム検索のテスト」

- 第48.3.4.5項「追加のカスタマイズ」

48.3.4.1 提供済のサード・パーティAPIを使用した検索結果の取得

CustomElements/Dummy/UI/Data/Search/SearchActionでは、第48.3.1項「事例: ダミー・リポジトリ」で作成したエレメントを使用して、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 dummy 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="Dummy/GetData" />
<%
JSONArray list = (JSONArray)ics.GetObj("items");

//
// ...to be continued in the next section
//
%>

</cs:ftcs>

この時点で、listには、外部コンテンツ・ソースから取得したJSONデータが格納されています。

48.3.4.2 検索結果のプロキシ・アセットへの変換、受信検索結果のフィルタ処理、外部コンテンツの登録、および検索グリッド・ウィジェット用のデータ収集

この手順では、一連の段階を通じてコードを作成します。

最初に、新しいデータ・ストアを作成します。

<proxy:createstore store="<storeName>" />

この<storeName>は、データ・ストアを指定する任意の文字列です。

その次に、受信外部コンテンツ・アセットごとに、現在のアセットをプロキシ・アセットとして登録します。

<proxy:register
externalid="<external_content_identifier>"
type="<proxy_asset_type>"
name="<proxy_asset_name>"
varname="<variable_name>" />

ここで:

- <external_content_identifier>は、サード・パーティ・リポジトリに含まれる現在の外部コンテンツ・アイテムの識別子です。この例のダミー・リポジトリの場合、この識別子は受信JSONデータのidフィールドで返されます。

- <proxy_asset_type>は、プロキシ・アセット・タイプの名前です。この例では、"Dummy"になります。

- <proxy_asset_name>は、Contributorインタフェース全体で名前として使用される、判読可能な文字列です。この例では、受信JSONデータのtitleフィールドで返されます。

- <variable_name>は、WebCenter Sitesの変数名です。この変数には、現在の外部コンテンツ・アイテムに対応するプロキシ・アセットのIDが格納されます。

その次に、受信登録済プロキシ・アセットごとに、アセットをデータ・ストアに追加します。

<proxy:addstoreitem
store="<storeName>"
id="<proxy_asset_id>"
type="<proxy_asset_type>" />

ここで:

- <storeName>は、<proxy:createstore />で定義したデータ・ストアです。

- <id>は、プロキシ・アセットの識別子です。

- <type>は、プロキシ・アセット・タイプです。

次に、Dummyプロキシ・アセットタイプの完全なコードを示します。

<%@ 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 dummy 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="Dummy/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="Dummy"
name='<%=item.getString("title") %>'
varname="internalid" />

<%-- Add the proxy asset to the datastore --%>
<proxy:addstoreitem store="assets"
id='<%=ics.GetVar("internalid") %>'
type="Dummy" />
<%
}
// put store name in request scope
request.setAttribute("store", "assets");
request.setAttribute("total", Integer.valueOf(list.length()));
%>
</cs:ftcs>

48.3.4.3 グリッド・ウィジェット用のデータ・ストアの作成

この手順では、UIウィジェットに送り返すJSONをレンダリングします。この手順は、CustomElements/Dummy/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>

48.3.4.4 カスタム検索のテスト

JSONのスクリプトを記述したら、検索機能が完全に動作することをテストします。検索をテストするには、次の手順を実行します。

1. Contributorインタフェースで、検索ボックスから「検索タイプ」としてDummyを選択します。「検索」アイコンをクリックします。

図48-5 Dummyアセットを表示する検索ドロップダウン

2. 「検索」タブが開き、関連データが表示されます。

図48-6 検索結果

3. サムネイル表示に切り替えると、次のようになります。

図48-7 サムネイル表示の検索結果

「検索」タブは、ドッキング・モードでも機能します。ツールチップには、デフォルト・データが記載されます。

図48-8 ドッキングされたパネル内の検索結果

48.3.4.5 追加のカスタマイズ

この項では、ここまでに説明した内容を超えて実装可能なカスタマイズについて説明します。これらのカスタマイズを使用していなくても、カスタム検索は実装できます。

サムネイルのレンダリング

この例では、Dummyリポジトリは、各コンテンツ・アイテムのサムネイル・イメージへのURLを返します。

サムネイルをレンダリングするために、Dummyリポジトリから送信されるサムネイルのURLを取得するように変更を加えます。これが行われるようにするには、サムネイル表示(ドッキングされている場合とドッキングされていない場合)のグリッドをカスタマイズする必要があります。つまり、次の構成エレメントをオーバーライドすることになります。

UI/Layout/CenterPane/Search/View/ThumbnailView
UI/Layout/CenterPane/Search/View/DockedThumbnailView

それぞれの構成ファイルは、次のように作成する必要があります。

CustomElements/Dummy/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig
CustomElements/Dummy/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>

これにより、Dummyのサムネイル表示用のformatter設定をオーバーライドしていることがわかります(その他のグローバル構成エレメントの設定は維持されます)。このformatterは、サムネイル・イメージを表示する検索結果ごとのデフォルト・ビューと、名前フィールド(調査リンク)をレンダリングします。

同様に、ドッキングされたサムネイル表示の設定は、CustomElements/Dummy/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/Dummy/UI/Layout/CenterPane/Search/View/ThumbnailViewConfig]" />
</cs:ftcs>

注意:

検索構成の詳細は、第III部「Contributorインタフェースのカスタマイズ」を参照してください。

エレメント名を囲む大カッコは、そこに指定されているエレメント名のカスタマイズ済バージョンを、ics:callelementタグで検索する必要がないことを示しています。

グリッド・コンテキスト・メニューの構成

アセット操作の一部は、プロキシ・アセットには適用されません。そのため、デフォルトのグリッド・コンテキスト・メニュー設定をオーバーライドする必要があります。エレメントUI/Config/GlobalHtmlをオーバーライドするために、MyConfigという名前の新しいエレメントをUI/Configに作成します。MyConfigの作成方法の詳細は、第65.5.3項「コンテキスト・メニューのカスタマイズ」を参照してください。

このようにすることで、グローバル設定はオーバーライドした設定にマージされないようになります。

フィールドのソート

外部コンテンツ・ソースのAPI機能によっては、一部のフィールドに対するソート機能が使用できないことがあります。この場合は、デフォルトのコンテキスト・メニュー構成ファイルをオーバーライドすることで、ソート・ドロップダウン・メニューをカスタマイズできます。これを処理するには、次の構成ファイルを作成します。

CustomElements/Dummy/UI/Layout/CenterPane/Search/View/SearchTopBarConfig

さらに、次のXMLコードを使用します(ここでは、名前によるソートのみが使用できると仮定しています)。

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
<%@ taglib prefix="xlat" uri="futuretense_cs/xlat.tld"%>
<cs:ftcs>
<sortconfig>
<sortfields>
<sortfield id="name_asc">
<fieldname>name</fieldname>
<displayname>
<xlat:stream key="UI/UC1/Layout/NameSort1" escape="true"/>
</displayname>
<sortorder>ascending</sortorder>
</sortfield>
<sortfield id="name_desc">
<fieldname>name</fieldname>
<displayname>
<xlat:stream key="UI/UC1/Layout/NameSort2" escape="true"/>
</displayname>
<sortorder>descending</sortorder>
</sortfield>
</sortfields>
</sortconfig>
</cs:ftcs>

SearchTopBarConfigエレメントとContextMenuConfigエレメントは、図48-9に示すように、どちらもエレメントのresdetails1 (またはresdetails2)フィールドにmerge=falseを設定しておく必要があります。

図48-9 構成ファイルのエレメントの詳細値フィールド

48.3.5 カスタム・ツリーの実装

カスタム・ツリーを使用すると、図48-10に示すように、ユーザーはカテゴリごとに簡単に外部コンテンツを参照できるようになります。

図48-10 カスタム・ツリー

ツリーをレンダリングするために、次の2つのエレメントを作成します。

- Dummy/Tree/Root: ツリーのルート・ノードをレンダリングします。これらのノードは、コンテンツの各カテゴリになります。

- Dummy/Tree/Load: 特定のカテゴリに属するコンテンツをすべてレンダリングします。

カスタム・ツリーを実装するには、最初にカスタム・ツリー・タブを登録してから、カスタム・ツリーのコードを実装する必要があります。

この項の内容は、次のとおりです。

- 第48.3.5.1項「カスタム・ツリー・タブの登録」

- 第48.3.5.2項「ツリーのコードの実装」

48.3.5.1 カスタム・ツリー・タブの登録

カスタム・ツリー・タブは、「新規ツリー・タブの追加」ページで定義します。この例で作成するタブでは、Proxy Assetsという新しいコンテンツ・ツリーを作成します。このツリーには、Dummy/Tree/Rootを参照する単一のカスタム・セクション(Dummy)を含めます。

この例のカスタム・ツリー・タブを登録するには、次の手順を実行します。

1. Adminインタフェースで、「管理」タブを選択して、「ツリー」をダブルクリックします。
「ツリー・タブ」ページが開きます。

2. 「ツリー・タブ」ページの下側にある、「新規ツリー・タブの追加」をクリックします。
「新規ツリー・タブの追加」ページが開きます(図48-11)。

図48-11 「新規ツリー・タブの追加」ページ

3. 必要に応じて、各フィールドに入力します。この例では、次のようにフィールドに入力します。

- タイトル: タブのタイトルとしてProxy Assetsを入力します。

- サイト: リストから「プロキシ」を選択します。

- 必須ロール: リストから「任意」を選択します。

- タブ・コンテンツ: 「Dummy」を選択してから、「選択したアイテムの追加」をクリックして、その項目を「選択済」列に移動します。「選択済」列の項目は、「Dummy」のみにする必要があります。

- セクション名: フィールドに、Dummyと入力します。

- エレメント名: フィールドに、Dummy/Tree/Rootと入力します。

4. 各フィールドに適切な値を入力したら、「保存」をクリックしてアセットを保存します。

48.3.5.2 ツリーのコードの実装

Dummy/Tree/Rootでは、外部リポジトリを問い合せてツリーのルート・ノード(この例では、カテゴリのリスト)を取得します。その後で、ツリー・ノードのデータがカテゴリごとに生成されます。

<%@ 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 dummy repository --%>
<ics:setvar name="serviceURL" value="/browse/categories.json" />
<ics:callelement element="Dummy/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' i.e. 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
// Dummy/Tree/Load
//
%>
<satellite:link assembler="query"
pagename="OpenMarket/Gator/UIFramework/LoadTab"
outstring="LoadURL">
<satellite:argument name="populate" value="Dummy/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>

このコードは、次のツリーを生成します。

図48-12 生成されたカスタム・ツリー

注意:

OpenMarket/Gator/UIFramework/BuildTreeNodeIDエレメントとOpenMarket/Gator/UIFramework/BuildTreeNodeエレメントは、どちらもICSスコープ内の変数を利用します。<ics:callelement />タグはグローバル・スコープを持つため、<ics:removevar />を使用して、特定の変数をICSスコープから明示的に削除(永久的または一時的)することが必要になる場合があります。

Dummy/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="Dummy/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="Dummy"
name='<%=item.getString("title") %>'
varname="internalid" />

<ics:callelement element="OpenMarket/Gator/UIFramework/BuildTreeNodeID">
<ics:argument name="AssetType" value="Dummy" />
<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>

その後、各カテゴリを参照できます。図48-13に示すように、各カテゴリを参照できるようになります。

図48-13 カスタム・ツリーのオブジェクトの参照

ノードをダブルクリックすると、そのノードについてのデフォルトのプロキシ・アセット調査ページが開きます。

48.4 Webページへのプロキシ・アセットの埋込み

この項の内容は、次のとおりです。

- 第48.4.1項「プロキシ・アセット用テンプレートの作成」

- 第48.4.2項「プロキシ・アセットのスロットでの使用」

- 第48.4.3項「プロキシ・アセットのキャッシング」

48.4.1 プロキシ・アセット用テンプレートの作成

プロキシ・アセット用のテンプレートは、その他のアセット・タイプのテンプレートと同じように定義できます。ここまでの例に使用してきたDummyアセットは、図48-14に示す方法でテンプレートを定義できます。

図48-14 定義済のSummaryテンプレート

すべてのテンプレートに対して、「使用」には、「エレメントはレイアウトとして使用されます。」がリスト表示されている必要があります。「エレメントはHTMLページ内で使用されます。」を選択していると、作成したテンプレートは、ページ・アセットの作成中に、ContributorのUIに表示されなくなります。

プロキシ・アセット用テンプレートの作成には、通常、2つの個別のアクションが必要になります。まず、(内部)アセットIDを指定して、外部IDを取得します。その次に、サード・パーティのリポジトリAPIを使用して、コンテンツ・メタデータを取得します。

Dummyアセットに固有の例として、次のコードを実装します。

<%@ 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"%>
<%@ page import="com.sun.jersey.api.client.*"%>
<%@ page import="com.sun.jersey.api.client.config.*"%>
<%@ page import="org.codehaus.jettison.json.*"%>
<cs:ftcs>
<render:logdep cid='<%=ics.GetVar("tid")%>' c="Template"/>

<%-- 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 = Client.create();
WebResource res = client.resource("http://localhost:7001/sites/samples/content/" +
ics.GetVar("externalid") + ".json");
ClientResponse resp = res.accept("application/json").get(ClientResponse.class);
JSONObject data = new JSONObject(resp.getEntity(String.class));
%>
<%-- finally render content metadata --%>
<h4><%=data.getString("title") %></h4>
<p><%=data.getString("foo") %></p>
<img src="<%=data.getString("image") %>" alt="<%=data.getString("title") %>" />
</cs:ftcs>

48.4.2 プロキシ・アセットのスロットでの使用

プロキシ・アセットは、標準アセットに適用されるものとまったく同じタグと原則を使用して、ページ内に埋込みできます。これについては、図48-15を参照してください。

図48-15 埋込みプロキシ・アセットの例

次に示すコード例では、ページ・アセットに、Dummyアセットを受け入れるdummyAttributeというページ属性があると仮定しています。

<%@ 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>Proxy test page</title>
</head>
<body>
<assetset:setasset name="page" id='<%=ics.GetVar("cid") %>'
type='<%=ics.GetVar("c") %>' />
<assetset:getattributevalues attribute="dummyAttribute" listvarname="dummy"
name="page" typename="PageAttribute" />
<ics:listget listname="dummy" fieldname="value" output="id" />
<h3>Proxy Test Page</h3>
<insite:calltemplate field="dummyAttribute" c='Dummy'
cid='<%=ics.GetVar("id") %>' tname="Summary" />
</body>
</html>
</cs:ftcs>

48.4.3 プロキシ・アセットのキャッシング

レンダリング済のコンテンツは独立したリポジトリで保管および管理されるため、コンテンツが変更されたときに(コンテンツが変更された後でも)、その変更をWebCenter Sitesが認識する方法がありません。

このため、プロキシ・アセットをレンダリングするテンプレート(第48.4.1項「プロキシ・アセット用テンプレートの作成」で定義したSummaryテンプレートなど)には、期間が限られたキャッシュ有効期限を設定するようにしてください。

49 カスタマイズ・フックのリアルタイム・パブリッシュ

この章では、リアルタイム・パブリッシュの概要について説明します。また、独自のトランスポータの作成方法、実装の詳細、ヘルパー・メソッド、トランスポータの実装例、完全なコードのリスト、特異な状況のシナリオ、および管理インスタンスでのアセット・パブリッシュ・イベントのインターセプトについて説明します。

この章には次の項が含まれます。

- 第49.1項「リアルタイム・パブリッシュの概要」

- 第49.2項「カスタム・トランスポータの作成」

49.1 リアルタイム・パブリッシュの概要

リアルタイム・パブリッシュとは、いくつかのジョブで構成されるパイプラインのことです。一部のジョブは管理インスタンスで実行され、その他のジョブはターゲット・インスタンスで実行されます。次に、これらについて簡単に説明します。

- Gatherer: パブリッシュ可能なアセットのリストを作成して、そのリストを追加のリソース(アセット・タイプ、表の行)で装飾します。これらを合せて、パブリッシュするデータの正規セットを構成します。

- Packager: Packagerは、Gathererで作成したリソースのリストを指定すると、各リソースのシリアル化されたレンディションを作成して、そのレンディションをローカルのfw_PubDataStore表に保存します。

- Transport: Packagerで作成したfw_PubDataStoreに含まれるシリアル化されたデータを受け取り、そのデータをターゲット側のfw_PubDataStore表にコピーします。

- Unpacker: ターゲット側のfw_PubDataStore表に含まれるシリアライズ化されたデータを受け取り、そのデータをデシリアライズしてターゲット・データベースに保存します。

- CacheUpdater: CacheUpdaterは、Unpackerで正常に保存されたアセットのリストを指定すると、ページ・キャッシュの関連部分をフラッシュして、必要な場合は再生成します。

リアルタイム・パブリッシュは、非同期メッセージングを使用して、各ジョブのステータスを追跡します。メッセージング・フレームワークの詳細を理解する必要はありませんが、ターゲット・システムとの通信がトランスポータによって円滑化されることは理解しておく必要があります。これには、アセットが保存されていることを管理システムに通知するために、Unpackerが発行するメッセージも含まれます。このメッセージにより、そのアセットにパブリッシュ済のマークを付けるように管理ロジックに指示します。

49.2 カスタム・トランスポータの作成

トランスポータには、次に示すいくつかのカスタマイズ・オプションが用意されています。

- HTTPに基づくOOTB (デフォルトまたは設定済)トラスポートを、別のプロトコルを使用するトランスポートに置き換える。

- 同一のパブリッシュ・セッションで複数のターゲットにパブリッシュする。

この項の内容は、次のとおりです。

- 第49.2.1項「独自のトランスポータの作成方法」

- 第49.2.2項「実装の詳細」

- 第49.2.3項「ヘルパー・メソッド」

- 第49.2.4項「トランスポータの実装例」

- 第49.2.5項「完全なコードのリスト」

- 第49.2.6項「境界状況のシナリオ」

- 第49.2.7項「管理インスタンスでのアセット・パブリッシュ・イベントのインターセプト」

- 第49.2.8項「最終工程」

49.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">

49.2.2 実装の詳細

AbstractTransporterのメソッドをオーバーライドするときには、次の点に注意してください。

- ping()には、ターゲットが稼働しているか、停止しているかを確認するロジックを含めます。最もわかりやすい使用法は、パブリッシュ・コンソールに緑色/赤色の診断インジケータを点灯させることです。パブリッシュ・セッションの起動には、pingの成功が必ずしも必要なわけではありませんが、接続の問題を診断するにはpingが便利なツールになります。
ターゲットへの接続にhttpを使用している場合は、デフォルトの実装を使用できます。このとき、オーバーライドや独自の実装は必要ありません。

- sendBatch()は、リモートfw_PubDataStoreにデータをアップロードする役割を果たします。これは、ローカルのfw_PubDataStoreから、IList形式のデータの小さなバッチで複数回呼び出されます。バッチ処理によりメモリーの使用量を抑えられます。バッチ処理は、気付かないうちに実行されています。

- remoteExecute()は、リモート・システムとの通信の役割を果たします。通信は双方向で行われ、管理側はリモートのジョブと取消しのリクエストをディスパッチするコマンドを送信し、ターゲット側はステータスを示すメッセージを送り返します。これらのメッセージの内容は、remoteExecuteには重要ではありません。このメソッドに必要な動作は、該当するリクエストを送信して応答を返すことのみです。

- listTransports()は、ターゲットが複数ある場合に、基になるトランスポートのリストになります。ターゲットが1つのみの場合、このメソッドは、現在のトランスポートのtoString()レンディションを返します。

- toString()は、このトランスポートのわかりやすい記述子です。たとえば、一般的な値は、http://mytarget:8081/cs/です。ただし、targetDataCenter-Virginia、serverOn8080などの別の文字列も受け入れられます。

49.2.3 ヘルパー・メソッド

AbstractTransporterには、いくつかのヘルパー・メソッドがあります。

- protected void writeLog(String msg)は、パブリッシュ・ログにメッセージを書き込みます

- protected AbstractTransporter getStandardTransporterInstance()は、標準のHTTPベース・トランスポータの新しいインスタンスを取得します。これは、複数のターゲットにトランスポートを実装する際に役立ちます。

- protected String getParam(String param)は、パブリッシュ・コンソールで構成された、パブリッシュ・パラメータの値を取得します。

49.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">

49.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();
}
}

49.2.6 境界状況のシナリオ

第49.2.5項「完全なコードのリスト」に示した例は、すべてのターゲットが実行しているという最適な状況では動作しますが、あるターゲットが短時間または長時間停止しているときもあります。あるターゲットにのみパブリッシュしているときに、アセットにパブリッシュ済としてのマークが付けられると、停止したターゲットは同期されなくなります。このようなシナリオには、次に示す方法で対応できます。

- ターゲットが短時間停止している場合は、アセットにパブリッシュ済のマークを付けないようにして、実行中のターゲットにはパブリッシュを続けます。別のターゲットが再起動されたときには、その時点より前のすべてのアセットがパブリッシュ用のキューに入れられた状態になります。これらのアセットは、最初のターゲットにも重複してパブリッシュされることになりますが、短時間の場合、このオーバーヘッドは無視できます。

- ターゲットが長時間停止したままになる場合は、そのターゲットを宛先構成のターゲットのリストからから削除することが最善策になるといえます(この例では、パブリッシュ構成の「宛先アドレス」から2番目のターゲットを削除します)。このようにすると、アクティブなターゲットが1つしかない場合でも、アセットはパブリッシュ済としてマークされ続けます。2番目のターゲットが再起動されたときには、最初にデータベースとファイル・システムの同期を実行して、その後で2番目のターゲットを宛先アドレスのリストに戻します。

49.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>

49.2.8 最終工程

複数の宛先にパブリッシュする場合は、それぞれの宛先ごとの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>

50 クローラ構成ファイルのコーディング

この章では、BaseConfiguratorクラスに関する情報と、このクラスのメソッドとインタフェースを実装してクローラのサイト・キャプチャ・プロセスを制御する方法について説明します。また、FirstSiteIIクローラのSite Captureインストールに使用できるサンプル・コードについても説明します。

この章は、次の項が含まれています。

- 第50.1項「クローラ制御の概要」

- 第50.2項「BaseConfiguratorのメソッド」

- 第50.3項「クローラのカスタマイズ・メソッド」

- 第50.4項「getSocketTimeout」

- 第50.5項「getPostExecutionCommand」

- 第50.6項「getNumWorkers」

- 第50.7項「getUserAgent」

- 第50.8項「createResourceRewriter」

- 第50.9項「createMailer」

- 第50.10項「getProxyHost」

- 第50.11項「getProxyCredentials」

- 第50.12項「インタフェース」

- 第50.13項「メソッドとインタフェースの概要」

50.1 クローラ制御の概要

クローラを制御するには、少なくとも開始URIとリンク抽出ロジックを使用してCrawlerConfigurator.groovyファイルをコーディングする必要があります。どちらの情報もgetStartUri()およびcreateLinkExtractor()メソッドを通じて提供されます。必要に応じてコードを追加して、たとえば、クロールするリンク数、クロールの深さ、クロール後イベントの呼出し(ダウンロードされたファイルのWebサーバーのドキュメント・ベースへの静的コピーなど)を指定できます。

使用するメソッドとインタフェースは、BaseConfiguratorクラスに用意されています。デフォルトの実装は、ターゲット・サイトの構造と収集するデータに適した方法でクロール・プロセスをカスタマイズおよび制御するためにオーバーライドできます。

この章では、最初にBaseConfiguratorのメソッド(第50.2項「BaseConfiguratorのメソッド」を参照)と単純なCrawlerConfigurator.groovyファイル(第50.2.2項「createLinkExtractor」を参照)を取り上げ、必要なメソッドの使用方法を示します。さらに、クローラのカスタマイズ方法について説明した後、Site CaptureのJavaインタフェース(デフォルト実装とカスタム実装を含む)について説明します。

50.2 BaseConfiguratorのメソッド

CrawlerConfigurator.groovyファイルには、CrawlerConfiguratorクラスのコードが含まれています。このクラスでは、クローラのデフォルト実装を提供する抽象クラスのBaseConfiguratorを拡張する必要があります。BaseConfiguratorクラスのメソッドとインタフェースについては、表50-1に一覧を示し、それに続く各項で説明しています。基本的なサンプルのCrawlerConfigurator.groovyファイルについては、第50.2.2項「createLinkExtractor」を参照してください。

表50-1 BaseConfiguratorクラスのメソッド

メソッド・タイプ

メソッド

メモ

必須

第50.2.1項「getStartUri」

なし

必須

第50.2.2項「createLinkExtractor」

第50.12.1項「LinkExtractor」インタフェースのファクトリ・メソッド。脚注 2

クローラのカスタマイズ

第50.3.1項「getMaxLinks」

なし

クローラのカスタマイズ

第50.3.2項「getMaxCrawlDepth」

なし

クローラのカスタマイズ

第50.3.3項「getConnectionTimeout」

なし

クローラのカスタマイズ

第50.4項「getSocketTimeout」

なし

クローラのカスタマイズ

第50.5項「getPostExecutionCommand」

なし

クローラのカスタマイズ

第50.6項「getNumWorkers」

なし

クローラのカスタマイズ

第50.7項「getUserAgent」

なし

クローラのカスタマイズ

第50.8項「createResourceRewriter」

第50.12.2項「ResourceRewriter」インタフェースのファクトリ・メソッド。

脚注 1 一覧に示したインタフェースには、この章で説明するデフォルトの実装があります。

脚注2 Site Captureには、サンプルのリンク・エクストラクタとリソース・リライタがあります。どちらもFirstSiteIIサンプル・クローラによって使用されます。第50.12.1.3項「カスタム・リンク・エクストラクタの作成とデプロイ」および第50.12.2.3項「カスタムResourceRewriterの作成」を参照してください。

この項の内容は、次のとおりです。

BaseConfiguratorの2つの抽象メソッドは、CrawlerConfiguratorでオーバーライドする必要があります。該当するメソッドは、getStartUri()とcreateLinkExtractor()です。

- 第50.2.1項「getStartUri」

- 第50.2.2項「createLinkExtractor」

50.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.
}

50.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の詳細は、第50.12.1.2項「LinkExtractorのデフォルト実装の使用」を参照してください。

- LinkExtractorインタフェースの実装方法の詳細は、第50.12.1.3項「カスタム・リンク・エクストラクタの作成とデプロイ」を参照してください。

基本の構成ファイル

次に示す、簡単なCrawlerConfigurator.groovyファイルの例では、必須のメソッドgetStartUri()とcreateLinkExtractor()がオーバーライドされています。

注意:

次に示すサンプルでは、追加のメソッド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;
}

50.3 クローラのカスタマイズ・メソッド

BaseConfiguratorクラスには、必須のメソッド以外にも、デフォルト実装を備えたメソッドが含まれています。これらのメソッドをオーバーライドすると、ターゲット・サイトの構造と収集する必要のあるデータに適する方法でクロールのプロセスをカスタマイズできます。

この項の内容は、次のとおりです。

- 第50.3.1項「getMaxLinks」

- 第50.3.2項「getMaxCrawlDepth」

- 第50.3.3項「getConnectionTimeout」

50.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;
}

50.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;
}

50.3.3 getConnectionTimeout

このメソッドでは、ターゲット・サイトへの接続を確立するまでにクローラが待機する時間を決定します。指定した時間内に接続が確立されない場合、クローラは、そのリンクを無視して後続のリンクに進みます。

例

接続タイムアウトに50,000ミリ秒を設定するには:

/**
* default: 30000 ms
* @return Connection timeout in milliseconds.
*/
public int getConnectionTimeout()
{
return 50000; // in milliseconds
}

50.4 getSocketTimeout

このメソッドでは、クロール対象のリンクに対して、クローラが行ったリクエストのソケット・タイムアウトを制御します。

例

ソケット・タイムアウトに30,000ミリ秒を設定するには:

/**
* default: 20000 ms
* @return Socket timeout in milliseconds.
*/
public int getSocketTimeout()
{
return 30000; // in milliseconds
}

50.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";
}

50.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;
}

50.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 ";
}

50.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');
}

- デフォルト実装の詳細は、第50.12.2.2項「ResourceRewriterのデフォルト実装の使用」を参照してください。

- ResourceRewriterインタフェースの実装方法の詳細は、第50.12.2.3項「カスタムResourceRewriterの作成」を参照してください。

50.9 createMailer

このメソッドは、クロールの終了時に電子メールを送信するための実装を提供します。createMailerメソッドは、Mailerインタフェースのファクトリ・メソッドです。

- Site Captureには、静的またはアーカイブのキャプチャ・セッションが終了したときに、クローラ・レポートを電子メールで送信する、SMTP over TLSの実装が用意されています(クローラ・レポートは、report.txtファイルです。詳細は、『Oracle Fusion Middleware 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();
}

- デフォルト実装の詳細は、第50.12.3.2項「Mailerのデフォルト実装の使用」を参照してください。

- ResourceRewriterインタフェースの実装方法の詳細は、第50.12.3.3項「カスタムMailerの作成」を参照してください。

50.10 getProxyHost

このメソッドは、クロール先のサイトがプロキシ・サーバーの背後にある場合に、オーバーライドする必要があります。プロキシ・サーバーは、このメソッドで構成できます。

注意:

getProxyHostを使用するときには、getProxyCredentialsも使用します(第50.11項「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);
}

50.11 getProxyCredentials

このメソッドは、getProxyHostメソッドで構成されるプロキシ・サーバーの資格証明を挿入するために使用します(第50.10項「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
}

50.12 インタフェース

Site Captureに用意されている、デフォルト実装のあるインタフェースは、次のとおりです。

- 第50.12.1項「LinkExtractor」

- 第50.12.2項「ResourceRewriter」

- 第50.12.3項「Mailer」

50.12.1 LinkExtractor

リンク・エクストラクタは、クロール・セッションでSite Captureの巡回先にするリンクを指定するために使用します。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入されます。この実装は、クロール・セッションの一環としてダウンロードされたマークアップからリンクを抽出するために、クロール・セッション中にSite Captureフレームワークによってコールされます。

Site Captureには、LinkExtractorの実装が1つ用意されています。カスタムのリンク抽出ロジックを作成して、デプロイすることもできます。詳細は、次の各項を参照してください。

- 第50.12.1.1項「LinkExtractorインタフェース」

- 第50.12.1.2項「LinkExtractorのデフォルト実装の使用」

- 第50.12.1.3項「カスタム・リンク・エクストラクタの作成とデプロイ」

50.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);
}

50.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クラスの説明を参照してください。

50.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インタフェースについては、第50.12.1.1項「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");
}

50.12.2 ResourceRewriter

リソース・リライタは、クロール・セッション中にダウンロードしたマークアップ内のURLをリライトするために使用します。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入する必要があります。

次に示すようなユースケースで、リソース・リライタが必要になります。

- 動的サイトをクローリングして、静的コピーを作成する。たとえば、FirstSiteIIサンプル・サイトには、動的リンクが含まれています。FirstSiteIIを静的サイトに変換するには、ダウンロードしたマークアップ内のURLをリライトする必要があります。

- 絶対URLを相対URLに変換する。たとえば、http://www.example.com/abc.htmlのようなURLがマークアップに含まれている場合、クローラは、このURLからhttp://www.example.comを削除する必要があります。これにより、ダウンロードしたファイルが保存されているホストから、リソースを提供できるようになります。

Site Captureには、ResourceRewriterの実装が2つ用意されています。また、カスタムの実装を作成することもできます。詳細は、次の各項を参照してください。

- 第50.12.2.1項「ResourceRewriterインタフェース」

- 第50.12.2.2項「ResourceRewriterのデフォルト実装の使用」

- 第50.12.2.3項「カスタムResourceRewriterの作成」

50.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;

}

50.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)

50.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インタフェースが示されます。)
カスタム実装を示す擬似コードは、次のとおりです。

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");
}

50.12.3 Mailer

メーラーは、クロールの終了後に電子メールを送信するために使用します。この実装は、CrawlerConfigurator.groovyファイルを通じて挿入する必要があります。

Site Captureには、SMTPTlsMailerの実装が用意されています。これを使用して、SMTP-TLSメール・サーバーからクローラ・レポートを送信できます。また、Mailerインタフェースを実装して、SMTP-TLS以外のサーバー(認証なしのSMTP、POP3など)から電子メールを送信するためのカスタム・ロジックを提供できます。カスタム・ロジックでは、電子メールを、クローラ・レポート以外のオブジェクトとして指定できます。CrawlerConfigurator.groovyファイルでMailerが構成されていない場合は、デフォルトでNullMailerが挿入されます。詳細な情報は、次のトピックを参照してください:

- 第50.12.3.1項「Mailerインタフェース」

- 第50.12.3.2項「Mailerのデフォルト実装の使用」

- 第50.12.3.3項「カスタムMailerの作成」

50.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;
}

50.12.3.2 Mailerのデフォルト実装の使用

Site Captureには、SMTP-TLSサーバー・ベースの電子メールの実装が用意されています。この実装では、静的またはアーカイブのクロール・セッションが終了したときにクローラ・レポートを送信します(クローラ・レポートは、report.txtファイルです。詳細は、『Oracle Fusion Middleware 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());
}
}

50.12.3.3 カスタム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 Fusion Middleware WebCenter Sites管理者ガイド』を参照)を電子メールで送信します。ロジックをカスタマイズすることで、クローラ・レポート以外のオブジェクトを電子メール送信できるようになります。

50.13 メソッドとインタフェースの概要

この章で説明した、Site CaptureのBaseConfiguratorクラスに含まれるメソッドとインタフェースは、クローラのサイト・キャプチャ・プロセスを制御するためのものです。この項では、メソッドとインタフェース、およびそれらのデフォルト実装についての概要を示します。

この項の内容は、次のとおりです。

- 第50.13.1項「メソッド」

- 第50.13.2項「インタフェース」

50.13.1 メソッド

Site CaptureのBaseConfiguratorで使用されるメソッドの一覧は、次のとおりです。

- 第50.2.1項「getStartUri」

- 第50.2.2項「createLinkExtractor」

- 第50.3.1項「getMaxLinks」

- 第50.3.2項「getMaxCrawlDepth」

- 第50.3.3項「getConnectionTimeout」

- 第50.4項「getSocketTimeout」

- 第50.5項「getPostExecutionCommand」

- 第50.6項「getNumWorkers」

- 第50.7項「getUserAgent」

- 第50.8項「createResourceRewriter」

- 第50.9項「createMailer」

- 第50.10項「getProxyHost」

- 第50.11項「getProxyCredentials」

この一覧のファクトリ・メソッドは、次に示すインタフェースに含まれています。

- 第50.2.2項「createLinkExtractor」は、第50.12.1項「LinkExtractor」インタフェースに含まれています。

- 第50.8項「createResourceRewriter」は、第50.12.2項「ResourceRewriter」インタフェースに含まれています。

- 第50.9項「createMailer」は、第50.12.3項「Mailer」インタフェースに含まれています。

50.13.2 インタフェース

Site CaptureのBaseConfiguratorで使用されているインタフェースは、次のとおりです。

- 第50.12.1項「LinkExtractor」
デフォルト実装は、正規表現に基づいてリンクを抽出する、PatternLinkExtractorです。

また、Site Captureには、サンプルのリンク・エクストラクタ(およびサンプルのリソース・リライタ)があります。FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。ソース・コードは、フォルダ<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/srcから入手可能です。

カスタムのリンク・エクストラクタ・ロジックを作成して、デプロイできます。

- 第50.12.2項「ResourceRewriter」
デフォルト実装は、リンクのリライトを省略するNullResourceRewriterと、正規表現に基づいてURLをリライトするPatternResourceRewriterです。

Site Captureには、サンプルのリソース・リライタ(およびサンプルのリンク・エクストラクタ)があります。FirstSiteIIサンプル・クローラは、これらを使用して、WebCenter Sitesの動的なFirstSiteII Webサイトを静的サイトとしてダウンロードします。ソース・コードは、フォルダ<SC_INSTALL_DIR>/fw-site-capture/crawler/_sample/FirstSiteII/srcから入手可能です。

URLをリライトする独自のロジックを作成して、デプロイできます。

- 第50.12.3項「Mailer」
デフォルト実装は、クローラ・レポートをSMTP-TLSメール・サーバーから送信するSMTPTlsMailerです。これとは別のタイプのサーバーから別のタイプのオブジェクトを電子メールで送信するように、ロジックをカスタマイズできます。

第II部

Developer Toolsの使用

この部では、Oracle WebCenter Sites: Developer Toolsについて説明します。このツールキットは、Oracle WebCenter SitesとEclipse統合開発環境(IDE)を統合するために使用します。Developer Toolsキットを使用すると、開発者は、Eclipse IDEとバージョン・コントロール・システム(VCS)を使用して分散環境で作業できるようになります。

この部は、次の章で構成されています。

- 第51章「Oracle WebCenter Sites: Developer Toolsについて」

- 第52章「Developer Tools: インストールと構成」

- 第53章「Developer Tools: EclipseでのWebCenter Sites機能」

- 第54章「Developer Tools: JSPの開発」

- 第55章「Developer Tools: モバイルWebサイト用テンプレートの作成」

- 第56章「Developer Tools: 同期とデータ交換」

- 第57章「Developer Tools: ワークスペース」

- 第58章「Developer Tools: コマンドライン・ツール」

- 第59章「Developer Tools: バージョン・コントロール・システムとの統合」

- 第60章「Developer Tools: 開発チーム統合のユースケース」

- 第61章「Developer Tools: コマンドライン・ツールを使用した再利用可能モジュールの作成」

51 Oracle WebCenter Sites: Developer Toolsについて

この章では、Oracle WebCenter Sites: Developer Toolsを使用して、WebCenter Sitesのコンテンツ管理サイトを開発する方法の概要について説明します。

この章には次の項が含まれます。

- 第51.1項「Developer Toolsのアーキテクチャ」

- 第51.2項「IDE統合」

- 第51.3項「Developer Toolsワークスペース」

- 第51.4項「同期」

- 第51.5項「JSPの管理」

- 第51.6項「コマンドライン・ツール」

- 第51.7項「バージョン・コントロール・システムの使用」

- 第51.8項「次の手順」

51.1 Developer Toolsのアーキテクチャ

Oracle WebCenter Sitesを実行している任意のコンピュータで、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のサマリーは、図51-1と、この章の後続の項を参照してください。

図51-1 Developer Toolsプロセスのフロー

51.2 IDE統合

Eclipse統合を使用すると、開発者は次の作業を行えます。

- CSElementアセット、テンプレート・アセット、およびSiteEntryアセットと、SiteCatalogエントリおよびElementCatalogエントリの作成、編集、および削除

- タグの補完、構文の強調表示、デバッグなどのEclipseの標準機能を使用したJSPエレメントの開発

- アセット、アセット・タイプ、フレックス・ファミリ、サイト、ロール、ツリー・タブ、およびスタート・メニュー・アイテムのエクスポートとインポート

- 埋込みのプレビュー・ブラウザを使用した、Eclipse IDEでのWebCenter Sitesのページのプレビュー

- 動的にリフレッシュされるパネルでのWebCenter Sitesログ・ファイルの表示

- バージョン・コントロール・システムとの統合

注意:

Developer ToolsをEclipseと統合すると、EclipseにWebCenter SitesのAdminインタフェースとContributorインタフェースが埋め込まれるため、開発者は簡単にアクセスできるようになります。Adminインタフェースでの作業の詳細は、第I部「Oracle WebCenter Sitesの開発」を参照してください。Contributorインタフェースでの作業の詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

51.3 Developer Toolsワークスペース

Eclipseで管理するWebCenter Sitesのリソースは、メインDeveloper Toolsワークスペースと呼ばれるファイル・システム構造のファイルとして格納されます。この構造により、WebCenter Sitesのインスタンスでのリソースの管理および交換が簡単になります。メインDeveloper Toolsワークスペースは、Eclipseからアクセスできる唯一のワークスペースです。

注意:

カスタム・ワークスペースは必要に応じて作成できますが、ほとんどの分散環境では、メインDeveloper Toolsワークスペースのみで十分です。カスタム・ワークスペースは、Eclipseからはアクセスできません。カスタム・ワークスペースの作成方法は、第57章「Developer Tools: ワークスペース」を参照してください。その他のDeveloper Toolsに関する章では、メインDeveloper Toolsワークスペースを対象に説明しています。

51.4 同期

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のページ・キャッシュおよび結果セット・キャッシュの透過的なフラッシュ操作も含まれます。

51.5 JSPの管理

Developer Toolsキットは、WebCenter SitesのJSPを個別のファイルとしてDeveloper Toolsワークスペースに公開します。開発者は、これらのJSPを、その他のJSPファイルと同じように管理(作成、編集、およびデバッグ)できます。

51.6 コマンドライン・ツール

Developer Toolsキットのコマンドライン・ユーティリティを使用すると、インポートおよびエクスポートのタスクの自動化、大規模なリソースの移動、カスタム・ワークスペースの作成、任意のワークスペースとのリソースの同期などが可能になります(これは、メインDeveloper Toolsワークスペースに格納されたリソースに対してのみ作業できるEclipse統合とは異なります)。

51.7 バージョン・コントロール・システムの使用

Developer Toolsキットは、バージョン・コントロール・システムの実装をサポートしています。ワークスペースからバージョン・コントロール・システムにリソースをチェックインすると、WebCenter Sitesのインスタンスと開発者間でリソースを交換できるようになります。また、他の開発者がバージョン・コントロール・システムにチェックインしたリソースでワークスペースを更新することもできます。バージョン・コントロール・システムを使用すると、テスト用サーバー、管理WebCenter Sitesシステム、他の開発者のWebCenter Sitesインスタンスなどのターゲット・システムにリソースをチェックアウトして、それらの機能(パブリッシュなど)を使用できるようになります。

図51-2は、Developer Toolsとバージョン・コントロール・システムを併用する例を示しています。この例では、専用のWebCenter Sitesインスタンスを使用して、リソースを管理WebCenter Sitesインスタンスにパブリッシュしています。そのため、WebCenter Sitesに備わった承認/パブリッシュの機能を使用して、バージョン・コントロール・システムからチェックアウトしたリソースをパブリッシュできます。この例は、Developer Toolsとバージョン・コントロール・システムを併せて使用する場合に推奨される方法ですが、必須だというわけではありません。

図51-2 Developer Toolsとバージョン・コントロール・システムの使用

51.8 次の手順

次の章では、Developer Toolsの設定手順と、WebCenter SitesインスタンスとEclipseの統合手順について説明します。さらに、Eclipseと統合されたWebCenter Sitesインスタンスで、リソースの作成および管理を始めるための情報についても説明します。第52章「Developer Tools: インストールと構成」を参照してください。

52 Developer Tools: インストールと構成

この章では、Developer Toolsを設定する手順、Developer Toolsを最新バージョンに更新する手順、およびEclipseにWebCenter Sitesインスタンスを統合する手順について説明します。さらに、EclipseでWebCenter Sitesリソースを管理する方法の概要について説明します。この章の最後の項では、Developer Toolsをアンインストールする手順について説明します。

この章には次の項が含まれます。

- 第52.1項「前提条件」

- 第52.2項「Developer Toolsの設定」

- 第52.3項「Developer Toolsの更新」

- 第52.4項「EclipseでのWebCenter Sitesリソースの管理」

- 第52.5項「WebCenter Sites Developer Toolsのアンインストール」

52.1 前提条件

Developer Toolsを設定する前に、次の点に注意してください。

- EclipseとWebCenter Sitesの統合が完了すると、WebCenter Sitesへのログインには、一般管理者の資格証明(fwadmin/xceladminなど)が必要になります。このユーザーは、RestAdminグループに属している必要があります。

- コマンドライン・ツール機能を使用する場合は、Developer Toolsについての高度な知識が必要になります。コマンドライン・ツールの実行と使用に関する詳細と手順は、第58章「Developer Tools: コマンドライン・ツール」を参照してください。

52.2 Developer Toolsの設定

1. 開発の要件に適したEclipseパッケージをダウンロードします。WebCenter Sitesの開発には、Eclipse IDE for Java EE Developersが推奨されています。Eclipseは、次のURLからダウンロードしてください。
http://www.eclipse.org/downloads/

2. WebCenter Sitesの配布パッケージ内にある、csdt.zipアーカイブを解凍します。このアーカイブに含まれるフォルダは、次のとおりです。

- csdt-client: コマンドライン・クライアント

- csdt-eclipse: Eclipseプラグイン。このフォルダには、アーカイブされたDeveloper Toolsプラグイン(com.fatwire.EclipseCSDT_11.1.1.v8_0_rxxxxxx.zip)が含まれています。

3. csdt-eclipseフォルダ内のDeveloper Toolsプラグイン(com.fatwire.EclipseCSDT_11.1.1.v8_0_rxxxxxx.zip)を、自分のファイル・システム上のフォルダ(${USER_HOME}など)に抽出します。

4. Developer Toolsプラグインをインストールします。

注意:

Eclipseは、ローカル・ファイル・システム(またはアーカイブ)の場所とリモートの場所からプラグインをインストールします。プラグインの場所は、ソフトウェア・サイトと呼ばれています。Developer Toolsプラグインの場合、ソフトウェア・サイトは、ファイル・システム上のアーカイブされたDeveloper Toolsプラグインへのパスになります(このプラグインは、手順3で抽出しています)。

1. Eclipseを起動します(eclipse.exeを実行します)。

2. Eclipseのメニューで、「Help」→「Install New Software」の順に選択します。
インストール・ウィザードが開始され、「Available Software」画面が表示されます(図52-1を参照)。

図52-1 インストール・ウィザード: 「Available Software」画面

3. 「Available Software」画面で、「Add」をクリックします(「Work with」フィールドの右側)。

4. 「Add Repository」ダイアログ・ボックス(図52-2を参照)で、次の各フィールドに入力してから「OK」をクリックします。

- 「Name」フィールドに、Developer Toolsプラグインの一意の名前を入力します。

- 「Location」フィールドで、「Archive...」をクリックして、Developer Toolsプラグイン・アーカイブ(手順3で抽出したアーカイブ)の場所(ソフトウェア・サイト)を指定します。

図52-2 「Add Repository」ダイアログ・ボックス

インストール・ウィザードは、指定された場所(ソフトウェア・サイト)からDeveloper Toolsプラグインを選択して、「Available Software」画面にプラグインの名前をリストします。

5. 「Available Software」画面で、「Oracle WebCenter Sites Developer Tools」を選択して(図52-3を参照)、「Next」をクリックします。

図52-3 インストール・ウィザード: Developer Toolsプラグインがリストされた「Available Software」画面

「Install Details」画面が開きます。

6. 「Install Details」画面(図52-4を参照)で、「Finish」をクリックします。

図52-4 インストール・ウィザード: 「Install Details」画面

7. インストール・プロセス中に、「Security Warning」ダイアログ・ボックスが開きます(図52-5を参照)。「OK」をクリックして、イントールを続行してください。

図52-5 「Security Warning」ダイアログ・ボックス

8. インストールが正常に完了すると、「Software Updates」ダイアログ・ボックスが開きます(図52-6を参照)。次を実行します。

1. ローカルのWebCenter Sitesインスタンスを開始します。
WebCenter Sitesが稼働していることを確認するには、${base_url}/HelloCSにアクセスします。ここで、${base_url}はWebCenter SitesインスタンスのベースURLです。たとえば、ベースURLがhttp://example:8080/csの場合、http://example:8080/cs/HelloCSがWebCenter Sitesインスタンスの検証URLとなります。

2. Eclipseを再起動するために、「Software Updates」ダイアログ・ボックスの「Yes」をクリックします。
Eclipseを再起動すると、プラグイン・キャッシュがリフレッシュされ、EclipseでDeveloper Toolsプラグインが使用できるようになります。

図52-6 「Software Updates」ダイアログ・ボックス

9. Eclipseの再起動後に、Developer Toolsプラグインが正常にインストールされていることを検証します。Eclipseのメニューで、「Help」→「About Eclipse」の順に選択します。
「About Eclipse」ダイアログ・ボックスが開き、インストール済プラグインのリストに「Developer Tools」アイコンが表示されます。図52-7を参照してください。

図52-7 「About Eclipse」ダイアログ・ボックス

5. Eclipse IDEの右上にある「Open Perspective」アイコンをクリックして、「Oracle WebCenter Sites」パースペクティブを開きます。「Open Perspective」ダイアログで、「Oracle WebCenter Sites」を選択して(図52-8を参照)、「OK」をクリックします。

図52-8 「Open Perspective」: 「Oracle WebCenter Sites」

6. Eclipse IDEにWebCenter Sitesを統合します。

- 初めてDeveloper Toolsを設定する場合は、構成フォームが自動的に表示されます。

- すでにWebCenter Sitesインスタンスに接続しているときに、別のインスタンスに接続するには、WebCenter Sitesツールバーに移動して、「Select Configuration」ウィザードをクリックして構成フォームを開きます。

構成フォーム(図52-9を参照)で、接続先にするWebCenter Sitesインスタンスの情報を、次の各フィールドに入力します。

図52-9 構成フォーム

1. 「Instance」フィールドでは、ローカル・ホストとリモート・ホストのどちらに接続するかに応じて、次のいずれかの操作を実行します。

注意:

リモート接続では、同一のリモート・ホスト上で複数のプロジェクトの作成がサポートされます。ローカル接続では、同時にサポートされるプロジェクトは1つのみになります。

- ローカル・ホストに接続する場合は、「Browse」をクリックして、WebCenter Sitesインスタンスのfuturetense.iniファイルを含むディレクトリを選択します。

- リモート・ホスト(たとえば、example:8080/cs)に接続する場合は、ホストへのパスを[host]:[port]/[path]の書式で入力します。

「Instance」フィールドに値を入力すると、次の各フィールドには自動的に値が入力されます。これらのフィールドの値は、「Instance」フィールドでローカル・ホストとリモート・ホストのどちらを指定したかに応じて異なります。

- Remote Connection: リモート・ホストに接続する場合、この値はtrueに設定されます。ローカル・ホストに接続する場合、この値はfalseに設定されます。

- Host IP Address: 接続するホストのIPアドレスを指定します。

- Port: 接続するホストのポート番号を指定します。

- Web Context Path: ホストへのコンテキスト・パスを指定します。

- Workspace: Developer Toolsワークスペース(Eclipseプロジェクト)の場所を指定します。

- Sites Context Root: ローカル・ホストに接続する場合、このフィールドには、WebCenter Sites Webアプリケーションのパスが含まれます。リモート・ホストに接続する場合、このフィールドは空欄になります。

2. 「Project name」フィールドに、作業するプロジェクトの名前を入力します。

3. 「Username」フィールドに、一般管理者のユーザー名を入力します。このユーザーは、RestAdminグループのメンバーである必要があります。

4. 「Password」フィールドに、手順cで入力したユーザー名のパスワードを入力します。

5. 「OK」をクリックします。
「Oracle WebCenter Sites」パースペクティブが開きます。WebCenter Sitesが統合されたEclipseに初めてアクセスすると、「Oracle WebCenter Sites」パースペクティブは図52-10のように表示されます。

図52-10 「Oracle WebCenter Sites」パースペクティブ

Oracleパースペクティブが、図52-10に示すようにレンダリングされた場合は、Developer Toolsの設定に成功しています。

注意:

EclipseビューとDeveloper Toolsビューを格納しているパネルは、相互に交換できます。別のパネルにビューを移動するには、ビューのタブをクリックして、そのタブを目的のパネルにドラッグします。

7. (オプション) Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスとOracle Fusion Middleware WebCenter Sites Java APIリファレンスを、Eclipseに関連付けます。

ローカル・ホストの場合:

1. TagReference.zipとjavadoc.zipをダウンロードします。

2. サーバーのコンテキスト・パスの下に、developerdocsという名前のフォルダを作成します。たとえば、サーバーがmyhost:8080/csにある場合、このdeveloperdocsフォルダへのパスはmyhost:8080/cs/developerdocsにする必要があります。

3. developerdocsフォルダ内に、TagReference.zipとjavadoc.zipを抽出します。

4. Eclipseで、「Sites Developer Reference」ビューを開きます。「Tag Reference」タブと「Javadoc」タブの両方で、「Home」をクリックします。それぞれのタブに、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスとOracle Fusion Middleware WebCenter Sites Java APIリファレンスが表示されます。

リモート・ホストの場合:

1. TagReference.zipとjavadoc.zipをダウンロードします。

2. サーバーのコンテキスト・パスの下に、developerdocsという名前のフォルダを作成します。たとえば、サーバーがexample:8080/csにある場合、このdeveloperdocsフォルダへのパスは、example:8080/cs/developerdocsにする必要があります。

3. developerdocsフォルダ内に、TagReference.zipとjavadoc.zipを抽出します。これで、このサーバーに接続するすべてのユーザーが、「Tag Reference」と「Javadoc」にアクセスできます。

4. Eclipseで、「Sites Developer Reference」ビューを開きます。「Tag Reference」タブと「Javadoc」タブの両方で、「Home」をクリックします。それぞれのタブに、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスとOracle Fusion Middleware WebCenter Sites Java APIリファレンスが表示されます。

8. (リモート・ホストの場合)コード補完を有効にして、WEB-INFディレクトリを、リモート・コンピュータから自分のEclipseプロジェクトにコピーします。これにより、Eclipseでのタグ補完と、構文の適切な強調表示が可能になります。詳細は、第54.2項「タグおよびJava APIの補完」を参照してください。

注意:

ローカル・インスタンスの場合、コード補完は自動的に有効化されます。

9. WebCenter Sitesシステムをアップグレードしていて、このリリースより前に作成したリソース(既存のリソース)に対してDeveloper Toolsを使用する場合は、第56.4.3項「既存のリソースとDeveloper Toolsの併用」を参照してください。

10. 「Oracle WebCenter Sites」パースペクティブでWebCenter Sitesリソースの管理をすぐに開始するには、次の項に進んでください。第52.4項「EclipseでのWebCenter Sitesリソースの管理」の手順4から開始してください。

52.3 Developer Toolsの更新

WebCenter Sitesインストールをアップグレードしたときには、この項の手順を実行して、Developer Toolsプラグインを更新してください。

Developer Toolsプラグインを更新する手順は次のとおりです。

1. 最新のDeveloper Toolsプラグイン・アーカイブを、ローカル・ファイル・システム上のフォルダに抽出します。

図52-11は、最新のDeveloper Toolsプラグイン・アーカイブ(com.fatwire.EclipseCSDT_11.1.1.v8_0_r157409.zip)を、現在インストールされているDeveloper Toolsプラグイン・アーカイブ(com.fatwire.EclipseCSDT_11.1.1.v8_0_r157385.zip)と同じフォルダに抽出した例を示しています。

注意:

Developer Toolsが最新バージョンであるかどうかを確認するには、アーカイブの名前に追加されているバージョン番号(rxxxxxx)を調べてください。

図52-11 ファイル・システム上の最新のプラグイン

2. Eclipseを起動します(eclipse.exeを実行します)。

3. Developer Toolsプラグインの場所(ソフトウェア・サイト)を更新します。

1. Eclipseのメニューで、「Window」→「Preferences」の順に選択します。
「Preferences」ウィンドウが開きます。

2. 「Preferences」ウィンドウで、「Install/Update」→「Available Software Sites」の順に選択します。「Available Software Sites」リストで、Developer Toolsエントリ(図52-12のWSDTエントリ)を選択して、「Edit」をクリックします。

図52-12 「Preferences」ウィンドウ: Developer Tools (WSDT)エントリの編集

「Add Repository」ダイアログ・ボックスが開きます。

3. 「Location」フィールドで、「Archive...」をクリックして、最新プラグイン(手順1で抽出したプラグイン)の場所を指定し、「OK」をクリックします(図52-13を参照)。

図52-13 「Add Repository」ダイアログ・ボックス

「Add Repository」ウィンドウが閉じられ、「Preferences」ウィンドウの「Available Software Sites」リストには、更新されたDeveloper Toolsエントリへのパスが表示されます。

4. 「Preferences」ウィンドウで、「OK」をクリックします。

4. 既存のプラグインに対する更新を確認します。

1. Eclipseのメニューで、「Help」→「Check for Updates」の順に選択します。
「Available Updates」ウィンドウが開きます。図52-14を参照してください。

図52-14 「Available Updates」ウィンドウ

2. 「Oracle WebCenter Sites Developer Tools」を選択して、「Next」をクリックします。
「Update Details」ウィンドウが開きます。図52-15を参照してください。

図52-15 「Update Details」ウィンドウ

3. 「Finish」をクリックして、更新を続行します。

4. 更新プロセス中に、「Security Warning」ダイアログ・ボックスが開きます(図52-16を参照)。「OK」をクリックして、更新を続行してください。

図52-16 更新プロセス中に表示される「Security Warning」ダイアログ・ボックス

5. 更新が正常に完了すると、「Software Updates」ダイアログ・ボックスが開きます。次を実行します。

1. ローカルのWebCenter Sitesインスタンスを開始します。

2. Eclipseを再起動するために、「Software Updates」ダイアログ・ボックスの「Yes」をクリックします。

6. Eclipseが再起動されたら、Developer Toolsプラグインが最新バージョンに正常に更新されていることを検証します。

1. Eclipseのメニューで、「Help」→「About Eclipse」の順に選択します。
「About Eclipse」ダイアログ・ボックスが開き、インストール済プラグインのリストに「Developer Tools」アイコンが表示されます。図52-17を参照してください。

図52-17 「About Eclipse」ダイアログ・ボックス

2. 「About Eclipse」ダイアログ・ボックスで、「Developer Tools」アイコンをクリックします。
「About Eclipse Features」ウィンドウが開き、Developer Toolsプラグインのバージョン詳細が表示されます。図52-18を参照してください。

図52-18 「About Eclipse Features」ウィンドウ

52.4 EclipseでのWebCenter Sitesリソースの管理

この項では、次に示すコード・ベースのWebCenter Sitesリソースについて、作成や編集などの管理手順を簡単に示して、Eclipseの「Oracle WebCenter Sites」パースペクティブの全体像を説明します。

- SiteEntryアセット

- CSElementアセット

- テンプレート・アセット

- ElementCatalogエントリ

- SiteCatalogエントリ

EclipseでWebCenter Sitesリソースを管理する手順は次のとおりです。

1. ローカルのWebCenter Sitesを開始します。

2. Eclipseを起動します。

3. 「Oracle WebCenter Sites」パースペクティブを開きます。
Eclipseメニュー・バーで、「Window」→「Open Perspective」→「Other」→「Oracle WebCenter Sites」の順に選択します。

4. リソースを作成するには、次の手順を実行します。

- SiteEntryアセットを作成するには、「New Site Entry」(SE)アイコンをクリックして、フォームに入力します。

- CSElementアセットを作成するには、「New CSElement」(C)アイコンをクリックして、フォームに入力します。

- テンプレート・アセットを作成するには、「New Template」(T)アイコンをクリックして、フォームに入力します。

- ElementCatalogエントリを作成するには、「New ElementCatalog Entry」(EC)アイコンをクリックして、フォームに入力します。

- SiteCatalogエントリを作成するには、「New SiteCatalog Entry」(SC)アイコンをクリックして、フォームに入力します。

フィールド定義については、第23章「テンプレート・アセット、CSElementアセットおよびSiteEntryアセットの作成」を参照してください。

5. 作成、編集、削除または他のサイトと共有するリソースを管理するには、「Sites Workshops Elements」ビューを使用します。リソースを右クリックし、目的のオプションを選択します。使用可能なオプションの詳細は、第53.4.1項「Sites Work」を参照してください。

6. Developer Toolsのビューをパネルに表示するには、次の手順を実行します。

1. 「Window」→「Show View」→「Other」の順に選択します。

2. 「Show View」ダイアログ・ボックスで、目的のビュー(Oracle WebCenter Sitesフォルダ内にあるビュー)を選択します。

- 「Sites UI」には、組込みのWebCenter Sites AdminインタフェースとContributorインタフェースが表示されます。

- 「Sites Log」には、WebCenter Sitesのログ・ファイルが表示されます。

- 「Sites Developer Reference」には、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスとOracle Fusion Middleware WebCenter Sites Java APIリファレンスが表示されます(ただし、タグ・リファレンスとJavadocを、現在のWebCenter Sitesインスタンスに関連付けている場合にかぎります)。手順については、第52.2項「Developer Toolsの設定」の手順7を参照してください。

- 「Sites Workspace Elements」では、コード関連のリソースにアクセスできます。このビューでは、ツリーにリソースが表示され、各リソースはサイト・アフィリエーションに従ってグループ化されます。

- 「Sites Logging Configuration」には、動的に更新されるlog4jの構成のビューが表示されます。このビューでは、各WebCenter Sitesログ出力のログ・レベルを設定できます。

- 「Sites Preview Browser」には、組込みのプレビュー・ブラウザが表示されます。

Developer Toolsのビューの詳細は、第53.4項「Developer Toolsのビュー」を参照してください。

7. WebCenter Sitesのリソースを同期するには、Synchronize Dataアイコンを選択します。同期ツールを使用すると、WebCenter SitesからDeveloper Toolsワークスペースにデータをエクスポートしたり、Developer ToolsワークスペースからWebCenter Sitesにデータをインポートできます。

- 同期ツールの使用方法の概要は、第53.5項「データ同期(エクスポート/インポート)ツール」を参照してください。

- リソースの同期の詳細は、第56章「Developer Tools: 同期とデータ交換」を参照してください。

52.5 WebCenter Sites Developer Toolsのアンインストール

この項では、Developer Toolsをアンインストールする手順について説明します。

Developer Toolsをアンインストールする手順は次のとおりです。

1. 「Oracle WebCenter Sites」パースペクティブを閉じます(「Oracle WebCenter Sites」パースペクティブに関連付けられたすべてのビューも同時に閉じます)。

2. Eclipseのメニューで、「Window」→「Preferences」の順に選択します。
「Preferences」ウィンドウが開きます。

3. 「Preferences」ウィンドウで、「Install/Update」を選択して、「Uninstall or update」リンクをクリックします(図52-19を参照)。

図52-19 「Preferences」: 「Install/Update」画面

4. 「Eclipse Installation Details」画面で、Developer Toolsプラグインを選択して、「Uninstall...」をクリックします(図52-20を参照)。

図52-20 「Eclipse Installation Details」画面

5. 「Uninstall Details」画面(図52-21を参照)で、「Finish」をクリックして、Developer Toolsプラグインのアンインストール・プロセスを続行します。

図52-21 「Uninstall Details」画面

6. 更新が正常に完了すると、「Software Updates」ダイアログ・ボックスが開きます(図52-22を参照)。「Yes」をクリックして、Eclipseを再起動します。

図52-22 「Software Updates」ダイアログ・ボックス

Eclipseを再起動すると、プラグイン・キャッシュがリフレッシュされ、EclipseからDeveloper Toolsプラグインが完全に削除されます。

53 Developer Tools: EclipseでのWebCenter Sites機能

この章では、WebCenter Sitesと統合されたEclipse IDEで利用できる、Developer Toolsの機能について説明します。

この章には次の項が含まれます。

- 第53.1項「Oracle WebCenter Sitesパースペクティブ」

- 第53.2項「構成画面」

- 第53.3項「Eclipseのプロジェクトとワークスペース」

- 第53.4項「Developer Toolsのビュー」

- 第53.5項「データ同期(エクスポート/インポート)ツール」

- 第53.6項「次の手順」

53.1 Oracle WebCenter Sitesパースペクティブ

EclipseでのDeveloper Toolsの機能は、すべて「Oracle WebCenter Sites」パースペクティブ内にグループ化されています。「Window」→「Open Perspective」→「Other」→「Oracle WebCenter Sites」の順に選択します。

図53-1 「Oracle WebCenter Sites」パースペクティブ

53.2 構成画面

構成画面は、WebCenter Sitesと統合されたEclipseに初めてアクセスしたときに自動的に開かれます。それ以降のアクセスでは、WebCenter Sitesツールバーの「Configuration」ボタンをクリックして、構成画面を開くことができます。この画面では、作業対象にするWebCenter Sitesインスタンスを指定できます。

構成画面では、WebCenter Sitesのインストール・ディレクトリへのパス、RestAdminグループに属するWebCenter SitesユーザーおよびWebCenter Sitesインスタンスのプロジェクト名が必須項目です。必須情報をすべて入力すると、Developer Toolsは、そのWebCenter Sitesインスタンスに応じて、他の多数のパラメータを決定し、それらのパラメータの情報を読取り専用フィールドに表示します。また、Developer Toolsが指定のWebCenter Sitesインスタンスに接続しているかどうかを示す接続インジケータも表示されます。

53.3 Eclipseのプロジェクトとワークスペース

Eclipseからアクセスする各WebCenter Sitesインスタンスには、Eclipseプロジェクトが割り当てられます。Eclipseプロジェクトのフォルダは、「Project Explorer」ビューに表示されます。このプロジェクトは、Developer Toolsワークスペースのアイテムを追跡するために必要になります。デフォルトでは、WebCenter Sitesインスタンスごとに1つのプロジェクトが作成されます。1つのプロジェクトで対応できるWebCenter Sitesインスタンスは1つのみになります。

注意:

プロジェクトの主な目的は、情報の追跡を円滑にすることと、Eclipseイベントを処理することです。プロジェクトはDeveloper Toolsプラグインで管理されます。プロジェクトは、開いたり、閉じたり、変更したりしないでください。

各Eclipseプロジェクトには、次のエレメントが含まれます。

- src: 現在のWebCenter Sitesインスタンスに対応するDeveloper Toolsワークスペースのフォルダです。このフォルダには、Developer Toolsワークスペースに格納されたリソースのファイルがすべて含まれています。このフォルダ内のリソースは、バージョン・コントロール・システムにチェックインできます。

- Config: このフォルダには、現在のWebCenter Sitesインスタンスに属している共通の構成ファイルへのリンクが含まれています。

- WEB-INF: このフォルダには、現在のWebCenter SitesインスタンスのWEB-INFフォルダへのリンクが含まれています。

例:

53.4 Developer Toolsのビュー

- 第53.4.1項「Sites Work」

- 第53.4.2項「Sites Logビュー」

- 第53.4.3項「Sites Preview Browserビュー」

- 第53.4.4項「Sites UIビュー」

- 第53.4.5項「Sites Logging Configurationビュー」

- 第53.4.6項「Sites Developer Referenceビュー」

- 第53.4.7項「ウィザード」

53.4.1 Sites Work

コード関連のリソースにアクセスできます。リソースは、それぞれのサイト・アフィリエーションに応じてグループ化されます。リソースを選択すると、このビューの下側にあるテキスト・ボックスに、そのリソースについての簡単な概要が表示されます。

ツリー内のリソースを右クリックすると、選択可能な管理オプションが表示されます。表示されるオプションは、選択したリソースに応じて異なります。

- Show Metadata: .main.xmlファイルへのショートカットです。このファイルには、選択したアイテムのメタデータが含まれています。

- Site Entry: リソースのサイト・エントリを表示したり、サイト・エントリを別のサイトと共有したり、新しいサイト・エントリを作成したり、サイト・エントリを削除したりします。

- Share: このリソースが関連付けられているサイトを管理します。

- Properties: このリソースのプロパティ(キャッシュ基準やデフォルトの引数など)を管理します。

- Delete: このリソースを削除します。

53.4.2 Sites Logビュー

動的に更新されるWebCenter Sitesログ・ファイルのレコードを表示します。このビューを使用すると、Eclipseと統合されたWebCenter Sitesインスタンスの動作を監視できます。

53.4.3 Sites Preview Browserビュー

簡単にページをプレビューできます。このビューでWebページをプレビューするには、アドレス・バーにページのURLを入力して、[Enter]を押すか、「Go」をクリックします。現在のページをリフレッシュするには、キーボード・ショートカットの[Ctrl] + [r]を使用するか、「Go」をクリックします。

53.4.4 Sites UIビュー

組込みブラウザ内に、WebCenter SitesのAdminインタフェースとContributorインタフェースが表示されます。これは、スタンドアロンのブラウザで使用するAdminインタフェースまたはContributorインタフェースと同じです。

注意:

WebCenter Sites Adminインタフェースは、Javaアプレットを使用して左側のペインを表示します。ブラウザのビューでアプレットを実行する方法の詳細は、Eclipse FAQ (http://www.eclipse.org/swt/faq.php#browserapplets)を参照してください。

アプレットを実行できない場合は、アプレットを使用しないAdminインタフェース・モードを使用するか、Adminインタフェースでの作業にスタンドアロンのブラウザを使用してください。

53.4.5 Sites Logging Configurationビュー

WebCenter SitesシステムでApache log4jを使用している場合、このビューには、動的に更新される「log4jの構成」画面が表示されます。「log4jの構成」画面を使用すると、現在のログ出力を表示したり、ログ出力レベルを変更したり、新しいログ出力を追加したり、ログを検索したりできます。

「log4jの構成」画面の使用方法の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

53.4.6 Sites Developer Referenceビュー

このビューには、2つのタブが含まれています。一方のタブにはOracle Fusion Middleware WebCenter Sitesタグ・リファレンスが表示され、もう一方のタブにはOracle Fusion Middleware WebCenter Sites Java APIリファレンスが表示されます。この情報は、Eclipseにタグ・リファレンスとJavadocを関連付けている場合にのみ表示されます。それ以外の場合、このビューには、Eclipseにタグ・リファレンスとJavadocを関連付ける手順が表示されます。手順については、第52.2項「Developer Toolsの設定」の手順7も参照してください。

53.4.7 ウィザード

ウィザードは、OracleメニューまたはWebCenter Sitesツールバーから起動できます。ウィザードを使用すると、コード・ベースのWebCenter Sitesリソースを作成できます。使用可能なウィザードは、SiteEntry、CSElement、テンプレート、ElementCatalog、SiteCatalog、構成ツールおよび同期ツールです。

53.5 データ同期(エクスポート/インポート)ツール

同期ツールには、次に示す2つのタブがあります。

- 第53.5.1項「Sync to Workspace (WebCenter Sitesからのエクスポート)」

- 第53.5.2項「Sync to WebCenter Sites (WebCenter Sitesへのインポート)」

53.5.1 Sync to Workspace (WebCenter Sitesからのエクスポート)

「Sync to Workspace」は、IDEと統合されたWebCenter SitesからDeveloper Toolsワークスペースにデータをエクスポートするために使用します。このプロセスでは、Developer Toolsは、選択されたリソースをシリアライズ(データベース表現をファイルに変換)して、シリアライズした表現をDeveloper Toolsワークスペースにコピーします。これにより、そのリソースをEclipseで変更できるようになります。

図53-2 同期アイコン/「Sync to Workspace」タブ

WebCenter Sitesからワークスペースにアイテムをエクスポートする手順は次のとおりです。

1. エクスポートするアイテムを選択します。アイテムのリストを絞り込むには、「正規表現」検索バーに移動して、検索するアセット・タイプの名前を入力します。複数のアセット・タイプを検索するには、カンマ区切りのリストを入力します。

2. 「Sync Selection to Workspace」をクリックします。
Developer Toolsワークスペースにエクスポートしたアセットは、「Sites Work」ツリー・タブにリストされます。

53.5.2 Sync to WebCenter Sites (WebCenter Sitesへのインポート)

「Sync to WebCenter Sites」は、IDEと統合されたWebCenter SitesにDeveloper Toolsワークスペースからのリソースをインポートするために使用します。このプロセスでは、Developer Toolsは、選択されたリソースをWebCenter Sitesのネイティブ表現に変換して、WebCenter Sitesデータベースにコピーします。

図53-3 同期アイコン/「Sync to WebCenter Sites」タブ

ワークスペースからWebCenter Sitesにアイテムをインポートする手順は次のとおりです。

1. インポートするアイテムを選択します。アイテムのリストを絞り込むには、「正規表現」検索バーに移動して、検索するアセット・タイプの名前を入力します。複数のアセット・タイプを検索するには、カンマ区切りのリストを入力します。

2. 「Sync Selection to WebCenter Sites」をクリックします。

53.6 次の手順

次の章では、Eclipse IDEでDeveloper Toolsによって提供されるWebCenter Sites機能を使用する方法について説明します。EclipseでのJSP開発については、第54章「Developer Tools: JSPの開発」に進んでください。

54 Developer Tools: JSPの開発

この章には、Developer Toolsを使用したWebCenter Sites JSPの開発に関する情報が記載されています。

この章には次の項が含まれます。

- 第54.1項「Developer Toolsを使用したJSPの開発」

- 第54.2項「タグおよびJava APIの補完」

- 第54.3項「デバッグ」

54.1 Developer Toolsを使用したJSPの開発

Developer Toolsキットでは、ネイティブのEclipse JSPエディタを使用したWebCenter Sites JSPの開発がサポートされています。Eclipse JSPエディタには、WebCenter SitesタグとJava API補完、構文の強調表示およびデバッグのサポートが含まれています。図54-1に、EclipseエディタでのWebCenter Sites JSPの例を示します。

図54-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で変更を表示できます。

54.2 タグおよびJava APIの補完

Eclipseには、タグおよびJava APIの補完機能があります。Eclipseでは、現在のWebCenter Sitesインスタンスに属するタグ・ライブラリとjarファイルを使用して、WebCenter Sites関連タグおよびJava APIの適切なコード補完を提供します。ローカル・ホストの場合、WebCenter Sitesタグ・ライブラリとjarファイルは、Eclipseプロジェクトに自動的にリンクされ、Eclipseプロジェクト・フォルダ(「ProjectExplorer」ビュー内)に含まれます。リモート・ホストの場合、WebCenter Sitesタグ・ライブラリとjarファイルは、リモート・ホストからEclipseプロジェクトに手動でコピーする必要があります。手順については、第52.2項「Developer Toolsの設定」を参照してください。

- タグ・ライブラリは、WEB-INFフォルダの下のfuturetense_csフォルダに含まれています。

- jarファイルは、メインのEclipseプロジェクト・フォルダの下に含まれています。

注意:

タグおよびJava APIの補完機能を使用する場合は、次の点に注意してください。

- 必ず厳密なJSPコーディング標準に従ってください。これにより、コードをアプリケーション・サーバーにデプロイできます。

- Eclipseコード補完により、WebCenter Sites jar内に含まれているパブリックJavaメソッドがすべて表示されます。WebCenter Sitesドキュメント内にあるAPIのみを使用してください。ドキュメントに記載されていない機能の使用は、リスクが高く、サポートされていません。

Oracle Fusion Middleware WebCenter Sites Java APIリファレンスとOracle Fusion Middleware WebCenter Sitesタグ・リファレンスをEclipseに関連付けると、タグおよびJava APIの補完機能により、WebCenter Sites JSPを管理する際に使用する各タグとJavaコードの断片に関する情報を表示できます。たとえば、WebCenter Sites JSPでの作業中に、タグの名前の入力を開始すると、コード補完の提案をリストするウィンドウが表示されます。タグ・リファレンスとJavadocをEclipseに関連付けている場合は、各提案に関する情報を含む2番目のダイアログ・ボックスが表示されます(図54-2を参照)。

図54-2 タグおよびJava APIの補完機能

Javadocとタグ・リファレンスは、タグおよびJavaコード補完機能に機能を追加するだけでなく、どちらも「Sites Developer Reference」ビューでアクセス可能です。詳細は、第53.4.6項「Sites Developer Referenceビュー」を参照してください。

54.3 デバッグ

Developer ToolsでJavaおよびJSPコードをデバッグするには、最初に、WebCenter Sitesを実行するJVMプロセスにデバッガをアタッチする必要があります。これはリモート・デバッグで実行することをお薦めします。WebCenter Sites JVMをアタッチするには、次のURLに記載されている、Eclipseが提供する手順に従ってください。

http://www.ibm.com/developerworks/library/os-ecbug/

JVMがデバッガにアタッチされると、JSPおよびJavaコード、ビュー変数などでブレークポイントを設定できます。

55 Developer Tools: モバイルWebサイト用テンプレートの作成

Developer Toolsを使用すると、モバイル・サイト用のテンプレートを作成できます。

この章には次の項が含まれます。

- 第55.1項「Developer ToolsのMobilityサポートの概要」

- 第55.2項「Developer Toolsを使用したモバイル・テンプレートの開発」

55.1 Developer ToolsのMobilityサポートの概要

Developer Toolsは、WebCenter Sites: Mobilityフレームワークをサポートしています。Mobility機能を使用すると、モバイル・デバイス用のWebサイトを作成できます。Mobility機能の詳細は、第68章「モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成」を参照してください。

55.2 Developer Toolsを使用したモバイル・テンプレートの開発

「Oracle WebCenter Sites」パースペクティブでは、テンプレートは「Sites Workspace Elements」タブのノードとして表示されます。ワークスペースには、WebCenter SitesインスタンスからEclipseにインポートしたテンプレート(デフォルトおよびモバイル)が表示されます。モバイル・テンプレートは、開発者定義の接尾辞で識別できます。(たとえば、タッチスクリーン・デバイス用に作成したテンプレートの場合は、_Touchのようになります。)

モバイル・テンプレートを開発する場合は、既存のテンプレートを基にして作成する必要があります。この項の残りの部分では、モバイル・テンプレートの作成手順について説明します。

モバイルWebサイト用のテンプレートを作成する手順は次のとおりです。

1. 「Sites Workspace Elements」タブ(左パネル内)で、モバイル・テンプレートを作成するサイトのノードを開きます。

注意:

モバイル・テンプレートには、開発者定義の接尾辞ごとに1つ以上のデバイス・グループ(同様の機能を備えたデバイスのグループ)が関連付けられます。デバイス・グループの詳細は、第68章「モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成」を参照してください。

図55-1は、「MarketingSite」ツリーを開いた状態を示しています。このツリーには、デフォルト・デバイス・グループ用(デスクトップおよびラップトップ用)のHome.jspテンプレートが含まれています。

図55-1 「MarketingSite」ノードの下に表示されたHome.jspテンプレート・エレメント

2. モバイル・テンプレートの基にするテンプレートを右クリックします。コンテキスト・メニューで、「Create Device Group Template」を選択して、作成するテンプレートのデバイス・グループの名前を選択します。

注意:

複数のデバイス・グループで、同一の接尾辞を共有できます。リスト内に適切なデバイス・グループが見つからない場合は、すでに作成されているデバイス・グループと同じ接尾辞でテンプレートを定義できます。開発者定義の接尾辞の詳細は、第68章「モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成」を参照してください。

図55-2 「Create Device Group Template」のコンテキスト・メニュー

「New Template」ウィンドウが開きます(図55-3を参照)。このウィンドウには、固定および変更可能なプロパティの値を保持するフィールドが表示されます。これらの値は、ソース・テンプレート(この例では、「MarketingSite」の「Home」テンプレート)から、ウィザードによってコピーされた値です。

3. 「New Template」ウィンドウで、変更可能フィールドのプロパティをモバイル・テンプレートの要件に合せて変更して、「Finish」をクリックします。

図55-3 「Home_Touch」モバイル・テンプレートの「New Template」フォーム

モバイル・テンプレートのファイル名(「New Template」フォームの「Storage path」フィールドで定義します)は、「Sites Workspace Elements」タブにリストされます。図55-4を参照してください。

図55-4 「Sites Workspace Elements」タブに表示されたHome_Touch.jsp

図55-4には、Home_Touchという名前のモバイル・テンプレートが示されています。この名前の「Home」の部分はテンプレートの名前です。「_Touch」の部分は、このテンプレートが作成されたデバイス・グループに定義した接尾辞です。

4. 新しいモバイル・テンプレートのコードを変更するには、ネイティブのEclipse JSPエディタを使用してください。(詳細は、第54章「Developer Tools: JSPの開発」を参照してください)。

56 Developer Tools: 同期とデータ交換

この章では、Developer Toolsによってサポートされているエクスポートおよびインポート機能について説明します。また、この章では、WebCenter SitesインスタンスとDeveloper Toolsマッピング・プロセス間のリソース交換についても説明します。

Developer ToolsキットはIDとサイト・マッピング・プロセスを使用して、開発者がWebCenter Sitesインスタンス間のリソースを交換できるようにします。Developer Toolsキットについては、IDマッピングとサイト・マッピングに関する項で説明します。

この章には次の項が含まれます。

- 第56.1項「Developer Toolsを使用した同期」

- 第56.2項「同期シナリオ」

- 第56.3項「依存性の解決」

- 第56.4項「IDマッピング」

- 第56.5項「サイト・マッピング」

56.1 Developer Toolsを使用した同期

同期はWebCenter Sitesインスタンスとその関連ワークスペース間のリソースの双方向フローです。Developer Toolsを使用して、次の同期操作を実行できます。

- 組込み依存性解決とIDマッピングを持つアセットをエクスポートおよびインポートします。

- フレックス・ファミリやAssetMakerアセット・タイプなどの、アセット・タイプをエクスポートおよびインポートします。

- サイト定義、ロール、スタート・メニュー・アイテムおよびツリー・タブをエクスポートおよびインポートします。

- SiteCatalogエントリおよびElementCatalogエントリをエクスポートおよびインポートします。

- (コマンドライン・ツール操作)サイトの再マッピングを実行します。たとえば、WebCenter Sites CMサイトにインポート可能な再使用可能なモジュールを作成します。

指定されたサイトのすべてのリソースをエクスポートまたはインポートすると、バージョン・コントロール・システムでサイト全体を追跡できます。上級開発者はコマンドライン・ツールを使用して、再使用可能なモジュール(カスタム・ワークスペース)を作成することにより、あるサイトのリソースを別のサイトに再マッピングできます。

56.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に自動的に同期されます。ただし、フレックス定義を変更するには、WebCenter SitesのAdminインタフェースを使用することをお薦めします。

場合によっては、Eclipse IDEの同期ツールまたはコマンドライン・ツール(上級開発者の場合)のいずれかを使用して、リソースを手動で同期する必要があります。手動同期は次の場合に必要です。

- Eclipseエディタが、Developer Toolsワークスペースに格納されているリソースの編集に使用されない場合。たとえば、リソースが共有ネットワーク・ファイル・システムまたはバージョン・コントロール・システムからDeveloper Toolsワークスペースにコピーされる場合などです。

- WebCenter Sitesのリソースが、WebCenter Sitesインタフェースで変更される場合。

注意:

Eclipse IDEは埋込みのWebCenter Sites Adminインタフェースを提供します。ただし、Eclipseはこのインタフェースを使用して行われる変更を検出しません。したがって、埋込みのAdminインタフェースでの作業は、Adminインタフェースを実行しているスタンドアロン・ブラウザでの作業と同じになります。

- WebCenter Sitesは、Eclipse IDEでリソースを作成または編集している間は実行されません。WebCenter Sitesが再起動したら、作成または編集したリソースを手動で同期する必要があります。

リソースの同期にコマンドライン・ツールを使用するのは、サーバーをテストするためにデプロイされるナイトリー・ビルドなど、主にデプロイメントのためです。たとえば、上級開発者は、自動化されたデプロイメント手順用のスクリプトに同期コマンドを埋め込むことができます。コマンドライン・ツールの実行および使用方法の詳細は、第58章「Developer Tools: コマンドライン・ツール」を参照してください。

56.3 依存性の解決

WebCenter Sitesのリソースは、多くの場合、他のリソースに依存します。たとえばフレックス・アセットは、そのアセットが作成される前に、関連付けられたフレックス定義が存在している必要があります。また、フレックス定義は属性セットに依存したり、他のリソースに依存する可能性もあります。したがって、すべてのフレックス構造では、システム上にフレックス・ファミリが存在している必要があります。フレックス・アセットを空のWebCenter Sitesシステムにインポートするには、まずフレックス・アセットが関連付けられるフレックス・ファミリを作成する必要があります。その後、次の手順を実行します。

1. フレックス属性を作成します。たとえば、名前、住所、年齢などです。

2. 必要なフレックス親定義を作成します。

3. フレックス定義を作成します。

4. 必要なフレックス親を作成します。

5. フレックス・アセットを作成します。

フレックス・アセットをエクスポートすると、Developer Toolsキットによって、そのアセットのすべての依存性が解決され、その依存性がすべて自動的にエクスポートされます。したがって、必要なリソース(必要なフレックス・アセットなど)を選択するだけで、Developer Toolsキットによって、アセットの依存性がすべて計算されます。

注意:

Developer Toolsキットは、サイト定義上でリソースの依存性を解決しません。これにより、サイト全体またはサイトのサブセットをエクスポートまたはインポートするか、あるいはサイト定義を完全に無視するかどうか(たとえば、コマンドライン・ツールを使用して、任意のサイトにインポートできる再使用可能なモジュールを作成している場合)を選択できます。再使用可能なモジュールの作成の詳細な例は、第61章「Developer Tools: コマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。

56.4 IDマッピング

WebCenter Sitesで作成された各リソースには、一意のローカルIDが割り当てられます。リソースのローカルIDは、作成されたWebCenter Sitesインスタンスに対してのみ一意です。リソースの作成には複数のWebCenter Sitesインスタンスが使用されるため、別個のWebCenter Sitesインスタンス上の2つの異なるリソースは、同じローカルIDを持つことができます。

この項の内容は、次のとおりです。

- 第56.4.1項「IDマッピングの概要」

- 第56.4.2項「リソースのfw_uidのオーバーライド」

- 第56.4.3項「既存のリソースとDeveloper Toolsの併用」

56.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インスタンスを使用しているとします(図56-1)。両方の開発者は完全に異なるテンプレート・アセットを作成しました。開発者AはテンプレートAを作成し、開発者BはテンプレートBを作成しました。2つのテンプレート・アセットは、fw_uid値も名前も異なります。ただし、ローカルIDがランダムに割り当てられているため、両方のテンプレート・アセットに、偶然同じローカルID (12345)が割り当てられています。開発者AとBは、お互いのWebCenter Sitesインスタンス間で、テンプレート・アセットを交換しようと考えています。開発者AはテンプレートBをCS1インスタンスに、開発者BはテンプレートAをCS2インスタンスにインポートしようと考えています。

図56-1は、両方の開発者がWebCenter Sitesインスタンス間でテンプレート・アセットを交換するために行う手順を説明しています。両方のテンプレート・アセットのローカルIDは、別の開発者のWebCenter Sitesインスタンスにインポートされるときに再マップされます。テンプレートAがCS2インスタンスにインポートされるときに、システムによってローカルID 52563が割り当てられます。テンプレートBがCS1インスタンスにインポートされるときに、システムによってローカルID 22342が割り当てられます。いずれの場合にも、両方のテンプレート・アセットのfw_uid値は同じままです。

注意:

この例の開発者は、WebCenter Sitesインスタンス間でのリソース交換にVCSまたは共有ファイル・システムを使用します。VCSの使用方法の詳細は、第59章「Developer Tools: バージョン・コントロール・システムとの統合」を参照してください。

図56-1 同じローカルIDを持つ2つの異なるアセットの2つのWebCenter Sitesインスタンス間での交換

図56-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値は変わりません。

図56-2 同じローカルIDを持つ2つの異なるアセットの、3番目のWebCenter Sitesインスタンスへのデプロイ

リソースがワークスペースにエクスポートされた場合は、fw_uidによってのみ識別されます。ElementCatalogエントリとSiteCatalogエントリはエレメント名によって一意に識別されているため、fw_uidは割り当てられません。

56.4.2 リソースのfw_uidのオーバーライド

リソースが作成されると、グローバルな一意識別子としてUUID値が自動的に生成され、fw_uidという名前のアセット属性に格納されます。上級開発者はアセットAPIを使用してfw_uid属性を変更することにより、デフォルトのfw_uidスキームを独自のスキームでオーバーライドできます。アセットAPIの使用方法の詳細は、Oracle Fusion Middleware WebCenter Sites Java APIリファレンスを参照してください。

注意:

デフォルトのWebCenter Sites fw_uidスキームの使用をお薦めします。リソースのデフォルトfw_uid値をオーバーライドする場合は、値がWebCenter Sitesインスタンス全体で一意であることを確認する必要があります。一度リソースのfw_uid属性を設定したら、その後は値を変更しないでください。

56.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をリソースに割り当てることができます。手順については、第56.4.2項「リソースのfw_uidのオーバーライド」を参照してください。

注意:

リソースに新しいfw_uidを割り当てる場合は、そのリソースのすべてのインスタンスに新しいfw_uid値を割り当てる必要があります。たとえば、リソースを別のWebCenter Sitesインスタンスにパブリッシュした後でfw_uid値を変更する場合は、必ずそのリソースの両方のコピーに、同じfw_uidを割り当ててください。

56.5 サイト・マッピング

アセットなどの大半のWebCenter Sitesリソースは、少なくとも1つのサイトに関連付けられています。リソースがWebCenter Sitesインスタンスからワークスペースへエクスポートされると、関連付けられているサイトの完全な(正規の)リストが.main.xmlファイル内に格納されます。新しいサイト・アフィリエーションの追加、現在のサイト・アフィリエーションの削除、または(上級開発者の場合)コマンドライン・ツールを使用したリソースのナチュラル・サイト・マッピングのオーバーライドを実行しないかぎり、リソースの正規リストは各WebCenter Sitesインスタンス間で同じです。

この項の内容は、次のとおりです。

- 第56.5.1項「ナチュラル・サイト・マッピング」

- 第56.5.2項「コマンドライン・ツールを使用したナチュラル・サイト・マッピングのオーバーライド」

56.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は正規リストを使用して、テンプレート・アセットが関連付けられたサイトを認識します。これらのサイトの一部がインストールされていないインスタンスに、アセットをエクスポートした場合でも認識できます。

56.5.2 コマンドライン・ツールを使用したナチュラル・サイト・マッピングのオーバーライド

上級開発者はコマンドライン・ツールを使用して、正規リストで参照されていないサイトにリソースをインポートできます。コマンドライン・ツールを使用すると、再利用可能なモジュールを作成できます。このモジュールは、任意のサイトにインポート可能なリソースを含むワークスペースです。

たとえば、開発者がFirstSiteIIサンプル・サイト内にブログ・ソリューションを作成するとします。このソリューションには、フレックス・ファミリ、アセット、テンプレートなどのリソースが含まれます。開発者は、まだ存在しないサイトも含め、様々なサイトにリソースをインポートすることを望んでいます。上級開発者であるため、コマンドライン・ツールを使用して必要なリソースを空のワークスペースにエクスポートしてから、このワークスペースのコンテンツを(.zipまたは.tar形式を使用して)アーカイブします。その後、他の開発者はコマンドライン・ツールを使用して、このモジュールに含まれるリソースのサイト・マッピングをカスタマイズし、モジュールのインポート先サイトを手動で指定します。

コマンドライン・ツールの使用方法の詳細は、第58章「Developer Tools: コマンドライン・ツール」を参照してください。再使用可能なモジュールの作成の詳細なシナリオは、第61章「Developer Tools: コマンドライン・ツールを使用した再利用可能モジュールの作成」を参照してください。

57 Developer Tools: ワークスペース

この章では、統合されたWebCenter Sitesインスタンスからエクスポートしたリソースが、どのようにDeveloper Toolsに格納されているかについて説明します。

この章には次の項が含まれます。

- 第57.1項「ワークスペースの概要」

- 第57.2項「ワークスペースの構造」

- 第57.3項「アセット記憶域の構造」

- 第57.4項「コード・ベースのリソース記憶域の構造」

- 第57.5項「属性エディタ記憶域の構造」

- 第57.6項「アセット・タイプ記憶域の構造」

57.1 ワークスペースの概要

ワークスペースとは、シリアライズされたWebCenter Sitesデータのディスクベースのリポジトリです。このデータは、ワークスペースのWebCenter Sitesインスタンスからのリソース、または別のインスタンスのワークスペースからのリソースを表します。ワークスペースには、アセット、フレックス・ファミリ、サイトなどのあらゆるタイプのWebCenter Sitesリソースを格納できます。各ワークスペースは、1つのWebCenter Sitesインスタンスに関連付けられています。

デフォルトでは、Eclipseは、WebCenter Sitesインスタンスごとに1つのメインDeveloper Toolsワークスペース(Eclipseプロジェクト・フォルダ内に配置される)を提供します。これは、Eclipse IDEで作業する際の継続的な開発に使用されます。カスタム・ワークスペースは、上級開発者がDeveloper Toolsのコマンドライン・ツールを使用して作成できます。カスタム・ワークスペースは、モジュールの作成などの特殊なプロジェクトに使用できます。カスタム・ワークスペースの作成方法の詳細は、第58章「Developer Tools: コマンドライン・ツール」を参照してください。

バージョン・コントロール・システム(Subversionなど)や共有ファイル・システムと併用することで、あるワークスペースに格納されたリソースを別のワークスペースと交換できるようになります。あるWebCenter Sitesインスタンスから関連ワークスペースにエクスポートされたリソースは、別のWebCenter Sitesインスタンスのワークスペースにコピーできます。これにより、そのリソースは、2番目のワークスペースの関連WebCenter Sitesインスタンスにインポートできるようになります。異なるワークスペース間でのリソース共有の詳細は、第59章「Developer Tools: バージョン・コントロール・システムとの統合」を参照してください。

57.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ファイルが適切なパスの下に格納されます。

ワークスペースの構造は高度に一貫性が保たれているため、あるワークスペースから別のワークスペースにリソースをコピーできます。どのファイル・システムのコピー操作にも当てはまることですが、同じ名前のファイルを上書きしないように注意してください。

57.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で追跡している場合は、古い名前のファイルを削除してください。

57.4 コード・ベースのリソース記憶域の構造

テンプレート、CSElement、およびElementCatalogのエントリは、それらのコード・エレメントで必要になるストレージ・パスの下に格納されます。コード・ベースのリソースに関連付けられたJSPファイルは、src/jsp/cs_deployedの下のワークスペースに格納され、XMLエレメントはsrc/_metadata/ELEMENTSの下に格納されます。コード・ベースのリソースのメタデータ・ファイルは、そのリソースのJSPと同じ名前に拡張子.main.xmlが追加されたファイル名で格納されます。これにより、コード・ベースのリソースのメタデータ・ファイル、JSPファイル、およびXMLファイルは、ワークスペース内でグループ化されます。

57.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

57.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

58 Developer Tools: コマンドライン・ツール

この章では、上級開発者に向けに、コマンドライン・ツールの実行方法と使用方法について説明します。

Developer Toolsのコマンドライン・ツールは、デプロイメントやその他のリソースの移動操作に使用できます。作業対象がDeveloper ToolsのワークスペースにかぎられるEclipse統合とは異なり、コマンドライン・ツールでは、どのワークスペースも作業対象にできます。また、コマンドライン・ツールには、Eclipse IDEでの作業時には使用できないインポート機能とエクスポート機能があります。たとえば、開発者は、任意のサイトにインポート可能なリソースを含むワークスペース(再利用可能なモジュール)を作成できます。

この章には次の項が含まれます。

- 第58.1項「コマンドライン・ツールの実行と使用」

- 第58.2項「コマンド例」

- 第58.3項「モジュールの作成」

58.1 コマンドライン・ツールの実行と使用

コマンドライン・ツールを実行する手順は次のとおりです。

1. csdt.zipを解凍します。これは、WebCenter Sitesの配布パッケージ内にあります。csdt-clientフォルダを開いて、csdt-client.jarファイルをクラスパス内に配置します。Oracle Fusion Middleware WebCenter Sites動作保証マトリックスにリストされたすべての要件を満たしていることを確認します。このリストは、Oracle Technology Network (http://otn.oracle.com)から入手できます。

2. コマンドライン・ツール(cmd)を実行して、次のコマンドを入力します。

java com.fatwire.csdt.client.main.CSDT  [ContentServer url]
username= username   password= password
cmd=export|import|listcs|listds    [options]

プレースホルダのパラメータは、自分の開発環境に関する情報と、実行する必要のあるコマンドに置き換えてください。

- ContentServer url: ローカルの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 assetアセットとすべての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ワークスペースがデフォルトで指定されます。リソースをエクスポートするときに、指定のワークスペースが存在しない場合は、そのワークスペースがコマンドライン・ツールにより自動的に作成され、目的のリソースがエクスポートされます。

58.2 コマンド例

コマンドライン・ツールを使用して実行できるコマンド例のリストを、次に示します。

- このコマンドは、FirstSiteIIに属しているアセットのうち、指定した日付以降に変更された特定のContent_CアセットとすべてのProduct_Cアセットをエクスポートします。ワークスペースを指定していないため、Developer Toolsワークスペースがデフォルトで使用されます。

java com.fatwire.csdt.client.main.CSDT  http://localhost:8080/cs/ContentServer username=bob password=password resources=Content_C:123432123423,11234234212,111234341234;Product_C:* fromSite=FirstSiteII modifiedSince=2010-08-08 19:14:00 cmd=export

- このコマンドは、ワークスペースに含まれる特定のContent_CアセットとすべてのProduct_Cアセットをインポートします。ワークスペースを指定していないため、Developer Toolsワークスペースがデフォルトで使用されます。

java com.fatwire.csdt.client.main.CSDT  http://localhost:8080/cs/ContentServer username=bob password=password resources=Content_C:aad618e9-f04e-4ee4-b902-076224bb6f7b;Product_C:* fromSite=FirstSiteII cmd=import

- このコマンドは、サイトSecondSiteIIのすべてのリソースを「TheOutput」という名前のワークスペースにエクスポートします。

java com.fatwire.csdt.client.main.CSDT  http://localhost:8080/cs/ContentServer username=bob password=password resources=@ALL_ASSETS:*;@ALL_NONASSETS:*  fromSite=SecondSiteII  datastore=TheOutput cmd=export

- このコマンドは、「TheInput」という名前のワークスペースに含まれるすべてのアセットとツリー・タブをサイトMySiteにインポートします。

java com.fatwire.csdt.client.main.CSDT  http://localhost:8080/cs/ContentServer username=bob password=password resources=@ALL_ASSETS:*;@TREETAB:* toSites=MySite  datastore=TheInput cmd=import

58.3 モジュールの作成

モジュールは、WebCenter Sitesインスタンスから特定のワークスペースにエクスポートされる関連リソースのセットです。datastoreパラメータを使用すると、WebCenter Sitesリソースのエクスポート先にするワークスペース、またはWebCenter Sitesリソースのインポート元にするワークスペースを指定できます。存在していないワークスペースにWebCenter Sitesリソースをエクスポートすると、そのワークスペースがコマンドライン・ツールにより自動的に作成され、目的のリソースがエクスポートされます。

モジュールは再利用可能であり、モジュールに含まれるコンテンツは任意のCMサイトにインポートできます(そのサイトが、リソースのサイトに関する正規リストに示されていない場合でもインポートできます)。モジュールをCMサイトにインポートするには、importコマンドを実行する必要があります。datastoreパラメータでは、目的のリソースが含まれているワークスペースを指定します。また、toSitesパラメータでは、それらのリソースをインポートするサイトを指定します。これにより、ワークスペースのコンテンツは、指定したCMサイトにインポートされます。

59 Developer Tools: バージョン・コントロール・システムとの統合

この章では、Developer Toolsワークスペースに含まれるリソースをバージョン・コントロール・システム(VCS)に保存する方法について説明します。これにより、Developer Toolsワークスペースのリソースを、他の開発者と共有できます。

この章には次の項が含まれます。

- 第59.1項「バージョン・コントロールとDeveloper Toolsについて」

- 第59.2項「Developer ToolsとVCSの統合」

- 第59.3項「Developer Toolsが統合されたVCSでの作業」

59.1 バージョン・コントロールとDeveloper Toolsについて

バージョン・コントロール・システム(VCS)は、ソース・コード・リポジトリを作成する機能を提供します。VCSは、ソース・ファイルをバージョニング、ブランチ化および管理するための高度なツールを提供できます。Developer ToolsのワークスペースがWebCenter Sitesリソースを格納するファイル・システム構造によって、それらのリソースを任意のVCS上に格納でき、VCS内で完全なCMサイトを追跡できます。

59.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ワークスペースのレイアウトの詳細や、リソースをワークスペースのファイルにマップする方法については、第57章「Developer Tools: ワークスペース」を参照してください。

注意:

Developer ToolsワークスペースからVCSにデータをチェックインする場合、Developer Toolsワークスペースのファイル構造を詳しく理解する必要はありません。かわりに、ほとんどのVCSクライアントは、Developer Toolsワークスペースのフォルダへの増分変更を検出し、それらの変更をVCSコミット操作時に示します。

59.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に統合できません。

60 Developer Tools: 開発チーム統合のユースケース

この章では、開発者チームがDeveloper Toolsを使用してCMサイトやリソースの作成を行う開発シナリオを示します。開発チームは、Developer Toolsにより提供される同期ツールを使用して、複数のWebCenter Sitesインスタンス間でリソースの管理および交換を行います。コマンドライン・ツールを使用して、CMサイトとそのリソースをナイトリー・ビルドとしてデプロイします。

シナリオのイベントのシーケンスは次のとおりです。

- 第60.1項「今日: サイトおよび関連付けられたリソースの開発」

- 第60.2項「3日後... デプロイメント」

60.1 今日: サイトおよび関連付けられたリソースの開発

午前7時14分: 新しいプロジェクトの割当て

Artie (アーキテクト)が起床し、自分が新しいWebベースのプロジェクトのリーダーに任命されたことを知ります。

午前7時34分: Developer Toolsの設定

Artieはコーヒーを飲み、自分のラップトップにWebCenter Sitesインスタンスをインストールします。その後、Eclipse IDEを起動して、Developer Toolsキットを構成します。

注意:

EclipseとWebCenter Sitesインスタンスを正常に統合するために、Artieは構成画面で一般管理者のユーザー名とパスワードを入力する必要があります。このユーザーは、RestAdminグループのメンバーである必要があります。

午前7時45分: サイト定義の作成

ArtieはEclipseの、組込みのWebCenter Sites Adminインタフェース・ビューを使用して、サイト定義を作成します(このシナリオでは、サイトの名前は「Acceptance」とします)。

Artieは、WebCenter Sites 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)を作成します。次に、属性をフレックス定義に追加します。

午前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」画面を使用して「Sync to Workspace」タブにアクセスし、検索フィールドに@Siteセレクタを入力して、自分のWebCenter Sitesインスタンス上にあるすべてのサイトのリストを取得します。

Artieは、先に作成したサイト(「Acceptance」サイト)を選択し、「Sync Selection to Workspace」オプションをクリックして、自分のWebCenter Sitesインスタンスからワークスペースに、サイト定義をエクスポートします。

2. 次に、Artieはサイトに関連付けられたフレックス・ファミリをワークスペースにエクスポートします。@ASSET_TYPEセレクタを使用して、自分のWebCenter Sitesインスタンス上にある、すべてのアセットをリストします。結果を絞り込むには、検索文字列Author_を使用します。その後、Artieはリストされているすべてのアイテムを選択して、「Sync Selection to Workspace」をクリックします。

フレックス・ファミリのタイプはワークスペースにシリアライズされます。これには、タイプ固有のElementCatalogエントリも含まれます。

3. ここで、Artieは自分のワークスペースにフレックス定義をエクスポートします。ArtieはAuthor_CDセレクタを使用します。このセレクタは、そのタイプの使用可能な定義をすべてリストします。この場合、定義は1つ(fictionAuthor)のみです。

注意:

Artieは、サイト定義が依存するフレックス属性(Author_Aインスタンス)を選択しませんでした。フレックス属性は、Developer Toolsキットによって自動的に定義と同期されることを知っていたからです。

4. Artieは、Eclipseの「Project Explorer」ビューで自分のワークスペースにさっと目を通して、自分の作業内容がすべてそこにあることを確認します。上から下まで見て、次の内容がプロジェクトのsrcフォルダにあることを確認します。

- Artieが同期したアセット・タイプごとの_metadata.ASSET_TYPEエントリ

- 両方のAuthor_A属性の_metadata.ASSET.Author_Aファイル

- シリアライズした定義の_metadata.ASSET.Author_CDファイル

- シリアライズした各アセット・タイプに関連するElementCatalogエントリの_metadata.ELEMENTSエントリ

- サイト定義の_metadata.SITEエントリ

注意:

Artieは、自分のWebCenter Sitesインストール・ディレクトリのexport/envision/cs_workspaceフォルダに、同じデータがあるかどうかを確認します。

Artieのワークスペース内には、すべてのリソースがあるように見えます。ただし、これはすべてArtieのラップトップ上にあり、チームはアクセスできません。ここで、チェックインが必要になります。

5. ArtieはSubclipseを使用して開発チームのSVNリポジトリに接続し、自分のメインDeveloper Toolsワークスペースのフォルダ(srcフォルダ)をSVNリポジトリにコミットして、自分のDeveloper Toolsプロジェクトを共有します。

注意:

メインDeveloper Toolsワークスペースは、Eclipseの「Project Explorer」ビューのsrcフォルダにあります。srcフォルダ内にあるファイルのみをコミットします。その他のファイルはすべて補助ローカル・リソースです。これらはコミットしないでください。

午前10時12分: 他のチーム・メンバーのワークスペースとSVNリポジトリの同期

SonokoとMatthäusは、各自のEclipse統合WebCenter Sitesインスタンスの設定を完了したところです。2人は各自のEclipseプロジェクトをSVNリポジトリに接続します。

先にArtieがサイトとそのリソースをSVNリポジトリにチェックインしているため、Subclipseはターゲットの場所がすでに存在していることを検出します。

SonokoとMatthäusは、自分のメインDeveloper Toolsワークスペースとリソースを同期します。このリソースは、ArtieがSVNリポジトリで使用可能にしたものです。これで、SonokoとMatthäusのメインDeveloper Toolsワークスペースから、それらのリソースにアクセスできるようになります。

ただし、リソースはまだ、SonokoやMatthäusのWebCenter Sitesインスタンスと同期されていません。

午前10時18分: ワークスペースとWebCenter Sitesインスタンスの同期

Sonokoは「Developer Tools Synchronization」画面を開いて、「Sync to WebCenter Sites」タブを選択します。SonokoのメインDeveloper Toolsワークスペースに含まれる、すべてのリソースがリストされます。

必要に応じて、Sonokoは最初にサイト定義をインポートし、次にフレックス・ファミリ、その次にアセットを個別にインポートして、次の説明のように実行します。

注意:

Matthäusは、マーケティングとのミーティング終了後に同じ作業を行います。

1. サイト定義(このシナリオでは「Acceptance」)をインポートします。
Sonokoは最初にサイト定義をインポートします。検索フィールドでSite.*Accepta式を使用して、検索を絞り込みます。次に、サイト(「Acceptance」)を選択し、「Sync to WebCenter Sites」をクリックして、そのサイトと自分のWebCenter Sitesインスタンスを同期します。

Sonokoは「FW Log」ビューを使用して、サイトが正常にインポートされていることを確認します。

2. もう一度同期画面を開いて、サイトのフレックス・ファミリをインポートします。インポートはフレックス属性(このシナリオではAuthor_A)から始めます。
Sonokoは「Acceptance」サイトのフレックス・ファミリを自分のWebCenter Sitesインスタンスで設定しなかったので、まず自分のWebCenter Sitesインスタンスにフレックス属性(Author_A)をインポートする必要があります。フレックス属性をインポートすると、サイトのフレックス・ファミリを構成する残りのアセット・タイプを、自分のWebCenter Sitesインスタンスに同期できます。

3. 最後の手順として、Sonokoはフレックス定義を同期します。これにより、必要な属性が自動的にインポートされます。
サイトのすべてのリソースのローカル・アセットIDは、新しいWebCenter Sitesインスタンスにインポートされると、再マップされます。これが「FW Log」ビューに表示されます。

午前10時21分: サイト権限の割当て

Sonokoはリソースと自分のWebCenter Sitesインスタンスの同期した後、自分にサイト権限を割り当てます。これらの権限により、SonokoはWebCenter Sites Adminインタフェースから、サイトやそのリソースにアクセスできます。

注意:

新しいサイトのツリー・アプレットにアクセスするために、Sonokoは少なくとも1つのツリー・タブをサイトに割り当てる必要があります。

午前10時22分: スタート・メニューの問題

Sonokoはサイトにログインして、「New」オプションをクリックします。しかし、利用できるスタート・メニュー・アイテムがないことに気付きます。Artieがサイトのスタート・メニュー・アイテムをSVNリポジトリにチェックインしていなかったので、当然です。

午前10時24分: スタート・メニューの問題の解決

SonokoはArtieに、新しいサイトのスタート・メニュー・アイテムのチェックインを忘れていることを知らせるIMを送ります。

1. Artieはサイトのスタート・メニュー・アイテムを、自分のメインDeveloper Toolsワークスペースと同期します。

2. 次に、Artieはサイトのスタート・メニュー・アイテムをSVNリポジトリにチェックインします。

3. Sonokoは角砂糖を2個入れて、紅茶を飲みました。デスクに戻ると、Artieがスタート・メニュー・アイテムをSVNにコミットしたことに気付きます。Sonokoは自分のEclipseプロジェクトを更新します。SVNリポジトリにアクセスして、スタート・メニュー・アイテムを自分のメインDeveloper Toolsワークスペースに同期します。次に、これらのスタート・メニュー・アイテムを、自分のWebCenter Sitesインスタンスにインポートします。

4. Sonokoは自分のWebCenter Sitesインスタンスを再起動しないで、「Search」をクリックします。
自分のWebCenter Sitesインスタンスにインポートしたスタート・メニュー・アイテムがリストされます。

午前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リポジトリにコミットします。

午前11時25分: サイトへの変更の確認

Artieは、変更されたAuthor定義をSVNから取得して、自分のWebCenter Sitesインスタンスにインポートします。

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」になっていることを確認します。「VO」は属性が無効であることを示します。
SonokoとMatthäusが自分のWebCenter Sitesインスタンスを更新すると、それに応じて、「birthplace」属性がSonoko達のワークスペースで無効になります。

午前11時53分: チームのワークスペースとWebCenter Sitesインスタンスの更新

1. SonokoとMatthäusは、自分のメインDeveloper Toolsワークスペースを、ArtieがSVNリポジトリにチェックインしたリソースで更新します。

2. 次に、「Synchronize to WebCenter Sites」タブを開いて、自分のワークスペースのリソースを、各自のWebCenter Sitesインスタンスにインポートします。使い勝手がよいように、リソースは「Modified Date」列でソートしておきます。これで、最新の変更が一番上に表示されます。
無効の属性(Artieが無効にした「birthplace」属性など)の「Name」列には、ステータスのヒント(status=VO)が表示されます。

3. SonokoとMatthäusは、自分のワークスペースから各自のWebCenter Sitesインスタンスに、これらの変更をインポートします。これで、ワークスペースとWebCenter Sitesインスタンスは最新の状態になります。

午後12時27分: サイトのテンプレート・アセットの作成

1. (午後12時27分) Matthäusはサイトの「Welcome」ページのテンプレート・アセットを作成します。

2. (午後12時34分) Matthäusはテンプレート・アセットを編集し、変更を「FW Preview Browser」ビューでプレビューします。テンプレート・アセットのJSPに加えた変更を保存し、すぐにキーボード・コマンドの[Ctrl] + [r]を使用してプレビュー・ブラウザを更新します。

3. (午後12時39分) Matthäusはテンプレートの.jspファイルと.main.xmlファイルをSVNリポジトリにコミットします。
Subclipseはプロジェクトの変更をすべて検出し、それらの変更を開発者に提示します。テンプレート・アセット以外に新しいアセットがないため、Matthäusは、.main.xmlファイルがテンプレートのメタデータであり、JSPファイルがテンプレートのコードであると推測できます。

4. (午後12時44分) Sonokoは自分のワークスペースで、テンプレートのJSPファイルを一部修正します。

5. SonokoはJSPファイルの変更を確認し、その変更をSVNにコミットします。

注意:

万一、Sonokoと同時に別のチーム・メンバーがこのファイルを修正してチェックインすると、SVNからSonokoに対して、別バージョンのファイルがすでにチェックインされていることが通知されます。Sonokoはそれらの変更を自分の変更と統合して、想定外の上書きを回避できます。

60.2 3日後... デプロイメント

Yogeshはコマンドライン・ツールを使用してサイトをデプロイします。この項で使用するコマンドについては、第58章「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 CS install directory
## create if not there
/home$ mkdir /opt/cs/export/envision/cs_workspace
/home$ cd  /opt/cs/export/envision/cs_workspace

## checkout site from svn
/opt/cs/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セレクタを使用するためのコマンド:

/opt/cs/export/envision/cs_workspace$ export
CLASSPATH=csdt-client-1.0.2.jar
/opt/cs/export/envision/cs_workspace$ java
com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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セレクタを使用するためのコマンド:

/opt/cs/export/envision/cs_workspace$ export
CLASSPATH=csdt-client-1.0.2.jar
/opt/cs/export/envision/cs_workspace$ java
com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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:*セレクタを使用して、必要なアセット・タイプがすべてインポートされることを確認します。
コマンド:

/opt/cs/export/envision/cs_workspace$
java com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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. 最初にサイトをインポートします。
コマンド:

/opt/cs/export/envision/cs_workspace$ java
com.fatwire.csdt.client.main.CSDT
http://localhost:9999/cs/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. 次にフレックス・ファミリをインポートします。
コマンド:

/opt/cs/export/envision/cs_workspace$ java
com.fatwire.csdt.client.main.CSDT
http://localhost:9999/cs/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. 次にアセットをインポートします。
コマンド:

/opt/cs/export/envision/cs_workspace java
com.fatwire.csdt.client.main.CSDT
http://localhost:9999/cs/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はスタート・メニュー・アイテムをインポートします。WebCenter Sites Adminインタフェースを使用して、すべてのリソースが正常にインポートされることを確認するためです。
コマンド:

/opt/cs/export/envision/cs_workspace$ java
com.fatwire.csdt.client.main.CSDT
http://localhost:9999/cs/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, etc
## Prepare the database with any custom settings, etc.
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分に実行されます。

61 Developer Tools: コマンドライン・ツールを使用した再利用可能モジュールの作成

Developer Toolsキットを使用すると、モジュールの形式でリソースを再利用および共有できるようになります。モジュールは、サイトに固有ではないワークスペースです。このワークスペースには、テンプレート、フレックス・ファミリ、ElementCatalogエントリなどのリソースが含まれています。ナチュラル・マッピングを使用してアセットがサイトに追加される標準のエクスポート/インポートとは異なり、モジュールでは、どのサイトにでもインポートできるように、通常はサイトのオーバーライドを使用します。

この章には次の項が含まれます。

- 第61.1項「再利用可能なモデルの作成」

- 第61.2項「WebCenter Sitesインスタンスでのリソースのリスト」

- 第61.3項「スタート・メニュー・アイテムのリスト」

- 第61.4項「目的のワークスペースへのすべてのリソースのエクスポート」

- 第61.5項「モジュールのコンテンツの調査」

- 第61.6項「モジュールのアーカイブ」

- 第61.7項「WebCenter Sitesインスタンスへのモジュールのインポート」

61.1 再利用可能なモデルの作成

Artieはフレックス定義のあるフレックス・ファミリを所有しています。このフレックス定義は、他のサイトで再利用する予定です。また、そのフレックス定義に関連付られたテンプレート・アセットも所有しています。次のシナリオでは、Artieがこれらのリソースを含むモジュールを作成します。このシナリオでは、コマンドライン・ツールを使用して、Artieとチームが第60章「Developer Tools: 開発チーム統合のユースケース」で開発したリソースを含むモジュールを作成します。

注意:

コマンドライン・ツールを使用するために、Artieはコマンドを実行するたびに、一般管理者のユーザー名とパスワードを指定する必要があります。このユーザーは、RestAdminグループのメンバーである必要があります。このシナリオでは、Artieはfwadmin/xceladminを使用します。

次の各項を参照してください。

- 第61.2項「WebCenter Sitesインスタンスでのリソースのリスト」

- 第61.3項「スタート・メニュー・アイテムのリスト」

- 第61.4項「目的のワークスペースへのすべてのリソースのエクスポート」

- 第61.5項「モジュールのコンテンツの調査」

- 第61.6項「モジュールのアーカイブ」

- 第61.7項「WebCenter Sitesインスタンスへのモジュールのインポート」

61.2 WebCenter Sitesインスタンスでのリソースのリスト

Artieはコマンドライン・ツールを使用して、自分のWebCenter Sitesインスタンスを参照します。resources=@ALL_ASSETSセレクタとfromSites=Acceptanceセレクタを使用して、Artieは「Acceptance」サイトのすべてのアセットをリストします。Artieはlistcsコマンドを使用して、自分のWebCenter Sitesインスタンス上のリソースをすべてリストします。

コマンド:

/opt/cs/export/envision/cs_workspace$ export CLASSPATH=csdt-client-1.0.2.jar
/opt/cs/export/envision/cs_workspace$ java com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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つのテンプレート・アセットがあることを確認します。

61.3 スタート・メニュー・アイテムのリスト

Artieはもう一度コマンドライン・ツールを使用して、「Acceptance」サイトに割り当てられたスタート・メニュー・アイテムを参照します。

コマンド:

/opt/cs/export/envision/cs_workspace$ java com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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 ||| -

61.4 目的のワークスペースへのすべてのリソースのエクスポート

Artieは、第61.2項「WebCenter Sitesインスタンスでのリソースのリスト」と第61.3項「スタート・メニュー・アイテムのリスト」でリストされたすべてのリソースを使用して、モジュールを作成しようとしています。次のコマンドを実行して、指定したワークスペースに、すべてのリソースを一度にエクスポートします。

コマンド:

/opt/cs/export/envision/cs_workspace$ java com.fatwire.csdt.client.main.CSDT
http://localhost:9010/cs/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インスタンスで再利用可能にするために必要になります。

61.5 モジュールのコンテンツの調査

Artieは、自分のファイル・システムのauthorModuleワークスペースを調べます。

Artieは自分のファイル・システムのワークスペースに、テンプレート・アセット、フレックス・ファミリのメンバー、アセット・タイプおよびスタート・メニュー・アイテムがすべてエクスポートされていることを確認します。

61.6 モジュールのアーカイブ

ArtieはauthorModuleワークスペースの.zipファイル・アーカイブを作成して、そのアーカイブを保存します。

61.7 WebCenter Sitesインスタンスへのモジュールのインポート

Artieは、FirstSiteIIサンプル・サイトにモジュールをインポートすることにしました。

1. Artieは、ターゲットのWebCenter Sitesインスタンスの、ワークスペースの場所にモジュールを解凍します。

2. コマンドライン・ツールを使用して、Artieはアセット・タイプとスタート・メニュー・アイテムを、ターゲットのWebCenter Sitesインスタンスにインポートします。
コマンド:

D:\FatWire\JSKdemo\ContentServer>java com.fatwire.csdt
.client.main.CSDT
http://localhost:8080/cs/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サンプル・サイトのWebCenter Sites Adminインタフェースにアクセスして、アセット・タイプとスタート・メニュー・アイテムが正常にインポートされていることを確認します。

4. ここでArtieは、アセットをインポートします。
コマンド:

D:\FatWire\JSKdemo\ContentServer>java com.fatwire.csdt
.client.main.CSDT http://localhost:8080/cs/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サンプル・サイトにフレックス定義が正常にインポートされていることを確認します。

6. コマンドライン・ツールを使用して、Artieはテンプレート・アセットをインポートします。次に、もう一度WebCenter Sites Adminインタフェースにアクセスして、テンプレート・アセットが正しくインポートされていることを確認します。

モジュール全体が、FirstSiteIIサンプル・サイトに正常にインポートされています。このモジュールは再利用可能であり、任意のWebCenter Sitesインスタンスにインポートできます。

第III部

Contributorインタフェースのカスタマイズ

この部の最初の章では、WebCenter SitesのContributorインタフェースをカスタマイズするための開発環境の概要について説明します。その後の各章では、カスタマイズ可能なインタフェース・コンポーネント、カスタマイズ方法およびサポート・コードに関する情報を提供します。

注意:

この部のサンプル・コードは、バンドルされていないWebCenter Sites配布ファイルのmisc\Samples\UICustomization\ディレクトリにあります。

- 検索ビューとダッシュボードをカスタマイズするためのコードは、CustomAttrEditor.zipファイルで提供されます。

- アセット・フォームをカスタマイズするためのコードは、sample_elements.zipファイルで提供されます。

この部は、次の章で構成されています。

- 第62章「Oracle WebCenter Sites Contributorインタフェースのカスタマイズについて」

- 第63章「Contributorインタフェース: フレームワークおよびUIコントローラについて」

- 第64章「Contributorインタフェース: ダッシュボードのカスタマイズ」

- 第65章「Contributorインタフェース: 検索ビューのカスタマイズ」

- 第66章「Contributorインタフェース: グローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ」

- 第67章「Contributorインタフェース: 検索フォームのカスタマイズ」

62 Oracle WebCenter Sites Contributorインタフェースのカスタマイズについて

このガイドでは、WebCenter Sites Contributorインタフェースのコンポーネントをカスタマイズする手順について説明します。この章では、カスタマイズ可能なコンポーネントを概説し、WebCenter Sitesで提供されているサンプル・コードの場所を示します。

この章は、次の項が含まれています。

- 第62.1項「始める前に」

- 第62.2項「Contributorインタフェースでカスタマイズできる内容」

- 第62.3項「サンプル・コードの検索場所」

- 第62.4項「開始する場所」

注意:

WebCenter SitesのContributorインタフェースは、開発者ではなく、コンテンツ・プロバイダによって使用されるように設計されています。そのため、次のシステム定義のアセット・タイプをContributorインタフェースで表示(検査)できますが、それらをContributorインタフェースで作成(または編集)できません。Template、CSElement、SiteEntry、DimensionSet、Dimension、Attribute Editor、Parent Definitions、AttributesおよびFlex Definitions。同様に、次のシステム定義のアセット・タイプはContributorインタフェースからアクセスできません。FW_ApplicationおよびFW_View。これらのタイプのアセットは、WebCenter SitesのAdminインタフェースでのみ作成(または編集)できます。

62.1 始める前に

このガイドを使用する開発者は、Contributorインタフェースに関する実践的な知識を持っている必要があります。また、Java、JavaScriptおよびHTMLの使用経験があって、WebCenter Sites開発ツールに熟知している必要があります。

Contributorインタフェースの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』および『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

62.2 Contributorインタフェースでカスタマイズできる内容

次のリストは、Contributorインタフェースでカスタマイズできるコンポーネントを要約しています。

- ダッシュボード。第64章「Contributorインタフェース: ダッシュボードのカスタマイズ」を参照してください。

- 検索ビュー。第65章「Contributorインタフェース: 検索ビューのカスタマイズ」を参照してください。

- グローバルおよびサイト固有の構成プロパティ、ツールバーおよびメニュー・バー。第66章「Contributorインタフェース: グローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ」を参照してください。

- アセット・フォーム。第67章「Contributorインタフェース: アセット・フォームのカスタマイズ」を参照してください。

62.3 サンプル・コードの検索場所

このガイドでは、インタフェースのカスタマイズを例示するためにサンプル・コードの一部が提供されています。その他のコードもWebCenter Sitesに同梱されているか、個別に提供されています。このようなコードへのパスは、このガイドの個々の章でリストされています。

62.4 開始する場所

Contributorインタフェース・フレームワークには、UIコントローラというコンポーネントが含まれており、アセット・フォーム関連以外のほとんどのインタフェース関連リクエストを処理します。UIコントローラは、第63章「Contributorインタフェース: フレームワークおよびUIコントローラについて」で説明されています。

- ダッシュボード、検索ビュー、構成プロパティ、ツールバー、メニュー・バーなどのコンポーネントのいずれかをカスタマイズする場合は、第63章から開始して、このガイドのほとんどの箇所とカスタマイズ・プロセスで使用する、概念とコードに関する基本情報を取得することをお薦めします。

- アセット・フォームをカスタマイズする場合は、アセット・フォーム・ヘッダーの変更および属性エディタの構築について、第67章「Contributorインタフェース: アセット・フォームのカスタマイズ」を参照してください。

63 Contributorインタフェース: フレームワークおよびUIコントローラについて

この章では、WebCenter Sites Contributorインタフェースのフレームワーク、特にインタフェース関連のすべてのリクエストを処理するUIコントローラについて説明します。また、UIコントローラで実行されるエレメントについても説明します。ここで紹介されている概念は、Contributorインタフェースをカスタマイズするための基本です。この概念は、このガイド全体を通じて使用されます。

この章は、次の項が含まれています。

- 第63.1項「Contributorフレームワークの概要」

- 第63.2項「UIコントローラ」

- 第63.3項「カスタム・エレメント」

63.1 Contributorフレームワークの概要

WebCenter Sites Contributorインタフェースのフレームワークは、サービス・レイヤーの上位にあり、クライアント・リクエストを処理します。図63-1に示すように、フレームワークは、プレゼンテーション・レイヤーとUIコントローラで構成されます。

図63-1 Contributorインタフェース・フレームワーク

プレゼンテーション・レイヤーは、ビューをレンダリングするエレメントとレスポンスを生成するエレメントで構成されます。第63.2項「UIコントローラ」で説明するように、UIコントローラは、Contributorインタフェースから受信したリクエストの処理に使用されます。

注意:

アセット・フォームはContributorフレームワークの外部に存在するため、UIコントローラはアセット・フォーム関連のリクエストの処理には使用されません。アセット・フォームについては、第67章「Contributorインタフェース: アセット・フォームのカスタマイズ」を参照してください。

63.2 UIコントローラ

図63-1に示されているUIコントローラは、Contributorインタフェースから受信したリクエストを処理するエンティティです。この項では、UIコントローラのリクエスト処理フェーズ、各フェーズのエレメントのネーミング規則、およびUIコントローラにおけるカスタム・エレメントのチェック・プロセスについて説明します。

この項の内容は、次のとおりです。

- 第63.2.1項「UIコントローラでリクエストを処理する方法」

- 第63.2.2項「例: エレメント・リクエストを処理するUIコントローラ」

63.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コントローラはまず、そのフェーズに固有のカスタム・エレメントのテストを行います。このプロセス・フローについては、第63.2.2項「例: エレメント・リクエストを処理する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というプレゼンテーション・エレメントを評価しようとします。

63.2.2 例: エレメント・リクエストを処理するUIコントローラ

UIコントローラがエレメント・リクエストを処理する場合、次のようにカスタム・エレメントをテストします。各フェーズ(構成、アクションおよびプレゼンテーション)で、UIコントローラはまず、そのフェーズ固有のカスタム・エレメントを検索します(詳細は、第63.3.2項「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/内にある)を実行します。

63.3 カスタム・エレメント

Contributorインタフェースをカスタマイズする場合、この項の説明に従って、推奨される場所にカスタム・エレメントを保存します。UIコントローラがそれらのエレメントをどのように検索するかを十分に理解しておいてください。

この項の内容は、次のとおりです。

- 第63.3.1項「エレメント・ストレージ」

- 第63.3.2項「UIコントローラでエレメントを検索する方法」

- 第63.3.3項「このガイドのエレメント・ネーミング規則」

63.3.1 エレメント・ストレージ

Contributorインタフェースのフレームワークにより、開発者はベスト・プラクティスに従って、カスタム・エレメントをシステムのデフォルト・エレメントから切り離しておくことができます。

注意:

システムのデフォルト構成を変更しないことをお薦めします。かわりに、独自のカスタム・エレメントを作成して、ElementCatalogのCustomElementsの下に保存することで、アップグレード時でも保持されるようにします。

カスタム・エレメントへのパスは、そのエレメントがグローバル、サイト固有、サイト固有およびアセット・タイプ固有、またはアセット・タイプ固有であるかどうかによって異なります。例として、図63-2を参照してください。

図63-2 カスタム・エレメントへのパス

63.3.2 UIコントローラでエレメントを検索する方法

UIコントローラがエレメントを検索する場合

1. UIコントローラは、まず、次の順序でCustomElementsの下にあるすべてのパスを横断することによって、エレメントのカスタマイズされたバージョンを検索します。

1. サイト固有およびアセット・タイプ固有のパス

2. アセット・タイプ固有のパス

3. サイト固有のパス

4. グローバル・パス

(パスの例として、図63-2を参照してください。)

2. カスタム・エレメントが見つからない場合、UIコントローラはシステム定義のエレメントを使用します。

注意:

UIコントローラがアセット・タイプ固有のエレメントを使用する場合、assetTypeParamパラメータの値として有効なアセット・タイプを指定してから、そのパラメータを渡す必要があります。

63.3.3 このガイドのエレメント・ネーミング規則

WebCenter Sitesでパッケージ化されたシステム定義のエレメントまたはサンプル・エレメントを参照している場合、このガイドでは、そのエレメントへのフル・パスが提供されます。フル・パスは常にUI/Layout/で始まります。たとえば、このガイドでは、システム定義エレメントDashBoardContentsConfig.jspは、次のように表示されます。

UI/Layout/CenterPane/DashBoardContentsConfig

作成するカスタム定義のエレメントを参照する場合、パスが不明であるため、このガイドでは、エレメント(JSP)の名前のみが提供されます。例:

DashBoardContentsConfig.jsp

カスタム・エレメントは、CustomElementsの下に保存されているものと想定されます。

64 Contributorインタフェース: ダッシュボードのカスタマイズ

この章では、WebCenter SitesのContributorインタフェースのダッシュボードをカスタマイズする方法を説明します。ダッシュボードの構成に関する詳細な説明と、この章で説明する手順を実行しながら使用できるサンプル・コードが記載されています。

この章は、次の項が含まれています。

- 第64.1項「ダッシュボード・カスタマイズの概要」

- 第64.2項「ダッシュボードのカスタマイズ」

- 第64.3項「ダッシュボードのカスタマイズの例」

64.1 ダッシュボード・カスタマイズの概要

Contributorインタフェースにログインすると、ダッシュボードが表示されます。デフォルトでは、図64-1に示すような使用準備済のウィジェット(「ブックマーク」、「SmartLists」、「チェックアウト」および「割当て」)がダッシュボードに表示されます。

図64-1 デフォルトのウィジェットが表示されたダッシュボード

ダッシュボードおよびそのウィジェットの次の部分をカスタマイズできます。

- 列の数

- 列幅

- ダッシュボード上のウィジェットの表示名、高さおよび位置

- 新しいウィジェットを追加することもできます。

64.2 ダッシュボードのカスタマイズ

システム定義のダッシュボードは、コントローラ・エレメントUI/Layout/CenterPane/DashboardContentsConfigによって生成されます。このエレメントをオーバーライドできます。

ダッシュボード構成は、グローバルまたはサイト固有にすることができます。デフォルトのウィジェットのカスタマイズ、新しいウィジェットの追加、および必要でないウィジェットの削除が行えます。

ダッシュボードをカスタマイズするには:

CustomElementsの下に独自のDashBoardContentsConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/DashBoardContentsConfigをオーバーライドします。

注意:

新しいウィジェットが追加されるか、既存のウィジェットが更新される場合、変更が行われるようにWEM UIのユーザー・プリファレンスを消去する必要があります。

次に、UI/Layout/CenterPane/DashBoardContentsConfigエレメントを示します。表64-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>

表64-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>で指定された値です。

64.3 ダッシュボードのカスタマイズの例

WebCenter Sites Contributorダッシュボードに新しいウィジェットを追加できます。新しいウィジェットを追加するには、次の2つの基本的な手順を実行します。

1. ウィジェット・エレメントの作成

2. カスタムDashBoardContentsConfig.jspエレメントへの新しいウィジェットの登録

この項では、ダッシュボードにウィジェットを追加するプロセスについて説明します。この項には、次の例が含まれています。

- 第64.3.1項「'Hello World'ウィジェットの追加」

- 第64.3.2項「最近変更されたアセットを表示するウィジェットの追加」

64.3.1 'Hello World'ウィジェットの追加

この項では、図64-2に示す、単純なウィジェットを作成および登録します。

図64-2 'Hello World'ウィジェット

ウィジェットをダッシュボードに追加するには

1. ウィジェットを作成します。

1. CustomElementsの下にJSPエレメントを作成します。この例では、エレメントにHelloWorldHtmlという名前を付けます。

2. ウィジェット・コードについては、このガイドで提供されているサンプル・ファイルに移動して、その内容をコピーできます。

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インタフェースのホームページをリフレッシュします。新しいウィジェットがダッシュボードに表示されます(図64-2)。

64.3.2 最近変更されたアセットを表示するウィジェットの追加

この項では、前の週に変更されたアセットを表示するウィジェットを作成します。この項の手順を完了したら、ダッシュボードに図64-3のようなウィジェットが表示されます。

図64-3 「最近変更されたアセット」ウィジェット

ウィジェットをダッシュボードに追加するには

1. ウィジェットを作成します。

1. CustomElementsの下にAction JSPエレメントを作成します。この例では、エレメントにRecentlyModifiedAssetsAction.jspという名前を付けます。ウィジェット・コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。

2. 前の手順で作成したアクション・エレメントのJson JSPエレメントを作成します。この例では、エレメントにRecentlyModifiedAssetsJson.jspという名前を付けます。コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。このエレメントをRecentlyModifiedAssetsAction.jspエレメントと同じ場所にエレメントを置きます。

3. ウィジェットのCustomElementsの下にプレゼンテーション・エレメントを作成します。ウィジェット・エレメントと同じ名前を付けます。この例では、表示エレメントにRecentlyModifiedAssetsHtml.jspという名前を付けます。コードについては、このガイドで提供されるサンプル・ファイルに移動して、その内容をコピーできます。

注意:

プレゼンテーション・エレメントはRecentlyModifiedAssetsAction.jspエレメントをコールします。そのエレメントへのパスを入力します。

2. ウィジェットを登録します(ダッシュボードに追加します)。

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. ダッシュボードをリフレッシュして、新しく構成されたウィジェットを表示します。例については、図64-3を参照してください。

65 Contributorインタフェース: 検索ビューのカスタマイズ

この章では、WebCenter Sites Contributorインタフェースのリストおよびサムネイルの検索ビューをカスタマイズする方法について説明します。

この章は、次の項が含まれています。

- 第65.1項「検索ビューのカスタマイズの概要」

- 第65.2項「カスタマイズ・プロセス」

- 第65.3項「ドッキングされていないビューのカスタマイズ」

- 第65.4項「ドッキングされたビューのカスタマイズ」

- 第65.5項「ソート・メニューおよびツールチップのカスタマイズ」

65.1 検索ビューのカスタマイズの概要

ユーザーがWebCenter SitesのContributorインタフェースにログインして、サイトにアクセスする場合、簡易検索または詳細検索を実行して、必要なアセットを検索できます。検索結果は、「リスト表示」または「サムネイル表示」のいずれかに表示されます。この項では、様々な検索ビュー、そのカスタマイズ可能な機能、および検索ビューの構成を制御するエレメントについて説明します。検索機能とビューに関する情報が必要な場合は、『Oracle WebCenter Sitesユーザーズ・ガイド』を参照してください。この項の内容は、次のとおりです。

- 第65.1.1項「検索ビューのタイプ」

- 第65.1.2項「検索ビューでカスタマイズ可能な内容」

- 第65.1.3項「ビューレンダリング・プロセス」

- 第65.1.4項「検索ビューの構成エレメント」

65.1.1 検索ビューのタイプ

検索結果パネルはドッキングされている状態またはドッキングされていない状態で、リスト表示またはサムネイル表示として表示できます。したがって、Contributorインタフェースには、次のビューが表示されます。

- ドッキングされていないリスト

- ドッキングされたリスト

- ドッキングされていないサムネイル

- ドッキングされたサムネイル

編集用にオープンになっているアセットが存在しない場合にのみ、ドッキングされていないビューが開きます。ドッキングされたビューは、編集モードのアセットにアタッチされるため、アセットが編集モードでオープンになっている場合にのみ開きます。

65.1.2 検索ビューでカスタマイズ可能な内容

図65-1は、リスト表示でカスタマイズ可能な機能を示しています。図65-2は、サムネイル表示でカスタマイズ可能な機能を示しています。詳細は、第65.3項「ドッキングされていないビューのカスタマイズ」を参照してください。これはドッキングされたビューにも適用されます。

ソート・メニューとツールチップは個別にカスタマイズされます。詳細は、第65.5項「ソート・メニューおよびツールチップのカスタマイズ」を参照してください。

どのビューが指定のモードでデフォルトで開くかは、構成設定とユーザーの検索習慣にかかっています。たとえば、ドッキング解除済モードでのデフォルト・ビューとしてサムネイル表示を設定した場合、ユーザーがドッキング解除済モードで最初に検索を実行するときにサムネイル表示が開き、リスト表示に切り替えるまでサムネイル表示が開かれたままになります(ブラウザのCookieが消去されるまで、検索によりユーザーの選択内容が記憶されます)。

図65-1 リスト表示のカスタマイズ可能な機能

リスト表示のカスタマイズ可能な機能は次のとおりです。

- 返されるアイテムの最大数

- ページ当たりの行数

- 表示するフィールド(列)

- 列の表示名

- 列幅

- 日付とその他のフィールドのフォーマット

- デフォルトのソート・フィールドとソート順

- ソート・メニュー(ドッキング・モード)

- コンテキスト(右クリック)メニュー

- ツールチップ(ドッキング・モード)

図65-2 サムネイル表示のカスタマイズ可能な機能

サムネイル表示のカスタマイズ可能な機能は次のとおりです。

- 返されるアイテムの最大数

- ページ当たりの行数

- 特殊なサムネイルを表示するアセット・タイプ

- 表示するフィールド

- 日付とその他のフィールドのフォーマット

- デフォルトのソート・フィールドとソート順

- ソート・メニュー

- コンテキスト(右クリック)メニュー

- ツールチップ(ドッキング・モード)

65.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の下に配置して、図65-1および図65-2の変更を実現してください。エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfigおよびUI/Layout/CenterPane/Search/View/SearchToolTipHtmlをそれぞれ使用して、ソート・メニューやツールチップなどの、個々の機能をカスタマイズすることもできます。

エレメントの包括的なリストについては、第65.1.4項「検索ビューの構成エレメント」を参照してください。

65.1.4 検索ビューの構成エレメント

この項では、検索ビューのカスタマイズに使用するJSPエレメントについて概説します。

- システム定義の構成エレメント: 検索ビューおよびグローバルな検索、またはサイト、アセット・タイプ、サイトとアセット・タイプの両方に固有の検索をカスタマイズするには、同じ名前を付けたエレメントを構成します。カスタマイズしたエレメントのすべてをCustomElementsの下に格納する必要があります(例については、図65-3を参照してください)。エレメントの概要については、次の表を参照してください。

- 表65-1に、使用準備済のドッキングされていないビューを定義するシステム定義の構成エレメント(エレメント名のすべてがConfigで終わる)を示します。

- 表65-2に、使用準備済のドッキングされたビューを定義するシステム定義の構成エレメント(エレメント名のすべてがConfigで終わる)を示します。

- 表65-3に、ソート・メニューやツールチップなど、検索ビューの個々の機能をカスタマイズするためのシステム定義のエレメント(エレメント名がConfigまたはHtmlで終わる)を示します。

- カスタム・エレメント: 表65-4に、WebCenter Sitesに同梱されている、カスタマイズ・コードを例示するためのサンプル・カスタム・エレメントを示します。

表65-1 ドッキングされていない検索ビューの構成エレメント

構成エレメント(JSP)へのパス

説明

…を参照

UI/Layout/CenterPane/Search/SearchResultsConfig

ドッキング解除済モードにあるデフォルトの検索ビュー(リスト表示またはサムネイル表示)を設定するエレメント。

第65.3.2項「デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定」

UI/Layout/CenterPane/Search/View/ListViewConfig

ドッキングされていないリスト表示を構成するエレメント。

第65.3.3項「ドッキングされていないリスト表示のカスタマイズ」

UI/Layout/CenterPane/Search/View/ThumbnailViewConfig

ドッキングされていないサムネイル表示を構成するエレメント。

第65.3.4項「ドッキングされていないサムネイル表示のカスタマイズ」

表65-2 ドッキングされた検索ビューの構成エレメント

構成エレメント(JSP)へのパス

説明

…を参照

UI/Layout/CenterPane/Search/DockedSearchResultsConfig

ドッキング・モードにあるデフォルトの検索ビュー(リスト表示またはサムネイル表示)を設定するエレメント。

第65.2項「カスタマイズ・プロセス」

UI/Layout/CenterPane/Search/View/DockedListViewConfig

ドッキングされたリスト表示を構成するエレメント。

第65.2項「カスタマイズ・プロセス」

UI/Layout/CenterPane/Search/View/DockedThumbnailViewConfig

ドッキングされたサムネイル表示を構成するエレメント。

第65.2項「カスタマイズ・プロセス」

表65-3 検索ビューの他の機能の構成およびプレゼンテーション・エレメント

構成エレメント(JSP)へのパス

説明

…を参照

UI/Layout/CenterPane/Search/View/SearchTopBarConfig

ドッキングされたリスト、ドッキングされていないサムネイルおよびドッキングされたサムネイル表示のソート・ドロップダウン・メニューのソート・オプションとしてフィールドを構成するエレメント。

第65.5.1項「ソート・メニューのカスタマイズ」

UI/Layout/CenterPane/Search/View/SearchToolTipHtml

ドッキングされたビュー(リストおよびサムネイル)のツールチップを構成するエレメント。このエレメントにより、ツールチップの外観とカスタム・メッセージを構成できます。

第65.5.2項「検索結果のツールチップのカスタマイズ」

UI/Config/GlobalHtml

コンテキスト(右クリック)メニューを構成するエレメント。このエレメントは、すべての検索ビューに対して有効です。

第65.5.3項「コンテキスト・メニューのカスタマイズ」

表65-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サンプル・サイトのドッキングされたサムネイル表示の構成エレメント。

65.2 カスタマイズ・プロセス

ドッキング解除済モードおよびドッキング・モードでビューをカスタマイズする場合、類似した手順を実行します。主な違いは次のとおりです。

- ドッキングされてないビューおよびドッキングされたビューのカスタマイズ:
ドッキングされていないビューをカスタマイズする場合は、第65.3項「ドッキングされていないビューのカスタマイズ」の手順に従い、その項で示すように構成エレメント(JSP)に名前を付けます(表65-1にも記載されています)。ドッキングされたビューをカスタマイズする場合も、第65.3項「ドッキングされていないビューのカスタマイズ」の手順に従いますが、表65-2に示すように構成エレメントに名前を付けます(つまり、Docked接頭辞を付けます)。

- 検索ビューのソート・メニューおよびツールチップのカスタマイズ:
ソート・メニューおよびツールチップを作成するエレメントは、ドッキング解除済モードおよびドッキング・モードの両方に適用されます。モードに関係なく、表65-3(および第65.5項「ソート・メニューおよびツールチップのカスタマイズ」)に示すように、エレメントに名前を付けます。

- ドッキングされたリスト表示またはドッキングされたサムネイル表示でフィールドを表示する場合:
デフォルトで、UI/Layout/CenterPane/Search/View/DockedListViewConfigエレメントは、UI/Layout/CenterPane/Search/View/ListViewConfigエレメントを指し、最初のリストされたフィールドのみを取得して、ドッキングされたリスト表示でその名前を表示します。フィールドは、最初の<field>プロパティで、次のように定義されます。

<field>
<fieldname>fieldname</fieldname>
<displayname>DisplayName</displayname>

ドッキングされたリスト表示で他のフィールド名を表示する場合は、カスタムDockedListViewConfig.jspエレメントでその名前を指定する必要があります。同じロジックは、ドッキングされたサムネイル表示のフィールド名の表示に適用されます(構成エレメントがThumbnailViewConfigおよびDockedThumbnailViewConfigと名付けられることを除く)。

65.3 ドッキングされていないビューのカスタマイズ

ドッキングされていないリスト表示およびサムネイル表示のカスタマイズには、同じ名前を付けた独自のエレメントを構成し、それらをCustomElementsの下に配置して、表65-1に示されているシステム定義のエレメントをオーバーライドすることが関係しています。

この項の内容は、次のとおりです。

- 第65.3.1項「ドッキングされていないビューのカスタマイズの基本手順」

- 第65.3.2項「デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定」

- 第65.3.3項「ドッキングされていないリスト表示のカスタマイズ」

- 第65.3.4項「ドッキングされていないサムネイル表示のカスタマイズ」

65.3.1 ドッキングされていないビューのカスタマイズの基本手順

ドッキングされていないビューをカスタマイズするには、次の手順の任意の組合せを実行します。

- すべてのアセット・タイプまたは選択したアセット・タイプに対して、デフォルトのドッキングされていないビューをリストまたはサムネイルとなるように設定します。ビューを設定するには、第65.3.2項「デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定」に示すように、エレメントUI/Layout/CenterPane/Search/SearchResultsConfigをオーバーライドします。

- ドッキングされていないリスト表示またはサムネイル表示(あるいはその両方)を構成します。ビューに表示される列数の指定、列名と列幅の構成、返されるアイテムのソート順の指定などを行うことができます(図65-1および図65-2を参照)。

- リスト表示を構成するには、第65.3.3項「ドッキングされていないリスト表示のカスタマイズ」で説明しているように、エレメントUI/Layout/CenterPane/Search/View/ListViewConfigをオーバーライドします。

- サムネイル表示を構成するには、第65.3.4項「ドッキングされていないサムネイル表示のカスタマイズ」で説明しているように、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigをオーバーライドします。

- ビューのソート・メニューなど、追加機能を構成します。この手順では、ビュー自体ではなく、ビューの機能(ソート・メニューなど)に固有のJSPエレメントを構成します。詳細は、第65.5項「ソート・メニューおよびツールチップのカスタマイズ」を参照してください。

65.3.2 デフォルトのドッキングされていないビューのリストまたはサムネイルへの設定

デフォルトの検索ビュー(リストまたはサムネイル)を設定する場合、すべてのアセット・タイプに対してグローバルに設定できます。選択したアセット・タイプに対してデフォルトの検索ビューを指定することもできます。

デフォルトの検索ビューを設定するには:

CustomElementsの下に独自のSearchResultsConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/SearchResultsConfigをオーバーライドします。

次に、UI/Layout/CenterPane/Search/SearchResultsConfigエレメントを示します。表65-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>

表65-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つ以上のアセット・タイプに対してデフォルト・ビューを選択的に構成するために使用します。

なし

<assettype id= name= >

アセット・タイプおよびそのデフォルト・ビューの指定に使用します(ユーザーが別のビューに切り替えるか、またはブラウザのCookiesを消去するまで、そのままの状態になります)。

必要な数のアセット・タイプを指定できます(<assettype>当たり1つ)。

<assettype id="unique_identifier" name="AssetTypeName"> listview | thumbnailview </assettype>

65.3.3 ドッキングされていないリスト表示のカスタマイズ

リスト表示をカスタマイズする場合は、返されるコンテンツのタイプとそのプレゼンテーションを設定できます。

ドッキングされていないリスト表示をカスタマイズするには:

CustomElementsの下に独自のListViewConfig.jspを作成し、そのプロパティをカスタマイズすることによって、UI/Layout/CenterPane/Search/View/ListViewConfigエレメントをオーバーライドします。

次に、UI/Layout/CenterPane/Search/View/ListViewConfigエレメントを示します。表65-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>

表65-6 UI/Layout/CenterPane/Search/View/ListViewConfigのプロパティ

プロパティ

説明

値

<numberofitems>

検索によって返されるアイテムの最大数。

0より大きい整数。

注意: -1を入力した場合は、検索基準に一致するすべての結果が返されます。

<numberofitemsperpage>

検索結果に必要なページ当たりの行数。

100がデフォルトです。

<defaultsortfield>

検索結果をフェッチする場合に検索によってソートされる必要があるデフォルト・フィールド。

デフォルトは空です。したがって、検索結果は関連性を基準に表示されます。他のフィールドをソート用にデフォルトとして設定する必要がある場合は、このエレメントを構成します。

<defaultsortorder>

検索で使用されるソート順。

ascending | descending

<defaultsortfield>が指定されている場合にのみ必要です。

<fields>

リスト表示で表示される列。これらの列は、<fields>にリストされているのと同じ順序で表示されます。

注意: アセット・タイプ固有の構成を作成し、検索結果にアセット・タイプ固有の属性を表示する場合は、アセット・タイプ索引と属性検索を有効にする必要があります。詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- 検索索引へのアセット・タイプの追加

- アセット・タイプ索引に対する属性の構成

この手順をスキップする場合は、検索によりグローバル索引が使用されます。

なし

<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は、ツールチップをレンダリングし、このプロパティの値を使用して、そのツールチップに関連するフィールド名をリストするかどうか(フィールド値もリストされる)を決定します。ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。手順は、第65.5.2項「検索結果のツールチップのカスタマイズ」を参照してください。

true | false

<dateformat>

日付フィールドにのみ適用されます。これは、日付がjavadateformat以外のフォーマットで表示される必要がある場合にカスタム日付フォーマットを指定するオプションです。

有効な日付フォーマット文字列。

注意: <dateformat>が使用される場合、<javadateformat>より優先されます。

<javadateformat>

日付フィールドにのみ適用されます。

有効な値は、SHORT、MEDIUM、LONGおよびFULLです。

注意: <javadateformat>が省略されるか、空白のままにされる場合、デフォルトでSHORTが使用されます。<dateformat>が使用される場合は、<javadateformat>より優先されます。

65.3.4 ドッキングされていないサムネイル表示のカスタマイズ

サムネイル表示をカスタマイズする場合は、返されるコンテンツのタイプとそのプレゼンテーションを設定できます。

ドッキングされていないサムネイル表示をカスタマイズするには:

CustomElementsの下に独自のThumbnailViewConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigをオーバーライドします。

次に、UI/Layout/CenterPane/Search/View/ThumbnailViewConfigエレメントを示します。表65-7のプロパティの説明が続きます。

注意:

<formatter>および<assettypes>は、特に注意を要します。エレメントUI/Layout/CenterPane/Search/View/ThumbnailViewConfigはUI/Layout/CenterPane/Search/View/ListViewConfigとほとんど同じですが、<formatter>プロパティは異なる方法で定義されます。また、<assettypes>はThumbnailViewConfigの専用のプロパティで、サムネイルのレンダリングに使用されます。

<assettypes>プロパティは、その使用法が例示されている、第65.3.4.1項「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>

表65-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 Fusion Middleware WebCenter Sites管理者ガイド』の次の項を参照してください。

- 検索索引へのアセット・タイプの追加

- アセット・タイプ索引に対する属性の構成

この手順をスキップする場合は、検索によりグローバル索引が使用されます。

なし

<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>プロパティの値を使用して、そのツールチップに関連するフィールドをリストするかどうか(フィールド値もリストされる)を決定します。ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。手順は、第65.5.2項「検索結果のツールチップのカスタマイズ」を参照してください。

true | false

<assettypes>

このセクションでは、特殊なサムネイルが表示されるアセット・タイプを指定します。各アセット・タイプには、コンテンツがサムネイルとしてレンダリングされる属性がある必要があります。

このセクションをいつカスタマイズする必要があるかの詳細は、第65.3.4.1項「ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細」を参照してください。

なし

<assettype id= >

特殊なサムネイルが表示されるアセット・タイプを記述します。

<assettype id="unique_identifier">

<type>

サムネイルがレンダリングされるアセット・タイプの名前。

詳細は、第65.3.4.1.2項および第65.3.4.1.3項を参照してください。

<subtype>

アセット・タイプのサブタイプ。

詳細は、第65.3.4.1.2項および第65.3.4.1.3項を参照してください。

<element>

<attribute>で指定されるコンテンツをサムネイルとしてレンダリングするコントローラ・エレメントへのパス。

詳細は、第65.3.4.1.2項および第65.3.4.1.3項を参照してください。

注意: エレメントを指定しない場合は、images/searchディレクトリに保存されている静的なアイコンのレンダリングに、システム定義のエレメントUI/Layout/CenterPane/Search/View/GlobalThumbnailが使用されます。詳細は、第65.3.4.1.1項を参照してください。

<attribute>

コンテンツがサムネイルとして表示される属性。

詳細は、第65.3.4.1.2項および第65.3.4.1.3項を参照してください。

65.3.4.1 ThumbnailViewConfigエレメントの<assettypes>セクションに関する詳細

表65-7に記載されている<assettypes>セクションは、カスタマイズを選択した機能によっては、構成する必要がある場合があります。次の様々な<assettypes>構成シナリオでは、最も一般的に実行されるカスタマイズを対象に説明します。

この項の内容は、次のとおりです。

- 第65.3.4.1.1項「静的アイコンを使用する場合」

- 第65.3.4.1.2項「システム定義のイメージ・サムネイル・エレメントを再使用する場合」

- 第65.3.4.1.3項「カスタム・サムネイルレンダリング・エレメントを使用する場合」

65.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ディレクトリでアイコンを検索するようにコード化されています。アセット・タイプおよびサブタイプに基づいたアイコンの名前を付けると、そのタイプおよびサブタイプのアセットにアイコンが自動的に関連付けられます。

65.3.4.1.2 システム定義のイメージ・サムネイル・エレメントを再使用する場合

ThumbnailViewConfig.jspエレメントの<assettypes>セクションのカスタマイズは、システム定義のエレメントImageThumbnailHtml.jspを再使用して、カスタム・イメージをサムネイルとして動的にレンダリングする場合に必要です。このエレメントは、特定のアセット・タイプまたはサブタイプ(あるいはその両方)に属するイメージ属性に関連付けられているイメージを処理します。

システム定義のImageThumbnailHtml.jspを再使用するには:

カスタムThumbnailViewConfig.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へのパスを指定します。

65.3.4.1.3 カスタム・サムネイルレンダリング・エレメントを使用する場合

ThumbnailViewConfig.jspの<assettypes>セクションのカスタマイズは、アセット・タイプ(またはサブタイプ)のblob属性のコンテンツをサムネイルとして動的にレンダリングするカスタム・エレメントを使用する場合に必要です。

後述の例では、ビデオ・サムネイルのレンダリングで一緒に使用するエレメントを作成します。図65-3に、この項の手順に従って再現できる、サンプル・ビデオ・サムネイル表示を示します。

図65-3 サンプル・ビデオのサムネイル表示

次の手順では、(1)ビデオ・サムネイルを動的にレンダリングするために一緒に使用するエレメントの作成用ガイドライン、(2) ThumbnailViewConfigエレメントの<assettypes>セクションのカスタマイズ用ガイドラインを示します。

注意:

このサンプルを正しく動作させるため、blob属性を持つアセットが存在していること、またそのblob属性のビデオ・ファイルがサイトのディレクトリにアップロードされていることを確認します。

ビデオ・ファイルを再生するには、ブラウザ・プラグインを使用可能にしておく必要があります。

ビデオ・サムネイルをレンダリングするエレメントを作成するには:

1. AssetAPIを使用するビデオ・サムネイルActionエレメントを記述して、そのエレメントで指定されるビデオ属性のBlobUtilを使用して、blobのURLを取得します。(エレメントには任意の名前を付けることができますが、Actionで終わる必要があります。エレメントは、CustomElementsの下のディレクトリに格納される必要があります。)

VideoThumbnailAction.jspという名前のサンプル・エレメントは、search_view_elementsフォルダのmisc\Samples\UICustomization\sample_elements.zipファイルにあるWebCenter Sitesディストリビューションから入手可能です。

2. ビデオ・サムネイルHtmlエレメントを記述します。このエレメントは前の手順で作成したURLをとり、サムネイルの下にビデオおよび他のアセット詳細をレンダリングします。(エレメントには任意の名前を付けることができますが、Htmlで終わる必要があります。エレメントは、CustomElementsの下のディレクトリに格納される必要があります。)このHtmlエレメントは、手順1のActionエレメントをコールします。
VideoThumbnailHtml.jspという名前のサンプル・エレメントは、search_view_elementsフォルダのmisc\Samples\UICustomization\sample_elements.zipファイルにあるWebCenter Sitesディストリビューションから入手可能です。

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という名前のサンプル・エレメントは、search_view_elementsフォルダのmisc\Samples\UICustomization\sample_elements.zipファイルにあるWebCenter Sitesディストリビューションから入手可能です。

65.4 ドッキングされたビューのカスタマイズ

ドッキングされたビューをカスタマイズする方法は、ドッキングされていないビューをカスタマイズする方法と類似しています。主な違いは、第65.2項「プロセスのカスタマイズ」で概述されています。

65.5 ソート・メニューおよびツールチップのカスタマイズ

この項で説明される機能は、表65-8に示すように、ドッキングされていないビュー、ドッキングされたビュー、またはその両方に対してカスタマイズできます。

この項の内容は、次のとおりです。

- 第65.5.1項「ソート・メニューのカスタマイズ」

- 第65.5.2項「検索結果のツールチップのカスタマイズ」

- 第65.5.3項「コンテキスト・メニューのカスタマイズ」

表65-8 検索ビューの他の機能のカスタマイズ

カスタマイズ・オプション

ドッキングされていないリスト

ドッキングされていないサムネイル

ドッキングされたリスト表示

ドッキングされたサムネイル

…を参照

ソート・メニュー

いいえ

はい

はい

はい

第65.5.1項

検索結果のツールチップ

いいえ

いいえ

はい

はい

第65.5.2項

コンテキスト・メニュー

はい

はい

はい

はい

第65.5.3項

65.5.1 ソート・メニューのカスタマイズ

ソート・メニューは、表65-8にリストされているビューに対してのみカスタマイズできます。ソート・メニューにどのソート・フィールドを表示するかを指定できます。各フィールドのソート順序を指定することもできます。

ソート・メニューをカスタマイズするには:

CustomElementsの下に独自のSearchTopBarConfig.jspを作成し、そのプロパティをカスタマイズすることによって、エレメントUI/Layout/CenterPane/Search/View/SearchTopBarConfigをオーバーライドします。

次に、UI/Layout/CenterPane/Search/View/SearchTopBarConfigエレメントを示します。表65-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>

表65-9 UI/Layout/CenterPane/Search/View/SearchTopBarConfigのプロパティ

プロパティ

説明

値

<sortfield id= >

検索結果をソートする検索索引フィールドを記述します。

id=unique_identifier

<fieldname>

検索索引フィールドの名前。

注意: 複数のソート順序を提供するために、同じフィールドを複数回繰り返すことができます。

前述のコードのnameなど。

<displayname>

ユーザーが読取り可能なフィールドの表示名。

前述のコードのNameなど。

<sortorder>

ソート順。

ascending | descending

65.5.2 検索結果のツールチップのカスタマイズ

ツールチップは、ドッキングされたビューに対してのみカスタマイズできます。ドッキングされたビューは、制限されたスペース内に表示されるため、検索結果として返されるアセットに関する情報量が限定されます。ツールチップは、返されたアセットに関する詳細情報を表示する方法です。たとえば、図65-4に示すように、すでにドッキング・モードで表示されている内容に加え、フィールド名と値を表示するためにツールチップをカスタマイズできます。カスタム・メッセージを表示するためにツールチップをカスタマイズしたり、ツールチップの外観を変更することもできます。

図65-4 ドッキングされていないリスト表示のツールチップ

ドッキングされた検索結果のデフォルトのツールチップは、エレメントUI/Layout/CenterPane/Search/View/SearchToolTipHtmlでレンダリングされます。このエレメントは、(図65-4に示すように)ツールチップをボックスとしてレンダリングします。ボックス内で、UI/Layout/CenterPane/Search/View/ListViewConfig(またはUI/Layout/CenterPane/Search/View/ThumbnailViewConfig)の<fields>セクションの各フィールドの名前をレンダリングしますが、これはフィールドの<displayintooltip>プロパティがtrueに設定されている場合にのみ実行されます。たとえば、<displayintooltip>がtrueに設定されている場合は、次のListViewConfig.jspのName、TypeおよびModifiedフィールドが、図65-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>

65.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>

66 Contributorインタフェース: グローバル・プロパティ、ツールバーおよびメニュー・バーのカスタマイズ

この章では、グローバル構成エレメントであるUI/Config/GlobalHtmlについて説明します。また、グローバル・エレメントでWebCenter Sites Contributorインタフェースに対して定義した機能をカスタマイズする方法についても示します。

この章は、次の項が含まれています。

- 第66.1項「グローバル構成プロパティのカスタマイズ」

- 第66.2項「ツールバーのカスタマイズ」

- 第66.3項「メニュー・バーのカスタマイズ」

- 第66.4項「コンテキスト・メニューのカスタマイズ」

66.1 グローバル構成プロパティのカスタマイズ

グローバル構成プロパティは、コンテンツ管理サイト全体にContributorインタフェースの表示条件を設定するために使用します。

この項の内容は、次のとおりです。

- 第66.1.1項「構成プロパティの概要」

- 第66.1.2項「デフォルト構成プロパティの変更」

- 第66.1.3項「カスタム構成プロパティの追加」

66.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オブジェクトには、クライアント側アプリケーションが期待するプロパティを設定することにより、関数本体で自由に操作できます。

また、次に説明するように、クライアント側アプリケーションはサーバー側から追加の構成プロパティを取得できるため、複数の場所にグローバル・プロパティを重複させることなく、複数のソースから設定をマージできます。

66.1.2 デフォルト構成プロパティの変更

表66-1は、システム定義の構成プロパティについて説明し、どのプロパティが変更可能であるかを示しています。

表66-1 UI/Config/GlobalHtmlの構成プロパティ

プロパティ名

説明

値および例

maxTabCount

同時に開いたままにできるタブの最大数。タブとは、開かれたアセットのタブのことです。

0より大きい整数。

例: config.maxTabCount = 30;

enableContextMenu

ユーザーがWebモードで作業する場合に、デフォルトのブラウザ・コンテキスト(右クリック)メニューを有効にする必要があるかどうかを示します。

true | false

例: config.enableContextMenu = true;

enableWebMode

Webモードを有効にする必要があるかどうかを示します。このプロパティをfalseに設定すると、フォーム・モードでのみアセットが操作可能になり、プレビュー機能が使用できます。

デフォルトでは、このプロパティは、futuretense_xcel.iniにあるxcelerate.enableinsiteプロパティの値をとります。

true | false

例: config.enableWebMode = true;

enableDatePreview

日付ベースのプレビューを有効にする必要があるかどうかを示します。

デフォルトでは、このプロパティは、futuretense_xcel.iniにあるcs.sitepreviewプロパティの値をとります。

true | false

例: config.enableDatePreview = false;

enablePreview

プレビューが許可されるかどうかを示します。

デフォルトでは、このプロパティは、「サイトの編集」フォームの「プレビュー方法」属性の値をとります(管理者インタフェースからアクセス可能: 「管理」タブを選択して「サイト」を開き、「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

ビューのタイプごとに、このプロパティは、使用可能なツールバー・アクションのリストを定義します。

第66.2項「ツールバーのカスタマイズ」を参照してください。

toolbarButtons

特定のツールバー・ボタンの動作の定義に使用します。

第66.2.2.3項「カスタム・アクションを使用したツールバーのカスタマイズ」を参照してください。

menubar

メニュー・バーで使用可能なアクションのリストを定義します。

第66.3項「メニュー・バーのカスタマイズ」を参照してください。

documents

ドキュメントの使用可能な実装を登録します。

このプロパティの値は変更しないでください。

サポートされる値はassetのみです。

views

ビューの実装を登録します。

このプロパティの値は変更しないでください。

controllers

コントローラの実装、および各コントローラでサポートされるアクションのセットを登録します。

このプロパティの値は変更しないでください。

roles

現在ログインしているユーザーのロールのリストが含まれます。

このプロパティの値は変更しないでください。

supportedTypes

Contributorインタフェースから編集可能なアセット・タイプのリストが含まれます。

このプロパティの値は変更しないでください。

searchableTypes

Contributorインタフェースから検索可能なアセット・タイプのリストが含まれます。

このプロパティの値は変更しないでください。

token

バイナリ・ファイルをアップロードする際のセキュリティ保護に使用します。

このプロパティの値は変更しないでください。

sessionid

バイナリ・ファイルをアップロードする際のセキュリティ保護に使用します。

このプロパティの値は変更しないでください。

contextMenus

コンテキスト・メニューで使用可能なアクションのリストを定義します。

第66.4項「コンテキスト・メニューのカスタマイズ」を参照してください。

66.1.3 カスタム構成プロパティの追加

UI/Config/GlobalHtmlに格納されているグローパル・プロパティを取得するほかに、Contributorアプリケーションは、UI/Config/SiteConfigの追加設定およびUI/Configに存在するエレメントを取得しようとします。要件によっては、UI/Config/GlobalHtmlに定義されているすべてのプロパティをレプリケートせずに、グローパル・プロパティまたはサイト固有のプロパティを設定できます。

この項の内容は、次のとおりです。

- 第66.1.3.1項「カスタム・グローバル・プロパティの追加」

- 第66.1.3.2項「サイト固有のプロパティの追加」

66.1.3.1 カスタム・グローバル・プロパティの追加

カスタム・グローバル・プロパティは、指定されたコンテンツ管理システム上のすべてのサイトで共有されます。推奨されるアプローチは、次のように定義されたカスタム構成エレメントを作成することです。

- プレゼンテーション・エレメント名は、UI/Config/SiteConfigHtmlである必要があります。

- エレメント・コードは、第66.1.1項「構成プロパティの概要」に示すパターンに従う必要があります。

たとえば、次の操作を実行します。

- すべてのサイトの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>

66.1.3.2 サイト固有のプロパティの追加

Contributorインタフェースは、コンテンツ管理サイトごとに異なる方法で構成する必要がある場合があります。推奨されるアプローチは、次のようなエレメントを作成して、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の元の値が保持されます。

66.2 ツールバーのカスタマイズ

ツールバーは、Webモードまたはフォーム・モードのアセット上で動作するアクションをリストするようにカスタマイズできます。ツールバーは、アセット・タイプおよびサブタイプごとに詳細にカスタマイズできます。

この項の内容は、次のとおりです。

- 第66.2.1項「ツールバー・カスタマイズの概要」

- 第66.2.2項「ツールバー・カスタマイズの例」

66.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などの標準アクションの場合、アクション名は、指定されたアイコン、タイトル、代替テキストなどに自動的にマッピングされます。標準アクション、カスタム・アクション、またはカスタム・ボタンの外観のカスタマイズ方法の詳細は、第66.2.2項「ツールバー・カスタマイズの例」を参照してください。

view_mode_iは、ビューによってサポートされているモードのいずれかです(通常はeditまたはview)。

66.2.2 ツールバー・カスタマイズの例

この項の内容は、次のとおりです。

- 第66.2.2.1項「Webモード用の標準アクションを使用したツールバーのカスタマイズ」

- 第66.2.2.2項「アセット・タイプおよびサブタイプ用の標準アクションを使用したツールバーのカスタマイズ」

- 第66.2.2.3項「カスタム・アクションを使用したツールバーのカスタマイズ」

66.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(ビュー・コントローラによってサポートされているすべてのアクション)。

66.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ページ・アセットを調査すると、次のツールバーが表示されます。

注意:

次のことに注意してください。

- viewモードのみをカスタマイズします。Page/AVISectionアセットがWebモードで編集されている場合、標準ツールバーが表示されます。

- 「ブックマーク」および「ブックマーク解除」ボタンは同時には表示されません。これらは両方とも、アセットの現在の状態(すでにブックマークを付けているかどうか)に依存しているからです。

66.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
}

注意:

この例では、セパレータ(垂直線)とカスタム・ボタンをツールバーの末尾に追加しています。

より複雑な例では、現在のアセットのidおよびタイプの取得、メッセージ領域でのフィードバックの提供が行われます。

config.toolbarButtons.helloWorld = {
src: 'js/fw/images/ui/ui/toolbarButton/smartlist.png',
onClick: function () {
var doc = SitesApp.getActiveDocument(), // the document in the active tab
asset = doc.get('asset'),                 // the asset object
view = SitesApp.getActiveView();    // the active view

view.info('Hello World!! The asset is a ' + asset.type +  ' with id: '
+ asset.id);

}
}

66.3 メニュー・バーのカスタマイズ

メニュー・バーは、特定のタイプまたはタイプ/サブタイプのアセット上で動作するメニューをサポートするようにカスタマイズできます。サブメニューには、アクション可能なアイテム、追加メニューまたはメニュー・セパレータを指定できます。

この項の内容は、次のとおりです。

- 第66.3.1項「メニュー・バー・カスタマイズの概要」

- 第66.3.2項「カスタム・アクションのメニュー・バーへの追加」

66.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などの、コントローラによってサポートされるアクションまたはカスタム・クリック・ハンドラを指定できます(第66.3.2項「カスタム・アクションのメニュー・バーへの追加」のカスタマイズ例を参照)。

注意:

指定されたアクションが現在のドキュメント/ビューでサポートされていない場合、メニューに無効化されて表示されます(グレー表示されます)。

たとえば、saveアクションをトリガーするメニュー・アイテムは、次のように定義されます。

{
label: "Save",
action: "save"
}

- 遅延ポップアップ・メニュー(ポップアップ・メニューは、サーバー側でコントローラ・エレメントを実行することによって動的に決定される)。

- labelは、メニュー・アイテムの表示名を指定します。

- deferredは、UI/Data/StartMenu/Newなど、コントローラのエレメント名を指定します。

- cacheは、コントローラ・エレメントの出力がキャッシュされる必要があるかどうかを示すブール値です。

たとえば、現在のサイト/ユーザーのすべての使用可能なスタート・メニュー・アイテムを読み取る「新規」ポップアップ・メニューは、次のように定義されます。

{
label: New,
deferred: "UI/Data/StartMenu/New",
cache: true
}

- ポップアップ・メニュー(子メニュー・アイテムが構成自体にハード・ワイヤリングされる)。

- メニュー・アイテム・セパレータ(横線、メニュー・エントリをグループ化するために使用する)。

66.3.2 カスタム・アクションのメニュー・バーへの追加

この例では、(カスタムonClickハンドラを実行するため)第66.2.2.3項「カスタム・アクションを使用したツールバーのカスタマイズ」で定義したhelloWorldカスタム・アクションをメニュー・バーに追加します。このアクションを追加するには、カスタム・アクションをトリガーする、Hello Worldという単一メニュー・アイテムを使用して、Custom Menuというメニュー・バーに新しいエントリを追加します。この手順は次のとおりです。

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!");
}
}]
});

Custom Menuが、AVISectionページ・セクションと一緒に表示されるようになります。

Hello Worldメニュー・アイテムを選択すると、次のようなカスタム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
}]
});

66.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"]

67 Contributorインタフェース: アセット・フォームのカスタマイズ

この章では、WebCenter SitesのContributorインタフェースでアセット・フォームに適用できるカスタマイズについて説明します。また、一部のサポートされているデータ型の単一値または複数値の属性エディタを作成するための手順を追った説明も示します。

この章は、次の項が含まれています。

- 第67.1項「アセット・フォームのカスタマイズの概要」

- 第67.2項「アセット・フォームのヘッダーの変更」

- 第67.3項「属性エディタの構築」

67.1 アセット・フォームのカスタマイズの概要

Contributorインタフェースのアセット・フォームで2つのタイプのカスタマイズを実行できます。1つ目のタイプでは、アセット・フォームのヘッダーを変更できます。もう一方では、第18.3項「属性エディタのカスタマイズ」で説明するように、既存の属性エディタをカスタマイズするか、または第67.3項「属性エディタの構築」で説明するように、WebCenter Sitesによってサポートされているデータ型のカスタム属性エディタを構築できます。

注意:

Contributorインタフェースの他のコンポーネントとは異なり、アセット・フォームは、Contributorフレームワークにはありません。そのため、アセット・フォームのリクエストは、UIコントローラによって処理されません。

67.2 アセット・フォームのヘッダーの変更

OpenMarket/Xcelerate/AssetType/<AssetTypeName>/ディレクトリのカスタムassettype固有のエレメントを作成することによって、アセット・フォームのヘッダーを変更できます。HTMLページの本文を変更するのではなく、追加のスタイルシートまたはJavaScriptコードを含めることができます。エレメントの名前はHeaderにする必要があります。

67.3 属性エディタの構築

第18.3項「属性エディタのカスタマイズ」の説明に従って、既存の使用準備済の属性エディタの一部で、ルック・アンド・フィールをカスタマイズできます。WebCenter Sitesでサポートされているデータ型のカスタム属性エディタを作成することもできます。

この項では、データ型text、string、integerまたはmoneyの単一値をサポートするカスタム属性エディタを構築する方法について説明します。また、この項では、同じデータ型の複数値属性エディタを実装するためのポインタおよびサンプル・コードも提供します。

注意:

blobまたはassetデータ型のカスタム属性エディタを作成する場合、blob型はUPLOADER属性エディタを、assetデータ型はPICKASSET属性エディタを実装の基準にすることができます。

属性エディタを構築する手順は次のとおりです。

- 第67.3.1項「Dojoウィジェットとそのテンプレートの作成」

- 第67.3.2項「プレゼンテーション・オブジェクトとしての属性エディタの定義」

- 第67.3.3項「属性エディタ・エレメントの作成」

- 第67.3.4項「属性エディタの作成」

- 第67.3.5項「複数値属性エディタの実装」

67.3.1 Dojoウィジェットとそのテンプレートの作成

この項では、データ型text、string、integerまたはmoneyの単一値を処理するDojoウィジェットを作成する方法について説明します。

この項の内容は、次のとおりです。

- 第67.3.1.1項「Dojoウィジェットのテンプレートの作成」

- 第67.3.1.2項「Dojoウィジェットの作成」

67.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>

前述のコードをテンプレートで使用する場合、エンド・ユーザーからの入力を入力ノードが受け取った後、その入力ノードの値は、第67.3.1.2項「Dojoウィジェットの作成」で作成するDojoウィジェットで保持されます。

5. テンプレート・ファイルを保存します。

6. 第67.3.1.2項「Dojoウィジェット」に進みます。

67.3.1.2 Dojoウィジェットの作成

Dojoウィジェットを作成するには:

1. WebCenter Sitesインストールのjs/extensions/dijitディレクトリに移動します。

2. 次の必須機能を実装することにより、dojoウィジェット、たとえば、MyWidget.jsを作成します(例67-1を参照)。

- _setValueAttr: このsetterメソッドは、属性の値を設定します。

- _getValueAttr: このgetterメソッドは、属性値を取得します。

- isValid: このメソッドは、指定された値が有効かどうかを確認するために検証を実行します。

- focus: これは、属性エディタにフォーカスを設定します。

- onChange: このメソッドは、ユーザーが属性の値を更新するたびにコールされます。

- onBlur: このメソッドは、属性値がユーザーによって入力されるときに、ウィジェットを更新します。ユーザーが別のフィールドを選択すると、更新がトリガーされます。

例67-1 Dojoウィジェットのサンプル・コード

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 i.e. 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ウィジェットの作成の詳細は、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. 作業を保存します。

6. 第67.3.2項「プレゼンテーション・オブジェクトとしての属性エディタの定義」に進みます。

67.3.2 プレゼンテーション・オブジェクトとしての属性エディタの定義

この項では、フレックス属性の入力タグ(プレゼンテーション・オブジェクト)を定義する方法について説明します。また、入力タグが属性エディタから表示エレメントへ渡すことができる引数を割り当てる方法を説明します。

属性エディタを定義するには:

1. WebCenter Sitesインストールで、Sites\11gR1\Sites\11.1.1.6.1\presentationobject.dtdファイルに移動します。

2. presentationobject.dtdファイルで、次を実行します。

1. 新しいタグ(プレゼンテーション・オブジェクト)を<!ELEMENT PRESENTATIONOBJECT …>文内のリストに追加します。この例では、新しいタグにはMYATTREDITORという名前が付けられます。
次の行では、MYATTREDITORは、その名前が第67.3.3項「属性エディタ・エレメントの作成」で作成するエレメントの名前に一致するカスタム属性エディタです。他のすべてのタグは使用準備済の属性エディタです。

<!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)>

2. 新しいタグ(プレゼンテーション・オブジェクト)とそれが取得する引数を定義する<!ELEMENT...… >セクションを追加します。この新しいタグには、フォームに表示されるときの対象属性の形式と動作のベースとなるロジックを提供するエレメントが含まれます。MAXALLOWEDCHARSが必須属性としてマークされていることを確認します。

<!ELEMENT MYATTREDITOR ANY>
<!ATTLIST MYATTREDITOR MAXALLOWEDCHARS CDATA #REQUIRED>
<!ATTLIST MYATTREDITOR MAXVALUES CDATA #IMPLIED>

3. presentationobject.dtdファイルを保存して閉じます。

3. 第67.3.3項「属性エディタ・エレメントの作成」に進みます。

67.3.3 属性エディタ・エレメントの作成

この項では、「新規」または「編集」フォームに表示されるときに、属性(単一値)の「編集」ビューを表示するエレメントの作成方法について説明します。このエレメントは、ElementCatalog表のOpenMarket/Gator/AttributeTypesディレクトリに配置される必要があります。エレメント名は、タグで起動できるように、第67.3.2項「プレゼンテーション・オブジェクトとしての属性エディタの定義」で定義したタグの名前と正確に一致している必要があります(この例では、MYATTREDITOR)。

1. ElementCatalogのOpenMarket/Gator/AttributeTypesディレクトリに移動します。

2. 新しいエディタの属性エレメントを作成します(この例では、MYATTREDITOR.jsp。例67-2を参照。)このエレメントの名前がpresentationobject.dtdファイル(第67.3.2項「プレゼンテーション・オブジェクトとしての属性エディタの定義」)で定義したタグ名に一致していることを確認します。

3. 属性エディタがデフォルトでレンダリングされないようにするには、doDefaultDisplay変数をnoに設定します。

4. 属性名を表示するには、エレメントOpenMarket/Gator/FlexibleAssets/Common/DisplayAttributeNameをコールします。コードは次のとおりです。

<ics:callelement
element="OpenMarket/Gator/FlexibleAssets/Common/DisplayAttributeName"/>

5. ウィジェットをレンダリングするには、次のパラメータを使用して、エレメントOpenMarket/Gator/AttributeTypes/CustomTextAttributeEditorをコールします。

- editorName: 第67.3.1.2項「Dojoウィジェットの作成」で作成したウィジェットの名前。この例では、extensions.dijit.MyWidgetです。

- editorParams: この引数は、パラメータのJSON文字列をウィジェットに渡します。この例では、maxAllowedLength値を渡しています。たとえば、値は次のようになります。{ maxAllowedLength: "10" }

- maximumValues: 複数値ウィジェットでのみ必要です。これは、複数値ウィジェットでレンダリング可能な値の最大数です。
単一値ウィジェットの場合、初期化パラメータおよびフォーマット・スタイルを使用した完全なコードは、例67-2「サンプル単一値属性エディタ(MYATTREDITOR)」のコードのようになります。複数値ウィジェットを実装するには、第67.3.5項「複数値属性エディタの実装」を参照してください。

例67-2で指定されるコードを使用する場合、単一値属性エディタは図67-1のエディタのようになります。

図67-1 単一値属性エディタ

注意:

例67-2では、新規属性エディタを使用して単一値属性をレンダリングするために、次のコア・ロジックが実装されます。

<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")にする必要があります。この入力ノード値は、属性を保存するためにサーバーに送信されます。

例67-2 サンプル単一値属性エディタ(MYATTREDITOR)

<%@ 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>

6. 第67.3.4項「属性エディタの作成」に進みます。

67.3.4 属性エディタの作成

この項では、属性エディタ・アセットを作成して、コンテンツ・コントリビュータがコンテンツ管理サイトで使用できるようにする方法について説明します。このアセットは、第67.3.3項「属性エディタ・エレメントの作成」で定義した入力タイプ、たとえば、チェック・ボックス、ラジオ・オプションおよびドロップダウン・リストをサポートします。開発者は、属性を作成または変更する際にこのエディタを選択します。

1. サイトのAdminインタフェースにログインします。

2. 「名前」列の「新規」ページで、「新規属性エディタ」をクリックします。

3. 「名前」フィールドに、エディタのわかりやすい名前を入力します。たとえば、MyAttrEditorと入力します。

4. 「XML」ボックスで、属性エディタのXMLコードを入力します。このコードの属性エディタの名前が、エレメント名とまったく同じであることを確認します。例:

<?XML VERSION="1.0"?>
<!DOCTYPE PRESENTATIONOBJECT >
<PRESENTATIONOBJECT NAME="MYATTREDITOR">
<MYATTREDITOR MAXALLOWEDCHARS="10"> </MYATTREDITOR> </PRESENTATIONOBJECT>

5. 「属性タイプ」ボックスで、適切な値を受け入れます。

6. 「保存」アイコンをクリックします。
図67-2のエディタに類似した属性エディタが、サイトに対して作成されます。

図67-2 サイトのサンプル属性エディタ

7. 第67.3.5項「複数値属性エディタの実装」に進みます。

67.3.5 複数値属性エディタの実装

第67.3.3項「属性エディタ・エレメントの作成」の例67-2には、単一値属性エディタの実装が示されています。text、integer、stringまたはmoneyデータ型の複数値属性エディタを実装するには、例67-3のコードに類似したコードを記述できます。

例67-3 サンプル複数値属性エディタ(CustomTextAttributeEditor)

<%@ 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>

例67-3のコードを使用すると、複数値属性エディタは、図67-3のエディタのようになります。

図67-3 複数値属性エディタ

例67-3に関する次の点に注意してください。

- 単一値ウィジェットを使用して複数値表現をレンダリングする、複数値ウィジェットをインスタンス化できます。

- no値を指定したMultiValueEntry変数は、属性エディタが単一値をレンダリングすることを示します。この変数値をyesに変更すると、属性エディタが複数値をレンダリングできるようになります。

- JSONオブジェクトまたは他の任意の形式の値を受け入れる複数値ウィジェットを実装できます。

- 複数値属性エディタの場合、RenderMultiValuedTextEditorエレメントは、Saveロジックに必要な非表示入力ノードを作成します。各ノードの値はサーバーに送信されます。

- 複数値ウィジェットは、OpenMarket/Gator/AttributeTypes/RenderMultiValuedTextEditorエレメントをコールしてレンダリングされます。その際には、例67-3の次のコードが使用されます。

<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属性エディタを実装の基準にすることができます。

第IV部

Oracle WebCenter Sites: Mobilityの構成

この部では、Oracle WebCenter Sites: Mobilityの構成について説明します。

この部は、次の章で構成されています。

- 第68章「モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成」

68 モバイルWebサイトをサポートするためのOracle WebCenter Sites: Mobilityの構成

Oracle WebCenter Sites: Mobilityは、Mobilityとも呼ばれ、そのユーザーは携帯電話やタブレットなどの様々なモバイル・デバイスにWebサイトを作成、プレビューおよび配信できます。

モバイルが最適化されたWebサイトをサポートするようにMobilityを実装するには、そのフレームワークを構成する必要があります。まず、この章では、主要な概念について説明し、そのフレームワークの主な機能を概説します。構成手順は次のとおりです。

この章には次の項が含まれます。

- 第68.1項「開発者の前提条件」

- 第68.2項「主要なMobilityの概念」

- 第68.3項「Mobility機能を構成するための前提条件」

- 第68.4項「Mobility機能の構成」

- 第68.5項「デバイス検出」

68.1 開発者の前提条件

Mobilityフレームワークを構成するには、サイト・プランやテンプレートなど、WebCenter Sitesのコア機能の使用経験が必要です。また、モバイル・デバイスおよびそのユーザー・エージェントに対する理解が必要です。

68.2 主要なMobilityの概念

WebCenter Sitesは、組込みのデバイス検出メカニズムを使用して、Webサイトのコンテンツを要求するデバイスを識別します。デバイスが識別されると、WebCenter Sitesは適切なサイト・プラン(サイト・ナビゲーション)を検索し、適切なテンプレートを呼び出してWebサイトをレンダリングします。

このデバイス検出プロセスのメカニズムには、デバイス・リポジトリ、デバイス・グループおよび接尾辞、デバイス・アセット、テンプレート・バリアント、サイト・プラン(モバイルWebサイトをサポートできるように拡張されている)などの新機能が関係しています。この項では、これらの新機能の背後にある概念について説明します。その後、モバイルWebサイトをサポートする機能の構成手順も示します。

機能が構成されたら、Contributorインタフェースで、図68-1に示すようなモバイル・サイトを作成し、プレビューおよび配信できます。この図では、avisportsサンプル・サイトのホームページが、3つのデバイスのコンテキストで表示されます(マルチデバイス・プレビュー)。

図68-1 Contributorインタフェースの複数デバイスのコンテキストのavisportサイト・ホームページのプレビュー

この項の内容は、次のとおりです。

- 第68.2.1項「デバイス・リポジトリ」

- 第68.2.2項「デバイス・グループおよび接尾辞」

- 第68.2.3項「デバイス・アセット」

- 第68.2.4項「サイト・プラン」

- 第68.2.5項「モバイル・テンプレート」

68.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には組み込まれていません。

必要なデバイス・リポジトリの使用手順については、第68.4.2項「手順2: デバイス・リポジトリの設定」を参照してください。

68.2.2 デバイス・グループおよび接尾辞

デバイス・グループでは、デバイスの機能ベースのグループ化が可能です。デバイス・グループは、共通のWebサイトが配信可能な、共通の特徴を持つデバイスのコレクションを定義するアセットです。たとえば、図68-2に示すように、すべてのタッチフォンはあるグループに属することができ、ノンタッチ(QWERTY)フォンは別のグループに属することができます。

図68-2 デバイス・タイプベースのグループ化

1つのWebサイトをすべてのタッチ・デバイスに配信できます。また、別のWebサイトをすべてのノンタッチ(QWERTY)デバイスへ配信できます。そのため、2セットのテンプレートをコーディングする必要があります。1セットはタッチ・デバイス・グループ用で、もう1セットはノンタッチ・デバイス・グループ用です。

ここで、接尾辞の概念が関係してきます。接尾辞は、正しいデバイス・グループにテンプレートを関連付けるために使用します。テンプレートおよびデバイス・グループが、_Touch(または_NonTouch)などの、同じ接尾辞を持つ場合に関連付けが行われます。たとえば、基本テンプレートHomeLayoutがデスクトップWebサイトのレンダリングに使用される場合は、テンプレートのバリアント、つまり、HomeLayout_suffixという名前のテンプレートを作成します。この例では、HomeLayout_Touchテンプレートを作成して、タッチ・デバイス・グループのデバイス上のコンテンツをレンダリングし、HomeLayout_NonTouchテンプレートを作成して、ノンタッチ・デバイス・グループのデバイス上のコンテンツをレンダリングします。

実行時に、WebCenter Sitesでは、デバイス・グループの接尾辞がテンプレート・バリアントの名前と照合されます。これにより、HomeLayoutがタッチ・デバイスから要求される場合には、HomeLayout_Touchテンプレートを使用してWebサイトがレンダリングされます。これはデバイス検出の一環です。

注意:

接尾辞のないテンプレートは、基本テンプレートと呼ばれます。接尾辞のあるテンプレートは、基本テンプレートのバリアントと呼ばれます。基本テンプレートは、そのバリアントが作成される前に存在している必要があります。

接尾辞は、デバイス・グループをサイト・プランに関連付けるためにも使用されます。これにより、異なるデバイス・グループ内のデバイスに対して異なるWebサイト・ナビゲーションを実装できます。テンプレートは、配信システムにおけるWebサイト・ナビゲーションを指定するために、device:siteplanタグを使用してコーディングされます。

デバイス・グループを作成するには、タイプDeviceGroupのアセットを作成します。その過程で、次のものを指定します。

- 接尾辞

- 登録されているデバイス名、またはデバイスを作成対象のグループに関連付けるためにWebCenter Sitesで使用される基準のいずれか

注意:

複数のデバイス・グループを作成する場合は、デバイスの検出中に、デバイス・グループへのデバイスのマッチングが適切に行われるように、デバイス・グループに優先順位を付ける必要があります。

デバイス・グループの構成手順については、第68.4.3項「手順3: デバイス・グループの構成」を参照してください。デバイス・グループの優先順位付けの手順については、第68.4.4項「手順4: デバイス・グループに優先順位を付ける」を参照してください。

68.2.3 デバイス・アセット

モバイル・デバイスは、デバイス・アセットで表すことができ、Contributorインタフェースにおけるモバイル・デバイスのコンテキストで、モバイルWebサイト・コンテンツのプレビューが行えます。デバイス・アセットは、プレビューをサポートする目的でのみ使用されます。デバイス・アセットは、デバイスが同じデバイス・グループで収集されるほど類似している場合でも、バリエーションを示します(画面サイズなど)。デバイス・アセットのコンテキストでプレビューすることにより、コンテンツ・コントリビュータは、対応する実デバイス上でコンテンツが正しくレンダリングされることを確認できます。

デバイス・アセットは、イメージとユーザー・エージェントで構成されます。ユーザー・エージェントは、デバイス・アセットを(1)デバイス・リポジトリの実デバイスおよび(2)基準に一致するデバイス・グループに関連付けるために使用します。デバイス・グループとデバイス・アセットの関係を示す関連付けの例については、図68-3を参照してください。

図68-3 デバイス・グループに関連付けられたデバイス

デバイス・アセットは、デバイス検出によってデバイス・グループに関連付けられます。デバイス・アセットが2つ以上のデバイス・グループで指定される基準に一致する場合、デバイス・アセットは希望する(優先順位が最も高い)デバイス・グループに自動的に関連付けられます。デバイスがすべてのデバイス・グループの基準に一致しない場合、デフォルトのデバイス・グループ(デスクトップ・ブラウザへのWebサイトの提供に使用される)に自動的に割り当てられます。デバイスがデバイス・グループに関連付けられたら、そのデバイス・グループに関連付けられているテンプレートがプレビュー・モードでWebサイト・コンテンツをレンダリングできます。コンテンツは、デバイス・イメージ上で上書きされます。

注意:

コンテンツ・コントリビュータが次のプレビュー動作を認識していることを確認してください。

- モバイル・デバイスのWebページのプレビューがすべてのブラウザで機能しているときに、ブラウザとユーザー・エージェント間で不一致がある場合には、一部の機能が正しく表示されません。たとえば、ユーザー・エージェントがAndroid上のFireFoxであるときに、Internet ExplorerでContributorインタフェースを開くと、ブラウザはInternet Explorerエンジンを使用してHTMLをレンダリングします。したがって、Contributorインタフェースのプレビューは、実モバイル・デバイス上の実際のページ表示とは異なる可能性あります。

- プレビューでは、実デバイス上のフルスクリーン・モード表示でページがレンダリングされます。

デバイスの作成手順については、第68.4.5項「手順5: デバイス・アセットの作成」を参照してください。

68.2.4 サイト・プラン

サイト・プランは、Webサイトのナビゲーショナル階層を定義します。たとえば、図68-4は、Contributorインタフェースのavisportsサンプル・サイト用の次のサイト・プラン(Default、TouchおよびNonTouch)を示しています。

図68-4 Contributorインタフェースのサイト・プラン

サイト・プランを作成する場合、共有接尾辞を選択することによって、デバイス・グループをそのサイト・プランに関連付けます。そのサイト・プランによって定義されるサイト・ナビゲーションは、それらのデバイス・グループのデバイスに提供されます。(選択すると、その接尾辞は他のサイト・プランに対して使用できなくなります。)

サイト・プランの作成には、次の2つの基本的な方法があります。

- すべてのデバイス・グループのすべてのデバイスの単一サイト・プランを作成します。

- 複数のサイト・プランを作成します。デバイス・グループごとに異なるサイト・プランを設けることで、異なるナビゲーションが可能になります。コンテンツはサイト・プラン間で再利用することもできれば、サイト・プランごとに変えることもできます。

サイト・プランの構成手順については、第68.4.6項「手順6: サイト・プランの作成」を参照してください。

68.2.5 モバイル・テンプレート

モバイルWebサイトをレンダリングするテンプレートを作成するには、次の2つの基本的な方法があります。

- すべてのモバイル・デバイス(つまり、すべてのデバイス・グループ)に適応する単一セットのテンプレートを作成します。Adaptiveテンプレートは、デバイスの画面解像度に適応し、コンテンツを適切にレンダリングします。このシナリオでは、接尾辞の付いたテンプレートを作成する必要はありません。

- 異なるデバイス・グループ用に異なるテンプレートを作成します。(その例が第68.2.2項「デバイス・グループと接尾辞」で説明されています。)
このシナリオでは、2セットのテンプレートを作成する必要があります。1つのセットには基本テンプレート(接尾辞なし)を含めます。他のセットには、テンプレート・バリアント(接尾辞付きテンプレート)を含めます。テンプレート・バリアントを作成するには、基本テンプレートの名前に_suffixを追加します。

たとえば、接尾辞Touchが付いたiPhonesというデバイス・グループを作成する場合、テンプレートはBaseTemplateName_Touchになります。このネーミング規則、およびデバイス・グループとテンプレートの接尾辞の照合により、WebCenter Sitesで、モバイル・デバイスから適切なテンプレート・バリアントへリクエストがルーティングされるようになります。特定のデバイス・グループにモバイル・テンプレート・バリアントが存在しない場合は、かわりに基本テンプレートが使用されます。

注意:

WebCenter Sitesは2つの接尾辞(_Touch_NonTouchなど)を持つテンプレートを認識しないため、このようなテンプレートは、Contributorインタフェースのアセット・ツールバーのページ・レイアウトの選択オプションを介して使用できません。2つの接尾辞を持つテンプレートを作成すると、このテンプレートは既存のテンプレートのバリアントとは見なされないため、アセットのレンダリングには使用されません。かわりに、基本テンプレートが使用されます。

デバイス・グループを作成し、接尾辞を指定した後はいつでもテンプレート・バリアントを作成できます。テンプレートの作成の詳細は、第68.4.8項「ステップ8: テンプレートの作成」を参照してください。

68.3 Mobility機能を構成するための前提条件

Mobility機能の構成を開始する前に、次の資格証明と情報を持っていることを確認します。

- SiteAdminまたはGeneralAdminのいずれかのロールを持っていること。この章では、GeneralAdminロールを持っていると想定しています。

- 使用するデバイス・リポジトリに対する理解。オプションおよび手順の詳細は、第68.4.2項「手順2: デバイス・リポジトリの設定」を参照してください。

- 異なるデバイスを編成する対象デバイス・グループの名前。

- デバイスを特定し、グループ化するのに使用する機能(ユーザー・エージェント、タッチ、タブレット、画面解像度など)。どのデータを提供するかの詳細は、第68.4.3項「手順3: デバイス・グループの構成」を参照してください。

- どの接尾辞を各デバイス・グループで使用するか。接尾辞は、各デバイス・グループに必要です。(これらのデバイス・グループのテンプレート・バリアントの名前に接尾辞を追加します。サイト・プランに対しても同じ接尾辞を選択します。)

- コントリビュータがモバイルWebサイトのプレビューで使用するデバイスのリスト。WebCenter Sitesは、一般的に使用されている多くのデバイスを表す複数のデバイス・アセットを備えています。
独自のデバイス・アセットを作成する必要がある場合は、最初に実デバイスの独自のイメージを作成して、その実デバイスのユーザー・エージェントを検索します。これらのイメージとユーザー・エージェント情報を使用して、デバイス・アセットを作成します。また、Contributorインタフェースのデバイス・セレクタ・パネルで使用するためにサムネイル・イメージも作成します。

- Webサイトのモバイル・バージョン用の効果的なサイト・プラン。

68.4 Mobility機能の構成

この項の内容は、次のとおりです。

- 第68.4.1項「手順1: 「モビリティ」タブの有効化」

- 第68.4.2項「手順2: デバイス・リポジトリの設定」

- 第68.4.3項「手順3: デバイス・グループの構成」

- 第68.4.4項「手順4: デバイス・グループに優先順位を付ける」

- 第68.4.5項「手順5: デバイス・アセットの作成」

- 第68.4.6項「手順6: サイト・プランの作成」

- 第68.4.7項「手順7: サイト・プランの編成」

- 第68.4.8項「手順8: テンプレートの作成」

68.4.1 手順1 「モビリティ」タブの有効化

「管理」インタフェースの「モビリティ」タブへのアクセスを自動的に付与されるユーザーは、WebCenter Sitesインストール・プロセス中にその資格証明が使用されたユーザーのみです。このユーザーには、MobileSitesDeveloperロールが自動的に割り当てられています。他のユーザーがこのタブを使用するには、MobileSitesDeveloperロールを明示的に割り当てる必要があります。

68.4.2 手順2: デバイス・リポジトリの設定

この手順には、次のデバイス・リポジトリのいずれかを使用するオプションがあります。

- devices.xml
このファイルを使用する場合は、アクティブであることを確認します。手順については、第68.4.2.1項「どのデバイス・リポジトリがアクティブかの判別」を参照してください。

このファイルを変更する必要がある場合は、ファイルを変更して、それをWebCenter Sitesに再度アップロードする必要があります。devices.xmlの設定手順については、第68.4.2.2項「デフォルトのデバイス・リポジトリの変更」を参照してください。

- WURFL
このリポジトリのライセンスされているバージョンをScientiaMobileから取得する必要があります。WebCenter Sitesには組み込まれていません。

WURFLリポジトリは、次の2つの形式のいずれかでアップロードできます。

- WURFl.zip

- WURFL.xml (WURFLパッチ・ファイルと一緒に)。パッチ・ファイルは、WURFL.xmlのコンテンツをオーバーライドするために使用します。パッチ・ファイルの詳細は、http://wurfl.sourceforge.net/を参照してください。WURFLの設定手順については、第68.4.2.3項「サード・パーティ・デバイス・リポジトリのアップロード」を参照してください。

68.4.2.1 どのデバイス・リポジトリがアクティブかの判別

1. 「モビリティ」タブで、「デバイス・リポジトリ」ノードをダブルクリックします。

2. 「デバイス・リポジトリ・アップローダ」フォームで、「デフォルト・リポジトリ」(devices.xmlがアクティブであることを意味する)またはWURFLファイル(複数のファイルのうちのいずれか)のどちらのリポジトリが選択されているかを確認します。

図68-5 デバイス・リポジトリ・アップローダ

3. 次の手順のいずれかに進みます。

- デバイス・リポジトリを変更する必要がある場合は、次の項のいずれかを完了します。

- 第68.4.2.2項「デフォルトのデバイス・リポジトリの変更」

- 第68.4.2.3項「サード・パーティのデバイス・リポジトリのアップロード」

- 現在のアクティブなリポジトリで問題がなければ、第68.4.3項「手順3: デバイス・グループの構成」に進みます。

68.4.2.2 デフォルトのデバイス・リポジトリの変更

この手順では、次のことを確認します。

- devices.xmlファイルに、必要なデバイス名とユーザー・エージェントが含まれていること。

- devices.xmlファイルがアクティブであること。

devices.xmlファイルを設定するには:

1. <WebCenterSites>\11gR1\Sites\11.1.1.8.0\Shared\Storage\DeviceRepository\902\235\devices.xmlディレクトリでdevices.xmlを検索します。必要な変更を行ってから、この手順を続行します。

2. devices.xmlをWebCenter Sitesにアップロードします:

1. Adminインタフェースで、「モビリティ」タブに移動します。

2. 「デバイス・リポジトリ」をダブルクリックします。

3. 「デバイス・リポジトリ・アップローダ」フォームで、デフォルトで選択されていない場合は、「デフォルト・リポジトリ」オプションを選択します。

4. 「デフォルト・リポジトリのアップロード」セクションで「参照」をクリックして、devices.xmlへのパスを選択します。

注意:

devices.xmlでデバイス名を変更した場合は、すでに作成している可能性のあるすべてのデバイス・グループの対応するデバイス名を更新してください。

5. 「保存」アイコンをクリックします。

3. 第68.4.3項「手順3: デバイス・グループの構成」に進みます。

68.4.2.3 サード・パーティのデバイス・リポジトリのアップロード

devices.xmlファイルですでに登録されているものより多くの機能およびデバイスのサポートが必要な場合は、WURFLをデバイス・リポジトリとして使用できます。WURFLはWURFL.zipとして、またはwurfl.xmlとそのパッチ・ファイルとしてアップロードできます。

注意:

WURFLは、サード・パーティのデバイス・リポジトリです。このリポジトリを使用するには、ライセンスを購入する必要があります。

wurfl.xmlファイルとパッチを使用する場合は、この手順を開始する前にパッチ・ファイルが構成されていることを確認してください。

WURFLをアップロードするには:

1. Adminインタフェースで、「モビリティ」タブに移動します。

2. 「デバイス・リポジトリ」をダブルクリックします。

3. 「デバイス・リポジトリ・アップローダ」フォームの「WURFL」セクションに移動して、完全なWURFL zipファイル、またはメインwurfl.xmlファイルとパッチ・ファイルのいずれかをアップロードします。

注意:

WURFL.patchファイルがアップロードされると、デバイス・リポジトリ表のWURFL.patchのレコードがまだActive=F (false)に設定されていることとは関係なく、このファイルがWURFL.xmlファイルと一緒に使用されます。

4. 第68.4.3項「手順3: デバイス・グループの構成」に進みます。

68.4.3 手順3: デバイス・グループの構成

デバイス・グループを構成するには:

1. 「モビリティ」タブで、「デバイス・グループ」ノードを開きます。

2. 図68-6に示すように、「デバイス・グループの追加」をクリックします。

図68-6 デバイス・グループの追加

図68-7に示すように、「デバイス・グループ」フォームが表示されます。

図68-7 「デバイス・グループ」フォーム

3. 「デバイス・グループ」フォームで「コンテンツ」タブを選択して、次の操作を実行します。

1. 「名前」フィールドに、作成しているデバイス・グループのわかりやすい名前を入力します。

2. 「接尾辞」セクションで、このデバイス・グループ(図68-7)用に作成するテンプレートで使用する接尾辞を入力します。既存の接尾辞がある場合は、それを選択できます。

注意:

この接尾辞は編集できません。後で変更したい場合は、このデバイス・グループを再作成して、この接尾辞を変更する必要があります。

3. 「アクティブ」フィールドで「はい」を選択すると、このデバイス・グループのデバイス検出が有効になります。

注意:

デバイス・グループはグローバルです。有効化すると、すべてのサイトで利用できるようになります。同様に、無効化すると、すべてのサイトで利用不可になり、デバイス検出で使用されなくなります。

4. 「基準」タブ(図68-8)を選択し、適切なテンプレート・バリアントに関連付けることのできる、実デバイスのマッチング用のルール・セットを作成します。
1つ以上のデバイス名を入力するか(残りのフォームは無効になる。図68-8を参照)、デバイス名を省略して残りのフォームに記入します。

図68-8 デバイス名の追加

1. デバイス名を入力する場合は、第68.4.2項「手順2: デバイス・リポジトリの設定」で使用することを選択したデバイス・リポジトリに登録されているのと同じ名前を入力します。devices.xmlをアップロードした場合は、デバイス・エントリ名を入力します。WURFLをアップロードした場合は、デバイスのmodel_nameを入力します。

注意:

デバイスは、一度に1つのデバイス・グループにしか属することができません。

第68.4.4項「手順4: デバイス・グループに優先順位を付ける」に進みます。

2. デバイス名を省略する場合は、次のように、残りのフォームを記入します。

1. 「ユーザーエージェント」セクション。(このセクションは、デバイス名を指定する場合は無効になります。)

このフィールドには、デバイス名のリスト、またはユーザー・エージェント、画面ディメンション、機能およびカスタム・フィルタの組合せを入力できます。ユーザー・エージェントregex、機能、画面ディメンションおよびカスタム・フィルタの組合せでは、デバイスは、デバイス・グループとの照合に使用されるすべてのルールを満たす必要があります。

受信リクエストの送信元のブラウザと一致するユーザー・エージェントを入力します。または、ユーザー・エージェントのセットと照合する正規表現や部分文字列を入力することもできます。たとえば、すべてのiPhoneユーザー・エージェントを照合するには、ユーザー・エージェントreg expを(m|M)ozilla/5.0(| )\(i(p|P)(hone|od|rod).*として指定します。この式は、iPhone Java regexを含むすべてのユーザー・エージェント文字列に一致します。または、すべてのiPhoneに一致する部分文字列iPhone;を使用することもできます。

2. 「機能」セクション。(このセクションは、デバイス名を指定する場合は無効になります。)
その機能は、「タッチ・スクリーン」、「JavaScript」、「縦横方向」および「タブレット」です。各機能には、「はい」、「いいえ」、「評価しない」というオプションがあります。

たとえば、このデバイス・グループでJavaScriptをサポートしないタブレット・デバイスのみを照合するには、「タブレット」機能で「はい」を、「JavaScript」機能で「いいえ」を、残りの機能で「評価しない」を選択します。

3. 「画面解像度」セクション。(このセクションは、デバイス名を指定する場合は無効になります。)
表示領域の幅および高さの最小値および最大値を入力します(ピクセル単位)。たとえば、最大幅640を指定する場合は、画面解像度の幅が640以下であるすべてのデバイスがこのデバイス・グループに一致します。

4. 「カスタム・デバイス・フィルタ」セクションで「参照」をクリックして、「デバイス・グループ」の「基準」タブにリストされていない機能に対して条件を適用するために作成した可能性のあるカスタム・フィルタを選択します。カスタム・フィルタを作成してデバイス基準を設定する方法については、第68.4.3.1項「デバイス・グループ基準に対するカスタム・フィルタの作成」を参照してください。

5. 「保存」アイコンをクリックして、デバイス・グループを保存します。
新しいデバイス・グループが「モビリティ」タブで、「デバイス・グループ」ノードの最下部にリストされます(図68-9)。

図68-9 新しいデバイス・グループ

注意:

デバイス・グループに優先順位を付けてデバイス・アセットを作成したら、デバイス検出によって正しく関連付けられていることを確認できます。そのためには、デバイス・グループを開いて「デバイス」タブを選択し、そのデバイス・グループに関連付けられているデバイス・アセットのリストを表示します。

デバイス・グループに優先順位を付ける手順については、第68.4.4項「手順4: デバイス・グループに優先順位を付ける」を参照してください。

デバイス・アセットの作成手順は、第68.4.5項「手順5: デバイス・アセットの作成」を参照してください。

6. 第68.4.4項「手順4: デバイス・グループに優先順位を付ける」に進みます。

68.4.3.1 デバイス・グループ基準に対するカスタム・フィルタの作成

WebCenterでは、入力としてXMLファイルをとる、デフォルトのカスタム・フィルタ実装(DefaultCustomFilter.java)を提供しています。独自のカスタム・フィルタを作成するには、CustomDeviceFilter.javaインタフェースの実装を記述できます。カスタム・フィルタ用のXMLファイルは、第68.4.3項「手順3: デバイス・グループの構成」で説明するように、「デバイス・グループ」構成画面からアップロードされます。

この項は、次のトピックで構成されています。

- WebCenter Sitesに付属するデフォルトのDefaultCustomFIlter.javaカスタム・フィルタの使用

- 独自のDeviceGroupFilter実装の作成

WebCenter Sitesに付属するデフォルトのDefaultCustomFIlter.javaカスタム・フィルタの使用

カスタム・フィルタのデフォルト実装クラスは、COM.FutureTense.Mobility.Filter.DefaultCustomFilterと呼ばれています。XML形式の入力を受け入れます。WebCenter Sitesが提供するデフォルトのカスタム・フィルタ実装では、すべての属性が渡された場合にのみ、フィルタが渡されます。同様に、そのすべてのフィルタが渡されると、カスタム・フィルタ全体が渡されます。そのため、どのシナリオでも、フィルタ条件を機能させるために、すべての引数を渡す必要があります。

例68-1は、WURFLリポジトリからデバイス・プロパティ名をとるサンプル・フィルタXMLを示しています。

例68-1 DefaultCustomFIlter.javaおよびWURFLリポジトリに基づくサンプル・フィルタ

<?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は例68-2のようになります(プロパティ名が変更されていることに注意してください)。このフィルタXMLには、tabletFilterおよびflashFilterという、2つのフィルタがあります。

例68-2 DefaultCustomFIlter.javaおよびDevices.xmlリポジトリに基づくサンプル・フィルタ

<?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のいずれか)。

独自のDeviceGroupFilter実装の作成

DeviceGroupFilterインタフェース(例68-3)を実装し、matchesメソッドを使用するJavaクラスを作成できます。カスタム・フィルタは1つ以上のフィルタで構成できます。各フィルタには0以上の引数を含めることができます。カスタム・フィルタ実装は、ORルールまたはカスタム・ロジックを使用できます。

例68-3 DeviceGroupFilterインタフェースおよびmatchesメソッドを実装するJavaクラス

public class UserDefinedCustomFilter implements DeviceGroupFilter
{
public boolean matches(DeviceContext context)
{
// Logic that returns true/false depending on whether criteria matched or not.
}
}

68.4.4 手順4: デバイス・グループに優先順位を付ける

実行時のデバイス検出で、優先順位が最も高いデバイス・グループに実デバイスが自動的に関連付けられるように、複数のデバイス・グループに優先順位を付ける必要があります。

デバイス・グループに優先順位を付けるには:

1. 「モビリティ」タブで、「デバイス・グループ」ノードを開きます。

2. 「デバイス・グループの並替え」(図68-10)をダブルクリックします。

図68-10 デバイス・グループの並替え

3. 「デバイス・グループの並替え」画面で、希望する優先順位順にデバイス・グループをドラッグ・アンド・ドロップします(図68-11)。

図68-11 デバイス・グループのドラッグ・アンド・ドロップ

デバイス・グループを並べ替えたら、「デバイス・グループの並替え」画面に新しい順序でデバイス・グループが表示されます(図68-12)。

図68-12 並べ替えられたデバイス・グループ

4. 「優先順位の保存」をクリックします。
「デバイス・グループの優先順位の再設定が正常に行われました」メッセージが表示されます。

5. 第68.4.5項「手順5: デバイス・アセットの作成」に進みます。

68.4.5 手順5: デバイス・アセットの作成

デバイス・アセット作成するには:

1. 「モビリティ」タブで、「デバイス」ノードを開きます。

2. 「デバイスの追加」(図68-13)をクリックします。

図68-13 デバイスの追加

図68-14に示すように、「デバイス」フォームが表示されます。

図68-14 「デバイス」フォーム - 「コンテンツ」タブ

3. 「コンテンツ」タブ(図68-14)で、次の操作を実行します。

1. 「名前」フィールドに、このデバイス・アセットの名前を入力します。
入力した名前は、Contributorインタフェースに表示されます。デバイス・リポジトリ内の名前と一致している必要はありません。

2. (オプション)。「製造業者」フィールドに、デバイス・メーカーの名前を入力します。

3. 「ユーザー・エージェント」フィールドで、イメージを追加するデバイスの登録済ユーザー・エージェントを指定します。ユーザー・エージェントは、デバイス・リポジトリからコピーできます。

注意:

「ユーザー・エージェント」フィールドは、このデバイス・アセットが表す実デバイスを識別します。このフィールドは、優先順位が一番高い、一致するデバイス・グループにこのデバイスを関連付けするために、デバイス検出ロジックで使用します。

4. 「ユーザー・エージェントのテスト」をクリックしてデバイス検出を実行し、このデバイスが特定のデバイス・グループに一致していることを確認します。

5. デバイス検出で、このデバイス・アセットをデバイス・グループに関連付けることができるように、「有効化」チェック・ボックスを選択します。

6. 「デバイス・イメージ」フィールドの隣にある「参照」をクリックして、イメージの保存先ディレクトリからデバイス・イメージを選択します。

7. (オプション)。「サムネイル・イメージ」フィールドの横に、サムネイル・イメージをアップロードします。このサムネイル・イメージは、Contributorインタフェースのプレビュー機能に関連付けられているデバイス・セレクタ・パネルに表示されます。サムネイルを選択すると、デバイス・イメージのページ・プレビューが表示されます。

4. 「画面ディメンション」タブで、「高さ」、「幅」、「上」および「左」の各フィールドに必要なピクセルを入力し、「ピクセル率」フィールドにピクセル率を入力して、画面領域の適切なディメンションを決定します。
各フィールドにピクセルを入力すると、デバイス・イメージの画面領域もそれに応じてリセットされ始めます。この機能により、デバイス表示領域の正確なディメンションをその場で決定できます。

図68-15 「画面ディメンション」タブ

5. フォーム上の「保存」アイコンをクリックして、新しいデバイスを作成します。
成功メッセージが表示されます。

6. 第68.4.6項「手順6: サイト・プランの作成」に進みます。

68.4.6 手順6: サイト・プランの作成

複数のサイト・プランと単一のサイト・プランのどちらが必要かは、設計方法により異なります。

サイト・プランを作成している場合、共通の接尾辞を選択することによって、デバイス・グループをそのサイト・プランに関連付けます。選択した接尾辞は、他のサイト・プランで使用できなくなります。

サイト・プランを作成するには:

1. Adminインタフェースで「管理」タブを開き、「サイト」ノードとサイト・プランの作成場所であるサイトを開きます。

注意:

SiteAdminロールが割り当てられている場合は、かわりに「サイト管理者」タブを使用します。

2. 「サイト・プラン」ノードを開きます。

3. 「新規追加」(図68-16)をダブルクリックします。

図68-16 「管理」タブの「サイト・プラン」ノード

「サイト・プランの追加」ページが表示されます(図68-17)。

図68-17 サイト・プランの追加

4. 「名前」フィールドに、サイト・プランのわかりやすい名前を入力します。

5. (オプション)「説明」フィールドに、サイト・プランの説明を入力します。

6. デバイス・グループをこのサイト・プランに関連付けるには、「接尾辞」セクションに移動して、これらのデバイス・グループによって使用される接尾辞を選択します。

注意:

「接尾辞」セクションには、サイト・プランに割り当てられていない接尾辞のみがリストされます。

「関連付けられたデバイス・グループ」パネル(図68-18)に、選択した接尾辞に関連付けられているデバイス・グループがリストされます。

図68-18 「関連付けられたデバイス・グループ」パネル

7. 「追加」をクリックして、サイト・プランを完了します。
図68-19のような画面が表示されます。

図68-19 作成された新しいサイト・プラン

8. 「サイト・プラン」タブをクリックして、新しく作成されたサイト・プランを表示します。
サイト・プランを修正するには、「管理」タブ上のサイト・ノードの下にあるサイト・プランをダブルクリックします。「サイト・プランの修正」ページで、必要な変更を行ってから、「修正」をクリックします。第68.4.7項「手順7: サイト・プランの編成」に進みます。

68.4.7 手順7: サイト・プランの編成

AdminおよびContributorインタフェースでサイト・プランを特定の順序で表示する必要がある場合には、それを並べ替えることができます。

サイト・プランを編成するには:

1. Adminインタフェースで「管理」タブを開き、「サイト」ノードとサイト・プランに優先順位を付けるサイトを開きます。

注意:

SiteAdminロールが割り当てられている場合は、かわりに「サイト管理者」タブを使用します。

2. 「サイト・プランの並替え」をダブルクリックします。

図68-20 サイト・プランの並替え

3. 「サイト・プランの並替え」画面(図68-21)で、サイト・プランをドラッグ・アンド・ドロップして、希望の順序に並べ替えます。

図68-21 サイト・プランのドラッグ・アンド・ドロップ

サイト・プランを並べ替えたら、「サイト・プランの並替え」画面が図68-22のように表示されます。

図68-22 並べ替えられたサイト・プラン

4. 「保存」をクリックします。
「修正に成功しました。」メッセージが表示されます。

5. 第68.4.8項「手順8: テンプレートの作成」に進みます。

68.4.8 手順8: テンプレートの作成

モバイルWebサイトをレンダリングするテンプレートを作成するには、次の2つの基本的な方法があります。

- すべてのモバイル・デバイス(つまり、すべてのデバイス・グループ)に適応する単一セットのテンプレートを作成します。

- 異なるデバイス・グループ用に異なるテンプレートを作成します。このシナリオには接尾辞を使用する必要があります。

この項では、2番目の方法について説明します。この項の内容は、次のとおりです。

- 第68.4.8.1項「テンプレート・バリアントを作成するための基本ガイドライン」

- 第68.4.8.2項「Mobilityのタグ」

- 第68.4.8.3項「デバイス保護とページ・レンダリングをサポートするために変更されるタグ」

68.4.8.1 テンプレート・バリアントを作成するための基本ガイドライン

異なるデバイス・グループ用の異なるテンプレートを作成する際には、次の要件に注意してください。

1. 基本テンプレート(デスクトップWebサイトをレンダリングするテンプレート)を作成します。

2. 基本テンプレートの名前を使用し、_suffixを追加して、テンプレート・バリアントを作成します。

3. テンプレートに基づいてページをキャッシュする場合は、キャッシュ基準の1つとして接尾辞(dパラメータ)を使用する必要があります。

68.4.8.2 Mobilityのタグ

表68-1では、テンプレートの作成時に使用するMobilityのタグについて説明しています。このタグの詳細は、Oracle Fusion Middleware WebCenter Sitesタグ・リファレンスを参照してください。

表68-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サイト・ナビゲーションを構築するために他のタグによって使用されます。

68.4.8.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属性の使用方法の詳細は、第68.5項「デバイス検出」を参照してください。

68.5 デバイス検出

WebCenter Sitesは、組込みのデバイス検出メカニズムを使用して、Webサイトのコンテンツを要求するデバイスを識別します。デバイスが特定されると、WebCenter Sitesは一致するデバイス・グループを検索して、その接尾辞を読み取ります。WebCenter Sitesは、接尾辞を使用してサイト・プランを見つけ、テンプレート・バリアントを呼び出してそのコンテンツをレンダリングします。

詳細な手順は次のとおりです。

1. 実デバイスからのページ・リクエストがリモートSatellite Serverで受信されます。このリクエストのヘッダーには、デバイスのユーザー・エージェントが含まれます。

2. リモートSatellite Serverは独自のキャッシュ内でそのページを検索します。ページの検索に失敗すると、リモートSatellite ServerはWebCenter Sitesにページ・リクエストを送信します。

3. WebCenter Sitesは次のように応答します。

1. リクエスト・ヘッダーのユーザー・エージェントによってデバイスを識別します。

2. デバイス・リポジトリでユーザー・エージェントを検索します。

3. デバイス・リポジトリで一致するデバイスを見つけると、WebCenter Sitesはそのデバイスの機能も検索します。

4. WebCenter Sitesはユーザー・エージェント機能とデバイス機能を使用して、基準に合ったデバイス・グループを検索します。

5. そのデバイスを優先順位の一番高いデバイス・グループに関連付けます。

6. このデバイス・グループの接尾辞を読み取ります。

7. その接尾辞をicsスコープ内のdパラメータに割り当てます。

8. _suffixをURLで要求されたテンプレート名に追加します。

9. 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

10. テンプレート・バリアントが存在する場合、WebCenter Sitesは新しいURLを実行してそのページをキャッシュし、それをリモートSatellite Serverに送信します。
テンプレート・バリアントが存在しない場合、WebCenter Sitesは元のURLを実行してそのページをキャッシュし、それをリモートSatellite Serverに送信します。

4. リモートSatellite Serverはそのページをキャッシュして、デバイスにレスポンスを送信します。

5. リモートSatellite Serverは、デバイス検出情報もキャッシュして、それを同じデバイスからの後続のリクエストを処理するために使用します。これにより、WebCenter Sitesでのデバイス検出の再実行が回避されます。

第V部

Webエクスペリエンス管理(WEM)フレームワークを使用したアプリケーションの開発

この部では、アプリケーション開発に関係するOracle WebCenter Sites: Webエクスペリエンス管理(WEM)フレームワークについて説明します。さらに、WEMフレームワークの概要を説明した後で、アプリケーションおよびRepresentational State Transfer (REST)のカスタム・リソースの開発プロセスについて説明します。また、シングル・サインオン(SSO)の実装とカスタマイズについても説明します。

この部は、次の章で構成されています。

- 第69章「Webエクスペリエンス管理(WEM)フレームワークについて」

- 第70章「WEMフレームワーク: フレームワークとサービスについて」

- 第71章「WEMフレームワーク: Articlesサンプル・アプリケーション」

- 第72章「WEMフレームワーク: アプリケーションの開発」

- 第73章「WEMフレームワーク: カスタムRESTリソースの開発」

- 第74章「WEMフレームワーク: 本番サイトでのシングル・サインオン」

- 第75章「WEMフレームワーク: RESTリソースの使用」

- 第76章「WEMフレームワーク: Customizable Single Sign-Onファシリティ」

- 第77章「WEMフレームワーク: バッファリング」

- 第78章「WEMフレームワーク: アプリケーションの手動登録」

69 Webエクスペリエンス管理(WEM)フレームワークについて

Oracle WebCenter Sites: Webエクスペリエンス管理(WEM)フレームワークは、アプリケーションを開発し、そのアプリケーションをOracle WebCenter Sitesと統合するためのテクノロジを備えています。単一の管理インタフェースであるWEM Adminは、アプリケーション管理およびユーザー認可の一元化をサポートします。また、シングル・サインオンを使用することによって、ユーザーは1回のログインで、セッション中に許可されているすべてのアプリケーションにアクセスできるようになります。

この章には次の項が含まれます。

- 第69.1項「WEMフレームワークの概要」

- 第69.2項「アプリケーション開発の前提条件」

- 第69.3項「はじめに」

69.1 WEMフレームワークの概要

WEMフレームワークを使用するには、コンテンツ管理プラットフォームが必要です。このリリースでは、WEMフレームワークはOracle WebCenter Sites上で稼働し、WebCenter Sites Representational State Transfer (REST) APIが同梱されています。サイト、ユーザーおよびデータ・モデルなど、WebCenter Sitesデータベース内のオブジェクトは、WEMフレームワークでRESTリソースにマッピングされます。

WEMフレームワーク上に実装されたアプリケーションは、RESTサービスを介してWebCenter Sitesデータベースと通信します。アプリケーションは、WEM Adminの「アプリケーション」ページ(図69-1)にリスト・アイテムとして表示されます。管理者はユーザーの認可を行う際に、アプリケーションおよびそのリソースへのアクセスも構成します。そのため、WEM Adminインタフェースでは、メニュー・バー上のリンクを介してから認可アイテムが(アプリケーションとともに)公開されます。

図69-1 WEM Adminの「アプリケーション」ページ

「図69-1 WEM Adminの「アプリケーション」ページ」の説明

図69-2に示すようにアイテムを結合することによって、ユーザーにアプリケーションの使用を許可します。

図69-2 認可モデル

結合処理が完了すると、ユーザーはデータベース・レベル、RESTレベルおよびアプリケーション・レベルで認可されます。

習熟したWebCenter Sites開発者であれば、WEMフレームワークによって、アプリケーションへのアクセスを制御するためのサイトおよびロールの用途が拡張されることがわかります。ただし、WebCenter Sitesとは異なり、WEM Adminインタフェースはデータ・モデルを公開しません。REST APIが公開します。この点においてWEM Adminは厳密な意味での認可インタフェースと見なすことができ、(ACLおよびグループの構成用に)WebCenter Sites Adminインタフェースでサポートされます。

開発者がWEM Adminを使用することはほとんどありませんが、ユーザー認可の背後にある概念を理解しておくことにより、アプリケーション開発に役立つ場合があります。以降の各章では、アプリケーション開発に関係するWEMフレームワークについて説明し、アプリケーション・コードの例を示します。

69.2 アプリケーション開発の前提条件

アプリケーション開発には、アプリケーション・ロジックのコーディング、アプリケーションのデプロイに加え、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、アプリケーションを登録してWEM Adminで公開することも含まれます。この情報は、アプリケーション開発のチュートリアルではなく、経験を積んだアプリケーション開発者がWEMフレームワークの使用方法を習熟できるようにするためのリファレンスです。これらの章のユーザーは、WebCenter Sitesに習熟し、この項に記載されているテクノロジについて実践的な知識を持った開発者である必要があります。必要なリソースについては、以降にも記載されています。

この項の内容は、次のとおりです。

- 第69.2.1項「テクノロジ」

- 第69.2.2項「WebCenter Sitesインタフェース、オブジェクトおよびAPI」

- 第69.2.3項「ドキュメント」

- 第69.2.4項「サンプル・アプリケーションおよびファイル」

- 第69.2.5項「アプリケーション・アクセス」

69.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」サンプル・アプリケーションのコードを実行します。

69.2.2 WebCenter Sitesインタフェース、オブジェクトおよびAPI

開発者は次に関する実践的な知識を持っている必要があります。

- WebCenter Sites Admin (WebCenter Sites管理インタフェース)

- WebCenter Sitesのベーシック・アセット・モデルおよびフレックス・アセット・モデル

- アセットAPI

- ACL。データベース表を保護し、表に対して実行可能な操作のタイプを定義します。

- サイトおよびロールの概念

69.2.3 ドキュメント

この項では、次のドキュメントが必要になります。

- Oracle Fusion Middleware WebCenter Sites REST APIリソース・リファレンス

- Oracle Fusion Middleware WebCenter Sites REST API Beanリファレンス

ACL、サイト、ロールの詳細およびこれらのWebCenter Sitesでの使用方法については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

69.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フォルダにあります。

69.2.5 アプリケーション・アクセス

このガイドを使用するとき、または開発やテストを行うときには、次に示すアプリケーションの一部またはすべてにアクセスします。

- CAS Webアプリケーション。次のように、このアプリケーションのURLを「Articles」サンプル・アプリケーションで指定して、シングル・サインオンを有効にします。
http://<server>:<port>/<cas_application_context>/login

<server>は、CASが実行されているコンピュータのホスト名またはIPアドレス、<cas_application_context>は、CAS Webアプリケーションのコンテキスト・パスです。

- WebCenter Sites Adminインタフェース。アプリケーションを手動で登録する場合は、次のように指定します。
http://<server>:<port>/<cs_application_context>/Xcelerate/LoginPage.html

WebCenter Sitesのインストール・プロセスで使用した一般管理者(または同等の一般管理者)の資格証明でログインします。デフォルトのログイン資格証明はfwadmin/xceladminです(WEM Adminへのログインと同様)。

注意:

WebCenter Sitesシステムの一般管理者は、WEMフレームワーク向けに特別に構成されます。インストール・プロセス中に、fwadminは、RESTサービスに無制限にアクセスするためにRestAdminグループに自動的に追加され、WEM Adminインタフェースが稼働するAdminSite上で有効化されます。WebCenter SitesへのWEM関連の変更の詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。

- WEM Admin。アプリケーション登録プロセスの結果をテストするには、次のように指定します。
http://<server>:<port>/<cs_application_context>/login

fwadmin(または同等のユーザー)でログインします。画面の順序は次のとおりです。

1. ログイン画面:

2. 遷移画面(初めてログインする場合または初めてアクセスするサイトにアクセスする場合)。次のように「AdminSite」と最初のアイコン「管理」を選択します。

3. WEM Adminの「サイト」ページ。登録済アプリケーションが「アプリケーション」ページに一覧表示されます。

69.3 はじめに

このガイドの各章は、順序に関係なくお読みいただけます。

- WEMフレームワークの詳細は、第70章「WEMフレームワーク: フレームワークとサービスについて」を参照してください。

- 「Articles」アプリケーションのデモについては、第71章「WEMフレームワーク: Articlesサンプル・アプリケーション」を参照してください。

- 「Articles」アプリケーションのコード、プログラムによるアプリケーションの登録、およびクロスドメインの実装の詳細は、第72章「WEMフレームワーク: アプリケーションの開発」を参照してください。手動によるアプリケーションの登録の例は、第78章「WEMフレームワーク: アプリケーションの手動登録」を参照してください。

- RESTリソースの作成の詳細は、第73章「WEMフレームワーク: カスタムRESTリソースの開発」を参照してください。

- SSOサンプル・アプリケーションのデモについては、第74章「WEMフレームワーク: 本番サイトでのシングル・サインオン」を参照してください。

- システム・セキュリティの詳細は、第75章「WEMフレームワーク: RESTリソースの使用」を参照してください。

- WEMフレームワークのログイン動作のカスタマイズの詳細は、第76章「WEMフレームワーク: Customizable Single Sign-Onファシリティ」を参照してください。

- バッファリングの詳細は、第77章「WEMフレームワーク: バッファリング」を参照してください。

70 WEMフレームワーク: フレームワークとサービスについて

アプリケーション開発者の環境は、RESTサービスを介してWebCenter Sites上で実行されるWEMフレームワークで構成されます。WebCenter SitesへのRESTコールは、アプリケーションで任意の言語で記述することで実行できます。カスタム構築アプリケーションは、プラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイ可能であるため、プラットフォームのデプロイメント・インフラストラクチャとは別に記述できます。

この章には次の項が含まれます。

- 第70.1項「アプリケーション開発のサポート」

- 第70.2項「RESTサービス」

- 第70.3項「UIコンテナ」

- 第70.4項「シングル・サインオン」

- 第70.5項「認可モデル」

- 第70.6項「カスタム・アプリケーション」

- 第70.7項「RESTリソースの要件」

70.1 アプリケーション開発のサポート

アプリケーション開発のサポートは、次のコンポーネントで行われます(この章のそれぞれの項も参照してください)。

- RESTサービス: WebCenter Sitesオブジェクトへのアクセスを提供する一連のプログラム・インタフェース。

- UIコンテナ: 登録済アプリケーションを公開します。登録によって、アプリケーションのインタフェースのレンダリングが可能になります。また、UIコンテナは、アプリケーションでログイン済ユーザーや現在のサイトに関する詳細情報をWEMフレームワークから取得するために使用する、WEMコンテキスト・オブジェクトもサポートしています。

- シングル・サインオン(SSO): 認証されたユーザーが1回ログインするのみで、そのセッション中に許可されるすべてのアプリケーションにアクセスできるようになります。(WebCenter Sitesインストール・プロセスでは、WEMのシングル・サインオンをサポートするCentral Authentication Service Webアプリケーションがインストールされます。)

- REST認可モデル: グループ・メンバーシップに基づいて、RESTリソースへの詳細なアクセス制御を提供します。アプリケーション開発は、事前定義済ユーザーがコードで指定されている場合を除き、(WEM AdminおよびWebCenter Sites Adminインタフェースでグラフィカルに構成されている)認可には直接関係していません。

WEM AdminもWEMフレームワークの一部ですが、アプリケーション開発に使用されることはほとんどなく、主に、アプリケーション登録プロセスの結果をテストしたり、サイト、ユーザー、グループ、ロールに関する管理情報を取得したりするために使用されます。WEM AdminおよびWebエクスペリエンス管理フレームワークの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

70.2 RESTサービス

REST APIでは、次のWebCenter Sitesデータ・モデルが公開されます。

- ベーシック・アセット・タイプおよびベーシック・アセット(読取り/書込み)

- フレックス・アセット・タイプおよび定義(読取り専用)

- フレックスの子と親(読取り/書込み)

- 索引付けによるアセット検索のサポート

次のオブジェクトも、REST APIで公開されます。これらのオブジェクトは、主に認可プロセスで管理者が使用します(オブジェクトはWEM Adminインタフェースに表示されます)。

- サイト(読取り/書込み)

- ユーザー(読取り/書込み)

- ロール(読取り/書込み)

- ACL(読取り専用)

- グループ(読取り専用): RESTレイヤーへのアクセスを制御するためにこのリリースで導入されました。

- 補助サービス: ユーザー・ロケールおよびサーバーのタイムゾーン

(サイト、ロールおよびユーザーはWEM Adminで構成できます。ACLおよびグループは、読取り専用アイテムとしてWEM Admin(「ユーザー」の下)に公開されます。それらは、WebCenter Sites Adminインタフェースで構成する必要があります。)

WebCenter Sitesのオブジェクトは、WEM内のRESTリソースにマップされます。パブリッシュ、ワークフロー、データベース管理ツール、ページのキャッシングなど、他のすべての機能には、WebCenter Sites AdminインタフェースからまたはJSPやXMLタグを介してアクセスする必要があります。

一般管理者が管理する認可オブジェクトの中で、サイトおよびロールが、要件によってはアプリケーション管理の候補となる可能性が高いです。また、管理者の認可タスクを簡素化するために、事前定義済ユーザーを指定することもできます。

- サイト: アプリケーション・コードでのサイトの使用は、アプリケーションのアセット・タイプとアセットをプログラムでインストールする必要がある場合の要件です。コードでアセット・タイプを有効にするサイトを1つ以上指定する必要があります(アセットへのサイト固有のアクセスを行うには、それらのアセット・タイプが1つ以上のサイトで有効になっている必要があります)。そうでない場合は、サイトを指定しないで、アセット・タイプを単にインストールできます。その後、管理者は、WebCenter Sites Adminインタフェースを使用して、独自に選択したサイト上でアセット・タイプとアセットを有効にします。

- WEMのロール: アプリケーションへのアクセスを管理するために使用します。同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。アプリケーション・コードでロールを使用すると、Editなどの、インタフェース機能を保護できます。WebCenter Sites Adminインタフェースは、ロールで保護されたインタフェース機能を備えたアプリケーションの一例です。

- ユーザー: アプリケーション・コードで指定する可能性のある唯一のユーザーは、管理者の認可プロセスを簡略化するための事前定義済ユーザーです。ユーザーの指定には、ユーザー名とパスワードのコーディングが含まれます。管理者は、すべてのアプリケーション・ユーザーをRESTレベルで個別に認可するかわりに、事前定義済ユーザーを認可します。事前定義済ユーザーに付与された権限は、ユーザーがアプリケーションにアクセスするとログイン済ユーザーに引き継がれます。事前定義済ユーザーおよび認可モデルの詳細は、第70.5項「認可モデル」を参照してください。

システム全体においてサイトとロールがどのように使用されているかを追跡するのは管理者のタスクですが、これにはアプリケーション開発者によるサポートが必要です。トラッキングは、WebCenter Sitesプラットフォームがステージング・システムとしても機能する場合に特に重要です。これは、WEMフレームワークがWebCenter Sitesデータベースを使用しているからです。たとえば、WEM Adminで作成されたサイトはデータベースに格納されます。それらはステージング用にWebCenter Sitesで使用されるとはかぎりませんが、WebCenter Sites Adminインタフェースで専用のCMサイトと一緒に公開されます。反対に、CM用途でWebCenter Sites Adminインタフェースで作成されたサイトは、WEM Adminで公開されます。ここで、その他のアプリケーションをそれらのサイトに割り当てることができます。ユーザーが適切に認可されるには、開発者はカスタム構築アプリケーションの性質を管理者に伝達する必要があります。そのような性質には、ユーザーが使用するリソース、ロールで保護されたインタフェース機能、事前定義済ユーザー(存在する場合)などが含まれます。

70.3 UIコンテナ

UIコンテナでは、登録済アプリケーションが公開され、コンテキスト・オブジェクトがサポートされます。コンテキスト・オブジェクトは、WEMフレームワークから情報を取得するためにアプリケーションで使用されます。

この項の内容は、次のとおりです。

- 第70.3.1項「登録」

- 第70.3.2項「WEMコンテキスト・オブジェクト」

70.3.1 登録

アプリケーションを登録する目的は、管理者がアプリケーションを管理したり、他のユーザーに提供したりできるように、WEM Adminでアプリケーションを公開することです。登録を行うと、そのアプリケーションがアセットとして認識され、次のことが実行されます。

- WEM Adminの「アプリケーション」ページにアプリケーションが一覧表示されます(図70-1)。

- アプリケーションを表すために選択したアイコンが配置されます。

- WebCenter Sitesのログイン・ページ、およびアプリケーションが割り当てられている各サイトのアプリケーション・バー(図70-1)にアプリケーションのアイコンが表示されます。

- アプリケーションのアイコンが選択された際にアプリケーションのインタフェースがレンダリングされます。

図70-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サービスを介してプログラムで登録することも、WebCenter Sites Adminインタフェースから手動で登録することもできます。プログラムによる登録をお薦めします。例については、第71.2項「Articlesサンプル・アプリケーションの起動」を参照してください。一般的な手順については、第72.6項「登録コード」を参照してください。手動登録の例については、第78章「WEMフレームワーク: アプリケーションの手動登録」を参照してください。

70.3.2 WEMコンテキスト・オブジェクト

UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、ログイン・ユーザーやサイトに関する詳細情報をWEMフレームワークから取得する際にアプリケーションで使用されます(たとえば、UIコンテナからの現在のサイトの名前など)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する様々なユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。詳細は、第72.5項「コンテキスト・オブジェクト: WEMフレームワークからのパラメータへのアクセス」を参照してください。

70.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. 初回アクセス

1. ユーザーがCASで保護されているアプリケーションに最初にアクセスしようとすると、

2. ユーザーは、CASログイン・ページにリダイレクトされます。ログインに成功すると、

3. ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。CASログイン・ページのCookieが保存されます。

4. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。(コンテンツ管理システムでは、CASはデフォルトでWebCenter Sitesデータベースに対して認証を行います。)

2. 2回目以降のアクセス

1. CASで保護された別のアプリケーションにユーザーがアクセスしようとすると、ユーザーはCASログイン・ページにリダイレクトされます。

2. リクエストからCookieが取得されて暗黙的ログインが実行され、ログイン・ページは省略されます。

3. ユーザーはチケットとともにアプリケーションに再びリダイレクトされます。

4. アプリケーションはユーザーのIDを検証するために、CASに対してチケットを検証します。

70.5 認可モデル

認可とは、アプリケーションへのアクセスをユーザーに付与するプロセスです。一般管理者は、図70-2に示すようにWEM Adminを使用してオブジェクトを結合することにより、認可を行う必要があります。開発者は、アプリケーションで事前定義済ユーザーをコーディングすることにより、管理者のタスクを簡素化できます。以降では、ユーザーを認可モデルに適合させる方法について説明します。

図70-2のサイト、アプリケーション、ユーザーおよびロールには、それぞれに対応するWEM Adminのメニュー・オプションがあります。ACLおよびグループは、各ユーザーのページで公開されます。

図70-2 認可モデル

認可は3つのレベル(アプリケーション、RESTおよびデータベース)で管理されます。

- アプリケーション・レベルの認可では、同じサイト上のユーザーとアプリケーションでロールを共有する必要があります。これにより、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。インタフェース機能がロールで保護されている場合、それらのロールもアプリケーション・ユーザーと共有されている必要があります。

- RESTレベルの認可では、ユーザーがアプリケーションのリソースを操作するための権限を制限します(ACLが正しく割り当てられていることが前提です)。RESTレベルの認可では、RESTリソースにマップされるオブジェクトへの操作権限を持つグループを構成する必要があります。グループに割り当てられたユーザーにはグループの権限が付与されます。
開発者は、ログイン済ユーザーのプロキシとして動作するユーザーをアプリケーションで定義できます(ユーザー名とパスワードを指定する)。これにより、管理者がログイン済ユーザーごとにRESTセキュリティを構成する必要がなくなります。アプリケーションがデプロイおよび登録されると、一般管理者は次の方法で事前定義済ユーザーを認可します。1) WEM Adminで、アプリケーションにアクセスするための事前定義済ユーザーを構成し、2)アプリケーションのリソースの操作権限を持つグループを(WebCenter Sites Adminインタフェースで)構成して、3)事前定義済ユーザーを(WEM AdminまたはWebCenter Sites Adminインタフェースのいずれかを使用して)そのグループに割り当てます。グループの権限は事前定義済ユーザーに渡され、ログイン済ユーザーがアプリケーションにアクセスする際に、そのログイン済ユーザーに渡されます。サポートされるセキュリティ構成は、第75.3項「REST認可」で一覧表示して説明されています。WEMフレームワークに付属の「Articles」サンプル・アプリケーションでは、事前定義済ユーザーが指定されます。

- データベース・レベルでは、そのユーザーのグループ・メンバーシップにかかわらず、ACLによって個々のユーザーのシステムへのアクセス(つまり、ログイン権限、データベースの操作権限)が決定されます。ACLでユーザーに適切な権限が割り当てられておらず、データベース表への権限が不足している場合、グループのメンバーシップによってそれらの権限が付与されることはありません。
デフォルトのACLでは、多くのデータベース表のオブジェクトに対してほぼ無制限の操作権限(手段ではない)がユーザーに提供されます。それらの権限を調整するには、RESTレベルで、ユーザーのグループ・メンバーシップによって直接調整するか(事前定義済ユーザーが存在しない場合)、アプリケーションの事前定義済ユーザーとそのユーザーのグループ・メンバーシップによって間接的に調整します。オブジェクトに対するグループの操作権限を変更すると、そのグループ・メンバーのリソースに対する操作権限も変更されます。WebCenter Sites側の同一ユーザーはグループ・メンバーシップによる影響は受けません。コンテンツに対する権限は、引き続きACLによって制限され、サイトとロールによって機能します。

70.6 カスタム・アプリケーション

WEMで開発されるカスタム・アプリケーションは、通常、コンテンツ管理プラットフォームに対して疎結合された形で実装されます。カスタム・アプリケーションは、WEMフレームワークで有効化されたREST API WebサービスとSSOメカニズムを利用するため、一般的にプラットフォームのアプリケーション・サーバー以外のアプリケーション・サーバーにデプロイされます。そのため、開発者はプラットフォームのデプロイメント・インフラストラクチャから完全に切り離してカスタム・アプリケーションを作成できます。ほとんどのカスタム・アプリケーションはリモートでデプロイされます(図70-3)。

図70-3 リモートでのアプリケーションのデプロイメント

カスタム・アプリケーションは、コンテンツ管理アプリケーションまたは配信アプリケーションとして実装できます。一般的に、コンテンツ管理側ではパフォーマンス・チューニングの手間がそれほどかからないため、コンテンツ管理側から着手することをお薦めします。

WEMフレームワークには、いくつかの軽量のサンプル・アプリケーションが付属しており、それぞれ専用アプリケーションを開発するためのモデルとして起動および分析できます。「Articles」は、コンテンツ管理アプリケーションを示しています。第71章「WEMフレームワーク: Articlesサンプル・アプリケーション」には、「Articles」を起動するための手順が含まれています。仕様については、第72章「WEMフレームワーク: アプリケーションの開発」を参照してください。ソース・コードはWebCenter Sites Misc/Samplesフォルダにあり、その他のサポート情報はREST APIリソースおよびBeanリファレンスに記載されています。SSOサンプル・アプリケーションはライブ・サイトでの認証用で、「Recommendations」アプリケーションはRESTリソースの作成方法を示しています。

70.7 RESTリソースの要件

すべてのREST POST/PUT/DELETEリクエストを有効であると認証するには、各リクエストには、X-CSRF-Tokenキーを持つヘッダーと、CASチケット(マルチまたはシングル)またはsessionidのいずれかの値が必要です。

71 WEMフレームワーク: Articlesサンプル・アプリケーション

Articlesは、詳細に文書化されたソース・コードと自己インストール・プロセスを備えた、単純なコンテンツ管理アプリケーションです。これにより、アプリケーション開発に最も重要な情報を素早く習得できます。名前からわかるように、Articlesでは記事アセットを管理できます。

この章には次の項が含まれます。

- 第71.1項「サンプル・アプリケーションの概要」

- 第71.2項「Articlesサンプル・アプリケーションの起動」

- 第71.3項「Articlesアプリケーションのテスト」

71.1 サンプル・アプリケーションの概要

Articlesホーム・ページには、前述の図で示したカスタム・インタフェースから、WEMで直接編集可能な2つの記事が表示されます。このアプリケーションでは、WebCenter Sites REST APIを使用して、Javaコードから検索問合せを実行し、JavaScriptコードからアセット変更問合せを実行する方法を示します。ArticlesアプリケーションとRESTサービスは、別々のアプリケーション・サーバーで実行させることができます。JavaScriptのクロスドメイン制限により、ArticlesアプリケーションからRESTサービスに対してAJAXを直接コールできません。単純なProxyControllerが導入されたのはこのためです。これにより、コールがJavaScriptからWEM REST Webサービスにリダイレクトされます。このコントローラ実装はカスタム実装で再利用できます。

アプリケーションのホーム・ページは次のようになります。

Articlesアプリケーションは、Spring MVCフレームワークに基づいています。Articlesには、fwadminという名前でxceladminというパスワードを持つ事前定義済管理ユーザーが含まれます。このユーザーはRestAdminというRESTグループに割り当てられています。　アプリケーションの自己インストーラには、Articlesアプリケーションを登録し、そのアセット・モデルとサンプル記事をインストールするための仕様が含まれます。このアプリケーションには、内部的に構成されたサイトやロールで保護された機能は存在せず、単一のiframeビューがあります。その他の仕様については、第71章「WEMフレームワーク: Articlesサンプル・アプリケーション」を参照してください。

71.2 Articlesサンプル・アプリケーションの起動

この項では、まずArticleアプリケーションのビルドとデプロイを行い、続いてインストーラを実行します。

この項の内容は、次のとおりです。

- 第71.2.1項「Articlesアプリケーションのビルドおよびデプロイ」

- 第71.2.2項「Articlesサンプル・アプリケーションの登録」

71.2.1 Articlesアプリケーションのビルドおよびデプロイ

1. サンプルのArticlesアプリケーションの割当て先となるサイトを選択または作成します。デフォルトのサイトはFirstSiteII (WebCenter SitesのサンプルのCMサイト)です。FirstSiteIIはシステムにインストールされていない場合があります。

サイトを選択または作成するには、次のURLにアクセスしてWEM Adminにログインします。

http://<server>:<port>/<cs_application_context>/login

このとき、一般管理者の資格証明(デフォルト値はfwadmin/xceladmin)を使用します。

注意:

手順5では、ここで選択したサイトを指定します。これにより、インストーラを実行した際に、指定したサイトでアプリケーションのアセット・モデルとアセットが有効になります。

2. 次のURLからSUN JDK (1.5以降)をダウンロードして、インストールします。
http://java.sun.com/

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 Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- csPassword: 事前定義済ユーザーのパスワードを指定します。

- articlesUrl: サンプル・アプリケーションにアクセスする際のURLを指定します。

6. デフォルトのターゲットを指定してAntビルドを実行します(コマンド・ラインでantと入力します)。

7. 生成されたtarget/articles-1.0.warをアプリケーション・サーバーにデプロイします。
デプロイメント時に、次のコンテンツがソースからターゲットにコピーされます。libフォルダの内容は/WEB-INF/lib/にコピーされます。resourcesフォルダの内容は/WEB-INF/classes/にコピーされます。ソース・アプリケーションの構造の詳細は、第72章「WEMフレームワーク: アプリケーションの開発」を参照してください。

71.2.2 Articlesサンプル・アプリケーションの登録

Articlesアプリケーションには自己インストーラが用意されており、install.appページにログインすると実行されます。インストーラによってサンプル・アプリケーション(ビューを含む)が登録され、そのデータ・モデルとアセットがWebCenter Sitesデータベースに作成されます。

注意:

登録アセット・タイプFW_ViewおよびFW_Applicationの仕様は、Oracle Fusion Middleware WebCenter Sites REST API Beanリファレンスおよび第78章「WEMフレームワーク: アプリケーションの手動登録」を参照してください。

Articlesインストーラを実行するには:

1. 次のようにinstall.appページに移動します。

http://<hostname>:<portnumber>/<context_path>/install.app

例:

http://localhost:9080/articles-1.0/install.app

2. 任意の資格証明を使用してログインします(csUserNameおよびcsPasswordで指定した(第71.2.1項「Articlesアプリケーションのビルドおよびデプロイ」を参照)、アプリケーションの事前定義済ユーザーにはアプリケーションに対する権限が付与されています。サンプル・アプリケーションではロールを使用しないため、認可チェックは実行されません。)

3. 自己インストール・プロセスによってInstallController.javaが起動されます。まずアプリケーション(アプリケーションBeanのビューを含む)が登録され、続いてサンプルのアセット・タイプとアセットがデータベースに書き込まれます。

1. 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属性によって行われます。

2. InstallController.javaは、次のようにアプリケーションのアセット・モデルとサンプル・アセットをインストールします。

- アプリケーションのFW_Articleアセット・タイプをWebCenter Sitesデータベースに作成します。(FW_Articleは、InstallController.javaで定義されているベーシック・アセット・タイプです。)

- applicationContext.xmlのcsSiteNameパラメータで指定されているサイト(第71.2.1項「Articlesアプリケーションのビルドおよびデプロイ」の手順5)でFW_Articleアセット・タイプを有効にします。

- 記事アセットの2つのサンプルをFW_Articleアセット・タイプ表に書き込みます。(記事のテキストとイメージは、/sample app/articles/src/main/resources/installに格納されます)

3. InstallController.javaは、アセット・タイプFW_Articleの検索をサポートするアセット・タイプに基づいた索引を作成します。(コントローラは、索引構成データを指定します。)

4. インストール・プロセスが正常に完了すると、InstallController.javaによって(http://<server>:<port>/articles/install.appに)次のページが表示されます。Homeはhome.appです。

71.3 Articlesアプリケーションのテスト

1. 次のようにhome.appページに移動します。

http://<hostname>:<portnumber>/<context_path>/home.app

例:

http://localhost:8080/articles-1.0/home.app

2. 任意の資格証明を使用してログインします(csUserNameおよびcsPasswordで指定した(第71.2.1項「Articlesアプリケーションのビルドおよびデプロイ」を参照)、アプリケーションの事前定義済ユーザーにはアプリケーションに対する権限が付与されています。サンプル・アプリケーションではロールを使用しないため、認可チェックは実行されません。)
次のように、アプリケーションのホーム・ページがWEMに表示されます。

図71-1 Articlesホーム・ページ

3. このアプリケーションを使用して実験を行う場合(たとえば、別のサイトに割り当てて、ユーザーを追加する場合)、WEM Adminを使用します。Webエクスペリエンス管理フレームワークの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

72 WEMフレームワーク: アプリケーションの開発

この章の全体を通して「Articles」サンプル・アプリケーションを使用し、RESTコールを実行するアプリケーションの基本アーキテクチャについて説明します。

この章には次の項が含まれます。

- 第72.1項「アプリケーションの構造」

- 第72.2項「構成ファイル」

- 第72.3項「RESTコールの実行」

- 第72.4項「バイナリ・データを処理するURLの作成」

- 第72.5項「コンテキスト・オブジェクト: WEMフレームワークからのパラメータへのアクセス」

- 第72.6項「登録コード」

72.1 アプリケーションの構造

図72-1は、「Articles」サンプル・アプリケーションのソース構造を示しています。デプロイメント時に、次のディレクトリはソースからターゲットにコピーされます。libディレクトリの内容は/WEB-INF/lib/にコピーされます。resourcesディレクトリの内容は、/WEB-INF/classes/にコピーされます。

図72-1 「Articles」サンプル・アプリケーションのソース構造

「Articles」は、Spring MVCで開発されたJava Webアプリケーションです。次のページが提供されます。

- /install.appは、「Articles」のインストール・ページです。また、アプリケーションが正常にインストールされた場合に確認メッセージが表示されます。

- /home.appは、「Articles」アプリケーションのホーム・ページです(図72-3)。

72.2 構成ファイル

- applicationContext.xml(/WEB-INF/)には、SSO構成およびアプリケーション固有の構成(事前定義済ユーザーや、データ・モデルおよびアセットが有効化されるサイトなど)が保持されます。

- spring-servlet.xml (/WEB-INF/)は、デフォルトのSpring構成ファイルです。このファイルはSpring構成を格納し、次のコントローラを参照します(「ソース・ファイル」を参照)。

- HomeController

- InstallController

- LayoutController

- ProxyController

- log4j.properties (/resources/)は、ロギング構成ファイルです。アプリケーションのデプロイ時に、/resources/から/WEB-INF/classes/にコピーされます。

ソース・ファイル

/sample app/articles/src/main/java/

/sample/フォルダには、次に示すソース・ファイルが含まれます。

- Configuration.javaは、(Springフレームワークによって)applicationContext.xmlファイルから移入されます(第72.2項「構成ファイル」を参照)。

- 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で使用されます(図72-3)。

- strategies.png

- strategies.txt

- tips.png

- tips.txt

ホーム・ページ・ファイル

/sample app/articles/src/main/webapp/images

/images/フォルダには次のファイルが含まれます。

- articles.pngアイコン(図72-2)。アプリケーション・バーで「Articles」アプリケーションを表します。

- 図72-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」アプリケーションのホーム・ページ・ビューをレンダリングする際に使用されます(図72-3)

- layout.jsp。アプリケーションのレイアウトを定義します。

WEB-INF

/sample app/articles/src/main/WEB-INF

/WEB-INF/フォルダには次のファイルが含まれます。

- articles.tld。TLD宣言ファイルです。

- spring-servlet.xml。Spring構成ファイルです。

- web.xml。Webアプリケーションのデプロイメント・ディスクリプタです。

図72-2 「Articles」のアイコン(articles.png)

「図72-2 「Articles」のアイコン(articles.png)」の説明

図72-3 「Articles」のホーム・ページ

72.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です(サンプル・コードについては、第72.3.1項「JavaScriptからのRESTコールの実行」の行64および66を参照)。

RESTコールの詳細は、この項の次のトピックを参照してください。

- 第72.3.1項「JavaScriptからのRESTコールの実行」

- 第72.3.2項「JavaからのRESTコールの実行」

72.3.1 JavaScriptからのRESTコールの実行

次のコード(home.jsp)は、アセットのRESTサービスに対してAJAXコールを実行して、アセット・データを保存します。実際には、プロキシ・コントローラに対してリクエストが実行され、プロキシ・コントローラから宛先のRESTサービスにリクエストがリダイレクトされます。

注意:

JSONのstringifyライブラリ(http://json.org/js.html)を使用して、JavaScriptオブジェクトを文字列としてシリアライズします。文字列のかわりにJSONオブジェクトを記述する方が便利です。

1. // Form the URL pointing to the asset service

2. // to the proxy controller, which will redirect this request to the CS REST servlet.

3. var idarr = assetId.split(":");

4. var assetUrl = "${pageContext.request.contextPath}/REST/sites/${config.csSiteName}/types/" + idarr[0] + "/assets/" + idarr[1];

5. // For the data object to be posted.

6. var data =

7. {

8. "attribute" :

9. [

10. {

11. "name" : "source",

12. "data" :

13. {

14. "stringValue" : document.getElementById("source_e_" + assetId).value

15. }

16. },

17. {

18. "name" : "cat",

19. "data" :

20. {

21. "stringValue" : document.getElementById("cat_e_" + assetId).value

22. }

23. }

24. ],

25. "name" : document.getElementById("name_e_" + assetId).value,

26. "description" : document.getElementById("desc_e_" + assetId).value,

27. // This should be removed.

28. "publist" : "${config.csSiteName}"

29. };

30. // Convert JSON data to string.

31. var strdata = JSON.stringify(data);

32. // Perform AJAX request.

33. var req = getXmlHttpObject();

34. req.onreadystatechange = function ()

35. {

36. if (req.readyState == 4)

37. {

38. if (req.status == 200)

39. {

40. // On successful result

41. // update the view controls with new values and switch the mode to 'view'.

42. for (c in controls)

43. {

44. document.getElementById(controls[c] + "_v_" + assetId).innerHTML =

45. document.getElementById(controls[c] + "_e_" + assetId).value;

46. }

47. switchMode(assetId, false);

48. }

49. else

50. {

51. // Error happened or the session timed out,

52. // reload the current page to re-acquire the session.

53. alert("Failed to call " + assetUrl + ", " + req.status + " " + req.statusText);

54. window.location.reload( false );

55. }

56. }

57. };

58. // We put Content-Type and Accept headers

59. // to tell CS REST API which format we are posting

60. // and which one we are expecting to get.

61. req.open("POST", assetUrl, true);

62. req.setRequestHeader("Content-Type", "application/json;charset=utf-8");

63. req.setRequestHeader("Content-Length", strdata.length);

64. req.setRequestHeader("Accept", "application/json");

65. req.send(strdata);

66. }

72.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エラーが返されます。

72.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が格納されます。

72.5 コンテキスト・オブジェクト: WEMフレームワークからのパラメータへのアクセス

UIコンテナは、コンテナ内のすべてのアプリケーションにJavaScriptコンテキスト・オブジェクト(WemContext)を提供します。コンテキスト・オブジェクトは、アプリケーションでログイン済ユーザーやサイトに関する詳細情報をWEMフレームワークから取得するために使用します(通常は、UIコンテナから現在のサイトの名前を取得します)。また、コンテキスト・オブジェクトは、アプリケーションでデータを共有する際に使用する各種ユーティリティ・メソッドも提供します。コンテキスト・オブジェクトは、WebCenter Sitesと同一ドメインまたは異なるドメインで実行されているアプリケーションで使用できます。

注意:

wemcontext.htmlファイルには公開されるメソッドがリストされています(第72.5.3項「コンテキスト・オブジェクトで使用可能なメソッド」でまとめられています)。

この項の内容は、次のとおりです。

- 第72.5.1項「同一ドメイン用の実装」

- 第72.5.2項「クロスドメイン用の実装」

- 第72.5.3項「コンテキスト・オブジェクトで使用可能なメソッド」

72.5.1 同一ドメイン用の実装

WebCenter Sitesドメイン内にあるアプリケーションのコンテキスト・オブジェクトを初期化して使用するには:

1. wemcontext.jsを含めます(次のサンプル・コードの行1では、wemcontext.jsは<cs webapp path>/wemresources/js/WemContext.jsにあります)。

2. WemContextオブジェクトのインスタンスを取得します(行3)。

3. WemContextのメソッドを使用します(行4および5)。

例72-1 同一ドメイン用の実装のサンプル・コード

1. <script src='http://<csinstalldomain>/<contextpath>/wemresources/js/WemContext.js'></script>

2. <script type="text/javascript">

3. var wemContext = WemContext.getInstance(); // Instantiate Context Object

4. var siteName = wemContext.getSiteName(); // Get Site Name

5. var userName = wemContext.getUserName(); // Get UserName

6. </script>

72.5.2 クロスドメイン用の実装

クロスドメイン・アプリケーションのコンテキスト・オブジェクトを初期化して使用するには:

1. wemxdm.js、json2.jsおよびhash.htmlを(Misc/Samplesフォルダから)アプリケーションにコピーします。

2. クロスドメイン・コールを実行するために、sample.htmlファイルを開いて、次のように変更します。

1. wemxdm.js、json.jsおよびhash.htmlのパスを、アプリケーション内でのそれぞれのパスに変更します(後述のコードの行1から4を参照)。

2. wemcontext.htmlのパスを、WebCenter Sites内でのこのファイルの場所に変更します(wemcontext.htmlは/wemresources/wemcontext.htmlにあります。WebCenter Sitesのホスト名とコンテキスト・パスを使用します。行14を参照してください。)

3. インタフェース宣言で、フレームワークで使用するメソッドを指定します(行15)。

4. このメソッドをローカル・スコープに実装し、リモート・メソッドを起動します(行30)。

例72-2 クロスドメイン・コール用のsample.html

1. <script type="text/javascript" src="../js/wemxdm.js"></script>

2. <script type="text/javascript">

3. // Request the use of the JSON object

4. WemXDM.ImportJSON("../js/json2.js");

5. var remote;

6. window.onload = function() {

7. // When the window is finished loading start setting up the interface

8. remote = WemXDM.Interface(/** The channel configuration */

9. {

10. // Register the url to hash.html.

11. local: "../hash.html",

12. // Register the url to the remote interface

13. remote: "http://localhost:8080/cs/wemresources/wemcontext.html"

14. }, /** The interface configuration */

15. {

16. remote: {

17. getSiteName :{},

18. ...

19. }

20. },/**The onReady handler*/ function(){

21. // This function will be loaded as soon as the page is loaded

22. populateAttributes();

23. });

24. }

25. </script>

26. <script type="text/javascript">

27. /** Define local methods for accessing remote methods */

28. function getSiteName(){

29. remote.getSiteName(function(result){

30. alert("result = " + result);

31. });

32. }

33. ...

34. </script>

72.5.3 コンテキスト・オブジェクトで使用可能なメソッド

表72-1 コンテキスト・オブジェクトで使用可能なメソッド

戻り型

メソッド名および説明

オブジェクト

getAttribute(attributename)

指定された属性名の属性値を返します。

オブジェクト

getAttributeNames()

すべての属性名を返します。

オブジェクト

getCookie(name)

指定された名前のCookie値を返します。通常のブラウザのCookieの制限がすべて適用されます。

オブジェクト

getCookies()

すべてのCookieを返します。

オブジェクト

getLocale()

ロケールを返します。

オブジェクト

getSiteId()

サイトIDを返します。

オブジェクト

getSiteName()

サイト名を返します。

オブジェクト

getUser()

ユーザー・オブジェクトを返します。

オブジェクト

getUserName()

ユーザー名を返します。

void

removeCookie(name, properties)

Cookieを削除します。

void

setAttribute(attributename, attributevalue)

属性を設定します。これらの属性には、他のアプリケーションからアクセスできます。

void

setCookie(name,value,expiredays,properties)

Cookieを設定します。

72.6 登録コード

第70.5項「認可モデル」で説明しているように、アプリケーションは登録することによってWEMフレームワークで公開されます。アプリケーションを登録すると、FW_Applicationタイプのアセットと、アプリケーションに関連付けられた各ビューに対してFW_Viewタイプのアセットが作成されます。アセット・タイプは、AdminSiteで有効になります。アセット・タイプの属性の定義は、Oracle Fusion Middleware WebCenter Sites REST API Beanリファレンスを参照してください。プログラムによる登録をお薦めします。手動登録の例は、第78章「WEMフレームワーク: アプリケーションの手動登録」を参照してください。

この項の内容は、次のとおりです。

- 第72.6.1項「iframeビューを使用したアプリケーションの登録」

- 第72.6.2項「JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録」

72.6.1 iframeビューを使用したアプリケーションの登録

この項では、「Articles」サンプル・アプリケーションのコードを使用して登録プロセスについて説明します。「Articles」には、iframeタイプの単一ビューが含まれます。JavaScriptおよびHTMLのビューにも同じ手順が適用されます。

アプリケーションを登録するには:

1. アプリケーションを表すアイコンを作成または取得します。(アイコンは、アプリケーション・バーに表示されます。)
(「Articles」サンプル・アプリケーションは、次の場所にあるarticles.pngイメージ・ファイルを使用します。/sample app/articles/src/main/webapp/images/)

2. アプリケーションのレイアウト(つまり各ビュー)をHTMLで指定するファイルを作成し、ビューでレンダリングされるコンテンツを保持するためのプレースホルダ・エレメントを作成します。図72-4に、アプリケーションとビューの関係を示します。

たとえば、「Articles」サンプル・アプリケーションのlayout.jspには次の行が含まれます。

<div id="articles" style="float:left;height:100%;width:100%" class="wemholder"></div>

ビューのコンテンツは、アプリケーションが表示される際にプレースホルダ・エレメント内にレンダリングされます(layout.appがアプリケーションのレイアウトをレンダリングし、home.appがビューをレンダリングします)。

注意:

レイアウト・ファイルの作成時に、プレースホルダ・エレメントに一意のidを指定します。ビュー・オブジェクトをコーディングする際には、同じidをparentnode属性に指定します。プレースホルダ・エレメントにclass="wemholder"を使用します。

図72-4 アプリケーションとビュー

アプリケーションとビューは、多対多の関係にあります(図72-4)。1つのアプリケーションで複数のビューを使用でき、各ビューは複数のアプリケーションで使用できます。登録済のビューは(ビューのアセットIDによって)共有可能です。アセットIDが省略されている場合は、そのアプリケーションのコンテキスト内にビューが作成されます。ベーシックの場合、1つのアプリケーションに関連付けられるビューは1つのみです。

1. PUT wem/applications/{applicationid} RESTサービスを起動して、アプリケーションBeanを指定します。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");

登録プロセスの結果をテストするには、WEM Adminインタフェースに一般管理者としてログインし、メニュー・バーで「アプリケーション」を選択します。このページにアプリケーションが一覧表示されるはずです。

72.6.2 JavaScriptビューおよびHTMLビューを使用したアプリケーションの登録

HTMLビューおよびJavaScriptビューを使用するアプリケーションの場合、前の項の手順に従いますが、次に示すサンプル・コードと属性を使用します。

- 第72.6.2.1項「JavaScriptビュー」

- 第72.6.2.2項「HTMLビュー」

72.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: (第72.6.1項「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.ScriptRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- sourceurl: .jsファイルのパス。ビューのコンテンツを提供します。例: http://example.com:8080/js/drawTree.js

- ソース・コードからのJavaScriptビューのレンダリング
次の属性を設定します。

- name: ビューの名前

- parentnode: (第72.6.1項「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.ScriptRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- javascriptcontent: JavaScriptコード(前述のサンプル。<script>タグはコードに含めないでください。)

72.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: (第72.6.1項「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.IncludeRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- sourceurl: ビューのコンテンツを提供するHTMLファイルのパスです。例: http://example.com:8080/js/drawTree.jsp

- ソース・コードからのHTMLビューのレンダリング
次の属性を設定します。

- view: ビューの名前

- parentnode: (第72.6.1項「iframeビューを使用したアプリケーションの登録」の手順2からの)プレースホルダ・エレメントのID

- viewtype: fw.wem.framework.IncludeRenderer。プレースホルダ・エレメントにJavaScriptをレンダリングします。

- includecontent: HTMLコンテンツ(前述のサンプル。<html>または<body>タグはコードに含めないでください。)

73 WEMフレームワーク: カスタムRESTリソースの開発

この章には次の項が含まれます。

- 第73.1項「Recommendationsサンプル・アプリケーション」

- 第73.2項「RESTリソースの作成」

73.1 Recommendationsサンプル・アプリケーション

「Recommendations」サンプル・アプリケーションは、WebCenter SitesおよびSatellite ServerのRESTリソースを作成する方法を示しています。アプリケーションは、GETおよびPOST操作で、新しいRESTリソースsample/recommendations/<id>を登録します。これによって、静的リスト推奨を取得し変更できます。また、アプリケーションは、Satellite Serverキャッシング・システムをどのように活用できるかについても示しています。

この項の内容は、次のとおりです。

- 第73.1.1項「アプリケーションのビルドおよびデプロイ」

- 第73.1.2項「アプリケーションのテスト」

73.1.1 アプリケーションのビルドおよびデプロイ

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を再起動します。

73.1.2 アプリケーションのテスト

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レスポンスを確認します。

73.2 RESTリソースの作成

この項の内容は、次のとおりです。

- 第73.2.1項「アプリケーションの構造」

- 第73.2.2項「カスタムRESTリソースの実装手順」

73.2.1 アプリケーションの構造

「Recommendations」サンプル・アプリケーションは、独自のRESTリソースを作成する過程を通じて手順を説明することを目的に作成されています。

図73-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のantタスク「generate」を実行します。

- LocalRecommendationServiceは、RecommendationServiceインタフェースのローカル(WebCenter Sites)実装です。

- RemoteRecommendationServiceは、RecommendationServiceインタフェースのリモート(Satellite Server)実装です。

73.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属性です。

74 WEMフレームワーク: 本番サイトでのシングル・サインオン

SSOサンプル・アプリケーションは、配信ユースケースで駆動されます。本番サイトのアプリケーションを保護する場合、使用準備済のCASは使用できないため、ここではライブ・サイトでのアプリケーションのシングル・サインオンおよびサインアウトを有効にする際の簡単な例を示します。

この章には次の項が含まれます。

- 第74.1項「SSOサンプル・アプリケーションのデプロイ」

- 第74.2項「アプリケーションの構造」

- 第74.3項「シングル・サインオンの実装」

- 第74.4項「シングル・サインアウトの実装」

74.1 SSOサンプル・アプリケーションのデプロイ

1. wem-sso-api-cas-sample.warファイルを(/sso-sampleフォルダなどに)解凍します。アプリケーションは、WebCenter SitesのMisc/Samples/WEM Samples/ WEM Sample applications/ディレクトリにあります。

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つのリンクがあります(図74-1)。

図74-1 シングル・サインアウト用のリンクを含む保護付きページ

1つ目のリンク(リダイレクトありのシングル・サインアウト)は、CAS側でシングル・サインアウトを実行し、ユーザーをホーム・ページにリダイレクトするHTMLリンクです。2つ目のリンク(リダイレクトなしのシングル・サインアウト)もHTMLリンクですが、CAS側でシングル・サインアウトを実行しても、現在のページから遷移したり、再ロードが発生したりすることはありません。

- 公開領域: 保護フィルタから除外されるページ。

- ログイン・フォームを含む公開領域: このページは保護フィルタから除外されますが、ページ内にログイン・フォームがあります。ログイン・フォームではサインイン操作を実行できますが、現在のページから遷移したり、再ロードが発生したりすることはありません。

図74-2 「サインイン」リンクを含む公開領域

74.2 アプリケーションの構造

SSOサンプル・アプリケーションには、本番サイトでシングル・サインオンおよびサインアウト機能を使用して、アプリケーションを保護するための基本コードが用意されています。次のコンポーネントを使用して、SSOサンプル・アプリケーションにアクセスします。

- index.jsp: 開始ページ。このページには、「保護されている領域」、「公開領域」および「ログイン・フォームを含む公開領域」の各ページ(第74.1項「SSOサンプル・アプリケーションのデプロイ」を参照)へのリンクがあります。

- template.html: CAS用のカスタム・サインイン・フォームを指定する際に使用します。このファイルへのパスは、applicationContext.xmlファイルのcasLoginPathにあるwemLoginTemplateパラメータで参照します。

構成ファイル: /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ページからコールされます。

74.3 シングル・サインオンの実装

Webサイトでシングル・サインオンを実装する場合、サインイン・フォームを実装することになります。サインイン・フォームは、次の2つのいずれかの方法でサイト訪問者に表示できます。

- 保護付きページに訪問者がアクセスしようとすると、サインイン・フォームが表示されます。これは、デフォルトのサインイン実装です。このサインイン・フォームには、CASに付属のデフォルト・サインイン・フォームまたはアプリケーションが提供するカスタム・フォームを指定できます。

- サインイン・フォームを公開ページに埋め込むと、ユーザーが現在のページから遷移することなくサインイン機能が実行されます。この動作を実装するには、保護付きページを指すiframeを埋め込みます。そのページは保護されているので、訪問者にはサインイン・フォームが表示されます。

74.4 シングル・サインアウトの実装

シングル・サインアウトをWebページで実装する場合、次のいずれかの方法で実行できます。

- 次のメソッドを起動して、シングル・サインアウトURLを取得します。
com.fatwire.wem.sso.SSO.getSSOSession()オブジェクトのgetSignoutUrl()またはgetSignoutUrl(String callbackUrl)メソッド。

シングル・サインアウト後に、必要に応じて、訪問者が指定したURLにCASからリダイレクトできます。これは、callbackUrlパラメータで設定します。

- 現在のページから遷移せずにシングル・サインアウトを実行するには、iframeの埋込み手法を使用します。この手法では、ソースにシングル・サインアウトURLを含むiframeを埋め込む必要があります。iframeがロードされると、サインアウトURLがコールされます(この方法は主に、ブラウザでのクロスドメイン制限を回避する場合に使用されます)。

75 WEMフレームワーク: RESTリソースの使用

この章には次の項が含まれます。

- 第75.1項「RESTリソースの認証」

- 第75.2項「CASの構成」

- 第75.3項「REST認可」

- 第75.4項「RESTを介したアセットの管理」

75.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パラメータはいずれも回数に制限がありますが、一般的な使用パターンが異なります。ticketはコールごとに取得されるので有効期限を気にする必要がありません。一方、同じmultiticketを再利用すると最終的に期限切れとなり、HTTP 403エラーが発生します。期限切れになった場合、アプリケーションでこのような動作を認識して、そのmultiticketを再取得できる必要があります。ticketとmultiticketのどちらを使用するかは、アプリケーション開発者が決定します。

この項の内容は、次のとおりです。

- 第75.1.1項「Javaコードからのチケットの取得」

- 第75.1.2項「他のプログラミング言語からのチケットの取得(HTTPを経由)」

- 第75.1.3項「チケットおよびマルチチケットの使用」

- 第75.1.4項「スタンドアロン・アプリケーションのSSO構成」

75.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)

75.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リクエストを発行します。レスポンス本文には実際のチケットが含まれます。

75.1.3 チケットおよびマルチチケットの使用

生成されたチケット/マルチチケットを使用するには、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

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が実行します。

- 入力: チケット/マルチチケット

- 出力: アサーション

デフォルトでは、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間の通信チャネルの信頼性を確保する必要があることに注意してください。

75.1.4 スタンドアロン・アプリケーションのSSO構成

シングル・サインオン・モジュールはSpring構成に基づいています。唯一必要なBeanはssoproviderで、これはssoconfig Beanを参照しています。

この項の内容は、次のとおりです。

- 第75.1.4.1項「Beanおよびプロパティ」

- 第75.1.4.2項「SSOフィルタで処理される問合せパラメータ」

75.1.4.1 Beanおよびプロパティ

id="ssolistener", class="com.fatwire.wem.sso.cas.listener.CASListener"

表75-1 id="ssolistener"

プロパティ

説明

このBeanにはプロパティはありません。

なし

id="ssofilter",
class="com.fatwire.wem.sso.cas.filter.CASFilter"

表75-2 id="ssofilter"

プロパティ

説明

config

必須。SSO構成参照です。

サンプル値: ssoconfig

provider

必須。SSOプロバイダ参照です。

サンプル値: ssoprovider

id="provider",
class="com.fatwire.wem.sso.cas.CASProvider"

表75-3 id="provider"

プロパティ

説明

config

SSO構成参照です。

サンプル値: ssoconfig

id="config",
class="com.fatwire.wem.sso.cas.conf.CASConfig"

表75-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の接頭辞です。

例: 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>,#]

例

第73.1項「Recommendationsサンプル・アプリケーション」のカスタムRESTリソースに指定する場合は、/ContentServer?[pagename=rest/sample/recommendation,#]です。

proxyTickets

チケットをプロキシするかどうかを指定します。

コール・チェーンの最後のサーバーに対してこのプロパティをfalseに設定すると、パフォーマンスが最適化されます。

現在のログイン済ユーザーの代理としてこのアプリケーションからCASで保護された別のアプリケーションをコールする必要がある場合は、このプロパティをtrueに設定します。これにより、メソッドSSO.getSSOSession().getTicket(String service, String username, String password)をコールできるようになります。

デフォルト値: true

useMultiTickets

マルチチケットを使用するかどうかを指定します。

デフォルト値: true

75.1.4.2 SSOフィルタで処理される問合せパラメータ

表75-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

75.2 CASの構成

CASクラスタリングに関する情報は、次のソースを参照してください。

- CASアーキテクチャの詳細は、次のリンクを使用してください。
http://www.jasig.org/cas/about

- WebCenter Sitesのインストール時にCASクラスタリングを構成する方法の詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。

- LDAPプロバイダでCASを構成する方法の詳細は、次のリンクを使用してください。
http://www.jasig.org/cas/server-deployment/authentication-handler

75.3 REST認可

この項は、管理者の認可プロセスに関心のある開発者を対象としています。REST認可は、アプリケーションのリソース(WebCenter Sites内のオブジェクトにマップされる)に対してRESTの各操作を実行するための権限を付与するプロセスです。REST認可は、「デフォルトではすべてを拒否」するモデルを使用します。権限が特定のグループに対して明確に付与されていない場合、その権限は拒否されます。

この項の内容は、次のとおりです。

- 第75.3.1項「セキュリティ・モデル」

- 第75.3.2項「RESTリソースへのセキュリティ・モデルを使用したアクセス」

- 第75.3.3項「RESTセキュリティの構成」

- 第75.3.4項「権限解決アルゴリズム」

75.3.1 セキュリティ・モデル

WEMセキュリティ・モデルはオブジェクト、グループおよびアクションに基づいています。セキュリティは、WebCenter Sites Adminインタフェースでオブジェクト・タイプごとに構成する必要があります。

- オブジェクトは、サイト、ユーザー、アセットなど、WEMフレームワーク内のエンティティを示す総称です。保護オブジェクトには次のタイプがあります。

- アセット・タイプ

- アセット

- 索引

- サイト

- ロール

- ユーザー

- ユーザー・ロケール

- ACL

- アプリケーション

- セキュリティ・グループは、ユーザーを集約して、ユーザーの(オブジェクトへの操作)権限を同時に管理するために使用します。

- アクションは、LIST、READ、UPDATE、CREATE、DELETEの各セキュリティ権限です。LISTはオブジェクトをリストするサービス(/typesなど)に対するGET権限を提供し、READは個々のオブジェクトの詳細を取得するサービス(/types/{assettype}など)に対するGET権限を提供します。
権限は、許可されたオブジェクトを操作するためにグループに割り当てられます。ACLなど一部のオブジェクトは読取り専用です(WebCenter Sitesで直接作成できますが、RESTを介して作成できません)。

前述のように、セキュリティ構成とは1つの配列です。セキュリティ構成では次を指定します。

- 保護されているオブジェクト・タイプおよびオブジェクト

- オブジェクトにアクセス可能なグループ

- グループ(およびそのメンバー)がオブジェクトに実行できるアクション

可能なセキュリティ構成およびWebエクスペリエンス管理フレームワークの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

75.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 Fusion Middleware WebCenter Sites REST APIリソース・リファレンス』を参照してください。

75.3.3 RESTセキュリティの構成

RESTセキュリティ構成およびWebエクスペリエンス管理フレームワークの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

75.3.4 権限解決アルゴリズム

セキュリティ権限を構成する際に、特定のタイプのすべてのオブジェクトまたは特定のタイプの単一のオブジェクトに権限が適用されるように指定できます。たとえば、UPDATE (POST)への権限を任意のサイトに付与すると、グループ内のユーザーはすべてのサイトの詳細をWEMフレームワークで変更できるようになります。UPDATE (POST)への権限をFirstSiteIIサンプル・サイトに付与すると、グループ内のユーザーはこのサイトの詳細を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のグループのリストで該当する場合、アクセスが許可されます。そうでない場合は、アクセスが拒否されます。

75.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

コードは、段階を追った説明によって詳細に文書化されています。ベーシック・アセット管理の例では、HelloAssetWorldサンプル・サイトを使用します。フレックス・アセット管理の例では、FirstSiteIIサンプル・サイトを使用します。必要なアセット・タイプおよびアセットに関するすべての情報は、javaファイルを参照してください。

76 WEMフレームワーク: Customizable Single Sign-Onファシリティ

この章には次の項が含まれます。

- 第76.1項「WEMフレームワークのログイン動作のカスタマイズ」

- 第76.2項「デフォルトCSSO実装のコンポーネント」

- 第76.3項「カスタムSSO動作の構成およびデプロイ」

- 第76.4項「CSSOサンプル実装の実行」

76.1 WEMフレームワークのログイン動作のカスタマイズ

WEMフレームワーク認証は、CASフレームワーク上に構築され、Oracle Customizable Single Sign-On (CSSO)ファシリティというカスタマイズ・レイヤーが備わっています。CSSOファシリティには、カスタムSSOソリューションを作成するために使用可能な認証の拡張が含まれているため、CAS構成を直接変更する必要はありません。かわりに、Spring構成でこれらの拡張をCAS構成に直接注入して、必要なログイン動作を実装します。

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サンプルおよびこのサンプルの実行手順を参照してください。

76.2 デフォルトCSSO実装のコンポーネント

この項では、CSSOファシリティで提供されるデフォルトのコンポーネントについて説明します。これらのコンポーネントは、独自のSSO実装をカスタマイズするための開始点となります。

com.fatwire.wem.sso.cas.custom.basisパッケージ(表76-1を参照)には、CSSOファシリティに含まれているデフォルト・クラスがあります。デフォルトSpring構成ファイル(customdefaultWEMSSObeans.xml)は、デフォルトWEMログイン動作を実装するためにこれらのクラスをインスタンス化します。

注意:

CSSOファシリティでは、デフォルトWEMログイン動作をカスタム・ログイン動作で置き換える完全なSSOサンプルが用意されています。詳細は、第76.4項「CSSOサンプル実装の実行」を参照してください。

表76-1 com.fatwire.wem.sso.cas.custom.basis

クラス

説明

CustomAuthenticator.java

CustomAuthenticationインタフェースを実装します。このクラスは、ログイン・シーケンスの動作を制御し、認証リクエストを処理します。デフォルトでは、標準のWEMログイン・フォームを表示して、認証を完了するためにWEMフレームワークに戻ります。

このクラスの拡張の詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

CustomConfiguration.java

デフォルトSpring構成ファイルで設定されているプロパティへのアクセスを提供します。追加のプロパティがカスタムSSO実装に必要な場合にはこのクラスを拡張できます。

このクラスの拡張の詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

CustomCredentials.java

カスタム認証に対して資格証明値の標準セットを提供します。追加の属性がカスタムSSO実装に必要な場合にはこのクラスを拡張できます。

このクラスの拡張の詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

com.fatwire.wem.sso.cas.custom.interfacesパッケージ(表76-2を参照)では、カスタム認証インタフェースを定義します。

表76-2 com.fatwire.wem.sso.cas.custom.interfaces

クラス

説明

CustomAuthentication.java

カスタムSSOソリューションで実装する必要があるインタフェースを定義します。

詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

CustomRestCodec.java

ユーザー名/パスワード・ベースではないカスタムREST認証トークンをエンコードおよびデコードするために実装する必要のあるインタフェースを定義します。

76.3 カスタムSSO動作の構成およびデプロイ

カスタムSSO動作を構成およびデプロイするには、最初にCSSOファシリティに含まれているデフォルトのクラスを拡張する必要があります。その後、クラスをインスタンス化するカスタムSpring構成ファイルを作成し、それらのクラスをCSSOフレームワークに公開して、Springに新しいJavaクラスを指定します。基本的な手順は次のとおりです。

1. デフォルトCSSOクラスを次のように拡張します。CustomAuthenticator.java、CustomConfiguration.javaおよびCustomCredentials.java (com.fatwire.wem.sso.cas.custom.basisパッケージ内に含まれます)。

1. デフォルトCSSOクラスを拡張する新しいJavaクラスを作成します。

2. 作成したJavaクラスをjarファイルにパッケージ化し、そのjarファイルをCASサーブレット(cas/WEB-INF/lib)のクラスパスに配置します。

詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

2. Springにインスタンス化する新しいJavaクラスを次のように指定します。

1. SSO実装用のカスタム・クラス名およびプロパティのすべてを含むSpring構成ファイルを作成します。

2. カスタムSpring構成ファイルをspring-configurationフォルダ(cas/WEB-INF/)に配置します。

3. デフォルトSpring構成ファイル(customDefaultWEMSSObeans.xml)から.xml拡張子を削除します。

詳細は、第76.3.2項「Springへのインスタンス化するJavaクラスの指定」を参照してください。

3. 外部認証局がユーザーの認証に使用される場合は、外部ユーザー識別子を適切なWebCenter Sitesシステムのユーザー名、一意の識別子およびACLにマップします。手順については、第76.3.3項「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

4. CAS Webアプリケーションを再起動します。詳細は、第76.3.4項「CAS Webアプリケーションの再起動」を参照してください。

この項の残りの部分では、前述の手順の詳細を説明します。

76.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フロー・ハンドラまたはカスタム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オーセンティケータに対する一意の名前を定義する必要があります。詳細は、第76.3.3項「外部ユーザー識別子の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);

76.3.2 Springへのインスタンス化するJavaクラスの指定

SSO実装のすべてのカスタマイズ設定は、spring-configurationフォルダ(cas/WEB-INF)にある、単一のSpring構成ファイルで指定されます。

この項の残りの部分は、次のトピックで構成されます。

- 第76.3.2.1項「Spring構成ファイルの作成」

- 第76.3.2.2項「Spring構成ファイルの配置」

76.3.2.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構成ファイル

1. <?xml version="1.0" encoding="UTF-8"?>

2. <beans xmlns="http://www.springframework.org/schema/beans"

3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

4. xmlns:flow="http://www.springframework.org/schema/webflow-config"

5. xmlns:p="http://www.springframework.org/schema/p"

6. xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

7. http://www.springframework.org/schema/webflow-config http://www.springframework.org/schema/webflow-config/spring-webflow-config-1.0.xsd">

8. <!-- 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 -->

9. <!-- This bean is never modified. It defines the web-flow controller which always passes control into

the custom authenticator -->

10. <bean id="customUserLoginAction" class="com.fatwire.wem.sso.cas.web.CustomLoginViewAction"

11. p:centralAuthenticationService-ref="centralAuthenticationService"

12. p:customAuthentication-ref="customUserAuthenticator"

13. />

14. <!-- 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 -->

15. <bean id="customRestCoder" class="com.fatwire.wem.sso.cas.custom.basis.CustomRestTokenCoding"

16. />

17. <!-- Modify this bean with a custom configuration implementation class when additional parameters are

needed for a custom implementation -->

18. <bean id="customUserConfiguration" class="com.fatwire.wem.sso.cas.custom.basis.CustomConfiguration"

19. p:casLoginUrl="http://localhost:7080/cas/login"

20. p:resolverUrl="http://localhost:8080/cs/custom/customCsResolver.jsp"

21. p:resolverUsername="fwadmin"

22. p:resolverPassword="xceladmin"

23. p:traceFlag="false"

24. />

25. <!-- Modify this bean with a customAuthentication class for a custom implementation. -->

26. <bean id="customUserAuthenticator" class="com.fatwire.wem.sso.cas.custom.basis.CustomAuthenticator"

27. p:customConfiguration-ref="customUserConfiguration"

28. p:customRestCoder-ref="customRestCoder"

29. />

30. </beans>

デフォルトSpring構成ファイルの分析

- 行18は、デフォルトのCSSO customConfiguration.javaクラスを参照する、customUserConfiguration Beanです。このクラスの詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。このBeanには、デフォルトSSO実装に必要なプロパティも含まれます。

- 行19は、casLoginURLプロパティを参照します。このプロパティは、CASログイン機能へのベースURLを指定します。指定された値がCASサーバー・インストールとは異なる場合、ドメインおよびポート番号設定を変更する必要があります。

- 行20から22は、外部認証プロパティresolverURL、resolverUsernameおよびresolverPasswordを参照します。WebCenter Sitesがユーザーの認証に使用される場合、これらのプロパティを参照する必要はありません。外部認証局がユーザー認証に使用される場合、これらのプロパティを参照する必要があります。これらのプロパティが参照されると、外部識別子からWebCenter Sitesシステム・ユーザーへのマッピングを実装できます。

- 行20は、resolverURLプロパティを参照します。外部認証局がユーザーの認証に使用される場合、このプロパティは、WebCenter Sitesにある、customCsResolverページへの完全なURLを指定する必要があります。customCsResolverページは、ユーザーの外部識別子を取得し、WebCenter Sitesデータベースに問い合せてユーザーのWebCenter Sites資格証明を取得します。このプロパティで指定されるドメインとポート番号は、指定された値がWebCenter Sitesインストールの値と異なる場合は変更する必要があります。

- 行21は、resolverUsernameプロパティを参照します。外部認証局がユーザーの認証に使用される場合、このプロパティは、SystemUserAttr表を読み取る権限を持つWebCenter Sitesユーザーのユーザー名を指定する必要があります。このユーザー名は、customCsResolverページでWebCenter Sitesデータベースを問い合せて登録済WebCenter Sitesユーザーに外部ユーザー識別子を解決する場合に使用されます。

- 行22は、resolverPasswordプロパティを参照します。外部認証局がユーザーの認証に使用される場合、このプロパティはresolverUsernameプロパティ(行21)で指定されたユーザーのパスワードを指定する必要があります。

マッピングの実装の詳細は、第76.3.3項「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

- 行23は、traceFlagプロパティを参照します。このプロパティは、カスタムSSOレイヤーに関する情報を提供するトレース・ログを有効にするか無効にするかを指定します。このプロパティは、TrueまたはFalseのいずれかに設定できます。

- 行26は、デフォルトCSSO CustomAuthenticator.javaクラスを参照する、customUserAuthenticator Beanです。このクラスの詳細は、第76.3.1項「デフォルトCSSOクラスの拡張」を参照してください。

76.3.2.2 Spring構成ファイルの配置

デフォルトWEMログイン動作のためのクラスとプロパティを指定するデフォルトSpring構成ファイルは、spring-configurationフォルダ(cas/WEB-INF)にあります。独自のファイルを同じ場所に配置するには、デフォルトのファイルを非アクティブ化する必要があります(ファイルの.xml拡張子を削除するか変更します)。これは、Springではspring-configurationフォルダ(cas/WEB-INF)に含まれるすべてのSpring構成ファイルがロードされ、これらのファイルが単一の構成にマージされるためです。カスタムおよびデフォルトの両ファイルは同じBean識別子を指定するため、これらのファイルの一方のみをSpring構成で認識できます。Bean識別子が重複すると、初期化が失敗します。

注意:

customDefaultWEMSSObeans.xmlを削除しないでください。かわりに、ファイルの.xml拡張子を削除するか変更してください。こうすると、デフォルトWEMログイン画面の使用に戻る場合にファイルをリストアできます。

76.3.3 外部ユーザー識別子のWebCenter Sites資格証明へのマッピング

CSSOファシリティでは、WebCenter Sitesユーザーの認証に外部認証局を使用できます。外部認証局では、ユーザーの資格証明を検証するときに、一意の外部識別子をそのユーザーに関連付けます。WEM認証を完了するには、(デフォルトCSSOクラスCustomAuthenticator.javaの静的メソッドとして定義される)メソッドcallCsResolverPageを使用して、ユーザーの外部識別子を対応するWebCenter Sitesのシステム・ユーザー名、一意の識別子およびACLにマップする必要があります。

外部識別子をWebCenter Sitesシステム・ユーザーにマップするには、Spring構成ファイルで外部認証プロパティを設定していることを確認してください(第76.3.2.1項「Spring構成ファイルの作成」の「デフォルトSpring構成ファイルの分析」を参照)。外部識別子から適切なWebCenter Sitesシステム資格証明へのマッピングを実装するには、次の操作を実行します。

マッピングを実装するには:

1. (拡張されたCustomAuthenticator.javaクラスで定義された) callCsResolverPageメソッドでカスタムSSO実装の外部認証局に一意のCSSOオーセンティケータ名を定義します。

たとえば、(サンプルCSSOクラスSampleAutheticator.javaで定義される)次のcallCsResolverPageメソッドは、一意のオーセンティケータ名として"samplesso"を定義します。

Map<String,String>csTokens=callCsResolverPage(externalUserId, "samplesso")

2. 一般管理者(たとえば、fwadmin/xceladmin)としてWebCenter Sites Adminインタフェースにアクセスします。

3. 「管理」タブで、「管理ツール」ノードを開き、「ユーザー」をダブルクリックします。

4. 外部識別子をWebCenter Sites資格証明にマップするユーザーを次のように選択します。

1. 「ユーザー名の入力」フィールドで、ユーザーの名前を入力します。

2. 「操作の選択」セクションで、「ユーザー属性の修正」オプションを選択します。

3. 「OK」をクリックします。
「ユーザーの修正」フォームが次のように表示されます。

5. 「ユーザー名」列で、外部識別子をWebCenter Sites資格証明にマップするユーザーの名前をクリックします。
次のフォームが表示されます。

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ユーザーを特定する、レスポンス・マップを作成します。

76.3.4 CAS Webアプリケーションの再起動

カスタムSSO実装をデプロイするには、CAS Webアプリケーションを再起動します。CASが再起動したら、spring-configurationフォルダ(cas/WEB-INF)にある、カスタムSpring構成ファイルで定義されたクラスを使用して、カスタム・ログイン動作を提供します。

76.4 CSSOサンプル実装の実行

CSSOファシリティには、カスタムSSO実装(Javaソース・ファイルを含む)の実行例が用意されています。サンプルでは、デフォルトのWEMログイン動作をカスタム・ログイン動作で置き換えています。これには、標準のユーザー名フィールドとパスワード・フィールド、ドメイン名を指定するためのユーザー用の追加フィールド、外部ユーザー識別子のフィールドが含まれます。ここでは、2種類の異なる認証、つまりユーザー名/パスワードのペア(追加のドメイン・フィールドを含む)と、外部認証局を通じたユーザー認証を示しています。

注意:

CSSOサンプルでは、ログイン・フォーム上のフィールドに適用される検証ルールは実行されません。フィールドに対する完全性はチェックされず、不正な値もレポートされません。認証が失敗すると、フォームはコメントなしに再度表示されます。本番環境でこのフォームを実装する場合、エラーが発生したら、適切な診断メッセージを使用してすべてのルールが実施されるようにする必要があります。

CSSOファシリティに含まれるすべてのサンプル・コンポーネントの詳細は、第76.4.3項「サンプルCSSOコンポーネント」を参照してください。

サンプルSSO実装を実行するには:

1. CASクラスパス(cas/WEB-INF/libフォルダ)に配置して、customizable-sso-1.0.jar (Misc/Samples/WEM Samples/CustomizableSSO)をデプロイします。このファイルには、サンプルCSSOクラスが含まれます。
サンプル・クラスの詳細は、第76.4.1項「サンプルCSSOクラス」を参照してください。

2. CAS Webアプリケーション・コンテキスト・フォルダ内にfatwireフォルダを作成します。SampleLoginform.jspファイルをfatwireフォルダにコピーします。

3. customizable-sso-1.0.jarファイルに含まれるクラスがインスタンス化されるように、Springに対して次のように指定します。

1. customSampleSSObeans.xml構成ファイルをspring-configurationフォルダにコピーします。

2. customSampleSSObeans.xmlファイルのプロパティを操作環境に一致するように変更します。

3. spring-configurationフォルダにあるcustomDefaultWEMSSObeans.xml構成ファイルの名前から.xml拡張子を削除します。

サンプルSpring構成ファイルの詳細は、第76.4.2項「サンプルSpring構成ファイル」を参照してください。

4. 外部識別子の資格証明を使用してユーザーを検証する場合は、SystemUserAttr表に適切なエントリを追加して、外部ユーザー識別子とユーザーのWebCenter Sitesシステム資格証明とのマッピング関係を定義します。
手順については、第76.3.3項「外部ユーザー識別子のWebCenter Sites資格証明へのマッピング」を参照してください。

5. CAS Webアプリケーションを再起動します。
サンプルのログイン・フォームは次のように表示されます。

76.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認証ハンドラがユーザー名とパスワードを検証します。

76.4.2 サンプルSpring構成ファイル

サンプルSSO実装のクラスおよびプロパティは、(Misc/Samples/WEM Samples/CustomizableSSO/src/main/webapp/WEB-INF/spring-configurationにある)サンプルSpring構成ファイルcustomSampleSSObeans.xmlで定義されています。

この項の残りの部分は、次のトピックで構成されます。

- 第76.4.2.1項「サンプルSpring構成ファイルの分析」

- 第76.4.2.2項「サンプルSpring構成ファイルの配置」

76.4.2.1 サンプルSpring構成ファイルの分析

サンプルSpring構成ファイルには、デフォルトSpring構成ファイルと同じBean識別子が含まれます(第76.3.2.1項「Spring構成ファイルの作成」を参照)。ただし、サンプルのログイン動作を実装するには、プロパティ値を変更します。たとえば、customUserConfiguration BeanはSampleConfiguration.javaクラスを参照し、customUserAuthenticator BeanはSampleAuthenticator.javaクラスを参照します。

また、customUserConfiguration Beanには、サンプルSSO実装にシステム情報を提供する構成プロパティも指定します。たとえば、SampleLoginForm.jspファイルでは、ユーザーの資格証明を取得するためにサンプルで使用されるブラウザ・フォームが提供されるため、SampleConfiguration.javaクラスを拡張して、sampleFormURLプロパティを含めます。このプロパティには、サンプルSSO実装用のログイン・ページの完全なURLを指定します。ドメイン名とポート番号は、CASサーバー・インストールに一致させ、パスは、設定中にこのページが配置された場所を指します。

次に、サンプルSpring構成ファイルのコードを示します。このファイルで参照されるプロパティの詳細は、第76.3.2.1項「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 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:7080/cas/login"
p:resolverUrl="http://localhost:8080/cs/custom/customCsResolver.jsp"
p:resolverUsername="fwadmin"
p:resolverPassword="xceladmin"
p:traceFlag="false"
p:sampleDomain="mydomain"
p:sampleFormUrl="http://localhost:7080/cas/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>

76.4.2.2 サンプルSpring構成ファイルの配置

サンプル・クラスをインスタンス化するには、サンプルSpring構成ファイルをspring-configurationフォルダ(cas/WEB-INF)に配置して、デフォルトSpring構成ファイルから.xml拡張子を削除します。詳細は、第76.3.2.2項「Spring構成ファイルの配置」を参照してください。

76.4.3 サンプルCSSOコンポーネント

サンプルCSSO実装のコンポーネントは、/WEM Samples/CustomizableSSOフォルダにあります。次のフォルダがサンプルCSSO実装に含まれています。

表76-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ログイン画面に戻る場合にそのコピーをリストアできるようにします。

77 WEMフレームワーク: バッファリング

アセットの作成、更新、削除操作は、読取り操作と比べるとはるかに低速です。場合によっては、これらの操作を遅延させて、最終的に一貫性が保証される形で後で操作が行われるようにすることも可能です。つまり、遅延(バッファ済)操作を実行すると、有限で不確定な時間にWebCenter Sitesプラットフォームが変更を受け取ることが保証されます。バッファリング操作はきわめて高速ですが、プラットフォームでのアセットの作成、更新、削除に必要な合計時間が短縮されるわけではありません。

この章には次の項が含まれます。

- 第77.1項「アーキテクチャ」

- 第77.2項「バッファリングの使用」

77.1 アーキテクチャ

バッファリング・サブシステムの現在の実装は、Java Messaging Service (JMS)テクノロジに依存しています。

バッファリングは次のコンポーネントで構成されます。

- バッファリング・プロデューサ。メッセージを生成し、それをメッセージング・キュー(MQ)に入れます。

- バッファリング・コンシューマ。MQからメッセージを取得し、それをプラットフォームで維持します。

バッファリング・プロデューサは、アセットRESTサービス<BaseURI>/sites/<sitename>/types/<assettype>/assets/<id>が使用可能な場合は、WebCenter SitesとリモートSatellite Serverの両方で使用できます。リモートSatellite Serverで使用する場合、バッファリング・プロデューサはWebCenter Sitesとの通信を行いません。その結果、システム全体の線形スケーラビリティが確保されます。

注意:

バッファリング・コンシューマは、WebCenter Sitesでのみ使用できます。バッファリング・コンシューマは、プライマリ・クラスタ・メンバーのみで有効にすることをお薦めします。複数のクラスタ・メンバーで有効にすると、CRUD操作の順序が保証されません。

77.2 バッファリングの使用

1. JMSプロバイダがまだインストールされていない場合はインストールします。サポート対象のプロバイダについては、Oracle Technology Network (http://otn.oracle.com)から入手可能なOracle Fusion Middleware WebCenter Sites動作保証マトリックスを参照してください。

2. WebCenter Sites(およびオプションでリモートSatellite Server)でBufferingConfig.xmlを構成します。

id="bufferingManager" class=
"com.fatwire.cs.core.buffering.jms.JmsBufferingManager"

表77-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で同じです。

78 WEMフレームワーク: アプリケーションの手動登録

第70章「WEMフレームワーク: フレームワークとサービスについて」で説明されているように、アプリケーションは登録することによってWEMフレームワークで公開されます。アプリケーションを手動で登録するには、WebCenter Sites Adminインタフェースを使用してアプリケーションのアセットを作成し、アセットの各ビューにアセットを作成して、ビュー・アセットをアプリケーション・アセットに関連付ける必要があります。登録アセット・タイプFW_ApplicationおよびFW_ViewがAdminSite有効化されます。

この章には次の項が含まれます。

- 第78.1項「登録手順」

- 第78.2項「リファレンス: 登録アセット・タイプ」

78.1 登録手順

アプリケーションおよびビューを手動で登録するには:

この項では、「Articles」サンプル・アプリケーションのコードを使用して登録プロセスについて説明します。「Articles」には、iframeタイプの単一ビューが含まれます。JavaScriptおよびHTMLのビューにも同じ手順が適用されます。

1. アプリケーションを表すアイコンを作成または取得します。(アイコンは、アプリケーション・バーに表示されます。)
「Articles」サンプル・アプリケーションは、次の場所にあるarticles.pngイメージ・ファイルを使用します。/sample app/articles/src/main/webapp/images/

2. アプリケーションのレイアウト(つまり各ビュー)をHTMLで指定するファイルを作成し、ビューでレンダリングされるコンテンツを保持するためのプレースホルダ・エレメントを作成します。図72-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. ビューおよびアプリケーションを登録します。

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインし、AdminSiteに移動して「管理」タブをクリックします。このタブでは、FW_ViewおよびFW_Applicationアセット・タイプが有効になります。
(ここでは、ビューおよびアプリケーションのアセットを同一セッション内で作成することを想定しています。この場合、「履歴」タブに両方のアセットが一覧表示されます。アプリケーション・アセットの作成時に、「履歴」タブからビュー・アセットを選択し、アプリケーション・アセットに関連付けます。「履歴」タブの情報は一時的なものであるため、ユーザーのセッションの最後にクリアされます。アクティブ・リスト・タブでは、アセットを永続的に配置できます。手順については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。)

2. 次のように、FW_Viewアセット・タイプのインスタンスを作成します。

「新規」をクリックして「新規FW_View」を選択し、次の図に示すように属性を設定します。(次の図には、「Articles」サンプル・アプリケーションのビュー・アセットの属性値が表示されています。)

名前: このビュー・アセットの短くてわかりやすい名前を入力します。

親ノード: (第78.1項「登録手順」の手順2で定義した)プレースホルダ・エレメントのidを入力します。プレースホルダ・エレメントには、ビューでレンダリングされたコンテンツが保持されます。

ビュー・タイプ: 次のいずれかのオプションを選択して、ビューのコンテンツをプレースホルダでレンダリングする方法を指定します。

- Iframe: プレースホルダ・エレメントにiframeのビューをレンダリングします。

- IncludeHTML: プレースホルダ・エレメントにHTMLをレンダリングします。

- IncludeJavaScript: プレースホルダ・エレメントにJavaScriptをレンダリングします。

ソースURL: ビューのコンテンツを提供するURLを入力します。たとえば、「Articles」サンプル・アプリケーションの「ソースURL」の値は次のようになります。http://localhost:9080/articles-1.0/home.app

3. 次のように、FW_Applicationアセット・タイプのインスタンスを作成します。
「新規」をクリックして「新規FW_Application」を選択し、次の図に示すように属性を設定します。(次の図には、「Articles」サンプル・アプリケーションのアプリケーション・アセットの属性値が表示されています。)

名前: このアプリケーション・アセットの短くてわかりやすい名前を入力します。

ツールチップ: ユーザーがアプリケーションのアイコンにマウスを重ねたときにアイコン上に表示されるテキストを入力します。

アイコン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: ビュー: 第78章「登録手順」の手順3で作成したビュー・アセットを選択します(「履歴」タブをクリックしてビュー・アセットを選択し、「選択したアイテムの追加」をクリックします)。

78.2 リファレンス: 登録アセット・タイプ

この項の内容は、次のとおりです。

- 第78.2.1項「FW_Viewアセット・タイプ」

- 第78.2.2項「FW_Applicationアセット・タイプ」

78.2.1 FW_Viewアセット・タイプ

このアセット・タイプはアプリケーションのビューを登録する際に使用します。各ビューに対してFW_Viewのインスタンスを作成します。WebCenter Sites Adminインタフェースに表示されるFW_Viewの属性は、次の一覧およびOracle Fusion Middleware WebCenter Sites REST API Beanリファレンスを参照してください。網掛け部分は必須属性であることを示しています。このアセット・タイプは、「AdminSite」という名前のサイトで有効になります。

表78-1 FW_Viewアセット・タイプの属性

属性: WebCenter Sitesインタフェース

属性: REST API

説明

名前

name

このビュー・アセットの短くてわかりやすい名前。

説明

説明

このビュー・アセットの説明。

親ノード

parentnode

アプリケーションのレイアウト・ファイルにおけるプレースホルダ・エレメントのID。プレースホルダ・エレメントには、ビューでレンダリングされるコンテンツが保持されます。レイアウト・ファイルには、ビューを配置するためのHTMLプレースホルダ・エレメント(divなど)のみが含まれます。

ビュー・タイプ

viewtype

ビューをレンダリングする方法。次のビュー・タイプを使用できます。

Iframe: プレースホルダ・エレメントにiframeのビューをレンダリングします。

IncludeHTML: プレースホルダ・エレメントにHTMLをレンダリングします。

IncludeJavaScript: プレースホルダ・エレメントにJavaScriptをレンダリングします。

ソースURL

sourceurl

ビューのコンテンツを提供するURL。

JavaScript

javascriptcontent

ビュー・タイプがIncludeJavaScriptで、「ソースURL」を指定しない場合は必須です。

ビュー・タイプでIncludeJavaScriptを指定した場合、この属性で指定した内容がスクリプト・タグに組み込まれます。IncludeJavaScriptを指定した場合は、Source URLを指定するか、JavaScript属性でコードを指定する必要があります。

コンテンツ

includecontent

ビュー・タイプがIncludeHTMLで、「ソースURL」を指定しない場合は必須です。ビュー・タイプでIncludeHTMLを指定した場合、この属性で指定した内容がプレースホルダ・エレメント・タグに組み込まれます。IncludeHTMLを指定した場合は、Source URLを指定するか、Content属性でコードを指定する必要があります。

78.2.2 FW_Applicationアセット・タイプ

このアセット・タイプはアプリケーションを登録する際に使用します。アセット・タイプは、AdminSiteで有効になります。WebCenter Sites Adminインタフェースに表示されるFW_Applicationの属性は、次の一覧およびOracle Fusion Middleware WebCenter Sites REST API Beanリファレンスを参照してください。網掛け部分は必須属性であることを示しています。

表78-2 FW_Applicationアセット・タイプの属性

属性: WebCenter Sitesインタフェース

属性: REST API

説明

名前

name

このアプリケーション・アセットの短くてわかりやすい名前。

説明

説明

このアプリケーション・アセットの説明。

ツールチップ

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

このアプリケーションで使用されるビュー・アセットのリスト。

第VI部

Community-Gadgetsアプリケーションの開発

この部の最初の章では、Community-Gadgetsアプリケーションとその開発者の概要について説明します。その後、Community-GadgetsアプリケーションとFacebook、Twitter、Google、Janrainを統合するプロセスについて説明します。さらに、Community-Gadgetsをカスタマイズする方法と、その機能を各種言語に翻訳する方法を説明します。最後に、Community-Gadgets Webサイトのプレゼンスを維持するためのガイドラインとヒントを示します。

この部は、次の章で構成されています。

- 第79章「Oracle WebCenter Sites: Community-Gadgetsについて」

- 第80章「Community-Gadgets: ソーシャル・ネットワーキング・サービスとの統合」

- 第81章「Community-Gadgets: 機能のカスタマイズ」

- 第82章「Community-Gadgets: 機能のローカライズ」

- 第83章「Community-Gadgets: パフォーマンスの監視」

- 第84章「Community-Gadgets: アプリケーションのメンテナンスに関するガイドライン」

- 第85章「Community-Gadgets: Communityのウィジェット・タグの分析」

- 第86章「Community-Gadgets: CommunityウィジェットでのSEOサポートの有効化」

- 第87章「Community-Gadgets: CSSタグのデプロイ」

79 Oracle WebCenter Sites: Community-Gadgetsについて

Oracle WebCenter Sites: Community-Gadgetsは、Webサイト・コンテンツ上の訪問者のコメント、レビューおよび評価を収集するために設計されたソーシャル・コンピューティングWebアプリケーションです。また、Community-Gadgetsでは、管理者やモデレータが必要なトピックに関するサイト訪問者を調査するために使用可能な投票を作成および管理することもできます。

この章には次の項が含まれます。

- 第79.1項「WebCenter Sites: Community-Gadgetsの概要」

- 第79.2項「Community-Gadgetsの管理コンポーネントおよび本番コンポーネント」

- 第79.3項「WebCenter Sites: Community-Gadgetsの技術概要」

- 第79.4項「前提条件」

79.1 WebCenter Sites: Community-Gadgetsの概要

Community-Gadgetsは、一連のJavaEE Webアプリケーションで、Oracle WebCenter Sitesと統合され、ソーシャル・コンピューティング・アプリケーションとして分散環境で機能します。Community-Gadgetsでは、ユーザーに次の2つのWebエクスペリエンス管理(WEM)アプリケーションを提供します。

- Community WEMアプリケーション: 訪問者のコメント、レビュー、評価および投票を収集するためのウィジェットの構成に使用されるCommunityインタフェースを提供します。また、Community WEMアプリケーションは、ユーザー生成コンテンツに対してモデレーションを行うためにも使用されます。

- Gadgets WEMアプリケーション: Gadgets管理者インタフェース(グローバル・カタログ)およびGadgetsユーザー・インタフェースを提供します。どちらのインタフェースが表示されるかは、ユーザーのロールによって異なります。両方のインタフェースが、ガジェットおよびダッシュボードの登録、共有および構成を含むガジェット管理に使用されます。

WEMフレームワークおよびWEMアプリケーションの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』および『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。

79.2 Community-Gadgetsの管理コンポーネントおよび本番コンポーネント

Community-Gadgetsは、管理アプリケーションおよび本番(配信)アプリケーションという2つの部分で構成されます。

注意:

管理用Community-Gadgetsおよび本番用Community-Gadgetsは、別のアプリケーション・サーバー・インスタンス上にデプロイされる必要があります。単一アプリケーション・サーバー上に両方をデプロイすることは、サポートされていません。

- 管理用Community-Gadgetsには次の2つのWebアプリケーションが含まれます。

- Community-Gadgets Webアプリケーション

- Shindig Webアプリケーション

- 本番用Community-Gadgetsには次の3つのWebアプリケーションが含まれます。

- Community-Gadgets Webアプリケーション

- Shindig Webアプリケーション

- CAS Webアプリケーション

管理コミュニティ-ガジェットは、ユーザーが生成したコンテンツ(UGC)の管理、ガジェットの登録および同様の機能に使用されます。セキュリティ上の理由から、通常、それには内部からのみアクセスできます。訪問者は、本番コミュニティ-ガジェットに、Webページにデプロイされているウィジェットおよびガジェット・ダッシュボードを使用してアクセスします。訪問者の認証はVisitors CASを介して管理されます。

管理用および本番用のCommunity-Gadgetsは両方とも、ガジェットをレンダリングするためにShindig OpenSocialコンテナを使用します。本番用Community-Gadgetsには、外部からアクセスできる必要があります。Shindig Webアプリケーションの詳細は、次のURLを参照してください。

http://shindig.apache.org/

79.3 WebCenter Sites: Community-Gadgetsの技術概要

コメント、レビュー、投票などのCommunity-Gadgets機能は、ウィジェットと呼ばれる別のモジュールとして開発されています。各ウィジェットは、ブラウザでウィジェットをレンダリングする、JavaScriptコード・スニペットを使用して、Webサイト上にデプロイできます。ブラウザでウィジェットをデプロイする機能により、デプロイメントを簡単かつプラットフォームに依存しないで行うことができます。ウィジェット・デプロイメント手法により、大規模なメンテナンスとアップグレードも促進されます。

Community-Gadgetsウィジェットは大半のサーバー側のバックエンド・テクノロジと互換性があるため、開発者が理解しておく必要のある重要なデプロイメント上の前提条件はありません。Community-GadgetsはWebCenter Sitesのアドオンであるため、WebCenter Sitesとは個別にデプロイできます。

JavaScriptを使用することにより、開発者は、使用しやすく機能が豊富なウィジェット・インタフェースを作成できます。開発者は、ユーザー・アクションに敏感で、Webページ全体を再ロードする必要のない動的画面を構築できます。ウィジェットがWebページにデプロイされるとすぐに、データ・リポジトリからのコメント、レビュー、特定の投票情報のリストなどの動的コンテンツのレンダリングおよびロードが開始されます。ウィジェットのデータは、AJAXと同様のリモート・スクリプティング・テクノロジによって、JavaScriptを使用してロードされます。また、このテクノロジにより、元のWebサイト・ドメイン以外のドメイン上にあるCommunity-Gadgets Webアプリケーションのデプロイメントも促進されます。図79-1は、デプロイメント後のWebサイト環境を示しています。

図79-1 Community-Gadgets機能のデプロイ後のクライアントWebサイト環境

Community-Gadgetsウィジェットの基になるCommunity-Gadgetsオブジェクト・データ・モデルに習熟するためには、第81.1項「Community-Gadgetsのデータ・モデルの概要」を参照してください。

79.4 前提条件

開発者は、Community-Gadgets Webアプリケーションのインストール方法を理解し、CommunityインタフェースおよびGadgetsインタフェースを認識している必要があります。このガイドを効率的に使用するには、開発者は次の使用経験が必要です。

- WEMフレームワーク、REST APIおよびWEM Adminインタフェース

- Oracle WebCenter Sitesアセット・モデルおよびOracle WebCenter Sites: Satellite Serverキャッシュ用

- Webシングル・サインオンに使用されるCentral Authentication Service (CAS)

- Oracle WebLogic Server、WebSphere Application ServerまたはTomcatアプリケーション・サーバー上のWebアプリケーションのデプロイメント

80 Community-Gadgets: ソーシャル・ネットワーキング・サービスとの統合

Community-Gadgetsウィジェットは、Webサイト上でFacebook、TwitterおよびJanrainの認証APIを活用するように設計されています。Community-Gadgetsウィジェットを使用すると、Webサイト(またはブログ)の訪問者が既存のソーシャル・ネットワーキング・プロファイルを使用して、会社のコンテンツにフィードバックを提供したり、ソーシャル・ネットワーキング・プロファイル上の同一コンテンツを共有したりできます。この章では、Community-Gadgets WebアプリケーションとFacebook、Twitter、Google、Janrain、Oracle Mobile and Social Access Service (OMSAS)との統合方法について説明します。

この章には次の項が含まれます。

- 第80.1項「認証プラグインについて」

- 第80.2項「Facebookとの統合」

- 第80.3項「Twitterとの統合」

- 第80.4項「Googleとの統合」

- 第80.5項「Janrainとの統合」

- 第80.6項「Oracle Internet Access Serviceとの統合」

- 第80.7項「WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化」

80.1 認証プラグインについて

開発者は、次の方法でサード・パーティ認証プロバイダを活用できます。

- Facebook、TwitterおよびGoogleの組込みサポートを使用します。これらは、Community-Gadgets Webアプリケーションですぐに利用できます。

- 認証ハブのJanrainを使用します。これにより、オンライン上で利用可能な一般的なプロバイダのほとんどにアクセスできます。Janrainは、Facebook、Twitter、Googleなどの多数のオンライン認証プロバイダとの統合サービスを提供するSaaSソリューションです。サポートされるサービスが増えるほど、サイト訪問者は、ログインに使用可能なこれらのサービスのいずれかのアイデンティティを持つ機会が多くなります。

- 認証ハブのOracle Mobile and Social Access Service (OMSAS)を使用します。これにより、オンライン上で利用可能な一般的なプロバイダにアクセスできます。OMSASは、Facebook、Twitter、Googleなどの多数のオンライン認証プロバイダとの統合サービスを提供するソリューションです。

注意:

Community-Gadgetsは、OMSASからのソーシャル機能のみを使用します。モバイル機能は使用しません。

80.2 Facebookとの統合

Webサイト上で、訪問者のFacebookアイデンティティは、各ログイン試行時にCommunity-Gadgets WebアプリケーションとFacebook間で確立される、信頼できるブリッジを介して認証されます。このブリッジを有効にするには、まず、Community-Gadgets本番サイトURLを使用して、Facebookアプリケーションを作成する必要があります。次に、Community-Gadgets Webアプリケーションの本番システム上のアプリケーション・サーバーでFacebook認証プロパティを構成します。この項では、次の操作方法について説明します。

- 第80.2.1項「Community-Gadgets用のFacebookアプリケーションの作成」

- 第80.2.2項「Community-Gadgets WebアプリケーションでのFacebookアプリケーション認証設定の構成」

80.2.1 Community-Gadgets用のFacebookアプリケーションの作成

注意:

この項に示す手順と画面は、アプリケーション作成時のFacebookインタフェースに一致しない場合があります。新しいフィールドが表示され、支援が必要な場合は、製品サポートにお問合せください。

Community-Gadgets用のFacebookアプリケーションを作成するには:

1. Facebookにログインし、「Apps」ページにアクセスします。https://developers.facebook.com/apps

2. ページの右上角にある「Create New App」をクリックし、「New App」ダイアログ・ボックスを表示します。

3. 「App Display Name」フィールドに、Community-Gadgets Webアプリケーションの名前を入力します。

4. 「I agree to the Facebook Platform Policies」チェック・ボックスを選択し、「Continue」をクリックします。

図80-1 新しいアプリ: Facebook

5. 「Security Check Required」ページの「Text in the box」フィールドに、表示されているCAPTCHA文字を入力します。次に「Submit」をクリックします。

6. 「Basic」の下の「App ID」と「App Secret」パラメータの値をコピーします(図80-2)。これらの値は、アプリケーション・サーバーでFacebook認証プロパティを構成する際に必要となります。

図80-2 アプリケーションIDとアプリケーション・シークレット

7. 「Select how your app integrates with Facebook」の下にある、「Website」の横のグレーのテキストをクリックして、「Site URL」入力フィールドを表示します(図80-3を参照)。

図80-3 アプリケーションとFacebookの統合方法の選択

8. 「Site URL」フィールドに、Community-Gadgets Webアプリケーションの本番アドレスを入力し、「Save Changes」をクリックします。

80.2.2 Community-Gadgets WebアプリケーションでのFacebookアプリケーション認証設定の構成

Community-Gadgetsアプリケーション・サーバーでFacebookアプリケーション認証プロパティを構成するには:

1. 本番システムのアプリケーション・サーバー・ホームで、standalone_nodeフォルダに移動します。デフォルトの管理システムおよび本番システムの場所は、次のとおりです。

<cg_install_dir>/deploy/management/management_node1
<cg_install_dir>/deploy/production/production_node1

2. setup_auth.propertiesファイルを開き、「Facebook Application Settings」セクションまで下にスクロールします。

3. widgets.external_auth.facebook.attrs.client_idおよびwidgets.external_auth.facebook.attrs.client_secret構成プロパティに、Facebookアプリケーションの作成時にコピーしたアプリケーションIDとアプリケーション・シークレット値を入力します。
「Facebook Application Settings」セクションは、次のように表示されます。

## Facebook Application Settings
#######################################
#
# Facebook application id
#
widgets.external_auth.facebook.attrs.client_id=1111111111111111111
#
# Facebook application secret
#
widgets.external_auth.facebook.attrs.client_secret=571bf600e8d23

4. 構成ファイルを保存したら、アプリケーション・サーバーを再起動します。

5. 一般管理者として管理側でCommunityインタフェースまたはGadgetsインタフェースを開きます。http://host:port/cs/login

6. 必要なサイトを選択します。

7. 「ログイン・バー」メニューで、「構成」を選択します。

8. 「ソーシャル・ログインと共有の設定」ページの「ソーシャル・ログイン」セクションで、「有効なネイティブ・ソーシャル統合」の下にある「Facebookログインの有効化」チェック・ボックス(図80-4)を選択して、「保存」をクリックします。

図80-4 Facebookログインの有効化

9. 管理環境と本番環境を再起動します。

10. ウィジェットがデプロイされるWebサイトにアクセスします。
Community-Gadgetsウィジェットのログイン画面にFacebookのログイン・ボタンが表示されます(図80-5)。

図80-5 Facebookのログイン・ボタン

注意:

Community-Gadgets WebアプリケーションがOracle WebLogic ServerまたはTomcatアプリケーション・サーバー上で実行されている場合、第80.2.1項「Community-Gadgets用のFacebookアプリケーションの作成」および第80.2.2項「Community-Gadgets WebアプリケーションでのFacebookアプリケーション認証設定の構成」で説明される手順のみが、Community-GadgetsをFacebookと統合するために必要です。ただし、WebSphere Application Serverインスタンスでは、第80.7項「WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化」で説明されるエクスポート/インポート手順を実行して、Community-Gadgetsとこのソーシャル・ネットワーキング・サービス間の通信を有効にする必要があります。

80.3 Twitterとの統合

Community-Gadgets Webアプリケーションは、Facebookと統合したように、Twitterとも統合できます。まず、本番サイトURLを使用してTwitterアプリケーションを作成し、次に、Twitterアプリケーションの必須情報を含めるように、アプリケーション・サーバー上の認証プロパティを更新します。

この項では、次の操作方法について説明します。

- 第80.3.1項「Community-Gadgets用のTwitterアプリケーションの作成」

- 第80.3.2項「Community-GadgetsでのTwitterアプリケーション認証設定の構成」

80.3.1 Community-Gadgets用のTwitterアプリケーションの作成

Twitterアプリケーションを作成するには:

1. https://dev.twitter.com/にあるTwitterの開発者サイトにログインします。

2. 「Create applications that integrate Twitter」の下にある「Create an app」をクリックします。

3. 「Application Details」の下で、次のように必須情報を入力します。

1. 「Name」および「Description」フィールドに、Community-Gadgets Webアプリケーションの名前と説明を入力します。

2. 「WebSite」フィールドに、Community-Gadgets本番サーバーURLを入力します。例: http://production.example.com

3. 「Callback URL」フィールドに、Community-Gadgets Webアプリケーションの本番ホストの場所を入力します。これは、手順bのURLと同じです。

4. 「Yes, I agree」チェック・ボックスを選択します。

5. 「CAPTCHA」の下に、画面に表示される単語を入力します。

6. 「Create your Twitter application」をクリックします。

4. 「Details」ページの「OAuth settings」セクションに表示される「Consumer key」と「Consumer secret」プロパティの値をコピーします(図80-6)。これらの値は、アプリケーション・サーバーで認証プロパティを構成する際に必要となります。

図80-6 OAuth設定

80.3.2 Community-GadgetsでのTwitterアプリケーション認証設定の構成

Community-Gadgetsで認証プロパティを構成するには:

1. 本番システムのアプリケーション・サーバー・ホームで、standalone_nodeフォルダに移動します。デフォルトの管理システムおよび本番システムの場所は、次のとおりです。

<cg_install_dir>/deploy/management/management_node1
<cg_install_dir>/deploy/production/production_node1

2. setup_auth.propertiesファイルを開き、「Twitter Application Settings」セクションまで下にスクロールします。

3. widgets.external_auth.twitter.attrs.consumer_keyおよびwidgets.external_auth.twitter.attrs.consumer_secret構成プロパティに、前にコピーしたコンシューマ・キーとコンシューマ・シークレットの値を入力します。
「Twitter Application Settings」セクションは、次のように表示されます。

## Twitter Application Settings
# Twitter consumer key
#
widgets.external_auth.twitter.attrs.consumer_key=uh5nvtwCg5WjBD9UHM29eQ
#
# Twitter consumer secret
#
widgets.external_auth.twitter.attrs.consumer_secret=CaYaLDk9IZBConpQVkxk

4. 構成ファイルを保存したら、アプリケーション・サーバーを再起動します。

5. 一般管理者として管理側でCommunityインタフェースまたはGadgetsインタフェースを開きます。http://host:port/cs/login

6. 必要なサイトを選択します。

7. 「ログイン・バー」メニューで、「構成」を選択します。

8. 「ソーシャル・ログインと共有の設定」ページの「ソーシャル・ログイン」セクションで、「有効なネイティブ・ソーシャル統合」の下にある「Twitterログインの有効化」チェック・ボックスを選択して、「保存」をクリックします。

9. 管理環境と本番環境を再起動します。

10. ウィジェットがデプロイされるWebサイトにアクセスします。
ウィジェットがデプロイされるWebサイト上のCommunity-Gadgetsウィジェットのログイン画面に、Twitterのログイン・ボタンが表示されます(図80-7)。

図80-7 Twitterのログイン・ボタン

注意:

Community-Gadgets WebアプリケーションがOracle WebLogic ServerまたはTomcatアプリケーション・サーバー上で実行されている場合、第80.3.1項「Community-Gadgets用のTwitterアプリケーションの作成」および第80.3.2項「Community-GadgetsでのTwitterアプリケーション認証設定の構成」で説明される手順のみが、Community-GadgetsをTwitterと統合するために必要です。ただし、WebSphere Application Serverインスタンスでは、第80.7項「WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化」で説明されるエクスポート/インポート手順を実行して、Community-Gadgetsとこのソーシャル・ネットワーキング・サービス間の通信を有効にする必要があります。

80.4 Googleとの統合

Webサイト上で、訪問者のGoogleアイデンティティは、各ログイン試行時にCommunity-Gadgets WebアプリケーションとGoogle間で確立される、信頼できるブリッジを介して認証されます。このブリッジを有効にするには、まず、Community-Gadgets本番サイトURLを使用して、Googleアプリケーションを作成する必要があります。次に、Community-Gadgets Webアプリケーションの本番システム上のアプリケーション・サーバーでGoogle認証プロパティを構成します。

この項では、次の操作方法について説明します。

- 第80.4.1項「Community-Gadgets用のGoogleアプリケーションの作成」

- 第80.4.2項「Community-GadgetsでのGoogleアプリケーション認証設定の構成」

80.4.1 Community-Gadgets用のGoogleアプリケーションの作成

Googleアプリケーションを作成するには:

1. 次のURLにサインインして、Google APIコンソールを開きます。

https://code.google.com/apis/console

2. 図80-8に示すように、「Create project...」をクリックします。

図80-8 プロジェクトの作成

3. 「All Services」ページの左ペインで、「API Access」をクリックします(図80-9を参照)。

図80-9 APIアクセス

4. アプリケーションを作成するには、「API Access」ページで、「Create an OAuth 2.0 client ID」(図80-9)をクリックして、次の手順を実行します。

1. 「Create Client ID」ダイアログ・ボックスの「Product name」フィールドに、アプリケーションのわかりやすい名前を入力します。例: Community-Gadgets (図80-10を参照)。

図80-10 クライアントIDの作成

2. 「Next」をクリックします。

3. 「Client ID Settings」画面の「Application type」に、「Web application」(図80-11)を選択します(デフォルトで選択されていない場合)。

4. 「Your site or hostname」の下に、Community-Gadgets本番サーバーのURLを入力します。例: example.yoursite.com:8280 (図80-11を参照)。

図80-11 クライアントID設定

5. 「Create client ID」をクリックします。

5. アプリケーションのクライアントIDとクライアント・シークレットを生成するには、「Client ID for web applications」セクションで、「Edit settings」(図80-12)をクリックして、次の操作を実行します。

図80-12 設定の編集

1. 「Edit client settings」ダイアログ・ボックスの「Authorized JavaScript Origins」フィールドに、http://<cg_production_hostname>:<cg_production_port>/<context-root>/external-auth/google/を入力します。例: http://example.yoursite.com:8280/community-gadgets/external-auth/google/ (図80-13を参照)。

図80-13 クライアントID設定

2. 「Update」をクリックします。
電子メールで図80-14に示すようなClient IDおよびClient secretを受け取ります。

図80-14 WebアプリケーションのクライアントID

第80.4.2項「Community-GadgetsでのGoogleアプリケーション認証設定の構成」で説明するように、これらのパラメータはsetup_auth.propertiesに追加されます。

80.4.2 Community-GadgetsでのGoogleアプリケーション認証設定の構成

Community-Gadgetsアプリケーション・サーバーでGoogleアプリケーション認証プロパティを構成するには:

1. 本番システムのアプリケーション・サーバー・ホームで、standalone_nodeフォルダに移動します。デフォルトの場所は次のとおりです。<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1

2. setup_auth.propertiesファイルを開き、「Google Application Settings」セクションまで下にスクロールします。

3. widgets.external_auth.google.attrs.client_idおよびwidgets.external_auth.google.attrs.client_secret構成プロパティに、Googleアプリケーションの作成時にコピーしたクライアントIDとクライアント・シークレットの値を入力します。
「Google Application Settings」セクションは、次のように表示されます。

## Google+ Application Settings
#######################################
#
# Google+ application id
#
widgets.external_auth.google.attrs.client_id= 757212173966.apps.googleusercontent.com
#
# Google+ application secret
#
widgets.external_auth.google.attrs.client_secret= pNu1ZTdsd8QYJ3B6BXXLiwkH

4. 構成ファイルを保存したら、アプリケーション・サーバーを再起動します。

5. 一般管理者として管理側でCommunityインタフェースまたはGadgetsインタフェースを開きます。http://host:port/cs/login

6. 必要なサイトを選択します。

7. 「ログイン・バー」メニューで、「構成」を選択します。

8. 「ソーシャル・ログインと共有の設定」ページの「ソーシャル・ログイン」セクションで、「有効なネイティブ・ソーシャル統合」の下にある「Googleログインの有効化」チェック・ボックス(図80-15)を選択して、「保存」をクリックします。

図80-15 Googleログインの有効化

9. 管理環境と本番環境を再起動します。

10. ウィジェットがデプロイされるWebサイトにアクセスします。
ウィジェットがデプロイされるWebサイト上のCommunity-Gadgetsウィジェットのログイン画面に、Googleログイン・ボタンが表示されます。

注意:

Community-Gadgets WebアプリケーションがOracle WebLogic ServerまたはTomcatアプリケーション・サーバー上で実行されている場合、第80.4.1項「Community-Gadgets用のGoogleアプリケーションの作成」および第80.4.2項「Community-GadgetsでのGoogleアプリケーション認証設定の構成」で説明される手順のみが、Community-GadgetsをGoogleと統合するために必要です。ただし、WebSphere Application Serverインスタンスでは、第80.7項「WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化」で説明されるエクスポート/インポート手順を実行して、Community-Gadgetsとこのソーシャル・ネットワーキング・サービス間の通信を有効にする必要があります。

80.5 Janrainとの統合

Community-Gadgets Webアプリケーションは、Janrainと統合され、Janrainは多数のサード・パーティ・サービスと統合されます。このサービスのリストから、訪問者はサイトにログインするために使用するサービスを選択できます。

Janrainサポートを構成するには:

1. JanrainのWebサイト上でアカウントを作成します。

2. Community-Gadgets用のJanrainアプリケーションを作成します。

3. Community-GadgetsでのJanrainアプリケーション認証設定を構成します。

80.5.1 Community-Gadgets用のJanrainアプリケーションの作成

この項で説明される手順を実行するには、Janrainアカウントが必要です。「Enterprise subscription plan」を選択して、Janrain Webサイトに自分の会社を登録します。

Janrainアプリケーションを作成するには:

1. 図80-16に示すように、ツールバーのドロップダウン・リストからrpxnow.comに移動し、「Create Application」を選択します。

図80-16 Janrainアプリケーションの作成

2. 必須フィールドに入力し、「Create Application」をクリックします。

図80-17 Plusアプリケーションの購入

3. 「Deployment」メニューから「Application Settings」を選択します。

図80-18 アプリケーション設定

4. 「Application Info」セクションで、新たに作成されたアプリケーションの一意の値が「Application Domain」、「App ID」および「API Key (Secret)」の下に表示されます。Community-Gadgets本番サーバーでJanrainサポートを構成する場合は、必要に応じてこれらの値をコピーします。

図80-19 必要なアプリケーション・パラメータ

5. 「Domain Whitelist」ボックスに、Community-GadgetsウィジェットをデプロイするWebサイト・ドメインを指定します(図80-20)。

図80-20 ドメイン・ホワイトリスト

6. この手順では、Community-GadgetsウィジェットをデプロイするWebサイト上にリストされるアイデンティティ・プロバイダが有効になります。したがって、訪問者は既存のオンライン・アイデンティティのいずれかを使用し、Webサイト・コンテンツにコメントや評価を追加できます。

1. 「Deployment」メニューから「Sign-in for Web」を選択します。

図80-21 Webへのサインイン

2. 「Choose Providers」リンクをクリックして、各プロバイダをウィジェットにドラッグします。

図80-22 アイデンティティ・プロバイダの構成

7. アイデンティティ・プロバイダにより、サイト訪問者はすでにログイン資格証明を持つプロバイダを選択できるようになります。アイデンティティ・プロバイダが有効になると、その構成ウィザードが表示されます。たとえば、図80-23に、Google用の構成ウィザードが表示されます。有効化されたプロバイダごとに、構成手順を実行します。

図80-23 Janrainを介したGoogleの構成

8. Janrainを使用したソーシャル共有を構成します。この手順では、Webサイト訪問者がソーシャル・ネットワーキング・サイト上のプロファイルを介して選択したコンテンツを共有できます。「Deployment」メニューから「Social Sharing for Web」を選択します。

図80-24 ソーシャル・ネットワーキング・サービス・プロバイダの構成

80.5.2 Community-GadgetsでのJanrainアプリケーション認証設定の構成

Janrainアプリケーションを構成した後で、本番Community-Gadgets WebアプリケーションでJanrain認証設定を構成します。

1. 本番システムのアプリケーション・サーバーで、standalone_nodeフォルダに移動します。デフォルトの管理システムおよび本番システムの場所は、次のとおりです。

<cg_install_dir>/deploy/management/management_node1
<cg_install_dir>/deploy/production/production_node1

2. setup_auth.propertiesファイルを開き、「Janrain Application Settings」セクションまで下にスクロールします。

3. widgets.external_auth.janrain.attrs.enabledプロパティをtrueに設定して、Janrainサポートを有効にします。

4. widgets.external_auth.janrain.attrs.app_name、widgets.external_auth.janrain.attrs.app_idおよびwidgets.external_auth.janrain.attrs.app_secret構成プロパティに、前にコピーしたアプリケーション名、アプリケーション・ドメイン、アプリケーションIDおよびAPIキーを入力します。
「Janrain Application Settings」セクションは、次のように表示されます。

## Janrain Application Settings
#######################################
#
# Enabling Janrain support
# Default is "false"
#
widgets.external_auth.janrain.attrs.enabled=true

#
# Jainrain application name
#
widgets.external_auth.janrain.attrs.app_name=fw

## Janrain application domain
# widgets.external_auth.janrain.attrs.app_domain=https://fw.rpxnow.com/

#
# Jainrain application id
#
widgets.external_auth.janrain.attrs.app_id=gajo1d134dfk3tgcoien

#
# Jainrain application secret
#
widgets.external_auth.janrain.attrs.app_secret=5asdf234jasdfk531

5. 構成ファイルを保存したら、アプリケーション・サーバーを再起動します。

6. CommunityインタフェースまたはGadgetsインタフェースを開いて、「ログイン・バー」→「構成」に移動します。

7. 「ソーシャル・ログインと共有の設定」ページの「ソーシャル共有」セクションで、Janrainサイトに共有オプションを構成している場合は「専用Janrainウィジェットを経由したコメントおよびレビューのソーシャル共有」オプション(図80-25)を選択し、「保存」をクリックします。

図80-25 Janrainサポートの有効化

8. 管理環境と本番環境を再起動します。

9. Community-GadgetsウィジェットがデプロイされるWebサイト上で、構成されたアイデンティティ・プロバイダがCommunity-Gadgetsウィジェットのログイン画面に表示されます(図80-26を参照)。

図80-26 アイデンティティ・プロバイダ・リンクを含むログイン画面

注意:

Community-Gadgets WebアプリケーションがOracle WebLogic ServerまたはTomcatアプリケーション・サーバー上で実行されている場合、第80.5.1項「Community-Gadgets用のJanrainアプリケーションの作成」および第80.5.2項「Community-GadgetsでのJanrainアプリケーション認証設定の構成」で説明される手順のみが、Community-GadgetsをJanrainと統合するために必要です。ただし、WebSphere Application Serverインスタンスでは、第80.7項「WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化」で説明されるエクスポート/インポート手順を実行して、Community-Gadgetsとこのソーシャル・ネットワーキング・サービス間の通信を有効にする必要があります。

80.6 Oracle Internet Access Serviceとの統合

この項では、まず、インターネット・アイデンティティ・プロバイダをサポートするようにWebLogic Serverを構成する方法、次に、Mobile and Socialサービスを有効化して、インターネット・アイデンティティ・プロバイダを定義し、それらのプロバイダに対して新しいMobile and Socialアプリケーション・プロファイルを作成する方法、そして最後に、構成済アイデンティティ・プロバイダを介したセキュアなトランザクションのためにCommunity-GadgetsとOMSASの統合を有効化する方法について説明します。

この項は、次のトピックで構成されています。

- 第80.6.1項「Mobile and Socialアイデンティティ・プロバイダをサポートするためのWebLogic Serverの構成」

- 第80.6.2項「OAM上のMobile and Socialサービスの有効化」

- 第80.6.3項「OMSASに対するインターネット・アイデンティティ・プロバイダの定義」

- 第80.6.4項「新しいMobile and Socialアプリケーション・プロファイルの作成」

- 第80.6.5項「Community-GadgetsとOMSASの統合の有効化」

80.6.1 Mobile and Socialアイデンティティ・プロバイダをサポートするためのWebLogic Serverの構成

Mobile and Socialサービスを有効化し、OAM上でアイデンティティ・プロバイダを構成する前に、必要なアイデンティティ・プロバイダに対する、OAMのWebLogic管理対象サーバー・インスタンスを構成する必要があります。

Facebookと互換性を持つためのWebLogic Serverの構成の詳細は、http://docs.oracle.com/cd/E27559_01/admin.1112/e27239/oicconfiginetidentitysrvcs.htm#AIAAG8292にあるインターネット・アイデンティティ・プロバイダのトラブルシューティングを参照してください。

80.6.2 OAM上のMobile and Socialサービスの有効化

この項では、OAM上でMobile and Socialサービスを有効化する手順を説明します。これを有効化することによって、以降の手順で、必要なアイデンティティ・プロバイダ(Facebook、Twitterなど)をこのサービスを使用して構成し、Community-Gadgetsおよびアイデンティティ・プロバイダをアプリケーション・プロファイルを介してOAMを使用して構成できるようになります。

OAM上でMobile and Socialサービスを有効化するには:

1. 次のように、OAMコンソール・アプリケーションにログインします。

http://<weblogic_host>:<weblogic_admin_port>/oamconsole

2. 「システム構成」タブで、「使用可能なサービス」ノードを開きます。

3. 「使用可能なサービス」タブで、「Mobile And Social」サービスの「有効化」をクリックします。
図80-27では、Mobile and Socialサービスがすでに有効化されているため、「無効化」オプションが表示されています。

図80-27 Mobile and Socialサービスの有効化

80.6.3 OMSASに対するインターネット・アイデンティティ・プロバイダの定義

OAM上でMobile and Socialサービスを有効化したら、このサービスを介してサポートできるようにアイデンティティ・プロバイダ(Facebook、Twitter、LinkedInなど)を定義します。詳細は、http://docs.oracle.com/cd/E27559_01/admin.1112/e27239/oicconfiginetidentitysrvcs.htm#autoId5にあるインターネット・アイデンティティ・プロバイダの定義を参照してください。

80.6.4 新しいMobile and Socialアプリケーション・プロファイルの作成

インターネット・アイデンティティ・プロバイダを定義した後の次の手順は、Community-Gadgetsの本番インスタンス用の新しいMobile and Socialアプリケーション・プロファイルを作成することです。このアプリケーション・プロファイルの作成時に、このプロファイルによってサポートされるように必要なアイデンティティ・プロバイダも有効化します。

新しいMobile and Socialアプリケーション・プロファイルは次の方法で作成できます。

- 第80.6.4.1項「OAMコンソール・アプリケーションを使用したMobile and Socialアプリケーション・プロファイルの作成」

- 第80.6.4.2項「WebLogicスクリプティング・ツール(WLST)スクリプトを使用したアプリケーション・プロファイルの作成」

80.6.4.1 OAMコンソール・アプリケーションを使用したMobile and Socialアプリケーション・プロファイルの作成

OAMコンソールを使用して新しいアプリケーション・プロファイルを作成するには:

1. OAMコンソール・アプリケーションにログインし、「システム構成」タブ(図80-28)をクリックします。

2. 左側のペインで、「Mobile And Social」をクリックします(図80-28)。

3. 左側のペインで、「インターネット・アイデンティティ・サービス」を開き、「アプリケーション・プロファイル」(図80-28)をクリックします。

4. 「Mobile and Socialホーム」タブの「アプリケーション・プロファイル」セクションで、「作成」(図80-28)をクリックします。

図80-28 OAM - システム構成 - Mobile and Social

5. 「アプリケーション・プロファイルの作成」フォームの「アプリケーション・プロファイル」ページで、図80-29および表80-1に示すように、必須情報を指定し、「次」をクリックします。

図80-29 「アプリケーション・プロファイルの作成」フォーム

表80-1 「アプリケーション・プロファイルの作成」フォームのフィールド

フィールド名

説明

名前

新しいアプリケーション・プロファイルの名前。

説明

新しいアプリケーション・プロファイルの説明。

共有シークレット

アプリケーション・プロファイルのパスワード。

戻りURL

Mobile and SocialがWebアプリケーションに認証レスポンスを返すために使用するURL。

URL形式: <production_cg_protocol>://<production_cg_host>:<production_cg_port>/<production_cg_context>/external-auth/oam

ここで:

- <production_cg_protocol>: Community-Gadgets本番システムに使用されるプロトコル。httpまたはhttpsが可能

- <production_cg_host>: 本番システムのホスト・サーバー

- <production_cg_port>: 本番システムのポート

- <production_cg_context>: アプリケーションをデプロイするコンテキスト・ルート

例: http://prodcg.example.com:8080/cg/external-auth/oam

モバイル・アプリケーション戻りURL

Mobile and Socialがモバイル・アプリケーションに認証レスポンスを返すために使用するURL。

アプリケーション・プロファイル・プロパティ

ログイン・タイプ

ローカル認証はサポートされていません。したがって、「インターネット・アイデンティティ・プロバイダ認証のみ」オプションを選択します。

ブラウザ・ポップアップの有効化

ログイン・ダイアログ・ボックスを新しいウィンドウでポップアップ表示するには、「はい」を選択します。

ユーザー登録

Community-Gadgetsで適切なユーザー・アカウントを作成するには、「有効」を選択する必要があります。

登録URL

Mobile and Socialがアイデンティティ・プロバイダからの認証(たとえば、avatar、ユーザー名など)を使用してWebアプリケーションに認証レスポンスを返すために使用するURL。

URL形式: <production_cg_protocol>://<production_cg_host>:<production_cg_port>/<production_cg_context>/external-auth/oam

トークンの説明は、前のエントリで述べられています。

UserID属性

一意のユーザー属性: uid。

ユーザー・プロファイル・サービス・エンドポイント

/userprofileである必要があります。

認証サービス・エンドポイント

/internetidentityauthenticationである必要があります。

アプリケーション・プロファイル・プロパティ

必要ありません

アプリケーション・ユーザー属性

mail、firstname、lastname、username、image、user_id、displaynameなどのユーザー属性を追加します。

登録サービス詳細とアプリケーション・ユーザー属性のマッピング

登録サービス詳細とユーザー属性表示名のマッピング。

例:

uid

ログインID

mail

電子メールID

firstname

名

lastname

姓

displayname

表示名

name

共通名

jpegphoto

ユーザー・イメージ

6. 「サービス・プロバイダ・インタフェース」ページは、指定されたアプリケーション・プロファイルの認証フローを統括するルール・セットを参照します。Mobile and Socialでは、次のサービス・プロバイダ・インタフェースを用意しています(図80-30)。

- DefaultServiceProviderInterface: Java互換のアプリケーション・サーバー上で実行されるWebアプリケーションをサポートします。

- OAMServiceProviderInterface: Access Managerサービス上で実行されるWebアプリケーションをサポートします。

適切なオプションを選択します。

図80-30 サービス・プロバイダ・インタフェースの選択

7. 次のように、このアプリケーション・プロファイルでサポートされているアイデンティティ・プロバイダを構成し、「次」をクリックします。

- Facebookアイデンティティ・プロバイダを構成するには、図80-31に示すように、「属性マッピング」セクションの「Facebook」チェック・ボックスを選択して、アプリケーション・ユーザーとインターネット・アイデンティティ・プロバイダ・ユーザーの属性を指定します。

図80-31 Facebookアイデンティティ・プロバイダの構成

- Twitterアイデンティティ・プロバイダを構成するには、図80-32に示すように、「属性マッピング」セクションの「Twitter」チェック・ボックスを選択して、アプリケーション・ユーザーとインターネット・アイデンティティ・プロバイダ・ユーザーの属性を指定します。

図80-32 Twitterアイデンティティ・プロバイダの構成

- LinkedInアイデンティティ・プロバイダを構成するには、図80-33に示すように、「属性マッピング」セクションの「LinkedIn」チェック・ボックスを選択して、アプリケーション・ユーザーとインターネット・アイデンティティ・プロバイダ・ユーザーの属性を指定します。

図80-33 LinkedInアイデンティティ・プロバイダの構成

- Googleアイデンティティ・プロバイダを構成するには、図80-34に示すように、「属性マッピング」セクションの「Google」チェック・ボックスを選択して、アプリケーション・ユーザーとインターネット・アイデンティティ・プロバイダ・ユーザーの属性を指定します。

図80-34 Googleアイデンティティ・プロバイダの構成

- Yahooアイデンティティ・プロバイダを構成するには、図80-35に示すように、「属性マッピング」セクションの「Yahoo」チェック・ボックスを選択して、アプリケーション・ユーザーとインターネット・アイデンティティ・プロバイダ・ユーザーの属性を指定します。

図80-35 Yahooアイデンティティ・プロバイダの構成

8. すべての定義済の値が表示される「サマリー」ページ(図80-36)で、「終了」をクリックして、作成プロセスを完了します。

図80-36 「サマリー」画面

80.6.4.2 WebLogicスクリプティング・ツール(WLST)スクリプトを使用したアプリケーション・プロファイルの作成

WLSTを使用して新しいアプリケーション・プロファイルを作成するには:

1. WLSTを起動します。詳細は、Oracle Fusion Middleware Oracle WebLogicスクリプティング・ツールを参照してください。

2. OAMが実行されているWebLogic Server管理対象サーバーに接続するには、connect();コマンドを実行します。

3. ドメイン全体のランタイム管理オブジェクトのルートに接続するには、domainRuntime()コマンドを実行します。

4. 次のスクリプトのトークンを置き換えて、それを起動します。表80-2は、これらのトークンについて説明し、例80-1は、サンプル・スクリプトを示しています。

createRPApplication('Facebook,Twitter,Linkedin,Google,Yahoo',
'<application_profile_shared_secret>',
'<production_cg_protocol>://<production_cg_host>:<production_cg_
port>/<production_cg_context>/external-auth/oam/',
'DefaultServiceProviderInterface',
'[{app.logintype:idp},
{app.login.popup:true},
{app.user.registration.enabled:true},
{app.registration.url: "<production_cg_protocol>://<production_cg_
host>:<production_cg_port>/<production_cg_context>/external-auth/oam/"},
{app.userid.attribute.name:uid},
{idaas.rest.crudservice:"/userprofile"},
{idaas.rest.tokenservice:"/internetidentityauthentication"},
{app.user.provisioning.mapping:"uid:Login ID:user_id:true:true;mail:Email
ID:mail:true:false;firstname:First Name:firstname:true:false;lastname:Last
Name:lastname:true:false;displayname:Display
Name:displayname:true:false;name:Common
Name:username:true:false;jpegphoto:User Image:image:true:false;"}]',
'[{Facebook:[{user_id:id},{mail:email},{displayname:name}]},
{Twitter:[{user_id:id_str},{displayname:name},{image:profile_image_url}]},
{Linkedin:[{user_
id:id},{image:picture-url},{firstname:first-name},{lastname:last-name}]},
{Google:[{user_
id:email},{mail:email},{firstname:firstname},{lastname:lastname}]},
{Yahoo:[{user_
id:email},{mail:email},{firstname:firstname},{lastname:lastname},
{displayname:fullname}]}]',
'[{user_id:uid},{mail:mail},{firstname:firstname},{lastname:lastname},
{displayname:displayname},
{username:name},{image:jpegphoto}]', '',
'<mobile_and_social_application_profile_name>',
'<mobile_and_social_application_profile_description>');

表80-2 トークンの説明と例

トークン

説明

例

<application_profile_shared_secret>

OAMアプリケーション・プロファイル共有シークレット

パスワード

<production_cg_host>

Community-Gadgetsアプリケーション・サーバーのホスト

prodcg.example.com

<production_cg_port>

Community-Gadgetsアプリケーション・サーバーのポート

8080

<production_cg_context>

Community-Gadgetsアプリケーション・サーバーのコンテキスト・ルート

cg

<mobile_and_social_application_profile_name>

OAMアプリケーション・プロファイルの名前

Community-Gadgetsプロファイル

<mobile_and_social_application_profile_description>

OAMアプリケーション・プロファイルの説明

Community-Gadgetsプロファイルの説明

例80-1 サンプル・スクリプト

createRPApplication('Facebook,Twitter,Linkedin,Google,Yahoo', 'password',
'http://prodcg.example.com:8080/cg/external-auth/oam/', 'DefaultServiceProviderInterface',
'[{app.logintype:idp}, {app.login.popup:true},
{app.user.registration.enabled:true}, {app.registration.url:
"http://prodcg.example.com:8080/cg/external-auth/oam/"}, {
app.userid.attribute.name:uid},
{idaas.rest.crudservice:"/userprofile"},
{idaas.rest.tokenservice:"/internetidentityauthentication"},
{app.user.provisioning.mapping:"uid:Login ID:user_id:true:true;mail:Email
ID:mail:true:false;firstname:First Name:firstname:true:false;lastname:Last
Name:lastname:true:false;displayname:Display
Name:displayname:true:false;name:Common
Name:username:true:false;jpegphoto:User Image:image:true:false;"}]',
'[{Facebook:[{user_id:id}, {mail:email}, {displayname:name}]},
{Twitter:[{user_id:id_str}, {displayname:name}, {image:profile_image_url}]},
{Linkedin:[{user_id:id}, {image:picture-url}, {firstname:first-name},
{lastname:last-name}]}, {Google:[{user_id:email}, {mail:email},
{firstname:firstname}, {lastname:lastname}]}, {Yahoo:[{user_id:email},
{mail:email}, {firstname:firstname}, {lastname:lastname},
{displayname:fullname}]}]', '[{user_id:uid}, {mail:mail},
{firstname:firstname}, {lastname:lastname}, {displayname:displayname},
{username:name}, {image:jpegphoto}]', '', 'Community Gadgets profile',
'Community Gadgets profile description');

統合プロセスを完了するには、第80.6.5項「Community-GadgetsとOMSASの統合の有効化」で説明される手順を実行します。

80.6.5 Community-GadgetsとOMSASの統合の有効化

Mobile and Socialサービスに対するインターネット・アイデンティティ・プロバイダを定義し、Community-Gadgetsアプリケーション用のMobile and Socialアプリケーション・プロファイルを作成した後の最後の手順は、Community-GadgetsとOMSASの統合を有効化することです。

本番システム上のCommunity-Gadgetsインスタンスで:

1. <cg_install_dir/deploy/production/production_node1フォルダ(またはインストール時に作成したフォルダ)に移動します。(詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。)

2. setup_auth.propertiesファイルを開いて、OAM - Social Settingsセクションを次のように変更します。

1. widgets.external_auth.oam.attrs.enabledパラメータをtrueに設定して、Mobile and Socialサポートを有効にします。

## OAM - Social Settings
#######################################
#
# Enabling OAM - Social support
# Default is "false"
#
widgets.external_auth.oam.attrs.enabled=true

2. widgets.external_auth.oam.attrs.hosturlパラメータにOAM管理対象サーバーURLを指定します。

## OAM - Social server URL
widgets.external_auth.oam.attrs.hosturl=<oam_protocol>://<oam_host>:
<oam_port>

3. widgets.external_auth.oam.attrs.application_nameパラメータにOMSASアプリケーション・プロファイル名を指定します。

# OAM - Social application name
#
widgets.external_auth.oam.attrs.application_name=<mobile_and_social_application_profile_name>

4. widgets.external_auth.oam.attrs.sharedsecretパラメータにOMSASアプリケーション・プロファイル・シークレットを指定します。

# OAM - Social application shared secret
#
widgets.external_auth.oam.attrs.sharedsecret=<application_profile_shared_secret>

5. ファイルを保存します。

3. Community-Gadgetsを再起動します。

4. 一般管理者の資格証明を使用してCommunityインタフェースまたはGadgetsインタフェースを開きます。

1. 「ログイン・バー」メニューで、「構成」オプションを選択します。

2. 図80-37に示すように、「ソーシャル・ログインと共有の設定」画面で、「Oracle Mobile and Social Access Managementとの統合の有効化」オプションを選択します。

図80-37 ソーシャル・ログインと共有の設定 - Oracle Mobile and Social Access Management

3. 「保存」をクリックして、この設定を適用します。

80.7 WebSphere Application Server上のソーシャル・ネットワーキング・サービスの有効化

Community-Gadgets WebアプリケーションとFacebook、Twitter、GoogleまたはJanrainをWASインスタンス上で統合した場合、この項で説明する手順を実行して、Community-Gadgetsとこれらのソーシャル・ネットワーキング・サイト間の通信を有効にする必要もあります。

この項は、次のトピックで構成されています。

- 第80.7.1項「セキュリティ証明書のエクスポート」

- 第80.7.2項「セキュリティ証明書のWebSphereへのインポート」

80.7.1 セキュリティ証明書のエクスポート

Community-Gadgets Webアプリケーションでネイティブ・ソーシャル統合およびログイン・オプションを有効化した場合(図80-25を参照)、それらをWebSphereでの統合を有効化する必要があるため、アプリケーション証明書をエクスポートします。

ヒント:

ネイティブ・ログインの無効化は、「ログイン・バー」→「構成」および「ソーシャル・ログインの無効化」オプションを選択し、CommunityインタフェースおよびGadgetsインタフェースを介して行うことができます。この機能を無効化する場合は、Webサイト上に表示されるログイン画面で訪問者のローカル資格証明(Webサイト上で使用されます)が必要になります。

1. セキュリティ証明書を取得するには、FireFoxブラウザで、プロバイダのURL (表80-3を参照)を開きます。例: https://developers.facebook.com/docs/reference/api

表80-3 プロバイダのURL

プロバイダ

URL

Facebook

https://developers.facebook.com/docs/reference/api

Twitter

https://api.twitter.com

Janrain

https://rpxnow.com/

Google

https://accounts.google.comおよびhttps://www.googleapis.com

2. 「ツール」メニューで、「ページの情報」を選択します。

3. 「セキュリティ」タブで、「証明書を表示」(図80-38)をクリックして、「証明書ビューア」ダイアログ・ボックスを表示します。

図80-38 Facebookセキュリティ証明書

4. 最下部のノードを選択します。

5. 「詳細」タブで、「エクスポート」をクリックします。

6. 「保存する場所」ドロップダウン・リストから、この証明書を保存するディレクトリを選択します。

7. 「証明書をファイルに保存」ダイアログ・ボックスの「ファイルの種類」フィールドで「X.509証明書(DER)」を選択します。

8. 「保存」をクリックします。

9. 最下部のノードの親について、手順5から8を繰り返します。

注意:

Facebookでは、さらにEntrust.netセキュア・サーバー証明書が必要です。この証明書は、インターネット・エクスプローラから、「インターネット・オプション」→「コンテンツ」→「証明書」→「Entrust.net Secure Server Certification Authority」を選択して、ダウンロードできます。

10. 表80-3のプロバイダURLごとに、手順3から9を繰り返します。

80.7.2 セキュリティ証明書のWebSphereへのインポート

セキュリティ証明書をWebSphereにインポートするには:

1. WAS管理コンソールにログインします。

2. 「Security」を開き、「SSL certificate and key management」をクリックします。

3. 「Configuration settings」の下にある「Manage endpoint security configurations」をクリックします(80-39を参照)。

図80-39 構成設定

4. 「Local Topology」タブの下の「Outbound」を開いて、(セル)を取得するための適切なアウトバウンド構成を選択します。

5. 右側の「Related Items」の下で、「Key stores and certificates」をクリックします。

6. 「Preferences」の下で、「CellDefaultTrustStore」キー・ストアを選択します(図80-40を参照)。

図80-40 プリファレンス: CellDefaultTrustStore

7. 右側の「Additional Properties」の下にある「Signer certificates」をクリックします。

8. 「Preferences」の下にある「Add」(図80-41)をクリックします。

図80-41 プリファレンス: 追加

9. 「Alias」フィールドに、追加する証明書に従ってURL名を入力します(図80-42を参照)。例: graph.facebook.com_cert、api.twitter.com_ certまたはrpxnow.com_cert

10. 「File name」フィールドに、保存されている証明書へのパスを入力します(図80-42を参照)。

11. 「Data type」で「Binary DER data」を選択します(図80-42を参照)。

図80-42 SSL証明書とキー管理: データ型

12. 「Apply」をクリックします。

81 Community-Gadgets: 機能のカスタマイズ

Community-Gadgets Webアプリケーションは、CSS、テンプレート、検索エンジン最適化(SEO)などの多数のカスタマイズ可能な拡張ポイントを提供しています。これらを使用して、Community-Gadgetsウィジェットの外観と機能性を変更できます。ただし、カスタマイズ可能な拡張ポイントを使用しても、特定のWebサイト設計や使用戦略がウィジェットに適用されていることが原因で、特定の顧客のプロジェクト要件を常に満たせるとはかぎりません。このようなシナリオでは、WebCenter Sitesデータ構造を直接操作し、それらをページ・テンプレートでカスタム手法を使用して個別にレンダリングすることを検討してください。

この章では、WebCenter Sitesデータ構造について詳しく説明します。次の項で構成されます。

- 第81.1項「Community-Gadgetsのデータ・モデルの概要」

- 第81.2項「CSSおよびウィジェット・テンプレートのカスタマイズ」

- 第81.3項「カスタム・ワード・フィルタの作成」

- 第81.4項「CAPTCHAジェネレータの作成」

- 第81.5項「ダッシュボード・テーマのカスタマイズ」

- 第81.6項「Community-Gadgetsのイベント処理」

81.1 Community-Gadgetsのデータ・モデルの概要

Community-Gadgetsは、WebCenter Sitesをデータ・リポジトリとして利用し、Webエクスペリエンス管理(WEM)フレームワークによって提供されるREST APIを通じてそのWebCenter Sitesと通信します。Community-Gadgetsのデータ構造をWebCenter Sitesリポジトリに格納することによって、WebCenter Sitesのアセット・モデルやキャッシング・システムを活用できます。

Community-Gadgets Webアプリケーションのオブジェクト・データ・モデルは、次のカテゴリとオブジェクトによって構成されます。

第81.1.1項「コメント」

- オブジェクト: CommentFeed

- オブジェクト: CommentRecord

第81.1.2項「レビュー」

- オブジェクト: ReviewFeed

- オブジェクト: ReviewRecord

第81.1.3項「評価」

- オブジェクト: RatingFeed

- オブジェクト: RatingRecord

第81.1.4項「投票」

第81.1.5項「トピック」

第81.1.6項「訪問者」

- オブジェクト: User

- オブジェクト: UserIdentity

- オブジェクト: UserLink

第81.1.7項「ガジェットとダッシュボード」

- オブジェクト: Gadget

- オブジェクト: OpenSocialDescriptor

- オブジェクト: SingleGadgetData

- オブジェクト: GadgetSet

図81-1は、これらのカテゴリとオブジェクトを図式化したものです。ユーザー生成コンテンツ・セクションでは、ビジネス・オブジェクトがコメントやレビューなどのCommunityウィジェットに関連付けられている様子が示されています。ユーザー生成コンテンツ(UGC)の各エントリには、それが登録済ユーザーによって投稿された場合、ユーザー・オブジェクトのセットが関連付けられます(訪問者セクション)。

図81-1 カテゴリとオブジェクトのレイアウト

図81-1に表示されているオブジェクトは、表81-1に示すように、WebCenter Sitesのデータベース表に格納されます。

表81-1 オブジェクトのデータベース表名

オブジェクト

データベース表名

CommentFeed

cg_comment_feed

CommentRecord

cg_comment_record

ReviewFeed

cg_review_feed

ReviewRecord

cg_review_record

RatingFeed

cg_rating_feed

RatingRecord

cg_rating_record

Polls

cg_poll

Topics

cg_topic

User

cg_user

UserIdentity

cg_user_id

UserLink

cg_user_link

81.1.1 コメント

コメントには、次の種類のプライマリ・オブジェクトが関連付けられます。

- 第81.1.1.1項「CommentFeed」

- 第81.1.1.2項「CommentRecord」

81.1.1.1 CommentFeed

このオブジェクトは、ウィジェットがデプロイされているWebページの計算された概要情報を表します。CommentFeedオブジェクトは、「コメント」ウィジェットがデプロイされているページが最初にアクセスされたときにデータベースに作成されます。

コメントとそのコメントが表示されるページの間の関係を決定するために、Community-Gadgets Webアプリケーションは、WebページのURL(ウィジェットのデプロイメント・タグ内にあるアプリケーション生成キー)、またはリソースID(ウィジェットのデプロイ時に管理者が指定可能)を使用します。WebページのURLがキーとして利用可能である場合は、そのページURLから生成されたハッシュがCommentFeedオブジェクト内に記録されます。リソースIDが指定されている場合は、そのリソースIDがCommentFeedオブジェクト内に記録されます。CommentFeedオブジェクトは複数のコメントを保持し、コメントを表すCommentRecordオブジェクトと1対多のアソシエーションを持ちます。

CommentFeedオブジェクトは、WebCenter Sites内ではcg_comment_feedベーシック・アセットとして格納され、それに対応してデータベース内ではcg_comment_feed表として格納されます。表81-2は、このアセットの構造の説明です。

表81-2 "cg_comment_feed" AssetTypeの構造

プロパティ

型

説明

id

BIGINT

一意のアセット識別子またはAssetTypeの主キー。

cos_resource_id

VARCHAR(256)

ディスカッションの識別子。これは、Community-Gadgetsが、訪問者がコメントを投稿したページとコメントのリストを関連付けるために使用する論理リンクです。このリンクは、ウィジェットのデプロイ時に、デプロイメント・ページの「リソースID」フィールドの値、またはウィジェット・コード・スニペット内のresource_id属性を指定することによって確立されます。指定されていない場合、Community-GadgetsはページURLのハッシュをリソースIDとして使用します。resource_id生成の独自の戦略を立てることをお薦めします。たとえば、データベース内でこのオブジェクトをより簡単に検索できるようにするため、ページIDをリソースIDとして使用できます。

cos_url

VARCHAR(256)

コメント・ディスカッション・スレッドをホストするURL。

cos_date_created

DATE

フィード・オブジェクトが作成された日付。

cos_date_modified

DATE

フィードの最新の変更日。

cos_modified_by

VARCHAR(256)

フィードを最後に変更したユーザーのID。

cos_owner

VARCHAR(256)

フィード・オブジェクトを作成したユーザーのID。(フィード・オブジェクトは、最初のページ・ロード時にウィジェットがデプロイされた直後に作成されます。通常、これはゲスト・セッションを使用して実行されるため、-1が典型的な値です。)

cos_approved_count

BIGINT

モデレーションを正常にパスし、訪問者に対して表示されるコメントの数。

cos_pending_count

BIGINT

モデレーションをまだパスしていないコメントの数。

cos_ext_type

VARCHAR(256)

コンテンツ・カテゴリのID。ファイル、記事、ブログなど、コメントの添付先コンテンツのタイプを示します。(デプロイメント・ページのResource Typeパラメータとして、またはウィジェット・デプロイメント・コード・スニペットのresource_type属性として指定されます。)

cos_resource_title

VARCHAR(256)

「コメント」ウィジェットがデプロイされるページのタイトル。デフォルトでは、ここにはウィンドウ・タイトルの値が記録されます。ページ・デザイナは、デプロイメント・コード・スニペット内のresource_title属性を指定することによってこの値をカスタマイズできます。

cos_posting_status

VARCHAR(256)

Adminインタフェースを通じてトピック・ページによって定義される投稿ステータスの状態。可能な値: open、closed

81.1.1.2 CommentRecord

このオブジェクトは、サイト・ページの訪問者によって投稿されたコメントを表します。これは、cos_root_idフィールドを介して多対1でCommentFeedオブジェクトに論理的にリンクされます。つまり、多数のCommentRecordオブジェクトを1つのCommentFeedオブジェクトにリンクできます。

表81-3 cg_comment_record assetTypeの構造

プロパティ

型

説明

id

BIGINT

コメントの識別子。

cos_text

VARCHAR(4000)

投稿されたコメントの内容。VARCHAR(4000)データ型は、WebCenter Sitesがインストールされているデータベースに対する、最も効率的な記憶域タイプ(CLOBなど)に変換されます。

cos_root_id

BIGINT

会話が行われているページを表すCommentFeedオブジェクトへのアソシエーション。ここには、対応するcg_comment_feed.id項目の値が格納されます。

この列を使用して、1つのページに投稿されたすべてのコメントを問い合せることができます。

cos_state_value

VARCHAR(450)

コメントの状態。コメントのモデレーションのステージを表します。

手動モデレーションが有効な場合、次の値になることがあります。

- pending.new(新規投稿)

- pending.modified(手動モデレーション)

コメントがモデレーションをパスしたか、または自動パブリッシュされた場合、値は次のようになります。

- approved.all

コメントが自動フィルタまたはモデレータによってパスにならなかった場合、値は次のようになります。

- inappropriate.robotdetected

- inappropriate.humandetected

モデレータのナビゲーションを簡素化するため、Communityインタフェースにはこれらのカテゴリに基づくフィルタが含まれています。

cos_owner

BIGINT

コメントを投稿した訪問者のID。ゲストによるエントリである場合は-1。

cos_owner_ip

VARCHAR(256)

コメントの投稿元のクライアントのIPアドレス。

cos_guest_name

VARCHAR(450)

コメント・エントリを投稿した登録済ユーザーまたはゲストの表示名。Communityインタフェース内では、このフィールドを使用して、データベースに追加リクエストをすることなくコメントを作成者名でソートして表示できます。

cos_guest_email

VARCHAR(450)

コメントの権限設定によってゲスト(未認証の訪問者)による投稿が可能になっており、訪問者に対して電子メールIDの指定が求められる場合、この列に電子メールIDが保存されます。

cos_level

BIGINT

コメントに対する返信が有効になっている場合の、コメント・スレッド内でのコメントのレベル。この数字が大きいほど、ツリーのより深い場所にコメントが投稿されています。

初期値は1です。

cos_parentid

BIGINT

返信が投稿された直接の親コメントのID。

cos_parent0id

cos_parent9id

BIGINT

階層内でのコメントの親のチェーン。リーフからルートへのパスです。

cos_flagged

VARCHAR(32)

trueまたはfalseのいずれか。他の訪問者によってコメントにフラグが付けられ、報告されたかどうかに基づきます。

cos_flagged_count

BIGINT

コメントにフラグが付けられた回数。

cos_record_rank

VARCHAR(450)

コメントに対する有用性レポート(「はい」および「いいえ」)の数。カンマで区切られ、0から始まります。初期値は0,0です。

cos_record_rank_calculated

INTEGER

他の訪問者によって報告された有用性に基づいて事前計算されたコメントのランク。「はい」の数から「いいえ」の数を減算することによって計算されます。

cos_date_created

DATE

コメントが投稿された日付。

cos_date_modified

DATE

コメントの最新の変更日付(登録済ユーザーは自分のコメントを変更できます。モデレータがコメントを変更する場合もあります)。

cos_reply_count

BIGINT

ディスカッション・スレッドが有効になっており、コメントに返信を投稿できる場合、現在のコメントに対する返信数がここに記録されます。

この数は再帰的ではないため、直接の子コメントのみが考慮されます(子の子は除外される)。

cos_thread_order

VARCHAR(450)

特定の書式で生成される文字列。単純なWEM REST問合せとアルファベット順の順序付けを使用するスレッド階層によるコメントの順序付けを有効にします。生成戦略は次のとおりです。

- これがルート・レベルのコメントである場合(別のコメントに対する返信として投稿されたものでない場合)、cos_date_createdフィールドの値(16進数形式)が記録されます。

- コメントに親コメントがある場合、親のcg_comment_record.cos_thread_orderフィールドとアンダースコア(_)フィールド、およびcos_date_createdフィールド(16進数形式)が連結された値になります。

81.1.2 レビュー

レビューには、次の種類のプライマリ・オブジェクトが関連付けられます。これらのオブジェクトは、コメントのオブジェクトと似ています。

- 第81.1.2.1項「ReviewFeed」

- 第81.1.2.2項「ReviewRecord」

81.1.2.1 ReviewFeed

このオブジェクトは、サイト・ページに投稿されたレビューのリストを表します。ReviewFeedオブジェクトは、第81.1.1.1項「CommentFeed」で説明したCommentFeedオブジェクトに非常に似ています。Community-Gadgetsは、同じコード・インフラストラクチャを使用して、これらのオブジェクトを処理します。ただし、データベース・スキーマ・レベルのメンテナンスを簡易化するために、CommentFeedおよびReviewFeedのデータは2つの個別の表に格納されます。CommentFeedとReviewFeedの唯一の相違は、ReviewFeedにはすべての投稿されたレビューを対象に計算された平均ランクに関する追加情報が含まれる点です。

ReviewFeedオブジェクトは、「レビュー」ウィジェットがデプロイされているページが最初にアクセスされたときにデータベースに作成されます。

レビューとそのレビューが表示されるページの間の関係を決定するために、Community-Gadgetsは、WebページのURL(ウィジェットのデプロイメント・タグ内にあるアプリケーション生成キー)、またはリソースID(ウィジェットのデプロイ時に管理者が指定可能)を使用します。WebページのURLがキーとして利用可能である場合は、そのページURLから生成されたハッシュがReviewFeedオブジェクト内に記録されます。リソースIDが指定されている場合は、そのリソースIDがReviewFeedオブジェクト内に記録されます。ReviewFeedオブジェクトは複数のレビューを保持し、レビューを表すReviewRecordオブジェクトと1対多のアソシエーションを持ちます。

レビュー・フィード・オブジェクトは、WebCenter Sites内ではcg_review_feedベーシック・アセットとして格納され、それに対応してデータベース内ではcg_review_feed表として格納されます。表81-4は、このアセットの構造の説明です。

表81-4 cg_review_feed AssetTypeの構造

プロパティ

型

説明

id

BIGINT

一意のアセット識別子またはAssetTypeの主キー。

cos_resource_id

VARCHAR(256)

ディスカッションの識別子。これは、Community-Gadgetsが、レビューされたトピックが投稿されたページとレビューのリストを関連付けるために使用する論理リンクです。このリンクは、ウィジェットのデプロイ時に、デプロイメント・ページの「リソースID」フィールドの値、またはウィジェット・コード・スニペット内のresource_id属性を指定することによって確立されます。指定されていない場合、Community-GadgetsはページURLのハッシュをリソースIDとして使用します。resource_id生成の独自の戦略を立てることをお薦めします。たとえば、データベース内でこのオブジェクトをより簡単に検索できるようにするため、ページIDをリソースIDとして使用できます。

cos_url

VARCHAR(256)

レビューが投稿されたディスカッションをホストするURL。

cos_date_created

DATE

フィード・オブジェクトが作成された日付。

cos_date_modified

DATE

フィードの最新の変更日。

cos_modified_by

VARCHAR(256)

フィードを最後に変更したユーザーのID。

cos_owner

VARCHAR(256)

フィード・オブジェクトを作成したユーザーのID。(フィード・オブジェクトは、最初のページ・ロード時にウィジェットがデプロイされた直後に作成されます。通常、これはゲスト・セッションを使用して実行されるため、-1が典型的な値です。)

cos_approved_count

BIGINT

モデレーションを正常にパスし、訪問者に対して表示されるレビューの数。

cos_pending_count

BIGINT

モデレーションをまだパスしていないレビューの数。

cos_rank

FLOAT

ページに投稿されたレビューに付けられたすべてのランクの平均(算術平均として計算される)。たとえば、ページに2つのレビューが投稿され、1つには星3つが、もう1つには星5つが与えられた場合、このフィールドの値は3+5/2 = 4となります。

cos_rank_precalculation

VARCHAR(450)

投稿されたランクの数のカンマ区切りリスト。このリストには全部で5つの項目が格納されます。リストのそれぞれの位置(索引)には、レビューに与えられたそれぞれの星の数のカウント数が格納されます。たとえば、3つのレビューがあり、1つのレビューに星3つが与えられ、他の2つのレビューに星5つが与えられた場合、残りの位置には0が置かれ、このリストには0,0,1,0,2が格納されます。対応する位置の投稿されたレビュー数に注目します。具体的な位置から、投票数/星の数を知ることができます。

cos_thumbs_up_rank

VARCHAR(450)

レビューのタイプがサムズ・アップ/ダウンに設定されている場合は、このフィールドに投票が記録されます。これは非正規化されたフィールドであり、サムズ・アップとサムズ・ダウンの数がカンマに区切られて格納されます。たとえば、レビューが3つあり、そのうち2つにサムズ・アップが付けられ、1つにサムズ・ダウンが付けられた場合、このフィールドの値は2,1,になります。

cos_ext_type

VARCHAR(256)

ファイル、記事、ブログなど、レビューが付加されるコンテンツの種類を表す、コンテンツ・カテゴリのID。(デプロイメント・ページのResource Typeパラメータとして、またはウィジェット・デプロイメント・コード・スニペットのresource_type属性として指定されます。)

cos_resource_title

VARCHAR(256)

「レビュー」ウィジェットがデプロイされるページのタイトル。デフォルトでは、ここにはウィンドウ・タイトルの値が記録されます。ページ・デザイナは、デプロイメント・コード・スニペット内のresource_title属性を指定することによってこの値をカスタマイズできます。

cos_posting_status

VARCHAR(256)

adminインタフェースを通じてトピック・ページによって定義される投稿ステータスの状態。可能な値: open、closed

81.1.2.2 ReviewRecord

このオブジェクトは、サイト・ページの訪問者によって投稿されたレビューを表します。これは、cos_root_idフィールドを介して多対1でReviewFeedオブジェクトに論理的にリンクされます。

表81-5 cg_review_record AssetTypeの構造

プロパティ

型

説明

id

BIGINT

レビューの識別子。

cos_text

VARCHAR(4000)

投稿されたレビューの内容。VARCHAR(4000)データ型は、WebCenter Sitesがインストールされているデータベースに対する、最も効率的な記憶域タイプ(CLOBなど)に変換されます。

cos_title

VARCHAR(450)

投稿されたレビューのタイトル。

cos_rank

FLOAT

訪問者によってレビューに与えられた星の数(ランク)。評価タイプがサムズ・アップ/ダウンの場合、5がサムズ・アップの値であり、1がサムズ・ダウンの値です。

cos_thumbs_up

INTEGER

評価タイプがサムズ・アップ/ダウンに構成されている場合、ここにランク値が格納されます。1がサムズ・アップの値であり、-1がサムズ・ダウンの値です。

cos_rating_type

INTEGER

与えられたレビュー・ランクのタイプ。可能な値コードは次のとおりです。

0: 星

1: サムズ・アップ/ダウン

cos_root_id

BIGINT

レビューが送信されたページを表すReviewFeedオブジェクトへのアソシエーション。

ここには、対応するcg_review_feed.id項目の値が格納されます。この列を使用して、1つのページに投稿されたすべてのレビューを問い合せることができます。

cos_state_value

VARCHAR(450)

レビューの状態。コンテンツのモデレーションのステージを表します。手動モデレーションが有効な場合、次の値になることがあります。

- pending.new(新規投稿)

- pending.modified(手動モデレーションが行われた)

レビューがモデレーションをパスしたか、または自動パブリッシュされた場合、値は次のようになります。

- approved.all

レビューが自動フィルタまたはモデレータによってパスにならなかった場合、値は次のようになります。

- inappropriate.robotdetected

- inappropriate.humandetected

モデレータのナビゲーションを簡素化するため、Communityインタフェースにはこれらのカテゴリに基づくフィルタが含まれています。

cos_owner

BIGINT

レビューを投稿した訪問者のID。ゲストによるエントリである場合は-1。

cos_owner_ip

VARCHAR(256)

レビューの投稿元のクライアントのIPアドレス。

cos_guest_name

VARCHAR(450)

レビュー・エントリを投稿した登録済ユーザーまたはゲストの表示名。Communityインタフェース内では、このフィールドを使用して、データベースに追加リクエストをすることなくレビューを作成者名でソートして表示できます。

cos_guest_email

VARCHAR(450)

レビューの権限設定によってゲスト(未認証の訪問者)による投稿が可能になっており、訪問者に対して電子メールIDの指定が求められる場合、この列に電子メールIDの値が保存されます。

cos_flagged

VARCHAR(32)

trueまたはfalseのいずれか。他の訪問者によってレビューにフラグが付けられ、報告されたかどうかに基づきます。

cos_flagged_count

BIGINT

他の訪問者がレビューにフラグを付けた回数。

cos_record_rank

VARCHAR(450)

レビューに対する有用性レポート(「はい」および「いいえ」)の数。カンマで区切られ、0から始まります。初期値は0,0です。

cos_record_rank_calculated

INTEGER

他の訪問者によって報告された有用性に基づいて事前計算されたレビューのランク。「はい」の数から「いいえ」の数を減算した値です。

cos_date_created

DATE

レビューが投稿された日付。

cos_date_modified

DATE

レビューの最新の変更日。(登録済ユーザーのみが自分のレビューを変更できます。必要に応じてモデレータがレビューを変更することも可能です。)

81.1.3 評価

このオブジェクトには、トピックまたはページ上の投稿に対して訪問者が与えた評価のリストが格納されます。これはReviewFeedオブジェクトに酷似しています。

Ratingsオブジェクトは、「評価」ウィジェットがWebサイトにデプロイされた後、Webページが最初にアクセスされたときにデータベースに作成されます。

評価とその評価が表示されるページの間の関係を決定するために、Community-Gadgetsは、WebページのURL(ウィジェットのデプロイメント・タグ内にあるアプリケーション生成キー)、またはリソースID(ウィジェットのデプロイ時に管理者が指定可能)を使用します。WebページのURLがキーとして利用可能である場合は、そのページURLから生成されたハッシュがRatingFeedオブジェクト内に記録されます。リソースIDが指定されている場合は、そのリソースIDがRatingFeedオブジェクト内に記録されます。RatingFeedオブジェクトは複数の評価を保持し、評価を表すRatingRecordオブジェクトと1対多のアソシエーションを持ちます。

評価フィード・オブジェクトは、WebCenter Sites内ではcg_rating_feedベーシック・アセットとして格納され、それに対応してデータベース内ではcg_rating_feed表として格納されます。

評価には、次の種類のプライマリ・オブジェクトが関連付けられます。

- 第81.1.3.1項「RatingFeed」

- 第81.1.3.2項「RatingRecord」

表81-6および表81-7は、cg_rating_feed assetTypeの構造の説明です。

81.1.3.1 RatingFeed

表81-6 cg_rating_feed AssetTypeの構造

プロパティ

型

説明

id

BIGINT

ページに投稿された評価のリストを保持するオブジェクトの識別子。

cos_resource_id

VARCHAR(256)

特定のWebページ上における評価の識別子。

これは、Community-Gadgetsが評価のリストと該当するページを関連付けることができるようにするための論理リンクです。このリンクは、ウィジェットのデプロイ時に、デプロイメント・ページの「リソースID」フィールドの値、またはウィジェット・コード・スニペット内のresource_id属性を指定することによって確立されます。この値は生成することも、手動で入力することもできます。この値が指定されない場合、Community-GadgetsはページURLのハッシュをリソースIDとして使用します。

resource_id生成の独自の戦略を立てることをお薦めします。たとえば、データベース内でこのオブジェクトをより簡単に検索できるようにするため、ページIDをリソースIDとして使用するという方法が考えられます。

cos_url

VARCHAR(256)

訪問者が評価を設定したWebページのURL。

cos_date_created

DATE

フィード・オブジェクトが作成された日付。

cos_date_modified

DATE

フィードの最終変更日。

cos_owner

VARCHAR(256)

最初にフィード・オブジェクトを作成したユーザーのID。(これは最初のページ・ロード時にウィジェットがデプロイされた直後に発生します。通常、フィード・オブジェクトはゲスト・セッションを通じて作成されるため、-1が典型的な値です。)

cos_approved_count

BIGINT

モデレーションを正常にパスし、一般的な評価計算でカウントされる評価の数。

cos_pending_count

BIGINT

モデレーションをまだパスしていない評価の数。

cos_stars_rank

FLOAT

訪問者によって投稿されたすべての星タイプの評価の平均(算術平均)。たとえば、2つの評価があり、1つは星3つのランク、もう1つは星5つのランクである場合、この値は3+5/2 = 4と計算されます。

cos_stars_rank_precalculation

VARCHAR(450)

評価の数のカンマ区切りリスト。このリストには全部で5つの項目が格納されます。リストのそれぞれの位置(索引)には、与えられたそれぞれの星の数のカウント数が格納されます。たとえば評価が3つあり、そのうち1つに星3つが与えられ、他の2つに星5つが与えられた場合、このリストの0は欠落している位置を示します。そのため、リストは0,0,1,0,2となります。対応する位置の評価の数に注意してください。具体的な位置から、投票数/星の数を知ることができます。

cos_thumbs_up_rank

VARCHAR(450)

評価のタイプがサムズ・アップ/ダウンに設定されている場合は、このフィールドに評価が記録されます。これは非正規化されたフィールドであり、サムズ・アップとサムズ・ダウンの数がカンマに区切られて格納されます。たとえば評価が3つあり、そのうち2つがサムズ・アップで、1つがサムズ・ダウンである場合、格納される値は2,1になります。

cos_likeit_count

BIGINT

like itの評価タイプがデプロイされている場合、このフィールドに「いいね」の数が記録されます。

cos_recommend_count

BIGINT

recommendの評価タイプがデプロイされている場合、このフィールドに「お薦め」の数が記録されます。

cos_ext_type

VARCHAR(256)

コンテンツ・カテゴリのID。ファイル、記事、ブログなど、評価の添付先コンテンツのタイプを示します。デプロイメント・ページのResource Typeパラメータの値として、またはウィジェット・デプロイメント・コード・スニペットのresource_type属性として指定されます。

cos_resource_title

VARCHAR(256)

「評価」ウィジェットがデプロイされるページのタイトル。デフォルトでは、ウィンドウ・タイトルの値がページ・タイトルとして記録されます。ページ・デザイナは、デプロイメント・コード・スニペット内のresource_title属性を指定することによってこの値をカスタマイズできます。

81.1.3.2 RatingRecord

このオブジェクトは、サイト・ページの訪問者によって投稿された評価を表します。これは、「cos_root_id」フィールドを介してRatingFeedオブジェクトに論理的にリンクされます。このオブジェクトは、多対1関係モデルに基づいています。

表81-7 cg_rating_record AssetTypeの構造

プロパティ

型

説明

id

BIGINT

評価の識別子。

cos_thumbs_up

INTEGER

評価のタイプがサムズ・アップ/ダウンに構成されている場合、ここにランク値が記録されます。1がサムズ・アップの値であり、-1がサムズ・ダウンの値です。

cos_rating_type_value

INTEGER

評価ランクのタイプ。

可能な値コードは次のとおりです。

0: 星

1: サムズ・アップ/ダウン

2: いいね

3: お薦め

cos_root_id

BIGINT

評価が送信されたページを表すRatingFeedオブジェクトへのアソシエーション。ここには、対応するcg_rating_feed.id項目の値が記録されます。この列を使用して、1つのページに投稿されたすべての評価を問い合せることができます。

cos_state_value

VARCHAR(450)

評価の状態。内容のモデレーションのステージを表します。

手動モデレーションが有効な場合、値はpending.new(新規投稿)またはpending.modified(手動モデレーション)になることがあります。

評価がモデレーションをパスしたか、または自動パブリッシュされた場合、値はapproved.allになります。

評価が自動フィルタまたはモデレータによってパスにならなかった場合、値はinappropriate.robotdetectedまたはinappropriate.humandetectedになります。

モデレータのナビゲーションを簡素化するため、Communityインタフェースの右側のパネルにはこれらのカテゴリのフィルタが用意されています。

cos_owner

BIGINT

評価を投稿した訪問者のID。ゲストによるエントリの場合は-1。

cos_owner_ip

VARCHAR(256)

評価の投稿元のクライアントのIPアドレス。

cos_guest_name

VARCHAR(450)

評価を与えた登録済ユーザーまたはゲストの表示名。Communityインタフェース内では、このフィールドを使用して、データベースに追加リクエストをすることなく評価を作成者名でソートして表示できます。

81.1.4 投票

投票機能はデータベース内の1つの表によって表されます。管理者が投票を作成するときに、対応する行がこの表に追加されます(表81-8)。

表81-8 cg_poll AssetTypeの構造

プロパティ

型

説明

id

BIGINT

投票インスタンスの識別子。

cos_uid

VARCHAR(256)

投票インスタンスの一意の文字列による識別子。これは通常のIDとともにデプロイメント・コード・スニペットに埋め込まれます。データ移行時に整数のIDが失われた場合は、システムはUIDによってこの投票を見つけることができます。これにより、既存のデプロイメントの破損を防止できます。

cos_chart_type

INTEGER

投票結果を表示するグラフのタイプ。

可能な値は次のとおりです。

- 0: 円グラフ

- 1: 棒グラフ

- 2: フラットな結果(オプションでパーセントが表示される)

cos_theme

INTEGER

Webサイト上で投票に適用されるテーマのID。可能な値は次のとおりです。

- 0: 基本

- 1: 詳細

- 2: デザインなし

- 3: オープン・デザイン

cos_start_date

DATE

投票が開始される日付。投票キャンペーンの開始日です。

cos_finish_date

DATE

投票が終了し、これ以上投票できなくなる日付。投票キャンペーンの終了日です。

cos_result_required

VARCHAR(32)

投票後に結果を表示するかどうかを指定するブール値(trueまたはfalse)。

cos_results_view

INTEGER

投票結果をどのように表示するかを指定します。

- 0: コンテキスト・メニュー

- 1: インプレース

- 投票ウィジェットの内部

cos_results_width

INTEGER

投票結果のコンテキスト・メニューの幅(ピクセル単位)。

cos_title

VARCHAR(450)

投票のタイトル。

cos_question

VARCHAR(450)

投票の主な質問。

cos_options

VARCHAR(4000)

JSON形式による投票で選択可能な投票オプションのリスト。メタデータには、Community-Gadgetsが内部で使用する投票のID、オプション・タイトル、色および残りの投票数が含まれます。例:

[{"id":"n0","count":1,"color":"#1751a7","value":"Avatar"},{"id":"n1","count":0,"color":"#8aa717","value":"Matrix"}]

cos_thankyou_note

VARCHAR(450)

訪問者に対して投票後に表示されるメッセージ。

cos_disclaimer_required

VARCHAR(32)

投票の免責事項テキストを表示するかどうかを指定するブール値(trueまたはfalse)。

cos_disclaimer

VARCHAR(450)

投票ウィジェットの下部に表示される免責事項テキスト。

cos_votes

INTEGER

現在の投票キャンペーンの合計投票数。

81.1.5 トピック

トピック機能によって、「コミュニティ」ウィジェットのレビュー数、評価値などの統計を収集し事前に計算できるため、後から収集された情報をより簡単かつ効率的に問い合せることができます。訪問者のフィードバックの事前計算と最適化は重要です。このタイプのコンテンツは、サイトのホーム・ページや、最もディスカッションされている/最もレビューされている/最も評価が高い記事をリストする訪問者のダッシュボードに表示されることがあるためです。

CommunityウィジェットがデプロイされたWebページや、それらのページで実行されたアクティビティは、トピック機能の主要な関心事になります。したがって統計は、CommentFeed、ReviewFeed、RatingFeedなどの複数の表にわたって集計されます。

表81-9 cg_topic AssetTypeの構造

プロパティ

型

説明

id

BIGINT

トピック・インスタンスの識別子。

cos_url

VARCHAR(450)

ウィジェットがデプロイされるページのURL。

cos_title

VARCHAR(450)

トピックが関連付けられたページのHTMLタイトル。

cos_resource_id

VARCHAR(450)

UGCコンテンツをウィジェットのデプロイ先ページにリンクするための、ページのリソースID。

cos_date_created

DATE

トピックが作成された日付。ウィジェットのデプロイ先ページが、ブラウザで最初にアクセスされた日付です。

cos_comments_feed_id

BIGINT

対応するCommentFeedオブジェクトとCommentFeed.idフィールドの間の関係。これは、統計の集計対象となっているソース・オブジェクトです。

cos_comment_count

BIGINT

特定のトピックが関連付けられたページで投稿されたコメント数。

cos_comments_resource_type

VARCHAR(450)

ページにデプロイされた「コメント」ウィジェットに割り当てられたコンテンツ・カテゴリ(ブログ、記事など)。デフォルトのカテゴリ値の場合もあれば、「外観」設定ページにアップロードされたカスタマイズされたカテゴリの場合もあります。

cos_comments_date_modified

DATE

CommentFeedオブジェクトが統計値(投稿されたコメント数など)で最後に更新された日付。

cos_reviews_feed_id

BIGINT

トピックが関連付けられたReviewFeedオブジェクトとの関係。

cos_review_count

BIGINT

トピックが関連付けられたページで投稿されたレビュー数。

cos_reviews_resource_type

VARCHAR(450)

ページにデプロイされた「レビュー」ウィジェットに割り当てられたコンテンツ・カテゴリ(ブログ、記事など)。デフォルトのカテゴリの場合もあれば、「外観」設定ページにアップロードされてカスタマイズされたカテゴリの場合もあります。

cos_reviews_date_modified

DATE

ReviewFeedオブジェクトが統計値(投稿されたレビュー数、ランクなど)で最後に更新された日付。

cos_ratings_feed_id

BIGINT

特定のトピックが関連付けられたRatingFeedオブジェクトとの関係。

cos_rating_count

BIGINT

このトピックが関連付けられたページに投稿された評価数。

cos_ratings_resource_type

VARCHAR(450)

ページにデプロイされた「評価」ウィジェットに割り当てられたコンテンツ・カテゴリ(ブログ、記事など)。デフォルトのカテゴリの場合もあれば、「外観」設定ページにアップロードされてカスタマイズされたカテゴリの場合もあります。

cos_ratings_date_modified

DATE

RatingFeedオブジェクトが統計値(投稿された評価数、ランクなど)で最後に更新された日付。

cos_rank

FLOAT

他のトピックと比較した場合の現在のトピックのランク。現在のランキングのスキーマは頻度の統計に基づいており、次のフィールドの合計として計算されます。cos_review_count + cos_comment_count + cos_rating_count。

81.1.6 訪問者

訪問者には、次の種類のプライマリ・オブジェクトが関連付けられます。

- 第81.1.6.1項「User」

- 第81.1.6.2項「UserIdentity」

- 第81.1.6.3項「UserLink」

81.1.6.1 User

User表は、Community-Gadgetsによって保持される訪問者プロファイルを表します。この表には、表示名、電子メール、アバターの画像など、訪問者の個人情報データが含まれます。

表81-10 cg_user AssetTypeの構造

プロパティ

型

説明

id

BIGINT

ユーザー・プロファイルの識別子。

cos_email

VARCHAR(450)

Webサイトの訪問者の電子メール。訪問者がFacebook、Twitter、Googleを使用して、またはJanrainを通じてログインした場合、この情報は入力されない可能性があります。ローカルに登録した訪問者は、この情報を使用することで、必要に応じてパスワードを復元できます。

cos_display_name

VARCHAR(450)

ユーザーの表示名。訪問者が登録時に入力するか、またはユーザーがログインで使用したソーシャル・ネットワーキング・サービスから取得されます。

cos_profile_type_code

INTEGER

ユーザー・プロファイルのタイプ。

可能な値は次のとおりです。

- 0: 通常のユーザーまたは訪問者

- 1: 編集権限のあるユーザーまたは管理ユーザー(コンテンツ・モデレータなど)

- 2: システム・ユーザー、または内部で接続をオープンする際にシステムが使用するユーザー。

packed_identities

VARCHAR(4000)

JSON形式による、訪問者のアイデンティティの非正規化されたリスト。これらのアイデンティティは認証時に使用されるため、このプロファイルにリンクされます。

例: [{"username":"john"}]

usernameフィールドは、対応するUserIdentityエントリにUserIdentity.cos_usernameフィールドを通じて関連付けられます。(Janrain経由で)ソーシャル・ネットワーク・サービスを使用してログインしたユーザーの訪問者プロファイルでは、ユーザー名に「jr:」の接頭辞が付加されます。

[{"username":"jr:http://twitter.com/account/profile?user_id=3333333"}]

cos_picture_blob

BINARY

ソーシャル・ネットワーキング・サービスを使用せずにローカルで登録したローカル・ユーザーのプロファイルでは、このフィールドにカスタマイズされたアバターが格納されます。

cos_picture_url

VARCHAR(450)

ソーシャル・ネットワーキング・サービスを使用してログインしたユーザーのプロファイルでは、ここにアバター画像のURLが格納されます。

81.1.6.2 UserIdentity

訪問者の資格証明を保存する2つのオプションとして、LDAPとWebCenter Sitesデータベースがあります。デフォルトでは、データベース・オプションが設定されます。

データベースが使用される場合、ユーザーの資格証明はUserIdentity表に格納され、対応する訪問者プロファイルにはUserLink表を使用して関連付けられます。

表81-11 cg_user_id AssetTypeの構造

プロパティ

型

説明

id

BIGINT

ユーザーの資格証明の識別子。

cos_username

VARCHAR(256)

認証で使用されるユーザー名。

cos_email

VARCHAR(256)

ユーザーの電子メール。必要に応じてユーザーのパスワードを復元する目的で使用されます。

cos_provider_id

VARCHAR(256)

訪問者の認証で使用されるアイデンティティ・プロバイダのタイプ。

可能な値は次のとおりです。

- none: 内部で接続をオープンしたシステム・ユーザーのアイデンティティである場合。

- ldap: 訪問者がLDAPを通じて認証される場合

- wem-db: WebCenter Sites assetTypeを使用するCommunity-Gadgetsプラグインを通じて訪問者が認証される場合。

cos_encryption_type

VARCHAR(256)

ユーザー・アイデンティティのパスワードを保護するために適用される暗号化アルゴリズム。システムの現在のバージョンで使用されるアルゴリズムはSHA-256です。

cos_password

VARCHAR(256)

認証で使用されるパスワードの暗号化された値。

81.1.6.3 UserLink

表81-12では、訪問者のアイデンティティ(認証の資格証明を保持する)と訪問者のユーザー・プロファイルを適切に関連付けるために、UserIdentityをUserにリンクします。これは非正規化された表であるため、UserIdentity表のいくつかのフィールドもここにキャッシュされます。

表81-12 cg_user_link AssetTypeの構造

プロパティ

型

説明

id

BIGINT

ユーザー・リンクの識別子。

cos_username

VARCHAR(256)

UserIdentityオブジェクトのユーザー名。このリンクによってUserオブジェクトが関連付けられます。

cos_email

VARCHAR(256)

UserIdentityオブジェクトの電子メール。このリンクによってUserオブジェクトが関連付けられます。

cos_provider_id

VARCHAR(256)

UserIdentityオブジェクトのアイデンティティ・プロバイダ・コード。このリンクによってUserオブジェクトが関連付けられます。

可能な値は次のとおりです。

- ext_auth: 訪問者がFacebookやTwitterなどのソーシャル・ネットワークを通じて、またはJanrainを通じて訪問した場合。

- none: 内部で接続をオープンするシステム・ユーザーのアイデンティティである場合。

- ldap: 訪問者がLDAPを通じて認証される場合

- wem-db: WebCenter Sitesのアセットを使用するCommunity-Gadgetsプラグインを通じて訪問者が認証される場合。

cos_account_id

BIGINT

Userオブジェクトの識別子。このリンクによってUserIdentityオブジェクトが関連付けられます。

81.1.7 ガジェットとダッシュボード

ガジェットとダッシュボードの機能には、次の種類のプライマリ・オブジェクトが関連付けられます。

- 第81.1.7.1項「Gadget」

- 第81.1.7.2項「OpenSocialDescriptor」

- 第81.1.7.3項「SingleGadgetData」

- 第81.1.7.4項「GadgetSet」

81.1.7.1 Gadget

Gadget表は、Community-Gadgetsによって保持されるガジェット・ユーザー設定を表します。

表81-13 cg_gadget AssetTypeの構造

プロパティ

型

説明

id

BIGINT

ガジェットの識別子。

original_gadget_id

BIGINT

特定のガジェットの継承元であるGadgetオブジェクトとの関係。

title

VARCHAR(256)

ガジェットのタイトル。

gadget_owner_id

BIGINT

特定のGadgetが関連付けられたUserオブジェクトとの関係。

packed_type

VARCHAR(256)

Gadgetオブジェクトのタイプ。

可能な値:

- user_dash: 末端の訪問者がダッシュボードにリンクしたガジェット。

- site_dash: 管理者がGadgetsインタフェースでダッシュボードにリンクしたガジェット。

- site_registry: サイトのGadgetカタログに追加されたガジェット・オブジェクト。

- global_registry: グローバルなGadgetカタログに追加されたガジェット・オブジェクト。

opensocial_descriptor_url

VARCHAR(4000)

Gadgetsインタフェースでガジェットが登録された際の登録元のOpenSocial XML記述子のURL。

gadgetset_id

BIGINT

特定のGadgetが関連付けられたGadgetSetオブジェクトとの関係。

packed_attributes

VARCHAR(4000)

特定のGadgetオブジェクトのCommunity-Gadgets固有のガジェット属性(JSON形式)。

packed_categories

VARCHAR(4000)

特定のGadgetオブジェクトに割り当てられたカテゴリの空白区切りリスト。

packed_preferences

VARCHAR(4000)

特定のGadgetオブジェクトの設定(JSON形式)。

gadget_iconid

BIGINT

ガジェットのアイコンが格納されているBLOBオブジェクトとの関係。

gadget_previewid

BIGINT

ガジェットのプレビューが格納されているBLOBオブジェクトとの関係。

gadget_thumbnailid

BIGINT

ガジェットのサムネイルが格納されているBLOBオブジェクトとの関係。

81.1.7.2 OpenSocialDescriptor

OpenSocialDescriptor表は、Gadgetsインタフェースでガジェットを登録する際に使用されるOpenSocialガジェットXML記述子を表します。

表81-14 cg_open_social_descriptor AssetTypeの構造

プロパティ

型

説明

id

BIGINT

OpenSocialDescriptorの識別子。

source_gadget_id

BIGINT

特定のOpenSocialガジェット記述子が関連付けられたGadgetオブジェクトとの関係。

site_id

BIGINT

記述子が作成されたサイトの名前。

gadget_links

VARCHAR(4000)

特定のOpenSocialガジェット記述子でのGadgetオブジェクトに対するリンクの非正規化されたリスト(JSON形式)。例: [{"siteId":"FirstSiteII", "gadgetId":1337101669171, "siteRegistry":false}, ...]。

packed_info

VARCHAR(4000)

ガジェット記述子の設定の非正規化されたリスト(JSON形式)。この設定は、ガジェットXML記述子から読み取られます。

81.1.7.3 SingleGadgetData

SingleGadgetData表は、個別にデプロイされたガジェットに対する、認可されたユーザーの設定を表します。

表81-15 cg_single_gadget_data AssetTypeの構造

プロパティ

型

説明

Id

BIGINT

SingleGadgetDataの識別子。

gadget_id

BIGINT

特定のデータが関連付けられたGadgetオブジェクトとの関係。

user_id

BIGINT

特定のデータが関連付けられたUserオブジェクトとの関係。

resource_id

BIGINT

ガジェットの識別子。これは、Community-Gadgetsが、訪問者がコメントを投稿したページとデプロイされたガジェットを関連付けるために使用する論理リンクです。このリンクは、ウィジェットのデプロイ時に、デプロイメント・ページの「リソースID」フィールドの値、またはウィジェット・コード・スニペット内のresource_id属性を指定することによって確立されます。resource_id生成の独自の戦略を立てることをお薦めします。たとえば、データベース内でこのオブジェクトをより簡単に検索できるようにするため、ページIDをリソースIDとして使用できます。

data_value

VARCHAR(4000)

ガジェット記述子の設定の非正規化されたリスト(JSON形式)。この設定は、ガジェットXML記述子から読み取られます。

81.1.7.4 GadgetSet

GadgetSet表は、ダッシュボードの設定を表します。

表81-16 ダッシュボードのプロパティ

プロパティ

型

説明

id

BIGINT

GadgetSetの識別子。

user_id

BIGINT

特定のGadgetSetが関連付けられたUserオブジェクトとの関係。

packed_type

VARCHAR(256)

GadgetSetPossibleの値のタイプ:

- user_dash: 末端のユーザーのダッシュボード

- site_dash: 管理サイドのユーザーのダッシュボード

packed_ui_settings

VARCHAR(4000)

URLパラメータとして格納されるダッシュボード・インタフェースの設定。

81.2 CSSおよびウィジェット・テンプレートのカスタマイズ

Communityウィジェットは、次の方法でカスタマイズできます。

- CSSを通じたカラー・スキーマとスキニング。ウィジェットがデプロイされるWebサイトにウィジェットのルック・アンド・フィールをマッチさせる必要がある場合、CSSをカスタマイズします。

- ウィジェット・テンプレートを通じた再設計。新しいレイアウトや機能拡張など、ウィジェットを大きく変更する必要がある場合は、ウィジェット・テンプレートをカスタマイズします。

次の項で、これらのカスタマイズを実行する方法について説明します。

- 第81.2.1項「CSSのカスタマイズ: カラー・スキーマとスキニング」

- 第81.2.2項「ウィジェット・テンプレートのカスタマイズ」

81.2.1 CSSのカスタマイズ: カラー・スキーマとスキニング

CSSをカスタマイズする一般的な手順は次のとおりです。

1. ウィジェットの標準のCSSスキンをダウンロードします。

2. カスタマイズが必要なインタフェース・エレメントのCSSスタイルを変更します。

3. カスタマイズしたCSSを適用します。

全体的なプロセスは同じですが、「コメント」ウィジェットおよび「レビュー」ウィジェットのCSSスタイルのカスタマイズは、他のウィジェットのカスタマイズとは異なります。

この項は、次のトピックで構成されています。

- 第81.2.1.1項「「コメント」ウィジェットおよび「レビュー」ウィジェットのカスタマイズ」

- 第81.2.1.2項「他のウィジェットのカスタマイズ」

81.2.1.1 「コメント」ウィジェットおよび「レビュー」ウィジェットのカスタマイズ

「コメント」および「レビュー」の場合、Communityインタフェースのウィジェットの「外観」ページからデフォルトのCSSをダウンロードし、それを変更してアップロードしなおします。Community-Gadgetsは、CSSがカスタマイズされている間もそのCSSをホストし続けるので、いつでも好きなときにCSSを変更できます。

CommentsのCSSをカスタマイズするには:

1. Communityインタフェースに管理者としてログインします。

2. 「コメント」メニューから「構成」→「外観」を選択し、「コメントの外観」ページを表示します。

3. 「一般」セクションで、「カスタムCSSのアップロード」フィールドの隣にある「現在のCSSのダウンロード」をクリックします。

図81-2 現在のCSSのダウンロード

4. ダウンロードしたCSSを編集するためにFireFoxで開きます。

5. 「表示」メニューから「Firebug」を選択します。

6. FireBugメニューから「要素を調査」を選択します。CSSが図81-3のように表示されます。

図81-3 FireBugで開かれたCSS

7. Commentsコード全体を含むDIVエレメントには、wsdk-records-recordクラスが含まれます。このクラスを検索するには、以前にダウンロードしたデフォルトのCSSで次を見つけます。

.wsdk-records .wsdk-records-record
{
border-top: 1px dashed #666;
clear: both;
overflow: hidden;
margin: 5px 0px;
}
Now, let's apply some customizations, for example change the default text
color and size, and border:
.wsdk-records .wsdk-records-record
{
border-top: 2px solid orange;
color: #359AD3;
font-size:15px;
clear: both;
overflow: hidden;
margin: 10px 0px;
}
We can also find that background color is defined in the next div inside this
container div, marked with CSS class "wsdk-state-default". Let's also define
a custom background color:
.wsdk-state-default
{
background: silver;
}

8. 必要に応じてwsdk-records-recordクラスをカスタマイズし(図81-4)、変更内容を保存します。

図81-4 変更されたCSS

9. カスタマイズしたCSSをアップロードするために、Communityインタフェースに戻ります。

10. 「コメント」メニューから「構成」→「外観」を選択し、「コメントの外観」ページを表示します。

11. 「一般」セクションで、スキンをデフォルトからカスタムに変更し、「カスタムCSSのアップロード」フィールドの隣にある「参照」をクリックして、カスタマイズしたCSSファイルを選択します。

12. 「保存」をクリックします。

13. Webページをリフレッシュしてウィジェットをリフレッシュし、CSSに加えた変更がウィジェットのインタフェースに反映されるかどうかを確認します。

「レビュー」ウィジェットのCSSをカスタマイズするには、「レビュー」に移動し、「構成」→「外観」を選択します。次に、前述の手順を実行します(手順3から手順12)。

81.2.1.2 他のウィジェットのカスタマイズ

「コメント」と「レビュー」以外のウィジェットをカスタマイズするには、この項で説明する一般的なアプローチを使用できます。状況によっては、ここで説明するアプローチを使用して「コメント」ウィジェットや「レビュー」ウィジェットをカスタマイズすることもできます。

この項で説明するアプローチと、「コメント」ウィジェットや「レビュー」ウィジェットで説明した内容の主な違いは、他のウィジェット用のカスタマイズされたCSSは、Community-Gadgets Webアプリケーションでホストされなくなるという点です。通常、カスタマイズされたCSSは、コメントがデプロイされるWebサイトでホストされます。

次の手順を実行して、レビュー機能のアドオンである「上位ランクのトピック」ウィジェットをカスタマイズします。

- ページ・テンプレートへのデプロイメント・タグとCSSタグのコピー

- CSSのカスタマイズ

ページ・テンプレートへのデプロイメント・タグとCSSタグのコピー

1. Community-Gadgetsに管理者としてログインします。

2. 「レビュー」メニューから、「デプロイ」→「上位ランクのトピック」を選択します。
「上位ランクのレビューのデプロイメント」フォームが表示されます(図81-5)。

図81-5 上位ランクのレビューのデプロイメント

3. 「リソース・タイプ」、「評価」、「トピック数」および「次以降を含む」の各フィールドに必要な情報を入力します。「次以降を含む」フィールドを選択すると、最初の日付を選択するためのカレンダが表示されます。

4. 「タグ」フィールドと「CSSタグ」フィールドの内容をコピーし、Webページ・テンプレートに貼り付けます。CSSは、前述のフィールドに追加された情報に基づいて更新されます。「タグ」フィールドの内容をテンプレートの<body>セクションに挿入します。「CSSタグ」フィールドの内容をページ・テンプレートの<head>セクションに挿入します。

5. コード・スニペットをデプロイします。
ページがレンダリングされると、上位ランクのトピックのデフォルトのルック・アンド・フィールは図81-6のようになります。

図81-6 テンプレート内にタグが挿入された後の上位ランクのトピック

CSSのカスタマイズ

最初に、デプロイした「CSSタグ」フィールドの内容に含まれているID属性およびHREF属性を確認します。ID属性の値は、カスタマイズ時に変更しないようにする必要があります。この項の手順で示すとおり、HREFの値は変更します。

<link
id="cos_css"
type="text/css"
rel="stylesheet" href="http://localhost:8280/cg/wsdk/skin/wsdk.topics.css?site_id=FirstSiteII&gateway=true"
/>

CSSをカスタマイズする前に、インターネット・ブラウザでHREFの場所にアクセスし、そのコンテンツをダウンロードします。

1. ダウンロードされたCSSの中で、トピック・リンクのCSSクラスを見つけます。ウィジェットの構造を調べます。

2. トピックのヘッドラインとトピックのリンクの色をカスタマイズするには、それぞれのコード・スニペットを見つけます。.fw_topics .headlineおよび.fw_topics .topicを検索します。Webサイトの設計仕様に基づいて、次のコードを変更します。

.fw_topics .headline h1 {
color: #359AD3;
font-size: 16px;
}
.fw_topics .topic {
font-size: 14px;
padding: 5px;
font-weight: bold;
text-decoration: none;
}
.fw_topics .topic a {
color: orange;
font-size: 12px;
text-decoration: none;
}

3. CSSをWebサイトに適用するには:

1. Webサイトのスタイルが格納されているフォルダにCSSをコピーします。

2. 以前にページ・テンプレートにコピーしたCSSの中で、デフォルトの場所を、カスタマイズしたCSSにアクセス可能な新しいURLに置き換えます。たとえば、CSSをskinsフォルダにコピーした場合は、HREFエレメントは次のようになります。

<link
id="cos_css"
type="text/css"
rel="stylesheet" href="http://localhost:8180/cs/skins/wsdk.topics.css"
/>

注意:

Community-Gadgets Webアプリケーションはウィジェットをロードするときに、cos_css IDを持つ<link>エレメントのページを検索するため、ID属性はcos_cssに等しいままにしておく必要があります。このIDが存在する場合は、アプリケーションは継続してウィジェットをレンダリングします。このIDが存在しない場合、アプリケーションはデフォルトのCSSスキンを求める明示的なリクエストを作成し、それをページに適用します。そのため、cos_cssをID属性値として使用すると、Community-Gadgetsが適用済のカスタマイズを上書きするのを回避できます。

4. 変更したばかりのCSSを含むウィジェットを使用しているページを再ロードし、カスタマイズが適用されていることを確認します(図81-7)。

図81-7 ウィジェットに適用されたカスタマイズ

ヒント:

同じページに複数のCommunityウィジェットをデプロイする場合、すべてのウィジェットのCSSファイルを1回のネットワーク・コールでロードすることによって、ネットワーク・コールの回数を最適化してください。Community-Gadgetsでは、<link/>タグ内にウィジェット名のコロン区切りリストを指定することで、このオプションがサポートされます。つまり、ウィジェット名を個別の<link/>エレメントに入れる必要はありません。例:

<link
id="cos_css"
type="text/css"
rel="stylesheet" href=" http://localhost:8280/cg/wsdk/skin/<widget name #1>:<widget name #2>:<widget name #3>.css?site_id=FirstSiteII&gateway=true "
/>

ウィジェット名の例は、wsdk.topicsおよびcomments-summaryです。特定のウィジェットの実際の値は、対応するデプロイメント・ページの「CSSタグ」フィールドで確認できます。

81.2.2 ウィジェット・テンプレートのカスタマイズ

大きな変更(「コメント」ウィジェットのアクションのリンクを、そのウィジェットの下部から上部に変更するなど)を行う場合は、プロジェクトの要件に応じてウィジェット・テンプレートをカスタマイズできます。

ウィジェット・テンプレートは、ブラウザ側でJavaScriptを使用して動的にレンダリングされます。これらのテンプレートは、Google Closure Templatesテクノロジに基づいています。

カスタマイズで利用可能な一連のテンプレート・ディレクティブが用意されています。詳細は、GoogleドキュメントのWebサイト(http://code.google.com/closure/templates/docs/commands.html)を参照してください。

この項で説明されている情報を適用する前に、Googleドキュメントのprint、if/else、forおよびforeachの各文の説明を必ず読み、内容を理解しておいてください。

この項は、次のトピックで構成されています。

- 第81.2.2.1項「Communityウィジェットのテンプレートの理解」

- 第81.2.2.2項「サンプル・テンプレートの作成」

- 第81.2.2.3項「カスタム・データ・セットのロード」

81.2.2.1 Communityウィジェットのテンプレートの理解

この項では、ウィジェット・テンプレート・テクノロジと構文について説明します。Community-Gadgetsテンプレート内で宣言されたテンプレートを対応するWebCenter Sitesテンプレート名に変換することで、どのようにアタッチ・ポイントをオーバーライドできるかを説明します。この項では、Community-Gadgetsでのカスタマイズに使用できるアタッチ・ポイントについて説明し、さらに、テンプレートのカスタマイズ時にウィジェット構造をナビゲートして必要なアタッチ・ポイントを見つける方法を説明します。

この項は、次のトピックで構成されています。

- 第81.2.2.1.1項「コンテキスト変数のアクセス・ポイント」

- 第81.2.2.1.2項「動的スクリプティング」

- 第81.2.2.1.3項「ウィジェットのソースとテンプレート」

- 第81.2.2.1.4項「Model-View-Controllerパターン」

- 第81.2.2.1.5項「Model-View-Controllerのリージョン」

- 第81.2.2.1.6項「ネストされたテンプレート」

- 第81.2.2.1.7項「カスタマイズのワークフロー」

- 第81.2.2.1.8項「ウィジェット・テンプレート構造におけるアタッチ・ポイント」

81.2.2.1.1 コンテキスト変数のアクセス・ポイント

テンプレートを変更する場合、開発者は訪問者の権限(Communityインタフェースで構成)および変数を扱う必要があります。Community-Gadgetsの各テンプレートには標準の$stack変数が含まれており、これらのコンテキスト変数や権限を見つけるのに利用できます。たとえば、次のタグを使用して、ローカライズ可能なリソースをテンプレートに挿入できます。

<h1>Welcome to {$stack.resources.get('label.comments')} Widget </h1>

$stack.resources変数は、cg.war/WEB-INF/classes/i18n_resources/widgets/cos.commonsおよびcg.war/WEB-INF/classes/i18n_resources/widgets/<widget name>で宣言されているすべてのリソースのアクセス・ポイントです。

81.2.2.1.2 動的スクリプティング

JavaScriptの{script}ディレクティブを使用して、テンプレート内に動的なロジックを構築できます。

{script}
var lastIndex = 10;
{/script}

{script}の中で定義した変数は、$$マークを使用することで他のクロージャ・ディレクティブ内でも利用可能です。たとえば、$$lastIndexがあります。

{for $index in range($$lastIndex)}
For loop: Iteration #{$index + 1} of {$$lastIndex} in total
<br />
{/for}

Googleのクロージャ・テンプレートの変数を{script}タグ内でアクセスする必要があるシナリオでは、通常の{$var}構文を使用できます。

{for $index in range(2)}
{script}
alert({$index});
{/script}
{/for}

{script}内で生成されたデータは、次の方法でWebページに表示できます。

- {script}タグを閉じ、以前に宣言したデータを{$$variable}}構文を使用して出力する。

- Community-Gadgetsが提供するシステム出力変数を使用し、{script}文内でoutput.append(variable)を使用してJavaScriptから直接結果を出力する。

{script}
var message= "Hello World!";
output.append(message);
{/script}

81.2.2.1.3 ウィジェットのソースとテンプレート

cg.war/js/widgetsディレクトリには、Community-Gadgets Webアプリケーションに同梱されているウィジェット・ソースのリストがあります。たとえば、Comments-Gadgetsウィジェットのコードは、cg.war/js/widgets/wsdk.commentsディレクトリに格納されています。それぞれのウィジェットのディレクトリには、.shtmlファイル、ウィジェット・レイアウト定義およびウィジェット・インタフェースのレンダリング・プロセスのメイン・エントリ・ポイントが含まれています。たとえば、comments_layout_view.shtmlファイルは、「コメント」ウィジェットのメイン・エントリ・ポイントです。

81.2.2.1.4 Model-View-Controllerパターン

ウィジェットのインタフェースを構築するために、Community-GadgetsではModel-View-Controller (MVC)パターンを使用します。したがって、それぞれのインタフェースのリージョンには、Model、ViewおよびControllerに対応する3つのアイテムが含まれています。例:

comments_layout_action.js (Controller)
comments_layout_model.js (Model)
comments_layout_view.shtml (View)

81.2.2.1.5 Model-View-Controllerのリージョン

ウィジェットのインタフェースを構築するために、Community-Gadgetsではテンプレート(.shtml)の定義ではなく、MVCの定義を扱います。

たとえば、CommentsのレイアウトのMVCリージョンは、cg.war/js/widgets/<WidgetName>/...ディレクトリ内の/comments_layoutのIDによって特定できます。特殊文字の/は、ウィジェット・フォルダの相対パスを表します。対応する他のMVCエンティティを参照および検出するには、comments_layout MVC接頭辞と、_view.shtml (viewには、バインディング付きのHTMLページが含まれる)などの接尾辞を組み合せて使用します。したがって、特定のインタフェース・リージョンのMVC定義は、そのウィジェット・フォルダ内の相対パス、および特定のモデル、ビューまたはコントローラの検出に使用されるMVCエンティティの接頭辞によって特定されます。

これらのMVC IDはテンプレート全体で頻繁に使用されるため、これらのMVC IDの理解は、ウィジェットのインタフェースを構築する上で不可欠な要素です。

81.2.2.1.6 ネストされたテンプレート

MVCのエンティティが処理され、そのテンプレートがレンダリングされるときに、別のMVCエンティティをテンプレート内に再帰的に含めることができます。これにより、小さなインタフェースの部品を組み合せながら複雑なインタフェースを構築できます。

テンプレートのネストを可能にするには、他のテンプレートをネストするテンプレートに次のタグを追加します。たとえば、「レビュー」ウィジェットの中に「ログイン・バー」ウィジェットをネストできます。

<div attachPoint="/sample"></div>

テンプレートにこのタグを含めると、Community-Gadgetsはウィジェットのルート・フォルダcg.war/js/widgets/<WidgetName>/から、sample_action.jsおよびsample_view.shtmlを検索します。

attachPoint=""構文以外に、bindMvc=""ディレクティブには、ネストされたテンプレート(たとえば、bindMvc="wsdk.ui.input")も含まれます。ただし、このディレクティブは特定のウィジェット・フォルダ階層の外部にあるテンプレートをコールするため、現在のウィジェット・フォルダ階層のテンプレートは含みません。これにより、Community-Gadgets内の複数のウィジェット間でコンポーネントを再利用できます。

81.2.2.1.7 カスタマイズのワークフロー

前の項では、アタッチ・ポイントを使用してテンプレートをネストする方法について説明しました。この項では、テンプレートを通じてアタッチ・ポイントをカスタマイズまたはオーバーライドする方法について説明します。

Community-GadgetsがウィジェットのJavaScriptバンドルをコンパイルする場合は、WebCenter Sitesから、WebCenter Sitesテンプレートとして定義された任意のウィジェット・テンプレート・カスタマイズをダウンロードし、それらをJavaScriptにコンパイルして、ウィジェットに適用します。Community-GadgetsとWebCenter Sites間の対応付けを作成できるテンプレート名の規定は、http://{host}:{port}/cs/ContentServer?pagename={site name}/cg/{widget}/{attach point}_view.shtml&ft_ss=trueで指定されます。また、Community-Gadgetsで特定のテンプレートが検出可能になります。

(/sampleテンプレートなどの)テンプレートをカスタマイズするには、最初に、Community-Gadgetsが構成された本番のWebCenter Sitesシステム上でWebCenter Sitesテンプレート・アセットを作成する必要があります。

アタッチ・ポイントをWebCenter Sitesのテンプレート名に変換するには、次のフォーマットを使用します。

http://{host}:{port}/cs/ContentServer
?pagename={site name}/cg/{widget}/{attach point}_view.shtml
&ft_ss=true

たとえば、「hello-world」ウィジェットのいずれかのテンプレートの中にattachPoint="/sample"というアタッチ・ポイントがある場合、次のようなWebCenter Sitesに対するHTTPリクエストに変換されます。

http://{host}:{port}/cs/ContentServer
?pagename={site name}/cg/hello-world/sample_view.shtml
&ft_ss=true

カスタムのCommunity-Gadgetsテンプレートの場合は、cos/hello-world/sample_view.shtmlというWebCenter Sitesのネーミング規則に従って、WebCenter Sites内に対応するテンプレートを作成する必要があります。

bindMvcは、事前定義されたアタッチ・ポイントのセットであり、ネストされたテンプレートで使用できます。表81-3には、作成したテンプレート内でbindMvc=""属性構文を使用してネストできる、テンプレートのリストが記載されています。再利用可能なウィジェット・コードが格納されているcg.war/js/widgets.commonsディレクトリの対応するサブディレクトリ内に、デフォルトのテンプレートがあります。

コンポーネントをオーバーライドするには、マッピング(表81-17)を使用してMVCの名前を、WebCenter Sites内で作成するテンプレートの名前にバインドします。

表81-17 MVCの名前をテンプレートの名前にバインドするためのマッピング

バインドされるMVC

オーバーライドするテンプレートの名前

wsdk.ui.stars

cg/wsdk.ui.stars/stars_view.shtml

wsdk.ui.thumbs

cg/wsdk.ui.thumbs/thumbs_view.shtml

wsdk.ui.input

cg/wsdk.ui.input/input_view.shtml

wsdk.ui.textarea

cg/wsdk.ui.textarea/textarea_view.shtml

wsdk.ui.pagination

cg/wsdk.ui.pagination/pagination_view.shtml

wsdk.ui.session

cg/wsdk.ui.session/session_view.shtml

81.2.2.1.8 ウィジェット・テンプレート構造におけるアタッチ・ポイント

Communityウィジェットのインタフェースと機能は、特定の方法で構造化されたテンプレートを利用して構築されます。図81-8は、「コメント」ウィジェットの構造を示しています。カスタマイズの際は、この構造をナビゲーション・マップとして利用できます。

図81-8 「コメント」ウィジェットの構造

訪問者のアクションに応じて動的に呼び出されレンダリングされるアタッチ・ポイントは、テンプレート内で直接参照されることはありません。たとえば、訪問者がコメントの「編集」または「削除」のリンクをクリックすると呼び出されるアタッチ・ポイントがあります。これらのイベントのダイアログ・ボックスは、ウィジェットの初期ロード・フェーズではレンダリングできず、後でプログラムでロードされます。

そのような動的なダイアログ・ボックスのアタッチ・ポイントの例をいくつか示します。

- 訪問者がコメントの「削除」リンクをクリックすると、「削除」ダイアログ・ボックス(図81-9)が表示されます。

図81-9 「削除」ダイアログ・ボックス

- コメントにフラグが付けられると、「コンテンツのフラグ付け」ダイアログ・ボックス(図81-10)が表示されます。

図81-10 「コンテンツのフラグ付け」ダイアログ・ボックス

「レビュー」ウィジェットのテンプレートとアタッチ・ポイントの構造を、図81-11に示します。レビューへのフラグ設定、レビューの編集および削除のアタッチ・ポイントはコメントの場合と同じであり、それぞれ/record_list/record/flag/flag、/record_list/record/edit/formおよび/record_list/record/remove/removeになります。

図81-11 「レビューの投稿」ページ

コメントやレビューの投稿フォームには、「プレビュー」ボタンが含まれています。このボタンをクリックすると、コンテキスト・メニューとともにレンダリングされたコメントまたはプレビュー(図81-12)が表示されます。

図81-12 「プレビュー」ポップアップ・ダイアログ・ボックス

コメントおよびレビューのいずれでも、/record_list/record/preview/previewというアタッチ・ポイントによってこのポップアップ機能が作成されます。

ヒント:

Community-Gadgets Webアプリケーションは、本番のWebCenter Sitesのインスタンスから、カスタマイズされたテンプレートをロードします。ただし、本番のインスタンスには、これらのテンプレートを管理するための編集用のインタフェースがない場合があります。したがって、最初は開発環境からスタートし、本番用および管理用のCommunity-Gadgetsサーバー・インスタンスから、編集用のインタフェースを備えたWebCenter Sitesの単一インスタンスをポイントすることをお薦めします。このアプローチを使用すると、テンプレートを作成して、Community-Gadgets内でルック・アンド・フィールを確認できます。テンプレートを作成してテストしたら、それらを開発環境からエクスポートして本番環境にインポートしたり、カスタム・テンプレートを目的の場所にパブリッシュすることができます。

81.2.2.2 サンプル・テンプレートの作成

WebCenter SitesのAdvancedインタフェースを使用してサンプル・テンプレートを作成するには:

1. 本番環境および管理環境のものを含め、すべてのCommunity-Gadgetsサーバーを停止します。

2. 本番環境のWebCenter Sitesインスタンスを起動します。
以降の手順では、サーバーはローカル・ホストのポート8080で実行されていると想定します。

3. http://localhost:8080/cs/loginにアクセスしてWebCenter Sitesにログインし、テンプレートのカスタマイズが必要なサイトを選択します。

4. そのサイトのAdvancedインタフェース・アプリケーションを起動します。

5. カスタマイズ可能なテンプレートを作成するには、「新規」をクリックします。

図81-13 WebCenter SitesのAdvancedインタフェース: 「新規」

6. 右側の表で、「テンプレート」の隣にある「新規テンプレート」リンクをクリックします。

図81-14 「新規テンプレート」リンク

7. 「割当て先」を任意の値に設定します(この値はここでは適切でないため)。「続行」をクリックします。

8. 「名前」フィールドに、オーバーライドされるアタッチ・ポイントをcg/{widget}/{attach point}_view.shtmlの形式で指定します。

9. 「対象アセット・タイプ」フィールドで「様々なアセット・タイプに適用可能」を選択し、「続行」をクリックします。

10. 「使用」フィールドで、「エレメントはHTMLページ全体を定義するため、外部から呼び出すことができます。」を選択します。

11. 「テンプレート・エレメントを作成しますか。」フィールドで、「JSP」をクリックします。

12. 「エレメント・ロジック」フィールドで、終了タグ</cs:ftcs>の直前にテンプレート・コンテンツを入力します。テンプレート・コンテンツには、次の文、およびCommunity-Gadgets内にキャッシュされたテンプレートを無効にするための必須エレメントを含める必要があります。

<%-- 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>

13. テンプレートのコンテンツについては、Community-Gadgetsのファイル・システムに移動し、cg.war/js/widgets/{widget}/{attach point}_view.shtmlにあるデフォルトのコンテンツをコピーします。

14. 「続行」をクリックします。

15. 「サイト・エントリ」ページで、「保存」をクリックします。

16. 新しく作成したテンプレートがHTTPを通じてCommunity-Gadgetsで利用できることを確認するには、ブラウザに次の形式でテンプレートのURLを入力します。

http://{host}:{port}/cs/ContentServer?pagename={site}/cg{attach point}_view.shtml&ft_ss=true

17. Community-Gadgetsサーバーを起動し、デプロイされているウィジェットにカスタマイズ内容が適用されていることを確認します。

81.2.2.3 カスタム・データ・セットのロード

シナリオによっては、既存のテンプレート内のカスタマイズされたプロジェクト固有のデータをロードする必要があります。これを行うには、Community-Gadgetsに対してデータをRESTサービスとして公開します(JSONP形式)。

RESTサービスを作成したら、システム・ローダー変数を使用してテンプレートからそのサービスを呼び出します。テンプレートがレンダリングされる前にカスタム・データがロードされるようにするには、ページの先頭の{script.preload}セクションにこの起動を含める必要があります。

{script.preload}
loader.loadData(url, params, key);
{/script.preload}

- url: データを提供するJSONPエンドポイントのURLアドレス。

- params: 問合せをパラメータ化する必要がある場合に、JSONPエンドポイントに対してGETのパラメータとして渡されるパラメータ。

- key: この変数には返された結果セットとデータが格納され、$stack.keyでアクセスできます。

1. 例として、JSONP RESTサービス・エンドポイントとして使用するdata.jspファイルを作成します。このファイルには次のコンテンツを含めます。

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"    pageEncoding="ISO-8859-1"%>
<%
out.write(request.getParameter("cosrestcallback"));
%>({ responseCode : "OK", data : ["foo","bar"]});

この例では、応答はJSON形式で提供され、そこにはレスポンス・コードとデータ配列によるサンプル・データが格納されます。JSONのレスポンスは、Community-Gadgetsで使用されるJSONPプロトコルに従って、コールバックの名前によってラップされます。

2. data.jspファイルを、Community-Gadgetsのwebappフォルダにデプロイします。

3. Community-Gadgetsにはサンプル・ウィジェットが用意されており、ウィジェット・テクノロジを試すためのサンドボックスとして利用できます。そのソースは、cg.war/js/widget/sample.widgetコード内にあります。cg/sample.widget/layout_view.shtmlという名前のWebCenter Sitesのカスタム・テンプレートを作成するには、第81.2.2.2項「サンプル・テンプレートの作成」で説明している手順に従います。

4. カスタマイズされたテンプレート内のscript.preloadセクションで指定されたデータをダウンロードし、それをページに出力します。

5. Community-GadgetsのURLを自分の場所に置き換えます。
図81-1は、ロードされた後のサンプル・データ・コードを示しています。

例81-1 ロードされたサンプル・データ

<%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"
%><%@ taglib prefix="asset" uri="futuretense_cs/asset.tld"
%><%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"
%><%@ taglib prefix="commercecontext" uri="futuretense_cs/commercecontext.tld"
%><%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"
%><%@ taglib prefix="listobject" uri="futuretense_cs/listobject.tld"
%><%@ taglib prefix="render" uri="futuretense_cs/render.tld"
%><%@ taglib prefix="siteplan" uri="futuretense_cs/siteplan.tld"
%><%@ taglib prefix="searchstate" uri="futuretense_cs/searchstate.tld"
%><%@ page import="COM.FutureTense.Interfaces.*,
COM.FutureTense.Util.ftMessage,
COM.FutureTense.Util.ftErrors"
%><cs:ftcs><%-- /cos/sample.widget/layout_view.shtml
--%>
<%-- 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>
{script.preload}
loader.loadData("http://localhost:8280/cg/data.jsp",{}, "customData");
{/script.preload}
<div>
<h1>Welcome to Sample Widget. Data Load Demo</h1>
<br />
Data loaded with response code = "{$stack.customData.responseCode}  "
<br />
Custom data loaded:&nbsp;&nbsp;
{script}
var data = {$stack.customData.data};
for(var dataIdx in data)
{
var item = data[dataIdx];
{/script}
{$$item},&nbsp;&nbsp;&nbsp;
{script}
}
{/script}
</cs:ftcs>

81.3 カスタム・ワード・フィルタの作成

Community-Gadgetsでは、CommunityウィジェットがデプロイされたWebサイトに訪問者がフィードバックを投稿できます。不適切な内容、スパムまたはなんらかの不正な情報がWebサイト上にパブリッシュされる事態を防ぐために、Community-Gadgetsには、コンテンツをフィルタリングするためのユーザー生成コンテンツ(UGC)フィルタリング・サブシステムが用意されています。

フィルタリング・システムのデフォルトの構成は、ワード・フィルタ・ファイル(制限付きワードのリスト)に依存します。このファイルは、Communityインタフェースで「設定」、「制限付きワード」の順に選択することでアップロードできます。制限付きワードのリストをアップロードし、Communityインタフェースで「設定」、「モデレート」の順に選択して自動モデレートを有効にすると、Community-Gadgetsは、訪問者が投稿したコンテンツが調べ、各ワードをリスト内のワードと比較します。投稿されたコメントまたはレビューに制限付きワードが含まれる場合は、「不適切」とマークされ、Webサイトで公開されません。

注意:

特殊文字を含む禁止ワードが「不適切」とマークされ、「承認済」とマークされないようにするには、例81-2に示されている構文を使用して、カスタム・ワード・フィルタを作成する必要があります。

デフォルトのコンテンツ・フィルタの動作をカスタマイズする必要が生じることがあります。たとえば、スパムの検出と防御のための統計的推測と高度な手法の機能を提供するサード・パーティ・ライブラリと統合するために、Community-Gadgetsはプラッガブル・ワード・フィルタ・モデルを備えています。これにより、カスタム・ワード・フィルタをゼロから作成できます。

カスタム・ワード・フィルタを作成するには、最初にワード・フィルタのロジックが含まれたJavaクラスを作成する必要があります。次に、このクラスをコンパイルし、JARファイルとしてアセンブルして、Community-Gadgetsのデプロイメントにプラグインできるようにします。

1. IDEで新規Javaプロジェクトを作成します。

2. プロジェクトのクラスパスに、com.fatwire.cos.moderation.filter.WordFilterインタフェースが格納されたJARライブラリを追加します。このライブラリのJARは、cg.war/WEB-INF/lib/cos-api-11.1.1.8.0.jarにあるCommunity-Gadgets Webアプリケーションからコピーできます。
例81-2に、WordFilterインタフェースを示します。

例81-2 新規Javaプロジェクト

package com.fatwire.cos.moderation.filter;
import java.util.Set;
/**
* The word filter interface that needs to be implemented
* when developing and plugging-in a custom word filter
* to Community-Gadgets Server.
* The content is assigned to "Inappropriate" category and isn't
* shown on web site once any of the filters registered in the system
* reports an abuse.
* @author e_shevchenko
*
* May 16, 2011
*/
public interface WordFilter
{
/**
* The filter method makes a decision whether content
* specified can be shown on web site or not
* @param text the content submitted by visitor
* @param profanityWords the list of prohibited words uploaded on
* "Moderation" page in the Community interface
* @return true if an abuse detected and false if content
* can be shown on web site
*/
boolean filter(StringBuffer text, Set<String> profanityWords);
}

3. プロジェクト内に新規Javaクラス(例: cos.demo.DemoFilter)を作成します。

4. このクラスが次のWordFilterインタフェースを実装することを宣言します。

package cos.demo;

import java.util.Set;
import com.fatwire.cos.moderation.filter.WordFilter;

public class DemoFilter
implements WordFilter
{
@Override
public boolean filter(StringBuffer text,
Set<String> profanityWords)
{
// Add filter logic here
return false;
}
}

5. filterメソッド本体にカスタムの実装を追加します。
filterメソッドは2つのパラメータをとります。1つは訪問者が送信したソース・テキストで、もう1つはCommunityインタフェースを通じてテキスト・ファイルとしてアップロードされた制限付きワードのリストです。要件に基づいて、既存の制限付きワードのリストを使用するか、またはサード・パーティの制限付きワードのデータベースを使用するかを選択できます。

次の例は、ユーザー生成コンテンツにdemoという単語が含まれているかどうかを確認する方法を示しています。

package cos.demo;
import java.util.Set;
import com.fatwire.cos.moderation.filter.WordFilter;
public class DemoFilter
implements WordFilter
{
@Override
public boolean filter(StringBuffer text, Set<String> profanityWords)
{
boolean result = false;
if(null != text )
{
result = text.toString().contains("demo");
}
return result;
}
}

6. フィルタ・クラスの内容を実装し、コンパイルします。

7. コンパイルしたクラスをfilter-demo.jarというJARファイルにパッケージ化します。

8. Community-Gadgets Webアプリケーションのクラス・ローダーがこのカスタム・フィルタを利用できるようにするには、管理環境と本番環境の両方のcg.war/WEB-INF/libディレクトリにfilter-demo.jarファイルをコピーします。

9. Community-Gadgets Webアプリケーションがカスタム・フィルタを検出できるようにするには、cg.war/WEB-INF/classesディレクトリにあるcos_word_filters.xml構成ファイルにこのフィルタをプラグインします。

<?xml version="1.0" encoding="UTF-8" ?>
<word-filters>
<word-filter
className="com.fatwire.cos.records.moderation.filter.DefaultWordFilter"
/>
</word-filters>

10. デフォルトのワード・フィルタを置き換えます。管理環境と本番環境の両方で、cos word filters.xmlファイルから既存の<word-filter/>エレメントを削除し、作成したクラスへの参照が含まれる新しいエレメントを追加します。新しいcos word filters.xmlファイルの内容は次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>
<word-filters>
<word-filter className="cos.demo.DemoFilter"/>
</word-filters>

11. 管理システムと本番システムの両方で、Community-Gadgetsサーバーを再起動します。

12. 自動ワード・フィルタリングを有効にするには、Communityインタフェースにアクセスし、「設定」→「モデレート」を選択し、「自動モデレート」セクションで「制限付きワードに対する自動モデレート」を選択します(図81-15)。

図81-15 制限付きワードに対する自動モデレート

13. Webサイトで、demoという単語を含んだコメントまたはレビューを投稿します。投稿が「不適切」カテゴリに割り当てられ、パブリッシュされないことを確認します。

81.4 CAPTCHAジェネレータの作成

CAPTCHAテクノロジは、Webサイトを攻撃する可能性のある自動スパム・システムのロボットを特定するのに役立ちます。Community-Gadgetsには、CAPTCHAのカスタム実装用のプラグイン・モデルが備わっています。

この項では、単純なCAPTCHAジェネレータを作成し、それをCommunity-Gadgetsにプラグインする方法について説明します。この手順は、カスタム・ワード・フィルタの作成手順と似ています。CAPTCHAジェネレータを作成するには、必要なインタフェースを実装する新しいクラスを作成し、このクラスをコンパイルしてJARファイルとしてパッケージ化し、Community-Gadgetsサーバーにデプロイします。

1. IDEで新規Javaプロジェクトdemo-captchaを作成します。

2. プロジェクトのクラスパスに、プロジェクト用のJARライブラリを追加します。必要なJARは、Community Webアプリケーションのディレクトリからコピーできます(cg.war/WEB-INF/lib/cos-api-11.1.1.8.0.jarにある)。

3. cos-api-11.1.1.8.0.jarファイルから、実装対象のインタフェースcom.fatwire.cos.captcha.CaptchaGeneratorを抽出します。例81-3に、このインタフェースの内容を示します。

例81-3 com.fatwire.cos.captcha.CaptchaGeneratorインタフェース

package com.fatwire.cos.captcha;
/**
* The interface that needs to be implemented when
* creating plug-in that generates CAPTCHA to be shown to
* visitors when UGC is submitted.
*
* It's a factory that generates complex Captcha objects that are managed
* by Community-Gadgets Server and utilized when CAPTCHA is rendered for visitors
* and when it's validated on content submission
*
* @author alex
*
* Oct 17, 2011
*/
public interface CaptchaGenerator
{
/**
* Factory method that creates a new captcha object
* that consists of challenge text
* and challenge image to shown to visitors
* @return
*/
public Captcha generate();
}

4. demo-captchaプロジェクト内に、cos.demo.DemoGeneratorという名前の新規Javaクラスを作成します(例81-4)。

例81-4 demo-captchaプロジェクト

package cos.demo;
import com.fatwire.cos.captcha.Captcha;
import com.fatwire.cos.captcha.CaptchaGenerator;
public class DemoGenerator
implements CaptchaGenerator
{
@Override
public Captcha generate()
{
// Add implementation
return null;
}
}

5. CaptchaGeneratorインタフェースを実装します。

6. 例81-5に示すように、generateメソッドを実装します。
最初にチャレンジ・テキストを生成してから、生成されたテキストを表示するイメージを作成します。テキストとイメージの準備が整ったら、CaptchaFactoryクラスを利用して、それらをCaptchaオブジェクトにパッケージします。Captchaオブジェクトのカスタム実装を作成するかわりに、このファクトリを使用することを強くお薦めします。これは、ファクトリによって構築されているCaptchaオブジェクトがすでにシリアライズ可能で、クラスタ・メンバー間で安全に共有できるからです。カスタム実装を作成することを選択した場合は、Captchaオブジェクトをシリアライズ可能にしてください。

例81-5 generateメソッド

package cos.demo;
import com.fatwire.cos.captcha.Captcha;
import com.fatwire.cos.captcha.CaptchaFactory;
import com.fatwire.cos.captcha.CaptchaGenerator;
public class DemoGenerator
implements CaptchaGenerator
{
@Override
public Captcha generate()
{
String challenge = "foo_bar";// Add generation
byte[] image = generateImage(challenge); // Generate image
return CaptchaFactory.create(challenge, image);
}
}

7. コンパイルしたクラスをcaptcha-demo.jarというJARファイルにパッケージ化します。

8. Community-Gadgetsのクラス・ローダーがこのジェネレータを利用できるようにするには、管理環境と本番環境の両方のcg.war/WEB-INF/libディレクトリにcaptcha-demo.jarファイルをコピーします。

9. Community-Gadgetsがジェネレータを検出できるようにするには、ジェネレータを構成ファイルにプラグインします。cg.war/WEB-INF/classesディレクトリ内に、次の内容のcos_captcha.xmlファイルを作成します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<captcha-generator className="cos.demo.DemoGenerator"/>

10. 管理システムと本番システムの両方で、Community-Gadgetsサーバーを再起動します。

11. コメントでCAPTCHAを有効にするには、Communityインタフェースにアクセスし、「コメント」→「構成」→「権限」を選択し、「コメントできるユーザー」セクションで「ユーザーは検証コードを入力する必要がある」を選択します(図81-16)。

図81-16 CAPTCHAの有効化

12. 前述の手順を繰り返して、レビューでもCAPTCHAを有効にします。

13. 「コメント」ウィジェットまたは「レビュー」ウィジェットを、ログイン・バーのサポートありでデプロイします。

14. CAPTCHAチャレンジのフィールドが表示され、CAPTCHAの画像がレンダリングされることを確認するには、Webサイトの「登録」リンクをクリックします。また、コメントまたはレビューをゲストとして投稿してみます。フォーム内にCAPTCHAが表示されます。

81.5 ダッシュボード・テーマのカスタマイズ

管理者はCSSファイルを使用して、ダッシュボード内の既存のテーマを変更できます。

ダッシュボード・テーマをカスタマイズするには:

1. Gadgetsインタフェースを開きます。

2. 「設定」メニューから「外観設定」を選択します(図81-17)。

図81-17 Gadgetsインタフェース - 「外観設定」ページ

3. 「外観設定」ページの「一般」セクションで、「カスタムCSSのアップロード」フィールドの隣にある「現在のCSSのダウンロード」リンクをクリックし、gadgets_dashboard.cssファイルを自分のコンピュータに保存します。

4. このダウンロードしたCSSファイル内のダッシュボード・テーマのCSSスタイルを変更します。たとえば、Blueテーマを変更するには、次の行を見つけ、必要に応じてそれらを変更します。
共通のダッシュボード背景色:

.gas.gas_blue{
background-color: #d7e9f2;
}

ガジェットのヘッダーの左、右およびコンテンツの画像:

.gas.gas_blue .gas_gadgetHeader_left {
background-image: url(../../admin-gadgets/images/BlueLeftTop.png);
}

.gas.gas_blue .gas_gadgetHeader_right {
background-image: url(../../admin-gadgets/images/BlueTopRight.png);
}

.gas.gas_blue .gas_gadgetHeader {
background-image: url(../../admin-gadgets/images/BlueStrip.png);
}

ガジェットのヘッダーのアクションの背景:

.gas.gas_blue .gas_gadgetActions {
background-image: url(../../admin-gadgets/images/BlueStrip.png);
}

ガジェットのヘッダーのアクション・ボタン:

.gas.gas_blue .gas_gadgetHeader_content a.gas_close {
background-image: url(../../admin-gadgets/images/BlueDeleteOff.png);
}

.gas.gas_blue .gas_gadgetHeader_content a.gas_expand {
background-image: url(../../admin-gadgets/images/BlueWSOpenOff.png);
}

.gas.gas_blue .gas_gadgetHeader_content a.gas_collapse {
background-image: url(../../admin-gadgets/images/BlueWSCollapsedOff.png);
}
User toolbar collors (gadget settings)

.gas.gas_blue .gas_UserPrefs_content {
background-color: #d7e9f2;
color: #ffffff;
}

パネル・テーマのアイコン:

.gas .gas_setup .gas_setupIcon_theme_blue {
background-image: url(../../admin-gadgets/images/gasThemeBlue.png);
}

* html .gas .gas_setup .gas_setupIcon_theme_blue {
background-image: url(../../admin-gadgets/images/gasThemeBlue.gif);
}

5. 変更したファイルを保存します。

6. 「スキン」ドロップダウン・リストから「カスタム」を選択します。
これにより、カスタマイズしたgadgets_dashboard.cssファイルをアップロードするためのフィールドが有効になります(図81-17を参照)。

7. 「カスタムCSSのアップロード」フィールドの隣にある「参照」をクリックします。

8. 「ファイルのアップロード」ダイアログ・ボックスで、変更したgadgets_dashboard.cssファイルを選択し、「開く」をクリックします。

9. 「外観設定」ページで、「保存」をクリックします。

81.6 Community-Gadgetsのイベント処理

Community-Gadgetsでは、すべてのイベントはCoSEventクラスから継承されます。顧客監視で使用されるイベントの例として、CommentEvent、ReviewEvent、RatingEventおよびExternalAuthEventがあります。

すべてのイベントには、メジャー・タイプとマイナー・タイプがあります。これらのタイプはイベントを特定するのに役立ちます。メジャー・タイプは、各イベントが属するシステムの部分を表します。これは、CoSEventMajorTypeによって表されます。可能な値は、ALL、COMMENT、REVIEWおよびRATINGです。ALLは、すべての可能なメジャー・タイプを指します。

イベント・マイナー・タイプは実行されたアクションを示し、CoSEventMinorTypeでイベントが表示されます。指定可能な値は、ALL、CREATED、MODIFIED、DELETEDおよびREPORTEDです。REPORTEDは、コメントおよびレビューにフラグが付くと表示されます。ALLは、すべての可能なマイナー・タイプを指しています。

イベントは、リスナーによって処理されます。すべてのリスナーは、CoSEventListenerクラスから継承されます。リスナーは、どのイベント(たとえば、CommentEventまたはReviewEvent)を処理するかを知っている必要があります。

この項の内容は、次のとおりです。

- 第81.6.1項「イベントのエンティティ」

- 第81.6.2項「イベントのリスナー」

81.6.1 イベントのエンティティ

すべてのイベント・エンティティの親クラスはCoSEventです。完全なクラス名は、com.fatwire.cos.events.CoSEventです。このクラスは、cg.war/WEB-INF/libs/cos-api-11.1.1.8.0.jarライブラリにあります。

この項の内容は、次のとおりです。

- 第81.6.1.1項「CommentEventエンティティ」

- 第81.6.1.2項「ReviewEventエンティティ」

- 第81.6.1.3項「RatingEventエンティティ」

- 第81.6.1.4項「ExternalAuthEventエンティティ」

81.6.1.1 CommentEventエンティティ

CommunityEventエンティティは、コメントの作成、変更および削除で使用されます。フル・クラス名はcom.fatwire.cos.records.events.CommentEventです。このクラスは、cg.war/WEB-INF/libs/cos-shared-11.1.1.8.0.jarライブラリにあります。

- サポートされるメジャー・タイプ: ALL、COMMENT

- サポートされるマイナー・タイプ: ALL、CREATED、MODIFIED、DELETED、REPORTED

表81-18 CommunityEventのメソッド

メソッド宣言

メソッド定義

Long getFeedId()

CommentsFeedオブジェクトへのリンク

String getSiteId()

イベントが発生したサイトの名前

ModerateContentState getRecordState()

モデレーションの状態を示します。可能な値:

- RECORD_PENDING_NEW

- RECORD_PENDING_MODIFIED

- RECORD_PENDING

- RECORD_APPROVED

- RECORD_INAPPROPRIATE_ROBOT_DETECTED

- RECORD_INAPPROPRIATE_HUMAN_DETECTED

- RECORD_INAPPROPRIATE

81.6.1.2 ReviewEventエンティティ

ReviewEventエンティティは、レビューの作成、変更および削除で発生します。フル・クラス名はcom.fatwire.cos.records.events.ReviewEventです。このクラスは、cg.war/WEB-INF/libs/cos-shared-11.1.1.8.0.jarライブラリにあります。

- サポートされるメジャー・タイプ: ALL、COMMENT

- サポートされるマイナー・タイプ: ALL、CREATED、MODIFIED、DELETED、REPORTED

表81-19 ReviewEventのメソッド

メソッド宣言

メソッド定義

Long getFeedId()

ReviewsFeedオブジェクトへのリンク

String getSiteId()

イベントが発生したサイトの名前

ModerateContentState getRecordState()

モデレーションの状態を示します。可能な値:

- RECORD_PENDING_NEW

- RECORD_PENDING_MODIFIED

- RECORD_PENDING

- RECORD_APPROVED

- RECORD_INAPPROPRIATE_ROBOT_DETECTED

- RECORD_INAPPROPRIATE_HUMAN_DETECTED

- RECORD_INAPPROPRIATE

81.6.1.3 RatingEventエンティティ

RatingEventエンティティは、評価の作成および削除で発生します。フル・クラス名はcom.fatwire.cos.records.events.RatingEventです。このクラスは、cg.war/WEB-INF/libs/cos-shared-11.1.1.8.0.jarライブラリにあります。

- サポートされるメジャー・タイプ: ALL、RATING

- サポートされるマイナー・タイプ: ALL、CREATED、DELETED

表81-20 RatingEventのメソッド

メソッド宣言

メソッド定義

Long getFeedId()

RatingFeedオブジェクトへのリンク

String getSiteId()

イベントが発生したサイトの名前

ModerateContentState getRecordState()

モデレーションの状態を示します。可能な値:

- RECORD_APPROVED

- RECORD_INAPPROPRIATE_ROBOT_DETECTED

- RECORD_INAPPROPRIATE_HUMAN_DETECTED

- RECORD_INAPPROPRIATE

81.6.1.4 ExternalAuthEventエンティティ

ExternalAuthEventエンティティは、外部の認証プロバイダによって正常に認証された場合に発生します。フル・クラス名はcom.fatwire.cos.events.api.ExternalAuthEventです。このクラスは、cg.war/WEB-INF/libs/cos-api-11.1.1.8.0.jarライブラリにあります。

- サポートされるメジャー・タイプ: ALL

- サポートされるマイナー・タイプ: ALL

表81-21 ExternalAuthEventEventのメソッド

メソッド宣言

メソッド定義

String getAuthenticatorId()

外部認証プロバイダの識別子

JSONObject getRawData()

JSONObjectクラスで外部認証プロバイダから受信したデータ。これはプロバイダ(たとえば、Facebook、Twitter)によって異なります。プロバイダ固有の方法で解析する必要があります。

81.6.2 イベントのリスナー

イベントのリスナーは、すべてのイベントのリスニングおよびアクティビティのログ記録で使用されます。すべてのリスナーは、CoSEventListenerクラスから継承されます。リスナーは、どのイベント(たとえば、CommentEventまたはReviewEvent)を処理するかを知っている必要があります。

フル・クラス名はcom.fatwire.cos.events.CoSEventListenerです。このクラスは、cg.war/WEB-INF/libs/cos-api-11.1.1.8.0.jarライブラリにあります。

この項の内容は、次のとおりです。

- 第81.6.2.1項「単純なリスナーの作成」

- 第81.6.2.2項「イベント通知リスナーの開発 - processメソッド」

- 第81.6.2.3項「イベント通知リスナーの開発 - 電子メールの送信」

81.6.2.1 単純なリスナーの作成

この例では、すべてのイベントのログを記録するリスナーの作成方法を示します。cos-api-11.1.1.8.0.jarライブラリが必要です。

単純なリスナーを作成するには

1. 抽象クラスCoSEventListenerを拡張して、SampleListenerクラスを作成します。

public class SampleListener extends com.fatwire.cos.events.CoSEventListener

2. リスナーが記録するメジャー・タイプとマイナー・タイプを選択し(この例ではALL)、クラスのコンストラクタでそれらのタイプを設定します。

public SampleListener () {
setMajorType(CoSEventMajorType.ALL);
setMinorType(CoSEventMinorType.ALL);
}

3. void process (CoSEvent event)およびint getTaskCount()という、2つの関数を実装します。これらは親の抽象クラスでは実装されていません。

private final static Logger LOG = Logger.getLogger(SampleListener.class);
private AtomicInteger counter = new AtomicInteger();

@Override
public void process(CoSEvent event) {
counter.incrementAndGet();
try{
LOG.info("Process event: " + event.getClass() + ": " + event);
} finally {
counter.decrementAndGet();
}
}

@Override
public int getTaskCount(){
return counter.get();
}

完了すると、完全なクラス・ファイルは次のようになります。

package com.example.listeners;

import java.util.concurrent.atomic.AtomicInteger;

import org.apache.log4j.Logger;

import com.fatwire.cos.events.CoSEvent;
import com.fatwire.cos.events.CoSEventListener;
import com.fatwire.cos.events.CoSEventMajorType
import com.fatwire.cos.events.CoSEventMinorType

public class SampleListener extends CoSEventListener
{
private final static Logger LOG = Logger.getLogger(SampleListener.class);
private AtomicInteger counter = new AtomicInteger();

public SampleListener () {
setMajorType(CoSEventMajorType.ALL );
setMinorType(CoSEventMinorType.ALL );
}

@Override
public void process(CoSEvent event) {
counter.incrementAndGet();
try{
LOG.info("Process event: " + event.getClass() + ": " + event);
} finally {
counter.decrementAndGet();
}
}

@Override
public int getTaskCount(){
return counter.get();
}
}

4. Community-Gadgetsの構成にこのリスナーを追加します。
cg.war/WEB-INF/classesフォルダにあるlisteners.xmlファイルを開き、リスナー・クラスのBeanを追加します。

<bean id="sampleListener" class="com.example.listeners.SampleListener" />

81.6.2.2 イベント通知リスナーの開発 - processメソッド

processメソッドは、イベントのタイプがALLに設定されている場合にイベントをフィルタリングできます。

@Override
public void process(CoSEvent event) {
if(event instanceof CommentEvent) {
sendCommentNotification(event);
} else if (event instanceof ReviewEvent) {
sendReviewsNotification(event);
}
}

81.6.2.3 イベント通知リスナーの開発 - 電子メールの送信

このリスナーは、アドレスまたはアドレス・グループに対して通知テキスト付きのMIME電子メールを送信できます。そのための1つの方法として、JavaMail APIを使用した送信機能の開発があります。また、Community-Gadgetsの電子メール機能を使用すると、クラス・ファイル(クラスパスにcos-core-11.1.1.8.0.jarが必要)内に2行のコードを追加することによって電子メールの送信が可能になります。

...
import com.fatwire.cos.core.CoS;
...
CoS.instance().getEmailFacility().send(mimeMessage);
...

mimeMessageを生成するには、次のようなコードが使用されます。

private MimeMessage generateEmail(CoSEvent event, String emails) throws
AddressException, MessagingException {
Session session = null;
MimeMessage msg = new MimeMessage(session);
msg.setFrom(new InternetAddress("noreply@samplenotify.example.com"));
msg.setSentDate(new java.util.Date());
msg.setRecipients(javax.mail.Message.RecipientType.TO,
InternetAddress.parse(emails));
msg.setSubject("==Notification subject==");

Multipart multipart = new MimeMultipart("alternative");
BodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setContent("<SOME NOTIFY TEXT>",
"text/plain;charset=\"UTF-8\"");
multipart.addBodyPart(messageBodyPart);

msg.setContent(multipart);
msg.saveChanges();

return msg;
}

注意:

メッセージ本文の内容を生成するには、Velocityライブラリや他のテンプレート・エンジンを使用できます。前述の"<SOME NOTIFY TEXT>"トークンではなく、生成されたテンプレートを使用する必要があります。

リスナーの作成が完了すると、完全なクラス・ファイルは次の例のようになります。このクラス・ファイルは、cos-api-11.1.1.8.0.jar、cos-core-11.1.1.8.0.jarおよびcos-shared-11.1.1.8.0.jarを必要とします。

package com.fatwire.cos.shared;

import java.util.concurrent.atomic.AtomicInteger;

import javax.mail.BodyPart;
import javax.mail.MessagingException;
import javax.mail.Multipart;
import javax.mail.Session;
import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;

import com.fatwire.cos.core.CoS;
import com.fatwire.cos.events.CoSEvent;
import com.fatwire.cos.events.CoSEventListener;
import com.fatwire.cos.events.CoSEventMajorType;
import com.fatwire.cos.events.CoSEventMinorType;
import com.fatwire.cos.records.events.CommentEvent;
import com.fatwire.cos.records.events.ReviewEvent;

public class NotificationListener extends CoSEventListener {

private AtomicInteger counter = new AtomicInteger();

public NotificationListener () {
setMajorType(CoSEventMajorType.ALL );
setMinorType(CoSEventMinorType.ALL );
}

@Override
public void process(CoSEvent event) {
counter.incrementAndGet();
try {
if(event instanceof CommentEvent) {
sendCommentNotification((CommentEvent)event);
} else if (event instanceof ReviewEvent) {
sendReviewsNotification((ReviewEvent)event);
}
} finally {
counter.decrementAndGet();
}
}

@Override
public int getTaskCount() {
return 0;
}

private void sendCommentNotification(CommentEvent event) {
MimeMessage mimeMessage = null;
String site = event.getSiteId();
try {
mimeMessage = generateEmail(event, site ,
"moderator_comments@samplenotify.example.com");
} catch (Throwable e) {
e.printStackTrace();
}
sendEmail(mimeMessage);
}

private void sendReviewsNotification(ReviewEvent event) {
// send notification only for creating review event
if (event.getMinorType().equals(CoSEventMinorType.CREATED)) {
MimeMessage mimeMessage = null;
String site = event.getSiteId();
try {
mimeMessage = generateEmail(event, site,
"moderator_reviews@samplenotify.example.com");
} catch (Throwable e) {
e.printStackTrace();
}
sendEmail(mimeMessage);
}
}

private void sendEmail(MimeMessage mimeMessage) {
CoS.instance().getEmailFacility().send(mimeMessage);
}

private MimeMessage generateEmail(CoSEvent event, String site,
String emails) throws AddressException, MessagingException {
Session session = null;
MimeMessage msg = new MimeMessage(session);
msg.setFrom(new InternetAddress("noreply@samplenotify.example.com"));
msg.setSentDate(new java.util.Date());
msg.setRecipients(javax.mail.Message.RecipientType.TO,
InternetAddress.parse(emails));
msg.setSubject("==Notification subject== from " + site + " site");

Multipart multipart = new MimeMultipart("alternative");
BodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setContent("<SOME NOTIFY TEXT>",
"text/plain;charset=\"UTF-8\"");
multipart.addBodyPart(messageBodyPart);

msg.setContent(multipart);
msg.saveChanges();

return msg;
}

}

ファイルを作成したら、次のBeanをlistentes.xmlに追加します。

<bean id="sampleListener" class="com.example.listeners.NotificationListener" />

82 Community-Gadgets: 機能のローカライズ

この章では、Community-Gadgetsの機能を複数の言語に翻訳可能にする方法について説明します。

この章には次の項が含まれます。

- 第82.1項「ローカライズについて」

- 第82.2項「Community-Gadgetsへの新しい言語の追加」

- 第82.3項「Community-Gadgetsへの新しい言語の登録」

82.1 ローカライズについて

Community-Gadgetsのユーザー・インタフェースはデフォルトで、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、スペイン語、簡体字中国語、繁体字中国語に翻訳できます。さらに、必要に応じて既存のラベルや翻訳を新しい言語にカスタマイズすることもできます。

言語パックは、Community-Gadgets Webアプリケーションのファイル・システム(cg.war/WEB-INF/classes/i18n_resources)にあります。

図82-1 言語パック

i18n_resourcesディレクトリには2つのサブフォルダserverおよびwidgetsがあり、それぞれにCommunity-Gadgetsインタフェースのリソース、およびクライアント側のウィジェットのリソースが含まれています。

serverディレクトリには、コミュニティ・アプリケーションのサブシステムに基づいて区切られたJavaプロパティ・リソース・バンドルのリストが含まれます。core、cos-resources、gadgets, gadgets-exception, service、shared、usersの各サブシステムのローカライゼーションが含まれます。

widgetsディレクトリには、各フォルダを特定のウィジェットに対応付けるフォルダのリストが含まれます。たとえば、wsdk.commentsフォルダはコメント・ウィジェットに対応付けられ、wsdk.reviewsフォルダはレビュー・ウィジェットに対応付けられます。

cos.commonsディレクトリには、すべてのウィジェットで共有されるリソースがあります。Communityインタフェースと、Webサイトにデプロイされるウィジェットでは、必要な言語を選択するためのロジックが異なります。次の項では、2つのロジックのタイプを優先度の高い順に説明します。

- 第82.1.1項「Community-Gadgetsインタフェースの言語検出」

- 第82.1.2項「Community-Gadgetsの言語検出」

82.1.1 Community-Gadgetsインタフェースの言語検出

1. ログインしているビジネス・ユーザーのWebエクスペリエンス管理(WEM)プロファイルで言語がカスタマイズされている場合は、それを適用します。それ以外の場合は、次の手順に進みます。

2. ブラウザのロケールがサポートされている場合は、この設定を適用します。それ以外の場合は、次の手順に進みます。

3. デフォルトのEnglishロケールを適用します。

82.1.2 Community-Gadgetsの言語検出

この項で説明する言語検出ロジックは、Community-Gadgets側のすべてのウィジェットに適用されます。

次の1番目と2番目の手順は、Webサイトにすでに、サイト・コンテンツを異なる言語で表示するためのいくつかの言語選択メカニズムがあることを前提としています。たとえば、大半のサイトには、この目的でサイトの上部または下部に言語アイコンがあります。このメカニズムが言語選択にCookieまたはJavaScript変数を使用する場合は、Communityウィジェットもクライアントの同意を得た後にそれらを使用できます。サイト開発者は、cos_language CookieまたはJavaScript変数と言語値の作成を可能にすることで、言語選択メカニズムをカスタマイズできます。これが実行されると、Communityウィジェットはクライアントの言語選択メカニズムを使用して、サイト・コンテンツを異なる言語で表示できます。

1. cos_language Cookieによって提供される言語パラメータを使用します(これはサイトの開発者が手動で指定します)。
Cookieが設定されていない場合は、次の手順に進みます。

2. JavaScriptのグローバル変数cos_languageの言語パラメータを使用します(これはサイトの開発者またはインテグレータが手動で指定できます)。
変数が設定されていない場合は、次の手順に進みます。

3. 管理者がCommunityインタフェースの「設定」→「言語」で選択したデフォルトの言語設定を使用します(図82-2)。
この設定は、サイトにデプロイされたすべてのタイプのウィジェットに適用されます。

図82-2 Community-Gadgetsの言語設定

82.2 Community-Gadgetsへの新しい言語の追加

新しい言語を追加するには、次の手順を実行します。

1. Community-Gadgetsの構成(第82.3項「Community-Gadgetsへの新しい言語の登録」を参照)のリストに新しい言語を追加して、その言語がCommunityインタフェースのデフォルト言語セレクタに表示されるようにします。

2. cg.war/WEB-INF/classes/i18n_resources/<subfolders containing translation files>内にあるすべてのリソースの翻訳をアップロードします。つまり、このディレクトリ内のすべての*_en.propertiesファイルを翻訳し、翻訳されたファイル(たとえば、ロシア語の場合、*_ru.propertiesというファイルになる)をコピーして戻します。

82.3 Community-Gadgetsへの新しい言語の登録

Community-Gadgetsの構成に新しい言語を登録するには:

1. cg.war/WEB-INF/libディレクトリに移動します。

2. cos-shared-11.1.1.8.0.jarファイルを開き、cos_core_metadata.xmlファイルを抽出します。

3. schema::cos::commons:permissions:languageという文字列を検索します。この宣言は次のとおりです。

<bean id="language" class="com.fatwire.cos.metadata.core.model.MetadataDescriptorImpl">
<property name="uid"
value="schema::cos::commons:permissions:language"/>
<property name="name" value="label.language"/>
<property name="defaultValue" value="en_US"/>
<property name="dataOptionsValue" value="[
{ name: 'label.language.english', value:'en_US'},
{ name: 'label.language.brazilian_portuguese', value:'pt_BR'},
{ name: 'label.language.chinese_simplified', value:'zh_CN'},
{ name: 'label.language.chinese_traditional', value:'zh_TW'},
{ name: 'label.language.french', value:'fr'},
{ name: 'label.language.german', value:'de'},
{ name: 'label.language.italian', value:'it'},
{ name: 'label.language.japanese', value:'ja'},
{ name: 'label.language.korean', value:'ko'},
{ name: 'label.language.spanish', value:'es'},
<ADD COMMA AND INSERT NEW LANGUAGE HERE>
]"/>
…
</bean>

4. dataOptionsValueプロパティに、新しい言語用の新しいJSONオブジェクトを追加します。たとえば、ロシア語の場合は次のようなエントリになります。

{ name: 'label.language.russian', value:'ru'}

ロシア語のエントリが追加された後のプロパティ値は次のようになります。

<property name="dataOptionsValue" value="[
{ name: 'label.language.english', value:'en_US'},
{ name: 'label.language.brazilian_portuguese', value:'pt_BR'},
{ name: 'label.language.chinese_simplified', value:'zh_CN'},
{ name: 'label.language.chinese_traditional', value:'zh_TW'},
{ name: 'label.language.french', value:'fr'},
{ name: 'label.language.german', value:'de'},
{ name: 'label.language.italian', value:'it'},
{ name: 'label.language.japanese', value:'ja'},
{ name: 'label.language.korean', value:'ko'},
{ name: 'label.language.spanish', value:'es'}
{ name: 'label.language.russian', value:'ru_RU'} ]"/>

5. cos_core_metadata.xmlファイルを保存し、この改訂されたファイルをcos-shared-11.1.1.8.0.jarファイルに含めます。

6. i18n_resources/server/cos-resources_<LANG>.propertiesのリソース・バンドルに移動し、label.langauge.russianというキーと、サポートされている各言語の翻訳値を追加します。
それぞれのcos-resourcesファイル(cos-resources.properties、cos-resources_de.properties、cos-resources_es.properties、cos-resources_fr.properties、cos-resources_it.propertiesなど)に、言語ラベルのセットが含まれています。次に示すのはcos-resources_en.propertiesの例です。

label.language.english = English
label.language.brazilian_portuguese = Brazilian Portuguese
label.language.chinese_simplified = Simplified Chinese
label.language.chinese_traditional = Traditional Chinese
label.language.french = French
label.language.german = German
label.language.italian = Italian
label.language.japanese = Japanese
label.language.korean = Korean
label.language.spanish = Spanish

パラメータ名(たとえば、label.language.russian)およびパラメータ値(たとえば、Russian for cos-resources_en.properties)を含む新しい行を追加します。

label.langauge.russian=Russian

label.langauge.russianのcos-resources_en.propertiesの値は異なります(cos-resources_de.propertiesの場合はRussische、cos-resources_fr.propertiesの場合はRusseになる)。

つまり、次のように指定します。

label.langauge.<lang_id>=<value_translation>

7. i18n_resourcesディレクトリ内で再帰的に検索したすべてのリソース・バンドルについて、対応する言語接尾辞を持つ同じフォルダ内の翻訳ファイルをアップロードします。たとえば、i18n_resources/server/users.propertiesという名前のディレクトリでは、英語パック用のロシア語翻訳を見つけることができます。したがって、i18n_resources/server/ディレクトリにはRussian: users_ru_RU.propertiesの翻訳ファイルをアップロードします。

8. Community管理アプリケーション用のアプリケーション・サーバーを再起動します。

9. 新しい言語表示を確認するには、Communityに管理者としてログインし、「設定」メニューから「言語」を選択します。

83 Community-Gadgets: パフォーマンスの監視

この章では、WebCenter Sitesでのキャッシングの概要について説明します。キャッシュが有効または無効な場合に、Webサイトでコンテンツがどのようにフェッチおよび表示されるかを説明します。また、様々なキャッシュ・モードと、それらがCommunity-Gadgets Webアプリケーションのパフォーマンスとデータの一貫性に及ぼす影響について説明します。キャッシュを構成して、ユーザーが生成したコンテンツの処理を最適化する方法について説明します。

この章には次の項が含まれます。

- 第83.1項「キャッシュについて」

- 第83.2項「Community-Gadgetsとキャッシュ」

- 第83.3項「Community-Gadgetsのキャッシュの構成」

- 第83.4項「Communityアプリケーションでのユーザー生成コンテンツ(UGC)の最適化」

83.1 キャッシュについて

図83-1に示すように(およびこの項で後述するとおり)、システムはリクエストを受信すると、別のサブシステムへリクエストをルーティングします。このサブシステムで、このリクエストの処理に必要な機能が実行されます。リクエストの結果はコンパイルされ、リクエストを行ったクライアントに送信されます。これらの結果は、ページの完全なコメント、特定の方法でソートされたコメント、レビューなどの形式になります。アプリケーションのパフォーマンスを改善するために、システムが同様のリクエストを受信したときに、即座に格納済の情報を検索および再利用して新しいリクエストに対応できるような方法で、これらの結果を格納できます。

ヒント:

Community-Gadgets WebアプリケーションはWebCenter Sitesのデータ・リポジトリを使用し、RESTを通じてそのデータ・リポジトリと通信します。WebCenter Sitesは、受け取ったRESTリクエストをデータベース問合せに変換します。

Community-Gadgetsはそのデータベースからコンテンツをロードすると、WebCenter Sitesが提供するinCacheテクノロジを使用して作成されたインメモリー・キャッシュにコンテンツをキャッシュします。キャッシュは、最も一般的でよくある問合せに関するデータが格納された中間記憶域(RAM)です。キャッシュへのアクセスは、RAMが記憶域として使用されている非常に高速です。

図83-1 キャッシュ・プロセスのフロー

キャッシュは、ネットワーク通信やデータのシリアライズに関するオーバーヘッドの削減に役立ちます。システムのパフォーマンスやスループットを向上させるには、リクエストの処理結果をキャッシュから提供する必要があります。

キャッシュ・テクノロジを使用してリクエストを処理する際には、キャッシュ・ヒットとキャッシュ・ミスという、2種類のイベントが発生します。キャッシュ・ヒットは、リクエストされたデータがすでにキャッシュ内に存在し、キャッシュから直接データを取り出してクライアントに返すことができる場合に発生します。キャッシュ・ミスは、リクエストされたデータがキャッシュ内に存在しない場合に発生します。この場合、最初にWebCenter Sitesのデータ・リポジトリからキャッシュにデータがコピーされ、それから後続のリクエストが処理されます。たとえば、ユーザーがコメントまたはレビューが投稿されたページを最初にリクエストする場合(つまり、そのページは以前にリクエストされていないか、またはキャッシュがフラッシュ済である場合)、Community-Gadgetsはそのページをキャッシュに保存します。別のユーザーがこのページをリクエストすると、Community-Gadgetsはキャッシュからそのページを取得します。ユーザーとCommunity-Gadgetsの間の相互作用の結果、アプリケーションはWebCenter Sitesからロードしたすべてのデータをキャッシュします。このキャッシュはインメモリー・キャッシュです。

次の項では、システムがキャッシュを扱う際の動作について説明します。

83.2 Community-Gadgetsとキャッシュ

この項の内容は、次のとおりです。

- 第83.2.1項「Community-Gadgetsの理解」

- 第83.2.2項「標準キャッシング」

- 第83.2.3項「失効キャッシング」

- 第83.2.4項「キャッシングの依存関係」

83.2.1 Community-Gadgetsの理解

Webサイトのページで訪問者がコメントやレビューなどのアイテムを作成、更新または削除すると、Community-Gadgetsは次の動作を行います。

- WebCenter Sites内の関連するすべてのデータを変更します

- 関連するすべてのキャッシュ・エントリを無効にします

このように、Community-Gadgetsはシステム全体に対して、キャッシュ・エントリは失効して無効になっており、ユーザーのアクションに基づいて更新する必要があることを伝えます。たとえば、既存のコメントを編集する場合は、キャッシュ内にある特定のアイテムおよび編集されたコメントのディスカッションに関連付けられたデータ・コレクション全体を無効にする必要があります。今後のアクセスに備えて、無効になった値の更新がバックグラウンドで実行されます。

WebCenter Sitesはリモート・サーバーをサポートしており、RESTプロトコルで無効化リクエストを送信することによってリモート・サーバーのキャッシュ・コンテンツを最新に保ちます。これを可能にするには、SystemSatellite表にCommunity-Gadgets Webアプリケーションをリモート・サーバーとして登録します。Community-Gadgetsのインストールと構成の詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。

Community-Gadgetsをサテライト・サーバーとして登録すると、Community-Gadgetsは変更されたデータに関する通知の受信を開始し、それに基づいてキャッシュの無効化を行います。データが変更されると、Community-Gadgetsの本番システムおよび管理システムを含むすべてのサテライトに通知が送信されます。図83-2は、そのプロセス・フローを示しています。

注意:

通知は同期的にブロードキャストされます。したがって、すべてのサテライトがこの無効化の受信の確認応答を行うまでは、変更リクエストは完了しません。

図83-2 WebCenter SitesとCommunity-GadgetsのSatellite Serverの間の通信

このプロセス・フローに示されているように、Community-Gadgetsはすべてのリクエストの結果をローカルのメモリーにキャッシュし、キャッシュの整合性を確保するために無効化通知を受け取ります。たとえば、Community-Gadgetsがリクエストの結果を収集、格納および送信した後で同様の内容のリクエストが到着すると、アプリケーションはキャッシュされたデータを返します。ただし、1回目と2回目のリクエストの時間枠の間に訪問者がなんらかの変更を行い、同じ時間枠内で無効化リクエストが行われた場合、2回目のリクエストではキャッシュからではなく、WebCenter Sitesのリポジトリからデータが提供されます。図83-3、図83-4および図83-5も参照してください。

Community-Gadgetsには、標準キャッシングと失効キャッシングという、2つのキャッシング・モードがあります。いずれのモードも、データの読取りでは同じアプローチをとります。要求されたデータがキャッシュにある場合は、そこから直接提供されます。データがキャッシュにない場合は、WebCenter Sitesのリポジトリから同期的にロードされます。したがって、ユーザー側のユーザー・インタフェースに結果が表示されるのは、load操作が完了し、データがキャッシュされた後です。ただし、データの無効化およびキャッシュの整合性の動作は、標準キャッシングと失効キャッシングで異なります。

83.2.2 標準キャッシング

Community-Gadgetsが特定のデータの無効化リクエストを受け取ると、Community-Gadgetsはキャッシュされたデータをすぐに無効にします。これにより、そのデータを要求する以降のすべてのリクエストではキャッシュ・ミスが発生し、WebCenter Sitesのリポジトリから新たにデータがロードされます。

図83-3は、標準キャッシング・モードでのキャッシュ・ヒット・イベントとキャッシュ・ミス・イベントのプロセス・フローを示しています。

図83-3 標準キャッシングにおけるキャッシュ・ヒットとキャッシュ・ミス

標準キャッシング・モードでは、データの整合性レベルは高く、すべての変更はただちにインタフェースに反映されます。たとえば、ユーザーが新しいコメントを投稿してページをリフレッシュすると、新しいコメントはすぐにページに表示されます。同様に、ページから削除されたコンテンツは、ページをリフレッシュするとすぐに消えます。

83.2.2 失効キャッシング

Community-Gadgetsが無効化リクエストを受け取っても、データはすぐには無効化されず、消去もされません。これは、標準キャッシング(キャッシュ・データをすぐに無効にする)の場合とは対照的です。失効キャッシング・モードでは、Community-Gadgetsは特殊な無効化マークを使用して、有効でなくなったデータにマーク付けを行います。しかし、データはキャッシュ内に置かれたままであるため、引き続きキャッシュ・メモリーから提供できます。無効化されたデータを要求するリクエストを受け取ると、そのデータを更新するためのスレッドが起動されます。このプロセスは再生成サイクルと呼ばれます。

図83-4は、無効化されたデータがバックグラウンドで再生成された後、その再生成されたコンテンツがキャッシュから提供される様子を示しています。

図83-4 失効キャッシングにおける再生成サイクル

失効キャッシング・モードでは、データ・ロードはバックグラウンドでシームレスに行われるため、パフォーマンス・レベルは高くなります。ただし、バックグラウンドでのデータ・ロードであるため、データの整合性レベルは標準キャッシング・モードよりも低くなり、訪問者は実際の結果をすぐには参照できません。たとえば、コメントを投稿した後で、そのコメントがページに表示されるまでには、何回かページをリフレッシュする必要があります。次のプロセスは、失効キャッシング・モードでの実行内容の説明です。

1. 訪問者によるコメントの投稿: Community-Gadgetsは、特殊な無効化マークを使用してコメント・リストにマーク付けを行います。

2. 訪問者による最初のページ・リフレッシュ: Community-Gadgetsは、キャッシュからの新しいコメントが含まれていない古いデータを引き続き提供しますが、特殊マークを検出し、バックグラウンドでの更新プロセスを開始します。

3. 訪問者による2回目のページ・リフレッシュ: バックグラウンドでの更新プロセスが完了し、キャッシュが更新されたため、新しく投稿されたエントリを含む新しいコメント・リストがクライアントに返されます。
バックグラウンドの更新プロセスは、最初のリフレッシュとともに開始されます。2回目のリフレッシュでは、最初のリフレッシュの終了によってキャッシュが更新されているため、更新されたデータが表示されます。ただし、この処理はネットワークのオーバーヘッドや変更量によって影響を受けるため、2回より多くのリフレッシュが必要になる可能性があります。

デフォルトでは、Community-Gadgetsは標準キャッシュ・スキーマを使用します。パフォーマンスを向上させるには、スタンドアロン・フォルダ(デフォルトの場所は<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1)内の構成ファイルwsdk_facilities.propertiesで失効キャッシングを有効にします。そのためには、例83-1に示すapp_cache.staleプロパティをtrueに設定します。

例83-1 失効キャッシュ・モードの有効化

## Application cache facility configuration
# + stale parameter enables usage 'old' data on production side
#
app_cache.stale=false

app_cache.staleプロパティをfalseに設定すると、標準キャッシング・スキーマが使用されます。ただし、製品の特定の領域では常に高い整合性レベルが必要になるため、次の領域では失効キャッシュ・モードが無視されます。

- CommunityインタフェースおよびGadgetsインタフェース。管理を容易にするため、データは本番システムとの間で常に整合性が取れている必要があります。

- 訪問者のプロファイルに関する操作。特に、登録時にアプリケーションでは、同じ名前を持つユーザーが存在するかどうかを確認する必要があります。

キャッシュは「キャッシュ管理」コンソールを介して管理できます。このコンソールには、各Community-Gadgetsインスタンスのhttp://<cg_host:<cg_port/<cg_context/cacheからアクセスします。たとえば、http://mycosprod.example.com:8180/cg/cache/です。キャッシュ管理とCommunity-Gadgetsの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

83.2.4 キャッシングの依存関係

キャッシングには、次のタイプの依存関係が関連付けられます。

- コンテンツ変更の依存関係: このタイプの依存関係は、Commons Cacheなどのキャッシュ・エントリ表のDependencies列に記録されます。ここには、既存のアセットのIDが格納されます。関連付けられたアセットに変更があった場合、システムはこのキャッシュ・エントリを無効にします。

- コンテンツ作成の依存関係: このタイプの依存関係はシステム固有です。このような場合、inCache依存関係キーワードのunknowndeps: <table name>というタイプが使用されます。表に新しいエントリが投稿されると、キャッシュは無効になります。このタイプのキャッシングは、なんらかの新しいコンテンツが投稿された場合に無効にする必要のある検索や個数の問合せで便利です。

キャッシュ管理中のユーザー操作は、Community-Gadgetsロジックと、キャッシュ内に格納されているエントリに常にマップされている必要があります。たとえば、コメントのロード中には、図83-5のデータ構造が、「コメント」ウィジェットのロード開始時に最初に表示される「ロード中」メッセージ(ロード操作)に関連付けられます。

図83-5 コメント操作に関連付けられているデータ構造

次に、図83-5の手順を追った説明を示します。これらの手順では、コメントの各操作がどのように実行され、キャッシュされるかについて説明しています。

1. ディスカッション全体を集約するCommentFeedオブジェクトが検出されます。

2. コメントの総数が検出されます。この数を使用して、ページ操作のインタフェースおよび他のコメント関連の機能が計算され、レンダリングされます。

3. Community-Gadgetsで構成されているサイト設定がロードされます。これらの設定が、訪問者がアクセスしたページにレンダリングされるCommentFeedオブジェクトに適用されます。これらの設定によって、ページ上でコメント投稿フォームが表示される場所(上部または下部)、コメント投稿権限のレベルなどが決定されます。設定IDが検出された後、Community-Gadgetsはデータベースにアクセスする前にキャッシュを検索し、キャッシュ・ヒットを取得します。

4. サイトの設定がキャッシュされていない場合は、それらのIDを利用してWebCenter Sitesのリポジトリから設定をフェッチします。プロセスの効率性の観点から、可能なかぎりIDによる参照が使用されます。

5. Webサイトに表示される実際のコメントのロードが開始されます。Comment FeedオブジェクトとCommentRecordオブジェクトには1対多の関係があります。最初に、特定のフィードに関連付けられているすべてのコメントIDが検出されます。特定のフィードに関連付けられているコメントIDが検出された後、ローカルのキャッシュ・エントリとの間でIDが分析、検証されます。キャッシュ内に存在しないIDは次のリクエストでロードされます。

6. 前の手順で検出されたIDを利用して、WebCenter SitesのリポジトリからCommentRecordオブジェクトがロードされます。

7. コメントが調べられ、認証済ユーザーによって投稿されたコメントから作成者IDが抽出されます。次に、WebCenter Sitesのリポジトリから、キャッシュ・ヒットが存在する訪問者のプロファイルIDがロードされます。

83.3 Community-Gadgetsのキャッシュの構成

Community-Gadgetsのキャッシュ構成はWebCenter Sitesのキャッシュ構成と似ています。これは、いずれの製品も同じinCacheインフラストラクチャを使用しているためです。

キャッシュ構成ファイルcos-cache.xmlおよびcas-cache.xmlは、それぞれのCommunityノード・ディレクトリのcos-standalone-configディレクトリ内にあります。

このファイルの構成パラメータ、およびページ・キャッシュ用のinCacheの構成方法の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

83.4 Communityアプリケーションでのユーザー生成コンテンツ(UGC)の最適化

訪問者トラフィックとフィードバック量が最大になる、1日の中でのピーク時間帯があります。つまり、1日の中で、最大数のUGCエントリがデータベースに送信される時間帯があります。このようなピーク・ロード期間では、データベースは、訪問者がコンテンツ・エントリを送信する速度でコンテンツ挿入を処理できません。この状況を解消するため、WebCenter Sitesは遅延書込みというオプションを提供しています。これは、プロデューサ・コンシューマ・パターンを使用する単純で効果的なツールです。訪問者は、コメント、レビューなどの形式でシステムにコメントを送信します。その後、コンテンツ・エントリはデータベースのキューに入れられます。コンシューマ・スレッドはこれらのエントリをキューから選択して、1つずつデータベースに挿入します。そのため、これらの受信リクエスト(UGCエントリ)の結果は、後でWebサイトに表示されます。変更内容はバッファされてバックグラウンドで適用されるため、データの不整合が生じます。そのため、ユーザーは変更内容をすぐには表示できません。

遅延書込みオプションが使用できるのは、管理者がWebCenter Sitesで構成した後のみです。このオプションを有効にする方法の詳細は、第77章「WEMフレームワーク: バッファリング」を参照してください。Community-Gadgetsで使用されるWebCenter Sitesインスタンスに対して遅延書込みオプションが構成されたら、standalone_nodeフォルダ内にあるアプリケーションのsetup_cs.properties構成ファイルにもこのオプションを設定する必要があります(デフォルトの場所は<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1)。このファイルの中で、widgets.cs.production.attrs.delayed_writesプロパティをtrueに設定します。

#
# Enabling "delayed writes" mechanism. CS will persist the assets asynchronously.
# Default is "false"
#
widgets.cs.production.attrs.delayed_writes=true

Community-Gadgetsで遅延書込みオプションを有効にしたら、Communityの本番アプリケーション・サーバーと管理アプリケーション・サーバーを再起動します。訪問者がレビュー、コメントなどの形式でコンテンツを送信したときに、本番システムの動作が変わることがわかります。たとえば、訪問者がコメントを投稿すると、「送信ありがとうございます」メッセージが表示され、それがサーバー上で非同期で処理されないかぎり、コメントはサイトに表示されません。

84 アプリケーションのメンテナンスに関するガイドライン

この章には次の項が含まれます。

- 第84.1項「ウィジェットのデプロイメントのガイドライン」

- 第84.2項「ロギング・レベルの調整」

- 第84.3項「問題の報告」

84.1 ウィジェットのデプロイメントのガイドライン

Community-Gadgets Webアプリケーションでウィジェットの機能、権限および外観を構成したら、Community-Gadgetsウィジェットのデプロイメント・プロセスを開始できます。ウィジェットのデプロイ時に「サイトの設定」オプションを選択すると、ウィジェットを含むページが再ロードされた後、Community-Gadgetsで行った構成が、デプロイ済のウィジェットにすぐに反映されます。このオプションを設定すると、デプロイ済のウィジェットがデータベース内の構成変更を常に監視するようになります。ただし、「カスタム設定」オプションの一部の構成設定では、ウィジェット・デプロイメント・コード・スニペット自体に埋め込まれるカスタム値が使用されます。カスタム構成設定は、データベースに格納されるのではなく、ウィジェットがデプロイされるページのHTML/JavaScriptコードに格納されることに注意してください。その結果、カスタム構成設定はサイト設定よりも優先されます。

「カスタム設定」オプションを選択してウィジェットをデプロイすると、カスタマイズ用に「リソースID」フィールドが利用できるようになります。Community-GadgetsはリソースIDを利用することによって、訪問者が投稿したコンテンツをデプロイ先のページに関連付けることができます。JavaScriptを使用してウィジェットの機能をWebサイトにデプロイする軽量な統合アプローチであるため、このIDを使用して、ページに表示されるコンテンツ・タイプが決定されます。たとえば、デプロイ時にリソースIDが指定されていない場合は、リソースIDとしてmd5 (128ビット(16バイト)のハッシュ値を生成する暗号化ハッシュ機能)が自動的に使用されます。この場合、あるページに訪問者が何度もアクセスすると、Community-Gadgetsによって同じコンテンツが表示されます。したがって、(コンテンツ管理システムによって管理されている場合、)リソースIDをページIDと同じにすることをお薦めします。そうすることによって、関連付けが単純で直感的になります。2つの異なるページに同じコメント・フィードを表示する必要がある場合は、同じリソースIDを指定するのみで済みます。　たとえば、両方のページでxyzをリソースIDとして使用することにより、これらのページに同じコンテンツがレンダリングされます。

84.2 ロギング・レベルの調整

この項の内容は、次のとおりです。

- 第84.2.1項「log4jログ出力の構成」

- 第84.2.2項「SEOウィジェットのJARファイルのロギングの有効化」

84.2.1 log4jログ出力の構成

製品メンテナンスにおいて、ログ・ファイルの構成と監視は重要な要素です。この項では、トラブルシューティングおよび監視で利用可能なlog4jログ出力について説明します。

- log4j-cos.propertiesファイルは、Community-Gadgets Webアプリケーションのロギング用のメイン構成ファイルです。log4j-shindig.propertiesファイルは、Shindig Webアプリケーションのロギング用のメイン構成ファイルです。これらのファイルは、standalone_nodeフォルダにあります(デフォルトの場所は、<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1)。

- Community-Gadgets固有のすべてのロギングを有効にするには、次のロガ出力をデバッグ・レベルに設定します。

log4j.logger.com.fatwire=DEBUG
log4j.logger.oracle.fatwire.widgets=DEBUG

- Community-GadgetsがWebCenter Sitesのデータ・リポジトリに送信するすべてのリクエストを監視するには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.core.jpa.cmd.wem.WemCommandManager = TRACE

- Community-Gadgetsがネットワークに送信するすべてのリクエスト、および使用されるネットワーク・プロキシを監視するには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.registry.client.local=TRACE

- RESTを介したWebCenter Sitesの接続に使用されるCASチケットのライフサイクル管理を監視するには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.core.jpa.session.wem.WemSessionManager = TRACE
log4j.logger.com.fatwire.cos.core.sites.wem.WemManager = TRACE

- Community-Gadgetsによって実行されるinCacheの操作を監視するには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.core.cache.appcache.wem.WemAppCacheFacility = TRACE

- WebCenter SitesからのinCacheの無効化リクエストを監視するには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.core.cache.appcache.wem.IncacheServlet = TRACE

- システム内のデータ整合性の問題や同期機能(ロック)のトラブルシューティングを行うには、次のログ出力を有効にします。log4j.logger.com.fatwire.cos.cluster.CacheLockClientFacility = TRACE
log4j.logger.com.fatwire.cos.cluster.ClusterLockImpl = TRACE

84.2.2 SEOウィジェットのJARファイルのロギングの有効化

検索エンジン最適化(SEO)をサポートするウィジェットをデプロイする場合、ウィジェットのデプロイメントとレンダリング・ロジックが格納されているcos-widget-tag.jarファイルをダウンロードし、Webアプリケーションのクラスパスにこのファイルを配置する必要があります。「コメント」→「デプロイ」→「コメント」に移動して「カスタム設定」を選択し、「ウィジェット・タグ」フィールドまで下にスクロールします。JARファイルをダウンロードするには、「注意」セクションのリンクをクリックします。

これは軽量のJARファイルであり、外部のロギング・ライブラリとは独立して機能するように作成されています。ただし、このライブラリ(cos-widget-tag.jar)によって提供されるログ・メッセージを有効にするには、Webアプリケーションを実行するJVMにJavaパラメータ-Dcos.widget.tag.debug=trueを追加する必要があります。これにより、ログ・メッセージが標準の出力ストリーム(コンソール)に表示されるようになります。

このライブラリのパフォーマンスを最適化するには、次のJVMパラメータを追加することをお薦めします。

-Dhttp.keepAlive=true, -Dhttp.maxConnections=<Number>

<Number>の値は、SEOデプロイメント・タグを含むページがデプロイされたアプリケーション・サーバーの並列度、およびアプリケーション・サーバー上で利用可能な処理スレッドの数にあわせる必要があります。

84.3 問題の報告

サポート・チームに問い合せる前に、調査に必要な情報を収集してください。これにより、不必要なコミュニケーションのやり取りが回避され、トラブルシューティング・プロセスが迅速になります。

次に、迅速で効率的なトラブルシューティングをサポートするために推奨される項目リストを示します。

環境の詳細

- オペレーティング・システムの名前とバージョン

- システムの言語、ロケール、タイムゾーン

- JVMの名前とバージョン

- アプリケーション・サーバーの名前とバージョン

構成の詳細

製品構成ディレクトリの内容をアーカイブし、そのアーカイブをサポート・チケットに添付します。たとえば、Production_node1またはManagement_Node1の構成は、<install folder>/deploy/productionおよび<install folder>/deploy/managementディレクトリに保存されています。それ以外にも、<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1ディレクトリにあるsetup_*.propertiesファイルが必要です。

ロギングの詳細

- Community-Gadgets、そのCASおよびShindigのログ・ファイル

- WebCenter SitesアプリケーションおよびそのCASのログ・ファイル

- Community-GadgetsおよびWebCenter Sitesのアプリケーション・サーバーのログ・ファイル(標準出力および標準エラー・コンソールを含む)

85 Community-Gadgets: Communityのウィジェット・タグの分析

Communityのそれぞれのウィジェットには独自のデプロイメント画面があり、そこにはウィジェットのタグが表示されます。この章では、それぞれのウィジェット・タグの中に定義されているパラメータの情報を提供します。

この章には次の項が含まれます。

- 第85.1項「「コメント」のウィジェット・タグ」

- 第85.2項「「レビュー」のウィジェット・タグ」

- 第85.3項「「評価」のウィジェット・タグ」

- 第85.4項「「ログイン・バー」のウィジェット・タグ」

- 第85.5項「「投票」のウィジェット・タグ」

85.1 「コメント」のウィジェット・タグ

ここでは、Webサイトへのコメント機能の追加に関連するウィジェット・タグを紹介します。

- 第85.1.1項「「コメント」ウィジェット・タグ」

- 第85.1.2項「「コメント・サマリー」ウィジェット・タグ」

- 第85.1.3項「「トピックへのリンク」ウィジェット・タグ」

- 第85.1.4項「「最近コメントされた」ウィジェット・タグ」

- 第85.1.5項「「最もコメントが多い」ウィジェット・タグ」

85.1.1 「コメント」ウィジェット・タグ

「コメントのデプロイメント」画面(メニュー・バーから「コメント」→「デプロイ」→「コメント」を選択してアクセスできる)では、デザイナに「コメント」ウィジェット・タグが提供されます。この項では、「コメント」ウィジェット・タグで定義されているパラメータを分析します。

「コメント」ウィジェット・タグ

1. <div id="comments_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.comments",

6. version: "1.5",

7. elementID: "comments_container",

8. attributes: {"site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.comments) == 'undefined')) {document.getElementById('comments_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Comments is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.comments');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「コメント」ウィジェット・タグの分析

- 行1は、ページ上の「コメント」ウィジェットを格納するコンテナを定義しています。「コメント」ウィジェットのこのインスタンスにリソースIDを割り当てた場合、この行にもウィジェットのリソースIDを指定します。例:

<div id= "comments_container[resource_id]"></div>

[resource_id]は、「コメント」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェット・タグのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「コメント」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「コメント」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「コメント」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「コメント」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「コメント」ウィジェット・タグ(wsdk.comments)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-1 Webページに表示された「コメント」ウィジェット

85.1.2 「コメント・サマリー」ウィジェット・タグ

「コメント・サマリーのデプロイメント」画面(メニュー・バーから「コメント」→「デプロイ」→「コメント・サマリー」を選択してアクセスできる)では、デザイナに「コメント・サマリー」ウィジェット・タグが提供されます。この項では、「コメント・サマリー」ウィジェット・タグで定義されているパラメータを分析します。

「コメント・サマリー」ウィジェット・タグ

1. <div id="comments_summary_container[resource_id]"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "comments-summary",

6. version: "0.1",

7. elementID: "comments_summary_container[resource_id]",

8. attributes: {"site_id":"FirstSiteII","resource_id":"[resource_id]","show_last_comment_date":"false"}});

9. setTimeout(

10. function(){if ((typeof(cos) == 'undefined')||(typeof(comments_summary) == 'undefined')) {document.getElementById('comments_summary_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Comments Summary is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('comments-summary');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「コメント・サマリー」ウィジェット・タグの分析

- 行1は、ページ上の「コメント・サマリー」ウィジェットを格納するコンテナを定義しています。「リソースID」フィールドに「コメント」ウィジェット・タグのリソースIDを指定した場合、この行にもそのリソースIDを指定します。例:

<div id= "comments_summary_container[resource_id]"></div>

[resource_id]は、目的の「コメント」ウィジェットのリソースIDです。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「コメント・サマリー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「コメント・サマリー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「コメント・サマリー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「コメント・サマリー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「コメント・サマリー」ウィジェット・タグ(comments-summary)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-2 Webページに表示された「コメント・サマリー」ウィジェット

85.1.3 「トピックへのリンク」ウィジェット・タグ

「トピックへのリンクのデプロイメント」画面(メニュー・バーから「コメント」→「デプロイ」→「トピックへのリンク」を選択してアクセスできる)では、デザイナに「トピックへのリンク」ウィジェット・タグが提供されます。この項では、「トピックへのリンク」ウィジェット・タグで定義されているパラメータを分析します。

「トピックへのリンク」ウィジェット・タグ

1. <a href="[resource_url]#comments_link&resource_id=[resource_id]" ></a>

2. <div id="comments_link_div[random]"></div>

3. <script type="text/javascript">

4. cos = window.cos || {};

5. cos.pageWidgets = cos.pageWidgets || [];

6. cos.pageWidgets.push({name: "comments-link",

7. version: "0.1",

8. elementID: "comments_link_div[random]",

9. attributes: {"site_id":"FirstSiteII"}});

10. cos.pageScripts = cos.pageScripts || [];

11. cos.pageScripts.push('comments-link');

12. (function()

13. {

14. var oldOnloadHandler = window.onload || function()

15. {

16. };

17. if (!oldOnloadHandler.alreadyProcessed)

18. {

19. window.onload = function()

20. {

21. var script = document.createElement('script');

22. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

23. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

24. script.type = 'text/javascript';

25. script.charset = 'utf-8';

26. document.getElementsByTagName("head").item(0) .appendChild(script);

27. oldOnloadHandler.apply(this, arguments);

28. };

29. window.onload.alreadyProcessed = true;

30. }

31. })();

32. </script>

「トピックへのリンク」ウィジェット・タグの分析

- 行1は、目的の「コメント」ウィジェット・タグがデプロイされるWebページへのリンクであり、「トピックへのリンクのデプロイメント」画面の「リソースID」フィールドおよび「リソースURL」フィールドに値を入力するとタグに自動的に追加されます。

- 行2は、ページ上の「トピックへのリンク」ウィジェットを格納するコンテナを定義しています。

- 行3は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行4は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行5は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行6から9は、「トピックへのリンク」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行5で定義)に新しいエレメントを追加しています。行8には、行2で定義されているコンテナの内部に「トピックへのリンク」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行10は、ページにデプロイされているスクリプトのリストを定義しています。スクリプトがデプロイされていない場合、このリストの値は空のままです。

- 行11は、「トピックへのリンク」ウィジェット・タグ(comments-link)をページ・スクリプトのリスト(行10で定義)に追加しています。

- 行14は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行17は、onload関数がすでに処理されているかどうかをチェックしています。

- 行19は、ページのロード時に実行されるコードをオーバーライドしています。

- 行21から26は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行27は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行29は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行32は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

85.1.3.1 「トピックへのリンク」ウィジェット・タグ(「コメント」用)のデプロイ

「トピックへのリンク」ウィジェットを構成して、「コメント」(および「レビュー」)ウィジェットがデプロイされる複数のWebページのサマリー情報およびそれらのページへのリンクを表示するには、目的のWebページにデプロイされる各「コメント」ウィジェットまたは「レビュー」ウィジェット(あるいはその両方)のリソースIDおよびリソースURLを、「トピックへのリンク」ウィジェット・タグに挿入する必要があります。

注意:

「コメント」ウィジェットと「レビュー」ウィジェットは、同一の「トピックへのリンク」ウィジェット・タグの中で指定できます。「トピックへのリンク」タグでの「レビュー」ウィジェットの指定の詳細は、第85.2.3.1項「「トピックへのリンク」ウィジェット・タグ(「レビュー」用)のデプロイ」を参照してください。

例:

1. メニュー・バーで、「コメント」→「デプロイ」→「トピックへのリンク」を選択します。

2. 「トピックへのリンクのデプロイメント」画面で、「トピックへのリンク」ウィジェット・タグをコピー([Ctrl]+[C])します。

3. WebCenter SitesのAdminインタフェースにアクセスし、「トピックへのリンク」ウィジェット・タグを目的のテンプレートに挿入します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

4. 「トピックへのリンク」ウィジェット・タグの行1に、「トピックへのリンク」ウィジェットによってサマリー情報とリンクが表示される、デプロイ済の各「コメント」ウィジェットまたは「レビュー」ウィジェット(あるいはその両方)のリソースIDを指定します。例:
「トピックへのリンク」ウィジェット・タグ内で指定するすべての「コメント」ウィジェットで、次の行を追加します。

<a href="http://URL#comments_link&resource_id=CommentsID"></a>

http://URLは、目的の「コメント」ウィジェットのデプロイ先であるWebページのパスです。

5. 「変更の保存」をクリックします。

6. ページのプレビューを行い、Webサイトにテンプレートを公開します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』および『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

図85-3 Webページに表示された「トピックへのリンク」ウィジェット

注意:

「トピックへのリンク」ウィジェットをデプロイしても、タイトルは表示されません。「トピックへのリンク」ウィジェットでタイトルを表示するには、「トピックへのリンク」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.1.4 「最近コメントされた」ウィジェット・タグ

「最近コメントされたデプロイメント」画面(メニュー・バーから「コメント」→「デプロイ」→「最近コメントされた」を選択してアクセスできる)では、デザイナに「最近コメントされた」ウィジェット・タグが提供されます。この項では、「最近コメントされた」ウィジェット・タグで定義されているパラメータを分析します。

「最近コメントされた」ウィジェット・タグ

1. <div id="topics_container_recently_commented_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_recently_commented_other",

8. attributes: {"content_type":"recently_commented","site_id":"FirstSiteII","resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_recently_commented_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最近コメントされた」ウィジェット・タグの分析

- 行1は、ページ上の「最近コメントされた」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最近コメントされた」ウィジェット・タグを定義し、ウィジェット・タグのリスト(4行で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最近コメントされた」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最近コメントされた」ウィジェットがリストするトピックのタイプを含め、「最近コメントされた」ウィジェット・タグの設定を指定しています。「最近コメントされた」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最近コメントされた」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最近コメントされた」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「最近コメントされた」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-4 Webページに表示された「最近コメントされた」ウィジェット

注意:

「最近コメントされた」ウィジェットをデプロイしても、タイトルは表示されません(図85-4を参照)。「最近コメントされた」ウィジェットでタイトルを表示するには、「最近コメントされた」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.1.5 「最もコメントが多い」ウィジェット・タグ

「最もコメントが多いデプロイメント」画面(メニュー・バーから「コメント」→「デプロイ」→「最もコメントが多い」を選択してアクセスできる)では、デザイナに「最もコメントが多い」ウィジェット・タグが提供されます。この項では、「最もコメントが多い」ウィジェット・タグで定義されているパラメータを分析します。

「最もコメントが多い」ウィジェット・タグ

1. <div id="topics_container_most_commented_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_most_commented_other",

8. attributes: {"content_type":"most_commented","site_id":"FirstSiteII","resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_most_commented_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最もコメントが多い」ウィジェット・タグの分析

- 行1は、ページ上の「最もコメントが多い」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最もコメントが多い」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最もコメントが多い」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最もコメントが多い」ウィジェットがリストするトピックのタイプを含め、「最もコメントが多い」ウィジェット・タグの設定を指定しています。「最もコメントが多い」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最もコメントが多い」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最もコメントが多い」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているページ・スクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「最もコメントが多い」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-5 Webページに表示された「最もコメントが多い」ウィジェット

注意:

「最もコメントが多い」ウィジェットをデプロイしても、タイトルは表示されません(図85-5を参照)。「最もコメントが多い」ウィジェットでタイトルを表示するには、「最もコメントが多い」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.2 「レビュー」のウィジェット・タグ

ここでは、Webサイトへのレビュー機能の追加に関連するウィジェット・タグを紹介します。

- 第85.2.1項「「レビュー」ウィジェット・タグ」

- 第85.2.2項「「レビュー・サマリー」ウィジェット・タグ」

- 第85.2.3項「「トピックへのリンク」ウィジェット・タグ」

- 第85.2.4項「「平均評価のレビュー」ウィジェット・タグ」

- 第85.2.5項「「上位ランクのレビュー」ウィジェット・タグ」

- 第85.2.6項「「最近レビューされた」ウィジェット・タグ」

- 第85.2.7項「「最もレビューされている」ウィジェット・タグ」

85.2.1 「レビュー」ウィジェット・タグ

「レビューのデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「レビュー」を選択してアクセスできる)では、デザイナに「レビュー」ウィジェット・タグが提供されます。この項では、「レビュー」ウィジェット・タグで定義されているパラメータを分析します。

「レビュー」ウィジェット・タグ

1. <div id="reviews_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.reviews",

6. version: "1.5",

7. elementID: "reviews_container",

8. attributes: {"site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.reviews) == 'undefined')) {document.getElementById('reviews_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Reviews is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.reviews');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「レビュー」ウィジェット・タグの分析

- 行1は、ページ上の「レビュー」ウィジェットを格納するコンテナを定義しています。「レビュー」ウィジェット・タグのこのインスタンスにリソースIDを割り当てた場合、この行にもウィジェットのリソースIDを指定します。例:

<div id= "reviews_container[resource_id]"></div>

[resource_id]は、「レビュー」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェットのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「レビュー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「レビュー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「レビュー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「レビュー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているページ・スクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「レビュー」ウィジェット・タグ(wsdk.reviews)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-6 Webページに表示された「レビュー」ウィジェット

85.2.2 「レビュー・サマリー」ウィジェット・タグ

「レビュー・サマリーのデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「レビュー・サマリー」を選択してアクセスできる)では、デザイナに「レビュー・サマリー」ウィジェット・タグが提供されます。この項では、「レビュー・サマリー」ウィジェット・タグで定義されているパラメータを分析します。

「レビュー・サマリー」ウィジェット・タグ

1. <div id="reviews_summary_container[resource_id]"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "reviews-summary",

6. version: "0.1",

7. elementID: "reviews_summary_container[resource_id]",

8. attributes: {"site_id":"FirstSiteII","resource_id":"[resource_id]","show_last_comment_date

9. setTimeout(

10. function(){if ((typeof(cos) == 'undefined')||(typeof(cos.reviews-summary) == 'undefined')) {document.getElementById('reviews_summary_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Reviews Summary is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('reviews-summary');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「レビュー・サマリー」ウィジェット・タグの分析

- 行1は、ページ上の「レビュー・サマリー」ウィジェットを格納するコンテナを定義しています。「レビュー・サマリー」ウィジェット・タグのこのインスタンスに「レビュー」ウィジェットのリソースIDを指定した場合、この行にも「レビュー」ウィジェットのリソースIDを指定します。例:

<div id= "reviews_summary_container[resource_id]></div>

[resource_id]は、目的の「レビュー」ウィジェットのリソースIDです。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「レビュー・サマリー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「レビュー・サマリー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「レビュー・サマリー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「レビュー・サマリー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「レビュー・サマリー」ウィジェット・タグ(reviews-summary)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-7 Webページに表示された「レビュー・サマリー」ウィジェット

85.2.3 「トピックへのリンク」ウィジェット・タグ

「トピックへのリンクのデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「トピックへのリンク」を選択してアクセスできる)では、デザイナに「トピックへのリンク」ウィジェット・タグが提供されます。この項では、「トピックへのリンク」ウィジェット・タグで定義されているパラメータを分析します。

「トピックへのリンク」ウィジェット・タグ

1. <a href="[resource_url]#reviews_link&resource_id=[resource_id]" ></a>

2. <div id="comments_link_div[random]"></div>

3. <script type="text/javascript">

4. cos = window.cos || {};

5. cos.pageWidgets = cos.pageWidgets || [];

6. cos.pageWidgets.push({name: "comments-link",

7. version: "0.1",

8. elementID: "comments_link_div[random]",

9. attributes: {"site_id":'FirstSiteII'}});

10. cos.pageScripts = cos.pageScripts || [];

11. cos.pageScripts.push('comments-link');

12. (function()

13. {

14. var oldOnloadHandler = window.onload || function()

15. {

16. };

17. if (!oldOnloadHandler.alreadyProcessed)

18. {

19. window.onload = function()

20. {

21. var script = document.createElement('script');

22. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

23. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

24. script.type = 'text/javascript';

25. script.charset = 'utf-8';

26. document.getElementsByTagName("head").item(0) .appendChild(script);

27. oldOnloadHandler.apply(this, arguments);

28. };

29. window.onload.alreadyProcessed = true;

30. }

31. })();

32. </script>

「トピックへのリンク」ウィジェット・タグの分析

- 行1は、目的の「レビュー」ウィジェット・タグがデプロイされるWebページへのリンクであり、「トピックへのリンクのデプロイメント」画面の「リソースID」フィールドおよび「リソースURL」フィールドに値を入力するとタグに自動的に追加されます。

- 行2は、ページ上の「トピックへのリンク」ウィジェットを格納するコンテナを定義しています。

- 行3は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行4は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行5は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行6から9は、「トピックへのリンク」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行5で定義)に新しいエレメントを追加しています。行8には、行2で定義されているコンテナの内部に「トピックへのリンク」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行10は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行11は、「トピックへのリンク」ウィジェット・タグ(comments-link)をページ・スクリプトのリスト(行10で定義)に追加しています。

- 行14は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックが存在しない場合、この関数は空のままになります。

- 行17は、onload関数がすでに処理されているかどうかをチェックしています。

- 行19は、ページのロード時に実行されるコードをオーバーライドしています。

- 行21から26は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトが含まれます。

- 行27は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行29は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行32は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

85.2.3.1 「トピックへのリンク」ウィジェット・タグ(「レビュー」用)のデプロイ

「トピックへのリンク」ウィジェットを構成して、「レビュー」ウィジェットまたは「コメント」ウィジェット(あるいはその両方)がデプロイされる複数のWebページのサマリー情報およびそれらのページへのリンクを表示するには、目的のWebページにデプロイされる各「レビュー」ウィジェットまたは「コメント」ウィジェット(あるいはその両方)のリソースIDおよびリソースURLを、「トピックへのリンク」ウィジェット・タグに挿入する必要があります。

注意:

「レビュー」ウィジェットと「コメント」ウィジェットは、同一の「トピックへのリンク」ウィジェット・タグの中で指定できます。「コメント」ウィジェットの指定の詳細は、第85.1.3.1項「「トピックへのリンク」ウィジェット・タグ(「コメント」用)のデプロイ」を参照してください。

例:

1. メニュー・バーで、「レビュー」→「デプロイ」→「トピックへのリンク」を選択します。

2. 「トピックへのリンクのデプロイメント」画面で、「トピックへのリンク」ウィジェット・タグをコピー([Ctrl]+[C])します。

3. WebCenter SitesのAdminインタフェースにアクセスし、「トピックへのリンク」ウィジェット・タグを目的のテンプレートに挿入します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

4. 「トピックへのリンク」ウィジェット・タグの行1に、「トピックへのリンク」ウィジェットによってサマリー情報とリンクが表示される、デプロイ済の各「レビュー」ウィジェットまたは「コメント」ウィジェット(あるいはその両方)のリソースIDとリソースURLを指定します。例:
「トピックへのリンク」ウィジェット・タグ内で指定するすべての「レビュー」ウィジェットで、次の行を追加します。

<a href="http://URL#reviews_link&resource_id+ReviewsID"></a>

http://URLは、目的の「レビュー」ウィジェットのデプロイ先であるWebページのパスです。

5. 「変更の保存」をクリックします。

6. ページのプレビューを行い、Webサイトにテンプレートを公開します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』および『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

図85-8 Webページに表示された「トピックへのリンク」ウィジェット

注意:

「トピックへのリンク」ウィジェットをデプロイしても、タイトルは表示されません。「トピックへのリンク」ウィジェットでタイトルを表示するには、「トピックへのリンク」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.2.4 「平均評価のレビュー」ウィジェット・タグ

「レビューの平均評価のデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「平均評価」を選択してアクセスできる)では、デザイナに「平均評価のレビュー」ウィジェット・タグが提供されます。この項では、「平均評価のレビュー」ウィジェット・タグで定義されているパラメータを分析します。

「平均評価のレビュー」ウィジェット・タグ

1. <divid="reviews_average_container[resource_id]"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.reviews_average",

6. version: "1.5",

7. elementID: "reviews_average_container[resource_id]",

8. attributes: {"site_id":"FirstSiteII","resource_id":"[resource_id]"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined')||(typeof(wsdk.reviews_average) == 'undefined')) {document.getElementById('reviews_average_container[resource_id]').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Reviews Average Rating is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.reviews_average');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「平均評価のレビュー」ウィジェット・タグの分析

- 行1は、ページ上の「平均評価のレビュー」ウィジェットを保持するコンテナを定義しています。Webページにデプロイされる「レビュー」ウィジェットのリソースIDを指定する必要があります。　その平均評価は、「平均評価のレビュー」ウィジェットに表示されます。例:

<div id="reviews_average_container[resource_id]"></div>

[resource_id]は、目的の「レビュー」ウィジェットのリソースIDです。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「平均評価のレビュー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「平均評価のレビュー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「平均評価のレビュー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「平均評価のレビュー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「平均評価のレビュー」ウィジェット・タグ(wsdk.reviews_average)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックが存在しない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

85.2.5 「上位ランクのレビュー」ウィジェット・タグ

「上位ランクのレビューのデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「上位ランクのトピック」を選択してアクセスできる)では、デザイナに「上位ランクのレビュー」ウィジェット・タグが提供されます。この項では、「上位ランクのトピック」ウィジェット・タグで定義されているパラメータを分析します。

「上位ランクのレビュー」ウィジェット・タグ

1. <div id="topics_container_top_ranked_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_top_ranked_other",

8. attributes: {"content_type":"top_ranked","site_id":"FirstSiteII","resource_type":"other","rating_type":"stars"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_top_ranked_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「上位ランクのレビュー」ウィジェット・タグの分析

- 行1は、ページ上の「上位ランクのレビュー」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「上位ランクのレビュー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「上位ランクのレビュー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「上位ランクのレビュー」ウィジェットがリストするトピックのタイプを含め、「上位ランクのレビュー」ウィジェット・タグの設定を指定しています。「上位ランクのレビュー」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「上位ランクのレビュー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「上位ランクのレビュー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「上位ランクのレビュー」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-9 Webページに表示された「上位ランクのレビュー」ウィジェット

85.2.6 「最近レビューされた」ウィジェット・タグ

「最近レビューされたデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「最近レビューされた」を選択してアクセスできる)では、デザイナに「最近レビューされた」ウィジェット・タグが提供されます。この項では、「最近レビューされた」ウィジェット・タグで定義されているパラメータを分析します。

「最近レビューされた」ウィジェット・タグ

1. <div id="topics_container_recently_reviewed_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_recently_reviewed_other",

8. attributes: {"content_type":"recently_reviewed","site_id":"FirstSiteII","resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_recently_reviewed_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最近レビューされた」ウィジェット・タグの分析

- 行1では、ページ上の「最近レビューされた」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェット・タグがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最近レビューされた」ウィジェット・タグを定義し、ウィジェット・タグのリスト(4行で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最近レビューされた」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最近レビューされた」ウィジェットがリストするトピックのタイプを含め、「最近レビューされた」ウィジェット・タグの設定を指定しています。「最近レビューされた」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最近レビューされた」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最近レビューされた」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「最近レビューされた」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-10 Webページに表示された「最近レビューされた」ウィジェット

注意:

「最近レビューされた」ウィジェットをデプロイしても、タイトルは表示されません(図85-10を参照)。「最近レビューされた」ウィジェットでタイトルを表示するには、「最近レビューされた」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.2.7 「最もレビューされている」ウィジェット・タグ

「最もレビューされているデプロイメント」画面(メニュー・バーから「レビュー」→「デプロイ」→「最もレビューされている」を選択してアクセスできる)では、デザイナに「最もレビューされている」ウィジェット・タグが提供されます。この項では、「最もレビューされている」ウィジェット・タグで定義されているパラメータを分析します。

「最もレビューされている」ウィジェット・タグ

1. <div id="topics_container_most_reviewed_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_most_reviewed_other",

8. attributes: {"content_type":"most_reviewed","site_id":"FirstSiteII","resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_most_reviewed_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最もレビューされている」ウィジェット・タグの分析

- 行1は、ページ上の「最もレビューされている」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最もレビューされている」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最もレビューされている」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最もレビューされている」ウィジェットがリストするトピックのタイプを含め、「最もレビューされている」ウィジェット・タグの設定を指定しています。「最もレビューされている」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最もレビューされている」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最もレビューされている」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。そのようなスクリプトがデプロイされていない場合、このリストの値は空になります。

- 行13は、「最もレビューされている」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-11 Webページに表示された「最もレビューされている」ウィジェット

注意:

「最もレビューされている」ウィジェットをデプロイしても、タイトルは表示されません(図85-11を参照)。「最もレビューされている」ウィジェットにタイトルを表示するには、「最もレビューされている」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.3 「評価」のウィジェット・タグ

ここでは、Webサイトへの評価機能の追加に関連するウィジェット・タグを紹介します。

- 第85.3.1項「「星評価」ウィジェット・タグ」

- 第85.3.2項「「サムズ・アップ/ダウン評価」ウィジェット・タグ」

- 第85.3.3項「「Like評価」ウィジェット・タグ」

- 第85.3.4項「「お薦め評価」ウィジェット・タグ」

- 第85.3.5項「「評価の平均評価」ウィジェット・タグ」

- 第85.3.6項「「最近評価された」ウィジェット・タグ」

- 第85.3.7項「「最も評価が高い」ウィジェット・タグ」

85.3.1 「星評価」ウィジェット・タグ

「星評価のデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「星評価」を選択してアクセスできる)では、デザイナに「星評価」ウィジェット・タグが提供されます。この項では、「星評価」ウィジェット・タグで定義されているパラメータを分析します。

「星評価」ウィジェット・タグ

1. <div id="ratingsstars_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.ratings",

6. version: "1.5",

7. elementID: "ratingsstars_container",

8. attributes: {"rating_type":"stars","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.ratings) == 'undefined')) {document.getElementById('ratings_stars_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Ratings is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.ratings');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「星評価」ウィジェット・タグの分析

- 行1は、ページ上の「星評価」ウィジェットを格納するコンテナを定義しています。「星評価」ウィジェット・タグのこのインスタンスにリソースIDを割り当てた場合、この行にもウィジェットのリソースIDを指定します。例:

<divid="ratingsstars_container[resource_id]"></div>

[resource_id]は、「星評価」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェット・タグのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「星評価」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「星評価」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「星評価」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「星評価」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「星評価」ウィジェット・タグ(wsdk.ratings)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-12 Webページにデプロイされた「星評価」ウィジェット

85.3.2 「サムズ・アップ/ダウン評価」ウィジェット・タグ

「サムズ・アップ/ダウン評価のデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「サムズ・アップ/ダウン評価」を選択してアクセスできる)では、デザイナに「サムズ・アップ/ダウン評価」ウィジェット・タグが提供されます。この項では、「サムズ・アップ/ダウン評価」ウィジェット・タグで定義されているパラメータを分析します。

「サムズ・アップ/ダウン評価」ウィジェット・タグ

1. <div id="ratingsthumbs_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.ratings",

6. version: "1.5",

7. elementID: "ratingsthumbs_container",

8. attributes: {"rating_type":"thumbs","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.ratings) == 'undefined')) {document.getElementById('ratings_thumbs_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Ratings is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.ratings');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「サムズ・アップ/ダウン評価」ウィジェット・タグの分析

- 行1は、ページ上の「サムズ・アップ/ダウン評価」ウィジェットを格納するコンテナを定義しています。「サムズ・アップ/ダウン評価」ウィジェットのこのインスタンスにリソースIDを割り当てた場合、この行にもそのリソースIDを指定します。例:

<div id="ratingsthumbs_container[resource_id]"></div>

[resource_id]は、「サムズ・アップ/ダウン評価」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェット・タグのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「サムズ・アップ/ダウン評価」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「サムズ・アップ/ダウン評価」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「サムズ・アップ/ダウン評価」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「サムズ・アップ/ダウン評価」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「サムズ・アップ/ダウン評価」ウィジェット・タグ(wsdk.ratings)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-13 Webページに表示された「サムズ・アップ/ダウン評価」ウィジェット

85.3.3 「Like評価」ウィジェット・タグ

「Like評価のデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「Like評価」を選択してアクセスできる)では、デザイナに「Like評価」ウィジェット・タグが提供されます。この項では、「Like評価」ウィジェット・タグで定義されているパラメータを分析します。

「Like評価」ウィジェット・タグ

1. <div id="ratingslike_it_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.ratings",

6. version: "1.5",

7. elementID: "ratingslike_it_container",

8. attributes: {"rating_type":"like_it","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.ratings) == 'undefined')) {document.getElementById('ratingslike_it_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Ratings is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.ratings');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「Like評価」ウィジェット・タグの分析

- 行1は、ページ上の「Like評価」ウィジェットを格納するコンテナを定義しています。「Like評価」ウィジェットのこのインスタンスにリソースIDを割り当てた場合、この行にもウィジェットのリソースIDを指定します。例:

<div id="ratingslike_it_container[resource_id]"></div>

[resource_id]は、「Like評価」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェット・タグのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「Like評価」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「Like評価」ウィジェット・タグをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「Like評価」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「Like評価」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「Like評価」ウィジェット・タグ(wsdk.ratings)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-14 Webページに表示された「Like評価」ウィジェット

85.3.4 「お薦め評価」ウィジェット・タグ

「お薦め評価のデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「お薦め評価」を選択してアクセスできる)では、デザイナに「お薦め評価」ウィジェット・タグが提供されます。この項では、「お薦め評価」ウィジェット・タグで定義されているパラメータを分析します。

「お薦め評価」ウィジェット・タグ

1. <div id="ratingsrecommend_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.ratings",

6. version: "1.5",

7. elementID: "ratingsrecommend_container",

8. attributes: {"rating_type":"recommend","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.ratings) == 'undefined')) {document.getElementById('ratingsrecommend_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Ratings is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.ratings');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「お薦め評価」ウィジェット・タグの分析

- 行1は、ページ上の「お薦め評価」ウィジェットを格納するコンテナを定義しています。「お薦め評価」ウィジェットのこのインスタンスにリソースIDを割り当てた場合、この行にもウィジェットのリソースIDを指定します。例:

<div id="ratingsrecommend_container[resource_id]"></div>

[resource_id]は、「お薦め評価」ウィジェットのこのインスタンスに割り当てられたリソースIDです。

注意:

このウィジェット・タグのリソースIDを指定しないと、このウィジェット・タグがデプロイされるページの暗号化されたURLがウィジェットのリソースIDとして割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「お薦め評価」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「お薦め評価」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「お薦め評価」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「お薦め評価」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「お薦め評価」ウィジェット・タグ(wsdk.ratings)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-15 Webページに表示された「お薦め評価」ウィジェット

85.3.5 「評価の平均評価」ウィジェット・タグ

「評価の平均評価のデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「平均評価」を選択してアクセスできる)では、デザイナに「評価の平均評価」ウィジェット・タグが提供されます。この項では、「評価の平均評価」ウィジェット・タグで定義されているパラメータを分析します。

「評価の平均評価」ウィジェット・タグ

1. <div id="ratings_average_container[resource_id]"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.ratings_average",

6. version: "1.5",

7. elementID: "ratings_average_container[resource_id]",

8. attributes: {"site_id":"FirstSiteII","resource_id":"[resource_id]"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined')||(typeof(wsdk.ratings_average) == 'undefined')) {document.getElementById('ratings_average_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Average Rating is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.ratings_average');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「評価の平均評価」ウィジェット・タグの分析

- 行1は、ページ上の「評価の平均評価」ウィジェットを格納するコンテナを定義しています。Webページにデプロイされる「星評価」ウィジェット・タグのリソースIDを指定する必要があります。その平均評価は、「評価の平均評価」ウィジェットに表示されます。例:

<div id="ratings_average_container[resource_id]"></div>

[resource_id]は、Webページにデプロイされる「星評価」ウィジェットのリソースIDです。このウィジェットの平均評価が、「評価の平均評価」ウィジェットによって表示されます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「評価の平均評価」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7は、行1で定義されているコンテナの内部に「評価の平均評価」ウィジェット・タグをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「評価の平均評価」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「評価の平均評価」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「評価の平均評価」ウィジェット・タグ(wsdk.ratings_average)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックが存在しない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

85.3.6 「最近評価された」ウィジェット・タグ

「最近評価されたデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「最近評価された」を選択してアクセスできる)では、デザイナに「最近評価された」ウィジェット・タグが提供されます。この項では、「最近評価された」ウィジェット・タグで定義されているパラメータを分析します。

「最近評価された」ウィジェット・タグ

1. <div id="topics_container_recently_rated_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_recently_rated_other",

8. attributes: {"content_type":"recently_rated","site_id":"FirstSiteII","resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_recently_rated_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最近評価された」ウィジェット・タグの分析

- 行1は、ページ上の「最近評価された」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最近評価された」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最近評価された」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最近評価された」ウィジェットがリストするトピックのタイプを含め、「最近評価された」ウィジェット・タグの設定を指定しています。「最近評価された」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最近評価された」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最近評価された」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「最近評価された」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-16 Webページに表示された「最近評価された」ウィジェット

注意:

「最近評価された」ウィジェットをデプロイしても、タイトルは表示されません(図85-16を参照)。「最近評価された」ウィジェットにタイトルを表示するには、「最近評価された」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.3.7 「最も評価が高い」ウィジェット・タグ

「最も評価が高いデプロイメント」画面(メニュー・バーから「評価」→「デプロイ」→「最も評価が高い」を選択してアクセスできる)では、デザイナに「最も評価が高い」ウィジェット・タグが提供されます。この項では、「最も評価が高い」ウィジェット・タグで定義されているパラメータを分析します。

「最も評価が高い」ウィジェット・タグ

1. <div id="topics_container_most_rated_other"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.topics",

6. version: "1.5",

7. elementID: "topics_container_most_rated_other",

8. attributes: {"content_type":"most_rated","site_id":"FirstSiteII"'"resource_type":"other"}});

9. setTimeout(

10. function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.topics) == 'undefined')) {document.getElementById('topics_container_most_rated_other').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Topics is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.topics');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「最も評価が高い」ウィジェット・タグの分析

- 行1は、ページ上の「最も評価が高い」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「最も評価が高い」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「最も評価が高い」ウィジェットをレンダリングする際に使用されるリンクが含まれています。行8は、「最も評価が高い」ウィジェットがリストするトピックのタイプを含め、「最も評価が高い」ウィジェット・タグの設定を指定しています。「最も評価が高い」ウィジェットにリスト内のすべてのタイプのトピックを含める場合は、"resource_type":"other"パラメータを削除します。

- 行9から11は、「最も評価が高い」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「最も評価が高い」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「最も評価が高い」ウィジェット・タグ(wsdk.topics)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-17 Webページに表示された「最も評価が高い」ウィジェット

注意:

「最も評価が高い」ウィジェットをデプロイしても、タイトルは表示されません(図85-17を参照)。「最も評価が高い」ウィジェットにタイトルを表示するには、「最も評価が高い」ウィジェット・タグのコピー先のテンプレートにタイトルを挿入する必要があります。

85.4 「ログイン・バー」のウィジェット・タグ

「ログイン・バーのデプロイメント」画面(メニュー・バーから「ログイン・バー」→「デプロイ」を選択してアクセスできる)では、デザイナに「ログイン・バー」ウィジェット・タグが提供されます。この項では、「ログイン・バー」ウィジェット・タグで定義されているパラメータを分析します。

「ログイン・バー」ウィジェット・タグ

1. <div id="session_box_container"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "wsdk.session",

6. version: "0.1",

7. elementID: "session_box_container",

8. attributes:{"view_type":"short","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(session_box) == 'undefined') || (typeof(session_box.v0_1) == 'undefined')) {document.getElementById('session_box_container').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Login Bar is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('wsdk.session');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「ログイン・バー」ウィジェット・タグの分析

- 行1は、ページ上の「ログイン・バー」ウィジェットを格納するコンテナを定義しています。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「ログイン・バー」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「ログイン・バー」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「ログイン・バー」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「ログイン・バー」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「ログイン・バー」ウィジェット・タグ(session-box)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-18 Webページに表示されたスタンドアロンの「ログイン・バー」ウィジェット

85.5 「投票」のウィジェット・タグ

「投票名の投票のデプロイ」画面(メニュー・バーから「投票」→「すべての投票」→「目的の投票への移動」→「デプロイ」を選択してアクセスできる)では、デザイナに特定の投票の「投票」ウィジェット・タグと「結果」ウィジェット・タグが提供されます。この項では、次のウィジェット・タグで定義されているパラメータを分析します。

- 第85.5.1項「メインの「投票」ウィジェット・タグ」

- 第85.5.2項「「投票結果」ウィジェット・タグ」

85.5.1 メインの「投票」ウィジェット・タグ

「投票タグ」はメインの「投票」ウィジェット・タグであり、デプロイする投票のすべての構成が格納されます。

「投票タグ」ウィジェット・タグ

1. <div id="poll_container1322111446303"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "poll",

6. version: "0.1",

7. elementID: "poll_container1322111446303",

8. attributes: {"poll_id":"1322111446303","uid":"35b48e18-f1c7-4e97-ab1a-98cea2564f66","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(poll) == 'undefined') || (typeof(poll.v1_0) == 'undefined')) {document.getElementById('poll_container1322111446303').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Poll is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('poll');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg/wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「投票タグ」ウィジェット・タグの分析

- 行1は、ページ上の「投票」ウィジェットを格納するコンテナを定義しています。また、この行はデプロイする「投票」ウィジェットの一意の識別子を指定しています。各投票には、作成時に一意の識別子が自動的に割り当てられます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「投票」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「投票」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、「投票」ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても「投票」ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。デプロイされているスクリプトが存在しない場合、このリストの値は空になります。

- 行13は、「投票」ウィジェット・タグ(poll)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28では、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるすべてのスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-19 Webページに表示された「投票」ウィジェット

85.5.2 「投票結果」ウィジェット・タグ

「結果タグ」には、メインの投票結果のサマリーが含まれます(第85.5.1項「メインの「投票」ウィジェット・タグ」)。この結果は、サイトの訪問者が投票を行うことによって動的に変化します。

「結果」ウィジェット・タグ

1. <div id="poll_summary_container1322111446303"></div>

2. <script type="text/javascript">

3. cos = window.cos || {};

4. cos.pageWidgets = cos.pageWidgets || [];

5. cos.pageWidgets.push({name: "poll-summary",

6. version: "0.1",

7. elementID: "poll_summary_container1322111446303",

8. attributes: {"poll_id":"1322111446303","uid":"35b48e18-f1c7-4e97-ab1a-98cea2564f66","site_id":"FirstSiteII"}});

9. setTimeout(

10. function(){if ((typeof(poll) == 'undefined') || (typeof(poll.v1_0) == 'undefined')) {document.getElementById('poll_summary_container1322111446303').innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva, sans-serif;font-size: 12px;color: #333333;border: 1px solid #dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Poll is unavailable right now. Please contact the site administrator.</div>";}}

11. ,30000);

12. cos.pageScripts = cos.pageScripts || [];

13. cos.pageScripts.push('poll');

14. (function()

15. {

16. var oldOnloadHandler = window.onload || function()

17. {

18. };

19. if (!oldOnloadHandler.alreadyProcessed)

20. {

21. window.onload = function()

22. {

23. var script = document.createElement('script');

24. script.src = 'http://prod-cg.example.com:8080/cg//wsdk/widget/'

25. + cos.pageScripts.join(':') + '.js?site_id=FirstSiteII';

26. script.type = 'text/javascript';

27. script.charset = 'utf-8';

28. document.getElementsByTagName("head").item(0) .appendChild(script);

29. oldOnloadHandler.apply(this, arguments);

30. };

31. window.onload.alreadyProcessed = true;

32. }

33. })();

34. </script>

「結果」ウィジェット・タグの分析

- 行1は、ページ上の「結果」ウィジェットを格納するコンテナを定義しています。また、この行は「結果」ウィジェットに関連付けられる投票の一意の識別子を指定しています。「結果」ウィジェットには、この行に指定された一意の識別子を持つ投票の結果が表示されます。

- 行2は、ウィジェットで必要になるブートストラップ用のJavaScriptコードを開始しています。

- 行3は、ページのcosオブジェクトを定義しています。cosオブジェクトには、Communityアプリケーションのすべての機能が含まれます。ページにCommunityのウィジェット・タグがデプロイされていない場合、cosオブジェクトの値は空になります。

- 行4は、ページにデプロイされているウィジェット・タグのリストを定義しています。ページにウィジェットがデプロイされていない場合、このリストの値は空になります。

- 行5から8は、「結果」ウィジェット・タグを定義し、ウィジェット・タグのリスト(行4で定義)に新しいエレメントを追加しています。行7には、行1で定義されているコンテナの内部に「結果」ウィジェットをレンダリングする際に使用されるリンクが含まれています。

- 行9から11は、投票結果ウィジェットがページ上でレンダリングされているかどうかをチェックしています。30秒たっても投票結果ウィジェットがレンダリングされない場合は、エラーが発生したことがユーザーに知らされ、サイトの管理者に連絡するように指示するメッセージが表示されます。

- 行12は、ページにデプロイされているスクリプトのリストを定義しています。スクリプトがデプロイされていない場合、このリストの値は空になります。

- 行13は、「結果」ウィジェット・タグ(poll)をページ・スクリプトのリスト(行12で定義)に追加しています。

- 行16は、ページにデプロイ済のロジックの中で、そのページがロードされた後に開始するものが存在するかどうかをチェックしています。そのようなロジックがページにデプロイされている場合、この行はそのロジックを実装する関数を定義します。そのようなロジックがデプロイされていない場合、この関数は空のままになります。

- 行19は、onload関数がすでに処理されているかどうかをチェックしています。

- 行21では、ページのロード時に実行されるコードをオーバーライドしています。

- 行23から28は、ページにJavaScriptタグを追加しています。その中には、デプロイする必要のあるスクリプトのリストが含まれます。

- 行29は、古いonload関数に、新しいonload関数コールと必要なすべての引数を追加しています。

- 行31は、onload関数が再度処理されるのを防ぐためのalreadyProcessed変数を定義しています。

- 行34では、ウィジェットで必要になるブートストラップ用のJavaScriptコードを終了しています。

図85-20 Webページに表示された「結果」ウィジェット

86 Community-Gadgets: CommunityウィジェットでのSEOサポートの有効化

この章では、SEOサポートに関する情報を提供し、WebサイトでSEOサポートを有効にする方法について説明します。

この章には次の項が含まれます。

- 第86.1項「概要」

- 第86.2項「SEOサポートの有効化」

86.1 概要

Communityのウィジェット・タグは、JavaScriptコードをベースとしています。JavaScriptを無効にしているブラウザでは、Communityウィジェットは一切表示されません。SEOサポートを有効にすることによって、JavaScriptを無効にしているブラウザでも訪問者のコメントやレビューを参照できるようになります。ただし、訪問者によるコメントやレビューへのアクセスは読取り専用になります。他のすべてのウィジェット、およびウィジェットの機能は非表示のままです。

また、SEOサポートによって、Googleなどの検索エンジンがWebサイトのコメントやレビューのコンテンツ内から検索用語を検出できるようになります。コメントやレビューに検索用語が含まれている場合、検索エンジンは検索結果のリストに、それらのコメントやレビューが投稿されたWebページへのリンクを表示します。

86.2 SEOサポートの有効化

SEOサポートの有効化に使用するフィールドは、「コメント」ウィジェット・タグおよび「レビュー」ウィジェット・タグのカスタム・デプロイメント画面の下部にあります。次に、「コメント」ウィジェット・タグのデプロイメント画面のSEOに関するフィールドを示します(「レビュー」ウィジェット・タグのカスタム・デプロイメント画面にも同じSEOフィールドがあります)。

SEOサポートを有効にするには

1. 「コメント」ウィジェット・タグまたは「レビュー」ウィジェット・タグのカスタム・デプロイメント画面にアクセスします。メニュー・バーで、次のいずれかを実行します。

- カスタムの「コメントのデプロイメント」画面にアクセスするには、「コメント」→「デプロイ」→「コメント」→「カスタム設定」を選択します。

- カスタムの「レビューのデプロイメント」画面にアクセスするには、「レビュー」→「デプロイ」→「レビュー」→「カスタム設定」を選択します。

2. 「リソースID」フィールドに、「コメント」ウィジェットまたは「レビュー」ウィジェットのリソースIDを指定します。SEO用のサーバー側のタグは指定したリソースIDを継承します。

3. アプリケーション・サーバーのクラスパス(たとえばWEB-INF/lib)に、cos-widget-tag.jarファイルを置きます。

1. 「ウィジェット・タグ」フィールドで、「SEOウィジェット・ファイルのダウンロード」をクリックし、SEOウィジェット・ファイル(cos-widget-tag.jar)をダウンロードします。

2. SEOウィジェット・ファイル(cos-widget-tag.jar)をアプリケーション・サーバーのクラスパスに置きます。
このjarファイルは、SEO用のサーバー側のタグ機能を定義しています。このjarファイルがないと、SEOサポートを有効にできません。

4. 「コメント」(または「レビュー」)ウィジェットがデプロイされるページに、SEO用のサーバー側のタグをデプロイします。

1. 「SEO用のサーバー側のタグ」フィールドにタグをコピー([Ctrl]+[C])します。

2. 「コメント」(または「レビュー」)ウィジェット・タグを挿入したテンプレートにアクセスし、その「コメント」(または「レビュー」)ウィジェット・タグのすぐ下に「SEO用のサーバー側のタグ」フィールドを挿入します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。
SEO用のサーバー側のタグは、WebページでSEOサポートを有効にするためのメイン・タグです。

5. SEO用のCSSタグをデプロイします。訪問者のブラウザでJavaScriptが無効になっている場合にWebページのコメントおよびレビューを適切なレイアウトで表示するには、このタグが必要です。次を実行します。

1. 「SEO用のCSSタグ」フィールドにタグをコピー([Ctrl]+[C])します。

2. 「コメント」(または「レビュー」)ウィジェット・タグを挿入したテンプレートにアクセスし、そのテンプレートのソース・コードの<head</headタグの間にSEO用のCSSタグを挿入します。手順は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。
SEO用のCSSタグは、「コメント」ウィジェットおよび「レビュー」ウィジェットに対して構成されている外観設定を継承します。このタグがデプロイされると、WebページにリストされるコメントおよびレビューにJavaScriptフォーマットが適用されます。

6. テンプレートを公開します。手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

7. SEOサポートが正常に有効化されていることを確認します。JavaScriptを無効にしたブラウザを使用してWebサイトにアクセスし、「コメント」(または「レビュー」)ウィジェットがデプロイされているWebページを表示します。

87 Community-Gadgets: CSSタグのデプロイ

この章では、CSSタグに関する情報を提供し、Webページにこのタグをデプロイする方法について説明します。

この章には次の項が含まれます。

- 第87.1項「概要」

- 第87.2項「CSSタグのデプロイ」

87.1 概要

各ウィジェットおよびガジェットには、Webページにデプロイされたウィジェットやガジェットに希望するルック・アンド・フィールを適用する固有のCSSが含まれます。ウィジェットまたはガジェットのCSSは、そのウィジェットまたはガジェットがデプロイされるWebページに対してリクエストが作成されたときにロードされます。複数のウィジェットおよびガジェットが同一ページにデプロイされる場合、システムは各ウィジェットおよびガジェットのCSSを個別にロードするため、Webページのロード時間が長くなります。

複数のウィジェットやガジェットがデプロイされているWebページのロード時間を短縮するため、CommunityおよびGadgetsのアプリケーションではCSSタグが提供されています。CSSタグをデプロイすると、そのページにデプロイされているウィジェットおよびガジェットのすべてのCSSファイルが1つのCSSに結合されます。これにより、各ウィジェットおよびガジェットのCSSが一度にロードされ、システムがページのコンテンツをロードする際に発行するリクエストの数が減少します。つまり、ページにデプロイされているウィジェットおよびガジェットのすべてのCSSファイルをCommunityおよびGadgetsアプリケーションがロードする時間が短縮されます。

87.2 CSSタグのデプロイ

すべてのウィジェットおよびガジェットのデプロイメント画面には、「CSSタグ」フィールドがあります。このシナリオでは、「コメントのデプロイメント」画面(「コメント」→「デプロイ」→「コメント」)でCSSタグを使用します。

特定のWebページにデプロイされているウィジェットおよびガジェットのすべてのCSSファイルがCSSタグによってロードされるためには、CSSタグを構成して、ページにロードされるウィジェット、ガジェットおよび関連するCSSファイルを指定する必要があります。ページがリクエストされると、Community-GadgetsアプリケーションはCSSタグのコードをスキャンし、CSSタグ内に指定されているすべてのウィジェットおよびガジェットのCSSファイルを一度にリクエストします。

注意:

ページにデプロイされているウィジェットまたはガジェットがCSSタグ内に指定されていない場合、そのウィジェットまたはガジェットのCSSはロードされません。

次に、「コメントのデプロイメント」画面の「CSSタグ」フィールドを示します(他のすべてのウィジェットおよびガジェットのデプロイメント画面にも、同様の「CSSタグ」フィールドがあります)。

CSSタグを構成してデプロイするには

1. ウィジェット・タグまたはガジェットのデプロイメント画面にアクセスします。この例では、「コメントのデプロイメント」画面にアクセスします。

2. 「CSSタグ」フィールドにCSSタグをコピー([Ctrl]+[C])します。

3. WebCenter SitesのAdminインタフェースにアクセスし、目的のWebページをレンダリングするテンプレートにCSSタグを挿入します。

1. メニュー・バーで、画面の右端にある下矢印アイコンをポイントし、アプリケーション・バーをレンダリングします。

2. アプリケーション・バーで、「管理」アイコンをクリックし、WebCenter SitesのAdminインタフェースをレンダリングします。

3. CSSタグを挿入するテンプレートを見つけます。

1. スタート・メニューのオプションから、「検索」をクリックします。

2. 「検索結果」リストで、「テンプレートの検索」を選択します。

3. 「テンプレートの検索」フォームで、「検索」をクリックします。

4. 「テンプレートのリスト」フォームで、ウィジェット・タグを挿入するテンプレートを選択します。

5. テンプレートの「調査」フォームで、「編集」をクリックします。

6. テンプレートの「エレメント」画面で、<head></head>タグの間の「エレメント・ロジック」フィールドにウィジェット・タグを挿入([Ctrl]+[V])します。例:

<head>
<link id="cos_css" type="text/css"rel="stylesheet" href="http://prod-cg.example.com:8080/cg/wsdk/skin/wsdk.comments.css?site_id=FirstSiteII&gateway=true" />
...
</head>

4. CSSタグ内に、ページとともにロードされる各ウィジェット、ガジェットおよびCSSファイルを指定します。例:
CSSタグによって、「コメント」、「レビュー」、「投票」、「ログイン・バー」の各ウィジェットのCSSファイル、および単一ガジェットのCSSファイルがロードされる場合、CSSタグを次のように変更する必要があります。

<link id="cos_css" type="text/css" rel="stylesheet" href="http://prod-cg.example.com:8080/cg/wsdk/skin/wsdk.comments:wsdk.reviews:poll:wsdk.session:gadgets_dashboard.css?site_id=FirstSiteII&gateway=true" />

ここで:

- wsdk.comments: 「コメント」ウィジェットの名前。

- wsdk.reviews: 「レビュー・サマリー」ウィジェットの名前。

- poll: 「投票」ウィジェットおよび「投票結果」ウィジェットの名前。

- wsdk.session: 「ログイン・バー」ウィジェットの名前。

- gadgets_dashboard: 単一ガジェットの名前。

CSSのhrefタグは、ページにデプロイされているウィジェットおよびガジェット用にロードされるCSSファイルの場所を参照します。各ウィジェットおよびガジェットの名前はコロンで区切ります。

それぞれのウィジェットの名前は、ウィジェットのデプロイメント画面のCSSタグ内にあります。ウィジェットの名前は次のとおりです。

- wsdk.comments: 「コメント」ウィジェットの名前。

- comments-summary: 「コメント・サマリー」ウィジェットの名前。

- comments-link: コメントおよびレビューの「トピックへのリンク」ウィジェットの名前。

- wsdk.topics: 「最もコメントが多い」、「最近コメントされた」、「最もレビューされている」、「最近レビューされた」、「上位ランク」、「最も評価が高い」、「最近評価された」の各ウィジェットの名前。

- wsdk.reviews: 「レビュー」ウィジェットの名前。

- reviews-summary: 「レビュー・サマリー」ウィジェットの名前。

- wsdk.reviews_average: 「平均評価のレビュー」ウィジェットの名前。

- poll: 「投票」ウィジェットおよび「投票結果」ウィジェットの名前。

- wsdk.ratings: 「星」、「サムズ・アップ/ダウン」、「Like」、「お薦め評価」の各ウィジェットの名前。

- wsdk.ratings_average: 「評価の平均評価」ウィジェットの名前。

- wsdk.session: 「ログイン・バー」ウィジェットの名前。

- gadgets_dashboard: ガジェットの名前。

5. 「変更の保存」をクリックします。

4. テンプレートをWebサイトに公開します。公開の手順は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

第VII部

Community Blogsの開発

この部では、ブログ・データ・モデルのカスタマイズ手順について説明します。また、テンプレート・コードと、各種のCMサイトにおけるブログ機能開発のガイドラインについても説明します。

この部は、次の章で構成されています。

- 第88章「Community Blogs: データ・モデル」

- 第89章「Community Blogs: サンプル・ブログ・ページ」

- 第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」

88 Community Blogs: データ・モデル

この章では、Community Blogsフレックス・ファミリの階層、およびCommunity Blogsモジュールのインストール処理時に作成されるアセットの情報を提供します。

この章には次の項が含まれます。

- 第88.1項「Blogフレックス・ファミリの概要」

- 第88.2項「フレックス・ファミリのメンバー」

88.1 Blogフレックス・ファミリの概要

Blogフレックス・ファミリは、ブログのアセットや作成者を格納するためのデータ構造を提供します。図88-1に、Blogフレックス・ファミリ・メンバーの構造を示します。ブログ・アセットは4レベルの階層に格納されます。

図88-1 ブログ・アセットの階層

- Blog Assetは、Webサイトに表示されるコンテンツ・ユニットの作成に使用されます。

- Blog Categoryは、ブログのカテゴリの名前の指定に使用されます。

- Blog Category Definitionは、ブログのカテゴリの階層順序での配置に使用されます。デフォルトでは、ブログのカテゴリの定義は、GrandParentBlogCategory(第1レベル)、ParentBlogCategory(第2レベル)、BlogCategory(第3レベル)になります。

- Blog Asset Definitionは、ブログ・アセットの親の決定に使用されます。デフォルトでは、ブログ・アセットの親はBlogCategoryレベル(第3レベル)のカテゴリです。また、Blog Asset Definitionは、「ブログ・アセット」フォームを構成するブログ属性も指定します。

- Blog Attributeは、「ブログ・アセット」フォームおよび「ブログ作成者」フォームのフィールドとして指定する属性の作成に使用されます。

ブログ作成者は、BlogAuthorsという名前の単一のカテゴリの下にフラットな構造で格納されます。

- Blog Authorは、作成者アセットの作成に使用されます。作成したブログに、作成者の名前(およびオプションでイメージ)が表示されます。

- Blog Author Categoryは、ブログ作成者のカテゴリの名前の指定に使用されます。デフォルトでは、BlogAuthorsという名前の作成者カテゴリが1つのみ存在し、すべての作成者アセットの格納に使用されます。

- Blog Author Category Definitionは、階層順序にブログ作成者カテゴリを配置するために使用されます。デフォルトでは、フラットな構造(すべてのブログ作成者カテゴリが同じレベル)を作成するブログ作成者カテゴリ定義(BlogAuthorCategory)のみが唯一存在します。

- Blog Author Definitionは、BlogAuthorsという名前の親の下での作成者アセットの配置に使用されます。また、Blog Author Definitionは、「ブログ作成者」フォームを構成するブログ属性も指定します。

データ変換にはブログ・フィルタが使用されます。

- Blog Filterは、1つのブログ属性からデータを取り込み、それをなんらかの方法で変換または評価し、ブログ・アセットの保存時に別のブログ属性に結果を格納するために使用されます。ブログ・フィルタのアクションによって得られた値を、導出された属性値といいます。

88.2 フレックス・ファミリのメンバー

この章の残りの部分では、デフォルトのBlogフレックス・ファミリのメンバーについて詳しく説明します。

- 第88.2.1項「デフォルトのブログ属性」

- 第88.2.2項「デフォルトのブログ・カテゴリ定義およびブログ・カテゴリ」

- 第88.2.3項「デフォルトのブログ・アセット定義およびブログ・アセット」

- 第88.2.4項「デフォルトのブログ作成者カテゴリ定義およびブログ作成者カテゴリ」

- 第88.2.5項「デフォルトのブログ作成者定義およびブログ作成者」

- 第88.2.6項「デフォルトのブログ・フィルタ」

88.2.1 デフォルトのブログ属性

Blog Attributeアセット・タイプには、次のデフォルトの属性が格納されます。

- Abstract: ブログ・アセット・フォームの「概要」フィールドを定義します。

- AssetId: ブログ・アセットの親アセットIDの取得に使用されます。ブログ・アセットは同じ親ブログ・カテゴリの下の複数のブログ・カテゴリに割り当てることができるため、現在のブログ・アセットが属するすべてのブログ・カテゴリの検索にこの属性が使用されます。

- Author: ブログ・アセット・フォームの「作成者」フィールドを定義します。

- BlogAuthorFullName: ブログ作成者フォームの「完全な名前」フィールドを定義します。

- BlogAuthorImage: ブログ作成者フォームの「作成者プロファイル・イメージ」フィールドを定義します。

- BlogAuthorImageHeight: アップロードされた作成者イメージのデフォルトの高さの特定に使用されます。

- BlogAuthorImageMimeType: アップロードされた作成者イメージのメディアの種類(jpegや.gifなど)を特定するために、Blog Authorフィルタによって使用されます。

- BlogAuthorImageWidth: アップロードされた作成者イメージのデフォルトの幅の特定に使用されます。

- BlogAuthorLargeThumbImage: ブログ作成者フォームへの作成者イメージの大きなサムネイルのレンダリングに使用されます。

- BlogAuthorLThumbHeight: アップロードされた作成者イメージの大きなサムネイルの適切な高さの指定に使用されます。

- BlogAuthorLThumbWidth: アップロードされた作成者イメージの大きなサムネイルの適切な幅の指定に使用されます。

- BlogAuthorSmallThumbImage: アップロードされた作成者イメージの小さなサムネイルのレンダリングに使用されます。

- BlogAuthorSThumbHeight: アップロードされた作成者イメージの小さなサムネイルの適切な高さの指定に使用されます。

- BlogAuhtorSThumbWidth: アップロードされた作成者イメージの小さなサムネイルの適切な幅の指定に使用されます。

- Body: ブログ・アセット・フォームの「ブログ本文」フィールドを定義します。

- Category: ブログ・アセット・フォームの「ブログ・カテゴリ」フィールドを定義します。

- Date: ブログ・アセット・フォームの「ブログの日時」フィールドを定義します。

- GrandParentCategory: ブログ・アセットが属する最上位カテゴリの取得に使用されます。GrandParentCategoryは、親およびアセットのカテゴリをカプセル化します。

- GrandParentDescription: ブログ・アセットが属する祖父母カテゴリの説明が格納されます。

- ParentCategory: 概念はGrandParentCategoryと同様ですが、親のカテゴリ情報のみが格納されます。

- ParentDescription: ブログ・アセットが属する親カテゴリの説明が格納されます。

デフォルトの属性を使用することによって、所有するサイトでブログ機能を簡単に始めることができます。また、新しい属性を作成したり、デフォルトの属性を変更または削除したりすることによって、要件に適合させることができます。詳細は、第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」の第90.1項「ブログ・アセット・フォームのカスタマイズ」を参照してください。

88.2.2 デフォルトのブログ・カテゴリ定義およびブログ・カテゴリ

Blog Category Definitionアセット・タイプには、GrandParentBlogCategory、ParentBlogCategoryおよびBlogCategoryの定義が格納されます。それぞれの定義では、カテゴリが配置されるレベルが指定されます(図88-2)。

図88-2 カテゴリのレベル

BlogCategoryは、カテゴリの第3レベルを定義します。すべてのブログ・アセットは、BlogCategoryレベルのカテゴリに属します。ブログ・アセットは、同じParentBlogCategoryの下の多くのブログ・カテゴリに属することができます。

Blog Categoryアセット・タイプは、カテゴリに名前を付け、それらを階層順序で配置するために使用されます(これらは前述のブログ・カテゴリの定義を通じて行われます)。Blog Categoryアセット・タイプには、Sports BlogsおよびTechnology Blogsという祖父母カテゴリが含まれます(図88-3を参照)。各祖父母カテゴリには、複数の親カテゴリを含めることができます。各親カテゴリには複数のブログ・カテゴリを含めることができ、各ブログ・カテゴリには複数のブログ・アセットを含めることができます。図88-3は、デフォルトのカテゴリとブログ・アセットを含むサンプル・ツリーです。

注意:

ブログ・アセットでは、単一値属性に複数の個別継承値を持たせることはできません。したがって、ブログ・アセットを複数のブログ・カテゴリに割り当てる場合は、それらのブログ・カテゴリが同一の親ブログ・カテゴリの下にあることを確認してください。

図88-3 サンプル・ブログ・カテゴリの階層

Webサイトのブログ・アセットのブログ・カテゴリを作成する場合、デフォルトのブログ・カテゴリ定義によって定義されている階層を再利用できます。WebCenter Sitesのツリーに、図88-3に示すようなブログ・カテゴリとブログ・アセットの階層を表示するには、ブログ・ツリー・タブを作成する必要があります。ブログ・コンポーネントを有効にする方法については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

88.2.3 デフォルトのブログ・アセット定義およびブログ・アセット

Blogフレックス・ファミリには、1つのブログ・アセットが同じ親ブログ・カテゴリ(第2レベル・カテゴリ)の下の複数のブログ・カテゴリ(第3レベル・カテゴリ)に所属できることを指定するBlogAssetDefという名前の1つのブログ・アセット定義が含まれます。また、BlogAssetDefは、ブログ・アセットのフォームを構成する属性を指定します。

- 概要

- 作成者

- 本文

- 日付

- タイトル

Blog Assetアセット・タイプは、コンテンツ・プロバイダがブログ・アセットを作成する際に入力するフォームを提供します。図88-4には、BlogAssetDefが表示されており、「ブログ・アセット」フォームでそのパラメータがどのように使用されているかが示されています。

図88-4 ブログ・アセット定義とブログ・アセット・フォームの関係

ブログ・アセット・フォーム用の独自の属性を作成するには、それらの属性をデフォルトのブログ・アセット定義に追加する必要があります。新しい属性を作成し、それらをブログ・アセット定義に追加する方法については、第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」の第90.1項「ブログ・アセット・フォームのカスタマイズ」を参照してください。

88.2.4 デフォルトのブログ作成者カテゴリ定義およびブログ作成者カテゴリ

デフォルトでは、Blogフレックス・ファミリには、ブログ作成者を格納するためのフラットな構造を定義する、BlogAuthorCategoryという名前の1つのブログ作成者カテゴリ定義が含まれます。Blog Author Categoryアセット・タイプは、カテゴリに命名するために使用されます。サイト上で作成(または共有)されたすべての作成者アセットを含めるために使用されるBlogAuthorsという名前のブログ作成者カテゴリが1つのみ存在します。

図88-5 サンプル・ブログ作成者カテゴリの階層

88.2.5 デフォルトのブログ作成者定義およびブログ作成者

Blogフレックス・ファミリには、ブログ作成者アセットがBlogAuthorsカテゴリに所属できることを指定するBlogAuthorDefという1つのブログ作成者定義が含まれます。また、BlogAuthorDefはブログ作成者フォームを構成する属性も指定します。

- 完全な名前

- 作成者プロファイル・イメージ

また、BlogAuthorDefは、作成者の完全な名前、および大小のサムネイル・イメージ(オプション)を取得するフィルタも指定します。

Blog Authorアセット・タイプは、公開されるブログの横に表示されるブログ作成者アセットを作成する際に管理者が入力するフォームを提供します。ブログ作成者は名前やイメージを変更できます。

図88-6には、BlogAuthorDefが表示されており、ブログ作成者フォームでそのパラメータがどのように使用されているかが示されています。

図88-6 ブログ作成者定義とブログ作成者フォームの関係

88.2.6 デフォルトのブログ・フィルタ

Blogフレックス・ファミリには、デフォルトのフィルタが含まれています。このフィルタでは、ユーザー定義のフレックス属性にシステム定義属性の内容をコピーするためにフィールド・コピー用フィルタが使用されます。

デフォルトのブログ・フィルタは次のとおりです。

- GetAssetId: Blog Category Definitionに適用され、ブログ・アセットのIDを取得します。

- GetAuthorUsername: Blog Author Definition内で定義されています。Blog Authorに適用され、指定されたブログ作成者の完全な名前を動的に生成します。

- GetCategory: Blog Category Definitionに適用され、ブログ・アセットに関連するカテゴリを取得します。

- GetGrandParentCategory: GrandParentBlogCategoryに適用され、指定されたブログ・アセットに関連する祖父母カテゴリを取得します。

- GetGrandParentDesc: GrandParentBlogCategoryに適用され、祖父母カテゴリの属性を取得します。

- GetLargeThumbnail: Blog Author Definition内で定義されています。Blog Authorに適用され、指定されたブログ作成者の大きなサムネイル・イメージを動的に生成します。

- GetParentCategory: ParentBlogCategoryに適用され、指定されたブログ・アセットに関連する親カテゴリを取得します。

- GetParentDesc: ParentBlogCategoryに適用され、親カテゴリの属性を取得します。

- GetSmallThumbnail: Blog Author Definition内で定義されています。Blog Authorに適用され、指定されたブログ作成者の小さなサムネイル・イメージを動的に生成します。

ブログ・アセット用の追加フィルタを作成する方法については、第17.2項「フレックス・フィルタ・クラスの定義およびフレックス・フィルタ・アセットの作成」を参照してください。

89 Community Blogs: サンプル・ブログ・ページ

この章では、Community Blogsモジュールによって提供されるデフォルトのブログ・コンポーネントについて説明します。これらのコンポーネントはそのまま使用可能で、サンプル・ブログ・ページをレンダリングします。

この章には次の項が含まれます。

- 第89.1項「サンプル・ブログ・ページの概要」

- 第89.2項「サンプル・ブログ・ページのコンポーネント」

- 第89.3項「次の手順」

89.1 サンプル・ブログ・ページの概要

ブログ・ページは、ブログ・アセット、ブログ作成者アセット、右側のナビゲーション・パネル、ヘッダーおよびフッターによって構成されます。ブログ・ページは、デフォルトのブログ・テンプレート、CSElementおよびSiteEntryアセットによってレンダリングされます(図89-1を参照)。デフォルトでは、すべてのブログ・ページがキャッシュされます(ラッパー・ページを除く)。

FW_RecentBlogsページは、Community Blogsモジュールのメイン・ページです。このページは、FW_RecentBlogsDetailテンプレートによって呼び出されます。

ラッパー・エレメントがサンプル・レイアウト・テンプレート(FW_BlogLayout)を呼び出します。このレイアウトはサンプル・ブログ・ページの全体的な外観を定義し、FW_BlogContainerテンプレートを呼び出します。このテンプレートが、ページとアセット・タイプBlog CategoryおよびBlog Asset用の対応する詳細なテンプレートを呼び出します。

ラッパーのパラメータ(ページに一度に表示するブログの数など)は、デフォルトのSiteEntryアセットによって定義されます。Community BlogsモジュールのSiteEntryアセットは、FW_Blogwrapper CSElementによってレンダリングされます。

図89-1 サンプル・ホーム・ページ

89.2 サンプル・ブログ・ページのコンポーネント

この項では、デフォルトのブログ・テンプレート、CSElementおよびSiteEntryアセットについて説明します。これらのコンポーネントは、サンプル・ブログ・ページをレンダリングするデフォルトのパラメータおよびコードによってあらかじめ構成されています。

WebCenter Sitesは、サンプル・ページ名に関連付けられたコードを実行することによってサンプル・ブログ・ページをレンダリングします。Webサイトの外観に適した独自のブログ・ページを作成するため、このサンプル・ブログ・ページを参照用として利用できます。

注意:

ページ・アセットはサイト間で共有できません。各種のCMサイトでCommunity Blogsモジュールを使用するには、それらのサイト用の新しいブログ・ページを作成する必要があります。他のすべてのコンポーネントは共有できます。サイトのブログ機能を完全にカスタマイズするには、サイトのコンポーネントに必要なブログ・コードを追加し、それらを要件に適合するように再構成します。ページを作成する方法については、第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」の第90.2.1項「ブログ・ページの作成」を参照してください。

サンプル・ブログ・ページはWebCenter Sitesのツリーの中にあります(「サイト・プラン」タブ→「未配置ページ」を選択します)。次に、サンプル・ページについて説明します。

- FW_RecentBlogs: このページはCommunity Blogsモジュールのサンプル・ホーム・ページであり、最近公開されたすべてのブログが表示されます。

- FW_AuthorBlogs: このページには、選択した作成者によって投稿されたブログが表示されます。右側のナビゲーション・パネルの「作成者」セクションで作成者の名前をクリックすると、ブログがレンダリングされます。

- FW_ArchiveBlogs: このページには、指定された月に投稿されたすべてのブログが表示されます。右側のナビゲーション・パネルの「アーカイブ」セクションで月の名前をクリックすると、このページにブログがレンダリングされます。

これらのページは、FW_BlogLayoutテンプレートによってレンダリングされます。ただし、ページ間を移動するには、最初にサンプル・ホーム・ページ(FW_RecentBlogs)を表示してください。このページを表示することによって、他のサンプル・ブログ・ページで必要なパラメータが初期化されるためです。

サンプル・ブログ・ページのコンポーネントの詳細は、次のトピックを参照してください。

- 第89.2.1項「デフォルトのブログのCSElement」

- 第89.2.2項「デフォルトのブログのSiteEntryアセット」

- 第89.2.3項「デフォルトのブログのテンプレート」

- 第89.2.4項「ブログ・アーカイブの「詳細」リンク機能」

89.2.1 デフォルトのブログのCSElement

Community Blogsモジュールは、デフォルトのCSElementsを提供します。これには、サンプル・ブログ・ページを構築するための再利用可能なコード(XMLまたはJSPおよびJavaの形式)が格納されています。たとえば、3つのサンプル・ブログ・ページすべてに「共有」リンクが表示されているため、リンク機能の完全なコードを含む、CSElementが作成されています(FW_Blogs/Utils/AddThisWidget)。

表89-1に、Community BlogsモジュールのデフォルトのCSElementを一覧表示して説明します。

表89-1 デフォルトのブログのCSElement

名前およびElementCatalogエントリ

説明

FW_BlogWrapper

Community Blogsモジュールのサンプル・ページのラッパー。

FW_Blogs/Utils/AddThisWidget

「共有」リンクをレンダリングします。訪問者はこのリンクを使用してWebサイト間でブログを共有できます。

FW_Blogs/Utils/CreateArchiveLink

FW_ArchiveBlogsテンプレートを呼び出すリンクをレンダリングします。

FW_Blogs/Utils/CreateAuthorLink

FW_AuthorBlogsDetailテンプレートを呼び出すリンクをレンダリングします。

FW_Blogs/Utils/GetAssetData

ブログ・アセットのデータを取得します。たとえば、このエレメントはブログ・アセットが親から継承した属性を取得できます。

FW_Blogs/Utils/GetAuthor

指定したブログ作成者の作成者アセットから完全な名前とプロファイル・イメージを取得します(存在する場合)。

FW_Blogs/Utils/GetBlogAuthors

作成者のリストを取得し、それぞれの作成者へのリンクを提供します。

FW_Blogs/Utils/GetBlogCategories

カテゴリのリストを取得し、それぞれのカテゴリへのリンクを提供します。

FW_Blogs/Utils/GetBlogsByMonth

月のリストを取得し、それぞれの月へのリンクを提供します。

FW_Blogs/Utils/GetChildren

特定のブログの親の子を取得します。

FW_Blogs/Utils/GetExternalURL

ブログ・アセットの外部URLを作成します。そのタイトルとサマリーは、RSSフィードでリストされます。デフォルトでは、このエレメントはローカルのWebCenter SitesのURLを作成します。URLを変更するには、このエレメントをカスタマイズする必要があります。第90.3項「RSSフィードのURLのカスタマイズ」を参照してください。

FW_Blogs/Utils/GetRecentBlogs

最近公開されたブログのリストを取得し、それらの詳細ページへのリンクを提供します。

89.2.2 デフォルトのブログのSiteEntryアセット

Community BlogsモジュールのSiteEntryアセットはページレットを表し、サンプル・ページのラッパーを生成するルート・エレメントであるFW_Wrapper CSElementに関連付けられています。Community BlogsモジュールのSiteEntryアセットによって、blogsperpageページレット・パラメータが指定されます。これは、ページに一度に表示可能なブログの数を定義します。

表89-2は、FW_BlogWrapper SiteEntryアセットのデフォルトのページレット・パラメータを示しています。

表89-2 FW_BlogWrapper SiteEntryアセットのページレット・パラメータ

ページレット・パラメータ

値

blogsperpage

5

rendermode

live

seid

この値は自動的に生成されます。

site

Community Blogsモジュールをインストールしたサイトの名前。

1ページ当たりのブログ数

1ページ当たりのブログ数は、FW_BlogWrapper SiteEntryアセットからblogsperpageパラメータとして渡されます。何も渡されない場合、1ページ当たりのブログ数のデフォルト値として10が指定されます。サイトのブログ・ページに一度に表示可能なブログ数を指定する方法については、第90.2.4項「サイトのSiteEntryアセットへのブログ・パラメータの追加」を参照してください。

89.2.3 デフォルトのブログのテンプレート

Community Blogsモジュールは、サンプル・ブログ・ページをレンダリングするデフォルト・テンプレートを提供します。リンクをクリックすると対応するテンプレートが呼び出され、コンテンツがレンダリングされます。たとえば、ブログ投稿の「詳細」リンクをクリックすると、関連付けられた詳細テンプレートによって投稿の完全なコンテンツがレンダリングされます。

サイトのページ・レイアウトは、独自のヘッダー、フッター、ナビゲーションおよびコンテンツ・コンテナによってレンダリングされます。Webサイトにブログ・ページを追加するには、Community Blogsモジュールのデフォルト・テンプレート内に指定されている必要なコードをサイトのテンプレートに追加します。表89-3に、Community Blogsモジュールのデフォルト・テンプレートを一覧表示して説明します。

表89-3 デフォルトのブログのテンプレート

テンプレート

デフォルトの名前

アセット・タイプ

説明

詳細

FW_ArchiveBlogsDetail

ページ

「ブログ・アーカイブ」ページにリストされるブログのレンダリングに使用されます。

詳細

FW_AuthorBlogsDetail

ページ

「この作成者によるブログ」ページにリストされるブログのレンダリングに使用されます。

詳細

FW_BlogAssetDetail

FW_BlogAsset

選択したブログの完全なコンテンツのレンダリングに使用されます。

詳細

FW_BlogCategoryDetail

FW_BlogParent

右側のナビゲーション・パネルの「カテゴリ」セクションにリストされるブログ・カテゴリのレンダリングに使用されます。

詳細

FW_RecentBlogsDetail

ページ

最近公開されたすべてのブログをリストするブログ・ホーム・ページのレンダリングに使用されます。

コンテナ

FW_BlogContainer

ページ

詳細テンプレートのコールに使用されます。

コンテナ

FW_BlogContainer

FW_BlogParent

詳細テンプレートのコールに使用されます。

コンテナ

FW_BlogContainer

FW_BlogAsset

詳細テンプレートのコールに使用されます。

ブログ・レイアウト

FW_BlogLayout

なし

サンプル・ブログ・ページのメイン・レイアウトのレンダリングに使用されます。

ブログRSS

FW_BlogRSS

なし

(型なし)FW_BlogSummaryRSSのレンダリングに使用されます。

ブログRSS

FW_BlogSummaryRSS

FW_BlogAsset

(型付き)WebページにRSSフィードをレンダリングします。FW_BlogRSSによって呼び出されます。

サマリー

FW_BlogSummary

FW_BlogAsset

各ブログ・アセットのサマリーを一覧表示するために使用されます。ブログ・アセットのサマリーには、タイトル、概要、作成者の完全な名前とプロファイル・イメージ、日付および時刻が含まれます。

リンク

FW_Link

FW_BlogParent

ブログ・カテゴリのリンクのレンダリングに使用されます。

リンク

FW_Link

FW_BlogAsset

ブログのリンクのレンダリングに使用されます。

ナビゲーション

FW_Nav

FW_BlogParent

各詳細テンプレートには、すべてのエレメント(最近の投稿、カテゴリ、作成者およびアーカイブ)を内部的に呼び出すナビゲーション・リンクがあります。

ナビゲーション

FW_Nav

FW_BlogAsset

各詳細テンプレートには、すべてのエレメント(最近の投稿、カテゴリ、作成者およびアーカイブ)を内部的に呼び出すナビゲーション・リンクがあります。

ナビゲーション

FW_Nav

なし

各詳細テンプレートには、すべてのエレメント(最近の投稿、カテゴリ、作成者およびアーカイブ)を内部的に呼び出すナビゲーション・リンクがあります。

ナビゲーション

FW_Nav

ページ

各詳細テンプレートには、すべてのエレメント(最近の投稿、カテゴリ、作成者およびアーカイブ)を内部的に呼び出すナビゲーション・リンクがあります。

89.2.4 ブログ・アーカイブの「詳細」リンク機能

右側のナビゲーション・パネルの「アーカイブ」セクションの隣にある「詳細」リンクは、「アーカイブ」ページに関連する追加データをフェッチするために使用されます。デフォルトでは、「アーカイブ」ページには過去12か月のブログがリストされます。「詳細」リンクを複数回クリックすると、1回のクリックごとにさらに12か月分のブログ・データが取得されます。

「詳細」リンクは、Community Blogsモジュールのデフォルト・レイアウト・テンプレート内にコーディングされています。レイアウト・テンプレートのコードの詳細は、第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」の第90.2.2項「ブログ・コードの追加」を参照してください。

89.3 次の手順

ガイドのこの項では、ここまで、Blogフレックス・ファミリ、およびサンプル・ブログ・ページを構成するデフォルトのコンポーネントについて説明してきました。以降の各章では、その手順について説明します。第90章「Community Blogs: ブログ・コンポーネントのカスタマイズ」には、開発者向けの情報が記載されており、カスタム・ページにブログ機能を追加するための手順とコードについて説明しています。『Oracle Fusion Middleware WebCenter Sites管理者ガイド』には、管理者向けの情報が記載されており、コンテンツ・プロバイダ用のブログ・アセット・タイプを有効にする方法について説明しています。『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』には、データ・モデルのテスト、およびブログ・アセットの作成と公開に関する情報が記載されています。

90 Community Blogs: ブログ・コンポーネントのカスタマイズ

この項では、デフォルトのブログ・コンポーネントを再構成してカスタム・ページをレンダリングするための全般的な情報と手順について説明します。

この章には次の項が含まれます。

- 第90.1項「ブログ・アセット・フォームのカスタマイズ」

- 第90.2項「CMサイトへのブログ機能の追加」

- 第90.3項「RSSフィードのURLのカスタマイズ」

90.1 ブログ・アセット・フォームのカスタマイズ

Blogフレックス・ファミリの階層は、要件にあわせて変更できます。この項では、新しいブログ属性を作成し、その属性をブログ・アセット定義に追加して、ブログ・アセット・フォームのフィールドとして表示する方法について説明します。

注意:

ブログ・カテゴリとブログ・アセットの階層関係を参照する場合は、ツリー・タブを作成します。ツリー・タブの作成方法については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

この項の内容は、次のとおりです。

- 第90.1.1項「ブログ属性の作成」

- 第90.1.2項「ブログ・アセット定義へのブログ属性の追加」

90.1.1 ブログ属性の作成

ブログ属性を作成してブログ・アセット定義に追加すると、その属性はブログ・アセット・フォームにフィールドとして表示されます。

ブログ属性を作成するには

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. Community Blogsモジュールが有効になっているサイトを選択します。

3. ボタン・バーで、「新規」をクリックします。

4. 「新規ブログ属性」をクリックします。

5. 「ブログ属性」フォームで、次のようにフィールドに入力します。

図90-1 「ブログ属性」フォーム

注意:

入力する必要のあるフィールドは、属性に対して選択したデータ型に応じて大きく異なる場合があります。

- 名前: 最大64文字の名前を入力します(空白文字を含めることはできません)。

- 説明: 属性の使用方法や機能について説明した、簡潔なサマリーを入力します。

- 値タイプ: この属性のデータ型を選択します。

- アセット・タイプ: 属性のタイプがassetの場合、ドロップダウン・リストからアセットを選択します。

- 依存性タイプのミラーリング: 属性のタイプがassetの場合、依存性タイプを選択します。

- フォルダ: (オプション)属性のタイプがblobの場合、属性値を保存するディレクトリのパスを入力します。

- 埋込みリンクの許可: 属性のタイプがtext、blobまたはURLの場合、属性のコンテンツ・フィールドに他のページまたはWebサイトへのリンクを埋め込むことが可能かどうかを選択します。

- 値の数: 「値タイプ」フィールドで選択したデータ型に応じて、ドロップダウン・リストから「単一」または「複数」のいずれかを選択します。

- 属性エディタ: (オプション)デフォルトの入力タイプを使用しない場合は、「属性エディタ」フィールドをクリックして、フィールドに適した属性エディタを選択します。

- (オプション)文字セット: デフォルトのISO文字セット(ISO-8859-1)をオーバーライドする必要がある場合は、この属性で使用する文字セットを入力します。

外部属性を作成する(外部システムでデータを保持する)場合は、次のフィールドに入力します。

- 編集スタイル: この属性を外部システムのネイティブ表として利用できるようにするには、「外部」を選択します。

- ストレージ・スタイル: 「外部」を選択します。詳細は、第16.3.6.4項「外部フレックス属性の作成」を参照してください。

- 外部ID:この外部属性を格納する表の主キーとなる列(この属性を一意に識別する列)の名前を指定します。

- 外部表: この属性を格納する表の名前を入力します。

- 外部列: 「外部表」フィールドで指定した表の、この属性の値が格納される列の名前を入力します。

6. 「保存」をクリックします。
属性を作成したら、その属性をブログ・アセット定義に追加します。手順は、次の項を参照してください。

90.1.2 ブログ・アセット定義へのブログ属性の追加

ブログ・アセット・フォームに属性を追加するには、その属性をブログ・アセット定義に追加する必要があります。

ブログ・アセット定義に属性を追加するには

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインし、Community Blogsモジュールが有効になっているサイトを選択します。

2. ブログ・アセット定義の「調査」フォームにアクセスします。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」フォームで、「ブログ・アセット定義の検索」をクリックし、「検索」をクリックします。

3. 「BlogAssetDef」を選択します。

3. 「調査」フォームで、「編集」をクリックします。

4. 「属性」フィールドで、「使用可能」リストから属性を選択し、「必須」ボタンまたは「オプション」ボタンを使用して属性を「選択済」リストに移動します。選択したボタンによって、ブログ・アセット・フォームでこの属性が必須またはオプションのいずれになるかが決定されます。

5. 「保存」をクリックします。
選択した属性が、ブログ・アセット・フォームにフィールドとして含まれるようになります。ユーザーがブログ・アセットを作成するときに、新しい属性が必須またはオプションのフィールドとして表示されます。

90.2 CMサイトへのブログ機能の追加

各種のCMサイトでCommunity Blogsモジュールを使用するには、それらのサイト用の新しいブログ・ページを作成する必要があります。Webサイトにブログ機能を追加する作業には、次の手順が含まれます。

1. コンテンツ管理サイトに、Webサイトでのブログ・アセットのレンダリングに使用されるページを作成します。

2. デフォルトのブログ・テンプレートおよびCSElementから、ご使用のサイトのテンプレートおよびCSElementにブログ・コードをコピーします。テンプレートおよびCSElementに挿入した後で、デフォルトのコードに加える必要のある変更内容は、サイトの設定方法によって決まります。

3. Community BlogsモジュールのSiteEntryアセットで指定されているblogsperpageパラメータを、ご使用のサイトのSiteEntryアセットに追加します。

この項の内容は、次のとおりです。

- 第90.2.1項「ブログ・ページの作成」

- 第90.2.2項「ブログ・コードの追加」

- 第90.2.3項「Community-Gadgetsの機能の追加」

- 第90.2.4項「サイトのSiteEntryアセットへのブログ・パラメータの追加」

90.2.1 ブログ・ページの作成

ブログ・ページを作成する前に、メイン・ブログ・ページ(Community BlogsモジュールではFW_RecentBlogsページ)、カテゴリ・ページなど、ページのタイプについて構想を練ります。また、ご使用のWebサイトのレイアウトに合致するブログ・ページを作成するため、サイトのグラフィック、ナビゲーション、機能を決定します。

ブログ・ページを作成するには

1. 一般管理者としてWebCenter Sitesにログインし、Webサイトの訪問者にブログを表示するページの作成場所であるサイトを選択します。その後、WebCenterのContributorインタフェースのアイコンを選択します。

2. メニュー・バーで、「コンテンツ」→「新規」→「新規ページ」を選択します。
タブが開き、「新規ページ」フォームが表示されます。

3. 「新規ページ」フォームで、次のようにフィールドに入力します。

- 名前: 最大64文字の名前を入力します。

- タグ: ページに追加する1つの語句またはフレーズを入力します。

- テンプレート: ページをレンダリングするテンプレートを選択します。

- 関連付けられたアイテム: このフィールドのドロップ・ゾーンにコンテンツ(関連する記事など)を追加します。

4. 「保存」アイコンをクリックします。
ブログ・アセットを表示するページを作成したら、ご使用のWebサイトで新しいページを呼び出してブログの機能をレンダリングするためのサイトのテンプレートおよびCSElementをコーディングします。詳細は、第90.2.2項「ブログ・コードの追加」を参照してください。

90.2.2 ブログ・コードの追加

Community Blogsモジュールは、サンプル・ブログ・ページをレンダリングするように構成されています。ただし、ほとんどの場合、ご使用のサイトのレイアウトはサンプル・ブログ・ページのレイアウトとは異なるでしょう。たとえば、サンプル・ブログ・ページでは右のナビゲーションを呼び出しますが、ご使用のサイトでは左のナビゲーションを呼び出す場合があります。テンプレートを初めからコーディングしてブログ機能を組み込むのではなく、サンプル・コードを再利用して自身のテンプレートやCSElementに挿入し、必要に応じてコードを再構成することができます。

注意:

サイトのレイアウトはサイトのラッパー・エレメントによってレンダリングされます。既存のページに加えて、ブログ・ページもラッパー・エレメントによってレンダリングされるようにするには、デフォルトのFW_Wrapperエレメントからサイトのラッパー・エレメントに該当するブログ・コードをコピーします。

サイトのレイアウト・テンプレートにブログ・コードを追加するには

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. Community Blogsモジュールがインストールされているサイトを選択します。

3. FW_BlogLayoutテンプレートにアクセスします。

1. ボタン・バーで、「検索」をクリックします。

2. 「検索」リストで、「テンプレートの検索」を選択します。

3. 「検索」フィールドにFW_BlogLayoutと入力し、「検索」をクリックします。

4. 「FW_BlogLayout」をクリックします。

4. レイアウト・テンプレートの「調査」フォームで、「編集」をクリックします。

5. Community 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"));
}

次の行は、ブログ・レイアウト・テンプレートのスタイル・シートを呼び出します。このスタイル・シートは、サンプル・ブログ・ページのルック・アンド・フィールを定義します。サイトにはすでに独自のスタイル・シートが存在するため、Community Blogsモジュールのスタイル・シートから必要なパラメータをコピーして、独自のスタイル・シートに挿入します。Community 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にコピーします。

90.2.3 Community-Gadgetsの機能の追加

Community BlogsモジュールをCommunity-Gadgetsに統合した場合、FW_BlogSummaryテンプレートおよびFW_BlogAssetDetailテンプレートに、コメント・ウィジェットおよびコメント・リンクのタグが追加されています。カスタム・ページにCommunity-Gadgetsの機能を追加するには、これらのテンプレートのウィジェット・タグをカスタム・テンプレートにコピーします。

ページにコメント・ウィジェットをコピーするには、デフォルト・ブログ・テンプレートからカスタム・テンプレートに次の行をコピーします。

<%
boolean cosEnabled = Boolean.parseBoolean(ics.GetProperty("fwblogs.cos.enabled", "futuretense_xcel.ini", true));
if(cosEnabled)
{
String cosProtocol = ics.GetProperty("cos.protocol", "futuretense_xcel.ini", true);
String cosHost = ics.GetProperty("cos.hostname", "futuretense_xcel.ini", true);
String cosPort = ics.GetProperty("cos.portnumber", "futuretense_xcel.ini", true);
String cosContext = ics.GetProperty("cos.contextroot", "futuretense_xcel.ini", true);
String cosUrl = cosProtocol + "://" + cosHost + ":" + cosPort + "/" + cosContext;
%>

<div id="comments_container"></div>
<script type="text/javascript">
cos = window.cos || {};
cos.pageWidgets = cos.pageWidgets || [];

cos.pageWidgets.push({name: "wsdk.comments",
version: "1.5",
elementID: "comments_container",
attributes: {"site_id":"<%=ics.GetVar("site")%>","resource_id":"<%=ics.GetVar("cid")%>"}});
setTimeout(
function(){if ((typeof(wsdk) == 'undefined') || (typeof(wsdk.comments) ==
'undefined')) {element:document.getElementById('comments_container')
.innerHTML = "<div style='font-family: Tahoma, Verdana, Geneva,
sans-serif;font-size: 12px;color: #333333;border: 1px solid
#dbdfe1;padding-left: 5px;padding-top: 4px;height: 22px;'>Comments is
unavailable right now. Please contact the site administrator.</div>";}}
,30000);

cos.pageScripts = cos.pageScripts || [];
cos.pageScripts.push('wsdk.comments');

(function()
{
var oldOnloadHandler = window.onload || function()
{
};
if (!oldOnloadHandler.alreadyProcessed)
{
window.onload = function()
{
var script = document.createElement('script');
script.src = '<%=cosUrl%>/wsdk/widget/'
+ cos.pageScripts.join(':') + '.js?site_id=<%=ics.GetVar("site")%>';
script.type = 'text/javascript';
script.charset = 'utf-8';
document.getElementsByTagName("head").item(0).appendChild(script);
oldOnloadHandler.apply(this, arguments);
};
window.onload.alreadyProcessed = true;
}

})();
</script>

<%}%>

ページにコメント・リンク・ウィジェットをコピーするには、デフォルト・ブログ・テンプレートからカスタム・テンプレートに次の行をコピーします。

boolean cosEnabled = Boolean.parseBoolean(ics.GetProperty("fwblogs.cos.enabled", "futuretense_xcel.ini", true));
if(cosEnabled)
{
String cosProtocol = ics.GetProperty("cos.protocol", "futuretense_xcel.ini", true);
String cosHost = ics.GetProperty("cos.hostname", "futuretense_xcel.ini", true);
String cosPort = ics.GetProperty("cos.portnumber", "futuretense_xcel.ini", true);
String cosContext = ics.GetProperty("cos.contextroot", "futuretense_xcel.ini", true);
String cosUrl = cosProtocol + "://" + cosHost + ":" + cosPort + "/" + cosContext;
%>

<script type="text/javascript">
cos = window.cos || {};
cos.pageWidgets = cos.pageWidgets || [];

cos.pageWidgets.push({name: "comments-link",
version: "0.1",
elementID: "comments_link_div",
attributes: {"site_id":"<%=ics.GetVar("site")%>"}});

cos.pageScripts = cos.pageScripts || [];
cos.pageScripts.push('comments-link');

(function()
{
var oldOnloadHandler = window.onload || function()
{
};
if (!oldOnloadHandler.alreadyProcessed)
{
window.onload = function()
{
var script = document.createElement('script');
script.src = '<%=cosUrl%>/wsdk/widget/'
+ cos.pageScripts.join(':') + '.js?site_id=<%=ics.GetVar("site")%>';
script.type = 'text/javascript';
script.charset = 'utf-8';
document.getElementsByTagName("head").item(0).appendChild(script);
oldOnloadHandler.apply(this, arguments);
};
window.onload.alreadyProcessed = true;
}

})();
</script>

<%}%>

90.2.4 サイトのSiteEntryアセットへのブログ・パラメータの追加

Community BlogsモジュールのSiteEntryアセットは、一度に1つのWebページ上に表示可能なブログ・アセットの数を指定できるblogsperpageパラメータを指定します。このパラメータはユーザー専用サイトのSiteEntryアセットで指定できます。

注意:

ご使用のサイトのSiteEntryアセットにblogsperpageパラメータを指定しない場合、1ページ当たりのブログ数としてデフォルトの10が使用されます。blogsperpageパラメータの詳細は、第89.2.2項「デフォルトのブログのSiteEntryアセット」を参照してください。

カスタムのSiteEntryアセットにblogsperpageパラメータを追加するには

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. ブログ機能を追加するサイトを選択します。

3. ボタン・バーで「検索」をクリックし、サイトのSiteEntryアセットを検索します。

1. 「検索」フォームで、「SiteEntryの検索」をクリックします。

2. 「検索」をクリックします。

3. サイトのSiteEntryアセットを選択します。

4. SiteEntryアセットの「調査」フォームで、「編集」をクリックします。

5. 「ページレット・パラメータ」フィールドで、次の項目を追加します。

- 名前: blogsperpageと入力します。

- 値: ページに一度に表示可能なブログの数を入力します。

6. 「保存」をクリックします。

90.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>は、Community Blogsモジュールが実行されているWebCenter Sitesアプリケーションのコンテキストです。

ご使用のサイトの外部URLでRSSフィードを使用するには、GetExternalURLエレメントのURL文字列を変更し、表90-1にリストされているパラメータをfuturetense_xcel.iniファイルに追加して、ホスト情報およびサイトのコンテキストの値を設定する必要があります。GetExternalURLエレメントは、futuretense_xcel.iniファイルからこれらのパラメータを読み取ることで、サイトのRSSフィードにリストされているブログ・アセットの外部URLを作成します。

表90-1 GetExternalURLエレメントが外部URLを作成する際に読み取るパラメータ

パラメータ

説明

fwblogs.hostscheme

URL命名構造の最上位レベルを指定します。たとえば、httpと指定します。

fwblogs.hostname

RSSフィードのアセットにアクセス可能なWebCenter Sitesインストールのホスト名を指定します。

fwblogs.portnumber

WebCenter Sitesアプリケーションのポート番号を指定します。

fwblogs.contextinfo

Community Blogsモジュールが実行されているWebCenter Sitesインストールのコンテキストを指定します。

第VIII部

ガジェットの開発

この部では、テンプレート開発者向けに、Oracle WebCenter Sites: Gadgetsアプリケーションのガジェット作成プロセスについて紹介します。ガイドのこの項を通じて、開発タスクを説明するために、Gadgetsアプリケーションに同梱されているサンプル・ガジェットが使用されます。これは完全に動作するガジェットのセットであり、Oracle WebCenter Sitesで提供されるFirstSiteIIサンプル・サイトで実行されます。このサンプル・ガジェットの基礎となるアセット・モデルおよびテンプレート・フレームワークは、開発者が独自のガジェットの作成を開始するのに必要なツールを提供します。

この部は、次の章で構成されています。

- 第91章「ガジェットの開発について」

- 第92章「Gadgets: テンプレート・フロー」

- 第93章「Gadgets: 独自のガジェットの作成」

91 ガジェットの開発について

この章では、WebCenter Sitesのテンプレート・コードに基づいてガジェットを作成するためのガイドラインについて説明します。

この章には次の項が含まれます。

- 第91.1項「始める前に」

- 第91.2項「ガジェットの仕様」

- 第91.3項「サンプル・ガジェット」

- 第91.4項「アセットの構造」

91.1 始める前に

ガイドのこの項を利用するには、次のものが必要です。

- WebCenter Sitesのベーシック・アセット・モデル、フレックス・アセット・モデル、テンプレート作成に関する開発者向けの知識。

- Google Gadget API。関連するリソースには次のURLからアクセスできます。

- APIリファレンス:
http://code.google.com/apis/gadgets/docs/reference/

- API開発者ガイド:
http://code.google.com/apis/gadgets/docs/dev_guide.html

- OpenSocial標準に関する知識。ガジェットのユーザーによるプリファレンスの設定が可能な環境を作成するために必要です。OpenSocialのドキュメントは次の場所にあります。
http://wiki.opensocial.org/

- WebCenter SitesのFirstSiteIIサンプル・サイトにインストールされたGadgetsアプリケーションのサンプル・ガジェット。Gadgetsアプリケーションのインストールと構成の詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。Gadgetsアプリケーションの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。

91.2 ガジェットの仕様

Gadgetsアプリケーションには、4つのサンプル・ガジェットが含まれています。これらは、FirstSiteIIサンプル・サイトで有効になっています。このガイドで説明するプロセスを使用して、独自のガジェットを開発できます。サンプル・ガジェットは次のとおりです。

- Listガジェット: ヘッドラインと記事のサマリー、および完全な記事へのリンクを提供します。

- ThumbListガジェット: 各製品の説明とサムネイルが含まれた製品のリストを提供します。

- Slideshowガジェット: 一連の製品イメージをスライドショーとしてレンダリングします。ユーザーは、サムネイルをクリックして拡大したイメージを表示できます。拡大したイメージをクリックすると、製品の詳細が記載されたページが開かれます。

- RSS Feed: RSSフィードから取得したヘッドラインのリストを提供します。それぞれのヘッドラインには、完全な記事へのリンクがあります。

この章の残りの部分では、ガジェットの主なコンポーネントに関する情報を提供し、サンプル・ガジェットについて詳しく説明します。

この項の内容は、次のとおりです。

- 第91.2.1項「アセット・モデルとテンプレート」

- 第91.2.2項「サンプル・アセット」

- 第91.2.3項「補助ファイル」

91.2.1 アセット・モデルとテンプレート

FirstSiteIIにサンプル・ガジェットをインストールすると、ガジェットの作成とレンダリングのための基本的なコンポーネントがインストールされます。これらのコンポーネントは、データ・モデル、テンプレート、およびガジェットのコンテンツを提供するサンプル・アセットです。

- FW_CSGadgetアセット・タイプ(その説明はCS-Based Gadget)。すべてのサンプル・ガジェットのタイプはFW_CSGadgetです。

- FW_RSSアセット・タイプ(その説明はRSS Feed)。このアセット・タイプは、RSS Feedガジェットのコンテンツ・ソースとしてURLを指定する際に使用します。

- FW_CSGadget/GenerateGadgetXMLテンプレート。Gadgetsアプリケーションによってアクセスされます。このテンプレートは、ガジェット・ディスクリプタXML (ガジェット仕様XMLとも呼ばれる)をレンダリングするために使用されます。

- FW_CSGadget/ListSiteGadgetsテンプレート。現在のコンテンツ管理サイトに各ガジェットのガジェット・ディスクリプタURLを提供します。

91.2.2 サンプル・アセット

サンプル・アセットは、ガジェットのコンテンツを提供するか、ガジェットをレンダリングします。サンプル・アセットは、次に示すようにサンプル・ガジェットによって参照されます。

- ガジェットのコンテンツの提供元は次のとおりです。

- Content_CタイプのContentアセット(Content_Pタイプの親を持つ)。スポーツ記事を表します。これらのアセットは、Listガジェットによって使用されます。

- Product_CタイプのProductアセット(Product_Pタイプの親を持つ)。スポーツ製品を表します。これらのアセットは、ThumbListおよびSlideshowガジェットによって使用されます。

- Media_CタイプのMediaアセット(Media_Pタイプの親を持つ)。Productアセットによって使用されるイメージを表します。これらのアセットは、ThumbListおよびSlideshowガジェットによって使用されます。

- Recommendation (AdvCols)アセット。ContentおよびProductアセットをカプセル化します。Recommendationアセットは、List、ThumbList、Slideshowの各サンプル・ガジェットによって使用されます。

- FW_RSSタイプのコンテンツ。RSS Feedガジェットのコンテンツ・ソースとしてURLを指定します。

- 次のように、テンプレートはガジェットをレンダリングします。

- GenerateGadgetXMLテンプレートはGadgetsアプリケーションによってアクセスされ、次のようなテンプレートを呼び出します。

- FW_CSGadgetタイプ付きテンプレート。各サンプル・ガジェットに存在します。次のテンプレートは、Gadgetsアプリケーションが認識できるガジェット・ディスクリプタXMLの本体を出力します。G_List、G_RSS、G_Slideshow、G_ThumbListの各テンプレートです。

- G_JSONという名前のタイプ付きテンプレート。サンプル・ガジェットで参照されるContent_C、Media_C、Product_C、Recommendation (AdvCols)の各アセットに存在します。これらのテンプレートは、ガジェット内で表示される各アセットのHTMLレンダリングに必要なデータを含む、JSONフォーマットの出力を提供します。テンプレートは、ガジェット・コードからのリモート・リクエストを介して呼び出されます。

91.2.3 補助ファイル

サンプル・ガジェットでは、次のイメージ・ファイルが使用されます。

- Slideshowガジェットで使用されるスクローラ矢印のイメージ(図91-1および図91-2)。これらの静的なイメージは、WebCenter Sites Webアプリケーションの下のFirstSiteII/gadgetsサブディレクトリにあります。

- ガジェットの様々なセクションを表すために、アイコン、サムネイル、プレビューとして使用されるイメージ。これらのデフォルトのイメージは、gadgetserver.zipインストール・パッケージ内のsample/GadgetImagesディレクトリにあります。

図91-1 サンプル・ガジェットによって使用されるイメージ

図91-2 サンプル・ガジェットによって使用されるイメージ

91.3 サンプル・ガジェット

この項では、WebCenter Sitesのサンプル・ガジェットと、これらで使用するアセットについて説明します。各アセットは、Gadgetsアプリケーションがリクエストを開始するときのアセットのコール順で記載されています。ガイドのこの項では、主にListガジェットを使用して様々な概念について説明します。

この項の内容は、次のとおりです。

- 第91.3.1項「Listガジェット」

- 第91.3.2項「ThumbListガジェット」

- 第91.3.3項「Slideshowガジェット」

- 第91.3.4項「RSS Feedガジェット」

91.3.1 Listガジェット

Listガジェットは、Contentアセットのリスト・ビューを含むRecommendationアセットをレンダリングします。それぞれのヘッドラインには、完全な記事へのリンクがあります。

Listガジェットのアセットは、ガジェット内でレンダリングされるRecommendationアセット、およびガジェットをレンダリングするテンプレート(G_List)を参照します。該当するアセットは次のとおりです。

- FW_CSGadgetタイプのListGadgetアセット。これは、レンダリングされるRecommendationアセットを参照します。

- G_Listテンプレート。これは、Gadgetsアプリケーションがガジェットをレンダリングする際に使用するガジェット・ディスクリプタXMLの本体を生成します。このプロセスの概要は、第92章「Gadgets: テンプレート・フロー」で説明されています。

- G_JSONテンプレート。これは、Recommendationアセットとそのコンテンツをレンダリングします。

AdvCols/G_JSON and Content_C/G_JSON

- ガジェット内でレンダリングされるRecommendation (AdvCols)アセット。

- Recommendationに含まれるContentアセット。

91.3.2 ThumbListガジェット

ThumbListガジェットは、Recommendationアセットをレンダリングする点でListガジェットに似ています。ガジェットには、Productアセットのリスト・ビューが含まれます。それぞれのヘッドラインには、製品ページへのリンクがあります。ただし、このガジェットの各製品には、Mediaアセットからのサムネイル・イメージも含まれます。このイメージは、Image属性を介してProductアセットに関連付けられています。

該当するアセットは次のとおりです。

- FW_CSGadgetタイプのThumbListGadgetアセット。これは、レンダリングされるRecommendation、およびガジェットをレンダリングするテンプレート(G_ThumbList)を参照します。

- G_ThumbListテンプレート。これは、Gadgetsアプリケーションがガジェットをレンダリングする際に使用するガジェット・ディスクリプタXMLの本体を生成します。

- G_JSONテンプレート。これは、Recommendationアセットとそのコンテンツ(AdvCols/G_JSON、Product_C/G_JSONおよびMedia_C/G_JSON)をレンダリングします。

- ガジェット内でレンダリングされるRecommendation (AdvCols)アセット。

- Recommendationアセットに含まれるProductアセット。

- 各ProductアセットのImage属性によって参照されるMediaアセット。

91.3.3 Slideshowガジェット

SlideshowガジェットはThumbListガジェットと同じコンテンツを使用しますが、そのコンテンツはまったく異なる方法で表示されます。このガジェットは、製品イメージが並んだサムネイル・ストリップを表示します。ストリップ内のイメージをクリックすると、ガジェット領域内で許可されている最大サイズでイメージが表示されます。フルサイズのイメージをクリックすると、製品の詳細ページが開きます。

該当するアセットは次のとおりです。

- SlideshowGadgetアセット。これは、レンダリングされるRecommendationアセット、およびガジェットをレンダリングするテンプレート(G_Slideshow)を参照します。

- G_Slideshowテンプレート。これは、Gadgetsアプリケーションがガジェットをレンダリングする際に使用するガジェット・ディスクリプタXMLの本体を生成します。

- G_JSONテンプレート。これは、Recommendationアセットとそのコンテンツ(AdvCols/G_JSON、Product_C/G_JSONおよびMedia_C/G_JSON)をレンダリングします。

- ガジェット内でレンダリングされるRecommendation (AdvCols)アセット。

- Recommendationアセットに含まれるProductアセット。

- 各ProductアセットのImage属性によって参照されるMediaアセット。

91.3.4 RSS Feedガジェット

RSS Feedガジェットは、RSSフィードの最新の項目を表示します。このガジェットでは、組込みのフィード読込み機能を実行するためにGoogle Gadget APIを利用しています。

該当するアセットは次のとおりです。

- FW_CSGadgetタイプのRSSGadgetアセット。これは、リクエストされるフィード(FW_RSS)、およびガジェットをレンダリングするテンプレート(G_RSS)を参照します。

- G_RSSテンプレート。これは、Gadgetsアプリケーションがガジェットをレンダリングする際に使用するガジェット・ディスクリプタXMLの本体を生成します。

- ガジェット内でリクエストされるフィードのURLを含むFW_RSSアセット。

91.4 アセットの構造

サンプル・ガジェットは、新しいアセット・タイプFW_CSGadgetに基づいています。ガジェットをレンダリングするために必要な情報を指定する際に使用します。これは、次の属性を含むベーシック・アセット・タイプです。

- Name of descriptor template。ガジェットのディスクリプタXMLを生成するために呼び出されるFW_CSGadgetテンプレートの名前を指定する際に使用します。Listガジェットの場合、テンプレートはFW_CSGadget/G_Listです(したがって、G_Listはこのフィールドで指定され、後でタイプ付きテンプレートとして解決されます)。

- DataAssetアソシエーション。単一の任意の型のアセット・アソシエーションです。このアソシエーションは、ガジェットのメイン・コンテンツを提供するアセットを参照します。たとえば、ListガジェットのDataAssetアソシエーションは、ガジェットがレンダリングするContentアセットの静的なリストを保持しているRecommendationアセットを参照します。

ディスクリプタ・テンプレート属性は、FW_CSGadget/GenerateGadgetXMLによって読み取られます。DataAssetアソシエーションは、ディスクリプタ・テンプレート自体(たとえば、G_List)によって読み取られます。

92 Gadgets: テンプレート・フロー

この章では、Listガジェットを例にして、テンプレート実行フローについて説明します。

- 第92.1項「Listガジェットのテンプレート・フロー」

- 第92.2項「テンプレート・フローの違い」

- 第92.3項「サーバー・コールが個別に行われる理由」

92.1 Listガジェットのテンプレート・フロー

設計上、ガジェットのディスクリプタXMLをリクエストする唯一の方法は、FW_CSGadgetアセットのGenerateGadgetXMLテンプレートを起動することです。このテンプレートを起動すると、図92-1とその説明で示されているように、レンダリング・プロセスが開始します。

図92-1 ガジェットのXML出力

1. GenerateGadgetXMLは、最初にXML宣言を出力します。これは、すべてのXMLドキュメントで推奨される機能です。プロセスの最初にXML宣言を出力することによって、ガジェット開発者は、記述するすべてのガジェットでこのことを考慮せずに済むようになります。

2. 次に、GenerateGadgetXMLは、渡されたc (FW_CSGadget)およびcid (ListGadgetのid)に対応するアセットをロードし、descriptortemplateの値を検索します。

注意:

cとcidの組合せは、WebCenter Sitesシステム内の特定のアセットをポイントします。パラメータcはアセットのタイプであり、cidはアセットの識別子です。この情報は、テンプレートの起動時に毎回必要になります。

3. GenerateGadgetXMLは、descriptortemplateフィールドのテンプレートを起動し(Listガジェットの場合はFW_CSTemplate/G_List)、手順0と同じcおよびcidを渡します。
G_Listテンプレート自体は、外部からコールできないこと(SiteCatalogエントリのpageletonlyフィールドがTに設定されている)に注意してください。この設定では、(たとえば、コールされるように設計されていない場合、)テンプレートの直接的なコールが禁止されます。

4. コールされたテンプレートG_Listは、ガジェット・ディスクリプタXMLの本体すべてを出力します。この時点で、ガジェット・ディスクリプタXMLは完全なものになります。

注意:

ガジェット・ディスクリプタXMLの作成に関する追加リソースのリンクについては、第91.1項「始める前に」を参照してください。

ディスクリプタXMLに基づいてガジェットがレンダリングされたら、ガジェットはそのコンテンツを取得します。図92-2は、Listガジェットがコンテンツを取得する様子を示しています。このプロセスはガジェットごとに異なります。Listガジェットは、G_Listテンプレートが出力する次のJavaScriptによって、WebCenter Sitesから記事を取得します(コードのこの行は、Google Gadgets APIをコールします)。

gadgets.io.makeRequest(url, handleJson, params);

G_Listテンプレートは、このガジェットのDataAsset (この場合は、Recommendation)をポイントする追加のWebCenter Sites URLを作成します。これは、そのアセット・タイプ用のG_JSONテンプレートを通じて行われます。このURLは、最終的にgadgets.io.makeRequest関数に渡されます。この関数を使用して、XML、JSON、Atom/RSSなどの各種の形式のデータに対応する追加のリモート・サーバー・コールを行うことができます。このリクエストによって、コンテンツ取得プロセスが開始されます。

図92-2 コンテンツの取得

1. XML本体内のガジェット・コードがAdvCols/G_JSONテンプレートを起動し、JSONレスポンスの開始を準備します。Recommendationsには他のアセットのリストが含まれているため、このテンプレートは単にJSON配列の出力を開始してから、アセットのリストをループ処理し、各アセットでそれぞれのG_JSONテンプレートをコールします。

2. Listガジェットの場合、すべての子はコンテンツ・アセットであるため、Recommendation内のアセットごとにContent_C/G_JSONが起動されます。Content_C/G_JSONテンプレートは、起動されるたびに完全なJSONオブジェクト表現を出力します。このJSONオブジェクト表現には、そのアセットの該当するフィールドが含まれます。

3. Content_C/G_JSONの各コールの間に、AdvCols/G_JSONは、構築する配列内のオブジェクトを正しく区切るためにコンマを出力します。ループが完了すると、AdvCols/G_JSONテンプレートは配列を閉じます。

4. この配列は、ガジェット・コード(gadgets.io.makeRequest(url, handleJson, params);)によって受け取られます。このガジェット・コードは、元のmakeRequestコールの指示に従って、handleJsonコールバック関数を実行します。handleJson関数は、コンテンツをHTMLでラップします。このHTMLは、そのガジェットのビュー(この例ではリスト・ビュー)をレンダリングします。

92.2 テンプレート・フローの違い

前の項では、Listガジェットのテンプレート・フローについて説明しました。他のサンプル・ガジェットのテンプレート・フローもよく似ていますが、WebCenter Sitesのテンプレート・ロジックの違いは注目に値します。

92.2.1 ThumbListとSlideshow

WebCenter Sitesでのガジェットのレンダリング手順は、Listガジェットのものに酷似しています。主な違いは、AdvCols/G_JSONテンプレートによって何が起動されるかです。ListガジェットはContentアセットが格納されたRecommendationを参照しますが、ThumbListガジェットとSlideshowガジェットは、Productアセットが格納されたRecommendationを参照します。また、これらのガジェットではProduct_C/G_JSONテンプレートのレスポンス固有の属性を調査します(これには、Media_C/G_JSONテンプレートによって生成されるデータも含まれます)。

92.2.2 RSS

RSSガジェットの2つ目のリクエストは、RSSフィードのURLに対して直接発行されます。これは、WebCenter Sites内にある場合もあれば、そうでない場合もあります。このURLは、関連付けられたFW_RSSアセットから読み取られます。このアセットはG_RSSテンプレート内でロードされます。

92.3 サーバー・コールが個別に行われる理由

追加のサーバー・コールがなぜ行われるのか、疑問に思うかもしれません。たとえば、Listガジェットのすべての記事をG_Listテンプレート自体から取得しないのはなぜでしょうか。その答えは2つあります。

1. ガジェット・ディスクリプタXMLをガジェット・コンテナでキャッシュ可能にしている可能性があります。これは、XML内に一時的なデータを埋め込まないようにする必要があることを意味します。

2. 追加のサーバー・コールは、プレゼンテーション・ロジック(たとえば、G_List内)を、下層のモデル(アセット・タイプのG_JSONテンプレート内)から分離するのに役立ちます。

93 Gadgets: 独自のガジェットの作成

この章には次の項が含まれます。

- 第93.1項「別のCMサイトでのガジェットの作成」

- 第93.2項「カスタム・ガジェット」

- 第93.3項「ガジェット登録の前提条件」

93.1 別のCMサイトでのガジェットの作成

サンプル・ガジェットは、FirstSiteII上で有効にする必要があります。開発者は、別のCMサイトでガジェットを作成することに関心を持つ場合があります。追加のCMサイトでガジェットのサポートを有効にするための手順は次のとおりです。

1. CMサイトでFW_CSGadgetアセット・タイプとそのスタート・メニュー・アイテムを有効にします。(デフォルトでは、スタート・メニュー・アイテムにアクセスできるのは、デザイナ、サイト管理者または一般管理者のロールを持つユーザーです。)

2. 次のテンプレート・アセットをサイトで共有します。
FW_CSGadget/GenerateGadgetXMLおよびFW_CSGadget/ListSiteGadgets

(サンプル・ガジェットを再利用する場合は、FirstSiteIIのテンプレートを共有し、該当するアセット・タイプを有効にし、必要に応じてアセットを共有します。たとえば、RSS Feedガジェットを再利用する場合は、FirstSiteIIのFW_CSGadget/G_RSSテンプレート・アセットを共有し、FW_RSSアセット・タイプを有効にします。)

93.2 カスタム・ガジェット

サンプル・ガジェットのアーキテクチャに関する知識に加え、FW_CSGadgetタイプでは、他のどのようなガジェットが作成可能かについて理解しておくと役立ちます。この項では、各種のガジェットを作成するための要件について説明します。また、RSSフィード・サンプル・ガジェットのディスクリプタXMLで定義されているパラメータについても説明します。

この項の内容は、次のとおりです。

- 第93.2.1項「新しいガジェット、WebCenter SitesはXMLのみを生成」

- 第93.2.2項「新しいガジェット、WebCenter SitesはXMLおよびフィールドの追加リクエストを生成」

- 第93.2.3項「同じガジェット・ロジック、異なるコンテンツ」

- 第93.2.4項「サンプルのRSSFeedガジェットの分析」

93.2.1 新しいガジェット、WebCenter SitesはXMLのみを生成

追加コンテンツのみを他のWebサイトから取得する、新しいガジェットを作成するとします。RSS Feedガジェットは、このように動作するガジェットの例です。第91.3.4項「RSS Feedガジェット」を参照してください。

このシナリオの要件は次のとおりです。

- 次のテンプレートおよびアセットを参照する、FW_CSGadgetタイプのガジェット。

- ガジェット・ディスクリプタXMLの本体を生成するFW_CSGadgetテンプレート(たとえば、FW_CSGadget/G_RSS)。

- ガジェット内でリクエストされるURLを指定するアセット。

93.2.2 新しいガジェット、WebCenter SitesはXMLおよびフィールドの追加リクエストを生成

このシナリオでは、WebCenter SitesのCMサイトの1つから、コンテンツをガジェットに直接読み込みます。List、ThumbListおよびSlideshowガジェットは、このように動作するガジェットの例です。図92-1および図92-2を参照してください。

このシナリオの要件は次のとおりです。

- 次のテンプレートおよびアセットを参照する、FW_CSGadgetタイプのガジェット。

- ガジェット・ディスクリプタXMLの本体をレンダリングするFW_CSGadgetテンプレート(G_Listなど)。

- ガジェット・コードによる追加リクエストへのレスポンスとして返されるデータをレンダリングするテンプレート(たとえば、サンプル・ガジェットに付属のG_JSONテンプレート)。

- ガジェットによって参照されるアセット(またはその追加リクエスト)。

93.2.3 同じガジェット・ロジック、異なるコンテンツ

同じ機能を持ちながら、異なるコンテンツ・セットを取得するガジェットを作成できます。このシナリオの要件は次のとおりです。

- あらかじめ存在するFW_CSGadgetテンプレートを参照するFW_CSGadgetアセット。

- ガジェットにコンテンツを提供するアセット。

93.2.4 サンプルのRSSFeedガジェットの分析

ガジェットのディスクリプタXMLは、ガジェット用に定義されているすべてのデータをModuleタグ内に含みます。このタグには、ガジェットの依存関係、ユーザー・プリファレンス(存在する場合)、外観設定、機能などの情報が格納されます。

この項では、例としてサンプルのRSSFeedガジェットのコード・スニペットを使用し、FW_CSGadgetアセットのディスクリプタXMLファイルを分析します。

RSSFeedガジェットのディスクリプタXMLファイルのコード分析

これらの行は、ガジェットのプロパティおよび依存関係を指定します。

<ModulePrefs title="FatWire RSS" height="350">
screenshot="http://localhost:8100/cs/FirstSiteII/gadgets/RSS/screenshot.png"
thumbnail="http://localhost:8100/cs/FirstSiteII/gadgets/RSS/thumbnail.png">
<Require feature="dynamic-height"/>
</ModulePrefs>

次の行は、訪問者が変更可能なガジェットの値であるガジェットのユーザー・プリファレンスを定義する行です。このコード・スニペットでは、訪問者はRSSFeedガジェットが一度に表示するニュース・フィードの数を選択できます。

<UserPref name="max" display_name="Number of Items"
datatype="enum" default_value="5">
<EnumValue value="1" display_value="1"/>
<EnumValue value="3" display_value="3"/>
<EnumValue value="5" display_value="5"/>
<EnumValue value="10" display_value="10"/>
</UserPref>

Contentタグには、RSSFeedガジェットのディスクリプタXMLファイルのすべてのコンテンツが格納されます。これには、ガジェットの外観を定義するガジェットのCSSファイル、およびガジェットのインタラクティブなコンテンツと初期化機能を指定するガジェットのJavaScript(<script>タグ内に格納される)が含まれます。

たとえば、RSSFeedガジェットのContentタグ内に定義されるCSSファイルは次のようになります。

<style type="text/css">
/* === generic styles === */
body #container {
padding: 15px;
padding-bottom: 5px; /* 5 plus 10 from bottom-most entry */
margin: 0;
}
body #container * {
padding: 0;
margin: 0;
font-size: 11px;
font-family: Tahoma,Arial,Helvetica,sans-serif;
color: #666;
}
body #container a, body #container * a {
text-decoration: none;
color: #555;
}
body #container a:hover, body #container * a:hover {
color: #3b9cce;
}
.error {
background-color: #fcc;
color: #c00;
}
/* === gadget-specific styles === */
#container .list {
padding-left: 1em; /* provide proper indentation space for bullets */
}
#container .list li {
padding-bottom: 10px;
}
#container .headline {
font-weight: bold;
}
</style>

93.3 ガジェット登録の前提条件

ガジェットがGadgetsアプリケーションで認識されるには、ガジェットを登録する必要があります(通常、Gadgetsアプリケーションの管理者が行います)。ガジェットには、そのガジェット・ディスクリプタXMLを生成するWebCenter Sites URLを通じてアクセスします。このURLは、FW_CSGadget/ListSiteGadgetsテンプレートを問い合せることによって、コンテンツ管理サイトのすべてのFW_CSGadgetアセットで素早く取得できます。このテンプレートは、次のいずれかの方法で簡単にアクセスできます。

- WebCenter SitesのAdvancedインタフェースで、サイトのFW_CSGadgetアセットをプレビューします。「Insite」ウィンドウで、「テンプレート」ドロップダウン・リストからListSiteGadgetsを選択します。

または

- ブラウザを開き、次のアドレスに直接アクセスします。

http://<host>:<port>/<application context>/wem/<sitename>/FW_CSGadget/ListSiteGadgets

(host、port、application contextは、WebCenter Sitesインストールに対応します。sitenameは、ガジェットが存在するコンテンツ管理サイトの名前です)。

次の図に、サンプル・ガジェットとその対応するURLを一覧表示します。

第IX部

CIP用のJavaコネクタおよびプラグインの開発

この部では、Oracle WebCenter Sites: Content Integration Platformを拡張して、任意のシステムからOracle WebCenter Sitesへパブリッシュする方法を開発者に示します。

この部は、次の章で構成されています。

- 第94章「カスタム・ソース・システムとの統合」

- 第95章「アダプタおよびプラグインの作成」

94 カスタム・ソース・システムとの統合

この章では、Oracle WebCenter Sites: Content Integration Platformを拡張して、カスタム・ソース・システムからOracle WebCenter Sitesへのコンテンツ配信をサポートする方法について説明します。

この章には次の項が含まれます。

- 第94.1項「WebCenter Sites: Content Integration Platformのカスタマイズ」

- 第94.2項「Content Integration Agent」

94.1 WebCenter Sites: Content Integration Platformのカスタマイズ

デフォルトでは、Content Integration Platform (CIP)は、ファイル・システム、Microsoft SharePoint、EMC DocumentumからOracle WebCenter Sitesへコンテンツを配信します。開発者は、ソース・アダプタとプラグインで構成される、またはアダプタのみで構成されるJavaベースの実装を記述することによって、Content Integration Platformを拡張してデータベースやカスタム・コンテンツ管理システムなどの任意のシステムから公開できます。アダプタとプラグインはいずれも、Content Integration Agentコンポーネントによってサポートされます。第94章「カスタム・ソース・システムとの統合」を参照してください。

Oracle WebCenter Sitesに配信されるコンテンツを保持している各ソース・システムでは、Javaソース・アダプタを記述する必要があります。このアダプタはソース・システムに問い合せて、そのメタデータとバイナリ・コンテンツを取得します。アダプタは、catalog.xmlファイル内の文で、Content Integration Agentに登録する必要があります。

プラグインが必要になるのは、WebCenter Sitesに公開する前に、アダプタで取得した項目を処理する必要がある場合のみです。たとえば、イメージ・ファイルからサムネイルを抽出したり、公開時に検証手順を実行したりする処理が考えられます。通常、プラグインは、各種のファイル形式をサポートしたり、公開プロセスから項目を選択してフィルタリングする場合に記述されます。どのアダプタでも、任意の数のプラグインを使用できます。アダプタの場合と同様に、プラグインも(types.xmlファイル内で)Content Integration Agentに登録する必要があります。

94.2 Content Integration Agent

Content Integration AgentはC++で記述されており、Javaベースのカスタム・コネクタおよびプラグインをサポートする次のコンポーネントを提供します。

- 堅牢なライタイム・システム。

- Javaベースのソース・コネクタとプラグインの実装に使用されるプラガブル・インタフェース。

- catalog.xmlおよびtypes.xmlという名前のXMLファイル。どちらもカスタム・ソース・アダプタおよびプラグインの登録に使用されます。

- ネイティブ・ソース・アダプタ(javaconnectorライブラリ)およびネイティブ・プラグイン(javapluginライブラリ)。どちらもC++で記述されています。これらは、Javaコードをコールするために使用します。

- ファシリティ(エージェントのランタイムに一連の機能を提供する構成ブロック)。Content Integration Agentは、C++ランタイム環境からのコールをJavaコードへ委任するために、自身のプロセス空間内にJava仮想マシンをホストします。このJVMは、facilities.xml内でjavafacilityを登録することで有効になります。

Javaベースのアダプタを作成してJVMを有効にしたら、C++エージェント・ランタイム・システムでJVMを使用して、ネイティブ・アダプタを介したJavaコードのコールを実行できるようになります(プラグインでもプロセスは同じです)。

Javaベースのコネクタとプラグインを作成する手順、および統合の実行手順については、第95章「アダプタおよびプラグインの作成」を参照してください。

- Content Integration Agentの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- ファイル・システムおよびMicrosoft SharePoint用のContent Integration Platformの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

- EMC Documentumを対象としたContent Integration Platformの詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

図94-1 Content Integration Platform

95 アダプタおよびプラグインの作成

この章では、任意のソース・システムからWebCenter Sitesへのコンテンツ配信をサポートする完全な統合ソリューションの作成方法について説明します。

この章には次の項が含まれます。

- 第95.1項「アダプタおよびプラグインの作成の概要」

- 第95.2項「Javaソース・アダプタの作成」

- 第95.3項「Javaプラグインの作成」

- 第95.4項「javafacilityの有効化」

- 第95.5項「トラブルシューティングとデバッグ」

95.1 アダプタおよびプラグインの作成の概要

アダプタおよびプラグインの作成には、次の手順が含まれます。

1. Content Integration Agent内で提供されるプラガブル・インタフェースの実装。

2. Content Integration Agentランタイム・システムへの実装の登録。

3. Java仮想マシンによる、C++エージェント・ランタイムからJavaコードへのコールの委任を可能にするためのjavafacilityの登録。

注意:

どのアダプタでも、カスタム・プラグインを使用できます。必要に応じて、任意の数のプラグインを実装してデプロイできます。

カスタム・アダプタ(またはプラグイン)を正常に使用するには、公開可能なオブジェクトのデータ・モデルがWebCenter Sitesシステムに存在していて、かつWebCenter Sitesシステムにマップされている必要があります。次の手順が必要になります。

1. オブジェクト・タイプ、その属性およびオブジェクト自体を格納するための専用のフレックス・ファミリを作成して(または既存のフレックス・ファミリを再利用して)、WebCenter Sites内にオブジェクトのメタデータを再生成します。

2. オブジェクト・タイプと属性を、それぞれのフレックス・ファミリ・アセット・インスタンス(前述の手順で作成したもの)にマップします。このマップは、アダプタの実装内で直接作成できます。または、mappings.xmlファイル内で作成できます。

95.2 Javaソース・アダプタの作成

サポート対象外のソース・システムからWebCenter Sitesに公開するには、Javaベースのソース・アダプタを作成する必要があります。アダプタで取得したオブジェクトを公開する前に処理する必要がある場合を除いて、プラグインは必要ありません。

注意:

リレーショナル・データベースを使用する場合は、アダプタを機能させるためにカスタム・ビューまたはカスタム問合せを実装します。

Javaソース・アダプタを作成するには

1. アダプタを実装します。
IConnector、IProviderSession、IRepository、IItemの各インタフェースを実装します。ソース・システムの項目に主要なバイナリ・コンテンツが含まれている場合は、オプションでInputStreamインタフェースを実装できます。

図95-1は、インタフェース間の関係を示しています。アダプタのコードのエントリ・ポイントは、ファクトリ・クラスであるIConnectorインタフェースの実装です。

図95-1 アダプタおよびプラグインのクラス図

アダプタの存続期間には、様々なフェーズがあります。フェーズに応じて、異なるメソッドが呼び出されます。図95-2は、各フェーズでのコール・シーケンスを示しています。

図95-2 ソース・アダプタのコール・シーケンス

図3 ソース・アダプタのコール・シーケンスの分析

getRepositoryByID関数に渡されるIDは、catalog.xmlファイル内の対応するワークスペース・エレメントの1つから取得されます。

cipcommanderに渡す内容に応じて、次のいずれかの関数が呼び出されます。

- -source_itemidを渡す場合は、getItemByIDが呼び出され、itemidを渡します。

- -source_itemidを省略して-source_pathを指定した場合は、getItemByPath関数が呼び出されます。

- -source_itemid、-source_pathのいずれも指定していない場合は、getTopFolder関数が呼び出されます。(この場合、リポジトリ全体が公開されます。)

一意性を確保するため、同一リポジトリ内のすべての項目で、異なるversionid、itemid、pathを保持し、同一フォルダ内のすべての項目に異なる名前が付与されるようにします。pathは次の形式である必要があります。<parent path>/<this item name>。

2. アダプタを登録します。

1. (integration_agent/conf/内の)catalog.xmlにconnectorエレメントを追加することによって、IConnectorインタフェースの実装をContent Integration Agentに登録します。

<connector id="connector_id" name="connector_descriptive_name">
<library>javaconnector</library>
<init-params>
<param name="className">connector_class_name</param>
connector-specific_parameters
</init-params>
</connector>

パラメータ

説明

connector_id

任意の一意の識別子。

connector_descriptive_name

任意の記述名(一意である必要はありません)。

connector_class_name

作成したIConnector実装の名前。

connector-specific_parameters

コール時にIConnector.initializeに渡されるパラメータ・セット。

2. 次のように、catalog.xmlに新しいproviderエレメントを追加することによって、公開を有効にします。

<provider id="provider_id" name="provider_descriptive_name">
<connector-ref refid="connector_id"/>
<init-params/>
provider-specific_parameters
</init-params>
</ provider >

パラメータ

説明

provider_id

任意の一意の識別子。

provider_descriptive_name

任意の記述名(一意である必要はありません)。

connector_id

アダプタの一意の識別子。

provider-specific_parameters

コール時にIConnector.loginに渡されるパラメータ・セット。

3. アダプタをデプロイします。
アダプタのjarファイルをフォルダ<resource>/java/<connector_id>/lib内に配置し、classファイルを<resource>/java/<connector_id>/classes内に配置します。

<resource>フォルダは、Content Integration Agent内にあります。

Windowsの場合: <resource>は<%INSTALLDIR%>です。

Unixの場合: <resource>は<$INSTALLDIR/shared/cipagent>です。

注意:

様々な実装やロード/アンロード機能との競合を回避するために、アダプタ・クラスは別のクラス・ローダーによってロードされます。すべてのアダプタのjarファイルおよびclassファイルは、CLASSPATH環境変数、java.class.pathプロパティまたはjre/lib/extフォルダではなく、<connector_id>フォルダに配置することを強くお薦めします。

3. Javaプラグインが必要な場合は(アダプタが取得した項目を処理するため)、第95.3項「Javaプラグインの作成」に進んでください。それ以外の場合は、javafacilityを有効にします(Java仮想マシンがC++エージェント・ランタイムからのJavaコード・コールを委任できるようにするため)。手順は、第95.4項「javafacilityの有効化」を参照してください。

95.3 Javaプラグインの作成

注意:

どのアダプタでも、カスタム・プラグインを使用できます。必要に応じて、任意の数のプラグインを作成してデプロイできます。

アダプタで取得したオブジェクトをWebCenter Sitesシステムに公開する前に処理する必要がある場合を除いて、プラグインは必要ありません。プラグインの主な目的は、取得した項目のメタデータを変更したり、取得した項目にメタデータを追加したり、項目を却下したりすることです。

プラグインの作成はアダプタの作成と似ています。その手順を次に示します。

Javaプラグインを作成するには

1. IAssetHandlerインタフェースを(Content Integration Agent内に)実装することによってプラグインを実装します。
プラグインのエントリ・ポイントはIAssetHandlerインタフェースです。これは、ランタイム・システムによって直接使用される唯一のインタフェースです。

ほとんどの場合、実装する必要があるメソッドはExtractMetadataのみです。図95-3は、プラグインの存続期間におけるコール・シーケンスを示しています。

図95-3 プラグインのコール・シーケンス

2. Content Integration Agentにプラグインを登録します。

1. (integration_agent/conf/フォルダ内の)types.xmlファイルに、新しいプラグインhandlerエレメントを追加します。

<handler id="handler_id">
<library>javaplugin</library>
<init-params/>
plugin-specific_parameters
</init-params>
</handler>

パラメータ

説明

handler_id

カスタム・プラグインの一意の識別子。

plugin-specific parameters

プラグインの初期化時に渡されるプラグイン固有のパラメータ。

2. Content Interation Platform for EMC Documentumを使用している場合は、この手順を実行します。それ以外の場合は、手順3に進みます。
選択したハンドラ・セットのハンドラを有効にします。どのハンドラ・セットを使用するかは、公開開始プロセスの実行時に指定します。各ハンドラ・セットにはハンドラのリストが含まれており、それらはContent Integration Agentのメタデータ抽出フェーズで呼び出されます。ハンドラの対応付けは、MIMEタイプまたはアセット・タイプによって行われます。

MIMEタイプは次の形式になります。<major type>/<minor type>

(たとえば、image/jpeg)。MIMEタイプには、*を使用するオプションがあります。これは、minor部分、またはMIMEタイプ全体に適用できます。たとえば、*/*はすべてのアセットと一致し、text/*はテキスト・ファイルとのみ一致します。

IConnectorContext.guessMIMEType関数を使用する場合、この関数は指定されたファイル拡張子に対応するMIMEタイプを取得するためにmimetypes.xmlを参照します。たとえば、パラメータにtxtを指定して呼び出すと、text/plainという結果が生成されます。

また、アセット・タイプでも*の表記がサポートされており、これはすべてのアセット・タイプと一致します。

複数のハンドラが特定の項目と一致する場合は、使用されるハンドラ・セット内での登録順序と同じ順序でそれらのハンドラが呼び出されます。対応するハンドラのいずれかがIItem.extracMetadataのコールからNULLオブジェクトを返す場合、その項目は将来の処理から破棄され、ターゲットのアダプタには送信されません。

3. types.xmlファイルにasset-type要素を追加することによって、選択したオブジェクト・タイプのカスタム・プラグインを有効にします。このプラグインが呼び出される項目は、MIMEタイプに従ってフィルタリングされます。

注意:

プラグインのコンテキスト内のasset-typeエレメントは、MIMEタイプ・グループです。

<asset-type type="MIME_type">
<extensions>
<ext>ext</ext>
. . .
</extensions>
<handler-ref refid="handler_id" />
</asset-type>

パラメータ

説明

MIME type

このプラグインが呼び出される項目のMIMEタイプ。MIMEtypeは、<major_type/minor_type>の形式である必要があります。たとえば、text/plainと指定します。

ワイルドカード記号(*)も使用できます。例:

- すべてのテキスト・ファイルに対してプラグインを有効にするには、次のように指定します。
text/*

- すべての項目に対してプラグインを有効にするには、次のように指定します。
*/*

ext

ファイル拡張子。たとえば、テキスト・ファイルの場合は.txtです。このファイル拡張子は、プラグインの選択プロセスに直接影響を与えるものではありません。これは、MIMEタイプを直接利用できないシステム(ファイル・システムなど)でMIMEタイプを推測する際に使用されます。

handler_id

カスタム・プラグインの一意の識別子(前の手順のhandlerエレメント内で指定したもの)。

4. プラグインをデプロイします。
プラグインのjarファイルをフォルダ<resource>/java/<plugin_id>/lib内に配置し、classファイルを<resource>/java/<plugin_id>/classes内に配置します。

<resource>フォルダは、Content Integration Agent内にあります。

Windowsの場合: <resource>は<%INSTALLDIR%>です。

Unixの場合: <resource>は<$INSTALLDIR/shared/cipagent>です。

注意:

様々な実装やロード/アンロード機能との競合を回避するために、プラグイン・クラスは別のクラス・ローダーによってロードされます。すべてのプラグインのjarファイルおよびclassファイルは、CLASSPATH環境変数、java.class.pathプロパティまたはjre/lib/extフォルダではなく、<plugin_id>フォルダに配置することを強くお薦めします。

3. カスタム・アダプタを作成したものの、まだjavafacilityを有効にしていない場合は、第95.4項「javafacilityの有効化」に進んでください。

95.4 javafacilityの有効化

C++エージェント・ランタイムからJavaコードを呼び出すには、facilities.xml内にjavaという特殊なファシリティを登録する必要があります。

javafacilityを有効にするには

1. facilities.xmlがコメント化されていないことを確認します(facilities.xmlは、integration_agent/conf/フォルダにあります)。

2. 次の行を追加します。

<facility name="javafacility">
<library>java</library>
<init-params>
<param name="VMArgparam_id">Java_VM_argument
</param>
<param name="VMLibraryPath">VM_library_path</param>
</init-params>
</facility>

パラメータ

説明

param_id

パラメータの一意のID(任意の一意の値)。JVMに複数の引数を渡すには、異なるparam_idを使用して複数のパラメータを構築します。

Java_VM_argument

エージェント・ランタイム・プロセス内で作成され、Java VMに渡されるJava VM引数。

例:

<param name="VMArg0">-Xmx256m

</param>

VM_library_path

JRE/JDKインストール内のJava VMライブラリ(DLLまたは共有ライブラリ)のフルパス。

たとえば、Windows版のSun JDKでは、VM_library_pathは次のいずれかになります。

%JAVA_HOME%\jre\bin\server\jvm.dll

または

%JAVA_HOME%\jre\bin\client\jvm.dll

95.5 トラブルシューティングとデバッグ

CIPのカスタム・コンポーネントを開発する場合、本番環境に表示されるデフォルトのロギング・メッセージ以外の情報があると役立つことがあります。CIP Agentでは、次の5つのロギング・レベルをサポートしています。

- fatal

- error

- warning

- info

- debug

次の指示に従って、CIPのカスタム・コンポーネントをデバッグしてください。

注意:

次に示す設定は、システムのパフォーマンスを低下させる可能性があるため、本番システムでは使用しないでください。

- CIP Agentのロギング・レベルのエスカレート
デフォルトでは、CIPはerrorに設定されています。ロギング・レベルを上げるには、CIP Agentをコンソール実行プログラムとして実行する必要があります。

1. CIP Agentシステム・サービスを停止します。

2. cipagent -t debugコマンドを実行します。

- Javaカスタム・コンポーネントのデバッグ
Agentランタイム内にホストされるカスタムのJava実装をデバッグするには、CIP Agentでリモート・デバッグを有効にします。たとえば、ポート7007でリモート・デバッガを開始し、デバッガがアタッチされるまでCIP Agentを一時停止するには、javafacilityに次の行を追加します。

<param name="VMArg1">-Xdebug</param>
<param name="VMArg2">-Xrunjdwp:transport=dt_socket,
address=7007,server=y,suspend=y</param>

- Sites Agent Servicesのロギング・レベルのエスカレート
Sites Agent Servicesアプリケーションのエラーに関するより詳細なデータを取得するには、com.fatwire.logging.csagentservicesカテゴリのcommons-logging.propertiesファイル内でDEBUGレベルを設定します。また、com.fatwire.logging.cs.dbカテゴリのcommons-logging.propertiesファイル内のDEBUGレベルを設定することもお薦めします。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。