Arnaud Georgin

Pour fêter dignement son 4ième anniversaire JQuery passe en version 1.4. Un site a d’ailleurs été développé pour l’évènement : http://jquery14.com/.

Au menu de cette nouvelle version on retrouve :

• des performances améliorées notamment pour les méthodes dites “populaires ” telles que .addClass(), .removeClass(), .css(), .append(), .html(), …
• la sérialisation des tableaux a la mode PHP pour les appels ajax
• détection automatique du content-type lors de retour d’un appel ajax (j’imagine que bon objet doit être instancié JSON, XML, text, ..)
• une nouvelle syntaxe : la “Quick Element Construction” pour ajouter des élements à une page (au passage je trouve cette nouvelle fonctionnalité énorme, nous y reviendrons plus loin dans cet article)
• le “multi-binding” d’évènement. Vous pouvez abonner un élément à plusieurs event (click, mousenter, …) en une seule ligne
• …

Je vous laisse découvrir la suite sur le site de JQuery mais ce n’est que du bon.

présentation de Quick Element Construction

C’est une nouvelle syntaxe qui permet en une seule instruction de créer et de qualifier complètement un élément du DOM (un div par exemple). Maintenant en une instruction vous pourrez :

• créer l’élément,
• rattacher l’élément à un parent,
• définir ses paramètres de style
• définir ses évènements et les callback associés

plus qu’un long discours un exemple est plus parlant :

Pour finir sur cette sortie de JQuery 1.4, voici mon avis personnel. Cette bibliothèque hausse encore son niveau que je trouve pour ma part excellent et offre encore plus de souplesse et de robustesse pour les développeurs web. Toutes les évolutions apportées par cette nouvelle version vont, à mon avis, dans la bonne direction en conservant la philosophie de base de JQuery : simplicité et rapidité.

C’est dans des jours comme aujourd’hui que je me dis quelle joie de faire du développement

developpement bibliothèque, framework, javascript, JQuery

Depuis le 21 Avril 2009, Google a mis à notre disposition une API Google Analytics (Cf. post sur le blog de google).

Cette API permet d’interroger le service Google Analytics afin de pouvoir extraire les données de consultations qui y sont stockées. Celle-ci est encore en version beta mais c’est une excellente nouvelle car ce type de fonctionnalité était attendue depuis très longtemps.

Google met à disposition 3 modes d’accès différents pour s’interfacer avec le service Analytics :

• en requête HTTP
• en JAVA
• en Javascript

requête HTTP

C’est la méthode de base pour interroger le service Analytics. On accède aux données en interrogeant des urls fournies par google. Que ce soit via les API Java ou Javascript la méthode d’accès aux données reste la même : des appels en HTTP vers les urls google. Google fourni en réponse des appels un flux XML contenant les données qui correspondent à la requête (nombre de visiteurs sur un période, nombre de pages vues, ….).

C’est ce protocole qu’il faudra employer pour s’interfacer avec le service Analytics pour tout autre langage que Java et Javascript (ie: PHP, Python, …).

Vous trouverez plus d’informations à l’adresse : http://code.google.com/intl/fr/apis/analytics/docs/gdata/1.0/gdataProtocol.html

API Java

Google met à disposition des développeurs Java un ensemble de classes masquant la “tuyauterie” d’appel ainsi que le traitement du flux XML en retour.

Vous trouverez plus d’informations à l’adresse : http://code.google.com/intl/fr/apis/analytics/docs/gdata/1.0/gdataJava.html

API javascript

Comme pour le langage Java, Google met à disposition des développeurs Javascript une bibliothèque de fonctions  masquant la “tuyauterie” d’appel ainsi que le traitement du flux XML en retour.

Vous trouverez plus d’informations à l’adresse : http://code.google.com/intl/fr/apis/analytics/docs/gdata/1.0/gdataJavascript.html

Il faut noter que pour toutes les méthodes d’accès, il faut respecter les pré-requis suivants:

