(57)【特許請求の範囲】
【請求項１】
所定のプラットフォームに依存した画面フォームを持つ通常のアプリケーションとHTMLで記述される画面フォームを持つWebアプリケーションとが混在するシステムに対して入力検証を実装して実行する入力検証実装方法であって、
検証情報一覧に格納された検証項目と１対１で紐付けられた検証ユニットを生成する工程であって、与えられた入力値に対して前記検証項目で定義される検証処理を前記システムを構成するコンピュータに実行させるためのプログラム要素である前記検証ユニットを生成する工程と、
前記システムを構成するコンピュータが前記通常のアプリケーションの検証制御部を実行することにより入力検証を行う際に、前記通常のアプリケーションの画面フォームにおいて検証すべき入力コントロールに対応する前記検証ユニットを特定し、前記特定した検証ユニットを実行することにより、前記入力コントロールの入力値に対して当該検証ユニットに紐付けられた検証項目で定義される検証処理を実行する工程と、
前記システムを構成するコンピュータが前記Webアプリケーションのサーバサイドの検証制御部を実行することにより入力検証を行う際に、前記Webアプリケーションの画面フォームにおいて検証すべき入力コントロールに対応する前記検証ユニットを特定し、前記特定した検証ユニットを実行することにより、前記入力コントロールの入力値に対して当該検証ユニットに紐付けられた検証項目で定義される検証処理を実行する工程と、
を備えることにより、
入力コントロールの入力値の検証処理をアプリケーション形態に関わらず統一したことを特徴とする入力検証実装方法。
【請求項２】
請求項１に記載の入力検証実装方法において、
前記システムを構成するサーバサイドのコンピュータが、前記Webアプリケーションの検証制御部を実行することにより、クライアントサイドで検証を行わせるための検証制御スクリプトを作成し、画面制御メインを実行することにより、前記検証制御スクリプトとバリデータスクリプトをHTMLに埋め込んでクライアントサイドのコンピュータに送信する工程と、
前記システムを構成するクライアントサイドのコンピュータがブラウザ及び前記検証制御スクリプトを実行することにより、検証すべき入力コントロールに対して前記バリデータスクリプトを実行して、前記入力コントロールの入力値の検証を行う工程と
を備えることにより、
Webアプリケーションにおけるクライアントサイドとサーバサイドの双方の入力検証をサポートしたことを特徴とする入力検証実装方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばWindows（登録商標）アプリケーションとWebアプリケーションが混在するシステム開発において、アプリケーション形態に依存しない統一された入力検証方式を提供する技術に関するものである。
【背景技術】
【０００２】
大規模なソフトウェア開発プロジェクトでは、WindowsアプリケーションやWebアプリケーションなど、１つのプロジェクト内に複数の、しかも異なる形態のアプリケーションが存在しうる。アプリケーション開発では、生産性と保守性を高めるために、プログラム構造をユーザーインターフェース層、ビジネスロジック層、およびデータアクセス層の３層に分離する方式が一般的になっている。このような３層構造において、ビジネスロジック層およびデータアクセス層は、アプリケーション形態の影響を受けにくいため、アプリケーション形態非依存の共通のロジックを作成しやすい。
【０００３】
しかし、ユーザーインターフェース層については、Windowsアプリケーションでは開発プラットフォームに依存した画面フォームであり、一方、WebアプリケーションではHTMLに相当することから、同じ開発プラットフォームにおいてもWindowsアプリケーションとWebアプリケーションとでは使用する入力コントロールが全く異なり、異形態アプリケーション間で共通の処理を作成するのが困難である。なお、入力コントロールとは、テキストボックスやコンボボックスなど、ユーザが任意のデータを入力できるユーザインターフェースの要素である。
【０００４】
特に、ユーザーインターフェース層で実装する処理のうち多くの比率を占める入力検証に着目すると、検証内容の変更が発生する度に、アプリケーションごとに入力コントロールの入力検証処理を修正する必要があり、高い生産性と保守性を実現するのが困難である。
【０００５】
入力検証処理の効率化を実現しているクラスとして、例えば、.NET Frameworkのバリデータ・コントロールがある。Webアプリケーションの入力検証は、一般にクライアントサイド(ブラウザでのJavaScriptなどによるチェック)およびサーバサイド（サーバでのHTTP要求受信時のチェック）の双方で実施する。クライアントサイドのみのチェックではアプリケーションが提供するHTML以外からのHTTP要求に対する入力検証が行えず、一方、サーバサイドのみのチェックではサーバがHTTP要求を受信してからのチェックとなるため、性能上問題があるためである。
【０００６】
.NET Frameworkのバリデータ・コントロールは、Webアプリケーション開発のための入力コントロールであり、コントロールのプロパティに桁数や正規表現などの検証情報を設定することで、アプリケーション動作時にクライアントサイドおよびサーバサイドの双方で入力検証を行う。つまり、開発者は、クライアントサイドとサーバサイドの検証処理を別々に実装する従来の方式と比べて、より少ない工数で検証処理を実装できる。
【０００７】
なお、Webフォームにおいて検証データを用意して入力検証を行う従来技術として、下記特許文献１〜３のようなものがある。
【特許文献１】特開平６−２７４３８９号公報
【特許文献２】特開平１１−２０３１１７号公報
【特許文献３】特開２００６−６７２１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、前記.NET Frameworkのバリデータ・コントロールはWebアプリケーション用のコントロールであり、Windowsアプリケーションのコントロールとしては提供されていない。したがって、WindowsアプリケーションとWebアプリケーションが混在するようなプロジェクトにおいて、Webアプリケーションでこのバリデータ・コントロールを使用すると、Windowsアプリケーションとの入力検証処理の共通化を図ることができない。その結果、同じ検証内容であるにも関わらず、WindowsアプリケーションとWebアプリケーションとで異なる検証処理が実装され、メンテナンスが発生した際の開発担当者の負荷が過大なもとのとなる可能性がある。
【０００９】
また、.NET FrameworkのWebアプリケーションにおいても、バリデータはグリッドコントロールのセルの入力検証に適用することはできない（なお、グリッドコントロールとは任意の数の行と列で構成される入力コントロールを指す）。したがって、グリッドコントロールを含む画面の検証処理の実装は、バリデータを使用する通常のコントロールの実装とは全く異なる記述となってしまう。
【００１０】
本発明は、クライアントサイドとサーバサイドの双方で入力検証を行うという.NET Frameworkバリデータの利点を損なわず、例えばWindowsアプリケーションとWebアプリケーションとで統一化された入力検証方式を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するため、本発明は、クライアントサイドとサーバサイドの双方で入力検証を行うという.NET Frameworkバリデータの利点を損なわず、例えばWindowsアプリケーションとWebアプリケーションで統一化された入力検証方式を提供することを特徴とする。また、提案するコントロールは、グリッドコントロール内セルの入力検証にも適用できる方式とすることを特徴とする。これにより、開発者が入力検証処理を実装する負担をさらに軽減できる。
【００１２】
すなわち、請求項１に係る発明は、所定のプラットフォームに依存した画面フォームを持つ通常のアプリケーションとHTMLで記述される画面フォームを持つWebアプリケーションとが混在するシステムに対して入力検証を実装して実行する入力検証実装方法であって、検証情報一覧に格納された検証項目と１対１で紐付けられた検証ユニットを生成する工程であって、与えられた入力値に対して前記検証項目で定義される検証処理を前記システムを構成するコンピュータに実行させるためのプログラム要素である前記検証ユニットを生成する工程と、前記システムを構成するコンピュータが前記通常のアプリケーションの検証制御部を実行することにより入力検証を行う際に、前記通常のアプリケーションの画面フォームにおいて検証すべき入力コントロールに対応する前記検証ユニットを特定し、前記特定した検証ユニットを実行することにより、前記入力コントロールの入力値に対して当該検証ユニットに紐付けられた検証項目で定義される検証処理を実行する工程と、前記システムを構成するコンピュータが前記Webアプリケーションのサーバサイドの検証制御部を実行することにより入力検証を行う際に、前記Webアプリケーションの画面フォームにおいて検証すべき入力コントロールに対応する前記検証ユニットを特定し、前記特定した検証ユニットを実行することにより、前記入力コントロールの入力値に対して当該検証ユニットに紐付けられた検証項目で定義される検証処理を実行する工程と、を備えることにより、入力コントロールの入力値の検証処理をアプリケーション形態に関わらず統一したことを特徴とする。
【００１３】
請求項２に係る発明は、請求項１に記載の入力検証実装方法において、前記システムを構成するサーバサイドのコンピュータが、前記Webアプリケーションの検証制御部を実行することにより、クライアントサイドで検証を行わせるための検証制御スクリプトを作成し、画面制御メインを実行することにより、前記検証制御スクリプトとバリデータスクリプトをHTMLに埋め込んでクライアントサイドのコンピュータに送信する工程と、前記システムを構成するクライアントサイドのコンピュータがブラウザ及び前記検証制御スクリプトを実行することにより、検証すべき入力コントロールに対して前記バリデータスクリプトを実行して、前記入力コントロールの入力値の検証を行う工程とを備えることにより、Webアプリケーションにおけるクライアントサイドとサーバサイドの双方の入力検証をサポートしたことを特徴とする。
【発明の効果】
【００１５】
本発明によれば、ユーザーの入力内容を検証するための記述がアプリケーション形態に依存しないため、異なるアプリケーション形態が混在するプロジェクトにおいても、可読性の高いプログラムを記述することができる。また、入力検証の実装方式が統一されることから開発者が遵守しやすいコーディングルールの規定が容易になる。また、この方式ではグリッドコントロール内セルにも一般的なコントロールと同様の入力検証方式を適用可能とするため、さらに統一化された入力検証の実装が可能となる。その結果、本発明により、生産性と保守性の高いユーザーインターフェース層の実装方式が開発者に提供される。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の一実施の形態に係る入力検証実装方式について、図面に基づき説明する。ここでは例として、Windowsアプリケーションは C#.NET による開発、WebアプリケーションはASP.NET(C#.NET)による開発とする。
【００１７】
図１は、本実施の形態に係る入力検証実装方式１００の概略構成を示している。
【００１８】
バリデータクラス１０１は、検証エンジンとしての機能を実装したクラスである。また、検証対象のコントロールに依存しない汎用クラスであり、他のシステム開発においても再利用できるクラスとする。
【００１９】
バリデータスクリプト１０２は、バリデータクラス１０１と同機能の検証エンジンを実装した汎用的な検証スクリプト関数群である。スクリプト言語は、ASP.NETではJScriptあるいはVBScriptの使用が可能であり、ここではJScriptによるソースコードで説明する。
【００２０】
検証情報一覧１０３の実体はExcelシートである。定義内容は、例えば「顧客番号は、正規表現バリデータで半角数字５桁の検証を行う」など、データ項目に対して、検証に適用するバリデータと個別情報（前記例では半角数字５桁）を定義する。画面の入力項目は一般的にシステムで利用するデータベースのテーブル定義とリンクするため、検証情報一覧１０３はシステムで利用するデータベースのテーブル定義を基に作成する。
【００２１】
検証ユニット１０４は、検証情報一覧１０３のExcelシートに対してマクロを実行することで生成されるソースコードであり、実体はバリデータクラス１０１にデータ項目個別の情報を設定したバリデータクラス・インスタンスである。検証情報一覧１０３の検証項目と検証ユニット１０４は、原則として１：１で紐付く。
【００２２】
WindowsアプリケーションおよびWebアプリケーションの画面制御メイン１１１は、共にユーザーから要求された処理のフロー制御を行う。画面制御メイン１１１は一般的に画面と１：１で紐付く。WindowsアプリケーションおよびWebアプリケーションの検証情報定義部１１２は、共に検証情報を格納する。検証情報とは「顧客番号コントロール―顧客番号検証ユニット」のように、入力コントロールと、その検証に使用する検証ユニット１０４との紐付けである。WindowsアプリケーションおよびWebアプリケーションの検証制御部１１３は、共に検証情報定義部１１２の検証情報に基づいて検証処理を行う。
【００２３】
以上のように構成された入力検証実装方式１００で行う入力検証処理の概要について説明する。
【００２４】
図２に、Windowsアプリケーションにおける入力検証処理シーケンスを示す。
【００２５】
画面１１０におけるボタン押下等を契機として、画面制御メイン１１１が起動される（ステップ１００１１）。画面制御メイン１１１は、検証制御部１１３に入力検証を依頼する（ステップ１００１２）。検証制御部１１３では、検証すべき入力コントロールに対して、検証情報定義部１１２から該当する検証ユニット１０４を特定し、その検証ユニット１０４に入力値を渡して検証を依頼する（ステップ１００１３）。検証ユニット１０４では、実際に入力値を検証し、検証結果として正常／エラーを検証制御部１１３に返却する（ステップ１００１４）。異常の場合は、検証ユニット１０４に定義されているエラーメッセージを画面に表示する（ステップ１００１５）。このように、検証制御部１１３は、検証すべき入力コントロールに対して検証を行い、検証結果が全て正常だった場合に限り、画面制御メイン１１１に「正常」を返却する（ステップ１００１６）。
【００２６】
図３に、Webアプリケーションにおける入力検証処理シーケンスを示す。
【００２７】
Webアプリケーションでは、前記の検証制御部１１３で入力検証に加えてクライアントサイドの検証処理を実装する必要がある。画面制御メイン１１１は、まずクライアントのブラウザからHTTP要求（URL）を受信する（ステップ１００２１）。要求を受信した画面制御メイン１１１は、ブラウザに表示するためのHTMLを作成する。このとき画面制御メイン１１１は、検証制御部１１３に対してクライアントサイドで検証を行うための検証制御スクリプト１１４を要求する（ステップ１００２２）。検証制御部１１３は、検証情報定義部１１２の検証情報に基づいて検証制御スクリプトを作成し、画面制御メイン１１１に返却する（ステップ１００２３）。画面制御メイン１１１は、その検証制御スクリプトとバリデータスクリプト１０２をHTMLに埋め込んでブラウザに送信する（ステップ１００２４）。
【００２８】
ブラウザでのボタン押下等を契機として、WebサーバにHTTP要求が送られる前に、HTMLに埋め込まれた検証制御スクリプト１１４が起動される（ステップ１００２５）。検証制御スクリプト１１４では、検証すべき入力コントロールに対して、バリデータスクリプト１０２に入力値を渡して検証を依頼する（ステップ１００２６）。バリデータスクリプト１０２では、実際に入力値を検証し、検証結果として正常／エラーを検証制御スクリプト１１４に返却する（ステップ１００２７）。異常が返却された場合は、検証ユニットに定義されているエラーメッセージ情報をブラウザに表示する（ステップ１００２８）。このように、検証制御スクリプト１１４は、検証すべき入力コントロールに対して検証を行い、検証結果が全て正常だった場合に限り、ユーザー要求をWebサーバつまり画面制御メイン１１１に送信する（ステップ１００２９）。
【００２９】
その後の処理（ステップ１００２Ａ〜１００２Ｅ）では、Windowsアプリケーションのステップ１００１２〜１００１６と同様の入力検証処理を行う。
【００３０】
検証制御部１１３について、WebアプリケーションとWindowsアプリケーションとでは、アプリケーション形態の違いからエラーメッセージ表示処理の実装が異なるものの、入力値に対する検証結果を出力するまでの処理は同様の記述が可能である。検証ユニット１０４を生成する生成マクロ、バリデータクラス１０１、およびバリデータスクリプト１０２は、汎用的なコンポーネントとして他のシステム開発で再利用可能である。画面制御メイン１１１における入力検証関連処理および検証制御部１１３についても、画面クラスの親クラスに実装するなど、共通化を行いやすい。検証情報一覧１０３は、システムで１人メンテナンスする担当者を割り当てるのが好ましい。
【００３１】
以上により、各画面の開発担当者が検証情報定義部１１２の作成に専念できるような開発体制とすることが可能となる。
【００３２】
以下、本実施の形態に係る入力検証実装方式１００の詳細について説明する。
【００３３】
図４は、バリデータクラス１０１の構成を示す静的クラス図である。バリデータクラス１０１は、検証する種別ごとに、入力必須バリデータ１０１１、正規表現バリデータ１０１２、範囲バリデータ１０１３、比較バリデータ１０１４、およびカスタムバリデータ１０１５とする。このバリデータの分類は .NET Framework がWebアプリケーション開発で提供しているバリデータクラスと同様である。
【００３４】
入力必須バリデータ１０１１は、入力コントロールに値が入力されていることを検証するバリデータである。正規表現バリデータ１０１２は、入力値が指定の正規表現にマッチすることを検証するバリデータである。主に文字種の検証に使用する。範囲バリデータ１０１３は、入力値が指定の範囲内（下限値〜上限値）であることを検証するバリデータである。指定のデータ型に変換した上で検証するが、Integer型指定でアルファベットが入力された場合など、指定のデータ型に変換できない場合はエラーとする。比較バリデータ１０１４は、入力値を指定した値あるいは他の入力コントロールの入力値と比較する。指定した比較演算子による比較を行い、結果がtrueであれば正常、falseであればエラーとする。指定のデータ型に変換した上で比較するが、Integer型（整数型）指定でアルファベットが入力された場合など、指定のデータ型に変換できない場合はエラーとする。カスタムバリデータ１０１５は、前記４つのバリデータでは検証できない、複雑な検証を行いたい場合に使用する。Webアプリケーションのクライアントサイドでは、指定されたクライアントサイド検証関数による検証を行う。WebアプリケーションのサーバサイドおよびWindowsアプリケーションでは、指定された検証メソッドによる検証を行う。
【００３５】
バリデータベース１０１０は、前記５つのバリデータの親クラスである。全バリデータ共通の情報としてエラーメッセージを持ち、入力コントロールから入力値を取り出すためのメソッドGetValueを子クラスに提供する。
【００３６】
図５は、バリデータスクリプト１０２を定義しているソースコード（JScript）の例を示す。
【００３７】
バリデータスクリプト１０２は、Webアプリケーション・クライアントサイドの検証で使用する関数であり、バリデータクラス１０１と同様の分類としている。入力必須検証関数validateRequiredは、入力必須バリデータ１０１１と同様の処理を行う（コード１０２１）。正規表現検証関数validateRegularExpressionは、正規表現バリデータ１０１２と同様の処理を行う（コード１０２２）。範囲検証関数validateRangeは、範囲バリデータ１０１３と同様の処理を行う（コード１０２３）。比較検証関数validateCompareは、比較バリデータ１０１４と同様の処理を行う（コード１０２４）。また、各検証関数から使用する共通関数として、フィールド名から値を取得するgetValue関数をバリデータスクリプト１０２に定義する（コード１０２０）。カスタムバリデータに対応する関数は、各画面の開発者が個別に作成するものであるため、バリデータスクリプト１０２には定義しない。
【００３８】
図６は、検証情報一覧１０３の記述を示す図である。
【００３９】
検証項目ごとに、共通情報として、検証名、エラーメッセージ、およびバリデータ種別を設定する（１０３０１）。一般に、検証項目は、当該システムで使用するデータベースのテーブル項目に相当する。ただし、半角・全角などの文字種や数値範囲など、データベースでは定義しきれない入力制限が考えられ、そのような検証情報を考慮して入力検証情報シート（検証情報一覧１０３）を作成する。
【００４０】
バリデータ種別は、「正規表現」「範囲」「比較」「カスタム」のいずれかを指定する。加えて、選択したバリデータ種別に必要な情報を指定する。バリデータ種別が「正規表現」であれば、正規表現式を指定する（１０３０２）。バリデータ種別が「範囲」であれば、データ型、下限値および上限値を指定する（１０３０３）。バリデータ種別が「比較」であれば、データ型および比較対象値を指定する。比較対象が固定値ではなく画面上のコントロールの場合は、ここには何も指定せず、検証情報定義部１１２で指定する（１０３０４）。バリデータ種別が「カスタム」であれば、検証メソッド名を指定し、Webアプリケーションの場合はさらにクライアントサイド検証関数名も指定する（１０３０５）。検証メソッド名とクライアントサイド検証関数名は、保守の観点から、同名にしておくことが好ましい。
【００４１】
バリデータ種別として「入力必須」は指定しない。入力必須かどうかは、同じ検証項目でも画面ごとに仕様が異なる可能性があることから、検証情報定義部１１２で指定する方式とする。
【００４２】
図６では、顧客番号、顧客名、入金日契約日以降、入金日本日以前、および金額という検証名で検証情報を定義している（検証項目１０３１〜１０３５）。
【００４３】
図７は、検証ユニット１０４の実体であるバリデータクラス・インスタンスの生成ソースコードである。このソースコードは、入力検証情報シートに対してソース作成マクロを実施することで作成する。入力検証情報シートの検証項目１つに対して検証ユニットを１つ作成する。
【００４４】
入力必須バリデータは、検証情報一覧１０３には表現しない情報であるが、各検証項目に共通で使用する特殊なバリデータとしてインスタンスを１つ生成する（コード１０４０）。コード１０４１〜１０４５で生成している各インスタンスは、図６の検証情報一覧１０３に定義している検証項目１０３１〜１０３５にそれぞれ対応している。カスタムバリデータの場合は、検証処理を行うメソッドおよびスクリプトを別途定義する必要がある。
【００４５】
図８は、入金日が本日以前であることを検証するメソッドValidatePastの定義例である。検証ユニット１０４では、ValidatePastはデリゲート（委譲）メソッドとして登録されることで、検証時に検証制御部１１３から呼び出される。図９は、入金日が本日以前であることを検証するクライアントサイド検証スクリプトvalidatePastの定義例である。これは図８と同様の処理をJScriptで記述したものである。カスタムバリデータのためのこれらのメソッドおよびスクリプトは、各画面の開発者が必要に応じて作成するが、本例にある日付検証処理のような汎用的な検証であれば、システム全体でメソッドおよびスクリプトを共有すべきである。
【００４６】
図１０は、検証情報定義部１１２のソースコードを示している。検証情報定義部１１２の実体は、各画面の各入力コントロールと検証ユニット１０４との紐付けを行うためのメソッドSetValidationInfoである。SetValidationInfoは各画面で定義し、画面ロード時に必ず実行されるように実装する。
【００４７】
ここで定義する紐付け情報には、入力コントロールと検証ユニット１０４に加えて、検証グループ名も設定する。検証グループは、イベント発生時の検証対象入力コントロールをグループ化するために使用する。本例では、ボタン「登録」を押下したときは全ての検証を行うが、ボタン「入金日チェック」を押下したときは入金日の検証のみを行う。このように、イベントによって検証する入力コントロールが異なる場合、検証グループの概念は有効である。つまり、ボタンと入力コントロールは直接紐付くのではなく、検証グループ名が仲介して紐付く。
【００４８】
図１０では、まず検証グループとボタンを紐付け（１１２０１〜１１２０２）、次に入力コントロールと検証ユニットと検証グループを紐付けている（１１２１１〜１１２１５）。メソッドSetValidationGroupは、検証グループとボタンを紐付けるためのメソッドであり、メソッドAddValidationは、検証グループと入力コントロールと検証ユニットを紐付けるためのメソッドである。いずれも画面の親クラスに共通メソッドとして実装する。
【００４９】
図１１は、検証グループとボタンの紐付けの結果を示す図である。図１０のコード１１２０１および１１２０２は、図１１における対応表１１２３の１１２３１および１１２３２に対応している。
【００５０】
図１２は、検証グループと入力コントロールと検証ユニットの紐付けの結果を示す図である。図１０のコード１１２１１〜１１２１５は、図１１における対応表１１２４の１１２４１〜１１２４Ｂに対応している。この中で、検証グループを２つ指定しているコード１１２１３は１１２４４〜１１２４７に対応しており、同様にコード１１２１４は１１２４８および１１２４９に対応している。メソッドAddValidationの第１引数は入力必須検証を行う／行わないの指定であり、trueを指定すると対応表に当該入力コントロールの入力必須検証が登録される。比較バリデータの場合は、検証付加情報として比較対象である契約日コントロールを検証情報に持つ。
【００５１】
図１３は、画面制御メイン１１１における検証制御部１１３への検証依頼ソースコードを示している。コード１１１１は登録ボタン押下時、コード１１１２は入金日チェックボタン押下時の処理である。
【００５２】
検証制御部１１３の実体はメソッドValidateであり、Validateにイベント発生の契機となったボタン（押下されたボタン）を指定する。C#.NETのイベントハンドラではイベント発生元がオブジェクトsenderに格納されているため、これをそのままValidateの引数に指定すればよい。したがって、イベントハンドラに関わらず、検証制御部１１３への検証依頼ソースコードは同じになる。
【００５３】
図１４は、検証制御部１１３の実体であるメソッドValidateの処理フローを示している。メソッドValidateでは、画面制御メイン１１１から指定されたボタンコントロールを基に検証情報定義１１２３を検索し、検証グループを特定する（ステップ１１３０１）。次に、特定した検証グループから検証情報定義１１２４を検索し、検証ユニット１０４を取得する。ここでは検証グループに紐付く検証ユニット１０４を全て取得する。次に、取得した検証ユニット１０４全てに対して、入力コントロールの入力値を渡して検証を依頼する（ステップ１１３０３）。次に、検証ユニット１０４から取得した検証結果を判定する（ステップ１１３０４）。検証結果が正常の場合、画面制御メイン１１１に正常(true)を返却する（ステップ１１３０５）。検証結果がエラーの場合、Windowsアプリケーションであれば画面にエラーメッセージを表示し、Webアプリケーションであればエラーメッセージ表示スクリプトを作成しクライアントに送信することで、ブラウザにエラーメッセージを表示させる（ステップ１１３０６）。さらに、画面制御メイン１１１にエラー(false)を返却する（ステップ１１３０７）。
【００５４】
図１５は、検証制御スクリプト１１４のソースコードを示している。検証制御スクリプト１１４は、Webアプリケーションにおいて画面制御メイン１１１で作成するHTMLに埋め込むスクリプトである。画面制御メイン１１１から検証制御スクリプト１１４の作成を依頼された検証制御部１１３は、検証情報定義部１１２の検証情報（図１２の対応表１１２４）に基づいてスクリプトを作成する。全ての検証情報に対してバリデータスクリプトを呼び出すのではなく、押下されたボタンに紐付く検証グループ名に紐付く検証ユニットに対してのみバリデータスクリプトを呼び出す処理とする。
【００５５】
図１５のコード１１４４１〜１１４４Ｂは、図１２の対応表１１２４の検証情報１１２４１〜１１２４Ｂにそれぞれ対応している。検証制御スクリプト１１４で行う処理は、バリデータスクリプト１０２に定義している各関数に入力コントロールの入力値を渡して検証を依頼する処理である。ただし、バリデータの種別がカスタムバリデータである検証情報については、バリデータスクリプト１０２内の関数ではなく、各画面で個別に定義した検証スクリプトを呼び出す。例えばコード１１４４９では、図９の「入金日本日以前」検証スクリプトを呼び出している。
【００５６】
画面制御メイン１１１では、検証制御スクリプト１１４とバリデータスクリプト１０２をHTMLに埋め込むだけではなく、ボタン押下時(サブミット時)に検証制御スクリプト１１４のValidate関数を呼び出すよう、サブミットボタンのonclick属性に処理を追加する必要がある。図１６は、onclick属性に処理を追加したサブミットボタンの定義HTMLを示している。これによって、ボタン押下時にまず図１５のValidate関数が呼び出され、その結果が正常(true)だった場合のみサブミットされ、サーバサイドにHTTP要求が送信される。
【００５７】
以上のように、本実施の形態に係る入力検証処理方式１００では、WindowsアプリケーションとWebアプリケーションとで一元化された検証情報を共有する。検証制御部１１３は、検証エラー時のエラーメッセージの表示処理がWindowsアプリケーションとWebアプリケーションとで異なることから、完全にアプリケーション非依存とすることはできない。しかし、検証制御部１１３のメソッドValidateの実装方式として、Windowsアプリケーションでは画面（Formクラス）の親クラスに実装し、Webアプリケーションでは画面（Pageクラス）の親クラスに実装することで、各Formクラス・Pageクラスにおける入力検証に関連する処理（図１０の検証情報定義部１１２、および図１３の検証制御部１１３呼び出し処理）はアプリケーション形態に依存しない統一化された記述となる。
【００５８】
検証内容に変更が発生した際は、入力検証情報シートを修正し、定義クラスのソースファイルを差し替えるだけでよい。これにより、高い保守性を実現する。
【００５９】
グリッドコントロール内セルの入力検証について、入力検証処理方式１００では扱っていないが、同様の方式で実現可能である。入力検証処理方式１００をベースにして、グリッドコントロール内セルの入力検証を行うようにするためには、入力検証処理方式１００内で検証対象として「入力コントロール」の情報を扱っている部分を「グリッドコントロール・列名」も扱えるように機能を拡張すればよい。ただし、当該グリッドコントロールの行が複数ある場合は、その全行に対して当該列の入力値の検証を行う必要がある。
【図面の簡単な説明】
【００６０】
【図１】本発明の一実施の形態に係る入力検証実装方式の概略構成を示すブロック図である。
【図２】本発明の一実施の形態に係るWindowsアプリケーションにおける入力検証処理の概要を示すフローチャートである。
【図３】本発明の一実施の形態に係るWebアプリケーションにおける入力検証処理の概要を示すフローチャートである。
【図４】バリデータクラス１０１の静的クラス図である。
【図５】バリデータスクリプト１０２のソースコードである。
【図６】検証情報一覧１０３の記述である。
【図７】検証ユニット１０４のソースコードである。
【図８】カスタムバリデータ使用時の検証メソッドの一例を示す「入金日本日以前」検証メソッドのソースコードである。
【図９】カスタムバリデータ使用時の検証スクリプトの一例を示す「入金日本日以前」検証スクリプトのソースコードである。
【図１０】検証情報定義部１１２のソースコードである。
【図１１】検証グループと画面ボタンの対応表である。
【図１２】検証グループと入力コントロールと検証ユニットの対応表である。
【図１３】画面制御メイン１１１における検証制御部１１３への検証依頼処理のソースコードである。
【図１４】検証制御部１１３の実体であるメソッドValidateの処理フローである。
【図１５】検証制御スクリプト１１４の実体であるValidate関数のソースコードである。
【図１６】画面制御メイン１１１が作成するサブミットボタンのHTMLを示す図である。
【符号の説明】
【００６１】
１００…入力検証実装方式、１０１…バリデータクラス、１０２…バリデータスクリプト、１０３…検証情報一覧、１０４…検証ユニット、１１０…画面、１１１…画面制御メイン、１１２…検証情報定義部、１１３…検証制御部、１１４…検証制御スクリプト、１００１１〜１００１６…Windowsアプリケーションの入力検証処理シーケンスにおける処理ステップ、１００２１〜１００２Ｅ…Webアプリケーションの入力検証処理シーケンスにおける処理ステップ、１０１０…バリデータベースクラス、１０１１…入力必須バリデータクラス、１０１２…正規表現バリデータクラス、１０１３…範囲バリデータクラス、１０１４…比較バリデータクラス、１０１５…カスタムバリデータクラス、１０２０…フィールド値取得関数、１０２１…入力必須検証関数、１０２２…正規表現検証関数、１０２３…範囲検証関数、１０２４…比較検証関数、１０３１〜１０３５…検証情報一覧に定義する検証項目、１０３０１〜１０３０５…検証情報一覧に記述する情報、１０４０〜１０４５…検証ユニット内に定義するバリデータクラスのインスタンス、１１２０１、１１２０２…検証グループと画面ボタンを紐付ける処理、１１２１１〜１１２１５…検証グループと入力コントロールと検証ユニットを紐付ける処理、１１２３…検証グループとボタンの対応表、１１２３１、１１２３２…検証グループとボタンの対応情報、１１２４…検証グループと入力コントロールと検証ユニットの対応表、１１２４１〜１１２４５…検証グループと入力コントロールと検証ユニットの対応情報、１１１１…登録ボタン押下のイベントハンドラ、１１１２…入金日チェックボタン押下のイベントハンドラ、１１３０１〜１１３７…検証制御部メソッドValidateの処理フローにおけるステップ、１１４４１〜１１４４Ｂ…検証制御スクリプトValidate関数における各入力コントロールの入力検証処理のソースコード、１１４０１…Webアプリケーション「実行」ボタンのHTML、１１４０２…Webアプリケーション「入力日チェック」ボタンのHTML。
【図１】
0005188818.tif 000002
【図２】
0005188818.tif 000003
【図３】
0005188818.tif 000004
【図４】
0005188818.tif 000005
【図５】
0005188818.tif 000006
【図６】
0005188818.tif 000007
【図７】
0005188818.tif 000008
【図８】
0005188818.tif 000009
【図９】
0005188818.tif 000010
【図１０】
0005188818.tif 000011
【図１１】
0005188818.tif 000012
【図１２】
0005188818.tif 000013
【図１３】
0005188818.tif 000014
【図１４】
0005188818.tif 000015
【図１５】
0005188818.tif 000016
【図１６】
0005188818.tif 000017