Validierung in Wisej.NET

Erstellen Sie das Aufnahmeformular ValidationClinic um zwei Möglichkeiten herum, Fehler zu erkennen: wenn der Benutzer ein Feld verlässt und wenn der Benutzer speichert. In Wisej.NET arbeiten diese Prüfungen zusammen, sodass ein unberührtes Feld der Validierung nicht entgehen kann.

Führen Sie im Validating-Ereignis Schnellprüfungen durch, bevor der Benutzer fortfährt. Der Browser meldet die Fokusänderung, aber Ihr C sharp-Handler wird auf dem Server ausgeführt. Wenn Sie diesen Handler kurz halten, wird vermieden, dass sich die normale Navigation langsam anfühlt.

Verwenden Sie „Validating“, um zu entscheiden, ob der Wert akzeptabel ist. Sagen Sie die Veranstaltung ab und erklären Sie das Problem, wenn dies nicht der Fall ist. „Validated“ folgt nur einer erfolgreichen Prüfung und ist daher der geeignete Ort für eine Bereinigung, z. B. das Kürzen eines akzeptierten Namens.

Legen Sie das AutoValidate-Verhalten des Formulars in seinem Konstruktor fest. In jedem Handler erklärt SetError einen abgelehnten Wert und e.Cancel lehnt ihn ab. Löschen Sie die Meldung nach der Korrektur, damit die Schnittstelle den aktuellen Wert und nicht einen früheren Fehler anzeigt.

Konzentrieren Sie sich weiterhin auf ein ungültiges Feld, wenn der Benutzer es korrigieren muss. Geben Sie „Cancel“ einen separaten Fluchtweg, indem Sie CausesValidation auf „false“ setzen. Andernfalls könnte die Validierung verhindern, dass jemand ein unvollständiges Formular verlässt.

Bevor Sie dem Kunden schreiben, rufen Sie ValidateChildren von Save aus an. Dadurch werden auch Felder überprüft, die der Benutzer nie besucht hat. Wenn ein Handler die Validierung abbricht, stoppen Sie den Speichervorgang. Nur akzeptierte Werte sollten den Schreibvorgang und seine Ausnahmebehandlung erreichen.

Achten Sie darauf, dass der leere Name den Fokus behält, während das Fehlersymbol erklärt, warum. Nach der Korrektur wird der akzeptierte Name gekürzt. Die fehlerhafte E-Mail wird unabhängig zurückgewiesen, während „Abbrechen“ das Formular weiterhin schließt, ohne dass eines der Felder korrigiert werden muss.

Testen Sie Speichern, bevor Sie das E-Mail-Feld berühren. ValidateChildren findet die fehlende Eingabe und verhindert den Schreibvorgang, obwohl dort keine Fokusänderung stattgefunden hat. Korrigieren Sie die Adresse und speichern Sie sie erneut, um zu bestätigen, dass eine gültige Eingabe dem erfolgreichen Pfad folgt.

Verbinden Sie für dieses Labor die Feldvalidierung, die Bereinigung erfolgreicher Werte und die abschließende Speicherprüfung in einem Aufnahmeformular. Testen Sie Abbrechen auch mit ungültiger Eingabe. In Ihrer Labornotiz sollte erläutert werden, wie diese Pfade fehlerhafte Daten verhindern, ohne den Benutzer in die Falle zu locken.

Geben Sie dem Kontaktformular Feedback, das auch nach dem ersten Fehler nützlich bleibt. Ein ErrorProvider verwaltet die Symbole, wiederverwendbare Helfer entscheiden, welche Werte ungültig sind, und eine sichtbare Zusammenfassung ermöglicht es Benutzern, jedes Problem gemeinsam zu überprüfen.

Trennen Sie die Überprüfung eines Werts von der Anzeige seines Fehlers. Unabhängige Feldhandler können veraltete Symbole hinterlassen oder nicht verwandte Nachrichten löschen. Durch einen gemeinsamen Ansatz wirkt sich jede Korrektur auf den relevanten Bereich aus und behält gleichzeitig Probleme bei, die noch Aufmerksamkeit erfordern.

