JP5537330B2 - 表示画面構成装置 - Google Patents

Description

本発明は、コンピュータのスクリーン上に表示される画面を構成する表示画面構成装置に関する。

従来、サーバ・クライアントシステムにおいては、クライアントのスクリーンからデータが入力されると、クライアントのスクリーンへの表示入力内容は、サーバへメッセージとして送られ、サーバで処理された後、クライアントに処理後のメッセージが返送されて、クライアントのスクリーンに表示されていた。

最近になって、AjaxなどのJavaScript（登録商標）で記述されたプログラムを使って、インターネットブラウジング等をする場合には、クライアント側から入力したデータは、クライアントの端末内で処理される。すなわち、ユーザの入力したデータが表示された後、クライアント内部で処理されて、処理 後のデータが、クライアント端末のスクリーン上の別の画面に表示されるということが行われる。ところで、画面表示は、各画面についてその画面を表示するプ ログラムである画面部品が存在する。したがって、ある画面でユーザが入力したデータを処理して、次の画面上で表示する等をする場合には、ユーザの入力した データをある画面部品から他の画面部品に渡さなくてはならない。

従来、AjaxなどのJavaScript（登録商標）を用いたリッチクライアントアプリケーションでは、画面部品に表示されるデータをコントロールする ために、画面部品間のデータのやり取りが頻繁に発生する。たとえば、「入力画面」から「確認画面」へ遷移する際には、入力画面の画面部品で入力されたデー タを確認画面の画面部品へとコピーする作業が必要だが、入力項目が多くなるとこの処理量も比例して大きくなり、プログラム上の負担になっている。

また、入力内容のチェックを行う際には、入力値のチェックと、チェック結果に応じて画面を更新する、という２つの処理を行うが、これらの処理が画面部品ごとに行われるため、保守しにくい。

JavaScript（登録商標）は、非オブジェクト指向言語であるが、オブジェクト指向言語においては、このような問題に対処するため、ＭＶＣ（Model, View, Controller）モデルという概念が導入されている。

ＭＶＣモデルはJava（登録商標）などのオブジェクト指向言語では普通に使われる技術だが、JavaScript（登録商標）などの非オブジェクト指向 言語では、プログラムが部品ごとに独立していないので、プログラムを独立したものとして扱い、それらの間の関連付けをすることが難しく、実現困難である。 特に、非オブジェクト言語でＭＶＣモデルを導入した場合、モデルからビューへの同期機構を実現するのが難しい。

図２５及び図２６は、従来のJavaScript（登録商標）を使ったプログラムの処理の流れを示す図である。
まず、図２５の 表示のための初期化動作では、ＨＴＭＬ文や、画面部品タグ、外部チェックスクリプト１０をフレームワーク１１が読み込む。フレームワーク１１は、たとえ ば、ウェブブラウザに読み込まれ、ＨＴＭＬ文等を解釈し、解釈結果に従った表示を作成する処理を行うプログラムである。読み込みは、フレームワーク１１の ＨＴＭＬ解析、部品作成器１３が行い、ＨＴＭＬ文を解析し、必要な画面部品を作成する。作成された画面部
品１２は、ＨＴＭＬ文、画面部品タグ、外部チェックスクリプトに記載された内容に従ったものであり、たとえば、入力データのチェック機能を持ったものである。

図２６は、従来の画面部品の表示動作を説明する図である。
ブラウザ内部でイベントが発生すると、画面部品１６のイベント解析部１８に通知される。ここで、ＨＴＭＬ ＤＯＭ（HTML Document Object Model)２０は、ブラウザ内部に実装される、標準的なＨＴＭＬ文書の処理機能である。イベント解析部１８で、発生したイベントの種類がわかると、内部 チェック部１９で、発生したイベントに対する、画面部品内でのチェック（正しい入力内容か等のチェック）が行われる。内部チェックの後には、外部チェック 部２０が、外部チェックスクリプト１７に、内部チェック以外の入力に対するチェック処理を依頼する。外部チェック部２０の処理が終わると、画面更新部２１ がブラウザに表示内容の更新を依頼する。また、外部チェックスクリプト１７も、独自に、ブラウザに表示内容の更新を依頼する。

入力値のチェックをするためには、図２６の処理をするが、画面部品ごとに行われるため、チェック機構が部品ごとに分散してしまい、保守しにくいという問題がある。
特許文献１には、スケルトンプログラムに「データ変換命令」を用意しておき、その内容を入力されたデータの内容によって置き換える方法が開示されている。

特開２００３−１５０２９０号公報

本発明の課題は、非オブジェクト言語で記述された画面部品において、画面部品ごとに入力値のチェック等を行う機構を用意しなくても、入力値チェック等を実行できるような表示画面構成装置を提供することである。

本発明の表示画面構成装置は、非オブジェクト指向言語による記述によって表示画面を構成する表示画面構成装置であって、表示画面を表示し、該表示画面からのユーザのイベント入力を受け付け、該イベント入力の内部処理を行って、表示画面に内部処理結果を反映した表示を行うビュー手段と、該ビュー手段とは別個 に設けられて、該ビュー手段とバインディング機能により関連付けられ、該ビュー手段を介して受け付けたイベント入力の外部処理を行い、外部処理結果を該 ビュー手段に渡して表示画面に反映させるモデル手段と、該モデル手段が受け付けたイベント入力による入力値が所定の条件を満たしているか否かを検査し、そ の結果を該モデル手段の外部処理結果として、表示画面に反映させるスキーマ手段とを備えることを特徴とする。

