27 Dec
2010
27 Dec
'10
9:36 a.m.
On Mon, 27 Dec 2010 10:21:31 +0100 Jean Couteau <couteau@codelutin.com> wrote: > Bon, j'ai rien fait encore, on en rediscute mercredi à 15h pour ceux > que ça intéresse. > Je peux déjà te donner quelques éléments pour qu'on entame le dialogue :) > Le 21/12/2010 18:41, Jean Couteau a écrit : > > Hello everybody > > > > On utilise la validation xworks dans Jaxx, maintenant dans Coser, et > > j'en ai besoin dans Refcomp, du coup l'idée c'était de faire un > > librairie et comme c'est plutôt pas trop gros de mettre ça dans > > nuiton-utils. - Y'a une évolution dans jaxx pour extraire l'api non liée à jaxx du BenaValidator. - Coser, Observe utilise jaxx-validator (ça sera son nom) et pas directement xworks - Struts lui utilise directement xWorks mais on pourrait imaginer faire une model dans nuiton-web un module qui se base sur notre moteur de validation (qui intègre des scopes contrairement à xworks) - Pour GWT je sais pas ce qui se passe ? Y'a ce qu'il faut pour le javascript ? je suis pas certain à moins que tu parles de validation côté serveur ? je vois pas trop ton but :) > > > > Comme ça tire plein de dépendance, l'idée c'était de mettre ça dans > > un module et donc de passer nuiton-utils en multi-module. On aurait > > du coup trois modules : > > - Pour ce qui est des dépendances y'en a 2 uniquement si mes souvenirs sont bons donc pas de quoi fouetter un chat (miaou?) > > nuiton-utils (regroupe le nuiton-utils actuel) > > nuiton-utils-extra (le projet nuiton-utils-extra actuel qui du coup > > disparaitrait) > > nuiton-utils-validation (la validation basée pour l'instant sur > > xworks, mais qui pourrait potentiellement changer d'implantation). euh plutot nuiton-utils-validator ? > > > > > > Nuiton-utils-validation > > ======================= > > > > On aurait une classe Validation qui instancie xworks et fait les > > validations avec une méthode validate(Object) : ValidationResult > > c'est plus complexe que ça! - Ce que tu décris comme api est trop simpliste je pense car y'a un peu plus que 3 classes à gerer pour se plugger sur XWorks... Il faut intégrer la notion d'un modèle de validation et pas des petites map sur lequel on peut rien faire... > > ValidationResult contient les différents messages et niveau > > d'erreur. On a alors : > > > > isSuccess() : Boolean //true si aucun message > > > > getLevel() : Set<Level> //les niveaux d'erreurs présents dans le > > résultat > > > > getField(Level) : List<String> // retourne tous les fields en erreur > > pour un niveau d'erreur. Si on pass null en paramètre, pour tous > > les levels. > > > > get(Level,String (fieldName)) : List<String> //Retourne tous les > > messages d'erreur pour un field et un level. Si on passe la > > constante #Bean en fieldName, on a les erreurs sur le bean. > > > > put(Level, String (fieldName), String) //Ajoute des messages pour un > > niveau et un champ > > > > addTagValue(String,String) > > getTagValue(String) : String euh... Faudrait penser à arrêter à essayer de mettre du flottant partout, les tag-values n'ont rien à faire dans une api de validation, c'est déplacé, non ? > > > > Du coup en interne c'est géré par une Map <Level, Map <String > > (fieldName), String (message)>> messages et une Map <String, String> > > tagValues. > > De manière générale, ce travail a déjà été fait dans jaxx, il faudrait peut-être juste un peu l'assainir mais certainement pas tout réécrire. Je pense sincèrement que ce qu'il y a dans jaxx tient la route et il faut partir de ça... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com