Suite à l'article de janvier, voici la suite avec pour toile de fond l'évolution de Driveo l'application SaaS de gestion d'auto école.

Les limites du code splitting

Malgré les analyses poussées que peuvent fournir les outils de GWT (SOYC - Story Of Your Compile), on arrive rapidement à la limite de l'exercice du fait que l'application n'a pas été structuré dès le début pour être chargeable bloc à bloc en fonction des besoins de l'utilisateur.

Le principe est de découper le menu en plusieurs sous-menus. Chaque sous-menu regroupe les appels aux fonctionnalités propre à une habilitation. Chaque sous-menu doit gérer le cycle de vie des gestion des écrans/objets propres à son habilitation.Ensuite, en fonction des habilitations, le menu père va charger en asynchrone les différents sous-menus. Les points de séparation (split) se feront à ce niveau. Chaque écran étant indépendant et n'interagissant qu'avec le bus événementiel, la premier javascript (le .cache.html) devrait être de taille très raisonnable.

Pour cela, j'ai du refactorer (réécrire une partie du code) le menu de Driveo. De plus, afin de gérer les changements d'écran de la manière le plus souple possible, il m'a semblé nécessaire de le gérer de manière événementiel. Pour cela GWT possède une fonction native : la gestion de l'historique.

La gestion de l'historique

Si on écoute les présentations et qu'on lit les docs des gars de l'équipe GWT de Google : on DOIT commencer par la mise au point de la gestion de l'historique quand on conçoit une application basée sur GWT.

Comme ce n'est pas très funky et que pas grand chose n'est visible pour les clients, je ne l'ai fait que 1 an et demi après...

La chose est relativement aisée et c'est bien documenté : Large scale application development and MVP. Le code source de l'exemple est même disponible. L'exemple comprend une utilisation de la gestion de l'historique avec GWT.

