(57)【要約】【課題】  プログラマーが記述するＨＴＭＬ文書から画面デザインの情報を完全に分離し、更にページ・レイアウト情報を提供するサーバーから、プログラマーが組み込んだロジックや非公開情報を管理するデータベースを不可視にできるウェブ・コンテンツ生成システムを提供する。【解決手段】  ウェブ・ページ・レイアウト・データベース７と、前記ウェブ・ページ・レイアウト・データベースに格納されるウェブ・ページ・レイアウト情報１０と、前記ウェブ・ページ・レイアウト情報にもとづきウェブ・ブラウザ上でウェブ・コンテンツを生成する画面描画ライブラリ９と、前記画面描画ライブラリの要求にもとづき前記ウェブ・ページ・レイアウト情報を出力する第二処理装置６と、で構成され、前記画面描画ライブラリを備えることにより、非公開情報等を管理するプロプライエタリ・データベース２０２をシステム内に設ける必要がない。【選択図】図１
2015138541.tif 000002
【特許請求の範囲】
【請求項１】
ウェブ・コンテンツを生成するウェブ・コンテンツ生成システム１であって、
ウェブ・ページのレイアウトを定義するウェブ・ページ・レイアウト・データベース７と、
前記ウェブ・ページ・レイアウト・データベースに格納されるウェブ・ページのレイアウト等の情報からなるウェブ・ページ・レイアウト情報１０と、
前記ウェブ・ページ・レイアウト情報にもとづきウェブ・ブラウザ上でウェブ・コンテンツを生成する画面描画ライブラリ９と、
前記画面描画ライブラリの要求にもとづき前記ウェブ・ページ・レイアウト情報を出力する第二処理装置６と、で構成され、
前記画面描画ライブラリを備えることにより、非公開情報等を管理するプロプライエタリ・データベース２０２をシステム内に設ける必要がないことを特徴とするウェブ・コンテンツ生成システム。
【請求項２】
前記ウェブ・ページ・レイアウト情報は、前記第二処理装置から出力する際にＸＭＬ形式で表現されていることを特徴とする請求項１に記載のウェブ・コンテンツ生成システム。
【請求項３】
前記ウェブ・ページ・レイアウト情報は、前記第二処理装置から出力する際にＪＳＯＮ形式で表現されていることを特徴とする請求項１に記載のウェブ・コンテンツ生成システム。
【請求項４】
前記画面描画ライブラリの関数呼び出しにより、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することを特徴とする請求項１に記載のウェブ・コンテンツ生成システム。
【請求項５】
前記ウェブ・ページ・レイアウト情報は、ウィジェット２４と呼ばれるウェブ部品の集合により構成されることを特徴とする請求項１に記載のウェブ・コンテンツ生成システム。
【請求項６】
前記ウェブ部品は、テキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、画面描画ライブラリにてプレースホルダー文字列に具体的な文字列を動的に割り当てることを特徴とする請求項５に記載のウェブ・コンテンツ生成システム。
【請求項７】
前記画面描画ライブラリの関数呼び出しにより、前記プレースホルダー文字列に具体的な文字列を動的に割り当てた後、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することを特徴とする請求項６に記載のウェブ・コンテンツ生成システム。
【請求項８】
前記ウェブ部品は、テキスト属性を有し、そのテキストの記法により、複数のサブ部品を表現及び生成することを特徴とする請求項５に記載のウェブ・コンテンツ生成システム。
【請求項９】
前記ウェブ部品及び前記サブ部品に自動的に識別名が割り振られることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１０】
前記ウェブ部品はｕｌタグを表し、サブ部品はｌｉタグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１１】
前記ウェブ部品はｏｌタグを表し、サブ部品はｌｉタグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１２】
前記ウェブ部品はｔａｂｌｅタグを表し、テキスト属性の各行がサブ部品のｔｒタグに、各行を区切り文字で分割した部分文字列がサブ部品のｔｈタグ、ｔｄタグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１３】
前記ウェブ部品はｓｅｌｅｃｔタグを表し、サブ部品はｏｐｔｉｏｎタグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１４】
前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｒａｄｉｏ”＞タグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１５】
前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｃｈｅｃｋｂｏｘ”＞タグに展開されることを特徴とする請求項８に記載のウェブ・コンテンツ生成システム。
【請求項１６】
前記ウェブ部品は、複数のウィジェットをまとめて１つのウィジェットとして扱えるようにしたコンテナ・ウィジェットであることを特徴とする請求項５に記載のウェブ・コンテンツ生成システム。
【請求項１７】
前記コンテナ・ウィジェットは、複数のウィジェットが１つの繰り返しパターンを形成し、コンテナ・ウィジェットの縦横サイズと、繰り返しパターンの縦横サイズを、それぞれ保持し、一定の規則に従って繰り返しパターンを複数回、複製表示することを特徴とする請求項１６に記載のウェブ・コンテンツ生成システム。
【請求項１８】
前記コンテナ・ウィジェットに含まれるウィジェットは、それぞれテキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、前記画面描画ライブラリに繰り返し回数分の連想配列の配列を渡すことで、  プレースホルダー文字列に対し繰り返しパターン毎にそれぞれ異なる文字列を動的に割り当てることを特徴とする請求項１７に記載のウェブ・コンテンツ生成システム。
【請求項１９】
前記コンテナ・ウィジェットは、繰り返しパターンを横方向に並べて表示し、繰り返しパターンの横幅の合計がコンテナ・ウィジェットの横幅を超える場合に次の行に改行することを特徴とする請求項１７に記載のウェブ・コンテンツ生成システム。
【請求項２０】
前記コンテナ・ウィジェットは、繰り返しパターンを縦方向に並べて表示することを特徴とする請求項１７に記載のウェブ・コンテンツ生成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブ・コンテンツ生成システムに関する。
【背景技術】
【０００２】
従来、ウェブ・コンテンツの作成を、画面レイアウト定義ファイルとデータベースの情報を元に、ＨＴＭＬ文書を出力するものは多数存在している。例えば、特許文献１には、表示画面のデザインを容易に変更することができ、また、表示データの追加・変更・削除等も容易に行えるウェブ・ページ・コンテンツ生成システムが開示されている。この場合、処理装置１２から出力される回答画面ファイルはＨＴＭＬ文書であった。このようにＷｅｂブラウザ２２に対しＨＴＭＬ文書で出力されると、プログラマーが追加の作業を行うことができない。また、新たなロジックを追加しようとした場合、一度前記ＨＴＭL文書を別の記憶装置等に保存し、追加作業を行わなければならなかった。さらに、前記処理装置１２から出力されたような機械生成されたＨＴＭＬ文書は、プログラマーが新たなロジックを追加しようとした場合、一見しただけではＨＴＭＬコードのどの部分を修正すればよいのかが判別しづらく、追加作業を非常に困難なものにしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２７６９８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、上述した問題を解決するためになされたもので、デザイナー及びプログラマーがひとつのＨＴＭＬファイルを巡って共同作業をするという作業工程を含まず、デザイナーが担当するデザインとプログラマーが担当するロジックを完全に分離して作業をできるとともに、プログラマーがロジックを追加する際にソフトウェアにより機械生成したＨＴＭＬ文書を直接編集する必要がなく、しかも、ページ・レイアウト情報を提供するサーバーから、プログラマーが組み込んだロジックや非公開情報を管理するデータベースを不可視にすることができるウェブ・コンテンツ生成システムを提供することを目的としている。
【課題を解決するための手段】
【０００５】
本発明のウェブ・コンテンツ生成システムは、ウェブ・ページのレイアウトを定義するウェブ・ページ・レイアウト・データベースと、前記ウェブ・ページ・レイアウト・データベースに格納されるウェブ・ページのレイアウト等の情報からなるウェブ・ページ・レイアウト情報と、前記ウェブ・ページ・レイアウト情報にもとづきウェブ・ブラウザ上でウェブ・コンテンツを生成する画面描画ライブラリと、前記画面描画ライブラリの要求にもとづき前記ウェブ・ページ・レイアウト情報を出力する第二処理装置と、で構成され、前記画面描画ライブラリを備えることにより、非公開情報等を管理するプロプライエタリ・データベースをシステム内に設ける必要がないことを特徴としている。
【０００６】
また、前記ウェブ・ページ・レイアウト情報は、前記第二処理装置から出力する際にＸＭＬ形式で表現されていることを特徴としている。
【０００７】
さらに、前記ウェブ・ページ・レイアウト情報は、前記第二処理装置から出力する際にＪＳＯＮ形式で表現されていることを特徴としている。
【０００８】
また、前記画面描画ライブラリの関数呼び出しにより、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することを特徴としている。
【０００９】
さらに、前記ウェブ・ページ・レイアウト情報は、ウィジェットと呼ばれるウェブ部品の集合により構成されることを特徴としている。
【００１０】
また、前記ウェブ部品は、テキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、画面描画ライブラリにてプレースホルダー文字列に具体的な文字列を動的に割り当てることを特徴としている。
【００１１】
さらに、前記画面描画ライブラリの関数呼び出しにより、前記プレースホルダー文字列に具体的な文字列を動的に割り当てた後、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することを特徴としている。
【００１２】
また、前記ウェブ部品は、テキスト属性を有し、そのテキストの記法により、複数のサブ部品を表現及び生成することを特徴としている。
【００１３】
さらに、前記ウェブ部品及び前記サブ部品に自動的に識別名が割り振られることを特徴としている。
【００１４】
また、前記ウェブ部品はｕｌタグを表し、サブ部品はｌｉタグに展開されることを特徴としている。
【００１５】
さらに、前記ウェブ部品はｏｌタグを表し、サブ部品はｌｉタグに展開されることを特徴としている。
【００１６】
また、前記ウェブ部品はｔａｂｌｅタグを表し、テキスト属性の各行がサブ部品のｔｒタグに、各行を区切り文字で分割した部分文字列がサブ部品のｔｈタグ、ｔｄタグに展開されることを特徴としている。
【００１７】
さらに、前記ウェブ部品はｓｅｌｅｃｔタグを表し、サブ部品はｏｐｔｉｏｎタグに展開されることを特徴としている。
【００１８】
また、前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｒａｄｉｏ”＞タグに展開されることを特徴としている。
【００１９】
さらに、前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｃｈｅｃｋｂｏｘ”＞タグに展開されることを特徴としている。
【００２０】
また、前記ウェブ部品は、複数のウィジェットをまとめて１つのウィジェットとして扱えるようにしたコンテナ・ウィジェットであることを特徴としている。
【００２１】
さらに、前記コンテナ・ウィジェットは、複数のウィジェットが１つの繰り返しパターンを形成し、コンテナ・ウィジェットの縦横サイズと、繰り返しパターンの縦横サイズを、それぞれ保持し、一定の規則に従って繰り返しパターンを複数回、複製表示することを特徴としている。
【００２２】
また、前記コンテナ・ウィジェットに含まれるウィジェットは、それぞれテキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、前記画面描画ライブラリに繰り返し回数分の連想配列の配列を渡すことで、
プレースホルダー文字列に対し繰り返しパターン毎にそれぞれ異なる文字列を動的に割り当てることを特徴としている。
【００２３】
さらに、前記コンテナ・ウィジェットは、繰り返しパターンを横方向に並べて表示し、繰り返しパターンの横幅の合計がコンテナ・ウィジェットの横幅を超える場合に次の行に改行することを特徴としている。
【００２４】
また、前記コンテナ・ウィジェットは、繰り返しパターンを縦方向に並べて表示することを特徴としている。
【発明の効果】
【００２５】
本発明のウェブ・コンテンツ生成システムは、ウェブ・ページのレイアウトを定義するウェブ・ページ・レイアウト・データベースと、前記ウェブ・ページ・レイアウト・データベースに格納されるウェブ・ページのレイアウト等の情報からなるウェブ・ページ・レイアウト情報と、前記ウェブ・ページ・レイアウト情報にもとづきウェブ・ブラウザ上でウェブ・コンテンツを生成する画面描画ライブラリと、前記画面描画ライブラリの要求にもとづき前記ウェブ・ページ・レイアウト情報を出力する第二処理装置と、で構成され、前記画面描画ライブラリを備えることにより、非公開情報等を管理するプロプライエタリ・データベースをシステム内に設ける必要がないことにより、サーバー処理装置とは完全に独立した別のウェブ・サーバーから配信されるＨＴＭＬ文書内で、当該ウェブ・ページ・レイアウト・データベースに格納されたウェブ・ページ・レイアウト情報にもとづき、ウェブ・コンテンツを生成・表示することができる。よって、デザイナーが担当するデザインとプログラマーが担当するロジックを完全に分離したウェブ・コンテンツ生成システムを提供することができる。また、前記画面描画ライブラリを備えることにより、非公開情報（個人情報、企業情報等）を管理するプロプライエタリ・データベースをシステム内に設ける必要がないため、非公開情報を第二ウェブ・サーバー装置等から直接アクセスされることを防止することができる。
【００２６】
また、本発明のウェブ・コンテンツ生成システムは、ウェブ・ページ・レイアウト情報を前記第二処理装置から出力する際にＸＭＬ形式で表現されていることにより、ＸＭL形式を扱うＪａｖａＳｃｒｉｐｔ（登録商標）ライブラリは多数ある為、画面描画ライブラリの実装が容易になる。
【００２７】
さらに、本発明のウェブ・コンテンツ生成システムは、ウェブ・ページ・レイアウト情報を前記第二処理装置から出力する際にＪＳＯＮ形式で表現されていることにより、ＪＳＯＮ形式を扱うＪａｖａＳｃｒｉｐｔ（登録商標）ライブラリは多数ある為、画面描画ライブラリの実装が容易になる。
【００２８】
また、本発明のウェブ・コンテンツ生成システムは、画面描画ライブラリの関数呼び出しにより、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することにより、前記ウェブ・ページ・レイアウト情報にもとづいた請求書や明細書などの印刷用のページをウェブ・コンテンツ閲覧者に提供することができる。
【００２９】
さらに、本発明のウェブ・コンテンツ生成システムは、ウェブ・ページ・レイアウト情報をウィジェットと呼ばれるウェブ部品の集合により構成することにより、ウェブ部品単位でウェブ・ページへの追加、削除、移動、コピー＆ペーストすることができ、ウェブ・コンテンツのページ・レイアウトを簡単かつ直感的に編集することができる。
【００３０】
また、本発明のウェブ・コンテンツ生成システムは、ウェブ部品にテキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、画面描画ライブラリにてプレースホルダー文字列に具体的な文字列を動的に割り当てることにより、画面描画ライブラリを通じて、プレースホルダー文字列に具体的な文字列を動的に割り当てることができる。
【００３１】
さらに、本発明のウェブ・コンテンツ生成システムは、画面描画ライブラリの関数呼び出しにより、前記プレースホルダー文字列に具体的な文字列を動的に割り当てた後、前記第二処理装置が前記ウェブ・ページ・レイアウト情報にもとづき、ＰＤＦ文書ファイルを出力することにより、前記ウェブ・ページ・レイアウト情報にもとづいた請求書や明細書などの印刷用のページに、ページ・レイアウトのデザイン時には特定できない宛名や金額など具体的な文字列や数字を書き込むことができる。
【００３２】
また、本発明のウェブ・コンテンツ生成システムは、ウェブ部品にテキスト属性を有し、そのテキストの記法により、複数のサブ部品を表現及び生成することにより、作成時、少ない労力で多数のウェブ・ページの画面要素を定義することができる。
【００３３】
さらに、本発明のウェブ・コンテンツ生成システムは、ウェブ部品及び前記サブ部品に自動的に識別名が割り振られることにより、自動的に割り振られた識別名でＤＯＭ要素を特定することでＪａｖａＳｃｒｉｐｔ（登録商標）コードから前記ＤＯＭ要素を操作することができ、ＡｊａｘやｊＱｕｅｒｙライブラリに代表されるウェブ・コンテンツの動的プログラミングに対応することができる。また、フォーム投稿型のウェブ・ページを作成した場合に、テキストボックスやチェックボックスなどのフォーム部品と、そこに入力した値や選択した結果が識別名を介して結びつく為、前記ウェブ・コンテンツ作成システムが動的に作成したウェブ・コンテンツであっても静的なＨＴＭＬ文書を記述するスタイルで開発したページと同様、ユーザーがフォームに入力した内容をサーバー側で取得することができる。
【００３４】
また、本発明のウェブ・コンテンツ生成システムは、ウェブ部品はｕｌタグを表し、サブ部品はｌｉタグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「順序なしリスト（Ｕｎｏｒｄｅｒｅｄ  Ｌｉｓｔ）」を生成・表示することができる。
【００３５】
さらに、本発明のウェブ・コンテンツ生成システムは、前記ウェブ部品はｏｌタグを表し、サブ部品はｌｉタグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「順序つきリスト（Ｏｒｄｅｒｅｄ  Ｌｉｓｔ）」を生成・表示することができる。
【００３６】
また、本発明のウェブ・コンテンツ生成システムは、前記ウェブ部品はｔａｂｌｅタグを表し、テキスト属性の各行がサブ部品のｔｒタグに、各行を区切り文字で分割した部分文字列がサブ部品のｔｈタグ、ｔｄタグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「表組み（Ｔａｂｌｅ）」を生成・表示することができる。
【００３７】
さらに、本発明のウェブ・コンテンツ生成システムは、前記ウェブ部品はｓｅｌｅｃｔタグを表し、サブ部品はｏｐｔｉｏｎタグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「ドロップ・ダウン・リスト」を生成・表示することができる。また、部分文字列の先頭が特定文字（‘＊’）であれば、その項目を選択済みとすることができる。
【００３８】
また、前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｒａｄｉｏ”＞タグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「ラジオ・ボタン選択」を生成・表示することができる。さらに部分文字列の先頭が特定文字（‘＊’）であれば、その項目を選択済みとすることができる。
【００３９】
さらに、前記サブ部品は＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｃｈｅｃｋｂｏｘ”＞タグに展開されることにより、ＨＴＭＬを記述しなくても簡単に「複数のチェックボックス」を生成・表示することができる。また、部分文字列の先頭が特定文字（‘＊’）であれば、その項目を選択済みとすることができる。
【００４０】
また、前記ウェブ部品は、複数のウィジェットをまとめて１つのウィジェットとして扱えるようにしたコンテナ・ウィジェットにすることができることにより、複数のウィジェットをまとめて削除、移動、コピー＆ペーストすることができ、複雑なウェブ・コンテンツのページ・レイアウトを簡単に編集することができる。さらに、コンテナ・ウィジェットを複数のウィジェットの相対位置を保持したまま１つの部品としてコピー＆ペーストすることで、同じデザイン・パターンを複数箇所、複数ページで使い回すことができる。
【００４１】
さらに、前記コンテナ・ウィジェットは、複数のウィジェットが１つの繰り返しパターンを形成し、コンテナ・ウィジェットの縦横サイズと、繰り返しパターンの縦横サイズを、それぞれ保持し、一定の規則に従って繰り返しパターンを複数回、複製表示することにより、１つのデザイン・パターンを一定の規則で配置したウェブ・ページを容易にデザインすることができる。
【００４２】
また、前記コンテナ・ウィジェットに含まれるウィジェットは、それぞれテキスト属性を有し、そのテキスト属性の文字列中にプレースホルダー文字列を記述でき、前記画面描画ライブラリに繰り返し回数分の連想配列の配列を渡すことで、
１つのプレースホルダー文字列に対し繰り返しパターン毎にそれぞれ異なる文字列を動的に割り当てることにより、写真の一覧表示や掲示板のような１つのデザイン・パターンが一定の規則で繰り返されたウェブ・ページにおいて、繰り返しパターン毎に異なる写真のタイトルや掲示板の書き込みテキストなどの部分を動的に切り替えて表示することができる。
【００４３】
さらに、前記コンテナ・ウィジェットは、繰り返しパターンを横方向に並べて表示し、繰り返しパターンの横幅の合計がコンテナ・ウィジェットの横幅を超える場合に次の行に改行することにより、写真の一覧表示のような１つのデザイン・パターンが横方向に繰り返し、一定の横幅に達すると縦方向に更に繰り返すウェブ・ページを容易にデザインすることができる。
【００４４】
また、前記コンテナ・ウィジェットは、繰り返しパターンを縦方向に並べて表示することにより、掲示板のような１つのデザイン・パターンが縦方向に繰り返すウェブ・ページを容易にデザインすることができる。
【図面の簡単な説明】
【００４５】
【図１】本発明のウェブ・コンテンツ生成システムのシステム構成を示す構成図
【図２】デザイナーの作業範囲を示したフローチャート
【図３】プログラマーの作業範囲を示したフローチャート
【図４】ウェブ・アプリ画面を示す説明図
【図５】ウェブ・コンテンツのＨＴＭＬコードを示す説明図
【図６】ＪＳＯＮ形式で表したウェブ・ページ・レイアウト情報を示す説明図
【図７】１つ目のウィジェット・レコードから動的に構築したＨＴＭＬ文書を示す説明図
【図８】２つ目のウィジェット・レコードから動的に構築したＨＴＭＬ文書を示す説明図
【図９】ウェブ・ページ・レイアウト情報にもとづいて表示したウェブ・コンテンツの画面を示す説明図
【図１０】コンテナ・ウィジェットを含んだウェブ・ページ・レイアウト情報を示す説明図
【図１１】コンテナ・ウィジェットを含んだウェブ・コンテンツのＨＴＭＬコードを示す説明図
【図１２】ウィジェット・レコードから動的に構築したＨＴＭＬ文書を示す説明図
【図１３】ウィジェット・レコードから動的に構築したＨＴＭＬ文書を示す説明図
【図１４】図１２及び図１３をＷｅｂブラウザ上に表示したウェブ・コンテンツの画面を示す説明図
【図１５】繰り返し描画関数によりプレースホルダー文字列の置換処理を行った結果の二次元配列の値を示す説明図
【発明を実施するための形態】
【００４６】
以下、本発明を実施するための最良の形態を、図面を参照して説明する。図１ないし図１５は、本発明の一実施例によるウェブ・コンテンツ生成システムの構成及び動作を示している。図１は、本発明のウェブ・コンテンツ生成システムのシステム構成を示す構成図である。
【００４７】
図１の如く、ウェブ・コンテンツ生成システム１は、少なくとも、第一ウェブ・サーバー装置２と、第二ウェブ・サーバー装置３と、第一端末装置４とで構成されている。
【００４８】
前記第一ウェブ・サーバー装置２は、ＨＴＴＰ／ＨＴＴＰＳプロトコルを通じてリクエストを処理する第一処理装置５を搭載している。前記第一処理装置５は、リアルタイム・ウェブ・アプリケーションを実現する為に、双方向通信が可能なＷｅｂＳｏｃｋｅｔプロトコルを処理する能力を有している。この第一ウェブ・サーバー装置２は、ページ・レイアウトを編集するウェブ・アプリケーション（ウェブ・アプリ）を提供するものである。このウェブ・アプリのシステムにより、ウェブ・コンテンツにおけるウェブ・ページのレイアウトを、ディスプレイ画面で見たものがそのまま印刷物やＨＴＭＬ文書として出力できる、所謂、ＷＹＳＩＷＹＧ編集することができる。
【００４９】
前記第二ウェブ・サーバー装置３は、第二処理装置６と、ウェブ・ページ・レイアウト・データベース７と、ハードディスク等の記憶装置８とで構成される。前記第二処理装置６は、ＨＴＴＰ／ＨＴＴＰＳプロトコルを通じてリクエストに応答しＨＴＭＬ文書を送信する。前記ウェブ・ページ・レイアウト・データベース７は、ウェブ画面のレイアウトを定義する。
【００５０】
前記記憶装置８には、画面描画ライブラリ９が保存されている。前記画面描画ライブラリ９は、ウェブ・ページ全てに組み込まれる共通のライブラリとしている。なお、本実施の形態では、前記画面描画ライブラリ９は、前記第二ウェブ・サーバー装置３に保存されているが、これに限るものではなく、後述する第三ウェブ・サーバー装置２００に保存されていても良いし、図示しない独立したウェブ・サーバーに保存されていても良い。
【００５１】
前記第二処理装置６は、Ｗｅｂ  ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）によるリクエストを処理し、ウェブ・ページ・レイアウト情報１０を配信する。なお、本実施の形態では、ウェブ・ページ・レイアウト・データベース７は、第二ウェブ・サーバー装置３に含まれているが、第一ウェブ・サーバー装置２にあっても良いし、両ウェブ・サーバー装置２，３とは独立した図示しないデータベース・サーバーとして存在していても良い。
【００５２】
前記第一端末装置４は、ウェブ・コンテンツを閲覧する一般ユーザーが使用する端末装置であり、Ｗｅｂブラウザ１１を起動できるパソコン、タブレットＰＣ、スマートフォン等の任意の端末装置である。前記Ｗｅｂブラウザ１１は、図１の仮想線で示される如く、前記第二処理装置６に前記画面描画ライブラリ９をリクエストし、あらかじめ画面描画ライブラリ９を取得しておく。そして、実行可能な状態となった前記画面描画ライブラリ９の描画関数を呼び出すことにより、前記ウェブ・ページ・レイアウト・データベース７に格納された前記ウェブ・ページ・レイアウト情報１０にもとづいてページ・レイアウトを再現し、ウェブ・コンテンツを表示する。前記第一端末装置４は、インターネット等を通じて、前記第二ウェブ・サーバー装置３及び後述する第三ウェブ・サーバー装置２００にアクセスする。
【００５３】
第二端末装置１００は、ウェブ・ページをレイアウト編集する際にこれらをデザインするデザイナーが使用する端末装置である。前記第二端末装置１００は、Ｗｅｂブラウザ１０１を起動できるパソコン、タブレットＰＣ、スマートフォン等の任意の端末装置である。
【００５４】
第三ウェブ・サーバー装置２００は、第三処理装置２０１と、プロプライエタリ・データベース２０２とを搭載している。前記第三処理装置２０１は、ＨＴＴＰ／ＨＴＴＰＳプロトコルを通じてリクエストに応答しＨＴＭＬ文書や画像ファイルを出力する。前記プロプライエタリ・データベース２０２は、非公開情報等を管理している。前記第三ウェブ・サーバー装置２００は、本発明のウェブ・コンテンツ生成システム１を利用するウェブ・コンテンツ開発者（プログラマー）が、本発明のシステムとは独立して設計・実装・管理するサーバー装置である。
【００５５】
次に、本発明のウェブ・コンテンツ生成システム１によるウェブ・コンテンツの生成方法について説明をする。図２は、本発明のウェブ・コンテンツ生成システム１によるウェブ・コンテンツの生成方法を示したフローチャートの一部であり、デザイナーの作業範囲を示している。図３は、本発明のウェブ・コンテンツ生成システム１によるウェブ・コンテンツの生成方法を示したフローチャートの一部であり、プログラマーの作業範囲を示している。
【００５６】
ウェブ・コンテンツを生成する際には、表示画面をデザインするデザイナーと、この表示画面についてＪａｖａＳｃｒｉｐｔ（登録商標）言語やサーバーサイド・スクリプト言語等を用いてプログラミングするプログラマーが分業体制で生成している場合が一般的である。
【００５７】
まず、Ｓｔｅｐ１ないしＳｔｅｐ６のデザイナーの作業範囲について図２を参照しながら説明する。
Ｓｔｅｐ１  前記第二端末装置１００で前記Ｗｅｂブラウザ１０１を立ち上げ、そして該Ｗｅｂブラウザ１０１に前記第一ウェブ・サーバー装置２のウェブ・ページのアドレスを入力する。前記Ｗｅｂブラウザ１０１は、入力されたアドレスに従い、前記第一ウェブ・サーバー装置２にアクセスし、ウェブ・アプリを記述したＨＴＭＬ文書を前記第一処理装置５にリクエストする。
【００５８】
Ｓｔｅｐ２  前記第一処理装置５は、リクエストされたＨＴＭＬ文書を前記Ｗｅｂブラウザ１０１に送信する。
【００５９】
Ｓｔｅｐ３  前記Ｗｅｂブラウザ１０１はＨＴＭＬ文書を解釈し、そこから外部参照された図示しない画像ファイル、スタイルシート及びスクリプトファイルを追加リクエストする。それらリクエストに対しても前記第一処理装置５は応答し、要求されたファイルを前記Ｗｅｂブラウザ１０１に送信する。前記Ｗｅｂブラウザ１０１は、このようにして取得したＨＴＭＬ文書、スタイルシートで指定された画面デザインを描画し、スクリプトコードを実行して、ウェブ・アプリを前記第二端末装置１００の画面上に表示する。ウェブ・アプリの画面は図４に示す。なお、本実施の形態では、ウェブ・アプリはウェブ・アプリケーションとして実装されているが、前記第二端末装置１００の専用アプリケーションとして提供することも可能である。
【００６０】
Ｓｔｅｐ４  デザイナーはウェブ・アプリを操作し、目的のウェブ・コンテンツのページ・レイアウトを編集する。このウェブ・ページのレイアウト編集の手順を図４にもとづいて、説明する。ウェブ・ページ編集画面は大きく分けて、編集対象となっているウェブ・ページ２０、ウィジェット・ツールボックス２１、ウィジェット属性編集ツールバー２２から構成されている。
【００６１】
前記ウィジェット・ツールボックス２１は、前記ウェブ・ページ２０をデザインする際の部品となるウィジェットアイコン２３（ウェブ部品）が多数並んでいる。デザイナーは前記ウィジェットアイコン２３をドラッグ＆ドロップ操作により、前記ウェブ・ページ２０に追加することができる。ウェブ・ページ２０に追加したウィジェット２４は、ドラッグによりページ内の位置を移動することができる。
【００６２】
また、前記ウィジット２４をクリックすることにより選択して、掴んで操作できるオブジェクトであるハンドル２５を表示し、ハンドル操作で前記ウィジェット２４の大きさや形を変形することができる。前記ウィジェット２４をダブル・クリックすることによりテキスト編集ダイアログ２６を表示し、テキスト属性を編集することができる。前記ウィジェット２４のテキスト属性を変更すると、ウィジェット２４のキャプションなど見た目が変化する。さらに、選択中のウィジェット２４は、前記ウィジェット属性編集ツールバー２２により、ウィジェット２４の文字色、背景色、線幅、ハイパーリンクのリンク先など、様々な属性値を編集することができる。
【００６３】
図２のフローチャートを参照しながら、作業工程の説明に戻る。
Ｓｔｅｐ５  本実施の形態のウェブ・アプリの起動中は、前記Ｗｅｂブラウザ１０１と前記第一処理装置５との間はＷｅｂＳｏｃｋｅｔプロトコルによりリアルタイムな双方向通信が可能な状態になっている。上述のウェブ・ページの編集操作を実行すると、その都度リアルタイムに前記Ｗｅｂブラウザ１０１は前記第一処理装置５に編集内容を通知（更新：図１参照）する。
【００６４】
Ｓｔｅｐ６  前記第一処理装置５は、編集内容からウェブ・ページやウィジェットのレコードを更新し、前記ウェブ・ページ・レイアウト・データベース７に書き込む。該ウェブ・ページ・レイアウト・データベース７への書き込みに時間がかかる場合は、タイマー割り込みを利用し、１０秒に１回書き込みをおこなうようにしたりして頻度を軽減する。このような手順により、ウェブ・コンテンツのウェブ・ページ・レイアウト情報１０が前記ウェブ・ページ・レイアウト・データベース７に格納（保存）された状態になる。
【００６５】
次に、あらかじめ編集されたウェブ・ページ・レイアウト情報１０を元に、前記ウェブ・コンテンツ生成システム１が、ウェブ・コンテンツを表示するまでの流れ、すなわち、Ｓｔｅｐ７ないしＳｔｅｐ１７のプログラマーの作業範囲について図３を参照しながら説明する。
【００６６】
Ｓｔｅｐ７  プログラマーが、前記画面描画ライブラリ９を利用するスクリプトを記述したＨＴＭＬ文書を作成する。
【００６７】
図５に、前記ウェブ・コンテンツ生成システム１により、ウェブ・コンテンツを実際に表示するＨＴＭＬコードを例示する。なお、このＨＴＭＬコードは、ＨＴＭＬ５仕様書に準拠した記述になっている。また、図５における説明は、ＨＴＭＬコードのうち、本発明に関連する部分のみとする。
【００６８】
図５の０６行目は、ｊＱｕｅｒｙライブラリを読み込んでいる。ｊＱｕｅｒｙは、ＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ
Ｍｏｄｅｌ）操作を簡単にするＪａｖａＳｃｒｉｐｔ（登録商標）言語で記述されたライブラリである。０７行目は、前記画面描画ライブラリ９を読み込んでいる。１１ないし１６行目は、ｊＱｕｅｒｙライブラリの機能を使い、ＤＯＭがロードされ操作、解析が可能になったタイミングで呼び出される関数を定義している。ＨＴＭＬ５においては、言語指定であるｔｙｐｅ属性を省略したｓｃｒｉｐｔタグは、暗黙的にＪａｖａＳｃｒｉｐｔ（登録商標）コードと解釈される。
【００６９】
１２行目の“ｕｘ”は、前記画面描画ライブラリ９の関数群を定義した名前空間となるオブジェクトである。１２ないし１５行目の“ｕｘ．ｒｅｎｄｅｒ（）”は、前記画面描画ライブラリ９が提供するウェブ・コンテンツを生成、表示する関数である。１３行目は、描画関数ｕｘ．ｒｅｎｄｅｒの第１引数。保存された前記ウェブ・ページ・レイアウト情報１０から、どのウェブ・ページを表示するかを指定している。ここではｐｕｂｌｉｓｈ＿ｉｄとｐａｇｅ＿ｉｄの組で一意にウェブ・ページを特定している。
【００７０】
１４行目は、描画関数ｕｘ．ｒｅｎｄｅｒの第２引数。プレースホルダー文字列と置き換えて表示する文字列を指定している。図５で示したように、従来のＨＴＭＬ文書で必要だった画面デザインの為のＨＴＭＬタグやスタイル定義の記述の大部分が不要となる。プログラマーは、このようなＨＴＭＬ文書を作成し、前記第三ウェブ・サーバー装置２００の図示しないハードディスク等所定のコンテンツ・フォルダに格納する。
【００７１】
図３のフローチャートを参照しながら、作業工程の説明に戻る。
Ｓｔｅｐ８  ウェブ・コンテンツのページを開く。Ｓｔｅｐ７で作成したＨＴＭＬ文書で表現されるウェブ・コンテンツを閲覧したい一般ユーザーは、自身が所有する前記第一端末装置４にて前記Ｗｅｂブラウザ１１を起動し、そのウェブ・コンテンツのアドレスを前記Ｗｅｂブラウザ１１に入力する。すると前記Ｗｅｂブラウザ１１は、前記第三処理装置２０１に対し当該ＨＴＭＬ文書を送信するようリクエストを送信（図１参照）する。
【００７２】
Ｓｔｅｐ９  ＨＴＭＬ文書を送信する。リクエストを受け取った前記第三処理装置２０１は、所定のコンテンツ・フォルダから当該ＨＴＭＬ文書を読み込み、前記Ｗｅｂブラウザ１１からのリクエストの応答として、Ｗｅｂブラウザ１１にＨＴＭＬ文書を送信（図１参照）する。
【００７３】
Ｓｔｅｐ１０  ＨＴＭＬ文書を解釈する。前記第三処理装置２０１からＨＴＭＬ文書を受信したＷｅｂブラウザ１１は、字句解析器であるＨＴＭＬパーサーによりＨＴＭＬ文書の中身を解釈する。
【００７４】
Ｓｔｅｐ１１  前記画面描画ライブラリ９を要求する。ＨＴＭＬ文書を解釈した結果、図５のＨＴＭＬコードの０６行目及び０７行目のような外部ファイルの参照を発見した場合、その外部ファイルをアドレスに指定されたサーバー装置に要求する。特に、このウェブ・コンテンツ生成システム１を利用するＨＴＭＬ文書の場合、外部ファイルとして前記画面描画ライブラリ９が必要になる。図５のＨＴＭＬコードの０７行目に、前記画面描画ライブラリ９を読み込み要求するｓｃｒｉｐｔタグの例を示す。ＨＴＭＬパーサーにより、この０７行目の記述を発見した前記Ｗｅｂブラウザ１１は、前記第二処理装置６に対し、前記画面描画ライブラリ９のスクリプトファイルを送信するようにリクエスト（図１参照）する。
【００７５】
Ｓｔｅｐ１２  前記画面描画ライブラリ９を送信（図１参照）する。前記画面描画ライブラリ９のファイルを送信するようリクエストされた前記第二処理装置６は、前記記憶装置８の所定のコンテンツ・フォルダに格納された前記画面描画ライブラリ９のファイルを、リクエストに対する応答として、前記Ｗｅｂブラウザ１１に送信する。本実施の形態では、前記画面描画ライブラリ９が第二ウェブ・サーバー装置３に保存された状態にした例を示したが、前記第三ウェブ・サーバー装置２００に保存して、前記第三処理装置２０１が送信する実装でもよい。あるいはコンテンツデリバリネットワーク（Ｃｏｎｔｅｎｔｓ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋ：ＣＤＮ）にて配信する形でも良い。ＣＤＮを利用すれば、前記第二ウェブ・サーバー装置３または前記第三ウェブ・サーバー装置２００への送信リクエストが減少し、サーバー装置の処理負荷が軽減する。
【００７６】
前記画面描画ライブラリ９は、前記ウェブ・コンテンツ生成システム１を利用するウェブ・ページ全てに組み込まれる共通のライブラリとして利用される。こうした場合、前記画面描画ライブラリ９の送信時の応答メッセージ中に含まれるファイルのキャッシュ寿命を１年間あるいはそれ以上に設定しておけば、ウェブ・コンテンツのページを開く度に前記画面描画ライブラリ９の送信リクエストが発生することがなくなり、画面描画完了までの時間を短縮することができる。こうした工夫は、送信リクエストを受けるサーバー装置の処理負荷を軽減するのに役立つ。
【００７７】
Ｓｔｅｐ１３  スクリプトを解釈する。ＨＴＭＬパーサーは、ｓｃｒｉｐｔタグに囲まれたＪａｖａＳｃｒｉｐｔ（登録商標）コードを発見すると、ＪａｖａＳｃｒｉｐｔ（登録商標）スクリプトエンジンにＪａｖａＳｃｒｉｐｔ（登録商標）コードの文字列を渡し、ＪａｖａＳｃｒｉｐｔ（登録商標）コードの文字列をプログラムとして解釈、実行する。ｓｃｒｉｐｔタグにより外部から読み込まれたスクリプトも同様に、ＪａｖａＳｃｒｉｐｔ（登録商標）スクリプトエンジンがプログラムとして解釈、実行する。そして外部ファイルの読み込みが終わり、ＤＯＭ操作ができる状態になると、ｊＱｕｅｒｙライブラリの機能により、図５の１１ないし１６行目のスクリプトが実行される。なお、ＤＯＭとは、ＪａｖａＳｃｒｉｐｔ（登録商標）コードからＨＴＭＬ文書のドキュメント構造を参照、変更する為のオブジェクトモデル及びＡＰＩである。
【００７８】
Ｓｔｅｐ１４  スクリプトが前記画面描画ライブラリ９のページ描画関数を呼び出す。図５の１２ないし１５行目は、前記画面描画ライブラリ９の描画関数ｕｘ．ｒｅｎｄｅｒを呼び出すＪａｖａＳｃｒｉｐｔ（登録商標）コードである。描画関数ｕｘ．ｒｅｎｄｅｒは、次のような動作をする。ａ）Ｗｅｂ  ＡＰＩを呼び出し、前記ウェブ・ページ・レイアウト情報１０を取得する。ｂ）前記ウェブ・ページ・レイアウト情報１０にもとづき、ＤＯＭを構築する。
【００７９】
まず、ａ）Ｗｅｂ  ＡＰＩを呼び出し、前記ウェブ・ページ・レイアウト情報１０を取得する動作を説明する。
Ｓｔｅｐ１５  ウェブ・ページ・レイアウト情報１０を要求する。関数の第１引数である｛ｐｕｂｌｉｓｈ＿ｉｄ：“１００１”，ｐａｇｅ＿ｉｄ：“１”
｝で特定されるウェブ・ページのウェブ・ページ・レイアウト情報１０を取得するには、まず、ウェブ・ページ・レイアウト情報１０を取得するＷｅｂ  ＡＰＩの要求先ＵＲＬを求める。この場合、ｈｔｔｐ：／／ａｐｉ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｇｅ＿ｌａｙｏｕｔ？ｐｕｂｉｓｈ＿ｉｄ＝１００１＆ｐａｇｅ＿ｉｄ＝１となる。ＨＴＴＰプロトコルのＧＥＴ要求を上記アドレス宛にリクエストする。
【００８０】
“ａｐｉ．ｅｘａｍｐｌｅ．ｃｏｍ”は、本実施の形態における前記第二ウェブ・サーバー装置３のドメイン名である。“／ｐａｇｅ＿ｌａｙｏｕｔ”は、前記第二ウェブ・サーバー装置３におけるウェブ・ページ・レイアウト情報１０を取得するＷｅｂ  ＡＰＩのエントリーポイントとなるパス名である。なお、Ｗｅｂ  ＡＰＩのドメイン名及びパスは実装パラメーターであり、自由に命名すれば良い。
【００８１】
Ｓｔｅｐ１６  ウェブ・ページ・レイアウト情報１０を送信（図１参照）する。第二処理装置６は、ウェブ・ページ・レイアウト情報１０を取得するＷｅｂ  ＡＰＩのエントリーポイントのパス名に対しＧＥＴ要求があると、ＵＲＬのクエリ部分“？ｐｕｂｌｉｓｈ＿ｉｄ＝１００１＆ｐａｇｅ＿ｉｄ＝１”を取り出す。クエリ部分の解析により、このＧＥＴ要求は、パブリッシュＩＤ＝１００１、ページＩＤ＝１のウェブ・ページに対応するウェブ・ページ・レイアウト情報１０を要求してきていることが判明する。
【００８２】
前記第二処理装置６は、パブリッシュＩＤ＝１００１、ページＩＤ＝１を検索条件にして、前記ウェブ・ページ・レイアウトデータベース７に問い合わせをする。この問い合わせに対し、前記ウェブ・ページ・レイアウトデータベース７は、該ウェブ・ページのウィジェット・レコードのリストを結果として返す。前記第二処理装置６は、前記ウェブ・ページ・レイアウトデータベース７から取得したウィジェット・レコードのリストを、ＪＳＯＮあるいはＸＭＬ形式に変換し、ＧＥＴ要求の応答として送信（図１参照）する。
【００８３】
ＵＲＬのクエリ部分が“？ｐｕｂｌｉｓｈ＿ｉｄ＝１００１＆ｐａｇｅ＿ｉｄ＝１＆ｃａｌｌｂａｃｋ＝ｃｂ”とｃａｌｌｂａｃｋ関数名（この場合“ｃｂ”）の指定があればＪＳＯＮＰ形式の応答となり、ＪＳＯＮ形式に変換したウィジェット・レコードのリストの前後に、更にｃａｌｌｂａｃｋ関数の呼び出しコード“ｃｂ（”と“）；”をつけて応答とする。
【００８４】
次に、ｂ）ウェブ・ページ・レイアウト情報１０にもとづき、ＤＯＭを構築する動作を説明する。
Ｓｔｅｐ１７  ウェブ・ページ・レイアウト情報１０から画面を生成、表示する。描画関数ｕｘ．ｒｅｎｄｅｒは、Ｗｅｂ  ＡＰＩから取得したウェブ・ページ・レイアウト情報１０にもとづき、以下の手順で画面を生成、表示する。取得したＪＳＯＮ形式で表したウェブ・ページ・レイアウト情報１０を図６に例示する。ウェブ・ページ・レイアウト情報１０は、ウィジェット・レコードのリスト（配列）である。図６で例示した配列には、２つのウィジェット・レコード（ウィジェットの属性情報）が含まれる。
【００８５】
図６の０２ないし０４行目は、１つ目のウィジェット・レコードである。テキスト型のウィジェットである。０５ないし０７行目は、２つ目のウィジェット・レコードである。チェックリスト型のウィジェットである。０７行目で、“ｂａｃｋｇｒｏｕｎｄ−ｃｏｌｏｒ”：“”と空文字列を指定しているのは、背景色を透明にする指定である。全て“属性名（ｋｅｙ）”：“属性値（ｖａｌｕｅ）”という形式で、属性が定義してある。
【００８６】
ちなみに、属性名の説明を以下にする。“ｔｙｐｅ”：は、ウィジェットの種別名である。“ｔｅｘｔ”：は、テキスト属性である。“ｌｅｆｔ”：は、左端のＸ座標である。“ｔｏｐ”：は、上端のＹ座標である。“ｗｉｄｔｈ”：は、横幅である。“ｈｅｉｇｈｔ”：は、高さである。“ｃｏｌｏｒ”：は、描画色である。“ｂａｃｋｇｒｏｕｎｄ−ｃｏｌｏｒ”：は、背景色である。“ｆｏｎｔ−ｓｉｚｅ”：は、文字の大きさである。
【００８７】
数字の単位はｐｘ（ピクセル）である。色はハッシュ（＃）に続く３桁または６桁の１６進カラーコード文字列で表現する。色の属性値が空文字列（“”）である場合は、透明色を示す。１つ目のウィジェット・レコードのテキスト属性の属性値は、プレースホルダー文字列を含んでいるので、プレースホルダー文字列の置換処理を行う必要がある。
【００８８】
描画関数ｕｘ．ｒｅｎｄｅｒは、取得した前記ページ・レイアウト情報１０のウィジェット・レコード各々に対して、そのウィジェットを画面に表示するのに必要なＤＯＭ要素を生成し、ＤＯＭに追加する。ここでは１つ目のウィジェットを例にとり、描画関数ｕｘ．ｒｅｎｄｅｒがウィジェット・レコード（図６の０２ないし０３行目）からＤＯＭ要素を生成、追加する過程を、図７を参照し説明する。前記画面描画ライブラリ９ではウィジェット種別毎に、そのウィジェットを表示する為のＤＯＭ要素の生成手順をそれぞれ定義してある。
【００８９】
まず、ウィジェット・レコードからウィジェット種別名(この場合“ｔｅｘｔ”：図６の０２行目、ｔｙｐｅ＝“ｔｅｘｔ”参照)を取得し、テキスト型のウィジェットであることが判明する。テキスト型のウィジェットでは、追加するＤＯＭ要素はｄｉｖタグで、そのコンテンツ部分はテキスト属性そのものだと定義してある。テキスト属性（“ｔｅｘｔ”）はこの場合、“こんにちは、＄｛ｎａｍｅ｝さん！”である。テキスト属性にはプレースホルダー文字列が含まれている可能性がある為、後述するプレースホルダー文字列の置換処理を行う。その結果、最終的なテキスト属性は“こんにちは、加藤さん！”となる。このテキスト属性をｄｉｖタグのコンテンツ部分に挿入する。また、１番目のテキスト型のウィジェットであることから、ｄｉｖタグの識別名（ｉｄ）は“ｔｅｘｔ＿１”となる。ここまでの手順で生成された追加すべきＤＯＭ要素は、＜ｄｉｖ  ｉｄ＝“ｔｅｘｔ＿１”＞こんにちは、加藤さん！＜／ｄｉｖ＞となる。
【００９０】
次に、ウィジェット・レコードの残りの属性から、ｄｉｖタグのｓｔｙｌｅ属性、すなわち描画関数ｕｘ．ｒｅｎｄｅｒが追加するＤＯＭ要素のスタイル（表示スタイル、表示の仕方）を定義する手順を説明する。スタイルもウィジェット・レコード同様、属性名と属性値の組から構成されている。ＨＴＭＬコード上ではｓｔｙｌｅ＝“属性名: 属性値；”と表記される。“ｌｅｆｔ”，“ｔｏｐ”，“ｗｉｄｔｈ”，“ｈｅｉｇｈｔ”，“ｆｏｎｔ−ｓｉｚｅ”の単位は“ｐｘ”（ピクセル）なので、各属性値の後ろに文字列“ｐｘ”を連結する。色属性を表す“ｃｏｌｏｒ”，“ｂａｃｋｇｒｏｕｎｄ−ｃｏｌｏｒ”は、そのまま属性値として採用する。それからウィジェットを自由な位置に配置する為に必要な“ｐｏｓｉｔｉｏｎ：ａｂｓｏｌｕｔｅ；”をスタイルに追加する。このスタイルは、親要素の左上隅を基準とした位置に、そのＤＯＭ要素を配置することを指示する。
【００９１】
こうして出来たＤＯＭ要素（ｄｉｖタグ）をＨＴＭＬコードで表記したものが、図７となる。描画関数ｕｘ．ｒｅｎｄｅｒが、このｄｉｖタグをＨＴＭＬ本文（ｂｏｄｙタグ）の下に追加すると、指定された位置にｄｉｖタグで表された矩形と「こんにちは、加藤さん！」という文字が前記Ｗｅｂブラウザ１１の画面に登場する（図９参照）。
【００９２】
次に、１つ目のウィジェット・レコードを例にしてプレースホルダー文字列の置換処理について、説明をする。正規表現エンジンを用いて、ウィジェット・レコードのテキスト属性（この場合“こんにちは、＄｛ｎａｍｅ｝さん！”：図６の０２行目参照）からプレースホルダー開始記号“＄｛“とプレースホルダー終了記号”｝”に囲まれた部分文字列を検索する。検索した部分文字列のうち、プレースホルダー開始記号“＄｛”とプレースホルダー終了記号“｝”を含んだ部分文字列をプレースホルダー文字列と呼ぶ。例：“＄｛ｎａｍｅ｝”。プレースホルダー開始記号“＄｛”とプレースホルダー終了記号“｝”を含まない部分文字列をプレースホルダー名と呼ぶ。例：“ｎａｍｅ”。これらは正規表現エンジンを利用すれば、検索結果として同時に取得できる。
【００９３】
次に、見つかったプレースホルダー文字列各々に対し、その置換文字列を算出する。すなわち、描画関数ｕｘ．ｒｅｎｄｅｒの第２引数として渡されたプレースホルダー連想配列を用いて、プレースホルダー名をキーにして、前記プレースホルダー連想配列から値を取得し、それを置換文字列とする。なお、連想配列とは、“ｄｏｇ”を“犬”などキーから値の組み合わせを記憶する辞書型のデータ構造である。キーを指定して値を設定、取得することができる。その置換文字列をプレースホルダー文字列があった部分と置換した結果が、テキスト属性にプレースホルダー処理を施した文字列（この場合“こんにちは、加藤さん！”）となる。
【００９４】
こうした手順により、１つ目のウィジェット・レコードから動的に構築したＨＴＭＬ文書は図７になる。また同様に、２つ目のウィジェット・レコードから動的に構築したＨＴＭＬ文書は図８になるが、詳細な手順は以下に述べる。
【００９５】
次に、２つ目のチェックリスト型のウィジェットを例に、図８を参照しながらサブ部品の生成手順を説明する。
まず、第２引数｛ｎａｍｅ：“加藤”，ａｇｅ：３４｝をプレースホルダー連想配列として保存する。
【００９６】
続いて、識別名カウンタ＝｛“ｃｈｅｃｋｌｉｓｔ”：０，“ｃｈｅｃｋｂｏｘ”：０｝のように、識別名カウンタ連想配列を０（ゼロ）で初期化する。そして、Ｗｅｂ  ＡＰＩを通じて、該ウェブ・ページのウィジェット・レコードの配列Ｗｓを取得する。その際、第１引数｛ｐｕｂｌｉｓｈ＿ｉｄ：“１００１”，ｐａｇｅ＿ｉｄ：“１”｝でページを特定する。
【００９７】
続いて、配列Ｗｓの先頭から終わりまで繰り返し処理し、ウィジェット・レコードにもとづいて、ウィジェットを生成、表示する。ウィジェットのｔｙｐｅ属性（図６の０５行目、ｔｙｐｅ＝“ｃｈｅｃｋ−ｌｉｓｔ”参照）を取得する。ｔｙｐｅ属性で指定された種別のウィジェット描画処理を呼び出す。例として、チェックリスト型のウィジェット描画処理については、以下のようになる。
【００９８】
識別名カウンタ［“ｃｈｅｃｋｌｉｓｔ”］＋＝１：カウンタのインクリメント処理。識別名（ｉｄ）＝“ｃｈｅｃｋｌｉｓｔ＿”＋識別名カウンタ［“ｃｈｅｃｋｌｉｓｔ”］すなわち、ｉｄ＝“ｃｈｅｃｋｌｉｓｔ＿１”となる。テキスト属性以外の属性からｄｉｖタグ８０１（図８の０１ないし０３行目参照）を生成し、ｂｏｄｙタグの下に子要素として追加する。テキスト属性の値を取得し、文字列Ａとする。文字列Ａにプレースホルダー処理を施す。すなわち、文字列Ａを更新する。文字列Ａを“，”で分割する。すなわち、部分文字列Ｂの配列となる。この例では“りんご，＊みかん，ぶどう”が [“りんご”，“＊みかん”，“ぶどう” ]となる。
【００９９】
そして、分割された部分文字列Ｂ各々に対し繰り返し処理して、サブ部品を生成する。部分文字列Bの先頭が“＊”であるかを確認する。｛Ｙｅｓ｝ならｃｈｅｃｋｅｄ＝ｔｒｕｅとし、部分文字列Ｂから先頭の“＊”を取り除き、部分文字列Ｃとする。｛Ｎｏ｝ならｃｈｅｃｋｅｄ＝ｆａｌｓｅとし、部分文字列Ｂを部分文字列Ｃとする。部分文字列Ｃを、チェックボックスのラベル文字列（りんご、みかん、ぶどう）とする。
【０１００】
識別名カウンタ［“ｃｈｅｃｋｂｏｘ”］＋＝１：カウンタのインクリメント処理をする。識別名（ｉｄ）＝“ｃｈｅｃｋｂｏｘ＿”＋識別名カウンタ［“ｃｈｅｃｋｂｏｘ”］すなわち、ｉｄ＝“ｃｈｅｃｋｂｏｘ＿１”，“ｃｈｅｃｋｂｏｘ＿２”，“ｃｈｅｃｋｂｏｘ＿３”となる。サブ部品のＤＯＭ要素：＜ｉｎｐｕｔ  ｔｙｐｅ＝“ｃｈｅｃｋｂｏｘ”＞タグ（図８の０４，０６，０８行目参照）を生成し、ｄｉｖタグ８０１の下に子要素として追加する。部分文字列Ｃからｌａｂｅｌタグ（図８の０５、０７、０９行目参照）を生成し、ｄｉｖタグ８０１の下に子要素として追加する。
【０１０１】
２つのウィジェットの座標が重なったときは、後続するウィジェットを手前に表示する。ＨＴＭＬ文書においても、より後ろに記述したＤＯＭ要素が手前に表示されるルールの為、配列の順番通りにＨＴＭＬ文書の本文（ｂｏｄｙタグ）直下にウィジェットに対応するＤＯＭ要素を追加していけば良い。このように構築されたウェブ・コンテンツの画面が図９となる。なお、図中に記載されているチェックリストの周りの破線は、実際には表示されない。
【０１０２】
次に、繰り返し表示を含んだウェブ・コンテンツを例に、コンテナ・ウィジェットを描画する手順を説明する。コンテナ・ウィジェットを含んだウェブ・コンテンツのウェブ・ページ・レイアウト情報１０を図１０に例示する。このウェブ・ページは、大きく２つのウィジェットにより構成されている。図１０の０２ないし０３行目が、１つ目のウィジェットの属性情報である。これはテキスト型のウィジェットであり、「書籍一覧」というページ見出しを表現している。
【０１０３】
図１０の０４ないし１７行目が、２つ目のウィジェットの属性情報である。これはタイル型のウィジェットで、１つのデザイン・パターン（繰り返しパターン）を横方向に繰り返し表示するタイプのコンテナ・ウィジェットである。この例ではタイル型のコンテナ・ウィジェットにより、書籍情報の一覧表示を実現しようとしている。
【０１０４】
次に、コンテナ・ウィジェットを定義する属性の詳細を説明する。図１０に示す０４ないし０５行目では、コンテナ・ウィジェットの表示位置（“ｌｅｆｔ”，“ｔｏｐ”）、縦横サイズ（“ｗｉｄｔｈ”，“ｈｅｉｇｈｔ”）、背景色（“ｂａｃｋｇｒｏｕｎｄ−ｃｏｌｏｒ”）を保持する。そして、０６ないし１６行目の“ｐａｔｔｅｒｎ”キーで示されるサブ・ドキュメントでは繰り返しパターンを定義している。さらに、０７行目のように繰り返しパターン自身もコンテナ・ウィジェットのものとは別に縦横サイズ（“ｗｉｄｔｈ”，“ｈｅｉｇｈｔ”）を保持する。“ｐａｔｔｅｒｎ”サブ・ドキュメントの“ｗｉｄｇｅｔｓ”キーでは、繰り返しパターン内部のレイアウト情報を表すウィジェット・レコードを保持している。コンテナ・ウィジェットでは再帰的なレイアウト構造を保持する。
【０１０５】
この繰り返しパターンには、３つのウィジェット・レコードが含まれている。０９ないし１０行目は、テキスト型の１つ目のサブ・ウィジェットの属性情報である。書籍のタイトルを差し込めるようにプレースホルダー文字列を含んでいる。１１ないし１２行目も、テキスト型の２つ目のサブ・ウィジェットの属性情報である。書籍の価格を差し込めるようにプレースホルダー文字列を含んでいる。１３ないし１４行目は、３つ目のサブ・ウィジェットの属性情報である。スター型のウィジェットである。
【０１０６】
スター型のウィジェットとは、評価値などを表す星マーク（★）を表示する為のウィジェットである。テキスト属性に例えば“３／５”を設定すると、全部で５つの星のうち、３つを獲得した状態を表す。すなわち“★★★☆☆”となる。例示したウィジェット・レコードでは、分子の星の数を、プレースホルダー文字列を利用して可変にしている。繰り返しパターン内部のサブ・ウィジェットが保持している表示位置（“ｌｅｆｔ”，“ｔｏｐ”）（図１０の１０、１２、１４行目）は、コンテナ・ウィジェットないし繰り返しパターンの左上隅からの相対位置を表す。なお、このような階層構造を持つドキュメント・データを格納するには、リレーショナルデータベースよりＣｏｕｃｈＤＢやＭｏｎｇｏＤＢに代表されるドキュメント指向データベースの方が適している。
【０１０７】
図１１は、前述した図１０の前記ウェブ・ページ・レイアウト情報１０を読み込んで、ウェブ・コンテンツを表示するＨＴＭＬコードである。以下、ＪａｖａＳｃｒｉｐｔ（登録商標）コードの部分を説明する。図５と同様、図１１の１２行目で描画関数ｕｘ．ｒｅｎｄｅｒを呼び出す。関数の第１引数である｛ｐｕｂｌｉｓｈ＿ｉｄ：“１００１”，ｐａｇｅ＿ｉｄ：“２”｝にて、図１０のウェブ・ページ・レイアウト情報１０を特定している。なお、第２引数のプレースホルダー文字列の為の連想配列は不要なので省略する。
【０１０８】
図１１の１３ないし１９行目では、繰り返し描画関数ｕｘ．ｒｅｐｅａｔを呼び出す。１３行目：関数の第１引数である“ｔｉｌｅ＿１”で、どのウィジェットを繰り返し描画するか指定する。この場合、２番目のウィジェットであるタイル型のコンテナ・ウィジェットを指し示す。この“ｔｉｌｅ＿１”という識別名は、前記ウェブ・コンテンツ生成システム１により自動的に付けられたものである。
【０１０９】
図１１の１４ないし１９行目は関数の第２引数である連想配列の配列である。配列には４つの要素が格納されている。これにより、コンテナ・ウィジェットが保持する繰り返しパターンを４回複製し、表示することを指示している。この例では、繰り返しパターン内部のサブ・ウィジェットにプレースホルダー文字列を含む為、連想配列の配列を第２引数としたが、プレースホルダー文字列を一切含まない場合、繰り返し表示する回数を整数値で指示すれば良い。また、この繰り返し回数を示す第２引数の内容は、ページ・レイアウトのデザイン時にコンテナ・ウィジェットのテキスト属性として指定しておくことも可能である。その場合には、繰り返し描画関数ｕｘ．ｒｅｐｅａｔの呼び出しは不要となる。
【０１１０】
次に、繰り返し描画関数ｕｘ．ｒｅｐｅａｔで繰り返し表示を実現する手順を説明する。まず、第１引数の識別名からコンテナ・ウィジェットに対応するＤＯＭ要素“ｔｉｌｅ＿１”を検索する。見つかったＤＯＭ要素“ｔｉｌｅ＿１”から子要素ｌｉタグを全て削除し、図１２の０３ないし０５行目で示されるｕｌタグだけの状態に戻す。ｕｌタグのｓｔｙｌｅ属性は描画関数ｕｘ．ｒｅｎｄｅｒを呼び出した際に、前記ウェブ・ページ・レイアウト情報１０のコンテナ・ウィジェットの属性（図１０の０４ないし０５行目）から生成したものである。
【０１１１】
コンテナ・ウィジェットの繰り返しパターンから、子要素ｌｉタグを再構築する。コンテナ・ウィジェットのｐａｔｔｅｒｎ属性に格納されている繰り返しパターンを取り出す。繰り返しパターンの属性から、ひな形となるｌｉタグを生成する。ｌｉタグのｓｔｙｌｅ属性は繰り返しパターンの属性（図１０の０７行目）から生成する（図１２の０７、１６行目及び図１３の２５、３４行目）。加えて、横方向に並べて表示するタイル型のコンテナ・ウィジェットを実現する為、ｓｔｙｌｅ属性に“ｄｉｓｐｌａｙ：ｉｎｌｉｎｅ−ｂｌｏｃｋ；”を指定する（図１２の０６、１５行目及び図１３の２４、３３行目）。“ｄｉｓｐｌａｙ：ｉｎｌｉｎｅ−ｂｌｏｃｋ；”を省略した場合、縦方向に並べて表示するスタック型のコンテナ・ウィジェットを実現できる。
【０１１２】
次に、ひな形のｌｉタグの下に繰り返しパターンのウィジェット・レコードから、サブ・ウィジェットのひな形となるＤＯＭ要素を生成、追加する。繰り返し描画関数ｕｘ．ｒｅｐｅａｔがサブ・ウェジェットのウェジェット・レコードからＤＯＭ要素を生成する手順と、描画関数ｕｘ．ｒｅｎｄｅｒがウィジェット・レコードからＤＯＭ要素を生成する手順は、基本的に同じである。ひとまず、繰り返しパターン内のサブ・ウィジェットのウィジェット・レコードをｗｉｄｇｅｔｓ属性から取り出す（図１０の０８ないし１５行目）。
【０１１３】
この例では、ウィジェット・レコードの配列は３つのウィジェット・レコードから構成されている。この３つのウィジェット・レコードを元に、ひな形のｌｉタグの下に３つのｄｉｖタグを生成し、各ｄｉｖタグのｓｔｙｌｅ属性をウィジェット・レコード（図１０の１０、１２、１４行目）から生成する。各ｄｉｖタグのコンテンツ部分はテキスト属性（図１０の０９、１１、１３行目）から生成されるが、テキスト属性にプレースホルダー文字列を含む為、ここでプレースホルダー文字列の置換処理を呼び出す。
【０１１４】
次に、繰り返し描画関数ｕｘ．ｒｅｐｅａｔにおけるプレースホルダー文字列の置換処理を説明する。繰り返し描画関数ｕｘ．ｒｅｐｅａｔの第２引数が連想配列の配列である場合、置換結果を保持する二次元配列ｒｅｓｕｌｔを用意し、｛配列の連想配列の数｝×｛繰り返しパターン内のサブ・ウィジェットの数｝だけ置換処理を繰り返す。
【０１１５】
第２引数の配列のｉ番目の連想配列に対し、ｊ番目のサブ・ウィジェットのプレースホルダー文字列の置換処理は以下の通りである。ｊ番目のサブ・ウィジェットのテキスト属性を取得し、正規表現エンジンを用いて、プレースホルダー文字列を検索する。見つかったプレースホルダー文字列各々に対し、プレースホルダー名をキーにして、ｉ番目の連想配列から値を取得し、プレースホルダー文字列があった部分と置換する。ｊ番目のサブ・ウィジェットのテキスト属性にて、全てのプレースホルダー文字列を置換した結果の文字列をｒｅｓｕｌｔ［ｉ］［ｊ］に格納する。結果として得られる二次元配列ｒｅｓｕｌｔの内容を図１５に示す。
【０１１６】
最後に、ひな形のｌｉタグとプレースホルダー文字列を置換した結果ｒｅｓｕｌｔからコンテナ・ウィジェット部分のＤＯＭ構造を構築する手順を説明する。以下の繰り返しパターンの複製作業を繰り返し描画関数ｕｘ．ｒｅｐｅａｔの第２引数でしてされた回数だけ繰り返す。ひな形のｌｉタグを複製し、追加するｌｉタグとする。更にｌｉタグの子要素であるｄｉｖタグ各々に対し、各ウィジェットの生成処理を呼び出す。生成処理を呼び出す際のテキスト属性はプレースホルダー文字列を置換後のｒｅｓｕｌｔ［ｉ］［ｊ］とする。
【０１１７】
テキスト型のウィジェットの場合、渡されたテキスト属性をそのままコンテンツ部分に採用する。スター型のウィジェットの場合、渡されたテキスト属性（“４／５”，“３／５”，“５／５”，“３／５”）からコンテンツ部分の星表記（“★★★★☆”，“★★★☆☆”，“★★★★★”，“★★★☆☆”）を生成する。こうして追加するｌｉタグが出来上がったら、第１引数の識別名で特定したｕｌタグの下に追加する。
【０１１８】
ここまでの手順に従いウィジェット・レコードから動的に構築されたＨＴＭＬ文書を図１２及び図１３に示す。最終的なウェブ・コンテンツの画面が図１４となる。
【０１１９】
ページ・レイアウトを編集するウェブ・アプリで更新したウェブ・ページ・レイアウト情報１０は、次のようなアクセス制限のバリエーションを持って、一般ユーザーに公開される。一つ目は、ウェブ・コンテンツにリアルタイムに反映する。二つ目は、明示的にパブリッシュすることで、ウェブ・コンテンツとして公開される。三つ目は、二つ目の前段階としてサンドボックス・モードを設ける。サンドボックス・モードでは開発者のみが公開前のウェブ・ページ・レイアウト情報１０にアクセスすることができる。サンドボックス・モードはウェブ・コンテンツの開発作業や表示の確認作業に利用することができる。
【０１２０】
前記Ｗｅｂブラウザ１１から、ＨＴＭＬ文書を取得した前記第三ウェブ・サーバー装置２００とは異なる前記第二ウェブ・サーバー装置３にアクセスして情報を取得（クロスドメインアクセスという）しようとすると、Ｓａｍｅ  Ｏｒｉｇｉｎ  Ｐｏｌｉｃｙというセキュリティ上の要請から他ドメインにアクセスできない問題にぶつかる。
【０１２１】
このＳａｍｅ  Ｏｒｉｇｉｎ  Ｐｏｌｉｃｙの回避技術としてはＪＳＯＮＰなどが存在するが、ＪＳＯＮＰでのアクセスを許すと、第三者が誰でもＷｅｂ  ＡＰＩを通じてウェブ・ページ・レイアウト情報１０を取得できる状態になってしまう。このような場合にＷｅｂ  ＡＰＩのセキュリティ性を確保する方法としては、次のような手法がある。
【０１２２】
第一の方法としては、Ｗｅｂ  ＡＰＩのアドレスとは別に認証（ログイン）ページを用意し、前記Ｗｅｂブラウザ１１がセッション管理されたクッキーを保持する方法。セッション管理されたクッキーは、Ｗｅｂ  ＡＰＩの呼び出し時にプロトコル・ヘッダーに書き込まれる為、Ｗｅｂ  ＡＰＩの呼び出しを個別に認証できる。こうすることで認証ＩＤ及びパスワードを知っているユーザーしかＷｅｂ  ＡＰＩを利用できなくなる為、サンドボックス・モード向けの実装である。
【０１２３】
第二の方法としては、前記Ｗｅｂブラウザ１１がＷｅｂ  ＡＰＩを呼び出す際にリクエストに付与するリファラー（元文書のアドレス）を見て、あらかじめ登録しておいたドメインと同一かどうか確認する方法である。
【符号の説明】
【０１２４】
１          ウェブ・コンテンツ生成システム
６          第二処理装置
７          ウェブ・ページ・レイアウト・データベース
９          画面描画ライブラリ
１０        ウェブ・ページ・レイアウト情報
２４        ウィジェット
２０２      プロプライエタリ・データベース
【図１】
2015138541.tif 000003
【図２】
2015138541.tif 000004
【図３】
2015138541.tif 000005
【図４】
2015138541.tif 000006
【図５】
2015138541.tif 000007
【図６】
2015138541.tif 000008
【図７】
2015138541.tif 000009
【図８】
2015138541.tif 000010
【図９】
2015138541.tif 000011
【図１０】
2015138541.tif 000012
【図１１】
2015138541.tif 000013
【図１２】
2015138541.tif 000014
【図１３】
2015138541.tif 000015
【図１４】
2015138541.tif 000016
【図１５】
2015138541.tif 000017