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 ;)"