J'insiste sur le fait que Google ne me donne aucune information secrète, ou de nature à faire croire que je faisais partie des initiés dans cette annonce :-), j'ai simplement toujours eu cette petite intuition. Lorsque GWT 2 est sortie en Janvier dernier, de nombreuses personnes m'ont demandé quel était l'intérêt d'une technologie telle que UIBinder dans l'enchevêtrement des briques proposées.  Je leur ai toujours rétorqué que le but ultime d'un outil de structuration d'IHM XML était de fournir un concepteur graphique. D'un point de vue technique, c'est une aberration de croire qu'on peut faire du rétro-engeenering d'IHM à partir du code source. C'est ce que GWT Designer faisait et j'ai toujours déconseillé cette approche à nos clients. GWT Designer dans sa première version était un simple « gadget » marketing.

Plusieurs fois sur ce blog j'ai envoyé des messages subliminaux aux éventuels entrepreneurs. Dans l'année 2010, celui qui se serait lancé dans un outil WYSIWYG générant de l'UiBinder était assuré d'être millionnaire. Et forcément, qui de mieux placé qu'un professionnel du domaine. Lorsqu'on sait faire un outil WYSIWYG par dessus un langage, on sait facilement l'adapter par dessus un autre. La société Instantiation avait tout pour réussir. J'en avais parlé le 2 Juillet sur ce blog, un des développeurs du projet commençait à se rapprocher de Google.

Ce rachat d'instantiation officialisé aujourd'hui est donc une excellente nouvelle pour tous les fans de GWT, pour tous les amoureux de cette technologie. Le rêve ultime de tout développeur d'applications Web (j'insiste sur le terme « Application » car nous n'utiliserons pas cet outil pour faire des sites web institutionnels) se réalise enfin. Concevoir une application Web visuellement par simple glisser/déplacer en tirant partie d'AJAX, du support multi-navigateurs automatique et sans se soucier de HTML et JavaScript est (presque) à portée du doigt. « Presque », car UiBinder n'est pas totalement prêt. Laissons un ou deux ans à cet outil et GWT sera enfin complet.

Tout au long de ces années, nous avons cessé d'insister sur la richesse de l'autre et l'intérêt de maîtriser les technologies concurrentes.

Au début de .NET, les termes mapping objet/relationnel ou portabilité étaient tabous, je me rappelle encore de discussions enflammées avec des responsables de Microsoft arguant sur l'intérêt de garder ADO.NET mono provider pour ne supporter que SQL Server. Je me rappelle d'ingénieurs Microsoft rejetant avec force l'idée même qu'un jour .NET puisse s'ouvrir à autre chose que du Microsoft. 

En dix ans, nous avons essayé de briser tous ces tabous, la programmation par aspects, UML, l'injection de dépendances, la séparation en couches, l'instrumentation de code, .NET sur Linux. Combattre le quick and dirty et la manie du glisser déplacer pour introduire une conception robuste et pérenne tout aussi compatible avec le développement RAD. Tout cela au travers de centaines d'articles représentant des milliers  de pages. Des heures, que dis-je, des nuits de travail.

J'ai construit ce site en Php à une époque où il n'existait aucun outil .NET pour faire ce genre de choses. De nombreux auteurs talentueux m'ont rejoint. La plupart sont devenus des amis, je ne les cite pas, ils se reconnaitront tous, DotNetGuru leur doit beaucoup. Chacun, par ses écrits, a contribué à faire évoluer les mentalités.

Aujourd'hui, nous pouvons l'affirmer haut et fort ; Microsoft a changé et .NET s'est métamorphosé. Des communautés (Alt.net, .) se sont créées sur le même modèle que DotNetGuru et l'heure est à l'intéropérabilité, aux DSL, à Silverlight sur Linux (qui l'aurait imaginé en 2001), Mono, VS 2010 et ses diagrammes UML, Entity Framework, Linq,etc ... Plus personne ne remet en cause les qualités de .NET, ni celles de Java d'ailleurs. Ces deux plateformes sont tout simplement devenues le pain quotidien de nombre d'entreprises.

Il faut donc savoir tourner la page, tirer sa révérence et acter le fait que cette bataille n'est plus à mener. Depuis quelques temps, le site est de moins en mois maintenu et mes obligations quotidiennes ne me permettent plus de fournir un niveau de qualité digne de ce que vous êtes en droit d'attendre. Je continue évidemment à faire du .NET (tout comme du Java), j'ai toujours autant d'idées et de choses à faire partager, mais mes priorités ont changé.

