[2.2.1] Les librairies

[erwan.bodere]

Bonjour,

Dans la version de BIRT que j'utilise (la 2.2.1), il y a une notion de librairies. Ces librairies permettent de créer des composants de rapport, des datasources, des datasets, des styles réutilisables.

Dans mon projet, j'ai un nombre important de requêtes SQL (data set) de de rapports à développer. Je voudrais structurer au mieux ces éléments pour qu'ils soient facilement retrouvables et (re)utilisables.

Comment peut-on organiser les datasets ? Une première solution serait de créer des répertoires dans la rubrique Data Sets de la librairie mais cette fonctionnalité n'est pas offerte par BIRT. Une seconde solution serait de créer plusieurs librairies :

• une librairie common-lib qui contiendrait les Data Sources, les Styles et les Master Pages
• une librairie par besoin métier qui contiendrait les Data Sets spécifique au métier. Ces librairies seraient dépendantes de la librairie common-lib.

Ainsi, on pourrait créer une organisation hiérarchique des besoins. Seulement cette solution ne semble pas être fonctionnelle. En effet, une librairie peut dépendre d'une autre mais on ne pourra pas directement utiliser les éléments constitutifs de la librairie parente. Il faut importer les éléments que l'on a besoin à partir de la librairie parente. Du coup, si on a besoin de tous les éléments de la librairie parente, on doit tous les importer et donc cela ne sera à rien d'utiliser une structure hiérarchique des librairies.

Avez-vous une idée d'une manière de structurer les librairies de telle sorte que les Data Sets soit facilement identifiable ?

[erwan.bodere]

La solution hiérarchique semblent finalement la bonne :
- je crée un librairie common-lib.rptlibrary contenant les éléments communs (datasources, masterpages, styles et quelques datasets)
- je crée des librairies "enfants" faisant référence à la librairie common-lib. Je ne peut pas créer directement des datasets à partir de la datasource de la librairie common-lib. Il faut au préalable que j'ajoute la datasource de la librairie parente dans la librairie courante.

C'est dommage que l'on ne puisse pas directement utiliser les datasources et/ou les datasets d'autres librairies malgré que l'on ait spécifié que l'on en a besoin. L'idéal serait de pouvoir créer des Data Sets dans une librairie à partir d'une Data Source d'une autre librairie. Cela sera peut-être possible dans une version ultérieure de BIRT.

[erwan.bodere]

Les librairies ne peuvent pas s'utiliser de manière hiérarchique !

J'ai crée une librairie parente : common-lib.rptlibrary. Celle-ci contient la source de données, les styles (css, master page, ...) ainsi que des data sets génériques.

J'ai ensuite crée 2 librairies : chil1-lib.rptlibrary et child2-lib.rptlibrary. Ces librairies font référence à la librairie common-lib pour utiliser la source de données notamment. Dans chaque librairie j'ai crée des data sets.

Je veux créer un rapport utilisant les data sets des différentes librairies mais il impossible de charger plus d'une librairie car il ne peut il y avoir qu'une seule référence à la source de données. Or, j'ai utiliser cette source de données dans chaque librairie.

Cette solution ne semble pas non plus être la bonne ...

[erwan.bodere]

Après pas mal de bidouille, il semblerait que cela soit finalement possible grâce à la notion de namespace. Dès que j'utilise un élément de la librairie common-lib dans une des librairies enfants, je dois modifier le nom de la référence pour la rendre unique. Pour cela, j'ai choisi d'utiliser la syntaxe suivante :

Code :

[librairie-name]@[element-ref-name]

Ainsi, il n'y a plus de problème de doublon. Cependant, cette solution reste une bidouille.

[syllant]

Oui j'ai aussi la même problématique que j'ai résolue comme toi, mais il subsiste encore un problème : image que ta common-lib.rptlibrary inclue une root-common-lib.rptlibrary.

Du coup les composants déclarés dans cette dernières sont importés en double dans chil1-lib.rptlibrary et child2-lib.rptlibrary et ça foire.

Je gère mes datasets dans des lib hiérachiques, avec à la racine une lib avec la datasource, mais ça ne fonctionne pas. J'ai donc dû dupliquer celle-ci sur les racines des branches des datasets (mais je dois de toute façon les remplacer à la volée par API, donc ce n'est pas bloquant dans mon cas).

AMHA, Birt devrait gérer les collisions de namespaces de manière transparente.