Datavalidering ved hjelp av IsMatch og variabler

I denne opplæringen skal vi snakke om datavalidering og hvorfor vi trenger det i appene våre.

Vi har diskuterti tidligere opplæringsprogrammer, og det er utrolig hvordan vi kan tillate sluttbrukere å legge inn nye data eller endre en eksisterende informasjon sømløst gjennom appen vår. Det vil imidlertid være tilfeller der en sluttbruker kan skrive inn informasjon som ikke samsvarer med det skjemaet krever. Det er her datavalidering kommer inn.

Innholdsfortegnelse

• Hva er datavalidering?
• Datavalidering ved hjelp av IsMatch
• Datavalidering ved hjelp av variabler
• Sikre en komplett valideringsprosess
• Konklusjon

Hva er datavalidering?

Datavalidering forhindrer sluttbrukere i å sende inn feilaktige data i skjemaene dine.

For eksempel gir det ikke mening å ha tall knyttet til et navn.

Noen kan også skrive inn 1 i stedet for I som en feil.

Uten datavalidering vil et trykk på Send-knappen automatisk oppdatere backend-datakilden. Dette kan forårsake problemer med å vite at det var feil i informasjonen som ble gitt. Datavalidering bidrar til å unngå dette problemet.

Datavalidering sjekker for visse regler og parametere som hjelper til med å avgjøre om skjemadataene kan sendes inn eller ikke.

Det er forskjellige måter å sette opp datavalidering i Power Apps. La oss gå gjennom noen av de beste måtene å gjøre det på.

Datavalidering ved hjelp av IsMatch

Tidligere nevnte vi at datavalidering følger et sett med regler. Når det gjelder eksemplene vi viste, var hovedproblemet å ha tall skrevet inn i felt der tall ikke gir mening. I tilfeller som disse kan IsMatch-funksjonen hjelpe oss å unngå det.

For å forstå hvordan IsMatch fungerer, la oss se på Microsoft Power Apps-dokumentet .

IsMatch tar en tekst, et mønster og noen alternativer. I utgangspunktet viser dette at denne funksjonen vurderer teksten basert på mønsteret.

Teksten dekker alt som sluttbrukeren skriver inn i tekstboksen. Når det gjelder mønsteret, er det en rekke forskjellige forhåndsbestemte som komma, sifre eller e-postadresser.

Hvis du velger e-postmønsteret, for eksempel, kommer IsMatch til å sørge for at teksten som er skrevet inn samsvarer med det mønsteret. Derfra ville den returnere enten en sann eller usann.

I vårt tilfelle skal vi bruke mønsteret for Digit. Dette dekker alle enkeltsiffer fra 0 til 9.

Når vi bruker dette mønsteret, vil IsMatch-funksjonen lete etter et hvilket som helst siffer i teksten og vil returnere en sann eller en usann avhengig av hva den finner.

Det er også spesifikke parametere som bidrar til å gjøre formelen vår mer presis når du bruker IsMatch-funksjonen. I dette tilfellet skal vi bruke parameteren Inneholder. Denne parameteren sjekker om mønsteret vises i teksten, men trenger ikke nødvendigvis å begynne eller slutte med det.

La oss gå tilbake til appen vår og se hvordan vi kan bruke det på skjemaet vårt.

Vi begynner med å legge til en etikett.

La oss plassere den i nærheten av Send-knappen.

Vi vil ha teksten på etiketten dynamisk produsert. Men for nå, la oss fokusere på å bruke FirstName-feltet, som er DataCardValue16.

Vi gjør dette til en IF-erklæring. I utgangspunktet, hvis denne formelen returnerer sann, vil vi at etiketten skal vise "Data Validation Error". Ellers forblir den blank.

Siden en IF-setning starter med en logisk tekst, setter vi inn vår IsMatch-funksjon her, som refererer til teksten i Fornavn-feltet. Dette er representert ved DataCardValue16.Text.

Vi vil også følge det opp med det faktiske mønsteret som vi vil at denne logikken skal se etter. La oss legge til Match.Digit.

Til slutt ønsker vi å legge til noen matchalternativer. Vi leter egentlig ikke etter den eksakte teksten her. I stedet vil vi bare matche et hvilket som helst siffer som teksten inneholder. Så vi legger til vår Inneholder-parameter.

Enkelt sagt spør denne formelen, vises noe siffer hvor som helst i teksten? Hvis den returnerer sann, vil etiketten si Data Validation Error. Hvis ikke, forblir den blank.

La oss prøve det. Så hvis vi skriver Lewis i tekstboksen, men bruker 1 i stedet for I, viser etiketten Data Validation Error.

Legg merke til at vi ikke engang trengte å skrive hele navnet ferdig. I det øyeblikket vi skrev inn 1, viste etiketten umiddelbart feilen.

Vi kan tilpasse denne etiketten for å gjøre feilen mer merkbar. Bortsett fra å gjøre teksten større, la oss gjøre den rød for å indikere at det er en feil.

Så hvis sluttbrukeren ser denne feilen, forteller den dem at de skrev inn feil data og burde fikse det.

Datavalidering ved hjelp av variabler

Selv om vi har satt opp en etikett som varsler sluttbrukeren om feilen i dataene de prøver å legge inn, vil du legge merke til at vi fortsatt har en Send-knapp som de kan klikke på selv om det er en feil. Det vi ønsker skal skje er at knappen ikke skal dukke opp når det oppdages en feil.

