Une question sur JODReport - JODConverter

Bonjour, j'aimerais ajouter dans une application la possibilité de générer des rapports à partir de templates crées et uploadés par l'utilisateur , j'ai naturellement pensé à JOD Report, et JOD Converter pour la conversion en .doc ou .pdf. ( et pour pouvoir avoir, j'imagine que converter le fait, des templates éventuellement créés en .doc )

Mais voilà, j'utilise GWT - Google App Engine, et je suis donc bloqué par JOD Converter qui demande une instance de OOo sur le serveur web.

Y'aurait il un moyen de faire sans ? une autre façon de passer de l'odt au .doc ? (ou seulement au pdf à la limite, bien qu'il reste le problème de l'upload des templates, ca m'embête de les restreindre au format odt )

ou d'autres bibliothèques qui gèrent les .doc nativement et font la même chose pourquoi pas.

Autre question, dans mon cas, conseilleriez vous de partir du jar de JOD Report et de l'adjoindre comme une librairie à mon projet ? ou d'utiliser le war et de faire des branchements ?

Bon, désolé de double-poster mais ça fera un up

Je suis tombé sur l'API "Google Documents List Data API", je me disais qu'en effet, le plus simple dans mon cas serait tout simplement de passer par les formats google docs.

Est ce que quelqu'un est familier avec cette API et saurait si elle conviendrait à mes besoins ?

Bonjour!

Ton sujet est intéressant!
Je me demande quelles conventions comptes-tu utiliser pour permettre à tes utilisateurs de créer des champs de fusion.
Surtout si tu veux leurs permettre d'utiliser plusieurs format d'import (tu partais sur odt, si j'ai bien suivi).
Est-ce que tu comptes aller plus loin que la gestion de champ de fusion et gérer le conditionnement d'affichage de certain paragraphes, éléments.
Encore plus loin? Pouvoir gérer un tableau dynamiquement?

Bref, j'ai un projet qui à démarré avec ce genre de contraintes il y a 2 ans et je n'ai pas trouvé de solution libre toute prête où les utilisateurs pouvait créer leur template relativement facilement.
(Sinon, il y avait BIRT, mais il faut installer BIRT designer pour faire des template).

Solution adopté à l'époque, s'appuyer sur le WordML de word 2003 et le pluggin WordXMLToolBox de MS pour associer graphiquement des référence à un XML selon un XSD.
Il a fallut développer des xsl-t de fusion de donnée.
Il existe des xsl-t qui font wordml -> xsl-fo et donc PDF qui était le format de fusion désiré.

J'avoue être passé un peu à coté de JOD Report.
Je serai curieux de voir qu'il est possible de faire et pourquoi pas avec google docs en effet.

Beaucoup de questions pour pas beaucoup de réponses :aie:
Bon courage!

Oui évidemment les champs de fusion sont vraiment au coeur de la problématique, le template est chargé avec des "blancs" (nom, prénom, reste à payer, date... c'est assez générique ) et des requêtes en base de donnée doivent les remplir.

JOD Report semble faire tout ça assez facilement, mais ne prend en entrée/sortie que du odt.

Les google documents eux sont conçus pour avoir n'importe quelle entrée/sortie, mais le gros problèmes, c'est que évidement il n'y a pas deux façons identiques de faire un template, donc j'imagine devoir essayer de trouver la solution la moins bancale possible (par exemple en faisant utiliser des champs du type ${nom} et d'imposer ce format... ) Mais c'est la première fois que je tombe sur aussi peu de documents/infos sur un problème ^^

Sur google, je vois juste que "google data list API" va "seulement" te permettre d'accepter plusieurs types de documents word (doc et odt pour simplifier) et de les convertir vers le format qui te semblera le plus exploitable.
Mais, il ne semble pas y avoir d'API pour manipuler les documents et réaliser la fusion de donnée.
Il y en a une pour les spreadsheets, mais pas pour les doc.

Le moteur/syntaxe de templating que tu décris ressemble à velocity.

Pendant que j'y pense, 2 points qui se révèlent en fin de projet pour moi :
- Lorsque la syntaxe logique est intégrée au document lui même. Il devient difficile d'éliminer complètement les espaces et saut de page qu'on introduit en écrivant une boucle foreach ou qu'on conditionne un paragraphe.
- La gestion des paragraphes solidaire (interdire le saut de page entre 2 paragraphe précis)

bon alors, par rapport à jodreport/jodconverter

jodconverter nécessite un serveur faisant tourner un openoffice, sur lequel il va se connecter pour faire les convertion. Peu de chance d'y échapper. Pour les template, il ne prend que du forma open document (odt, ods, etc), car ces format, xml, sont très simple à gérer pour un moteur de template comme jodreport qui n'a pas besoin de "comprendre" les document pour les transformer, contrairement à ce qui serait nécessaire avec d'autres formats.

Enfin, pour revenir sur la nécessité de open office pour faire les conversion, oui il est nécessaire, mais a moins d'etre chaud chaud coté ressources sur le serveur, je vois pas en quoi c'est un problème, open office est prévu dans son code pour ce genre de pilotage!

Oui, j'arrive aux même conclusions, il me faudrait donc, à tout le moins, un serveur faisant tourner open office en dehors de google app engine

Et si t'as un serveur autant y héberger également ton appli GWT, donc plus vraiment besoin de GAE :aie:.

je suis bien avancé hein ? :p