Validation dans Wisej.NET

Créez le formulaire d'admission ValidationClinic autour de deux opportunités de détecter les erreurs : lorsque l'utilisateur quitte un champ et lorsqu'il enregistre. Dans Wisej.NET, ces vérifications fonctionnent ensemble afin qu'un champ intact ne puisse échapper à la validation.

Exécutez des vérifications rapides dans l’événement Validating, avant que l’utilisateur ne continue. Le navigateur signale le changement de focus, mais votre gestionnaire C sharp s'exécute sur le serveur. Garder ce gestionnaire court évite de rendre la navigation ordinaire lente.

Utilisez Validation pour décider si la valeur est acceptable. Annulez l'événement et expliquez le problème lorsque ce n'est pas le cas. Validé suit uniquement une vérification réussie, ce qui en fait l'endroit approprié pour un nettoyage tel que la suppression d'un nom accepté.

Définissez le comportement AutoValidate du formulaire dans son constructeur. Dans chaque gestionnaire, SetError explique une valeur rejetée et e.Cancel la rejette. Effacez le message après correction afin que l'interface reflète la valeur actuelle plutôt qu'une erreur antérieure.

Restez concentré sur un champ invalide lorsque l’utilisateur doit le corriger. Donnez à Cancel une voie d'évacuation distincte en définissant CausesValidation sur false. Dans le cas contraire, la validation pourrait empêcher quelqu'un d'abandonner un formulaire incomplet.

Avant d'écrire au client, appelez ValidateChildren depuis Save. Cela vérifie également les champs que l'utilisateur n'a jamais visités. Si un gestionnaire annule la validation, arrêtez la sauvegarde ; seules les valeurs acceptées doivent atteindre l'opération d'écriture et sa gestion des exceptions.

Regardez le nom vide rester concentré pendant que l'icône d'erreur explique pourquoi. Après correction, le nom accepté est tronqué. L'e-mail mal formé est rejeté indépendamment, tandis qu'Annuler ferme toujours le formulaire sans nécessiter la correction des deux champs.

Testez Enregistrer avant de toucher le champ e-mail. ValidateChildren détecte cette entrée manquante et empêche l'écriture même si aucun changement de focus ne s'y est produit. Corrigez l'adresse et enregistrez à nouveau pour confirmer que l'entrée valide suit le chemin réussi.

Pour cet atelier, connectez la validation des champs, le nettoyage des valeurs réussies et la vérification finale de l'enregistrement dans un seul formulaire d'admission. Testez également Annuler avec une entrée non valide. Votre note de laboratoire doit expliquer comment ces chemins empêchent les mauvaises données sans piéger l'utilisateur.

Donnez au formulaire de contact un feedback qui reste utile après la première erreur. Un ErrorProvider gère les icônes, des assistants réutilisables décident quelles valeurs ne sont pas valides et un résumé visible permet aux utilisateurs d'examiner ensemble chaque problème.

Séparez la vérification d’une valeur de l’affichage de son erreur. Les gestionnaires de champs indépendants peuvent laisser des icônes obsolètes ou effacer des messages sans rapport. Une approche partagée permet à chaque correction d'affecter le domaine concerné tout en préservant les problèmes qui nécessitent encore une attention particulière.

Choisissez comment chaque message parvient à l'utilisateur. SetError ajoute une icône à côté d'une entrée, tandis que InvalidMessage fournit la propre info-bulle du contrôle. Le résumé fournit un texte lisible pour l'ensemble du formulaire, de sorte que les erreurs ne sont pas détectables uniquement en survolant le formulaire.

Configurez un seul ErrorProvider pour le formulaire, avec des icônes stables placées à droite. Laissez ValidateEmail renvoyer un résultat FieldValidation au lieu de modifier les contrôles. Cette séparation maintient la règle réutilisable et laisse la présentation au formulaire.

Appliquer des processus à chaque résultat, y compris les résultats réussis. Un message vide supprime l’ancienne icône de ce champ ; les résultats invalides remplissent également le résumé. Renvoyer si tous les résultats ont été transmis donne à Save une décision claire avant que des données ne soient écrites.

Faites correspondre les commentaires au problème. Placez une correction de champ à côté de son entrée, expliquez une règle métier dans le résumé de sauvegarde et donnez à une panne système son propre message convivial. Les utilisateurs doivent comprendre quelle action est disponible pour eux.

Enregistrez le formulaire avec les trois champs de contact invalides. Comparez les icônes locales avec le résumé : les deux doivent décrire les mêmes problèmes restants. L'info-bulle du code client montre le chemin d'affichage alternatif sans remplacer l'explication à l'échelle du formulaire.

