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

Re: [Cantharella-devel] Setter des associations bidirectionnelles hibernate
by Adrien Cheype 04 Mar '13

04 Mar '13

Bonjour Eric, Nous avons mis à jour qu'un côté des associations pour l'unique raison de simplifier le code. Mais tu as raison, cette manière de faire entraîne des graphs de persistance incohérents. Si je comprends bien le post que tu donnes en exemple, quand Hibernate détecte des incohérences, il semble prendre en compte la version de l'entité propriétaire de l'association (par exemple dans une association 1-n, l'entité du côté 1). Seulement ce ne semble pas être ce qui arrive avec personne#lotsDroits par exemple. En effet, c'est bien l'entité non propriétaire de la relation qui est mise à jour et une fois la session hibernate rechargée, nous nous retrouvons bien avec graph cohérent avec les éléments précédemment ajoutés. En regardant la doc d'hibernate que j'ai trouvée, ils parlent en effet bien qu'il fasse mettre à jour les deux côtés, mais disent seulement qu'il se servent de l'entité propriétaire pour résoudre les conflits. http://docs.jboss.org/hibernate/core/4.1/manual/en-US/html/ch01.html#tutori… J'ai donc plutôt l'impression que quand le graph est incohérent, il prend d'abord en compte la propriété qui a été mise à jour et si les deux l'ont été (de manière différente du coup), il prend la version de l'entité propriétaire. En tout cas, n'hésite pas à corriger la façon de mettre à jour ces associations... surtout si cela peut entraîner des effets de bord avec Hibernate Search. Adrien PS : en passant ManageUtilisateurPage.java est un bon exemple Wicket de comment inutilement compliquer les développements en utilisant des listes temporaires. C'est un artefact qui reste par rapport aux autres interfaces qui gèrent bien plus simplement des listes de même type. Le 01/03/2013 04:51, Eric Chatellier a écrit : > Bonjour, > > Dans cantharella, les associations sont bidirectionnelles > mais des modifications ne sont toujours faite que d'un seul coté. > > Comme décrit dans ce commentaire: > http://stackoverflow.com/a/5460737/2038100 > l'association devrait être référencées des deux cotés. > (apparemment la doc officielle en parle aussi, mais pas > moyen de retrouver le lien). > > Le problème n'est pas visible à l'exécution car > dans le cas d'une application web, lors du rechargement > entre les pages, les associations sont bien valuées des > deux cotés. > > Ce problème pourrait être à l'origine d'un effet > de bord dans l'indexation lucene. > Les droits sont ajoutés sur les utilisateurs: > personne#lotsDroits, mais le lot n'étant pas modifiés > lot#personnesDroits, hibernate ne peut pas détecter > que le lot a été modifié pour le réindexer. > > Est-ce volontaire de ne pas gérer les bidirections > des deux cotés ? > -- 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

CR Réunion Cantharella du 19/02/2013
by Eric Chatellier 04 Mar '13

04 Mar '13

CR Réunion Cantharella du 19/02/2013 ==================================== Molécule -------- * Faire en sorte que les tableaux soient alignés et non centrés * Rendre le canvas cliquable pour afficher l'image du rendu html5 * Ajouter un lien pour télécharger le fichier .mol (Renommer le lien Download) * Le tableau de provenance n'est pas finalisé en visualisation * Le pourcentage de provenance n'est pas obligatoire * Tester le rafraichissement des champs après mise à jour * Ajouter l'infobulle d'information pour signaler que les molécules sont visible par tout le monde * Tester l'affichage des provenances pour un simple utilisateur (pb affichage) Documents --------- * Renommer le texte en "Joindre un document" * Indiquer dans le formulaire que le fichier ne peut pas faire plus de 1M * Rendre la taille configurable * Corriger la mise à jour du tableau des documents après ajout (retour) * Supprimer le champ "est une image" du type de document c'est c'est faisable par extension ou mimetype de fichier * Générer la miniature dès l'enregistrement du fichier et la stocker en base de données (pour avoir de meilleurs performances) Divers ------ * À rediscuter d'avoir l'export CSV dans tous les tableaux (test biologiques) * Corriger le problème de recherche des molécules (droits) * Essayer de ne pas faire la recherche sur les ID (sauf molécule): champ indexés, mais pas recherché * Problème lors de la récupération de mot de passe: * "Vote mot de passe Cantharella a été régénéré" ('vote' -> 'votre') * probleme message: probleme envoie mot de passe, mais au final envoyé. * probleme: le mot de passe envoyer ne permet pas de s'authentifier * probleme avec IE sur les dernières versions Env --- * Ajouter les svn:keywords pour la mise à jour des variables * Envoyer un mail pour la génération du site maven -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

1 4

Re: [Cantharella-devel] Gestion des droits dans cantharella
by Sylvain PETEK 28 Feb '13

28 Feb '13

Bonjour, Les personnes peuvent effectivement avoir des droits: soit - sur 1 campagne et tous les lots associés soit - sur 1 ou plusieurs lots d'une campagne >> Il y a en plus une notion de 'groupe', mais qui n'a pas l'air utilisée. Est-ce une notion future ? ou qui ne sert plus ? Ca fait partie des fonctionnalités en suspend: l'idée est de créer des groupes de personnes (membres d'un même laboratoire, d'un même projet etc...) pour pouvoir leur assigner les mêmes droits. >>Pour un droit, il y a aussi plusieurs notions, >>4 booléens (droitExtrait, droitPuri, droitTestBio, droitRecolte) http://maven-site.forge.codelutin.com/cantharella/cantharella.data/apidocs/i ndex.html?>>nc/ird/cantharella/data/model/Droits.html >>Mais ils n'ont pas encore l'air exploité à l'heure actuelle. Là encore il s'agit d'une fonctionnalité en suspend: l'idée est de pouvoir donner des droits différenciés sur tel ou tel "module". Cordialement, 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é : jeudi 28 février 2013 07:31 À : cantharella-devel(a)list.forge.codelutin.com Objet : [Cantharella-devel] Gestion des droits dans cantharella Bonjour, Je viens de reprendre la gestion des droits dans cantharella. Les personnes ont donc: * un droit sur une campagne (tous les lots) * un droit sur plusieurs lots d'une campagne Il y a en plus une notion de 'groupe', mais qui n'a pas l'air utilisée. Est-ce une notion future ? ou qui ne sert plus ? Pour un droit, il y a aussi plusieurs notions, 4 booléens (droitExtrait, droitPuri, droitTestBio, droitRecolte) http://maven-site.forge.codelutin.com/cantharella/cantharella.data/apidocs/i ndex.html?nc/ird/cantharella/data/model/Droits.html Mais ils n'ont pas encore l'air exploité à l'heure actuelle. L'indexation du moteur de recherche dépend des choses à gérer réellement. Cordialement, -- Éric Chatellier _______________________________________________ Cantharella-devel mailing list Cantharella-devel(a)list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel

1 0

Setter des associations bidirectionnelles hibernate
by Eric Chatellier 28 Feb '13

28 Feb '13

Bonjour, Dans cantharella, les associations sont bidirectionnelles mais des modifications ne sont toujours faite que d'un seul coté. Comme décrit dans ce commentaire: http://stackoverflow.com/a/5460737/2038100 l'association devrait être référencées des deux cotés. (apparemment la doc officielle en parle aussi, mais pas moyen de retrouver le lien). Le problème n'est pas visible à lexécution car dans le cas d'une application web, lors du rechargement entre les pages, les associations sont bien valuées des deux cotés. Ce problème pourrait être à l'origine d'un effet de bord dans l'indexation lucene. Les droits sont ajoutés sur les utilisateurs: personne#lotsDroits, mais le lot n'étant pas modifiés lot#personnesDroits, hibernate ne peut pas détecter que le lot a été modifié pour le réindexer. Est-ce volontaire de ne pas gérer les bidirections des deux cotés ? -- Éric Chatellier

1 0

Gestion des droits dans cantharella
by Eric Chatellier 28 Feb '13

28 Feb '13

Bonjour, Je viens de reprendre la gestion des droits dans cantharella. Les personnes ont donc: * un droit sur une campagne (tous les lots) * un droit sur plusieurs lots d'une campagne Il y a en plus une notion de 'groupe', mais qui n'a pas l'air utilisée. Est-ce une notion future ? ou qui ne sert plus ? Pour un droit, il y a aussi plusieurs notions, 4 booléens (droitExtrait, droitPuri, droitTestBio, droitRecolte) http://maven-site.forge.codelutin.com/cantharella/cantharella.data/apidocs/… Mais ils n'ont pas encore l'air exploité à l'heure actuelle. L'indexation du moteur de recherche dépend des choses à gérer réellement. Cordialement, -- Éric Chatellier

1 0

Re: [Cantharella-devel] Méthode equals() et hashCode() non redéfinie sur les entités
by Adrien Cheype 28 Feb '13

28 Feb '13

Le 27/02/2013 20:47, Eric Chatellier a écrit : > Le 27/02/2013 07:04, Adrien Cheype a écrit : > >> Tu devrais normalement t'en sortir avec cet astuce... > Ok, ca fonctionne avec cette astuce. Parfait, si ça a pu résoudre ton problème. Attention tout de même à changer le commentaire pour la compréhension, ce hack n'est plus dans ce cas pour une "saisie multiple avec préremplissage". Autres détails, il ne me semble pas que tu sois obliger de passer en argument pour ManageListDocumentsPanel un Model de DocumentAttachable, un DocumentAttachable devrait suffire. Pareil pour ReadDocumentPage et ManageDocumentPage. La question peut se poser de passer systématiquement entre classes des modèles ou directement les objets, mais actuellement la logique actuelle est de passer les objets, donc mieux vaut suivre la même logique (on créé les modèles quand on a besoin dans chaque classe). >> à moins que tu préfères charger ton objet dans la même session Hibernate que >> ta liste. > C'est un document qui n'a pas forcement d'id (par encore sauvé), donc actuellement > je n'ai que l'instance non rechargeable. Ok, je comprends mieux la subtilité. Tu ne peux pas utiliser un constructeur qui prend en argument un id et qui charge l'objet car celui-ci peut ne pas exister. Cela se passe uniquement quand on crée une entité quelconque puis qu'on ajoute un document et qu'on revient sur son édition avant d'avoir valider l'entité créer. Ce n'est qu'à la validation du formulaire de cet entité que l'ensemble des objets sont enregistrés en base. Par contre, ce que je ne saisis pas tout à fait, c'est que tu sembles effectuer l'ajout du fichier en base lorsqu'on valide l'ajout d'un document. Cette ajout ne devrait-il pas se faire qu'une fois l'entité enregistré pour éviter de laisser des fichiers orphelins ?? (exemple du cas où l'utilisateur ajoute des documents puis annule ensuite l'ajout de l'entité). Cela me fait penser qu'il faudrait prévenir l'utilisateur au retour de formulaire d'édition du document par un simple avertissement du style : "L'enregistrement du document s'effectuera à la validation du formulaire". 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] [Cantharella - Anomalie #2061] (Nouveau) Interface "Gestion d'un document" : problem with field "langue"
by Eric Chatellier 27 Feb '13

27 Feb '13

Le 26/02/2013 23:30, admin(a)forge.codelutin.com a écrit : > ---------------------------------------- > Anomalie #2061: Interface "Gestion d'un document" : problem with field "langue" > > For the field "langue", there is a list of country instead of a list of languages J'ai fait la même chose que pour la liste des pays par copier/coller en addaptant avec le mot de langues. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

1 0

Re: [Cantharella-devel] Méthode equals() et hashCode() non redéfinie sur les entités
by Adrien Cheype 27 Feb '13

27 Feb '13

Le 27/02/2013 01:50, Eric Chatellier a écrit : > Bonjour, > > Je rencontre actuellement un petit problème visible sur > la modification d'un document. > Lorsque l'on tente de modifier un document existant, le > créateur n'est sélectionné avec la bonne valeur. > > Le code étant le suivant: > final DropDownChoice<Personne> createurInput = new > DropDownChoice<Personne>("Document.createur", > new PropertyModel<Personne>(documentModel, "createur"), personnes); > > Je pense que le problème se situe au niveau des méthodes > equals() des entités qui ne sont pas redéfini, l’implémentation > par defaut étant 'this == obj', ca peut passer > dans la majorité des cas car il y a le cache hibernate, > mais dans ce cas la cela ne fonctionne pas. > > A code lutin, nous redéfinissons systématiquement le equals() > et le hashCode() en fonction des id car il existe toujours. > Mais dans le cas de cantharella ils sont générés par la base de > données. > > Je ne vois pas comment corriger simplement le problème. > J'ai testé en ajoutant un equals() rapidement et cela corrige > le problème. Re Eric, Initialement, le choix avait été fait de ne pas redéfinir les equals() et hashCode() et nous avons mis en place pour Cantharella des façons de contourner les désavantages que cela impliquent. Même si ce n'est pas la solution optimale, je ne pense pas que ce soit une bonne idée de revenir sur ce choix aujourd'hui. Cela impliquerait trop d'effets de bords, par conséquent énormément de tests pour vérifier que l'existant fonctionne toujours correctement et pas mal de modifications de codes. Pour être plus exact, tous les equals() et hashCode() ne sont pas redéfinis à part pour les @CompositeId (c'est obligatoire) où c'est à chaque fois la même classe paramétré (CompositeId.java) qui est utilisé. Le hashcode et le equals sont alors redéfinis en se basant sur chaque hashcode ou equals de deux entités qui le compose. Grosso modo, l'inconvénient de ce choix est que deux mêmes objets ne seront pas égaux s'ils proviennent d'une session hibernate différente. Ainsi cela implique que pour comparer deux entités, nous utilisons pas les equals() classiques mais une méthode spécifique qui se basent sur la valeur d'une ou plusieurs propriétés (BeanTools.equals(Object thiz, Object obj, AccessType accessType, String... properties)). De même pour les comparaisons dans une liste, nous n'utilisons pas les contains() et dérivés mais d'autres méthodes statiques de la classe CollectionTools (containsWithValue(...), findWithValue(...), countWithValue(...)). Dans ton cas particulier de liste déroulante, le problème est que Wicket utilise un contains() pour initialiser la liste avec la bonne valeur. Si la liste dans laquelle il recherche l'entité et cette entité recherchée n'ont pas été chargés dans la même session Hibernate, Wicket ne peut pas faire la correspondance avec le contains(). En générale, nous chargeons les objets dans la même session ce qui évite ce problème. Nous avons cependant déjà eu plusieurs cas où il nous a fallu contourné le problème. Cela se passe lors d'une saisie multiple lorsqu'on veut précharger certains champs du formulaire avec ceux du précédent formulaire. Tu peux trouver le code suivant dans la classe ManagePurificationPage, les commentaires expliquent ce cas particulier : > // qd saisie multiple avec préremplissage, hack nécessaire > afin d'avoir dans le model le même objet que > // celui de la liste de choix (sinon comme les objets > viennent de sessions hibernate différentes, on n'a pas > // l'égalité entre les objets) > purificationModel.getObject().setManipulateur( > CollectionTools.findWithValue(personnes, > "idPersonne", AccessType.GETTER, purificationModel > .getObject().getManipulateur().getIdPersonne())); Tu devrais normalement t'en sortir avec cet astuce... à moins que tu préfères charger ton objet dans la même session Hibernate que ta liste. 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] Méthode equals() et hashCode() non redéfinie sur les entités
by Adrien Cheype 27 Feb '13

27 Feb '13

Quelques questions à la liste pour revenir à la problématique hors projet Cantharella. Étant donné que l'inconvénient de ne pas définir les equals()/hashCode() implique à prendre en compte certains cas particuliers que je préférerais me passer, je me demande quelle serait la stratégie qui comportent le plus d'avantages. Pour mon information, Eric, pourrais-tu me donner plus de détails sur votre façon de générer un id depuis la couche DAO (et même un exemple de classe si possible) ?? La page suivante (https://community.jboss.org/wiki/EqualsAndHashCode) résume bien les différents problèmes qui peuvent survenir suivant les différentes stratégies (cf. "Summary"). La votre n'y est pas présentée, mais elle semble répondre aux quatre problèmes présentés. Le seul inconvénient que j'y vois semble qu'il n'est alors pas possible de garantir au niveau de la base une même logique d'affectation des identifiants (quid des autres moyens de renseigner la BD que via l'application en question ?). J'avais pensé il y a déjà quelques temps à une autre stratégie ou l'on attribue un ID temporaire au niveau de l'application à la création puis que l'ID soit écrasé par la valeur attribué par la BD dès qu'il passe en persistance. Une dernière solution très fréquente est de baser l'equals/hashcode sur les clés métiers. Bien qu'il faille prendre le temps de les définir pour chaque objet, il semblerait que ce soit la solution idéale lorsqu'on est sûr d'avoir une propriété immuable (ou une combinaison) pour le cycle de vie de l'entité. Dans le cas où l'entité n'ait pas de telles propriétés (c'est le cas notamment dans Cantharella), on entend deux sons de cloches : certains semblent dirent qu'il faille trouver une autre statégie, d'autres prétendent que contrairement à une clé primaire, ce n'est pas une obligation que les clés métiers ne changent pas, si cela se produit rarement (cf. extrait de "Java Pertinence with Hibernate" dans le sujet : http://stackoverflow.com/questions/2719877/object-equality-in-context-of-hi…) Si l'on tolère de rares changements, la solution d'ID temporaire, et celle des clés métiers pourraient être toutes deux de bonnes candidates qui s'appliqueraient à tous les cas. Qu'en pensez-vous ? Des avis/préférences sur ces stratégies ? Adrien Le 27/02/2013 17:04, Adrien Cheype a écrit : > Re Eric, > > Initialement, le choix avait été fait de ne pas redéfinir les equals() > et hashCode() et nous avons mis en place pour Cantharella des façons > de contourner les désavantages que cela impliquent. Même si ce n'est > pas la solution optimale, je ne pense pas que ce soit une bonne idée > de revenir sur ce choix aujourd'hui. Cela impliquerait trop d'effets > de bords, par conséquent énormément de tests pour vérifier que > l'existant fonctionne toujours correctement et pas mal de > modifications de codes. > > Pour être plus exact, tous les equals() et hashCode() ne sont pas > redéfinis à part pour les @CompositeId (c'est obligatoire) où c'est à > chaque fois la même classe paramétré (CompositeId.java) qui est > utilisé. Le hashcode et le equals sont alors redéfinis en se basant > sur chaque hashcode ou equals de deux entités qui le compose. > > Grosso modo, l'inconvénient de ce choix est que deux mêmes objets ne > seront pas égaux s'ils proviennent d'une session hibernate différente. > Ainsi cela implique que pour comparer deux entités, nous utilisons pas > les equals() classiques mais une méthode spécifique qui se basent sur > la valeur d'une ou plusieurs propriétés (BeanTools.equals(Object thiz, > Object obj, AccessType accessType, String... properties)). De même > pour les comparaisons dans une liste, nous n'utilisons pas les > contains() et dérivés mais d'autres méthodes statiques de la classe > CollectionTools (containsWithValue(...), findWithValue(...), > countWithValue(...)). > > Dans ton cas particulier de liste déroulante, le problème est que > Wicket utilise un contains() pour initialiser la liste avec la bonne > valeur. Si la liste dans laquelle il recherche l'entité et cette > entité recherchée n'ont pas été chargés dans la même session > Hibernate, Wicket ne peut pas faire la correspondance avec le > contains(). En générale, nous chargeons les objets dans la même > session ce qui évite ce problème. > > Nous avons cependant déjà eu plusieurs cas où il nous a fallu > contourné le problème. Cela se passe lors d'une saisie multiple > lorsqu'on veut précharger certains champs du formulaire avec ceux du > précédent formulaire. Tu peux trouver le code suivant dans la classe > ManagePurificationPage, les commentaires expliquent ce cas particulier : > >> // qd saisie multiple avec préremplissage, hack >> nécessaire afin d'avoir dans le model le même objet que >> // celui de la liste de choix (sinon comme les objets >> viennent de sessions hibernate différentes, on n'a pas >> // l'égalité entre les objets) >> purificationModel.getObject().setManipulateur( >> CollectionTools.findWithValue(personnes, >> "idPersonne", AccessType.GETTER, purificationModel >> .getObject().getManipulateur().getIdPersonne())); > > Tu devrais normalement t'en sortir avec cet astuce... à moins que tu > préfères charger ton objet dans la même session Hibernate que ta liste. > > 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 -- 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 19/02/2013
by Adrien Cheype 27 Feb '13

27 Feb '13

Le 26/02/2013 21:17, Eric Chatellier a écrit : > Ok, merci pour ce retour. Je me doutais bien que le model (load()) ne servait > pas a grand chose. > Avec un simple PropertyModel, c'est tout de suite plus propre. >> Tu peux d'ailleurs le passer en paramètre de ton ReadListDocumentsPanel au >> lieu du modèle de molécule. Ce serait plus cohérent : le panel sert à afficher >> le modèle de ce qu'il doit afficher. > En fait je me sers quand même de la molécule pour ajouter les documents dessus > quand on passe > en édition. Je trouves le couplage avec l'entité sauvegardée en base plus fort > qu'une simple > liste (lazy) qui pourrait peut être poser d'autres problèmes. C'est ok pour moi comme tu l'as écris. Je t'avais répondu pour un cas plus général et c'est sûr que dans ce cas précis on a besoin d'accéder aux documents de l'entité en modification. > Du coup, l'interface DocumentAttachable (sur les entités sur lequelles ont peut > ajouter > des documents) ne servirait pas non plus ? Je n'ai pas vu la manière dont tu t'en servais avant mais l'ajout d'une interface me semble être une bonne idée car elle apporte plus de clarté au niveau du modèle. Par ailleurs, elle permet de contraindre l'ajout de document aux seules entités qui puissent en avoir (IModel<? extends DocumentAttachable> que tu as mis en signature du constructeur ManageDocumentPage). -- 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