Généricité / Ajouter de nouveaux protocoles spécifiques about geonature HOT 7 CLOSED

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)

from geonature.

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.

from geonature.

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.

from geonature.

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

from geonature.

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

from geonature.

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

from geonature.

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

from geonature.