Ce blog (et mon compte twitter) resteront mes modes de communication privilégiés dans les mois à venir. DotNetGuru.org sera actif pendant quelques mois, le temps de laisser la communauté profiter pleinement du contenu existant. Ensuite, je briserai les chaînes qui me relient à ce site, pour lequel j'ai tant donné mais qui me l'a si bien rendu.

Don't stay tuned anymore ...

Mais à force de répéter qu'un concepteur graphique est inéluctable, on finit un peu par ne plus y croire. Cette fois, c'est la bonne, ce n'est pas Google qui l'annonce, mais bel et bien la société en charge de GWT Designer, Instanciations. Par la voix de Konstantin Scheglov, Instantiations parle du projet et propose sur la liste des contributeurs de modifier quelques caractéristiques du framework UiBinder pour le rendre compatible "Design Time" (c'est presque le cas aujourd'hui).

GWT Designer <http://www.instantiations.com/gwtdesigner/> is tool for WYSIWYG building of GWT UI, which development I lead at Instantiations. Its latest release works only with Java source for GWT, but now I work on UiBinder support too and many things already work

Sur le terrain, GWT prend une nouvelle dimension. Tous les jours des projets migrent ou se construisent sur la base de cette technologie dont les nombreuses qualités masquent l'essentiel des défauts.

Dans le livre j'insiste sur l'intérêt des bonnes pratiques mais surtout sur l'importance de maîtriser ce que l'on fait. Il m'arrive souvent de comparer GWT aux technologies de mapping O/R. Il y a deux effets kiss-cool dans GWT. Aux premiers abords, les choses paraissent d'une simplicité enfantine, même mamie pourrait coder une petite appli en quelques jours. Mais dès que le code se complexifie, le second effet apparaît. Il faut maîtriser un minimum le DOM et explorer à minima les dessous de GWT. Tout comme un outil de mapping ne doit pas être un moyen de naviguer aveuglément dans un graphe objet. Il faut se former et s'informer, le web recèle de ressources sur GWT et de nombreuses sociétés proposent d'ores et déjà leurs services, comme DNG Consulting.

Petite pub au passage pour l'évènement GWT 2 organisé le 15 Juin par Objectif Informatique sur Paris. C'est entre midi et deux et cela se passe à Paris. J'ai ouï dire que quelques livres Prog GWT 2 y seraient distribués..

Au plaisir

Le mot-clé à retenir pour GWT 2.1 est Bikeshed. Bikeshed est le nom de code d'un nouveau framework graphique sur lequel planche l'équipe de Bruce. Pourquoi ce nom ? Bikeshed n'a pas grand chose à voir avec les vélos, en réalité c'est un terme emprunté à l'historien Parkinson. Le Bikesheding est une loi qui exprime le fait que les sujets dont on discute longtemps sont ceux qui sont les plus triviaux alors que peu de personnes peuvent échanger et exprimer une opinion sur un sujet techniquement complexe (comme celui d'un réacteur nucléaire). Tout le monde peut discuter indéfiniment de la couleur d'un abri à vélo (BikeShed) et faire entendre son avis.

Bikeshed s'appuie sur plusieurs briques fondamentales :

- De nouveaux composants graphiques

- Un framework de Validation

- Un framework (RequestFactory) permettant de synchroniser des entités serveur suivant une philosophie REST/JSon

- Un framework de Data-Binding (appelé aussi ValueStore)

- Un framework gwt-collections

Au jour d'aujourd'hui, je ne sais pas si GWT 2.1 sera annoncé à Google IO et quelle sera la place laissée à Bikeshed. Vu la maturité du code disponible sur le trunk, Bikeshed n'est qu'un embryon de framework. En revanche, ce qui est sûr, c'est qu'il représente une brique majeure dans la stratégie GWT de Google pour les prochains mois.

Nouveaux composants graphiques

Il y a encore peu d'information disponible sur les nouveaux composants graphiques. La fameuse grille paginée est belle est bien là. Elle se prénomme PagingTableListView. Elle n'a plus grand chose à voir avec la fameuse grille du projet d'incubation. Cette fois, les entêtes sont personnalisables et un modèle (ListView) fait son apparition.

