Le stockage local HTML5, pourquoi faire? Dans une optique de réduction des couts de maintenance, de déploiement, beaucoup d'entreprises ont fait le choix de migrer leurs applicatifs (comptables, commerciales, administratives, etc.) vers des applications web. Au début en simple XHTML/CSS puis très vite l'arrivée de JavaScript puis AJAX a permis de créer des interfaces dites «riches» avec une ergonomie importante et une grande rapidité d'utilisation (on peut le voir avec Gmail, la recherche instantanée sur Google.fr, etc.) Cependant le problème de la connectivité s'est posé au niveau de cette migration «full-web» : que se passe-t-il si l'utilisateur n'a plus internet : Il ne peut plus accéder à l'application? Prenons l'exemple concret d'un de nos clients : il a voulu mettre en place une application de suivi commercial pour ses commerciaux nomades. Jusque-là pas de problèmes, sauf qu'il s'est aperçu que comme ils n'avaient pas internet en sortant de rendez-vous, ils prenaient des notes sur papier et faisaient leurs comptes rendus le soir en rentrant. Résultat : près de 30% des saisies oubliées ou incomplètes. La solution est la capacité à faire du «stockage local», c'est-à-dire que le navigateur va être capable de garder l'information même après fermeture de la page, même après avoir été redémarré. Ceci, bien que ce soit une très bonne solution, doit être étudié en détails puisque faire le choix de rendre son application utilisable «offline» (hors-ligne) soulève d'autres problèmes importants : Gestion de la mise à jour des données sur le navigateur (il faut pouvoir les synchroniser avec le serveur) Gestion des conflits de données : que se passe-t-il si je modifie la fiche de client123 en mode offline et qu'avant la synchronisation un autre collègue modifie aussi client123 sur le serveur? Historique
HTML5 n'a pas inventé le stockage de données local, il est seulement la première possibilité que nous ayons pour avoir une solution standardisée de stockage de données au niveau du navigateur sans plugin tiers. La première solution a toujours été le stockage via cookies. En plus d'être fortement limités en taille (100KB), il faut savoir que toutes les données des cookies sont envoyées à chaque appel HTTP. Cela signifie qu'à chaque changement de pages, à chaque envoi de flux XML, votre navigateur envoi tous les cookies et le serveur lui renvoi lui aussi tous les cookies. Pas besoin de vous dire que ce n'est ni optimisé (taille, temps de traitement), ni vraiment sécurisé. Ensuite Flash (pionnier des RIA) a proposé une autre solution, les Flash Local Storage Objects. Limités à 100KB par domaine, ils fournissaient déjà une meilleure alternative aux cookies. Au vu du taux de pénétration de Flash sur les navigateurs (90-95%), la compatibilité n'était pas un problème. Par contre, l'obligation de plugin tiers ainsi que la limitation à 100KB était clairement un frein. Google lance donc en 2007 un projet appelé Google Gears, renommé ensuite Gears simplement pour effacer la patte Google de ce projet, et éviter que les craintifs de «big brother» n'utilisent pas le projet. Les avantages sont nombreux et le projet alléchant : OpenSource et gratuit Base de donnée SQL intégrée alors que nous avions simplement un système clé/valeur jusqu'à maintenant Aucunes limitations en lecture/écriture ou taille après acceptation du plugin par l'utilisateur Malheureusement, il a un défaut : ceci reste un plugin. Google a décidé, en 2009, avec l'arrivée de HTML5, de ne plus supporter Gears. Une autre complexité réside dans le fait qu'au niveau de nos applications, il faut être capable d'utiliser la meilleure technologie en fonction de ce qui est disponible sur le navigateur. C'est l'objectif du projet DOJOX. En effet, comme nous l'abordons dans les tutoriaux sur la vidéo en HTML5, l'idée ici est de s'adapter en fonction des capacités du navigateur. Le comportement de DOJOX est le suivant : Il utilise Gears s'il est installé Il utilise HTML5 si possible Il supporte Flash si les deux précédents ne sont pas supportés
Son utilisation n'est pas vraiment simple, donc pas vraiment à la portée de tous. Le stockage clé/valeur en HTML5 Commençons par une bonne nouvelle, le stockage clé/valeur HTML5 (keystore) est largement supporté par les navigateurs actuels. 8.0+ 3.5+ 4.0+ 4.0+ 10.5+ 2.0+ 2.0+ Le stockage HTML5 est entièrement stocké sur le navigateur, sans trace sur le serveur, les données ne sont pas envoyées au serveur à chaque appel (contrairement aux cookies), le support est natif au navigateur (sans installation de plugin tiers) et la limitation est fixée à 5 Mo par origine. Maintenant abordons nous à la notion de clé/valeur, qu'est-ce que cela signifie? De la même façon que pour les sessions en PHP ou en JAVA, les données sont stockées dans un tableau associatif ou dictionnaire. Schématisons par exemple ce que vous pourriez stocker sur le client pour un site e-commerce : Clé Valeur "utilisateur_id" "E13AEAZFEA3356GDZZRGRADSF REZA3" "panier" 43232 4535546 42322 343556 433212 "date_arrivee" "2011/05/03 03:24:03" "historique"
Vous remarquez plusieurs points ici : Tout d'abord qu'à une valeur correspond une clé mais qu'à une clé peut être liées plusieurs valeurs (le panier stocke les IDs des produits du panier) Tous les types sont supportés : entiers, réels, chaînes de caractères, dates Vous pouvez stocker des objets, à condition qu'ils aient été «JSONifiés». Nous y reviendrons. Première étape : vérifier la compatibilité Il faut commencer par s'assurer que le stockage clé/valeur de HTML5 est supporté par le navigateur de votre visiteur. Pour cela, plusieurs choix s'offrent à vous, nous vous en présenterons deux : Vérification manuelle dans les objets mis à disposition par le navigateur Vérification du support grâce à la libraire Modernizr Commençons en utilisant l'objet window qui contient l'attribut localstorage. S'il ne le contient pas ou s'il est null, c'est que nous avons un problème de compatibilité. function supports_html5_storage() { if ( ('localstorage' in window) && window['localstorage']!= null) alert("ok") ; else Puis utilisons la libraire Modernizr, un peu plus simple à utiliser :
function testlocalstorage(){ if (Modernizr.localstorage) { alert("ok"); Deuxième étape : stocker des informations Comme expliqué précédemment, le stockage de données clé/valeur en HTML5 se fait de la même manière qu'un tableau associatif (ou dictionnaire). Pour stocker une information, il suffit donc de : Choisir une clé S'assurer que stockage[«clé»] ne contient pas d'informations (sinon on écrase) Définir que stockage[«clé»] pointe vers notre information L'objet à utiliser pour manipuler le stockage de données clé/valeur est «localstorage». Affectons donc maintenant une valeur à une clé, si celle-ci est vide : function definissonsunevaleur(){ if (Modernizr.localstorage) { if (localstorage["macle"] == null){
localstorage["macle"] = "ok"; alert("storage[macle] vaut maintenant ok"); alert("storage[macle] a déjà une valeur: " + localstorage["macle"]); Comme vous pouvez le voir, les opérations de base sur les données sont simples. Reprenons les opérations CRUD pour le stockage local clé/valeur en HTML5 : Création de données : localstorage[«clé»] = valeur Mise à jour de données : localstorage[«clé»] = valeur Lecture de données : localstorage[«clé»] Suppression de données : localstorage[«clé»] = null ; Le stockage d'objets JavaScript en HTML5 Comment ferions-nous si nous voulions stocker un objet JavaScript en HTML5? localstorage[«clé»] = monobjetjavascript.
Ceci ne peut pas réellement marcher, pourquoi? Parce que le stockage de données côté client se fait par sérialisation, c'est-à-dire qu'il doit convertir l'information de l'objet dans une chaine de caractères stockée sur le disque dans un fichier. En bref, quand vous utiliserez un objet en JavaScript il faudra faire : Objet JavaScript => Chaine de caractères (String) => Objet JavaScript. Pour transformer un objet JavaScript en String, JavaScript nous fournit un standard de formalisation d'objets, le JSON (JavaScript Object Notation). Une représentation d'un objet d'une classe Societe ayant pour attributs id=1,nom=mistra,domaines=[«formation», «tutoriaux»] aurait pour représentation JSON : { «id» : «1», «nom» : «Mistra», «domaines» : Utilisons donc maintenant les méthodes permettant de créer une chaine de caractères depuis un objet avant de le stocker et inversement, récupérons un objet depuis une chaîne de caractères stockée sur le navigateur : function stockageobjetutilisateur(monobjet){ if (Modernizr.localstorage) { // Ici on écrase si l'utilisateur existe déjà // On utilise la méthode stringify qui créé une String à partir d'un objet localstorage["macle"] = JSON.stringify(monObjet);
function recupereobjetutilisateur(){ if (Modernizr.localstorage) { if (localstorage["macle"] == null){ alert("pas d'utilisateur stocké"); return null; else // On utilise la méthode parse qui créé un objet en fonction d'une String return JSON.parse(localStorage["macle"]); return null;
Powered by TCPDF (www.tcpdf.org) Le stockage local de données en HTML5 Vous savez maintenant comment stocker des informations en HTML5 grâce au système de clé/valeur. Cependant, comme sur un langage côté serveur, cette méthode peut devenir inutilisable sur des données que l'on veut plus structurées. HTML5 apporte là aussi une solution avec le système de stockage de données SQL intégré. Ce sera le sujet de notre prochain tutoriel, suivez-nous sur Facebook ou Twitter pour être informé de sa prochaine sortie