Version pré-buildée du frontend

camillemonchicourt commented 4 years ago

Actuellement lors de l'installation de GeoNature, il faut builder le frontend. Idem à chaque fois que l'on modifie de GeoNature ou d'un de ses modules. Cela est lourd et source d'erreurs.

C'est pourquoi il a été retenu de fournir GeoNature avec son frontend déjà buildé pour ne pas avoir à le faire lors de l'installation. La méthode de gestion de la configuration a aussi été revue pour ne pas nécessiter de rebuild pour prendre en compte ses modifications.

Une conséquence est que l'on n'aura plus de surcouche de style en SCSS, mais uniquement en CSS.

Autre conséquence, on n'aura plus qu'une seule commande de mise à jour de la configuration de GeoNature et de ses modules, et non plus une par module. La configuration de GeoNature inclura dynamiquement dans un seul fichier la configuration du cœur et des éventuels modules externes.

On garde cependant la nécessité de rebuilder le frontend quand on installe un module externe (sinon trop complexe et tordu de l'intégrer dans l'application Angular GeoNature)

Travail en cours dans la branche dédiée : https://github.com/PnX-SI/GeoNature/commits/feat/ngx-config

TheoLechemia commented 4 years ago

NB: à l'installation l'utilisateur n'embarque plus tout l’environnement de développement frontend (Angular CLI, nvm, npm, node etc...). L'installation de cet environnement nécessaire à l’installation de nouveaux module a été intégré dans un script séparé: install_dev_dependencies.sh

joelclems commented 3 years ago

J'ai repris les travaux effectués dans feat/ngx-config pour repartir sur une nouvelle branche feat/config

https://github.com/PnX-SI/GeoNature/commit/d85bb616a9c3d4d963fc29266ade6e4779b3b470

Li'dée est de ne plus avoir à relancer le build après un changement de paramêtre des fichiers toml voir meme de ne plus relancer l'appli (ce qui marche tant qu'on ne change pas le paramètre API_ENDPOINT.

La gestion de la config se fait de la manière suivante:

Au demarrage de l'appli on crée deux fichier api.config.json qui contiennent la valeur de API_ENDPOINT: l'url de 'lapi deGeoNature:
- frontend/src/assets/config/api.config.json
- frontend/dist/assets/config/api.config.json
Au demarrage du frontend, le service de config charge la config en deux temps:
- réquête pour récupérer le fichier api.config.json et la valeur de API_ENDPOINT
- réquête à l'api <API_ENPOINT>/gn_commons/frontend_config pour réupérer toute la config
- contient la config des modules
- la configuration est relue depuis les fichiers toml (application et modules) et mise à jour pour l'appli
- MISE A JOUR POUR LES MODULES A FAIRE???
- les valeurs de la config sont accessible dans le code du frontend grace au service de config:
- ts : this._configService.getSettings('MAPCONFIG.CENTER')
- html : <p>API_ENDPOINT : {{'API_ENDPOINT' | config}}</p>

A l'heure de ce post j'ai pu tester de changer l'emprise de la carte et de voir le changement près avoir rafraichi le navigateur.

bouttier commented 3 years ago

Super feature ! C’est super cool de ne pas avoir à rebuilder le front lors d’un changement de 2, 3 paramètres de config … J’ai fais 2 commentaires :

il faut relancer le backend
générer le fichier api.config.json par une commande geonature (pour simplifier, on pourrait avoir une unique commande geonature qui met à jour api.config.json / tsconfig / tsconfig_app / modules routes, bref tous les fichiers autogénéré du frontend nécessitant un rebuild)

joelclems commented 3 years ago

une commande (et une fonction) unique pour ce qui c'est une très idée pour tout ce qui concerne le frontend

est ce qu'on ne peut pas mettre à jour la config de l'appli à la volée

  current_app.config.update(nouvelle_config)

à voir comment traiter les changements de config pour les MAILS la BDD ???

joelclems commented 3 years ago

J'ai un peu avancé sur ce volet,

backend: ajout d'options reload et reload-extra-file à gunicorn pour relancer automatiquement le backend en cas de changement des fichiers toml, et des fichiers custom
frontend: le changement de config se voit au rechargement de la page
le rebuild du frontend est nécessaire seulement en cas d'ajout d'un module
la configuration des modules est placé dans le dossier GeoNature/config (par ex GeoNature/config/occtax_config.toml)
passage en css pour le style

TheoLechemia commented 3 years ago

La config des modules dans le coeur est un lien symbolique ?

joelclems commented 3 years ago

tu veux dire pour occtax, occhab, validation? ils sont écrit directement dans GeoNature/config je n'ai pas fait de liens symbolique

les autres (par ex synthese) restent dans geonature_config.toml

TheoLechemia commented 3 years ago

Non de ça:

la configuration des modules est placé dans le dossier GeoNature/config (par ex GeoNature/config/occtax_config.toml)

joelclems commented 3 years ago

Ce n'est pas un lien symbolique et ce n'est pas automatique, je l'ai mis dans les notes de version il faut déplacer et renommer les fichiers

TheoLechemia commented 3 years ago

Pourquoi on ne va pas plutôt lire les fichiers de conf dans le répertoire des modules ?Le chemin est connu du coeur, on peut donc facilement le trouver

joelclems commented 3 years ago

je trouvais ça commode d'avoir toute la conf dans le meme dossier

pour le chemin de la config des modules j'ai fait une fonction qui dépend de module_code https://github.com/PnX-SI/GeoNature/blob/c45c6bf48fb0fc07faa213960fc86b22b04e6b74/backend/geonature/utils/env.py#L55-L56

camillemonchicourt commented 3 years ago

Oui ça ne me semble pas souhaitable de déplacer les config des modules dans un dossier centralisé.

joelclems commented 3 years ago

je trouvais ça commode d'avoir toute la config au même endroit. le fichiers de conf ne se trouve plus dans les modules

camillemonchicourt commented 3 years ago

C'est peut-être plus simple pour les utilisateurs en effet. Mais est-ce vraiment compatible et cohérent avec la logique de modules qui sont autonome dans leur propre dossier ?

joelclems commented 3 years ago

ce sont des fichiers non commités, l'emplacement n'est pas très important, du moment que geonature sais ou les trouver.

le seul probleme qui se poserait serait en cas de changement de module_code, mais c'est en général une constante forte du module

TheoLechemia commented 3 years ago

Ce que je ne comprend pas, c'est comment les modules vont venir mettre leur fichier de conf dans le coeur. La commande d'installation fait ça ?

joelclems commented 3 years ago

oui c'est ça, la fonction conf_gn_module_path(module_code) me donne l'emplacement du fichier de config et je m'en sert pour l'écrire ou pourle lire

PnX-SI / GeoNature

Version pré-buildée du frontend #879