Laveur de cerveaux?

Cette semaine, plusieurs articles ont eu comme sujet "Power Point". Ils ont pour origine le livre de Franck Frommer, «Pensée Powerpoint : enquête sur un logiciel qui rend stupide».
L'article de Télérama sur le sujet conclue : "Le problème ce n'est pas le logiciel lui-même, mais l'usage que l'on en fait. Ça ne fait que valoriser une façon de penser, l'idéologie dominante: simplicité, efficacité, moindre coût."

Cette conclusion s'applique elle aussi au logiciel de la BI. En effet, lorsque qu'un non informaticien me demande à quoi sert la BI, je réponds "la BI a pour but de rendre intelligible les données que stocke une entreprise". Cet objectif est noble et nécessaire tant la quantité de données stockées est importantes. Hélas, les outils dont nous disposons ont les mêmes travers que les PPT. Ansi, les solutions uniquement "sexy" et rapide à mettre en place sont privilégiées à la mise en place de solutions viables et pertinentes, ses dernières nécessitant temps et réflexion donc argent.

Une api GTW partagée

Le but de ce post est de montrer comment créer simplement dans eclipse une api graphique GWT réutilisable dans plusieurs projets.

Pré-requis:
Avoir sur son poste une version d'éclipse contenant le plugin GWT ce dernier correctement configurer pour utiliser une version 2.x de l'api GWT.

Etape 1: création du projet.
En cliquant sur l'icône de création d'un projet GWT la fenêtre ci-dessous s'affiche. Pour l'exemple j'ai choisi d'appeler mon projet ApiGwt avec comme package principal org.graphical.api:



Par défaut GWT créé des classes d'exemples. Supprimer toutes les classes existantes ainsi que les packages org.graphical.api.server et org.graphical.api.shared

Etape 2: mise à jour du fichier XML de déclaration du module.

Editer le fichier ApiGwt.gwt.xml et modifier le en supprimant les lignes surlignées en jaunes ci dessous.


Le projet est maintenant prêt et peut-être utiliser pour créer les classes que l'on souhaite partager.

Etape 3: Création d'une classe simple.
Afin d'avoir un plus grande lisibilité dans le code source, il est intéressant de créer un nouveau dossier source. Pour cela faire un clic droit sur le projet puis new -> source folder


J'ai appelé "ui" ce nouveau dossier source. Dans ce dossier il faut créer deux packages:

• org.graphical.api.client.ui
• org.graphical.api.client.ui.dialogs

Il est maintenant nécessaire de déclarer ces packages comme étant des modules GWT. Pour cela dans le package org.graphical.api.client.ui il faut créer un fichier ApiGwtUI.gwt.xml. Le contenu de ce fichier est le suivant:

Note: penser à décommenter le doctype.

Afin de fournir un exemple, dans le package org.graphical.api.client.ui.dialogs, je créé la classe MyDialog dont le code est:

package org.graphical.api.client.ui.dialogs;

import com.google.gwt.user.client.ui.DialogBox;
import com.google.gwt.user.client.ui.HTML;

public class MyDialog extends DialogBox {

 public MyDialog() {
    super();
    this.setText("Mon titre");
    this.setWidget(new HTML("Bla bla bla"));
 }
}

Etape 4: déclaration du nouveau module dans le fichier XML de déclaration principal.
Pour cela il suffit de rajouter la ligne suivante dans le fichier ApiGwt.gwt.xm:

A ce stade il est possible d'exporter les packages créés sous forme de jar afin de les utiliser dans un autre projet GWT. Le soucis est que pour le moment nous n'avons pas testé notre classe.

Etape 5: création d'un package de tests.
Afin de bien séparer les tests du reste je créé un nouveau dossier source nommé "tests". Dans ce dossier je créé deux packages:

• org.graphical.api.tests
• org.graphical.api.tests.client

Dans le premier package (org.graphical.api.tests), je crée le fichier de déclaration d'un module GWT: ApiGwtTests.gwt.xml dont le contenu est:

La ligne

permet de déclarer quelle est la classe qui implémente "EntryPoint".