public class PagingTableListView<T> extends Widget implements ListView<T> { ...  }

PagingTableListView<StockQuote> favorite = new PagingTableListView<StockQuote>(10);
    favoritesListViewAdapter.addView(favorite);

    favorite.addColumn(Columns.tickerColumn, "ticker" );
    favorite.addColumn(Columns.priceColumn, "price" );
      favorite.addColumn(Columns.profitLossColumn, "profit/loss" );

On trouve également de nouveaux composants de type arbre (SideBySideTreeView et StandardTreeView), un TreeView est également associé à un modèle. Plus généralement, la plupart des nouveaux composants arborent désormais un modèle et surtout, autre nouveauté, un client bundle pour la gestion des ressources. Voici une partie du code source de la classe TreeView :

public abstract class TreeView extends Composite {

  /**
   * A ClientBundle that provides images for this widget.
   */
  public static interface Resources extends ClientBundle {

    /**
     * An image indicating a closed branch.
     */
    ImageResource treeClosed();

    /**
     * An image indicating an open branch.
     */
    ImageResource treeOpen();
  }

  private static final Resources DEFAULT_RESOURCES = GWT.create(Resources.class);

{...}

Framework de validation

Un framework de validation est également en préparation. Pour l'instant on ne peut pas dire qu'il soit réellement industriel, on trouve simplement une ou deux classes, une sorte de brouillon de prototype.

Gestion du data binding

Pour ceux qui ont l'habitude d'utiliser du DataBinding dans les framework traditionnel (beans-binding, Flex, Silverlight, .), oubliez tout, GWT a cherché à innover sur ce plan. Pour faire court, le RequestFactory est un framework permettant de créer des requêtes REST associé à un ValueStore, une sorte de mécanisme observer/observable permettant de synchroniser l'état d'entités (JPA) serveur sur le client. Sur le papier, le projet est très ambitieux. Dans la pratique, tout cela est encore loin d'être simple. Il manque encore tout l'outillage destiné à générer la tuyauterie aujourd'hui encore trop visible. Chaque objet du domaine, par exemple Facture ou Client possède une représentation cliente (FactureRequest) et des classes de requêtes (AllFacturesRequester) :

Ex :

public final class AllEmployeesRequester implements ValuesListView.Delegate {
  private final ValuesListViewTable<EmployeeRecord> view;
  private final ExpensesRequestFactory requests;

  public AllEmployeesRequester(ExpensesRequestFactory requests,
      ValuesListViewTable<EmployeeRecord> newView) {
    this.view = newView;
    this.requests = requests;
  }

