validation ASP.NET en profondeur

 

Anthony Moore
Microsoft Corporation

Octobre 2000
Mise à jour en mars 2002

Résumé: Examen détaillé du fonctionnement des contrôles web de validation ASP.NET. (15 pages imprimées)

Contenu

Introduction
Au début
Que se passe-t-il quand ?
séquence de validation Server-Side
validation Client-Side
Règles de validité et messages d’erreur significatifs
Effet des propriétés Enabled, Visible et Display
Contrôle CustomValidator
Quels contrôles peuvent être validés ?
Voilà

Introduction

Cet article décrit en détail le fonctionnement des contrôles de validation ASP.NET. Cet article est recommandé à tous ceux qui créent des pages complexes avec des contrôles de validation ou qui cherchent à étendre l’infrastructure de validation. Pour les personnes qui souhaitent commencer à utiliser les contrôles de validation ou décider de les utiliser, consultez Validation d’entrée utilisateur dans ASP.NET.

Au début

Tout au long du développement de ASP.NET, nous savions que l’aide à la validation était importante. Jetez un coup d’œil à la plupart des sites web commerciaux aujourd’hui et vous remarquerez qu’ils sont remplis de formulaires qui exécutent clairement beaucoup de code manuscrit pour effectuer la validation. Le code de validation n’est pas particulièrement sexy à écrire. Il peut être intéressant d’écrire du code pour afficher des tables de données ou générer dynamiquement des graphiques, mais personne n’obtient de ses collègues de case activée la manière cool d’empêcher quelqu’un d’entrer une valeur vide pour un champ de nom.

La validation des applications web est particulièrement frustrante pour d’autres raisons. HTML 3.2 est tellement limité dans ce que vous pouvez contrôler et les commentaires que vous recevez de l’utilisateur que vous ne pouvez pas appliquer les mêmes astuces que celles que vous pouvez utiliser sur un client plus riche, comme empêcher l’utilisateur d’entrer certains caractères ou faire des sons de bip. Il est possible de créer une validation plus puissante à l’aide d’un script de navigateur. Cela peut toutefois être difficile à justifier, car le script n’est pas toujours présent dans les navigateurs clients et peut être contourné par des utilisateurs malveillants. Il est donc nécessaire d’implémenter les mêmes vérifications sur le serveur de toute façon, afin d’avoir un site sécurisé.

Dans le développement de ASP.NET, notre intention initiale était d’avoir un seul contrôle pour gérer la validation, qui aurait été une version du contrôle TextBox qui pouvait également afficher des erreurs. Quand le moment est venu de concevoir le contrôle, cependant, il est devenu clair que cela ne couperait pas la moutarde. Nous avons examiné un grand nombre de formulaires de saisie de données et essayé de trouver une solution qui s’adapterait au plus grand nombre d’entre eux possible. Nous avons trouvé un certain nombre d’éléments intéressants concernant les formulaires de saisie de données :

• Il est courant d’avoir des messages d’erreur ou des icônes adjacents aux éléments d’entrée, mais ils sont presque toujours positionnés dans différentes cellules de tableau.
• Il est courant d’avoir une zone de la page où toutes les erreurs sont résumées.
• De nombreux sites contiennent un script côté client pour fournir des commentaires plus immédiats et éviter les allers-retours gaspiller vers le serveur.
• De nombreux sites qui ont un script côté client affichent des boîtes de message en cas d’erreurs.
• Ce ne sont pas seulement les entrées de texte qui sont validées. Les listes déroulantes et les cases d’option sont également fréquemment validées.
• Lorsqu’un champ est vide, les sites affichent généralement un message ou une icône différent de celui qu’ils affichent lorsque l’entrée n’est pas valide.
• De nombreux contrôles de validation sont d’excellents candidats pour les expressions régulières.
• Il est courant que la validité dépende des comparaisons entre les entrées.
• Parmi les tâches de validation, 90 % ou plus sont des opérations courantes telles que la vérification des noms et des codes postaux. La plupart des sites semblaient réinventer la roue.
• Il existe généralement trop de variations entre les sites pour disposer d’une solution parfaite capable d’effectuer 100 % des tâches de validation pour chaque site.

