Ci joint un guide d'utilisation de JasperReports/iReport.

Merci d'avance pour vos remarques sur ce document.

Merci pour cette réponse.

Je rebondis sur quelques points :

- Temps d'apprentissage de iReport : celui ci n'est pas négligeable, la génération d'un premier rapport peut demander du temps, mais cela est surtout lié à l'appréhension des concepts de JasperReports plutôt qu'a l'outil iReport, lui-même plutôt instinctif. Une fois les concepts de JasperReports assimilés, le gain de productivité me semble important. Un guide d'utilisation de JasperReports/iReport est en cours de réalisation au MAE.

- datasources : comme précisé, la connexion direct du rapport à la base de données est contraire aux principes ACube, même si JasperReports le permet. On privilégiera les datasources sous forme de collection d'objets Java, objets pouvant être des instances des VO du projet, ou de JavaBeans dédiés au rapport.

- consommation mémoire : dans ces cas très particulier de graphiques (puisque selon les tests c'est la partie graphique qui poserait problème) sur des grosses quantités de données, on pourrait imaginer que le travail sur les données pourrait être réalisé en amont par le code Java pour fournir au rapport directement les valeurs à afficher.

JasperReport en tant que solution de remplacement à xsl :fo me semble également intéressante, mais il faudrait étudier les limites en terme de fonctionnalité, de gain de productivité (éditeur wysiwyg certes mais bon…) et de performance (temps de génération, occupation mémoire) sur des documents de complexités différentes.

* fonctionnalités :
JasperReport est avant-tout spécialisé dans la restitution d’états, et ne semble pas à priori aussi polyvalent que xsl :fo. Une connaissance des limites fonctionnelles de l’outil semble indispensable. Comme JasperReport est un générateur d’état, un rapport ne permet de représenter qu’une collection de données (sous forme de tableau ou graphique). Mais les sous-rapports permettent visiblement de créer des documents plus complexes contenant plusieurs paragraphes et plusieurs tableaux, à étudier…
Par contre les tableaux avec regroupement sont plus simples à réaliser qu’avec xsl :fo.
-Les scriplets sont plus puissantes que les fonctions XSLT (le formatage des données peut être fait intégralement dans le rapport)

* Productivité :
-IReport semble intéressant permet-il de gérer toutes les fonctionnalités de jasper ? Quelle est le temps d’apprentissage ?
Il existe un outil similaire pour xsl :fo disponible ici foa.sourceforge.net, mais la dernière release date de 2003…

-Les controles plus stricts que xsl :fo : contrôle de correspondance entre champ du rapport et datasource, typage de donnée… ce qui permet de débugger rapidement son rapport.

- Avec son système de datasource, il est possible de générer un rapport en connexion directe au SGBD. Cependant ce n’est pas compatible avec une architecture 3-tiers Acube car une couche métier doit exister entre le SGBD et la couche présentation (indépendance des données).

* Performances :

-On peut créer ses propres datasource, par exemple pour de gros documents, on peut imaginer une datasource récupérant les données par blocs.
-La virtualisation de la mémoire permet d’éviter les OutOfMemory (au détriment du temps de génération).
-Par contre j’ai repris le projet d’exemple en augmentant la taille des données : 1000 programmes et implantation. Résultat : OutOfMemory. La virtualisation ne change rien… Le responsable semble être le sous-rapport contenant les graphiques jfreechart. JFreechart semble très consommateur donc, et la virtualisation ne semble pas avoir d’effet…
-Sinon l’inclusion des numéros de pages ne semblent pas poser de problèmes de mémoire sur ce test (comme c’est souvent le cas pour Xsl :fo)
- Enfin par rapport à xsl :fo, il n’y a pas de phase de transformation des données en XML, d’où un gain en mémoire. Par contre il existe un flux intermédiaire où les données sont fusionnées au modèle. A voir l’impact de ce flux sur la mémoire.