Closed Amegilla closed 1 week ago
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 ?
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.
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:
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.
Pour donner quelques infos sur mon développement:
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.
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
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
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...