Le résultat obtenu fait tout de suite beaucoup plus professionnel :

J’avais déjà utilisé JFreeChart il y a longtemps… Mais BIRT étant un projet Eclipse sous licences EPL, je l’avais mis depuis longtemps sur ma liste des choses à regarder. Le projet Eclipse BIRT est assez vaste, en fait c’est une solution de Business Intelligence complet qui est comparable à la suite Jaspersoft. Je me concentre ici sur le module Eclipse Charting Engine de BIRT : c’est lui qui dessine les diagrammes et qui est donc plus comparable à JFreeChart.

Finalement, ces librairies fonctionnent de la même manière. Au travers d’une API le modèle du diagramme est défini : le type de diagramme, les différentes séries qui vont être représentées, les éléments graphiques (couleur, légende, titre…).
Pour s’en sortir, rien ne vaut une petite recherche Google pour trouver les extraits de codes qui permettent de partir d’un exemple déjà défini. Je suis surpris de ne pas trouver de galerie présentant les différents types de diagramme (histogramme, diagramme circulaire…). D’autant plus qu’il existe un projet contenant des exemples: org.eclipse.birt.chart.examples

Rapidement j’ai obtenu ce que je souhaitais… La plus grande difficulté concerne les dépendances… En fait le morceau de code que j’avais trouvé marchait bien en Java SE, mais j’ai mis un certain temps à comprendre comment cela fonctionnait dans mon application Eclipse Scout. Sans y faire attention (ayant copié collé du code venant de StackOverflow), j’utilisais le mode STANDALONE de BIRT. Dans une application Eclipse Scout, on est évidemment dans un contexte OSGi.

Aller plus loin :
Pour aller plus loin, il me semble que passer par le champ SVG d’Eclipse Scout n’est pas vraiment une bonne solution. D’après ce que j’ai vu, BIRT dispose de widgets d’affichage pour Swt et Swing. Il serait plus malin d’avoir un ChartField dans Eclispe Scout avec les renderer appropriés.

Une autre réflexion à mener concerne la répartition client server de la logique de diagramme. Il me semble que BIRT propose un découpage plutôt intéressant qu’il serait possible de reprendre en réfléchissant à l’intégration client/serveur.

Au final l’utilisation d’Eclipse BIRT Chart-Engine se révèle être une bonne expérience.

Pour moi, chacune de ces EclipseCon m’a donné la possibilité de rencontrer des gens, de replacer les choses dans leur contexte, de réexpliquer notre projet en partant du début… Voici quelques réflexions que je souhaite partager ici.

A la différence d’autres stands consacrés à la promotion d’outils payants, nous présentons un projet Eclipse. J’ai été surpris de voir qu’il y a toujours de la pédagogie à faire. Un projet Eclipse cela signifie : du code open-source, du code dont la licence permet une réutilisation, y compris dans des projets commerciaux, et enfin du code dont la propriété intellectuelle a été contrôlée. Plusieurs fois les visiteurs du stand n’imaginaient pas qu’ils allaient pouvoir utiliser ce que nous montrons gratuitement, sans aucun engagement. Evidemment mon entreprise propose des préstations commerciales autour des projets Eclipse. Mais ce n’est qu’une possibilité, pas une obligation.

Pour Eclipse scout les signaux sont bons. J’ai présenté ce framework la première fois en 2011 lors d’un Eclipse Day à Paris. A l’époque il fallait beaucoup justifier ce que nous proposions. Même si le projet Scout existe en interne dans notre entreprise depuis plus de 10 ans, passer en open-source c’est se trouver sur la place publique au milieu de tout ce qui existe déjà. Aujourd’hui davantage de gens nous connaissent déjà ou ont envie de savoir qui nous sommes. Nous avons des éléments tangibles pour montrer ce que nous faisons : nos applications de démonstration, notre forum, notre livre à télécharger (voir aussi les premiers retours sur le livre eclipse scout).

