PnX-SI / gn_module_import

Module GeoNature d'import de données
7 stars 11 forks source link

Revoir export PDF des rapports d'import #398

Open camillemonchicourt opened 2 years ago

camillemonchicourt commented 2 years ago

Voir https://github.com/PnX-SI/gn_module_import/pull/295#issue-1165347848

En lien avec https://github.com/PnX-SI/GeoNature/pull/1303, même si ça ne sera certainement pas la solution retenue.

Mais de la même manière il est souhaité améliorer et simplifier la génération des graphiques et cartes dans les exports PDF des JDD. Donc à mettre en cohérence avec les exports PDF des imports.

Gaetanbrl commented 1 year ago

Ref https://github.com/PnX-SI/GeoNature-atlas/issues/168

Des technos full client side :

pierrejego commented 1 year ago

Juste des notes d'une première analyse

Je ne connais pas toutes les fonctionnalités de geonature et des ces modules.

Est-ce que la génération de PDF est toujours quelques choses venant de l'IHM ? ou est-ce qu'il y a des cas ou l'on peut télécharger un pdf qui n'afficherait pas que des données affichées côté client ?

Je n'ai pas réussi à trouver de cas d'export PDF avec une carte, je dois pas avoir les bonnes données de test sur notre serveur ou sur celui de démo geonature.

Le code développé actuellement utilise weasyprint qui fonctionne très bien, et en plus utilise déjà la notion de template ( pour l'instant un seul disponible, mais simple a étendre) et en plus tire parti du render Flask .

Weasyprint est connu pour utiliser énormément de mémoire, mais uniquement lorsqu'on a un un gros HTML, en tout cas dans les tests fait sur les métadata sur notre plateforme, aucun pic de mémoire n'est visible.

On pourrait modifier https://github.com/PnX-SI/GeoNature/blob/master/backend/geonature/utils/filemanager.py#L92 pour générer le PDF sans dépot sur le serveur ( pour éviter les soucis d'export de pdf en même temps) avec un BytesIO ou un StringIO et faire une réponse

response = make_response(binary_pdf) response.headers['Content-Type'] = 'application/pdf' response.headers['Content-Disposition'] = \ 'inline; filename=%s.pdf' % 'yourfilename'

ou générer le pdf avec un filename + timestamp ( encore plus simple )

Côté backend en java on utilise très souvent FOP avec des templates XML. ça existe aussi en python, https://pypi.org/project/pypfop/ mais cela va nécessiter de créer un modèle de données compréhensible par le backend et des routes de générations de graphs et d'images de carte

Pour aller vers une simplification de la génération, c'est vrai qu'un passage en full frontend serait un plus, mais il y a toujours la problématique de la carte leaflet, en utilisant le canvas ça ne devrait pas poser de soucis pour la génération du pdf, (Et les graphs aussi peuvent passer en canvas.) par contre il faut gérer la partie template.

Si on veut un template facilement modifiable, je pense qu'il faut qu'il reste au moins une route côté backend pour le récupérer, ce qui permettrait en plus lors de l'appel de choisir quel template on veut utiliser.

Mais pour le rerender des variables dans le template ça va être peut être plus compliqué ou limité côté client. Il faudrait directement créer le template côté client, mais dans ces cas la il n'est plus personnalisable facilement.