Ajax Journal

L'équipe du toolkit javascript Dojo vient de publier une Release Candidate de la version 1.0, dont le version finale est attendue sous peu. Pas d'énorme modification fonctionnelle par rapport à la version 0.9, mais des corrections de bugs et des améliorations de compatibilité.

Semaine chargée, puisque 2 toolkits javascript viennent de publier une nouvelle version.

• Dojo 0.4 est maintenant disponible, proposant dans cette nouvelle mouture un foule d'amélioration et de nouvelles fonctionnalités:
  • Des fonctions d'accessibilité (dojo.a11y)
  • Un moteur de graphiques (dojo.charting).
  • Des amélioration dans le support de l'internationnalisation (dojo.i18n).
  • Une librairie graphique 2D (dojo.gfx).
  • La possibilité de chainer des animations dans dojo.lfx (cool)
  • Des nouveaux widgets, des améliorations pour les widgets prééxistants.

Bref que du bon !

• Moo.fx est maintenant disponible en version 2. Cette nouvelle version, de l'une des plus légères biblotheques d'effets graphiques javascript, apporte également sont lots de nouveautés:
  • Fx.Style permettant de modifier n'importe quelle propriété CSS.
  • Fx.Styles permettatnde modifier d'un coup d'un seul plusieurs propriétés CSS.
  • Fx.Color permettant de manipuler les couleurs des éléments.
  • Fx.Scroll permettant de faire scroller des divs.
  • Une version complétement réécrite de Accordion

A vos éditeurs de code !

Atomic OS est un projet visant à developper une sorte de système d'exploitation (WAJAX) tournant dans un navigateur qui utilise Ajax pour reproduire le fonctionnement d'un système (ROM, Kernel ...) avec gestionnaires de fenêtres (déplacement, reduction ...). Une démo est utilisable en ligne. Reste à trouver l'utilité de ce genre de chose ... Qu'en pensez-vous ? Utile, Inutile, Simple Démo Technologique, Aperçu de l'avenir ?

Les closures ou fermeture sont un aspect puissant de javascript, mais un aspect malheureusement méconnu et pouvant paraitre obscure de prime abord.

Morris Johns a mis en ligne un article intéressant expliquant le fonctionnement des closures en Javascript, la facon dont elles fonctionnent et les erreurs classiques commises lorsque l'on débute. Une lecture valant le détour si vous souhaitez utiliser toutes les subtilités offertes par Javascript. Un exemple ? Douglas Crockford utilise les closures pour que ses objets JS possèdent des membres privés. (un peu comme en java ou c++).

Mais attention ! Comme nous avons pu le voir dans un article récemment publié sur l'AjaxJournal, les closures peuvent créer des fuites de mémoire sous certains navigateurs si elles sont mal utilisées. Prudence donc !

Une fuite de mémoire ou memory leak en anglais est une consommation involontaire de mémoire par un programme informatique, généralement due au fait que le programme ne libère pas la mémoire dont il n'a plus besoin de facon convenable. Cela entraine des ralentissements des programmes voir des plantages.

Concept bien connu des développeurs C, les fuites de mémoires étaient pour le moment bien loin des préoupations des développeurs d'applications web. Cependant avec Ajax, la donne a changé. En effet, avant l'arrivée du web 2.0, l'utilisation de javascript dans les pages web était relativement simple et surtout à chaque changement ou rechargement de page, le Garbage Collector - Ramasse-miettes en francais - faisait son office est désaloué les objets javascripts utilisés par la page précédente.

Mais vous l'auriez bien compris, le problème vient qu'avec Ajax la page web n'est plus rechargée, elle est modifiée à la volé, et de nouveaux objets javascripts sont sans cesses créés. Le garbage collector ne désaloue donc pas les objets non utilisées. Il faut le faire explicitement pour eviter les fuites de mémoire. Ces fuites de mémoires peuvent prendre des proportions assez importante, alors soyez vigilant.

De plus il existe d'autre cas non liés exclusivement à l'utilisation d'Ajax qui peuvent provoquer des fuites de mémoires, Internet Explorer semble être enclin à se laisser aller dans ce secteur. (Encore lui !) Le garbage collector de l'interpreteur Javascript d'IE ne semble pas capable de detecter des références circulaires entre des noeuds DOM et d'autre objets. Ce problème vien(drai)t du faire que les objets JS et les objets DOM sont gérés par deux composants différents. L'article DHTML leaks like a sieve (une lecture chaudement recommandée) revient sur les problèmes causés par les références circulaires (la gestion des évenement, les fermetures) et donne quelques exemples de code javascript provoquant des fuites de mémoire.

var unDiv = document.getElementById('unDiv');
monObjetJS.unObjetDom = unDiv; 
unDiv.unObjet = monObjetJS;

Ce code provoque une référence circulaire, monObjetJS ayant une référence du unDiv et unDiv ayant une référence vers monObjetJS.

Il faut également noté que les handler d'évenement peuvent également créer des références circulaires si celui-ci référence un objet javascript. Il faut donc autant que possible décrocher les handlers d'évenement lorsqu'ils ne sont plus utilisés.

Un article sur le wiki mozilla pour les développeurs traite également de ces problèmes

Ce problème de fuite de mémoire n'est pas spécifique à IE, tous les navigateurs peuvent en être victimes. Pour preuve, Firefox a plusieurs bugs pouvant provoquer des fuites de mémoires.

Enfin pour terminer ce post, un outil utile. Pour détecter ces fuites de mémoire, David Baron (développeur Mozilla) a développé une petite extension firefox avertissant des blocs de mémoire perdus lorsque l'on quitte une page web. Bien pratique.

