| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
 前 |
 次 |
ホーム > Oracle WebCenter Contentによる開発 > 動的サーバー・ページの作成
| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > 動的サーバー・ページの作成
この章では、動的サーバー・ページを作成してWebページの外観およびナビゲーションを変更するために必要なビルディング・ブロックの使用方法について説明します。
この章では、次の項目について説明します。
動的サーバー・ページとは、コンテンツ・サーバーにチェックインされ、Webページを動的に生成するために使用されるファイルのことです。動的サーバー・ページは通常、Webページのルック・アンド・フィールおよびナビゲーションを変更するために使用されます。たとえば、動的サーバー・ページは、次のタスクを実行するために使用できます。
Content Publisherによってパブリッシュされる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設計とフォーム・ページのカスタマイズに最も役立ちます。
動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があります。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。
図6-1は、動的サーバー・ページの生成および使用プロセスを示しています。
動的サーバー・ページには次の4つのタイプがあり、ファイル名の4文字の拡張子によってコンテンツ・サーバーで識別されます。
IDOC
HCST
HCSP
HCSF
IDOCファイルは、HCST、HCSP、HCSFの各ページによって呼び出されるHTMLインクルードを含むテキスト・ファイルです。
詳細は、第11章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。
Hypertext Content Server Template(HCST)ファイルは、コンテンツ・サーバーの標準的なテンプレート・ページに似たテンプレート・ページであり、Webページをアセンブルする際にフレームワークとして使用されます。
HCSTページが使用される代表的なケースは、ページのコンテンツ自体が動的な場合、または、検索ページ、検索結果ページ、カスタム・チェックイン・ページなどでコンテンツ・サーバー機能が必要とされる場合です。
このタイプのページは、動的にアセンブルされたコードでほとんどが構成されているため、HCSTファイルはコンテンツ・サーバー内で索引が付けられません。
Hypertext Content Server Page(HCSP)ファイルはパブリッシュ済のWebページであり、実際のWebサイトのコンテンツを表示します。
HCSPファイルの代表的な作成方法としては、テンプレートとしてHCSTページを使用し、Content PublisherによってWebページを生成すること、または、HCSFページによってコンテンツ・サーバーでフォームを送信することがあります。
このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSPファイルはコンテンツ・サーバー内で索引が付けられます。
Hypertext Content Server Form(HCSF)ファイルは、HCSPファイルに似ていますが、Webブラウザから記入して送信することのできるHTMLフォーム・フィールドが含まれている点が違います。
ユーザーがHCSFページからフォームを記入して送信すると、HCSFページのXML要素によってメタデータが定義された別のコンテンツ・アイテムとして、HCSPファイルがチェックインされます。
このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSFファイルはコンテンツ・サーバー内で索引が付けられます。
HCSFページの詳細は、第6.1.1.4項「HCSFファイル」を参照してください。
動的サーバー・ページは、カスタム・コンポーネントとは異なる形でコンテンツ・サーバーに実装されていますが、WebCenter Contentコンポーネントのアーキテクチャ概念、特にコンテンツ・サーバーのテンプレートおよびHTMLインクルードに精通している必要があります。詳細は、第11章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。
動的サーバー・ページとともにコンテンツ・サーバーのインスタンスをカスタマイズするには、次の基本手順を実行します。
カスタム・インクルードを含むIDOCファイルを作成します。
IDOCファイルをコンテンツ・サーバーにチェックインします。
IDOCファイルを参照するHCSTファイル、HCSPファイルまたはHCSFファイルを作成します。
HCS*ファイルをコンテンツ・サーバーにチェックインします。
コンテンツ・サーバーで検索するか、またはパブリッシュされたWebページからリンクすることによって、WebブラウザでHCS*ファイルを表示します。
異なるタイプの動的サーバー・ページは、解釈も表示も異なっているため、ファイル内のIdocスクリプトは、異なるコーディングを行う必要があります。次の表は、それらの違いをまとめたものです。
|
注意: Idocスクリプトでは、標準的なHTMLインクルードのコーディングを使用します。詳細は、第17.2.1項「HTMLインクルード」を参照してください。 HCSTでは、コンテンツ・サーバーの標準的なテンプレートのコーディングを使用します。詳細は、第17.2.8.1項「テンプレート・ページとレポート・ページ」を参照してください。 HCSPとHCSFでは特殊なコーディングが使用され、ページを静的にも動的にもレンダリングでき、全文索引を作成できます。 |
HCSPページとHCSFページでは、Idocスクリプトの式は一般的に、HTMLコメント・タグ間に配置されます。ページが静的に表示されるときには、このように配置することによって、Webブラウザでページ・コンテンツを表示でき、コンテンツの書式設定に使用されている動的コードがあっても無視されます。またこれによって、全文索引作成エンジンが、これらのページのコンテンツの索引を正常に作成できます。
次に、いくつかの例を示します。
IDOCファイルまたはHCSTファイル: <$include MyIdocExpression$>
HCSPファイルまたはHCSFファイル: <!--$include MyIdocExpression-->
状況によっては、HTMLコメントの開始と終了を制御することもできます。HCSPファイルとHCSFファイルでは、この操作を行うには、例6-1に示すように、Idoc Scriptの式の後にある終了タグで、ダッシュ(-)を他の文字に置換します。
例6-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-->.
例6-1では、ダッシュ(-)がシャープ記号(#)に置換されています。
HCSPファイルとHCSFファイルでの別のオプションとしては、例6-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ファイルからすべてのインクルードがロードされます。例6-3に、HCSTファイルからこの関数をコールする形式を示します。
例6-3 HCSTファイルでのdocLoadResourceIncludes関数コール
<$docLoadResourceIncludes("dDocName=system_std_page&RevisionSelectionMethod=Latest")$>
例6-4に、HCSPファイルまたはHCSFファイルからこの関数をコールするフォーマットを示します。
例6-4 HCSPファイルまたはHCSFファイルでのdocLoadResourceIncludes関数コール
<!--$docLoadResourceIncludes("dDocName=system_std_page&RevisionSelectionMethod=Latest")-->
指定されたコンテンツ・アイテムのネイティブ・ファイルでは、拡張子が.idocになっている必要があります。
docLoadResourceIncludesコールは、HCS*ファイル内で最初のインクルードの前に配置する必要があります。この関数は、ページのHEADセクション内に配置することをお薦めします。
HCS*ページからdocLoadResourceIncludes関数をコールするときには、正しいアンパサンド文字を使用する必要があります。詳細は、第6.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以上です。詳細は、第24章「環境へのWebCenter Contentの統合の開始」を参照してください。
コンテンツ・サーバーの標準的なサービスについては、IdcHomeDir/resources/core/tables/std_services.htmファイルを参照してください。
executeService関数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。
サービスの詳細は、第24章「環境へのWebCenter Contentの統合の開始」を参照してください。
|
パフォーマンスに関するヒント: サービスの使用は控えめにしてください。ページ上でサービス・コールが多すぎると、パフォーマンスが影響を受けたり、スケーラビリティが制限される場合があります。 |
動的サーバー・ページの開発を支援するための次の推奨事項には、一般的なガイドラインとHCSFのガイドラインが含まれています。
次の推奨事項は、すべてのタイプの動的サーバー・ページの開発に当てはまります。
テンプレートは、できるだけ簡略でコードのないものにします。テンプレートはHTMLインクルードのみにして、コードと条件はすべてIDOCファイルに入れるようにします。これが特に役立つのはHCSFページで、そこでは、送信されたフォームも、IDOCファイルに対する変更に反映されます。
Oracle WebCenter Content Serverのインスタンスをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があることを頭に入れてください。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。
動的サーバー・ページを使用してWebサイトを開発するときには、開発プロセスとコントリビューション・プロセスを、所有の観点で考えます。
構造(サイトの設計とナビゲーションを含む)は、Webマスターが所有しています。動的サーバー・ページを使用するときには、構造は、IDOCファイルに定義されているインクルードに含まれており、そのインクルードとともに制御されます。
コンテンツ、すなわちWebページの実際のテキストは、コントリビュータが所有しています。動的サーバー・ページを使用するときには、コンテンツは主として、IDOCファイル内のインクルードを利用するHCSPファイルに含まれています。
Content Publisherとともに動的サーバー・ページを使用することは、Web公開の強力なツールになる可能性があります。Word文書またはHCSFページを使用してコンテンツを作成し、Content Publisherを使用して、そのドキュメントを、パブリッシュされたHCSPファイルに変換することができます。SCPテンプレートで前にインクルードと後ろにインクルードのオプションを使用して、追加のIdocスクリプト・インクルードを挿入できます。
Content Publisherで動的サーバー・ページをパブリッシュする場合は、ドキュメントを簡単に識別できるように接頭辞オプションを使用します。
一貫性のあるネーミング規則を使用します。たとえば、「システム」レベルのインクルードの場合は、IDOCファイルにsystem_std_pageという名前を付け、そのファイル内の各インクルードに、system_を接頭辞とする名前を付けることができます。こうすると、インクルードを見つけやすくなります。
動的サーバー・ページのタイプごとにコンテンツ・タイプを作成することをお薦めします(HCSF_templatesやsubmitted_formsなど)。
優れたコーディング手法に従って、動的サーバー・ページに常にコメントを入れて、カスタマイズの記録を残してください。
次の推奨事項は、HCSFページの開発にのみ当てはまります。
フォームを設計する際には、テンプレートがどのように使用されるかを検討してください。
このテンプレートは、フォームを送信するユーザーのロールに応じて変わるか
送信されたコンテンツは、重要なワークフローに入るか
どのようなデフォルトのメタデータ値を設定するか
複数のライン入力に対するResultSetがフォームに含まれるか
フォームのパラメータがWebブラウザからWebサーバーに渡され、Oracle WebCenter Content Serverを通じてフィルタリングされてWebブラウザに戻されるときに、そのパラメータが表示されるようにするには、次のようにして、インクルード・コードのmethod属性をPOSTからGETに変更します。
<form name="<$formName$>" method="GET" action="<$HttpCgiPath$>">
DataScriptというフォーム・フィールドを、送信されているフォームに追加した場合、その値に対するIdocスクリプトがあれば、Oracle WebCenter Content Serverがフォームを処理するときにそのスクリプトを評価します。
Oracle WebCenter Content ServerテンプレートおよびHTMLフォームに対する標準的な書式設定ルールを遵守することに加えて、HCSFページでは、Oracle WebCenter Content Serverによる処理を可能とする特殊なセクションとタグがいくつか必要です。これらの特殊セクションは、通常のHCSFファイルでは次の順序で表示されます。
ロード・セクション
データ・セクション
フォーム・セクション
完全なHCSFページの例は、第6.1.1.4項「HCSFファイル」を参照してください。
HCSFページの先頭にあるロード・セクションでは、ファイルをHTMLファイルとして宣言し、IDOCファイルをロードして、ページに関する他の情報をロードします。例6-5は、一般的なロード・セクションを示しています。
例6-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ファイルからすべてのインクルードがロードされます。詳細は、第6.2.4.1.2項「docLoadResourceIncludes関数」を参照してください。
meta要素がContent Publisherによって使用され、これが特殊なタイプのページであることを示します。
この要素は、フォームがContent Publisherによってパブリッシュされていない場合は不要です。
meta要素は、HTMLファイルのHEADセクションの内側に配置する必要があります。
metaタグには次の構文を使用します。
<meta NAME="idctype" CONTENT="form; version=1.0">
HCSFページのHEADセクションには、必要に応じて、変数定義とHTMLインクルードが含まれる場合があります。HEADセクションの中でデフォルトのページ・タイトルを定義し、std_html_head_declarationsコードをロードする行を、例6-6に示します。
HCSFページのデータ・セクションには、フォームの処理に使用されるルールおよびメタデータ情報が含まれます。データ・セクション内の情報とページの表示との間には、次のように緊密な関係があります。
HCSFページがユーザーに配信された時点で、データ・セクション内の情報がDataBinderオブジェクトに解析され、フォーム・セクションにマージされます。
フォームが送信された時点で、データ・セクション内の情報がリクエストとマージされ、データ・セクションに再び書き出されます。詳細は、第11章「データ・バインダ」および第11.1.3.1.1項「HDAファイル内の要素」を参照してください。
例6-7に示すように、データ・セクションは、Idoc Scriptのタグidcbegindataとidcenddataの間に配置されたXML要素で構成されます。
例6-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の書式設定の詳細は、第6.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が設定されます。
Content Publisherでは、content属性以外の属性はすべて無視されます。
HCSFページをContent Publisherによってパブリッシュしない場合は、データ・セクション内でネストされたXML要素(別名ノード)を使用できます。例6-8は、<chapter>要素内でネストされた<section>要素を示しています。
ネストされたXML要素を参照するには、ルートレベルの要素から始め、要素レベルの間に感嘆符(!)を使用します。次に例を示します。
chapter!section
任意の要素の属性を参照するには、タグ名の後ろにコロン(:)を使用します。次に例を示します。
chapter!section:title
データ・セクション内の要素を参照する場合は、次の文のいずれかが真の場合にのみ、フォームの送信時に要素の値を元のデータ・セクションにマージできます。
デフォルト値は、タグ・パスに:default接尾辞を適用することによって指定できます。デフォルトの要素には、後で評価できるように、Idocスクリプトが含まれている場合もあります。例6-9に、dDocTitleのデフォルト値を指定するための書式を示します。
ExtraRootNodesフォーム要素を使用すると、フォームのデータ・セクション内のタグを指定するのではなく、Idocスクリプトの変数を作成してそれにタグ名を付加することによってタグを追加できます。フォームの最後で、ExtraRootNodesの値に文字列の値を代入して、元のデータ・セクションにマージできます。
resultsetsフォーム要素を使用すると、データ・セクション内のResultSetを指定するのではなく、ResultSetとしてタグを追加できます。
ExtraRootNodesフォーム要素とResultSetフォーム要素では、カンマで区切られたタグのリストを使用します。
idcformrules resultsets属性にmychapters!chapter要素がまだ定義されていない場合に、有効なResultSetとしてそれを追加するフォーム要素を、例6-10に示します。また、必要に応じて、ルート要素mychaptersも追加されます。
次のように、HCSFページのデータ・セクション内のXML要素を使用して、ResultSetを定義できます。
idcformrules要素のresultsets属性を使用して、ResultSetを指定する必要があります。
要素名は完全修飾されている必要があり、ルート・ノードからの参照のフルパスを使用する必要があります。
ResultSetの列は、要素コンテンツおよび要素属性です。
ResultSetでのXML要素の繰返しとネストに対する制限については、例6-13と例6-15を参照してください。
例6-11は、volumeとchapterという2つのResultSetを定義するXML要素を示しています。
例6-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に評価されます。例6-12は、これらのResultSetを示しています。
例6-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
HCSFページをContent Publisherによってパブリッシュしない場合は、データ・セクション内でResultSetに対して繰り返された要素を使用できます。繰り返された要素は通常、コードをループ処理してResultSetを作成する場合に役立ちます。
ResultSetのために繰り返された要素には次のルールが適用されます。
繰り返された要素は、ResultSetの一部でないかぎり許可されません。
繰り返されたXML要素は、Content Publisherでは許可されません。
例6-13は、chapter ResultSetのためにchapter要素がどのように繰り返されるかを示しています。
例6-13 ResultSetのために繰り返された要素
<idcformrules resultsets="chapter">
<chapter title="First Chapter">
Some content here
</chapter>
<chapter title="Second Chapter">
More content here
</chapter>
このコードでは、2つの列と2つの行を持つResultSetに評価されます。例6-14は、このResultSetを示しています。
例6-14 繰り返された要素で作成されたResultSet
@ResultSet chapter 2 chapter chapter:title Some content here First Chapter More content here Second Chapter @end
ResultSetにはネストされた要素があってかまいませんが、例6-15に示すように、ネストされた要素を親要素内で繰り返すことはできません。この例に示したコードでは、最初の<chapter>要素内で<section>要素を追加しようとしても許可されません。
例6-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>
例6-16に示すように、このコードでは、4つの列と4つの行を持ち、最後の2つのセルが空白のResultSetに評価されます。
例6-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の行番号を指定する必要があります。シャープ記号(#)がコンテンツ・サーバーによって使用され、特定の行を示します。#文字を使用して行を指定しない場合は、行が付加されます。まだ存在していない行番号を指定した場合は、十分な空の行が追加されて、編集対象となる行が提供されます。
例6-17は、ResultSetの最初の行(行0)を更新する方法を示しています。
感嘆符(!)を使用して、ResultSetに新規の行を挿入します。
たとえば、comment ResultSetに作成者とタイトルのフィールドを挿入するには、入力フィールドにcomment!authorとcomment!titleという名前を付けることができます。これらのフィールドがResultSetにまだない場合は、フォームの送信時に追加されます。
ResultSetから行を削除するには、例6-18に示すように、すべてのフィールド値を空にして、空白となるようにします。
例6-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表内に、フォーム・プロパティ、フォーム・フィールドおよびフォーム・ボタンが配置されます。
コードの例は、第6.6.1項「フォームの共通コード」を参照してください。
例6-19に示すように、フォーム・セクションの先頭は、2行のIdocスクリプトです。
例6-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ページの値に設定するためのコードが含まれます。例6-20は、このコードを示しています。
フォーム表は通常、プロパティの定義で始まります。この定義とは、フォーム・フィールドとしてフォームを作成し、そのフィールドを編集可能にして、フィールド・キャプション領域のサイズを設定するものです。例6-21は、これらのプロパティ定義を示しています。
例6-22に示すように、それぞれの入力フィールドを作成するには通常、数行のコードが使用されます。
例6-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番目の表の特定の列および行の値を変更することが目標です。この値変更を行うために、例6-23に示すように、Idocスクリプトを使用し、JavaScriptを記述してDataScriptの値を設定できます。
例6-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行のコードが使用されます。例6-24は、これらの行を示しています。
動的サーバー・ページが相互に連携することによって、コンテンツ・サーバーの動作を変更することができます。動的サーバー・ページを作成できるようにするには、参照するページ用のカスタム・インクルードを含むIDOCファイルを作成しておく必要があります。
動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルを作成する手順は次のとおりです。
例6-25に示すフォーマットで、カスタム・インクルードを含むIDOCファイルを作成します。
この例では、最初のインクルードはHelloWorldと名付けられ、2番目のインクルードでは、HTMLコードを1行定義しています。
拡張子を.idocとしてこのファイルを保存します(例、helloworld.idoc)。
このIDOCファイルをコンテンツ・サーバーにチェックインします。このとき、helloworldのように、別のファイルから参照できるコンテンツIDを指定します。
このIDOCファイルは、参照元のいずれのHCS*ページでも利用可能です。
HCSTファイルでIDOCファイルを参照することによって、HCST動的サーバー・ページを作成できます。
HCSTページを作成する手順は次のとおりです。
例6-26に示すHCSTファイルのような、IDOCファイル内のインクルードを参照するHCSTファイルを作成します。
例6-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ページを作成する手順は次のとおりです。
例6-27に示すHCSPファイルのような、IDOCファイル内のインクルードを参照するHCSPファイルを作成します。
例6-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ファイルを例6-28に示します。この例では、ユーザーが記入して送信し、コンテンツ・アイテムとして製品の説明を入力できるフォームを作成します。
HCSFページを作成する手順は次のとおりです。
例6-28に示すように、form_std_pageというIDOCファイルを参照するHCSFファイルを作成します。
例6-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ページで利用可能となります。
これがコンテンツ・サーバーのHTMLフォームであるとContent Publisherで認識されるようにするには、metaタグが必要です。
form_std_page IDOCファイルに定義されている、metaタグの後の2つのインクルードによって、Webページの先頭にコードが生成されます。
idcformrulesタグのisFormFinished属性によって、フォームが未完成であることがコンテンツ・サーバーに伝えられるため、フィールドを編集してフォームを送信できます。
タグごとにcontentプロパティを設定する必要はなく、デフォルトでhtmlが設定されます。
idcbegindataタグとidcenddataタグによってXMLタグ付き領域が定義され、それによって、フォームのルールおよび初期メタデータが指定されます。
XMLタグの各セットのテキストが、フォーム上の対応するフィールドに入力されます。
form_std_page IDOCファイルに定義されている、この例の最後のインクルードによって、Webページの末尾にコードが生成されます。
product_form.hcsfとしてこのファイルを保存します。
HCSFファイルをコンテンツ・サーバーにチェックインします。
例6-29に示すように、カスタム・インクルードを含むIDOCファイルを作成します。
例6-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ページを作成します。フォームは、図6-2のサンプルのようになります。
サンプルの値をいくつか使用してフォームに記入し、「送信」をクリックします。
HCSPページとしてコンテンツ・アイテムが作成されます。
コンテンツ・サーバーでHCSPページを検索します。
WebブラウザにHCSPページを表示するためのリンクをクリックします。図6-3は、ページがどのように表示されるかを示しています。
HCSFページおよび関連付けられているIDOCファイルで広く使用されている機能は次のとおりです。
ファイル情報の取得
ファイル拡張子の参照
フォーム情報の定義
フォーム・フィールドの定義
非表示フィールドの定義
フォームの送信
サービスDOC_INFO_SIMPLEを実行すると、特定のファイルのメタデータがページで利用可能になります。例6-30は、このサービスを実行するためのIdocスクリプトを示しています。
例6-31に示すように、フォームのif文でファイル拡張子を参照して、フォームが送信済(.hcspファイル)か未送信(.hcsfファイル)かを判別できます。
例6-31 ファイル拡張子を参照するための文
<$if (strEquals(ref:dExtension,"hcsf"))$>
<$isHcsf=1$>
<$else$>
<$isHcsp=1$>
<$endif$>
ref:接頭辞については、第6.2.1.4項「メタデータの参照」を参照してください。
例6-32に示すように、2行のコードによって、フォーム名と、HTMLフォームを開始するための標準的なインクルードが定義されます。
例6-33は、フォーム・プロパティを定義するための一般的なコードを示しています。
例6-34に示すように、フォーム・フィールドを表示するには、標準的なIdocスクリプト変数とstd_display_fieldインクルードを使用します。
例6-34 フォーム・フィールドを表示するための標準的なIdocスクリプト
<$fieldName="news_author",fieldDefault=dUser,fieldCaption="Author",isRequired=1,requiredMsg = "Please specify the author."$> <$include std_display_field$>
フィールドが正しく表示されるようにするために、追加のコードが必要となるフィールドもあります。たとえば、メモの標準的なテキスト領域は縦が3行、横が40列ですが、テキスト領域のサイズを増やすために、標準的なインクルードを無効にすることが必要になる場合があります。例6-35は、標準的なstd_memo_entryインクルードを示しています。
例6-35 メモ・フィールドの標準的なインクルード
<@dynamichtml std_memo_entry@>
<textarea name="<$fieldName$>" rows=3 cols=40 wrap=virtual> <$fieldValue$></textarea>
<@end@>
指定したサイズ(この場合は、縦が15行、横が50列)にテキスト領域を増やすために、カスタムstd_memo_entryインクルードを使用する方法を、例6-36に示します。
コントリビュータが変更できない非表示フィールドを定義することによって、送信されたフォーム(HCSP)のメタデータを指定できます。たとえば、次のコードでは、送信された各フォームにドキュメント・タイプNews_Formsが割り当てられます。
<input type=hidden name="dDocType" value="News_Forms">
次のコードでは、送信されたフォームのセキュリティ・グループが指定されます。
<input type=hidden name="dSecurityGroup" value="Public">