Corrigez uniquement l'e-mail et laissez ce champ. Son icône et son récapitulatif disparaissent, mais le nom et les messages téléphoniques restent. Cela démontre pourquoi les résultats individuels doivent effacer les erreurs individuelles plutôt que l'ensemble du fournisseur.

Créez les assistants, le ErrorProvider partagé et la méthode Apply comme un seul chemin de rétroaction. Vérifiez que la correction d'un champ préserve les autres erreurs. Comparez le code client InvalidMessage avec les icônes et le résumé pour expliquer quand chaque présentation est utile.

Déplacez les règles de champ répétées dans l'extension de validation. Dans Wisej.NET, la description des exigences de chaque champ permet au répéteur d'effectuer des vérifications cohérentes pour ValidationClinic, tandis que le formulaire reste chargé de présenter des commentaires utiles à l'utilisateur.

Le prolongateur se connecte à Validating et Validated sur les contrôles. Au lieu de répéter la même vérification de valeur vide dans plusieurs gestionnaires, attachez des métadonnées de règle à chaque champ. Le flux des événements reste familier tandis que les définitions deviennent plus faciles à partager.

Choisissez une règle intégrée pour le type de valeur que vous acceptez, comme un e-mail, un nombre entier, une devise ou un téléphone. Utilisez une expression régulière lorsque le modèle requis en a besoin. Attribuez à chaque règle un InvalidMessage qui explique la correction dans la langue de l'utilisateur.

Ajoutez une validation dans le concepteur, puis ouvrez la collection ValidationRules d’un contrôle. Mettez Obligatoire avant l'E-mail. L'ordre de collecte est également un ordre d'exécution, donc l'organisation de ces entrées détermine quelle explication l'utilisateur reçoit en premier.

Un échec de règle arrête les règles restantes et annule la validation. C'est pourquoi un e-mail vide devrait échouer. Obligatoire en premier : demander une adresse manquante est plus utile que signaler un problème de format avant qu'une adresse n'existe.

La configuration du runtime suit le même modèle de règles. Créez les tableaux une fois dans ClinicRules, sélectionnez la cible d'affichage, puis attribuez chaque champ via SetValidationRules. Le fait de conserver les définitions ensemble évite des copies légèrement différentes de la même règle d’un formulaire à l’autre.

Comparez une adresse vide, une adresse mal formée et une adresse valide. Chaque tentative ne doit produire que la première erreur applicable. Lorsque la valeur devient valide, l'icône et l'entrée récapitulative s'effacent, confirmant que la présentation suit le dernier résultat de validation.

Les règles peuvent envoyer un retour au contrôle, à un ErrorProvider ou à une étiquette. Choisissez délibérément la cible, puis mettez à jour le résumé à partir des propres événements du répéteur. Cela permet de synchroniser le résumé avec les contrôles réellement exécutés.

Remplacez les gestionnaires répétés par des définitions ClinicRules partagées. Gardez d'abord Required et connectez le résumé aux événements du prolongateur. Votre test doit montrer que les valeurs vides, mal formées et corrigées produisent le message approprié sans conserver de commentaires obsolètes.

Module quatre. Validation personnalisée dans Wisej.NET. Un formulaire peut accepter des valeurs correctement formatées qui enfreignent toujours les règles métier. Réparons ça.

Les règles intégrées vérifient la forme d'une valeur. Mais une date valide peut toujours être postérieure à une date de fin, et une date de naissance valide peut appartenir à quelqu'un de trop jeune. Ce sont des règles commerciales. Lorsque vous comparez des champs, calculez un âge ou vérifiez des valeurs ensemble, écrivez une règle de validation personnalisée.

La validation personnalisée comporte trois foyers. Tout d’abord, une méthode qui renvoie un message d’erreur. Deuxièmement, un service qui renvoie les enregistrements ValidationMessage. Troisièmement, une classe dérivée de ValidationRule exécutée par l'extension de validation. Choisissez la maison qui correspond à la responsabilité de votre règle.

ValidateStartEndDates renvoie une chaîne vide lorsque les dates sont valides, ou un message d'erreur lorsqu'elles ne le sont pas. Appliquez ce même message aux deux sélecteurs de date. Le service ContactValidator ne dépend pas des contrôles. Il valide le modèle afin que vous puissiez tester la logique métier sans l'interface utilisateur.

MinimumAgeValidationRule dérive de ValidationRule. Sa méthode OnValidating renvoie vrai ou faux. Attachez la règle au sélecteur de date de naissance avec SetValidationRules. ApplyModelValidation connecte les résultats du service à l'écran. Il mappe les noms de champs aux contrôles, de sorte que chaque message apparaît là où l'utilisateur peut résoudre le problème.

