2011-01-30 12 views
0

私はそれに複数の検証を持つ私のアプリケーション内にテキストボックスを持っています。 RequiredFieldValidator、RegexValidation、およびCustomValidationです。私のページには、いくつかの同様のテキストボックスがあります。だから私はちょうどコピー貼り付け、IDとcontroltovalidateプロパティを変更し、それは働いている。カスタムのTextBoxコントロールが組み込まれたクライアント側の検証

同様のtbxが別のページでも使用されるため、独自のカスタムTextBoxコントロールをビルトイン検証で作成するとよいでしょう。

1:検証方法で私のカスタム検証を行うIValidatorから実装ここ

は、私が発見し、試してみました2つのアプローチがあります。ここに示すように:Self-Validating TextBoxしかし、クライアント側の検証を実装する方法は示されていません。

2:TextBoxから派生し、必要なasp.netビルトインバリデータを追加するカスタムコントロールを作成します。ここに示すように:Custom TextBox。私はコードを試して、それはサーバー/クライアント側で動作します。

私は最初のアプローチは好きですが、クライアント側の検証を実装する方法はわかりません。私はクライアントサイドのjs関数が必要であることを知っています。私はそれを行うことができます。私はPage.ClientScriptクラスを使ってjsファイルをインクルードする方法を知っていますが、すべてを統合して動作させる方法はわかりません。

私は上記のUserControlまたは2番目のアプローチを作成できますが、私は特にカスタムコントロールからクライアント側の検証を学び実装することを検討しています。

私はAsp.Net 2.0を使用しています。ご意見ありがとうございます。

答えて

0

まあまあですが、TextBoxから派生したカスタムサーバーコントロールを実装し、いくつかのバリデーターを自動的に関連付けることができます。しかし、通常、明示的に必要とされない限りカスタムコントロールを作成しないで、いくつかの異なるプロジェクトを作成します。 クライアント側のバリデーションを行うには、通常JavaScriptが必要ですが、ほとんどのASP.net検証コントロールにはクライアント側検証が既に組み込まれています(つまり、必須フィールドバリデーター、範囲バリデーターなど)。他のもの(カスタムバリデータのようなもの)はあなたのカスタムjavascriptをフックできます。

私にとってより妥当と思えるアプローチは、ASP.netページ/ usercontrol上にTextBoxコントロールを配置し、実行時にコードからバリデータを動的に関連付けることです。 OnInitイベントでは、RegisterRequiredValidatorsという関数を呼び出して、TextBoxのリストを渡します。私はちょうど声を出して考えています:

これは単なる文脈を説明するための単なる例です。理論的には、このコンセプトを発展させてあらゆる種類のバリデータを登録することができます。私たちは、これを "ルール"の形で抽象化することで、フロントエンドでASP.netバリデーターとして最終的にレンダリングされることで、同様のことを行います。

+0

ありがとうございます。はい、私は、クライアント側のバリデーションが組み込まれているバリデーターに付属していることを認識しています。私はこのコントロールを複数のページで複数回使用し、潜在的に他のプロジェクトでも使用します。あなたが提案したアプローチが私のニーズに合うかどうかは疑問です。私が仕事に1番目のアプローチをすることができない場合、私は2番目のものと一緒に行くと思う。 – gbs

関連する問題