本発明によれば、非オブジェクト指向言語においても、画面部品ごとに入力値チェック機構を設ける必要がなく、プログラミングを容易にし、部品点数の増加を抑制することが出来る。

本発明の原理を説明する図（その１）である。 本発明の原理を説明する図（その２）である。 本発明の原理を説明する図（その３）である。 非オブジェクト指向言語においてＭＶＣを実現する場合のシステムの初期化時の動作を説明する図である。 画面部品に対する入力値の変更があった場合に、値の変更をモデルに反映する場合の動作を説明する図である。 モデルに対する変更を画面部品に反映する場合の動作を説明する図である。 スキーマを用いて、画面への入力値のチェックを行う場合の動作を説明する図である。 １つの入力についてのみ値チェックを行う場合の動作を説明する図である。 図７及び図８の動作を処理フローにまとめた図である。 初期化処理時の詳細な処理フローである。 画面に変更があり、モデルに変更を反映する場合の詳細な処理フロー（その１）である。 画面に変更があり、モデルに変更を反映する場合の詳細な処理フロー（その２）である。 モデルに変更があり、画面に変更を反映する場合の詳細な処理フローである。 全体チェックの場合のチェック動作処理を説明する詳細な処理フロー（その１）である。 全体チェックの場合のチェック動作処理を説明する詳細な処理フロー（その２）である。 全体チェックの場合のチェック動作処理を説明する詳細な処理フロー（その３）である。 全体チェックの場合のチェック動作処理を説明する詳細な処理フロー（その４）である。 全体チェックの場合のチェック動作処理を説明する詳細な処理フロー（その５）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その１）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その２）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その３）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その４）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その５）である。 単一チェック動作時のチェック動作処理を説明する詳細な処理フロー（その６）である。 従来のJavaScript（登録商標）を使ったプログラムの処理の流れを示す図（その１）である。 従来のJavaScript（登録商標）を使ったプログラムの処理の流れを示す図（その２）である。

図１〜図３は、本発明の原理を説明する図である。
図１に 示されるように、本発明の実施形態では、JavaScript（登録商標）において、モデル（表示画面に対する処理ロジックの集まり）とビュー（画面に表 示を行うためのプログラム）を分離し、その間をバインディングのしくみで繋ぐことにより、データの自動更新を可能にする。また、スキーマ記述（入力表示内 容に対する制限を記述するプログラム文）を元に、モデルをチェックし、ビューに自動反映する。アクション設定は、ビューに対する所定のイベントが発生した 場合にビューが行うべきアクションを規定する。モデル
は、共通ＡＰＩ（Application Program Interface）を介して、他のアプリケーションからの操作を受け付ける。

すなわち、JavaScript（登録商標）のオブジェクト記法であるJSON(JavaScript Object
Notation)で記述された処理ロジックをモデル、画面部品をビュー、その他のロジックをコントローラというようにJavaScript（登録商標）にＭＶＣモデルを導入する。

ここで、ビューからモデルに対して「バインディング」という機構により、あるビューがモデルのどのデータを表示/入力するのかを指し示す仕組みを導入する。図２に示されるとおり、このバインディングの定義に従い、ビューとモデルを自動同期する機構を導入することにより、画面部品の変更(例えば、テキストフィールドへの文字入力)はモデルに自動反映され、逆にモデルの変更(例えば、サーバとの通信結果による変更)は画面部品に自動反映される。

さらに、複数の画面部品を同じモデルデータにバインディングすることも可能とするため、入力画面と確認画面の間のデータのコピーなどはモデルを通じて自動反映され、コピーするプログラムを記述する必要が一切不要になる。

また、モデルと対応した「スキーマ」というモデルの性質を記述した定義、及び、ビューに対応した「アクション」というスキーマのチェック結果をどのように処理するかの定義を用意することにより、モデルの正当性のチェックとそのビューへの自動反映を実現する。

図３は、モデルとバインドされた、テキストフィールドを持つビューの表示例を示している。
図３のテキストフィールドにあるモデルをバインドする場合には、以下のような記述を行う。
model={name:'abcde',price:'1000'};
RCF.bind('model',model);
<div rcf: id = "text1" rcf : type = "TextInput" rcf : value = "{model. name}" > </div>
<div rcf : id = "text2" rcf : type = "Text" rcf : value = "{model. name}" > </div>
一行目にモデルが定義され、モデルの名前と、値段として「１０００」という値を与えることが定義されている。RCF.bindの文は、モデルと、divタ グで記述されるビューをバインドする文である。divタグで記述されているビューは、上の文が、テキスト入力のためのテキストボックスの表示であり、下の文が、入力されたテキストを表示するビューの文である。

まず、ブラウザがHTMLをダウンロードすると、そこに記述されているフレームワークのためのスクリプト読込み指示により、フレームワークがダウンロードされる。フレームワークをダウンロードするためのスクリプトはHTMLに以下のように記述される。
<script src=”rcf.js”></script>
フレームワークは、複数のスクリプトのファイルで構成されるかもしれないが、rcf.jsがその他のファイルを自動的に読み込むため、ユーザが記述しなければいけないのは上記のrcf.jsの読込みの指示だけである。

HTMLの読込みが終了すると、フレームワークの動作が開始する。フレームワークは、まずHTMLの解析を行う。HTML内に記述されているタグに応じて、画面部品や機能部品を作成する。

画面表示のためのプログラムを画面部品と機能部品に分割して構成する技術については、本発明の出願人と同じ出願人によって出願された、特願２００７−２８６４号明細書に記載されている。