Le gestionnaire Save exécute la validation dans l’ordre. Tout d’abord, vérifiez les règles du champ. Exécutez ensuite le service de validation et la règle de date. Revenez tôt si une couche échoue. Appelez le référentiel uniquement après chaque vérification réussie. La base de données ne doit jamais recevoir de données que votre validation a déjà rejetées.

Essayez maintenant d'enregistrer avec la date de début après la date de fin. Les deux sélecteurs affichent la même erreur et le résumé affiche un seul message.

Corrigez la date de fin. Les deux erreurs disparaissent ensemble. Étant donné que cette règle compare deux valeurs, les deux contrôles partagent le feedback.

Entrez une date de naissance à partir de vingt-onze heures. La règle de l'âge minimum le rejette dès que l'utilisateur quitte le préparateur.

Corrigez la date de naissance et l’erreur disparaît. Save exécute désormais chaque couche de validation avec succès, puis stocke le contact exactement une fois.

Pour le quatrième laboratoire, implémentez la vérification de date, le service de validation, le mappage des messages et la règle d'âge minimum.

Connectez-les dans un gestionnaire de sauvegarde qui n'enregistre jamais les données non valides.

Module cinq. Validation liée aux données dans Wisej.NET. Le formulaire d'admission modifie désormais un modèle de modification de contact. Ses règles de validation de base appartiennent aux données, donc les mêmes règles peuvent protéger le formulaire, la grille et d'autres moyens de modifier un contact.

Un gestionnaire de formulaire protège uniquement les modifications apportées via ce formulaire. Une grille, une importation ou un service peut mettre à jour le même contact sans exécuter ces gestionnaires. Mettez les règles de base sur le modèle, puis faites en sorte que chaque chemin de sauvegarde les exécute avant d'accepter les données.

Tout d’abord, terminez la modification en cours. La valeur encore en cours de saisie n'a peut-être pas encore atteint le modèle. Appelez End Edit sur la source de liaison du contact avant de valider. Sinon, le validateur pourrait vérifier une valeur plus ancienne même si l'utilisateur a déjà corrigé le champ.

Les annotations de données décrivent les règles, mais elles ne s'exécutent pas elles-mêmes. Essayez de valider l'objet, les applique et collecte les résultats. Définissez valider toutes les propriétés sur true. Sans cette option, seul Obligatoire est coché, donc un e-mail mal formé ou un âge hors plage pourrait passer.

Le validateur renvoie les noms de propriétés, pas les contrôles. Utilisez une carte de champ pour connecter chaque résultat à l’entrée correcte. Mettez le message à côté de cette entrée et dans le résumé. Si une propriété n'a pas de contrôle correspondant, conservez son message dans le résumé afin que l'erreur soit toujours visible.

Il existe une autre approche. Un modèle implémentant I Data Error Info répond aux questions de validation pour chaque propriété. Un fournisseur d'erreurs lié aux données lit ces réponses. Lors du changement de source au moment de l'exécution, Bind To Data And Errors définit la source et le membre ensemble, évitant ainsi une incompatibilité temporaire.

Essayez d'enregistrer le contact invalide. End Edit valide d’abord l’entrée actuelle dans le modèle. Les vérifications d'annotation rejettent le nom, l'adresse e-mail et l'âge. La carte de champ place chaque message à côté de son entrée et dans le résumé. Le chemin de sauvegarde s'arrête avant d'écrire quoi que ce soit.

Corrigez les valeurs et enregistrez à nouveau. Les contrôles sont désormais réussis et le contact est enregistré. Sur le modèle I Data Error Info, la suppression du nom ramène l’icône d’erreur via la liaison de données. Le formulaire n’a pas besoin d’appeler Set Error pour cette modification.

Pour le laboratoire cinq, liez l'éditeur au modèle, terminez les modifications avant de valider et mappez les résultats des annotations aux champs et au résumé. Connectez ensuite le modèle I Data Error Info via Bind To Data And Errors. Vérifiez que les données non valides n'atteignent jamais le référentiel.

La grille de contacts introduit un chemin d'édition différent du formulaire d'admission. Une cellule possède son propre éditeur et ses propres événements de validation. Réutilisez donc la même intention commerciale via les gestionnaires de grille plutôt que d'attendre que les gestionnaires de champs de texte du formulaire s'exécutent.

Séparez les trois problèmes avant de choisir un gestionnaire. Le format de courrier électronique appartient à la cellule, l'âge non numérique peut échouer à la conversion et un contact fermé sans date de clôture enfreint une règle dans tous les champs. Un seul contrôle ne peut pas expliquer les trois de manière fiable.

