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