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
Le 29/01/2013 11:06, Eric Chatellier a écrit :
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.
Avant de commencer cette migration, j'ai quelques petites questions. 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é. Cordialement, Eric Chatellier. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
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é.
Le 29/01/2013 11:06, Eric Chatellier a écrit :
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
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. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Bonjour, Le 29/01/2013 11:06, Eric Chatellier a écrit :
* L'ird fait les page de CRUD des Documents. On doit seulement intégrer les Documents Nous sommes actuellement bloqués par ce point.
En relisant le cahier des charges et notre chiffrage, nous avons l'impression que nous sommes trompés durant la dernière réunion. Dans le CR, il est écrit "CRUD des Documents". Il semblerait que cela soit "CRUD des Types de Documents". 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 ? Cordialement, Eric Chatellier. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Le 29/01/2013 11:06, Eric Chatellier a écrit :
* édition des molécules: aligner sur les champs, manque la recherche de molécule, et la calculatrice J'ai réussit à activer la recherche et la calculatrice, mais ça nécessite l'utilisation d'un service distant.
Actuellement, cela affiche: "Your domain is not registered to use these services. Please contact iChemLabs to register. http://www.ichemlabs.com." -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
participants (2)
-
Eric Chatellier -
Mickaël Tricot