[2.2.2] Propriété "visibility" - composant exécuté ou non ?

**erwan.bodere** · 15/07/2008, 15h51

Bonjour à tous,

Savez-vous si, lorsque l'on attribue la propriété "visibility" d'un composant à 'vrai', le composant est exécuté puis caché ou si ce composant est caché sans jamais être exécuté ?

D'avance merci.

Erwan

**BiM** · 15/07/2008, 15h52

Bonjour,

Il me semble que c'est executé si nécéssaire. Par exemple, si on réappelle l'objet à un autre endroit du rapport.

**Stefan C** · 15/07/2008, 16h08

A ma connaissance , il est executé ( 2.2.2 ). Ce type de composant est surtout destiné pour la personnalisation du rapport par un end - user via un front AJAX ( de type Actuate Interactive Viewer par exemple ) . L'utilisateur , via un treeview des composants , fait son "shoppping" afin de customiser son rapport.

Il faut faire une distinction entre RunAndRender ( création du rptdocument à partir de rptdesign et optionnellement rptlibrary , fichiers resources/config etc. ET render = affichage )

C'est un simple constat , le Run , ensuite le Render c'est plus performant , le RunAndRender existe ( du point de vue Actuate ) principalement pour le preview ( le Viewer dans le Designer ) .

Le Render n'exécute pas les parties "Visibility" false. Si l'utilisateur modifie cette propriété , alors il peut les exécuter.

A vérifier dans la 2.3 , j'ai pas fait le tour dans toutes les améliorations.

A votre dispo si c'est pas assez clair

**erwan.bodere** · 15/07/2008, 16h27

C'est un peu embêtant :

J'ai un rapport (quasi)générique me permettant de restituer l'activité d'un ensemble d'individus mais selon la localité géographique j'affiche telle ou telle carte (image PNG), tel ou tel tableau. Par conséquent, mes rapports sont hyper longs à être générés.

J'utilise également des composants "temporaires" que je cache et dont j'ai besoin qu'il soient exécutés.

Ne faudrait-il pas ajouter une propriété "executable" dans l'onglet "visibility" pour permettre ou non l'exécution de certains blocs ?

Erwan

**erwan.bodere** · 16/07/2008, 09h17

Qu'en pensez-vous ?

Faut-il que je fasse un telle demande d'évolution auprès de bugzilla ?

**BiM** · 16/07/2008, 09h25

As-tu essayé de voir s'ils s'éxecutaient ?

**erwan.bodere** · 16/07/2008, 11h19

Oui, ils s'exécutent.

Un exemple simple :

- ajouter un dynamic text ayant pour valeur "maVar = 15;" et rendre ce composant invisible
- ajouter un second dynamic text ayant pour valeur "maVar + 1".

Le résultat affiché sera 16.

Code :

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
 
<?xml version="1.0" encoding="UTF-8"?>
<report xmlns="http://www.eclipse.org/birt/2005/design" version="3.2.15" id="1">
    <page-setup>
        <simple-master-page name="Simple MasterPage" id="2"/>
    </page-setup>
    <body>
        <text-data id="6">
            <list-property name="visibility">
                <structure>
                    <property name="format">all</property>
                    <expression name="valueExpr">true</expression>
                </structure>
            </list-property>
            <expression name="valueExpr">maVar = 15;</expression>
            <property name="contentType">html</property>
        </text-data>
        <text-data id="7">
            <expression name="valueExpr">maVar + 1</expression>
            <property name="contentType">html</property>
        </text-data>
    </body>
</report>

**erwan.bodere** · 17/07/2008, 10h18

Pas d'avis ?

**Stefan C** · 17/07/2008, 11h14

Pourquoi ne pas utiliser des Rapport liés?

Le rapport no1 fera les calculs et détérminera le contexte ensuite "appelera" un 2e rapport en lui passant les paramètres.

le 2e étant contextuel résout un peu le problème de génération de TOUT.

**erwan.bodere** · 17/07/2008, 11h53

cucubau123, pourquoi multiplier les rapports quand on peut en faire qu'un. Il est plus facile de maintenir un seul rapport. Tant que BIRT ne gérera pas correctement les sous-rapports (avoir un composant subreport) c'est le seul moyen possible.

Ceci dit, ta réponse ne répond pas à mon problème. Je vais reformuler ma question :

J'ai un "gros" rapport quasi-générique. Il est quasi-générique car il persiste certaines spécificités selon les valeurs des paramètres de rapports. En effet, comme je l'ai expliqué, suivant la zone géographique traitée au sein du rapport je dois restituer des composants (tableaux, images, ...) voir des pages en plus ou en moins.

Mon problème est que la propriété "visbility" masque l'affichage des composants pour lesquels on a fixé la valeur a "true", ce qui est parfaitement logique, mais cela n'empêche pas l'exécution des composants (on l'a bien vu avec l'exemple fourni précédemment). Par conséquent, BIRT va charger/exécuter l'intégralité des composants qu'ils soient invisble ou visible, ce qui a pour effet de ralentir la génération des rapports.

Ne serait-il pas judicieux de proposer une propriété "executable" permettant d'éviter de charger/exécuter les composants rendus invisible ?

**Stefan C** · 17/07/2008, 12h08

Mieux expliqué , mieux compris. Judicieux , ça dépend.

Cas 1 : ton cas : c'est judicieux.