また、HTML内または読み込まれた別ファイルのJavaScript（登録商標）内には、モデル定義とスキーマ定義として、以下のような記述を行う。
model1= { name: 'abcde', price: '1000' };
schema1 = { price: { type: integer, check: function(value) { if (value < 0) return false; else return true; } } };
RCF.bind('model', model1, schema1);
model1変数はモデルの定義、schema1変数はスキーマの定義である。これを、RCF.bind命令で関連付けている。ここでは関連付けはJavaScript（登録商標）の命令で行っているが、タグで記述することもできる。その場合、次のようになる。
<div rcf:id="model" rcf:type="Model" rcf:model="model1" rcf:schema=”schema1”></div>
ここで、変数model1は、modelという名のモデルとして使えるようになる。

このとき、フレームワークでは、モデル管理部が動作し、モデルリポジトリにmodelという名のモデルが登録される。スキーマが指定されている場合は、スキーマも一緒に登録される。

そして、バインドを行うことにより、ある画面から入力された値の他の画面への自動反映を行うことが出来るようになる。
バインドは、以下のように記述する。
<div rcf:id="a" rcf:type="TextInput" rcf:value="{model.price}"></div>
<div rcf:id="av" rcf:type="ValidationHandler" rcf:target="a" rcf:event=”blur”
rcf:success=”a.color='black'” rcf:fail=”a.color='red'”></div>
TextInput部品は、テキスト入力を行う部品である。ここで、rcf:value="{model.price}"と記述することにより、この TextInput部品は、modelという名のモデルのprice変数にバインドされる。すなわち、このテキスト入力部品に値を入力すると、model1のprice変数に値が伝わる。なお、ここでは、当該TextInputに対応するアクション部品も記述している(ここの例では、 ValidationHandlerという名の部品。入力値が正しい形式で入力されているか否かを判断するプログラム部品)。

TextInput部品が変更されると、そのイベントが画面部品に伝達される。その内容はモデル管理部に伝わり、最終的にバインドされているモデルの内容 が変更される。逆にモデルのprice変数を変更すると、その内容がテキストフィールドに伝わり、自動的に表示が更新される。ただし、price変数を変更するためには、単に
model1.price = 2000;
などと代入することでは値を伝えることができない。これは、上記命令が実行されたことをフレームワークで感知することが言語仕様上不可能だからである。その代わりに、フレームワークの命令を使って値を変更する。
model.setProperty(“price”, 2000);
この命令でprice変数を変更することにより、その変更をテキストフィールドに自動的に伝えることができる。

値のチェックは、モデル全体をチェックする方法と、ひとつの画面部品のデータのみをチェックする方法と２種類が可能である。
全体チェックの場合、ユーザのスクリプトからモデル管理部に対してチェック実行指示
がなされる。これを契機として、チェックが開始する。チェックはスキーマを使って行う。スキーマの定義は、モデルと同じ名前の属性に対して、型やその他の内容が整合しているかどうかをチェックできるようになっている。先ほどの例を再掲すると、
model1= { name: 'abcde', price: '1000' };
schema1 = { price: { type: integer, check: function(value) { if (value < 0) return false; else return true; } } validateAll: function(value, result) { if (value.name == “afo” && value.price == 2000) { result.name = false; result.price = false; return false; } else true; } };
となっている。ここでは、priceという属性に対して
type: integer
check: function(value) { if (value < 0) return false; else return true; } }
という2つのチェック内容が定義されている。これは、
・priceは整数でなければならない。
・priceは0より大きくなければならない。
という2つの内容を定義している。ここでわかるように、チェック内容は、typeのように宣言的なものと、checkのようにロジックで記述するものとの２種類がある。
宣言的に記述できる内容の例は、以下のようなものである。

type: データの型。integerやfloat、stringなど
length: データの文字列長
minValue, maxValue: データが数値の場合の最小値、最大値
上記のような宣言的な書き方でチェックしきれない内容は、ロジックで行うことができる。その場合はcheckを使う。

さらに、複数の値の間の相関的なチェックを行いたい場合は、validateAllで行うことができる。validateAllは常にfunctionで ある。validateAllのvalue引数にはチェック対象のモデルが渡され、モデル内のさまざまな値を混在したチェックを行うことができる。たとえ ば、上記の例では、モデルのnameが”afo”であり、priceが2000のときにはチェックが失敗したものとして扱う。この場合、下記のチェック結 果部もresult引数として渡されるので、ここに任意のチェック結果を格納する。上記の場合は、name属性とprice属性の両方が失敗したものとし て結果部に格納されている。

チェックした内容は、チェック結果部に格納される。チェックはすべての属性(type, checkなど)について行われ、ひとつでもエラーがあればチェックが失敗したものとして、その情報がチェック結果部に格納される。失敗している情報は、 すべてチェック結果部に格納される。これにより、あとでアクション部品がどのチェックで失敗しているかを知ることができる。

上記のcheckやvalidateAllの例ではtrue(チェック成功), false(チェック失敗)の２種類しかないが、チェックが失敗した場合はErrorオブジェクトなど、任意のオブジェクトを格納することもできる。たとえば、以下のようにも記述できる。
check: function(value) { if (value < 0) return throw new Error(“正でなければなりません”); else return true; } }
validateAll: function(value, result) { if (value.name == “afo” && value.price == 2000) { result.name = new Error(“名前が間違っています”); result.price = new
Error(“値段が間違っています”); return false; } else true; }
また、上記のスキーマにはname属性に対応する定義がない。この場合は、チェックは行われず、チェック結果は常にチェックが成功しているものとみなされ る。チェックが終了すると、モデル管理部はチェック結果を参照し、対応するバインドが行われている画面部品に対して、チェック結果を通知する。画面部品で は、チェック結果を受け取ると、アクション部品が存在する場合のみ、そのチェック結果をアクション部品に伝達する。

