Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1 (11.1.1) B72427-04 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > 動的サーバー・ページの作成
この章では、動的サーバー・ページを作成してWebページの外観およびナビゲーションを変更するために必要なビルディング・ブロックの使用方法について説明します。
この章の内容は次のとおりです。
動的サーバー・ページとは、Oracle WebCenter Content Serverにチェックインされ、Webページを動的に生成するために使用されるファイルのことです。動的サーバー・ページは通常、Webページのルック・アンド・フィールおよびナビゲーションを変更するために使用されます。たとえば、動的サーバー・ページは、次のタスクを実行するために使用できます。
HTMLフォームを実装する
Webサイト全体で一貫性のあるルック・アンド・フィールを維持する
動的サーバー・ページには、次のようなファイル形式があります。
IDOC: 独自のスクリプト言語です。
HCST: Hypertext Content Server Template。IdcHomeDir
/resources/core/templates
ディレクトリに格納されているコンテンツ・サーバーの標準的なテンプレートに似ています。
HCSP: Hypertext Content Server Page。HTMLに対応したバージョンのHCSTページで、通常はパブリッシュ済のコンテンツに使用されます。
HCSF: Hypertext Content Server Form。HCSPページおよびHCSTページに似ていますが、Webブラウザから記入して送信することのできるHTMLフォーム・フィールドが含まれています。
動的サーバー・ページを使用すると、コンテンツ・サーバーでは、コンテンツ・サーバーにチェックインしたカスタム・テンプレート(HCST、HCSP、HCSFいずれかのファイル)を使用して、Webページが動的にアセンブルされます。このテンプレートでは、同じくコンテンツ・サーバーにチェックインしたテキスト・ファイル(IDOCファイル)からHTMLインクルードが呼び出されます。
Webページのルック・アンド・フィールおよびナビゲーションを変更するには、HCS*テンプレート・ページまたはIDOCファイル、あるいはその両方を変更して、改定後のファイルを新たなリビジョンとしてチェックインします。変更内容がすぐにわかります。
コンテンツ・サーバーとともに動的サーバー・ページを使用すると、次のメリットが得られます。
カスタマイズの導入とテストを迅速かつ容易に行うことができます。動的サーバー・ページのリビジョンをチェックインするだけで変更内容が即座に実装され、コンテンツ・サーバーを再起動する必要はありません。
Webページでは、標準的なHTMLにはない機能を利用できます。たとえば、CGIスクリプトなしで、HTMLフォームをコンテンツ・サーバーに直接送信できます。また、Idocスクリプトを使用すると、コンテンツ・サーバーに関する環境および状態の情報を直接操作できます。
コンポーネント・ファイルをインストールしたり常時監視する必要はありません。ファイルが大量にあったり、システムが高度にカスタマイズされている場合は、コンポーネントの維持とトラブルシューティングが難しくなることが考えられます。動的サーバー・ページのほうが、カスタマイズのすべてを含んだコンテンツ・アイテムを少しチェックインするだけなので、操作しやすくなります。
カスタマイズを個々のページに適用できます。動的サーバー・ページを使用すると、グローバルではなく単一のページにカスタマイズを適用できるため、コンテンツ・サーバーのページの標準的なコーディングに手を入れなくてすみます。
動的サーバー・ページを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。
動的サーバー・ページは、コンテンツ・サーバーのコアな機能の変更には使用できません。動的サーバー・ページは、Web設計とフォーム・ページのカスタマイズに最も役立ちます。
動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があります。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。
図7-1は、動的サーバー・ページを生成および使用するプロセスを示しています。
動的サーバー・ページには次の4つのタイプがあり、ファイル名の4文字の拡張子によってコンテンツ・サーバーで識別されます。
IDOC
HCST
HCSP
HCSF
IDOCファイルは、HCST、HCSP、HCSFの各ページによって呼び出されるHTMLインクルードを含むテキスト・ファイルです。
詳細は、第12章「コンテンツ・サーバーのコンポーネントのスタート・ガイド」を参照してください。
Hypertext Content Server Template (HCST)ファイルは、コンテンツ・サーバーの標準的なテンプレート・ページに似たテンプレート・ページであり、Webページをアセンブルする際にフレームワークとして使用されます。
HCSTページが使用される代表的なケースは、ページのコンテンツ自体が動的な場合、または、検索ページ、検索結果ページ、カスタム・チェックイン・ページなどでコンテンツ・サーバー機能が必要とされる場合です。
このタイプのページは、動的にアセンブルされたコードでほとんどが構成されているため、HCSTファイルはコンテンツ・サーバー内で索引が付けられません。
Hypertext Content Server Page (HCSP)ファイルはパブリッシュ済のWebページであり、実際のWebサイトのコンテンツを表示します。
HCSPファイルは一般的に、HCSTページをテンプレートとして使用するか、HCSFページによってコンテンツ・サーバーでフォームを送信することによって作成されます。
このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSPファイルはコンテンツ・サーバー内で索引が付けられます。
Hypertext Content Server Form (HCSF)ファイルは、HCSPファイルに似ていますが、Webブラウザから記入して送信することのできるHTMLフォーム・フィールドが含まれている点が違います。
ユーザーがHCSFページからフォームを記入して送信すると、HCSFページのXML要素によってメタデータが定義された別のコンテンツ・アイテムとして、HCSPファイルがチェックインされます。
このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSFファイルはコンテンツ・サーバー内で索引が付けられます。
HCSFページの詳細は、第7.1.1.4項「HCSFファイル」を参照してください。
動的サーバー・ページは、カスタム・コンポーネントとは異なる形でコンテンツ・サーバーに実装されていますが、WebCenter Contentコンポーネントのアーキテクチャ概念、特にコンテンツ・サーバーのテンプレートおよびHTMLインクルードに精通している必要があります。詳細は、第12章「コンテンツ・サーバーのコンポーネントのスタート・ガイド」を参照してください。
動的サーバー・ページとともにコンテンツ・サーバーのインスタンスをカスタマイズするには、次の基本手順を実行します。
カスタム・インクルードを含むIDOCファイルを作成します。
IDOCファイルをコンテンツ・サーバーにチェックインします。
IDOCファイルを参照するHCSTファイル、HCSPファイルまたはHCSFファイルを作成します。
HCS*ファイルをコンテンツ・サーバーにチェックインします。
コンテンツ・サーバーで検索するか、またはパブリッシュされたWebページからリンクすることによって、WebブラウザでHCS*ファイルを表示します。
異なるタイプの動的サーバー・ページは、解釈も表示も異なっているため、ファイル内のIdocスクリプトは、異なるコーディングを行う必要があります。次の表は、それらの違いをまとめたものです。
注意: Idocスクリプトでは、標準的なHTMLインクルードのコーディングを使用します。詳細は、第18.2.1項「HTMLインクルード」を参照してください。 HCSTでは、コンテンツ・サーバーの標準的なテンプレートのコーディングを使用します。詳細は、第18.2.8.1項「テンプレート・ページとレポート・ページ」を参照してください。 HCSPとHCSFでは特殊なコーディングが使用され、ページを静的にも動的にもレンダリングでき、全文索引を作成できます。 |
HCSPページとHCSFページでは、Idocスクリプトの式は一般的に、HTMLコメント・タグ間に配置されます。ページが静的に表示されるときには、このように配置することによって、Webブラウザでページ・コンテンツを表示でき、コンテンツの書式設定に使用されている動的コードがあっても無視されます。またこれによって、全文索引作成エンジンが、これらのページのコンテンツの索引を正常に作成できます。
次に、いくつかの例を示します。
IDOCファイルまたはHCSTファイル: <$include MyIdocExpression$>
HCSPファイルまたはHCSFファイル: <!--$include MyIdocExpression-->
状況によっては、HTMLコメントの開始と終了を制御することもできます。HCSPファイルとHCSFファイルでは、この操作を行うには、例7-1に示すように、Idocスクリプトの式の後にある終了タグで、ダッシュ(-
)を他の文字に置換します。
例7-1 HCSPファイルまたはHCSFファイルでのHTMLコメントのシャープ記号によるデリミタ
<!--$a="ab"##> HTML comment remains open <a href="<!--$myUrlAsVariable##>">MyUrl</a> Static view does not see this <!--$dummy=""--> <!—Ended the comment area-->.
例7-1では、ダッシュ(-
)がシャープ記号(#
)に置換されています。
HCSPファイルとHCSFファイルでの別のオプションとしては、例7-2に示すように、標準的なHTMLコメントの開始タグおよび終了タグ(< >
)を大カッコ([]
)に置換します。このように置換すると、XHTMLパーサーでは、静的に表示されたときにすべてのスクリプトを適切に識別できます。
HCSPページとHCSFページでは、(==などの)標準的な比較演算子は、HTMLパーサーにとっては特殊な意味があるため使用できません。動的サーバー・ページでは、次の比較演算子を使用します。
IDOCファイルまたはHCSTファイル | HCSPファイルまたはHCSFファイル | 説明 |
---|---|---|
== |
eq |
等価かどうかをテストします。 |
!= |
ne |
非等価かどうかをテストします。 |
< |
lt |
より小さいかどうかをテストします。 |
> |
gt |
より大きいかどうかをテストします。 |
<= |
le |
以下かどうかをテストします。 |
>= |
ge |
以上かどうかをテストします。 |
たとえば、次のコードは、変数count
の値が10より大きいかどうかを評価します。
IDOCファイルまたはHCSTファイル | HCSPファイルまたはHCSFファイル |
---|---|
<$if count > 10$> <$"Count is greater than"$> <$endif$> |
<!--$if count gt 10--> <!--$"Count is greater than"--> <!--$endif--> |
HCSPページとHCSFページでは、アンパサンド(&)などの特殊文字は、HTMLパーサーにとっては特殊な意味があるため使用できません。HTMLまたはXMLの標準的なエスケープ・フォーマット(&
や&
など)を使用する必要があります。
注意: HCSPページまたはHCSFページからdocLoadResourceIncludes関数をコールするときには、エスケープ文字 |
次の例に示すように、Idocスクリプトでは、先頭にバックスラッシュ文字を置くことによって、文字列に引用符を含めることができますが、HCSPページまたはHCSFページでは、引用符はHTMLのエスケープ文字で表す必要があります。
IDOCファイルまたはHCSTファイル: "Enter \"None\" in this field."
HCSPファイルまたはHCSFファイル: "Enter "None" in this field."
HCSTページでは、\n
を使用して行送りが挿入されます。HCSPページでは、行送りをファイルに直接挿入するか、または行送りの数値ASCII番号を使用してXML内にエンコードします。
注意: &文字列の結合演算子を |
動的サーバー・ページでは、いくつかのメタデータ値が、ref:
という接頭辞付きで格納されており、その値はページで利用できますが、ResultSet
の値を置換するものではありません。(このため、動的サーバー・ページによるResultSetの汚染が防止されます。)
動的サーバー・ページで次のメタデータ値のいずれかを参照する場合は、ref:
接頭辞を含める必要があります。
hasDocInfo
dDocName
dExtension
dSecurityGroup
isLatestRevision
dDocType
たとえば、次の文では、ドキュメント・タイプがPage
であるかどうかを判別します。
<$if strEquals(ref:dDocType,"Page"))$>
動的サーバー・ページでは、Idocスクリプトの次の2つの特殊関数が必要です。
docLoadResourceIncludes
executeService
IDOCファイルでHTMLインクルードを使用できるようにするには、次の例に示すように、HCS*ファイルでdocLoadResourceIncludes
関数をコールする必要があります。この関数では、現在のページのアセンブルに使用できるように、指定されたIDOCファイルからすべてのインクルードがロードされます。例7-3に、HCSTファイルからこの関数をコールする形式を示します。
例7-3 HCSTファイルでのdocLoadResourceIncludes関数コール
<$docLoadResourceIncludes("dDocName=system_std_page&RevisionSelectionMethod=Latest")$>
例7-4に、HCSPファイルまたはHCSFファイルからこの関数をコールするフォーマットを示します。
例7-4 HCSPファイルまたはHCSFファイルでのdocLoadResourceIncludes関数コール
<!--$docLoadResourceIncludes("dDocName=system_std_page&RevisionSelectionMethod=Latest")-->
指定されたコンテンツ・アイテムのネイティブ・ファイルでは、拡張子が.idoc
になっている必要があります。
docLoadResourceIncludes
コールは、HCS*ファイル内で最初のインクルードの前に配置する必要があります。この関数は、ページのHEAD
セクション内に配置することをお薦めします。
HCS*ページからdocLoadResourceIncludes
関数をコールするときには、正しいアンパサンド文字を使用する必要があります。詳細は、第7.2.1.3項「特殊文字」を参照してください。
どのIDOCファイルを呼び出すかを指定するには、docLoadResourceIncludes
関数で次のパラメータを使用します。
dDocName
とdID
のいずれかを定義する必要があります。両方のパラメータをいっしょに使用することはやめてください。
dDocName
を定義する場合は、RevisionSelectionMethod
をLatest
またはLatestReleased
に定義する必要があります。
dID
を定義する場合は、RevisionSelectionMethod
を定義しないでください。あるいは、RevisionSelectionMethod
をSpecific
に定義します。
パラメータ | 説明 |
---|---|
IDOCファイルのコンテンツIDを指定します。 このパラメータは、コンテンツIDの値がわかっているときには常に存在している必要があります。エラー・メッセージは、フォームなど、他の機能と同様に、これが存在しているという想定に基づいています。 |
|
IDOCファイルの特定のリビジョンの一意のID番号を指定します。 |
|
このIDOCファイルのいずれのリビジョンを使用するかを指定します。
|
|
このIDOCファイルのいずれのレンディションを使用するかを指定します。
|
executeService
関数は、動的サーバー・ページ内からコンテンツ・サーバーのサービスを実行します。次に例を示します。
HCSTファイル: <$executeService("GET_SEARCH_RESULTS")$>
HCSPファイルまたはHCSFファイル: <!--$executeService("GET_SEARCH_RESULTS")-->
executeService
関数でコールできるサービスは、パラメータ入力が必要でないという意味で、「スクリプト可能」である必要があります。
スクリプト可能なサービスのアクセス・レベルは32以上です。詳細は、第25章「環境へのWebCenter Contentの統合のスタート・ガイド」を参照してください。
コンテンツ・サーバーの標準的なサービスについては、IdcHomeDir
/resources/core/tables/std_services.htm
ファイルを参照してください。
executeService
関数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。
サービスの詳細は、第25章「環境へのWebCenter Contentの統合のスタート・ガイド」を参照してください。
パフォーマンスに関するヒント: サービスの使用は控えめにしてください。ページ上でサービス・コールが多すぎると、パフォーマンスが影響を受けたり、スケーラビリティが制限される場合があります。 |
動的サーバー・ページの開発を支援するための次の推奨事項には、一般的なガイドラインとHCSFのガイドラインが含まれています。
次の推奨事項は、すべてのタイプの動的サーバー・ページの開発に当てはまります。
テンプレートは、できるだけ簡略でコードのないものにします。テンプレートはHTMLインクルードのみにして、コードと条件はすべてIDOCファイルに入れるようにします。これが特に役立つのはHCSFページで、そこでは、送信されたフォームも、IDOCファイルに対する変更に反映されます。
Oracle WebCenter Content Serverのインスタンスをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があることを頭に入れてください。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。
動的サーバー・ページを使用してWebサイトを開発するときには、開発プロセスとコントリビューション・プロセスを、所有の観点で考えます。
構造(サイトの設計とナビゲーションを含む)は、Webマスターが所有しています。動的サーバー・ページを使用するときには、構造は、IDOCファイルに定義されているインクルードに含まれており、そのインクルードとともに制御されます。
コンテンツ、すなわちWebページの実際のテキストは、コントリビュータが所有しています。動的サーバー・ページを使用するときには、コンテンツは主として、IDOCファイル内のインクルードを利用するHCSPファイルに含まれています。
一貫性のある命名規則を使用します。たとえば、「システム」レベルのインクルードの場合は、IDOCファイルにsystem_std_page
という名前を付け、そのファイル内の各インクルードに、system_
を接頭辞とする名前を付けることができます。こうすると、インクルードを見つけやすくなります。
動的サーバー・ページのタイプごとにコンテンツ・タイプを作成することをお薦めします(HCSF_templates
やsubmitted_forms
など)。
優れたコーディング手法に従って、動的サーバー・ページに常にコメントを入れて、カスタマイズの記録を残してください。
次の推奨事項は、HCSFページの開発にのみ当てはまります。
フォームを設計する際には、テンプレートがどのように使用されるかを検討してください。
このテンプレートは、フォームを送信するユーザーのロールに応じて変わるか
送信されたコンテンツは、重要なワークフローに入るか
どのようなデフォルトのメタデータ値を設定するか
複数のライン入力に対するResultSetがフォームに含まれるか
フォームのパラメータがWebブラウザからWebサーバーに渡され、コンテンツ・サーバーを通じてフィルタリングされてWebブラウザに戻されるときに、そのパラメータが表示されるようにするには、次のようにして、インクルード・コードのmethod
属性をPOST
からGET
に変更します。
<form name="<$formName$>" method="GET" action="<$HttpCgiPath$>">
DataScriptというフォーム・フィールドを、送信されているフォームに追加した場合、その値に対するIdocスクリプトがあれば、コンテンツ・サーバーがフォームを処理するときにそのスクリプトを評価します。
コンテンツ・サーバーのテンプレートおよびHTMLフォームに対する標準的な書式設定ルールを遵守することに加えて、HCSFページでは、コンテンツ・サーバーによる処理を可能とする特殊なセクションとタグがいくつか必要です。これらの特殊セクションは、通常のHCSFファイルでは次の順序で表示されます。
ロード・セクション
データ・セクション
フォーム・セクション
完全なHCSFページの例は、第7.1.1.4項「HCSFファイル」を参照してください。
HCSFページの先頭にあるロード・セクションでは、ファイルをHTMLファイルとして宣言し、IDOCファイルをロードして、ページに関する他の情報をロードします。例7-5は、一般的なロード・セクションを示しています。
例7-5 HCSFページのロード・セクション
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <head> <!--$docLoadResourceIncludes("dDocName=my_idoc_page&RevisionSelectionMethod=Latest")--> <meta NAME="idctype" CONTENT="form; version=1.0"> <!--$defaultPageTitle="Department News Form"--> <!--$include std_html_head_declarations--> </head>
ロード・セクションには、次の3つのアイテムがあります。
HTML宣言
docLoadResourceIncludes
関数
meta
要素
変数とインクルード
HTML宣言では、次の構文でファイルをHTMLファイルとして指定しています。
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
docLoadResourceIncludes関数では、現在のページのアセンブルに使用できるように、指定されたIDOCファイルからすべてのインクルードがロードされます。詳細は、第7.2.4.1.2項「docLoadResourceIncludes関数」を参照してください。
meta
要素は特別な種類のページを識別します。
この要素は必要ではありません。
meta
要素は、HTMLファイルのHEAD
セクションの内側に配置する必要があります。
meta
タグには次の構文を使用します。
<meta NAME="idctype" CONTENT="form; version=1.0">
HCSFページのHEAD
セクションには、必要に応じて、変数定義とHTMLインクルードが含まれる場合があります。HEAD
セクションの中で、デフォルトのページ・タイトルを定義し、std_html_head_declarations
コードをロードする行を、例7-6に示します。
HCSFページのデータ・セクションには、フォームの処理に使用されるルールおよびメタデータ情報が含まれます。データ・セクション内の情報とページの表示との間には、次のように緊密な関係があります。
HCSFページがユーザーに配信された時点で、データ・セクション内の情報がDataBinder
オブジェクトに解析され、フォーム・セクションにマージされます。
フォームが送信された時点で、データ・セクション内の情報がリクエストとマージされ、データ・セクションに再び書き出されます。詳細は、第12章「データ・バインダ」および第12.1.3.1.1項「HDAファイル内の要素」を参照してください。
例7-7に示すように、データ・セクションは、Idocスクリプトのタグidcbegindata
とidcenddata
の間に配置されたXML要素で構成されます。
例7-7 HCSFページのデータ・セクション
<!--$idcbegindata--> <idcformrules isFormFinished="0"/> <model_number content="html">AB-123</model_number> <revision>12</revision> … <!--$idcenddata-->
データ・セクションには次のルールが適用されます。
idcformrules要素では、データ・セクションにおけるコンテンツ・サーバーのルールを定義します。この要素では、isFormFinished
とresultsets
のいずれか1つの属性が必要です。
IsFormFinished属性: isFormFinished
属性は、フォームを再送信できるかどうかを示します。
フォームを再送信可能と指定する場合は、次の属性値を使用します。
<idcformrules isFormFinished="0"/>
フォームを再送信不可能と指定する場合は、次の属性値を使用します。
<idcformrules isFormFinished="1"/>
このコードでは、読取り専用のフォームになります。
resultsets属性: resultsets
属性は、データ・セクション内のいずれのXML要素がResultSetと解釈されるかを示します。
この属性では、1つ以上のXMLタグ名をカンマで区切って指定します。次に例を示します。
<idcformrules resultsets="volume,chapter">
ユーザーへのHCSFページの配信中に、コアのコンテンツ・サーバーがresultsets
属性を読み取り、必要に応じて、指定した名前を持つ空のResultSetをDataBinder
オブジェクトに配置して、マージに利用できるようにします。
データ・セクションにおけるResultSetの書式設定の詳細は、第7.2.4.2.7項「ResultSet」を参照してください。
メタデータ要素では、ブラウザにフォームを表示するときにフォーム・フィールドに表示されるメタデータ値を指定します。次に例を示します。
<model_number>AB-123</model_number>
各メタデータ要素には、その要素にどのタイプのコンテンツが含まれるかを示すcontent
属性を割り当てることができます。次に例を示します。
<model_number content="html">AB-123</model_number>
content
属性の値としては、html
とtext
のいずれかが可能です。textは、この要素のコンテンツを、厳密にテキストと解釈することを示します。htmlは、この要素のコンテンツをHTMLと解釈することを示します。
メタデータ要素にcontent
属性が指定されていない場合は、デフォルトでhtml
が設定されます。
データ・セクション内でネストされたXML要素(ノードともいう)を使用できます。例7-8は、<chapter>
要素内でネストされた<section>
要素を示しています。
ネストされたXML要素を参照するには、ルートレベルの要素から始め、要素レベルの間に感嘆符(!)を使用します。次に例を示します。
chapter!section
任意の要素の属性を参照するには、タグ名の後ろにコロン(:)を使用します。次に例を示します。
chapter!section:title
データ・セクション内の要素を参照する場合は、次の文のいずれかが真の場合にのみ、フォームの送信時に要素の値を元のデータ・セクションにマージできます。
デフォルト値は、タグ・パスに:default
接尾辞を適用することによって指定できます。デフォルトの要素には、後で評価できるように、Idocスクリプトが含まれている場合もあります。例7-9に、dDocTitle
のデフォルト値を指定するための書式を示します。
ExtraRootNodesフォーム要素を使用すると、フォームのデータ・セクション内のタグを指定するのではなく、Idocスクリプトの変数を作成してそれにタグ名を付加することによってタグを追加できます。フォームの最後で、ExtraRootNodesの値に文字列の値を代入して、元のデータ・セクションにマージできます。
resultsetsフォーム要素を使用すると、データ・セクション内のResultSetを指定するのではなく、ResultSetとしてタグを追加できます。
ExtraRootNodesフォーム要素とResultSetフォーム要素では、カンマで区切られたタグのリストを使用します。
idcformrules resultsets
属性にmychapters!chapter
要素がまだ定義されていない場合に、有効なResultSetとしてそれを追加するフォーム要素を、例7-10に示します。また、必要に応じて、ルート要素mychapters
も追加されます。
次のように、HCSFページのデータ・セクション内のXML要素を使用して、ResultSetを定義できます。
idcformrules
要素のresultsets
属性を使用して、ResultSetを指定する必要があります。
要素名は完全修飾されている必要があり、ルート・ノードからの参照のフルパスを使用する必要があります。
ResultSetの列は、要素コンテンツおよび要素属性です。
ResultSetでのXML要素の繰返しとネストに対する制限については、例7-13と例7-15を参照してください。
例7-11は、volume
とchapter
という2つのResultSetを定義するXML要素を示しています。
例7-11 HCSFページのデータ・セクションにおけるResultSetを定義するためのXML要素
<idcformrules resultsets="volume,chapter"> <volume title="First Volume"> Volume content here </volume> <chapter title="First Chapter"> Chapter content here </chapter>
このコードでは、それぞれ2つの列を持つ2つのResultSetに評価されます。例7-12は、これらのResultSetを示しています。
例7-12 XML要素で定義されたResultSet
@ResultSet volume 2 volume volume:title Volume content here First Volume @end @ResultSet chapter 2 chapter chapter:title Chapter content here First Chapter @end
データ・セクションでは、ResultSetに対して繰り返された要素を使用できます。繰り返された要素は通常、コードをループ処理してResultSetを作成する場合に役立ちます。
繰り返された要素は、ResultSetの一部でないかぎり許可されません。
例7-13は、chapter
ResultSetのためにchapter
要素がどのように繰り返されるかを示しています。
例7-13 ResultSetのために繰り返された要素
<idcformrules resultsets="chapter"> <chapter title="First Chapter"> Some content here </chapter> <chapter title="Second Chapter"> More content here </chapter>
このコードでは、2つの列と2つの行を持つResultSetに評価されます。例7-14は、このResultSetを示しています。
例7-14 繰り返された要素で作成されたResultSet
@ResultSet chapter 2 chapter chapter:title Some content here First Chapter More content here Second Chapter @end
ResultSetにはネストされた要素があってかまいませんが、例7-15に示すように、ネストされた要素を親要素内で繰り返すことはできません。この例に示したコードでは、最初の<chapter>
要素内で<section>
要素を追加しようとしても許可されません。
例7-15 ResultSetのために繰り返されたネスト済要素
<idcformrules resultsets="chapter"> <chapter title="First Chapter"> Some content here <section title="First Section of First Chapter"> Section content </section> </chapter> <chapter title="Second Chapter"> More content here </chapter>
例7-16に示すように、このコードでは、4つの列と4つの行を持ち、最後の2つのセルが空白のResultSetに評価されます。
例7-16 繰り返されたネスト済要素で作成されたResultSet
@ResultSet chapter 4 chapter chapter:title chapter!section chapter!section:title Some content here First Chapter Section Content First Section of First Chapter More content here Second Chapter @end
ResultSetの編集には、次のガイドラインが適用されます。
ResultSet内の特定の行を更新するには、リクエスト・パラメータでResultSetの行番号を指定する必要があります。シャープ記号(#)がコンテンツ・サーバーによって使用され、特定の行を示します。#文字を使用して行を指定しない場合は、行が付加されます。まだ存在していない行番号を指定した場合は、十分な空の行が追加されて、編集対象となる行が提供されます。
例7-17は、ResultSetの最初の行(行0)を更新する方法を示しています。
感嘆符(!)を使用して、ResultSetに新規の行を挿入します。
たとえば、comment
ResultSetに作成者とタイトルのフィールドを挿入するには、入力フィールドにcomment!author
とcomment!title
という名前を付けることができます。これらのフィールドがResultSetにまだない場合は、フォームの送信時に追加されます。
ResultSetから行を削除するには、例7-18に示すように、すべてのフィールド値を空にして、空白となるようにします。
例7-18 ResultSetからの最初の行の削除
<input type="hidden" name="comment#0" value=""> <input type="hidden" name="comment!title#0" value=""> <input type="hidden" name="comment!date#0" value=""> <input type="hidden" name="comment!author#0" value="">
ResultSetから行を削除するための別の方法としては、DeleteRows
フォーム要素を、ResultSet名と行番号のカンマで区切られたペアのリストに設定します。たとえば、comment
ResultSetから行2を削除し、book
ResultSetから行5を削除するには、DeleteRows
フォーム要素を次のコンマで区切られたペアに設定します。
comment:2,book:5
フォーム・セクションには、HTMLフォーム要素の表示など、ページに必要な機能のためのコードが含まれます。アセンブルされたWebページのフォーマットを制御するために、HTML表内に、フォーム・プロパティ、フォーム・フィールドおよびフォーム・ボタンが配置されます。
コードの例は、第7.6.1項「フォームの共通コード」を参照してください。
例7-19に示すように、フォーム・セクションの先頭は、2行のIdocスクリプトです。
例7-19 フォーム・セクションを開始するためのIdocスクリプト
<!--$formName="HTMLForm"--> <!--$include std_html_form_submit_start-->
the std_page.idoc
リソース・ファイルのstd_html_form_submit_start
インクルードには、POST
メソッドを使用して標準的なHTMLフォームを作成し、IdcService
の値をSUBMIT_HTML_FORM
に設定して、dID
変数を現在のHCSFページの値に設定するためのコードが含まれます。例7-20は、このコードを示しています。
フォーム表は通常、プロパティの定義で始まります。この定義とは、フォーム・フィールドとしてフォームを作成し、そのフィールドを編集可能にして、フィールド・キャプション領域のサイズを設定するものです。例7-21は、これらのプロパティ定義を示しています。
例7-22に示すように、それぞれの入力フィールドを作成するには通常、数行のコードが使用されます。
例7-22 フォーム上に入力フィールドを作成するためのコード
<!--$eval("<$product_name:maxLength=250$>")--> <!--$fieldName="model", fieldCaption="Model Number"--> <!--$include std_display_field-->
注意: 表示が適切に行われるようにするために、追加のコードが必要となるフィールドもあります。たとえば、テキスト領域のサイズを増やすために、標準的な <@dynamicalhtml std_memo_entry@> <textarea name="<$fieldName$>" rows=15 cols=50 wrap=virtual><$fieldValue$></textarea> <@end@> |
DataScript
: DataScriptというフォーム・フィールドを、送信されているフォームに追加した場合、その値に対するIdocスクリプトがあれば、コンテンツ・サーバーがフォームを処理するときにそのスクリプトを評価します。
(HCSPフォーム内のデータ・アイランドから生成された)表が2つあり、1つの表の中にあるエントリがもう1つの表の中のエントリを参照しています。最初の表の行を更新するときに、2番目の表の特定の列および行の値を変更することが目標です。この値変更を行うために、例7-23に示すように、Idocスクリプトを使用し、JavaScriptを記述してDataScriptの値を設定できます。
例7-23 表の行を更新するときの、別の表のフィールド値の変更
modifyRowAndColumn(row, column, value) { document.myform.DataScript = "<$setValue('#local', 'table2!'"+ column + "#'"+ row + "','" + value + "')$>"; }
次に、更新フォームの送信中に、column = "myColumn"、row="1"
、value = "Test"
とした関数をコールすると、送信前のDataScript値は次のようになります。
DataScript.value = <$setValue('#local', 'table2!myColumn#1', 'Test')$>
フォームが送信された後、表table2
の行1の列table2!myColumn
が更新されて、値Test
が反映されます。
DataScriptを使用すると、データ・アイランドにある他のエントリを、その名前を参照するHTMLフォーム・フィールドを実際に作成しなくても、自由に編集できると言うこともできます。
フォームの送信ボタンとリセット・ボタンを作成するには通常、2行のコードが使用されます。例7-24は、これらの行を示しています。
動的サーバー・ページが相互に連携することによって、コンテンツ・サーバーの動作を変更することができます。動的サーバー・ページを作成できるようにするには、参照するページ用のカスタム・インクルードを含むIDOCファイルを作成しておく必要があります。
動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルを作成する手順は次のとおりです。
例7-25に示すフォーマットで、カスタム・インクルードを含むIDOCファイルを作成します。
この例では、最初のインクルードはHelloWorld
と名付けられ、2番目のインクルードでは、HTMLコードを1行定義しています。
拡張子を.idoc
としてこのファイルを保存します(例、helloworld.idoc
)。
このIDOCファイルをコンテンツ・サーバーにチェックインします。このとき、helloworld
のように、別のファイルから参照できるコンテンツIDを指定します。
このIDOCファイルは、参照元のいずれのHCS*ページでも利用可能です。
HCSTファイルでIDOCファイルを参照することによって、HCST動的サーバー・ページを作成できます。
HCSTページを作成する手順は次のとおりです。
例7-26に示すHCSTファイルのような、IDOCファイル内のインクルードを参照するHCSTファイルを作成します。
例7-26 カスタム・インクルードを参照するHCSTファイル
<HTML> <HEAD> <$docLoadResourceIncludes("dDocName=helloworld&RevisionSelectionMethod=LatestReleased")$> </HEAD> <BODY> You should see it: <$include HelloWorld$> </BODY> </HTML>
この例では、<HEAD>
タグの後の行によってhelloworld.idoc
ファイルがロードされ、IDOCファイル内のインクルードがこのHCSTページで利用可能となります。<BODY>
タグの後の2番目の行によって、helloworld.idoc
ファイルのHelloWorld
インクルードのコードが表示されます。Idocスクリプトの標準的なタグ<$...$>
が使用されていることに注意してください。
拡張子を.hcst
としてこのファイルを保存します(例: helloworld.hcst
)。
HCSTファイルをコンテンツ・サーバーにチェックインします。
HCSPファイルでIDOCファイルを参照することによって、HCSP動的サーバー・ページを作成できます。
HCSPページを作成する手順は次のとおりです。
例7-27に示すHCSPファイルのような、IDOCファイル内のインクルードを参照するHCSPファイルを作成します。
例7-27 カスタム・インクルードを参照するHCSPファイル
<HTML> <HEAD> <!--$docLoadResourceIncludes("dDocName=helloworld&RevisionSelectionMethod=LatestReleased")--> </HEAD> <BODY> You should see it: <!--$include HelloWorld--> </BODY> </HTML>
この例では、<HEAD>
タグの後の行によってhelloworld.idoc
ファイルがロードされ、IDOCファイル内のインクルードがこのHCSPページで利用可能となります。<BODY>
タグの後の2番目の行によって、helloworld.idoc
ファイルのHelloWorld
インクルードのコードが表示されます。HTMLコメント・タグ<!--...-->
が使用されていることに注意してください。
拡張子を.hcsp
としてこのファイルを保存します(例: helloworld.hcsp
)。
HCSPファイルをコンテンツ・サーバーにチェックインします。
一般的なHCSFページとそれに関連付けられたIDOCファイルを例7-28に示します。この例では、ユーザーが記入して送信し、コンテンツ・アイテムとして製品の説明を入力できるフォームを作成します。
HCSFページを作成する手順は次のとおりです。
例7-28に示すように、form_std_page
というIDOCファイルを参照するHCSFファイルを作成します。
例7-28 HCSFファイル内の製品の説明フォーム
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <!--$docLoadResourceIncludes("dDocName=form_std_page& RevisionSelectionMethod=Latest")--> <head> <meta NAME="idctype' CONTENT="form; version=1.0"> <!--$include form_head_section--> </head> <!--$include form_pre_xml_section--> <!--$idcbegindata--> <idcformrules isFormFinished="0"/> <product_name content="html"> </product_name? <model_number content="html"> SC- </model_number> <summary_description> Enter a summary here. </summary_description> <full_description> Enter a full description here. </full_description> <author> <division> Household Products </division> <revision> </revision> <!--$idcenddata--> <!--$include form_post_xml_section--> </body> </html>
この例では、html
タグの後の行によって、form_std_page
をコンテンツIDとするIDOCファイルがロードされ、IDOCファイル内のインクルードがこのHCSFページで利用可能となります。
form_std_page
IDOCファイルに定義されている、meta
タグの後の2つのインクルードによって、Webページの先頭にコードが生成されます。
idcformrules
タグのisFormFinished
属性によって、フォームが未完成であることがコンテンツ・サーバーに伝えられるため、フィールドを編集してフォームを送信できます。
タグごとにcontent
プロパティを設定する必要はなく、デフォルトでhtml
が設定されます。
idcbegindata
タグとidcenddata
タグによってXMLタグ付き領域が定義され、それによって、フォームのルールおよび初期メタデータが指定されます。
XMLタグの各セットのテキストが、フォーム上の対応するフィールドに入力されます。
form_std_page
IDOCファイルに定義されている、この例の最後のインクルードによって、Webページの末尾にコードが生成されます。
product_form.hcsf
としてこのファイルを保存します。
HCSFファイルをコンテンツ・サーバーにチェックインします。
例7-29に示すように、カスタム・インクルードを含むIDOCファイルを作成します。
例7-29 カスタム・インクルードを含むIDOCファイル
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <body> <@dynamichtml form_head_section@> <!--standard includes for a standard hcsp page--> <$defaultPageTitle="Product Description Form"$> $include std_html_head_declarations$> <@end@> <@dynamichtml form_pre_xml_section@> <!--This code is here for static viewing.--> <$if 0$> <body> <$endif$> <$include body_def$> <@end@> <@dynamichtml form_post_xml_section@> <$include std_page_begin$> <$include std_header$> <$formName="HTMLForm"$> <$include std_html_form_submit_start$> <table> <$if strEquals(ref:dExtension,"hcsf"))$> <$isHcsf=1$> <$else$> <$isHcsp=1$> <$endif$> <$if isHcsf$> <$isFormSubmit=1,isEditMode=1$> <$endif$> <$captionFieldWidth=150, captionEntryWidth=200$> <$eval("<$product_name:maxLength=250$>")$> <$fieldName="product_name", fieldCaption="Product Name"$> <$if isHcsp$><isInfoOnly=1$><$endif$> <$include std_display_field$> <$eval("<$model_number:maxLngth=250$>")$> <$fieldName="model_number", fieldCaption="Model Number"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <$fieldName="summary_description", fieldCaption="Summary Description", fieldType="Memo"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <fieldName="full_descripton", fieldCaption="Full Description", fieldType="Memo"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <$eval("<$author:maxLength=250$>")$> <$fieldName="author", fieldCaption="Author"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <$eval("<$division:maxLength=250$>")$> <$fieldName="division", fieldCaption="Division"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <$eval("<$revision:maxLength=250$>")$> <$fieldName="revision", fieldCaption="Revision"$> <$if isHcsp$><$isInfoOnly=1$><$endif$> <$include std_display_field$> <tr> <td colspand=2><hr></td> </tr> <tr>align=center> <td colspan=2> <$if isHcsf$> <input type=submit name=Submit value=" Submit "> <input type=reset name=Reset Value="Reset"> <$endif$> <input type=hidden name="dDocTitle:default" value="<$"Product Description " & dateCurrent()$>"> </td> </tr> </table> </form> <$include std_page_end$> <@end@> </body> </html>
この例では、form_head_section
インクルードによって、ページ・タイトルと、(std_page.htm
リソース・ファイル内のstd_html_head_declarations
インクルードを参照する)HTMLの標準的なheadセクションのコードが定義されます。
form_pre_xml_section
インクルードによって、ページが静的に表示できるようになり、(std_page.htm
リソース・ファイル内のbody_def
インクルードを参照する)コンテンツ・サーバーの標準的なWebページのコードが定義されます。
form_post_xml_section
インクルードでは、フォーム・フィールドが定義されます。std_page.htm
リソース・ファイルに定義されている、std_page_begin
インクルードとstd_header
インクルードによって、コンテンツ・サーバーの標準的なWebページのコードが定義されます。これらのインクルードの後の2行によって、フォーム名と、(std_page.htm
ファイル内のstd_htm_form_submit_start
インクルードを参照する)HTMLの標準的なフォームのコードが定義されます。
table
タグの後の条件では、これが送信済の編集可能なフォームまたはページであるかが、ファイル名の拡張子に基づいて判別されます。これが編集可能なページ(isHcsf=1
)の場合は、次の条件によって、フィールドをフォーム・フィールドとして作成して編集可能にする変数が設定されます。条件の後の行では、フィールド・キャプションの表セルの幅が150ピクセルに設定され、入力フィールドの表セルの幅が200ピクセルに設定されています。
eval
関数では、テキスト・フィールドの最大長が250文字に設定されています。
fieldName
タグでは、フィールドの名前、キャプションおよびタイプが定義されます。fieldType
が定義されていない場合は、デフォルトでText
が設定されます。
これが送信済のフォーム(isHcsp=1
)の場合は、if isHcsp
条件によって、フォーム・フィールドを読取り専用にする変数に設定されます。
std_page.htm
リソース・ファイルに定義されているstd_display_field
インクルードによって、フォーム・フィールドを作成するコードが定義されます。
これが編集可能なフォーム(isHcsf=1
)の場合は、if isHcsf
条件によって、「送信」ボタンと「リセット」ボタンが作成されます。
if isHcsf
条件の後の行では、ドキュメント・タイトル(dDocTitle
)が自動的に生成されます。
std_page.htm
リソース・ファイルに定義されているstd_page_end
インクルードによって、Webページの末尾にコードが生成されます。
form_std_page.idoc
としてこのファイルを保存します。
このIDOCファイルをコンテンツ・サーバーにチェックインします。このとき、コンテンツIDをform_std_page
に指定します。(これは、HCSFページによって参照される名前です。)
コンテンツ・サーバーでHCSFコンテンツ・アイテムを検索します。
フォームを表示するためのリンクをクリックして、WebブラウザにHCSFページを作成します。フォームは、図7-2のサンプルのようになります。
サンプルの値をいくつか使用してフォームに記入し、「送信」をクリックします。
HCSPページとしてコンテンツ・アイテムが作成されます。
コンテンツ・サーバーでHCSPページを検索します。
WebブラウザにHCSPページを表示するためのリンクをクリックします。図7-3は、ページがどのように表示されるかを示しています。
HCSFページおよび関連付けられているIDOCファイルで広く使用されている機能は次のとおりです。
ファイル情報の取得
ファイル拡張子の参照
フォーム情報の定義
フォーム・フィールドの定義
非表示フィールドの定義
フォームの送信
DOC_INFO_SIMPLE
サービスを実行すると、特定のファイルのメタデータがページで利用可能になります。例7-30は、このサービスを実行するためのIdocスクリプトを示しています。
例7-31に示すように、フォームのif
文でファイル拡張子を参照して、フォームが送信済(.hcsp
ファイル)か未送信(.hcsf
ファイル)かを判別できます。
例7-31 ファイル拡張子を参照するための文
<$if (strEquals(ref:dExtension,"hcsf"))$> <$isHcsf=1$> <$else$> <$isHcsp=1$> <$endif$>
ref:接頭辞については、第7.2.1.4項「メタデータの参照」を参照してください。
例7-32に示すように、2行のコードによって、フォーム名と、HTMLフォームを開始するための標準的なインクルードが定義されます。
例7-33は、フォーム・プロパティを定義するための一般的なコードを示しています。
例7-34に示すように、フォーム・フィールドを表示するには、標準的なIdocスクリプト変数とstd_display_fieldインクルードを使用します。
例7-34 フォーム・フィールドを表示するための標準的なIdocスクリプト
<$fieldName="news_author",fieldDefault=dUser,fieldCaption="Author",isRequired=1,requiredMsg = "Please specify the author."$> <$include std_display_field$>
フィールドが正しく表示されるようにするために、追加のコードが必要となるフィールドもあります。たとえば、メモの標準的なテキスト領域は縦が3行、横が40列ですが、テキスト領域のサイズを増やすために、標準的なインクルードを無効にすることが必要になる場合があります。例7-35は、標準的なstd_memo_entry
インクルードを示しています。
例7-35 メモ・フィールドの標準的なインクルード
<@dynamichtml std_memo_entry@> <textarea name="<$fieldName$>" rows=3 cols=40 wrap=virtual> <$fieldValue$></textarea> <@end@>
指定したサイズ(この場合は、縦が15行、横が50列)にテキスト領域を増やすために、カスタムstd_memo_entry
インクルードを使用する方法を、例7-36に示します。
コントリビュータが変更できない非表示フィールドを定義することによって、送信されたフォーム(HCSP)のメタデータを指定できます。たとえば、次のコードでは、送信された各フォームにドキュメント・タイプNews_Forms
が割り当てられます。
<input type=hidden name="dDocType" value="News_Forms">
次のコードでは、送信されたフォームのセキュリティ・グループが指定されます。
<input type=hidden name="dSecurityGroup" value="Public">