La prise en compte de tous ces points a conduit à la solution finale des cinq contrôles Validateator, du contrôle ValidationSummary et de l’intégration à l’objet Page . Il était également clair que la solution devait être extensible et qu’il fallait une API pour l’utiliser à la fois sur le client et le serveur.

Lorsque nous avons examiné les différents types de validation qui ont lieu, il nous a semblé que nous aurions besoin d’une boîte à outils plus grande. Dans la plupart des environnements de composants comme Microsoft® ActiveX®, nous aurions probablement essayé de surcharger les fonctionnalités de tous les contrôles de validation en un seul contrôle qui fonctionnait avec différentes propriétés dans différents modes. Toutefois, grâce à la magie de l’héritage dans Microsoft® .NET Framework, il est possible de fournir une suite de contrôles qui effectuent une validation spécifique avec des propriétés spécifiques, car la surcharge liée à la dérivation de chaque nouveau contrôle est très faible.

La plupart du travail effectué par ces contrôles est implémenté dans leur parent commun, BaseValidator. Vous pouvez également dériver de BaseValidator ou d’autres contrôles pour en tirer parti. En fait, même BaseValidator est trop paresseux pour implémenter sa propre propriété Text et hérite de Label.

Que se passe-t-il quand ?

Il est utile de comprendre la séquence d’événements lorsqu’une page avec des contrôles Web de validation est traitée. Si l’une des conditions de validation est facultative, vous souhaiterez savoir exactement quand la validation a lieu sur le client et le serveur. Si vous écrivez vos propres routines de validation qui peuvent prendre du temps ou qui ont des effets secondaires, il est également important d’avoir une idée du moment où elles seront appelées.

Tout d’abord, examinons le serveur.

séquence de validation Server-Side

Il est important de comprendre le cycle de vie d’une page. Pour ceux qui sont habitués à utiliser des formulaires en Visual Basic ou des outils clients riches similaires, il faut un peu de s’y habituer. Une page et tous les objets qu’elle contient ne vivent pas réellement tant qu’un utilisateur interagit avec eux, même s’il peut parfois sembler que c’est le cas.

Voici une séquence simplifiée d’événements lors de la première consultation d’une page :

1. La page et ses contrôles sont créés, en fonction du fichier ASPX.
2. Page_Load événement se déclenche.
3. Les propriétés de page et de contrôle sont enregistrées dans un champ masqué.
4. La page et les contrôles sont convertis en HTML.
5. Tout est jeté.

Maintenant, lorsqu’un utilisateur clique sur un bouton ou un contrôle similaire, il retourne au serveur et effectue une séquence similaire. C’est ce qu’on appelle la séquence post-retour :

1. La page et ses contrôles sont créés en fonction du fichier ASPX.
2. Les propriétés de page et de contrôle sont récupérées à partir du champ masqué.
3. Les contrôles de page sont mis à jour en fonction de l’entrée de l’utilisateur.
4. Page_Load événement se déclenche.
5. Les événements de notification de modification se déclenchent.
6. Les propriétés de page et de contrôle sont enregistrées dans un champ masqué.
7. La page et les contrôles sont convertis en HTML.
8. Tout est jeté à nouveau.

Pourquoi ne pas simplement garder tous les objets en mémoire ? Étant donné que les sites web sont générés avec ASP.NET ne fonctionne pas avec un très grand nombre d’utilisateurs. De cette façon, les seuls objets en mémoire sur le serveur sont des éléments en cours de traitement en ce moment.

Quand la validation côté serveur a-t-elle lieu ? Eh bien, il n’a pas lieu du tout sur la première extraction de page. La plupart de nos utilisateurs finaux sont très diligents, et nous voulons leur donner le bénéfice du doute qu’ils rempliront correctement le formulaire avant de les bombarder de texte rouge.

Sur la post-retour, la validation a lieu à l’étape 5, juste avant que l’événement ne se déclenche pour le bouton ou le contrôle qui a déclenché la validation. Les contrôles de bouton dans ASP.NET ont une propriété appelée CausesValidation qui a la valeur true par défaut. C’est l’action de cliquer sur des boutons qui rend la validation possible. Le meilleur endroit pour case activée les résultats de la validation se trouve dans le gestionnaire d’événements qui a déclenché la validation. Vous pouvez également avoir des boutons avec CausesValidation=False, qui n’entraînent aucune évaluation des validateurs.

