Ce type de pagination contraint l’utilisateur à effectuer plusieurs clics pour avancer à travers les données paginées, et atteindre sa page cible. Pour améliorer ce comportement, un ergonome et moi avons proposé une nouvelle stratégie de pagination permettant d’atteindre la page souhaitée avec un minimum de clics, tout en gardant un comportement proche d’une pagination classique (pagination des pages). Le résultat de notre travail est un contrôle scroll permettant de paginer à travers les données en utilisant la fonctionnalité drag-and-drop.

L’expérience tactile des utilisateurs et la résolution fixe du terminal nous imposait certaines règles à respecter pour une interaction facile et aisée avec l’application :

• La barre de scroll doit avoir une taille fixe (56 pixels dans mon exemple) pour mieux interagir avec les doigts des utilisateurs.
• Le contrôle scroll (boutons de navigation+espace de scrolling) doit avoir une hauteur fixe selon le nombre de lignes par page et la résolution du terminal. (L’affichage du scroll navigateur est banni)

Une fois le travail réalisé, j’ai trouvé intéressante l’idée de partager cette expérience de code avec des personnes sensibles à l’ergonomie et à l’utilisabilité des interfaces web.

Le Design

Le contrôle Scroll est sensible aux évènements suivants : click, drag-and-drop, et mouse-wheel. Il est composé essentiellement des éléments suivants :

• Deux boutons de navigation pour avancer et reculer d’une page.
• Un espace de scrolling.
• Une barre de scroll pour changer de page.

Les boutons de navigation sont des boutons cliquables qui par souci de design ont la même hauteur qu’une ligne de données. L’espace de scrolling est défini sur la base de nombre de lignes maximum par page. La barre de scroll est un bloc graphique draggable dans l’espace de scrolling. La taille de ce bloc dépend du nombre total de pages remontées par le serveur et de la contrainte de taille des doigts des utilisateurs de l’application.

Les évènements click et mouse-wheel sont branchés sur l’espace scrolling pour permettre une meilleure expérience utilisateur. L’évènement drag-and-drop est branché sur la barre de scroll pour naviguer à travers les données en utilisant cette partie du composant.

La barre de scroll peut avoir une taille dynamique seulement si le nombre total de pages est inférieur à 6 (valeur définie dans mon exemple et correspondant à la résolution maximale utilisée par mon application, vous pouvez redéfinir cette valeur selon vos spécifications). Dans ce cas la taille de la barre de scroll est générée par une formule de calcul et dépend de la taille de l’espace de scrolling et du nombre de pages.

Si le nombre total de pages est supérieur ou égal à 6, la barre de scroll générée par la formule de calcul devient trop petite pour les doigts de l’utilisateur. J’utilise alors une formule de calcul pour générer une barre de scroll à taille fixe quelque soit le nombre de page.

La structure HTML

Pour une meilleure intégration avec les styles CSS, la structure HTML du composant scroll est basée essentiellement sur des balises DIV. Les identifiants avec marqueurs sont nécessaires pour intégrer plusieurs instances du composant scroll dans la même page. Les classes CSS définissent les styles, et le positionnement des éléments dans la page.

<!--Le composant scroll-->
<div id="scrollComponent#{marker}" class="scrollComponent">
       <!--Bouton de navigation (Reculer d’une page)-->
       <div id="scrollUpButton#{marker}" class="scrollUpButton"></div>
       <!--Espace de scrolling-->
       <div id="scrollBarContainer#{marker}" class="scrollBarContainer">
            <!--Barre de scroll-->
            <div id="scrollBar#{marker}" class="scrollBar">
                 <label id="pageNumberLabel#{marker}" class="pageNumberLabel"></label>
            </div>
       </div>
       <!--Bouton de navigation (Avancer d’une page)-->
       <div id="scrollBottomButton#{marker}" class="scrollBottomButton"></div>
</div>

Les styles CSS

Les styles CSS permettent de donner l’aspect visuel du composant Scroll. Le JavaScript est nécessaire pour calculer les dimensions, positionner et afficher les différentes briques du composant scroll en fonction du nombre des pages et des paramètres avancés par l’application.

Le composant scroll

Le style appliqué permet de définir la largeur du composant scroll. Il définit également l’image de fond, et les images des boutons de navigation dans les données et leurs positions.

.scrollComponent {
 width:46px;
 background-image: url("./images/scrollup.png"), url("./images/scrolldown.png"), url("./images/contenu.png");
 background-repeat: no-repeat, no-repeat, repeat-y;
 background-position: center top, center bottom, center top;
}

L’espace de scrolling

Le style appliqué permet de définir la largeur de l’espace de scrolling. La hauteur est calculée en fonction du nombre des lignes maximum à afficher par page.

.scrollBarContainer {
        width:46px;
}

La barre de scroll

La classe CSS scrollBar permet de définir la largeur de la barre du scroll, son positionnement, ses bordures, et son image de fond. La taille de la barre de scroll est calculée selon le nombre de pages. La classe CSS pageNumberLabel permet de définir le positionnement, les propriétés de la police des caractères, et la largeur du libellé utilisé pour l’affichage de la page en cours.

.scrollBar {
 position:absolute;
 width:39px;
 margin-left:4px;
 -webkit-border-radius:150px;
 -moz-border-radius:150px;
 -o-border-radius:150px;
 border-radius:150px;
 background-image:url("./images/texture.png");
}
.pageNumberLabel {
 position:absolute;
 top:40%;
 width:37px;
 font-family:Trebuchet MS,Arial,Helvetica,Jamrul,sans-serif;
 font-size:9px;
 color: #FFFFFF;
 font-weight: bold;
 text-align: center;
}

Les boutons de navigation

Le style appliqué sur les boutons de navigation permet de définir le type de curseur en survolant ces briques.

.scrollUpButton {
 cursor: pointer;
}
.scrollBottomButton {
 cursor: pointer;
}

Le script JavaScript

Le script ci-dessous, permet de définir les propriétés du composant scroll, et de brancher les événements click, drag-and-drop et mouse-wheel sur les différentes briques du composant scroll.

Initilisation du composant scroll

En premier lieu, le script doit définir les dimensions des différentes briques du composant scroll ainsi que leur positionnement. Pour cela, nous avons utilisé la fonction css de jQuery pour accéder et modifier les propriétés des différents styles.

Nous commençons par initialiser la taille de la barre de scroll et la sensibilité de déplacement dans l’espace de scrolling. Ces propriétés sont définies suivant le nombre total de pages et le nombre maximum de lignes à afficher par page.

Si le nombre de pages est inférieur à 6 :

// Hauteur dynamique de la barre de scroll selon le nombre de pages (1)
scrollBarHeight = ((maxRowsPerPage-2) * rowHeight) / totalPages;
// 2 correspond aux boutons de navigation qui sont font partie de l'espace de données.
// Sensibilité de déplacement de la barre de scroll (2)
sensibility = ((maxRowsPerPage-2) * rowHeight) / totalPages;

Si le nombre de pages est supérieur ou égal à 6 :

// Hauteur fixe du composant scrollBar (1)
scrollBarHeight = ((maxRowsPerPage - 2) * rowHeight) / 6;
var oldsensibility = ((((maxRowsPerPage-2)  * rowHeight) / totalPages) - (scrollBarHeight / totalPages));
var diff = (((rowHeight * maxRowsPerPage) - (rowHeight+scrollBarHeight)) -
           (rowHeight + (oldsensibility * (totalPages - 1))) ) / (totalPages - 1);
// Sensibilité de déplacement du composant scrollbar (2)
sensibility = oldsensibility + diff;

Le positionnement de la barre de scroll, et les dimensions des autres briques du composant scroll sont définies par la suite.

// Positionnement du scrollbar selon la page courante (3)
scrollBarBottom = parseFloat(scrollUpButton.position().top)+rowHeight;
var initialScrollBarTop = scrollBarBottom + ((currentPage * sensibility) - sensibility);
scrollBar.css('top',initialScrollBarTop+'px');
// Définition de la taille du composant scroll (4)
scrollComponent.css('height', maxRowsPerPage * rowHeight+'px');
// Définition de la taille d'espace de scrolling (5)
scrollBarContainer.css('height', (maxRowsPerPage - 2) * rowHeight+'px');
// Définition de la taille des boutons de navigation (6)
scrollUpButton.css('height',rowHeight+'px');
scrollBottomButton.css('height',rowHeight+'px');
// Définition de la taille de la barre de scroll
scrollBar.css('height',scrollBarHeight+'px');
// Numéro de page courante (7)
pageNumberLabel.html(currentPage + '/' + totalPages);

Évènements click sur les boutons de navigation

Nous utilisons l’évènement click de l’API jQuery pour utiliser les boutons de navigation.

// Reculer d'une page
scrollUpButton.click(function() {
    previousPage();
});
// Avancer d'une page
scrollBottomButton.click(function() {
    nextPage();
});
// Avancer d'une page
function nextPage() {
    if (currentPage == totalPages) return false;
    currentPage = currentPage + 1;
    changePage();
}
// Reculer d'une page
function previousPage() {
   if (currentPage == 1) return false;
   currentPage = currentPage - 1;
   changePage();
}
// Changer les propriétés de la barre de scroll
function changePage() {
    // Nouvelle position selon la page en cours
    var newTop = scrollBarBottom + ((sensibility * currentPage) - (sensibility));
    scrollBar.css('top',newTop+'px');
    // Mise à jour du numéro de la page
    pageNumberLabel.html(currentPage + '/' + totalPages);
}

Évènement drag-and-drop sur la barre de scroll

Pour donner la vie à notre barre de scroll, nous utilisons la fonction draggable de l’API jQuery UI.

// Evènement DragAndDrop sur le scrollbar
scrollBar.draggable({ axis:'y', opacity: 0.70, currentPage: 'pointer', containment: "#scrollBarContainer"+componentId,
    stop: function(event, ui) {
        // Changer les propriétés de la barre de scroll
        changePage();
        // Charger la page en cours
        loadPage();
    },
   drag: function(event, ui) {
        // Définir la page en cours selon la position de la barre de scroll dans l'espace de scrolling
        var p = scrollBar.position();
        var scrollBarPosition =  parseFloat(p.top+sensibility);
        currentPage = Math.round((scrollBarPosition - scrollBarTop) / sensibility);
        pageNumberLabel.html(currentPage + '/'+ totalPages);
   }
});

Évènement mouse-wheel sur l’espace de scrolling

Pour gérer la souris molette ou le mouse-wheel, nous utilisons le plugin mousewheel de l’API jQuery. Pour des performances optimales, nous attendons un laps de temps après l’arrêt pour charger la dernière page sélectionnée. Toutefois, la barre de scroll change de position pour une meilleure interaction avec l’utilisateur.

// Evènement molette souris sur le composant scroll
scrollComponent.bind('mousewheel', function(event, delta) {
    var direction = delta > 0 ? 'Up' : 'Down';
    if (direction =='Up') {
        previousPage();
    }
    else if  (direction =='Down') {
        nextPage();
    }
    clearTimeout(jQuery.data(this, 'timer'));
    jQuery.data(this, 'timer', setTimeout(function() {
        loadPage();
    }, 250));
});
// Charger la page en cours
function loadPage() {
    if (alreadyLoadedPage != currentPage) {
        alreadyLoadedPage = currentPage;
        // Appel asynchrone pour charger les données ...
    }
}

Exemple d’utilisation

La fonction Ready de jQuery est utilisé pour activer le composant et définir ses propriétés une fois le document DOM est entièrement chargé.

jQuery(document).ready(initialiseScroll);
function initialiseScroll() {
      var scrollComponent = scrollComponentFunction({
                                             componentId: 'test1',
                                             currentPage : 1,
                                             totalPages: 5,
                                             maxRows: 10
                            });
}

Quelques exemples du composant scroll

Conclusion

Le projet de création de notre Framework UI vient en remplacement du Framework RichFaces qui constituait un frein à l’évolution de notre application à tous les niveaux : (développements, intégration avec d’autres technologies, tests IHM, performances des pages générées, évolutivité des composants de base …). En combinant quelques technologies et Frameworks de base (HTML, CSS, jQuery, jQuery UI, Java, …), nous avons réussi à créer des composants UI légers, performants et facilement intégrables … Utiliser des technologies de base pour développer notre propre Framework s’est avéré un pari gagnant. Toutefois, créer son propre Framework est un travail laborieux et couteux dans le temps mais les résultats sont plus que satisfaisants. Utiliser des technologies de base ou partir sur des Frameworks comme GWT, RichFaces … ? C’est un sujet auquel nous essayerons de répondre dans d’autres articles.

Ressources :

• Code source du projet

• Working Off the Grid: HTML5 Offline
• Bleeding Edge HTML5

Elles ont toutes été réalisées par des personnes de Google, preuve de l’implication de la compagnie dans le futur du HTML.

Il y avait aussi un sujet « Intro to HTML5 Game Programming – WebGL Edition » mais auquel aucun Xebian n’a pu assister: il faut bien faire un choix lorsque plusieurs sessions intéressantes sont en parallèle !

Working Off the Grid: HTML5 Offline

Sam Dutton de Google nous a présenté les différentes solutions de stockage hors ligne. Les problématiques adressées par ces technologies sont multiples:

• Problèmes de bande passante.
• Connexions peu stables.
• Amélioration des performances des applications web.
• Diminution de la consommation de ressources sur le serveur.
• Amélioration générale de l’expérience utilisateur.

Auparavant, nous ne disposions que de méthodes peu satisfaisantes: cookies, flash…

Maintenant, des solutions plus adaptées sont à notre disposition:

• Web Storage (localStorage/sessionStorage): permet de stocker de façon simple des paires clef/valeur.
• IndexedDB/WebSQL: stockage de structures plus complexes et support des transactions (utile si plusieurs onglets ou sessions ouverts simultanément).
• AppCache: l’utilisation d’un fichier manifeste permet de déclarer des ressources (images, CSS…) à mettre en cache.

Bref, les possibilités s’annoncent énormes mais des problématiques fondamentales demeurent: quid de la compatibilité entre navigateurs ? Tous ne supportent pas toutes les APIs et cela peut augurer de belles galères. C’est malheureusement un aspect sur lequel la présentation n’a pas du tout insisté.

Pour plus de renseignements sur les possibilités de stockages hors ligne, le site html5Rocks en offre un vaste aperçu.

Bleeding Edge HTML5

Paul Kinlan (dont voici le blog) a effectué une présentation assez généraliste sur nombre de nouveautés apportées par HTML 5. Les slides sont en ligne et voici les points marquants:

• Début en douceur avec la nouvelle balise <mark /> qui s’utilise pour mettre en avant, de façon sémantique, une partie de texte. Bon, ce n’est pas cela qui changera la face du web !
• Les champs susceptibles d’être remplis par la voix, les speech input, sont aussi une nouveauté: un attribut x-webkit-speech, pour l’instant disponible seulement sur Chrome, permet d’offrir la possibilité de saisir du texte avec un micro. On peut se demander pourquoi laisser au développeur le choix d’activer ou non cette possibilité: il serait peut être plus simple de laisser le choix au niveau du navigateur, ce qui permettrait à tous les champs texte de bénéficier de cette fonctionnalité.
• On passe ensuite à des nouveautés plus impressionnantes concernant les animations. On en profitera pour remarquer que Google a en ce moment un intérêt certain pour les jeux videos: que ce soit avec Angry Birds dans Chrome ou le nouveau framework avec lequel il a été réalisé, PlayN, Google a envie de réussir dans ce domaine. Pour revenir aux animations, donc, au lieu de coder en dur un timeout définissant le framerate à une valeur fixe, les navigateurs proposent maintenant la notion de « RequestAnimationFrame » qui appelle un callback définit par l’utilisateur quand le navigateur le juge utile. Ainsi le CPU ne travaillera pas pour rien: d’une part, pas besoin de calculer 100 images secondes si le rafraichissement de l’écran est de 60Hz, et d’autre part le callback ne sera pas appelé si l’onglet de l’animation n’est pas l’onglet actif. Cette fonctionnalité fait aussi partie de la « page visibility API« : les vidéos ou sons pourront être mis en pause lors du changement d’onglet.
• Les « prerendered pages » sont des pages liées à d’autres par un lien spécial permettant leur chargement en arrière plan pour un rendu immédiat lors du clic sur le lien. On peut imaginer Google utiliser ce type de liens pour précharger les 2 ou 3 premiers résultats affichés lors d’une recherche. Par contre, on voit mal comment ce type de liens pourra se passer d’augmenter virtuellement le traffic des sites même s’ils n’ont pas été visités réellement par des utilisateurs.
• Un attribut « online » de l’objet js navigator permet maintenant de connaitre l’état de l’ordinateur, connecté ou non à un réseau. Un callback permet d’être notifié sur un changement d’état (connexion/déconnexion).
• Après le succès qu’on leur connait dans Android, les « intents » débarquent sur le web. On pourra grâce à eux partager du contenu entre plusieurs sites. Il suffira que les sites fournisseurs se déclarent au navigateur pour que l’on puisse les sélectionner comme tel et, par exemple, importer directement des photos en provenance de Picasa lors de la rédaction de son mail sur gmail.com. Plus de détails dans les slides.
• Le projet WebRTC a pour but de donner la possibilité de réaliser des chats vidéos sans flash, directement avec les API javascript fournies par le navigateur. Le but avoué est de casser le paradigme de la numérotation en permettant des communications instantanées en un clic. Mais du coté software, cela suppose bien sûr des notions de:
  • Capture/rendu de flux audios/vidéos.
  • Énumération des périphériques matériels de capture.
• Pour finir, nous avons eu droit à une démonstration plutôt impressionnante de génération dynamique de sons, en temps réel et en javascript. Des filtres successifs peuvent être appliqués pour déformer le son original.

Dès demain, de nouvelles présentations sur HTML5 devraient avoir lieu, notamment en relation avec JavaFX et Play!/Scala. Il n’y a pas de mystère, HTML5 gagne ces temps-ci une crédibilité énorme, avec notamment les soutiens récents de Microsoft et Adobe, qui incitent nombre d’entre nous à s’intéresser de près au projet qui est en perpétuelle évolution.

David commence par poser la question suivante : comment créer une application Web avec le comportement d’une application desktop ? La réponse réside dans de petites démonstrations des possibilités d’HTML 5 :

• Sauvegarde de fichiers du navigateur vers le filesystem et inversement.
• Sauvegarde des données saisies localement
• Détection des déconnexions et reconnexions automatique.

Assez bluffantes, ces fonctionnalités se mettent en place en seulement quelques lignes !

David poursuit avec le CSS3 et nous parle des possibilités de transitions et d’animations. Pour les fans de jeux, la version Web d’Angry Birds est basée sur CSS3 et lorsque nous voyons le résultat, nous ne pouvons qu’être admiratifs.

Vient ensuite une discussion autour de la conception des applications. David nous explique que les frameworks MVC (Backbone, ExtJS, etc) nous impose une limitation de par leur structure.

Une première solution réside dans l’utilisation du triplet HTML, javascript et CSS, mais cette dernière pose un certain nombre de problèmes :

• Manque de performances.
• Difficulté de debugging.
• Pas de typage fort, rendant le développement d’outils difficile.

La seconde solution est l’utilisation du framework GWT. Le principe est de coder du Java qui est automatiquement « traduit » en javascript. Ce dernier permet d’adresser les problèmes précédemment cités, mais GWT reste difficile à maîtriser et peut se révéler lourd à mettre en place.

David nous présente alors DART. Ce dernier est né de la volonté d’avoir un langage de scripting plus léger tout en utilisant la structure d’un langage orienté objet. Dart est un langage construit pour plaire à la fois aux personnes fluides en Java ou en JavaScript. La courbe d’apprentissage devrait être particulièrement courte pour ces deux populations. Aujourd’hui Dart est un langage qu’il faut « compiler » pour produire du javascript, dans la même veine que coffeescript.

Voici un exemple de code en DART :

interface Shape {
  num perimeter();
}
class Rectangle implements Shape {
  final num height, width;
  Rectangle(num this.height, num this.width);  // Compact constructor syntax.
  num perimeter() => 2*height + 2*width;       // Short function syntax.
}
class Square extends Rectangle {
  Square(num size) : super(size, size);
}

Nous retrouvons ainsi les notions de classes, interfaces et méthodes entre autres.

Concernant l’outillage, nous avons à disposition Dart VM, dartc (compilateur javascript écrit en java), frog (compilateur javascript écrit en Dart, qui fait figure de futur compilateur) et le dartboard. Un début d’IDE Dart (appelé Dart Editor) existe également pour Eclipse. Tous ces éléments peuvent être retrouvés sur le site du langage. Il est à noter que Dart est encore en version alpha, et que des changements dans le langage vont encore intervenir. Il n’existe pas non plus de binaire disponible en téléchargement pour toutes les plateformes, mais nous sommes invités à télécharger les sources et à construire les différents outils (VM, compilateur etc..)

David termine sa présentation en nous expliquant qu’il reste encore du travail sur ce langage, mais que Google travaille d’arrache pied pour nous donner la possibilité de développer du javascript avec une syntaxe allégée. Notamment ils discutent avec l’équipe en charge de Google Chrome pour une intégration native de Dart dans le navigateur, poussant pour que demain, les navigateurs du marchés embarquent une vm dart, comme ils embarquent aujourd’hui une vm javascript.

Nul doute que l’évolution de ce langage est à surveiller et que ce dernier fera parler de lui dans les mois à venir.

Les slides de cette présentation sont disponibles, en html5 bien sur.

Sommaire

• Surveiller l’état de la connexion
• Gérer le contenu dynamique
• • Attention aux liens et à la pagination
  • Passez au JSON
• Le mode hors ligne
• • Gestion d’erreur Ajax
  • Stratégie de stockage
  • Gestion des formulaires
• Conclusion

Cet article s’appuie sur la librairie PrototypeJS pour la majorité des exemples de code JavaScript.

Surveiller l’état de la connexion

La première étape est d’afficher un bloc indiquant à l’utilisateur l’état de la connexion. Le bloc affiche online ou offline en fonction du mode actif (connecté / déconnecté).

Il faut tout d’abord créer le bloc HTML dont nous avons besoin :

<div id="line-status" class="online">
Online
</div>

Un bloc div contient le libellé associé au statut. Nous avons positionné un id sur l’élément pour le manipuler facilement en JavaScript et la classe CSS nous servira à changer la couleur de fond : rouge pour connecté et vert pour déconnecté. Nous pouvons maintenant modifier le texte et la classe du bloc en fonction de l’objet navigator.onLine.

setInterval(function () {
var status = document.getElementById('line-status');
  	status.className = navigator.onLine ? 'online' : 'offline';
  	status.innerHTML = navigator.onLine ? 'Online' : 'Offline';
}, 250);

Le texte et la classe du bloc #line-status seront mis à jour toutes les 250ms en fonction de la valeur de l’objet navigator.onLine. Vous pouvez tester ce code en coupant la connexion wifi/3G de votre ordinateur/téléphone (avec firefox, cliquer sur Travailler Hors Connexion). Une exécution toutes les 250ms a tendance à être consommatrice en ressources ; utilisons plutôt les événements associés à cet état fournis par HTML5.