Parler avec les visiteurs de la conférence, c’est l’occasion de se (re)définir : nous sommes un framework pour réaliser des applications métiers, avec une architecture client-serveur. Notre force est de ne pas dépendre d’une librairie graphique en particulier, mais de proposer une couche d’abstraction dans laquelle nos formulaires sont définis. Cela permet de suivre les évolutions du marché sans avoir à tout réécrire. Les applications que nous développons avec Eclipse Scout ont un cycle de vie assez long : disons au-delà de 10 ans. Or les librairies graphiques, les plateformes applicatives, les attentes des utilisateurs en termes de charte graphique évoluent. Pouvoir en profiter, en mutualisant les coûts au niveau d’un framework est un avantage. C’est le message que mes collègues ont essayé de faire passer durant leur talk.

Montrer Eclipse Scout c’est l’occasion de redécouvrir ce que nous faisons et ce que nous proposons. Le premier soir j’ai relu mes articles de 2011 sur ce blog. Beaucoup de choses sont toujours valables. De plus à l’époque j’avais une vision neuve du projet. Les applications Eclipse Scout disposent par défaut de plusieurs éléments vraiment intéressants pour les utilisateurs finaux. Par exemple toutes les tables qui affichent des données peuvent être réorganisées par les utilisateurs (tri multiple, filtre, ordre des colonnes…). Il est facile d’y brancher un export vers Excel. Les champs de saisie disposent de nombreuses petites fonctionnalités qui facilitent le travail au quotidien. Ce sont des avantages indéniables pour les utilisateurs des applications réalisées avec Eclipse Scout. Cela leur facilite la vie dans leur travail quotidien. Sans Eclipse Scout, ce sont autant de choses qu’il faudrait redévelopper à chaque fois.

Un dernier très bon moment de ce dernier EclipseCon en Allemagne : mon interview avec InfoQ France… Une vidéo devait bientôt être mise en ligne.

Je n’ai pas résisté à l’envie de mettre quelques photos :

C’est une possibilité de plus qui confirme la stratégie multi front-end d’Eclipse Scout. En effet la même application peut-être rendue sous différente forme : application desktop, application web et maintenant application web mobile.

Depuis toujours, une idée principale d’Eclipse Scout consiste en une surcouche pour définir l’application qui soit indépendante de toute librairie graphique (SWT ou Swing). Les formulaires ainsi que les champs qu’ils contiennent sont définis dans un modèle d’application qui sera rendu sous forme d’interface graphique à l’exécution. Cette technique permet d’obtenir plusieurs déclinaisons de la même application :

Version SWT :

Version Swing :

Version web :

Le mobile étant une plateforme différente, il a fallu ajouter une étape supplémentaire lors du rendu. Les composants sont adaptés pour tenir compte des spécifiés de la plateforme. Voici quelques exemples :

Smartfield :

Le smartfield est un champ assez puissant : à la manière d’un combo-box, il permet de choisir parmi plusieurs choix. Il est également possible de saisir du texte dans le champ pour réduire les choix proposés. En version mobile, pour reproduire toutes ces possibilités, il a fallu ajouter une vue annexe sur la droite.

Absence de menu contextuel :

L’action proposée dans le menu contextuel apparait sous forme de bouton sous la table.

Représentation des tableaux :

La largeur offerte par le téléphone est limitée. La hauteur des lignes d’un tableau doit être suffisante pour permettre une sélection avec le doigt « sélection touch ». Du coup, les colonnes d’un tableau sont rassemblées sous forme de lignes dans une cellule plus haute. Les colonnes d’une ligne du tableau vont être représentées dans un formulaire annexe accessible en sélectionnant une cellule dans la liste mobile.

L’action principale du menu contextuel (celle qui aurait été proposée en double cliquant sur la ligne du tableau) et qui correspond souvent à l’opération d’édition se retrouve déportée en haut à droite. Les opérations restantes sont disponibles dans un menu supplémentaire.

Masquer certaines fonctionnalités :

Toutes les fonctionnalités ne font pas forcément sens sur mobile. Pour mon application, j’ai décidé de masquer la représentation sous forme graphique (déjà rudimentaire dans la version desktop) en supprimant l’onglet correspondant.

En conclusion

Cette transformation du modèle applicatif permet d’adapter le rendu web aux spécificités du mobile. Évidement l’application obtenue n’est pas aussi efficace qu’un développement dédié, mais le résultat est plus que convainquant par rapport au temps investi.