Wählen Sie aus, wie jede Nachricht den Benutzer erreicht. SetError fügt neben einer Eingabe ein Symbol hinzu, während InvalidMessage den eigenen Tooltip des Steuerelements bereitstellt. Die Zusammenfassung stellt lesbaren Text für das gesamte Formular bereit, sodass Fehler nicht nur durch Bewegen des Mauszeigers erkannt werden können.

Konfigurieren Sie ein einzelnes ErrorProvider für das Formular, mit stabilen Symbolen auf der rechten Seite. Lassen Sie ValidateEmail ein FieldValidation-Ergebnis zurückgeben, anstatt die Steuerelemente zu ändern. Durch diese Trennung bleibt die Regel wiederverwendbar und die Darstellung bleibt dem Formular überlassen.

Apply verarbeitet jedes Ergebnis, auch erfolgreiche. Eine leere Nachricht entfernt das alte Symbol dieses Feldes; Ungültige Ergebnisse werden ebenfalls in die Zusammenfassung eingetragen. Durch die Rückgabe, ob alle Ergebnisse bestanden wurden, erhält Save eine klare Entscheidung, bevor Daten geschrieben werden.

Ordnen Sie das Feedback dem Problem zu. Platzieren Sie eine Feldkorrektur neben der Eingabe, erläutern Sie eine Geschäftsregel in der Speicherzusammenfassung und geben Sie einem Systemfehler eine eigene freundliche Nachricht. Benutzer sollten verstehen, welche Aktion ihnen zur Verfügung steht.

Speichern Sie das Formular mit den drei ungültigen Kontaktfeldern. Vergleichen Sie die lokalen Symbole mit der Zusammenfassung: Beide sollten die gleichen verbleibenden Probleme beschreiben. Der Tooltip des Kundencodes demonstriert den alternativen Anzeigepfad, ohne die formularweite Erklärung zu ersetzen.

Korrigieren Sie nur die E-Mail und lassen Sie dieses Feld stehen. Das Symbol und der Zusammenfassungseintrag verschwinden, der Name und die Telefonnachrichten bleiben jedoch erhalten. Dies zeigt, warum einzelne Ergebnisse einzelne Fehler löschen müssen, anstatt den gesamten Anbieter zu löschen.

Erstellen Sie die Helfer, das gemeinsame ErrorProvider und die Apply-Methode als einen Feedbackpfad. Stellen Sie sicher, dass durch die Korrektur eines Felds andere Fehler erhalten bleiben. Vergleichen Sie den Kundencode InvalidMessage mit den Symbolen und der Zusammenfassung, um zu erklären, wann jede Präsentation nützlich ist.

Verschieben Sie die wiederholten Feldregeln in den Validation Extender. In Wisej.NET ermöglicht die Beschreibung der Anforderungen jedes Feldes dem Extender, konsistente Prüfungen für ValidationClinic durchzuführen, während das Formular weiterhin dafür verantwortlich ist, dem Benutzer nützliches Feedback zu präsentieren.

Der Extender stellt eine Verbindung zu „Validating“ und „Validated“ auf den Steuerelementen her. Anstatt dieselbe Leerwertprüfung in mehreren Handlern zu wiederholen, fügen Sie jedem Feld Regelmetadaten hinzu. Der Ereignisablauf bleibt vertraut, während die Definitionen einfacher zu teilen sind.

Wählen Sie eine integrierte Regel für die Art von Wert, den Sie akzeptieren, z. B. E-Mail, Ganzzahl, Währung oder Telefonnummer. Verwenden Sie einen regulären Ausdruck, wenn das erforderliche Muster dies erfordert. Geben Sie jeder Regel einen InvalidMessage, der die Korrektur in der Sprache des Benutzers erklärt.

Fügen Sie im Designer die Validierung hinzu und öffnen Sie dann die ValidationRules-Sammlung eines Steuerelements. Setzen Sie „Erforderlich“ vor „E-Mail“. Die Sammlungsreihenfolge ist auch die Ausführungsreihenfolge. Die Anordnung dieser Einträge bestimmt also, welche Erklärung der Benutzer zuerst erhält.

