Généricité / Ajouter de nouveaux protocoles spécifiques

[camillemonchicourt]

L'application est fourni avec quelques protocoles, leurs formulaires de saisie, leurs schémas dans la BDD et les triggers pour alimenter la synthèse dès qu'une donnée est saisie dans ces différents protocoles.

Il est possible d'ajouter de nouveaux protocoles dans GeoNature.
Il faut les ajouter de la manière la plus générique possible pour ne pas modifier le code de GeoNature et ainsi pouvoir bénéficier des prochaines mises à jour de GeoNature.

GENERIQUE :

• Créer un schéma par protocole dans la base de données pour ne pas modifier les schémas existants dans GeoNature.
• Dans les schémas des nouveaux protocoles, mettre en place les triggers alimentant automatiquement la synthèse à chaque fois d'une donnée est insérée ou modifiée dans un de ces protocoles (en s'inspirant des triggers existants dans les schémas des protocoles existants).
• Si vous souhaitez intégrer les formulaires de saisie dans l'application, créer un nouveau module Symfony pour chaque protocole pour leurs formulaires de saisie. Vous pouvez copier un des modules existants pour s'en inspirer en le modifiant.
• Compléter les tables meta.bib_programmes, meta.bib_lots, meta.t_protocoles et synthese.bib_sources et renseignez leurs identifiants dans les fichiers de configuration lib/sfGeonatureConfig.php et web/js/config.js avec les identifiants de chaque protocole. Voir Mettre à jour la liste des programmes du critère de recherche COMMENT de SYNTHESE #63

NON GENERIQUE :

• Les parties qui ne sont pas dissociables sont le module Symfony bibs, le fichier de routing, la description de la BDD dans le fichier config/doctrine/schema.yml et l'appel des JS et CSS dans apps/backend/modules/home/config/view.yml.
  A terme ces éléments pourraient être éclatés dans un fichier par protocole/module mais aujourd'hui il faut y ajouter les parties spécifiques à vos nouveaux protocoles.
  Pensez à bien les grouper et les commenter pour pouvoir les reporter après mise à jour de GeoNature.
• La liste des protocoles et les liens vers leurs formulaires de saisie sur la page d'accueil de GeoNature est à modifier dans le fichier apps/frontend/modules/home/template/indexSuccess.php.
• Pour pouvoir éditer une donnée source dans son formulaire de saisie depuis la liste des observations de la synthèse, complétez le fichier web/js/synthese/application.synthse.search.js.

[camillemonchicourt]

Depuis la version 1.5.0 de GeoNature, la liste des liens vers les formulaires de saisie des différents protocoles est paramétrable dans la table synthese.bib_source, voir #69).

Du coup il ne faut plus modifier la page apps/frontend/modules/home/template/indexSuccess.php à la main pour y ajouter ses protocoles, mais bien compléter la table synthese.bib_source.

• Le nouveau champs url permet de spécifier l'url du formulaire (cf ou http://mondomaine.fr/suivi_chiro par exemple)
• Le nouveau champs target permet de spécifier si le lien doit s'ouvrir dans le même onglet (laisser le champs vide) ou dans un autre onglet (saisir _blank)
• Le nouveau champ picto permet de renseigner le chemin vers le picto à afficher devant chaque protocole (images/pictos/mousse.gif par exemple pour le protocoles bryophytes).
• Le nouveau champs groupe permet de regrouper les protocoles dans différents blocs (par exemple Faune, Flore, Fonge ou Inventaire, Suivi)

[gildeluermoz]

GENERICITE :
Le fichier indexSucess.php ne comporte plus que l'accès à la page home. Les accès aux autres modules ont été déplacés dans le fichier actions/actions.class.php
Chaque module comporte désormais dans son propre répertoire :
* son template = indexSuccess.php dans le répertoire templates
* son view.yml dans le répertoire config pour l'appel des js et css.

Les parties qui restent non génériques sont le module Symfony bibs (modification à venir),

Pour ce qui concerne le fichier de routing.yml et la description de la BDD dans le fichier config/doctrine/schema.yml. Symfony 1 ne permet pas l'éclatement de leur contenu dans plusieurs fichiers. Ces deux fichiers resteront donc à modifier en cas d'ajout de modules à GeoNature.

[camillemonchicourt]

Concernant la liste des protocoles affichés sur la page d'accueil, elle est générée dynamiquement depuis la version 1.5.0 à partir des valeurs dans la table synthese.bib_sources - #69

Concernant ces évolutions en terme de généricité et de séparation des modules dans des fichiers qui leur sont propres, bien l'indique dans les prochaines notes de version et voir si il y a des répercussions à faire dans la doc.

[camillemonchicourt]

Révision dans la V2 à l'occasion du passage à Python/Flask.

[orovellotti]

Cette discution semble obsolète.
Est ce qu'il existe une doc pour ajouter un protocole a la V2 ?

[camillemonchicourt]

Oui cela concernait la V1 qui était beaucoup moins modulaire que ce que l'on met en place avec la V2.
Concernant la V2, on a amorcé une doc DEVELOPER : https://github.com/PnX-SI/GeoNature/blob/develop/docs/development.rst

Mais pas encore concernant la création d'un module.
Le module devra avoir son propre schéma dans la BDD, avec ses propres fichiers SQL de création comme le module Contact (OCCTAX) : https://github.com/PnX-SI/GeoNature/tree/develop/data/modules/contact

Côté backend chaque module a aussi son modèle et ses routes : https://github.com/PnX-SI/GeoNature/tree/develop/backend/src/modules/pr_contact

Idem côté FRONT, où chaque module a sa config et ses composants : https://github.com/PnX-SI/GeoNature/tree/develop/backend/src/modules/pr_contact
Mais en pouvant utiliser des composants du CORE comment expliqué dans le début de doc DEVELOPER : https://github.com/PnX-SI/GeoNature/tree/develop/frontend/src/core/GN2Common

[camillemonchicourt]

Concerne la V1. Intégration de modules externes intègrement revue dans la V2.