| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
 前へ |
 次 |
ホーム > Content Server開発者ガイド > カスタム・コンポーネントの作成
| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
前へ |
次 |
ホーム > Content Server開発者ガイド > カスタム・コンポーネントの作成
この章では、Oracle WebCenter Content Serverで使用するカスタム・コンポーネントを作成する方法について説明します。
この章では、次の項目について説明します。
カスタム・コンポーネントを使用すると、システムのデフォルトの変更、新機能の追加または反復性の機能の整備ができます。カスタム・コンポーネントを作成および使用して、システムの整合性を失わないでコンテンツ・サーバーのインスタンスを変更できます。
コンテンツ・サーバーをカスタマイズするには、次のタイプのリソースを使用できます。
HTMLインクルード
動的データ表
文字列リソース
動的表
静的表
問合せ
サービス
テンプレート
環境リソース
インクルードは、HTMリソース・ファイルの<@dynamichtml name@>タグと<@end@>タグの中に定義されます。続いてインクルードは、次の構文を使用して呼び出されます。
<$include name$>
インクルードには、Idocスクリプトおよび有効なHTMLコード(JavaScript、Javaアプレット、カスケード・スタイルシート、コメントなど)を含めることができます。インクルードは、呼出し元と同じファイルで定義するか、または別のHTMファイルで定義することができます。標準的なHTMLインクルードは、IdcHomeDir/resources/core/idocファイルで定義されます。
HTMLインクルード、文字列および静的表は、同じHTMファイルにあってもかまいません。HTMLインクルード・リソースには、マージ・ルールは不要です。
既存のHTMLインクルードに対する例外を定義するには、superタグを使用します。superタグはインクルードに対して、既存のインクルードで始め、指定されたコードを使用して、そのインクルードに追加するか、またはそのインクルードを変更するように指示します。
superタグが特に役立つのは、大規模なインクルードに小規模なカスタマイズを行う場合や、ソフトウェアが次のバージョンになったときに変わる可能性の高い標準コードをカスタマイズする場合です。新しいバージョンのOracle WebCenter Content Serverにアップグレードする場合は、superタグによって、コンポーネントが、最新バージョンのインクルードを使用し、インスタンスのカスタマイズに必要な特定のコードのみを変更するようになります。
superタグでは、次の構文を使用します。
<@dynamichtml my_resource@>
<$include super.my_resource$>
exception code
<@end@>
superタグを使用して、標準的なインクルードまたはカスタム・インクルードを参照できます。superタグには、最後にロードされたインクルードが組み込まれます。
|
注意: superタグの配置によって、Idocスクリプトがどのように評価されるかが決まります。 |
例15-1は、superタグの使用例を示しています。
この例では、コンポーネントによって、my_resourceインクルードが次のように定義されます。
<@dynamichtml my_resource@>
<$a = 1, b = 2$>
<@end@>
後でロードされた別のコンポーネントでは、superタグを使用して、my_resourceインクルードが拡張されます。次の拡張を行うと、aには値1が割り当てられ、bには値3が割り当てられます。
<@dynamichtml my_resource@>
<$include super.my_resource$>
<!--Change "b" but not "a" -->
<$b = 3$>
<@end@>
コンポーネント・ウィザードを使用して既存のHTMLインクルード・リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「インクルード」タブをクリックします。
「カスタムHTMLインクルード」リストでインクルードを変更します。
既存のインクルードを編集するには、インクルードを選択して「編集」をクリックし、コードを変更して「OK」をクリックします。
リソース・ファイルにインクルードを追加するには、「追加」をクリックします。
インクルードを削除するには、インクルードを選択して「削除」をクリックし、「はい」をクリックして確定します。
動的データ表のリソースはdynamicdata表です。このタイプのリソースを使用すると、HTML表定義、インタフェース・メニュー・アクション、またはメタデータ・フィールドに関する情報をロードするIdocスクリプト内から、あるいは、SharedObjectにロードされた静的表に対する代替としてJavaコード内から、データの表を定義できます。
SharedObjectにロードされる表は静的でめったに変更されませんが、dynamicdata表がユーザーのコンテキストにロードされると、コンテンツ・サーバー内の数多くのコードによって、この表の内容が変更されます。dynamicdataのリソースを使用すると、ユーザーが実行している具体的なアクションに対するセキュリティ属性の任意の要素に応じて、様々なデータをユーザーの画面に表示できます。コンポーネントは、このリソース・タイプで作成された表に、ターゲットを絞ったマージを実行でき、Idocスクリプト・ページは行の選択とソートができます。
例15-2に示すように、dynamichtml構成を含めることのできる任意のリソース・ファイルで、dynamicdataリソースを宣言できます。
例15-2 dynamicdataリソース
<@dynamicdata NameOfTable@> <?formatoftable properties-of-table?> table-data <@end@>
dynamicdata表は、リソース・ファイルの<@dynamicdata name@>タグと<@end@>タグの中に定義されます。dynamicdata表を参照するには、Idocスクリプトの関数を使用する必要がありますが、その関数は、ddLoadResultSetのように、名前の先頭がddで、マージされたdynamicdata表をロードし、現在のデータ・バインダにResultSetを作成するものです。
IdcHomeDir/resources/core/idocファイルでは、標準的なdynamicdataリソースを定義します。
dynamicdataリソースのformatoftableパラメータでは、次の2つの形式タイプのいずれかを指定できます。
commatable
htmltable
デフォルトの形式はcommatableです。
commatable
commatableとは、値に行送りも改行もない表の形式です。例15-3に示すように、この形式では、フィールド名のカンマ区切りのリストを1つの行に入力し、値のカンマ区切りのリストを後続の行に入力できます。この場合、1行の対象が各フィールドになります。
例15-3 commatable形式
<@dynamicdata SampleTable@> <?commatable?> col1, col2 val1_1, val1_2 val2_1, val2_2 <@end@>
値にカンマ(,)を挿入する必要がある場合は、カンマでなく曲折アクセント記号(^)を使用します。例15-4に示すように、曲折アクセント記号を挿入する必要がある場合は、エスケープ・シーケンスのハッシュ-曲折アクセント記号(#^)を入力し、ハッシュまたは曲折アクセント記号が後に続くハッシュ(#)を挿入する必要がある場合は、エスケープ・シーケンスのハッシュ-ハッシュ(##)を入力します。
このdynamicdataリソースでは、field1の値がA,B、field2の値がC#^D^E#F,Gとなる表の行がロードされます。
行送りも改行もエスケープはできません。これらの文字列のいずれかを含む値を指定する必要がある場合は、htmltable形式を使用してください。
htmltable
例15-5に示すように、htmltable形式は、コンテンツ・サーバーにおける静的なHTML表構成と同じ形式です。
コンポーネント・ウィザードを使用して既存のdynamicdataリソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「インクルード」タブをクリックします。
カスタム・リソース定義におけるdynamicdata表のいずれかを変更したり、dynamicdata表を追加したり、dynamicdata表を削除することができます。
既存のdynamicdata表を編集するには、表を選択して「編集」をクリックし、コードを変更して「OK」をクリックします。
リソース・ファイルにdynamicdata表を追加するには、「追加」をクリックします。
dynamicdata表を削除するには、表を選択して「削除」をクリックし、「はい」をクリックして確定します。
dynamicdataリソースのproperties-of-tableパラメータの形式は次のとおりです。
field1="value1" field2="value2" . . .
プロパティは、XMLノードに定義された属性に似ています。例15-6は、一般的な表宣言を示しています。
例15-6 表定義における表のプロパティ
<@dynamicdata ExampleTable@> <?commatable mergeField="fieldA" indexedColumns="fieldA,fieldB"?> fieldA, fieldB 1, 2 3, 4 <@end@>
値を囲む引用符は、空白のない値では省略可能であり、引用符は一重と二重のどちらでも使用できます。また、プロパティのデフォルト値は"1"であるため、表のプロパティの値が"1"の場合は、値の割当てを省略できます。
この値を省略することは、notrimやmergeBlanksのようなブール型プロパティの場合に役立ちます。例15-7は、値をトリミングしない表を指定する宣言を示しています。
例15-7 notrimプロパティ
<@dynamicdata ExampleTable@> <?commatable mergeField="fieldA" indexedColumns="fieldA,fieldB" notrim?> fieldA, fieldB 1, 2 3, 4 <@end@>
この例では、2または4の前に空白があってもトリミングされません。(フィールド名は常にトリミングされます。)
次の種類の表のプロパティを指定できます。
マージ・プロパティ
アセンブリ・プロパティ
ソート・プロパティ
フィルタとdynamicdata表のプロパティ
dynamicdata表は自動的にまとめてマージでき、これは、これらの表を使用することの力の一部です。名前の同じdynamicdata表が2つ、別々のリソース・ファイルにある場合は、自動的にマージされます。mergeOtherDataオプションを使用して、別の既存の表を現在の既存の表にマージできます。この手法を使用すると、他の様々な表からすべてマージされた複雑な表を構築できます。このマージを行うと、データの可読性を向上でき、一部の表を他の表のサブセットにすることができます。
dynamicdataリソースのproperties-of-tableパラメータで、次のマージ・プロパティを1つ以上指定できます。
mergeKey: マージの実行場所とするフィールドの名前。この値は、オーバーレイを行うときに、この表と既存の表の両方に適用されます。ただし、mergeNewKeyが設定されている場合は、既存の表にのみ適用されます。この値が設定されていない場合は、マージ・キーによって、この表の最初の列がデフォルトに設定されます。mergeKeyが、既存の表に存在していない列を参照している場合は、既存の表にこの表が付加されます。ただし、mergeRuleが、別の結果を指定する値に設定されている場合は除きます。このプロパティにはマージ・スコープが指定されています。
mergeNewKey: この表の中で、既存の表のmergeKey列と比較するときの基準として使用するフィールドの名前。デフォルトは、mergeKeyの値となります。このプロパティにはマージ・スコープが指定されています。
mergeRule: 2つの表のマージを実行するときに使用するルール。このプロパティには3つの値を指定でき、そのデフォルトはmergeです。このプロパティにはマージ・スコープが指定されています。
merge: マージを実行するためにmergeKey(および、指定した場合はmergeNewKey)のプロパティを使用したマージ。
mergenoappend: マージを実行しますが、新規の行はいっさい付加しません。実行する有効なマージがない(たとえば、mergeKeyが、既存の表の有効な列を参照しない)場合は、マージはいっさい実行されず、表が重なっても最終結果に影響はありません。
replace: 既存の表をこの表に置換します。このオプションの結果として、先行する表のリソースが抑制されます。これは、dynamichtmlリソースでスーパー・インクルードを使用しないのと同じです。
mergeBlanks: デフォルトでは、この表から既存の表に値がマージされたときには、この表に空白の値があれば、既存の表で重ね合される値は置換されません。これにより、既存の表にある列の値をターゲットに絞り、この表で置換ができます。ただし、このオプションが有効になっている(値なしで設定されているか、あるいは値を1またはtrueにして設定されている)場合は、この表の空白によって、既存の表の空白でない値が置換されます。デフォルトは0(またはfalse)で、このプロパティにはマージ・スコープが指定されています。
mergeAppendColumns: これは、この表における列のカンマ区切りのリストです。このリストで言及されている任意の値では、その列に対するこの表における列値は、その列に対する既存の表における値を置換しませんが、そのかわり、(区切り文字としてカンマを使用して)現在の値に新しい値を付加するか、または新しい値を現在の値に置換します。カンマ区切りのリストにあるサブ値のそれぞれは、key=value形式で、=value部分は省略可能と想定されています。この表で、カンマ区切りのリストに同じキーがある場合、そのkey=valueのペアは、既存の表における値を置換します。たとえば、既存の表に形式a=1,b=2の列値があり、この表に値b=3,c=4がある場合、マージ後はa=1,b=3,c=4となります。このプロパティにはマージ・スコープが指定されています。
cssStyleMergeAppendFormat: これはブール型プロパティで、mergeAppendColumnsプロパティに使用されている区切り文字を変更します。通常の場合、mergeAppendColumnsで言及されているフィールドの値は、名前=値のペアのカンマ区切りのリストで、等号演算子(=)は代入演算子です。このプロパティが有効になっている場合は、リストの区切り文字はセミコロン(;)になり、名前と値のペアは代入にコロン(:)を使用します。そのため、フィールド値の形は、A=1,B=2ではなく、A:1;B:2となります。デフォルトはfalseで、このプロパティにはマージ・スコープが指定されています。
wildcard: 通常の場合、マージが実行されると、マージ・テストで一致比較を行う際に、大文字と小文字が区別されません。このオプションが有効になっている場合は、比較がコンテンツ・サーバーの標準ワイルドカード一致(* = 0個以上の任意の文字、? = 任意の単一文字)です。一般的にこのオプションは、mergeKey以外の列にmergeNewKeyを設定した状態で使用し、多くの場合、mergeKeyは、この表にある有効な列を参照することさえしません。デフォルトは0(またはfalse)で、このプロパティにはマージ・スコープが指定されています。
mergeOtherData: このリソースにマージするための、他のdynamicdataリソースのカンマ区切りのリスト。他のdynamicdataリソースのそれぞれは、全面的にマージされた後にこのリソースにマージされます(それらの他のリソースでもmergeOtherDataを使用している場合は、それらのマージが最初に行われます。コードには再帰削除があります)。参照されているdynamicdataリソースの1つで、複数のファイルに複数の定義がある場合は、このリソースにマージするために使用されるマージ・キーは、その他のリソースでマージ順序が最も高い(最後にマージされる)と定義されたマージ・キーです。このdynamicdataリソース(mergeOtherDataプロパティのあるリソース)で、複数のファイルに複数の定義がある場合は、マージ・スタックにあるすべてのリソースから参照された名前付きリソースをすべてマージすることによって、mergeOtherDataパラメータが生成されます。デフォルトはNULLで、グローバルなスコープが指定されています。
dynamicdataリソースのproperties-of-tableパラメータで、次のアセンブリ・プロパティを1つ以上指定できます。
notrim: このオプションは、commatable形式にのみ適用されます。通常の場合は、表のリソースに対して解析されるすべての値がトリミングされます。このオプションを設定すると、値はトリミングされません。これはめったに使用されないオプションと推定されます。デフォルトは0(またはfalse)で、このプロパティにはローカルな表スコープが指定されています。
indexedColumns: このプロパティは、索引付き参照用に最適化する必要のある列をリストしています。Idocスクリプトの特殊関数は、索引付き列のいずれかを利用するために存在しています。索引付き列に対して参照を行うときには、列名と値を指定する必要があります。索引付き列の値と関数に渡された値が(大文字と小文字を区別して)一致した行のみで構成される、フィルタリング済表が返されます。これらの索引付き列の参照がすべて、ロード時およびマージ時に計算され、すぐに取り出せるようにハッシュ表に格納されることに注意してください。すべての重なり合う表の索引付き列の値のリストがまとめてマージされ、索引計算はマージの終了後に行われます。このプロパティにはグローバルな表スコープが指定されています。
countColumn: この値は、全面的にマージされた表の中で、行数の値が入力される列を指定します。このカウントは1で始まり、表の中の行ごとに増えていきます。マージされた表のその列に値がある場合は、その値がカウント値に置換されます。このプロパティを使用すると、行ごとに迅速な一意のキーを作成できます。このプロパティのデフォルト値はcountなので、countという名前の列があって、別のcountColumnを指定していない表があれば、その列にカウンタ値が自動的に入力されます。このプロパティの値は、最終的にマージされた表の列名と一致していない場合には無視されます。重ね合せる側の表のリソースで、前の表のリソースで指定されたものとは異なるcountColumnが指定されている場合は、重ね合せる側の表のリソースが使用されます。このプロパティにはグローバルな表スコープが指定されています。
defaultValues: このプロパティは、表に適用するデフォルト値のカンマ区切りのリストを指定します。このリストにあるそれぞれのデフォルト値は、fieldname:valueという形式です。値が空の文字列の場合は、コロンを省略できます。たとえば、文字列field1:val1,field2:val2,field3では、デフォルト値を、field1にはval1、field2にはval2、field3には空の文字列と指定します。コロンは星印(*)で代用でき、星印は、その前にハッシュ(#)を置くことで避けることができます。ハッシュと星印のいずれかがハッシュに続く場合は、ハッシュをもう1つ追加することでハッシュを避けることができます(カンマのエスケープについて、前に説明したルールと同じ)。最終的にマージされた表に、デフォルト値の構成で指定されたフィールドがない場合は、新規のフィールドとして追加され、その表のすべての行のデフォルト値が指定されます。そのフィールドがある場合は、その表でそのフィールドに空白の値があれば、デフォルト値が優先されます。新しい重ね合せる側の表のdefaultValuesの定義が、既存の表の実際の定義と照合されます。あるデフォルト値の定義に競合があった場合は、新しい重ね合せる側の表が優先されます。このプロパティのデフォルトはNULLで、グローバルな表スコープが指定されています。
derivedColumns: このプロパティは、他の列の値から構築する列を指定します。一般的な構文は、導出された列定義のカンマ区切りのリストで、そのフォームはderivedColumnDef1,derivedColumnDef2,...であり、それぞれの列定義はfieldName:sourceField1+sourceField2+...というフォームです。fieldNameは、作成されるフィールドの名前を指し、sourceFieldNは、導出された列を作成するときのソースとなる値を持つフィールドを指します。導出された列には、二重コロン(::)で区切られたソース・フィールドの値が保持されます。導出された列があり、そこに空でない値が入っている場合は置換されません。defaultValuesプロパティの場合と同様に、最終的な表がアセンブルされた後に2番目のパスがあり、導出された値のいずれかに入力する必要がまだあるかどうかが判別されます。導出された列の最も代表的な使用法としては、マージ基準を指定するために、1つのdynamicdataリソースで、1つの列だけでなく複数の列を使用できるようにすることです。導出された列は、マージのターゲットとして使用され、既存の表の定義で定義されます。導出された列の定義は、新しい重ね合せる側の表に継承されます。また、ある導出された列の定義に競合があった場合は、新しい重ね合せる側の表の定義が優先されます。そうでない場合は、既存の表と新しい表の、導出された列の定義がまとめて照合されます。このプロパティのデフォルト値はNULLで、グローバルな表スコープが指定されています。
dynamicdataリソースのproperties-of-tableパラメータで、次のソート・プロパティを1つ以上指定できます。
sortColumn: ソートする列を選択します。重ね合せる側の表のリソースで、前の表のリソースで指定されたものとは異なるsortColumnが指定されている場合は、重ね合せる側の表のリソースが使用されます。この列の名前が、最終的にマージされた表の列名と一致していない場合には、ソートは実行されません。デフォルト値はsortOrderです。そのため、この名前の列を作成すると、表が自動的にソートされます。このプロパティにはグローバルな表スコープが指定されています。
sortType: ソートされる列をどのデータ型と想定するかを指定します。この型は、sortColumnとsortParentColumnの両方に適用されます。この値は、int、stringまたはdateです。このプロパティのデフォルト値はintです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。
sortOrder: ソートを実行するときに使用するソート順序を指定します。使用可能な値は、asc(昇順の場合)とdesc(降順の場合)です。デフォルトはascです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。
sortIsTree: ソートが実際に、sortChildColumnとともにsortParentColumnがソートされたツリー・ソートであるかどうかを指定します。その場合は、sortParentColumnにおける子の行の値を使用して、そのsortChildColumnフィールドで値が一致している親の行を見つけることによって、子から親への行マッピング関係が行われると想定されています。最上位レベルの親が最初にソートされ、次に、それぞれの親の子がそれぞれの親のサブグループとしてソートされ、さらに子のすべての子が再帰的にソートされるというようにソートが実行されます。デフォルト値は0(またはfalse)です。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。
sortParentColumn: この値は、sortIsTreeオプションが有効になっている場合に指定する必要があります。このプロパティの値が欠落しているか、または無効な列を指定している場合、sortIsTreeオプションは無視され、効果はありません。その内容の詳細は、sortIsTreeプロパティの前述の説明を参照してください。sortParentColumnプロパティのデフォルトはNULLです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルなスコープが指定されています。
sortChildColumn: この値は、sortIsTreeオプションが有効になっている場合に指定する必要があります。このプロパティの値が欠落しているか、または無効な列を指定している場合、sortIsTreeオプションは無視され、効果はありません。その内容の詳細は、sortIsTreeプロパティの前述の説明を参照してください。sortChildColumnプロパティのデフォルトはNULLです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルなスコープが指定されています。
sortNestLevelColumn: この値は、sortIsTreeオプションが有効になっている場合にのみ使用できます。このプロパティの値は、無効な列を参照している場合には効果がありません。有効な列が指定されている場合、その列は、そのネスト・レベル(最初の値は0)を指定する整数値を取得します。ネスト・レベルは、自身に親のない親に到達するまでに横断する必要のある、直接の親の数として定義されます。このプロパティのデフォルト値はnestLevelで、グローバルなスコープが指定されています。
dynamicdataリソースのproperties-of-tableパラメータで、次のフィルタおよびインクルードのプロパティを1つ以上指定できます。
filterInclude: このプロパティは、表(索引付きの列が副表の選択に使用されている場合は副表)の各行に実行するインクルードを指定します。これは、現在のユーザーのコンテキストに表がロードされたときに実行されます。その主な目的は、副作用を生みだすこと、または行を除外する必要があるかどうかを判別することです。最終的な結果セットに行がロードされないようにするために、変数ddSkipRowを1(<$ddSkipRow=1$>)に設定できます。このインクルードの実行時に表はアクティブにされ、表の値へのアクセスと値の置換を簡単にできます。このプロパティのデフォルト値はnullで、グローバルなスコープが指定されています。
includeColumns: このプロパティは、実行するリソース・インクルードの名前が行の値になっている列のカンマ区切りのリストを指定します。リソース・インクルードが実行された後で、結果が結果セットにフィードバックされ、その行のその列の新しい値となります。実行のタイミングおよびルールはfilterIncludeと同じですが、includeColumnsでは、行をロードすることを抑制できません。フィルタ・インクルードが指定され、アクティブなインクルード列がある場合は、一時的にアクティブな結果セットをループ処理する際に、インクルード列の値が最初に実行され、次にフィルタ・インクルードが実行されます。最終的にマージされた表に、指定されたインクルード列のいずれかがない場合は、効果はありません。インクルード列にある空の値は無視されます。includeColumns属性は、一般的にはdefaultValues属性と結合され、他の列から値が導出される列が作成されます。このプロパティのデフォルト値はnullで、グローバルなスコープが指定されています。
|
注意: includeColumnsは、最初に表示されたときほどには役に立たないことがあります。リソース・インクルードが実行されるのは、表をロードするためにIdocスクリプトの関数が実行されたときですが、出力をカスタマイズするコンポーネントによって列の値が決定されるのが、さらに処理を行った後(この表に他の表がマージされたり、行統計のサマリーが計算されたりなどした後)に限定される場合もあります。 |
動的データ表の場合は、次のdynamicdata Idocスクリプト関数を使用できます。
ddAppendIndexedColumnResultSet
ddAppendResultSet
ddApplyTableSortToResultSet
ddGetFieldList
ddIncludePreserveValues
ddLoadIndexedColumnResultSet
ddLoadResultSet
ddMergeIndexedColumnResultSet
ddMergeResultSet
ddMergeUsingIndexedKey
ddSetLocal
ddSetLocalByColumnsFromFirstRow
ddSetLocalByColumnsFromFirstRowIndexed
ddSetLocalEmpty
ddSetLocalEmptyByColumns
stringリソースは、エラー・メッセージおよびコンテンツ・サーバーWebページとアプレットで使用される、ロケールに依存するテキスト文字列を定義します。Webページがアセンブルされるか、アプレットが開始されるか、またはエラー・メッセージが表示されるたびに、文字列がコンテンツ・サーバーによって解決されます。
stringは、次の形式を使用して、HTMファイルで定義されます。
<@stringID=Text string@>
stringは、次のIdocスクリプト関数を使用して、HTMテンプレートから呼び出されます。
<$lc("wwStringID")$>
|
注意: コンテンツ・サーバーWebページでは、ww_strings.htmファイルには文字列のみを使用してください。 |
標準的な英語文字列は、IdcHomeDir/resources/core/langディレクトリで定義されます。他にサポートされている言語の文字列は、ローカライゼーション・コンポーネントによって提供されます。
HTMLインクルード、文字列および静的表は、同じHTMファイルにあってもかまいません。stringリソースには、マージ・ルールは不要です。
string値に次の特殊文字を含めるには、HTMLエスケープ・エンコーディングを使用する必要があります。
| エスケープ・シーケンス | 文字 |
|---|---|
&at; |
@ |
\&lf; |
行送り(ASCII 10) |
\&cr; |
改行(ASCII 13) |
\&tab; |
タブ(ASCII 9) |
\&eatws; |
次の空白以外の文字まで空白を食いつぶします。 |
\< |
<(より小さい) |
\> |
>(より大きい) |
\&sp; |
空白(ASCII 32) |
\&#xxx; |
10進数で表すASCII文字(nnn) |
すべての言語にシングルバイト文字がある場合、またはマルチバイト文字がある場合は、言語識別子接頭辞を使用して、同じリソース・ファイルで複数の言語の文字列を指定できます。例15-8は、リソース・ファイルにおける、複数の言語による文字列の接頭辞を示しています。
例15-8 同じリソース・ファイルにおける複数の言語
<@myString=Thank you@> <@es.myString=Gracias@> <@fr.myString=Merci@> <@de.myString=Danke@>
|
注意: シングルバイト文字列とマルチバイト文字列は、同じリソース・ファイルで指定しないでください。シングルバイト文字列用とマルチバイト文字列用に、別々のリソース・ファイルを作成してください。 |
カスタム文字列リソースでマルチバイト文字列を指定する場合は、HTMLページでのキャラクタ・セット指定が、適切なエンコーディングに変更されるようにしてください。リソース・ファイルには正しいhttp-equiv charsetタグを指定して、コンテンツ・サーバーが正しく読み取るようにしてください。
テキスト文字列には変数パラメータを含めることができ、そのパラメータは、中カッコ内にパラメータ引数を配置(たとえば、{1})することによって指定されます。文字列がローカライズされると、この引数は、文字列ID、およびロケール情報を含むExecutionContext値とともに渡されます。パラメータ化された文字列の構文は次の表のとおりです。
| 構文 | 意味 | 例 |
|---|---|---|
| {{} |
開始側の中カッコ。(リテラルとして表現する必要があるのは、開始側の中カッコのみです。) | {{}中カッコ内のテキスト} |
| {n} | n番目の引数を代入します。 | コンテンツID {1}が見つかりません |
| {ni} | n番目の引数を整数形式で代入します。 | dID {1i}は存在しません |
| {nx} | n番目の引数を16進数の整数形式で代入します。 | |
| {nd} | n番目の引数を日付形式で代入します。 | リリース日は{1d}です |
| {nD} | n番目の引数を日付形式で代入します。引数はODBC形式にする必要があります。 | リリース日は{1D}です |
| {nt} | n番目の引数を日時形式で代入します。 | リリース日は{1t}です |
| {ne} | n番目の引数を経過時間形式で代入します。 | |
| {nT} | n番目の引数を日時形式で代入します。引数はODBC形式にする必要があります。 | リリース日は{1T}です |
| {nfm} | n番目の引数を浮動小数点形式で代入します。 | 距離は{1f3}マイルです。 |
| {nk} | n番目の引数を使用してローカライズした文字列を文字列IDとして代入します。 | {2}の{1k}リビジョンが見つかりません |
| {nm} | n番目の引数を、文字列スタック・メッセージであるかのようにローカライズします。(たとえば、引数には、連結されたテキスト文字列およびローカライズされた文字列IDを含めることができます。) | 索引付けの内部エラー: {1m} |
| {nl} | n番目の引数をリストとして代入します。数は、カンマ(,)およびカレット(^)を区切り文字とするリストである必要があります。 | アドオン: {1l} |
| {nK} | カンマで区切られたローカライゼーション・キー名のリストを利用し、各キーをリストにローカライズします。 | サポートされていないバイト機能: {1K} |
| {nM} | メッセージ文字列のリストを利用し、各メッセージをリストにローカライズします。 | {1q}コンポーネント、バージョン{2q}は、現在有効になっているバージョンより古いバージョンの機能を提供します。{3M} |
| {nq} | n番目の引数がNULLでなく、長さがゼロでない場合は、引用符で引数を代入します。それ以外の場合は、文字列syUndefinedを代入します。 | コンテンツ・アイテム{1q}を正常にチェックインできませんでした。 |
| {no} | n番目の引数に対して、順序を示す代入を実行します。たとえば、1st、2nd、3rdなどです。引数は整数である必要があります。 | "I am {1o}."で引数を7とすると、"I am 7th."にローカライズされます。 |
| {n?text} | n番目の引数の値が1でない場合は、テキストを代入します。 | {1}ファイル{1?s}が削除されました |
| {n?text1:text2} |
必要なだけの数の置換変数を使用して(n?)関数を拡張できます。リスト内の最後の変数は常に、値1に対応します。 |
There {1?are:is} currently {1} active search{1?es}. |
| {n?text1:text2:text3} |
必要なだけの数の置換変数を使用して(n?)関数を拡張できます。リスト内の最後の変数は常に、値1に対応します。 |
Contact {1?their:her:his} supervisor. |
コンポーネント・ウィザードを使用して既存の文字列リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「文字列」タブをクリックします。
「カスタム・文字列」リストで文字列を変更します。
既存の文字列を編集するには、文字列を選択して「編集」をクリックし、文字列テキストを変更して「OK」をクリックします。
リソース・ファイルに文字列を追加するには、「追加」をクリックします。
文字列を削除するには、文字列を選択して「削除」をクリックし、「はい」をクリックして確定します。
動的表のリソースは、HDAファイル形式で定義されます。HDA ResultSet表の詳細と例は、第9.1.3.1.1項「HDAファイル内の要素」を参照してください。
カスタム・リソースのデータによって既存の表のデータが置換される場合は、動的表にマージ・ルールが必要です。カスタム・リソースのデータが新規の表に配置される場合は、動的表にマージ・ルールは不要です。
静的表、HTMLインクルードおよび文字列は、同じHTMファイルにあってもかまいません。
カスタム・リソースのデータによって既存の表のデータが置換される場合は、静的表にマージ・ルールが必要です。カスタム・リソースのデータが新規の表に配置される場合は、動的表にマージ・ルールは不要です。
問合せリソースは、コンテンツ・サーバーのデータベース内の情報を管理するために使用されるSQL問合せを定義します。問合せをサービス・スクリプトで使用して、データベースに対するデータの追加、削除、取得などのタスクを実行します。
コンテンツ・サーバーの標準的な問合せは、IdcHomeDir/resources/core/tables/query.htmファイルのQueryTable表に定義されています。特殊目的の問合せは、IdcHomeDir/resources/core/tablesディレクトリに格納されているindexer.htmファイルとworkflow.htmファイルにもあります。問合せリソースにマージ・ルールは不要です。
問合せリソースは、name、queryStr、parametersの3つの列があるResultSet表を使用したHTMファイルで定義されます。
name列では、各問合せの名前を定義しています。既存の問合せをオーバーライドするには、同じ名前をカスタム問い合わせに使用します。新規の問合せを追加するには、一意の問合せ名を使用します。新規の問い合わせに名前を付けるときには、次の文字のいずれかを名前の先頭に付けて、問合せのタイプを特定します。
| 先頭文字 | 問合せのタイプ |
|---|---|
D |
削除 |
I |
挿入 |
Q |
選択 |
U |
更新 |
queryStr列では、問合せ式を定義しています。問合せ式は、SQLの標準構文にします。データベースに渡すパラメータ値がある場合、その場所は、疑問符(?)をエスケープ文字として固定されます。
parameters列では、サービスから問合せに渡されるパラメータを定義しています。Webブラウザからのリクエストによってサービスが呼び出され、さらにそこから問合せが呼び出されます。HTTPの標準パラメータである問合せパラメータに値を提供するのは、Webブラウザの役割です。ブラウザは、URLから、またはWebページ内のFORM要素から、問合せパラメータを渡すことができます。たとえば、QdocInfo問合せでは、パラメータとしてdID(リビジョンID)を渡す必要があるため、この値は、サービス・リクエストのURLから取得されます。
図15-1に示している標準的なQdocInfo問合せは、IntradocDir/core/config/resources/query.htmファイルで定義されています。この問合せでは、DOC_INFOテンプレート・ページに表示するメタデータ情報が取得されます。このテンプレート・ページは、検索結果ページでユーザーが「情報」アイコンをクリックしたときに表示されるページです。
WebブラウザのURLから渡されるパラメータはdIDであり、これは、コンテンツ・アイテム・リビジョンの一意のID番号です。リビジョンにDELETEDステータスがない場合、問合せ式では、「リビジョン」、ドキュメント、DocMetaの各データベース表から、プライマリ・リビジョンのdIDと一致するデータを選択します。
例15-9に、query.htmファイルの内容を示します。
例15-9 query.htmファイル
<HTML>
<HEAD>
<META HTTP-EQUIV='Content-Type' content='text/html; charset=iso-8859-1'>
<TITLE>Query Definition Resources</TITLE>
</HEAD>
<BODY>
<@table QueryTable@>
<table border=1><caption><strong>Query Definition Table</strong></caption>
<tr>
<td>name</td>
<td>queryStr</td>
<td>parameters</td>
</tr>
<tr>
<td>QdocInfo</td>
<td>SELECT Revisions.*, Documents.*, DocMeta.*
FROM Revisions, Documents, DocMeta
WHERE Revisions.dID=? AND Revisions.dID=Documents.dID AND DocMeta.dID = Documents.dID AND Revisions.dStatus<>'DELETED' AND Documents.dIsPrimary<>0</td>
<td>dID int</td>
</tr>
</table>
<@end@>
</BODY>
</HTML>
コンポーネント・ウィザードを使用して問合せリソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
リソースに複数の表がある場合は、編集する問合せ表を「表名」リストから選択します。
選択した問合せ表を変更します。
表に問合せを追加するには、「追加」をクリックします。
既存の問合せを編集するには、問合せを選択して「編集」をクリックし、問合せ式またはパラメータ、あるいはその両方を変更して「OK」をクリックします。
問合せを削除するには、問合せを選択して「削除」をクリックし、「はい」をクリックして確定します。
サービス・リソースは、コンテンツ・サーバーで実行される関数またはプロシージャを定義します。クライアントとサーバーどちらの側からもサービス・コールを実行できるため、Webブラウザのクライアントの代理としても、システム自体の内部でもサービスを実行できます。次に例を示します。
クライアント側のリクエスト: コンテンツ・サーバーのWebページで「検索」リンクをクリックすると、GET_DOC_PAGEサービスによってWebブラウザに標準的な検索ページが表示されます。このとき、次のURLセグメントが使用されます。
IdcService=GET_DOC_PAGE&Action=GetTemplatePage&Page=STANDARD_QUERY_PAGE
サーバー側のリクエスト: START_SEARCH_INDEXサービスを使用すると、バックグラウンド・スレッドで自動的に、検索索引が更新または再構築されます。
サービスは、クライアントがサーバーと対話したりデータベースにアクセスすることのできる唯一の手段です。いずれのプログラムでもHTMLページでも、コンテンツ・サーバーに情報を要求するサービス、または指定された機能を実行するサービスを実行できます。
コンテンツ・サーバーの標準的なサービスは、IdcHomeDir/resources/core/tables/std_services.htmファイルのStandardServices表に定義されています。特殊目的のサービスは、IdcHomeDir/resources/core/tablesディレクトリに格納されているworkflow.htmファイルにもあります。コンテンツ・サーバーが提供する標準サービスと特殊目的のサービスの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。
サービスが機能を実行する際には、他のリソース定義に左右されます。HTMLを返すサービスでは、テンプレートを指定する必要があります。広く知られている例外はPING_SERVERサービスであり、このサービスはブラウザにページを返しません。
ほとんどのサービスでは問合せを使用します。広く知られている例外はSEARCHサービスであり、このサービスは検索コレクションにリクエストを直接送信します。サービス・リソースにマージ・ルールは不要です。
図15-2に、サービス定義の例を示します。
サービス・リソースは、次の3つの列があるResultSet表を使用したHTMファイルで定義されます。
Name列では、各サービスの名前を定義しています。クライアント側のリクエストでは、これはURLの中で呼び出される名前です。既存のサービスをオーバーライドするには、同じ名前をカスタム・サービスに使用します。新規のサービスを追加するには、一意のサービス名を使用します。
Attributes列では、各サービスの次の属性を定義しています。
| 属性 | 説明 | 例(DELETE_DOCサービスの属性) |
|---|---|---|
| サービス・クラス | サービスで実行できるアクションの一部を決定します。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
| アクセス・レベル | サービスにユーザー・アクセス・レベルを割り当てます。この数値は、使用可能な次のビット・フラグの合計です。
READ_PRIVILEGE = 1 WRITE_PRIVILEGE = 2 DELETE_PRIVILEGE = 4 ADMIN_PRIVILEGE = 8 GLOBAL_PRIVILEGE = 16 SCRIPTABLE_SERVICE=32 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
| テンプレート・ページ | サービスの結果を表示するテンプレートを指定します。サービスの結果にページ表示が必要ない場合は、この属性はnullにします。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
| サービス・タイプ | サービスを別のサービスの内側で実行する場合は、この属性はSubServiceにします。それ以外の場合はnullにします。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
| 通知された件名 | サービスによって通知される件名(サブシステム)を指定します。件名が通知されない場合は、この属性はnullにします。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
| エラー・メッセージ | アクション・エラー・メッセージによってオーバーライドされない場合、サービスによって返されるエラー・メッセージを定義します。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
Actions列では、各サービスのアクションを定義しています。アクションとは、サービス・スクリプトの一部として実行される操作です。アクションは、SQL文の実行、問合せの実行、コードの実行、問合せの結果のキャッシュまたはオプション・リストのロードを行うことができます。各サービスにはアクションが1つ以上含まれていて、実行時に何が起こるかを指定します。
Actions列の<br>タグは、ブラウザ表示のみを目的としたものなので、省略可能です。ただし、</td>タグは、アクションの直後に置くもので、その間に改行を入れてはなりません。アクションは、次の形式を使用して定義されます。
type:name:parameters:control mask:error message
| セクション | 説明 | 例(DELETE_DOCサービスの最初のアクション) |
|---|---|---|
type |
アクションのタイプを定義します。
|
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists
|
name |
アクションの名前を指定します。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
parameters |
アクションに必須のパラメータを指定します。必須のパラメータがない場合は、この部分を空白にしておきます(1つの行の中の2つの列)。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
control mask |
データベースへの問合せ結果を制御します。この数値は、使用可能な次のビット・フラグの合計です。
制御マスクなし=
|
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
Error message |
このアクションで表示するエラー・メッセージを定義します。このエラー・メッセージは、サービスの属性として用意されているエラー・メッセージをオーバーライドします。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
DOC_INFOサービスでは、サービス、問合せおよびテンプレートがまとまってどのように機能しているかの好例が提供されています。図15-3は、DOC_INFOサービスで実行できるアクションを示しています。
例15-10は、IntradocDir/config/resources/std_services.htmファイル内のDOC_INFOサービスの定義を示しています。
例15-10 std_services.htmファイル内のDOC_INFOサービス定義
<HTML>
<HEAD>
<META HTTP-EQUIV='Content-Type' content='text/html; charset=iso-8859-1'>
<TITLE>Standard Scripted Services</TITLE>
</HEAD>
<BODY>
<@table StandardServices@>
<table border=1><caption><strong>Scripts For Standard Services</strong></caption>
<tr>
<td>Name</td><td>Attributes</td><td>Actions</td>
</tr>
<tr>
<td>DOC_INFO</td>
<td>DocSgervice
33
DOC_INFO
null
null<br>
!csUnableToGetRevInfo</td>
<td>5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2
3:mapNamedResultSetValues:DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null
3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)
3:getDocFormats:QdocFormats:0:null
3:getURLAbsolute::0:null
3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null
3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null
3:getWorkflowInfo:WF_INFO:0:null
3:getDocSubscriptionInfo:QisSubscribed:0:null
5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)</td>
</tr>
</table>
<@end@>
</BODY>
</HTML>
次の表では、前述のDOC_INFOサービスの属性について説明します。
| 属性 | 値 | 説明 |
|---|---|---|
Service class |
DocService |
このサービスは、コンテンツ・アイテムに関する情報を提供しています。 |
アクセス・レベル |
33 |
32 =このサービスは、IdocスクリプトのexecuteService関数で実行できます。
|
テンプレート・ページ |
DOC_INFO |
このサービスでは、DOC_INFOテンプレート(doc_info.htm ファイル)を使用しています。アクションの結果がこのテンプレートにマージされて、ユーザーの画面に表示されます。 |
サービス・タイプ |
null |
このサービスは、サブサービスではありません。 |
通知された件名 |
null |
このサービスの影響を受ける件名はありません。 |
エラー・メッセージ |
!csUnableToGetRevInfo |
このサービスが英語コンテンツ・サーバー・システムで失敗した場合は、「リビジョンに関する情報を取得できません。」というエラー・メッセージ文字列が返されます。 |
DOC_INFOサービスでは、次のアクションを実行します。
5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2
| アクション定義 | 説明 |
|---|---|
5 |
問合せを使用してデータベースから情報を取得する、キャッシュされた問合せアクション。 |
QDocInfo |
このアクションでは、query.htmファイル内のQDocInfo問合せを使用して、コンテンツ・アイテム情報を取得します。 |
DOC_INFO |
この問合せの結果がパラメータDOC_INFOに割り当てられ、後で使用できるように格納されます。 |
2 |
CONTROL_MUST_EXIST制御マスクによって、問合せがレコードを返す必要があるのか、アクションが失敗するのかが指定されます。 |
!csItemNoLongerExists2 |
このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、「該当コンテンツ・アイテムはもはや存在しません。」というエラー・メッセージ文字列が返されます。 |
3:mapNamedResultSetValues:DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null
| アクション定義 | 説明 |
|---|---|
3 |
サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
mapNamedResultSetValues |
このアクションでは、DOC_INFO ResultSetの最初の行からdStatusおよびdDocTitleの値を取得して、ローカル・データに格納します。(これによってスピードが上がり、正しい値が使用されるようになります。) |
DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle |
mapNamedResultSetValuesアクションに必須のパラメータ。 |
0 |
制御マスクが指定されていません。 |
null |
エラー・メッセージが指定されていません。 |
3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)
| アクション定義 | 説明 |
|---|---|
3 |
サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
checkSecurity |
このアクションでは、DOC_INFOパラメータに割り当てられているデータを取得し、割り当てられているセキュリティ・レベルを評価して、ユーザーがこのアクションを実行する権限があることを確認します。 |
DOC_INFO |
checkSecurityアクションによって評価されるセキュリティ情報を含むパラメータ。 |
0 |
制御マスクが指定されていません。 |
!csUnableToGetRevInfo2(dDocName) |
このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、「''{dDocName}"に対する情報を取得できません。」というエラー・メッセージ文字列が返されます。 |
3:getDocFormats:QdocFormats:0:null
| アクション定義 | 説明 |
|---|---|
3 |
サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
getDocFormats |
このアクションでは、query.htmファイル内のQdocFormats問合せを使用して、コンテンツ・アイテムのファイル形式を取得します。ファイル形式のカンマ区切りのリストが、dDocFormatsとしてローカル・データに格納されます。 |
QdocFormats |
ファイル形式の取得に使用される問合せを指定します。 |
0 |
制御マスクが指定されていません。 |
null |
エラー・メッセージが指定されていません。 |
3:getURLAbsolute::0:null
| アクション定義 | 説明 |
|---|---|
| 3 | サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
| getURLAbsolute | このアクションでは、コンテンツ・アイテムのURLを解決し、DocUrlとしてローカル・データに格納します。 |
| 空白 | このアクションではパラメータを利用しません。 |
| 0 | 制御マスクが指定されていません。 |
| NULL | エラー・メッセージが指定されていません。 |
3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null
| アクション定義 | 説明 |
|---|---|
| 3 | サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
| getUserMailAddress | このアクションでは、コンテンツ・アイテムの作者の電子メール・アドレスを解決します。 |
| dDocAuthor,AuthorAddress | このアクションでは、パラメータとしてdDocAuthorとAuthorAddressを渡します。 |
| 0 | 制御マスクが指定されていません。 |
| NULL | エラー・メッセージが指定されていません。 |
3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null
| アクション定義 | 説明 |
|---|---|
| 3 | サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
| getUserMailAddress | このアクションでは、コンテンツ・アイテムがチェックアウトされているユーザーの電子メール・アドレスを解決します。 |
| dCheckoutUser,CheckoutUserAddress | このアクションでは、パラメータとしてdCheckoutUserとCheckoutUserAddressを渡します。 |
| 0 | 制御マスクが指定されていません。 |
| NULL | エラー・メッセージが指定されていません。 |
3:getWorkflowInfo:WF_INFO:0:null
| アクション定義 | 説明 |
|---|---|
| 3 | サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
| getWorkflowInfo | このアクションでは、コンテンツ・アイテムがワークフローの一部かどうかを評価します。WF_INFO ResultSetが存在している場合は、ワークフロー情報がDOC_INFOテンプレートにマージされます。 |
| WF_INFO | このアクションでは、パラメータとしてWF_INFOを渡します。 |
| 0 | 制御マスクが指定されていません。 |
| NULL | エラー・メッセージが指定されていません。 |
3:getDocSubscriptionInfo:QisSubscribed:0:null
| アクション定義 | 説明 |
|---|---|
| 3 | サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。 |
| getDocSubscriptionInfo | このアクションでは、現在のユーザーがコンテンツ・アイテムをサブスクライブしているかどうかを評価します。
|
| QisSubscribed | サブスクリプション情報の取得に使用される問合せを指定します。 |
| 0 | 制御マスクが指定されていません。 |
| NULL | エラー・メッセージが指定されていません。 |
5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)
| アクション定義 | 説明 |
|---|---|
| 5 | 問合せを使用してデータベースから情報を取得する、キャッシュされた問合せアクション。 |
| QrevHistory | このアクションでは、query.htmファイル内のQrevHistory問合せを使用して、リビジョン履歴情報を取得します。 |
| REVISION_HISTORY | この問合せの結果がパラメータREVISION_HISTORYに割り当てられます。DOC_INFOテンプレートでは、このパラメータをループで使用し、各リビジョンに関する情報を表示します。 |
| 0 | 制御マスクが指定されていません。 |
| !csUnableToGetRevHistory(dDocName) | このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。
|
コンポーネント・ウィザードを使用してサービス・リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
リソースに複数の表がある場合は、編集するサービス表を「表名」リストから選択します。
選択したサービス表を変更します。
表にサービスを追加するには、「追加」をクリックします。
既存のサービスを編集するには、サービスを選択して「編集」をクリックし、サービス属性またはアクション、あるいはその両方を変更して「OK」をクリックします。
サービスを削除するには、サービスを選択して「削除」をクリックし、「はい」をクリックして確定します。
テンプレート・リソースは、コンポーネント用にロードされるカスタム・テンプレートの名前、タイプおよび場所を定義します。
実際のテンプレート・ページは、テンプレート・リソース・ファイルで参照される別々の.htmファイルです。テンプレートHTMファイルには、Webページをアセンブルするためにコンテンツ・サーバーが使用するコードが含まれています。テンプレート・ファイル内のHTMLマークアップでは、ページの基本レイアウトが定義され、テンプレート・ファイル内のIdocスクリプトでは、ページのリクエスト時にWebページの追加のHTMLコードが生成されます。HTMテンプレート・ファイルには、最終ページがアセンブルされるまでコンテンツ・サーバーによって解決されないスクリプトが大量に含まれているため、これらのファイルは表示できないWebページです。
HTMファイルのテンプレート・タイプは、次のコンポーネント・ファイルの定義に使用されます。
テンプレート・ページ:標準的なテンプレート・ページは、IdcHomeDir/resources/core/templatesディレクトリの中にあります。
レポート・ページ:標準的なレポート・ページは、IdcHomeDir/resources/core/reportsディレクトリの中にあります。
テンプレート・リソース(templates.hda)は、HDAファイル形式で定義されます。標準的なテンプレートは、IdcHomeDir/resources/core/templates/templates.hdaファイルで定義されます。HDA ResultSet表の詳細と例は、第9.1.3.1.1項「HDAファイル内の要素」を参照してください。
IntradocTemplates表またはSearchResultTemplates表に新規のテンプレート定義をマージする際には、マージ・ルールが必要です。通常、マージはname列にあります。例15-11に、テンプレートのMergeRules ResultSetを示します。
例15-11 MergeRules ResultSet
@ResultSet MergeRules 4 fromTable toTable column loadOrder MultiCheckinTemplates IntradocTemplates name 1 @end
標準的なtemplates.hdaファイルでは、次の3つのResultSet表を定義しています。
IntradocTemplates ResultSet表では、コンテンツ・サーバーのすべてのWebページ(検索結果ページは除く)のテンプレート・ページを定義しています。この表は、次の5つの列で構成されています。
name列では、各テンプレート・ページの名前を定義しています。コンテンツ・サーバーCGI URLおよびコード内では、この名前を使用してテンプレートが参照されます。
class列では、テンプレートの一般カテゴリを定義しています。最も一般的なclassタイプはDocumentです。
formtype列では、ページで実現しようとする特定のタイプの機能を定義しています。formtypeは通常、フォームの名前と同じですが、小文字であることが異なります。
filename列では、テンプレート・ファイルのパスとファイル名を定義しています。この場所は、絶対パスで指定できます。また、テンプレート・ページとテンプレート・リソース・ファイルが同じディレクトリの中にある場合には、テンプレート・リソース・ファイルを基準とした相対パスで指定することもできます。
description列では、テンプレートの説明を定義しています。
VerifyTemplates ResultSet表は、コンテンツ・サーバーで使用されなくなりましたが、この表は、下位互換性を維持するために、レガシー・コードとしてtemplates.hdaファイルに残っています。
SearchResultTemplates表では、検索結果ページのテンプレート・ページを定義しています。テンプレート・ページでは、ライブラリの検索結果ページに問合せ結果がどのように表示されるかを定義しています。問合せ結果ページは、特殊なタイプの検索結果ページです。この表は、次の6つの列で構成されています。
name列では、各テンプレート・ページの名前を定義しています。コンテンツ・サーバーCGI URL、コードおよびWebレイアウト・エディタ・ユーティリティ内では、この名前を使用してテンプレートが参照されます。
formtype列では、ページで実現しようとする特定のタイプの機能を定義しています。ResultsPageは、検索結果ページに対して現在サポートされている唯一のフォーム・タイプです。
filename列では、テンプレート・ファイルのパスとファイル名を定義しています。この場所は、絶対パスで指定できます。また、テンプレート・ページとテンプレート・リソース・ファイルが同じディレクトリの中にある場合には、テンプレート・リソース・ファイルを基準とした相対パスで指定することもできます。
outfilename列は将来使用するためのもので、値は常にNULLです。
flexdata列では、検索結果ページの各行に表示するメタデータを定義しています。flexdata列のテキストの形式は次のとおりです。
Text1 "text 1 contents"%<Tab>Text2"text 2 contents"%
この形式では、各検索結果行の最初の行にはText1値が表示され、2番目の行にはText2値が表示されます。<Tab>は、リテラル・タブ文字を表しています。
flexdataフィールドの内容を定義する際には、Idocスクリプトを使用できます。Webレイアウト・エディタを使用してStandardResultsテンプレートのflexdataを変更することもできます。ただし、それらの変更は、templates.hdaファイルのSearchResultTemplates表でなく、別のファイル(IntradocDir/data/results/custom_results.hda)に保存されます。
description列では、テンプレートの説明を定義しています。
カスタム・コンテンツ管理ページ(multicheckin_doc_man.htm)およびカスタム検索結果ページ(MultiCheckin_search_results.htm)を指すカスタム・テンプレート・リソース・ファイルを、例15-12に示します。
例15-12 カスタム・テンプレート・リソース・ファイル
<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet MultiCheckinTemplates
5
name
class
formtype
filename
description
DOC_MANAGEMENT_LINKS
DocManagement
DocManagementLinks
multicheckin_doc_man.htm
Page containing links to various document management functions
@end
@ResultSet MultiCheckin_2
6
name
formtype
filename
outfilename
flexdata
description
StandardResults
SearchResultsPage
MultiCheckin_search_results.htm
null
Text2 <$dDocTitle$> <$dInDate$>% Text1 <$dDocName$>%
apStandardResultsDesc
@end
テンプレート・ページとレポート・ページは、プレゼンテーション・ページとも呼ばれます。コンテンツ・サーバーでは、これらのページが、Webページ・リクエストの結果をアセンブル、書式設定および提示するために使用されるからです。
標準的なテンプレート・ページは、IdcHomeDir/resources/core/templatesディレクトリの中にあります。標準的なレポート・ページは、IdcHomeDir/resource/core/reportsディレクトリの中にあります。
標準「コンテンツ管理」ページのテンプレート・ファイルはdoc_man.htmです。例15-13に、このファイルの内容を示します。
例15-13 doc_man.htmファイル
<$include std_doctype_html_decl$>
<head>
<$defaultPageTitle=lc("wwContentMgmt")$>
<$include std_html_head_declarations$>
</head>
<$include body_def$>
<$include std_page_begin$>
<$include std_header$>
<table border="0" cellpadding="2" cellspacing="2" width="450" summary="">
<$include std_doc_man_pages$>
</table>
<table cellpadding="7" cellspacing="7" summary="">
<$if showQuickHelp$>
<tr><td><form><INPUT type=Button onClick="QuickHelp('<$getHelpPage("QH_DocMan")$>', 'QH_DocMan')"
value="<$lc("wwQuickHelp")$>"></form></td></tr>
<$endif$>
</table>
<$include std_page_end$>
</body>
</html>
この例では、std_doctype_html_declインクルードは、コンテンツ・サーバーの標準的なドキュメント・タイプを参照しています。<head>要素はページ・タイトルを参照し、headセクションのコードは、std_page.htmリソース・ファイル内のstd_html_head_declarationsインクルード・コードを使用して構築されます。ページ定義におけるその他の要素は次のとおりです。
コンテンツ・サーバーのほとんどのWebページに共通するページ要素は、std_page.htmリソース・ファイル内のインクルード・コードであるbody_def、std_page_beginおよびstd_headerを使用して構築されます。
「コンテンツ管理」ページ上のリンクは、std_page.htmリソース・ファイル内のインクルード・コードを使用して構築されます。
例にある<table>要素では、「コンテンツ管理」ページに「クイック・ヘルプ」ボタンを表示するかどうかを定義しています。
ページの末尾のコードは、std_page.htmリソース・ファイル内のstd_page_endインクルード・コードを使用して構築されます。
図15-4は、「コンテンツ管理」ページを示しています。
標準「ドキュメント・タイプ」レポート・ページのテンプレート・ファイルは、doc_types.htmにあります。例15-14に、このファイルの内容を示します。
例15-14 doc_types.htmファイル
<$include std_doctype_html_decl$>
<head>
<$defaultPageTitle=lc("wwDocumentTypes")$>
<$include std_html_head_declarations$>
</head>
<$include body_def$>
<$include std_page_begin$>
<$include std_header$>
<!--Directory Title--->
<table border="0" cellpadding="0" cellspacing="0" summary="">
<tr>
<td width="75"><$if PageParent$><a href="<$PageParent$>">
<$strTrimWs(inc("open_folder_image"))$></a>
<$endif$></td>
<td colspan="2" width="390"><span class=title><$PageTitle$></span></td>
</tr>
</table>
<$if IsSavedQuery$>
<!---Parameters for historical reports-->
<table border="0" cellpadding="0" cellspacing="0" summary="">
<tr>
<td width="75" height="45"> </td><!---Indent-->
<td><strong><span class=highlightField><$lc("wwReportCreated")$></span> <$ReportCreationDate$></strong></td>
</tr>
</table>
<$endif$>
<!--Directory Header--->
<table border="0" cellspacing="0" summary="">
<tr>
<td width="75" height="45"> </td><!---Indent-->
<td colspan="2" width="390"><$HeaderText$></td>
</tr>
</table>
<!---Doc types report-->
<table border=0 cellpadding=0 cellspacing=0 summary="">
<tr><td> </td></tr>
<tr>
<td align=center width=<$StdPageWidth$>>
<h1 class="underlinePageTitle"><$lc("wwDocumentTypes")$></h1>
</td>
</tr>
<tr><td> </td></tr>
<$if IsMultiPage$>
<!---Navigation Bar-->
<tr>
<td width=565 align="center"><$include std_page_nav_bar$></td>
</tr>
<$endif$>
<tr>
<td>
<table class="xuiTable" width=<$StdPageWidth$> summary="<$stripXml(lc("wwReportResultsTable"))$>">
<tr class="xuiAltHeader">
<td width=12% class="xuiAltHeader" scope="col"></td>
<td width=29% class="xuiAltHeader" scope="col"><$lc("wwDocumentType")$></td>
<td width=49% class="xuiAltHeader" scope="col"><$lc("wwDescription")$></td>
<td width=12% class="xuiAltHeader" scope="col"><$lc("wwImageFileName")$></td>
</tr>
<$rowCount=0$>
<$loop DocTypes$>
<$if rowCount%2 == 0$>
<$rowClass="xuiRow"$>
<$else$>
<$rowClass="xuiAltRow"$>
<$endif$>
<tr class="<$rowClass$>">
<!--Document types are localized to each instance, so we must use direct path to images directory.-->
<td><img src="<$HttpWebRoot$>images/docgifs/<$dGif$>" alt="<$stripXml(lc("wwDoctypeIcon"))$>" border=0></td>
<td><$dDocType$></td>
<td><$dDescription$></td>
<td><$dGif$></td>
</tr>
<$rowCount=rowCount+1$>
<$endloop$>
</table>
</td>
</tr>
</table>
<$include std_page_end$>
</body>
</html>
この例では、std_doctype_html_declインクルードは、コンテンツ・サーバーの標準的なドキュメント・タイプを参照しています。例にある<head>要素はページ・タイトルとメタデータを参照し、headセクションのコードは、std_page.htmリソース・ファイル内のstd_html_head_declarationsインクルード・コードを使用して構築されます。ページ定義におけるその他の要素は次のとおりです。
コンテンツ・サーバーのほとんどのWebページに共通するページ要素は、std_page.htmリソース・ファイル内のインクルード・コードであるbody_def、std_page_beginおよびstd_headerを使用して構築されます。
例にあるDirectory Titleセクションには、開いたフォルダのイメージが表示され、そのイメージが親ページにリンクされて、ページ・タイトルが表示されます。
Parameters for historical reportsセクションには、履歴レポートの元の問合せ日付が表示されます。
Directory Headerセクションには、レポートの説明が表示されます。
Doc types reportセクションには、表のタイトルが表示されます。
Navigation Barセクションには、履歴レポートに2ページ以上が必要な場合に、ページのナビゲーション・バーが表示されます。
次の<table>要素では、最初の部分に表の列ヘッダーが表示されます。
<table>要素の最後の部分はドキュメント・タイプでループし、レポート表の行が作成されます。
ページの末尾のコードは、std_page.htmリソース・ファイル内のstd_page_endインクルード・コードを使用して構築されます。
コンポーネント・ウィザードを使用して既存のテンプレート・リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソースを選択します。
テンプレート定義表を削除するか、またはテンプレート定義を手動で編集するには、「カスタム・リソース定義」領域で「エディタの起動」をクリックします。
リソースに複数の表がある場合は、編集するテンプレート表を「表名」リストから選択します。
選択したテンプレート表を変更します。
表にテンプレート定義を追加するには、「追加」をクリックします。
既存のテンプレート定義を編集するには、定義を選択して「編集」をクリックし、パラメータを変更して「OK」をクリックします。
テンプレート定義を削除するには、定義を選択して「削除」をクリックし、「はい」をクリックして確定します。
環境リソースは、新規変数の値を作成するか既存の値を置換して、構成変数を定義します。カスタム・リソースは、標準的なconfig.cfgファイルがロードされた後でロードされるので、カスタム環境リソースで定義された変数の値が、元の変数の値を置換します。
環境リソースは、次のような名前と値のペア形式を使用して、CFGファイルで定義されます。
variable_name=value
変数の値を定義した後で、次のIdocスクリプト・タグを使用して、テンプレートなどのリソース・ファイル内の変数を参照できます。
<$variable_name$>
環境リソース・ファイルには、次のように#記号で指定されたコメント行を含めることができます。
#Set this variable to true to enable the function.
例15-15に、環境リソース・ファイルの内容を示します。
# Use this to turn on or off alternate row coloring nsUseColoredRows=0 # These are the nested search field definitions. nsFld1Caption=Document Text nsFld1Name= nsFld1Type=FullText nsFld1OptionKey= # nsFld2Caption=Text nsFld2Name=xtext nsFld2Type=Text nsFld2OptionKey= # nsFld3Caption=Date nsFld3Name=xdate nsFld3Type=Date nsFld3OptionKey= # nsFld4Caption=Integer nsFld4Name=xinteger nsFld4Type=Int nsFld4OptionKey= # nsFld5Caption=Option List nsFld5Name=xoptionlist nsFld5Type=OptionList nsFld5OptionKey=optionlistList # nsFld6Caption=Info Topic nsFld6Name=xwfsInfoTopic nsFld6Type=OptionList nsFld6OptionKey=wfsInfoTopicList
ネストされた検索コンポーネントにあるcolored_search_resource.htmテンプレート・リソース・ファイルは、次のようにnsUseColoredRows変数を参照します。
<$if isTrue(#active.nsUseColoredRows)$><$useColoredRows=1, bkgHighlight=1$><$endif$>
標準的な構成変数は、IntradocDir/config/config.cfgファイルで定義されます。構成変数の詳細なリストは、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
コンポーネント・ウィザードを使用して既存の環境リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストでリソース・ファイルを選択します。
「エディタの起動」をクリックします。
テキスト・エディタで構成変数を変更します。
リソース・ファイルを保存して閉じます。
変更内容は、「カスタム環境パラメータ」リストに反映されます。
|
注意: 「カスタム環境パラメータ」リストでの構成設定の表示順は、リソース・ファイルでの実際の表示順とは異なる場合があります。わかりやすく表示するために、テキスト・エディタを起動します。 |
コンポーネント定義ファイルを作成または変更するには、コンポーネント・ウィザードを使用できます。
例15-16は、customhelp_environment.cfgという環境リソース・ファイルを指すコンポーネント定義ファイルを示しています。
例15-16 環境リソースのコンポーネント定義ファイル
<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet ResourceDefinition
4
type
filename
tables
loadOrder
environment
customhelp_environment.cfg
null
1
@end
コンテンツ・サーバーは、カスタム・コンポーネントを適用する前に再起動する必要があります。コンテンツ・サーバーを再起動するには、管理コンソール、停止スクリプトと起動スクリプト、またはFusion Middleware Controlを使用して、WebCenter Content管理対象サーバーを再起動します。
次の例では、stopManagedWebLogicおよびstartManagedWebLogicスクリプトでWebCenter Contentを再起動する方法を示します。
詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンテンツ・サーバーの再起動に関する項を参照してください。
WebCenter Content管理対象サーバーをコマンドラインからスクリプトを使用して再起動する手順は、次のとおりです。
stopManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを停止します。
UNIXスクリプト:
DomainHome/bin/stopManagedWebLogic.sh UCM_server1
Windowsスクリプト:
DomainHome\bin\stopManagedWebLogic.cmd UCM_server1
stopWebLogicスクリプトを使用して管理サーバーを停止します。
UNIXのスクリプト: DomainHome/bin/stopWebLogic.sh
Windowsのスクリプト: DomainHome\bin\stopWebLogic.cmd
startWebLogicスクリプトを使用して管理サーバーを起動します。
UNIXのスクリプト: DomainHome/bin/startWebLogic.sh
Windowsのスクリプト: DomainHome\bin\startWebLogic.cmd
startManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを起動します。
UNIXスクリプト:
DomainHome/bin/startManagedWebLogic.sh UCM_server1
Windowsスクリプト:
DomainHome\bin\startManagedWebLogic.cmd UCM_server1
