JP4438625B2 - 表示装置 - Google Patents

Description

本発明は、ウェブブラウザからの表示要求により表示データを取得して編集し、ウェブコントロールを介して表示イメージを前記ウェブブラウザに返す画面アプリケーション手段を有する表示装置に関する。

ウェブブラウザを表示手段としたデータ表示装置に関連する先行技術文献としては次のようなものがある。

特開２００２−４１２９６号公報

ＰＣ及びインターネットの普及により、ウェブブラウザを表示手段とした画面アプリケーションをウェブサーバに構築した表示装置が幅広く使われるようになった。ただし、画面アプリケーションは表現能力が乏しく、これを補うための共通コンポーネントが画面アプリケーション作成時には必須のものとなっている。このコンポーネントはウェブコントロールと呼ばれる。

ウェブコントロールの中でも、特に、データグリッド、ツリービュー、タブシート、グラフなどは、分かりやすい形式でのデータ表示や操作ができるため、画面アプリケーションではよく使われ、汎用的な共通コンポーネントとして提供されている。

画面アプリケーションは、ウェブコントロールを介して表示イメージをウェブブラウザに渡すが、データベースから取得した表示データをウェブコントロール毎に編集して設定するデータインターフェースの処理を必要とする。

図１１は従来における表示装置の一例を示す機能ブロック図である。点線のブロック１はウェブサーバであり、画面アプリケーション手段１０を有する。点線のブロック２はクライアントＰＣであり、ウェブブラウザ２０を有する。点線のブロック３はデータベースサーバであり、ウェブコントロールを介して表示するデータを更新保持している。

画面アプリケーション手段１０において、１１はウェブコントロールＡであり、ウェブブラウザ２０からの表示要求Ｑによりウェブブラウザに表示イメージ（例えばグラフ）を渡してウェブコントロールＡ画面２１を表示させる。

同様に、１２はウェブコントロールＢであり、ウェブブラウザに表示イメージ（例えばグリッド）を渡してウェブコントロールＢ画面２２を表示させる。１３はウェブコントロールＣであり、ウェブブラウザに表示イメージ（例えばツリー）を渡してウェブコントロールＣ画面２３を表示させる。

画面アプリケーション手段１０において、１４はデータ入力処理手段Ａであり、データベースサーバ３に対するデータ送付要求Ｒに基づいてデータベース３１より表示データＡを取得して１７で示すデータ編集処理手段Ａに渡す。

同様に、１５はデータ入力処理手段Ｂであり、データベース３２より表示データＢを取得して１８で示すデータ編集処理手段Ｂに渡す。１６はデータ入力処理手段Ｃであり、データベース３３より表示データＣを取得して１９で示すデータ編集処理手段Ｃに渡す。

データ編集処理手段１７乃至１９は、入力処理手段１４乃至１６から渡された表示データを対応する各ウェブコントロール１１乃至１４のデータインターフェース構造に合わせて編集し直して各ウェブコントロールに設定する。

これらの処理が完了すると、画面アプリケーション手段１０のウェブコントロールからウェブブラウザ２０に表示イメージが返信され、表示要求されたウェブコントロール画面が表示される。

従来の表示装置では、夫々のウェブコントロールを互いに独立した関連の薄い機能として捉えていた。このため、ウェブコントロールのデータインターフェースも統一されていないため、ウェブコントロール画面の作成時に、それぞれのウェブコントロールに対応したデータ編集の作成が必要であった。

従来の表示装置の構成では、以下の問題点がウェブコントロール画面作成の効率低下要因となっている。
（１）煩雑なデータインターフェース：
ウェブコントロールへのデータ表示は、ウェブコントロールのデータバッファにデータを設定することで行われる。ウェブコントロールは多彩な表現に対応するために、そのデータインターフェースが複雑なものになっている。

ウェブコントロールを使用する場合、そのデータバッファ名を知り設定作業をする必要がある。ウェブコントロールの種類が増えるとデータバッファ数も増加し、各々のデータバッファ名を知る作業が煩雑となる。

（２）煩雑なプロパティ設定：
ウェブコントロールに対するプロパティ設定は、例えば、フォント名、フォントサイズといった一つのシステム、あるいはウェブコントロール画面内で同じ設定にしたいプロパティであっても、個々のウェブコントロールに対して個別に行う必要があり、ウェブコントロールの種類が増えるとプロパティ設定作業が極めて煩雑になる。

従って本発明が解決しようとする課題の第１は、ウェブコントロールのデータバッファ名を意識しないデータ設定並びに共通プロパティ設定ができる表示装置を実現することにある。

