Idées en vue d'une refactorisation

[elias75015]

Dans ce ticket chapeau, l'idée dans un premier temps est de lister ce qui nous parait améliorable dans le code pour permettre une homogénéisation de la manière de créer un widget.

Dans un second temps, on essayera de décliner les différentes remontées listées ici en sous-tickets au périmètre mieux défini.

A terme, l'objectif est de proposer un protocole de contribution basé sur un workflow bien documenté et éventuellement des templates.

Idées Générales

• Créer un "Core" pour la création du DOM : une bibliothèque de fonctions dans laquelle un contributeur pourrait piocher pour créer son widget.

• Faire la distinction entre plusieurs types de widgets : widget avec formulaire (ex.import de donnéees), widget avec interaction (ex.calcul de distance)

• Homogénéiser les widgets fullCustom et les widgets natifs OpenLayers qu'on surcharge

Incohérences entre widgets

• les options du widgets sont passées à des endroits différents

• des options similaires entre deux widgets ont des nom différents

• la manière d'ajouter des classCSS aux éléments (parfois classList.add(), parfois classList = ".....")

Factorisations possibles

• le constructeur des widgets est souvent surchargé avec les mêmes éléments

• les setters/getter du DOM (ex. setCollapsed, getContainer)

• pour les widgets de calcul/dessin, les méthodes pour récupérer la données (set/get data, set/getgeometry)

• la création du DOM et des listeners sur les boutons (ex. _createShowIsoExclusionsPictoElement = _createShowElevationPathPictoElement = ....)

[IGNFhc]

• Uniformiser et rendre paramétrable les styles (carto et DOM)
• ajouter des méthodes de DOM getter et setter (icone, panel, ....)
• templatiser le DOM
• avoir un modèle de données plus précis (utilisation du Typescript, standardisation des entrées et sortie d’un widget)
• centraliser certaines infos : liste et ordre des couches, objet/layer en interaction sur la carte, interaction entre les widgets (collision, ...)
  par exemple : des méthodes pour fermer tous les widget de la carte
• générateur de widget : quand on veut créer un widget on peut faire npm create widget, ça pose qulques questions et bim. Ya plus qu’à coder fonctionnellement et spécifiquement ce qui s’y passe.
  (un widget à besoin: d’infos de la map / de certaines interactions avec la map / un code spécifique / du dom à peupler en fonction de ces infos)

[elias75015]

Link : #39

[azarz]

Centraliser un maximum de code commun à tous les widgets héritant de ControlExtended dans cette dernière :
Création de l'uuid (#284), getContainer(), etc

[elias75015]

@IGNF/geopf-api

Première réunion du 08/04/2025, liste des tâches pour la prochaine échéance :

-1) faire diagramme UML de l'existant --> Elias
-2) explorer autres API/produits qui existent --> Hector, Amaury, JP
-3) faire nouveau UML -> Hector
-4) lister incohérences syntaxiques -> Elias
-5) définir linter pour refacetorisation -> Elias, Hector

Prochain point le 24/04

[lowzonenose]

Perso, j'aime bien comment est réalisé cette lib UI, elle répond à pas mal de nos besoins
https://github.com/Polydile/dile-components

[elias75015]

Tache 1 : Premier jet à compléter corriger

[elias75015]

geopf_widgets_full_uml.txt

Fichier plant uml en .puml

[elias75015]

geopf_widgets_full_extended_uml.txt

Mise à jour plus complète sur les classes et widgets

[lowzonenose]

Pour info,
Theme, Legend, Layers... sont des classes appelées par Editor.
Seul Editor est un classe de type Control.

La classe Control peut aussi gérer les properties non natives de OpenLayers, ex. position (la fameuse position relative) ou alors une classe Interface pour la position des contrôles...

[IGNFhc]

Bonjour aujourd'hui nous avons décidé d'orienter les prochaines étapes de travail du "DOM core" vers :

• lister des "MapComponents" à développer (par exemple : des panels, des boutons, inputs de coordonées, ....) avec leurs entrées / sorties / méthodes / évenements
• trouver un système de templating satisfaisant
• Réfléchir à la gestion du css (sans doute conserver le fonctionnement actuel à 3fichiers)
• proposition de créer une classe CanvasOMManager pour gérer : les collisions, ouverture, fermeture de panel / infobulles, superposition, placement sur le canvas selon espace dispo (quadrillage, ...), type de dom, .....

Prochaine date : mi juin

[azarz]

Pour un seul dev utilisable dans plusieurs librairies carto, concept d'adapter à creuser comme sur https://github.com/JamesLMilner/terra-draw

[lowzonenose]

yeah, il va falloir apprendre nos design pattern !

[elias75015]

https://github.com/JamesLMilner/terra-draw

[elias75015]

CR rencontre CdB

Fork du projet pour le projet de cartographie des services publics
-> https://github.com/cdebarros/geopf-extensions-openlayers
Page de démo :
-> https://cartosp.modernisation.gouv.fr/

Copiés - collés pour créer le nouveaux widgets.

Gain de temps pour gestion du DSFR et certains widgets clés en main (rechercher par adresse, layerswitcher)
Un template de développement plus visible aurait été utile.
Le Contributing.md est à revoir et mettre à jour.

A court terme : accueiilir les contributions dans un dossier contributions. Ajouter la possibilité de compiler le projet avec ou sans ses contributions. Encore mieux, pouvoir choisir les contributions que l'on veut compiler.

Isochrone surchargé : voir si on peut récupérer les évplutions dans le widget principal.

Attention, les contributions peuvent être au mode DSFR, Classic, ou les deux. Il faudrait trouver un moyen de les documenter (ou de les ranger) correctement pour que ce soit explicite pour l'utilisateur.

[lowzonenose]

Un concept que j'ai mis en place sur le widget Reporting à creuser pour notre refactoring des API
Ioc.pdf

[elias75015]

@IGNFhc 👀

[IGNFhc]

oui j'ai lu le pdf merci JP c'est très instructif