CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL ASSOCIE DE STRASBOURG. Filière Informatique Systèmes d Information

Transcription

1 CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL ASSOCIE DE STRASBOURG Filière Informatique Systèmes d Information Présenté en vue d obtenir le diplôme D INGENIEUR C.N.A.M en INFORMATIQUE par Soutenu le 13 décembre 2006 JURY Président : Membres : Mme I. Wattiau M J. Korczack M C. Eisenmann M C. Kleinpeter

2 SUJET Imaginez-vous dans une mission de consulting durant laquelle vous devez fournir tous les éléments nécessaires aux décideurs quant à l introduction d dans l entreprise. Tout d abord introduisez le sujet avec le fonctionnement d. Ensuite détaillez les avantages et les inconvénients en fonction de différents environnements. Expliquer la ou les démarches à suivre pour correctement débuter avec dans les projets existants ainsi que dans les nouveaux projets. Vérifiez s il existe des frameworks, si oui lesquels et comment les utiliser. Terminez avec les perspectives d avenir d 2/41

3 SOMMAIRE 1. INTRODUCTION EVOLUTION DES TECHNOLOGIES WEB Limites du fonctionnement standard du web Améliorations apportées au fil des années FONCTIONNEMENT D Définition Fonctionnement Mise en oeuvre Avantages et inconvénients LES FRAMEWORKS Définition Avantages d un framework Frameworks existants INTEGRATION D A UN PROJET Faut-il utiliser Ajax dans un projet? Choisir un framework La mise en œuvre CONCLUSION : PERSPECTIVES D AVENIR Utilisation d à l heure actuelle Expansion dans les prochaines années /41

4 1. INTRODUCTION Le Web tel que nous le connaissons est limité par le fait que les échanges entre le navigateur et le serveur doivent de faire de manière synchrone, c est à dire que le navigateur envoie une requête au serveur, puis doit attendre sa réponse. Ce fonctionnement est très limitatif, et ne permet pas une interactivité satisfaisante des sites. Mais aujourd hui le Web que nous connaissons est entrain de subir une transformation importante. On voit de plus en plus apparaître le terme Web 2.0, qui représente un fonctionnement beaucoup plus interactif que ce que nous connaissons. Ajax s intègre dans cette évolution vers le Web 2.0. Il s agit de transformer les sites en interfaces riches, plus conviviales, plus agréables, plus réactives que ce que nous avons l habitude de voir. Ajax permet aujourd hui d envisager le développement d applications Web, que l on pensait jusqu alors réservées à une installation locale sur le poste de l utilisateur. Avec l apparition du webmail de Google, «GMail», tout le monde s est demandé comment il était possible d avoir une interface Web aussi réactive, sans rechargement complet des pages. La solution qu a utilisé Google a pris par la suite le nom d Ajax. Ce document commence par présenter l évolution des technologies Web au cours de ces dernières années. Il explique ensuite ce qu est réellement Ajax, quel est son fonctionnement, et décrit ses avantages et ses inconvénients par rapport aux sites «standards» non Ajax. Une partie de ce document est ensuite dédiée aux frameworks Ajax, que l on voit apparaître, de plus en plus nombreux. Puis nous verrons quelle est la démarche à suivre pour intégrer Ajax dans une entreprise, à un projet déjà existant, ou à un nouveau projet. Et enfin nous essaierons de déterminer quelles sont les perspectives d avenir d Ajax. 4/41

5 2. EVOLUTION DES TECHNOLOGIES WEB 2.1. Limites du fonctionnement standard du web Les sites Internet reposent sur le protocole de communication HTTP (HyperText Transfer Protocol). Le principe de ce protocole est le suivant : Le client envoie une demande au serveur. Le serveur traite la demande (calculs, récupération de données dans une base de données ). Le serveur renvoie la réponse au client. Ce fonctionnement est schématisé ci-dessous. Demande Client web (Navigateur) Attente Réponse Traitement Serveur Web Fig : Protocole HTTP Pendant tout le temps de traitement sur le serveur, le client doit attendre la réponse. A l apparition des sites Internet, tout le code était exécuté sur le serveur, ce qui impliquait un traitement du serveur, et donc un temps d attente à chaque action de l utilisateur sur un élément d une page Web. De plus, il était impossible de recharger une page partiellement, chaque clic générait donc un rafraîchissement complet de la page. Les inconvénients de ce principe sont nombreux : Le client est coupé dans son travail ou sa navigation à chaque action qu il effectue. La quantité de données qui transitent sur le réseau est élevée (la page complète à chaque action). Cela implique un long temps d attente. La longueur des temps d attente liés à cette technologie a depuis été réduite du fait de l augmentation de la vitesse des connexions Internet. L ergonomie des sites n est pas optimale, puisque les éléments de la page ne peuvent pas être dynamiques. De nombreuses personnes ont tenté d améliorer ce principe de fonctionnement au cours des années, en essayant d exécuter une partie du code sur le client pour limiter le nombre d allers-retours client serveur, ou en essayant de découper la page pour n en rafraîchir qu une partie. La partie suivante décrit les améliorations apportées au cours des années pour tenter d augmenter l interactivité des sites, et qui ont permis au Web de devenir celui que l on connaît actuellement. 5/41

6 2.2. Améliorations apportées au fil des années HTML A l origine du Web, dans les années 90, les pages des sites étaient écrites en langage HTML sans animation possible. Le HTML (HyperText Markup Language) est un langage balisé permettant d afficher un document. Il permet l affichage de texte et d images dans la page, ainsi que le positionnement des éléments en utilisant des tableaux. Le style peut être défini, mais de manière assez simpliste : couleur de fond ou image de fond du document, couleur et taille du texte, alignement des éléments (gauche, droite, centré). Il permet également de placer sur une page des «hyperliens», qui sont des liens permettant d accéder à d autres documents. Mais une page HTML peut uniquement être affichée pour être consultée, puis appeler une autre page via un lien. Elle n est jamais mise à jour pendant la navigation, l affichage est totalement statique CSS La première normalisation de CSS (Cascading Style Sheet) a été définie en 1996 par le W3C (1). CSS permet de définir des styles et de les appliquer aux différents éléments de la page (tableaux, zones de saisie, textes, images ), en utilisant l attribut «style». Mais le gros avantage est que ces styles peuvent également être mutualisés. Ils sont alors définis dans un fichier à part, et utilisés dans plusieurs pages d un site. Cela garanti une homogénéités des styles dans le site. Grâce à CSS, les pages ont un aspect beaucoup plus agréable, et les coûts de maintenance des sites sont moins importants. Cela permet également à une société ou une administration de réutiliser le fichier de styles dans tous ses sites, pour se créer une identité Javascript Dans les années 95 est apparu pour la première fois le Javascript. C est un langage de script, incorporé dans un document HTML. Ce langage a l avantage d être intégré au navigateur, et donc directement exécuté sur le poste client sans intervention du serveur. Une fois un script de ce type intégré à une page, un clic sur un des éléments permet une action sur la page sans aller-retour avec le serveur. Une action de l utilisateur peut par exemple changer le style du titre, ou exécuter du code plus poussé, comme un calcul en fonction de données saisies. Bien que ses détracteurs lui reprochent son manque de sécurité (le code est visible par les personnes qui accèdent au site puisqu il est exécuté directement sur le navigateur) et son manque de fiabilité (le comportement d un script peut différer d un navigateur à l autre), Javascript a été une grande avancée dans la dynamisation des pages Web. Il est aujourd hui très largement répandu : la plupart des sites, qu ils soient écrits en java,.net, PHP, ASP ou autre, comportent des éléments en Javascript pour accélérer les traitement et limiter le nombre d allers-retours entre le client et le serveur. Ajax s appuie fortement sur Javascript. (1) World Wide Web Consortium : Consortium international dont le but est de promouvoir l'évolutivité du Web et de garantir son interopérabilité. 6/41

7 XML Le XML (Extensible Markup Language) est un langage balisé qui permet la structuration de documents divers. Une structure XML peut être définie à l aide d un schéma permettant de valider un document XML. Si la structure d un document est bien définie, il peut facilement être interprété par un programme, d où l utilité de ce langage dans le monde du Web. XML permet donc l échange d informations structurées entre différents systèmes. Un service Web qui communique à l aide du langage XML peut être appelé par différentes applications, indépendamment de leur langage de développement. L application appelle le service Web en lui fournissant les paramètres nécessaires (au format XML), et récupère les données au format XML. Il ne reste ensuite plus qu à traiter ces données dont la structure est connue. XML est un élément très important dans la communication entre différents systèmes XSLT XSLT (extended Stylesheet Language Transformations) est un langage permettant la transformation d un fichier XML. Le fichier de sortie peut être du XML structuré différemment, mais aussi du HTML, un fichier texte. Ce qui est très intéressant dans le domaine du Web est la possibilité qu offre ce langage d appliquer une transformation sur un fichier XML pour en faire un fichier HTML. Cela veut dire que le résultat XML renvoyé par un service Web peut être affiché en HTML simplement en se servant d une transformation XSL. XSLT apporte bien sûr la possibilité de défini le positionnement des éléments dans la page, et leur style DOM et DHTML DOM (Document Object Model) a été introduit par Microsoft. La première version est apparue en DOM permet d accéder aux données de documents HTML ou XML en parcourant l arborescence du fichier. Un fichier HTML étant présenté sous la forme d une arborescence (une zone de texte à l intérieur d un tableau à l intérieur du corps de la page), il est facile grâce à DOM d accéder à ses différents éléments et de les manipuler. DHTML (Dynamic HyperText Markup Language) est un regroupement de technologies, composé de CSS, Javascript, et DOM. Le DOM permet d accéder facilement aux objets placés dans la page HTML, le Javascript permet de manipuler ces objets, et CSS permet de leur appliquer le style voulu. Avec ces 3 composantes, il est ainsi possible de mettre à jour dynamiquement une partie de la page, sans modifier le reste, et sans communiquer avec le serveur, donc instantanément. Le concept DHTML peut paraître très intéressant à première vue mais comporte certains inconvénients : DHTML est apparu en même temps que DOM, donc avant qu une norme ne soit définie. Pendant ce temps, Microsoft a travaillé sur l élaboration de DHTML de son côté, et Netscape a fait de même du sien. Il n y a eu aucune concertation entre les 2 éditeurs, si bien que l on se retrouve au final avec 2 versions de DHTML, une intégrée à Netscape, l autre à Internet Explorer, avec beaucoup de différences. Pour utiliser DHTML dans un site, il faut alors effectuer 2 développements différents pour gérer les 2 navigateurs de manière distincte, et savoir que les autres navigateurs ne pourront pas interpréter les 7/41

