Discussion :

[Yehohanan82]

Bonjour,

Lorsque l'on exporte son rapport en XLS, selon la structure de l'entete et pied de page définit dans le master page, celui-ci est soit inséré dans la feuille de calcul, soit mappé sur l'entête et pied de page excel. Jusque là tout va bien.

Un petit saut dans le code source de BIRT (2.5.2) nous donne les conditions pour apparaitre dans l'entete et pied de page excel :
- Dimension de la grille : 1 ligne et 3 colonnes max ;
- pas d'html ;
- pas de grille imbriquée ;

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
		public boolean needOutputInMasterPage( IContent headerFooter )
	{
		if ( headerFooter != null )
		{
			Collection list = headerFooter.getChildren( );
			Iterator iter = list.iterator( );
			while ( iter.hasNext( ) )
			{
				Object child = iter.next( );
				if ( child instanceof ITableContent )
				{
					int columncount = ( (ITableContent) child ).getColumnCount( );
					int rowcount = ( (ITableContent) child ).getChildren( ).size( );
					if ( columncount > 3 || rowcount > 1 )
					{
						logger.log(Level.WARNING,"Excel page header or footer only accept a table no more than 1 row and 3 columns." );
						return false;
					}
					if ( isEmbededTable( (ITableContent) child ) )
					{
						logger.log( Level.WARNING,"Excel page header and footer don't support embeded grid." );
						return false;
					}
    			}
				if ( isHtmlText( child ) )
				{
					logger.log( Level.WARNING,"Excel page header and footer don't support html text." );
					return false;
				}
			}
		}
		return true;
	}

OK jusque là c'est compréhensible ; BIRT mappe chaque cellule de la grille dans une zone de l'entete (ou pied de page) excel. Pour info, l'entete (ou pied de page) excel prévoit 3 zones éditables : gauche, centre, droite de tailles identiques.

En résumé, en théorie, il suffit donc de placer une grille de taille 1 x 3 dans l'entete et pied de page du master page de BIRT et d'insérer les valeurs qui vont bien dans la bonne cellule. La première cellule pour la zone de gauche. La deuxième cellule pour la zone du centre et la troisième cellule pour la zone de droite.

Néanmoins, même en respectant ces consignes, toutes les valeurs atterissent dans la zone du centre.

Hors si l'on regarde le code, on voit que BIRT prévoit bien la possibilité de choisir sa zone :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
	public String getRowValue( IRowContent row )
	{
		StringBuffer rowValue = new StringBuffer( );
		Collection list = row.getChildren( );
		Iterator iter = list.iterator( );
		int cellCount = list.size( );
		int currentCellCount = 0;
		while ( iter.hasNext( ) )
		{
			currentCellCount++;
			Object child = iter.next( );
			switch ( currentCellCount )
			{
				case 1 :
					rowValue.append( "&L" );
					break;
				case 2 :
					rowValue.append( "&C" );
					break;
				case 3 :
					rowValue.append( "&R" );
					break;
				default :
					break;
			}
			rowValue.append( getCellValue( (ICellContent) child ) );
		}
		return rowValue.toString( );
	}

Ce qui génère ceci par exemple :

Code Xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
<Header x:Data="&amp;LNom Prénom&amp;CMon Rapport&amp;Rune date"/>
<Footer x:Data="&amp;LGénéré le: une date&amp;CMon Rapport&amp;R© TOTO Cie"/>

Le problème vient du fait que les codes en "&X" ne semblent pas bon. En effet, si l'on modifie manuellement l'entête et pied de page du fichier excel depuis excel, on obtient ceci :

Code Xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
<Header x:Data="&amp;ENom Prénom&amp;CMon Rapport&amp;Dune date"/>
<Footer x:Data="&amp;EGénéré le: une date&amp;CMon Rapport&amp;D© TOTO Cie"/>

La différence, c'est le code en "&X".

&L devient &E ;
&C reste &C ;
&R devient &D ;

Ma question est donc la suivante : s'agit-il d'un bogue (les mauvais codes ont été utilisés par les équipes de développement) ou ces codes là sont-ils dépendant de la version excel, du pays ou de je ne sais quel autre paramètre propre à la configuration de la machine cliente ?

