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 :

En anglais, ce livre donne un bon aperçu des possibilités d’Eclipse scout au travers de deux tutoriaux. Un chapitre est consacré aux outils « Scout SDK » intégrés à Eclipse, qui permettent un accès facile à Eclipse Scout et un développement efficace. Le tout commençant par un chapitre d’introduction donnant en quelques pages une description d’Eclipse Scout et sa philosophie.

J’avais envie de partager quelques notes sur les coulisses de rédaction du livre.

L’infrastructure du livre a été pensée avec les valeurs de l’open source. Le code est sur GitHub, le contenu est au format Creative Commons (CC-BY), les scripts de compilation sont fournis (les livrables sont générés avec LaTeX).

Si durant la phase de rédaction il a eu peu de retours, le fait de « sortir » une première version du livre a fait bouger les choses. Les premières contributions arrivent : certaines personnes souhaitant creuser certains sujets ont posé des questions dans notre forum. D’autres ont ouvert des tickets sur GitHub pour signaler des coquilles de frappe. Enfin les personnes les plus à l’aise avec Git et GitHub ont envoyés des changements par commit git. Ces retours ont de la valeur. Ils améliorent le produit final.

Il s’agit d’une première version. Certaines ambitions ont dû être revues à la baisse pour pouvoir sortir cette version en coïncidence avec le release train Eclipse (Kepler en juin 2013). L’idée est de fixer les bugs sur la version Kepler et d’enrichir le livre dans le courant de l’année pour revenir en juin 2014 avec une version Luna plus étoffée.

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.

Pour mémoire j’avais écrit sur ce blog plusieurs articles autour de ce projet.
* Nouveau avec Indigo : Eclipse Scout
* Quelques points pour mieux comprendre Eclipse Scout
* Eclipse Scout, fait pour les applications d’entreprises ?

C’est pour moi un nouveau défi professionnel. J’ai hâte de pouvoir écrire mes premières contributions (ou de pouvoir commiter celles des contributeurs).

Si tout va bien, mon premier travail devrait être de rendre open-source notre suite de test. Il s’agit également de faire le ménage dans le code, de proposer quelque chose de plus systématique et d’utiliser des technologies standard (JUnit, Maven, …) de manière à se trouver intégrer au build de manière correcte.

Une application Eclipse Scout propose par défaut deux manières de lancer chaque application (le serveur, et chaque client). S’il n’existe côté client, qu’une seule application (reposant sur SWT par exemple), cela fait tout de même 4 lanceurs différents:

Ce mécanisme repose sur les fichiers *.product et n’est pas si difficile à comprendre.

Pour chaque application, Eclipse Scout se propose de définir un fichier product «dev» et un fichier product «prod». Le fichier «dev» est pensé pour l’exécution à partir d’Eclipse. Le fichier «prod» est pensé pour la compilation.

Avec chaque fichier *.product se trouve également le fichier config.ini qui sera utilisé (il est référencé dans le fichier *.product. Le fait qu’il se trouve dans le même dossier est une simple convention).

Même si comme le mentionne l’article de Patrick Paulin il est possible d’utiliser le même fichier pour l’exécution et la compilation, faire la distinction entre les deux apporte plus de flexibilité.

Serveur: Jetty vs war
Dans l’application serveur, le produit «dev» va inclure les composants nécessaires (jetty) pour fonctionner de manière autonome. Le produit «prod» est quant à lui pensé pour un servlet container comme tomcat (on obtiendra un fichier war).

Reglage du port
Bien souvent le port 8080 est occupé par le serveur tomcat. Aussi il peut être pratique de tester son application à partir d’un autre port. Côté serveur, un paramètre dans le fichier config.ini va indiquer à Jetty sur quel port il doit travailler.
Fichier: {{application_scout}}.server/products/development/config.ini

Côté client, un paramètre va indiquer l’url du serveur:
Fichier: {{application_scout}}.client/products/development/config.ini

Il suffit que le client et le serveur soient réglé de manière compatible pour que cela marche sur n’importe quel port. (nb: voir ce commit)

Laisser des placeholders dans le fichier de config
Bien souvent, en tant que devellopeur, il faut laisser des placeholders dans les fichiers de configuration. Au moment de l’installation, ils seront remplacés avec les vraies valeurs (peut-être même de manière différente s’il s’agit d’une installation en production ou sur l’environnement d’intégration).

Pour cela, les fichiers de config «prod» sont génériques et contiennent ces chaines de caractères qui seront remplacées plus tard.

D’autres lanceurs
Il est évidement possible de créer d’autres fichiers. Par exemple, j’ai un fichier *.product pour lancer mon serveur sans base de données. Voir: Un fragment NoDB pour le serveur de mon application Eclipse Scout