8 pages du tout. Au final, aucune norme n a été définie pour DHTML, malgré les pressions de Microsoft. DHTML a également un autre inconvénient, il ne permet pas de communiquer avec le serveur, ce qui limite les modifications dynamiques qui peuvent être faites dans la page. Il n est par exemple pas possible de récupérer les données d une base de données sans recharger toute la page. Pour ces raisons le DHTML ne s est jamais vraiment répandu XMLHTTPREQUEST XmlHttpRequest est un des éléments importants d, comme nous le verrons dans la partie suivante. Cet objet existe depuis longtemps dans Internet explorer sous la forme d un activex. Il était toutefois méconnu, et non disponible dans les autres navigateurs. XmlHttpRequest permet à du code exécuté sur le client (Javascript, ASP, ou autre) d appeler une autre page en arrière plan en lui passant éventuellement des paramètres, et de récupérer le code généré par cette page. XmlHttpRequest a été intégré aux différents navigateurs au cours des années, il est maintenant disponible dans la plupart d entre eux en standard (Firefox, Mozilla, Opera, Safari ). Il le sera également dans Internet explorer 7, il est en effet disponible sous forme d un ActiveX dans Internet explorer 6 ce qui complique un peu son utilisation comme nous le verrons par la suite. Un site qui utilise cet objet actuellement sera donc accessible par une très grande majorité de visiteurs. Mais certains, qui utilisent un navigateur ancien, ou qui n autorisent pas l exécution des ActiveX sur Internet Explorer n y arriveront pas. 8/41

9 3. FONCTIONNEMENT D 3.1. Définition Ajax signifie «Asynchronous Javascript And Xml». C est un paradigme : ce n est ni un outil téléchargeable sur Internet, ni un langage de programmation. On peut plutôt le définir comme une méthode de réalisation de sites Web qui s appuie sur d autres technologies (Javascript, XML, DOM, XmlHttpRequest, CSS ). Ajax permet la mise à jour dynamique et de façon asynchrone d une partie d une page Web, sans rafraîchir le reste de la page. Le fonctionnement «asynchrone» est la clé d Ajax, l utilisateur ne perçoit pas les opérations effectuées en arrière plan la navigation est ainsi plus fluide. Le nom est apparu pour la première fois en février 2005, dans un article publié par Jesse James Garrett (1) Fonctionnement Voici le schéma qui figure dans l article de Jesse James Garrett pour décrire le fonctionnement d Ajax a) L utilisateur effectue une action dans la page web b) Cette action est interprétée en Javascript, par une méthode qui va solliciter le moteur Ajax. c) Le moteur Ajax va interroger le serveur en fonction de la demande faite par l utilisateur, en passant les paramètres nécessaires. Il utilise pour cela XmlHttpRequest que nous avons vu dans la partie précédente d) Le serveur effectue le traitement nécessaire (calcul, récupération de données dans une base de données ), et renvoie la réponse au moteur Ajax sous forme XML e) Le moteur Ajax traite ce XML, et renvoie les informations à la page sous forme de HTML associé à un style CSS. f) Ces informations peuvent alors être affichées directement dans la page à l endroit voulu. Fig : Fonctionnement Ajax (1) L article complet de Jesse James Garret peut être consulté à l adresse suivante : Il est également fourni en annexe de ce document. 9/41

10 Pendant les étapes b) à e) décrites précédemment, l utilisateur ne perçoit pas le traitement effectué. Tout est fait en arrière plan, de manière asynchrone, l utilisateur peut pendant ce temps continuer à lire la page. Lorsque la réponse revient du serveur, la partie de la page qui est impactée se met à jour, toujours sans perturber la navigation de l utilisateur puisque le reste de la page est inchangé. Avec ce principe on se rapproche du fonctionnement d une application standard «non Web», il devient possible d utiliser une application en continu, sans temps d attente. A première vue, cela semble être une révolution dans la manière de fonctionner du Web. Mais les détracteurs d Ajax mettent en avant le fait que Jesse James Garrett ne décrit qu une combinaison de technologies déjà existantes depuis longtemps. On constate en effet que tous les composants d Ajax décrits dans le schéma ci-dessus n ont rien de nouveau. Il s agit simplement de mettre une étiquette sur un principe de développement. De plus, suite à l article de Jesse James Garrett, on a mis l étiquette «Ajax» sur d autres principes de fonctionnement que celui définit à l origine. Certains ont en effet soulevé le fait que certaines composantes qu il décrit ne sont pas indispensables pour arriver à un fonctionnement de type Ajax. On peut par exemple se passer d XML et renvoyer les données sous un autre format (HTML par exemple). On peut également noter que le Gmail de «Google», considéré comme un initiateur d Ajax, n utilise pas systématiquement l objet XmlHttpRequest. Lors de la navigation c est la technique des Iframes cachés qui est utilisée (méthode décrite dans la partie suivante). On se rend donc compte que le terme Ajax est parfois un peu flou. Il s agit de décrire le fonctionnement d une page web, ainsi que des principes à mettre en œuvre pour y arriver, mais ces principes peuvent être implémentés de plusieurs manières. En résumé on peut dire que le fonctionnement d une page «Ajax» respecte les points suivants : Elle ne se rafraîchit que partiellement lors d une action d utilisateur. Elle appelle le serveur (pour récupérer ou modifier des données dans une base de données par exemple). Elle fonctionne en mode asynchrone : l utilisateur fait une demande, le traitement est effectué en arrière-plan puis la mise à jour de la page est faite lorsque l on récupère la réponse Mise en oeuvre Pour arriver au fonctionnement décrit ci-dessus, il existe deux manières de procéder : L utilisation de cadres cachés. L utilisation de XmlHttpRequest. De nombreux ouvrages détaillent précisément la manière de mettre en place ces deux méthodes, nous allons donc voir sommairement comment elles fonctionnent sans toutefois rentrer dans les détails de mise en œuvre. Il est un peu délicat de déterminer si la première méthode peut ou non être appelée «Ajax». Beaucoup d ouvrages ou sites Internet différencient ces méthodes, en parlant de la méthode des cadres cachés et en les comparant à Ajax. D autres parlent d Ajax mis en oeuvre de deux manières différentes. (C est le cas par exemple de l ouvrage «Ajax : Pour développer des applications Web à interface riche» dont vous trouverez les références en annexe) 10/41

11 Méthode des cadres cachés La méthode des cadres cachés peut techniquement être implémentée depuis la sortie de Netscape Navigator 2.0 en septembre 1995! Ce n est toutefois qu en que les premiers articles ont dévoilé ce principe. On peut notamment citer un article paru sur le site d Apple à cette époque, et qui s intitule «Remote Scripting with IFRAME». Cet article est disponible à l adresse suivante : On considère que c est le premier article évoquant une méthode de type Ajax. Le principe des cadres cachés consiste en l intégration à une page html d un frame (cadre) dont la taille est à 0, ce qui permet de disposer d un cadre caché dans la page. C est à l intérieur de celui-ci que l on place le code Javascript qui va appeler le serveur. Le schéma ci-dessous décrit les différentes étapes du processus. Page WEB Cadre visible 1 Appel Javascript 4 Appel Javascript Cadre caché 3 Page WEB Serveur WEB 2 Requête Fig : Technique des cadres cachés 1) Suite à une action de l utilisateur, le cadre visible appelle en Javascript une fonction qui se trouve dans le cadre caché. 2) Le cadre caché envoie une requête au serveur Web, en lui passant les paramètres nécessaires. 3) Le serveur renvoie une page Web au cadre caché. Cette page contient les données répondant à la requête, ainsi que du code Javascript qui lui permettra de mettre à jour le cadre visible. 4) La page renvoyée prend place dans le cadre caché, et, lors de son chargement, appelle en Javascript une fonction contenue dans le cadre visible, en lui passant les paramètres nécessaires. Le cadre visible peut alors mettre à jour les éléments voulus dans la page. 11/41

