February 2013 - Cantharella-devel - mailman.cloud.codelutin.com

Re: [Cantharella-devel] Mise à jour wicket 6.5.0
by Adrien Cheype Feb. 15, 2013

Feb. 15, 2013

Le 15/02/2013 03:42, Eric Chatellier a écrit : > Bon, en fait j'ai insisté et j'ai mis à jour wicket en 6.5 :-) > > Le gros changement est que pour les tables, la propriété > de tri n'est plus une chaine, mais un type générique <S> > > Il y a des choses intéressantes dans comme le support > de l'export des tableaux: > https://issues.apache.org/jira/browse/WICKET-4802 > > J'aurais dû le faire plus tôt :-( C'est une bonne nouvelle ! J'aimerais bien à terme faire un peu de publicité pour Cantharella auprès de la mailing list de Wicket. Un projet comme Cantharella qui donne un exemple d'utilisation du framework avec Spring/Hibernate pourrait certainement intéressé leur communauté... En ce qui concerne la migration, il reste juste encore quelques depreciated qu'on voit notamment en effectuant un build. Cela ne doit pas être grand chose. -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Re: [Cantharella-devel] Stockage des documents
by Sylvain PETEK Feb. 15, 2013

Feb. 15, 2013

Bonjour, Merci pour cette mise à jour. Au niveau du formulaire "gestion d'un document": - Au niveau de "Editeur" et de "Contrainte légale" on devrait avoir une liste suggestive des données précédemment saisie pour ce champ. - A la hauteur de la liste déroulante des types, il faudrait remplacer "Nom" par "Type de document" - Au niveau du bouton pour joindre le document, il faudrait supprimer "Nom" ou le remplacer par "fichier" Voilà voilà pour le moment, Bonne journée, Sylvain -----Message d'origine----- De : cantharella-devel-bounces(a)list.forge.codelutin.com [mailto:cantharella-devel-bounces@list.forge.codelutin.com] De la part de Eric Chatellier Envoyé : mercredi 13 février 2013 06:23 À : cantharella-devel(a)list.forge.codelutin.com Objet : [Cantharella-devel] Stockage des documents Bonjour, Je viens de mettre à jour le serveur avec le début des interfaces de gestion et visualisation des documents (seulement pour les molécules avant de le généraliser). Concernant le stockage des fichiers attachés, peut-on les stocker directement dans la base de données ? Cela simplifierais la gestion et la cohérence pour l'ajout et la suppression. Techniquement, le modèle de données serait typé en byte[] voire en InputStream (voire si vraiment ca ne fonctionne pas en java.sql.Blob) et annoté en @Lob -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com _______________________________________________ Cantharella-devel mailing list Cantharella-devel(a)list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel

1 0

Mise à jour wicket 6.5.0
by Eric Chatellier Feb. 14, 2013

Feb. 14, 2013

Bonjour, Juste à titre d'information j'ai tenté une mise à jour vers les versions 6.0 et 6.5 de wicket. Les modifications étant trop importantes, je n'ai pas insisté. Il faudra peut-être la prévoir plus tard. Cordialement, Eric Chatellier. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

1 1

Re: [Cantharella-devel] Réorganisation des dépendances MAVEN
by Adrien Cheype Feb. 14, 2013

Feb. 14, 2013

Le 13/02/2013 23:03, Benjamin POUSSIN a écrit : > On Wed, 13 Feb 2013 17:54:29 +1100 > Adrien Cheype <adrien.cheype(a)ird.fr> wrote: > >> Super sinon pour la configuration. J'imagine que si je met un fichier >> "cantharella.conf" dans mon home, il prendra le dessus sur les 3 >> fichiers cantharella.conf définis initialement pour chaque module ? > Un essai de documentation a été mis en place pour expliquer où mettre > les fichiers de configuration, il ne faut pas hésiter à refaire/modifier/effacer. > > http://maven-site.forge.codelutin.com/cantharella/configuration.html > Merci, la documentation est très claire. J'ai effectué quelques tests de mon côté et cela semble bien fonctionner. Sur le serveur de prod., nous devrons également changer le fichier de configuration de log4j. Auriez-vous également une solution à proposer pour qu'on puisse effectuer ce paramétrage sans modifier l'archive war ? Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Stockage des documents
by Eric Chatellier Feb. 13, 2013

