WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

CustomValidator のクライアント側での検証

by WebSurfer 27. June 2020 12:03

ASP.NET Web Forms アプリでユーザー入力の検証に用いられる CustomValidator のクライアント側での検証について調べたことをまとめて備忘録として書いておきます。

CustomValidator のクライアント側での検証

CustomValidator は、プログラマが独自の検証ロジックをコーディングして検証メソッドとしてページに実装し、ユーザー入力の検証を行うために利用されます。複数の入力コントロールにまたがって検証を行うことも可能です。

また、RegularExpressionValidator などと異なり、TextBox の他に CheckBox, RadioButton, DropDownList, FileUpload などのユーザー入力コントロールの検証に利用できます。

クライアント側での検証は、JavaScript を使って検証用メソッドを自力でコーディングし、それをページに実装することで可能になります(サーバー側でなければ検証できない場合は話は別です。ajax を使う手はいろいろ問題がありそうです。詳しくは先の記事「CustomValidator で jQuery.ajax 利用」を見てください)。

この記事の下の方に TextBox, CheckBox, RadioButton, DropDownList, FileUpload を対象として、CustomValidator によるクライアント側での検証を実装したサンプルコードを書いておきます。上の画像を表示したものです。

自分的に注意が必要と思う点を以下に箇条書きにしておきます。

  1. クライアント側での検証は html 要素の change イベントでかかるようになっています。CustomValidator を change イベントで動くようにするには ControlToValidate プロパティの設定が必要です。(注: submit でも検証がかかります。というか、change で検証がかかるのはユーザビリティ向上のためで、submit 時の検証がメインです)
  2. CheckBox, RadioButton コントロールに対しては CustomValidator の ControlToValidate プロパティを設定できません。設定すると HttpException がスローされ、例えば CheckBox の場合は「'CustomValidator' の ControlToValidate プロパティで参照されたコントロール 'CheckBox' を検証できません。」というエラーメッセージが表示されます。

    エラーとなる直接の理由は、ASP.NET 内部で CheckControlValidationProperty メソッドによる検証対象コントロールのチェックを行っていますが、CheckBox RadioButton コントロールには ValidationPropertyAttribute 属性が付与されてないためないためです。

    そもそもの理由は、Microsoft のドキュメントによると「ControlToValidate プロパティを設定せずに CustomValidator コントロールを使用することもできます。 これは、複数の入力コントロールを検証する場合や、CheckBox コントロールなどの検証コントロールで使用できない入力コントロールを検証する場合に一般的に行われます」とのことで、もともと CheckBox や RadioButton は検証コントロールを使う対象外のように読めます。
  3. TextBox, DropDownList, FileUpload コントロールについては、CustomValidator の ControlToValidate プロパティを検証対象コントロールの ID に設定すれば change イベントで検証がかかります。

    なお、ControlToValidate プロパティを設定しなくても submit で検証はかかりますので、change イベントでいちいち検証がかかるのは煩わしいという場合は設定しない方がよさそうです。(RequiredFieldValidator など他の検証コントロールは ControlToValidate プロパティを設定しないとエラーになりますので注意してください。CustomValidator だけ特別です)。
  4. どういう html 要素がどのタイミングで change イベントを発生させるかについては MDN の記事 HTMLElement: change event を見てください。その記事に書いてある通り、TextBox はユーザーが入力してフォーカスを外した時、DropDownList はユーザーが選択を変更したとき、FileUpload はユーザーがファイルを選択したとき change イベントが発生し、CustomValidator の ControlToValidate プロパティが設定されていれば検証がかかります。

    CheckBox (input type="checkbox"), RadioButton (input type="radio") も change イベントは発生しますが、上に述べたように CustomValidator の ControlToValidate プロパティを設定できないので、change イベントでは CustomValidator による検証はかかりません(submit で検証されます)。
  5. クライアント側での検証用 JavaScript のメソッドは CustomValidator の ClientValidationFunction プロパティに設定します。メソッド名が例えば Validate(sender, args) とすると、sender には CustomValidator が html に変換された span 要素が渡されます。args には IsValid, Value プロパティを持つ JavaScript オブジェクトが渡されます。

    CustomValidator の ControlToValidate プロパティが検証対象コントロールに対して設定してある場合は、args.Value には検証対象の入力コントロールが html に変換された input 要素の value 属性の値が渡されます。ControlToValidate プロパティが設定されてない場合は args.Value は空 "" になります。

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" 
    AutoEventWireup="true" CodeBehind="WebForm6.aspx.cs" 
    Inherits="WebApplication1.WebForm6" %>

<asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" 
    runat="server">

    <script type="text/javascript">
        //<![CDATA[

        // ControlToValidate が設定されてない場合、引数 args には
        // テキストボックスの値が渡されないので注意。args に頼らず
        // 以下のようにしておくのがよさそう
        function TextBoxValidate(sender, args) {
            var tb =
                document.getElementById('<%= TextBox1.ClientID%>');

            var membership = tb.value.toLowerCase();
            if (membership === "gold" || membership === "silver") {
                args.IsValid = true;
            } else {
                args.IsValid = false;
            }
        }

        function CheckBoxValidate(sender, args) {
            var cb =
                document.getElementById('<%= CheckBox1.ClientID%>');

            if (cb.checked == true) {
                args.IsValid = false;
            } else {
                args.IsValid = true;
            }
        }

        function RadioButtonValidate(sender, args) {
            var rb =
                document.getElementById('<%= RadioButton1.ClientID%>');

            if (rb.checked == true) {
                args.IsValid = false;
            } else {
                args.IsValid = true;
            }
        }

        // ControlToValidate が設定されてない場合、引数 args には
        // テキストボックスの値が渡されないので注意。args に頼らず
        // 以下のようにしておくのがよさそう
        function DropDwonListValidate(sender, args) {
            var ddl =
                document.getElementById('<%= DropDownList1.ClientID%>');

           if (ddl.value == "2") {
                args.IsValid = false;
            } else {
                args.IsValid = true;
            }
        }

        function FileUploadValidate(sender, args) {
            if (window.File && window.FileList) {
                var fileUpload =
                    document.getElementById("<%=FileUpload1.ClientID%>");

                if (fileUpload.files[0] == null) {
                    args.IsValid = false;
                    return;
                }

                if (fileUpload.files[0].type != "image/jpeg") {
                    args.IsValid = false;
                    return;
                }


            } else {
                args.IsValid = true;
            }
            
        }

        //]]>
    </script>

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" 
    runat="server">

    <h1>CustomValidator</h1>
    <p>CustomValidator のクライアント側での検証のタイミング</p>

    <table>
        <tr>
            <td>
                TextBox
            </td>
            <td>
                <asp:TextBox ID="TextBox1" runat="server">
                </asp:TextBox>
            </td>
            <td>
                <asp:CustomValidator ID="CustomValidator1" 
                    runat="server" 
                    ForeColor="Red"
                    Display="Dynamic"
                    ErrorMessage="Gold または Silver でない" 
                    ClientValidationFunction="TextBoxValidate" 
                    ControlToValidate="TextBox1">
                </asp:CustomValidator>
            </td>
        </tr>
        <tr>
            <td>
                CheckBox
            </td>
            <td>
                <asp:CheckBox ID="CheckBox1" runat="server" />
            </td>
            <td>
                <%--ControlToValidate="CheckBox1" を設定すると
                    HttpException がスローされる。理由は CheckBox
                    には ValidationProperty 属性が付与されてない
                    から。なので submit しないと検証はかからない
                    --%>
                <asp:CustomValidator ID="CustomValidator2" 
                    runat="server"
                    ForeColor="Red"
                    Display="Dynamic"
                    ErrorMessage="チェック不可" 
                    ClientValidationFunction="CheckBoxValidate">
                </asp:CustomValidator>
            </td>
        </tr>
        <tr>
            <td>
                RadioButton
            </td>
            <td>
                <asp:RadioButton ID="RadioButton1" runat="server" />
            </td>
            <td>
                <%--ControlToValidate="RadioButton1" を設定すると
                    HttpException がスローされる。理由は RadioButton
                    には ValidationProperty 属性が付与されてないから。
                    なので submit しないと検証はかからない
                    --%>
                <asp:CustomValidator ID="CustomValidator3" 
                    runat="server"
                    ForeColor="Red"
                    Display="Dynamic"
                    ErrorMessage="選択不可" 
                    ClientValidationFunction="RadioButtonValidate">
                </asp:CustomValidator>
            </td>
        </tr>
        <tr>
            <td>
                DropDownList
            </td>
            <td>
                <asp:DropDownList ID="DropDownList1" runat="server">
                    <asp:ListItem>0</asp:ListItem>
                    <asp:ListItem>1</asp:ListItem>
                    <asp:ListItem>2</asp:ListItem>
                </asp:DropDownList>
            </td>
            <td>
                <asp:CustomValidator ID="CustomValidator4" 
                    runat="server"
                    ForeColor="Red"
                    Display="Dynamic"
                    ErrorMessage="2 は選択不可" 
                    ClientValidationFunction="DropDwonListValidate" 
                    ControlToValidate="DropDownList1">
                </asp:CustomValidator>
            </td>
        </tr>
        <tr>
            <td>
                FileUpload
            </td>
            <td>
                <asp:FileUpload ID="FileUpload1" runat="server" />
            </td>
            <td>
                <asp:CustomValidator ID="CustomValidator5" 
                    runat="server"
                    ForeColor="Red"
                    Display="Dynamic"
                    ErrorMessage="jpg ファイル以外不可" 
                    ClientValidationFunction="FileUploadValidate" 
                    ControlToValidate="FileUpload1">
                </asp:CustomValidator>
            </td>
        </tr>
    </table>
    <asp:Button ID="Button1" runat="server" Text="Submit" />