（３）プログラム記述を必要とするデータ入力処理：
データ入力処理に関しては、データ入力先の指定、データ入力メソッドの呼び出しによるソースプログラムの作成を行うためのプログラム記述が必要となり、プログラミングに習熟していないユーザのウェブ画面作成効率の阻害要因となっている。

従って本発明が解決しようとする課題の第１は、ウェブコントロールのデータバッファ名を意識しないデータ設定並びに共通プロパティ設定ができる表示装置を実現することにある。

本発明が解決しようとする課題の第２は、データ入力処理に関してプログラム記述を必要としない表示装置を実現することにある。

このような課題を達成するために、本発明の構成は次の通りである。
（１）ウェブサーバに構築された、ウェブブラウザを表示手段とする画面アプリケーション手段が、前記ウェブブラウザより表示イメージの異なる複数のデータ表示要求を受けて前記表示イメージに対応する複数の表示データを取得し、取得した複数の表示データに対して前記複数の表示イメージの表示処理を実行する、複数の種類の異なるウェブコントロールを介して複数の表示イメージを前記ウェブブラウザに返す表示装置において、
前記画面アプリケーション手段は、
取得した前記複数の表示データを汎用データ記述言語に変換するデータ変換手段と、
変換された前記複数の表示データを取得し、前記複数のウェブコントロール毎のデータインターフェースに合わせた編集処理を実行する、共通のデータインターフェース手段と、
を備えたことを特徴とする表示装置。

（２）前記データインターフェース手段は、
変換された前記複数の表示データから前記複数の種類の異なるウェブコントロールＩＤを取得し、取得したこのウェブコントロールの種類に基づいて、どのウェブコントロールにどの表示データを出力するかを判定するデータ出力先判定手段を備えたことを特徴とする（１）に記載の表示装置。

（３）前記データインターフェース手段は、
変換された前記複数の表示データに基づいて前記複数の種類の異なるウェブコントロール固有のプロパティ情報を前記各ウェブコントロールに設定すると共に、全てのウェブコントロールに共通のプロパティ情報を、共通プロパティ設定手段より取得して前記各ウェブコントロールに設定することを特徴とする請求項１又は２に記載の表示装置。

（４）前記汎用データ記述言語は、ＸＭＬであることを特徴とする請求項１乃至３のいずれかに記載の表示装置。

以上説明したことから明らかなように、本発明によれば次のような効果が期待でき、ウェブコントロール画面の作成工数を大幅に削減することが可能となる。
（１）ウェブコントロールの種別に因らない、共通のデータインターフェース手段を導入することにより、ウェブコントロールのバッファ名を意識することなくウェブコントロールへのデータ設定、プロパティ設定が行えるので、ウェブコントロールの扱いが簡単になる。

（２）ウェブコントロールの種類が異なっても、同様の形式でデータ設定、プロパティ設定できるため、ウェブコントロール毎にデータをそろえなおすことなく設定できる。例えば、同一のデータを複数の表現形式でウェブコントロール画面に表示する場合でも、同一の形式でデータをそろえておけば表示できる。

（３）複数ウェブコントロールに対して共通プロパティ定義による設定ができるため、この定義に従う範囲ではウェブコントロール毎にプロパティ設定を行う必要がなくなる。更に、共通プロパティ定義に優先して個別プロパティ定義による設定を可能とすることで、プロパティ設定作業を効率化できる。

（４）データ入力先の指定、データ入力メソッドの呼び出しによるソースプログラムの作成を行うデータ入力処理でのプログラム記述が不要となり、プログラミングに習熟していないユーザのウェブ画面作成効率を向上させることができる。

以下本発明を、図面を用いて詳細に説明する。図１は本発明を適用した表示装置の一実施形態を示す機能ブロック図である。図１１で説明した従来表示装置と同一要素には同一符号を付し、説明を省略する。以下、本発明の特徴部につき説明する。

本発明の構成上の特徴は、
（１）異なる種類のウェブコントロールに対して同一形式でデータ設定、プロパティ設定できる共通データインターフェース手段の導入。
（２）異なる種類のウェブコントロールに対して共通プロパティ設定を可能とする共通プロパティ定義手段の導入。
（３）ウェブコントロールに対する表示データを、汎用データ記述言語に変換して共通データインターフェース手段に渡すデータ変換手段の導入。
（４）入力データ定義の標準化による、プログラム記述不要のデータ入力処理。
にある。

