Anthony Moore
Microsoft Corporation
Octobre 2000
Résumé: Une explication détaillée sur l'utilisation d'ASP + pour vérifier les contrôles Web
Introduction
Cet article explique en détail le fonctionnement des contrôles de vérification ASP +. Si vous souhaitez générer une page complexe avec des contrôles de vérification ou si vous souhaitez étendre le cadre de vérification, il est conseillé de lire cet article. Si vous souhaitez apprendre à utiliser des contrôles de vérification ou à décider d'utiliser des contrôles de vérification, voir "Vérification de l'entrée utilisateur dans ASP + (anglais)".
commencer
Nous savons que tout au long du processus de développement ASP +, il est important de comprendre la vérification. En regardant la plupart des sites Web commerciaux aujourd'hui, vous verrez qu'il existe de nombreuses formes dans ces sites qui sont évidemment validées en exécutant beaucoup de code manuscrit. La rédaction du code de vérification n'est pas un travail intéressant. Il pourrait être engageant si vous souhaitez écrire du code pour afficher des tables de données ou générer des graphiques à la volée, mais personne ne peut confirmer à ses collègues que cette approche "cool" peut interdire les valeurs nulles 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 des utilisateurs, il ne peut donc pas appliquer de techniques qui peuvent être utilisées sur des clients plus entièrement fonctionnels, tels que les utilisateurs interdisant à saisir certains caractères ou bip. L'utilisation de scripts de navigateur peut entraîner une vérification plus puissante. Cependant, cette méthode est difficile à prouver car il n'y a pas nécessairement de scripts dans le navigateur du client, 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 sur le serveur.
Lors du développement d'ASP +, notre intention d'origine était d'utiliser un seul contrôle pour gérer la vérification, qui aurait pu être un contrôle de zone de texte qui pourrait afficher les erreurs. Mais quand je concevais le contrôle, j'ai trouvé que ce souhait ne pouvait pas être réalisé. Nous avons examiné un grand nombre de formulaires de saisie de données, essayant de trouver une solution qui pourrait fonctionner avec autant de formulaires que possible. Nous avons constaté que les formulaires de saisie de données ont de nombreuses fonctionnalités intéressantes:
Bien que les messages d'erreur ou les icônes soient souvent adjacents à l'élément d'entrée, ils sont presque toujours situés dans différentes cellules de la table.
Il y a souvent une zone dans 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 Vain de faire des allers-retours avec le serveur.
De nombreux sites contenant des scripts client affichent des cases d'informations lorsque des erreurs se produisent.
Non seulement l'entrée de texte valide, mais aussi les listes déroulantes et les boutons radio.
Si un champ est vide, le site affiche généralement un message ou une icône différente de celui de l'entrée invalide.
De nombreux contrôles de validité sont de bons remplacements pour les expressions couramment utilisées.
La vérification est généralement basée sur la comparaison entre deux entrées.
90% ou plus des tâches de vérification sont des opérations communes telles que les noms de vérification ou les codes postaux. La plupart des sites semblent encore faire ce travail à plusieurs reprises.
Parce que les différences entre les sites sont souvent trop grandes pour obtenir une solution parfaite pour gérer toutes les tâches de vérification pour chaque site.
En tenant compte de tout ce qui précède, la solution finale comprenait cinq commandes de validateur, le contrôle de validation engrais et l'intégration avec l'objet Page. Il est également évident que la solution doit être prolongée, et une API est nécessaire à la fois sur le client et le serveur pour coopérer.
Nous avons trouvé à travers diverses validations menées dans nos recherches que nous semblions avoir besoin d'une boîte à outils plus grande. Dans la plupart des environnements de composants, tels que Microsoft® ActiveX®, nous aurions pu tenter d'intégrer toutes les fonctionnalités du contrôle de vérification en un seul contrôle, gérant différentes propriétés dans différents modes. Heureusement, cependant, il existe un héritage magique dans le cadre Microsoft® .NET, qui fournit un ensemble de contrôles pour effectuer une validation spécifique de propriétés spécifiques, car l'effort supplémentaire requis pour dériver chaque nouveau contrôle est très faible.
La plupart des travaux effectués par ces contrôles sont mis en œuvre dans leur valeur de base de la mère commune. Vous pouvez également dériver de BaseValidator ou d'autres contrôles pour faire tout le travail. En fait, même BaseValidator est trop paresseux pour implémenter sa propre propriété de texte, mais hérite de la propriété Label.
Quand et que s'est-il passé?
Comprendre la séquence des événements est très efficace lorsque vous travaillez avec des pages contenant des contrôles Web de validation. Si une condition de vérification est facultative, vous devez savoir exactement quand la vérification est effectuée sur le client et le serveur. Si vous souhaitez rédiger votre propre routine de vérification, cela peut prendre beaucoup de temps ou avoir des effets secondaires. Dans le même temps, il est également important de comprendre le moment de l'appel de la routine de vérification.
Tout d'abord, jetons un œil au serveur.