7
Tags:
grails
hjemmeside
database
groovy
Skrevet af
Bruger #5097
@ 19.08.2011
Domæne begrænsninger
Når du beder en bruger indtaste forskellige oplysninger, har du højt sandsynligt forskellige krav til hvad deres formular skal indeholde. Eksempelvis kan man forestille sig at følgende skal gælde for 4 felter for en bruger:
Brugernavn skal være unikt og ikke tomt.
Password skal have en længde fra 6 til 30 ord og ikke tomt.
E-mail skal have den rette mail-syntaks (@, top-domæne og så videre), og ikke være tomt.
Alderen må ikke være mindre 0 år og ikke må være tomt.
Sådanne krav kan i domænet meget let defineres, således at det kun står et sted i koden, og du aldrig mere behøver tænke over kravene, når du senere skal bruge domænet.
Lad os derfor gå kikke på de domæne fil (ligger i
grails-app/Domain) som vi vi ønsker at tilføje disse begrænsninger. I denne artikel vil vi beskæftige os med følgende domæne:
- class User {
- String user
- String password
- String mail
- Integer age
- }
Måden vi tilføjer disse begrænsninger er nu ved ganske simpelt at oprette propertyen
constraints som det ses nedenfor:
- static constraints = {
- user(blank:true, unique:true)
- password(size:6..30)
- mail(email:true)
- age(min:0)
- }
Vi ser her at vi giver de begrænsninger som nævnt tidligere. Dette er dog kun en lille del af alle de mulige egenskaber du kan vælge. Her er der en oversigt over nogen af de jeg finder vigtigst:
Navn Eksempel Beskrivelse
======== ========= ==========
blank blank:false Gør det ikke muligt at lade feltet være tomt,
email email:true Sættes til true hvis stringen skal være en e-mail.
InList inList:['Element1', 'Element2'] Element skal være i listen
min min:6 Må ikke være mindre end denne værdi
max max:6 Må ikke være større end denne værdi
unique unique:true Sættes til true hvis den skal være unik
url url:true Sættes til true hvis stringen skal være en url adresse.
Du kan læse mere om dette her:
http://www.grails.org/doc/latest/ref/Constraints/Usage.htmlFindes der ikke en standart egenskab, er det også muligt at lave sine egne, hvilket vi dog ikke ser på her. Den samlede kode ser nu således ud:
- class User {
- String user
- String password
- String mail
- Integer age
-
- static constraints = {
- user(blank:false, unique:true)
- password(blank:false, size:6..30)
- mail(blank:false, email:true)
- age(blank:false, min:0)
- }
- }
Hvordan behandles fejlIndtaster en bruger oplysninger i en formular som ikke overholder vores restriktioner, skal vores siden naturligvis håndterer dette. Vores bruger skal modtage en fejlmeddelelse med besked om hvad der er galt.
Genererer du en controller og et view til din model (brug generate-all som beskrevet i forrige artikel, vil du kunne køre dit program. Og du vil bemærke at vores controller allerede håndterer dette. Dette skyldes at vi i save og update benytter og af instans.save() til at gemme:
- if (userInstance.save(flush: true)) {
- //Blev gemt
- } else {
- //Fejlede
- }
Hvis begrænsningerne ikke bliver overholdt returnerer
instans.save() nemlig false, og vi vil bliver videresendt tilbage til formularen igen.
Hvis du gerne ønsker at tjekke om inputtet er lovligt uden at gemme, kan funktionen
validate() benyttes:
- if (userInstance.validate) {
- //Valideret
- } else {
- //Fejlede
- }
Bemærk hvorledes Grails uden videre allerede sørger for at vise fejlmeddelelser. Dette gør den idet at fejlene under
save() bliver gemt i vores domæneobjekt,
userInstance. I vores view bliver dette bemærket og fejlmeddelelser med mere bliver derfor vist. Dette vil jeg komme ind på i en anden artikel.
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 (3)
Lovely.... Denne artikel var længe ventet
Tak!!!
Hej Theis
Er der en tredje del i trykken?
\ Martin
Hey og tak for at du kan lide det. Lige pt ikke, men hvis jeg får tid. Måske i starten af januar...
I øvrigt er jeg informeret om at der nok er nogle ukorrektheder omkring many-to-many relationer. Jeg har ikke lige tid til at kikke på det nu, men det afsnit kan det anbefales evt at få dobbeltchecket hvis der er brug for.
Du skal være
logget ind for at skrive en kommentar.