Nuiton-web-devel

Download

nuiton-web-devel@list.nuiton.org

June 2011

5 participants
2 discussions

[nuiton-struts-2] Interceptor qui ferme une transaction topia
by Tony Chemit June 28, 2011

June 28, 2011

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(a)codelutin.com http://www.codelutin.com

2 1

Rejet des tickets #565 et #566 ?
by Brendan Le Ny June 20, 2011

June 20, 2011

Je propose le rejet de ces tickets : http://www.nuiton.org/issues/565 http://www.nuiton.org/issues/566 Le #565 propose de packager des icônes, or je ne vois pas pourquoi nous prendrions cette initiative au lieu de réutiliser ce qui existe déjà : http://search.maven.org/#search|ga|1|g%3A%22org.freedesktop.tango%22 http://search.maven.org/#search|ga|1|g%3A%22com.famfamfam%22%20a%3A%22silk%… Le #565 propose de factoriser des CSS commun, or le cas ne s'est jamais présenté et je vois mal comment on pourrait avoir des CSS communes. S'il s'agit de factoriser des choses entre les projets chorem (but initial du ticket), ça aurait plutôt sa place dans le projet en question, non ? -- Brendan Le Ny <bleny(a)codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com

3 2