12 Les étapes un à trois ne sont pas perçues par l utilisateur. En effet c est uniquement le cadre caché qui appelle le serveur et se rafraîchit intégralement. A l étape quatre, le cadre caché est entièrement rechargé, puisqu une nouvelle page prend place dans celui-ci. Dans toute page web, il est possible de définir une action au moment de son chargement. Dans le cas présent, il suffit de définir une fonction Javascript (cette fonction est déjà intégrée dans la page lorsqu elle est renvoyée par le serveur en étape trois), qui va appeler une autre fonction, contenu elle dans le cadre visible. Les cadres d une même page peuvent communiquer entre eux grâce à DOM que nous avons décrit précédemment. De la même manière, toujours grâce à DOM, la fonction Javascript du cadre visible peut modifier les éléments voulus dans la page, en se servant des données renvoyées par le cadre caché. Cette méthode est possible en utilisant un des deux types de cadres existants : Les «frames», qui sont les cadres standards HTML. Les frames existent depuis longtemps. Pour définir des frames dans une page, il faut la structurer d une manière particulière (utiliser un «frameset» qui englobe les «frames»), ce qui implique qu il faut le prévoir dès le début du développement. Les «Iframes», qui sont apparus peu après les frames, et présentent un avantage important par rapport à ces derniers : ils peuvent être positionnés dynamiquement dans une page pendant son exécution. La page ne nécessite dans ce cas pas de structure particulière. C est un plus dans le cas de l intégration de cette méthode à une page déjà existante. La technique des cadres cachés a l avantage de conserver l historique de navigation : les boutons «précédent» et «suivant» du navigateur restent actifs, ce n est pas le cas en utilisant XmlHttpRequest, comme nous le verrons dans la partie suivante. Il faut toutefois noter que l historique n est pas conservé par le navigateur «Firefox» dans le cas d utilisation d Iframes. Il faut nécessairement utiliser les frames standards. Cette méthode a plusieurs inconvénients. L un d eux est l absence de remontées en cas d erreurs. Etant donné que le code se trouve dans une partie cachée, l utilisateur n est pas informé en cas d erreur, la page restera figée sans afficher de message. Il est alors difficile de savoir ce qui se passe en arrière plan. De plus, la mise en œuvre de cette solution est assez compliquée. Il faut développer la page qui prendra place dans le cadre visible, avec les méthodes Javascript qui permettront d appeler le cadre caché, mais également les méthodes qui permettront de mettre à jour le cadre visible. Il faut également développer les pages qui prendront place dans le cadre caché, ce qui alourdit le développement. On peut encore signaler que les Iframes et frames ne sont pas conçues pour cet usage, et que beaucoup considèrent cette méthode comme du bricolage. Les puristes sont donc contre cette méthode et préféreront utiliser l objet XmlHttpRequest. 12/41

13 Méthode utilisant XMLHTTPREQUEST Comme nous l avons vu précédemment, XmlHttpRequest permet d appeler une page en Javascript, et de récupérer son contenu. Pour utiliser XmlHttpRequest en Javascript, il faut commencer par créer (instancier) un objet XmlHttpRequest. Cette étape peut paraître simple, il ne s agit en général que d une ligne, mais c est ici un peu plus compliqué que cela. En effet il faut gérer les différentes versions du navigateur. Pour Internet Explorer il faudra l instancier sous forme d un ActiveX, sous Firefox non. De plus l objet peut prendre des noms différents en fonction du navigateur (il existe actuellement cinq versions de l objet ActiveX en fonction de la version de Internet explorer). Ce problème est principalement dû au fait que le W3C n a pas normalisé cet objet. Une fois l objet créé, il faut : L initialiser. Lui spécifier quelle page il doit appeler. Lui spécifier quelle méthode il doit appeler à la fin de son traitement, quand la page a été récupérée. Lancer la requête. Dans la méthode appelée après le traitement, il faut vérifier le code du statut HTTP de la requête. Si le code est différent de 200, une erreur est survenue lors du chargement de la page, il faut en informer l utilisateur en se servant du code pour déterminer le type d erreur. Si le code est égal à 200, il suffit de récupérer le contenu de l objet (attribut «responsetext», ou «responsexml» si l on récupère du XML que l on veut ensuite traiter). Vous trouverez en annexe de ce document un exemple de méthode Javascript à implémenter pour créer un objet XmlHttpRequest et appeler une page. Voyons maintenant comment s organise la méthode Ajax, basée sur l utilisation de cet objet. Le schéma ci-après décrit les différentes étapes du traitement. 13/41

14 Partie cliente (Navigateur) Partie serveur 2 XHR 3 Serveur WEB Base de données 4 Méthode Javascript de mise à jour de la page 1 Evénement (clic bouton ) Fig : Technique XmlHttpRequest 1) En premier lieu, un événement est déclenché dans la page, par une action quelconque (clic sur un bouton, choix d un élément dans une liste.). 2) Une méthode Javascript est appelée. Celle-ci crée un objet XmlHttpRequest, lui spécifie la page à appeler et lance le traitement. 3) La page appelée sur le serveur peut simplement être un simple fichier texte à récupérer, mais c est en général une page qui contient du code permettant de générer un fichier XML ou HTML. Ce fichier peut contenir par exemple des données issues d une base de données. Le serveur, après traitement, renvoie donc ce fichier à l objet XmlHttpRequest appelant. 4) Une fois le fichier récupéré, l objet XmlHttpRequest appelle une méthode Javascript. Cette méthode vérifie le code d erreur, et traite les données récupérées, en modifiant les parties de la page qui sont impactées. L avantage de cette méthode par rapport à celle des cadres caché, est qu elle permet d écrire du code plus propre et plus efficace. Elle permet également de gérer correctement les erreurs, alors que la méthode des cadres cachés ne le permet pas. En revanche, il faut signaler que l objet XmlHttpRequest, s il est compatible avec la plupart des navigateurs ne fonctionnera pas dans certains cas : Navigateur trop ancien ou trop exotique (cas assez rare). Navigateur Internet Explorer, sur lequel les activex sont désactivés (si le navigateur a été paramétré en «sécurité haute»). L objet XmlHttpRequest sera intégré en natif à Internet Explorer 7, ce qui règlera ce problème. Il faut être conscient de ce risque si l on développe un site Internet qui s adresse à un large public. De plus l historique du navigateur est perdu, puisque c est une seule page qui fait toutes les opérations en Javascript. Les boutons «précédent» et «suivant» deviennent inopérants, ce qui est assez gênant pour les utilisateurs. 14/41

15 3.4. Avantages et inconvénients Nous allons tenter de lister les avantages et inconvénients d Ajax. La plupart sont communs à la technique du XmlHttpRequest, et à celle des cadres cachés, mais certains diffèrent Avantages Ajout de nouvelles fonctionnalités : Ajax ouvre la porte à des fonctionnalités que l on n aurait jamais imaginé pouvoir implémenter dans un site Web auparavant. Il devient possible de déplacer des zones d une page d un endroit à un autre, d afficher des informations provenant du serveur au survol d un élément ou de faire des recherches en arrière plan lorsque l utilisateur saisit des caractères au clavier (GoogleSuggest dont nous parlerons un peu plus loin dans ce document). Diminution de la charge réseau : du coté technique, on peut mettre en avant la diminution des données qui transitent par le réseau. Auparavant toute la page était envoyée à chaque événement. Maintenant elle est chargée au moment où l utilisateur arrive sur celle-ci, et ensuite ce sont seulement les données nécessaires qui sont récupérées lors des événements. Cela peut représenter un gros avantage pour les sites qui accueillent beaucoup d utilisateurs, ou ceux qui payent un hébergeur en fonction de la quantité de données échangées. Amélioration de l interactivité : c est le point essentiel d Ajax, qui permet à l utilisateur de naviguer presque comme s il était sur une application installée directement sur son poste. Les échanges entre le client et le serveur se font oublier puisqu ils s effectuent en arrière-plan. Du coup l utilisateur n est plus coupé dans sa navigation, a des temps d affichage beaucoup plus courts, et les sites qui lui sont proposés sont beaucoup plus riches qu auparavant (dynamisation des éléments des pages) Inconvénients Compatibilité : il ne faut pas oublier que pour une minorité de personnes les sites Ajax ne fonctionneront pas. Si l on ne peut pas accepter cette perte (manque à gagner pour un site d e-commerce par exemple), il faudra prévoir un double développement, avec une version qui n utilise pas Ajax pour que ces personnes puissent quand même accéder au site. Cela implique bien sûr un surcoût. Impossibilité d indexer les pages : dans un autre registre, il faut parler des robots d indexation, qui permettent aux moteurs de recherche de retrouver les pages en fonction des critères de recherche. Le fonctionnement est le suivant : le robot va trouver une page, indexer son contenu, et parcourir ensuite toutes les pages référencées par la première au travers d un lien hypertexte. Dans un site Ajax, le contenu initial des pages (état affiché lorsqu un utilisateur y accède) va donc être indexé. Mais dans une page Ajax, si un utilisateur effectue une action, ce n est pas une autre page qui est appelée, mais le contenu de la page courante qui change. D autres informations sont alors affichées, toujours sur la même page. Etant donné que les robots d indexation actuels ne savent pas appeler les méthodes Javascript, tout le texte de la page qui n est pas chargé initialement ne sera jamais indexé. On peut espérer qu avec l expansion d Ajax les moteurs de recherche perfectionneront leurs robots pour corriger cela, mais ce n est pas prévu pour l instant, étant donné la complexité de la mécanique à mettre en œuvre. 15/41