Firefox via son système d'extension permet à un miriade d'outil de faciliter la vie des développeurs d'applications web. Parmis la multitude d'extensions disponibles, en voici trois, vraiment indispensables.

Firebug est un outil permettant de grandement faciliter le débugage d'application web, en effet il propose au coeur de la même extension, un inspecteur DOM, une console javascript évoluée, un débugger javascript. L'une des killer features de firebug est la possibilité de voir les requêtes XMLHttpRequest effectuées par l'application, tellement pratique pour débugger de l'Ajax.

La Web developper toolbar est comme son nom l'indique à nos amis anglophones, une barre d'outils destinée aux développeurs web. Elle apporte son lot d'outils allant de l'éditeur CSS, à la validation de page XHTML en passant par l'affichages des id des balises en surimpression sur la page web.

Le Venkman Debugger est un débugger Javascript très complet proposant toutes les fonctionnalités attendues d'un débugger. Il permet même de débugger les fichiers javascripts qui animent Firefox. (attention cette extension est un peu lourde en terme de ressources consommées).

Bref, 3 extensions à installer de toute urgence si vous utilisez Firefox.

Que se cache derrière ce titre obscure ? Tout simplement un article expliquant la facon de bien mettre en place un , devenu quasiment synonyme d'application web 2.0 depuis l'avènement d'ajax. GenXDesign propose ainsi un article de 4 pages sur le sujet, CSS et Javascript sont au menu, et bien évidemment l'ensemble se termine par une page de démo.

Ed Burnette a posté sur son blog chez Zdnet un article sur les erreurs classiques commises lorsqu'on utilise Ajax. Il identifie les principales erreurs à éviter à tout prix comme étant:

• Des communications entre le client et le serveur trop lourdes: Il faut éviter de faire trop d'aller-retour entre le client et le serveur, et essayer de faire des requêtes intelligentes, en mettant en cache un maximum de chose.
• Trop d'analyse (parsing) de flux XML, l'efficacité des parseurs XML intégrés aux navigateurs web étant ce qu'elle est ... il faut préférer des formats alternatifs de serialisation des données comme JSON par exemple.
• Charger toute l'application avant d'afficher quelque chose. Il est préférable de charger le minumum de chose au lancement pour donner un maximum de retour à l'utilisateur, et charger ensuite, en arrière plan, la suite.
• Effectuer trop de chose sur le serveur. Ajax est une méthodologie pour offrir plus d'interactivité à l'utilisateur, en transférant un peu d'intelligence au client executant l'application. (par opposition à tout effectuer sur le serveur, et uniquement fournir les résultats à l'utilisateur). Il faut donc ne pas eviter à transferer autant d'intelligence que possible au client, tout en gardant à l'esprit les erreurs ci-dessus à éviter et sans négliger la sécurité de l'application.

Un point de départ interressant pour une réflexion sur les travers d'Ajax.

JSDoc est un utilitaire s'inspirant largement de JavaDoc et permettant de générer très facilement la documentation de son code Javascript à partir des commentaires placés dans les fichiers sources. Le résultat est propre et indispensable pour des projets utilisant beaucoup Javascript.

Log4JS est une classe permettant de fournir des fonctionnalités de log en javascript. Elle s'inspire de Log4j du Logging Services de la fondation Apache (oui, oui la même que le célèbre serveur web). Il est possible d'envoyer les logs vers une popup, un fichier local, et - fonctionnalité intéressante - un fichier distant via des appels à XmlHttpRequest.

La page d'exemples permet de se rendre compte de l'étendue des possibilités de logging offertes par log4JS. Bref, un bon outils pour ajouter facilement des logs dans son projet web 2.01.

Steven Miles a développé un script d'upload de fichier utilisant Ajax afin de rendre compte à l'utilisateur de l'avancement de l'upload de ses fichiers. Perl, PHP et Javascript animent le tout. Le look de l'ensemble est facilement adaptable en modifiant la CSS.

L'excellent Ajaxian.com propose aujourd'hui un article pour découvrir le toolkit Dojo par la pratique (en anglais seulement).

Voici le début d'une série de 2 ou 3 articles (je ne me suis pas encore décidé) sur l'écriture d'une application AJAX, ici point d'application révolutionnaire, mais un pretexte pour découvrir par la pratique les entrailles d'une application web 2.0.

Lire la suite

Le fameux toolkit Javascript Dojo est maintenant disponible en version 0.3 (attention à ne pas se fier à ce numéro de version relativement faible).

Cette nouvelle version apportent plusieurs nouveautés très interressantes dont dojo.lang.storage permettant de stocker des données du coté du client et non du serveur comme c'est le cas pour toutes les applications web. Cela ouvre des possibilités interressantes comme celle de pouvoir ajouter un vrai mode hors-ligne, imaginez la possibilité de rédiger ses mails sous gmail en mode hors ligne et de les envoyer lorsque l'on repasse en mode en-ligne ! Un article au sujet de cette nouvelle fonctionnalité est disponible sur le blog de Brad Neuberg.

L'excellent OpenWeb propose un article complet pour comprendre le fonctionnement de l'objet XmlHttpRequest, qui je rappelle permet de faire des requêtes HTTP asynchrones permettant ainsi d'effectuer des actions (sauvegarde, mise à jour de l'interface ...) sans avoir à recharger toute la page, les échanges entre le navigateur et le serveur se faisant en arrière plan. Après une partie théorique traitant entre autre sur les avantages et les inconvénients de l'utilisation de XHR, la partie pratique explique la facon de créer l'objet XHR en fonction du navigateur utilisé, puis d'effectuer des requêtes, le tout étant illustré par un exemple concret et utile d'utilisation, à savoir un système d'authentification. Bref, un article qui mérite lecture.