</asp:Content>

上のコードはマスターページを利用しています。先の記事「ASP.NET 4.5 ScriptManager」で書きましたように、ASP.NET 4.5 以降でクライアントスクリプトを利用するサーバーコントロールが正しく機能するには、必要なクライアントスクリプトの ScriptManager への登録と全ページでの ScriptManager の配置が必要です。マスターページを使ってそのあたりを解決しています。

Tags: , , ,

Validation

Visual Studio 2019 がフリーズする

by WebSurfer 21. June 2020 13:30

2020/7/10 追記: Developer Community フォーラムによると、この記事の問題は v16.6.3 で fix されているそうです。自分も v16.6.3 にバージョンアップ後は問題ないことを確認しました。

自分が使っている Visual Studio Cummunity 2019 のバージョンを 16.6.0 にアップグレードした後、[ヘルプ(H)]⇒[Microsoft Visual Studio のバージョン情報(A)]でバージョン情報を表示しようとすると、

ヘルプでバージョン情報を表示

以下の画像で示したようにビジー状態となってしまいます。一旦こうなってしまうと Visual Studio の操作が不能になってしまい、タスクマネージャーで Visual Studio を終了する他手がなくなってしまいます。

VS2019 がビジー状態

4 月に MySQL 8.0.19 をインストールしたのですが、その時同時にインストールされた MySQL for Visual Studio v1.2.9 との相性の問題が原因のようで、それを Visual Studio の[拡張機能(X)]⇒[拡張機能の管理()]で表示される「拡張機能の管理」ダイアログで無効にすると、

拡張機能の管理

以下の画像の通りバージョン情報は表示されるようになりました。(MySQL の何をインストールしたかの詳細は、先の記事「MySQL をインストールしました(その 3)」を参照ください)

バージョン情報

調べてみると、Microsoft の Developer Community フォーラム About Microsoft Visual Studio frozen で報告が上がっていて、MySQL for Visual Studio 以外にも Oracle Developer Tools for Visual Studio 2019 Version: 19.3.1.0 で同様な問題が出るそうです。

というわけで、どうしても Oracle の開発ツールを使う必要がある時以外は無効にしておいた方が良いかもしれません。自分が使ってきた限りではバージョン情報の表示以外の不具合は気が付かなかったのですが・・・

Developer Community フォーラムによると "A fix for this issue has been internally implemented and is being prepared for release." とのことですので、そのうち修正されることを期待してます。

Tags: , , ,

DevelopmentTools

Dispose パターン (その 2)

by WebSurfer 20. June 2020 13:32

先の記事「Dispose パターン」で、Visual Studio による Dispose パターンの自動生成機能の説明と、その機能を利用して自作カスタムクラスに Dispose パターンを実装する例を書きました。

この記事では Dispose パターンを実装済のクラスを継承してカスタムクラスを作成する際に、それに Dispose が必要な .NET のクラスのインスタンスを保持する場合、どのようなコードを書けばよいかについて述べます。

説明に ASP.NET MVC のプロジェクトを作成するテンプレートで ASP.NET Identity を実装した時に生成される AccountController の例を挙げます。自分が書いたコードで説明するより説得力があると思いますので。(笑)

Visual Studio が自動生成する Controllers/AccountController.cs のコードは以下のようになっています。この記事の説明に不要な部分は省略しています。

namespace Mvc5App2.Controllers
{
    [Authorize]
    public class AccountController : Controller
    {
        private ApplicationSignInManager _signInManager;
        private ApplicationUserManager _userManager;

        // ・・・中略・・・

