Sortie de LOTemplate V2

Posté par  . Édité par Benoît Sibaud, Xavier Teyssier, Pierre Jarillon et Arkem. Modéré par bobble bubble. Licence CC By‑SA.
Étiquettes :
26
23
mai
2025
Technologie

Pour les lecteurs pressés retenez que LA grande nouveauté de la V2 est la gestion des calc (xlsx, ods,…)

Pour rappel : LOTemplate est un générateur de documents sous licence AGPL v3 qui permet de créer des documents (ODT, DOCX, ODS, XLSX, PDF, …) à partir d'un document modèle office et d'un fichier json pour les données. Cela devrait intéresser toute personnes qui a déjà essayé de générer du doc/odt ou excel/calc à partir de son code.
Logo LOTemplate

LOTemplate offre des caractéristiques permettant une intégration simple dans tout projet et permettre la gestion de modèle de document a partir de modèle office :

  • Les modèles sont au format bureautique (ods,odt, docx, xlsx, … )
  • Les modèle peuvent avoir des structures complexes (variables, boucle, conditions, compteurs, html,…)
  • L'outil peut scanner le modèle pour extraire la feuille de variables
  • L'outil peut être appelé par une API, une CLI ou un module Python.
  • L'outil utilise un LibreOffice headless pour remplir les modèles donc 100% compatible avec Libreoffice.
  • Les formats de sortie sont tous les formats pris en charge par LibreOffice (docx, xlsx, pdf, odt, ods, texte, rtf, html, etc.).

Intégrer LOTemplate c'est permettre à un utilisateur lambda de partir de ses documents office pour intégrer ses modèles dans l’application sans avoir à maîtriser des technologies spécifiques et complexes.

Pour aller plus loin vous trouverez dans la documentation :

  • deux schémas qui expliquent le fonctionnement de Lotemplate (schema)
  • un exemple d’utilisation très parlant dans la doc ;
  • des exemples dans les tests unitaires.

Et surtout n’hésitez pas à l’utiliser, faire vos retours et bien sûr contribuer.