Feb. 13, 2013

Bonjour, Je viens de mettre à jour le serveur avec le début des interfaces de gestion et visualisation des documents (seulement pour les molécules avant de le généraliser). Concernant le stockage des fichiers attachés, peut-on les stocker directement dans la base de données ? Cela simplifierais la gestion et la cohérence pour l'ajout et la suppression. Techniquement, le modèle de données serait typé en byte[] voire en InputStream (voire si vraiment ca ne fonctionne pas en java.sql.Blob) et annoté en @Lob -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

1 0

Re: [Cantharella-devel] Réorganisation des dépendances MAVEN
by Adrien Cheype Feb. 13, 2013

Feb. 13, 2013

Ce n'est pas bien grave, j'ai mergé de mon côté les différentes modifications. Je vous commiterai le tout une fois que j'aurais fais le ménage dans les pom.xml. Super sinon pour la configuration. J'imagine que si je met un fichier "cantharella.conf" dans mon home, il prendra le dessus sur les 3 fichiers cantharella.conf définis initialement pour chaque module ? Je suis en train de regarder pour remplacer les nouvelles injections que vous avez effectuées dans le fichier XML par des annotations dans les fichiers de configuration Java. Le but étant de revenir vers du full annotation comme nous avions avant de passer à Spring 3 (qui avaient à l'époque perdu pas mal de possibilité en annotation, ceci a certainement évolué depuis). Adrien Le 12/02/2013 22:50, Benjamin POUSSIN a écrit : > On Tue, 12 Feb 2013 20:17:04 +1100 > Adrien Cheype <adrien.cheype(a)ird.fr> wrote: > >> J'ai commencé à restructurer les pom.xml en enlevant les profils. > Houla, j'étais justement en train de faire la même chose pour intégrer > la mise en place du fichier de configuration :(. > > J'étais en train de validé le travail fait (vérifier que ça > fonctionnait) avant de tout commiter. Je pensais commiter cet après > midi. > > Je ne vois pas pour l'instant de commit sur les pom.xml > Donc j'espère que lorsque je vais commiter cela ne posera de problème à > personne :( > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Re: [Cantharella-devel] Tableau wicket de la liste des molécules
by Adrien Cheype Feb. 13, 2013

Feb. 13, 2013

Bonjour, > Personnellement, je préfère la première car cela représente un > cas particulier d'affichage et cela permet de ne pas polluer > le modèle de données avec des problématiques d'affichage. Je suis d'accord, il serait en effet dommage de devoir modifier le modèle pour régler un problème de page web. Je ne vois pas par contre comment régler le problème d'itération sur List<AbstractModel> sans rajouter une interface commune. Mais c'est un moindre mal si cela nous permet de garder le modèle intact. > Par contre, je pense qu'elle ne convient pas exactement au > problème, car l'objet à manipuler devrait être un javaBean > car wicket affiche un propriété d'un bean, par exemple: > columns.add(new PropertyColumn<Molecule>(new > Model<String>(getString("Molecule.nomCommun")), > "nomCommun", "nomCommun")); > il va appeler la méthode getNomCommun() de la ligne courant. Il suffit de ne pas utiliser PropertyColumn et de créer à la place une classe interne anonyme qui hérite d'AbstractColumn<Molecule>. Exemple : column.add(new AbstractColumn<Molecule>(new Model<String>(getString("Molecule.nomCommun"))) { @Override public void populateItem(Item<ICellPopulator<Molecule>> item, String componentId, IModel<Molecule> rowModel) { item.add(new Label(componentId, RowMoleculeFinder.getNomCommun(rowModel.getObject())); } }); ou mieux encore : garder PropertyColumn<Molecule> mais utiliser la stratégie de surchage non pour trouver la valeur mais le nom de propriété. Ainsi pour continuer avec l'exemple du nom commun, la méthode RowMoleculeFinder.getNomCommunProperty(Molecule molecule) rendrait "nomCommun", tandis que RowMoleculeFinder.getNomCommunProperty(MoleculeProvenance moleculeProvenance) rendrait "molecule.nomCommun". Par ailleurs, je viens de remarquer que vous étendez systématiquement dans cette page une PropertyColumn (ou ces dérivés tel DecimalPropertyColum, ...) au lieu d'AbstractColumn (les propriétés déclarées dans le constructeurs n'étant ensuite pas utilisées). > Nous allons également essayer de réfléchir à une solution. > > > > Pour revenir a la même problématique pour les Produit, les molécules > portant sur les produits, cela devient également lorsque l'on doit afficher > le nom du programme sachant que: > * la ligne est soit une Molecule, soit une MoleculeProvenance > * le produit est soit une Fraction, soit un extrait > > Par exemple, pour la référence du lot, je dois faire deux cas encore > suivant le type de produit: > * "produit.purification.lotSource.ref" > * "produit.extraction.lot.ref" Dans ce cas particulier où on doit afficher " - " (valeur nulle) quand c'est une Molecule, et la valeur de deux propriétés différentes (suivant si c'est une Fraction ou un Extrait) quand c'est une MoleculeProvenance, je conseillerais également d'utiliser la solution de surcharge pour obtenir la bonne propriété. Les méthodes aurait alors deux arguments comme par exemple : RowMoleculeFinder.getProgrammeProperty(Molecule, Fraction) (au total 4 surcharges pour chacun des cas). Puisque Wicket est écrit intelligemment, cette solution devrait marcher même pour les deux surcharges avec Molecule. En effet, dans le PropertyResolver de Wicket nous avons : > /** > * Looks up the value from the object with the given expression. > If the expression, the object > * itself or one property evaluates to null then a null will be > returned. > * > * @param expression > * The expression string with the property to be lookup. > * @param object > * The object which is evaluated. > * @return The value that is evaluated. Null something in the > expression evaluated to null. > */ > public final static Object getValue(final String expression, final > Object object) Ainsi les deux surcharges utilisant Molecule peuvent rendre la valeur null et le résultat de l'évaluation du PropertyColumn rendra bien null. Il suffit alors de rajouter le behavior RemplaceEmptyLabelBehavior sur le cellItem du populateItem pour obtenir la chaîne désirée pour ces cas. Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

3 4

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Sylvain PETEK Feb. 13, 2013

Feb. 13, 2013

Bonjour, Merci pour le CR de la réunion. Juste un petit commentaire concernant: >Molécules >* en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule. Pour plus d'homogénéité, il a été proposé que le lien pour télécharger le fichier mol de la molécule figure plutôt avec les autres documents à télécharger. Bonne journée, Sylvain -----Message d'origine----- De : cantharella-devel-bounces(a)list.forge.codelutin.com [mailto:cantharella-devel-bounces@list.forge.codelutin.com] De la part de Eric Chatellier Envoyé : mardi 29 janvier 2013 00:06 À : cantharella-devel(a)list.forge.codelutin.com Objet : [Cantharella-devel] CR Réunion Cantharella du 29/01/2013 CR Réunion Cantharella du 29/01/2013 ==================================== Molécules --------- * Liste des molécules: les molécules doivent être dupliqué pour chaque provenance * édition des molécules: aligner sur les champs, manque la recherche de molécule, et la calculatrice * champs obligatoire qui ne sont pas requis: nom commun, famille chimique, nom iupac. * Identifiée par, mettre en plus les organismes lié aux personnes * problème le message "... car vous n'avez pas les droits nécessaires" est toujours affiché (voir exemple dans test biologique) (a regarder la meilleurs solution comment faire) * Les champs campagne et espèce ne fonctionne pas encore * Les droits utilisateurs ne sont pas encore complètement géré * double sur la page d'affichage de la molécule (même taille que l’édition) * si on clique sur l'image, il faut pouvoir la sauver. (ça marche sur firefox mais pas sous webkit, donc prévoir que si on clique sur l'image, on ouvre une nouvelle fenêtre avec une vraie image * changer "est-ce une nouvelle molécule ?" en "nouvelle molécule ?" * en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule. * Molécule provenance: On peut rattacher plusieurs fraction et non pas une seule, a priori seul le MCD est faux. Dans le code ça doit être possible slf4j contre commons-logging ---------------------------- * Log: pas de plus value à migrer, mais il faut tout de même corrige le problème actuel. * Une migration slf4j avec une impl log4j est tout de même demandée. Configuration et suppression des profiles ----------------------------------------- * On passe par ApplicationConfig, qui peut changer de fichier de config sur la ligne de commande Gestion des dépenandances maven ------------------------------- * double déclaration des dépendances pom.xml parent et enfant * c'est une convention maven * CodeLutin se renseigne sur la vrai plus value à faire cela et renvoi un mail sur la liste Convention de codage -------------------- * il y a un mélange historique de commentaire anglais/francais, mais les commentaires javadoc doivent tous être en anglais. * manque des commentaires javadoc (classe, attributs, méthodes) * utiliser la convention d'indentation avec 4 espaces (faire un commit pour remplacer les tabulations) * limiter la taille des lignes à 120 caractères (une limite de 80 caractères aurait pu être plus pratique pour les petits écrans) Documents --------- * On ajoute les colonnes dans l’entité Document (au lieu de multiples table de jointure non performantes) * On fait la liaison Document ↔ Entite avec une stratégie cascade on delete * L'ird fait les page de CRUD des Documents. On doit seulement intégrer les Documents * Ajout de pièce jointe, après un ajout, il faut revenir sur l'ancienne page d'édition * Prochaine réunion: mardi 19 février à 8h00 -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com _______________________________________________ Cantharella-devel mailing list Cantharella-devel(a)list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel

2 1

Re: [Cantharella-devel] Réorganisation des dépendances MAVEN
by Adrien Cheype Feb. 13, 2013

Feb. 13, 2013

Le 12/02/2013 23:00, Benjamin POUSSIN a écrit : > On Tue, 12 Feb 2013 11:45:38 +0100 > Eric Chatellier <chatellier(a)codelutin.com> wrote: > >> Par exemple, dans le module web, la classe : >> nc.ird.cantharella.web.pages.SandboxPage >> compile explicitement en utilisant des imports hibernate : >> import org.hibernate.criterion.DetachedCriteria; >> import org.hibernate.criterion.Restrictions; >> >> Il semble y avoir une bonne pratique maven qui stipule que les dépendances >> nécessaires >> à la compilation doivent être explicitement déclarée dans le pom en scope compile. >> Il y a d'ailleurs un plugin maven qui sert a détecter ce genre d'erreur >> http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#The_depe… >> >> C'est une mauvaise pratique de compiler sur une dépendance transitive car si la >> librairie >> qui l'a tire est mise à jour et ne la tire plus, cela causera une erreur de >> compilation. >> >> Là encore, si les dépendances sont maitrisées, cela ne me parait pas gênant >> de ne pas le faire. D'autant plus qu'hibernate serait une dépendance transitive >> du module "cantharella.data" et le jour où il ne la tirera plus n'est pas prêt >> d'arriver. > Je ne suis pas vraiment d'accord :). > > Si dans le code on a un import explicite d'une librairie, il faut > l'avoir en dépendance dans le pom.xml > > Si cela nous dérange de l'avoir en dépendance (ex: mais pourquoi avoir > du hibernate dans la couche presentation ?). Pour moi cela veut dire que > le projet est mal découpé. On ne devrait pas avoir d'import hibernate > dans le module présentation et donc pas besoin de la dépendance. > > Il ne faut pas caché un mauvais découpage en module ou un manque de > méthode métier dans un module, en masquant une dépendance dans le > pom.xml en s'appuyant sur les dépendances transitive pour cela. > > Donc pour moi, soit on en a besoin et on met la dépendance > soit on en veut pas, et il faut refactoré le code pour supprimer la > dépendance Je comptais effectivement utiliser dependency:analyse pour m'assurer que seules les librairies utilisées directement apparaissent pour chaque module (sans oublier celle utilisées au runtime). Je vous tiens au courant dès que j'ai terminé ce nettoyage. J'enlèverai les dépendances qui n'ont pas lieu d'être car initialement le projet était bien découpée. Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Re: [Cantharella-devel] Réorganisation des dépendances MAVEN
by Adrien Cheype Feb. 12, 2013

Feb. 12, 2013

Bonjour, Je reprends la discussion suite au dernier message d'Eric (sujet "CR Réunion Cantharella du 29/01/2013") concernant la double déclaration systématique des dépendances dans un projet maven multimodule : - pom parent -> dans <dependencyManagement> avec <version> et <scope> - pom enfant -> dans <dependencies> sans <version> et <scope> Le 06/02/2013 22:10, Eric Chatellier a écrit : > Le 29/01/2013 11:06, Eric Chatellier a écrit : >> * CodeLutin se renseigne sur la vrai plus value à faire cela et renvoi un mail >> sur la liste > C'est bien une convention maven qui garantit la non divergence de version > des dépendances entre modules. > > Parce exemple, si la version d'une librairie (par exemple commons-io) est > définie dans un module. Si un jour un autre module en a besoin > et qu'il défini une version plus récente, il y a divergence. > Si la version est défini dans le dependencyManagement les futures > divergences seront impossibles. > > Après le problème des dépendances wicket est moins évident car > le cas où plusieurs modules utilisent des dépendances wicket n'est > pas prêt de se produire. > Mais par unification et dans le but d'éviter les futures erreurs, toutes > les versions sont définies à un seul endroit. > > C'est peut-être beaucoup plus évident également dans les gros > projets avec beaucoup de modules, mais la convention semble > s'appliquer de la même manière même aux projets plus petits. Merci pour les précisions, Eric. Effectivement, nous n'utilisions pas dependencyManagement bien que cela fasse partie des bonnes pratiques de Maven. Ce mécanisme qui permet de centraliser la gestion des versions de dépendance est en effet bien utile pour éviter les problèmes liées aux dépendances transitives. Cependant, bien que cela permette de fixer les versions réellement utilisées dans un build, ce mécanisme peut également certains effets de bords : dans le cas d'une dépendance transitive d'une version plus élevée que la version définie dans le dependencyManagement, il se peut que la librairie qui comporte cette dépendance transitive utilise un nouvelle méthode qui n'existe alors pas dans la version utilisée (version du dependencyManagement). Dans ce cas, le build s'effectue mais laisse des erreurs qui se produiront à l'exécution. Par conséquent, on voit aussi certains architectes qui préfère limiter au maximum l'utilisation du dependencyManagement : "don't use a |<dependencyManagement>| section unless you absolutely have to" !! (cf. http://blog.kdgregory.com/2012/08/taming-maven-dependency-management.html) Dans notre cas, je suis d'accord avec vous. Mieux vaut plus simplement déclarer toutes les versions des modules utilisées au même endroit, c'est plus uniforme et permettra d'éviter certaines erreurs. Par contre, cela n'empêche pas d'avoir également une section <dependencies> dans le pom parent (sans <version> et <scope>) permettant de factoriser certaines dépendances de base comme slf4j, log4j et junit. Cette pratique ne se retrouve pas dans tous les projets OpenSource, mais elle me semble avoir son sens. On la voit notamment dans des projets d'Apache tel Wicket : http://code.metager.de/source/xref/apache/wicket/pom.xml J'ai commencé à restructurer les pom.xml en enlevant les profils. Si vous partagez mes conclusions, je continuerai demain en modifiant les parties dépendances. D'ailleurs est-ce normal qu'il y ait les dépendances hibernate-core et hibernate-validator dans cantharella.web ? spring-jdbc dans cantharella.service ? ou h2 dans cantharella.service ? Et parmi hibernate-core, hibernate-search-engine, hibernate-search-orm, lucene-core dans cantharella.service, ne peut-on pas en enlever certaines qui se retrouveraient en dépendances transitives ? Bonne journée, Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

3 3

Re: [Cantharella-devel] Tableau wicket de la liste des molécules
by Adrien Cheype Feb. 12, 2013

Feb. 12, 2013

Bonjour, Effectivement ce cas précis ne s'était pas encore présenté mais il ressemble tout de même aux listes de produits des pages de consultation/édition des purifications ou des tests biologiques. Ce ne sont alors pas des Molecule ou des MoleculeProvenance qu'on liste mais des Extrait ou des Fractions (la différence étant qu'Extrait et Fraction héritent tous deux de Produit). La différenciation de traitement pour ces deux entités étaient alors gérée par des typeof, et tu fais bien de soulever le problème Eric car cette solution mériterait également d'être améliorée. Pour la liste des Molecule/MoleculeProvenance, je vois deux améliorations : - différenciation de traitement sans passer par des typeof - interface commune afin de ne pas itérer sur une liste d'Object (ou pour être précis d'AbstractModel, tel qu'écrit actuellement dans le code) En ce qui concerne le pattern visiteur, ce n'est pas à mon avis la solution la plus adaptée car nous n'avons pas besoin d'avoir plusieurs traitements pour un type d'objet. Par ailleurs, l'ajout d'une propriété "visitor" (appelée par accept) a davantage d'impact sur le modèle que l'ajout d'une méthode (bien qu'il soit possible de la déclarer @Transiant). Voici deux propositions à discuter qui reprend le cas de l'Id à afficher à chaque ligne du tableau (propriété "id" si Molecule ou "molecule.id" si MoleculeProvenance). 1ère proposition : lien pour modifier le diagramme <http://yuml.me/diagram/plain;/class/edit/%5BMolecule%7C+getId%28%29%5D%3Cmo…> + la surcharge de méthode permet la différenciation de traitement + aucune modification du modèle, MoleculeRow est indépendant du modèle et peut ainsi être inclue dans la couche web - ne répond pas au problème d'interface commune 2ème proposition : lien pour modifier le diagramme <http://yuml.me/diagram/plain;/class/edit/[--Interface--;MoleculeRow%7C+getR…> (comprendre <<Interface>> pour --Interface--) + l'utilisation du surclassage permet d'apporter les deux améliorations - est un peu plus intrusif par rapport au modèle (bien que l'interface et les méthodes supplémentaires n'auront a priori pas d'impact sur la structure de la BD sous-jacente) Quelle solution préférez-vous ? Une autre alternative à proposer ? Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype Feb. 11, 2013

Feb. 11, 2013

Bonjour Eric, Je confirme également. J'avais à ce propos déjà rectifier le CR dans mon mail du 04/02 : > Modification le point 3 de la partie Document : > * l'IRD fait les page de CRUD des types de documents (pour la partie > configuration). Code Lutin devra s'occuper des interfaces liées aux > documents. Adrien Le 12/02/2013 06:33, Sylvain PETEK a écrit : > Bonjour, > > Pour récapituler, est-ce que l'IRD doit faire quelque chose ? > Et si oui, quoi ? > > Pour nous, ce que doit faire code lutin c'est: > * ajout d'une colonne fichiers joints dans les tableaux > * ajout de la liste des documents sur les fiches consultations > * ajout de la liste des documents sur les fiches en éditions avec > possibilité d'ajout, modification, suppression d'un document attaché > * page de visualisation d'un document attaché > * page de création/modification d'un document attaché > > et à l'ird: > * les interfaces de visualisation/modification/suppression > des types de documents via l'interface d'administration > > Sommes-nous d'accord ? > > Oui c'est tout à fait ça. > > A bientôt, > > Sylvain > > > Sylvain PETEK > Chargé de Recherche > > UMR 241 Ecosystèmes Insulaires Océaniens > Etude Intégrée des Métabolites Secondaires > > Institut de recherche pour le développement > BP529 > 98713 Papeete > Polynésie française > > Tél. : +689 47 42 14 > Fax : +689 42 95 55 > sylvain.petek(a)ird.fr > > www.ird.fr > www.pomare.org > cantharella.ird.nc > > > > > > _______________________________________________ > Cantharella-devel mailing list > Cantharella-devel(a)list.forge.codelutin.com > http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Sylvain PETEK Feb. 11, 2013

Feb. 11, 2013

Bonjour, Pour récapituler, est-ce que l'IRD doit faire quelque chose ? Et si oui, quoi ? Pour nous, ce que doit faire code lutin c'est: * ajout d'une colonne fichiers joints dans les tableaux * ajout de la liste des documents sur les fiches consultations * ajout de la liste des documents sur les fiches en éditions avec possibilité d'ajout, modification, suppression d'un document attaché * page de visualisation d'un document attaché * page de création/modification d'un document attaché et à l'ird: * les interfaces de visualisation/modification/suppression des types de documents via l'interface d'administration Sommes-nous d'accord ? Oui c'est tout à fait ça. A bientôt, Sylvain Sylvain PETEK Chargé de Recherche UMR 241 Ecosystèmes Insulaires Océaniens Etude Intégrée des Métabolites Secondaires Institut de recherche pour le développement BP529 98713 Papeete Polynésie française Tél. : +689 47 42 14 Fax : +689 42 95 55 sylvain.petek(a)ird.fr www.ird.fr www.pomare.org cantharella.ird.nc

1 0

Tableau wicket de la liste des molécules
by Eric Chatellier Feb. 11, 2013

Feb. 11, 2013

Bonjour, Actuellement, dans cantharella, l'affichage des tableaux est relativement "simple" dans le sens où il affiche globalement une liste simple d'elements (List<Lot>). Pour les molécules, il faut afficher une liste mixte (List<Object>) qui est composée: * de MoléculeProvenance (répété pour une même molécule) * de Molécule (s'il n'y a pas de provenance ou de provenance visible pour l'utilsateur) Donc le but serait d'afficher une List<Object> composé de MoleculeProvenance et/ou Molecule. J'ai peur que pour les tableau, géré pour chaque colonne 2 cas via un instanceof ne soit pas très propre. Y a-t-il une facon plus simple de coder la chose ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

2 1

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype Feb. 5, 2013

Feb. 5, 2013

Ok, parfait Eric. Je suis en train de regarder de mon côté pour mettre en place le module Maven java-formatter qui nous permettra d'homogénéiser le formatage du code (cf. les conventions que nous avons définies). Il me reste à faire fonctionner le module avec notre configuration multi-projet. J'enverrai un mail spécial convention dès que ça sera fait. Bonne journée, Adrien Le 04/02/2013 21:35, Eric Chatellier a écrit : > C'est fait. > > Juste à noter deux petits changements: > * le niveau 'fatal' n'existe pas sur slf4j (à deux endroits j'ai changé à error) > * log.debug() prend un Object dans jcl alors que c'est un String dans slf4j > J'ai du convertir en String certains log.debug sur des double, boolean, List... > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype Feb. 4, 2013

Feb. 4, 2013

Bonjour, Comme Mickaël l'a expliqué, l'intérêt de LogTools#getLog() est de pouvoir déclarer un logger avec un simple copier-coller. Je ne saurais dire pourquoi cette idée, a priori bonne, n'est pas plus répandue. J'imagine que c'est lié aux inconvénients introduits pour récupérer la classe de la méthode appelante. Au départ, il y avait effectivement un mécanisme de lever d'exception qui nous permettait de récupérer le bon nom de classe. Cette façon de faire n'étant pas très performante, j'avais pris la décision de régler le problème de performance en utilisant la classe Sun.reflect.Reflection. La contre-partie est que la classe n'existe que dans certaines jvm (sun et openjdk par ex.) et qu'il est imposible de l'exécuter dans certains environnements de sécurité restreinte (applets notamment). OK pour revenir à une déclaration plus classique en écrivant à la main le nom de classe. Pour ne pas avoir à changer plus d'une ligne, vous pouvez garder le nom de variable LOG. Adrien Le 02/02/2013 05:10, Mickaël Tricot a écrit : > Bonsoir, > > J'ai écrit l'implémentation initiale de LogTools#getLog(), qui a > apparemment évoluée depuis. > > L'unique avantage est de pouvoir copier-coller cette ligne d'une > classe à l'autre sans risque d'erreur. > > C'est moins performant que la méthode classique — > LoggerFactory.getLogger(HelloWorld.class) — puisqu'il s'agit de > générer une exception, d'analyser la stacktrace pour récupérer la > classe appelante et enfin de générer le logger adéquate. Générer une > exception est coûteux et généralement déconseillé, mais j'avais jugé > ce surcoût négligeable dans une telle application. > > Revenir à la méthode plus conventionnelle est une bonne idée, car plus > compréhensible pour les autres développeurs. Concernant le nom de la > variable, j'ai une préférence pour le nom concis (LOG), mais il s'agit > seulement là d'une habitude ou d'une question de goût. > > Cordialement, > Mickaël > > On 01/02/2013 18:13, Eric Chatellier wrote: >> Actuellement nous avons: >> private static final Log LOG = LogTools.getLog(); >> >> La convention slf4j est plutôt: >> >> private static final Logger logger = >> LoggerFactory.getLogger(HelloWorld.class); >> Ce qui implique de renommer aussi la variable "LOG" en LOGGER dans toute >> la classe également. >> >> La modification est plus importante que modifier une seule ligne >> dans chaque classe. >> >> >> Une autre question. C'est la première fois que je vois la déclaration >> des logs de façon générique: >> private static final Log LOG = LogTools.getLog(); >> qui récupère un Log sur la classe en haut de la stack actuelle. >> >> Je suis curieux de savoir si c'est performant et s'il y a une source >> qui explique les avantages (voire pourquoi ce n'est pas plus répandu). >> >> Ce mécanisme utilise, de plus, un import "sun.reflect.Reflection" >> (dans nc.ird.module.utils.GenericsTools) qui est déconseillé. > _______________________________________________ > Cantharella-devel mailing list > Cantharella-devel(a)list.forge.codelutin.com > http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype Feb. 4, 2013

Feb. 4, 2013

Bonjour, Quelques petites corrections de ma part par rapport à ce qui a été dit. Dans la partie molécule, ajout du point : * le dessin de la molécule affiché dans la liste de molécules et dans la consultation est tronquée de sur la droite (atomes manquants pour certaines molécules !) + modification de Sylvain Modification le point 3 de la partie Document : * l'IRD fait les page de CRUD des types de documents (pour la partie configuration). Code Lutin devra s'occuper des interfaces liées aux documents. Ci-dessous le CR mis à jour (modification en gras). CR Réunion Cantharella du 29/01/2013 ==================================== Molécules --------- * Liste des molécules: les molécules doivent être dupliqué pour chaque provenance * édition des molécules: aligner sur les champs, manque la recherche de molécule, et la calculatrice * champs obligatoire qui ne sont pas requis: nom commun, famille chimique, nom iupac. * Identifiée par, mettre en plus les organismes lié aux personnes * problème le message "... car vous n'avez pas les droits nécessaires" est toujours affiché (voir exemple dans test biologique) (a regarder la meilleurs solution comment faire) * Les champs campagne et espèce ne fonctionne pas encore * Les droits utilisateurs ne sont pas encore complètement géré * double sur la page d'affichage de la molécule (même taille que l’édition) * si on clique sur l'image, il faut pouvoir la sauver. (ça marche sur firefox mais pas sous webkit, donc prévoir que si on clique sur l'image, on ouvre une nouvelle fenêtre avec une vraie image * changer "est-ce une nouvelle molécule ?" en "nouvelle molécule ?" * en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule. * Molécule provenance: On peut rattacher plusieurs fraction et non pas une seule, a priori seul le MCD est faux. Dans le code ça doit être possible* * en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule.* ** le dessin de la molécule affiché dans la liste de molécules et dans la consultation est tronquée de sur la droite (atomes manquants pour certaines molécules !)* slf4j contre commons-logging ---------------------------- * Log: pas de plus value à migrer, mais il faut tout de même corrige le problème actuel. * Une migration slf4j avec une impl log4j est tout de même demandée. Configuration et suppression des profiles ----------------------------------------- * On passe par ApplicationConfig, qui peut changer de fichier de config sur la ligne de commande Gestion des dépenandances maven ------------------------------- * double déclaration des dépendances pom.xml parent et enfant * c'est une convention maven * CodeLutin se renseigne sur la vrai plus value à faire cela et renvoi un mail sur la liste Convention de codage -------------------- * il y a un mélange historique de commentaire anglais/francais, mais les commentaires javadoc doivent tous être en anglais. * manque des commentaires javadoc (classe, attributs, méthodes) * utiliser la convention d'indentation avec 4 espaces (faire un commit pour remplacer les tabulations) * limiter la taille des lignes à 120 caractères (une limite de 80 caractères aurait pu être plus pratique pour les petits écrans) Documents --------- * On ajoute les colonnes dans l’entité Document (au lieu de multiples table de jointure non performantes) * On fait la liaison Document ↔ Entite avec une stratégie cascade on delete **l'IRD fait les page de CRUD des types de documents (pour la partie configuration). Code Lutin devra s'occuper des interfaces liées aux documents.* * Ajout de pièce jointe, après un ajout, il faut revenir sur l'ancienne page d'édition

1 0