[nuiton-struts-2] Interceptor qui ferme une transaction topia
Suite d'une discussion sur un coin de table sous l'intiative de Brendan... puis sur reuniondev Context ------- L'utilisation de ToPIA (et donc d'hibernate) pose un problème sur l'acquisition des données). En effet, on se retrouve souvent à devoir charger à la main des propriétés ou association car on sait que l'on en a besoin dans l'ui et que les données sont en lazy. Comment faire ------------- L'idée serait d'ouvrir une transaction au début d'une action et d'utiliser un intercepteur après le rendu de l'action. Soit un contrat d'action TopiaTransactionAware + getTransaction() : TopiaContext On pose le contrat sur les actions qui utilise une transaction pour acquérir les données en base (ET on ne ferme surtout pas la transaction MAIS on la rend accessible via la méthode getTransaction()). L'intercepteur récupère la transaction sur l'action (si action bien du bon type). Si la transaction n'est pas nulle ni fermée, il la ferme. Où le faire ----------- Pour le moment c'est codé dans T3, mais il serait bien d'avoir ça disponible pour tout le monde. org.nuiton.nuiton-web:nuiton-struts2 serait le meilleur endroit. dans un package org.nuiton.web.struts2.topia . On mettrait donc une dépendance sur ToPIA mais en provided car si on utilise struts2 et Topia et bien il paraît un peu évident que ces deux dépendances soient là où il faut. En PJ le contrat a poser sur les actions + l'intercepteur qui close les transactions. A vos retours (et améliorations). Si pas d'objection, je le pousse dans nuiton-web. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Mon, 27 Jun 2011 16:45:45 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Suite d'une discussion sur un coin de table sous l'intiative de Brendan... puis sur reuniondev ... L'idée serait d'ouvrir une transaction au début d'une action et d'utiliser un intercepteur après le rendu de l'action.
Soit un contrat d'action
TopiaTransactionAware
+ getTransaction() : TopiaContext
Tres bonne idee ..
Pour le moment c'est codé dans T3, mais il serait bien d'avoir ça disponible pour tout le monde.
org.nuiton.nuiton-web:nuiton-struts2 serait le meilleur endroit.
dans un package org.nuiton.web.struts2.topia .
La je ne sais pas trop ce qui est le mieux. Je verrais bien plutot dans Topia un nouveau module avec une dépendance sur struts2. On utilise topia mais pas ce module, ca doit passer. On utilise ce module, ca veut dire qu'on fait du struts, ca passe aussi et si on en a besoin c qu'on utilise aussi topia. Si on detruit le projet Topia, y'a rien d'autre a penser (pas de class dans nuiton-web a supprimer. Donc au niveau des pom.xml ça me paraît plus simple. Mais comme j'ai dit, je ne sais pas si c'est mieux. ...
A vos retours (et améliorations).
J'aurais bien vu un autre mécanisme (mais c plus compliqué a implanter et je ne sais pas si ca fonction dans tous les cas) - lorsqu'une action est TopiaAware, il faut aussi un setTransaction - l'intercepteur dans ce cas utilise le setTransaction pour injecter un TopiaContext - l'intercepteur ferme le context si besoin a la fin Le TopiaContext est un 'proxy' sur lequel on ne peut pas faire de beginTransaction ni de commit/close et autre. Car c'est a l'intercepteur de gerer ca. Par contre ce proxy n'ouvre réellement une transaction que s'il est utilisé. Avantage: - les actions ne gere rien, on leur donne tout - la transaction n'est ouvert que s'il y a vraiment besoin - on partage le meme context ouvert tout le long de le requete HTTP Inconveniant: - il faut configurer quelque part la source, pour que l'intercepteur puisse creer les TopiaContext - on ne peut avoir qu'une source pour tous les TopiaAware - on partage le meme context ouvert tout le long de le requete HTTP (et oui ca peut aussi etre un incoveniant On peut aussi imaginer un mixte des deux solutions: Si l'utilisateur veut creer lui meme ca transaction, il ne fait rien dans le setTransaction. Et l'intercepteur quelque soit le TopiaContext qu'il recupere par le getTransaction le commit/ferme (et en cas d'exception, il le rollback/ferme) Je ne sais pas si je suis clair, ne si ca repond a la question :). Mais on peut en rediscuter de vive voix -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
participants (2)
-
Benjamin POUSSIN -
Tony Chemit