window.addEventListener('online', function(){
  var status = document.getElementById('line-status');
  status.className = 'online';
  status.innerHTML = 'Online';
}, false);
window.addEventListener('offline', function(){
  var status = document.getElementById('line-status');
  status.className = 'offline';
  status.innerHTML = 'Offline';
}, false);

Notez que l’événement est levé sur l’objet window et non sur l’objet navigator. Avec ce code, la mise à jour du bloc est réalisée à chaque fois que le navigateur change d’état de connexion. Dans cette version, nous reposons entièrement sur le fonctionnement du navigateur pour différencier le mode connecté du mode déconnecté. Si cela fonctionne sur Webphone, sur ordinateur portable la coupure de la connexion réseau ne change pas l’état du navigateur. Seul le passage en mode hors connexion permet de lancer l’événement offline. Le navigateur restera online si les requêtes partent en timeout ou finissent en ‘host not found’ par exemple.
Pour affiner la gestion du mode hors ligne en JavaScript, nous allons maintenir l’état de la connexion dans un objet qui réagira aux événements du navigateur et fournira la possibilité de changer directement l’état de la connexion.

Utils.LinkClass = Class.create({
	// Constructeur
	initialize: function (elem, config){
		// Par défaut nous utilisons la valeur du navigateur
		this.online = navigator.onLine;
		// Récupérer la div par son id
		this.elem = $(elem);
		// Ecouter les évènements online/offline sur l'objet
		this.evtOnLine = this.updateTagOnline.bindAsEventListener(this);
		this.evtOffLine = this.updateTagOffline.bindAsEventListener(this);
		Event.observe(window, 'online', this.evtOnLine);
		Event.observe(window, 'offline', this.evtOffLine);
		// Rendre les classes CSS et les libellés paramétrables
		this.config = Object.extend({
offlineText:'Offline',
onlineText:'Online',
 onlineClass:'online',
offlineClass:'offline' }, config || { });
		this.updateTag(this.online);
	},
	// change l'état et met à jour la div si l'état fourni est différent de celui de l'objet
	setLineState: function (online){
		if(online != this.online){
			this.updateTag(online);
		}
	},
	// Met à jour l'état et la div sur évènement online
	updateTagOnline: function (evt){
		this.updateTag(true);
	},
	// Met à jour l'état et la div sur évènement offline
	updateTagOffline: function (evt){
		this.updateTag(false);
	},
	// Met à jour l'état et la div avec le booléen fourni
	updateTag: function (online) {
		this.online = online;
		if (online) {
			this.elem.addClassName(this.config.onlineClass );
  			this.elem.update(this.config.onlineText);
  			this.elem.removeClasseName(this.config.offlineClass);
  		} else {
  			this.elem.addClassName(this.config.offlineClass);
  			this.elem.update(this.config.offlineText);
  			this.elem.removeClasseName(this.config.onlineClass);
  		}
	}
});
// Instancier Utils.Link lorsque la page est chargée
Event.observe (window, 'load', function (){
	Utils.link = new Utils.LinkClass('line-status');
});

Dans le cas où l’état de la connexion est mis à jour directement sans émettre un événement du navigateur, vous pouvez lancer un service de ping http qui ira vérifier à intervalles réguliers la disponibilité du serveur et mettra à jour l’état de la connexion.

Utils.PingServiceClass  = Class.create({
	initialize: function (config){
		this.timer = null;
                  // Configuration par défaut de la fréquence de ping en ms
		this.config = Object.extend({
			pingInterval: 20000,
			startDelay: 1000,
			url: null,  // Url ciblée par le ping Ajax
			onUplink: function(){}}, // fonction invoquée quand le ping réussi
                      config || {});
		this.url = this.config.url;
	},
        // méthode de ping
	ping: function(){
		if (this.timer != null){
			new Ajax.Request(this.url, {
				  method: 'get',
				  onSuccess: function(transport) {
					if (transport.status < 300 && transport.status >= 200){
						this.timer = null;
                                                  // appel du callback si le ping AJAX a réussi
						this.config.onUplink();
					} else if (this.timer != null){
                                                  // Planification du prochain ping en cas d'erreur
						this.timer = setTimeout(this.ping.bind(this), this.config.pingInterval);
					}
				  },
                                     // Planification du prochain ping en cas d'erreur
				  onFailure: function(){
					if(this.timer != null) {
						this.timer = setTimeout(this.ping.bind(this), this.config.pingInterval);
					}
				  }
				});
		}
	},
          // Lancement du service de ping
	start: function(){
		if (this.timer == null){
			this.timer = setTimeout(this.ping.bind(this), this.config.startDelay);
		}
	},
	  // Arret forcé du ping
	stop: function(){
		if (this.timer != null){
			clearTimeout(this.timer);
			this.timer = null;
		}
	}
});

La classe PingServiceClass utilise la fonction setTimeout pour assurer une exécution régulière et asynchrone. À chaque timeout, elle lance une requête Ajax sur l’URL fournie en configuration. Le ping se lance par un appel à start() et peut être arrêté par un appel à stop(). Il faut aussi modifier la classe Utils.LinkClass pour qu’elle utilise un PingService lorsqu’un script forcera le passage hors-ligne(Utils.link.setLineState(false);).

//...
        initialize: function(config){
          //...
          	if (this.config.ping){ // Instanciation du PingService si la configuration l'autorise
		  this.ping = new Utils.PingServiceClass({
			url: this.config.url,
			onUplink: this.updateTagOnline.bind(this) // Passer Online quand le ping réussi
			});
		}
           },
//...
	setLineState: function (online){
		if(online != this.online){
			this.updateTag(online);
			if (!online && this.config.ping){ // Lancement du Ping HTTP sur passage forcé en mode hors-ligne
				this.ping.start();
			}
		}
	},
	updateTagOnline: function (evt){
		this.updateTag(true);
		  // Arret du Ping HTTP si le navigateur passe en ligne
                if(this.config.ping){
		  this.ping.stop();
                }
	},
//...
Event.observe (window, 'load', function (){ // Ajoute l'url de ping en configuration
	Utils.link = new Utils.LinkClass('line-status',{url:'/ping.html'});
});

Nous avons maintenant un moyen de notifier l’utilisateur et de savoir à tout moment si l’application est en ligne ou non. Le service ping sera utilisé seulement sur les navigateurs ne supportant pas ou mal les événements ‘online’ et ‘offline’. Notez que le ping est exécuté sur l’URL ‘/ping.html’ qui fournit une simple page html statique hors du manifest.

Gérer le contenu dynamique

La première étape, en partant d’une application existante, consiste à ajaxifier son contenu dynamique. Pour reprendre le cas du blog, la page d’accueil liste les en-têtes des articles les plus récents. La première solution consiste à récupérer le bloc HTML listant les articles en Ajax et à l’injecter dans la page. Attention pour les moteurs de recherches et pour des questions d’accessibilité, la page doit toujours être servie avec l’intégralité de son contenu.
Dans le cas d’une page liée au fichier manifest, le problème est de savoir quand mettre à jour la liste. La page étant affichée à partir du cache, son contenu ne changera qu’avec le fichier manifest. Le plus simple est de récupérer le bloc HTML systématiquement au chargement de la page, puis de planifier des mises à jour à intervalles réguliers pour garantir la fraîcheur de l’information.

new Ajax.PeriodicalUpdater('blocElementId', '/articles', {frequency: 30, decay: 2});

L’exemple ci-dessus crée un PeriodicalUpdater qui rechargera les articles toutes les 30s. Si le contenu ne change pas, la prochaine exécution sera planifiée avec un timeout de 30×2 secondes en doublant le decay après chaque passage.

Afin d’améliorer l’expérience utilisateur, pensez à cacher le contenu par css au chargement initial ; le JavaScript l’affichera évitant à l’utilisateur la vue de contenu obsolète à chaque affichage de la page. Pensez aussi à mettre une animation d’attente ou une barre de chargement si vous êtes courageux. Pour la touche finale, vous pourrez ajouter un effet pour faire apparaître la liste des articles.

Attention aux liens et à la pagination

Dans le cadre d’un blog, la page d’accueil liste les articles les plus récents avec pour chaque article, un lien vers l’article complet et son pitch. Sans oublier les boutons de navigation pour consulter des articles plus anciens. Tous ces liens doivent aussi être traités en JavaScript.
Le script devra prendre soin d’intercepter les événements ‘click’ sur les liens d’articles et de pagination pour permettre l’exécution en Ajax de la requête et la mise à jour de l’interface.
A l’aide d’un sélecteur CSS, nous allons retrouver les liens et observer les événements click en exécutant la fonction d’affichage de l’article ou de la liste.

// Utilise l'URL du lien d'article pour afficher ce dernier
Blog.displayArticle = function (evt){
	var url = evt.element().href;
	// ... Update Ajax de #uiBody
};
// Intercepter le click sur un article et afficher ce dernier
$$('#uiBody a.article').each(
function (item){
		item.observe('click', Blog.displayArticle);
});

Passez au JSON

Pour offrir plus de flexibilité au script, je vous recommande de passer d’un échange Ajax en HTML brut à une donnée formatée en JSON. Nous pourrons communiquer des informations au script, comme le jeton de version, sans impacter le HTML. Le formatage des articles en JSON pourra contenir la vue HTML de pré-visualisation pour la page d’accueil et le HTML complet de l’article. L’utilisation du code HTML dans l’objet JSON évite la création chronophage des éléments HTML par le script.
Dans le cas de la liste d’articles, vous allez devoir gérer la pagination de la liste à la main. Dans l’objet JSON remonté par le serveur, pensez à intégrer les informations nécessaires à la pagination (nombre d’éléments total de la liste, numéro de la page, nombre d’éléments par page). La génération des boutons de navigation peut par exemple reposer sur le plugin JQuery pagination (http://plugins.jquery.com/project/pagination).
Le format JSON nous servira aussi au stockage des données côté navigateur. Le localStorage que nous allons utiliser ne supporte que des valeurs de type chaîne de caractères. Les objets y seront donc persistés en chaînes JSON, de manière à maintenir la structure objet sans surcoût de mapping.
Attention à l’injection de code dans vos objets JSON, pensez à toujours passer par une librairie JavaScript comme PrototypeJS ou JQuery pour évaluer l’arbre JSON. Elles se chargeront pour vous de faire les contrôles de syntaxe nécessaires ainsi que la conversion automatique du contenu JSON des réponses AJAX.

Le mode hors ligne

Que se passe-t-il lorsque le navigateur est hors ligne ? En l’état actuel des choses, la page reste vide ou affiche un contenu obsolète issu du premier chargement. Dans certain cas, le bloc de notification restera même désespérément ‘online’.

Gestion d’erreur Ajax

Le script doit traiter les erreurs AJAX, et mettre à jour le bloc de notification en cas d’indisponibilité du serveur. Pensez à positionner un timeout sur vos requêtes pour limiter le temps de chargement et détecter les erreurs réseau. Attention aussi aux redirections HTTP, les requêtes Ajax les suivent si elles sont sur le même domaine. La requête pourra être réussie et contenir la page de login vers laquelle vous aurez été redirigé si vous n’avez plus de session.
En cas de problème réseau, mettez à jour le bloc de notification Utils.link.setLineState(false); et exécutez le traitement hors-ligne reposant sur les données stockées dans le navigateur. Si vous n’utilisez pas le ping HTTP, pensez aussi à mettre à jour le bloc de notification lorsqu’une requête Ajax réussit pour éviter la notification hors-ligne éternelle.

Stratégie de stockage

Bien sûr HTML5 fournit différents supports de persistance dans le navigateur allant de la base de données SQL au stockage dans des tables clé-valeur en passant par les tables clé-valeur indexées. Aujourd’hui seul le stockage de type clé-valeur (localStorage, sessionStorage) est supporté par tous les navigateurs. Les autres API sont intéressantes et pourront faire l’objet d’études futures mais pour cet article, je me suis contenté d’utiliser le localStorage directement disponible sur tous les navigateurs.

Attention, le localStorage ne convient pas à la persistance d’une grande quantité de tuples. Ne comptez pas non plus fournir des fonctionnalités de recherche hors-ligne. L’API du localStorage permet simplement de lister les clés, de récupérer la chaîne associée à une clé et d’associer une chaîne à une clé. Nous pourrons aussi supprimer une clé et sa valeur de la table ou vider l’intégralité de la table. C’est le script qui va devoir combler les manques de l’API en maintenant ses propres index.

Choisissons maintenant le support que nous allons fournir:

• Proxy cache – Le script stocke le résultat des requêtes AJAX dans le localStorage et utilise les objets JSON stockés si le serveur est indisponible. Ce type de stockage est adapté aux contenus liés (tag cloud, articles les plus lus, …) évoluant peu, mais il trouvera vite ses limites dans la gestion du contenu principal pour la pagination notamment. La taille du localStorage va grandir à chaque nouvel article et les articles n’ayant pas été visités ne seront pas disponibles hors-ligne.
• Synchronisation automatique – Stockage d’un nombre restreint d’articles en fonction de la date de publication par exemple. Le navigateur doit synchroniser les n articles les plus récents lorsqu’il est en ligne. En mode hors-ligne, le navigateur ne listera que les articles disponibles dans le localStorage. Le script sera un peu plus compliqué à réaliser mais la taille de la base locale sera fixe et la pagination inutile. La synchronisation automatique est sans doute le meilleur choix dans le cas du blog en lecture seule.
• Synchronisation manuelle – Stockage manuel des articles à positionner dans le cache. L’utilisateur choisi lui même d’ajouter les articles dans le localStorage à l’aide d’un bouton radio par exemple. Pour chaque article listé, le script indique si il est disponible hors ligne. Lorsque le serveur est indisponible, le navigateur n’affichera que les articles persistés dans le localStorage. Là encore, le script sera plus compliqué car cela ajoute plusieurs traitements d’évenements. Il faudra limiter le nombre d’articles persistants pour éviter les scripts trop longs et trop consommateurs en mémoire. La synchronisation manuelle est la plus efficace et la mieux sécurisée pour autoriser l’édition des articles hors-ligne.

Vous l’aurez compris, c’est la synchronisation automatique que nous allons retenir pour assurer l’accès au blog hors-ligne et en lecture seule.

Nous voulons lister des articles pour pouvoir afficher une introduction dans la liste des articles et le contenu intégral dans la page d’article. Nous allons donc créer une vue logique servie par un DAO article qui se chargera de persister les articles, et de les lister. Le DAO pourra par exemple, maintenir la liste des identifiants d’article dans un tableau stocké avec la clé article.index. Cette liste sera triée par ordre de date de publication décroissante pour éviter d’avoir à réaliser des tris couteux en JavaScript.
Chaque article sera stocké avec une clé de type article.id en remplaçant id par l’identifiant de l’article. Pour limiter le temps de traitement l’introduction et le contenu serront stockés séparément. Cela évite le chargement des articles complets pour toute les pages affichant une liste d’articles (pagination, tri, recherche, …). La clé article.index contiendra en plus des identifiants les introductions de chaque article.

var Article = {};
Article.DAOLocalStorageClass = Class.create( {
	initialize: function(){
		var articles = window.localStorage.getItem("article.index");
		if (articles != null && articles.isJSON()){
			this.articles= articles.evalJSON();
		}else {
			this.articles = [];
		}
	},
	getArticleList: function(){
		return this.articles;
	},
	getArticle: function(id){
		var article = window.localStorage.getItem("article."+id);
		if (article != null && article.isJSON()){
			return article.evalJSON();
		}
		return null;
	},
	setArticleList: function(list){
		if (list != null){
			window.localStorage.setItem("article.index", list.toJSON());
			this.articles = list;
		}
		else {
			this.articles = [];
		}
	},
	setArticle: function (article){
		if (article != null){
			window.localStorage.setItem("article."+article.id, article.toJSON());
		}
	},
	removeArticle: function(id){
		window.localStorage.removeItem("article."+id);
	},
	clear: function(){
		this.articles.each(function (item){
			window.localStorage.removeItem('article.'+item.id);
		});
		window.localStorage.removeItem('article.index');
		this.articles =[];
	}
});
Article.DAO = new Article.DAOLocalStorageClass();

Avec ce DAO nous sommes capables de gérer une petite liste d’articles persistés dans le navigateur. Si le navigateur implémente le localStorage et autorise le site à l’utiliser, notre DAO fonctionnera sans problème. Mais le DAO ne supporte pas de dégradation en cas d’indisponibilité du localStorage. La solution retenue est d’utiliser un bouchon à la place du localStorage dans ce cas.

initialize: function(){
	this.enabled = false;
		this.storage = this.getStorage();
 		// ...
},
	getStorage: function(){
		if(window.localStorage){
			this.enabled = true;
			return window.localStorage;
		}else {
			return {
					setItem: function (){},
					getItem: function (){ return null;},
					removeItem: function () {}
			};
		}
	},

La méthode getStorage() fournit un bouchon et positionne la propriété this.enabled à true si le navigateur supporte bien le localStorage. Le reste du DAO doit être modifié pour utiliser this.localStorage au lieu de window.localStorage.

Passons maintenant à la récupération des données à persister. Nous allons développer un service de synchronisation des articles les plus récents pour renseigner notre base d’articles locale.

		new Ajax.Request('sync', {
			  method: 'get',
			  onSuccess: function(transport) {
				if (transport.responseJSON != null){
Article.DAO.clear();				Article.DAO.setArticleList(transport.responseJSON.articles);
					transport.responseJSON.articles.each(function (pitch){
						new Ajax.Request('/article/'+pitch.id, {
							onSuccess: function(transport) {
								if (transport.responseJSON != null){
									Article.DAO.setArticle(transport.responseJSON);
								}
						  	}
						});
					});
				}
			  }
			  }
			});

Le code ci-dessus invoque un web service JSON qui lui retourne la liste des articles les plus récents avec les pitchs à la manière du service listant les articles. La base locale est d’abord vidée intégralement, puis la liste est persistée. Pour chaque article listé, une requête Ajax est lancée pour en récupérer le contenu et le stocker. Bien que la méthode soit assez consommatrice en ressources, elle a le mérite de fonctionner. Une bonne amélioration à réaliser serait de ne récupérer que les nouveaux articles tout en évitant de vider la base à chaque synchronisation.
Une fois la liste récupérée, il faut supprimer de la base les articles qui ne sont plus listés et télécharger tous les nouveaux ainsi que ceux nécessitants une mise à jour (date ou version différente).
N’oublions pas la règle d’or de la notification utilisateur. Nous devons montrer à l’utilisateur l’état de la synchronisation. Il suffit de stocker dans un contexte un booléen à true si la synchronisation est en cours et un compteur des requêtes Ajax lancées et non terminées. Lorsque la derniere requête se terminera elle décrémentera le compteur à zéro, passera le booléen à false et pourra alors notifier l’utilisateur. Pour le contrôle d’erreur on ajoutera un champs error initialement vide dans le contexte qui sera renseigné en cas d’erreur Ajax.

var syncCtx = { running: false, requestCount: 0, error: null};

Il faut lancer la synchronisation au chargement de la page et à chaque fois que le navigateur passe en ligne. En principe pour un blog cela devrait suffire car les utilisateurs ne restent pas connectés très longtemps et le contenu change peu. Dans un site où le contenu évolue rapidement, pensez à exécuter la synchronisation à intervalle régulier. Attention, il est inutile de lancer ce nouveau service si !Article.DAO.enabled, puisqu’aucun article ne sera persisté dans ce cas.

Les fonctions d’affichage précédemment créées doivent-être modifiées pour utiliser le DAO lorsque le navigateur est hors-ligne. Comme vous avez pu le constater de nombreux cas d’erreur sont envisageables : veillez à afficher un contenu alternatif en cas d’indisponibilité des données.

Gestion des formulaires

Les requetes POST sont toujours envoyées sur le serveur sans tenir compte du cache manifest. Lors d’un POST redirect le navigateur pourra afficher la page depuis le cache. Si la réponse du POST contient la page elle sera affichée telle quelle par le navigateur. Seules les requêtes de type GET sont élligibles au cache. Quand le navigateur est hors-ligne, les formulaires utilisant la méthode POST vont afficher le message d’erreur HTTP habituel. Si toutefois vous utilisez la méthode GET, le manifest pourra être utilisé pour fournir une version hors-ligne de la page. Pour permettre l’utilisation d’un formulaire hors-ligne nous allons le soumettre via une requête AJAX en captant l’évènement ‘submit’ du formulaire. Le handler sérialisera les données du formulaire dans un objet JSON ou directement dans la requête AJAX à soumettre sous forme de POST HTTP au serveur.

	// Ecouter le submit du formulaire
$('form').observe('submit', function (evt){
// Soumettre le formulaire en AJAX
			$('form').request({
				method: 'post',
onComplete: function () {
	// Affiche alerte 'Post Submitted'
	alert('Post submitted !');
}});
// Stopper l'évènement submit pour que le navigateur ne le traite pas
evt.stop();
});

Ajoutons un peu de traitement pour les cas d’erreur (indisponibilité du serveur, authentification requise) et le mode hors-ligne. Dans les deux cas, le principe sera d’enregistrer la modification dans le localStorage sous la forme d’un évènement qui pourra être synchronisé lorsque la connexion le permettra.

addEvent: function (evt){
	this.events.push(evt);
	this.storage.setItem('events', this.events.toJSON());
},
getEvents: function (){
	return this.events;
},
clearEvents: function(){
	this.events = [];
	this.storage.removeItem('events');
}

Sur POST d’un nouveau commentaire, l’évènement est enregistré dans la base locale.

Article.DAO.addEvent({ type: 'comment', comment: $('form').serialize(true)});

Pour indiquer à l’utilisateur que le commentaire est bien pris en compte, pensez à vider les champs du formulaire et à afficher un message d’information par exemple. Ajoutez aussi un élément à l’interface pour indiquer à l’utilisateur qu’il y a des données à synchroniser avec le serveur. Cela pourra être un bouton ou un lien qui permettra de soumettre au serveur les modifications réalisées hors-ligne ou hors session. Dans le cas des commentaires, il est possible de prévoir une synchronisation automatique quand le navigateur passe en ligne et au chargement de la page. En revanche cette pratique est fortement déconseillée pour des évènements concernant des articles modifiés.
Vous l’aurez compris tous les évènements qui nécessitent une authentification de l’utilisateur doivent être synchronisés manuellement à la demande de ce dernier. Prévoyez une interface d’administration permettant de lister, éditer et supprimer les évènements à synchroniser.

Conclusion

Avec l’utilisation conjointe du localStorage et du MANIFEST, nous pouvons fournir une application qui fonctionnera hors ligne. Les étapes que nous avons suivies prises séparément sont assez simples. Mais les impacts sont nombreux et plusieurs refactoring seront nécessaires sur le serveur. Le passage au mode hors ligne ne se fera pas sans mal. L’API localStorage n’est pas destinée à stocker et manipuler un grand nombre d’objets. Elle ne sera d’aucun secours pour la recherche, et le tri des listes par exemple. En bref les limitations du localStorage compliquent fortement les développements. Pour créer une application hors-ligne capable de gérer un grand nombre de données et affichant des fonctionnalités égales à des applications de bureau, vous devrez passer par l’utilisation d’un autre mode de stockage comme l’API WebSqlDatabase pour travailler en SQL ou bien l’API WebIndexedDatabase qui répondent à ces besoins. Notez tout de même que WebSQLDatabase n’est supportée ni par IE, ni par Firefox. L’API IndexedDB n’est de son côté supportée que par Firefox et Chrome. Pour un support tout navigateur vous devrez passer par l’utilisation des API fournies par Google Gears. L’inconvénient étant que Gears n’implémente pas les API du standard en cours d’écriture HTML5. À terme, l’extension risque même de disparaître au profit des implémentations natives des navigateurs HTML5.