Cas 2 : Utilisation de Interactive Viewing : c'est plus rapide si c'est prégénéré. donc pas judicieux.

L'idée d'un paramètre de "bascule" : TRES judicieux.

Je vais donc poser la question aux labs.

RAJOUT : Question envoyée à BIRT Experts Actuate. A priori les subreports ne font pas partie des priorités , justement à cause du drill down particulièrement développé.

**erwan.bodere** · 17/07/2008, 12h11

Merci

Sais-tu si un composant "subreport" est prévu dans des futures versions de BIRT ?

**Stefan C** · 18/07/2008, 11h59

Sur le subreport , un peu calme plat en ce moment.

Sinon , j'ai trouvé une approche pour ton problème , mais un peu compliquée.

Les labs m'indiquent que tu peux vérifier la propriété "visibility" par un script dans le Rapport , ensuite appeler BIRT Design Engine API pour virer le composant du design avant exécution.

Tu trouveras ça sous le nom de DE API. Voici un lien vers la Doc. Tu trouveras toutes les doc open-source , API , et Actuate à ce lien.

http://www.birt-exchange.com/modules...-designers.php

**erwan.bodere** · 22/07/2008, 14h42

Merci cucubau123 mais ta solution ne fonctionnera pas car j'ai hélas parfois besoin de rendre invisible certains composants pour initialiser des variables javascript par exemple.

Je vais faire une demande auprès de bugzilla.

**BiM** · 22/07/2008, 14h54

Bonjour,

C'est justement ce qu'il est en train de te dire.

Tu mets tout mais avant l'exécution tu supprimes carrément les éléments qui ne doivent pas être exécutés.

Les autres que tu veux exécuté mais ne pas rendre visible restent dans le rapport avec la propriété hidden à vrai.

**erwan.bodere** · 22/07/2008, 15h10

Et pour les utilisateurs utilisant le BIRT viewer ?

Il n'y a actuellement aucune propriété native permettant de ne pas exécuter des composants invisibles. Il faut donc passer par une bidouille. Pour le moment, je peux m'en satisfaire mais je pense qu'il faudrait peut-être ajouter une propriété supplémentaire dans les prochaines versions de BIRT afin de faciliter la création de rapports, surtout pour les non-développeurs.

**erwan.bodere** · 04/08/2008, 10h22

J'ai posté une demande d'évolution sous Bugzilla dont voici le lien : https://bugs.eclipse.org/bugs/show_bug.cgi?id=243035

**Fendal** · 11/08/2008, 04h06

Envoyé par cucubau123

Pourquoi ne pas utiliser des Rapport liés?

Le rapport no1 fera les calculs et détérminera le contexte ensuite "appelera" un 2e rapport en lui passant les paramètres.

le 2e étant contextuel résout un peu le problème de génération de TOUT.

Bonjour,
cette méthode permettrait-elle de simuler le comportement d'un sous-rapport ?
Par exemple, avec du code javascript dans un rapport, peut-on appeler un rapport contextuel et ensuite l'inclure dans le rapport principal à l'endroit voulu ? Ou bien il s'agit simplement de créer un rapport qui collecte et calcule des paramètres et qui appelle un autre rapport complet totalement distinct en lui passant ces paramètres ?

Ayant moi aussi ce problème avec la visibilité, j'ai essayé de parcourir la documentation DE API pour justement avoir accès à la "bidouille" en question pour supprimer ou ajouter un composant. Mais étant débutant dans le domaine j'ai un peu de mal à comprendre le fonctionnement. Peut-on trouver des exemples sur lesquels s'inspirer ?

Merci.

**Stefan C** · 11/08/2008, 10h26

Bonjour,

L'approche drill n'est pas un sous rapport. ça permet d'obtenir le même comportement mais SANS inclure le 2e rapport dans le 1er.

BIRT voit les sous rapports comme des composants. Vous pouvez développer des sous-rapports comme des composants Grid dans une rptlibrary. Ensuite les inclure dans le rapport et jouer sur les paramètres afin de séléctionner dynamiquement les Grids à inclure. Comme BIRT c'est du XML , vous pouvez faire un peu d'AJAX afin de modifier les tags XML correspondants , ensuite passer le rptdesign à l'engine pour avoir les résultats.

Le DE API , c'est vraiment si vous voulez inclure le tout dans une appli J2EE. Voici un lien vers la documentation :

http://www.birt-exchange.com/documen...api/index.html

En gros , vérifier la propriété Visibility de chaque objet dans la liste de vos composants selon vos règles métier, et supprimer ou non le composant du rptdesign.

Si je ne suis pas assez clair , merci d'insister sur les points "flous"

**Fendal** · 12/08/2008, 15h30

Merci pour toutes ces explications, la situation est beaucoup plus claire pour moi maintenant ! Par contre aucune des deux solutions n'est envisageable dans mon cas, que ce soit le drill ou la DE API, cela ne me convient pas pour palier à ce problème de visibilité ...

Par contre la solution de l'inclusion dynamique des grids à partir des librairies en fonction des paramètres pourrait peut être me permettre de résoudre mon problème en attendant l'option exécutable. Serait-t il possible d'avoir quelques détails ou de la documentation sur cette fonctionnalité et sur la marche à suivre pour la réaliser ?

Merci.

[2.2.2] Propriété "visibility" - composant exécuté ou non ?

BIRT

Discussions similaires

Partager

Partager