アクション部品は、チェックが成功した場合と失敗した場合のそれぞれにどのような動作をするべきかを定義してある。先ほどの例の場合、
<div rcf:id="av" rcf:type="ValidationHandler" rcf:target="a" rcf:event=”blur”
rcf:success=”a.color='black'” rcf:fail=”a.color='red'”></div>
となっている。ここで、
rcf:successは、チェックが成功している場合に実行する内容
rcf:failは、チェックが失敗した場合に実行する内容
である。上記例では、チェックが成功している場合は対象の画面部品(この場合TextInput)の色を黒く(a.color='black')、失敗した場合は対象の画面部品を赤く(a.color='red')するようになっている。

アクション部品では、さらに複雑な動作をさせるために外部関数を指定することもできる。
<div rcf:id="av" rcf:type="ValidationHandler" rcf:target="a" rcf:event=”blur”
rcf:success=”successProcess(a, result)” rcf:fail=”failProcess(a, result)”></div>
function successProcess(target, result) {
...
}
function failProcess(target, result) {
...
}
上記のような記述になっていると、成功時、失敗時にそれぞれsuccessProcess、failProcessが呼び出され、その中で詳細な動作を記 述することができる。ここでtarget変数は変更対象とする画面部品であり、resultはチェック結果である。なお、画面部品にアクション部品が関連 付けられていないときは、特に何もしない。

また、チェックは、単一のデータのみに対して行うこともできる。たとえば、上記のアクション部品では、
rcf:event=”blur”
という定義がなされている。これは、対象の部品からフォーカスが外れた（カーソルが別のところに移動した）ときにチェックの実行を開始することを意味している。

処理の流れは、以下の通りである。
まず、ブラウザ内部からイベントが発生する。イベントはアクション部品に伝わり、これがチェック実行指示と同じイベントの場合(上記例なら、フォーカスが外れたら)、モデル管理部に対してチェックの実行を開始させる。

その後の動作は、ほぼ全体をチェックする場合と同じだが、チェック実行の契機となった画面部品に関連するデータのみをチェックする、という点が全体チェッ クと異なる。validateAllは複数のデータの関連をチェックするときのみ実行されるものなので、単一データのチェック時には呼び出されない。

スキーマによるチェックは画面部品がバインドしているデータのみにおいて行われ、チェック結果も契機となった画面部品にのみ伝えられる。
以上の構成により、非オブジェクト指向のJavaScript（登録商標）においてMVCを実現している。また、モデルと一緒に「スキーマ」を用意するこ とにより、データチェックをモデルと同じ粒度(単位)で実現できる。これにより、部品ごとにチェックロジックが分散しないという効果が得られる。また、 チェック処理と画面操作を分離しているので、同じ
モデルデータを画面上の複数箇所に表示している場合などに、部品ごとにエラーに対するアクション の仕方を分けることができる。更に、JavaScript（登録商標）では、必要に応じてチェックをサーバに依頼することも可能である。よって、データ個 別の値チェック、モデルまとめての値チェックの両方がひとつの仕組みでできるようになる。

図４は、非オブジェクト指向言語においてＭＶＣを実現する場合のシステムの初期化時の動作を説明する図である。
まず、ＨＴＭＬ文、画面部品タグ、機能部品タグ、モデル、スキーマ定義をフレームワーク３１のＨＴＭＬ解析、部品作成器２８が読み込む。ＨＴＭＬ解析、部 品作成器２８は、画面部品タグ、機能部品タグを基に、画面部品２６、機能部品（アクション部品）２７を作成する。また、機能部品２７は、画面部品２６と関 連付けられて、画面部品２６への入力に対する処理の実行を担当し、画面部品２６と機能部品２７は、ＭＶＣモデルにおけるビューに対応する。また、モデル、 スキーマ定義は、モデル管理部２９によって、モデルリポジトリ３０に登録される。

図５は、画面部品に対する入力値の変更があった場合に、値の変更をモデルに反映する場合の動作を説明する図である。
ブラウザ内部３５において、イベントが発生し、これが、画面部品の変更である場合、この変更は、画面部品２６に対して行われる。画面部品２６は、変更が あった場合には、フレームワーク３１のモデル管理部２９に変更内容のモデルへの反映を依頼する。モデル管理部２９は、画面部品２６に対して行われた変更を モデル３６に反映して処理を終了する。

図６は、モデルに対する変更を画面部品に反映する場合の動作を説明する図である。
ユーザの記述したJavaScript（登録商標）４０によって、モデル３６に変更依頼がなされる。ここで、モデル２６への変更依頼は、たとえば、 setPropertyコマンドで行われる。モデル３６に変更がなされると、モデル３６からモデル管理部２９に対し、画面部品２６への変更の反映依頼がな される。モデル管理部２９は、反映依頼を受け取ると、画面部品２６に対し、画面部品更新依頼を行う。この依頼により、モデル３６に対してなされた変更が、 画面部品２６に反映される。画面部品２６は、変更を受け付けると、ブラウザ内部のＨＴＭＬ ＤＯＭ３５に、ブラウザの表示の更新を行う。これにより、画面部品２６への変更が、実際にブラウザ上の表示の変更となって表示される。

