ASP.NET Tutorial, Part 11 - Validering - fortsat

Tags:    asp.net
Skrevet af Bruger #7741 @ 09.08.2005
I forrige lektion så vi på både RequiredFieldValidator- og RangeValidator-kontrollen. I denne lektion ser vi på brugen af de resterende valideringskontroller.

CompareValidator


CompareValidator-kontrollen kan bruges hvis man ønsker at sammenligne to værdier - eksempelvis indtastet i to tekstbokse. Sammenlignet med RequiredFieldValidator-kontrollen har den et par nye egenskaber:

[table][tr][td]Egenskab[/td] [td]Beskrivelse[/td][/tr][tr][td]ControlToCompare[/td] [td]Reference til den kontrol der ønskes sammenlignet med kontrollen refereret i ControlToValidate-egenskaben.[/td][/tr][tr][td]Operator[/td] [td]Den operator der skal benyttes i sammenligningen:
- Equal (lig med)
- NotEqual (ikke lig med)
- GreaterThan (større end)
- GreaterThanEqual (større end eller lig med)
- LessThan (mindre end)
- LessThanEqual (mindre end eller lig med)
- DataTypeCheck
De første seks operatorer siger sig selv. Den sidste kigger vi lidt nærmere på senere.[/td][/tr][tr][td]ValueToCompare[/td] [td]Hvis ikke man angiver en reference i ControlToCompare, kan man tildele ValueToCompare en konstant i stedet.[/td][/tr][table]

På opmærkningsplan kan kontrollen i en simpel form se således ud:

Fold kodeboks ind/udKode 


Her er et eksempel på brug af kontrollen til at sikre, at en dato indtastet i en tekstboks skal være større end indholdet i en anden:

Fold kodeboks ind/udKode 


DataTypeCheck


Som før nævnt kan kontrollen håndtere syv operatorer, hvoraf de seks er logiske operatorer. Den syvende er DataTypeCheck, og den kan være brugbar i mange situationer. Som navnet antyder, kan den bruges til at sikre, at en kontrol indeholder en værdi som kan konverteres til en af de fem datatyper (String, Integer, Date, Double og Currency).

Når DataTypeCheck-operatoren bruges, er det kun ControlToValidate-egenskaben der skal tildeles en reference. Hverken ControlToCompare- eller ValueToCompare-egenskaben benyttes.

Her er et kort eksempel hvor kontrollen bruges til at sikre, at indholdet i en tekstboks kan konverteres til en dato:
Fold kodeboks ind/udKode 

Man skal dog være opmærksom på, at kontrollen accepterer en tom streng, og man bør derfor kombinere kontrollen med en RequiredFieldValidator-kontrol.

RegularExpressionValidator


RegularExpressionValidator-kontrollen kan bruges til at validere mod en RegEx (Regular Expression) maske. RegEx kan være ekstremt brugbart i nogle situationer, men kan også være meget kompliceret. Det ligger uden for denne artikelserie at beskrives RegEx, men der kan eksempelvis henvises til http://www.regexlib.com for yderligere oplysninger.

Kontrollen indeholder en enkelt ny egenskab i forhold til RequiredFieldValidator-kontrollen:

[table][tr][td]Egenskab[/td] [td]Beskrivelse[/td][/tr][tr][td]ValidationExpression[/td] [td]Den RegEx-maske der skal valideres imod - eksempelvis ^\\d{4}$ som kan bruges til at teste om en streng indeholder fire (og kun fire) tal (dansk postnummer).[/td][/tr][/table]

På opmærkningsplan kan det eksempelvis se således ud:
Fold kodeboks ind/udKode 


