FW.

GraniteDS 2.2 comes with an ActionScript3 implementation of the Bean Validation specification and its code generation tools may be configured to automatically replicate Java bean constraint annotations into the generated ActionScript3 model.

FW.

Hum, un peu des deux

En fait, le bug concernant l’internationalisation et la mise en œuvre de sa correction sont, AMHA, spécifiques à Hibernate Validator 4.x.

La verbosité de l’API et la non prise en compte des génériques sont eux plus à lier à la JSR303 elle même.

Au demeurant, ces 2 derniers points ont certainement fait l’objet de discussion pendant l’élaboration de la JSR et, assurément, ne sont pas d’une résolution aisée. Mais le résultat reste verbeux et surprenant à l’heure de Java 7.

++
joseph

merci pour ce retour d’expérience.

Lorsque vous parlez de « réalisation de l’API pas tip top », il s’agit d’Hibernate Validator ?

S’il n’y a pas de besoins particuliers pour migrer vers un framework standard et que les services de validations « manuels » sont satisfaisants, autant rester sur un existant qu’on maîtrise bien.

Pour de nouveaux projets par contre je trouve ça intéressant de pouvoir s’appuyer sur un socle commun et pouvoir profiter de l’expérience d’autres projets.

Sympa cette présentation détaillée.

Pour avoir mis en pratique Bean Validation depuis sa sortie, voici quelques retours d’expériences:
- intégration avec Wicket est sympa (cf http://mvnrepository.com/artifact/org.wicketstuff/jsr303), surtout le PropertyValidator (à condition d’utiliser des PropertyModel partout, rien n’est parfait)
- principe fort intéressant: les entités définissent désormais le « socle vital » de règles de validations (ce qui est nommé les invariants plus haut). Avoir tout cela en un seul endroit et repris partout ailleurs est vraiment intéressant.
- réalisation de l’API pas tip top : l’implémentation de l’internationalisation avait un bug plus que surprenant. Plus embêtant, l’implémentation est verbeuse et ne prend pas en compte les génériques, par exemple un Set.

au final, on est mieux avec que sans, mais l’API aurait sans doute pu être plus compact et proche de Java6.

++
joseph

Effectivement c’est possible avec les groupes. Mais moi j’aime la simplicité . Lorsqe ça devient trop fastidieux de définir un ensemble de contraintes j’aime autant encapsuler ma validation dans une classe que j’appelle.

Je vais explorer les groupes plus en profondeur mais par principe je préfère encapsuler mes validations dans une classe (ça me permet d’être fortement cohésif) dont la responsabilité est de valider un Use Case complexe qui implique plusieurs objets qui collaborent entre eux. C’est plus cohésif mais très certainement moins industrialisable pour les outils de génération.

Je préfère une classe de type RenewXXXValidator qui va faire des contrôles de type business dans les objets metiers User, Transaction, Advert, Media
plutôt que de définir un groupe @RenewXXX sur les propriétés de chacun des objets ci-dessus qui participent au renouvellement de XXX.

Je suppose que je me fais vieux et que je devrais me mettre aux nouveaux outils .

Bonne soirée.

D’après la doc hibernate ( http://docs.jboss.org/hibernate/annotations/3.5/reference/en/html/additionalmodules.html#d0e3875 ), il suffit effectivement d’ajouter dans le classpath un jar implémentant la jsr-303. Si on veut forcer la présence de ce jar il faut passer en mode callback et si au contraire on ne veut pas du tout de validation il faut le mode none.

J’espère que ça répond à ta question.

Merci pour ce retour d’expèrience concret.

Il me semble que dans tes deux cas on peut tout de même utiliser la jsr-303 en s’appuyant sur la notion de groupe ( http://people.redhat.com/~ebernard/validation/#validationapi-validatorapi-groups ).

Par exemple pour le cas de l’annulation, on créerait une interface AnnulationCheck. L’annotation serait donc @NotNull(groups={AnnulationCheck.class}). Ensuite pour la validation en cas d’annulation validator.validate(monObjet, AnnulationCheck.class). Dans les autres validations, si on ne précise pas le groupe, la validation sera désactivée sur le champ commentaire.

L’autre exemple semble plus complexe mais je pense que cette solution doit fonctionner aussi.

J’ai une petite question concernant le javax.persistence.validation.mode: Si on ne configure rien, par défaut cette propriété est en auto c’est ca ? (si j’en crois la doc jboss)

Pour quand on ne met rien, on ne retrouve pas les contraintes en bdd dans le schéma.

Une idée ?

Merci pour l’article. L’intégration à Spring est intéressante.
J’aimerais juste apporter un éclairage sur l’utilisation de la jsr-303.

La validation fournie par la jsr-303 est une validation de type « validation donnée ».
Elle est effectivement intéressante pour les « invariants ». Les invariants sont des données qui ont la même validation quel que soit le use-case.
Exemple : donnée obligatoire, format de sécurité sociale, etc.
On ne pourra pas valider de telles contraintes :
– BR-127 : La raison d’une annulation est obligatoire
– BR-542 : Le nombre maximal d’alertes est de 3 tant que la transaction est à l’état « non payée ».

La 1ère règle montre que le champ « commentaire » est non obligatoire d’habitude mais est obligatoire dans le cas d’une annulation. Dans ce cas il ne faut pas annoter le champ @NotNull.
La 2ème règle montre bien que l’on ne peut pas annoter @Valid sur le collaborateur Transaction, ni annoter @Size(min = 0, max = 3) sur le collaborateur Set. Ca n’est pas vrai dans tous les cas.

La solution est d’utiliser la jsr-303 pour les invariants de format (donnée correctement formatée, périmètre de valeur correct, type de valeur correct, caractère obligatoire permanent).
Pour une gestion des données qui dépendent du use-case, utiliser un validateur.
Le concept est celui des validateurs spring mais sans être liée à l’API d’erreur qui est lourde d’après moi. On prendra soin d’invoquer le validateur de la jsr-303 (pour appliquer la validation données) avant de commencer notre validation métier.

Cdt,

Louis.