le templating xml ?
1 « J'aime »
J’amène ma petite pierre… et suis d’accord avec la dernière idée d’html (qui au fond est du xml quand-même…).
J’ai fait ce genre d’exercice pour un export d’un script python vers une impression ‹ propre ›.
La solution a été un une mise en page sans déco en html strict avec balises (ids et classes) bien définis et les décors en pur css pour une mise en page papier. Après l’utilisateur imprime ou sauve en pdf depuis le menu d’impression ou avec un pdf_creator like.
Un avantage étant qu’au pire du pire (en déplacement, sans accès au logiciel), on peut encore changer le contenu ‹ en dur › dans l’html publié sans devoir être une brute en programmation.
Voilà c’étaient mes 2cents…
–
tmaes
Bonjour,
Un petit retour d’expérience puisque j’ai développé il y a quelques années pour un logiciel de compta propriétaire un générateur d’édition basé sur des modèles html.
Par rapport au templating html, il faut pouvoir utiliser des champs de la base de données, des attributs d’objets métiers, et des fonctions (au sens programmatique); par exemple pouvoir dire ici je mets l’adresse du tiers facturé, ou là je mets le prix formaté comme il faut (fonction price).
Ceci est faisable dans un squelette html en définissant une syntaxe spécifique qui devra être connue et respectée par celui qui fait le template, ou bien en utilisant un éditeur wysiwyg dédié qui permettra un ajout simple de ces données.
Pour ma part, j’avais choisi cette dernière option et développé un outil jQuery avec l’éditeur tinyMCE et ses API. Beaucoup de travail pour arriver à quelque chose d’utilisable, et néanmoins pas à la portée de l’utilisateur lambda qui ne maîtrise pas html ni les styles…
Pour la partie génération pdf, il faut avoir conscience que les outils existants de conversion html vers pdf (j’avais choisi html2pdf) ont tous des limitations, que ce soit au niveau des balises et des styles supportés ou au niveau de la gestion des sauts de page; ces limitations doivent être prises en compte par le designer du template ou de l’éditeur visuel si cette solution est choisie.
Il y a également parfois des limitations au niveau des performances (dépassements de mémoire allouée, temps de génération du pdf) qui seront moins contraignantes pour une simple facture que pour un grand-livre de plusieurs milliers de page (mais attention à la compta qui arrive dans Dolibarr).
Pour toutes ces raisons, j’ai préféré partir sur les programmes de création pdf utilisés dans Dolibarr, mais en « externalisant » la description des données et de leur forme vers un fichier XML pouvant être par la suite généré via un outil dédié.
Le résultat actuel est prometteur; la description xml est assez facile à manipuler pour des besoins simples; pour des personnalisations évoluées, l’éditeur wysiwyg sera incontournable.
Alors, on en est ou ? 
Ce serait bien que ce sujet ne soit pas abandonné, je pense que c’est même important pour l’évolution de Dolibarr.
Hello christophe tu as pu avancer?
Bonsoir Altatof, Defrance,
où en êtres vous de vos réflexions sur le sujet?
Par avance merci de votre retour.
De mon coté rien n’a bougé puisque que Christophe semblait avoir bien avancé sur le sujet
Mais cela me tente de plus en plus de sortir un myPrint, ne serais-ce pour les clients qui me demandent régulièrement des éditions pdf…
Bonjour,
Je vous annonce la sortie prochaine d’un nouveau module dédié à la personnalisation d’édition : myPrint
Il permettra d’ajouter rapidement des champs sur les éditions (pour le moment propale, commande et factures client et fournisseur) sans avoir de compétences php.
Il devrait être disponible début octobre pour un prix modique (dans la fourchette basse du prix de mes modules)
1 « J'aime »
Bonjour
Juste pour dire que j’ai repris l’étude développement d’un générateur de pdf basé sur une description xml, celui-ci devrait sortir durant le second trimestre au même prix que myprint qui sera proposé à l’intégration au core de dolibarr (V6). A titre d’info mes premiers résultats sont très encourageant tant en terme de résultats que d’interfacage avec dolibarr.
Le plus long dans ce développement n’est pas à proprement parlé le codage du module mais le développement des modèles XML, il est probable qu’au début le module ne contienne que les pièces principales (propales, commande et factures clients) et que je rajoute ensuite les autres documents
Une première version pilote devrait sortir d’ici la fin du mois de mars pour nos partenaires histoire de tester/stabiliser celle-ci, la documentation devrait sortir à ce moment là
1 « J'aime »
Salut Defrance,
Tu veux un coup de main sur la génération des BL au format XML ?
Mon développeur peut apporter sa pierre à l’édifice.
On en aurait besoin pour envoyer à nos clients qu’ils « importent » les produits sur le BL et éviter de se re palucher la saisie des lots/dates de péremption… Et comme je ne veux pas que tu réveilles ton urticaire/allergie, on peut essayer d’y bosser.
Merci de ton retour
Hello Hubz
en fait le module que je développe générera du PDF, pas du XML
mais je trouve cependant l’idée intéressante, il faut que je regarde comment je peux implémenter cet autre mode de génération mais ce sera dans un second temps.
Dans ta vision des choses c’est un xml unique par document? tu prévois de l’envoyer ensuite par mail ou webservice?
D’abord par email,
pour la confirmation de commande, pour les bons d’expédition
Ce sera un xml par objet (expédition SH1702_123456 = 1 xml)
si expé multiple alors 2 ou plus xml à envoyer par mail
et plus tard par webservice si le client en fait la demande, ou si on trouve des clients qui utilisent les websaucisses.
dans customLine tu as déjà une fonction d’import de ligne de pièce (pour le moment propale, commande et facture) à partir d’un csv
je me tate de faire l’export csv et la même avec du xml (import/export).
Dans ce dernier cas le plus fastidieux à coder ce sera le format du xml dans le sens champs et llibellé à envoyer/récupérer dans le xml
Bref, c’est pas le travail qui manque
Euh il semble que le projet est à l’abandon depuis 10ans…
1 « J'aime »
a mon avis il faut abandonner ce chemin xml2pdf (il faut un xslt et un model à implémenter) ça sera vraiment très limiter et peu flexible…
s’orienter au html2pdf c’est plus direct
ou bien faire le chemin suivant : xml2html puis html2pdf (voir lien suivant xml2html)
pour html2pdf il y en a beaucoup de lib qui génèrent d’excellents reports
Rassure-moi c’est une blague …
Tu connais la différence entre le xml et le html?
Les gens comme toi me rassure sur la pérennité de mon activité… tu n’as jamais du mettre les doigts dans du code ou gérer des problématiques d’intégration pour écrire un tel truc
Bonjour
Un test… fait avec dolibarr
La pièce jointe test.png est absente ou indisponible
Fred
1 « J'aime »
Bonjour
La même avec le crabe de dolibarr
La pièce jointe test3.png est absente ou indisponible
Fred
