詳細な説明ASP+検証
アンソニー・ムーア
Microsoft Corporation
2000年10月
概要：ASP+検証Webコントロールの使用に関する詳細な説明。
目次
簡単な紹介
はじめる
いつ起こりますか？
サーバー側の検証シーケンス
クライアント検証
効果的なルールと有用なエラー情報
有効化、可視、表示プロパティの機能
CustomValidatorコントロール
どのコントロールを検証できますか？
終わり
-------------------------------------------------------------- -------------------------------------------------------------- -----------------------------
簡単な紹介
この記事では、ASP+検証制御の作業方法について詳しく説明します。検証制御を含む複雑なページを生成する場合、または検証フレームワークを拡張する場合は、この記事を読むことをお勧めします。検証コントロールを使用するか、検証コントロールを使用するかどうかを決定する場合は、「ASP+ユーザーEnter Verification（英語）」を参照してください。
はじめる
ASP+開発プロセス全体で検証を理解することが重要であることを知っています。今日の商用Webサイトのほとんどを見ると、これらのサイトには多くのフォームがあり、これは明らかに多数の手書きコードを実行することで実行されます。検証コードを書くことは興味深い仕事ではありません。データテーブルを表示したり、チャートを動的に生成したりするコードを作成した場合、非常に魅力的かもしれませんが、この「クールな」方法が名前フィールドの空の値を禁止できることを同僚と確認することはできません。
他の理由から、Webアプリケーションの検証も非常に面倒です。 HTML 3.2には、ユーザーから取得できるコンテンツまたはフィードバックを制御できるコンテンツに多くの制限があるため、ユーザーが特定の文字を入力することを禁止するなど、より充実したクライアントに使用できる手法には適用できません。音を立てる。ブラウザスクリプトを使用すると、より強力な検証が生じる場合があります。ただし、顧客のブラウザは必ずしもスクリプトではなく、悪意のあるユーザーがバイパスできるため、この方法を確認することは困難です。したがって、サイトの安全性を確保するためには、サーバーの同じ検査を実行する必要があります。
ASP+を開発する場合、当初の意図は、1つのコントロールのみを使用して検証を処理することです。しかし、それが設計されたとき、私はこの欲求を達成できないことがわかりました。できるだけ多くのフォームに適用できるソリューションを見つけるために、多数のデータ入力フォームを調査しました。データ入力テーブルには多くの興味深い機能があることがわかりました。
エラー情報またはアイコンは多くの場合、入力要素に隣接していますが、ほとんどの場合、テーブルの異なるセルにあります。
多くの場合、すべてのエラーを要約するためにページに領域があります。
多くのサイトには、クライアントスクリプトが含まれており、より高速なフィードバックを提供しながら、サーバー間の旅行を無駄に防止します。
クライアントスクリプトを含む多くのサイトは、エラーが発生したときに情報ボックスを表示します。
テキスト入力が検証されるだけでなく、ドロップダウンリストと単一の選択ボタンも検証されます。
フィールドが空の場合、サイトには通常、エントリが無効なときに異なる情報またはアイコンが表示されます。
多くの効果的な検査は、一般的に使用される表現によく置き換えることができます。
検証は通常、2つの入力間の比較結果に基づいています。
検証タスクの90％または90％以上は、名前や郵便番号のチェックなど、いくつかの一般的な操作です。ほとんどのサイトはまだこれらのタスクを繰り返しているようです。
サイト間の違いは通常大きすぎるため、各サイトのすべての検証タスクを処理するための完璧なソリューションを取得することはできません。
上記のすべての状況を考慮すると、最終的なソリューションには、5つの検証デバイスコントロール、検証ムマリーコントロール、およびページオブジェクトとの統合が含まれます。同時に、ソリューションを拡張する必要があることは明らかであり、クライアントとサーバーに協力するためにAPIが必要であることは明らかです。
研究のさまざまな検証中に、より大きなツールボックスが必要であるように思われました。 Microsoft®ActiveX®などのほとんどのコンポーネント環境では、すべての検証制御の関数を制御に統合して、異なるモードで異なる属性を処理しようとした可能性があります。幸いなことに、Microsoft®.NETフレームワークには、新しいコントロールに必要な追加のワーキングロードが非常に小さいため、一連のコントロールを提供できます。
これらのコントロールのほとんどは、パブリックレベルのベースバリデーターに実装されています。また、Basevalidatorまたは他のコントロールからさまざまなタスクを完了することもできます。実際、BaseValidatorが独自のテキスト属性を実現できない場合でも、ラベル属性から継承されます。
いつ起こりますか？
Webコントロールのページを含むページを処理する際に、イベントシーケンスを理解することは非常に効果的です。検証条件がオプションである場合、クライアントとサーバーが確認されたときに正確に理解する必要があります。自分で検証ルーチンを書きたい場合は、非常に時間がかかるか副作用があるかもしれません。同時に、検証ルーチンを呼び出すタイミングを理解することも重要です。
まず、サーバーを見てみましょう。
サーバー側の検証シーケンス
ページの有効期間を理解することが重要です。視覚的な基本的または同様の機能的クライアントツールでフォームを処理することに慣れている場合は、理解するために一定の時間を費やす必要があります。ページとページ上のすべてのオブジェクトは、ユーザーと対話するときに効果的ではありませんが、これは同じこともあります。
以下は、初めてページにアクセスする際の単純化されたイベントシーケンスです。
ASPXファイルに基づいてページとそのコントロールを作成します。
page_loadイベントのトリガー。
ページと制御属性は、隠されたフィールドに保存されます。
ページとコントロールはHTMLに変換されます。
すべてを捨てます。
これで、ユーザーがボタンまたは同様のコントロールをクリックすると、サーバーに戻り、同様のイベントシーケンスを実行します。このシーケンスは、リターンシーケンスと呼ばれます。
ASPXファイルに基づいてページとそのコントロールを作成します。
非表示フィールドからページと制御属性を復元します。
ユーザーに応じて更新ページコントロールを入力します。
page_loadイベントのトリガー。
トリガー通知イベントを変更します。
ページと制御属性は、隠されたフィールドに保存されます。
ページとコントロールはHTMLに変換されます。
すべてをもう一度捨ててください。
すべてのオブジェクトをメモリに保管してみませんか？ ASP+で確立されたWebサイトは、非常に多くのユーザーを処理できないためです。したがって、サーバーのメモリは、すぐに処理されるコンテンツのみを保持します。
サーバー側の検証はいつですか？ページ情報を初めて取得する場合、サーバー側の検証はまったく実行されません。ほとんどのエンドユーザーは非常に深刻です。ユーザーは、フォームに記入された情報が正しいかどうかを確認し、赤いテキストを使用してユーザーに間違った情報を入力します。
戻りイベントシーケンスでは、ステップ3からステップ4の間に検証が実行されます。言い換えれば、検証は、ユーザーからのデータロード制御属性の後に、しかしほとんどのコード実行の数の前にあります。これは、ユーザーイベントを作成するときに、通常は検証に使用できることを意味します。通常の状況では、これを行いたいと思うでしょう。
その時点での検証の欠点は、プログラミングによる検証に影響を与えるいくつかの属性を変更したい場合、手遅れになります。たとえば、コードを使用して検証制御の属性を有効または無効にする場合、または検証コントロールを変更する場合、ページを処理する前に効果が表示されないことがわかります。この問題は、次の2つの方法で回避できます。
検証前に属性を変更します。
属性の変更後にコントロールを再検証します。
どちらの方法でも、ページオブジェクトで効果的な検証属性とメソッドを使用する必要があります。
ページAPI
ページオブジェクトには、サーバー側の検証に関連するいくつかの重要な属性とメソッドが含まれます。表1は、これらの属性と方法をまとめたものです。
表1。ページオブジェクトの属性とメソッド
属性またはメソッドの説明
IsValid属性は最も有用な属性です。この属性は、フォーム全体が効果的かどうかを確認できます。このチェックは通常、データベースを更新する前に実行されます。バリデーターのすべてのオブジェクトのみが有効であり、属性は真であり、値はキャッシュに保存されません。
Validatorsは、このページのすべての検証オブジェクトのコレクションを属性にします。これは、ivalidatorインターフェイスを実装するオブジェクトのコレクションです。
値メソッドは、検証時にメソッドを呼び出します。ページオブジェクトのデフォルトの実行方法は、各検証デバイスに頼り、検証デバイスが自体を評価する必要があることです。
Validatorsコレクションは、多くのタスクに非常に役立ちます。このセットは、ivalidatorインターフェイスを実装するオブジェクトのコレクションです。私がオブジェクトを使用する理由は、ページオブジェクトがivalidatorインターフェイスにのみ注意を払うため、コントロールの制御ではありません。すべての検証は通常、ivalidatorの視覚的制御を実現するために使用されるため、検証オブジェクトを使用して検証オブジェクトをページに追加できるはずです。
ivalidatorインターフェイスには、次の属性と方法が含まれています。
表2。Ivalidatorインターフェイスの属性と方法
属性またはメソッドの説明
ISValid属性は、個別の検証オブジェクトによって実行された有効性テストが渡されたかどうかを指摘しました。検証後に値を手動で変更できます。
ErrorMessage属性は、検証するオブジェクトを確認するためのエラーと、ユーザーに表示されるエラーを確認します。
検証メソッドは、検証オブジェクトの有効性をチェックして、そのvalid値を更新します。
このインターフェイスを使用して、いくつかの興味深いタスクを実行できます。たとえば、ページを効果的な状態にリセットするには、次のコード（C＃に示す例など）を使用します。
ivalidator値;
foreach（バリネーターのval）{
valueValid = true;
}
検証シーケンス全体を再実行するには、次のコードを使用します。
ivalidator値;
foreach（バリネーターのval）{
val.Validate（）;
}
ベータ1エディション以下のバージョンがある場合は、同じタスクを完了できるように、ページオブジェクトの値メソッドを呼び出すこともできます。検証の前にいくつかの変更を加えるために、値メソッドをカバーできます。この例は、チェックボックスの値に応じて開くかオフにする検証装置を含むページを示しています。
パブリッククラスの条件：ページ{
public htmlinputcheckbox chksameas;
Public ResearchFieldValidator rfvalshipAddress;
保護されたオーバーライドvoid validate（）{）{）
//配送先住所を確認するだけです（支払いアドレスとは異なる場合）
bool enableship =！
rfvalshipaddress.enabled = enableShip;
//検証を実行しています
base.validate（）;
}
}
クライアント検証
クライアント検証によってページが有効になっている場合、往復中にまったく異なるイベントシーケンスが発生します。クライアントの検証は、クライアントJScript®を使用しています。検証では、バイナリコンポーネントは必要ありません。
JScript言語の標準化はよく実行されていますが、ブラウザ（DOM）のHTMLドキュメントで使用されているドキュメントオブジェクトモデル（DOM）は、広く使用されていません。したがって、クライアントの検証は、検証されたオブジェクトがインターネットエクスプローラーDOMであるため、インターネットエクスプローラー4.0以降でのみ実行されます。
サーバーの観点から見ると、クライアントの検証は、検証制御が異なるコンテンツをHTMLに送信することを意味します。さらに、インシデントシーケンスはまったく同じです。サーバー側のチェックは引き続き実行されます。それは冗長のようですが、それは非常に重要です。
一部の検証コントロールは、クライアントスクリプトをサポートしていない場合があります。良い例があります。CustomValidatorとサーバーの検証関数を同時に使用するが、クライアント検証機能はありません。
安全上の注意。一部の人々は、スクリプトを含むページを簡単に取得し、ページを無効または変更できます。悪いデータがシステムに入るのを防ぐためにスクリプトを使用しないでください。したがって、CustomValidatorを使用する場合は、対応するサーバー検証関数なしでクライアント検証機能を提供しないでください。
各検証制御により、標準のクライアントスクリプトブロックがページに送信されるようにします。実際、これはコードのほんの一部であり、スクリプトライブラリWebUivalidation.jsのコードへの参照が含まれています。このスクリプトライブラリファイルには、クライアントによって検証されたすべてのロジックが含まれています。
スクリプトライブラリについて
Webコントロールスクリプトの検証はスクリプトライブラリにあるため、すべてのクライアントによって検証されたコードは、表面上で行われているように見えますが、ページに直接送信する必要はありません。メインスクリプトファイルの参照は、次のものに似ています。
<スクリプト言語= javascript
src =/_ aspx/1.0.9999/script/webuivalidation.js> </scrip>
デフォルトでは、スクリプトファイルは_aspxディレクトリのデフォルトのルートディレクトリにインストールされ、スクリプトに含まれる命令を使用して、肯定的な対角線で始まる命令を使用します。参照は、個々のオブジェクトがスクリプトライブラリを含める必要がなく、同じコンピューター上のすべてのページが同じファイルを参照できることを示しています。このパスには、異なるランタイムバージョンが同じコンピューターで実行できるように、このパスには一般言語バージョン番号もあることに気付くでしょう。
デフォルトの仮想ルートディレクトリを見ると、ファイルを見つけてコンテンツを表示します。これらのファイルの位置は、config.webファイルで指定されています。 config.webファイルは、ほとんどのASP+設定のXMLファイルです。以下は、このファイルの位置の定義です。
<webControls
clientscriptslocation =/_ aspx/{0}/script/
/>
詳細に発生するイベントを理解できるように、スクリプトを読むことをお勧めします。ただし、機能は特定のランタイムバージョンに密接にリンクされているため、これらのスクリプトを変更しないことをお勧めします。バージョンが更新されると、これらのスクリプトをそれに応じて更新する必要があります。特定のプロジェクトを変更する必要がある場合は、最初にこれらのスクリプトをバックアップしてから、プロジェクトをバックアップファイルに向けます。この方法は、プライベートconfig.webファイルを使用してこれらのファイルの位置を置き換えることです。文字列にフォーマットコマンド{0}が含まれている場合、ランタイムバージョン番号が置き換えると、バージョン番号が命令を置き換えます。この位置を相対的な参照または絶対的な参照に変更することが最善です。
クライアントの検証を無効にします
クライアントを検証したくない場合があります。入力フィールドの数が小さい場合、クライアントの検証はあまり役に立たない場合があります。結局のところ、毎回1つのラウンドトリップサーバーを必要とするロジックが必要です。クライアントの動的な情報は、レイアウトにマイナスの影響を与えることがわかります。
クライアントの確認を無効にするには、ページ命令ClientTarget = downLevelを使用します。この命令は、ASPXファイルの開始に似ています。
<％@ページ言語= c＃clientTarget = downlevel％>
この命令のデフォルト値はAUTOであり、Microsoft Internet Explorer 4.0以下のバージョンのクライアントのみを確認することを示します。
注：残念ながら、ベータ1では、この命令は検証のために無効になっているだけでなく、同時にすべてのWebコントロールがHTML 3.2タグを使用して処理する可能性があります。最終バージョンは、この問題を制御するためのより良い方法を提供します。
クライアントイベントシーケンス
このシーケンスは、クライアントの検証を含むページが発生するイベントシーケンスです。
ページにブラウザをロードするときは、各検証コントロールを初期化する必要があります。これらのコントロールは<Span>マークとして送信され、HTML機能はサーバー上の機能に最も近いものです。最も重要なことは、検証装置によって参照されるすべての入力要素は、現時点で「絞首刑」されることです。参照された入力要素は、変更を入力するときに確認ルーチンを呼び出すためにクライアントイベントを変更します。
スクリプトライブラリのコードは、ユーザーがTABキーを使用して各フィールドを切り替えると実行されます。特定の独立したフィールドが変更されると、検証条件が再評価され、検証装置が必要に応じて表示または見えなくなります。
ユーザーがフォームを送信しようとすると、すべての検証が評価されます。これらすべての確認が効果的である場合、フォームはサーバーに送信されます。 1つ以上の場所でエラーがある場合、次の状況が発生します。
提出はキャンセルされました。フォームはサーバーに送信されません。
すべての無効な検証が表示されます。
検証概要にshosummary = trueが含まれている場合、検証コントロールからのすべてのエラーが収集され、これらのエラーでコンテンツが更新されます。
検証の要約にshowmessagebox = trueが含まれている場合、エラーを収集し、クライアントの情報ボックスにこれらのエラーを表示します。
クライアント検証コントロールが入力時または時期に実行されるためです。提出後、これらの検証制御はサーバー上で再評価されることに注意してください。