図７は、スキーマを用いて、画面への入力値のチェックを行う場合の動作を説明する図である。
まず、ユーザのスクリプト３５が値のチェックを実行する。すると、フレームワーク３１のモデル管理部２９は、スキーマ３７に対し、値のチェック実行を依頼 する。スキーマ３７は、モデル３６の値を取得し、所定の条件を満たしているか否かをチェックし、チェック結果をチェック結果格納部３８に格納する。モデル 管理部２９は、チェック結果格納部３８内のチェック結果を参照し、チェック結果に従った画面部品の更新依頼を画面部品２６に対して行う。たとえば、値が正しくない場合には、赤色で値を表示するなどである。画面部品２６は、画面入力に対する処理を担当する機能部品２７に対し、画面部品更新依頼を行う。機能部 品２７は、依頼にしたがって、画面部品を更新して、処理を終了する。

図７では、モデルに関連付けられている全ての値表示に対し、値の全体チェックを行う場合を記述している。
図８は、１つの入力についてのみ値チェックを行う場合の動作を説明する図である。

ブラウザ内部３５でイベントが発生すると、画面部品２６がイベントの発生を検出する
。 今の場合、フォーカスがずれる等である。これにより、画面部品２６は、機能部品２７に対して、入力値のチェックの実行指示を行う。機能部品２７は、フレー ムワーク３１のモデル管理部２９に対し、発生したイベントに対応するモデルの入力値のチェック依頼を行う。モデル管理部２９は、スキーマ３７に対し、 チェックの実行を依頼し、スキーマ３７は、対応するモデル３６から値を取得してチェックし、チェック結果をチェック結果格納部３８に格納する。モデル管理 部２９は、チェック結果格納部３８に格納されているチェック結果を参照し、画面部品２６に画面部品変更依頼を行う。画面部品変更依頼を受け取った画面部品 ２６は、機能部品２７に対し、画面更新依頼を行い、機能部品２７は、画面部品２６を更新する。この動作により、入力値がスキーマで規定される条件を満たし ていない場合には、入力値が赤色で表示されるなどの表示の変更がなされる。

図８では、１つの入力値についてのみの単一チェック動作であるので、たとえば、値が入力されたテキストボックスの値に対してのみチェック動作を行う。
図９は、図７及び図８の動作を処理フローにまとめた図である。

図９（ａ） においては、全てのモデル全体について値のチェックを行う場合と、１つのイベントに対する値のチェックを行う場合の処理の流れが示されている。全体の チェックを行う場合には、ステップＳ１０において、ユーザが作成したスクリプトであるモデルのチェック処理を呼び出し、ステップＳ１３に進む。１つのイベ ントに対する単体のチェックの場合には、ステップＳ１１で、ブラウザにおけるイベントの発生を検出し、ステップＳ１２で、当該イベントに対応するモデルを 確認して、ステップＳ１３に進む。

ステップＳ１３においては、スキーマでチェックを行う。全体チェックの場合には、ユーザスクリプトで指定されたとおり、全てのモデルについてチェックを行 う。単体のチェックの場合には、ステップＳ１２で確認されたモデルに対してのみチェックを行う。ステップＳ１４では、チェック結果を格納し、モデル管理部 がチェック結果を参照する。そして、ステップＳ１５において、各画面部品に対するチェック結果の確認を行い、処理を終了する。

図９（ｂ）は、図９（ａ）のステップＳ１５の処理内容を示すフローである。
まず、ステップＳ１６において、チェック対象となるモデルを確認し、ステップＳ１７において、対象モデルがあるか否かを判断する。ステップＳ１７におい て、チェック処理を行うプログラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１７において、対象モデルがあると判断 された場合（Ｙｅｓの場合）には、ステップＳ１８において、チェック処理を行うプログラム（ここでは、前述の、入力値が正しい形式で入力されているか否か を判断するValidationHandlerというプログラムとしている）があるか否かを判断する。ステップＳ１８において、チェック処理を行うプログ ラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１８において、チェック処理を行うプログラムがあると判断された場合 （Ｙｅｓの場合）には、チェックを行い、ステップＳ１９において、チェックの結果、入力値が正しいか否かにしたがった処理を行って、処理を終了する。この 処理は、入力値が正しくないときには、値を赤色で表示し、正しい場合には、黒色で表示するなどである。

図１０は、初期化処理時の詳細な処理フローである。
ステップＳ２５とステップＳ２９で示されるループで、ブラウザから読み取られたＨＴＭＬ文の要素全てについて処理を行う。ステップＳ２６において、 ＨＴＭＬ文の要素を取得し、ステップＳ２７において、取得されたＨＴＭＬ文の要素が、画面部品であるか否かを判断する。ステップＳ２７の判断がＮｏの場合 には、ステップＳ２８に進む。ステップＳ２７の判断がＹｅｓの場合には、ステップＳ３０において、画面部品を作成し、画面部品を画面部品リポジトリに登録 して、ステップＳ２９に進む。

ステップＳ２８においては、取得されたＨＴＭＬ文の要素がモデル定義タグまたは、命令か否かを判断する。ステップＳ２８の判断がＮｏの場合には、ステップ Ｓ２９に進む。ステップＳ２８の判断がＹｅｓの場合には、ステップＳ３２において、モデルのデータをモデルリポジトリに保存し、ステップＳ３３において、 スキーマが指定されているか否かを判断する。ステップＳ３３の判断がＮｏの場合には、ステップＳ２９に進む。ステップＳ３３の判断がＹｅｓの場合には、ス キーマのデータをモデルリポジトリに保存して、ステップＳ２９に進む。

