Context dans les entités topia ============================== L'idée de conservé aussi bien l'entité que le contexte tout au long de leur cycle de vie. C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) L'idée serait donc de permettre les deux fonctionnements dans Topia. Solution 1 ---------- Ajout d'un tagValue pour que les entités générées hérite de "TopiaEntityContextable" (qui elle même hérite de TopiaEntity). Cette interface contient les méthodes : - getTopiaContext() - update() - delete() Potentiellement un problème sur les l'utilisation de TopiaEntity ou TopiaEntityContextable dans les DAO, etc... Solution 2 ---------- Ajouter le topiaContext dans les méthodes d'une entité qui en ont le besoin. Autre solution ? ---------------- -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
On Wed, 09 Mar 2011 17:42:44 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Context dans les entités topia ==============================
L'idée de conservé aussi bien l'entité que le contexte tout au long de leur cycle de vie.
C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) le indispensable va fait un peu sourire :) c'est vrai qu'il est indispensable de conserver la transaction dans laquelle ton entité à été chargée :)
C'est une blague ?
Autre solution ? ----------------
Supprimer tout simplement ce lien vers le TopiaContext qui en gros laisse un gros coupable avec hibernate et donc la persistance sur des objets manipulé dans des couches hautes, c'est vraiment très moyen... comme principe de séparation des couches :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 9 Mar 2011 18:08:27 +0100 chemit <chemit@codelutin.com> wrote:
On Wed, 09 Mar 2011 17:42:44 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Context dans les entités topia ==============================
L'idée de conservé aussi bien l'entité que le contexte tout au long de leur cycle de vie.
C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) le indispensable va fait un peu sourire :) c'est vrai qu'il est indispensable de conserver la transaction dans laquelle ton entité à été chargée :)
C'est une blague ?
Autre solution ? ----------------
Supprimer tout simplement ce lien vers le TopiaContext qui en gros laisse un gros coupable avec hibernate et donc la persistance sur des objets manipulé dans des couches hautes, c'est vraiment très moyen... comme principe de séparation des couches :)
un gros couplage* :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) le indispensable va fait un peu sourire :) c'est vrai qu'il est indispensable de conserver la transaction dans laquelle ton entité à été chargée :)
J'ajoute quelques précisions. Dans Isis-Fish on propose aux utilisateurs qui écrivent les scripts de faire des update() sur leurs entités pour sauver les modifications en base. Il y a d'autres cas où un appel de méthode provoque en lazy une création en base si besoin (là j'ai pas l'exemple). Du coup, l'entité trimbale son contexte, en fait Éric migre Isis vers les nouvelles versions de topia et ça casse beaucoup de choses de ne plus pouvoir accéder au contexte d'une entité. Le contexte n'est plus accessible depuis l'extérieur de l'entité (il n'y a plus les accesseurs sur l'interface TopiaEntity) par contre, le contexte est toujours présent dans l'entité mais si j'ai bien suivi, y'en a qui (Tony ? Flo ? Chaipaki ?) voudraient complètement le virer afin que les entités deviennent des POJOs qui ignorent tout des problématiques de persistance (c'est la même raison pour laquelle on préfère les fichiers de mapping aux annotations). Ça aurait l'avantage de permettre d'utiliser les entités hors de tout contexte de persistance (tests), et de les manipuler en contexte distribué (le topiaContext ne passant pas la sérialisation/marshalisation ou alors faut le mettre transient mais ça a des implications...). J'espère avoir résumé le dilemne, pour que chacun puisse se préparer au débat de jeudi soir. -- Brendan Le Ny Code Lutin
On Wed, 9 Mar 2011 18:08:27 +0100 chemit <chemit@codelutin.com> wrote:
C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) le indispensable va fait un peu sourire :) c'est vrai qu'il est indispensable de conserver la transaction dans laquelle ton entité à été chargée :)
C'est une blague ?
Non, dans les scripts de ISIS, entre autre, c'est un vrai besoin. Ces scripts sont de plus écrit et utilisé par des non-informaticiens à qui on essaie de leur dire l'objet c'est bien. Et donc qu'il fasse juste: pop.update() ou pop.getEquationReproduction() au lieu d'autre chose plus compliqué pour eux est un gros plus. Surtout si on ne le permet plus, tous les scripts de tous les utilisateurs devront être réécrit. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 9 Mar 2011 19:03:06 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 9 Mar 2011 18:08:27 +0100 chemit <chemit@codelutin.com> wrote:
C'est utile voir indispensable dans certain cas (IsisFish) mais d'autres application peuvent avoir le besoin de ne pas avoir le contexte dans leurs application (application web) le indispensable va fait un peu sourire :) c'est vrai qu'il est indispensable de conserver la transaction dans laquelle ton entité à été chargée :)
C'est une blague ?
Non, dans les scripts de ISIS, entre autre, c'est un vrai besoin. Ces scripts sont de plus écrit et utilisé par des non-informaticiens à qui on essaie de leur dire l'objet c'est bien.
On peut très bien gérer ça au niveau d'Isis-Fish et pas dans ToPIA...
Et donc qu'il fasse juste: pop.update() ou pop.getEquationReproduction()
au lieu d'autre chose plus compliqué pour eux est un gros plus. Il n'y verront que du feux ;) il suffit juste de rajouter les méthodes dans le modèle d'Isis... et de les implanter dans les Impl...
Surtout si on ne le permet plus, tous les scripts de tous les utilisateurs devront être réécrit.
Non! -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 09/03/2011 17:42, Eric Chatellier a écrit :
Solution 1 ----------
Ajout d'un tagValue pour que les entités générées hérite de "TopiaEntityContextable" (qui elle même hérite de TopiaEntity).
Cette interface contient les méthodes : - getTopiaContext() - update() - delete()
Potentiellement un problème sur les l'utilisation de TopiaEntity ou TopiaEntityContextable dans les DAO, etc...
Après discussion ce soir, nous partirons sur cette solution (1). Elle consistera donc à ajouter le support d'un tagValue qui indique que l'entité sera "Contextable". Dans le code, cela se traduira par le fait que l'entité générée implantera une interface "TopiaEntityContextable". Cette interface contiendra les méthodes suivantes : - ... getTopiaContext() - setTopiaContext(...) - update() Le TopiaContext contenu dans l'entité (encore aujourd'hui), doit être transient afin d'éviter tout comportement intrusif. Au chargement de l'entité, le TopiaContextImpl devra s'enregistrer dans l'entité : entity.setTopiaContext(this) Cette solution est choisie car elle permet d'avoir d'aller vers un consensus : chacun peut y trouver son compte (approche pure POJO vs approche objet) Le cas où l'entité est "Contextable" est un cas particulier, le cas par défaut restant l'approche POJO. Nous avons convenu que si l'implémentation de cette solution introduisait trop de complexité/changements, elle serait revue. Une feature request a été créée pour suivre l'évolution de cette demande : http://nuiton.org/issues/show/1391 Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
participants (5)
-
Arnaud Thimel -
Benjamin POUSSIN -
Brendan Le Ny -
chemit -
Eric Chatellier