Une chose potentiellement déroutante à propos de ce moment est que les validateurs n’auront pas été évalués au moment où Page_Load est déclenché. L’avantage est que cela vous donne la possibilité de modifier par programmation les valeurs de propriété affectant la validité de la page, par exemple en activant ou en désactivant certains validateurs.

Si ce moment n’est pas à votre goût et que vous préférez tout évaluer dans Page_Load, vous pouvez le faire en déclenchant explicitement la validation pendant cet événement en appelant Page.Validate. Une fois cette opération appelée, vous pouvez case activée le résultat de Page.IsValid. Si vous essayez d’interroger le résultat de Page.IsValid avant que Page.Validate n’ait été appelé, soit explicitement, soit en cours de déclenchement par un bouton avec CausesValidation=True, sa valeur n’a aucun sens. Une exception sera levée.

The Page API

L’objet Page possède des propriétés et des méthodes importantes en ce qui concerne la validation côté serveur. Elles sont récapitulées dans le tableau 1 :

Tableau 1. Propriétés et méthodes de l’objet Page

Propriété ou méthode	Description
Propriété IsValid	Il s’agit de la propriété la plus utile. Il vous permet de case activée si l’intégralité du formulaire est valide. Cette opération est généralement effectuée avant d’effectuer une mise à jour de base de données. Elle est vraie uniquement si tous les objets de la collection Validateurs sont valides et qu’elle ne met pas en cache cette valeur.
Validateurs, propriété	Collection de tous les objets de validation de la page. Il s’agit d’une collection d’objets qui implémentent l’interface IValidator.
Validate , méthode	Méthode appelée au moment de la validation. L’implémentation par défaut sur Page est envoyée à chaque validateur et lui demande de s’évaluer elle-même.

La collection Validateurs est utile pour un certain nombre de choses. Il s’agit d’une collection d’objets de qui implémentent l’interface IValidator. J’utilise le terme objets plutôt que les contrôles, car la Page se soucie uniquement de l’interface IValidator. Bien qu’il arrive que tous les validateurs soient généralement des contrôles visuels qui implémentent IValidator, il n’y a aucune raison que quelqu’un ne puisse pas venir avec un objet de validation arbitraire et l’ajouter à la page.

L’interface IValidator possède les propriétés et méthodes suivantes :

Tableau 2. Propriétés et méthodes de l’interface IValidator

Propriété ou méthode	Description
Propriété IsValid	Indique si l’case activée de validation effectuée par l’objet de validation individuel a réussi. Vous pouvez modifier manuellement cette valeur une fois la validation effectuée.
Propriété ErrorMessage	Décrit l’erreur que l’objet de validation valide et qui peut être affichée à l’utilisateur.
Validate , méthode	Exécute la case activée de validation de l’objet de validation pour mettre à jour sa valeur IsValid.

