ACube. Normes de développement Jasper. Version 1.1 du 22/02/2010. Etat : Validé

(1)

ACube

Normes de développement Jasper

Version 1.1 du 22/02/2010 Etat : Validé

(2)

Version 1.1 du 22/02/2010 / Etat : Validé Page 2/8

Cette création est mise à disposition selon le Contrat Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à l'Identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

S UIVI DES MODIFICATIONS

Version Rédaction Description Vérification Date

1.0 A. Lesuffleur Initialisation 27/08/09

D OCUMENTS DE REFERENCE

Version Titre

(3)

S OMMAIRE

1 I

NTRODUCTION

... 4

2 P

RESENTATION DE

J

ASPERREPORT

... 5

2.1 Présentation général ... 5

3 N

ORMES

J

ASPER

... 6

3.1 Nommage et localisation ... 6

3.2 Rapports, Performance et Mémoire ... 6

3.3 Livraison des rapports ... 6

3.4 Scriplets ... 6

3.5 Eléments prohibés ... 6

3.5.1 Fragment de code Java ... 6

3.5.2 Accès aux données... 7

4 M

ETHODOLOGIE

... 8

4.1 Architecture projet ... 8

4.2 Les objets javabeans ... 8

4.3 Les interfaces de services... 8

4.4 Les classes de tests ... 8

F IGURES

Figure 1 : Cycle de vie d'un rapport Jasper ... 5

D OCUMENTS DE REFERENCE

Version Titre

(4)

1 1 I I NT N TR RO OD D UC U CT T IO I ON N

Ce document présente les normes et méthodologies à appliquer dans les projets lors de l’utilisation de Jasper Report.

(5)

2 2 P P RE R ES SE EN NT TA AT TI IO ON N D D E E J J AS A SP PE ER RR RE EP P OR O RT T

2.1 P RESENTATION GENERAL

Jasperreport est un Framework java open source permettant de générer des rapports d’états à partir d’une source de données. Les rapports peuvent être générés dans les formats suivant : xml, pdf, txt, xls, rtf, html et csv.

Jasperreport est le remplaçant de FOP pour LISE V3, il est à utiliser dans le même cadre que FOP.

Pour réaliser une génération d’un rapport, il faut :

• Réaliser le document jrxml qui est la description du rapport au format XML (JRXML),

• Définir la source de données : base de données, fichier XML, objets JAVABeans …

• Compiler le rapport jrxml pour obtenir le rapport compilé « .jasper »

Figure 1 : Cycle de vie d'un rapport Jasper

(6)

3 3 N N OR O RM ME ES S J J AS A SP PE ER R

3.1 N OMMAGE ET LOCALISATION

Les sources des rapports (jrxml) sont à placer dans un package jasper au même niveau que le répertoire src contenant les sources java.

Les règles de nommages des rapports sont similaires aux règles java et les rapports doivent respectés le découpage fonctionnel java.

Par contre, en raison d’un dysfonctionnement jasper, les rapports compilés (fichier jasper) doivent se trouver dans un sous répertoire des sources java appelé src/acube/projet/export/jasper/report/<DOMAINE FONCTIONEL/…)

3.2 R APPORTS , P ERFORMANCE ET M EMOIRE

Les rapports de plus de 5 pages doivent être identifiés en amont de la réalisation et signalés aux équipes transverses afin de prévenir les cas de non performance ou de consommation mémoire excessive.

Les rapports volumineux avec graphiques doivent être employés avec précaution : ils sont potentiellement consommateur en CPU et en RAM.

3.3 L IVRAISON DES RAPPORTS

Le code source des rapports doit impérativement être livré avec le code source de l’application (fichier jrxml) Les rapports doivent être compilées lors de la construction du livrable (jrxml -> jasper).

3.4 S CRIPLETS

L’utilisation et la création de scriplet pour un rapport doivent être soumises à l’autorisation préalable des équipes transverses (comme les taglibs jsp).

3.5 E LEMENTS PROHIBES

3.5.1F

RAGMENT DE CODE

J

AVA

L’utilisation de code pseudo-java ou java est possible dans jasper, notamment pour les structures conditionnelles.

L’utilisation de code pseudo-java ou java interdite dans les rapports, les règles de gestion et le formatage doivent être fait dans des V.O. ou classes utilitaires.

Pour illustration, voici un exemple de code java « à la jasper » : ( $F{matrRegNaEpx} != null

?

($F{matrPaysNaEpx} != null

? $F{matrRegNaEpx} + "( " + $F{matrPaysNaEpx} + " )"

: $F{matrRegNaEpx}) : ( $F{matrArrondNaEpx} != null

? ( $F{matrDeptNaEpx} != null

? $F{matrArrondNaEpx}.toString() + "( " +

$F{matrDeptNaEpx}.toString() + " )"

(7)

: $F{matrArrondNaEpx}) : "")

)

3.5.2A

CCES AUX DONNEES

Aucun accès à une source de données, SQL ou autre, ne doit avoir lieu dans un rapport jasper.

(8)

4 4 M M E E TH T HO OD D OL O LO OG GI IE E 4.1 A RCHITECTURE PROJET

Classe à implémenter pour le maquettage du rapport:

• Un Javabean de présentation permet d’alimenter le rapport

• Une interface du service pour récupérer les Javabeans nécessaires à un rapport.

• Une classe de test qui implémente l’interface du service avec les méthodes statiques pour y accéder à partir d’Ireport

Classe à implémenter pour le rapport final:

• Un Javabean de présentation permet d’alimenter le rapport

• Une interface du service pour récupérer les Javabeans nécessaires à un rapport.

• Une classe de test qui implémente l’interface du service avec les méthodes statiques pour y accéder à partir d’Ireport

• Une classe service pour instancier les JavaBeans à partir des BO ou à partir de la base de données

• Une classe Action struts pour rendre disponible le fichier généré

4.2 L ES OBJETS JAVABEANS

• Les formatages doivent être fait dans cet objet et non dans le rapport jasper.

• Il faut au minimum un JavaBean par sous-rapport

•

4.3 L ES INTERFACES DE SERVICES

• Il faut au minimum une méthode par JavaBean qui retourne une liste de ce type dans le but de pouvoir générer unitairement les sous-rapports.

•

4.4 L ES CLASSES DE TESTS

• Elle implémente l’interface service

•