juin
2008
La présentation est faite par Maarten Volders.
Comme à chaque présentation de GWT il y a eu une petite introduction je ne vais donc pas vous la décrire.
La présentation est très intéressante, il nous a expliqué comment concevoir des applications web pour l’utilisateur et non pas pour le développeur. GWT va dans cette direction en générant un code JavaScript extrêmement diminué pour prendre moins de place lors des chargements. Typiquement pas de formattage du code variable très courte et pas de commentaires.
Il y a aussi une grande partie d’optimisation qui est réalisée grâce au « deferred binding » que je décrirai plus en détail dans mon reportage complet.
Une option intéressante qui a été présentée est la possibilité de compiler directement sur le serveur. Si l’on remarque que la machine du client est trop lente on peut passer la compilation au serveur.
Il a également préciser que l’on ne devrait pas utiliser de widgets si c’est juste pour faire de l’HTML.
Ensuite il a un peu présenter l’internationalisation qui est semblable à ce que l’on retrouve en Java. Puis il a abordé les problèmes que l’on rencontre avec AJAX au niveau des bookmarks et de l’historique de navigation. GWT permet de créer un historique pour les requêtes AJAX.
Pour finir il nous a présenté la gestion des erreurs et les « best practices » pour les gérer, les logs et les tests unitaires avec Selenium !
Petite déception : il n’a quasiment pas parler de Gears
J’ai peut-être mal compris… Je vais attendre les slides pour être sûr ! C’est vrai que sa me paraît aussi bizarre…
Je ne comprend pas trop cette histoire de lenteur du poste client ???
GWT te permet de compiler du code Java en Javascript.
Normallement, c’est sur la machine de développement qu’on code en Java et qu’on lance la compilation (il faut en effet que la machine soit performante).
On obtient un ensemble de fichiers html et javascript (autant de version que de locale et de navigateurs (les 4 : IE, FF, Opera, Safari).
Ce sont ces fichiers là (la partie cliente) qu’il faut mettre sur un serveur web.
La partie serveur reste classique.
Ensuite, la première fois, le navigateur client récupère ces fichiers javascripts et html et les mets dans son cache. Et bien entendu, c’est suivant les performance de la machine cliente que l’exécution du javascript se fait ressentir mais le serveur n’y peut plus rien.
Ben en fait comme j’ai pu comprendre, tu compiles le javascript côté serveur et tu envoies le code compiler au client sous forme de fichier. Tu peux même faire un compromis entre les deux d’après le bonhomme![;-)](https://blog.developpez.com/yoteco/wp-includes/images/smilies/icon_wink.gif)
Edit : Je suis bête ! C’est de toute manière compilé par le serveur… Mais il y a certains choix, notamment au niveau de l’internationalisation qui se font après coup et là si le client est trop long on peut passer une partie de la charge au serveur du moins je crois ! Si un expert pouvait confirmer…
salut
je comprends pas bien comment on peut compiler le javascript coté serveur :/ étrange ce truc.
P.S. : merci pour tes billets, c’est vraiment sympa de pouvoir suivre cet événement grâce a toi![:)](https://blog.developpez.com/yoteco/wp-includes/images/smilies/icon_smile.gif)