Sommaire

• Principe de fonctionnement
• Écrire le manifest du cache
• Intégrer le manifest à l’application
• Gérer la mise à jour du cache
• Gérer le cache en JavaScript
• Aller plus loin avec le manifest
• Notes de sécurité
• Conclusion

Principe de fonctionnement

Une page HTML intègre une référence vers un fichier manifest. Celui-ci liste les URL des ressources à mettre dans le cache. Quand le navigateur charge la page pour la première fois, il va télécharger toutes les URL du manifest et les stocke dans le cache. Tous les chargements suivants se feront directement à partir du cache sans passer par le serveur.

En parallèle, le navigateur va vérifier la version de son fichier manifest auprès du serveur. En cas de mise à jour, le navigateur va télécharger l’intégralité des ressources dans un nouveau cache, qui sera utilisé pour tous les chargements suivants.

Que le navigateur soit en ligne ou hors-ligne, il n’y a plus aucun impact sur l’affichage de la page qui vient directement du cache.
Maintenant que vous connaissez le principe de fonctionnement passons à la première étape.

Écrire le manifest du cache

Il s’agit d’un fichier texte encodé en UTF-8 qui contient une liste d’URLs réparties en trois sections :

• CACHE : C’est la section par défaut, elle contient les URLs que le navigateur doit impérativement mettre en cache.
• NETWORK : Liste les URLs qui doivent toujours être consultées sur le serveur. Ce sera par exemple le cas des ressources AJAX et des ressources externes (publicité, …).
• FALLBACK : Cette section permet d’associer des préfixes d’URL à des ressources alternatives utilisées en cas d’indisponibilité.

Passons maintenant à la pratique : la première chose à faire est de créer notre cache manifest.

CACHE MANIFEST
# Version 1 25/09/2010
images/img01.gif
images/img02.gif
images/img03.gif
styles/default.css
lib/demo.js
demo.html
offline.html
NETWORK:
/online.html
FALLBACK:
/online  offline.html

Le navigateur doit donc conserver en cache les ressources statiques du site (images, css, javascript), ainsi que la page demo.html.
La page online.html sera toujours consultée sur le serveur. En cas d’indisponibilité, le navigateur affichera la page offline.html à la place du service en ligne.

Par défaut, seules les ressources listées dans le cache explicite sont disponibles. Par exemple : si vous oubliez de lister une image, celle-ci ne sera pas affichée dans la page. Il faut donc lister toutes les ressources, ou bien ajouter le joker ‘*’ dans la section NETWORK afin de permettre le téléchargement des ressources manquantes. Les ressources listées dans la section CACHE sont toujours prioritaires sur les autres. De ce fait, le joker n’a aucune incidence sur la mise en cache, il permet seulement d’accéder à d’autres ressources, y compris sur des domaines différents.

Intégrer le manifest à l’application

Pour activer le cache, il reste maintenant à ajouter le fichier dans l’application web et à référencer son URL dans l’attribut manifest='cache-manifest.mf' en s’assurant qu’il est encodé en UTF-8 et que le serveur lui donnera bien le type mime ‘text/cache-manifest’.

web.xml:

<mime-mapping>
    <extension>mf</extension>
    <mime-type>text/cache-manifest</mime-type>
</mime-mapping>

Pages HTML:

<html manifest="cache-manifest.mf">
...

Au premier chargement d’une page, le navigateur va construire son cache en téléchargeant toutes les ressources listées dans le manifest et afficher la page. Après quoi, le navigateur affichera toujours cette page à partir du cache.
Notez bien que toute page référençant le manifest est ajoutée dans le cache explicite associé à ce dernier. Dans le cas de la page online.html, il ne faut donc surtout pas y référencer le fichier manifest.

Nous avons maintenant une première démonstration fonctionnelle que l’on peut qualifier de preuve de concept. Nous souhaitons modifier la page demo.html pour y ajouter un peu de contenu. Malheureusement, vous l’aurez compris, la modification du fichier html sur le serveur n’a aucun effet immédiat.

Gérer la mise à jour du cache

Souvenez vous, le navigateur vérifie toujours la version du fichier manifest au chargement des pages du cache. Si le manifest n’est plus à jour, le navigateur va le récupérer et va télécharger l’ensemble des ressources dans une nouvelle version du cache en tache de fond. Au prochain chargement de la page, le navigateur utilisera le cache le plus à jour et vous pourrez constater la prise en compte de vos modifications.

Attention, les ressources du manifest sont téléchargées en outrepassant les directives de cache HTTP. A contrario, le fichier manifest est géré dans un cache standard du navigateur, ce qui signifie qu’il respecte les standards de mise en cache. Si le serveur est configuré pour forcer la mise en cache pendant trois semaines du fichier manifest, il vous faudra attendre autant de temps avant de pouvoir voir la moindre modification de votre interface.

En développement, l’interface change régulièrement, il donc est impératif d’interdire la mise en cache du fichier à l’aide du header HTTP Cache-Control. Pour la production, les directives de cache peuvent-être plus agressives (24h par exemple) car l’interface évolue moins vite. Les en-têtes HTTP peuvent-être positionnées à l’aide d’un filtre sur l’URL du manifest ou d’une Servlet générant le manifest.

A chaque modification du fichier manifest détectée par le navigateur, celui-ci re-télécharge l’intégralité du cache. Pour garantir la mise à jour du cache à chaque nouvelle version de l’application, il faut donc modifier le fichier manifest. C’est le rôle du commentaire # version 1 25/09/2010 qui changera à chaque livraison ou déploiement de l’application.

Le site est donc consultable hors-ligne et nous sommes capables de forcer la mise à jour du cache. L’utilisateur pourra continuer à consulter le site et verra une page d’erreur appropriée s’il tente d’accéder à des services indisponibles. Pour un site statique c’est très bien mais quand on parle d’application, on pense à quelque chose de dynamique.

Gérer le cache en JavaScript

Pour un blog dont le contenu évolue lentement, il est envisageable de s’assurer que la version du manifest soit changée à chaque nouvel article. Le manifest devient alors un service généré par l’application qui change le commentaire de version à chaque nouvel article.
Malheureusement, l’utilisateur ne pourra voir le nouvel article qu’à son deuxième passage sur le site, une fois que le cache aura été mis à jour. Un début de solution est d’utiliser l’API JavaScript pour recharger automatiquement la page lorsque le nouveau cache est prêt.

L’objet window.applicationCache va nous permettre de :

• Suivre l’activité et l’état du cache associé au document courant.
• Lancer le téléchargement de la nouvelle version du cache si le manifest a changé.
• Activer la nouvelle version du cache pour que les prochains chargements l’utilisent.

<script>
// Activer le nouveau cache quand il est disponible et recharger la page
window.applicationCache.addEventListener('updateready', function (){
  	window.applicationCache.swapCache();
  	alert('mise a jour du cache');
  	window.location.reload();
}, false);
// Notifier les erreurs
window.applicationCache.addEventListener('error', function (evt){
	alert('Erreur du cache : ' + evt);
}, false);
// Vérification de la version du manifest
window.applicationCache.addEventListener('checking', function (evt){
	alert('Vérification du cache : ' + evt);
}, false);
// Télécharger le nouveau cache quand le manifest a changé
window.applicationCache.addEventListener('obsolete', function (evt){
	alert('Le cache est obsolète : ' + evt);
	window.applicationCache.update();
}, false);
// Le manifest n'a pas changé
window.applicationCache.addEventListener('noupdate', function (evt){
	alert('Pas de mise à jour du cache : ' + evt);
}, false);
</script>

Ce code rechargera automatiquement la page du navigateur lorsque le cache aura été mis à jour. Le lecteur du blog peut maintenant voir rapidement le nouvel article ou tout du moins son introduction. Pour pouvoir lire l’article hors-ligne, il faudra qu’il pense à afficher la page au moins une fois pour la mettre en cache.

Aller plus loin avec le manifest

La solution peut être de créer un service générant le manifest en changeant, d’une part, de version à chaque nouvel article publié et, d’autre part, en listant les URLs des derniers articles dans le cache explicite. Le chargement prendra plus de temps mais le lecteur pourra consulter l’article hors-ligne sans plus d’effort.

Attention, les pages implicites qui déclarent le manifest sans être listées dans ce dernier y sont ajoutées et seront téléchargées elles aussi lors de la mise à jour du cache.
Soyez prudent quand vous activez le manifest et ne multipliez pas les pages. Dans le cas du blog par exemple les pages affichant les articles ne doivent pas utiliser le manifest. Le lecteur ne souhaite certainement pas télécharger l’ensemble des articles qu’il a déjà lu à chaque nouvel article.

Cette solution minimaliste peut convenir à certains, mais elle n’est pas applicable pour un site dont le contenu change beaucoup ou pour un site à fort trafic tant l’utilisation du cache est mauvaise.

Pour optimiser l’utilisation du cache, il faut le considérer comme la vue statique de l’application qui évoluera au gré des changements d’interface et non au gré du contenu. Le contenu dynamique devra être servi par des requêtes asynchrones. Pour la mise en cache et le fonctionnement il faudra utiliser les nouvelles API JavaSript : LocalStorage et document.onLine. De cette manière, le manifest redeviendra un fichier statique évoluant au gré des versions de l’application.

Pour garantir l’indexation du contenu par les moteurs de recherche et assurer la compatibilité avec d’anciens navigateurs, prévoyez toujours un mode dégradé sans manifest ni contenu asynchrone.

Notes de sécurité

Notez que le cache est maintenu par nom de domaine. Il n’existe qu’une seule instance du même manifest pour un serveur. Pour les serveurs hébergeant plusieurs applications, l’utilisation d’hôte virtuel est plus que conseillée.

Le cache ne doit jamais contenir de données confidentielles. Les pages de login et tous services de sécurité doivent être exclus du cache. Ne les listez jamais dans le manifest sauf pour les exclure et surtout n’intégrez pas le manifest dans ces pages.

Informez l’utilisateur sur les dangers de ce service et surtout laissez le choisir d’activer ou non le fonctionnement hors ligne. En effet si le navigateur lui-même n’est pas protégé, toute personne y ayant accès pourra consulter le cache. Pour limiter le problème vous pouvez activer le service en stockant un cookie sur le navigateur si l’utilisateur active le mode hors ligne. Ainsi le lecteur devra répéter l’opération pour tous les navigateurs sur lesquels il souhaite consulter le site.

En dehors de ces règles de sécurité basiques, toutes les règles de sécurité inhérentes aux sites web s’appliquent.

Conclusion

Dans ce premier article, nous avons posé la première pierre d’une application hors-ligne, en intégrant un fichier manifest pour mettre en cache son interface et ses ressources statiques. Dans le prochain article, nous verrons comment utiliser les nouvelles API JavaScript pour permettre de lire et d’éditer du contenu hors-ligne.

Les points importants du manifest :

• Versionnez le manifest avec un commentaire
• Désactivez ou maitrisez les directives de cache HTTP
• Minimisez le nombre de pages référençant le manifest
• Stockez uniquement les ressources statiques du site

L’avantage du Flash

L’avantage du Flash est la possibilité de développer des applications plus intuitives, efficaces et faciles à utiliser. Michael nous présente une application pour la finance réalisée pour une grande banque française. Le backend est resté le même, seul le client a été modifié pour être remplacé par du Flex. Une amélioration de la productivité des utilisateurs a pu être constatée. En effet, les données étaient plus facilement lisibles et exploitables par les utilisateurs qui prenaient donc des décisions plus rapidement.
Michael met en avant la productivité par le design. L’avantage de Flex est la facilité avec laquelle on peut réaliser des applications. Elle est productive pour le développeur et pour l’utilisateur.

Les nouveautés de la plateforme Flash

Tout d’abord Adobe a intégré dans sa plateforme le support d’HTML5 pour que ses outils, tels que Dreamweaver et Illustrator par exemple, le supportent .
La plateforme Flash est un panel complet de solutions permettant de réaliser des applications riches sur tous les supports qui vont du mobile à l’ordinateur, en passant par la télé. Cette plateforme fournit tous les outils indispensables au développement d’applications, vidéos et autres. Les applications sont natives pour tous les supports. Adobe et d’autres partenaires ont d’ailleurs créé le projet open-screen qui a pour but de travailler ensemble à l’élaboration d’un environnement consistant pour la navigation web et le lancement d’application sur n’importe quel écran. Ce projet exploite les avantages de Flash Player et d’Adobe Air.

Flash Player 10.1

Le taux de pénétration de Flash Player 10.1 est actuellement supérieur à 70%.
Les nouvelles fonctionnalités permettent maintenant d’exploiter les avantages des mobiles :

• le multi-touch et les gestures,
• l’acceléromètre,
• la gestion de l’orientation de l’écran,
• les champs textes pour mobile …

La performance a également été améliorée sur l’audio, la vidéo, la gestion des ressources en général pour économiser de la batterie (surtout pour les mobiles). Une nouvelle API vidéo a été développée pour réduire la charge sur le processeur comme certains ont pu le constater sur Mac OS. Elle utilise plutôt les ressources de la carte graphique pour fonctionner. L’utilisation de la mémoire a été optimisée. Pour tester ces nouvelles fonctionnalités, vous pouvez télécharger l’application de démonstration TourDeFlex et tester la partie Flash Player APIs. Le multi-touch est assez bluffant si vous avez un trackpad adapté .

Applications pour Mobile

Pour développer des applications pour mobile, vous pouvez utiliser Device Central CS5. Il fait partie de la Creative Suite et fournit toutes les configurations des smartphones, telles que la mémoire, le processeur … Ces dernières sont mises à jour dynamiquement. Vous trouverez une démonstration de ce que l’on peut réaliser en terme d’application mobile sur le blog de Michael Chaize où il présente un Doodle Jump développé avec Air et qu’il a pu déployer sur son Android en version 2.2 (Froyo).

AIR 2

Air est une application desktop, ce qui signifie qu’il exploite les ressources de l’ordinateur. Maintenant le déploiement est possible sur Android, et pour plus d’informations je vous renvoie vers cet article. Autre nouvelles fonctionnalités avec AIR :

• ouverture des fichiers avec l’application par défaut définie par l’OS,
• détection de l’OS avec l’objet Capabilities.os,
• exécution possible de commandes grâce à NativeProcess.

Quoi de neuf sur Flex Hero ?

Flex Hero est le petit nom de la release majeure 4.1 de Flex. Dans cette nouvelle version, de nouveaux composants spark sont disponibles :

• une datagrid spark avec :
  • gestion des déplacements avec les touches,
  • une skin class (apparence) plus simple à personnaliser que celui de Halo
  • et un chargement des données dynamique au moment du scroll. Ce qui rend le chargement plus rapide grâce à la pagination.
• un formulaire spark,
• des formatters spark avec gestion de l’internationalisation,
• un MobileApplication pour gérer les applications mobiles,
• une API pour la navigation dans les vues,
• ActionBar,
• MobileItemRenderer pour les rendus de liste spécifique aux applications mobiles,
• gestion de la géolocalisation,
• gestion de l’orientation,
• génération de l’application sous forme de package Android (APK).

Flash Catalyst

La sortie en release preview de Flash Builder « Burrito » s’accompagne aussi de celle de Flash Catalyst « Panini ». Celui-ci a été revu pour faciliter la collaboration entre le développeur et le designer. Précédemment, le problème était que le designer ne pouvait pas retravailler sur ce qu’avait réalisé le développeur. Avec cette nouvelle version de Flash Catalyst, c’est maintenant possible.

LiveCycle Collaboration Service

Le LiveCycle Collaboration est une solution hébergée par Adobe pour proposer aux développeurs de réaliser des applications Flex collaboratives. Ils ont à leur disposition des composants : tableau blanc pour les dessins, gestion de la webcam … pour réaliser des applications où il est possible aux utilisateurs d’échanger des informations. Michaël nous a d’ailleurs invité à accéder à une des applications qu’il a réalisé. C’était très intéressant de voir sur le grand écran de la salle une dizaine de webcams afficher le visage de quelques participants curieux.

Crédit photo : les images proviennent du site d’Adobe et de l’album Picasa de Stephan Jaansen pour Devoxx 2010

Récupération du projet Flash Catalyst

Commençons donc par récupérer ce que notre designer a réalisé. Ce dernier nous génère grâce à Flash Catalyst un fichier fxp. Pour le récupérer dans Flash Builder, il suffit d’aller dans Fichier > Importer un projet Flex (FXP) et de sélectionner le fichier à importer.

Une fois cette importation terminée, le projet apparaît comme un projet Flex classique dans Flash Builder. Il contient la librairie de Flash Catalyst. Le projet compile et s’exécute à merveille. Inspectons maintenant le code généré par Flash Catalyst.

La partie design de Flash Builder

Ouvrons l’application principale, c’est-à-dire le Main.mxml dans Flash Builder et intéressons nous à la partie Design (Conception si vous avez comme moi la version française) :

Dans cette vue il est maintenant possible de visualiser les différents états possibles d’un composant.

La librairie Spark de Flex 4

Observons ensuite le composant bouton Button1, le code généré donne ceci :

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:s="library://ns.adobe.com/flex/spark" xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:d="http://ns.adobe.com/fxg/2008/dt">
	<fx:Metadata>[HostComponent("spark.components.Button")]</fx:Metadata>
	<s:states>
		<s:State name="up"/>
		<s:State name="over"/>
		<s:State name="down"/>
		<s:State name="disabled"/>
	</s:states>
	<s:BitmapImage source="@Embed('/assets/images/xke_ui/telephone over.png')" d:userLabel="over" x="0" y="0" id="bitmapimage1" visible.down="false" visible.up="false"/>
	<s:RichText color="0x000000" fontFamily="Arial" fontSize="18" kerning="off" lineHeight="27" textAlpha="0.9" d:userLabel="label" whiteSpaceCollapse="preserve" x="16" y="4" id="labelDisplay" text="(Label)">
	</s:RichText>
	<s:transitions>
		<s:Transition fromState="up" toState="over" autoReverse="true">
			<s:Parallel>
				<s:Parallel target="{bitmapimage1}">
					<s:Fade duration="0"/>
				</s:Parallel>
			</s:Parallel>
		</s:Transition>
	</s:transitions>
</s:Skin>

Ce composant utilise Flex 4 et notamment la nouvelle librairie spark qui permet de réaliser des composants plus «customisables». C’est grâce à cette librairie que l’on peut faire collaborer designer et développeur. Comme vous pouvez le voir ici, le code MXML est vraiment différent de ce que l’on a pu voir jusqu’à maintenant avec Flex 3.
On peut retrouver toutes les informations données dans Catalyst telles que :

• le fait que le composant soit un bouton <fx:Metadata>HostComponent("spark.components.Button")</fx:Metadata>,
• les différents états des boutons (up, down, over, disabled),
• et l’apparence du bouton en lui même.

Pour plus d’informations, vous pouvez consulter cet article sur les nouveautés de Flex 4.

Intégration au backend Java

L’introspection des services avec Flash Builder

Passons maintenant à l’intégration avec un backend Java: nous allons pour cela utiliser Flash Builder 4. Une des grandes nouveautés de cet IDE est la possibilité de réaliser l’introspection des différents services exposés côté Serveur. Il peut s’agir de services Java avec LCDS (LiveCycle Data Service ES) ou BlazeDS, ou encore de services PHP avec AmfPHP par exemple.

Le service sur lequel nous allons travailler côté Java est un simple war contenant un POJO TravelService renvoyant une liste fixe d’objets Travel.

Nous allons utiliser la fonctionnalité d’introspection que fournit Flash Builder 4. Pour ce faire, commençons par configurer le web.xml pour le développement en ajoutant la servlet permettant de réaliser l’introspection des classes Java par Flash Builder. Pour réaliser cette configuration, je me suis basée sur cet article qui fournit toutes les librairies nécessaires.

<servlet>
        <servlet-name>RDSDispatchServlet</servlet-name>
		<display-name>RDSDispatchServlet</display-name>
        <servlet-class>flex.rds.server.servlet.FrontEndServlet</servlet-class>
        <init-param>
			<param-name>messageBrokerId</param-name>
			<param-value>_messageBroker</param-value>
		</init-param>
		<init-param>
			<param-name>useAppserverSecurity</param-name>
			<param-value>false</param-value>
		</init-param>
        <load-on-startup>10</load-on-startup>
    </servlet>
    <servlet-mapping id="RDS_DISPATCH_MAPPING">
        <servlet-name>RDSDispatchServlet</servlet-name>
        <url-pattern>/CFIDE/main/ide.cfm</url-pattern>
    </servlet-mapping>

Cela permettra à Flash Builder de réaliser l’introspection des classes côté Java. La propriété useAppserverSecurity est à false durant la période de développement pour faciliter l’accès aux données.

Pour l’exposition des services, nous utilisons Spring BlazeDS configuré par annotation de la façon suivante.