Ein Regelfehler stoppt die verbleibenden Regeln und bricht die Validierung ab. Aus diesem Grund sollte eine leere E-Mail fehlschlagen. Zuerst erforderlich: Nach einer fehlenden Adresse zu fragen ist sinnvoller, als ein Formatproblem zu melden, bevor eine Adresse vorhanden ist.

Die Laufzeitkonfiguration folgt demselben Regelmodell. Erstellen Sie die Arrays einmal in ClinicRules, wählen Sie das Anzeigeziel aus und weisen Sie dann jedes Feld über SetValidationRules zu. Durch das Zusammenhalten der Definitionen werden geringfügig unterschiedliche Kopien derselben Regel in verschiedenen Formularen vermieden.

Vergleichen Sie eine leere Adresse, eine fehlerhafte Adresse und eine gültige Adresse. Jeder Versuch sollte nur den ersten zutreffenden Fehler erzeugen. Wenn der Wert gültig wird, werden sowohl das Symbol als auch der Zusammenfassungseintrag gelöscht, um zu bestätigen, dass die Präsentation dem letzten Validierungsergebnis folgt.

Die Regeln können Feedback an die Steuerung, einen ErrorProvider oder ein Label senden. Wählen Sie das Ziel bewusst aus und aktualisieren Sie dann die Zusammenfassung anhand der Ereignisse des Extenders. Dadurch bleibt die Zusammenfassung mit den tatsächlich durchgeführten Prüfungen synchronisiert.

Ersetzen Sie die wiederholten Handler durch gemeinsam genutzte ClinicRules-Definitionen. Behalten Sie zuerst „Erforderlich“ bei und verknüpfen Sie die Zusammenfassung mit den Ereignissen des Extenders. Ihr Test sollte zeigen, dass leere, fehlerhafte und korrigierte Werte die entsprechende Meldung erzeugen, ohne veraltete Rückmeldungen beizubehalten.

Modul vier. Benutzerdefinierte Validierung in Wisej.NET. Ein Formular kann korrekt formatierte Werte akzeptieren, die dennoch gegen Geschäftsregeln verstoßen. Lasst uns das beheben.

Integrierte Regeln überprüfen die Form eines Werts. Ein gültiges Datum kann jedoch immer noch nach einem Enddatum liegen, und ein gültiges Geburtsdatum kann zu einer zu jungen Person gehören. Das sind Geschäftsregeln. Wenn Sie Felder vergleichen, ein Alter berechnen oder Werte gemeinsam überprüfen, schreiben Sie eine benutzerdefinierte Validierungsregel.

Die benutzerdefinierte Validierung hat drei Häuser. Erstens eine Methode, die eine Fehlermeldung zurückgibt. Zweitens ein Dienst, der ValidationMessage-Datensätze zurückgibt. Drittens eine von ValidationRule abgeleitete Klasse, die der Validierungs-Extender ausführt. Wählen Sie das Zuhause, das der Verantwortung Ihrer Herrschaft entspricht.

ValidateStartEndDates gibt eine leere Zeichenfolge zurück, wenn die Daten gültig sind, oder eine Fehlermeldung, wenn dies nicht der Fall ist. Wenden Sie dieselbe Nachricht auf beide Datumsauswahlfelder an. Der ContactValidator-Dienst ist nicht von Steuerelementen abhängig. Es validiert das Modell, sodass Sie die Geschäftslogik ohne die Benutzeroberfläche testen können.

MinimumAgeValidationRule leitet sich von ValidationRule ab. Die Methode OnValidating gibt „true“ oder „false“ zurück. Hängen Sie die Regel mit SetValidationRules an die Geburtsdatumsauswahl an. ApplyModelValidation verbindet Serviceergebnisse mit dem Bildschirm. Es ordnet Feldnamen Steuerelementen zu, sodass jede Meldung angezeigt wird, in der der Benutzer das Problem beheben kann.