Le principe est que chaque élément des sous-menus est une ancre (Anchor). Quand on clique sur cette ancre, l'URL est modifié (un #NomMenu est rajouté à la fin) et un événement javascript de type historique est créé. Il suffit alors de réceptionner et de filtrer ces évènements dans les sous-menus pour gérer le cycle de vie de l'écran (l'afficher, le cacher, le détruire, le re-créer).

Cependant, il faut bien tester la chose et bien vérifier le comportement de l'application au démarrage quand l'utilisateur démarre directement sur un lien marqué par un historique (avec le #NomMenu à la fin). En effet, le marque page de l'utilisateur a de fortes chances d'en avoir un et il faut bien rediriger l'utilisateur vers le bon écran et réémettant un évènement javascript d'historique.

L'effet sur Driveo

Si vous regardez la courbe suivante, l'ajout de code splitting sans restructurer la partie menu n'a tenu qu'un temps. L'ajout d'une fonction transverse à tous les écrans (la gestion multi-agence) a rajouté 200ko sur le premier fichier javascript GWT à charger par le navigateur.

La mise à jour du menu, lui à permis de descendre très fortement la taille du javascript initial (à 270ko - dans la courbe il y aussi le CSS et les images) et surtout de le stabiliser malgré l'ajout de fonctionnalités.

Après un gros mois très dense pour la sortie de la version Multi-Agence de Driveo, j'ai enfin un peu de temps pour bloguer quelque chose. Cet article, sera donc consacré à la critique de l'excellent Programmation GWT 2 sortie en Janvier. Un article qui aurait du paraitre ce même mois, si La poste ne m'avais pas retenu le livre pendant un mois dans le centre de tri.


Le livre Programmation GWT 2 : Développer des applications RIA et Ajax avec Google Web Toolkit est le premier livre qui expose les nouveautés de la dernière version GWT sortie en décembre 2009.

Tout d'abord, le livre n'est pas vraiment piur les débutants qui souhaitent découvrir GWT, mais plutôt aux programmeurs ayant un minimum pratiqué le framework de Google. Non pas, que les chapitres d'introductions sont mauvais au contraire, mais que cela risque d'être trop dense et trop rapide.

Le grand intérêt du livre est que les différents chapitres évoquent des points pratiques à réutiliser dans ses projets comme les bibliothèques de courbes et de graphiques, le drag & drop, la gestion de l'historique, etc...

L'autre point intéressant est la description des nouveautés de GWT 2.0 et des points très techniques comme le eRPC, le JSNI, JSON, la nouvelle gestion des CSS, les tests, le chargement à la demande, le modèle de placement CSS et l'UIBinder.

Le chapitre le plus attendu est le chapitre 15 sur les "Design pattern GWT", où il y a des sujets très utile comme les chargements incrémentales. J'ai découvert et adopté ce mode à travers ce livre, il permet permette de fluidifier l'affichage d'une longue liste d'élément sans bloquer la navigateur. Les patterns MVC et MVP sont aussi présentés (cf mon article précédent). Il y a même une partie sur la sécurité.

Le problème de ce chapitre est qu'il est beaucoup trop court et que l'on reste sur sa faim. J'aurais aimé un chapitre par sous partie et pour permettre de développer chaque patron d'utilisation de GWT. De plus, j'aurais aussi aimé voir apparaitre les limites d'utilisation des patterns (par exemple UI Binder + un framework MVP).

Il faut cependant garder à l'esprit que c'est le premier livre sur GWT qui va aussi loin.

Vous l'aurez compris, en tant que programmeur GWT, je vous recommande fortement ce livre. Enfin, vous pouvez même écrire vos questions, remarques et contributions dans le wiki de l'ami Sami.

Pour ce début d'année 2010, voici un nouvel article sur l'utilisation de GWT avancé. Cela concerne des techniques de programmation permettant de construire des applications GWT ambitieuse maitrisable ("Large Scale Application".

Les enjeux

Derrière ces articles techniques, il y a aussi des enjeux commerciaux.

L'impression de vitesse est très importante pour les tous les utilisateurs. Pour Driveo, c'est un critère discriminant dans le choix de la solution par rapports aux concurrents offline. Cela passe donc par la maitrise du premier chargement et donc la taille du fichier javascript généré par GWT.

L'agilité à corriger, maintenir et à faire évoluer l'application est aussi un facteur très différenciateur pour Driveo par rapport à la concurrence offline qui évolue plus lentement. Pour cela, la maintenabilité et la maitrise de la croissance d'une application doit passer des pratiques de conception le permettant.

Event Bus et MVP

Cette partie est la plus compliquée. Cependant, le paragraphe va être court. En effet, il y a la présentation donnée au normandy jug et surtout Google a surtout un article complet dessus.

Vous trouverez donc ma présentation au normandyjug qui évoque l'objectif de découplage des composants d'une application.

Enfin, l'équipe GWT a sortie un tutoriel nommé Large scale application development and MVP. Le code source de l'exemple est même disponible. L'exemple comprend même une utilisation de la gestion de l'historique avec GWT.

Le code de Driveo est cours de migration vers ces pratiques (20% sur Bus Events, 10% sur MVP). Les premiers avantage sont une diminution du code et meilleur maitrise de la maintenance.

Cependant, la migration en mode événementiel est à prendre avec des précautions car cela influence la conception complète de l'application. Il faudra veiller à éviter la prise en compte d'événement en double (par le bus events (nouveau code) et par listener/handler (ancien code)) car la localisation de prise en compte de l'évènement n'est pas la même.

Enfin, la partie la plus importante est le découplage des modules constituant l'application. Cela va permettre un code splitting plus efficace.

Code Splitting

Par le simple ajout de GWT.runAsync, dans l'embranchement principale de l'application (le menu, l'accueil, le tableau de bord), il est possible de reporter le chargement de certains modules en fonction du profil de l'utilisateur ou du module (si c'est un module peu fréquemment utilisé).

Le problème c'est que c'est efficace uniquement si les modules sont correctement découplés. On en revient donc aux pratiques de Bus Events et MVP.

Heureusement, pour pouvoir analyser ce découplage, l'équipe de GWT a ajouté l'analyse SOYC de votre code (SOYC = Story Of Your Compile). Cela vous permet, entre autre, d'avoir des rapports HTML qui permettent de savoir dans quel bloc de javascript compilés vos classes GWT se trouvent.

Pour cela, il faut ajouter les arguments " -compileReport -XsoycDetailed extra /path/path/report/application " à votre ligne de compilation. Attention, pour moi, avec ses options la compilation est passé de 9mn à 33mn! Il ne faut donc pas les laisser par défaut.

Pour conclure voici un graphique d'évolution de la taille de Driveo (Javascript compilé par GWT + CSS + noyau d'images) :

Hier soir, c'était la 4ème réunion du Normandy JUG avec au programme Android (Par Nicolas Giard le wicket fan boy), GWT avancé (par moi même) et JSF par Gontran Tombette de chez Sopra.

J'ai trouvé la présentation d'Android beaucoup mieux que celle de Google à Le Web. En effet, la présentation par les geeks de chez Google n'était qu'un enchainement de démo (genre Spotify, Shazam et Google Goggles). Pour cela à Rouen il y a Benjamien Anseaume ;-).
Donc, hier avec Nicolas, on a eu le droit à une vision du marché du mobile et des capacités de l'OS. Et c'était très bien!

Pour la présentation JSF 2, j'ai trouvé Gontran très pédagogique. Après, pour le rendu de page de contenu j'ai toujours préféré les frameworks à base de templates genre Velocity et FreeMarker (ou Smarty pour le monde PHP).

Enfin, pour ma présentation j'ai enchainé les obstacles. Pour commencer, je me suis pris une bonne rhino dans la trocnhe, les médicaments m'en remis en forme (enfin presque il parait que je respirais comme Nicolas Hulot, ca devait être beau voir ... tiens).
De plus, il me manquait l'accessoire suivant pour brancher le mac book pro sur une pauvre petite prise VGA (putain 29€ quand même, ils se font pas chier chez Apple).

Etant donné qu'une partie de la présentation devait montrer en mode debug le fonctionnement du Bus Event, je n'ai réussi qu'a faire 2 vidéos à l'arrache (pendant la présentation Androïd en fait) avec ScreenFlow.

Sur GWT, les commentaires restent les mêmes :

• c'est Google derrière ==> mais c'est pas pire que Oracle,
• on ne maitrise pas le rendu généré (i.e. on nous cache des choses) ==> c'est le prix à payer pour optimiser pour obtenir de la perf.
• c'est lent ==> c'est vrai et faux selon les applications (Google Wave est lent, Seesmic Web est très rapide) et les navigateurs (Internet Explorer et les navigateurs modernes).

Sur la rapidité, le truc avec GWT, c'est qu'il y a beaucoup de possibilités et il y donc encore plus facile de faire du code obèse (et donc lent). J'espère que les recommandations de la présentation permettront d'éviter de telles pratiques.

La soirée s'est finie par un repas ou j'ai pu trinquer au .... dafalgan.

Voici donc la présentation GWT Avancé, pour les autres présentations, elles vont arriver sur le site et vous pouvez être prévenu par le twitter.



La présentation est aussi téléchargeable en PDF : GWT Avancé.pdf

J'ajoute aussi les sources de l'exemple. Pour le faire fonctionner vous avez uniquement besoin de eclipse avec les plugins GWT.

Je souhaite aussi ajouter quelques précisions sur cet exemple qui contient l'utilisation du Bus Event et du pattern MVP, en effet, par rapport à la ce qui a été présenté à la Google IO :

• pas d'utilisation du design pattern command dans la gestion des actions sur la réception d'un évènement,
• pas d'utilisation du design pattern Inversion de Contrôle dans l'injection de la Vue sur le Presenter,
• quelques classe de gestion (MVPPresenter etc...) de mon cru.

Le fichier pdf est disponible sur ce lien :

http://groups.google.fr/group/normandyjug/web/Affiche_JUG_200912.pdf

A diffuser dans vos entreprises, écoles et universités!

La quatrième réunion de l’association NormandyJUG aura lieu le Mardi 15 Décembre à partir de 18h30, dans les locaux de l’eXia / CESI (à Mont Saint Aignan).

Les thèmes de la soirée sont les suivants :

• Découverte d’Android par Nicolas Giard
• GWT avancé par Youen Chéné
• JSF par Gontran Tombette

3 sujets de 40 minutes (oui ça peut marcher !…)

Et encore une fois, grâce à nos amis de chez JetBrains, Des T-Shirts et des Licences TeamCity et/ou IntelliJ IDea à Gagner !!!

Le sujet Google Web Toolkit et référencement est un sujet qui revient souvent. En effet, on peut penser naïvement que Google a produit un framework web hautement référençable par son propre moteur de recherche. Et bien, c'est tout le contraire :

C'était il y a une semaine au Pôle Normand à Mont Saint Aignan. Le Normandy JUG a réuni près d'une quarantaine de personnes.

La première présentation a été consacré à une "battle" GWT versus Wicket avec Nicolas Giard de Noocodecommit et moi même. La présentation a un peu durée. Nous avons eu pas mal de questions notamment sur GWT qui casse les habitudes de développement Web. De ce fait, je crois même que j'ai du répondre à côté d'une question sur le cache.



La présentation :



Un merci à Nicolas pour avoir relever le challenge, il faut savoir que avant l'organisation du Normandy JUG nous nous sommes uniquement croisé que par mail. Un merci aussi au public qui a fait vivre la session avec ses questions.

La deuxième partie sur l'intégration continue était assurée par Dimitri Baeli de Exo Platform et Laurent Deséchallier. L'objectif était de montrer qu'une petite structure ou une moyenne structure ont la capacité à intégrer un processus d'intégration continue pour leur(s) équipe(s) de développement. Si le débat a un peu trop dévié sur l'intérêt d'une approche orientée tests, nous avons pu avoir un premier aperçu des enjeux, des principes et de l'outillage.

La présentation :



Cette présentation sera sans doute complétée à l'automne par des présentations plus orientées outillage (maven, easy ant etc....). Les tracations sont ouvertes sur le forum du Normandy JUG.

Enfin, un grand merci à Benjamin Anseaume du Pôle Normand qui est resté plus tard que prévu pour accueillir cette première réunion.

Après avoir fait la visite de l'inauguration du Chtit JUG le 13mai sur Java EE 6, la première du Normandy JUG aura lieu le mardi 16 juin au pole normand à 19h au pôle normand (Zone d'activité de la Vatine à Rouen/Mont Saint Aignan).

Au programme, nous avons prévu 2 présentations. Une première "battle" GWT versus Wicket avec Nicolas Giard de NooCode Commit (pour Wicket) et moi même (pour GWT). Elle vous permettra de mieux connaître ces deux frameworks Web et de savoir quand utiliser chacun des deux. La deuxième présentation concernera l'intégration continu avec Dimitri Baeli de Exo Platform France et Laurent Deséchalliers (à confirmer).

L'inscription est rapide et se déroule sur cette page, elle est ouverte à tout le monde.

Au passage, le 9 juin sur Rouen, Proxiad organise le JEE Productivity Tour avec SpringSource, l'inscription est disponible sur cette page.

Afin de compléter les nombreux articles de découverte et de tutoriaux sur GWT, voici le premier article d'une série nommé "GWT avancé".

Pour rappel, GWT est un framework web et ajax de google qui génère votre site en javascript optimisé pour chaque navigateur à partir de code Java.

Cet article va mettre en avant l'utilisation des panels dans GWT. En effet, il est possible d'utiliser une grande variété de panels : FlowPanel, HorizontalPanel, VerticalPanel; ScrollPanel, Grid, etc...

Le premier réflexe que l'on entends dans les présentation, c'est de s'abstraire que le rendu (HTML dans un navigateur). Il suffit de programmer comme on fabrique une application SWT ou Swing (Entendu dans des pres' de Sami Jaber). Et bien après plus d'un an et demi sur ce framework, je pense que c'est une grosse bétise.

Voici les éléments de mon explication :

• Les bonnes pratiques de développement web disent que il ne faut utiliser les tableaux que pour les données tabulaires, le reste d'une page web doit être mis en page en appliquant un style (CSS) sur des éléments de contenu
• La plupart des panels de GWT génèrent des tables par exemple si on fait un HorizontalPanel qui contient 2 VerticalPanel, cela génère une table qui contient 2 tables. (magnifique!)
  

En conséquence, j'ai appliqué les 2 règles suivantes :

• Pour structurer les élements, le seul panel autorisé est le FlowPanel (qui génère un div) .
• Pour les données tabulaires (et uniquement pour cela), j'utilise le Grid ou la FlexTable.

Avec un peu de recul, ces 2 règles ont les bénéfices suivant :

• Un code plus compact (toutes les instructions de mise en page sont dans le CSS), les fichiers générés par GWT sont donc plus petits (donc plus rapide à charger pour l'utilisateur). C'est même plus rapide à programer.
  
• Une meilleure séparation de la mise en page et du code.
• Une meilleure compatibilité de la mise en page entre navigateur (sur les tableaux c'est souvent difficile).
• Un HTML généré plus léger, plus simple, plus compréhensible et plus rapide à traiter pour le navigateur (par exemple sous IE7 la génération d'une liste d'élève est passé de 4 secondes à immédiat en passant en FlowPanel).
• Et enfin une page plus accessible et lisible par les lecteurs audios de site web (pour les mal-voyants).
  

Le prochain article parlera de GWT et de ses problèmes de référencement avec comment le mélanger avec une page statique pour la prise en compte de la partie AJAX et des intéractions.