@Service("travelService")
@RemotingDestination(channels={"my-amf"})
public class TravelService {

Le channel est défini de façon classique dans un fichier de configuration services-config.xml dont voici un extrait :
Définition du channel :

<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
        </channel-definition>

Configuration du channel par défaut :

<services>
	<default-channels>
             <channel ref="my-amf"/>
     </default-channels>
</services>

Lançons maintenant notre serveur Tomcat côté Java pour y déployer notre war.

Côté Flash Builder, faites un clic droit sur votre projet puis sélectionnez Propriétés > Serveur Flex. Donnez le type de serveurs d’application J2EE et sélectionnez BlazeDS.

Le dossier de sortie permet à Flash Builder de pouvoir déployer l’application Flex sur le serveur d’application.

Après avoir validé la configuration, nous allons maintenant pouvoir visualiser les services disponibles pour cette application.

Allez dans le menu Données > Connexion à BlazeDS. Une authentification est demandée mais pour notre application aucun mot de passe n’est nécessaire. Sélectionnez donc « Aucun mot de passe requis », puis Ok.

Une fois validé, vous pourrez visualiser les services disponibles côté Java exposés par BlazeDS :

A ce stade vous pouvez sélectionner le service et l’associer à votre projet.

Tester son service avec Flash Builder

En cliquant droit sur votre service, vous pouvez réaliser des opérations de test. Le test permet d’afficher les valeurs de retour de vos méthodes. Par exemple pour la méthode loadAll proposée par TravelService, nous pouvons voir les valeurs que retourne notre service.

Associer le service à l’IHM

Le but étant de montrer ce que Flash Builder est capable de faire, nous allons utiliser tout ce qu’il nous propose en évitant le plus possible de coder.

Commençons par aller dans la vue design du Main.mxml, dans l’état voyages, sélectionnez la liste contenant les éléments San Francisco, cliquez droit sur le composant et sélectionnez Lier aux données.

Flash Builder propose les services précédemment configurés pour notre projet. Sélectionnez le champs de liaison aux données (dans notre cas destination) puis validez. Flash Builder va supprimer la liste de San Francisco pour la remplacer par le service sélectionné.
Maintenant en allant sur http://localhost:8080/FlexProjectXke/, nous pouvons voir notre liste. Mais n’étant pas correctement configurée, les éléments apparaissent ainsi object Travel. Nous allons donc faire quelques réajustements pour que l’affichage se fasse correctement.

A vrai dire, la définition de la destination ne fonctionne pas ici car la liste n’utilise pas le labelField mais fait appel à des composants « custom ».
Mais où doit être effectuée cette modification ? Commençons par repérer où se trouve la liste des données dans le Main.mxml :

<fx:DesignLayer d:userLabel="voyages page" visible.operateurs="false" id="designlayer3" visible.xke="false">
		<s:BitmapImage source="@Embed('/assets/images/xke_ui/Objet dynamique vectoriel_1.png')" d:userLabel="Objet dynamique vectoriel_1" x="486" y="140"/>
		<s:BitmapImage source="@Embed('/assets/images/xke_ui/Objet dynamique vectoriel_2.png')" d:userLabel="Objet dynamique vectoriel_2" x="179" y="140"/>
		<s:VScrollBar skinClass="components.Objetdynamiquev_VerticalScrollbar" fixedThumbSize="true" x="433" y="155" includeIn="operateurs,xke"/>
		<s:List skinClass="components.DataList1" x="181" y="155" id="list" creationComplete="list_creationCompleteHandler(event)"  dataProvider="{loadAllResult.lastResult}" labelField="destination">
		</s:List>
	</fx:DesignLayer>

La liste fait appel au composant DataList1, regardons ce qu’il contient :

<s:DataGroup itemRenderer="components.RepeatedItem1" x="0" id="dataGroup" width="253" height="69" clipAndEnableScrolling="true" height.normal="332" y="1">
		<s:layout>
			<s:VerticalLayout horizontalAlign.normal="left" gap.normal="2"/>
		</s:layout>
	</s:DataGroup>

L’itemRenderer RepeatedItem1 dans DataGroup fournit le rendu de chaque élément affiché dans la liste. C’est exactement à lui que l’on va s’intéresser pour personnaliser l’affichage des données.

<s:ItemRenderer xmlns:s="library://ns.adobe.com/flex/spark" xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:d="http://ns.adobe.com/fxg/2008/dt" xmlns:mx="library://ns.adobe.com/flex/halo">
	<s:states>
		<s:State name="normal"/>
		<s:State name="hovered"/>
		<s:State name="selected"/>
	</s:states>
	<mx:Image source="{data.image1}" d:userLabel="Objet dynamique vectoriel" x="0" y="0" maintainAspectRatio="false"/>
	<s:RichText color="0x000000" color="0xFFFFFF" fontFamily="Arial" fontSize="18" kerning="off" lineHeight="27" d:userLabel="San Francisco" whiteSpaceCollapse="preserve" x="10" y="5" text="{data.destination}">
	</s:RichText>
</s:ItemRenderer>

Maintenant ajoutons l’image dans le Main.mxml, pour qu’elle soit affichée lorsqu’on sélectionne un pays.

<mx:Image includeIn="voyages" x="495" y="155" width="282" height="335" source="{list.selectedItem.photo}"/>

Et voilà le résultat :

Conclusion

L’intégration dans Flash Builder de la maquette réalisée par Flash Catalyst ne fût pas aussi simple que prévue et il a fallu chercher et modifier un peu le code. Rien de très important certes, mais sur des maquettes plus complexes cela peut devenir plus compliqué. Comment en sommes nous arrivés là ? La création de l’élément répété a été faite par rapport à un texte sur fond d’image (noir si non sélectionné et gris sinon). Le problème est que la liste de données transportait initialement le chemin vers cette image, chose que le designer n’aurait pas dû faire si il s’était concerté avec le développeur. Une très bonne communication est nécessaire entre les deux mondes pour que le développeur ait un projet facilement exploitable et intégrable. A mon avis, le designer doit être sensibilisé à la qualité du code que Flash Catalyst pourrait générer en arrière plan. Sinon, le travail d’intégration au backend risque d’être laborieux.
Un autre inconvénient de Flash Catalyst concerne le code Flex généré: un peu lourd comparé à ce que le développeur aurait pu réaliser lui même, il fournit pas mal d’images pour obtenir le rendu de départ, rendant le code moins compréhensible au premier abord.
Enfin Flash Builder 4 apporte beaucoup d’amélioration au développement d’application. L’auto-complétion y est améliorée. Et la récupération des services via Flash Builder permet d’éviter toute duplication des classes côté Flex, il s’occupe de gérer l’appel des services. Un gros point négatif à rayer de votre liste d’inconvénients vous empêchant de débuter un projet Flex/Java. Un outil à tester sans hésiter !

Mise en place de l’image Photoshop/Illustrator

N’ayant que très peu de connaissance de l’univers Photoshop, cette tâche s’est avérée au début périlleuse… Néanmoins, les différents tutoriaux d’Adobe permettent d’acquérir suffisamment de connaissances pour mettre en place une image, dont voici le résultat:

Assez basique, le premier écran listera les voyages, et lorsque l’utilisateur cliquera sur l’un d’eux, une image s’affichera dans le panel de droite. C’est dans cet écran que sera branché notre backend Java. Le menu sera simplement utilisé afin de montrer la mise en place des états/transitions avec Catalyst. Ainsi, les autres rubriques du menu afficheront respectivement une carte, et un descriptif.

Voici notre arborescence de l’image Photoshop créée:

Le principe est simple: l’image est découpée en calque, et ces derniers sont regroupés par fonctionnalités/pages. Ainsi nous retrouvons notre menu (navigation) avec les types d’effets que nous voudrons voir lorsque la souris de l’utilisateur passera sur le texte (ici une image violette), et les différentes pages avec leurs contenus.
Cette organisation est très importante, car par la suite nous l’utiliserons afin de mettre en place les transitions entre pages et créer nos composants.

Flash Catalyst

Une fois l’image importée dans Catalyst, nous constatons que la structure de Photoshop est bien présente et qu’un état a été créé.

Nous allons commencer par créer les transitions entre les différents écrans:

• Sélectionnez le premier état en haut à gauche et renommez le en voyages.
• Sélectionnez pour cet état la page que vous voudrez afficher dans la fenêtre Layers en haut à droite (en l’occurrence voyages page)
• Créez deux autres états (Duplicate State en haut à gauche)
• Répétez l’étape 2 pour les pages opérateurs et XKE.

Animons cette page en créant les boutons:

• Revenez sur l’état «voyages».
• Sélectionnez le texte «Voyages» ainsi que le fond violet.
• La fenêtre Convert to Artwork apparaît, sélectionnez Button.
• Re cliquez sur le texte Voyages et cochez Label dans la fenêtre qui est apparue.

• Dans la fenêtre Layers (en haut à droite), renommez Voyages en Label et voyages over en over (ce sera un composant générique pour les autres boutons du menu).
• Revenez sur la racine de votre projet (nom du projet) et renommez le composant Button en voyages_button par exemple (fenêtre en haut à droite).
• Ajoutez le label Voyages dans les propriétés du composant, et décochez Enabled.

• Sélectionnez le label de «Voyages» et modifier la couleur en noir (dans la fenêtre Properties en bas à droite)

• Copier coller deux fois le composant voyage_button dans la fenêtre Layers (en haut à droite). Ce seront les boutons Opérateurs et XKE.
• Supprimez les composants du layer navigation importés de l’image Photoshop

• Tout comme «Voyages», modifiez les labels pour Opérateurs et XKE (par contre laissez la propriété Enabled cochée).
• Vous devez réaligner les boutons les uns en dessous des autres, car en créant ces composants, Catalyst les a superposés.
• Sur chaque bouton, faire clique droit => Share to State => All States.
• Allez dans les états Opérateurs et xke: alignez les boutons et vérifier la couleur des labels.
• Attention, pour ces états vérifiez également que pour le bouton Voyages, la propriété Enabled est bien cochée.
• Cliquez sur le bouton Voyages, la fenêtre suivante s’ouvre

• Dans Up et Down, désélectionnez voyages over dans la fenêtre layers.

• Cliquez sur le bouton «Voyages» et dans le panneau Interactions (sur la droite), sélectionnez Add Interaction.
• Dans la liste déroulante Choose state, sélectionnez voyages.

• Répétez ces opérations pour les boutons Opérateurs et XKE.
• Allez dans File => Run Project pour tester la navigation.

Passons à la création de la scrollBar verticale ainsi que de son association avec une liste déroulante :

• Sélectionnez les éléments graphiques qui vont composer la scrollBar.
• Une fenêtre est apparue (Convert to Artwork), sélectionnez Vertical scrollBar dans la liste. Ne tenez pas compte du message Component Issues.
• Cliquez sur Edit Parts, et associez les éléments graphiques aux éléments de la scrollBar.

• Un fois le composant terminé, cliquez sur la racine du projet (nom de votre projet) en haut à gauche.
• Sélectionnez le fond gris clair avec le texte San Francisco et dans la fenêtre Convert Artwork, sélectionnez Data List.
• Cliquez sur Edit Parts, et associez le fond gris ainsi que le texte San Francisco à Repeated Item.

• Ajustez la taille de la Data List à celle de la scrollBar.
• Dans la fenêtre du bas, cliquez sur l’onglet Design-Time Data.
• Ajouter des données en cliquant sur Add Row.

• Couper la scrollBar, double cliquez sur la Data List et coller la scrollBar dedans (l’association avec la liste est effectuée à ce moment).
• Allez dans File => Run Project pour tester l’application.

Analyses

A travers la mise en place de cette première partie, nous pouvons effectuer les constats suivants:

• La maîtrise des outils Photoshop et Illustrator est indispensable : créer ses composants graphiques, appliquer des effets nécessitent un travail non négligeable.
• Pour un développeur n’ayant pas de connaissances graphiques, la courbe d’apprentissage peut être assez longue.
• Lors de la mise en place de l’image, il faut anticiper les transitions et effets car l’arborescence des composants est importante pour Catalyst.
• L’outil Catalyst possède de bonnes interactions avec Photoshop et Illustrator:
• l’import d’images Photoshop est bien reconnu
• possibilité de modifier et d’améliorer ses composants à partir de Catalyst dans Illustrator.
• Catalyst permet de créer des états, transitions assez rapidement et facilement
• La création de certains composants n’est pas forcément très intuitive : création d’un composant Button et suppression des «boutons» créés dans Photoshop…

Vous pouvez télécharger l’image et le projet Catalyst sur le SVN de Xebia France

Sommaire

• Sélecteurs CSS
• Timers
• Workers et Messaging
• Web Storage
• Offline Web Application
• Geolocation
• WebSocket
• Web SQL Database
• Drag’n'drop
• ContentEditable
• Conclusion

Sélecteurs CSS

Habituellement utilisés pour appliquer des styles aux éléments HTML, les sélecteurs sont aussi utilisés en JavaScript pour retrouver facilement un ou plusieurs éléments. #loginForm fieldset permet de récupérer le ou les fieldset contenu dans l’élément dont l’id est loginForm. Tous les frameworks JavaScripts proposent leurs propre implémentation des sélecteurs CSS. Mais vous pouvez dès aujourd’hui migrer vers document.querySelector() qui fonctionne nativement sur tous les navigateurs récents et supporte la norme CSS3.

document.querySelector() retourne le premier élément trouvé correspondant au sélecteur, et document.querySelectorAll() va nous retourner la collection complète. Le gros avantage est la rapidité d’exécution fournie par le navigateur qui bat à plate couture tous les équivalents en framework JS.

Constatez par vous même en lançant Slick Speed dans votre navigateur.

http://www.w3.org/TR/selectors-api

Timers

Comme leur nom l’indique, les Timers permettent de planifier dans le temps des exécutions de callbacks avec ou sans répétition. La fonctionnalité n’est pas franchement nouvelle, mais elle trouve bonne place dans la recommandation du W3C. L’API propose deux fonctions pour créer les timers:

• setTimeout(handler, ms, [args ...]) – Enregistre un handler pour être exécuté dans ms millisecondes en lui passant les arguments args.
• setInterval(handler, ms, [args ...]) – Enregistre un handler pour être exécuté toutes les ms millisecondes.

Toutes deux retournent un pointeur qui pourra être utilisé plus tard pour supprimer le timer à l’aide de clearTimeout() et clearInterval(). Les timers sont assez pratiques pour rafraîchir le contenu de la page sans la recharger totalement. Ils sont maintenant aussi beaucoup utilisés pour animer le canvas. L’API intégrée depuis longtemps par les frameworks JavaScript est supportée par tous les navigateurs d’aujourd’hui et d’hier.

http://dev.w3.org/html5/spec-author-view/timers.html

Workers et Messaging

Les Workers sont des tâches de fond qui vont s’exécuter en parallèle du programme JavaScript principal. Pour assurer la sécurité, ils tournent dans un environnement totalement séparé de la page et n’ont aucun accès direct sur cette dernière. C’est via la nouvelle API de Messaging que les workers vont pouvoir communiquer avec le programme principal. Chacun des threads peut envoyer un message via la méthode postMessage(...) et le recevoir en enregistrant un handler pour l’évènement onMessage.

Créons, d’abord, un nouveau Worker en lui fournissant l’url du script à exécuter :

var w = new Worker('prime.js');
// Ecrire le nombre premier trouvé dans la page sur message du worker
w.onMessage  = function (evt){
    document.getElementById('prime').textContent = event.data;
};
// Lancer le worker
document.getElementById('startTimerButton').onClick = function (evt) {
   w.postMessage('start');
}
// Stoper le worker
document.getElementById('stopTimerButton').onClick = function (evt) {
   w.postMessage('stop');
}

Voyons maintenant le code du Worker :

var running = false;
var timer;
var n = 1;
// Traiter le message de la page
onmessage = function (event) {
  if (event.data == 'start' && !running) {
    running = true;
    n = 1;
    timer = setInterval(run, 50);
  } else if (event.data == 'stop' && running) {
    running = false;
    clearInterval(timer);
  }
};
// Rechercher un nombre premier
function run() {
  var isAPrime = false;
  while (!isAPrime) {
    isAPrime = true;
    n += 1;
    for (var i = 2; i <= Math.sqrt(n); i += 1){
      if (n % i == 0){
        isAPrime = false;
        break;
      }
    }
  }
  // found a prime!
  postMessage(n);
}

Le code est assez simple. Sur message 'start' de la page, il créé un Timer qui exécutera la fonction run toutes les 50ms. Si le message reçu est 'stop', il coupe le Timer ce qui arrêtera la recherche au prochain nombre premier trouvé.
Attention, le message contenu dans event.data ne peut contenir que du texte. Pour supporter des messages plus complexes, il faudra passer par des chaînes JSON.

Les Workers peuvent créer d’autres Workers sans limite, et importer d’autres scripts via la fonction importScript(url). Les traitements lourds ne sont plus réservés aux applications de bureaux. L’API est supportée par Chrome, Safari, et Firefox. Il faut encore reposer sur Gears pour pouvoir en bénéficier sur IE et Opéra a planifié l’API pour sa prochaine version.

L’API de Messaging est aussi utilisée pour d’autres fonctionnalités comme la communication entre la page et son iFrame quelque soit le domaine d’origine. La page enregistre un handler window.onMessage et peut appeler le postMessage() pour communiquer. Ainsi, même deux iframe de la même page peuvent communiquer entre elles. Vous pouvez tester cette démonstration pour avoir un aperçu de la communication cross-domain. Cette API est disponible pour tous, à partir d’IE 8 .

http://dev.w3.org/html5/workers

Web Storage

Cette nouvelle API fournit deux types de stockage de données dans le navigateur :

• Le sessionStorage est une base JSON partagée, pour la durée de la session, entre toutes les pages d’une même fenêtre.
• Le localStorage stocke aussi des objets JSON, maintenus localement d’une session à l’autre et partagés pour toutes les pages d’une même origine.

Ces deux nouveaux objets implémentent l’interface Storage qui fournit les méthodes :

• getItem(key), setItem(key), removeItem(key), permettent de gérer les objets du tableau.
• key(index) et length fournissent la longueur du tableau et la clé de l’objet stocké à un certain indice.
• clear() vide entièrement le tableau.

Mais vous pouvez aussi bien les utiliser comme de simples objets JavaScript :

if (!localStorage.drafts){
  localStorage.drafts = [];
}else {
  // Afficher les drafts stockés
}

Dans une application disponible hors ligne, les modifications pourront être enregistrées dans le localStorage, pour être synchronisées plus tard quand le navigateur repassera en ligne. En REST, l’état pourra être stocké du côté navigateur dans le sessionStorage. Un autre exemple d’utilisation peut être l’enregistrement des préférences utilisateur thème et personnalisation. Déjà disponible dans Firefox, Chrome, Safari et IE 8, le WebStorage sera supporté partout à la sortie d’Opera 10.50.

http://dev.w3.org/html5/webstorage

Offline Web Application

L’idée est de fournir des applications qui peuvent fonctionner sans connexion à internet. La solution repose sur une gestion fine de la mise en cache des ressources et la mise à disposition d’un événement notifiant le changement d’état de la connexion online/offline. On pourra aussi utiliser WebStorage pour enregistrer, hors ligne, les nouveaux mails à envoyer plus tard quand la connexion sera de nouveau disponible.

La gestion du cache se fait via un fichier MANIFEST qui liste les règles de mises en cache.

CACHE MANIFEST
index.html
style/default.css
images/logo.png
images/backgound.png
NETWORK:
server.cgi
FALLBACK:
online/images offline/images

Le fichier manifest contient plusieurs sections :

• CACHE liste les url des fichiers à conserver dans le cache, c’est la section par défaut.
• NETWORK permet de lister les urls qui ne doivent pas être conservées dans le cache.
• FALLBACK liste des pairs d’urls. Si la première ne répond pas la seconde sera utilisée.

Pour le déclarer, il suffit ensuite de l’ajouter dans la balise html des pages.

<!DOCTYPE HTML>
<html manifest="demo.manifest">

Attention, le fichier demo.manifest doit être servi avec le type mime text/cache-manifest, pour garantir son traitement par le navigateur. Au premier accès à la page, le navigateur va télécharger et stocker les ressources dans le cache, éventuellement en notifiant l’utilisateur. Au prochain accès, le navigateur vérifiera la version du fichier manifest sur le serveur, et téléchargera la mise à jour, ou affichera directement la page du cache.

Les scripts peuvent suivre le chargement et forcer le passage d’une version du cache à une autre.

var cache = window.applicationCache;
// Mise à jour du cache
cache.update();
// Passage au nouveau cache et invalidation de l'ancien sur updateReady
cache.swapCache();

L’objet ApplicationCache fournit en plus des deux méthodes, un status indiquant son état en cours et quelques événements permettant de suivre les changements d’état du cache.

Nous avons donc, de quoi conserver les pages d’une application pour pouvoir les afficher hors ligne, avec une solution pour fournir un contenu alternatif lorsque le navigateur n’est pas connecté. Bien sûr, il faut aussi prévoir un traitement alternatif en JavaScript lorsque le navigateur est hors ligne. L’objet window hérite donc d’une propriété booléenne online, accompagnée des événements online et offline.

Les applications hors ligne sont utilisables, dès aujourd’hui, sur Safari, Firefox, Chrome et Internet Explorer via gears. Attention tout de même, l’implémentation fournie par gears diffère un peu de la spécification.

http://www.w3.org/TR/html5/offline.html

Geolocation

La Géo-localisation, ou Geolocation en anglais est une nouvelle API qui permet de récupérer auprès de l’objet navigator, les coordonnées complètes de l’utilisateur (longitude, latitude, et altitude). C’est comme ça que fonctionne le bouton « Where am I » de google maps sur l’iPhone par exemple. La spécification va un peu plus loin en permettant de faire un suivi de la position courante, de connaitre la vitesse et de retrouver la dernière position connue en cas d’indisponibilité.

Voici, un petit exemple issu de la spécification :