• disposer d’un compte Google Analytics,
• utiliser l’API d’authentification Google avant de pouvoir effectuer une requête (documentation sur l’api d’authentification ici)
• Respecter la règle de quota mise en place par google : pas plus de 10 000 requêtes par 24h et moins de 100 requêtes toutes les 10 secondes. Au delà, vous le service Analytics retourne une erreur HTTP 503 (Service Unavailable)

Je vous reparle très rapidement de cette API dès que j’aurais eu le temps de jouer un peu avec

developpement developpement, javascript

JQuery est de plus en plus à la mode. Résultat nombreux sont ceux qui veulent l’utiliser pour des développements futur.

Mais quid de l’existant.

En effet, il peut être parfois fastidieux de recoder toutes les fonctions javascript d’un site qui utilisait un autre framework javascript tel que prototype.

Inclure JQuery en même temps que prototype par exemple génère des conflits. Dans ce cas par exemple, il résultera un conflit à cause de la fameuse fonction $ qui existe dans en JQuery et en Prototype.

Heureusement, JQuery répond à la problématique en introduisant le mode de fonctionnement “No Conflict“. Pour cela, il suffit d’invoquer la méthode jQuery.noConflict(); à la suite du chargement de l’ensemble des frameworks.

Ainsi, en reprenant l’exemple de la fonction $, celle-ci n’utilisera pas JQuery mais un autre fremewok (ou une fonction propriétaire) définissant cette fonction.

ATTENTION, pour utiliser les fonctions de JQuery, il faut utiliser l’operateur jQuery.xxx et non plus l’opérateur $.xxx.

developpement framework, javascript, JQuery, prototype

Je viens de débuter depuis quelque jours le développement d’un gadget iGoogle pour un des sites sur lesquels je travaille. Je suis rapidement tombé sur un problème ennuyeux lors de la phase de développement le cache. N’ayant pas trouvé la solution facilement je vous fait partager mon expérience.

Avant d’aller plus loin, voici quelques rappels.

Un gadget iGoogle est une petite application qui s’installe sur la plateforme iGoogle. En général ces applications servent à mettre en avant les contenus d’un site Internet (la météo, les résultats sportifs, …) mais certaines font beaucoup plus qu’être un simple agrégateur du flux RSS ou XML. C’est applications sont en général un document XML contenant de l’HTML couplé à des feuilles de styles CSS pour l’interface utilisateur ainsi que du code javascript pour les interactions.

La plateforme iGoogle est le conteneur de ces applications (à noter qu’il existe d’autres conteneurs d’applications tels que facebook, myspace, …). Elle permet ainsi d’ajouter et/ou supprimer des applications, gérer leur affichage ainsi que leur comportement. Pour finir sur la présentation du conteneur iGoogle, Google fournit toute une série d’API de développement utilisables en javascript (appels ajax, API opensocial, …) au sein d’un gadget.

Pour utiliser iGoogle, il suffit de disposer d’un compte chez google (un compte gmail par exemple). Ensuite, vous pouvez utiliser le service et développer vos premiers gadgets.

Lors du développement d’un gadget, le seul moyen de tester notre code consiste à ajouter ce gadget à notre conteur iGoogle. Or c’est à ce moment que se pose notre problème. Lors de l’ajout d’un gadget dans le conteneur, celui-ci est mis en cache par google. Ce comportement est génial lorsque le gadget est finalisé. En effet, le cache évite que le gadget interroge constament votre serveur ce qui pourrait poser problème si le gadget est utilisé par de nombreuses personnes. Par contre, en phase de développement il est impossible de développer avec du cache surtout que la durée de mise en cache est très importante.

Heureusement (il m’a fallu une après-midi pour trouver la solution), google met à notre disposition un gadget : my gadgets qui permet d’administrer les gadgets au sein du conteneur courant. Ce gadget vous permet d’ajouter un gadget dans votre conteneur et définir si celui-ci doit utiliser le cache google.  Pour cela il suffit de décocher la case cached en face du nom de votre widget et le tour est joué.

developpement gadget, iGoogle, javascript, widget

