But du tutorial
- Montrer comment faire un lien direct sur un onglet d’un TabPanel (cela fonctionne quasiment de la même manière avec un DeckPanel d’ailleurs).
- Montrer comment gérer l’historique dans GWT (boutons précédent et suivant du navigateur).
- Montrer un pattern pour une application avec un TabPanel.
Rappels sur GWT
Tout d’abord, petite précision sur les TabPanel : c’est un composant GWT de type composite qui comprends une TabBar et un DeckPanel. A chaque élément de la TabBar est associé un Deck, et seulement un Deck à la fois peut être affiché. C’est donc un outil très pratique qui permet de facilement gérer une interface avec des onglets.
L’exemple que je vais décrire montre comment associer un lien direct à un onglet de notre TabPanel. On peut ainsi donner une URL affichant notre application avec la vue choisie.
La solution utilise le mécanisme d’historique de GWT, qui consiste à associer un fragment de l’url à un état de l’application. Par exemple, index.html#vue1 et index.html#vue2 présente la même application mais dans un état différent. “vue1″ et “vue2″ sont appelé des tokens et ces éléments sont passé au navigateur lorsque l’utilisateur utilise les boutons “précédent” et “suivant”. Cela permet d’améliorer l’intégration de l’application dans le navigateur, ce qui est crucial pour une application AJAX.
L’application
Voici l’application qui va nous servir d’exemple :
Lorsque l’on clique sur un onglet, le token correspondant s’affiche dans l’URL de l’application. L’utilisation des boutons “précédent” et “suivant” permettent de retracer l’historique de la navigation. De plus, on peut accéder directement à la vue voulue (vous avez envie de voir un bout… d’Italie? ).
Description du projet
- Tuto1 : point d’entrée de l’application. Se charge de créer les onglets et charge l’application dans la page HTML.
- Tuto1Page : gère le TabPanel et l’historique. D’après la liste d’onglets reçus, on créé une HashMap qui associe à chaque onglet son token d’historique correspondant.
- Package tab : gère le contenu des onglets. La classe abstraite TabAbstract permet de factoriser le code et favoriser l’ajout de nouveaux onglets.
Comment cela fonctionne ?
- Cas d’un lien direct : on analyse le token reçu et on se sert de notre hashMap pour décider quel onglet affiché.
- Cas d’un changement d’onglet par l’utilisateur : grâce à un listener sur la TabBar, on peut modifier le token existant pour le remplacer par celui du nouvel onglet affiché.
Le code est très “straightforward” donc je ne pense pas qu’il soit nécessaire d’entrer dans les détails d’ordre technique. J’en profite juste pour préciser les 3 points à respecter pour gérer l’historique :
- Implémentation de l’interface ValueChangeHandler<>
- Enregistrement de l’handler (History.addValueChangeHandler(this))
- Ajout du code HTML pour le support de l’historique dans Internet Explorer (<iframe src=”javascript:” ” id=”__gwt_historyFrame” tabIndex=’-1′ style=”position:absolute; width:0;height:0 ;border:0″> </iframe>)
Télécharger le code source de l’application
Lien vers l’application
Ce matin est sortit une nouvelle version majeure de GWT 1.6.
Lire l’annonce
Le support Java pour AppEngine n’est pas vraiment ce que j’attendais le plus pour mes projets à court terme mais, par contre, cela pourrait beaucoup m’intéresser dans quelques temps… J’irai donc faire un tour bientôt dans cette plate-forme Google, notamment pour sa gratuité (payante à partir de 5 millions de pages vues par mois, y’a de la marge :p) !
Concernant le plugin Eclipse, là c’était vraiment quelque chose que j’attendais. Je ne sais pas s’il me sera très utile vu que je n’utilise pas de servlets (et qu’il m’oblige à restructurer mes projets à la sauce 1.6 !), mais j’espère qu’il sera la solution à mon problème récent : avoir une structure de projet propre, qui contient plusieurs modules et où l’on peut facilement compiler chaque module séparément, quelque soit le système d’exploitation sur lequel on travaille… to be continued.
Déjà, pour quoi faire? Il y a déjà Safari et Firefox (entre autres), pourquoi s’encombrer avec un navigateur pas franchement recommandé? Eh bien… pour faire des tests ! Lorsque l’on fait un peu de développement web, on est toujours confronté à un problème de compatibilité entre les navigateurs, le dilemme étant de faire un site qui s’affiche correctement quelque soit le navigateur du client (cela ne veut pas dire que le site s’affiche de la même manière sur tous les navigateurs d’ailleurs).
Donc, avec MacOS X, on peut aussi installer IE6 sans utiliser tout un système Windows (via bootcamp, parallels ou vmware fusion par exemple) avec ies4osx : http://www.kronenberg.org/ies4osx/. Tout est très bien expliqué sur le site, et l’installation est très simple. Ce logiciel m’est vraiment utile dans la mesure où je n’ai pas encore trouvé de solution de virtualisation GRATUITE convenable pour émuler XP (et Ubuntu). Cerise sur le gâteau, c’est open-source :).
Tiens, c’est marrant… en écrivant ce billet je découvre qu’il existe aussi netrenderer, qui propose de vous afficher online la manière dont IE (5.5, 6, 7 ou 8, au choix !) affiche votre page. Alléchant mais malheureusement cela ne semble pas très bien marcher, notamment lorsqu’il y a du javascript sur la page.
Voici un script que j’utilise pour uploader une application GWT en cours de développement sur un serveur web :
1
2
3
4
5
6
7
8
9
10
11
| #! /bin/sh
./Project-compile
tar -cf project.tar www/#packageProject.client/*
ftp -n #ftp_address<<_FTP
quote USER #username
quote PASS #passwd
prompt
cd dirProject
lcd www/#packageProject.client
mput *
bye _FTP |
Quelques détails :
- La commande ligne 3 permet de conserver une sauvegarde de l’application tel qu’elle est sur le serveur web.
- Il faut répéter la ligne 8 autant de fois qu’il le faut pour se placer dans le bon répertoire. En effet, on ne peut pas utiliser la commande cd dir1/dir2/dir3.
- l’option -n ligne 4 permet de ne pas se connecter en mode interactif, indispensable pour utiliser le protocole FTP avec un script.
- Le changement de répertoire ligne 9 correspond à un changement de répertoire local
- Ce script n’upload pas les sous-répertoire de votre application compilée. Je n’ai en effet pas trouvé de commande qui puisse uploader tout le contenu d’un répertoire local, récursivement… Attention donc à ne pas oublier le répertoire gwt notamment ! Cela présente quand même l’avantage de ne pas ré-uploader par exemple un dossier contenant des images…
- Ce script est à placer à la racine de votre projet bien sûr
Si vous n’êtes toujours pas convaincu par GWT, ou si vous ne comprenez pas exactement de quoi il s’agit, voici une petite sélection d’articles qui reprennent le même thème : pourquoi GWT ?
Ce thème a été réalisé par Miguel Santirso. Il est disponible en vert, bleu et rose, mais comme cela ne me plaisait pas vraiment, j’ai réalisé une nouvelle feuille de style perso, avec quelques changements de forme par ci par là. Je n’ai pas de grande qualité en tant que designer mais je voulais tout de même un thème qui soit unique.
Il reste encore quelques petits problèmes d’affichages notamment avec les titres des posts sur Safari. Je vais essayer de corriger cela dans les jours à venir.
En tout cas, cela illustre bien la difficulté de réaliser un ensemble PHP/HTML/CSS qui, déjà, soit opérationnel sur tous les navigateurs, et ensuite qui soit interprété de la même manière. La résolution de ces problèmes est un aspect du développement web qui m’a toujours enervé. Cela me confortait dans l’idée de vouloir faire du développement logiciel , du vrai, avec un compilateur ou une machine virtuelle 
J’ai pourtant découvert (un peu par hasard) en ce début d’année 2009 le framework Google Web Toolkit (GWT). J’ai tout de suite été séduit par le fait de pouvoir produire, avec du code Java, du contenu interprétable par n’importe quel serveur web. Je classe les qualités de GWT dans 3 catégories :
- Java : intégration de GWT dans Eclipse, possibilité d’utiliser mes acquis en Java. Avec un serveur capable de gérer les servlets (Tomcat par exemple), on peut réaliser de véritable application web, sur le modèle de Gmail par exemple. Et même sans, on peut interagir avec tout type de serveur.
- Google : cela a sûrement des inconvénients, mais aussi des avantages. L’image de Google sur le produit permet de penser que le produit a toutes les chances de continuer d’évoluer dans le futur. Cela permet aussi de s’approcher des services Google (Maps, Visualization etc…) omniprésent sur le web.
- Javascript : Web 2.0, AJAX… avec GWT on est en plein dans la nouvelle (?) mode du web. Je sais que d’autres frameworks AJAX existent, mais je ne les ai pas testé donc je ne dirai rien :). Quoiqu’il en soit, avec GWT, on a l’assurance que le code généré fonctionnera sur tous les navigateurs et l’on a tous les outils pour construire un client robuste.
Tout ceci me pousse donc à m’étendre sur le sujet, découvrir, approfondir.