Dans le deuxième package org.graphical.api.tests.client je crée la classe "Tests":

package org.graphical.api.tests.client;

import org.graphical.api.client.ui.dialogs.MyDialog;

import com.google.gwt.core.client.EntryPoint;

public class Tests implements EntryPoint {

 @Override
 public void onModuleLoad() {
    MyDialog myDialog = new MyDialog();
    myDialog.show();
    myDialog.center();

 }

}

Une dernière modification est nécessaire avant de pouvoir lancer la classe de test. Il faut éditer le fichier ApiGwt.html et remplacer la ligne:

par la ligne:

Une fois cela fait faire un clic droit sur ApiGwtTests.gwt.xml puis run as -> web application.

L'étape 5 n'est pas nécessaire, en effet il aurait été possible de faire les tests directement dans la classe d'entrée créé automatiquement par GWT. L'intéret de cette solution est qu'elle permet de bien isoler les tests et le reste du code et aussi de faire des exports incluant uniquement les classes effectivement utiles.

Etape 6: export sous forme de jar.
L'arborescence finale est la suivante:

Pour exporter sous forme de jar faire un clic droit sur le projet puis export->java->jar file et sélectionner les packages a exporter comme suit:

Etape 7 : Utilisation du jar créé.
Pour utiliser le jar créé il suffit de la placer dans le répertoire lib de votre projet GWT, de l'ajouter au classpath de celui-ci et enfin de le déclarer dans le fichier .gwt.xml en y ajoutant la ligne suivante:

Conclusion:
Cette démarche me parait intéressante et facile à mettre en place. Lors de mes différents essais je n'ai trouvé qu'un lien sur le sujet (http://java.ociweb.com/mark/programming/GWT.html#Reuse) que j'ai trouvé un peu léger même si tout y est dit, d'où l'idée de ce post.

Charabia

Il y a un peu plus de deux ans, lorsque j'ai fait mes premiers pas en temps que salarié du privé ma première action a été de créer un répertoire définitions dans mes favoris. Dans ce répertoire je plaçais tous les liens wikipédia vers les acronymes que je découvrait pour la première fois.
Je vous laisse imaginer ce qu'une simple phrase telle que "Pour le design d'un cube OLAP, il est nécessaire de créer un DWH à l'aide d'un ETL" pouvait déclencher comme recherches!

Vendredi dernier l'émission de France Inter Nous Autres, m'a refait vivre ses grands moments avec beaucoup d'humour. L'interview diffusé était tout simplement jouissif, je vous le conseille.

Le retour

Après bientôt un an d'absence me voici de retour!!

La raison de cette absence prolongée, la recherche d'un appartement. Il a fallut un peu plus de huit mois pour trouver le mouton à cinq pâtes... Emménagement prévu mi juin.

La raison de mon retour, la publication par Smile du livre blanc "Bi open source décisionnel 2010". En effet ce livre blanc à fait débat au sein de ma société (bpm-conseil).

A titre personnel, je ne suis pas surpris que la suite vanilla ne soit pas citée dans ce livre et je ne m'en émeu pas outre mesure. Evidemment, j'aurai préféré que nous soyons présent mais je ne vois ici aucune forme de "censure". J'estime de plus qu'il aurait été difficile de nous jugé objectivement car comme le dit Sylvain Decloix, de nombreuses copies d'écrans n'étant pas à jour je doute que Smile ai eu (pris?) le temps de regarder les dernières avancées de vanilla.

Pour moi sa relative confidentialité est la seule raison objective de l'absence de vanilla dans ce livre blanc. Quoiqu'il en soit, cette raison est de moins en moins valable si j'en juge par le nombre de formations qui sont organisées autour de vanilla, notamment sur le triptyque FreeMetadata, FreeDashboard, BIRT. Le bon travail réalisé en 2008 avec le Grand Lyon nous a ouvert les portes de nombreuses collectivités désireuses de remplacées BO par une solution OpenSource. Enfin la stabilisation de la plateforme et l'augmentation constante des performances nous ouvre les portes de grands comptes.

Gaël