  public void onRangeChanged(int start, int length) {
    requests.employeeRequest().findAllEmployees().forProperties(
        view.getProperties()).to(view).fire();
  }
}

Le moins qu'on puisse dire c'est qu'il est encore trop tôt pour s'avancer sur une quelconque maturité de ce framework. A titre personnel, je le trouve (et j'ai eu l'occasion d'en parler avec Ray Ryan ici, à l'origine du projet) trop ambitieux, suréquipé et incontestablement trop compliqué. Un framework de databinding doit rester réservé au périmètre du poste client (il existe d'autres outils pour synchroniser des entités serveur) et se résumer à connecter deux propriétés. Ici, il faut compter pas moins de cinq classes par objet du domaine, même avec un générateur de code JPA, c'est beaucoup trop.

Malgré tout, il faut noter la richesse des fonctionnalités proposées ; gestion des deltas en cas de modification d'une liste, gestion des évènements (deleted, modified,..), gestion de la vue maître/détail, etc .

Collections

Bikeshed introduit également un petit framework de Collections (tableaux immuables et muables, .).

Les démos

Il existe sur le trunk plusieurs démos (elles seront sûrement présentées lors de Google IO) destinées à valoriser Bikeshed. J'avoue avoir pensé à les déployer sur AppEngine mais vu la maturité du code (tout cela relève du prototype encore) et la pauvreté des styles (le graphisme n'est décidément pas le point fort des Gwiters), cela n'aurait pas été très fair play. Voici malgré tout un petit screenshot de l'application Day Trader, on peut y apercevoir la nouvelle grille.

Pour le reste, vous en saurez beaucoup plus lors de Google IO, qui s'annonce très excitant !.

Bref, vous l'aurez donc remarqué par vous même, ces dernières semaines ont été plutôt chargées pour DNG Consulting. La société s'est agrandit, depuis début Avril nous sommes dans de nouveaux locaux flambants neufs à quelques encablures de nos précédents bureaux. Et côté projets, les activités de conseil, formation et forfait se portent plutôt bien. Mais ce n'est pas la seule raison de ce silence. Parfois, Il faut savoir se taire, prendre un peu de recul et se ressourcer techniquement sur le terrain. J'espère très bientôt vous faire quelques retours d'expérience et commenter l'actualité, plutôt riche en ce moment. Parmi les technologies sur lesquelles nous travaillons en ce moment, Java et .NET occupent évidemment une place de choix, mais surtout les nouveaux framework qui les accompagnent.

Après avoir consacré une année entière au développement d'EJB 3 en 2008 avec JBoss 5 (béta) Embedded et OpenEJB, précurseurs en la matière, j'ai été ravi de voir que, ce qui à l'époque relevait de l'expérimentation de laboratoire, était devenu un standard. Glassfish V3 a depuis lui aussi adopté la mode Embeddable Container avec des résultats remarquables. Nous l'utilisons aux côté de GWT pour nos projets AJAX et la productivité du développeur est incroyable. Au-delà de Glassfish, c'est aussi son architecture interne qui nous a séduits. On évoque un peu partout les prémisses de la norme HTML 5, les WebWorkers et les nouveaux modes de communication entre navigateur http et serveurs web. La norme Servlet 3.0 ajoute les Threads Asynchrone qui s'appuient entre autre sur le principe des continuations pour arrêter et suspendre une requête http en cours d'exécution. Pour des applications gourmandes en Push, rien de tel qu'un Grizzly intégré dans Glassfish. Peu de serveurs d'application propose aujourd'hui une pile aussi riche. Et je ne vous parle pas du framework Atmosphere de Jean-François Arcand avec qui j'ai eu l'occasion de m'entretenir récemment. Le futur du web se profile aussi parmi ses frameworks. Plus performants, plus robustes, supportant le mode full-duplex, multiplexés et optimisés pour la montée en charge et les échanges intensifs entre client et serveur. Le développement Web avec GWT 2, Glassfish V3 Embedded (en mode-dev) et JPA reste ce qui a de mieux sur le marché Java aujourd'hui.

Autre sujet sur lequel j'espère avoir le temps de formaliser, les progrès de .NET depuis la V4 et VS 2010. Je ne me lasse pas de cet IDE. Plus je l'utilise et plus je me dis qu'Eclipse va avoir du pain sur la planche pour combler son retard sur la partie graphique. Attention, je ne parle pas des dizaines de « petites » fonctionnalités qui font la richesse d'Eclipse et que VS 2010 ne possède pas toujours. Mais plutôt de la couche vectorielle que WPF a apporté dans VS. Il faut être lucide, les IDE de demain seront vectoriels. Quand on voit la popularité grandissante de clients riches comme WPF et Flash, on a du mal à comprendre pourquoi Eclipse s'appuie encore sur ce mammouth à base de bitmap Win32 qu'est SWT.

Pour l'anecdote, j'ai pris l'habitude d'utiliser (comme dans un navigateur) la roulette et la touche « Ctrl » pour augmenter la police de caractères sous VS. Sous Eclipse, il ne faut pas moins de 7 clicks : Window--> Préférences--> Général--> Apparence--> Fonts--> Edit . Et encore, je n'ai pas la preview ! Lorsqu'on est en mode WYSIWYG dans un concepteur graphique, rien de tel que le vectoriel pour agrandir certaines zones de formulaire.

Je reviendrais très prochainement sur l'actualité de GWT (qui évolue toujours dans le bon sens), du livre (merci mille fois à ceux qui prennent la peine de m'envoyer un petit mail d'encouragement) et des nouveaux cours que nous développons actuellement à notre catalogue.

Stay Tuned

Billet rédigé par Sami Jaber

Lionel Laské, directeur innovation chez C2S, vient de publier un très joli billet sur l'intérêt de se pencher sur GWT lorsqu'on est développeur .NET. Pour être le premier défenseur de .NET lorsqu'il s'agit d'applications stratégiques et transactionnelles, il n'en reste pas moins que sur la partie Web AJAX, le framework de Microsoft reste encore trop dépouillé.

Cependant, et on le lit un peu partout, il n'est pas conseillé d'écrire de gros traitements en JSNI pour de très bonnes raisons :