図１において、１００は本発明が適用された画面アプリケーション手段である。ウェブコントロール１０１乃至１０３及びデータ入力処理手段１０４乃至１０６は、図７で説明したウェブコントロール１１乃至１３及びデータ入力処理手段１４乃至１６と同一機能であるため説明を省略する。

本発明特有の構成は、データインターフェース手段２００、データ変換手段３００、共通プロパティ定義手段４００である。データインターフェース手段２００は、データ変換手段３００から渡される汎用データ記述言語に変換された表示データ及び共通プロパティ定義手段４００から渡される共通プロパティ情報を取得して、ウェブコントロール毎のデータインターフェースに合わせた編集を実行して表示データ及びプロパティ設定を実行する。

本発明で採用できる汎用データ記述言語は、ＸＭＬ（Extensible Markup Language）が最も一般的であるが、ＣＳＶ（Comma Separated Value）やＴＳＶ（Tab Separated Value ）
のデータ記述形式でも採用できる。本発明の実施形態ではＸＭＬとして説明する。

図２は、データインターフェース手段２００の具体的な構成例を示す機能ブロック図である。２０１はウェブコントロール１０１のデータ編集手段、２０２はウェブコントロール１０２のデータ編集手段、２０３はウェブコントロール１０３のデータ編集手段である。

２０４はデータ編集手段２０１に対するプロパティ設定部、２０５はデータ編集手段２０２に対するプロパティ設定部、２０６はデータ編集手段２０３に対するプロパティ設定部である。

２０７はデータ受け取り手段であり、データ変換手段３００よりＸＭＬ変換されたウェブコントロール毎の表示データ並びにプロパティ定義情報を取得し、取得データをデータ出力先判定手段２０８に渡す。

データ出力先判定手段２０８は、渡された表示データ並びにプロパティ情報よりウェブコントロールのＩＤを知り、このＩＤに基づいてウェブコントロールの種類を取得し、その種類情報により、データ編集手段２０１乃至２０３に表示データを渡し、プロパティ設定部２０４乃至２０６にプロパティ定義情報を渡す。

２０９は共通プロパティ設定手段であり、共通プロパティ定義手段４００からＸＭＬで渡されるプロパティ定義情報を保持し、プロパティ設定部２０４乃至２０６に共通プロパティ定義情報を渡す。

プロパティ設定部２０４乃至２０６は、データ変換手段３００より渡されるウェブコントロール固有のプロパティ定義情報と共通プロパティ定義手段４００から渡されるウェブコントロール共通のプロパティ定義情報を設定するが、ウェブコントロール固有のプロパティ定義情報が優先される。

データ編集手段２０１乃至２０３は、ＸＭＬで記述されているデータをウェブコントロール毎に異なるデータインターフェースに設定する処理を実行するが、最初の処理手順のプログラムを作成すれば、データの形式が標準化されているので次からは処理手順のプログラムを汎用的に使用できる。

従って、データインターフェース手段２００として必要なウェブコントロールの編集手段をあらかじめ備えたパッケージとすることにより、これを汎用的なソフトウェア部品として利用することができるので、ウェブ表示画面の設計作業の効率を大幅に向上できる。

図３は、データインターフェース手段２００の信号処理手順を示すフローチャートである。処理がスタートすると、ステップＳ１乃至Ｓ３はデータ受け取り手段２０７及び共通プロパティ設定手段２０９の処理である。

ステップＳ１ではデータ変換手段３００よりウェブコントロールの表示データ及びプロパティ定義情報を受け取る。ステップＳ２では共通プロパティ定義手段４００よりウェブコントロールに対する共通プロパティ定義情報を受け取る。ステップＳ３ではＸＭＬで受け取った定義情報を先頭から解釈する。

ステップＳ４及びＳ５は、データ出力先判定手段２０８の処理である。ステップＳ４では、出力先のウェブコントロールのＩＤを取得する。このＩＤは、ＸＭＬの先頭にプロパティ情報と共に記述されている。ステップＳ５では、取得したＩＤから用意された関数を用いてウェブコントロールの種類を取得する。

ステップＳ６乃至Ｓ１１は、データ出力先判定手段２０８の判定結果に基づくデータ編集手段２０１乃至２０３の処理である。ステップＳ６の判定で出力先がデータグリッドであればステップＳ７でデータグリッドのウェブコントロールのデータ編集手段にデータを出力する。

ステップＳ８の判定で出力先がグラフであればステップＳ９でグラフのウェブコントロールのデータ編集手段にデータを出力する。ステップＳ１０の判定で出力先がツリービューであればステップＳ１１でツリービューのウェブコントロールのデータ編集手段にデータを出力する。全ての種類のウェブコントロールについてのデータ編集が終了すると処理が終了する。