Det er to måter å gjøre dette på. Den første er en logisk og enklere rute å ta, mens den andre tilnærmingen vil være mer komplisert, men vil også gjøre det enklere for deg når du begynner å legge til mer datavalidering på skjermen.

La oss starte med den første tilnærmingen.

Først kopierer du hele formelen som er brukt på etiketten vår.

Deretter markerer du knappen, velger synlighetsegenskapen under rullegardinmenyen, og limer inn formelen i formellinjen. Dette setter dynamisk knappens synlighet til denne logikken.

Så hvis tekstboksen inneholder et siffer, vil ikke knappen være synlig.

La oss se om det fungerer. Hvis jeg endrer bokstaven O i Coy til en null, vil du se at feilen dukker opp og Send-knappen forsvinner.

Hvis vi endrer dette tilbake til en O, kommer knappen tilbake.

Problemet med denne tilnærmingen er at vi bruker den samme logikken på to forskjellige steder - etiketten og knappen. Dette betyr at hvis det er noe å endre, må du gjøre det på to forskjellige steder også. Dette kan bli slitsomt, spesielt hvis du har lagt til mer valideringslogikk senere.

For å løse det problemet, legger vi til en annen knapp. La oss plassere den nye knappen ved siden av Send-knappen.

La oss kalle dette Valider-knappen.

Så la oss legge den samme logikken i denne knappen.

Det vi vil at denne knappen skal gjøre er å oppdatere en variabel for oss, som oppdaterer konteksten.

Så la oss fjerne den delen av formelen som ber logikken om å vise Data Validation Error og la oss endre det til UpdateContext.

Vi trenger det for å referere til en variabel, så la oss lage en variabel som heter Submit . Vi setter dette til usann i tilfelle valideringsfeilen faktisk oppstår.

Deretter vil vi umiddelbart følge det opp med samme format, men denne gangen setter vi det til sant i tilfelle tekstboksen ikke inneholder et siffer.

Det vi gjorde var å gjøre knappenes synlighet avhengig av variabelen vi laget i stedet for av logikken. Så vi må også endre logikken på Send-knappen og bare gjøre dens synlighet lik Submit, som er variabelen vi snakker om.

Så la oss skrive inn Coy i tekstboksen, så klikker vi på valider.

Som du kan se, dukker Send inn-knappen opp etter at vi har gjort det.

La oss nå endre O til null og la oss klikke på valider. Denne gangen forsvinner send-knappen.

Nå som vi har fikset knappene, la oss endre logikken i etiketten også. For øyeblikket inneholder den fortsatt den originale logikken ved å bruke IsMatch-funksjonen.

Siden vi nå baserer logikken vår på variabelen Submit, vil vi bytte mellom tom og feil. Så hvis Send er sant, vil vi at etiketten skal være tom. Men hvis Send er falsk, vil vi at feilteksten vår skal vises.

For å gjøre feilmeldingen lettere å forstå for sluttbrukere, la oss endre den til "Mulig datavalideringsfeil – klikk på Valider for å sjekke".

For å teste den nye logikken vi brukte, la oss gå til en annen post for Anitra og klikk på Rediger-ikonet.

Som du kan se, er det ingen valideringsfeil på denne siden ennå.

Hvis jeg endrer Anitra til Anitr0 og klikker Valider, er det da feilmeldingen kommer ut.

Sikre en komplett valideringsprosess

På grunn av måten vi har satt opp datavalideringsprosessen på denne skjermen, er det to mulige problemer som fortsatt vil føre til at feil data sendes inn.

Det første problemet er at det er mulig å hoppe over å klikke på Valider-knappen fordi Send-knappen fortsatt er synlig med mindre en feil oppstår fra valideringsprosessen. Så vi kan for eksempel bare skrive inn Alons5, ignorere Valider-knappen og trykke på Send-knappen med en gang.

Det andre problemet er at hvis vi validerer en korrekt oppføring, kan vi fortsatt gå tilbake til tekstboksen og skrive inn alt vi vil. Så hvis Send-knappen dukker opp, kan hvem som helst enkelt gå tilbake til tekstboksen, skrive inn et siffer og klikke på Send-knappen.

Vi må gjøre Submit-variabelen falsk som standard. Vi må også sørge for at når noen klikker på tekstboksen, går alt tilbake til standardmodus.

Så la oss gå til Fornavn-feltet og velge OnSelect i rullegardinmenyen for egenskaper. La oss deretter bruke UpdateContext og referere til Submit-variabelen. Så setter vi det til usann.

Nå, hver gang noen klikker på tekstboksen, ber den automatisk brukeren om å klikke på Valider først.

Så hvis jeg prøver å endre fornavnet til Frank og klikker på Valider, er det den eneste gangen Send-knappen dukker opp.

Men hvis jeg går tilbake til den samme tekstboksen og prøver å legge til 1 på slutten av Frank, går den rett tilbake til standardtilstanden der feilen vises og Send-knappen forsvinner.

Konklusjon

Datavalidering bidrar til å beskytte dataene våre og sikrer at sluttbrukere ikke sender inn feil registreringer ved en feiltakelse. Det vi har gått gjennom i denne opplæringen er faktisk bare noe av det grunnleggende. Du kan legge til så mange typer validering som du vil.

I tillegg angir vi kun datavalidering for fornavnet. Du kan gå videre og gjøre det samme for etternavnet. Du kan til og med angi VIP-nivået eller passnummeret til kun å vise sifre. Alt avhenger av hvilke felt du vil bruke ulike valideringsprosesser på.

Beste ønsker,

Henry