Babozor’s Blog

Source: http://ajaxian.com/archives/speeding-up-ajax-with-json

Augmenter la rapidité d’Ajax avec JSON

La rapidité est la chose la plus importante quand on parle d’applications en ligne. Les utilisateurs détestent attendre, spécialement les plus expérimentés. En sachant cela, optimiser tout ce qui est possible dans votre application peut faire la différence entre quelqu’un qui délaisse votre service et quelqu’un qui reste et continue d’explorer votre site. Une méthode pour améliorer la vitesse de votre application est décrite sur Builder.com en utilisant JSON pour améliorer la rapidité de connexion des scripts Ajax entre ceux-ci et le serveur.

“
XML est la méthode standard déchange de donnée, mais ce n’est pas souvent la meilleure méthode. Bienque le XML ajoute une structure et des meta-data aux données, il le fait d’une façon un peu bavarde. XML dispose aussi d’une syntaxe un peu complexe, demandant l’action d’un parser qui est loin d’être trivial. En JavaScript, XML diot être parsé en utilisant une arborescence de type DOM. Et une fois l’arborescence DOM construite, vous devez aussi pouvoir la parcourir, pour créer les objets JavaScript correspondant ou alors utiliser les données XML dans votre application Web côté Client.

Heureusement, il existe une meilleur méthode
“

L’article introduit JSON au lecteur, en offrant une comparaison avec une structure XML équivalente. Leur point de vue est que le XML est très bien pour marquer les données, mais JSON permet d’accélérer les échanges de données. Un exemple est fourni de la différence pour la même requête entre XML et JSON, la solution JSON paraissant plus simple. L’article se finit sur une démonstration de la fiabilité de JSON pour votre application, et certains aspects de cette technologie côté Serveur.

Babozor:
Pas encore eut le temps de regarder plus précisément l’article en question, mais ça vaut le coup d’oeil…

Source: http://ajaxian.com/archives/phpclassesorg-chooses-iframes-over-ajax

PHPClasses.org choisit les iFrames au détriment d’Ajax?!

Quand les gens regardent pour la première fois les possibilités d’Ajax, il semble qu’ils soient immédiatement retournés et s’y lancent à pied joint. Bien sûr, d’autres plus mitigés, prennent Ajax comme un moyen d’ajouter certaines fonctionnalités à leur site web, mais ne semblent pas convaincu. Ils se retranchent donc vers des notions connus et qui marchent pour eux - la traditionnelle iFrame.

Une exmple est ce post sur le blog de PHPClasses qui parle du choix de Manuel Lemo de passer par des iFrame au lieu du XmlHttprequest pour la nouvelle version de son site, PHPClasses.org.

“
Ce plu-in Ajax que j’ai développé n’utilise par l’objet XMLJttpRequest. Il utilise à la place des iFrame cachées. Certains considèrent l’AJAX comme la seule méthode pour une interaction serveur-navigateur, grâce à l’objet XmlHttpRequest. Cette définition est fausse puisqu’on peut utiliser les iFrame pour les même besoins.
Je voudrais donc partager avec vous les raisons pour lesquelles j’ai choisi les iFrames plutôt que l’objet XMLHttpRequest.
“

Cretaines de ces raisons sont: “Compatibilité navigateurs”, “Les contraintes de sécurité des navigateurs” et “Rapidité de réponse”. Il base sa discussion sur une présentation qu’il a assisté qui disait que Ajax convenait pour de petites requêtes, mais qu’une iFrame pouvait supporter des requêtes plus larges, d’une façon plus facile et plus rapide que son homologue. Il cite aussi une autre raison pour sa décision: avec une connexion Ajax, les données ne sont disponibles qu’à la fin de la requête, alors que l’iFrames peut renvoyer des données partielles. Quelques autres arguments sont avencés, comme la possibilité de faire plusieurs actions dans la même requête et qu’il n’y a pas de méthode directe qui gère l’upload de fichier.