図４は、表示データのＸＭＬ記述例を示すリストである。タグ先頭行でＴＹＰＥ、ＩＤ、フォント等のプロパティ定義情報が記述され、次のレコード領域にデータの数値情報が記述される。

図５は、図４の数値情報によりグリッド表示した画面例、図６は同じ数値情報によりグラフ表示した画面例示す。表示データのＸＭＬ記述では、データとウェブコントロールの結びつけの定義を含むため、同一データを使用する場合には、コントロール毎に上記データ中のＴＹＰＥ、ＩＤを修正すればよく、データの修正は不要である。

このように、ブラウザの画面上に一連のデータをグラフ（アナログ表示）と表（デジタル表示）する場合には、表示データのＸＭＬ記述により、データの記述が標準化されるため、画面アプリケーションの設計作業が効率化され大きな効果が期待できる。

次に、入力データ定義の標準化による、プログラム記述不要のデータ入力処理環境について図７乃至図９により説明する。図７は、データ入力処理手段の構成を中心に示した画面アプリケーション１００の機能ブロック図である。

図７において、５００は本発明を適用したデータ入力処理手段Ａ（図１では１０４）であり、データベース３１の表示データＡを入力してデータ変換手段３００に渡す処理を実行する。他のデータ入力処理手段Ｂ，Ｃの機能構成も同一である。

５０１は、表示データの形式を定義する入力データ定義手段であり、定義情報保持手段５０１ａを備える。５０２はデータ入力手段であり、入力データ定義手段５０１で定義された入力データ定義及びＯＰＣ（OLE for Process Control）インターフェース手段５０３を介してデータベース３１から取得される表示データを入力する。

データ入力手段５０２は、ＸＭＬ形式の入力データ定義から入力データアイテム名を取り出し、ＯＰＣインターフェース手段５０３を介して取得される表示データと共にデータ変換手段３００に渡す。

図８は、入力データ定義手段５０１から、データインターフェース手段２００までの一連の信号処理手順を示すフローチャートである。ステップＳ１よりステップＳ４までが入力データ定義手段５０１の処理である。

ステップＳ１で定義情報中にＸＭＬ形式の入力データ定義の有無がチェックされ、ない場合には、ステップＳ２でそのプロパティに定義された入力データ定義を取得し、ステップＳ３でＸＭＬ形式の入力データ定義を生成する。ステップＳ２，Ｓ３の処理ルートを（Ａ）とする。

ステップＳ１のチェックにおいて、定義情報中にＸＭＬ形式の入力データ定義がある場合には、ステップＳ４でそのＸＭＬ形式の入力データ定義を取得する。ステップＳ４の処理を（Ｂ）とする。

ステップＳ５及びステップＳ６は、データ入力手段５０２の処理である。ステップＳ５では、ＸＭＬ形式の入力データ定義から入力データアイテム名を取り出し、ステップＳ６でＯＰＣインターフェース手段５０３を介して表示データを取得する。ステップＳ５の処理を（Ｃ）とする。

ステップＳ７及びステップＳ８は、データ変換手段３００及びデータインターフェース手段２００の処理である。ステップＳ７では、入力したデータをウェブ画面に表示するためにＸＭＬデータ形式に編集する。ステップＳ８では、編集したＸＭＬデータをデータインターフェース手段２００に渡す。ステップＳ７の処理を（Ｄ）とする。

図９は、図８のフローチャートに対応するデータ処理内容を例示した遷移図である。ブロック（Ａ），（Ｂ）→（Ｃ）→（Ｄ）の遷移は、図８のフローチャートで示した（Ａ），（Ｂ），（Ｃ），（Ｄ）の処理に対応したデータ処理内容の具体例を示す。

（Ａ）では、定義情報中にＸＭＬ形式の入力データ定義がないので、プロパティに定義されたデータアイテム名を取得し、これを編集してＸＭＬ形式の入力データ定義を生成している。（Ｂ）では、定義情報中にＸＭＬ形式の入力データ定義があるにで、その定義によりＸＭＬ形式の入力データ定義を生成している。この場合には、ウェブブラウザへのデータ表示時に細かい指定を行うことが可能である。

（Ｃ）では、ＸＭＬ形式の入力データ定義から入力データアイテム名を取り出す。（Ｄ）では、入力データ定義とＯＰＣインターフェース手段５０３を介して取得された入力データ（数値）に基づき、表示用のＸＭＬデータ形式に編集する。