なお、ここでは、モデルリポジトリと独立して、画面部品リポジトリが設けられているものとしたが、モデルと画面部品を別々に管理できれば、両方をまとめて、１つのリポジトリとしても良い。

図１１及び図１２は、画面に変更があり、モデルに変更を反映する場合の詳細な処理フローである。
図１１に おいて、まず、ステップＳ３５で、ブラウザ内にイベントが発生したことが検出される。ステップＳ３６において、画面部品がイベントを受信する。ステップ Ｓ３７において、当該イベントによって、入力内容が変更されたか否かを判断する。ステップＳ３７の判断がＮｏの場合には、処理を終了する。ステップＳ３７ の判断がＹｅｓの場合には、ステップＳ３８において、値がモデルを指しているか否かを判断する。すなわち、値が、rcf:value = "{model. name}"の形式か否かを判断する。ステップＳ３８の判断がＮｏの場合には、処理を終了する。ステップＳ３８の判断がＹｅｓの場合には、ステップＳ３９ において、モデル管理部を呼び出し、モデル管理部の処理が終わったら、処理を終了する。

図１２は、図１１の処理フロー中のモデル管理部の処理を説明する処理フローである。
ステップＳ４０において、画面部品の設定値を取得する。すなわち、< span ……… rcf:value = "{model. name}">のvalueの部分を取得する。ステップＳ４１において、設定値からモデル名を取得する。たとえば、{model. name}と指定されていたら、modelの部分を取得する。ステップＳ４２において、取得した名前で示されるモデルをモデルリポジトリから取得する。ス テップＳ４３において、設定値からプロパティ名を取得する。たとえば、{model. name}と指定されていたら、nameの部分を取得する。ステップＳ４４において、モデルに入力値を設定する。すなわち、画面部品に入力された値をモデ ルに設定する。

図１３は、モデルに変更があり、画面に変更を反映する場合の詳細な処理フローである。
ステップＳ４５において、ユーザJavaScript（登録商標）を実行する。ここでは、setPropertyを実行するとしている。この実行により、 ステップＳ４６において、モデルの保持する値を更新する。次に、ステップＳ４７からステップＳ５３のループで、画面部品リポジトリに含まれる全ての画面部 品について処理を行う。ステップＳ４８では、画面部品を１つ取得する。ステップＳ４９において、画面部品の保持する値がモデルを指しているか否かを判断す る。「値がモデルを指す」とは、図１１の ステップＳ３８の場合と同じことを意味する。ステップＳ４９の判断がＮｏの場合には、ステップＳ５３に進む。ステップＳ４９の判断がＹｅｓの場合には、ス テップＳ５０において、モデルを指している値が更新されたか否かを判断する。ステップＳ５０の判断がＮｏの場合には、ステップＳ５３に進む。ステップ Ｓ５０の判断がＹｅｓの場合には、ステップＳ５１において、画面部品に値を設定し、ステップＳ５２において、画面部品が表示を更新し、ステップＳ５３に進 む。ステップＳ４７からステップＳ５３のループで、全ての画面部品について処理が終わったら、処理を終了する。

図１４〜図１８は、全体チェックの場合のチェック動作処理を説明する詳細な処理フローである。
図１４に おいて、ステップＳ５５で、ユーザのスクリプトからモデルを指定し、チェックの実行指令を出す。ステップＳ５６において、指定されたモデルをモデルリポジ トリから取り出し、ステップＳ５７において、モデルに対応するスキーマが存在するか否かを判断する。ステップＳ５７の判断がＮｏの場合には、処理を終了す る。ステップＳ５７の判断がＹｅｓの場合には、ステップＳ５８からステップＳ６６のループで、以下の処理をすべてのモデル内の要素について行う。まず、ス テップＳ５９において、モデル内の要素を一つ取り出す。ステップＳ６０において、スキーマに対応する名前が、要素の中にあるか否かを判断する。ステップ Ｓ６０の判断がＮｏの場合には、ステップＳ６６に進む。ステップＳ６０の判断がＹｅｓの場合には、ステップＳ６１において、スキーマ定義を取り出し、ス テップＳ６２において、宣言要素を実行する。ステップＳ６３において、結果をチェック結果に格納し、ステップＳ６４において、ロジック要素を実行し、ス テップＳ６５において、結果をチェック結果格納部に格納し、ステップＳ６６に進む。ステップＳ５８からステップＳ６６のループで、全てのモデル内要素について処理が終わったら、ステップＳ６７に進む。

ステップＳ６７からステップＳ７０のループでは、画面部品リポジトリに格納されている画面部品全てについて以下の処理を行う。まず、ステップＳ６８におい て、画面部品を取り出し、ステップＳ６９において、画面部品にチェック結果を反映し、ステップＳ７０に進む。ステップＳ６７からステップＳ７０のループ で、画面部品リポジトリに格納されている全ての画面部品について処理が終わると、全体の処理を終了する。

図１５は、図１４のステップＳ６２の詳細フローである。
宣言要素を実行する場合には、ステップＳ７１において、モデルの値を取り出し、ステップＳ７２で値が、たとえば、整数か否かを判断する。これは、 type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ７２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であったことを返す。

図１６は、図１４のステップＳ６４の詳細フローである。
ロジック要素を実行する場合、ステップＳ７３において、モデルの値を取り出し、ステップＳ７４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。