Aller plus loin

  • # Texte riche ?

    Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-1).

    J'avais commencé à travailler sur un tel sujet, le truc sur lequel je bloquait était l'intégration de texte riche genre à base de HTML.

    Est-ce que LOTemplate le supporte ?

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Memory

    Posté par  . Évalué à 5 (+3/-0).

    Y'a environ 25 ans, j'avais fait la même chose avec Microsoft Office en utilisant OLE Automation.

    Je posais des signets partout dans le doc où je voulais injecter de la donnée, j'avais un fichier CSV avec les données, et un autre fichier qui disait comment lire le fichier CSV, et où mettre les données dans le document word. Tout écrit en Delphi, avec cependant un peu de macros VBA pour les cas où il fallait trifouiller les entrailles de Word ou d'Excel.

    C'était pas vraiment headless, et ça pouvait tourner sur une workstation où on pouvait voir tout ça bouger tout seul - ça faisait flipper le métier. Ca plantait à tout bout de champ (la légendaire stabilité de Word 97) et quand ça plantait pas tout seul, un utilisateur qui passait par là touchait au clavier et ça partait en sucette. Je me suis vu passer une nuit devant la machine parce qu'on avait 2000 rapport de ~30 pages à produire, et qu'il fallait relancer à la main tous les 150 rapports.

    Sans essayer LOTemplate, je peux déjà prédire que ça marche bien mieux que mon truc :-).

    Par contre, à chaque fois qu'on m'a présenté un outil avec l'accroche "vous verrez le métier se débrouillera tout seul", ça s'est transformé en "l'IT fait tout, et le métier se contente de valider". BusinessObjects, SpotFire, PowerBI… Toujours la même histoire. Et quand on trouve un power user capable d'effectivement faire une partie du taf, et ben on doit tout casser au moment où on fait la plomberie.

    • [^] # Re: Memory

      Posté par  . Évalué à 5 (+4/-0). Dernière modification le 23 mai 2025 à 19:28.

      Je suis d'accord avec toi.

      Lotemplate n'est pas un outil du style "vous verrez le métier se débrouillera tout seul"

      Même si effectivement, il peut y avoir une ambiguïté si l'on lit vite la phrase de la dépêche.

      Intégrer LOTemplate c'est permettre à un utilisateur lambda de partir de ses documents
      office pour intégrer ses modèles dans l’application sans avoir à maîtriser des
      technologies spécifiques et complexes.

      Du coup, ta remarque me permet de clarifier pour ceux que cela intéresse.

      L'intégration de Lotemplate dans une solution ou un logiciel permet l'utilisation de documents office comme modèle pour générer des (ODT, DOCX, ODS, XLSX, PDF, …).

      Et aussi étonnant que cela puisse paraître, cela reste une vraie gageure de générer des PDF ou doc office au sein d'une solution web.

      En plus, si on a plein de modèle qui doivent s'adapter régulièrement à une évolution du besoin ou une nouvelle charte graphique, cela peut vite devenir un casse tête pour les développeurs sur un sujet qui n'est souvent pas le plus intéressant techniquement.

      C'est là que Lotemplate peut intervenir en permettant de ne pas être dépendant des développeurs pour faire évoluer ou créer de nouveaux modèles.

    • [^] # Re: Memory

      Posté par  . Évalué à 4 (+2/-0).

      Par contre, à chaque fois qu'on m'a présenté un outil avec l'accroche "vous verrez le métier se débrouillera tout seul", ça s'est transformé en "l'IT fait tout, et le métier se contente de valider"

      Tellement vrai

      Et tu te retrouves à devoir travailler avec des solutions "low code" qui soit-disant "empower le user", que le métier à choisi et qu'il t'impose.

  • # Comparatif

    Posté par  . Évalué à 3 (+2/-0).

    Cela semble effectivement intéressant.

    Tu sais quelles sont les principales différences par rapport à relatorio https://relatorio.readthedocs.io ?

    • [^] # Re: Comparatif

      Posté par  (site web personnel, Mastodon) . Évalué à 8 (+6/-0).

      Disclosure: Je suis une des mainteneurs de Relatorio

      De ce que je comprends, une différence importante est que LOTemplate a besoin de données statiques (un JSON) alors que Relatorio est une librairie qui peut être appelée sur des données qui seront chargées à la demande (par exemple d'un ORM).
      Et une autre est que Relatorio n'a pas besoin d'une connexion à LibreOffice pour faire le rendu du template. D'ailleurs on publie une image Docker pour pouvoir faire uniquement la conversion en PDF sur un service externe.

    • [^] # Re: Comparatif

      Posté par  . Évalué à 6 (+5/-0).

      Je précise que je maintiens Lotemplate donc je vais surtout parler des plus de LOTemplate de mon point de vue.

      Comme résumé par cedrickrier

      Relatorio dézippe et édite les xlm constituant les documents openoffice alors que LOTemplate fais tourner un libreoffice en headless (sans interface graphique).

      Ce choix technique induit du coup plein de différence :

      1. LOTemplate peut lire tous les formats que lit LibreOffice (doc, docx, xlsx, …), de même pour l'export cela offre plein de possibilité

      2. LOTemplate permet l'intégration de texte riche à base de HTML

      3. Pour l'export PDF, les documents étant convertis par LibreOffice, l'ensemble des champs dynamique et formule de LibreOffice sont fonctionnels (ex: Numéro de page, champs dynamique, formule, …)

      4. LOTemplate a son propre langage de templating en essayant de garder le document office lisible, relatorio s'appuie sur Genshi. La différence apparaît clairement sur les documents calc (LOTemplate , relatorio)

      • [^] # Re: Comparatif

        Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

        Avec relatorio, les champs dynamiques sont aussi opérationnelle car LibreOffice les met à jour à l'ouverture.

        Il est vrai que l'inclusion de texte au format HTML est une fonctionnalité qui manque à relatorio. On aimerait avoir un XSLT pour convertir le HTML en ODF: https://bugs.tryton.org/2068

        • [^] # Re: Comparatif

          Posté par  . Évalué à 2 (+1/-0).

          Vrai pour ta réponse

          Mais dans ma remarque, je parlais de l'ensemble des champs dynamique et formule de LibreOffice dans le cadre de l'export PDF.

          Donc dans le cas où on utilise un odt, ods, docx, xlxs pour générer un pdf.

          Sauf erreur (ce qui est possible), relatorio ne le fais pas tout seul, il faut soit utiliser unoserver ou unoconv qui eux lance un libreoffice en headless in fine

  • # for

    Posté par  . Évalué à 3 (+1/-0).

    super idée.

    j'avais fait bricolé un outil similaire avec jinja. Avantage, facile à câbler ; Inconvénient, ce n'est pas utilisable par un non technicien.

    je cherchais l'indispensable boucle for, j'ai trouvé:

    [for $tutu]

    et les data 

    {
  "tutu": {
    "type": "array",
    "value": [
      {
        ...
      },
      {
        ...
      }
    ]
  }
}

    Outre le nom de variable peu inspiré, pourquoi ne pas avoir une syntaxe

    [for person in persons et une data 

    {
  "persons": [
    {
      ...
    },
    {
      ...
    }
  ]
}

    Je trouve le nécessité d'ajouter type : array redondante avec le type json déjà explicité par []. Et la nécessité implicite d'avoir un champ value source d'erreur, contraignante et ajoutant un niveau hiérarchique supplémentaire inutile dans les données.

  • # Sans libreoffice

    Posté par  (site web personnel) . Évalué à 4 (+3/-1).

    Si vous recherchez une solution de génération de document sans avoir à dépendre d'un libreoffice ou tout autre logiciel externe et que le Java ne vous fait pas peur : jOpenDocument est votre ami.

    Nous l'avons crée il y a bien longtemps, et avons eu un prix de la part de Sun Microsystems il y a fort longtemps. Le projet est toujours maintenu et est très utilisé (notamment par OpenConcerto).

    • [^] # Re: Sans libreoffice

      Posté par  . Évalué à 1 (+0/-1).

      sans avoir à dépendre d'un libreoffice ou tout autre logiciel externe

      À un moment, il faut bien créer la template, non ?

    • [^] # Re: Sans libreoffice

      Posté par  . Évalué à 4 (+2/-0).

      Pour ma part, je ne suis pas très satisfait de jOpenDocument dans OpenConcerto : substitution silencieuse de polices, un système de marges à gérer à deux endroits (dans le fichier libreoffice et dans un fichier de config textuel, pourquoi ?), un paramètre "zoom" (re-pourquoi ?) réglé par défaut à 85% (re-re-pourquoi ?) à modifier au jugé dans un fichier de config, un système de coupure de bas de page qui n'a pas l'air de faire ce que l'on veut, etc.
      Comme il n'y a pas de documentation précise du fonctionnement de ces fonctionnalités pour l'utilisateur (je parle pas pour le développeur), il est très difficile de comprendre qui fait quoi, et d'arriver au résultat que l'on veut.
      Bref, l'aperçu de mon template OpenConcerto dans LibreOffice n'est jamais le résultat obtenu après la moulinette jOpenDocument. Je me contente du strict minimum en modification, j'espère juste à chaque fois que la mise en page ne pête pas.
      NB : Je suis un utilisateur payant pour les soutenir.

  • # Publipostage

    Posté par  . Évalué à 5 (+3/-0).

    Bonjour,

    Quelle différence avec la fonction de publipostage ? Est-ce qu'on peut faire du publipostage avec LOTemplate mais qu'on ne peut pas faire avec le publipostage tout ce que permet LOTemplate ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.