Pour tous les déçus d’ext-js il existe SmartClient qui propose un framework très similaire mais en LGPL (il existe également des licenses pro et commerciale pour des features avancées). Très pratique pour développer rapidement des proto RIA qui manipulent des sources de données XML ou WS et également pour faire du REST.

Et pour les irréductibles de GWT, il y a SmartGWT qui permet de profiter de SmartClient en utilisant les API GWT.

je voudrais faire un retour d’expérience avec le fwk Ext JS 2.0 .
Je le déconseille sur des projets avec des profils pas assez expérimentés en JavaScript.
Le temps d’apprentissage est long ! Certes le look-and-feel est sexy, mais son utilisation peu vite devenir un cauchemar.
Pour arriver à faire quelque chose de simple on y arrive jamais du premier coup, par conséquence on a l’impression qu’il faut faire les choses compliquées pour arriver à faire une chose simple !!
Et c’est après pas mal de temps passé sur le forum et/ou les examples que l’on se rend compte que c’était simple à faire mais pas INTUITIF du tout.

Je viens de réaliser un proto GWT avec de la librairie Ext-GWT (aka GXT) dont je vous livre la conclusion :

GXT est bourré de bugs et quasi-inutilisable (version testée : 1.1)
GWT-Ext n’est pas du code Java mais un wrappeur sur du Javascript externe -> à éviter

Solution à suivre : SmartGWT qui semble rassembler le meilleur de ces libs :

- large collection de widgets visuellement très réussis
- licence LGPL
- pur Java

Concernant la préconisation du framework GWT, je pense qu’il faut être assez prudent.

C’est-à-dire qu’il faut avoir un cadre défini au niveau :
– Des composants dont l’application a besoin
– L’interaction entre ces composants
donc peut être une maquette ou un story board de l’application serait une bonne solution d’évaluation.

Notre expérience de GWT-ext, nous a prouvé que GWT marche très bien, mais l’intégration des composants tiers peut être un frein à la productivité. Du fait que les composants soient de mauvaise qualité ou soient fonctionnellement mal conçus.

La seule structuration que propose GWT, ce sont les composants. Donc, il faut avoir/trouver des patterns pour structurer une page GWT. Je pense que mettre en place des patterns MVC ne semble pas adapté pour le framework, cela ne reflète pas le côté événementiel du client : le modèle de programmation GWT.

GWT ne semble pas adapter pour toutes les applications, GWT est plus adapté aux applications Web dont :
– Il y a peu de pages, et surtout il a peu de navigation entre les pages
– Il y a une logique événementielle côté client sur les pages (déroulement d’arbre qui met à jour un panneau sur le clic d’un noeud …)
– Il faut que l’ergonomie soit adaptée aux composants disponibles (il faut avoir une bonne maîtrise des composants pour savoir ce que l’on désire en faire, et comment il s’intègre avec les autres composants)
– Il y a peu d’interactions entre le client et le serveur.

Tu trouveras peut être plus d’informations dans un article en cours de préparation chez Xebia : GWT Galaxy, voici un extrait : « Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie, de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques. »

Merci Alexandre pour tes retours, apparemment il y a des possibilités d’optimiser cette phase de compilation, en phase de développement, en générant seulement le javascript pour un navigateur cible au lieu 4-5 navigateurs supportés de base. (Xebia en parlera dans l’article GWT Galaxy).

Nicolas LC (Xebia).

Très bon article ! J’avais pour idée d’organiser ce même type de contest, et j’avoue que de lire cet article me donne envie de pousser cette idée plus loin pour la concrétiser en 2009.

Je voulais savoir si actuellement vous préconisez l’utilisation de framework GWT pour cadrer le développement ?

Je ne parle pas de framework « graphiques » mais de framework structurant !

Je sors du monde Eclipse RCP ou de nombreux facilitant, pattern et outils existent pour aider a la structuration du code.

Par exemple, le framework command d’Eclipse me manque beaucoup, le databinding apparait complexe a mettre en place, le MVC est inexistant ou presque. La notion même d’action ne semble pas vraiment présente dans le framework. Je me retrouve à implémenter de piètres équivalents… qui vont forcément être plus lourds à maintenir ou à faire évoluer.

Gwittr ? Metawidget ? smartGWT/smartClient ? GWTEventService ? uface ? autre ?

Merci par avance,

Cyril Lakech

I read this article translated, hope you don’t mind me commenting in english…