図１７は、図１４のステップＳ６７の詳細フローである。
画面部品に変更を反映する場合、ステップＳ７５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３の ステップＳ４９と同じである。ステップＳ７５の判断がＮｏの場合には、処理を終了する。ステップＳ７５の判断がＹｅｓの場合には、ステップＳ７６におい て、アクション部品（機能部品）があるか否かを判断する。ステップＳ７６の判断がＮｏの場合には、処理を終了する。ステップＳ７６の判断がＹｅｓの場合に は、ステップＳ７７において、アクション部品を呼び出し、実行して処理を終了する。

図１８は、図１７のステップＳ７７の詳細フローである。
アクション部品を呼び出し、実行する場合、ステップＳ７８において、チェックは成功したか否かを判断する。ステップＳ７８の判断がＹｅｓの場合には、ステップＳ７９に進
み、success属性があるか否かを判断する。ステップＳ７９の判断がＮｏの場合には、処理を終了する。ステップＳ７９の判断がＹｅｓの場合には、ステップＳ８０において、success属性の中身を実行して、処理を終了する。

ステップＳ７８の判断がＮｏの場合には、ステップＳ８１において、failed属性はあるか否かを判断する。ステップＳ８１の判断がＮｏの場合には、処理 を終了する。ステップＳ８１の判断がＹｅｓの場合には、ステップＳ８２において、failed属性の中身を実行して、処理を終了する。

図１９〜図２４は、単一チェック動作時のチェック動作処理を説明する詳細な処理フローである。
図１９に おいて、まず、ステップＳ９０で、ブラウザからイベントが発生すると、ステップＳ９１において、画面部品がイベントを受信し、ステップＳ９２において、画 面部品がモデルを指しているか否かを判断する。ここの判断は、画面部品がバインディングで関連付けられたモデルを有しているか否かの判断である。ステップ Ｓ９２の判断がＮｏの場合には、処理を終了する。ステップＳ９２の判断がＹｅｓの場合には、ステップＳ９３において、アクション部品が存在するか否かを判断する。ステップＳ９３の判断がＮｏの場合には、処理を終了する。ステップＳ９３の判断がＹｅｓの場合には、ステップＳ９４において、event属性が存在するか否かを判断する。ステップＳ９４の判断がＮｏの場合には、処理を終了する。ステップＳ９４の判断がＹｅｓの場合には、ステップＳ９５において、 チェック対象イベントか否かを判断する。ステップＳ９５の判断がＮｏの場合には、処理を終了する。ステップＳ９５の判断がＹｅｓの場合には、ステップ Ｓ９６において、チェックを実行し、処理を終了する。

図２０は、図１９のステップＳ９６の詳細フローである。
ステップＳ９７において、モデルリポジトリから対象モデルを取り出し、ステップＳ９８において、モデルに対応するスキーマが存在するか否かを判断する。ス テップＳ９８の判断がＮｏの場合には、処理を終了する。ステップＳ９８の判断がＹｅｓの場合には、ステップＳ９９において、画面部品に指定された、モデル の要素を取り出す。ステップＳ１００において、スキーマに対応する名前があるか否かを判断する。ステップＳ１００の判断がＮｏの場合には、処理を終了す る。ステップＳ１００の判断がＹｅｓの場合には、ステップＳ１０１において、スキーマ定義を取り出し、ステップＳ１０２において、宣言要素を実行し、ス テップＳ１０３において、結果をチェック結果格納部に格納する。ステップＳ１０４において、ロジック要素を実行し、ステップＳ１０５において、結果を チェック結果格納部に格納する。ステップｓ１０６では、画面部品に反映し、処理を終了する。

図２１は、図２０のステップＳ１０２の詳細フローである。
宣言要素を実行する場合には、ステップＳ２０１において、モデルの値を取り出し、ステップＳ２０２で値が、たとえば、整数か否かを判断する。これは、 type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ２０２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であった ことを返す。

図２２は、図２０のステップＳ１０４の詳細フローである。
ロジック要素を実行する場合、ステップＳ２０３において、モデルの値を取り出し、ステップＳ２０４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。

図２３は、図２０のステップＳ１０６の詳細フローである。
画面部品に変更を反映する場合、ステップＳ２０５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３の ステップＳ４９と同じである。ステップＳ２０５の判断がＮｏの場合には、処理を終了する。ステップＳ２０５の判断がＹｅｓの場合には、ステップＳ２０６に おいて、アクション部品（機能部品）があるか否かを判断する。ステップＳ２０６の判断がＮｏの場合には、処理を終了する。ステップＳ２０６の判断がＹｅｓ の場合には、ステップＳ２０７において、アクション部品を呼び出し、実行して処理を終了する。

図２４は、図２３のステップＳ２０７の詳細フローである。
アクション部品を呼び出し、実行する場合、ステップＳ２０８において、チェックは成功したか否かを判断する。ステップＳ２０８の判断がＹｅｓの場合には、 ステップＳ２０９に進み、success属性があるか否かを判断する。ステップＳ２０９の判断がＮｏの場合には、処理を終了する。ステップＳ２０９の判断 がＹｅｓの場合には、ステップＳ２１０において、success属性の中身を実行して、処理を終了する。

ステップＳ２０８の判断がＮｏの場合には、ステップＳ２１１において、failed属性はあるか否かを判断する。ステップＳ２１１の判断がＮｏの場合に は、処理を終了する。ステップＳ２１１の判断がＹｅｓの場合には、ステップＳ２１２において、failed属性の中身を実行して、処理を終了する。