 function showMap(position) {
      // Show a map centered at (position.coords.latitude, position.coords.longitude).
 }
    // One-shot position request.
 navigator.geolocation.getCurrentPosition(showMap);

Pour plus de détail sur l’API proprement dite, je vous invite à lire la spécification qui montre des exemples de code facilement compréhensibles. Bien qu’expérimentale dans Internet Explorer, la fonctionnalité est disponible dans tous les navigateurs récents. Là encore, attention, Chrome vient d’intégrer l’implémentation HTML5 de la géo-localisation qui remplace celle de Gears. Si le système fonctionne très bien sur les mobiles grâce au GPS et au triangulation GSM, il s’avère assez hasardeux dès qu’il repose sur la géolocalisation par adresse IP.

http://dev.w3.org/geo/api/spec-source.html

WebSocket

Avec les server-event, les WebSockets permettent d’établir une communication bi-directionnelle asynchrone entre le navigateur et le serveur, l’idée est de supporter le push server. En fournissant une API native qui ne nécessite pas de « bidouille » à base de requêtes Ajax ou d’iframe pour gérer les notifications du serveur. Les WebSocket tentent donc de fournir un cadre standard pour les applications Comet.

Les WebSocket fournissent deux méthodes :

• send( data_string) pour envoyer un message au serveur.
• close() pour fermer la socket.

Les messages envoyés par le serveur sont notifiés par l’événement onmessage contenant le message du serveur sous forme de chaîne. Les événements onerror, onopen et onclose permettent de suivre en temps réel l’état de la connexion. Côté protocole, la spécification est développée conjointement avec un draft déposé par Google à l’IETF. Le protocole WebSocket imaginé par Ian Hickson permet de valider l’origine des messages pour la sécurité et évite les lourdeurs de HTTP. Il est donc compatible avec le modèle de sécurité standard des navigateurs, et autorise même l’utilisation de proxy. Le protocole WebSocket est à considérer comme un protocole de transport qui va pouvoir être utilisé, pour encapsuler d’autres protocoles. Nous connaissons déjà l’exemple de Jabber qui est utilisé par Google Talk, mais il devient aussi possible de transporter des messages JMS ou AMQP. Ce type de connexion a des chances de venir concurrencer sérieusement les solutions fournies par Flash.

Par contre, la spécification est encore jeune et ne bénéficie pas pour le moment d’un large support parmi les navigateurs. Seul Chrome a terminé son implémentation depuis quelques semaines, Safari devrait suivre bientôt. A priori du côté de Firefox, le travail est déjà bien avancé puisque le bug est en cours de traitement depuis près d’un an. Il y a fort à parier que la prochaine version majeure du renard brûlant supportera les WebSockets. Pour ce qui est d’Opera et d’Internet Explorer aujourd’hui rien n’est fait mais je ne sais pas ce que l’avenir nous réserve.

Outre le navigateur, les WebSockets posent aussi un problème d’infrastructure puisqu’il ne s’agit plus de fournir seulement un serveur HTTP mais en plus un serveur web socket. Il existe déjà quelques solutions serveur telles que Kaazing gateway et Jetty qui supportent des WebSocketServlet. Mais l’offre est encore très réduite et expérimentale, il faudra attendre encore quelque temps avant de pouvoir bénéficier de serveurs web socket éprouvés.

http://dev.w3.org/html5/websockets/

Web SQL Database

Apple et Google ont décidé d’aller plus loin que le simple stockage NoSQL du navigateur en proposant une véritable base de données SQL embarquée dans le navigateur. Une fois de plus, c’est l’évangéliste HTML5 Ian Hickson qui rédige la spécification pour le W3C. Web SQL Database fonctionne de la même façon que le localStorage à la différence près qu’il s’agit bel et bien d’une base SQL stockée elle aussi par origine (nom de domaine racine). Comme d’habitude en JavaScript, l’API fonctionne en asynchrone grâce à l’utilisation de fonction callback. Elle permet d’ouvrir ou de créer une base avec un numéro de version pour gérer les évolutions du modèle. Une fois la base ouverte, il est possible d’exécuter des requêtes SQL avec paramètres au sein d’une transaction. La fonction de callback reçoit l’objet SQLResultSet qui contient les données lues en base ou les informations liées à l’insertion où la mise à jour des tuples en base de données.

// ouverture de la base  et création si besoin
window.openDatabase('documents', '1.0', 'Offline document storage', 5*1024*1024, function (db) {
    db.changeVersion('', '1.0', function (t) {
      t.executeSql('CREATE TABLE docids (id, name)');
    }, error);
});
var span = document.getElementById('docCountSpan');
// Lecture du nombre de document en base
db.readTransaction(function (t) {
    t.executeSql('SELECT COUNT(*) AS c FROM docids', [], function (t, r) {
      span.textContent = r.rows[0].c;
    }, function (t, e) {
      // couldn't read database
      span.textContent = '(unknown: ' + e.message + ')';
    });
  });

Il existe maintenant aussi des méthodes synchrones pour accéder à la base qui peuvent être utilisées sans risque dans un Worker. Si les appels sont réalisés directement dans la page, utilisez toujours les méthodes asynchrones pour éviter les effets de bords type navigateur figé toujours désagréables.

Cette spécification, bien que prometteuse, n’est pas considérée comme stable. Le problème vient du langage SQL soutenu par la spécification qui n’est pour le moment qu’une redirection vers la documentation SQLite. L’API est donc figée en attente d’un navigateur qui utilisera un autre backend de base de données. Pour l’instant, tout le monde utilise SQLite, que ce soit avec Gears pour Firefox et Internet Explorer ou en natif dans Chrome, Opera et Safari.

http://dev.w3.org/html5/webdatabase/

Drag’n'drop

L’API cette fois vient d’Internet Explorer puisqu’elle existe depuis IE 6. Elle permet de définir un élément pour recevoir les objets déposés par l’utilisateur via l’événement ondrop, et de suivre l’objet glissé par l’utilisateur sur la page où le receveur d’objet déposé via six événements (dragstart, drag, dragend, dragenter, dragover, dragleave). L’idée offre des perspectives sympathiques:

• Gérer l’upload de fichier par glisser-déposer.
• Récupérer proprement le texte glissé.
• Supporter nativement le drag and drop des éléments de la page.

C’est sur ce dernier point que la spécification apporte une réelle nouveauté avec l’attribut dragable qui peut-être positionné directement sur les balises de la page. Malheureusement seul Firefox supporte ce nouvel attribut. Pour le reste, les auteurs se sont contentés de recopier l’API Microsoft comme l’ont fait tous les navigateurs. Seul Opera résiste encore à cette API lourdement critiqué à travers la blogo-sphère. Il y a d’abord trop d’événements impliqués dans le simple glissé-déposé, mais ils sont en plus dépendants les uns des autres. Par exemple, pour espérer recevoir ondrop sur un élément HTML, il faudra recevoir et annuler l’événement dragover.

http://dev.w3.org/html5/spec-author-view/dnd.html

ContentEditable

Pour cette dernière étape de notre tour d’horizon des API JavaScript, j’ai décidé de vous parler de l’attribut contenteditable. Cet attribut active l’édition en ligne du contenu de l’élément. Il s’agit d’un éditeur WYSIWYG basique qui permet donc d’éditer directement le contenu de la page. Plus besoin de remplacer à la volée le texte par un input ou une textarea, il suffit de positionner l’attribut contenteditable sur la balise voulue. C’est ensuite au tour de l’attribut designmode de rentrer en jeu : placé à on le contenu de l’élément devient éditable. Toutes les modifications apportées par l’utilisateur pourront être traitées à la fin de l’édition.
Le tout est servi avec une API permettant d’autoriser et d’exécuter des command sur le texte en cours d’édition. Les commandes vont de passer le texte en italique à insérer une image ou créer une liste. Bref, si la spécification n’est pas encore complète, elle a l’ambition de fournir une API d’édition de texte riche pour tous les navigateurs HTML5. La bonne nouvelle de ce côté étant que les navigateurs principaux sont tous de la partie. Surtout Internet Explorer qui supporte l’édition en ligne depuis sa version 5.5 et a très largement inspiré cette fonctionnalité.

Pour plus d’information sur le sujet, vous pouvez jeter un œil à la spécification du W3C ou lire cet article d’introduction en anglais sur le blog du WHATWG.

Conclusion

Dans l’ensemble, les API JavaScript spécifiées dans HTML5 sont convaincantes et plutôt bien supportées par les navigateurs. Bien sûr Internet Explorer est à la traine mais les rumeurs vont bon train sur la roadmap d’IE 9. A l’occasion du MIX 2010, une conférence Microsoft de trois jours autour du développement web qui se tenait cette semaine, la preview IE9 a été publiée cette semaine. Avec cette pré-version, Microsoft confirme son entrée dans la bataille HTML5 avec : la vidéo, le canvas, une machine JavaScript largement optimisée et 55 points au test ACID CSS3. Même Mike Shaver haut responsable de Firefox félicite cette nouvelle concurrence dans un Tweet. Plus performant, plus portable et plus puissant, avec HTML5 JavaScript peut gagner ses lettres de noblesses, voire même, convaincre les foules de développeurs réticents. Outre l’intérêt maintenant avéré de Microsoft pour la spécification, HTML5 manque cruellement d’outils pour pouvoir concurrencer Flex. Amis éditeurs à votre bon cœur.

• HTML5 Demos and Examples
• Table de compatibilité des navigateurs HTML5, CSS3, SVG
• Draft HTML5 du W3C

Sommaire

• HTML5 ?
• Nouveau modèle de contenu
• Nouveaux éléments de mise en page
• Eléments interactifs
• Les WebForms
  • Nouveaux input
  • Validation native
  • Auto-complétion
  • Répétitions
  • Etat des lieux
• Multimedia
  • Audio et Video
  • La guerre des Codecs
  • Le Canvas
• Conclusion

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s’agit d’une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L’idée d’une nouvelle version de HTML serait motivée par quelques constats simples :

• Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
• La structure des documents n’est pas intuitive et rend l’accessibilité difficile
• Les API JavaScript varient trop d’un navigateur à l’autre pour garantir la portabilité des documents
• Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l’émergence du web sémantique, la spécification propose :

• Un nouveau modèle de contenu des éléments
• Des éléments de mise en page
• De nouveaux éléments pour les formulaires
• Du contenu multimédia
• Plus d’interactivité
• Des APIs standards JavaScript

Bien que la spécification soit encore en cours d’écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

• La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
• Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
• Interactive définit les éléments qui fournissent une interaction avec l’utilisateur
• Embedded affiche des ressource externes dans le document
• Les Metadata représentent tout ce qui n’est pas affiché (style, script, …)
• Heading définit les en-têtes d’une section
• Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d’une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d’autre part ces catégories permettent aux navigateurs d’assimiler le contenu de la page, notamment pour les exports d’impression ou l’accessibilité.

Nouveaux éléments de mise en page

Jusqu’à maintenant, l’élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d’empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

• Ce n’est pas intuitif pour le développeur, vous en conviendrez.
• Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d’aide à la navigation.

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s’organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d’utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l’organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L’algorithme nécessaire est d’ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l’exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l’interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d’une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d’éléments permettant de lancer des commandes.

<menu type="toolbar">
 <li>
  <menu label="File">
   <button type="button" onclick="fnew()">New...</button>
   <button type="button" onclick="fopen()">Open...</button>
   <button type="button" onclick="fsave()">Save</button>
  </menu>
 </li>
 <li>
  <menu label="Edit">
   <button type="button" onclick="ecopy()">Copy</button>
   <button type="button" onclick="epaste()">Paste</button>
  </menu>
 </li>
</menu>

Pour les commandes, HTML5 propose directement un élément command qui permet d’associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d’ajouter l’attribut contextmenu="menu_id", sur l’élément qui doit utiliser le menu.

L’autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d’un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l’utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

<section class="progress window">
 <h1>Copying "Really Achieving Your Childhood Dreams"</h1>
 <details>
  <summary>Copying... <progress max="375505392" value="97543282"></progress> 25%</summary>
  <dl>
   <dt>Transfer rate:</dt> <dd>452KB/s</dd>
   <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
   <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
  </dl>
 </details>
</section>

Ici, le tag details est utilisé pour cacher les informations techniques d’une copie. Vous noterez au passage l’utilisation d’une balise progress, pour afficher une barre d’avancement.

Les WebForms

Nouveaux input

Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu’une API JavaScript de validation en plus d’une interactivité accrue. Parmi les nouveaux types d’input, il y a :

• Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n’aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
• La saisie de formats numériques via les number et les range qui pourront prendre la forme d’un slider vertical ou horizontal
• Différents types de chaînes formatées comme les url, les email et tel
• Le selecteur de couleur color
• Le champ de recherche search

Les anciens types sont maintenus. Ils bénéficient d’un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d’un seul coup, tout en précisant le type mime accepté. Il y a aussi l’attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n’est pas renseigné.

Validation native

Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l’utilisateur, et peuvent interdire la soumission du formulaire, s’il n’est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s’accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, …).

Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

• required pour un champ requis
• min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
• pattern fournit une expression régulière que la saisie doit respecter

Auto-complétion

Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l’aide d’éléments de type liste (li, option, …). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l’attribut list. Une fois l’association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l’intérieur de la liste peuvent-être décorés par CSS directement.

<input type="text" list="roles" autofocus />
<datalist id="roles">
   <li>Designer</li>
   <li>Integrateur</li>
   <li>Programmeur</li>
</datalist>

Répétitions

Une autre évolution sympathique est la création d’un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

<tr id="order" repeat="template" repeat-start="3">
   <td><input type="text" name="row[order].product" value=""></td>
   <td><input type="text" name="row[order].quantity" value="1"></td>
   <td><button type="remove">Remove This Row</button></td>
</tr>
<p><button type="add" template="order">Add Row</button><button type="submit">Submit</button></p>

C’est l’attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d’éléments précédemment soumis. Pour assurer l’ajout et la suppression de ligne, j’ai utilisé les boutons de type add et remove mais j’aurais aussi bien pu utiliser des méthodes JavaScript de l’élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l’ordre des répétitions permettant de monter et descendre les lignes répétées.

Etat des lieux

Voilà la promesse d’un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d’autres termes, il sera possible de placer nos input pour un formulaire à l’extérieur de ce dernier.

Comme vous l’avez remarqué, j’ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s’y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l’API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l’on sait, c’est que l’éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

Page de démonstration pour Chrome, Safari et Opera.

Multimedia

Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd’hui que Flash est utilisé principalement pour 3 choses dans les applications :

• Pouvoir écouter de la musique
• Pouvoir regarder des vidéos
• Faire des animations de folies

J’ai mis volontairement de côté Flex car il cible plutôt les applications d’entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler . Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

• audio permet de gérer la lecture de fichiers audio en streaming.
• video assure la lecture de vidéos en streaming toujours.
• canvas permet de dessiner et de faire des animations en JavaScript.

Audio et Video

Jusqu’à maintenant, les gros avantages de la technologie d’Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

• controls pour activer l’affichage de l’interface de contrôle du navigateur
• autobuffer pour activer le chargement automatique de la ressource en cache
• autoplay pour activer le lancement automatique de la lecture
• loop pour lire le ou les médias en boucle
• src pour fournir l’url du fichier média à lire

La balise source placée à l’intérieure d’une balise audio ou video permet aussi de définir l’url (@src), le type mime et le codec (@type) d’une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

<audio controls autobuffer autoplay loop>
  <source src="elvis.ogg" />
  <source src="elvis.mp3" />
</audio>
<video src="video.ogg" controls>
  <source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <!-- Un texte alternatif pour les anciens navigateurs -->
  Your browser does not support the <code>video</code> element.
</video>

Si le navigateurs n’arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l’élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

Si vous ne voulez pas utiliser l’interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l’API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

De plus l’interface HTMLMediaElement fournit quantité de propriétés allant du volume à l’état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d’une batterie d’événements qui permettent de suivre l’avancement du chargement, l’état du lecteur, et les action lancées par l’utilisateur.

Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

La guerre des Codecs

Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l’audio avec AAC, FLAC, Vorbis, … La spécification laisse le libre choix aux navigateurs et table sur la création d’extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd’hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d’H.264, à mon sens, tient au fait qu’il est parfaitement adapté à l’embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

Codecs supportés par navigateurs

Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s’intéresse au sujet pour l’avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l’embarqué, iPhone et iPod Touch en tête, qui, d’une part, supportent pleinement les balises audio, et video, et d’autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

Le Canvas

Passons maintenant au canvas. Inventé par Apple pour le Dashboard d’OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L’objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l’API permet de faire de la composition, des transformations, de manipuler des images et d’afficher du texte formaté. Avec un timeout ou un intervalle sur l’objet et un peu de JavaScript, il devient possible d’animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d’animation. Il existe déjà un tas de librairie JS construites autour de l’élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

<canvas id=firstCanvas">Browser does not support the canvas element.</canvas>
<script type="text/JavaScript">
var canvas=document.getElementById('myCanvas');
var ctx=canvas.getContext('2d');
ctx.fillStyle='#FF0006';
ctx.fillRect(0,0,80,120);
</script>

Les détracteurs déplorent l’utilisation d’une API procédurale, et l’absence d’éléments crées dans l’arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

Voilà pour les domaines d’application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d’habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

Conclusion

Nous voici à la fin de ce tour d’horizon des nouveautés d’HTML5, côté contenu du moins.
Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd’hui. Il faudra attendre la sortie d’IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu’il s’imposera sur le web. Il faudra aussi regarder de près l’évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

Il reste un problème d’outillage, car il n’existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l’export vers d’autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d’implémentation.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

Les styles

Avec Flex, les styles sont très simples à mettre en place, et se font de la même manière qu’en HTML :

• Soit via la définition des styles directement dans le fichier MXML :

<mx:Style>
	myStyle {
		fontFamily: "arial";
		background-color:#FFFFFF;
	}
</mx:Style>

• Soit via la définition d’une feuille de styles CSS, déclarée dans le fichier MXML :

<mx:Style source="css/xebia.css"/>

Concernant le composant DataGrid, modifier les couleurs des lignes devient trivial avec la propriété alternatingItemColors. Néanmoins la situation se corse lorsque nous devons appliquer ces couleurs aux lignes d’une seule colonne…

Exemple

Prenons un exemple :

XebiaCustomDataGrid1.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

Dans cet exemple, nous avons un simple DataGrid remplit avec une ArrayCollection, et dont les lignes ont des couleurs alternées.

Dans ce second exemple, nous ajoutons une CSS :

xebia.css

.grid {
	alternatingItemColors: #ffccff, #ff99cc;
}
.header {
	fontWeight: bold;
}

XebiaCustomDataGrid2.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Style source="css/xebia.css"/>
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" styleName="grid" headerStyleName="header" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

On notera l’ajout des attributs styleName et headerStyleName dans les propriétés du DataGrid, ainsi que de la déclaration de la CSS :

<fx:Style source="css/xebia.css"/>

Nous obtenons ainsi le rendu suivant :

Mais que faire si nous voulons appliquer un style sur une seule colonne ? La solution consiste à surcharger les cellules de la colonne concernée par un renderer. Pour ce faire, une classe ActionScript doit être mise en place.

Voici la classe CustomCell.as :

public class CustomCell extends Label
     {
      override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
        {
            super.updateDisplayList(unscaledWidth, unscaledHeight);
            var g:Graphics = graphics;
            g.clear();
	    	if (DataGridListData(listData).rowIndex % 2 == 0) {
	        	g.beginFill(0xffdfbf);
	     	} else {
	     		g.beginFill(0xffc080);
	     	}
	        g.drawRect(0, -2, unscaledWidth+1, unscaledHeight+4);
	        g.endFill();
        }
     }

Ainsi pour chaque ligne, nous dessinons un rectangle dans la cellule avec la même alternance de couleurs.
Il ne nous reste plus qu’à appliquer ce renderer au DataGrid.

XebiaCustomDataGrid3.mxml

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<fx:Style source="css/xebia.css"/>
	<fx:Script>
	<![CDATA[
			import mx.collections.ArrayCollection;
			[Bindable]
			public var xebia:ArrayCollection = new ArrayCollection([
				{Company:"Xebia France", City:"Défense", Benefits:200000},
				{Company:"Xebia Hollande", City:"Hilversum", Benefits:400000},
				{Company:"Xebia Inde", City:"New Dehli", Benefits:150000},
				{Company:"Xebia US", City:"New York", Benefits:500000},
				{Company:"Xebia Allemagne", City:"Berlin", Benefits:160000},
				{Company:"Xebia Espagne", City:"Barcelone", Benefits:80000},
				{Company:"Xebia Portugal", City:"Lisbonne", Benefits:75000},
				{Company:"Xebia Italie", City:"Milan", Benefits:110000}
			]);
		]]>
	</fx:Script>
	<mx: DataGrid dataProvider="{xebia}" sortableColumns="false" selectable="false" styleName="grid" headerStyleName="header" height="228" width="515">
		<mx:columns>
			<mx: DataGridColumn headerText="Company" dataField="Company"/>
			<mx: DataGridColumn headerText="City" dataField="City"/>
			<mx: DataGridColumn headerText="Benefits" dataField="Benefits" itemRenderer="renderer.CustomCell"/>
		</mx:columns>
	</mx: DataGrid>
</s:Application>

Nous remarquons que la propriété itemRenderer a été ajoutée sur la troisième colonne du DataGrid.

Ainsi nous obtenons le rendu suivant :

Enfin à travers cet exemple nous revoyons une des limites de Flex: malgré la richesse des composants et de leurs comportements, lorsque les développements deviennent un peu plus subtils, du code ActionScript est nécessaire, là où dans cet exemple une simple instruction CSS aurait suffit…

En espérant que cette solution puisse aider d’autres personnes !

Vous pouvez télécharger les sources sur le SVN de Xebia France.

Qu’est ce qu’un effet ?

Flex 3

En Flex, il est possible de définir des effets pour des transitions ou lors du déclenchement d’un évènement (hide, show par exemple).
Nous allons reprendre l’exemple du Dissolve disponible sur le Flex 3 Component Explorer.
On commence par définir les effets :

<mx: Dissolve id="dissolveOut" duration="1000" alphaFrom="1.0" alphaTo="0.0"/>

Puis on indique au composant cible, l’effet qu’il doit utiliser lorsque l’on cache le label :

<mx:Label text="Nokia 9930"
          fontSize="14"
          visible="{cb1.selected}"
          hideEffect="{dissolveOut}"/>
...
<mx:CheckBox id="cb1" label="visible" selected="true"/>

Dans Flex 3, il n’est pas possible de gérer des effets sur la valeur d’une propriété comme le texte ou la couleur par exemple. Les effets ne sont en effet applicables que sur les composants.

Flex 4

La nouveauté dans Flex 4 tient tout d’abord dans la définition d’une nouvelle super classe Animate qui vient remplacer TweenEffect. Cette nouvelle super classe fournit de nouvelles propriétés telles que easer, interpolator et motionPaths que nous verrons par la suite.

Dans cette nouvelle version, les effets sont plus flexibles et il est possible de :

• modifier la valeur des propriétés telles que le gradient d’une couleur ou la taille,
• régler la vitesse de l’effet, lui donner une accélération au début ou à la fin par exemple,
• déplacer plus facilement les composants lors d’un effet.

Les nouveaux effets

Les effets 3D

Parmi les nouveaux effets, voici probablement les plus impressionnants d’entre eux : les effets en trois dimensions. Grâce à Flash Player 10 qui est maintenant capable de représenter un objet 3D, on peut par exemple exécuter un effet de déplacement en profondeur ou une rotation.

La configuration des effets

Avec cette nouvelle super classe Animate viennent de nouvelles propriétés :

• easer : l’atténuation de l’effet (en quelque sorte une accélération ou décélération avec laquelle l’effet sera appliqué),
• interpolator : fonction utilisée par l’effet pour calculer les valeurs à prendre pour une propriété entre le début et la fin de cet effet,
• motionPaths : un vecteur contenant des objets MotionPath, chacun portant le nom et la valeur que la propriété peut prendre,
• repeatBehavior : permet de répéter l’effet.

Avec ces nouvelles fonctions, il est encore plus simple de réaliser des effets customisés comme par exemple un bouton qui s’enfonce lorsque l’on clique dessus, ou un changement de couleur lorsque le curseur pointe un composant. Maintenant à vous de laisser parler votre imagination.

La plateforme Flash : qu’est ce que c’est ?

Cette plateforme Flash est composée de :

• La gamme Creative Suite (avec Fireworks, Photoshop et Illustrator) destinée au designer.
• Flash Catalyst qui permettra de générer une application Flex à partir des maquettes réalisées avec les outils précédents.
• Flash Builder 4 pour le développement du reste de l’application et de son backend.

Flash Catalyst

Pour rappel Flash Catalyst est un outil permettant à partir d’un dessin réalisé avec les outils de la gamme Creative Suite de générer une véritable application Flex sans toucher à une ligne de code. Cet outil est capable de générer tous les composants graphiques disponibles dans Flex 4 et gèrent également les itemrenderer. Les effets et les transitions peuvent être également gérés avec cet outil. Lors de la session Tools In Action, une démonstration bluffante d’environ 30 minutes a été effectuée avec cet outil. Il y a cependant quelques conditions pour que la génération s’effectue au mieux :

• Penser à bien séparer ses filtres et à les nommer proprement. Ceci afin que l’intégrateur puisse plus aisément les récupérer et les convertir en composant Flex.
• L’intégrateur doit aussi bien nommer les composants une fois créés afin que le développeur puisse les exploiter plus facilement.

À la fin de cette courte session, nous avons pu voir le résultat : une application Flex reprenant la maquette de départ.

Flex 4

Cette nouvelle plateforme ne peut être utilisée qu’avec Flex 4. En effet, la nouvelle librairie de composants graphiques spark qui vient remplacer l’ancienne (que l’on nomme halo ou mx aussi) proposent de séparer l’aspect du composant de son comportement. Un billet a déjà été écrit à ce sujet. C’est ce qui permettra à Catalyst de générer l’aspect des composants. Le développeur quant à lui ne se préoccupera plus que des comportements du bouton tels que le traitement des données, la gestion des événements et le traitement avec le backend. Les composants peuvent également supporter les formes primitives (rectangles, ronds, carrés), les bitmaps, les textes riches et les vidéos. Autre nouveauté dans ce nouveau SDK, une nouvelle structure du code : les déclarations des HTTPService et autres RemoteObject s’effectuent dans les balises <fx:Declaration>.

Spring BlazeDS Integration

Parmi les nouveautés, nous noterons la présentation de Spring BlazeDS Integration. Avec moins de configuration que BlazeDS, il est possible de mettre en place plus facilement un backend utilisant Spring. Grâce à des annotations, il est maintenant plus simple d’exposer ses services à la partie cliente.

