Je pense qu'on s'est rencontrés aux JDLL. Merci d'être passé à notre stand :-)
Merci pour ce retour d'expérience. C'est toujours intéressant de savoir que l'outil sur lequel on bosse est utile, et quels problèmes on peut rencontrer avec. On prend note !
Pour la génération PDF multi page, en effet ce n'est pas une fonctionnalité de base et l'extension qui servait à ça n'est plus maintenue. Une manière classique de faire est de créer une nouvelle page et d'utiliser la macro include pour inclure les différentes pages dedans, avec des sauts de pages entre (ce qui peut se faire avec la propriété CSS break-after).
Ça peut aussi, comme tu le mentionnes (tu sais déjà mais je développe pour les lecteurs et les lectrices du site), se scripter en Velocity, qui est effectivement un langage de template assez puissant et avec lequel on peut accéder à l'API publique d'XWiki et faire pas mal de choses. Ou en Groovy. Ça permet d'utiliser des boucles pour ne pas avoir à de payer l'inclusion manuelle de dizaines de pages si effectivement il y en a beaucoup. Ou d'automatiser, par exemple, la création de pages, ce qui peut se faire en quelques lignes :
Tout ceci étant dit, j'ai partagé ton article dans le chat de l'équipe, on me souffle à l'oreille que tu pourrais être intéressé par nos derniers développements en matière d'export PDF. On te recontacte.
Concernant le déplacement de pages, ça se fait aisément avec la fonction de renommage. Mais effectivement, si l'application stocke des métadonnées dans la page (Pour celles et ceux qui ne connaissant pas, dans XWiki, on peut définir des classes, et il est possible d'attacher des objets qui sont des instances de ces classes à des pages XWiki), ça va tout casser, un peut comme vous casseriez une application de bureau en déplaçant ses fichiers de configurations.
J'imagine qu'une des solutions possibles pour avoir le contenu ailleurs serait là aussi d'utiliser la macro include sur la page où on veut voir le contenu, ou de le scripter en Velocity / Groovy. Mais on est d'accord, parfois, c'est tout aussi voir plus simple de le faire manuellement, surtout quand c'est une opération one-shot qui ne concerne pas un volume énorme de données.
En tout cas il ne faut pas hésiter à nous faire d'autres retours ou nous poser des questions. On a aussi un canal #xwiki public sur Matrix (en anglais).
# Merci pour le retour
Posté par raphj (site web personnel) . En réponse à la dépêche Utiliser XWiki pour générer une documentation logicielle en PDF. Évalué à 10. Dernière modification le 01 juillet 2022 à 09:47.
Je pense qu'on s'est rencontrés aux JDLL. Merci d'être passé à notre stand :-)
Merci pour ce retour d'expérience. C'est toujours intéressant de savoir que l'outil sur lequel on bosse est utile, et quels problèmes on peut rencontrer avec. On prend note !
Pour la génération PDF multi page, en effet ce n'est pas une fonctionnalité de base et l'extension qui servait à ça n'est plus maintenue. Une manière classique de faire est de créer une nouvelle page et d'utiliser la macro
includepour inclure les différentes pages dedans, avec des sauts de pages entre (ce qui peut se faire avec la propriété CSS break-after).Ça peut aussi, comme tu le mentionnes (tu sais déjà mais je développe pour les lecteurs et les lectrices du site), se scripter en Velocity, qui est effectivement un langage de template assez puissant et avec lequel on peut accéder à l'API publique d'XWiki et faire pas mal de choses. Ou en Groovy. Ça permet d'utiliser des boucles pour ne pas avoir à de payer l'inclusion manuelle de dizaines de pages si effectivement il y en a beaucoup. Ou d'automatiser, par exemple, la création de pages, ce qui peut se faire en quelques lignes :
Tout ceci étant dit, j'ai partagé ton article dans le chat de l'équipe, on me souffle à l'oreille que tu pourrais être intéressé par nos derniers développements en matière d'export PDF. On te recontacte.
Concernant le déplacement de pages, ça se fait aisément avec la fonction de renommage. Mais effectivement, si l'application stocke des métadonnées dans la page (Pour celles et ceux qui ne connaissant pas, dans XWiki, on peut définir des classes, et il est possible d'attacher des objets qui sont des instances de ces classes à des pages XWiki), ça va tout casser, un peut comme vous casseriez une application de bureau en déplaçant ses fichiers de configurations.
J'imagine qu'une des solutions possibles pour avoir le contenu ailleurs serait là aussi d'utiliser la macro
includesur la page où on veut voir le contenu, ou de le scripter en Velocity / Groovy. Mais on est d'accord, parfois, c'est tout aussi voir plus simple de le faire manuellement, surtout quand c'est une opération one-shot qui ne concerne pas un volume énorme de données.En tout cas il ne faut pas hésiter à nous faire d'autres retours ou nous poser des questions. On a aussi un canal
#xwikipublic sur Matrix (en anglais).