Utilisant comme framework javascript de plus en plus JQuery (comparaison des frameworks javascript) j’ai été amené à développer des interfaces utilisateur à base de “popup ajax”.

Ne voulant pas réinventer la roue, j’ai cherché quels étaient les plugin JQuery qui offraient cette fonctionnalité. Mon choix s’est arrêté sur Thickbox.

Thickbox est plugin JQuery permettant d’afficher à l’écran du contenu en sur-impression de la page courante.

Ce plugin est très léger : 20ko en version compressée et 58ko en version normale. De plus son mode de fonctionnement est l’un des plus simple que j’ai utiliser et certainement le moins intrusif.

En effet pour ouvrir un contenu dans une “popup ajax”, il suffit (une fois le script chargé dans la page évidemment) de définir un lien HTML portant l’attribut class=”thickbox”. Thickbox se charge donc d’ouvrir la cible du lien dans une popup en sur-impression de la page courante.

La puissance de la bibliothèque ne s’arrête pas là. En effet, le comportement de la popup est paramétrable. Vous pouvez très simplement déterminer par exemple la hauteur ou la largeur de la popup à afficher. Pour cela, rien de plus simple il suffit d’ajouter à la suite de l’url du lien à charger en popup les paramètres height et/ou width.

Par exemple, si nous voulons charger la home de google dans une popup de largeur 200 pixels et de hauteur 300 pixels il suffit de définir un lien dont l’attribut href aura la valeur http://google.fr?height=300&width=200.

de la même manière si nous voulons que notre popup soit modale il nous suffit d’ajouter le paramètre d’url &modal=true.

Je conseille vivement à tous les utilisateurs de JQuery de tester cette bibliothèque très utile et tellement simple d’utilisation qu’elle rendra vos développement javascript encore plus joyeux. Vous remarquerez au passage que le système d’affichage des photos de ce blog utilise thickbox

developpement ajax, javascript, JQuery

Le web 2.0 étant la nouvelle tendance actuelle il existe une multitude de framework javascript nous faciltant la tache dans nos développements (ajax, manipulation du DOM, widgets, modalbox…).

En faisant un état des lieux des projets web dont j’ai la charge, je me suis rendu compte que nous utilisons pas moins de trois frameworks différents par projet. En effet, chaque développeur a ses habitudes, ses bibliothèques et utilise par conséquent le framework qu’il connait le mieux pour gagner du temps.

Résultat, les sites embarquent un nombre de javascript important : les différents frameworks ainsi que nos codes les utilisant.

Tous les frameworks font globalement la même chose, nous avons donc décidé d’uniformiser nos projets afin d’utiliser un framework unique.

Il s’est alors posé la question du choix du framework : prototype, jquery, yui, mootols… avec deux préocupations majeures : les performances et les fonctionnalités natives du framework.

En cherchant de la documentation sur le net, je suis tombé sur la page suivante :

http://mootools.net/slickspeed/

Cette page permet de tester sur son propre navigateur les performances ainsi que les différentes fonctionnalités des framework javascript les plus connus. Pour cela il vous suffit de cliquer sur le bouton “start test” et d’attendre la fin de l’exécution des tests.

Résultats des tests sur ma machine (windows XP, 2Go de RAM)

Avec Firefox 3.0.4

1. Dojo 1.1.1
2. JQuery 1.2.6
3. Mootools 1.2
4. Yui (Yahoo User Interface) 2.5.2
5. prototype 1.6.0.2

Avec Internet Explorer 6.0.2

1. Dojo 1.1.1
2. JQuery 1.2.6
3. Yui (Yahoo User Interface) 2.5.2
4. prototype 1.6.0.2
5. Mootools 1.2

Conclusions

Les deux grands gagnants sont et de loin Dojo et JQuery.

Nous concernant, nous avons choisi JQuery framework plus connu que Dojo avec une communauté de développeurs importante et ayant une syntaxe proche de prototype qui était très utilisé chez nous.

Projets professionnels, developpement dojo, framework, javascript, JQuery, mootools, prototype, yui