Der Save-Handler führt die Validierung der Reihe nach aus. Überprüfen Sie zunächst die Feldregeln. Führen Sie dann den Validierungsdienst und die Datumsregel aus. Kehren Sie frühzeitig zurück, wenn eine Schicht ausfällt. Rufen Sie das Repository erst auf, nachdem jede Prüfung erfolgreich war. Die Datenbank sollte niemals Daten empfangen, die Ihre Validierung bereits abgelehnt hat.

Versuchen Sie nun, das Startdatum nach dem Enddatum zu speichern. Beide Picker zeigen den gleichen Fehler und in der Zusammenfassung wird eine einzige Meldung angezeigt.

Korrigieren Sie das Enddatum. Beide Fehler werden gemeinsam behoben. Da diese Regel zwei Werte vergleicht, teilen sich beide Steuerelemente das Feedback.

Geben Sie ein Geburtsdatum ab 21 Uhr ein. Die Mindestalterregel lehnt dies ab, sobald der Benutzer den Picker verlässt.

Korrigieren Sie das Geburtsdatum und der Fehler wird gelöscht. „Jetzt speichern“ führt alle Validierungsebenen erfolgreich durch und speichert den Kontakt dann genau einmal.

Implementieren Sie für Labor vier die Datumsprüfung, den Validierungsdienst, die Nachrichtenzuordnung und die Mindestalterregel.

Verbinden Sie sie in einem Save-Handler, der niemals ungültige Daten speichert.

Modul fünf. Datengebundene Validierung in Wisej.NET. Das Aufnahmeformular bearbeitet nun ein Kontaktbearbeitungsmodell. Seine grundlegenden Validierungsregeln gehören zu den Daten, sodass dieselben Regeln das Formular, das Raster und andere Möglichkeiten zum Ändern eines Kontakts schützen können.

Ein Formularhandler schützt nur Änderungen, die über dieses Formular vorgenommen werden. Ein Raster, ein Import oder ein Dienst kann denselben Kontakt aktualisieren, ohne diese Handler auszuführen. Legen Sie die Grundregeln für das Modell fest und lassen Sie sie dann von jedem Speicherpfad ausführen, bevor Sie die Daten akzeptieren.

Beenden Sie zunächst die aktuelle Bearbeitung. Der Wert, der noch eingegeben wird, hat das Modell möglicherweise noch nicht erreicht. Rufen Sie vor der Validierung End Edit für die Kontaktbindungsquelle auf. Andernfalls könnte der Validator einen älteren Wert prüfen, obwohl der Benutzer das Feld bereits korrigiert hat.

Datenanmerkungen beschreiben die Regeln, sie werden jedoch nicht selbst ausgeführt. Versuchen Sie Validate Object, wendet sie an und sammelt die Ergebnisse. Setzen Sie „Alle Eigenschaften validieren“ auf „true“. Ohne diese Option wird nur „Erforderlich“ überprüft, sodass eine fehlerhafte E-Mail oder ein außerhalb des zulässigen Bereichs liegendes Alter passieren könnte.

Der Validator gibt Eigenschaftsnamen zurück, keine Steuerelemente. Verwenden Sie eine Feldkarte, um jedes Ergebnis mit der richtigen Eingabe zu verbinden. Platzieren Sie die Nachricht neben dieser Eingabe und in der Zusammenfassung. Wenn für eine Eigenschaft kein passendes Steuerelement vorhanden ist, behalten Sie die Meldung in der Zusammenfassung bei, damit der Fehler weiterhin sichtbar ist.

Es gibt einen anderen Ansatz. Ein Modell, das I Data Error Info implementiert, beantwortet Validierungsfragen für jede Eigenschaft. Ein datengebundener Fehleranbieter liest diese Antworten. Beim Wechseln der Quellen zur Laufzeit setzt „Bind To Data And Errors“ die Quelle und das Mitglied zusammen und vermeidet so eine vorübergehende Nichtübereinstimmung.