16 Cet inconvénient peut paraître anodin, mais un site qui offre des informations qui ne peuvent pas être trouvées par un moteur de recherche sera beaucoup moins consulté et perd une grande partie de son intérêt. C est un point important dont il faut être conscient. Gestion des favoris : de la même manière, puisqu une même page peut accueillir plusieurs contenus différents, il n est pas possible pour l utilisateur de se créer un «favori» pointant sur la page affichée. Si un favori est créé, c est la page dans son état initial qui apparaîtra lorsqu il sera ouvert. Perte de l historique : on peut également parler des problèmes d historique, dans le cas de l utilisation d XmlHttpRequest. Les utilisateurs peuvent être troublés de constater que leurs boutons «précédent» et «suivant», qu ils ont l habitude d utiliser, ne fonctionnent pas sur les sites Ajax. Complexité de mise en œuvre : c est l inconvénient le plus important qu il faut signaler. Beaucoup de code Javascript doit être écrit, Javascript étant un langage difficile à débuguer et peu explicite lorsqu une erreur survient. De plus certains bouts de code peuvent être interprétés de différentes manières en fonction du navigateur ce qui implique une bonne rigueur dans le développement (il faut penser à gérer tous les cas). Ce langage est critiqué par beaucoup de développeurs, car peu fiable et difficile à maintenir. Pour développer un site en utilisant Ajax, il est indispensable de faire appel à un développeur expérimenté, ce qui implique inévitablement un coût plus élevé. Difficulté de maintenance des applications : un autre inconvénient qui découle du précédent est la difficulté à maintenir une telle application. En effet des centaines, voire des milliers de lignes doivent être écrites en Javascript. Une application écrite par un développeur pourra difficilement être reprise par quelqu un d autre en vue de la corriger ou de l améliorer, en raison de sa complexité. Cette critique peut paraître sévère, mais l intérêt d Ajax est réel, puisque nous allons voir dans la partie suivante que les inconvénients les plus gênants disparaissent avec l utilisation d un framework Ajax lors du développement. 16/41

17 4. LES FRAMEWORKS 4.1. Définition Un framework est un ensemble de bibliothèques qui facilitent le développement. Un framework Ajax est donc un ensemble de classes, d outils, qui permettent le développement d une application Ajax plus simplement et plus rapidement. Il n est pas nécessaire de connaître précisément le fonctionnement de l outil puisqu il est piloté par les bibliothèques, qui assurent l interface entre le développeur et le système Ajax. Un framework Ajax peut par exemple créer l objet XmlHttpRequest en fonction du navigateur de l utilisateur. Cela permet au développeur de ne pas se soucier du problème des différentes versions de XmlHttpRequest vu précédemment. Il est possible de développer son propre framework, pour éviter d avoir à écrire plusieurs fois les même portions de code, mais il est encore plus simple d utiliser un framework existant. Beaucoup de framework sont disponibles en «open source» (1), il est donc possible de les adapter si besoin. Un framework (Ajax) peut être de différents types : Un ensemble de fichiers Javascript, contenant des méthodes déjà écrites que l on peut utiliser pour le développement (appelé framework «client»). Un ensemble de quelques composants Ajax évolués que l on peut intégrer à une application. Exemple : un composant sous forme d une zone de texte, qui effectue des recherches en arrière plan lors de la saisie de l utilisateur. Le développeur doit placer le composant fourni dans sa page, et son fonctionnement est ensuite géré par les méthodes du framework. Un cadre de développement complet, qui imbrique toutes les fonctionnalités Ajax. Avec ce type de framework, le développeur n a plus besoin de connaître le principe mis en œuvre pour le fonctionnement d Ajax. Il n a plus qu à appeler les méthodes que le framework lui propose. 1) Désigne un logiciel dont le code source peut être consulté, et modifié si besoin. En opposition avec les logiciel dont le code source est caché, pour lesquels seuls les fichiers nécessaires au fonctionnement sont disponibles. 17/41

18 4.2. Avantages d un framework Simplicité de mise en œuvre : l utilisation d un framework diminue très nettement la complexité de mise en œuvre d Ajax, l inconvénient le plus important que nous avons vu précédemment. Il n est plus nécessaire de connaître la mécanique d Ajax, relativement compliquée, pour développer un site. Il suffit d appeler les méthodes proposées par le framework. La gestion des différentes versions des navigateurs, qui doit être faite rigoureusement, n est plus à la charge du développeur, puisque le framework s en charge. Maintenance facilitée : les pages développées sont plus claires et mieux structurées puisque le code Ajax ne s y trouve plus. Il est alors plus facile de maintenir l application. De plus, si l on constate un «bug» dans le fonctionnement d Ajax, ou si l on décide de l améliorer, il suffit de modifier les classes fournies par le framework, sans que cela nécessite une retouche de toutes les pages. Ajout de fonctionnalités : un framework, en plus de simplifier la mise en œuvre du moteur Ajax, fournit dans bien des cas des composants évolués qui permettent l implémentation de fonctionnalités intéressantes, telles que le glisser déposer par exemple. Ces fonctionnalités n ont plus besoin d être écrites lors du développement de l application, puisqu elles sont déjà intégrées au framework. Ces avantages représentent un gain de temps et une diminution des compétences requises par le développeur, donc une diminution du coût du projet. On constate que le gros point faible d Ajax disparaît lorsque l on utilise un framework. Dans la majeure partie des cas, il sera donc nécessaire d avoir recours à un framework pour qu Ajax devienne intéressant Frameworks existants Il existe de très nombreux frameworks Ajax, si bien qu il est impossible de tous les étudier. Beaucoup d acteurs importants du Web se sont lancés dans le développement d un tel projet, dont Yahoo, Google, Microsoft, Adobe, IBM Chaque framework a ses spécificités, son mode de fonctionnement et sa mise en œuvre bien à lui. Ils s utilisent et s installent de manières différentes, et offrent des fonctionnalités diverses. La plupart sont fortement liés à un langage, bien que certains soient toutefois compatibles avec plusieurs technologies différentes. Voici quelques technologies (liste non exhaustive) pour lesquelles il existe des frameworks qui gèrent Ajax : Java,.NET, PHP, Ruby, Perl, Python, C++ Nous allons voir rapidement quelques framework qui sont compatibles avec plusieurs technologies, puis nous nous concentreront sur deux technologies qui se répandent beaucoup actuellement : Java et Microsoft.NET. C est également ces deux technologies qui comptent le plus de framework (au moins vingt pour.net, et quarante pour Java). Les frameworks sélectionnés sont volontairement assez différents les uns des autres pour permettre une vision assez large de ce qui peut exister. 18/41

