この章では、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サービス・リファレンス』を参照してください。
サービスが機能を実行する際には、他のリソース定義に左右されます。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管理対象サーバーをコマンドラインからスクリプトを使用して再起動する手順は、次のとおりです。