Babozor:
Je ne suis pas sûr que ce choix soit impartial, mais peut être pour aller à contre-courant de la tendance actuelle. Personnellement je ne vois pas l’intérêt d’un iFrame caché, alors que même pour des applications aux besoins gourmands, l’Ajax peut soutenir largement la comparaison. Il n’en reste pas moins, que la question reste ouverte…

Source: http://ajaxian.com/archives/scriptaculous-16-released
Script.aculo.us 1.6 disponible

Script.aculo.us version 1.6 est disponibe (et qui suit la mise en ligne de la version 1.1 de Rails), comme l’avait dit Thomas Fuchs.

“
Script.aculo.us 1.6 marque une divergence avec Prototype 1.5 (la version 1.4 n’est plus supportée), avec de merveilleuses nouvelles fonctionnalités et est passé par un recodage complet pour tirer le meilleur parti de Propotype 1.5.
Les nouvelles fonctionnalités incluront la possibilité de scroller des fenêtres pendant le drag & drop, des optimisations de performance et des corrections de bug.
Pour voir des combinaisons vraiment cool des nouvelles fonctionnalités de Prototype avec la dernière version béta 1.6 de script.aculo.us, regardez les exemples 1 et exemples 2 (accesibles aussi depuis le functional test suite).
“

Juste quand on commence à piger le truc, ils rajoutent d’autres trucs cool

Babozor:
Après un test léger, ces nouvelles fonctionnalités m’ont l’air plutôt gadget qu’autre chose, mais il faudrait se plonger dans le code de la nouvelle version pour voir l’étendue de la réorganisation du code pour permettre une meilleur implémentation du code avec Prototype 1.5…
A voir…

Depuis quelques temps je m’intéresse à tout ce qui touche de prêt ou de loin à ce que tout le monde apelle le Web 2.0
La définition de ce Web 2.0 reste encore floue, mais en gros le but est de faire des services plus pratiques, qui prennent en compte les réels besoins des utilisateurs, etc…
Une des technologies fondatrices du Web 2.0 est Ajax (Asynchronous JavaScript And XML), cela permet entre autre de bouger certains layers, de recharger juste du contenu dans des bouts de page, etc… cette technologie est vraiment démentiel, elle permet une interactivité hors du commun, de bouger les éléments de la page, de recharger juste les informations qu’on a besoin, etc…
Juste pour le fun, j’ai refait le site de ma fille tout en Ajax.
Le site de ma fille est assez basique, il nous permet de poster des photos, avec un petit commentaires et permet aux vsisteurs de poster des articles, regarder les photos, etc…
L’ancienne version du site était basique, vous cliquez sur le calendrier, les images de la date s’affichent, et ensuitge en cliquant sur les différents thumbnails, vous ouvrez un popup avec l’image concernée.
Le nouveau site reprend quasiment les même fonctionnalités, mais sans aucun rechargement de page, on ne recharge que le layer concerné et franchement c’est bien pratique. De même plus de popup, l’image apparaît à l’intérieur de la page, c’est plutôt joli.
Mais pendant ce ‘petit’ test, j’ai pu me confronter à un désaventage de cette technique.
J’écris en français, donc avec des accents, donc en général j’inclus un meta-tag pour que le navigateur interprète correctement les accents. Ca marche bien dans les pages standard, mais pas pour le site de ma fille. En effet tout le contenu du site est chargé ou rechargé après l’interprétation du meta tag par le navigateur, donc le navigateur ne recharge pas la page… donc ne traite pas les accents et autres caractères bizarre comme il devrait.
La solution est donc avant affichage du contenu, de remplacer tous les caractères spéciaux par leur valeur en HTML… pour le français ça va c’est pas trop long, le nombre de caractères spéciaux est limité, mais pour les langues plus exotiques, comme le bulgare, le japonais, le thailandais? comment que c’est ti qu’on fait, hein???
Si vous avez des pistes je suis preneur.