Dans l'explication de la vérification ASP +
Anthony Moore
Microsoft Corporation
Octobre 2000
Résumé: Explications détaillées à l'utilisation du contrôle Web ASP + Vérification.
Table des matières
Brève introduction
commencer
Quand est-ce que ça arrive?
Séquence de vérification du côté serveur
Vérification du client
Règles efficaces et informations d'erreur utiles
Fonctions des propriétés activées, visibles et affichés
Contrôle de la valeur personnalisée
Quels contrôles peuvent être vérifiés?
Fin
------------------------------------------------ - - -------------------------------------------------- ------------------------
Brève introduction
Cet article explique en détail la méthode de travail du contrôle de vérification ASP +. Si vous souhaitez générer une page complexe qui contient le contrôle de vérification ou pour étendre le cadre de vérification, il est recommandé de lire cet article. Si vous souhaitez apprendre à utiliser le contrôle de vérification ou à décider d'utiliser le contrôle de vérification, voir "ASP + User entrez la vérification (anglais)".
commencer
Nous savons qu'il est important de comprendre la vérification pendant tout le processus de développement ASP +. Regardez la plupart des sites Web commerciaux d'aujourd'hui, vous constaterez qu'il existe de nombreuses formes dans ces sites, qui sont évidemment exécutées en exécutant un grand nombre de code manuscrit. La rédaction du code de vérification n'est pas un travail intéressant. Si vous écrivez un code pour afficher la table de données ou générer dynamiquement des graphiques, il peut être très attrayant, mais personne ne peut confirmer avec ses collègues que cette méthode "cool" peut interdire la valeur vide dans le champ de nom.
Pour d'autres raisons, la vérification des applications Web est également très gênante. HTML 3.2 a de nombreuses restrictions sur le contenu que vous pouvez contrôler ou les commentaires que vous pouvez obtenir de l'utilisateur, il ne peut donc pas être appliqué aux techniques qui peuvent être utilisées sur un client plus épanouissant, comme interdire aux utilisateurs de saisir certains caractères ou faire un son. L'utilisation du script de navigateur peut produire une vérification plus puissante. Cependant, cette méthode est difficile à confirmer, car le navigateur du client n'est pas nécessairement un script, et les utilisateurs malveillants peuvent le contourner. Par conséquent, afin d'assurer la sécurité du site, il est nécessaire d'effectuer la même inspection du serveur.
Lors du développement d'ASP +, notre intention d'origine est d'utiliser un seul contrôle pour traiter la vérification. Mais quand il a été conçu, j'ai constaté que ce désir ne pouvait pas être réalisé. Nous avons recherché un grand nombre de formulaires d'entrée de données pour trouver une solution qui peut être appliquée à autant de formes que possible. Nous avons constaté que le tableau d'entrée de données a de nombreuses fonctionnalités intéressantes:
Bien que les informations d'erreur ou les icônes soient souvent adjacentes aux éléments d'entrée, ils sont presque toujours situés dans différentes cellules de la table.
Il y a souvent une zone sur la page pour résumer toutes les erreurs.
De nombreux sites incluent des scripts clients pour fournir des commentaires plus rapides tout en empêchant les voyages entre le serveur en vain.
De nombreux sites contenant des scripts clients affichent des cases d'informations lorsqu'il y a une erreur.
Non seulement l'entrée du texte sera vérifiée, mais aussi la liste de drop -down et le bouton unique de sélection seront vérifiées.
Si un champ est vide, le site affiche généralement différentes informations ou icônes lorsque l'entrée n'est pas valide.
De nombreux examens efficaces peuvent être bien remplacés par des expressions couramment utilisées.
La vérification est généralement basée sur les résultats de comparaison entre deux entrées.
90% ou plus de 90% des tâches de vérification sont des opérations courantes, telles que le nom de vérification ou le code postal. La plupart des sites semblent encore répéter ces tâches.
Parce que la différence entre les sites est généralement trop grande, une solution parfaite ne peut pas être obtenue pour gérer toutes les tâches de vérification de chaque site.
Compte tenu de toutes les situations ci-dessus, les solutions finales incluent cinq commandes de dispositifs de vérification, valides de commandes d'études et intégration avec des objets page. Dans le même temps, il est évident que la solution doit être élargie et une API est nécessaire pour coopérer sur le client et le serveur.
Nous avons constaté que nous semblions avoir besoin d'une boîte à outils plus grande pendant les différentes vérifications de la recherche. Dans la plupart des environnements de composants, tels que Microsoft® ActiveX®, nous avons peut-être essayé d'intégrer les fonctions de tous les contrôles de vérification en un contrôle pour traiter différents attributs dans différents modes. Heureusement, il y a un héritage magique dans le cadre Microsoft® .NET.
La plupart de ces contrôles sont mis en œuvre dans leur Validator de niveau parent public. Vous pouvez également effectuer diverses tâches de BaseValidator ou d'autres commandes. En fait, même si BaseValidator est trop paresseux pour obtenir ses propres attributs de texte, il est hérité des attributs d'étiquette.
Quand est-ce que ça arrive?
Il est très efficace de comprendre la séquence d'événements lors du traitement de la page contenant la page du contrôle Web. Si une condition de vérification est facultative, vous devez comprendre avec précision quand le client et le serveur sont vérifiés. Si vous souhaitez rédiger une routine de vérification vous-même, cela peut être très temps ou effets secondaires. Dans le même temps, il est également important de comprendre le calendrier de la routine de vérification des appels.
Tout d'abord, jetons un coup d'œil au serveur.
Séquence de vérification du côté serveur
Il est important de comprendre la période de validité de la page. Si vous êtes habitué au traitement du formulaire dans les outils client Fonctionnels Visual Basic ou similaires, vous devez passer un certain temps pour comprendre. Tous les objets de la page et de la page ne sont pas efficaces lorsqu'ils interagissent avec les utilisateurs, bien que ce soit parfois la même chose.
Ce qui suit est une séquence d'événements simplifiée lors de la visite d'une page pour la première fois:
Créez une page et son contrôle basé sur le fichier ASPX.
Déclencher l'événement page_load.
Les attributs de page et de contrôle sont stockés dans un champ caché.
Les pages et les commandes sont converties en HTML.
Jetez tout.
Maintenant, lorsque l'utilisateur clique sur un bouton ou un contrôle similaire, il reviendra au serveur, puis exécutera une séquence d'événements similaire. Cette séquence est appelée la séquence de retour:
Créez une page et son contrôle basé sur le fichier ASPX.
Restaurez les attributs de page et de contrôle à partir du champ caché.
Entrez le contrôle de la page de mise à jour en fonction de l'utilisateur.
Déclencher l'événement page_load.
Déclencher des changements de notification.
Les attributs de page et de contrôle sont stockés dans un champ caché.
Les pages et les commandes sont converties en HTML.
Jetez tout à nouveau.
Pourquoi ne gardons-nous pas tous les objets en mémoire? Parce que les sites Web établis avec ASP + ne peuvent pas gérer un très grand nombre d'utilisateurs. Par conséquent, la mémoire du serveur ne conserve que le contenu à traiter immédiatement.
Quand est la vérification du serveur? Lors de l'obtention d'informations sur la page pour la première fois, la vérification du serveur ne sera pas du tout effectuée. La plupart des utilisateurs finaux sont très graves.
Dans la séquence d'événements de retour, la vérification sera effectuée entre l'étape 3 et l'étape 4. En d'autres termes, la vérification est après les attributs de contrôle de chargement des données de l'utilisateur, mais avant la majeure partie du nombre d'exécution de code. Cela signifie que lors de la rédaction d'événements utilisateur, il peut généralement être utilisé pour la vérification. Dans des circonstances normales, vous voudrez le faire.
L'inconvénient de la vérification à ce moment est: si vous souhaitez modifier certains attributs qui affectent la vérification par programmation, il sera trop tard. Par exemple, vous constaterez que si vous utilisez le code pour activer ou désactiver les attributs du contrôle de vérification ou modifier le contrôle de vérification, vous ne verrez aucun effet avant de traiter la page. Ce problème peut être évité à travers les deux méthodes suivantes:
Modifiez l'attribut avant vérification.
Re -very le contrôle après le changement d'attribut.
Les deux méthodes doivent utiliser des attributs de vérification et des méthodes efficaces sur l'objet page.
API de page
Les objets de page incluent certains attributs et méthodes importants liés à la vérification du serveur. Le tableau 1 résume ces attributs et méthodes:
Tableau 1. Attributs et méthodes de l'objet Page
Attribut ou description de la méthode
L'attribut isvalid est l'attribut le plus utile. Cet attribut peut vérifier si l'ensemble du formulaire est efficace. Ce chèque est généralement effectué avant de mettre à jour la base de données. Seuls tous les objets des validateurs sont valides, l'attribut est vrai et la valeur n'est pas stockée dans le cache.
Les validateurs attribuent la collecte de tous les objets de vérification de cette page. Il s'agit d'une collection d'objets qui implémentent l'interface ivalidator.
La méthode de valeur appelle une méthode lors de la vérification. La méthode d'exécution par défaut sur l'objet Page consiste à se tourner vers chaque périphérique de vérification et à nécessiter le périphérique de vérification pour s'évaluer.
La collection Validators est très utile pour de nombreuses tâches. Cet ensemble est une collection d'objets qui implémentent l'interface ivalidator. La raison pour laquelle j'utilise l'objet n'est pas le contrôle du contrôle car l'objet page ne fait attention qu'à l'interface ivalidator. Étant donné que toutes les vérifications sont généralement utilisées pour obtenir certains contrôles visuels de ivalidator, n'importe qui devrait être en mesure d'utiliser n'importe quel objet de vérification et d'ajouter l'objet de vérification à la page.
L'interface ivalidator contient les attributs et méthodes suivants:
Tableau 2. Les attributs et les méthodes de l'interface ivalidator
Attribut ou description de la méthode
L'attribut isvalid a souligné si le test de validité effectué par un objet de vérification distinct s'est écoulé. Vous pouvez modifier manuellement la valeur après vérification.
L'attribut ErrorMessage introduit l'erreur pour vérifier l'objet à vérifier et les erreurs qui peuvent être affichées à l'utilisateur.
La méthode Validate est vérifiée pour la validité de l'objet de vérification pour mettre à jour sa valeur isvalide.
Vous pouvez utiliser cette interface pour effectuer des tâches intéressantes. Par exemple, pour réinitialiser la page à un état efficace, utilisez le code suivant (comme l'exemple indiqué dans C #):
Valeur ivalidator;
Foreach (val dans les validateurs) {
valueValid = true;
}
Pour réécrire toute la séquence de vérification, utilisez le code suivant:
Valeur ivalidator;
Foreach (val dans les validateurs) {
Val.validate ();
}
Si vous avez une édition Beta 1 ou des versions supérieures, vous pouvez également appeler la méthode de valeur uniquement pour l'objet page, afin que la même tâche puisse être terminée. Pour apporter des modifications avant vérification, la méthode de valeur peut être couverte. Cet exemple montre une page contenant le périphérique de vérification, qui est ouvert ou désactivé en fonction de la valeur de la case:
Classe publique Conditionnel: Page {
public htmlinputcheckbox chksameas;
Public ResearchFieldValidator RfvalshipAddress;
Override protégé void validate () {) {)
// vérifie simplement l'adresse de livraison (si différente de l'adresse de paiement)
BOOL ARRIGHESHIP =!
rfValShipAddress.Enabled = CertiveShip;
// exécutant maintenant la vérification
base.validate ();
}
}
Vérification du client
Si votre page est activée par la vérification du client, une séquence d'événements complètement différente se produira pendant l'aller-retour. La vérification du client utilise le client JScript®. La vérification ne nécessite aucun composant binaire.
Bien que la normalisation de la langue JScript soit bien faite, le modèle d'objet de document (DOM) utilisé dans la documentation HTML dans le navigateur (DOM) n'a pas de normes largement utilisées. Par conséquent, la vérification du client n'est effectuée que dans Internet Explorer 4.0 et des versions supérieures, car l'objet vérifié est l'Internet Explorer Dom.
Du point de vue du serveur, la vérification du client signifie seulement que le contrôle de vérification envoie un contenu différent à HTML. De plus, la séquence incidente est exactement la même. La vérification du serveur est toujours effectuée. Bien qu'il semble redondant, il est très important car:
Certains contrôles de vérification peuvent ne pas prendre en charge le script client. Il y en a un bon exemple: si vous souhaitez utiliser les fonctions de vérification CustomValidator et Server en même temps, mais il n'y a pas de fonction de vérification du client.
Précautions de sécurité. Certaines personnes peuvent facilement obtenir une page contenant un script, puis désactiver ou modifier la page. Vous ne devez pas utiliser votre script pour empêcher les mauvaises données d'entrer dans votre système, mais uniquement pour que les utilisateurs puissent obtenir des commentaires plus rapides. Par conséquent, si vous souhaitez utiliser CustomValidator, vous ne devez pas fournir de fonction de vérification du client sans fonctions de vérification du serveur correspondantes.
Chaque contrôle de vérification peut garantir qu'un bloc de script client standard est envoyé à la page. En fait, ce n'est qu'une petite partie du code, qui contient une référence au code dans la bibliothèque de script webuivalidation.js. Ce fichier de bibliothèque de scripts contient toute la logique vérifiée par le client.
À propos de la bibliothèque de script
Étant donné que la vérification du script de contrôle Web se trouve dans la bibliothèque de scripts, le code vérifié par tous les clients n'est pas nécessaire pour l'envoyer directement à la page, bien qu'il semble être fait à la surface. Les références de fichier de script principal sont similaires à ce qui suit:
<Script Language = JavaScript
src = / _ aspx / 1.0.9999 / script / webuivalidation.js> </ script>
Par défaut, le fichier de script sera installé dans le répertoire racine par défaut dans le répertoire _aspx et utilise un script inclut l'instruction à appeler, qui commence par une ligne diagonale positive. La référence montre que chaque objet individuel n'a pas besoin d'inclure la bibliothèque de scripts, et toutes les pages du même ordinateur peuvent faire référence au même fichier. Vous remarquerez qu'il existe également un numéro de version publique dans ce chemin, afin que différentes versions d'exécution puissent s'exécuter sur le même ordinateur.
Si vous regardez votre répertoire racine virtuel par défaut, vous trouverez le fichier et afficherez le contenu. La position de ces fichiers est spécifiée dans le fichier config.web. Le fichier config.web est un fichier XML pour la plupart des paramètres ASP +. Ce qui suit est la définition de la position dans ce fichier:
<webcontrols
ClientScripTsLocation = / _ Aspx / {0} / script /
/>
Vous encourage à lire le script afin que vous puissiez comprendre les événements qui se produisent en profondeur. Cependant, il est recommandé de ne pas modifier ces scripts, car leurs fonctions sont étroitement liées à des versions d'exécution spécifiques. Lorsque la version est mise à jour, ces scripts peuvent également être mis à jour en conséquence. Si des projets spécifiques doivent être modifiés, sauvegardez d'abord ces scripts, puis pointez votre projet vers le fichier de sauvegarde, la méthode consiste à utiliser un fichier config.web privé pour remplacer la position de ces fichiers. Si la chaîne contient l'instruction du format {0}, le numéro de version remplacera l'instruction lorsque le numéro de version d'exécution sera remplacé. Il est préférable de changer cette position en une référence relative ou une référence absolue.
Désactiver la vérification du client
Parfois, vous ne voudrez peut-être pas vérifier les clients. Si le nombre de champs d'entrée est faible, la vérification du client peut ne pas être très utile. Après tout, vous devez avoir une logique qui nécessite un serveur rond à Trip à chaque fois. Vous constaterez que les informations dynamiques sur le client auront un impact négatif sur votre mise en page.
Pour désactiver la vérification du client, utilisez l'instruction de page clientTarget = Downlevel. Cette instruction est similaire au début du fichier ASPX:
<% @ Page Language = C # clientTarget = Downlevel%>
La valeur par défaut de cette instruction est automatique, indiquant que vous ne vérifiez que le client de Microsoft Internet Explorer 4.0 ou des versions supérieures.
Remarque: Malheureusement, dans la bêta 1, cette instruction n'est pas seulement désactivée pour la vérification, et en même temps, tous les contrôles Web utilisent des balises HTML 3.2 à traiter, qui peuvent avoir des résultats inattendus. La version finale offre un meilleur moyen de contrôler ce problème.
Séquence d'événements clients
Cette séquence est une séquence d'événements qui se produit lorsque la page contenant la vérification du client:
Lors du chargement du navigateur sur la page, vous devez initialiser chaque contrôle de vérification. Ces commandes sont envoyées sous forme de marque <span> et leurs fonctionnalités HTML sont les plus proches des fonctionnalités du serveur. Plus important encore, tous les éléments d'entrée référencés par le dispositif de vérification seront "pendus" pour le moment. L'élément d'entrée référencé modifiera son événement client pour appeler la routine de vérification lors de la saisie du changement.
Le code de la bibliothèque de scripts sera exécuté lorsque l'utilisateur utilise la touche Tab pour basculer entre chaque champ. Lorsqu'un certain champ indépendant est modifié, les conditions de vérification seront réévaluées et le dispositif de vérification sera visible ou invisible au besoin.
Lorsque l'utilisateur essaie de soumettre le formulaire, toutes les vérifications seront évaluées. Si toutes ces vérifications sont efficaces, le formulaire sera soumis au serveur. S'il y a une erreur dans un ou plusieurs endroits, la situation suivante se produira:
La soumission a été annulée. Le formulaire n'est pas soumis au serveur.
Toutes les vérifications non valides sont visibles.
Si un résumé de vérification contient showsummary = true, toutes les erreurs du contrôle de vérification seront collectées et le contenu est mis à jour avec ces erreurs.
Si un résumé de vérification contient ShowMessageBox = true, il collectera les erreurs et affichera ces erreurs dans la zone d'information du client.
Étant donné que le contrôle de vérification du client est effectué lorsque le contrôle de vérification du client est effectué à chaque changement d'entrée ou lors de la soumission, ces contrôles de vérification sont généralement évalués deux fois ou plus deux fois sur le client. Veuillez noter qu'après la soumission, ces contrôles de vérification seront toujours réévalués sur le serveur.