Le weblogue de SeB

Introduction

Qu’est-ce que le cross-domain ? Un script Javascript est dit cross-domain lorsqu’il est hébergé sur un serveur avec un nom de domaine bien précis et qu’il fait des requêtes HTTP vers d’autres domaines.

Par défaut, ce comportement est interdit par les navigateurs butineurs. Non pas pour pourrir la vie des développeurs, mais pour protéger celle des utilisateurs. Cependant il existe quelques techniques qui permettent de contourner le problème.

Solutions

Le proxy

La première méthode consiste à mettre en place sur son propre serveur un proxy. Le Javascript interroge le proxy qui lui-même va interroger le serveur distant qui peut être sur un autre domaine. Cette solution n’est pas idéale car elle oblige à mettre en place ce fameux proxy. De plus dans le cadre la distribution d’une API Javascript, la technologie utilisée côté serveur par les utilisateurs sur service n’est pas maîtrisée.

Notons tout de même qu’elle a l’avantage de pouvoir mettre en place un système de cache (au niveau du proxy) pour améliorer les performances^[1].

Les images invisibles

Cette astuce consiste à ajouter la référence d’une image dans le document HTML dont l’URL pointe vers le serveur distant. Bien entendu cette image est invisible et l’URL pointe vers un service et non vers une image. Si je ne me trompe pas, cette astuce est utilisé par Google Analytics.

La contre-partie est qu’il n’est pas possible de récupérer des informations. Cette méthode a ses limitations puisqu’elle ne sert qu’à envoyer des données à un serveur distant et non à en récupérer.

JSON

Qu’est-ce que JSON ? C’est un format de structure des données. Et il a l’avantage^[2] d’utiliser la notation des objets JavaScript.

Cette technique consiste à ajouter la référence d’un script dans le document HTML dont l’URL pointe vers le serveur distant. Le serveur doit alors retourner son résultat sous le format JSON. Ensuite à la réception des données, une fonction de callback Javascript exécute le traitement des informations retournées par le serveur.

Cette solution nécessite que le serveur distant puisse retourner son résultat dans le format JSON. Néanmoins, de plus en plus de services tels que ceux de Yahoo! ou Google proposent de spécifier le format de retour^[3] et même la fonction de callback !

Cette méthode possède ses limitations. Cependant, dans le cadre de la mise en place d’un service web avec la mise à disposition d’une API Javascript, cette technique se révèle être terriblement efficace ! Elle permet donc d’envoyer des informations à un serveur distant et de recevoir des donnÃés en retour.

Conclusion

Chaque méthode a ses avantages et ses inconvénients. Tout dépend du contexte. Il faut retenir que pour seulement envoyer des données la méthode des images invisibles suffi. Alors que pour récupérer des informations, il faut utiliser selon les cas un proxy ou JSON.

Notes

[1] Et économiser de la bande passante.

[2] Pour notre problème.

[3] En général XML ou JSON.

Dans la bataille des géants du web, chacun essaie de promouvoir son framework Ajax.

La société Google ne cesse de distribuer des applications de type clients riches. Leurs interfaces sont réalisées en Ajax. Et en connaissant les difficultés pour développer en Javascript, on est en droit de se demander quel est leur secret ? Surtout au regard de la qualité exceptionnelle des interfaces web réalisées telles que Google Mail ou Google Reader.

La réponse à cette question a été donnée avec la publication^[1] de Google Web Toolkit, leur framework d’applications riches.

GWT se démarque de ses concurrents de par son architecture. En effet, alors que la plupart proposent des bibliothèques Javascript combinant judicieusement HTTPRequest, XML, HTML et CSS; Google propose un environnement en Java^[2] !?

L’interface est codée en Java, puis un compilateur génère le code Javascript de l’application à la sauce Ajax. Le développement en Javascript n’est pas une chose aisée. Et on ne parle même pas du debuggage. La force de cette architecture est que le développeur dispose alors des outils de développement Java. Le projet Echo 2 a également opté pour cette solution.

Le code généré peut est directement exécuté dans un butineur si l’application n’a pas besoin qu’un serveur distant. Sinon, l’application peut être chargé dans l’environnement d’exécution de Google^[3] ou dans un conteneur de servlet tel que Tomcat.

Google propose aujourd’hui un framework de conception d’application web très intéressant. Il faut noter deux petit bémols. Tout d’abord l’environnement interroge à chaque exécution Google pour savoir si une nouvelle version est disponible et en profite pour envoyer quelques informations telles que l’adresse IP. De plus le code Javascript semble assez conséquent…

Ou comment afficher un butineur dans une page web ?

Bitty Browser est réalisé en JavaScript et permet d’afficher un mini-butineur sur un site web :

Un gadget inutile ? Eric Dupin y voit une application intéressante : une émulation live pour les appareils mobiles tels que les PDAs. En effet la taille de la zone d’affichage est totalement redimensionnable. Néanmoins, il ne faut pas oublier que Bitty adopte les mêmes comportements que le butineur utilisé pour l’afficher. Ainsi les comportements peuvent fortement différer par rapport à un vrai PDA.

Son utilisation reste anecdotique, mais sympathique.

Une nouvelle version est sur le point d’être publiée.

Stephan Strittmatter annonce qu’il va bientôt publier log4js en version 0.2.

Avant celà, il recherche des testeurs pour cette prochaine version. Notamment des personnes utilisant Mac, Unix ou GNU/Linux pourront valider cette nouvelle version. La version en cours de développement est bien entendue disponible sur le SVN du projet.

Alors pour obtenir la meilleure qualité possible pour ce framework, il ne faut pas hésiter tester cette version et à rapporter les différentes anomalies rencontrées auprès de l’auteur.