Versuchen Sie, den ungültigen Kontakt zu speichern. End Edit übergibt zunächst die aktuelle Eingabe an das Modell. Die Anmerkungsprüfungen lehnen Name, E-Mail und Alter ab. Die Feldzuordnung platziert jede Nachricht neben ihrer Eingabe und in der Zusammenfassung. Der Speicherpfad stoppt, bevor etwas geschrieben wird.

Korrigieren Sie die Werte und speichern Sie erneut. Die Prüfungen bestehen nun und der Kontakt ist gespeichert. Beim I Data Error Info-Modell führt das Löschen des Namens durch die Datenbindung dazu, dass das Fehlersymbol wieder angezeigt wird. Für diese Änderung muss das Formular „Set Error“ nicht aufrufen.

Binden Sie für Labor fünf den Editor an das Modell, schließen Sie die Bearbeitungen vor der Validierung ab und ordnen Sie die Anmerkungsergebnisse den Feldern und der Zusammenfassung zu. Verbinden Sie dann das I Data Error Info-Modell über „Bind To Data And Errors“. Stellen Sie sicher, dass ungültige Daten niemals das Repository erreichen.

Das Kontaktraster führt einen anderen Bearbeitungspfad ein als das Aufnahmeformular. Eine Zelle verfügt über einen eigenen Editor und eigene Validierungsereignisse. Verwenden Sie daher dieselbe Geschäftsabsicht über Raster-Handler wieder, anstatt zu erwarten, dass die Textfeld-Handler des Formulars ausgeführt werden.

Trennen Sie die drei Probleme, bevor Sie einen Handler auswählen. Das E-Mail-Format gehört zur Zelle, ein nicht numerisches Alter kann bei der Konvertierung fehlschlagen und ein geschlossener Kontakt ohne Abschlussdatum verstößt gegen eine feldübergreifende Regel. Eine Prüfung kann nicht alle drei zuverlässig erklären.

Überprüfen Sie während der Bearbeitung e.FormattedValue, da es enthält, was der Benutzer gerade eingibt. Der in der Zelle gespeicherte Value stellt immer noch die zuvor festgeschriebene Eingabe dar. Die Überprüfung dieses alten Werts könnte genau den Fehler akzeptieren, den der Benutzer gerade gemacht hat.

Verwenden Sie den Spaltennamen, um die Regel in CellValidating auszuwählen. Löschen Sie die vorherige Meldung dieser Zelle, überprüfen Sie den bearbeiteten Wert und brechen Sie mit einer klaren Erklärung ab, wenn der Vorgang fehlschlägt. Dadurch bleibt der Benutzer neben der Eingabe, die korrigiert werden muss.

Platzieren Sie einen Einzelwertfehler in der Zelle und einen Beziehungsfehler in der Zeile. Reservieren Sie DataError für Konvertierungs- oder Speicherfehler, die das Raster meldet. Überspringen Sie den Platzhalter für die neue Zeile, da es sich noch nicht um einen Kontakt handelt, der eine Validierung erfordert.

ValidateRow aktualisiert die Zeilennachricht und die Abschlussdatumszelle zusammen, wodurch die Beziehung auf beiden Ebenen sichtbar wird. Erklären Sie in DataError Konvertierungsfehler in normaler Sprache und protokollieren Sie die Ausnahme separat, damit die Diagnose nicht in die Verantwortung des Benutzers fällt.

Versuchen Sie es zunächst mit der fehlerhaften E-Mail: Die Validierung behält die Bearbeitung bei und zeigt den Zellenfehler an. Geben Sie dann Buchstaben für das Alter ein. Die freundliche Konvertierungsnachricht zeigt einen anderen Fehlerpfad, obwohl beide Fehler beim Bearbeiten einer Zelle aufgetreten sind.

Der geschlossene Kontakt kann immer noch nicht gespeichert werden, bis das erforderliche Abschlussdatum vorliegt. Durch den Zeilenfehler bleibt diese Beziehung sichtbar, während der Platzhalter ignoriert wird. Geben Sie das Datum ein und speichern Sie es erneut, um zu überprüfen, ob die Korrektur der Regel eine Persistenz zulässt.

