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