Exploitez l’historique de navigation d’applications AJAX grâce à Yahoo!

L’un des plus gros reproche fait aux interfaces réalisées avec AJAX est l’impossibilité d’utiliser le bouton ‘Retour’ du navigateur. Et bien tout ceci est du passé puisque les équipes de Yahoo! ont publié la semaine dernière un composant qui enregistre les actions réalisées en local par les utilisateurs : Browser History Manager.

Je ne suis pas un spécialiste de Javascript et suis donc bien mal placé pour juger de la qualité de ce composant, mais là n’est pas la question. Je viens en effet de découvrir que ce composant a été développé par un certain Julien Lecomte qui nous raconte la genèse de son composant ici : Building the YUI Browser History Manager.

Photo de Julien Lecomte

Julien Lecomte ? Mais bon sens, mais ce type est français ! Alors ça c’est formidable, rien que pour ça j’interdis formellement tout forme de critique à l’égard de ce composant ! Est-ce du chauvinisme primaire ? Oui tout à fait, et alors ?

Un commentaire sur “Exploitez l’historique de navigation d’applications AJAX grâce à Yahoo!

  1. Pour votre information, la librairie JQuery (très complète et légère) propose un plug-in pour simuler le bouton ‘retour’. Evidemment JQuery ne dispose pas des mêmes ressources que Yahoo pour en parler :) Mais ca devrait intéresser quelques developpeurs… P.S: Fred, étiez-vous à la conférence?

  2. A noter que le framework « ajax » (gwt pour ne pas le nommer) de google possède l’historique depuis un bon bout de temps !

  3. @ Michel > Quelle conférence ? @ Manatlan > Oui, mais le Google Web Toolkit est un peu plus complexe à manier (c’est un framework Java qui génère de l’AJAX). Attention, je le dis et je le répète : ceux qui diront du mal de ce composant seront jugés pour haute trahison envers le travail d’un compatriote ! /Fred

  4. Pardon Fred, j’ai lu tes 2 posts et j’ai un peu tout mélangé, je dois pas être très bien réveillé non plus :^) Je parlais de la conférence à Londres sur le future des applications web. Mais c’est plutot un post pour l’autre topic… sorry

  5. Bonjour, Un peu de veille technologique vous aurait appris que ce type de composant existe depuis longtemps, notamment dans le framework BackBase (que j’utilise au quotidien) :) Je suis sur que si vous êtes emballés par ce type de composant, vous pourrez vous extasier devant les CGI c’est une technologie révolutionnaire :)

  6. Rololo, c’est pas tout neuf tout ça. Le bouton retour marche déjà depuis longtemps Gmail par exemple. On trouve quelques scripts (plus ou moins mauvais) permettant de gérer la navigation. Le seul problème c’est Safari, sur lequel ça marche pas. À voir si cette solution marche avec, ou non. De toute façon si ce n’est que pour YUI… Le dernier problème c’est que rien de tout ça n’est standard, et que c’est des bon gros hacks. Ce devrait être un truc standardisé dans le langage javascript lui-même. Ce serait tellement mieux.

  7. Je viens d’aller voir comment ça marchait. À lire la liste des limitations, c’est bien la méthode classique (qui a de grandes chances de pas marcher sur Safari) qui est employée. Tout d’abord on ajoute une iframe cachée à la page (pas sûr qu’on en ai besoin mais je crois) avec un formulaire dedans. Bon, c’est pas très propre, mais passons. On utilise ensuite les fonctions de mémorisation des formulaires par les navigateurs pour stocker des données. Le lien permettant d’y accéder, c’est le hash de la page (à savoir ce qu’il y a après le « # » dans l’URL). Quand on clique sur suivant / précédent, on se ballade juste dans ces hashs, ce qui ne recharge pas la page, mais permet à javascript de savoir si on se ballade dans l’historique de navigation. Du coup ça marche. Sauf qu’il y a tout un tas de limitations et de problèmes qui peuvent survenir et qui vont tout casser l’expérience utilisateur, s’il fait une mauvaise manœuvre — totalement admissible au demeurant, mais mauvaise pour l’application. si on recharge la page, les navigateurs qui ne se souviennent pas du contenu des formulaires oublient les données ; si on force le rechargement de la page : tous les navigateurs oublient les données ; pas de bookmark possible : le hash n’est pas envoyé au serveur par le navigateur qui se le garde pour lui ; si on veut autoriser le bookmark, il faut relancer une requête au serveur avec AJAX juste après avoir chargé la page, ce qui double la charge serveur du coup et offre un temps de latence entre le chargement de la page et l’arrivée du contenu ; je crois pas que ça marche avec Safari ; etc. Bon je suis méchant là. C’est bien que des trucs comme ça arrivent et corrigent des problèmes. Le hic c’est que ça reste des gros hacksqui viennent avec tout un ensemble de défauts. Voilà, ça c’était pour l’analyse technique. Si ça marche pas comme ça, dites-moi donc :)

  8. @ Pierre > BackBase ? J’avais testé leur moteur de recherche de billets d’avions en démo. C’est très bien mais un peu lent, non ? Ont-ils améliorer leur framework depuis ? /Fred

  9. @ Fred > Oui c’est vrai que le framework Backbase est un peu plus lent que les autres frameworks Javascript. Backbase est une couche d’abstraction à la programmation Javascript: c’est un langage de balises (pas une ligne de javascript), et ces balises sont interprétées côté client, dans le navigateur. On gagne en productivité et en qualité, mais on perd un peu en performances. Mais je suis sur qu’ils travaillent à l’optimiser :) Ils ont une très bonne équipe technique en Hollande que j’ai beaucoup apprécié rencontrer, et c’est un produit vraiment innovant. D’ailleurs c’est un peu la voie que suit Microsoft avec le XAML, sauf que chez Backbase, pas besoin de plug-in :)

  10. Sans vouloir te casser tes illusions, mais, que-ce qui prouve que Julien est français ? … Peut etre canadien ou belge, voir même originaire de Louisiane et pas comprendre un seul mot de français ! :o))) .oO(d’autant que son anglais est irréprochable) A part çà, mis à part les antennes locales de Yahoo!, il y a beaucoup d’etrangers dans les centres de recherche de Yahoo!, même aux USA.

  11. Je viens de tomber sur cet article, qui date un peu, certes. Mais une petite interrogation me vient, peut-être est-elle débile, mais sait-on jamais…

    Il me semble, a priori, qu’une personne autorisant javascript sur son navigateur, autorise en général aussi les cookies, dans la majorité des cas ( à moins de tomber sur un visiteur en mode semi-paranoiaque ). Pourquoi ne pas utiliser les cookies comme historique de navigation? ça me semble plus léger et plus simple d’utilisation qu’une appli AJAX. A la limite même, les variables de session sont tout aussi maniables, pas besoin d’une iframe cachée, de formulaires qui foirent selon les navigateurs, un simple contrôle sur l’état des variables de session et hop, le tour est joué…

    Enfin je suis probablement à côté de la plaque, si des grands intelligents utilisent des composants pour faire ça, il doit y avoir une raison.

Laisser un commentaire