Lorsque je suis amené à parler d’Eclipse Scout, je commence toujours par dire qu’Eclipse Scout ne répond pas à tous les besoins. C’est un point crucial, car selon moi, il faut bien avoir compris ce que le projet propose pour pouvoir en évaluer la pertinence pour soi-même.

Il ne faut pas survendre le framework, mais parler de ses qualités en expliquant ses limites. Dans ce billet, j’ai essayé de m’intéresser à différents points en pensant aux entreprises.

Uniformité du fonctionnement de l’application.

Eclipse Scout se concentre sur les applications métiers. Les besoins de ce type d’application sont limités. On se trouve face à des listes de données représentant des entités avec une certaine dépendance entre elles. La plupart du temps, ces données doivent pouvoir être éditées. Enfin on souhaite pouvoir compléter ces données avec des éléments graphiques (diagramme…).

De ce point de vue, la liberté offerte par la plateforme Eclipse (RCP ou maintenant e4) est trop grande :
l’expérience utilisateur va dépendre de ce que les développeurs auront défini. Sur un gros projet, cette liberté aura pour effet de ne pas proposer d’expérience uniforme sur l’ensemble de l’application.

En se focalisant sur les besoins des applications métier, des choix ont été faits dans Eclipse Scout. Ils limitent les possibilités pour le développeur, mais garantissent l’uniformité de l’application.

Avec un framework, tout le monde travaille de la même manière.

Un framework comme Eclipse Scout force les développeurs à coder de la même manière. L’architecture est prédéfinie par les outils du SDK. Il n’y a pas de questions à se poser : les règles de validation métier vont à un endroit, le code de persistance des données se retrouve à un autre endroit et ainsi de suite.

Avantage certain pour une entreprise avec plusieurs projets fondés sur le même framework : un développeur s’y retrouve très vite. S’il débute sur le projet, il va être très vite opérationnel. S’il intervient en tant qu’expert, il saura où chercher et comment s’y retrouver.

Dans une application RCP plus classique, l’organisation cohérente du code n’est pas impossible, mais elle dépend de la volonté de l’équipe (et du temps qui y est consacré).

Le modèle d’application : une garantie de pérennité.

Avoir un modèle d’application (indépendant de la bibliothèque de rendu) permet de garder une certaine flexibilité et évolutivité. Les besoins et les technologies changent. Travailler au niveau d’un modèle d’application permet de séparer la logique métier de la manière dont l’application fonctionne en interne.

Eclipse change sa plateforme applicative ? Par une adaptation de la couche «runtime» d’Eclipse Scout, la nouvelle version est supportée. À long terme Swing n’est plus maintenu par Oracle ? Ce jour-là, le runtime aura été adapté pour utiliser la technologie qui remplace Swing (JavaFx ou autre chose).

Dans le même ordre d’idée : le besoin d’avoir une instance web de nos applications s’est fait sentir. Nous avons étendu le runtime pour pouvoir en disposer pour toutes nos applications de cette possibilité (c’est une nouveauté de la version 2012. Cette extension est fondée sur Eclipse RAP).

Tout n’est pas parfait pour autant : les applications créées sont dépendantes de la couche «runtime». Par exemple avec Eclipse Juno, le mécanisme d’internationalisation a changé : de l’utilisation d’un Singleton, on est passé à un Service OSGi (comme partout ailleurs dans Eclipse Scout). Lors de la migration d’une application utilisant la version 2011 à la version 2012, cette partie-là est à remanier (à grands coups de rechercher remplacer – mais tout de même).

Autre limite, celle des éléments disponibles dans le modèle d’application : il n’existe pour le moment pas de composant «Table Tree». Cela ne veut pas dire que le modèle ne peut pas être étendu pour en disposer (c’est possible), mais aujourd’hui, cela ne fait pas partie du standard. Autre exemple de limite : il n’est pas prévu de pouvoir modifier le fonctionnement de la tabulation dans une fenêtre. Il faut se contenter de ce qui est proposé par défaut. Ce sera bien suffisant dans l’immensité des cas, mais pour des besoins spécifiques, pour le moment, cela ne fait pas partie du périmètre d’Eclipse Scout.

Ce qu’il manque à Eclipse Scout

Si le framework Scout existe en interne depuis longtemps, il est encore jeune en tant que projet open source. Eclipse Scout doit passer du statut de framework interne d’une entreprise, à un outil que chacun puisse utiliser. Les efforts accomplis dans ce domaine sont très importants, mais le résultat n’est pas encore à la hauteur des attentes des standards du domaine.

Il ne s’agit pas d’ajouter des couches ou des fonctionnalités dans le framework, mais plutôt de mieux expliquer et documenter ce qu’il est possible de faire. Évidemment c’est un processus qui demande du temps et pour lequel une certaine demande doit exister. Pour le moment, cette demande s’exprime à travers le forum du projet. Toutes les questions posées sont traitées avec une grande attention.

