GWT

A la fin du précédent article, nous en étions restés à une application GWT testée unitairement : tous les comportements des contrôleurs sont testés les points difficiles des vues sont testés Ces tests sont exécutés avec JUnit ou Maven, comme n'importe quel autre test. Nous sommes donc capables de lancer l'application GWT dans une JVM standard. Rien ne s'affiche, mais toutes les classes sont instanciées, et les comportements sont implémentés. Par contre la partie serveur (qui reçoit les appels GWT-RPC) est mockée. La faiblesse de…

Dans le précédent article, nous avons démontré qu'il n'était pas si facile de faire des tests avec GWT car : La classe de test de base, GWTTestCase est trop restrictive (impossible d'utiliser des outils de tests), et est source de lenteurs Le mock de composants GWT requiert l'utilisation d'interfaces intermédiaires plutôt que des classes de composants, ce qui induit un gros travail de refactoring sur les projets existants Nous avons donc mis en place une solution alternative...

GWT est un framework permettant de créer une interface Web riche en Java plutôt qu'en HTML et Javascript. La programmation de l'interface ressemble beaucoup à du Swing : new Panel(), new Button(), add ClickListener... C'est une approche assez séduisante : pas besoin de connaître un nouveau langage, possibilité de réutiliser les outils que l'on utilise en Java... De plus, comme tout est en Java (même la partie vue du modèle MVC!), on devrait donc pouvoir faire des tests sur l'IHM. Essayons donc.

Développer, tester et exécuter des applications GWT est facile avec le plugin "GWT for Eclipse". Mais ce plugin n’est pas vraiment adapté pour Maven2, l’arborescence de dossiers qu’il requiert n’étant pas conforme au standard des applications web buildées avec Maven. Aujourd'hui, nous allons nous concentrer sur le développement et l'exécution d'application GWT via Maven et Eclipse. Les tests seront couverts dans un autre article, à paraître prochainement.

Le temps de chargement d'une application informatique est un point essentiel en terme d'usabilité. Il a un impact important sur l'expérience utilisateur, tellement important qu'il peut être le facteur décisif d'adhésion ou de rejet de l'application par les utilisateurs qui se font un avis en 2-3 secondes. On a tous des exemples douloureux en tête... ou pas d'ailleurs... et c'est bien ça le drame : ces applications passent aux oubliettes!

De base le toolkit GWT vient avec son framework d'échange : GWT-RPC. Aucun problème particulier dans son fonctionnement mais quelques limitations à la fois dans la configuration que l'on pourra qualifier d'un "peu lourde", ainsi que dans l'intégration avec un existant (typiquement un existant Spring).

Intégrer de multiples partenaires et applications et donner une vision unifiée et simple à l’utilisateur passe souvent et entre autre par la mise en place d’une brique de SSO. Dans ce domaine, CAS (Central Authentication Service) fait très certainement partie des référents. Reste que lorsque l’on m’a demandé si l’intégration d’applications GWT avec CAS était réalisable facilement, j’étais bien incapable de répondre…

Cette partie complémente la précédente et propose une autre solution d'implémentation des applications web en mode déconnecté, une solution où connecté et déconnecté sont vus de manière transparente par l'utilisateur...