| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 12c (12.2.1.3.0) E90143-05 |
|
 前 |
 次 |
この章では、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タグが特に役立つのは、大規模なインクルードに小規模なカスタマイズを行う場合や、ソフトウェアが次のバージョンになったときに変わる可能性の高い標準コードをカスタマイズする場合です。新しいバージョンのコンテンツ・サーバーにアップグレードする場合は、superタグによって、コンポーネントが、最新バージョンのインクルードを使用し、インスタンスのカスタマイズに必要な特定のコードのみを変更するようになります。
superタグでは、次の構文を使用します。
<@dynamichtml my_resource@> <$include super.my_resource$> exception code <@end@>
superタグを使用して、標準的なインクルードまたはカスタム・インクルードを参照できます。superタグには、最後にロードされたインクルードが組み込まれます。
注意:
superタグの配置によって、Idocスクリプトがどのように評価されるかが決まります。
例18-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@>
動的データ表のリソースはdynamicdata表です。このタイプのリソースを使用すると、HTML表定義、インタフェース・メニュー・アクション、またはメタデータ・フィールドに関する情報をロードするIdocスクリプト内から、あるいは、SharedObjectにロードされた静的表に対する代替としてJavaコード内から、データの表を定義できます。
SharedObjectにロードされる表は静的でめったに変更されませんが、dynamicdata表がユーザーのコンテキストにロードされると、コンテンツ・サーバー内の数多くのコードによって、この表の内容が変更されます。dynamicdataのリソースを使用すると、ユーザーが実行している具体的なアクションに対するセキュリティ属性の任意の要素に応じて、様々なデータをユーザーの画面に表示できます。コンポーネントは、このリソース・タイプで作成された表に、ターゲットを絞ったマージを実行でき、Idocスクリプト・ページは行の選択とソートができます。
dynamichtml構成を含めることのできる任意のリソース・ファイルで、dynamicdataリソースを宣言できます。
例18-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とは、値に行送りも改行もない表の形式です。この形式では、フィールド名のカンマ区切りのリストを1つの行に入力し、値のカンマ区切りのリストを後続の行に入力できます。この場合、1行の対象が各フィールドになります。
commatable Format <@dynamicdata SampleTable@> <?commatable?> col1, col2 val1_1, val1_2 val2_1, val2_2 <@end@>
値にカンマ(,)を挿入する必要がある場合は、カンマでなく曲折アクセント記号( ^)を使用します。曲折アクセント記号を挿入する必要がある場合は、エスケープ・シーケンスの番号記号-曲折アクセント記号(#^)を入力し、番号記号または曲折アクセント記号が後に続く番号記号(#)を挿入する必要がある場合は、エスケープ・シーケンスの番号記号-番号記号(##)を入力します。
Special Characters in Values <@dynamicdata SampleTable@> field1, field2 ÂB, C##^D#^E#F^G <@end@>
このdynamicdataリソースでは、field1の値がA,B、field2の値がC#^D^E#F,Gとなる表の行がロードされます。
行送りも改行もエスケープはできません。これらの文字列のいずれかを含む値を指定する必要がある場合は、htmltable形式を使用してください。
htmltable
htmltable形式は、コンテンツ・サーバーにおける静的なHTML表構成と同じ形式です。
例18-3 htmltable形式
<@dynamicdata SampleTable@>
<?htmltable?>
<table>
<tr>
<td>col1</td>
<td>col2</td>
</tr>
<tr>
<td>val11</td>
<td>val12</td>
</tr>
<tr>
<td>val21</td>
<td>val22</td>
</tr>
</table>
<@end@>
dynamicdataリソースのproperties-of-tableパラメータの形式は次のとおりです。
field1="value1" field2="value2" . . .
プロパティは、XMLノードに定義された属性に似ています。次の例は、一般的な表宣言を示しています。
Table Properties in a Table Definition <@dynamicdata ExampleTable@> <?commatable mergeField="fieldA" indexedColumns="fieldA,fieldB"?> fieldA, fieldB 1, 2 3, 4 <@end@>
値を囲む引用符は、空白のない値では省略可能であり、引用符は一重と二重のどちらでも使用できます。また、プロパティのデフォルト値は1であるため、表のプロパティの値が1の場合は、値の割当てを省略できます。
この値を省略することは、notrimやmergeBlanksのようなブール型プロパティの場合に役立ちます。次の例は、値をトリミングしない表を指定する宣言を示しています。
notrim Property <@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つ以上指定できます。
countなので、countという名前の列があって、別のcountColumnを指定していない表があれば、その列にカウンタ値が自動的に入力されます。このプロパティの値は、最終的にマージされた表の列名と一致していない場合には無視されます。重ね合せる側の表のリソースで、前の表のリソースで指定されたものとは異なるcountColumnが指定されている場合は、重ね合せる側の表のリソースが使用されます。このプロパティにはグローバルな表スコープが指定されています。field1:val1,field2:val2,field3では、デフォルト値を、field1にはval1、field2にはval2、field3には空の文字列と指定します。コロンはアスタリスク(*)でエスケープでき、アスタリスクは前に番号記号(#)を置くことでエスケープできます。番号記号に番号記号またはアスタリスクのいずれかが続く場合には、別の番号記号を追加することで番号記号をエスケープできます(前述のカンマをエスケープする同様の規則を参照)。最終的にマージされた表に、デフォルト値の構成で指定されたフィールドがない場合は、新規のフィールドとして追加され、その表のすべての行のデフォルト値が指定されます。そのフィールドがある場合は、その表でそのフィールドに空白の値があれば、デフォルト値によってオーバーライドされます。新しい重ね合せる側の表のdefaultValuesの定義が、既存の表の実際の定義と照合されます。あるデフォルト値の定義に競合があった場合は、新しい重ね合せる側の表が優先されます。このプロパティのデフォルトはNULLで、グローバルな表スコープが指定されています。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: このプロパティは、表(索引付きの列が副表の選択に使用されている場合は副表)の各行に実行するインクルードを指定します。これは、現在のユーザーのコンテキストに表がロードされたときに実行されます。その主な目的は、副作用を生みだすこと、または行を除外する必要があるかどうかを判別することです。最終的なResultSetに行がロードされないようにするために、変数ddSkipRowを1(<$ddSkipRow=1$>)に設定できます。このインクルードの実行時に表はアクティブにされ、表の値へのアクセスと値の置換を簡単にできます。このプロパティのデフォルト値はnullで、グローバルなスコープが指定されています。
includeColumns: このプロパティは、実行するリソース・インクルードの名前が行の値になっている列のカンマ区切りのリストを指定します。リソース・インクルードが実行された後で、結果がResultSetにフィードバックされ、その行のその列の新しい値となります。実行のタイミングおよびルールはfilterIncludeと同じですが、includeColumnsでは、行をロードすることを抑制できません。フィルタ・インクルードが指定され、アクティブなインクルード列がある場合は、一時的にアクティブなResultSetをループ処理する際に、インクルード列の値が最初に実行され、次にフィルタ・インクルードが実行されます。最終的にマージされた表に、指定されたインクルード列のいずれかがない場合は、効果はありません。インクルード列にある空の値は無視されます。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エスケープ・エンコーディングを使用する必要があります。
| エスケープ・シーケンス | 文字 |
|---|---|
|
|
|
行送り(ASCII 10) |
|
改行(ASCII 13) |
|
タブ(ASCII 9) |
|
次の空白以外の文字まで空白を食いつぶします。 |
|
|
|
|
|
空白(ASCII 32) |
|
10進数で表すASCII文字( |
すべての言語にシングルバイト文字がある場合、またはマルチバイト文字がある場合は、言語識別子接頭辞を使用して、同じリソース・ファイルで複数の言語の文字列を指定できます。次の例は、リソース・ファイルにおける、複数の言語による文字列の接頭辞を示しています。
Multiple Languages in the Same Resource File <@myString=Thank you@> <@es.myString=Gracias@> <@fr.myString=Merci@> <@de.myString=Danke@>
注意:
シングルバイト文字列とマルチバイト文字列は、同じリソース・ファイルで指定しないでください。シングルバイト文字列用とマルチバイト文字列用に、別々のリソース・ファイルを作成してください。
カスタム文字列リソースでマルチバイト文字列を指定する場合は、HTMLページでの文字セット指定が、適切なエンコーディングに変更されるようにしてください。リソース・ファイルには正しいhttp-equiv charsetタグを指定して、コンテンツ・サーバーが正しく読み取るようにしてください。
テキスト文字列には変数パラメータを含めることができ、そのパラメータは、中カッコ内にパラメータ引数を配置(たとえば、{1})することによって指定されます。文字列がローカライズされると、この引数は、文字列ID、およびロケール情報を含むExecutionContext値とともに渡されます。パラメータ化された文字列の構文は次の表のとおりです。
| 構文 | 意味 | 例 |
|---|---|---|
{{} |
開始側の中カッコ。(リテラルとして表現する必要があるのは、開始側の中カッコのみです。) |
{{}Text in braces} |
{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でなく、長さがゼロでない場合は、引用符で引数を代入します。それ以外の場合は、文字列 |
コンテンツ・アイテム{1q}を正常にチェックインできませんでした。 |
{no} |
n番目の引数に対して、順序を示す代入を実行します。たとえば、1st、2nd、3rdなどです。引数は整数である必要があります。 |
" |
{n?text} |
n番目の引数の値が1でない場合は、テキストを代入します。 |
{1} file{1?s} deleted |
{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. |
動的表のリソースは、HDAファイル形式で定義されます。HDA ResultSet表の詳細と例は、「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列では、各問合せの名前を定義しています。既存の問合せをオーバーライドするには、同じ名前をカスタム問合せに使用します。新規の問合せを追加するには、一意の問合せ名を使用します。新規の問合せに名前を付けるときには、次の文字のいずれかを名前の先頭に付けて、問合せのタイプを特定します。
| 先頭文字 | 問合せタイプ |
|---|---|
|
削除 |
|
挿入 |
|
選択 |
|
更新 |
queryStr列では、問合せ式を定義しています。問合せ式は、SQLの標準構文にします。データベースに渡すパラメータ値がある場合、その場所は、疑問符(?)をエスケープ文字として固定されます。
parameters列では、サービスから問合せに渡されるパラメータを定義しています。Webブラウザからのリクエストによってサービスが呼び出され、さらにそこから問合せが呼び出されます。HTTPの標準パラメータである問合せパラメータに値を提供するのは、Webブラウザの役割です。ブラウザは、URLから、またはWebページ内のFORM要素から、問合せパラメータを渡すことができます。たとえば、QdocInfo問合せでは、パラメータとしてdID(リビジョンID)を渡す必要があるため、この値は、サービス・リクエストのURLから取得されます。
図18-1に示している標準的なQdocInfo問合せは、IntradocDir/core/config/resources/query.htmファイルで定義されています。この問合せでは、DOC_INFOテンプレート・ページに表示するメタデータ情報が取得されます。このテンプレート・ページは、検索結果ページでユーザーが「情報」アイコンをクリックしたときに表示されるページです。
WebブラウザのURLから渡されるパラメータはdIDであり、これは、コンテンツ・アイテム・リビジョンの一意のID番号です。リビジョンにDELETEDステータスがない場合、問合せ式では、「リビジョン」、ドキュメント、DocMetaの各データベース表から、プライマリ・リビジョンのdIDと一致するデータを選択します。
例18-4に、query.htmファイルの内容を示します。
例18-4 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>
サービス・リソースは、コンテンツ・サーバーで実行される関数またはプロシージャを定義します。クライアントとサーバーどちらの側からもサービス・コールを実行できるため、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 Fusion Middleware Oracle WebCenter Contentサービス・リファレンス』のOracle WebCenter Contentサービスのリストに関する項を参照してください。
サービスが機能を実行する際には、他のリソース定義に左右されます。HTMLを返すサービスでは、テンプレートを指定する必要があります。広く知られている例外はPING_SERVERサービスであり、このサービスはブラウザにページを返しません。
ほとんどのサービスでは問合せを使用します。広く知られている例外はSEARCHサービスであり、このサービスは検索コレクションにリクエストを直接送信します。サービス・リソースにマージ・ルールは不要です。
図18-2に、サービス定義の例を示します。
サービス・リソースは、次の3つの列があるResultSet表を使用したHTMファイルで定義されます。
Name列では、各サービスの名前を定義しています。クライアント側のリクエストでは、これはURLの中で呼び出される名前です。既存のサービスをオーバーライドするには、同じ名前をカスタム・サービスに使用します。新規のサービスを追加するには、一意のサービス名を使用します。
Attributes列では、各サービスの次の属性を定義しています。
| 属性 | 説明 | 例(DELETE_DOCサービスの属性) |
|---|---|---|
サービス・クラス |
サービスで実行できるアクションの一部を決定します。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
アクセス・レベル |
サービスにユーザー・アクセス・レベルを割り当てます。この数値は、使用可能な次のビット・フラグの合計です。
|
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
テンプレート・ページ |
サービスの結果を表示するテンプレートを指定します。サービスの結果にページ表示が必要ない場合は、この属性は |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
サービス・タイプ |
サービスを別のサービスの内側で実行する場合は、この属性は |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
通知された件名 |
サービスによって通知される件名(サブシステム)を指定します。件名が通知されない場合は、この属性はnullにします。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
エラー・メッセージ |
アクション・エラー・メッセージによってオーバーライドされない場合、サービスによって返されるエラー・メッセージを定義します。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、「ローカライズされた文字列の解決」を参照してください。 |
DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)
|
Actions列では、各サービスのアクションを定義しています。アクションとは、サービス・スクリプトの一部として実行される操作です。アクションは、SQL文の実行、問合せの実行、コードの実行、問合せの結果のキャッシュまたはオプション・リストのロードを行うことができます。各サービスにはアクションが1つ以上含まれていて、実行時に何が起こるかを指定します。
Actions列の<br>タグは、ブラウザ表示のみを目的としたものなので、省略可能です。ただし、</td>タグは、アクションの直後に置くもので、その間に改行を入れてはなりません。アクションは、次の形式を使用して定義されます。
type:name:parameters:control mask:error message
| セクション | 説明 | 例(DELETE_DOCサービスの最初のアクション) |
|---|---|---|
|
アクションのタイプを定義します。
|
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists
|
|
アクションの名前を指定します。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
|
アクションに必須のパラメータを指定します。必須のパラメータがない場合は、この部分を空白にしておきます(1つの行の中の2つの列)。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
|
データベースへの問合せ結果を制御します。この数値は、使用可能な次のビット・フラグの合計です。 制御マスクなし =
|
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
|
このアクションで表示するエラー・メッセージを定義します。このエラー・メッセージは、サービスの属性として用意されているエラー・メッセージをオーバーライドします。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、「ローカライズされた文字列の解決」を参照してください。 |
5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist
|
DOC_INFOサービスでは、サービス、問合せおよびテンプレートがまとまってどのように機能しているかの好例が提供されています。図18-3は、DOC_INFOサービスで実行できるアクションを示しています。
例18-5は、IntradocDir/config/resources/std_services.htmファイル内のDOC_INFOサービスの定義を示しています。
例18-5 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サービスの属性について説明します。
| 属性 | 値 | 説明 |
|---|---|---|
サービス・クラス |
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としてローカル・データに格納します。 |
blank |
このアクションではパラメータを利用しません。 |
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が存在している場合は、ワークフロー情報が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) |
このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。
|
テンプレート・リソースは、コンポーネント用にロードされるカスタム・テンプレートの名前、タイプおよび場所を定義します。
実際のテンプレート・ページは、テンプレート・リソース・ファイルで参照される別々の.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表の詳細と例は、「HDAファイル内の要素」を参照してください。
IntradocTemplates表またはSearchResultTemplates表に新規のテンプレート定義をマージする際には、マージ・ルールが必要です。通常、マージはname列にあります。次の例に、テンプレートのMergeRules ResultSetを示します。
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レイアウト・エディタ・ユーティリティ内では、この名前を使用してテンプレートが参照されます。
注意:
StandardResultsテンプレート(search_results.htmファイル)は通常、ライブラリの標準的な検索結果ページおよび問合せ結果ページのグローバル・テンプレートとして使用されます。テンプレートを新規作成するか、またはWebレイアウト・エディタを使用してStandardResultsテンプレートのflexdata値を変更できます。ただし、それらの変更は、templates.hdaファイルのSearchResultTemplates表でなく、別のファイル(IntradocDir/data/results/custom_results.hda)に保存されます。
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)を指すカスタム・テンプレート・リソース・ファイルを、次の例に示します。
例18-6 カスタム・テンプレート・リソース・ファイル
<?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です。次の例は、このファイルの内容を示しています。
The doc_man.htm File
<$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インクルード・コードを使用して構築されます。
図18-4は、「コンテンツ管理」ページを示しています。
標準「ドキュメント・タイプ」レポート・ページのテンプレート・ファイルは、doc_types.htmにあります。次の例は、このファイルの内容を示しています。
The doc_types.htm File
<$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インクルード・コードを使用して構築されます。
環境リソースは、新規変数の値を作成するか既存の値を置換して、構成変数を定義します。カスタム・リソースは、標準的なconfig.cfgファイルがロードされた後でロードされるので、カスタム環境リソースで定義された変数の値が、元の変数の値を置換します。
環境リソースは、次のような名前と値のペア形式を使用して、CFGファイルで定義されます。
variable_name=value
変数の値を定義した後で、次のIdocスクリプト・タグを使用して、テンプレートなどのリソース・ファイル内の変数を参照できます。
<$variable_name$>
環境リソース・ファイルには、次のように#記号で指定されたコメント行を含めることができます。
#Set this variable to true to enable the function.
次の例に、環境リソース・ファイルの内容を示します。
Environment Resource File # 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 Fusion Middleware Oracle WebCenter Content構成リファレンス』の構成変数に関する項を参照してください。
コンポーネント・ウィザードを使用して既存の環境リソースを編集するには、次の手順を実行します。
コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。
「カスタム・リソース定義」リストからリソースを選択します。
「エディタの起動」をクリックします。
テキスト・エディタで構成変数を変更します。
リソース・ファイルを保存して閉じます。
変更内容は、「カスタム環境パラメータ」リストに反映されます。
注意:
「カスタム環境パラメータ」リストでの構成設定の表示順は、リソース・ファイルでの実際の表示順とは異なる場合があります。わかりやすく表示するために、テキスト・エディタを起動します。
コンポーネント定義ファイルを作成または変更するには、コンポーネント・ウィザードを使用できます。
次の例は、customhelp_environment.cfgという環境リソース・ファイルを指すコンポーネント定義ファイルを示しています。
例18-7 環境リソースのコンポーネント定義ファイル
<?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 Fusion Middleware Oracle WebCenter Contentの管理』のシステム・プロセスの管理に関する項を参照してください。
WebCenter Content管理対象サーバーをコマンドラインからスクリプトを使用して再起動する手順は、次のとおりです。
