Draft roadmap ToPIA 3
Bonjour, Premier draft pour la roadmap ToPIA 3, ça reprend et synthétise la précédente discussion : Pré-travail en vue d'un changement de version majeure ===================================================== - Déprécier immédiatement et supprimer dans ToPIA 3 tout le code qu'on ne veut plus dans ToPIA - un paquet util qui pourrait redescendre dans ObServe - ServiceTransformer - TopiaQuery - Supprimer tout le code déprécié Migration vers JPA ================== - Réécrire TopiaContextImpl en utilisant l'API JPA (EntityManager...) - Vérifier/Corriger les mappings générés - Utiliser OpenJPA comme implémentation de JPA par défaut et permettre d'utiliser Hibernate 4 Améliorations diverses ====================== - Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer) - Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish - Une approche « bonne pratique par défaut » pour ne pas avoir de boilerplate tagValues (0 config = config propre). Exemple : model.tagvalue.constantPrefix=PROPERTY_ model.tagValue.doNotGenerateBooleanGetMethods=true - Forcer l'encapsulation du code spécifique JPA : rendre DAO#createQuery() et findByQuery, countByQuery protected. A contrario, dans le DAO, laisser l'accès à l'intégralité de la sous-couche pour usage exceptionnel - TopiaException extends RuntimeException - Permettre de déclarer tout un package du modèle (stéréotype) pour que toutes les classes à l'intérieur soient considérées comme entités (sans besoin de mettre le stéréotype sur chaque classe) - Introduire un contrat TopiaIdFactory, Un TopiaRootContext est lié à une instance de cette factory (qu'on peut changer par configuration), ainsi que trois implémentations - L'actuelle, corrigée en utilisant RandomStringUtils (pas de boucle), implémentation par défaut - Une déterministe (Random avec graine et/ou compteur) - Une qui utilise l'implémentation fournie par l'implémentation JPA (par Hibernate ou autre) Autre chose ? -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Pour la réalisation, je propose que Tony et moi nous y attaquions sur la semaine prochaine. Pour ne pas partir seuls, j'ai programmé une réunion de lancement demain à 15h30 dont l'ordre du jour est grosso modo le présent draft de roadmap (merci Brendan). Kevin, Julien, je suis conscient que vous auriez aimé y participer, je vous invite donc à vous exprimer ici avant l'heure de début. Arnaud Le 03/05/2012 15:48, Brendan Le Ny a écrit :
Bonjour,
Premier draft pour la roadmap ToPIA 3, ça reprend et synthétise la précédente discussion :
Pré-travail en vue d'un changement de version majeure =====================================================
- Déprécier immédiatement et supprimer dans ToPIA 3 tout le code qu'on ne veut plus dans ToPIA
- un paquet util qui pourrait redescendre dans ObServe
- ServiceTransformer
- TopiaQuery
- Supprimer tout le code déprécié
Migration vers JPA ==================
- Réécrire TopiaContextImpl en utilisant l'API JPA (EntityManager...)
- Vérifier/Corriger les mappings générés
- Utiliser OpenJPA comme implémentation de JPA par défaut et permettre d'utiliser Hibernate 4
Améliorations diverses ======================
- Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer)
- Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish
- Une approche « bonne pratique par défaut » pour ne pas avoir de boilerplate tagValues (0 config = config propre). Exemple :
model.tagvalue.constantPrefix=PROPERTY_ model.tagValue.doNotGenerateBooleanGetMethods=true
- Forcer l'encapsulation du code spécifique JPA : rendre DAO#createQuery() et findByQuery, countByQuery protected. A contrario, dans le DAO, laisser l'accès à l'intégralité de la sous-couche pour usage exceptionnel
- TopiaException extends RuntimeException
- Permettre de déclarer tout un package du modèle (stéréotype) pour que toutes les classes à l'intérieur soient considérées comme entités (sans besoin de mettre le stéréotype sur chaque classe)
- Introduire un contrat TopiaIdFactory, Un TopiaRootContext est lié à une instance de cette factory (qu'on peut changer par configuration), ainsi que trois implémentations
- L'actuelle, corrigée en utilisant RandomStringUtils (pas de boucle), implémentation par défaut
- Une déterministe (Random avec graine et/ou compteur)
- Une qui utilise l'implémentation fournie par l'implémentation JPA (par Hibernate ou autre)
Autre chose ?
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
Oui : Je me souviens plus que l'on avait décider d'utiliser Open JPA. Après au niveau fonctionnalité au peut rajouter le point que Flo avait relevé pour la gestion des transactions par annotation. On avait aussi discuté de l'écriture du modèle texte. Julien Le Thu, 03 May 2012 17:19:17 +0200, Arnaud Thimel <thimel@codelutin.com> a écrit :
Pour la réalisation, je propose que Tony et moi nous y attaquions sur la semaine prochaine.
Pour ne pas partir seuls, j'ai programmé une réunion de lancement demain à 15h30 dont l'ordre du jour est grosso modo le présent draft de roadmap (merci Brendan).
Kevin, Julien, je suis conscient que vous auriez aimé y participer, je vous invite donc à vous exprimer ici avant l'heure de début.
Arnaud
Le 03/05/2012 15:48, Brendan Le Ny a écrit :
Bonjour,
Premier draft pour la roadmap ToPIA 3, ça reprend et synthétise la précédente discussion :
Pré-travail en vue d'un changement de version majeure =====================================================
- Déprécier immédiatement et supprimer dans ToPIA 3 tout le code qu'on ne veut plus dans ToPIA
- un paquet util qui pourrait redescendre dans ObServe
- ServiceTransformer
- TopiaQuery
- Supprimer tout le code déprécié
Migration vers JPA ==================
- Réécrire TopiaContextImpl en utilisant l'API JPA (EntityManager...)
- Vérifier/Corriger les mappings générés
- Utiliser OpenJPA comme implémentation de JPA par défaut et permettre d'utiliser Hibernate 4
Améliorations diverses ======================
- Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer)
- Avoir des entités POJO (sans topiaContext dedans) par défaut et avoir un mode pour Isis-Fish
- Une approche « bonne pratique par défaut » pour ne pas avoir de boilerplate tagValues (0 config = config propre). Exemple :
model.tagvalue.constantPrefix=PROPERTY_ model.tagValue.doNotGenerateBooleanGetMethods=true
- Forcer l'encapsulation du code spécifique JPA : rendre DAO#createQuery() et findByQuery, countByQuery protected. A contrario, dans le DAO, laisser l'accès à l'intégralité de la sous-couche pour usage exceptionnel
- TopiaException extends RuntimeException
- Permettre de déclarer tout un package du modèle (stéréotype) pour que toutes les classes à l'intérieur soient considérées comme entités (sans besoin de mettre le stéréotype sur chaque classe)
- Introduire un contrat TopiaIdFactory, Un TopiaRootContext est lié à une instance de cette factory (qu'on peut changer par configuration), ainsi que trois implémentations
- L'actuelle, corrigée en utilisant RandomStringUtils (pas de boucle), implémentation par défaut
- Une déterministe (Random avec graine et/ou compteur)
- Une qui utilise l'implémentation fournie par l'implémentation JPA (par Hibernate ou autre)
Autre chose ?
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
Le 04/05/2012 10:54, Julien Ruchaud a écrit :
Je me souviens plus que l'on avait décider d'utiliser Open JPA.
C'est pas décidé, mais y'en a qui sont pour faire la transition et personne contre. De toute façon, théoriquement, ToPIA supporte les deux.
Après au niveau fonctionnalité au peut rajouter le point que Flo avait relevé pour la gestion des transactions par annotation.
Oups. J'ai oublié un truc en relisant la discussion ? C'est vrai qu'il y a le WaoDAOHelper instantiable mais il me semble pas qu'on ait parlé d'annot' @Transactional. Pour moi, c'est hors topia, c'est à l'architecture de l'appli qu'on décide de la façon de gérer la transac selon l'infra (appli web, EJB ?).
On avait aussi discuté de l'écriture du modèle texte.
Pour moi c'est une possibilité d'avenir, mais ce n'est clairement pas à l'ordre du jour dans la roadmap actuelle. On peut déjà faire tout ce qui est listé, la modélisation textuelle devra se greffer sur le projet bien plus tard àmha. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 03/05/2012 15:48, Brendan Le Ny a écrit :
Migration vers JPA ==================
- Utiliser OpenJPA comme implémentation de JPA par défaut et permettre d'utiliser Hibernate 4
Pour moi, il n'y a pas "d'implémentation par défaut". Topia doit être codé sur l'API JPA et à l'utilisateur de fournir le moteur. Par contre, il serait intéressant que les test passe à la fois sur openjpa et sur hibernate.
Améliorations diverses ======================
- Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer)
Pour info, il est tout a fait possible à l'heure actuelle de ne pas modéliser les DAO dans le modèle et d'avoir des DAO custom. Donc ne rien changer et ne pas avoir de "transformer pour ca". L'héritage des classes DAO est étrange: TopiaDAOImpl <-- XXXDAOAbstract <-- XXXDAO <--- XXXDAOImpl Il n'y a pas d'interface, et 2 classes d'impl. Je pense (sans en être sûr) que cela avait été réfléchit comme ca au départ, et il n'y a qu'à redéfinir XXXDAO et c'est tout. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 04/05/2012 10:24, Eric Chatellier a écrit :
Améliorations diverses ======================
- Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer) Pour info, il est tout a fait possible à l'heure actuelle de ne pas modéliser les DAO dans le modèle et d'avoir des DAO custom. Donc ne rien changer et ne pas avoir de "transformer pour ca".
L'héritage des classes DAO est étrange: TopiaDAOImpl <-- XXXDAOAbstract <-- XXXDAO <--- XXXDAOImpl Aux temps pour moi, c'est même:
TopiaDAOImpl <-- XXXDAOAbstract <--- XXXDAOImpl <-- XXXDAO -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 04/05/2012 10:34, Eric Chatellier a écrit :
Aux temps pour moi, c'est même:
TopiaDAOImpl <-- XXXDAOAbstract <--- XXXDAOImpl <-- XXXDAO Et donc je me rend compte, que dans Lima j'ai redéfini le XXXDAO au lieu du XXXDAOImpl :-(
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Fri, 04 May 2012 10:24:24 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 03/05/2012 15:48, Brendan Le Ny a écrit :
Migration vers JPA ==================
- Utiliser OpenJPA comme implémentation de JPA par défaut et permettre d'utiliser Hibernate 4
Pour moi, il n'y a pas "d'implémentation par défaut". Topia doit être codé sur l'API JPA et à l'utilisateur de fournir le moteur.
Il ne faut pas oublier qu'à l'heure actuelle ToPIA est exclusivement basé sur Hibernate. La on voudrait tout passer sur JPA, donc supprimer les fichiers de mapping hibernate.
Par contre, il serait intéressant que les test passe à la fois sur openjpa et sur hibernate.
Pourquoi faire ? Dans ToPIA on veut teser ToPIA ou les frameworks du dessous ? (petit troll sur les tests...)
Améliorations diverses ======================
- Arrêter de modéliser les DAO (ne garder que le nécessaire dans le transformer)
Pour info, il est tout a fait possible à l'heure actuelle de ne pas modéliser les DAO dans le modèle et d'avoir des DAO custom. Donc ne rien changer et ne pas avoir de "transformer pour ca".
L'héritage des classes DAO est étrange: TopiaDAOImpl <-- XXXDAOAbstract <-- XXXDAO <--- XXXDAOImpl
Il n'y a pas d'interface, et 2 classes d'impl.
Je pense (sans en être sûr) que cela avait été réfléchit comme ca au départ, et il n'y a qu'à redéfinir XXXDAO et c'est tout.
Ouai je me demande bien le but, pour l'héritage ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 04/05/2012 10:39, Tony Chemit a écrit :
Pourquoi faire ?
Dans ToPIA on veut teser ToPIA ou les frameworks du dessous ? (petit troll sur les tests...)
L'essentiel des tests doivent bien sûr tester ToPIA. En même temps, ToPIA repose tellement sur JPA qu'un petit test d'intégration me semble pas du luxe. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
Le 04/05/2012 10:24, Eric Chatellier a écrit :
Pour info, il est tout a fait possible à l'heure actuelle de ne pas modéliser les DAO dans le modèle et d'avoir des DAO custom. Donc ne rien changer et ne pas avoir de "transformer pour ca".
Il te faut quand même un transformer pour générer les DAO, c'est juste la gestion des méthodes spécifiques précisées qui n'est pas nécessaire, mais faut quand même garder le transformer.
L'héritage des classes DAO est étrange: TopiaDAOImpl<-- XXXDAOAbstract<-- XXXDAO<--- XXXDAOImpl
C'est faux. C'est TopiaDAOImpl <-- XXXDAOAbstract <-- XXXDAOImpl <-- XXXDAO -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
participants (5)
-
Arnaud Thimel -
Brendan Le Ny -
Eric Chatellier -
Julien Ruchaud -
Tony Chemit