- Lima-devel - mailman.cloud.codelutin.com

Tr:Re: Premiers retours Scil pour Lima
by mallon＠codelutin.com 29 Jun '12

29 Jun '12

Voici les échanges concernant des demandes portant sur Lima, et qui m'avaient été directement envoyé, au lieu de passer par lima-devel. > > Message du 26/06/12 08:31 > > De : "Philippe Pary" > > > A : "matthieu.allon" > > Copie à : "lutins codelutin com" , "Cédric Houbart" > > Objet : Re: Premiers retours Scil pour Lima > > > > Salut, > > > > Le 25/06/2012 16:51, matthieu.allon a écrit : > > > J'ai déjà créé deux nouveaux tickets ('http://chorem.org/projects/lima/issues' <http://chorem.org/projects/lima/issues%27> : tickets 637[Création de raccourcis claviers] et 638[Optimiser l'exécution de Lima]) : le premier concerne la création de raccourcis claviers et l'amélioration de ceux déjà existants; tandis que le second porte sur l'optimisation générale de Lima. > > > > Mais c'est super ! > > > > Plus sérieusement, je n'ai pas pris le temps de lire les tickets en > > effet. Mea culpa > > > > > J'aurai cependant quelques questions : > > > - quel est le nom du format que vous aimeriez avoir en import / export, au lieu de ceux proposés actuellement (EBP / CSV) ? > > > > 2 formats : celui d'OpenERP (pour sortir nos comptas de ce logiciel) et > > celui du crédit coopératif > > > > Tu as en document joints deux exemples. Ce sont nos mouvements bancaires > > en août 2011 > > > > > - en ce qui concerne la documentation du lettrage, simplement pour savoir si j'ai bien compris : ce que vous souhaitez, c'est avoir davantage d'informations détaillant son fonctionnement, et ce au sein de l'écran correspondant ? > > > > C'est l'idée, encore que je peux chercher à tâtons et rédiger la doc > > moi-même > > > > > De plus, êtes-vous d'accord pour que je fasse suivre votre mail à l'adresse suivante : lima-devel(a)codelutin.com (Adresse pour les messages concernant le développement de Lima)? > > > Je vous invite aussi à vous inscrire à la liste suivante : 'list.chorem.org/cgi-bin/mailman/listinfo/lima-devel' > > > > Oui bien sur pour le mail. Je m'inscris à la liste > > > > Philippe > > <http://www.laposte.net>

2 1

Création des rapports sur périodes bloquées
by Eric Chatellier 05 Jun '12

05 Jun '12

Bonjour, Dans les interfaces de rapports de lima, il est possible de générer les rapport et les afficher dans l'ui, et de le generer en PDF. Seulement, la generation PDF est impossible tant que la periodes n'est pas bloqué/cloturée. C'est peut-être normal, mais pourquoi ? Deuxiemement, les interfaces de rapport ne s'affiche actuellement qu'avec les periodes non bloquées/cloturées; il est donc impossible de generer les rapports PDF sur les periodes cloturées. Il y a une incohérence... -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

Re: [Lima-devel] [Lima-commits] r3425 - in trunk/lima-swing/src/main: java/org/chorem/lima/enums java/org/chorem/lima/ui/accountsreports java/org/chorem/lima/ui/celleditor java/org/chorem/lima/ui/combobox java/org/chorem/lima/ui/common java/org/chorem/lima/ui/financialtransactionsearch resources/i18n
by Arnaud Thimel 24 May '12

24 May '12

Autant pour le private -> protected, je suis d'accord, par contre pour la disparition du final, je me demande pourquoi ? Au contraire, je trouve que ça a plus de sens... Arnaud Le 16/05/2012 14:41, echatellier(a)users.chorem.org a écrit : > public enum ComboBoxDatesEnum { > > FISCAL_PERIOD(_("lima.enum.comboboxperiod.fiscalperiod")), > FINANCIAL_PERIOD(_("lima.enum.comboboxperiod.financialperiod")), > PERIOD(_("lima.enum.comboboxperiod.period")); > > - private final String description; > + protected String description; > > ComboBoxDatesEnum(String description) { > this.description = description;

3 2

Recherche par interval de dates (au lieu d'entités)
by Eric Chatellier 10 May '12

10 May '12

Bonjour, Je refactor beaucoup de code sur les recherches via les dao pour retrouver des choses invalides, non close, non balancées etc... Je les fait fonctionner, c'est parfait. Par contre, je viens de m'apercevoir d'une chose que je ne comprend pas sur les recherches, elles sont faites par intervalles de date et non par association d'entités (exercice, périodes fiscal notamment). Par exemple, avant de close un exercice, on recherche les transactions non équilibrées de l'exercice. Cependant, au lieu de faire une requête JPA sur les transaction qui porte sur l'exercice, on recherche les transactions dont la date de la transaction est entre la date de début et la date de fin de l'exercice. Donc y a-t-il une raison à ce que les recherches soit fait de la sorte, ou cela n'a aucune importance ? -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 3

Architecture d'utilisation des services de Lima
by Eric Chatellier 09 May '12

09 May '12

Bonjour, J'ai essayé de synthétiser l'architecture de lima telle qu'il est à l'heure actuelle. Donc nous avons: * les handler qui s'enregistrent sur les proxy monitorable et qui sont notifiés des modifications suite à l'appel d'une méthode sur un service. Cela reste interne à un client, et cela permet de mettre à jour facilement les interfaces qui manipule les mêmes données. * L'interceptor qui initie une topia context et qui l'enregistre dans la transaction courante (enlist). Même si ça fonctionne, je ne suis pas fan du fonctionnement: - thread local, avec accès statiques - j'ai l'impression que c'est plus un hack qu'autre chose. - la xaresource implémente 2 méthodes sur 8 À cogiter pour une prochaine discussion... -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 2

Re: [Lima-devel] [Lima-commits] r3391 - trunk/lima-business/src/test/java/org/chorem/lima/business
by Tony Chemit 25 Apr '12

25 Apr '12

On Wed, 25 Apr 2012 10:28:20 +0200 (CEST) echatellier(a)users.chorem.org wrote: > /** > @@ -47,7 +46,7 @@ > public class AccountServiceImplTest extends AbstractLimaTest { > > @Before > - public void initTest() throws LimaException, ParseException { > + public void initTest() throws Exception { > initTestDatabase(); > } > Je t'aurais bien proposé d'utiliser plutôt une Rule avec un object qui contient les services, la transaction et autres plutôt qu'une architecture en héritage, mais j'ai un peu peur de ta réponse (et certes oui on en a parlé parlé en réuniondev, ...). Ca me parait une meilleure approche que des tests avec héritage. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

Re: [Lima-devel] [Lima-commits] r3385 - in trunk: lima-business/src/main/java/org/chorem/lima/business/ejb lima-business/src/test/java/org/chorem/lima/business lima-business-api/src/main/java/org/chorem/lima/business/api
by Tony Chemit 24 Apr '12

24 Apr '12

On Tue, 24 Apr 2012 16:19:59 +0200 (CEST) echatellier(a)users.chorem.org wrote: > Author: echatellier > Date: 2012-04-24 16:19:58 +0200 (Tue, 24 Apr 2012) > New Revision: 3385 > > Url: http://chorem.org/repositories/revision/lima/3385 > > Log: > Fix import entry book from ebp test t'as pas envie de tester nuiton-csv ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

2 2

Re: [Lima-devel] Gestion des transactions dans les EJB
by Eric Chatellier 17 Apr '12

17 Apr '12

Le 11/04/2012 18:28, Eric Chatellier a écrit : > > Après un nouvel essai, j'ai un debut d'implémentation qui marche. > > L'interceptor ouvre une transaction (topiacontext) et l'enregistre > dans la transaction du conteneur. > Il enregistre le topiacontext egalement dans une map de données > de InvocationContext de l'intercepteur. Finalement, cela ne fonctionne pas. La map de l'InvocationContext n'est disponible que pour l'ejb qui est la cible de l'intercepteur, pas pour les appels suivants :( Je suis donc revenu au thread local. C'est mieux que ce qu'il y a actuellement, mais c'est pas top. > > L'EJB service utilise un DAOHelper (qui est un ejb aussi) qui > a accès à l'EJBContext qui contient la même map > que celle de l'intercepteur avec le context topia qu'il > peut utiliser pour instancier les dao. Le DAOHelper n'est plus un EJB et les règles (AccountingRule) non plus. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

MVC et service pour les interfaces
by Eric Chatellier 16 Apr '12

16 Apr '12

Bonjour, Après avoir refactorés quelques interfaces et services, voici les modifications qui sont en cours sur les interfaces et comment elles exploitent les services. Version 0.5 ----------- En version 0.5, voici comment cela fonctionnait: - le contrôleur instançiait le modèle et la vue - le modèle était le seul a connaître les services - le modèle récupérait les données (parfois en plusieurs appel : pour les arbres par exemple) - lors d'une modification, le contrôleur appelait une méthode du modèle qui appelait le service et qui mettait ensuite à jour la vue. - lors d'une mise à jour du modèle, les données de cache était trop souvent "invalidées" et récupérée entièrement depuis le service :( On en avait quand même convenu que le fait que le modèle utilise le service était une bonne solution. Cependant, j'ai changer cette façon de faire :( Version 0.6 ----------- En version 0.6, voilà comment cela a été modifié: - le contrôleur récupère les données, de préférences en un unique appel au webservice - il instancie ensuite le modèle avec ces données qui lui serviront de cache, et la vue avec ce modèle - le controleur gere seul le service. Lors d'une modification le contrôleur appelle le service et si l'appel du WS s'est bien passé, il notifie le modèle (qui met à jour son cache) qui notifie ensuite la vue. Les données ne sont plus entièrement rechargée - les listeners de service sont maintenant les contrôleurs et non les modèles comme auparavant. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

Modifications à venir sur le modèle
by Eric Chatellier 12 Apr '12

12 Apr '12

Bonjour, Voici l'état actuel du modèle de données de lima (v 0.5). Voici la liste des modifications qui vont lui être apportés: - suppression de "Record" : aucune idée de l'utilité - suppression de la boucle "masterAccount" sur account - suppression de la boucle "generalLedger" sur account * (la hiérarchie est basé sur les accountNumber) - suppression de la classe "letter" (remplacée par un attribut letter:String dans Entry) - suppression de l'attribut "amount" de VatStatement - réduction de visibilités entre: * Entry et FinancialTransaction * FinancialTransaction et FinancialPeriod Les services vont également être modifiés en conséquence pour rapatrier toutes les données d'un écran via un seul appel de webservice. Les "bean" générés à partir du modèle vont en partit être supprimés (au moins ceux qui ne servent qu'à l'import EBP). Cordialement, -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 2