Her er et eksempel hvor kontrollen bruges til at lave et foreløbigt check om en streng kan minde om et dansk CPR-nummer. RegEx-masken er ^[0-3][0-9][0-1]\\d{3}-\\d{4}? (først et tal mellem 0 og 3, herefter et mellem 0 og 9, herefter et mellem 0 og 1, herefter tre vilkårlige tal, herefter en -, og slutteligt fire vilkårlige tal. Bemærk, at RegEx-masken ikke validerer et CPR-nummer - hertil skal man bruge en Modulus-kontrol - men den kan bruges til at "luse" de fleste indtastningsfejl ud:
Fold kodeboks ind/udKode 


CustomValidator


CustomValidator-kontrollen kan bruges der hvor ingen af de andre kontroller kan benyttes - man skriver nemlig selv valideringskoden. Der kan skrives til validering på både klient- og serverplan, men medmindre man er god til JavaScript, er validering på serveren klart det nemmeste.

De specifikke medlemmer til kontrollen er som følger:

[table][tr][td]Medlem[/td] [td]Beskrivelse[/td][/tr][tr][td]ClientValidationFunction (egenskab)[/td][td] Reference til en eventuel DTML-funktion (til validering på klientplan) skrevet i eksempelvis JavaScript eller VBScript.[/td][/tr] [tr][td]ServerValidate (hændelse)[/td] [td]Hændelsen kan bruges til at skrive kode på serverplan til at foretage validering.[/td][/tr][/table]

På opmærkningsplan kan kontrollen beskrives i sin simple form som følger:
Fold kodeboks ind/udKode 

I koden vil valideringen ske på serverplan via hændelsen ServerValidate, som kan fanges i ServerValidate-metoden:
Fold kodeboks ind/udKode 


Af de til metoden overførte argumenter er ServerValidateEventArgs i denne sammenhæng mest interessant. Det er blandt andet her man kan påvirke IsValid-egenskaben, og dermed lade valideringen fejle eller være succesfuld. Yderligere kan det i tekstboksen indtastede findes i Value-egenskaben (kan dog også findes via Sender-objektet).

Lad os se på et eksempel som benytter validering på serverplan:

I Danmark er det i den finansielle branche om ikke standard så meget udbredt at indtaste datoer som ddmmyy, og ikke som .NET kan håndtere eksempelvis dd-mm-yy. I formularer hvor der skal indtastes datoer kan det derfor give lidt bøvl fordi valideringskontrolleren ikke kender denne "standard". Derfor er det oplagt at skrive sin egen valideringsrutine, og kombinere den med CustomValidator-kontrollen. Se følgende side:
Fold kodeboks ind/udKode 

Den består af en tekstboks, en customvalidator og en knap. Tilføj så følgende kode afhængigt af sprog:
Fold kodeboks ind/udKode 


Det indtastede valideres i CustomValidator1_ServerValidate(…) ved at forsøge at konvertere til en dato (det indtastede findes i e.Value). Hvis konverteringen lykkes, tildeles IsValid-egenskaben værdien Sand, ellers Falsk. Bemærk, at valideringen ligesom andre valideringskontroller fortsat vil acceptere en tom streng.

ValidationSummary


Den sidste kontrol vi kigger på i denne lektion, er ValidationSummary-kontrollen. Den bruges ikke til validering, men til at samle alle fejlmeddelelser på et sted.


Figur 1 Brug af ValidationSummary-kontrollen.

Ud over eksempelvis farve og font har den et par interessante egenskaber som vi skal kigge lidt på:
[table][tr][td]Egenskab[/td] [td]Beskrivelse[/td][/tr]
[tr][td]DisplayMode[/td] [td]Angiver hvordan meddelelser skal vises:
- List (liste)
- BulletList (liste med "bullets")
- SingleParagraph (afsnit)[/td][/tr][tr][td]HeaderText[/td] [td]Den tekst der skal angives over
meddelelserne (det kunne eksempelvis være "Disse fejl er opstået:").[/td][/tr][tr][td]ShowMessageBox[/td] [td]Fejl vises i en meddelelsesboks (hvis browseren kan håndtere DHTML).[/td][/tr][/table]

På opmærkningsplan kan kontrollen i en simpel form se således ud:
Fold kodeboks ind/udKode 


Da alle fejlmeddelelser samles af kontrollen til visning et sted på siden, er der ikke nogen grund til at vise en fejlmeddelelse for hver enkelt valideringskontrol. Det kan styres ved at tildele valideringskontrollens Text-egenskab en værdi jf. tidligere - eksempelvis kan en stjerne benyttes.

Her er koden bag Figur 1 fra tidligere som viser brugen af kontrollen (og brug af Text-egenskaben):
Fold kodeboks ind/udKode 

Bemærk de to valideringskontroller, som begge benytter Text-egenskaben til at angive, at der skal vises en * ved fejl. Selve fejlmeddelelsen vises under knappen ved hjælp af ValidationSummary-kontrollen.

Nu har vi været igennem alle valideringskontrollerne, og afslutter den teoretiske gennemgang af denne funktion i ASP.NET som kan spare en frygtelig masse tid (se blot sidste eksempel - det skal der en del kode til at lave selv).

I næste lektion bruger vi en del af kontrollerne i formularen fra lektion 9 for at se på validering i praksis.

Hvad synes du om denne artikel? Giv din mening til kende ved at stemme via pilene til venstre og/eller lægge en kommentar herunder.

Del også gerne artiklen med dine Facebook venner:  

Kommentarer (0)

Du skal være logget ind for at skrive en kommentar.
t