以上説明したデータインターフェース手段２００、データ変換手段３００、データ入力処理手段５００は別々のソフトウェアとして開発されるが、コンピュータ上での実行可能プログラムを作成して実装された環境下では、ウェブ画面作成者は、これら手段の個々の存在を意識する必要がない。

ウェブ画面アプリケーションを作成する場合、何らかのソフトウェア開発ツールを使用するが、画面の表示イメージを直接編集できるようなイメージエディタ機能を持つ開発ツールを使用するのが一般的である。

図１０は、ソフトウェア部品によるウェブ画面プログラム開発環境の例を示すイメージ図である。６００は画面イメージエディタ、７００はソフトウェア部品選択パレット、８００はソフトウェア部品プロパティエディタである。

以下に、この画面イメージエディタ６００を使用してウェブ画面アプリケーションを開発する一般的な手順をステップＳ１乃至Ｓ４により説明する。
（Ｓ１）表示用のソフトウェア部品（表示名：＊＊＊グリッド等）をソフトウェア部品選択パレット７００から選択し、画面イメージエディタ６００上に配置する。

（Ｓ２）配置したソフトウェア部品のプロパティ（色、フォント名、フォントサイズ）をソフトウェア部品プロパティエディタ８００に値を入力して設定する。

（Ｓ３）ソフトウェア部品選択パレット７００から実装（表示名：ＯＰＣデータオブジェクト等）を選択し、画面イメージエディタ６００上に配置する。

（Ｓ４）この実装についても（Ｓ２）と同様にソフトウェア部品プロパティエディタ８００に値を入力してプロパティを設定する。ここで設定するのは、以下の項目となる。
（１）入力データ定義（ＸＭＬファイル名、または、入力データ名）
（２）入力データを表示するソフトウェア部品名（（Ｓ１）で配置したもの）

本発明を適用した表示装置の一実施形態を示す機能ブロック図である。 データインターフェース手段の具体的な構成例を示す機能ブロック図である。 データインターフェース手段の信号処理手順を示すフローチャートである。 表示データのＸＭＬ記述例を示すリストである。 グリッド表示した画面例である。 グラフ表示した画面例である。 データ入力処理手段の構成を中心に示した画面アプリケーションの機能ブロック図である。 入力データ定義手段から、データインターフェース手段までの一連の信号処理手順を示すフローチャートである。 図８のフローチャートに対応するデータ処理内容を例示した遷移図である。 ソフトウェア部品によるウェブ画面プログラム開発環境を示すイメージ図である。 従来表示装置の一例を示す機能ブロック図である。

符号の説明

１ ウェブサーバ
２ クライアントＰＣ
２０ ウェブブラウザ
２１，２２，２３ ウェブコントロール画面
３ データベースサーバ
３１，３２，３３ データベース
１００ 画面アプリケーション
１０１，１０２，１０３ ウェブコントロール
１０４，１０５，１０６ データ入力処理手段
２００ データインターフェース手段
３００ データ変換手段
４００ 共通プロパティ定義手段

Claims (4)

1. ウェブサーバに構築された、ウェブブラウザを表示手段とする画面アプリケーション手段が、前記ウェブブラウザより表示イメージの異なる複数のデータ表示要求を受けて前記表示イメージに対応する複数の表示データを取得し、取得した複数の表示データに対して前記複数の表示イメージの表示処理を実行する、複数の種類の異なるウェブコントロールを介して複数の表示イメージを前記ウェブブラウザに返す表示装置において、
   前記画面アプリケーション手段は、
   取得した前記複数の表示データを汎用データ記述言語に変換するデータ変換手段と、
   変換された前記複数の表示データを取得し、前記複数のウェブコントロール毎のデータインターフェースに合わせた編集処理を実行する、共通のデータインターフェース手段と、
   を備えたことを特徴とする表示装置。
2. 前記データインターフェース手段は、
   変換された前記複数の表示データから前記複数の種類の異なるウェブコントロールＩＤを取得し、取得したこのウェブコントロールの種類に基づいて、どのウェブコントロールにどの表示データを出力するかを判定するデータ出力先判定手段を備えたことを特徴とする請求項１に記載の表示装置。
3. 前記データインターフェース手段は、
   変換された前記複数の表示データに基づいて前記複数の種類の異なるウェブコントロール固有のプロパティ情報を前記各ウェブコントロールに設定すると共に、全てのウェブコントロールに共通のプロパティ情報を、共通プロパティ設定手段より取得して前記各ウェブコントロールに設定することを特徴とする請求項１又は２に記載の表示装置。
4. 前記汎用データ記述言語は、ＸＭＬであることを特徴とする請求項１乃至３のいずれかに記載の表示装置。