Pour info je teste avec Excel 2003 sur un PC en france.

Merci. En espérant que quelqu'un ait une idée ou que Stefan pourra poser la question aux Labs.

[Stefan C]

En effet , ca parait pas normal. Vous avez essayé avec l'émitter Excel commercial?

Pourriez vous ouvrir un cas sous Buzgilla et nous donner ici le lien svp?

Je vais me mettre dans le thread.

Sinon , en effet , nos emitters sont localisés , donc dépendants de la locale.

[Yehohanan82]

Le bug est créé : https://bugs.eclipse.org/bugs/show_bug.cgi?id=317993

J'espère que ce que j'ai écrit en anglais est compréhensible

Je n'ai pas encore eu le temps de tester l'emitter professionnel. Ma connexion étant ce qu'elle est, il me faut un certain temps pour télécharger la beta d'Actuate 11.

[Yehohanan82]

Bon, je ne sais pas si c'est ce que tu entendais par "emitter commercial" mais j'ai téléchargé et installé Actuate 11 (beta). J'ai rajouté un rapport simpliste avec un entete.

Au final, les rapports excel exportés avec Actuate 11 n'ont pas le bogue mais en revanche ils sont générés au format binaire. Ce n'est donc pas la même chose.

[Stefan C]

C'est bien ça.

Et oui c'est format binaire pour plusieurs raisons :

1. Taille du fichier généré.
2. Support de "vrais" Objets Excel comme Charts , Tableaux Pivots , Formules etc.
3. Vitesse de génération.
4. Compatibilité Open Office.

[Yehohanan82]

J'ai intégré le spreadsheet engine and api dans ma webapp et j'ai tester une génération.

Dans l'entête j'ai utilisé &E, &C et &D (codes qui fonctionnent dans excel).

Dans le pied de page, j'ai utilisé &L, &C et &R (codes birt).

Seul le pied de page est interprété correctement.

J'en déduis donc que les codes utilisés dans BIRT sont des codes propriétaires compréhensibles et interprétables par le moteur Spreadsheet mais pas par Excel directement.

Voilà peut-être l'explication. Il s'agirait alors d'un bogue.

[Stefan C]

Petite clarification :

1. L'emitter Excel BIRT Open source est développé par Innovent Solutions. Nous essayons depuis un moment de les remplacer , mais malgré les nombreux avantages du consortium Eclipse , il existent qq inconvénients... et nous ne sommes pas particulièrement heureux du format XML pour Office choisi et ses bugs / ennuis.

2. L'emitter Excel BIRT Actuate est bien propriétaire. Idem pour BIRT Spreadsheet. Attention d'ailleurs , si l'API Spreadsheet est gratuite, le engine est payant. C'est vraiment pas cher , mais pas gratuit non plus

[Yehohanan82]

Oui je suis au courant de ces différences. Merci pour le rappel néanmoins.

En l'état, je n'ai pas très envie de modifier le code source de l'emitter si je peux faire autrement. L'achat du module SpreadSheet est une éventualité en cours d'examen mais elle n'est pas prioritaire car en plus du coût, si je ne m'abuse, elle oblige la création d'un template spécifique pour l'excel. Pour chaque rapport, il faudra donc développer deux templates : l'un pour excel avec le Spreadsheet Designer, l'autre pour les autres formats avec Eclipse BIRT.

Je pensais peut-être placer les bons codes directement dans le texte de la cellule mais comme il ne faut les afficher que pour l'excel, il faut pouvoir filtrer sur le format directement dans l'expression javascript. Malheureusement je n'arrive pas à obtenir le format courant via l'API javascript.

De fait, j'ai rajouté un "Label" qui ne contient que le code Excel dans chaque zone de l'entête/pied-de-page. Label que je n'affiche que pour l'Excel.

Je n'ai pas trouvé mieux pour l'instant. Bien sûr si quelqu'un a une meilleure idée, je suis preneur

[Stefan C]

Je cite "Bon, je ne sais pas si c'est ce que tu entendais par "emitter commercial" mais j'ai téléchargé et installé Actuate 11 (beta). J'ai rajouté un rapport simpliste avec un entete.

