Dans ce troisième article sur le framework Grails, nous allons aborder la validation. Cela vous permettra de définir des contraintes sur votre objet qui devront être respectées lors de sa création.
Nous partons du principe que vous avez déjà suivi les deux articles précédents : Introduction à Grails et Grails partie 2 : création d’une application basique.
Changer l’ordre des champs
Vous aurez probablement remarqué que l’ordre d’affichage des champs dans la vue ne correspond pas à celui de notre objet. Par exemple pour l’objet Race :
[pastacode lang= »java » message= » » highlight= » » provider= »manual »]
class Race {
String name
Date startDate
String city
BigDecimal distance
BigDecimal cost
Integer maxRunners
static constraints = {
}
}[/pastacode]
Pour organiser les champs, il suffit de les écrire dans l’ordre souhaité dans le bloc statique constraints qui a été généré au préalable.
[pastacode lang= »java » message= » » highlight= » » provider= »manual »]
static constraints = {
name()
startDate()
city()
distance()
cost()
maxRunners()
}[/pastacode]
Si vous regénérez les vues, vous pourrez voir que l’ordre a cette fois-ci été conservé :
Contraintes
Le bloc statique constraints a également une autre utilité, celle de nous permettre de spécifier des contraintes sur chaque champ de notre objet.
Imaginons que l’utilisateur entre une distance négative pour une course, renseigne une date de départ inférieure à la date actuelle, ou encore oublie de taper le nom de la course. Cela peut vite devenir problématique. Grails nous permet donc de spécifier facilement des contraintes de validation. Il existe de nombreuses contraintes déjà utilisables, vous pouvez en consulter la liste complète sur la documentation officielle. Nous en utiliserons seulement quelques-unes pour l’exemple.
Restons sur notre classe Race pour commencer. Nous devons appliquer les règles de validation suivantes :
– Le nom de la course est obligatoire et ne doit pas dépasser 40 caractères.
– La date de départ doit être supérieure à la date actuelle.
– La ville doit forcement être Paris ou Marseille.
– La distance ne peut pas être négative.
– Le coût ne doit pas être négatif ni dépasser 100€.
– Le nombre maximal de participants ne doit pas être négatif ni dépasser 1000.
Pour cela, rien de plus simple grâce aux validateurs déjà existants :
[pastacode lang= »java » message= » » highlight= » » provider= »manual »]
static constraints = {
name blank: false, maxSize: 40
startDate()
city inList:["Paris", "Marseille"]
distance min: 0.0
cost min: 0.0, max: 100.0
maxRunners min: 0, max: 1000
}[/pastacode]
Nous avons ici l’utilisation de 5 validateurs différents :
[table id=3 /]
En plus de se servir de propriétés HTML5, Grails effectuera également une vérification côté serveur avant la sauvegarde de l’objet dans la base de données.
Vous pouvez maintenant regénérer la vue de Race et essayer de renseigner des valeurs invalides.
Comme vous pouvez le constater, Grails vous avertira lorsqu’une contrainte n’est pas respectée.
Il nous reste maintenant un cas à traiter, celui de la date de départ. Malheureusement, Grails ne propose pas de validateur pour ceci. Nous allons donc le créer nous même.
Contraintes personnalisées
Créer une contrainte personnalisée est très simple. Il est nécessaire de savoir que votre validateur se présentera sous la forme d’une closure Groovy, qu’il devra retourner un booléen et qu’il pourra utiliser en son sein la variable it qui représente la valeur entrée par l’utilisateur. Ainsi, pour vérifier si la date entrée est bien supérieure à la date actuelle, il nous suffit de faire :
[pastacode lang= »java » message= » » highlight= » » provider= »manual »]
startDate validator: {return (it > new Date())}[/pastacode]
Vous pouvez tester cette contrainte en entrant une date invalide :
Notre validateur est bien fonctionnel. Toutefois, vous aurez surement remarqué que les messages d’erreurs ne sont pas très « esthétiques », ni très explicites dans le cas de validateurs personnalisés. Il est heureusement possible de les changer facilement et sans toucher aux vues.
Messages d’erreur
Pour changer les messages d’erreur par défaut, ouvrez le fichier i18n -> messages_fr.properties. Plutôt que de changer les valeurs par défaut, nous allons ajouter des messages pour la classe Race. Pour cela, ajoutez ceci à la fin du fichier :
[pastacode lang= »javascript » message= » » highlight= » » provider= »manual »]
race.name.blank = Veuillez renseigner un nom pour cette course.
race.name.maxSize.exceeded = Le nom d'une course ne doit pas dépasser 40 caractères.
race.startDate.validator.invalid = Une course ne peut pas se dérouler dans le passé !
race.distance.min.notmet = La distance d'une course ne peut être négative.
race.cost.min.notmet = Le coût d'une course doit être supérieur à 0€.
race.cost.max.exceeded = Le coût d'une course ne peut pas dépasser 100€.
race.maxRunners.min.notmet = Une course ne peut pas accueillir un nombre négatif de participants.
race.maxRunners.max.exceeded = Une course ne peut pas accueillit plus de 1000 participants.[/pastacode]
Pour connaître le code d’erreur de chaque validateur, référez-vous à la documentation officielle et choisissez ensuite dans le menu de droite le nom de votre validateur.
Les messages ont maintenant bien été changés :
Ainsi, nous avons vu dans cet article comment mettre en place simplement et rapidement des contraintes sur les différents champs de nos objets. Vous pouvez si vous le souhaitez en ajouter également sur la classe Runner, cela vous fera pratiquer notamment les validateurs email et unique.
Dans le prochain article, nous resterons encore dans les domain-classes et nous verrons comment créer des relations entre nos objets.
Sources
http://www.infoq.com/minibooks/grails-getting-started