J’imagine qu’en cela Eclipse Scout n’est pas différent de n’importe quel autre projet open source.

En savoir plus ?
* Lisez mon article : premiers pas avec Eclipse Scout.
* Retrouvez ma page Eclipse Scout rassemblant une collection de ressources.
* La page officielle (en anglais) constitue également un bon point d’entrée.

IQuestionsListProcessService service = SERVICES.getService(IQuestionsListProcessService.class);

Côté client, deux cas se présentent:
* une implémentation est disponible côté client. Dans ce cas elle est retournée par cet appel.
* l’implémentation se trouve côté serveur. Dans ce cas, un proxy est retourné, et l’appel à la fonction est transmis au serveur par Eclipse Scout.

Ce registre de services gère plusieurs implémentations pour une même interface. Il est possible de définir une priorité pour donner un ordre entre les implémentations.

D’où mon idée de septembre dernier de proposer pour chaque service une implémentation se passant de la base de données. Dans ce cas il n’y a plus de persistance des informations, mais dans le cas de démonstration ou de tests cela peut être suffisant.

Je l’ai mis en oeuvre pour mon application MCQS.

Depuis ce commit, je dispose maintenant d’un fragment org.eclipselabs.mcqs.server.nodb.frament qui propose une implémentation des services avec une priorité plus haute. Lorsque le fragment est chargé avec le serveur (ce qui est le cas avec le produit server/products/nodb), ce sont ses implémentations qui ont la priorité.

Ce n’est pas encore tout à fait parfait, car pour faire les choses proprement il ne faudrait pas avoir de dépendance à la base de données dans le plug-in serveur principal, mais dans un deuxième fragment (et utiliser l’un ou l’autre).

Mon fragment NoDB est rudimentaire. Il ne garde rien en mémoire, ce qui devrait être possible.

Dans tous les cas, c’est un bon cas d’exemple de l’annotation @Priority que l’on peut ajouter sur chacun des services.

Par défaut, une application Eclipse Scout contient un certain nombre d’images qui sont des «place-holders» pour l’application finale. Il s’agit de tous les remplacer pour avoir une application à l’apparence correcte.

Splash Screen
Affiché lors du chargement de l’application, il permet à l’utilisateur de savoir qu’il doit patienter et qu’il se passe quelque chose.

Il suffit d’ajouter un fichier splash.xxx à la racine du plug-in de lancement (Swing ou SWT en fonction du moteur de rendu choisi. Pour SWT sans changer les réglages par défaut de l’application RPC, il faudra utiliser un fichier bmp). Ne pas oublier de l’inclure dans le ficher build.properties (dans la catégorie binary build).

Logo
Ce logo (grand) est notamment affiché dans la fenêtre «à propos de cette application».

Voir ce tutoriel.

Icône
L’icône est également un élément important.

Voir ce sujet de forum.

Page de téléchargement sur le serveur
Lorsque l’on se connecte en HTTP sur le serveur où est déployée l’application, on obtient une page de téléchargement. Il est important de personnaliser cette page.

La page en question se trouve dans le plug-in de l’application server sous /resources/html.

Je n’ai pas fait beaucoup de modifications sur cette page, mais mon idée est de toute façon de proposer un installateur (voir ci après). J’ai donc laissé le texte en anglais et la description correspondant à une application windows.

Installation
La prochaine étape va consister à se préoccuper de l’installation d’un produit fini. Il doit être possible:
* d’installer ou de choisir une base de données Derby.
* de configurer l’adresse à laquelle les clients devront se connecter.
…

Encore un peu de travail en perspective…

Je voulais obtenir un code indépendant de la configuration de la base de données, c’est-à-dire utiliser le fichier config.ini (qui doit de toute façon être mis à jour leur d’un changement d’environnement).

Fidèle à sa logique, Eclipse Scout propose d’étendre la classe AbstractSqlService pour définir la configuration d’accès à la base de données.

Il existe une propriété privée m_jdbcMappingName qui est accessible par des getters et des setters publics. Dans la classe fille, il est d’usage d’indiquer une constante dans la fonction getConfigured*() correspondante (getConfiguredJdbcMappingName() dans ce cas). C’est ce que la perspective Eclipse fait si l’on utilise la «Scout Properties View».

Le code correspondant:

À l’initialisation, cette valeur va être lue et devenir la valeur courante (accessible ensuite par le getter traditionnel).

Pourtant il existe une autre manière d’initialiser cette valeur. Il est possible d’utiliser dans le fichier config.ini une ligne respectant ce pattern:

<Qualified Name>#<Setter name without set prefix>=<value>

Ainsi dans notre cas:
org.eclipselabs.mcqs.server.services.common.sql.McqDerbySqlService#JdbcMappingName=jdbc:derby:/Users/jebr/code/mcq/mcq_db.derby

C’est magique…