Au final, les rapports excel exportés avec Actuate 11 n'ont pas le bogue mais en revanche ils sont générés au format binaire. Ce n'est donc pas la même chose. "

Si je comprends bien Actuate BIRT v11 donne entière satisfaction sauf pour le format binaire?

[Yehohanan82]

Eh bien surement mais pour avoir l'emitter excel commercial, il faut acheter un iServer ? La solution la moins chère reste donc le Spreadsheet Engine ?

[BiM]

Pour l'histoire du format de sortie, quand je fais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

reportContext.getOutputFormat()

dans n'importe quel endroit du rapport, j'ai bien le format de sortie demandé (html, pdf, xls, etc.)

[Stefan C]

Cela dépend de ce que l'on nomme 'cher' et pour quel type d'usage.

Pour les OEM ( partenaires technologiques qui embarquent nos solutions ) le mode 'composant' comme le Spreadsheet engine ou même le BIRT engine V11 est disponible.

Pour les clients "directs" , il faut passer par iServer ( Express ou Enterprise en fonction de la charge attendue ou d'autres besoins plus BI que reporting ).

[Yehohanan82]

Pour l'histoire du format de sortie, quand je fais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

reportContext.getOutputFormat()

dans n'importe quel endroit du rapport, j'ai bien le format de sortie demandé (html, pdf, xls, etc.)

Est-ce que cela fonctionne également avec la servlet "frameset" et l'utilisation d'un "__document" ?

Merci.

[Yehohanan82]

Cela dépend de ce que l'on nomme 'cher' et pour quel type d'usage.

Pour les OEM ( partenaires technologiques qui embarquent nos solutions ) le mode 'composant' comme le Spreadsheet engine ou même le BIRT engine V11 est disponible.

Pour les clients "directs" , il faut passer par iServer ( Express ou Enterprise en fonction de la charge attendue ou d'autres besoins plus BI que reporting ).

OK merci pour le détail.

[Stefan C]

Ca fonctionne avec les 2 normalement.

La conversion Excel est faite au niveau du render ( donc à partir du document ).

[BiM]

Est-ce que cela fonctionne également avec la servlet "frameset" et l'utilisation d'un "__document" ?

Merci.

Ca fonctionne avec les 2 normalement.

La conversion Excel est faite au niveau du render ( donc à partir du document ).

Je confirme ce que dit Stefan. La transformation vers un format se fait à partir du rptdocument si on passe par un document.

Voir http://www.developpez.net/forums/d48...t/#post5179050.

[Yehohanan82]

Merci pour tes essais BiM, j'ai également retenté ma chance de mon côté, et ça ne fonctionne pas, j'obtiens toujours "pdf".

J'ai essayé tout un tas de choses. Il en ressort hormis mon bogue personnel avec "getOutputFormat" que la gestion des entêtes et pied de page est quand même pas mal boggué dans Birt Open Source à ce jour.

<VALUE-OF>totalPage</VALUE-OF> ne marche pas comme expliqué dans ce bogue : https://bugs.eclipse.org/bugs/show_bug.cgi?id=215231. Obligation de passer par l'AutoText qui fonctionne bien et reste quand même maléable puisqu'il est possible de fixer une taille en pourcentage pour certainnes colonnes de la grille ("le / par exemple), la taille des autres colonnes étant calculée dynamiquement.

L'utilisation séparé de l'AutoText "Total Page Count" ne marche pas dans excel car cela génère le mauvais code excel également. Génération de &N (équivalent &[Fichier] pour l'utilisateur) au lieu de &T (équivalent de &[Pages] pour l'utilisateur). Je me demande quand même si ces codes ne sont pas dépendants de la locale. Je trouve étrange qu'ils aient laissé passé ça chez Innovent Solutions même si leur emitter n'est pas parfait. C'est un peu gros quand même. Dommage que je n'ai pas un excel anglophone.

Du coup, pour gérer le nombre de pages, j'ai refait pareil : un Label spécial excel avec les codes excels et un Label pour tout le reste avec l'AutoText.

Autre bogue mais pour l'emitter powerpoint cette fois, le nombre total de pages n'apparait pas. Pas encore investigué.