Lors de l'édition, validez e.FormattedValue car il contient ce que l'utilisateur est en train de saisir actuellement. Le Value stocké dans la cellule représente toujours l’entrée validée précédente. Vérifier cette ancienne valeur pourrait accepter l’erreur même que l’utilisateur vient d’introduire.

Utilisez le nom de la colonne pour sélectionner la règle dans CellValidating. Effacez le message précédent de cette cellule, inspectez la valeur modifiée et annulez avec une explication claire en cas d'échec. Cela maintient l'utilisateur à côté de l'entrée qui doit être corrigée.

Placez une erreur de valeur unique sur la cellule et une erreur de relation sur la ligne. Réservez DataError pour les échecs de conversion ou d’enregistrement signalés par la grille. Ignorez l'espace réservé de nouvelle ligne, car il ne s'agit pas encore d'un contact nécessitant une validation.

ValidateRow met à jour le message de ligne et la cellule de date de clôture ensemble, rendant la relation visible aux deux niveaux. Dans DataError, expliquez les échecs de conversion dans un langage ordinaire et enregistrez l'exception séparément afin que le diagnostic ne relève pas de la responsabilité de l'utilisateur.

Essayez d'abord l'e-mail mal formé : la validation maintient la modification en place et affiche l'erreur de cellule. Entrez ensuite les lettres correspondant à l'âge. Le message de conversion convivial montre un chemin d'échec différent, même si les deux erreurs se sont produites lors de la modification d'une cellule.

Le contact fermé ne peut toujours pas être enregistré tant que sa date de clôture requise n'est pas présente. L'erreur de ligne maintient cette relation visible, tandis que l'espace réservé est ignoré. Saisissez la date et enregistrez à nouveau pour vérifier que la correction de la règle permet la persistance.

Construisez les vérifications de la grille autour de la valeur modifiée actuelle, des relations entre les lignes et des erreurs de conversion conviviales. Effacez les erreurs de cellule réussies et protégez Save contre les échecs restants. Testez chaque couche séparément afin qu'une cellule valide ne puisse pas masquer une ligne de contact non valide.

Rassemblez les contrôles ValidationClinic dans un seul chemin de sauvegarde. La validation des champs, des modèles, des activités et de la grille doit désormais coopérer dans Wisej.NET, de sorte qu'une vérification réussie sur une couche ne contourne jamais un problème non résolu sur une autre.

Les validateurs individuellement corrects ne garantissent pas une sauvegarde correcte. Une modification en attente peut laisser le modèle obsolète, ou une erreur de grille peut ne jamais atteindre les vérifications du formulaire. Placez les étapes dans un ordre fixe et exigez que chaque étape réussisse.

Réinitialisez les commentaires et terminez la modification en cours avant de vérifier les champs, le modèle, les règles métier et les lignes de la grille. Arrêtez-vous à la première étape échouée. Cette séquence empêche un travail ultérieur de s'exécuter avec une entrée non valide et conserve l'écriture éventuelle derrière toutes les vérifications.

Utilisez le contrat IErrorProvider pour envoyer des messages sans lier la validation à un seul affichage. SummaryErrorProvider conserve un message pour chaque contrôle et masque son étiquette lorsqu'il n'en reste plus. Le résumé peut donc refléter les mêmes erreurs que le retour de terrain.

Revenez plus tôt lorsque la validation du champ ou du modèle échoue. Si la sauvegarde finale échoue, distinguez un nom en double que l'utilisateur peut corriger d'une panne système qu'il ne peut pas corriger. Acheminez le doublon vers son champ et expliquez calmement les autres échecs.

Examinez les commentaires dans le cadre du flux de travail, et pas seulement sous forme de texte d'erreur. Expliquez la correction près du champ et dans le résumé, conservez Annuler et gardez les traces techniques hors des messages des utilisateurs. Testez les entrées manquantes, invalides, valides et limites.

Premièrement, le nom manquant et l'email mal formé arrêtent la sauvegarde lors de la validation du champ. Corrigez ces champs et réessayez. Le modèle rejette ensuite l’âge de cent trente ans, montrant pourquoi la réussite des contrôles sur le terrain ne rend pas les contrôles ultérieurs facultatifs.

L'étape de la grille détecte les problèmes restants de courrier électronique et de lignes fermées, et le résumé explique les deux. Après ces corrections, chaque étape réussit et la sauvegarde se termine. La confirmation finale signifie désormais que tout le chemin de validation a été réussi.

Fournissez le chemin de sauvegarde complet avec le fournisseur de résumé et l'assistant de message partagé. Incluez la gestion des exceptions qui distingue les entrées corrigibles des pannes du système. Documentez les cas de test afin qu'un autre développeur puisse reproduire à la fois les sauvegardes bloquées et les corrections réussies.