I just wanted to hint about yet another alternative: IT Mill Toolkit ( http://www.itmill.com ) is a java serverside RIA framework that uses GWT for the client-side; you get the benefits of server-side programming (e.g security), and you can program the client-side using java as well.

Best Regards,
Marc

Si un consensus existait quant au choix de la technologie, ce contest n’existerait probablement pas. À l’inverse de votre choix, d’autres avoueront probablement s’être mordus les doigts avec GWT : difficulté pour structurer les projets, temps de compilation pouvant devenir trop long … le meilleur des codes Java n’implique par forcement une bonne ergonomie.

Tant que le compilateur GWT générera du code HTML, les notions de présentation web restent obligatoires. À quand un compilateur GWT générant du flash

Une petite remarque sur l’exercice qui est intéressant mais avec lequel il faut prendre des précautions en lisant les résultats.

On ne peut utiliser les résultats d’un tel « contest » que pour envisager le développement d’une petite application. Sur un gros projet les résultats peuvent complètement différent.

Nous travaillons sur un projet qui nous a permis de « tester » en profondeur 2 de ces frameworks : flex et gwt. Nous développons une application métier assez complexe avec quelques dizaines de vues. Nous avons d’abord débuté le développement en nous appuyant sur Flex. Les premiers résultats concordaient avec le contest: Développement rapide des premiers écrans, aspect fini de l’application, … En revanche dès que le volume de code à commencer à augmenter, la productivité est rapidement tombée. Les outils ne sont pas du tout à la hauteur de ce qui existe en java. Le code est difficile à refactoriser, tester, …

Nous avons décider d’abandonner FLEX pour repartir sur GWT. La courbe de productivité est différente. Elle débute plus bas mais augmente au fur et à mesure. Le code est refactorisable, réutilisable, … Nous avons aujourd’hui plus de 300 classes pour la couche cliente que nous maintenons sans difficulté avec un IDE de qualité (intellij Idea). Nous avons dû travailler sur la structuration du code : mise en oeuvre du pattern Présentation Model, binding, validation,… souvent avec du code maison car les frameworks sont assez récents. Ce que nous avions trouvé sur Flex n’allait pas tellement plus loin (binding unidirectionnel, framework Cairngorm $!#).

En bref, le choix ne peut se limiter à la lecture rapide des résultats d’un contest mais doit bien prendre en compte le projet cible.

Gaetan Zoritchak

Par rapport à Ext GWT, je voulais apporter une précision qui me semble importante pour tous les nouveaux utilisateurs GWT. Vous devez avoir la licence commerciale de Ext GWT pour le développement d’une application commerciale : http://extjs.com/products/license.php.

NB : attention il existe « Ext GWT » et « GWT-Ext ». GWT-Ext a été utilisé pour le Xebia RIA Contest, tandis que Nico fait allusion à Ext GWT (anciennement myGWT).

Nicolas Le Coz (Xebia)

Le contexte du contest ne permettait pas à l’équipe GWT de faire une conception préliminaire du code de l’interface.

Le développement a commencé avec une classe Java : l’EntryPoint GWT. De plus nous sommes partis avec un composant Layout de Gwt-Ext : BorderLayout (http://www.gwt-ext.com/demo/#borderLayout). Ce layout décompose la page en 5 sous Layout.

Rapidement notre classe principale (EntryPoint) faisait plusieurs centaines de lignes et 3 développeurs faisaient des modifications dessus.

Avec un refactoring rapide d’Eclipse, nous avons rapidement donné un coup de frais au code :
– Découpage de la classe en 5 sous classes (logiquement Noth, West, East, Center, South)
– Extraction de code dans des méthodes avec un nom explicite

En une dizaine de minutes nous sommes passer d’un code moyennement maintenable (une classe de 400 lignes avec seulement 2 méthodes) à un code de meilleur qualité.

De plus nous avons constaté qu’une conception de classe reflettait le fonctionnel et la cinématique de la page et de ses composants. Par exemple lors qu’il y a différente zone graphique cela correspond à des fonctionnalités distinctes : la recherche, la presentation d’un produit par exemple. L’idée est d’appliquer les concepts objets à ces
fonctionnalités : un objet pour gérer les composants graphiques de la recherche, et un autre objet pour la présentation d’un produit. Il existe aussi un autre concept qui est l’encapsulation. En effet, il y a des composants partagés entre les deux objets pour par exemple permettre la présentation d’un produit trouvé dans la recherche.

Ainsi, plusieurs concepts de programmation objet peut être appliqués à la réalisation d’une application GWT comme les concepts d’objet, encapsulation. Le pattern MVC est un pattern de structuration qui oblige à faire des classes Controller ou Action qui ne refléte pas une abstraction d’une interface (événement, composant, fonction, communication entre composants, …).

Nico parle de cadre, c’est vrai qu’il faut avoir une réflexion de conception prélimaire pour définir ce cadre, quel son les éléments de ce cadre (widgets, layouts, communication entre widget, événement, …).

Nicolas Le Coz (Xebia)

Pouvez-vous développer ce point? L’équipe s’est sentie plus à l’aise avec les patterns de conception propre à GWT ou au concept de RIA en général ? N’avez-vous pas souffert de manque de structuration du code ? c’est un retour que j’ai eu sur GWT, venant d’une équipe habituée au pattern MVC « classique ».
En tout cas merci pour cet article, très bon travail.

En tout cas, article intéressant. Merci.

Sinon, félicitations pour l’article, très intéressant, notamment sur les nouveaux frameworks RIA (Echo3, Silverlight, JavaFX : grand chelem !).

Bruno

Serait-il possible d’avoir des screenshots ( voir mieux des videos ) des différentes implémentations afin de comparer leur ergonomie ?