Vous pouvez faire des choses intéressantes avec cette interface. Par exemple, pour rétablir l’état valide de la page, utilisez le code suivant (exemples illustrés en C#) :

    IValidator val;
    foreach(val in Validators) {
        Val.IsValid = true;
    }

Pour réexécutar l’ensemble de la séquence de validation, utilisez le code suivant :

    IValidator val;
    foreach(val in Validators) {
        Val.Validate();
    }

Cela équivaut à appeler la méthode Validate() sur Page.

Une autre façon d’apporter des modifications avant la validation consiste à remplacer la méthode Validate . Cet exemple montre une page qui contient un validateur activé ou désactivé en fonction de la valeur d’une case à cocher :

    public class Conditional : Page {
        public HtmlInputCheckBox chkSameAs;
        public RequiredFieldValidator rfvalShipAddress;

        public override void Validate() {
            // Only check ship address if not same as billing
            bool enableShip = !chkSameAs.Checked;
            rfvalShipAddress.Enabled = enableShip;
            // Now perform validation
            base.Validate();
        }
    }

validation Client-Side

Si la validation côté client est activée pour votre page, une séquence différente se produit entre les allers-retours. La validation côté client fonctionne à l’aide du client JScript®. Aucun composant binaire n’est nécessaire pour que cela fonctionne.

Bien que le langage JScript soit relativement bien standardisé, le modèle DOM (Document Object Model) pour l’interaction avec les documents HTML dans les navigateurs n’avait pas de norme largement adoptée au moment du développement et du test de ces composants. Par conséquent, la validation côté client n’a lieu que dans Internet Explorer 4.0 et versions ultérieures, car elle cible Internet Explorer DOM.

Du point de vue du serveur, la validation côté client signifie simplement que les contrôles de validation émettent des éléments différents dans le code HTML. En outre, leur séquence d’événements est exactement la même. Les vérifications côté serveur sont toujours effectuées. Cela peut sembler redondant, mais il est important pour les raisons suivantes :

• Certains contrôles de validation peuvent ne pas prendre en charge les scripts client. Un bon exemple : si vous utilisez un CustomValidator avec une fonction de validation de serveur, mais aucune fonction de validation cliente.
• Considérations sur la sécurité. Quelqu’un peut très facilement prendre une page avec un script et la désactiver ou la modifier. Vous ne devez pas compter sur un script pour empêcher l’entrée de données incorrectes dans votre système, mais pour fournir des commentaires plus immédiats à vos utilisateurs. Pour cette raison, si vous utilisez un CustomValidator, vous ne devez pas fournir une fonction de validation cliente sans une fonction de validation de serveur correspondante.

Chaque contrôle de validation garantit qu’un bloc standard de script client est émis dans la page. Il s’agit en fait d’une petite quantité de script qui inclut une référence au code dans une bibliothèque de scripts appelée WebUIValidation.js. Ce fichier, qui est téléchargé séparément et qui peut être mis en cache par le navigateur, contient toute la logique de validation côté client.

À propos de la bibliothèque de scripts

Étant donné que le web de validation contrôle le script qui se trouve dans une bibliothèque de scripts, il n’est pas nécessaire d’émettre tout le code pour la validation côté client directement dans la page, bien qu’il agisse comme si c’est ce qui s’est produit. La référence du fichier de script main ressemble à ceci :

<script language="javascript" 
        src="/aspnet_client/system_web/1_0_3617_0/WebUIValidation.js">
</script>

Par défaut, le fichier de script est installé dans votre racine par défaut dans le répertoire aspnet_client, et il est référencé à l’aide d’une directive include de script relative à la racine, qui commence par la barre oblique. Cette référence signifie que chaque projet individuel n’a pas besoin d’inclure la bibliothèque de scripts à l’intérieur de celui-ci, et que toutes les pages d’un même ordinateur peuvent référencer le même fichier. Vous remarquerez qu’il a également le numéro de version common language runtime dans le chemin d’accès, de sorte que différentes versions du runtime peuvent s’exécuter sur la même machine.

Si vous examinez votre racine virtuelle par défaut, vous pouvez trouver ce fichier et y jeter un coup d’œil. L’emplacement de ces fichiers est spécifié dans le fichier machine.config, un fichier XML utilisé pour la plupart des paramètres ASP.NET. Voici la définition de l’emplacement dans ce fichier :

        <webControls
            clientScriptsLocation="/aspnet_client/{0}/{1}/"
        />

Nous vous encourageons à lire le script pour en savoir plus sur ce qui se passe. Toutefois, il n’est pas recommandé de modifier ces scripts, car leur fonction est très étroitement liée à une version particulière de l’exécution. Si l’exécution est mise à jour, les scripts peuvent avoir besoin d’une mise à jour correspondante et vous devrez soit perdre vos modifications, soit faire face à des problèmes avec les scripts qui ne fonctionnent pas. Si vous devez modifier les scripts d’un projet particulier, prenez une copie des fichiers et pointez votre projet vers ceux-ci en remplaçant l’emplacement des fichiers par un fichier web.config privé. Il est tout à fait correct de faire de cet emplacement une référence relative ou absolue.

Désactivation de la validation Client-Side

Dans certains cas, vous ne souhaitez peut-être pas la validation côté client. Si le nombre de champs d’entrée est très faible, la validation côté client peut ne pas être très utile. Vous pouvez avoir une logique qui nécessite un aller-retour au serveur à chaque fois. Vous constaterez peut-être que les messages qui apparaissent dynamiquement sur le client ont un impact négatif sur votre disposition.

Note La façon de désactiver la validation côté client consiste à définir la propriété EnableClientScript du validateur ou du contrôle ValidationSummary sur False. Il est possible d’avoir un mélange de composants de validation serveur uniquement et serveur client sur la même page.

Séquence Client-Side

Il s’agit de la séquence d’événements lorsqu’une page avec validation côté client s’exécute :

1. Lorsque la page est chargée dans le navigateur, une initialisation est effectuée sur chaque contrôle de validation. Les contrôles sont émis sous forme <de balises d’étendue> avec des attributs HTML qui correspondent étroitement à leurs propriétés sur le serveur. La chose la plus importante qui se produit ici est que tous les éléments d’entrée référencés par les validateurs sont « branchés ». Les éléments d’entrée référencés ont leurs événements clients modifiés afin que les routines de validation soient appelées chaque fois que l’entrée est modifiée.
2. Le code dans la bibliothèque de scripts sera exécuté sous forme d’onglet utilisateurs d’un champ à l’autre. Les conditions de validation sont réévaluées lorsqu’un champ dépendant est modifié et que le validateur est rendu visible ou invisible le cas échéant.
3. Lorsque l’utilisateur appuie sur un bouton dont la propriété CausesValidation est définie sur True, les validateurs sont tous réévalués. S’ils sont tous valides, le formulaire est publié sur le serveur. S’il existe une ou plusieurs erreurs, un certain nombre de choses se produisent :
   • L’envoi est annulé. Le formulaire n’est pas publié sur le serveur.
   • Tous les validateurs non valides deviennent visibles.
   • S’il existe un résumé de validation avec ShowSummary=true, il collecte toutes les erreurs des contrôles de validation et met à jour son contenu avec eux.
   • S’il existe un résumé de validation avec ShowMessageBox=true, il collecte les erreurs et les affiche dans la boîte de message du client.

Étant donné qu’ils sont exécutés chaque fois que les entrées changent ainsi qu’au moment de l’envoi, les contrôles de validation côté client évaluent généralement deux ou plusieurs fois sur le client. N’oubliez pas qu’ils seront toujours réévalués sur le serveur une fois l’envoi effectué.

The Client-Side API

Il existe une mini-API que vous pouvez utiliser sur le client pour obtenir différents effets avec votre propre code côté client. Étant donné qu’il n’est pas possible de masquer certaines routines, vous pouvez théoriquement utiliser les variables, attributs et fonctions définis par le script de validation côté client. Toutefois, la plupart d’entre eux sont des détails d’implémentation qui peuvent être modifiés. Voici un résumé des objets côté client que nous vous encourageons à utiliser.

Tableau 3. Objets côté client

Nom	Type	Description
Page_IsValid	Variable booléenne	Indique si la page est actuellement valide. Les scripts de validation le maintiennent à jour à tout moment.
Page_Validators	Tableau d’éléments	Il s’agit d’un tableau contenant tous les validateurs de la page.
Page_ValidationActive	Variable booléenne	Indique si la validation doit avoir lieu. Définissez cette variable sur False pour désactiver la validation par programme.
isvalid	Propriété booléenne	Il s’agit d’une propriété sur chaque validateur client qui indique si elle est actuellement valide.

Contournement de la validation du client

Une tâche courante que vous devrez peut-être effectuer consiste à disposer d’un bouton « Annuler » ou d’un bouton de navigation sur une page. Dans ce cas, définissez la propriété CausesValidation sur le bouton sur False et aucune validation n’aura lieu, que ce soit sur le serveur ou sur le client. Si vous créez une page comme celle-ci, vous souhaiterez case activée Page.IsValid dans vos gestionnaires de bouton. Si vous appelez plutôt Page.Validate pendant Page_Load, vous n’aurez pas de moyen de savoir si un bouton d’envoi ou d’annulation a été poussé.

Effets spéciaux

Une autre exigence courante consiste à avoir des effets autres que les messages d’erreur affichés par les validateurs eux-mêmes dans les situations d’erreur. Dans ce cas, toutes les modifications de comportement que vous apportez doivent être effectuées sur le serveur et sur le client. Supposons que vous souhaitiez avoir une étiquette qui change de couleur selon qu’une entrée est valide ou non. Voici comment procéder sur le serveur :

public class ChangeColorPage : Page {
    public Label lblZip;
    public RegularExpressionValidator valZip;
    
protected override void OnLoad(EventArgs e) {     
    Page.Validate();       
        lblZip.ForeColor = valZip.IsValid? Color.Black : Color.Red;
    }               
}

C’est très agréable, mais chaque fois que vous modifiez la validation comme celle-ci, vous pouvez constater qu’elle semble incohérente, sauf si vous effectuez une opération équivalente sur le client. Les frameworks de validation vous évitent beaucoup de ce double effort, mais pour des effets supplémentaires, il vous suffit de le faire à deux endroits. Voici un fragment client qui fait la même chose :

<asp:Label id=lblZip runat=server 
   Text="Zip Code:"/> 
<asp:TextBox id=txtZip runat=server 
   OnChange="txtZipOnChange();" /></asp:TextBox><br>
<asp:RegularExpressionValidator id=valZip runat=server
   ControlToValidate=txtZip
   ErrorMessage="Invalid Zip Code" 
   ValidationExpression="[0-9]{5}" /><br>

<script language=javascript>
function txtZipOnChange() {
   // Do nothing if client validation is not active
   if (typeof(Page_Validators) == "undefined")  return;
   // Change the color of the label
   lblZip.style.color = valZip.isvalid ? "Black" : "Red";
}
</script>

API Client-Side

Certains scénarios supplémentaires sont activés par des fonctions qui peuvent être appelées à partir de votre script côté client.

Tableau 4. Fonctions appelées à partir d’un script côté client

Nom	Description
ValidatorValidate(val)	Prend un validateur client comme entrée. Rend le validateur case activée son entrée et met à jour son affichage.
ValidatorEnable(val, enable)	Prend un validateur client et une valeur booléenne. Active ou désactive un validateur client. Le fait d’être désactivé l’empêche d’évaluer et il apparaît toujours valide.
ValidatorHookupControl(control, val)	Prend un élément HTML d’entrée et un validateur client. Modifie ou crée l’événement de modification de l’élément afin qu’il met à jour le validateur en cas de modification. Cela peut être utile pour les validateurs personnalisés qui dépendent de plusieurs valeurs d’entrée.

Il est particulièrement pratique d’activer ou de désactiver les validateurs. Si vous avez la validation que vous voulez actif uniquement dans certains scénarios, vous devrez peut-être modifier l’activation sur le serveur et le client, ou vous constaterez que l’utilisateur ne peut pas envoyer la page.

Voici l’exemple précédent avec un champ qui ne doit être validé que lorsqu’une case case activée est décochée :

    public class Conditional : Page {
        public HtmlInputCheckBox chkSameAs;
        public RequiredFieldValidator rfvalShipAddress;
        public override void Validate() {
            bool enableShip = !chkSameAs.Checked;
            rfvalShipAddress.Enabled = enableShip;
            base.Validate();
        }
    }

Voici l’équivalent côté client :

<input type=checkbox runat=server id=chkSameAs 
   onclick="OnChangeSameAs();" >Same as Billing<br>
<script language=javascript>
function OnChangeSameAs() {
    var enableShip = !event.srcElement.status;
    ValidatorEnable(rfvalShipAddress, enableShip);
}
</script>

Règles de validité et messages d’erreur significatifs

Chaque validateur affiche un message d’erreur spécifique concernant une condition spécifique sur un contrôle spécifique. Il existe des règles relatives à ce qui est considéré comme valide qui peuvent au premier abord sembler déroutantes pour vous en tant que développeur, mais elles sont nécessaires pour vous permettre de construire des messages d’erreur qui sont réellement utiles à l’utilisateur.

Tous les validateurs (à l’exception de RequiredFieldValidator) sont considérés comme valides s’ils sont vides. Si une valeur vide n’est pas valide, vous devez généralement fournir un RequiredFieldValidator en plus d’un autre validateur. Vous devez le faire, car presque tous les messages d’erreur sont souhaités pour le caractère vide et la validité. Sinon, vous vous retrouvez avec des messages confus comme « Vous devez entrer une valeur et elle doit être comprise entre 1 et 10 ».

Une autre règle spéciale concerne CompareValidator et RangeValidator lorsque les champs d’entrée ne peuvent pas être convertis vers le type de données spécifié. L’évaluation de la validité de CompareValidator avec ControlToCompare spécifié se présente comme suit :

1. Si le champ d’entrée référencé par ControlToValidate est vide, il est valide.
2. Si le champ d’entrée référencé par ControlToValidate ne peut pas être converti en type de données, il n’est pas valide.
3. Si le champ d’entrée référencé par ControlToCompare ne peut pas être converti en type de données, il est valide.
4. Les champs d’entrée sont convertis en type de données et comparés.

La troisième étape peut sembler un peu contre-intuitive. L’étape fonctionne de cette façon, car il serait difficile d’écrire un message d’erreur significatif pour le validateur s’il vérifiait la validité de plusieurs champs à la fois. Un validateur distinct doit être utilisé pour signaler les conditions d’erreur dans le champ d’entrée ControlToCompare. RangeValidator fonctionne de la même manière avec ses propriétés maximales et minimales.

Effet des propriétés Enabled, Visible et Display

La différence entre les propriétés Enabled, Visible et Display sur les validateurs peut ne pas être immédiatement évidente.

Display=None peut être utilisé pour spécifier un validateur qui n’affiche rien directement, mais qui est toujours évalué, affecte toujours la validité globale et peut toujours placer une erreur dans le résumé sur le client et le serveur. Pour la validation côté client, ces valeurs déterminent si les attributs de visibilité ou de style d’affichage sont utilisés pour activer ou désactiver le validateur. Pour la validation côté serveur, Display=Dynamic signifie que rien ne s’affiche quand l’entrée est valide, tandis que Display=Static signifie qu’un seul espace non déstructurant («& nbsp ») est émis. Ce dernier comportement existe afin que les cellules de tableau contenant uniquement des validateurs ne se réduisent à rien lorsqu’elles sont valides.

Pourquoi ne pas simplement utiliser Visible=false pour avoir un validateur invisible ? Dans ASP.NET la propriété Visible d’un contrôle a une signification très forte : un contrôle avec Visible=false ne sera pas traité du tout pour le pré-rendu ou le rendu. En raison de cette signification plus forte, Visible=false pour un validateur signifie que non seulement il n’affiche rien, mais ne fonctionne pas non plus. Elle n’est pas évaluée, n’affecte pas la validité de la page et ne met pas d’erreurs dans le résumé.

Bande de roulement activée ici. Pour la plupart, Enabled=false a exactement le même effet que Visible=false. Toutefois, dans la validation côté client, un validateur désactivé est toujours envoyé au navigateur, mais dans un état désactivé. Vous pouvez l’activer avec la fonction ValidatorEnable dans le script client.

Lorsque vous utilisez Visible ou Activé pour contrôler si la validation a lieu, gardez à l’esprit la séquence d’événements sur le serveur ci-dessus. Modifiez-les avant la validation, ou validez à nouveau par la suite. Sinon, leurs valeurs IsValid peuvent ne pas refléter les modifications apportées à leurs propriétés.

Contrôle CustomValidator

Le moyen le plus simple d’étendre l’infrastructure de validation consiste à utiliser le contrôle CustomValidator. Cela peut être utilisé pour effectuer une validation qui n’est pas couverte par quelque chose qu’un autre contrôle de validation peut effectuer ou pour effectuer une validation qui nécessite l’accès aux informations sur le serveur, telles qu’une base de données ou un service Web.

Si vous ajoutez un CustomValidator avec uniquement une fonction de validation serveur définie, vous remarquerez qu’elle ne participe pas à la validation côté client. CustomValidator n’est pas mis à jour en tant qu’onglet utilisateurs entre les champs et nécessite un aller-retour vers le serveur pour effectuer sa validation. Si vous utilisez un CustomValidator pour effectuer une case activée qui n’a pas besoin d’informations qui résident sur le serveur, vous pouvez également faire en ce que votre validateur participe pleinement à la validation côté client à l’aide de la propriété ClientValidationFunction. Il est supposé que si vous fournissez un ClientValidationFunction, il doit idéalement effectuer exactement les mêmes vérifications que votre gestionnaire de validation de serveur. À défaut, elle doit effectuer un sous-ensemble de cette vérification. Ne disposez pas d’une fonction de validation du client qui effectue plus de vérifications que celles effectuées sur le serveur, car les pirates pourront facilement la contourner.

Voici un exemple simple d’un CustomValidator qui fonctionne sur le client et le serveur qui vérifie simplement que l’entrée est un nombre pair. Tout d’abord, voici la fonction serveur (en C#) :

protected void ServerValidate(object source, ServerValidateEventArgs args) {
    try { 
        int i = Int32.Parse(args.Value);
        args.IsValid = ((i % 2) == 0);
    } catch {
        args.IsValid = false;
    }        
}

Voici comment il est déclaré sur le client, ainsi qu’une fonction de validation du client qui effectue la même case activée. Il s’agit généralement de JScript, bien qu’il puisse également s’agir de VBScript® si vous ciblez Microsoft® Internet Explorer.

<asp:CustomValidator id="CustomValidator1" runat="server" 
    ErrorMessage="Number not divisible by 2!" 
    ControlToValidate="txtCustomData" 
    OnServerValidate="ServerValidate" 
    ClientValidationFunction="CheckEven" /><br>
Input:
<asp:TextBox id="txtCustomData" runat="server" />
<script language="javascript">
<!--
function CheckEven(source, args) {
    var val = parseInt(args.Value, 10);
    if (isNaN(val)) {
        args.IsValid = false;
    }
    else {
        args.IsValid = ((val % 2) == 0);
    }
}
// -->
</script>

Voici quelques points à noter sur l’utilisation de CustomValidator :

• Comme tous les autres contrôles de validation (en plus de RequiredFieldValidator), il est considéré comme valide si le champ d’entrée est vide.
• Pour les navigateurs plus anciens ou lorsque la validation du client est désactivée, votre fonction de validation cliente n’est pas appelée. Vous n’avez pas besoin de case activée les fonctionnalités du navigateur vous-même avant de définir la fonction, mais vous devez vous assurer qu’elle ne provoque pas d’erreurs de script simplement en étant défini. Placez toujours votre code client dans un commentaire HTML, comme dans l’exemple.
• Deux paramètres sont passés à votre fonction cliente, correspondant aux paramètres passés à la fonction serveur. Le premier est l’élément de validateur client et le second est l’équivalent des arguments sur le serveur. Il a deux propriétés, la Valeur, qui contient l’entrée à valider et IsValid, que vous pouvez mettre à jour pour indiquer la validité.
• Vous pouvez laisser controlToValidate vide. Dans ce mode, la fonction serveur se déclenche toujours une fois par aller-retour et la fonction cliente se déclenche toujours une fois pour chaque tentative d’envoi. Vous pouvez l’utiliser pour valider des contrôles qui ne peuvent pas être validés autrement, tels qu’une case d’option CheckBoxList ou autonome. Elle peut également être utile lorsque la condition est basée sur plusieurs contrôles et que vous ne souhaitez pas qu’elle soit évaluée en tant qu’onglets utilisateur entre les champs de la page.
• Vous pouvez également connecter les événements de modification de plusieurs contrôles. Pour ce faire, vous pouvez disposer d’un script inline qui appelle la fonction cliente ValidatorHookupControl, décrite ci-dessus.

Quels contrôles peuvent être validés ?

Pour être référencé par un contrôle de validation, un contrôle doit avoir une propriété de validation. Tous les contrôles qui peuvent être validés ont une valeur ValidationPropertyAttribute, qui indique la propriété à lire à des fins de validation. Si vous écrivez votre propre contrôle, vous pouvez le faire participer à la validation en fournissant l’un de ces attributs pour spécifier la propriété à utiliser.

Pour que la validation fonctionne également côté client, cette propriété doit correspondre à l’attribut value de l’élément HTML qui est rendu sur le client. De nombreux contrôles complexes tels que DataGrid et Calendar n’ont pas de valeur sur le client et ne peuvent être validés que sur le serveur. C’est pourquoi seuls les contrôles qui correspondent étroitement aux éléments HTML peuvent être impliqués dans la validation. En outre, un contrôle doit avoir une seule valeur logique sur le client. C’est pourquoi RadioButtonList peut être validé, mais CheckBoxList ne peut pas.

Voilà

C’est probablement plus que ce que vous vouliez savoir sur ASP.NET validation. Amusez-vous !

© Microsoft Corporation. Tous droits réservés.