        protected override void Dispose(bool disposing)
        {
            if (disposing)
            {
                if (_userManager != null)
                {
                    _userManager.Dispose();
                    _userManager = null;
                }

                if (_signInManager != null)
                {
                    _signInManager.Dispose();
                    _signInManager = null;
                }
            }

            base.Dispose(disposing);
        }

        // ・・・中略・・・
    }
}

AccountController の継承元 Controller クラスは IDisposable インターフェイスを継承しており Dispose パターンを実装しています。

フィールド _signInManager と _userManager には、ApplicationSignInManager と ApplicationUserManager が初期化されてそれらのオブジェクトへの参照が代入されるようにコーディングされています。

ApplicationSignInManager と ApplicationUserManager は継承元が IDisposable インターフェイスを継承しており Dispose パターンを実装しています。

AccountController には上に紹介した「Dispose パターン」の記事のような Dispose パターンのコードは実装できませんが、AccountController が Dispose されるときには _signInManager と _userManager も Dispose する必要があります。

というわけで、上のコードのように、Controller クラスが実装している Dispose(bool) メソッドをオーバーライドして _signInManager と _userManager が Dispose されるようにしています。

ASP.NET が要求の処理を終えてコントローラーをアンロードする際、自動的にコントローラーの Dispose() メソッドが実行されます。デバッガで上の Dispose(bool) メソッド内にブレークポイントを置いて実行し、AccountController のアクションメソッドを呼び出してみてください。Dispose(bool) メソッドに制御が飛んでくることで Dispose されるのが分かると思います。

(自分が試した限りですが、上の Dispose(bool) メソッドに制御が飛んでくる前のどこかで _signInManager と _userManager は Dispose されるようで、デバッガで値を調べると null になっていました。それゆえ null をチェックするコードが入っているようです)

次に、Windows Forms アプリの例を紹介します。下のコードは Visual Studio で自動生成されたフォームの .Designer.cs のコードです。(この記事の説明に不要な部分は省略しています)

namespace WindowsFormsApplication1
{
    partial class Form3
    {
        private System.ComponentModel.IContainer components = null;

        protected override void Dispose(bool disposing)
        {
            if (disposing && (components != null))
            {
                components.Dispose();
            }
            base.Dispose(disposing);
        }

        private void InitializeComponent()
        {
            this.components = new System.ComponentModel.Container();
            this.bindingSource1 = new BindingSource(this.components);
            this.bindingNavigator1 = new BindingNavigator(this.components);
            // ・・・中略・・・
        }

        // ・・・中略・・・
}

上のコードで Form3 は Form クラスを継承しており、Form クラスは Dispose パターンを実装しています。なので、上の AccountController の場合と同様に、Form クラスが実装している Dispose(bool) メソッドをオーバーライドし、内部で使用された Dispose が必要な .NET のクラスを Dispose するようになっています。

AccountController の場合と���違って .NET のクラスへの参照を直接 Dispose するのではなく、Container クラス(コンポーネントをカプセル化し追跡するコンテナ)にまとめて Dispose しています。

デザイナ画面で Dispose が必要なコントロールを Form にドラッグ&ドロップすると、.Designer.cs の InitializeComponent メソッド内に Container クラスを初期化し、そのコントロールを Container オブジェクトに追加するコードが自動生成されます。上のコード例では、BindingSource と BindingNavigator が Container オブジェクトに追加されています。

そのあたりの詳しい説明は @IT の記事「第4回 Visual Studio 2010のひな型コードを理解する (3/4)」が参考になると思います。

なお、デザイナ画面を使わないで自分でコードを書いた場合は、InitializeComponent メソッド内には上のようなコードは自動生成されませんので、.cs ファイルの方に自力でコードを書くことになります。具体例は別の記事「XML ファイルを DataGridView に表示」のコードを見てください。

また、IDisposable を継承しているクラスでも、全てが自動的に Container オブジェクトに追加されることはないです。例えば DataGridView クラスとか DataSet クラスがそうです。ホントに Dispose が必要かという疑問はありますが、IDisposable を継承しているクラスは使い終わったら Dispose するのが基本のようですので、上に紹介した記事のように自分でコードを書いて Container オブジェクトに追加した方がよさそうです。(初期化する前に Add しても無効のようですので注意してください)

Container オブジェクトに登録しておけば、フォームの右上の × 印アイコンをクリックするなどしてフォームを閉じる際に、自動的にフォームの Dispose() メソッドが実行され、上のコードの Dispose(bool) メソッドも実行されます。(これもブレークポイントを置いて実行してみれば、そこに制御が飛んでくることで Dispose されるのが分かると思います)

Tags: ,

.NET Framework

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  August 2020  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar