Vérification du client
Si votre page a une authentification client activée, une séquence d'événements complètement différente se produit pendant l'aller-retour. L'authentification client est implémentée à l'aide du client JScript®. Aucun composant binaire n'est nécessaire pour mettre en œuvre cette vérification.
Bien que le langage JScript soit bien standardisé, il n'y a pas de norme largement adoptée pour le modèle d'objet de document (DOM) utilisé pour interagir avec les documents HTML dans le navigateur. Par conséquent, l'authentification du client n'est effectuée que dans Internet Explorer 4.0 et plus tard parce que l'objet d'authentification est Internet Explorer Dom.
Du point de vue du serveur, la vérification du client signifie seulement que le contrôle de vérification envoie différents contenus à HTML. En dehors de cela, sa séquence d'événements est exactement la même. La vérification côté serveur est toujours exécutée. Bien que cela puisse sembler redondant, il est très important car:
Certains contrôles de vérification peuvent ne pas prendre en charge les scripts clients. Il y a un bon exemple: si vous souhaitez utiliser les fonctions de vérification CustomValidator et Server, 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 avec des scripts, puis désactiver ou modifier cette page. Vous ne devez pas utiliser les scripts pour empêcher les mauvaises données d'entrer dans votre système, mais juste pour obtenir des commentaires plus rapides des utilisateurs. Par conséquent, si vous souhaitez utiliser CustomValidator, vous ne devez pas fournir de fonction de vérification du client sans la fonction de vérification du serveur correspondant.
Chaque contrôle de vérification garantit qu'un bloc de script client standard est envoyé à la page. En fait, ce n'est qu'une petite partie du code qui contient des références au code dans la bibliothèque de script webuivalidation.js. Ce fichier de bibliothèque de scripts contient toute la logique pour la vérification du client.
À propos de la bibliothèque de script
Étant donné que le script de contrôle Web de vérification se trouve dans la bibliothèque de scripts, il n'est pas nécessaire d'envoyer tout le code vérifié par le client directement à la page, bien qu'il semble le faire à la surface. Les références de fichiers de script principales ressemblent à ceci:
<Script Language = "JavaScript"
src = "/ _ aspx / 1.0.9999 / script / webuivalidation.js"> </ script>
Par défaut, le fichier de script est installé dans le répertoire racine par défaut dans le répertoire "_aspx" et est appelé avec le script racine-relatif inclue la directive, qui commence par une barre oblique. Cette référence indique que chaque objet individuel n'a pas à contenir de 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 d'exécution de langage commun 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 de celui-ci. L'emplacement de ces fichiers est spécifié 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 l'emplacement dans le fichier:
<webcontrols
clientScriptsLocation = "/ _ ASPX / {0} / script /"
/>
Vous êtes encouragé à lire le script pour avoir un aperçu de ce qui s'est passé. Cependant, il est recommandé de ne pas modifier ces scripts, car leur fonctionnalité est étroitement liée à des versions d'exécution spécifiques. Lorsque la version d'exécution est mise à jour, ces scripts peuvent également nécessiter des mises à jour correspondantes, et vous abandonnerez les modifications ou face au problème que le script ne fonctionne pas. Si un projet spécifique doit modifier ces scripts, sauvegardez d'abord les scripts, puis pointez votre projet vers le fichier de sauvegarde en remplaçant l'emplacement de ces fichiers par un fichier config.web privé. Si la chaîne contient l'instruction de format "{0}", le numéro de version d'exécution remplacera l'instruction. Il est préférable de changer cet emplacement en une référence relative ou absolue.
Désactiver l'authentification du client
Parfois, vous ne voudrez peut-être pas l'authentification du client. Si le nombre de champs d'entrée est faible, la vérification du client peut être peu utile. Après tout, vous devez avoir une logique qui doit se déplacer vers et depuis le serveur une fois à chaque fois. Vous constaterez que les informations qui apparaissent dynamiquement sur le client auront un impact négatif sur votre mise en page.
Pour désactiver l'authentification du client, utilisez la directive de page "ClientTarget = Downlevel". Cette directive est similaire au début du fichier ASPX suivant:
<% @ Page Language = "C #" ClientTarget = Downlevel%>
La valeur par défaut de cette directive est "Auto", ce qui signifie que vous effectuez une authentification client uniquement pour Microsoft Internet Explorer 4.0 ou version ultérieure.
Remarque: Malheureusement, dans la bêta 1, cette directive ne désactive pas simplement la vérification, mais entraîne également le traitement de tous les contrôles Web à l'aide de balises HTML 3.2, ce qui peut produire 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 produisent lors de l'exécution d'une page contenant la validation du client:
Lorsque la page se charge dans le navigateur, chaque contrôle de vérification doit être initialisé du temps. Ces contrôles sont envoyés sous forme de balises <pan>, et leurs attributs HTML sont les plus proches de ceux du serveur. Plus important encore, tous les éléments d'entrée référencés par le validateur sont "montés" pour le moment. L'élément d'entrée référencé modifie ses événements clients afin que la routine de vérification soit appelée chaque fois que l'entrée change.
Le code de la bibliothèque de scripts sera exécuté lorsque l'utilisateur bascule entre les champs à l'aide de la touche Tab. Lorsqu'un champ séparé change, la condition de vérification est réévaluée, ce qui rend le validateur visible ou invisible au besoin.
Lorsque l'utilisateur essaie de soumettre un formulaire, tous les validateurs sont réévalués. Si tous ces validateurs sont valides, le formulaire sera soumis au serveur. S'il y a une ou plusieurs erreurs, les situations suivantes se produiront:
La soumission a été annulée. Le formulaire n'est pas soumis au serveur.
Tous les validateurs non valides sont visibles.
Si un résumé de vérification contient showsummary = true, toutes les erreurs du contrôle de vérification sont collectées et leur contenu est mis à jour avec ces erreurs.
Si un résumé de vérification contient ShowMessageBox = true, les erreurs sont collectées et affichées dans la zone d'information du client.
Étant donné que les contrôles de vérification du client sont exécutés chaque fois qu'une modification est saisie ou soumise, ces contrôles de vérification sont généralement évalués le client deux fois ou plus. Veuillez noter qu'après la soumission, ces contrôles de vérification seront toujours réévalués sur le serveur.
API client
Il existe une petite API qui peut être utilisée sur la machine client pour obtenir divers effets dans votre propre code client. Parce que certaines routines ne peuvent pas être cachées, en théorie, vous pouvez tirer parti du client pour vérifier toutes les variables, fonctionnalités et fonctions définies par le script. Cependant, beaucoup d'entre eux sont des détails d'implémentation qui peuvent être modifiés. Ce qui suit résume les objets clients que nous vous encourageons à utiliser.
Tableau 3. Objets clients
DESCRIPTION DE TYPE DE NOM
La variable Boolean Page_isvalid indique si la page est actuellement valide. Le script de vérification maintient toujours la variable à jour.
PAGE_VALIDATEAUX Élément Array Il s'agit d'un tableau contenant tous les validateurs de la page.
La variable booléenne Page_ValidationActive indique si la vérification doit être effectuée. La définition de cette variable sur FALSE peut être désactivée par programmation.
Isvalid Boolean Property Chaque validateur client a cette propriété indiquant si le validateur est actuellement valide. Notez que dans la version PDC, cette propriété est mélangée avec une partie supérieure et en minuscules ("isvalid").
Contourner l'authentification du client
Une tâche que vous devez souvent effectuer consiste à ajouter un bouton d'annulation ou un bouton de navigation sur la page. Dans ce cas, vous pouvez soumettre la page à l'aide du bouton, même s'il y a une erreur sur la page. Étant donné que l'événement du bouton client "onclick" se produit avant l'événement "onSubmit" du formulaire, il peut éviter de soumettre des chèques et de contourner la vérification. Ce qui suit décrit comment terminer la tâche à l'aide du contrôle d'image HTML comme le bouton Annuler:
<Type d'entrée = Image Runat = Server
Value = "Annuler"
OnserverClick = cmdcancel_click>
L'exécution de cette tâche à l'aide du bouton ou du contrôle ImageButton provoquera une certaine confusion car l'événement "onClick" est supposé être un événement côté serveur au même nom. Vous devez définir l'événement dans le script client:
<asp: ImageButton runat = server id = cmdimgcancel
AlternateText = "annuler"
OnClick = cmdcancel_click />
<script linguisse = "javascript">
document.all ["cmdimgcancel"]. onclick =
nouvelle fonction ("page_validationactive = false;");
</cript>
Une autre façon de résoudre ce problème consiste à définir le bouton Annuler afin qu'il ne déclenche pas l'événement de validation dans le script client lors de son retour. Les commandes HTMLINPUTBUTTON et LINKBUTTON en sont des exemples.
Effets spéciaux
Une autre exigence commune est qu'en cas d'erreur, en plus du message d'erreur affiché par le validateur lui-même, d'autres effets sont nécessaires. Dans ce cas, toute modification que vous apportez doit être apportée simultanément sur le serveur ou le client. Supposons que vous deviez ajouter une étiquette pour modifier la couleur selon que l'entrée est valide ou non. Voici comment implémenter cette tâche sur le serveur:
classe publique ChangeColorPage: Page {
Label public lblzip;
Public RegularexpressionValidator Valzip;
Override protégé void onload (EventArgs e) {
lblzip.foreColor = Valzip.isvalid?
}
}
Toutes les méthodes ci-dessus sont parfaites, mais tant que vous modifiez la vérification comme mentionné ci-dessus, vous constaterez qu'à moins que vous ne fassiez de même sur le client, cela semblera très incohérent. Le cadre de vérification vous empêchera de plusieurs de ces deux effets, mais il ne peut pas éviter d'autres effets que vous devez réaliser simultanément sur le client et le serveur. Voici un extrait de l'exécution de la même tâche sur le client:
<asp: étiquette id = lblzip runat = serveur
Text = "Code postal:" />
<asp: TextBox ID = txtZip runat = serveur
/> </ asp: TextBox> <br>
<ASP: RegulArExpressionValidator ID = Valzip Runat = Server
ControlTovalated = txtzip
ErrorMessage = "code postal non valide"
ValidationExpression = "[0-9] {5}" /> <br>
<Script Language = JavaScript>
fonction txtziponChange () {
// Si l'authentification client n'est pas active, aucune action n'est effectuée
if (typeof (page_validators) == "Undefined") return;
// change la couleur de l'étiquette
lblzip.style.color = valzip.isvalid?
}
</cript>
API client Beta 1
Pour la version bêta 1, certaines fonctions qui peuvent être appelées à partir de scripts clients peuvent provoquer d'autres situations.
Tableau 4. Fonctions appelées à partir de scripts clients
Description du nom
ValidatorValidate (VAL) prend un validateur client en entrée. Faites en sorte que le validateur vérifie ses entrées et mettez à jour son affichage.
ValidatorEnable (Val, activer) obtient un validateur client et une valeur booléenne. Activer ou désactiver le validateur client. Si elle est désactivée, le validateur du client ne sera pas évalué et le validateur du client apparaîtra toujours comme valide.
ValidatorHookUpControl (Control, Val) obtient un élément HTML d'entrée et un validateur client. Modifiez ou créez l'événement de modification pour cet élément afin que le validateur soit mis à jour lorsqu'il change. Cette fonction convient aux validateurs personnalisés en fonction de plusieurs valeurs d'entrée.
Son objectif spécial est d'activer ou de désactiver le validateur. Si vous souhaitez que la vérification ne soit efficace que dans une situation spécifique, vous devrez peut-être modifier l'état d'activation sur le serveur et le client, sinon vous constaterez que l'utilisateur ne peut pas soumettre la page.
Ce qui suit est l'exemple ci-dessus plus un champ qui n'est validé que lorsqu'une case à cocher n'est pas contrôlée.
classe publique Conditionnel: Page {
public htmlinputcheckbox chksameas;
Public Obligatoire OBLIQUE VALIDATEUR RFVALSHIPADdress;
Override protégé void validate () {
Bool EntorityHeship =! Chksameas.Coched;
rfValShipAddress.Enabled = CertiveShip;
base.validate ();
}
}
Voici le code équivalent client:
<entrée type = checkbox runat = server id = chksameas
> Identique à l'adresse de paiement <br>
<Script Language = JavaScript>
fonction onchangesameas () {
var neweship =! event.srcelement.status;
ValidatorEnable (RFValShipAddress, aperçu);
}
</cript>