Hello, Florian a émis le souhait de s'atteler à ToPIA 3 prochainement, cool :) Il faudrait qu'on définisse clairement ce qu'on veut faire car il ne s'agit pas de faire ça sur un bord de table, la plupart de nos applications utilisant ToPIA il faut assumer :) et limiter la casse lors de la migration vers la future version 3. Ce qui doit être fait selon moi : - Ecrire un nouveau TopiaContextImpl qui utilise EntityManager au lieu de la session hibernate (et encore, je suis même pas sûr, on pourrait peut-être continuer à utiliser la session hibernate 4...) - Déprécier tout les code qu'on ne veut plus dans ToPIA (j'en avais écrit pas mal dans un paquet util mais je pourrais le redescendre dans ObServe je pense car au final c'est assez spécifique) cela doit être fait avant la version 3 pour le supprimer en version 3! - Supprimer tout le code déprécié - Revoir le générateur de mapping Au final hormis les requètes basées sur TopiaQuery tout le reste doit rester compatible (i.e les entités et dao doivent être identiques). Qui dit mieux ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 14/03/2012 16:17, Tony Chemit a écrit :
Au final hormis les requètes basées sur TopiaQuery tout le reste doit rester compatible (i.e les entités et dao doivent être identiques).
Ma wishlist : - Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish. OK il n'est pas accessible mais il est toujours dans les entités et ça fout la merde à la sérialisation et autres manœuvres par introspection - Une approche « bonne pratique par défaut » pour ne pas avoir de boilerplate tagValues (0 config = config propre). Par exemple, on ne devrait pas avoir besoin de mettre model.tagvalue.constantPrefix=PROPERTY_ puisque ne pas le mettre est une mauvaise idée. Ceux qui n'en veulent pas ont qu'à mettre model.tagvalue.constantPrefix= De même, ce truc devrait déjà être à true par défaut model.tagValue.doNotGenerateBooleanGetMethods=true - Pas de TopiaQuery, comme c'est trop compliqué de faire un truc qui gère toutes les subtilités d'un langage de requêtes complexes tout en étant compile-safe. Dans les DAOImpl, autant écrire direct avec l'API JPA Criteria, HQL ou SQL direct. - Il faut empêcher le couplage JPA/services et donc rendre DAO#createQuery() et findByQuery, countByQuery protected. cf Wao, ex-Pollen, Lima... - (y'a rien à faire mais bon) Arrêter de modéliser les dao vue que ça sert à rien à part perdre du temps. - Déprécier || Supprimer ServiceTransformer. Modéliser les services n'apporte rien (ou pas assez), le code généré est bien trop lourd (comparé aux pauvres POJO qu'on a dans l'extranet). Ou alors le revoir complètement mais pour moi c'est de l'archi et pense qu'on ne peut pas faire quelque-chose qui conviennent à tous les cas de figure : client lourd, applis distantes (via EJB comme lima), appli web 3-tiers avec framework web stateless vs statefull. Pour moi, y'a pas d'approches commune possible pour tout ça. - TopiaException extends RuntimeException. Y'a 0 impact pour que le code soit compatible mais on gagnera des dizaines de lignes dans toutes nos applis. C'est une exception technique et donc ça n'a rien à faire en checked exception, on peut jamais la catcher utilement. - Assumer qu'on fait du simili-DBdesigner et pas du DDD, dans ToPIA, on modélise une base de données relationnelles (pas trop de bidi etc...) et non un modèle métier. Donc ToPIA ne devrait pas m'imposer d'ajouter le stéréotype entity sur *toutes* les classes une par une que j'ajoute puisque de toute façon toutes les classes que j'ajoute sont des entités, y'a que ça dans mon modèle. Placer toutes ces classes dans un package entity (c'est déjà le cas, dans le pom on précise le package en question) devrait suffire. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
Le 14/03/2012 17:20, Brendan Le Ny a écrit :
- Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish. OK il n'est pas accessible mais il est toujours dans les entités et ça fout la merde à la sérialisation et autres manœuvres par introspection
Je ne vois pas le problème avec ça. C'est EXACTEMENT le même principe que hibernate et sa session embarquée. Si le contexte est transient, la serialisation ne devrait pas en tenir compte. Quel est le problème de l'introspection ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 14/03/2012 17:49, Eric Chatellier a écrit :
Si le contexte est transient, la serialisation ne devrait pas en tenir compte.
Je ne parlais pas de la sérialisation au sens java.io.Serializable qu'on utilise assez pas. Je voulais parler de sérialisation json, xml, yaml, autres (via struts-json, ou xstream)... qui fonctionnent en faisant de l'introspection sur le POJO pour récupérer les propriétés et leurs valeurs. Du coup ça essaie de sérialiser la terre souvent. Après c'est peut-être les libs en question qui sont pas bonnes et devraient ignorées les propriétés transiantes ou non-public. Y'a un autre souci avec ça dans Hibernate, mais c'est Tony qui l'a eu. Il me semble que c'est un calcul de equals, qui faisait chaipasquoi en comparant les propriétés une à une et de mémoire, là aussi, le topiaContext dans l'object avait posé problème. C'est même depuis ce truc là qu'on a essayé de l'enlever mais Tony pourra nous rafraichir la mémoire. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
Le 14/03/2012 17:49, Eric Chatellier a écrit :
Je ne vois pas le problème avec ça.
D'une façon générale. Chez Code Lutin, on utilise (est bien où mal, c'est un autre débat), le même classe pour toutes les couches. Le POJO généré par Topia se trouve utilisé dans l'UI (web ou lourde), dans les services, et dans la couches de persistance (dans une appli 3-tiers évidemment). Ça me paraît problématique niveau design, d'avoir un couplage entre le POJO en question et une de ces trois couches. Donc le POJO doit être aussi bien découplé de la session Hibernate que de la session Jetty par exemple. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
Le 14/03/2012 16:17, Tony Chemit a écrit :
- Ecrire un nouveau TopiaContextImpl qui utilise EntityManager au lieu de la session hibernate (et encore, je suis même pas sûr, on pourrait peut-être continuer à utiliser la session hibernate 4...)
L'EntityManager devrait suffir, je regarderais pour la Session hibernate 4 ce qu'elle apporte de plus.
- Déprécier tout les code qu'on ne veut plus dans ToPIA (j'en avais écrit pas mal dans un paquet util mais je pourrais le redescendre dans ObServe je pense car au final c'est assez spécifique) cela doit être fait avant la version 3 pour le supprimer en version 3!
+1
- Supprimer tout le code déprécié
+1
- Revoir le générateur de mapping
+1 On Wed, 14 Mar 2012 17:20:26 +0100, Brendan Le Ny <bleny@codelutin.com> wrote:
Ma wishlist :
- Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish. OK il n'est pas accessible mais il est toujours dans les entités et ça fout la merde à la sérialisation et autres manœuvres par introspection
+1
- Une approche « bonne pratique par défaut » pour ne pas avoir de boilerplate tagValues (0 config = config propre). Par exemple, on ne devrait pas avoir besoin de mettre
model.tagvalue.constantPrefix=PROPERTY_
puisque ne pas le mettre est une mauvaise idée. Ceux qui n'en veulent pas ont qu'à mettre
model.tagvalue.constantPrefix=
De même, ce truc devrait déjà être à true par défaut
model.tagValue.doNotGenerateBooleanGetMethods=true
+1, on a aussi le toString
- Pas de TopiaQuery, comme c'est trop compliqué de faire un truc qui gère toutes les subtilités d'un langage de requêtes complexes tout en étant compile-safe. Dans les DAOImpl, autant écrire direct avec l'API JPA Criteria, HQL ou SQL direct.
Snif, sera donc déprécié et supprimé ? Je dirais juste qu'on la laisse là, au pire elle ne fait pas de mal au vu de la proposition suivante.
- Il faut empêcher le couplage JPA/services et donc rendre DAO#createQuery() et findByQuery, countByQuery protected. cf Wao, ex-Pollen, Lima...
+1
- (y'a rien à faire mais bon) Arrêter de modéliser les dao vue que ça sert à rien à part perdre du temps.
- Déprécier || Supprimer ServiceTransformer. Modéliser les services n'apporte rien (ou pas assez), le code généré est bien trop lourd (comparé aux pauvres POJO qu'on a dans l'extranet). Ou alors le revoir complètement mais pour moi c'est de l'archi et pense qu'on ne peut pas faire quelque-chose qui conviennent à tous les cas de figure : client lourd, applis distantes (via EJB comme lima), appli web 3-tiers avec framework web stateless vs statefull. Pour moi, y'a pas d'approches commune possible pour tout ça.
Encore une de mes mauvaises idées :( J'ai l'impression qu'on supprime toutes mes contributions, mais je suis d'accord, avec l'expérience je vois bien les faiblesses de tout ca.
- TopiaException extends RuntimeException. Y'a 0 impact pour que le code soit compatible mais on gagnera des dizaines de lignes dans toutes nos applis. C'est une exception technique et donc ça n'a rien à faire en checked exception, on peut jamais la catcher utilement.
+++++++1
- Assumer qu'on fait du simili-DBdesigner et pas du DDD, dans ToPIA, on modélise une base de données relationnelles (pas trop de bidi etc...) et non un modèle métier. Donc ToPIA ne devrait pas m'imposer d'ajouter le stéréotype entity sur *toutes* les classes une par une que j'ajoute puisque de toute façon toutes les classes que j'ajoute sont des entités, y'a que ça dans mon modèle. Placer toutes ces classes dans un package entity (c'est déjà le cas, dans le pom on précise le package en question) devrait suffire.
Ça je sais pas, pas dans un premier temps. Je me souviens avoir utilisé d'autres classes dans mes diagrammes (ptet pour les services tu me dira...) Je rajouterais d'autres points qu'on a déjà sur redmine, comme rendre instantiable le DAOHelper, ... Pfiou ca fait du boulot. Je pense qu'on va partir sur un ptit cahier des charges de tout ca en partant de l'existant. Je dirais une bonne semaine d'études (voir 2) et de validation avant de se lancer sur le projet. Qu'est ce que vous en pensez ? Ca sux de faire une branche SVN, mais à priori ce sera le mieux... je dirais juste : "vive Git ;)"
On Wed, 14 Mar 2012 18:30:19 +0100 fdesbois <fdesbois@codelutin.com> wrote:
Je pense qu'on va partir sur un ptit cahier des charges de tout ca en partant de l'existant. Je dirais une bonne semaine d'études (voir 2) et de validation avant de se lancer sur le projet.
Perso, je voyais plutot une semaine pour faire le tout, voir 2 pour bien tester sur toutes les applis existantes. Donc si rien que pour l'etude on est deja a 2 semaines, j'ai tres peur pour l'implantation :( -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 14 Mar 2012 17:20:26 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
- Assumer qu'on fait du simili-DBdesigner et pas du DDD, dans ToPIA, on modélise une base de données relationnelles (pas trop de bidi etc...) et non un modèle métier. Donc ToPIA ne devrait pas m'imposer d'ajouter le stéréotype entity sur *toutes* les classes une par une que j'ajoute puisque de toute façon toutes les classes que j'ajoute sont des entités, y'a que ça dans mon modèle. Placer toutes ces classes dans un package entity (c'est déjà le cas, dans le pom on précise le package en question) devrait suffire.
Personnellement je suis pour la simplicité, mais je garderais tout de meme le stereotype entity sur les objets que l'on veut generer en entity. Par exemple on pourrait avoir certaine fois des interfaces entity et certaine fois non. Mais elle serait toujours dans le meme package. Et surtout lorsque je regarde un modele et que je vois le stereotype entity je sais tout de suite le but de l'entity. (S'il n'est plus obligatoire, il va disparaitre, et la facilite de lecture avec :() -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Wed, 14 Mar 2012 18:59:56 +0100, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 14 Mar 2012 17:20:26 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
- Assumer qu'on fait du simili-DBdesigner et pas du DDD, dans ToPIA, on modélise une base de données relationnelles (pas trop de bidi etc...) et non un modèle métier. Donc ToPIA ne devrait pas m'imposer d'ajouter le stéréotype entity sur *toutes* les classes une par une que j'ajoute puisque de toute façon toutes les classes que j'ajoute sont des entités, y'a que ça dans mon modèle. Placer toutes ces classes dans un package entity (c'est déjà le cas, dans le pom on précise le package en question) devrait suffire.
Personnellement je suis pour la simplicité, mais je garderais tout de meme le stereotype entity sur les objets que l'on veut generer en entity. Par exemple on pourrait avoir certaine fois des interfaces entity et certaine fois non. Mais elle serait toujours dans le meme package.
Et surtout lorsque je regarde un modele et que je vois le stereotype entity je sais tout de suite le but de l'entity. (S'il n'est plus obligatoire, il va disparaitre, et la facilite de lecture avec :()
C'est assez "lourd" de devoir sur chaque entité mettre le stereotype <<entity>>. Je pense que dans un package "entity", on s'attend à avoir des entities. Par contre, tout le monde n'utilise pas un package entity. Ca m'est déjà arrivé, à Wiztivi par exemple, d'avoir des débats sur la façon d'organiser les packages : grosso modo, organisation technique ou fonctionnelles ? Dans le cas d'une orga orientée fonctionnelle, je pense qu'il devient alors nécessaire d'avoir le stéréotype sur les entities, DTOs, etc ... La solution pourrait peut etre de pouvoir appliquer le stéréotype sur un package, qui s'appliquerait à toutes les classes de ce package. Concernant les autres points, il y en a un peu beaucoup, et au fil des mails et réponses, ca va pas etre terrible pour répondre je trouve. Mais : - favorable à la dépréciation de topiaQuery (ou alors la simplifier autant que possible) - pour le passage en Runtime de TopiaException, je suis mitigé. Ne pas l'avoir en Runtime permet de rappeler qu'elle est là, et peut obliger à de la rigueur - la partie sérialisation demande peut etre de la reflexion sur la volonté/nécessité de sérialiser les entités. Si c'est pour en faire une vue précise, c'est le boulot d'un DTO pour moi. Pourquoi ne pas faire directement des tickets sur Topia, destinés à la V3, et d'y lancer les discussions ? Meme si j'estime plus reactif de répondre à un mail directement plutot que de voir un mail de commentaire, ouvrir son navigateur et la page associée, et répondre, il faut admettre quand dans les mails, c'est difficile de rebondir aisément à toutes les propositions/réactions. -- Yannick Martel
On Thu, 15 Mar 2012 09:27:33 +0100, Yannick Martel <martel@codelutin.com> wrote:
C'est assez "lourd" de devoir sur chaque entité mettre le stereotype <<entity>>. Je pense que dans un package "entity", on s'attend à avoir des entities. Par contre, tout le monde n'utilise pas un package entity. Ca m'est déjà arrivé, à Wiztivi par exemple, d'avoir des débats sur la façon d'organiser les packages : grosso modo, organisation technique ou fonctionnelles ? Dans le cas d'une orga orientée fonctionnelle, je pense qu'il devient alors nécessaire d'avoir le stéréotype sur les entities, DTOs, etc ...
La solution pourrait peut etre de pouvoir appliquer le stéréotype sur un package, qui s'appliquerait à toutes les classes de ce package.
Pourquoi pas. Je ne sais plus si EUGene le permet.
Concernant les autres points, il y en a un peu beaucoup, et au fil des mails et réponses, ca va pas etre terrible pour répondre je trouve. Mais : - favorable à la dépréciation de topiaQuery (ou alors la simplifier autant que possible) - pour le passage en Runtime de TopiaException, je suis mitigé. Ne pas l'avoir en Runtime permet de rappeler qu'elle est là, et peut obliger à de la rigueur
Ouais rigueur... Plutôt une contrainte qu'autre chose. Je sais plus ce qu'il en était du coup du rollback. Si tu commit pas dû à une erreur, qu'est ce qui se passe ?
- la partie sérialisation demande peut etre de la reflexion sur la volonté/nécessité de sérialiser les entités. Si c'est pour en faire une vue précise, c'est le boulot d'un DTO pour moi.
Pourquoi ne pas faire directement des tickets sur Topia, destinés à la V3, et d'y lancer les discussions ?
J'y ai pensé en lisant la réponse de Brendan et en faisant la mienne. Mais j'ai pas encore pris le temps de mettre ca au propre.
Le 15/03/2012 09:52, fdesbois a écrit :
Ouais rigueur... Plutôt une contrainte qu'autre chose.
+1. Ce qu'on fait partout, c'est la catcher le plus tôt possible (dès la sortie du DAO) pour la réencapsuler dans TopiaRuntimeException(e). Ça fait juste des lignes de plus et ça apporte rien. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
On Thu, 15 Mar 2012 09:52:30 +0100 fdesbois <fdesbois@codelutin.com> wrote:
Pourquoi ne pas faire directement des tickets sur Topia, destinés à la V3, et d'y lancer les discussions ?
J'y ai pensé en lisant la réponse de Brendan et en faisant la mienne. Mais j'ai pas encore pris le temps de mettre ca au propre.
Non, pas de ticket tant qu'on ne sait pas / qu'on est pas d'accord sur ce qu'on veut faire. Les listes developpeurs sont la pour ca. Il faut donc discuter sur les listes le plus possible. Potentiellement lorsqu'on est a peut pres d'accord (ou pas du tout) pourquoi pas faire une petite reunion, qui devra servir a la creation de la roadmap (et donc de tous les tickets qui vont bien). -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le 14/03/2012 17:20, Brendan Le Ny a écrit :
Ma wishlist :
Concernant la génération des topiaId : dans TopiaId, on a une méthode create implémentée comme ça : public static String create(Class clazz) { if (!clazz.isInterface()) { throw new IllegalArgumentException( "Only interface is permit to create id: " + clazz); } double random = Math.random(); while (Double.toString(random).contains("E-")) { random = Math.random(); } return clazz.getName() + '#' + System.currentTimeMillis() + '#' + random; } Or dedans y'a : - Math.random(); (du static) - System.currentTimeMillis() (re-du static aussi) Ce qui fait deux appels non-déterministes. J'aurais voulu changer ce comportement pour les tests (pour fixer la graîne du random et mettre un compteur pour currentTimeMillis par exemple) pour pas qu'il me génère des topiaIds différents à chaque cycle de test (pas pratique pour comparer des bases, écrire les tests, etc.). Et comme la méthode en question une méthode static (...étonnant !...) je peux pas utiliser de doublure ou autre... Donc, pour Topia3, j'aimerais pouvoir changer la stratégie de génération des topiaIds par configuration. On pourrait fournir deux impléms : - la première, par défaut, qui reprendrais l'actuel - une autre pour les tests (Random avec une graine ou je sais pas quoi de déterministe) Cela m'aiderait beaucoup. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
On Thu, 22 Mar 2012 17:51:01 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
Le 14/03/2012 17:20, Brendan Le Ny a écrit :
Ma wishlist :
Concernant la génération des topiaId : dans TopiaId, on a une méthode create implémentée comme ça :
public static String create(Class clazz) { if (!clazz.isInterface()) { throw new IllegalArgumentException( "Only interface is permit to create id: " + clazz); } double random = Math.random(); while (Double.toString(random).contains("E-")) { random = Math.random(); } return clazz.getName() + '#' + System.currentTimeMillis() + '#' + random; }
Or dedans y'a : - Math.random(); (du static) - System.currentTimeMillis() (re-du static aussi)
Ce qui fait deux appels non-déterministes.
J'aurais voulu changer ce comportement pour les tests (pour fixer la graîne du random et mettre un compteur pour currentTimeMillis par exemple) pour pas qu'il me génère des topiaIds différents à chaque cycle de test (pas pratique pour comparer des bases, écrire les tests, etc.).
Et comme la méthode en question une méthode static (...étonnant !...) je peux pas utiliser de doublure ou autre...
Donc, pour Topia3, j'aimerais pouvoir changer la stratégie de génération des topiaIds par configuration. On pourrait fournir deux impléms : - la première, par défaut, qui reprendrais l'actuel - une autre pour les tests (Random avec une graine ou je sais pas quoi de déterministe)
+1 c'est in-test-able. et puis un truc en static, je dis bof :( donc vive une vrai factory de-ter-mi-niste.
Cela m'aiderait beaucoup.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 2012-03-22 18:51, Brendan Le Ny a écrit :
Le 14/03/2012 17:20, Brendan Le Ny a écrit :
Ma wishlist :
Concernant la génération des topiaId : dans TopiaId, on a une méthode create implémentée comme ça :
public static String create(Class clazz) { if (!clazz.isInterface()) { throw new IllegalArgumentException( "Only interface is permit to create id: " + clazz); } double random = Math.random(); while (Double.toString(random).contains("E-")) { random = Math.random(); } return clazz.getName() + '#' + System.currentTimeMillis() + '#' + random; }
Moi, ce qui me choque le plus est le while :(, non deterministe par rapport au temps de generation de l'id. Ne serait-il pas plus judicieux de faire une suppression dans la chaine du "E-" ? (si jamais une JVM change l'impl de random et qu'il retourne toujours des chiffres avec un E-, on est tres mal :() ...
Donc, pour Topia3, j'aimerais pouvoir changer la stratégie de génération des topiaIds par configuration. On pourrait fournir deux impléms : - la première, par défaut, qui reprendrais l'actuel - une autre pour les tests (Random avec une graine ou je sais pas quoi de déterministe)
Plutot une bonne idée, mais il ne faut surtout pas devoir créer un objet a chaque génération d'un id. Donc une fois instancié le constructeur d'id doit etre reutilisé par tous (un singleton configurable ?) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Le 29/03/2012 10:00, poussin a écrit :
Moi, ce qui me choque le plus est le while :(, non deterministe par rapport au temps de generation de l'id. Ne serait-il pas plus judicieux de faire une suppression dans la chaine du "E-" ? (si jamais une JVM change l'impl de random et qu'il retourne toujours des chiffres avec un E-, on est tres mal :()
Ouais. un replace("E-", "") fera le boulot.
Plutot une bonne idée, mais il ne faut surtout pas devoir créer un objet a chaque génération d'un id. Donc une fois instancié le constructeur d'id doit etre reutilisé par tous (un singleton configurable ?)
Plutôt un objet instancié une fois pour toute par le rootContext (comme cela dépend de la config, la factory déjà écrite fait bien le job). -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com
Le Thu, 29 Mar 2012 10:23:40 +0200, Brendan Le Ny <bleny@codelutin.com> a écrit :
Le 29/03/2012 10:00, poussin a écrit :
Moi, ce qui me choque le plus est le while :(, non deterministe par rapport au temps de generation de l'id. Ne serait-il pas plus judicieux de faire une suppression dans la chaine du "E-" ? (si jamais une JVM change l'impl de random et qu'il retourne toujours des chiffres avec un E-, on est tres mal :()
Ouais. un replace("E-", "") fera le boulot.
Ou plutôt utiliser RandomStringUtils d'apache. Julien
Plutot une bonne idée, mais il ne faut surtout pas devoir créer un objet a chaque génération d'un id. Donc une fois instancié le constructeur d'id doit etre reutilisé par tous (un singleton configurable ?)
Plutôt un objet instancié une fois pour toute par le rootContext (comme cela dépend de la config, la factory déjà écrite fait bien le job).
participants (8)
-
Benjamin POUSSIN -
Brendan Le Ny -
Eric Chatellier -
fdesbois -
Julien Ruchaud -
poussin
-
Tony Chemit -
Yannick Martel