１０ ＨＴＭＬ、画面部品タグ、外部チェックスクリプト
１１ フレームワーク
１２ 画面部品（チェック機能付き）
１３ ＨＴＭＬ解析、部品作成器
１５、３５ ＨＴＭＬ ＤＯＭ（ブラウザ内部）
１６ 画面部品
１７ 外部チェックスクリプト
１８ イベント解析部
１９ 内部チェック部
２０ 外部チェック部
２１ 画面更新部
２５ ＨＴＭＬ、画面部品タグ、機能部品タグ、モデル、スキーマ定義
２６ 画面部品
２７ 機能部品
２８ ＨＴＭＬ解析、部品作成器
２９ モデル管理部
３０ モデルリポジトリ
３１ フレームワーク
３６ モデル
３７ スキーマ
３８ チェック結果格納部
４０ ユーザJavaScript

Claims (5)

1. コンピュータを、
   Ｊａｖａｓｃｒｉｐｔで記述された画面部品を表示し、該画面部品に対してユーザにより入力された入力情報を受け付け、該入力情報に対するチェック結果を基に前記画面部品の表示を更新するビュー手段と、
   モデル変数と、前記モデル変数の値の性質が宣言的に記述されたスキーマ定義とを対応付ける第１のバインディング定義を基に前記モデル変数及び前記スキーマ定義をモデルリポジトリに登録し、前記モデルリポジトリから、前記画面部品と前記モデル変数とを対応付ける第２のバインディング定義を基に、前記ビュー手段がイベント入力を受け付けた前記画面部品に対応するモデル変数を取得し、該取得したモデル変数に前記入力情報を設定し、前記モデルリポジトリに登録された、前記入力情報を設定したモデル変数のモデル変数の値の性質が宣言的に記述されたスキーマ定義を基に、前記入力情報が設定されたモデル変数の値の性質が前記スキーマ定義に宣言的に記述された性質に合致するか否かをチェックし、該チェック結果を前記ビュー手段に通知するモデル管理手段
   として機能させるプログラム。
2. 前記モデル管理手段は、前記モデルリポジトリに登録されたモデル変数のうち、ユーザスクリプトに基づき値が変更されたモデル変数を取得し、前記モデルリポジトリに登録された、前記値が変更されたモデル変数の値の性質が宣言的に記述されたスキーマ定義を基に、前記値が変更されたモデル変数の値の性質が前記スキーマ定義に宣言的に記述された性質に合致するか否かをチェックし、該チェック結果を前記ビュー手段に通知し、
   前記ビュー手段は、前記モデル管理手段からのチェック結果の通知を基に、前記画面部品の表示の更新を行う
   請求項１記載のプログラム。
3. 前記第２のバインディング定義に更に含まれる、前記モデル変数の値の性質が前記スキーマ変数に宣言的に記述された性質に合致した場合及び合致しなかった場合の少なくともいずれかの動作定義を基に、前記モデル変数に対応付けられた前記画面部品を、前記チェック結果に基づき更新するアクション手段を更に備え、
   前記ビュー手段は前記モデル管理手段からの前記チェック結果の通知を基に前記アクション手段を呼び出して実行することにより、前記画面部品を更新する
   請求項１記載のプログラム。
4. 前記ビュー手段は、前記画面部品に対するイベントの発生に基づき前記入力情報が変更されたか否かを判定し、前記入力情報が変更されたと判定し、且つ、前記第２のバインディング定義に前記入力値が変更された画面部品に対応付けてモデル変数が定義されている場合に前記モデル管理手段に前記入力情報のモデルへの反映を依頼し、前記画面部品に対するイベントの発生に基づき、前記第２のバインディング定義に前記イベントが変更された画面部品に対応付けて前記モデル変数及び前記アクション手段が定義されている場合に前記モデル管理手段に前記モデルの値のチェックを依頼し、
   前記モデル管理手段は、前記ビュー手段による前記モデルへの反映の依頼に基づき、前記モデルリポジトリに登録されたモデル変数のうち、前記第２のバインディング定義に前記入力値が変更された画面部品の識別情報に対応付けて定義されているモデル変数に前記入力値を設定し、前記ビュー手段による前記モデルの値のチェック依頼に基づき、前記モデル変数の設定値の性質が、前記スキーマ変数に宣言的に記述された性質に合致するか否かをチェックする
   請求項１記載のプログラム。
5. Ｊａｖａｓｃｒｉｐｔで記述された画面部品を表示し、該画面部品に対してユーザにより入力された入力情報を受け付けるビュー手段と、
   モデル変数と、前記モデル変数の値の性質が宣言的に記述されたスキーマ定義とを対応付ける第１のバインディング定義を基に前記モデル変数及び前記スキーマ変数を前記モデルリポジトリに登録し、前記モデルリポジトリから、前記画面部品と前記モデル変数とを対応付ける第２のバインディング定義を基に、前記ビュー手段がイベント入力を受け付けた前記画面部品に対応するモデル変数を取得し、該取得したモデル変数に前記入力情報を設定し、前記モデルリポジトリに登録された、前記入力情報を設定したモデル変数のモデル変数の値の性質が宣言的に記述されたスキーマ定義を基に、前記入力情報が設定されたモデル変数の値の性質が前記スキーマ定義に宣言的に記述された性質に合致するか否かをチェックし、該チェック結果を前記ビュー手段に通知するモデル管理手段と、を備え、
   前記ビュー手段は前記前記モデル管理手段からの前記チェック結果の通知を基に前記画面部品の表示を更新する
   ことを特徴とする表示画面構成装置。