Exemple :

@Service("contactService")
@RemotingDestination
public class ContactDao {
...

On expose contactService à la partie cliente. Côté Flex, il n’y aura plus qu’à simplement appeler ce service grâce au RemoteObject. Concernant le lien client-serveur, Christophe Coenraets soulève un point intéressant : actuellement il est impossible pour le compilateur Flex de reconnaître les services exposés côté serveur. Effectivement, à ce niveau là le compilateur doit croire le développeur et ne possède aucune réelle visibilité. C’est pour cela que dans Flash Builder 4 a été ajoutée la possibilité de réaliser de l’introspection sur les services exposés côté serveur. Fonctionnant avec BlazeDS, LiveCycle Data Service ES et AMF PHP, Flash Builder est donc maintenant capable de reconnaître ses services et de les importer côté client.

Model Driven Development dans FlashBuilder

Une autre nouveauté dans FlashBuilder 4 est une nouvelle vue nommée Data Models permettant de réaliser des modèles de données et de les générer autant côté client que côté Serveur. Cette partie sera davantage détaillée dans la session de Jeudi : Model Driven Development using Adobe Flash Builder 4 and LiveCycle Data Services ES.

La présentation était réussie et les démonstrations très bluffantes. Flash Catalyst semble mature et Flash Builder 4 répond mieux aux besoins des développeurs (il est enfin possible de faire un Generate getter/setter sur une propriété !). Mais on attend toujours la release qui est maintenant prévue pour mi-2010 voire même un peu après.

• Les effets
• Dessine moi un bouton … avec spark.
• Les autres nouveautés de Flex 4
• Conclusion
• Pour aller plus loin

Pour visualiser les exemples Flex 4 ci dessous, il vous faudra installer Flash Player 10.

Les effets

Une différence notable avec la précédente version de Flex est la gestion des états qui est maintenant nettement plus simple.
En Flex, il est possible de décrire plusieurs états associés à un composant. Ces états définissent, pour un composant, des éléments à ajouter, des styles ou des propriétés à appliquer. En effet, il est question de manipuler des AddChild, des SetProperty ou encore des SetStyle qui peuvent devenir très vite lourds à gérer. Pour mieux comprendre, prenons un exemple :
Nous allons réaliser une application sur 2 états, l’état blueState qui va colorer le label helloLabel en bleu et l’état redState qui va le colorer en rouge. Pour ce faire, avec Flex 3, nous utilisons les balises SetStyle qui permettent de modifier le style color du label et de le mettre à la couleur voulue.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" minWidth="300" minHeight="300">
    <mx:states>
        <mx:State name="blueState">
            <mx:SetStyle target="{helloLabel}" name="color" value="blue"/>
        </mx:State>
        <mx:State name="redState">
            <mx:SetStyle target="{helloLabel}" name="color" value="red"/>
        </mx:State>
    </mx:states>
    <mx:HBox>
        <mx:Label text="Bonjour !" id="helloLabel"/>
        <mx:Button label="Bleu" id="blue" click="currentState='blueState'"/>
        <mx:Button label="Rouge" id="red" click="currentState='redState'"/>
    </mx:HBox>
</mx:Application>

Avec Flex 4, il n’est plus question de définir des SetStyle ou SetProperty dans les composants. Tout se fait dans les attributs qui peuvent se décliner en fonction des états comme ceci : styleOuPropriete.monEtat. Ainsi color.blueState prendra la couleur bleu lorsque l’on sera dans cet état.D’autre attributs apparaissent également dans les composants graphiques comme includeIn ou encore excludeFrom pour permettre d’exclure ou d’inclure un composant en fonction de l’état courant. De plus, Flex prend maintenant par défaut le premier état lorsqu’on en définit plusieurs pour un composant. C’est la raison pour laquelle nous avons ajouté defaultState comme état par défaut. Avec Flex 4, notre précédent exemple donne donc ceci :

<?xml version="1.0" encoding="utf-8"?>
<s:Application
   xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" width="300" height="300">
	<s:states>
		<mx:State name="defaultState" />
		<mx:State name="blueState" />
		<mx:State name="redState" />
	</s:states>
	<mx:Label text="Bonjour !" color="black" color.blueState="blue" color.redState="red"/>
	<s:Button label="Rouge" click="currentState='redState'"/>
	<s:Button label="Bleu" click="currentState='blueState'"/>
	<s:layout>
		<s:HorizontalLayout />
	</s:layout>
</s:Application>

Certes, il s’agit d’un petit exemple. Mais cela pourrait simplifier la gestion des états sur des applications plus élaborées.

Dessine moi un bouton … avec spark.

De nouvelles librairies ont vu le jour dans Flex 4. Commençons par la librairie spark, présente depuis Mai 2009. Elle offre toute une nouvelle génération de composants dont l’architecture est clairement différente de son prédécesseur halo. Cette dernière proposait des composants graphiques sur lesquels il n’était possible que de changer les couleurs et le style du texte : le Flex Style Explorer en est un bon exemple.
La librairie spark, de son côté, propose un nouveau type de composant « skinnable », c’est-à-dire que nous avons d’un côté le dessin représentant un bouton et de l’autre l’objet bouton. De plus, spark intègre la librairie FXG qui fournit tous les composants permettant de faire des dessins vectoriels.
Pour mieux comprendre le fonctionnement, rien de mieux qu’un exemple :
Nous créons d’abord un Skin sous le nom de component.CustomSkin.

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" height="300" width="300">
    <fx:Metadata>
        [HostComponent("spark.components.Button")]
    </fx:Metadata>
    <s:states>
        <mx:State name="up" />
        <mx:State name="over" />
        <mx:State name="down" />
    </s:states>
    <s:Ellipse height="86" width="96" verticalCenter="0" horizontalCenter="0">
        <s:fill>
          <mx:SolidColor color="#FF0000" color.over="red" color.up="blue"/>
         </s:fill>
    </s:Ellipse>
    <s:layout>
        <s:BasicLayout/>
    </s:layout>
</s:Skin>

Nous définissons le comportement de ce composant grâce au metatag HostComponent, ici il s’agit donc d’un bouton. Nous ajoutons ensuite les états en regardant dans la documentation, nous pouvons voir que Button dispose des états : up, over, down et disabled. Contentons-nous des trois premiers états pour cet exemple. Enfin, on finit par dessiner un bouton qui sera disposé dans un layout qui doit être défini dans tout composant spark. Ce skin est ensuite associé à un bouton dans l’application principale.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/halo"
    minWidth="1024" minHeight="768"
    xmlns:component="component.*">
    <fx:Script>
        <![CDATA[
            import mx.controls.Alert;
            import component.MyButton;
        ]]>
    </fx:Script>
    <fx:Style source="TestFlex4.css"/>
    <s:Button skinClass="component.CustomSkin"  click="Alert.show('Je suis un bouton !')"/>
</s:Application>

Et voici le rendu :

Les autres nouveautés de Flex 4

Support dans l’ASDoc des fichiers MXML
La SDK de Flex 3 ne générait que la documentation associée au code ActionScript 3. Il est maintenant possible dans le SDK 4 de générer de l’ASDoc pour les composants MXML.

Le data binding dans les deux sens
Actuellement, la liaison des données dans un composant avec Flex se fait de la façon suivante :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:TextInput id="myText1" />
    <mx:TextInput id="myText2" text="{myText1.text}" />
</mx:Application>

Dans cet exemple, l’édition dans myText1 modifie le champs myText2 mais l’inverse ne se fait pas. Pour les lier tous les deux il faudrait modifier myText1 comme ceci :

<mx:TextInput id="myText1" text="{myText2.text}"/>

Avec la nouvelle notation que propose Flex 4, il suffit de faire comme ceci :

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
    <s:TextInput id="myText1" />
    <s:TextInput id="myText2" text="@{myText1.text}" />
    <s:layout>
        <s:VerticalLayout/>
    </s:layout>
</s:Application>

Et automatiquement les deux composants sont liés.

Conclusion

Toutes ces nouveautés proposées par Adobe ont pour but :

• d’améliorer la productivité du développeur en simplifiant le langage,
• d’avoir plus de liberté sur le design.

La librairie spark propose des composants radicalement différents de ce que l’on peut actuellement utiliser dans Flex 3, mais il est cependant possible d’utiliser les composants de l’ancienne librairie nommée halo. Les habitués ne s’y perdront donc pas.
Mais alors pourquoi autant de changement ? La raison est très simple et se nomme Flash Catalyst. Le nouvel outil d’Adobe sorti en Juin 2009 en version bêta est capable de générer du code Flex à partir de dessins réalisés par la gamme Creative Suite 4.
Flex 4 est toujours en bêta actuellement, une release est prévue pour le dernier trimestre 2009.

Pour aller plus loin

• LiveDocs Flex 4
• Télécharger le SDK

Afin de déclarer votre service Remote, les lignes suivantes doivent être ajoutées dans votre applicationContext.xml :

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	<property name="mappings">
	    <value>
	        /*=mySpringManagedMessageBroker
	    </value>
	</property>
</bean>
<!-- Envoie les requêtes au "message broker" -->
<bean class="org.springframework.flex.servlet.MessageBrokerHandlerAdapter"/>
<!-- Le MessageBroker de BlazeDs -->
<bean id="mySpringManagedMessageBroker" class="org.springframework.flex.core.MessageBrokerFactoryBean" />
<!-- Service myService -->
<bean id="myService" class="com.xebia.impl.MyServiceImpl" />
<flex:remoting-destination message-broker="mySpringManagedMessageBroker" destination-id="myServiceDest" ref="myService" />

Ainsi que la référence au fichier xsd : http://www.springframework.org/schema/flex/spring-flex-1.0.xsd

Malheureusement, au démarrage de votre application, vous aurez cette erreur :

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 67 in XML document from ServletContext resource [/WEB-INF/classes/applicationContext-service.xml] is invalid;
        nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'flex:remoting-destination'.
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Pourtant cela fonctionnait parfaitement avec les versions précédentes de Spring BlazeDS Integration …

Je regarde donc le fichier xsd sur lequel se base mon applicationContext (http://www.springframework.org/schema/flex/spring-flex-1.0.xsd), et le remoting-destination est bien présent… étrange. Je regarde également la documentation du projet et d’après cette dernière, ma configuration est bonne … le mystère s’épaissit.

Après quelques recherches, j’ai l’idée de regarder le xsd du jar de Spring BlazDS Integration (org.springframework.flex-1.0.0.M2.jar). Et eureka, je trouve l’explication : le xsd du jar n’est pas le même que celui vers lequel pointe mon applicationContext… Au chargement de l’application, c’est le xsd du jar qui est recherché… De plus, je me rends compte que cette version a subi un peu de refactoring et certains chemins ont été modifiés.
Par conséquent, vous devez déclarer votre service Remote de cette manière :

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  <property name="mappings">
	   <value>
	       /*=mySpringManagedMessageBroker
	   </value>
  </property>
</bean>
<!-- Envoie les requêtes au "message broker" -->
<bean class="org.springframework.flex.messaging.servlet.MessageBrokerHandlerAdapter"/>
<!-- Le MessageBroker de BlazeDs -->
<bean id="mySpringManagedMessageBroker" class="org.springframework.flex.messaging.MessageBrokerFactoryBean" />
<!-- Service myService -->
<bean id="myService" class="com.xebia.impl.MyServiceImpl" />
<flex:remote-service message-broker="mySpringManagedMessageBroker" service-id="myServiceDest" ref="myService" />

Vous remarquerez que remoting-destination et destination-id sont devenus remote-service et service-id et que les chemins des classes MessageBrokerHandlerAdapter et MessageBrokerFactoryBean ont changé.

Néanmoins, une solution plus rapide consiste à effectuer une montée de version vers la 1.0.0.RELEASE de Spring BlazeDS Integration. En effet, le fichier xsd ainsi que les chemins ont été remis comme la version RC2, posant ainsi moins de problèmes.

En espérant que cette solution puisse aider d’autres personnes !

• La modularité : introduite par le projet Jigsaw, actuellement au cœur d’une polémique, elle devrait permettre de supprimer les principaux reproches faits aux précédents JDKs, à savoir leur lenteur au démarrage, le plat de spaghettis des dépendances, et l’enfer du classpath.
• La JVM polyglotte : capable d’exécuter de nombreux langages (la voie a été ouverte par JRuby), elle devrait faciliter l’émergence des langages dynamiques. C’est le projet DaVinci.
• Les ajouts au langage : ils sont listés dans le projet Coin. Danny a listé les switch sur les String, la gestion d’exceptions multiples, une meilleure inférence de type, et l’opérateur Elvis
• Plus d’APIs I/O : le Path remplace le File, manipulation des Directory, recherche en utilisant des FileVisitor, opérations asynchrones. On peut se demander si ce genre de fonctionnalités sera vraiment cross-platform (comportement identique ?).
• Nouveau Garbage collector : le fameux G1 (dont nous avons parlé ici) est disponible en preview dans le JSE 6 update 14 en utilisant l’option -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

La final release devrait être disponible (selon la roadmap annoncée) dans le courant du premier trimestre 2010.

On apprécie les efforts continus faits sur la VM mais nous regrettons que les évolutions du langage restent superficielles (c’est bien mais pas suffisant). C’est probablement l’une des raisons de l’émergence des langages dynamiques. Comme si Danny Coward avait voulu légitimer l’opening keynote de James Gosling : « la force de Java ce n’est pas son langage, mais sa VM ».

Dans cet article, je vais donc revenir sur les annonces et points marquants de ces deux jours de conférences.

D’autre part, les vidéos des keynotes sont disponibles, vous pouvez consulter celle du premier jour (html5, android, web components …) ou celle du second jour (google wave).

Google I/O 2009, voici ce que j’en ai retenu :

• Le futur du Web, avec les premières démonstrations émoustillantes HTML 5.
• Google Wave, le prochain outil de communication et collaboration made in Google.
• La réconciliation de Google avec GWT et la sortie de GWT Query.
• Le futur d’Android, avec l’annonce de la branche Android 2.0 : Donut.
• Java sur Google App Engine en GA.
• Google Web Elements, comment intégrer les services Google dans vos pages web.
• Les macros dans Google Document, avec Google Apps Script.
• Arrivée des extensions dans Chrome.

HTML 5, le premier whaou effect

C’est la première fois que HTML 5 me fait rêver. C’est en effet un sacré coup de pouce que Google à donné afin de faire taire les tergiversions. Google a pris position, et nous en a mis plein la vue ! C’est ainsi qu’a débuté le premier jour de conférence avec une vidéo d’introduction de 5 minutes présentant des applications écrites avec HTML 5. Application ai-je dit ? Eh bien oui, il semble bien loin le temps de la page web statique. Il semble bien loin le temps des hacks Javascript, arrêtons la bidouille et commençons le développement d’applications riches : c’est en tout cas ce que nous promet Google avec le HTML 5. Tout cela sans nécessiter le moindre plugin … pour peu que vous ayez un navigateur compatible.

Pour Google, le navigateur a encore de beaux jours devant lui. Installé sur prêt d’un demi-milliard d’ordinateurs, il reste le moyen le plus simple et répandu pour accéder à Internet. Google l’a bien compris et a participé à la course aux performances des moteurs JavaScript. En un an, les performances des moteurs JavaScript ont été multipliées par 5 ! Vous n’êtes pas fan de JavaScript, il faudra pourtant vous y faire. Comme nous vous pourrez le constater dans la suite de cet article, ce langage est l’un des points centraux de la stratégie Google.

Sans le savoir, vous possédez peut-être déjà l’un des navigateurs compatibles avec certaines fonctionnalités HTML 5, si tel est le cas vous pouvez lancer certaines des démonstrations présentées directement depuis celui-ci.

Les principales nouveautés apportées par HTML 5 sont :

• Les canvas, zone sur laquelle il est possible de dessiner et d’effectuer des transformations : agrandissement, rotations, translations sur différents types de figures.
• Des balises audio et video, qui permettent d’intégrer des médias dans le document sans nécessiter un plugin externe. Elles disposent de fonctionnalités similaires aux lecteurs Flash ou Silverlight vous permettant de contrôler le comportement de vos médias.
• Les sections permettent de diviser vos pages en parts sémantiques. Elles se différencient des balises div qui ont pour rôle principal la présentation. Une section est complétée par un header et un footer.
• Un nouvel attribut async pour les balises script, il permet d’exécuter un script indépendamment de l’affichage de la page. Ces scripts pourront s’activer à la demande selon la disponibilité de ressources.

HTML 5 vous propose donc de transformer vos pages web en application riche, ce nouveau balisage vous permet de tirer pleinement partie de contenu multimédia sans nécessiter de plugin extérieur.

Google Wave, la grosse annonce de la conférence

Sans conteste la grosse annonce de Google durant ces 2 jours, Google a annoncé la sortie prochaine de Google Wave. Il s’agit d’un nouvel outil Open Source de communication et de collaboration, initié à l’origine par les deux frères Rasmussen, déjà à l’origine de Google Maps. Leur point de départ, à quoi les emails ressembleraient s’ils avaient été inventés aujourd’hui ? Après nous avoir parlé d’HTML 5 et d’applications riches, Google dévoile comment ils comptent tirer parti de ces nouveautés. A la vue du résultat, difficile de croire que l’application fonctionne sur un simple navigateur. Je vous encourage vivement de regarder la démonstration, le moins que l’on puisse dire est qu’elle donne envie d’essayer le produit. Pour ma part, même si j’avoue bien volontiers avoir été moins époustouflé qu’à la sortie de Google Earth il y a quelques années, il faut bien admettre qu’une fois encore Google est moteur d’innovations. Tout comme la sortie de Gmail, fort est à parier qu’une multitude de concurrents essayeront en vain d’égaler cette nouveauté. Et si une page était en train de se tourner dans le développement d’applications Web ?

Là où les emails permettaient un échange point à point, Google Wave centralise et met à disposition le contenu. On n’envoie pas une Wave, on y participe. L’historique des modifications des conversations (texte, média, widget) est stocké sur un serveur. Ainsi, tout nouveau participant pourra rejouer intégralement celle-ci.

Google Wave est un mixte entre email, messagerie instantanée, réseaux sociaux, partages de documents. Il se base sur un protocole spécialement créé pour l’occasion. Celui-ci permet la transmission d’incréments de données et permet, entre autres, l’affichage caractère par caractère d’une conversation au fur et à mesure de la rédaction par son auteur.

Bien plus qu’une application, Google Wave est également contrôlable via une API spécifique. Vous pourrez donc y utiliser ces services à votre guise pour modeler vos propres solutions. Du coup, fort est à parier que Google Wave sera également disponible sous la forme de widget à utiliser sur vos blogs, sites web …

Pour plus d’information sur le sujet, vous pouvez consulter cette page sur laquelle l’auteur à centralisé les informations, définitions et fonctionnalités de Google Wave.

GWT, au cœur de la stratégie Google ?

L’autre grosse surprise avec l’arrivée de Google Wave, l’utilisation de GWT à grande échelle dans un produit Google !

Jusqu’ici, il était drôle de constater que si GWT avait bien été créé intégralement en interne chez Google, au final, aucun produit phare n’utilisait cette technologie. Et bien, ceci sera bientôt du passé ! Non seulement le client Wave a été écrit en GWT, mais Google continue à investir beaucoup sur cette technologie. Certes GWT à tout de même dû subir pour l’occasion quelques modifications, mais force est de constater que GWT semble plus que jamais au centre de la stratégie Google. GWT permettra également la création d’applications pour Android et iPhone. C’est comme si Google voulait nous faire oublier nos applications locales/desktop aux bénéfices d’applications légères/riches.

Google I/O, c’est également l’annonce de la sortie de Gwt Query : un clone de jQuery pour GWT. Cette nouvelle Api permet d’ajouter du comportement côté client sans rencontrer les lourdeurs des Widgets. À ce stage GWT Query reprend 98% des fonctionnalités de jQuery.

Android 2.0 Donut, recherches et filtres

A l’heure où les premiers téléphones Android arrivent tout juste en France, Google a annoncé la création de la branche 2.0, appelée Donut. Sortie prévue : fin 2009.

Comme le communiquent certains, 2009 sera probablement l’année d’Android. Si à ce jour seuls deux mobiles sous ce système sont timidement sortis en France, Google attend la sortie d’une vingtaine d’appareils (pour une dizaine de fabriquants) en 2009.

Google I/O a donc été l’occasion de faire un point sur la roadmap de cette nouvelle version, celle-ci est prévue pour fin 2009 :

• Recherche globale : un champ de recherche commun pour le web, la musique, les contacts… C’est en effet, l’un des défauts de la version actuelle, le market nous encourage à installer toujours plus d’applications, il s’avère pour le moment peu pratique de retrouver celle que l’on cherche. J’avais d’ailleurs l’idée de développer une application ‘launcher’, je vais donc pouvoir nettoyer ma todo-list. Cette recherche globale vous permet donc d’effectuer des recherches aussi bien en local sur votre téléphone qu’en connecté sur le web. Démonstration de la fonctionnalité après la 3e minute de cette vidéo.
• Contrôle par la voix : Android 1.5 (Cupcake) a introduit les embryons de Google Voice Search, vous permettant de lancer des recherches Google par la voix. Donut va davantage utiliser cette fonctionnalité qui vous permettra aussi bien d’appeler un contact que de contrôler vos applications à la voix. Ces fonctionnalités seront intégrées aux applications Google, mais pas seulement. Vous pourrez les utiliser dans vos applications via la nouvelle API. Révolutionnaire ? par forcément, j’ai utilisé cette fonctionnalité pour la première fois sur Pocket PC il y a 3 ans avec Microsoft Voice Command.
• Synthèse vocale : vous contrôlez votre téléphone par la voix, celui-ci sait également vous parler. Donut offrira également des fonctionnalités de text2speach multi-langues, la présentation à été portée par une application de traduction plutôt réussie.
• Contrôle par le geste : votre téléphone sera capable également de reconnaître via l’écran tactile des formes complexes. Cela vous permettra entre autres de filtrer une liste de contacts en dessinant la première lettre du nom recherché.

Pour clôturer ce sujet, notez l’ouverture d’un nouveau concours mondial de programmation sur Android : Android Developper Challenge 2 avec de belles récompenses à la clé.

Java sur Google App Engine, ouvert à tous

Bien qu’aucune annonce n’ait encore été faire sur le blog officiel, il semblerait que Google ait annoncé officiellement le support Java sur Google App Engine, ce qui veut dire : ouvert à tous. En effet, en avril dernier, Google avait déjà pré-ouvert sa plateforme aux langages Java et Groovy aux 10 000 premiers inscrits.

Google Web Elements, widgets pour vos sites internet

Google Web Elements vous permet d’utiliser les services Google sous la forme de widgets sur vos blogs ou sites web. Ces widgets nous permettront par exemple d’afficher facilement nos présentations PowerPoint sur le blog, les sites du type Slideshare doivent grincer des dents…

Le fonctionnement est très simple :

• Rendez-vous sur le site de Google Web Elements pour choisir votre type de Widget.
• Configurez-le en ligne via un simple formulaire permettant de générer le code HTML et JavaScript représentant le widget.
• Copier-collez le code sur votre site ou blog.

Huit applications sont disponibles pour le moment: Calendar, Presentation, Conversation, Custom Search, Maps, News, Spreadsheets et Youtube News.

Google Apps Script, scriptez vos Google Documents

Google IO c’est du grand spectacle, comme nous l’avons vu durant les keynotes, mais aussi des annonces plus terre-à-terre : Google Apps Script en est un bon exemple. Avec cette fonctionnalité, il vous sera donc possible prochainement d’ajouter des fonctionnalités de scripting dans vos documents. Le développement de ces ‘macros’ s’effectuera entièrement en JavaScript à partir d’un éditeur intégré aux différentes applications Google Document. Je vous invite à consulter une vidéo de démonstration durant laquelle le présentateur effectue une macro d’envoi d’email.

Chrome, arrivée des extensions

Comme certains le savent déjà, Chrome, le navigateur internet made in Google, proposera prochainement un système de gestion d’extensions. Il vous est d’ailleurs déjà possible de commencer à écrire vos propres extensions en utilisant le dernier build developper, je m’y suis d’ailleurs essayé comme vous avez pu le lire sur mon twitter. Si cela vous intéresse, jetez un coup d’œil au howto vous permettant de créer votre premier plugin en 30 secondes chrono.

Les extensions sont des archives ZIP contenant du HTML, des CSS et du JavaScript. Chaque partie d’UI d’une extension se présente sous la forme d’une simple page internet. Du coup, vous utilisez les mêmes outils, même debugger, mêmes librairies JavaScript et les mêmes techniques de programmation que pour créer vos pages web. Google a particulièrement bien travaillé son API pour la rendre aussi simple que possible.

Chrome dispose depuis sa première version d’une gestion des processus bien ficelée : chaque onglet dispose de son propre processus rendant de ce fait difficile de planter le navigateur à cause d’une des pages web. Les extensions fonctionneront sur un principe similaire et disposeront donc également de leur propre processus.

Les extensions seront distribuées sous la forme de fichier CRX composé de :

• Une signature, pour éviter les attaques du type Man In The Middle.
• Un manifeste, contenant les informations générales (nom, version …).
• Un fichier zip avec le contenu.

Tiens tiens, cela n’est pas sans nous rappeler le packaging des applications Android…

Heureusement, il est possible d’écrire votre validateur : il suffit de coder une classe ActionScript qui hérite de mx.validators.Validator et de surcharger la méthode doValidation(). Voici notre validateur permettant de contrôler qu’une suite de chiffres doit être comprise entre une longueur minimale et une longueur maximale.

Ecriture du validateur

CustomNumberValidator.as

package validation
{
    import mx.validators.NumberValidator;
    import mx.validators.ValidationResult;
    public class CustomNumberValidator extends NumberValidator {
          public var minLength:Number;
          public var maxLength:Number;
	  public var lengthFieldError:String;
	  public function CustomNumberValidator() {
		super();
	  }
	  override protected function doValidation(value:Object):Array {
          	var results:Array = super.doValidation(value);
		var val:String = value ? String(value) : "";
		// value has to be between minLength and maxLength
		if ((val.length >= minLength && val.length <= maxLength) || ((val.length == 0) && !required)) {
			return results;
		} else {
			return checkForLength(value);
		}
    	   }
	   public function checkForLength(value:Object):Array {
		var results:Array = [];
		results.push(new ValidationResult(
				 true, null, "invalidChar",
				 lengthFieldError));
		return results;
	   }
    }
}

Tout d’abord, nous définissons des variables:

public var minLength:Number; //la longueur minimale de la suite de chiffres
public var maxLength:Number; //la longueur maximale de la suite de chiffres
public var lengthFieldError:String; //message d'erreur si la longueur n'est pas comprise entre minLength et maxLength

Ces 3 variables sont paramétrables lors de la définition du Validator dans le fichier MXML que nous verrons plus loin.

Comme vous pouvez le voir, dans la méthode doValidation() nous récupérons une chaîne (la suite de chiffres), et nous testons si cette dernière est bien comprise entre minLength et maxLength. Si la validation se passe mal, la méthode retournera un tableau de ValidationResult avec le message d’erreur que nous avons défini (lengthFieldError), sinon elle renverra un tableau vide.

Voici le fichier MXML utilisant ce Validator:

XebiaValidator1.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
                xmlns:validation="validation.*"
                layout="absolute"
                width="520" height="242">
    <mx:StringValidator id="userNameValidator"
		        source="{userName}"
		        property="text"
		        requiredFieldError="User Name can not be empty !"/>
    <validation:CustomNumberValidator id="commandValidator"
        source="{commandeId}"
        property="text"
        minLength="4"
        maxLength="20"
        domain="int"
        required="true"
        lengthFieldError="Number command has to be between 4 and 20 digits"/>
    <mx:Panel title="Command management" x="86" y="31">
    	   <mx:Form defaultButton="{valideButton}" verticalGap="20">
    	        <mx:FormItem label="User Name">
    	            <mx:TextInput id="userName" styleName="textLogin" width="172"/>
    	        </mx:FormItem>
    	        <mx:FormItem label="Command Number">
    	            <mx:TextInput id="commandeId" width="172"/>
    	        </mx:FormItem>
    	        <mx:FormItem horizontalAlign="right" width="100%">
    	            <mx:Button id="valideButton" label="Validate"/>
    	        </mx:FormItem>
    	    </mx:Form>
    </mx:Panel>
</mx:Application>

Le résultat:

Dans cet exemple, nous utilisons 2 validateurs (StringValidator et CustomNumberValidator). Au passage, afin d’utiliser notre validateur nous avons défini un namespace (xmlns:validation="validation.*")
En ce qui concerne notre validateur, nous retrouvons nos attributs (minLength, maxLength et lengthFieldError) que nous avons renseignés.

Amélioration de la validation

Améliorons notre processus de validation. En effet, pour le moment nous avons les messages d’erreurs lors du remplissage des champs du formulaire (un Tooltip s’affiche en cas d’erreur). Nous allons faire en sorte d’avoir également ces messages lors du click sur le bouton « Validate ».

XebiaValidator2.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
                xmlns:validation="validation.*"
                layout="absolute"
                width="520" height="242"
                initialize="this.fillValidators()">
    <mx:Script>
        <![CDATA[
            import mx.events.ValidationResultEvent;
            import mx.controls.Alert;
            import mx.core.Application;
            import mx.validators.Validator;
            public var validatorsList:Array;
            public function fillValidators() : void {
                this.validatorsList = new Array();
                this.validatorsList.push(
                userNameValidator,
                commandValidator);
            }
           public function validateForm():void {
            	var validationErrors:Array = Validator.validateAll(this.validatorsList);
                var isValidForm:Boolean = (validationErrors.length == 0);
                if (isValidForm) {
                    Alert.show("Validation OK");
                } else {
                	this.onValidationErrors(validationErrors);
                }
            }
            public function onValidationErrors(errors:Array):void  {
            	var error:ValidationResultEvent;
                var messages:Array = [];
                for each (error in errors) {
                    messages.push(error.message);
                }
                Alert.show(messages.join("n"),
                		   "ERROR",
                		   Alert.OK);
            }
        ]]>
    </mx:Script>
    <mx:StringValidator id="userNameValidator"
		        source="{userName}"
		        property="text"
		        requiredFieldError="User Name can not be empty !"/>
    <validation:CustomNumberValidator id="commandValidator"
        source="{commandeId}"
        property="text"
        minLength="4"
        maxLength="20"
        domain="int"
        required="true"
        lengthFieldError="Number command has to be between 4 and 20 digits"/>
    <mx:Panel title="Command management" x="86" y="31">
    	   <mx:Form defaultButton="{valideButton}" verticalGap="20">
    	        <mx:FormItem label="User Name">
    	            <mx:TextInput id="userName" styleName="textLogin" width="172"/>
    	        </mx:FormItem>
    	        <mx:FormItem label="Command Number">
    	            <mx:TextInput id="commandeId" width="172"/>
    	        </mx:FormItem>
    	        <mx:FormItem horizontalAlign="right" width="100%">
    	            <mx:Button id="valideButton" label="Validate" click="this.validateForm()"/>
    	        </mx:FormItem>
    	    </mx:Form>
    </mx:Panel>
</mx:Application>

Le résultat:

Dans ce fichier, du code ActionScript a fait son apparition. Dans un premier temps la méthode fillValidators(), appelée lors de l’initialisation du composant, remplit une liste composée des validateurs référencés par leurs id.

Par la suite, lors du clic sur « Validate », la méthode validateForm() est appelée. La classe Validator possède une méthode très pratique qui est validateAll(), prenant en paramètre une liste de validateurs. Cette méthode renvoie un tableau vide si la validation a réussi, et sinon il y aura des éléments de type ValidationResultEvent contenant le message que nous affichons. Dans notre exemple, en cas d’erreurs les messages apparaîtront dans une popup.

A travers ces deux exemples, nous voyons que le mécanisme de validation de Flex est assez simple, et écrire ses propres validateurs devient un jeu d’enfant !

Vous pouvez télécharger les sources sur le SVN de Xebia France.

flex.messaging.LocalizedException: The FlexSession is invalid.
    at flex.messaging.FlexSession.checkValid(FlexSession.java:906)
    at flex.messaging.FlexSession.getUserPrincipal(FlexSession.java:225)
    at flex.messaging.HttpFlexSession.getUserPrincipal(HttpFlexSession.java:272)
    at flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:327)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1097)
    at com.wavecom.ui.util.AddToMDCFilter.doFilter(AddToMDCFilter.java:68)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
    at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)

En se tournant vers la documentation de BlazeDS, nous voyons que celui-ci n’est pas capable d’invalider lui-même des sessions HTTP. Il est cependant possible d’utiliser un paramètre dans les propriétés des channels afin d’invalider une session:

<invalidate-session-on-disconnect>true</invalidate-session-on-disconnect>

Mais malgré cette option l’erreur restait présente… étrange.

Après quelques recherches plus poussées (merci Google), je suis tombé sur les problèmes liés aux Session Fixation et sur cet article.
En effet, en creusant un peu plus, nous voyons dans la documentation de configuration de Spring :

« Session fixation attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example). »

Afin de contrer cela, Spring a pris le parti de créer une nouvelle session à chaque authentification d’un utilisateur.
Nous pouvons ainsi comprendre le problème. En effet, nous utilisons un channel HTTP et une instance de la classe HttpFlexSession (flex.messaging.HttpFlexSession) contenant des attributs dont une Map de flexSession. Cette Map contient les id de session des utilisateurs. A la première connexion, cette instance récupère une requête avec un id session qui sera placé dans cette Map. Et lors de la deuxième connexion, la requête contiendra un autre id session. Le problème est que l'instance de HttpFlexSession va rechercher l'id session de la deuxième connexion dans la Map mais ne la trouvera pas, d'où l'exception citée ci-dessus.

Néanmoins, il existe une solution : mettre le paramètre session-fixation-protection à none dans votre fichier de configuration Spring

<security:http auto-config="true" access-denied-page="/" session-fixation-protection="none">

Avec cette solution, la session ne sera pas systématiquement recréée et l'exception ne sera plus présente ! En espérant que cette solution puisse aider d'autres personnes !

Évolutions du langage

Petit rappel : la toute première version de GWT (1.0) est sortie le 17 mai 2006. Oui, il y a seulement 2 ans et demi ! De nombreuses versions se sont suivies pour arriver à une version 1.4 (fin août 2007) stable et très complète, permettant de démarrer sereinement nos projets.
Mais voilà, fin août 2008 (1 an plus tard, la plus longue période entre 2 releases), la communauté GWT était en ébullition : en effet, l’importante version 1.5 pointa son nez apportant un lot de nouveautés assez importantes.
De nombreux articles nous exposent parfaitement ces nouveautés du langage ; on pourra se diriger sur le Blog de GWT, sur InfoQ ou chez Octo.
Un rapide résumé donnerait :

1. Enfin du Java en version 5 : annotations, generics, enhanced loop, autoboxing, import static…
2. Generics ? Donc nos @gwt.typeArgs sont terminés !
3. JRE Emulation beaucoup plus large avec entre autres les très attendues TreeMap, LinkedHashMap et autres StringBuilder
4. Compilateur beaucoup plus rapide
5. Widgets plus complets et plus rapides

En bref : que du bon !

Plug-ins

GWT Designer

Plugin de type WYSIWYG. Il permet entre autres :

• la création de projet GWT, de module, de service et de librairie,
• génération du service Async ,
• la palette de widgets (intégrée dans une vue multi-onglets Design et Source),
• ajout d’événements et modification des propriétés d’un composant dans les onglets Event et Properties,
• Compilateur et Hosted Mode intégrés au projet (Builder Eclipse, menu « Run As… »),
• drag and drop côté Design qui met automatiquement le « Source » à jour.

À noter qu’il faudra, au-delà de la période d’essai, une licence annuelle ou perpétuelle pour continuer à l’utiliser.

VistaFei

Environnement de développement (qui s’appuie sur Eclipse 3.2) intégrant toute sorte de plugins spécialement conçus pour GWT. Il propose :

• la création de projet, de module (GWTView) et de service,
• un WYSIWYG (très similaire à celui de GWT Designer) séparant l’onglet « Properties » de la vue « Design »,
• la génération de code depuis la « GWTView »,
• l’internationalisation aussi générée.

Son utilisation est gratuite avec la licence « Community Edition ».

IntelliJ IDEA

Un plugin GWT intégré à l’IDE très abouti :

• création de projet, de module et de service,
• compilateur de projet,
• complétion Javascript dans une méthode native (non, vous ne rêvez pas !!!),
• quick-fix spécifiques GWT (votre code Java est correct mais il ne compilera pas, oubli de l’interface « IsSerializable », utilisation d’une librairie non émulée…), remplacement des @gwt.typeArgs…,
• navigation rapide entre les méthodes synchrones et asynchrones.

Le plugin est intégré à l’IDE de JetBrains, il faudra donc mettre la main à la poche pour obtenir une licence à moins de vous lancer dans un projet Open Source.

Cypal Studio

Le plugin que tout développeur GWT anti-WYSIWYG a dans son IDE !

• création de module, de service et d’exemple (sample),
• compilateur intégré au projet (« builder » Eclipse),
• lancement du Hosted Mode.

Simple mais efficace, ce produit est disponible gratuitement.

Frameworks

GWT-Maven

De nombreuses commandes maven adaptées à GWT sont disponibles, on notera parmi les plus intéressantes :

• Lancement du Hosted Mode (Tomcat, noserver, debug…),
• Compilation GWT,
• Lancement des tests unitaires GWT,
• Génération des interfaces pour l’internationalisation,
• Création de WAR GWT,
• Création de JAR GWT.

Gilead (anciennement Hibernate4GWT)

L’un des gros problèmes rencontrés au démarrage de GWT est l’utilisation des POJOs Hibernate côté client.
Je vous renvoie vers le très bon article d’Amin Fathallah (Xebia) qui détaille très bien les problèmes rencontrés.
Ainsi, Gilead nous permet d’utiliser nos POJOs Hibernate directement côté client sans aucun mapping Dozer !

Spring

Accessible par les librairies GWT-SL et GWT-WL, il est tout à fait possible d’utiliser Spring dans un projet GWT.
Le principal changement est que les services ne sont plus définis en tant que servlets dans le web.xml. Ils sont remplacés par la classe DispatcherServlet de Spring qui pilotera l’application.
On notera aussi les classes GWTController et GWTHandler, cœur de GWT-SL, permettant de wrapper intégralement nos actions et nos services.

G4JSF

L’adaptation de JSF dans le monde GWT. Même mécanisme que pour le SpringController i.e. que l’on aura des interfaces/classes à implémenter/étendre au lieu des classes GWT standard, les principales étant ComponentEntryPoint et GwtFacesServiceAsync.
Le tutoriel de référence pour l’intégration de JSF avec GWT se trouve sur The Server Side.

APIs graphiques

Le tour d’horizon continue avec les APIs graphiques.
Chaque composant ne sera pas détaillé à outrance, seuls certains seront cités pour donner un aperçu général de ce qui est proposé (détail complet sur les sites officiels respectifs de chaque librairie).

Widgets Core (démo)

Premier réflexe avec tout ce que l’on entend sur GWT : foncer sur la première librairie de composants graphiques à la mode !
Mais n’oublions pas toutefois que GWT propose en standard des widgets haut niveau très complets :

• Boutons : basique, checkbox, radio, custom…,
• Listes : basique, suggest, arbre, menu…,
• Text : basique et riche (à la word),
• Popups,
• Panels : décorateur, horizontal, vertical, dock, disclosure, onglet…,
• Tables : tableau standard et flex.

GWT-Ext (démo)

Certainement la librairie graphique la plus répandue.
Wrapping complet de l’API ExtJS dans sa version 2.0.2.
L’API ne contient donc quasiment que des classes dont les méthodes font une redirection native vers le code Javascript d’ExtJS.
On retrouvera donc tout ce qui se fait dans ExtJS avec des composants très puissants comme :

• Arbres : éditable, drag & drop (arbre vers arbre ou tableau), tri, checkbox…,
• Layouts : horizontal, vertical, accordéon…,
• Liste : basique, listes liées, live (suggest), paginé…,
• Tableau : éditable, tableaux groupés, JSON ou XML, chargement local ou distant, checkbox…,
• Formulaire : à onglets, fieldset, multi-colonnes, binding avec un tableau…,
• Éléments redimensionnables, déplaçables…
• Widgets bien stylés et des thèmes out-of-the-box

Le point noir reste toutefois la Javadoc, même si celle-ci s’étoffe au fur et à mesure des sorties de GWT-Ext (gros efforts fournis entre les versions 2.0.2 et 2.0.5). Elle reste cependant insuffisante. On pourra tout de même se retourner sur la doc d’ExtJS (puisque ce n’est que du pur wrapping) mais dès que l’on souhaitera aller un peu plus loin avec les composants, il faudra mettre les mains dans le cambouis Javascript.

Ext-GWT (démo)

Le produit de la compagnie ExtJS adapté à GWT.
Ext-GWT prend le parti de tout réécrire en pur GWT i.e. il n’y a aucun Javascript externe, tout est en Java.
Autre atout, l’API utilise les mécanismes internes de GWT permettant une intégration standard des fonctionnalités comme le remote service en Callback, retour JSON, XML… mais aussi du Java 5 (generics, enums et varargs).
On retrouve, sans surprise, les mêmes composants que pour GWT-Ext.
A noter enfin 3 licences disponibles pour le produit (commercial, open source ou revendeur).

Smart-GWT (démo)

Sanjiv Jivan a encore frappé !
Après son wrapping complet d’ExtJS avec GWT-Ext, il s’attaque cette fois-ci à la librairie SmartClient avec sa nouvelle API SmartGWT (nous vous en parlions dans une précédente revue de presse).
Le wrapping est encore une fois très complet : tous les composants de SmartClient sont présents dont :

• Arbre : colonne bloquée, drag & drop entre de nombreux composants, data binding multiples…,
• Slider, effects, animations, dialogs, look & feel, …
• Tableau : filtres, interactions avancées, …
• Tile (démo),
• Liste-Tableau, Calendrier (à la outlook), load on demand, …

On retrouvera aussi, et sans surprise, la plupart des composants combobox, radio, field, … d’autres librairie du même type.

Rialto-GWT (démo)

De même que pour Ext-GWT, Rialto-GWT dans sa version 2.0 nous propose d’utiliser GWT 1.5 donc Java 5.
L’API utilise aussi les mécanismes internes à GWT, le Wrapping Javascript est présent mais l’abstraction avec les classes Java rend l’utilisation très simple.
A noter toutefois une Javadoc de composants peu fournie…
Les composants principaux sont proches de ceux d’Ext-GWT.

Tatami (Dojo) (démo)

Encore une célèbre librairie Javascript porté en GWT : Dojo !
Une fois de plus, on retrouve le support de GWT 1.5, des tableaux en tout genre, des sliders, des pickers…

Autres…

D’autres librairies/codes sont disponibles sur la plupart des sites d’informations GWT, on trouvera ainsi quelques wrapper Script.aculo.us (ici ou là) mais aussi des wrapper jQuery (avec entre autre GQuery).

APIs générales

I18N

GWT gère nativement l’internationalisation, donc pas de librairies externes pour cette fonctionnalité.
L’utilisation est simple :

• un fichier properties contenant toutes nos clés,
• des interfaces (I18NConstants, I18NMessages…) Java permettant de faire appel à ces clés,
• une entrée dans notre module.gwt.xml avec si besoin la locale par défaut,
• une locale pouvant être définie au runtime, dans la JSP ou dans l’URL.

Logs (demo)

Un logger côté client très complet avec différents niveaux de logs : info, warn, debug, error et fatal.
De nombreux loggers sont disponibles comme le ConsoleLogger, le GWTLogger ou bien encore le FireBugLogger.

Google API

Gears, gadgets, Ajax Search et Maps, voici ce que propose la librairie de Google.
À noter que Visualization est en release candidate.

Maths

Émulation de BigInteger et BigDecimal avec un grand nombre de méthodes (add, subtract, multiply, divide, abs, negate, compareTo, equals, toString…).

Et bien d’autres encore !

A chercher/récupérer au besoin

On pourra rapidement citer GWTEventService (qui permet entre autre de faire du pushing / comet), PureMVC (MVC pour GWT) ou bien encore Goda-Time (Joda-Time pour GWT !).

Conclusion

Ce petit tour d’horizon de la galaxie GWT nous permet de retenir 3 choses : vous avez dit galaxie ?, [Mode gros doutes] Tu penses que c’est possible ? et enfin ça ressemble vraiment à un puzzle cette techno….

Galaxie ? On peut se poser la question dans le sens où, si l’on creuse un peu, on trouve en effet quelques APIs très bien faites… mais elles sont tout de même rares ! Après plus de 2 ans d’existence, on a tout de même l’impression que cette techno se cherche encore et que, du coup, la communauté J2EE n’a pas encore confiance en GWT pour démarrer ses projets. Ce manque d’API robuste ne fera que renforcer cette tendance.

Est-ce possible ? Réponse : Google est ton ami Très peu de sites (comme par exemple onGWT) référencent ce qui se fait en GWT au niveau des outils, des frameworks… Il devient assez laborieux de trouver une API pour un besoin spécifique. N’oublions pas que GWT émule les packages java.util, java.lang et java.io. Suffisant pour certains projets, mais pour de grosses applications de gestion il en faudra d’autres…

Un puzzle ! C’est certainement ce qui ressort le plus des projets GWT. Les librairies se récupèrent à droite, à gauche sur Google, il y en a partout avec peu de référencement… GWT devrait peut-être intégrer directement des APIs reconnues qui ont fait leurs preuves (comme par exemple Java 7 avec Joda-Time)…

Autrement dit, et c’est aussi une des conclusions de GWT in Action, GWT permet de développer très facilement des applications Ajax sans forcément connaitre Javascript (tout en laissant la possibilité de coder directement en Javascript). Il y a bien sûr encore des choses à revoir/améliorer mais le langage est en très bonne voie et les librairies existantes font le travail demandé.

Cependant, devez-vous foncer tête baissée sur GWT car vous démarrez un nouveau projet Web / Ajax et vous ne savez pas quelle technologie choisir (GWT, Flex, Silverlight, JavaFX…) ? Impossible de répondre de manière générale pour tous les projets, cela dépend du back-end existant, des besoins du projet, du temps imparti… Sachez en tout cas que GWT est un excellent compromis entre Ajax, Java et Javascript et que personnellement, sur les projets auxquels j’ai participé, je ne regrette absolument pas son utilisation !

Une solution existe, utiliser les tags Metadata et plus précisemment le tag Event. Dans l’exemple du billet précédent, nous avons créé plusieurs composants pour mettre en place un formulaire. Nous allons effectuer le même exercice, avec une liste de contacts dans laquelle il est possible d’ajouter des utilisateurs. Nous verrons comment deux composants indépendants l’un de l’autre pourront communiquer et échanger des données.

Ce billet se découpe de la façon suivante :

• Nous commencerons par mettre en place les composants réutilisables qui formeront l’application
• Nous expliquerons ce qu’est un tag Metadata
• Nous présenterons comment les mettre en place sur notre exemple
• Et enfin, nous verrons le résultat

Mise en place des composants réutilisables

Pour créer notre application, nous allons mettre en place :

• ContactListView : une liste de contacts contenant une Datagrid et un bouton Ajouter

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml"
	width="400" height="300"
	horizontalAlign="center">
	<mx: DataGrid width="100%" height="100%" dataProvider="{contacts}">
		<mx:columns>
			<mx: DataGridColumn headerText="Nom et prénoms"/>
		</mx:columns>
	</mx: DataGrid>
	<mx:Button label="Ajouter"/>
</mx:VBox>

• ContactFormView : un formulaire contenant un champ texte nom, un autre prénom et deux boutons Valider et Annuler

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300">
	<mx:Form width="100%" height="100%">
		<mx:FormItem label="Nom" width="100%">
			<mx:TextInput width="100%" id="lastName"/>
		</mx:FormItem>
		<mx:FormItem label="Prénom" width="100%">
			<mx:TextInput width="100%" id="firstName"/>
		</mx:FormItem>
		<mx:FormItem width="100%">
			<mx:HBox width="100%" horizontalAlign="right">
				<mx:Button label="Valider"/>
				<mx:Button label="Annuler"/>
			</mx:HBox>
		</mx:FormItem>
	</mx:Form>
</mx:VBox>

Ils seront stockés dans une pile de vues ({{ViewStack}}). Le composant ViewStack contient des vues filles dans lesquelles il est possible de naviguer. Seule une vue fille peut être affichée à la fois grâce à la propriété selectedItem ou selectedIndex. En manipulant ce composant, nous allons tenter de passer d’une vue à l’autre en modifiant la valeur de selectedIndex.
- selectedIndex = 0 : le ViewStack affiche ContactListView
- selectedIndex = 1 : le ViewStack affiche ContactFormView

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:ViewStack id="viewStack">
		<view:ContactListView id="contactListView"/>
		<view:ContactFormView id="contactFormView"/>
	</mx:ViewStack>
</mx:Application>

Lorsque l’utilisateur clique sur le bouton Ajouter, l’application change de vue pour passer sur le formulaire. Les boutons Valider et Annuler quant à eux permettent de revenir sur la première vue.

La partie graphique est en place mais comment signaler à la pile de vue de passer de l’une à l’autre ? Effectivement depuis une vue, comment peut-on signaler à son parent qu’il s’est passé quelque chose ?

C’est là que les tags Metadata viennent à notre secours.

Qu’est ce qu’un tag Metadata ?

Un tag Metadata fournit au compilateur des informations sur la façon dont le composant MXML est utilisé dans une application Flex. Il existe 12 tags Metadata documentés dont entre autres Bindable, Embed, Effect et celui que nous allons utilisé Event. Le tag Event permet de définir des évènements que le composant concerné peut déclencher, ce qui convient très bien à notre problème.

Et concrètement ?

Côté déclencheur

Créons un tag Event dans notre vue ContactListView:

<mx:Metadata>
    [Event(name="addContact", type="flash.events.Event")]
</mx:Metadata>

Lorsque l’utilisateur clique sur le bouton Ajouter, le composant déclenche l’évènement addContact.

<mx:Script>
	<![CDATA[
        import mx.collections.ArrayCollection;
	[Bindable]
	private var contacts:ArrayCollection;
        private function onClick():void{
	        // on dispatche un nouvel évènement
	        // qui sera intercepté ici par le composant parent
	        dispatchEvent(new Event("addContact"));
        }
	]]>
</mx:Script>
<mx: DataGrid width="100%" height="100%" dataProvider="{contacts}">
	<mx:columns>
		<mx: DataGridColumn headerText="Nom et prénoms"/>
	</mx:columns>
</mx: DataGrid>
<mx:Button label="Ajouter" click="onClick()"/>

Côté abonné

Le parent de la vue, qui est ici l’application, ajoute un listener sur la vue pour attendre l’évènement addContact. Une fois l’évènement déclenché, nous changeons de vue.

<mx:Script>
	<![CDATA[
		import mx.collections.ArrayCollection;
		private function onAddContact(event:Event):void{
			// passage de la vue contenant la liste de contacts
			// à la vue d'ajout de contacts.
			viewStack.selectedIndex = 1;
		}
        ]]>
</mx:Script>
<mx:ViewStack id="viewStack">
	<view:ContactListView id="contactListView" addContact="onAddContact(event)"/>
	<view:ContactFormView id="contactFormView"/>
</mx:ViewStack>

Résultat

En faisant de même avec les boutons Valider et Annuler, nous arrivons au résultat suivant:

Ce billet présente un exemple très simple d’utilisation du tag Event avec un évènement de type flash.events.Event. Mais vous pouvez créer vos propres classes d’évènements comme le montre le livedocs. Le code source est disponible ici, vous trouverez l’exemple complet avec la gestion de l’ajout d’un contact et le retour vers la liste.

Références

http://livedocs.adobe.com/flex/3/html/help.html?content=metadata_2.html

Jeu de données

<mx:ArrayCollection id="countries">
        <mx:Object label="Germany" data="0"/>
	<mx:Object label="England" data="1"/>
	<mx:Object label="Spain" data="2"/>
	<mx:Object label="United States" data="3"/>
	<mx:Object label="France" data="4"/>
	<mx:Object label="India" data="5"/>
	<mx:Object label="Netherlands" data="6"/>
</mx:ArrayCollection>
<mx:Array id="roles">
      <mx:Object label="Administrator"/>
      <mx:Object label="Gold Customer"/>
      <mx:Object label="Read only Customer"/>
      <mx:Object label="Editor Customer"/>
      <mx:Object label="Read only User"/>
      <mx:Object label="Admin User"/>
</mx:Array>

Nous créons deux listes (id='countries', id='roles') composées d’objets qui ont comme attribut label.

Formulaire

XebiaForm1.mxml

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
		layout="absolute" width="522" height="338">
        <mx: Panel title="Gestion des utilisateurs">
	    <mx:Form>
		<mx:FormItem label="Login">
		     <mx:TextInput width="182" id="login"/>
		</mx:FormItem>
		<mx:FormItem label="Password">
		     <mx:TextInput width="182" id="password" displayAsPassword="true"/>
		</mx:FormItem>
		<mx:FormItem label="Country">
		     <mx:ComboBox id="country" dataProvider="{countries}" width="182"
		        	  prompt="Select a Country"
				  selectedIndex="-1"/>
		</mx:FormItem>
		<mx:FormItem>
		     <mx:HBox width="400" height="175">
			<mx:VBox width="50%">
			    <mx:Label text="Available Role"/>
                            <mx:List id="roleProvider" width="100%"
    				     dataProvider="{roles}"
 				     height="138"
				     allowMultipleSelection="true"
				     dragEnabled="true"
				     dropEnabled="true"
                                     dragMoveEnabled="true"/>
			</mx:VBox>
			<mx:VBox width="50%">
			    <mx:Label text="Selected Role"/>
			    <mx:List id="roleSelected" width="100%"
                                     height="138"
				     dropEnabled="true"
				     dragEnabled="true"
				     dragMoveEnabled="true"/>
			</mx:VBox>
		     </mx:HBox>
		</mx:FormItem>
	</mx:Form>
</mx: Panel>
</mx:Application>

Nous avons un composant Panel dans lequel se trouve un Form composé de FormItem. Ce formulaire possède :

• Un champ texte pour le login.
• Un champ texte pour le password.
• Une liste déroulante pour les pays.
• Deux listes : la première propose les permissions, et la seconde accueille les permissions accordées à l’utilisateur.

En ce qui concerne les attributs des deux listes pour le drag and drop, vous trouverez les détails dans ce billet.

Le résultat :

Imaginons maintenant que nous ayons besoin de la liste des pays et des permissions dans d’autres écrans. Comment faire pour réutiliser ce même code ? Flex propose un mécanisme très simple afin de pouvoir « créer ses propres composants ».

Formulaire simplifié

Dans un premier temps, nous allons créer notre composant pour la liste déroulante :

ComboCountry.mxml

<mx:ComboBox xmlns:mx="http://www.adobe.com/2006/mxml" prompt="Select a Country" selectedIndex="-1">
	<mx:dataProvider>
		<mx:ArrayCollection>
			<mx:Object label="Germany" data="0"/>
			<mx:Object label="England" data="1"/>
			<mx:Object label="Spain" data="2"/>
			<mx:Object label="United States" data="3"/>
			<mx:Object label="France" data="4"/>
			<mx:Object label="India" data="5"/>
			<mx:Object label="Netherlands" data="6"/>
		</mx:ArrayCollection>
	</mx:dataProvider>
</mx:ComboBox>

Lorsque vous créez un composant, vous devez lui indiquer le namespace (ici le préfixe mx et comme nom http://www.adobe.com/2006/mxml). Vous remarquerez que la liste des pays est directement incluse dans le composant ComboBox grâce à la propriété dataProvider. Néanmoins, il est possible d’écrire ce composant de la manière suivante :

<mx:ComboBox xmlns:mx="http://www.adobe.com/2006/mxml" prompt="Select a Country" selectedIndex="-1"
             dataProvider="{countries}">
	<mx:ArrayCollection id="countries">
		<mx:Object label="Germany" data="0"/>
		<mx:Object label="England" data="1"/>
		<mx:Object label="Spain" data="2"/>
		<mx:Object label="United States" data="3"/>
		<mx:Object label="France" data="4"/>
		<mx:Object label="India" data="5"/>
		<mx:Object label="Netherlands" data="6"/>
	</mx:ArrayCollection>
</mx:ComboBox>

De la même manière que la liste déroulante, les deux listes permettant de « drag and droper » les permissions peuvent être externalisées dans un composant :

ListPerm.mxml

<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml" width="400"
 	 height="175">
	<mx:Array id="roles">
          <mx:Object label="Administrator"/>
          <mx:Object label="Gold Customer"/>
          <mx:Object label="Read only Customer"/>
          <mx:Object label="Editor Customer"/>
          <mx:Object label="Read only User"/>
          <mx:Object label="Admin User"/>
        </mx:Array>
 	<mx:VBox width="50%">
           <mx:Label text="Available Role"/>
           <mx:List id="roleProvider" dataProvider="{roles}" width="100%"
                    height="138"
                    allowMultipleSelection="true"
                    dragEnabled="true"
                    dropEnabled="true"
		    dragMoveEnabled="true"/>
        </mx:VBox>
        <mx:VBox width="50%">
            <mx:Label text="Selected Role"/>
            <mx:List id="roleSelected" width="100%" height="138"
                     dropEnabled="true"
                     dragEnabled="true"
		     dragMoveEnabled="true"/>
	</mx:VBox>
</mx:HBox>

Maintenant que ces deux composants ont été externalisés, nous pouvons les intégrer dans le formulaire :

XebiaForm2.mxml

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
		xmlns:myComponent="myComponents.*"
		layout="absolute" width="522" height="338">
	<mx: Panel title="Gestion des utilisateurs">
	   <mx:Form>
	        <mx:FormItem label="Login">
		   <mx:TextInput width="182" id="login"/>
		</mx:FormItem>
		<mx:FormItem label="Password">
		   <mx:TextInput width="182" id="password" displayAsPassword="true"/>
		</mx:FormItem>
		<mx:FormItem label="Country">
		    <myComponent:ComboCountry width="182" id="country"/>
		</mx:FormItem>
	        <mx:FormItem>
	            <myComponent:ListPerm id="listRoles"/>
		</mx:FormItem>
	    </mx:Form>
	</mx: Panel>
</mx:Application>

On remarquera que nous avons ajouté un namespace afin de pouvoir utiliser nos composants :

xmlns:myComponent="myComponents.*"

Cela signifie que nous pouvons utiliser nos deux composants se situant dans le package myComponents, et ayant comme préfixe myComponent :

<myComponent:ComboCountry width="182" id="country"/>
<myComponent:ListPerm id="listRoles"/>

Ainsi, pour utiliser nos composants nous déclarons le préfixe, ainsi que le nom de ce dernier (égal au nom_du_composant.mxml).

Le résultat :

À travers ce billet, nous avons pu voir que la création de composants Flex est vraiment très simple, permettant d’avoir un code plus clair, mieux structuré et d’avoir des composants réutilisables !

Vous pouvez télécharger les sources sur le SVN de Xebia France.

Références

• http://livedocs.adobe.com/flex/3/html/help.html?content=Part4_CreateComps_1.html

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 :

• Flex 3
• Silverlight 2.0 beta 2
• Google GWT 1.5
• Echo3
• JavaFX Preview SDK

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

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é.

Exadel Flamingo fournit un ensemble de scripts, basés sur Maven, visant à simplifier le démarrage de projets RIA. Ces scripts permettent de générer le code initial et redondant d’un projet.
La promesse est donc d’offrir la capacité de créer une application CRUD dotée d’une interface riche très rapidement et sans effort de développement.
(Nous ne discuterons pas ici de l’intérêt ou non de doter une application de type CRUD d’une interface riche …)

Les technologies couvertes aujourd’hui sont :

• Flex et JavaFX pour partie cliente,
• AMF et Hessian pour la communication,
• JBoss Seam et Spring pour la partie serveur.

Question de contexte et de goût, j’ai pour ma part porté mon attention sur le triplet Flex / AMF / Spring.

Même si certains aspects méritent des améliorations, la promesse est tenue. Bien que n’ayant jamais pratiqué Flex (ou presque), il ne m’a pas fallu longtemps pour monter mon CRUD Flex / Spring / Hibernate.
Ce billet présente le déroulé de mes premiers essais.

Installation de Flamingo et pré-requis

L’utilisation de flamingo requiert un poste de travail sur lequel sont installés et configurés :

• Maven 2
• Un JDK 1.5 ou supérieur
• Un SDK Flex

L’installation de flamingo est on ne peut plus simple :

• Décompression de l’archive flamingo-1.x.x.zip.
• Exécution du script flamingoinstall (ce script installe les librairies flamingo dans le repository maven local du poste de travail).
• Ajout du répertoire bin de flamingo dans le {{PATH}}

Création du projet

La création d’un projet à partir de flamingo en mode ligne de commande se fait tout bonnement par exécution de flamingo create project :

X:\XFR_Code\trunk\flex>flamingo create project
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [com.exadel.flamingo.maven.plugin:flamingoapp:1.6.0:create-project] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [flamingoapp:create-project]
discovered andromdapp type --> 'flamingo-spring'
discovered andromdapp type --> 'flamingo-seam'

Il suffit ensuite de répondre à une douzaine de questions afin de paramétrer le projet :

• Choix de la technologie serveur :

	Please choose the type of application to generate (flamingo-spring, flamingo-seam):[flamingo-spring]
	flamingo-spring
	

• Caractéristiques du projet :

	Please enter the location in which your new application will be created (i.e. c:/java/development):
	X:\XFR_Code\trunk\flex
	Enter the project name (e.g. myproject):
	flamingo-demo
	Please enter the root package name for your project (e.g. com.mydomain.myproject): [fr.xebia.demo.flamingo]
	fr.xebia.demo.flamingo
	

• Choix de la technologie cliente :

	Will this project have Flex or JavaFX user interface? (flex, javafx): [flex]
	flex
	

• Choix du protocole de communication :

	Will this project use Hessian or AMF protocol? (amf, hessian): [amf]
	amf
	

• Configuration de la base de données :

	What kind of database are you using? (hsql, mysql, oracle, postgres, mssql, db2, sybase, none): [hsql]
	hsql
	Enter the JDBC URL for your database (e.g. jdbc:hsqldb:.): [jdbc:hsqldb:.]
	jdbc:hsqldb:.
	Enter database username: [sa]
	sa
	Enter database password: []
	Do you want to update the database schema each time you deploy? (y, n): [y]
	y
	

• Nom de la première entité du projet :

	Enter the entity class name (Flex source files to view and modify entities will be generated as well): [Product]
	Product
	

Le projet est ensuite généré au format Maven :

-------------------------------------------------------------------------------------
    G e n e r a t i n g   A n d r o M D A   P o w e r e d   A p p l i c a t i o n
-------------------------------------------------------------------------------------
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flamingoproject.properties'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flex/pom.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flex/src/main/flex/fr/xebia/demo/flamingo/view/ProductManager.mxml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flex/src/main/flex/fr/xebia/demo/flamingo/vo/Product.as'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flex/src/main/flex/main.mxml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/flex/src/main/resources/services-config.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/pom.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/readme.txt'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/pom.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/Product.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/ProductDAO.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/ProductDAOImpl.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/service/ProductService.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/service/ILoginService.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/java/fr/xebia/demo/flamingo/service/LoginService.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/resources/applicationContext-test.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/resources/applicationContext.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/resources/hibernate.cfg.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/webapp/index.html'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/main/webapp/WEB-INF/web.xml'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/test/java/fr/xebia/demo/flamingo/dao/ProductDAOTest.java'
    Output: 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/web/src/test/java/fr/xebia/demo/flamingo/DataSourceTestCase.java'
-------------------------------------------------------------------------------------
    New application generated to --> 'file:/X:/XFR_Code/trunk/flex/flamingo-demo/'
-------------------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 42 seconds
[INFO] Finished at: Fri Aug 01 11:17:54 CEST 2008
[INFO] Final Memory: 9M/19M
[INFO] ------------------------------------------------------------------------

Compilation, Tests Unitaires et Packaging

Le projet étant généré au format Maven, un simple mvn clean package -Denv.FLEX_HOME=C:toolsflex_sdk_3 permet de compiler, lancer les tests unitaires et packager un war :

X:\XFR_Code\trunk\flex\flamingo-demo>mvn clean package -Denv.FLEX_HOME=C:\tools\flex_sdk_3

Première exécution

Souhaitant exécuter mes essais sous jetty depuis Maven, il m’a fallu :

• Ajouter le plugin jetty au projet web ({{flamingo-demo/web/pom.xml}}) :

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <dependencies>
        <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
            <version>1.1.1</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-jcl</artifactId>
            <version>1.4.3</version>
        </dependency>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.15</version>
        </dependency>
    </dependencies>
    <configuration>
        <stopPort>9181</stopPort>
        <stopKey>STOP</stopKey>
        <systemProperties>
            <systemProperty>
                <name>log4j.configuration</name>
                <value>file:./target/classes/log4j.xml</value>
            </systemProperty>
        </systemProperties>
    </configuration>
</plugin>

• Ajouter un fichier log4j.xml dans flamingo-demowebsrcmainresources
• Supprimer le scope test sur la dépendance à hsqldb ({{flamingo-demo/web/pom.xml}}) :

	<dependency>
        <groupId>hsqldb</groupId>
        <artifactId>hsqldb</artifactId>
        <version>1.8.0.7</version>
    </dependency>

J’ai également modifié le fichier flamingo-demo/flex/src/main/resources/services-config.xml afin que le canal AMF pointe au bon endroit (dans le cadre d’un projet, on veillera à templatiser).

<channels>
    <channel-definition id="spring-amf" class="mx.messaging.channels.AMFChannel">
        <endpoint
            uri="http://localhost:9081/flamingo-demo-web/flamingo/amf"
            class="flex.messaging.endpoints.AMFEndpoint"/>
    </channel-definition>
</channels>

Après installation du projet avec la commande mvn clean install -Denv.FLEX_HOME=C:toolsflex_sdk_3 (à la racine du projet parent), la commande mvn jetty:run-war -Djetty.port=9081 (dans le projet web) lance l’exécution du war packagé sous jetty :

	X:\XFR_Code\trunk\flex\flamingo-demo\web>mvn -Dmaven.test.skip=true jetty:run-war -Djetty.port=9081

L’application est alors accessible à l’url http://localhost:9081/flamingo-demo-web/. Elle démarre sur un écran de login assez inattendu avec le mot de passe en clair :

Une fois « authentifié », on accède à un écran présentant la liste des entités sous forme de tableau triable et aux fonctions de création modification suppression :

Modification de l’entité et regénération des écrans

Modifions maintenant notre entité Product pour y ajouter les attributs suivants (avec leurs accesseurs) :

private String description;
private Float price;
private Date avaibility;

La regénération des beans et des écrans passe par la commande flamingo create screen :

	X:\XFR_Code\trunk\flex\flamingo-demo>flamingo create screen
	X:\XFR_Code\trunk\flex\flamingo-demo>set MAVEN_OPTS=-Xmx1024m
	[INFO] Scanning for projects...
	[INFO] Reactor build order:
	[INFO]   flamingo-demo
	[INFO]   flamingo-demo Flex
	[INFO]   flamingo-demo Web
	[INFO] ----------------------------------------------------------------------------
	[INFO] Building flamingo-demo
	[INFO]    task-segment: [com.exadel.flamingo.maven.plugin:flamingoapp:1.6.0:create-screen] (aggregator-style)
	[INFO] ----------------------------------------------------------------------------
	[INFO] [flamingoapp:create-screen]
	File Product.as already exists. Do you want replace it? (yes, no, all):[all]
	all
	[INFO] all
	[INFO] Product is a root entity
	File ProductScreens.mxml already exists. Do you want replace it? (yes, no, all):[all]
	all
	[INFO] all
	Check if the services-config.xml file contains the following destinations:
	<destination id="Product" />
	[INFO] ------------------------------------------------------------------------
	[INFO] BUILD SUCCESSFUL
	[INFO] ------------------------------------------------------------------------
	[INFO] Total time: 22 seconds
	[INFO] Finished at: Tue Aug 05 09:16:42 CEST 2008
	[INFO] Final Memory: 8M/15M
	[INFO] ------------------------------------------------------------------------

Après réinstallation de l’application dans notre repository local et redémarrage de jetty, nous obtenons les écrans suivants :

L’ajout de nouvelles entités se fait tout aussi simplement. Les différentes entités sont alors présentées au travers d’onglets.

Pour conclure

Exadel Flamingo répond donc bien au besoin de génération du code initial et redondant d’un CRUD RIA. La création d’un CRUD Flex / Spring / Hibernate se fait sans heurt et sans que l’on ait trop à regarder sous le capot.

Quelques points restent cependant à améliorer (gageons qu’ils le seront rapidement), notamment la validation des données saisies : apparemment, aucune validation n’est faite sur le type des données. Si l’on saisit des données erronées pour des attributs de type numérique ou date, la soumission du formulaire est « acceptée » et ses attributs se voient affecter une valeur null.

Le résultat de ces premiers essais est disponible sur le SVN de Xebia France : http://code.google.com/p/xebia-france/source/browse/#svn/trunk/flex/flamingo-demo.