19 Frameworks communs Les frameworks communs à plusieurs technologies sont appelés «frameworks coté client». Il s agit de librairies Javascript qui implémentent le fonctionnement d Ajax. Il suffit alors d appeler en Javascript les différentes méthodes offertes par ces frameworks. Le premier, XHConn est très limité et très simple, le second, OpenRico, est plus élaboré, et le 3 ème, Dojo est très complet. Cela donne ainsi un aperçu des grosses différences qui existent entre les frameworks. OpenRico et Dojo sont fréquemment cités dans les ouvrages qui portent sur Ajax, ainsi que sur Internet. Il sembleraient qu ils soient parmi les frameworks Ajax «coté client» les plus utilisés actuellement. XHConn ( Le but de XHConn se limite à simplifier l utilisation de l objet XmlHttpRequest. Lors du développement des méthodes Javascript on crée un objet XHConn, au lieu de créer un objet XmlHttpRequest. L avantage est de ne pas avoir à se soucier des différents navigateurs lors de la création de l objet. XHConn est compatible avec Internet Explorer, Mozilla, Firefox, Safari et Opera. Il se présente sous la forme d un seul fichier Javascript, en «open source» bien sûr, ce qui permet de le modifier si besoin. Il suffit d intégrer ce fichier au site Web pour l utiliser. Dans les faits ce framework sera très peu utilisé, compte tenu de son faible apport. Il pourra plutôt servir de base à une entreprise qui désire développer son propre framework OpenRico ( OpenRico a été développé par une entreprise américaine (Sabre Airline Solutions) qui fourni des solutions informatiques à des compagnies aériennes. Le terme «Rico» signifie «Riche» en espagnol, rapport aux interfaces riches. Ce framework fourni plusieurs éléments : Un moteur Ajax, pour communiquer avec le serveur en asynchrone, une librairie pour gérer le glisser déposer, une librairie pour gérer les animations, une autre pour les comportements. Il se présente sous la forme de deux bibliothèques Javascript gratuitement téléchargeables, et modifiables si nécessaire. Les méthodes fournies par ces bibliothèques sont prêtes à l emploi. Il suffit d intégrer les deux fichiers au site web, et d appeler les méthodes voulues pour utiliser le framework. DOJO ( Dojo est un des frameworks Ajax (côté client) les plus complets, c est donc également l un des plus lourds. Son développement a commencé dès 2004 (donc avant même que le terme «Ajax» apparaisse). De très nombreuses fonctionnalités sont disponibles, on peut noter par exemple qu il est possible, grâce à ce framework, de gérer les boutons «précédent» et «suivant» du navigateur, ainsi que les favoris. Un éditeur de texte est disponible, ainsi qu une librairie de glisser déposer, des librairies d animation, un calendrier, Cela implique que le nombre de fichiers disponible est beaucoup plus important que pour les frameworks précédent, et que son utilisation est un peu plus compliquée. La documentation semble toutefois assez complète, et le téléchargement et l utilisation sont gratuits. 19/41

20 Frameworks Java Java est une technologie très utilisée. C est un langage «open source» orienté objet. Il est gratuit et utilisable aussi bien sur une machine Windows que Linux Des frameworks (non Ajax) permettent depuis longtemps d utiliser Java pour faire du développement Web : des composants fournis par le framework sont placés dans les pages, et ces composants appellent du code java sur le serveur lorsqu ils sont actionnés (bien sûr, sans Ajax, c est toute la page qui est rafraîchie lors de l appel des méthodes). La liste des frameworks Ajax utilisables avec Java est impressionnante. Parmi ces frameworks, nous allons en voir 3 : DWR, qui se greffe par dessus un framework java «Web», Google Web Toolkit, qui est un framework complet, gérant à la fois Ajax et les composants Web, et ATF (également appelé «OpenAjax») qui est encore à ses débuts, mais qui semble très prometteur. DWR ( DWR (Direct Web Remoting) est l un des frameworks Ajax pour Java les plus répandus (sans doute même le plus répandu). Il est gratuit et fourni en «open source». DWR permet, à partir d une méthode Javascript, d appeler directement les méthodes Java qui se trouvent sur le serveur (en asynchrone bien sûr) Il se greffe par dessus un framework Web, comme struts par exemple, qui est l un des framework Java «Web» les plus répandus. Dans une configuration Java avec Struts et DWR, c est Struts qui se charge de générer les composants Web et les pages, et DWR permet d appeler les méthodes Java du serveur à partir d une méthode Javascript. La documentation est très complète, et l installation relativement simple, la prise en mains de cet outil semble assez rapide. Google Web Toolkit ( Google, que l on considère comme un précurseur dans le domaine d Ajax, a publié en 2006 son propre framework. Cet outil permet de concevoir les pages Web, en y intégrant des composants fournis par le framework (boutons, zones de texte..) Tout le développement se fait en Java, sans saisir aucune ligne de Javascript. Ensuite c est le framework qui se charge de générer le code Javascript, à partir du code Java écrit par le développeur. Comparé à DWR, qui se greffe sur un framework existant, Google Web Toolkit est un framework complet, qui gère lui-même tous les composants Web, ainsi que la technologie Ajax. ATF ( Ajax Toolkit Framework est un projet très récent, mené en commun par plusieurs sociétés telles que IBM, Borland, Zend, Oracle Ce framework s intègre totalement à Eclipse, l environnement de développement le plus utilisé par les développeurs Java. C est un atout important. Il s appuie sur des bibliothèques existantes, telles que Zimbra, Dojo et Rico. Ce projet va peut-être vers une normalisation des syntaxes d Ajax. Pour cela il aura l appui des acteurs cités précédemment, qui ont une énorme influence sur le Web. 20/41

21 Frameworks.NET Le framework Microsoft.NET 1.0 est apparu en Ce framework permet de faire du développement Web. De nombreux composants sont fournis (zones de texte, boutons, grilles de données, ). L environnement.net s est très vite répandu, il est actuellement un des plus utilisé dans les nouveaux projets Web. Nous allons donc étudier 3 frameworks Ajax qui s intègrent au framework Microsoft.NET. Le premier étudié sera celui que propose Microsoft, et qui s intègre donc parfaitement dans l environnement de développement.net. Nous verrons également le framework Ajax.net qui est assez complet, puis les composants, «Dart PowerWeb LiveControls», seul framework payant parmi ceux étudiés dans ce document. ASP.NET ( Microsoft a commencé le développement de son framework Ajax en Son nom de code était «ATLAS» à l origine, il a été renommé par la suite «ASP.NET Ajax». Il est gratuitement téléchargeable, mais uniquement en version beta pour l instant. L utilisation est très simple. Il suffit de télécharger et d installer le fichier fourni. Dès lors, en ouvrant Microsoft Visual Studio 2005 (une version «express» est téléchargeable gratuitement), on voit qu un type de projet «Ajax» est présenté. Si on le choisit, les composants Ajax sont disponibles dans le projet et peuvent être positionnés dans les pages. On peut alors les découper en autant de «zones» que nécessaire, et choisir lesquelles sont mises à jour lors de chaque action effectuée par l utilisateur. Pour l instant ce framework n est pas très utilisé, étant donné qu une version définitive n est pas encore sortie. Mais il y a fort à parier que ce sera par la suite l un des plus implémentés dans les nouvelles applications, surtout du fait qu il est développé par le même éditeur que celui du framework.net. Il faut cependant signaler que «ASP.NET Ajax» nécessite le framework.net 2.0 pour fonctionner (framework apparu en 2005), alors que la majorité des applications.net existantes utilisent encore la version 1.1. Il sera donc plus utilisé dans les nouveaux projets que dans les projets existants..net ( Ajax.NET est un peu pour.net ce qu est DWR pour JAVA. Il permet, à partir d une méthode Javascript qui se trouve dans la page, d appeler les méthodes qui se trouvent sur le serveur. Ce framework, contrairement à celui de Microsoft, fonctionne aussi bien avec la version 1.1 du framework.net qu avec la version 2.0. Il est téléchargeable gratuitement. DART POWERWEB LiveControls ( Ce framework est fourni par la société américaine Dart Communications. C est un ensemble de composants Ajax, tels que des cases à cocher, boutons, grilles de données, Images Ces composants peuvent prendre la place de ceux fournis en standard par Microsoft, et fonctionnent en asynchrone, sans rechargement complet de la page. Ces composants sont compatibles avec toutes les versions du framework.net. Mais ils ne sont pas disponibles gratuitement, il faudra payer entre 500 et 5000 dollars en fonction de la version choisie pour pouvoir télécharger et utiliser cette bibliothèque de composants. 21/41

22 Tableau récapitulatif Nom Type Techno Prix Editeur Maturité Fonctionnalités XHConn Client Tous Gratuit Brad Fults Stable Manipulation objet XmlHttpRequest OpenRico Client Tous Gratuit Sabre Airline Solutions Stable Glisser-déposer Moteur Ajax Animations DOJO Client Tous Gratuit Alex Russell Stable Très nombreuses Composants, gestion historique DWR Serveur Java Gratuit GetAhead Stable Appel méthodes Serveur en Javascript Google Web Toolkit Serveur Java Gratuit Google Stable Composants Génération code Javascript à partir de Java ATF Serveur Java Gratuit IBM, Oracle, Borland, Zend, Beta Nombreuses : Composants, debugage du Javascript... ASP.NET Serveur.NET Gratuit Microsoft Beta Rechargement partiel d'une page.net Serveur.NET Gratuit Michael Schwartz Stable Appel méthodes Serveur en Javascript DART Serveur.NET $ Dart communications Stable Composants évolués Fig : Comparatif frameworks 22/41

23 5. INTEGRATION D A UN PROJET Cette partie a pour but d aider une entreprise dans la mise en œuvre d Ajax. Dans un premier temps, il faut se décider quant à l utilisation ou non d Ajax dans le projet visé. Ensuite, il s agit de déterminer quel framework sera le plus intéressant. Et enfin, il faut savoir comment mettre Ajax en œuvre, tant au niveau développement, qu architecture Faut-il utiliser Ajax dans un projet? Avant de se lancer dans l aventure Ajax, il faut bien se poser la question de l utilité de cette technologie dans le projet envisagé, qu il s agisse d un nouveau projet, ou d un projet existant que l on voudrait faire évoluer. L erreur à ne pas faire serait d intégrer Ajax à un projet pour des raisons purement marketing, c est à dire pour suivre le mouvement qui incite à se lancer dans Ajax. Les avantages d Ajax sont nombreux, mais il faut se demander s ils seront vraiment exploités dans le projet envisagé. D une manière générale, Ajax améliore l ergonomie et l interactivité, et permet des fonctionnements jusqu alors difficilement envisageables sur un site web. Dans la plupart des projets, cela représentera donc une amélioration, plus ou moins importante. Mais il faut mettre cette amélioration en balance avec les inconvénients d Ajax, et se poser certaines questions avant de pouvoir prendre une décision Quel est le type d application que l on veut développer? Mise à disposition de contenu : Ajax n aura pas vraiment d intérêt. L utilisateur lit un document, et va ensuite en consulter un autre et ainsi de suite. Cela ne pose pas de problème dans ce cas que la page soit rechargée en totalité. De plus, les sites Ajax n étant pas correctement indexés, Ajax sera plus un frein qu un atout pour ce type de site. Site de e-commerce : l avantage peut se trouver au niveau de certaines fonctionnalités telles que l élaboration d une configuration complète d un pc, avec le prix de la configuration qui se met à jour à chaque modification d un élément, sans rechargement. Cela peut être également au niveau de la facilité et rapidité de navigation. Le site peut se démarquer de la concurrence en diminuant le temps nécessaire pour passer une commande, et en améliorant l ergonomie et l interactivité du site. Application «professionnelle» : si l application est assez «basique» avec des objets (clients, fournisseurs, matériel, ) qui n ont que quelques attributs, cela n aura pas vraiment d intérêt. Par contre si les attributs sont nombreux, et nécessitent des sélections d éléments extérieurs, Ajax permettra de diminuer le nombre de rechargement de la page et représentera un gain de temps pour l utilisateur. Site d entreprise : un site plus interactif et agréable à utiliser peut permettre de gagner des clients, particulièrement pour les entreprises informatiques qui montreront ainsi leur savoir-faire. Pour les entreprises non informatiques ce n est pas forcément utile. Site «particulier» : certaines applications proposent des fonctionnalités particulières, qui ne peuvent être envisagées qu avec Ajax. C est le cas des nouvelles applications «Riches» qui nécessitent une interaction forte avec l utilisateur. Dans ce cas la question de l utilisation ou non d Ajax ne se pose pas. Si l on décide de développer l application, Ajax y sera nécessairement intégré. 23/41

24 Quels sont les utilisateurs visés? Utilisateurs occasionnels : si le site est un site de «passage», sur lequel les utilisateurs viennent simplement consulter une information, l utilisation d Ajax ne sera pas utile. Ajax devient intéressant lorsque l utilisateur effectue des actions dans une page. S il ne fait qu afficher la page, pour en consulter le contenu et ensuite quitter le site, Ajax n apporte rien. Utilisateurs réguliers : si l application est utilisée toute la journée pas certaines personnes (sites professionnels essentiellement), l utilisation d Ajax sera intéressante. Une page sera un peu plus longue à charger la première fois, en raison du code Javascript qui s y trouve, mais l utilisateur pourra ensuite l utiliser pendant une certaine période sans avoir à la recharger entièrement lors de ses actions. L utilisation sera plus agréable, et cela représentera également un gain de productivité puisque les temps d attente seront nettement diminués Peut-on accepter les désavantages d Ajax? Nous avons vu précédemment qu Ajax a un certain nombre de désavantages. Même si l utilisation d un framework permet de se débarrasser de certains, il reste tout de même des limites dont il faut être conscient : L indexation des pages Ajax par les moteurs de recherche est impossible, les favoris ne peuvent plus être utilisés (sauf avec certains frameworks), les boutons «Précédent et suivant» ne fonctionnent plus (sauf avec certains frameworks), certains navigateurs ne supportent pas Ajax et ne peuvent pas afficher ces pages, un projet Ajax nécessitera plus de temps de développement qu un projet standard. Ce temps supplémentaire est moins important si l on utilise un framework, mais il faut tout de même le prendre en compte. Si l un de ces inconvénients est inacceptable dans le cadre d un projet, il faudra soit renoncer à utiliser Ajax, soit limiter son utilisation à certaines pages dans lesquelles ces désavantages sont moins un problème pour le projet. Il faut cependant noter que si Ajax apporte un vrai plus au site et qu il est très important de pouvoir l utiliser, il sera toujours possible de développer deux versions des pages, une avec Ajax, l autre sans, pour les navigateurs qui ne peuvent pas interpréter les pages Ajax. Bien sûr cela représente alors un réel surcoût S agit-il d un projet existant ou d un nouveau projet? Projet existant : si un manque est constaté dans un site ou une application Web existante, la question d y intégrer ou non Ajax se posera. Il est plus facile de prendre une décision pour un projet existant que pour un nouveau projet. En effet la population d utilisateur/visiteurs est connue, leurs habitudes également. Il sera assez facile de voir ce qu Ajax peut apporter à l application, étant donné qu elle est déjà utilisée. Il suffit de regarder si certaines pages sont trop lourdes à utiliser, si des rechargements gênent la navigation, si des fonctionnements pourraient être plus faciles avec des composants Ajax. Les utilisateurs habituels (pour un site intranet) pourront donner leur avis sur le site existant, et pointer du doigt les parties qui manquent 24/41

25 d ergonomie. Si le site fonctionne correctement, et que rien n est gênant durant la navigation, il n est pas nécessaire d envisager l évolution vers Ajax. Concernant le problème de compatibilité des navigateurs, on peut savoir facilement quelle proportion d utilisateurs ne pourra plus accéder au site s il évolue vers une solution Ajax : Pour un site intranet, le problème de compatibilité ne se pose pas. En règle générale tous les postes ont la même version de navigateur, sinon il suffit d installer le bon sur les postes des utilisateurs du site. S il s agit d un site Internet, il suffit d étudier les logs du serveur web, pour étudier la proportion de personnes qui utilisent le site et dont le navigateur ne supporte pas Ajax. Il faudra ensuite évaluer si la proportion de «pertes» est acceptable, en sachant également que la proportion de navigateurs non compatibles (en général des navigateurs plus anciens) va forcément diminuer au fil des années. Nouveau projet : dans un nouveau projet, il est plus difficile d évaluer les avantages qu Ajax représentera. Il est également plus difficile d évaluer la population d utilisateurs (pour les sites Internet de passage). Il est très difficile de savoir quelle proportion d utilisateurs ne pourront pas utiliser le site en raison de leur navigateur non compatible. Il faut quand même savoir que la plupart des navigateurs actuels sont compatibles, et qu avec le temps de moins en moins d utilisateurs seront incapables d accéder à un site Ajax Faut-il utiliser Ajax? Le graphique ci-dessous récapitule les arguments que nous venons de voir, et qui font pencher la balance vers une utilisation, ou une non utilisation d Ajax. Bien sûr ce ne sont que des éléments d aide à la décision. Il existe une multitude de critères qui permettront de se décider quant à l utilisation ou non d Ajax, et l on ne peut donc pas étudier tous les cas. Il faudra donc au final étudier chaque projet au cas par cas. Mise à disposition de contenu Site riche, fonctionnement particulier Application professionnelle Site d une entreprise Site de commerce électronique Non Oui Soc. non info Soc. info Simple Complexe Non Site de passage Usage intensif Site de passage Usage intensif Inconvénients Acceptables Inconvénients Inacceptables Non A définir A définir Oui Oui Non Fig : Faut-il utiliser Ajax? 25/41

26 5.2. Choisir un framework Dans certains cas, aucun framework ne sera utilisé dans le cadre du projet, mais nous avons vu dans la partie qui leur est dédiée que, bien que ce ne soit pas indispensable, il est fortement conseillé d en utiliser un. Une grosse entreprise peut envisager de développer son propre framework, mais étant donné la quantité et la diversité des frameworks déjà existants, cette solution paraît inutile, surtout compte tenu du coût qu il faudrait y consacrer. Nous allons donc nous pencher sur la solution qui sera la plus souvent retenue, l utilisation d un framework existant. Il est impossible de conseiller de prime abord un framework qui sera parfait pour tous les projets. On ne peut pas dire qu il y ait un framework Ajax qui soit le meilleur. Voici donc quelques critères qui permettront d orienter une entreprise dans son choix Le langage Lors de l analyse d un projet, le langage dans lequel il sera écrit est décidé avant tout. Le framework Ajax devra donc être choisi en fonction du langage du projet (PHP, JAVA,.NET, ). Ainsi la liste de frameworks utilisables est fortement diminuée. S il n existe aucun framework adapté à la technologie utilisée pour développer le projet, il faudra se tourner vers un framework «côté client», développé uniquement en Javascript, et donc indépendant de la technologie utilisée pour le projet. Un framework «côté client» peut également être utile si l entreprise utilise plusieurs technologies, mais veut utiliser le même framework Ajax pour tous ses projets. En règle générale il est préférable d utiliser un framework «côté serveur» adapté au langage s il en existe. Les possibilités offertes sont plus importantes, et la mise en œuvre est plus simple. Le développeur n a souvent même pas besoin de maîtriser Javascript pour utiliser ce type de framework La prise de risque La maturité : il est conseillé en règle générale d utiliser un framework qui est déjà bien implanté et suffisamment documenté. Un framework qui en est à ses début peut s avérer avoir beaucoup de qualités, mais il est risqué de l utiliser, dans la mesure où son développement peut très bien être arrêté avant que le framework soit stable. Dans ce cas il faudrait se tourner vers un autre framework par la suite, ce qui représente un coût très important. Il est donc préférable d utiliser un framework qui a déjà fait ses preuves, et qui est suffisamment utilisé pour être sûr qu il ne sera pas laissé à l abandon par ses créateurs. L éditeur : de la même manière, si l on choisit un framework développé par une ou des sociétés importantes, le risque de voir le framework abandonné est moins important. Par exemple le framework ATF, mené par IBM, Borland et intégré à Eclipse a de très fortes chances de devenir bientôt l un des plus utilisés pour Java. Il serait très surprenant que son développement soit mis de côté. Il en est de même pour le framework développé par Microsoft, qui est encore en version beta mais qui s imposera sans doute comme l un des plus utilisés pour.net. A partir de ces deux critères, il faut évaluer le risque que représente l utilisation de chaque framework. 26/41

27 Projet existant ou nouveau projet Le framework retenu ne sera pas forcément le même pour un nouveau projet que pour un projet existant. Certains frameworks sont très complets et pratiques à utiliser, mais peuvent difficilement être intégrés à un projet existant. En Java, nous avons vu que certains peuvent être ajoutés par dessus le framework Web (struts ), alors que d autres assurent en même temps la gestion des composants Web, et du fonctionnement d Ajax. Dans ce dernier cas, il faudrait re-développer toute l application pour y intégrer le framework. En.NET ce n est pas le cas..net est le framework Web, et les frameworks Ajax viennent nécessairement se greffer par dessus Les fonctionnalités attendues Il faut savoir si l on veut seulement pouvoir recharger une partie de la page sans recharger le reste, ou si l on a besoin de fonctionnalités vraiment évoluées, qui nécessitent des composants divers. Dans le premier cas il faudra se tourner vers un framework assez léger, qui sera plus simple à appréhender pour les développeurs, et qui n alourdira pas trop le poids des pages. Sinon il faudra se tourner vers un framework plus riche, mais qui sera un peu plus long à mettre en place, et qui alourdira les pages. Certains frameworks proposent en effet des fonctionnalités assez évoluées (par exemple DOJO qui permet de gérer les boutons «précédent» et «suivant» du navigateur). Il faut étudier les fonctionnalités offertes par chaque framework, et voir lesquelles sont utiles ou nécessaires pour l application envisagée Les performances Un des critères qui peut être important si le site est très visité est le poids des pages. Nous avons vu qu Ajax ajoute du code Javascript dans les pages, ce qui peut les alourdir, légèrement ou de manière plus importante. En règle générale, ce critère est lié aux fonctionnalités que proposent le framework. Plus les fonctionnalités offertes sont nombreuses, plus la quantité de Javascript est importante, plus les pages sont lourdes à charger. Si les fonctionnalités requises par le site sont minimes, il est donc préférable de ne pas utiliser un framework trop riche Le coût Un autre critère de choix est le coût. Même si beaucoup de frameworks sont gratuits, certains sont payants et peuvent apporter un plus. Des composants très riches peuvent être achetés, reste à déterminer en fonction des cas si l investissement est vraiment utile et s il y aura un retour sur investissement par la suite La formation Les développeurs devront bien sûr apprendre à utiliser le framework. Certains frameworks proposent une documentation très complète, d autres beaucoup moins. Des centres de formation pourront initier les développeurs aux techniques d Ajax et les former à certains framework. Il ne faut pas espérer trouver une formation pour n importe quel framework, mais c est possible pour les plus répandus. On peut par exemple trouver des formations à DWR pour Java, et à ASP.NET Ajax pour.net. Ces formations se font en général sous la forme de stages d une journée ou plus. 27/41

28 Beaucoup de développeurs savent se former d eux-mêmes aux nouvelles technologies. Les stages de formation, souvent très coûteux, peuvent s avérer utiles mais ne sont pas forcément nécessaires, surtout pour un développeur expérimenté. Il faut dans tous les cas s assurer que la documentation soit suffisamment riche pour que les développeurs parviennent à se familiariser rapidement avec le framework La prise de décision Les critères de choix d un framework Ajax sont nombreux. Il faudra donc prendre le temps de les étudier avant de se décider. Toutefois, certains frameworks très répandus actuellement, tels que DWR pour Java sont des valeurs sûres. Ils offrent à la fois une prise de risque minimum, une documentation correcte, des formations, et sont de plus gratuits. Pour une utilisation simple, ces frameworks conviendront dans la majorité des cas. Si le projet nécessite des fonctionnalités particulières, il faudra se tourner vers des framework plus «exotiques» et parfois payants, pour trouver les composants appropriés. Le schéma ci-après décrit la démarche à suivre pour se décider entre les frameworks vu dans la partie suivante. Bien sûr il y aurait plus de questions à se poser que celles qui figurent ici, si l on examinait une liste de frameworks plus importante. XHConn étant très limité, il pourra servira de base au développement d un framework plus complet. Sinon la technologie utilisée permet d appliquer un premier filtre. On se retrouve alors avec 3 frameworks dans chaque catégorie. Voici comment procéder pour faire un choix : Java Si l application existe déjà, on utilisera DWR qui se greffe par-dessus un framework Web existant. Les autres demanderaient un développement trop important, puisqu ils intègrent tout le fonctionnement Web en plus du fonctionnement Ajax. Si l on développe une nouvelle application, ATF serait une bonne alternative, mais uniquement si l on accepte de prendre un petit risque. En effet ce framework va sans doute se répandre, mais il n est pas encore totalement finalisé. SI la prise de risque n est pas acceptable, on étudiera les fonctionnalités de Google Web Toolkit et de DWR plus en détail, ce qui permettra de choisir entre ces deux frameworks..net Si l application nécessite des fonctionnalités particulière (zone de texte très évoluée avec une partie des fonctionnalités existantes dans Word par exemple), et que l entreprise est prête à payer la licence, c est le framework fourni par DART qui sera retenu. Sinon on penchera pour ASP.NET Ajax (Microsoft) mais seulement si deux conditions sont réunies : l application ne doit pas être développée avec.net 1.1, incompatible avec ASP.NET Ajax, et il faut prendre un petit risque, ce framework étant encore en beta. Si l une de ces deux conditions n est pas remplie, on penchera alors vers Ajax.Net. Autre technologie pour laquelle il n existe pas de framework Ajax Il faudra choisir entre la simplicité et la rapidité de OpenRico, et la puissance de Dojo. 28/41

29 Volonté de développer son propre framework en s appuyant sur un framework existant? Oui Non XHConn Existe t il des frameworks serveur pour la techno choisie? Non Oui Simplicité et performance, ou fonctionnalités nombreuses? Techno utilisée? Autre Simplicité OpenRico Fonctionnalités DOJO Java.Net Etudier la liste des Fmrk existants Application déjà existante? Nécessité d avoir des fonctionnalités particulières, et prêt à payer? Oui Non Oui DWR Oui Prise de risque acceptable? Non DART Application existante, et développée en.net V1.1? ATF Google Web Toolkit ou DWR, étude des fonctionnalités les plus adaptées au projet Non Prise de risque acceptable? Oui Ajax.Net Non Oui Ajax.Net ASP.Net Ajax (Atlas) Fig : Choisir un framework Ajax 29/41

30 5.3. La mise en œuvre Cette partie décrit les différents éléments à prendre en compte lors de la mise en œuvre d Ajax dans un projet. Elle décrit la structure de l équipe de développement du projet, puis l architecture à mettre en place pour pouvoir mettre à disposition un site Ajax, et les précautions à prendre pour améliorer le plus possible le confort de l utilisateur final Equipe de développement En partant du principe que la ou les personnes qui vont développer le projet connaissent bien le langage dans lequel il sera écrit (PHP, Java..), il faudra les former à Ajax, et plus particulièrement au framework retenu, si le choix d utiliser un framework est fait. Dans certains projets, on pourra définir qu une personne est responsable de la partie Ajax. Pour cela, il faut que le fonctionnement Ajax soit implémenté «côté client», en Javascript donc, ou côté serveur avec un framework qui se greffe par-dessus le framework Web. Si l on prend un framework comme ATF, qui assure à la fois le fonctionnement Web et le fonctionnement Ajax, il sera difficile, voire impossible de dissocier Ajax du reste du développement. Dans la plupart des cas c est la totalité de l équipe de développement qui devra maîtriser le fonctionnement d Ajax, ou du framework retenu. Chacun pourra ainsi développer sa page en intégralité, ce qui est plus intéressant que de faire développer une page par une personne, pour ensuite la faire modifier par une autre. Une fois cette décision prise, il s agira de former les personnes qui utiliseront Ajax soit au fonctionnement d Ajax lui-même, soit au framework retenu. Si l on retient le premier cas, il faudra aux développeurs une formation assez longue et une parfaite maîtrise de Javascript pour pouvoir implémenter un fonctionnement Ajax. La formation risque alors d être assez coûteuse. L utilisation d un framework existant est donc plus intéressante, puisque la formation sera moins longue et moins compliquée. La formation peut consister en un stage dans un centre, ou simplement en quelques jours d autoformation, pour étudier la documentation du framework et se familiariser avec son fonctionnement. Le coût sera donc modeste, une ou deux journées devraient suffire à un développeur pour se familiariser avec un framework s il est correctement documenté. Il est quand même préférable qu une ou plusieurs personnes maîtrisent le fonctionnement d Ajax, au moins approximativement, pour bien comprendre la cinématique mise en place par le framework. Javascript devra également être maîtrisé par certaines personnes, dans le cas où le framework devrait être modifié légèrement pour être adapté aux besoins Architecture L architecture à mettre en place pour pouvoir installer un site Ajax sur la plateforme de production d une entreprise est identique à celle à mettre en œuvre pour une application Web sans Ajax. C est ce qui fait la force d Ajax. Il faudra donc un serveur Web et un serveur applicatif, et éventuellement un serveur de bases de données comme pour une application standard. Le schéma ci-après représente cette architecture. 30/41

31 Fig Architecture Ajax A partir de cette architecture standard, une application Ajax peut être développée et installée sans problème. Si l on n utilise pas de framework, ou un framework côté client, rien n est à installer sur le serveur. S il s agit d un framework «serveur», il faudra dans certains cas installer des librairies sur le serveur IIS (Windows) ou Tomcat (Linux). En ce qui concerne la configuration matérielle, les serveurs n auront pas plus de charge à supporter que pour une application web standard. Au contraire, étant donné que les allers-retours entre le client et le serveur sont moins importants dans une application Ajax, et qu une partie du code est exécutée côté client, la charge des serveurs Web et applicatifs est moindre par rapport à une application Web standard. Les serveurs déjà utilisés par l entreprise pour ses sites non Ajax pourront donc être utilisés sans modification. Concernant les clients, il faut bien sûr qu ils supportent Ajax, c est à dire que le navigateur puisse interpréter l objet XmlHttpRequest. Ils nécessitent donc au choix : Internet explorer 5 ou 6 avec les ActiveX autorisés, Firefox, Mozilla, Safari, ou Opera. Il faudra également que la configuration des clients soit suffisante. En effet, une partie du code est à présent exécutée en Javascript sur le client. Le serveur est moins chargé, mais le client a plus d opérations à effectuer. Bien sûr la configuration requise reste peu élevée, il est inutile de posséder un ordinateur dernier cri pour utiliser un site Ajax. Mais dans une entreprise, des personnes sont habituées à utiliser des sites non Ajax à partir de postes anciens, largement suffisant pour cet usage. Si un site est modifié pour y intégrer Ajax, et que beaucoup de code est exécuté côté client, il faudra peut-être investir dans des ordinateurs un peu plus performants, pour éviter les temps d attente dus à la lenteur du poste client. 31/41

32 Précautions à prendre Il faut essayer de respecter certaines règles lors du développement du projet. La première est d utiliser Ajax uniquement aux endroits où c est utile. Développer tout le site en Ajax est bien souvent inutile. Comme Ajax présente certains inconvénients, que nous avons déjà décrits, il vaut mieux ne l utiliser que dans les pages où c est utile. Il faut également être conscient qu Ajax est encore peu répandu actuellement, et qu il ne faut donc pas que les applications perturbent trop les utilisateurs habitués au fonctionnement Web standard. Par exemple, lors d un événement généré par l utilisateur, le code est exécuté en arrière plan. En général la partie de page concernée est rafraîchie instantanément ou presque. Mais si le traitement est un peu plus long, l utilisateur ne verra pas qu une opération est en cours, puisque tout se passe en arrière plan. Dans une application Web standard, la barre du navigateur indique qu un chargement est en cours, ce n est pas le cas dans une application Ajax. Il faut donc penser à afficher un message d attente pendant la durée du traitement. De la même manière, si l on ne rafraîchit qu une partie de la page, cela peut parfois être difficile à percevoir si c est très rapide. Il faut donc indiquer à l utilisateur qu une partie a été modifiée (un cadre qui apparaît autour de la partie concernée par exemple). Il faut faire attention à ce point dans une nouvelle application, mais surtout dans le cadre de l évolution d une application existante, dans laquelle les utilisateurs sont habitués à un certain mode de fonctionnement, et risquent de ne pas comprendre le nouveau. S il s agit d améliorer une application Internet existante, il faut également être conscient que certains utilisateurs ne pourront pas utiliser l application Ajax. Si c est possible, il faut donc laisser à disposition l ancienne version de l application, qui prendra automatiquement le relais si le navigateur de l utilisateur ne supporte pas Ajax. 32/41

33 6. CONCLUSION : PERSPECTIVES D AVENIR 6.1. Utilisation d à l heure actuelle Ajax est une technologie assez récente. Son utilisation est donc pour l instant relativement limitée. Voici toutefois 3 applications développées par Google, qui utilisent Ajax : GMail ( Le webmail développé par Google est l une des premières applications développées avec Ajax. Lorsque l utilisateur se connecte au site, tout est effectué en Ajax. A chaque opération de l utilisateur, seule une partie de la page est rechargée. Les clics de l utilisateur ont un effet immédiat sur l interface. Pour ne pas perturber l utilisateur, une barre de défilement s affiche à l écran lorsque la durée de traitement est plus importante. Beaucoup se sont demandés en utilisant GMail comment il était possible d arriver à un tel fonctionnement. C est ce qui a fait connaître Ajax à ses débuts. GoogleMaps ( Cette application permet de visionner des cartes. Ceci était possible depuis quelques années déjà, mais l utilisation était très désagréable. Lorsque l on voulait consulter une autre partie de la carte, non affiché à l écran, il fallait cliquer sur une flèche de défilement dans le sens voulu, et toute la carte était rechargée, et ainsi de suite. Avec GoogleMap, lorsqu une carte est affichée à l écran, le système Ajax charge en mémoire des parties invisibles tout autour de la partie visible. Ainsi, lorsque l utilisateur veut se déplacer sur la carte, l effet est immédiat, les données étant déjà en mémoire. Si l on se déplace très vite dans une direction et que l outil n a pas eu le temps de charger la partie demandée, un simple carré gris s affiche à la place de la zone manquante, le temps qu elle soit rapatriée du serveur, mais ce n est pas toute la carte qui reste blanche pendant le chargement. GoogleSuggest ( GoogleSuggest est directement lié au moteur de recherche Google. Il permet d afficher dans une fenêtre, au cours de la frappe, les mots qui commencent par les caractères saisis, et le nombre de pages trouvées pour chaque mot, avant que l utilisateur n ait lancé la recherche. Avec ces 3 applications, Google a donc réussi à tirer parti d Ajax, et en faire quelque chose de vraiment utile. En naviguant sur Internet, on voit rapidement qu Ajax pourrait améliorer un bon nombre de sites Internet. Si l on parcourt un site de commerce en ligne, on se rend compte que la recherche d un article n est pas pratique. Il faut choisir une rubrique, ce qui rafraîchit toute la page avec les sous rubriques. Lorsque l on choisit la sous rubrique, toute la page se recharge avec les articles disponibles. De même lorsque l on choisit un article, c est toute la page qui est mise à jour pour présenter les détails de l article. Et sur bien des sites, la page est encore une fois rechargée lorsque l on ajoute l article au panier, alors que ce n est qu une petite partie de la page (le panier) qui est mise à jour réellement. Il existe peu de sites sur lesquels on constate une réelle interactivité actuellement, et ceux qui proposent une solution Ajax sont en général assez faciles à repérer. 33/41

34 6.2. Expansion dans les prochaines années Dans le monde de l informatique, il est difficile en ce moment de passer à côté d Ajax. Toutes les revues informatiques en parlent, les termes «Web 2.0» et «Ajax» reviennent sans cesse. On se sent presque obligé d adhérer à ces nouvelles technologies, pour ne pas rester en retrait. Dans les services informatiques des entreprises et des administrations, les décideurs ont déjà pour la plupart entendu parler d Ajax et de ses avantages. Ils se sont sans doute rapidement rendus compte qu ils pourront tirer profit de cette nouvelle technologie pour leurs applications Web. Il y a donc fort à parier qu Ajax prenne vite une place importante dans le monde du Web ces deux à trois prochaines années. La technologie est jeune, mais se répand déjà très rapidement. Il est vrai que les inconvénients d Ajax sont souvent moins connus des décideurs que ses avantages. Il faut donc espérer que les entreprises sauront utiliser Ajax à bon escient, et ne tenteront pas à tout prix «d Ajaxiser» leurs sites, sans en mesurer les conséquences. Cela risque sinon de représenter pour ces entreprises un coût supplémentaire, plus qu un apport réel. Du côté des frameworks, on peut penser que certains prendront rapidement possession du marché. Du côté de.net on pense bien sûr à la solution proposée par Microsoft, qui risque de s imposer naturellement, étant donné qu elle est proposée par le même éditeur que le framework.net lui même. Pour Java, on sent que même si le framework DWR est aujourd hui assez en vogue, il risque de se faire dépasser par ATF, en raison de la puissance que représentent ses éditeurs, IBM en tête. Cela restera bien sûr à confirmer par la suite, d autres frameworks intéressants pouvant encore apparaître dans les prochains temps. D une manière générale, Ajax a clairement de très bonnes perspectives d avenir dans les prochaines années. On peut dire sans trop s avancer que d ici un an ou deux, une partie non négligeable des nouvelles applications créées utilisera Ajax. Une fois que ce fonctionnement se sera répandu, les sites qui ne l utiliseront pas risquent fort d être «obligés» de s adapter, dans les cas bien sûr ou cela représente un avantage (tous les sites de e-commerce par exemple). Nous ne sommes sans doute qu au début d une grosse évolution, qui fera changer de manière importante le Web tel que nous le connaissons actuellement. 34/41

35 Tableau des figures Figure : Le Protocole HTTP Page 5 Figure : Fonctionnement Ajax Page 9 Figure : Technique des cadres cachés Page 11 Figure : Technique XmlHttpRequest Page 14 Figure : Comparatif frameworks Page 22 Figure : Faut-il utiliser Ajax? Page 25 Figure : Choisir un framework Ajax Page 29 Figure : Architecture Ajax Page 31 35/41

36 Bibliographie Livres Dave CRANE, Eric PASCARELLO, Darren JAMES : Ajax en pratique, 2006 (ISBN : ) C. ZAKAS, Jeremy MCPEAK, Joe FAWCETT : Ajax : Pour développer des applications Web à interface riche (ISBN : ) Ryan ASLESON, Nathaniel T. SCHUTTA : Foundations of Ajax (ISBN ) Magazine «Programmez», n 90 octobre 2006 : Internet François Tonic : Le Web 2.0 et ses méandres Grégory Renard : Développez vos applications web riches ASP.NET 2.0 avec ATLAS Xavier Leclercq : Comparaison de quelques frameworks et toolkits Ajax Jesse James GARRETT : Ajax: A New Approach to Web Applications Gaël Donat : Introduction à et interaction avec PHP Frédéric Bordage : Ajax : la revanche du navigateur : Xavier Borderie, JDN Développeurs, 8 conseils pour le développement Ajax Société WIGMAM : «Développez vos applications Web riches ASP.NET 2.0 avec Atlas» Auteur inconnu : Accessibilité au Web : HTML et feuilles de style Auteur inconnu : Les cadres d application Ajax Gilles Chagnon : Cours de manipulation du DOM et DHTML Jérôme Charron : Les moteurs de recherche n indexeront pas les sites Ajax 3_/5/17/1/ Les_moteurs_de_recherche_n_indexeront _pas_les_sites_ajax.htm Apple : Remote scripting with IFrame Daniel Zeiss : Comparison of frameworks for ASP.NET Auteur inconnu : Comparatif de frameworks Ajax Auteur inconnu : frameworks Ajax Patterns : Julien Carnelos : Framework Ajax et Java : Julien Carnelos : et Struts par l exemple Joe : Site de présentation du framework DWR : 36/41

37 Lionel Laské : Construire un mini framework pour GoogleMap, YahooMap et VirtualEarth : Laurent Bois : DWR sait rendre Ajax simple : Stéphane Traumat : Retour d expérience sur Google Web Toolkit : Olivier Rafal : Quand Ajax rencontre Eclipse : Google : Google Web Toolkit Product Overview Laurent Chartrain : DWR : librairie pour Java Brad fults : XHConn : A simple XMLHTTP Interface Library Michael Schwartz : Ajax.NET Professional 37/41

38 Annexes Article publié le 18 février 2005 par Jesse James Garrett, considéré comme le «créateur» du terme «Ajax» If anything about current interaction design can be called glamorous, it s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn t on the Web? (Okay, besides the ipod.) All the cool, innovative new projects are online. Despite this, Web interaction designers can t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application. That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload. Google Suggest and Google Maps are two examples of a new approach to Web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what s possible on the Web. Defining Ajax Ajax isn t a technology. It s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates: standards-based presentation using XHTML and CSS; dynamic display and interaction using the Document Object Model; data interchange and manipulation using XML and XSLT; asynchronous data retrieval using XMLHttpRequest; and JavaScript binding everything together. The classic Web application model works like this: Most user actions in the interface trigger an HTTP request back to a Web server. The server does some processing retrieving data, crunching numbers, talking to various legacy systems and then returns an HTML page to the client. It s a model adapted from the Web s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn t necessarily make it good for software applications. 38/41

39 Figure 1: The traditional model for Web applications (left) compared to the Ajax model (right). This approach makes a lot of technical sense, but it doesn t make for a great user experience. While the server is doing its thing, what s the user doing? That s right, waiting. And at every step in a task, the user waits some more. Obviously, if we were designing the Web from scratch for applications, we wouldn t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all? How Ajax is Different An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary an Ajax engine between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true. Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user s behalf. The Ajax engine allows the user s interaction with the application to happen asynchronously independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. Figure 2: The synchronous interaction pattern of a traditional Web application (top) compared with the asynchronous pattern of an Ajax application (bottom). 39/41