RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX
Après le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest dédié aux RIA.
Le but de cette journée était de développer une application de gestion de playlist de morceaux de musique. En promoteurs des méthodes Agiles, les spécifications furent données sous forme d’un Product Backlog. Trois sprints d’une durée de 90 minutes ont permis à tous de suivre l’évolution des différentes réalisations. Un web service SOAP fournissait les différentes données: Artiste, Album, Titres et Pochettes d’album.
Les frameworks RIA testés
Cinq équipes ont été constituées, cinq frameworks ont donc été choisis :
Le nombre d’équipes étant limité, la liste des frameworks choisis l’est aussi, et nous avons donc nécessairement mis de côté certains frameworks qui auraient certainement eu leur place dans le contest. Citons par exemple Ext JS, Yahoo! UI, Curl, XUL, ZK ou OpenLaszlo. Si vous avez une expérience sur un de ces frameworks, n’hésitez pas à la partager dans les commentaires de cet article!
Au terme de cette journée, chaque équipe a pu exprimer un retour d’expérience significatif, que vous trouverez ci-dessous.
Product Backlog
| Priorité | Nom |
| 10 | En tant qu’utilisateur, je peux visualiser la liste des catégories |
| 20 | En tant qu’utilisateur, je peux visualiser la liste des artistes |
| 30 | En tant qu’utilisateur, je peux consulter la liste des albums d’une catégorie |
| 40 | En tant qu’utilisateur, je peux consulter la liste des albums d’un artiste |
| 45 | En tant qu’utilisateur, je peux consulter la liste des pistes d’un album |
| 50 | En tant qu’utilisateur, je peux rechercher un album |
| 60 | En tant qu’utilisateur, je peux consulter la liste des playlists enregistrées |
| 70 | En tant qu’utilisateur, je peux charger une playlist existante |
| 80 | En tant qu’utilisateur, je peux créer et enregistrer une nouvelle playlist |
| 90 | En tant qu’utilisateur, je peux ajouter des pistes à une playlist |
| 95 | En tant qu’utilisateur, je peux réordonner les pistes d’une playlist |
| 97 | En tant qu’utilisateur, je peux enlever des pistes à une playlist |
| 100 | En tant qu’utilisateur, je peux sauvegarder une playlist |
| 110 | En tant qu’utilisateur, je peux supprimer une playlist |
Flex
Le premier sprint a été consacré :
- A la création du layout de l’interface, à l’aide du langage MXML. Pour cette étape, Flex Builder a été d’une aide précieuse et nous a permis d’être productif.
- A la mise en place du proxy SOAP et de la ‘
destination‘ vers le web service du backend. Pour ce faire nous avons utilisé BlazeDS. Vous pouvez trouver sur le wiki d’Adobe un exemple d’utilisation du proxy BlazeDS.
Le second sprint a été l’occasion de :
- Mettre en place le binding entre les résultats d’invocation des web services et le layout (cliquez ici pour une description du mécanisme de databinding dans Flex)
- De mettre en place la gestion des événements.
Arrivée au troisième et dernier sprint, l’équipe était très à l’aise avec Flex. Celui-ci a donc été l’occasion de compléter les fonctionnalités et très rapidement de refondre l’interface et d’y ajouter un ensemble d’effets visuels.
Points forts
- Facilité de prise en main: le coût d’entrée pour un développeur d’applications web Java est réduit, les composants MXML sont simples à utiliser, et le langage ActionScript se rapproche fortement de JavaScript (ils implémentent tous deux la spécification ECMAScript)
- Richesse des composants (nombreux composants de haut niveau) (voir le component explorer Flex 3)
- Communauté active : facilité de trouver des ressources de qualité (exemples, tutoriels, mailing lists) sur le web.
Points faibles
- Flex Builder ne propose pas de compilation à la volée du code mxml (peut être dû à un souci sur notre environnement de développement)
- Tester notre code directement dans Flex Builder n’est pas possible sans déploiement (mais un simple serveur Apache ou Tomcat fait l’affaire)
- L’adaptation au modèle documentaire Adobe (style javadoc) n’est pas sans douleur
Silverlight
Version Microsoft de l’approche RIA à base de plugins, Silverlight permet l’exécution d’applications web riches au sein de moteur de rendu vectoriel. Avec l’arrivée de Silverlight 2, Microsoft enrichit de façon notable sa technologie et rattrape son retard sur ses concurrents.
Même si elle propose une intégration forte et séduisante avec les technologies DotNet, Silverlight ne se reste pas pour autant limité à celles-ci. C’est d’ailleurs dans ce contexte de cohabitation particulier, FrontEnd Silverlight / BackEnd Java, que le contest s’est déroulé.
Points forts
- Silverlight utilise un descripteur d’interface utilisateur en XAML, dérivée de fichier XML pour définir son UI. Contrairement à ses concurrents, ce format est directement interprété par le plugin, aucune compilation n’est nécessaire, facilitant ainsi le déploiement et le débogage. De plus, ces fichiers .xaml sont directement packagés dans des archives .XAP (donc ZIP) qui permet d’espérer une indexation aisée des éléments statiques par nos moteurs de recherches préférés.
- Il est ensuite possible de scripter ces UI en utilisant soit le langage Javascript, soit n’importe quel langage supporté par .net (C# par exemple). Vous écrivez donc du C# sur la partie cliente de la même façon que sur la partie serveur.
- Une application Silverlight ne requiert pas forcément de backend server.
- Visuellement, Silverlight nous permet d’ajouter des effets et des animations proches de ce que fait Flex.
- Prise en main plutôt facile, dès le 1er sprint (1h30) on avait un début d’interface (sans compter le temps de l’installation)
Points faibles
- Manque flagrant de maturité par rapport à son rival. Silverlight devrait sortir de sa version bêta sous peu.
- Installation longue et complexe pour des développeurs non familiers avec la technologie .net : .net framework, Visual Studio Pro et son extension Silverlight pour faciliter la programmation, et Expression Blend pour faciliter la création d’interfaces. Il est d’ailleurs rageant d’avoir à utiliser un outil séparé pour créer ses écrans. En outre l’éditeur de composant de Visual Studio n’est pas assez puissant, il ressemble plus à une preview qu’à un véritable éditeur WYSIWYG
- XAML peut devenir rapidement volumineux (même si nous présumons que nous avons mal développé nos composants). L’exemple Microsoft dont nous nous sommes inspiré utilise par exemple 5 à 10 formes de base pour un simple bouton.
- Si la communication avec un backend .net semble aisée, il n’en est pas de même pour un backend Java. Silverlight nous permet, sur le papier, de nous connecter très facilement via Webservices ou la technologie REST (un simple clic droit, ajoutez un service web semble suffisant). Dans la réalité, nous n’avons jamais réussi à communiquer avec notre backend Webservice Java généré par CXF. D’autre part, Silverlight ne possède pas de protocole binaire permettant d’optimiser les échanges.
- Linux est supporté via Moonlight, mais on peut craindre que l’implémentation Linux n’ait toujours une longueur de retard par rapport aux releases Windows et Mac. D’autre part, qu’en est-il du plugin Silverlight sur téléphone mobile si le téléphone ne fonctionne pas sur Windows Mobile?
- Silverlight fonctionne uniquement dans un navigateur, il n’existe pas d’équivalent à Adobe AIR pour Silverlight.
Tous ces points négatifs doivent être tempérés, n’oublions pas qu’il ne s’agit que d’une version bêta!
Google GWT
Google Web Toolkit propose une approche différente des autres frameworks RIA :
- Tout d’abord le développeur réalise l’interface graphique entièrement en Java en utilisant les API fournies par GWT.
- Ensuite, avec les outils GWT, le code précédemment produit est parsé afin de générer l’équivalent en HTML et Javascript.
L’objectif premier de GWT est de confier la réalisation d’une application Web à un développeur Java, sans que ce dernier n’ait à maîtriser les particularités de fonctionnement des navigateurs : le compilateur GWT génère automatiquement, à partir du code Java, le code HTML/JavaScript adéquat et portable sur différents navigateurs.
Pour le RIA Contest, l’équipe GWT a utilisé : GWT 1.5 et la surcouche GWT-ext-2.04
Grâce à GWT, le développement des fonctionnalités demandées a été réalisé assez rapidement. A l’issue des premiers sprints les 5 premières fonctionnalités ont été implémentées entièrement.
Pour l’équipe GWT, la principale cause de perte de temps est dûe à des composants GWT-ext. Certains composants GWT-ext ne fonctionnaient pas toujours de manière déterministe, sans compter leur prise en main difficile (exemple : l’arbre ou la liste). Finalement l’équipe GWT s’est retranchée sur les composants GWT (mieux documentés).
L’équipe GWT a appris une leçon au cours de ce RIA contest qui est de privilégier l’utilisation des composants fournis par GWT. D’une part ils fonctionnent très bien, et d’autre part ils sont simples d’utilisation. Même si le contexte de développement favorisait le développement sans conception, un refactoring a été réalisé très simplement grâce aux outils d’Eclipse (extraction de méthode, découpage de classe). L’équipe a pu pointer du doigt un point fort de GWT concernant la conception d’une interface graphique : une conception plus riche (conception par concept métier ou/et fonctionnalité de la page) par rapport au modèle classique MVC (type action, jsp).
Points forts
- Compétences : tout le développement de l’interface est effectué en Java. De plus l’utilisation de Java 5 est un réel apport sur les versions antérieures de GWT. Cependant afin de personnaliser, améliorer le rendu et le rendre plus sexy, il est nécessaire de manipuler des feuilles de style CSS.
- Paradigme : Le modèle de programmation événementielle est très intuitif pour un développeur Java, et ce n’est pas sans rappeler la programmation Swing. Cependant GWT reste plus simple, car il n’y a pas l’aspect programmation concurrentielle et déploiement sur le poste client.
- Productivité : permet de développer une application RIA (1 écran) très rapidement. Le code produit est très maintenable (c’est du Java).
- Outillage : les outils fonctionnent correctement : script de génération du squelette de l’application, l’intégration avec Eclipse (Host Mode, debugging de la partie cliente et serveur)
- Bonne courbe d’apprentissage : les outils fournis par GWT sont d’une fiabilité remarquable. Cela permet de rapidement monter un projet « HelloWord » et de le lancer dans un navigateur (ou le GWTHost). De plus, le fait de manipuler du langage Java permet d’être directement productif.
Points faibles
- Pauvreté des composants : la librairie de composant GWT-ext n’est pas à la hauteur de GWT au niveau utilisabilité et robustesse. GWT doit encore travailler sur ses composants graphiques afin d’arriver au niveau de Flex. Vus les progrès sur ce point dans la version 1.5 de GWT et les bases solides du framework, on peut rester très optimiste sur l’amélioration de cet aspect.
- Il y a des conventions de programmation qui empêchent le bon fonctionnement des outils de refactoring, comme par exemple le pattern d’appel asynchrone. De manière générale, on peut regretter que GWT ne tienne pas compte des bonnes pratiques acquises dans le développement d’applications en Java.
- Intégration : l’intégration dans l’existant n’est pas si facile tant au niveau des technologies qu’au niveau du packaging. Un exemple concret : comment intégrer de manière élégante un modèle métier existant comme modèle de données pour l’interface sans faire de DTO?
- Une application plus complexe doit demander une bonne expertise du framework pour découper correctement les différents composants
- Mauvaise courbe de mise en œuvre : il y a des points un peu flous et des pièges à éviter. Par exemple, la mise en oeuvre d’un appel RPC demande de bien mettre en place la convention fixée par GWT, de même pour le binding d’objet.
Echo3
Echo est une plateforme de type RIA orientée composant et évènement. La version 3 est aujourd’hui en beta 1. Cette version propose de développer soit directement côté client en javascript, soit côté serveur en Java.
L’API Server, utilisée pour le contest, permet de développer l’interface utilisateur dans une logique proche de Swing (Composants, Layout et évènementiel).
Le framework Echo se veut concurrent de GWT dans la mesure où il permet le développement d’applications entièrement server-side. Une particularité cependant est qu’il ne possède pas de phase de pré-compilation Java vers Javascript. Durant l’exécution l’état des composants est sérialisé puis envoyé vers le client qui effectue le rendu des composants grâce à la librairie Javascript de Echo.
Bien que méconnu, ce framework a été choisi comme challenger GWT. En effet, il en possède plusieurs aspects intéressants, comme le développement intégral server-side et la gestion de l’évènementiel. Mais l’absence de phase de précompilation Javascript et la simplicité d’intégration avec Maven sont des avantages qui nous ont tenté.
Points forts
- Accessibilité : Facile à mettre en oeuvre et à déployer, quelques minutes suffisent pour obtenir une première application type « hello world ».
- Flexibilité : Possibilité de choisir son mode de développement, application server-side (développement 100% Java) ou client-side (développement 10% Java, 90% Javascript).
- Intégration : Echo s’appuie directement sur l’API servlet et ne nécessite rien de plus que le déploiement d’une application web avec sa servlet proprement configurée.
- HTML Agnostic : Aucune connaissance HTML, JavaScript ni CSS n’est nécessaire pour la conception d’une application.
Points faibles
- Documentation : seule existe la documentation officielle, qui est encore en cours d’écriture, et la javadoc est très limitée en commentaires.
- Contenu : Peu de composants ‘haut niveau’ (pas de Datatable par exemple). On est obligé d’étendre l’existant pour obtenir des composants évolués. De plus, certaines fonctionnalités offertes par l’API ne sont pas encore implémentées au niveau du moteur de rendu (Echo3 est toujours en beta1).
- Communauté : Echo2 ne bénéficie déjà pas d’une grosse communauté, et Echo3 est en beta donc encore très peu utilisé.
- Eye candy : Il manque de précieux effets visuels (notamment le drag’n'drop) et des styles embarqués, permettant aux non-graphistes de facilement créer une jolie interface.
Java FX
JavaFX est la réponse de Sun à Flex et aux autres frameworks RIA. Présenté il y a un an à la conférence JavaOne 2007, puis cette année encore à l’édition 2008, JavaFX se fait attendre. Pour nous faire patienter, Sun a sorti une pre-release, incluse avec NetBeans 6.1.
Les 2 premiers sprints ont été consacrés à la réalisation de l’IHM à l’aide du langage de script JavaFX. L’équipe a eu quelques difficultés à implémenter la première fonctionnalité, heureusement l’exemple de playlist de James Weaver a été d’un grand secours. Le code est toutefois d’assez bas niveau puisque l’affichage d’un tableau se fait en dessinant des rectangles que l’on déplace pour représenter les lignes du tableau.
Passée cette mauvaise surprise, il fut très facile d’intégrer l’appel du webservice. En effet le script JavaFX permet d’appeler naturellement des classes Java, en l’occurrence CXF. La sérialisation / désérialisation étant réalisée par ce framework, la manipulation du XML est transparente, et il est aisé d’afficher les propriétés ad-hoc des objets vers le tableau.
Il fut plus délicat d’arriver à rafraîchir automatiquement les listes, mais une fois le binding compris et assimilé, là aussi cela se fait de manière transparente.
Le dernier sprint a été l’occasion d’essayer quelques effets graphiques, par exemple faire tourner la pochette des albums. Ce n’est pas très utile, mais c’est quand même impressionnant !
Points forts
- Communauté : JavaFX s’appuie sur du Java, très largement répandu
- Scripting : malgré une syntaxe un peu différente du Java et quelques nouveautés, JavaFX Script simplifie l’écriture d’interface comparé à Swing. On apprécie particulièrement le binding.
- Intégration : il est très facile d’appeler du code Java depuis un script JavaFX
- Return of the applet : il est possible de détacher une applet du browser pour la mettre sur le desktop (à partir de Java SE 6 update 10)
Points faibles
- Outillage : NetBeans possède un début de plugin pour JavaFX Script, mais il est encore assez bugué.
- Documentation : la documentation est assez mince et les exemples sont souvent difficiles à reprendre
- Manque de composants : il n’y a aucun composant graphique « évolué ».
JavaFX n’est évidemment pas mature, rappelons qu’il ne s’agit que d’une preview. Malgré les difficultés rencontrées, nous gardons l’impression agréable de pouvoir faire des interfaces jolies en Java, et assez simplement grâce au langage de script JavaFX. La preview est plutôt prometteuse, mais il reste encore beaucoup de travail pour aboutir à un vrai produit. Il faudrait enrichir l’API avec des librairies de composants graphiques et offrir un vrai support pour les IDE, et pas seulement NetBeans. Heureusement Sun peut compter sur la communauté Java pour l’aider à combler ces défauts.
Il va cependant falloir courir vite pour rattraper un Flex déjà bien lancé.
Alors qui est le gagnant ?
Au terme de cette journée, l’équipe Flex, s’est nettement démarquée de ses concurrentes. Après deux sprints de mise en place et de prise en main, elle a pu consacrer le troisième et dernier sprint à l’enrichissement rapide et aisé de l’application, se concentrant uniquement sur les aspects fonctionnalités et expérience utilisateur.
C’est grâce à la richesse des composants de haut niveau, à la richesse de la documentation disponible et a la maturité du framework que l’équipe Flex a réalisé l’application la plus aboutie.
L’année dernière Wicket fut la révélation du Xebia Web Framework Contest. Cette année, peu de surprises, même si GWT semble avoir atteint le bon niveau de maturité.
[...] Voici le lien des résultats : http://blog.xebia.fr/2008/10/03/ria-contest-flex-silverlight-gwt-echo3-javafx/ [...]
Résultats très intéressant.
Serait-il possible d’avoir des screenshots ( voir mieux des videos ) des différentes implémentations afin de comparer leur ergonomie ?
Pour GWT et l’intégration avec un modele de données existant, je ne peux que conseiller hibernate4gwt… puisque j’en suis l’auteur
D’ailleurs, BlazeDS souffre exactement du même problème avec un Domaine géré par Hibernate…
Sinon, félicitations pour l’article, très intéressant, notamment sur les nouveaux frameworks RIA (Echo3, Silverlight, JavaFX : grand chelem !).
Bruno
With flex you can use GraniteDS, an open source alternative of blazeds and has a lazy loading support for hibernate model.
[...] back-ends) qui différentient nettement Flex de la concurrence (ce n’est pas le tout récent exercice des équipes de Xebia qui diront le contraire !), nos équipes ont adopté Flex pour leur projets futurs car leur premier [...]
Belle initiative.
J’aime bien cette démarche commando qui, bien qu’elle ait ses limites, permet de flairer les tendances et la maturité de certaines technos.
Merci !
[...] Flux RSS « RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX [...]
Une précision sur GWT. Concernant la pauvreté des composants, il existe une surcouche alternative à GWT-Ext, nommée Ext GWT (supportée par la société ExtJS, on retrouve donc les même look&feels), à la hauteur au niveau de la robustesse et de l’utilisabilité. Cette surcouche facilite également l’intégration avec un modèle d’objets existants, et il y aussi Hibernate4GWT pour l’intégration avec Hibernate, comme l’a souligné Bruno.
En tout cas, article intéressant. Merci.
« L’équipe a pu pointer du doigt un point fort de GWT concernant la conception d’une interface graphique : une conception plus riche (conception par concept métier ou/et fonctionnalité de la page) par rapport au modèle classique MVC (type action, jsp). »
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.
[...] http://blog.xebia.fr/2008/10/03/ria-contest-flex-silverlight-gwt-echo3-javafx/ [...]
@Fanch : si je puis me permettre, en tant qu’utilisateur de GWT depuis plusieurs mois, je trouve également que GWT manque d’un cadre aidant à structurer le code. GWT fournit vraiment la base du développement (outils + compilateur) mais il manque en effet ce cadre ainsi que des widgets déjà « habillés ». En revanche, l’ajout de la surcouche Ext GWT comble (entre autres) ces manques, bien que la « fonctionnalité » MVC ne soit pas encore bien documentée.
Bonjour Fanch,
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)
Bonjour Nico,
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)
Bonjour,
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
Merci Gaetan pour ce retour terrain très pertinent. Il est en effet important de ne pas se tromper sur la nature de ce contest.
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
[...] RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX [...]
Pardon, je ne comprend pas. Parlez-vous anglais?
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
[...] les avantages et inconvénients de différents framework RIA, nous annoncions un certain nombre de points négatifs sur la version Silverlight que nous avions utilisée (Silverlight 2 Beta 2). Microsoft comble avec [...]
Personnellement, je pense que Zk (www.zkoss.org) gagne à être plus connu par rapport à GWT (cfr : http://ria.dzone.com/articles/zk-vs-gwt-server-centric-matte-1). Pour les architectes /développeurs qui ne souhaitent pas s’investir de trop dans le monde du javascript (AJAX) puisque celui-ci est généré par le framework et sont amenés à prendre en charge le développement du côté serveur, ce framework (basé sur XUL) est réellement intéressant. Celui-ci s’intègre facilement à des pages JSP, JSF si nécessaire et ceci afin de ne pas devoir développer des pages zul. De plus, il est maintenant possible de l’utiliser avec Spring, Hibernate voir Spring WebFlow et Seam. Pour les amateurs de l’approche cometd, celui-ci permet de pusher les données du serveur vers le browser (ce qui n’est pas le cas de GWT – polling approche). Bref, le framework est simple, efficace et nous permet de ganger bcp de temps dans le développement d’applications J2EE basée sur un RIA.
Charles, il est tout a fait possible de travailler avec GWT en pushing selon le modèle cometd. C’est ce que j’ai démontré l’année dernière lors d’un barcamp Sun avec une maquette de client vnc web (WEBVnc, sources dispo sur google code).
Nicolas, concernant le test de GWT (puisque c’est toi à priori qui a travaillé dessus), j’ai le sentiment que tu as été influencé par Marc en utilisant tout de suite une extension au framework (GWT-Ext).Heureusement, tu es arrivé rapidement aux mêmes conclusions que moi : autant utiliser les composant de base. Pour le reste, j’aurais aimé voir apparaitre dans les points faibles un élément majeur : le temps de compilation Java -> JS. Ce temps s’est considérablement allongé entre GWT 1.4 et 1.5. J’ai l’expérience de deux projets GWT pro et je peux assurer que c’est vraiment pénalisant. Mais je comprends que vous ne l’ayez pas ressenti sur votre mini projet. Encore un dernier point faible sur GWT : la compatibilité inter navigateur. C’est même le cheval de bataille de ce framework. Et bien sachez qu’il reste des différence de comportements entre IE et FF. Avec une bonne expérience du framework, on arrive à écrire le bon code java qui donnera le bon js mais c’est un peu dommage.
Bonjour,
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
Bonjour Cyril,
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).
[...] les OS Linux et Solaris ne sont pas (encore) supportés. Cette version 1.0 tient elle malgré tout les promesses entrevues lors de la parution de la preview ? Et bien, pas vraiment. Les défauts rédhibitoires que nous y avions décelés sont toujours là [...]
Bonjour,
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
Bonjour,
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.
Sans parler du fait que la license d’Ext js est une GPL.
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.