JP2008171281A - 表示画面構成装置 - Google Patents
表示画面構成装置 Download PDFInfo
- Publication number
- JP2008171281A JP2008171281A JP2007005170A JP2007005170A JP2008171281A JP 2008171281 A JP2008171281 A JP 2008171281A JP 2007005170 A JP2007005170 A JP 2007005170A JP 2007005170 A JP2007005170 A JP 2007005170A JP 2008171281 A JP2008171281 A JP 2008171281A
- Authority
- JP
- Japan
- Prior art keywords
- model
- check
- screen
- display screen
- input
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
【課題】非オブジェクト言語で記述された画面部品において、画面部品ごとに入力値のチェック等を行う機構を用意しなくても、入力値チェック等を実行できるような表示画面構成装置を提供する。
【解決手段】非オブジェクト言語で記述された画面プログラムを、画面表示を行うビューと、画面表示に対する外部処理ロジックであるモデルに分割して、ビューとモデルをバインディング設定により関連付ける。複数のビューを同じモデルに関連付けることで、複数の画面で同じ値が表示される場合に、モデルに処理を施すことで、全ての画面での表示に同様に処理の結果を表示させることが出来る。また、モデルには、画面からの入力値への制限を記述するスキーマを関連させ、画面からの入力値が正しい形式で入力されているか等のチェックを一括して行う。
【選択図】図１
【解決手段】非オブジェクト言語で記述された画面プログラムを、画面表示を行うビューと、画面表示に対する外部処理ロジックであるモデルに分割して、ビューとモデルをバインディング設定により関連付ける。複数のビューを同じモデルに関連付けることで、複数の画面で同じ値が表示される場合に、モデルに処理を施すことで、全ての画面での表示に同様に処理の結果を表示させることが出来る。また、モデルには、画面からの入力値への制限を記述するスキーマを関連させ、画面からの入力値が正しい形式で入力されているか等のチェックを一括して行う。
【選択図】図１
Description
本発明は、コンピュータのスクリーン上に表示される画面を構成する表示画面構成装置に関する。
従来、サーバ・クライアントシステムにおいては、クライアントのスクリーンからデータが入力されると、クライアントのスクリーンへの表示入力内容は、サーバへメッセージとして送られ、サーバで処理された後、クライアントに処理後のメッセージが返送されて、クライアントのスクリーンに表示されていた。
最近になって、AjaxなどのJavaScript（登録商標）で記述されたプログラムを使って、インターネットブラウジング等をする場合には、クライアント側から入力したデータは、クライアントの端末内で処理される。すなわち、ユーザの入力したデータが表示された後、クライアント内部で処理されて、処理後のデータが、クライアント端末のスクリーン上の別の画面に表示されるということが行われる。ところで、画面表示は、各画面についてその画面を表示するプログラムである画面部品が存在する。したがって、ある画面でユーザが入力したデータを処理して、次の画面上で表示する等をする場合には、ユーザの入力したデータをある画面部品から他の画面部品に渡さなくてはならない。
従来、AjaxなどのJavaScript（登録商標）を用いたリッチクライアントアプリケーションでは、画面部品に表示されるデータをコントロールするために、画面部品間のデータのやり取りが頻繁に発生する。たとえば、「入力画面」から「確認画面」へ遷移する際には、入力画面の画面部品で入力されたデータを確認画面の画面部品へとコピーする作業が必要だが、入力項目が多くなるとこの処理量も比例して大きくなり、プログラム上の負担になっている。
また、入力内容のチェックを行う際には、入力値のチェックと、チェック結果に応じて画面を更新する、という２つの処理を行うが、これらの処理が画面部品ごとに行われるため、保守しにくい。
JavaScript（登録商標）は、非オブジェクト指向言語であるが、オブジェクト指向言語においては、このような問題に対処するため、ＭＶＣ（Model, View, Controller）モデルという概念が導入されている。
ＭＶＣモデルはJava（登録商標）などのオブジェクト指向言語では普通に使われる技術だが、JavaScript（登録商標）などの非オブジェクト指向言語では、プログラムが部品ごとに独立していないので、プログラムを独立したものとして扱い、それらの間の関連付けをすることが難しく、実現困難である。特に、非オブジェクト言語でＭＶＣモデルを導入した場合、モデルからビューへの同期機構を実現するのが難しい。
図２５及び図２６は、従来のJavaScript（登録商標）を使ったプログラムの処理の流れを示す図である。
まず、図２５の表示のための初期化動作では、ＨＴＭＬ文や、画面部品タグ、外部チェックスクリプト１０をフレームワーク１１が読み込む。フレームワーク１１は、たとえば、ウェブブラウザに読み込まれ、ＨＴＭＬ文等を解釈し、解釈結果に従った表示を作成する処理を行うプログラムである。読み込みは、フレームワーク１１のＨＴＭＬ解析、部品作成器１３が行い、ＨＴＭＬ文を解析し、必要な画面部品を作成する。作成された画面部
品１２は、ＨＴＭＬ文、画面部品タグ、外部チェックスクリプトに記載された内容に従ったものであり、たとえば、入力データのチェック機能を持ったものである。
まず、図２５の表示のための初期化動作では、ＨＴＭＬ文や、画面部品タグ、外部チェックスクリプト１０をフレームワーク１１が読み込む。フレームワーク１１は、たとえば、ウェブブラウザに読み込まれ、ＨＴＭＬ文等を解釈し、解釈結果に従った表示を作成する処理を行うプログラムである。読み込みは、フレームワーク１１のＨＴＭＬ解析、部品作成器１３が行い、ＨＴＭＬ文を解析し、必要な画面部品を作成する。作成された画面部
品１２は、ＨＴＭＬ文、画面部品タグ、外部チェックスクリプトに記載された内容に従ったものであり、たとえば、入力データのチェック機能を持ったものである。
図２６は、従来の画面部品の表示動作を説明する図である。
ブラウザ内部でイベントが発生すると、画面部品１６のイベント解析部１８に通知される。ここで、ＨＴＭＬ ＤＯＭ（HTML Document Object Model)２０は、ブラウザ内部に実装される、標準的なＨＴＭＬ文書の処理機能である。イベント解析部１８で、発生したイベントの種類がわかると、内部チェック部１９で、発生したイベントに対する、画面部品内でのチェック（正しい入力内容か等のチェック）が行われる。内部チェックの後には、外部チェック部２０が、外部チェックスクリプト１７に、内部チェック以外の入力に対するチェック処理を依頼する。外部チェック部２０の処理が終わると、画面更新部２１がブラウザに表示内容の更新を依頼する。また、外部チェックスクリプト１７も、独自に、ブラウザに表示内容の更新を依頼する。
ブラウザ内部でイベントが発生すると、画面部品１６のイベント解析部１８に通知される。ここで、ＨＴＭＬ ＤＯＭ（HTML Document Object Model)２０は、ブラウザ内部に実装される、標準的なＨＴＭＬ文書の処理機能である。イベント解析部１８で、発生したイベントの種類がわかると、内部チェック部１９で、発生したイベントに対する、画面部品内でのチェック（正しい入力内容か等のチェック）が行われる。内部チェックの後には、外部チェック部２０が、外部チェックスクリプト１７に、内部チェック以外の入力に対するチェック処理を依頼する。外部チェック部２０の処理が終わると、画面更新部２１がブラウザに表示内容の更新を依頼する。また、外部チェックスクリプト１７も、独自に、ブラウザに表示内容の更新を依頼する。
入力値のチェックをするためには、図２６の処理をするが、画面部品ごとに行われるため、チェック機構が部品ごとに分散してしまい、保守しにくいという問題がある。
特許文献１には、スケルトンプログラムに「データ変換命令」を用意しておき、その内容を入力されたデータの内容によって置き換える方法が開示されている。
特開２００３−１５０２９０号公報
特許文献１には、スケルトンプログラムに「データ変換命令」を用意しておき、その内容を入力されたデータの内容によって置き換える方法が開示されている。
本発明の課題は、非オブジェクト言語で記述された画面部品において、画面部品ごとに入力値のチェック等を行う機構を用意しなくても、入力値チェック等を実行できるような表示画面構成装置を提供することである。
本発明の表示画面構成装置は、非オブジェクト指向言語による記述によって表示画面を構成する表示画面構成装置であって、表示画面を表示し、該表示画面からのユーザのイベント入力を受け付け、該イベント入力の内部処理を行って、表示画面に内部処理結果を反映した表示を行うビュー手段と、該ビュー手段とは別個に設けられて、該ビュー手段とバインディング機能により関連付けられ、該ビュー手段を介して受け付けたイベント入力の外部処理を行い、外部処理結果を該ビュー手段に渡して表示画面に反映させるモデル手段と、該モデル手段が受け付けたイベント入力による入力値が所定の条件を満たしているか否かを検査し、その結果を該モデル手段の外部処理結果として、表示画面に反映させるスキーマ手段とを備えることを特徴とする。
本発明によれば、非オブジェクト指向言語においても、画面部品ごとに入力値チェック機構を設ける必要がなく、プログラミングを容易にし、部品点数の増加を抑制することが出来る。
図１〜図３は、本発明の原理を説明する図である。
図１に示されるように、本発明の実施形態では、JavaScript（登録商標）において、モデル（表示画面に対する処理ロジックの集まり）とビュー（画面に表示を行うためのプログラム）を分離し、その間をバインディングのしくみで繋ぐことにより、データの自動更新を可能にする。また、スキーマ記述（入力表示内容に対する制限を記述するプログラム文）を元に、モデルをチェックし、ビューに自動反映する。アクション設定は、ビューに対する所定のイベントが発生した場合にビューが行うべきアクションを規定する。モデル
は、共通ＡＰＩ（Application Program Interface）を介して、他のアプリケーションからの操作を受け付ける。
図１に示されるように、本発明の実施形態では、JavaScript（登録商標）において、モデル（表示画面に対する処理ロジックの集まり）とビュー（画面に表示を行うためのプログラム）を分離し、その間をバインディングのしくみで繋ぐことにより、データの自動更新を可能にする。また、スキーマ記述（入力表示内容に対する制限を記述するプログラム文）を元に、モデルをチェックし、ビューに自動反映する。アクション設定は、ビューに対する所定のイベントが発生した場合にビューが行うべきアクションを規定する。モデル
は、共通ＡＰＩ（Application Program Interface）を介して、他のアプリケーションからの操作を受け付ける。
すなわち、JavaScript（登録商標）のオブジェクト記法であるJSON(JavaScript Object
Notation)で記述された処理ロジックをモデル、画面部品をビュー、その他のロジックをコントローラというようにJavaScript（登録商標）にＭＶＣモデルを導入する。
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>
図３のテキストフィールドにあるモデルをバインドする場合には、以下のような記述を行う。
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の読込みの指示だけである。
<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= { 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という名のモデルとして使えるようになる。
<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という名の部品。入力値が正しい形式で入力されているか否かを判断するプログラム部品)。
バインドは、以下のように記述する。
<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.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のようにロジックで記述するものとの２種類がある。
宣言的に記述できる内容の例は、以下のようなものである。
全体チェックの場合、ユーザのスクリプトからモデル管理部に対してチェック実行指示
がなされる。これを契機として、チェックが開始する。チェックはスキーマを使って行う。スキーマの定義は、モデルと同じ名前の属性に対して、型やその他の内容が整合しているかどうかをチェックできるようになっている。先ほどの例を再掲すると、
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を使う。
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; }
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=”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はチェック結果である。なお、画面部品にアクション部品が関連付けられていないときは、特に何もしない。
<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”
という定義がなされている。これは、対象の部品からフォーカスが外れた（カーソルが別のところに移動した）ときにチェックの実行を開始することを意味している。
rcf:event=”blur”
という定義がなされている。これは、対象の部品からフォーカスが外れた（カーソルが別のところに移動した）ときにチェックの実行を開始することを意味している。
処理の流れは、以下の通りである。
まず、ブラウザ内部からイベントが発生する。イベントはアクション部品に伝わり、これがチェック実行指示と同じイベントの場合(上記例なら、フォーカスが外れたら)、モデル管理部に対してチェックの実行を開始させる。
まず、ブラウザ内部からイベントが発生する。イベントはアクション部品に伝わり、これがチェック実行指示と同じイベントの場合(上記例なら、フォーカスが外れたら)、モデル管理部に対してチェックの実行を開始させる。
その後の動作は、ほぼ全体をチェックする場合と同じだが、チェック実行の契機となった画面部品に関連するデータのみをチェックする、という点が全体チェックと異なる。validateAllは複数のデータの関連をチェックするときのみ実行されるものなので、単一データのチェック時には呼び出されない。
スキーマによるチェックは画面部品がバインドしているデータのみにおいて行われ、チェック結果も契機となった画面部品にのみ伝えられる。
以上の構成により、非オブジェクト指向のJavaScript（登録商標）においてMVCを実現している。また、モデルと一緒に「スキーマ」を用意することにより、データチェックをモデルと同じ粒度(単位)で実現できる。これにより、部品ごとにチェックロジックが分散しないという効果が得られる。また、チェック処理と画面操作を分離しているので、同じ
モデルデータを画面上の複数箇所に表示している場合などに、部品ごとにエラーに対するアクションの仕方を分けることができる。更に、JavaScript（登録商標）では、必要に応じてチェックをサーバに依頼することも可能である。よって、データ個別の値チェック、モデルまとめての値チェックの両方がひとつの仕組みでできるようになる。
以上の構成により、非オブジェクト指向のJavaScript（登録商標）においてMVCを実現している。また、モデルと一緒に「スキーマ」を用意することにより、データチェックをモデルと同じ粒度(単位)で実現できる。これにより、部品ごとにチェックロジックが分散しないという効果が得られる。また、チェック処理と画面操作を分離しているので、同じ
モデルデータを画面上の複数箇所に表示している場合などに、部品ごとにエラーに対するアクションの仕方を分けることができる。更に、JavaScript（登録商標）では、必要に応じてチェックをサーバに依頼することも可能である。よって、データ個別の値チェック、モデルまとめての値チェックの両方がひとつの仕組みでできるようになる。
図４は、非オブジェクト指向言語においてＭＶＣを実現する場合のシステムの初期化時の動作を説明する図である。
まず、ＨＴＭＬ文、画面部品タグ、機能部品タグ、モデル、スキーマ定義をフレームワーク３１のＨＴＭＬ解析、部品作成器２８が読み込む。ＨＴＭＬ解析、部品作成器２８は、画面部品タグ、機能部品タグを基に、画面部品２６、機能部品（アクション部品）２７を作成する。また、機能部品２７は、画面部品２６と関連付けられて、画面部品２６への入力に対する処理の実行を担当し、画面部品２６と機能部品２７は、ＭＶＣモデルにおけるビューに対応する。また、モデル、スキーマ定義は、モデル管理部２９によって、モデルリポジトリ３０に登録される。
まず、ＨＴＭＬ文、画面部品タグ、機能部品タグ、モデル、スキーマ定義をフレームワーク３１のＨＴＭＬ解析、部品作成器２８が読み込む。ＨＴＭＬ解析、部品作成器２８は、画面部品タグ、機能部品タグを基に、画面部品２６、機能部品（アクション部品）２７を作成する。また、機能部品２７は、画面部品２６と関連付けられて、画面部品２６への入力に対する処理の実行を担当し、画面部品２６と機能部品２７は、ＭＶＣモデルにおけるビューに対応する。また、モデル、スキーマ定義は、モデル管理部２９によって、モデルリポジトリ３０に登録される。
図５は、画面部品に対する入力値の変更があった場合に、値の変更をモデルに反映する場合の動作を説明する図である。
ブラウザ内部３５において、イベントが発生し、これが、画面部品の変更である場合、この変更は、画面部品２６に対して行われる。画面部品２６は、変更があった場合には、フレームワーク３１のモデル管理部２９に変更内容のモデルへの反映を依頼する。モデル管理部２９は、画面部品２６に対して行われた変更をモデル３６に反映して処理を終了する。
ブラウザ内部３５において、イベントが発生し、これが、画面部品の変更である場合、この変更は、画面部品２６に対して行われる。画面部品２６は、変更があった場合には、フレームワーク３１のモデル管理部２９に変更内容のモデルへの反映を依頼する。モデル管理部２９は、画面部品２６に対して行われた変更をモデル３６に反映して処理を終了する。
図６は、モデルに対する変更を画面部品に反映する場合の動作を説明する図である。
ユーザの記述したJavaScript（登録商標）４０によって、モデル３６に変更依頼がなされる。ここで、モデル２６への変更依頼は、たとえば、setPropertyコマンドで行われる。モデル３６に変更がなされると、モデル３６からモデル管理部２９に対し、画面部品２６への変更の反映依頼がなされる。モデル管理部２９は、反映依頼を受け取ると、画面部品２６に対し、画面部品更新依頼を行う。この依頼により、モデル３６に対してなされた変更が、画面部品２６に反映される。画面部品２６は、変更を受け付けると、ブラウザ内部のＨＴＭＬ ＤＯＭ３５に、ブラウザの表示の更新を行う。これにより、画面部品２６への変更が、実際にブラウザ上の表示の変更となって表示される。
ユーザの記述したJavaScript（登録商標）４０によって、モデル３６に変更依頼がなされる。ここで、モデル２６への変更依頼は、たとえば、setPropertyコマンドで行われる。モデル３６に変更がなされると、モデル３６からモデル管理部２９に対し、画面部品２６への変更の反映依頼がなされる。モデル管理部２９は、反映依頼を受け取ると、画面部品２６に対し、画面部品更新依頼を行う。この依頼により、モデル３６に対してなされた変更が、画面部品２６に反映される。画面部品２６は、変更を受け付けると、ブラウザ内部のＨＴＭＬ ＤＯＭ３５に、ブラウザの表示の更新を行う。これにより、画面部品２６への変更が、実際にブラウザ上の表示の変更となって表示される。
図７は、スキーマを用いて、画面への入力値のチェックを行う場合の動作を説明する図である。
まず、ユーザのスクリプト３５が値のチェックを実行する。すると、フレームワーク３１のモデル管理部２９は、スキーマ３７に対し、値のチェック実行を依頼する。スキーマ３７は、モデル３６の値を取得し、所定の条件を満たしているか否かをチェックし、チェック結果をチェック結果格納部３８に格納する。モデル管理部２９は、チェック結果格納部３８内のチェック結果を参照し、チェック結果に従った画面部品の更新依頼を画面部品２６に対して行う。たとえば、値が正しくない場合には、赤色で値を表示するなどである。画面部品２６は、画面入力に対する処理を担当する機能部品２７に対し、画面部品更新依頼を行う。機能部品２７は、依頼にしたがって、画面部品を更新して、処理を終了する。
まず、ユーザのスクリプト３５が値のチェックを実行する。すると、フレームワーク３１のモデル管理部２９は、スキーマ３７に対し、値のチェック実行を依頼する。スキーマ３７は、モデル３６の値を取得し、所定の条件を満たしているか否かをチェックし、チェック結果をチェック結果格納部３８に格納する。モデル管理部２９は、チェック結果格納部３８内のチェック結果を参照し、チェック結果に従った画面部品の更新依頼を画面部品２６に対して行う。たとえば、値が正しくない場合には、赤色で値を表示するなどである。画面部品２６は、画面入力に対する処理を担当する機能部品２７に対し、画面部品更新依頼を行う。機能部品２７は、依頼にしたがって、画面部品を更新して、処理を終了する。
図７では、モデルに関連付けられている全ての値表示に対し、値の全体チェックを行う場合を記述している。
図８は、１つの入力についてのみ値チェックを行う場合の動作を説明する図である。
図８は、１つの入力についてのみ値チェックを行う場合の動作を説明する図である。
ブラウザ内部３５でイベントが発生すると、画面部品２６がイベントの発生を検出する
。今の場合、フォーカスがずれる等である。これにより、画面部品２６は、機能部品２７に対して、入力値のチェックの実行指示を行う。機能部品２７は、フレームワーク３１のモデル管理部２９に対し、発生したイベントに対応するモデルの入力値のチェック依頼を行う。モデル管理部２９は、スキーマ３７に対し、チェックの実行を依頼し、スキーマ３７は、対応するモデル３６から値を取得してチェックし、チェック結果をチェック結果格納部３８に格納する。モデル管理部２９は、チェック結果格納部３８に格納されているチェック結果を参照し、画面部品２６に画面部品変更依頼を行う。画面部品変更依頼を受け取った画面部品２６は、機能部品２７に対し、画面更新依頼を行い、機能部品２７は、画面部品２６を更新する。この動作により、入力値がスキーマで規定される条件を満たしていない場合には、入力値が赤色で表示されるなどの表示の変更がなされる。
。今の場合、フォーカスがずれる等である。これにより、画面部品２６は、機能部品２７に対して、入力値のチェックの実行指示を行う。機能部品２７は、フレームワーク３１のモデル管理部２９に対し、発生したイベントに対応するモデルの入力値のチェック依頼を行う。モデル管理部２９は、スキーマ３７に対し、チェックの実行を依頼し、スキーマ３７は、対応するモデル３６から値を取得してチェックし、チェック結果をチェック結果格納部３８に格納する。モデル管理部２９は、チェック結果格納部３８に格納されているチェック結果を参照し、画面部品２６に画面部品変更依頼を行う。画面部品変更依頼を受け取った画面部品２６は、機能部品２７に対し、画面更新依頼を行い、機能部品２７は、画面部品２６を更新する。この動作により、入力値がスキーマで規定される条件を満たしていない場合には、入力値が赤色で表示されるなどの表示の変更がなされる。
図８では、１つの入力値についてのみの単一チェック動作であるので、たとえば、値が入力されたテキストボックスの値に対してのみチェック動作を行う。
図９は、図７及び図８の動作を処理フローにまとめた図である。
図９は、図７及び図８の動作を処理フローにまとめた図である。
図９（ａ）においては、全てのモデル全体について値のチェックを行う場合と、１つのイベントに対する値のチェックを行う場合の処理の流れが示されている。全体のチェックを行う場合には、ステップＳ１０において、ユーザが作成したスクリプトであるモデルのチェック処理を呼び出し、ステップＳ１３に進む。１つのイベントに対する単体のチェックの場合には、ステップＳ１１で、ブラウザにおけるイベントの発生を検出し、ステップＳ１２で、当該イベントに対応するモデルを確認して、ステップＳ１３に進む。
ステップＳ１３においては、スキーマでチェックを行う。全体チェックの場合には、ユーザスクリプトで指定されたとおり、全てのモデルについてチェックを行う。単体のチェックの場合には、ステップＳ１２で確認されたモデルに対してのみチェックを行う。ステップＳ１４では、チェック結果を格納し、モデル管理部がチェック結果を参照する。そして、ステップＳ１５において、各画面部品に対するチェック結果の確認を行い、処理を終了する。
図９（ｂ）は、図９（ａ）のステップＳ１５の処理内容を示すフローである。
まず、ステップＳ１６において、チェック対象となるモデルを確認し、ステップＳ１７において、対象モデルがあるか否かを判断する。ステップＳ１７において、チェック処理を行うプログラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１７において、対象モデルがあると判断された場合（Ｙｅｓの場合）には、ステップＳ１８において、チェック処理を行うプログラム（ここでは、前述の、入力値が正しい形式で入力されているか否かを判断するValidationHandlerというプログラムとしている）があるか否かを判断する。ステップＳ１８において、チェック処理を行うプログラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１８において、チェック処理を行うプログラムがあると判断された場合（Ｙｅｓの場合）には、チェックを行い、ステップＳ１９において、チェックの結果、入力値が正しいか否かにしたがった処理を行って、処理を終了する。この処理は、入力値が正しくないときには、値を赤色で表示し、正しい場合には、黒色で表示するなどである。
まず、ステップＳ１６において、チェック対象となるモデルを確認し、ステップＳ１７において、対象モデルがあるか否かを判断する。ステップＳ１７において、チェック処理を行うプログラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１７において、対象モデルがあると判断された場合（Ｙｅｓの場合）には、ステップＳ１８において、チェック処理を行うプログラム（ここでは、前述の、入力値が正しい形式で入力されているか否かを判断するValidationHandlerというプログラムとしている）があるか否かを判断する。ステップＳ１８において、チェック処理を行うプログラムがないと判断された場合（Ｎｏの場合）には、そのまま処理を終了する。ステップＳ１８において、チェック処理を行うプログラムがあると判断された場合（Ｙｅｓの場合）には、チェックを行い、ステップＳ１９において、チェックの結果、入力値が正しいか否かにしたがった処理を行って、処理を終了する。この処理は、入力値が正しくないときには、値を赤色で表示し、正しい場合には、黒色で表示するなどである。
図１０は、初期化処理時の詳細な処理フローである。
ステップＳ２５とステップＳ２９で示されるループで、ブラウザから読み取られたＨＴＭＬ文の要素全てについて処理を行う。ステップＳ２６において、ＨＴＭＬ文の要素を取得し、ステップＳ２７において、取得されたＨＴＭＬ文の要素が、画面部品であるか否かを判断する。ステップＳ２７の判断がＮｏの場合には、ステップＳ２８に進む。ステップＳ２７の判断がＹｅｓの場合には、ステップＳ３０において、画面部品を作成し、画面部品を画面部品リポジトリに登録して、ステップＳ２９に進む。
ステップＳ２５とステップＳ２９で示されるループで、ブラウザから読み取られたＨＴＭＬ文の要素全てについて処理を行う。ステップＳ２６において、ＨＴＭＬ文の要素を取得し、ステップＳ２７において、取得されたＨＴＭＬ文の要素が、画面部品であるか否かを判断する。ステップＳ２７の判断がＮｏの場合には、ステップＳ２８に進む。ステップＳ２７の判断がＹｅｓの場合には、ステップＳ３０において、画面部品を作成し、画面部品を画面部品リポジトリに登録して、ステップＳ２９に進む。
ステップＳ２８においては、取得されたＨＴＭＬ文の要素がモデル定義タグまたは、命令か否かを判断する。ステップＳ２８の判断がＮｏの場合には、ステップＳ２９に進む。ステップＳ２８の判断がＹｅｓの場合には、ステップＳ３２において、モデルのデータをモデルリポジトリに保存し、ステップＳ３３において、スキーマが指定されているか否かを判断する。ステップＳ３３の判断がＮｏの場合には、ステップＳ２９に進む。ステップＳ３３の判断がＹｅｓの場合には、スキーマのデータをモデルリポジトリに保存して、ステップＳ２９に進む。
なお、ここでは、モデルリポジトリと独立して、画面部品リポジトリが設けられているものとしたが、モデルと画面部品を別々に管理できれば、両方をまとめて、１つのリポジトリとしても良い。
図１１及び図１２は、画面に変更があり、モデルに変更を反映する場合の詳細な処理フローである。
図１１において、まず、ステップＳ３５で、ブラウザ内にイベントが発生したことが検出される。ステップＳ３６において、画面部品がイベントを受信する。ステップＳ３７において、当該イベントによって、入力内容が変更されたか否かを判断する。ステップＳ３７の判断がＮｏの場合には、処理を終了する。ステップＳ３７の判断がＹｅｓの場合には、ステップＳ３８において、値がモデルを指しているか否かを判断する。すなわち、値が、rcf:value = "{model. name}"の形式か否かを判断する。ステップＳ３８の判断がＮｏの場合には、処理を終了する。ステップＳ３８の判断がＹｅｓの場合には、ステップＳ３９において、モデル管理部を呼び出し、モデル管理部の処理が終わったら、処理を終了する。
図１１において、まず、ステップＳ３５で、ブラウザ内にイベントが発生したことが検出される。ステップＳ３６において、画面部品がイベントを受信する。ステップＳ３７において、当該イベントによって、入力内容が変更されたか否かを判断する。ステップＳ３７の判断がＮｏの場合には、処理を終了する。ステップＳ３７の判断がＹｅｓの場合には、ステップＳ３８において、値がモデルを指しているか否かを判断する。すなわち、値が、rcf:value = "{model. name}"の形式か否かを判断する。ステップＳ３８の判断がＮｏの場合には、処理を終了する。ステップＳ３８の判断がＹｅｓの場合には、ステップＳ３９において、モデル管理部を呼び出し、モデル管理部の処理が終わったら、処理を終了する。
図１２は、図１１の処理フロー中のモデル管理部の処理を説明する処理フローである。
ステップＳ４０において、画面部品の設定値を取得する。すなわち、< span ……… rcf:value = "{model. name}">のvalueの部分を取得する。ステップＳ４１において、設定値からモデル名を取得する。たとえば、{model. name}と指定されていたら、modelの部分を取得する。ステップＳ４２において、取得した名前で示されるモデルをモデルリポジトリから取得する。ステップＳ４３において、設定値からプロパティ名を取得する。たとえば、{model. name}と指定されていたら、nameの部分を取得する。ステップＳ４４において、モデルに入力値を設定する。すなわち、画面部品に入力された値をモデルに設定する。
ステップＳ４０において、画面部品の設定値を取得する。すなわち、< span ……… rcf:value = "{model. name}">のvalueの部分を取得する。ステップＳ４１において、設定値からモデル名を取得する。たとえば、{model. name}と指定されていたら、modelの部分を取得する。ステップＳ４２において、取得した名前で示されるモデルをモデルリポジトリから取得する。ステップＳ４３において、設定値からプロパティ名を取得する。たとえば、{model. name}と指定されていたら、nameの部分を取得する。ステップＳ４４において、モデルに入力値を設定する。すなわち、画面部品に入力された値をモデルに設定する。
図１３は、モデルに変更があり、画面に変更を反映する場合の詳細な処理フローである。
ステップＳ４５において、ユーザJavaScript（登録商標）を実行する。ここでは、setPropertyを実行するとしている。この実行により、ステップＳ４６において、モデルの保持する値を更新する。次に、ステップＳ４７からステップＳ５３のループで、画面部品リポジトリに含まれる全ての画面部品について処理を行う。ステップＳ４８では、画面部品を１つ取得する。ステップＳ４９において、画面部品の保持する値がモデルを指しているか否かを判断する。「値がモデルを指す」とは、図１１のステップＳ３８の場合と同じことを意味する。ステップＳ４９の判断がＮｏの場合には、ステップＳ５３に進む。ステップＳ４９の判断がＹｅｓの場合には、ステップＳ５０において、モデルを指している値が更新されたか否かを判断する。ステップＳ５０の判断がＮｏの場合には、ステップＳ５３に進む。ステップＳ５０の判断がＹｅｓの場合には、ステップＳ５１において、画面部品に値を設定し、ステップＳ５２において、画面部品が表示を更新し、ステップＳ５３に進む。ステップＳ４７からステップＳ５３のループで、全ての画面部品について処理が終わったら、処理を終了する。
ステップＳ４５において、ユーザJavaScript（登録商標）を実行する。ここでは、setPropertyを実行するとしている。この実行により、ステップＳ４６において、モデルの保持する値を更新する。次に、ステップＳ４７からステップＳ５３のループで、画面部品リポジトリに含まれる全ての画面部品について処理を行う。ステップＳ４８では、画面部品を１つ取得する。ステップＳ４９において、画面部品の保持する値がモデルを指しているか否かを判断する。「値がモデルを指す」とは、図１１のステップＳ３８の場合と同じことを意味する。ステップＳ４９の判断がＮｏの場合には、ステップＳ５３に進む。ステップＳ４９の判断がＹｅｓの場合には、ステップＳ５０において、モデルを指している値が更新されたか否かを判断する。ステップＳ５０の判断がＮｏの場合には、ステップＳ５３に進む。ステップＳ５０の判断がＹｅｓの場合には、ステップＳ５１において、画面部品に値を設定し、ステップＳ５２において、画面部品が表示を更新し、ステップＳ５３に進む。ステップＳ４７からステップＳ５３のループで、全ての画面部品について処理が終わったら、処理を終了する。
図１４〜図１８は、全体チェックの場合のチェック動作処理を説明する詳細な処理フローである。
図１４において、ステップＳ５５で、ユーザのスクリプトからモデルを指定し、チェックの実行指令を出す。ステップＳ５６において、指定されたモデルをモデルリポジトリから取り出し、ステップＳ５７において、モデルに対応するスキーマが存在するか否かを判断する。ステップＳ５７の判断がＮｏの場合には、処理を終了する。ステップＳ５７の判断がＹｅｓの場合には、ステップＳ５８からステップＳ６６のループで、以下の処理をすべてのモデル内の要素について行う。まず、ステップＳ５９において、モデル内の要素を一つ取り出す。ステップＳ６０において、スキーマに対応する名前が、要素の中にあるか否かを判断する。ステップＳ６０の判断がＮｏの場合には、ステップＳ６６に進む。ステップＳ６０の判断がＹｅｓの場合には、ステップＳ６１において、スキーマ定義を取り出し、ステップＳ６２において、宣言要素を実行する。ステップＳ６３において、結果をチェック結果に格納し、ステップＳ６４において、ロジック要素を実行し、ステップＳ６５において、結果をチェック結果格納部に格納し、ステップＳ６６に進む。ステップＳ５８からステップＳ６６のループで、全てのモデル内要素について処理が終わったら、ステップＳ６７に進む。
図１４において、ステップＳ５５で、ユーザのスクリプトからモデルを指定し、チェックの実行指令を出す。ステップＳ５６において、指定されたモデルをモデルリポジトリから取り出し、ステップＳ５７において、モデルに対応するスキーマが存在するか否かを判断する。ステップＳ５７の判断がＮｏの場合には、処理を終了する。ステップＳ５７の判断がＹｅｓの場合には、ステップＳ５８からステップＳ６６のループで、以下の処理をすべてのモデル内の要素について行う。まず、ステップＳ５９において、モデル内の要素を一つ取り出す。ステップＳ６０において、スキーマに対応する名前が、要素の中にあるか否かを判断する。ステップＳ６０の判断がＮｏの場合には、ステップＳ６６に進む。ステップＳ６０の判断がＹｅｓの場合には、ステップＳ６１において、スキーマ定義を取り出し、ステップＳ６２において、宣言要素を実行する。ステップＳ６３において、結果をチェック結果に格納し、ステップＳ６４において、ロジック要素を実行し、ステップＳ６５において、結果をチェック結果格納部に格納し、ステップＳ６６に進む。ステップＳ５８からステップＳ６６のループで、全てのモデル内要素について処理が終わったら、ステップＳ６７に進む。
ステップＳ６７からステップＳ７０のループでは、画面部品リポジトリに格納されている画面部品全てについて以下の処理を行う。まず、ステップＳ６８において、画面部品を取り出し、ステップＳ６９において、画面部品にチェック結果を反映し、ステップＳ７０に進む。ステップＳ６７からステップＳ７０のループで、画面部品リポジトリに格納されている全ての画面部品について処理が終わると、全体の処理を終了する。
図１５は、図１４のステップＳ６２の詳細フローである。
宣言要素を実行する場合には、ステップＳ７１において、モデルの値を取り出し、ステップＳ７２で値が、たとえば、整数か否かを判断する。これは、type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ７２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であったことを返す。
宣言要素を実行する場合には、ステップＳ７１において、モデルの値を取り出し、ステップＳ７２で値が、たとえば、整数か否かを判断する。これは、type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ７２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であったことを返す。
図１６は、図１４のステップＳ６４の詳細フローである。
ロジック要素を実行する場合、ステップＳ７３において、モデルの値を取り出し、ステップＳ７４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。
ロジック要素を実行する場合、ステップＳ７３において、モデルの値を取り出し、ステップＳ７４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。
図１７は、図１４のステップＳ６７の詳細フローである。
画面部品に変更を反映する場合、ステップＳ７５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３のステップＳ４９と同じである。ステップＳ７５の判断がＮｏの場合には、処理を終了する。ステップＳ７５の判断がＹｅｓの場合には、ステップＳ７６において、アクション部品（機能部品）があるか否かを判断する。ステップＳ７６の判断がＮｏの場合には、処理を終了する。ステップＳ７６の判断がＹｅｓの場合には、ステップＳ７７において、アクション部品を呼び出し、実行して処理を終了する。
画面部品に変更を反映する場合、ステップＳ７５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３のステップＳ４９と同じである。ステップＳ７５の判断がＮｏの場合には、処理を終了する。ステップＳ７５の判断がＹｅｓの場合には、ステップＳ７６において、アクション部品（機能部品）があるか否かを判断する。ステップＳ７６の判断がＮｏの場合には、処理を終了する。ステップＳ７６の判断がＹｅｓの場合には、ステップＳ７７において、アクション部品を呼び出し、実行して処理を終了する。
図１８は、図１７のステップＳ７７の詳細フローである。
アクション部品を呼び出し、実行する場合、ステップＳ７８において、チェックは成功したか否かを判断する。ステップＳ７８の判断がＹｅｓの場合には、ステップＳ７９に進
み、success属性があるか否かを判断する。ステップＳ７９の判断がＮｏの場合には、処理を終了する。ステップＳ７９の判断がＹｅｓの場合には、ステップＳ８０において、success属性の中身を実行して、処理を終了する。
アクション部品を呼び出し、実行する場合、ステップＳ７８において、チェックは成功したか否かを判断する。ステップＳ７８の判断がＹｅｓの場合には、ステップＳ７９に進
み、success属性があるか否かを判断する。ステップＳ７９の判断がＮｏの場合には、処理を終了する。ステップＳ７９の判断がＹｅｓの場合には、ステップＳ８０において、success属性の中身を実行して、処理を終了する。
ステップＳ７８の判断がＮｏの場合には、ステップＳ８１において、failed属性はあるか否かを判断する。ステップＳ８１の判断がＮｏの場合には、処理を終了する。ステップＳ８１の判断がＹｅｓの場合には、ステップＳ８２において、failed属性の中身を実行して、処理を終了する。
図１９〜図２４は、単一チェック動作時のチェック動作処理を説明する詳細な処理フローである。
図１９において、まず、ステップＳ９０で、ブラウザからイベントが発生すると、ステップＳ９１において、画面部品がイベントを受信し、ステップＳ９２において、画面部品がモデルを指しているか否かを判断する。ここの判断は、画面部品がバインディングで関連付けられたモデルを有しているか否かの判断である。ステップＳ９２の判断がＮｏの場合には、処理を終了する。ステップＳ９２の判断がＹｅｓの場合には、ステップＳ９３において、アクション部品が存在するか否かを判断する。ステップＳ９３の判断がＮｏの場合には、処理を終了する。ステップＳ９３の判断がＹｅｓの場合には、ステップＳ９４において、event属性が存在するか否かを判断する。ステップＳ９４の判断がＮｏの場合には、処理を終了する。ステップＳ９４の判断がＹｅｓの場合には、ステップＳ９５において、チェック対象イベントか否かを判断する。ステップＳ９５の判断がＮｏの場合には、処理を終了する。ステップＳ９５の判断がＹｅｓの場合には、ステップＳ９６において、チェックを実行し、処理を終了する。
図１９において、まず、ステップＳ９０で、ブラウザからイベントが発生すると、ステップＳ９１において、画面部品がイベントを受信し、ステップＳ９２において、画面部品がモデルを指しているか否かを判断する。ここの判断は、画面部品がバインディングで関連付けられたモデルを有しているか否かの判断である。ステップＳ９２の判断がＮｏの場合には、処理を終了する。ステップＳ９２の判断がＹｅｓの場合には、ステップＳ９３において、アクション部品が存在するか否かを判断する。ステップＳ９３の判断がＮｏの場合には、処理を終了する。ステップＳ９３の判断がＹｅｓの場合には、ステップＳ９４において、event属性が存在するか否かを判断する。ステップＳ９４の判断がＮｏの場合には、処理を終了する。ステップＳ９４の判断がＹｅｓの場合には、ステップＳ９５において、チェック対象イベントか否かを判断する。ステップＳ９５の判断がＮｏの場合には、処理を終了する。ステップＳ９５の判断がＹｅｓの場合には、ステップＳ９６において、チェックを実行し、処理を終了する。
図２０は、図１９のステップＳ９６の詳細フローである。
ステップＳ９７において、モデルリポジトリから対象モデルを取り出し、ステップＳ９８において、モデルに対応するスキーマが存在するか否かを判断する。ステップＳ９８の判断がＮｏの場合には、処理を終了する。ステップＳ９８の判断がＹｅｓの場合には、ステップＳ９９において、画面部品に指定された、モデルの要素を取り出す。ステップＳ１００において、スキーマに対応する名前があるか否かを判断する。ステップＳ１００の判断がＮｏの場合には、処理を終了する。ステップＳ１００の判断がＹｅｓの場合には、ステップＳ１０１において、スキーマ定義を取り出し、ステップＳ１０２において、宣言要素を実行し、ステップＳ１０３において、結果をチェック結果格納部に格納する。ステップＳ１０４において、ロジック要素を実行し、ステップＳ１０５において、結果をチェック結果格納部に格納する。ステップｓ１０６では、画面部品に反映し、処理を終了する。
ステップＳ９７において、モデルリポジトリから対象モデルを取り出し、ステップＳ９８において、モデルに対応するスキーマが存在するか否かを判断する。ステップＳ９８の判断がＮｏの場合には、処理を終了する。ステップＳ９８の判断がＹｅｓの場合には、ステップＳ９９において、画面部品に指定された、モデルの要素を取り出す。ステップＳ１００において、スキーマに対応する名前があるか否かを判断する。ステップＳ１００の判断がＮｏの場合には、処理を終了する。ステップＳ１００の判断がＹｅｓの場合には、ステップＳ１０１において、スキーマ定義を取り出し、ステップＳ１０２において、宣言要素を実行し、ステップＳ１０３において、結果をチェック結果格納部に格納する。ステップＳ１０４において、ロジック要素を実行し、ステップＳ１０５において、結果をチェック結果格納部に格納する。ステップｓ１０６では、画面部品に反映し、処理を終了する。
図２１は、図２０のステップＳ１０２の詳細フローである。
宣言要素を実行する場合には、ステップＳ２０１において、モデルの値を取り出し、ステップＳ２０２で値が、たとえば、整数か否かを判断する。これは、type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ２０２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であったことを返す。
宣言要素を実行する場合には、ステップＳ２０１において、モデルの値を取り出し、ステップＳ２０２で値が、たとえば、整数か否かを判断する。これは、type: integerの場合である。そのほかにも、性質に応じてさまざまなチェックが出来る。たとえば、type: zenkakuでは、全角文字列か否かを判断する。maxLength: 12では、１２文字以下か否かを判断する。そして、ステップＳ２０２の判断がＮｏのときは、エラーを返し、Ｙｅｓのときは、チェックの結果が成功であったことを返す。
図２２は、図２０のステップＳ１０４の詳細フローである。
ロジック要素を実行する場合、ステップＳ２０３において、モデルの値を取り出し、ステップＳ２０４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。
ロジック要素を実行する場合、ステップＳ２０３において、モデルの値を取り出し、ステップＳ２０４において、モデルの値を引数にチェック関数を実行する。そして、チェック関数の返り値を図１４のフローに返す。チェック関数は、返り値として、成功か失敗かを示す値を返す。
図２３は、図２０のステップＳ１０６の詳細フローである。
画面部品に変更を反映する場合、ステップＳ２０５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３のステップＳ４９と同じである。ステップＳ２０５の判断がＮｏの場合には、処理を終了する。ステップＳ２０５の判断がＹｅｓの場合には、ステップＳ２０６において、アクション部品（機能部品）があるか否かを判断する。ステップＳ２０６の判断がＮｏの場合には、処理を終了する。ステップＳ２０６の判断がＹｅｓの場合には、ステップＳ２０７において、アクション部品を呼び出し、実行して処理を終了する。
画面部品に変更を反映する場合、ステップＳ２０５において、値はモデルを指しているか否かを判断する。ここの判断は、図１３のステップＳ４９と同じである。ステップＳ２０５の判断がＮｏの場合には、処理を終了する。ステップＳ２０５の判断がＹｅｓの場合には、ステップＳ２０６において、アクション部品（機能部品）があるか否かを判断する。ステップＳ２０６の判断がＮｏの場合には、処理を終了する。ステップＳ２０６の判断がＹｅｓの場合には、ステップＳ２０７において、アクション部品を呼び出し、実行して処理を終了する。
図２４は、図２３のステップＳ２０７の詳細フローである。
アクション部品を呼び出し、実行する場合、ステップＳ２０８において、チェックは成功したか否かを判断する。ステップＳ２０８の判断がＹｅｓの場合には、ステップＳ２０９に進み、success属性があるか否かを判断する。ステップＳ２０９の判断がＮｏの場合には、処理を終了する。ステップＳ２０９の判断がＹｅｓの場合には、ステップＳ２１０において、success属性の中身を実行して、処理を終了する。
アクション部品を呼び出し、実行する場合、ステップＳ２０８において、チェックは成功したか否かを判断する。ステップＳ２０８の判断がＹｅｓの場合には、ステップＳ２０９に進み、success属性があるか否かを判断する。ステップＳ２０９の判断がＮｏの場合には、処理を終了する。ステップＳ２０９の判断がＹｅｓの場合には、ステップＳ２１０において、success属性の中身を実行して、処理を終了する。
ステップＳ２０８の判断がＮｏの場合には、ステップＳ２１１において、failed属性はあるか否かを判断する。ステップＳ２１１の判断がＮｏの場合には、処理を終了する。ステップＳ２１１の判断がＹｅｓの場合には、ステップＳ２１２において、failed属性の中身を実行して、処理を終了する。
１０ ＨＴＭＬ、画面部品タグ、外部チェックスクリプト
１１ フレームワーク
１２ 画面部品（チェック機能付き）
１３ ＨＴＭＬ解析、部品作成器
１５、３５ ＨＴＭＬ ＤＯＭ（ブラウザ内部）
１６ 画面部品
１７ 外部チェックスクリプト
１８ イベント解析部
１９ 内部チェック部
２０ 外部チェック部
２１ 画面更新部
２５ ＨＴＭＬ、画面部品タグ、機能部品タグ、モデル、スキーマ定義
２６ 画面部品
２７ 機能部品
２８ ＨＴＭＬ解析、部品作成器
２９ モデル管理部
３０ モデルリポジトリ
３１ フレームワーク
３６ モデル
３７ スキーマ
３８ チェック結果格納部
４０ ユーザJavaScript
１１ フレームワーク
１２ 画面部品（チェック機能付き）
１３ ＨＴＭＬ解析、部品作成器
１５、３５ ＨＴＭＬ ＤＯＭ（ブラウザ内部）
１６ 画面部品
１７ 外部チェックスクリプト
１８ イベント解析部
１９ 内部チェック部
２０ 外部チェック部
２１ 画面更新部
２５ ＨＴＭＬ、画面部品タグ、機能部品タグ、モデル、スキーマ定義
２６ 画面部品
２７ 機能部品
２８ ＨＴＭＬ解析、部品作成器
２９ モデル管理部
３０ モデルリポジトリ
３１ フレームワーク
３６ モデル
３７ スキーマ
３８ チェック結果格納部
４０ ユーザJavaScript
Claims (5)
- 非オブジェクト指向言語による記述によって表示画面を構成する表示画面構成装置をコンピュータに実現させるプログラムであって、
表示画面を表示し、該表示画面からのユーザのイベント入力を受け付け、該イベント入力の内部処理を行って、表示画面に内部処理結果を反映した表示を行うビュー手段と、
該ビュー手段とは別個に設けられて、該ビュー手段とバインディング機能により関連付けられ、該ビュー手段を介して受け付けたイベント入力の外部処理を行い、外部処理結果を該ビュー手段に渡して表示画面に反映させるモデル手段と、
該モデル手段が受け付けたイベント入力による入力値が所定の条件を満たしているか否かを検査し、その結果を該モデル手段の外部処理結果として、表示画面に反映させるスキーマ手段と、
を備える機能をコンピュータに実現させるプログラム。 - 前記非オブジェクト指向言語は、JavaScriptであることを特徴とする請求項１に記載のプログラム。
- 前記イベント入力は、テキスト入力であり、
前記スキーマ手段は、前記モデル手段が担当する全ての入力テキストが所定の条件を満たしているか否かを検査することを特徴とする請求項１に記載のプログラム。 - 前記イベント入力は、テキスト入力であり、
前記スキーマ手段は、前記モデル手段が担当する入力テキストの内、イベントが発生したテキストについてのみ、該テキストが所定の条件を満たしているか否かを判断することを特徴とする請求項１に記載のプログラム。 - 非オブジェクト指向言語による記述によって表示画面を構成する表示画面構成装置であって、
表示画面を表示し、該表示画面からのユーザのイベント入力を受け付け、該イベント入力の内部処理を行って、表示画面に内部処理結果を反映した表示を行うビュー手段と、
該ビュー手段とは別個に設けられて、該ビュー手段とバインディング機能により関連付けられ、該ビュー手段を介して受け付けたイベント入力の外部処理を行い、外部処理結果を該ビュー手段に渡して表示画面に反映させるモデル手段と、
該モデル手段が受け付けたイベント入力による入力値が所定の条件を満たしているか否かを検査し、その結果を該モデル手段の外部処理結果として、表示画面に反映させるスキーマ手段と、
を備えることを特徴とする表示画面構成装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007005170A JP2008171281A (ja) | 2007-01-12 | 2007-01-12 | 表示画面構成装置 |
| US12/013,020 US8127234B2 (en) | 2007-01-12 | 2008-01-11 | Display screen structuring apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007005170A JP2008171281A (ja) | 2007-01-12 | 2007-01-12 | 表示画面構成装置 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010180089A Division JP5537330B2 (ja) | 2010-08-11 | 2010-08-11 | 表示画面構成装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2008171281A true JP2008171281A (ja) | 2008-07-24 |
Family
ID=39618714
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007005170A Pending JP2008171281A (ja) | 2007-01-12 | 2007-01-12 | 表示画面構成装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8127234B2 (ja) |
| JP (1) | JP2008171281A (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4185159B1 (ja) * | 2008-01-30 | 2008-11-26 | 株式会社三菱東京Ｕｆｊ銀行 | アプリケーション開発支援装置及びプログラム |
| US11003464B2 (en) * | 2012-04-19 | 2021-05-11 | Microsoft Technology Licensing, Llc | Control flow integrity enforcement at scale |
| US9342323B2 (en) * | 2012-08-09 | 2016-05-17 | Google Inc. | Browser-level background page for providing multiple views |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002215394A (ja) * | 2000-08-15 | 2002-08-02 | Fujitsu Ltd | Ｗｅｂアプリケーション開発・実行システム及びＷｅｂアプリケーション生成装置 |
| US20030226115A1 (en) * | 2002-06-03 | 2003-12-04 | Wall Peter M. | Input field constraint mechanism |
| JP2004318848A (ja) * | 2003-03-28 | 2004-11-11 | Daiwa Securities Group Inc | 画面自動生成装置、画面自動生成方法、画面自動生成プログラム、記録媒体、実行装置、ファイル編集装置、ファイル編集方法およびファイル編集プログラム |
| JP2006260540A (ja) * | 2005-03-15 | 2006-09-28 | Microsoft Corp | データバインドされたリッチなアプリケーション |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002214394A (ja) | 2001-01-19 | 2002-07-31 | Shimizu Corp | 地層処分施設とその施工法 |
| JP2003150290A (ja) | 2001-11-16 | 2003-05-23 | Higashi Nippon System Kensetsu Kk | データ管理システム |
| US7953767B2 (en) * | 2004-10-05 | 2011-05-31 | Sap Ag | Developing applications using configurable patterns |
| US20070283273A1 (en) * | 2005-10-24 | 2007-12-06 | Woods Michael E | System, Method, and Computer Program Product for Internet Tool |
| US20070124278A1 (en) * | 2005-10-31 | 2007-05-31 | Biogen Idec Ma Inc. | System and method for electronic record keeping |
| US7890957B2 (en) * | 2006-09-08 | 2011-02-15 | Easyonme, Inc. | Remote management of an electronic presence |
| US20080065974A1 (en) * | 2006-09-08 | 2008-03-13 | Tom Campbell | Template-based electronic presence management |
| JP4961949B2 (ja) * | 2006-10-30 | 2012-06-27 | 富士通株式会社 | 生成プログラム、検査プログラム、生成装置、および生成方法 |
| US8341595B2 (en) * | 2007-05-30 | 2012-12-25 | Roam Data Inc | System and method for developing rich internet applications for remote computing devices |
| US7917584B2 (en) * | 2007-10-22 | 2011-03-29 | Xcerion Aktiebolag | Gesture-based collaboration |
-
2007
- 2007-01-12 JP JP2007005170A patent/JP2008171281A/ja active Pending
-
2008
- 2008-01-11 US US12/013,020 patent/US8127234B2/en not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002215394A (ja) * | 2000-08-15 | 2002-08-02 | Fujitsu Ltd | Ｗｅｂアプリケーション開発・実行システム及びＷｅｂアプリケーション生成装置 |
| US20030226115A1 (en) * | 2002-06-03 | 2003-12-04 | Wall Peter M. | Input field constraint mechanism |
| JP2004318848A (ja) * | 2003-03-28 | 2004-11-11 | Daiwa Securities Group Inc | 画面自動生成装置、画面自動生成方法、画面自動生成プログラム、記録媒体、実行装置、ファイル編集装置、ファイル編集方法およびファイル編集プログラム |
| JP2006260540A (ja) * | 2005-03-15 | 2006-09-28 | Microsoft Corp | データバインドされたリッチなアプリケーション |
Also Published As
| Publication number | Publication date |
|---|---|
| US8127234B2 (en) | 2012-02-28 |
| US20080172624A1 (en) | 2008-07-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Mann | Java Server Faces in Action | |
| US10977054B2 (en) | Method and system for providing and executing web applications with runtime interpreter | |
| EP1901179A1 (en) | Document processing device, and document processing method | |
| Nelson | Getting to know Vue. js | |
| WO2002023336A1 (en) | Xml-based graphical user interface application development toolkit | |
| US9032363B2 (en) | Providing a user interface library for building web-based applications | |
| US20210200560A1 (en) | Enhanced Target Selection for Robotic Process Automation | |
| JP4814801B2 (ja) | 表示画面構成装置 | |
| JP2008171281A (ja) | 表示画面構成装置 | |
| Penberthy | Beginning ASP. NET for Visual Studio 2015 | |
| Kumpulainen | Web application development with Vue. js | |
| JP5537330B2 (ja) | 表示画面構成装置 | |
| US20230060787A1 (en) | System and Method for Real-Time, Dynamic Creation, Delivery, and Use of Customizable Web Applications | |
| Bretet | Spring mvc cookbook | |
| Derks | React Projects: Build 12 real-world applications from scratch using React, React Native, and React 360 | |
| Lim | Beginning Angular 2 with Typescript | |
| Ferguson et al. | JavaScript and Application Frameworks: Angular | |
| Subramanian et al. | React-bootstrap | |
| Abbruzzese | Hands-On TypeScript for C# and. NET Core Developers: Transition from C# to TypeScript 3.1 and build applications with ASP. NET Core 2 | |
| Stäuble et al. | ZK Developer's Guide | |
| Steyer | Behind the Scenes: How and Why Does Vue. js Work? | |
| Mason | SAS Stored Processes | |
| Ganatra | Kendo UI Cookbook | |
| Han et al. | Practice and evaluation of pagelet-based client-side rendering mechanism | |
| Patel | Sitecore Cookbook for Developers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081205 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090501 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090602 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090731 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100511 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100811 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20100818 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20101029 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120206 |