Erstellen Sie die Rasterprüfungen um den aktuell bearbeiteten Wert, Zeilenbeziehungen und benutzerfreundliche Konvertierungsfehler herum. Beheben Sie erfolgreiche Zellfehler und schützen Sie Save vor verbleibenden Fehlern. Testen Sie jede Ebene einzeln, damit eine gültige Zelle eine ungültige Kontaktzeile nicht verbergen kann.

Bringen Sie die ValidationClinic-Prüfungen in einen einzigen Speicherpfad. Feld-, Modell-, Geschäfts- und Netzvalidierung müssen jetzt in Wisej.NET zusammenarbeiten, sodass eine erfolgreiche Prüfung auf einer Ebene niemals ein ungelöstes Problem auf einer anderen Ebene umgeht.

Individuell korrekte Validatoren garantieren keine korrekte Speicherung. Eine ausstehende Bearbeitung kann dazu führen, dass das Modell veraltet ist, oder ein Rasterfehler erreicht möglicherweise nie die Formularprüfungen. Ordnen Sie die Phasen in einer festen Reihenfolge an und stellen Sie sicher, dass jede Phase erfolgreich ist.

Setzen Sie das Feedback zurück und beenden Sie die aktuelle Bearbeitung, bevor Sie Felder, das Modell, Geschäftsregeln und Rasterzeilen überprüfen. Stoppen Sie bei der ersten fehlgeschlagenen Stufe. Diese Reihenfolge verhindert, dass spätere Arbeiten mit ungültigen Eingaben ausgeführt werden, und sorgt dafür, dass der eventuelle Schreibvorgang hinter allen Prüfungen zurückbleibt.

Verwenden Sie den IErrorProvider-Vertrag, um Nachrichten zu senden, ohne die Validierung an eine Anzeige zu binden. SummaryErrorProvider behält eine Nachricht für jedes Steuerelement bei und verbirgt deren Beschriftung, wenn keine übrig bleibt. Die Zusammenfassung kann daher dieselben Fehler widerspiegeln wie das Feld-Feedback.

Kehren Sie frühzeitig zurück, wenn die Feld- oder Modellvalidierung fehlschlägt. Wenn die endgültige Speicherung fehlschlägt, unterscheiden Sie einen doppelten Namen, den der Benutzer korrigieren kann, von einem Systemfehler, den er nicht korrigieren kann. Leiten Sie das Duplikat in sein Feld weiter und erklären Sie andere Fehler ruhig.

Überprüfen Sie Feedback als Teil des Workflows, nicht nur als Fehlertext. Erklären Sie die Korrektur neben dem Feld und in der Zusammenfassung, behalten Sie „Abbrechen“ bei und halten Sie technische Spuren aus Benutzernachrichten fern. Testen Sie fehlende, ungültige, gültige und Grenzeingaben.

Erstens verhindern der fehlende Name und die fehlerhafte E-Mail-Adresse das Speichern während der Feldvalidierung. Korrigieren Sie diese Felder und versuchen Sie es erneut. Das Modell lehnt dann das Alter von einhundertdreißig ab und zeigt, warum das Bestehen der Feldprüfungen spätere Prüfungen nicht optional macht.

In der Rasterphase werden die verbleibenden E-Mail- und Closed-Row-Probleme erfasst und in der Zusammenfassung werden beide erläutert. Nach diesen Korrekturen ist jede Phase erfolgreich und der Speichervorgang ist abgeschlossen. Die endgültige Bestätigung bedeutet nun, dass der gesamte Validierungspfad bestanden wurde.

Stellen Sie den vollständigen Speicherpfad mit dem Zusammenfassungsanbieter und dem Shared Message Helper bereit. Schließen Sie eine Ausnahmebehandlung ein, die korrigierbare Eingaben von Systemfehlern unterscheidet. Dokumentieren Sie die Testfälle, damit ein anderer Entwickler sowohl blockierte Speicherungen als auch erfolgreiche Korrekturen reproduzieren kann.