comment reprendre des éléments du module monitoring sans dupliquer le code ?

[Amegilla]

Suite à la remarque de Camille M., : Il y a notamment un point important de vigilance. Si il semble possible de réutiliser pas mal d'éléments du module Monitoring, alors il faudrait dupliquer le moins de code possible, voir aucun. Mais à voir comment.

J'ouvre ce ticket pour explorer les solutions techniques.

Personnellement je ne vois pas trop comment faire car le module monitoring est optionnel et donc pas toujours installé sur une instance GeoNature. Et j'imagine qu'il n'est pas pertinent de migrer de nombreux éléments de ce module dans le coeur de GeoNature. Ou bien, on peut imaginer que le module CMR serait dépendant du module monitoring ?

à vos idées...

[camillemonchicourt]

Je n'y vois pas clair techniquement sur le sujet. Le module MONITORING a vocation a intégré le coeur de GeoNature car générique et transversal. Mais ce n'est pas encore le cas, car il est encore jeune.

A voir si @joelclems ou @amandine-sahl ont des pistes ?

[joelclems]

C'est pas une question facile, il faut prendre en compte les contraintes de chacun et le travail déjà effectué.

Et effet il y a des points communs et des chose à factoriser.

Je ne sais pas si le module cmr part du module monitoring ou s'il est complétement différent.

De ce que j'ai vu de la démo du module cmr, il y a beaucoup de chose intéressantes à reprendre pour le module monitoring.

• possiblité d'agencer différemment les tableau, les carte selon les objets
• les formulaires en modal
• les pages de détails

Mais j'imagine que la priorité pour GeoFit de rendre un travail fini dans un temps donné.

Je donnerai pour le module monitoring la priorité d'ếtre le plus générique possible et au module CMR la priorité d'être plus spécifique.

Au cours des développements on pourra toujours échanger et voir comment l'avancée d'un module peut profiter à l'autre, ou bien identifer des besoins communs.

Par exemple, je pense qu'il reste un gros travail à effectuer sur le composant dynamic form:

• pouvoir spécifier l'agencement des formulaires (ligne colonne ou plus complexe)
• améliorer le composant datalist
  • autocomplete
  • pouvoir l'afficher en bootstrap pour être raccord avec le reste
  • améliorer les définitions dynamique (le fait par exemple de cacher / afficher un composant du formulaire selon les valeurs du formulaire (comme pour les medias par exemple)
• organiser les formulaire en accordéon comme c'est fait pour le module cmr ou on peut cacher/afficher les partie concernant les détails.
• améliorer et compléter le travail effectué pour avoir les listes d'objets dans les formulaire (encore avec datalist)
  • avoir une liste de liste, de groupe de site, d'individus etc....
  • pouvoir avoir à coté de la liste un boutton ajouter un objet (un peu comme pour la saisie des individus depuis les observations) Le fait de pouvoir filtrer les données des liste par rapport aux JDD auquels a accès l'utilisateur (en faire une options du module??) peut être utile aux deux modules.

Il faut identifier quels sont les développement qui peuvent au final être placés dans le coeur et profiter à tous le reste de GN.

Le bémol c'est qu'on est beaucoup moins souple sur le développement et un peu tributaire de la sortie des release de GéoNature.

[FlorentRICHARD44]

Pour donner quelques infos sur mon développement:

• j'ai fait un fork de ce repository gn_module_cmr sur mon Github, en créant un branche "geofit/cmr_cistude". Le code est disponible ici https://github.com/FlorentRICHARD44/gn_module_cmr/tree/geofit/cmr_cistude
• je suis donc plutôt reparti d'une "feuille blanche" que du module monitoring (même si j'ai gardé quelques éléments qui étaient déjà dans le module CMR).

Le module monitoring est très générique (même vue quelque soit l'objet site/visite/observation). Mon idée pour ce module CMR est qu'il doit permettre des variantes à chaque objet => comportement plus spécifique, affichages de détails différents (les détails d'un individu par exemple sont très différents des autres objets et nécessitent une répartition différente dans l'écran). Je suis parti sur 1 écran = 1 composant (c'est assez basique je le reconnais, mais je n'ai pas assez d'expérience en Angular pour faire beaucoup mieux pour l'instant). Je fais dans chaque composant un comportement spécifique, et une fois que j'aurais abouti à un fonctionnement assez complet, je suis sur qu'il y aura des éléments que je pourrais factoriser à l'intérieur du module CMR dans un premier temps, et éventuellement dans le coeur de GeoNature par la suite. Côté backend, c'est déjà plus factorisé, mais il y a encore un peu de factorisation à faire et certains éléments qui devront rester très spécifiques (requêtes avec certains comptages par exemple).

J'ai gardé certaines fonctionnalités comme dans le monitoring: par exemple tous les formulaires, liste de propriétés affichées, colonnes des tableaux sont tous configurables en json (dossier "generic" + dossier par sous-module). Pour les formulaires en accordéon, je ne l'ai mis que pour les observations (le seul endroit où cela est nécessaire je pense), j'ai tout simplement créé des groupes de champs dans le json. Chaque groupe a un label, un état ouvert/fermé par défaut et une liste de champs. (c'est tout frais donc je dois encore l'améliorer et vérifier). J'ai également prévu de regarder les possibilités d'interaction entre champs dynamiques: enable/disable, show/hide, valeurs par défaut (pour recopie de date par exemple) ou des min/max de date (date de relâché supérieure ou égale à date de capture). Surement pas de solution simple, mais c'est nettement mieux pour l'expérience utilisateur.

Je n'ai pas encore vu cette partie, mais le script d'ajout de sous-module est certainement factorisable entre monitoring et CMR.

[joelclems]

Pour la partie champs dynamiques, j'ai un gros travail de documentation à faire mais on peux échanger dessus si tu veux.

Les groupes de formulaire c'est quelques chose que j'aimerai bien mettre en place pour les formulaires dynamique, avec des possiblilités de mettre des titres, d'afficher les composant en ligne ou de faire des accordéons.

Je publirai un issue sur les formulaire dans GéoNature

[camillemonchicourt]

Il a finalement été retenu d'individu le concept d'individu dans le module Monitoring : https://github.com/PnX-SI/gn_module_monitoring/issues/213