Ajax, dépoussiérez vos applications Web - Flash informatique
publicité
Ajax Sommaire FI 4/2005 Dépoussiérez vos applications Web ! [email protected], [email protected], [email protected], [email protected] & [email protected], Ecole d’ingénieurs et d’architectes de Fribourg Introduction Qu’est-ce que Ajax ? Pourquoi Ajax ? L’apport d’Ajax dans le Web 2.0 Buts d’Ajax Trois principes d’Ajax Les éléments clés d’Ajax Javascript Cascading Style Sheets (CSS) Document Object Model (DOM) L’objet XMLHttpRequest Clients riches Ajax dans le monde réel Résumé Étude de la mise en œuvre Communication asynchrone Mise en place côté serveur Mise en place côté client Apports d’Ajax Les trois principes définissant le terme Ajax Coûts réduits Fonctionnalités d’applications de bureau Résumé Désavantages d’Ajax Ergonomie Adaptabilité Ajax en pratique Conception d’une application Ajax Quelques toolkits/frameworks courants Dojo Rails DWR Réalisation de fonctionnalités de base Conclusion Bibliographie Ndr: Le Domaine IT organise un cours AJAX au mois de mai, voir en page 17. 1 Ajax – dépoussiérez vos applications Web ! Dominik Chanton, Jean Revertera, Cédric Vonlanthen, Jacques Bapst & Omar Abou Khaled 2 DIT-info 3 Les trombines de people Ion Cionca 4 epfl @ Shibboleth @ epfl Pierre Mellier 5 Du nouveau dans les News Franck Perrot 13 SPAM, la lutte continue Jacqueline Dousson 14 Word, je thème... un peu... Jacqueline Frey 15 Programme des cours 19 ForumIT Jacqueline Dousson 20 Langage Laurent Kling, Marc Dumont & Esteban Rosales Prochaines parutions suite en page 6 délai rédaction 5 6 sp 7 8 9 10 04.05.06 08.06.06 30.06.06 07.09.06 05.10.06 02.11.06 30.11.06 parution 23.05.06 27.06.06 29.08.06 26.09.06 24.10.06 21.11.06 19.12.06 FI 4 – 25 avril 2006 – page Ajax: dépoussiérez vos applications Web ! suite de la première page Introduction Qu’est-ce que Ajax ? Idéalement, l’interface d’une application doit permettre à l’utilisateur d’arriver à faire ce qu’il veut de manière intuitive, en lui offrant le maximum de temps pour réfléchir à son problème plutôt qu’à l’outil qu’il utilise. En pratique, nous sommes habitués à utiliser des interfaces peu optimales et c’est seulement lorsque quelqu’un nous montre une meilleure façon de faire que nous réalisons à quel point notre ancienne méthode était frustrante… Le Web est en train de subir une telle évolution. En effet, les technologies de base du Web pour l’affichage de contenu ont déjà été poussées au-delà des limites du raisonnable. Ajax, pour Asynchronous Javascript And XML, est un nom apparu en février 2005 dans un article publié par Jesse James Garrett1 sur le site AdaptivePath. Ajax n’est pas une nouvelle technologie, c’est une appellation qui désigne une architecture c’est-à-dire une façon de concevoir et de développer un service en ligne. Les ingrédients de base en sont les XHTML, CSS (feuilles de style), Javascript, DOM, XML, XSL et XMLHttpRequest. C’est en fait Microsoft qui le premier a lancé le concept, car, à la base, l’objet XMLHttpRequest était un ActiveX d’Internet Explorer 5 (en 1999 déjà). Cet ActiveX a ensuite été intégré, sous une autre forme, à tous les navigateurs modernes sous l’impulsion de Mozilla. Le premier à avoir massivement employé, et donc popularisé Ajax, est Google avec ses services Google Suggest (l’outil de suggestion des requêtes), Gmail2 (le webmail de Google3) ou encore Google Maps4 (l’outil de consultation de cartes), même si les technologies sur lesquelles Ajax repose existaient depuis plus de 5 ans et qu’une multitude de sites faisaient déjà de l’Ajax sans le savoir. Les services Web demandés deviennent de plus en plus complexes et les applications Web classiques commencent à ne plus pouvoir répondre aux exigences. Ajax, en alliant diverses technologies qui ont fait leurs preuves et qui sont présentes sur la majorité des ordinateurs, permet de combler cette lacune en facilitant la création de clients plus riches et plus conviviaux. Pourquoi Ajax ? Quels manques y a-t-il dans les applications Web actuelles ? Les utilisateurs souffrent de plus en plus de la lenteur des applications Web. Après chaque action il faut attendre que la page montrant le résultat s’affiche. Prenons l’exemple d’une liste d’éléments sur une page. Si l’on veut permettre à l’utilisateur de changer leur ordre, la façon classique de faire est de mettre des flèches cliquables permettant de faire monter ou descendre l’élément d’un niveau. Sur un client riche, l’interaction serait bien plus simple, en faisant, par exemple, un glisser-déposer, permettant de rapidement et simplement déplacer l’élément à sa nouvelle position. FI 4 – 25 avril 2006 – page Reorder T S T S T S T Drag and drop items to reorder! I'm number 2 I'm number 3 I'm number 1 Méthode classique Avec glisser-déposer utilisant Ajax fig. 1 Si l’on prend comme autre exemple le cas d’un traitement de texte, on peut, avec Ajax, offrir un correcteur orthographique durant la frappe ou encore le tri instantané d’une colonne dans un tableau. Petit historique du Web Le Web a beaucoup évolué depuis ses débuts, nous sommes passés des pages statiques - et difficilement éditables - aux applications dynamiques puis aux portails collaboratifs en quelques années seulement. Voici une courte rétrospective des étapes majeures. Web 1.0 z z z z z Type de Web: statique. Période: 1994-1997. Technologies associées: HTML, GIF. Noms associés: Netscape Caractéristiques: les pages Web sont des documents statiques rarement mis à jour. Web 1.5 z Type de Web: dynamique. z Période: 1997-2003. z Technologies associées: DHTML, langage de script côté serveur tel que ASP/PHP/Perl, CSS. z Noms associés: Yahoo !, Amazon, eBay z Caractéristiques: les pages Web sont construites à la volée à partir d’une ou plusieurs bases de données. Web 2.0 z Type de Web: collaboratif. z Période: 2003-… z Technologies associées: Ajax, DHTML, XHTML, XML, Soap, RSS. z Noms associés: Google, blogs, wiki (tel que Wikipedia), album photos (tel que Flickr), réseaux sociaux (tel que Linked In5) z Caractéristiques: l’utilisateur devient contributeur. Il publie des informations et manipule les données. P a r t c i p a t i o n Web 1.x Web 0.x Web 2.x er sum nt nte Co cer du n Co nt nte Co o Pr Time Few to Many Many to Everybody fig. 2 'Everybody' to Everybody Ajax: dépoussiérez vos applications Web ! Remarque L’attribution de numéros de version au Web est controversée, car leWeb est en constante évolution et ne subit pas de brusques changements. Néanmoins, nous l’utiliserons, faute de mieux, pour désigner une période de son évolution et non pas un instant précis. L’apport d’Ajax dans le Web 2.0 Ajax permet d’améliorer nettement le confort utilisateur (l’utilisabilité) des applications Web en s’approchant du niveau clients riches que l’on trouve sur le poste de travail. En effet, cet ensemble de technologies améliore la réactivité des applications en fournissant une variété de composants permettant de saisir et de manipuler de l’information plus aisément et souvent de manière beaucoup plus intuitive. Buts d’Ajax L’objectif d’Ajax est de permettre d’avoir des applications utilisables à l’aide d’un navigateur Web et qui satisfont les buts de productivité, de mise en réseau et de maintenance centralisée sans un trop grand effort. Pour atteindre ce niveau, il faut commencer par penser différemment la façon de créer nos pages Web ainsi que nos applications. Trois principes d’Ajax La technologie Ajax repose sur les trois principes: 1. Le navigateur accueille l’application, pas le contenu. 2. Le serveur livre les données, pas le contenu. 3. L’utilisateur interagit continuellement avec l’application, les requêtes aux serveurs sont implicites plutôt qu’explicites. Ils sont expliqués plus en détail au paragaphe: Les principes définissant le terme Ajax, en page 9. Les éléments-clés d’Ajax Ajax est un ensemble de technologies qui se complètent, voici un bref résumé de ces technologies ainsi que leurs rôles. Javascript Javascript6 est un langage de script créé pour être utilisé à l’intérieur d’applications. Dans un navigateur Web, il permet l’interaction avec les fonctionnalités de celui-ci. Les applications Ajax sont écrites en Javascript. Cascading Style Sheets (CSS) Les CSS7 permettent de définir un aspect graphique réutilisable pour des éléments d’une page Web. Dans une application Ajax, l’interface utilisateur peut être modifiée dynamiquement grâce à ces feuilles de style. Document Object Model (DOM) Le DOM8 représente la structure de la page sous forme d’une collection d’objets pouvant être manipulés avec du Javascript. Utiliser des scripts sur le DOM nous permet de modifier l’interface utilisateur à la volée, en redessinant des parties de la page. L’objet XMLHttpRequest L’objet XMLHttpRequest9 permet au programmeur Web d’obtenir des données du serveur Web en tâche de fond. Le format des données est prédestiné à être du XML, mais cela fonctionne également avec n’importe quelles données textuelles. Clients riches Ajax dans le monde réel C’est Google qui a le plus popularisé ce nouveau profil d’application. C’était au début 2004, avant même que le terme Ajax n’existe, grâce à son webmail nommé Gmail. Google a en effet été le premier à proposer une interface graphique épurée et efficace, fournissant les mêmes fonctions que les outils de messagerie d’entreprises tel que Microsoft Outlook et Lotus Notes, sans avoir recours à des ActiveX ou du code Java. Cela a permis d’avoir un webmail puissant, multi-plateforme, accessible depuis n’importe où et sans avoir besoin de préconfigurer le poste client pour avoir un outil de qualité. Suite à ce succès, les sites d’envergure utilisant Ajax se sont multipliés. On peut citer Flickr10, appartenant à Yahoo!, qui est un système de partage de photographies; plusieurs nouveaux services de Google tels que Google Maps11, un outil de visionnage de cartes; Google Suggest12 qui est un système de complétion de recherche; ou encore Start.com13 et Microsoft Live 14 qui sont tous deux des portails d’actualités entièrement paramétrables par l’utilisateur. Résumé Ajax est approprié lorsqu’on n’a pas la maîtrise du poste client, lorsqu’il n’est pas possible d’imposer l’installation de plug-in (comme c’est le cas pour Flash), de machine virtuelle (Java Web Start et No Touch Deployment) ou encore d’ActiveX souvent bloqués par les pare-feux. Ajax est une solution non-intrusive, mais sensiblement moins puissante, et qui ne peut pas vraiment rivaliser dans tous les domaines avec des applications locales. Étude de la mise en oeuvre Le but de cette analyse est de déterminer quels moyens généraux sont nécessaires pour déployer une architecture Ajax aussi bien du côté du serveur que de la partie cliente. Communication asynchrone Principe Dans le modèle des pages Web classiques encore largement utilisé aujourd’hui, la communication entre le navigateur et le serveurWeb est dite synchrone. En effet, à partir d’un certain état d’une page, l’utilisateur ne peut effectuer qu’une seule requête au serveur qui va aboutir à un rechargement complet de celle-ci, dont le contenu restera statique avant d’être à nouveau mise à jour en intégralité (fig 3). FI 4 – 25 avril 2006 – page Ajax: dépoussiérez vos applications Web ! Traditional Web Architectures Web page User interaction Time Server Processing Processing = Server Request fig. 3 – Modèle de communication Web synchrone Mise en place côté serveur Le rechargement complet d’une page qui s’accompagne souvent d’une réinitialisation des barres de défilement (scrollbars) et d’une plus ou moins brève disparition du contenu, limite fortement l’impression d’interactivité pour l’utilisateur, et rend très difficile l’utilisation d’éléments standards des interfaces utilisateurs à contenu dynamique ou la manipulation directe (par exemple le drag & drop). La communication asynchrone permet de résoudre ce problème en permettant à l’utilisateur, depuis un certain état d’une page, de lancer en arrière-plan, un nombre arbitraire de requêtes pour mettre à jour uniquement des éléments internes de la page (fig 4). Les requêtes asynchrones étant traitées de manière classique, l’utilisation d’Ajax peut se faire de manière totalement indépendante du serveur. On aura néanmoins avantage à choisir une plate-forme de programmation (tel que Java, PHP, Ruby on Rails, etc.) correspondant aux besoins du projet. La plupart d’entre elles supportent déjà et de manière native un parseur XML permettant de manipuler plus facilement les données transmises. Mise en place côté client Tout comme avec la partie serveur, la mise en place d’Ajax côté client est relativement légère, elle se base principalement sur la présence de deux fonctionnalités: z La capacité d’envoyer des requêtes de type XMLHttpRequest pour la communication asynchrone. z La capacité de traiter (parser) les réponses XML du serveur. L’implémentation des objets XMLHttpRequest est native dans la plupart des navigateurs récents et ne nécessite donc pas de plugin supplémentaire, concrètement il s’agit de Mozilla depuis sa version 1.0, Opera depuis sa version 8.0 et MS Internet Explorer (MSIE) depuis sa version 7.0 (5.0 via plugin ActiveX). Implémentation avec Ajax L’implémentation d’un concept de communication asynchrone passe par une adaptation au niveau client (qui doit être capable de lancer des requêtes de manière asynchrone), et éventuellement au niveau du serveur. En effet, les données envoyées n’étant plus forcément des pages Web, mais des données utilisateur brutes (destinées par exemple à peupler un formulaire), on peut attendre de l’application cliente qu’elle soit capable de traiter un format de données plus propice. AJAX Based Web Architectures Web page User interaction Time Server Processing Processing = Server Request fig. 4 – Modèle de communication Web asynchrone FI 4 – 25 avril 2006 – page Ajax: dépoussiérez vos applications Web ! Le parser XML quant à lui est interne dans la majeure partie des navigateurs (Mozilla, Netscape,. . .) excepté avec MSIE qui utilise une librairie propre au système d’exploitation MS-Windows (MSXML.dll). Vérification et enregistrement instantanés de champs – Il est ainsi possible non seulement de vérifier chez le client si une donnée est valide, mais également sur le serveur. L’utilisateur d’applications de bureau y est habitué depuis longtemps. Apports d’Ajax Coûts réduits Les diverses technologies utilisées par Ajax ne sont pas nouvelles. En les utilisant de manière appropriée, on peut envisager le développement Web de clients riches. On retiendra deux mots clés: riche et client. Riche se réfère ici au modèle d’interaction avec le client, qui se doit donc de supporter un ensemble de méthodes d’entrées et de répondre dans un laps de temps raisonnable. Regardons ce qu’Ajax possède pour tendre vers une application riche de type bureautique, en profitant de la caractéristique client. Les principes définissant le terme Ajax Le modèle classique d’application Web (connu aussi sous le nom d’application paginée) est bien ancré dans notre façon de penser. Voyons quels sont les principes de bases de la nouvelle approche. Le navigateur héberge une application et non du contenu Lorsque l’utilisateur lance l’application, des données légèrement plus lourdes seront chargées chez le client. Cependant, elles y resteront durant toute la session et seules les interactions seront transmises. Ajax: Le juste milieu – Deux approches principales existaient avant Ajax: l’approche tout sur le même écran et celle par page. Dans la première approche, la page est mise à jour dès que l’utilisateur modifie un élément, tandis que dans la deuxième, la page n’est mise à jour qu’au terme d’un processus de plusieurs étapes. Ajax combine avantageusement ces deux approches, permettant des fonctionnalités plus sophistiquées en utilisant les standards Web qui peuvent être implémentés plus facilement. Par rapport aux approches classiques, une réelle et puissante alternative nous est donc proposée. Interface à écran unique – Cette approche facilite la cohésion de la navigation et l’utilisateur possède ainsi une vue d’ensemble de l’application, des étapes d’une procédure, etc. La flexibilité est aussi à l’ordre du jour, puisque l’utilisateur choisit l’ordre dans lequel il parcourt les étapes et peut également revenir en arrière. Partage d’éléments et d’objets – Ce cas s’applique pour les interfaces de type monopage. Il est ainsi possible de réutiliser les éléments à divers endroits de l’application. Le partage est facilité et l’utilisateur doit télécharger moins de données. Voici un argument non négligeable, voire décisif, dans certains cas. Une réduction des coûts intervient même dans des domaines insoupçonnés. Une entreprise a, par exemple, pu remplacer une application de bureau coûteuse par une solution Ajax proposant des fonctionnalités similaires avec une même ergonomie utilisateur (passage ici à EBA Grid Control15). Typiquement les coûts se situent au niveau des ressources humaines et des prix des licences pour le développement Web. Mais ceux-ci sont bien moindres quand on considère le montant des licences annuelles des applications de bureau, ainsi que la distribution des mises à jour et le support utilisateur. Les coûts de déploiement sont eux aussi fortement réduits. En effet grâce à l’architecture client-serveur d’une application Web, les changements dans l’application ne se font que sur le serveur et non plus sur tous les postes de travail. Mais il s’agit là d’une analyse bien succincte et non complète. Il faut également incorporer des éléments qui sont plus difficiles à quantifier. Pensons par exemple à l’impact sur la satisfaction de l’utilisateur. Une meilleure interface réduira les erreurs humaines, les coûts d’apprentissage et les frustrations. Fonctionnalités d’applications de bureau Dans le contexte Ajax, il est possible d’ajouter des fonctionnalités jusqu’ici propres aux applications de bureau. L’utilisateur pourra visualiser les données et interagir avec elles d’une manière jusqu’alors impossible sur le Web. Par rapport à une application de bureau, on peut retenir plusieurs avantages: Ajax permet de s’affranchir d’un système d’exploitation, d’une plate-forme donnée, le Web est la plateforme. On centralise les données afin de pouvoir y accéder depuis un ordinateur quelconque ayant un accès internet. On évite aussi de stocker des informations sensibles sur un ordinateur personnel. Résumé Même en gardant une certaine dose de scepticisme, il faut admettre qu’Ajax apporte des avantages clairement démontrables et quantifiables pour une application Web. Les économies de coûts résultent principalement d’économies de temps, mais également d’économies de bande passante. En outre, on peut s’attendre à une réduction des coûts de travail de 30-70% (source: 16) en utilisant cette technique. Le serveur envoie des données et non du contenu Puisque la majeure partie de l’application se trouve déjà du côté client, ne sont échangées avec le serveur que les données modifiées. FI 4 – 25 avril 2006 – page Ajax: dépoussiérez vos applications Web ! Désavantages d’Ajax Adaptabilité Ergonomie Utilisation de Javascript Retour en arrière Le côté le plus décrié d’Ajax est sans aucun doute son atteinte à certains mécanismes Web traditionnels qui ont été largement utilisés jusqu’alors sans problème, et ceci, dès les premiers balbutiements d’Internet. On pense bien sûr au bouton Retour en arrière devenant trop souvent inutilisable dans les premières applications utilisant Ajax. En effet, s’il n’est jamais vraiment nécessaire de se soucier de cette fonction tant que l’on travaille avec des pages au contenu statique (l’appui sur le bouton en question réaffichant la dernière page visitée), elle n’est pas du tout adaptée aux documents à contenu dynamique qu’induit le modèle de communication asynchrone: l’utilisateur veut avoir la certitude qu’il peut annuler une action et revenir dans un état antérieur de la page, comme c’est le cas dans les applications dites lourdes. Il est possible de combler cette lacune ergonomique en codant de manière conséquente nos applications Ajax (par exemple grâce à l’utilisation d’I-Frames). Dans cette optique certains frameworks intègrent des fonctions d’historique avancées permettant de rendre cohérente l’utilisation du bouton Retour en arrière. Gestion des marques-pages Un autre problème, lié au précédent, est la difficulté de sauvegarder un état précis d’une page Web qui se fait traditionnellement via l’utilisation de marques-pages (bookmarks). En effet, avec un modèle asynchrone dynamique, et contrairement aux pages Web classiques, une même URL peut aboutir à un document au contenu très différent. Encore une fois, il est à la charge du développeur de contourner le problème. Une des manières les plus simples consiste à jouer avec les fragments d’identifiant de l’URL (la partie après le #). Limitations de Javascript Lenteur – Javascript, sur lequel se base le moteur d’Ajax côté client, est un langage interprété dont le code sera exécuté dans l’environnement d’exécution du navigateur Web. Il est relativement lent (plus ou moins suivant le navigateur utilisé). L’utilisateur se trouvera donc devant des applications aux interfaces très semblables, mais proposant moins de réactivité que leurs homologues installées localement et qui se basent la plupart du temps sur des langages compilés, plus complexes et mieux adaptés. Il est peu probable que l’on voie, dans un avenir proche, des applications Web nécessitant une très forte réactivité telle que des jeux d’action, des applications temps réel, etc. Ressources – Les librairies Javascript sont principalement destinées à des fonctions de calcul et de manipulation de texte, elles ne disposent pas de toutes les fonctions plus avancées que l’on retrouve dans les langages standards, principalement dans la manipulation d’images et d’objets 3D. Ce manque est en partie comblé par l’utilisation de Canvas17, mais qui n’est pas pleinement supporté par l’ensemble des navigateurs actuels. FI 4 – 25 avril 2006 – page 10 Selon différentes sources, environ 4 à 13% des internautes utilisent un navigateur ne supportant pas Javascript (indispensable à l’utilisation d’Ajax) ou l’ayant désactivé (le plus souvent dans un souci de sécurité). Inutile donc de préciser qu’avec un visiteur sur dix il n’est absolument pas superflu (il est même indispensable), de toujours mettre à disposition la version d’un service accessible de manière classique. Cross-browsing Les implémentations de Javascript varient grandement entre les navigateurs, de ce fait, certains composants Ajax ou propres aux applications riches, sont susceptibles d’être dépendant d’une plate-forme cible. Cependant, la majorité des frameworks courants affichent une bonne compatibilité inter-navigateurs. Ajax en pratique Conception d’une application Ajax Dans le cadre de notre projet et pour mieux nous rendre compte des difficultés quant à l’utilisation d’Ajax nous avons programmé partiellement une application proof-of-concept dans laquelle nous avons cherché à profiter de la communication asynchrone: un GED ou Gestionnaire Électronique de Documents. Plus précisément, nous avons tenté l’implémentation de trois éléments que l’on retrouve fréquemment dans ceux-ci: une fonction d’envoi de fichiers (avec barre de progression), la possibilité de faire du glisser-déplacer dans une arborescence (drag’n’drop) et de pratiquer de l’autocomplétion sur une boîte de texte (pour les noms des fichiers situés sur les serveurs). Quelques toolkits/frameworks courants Bien qu’étant une technologie relativement récente il existe déjà un grand nombre de frameworks visant à simplifier le développement d’applications Ajax. La grande majorité d’entre eux ne se limitent pas à la communication asynchrone, mais mettent également à disposition des éléments d’applications riches, tels que des barres de chargement ou diverses animations graphiques rendues viables grâce à Ajax. Pour mener à bien notre projet, nous avons dû choisir une librairie de développement parmi les nombreux toolkits existants, en voici une liste non exhaustive: z Dojo Toolkit z DWR z script.aculo.us z Zimbra z Mochikit z Taconite z Atlas z xAjax z Plex Toolkit z WebORB z Open Rico z AjaxAnywhere z Xoad z Rialto Pour réaliser ce choix nous nous sommes basés sur différents critères, notamment les droits d’utilisation (licences), les fonctionnalités, la notoriété, etc. (pour plus de détails, voir le rapport complet de notre projet18). Nous avons finalement retenu les trois framework suivants: Dojo, Ruby-on-Rail (utilisant script.aculo.us en back-end), et DWR. Ajax: dépoussiérez vos applications Web ! Dojo Le toolkit Dojo est un ensemble de librairies pour développer une application Web moderne mettant l’accent sur l’interactivité avec l’utilisateur. Plusieurs versions de Dojo existent et diffèrent uniquement par les librairies intégrées dans le paquet de base. Le choix de ce dernier ne limite en aucun cas l’utilisation de Dojo, puisqu’il suffit d’ajouter après l’intégration du paquet toutes les librairies nécessaires. En fait, en minimisant la taille des librairies, le chargement dans le navigateur de l’utilisateur sera bien plus rapide. Rails Ruby on Rails (aussi abrégé RoR ou Rails) est un framework de développement d’applications Web utilisant le langage Ruby qui permet de développer très rapidement des applications évoluées, en écrivant un minimum de code. Il est basé sur le modèle MVC, et supporte la technologie Ajax, les SGBD SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server, et inclut son propre serveur Web, nommé WEBrick19, permettant de développer et tester son application directement sans avoir à installer de serveur Web. L’EDI (Environnement de Développement Intégré) nommé RadRails20 à été utilisé dans le cadre de ce projet. Celui-ci est basé sur Eclipse21 et permet de bénéficier entre autres de la coloration syntaxique et la complétion en cours de frappe. DWR DWR est un framework Java permettant d’aborder d’une manière innovante et ambitieuse le développement d’applications Ajax. Il permet de générer dynamiquement (à la demande du client) le code Javascript nécessaire pour accéder et/ou instancier un objet sur le serveur quel qu’il soit (les conversions nécessaires entre les types Java et Javascript étant effectuées de manière transparente) un peu à la méthode des RMI. Le principe est simple: à chaque appel d’une méthode présente sur le serveur il nécessaire de spécifier en argument la méthode Javascript qui sera utilisée pour le retour d’une éventuelle valeur. Dans un souci évident de sécurité (qui semble-t-il a toujours été présent depuis le début du développement de ce framework), il est nécessaire de spécifier dans un fichier de configuration (WEB-INF/dwr.xml), la liste des classes qui sont accessibles au navigateur. Contrairement à Dojo et Rails, DWR ne met pas à disposition du développeur des éléments d’applications riches pour la partie cliente mais se concentre uniquement sur l’aspect asynchrone de l’interaction. Réalisation de fonctionnalités de base Auto-complétion Avec Rails et Dojo, l’intégralité du développement de notre application de test a pu se faire du côté serveur, mais c’est avec Dojo qu’elle s’est révélée la plus aisée: une fois la liste des fichiers retournée (trivial en PHP), l’autocomplétion est activée simplement via l’ajout d’attributs à notre balise input, tel que Dojotype (spécifie quel widget est à utiliser) et dataUrl (spécifie une source de donnée ou un script dynamique). Pour Rails, les fonctions de filtrage ont été développées sur le serveur. Les seules facilités de développement ont été le traitement des événements et l’affichage de l’icône de chargement, l’implémentation s’est tout de même révélée assez simple. Du côté de DWR, la partie développement Ajax est aussi très succincte, se composant uniquement de quatre fonctions réparties entre le client et le serveur (deux pour le client pour l’envoi du contenu de l’entrée texte et la réception de la réponse et deux du côté serveur pour réceptionner et effectuer le filtrage sur la requête), mais il aura fallu un temps non négligeable pour la mise en forme, avec Javascript, des données pour l’utilisateur (près de 85% du temps d’implémentation). Fonction d’envoi de fichiers On constate qu’avec DWR, qui est de très bas niveau, il faut beaucoup plus de temps pour l’implémentation qu’avec les deux autres frameworks. Concernant Dojo, le seul avantage qu’il offre est d’éviter un rechargement de la page (grâce aux IFrame). De plus, avec Dojo, il serait compliqué d’ajouter une barre de progression (qui ne figure pas dans les widgets fournis) et il serait laborieux d’indiquer l’état d’avancement de l’envoi. Pour Rails, grâce à sa communauté très active actuellement, il existe déjà plusieurs exemples prêts à l’emploi, la seule contrainte est d’installer un serveur Apache avec une configuration spécifique. Du côté de la difficulté de réalisation, on constate qu’avec DWR il est nécessaire de se familiariser avec l’API (peu intuitive) de Jakarta pour l’envoi de fichiers. Il est également nécessaire de bien comprendre les mécanismes de Java côté serveur (session, JSP, objet, etc.) pour le traitement des requêtes et conserver les informations relatives à l’envoi simultané de plusieurs fichiers. Avec Rails, le code reste assez succinct et facilement compréhensible. Dans les trois frameworks, il serait assez aisé de faire un envoi simultané grâce aux IFrame (comme il a été fait pour DWR). Glisser-déplacer dans une arborescence Parmi les trois frameworks traités, DWR ne propose pas l’affichage sous forme d’arbre, ni le glisser-déplacer. Pour les deux autres, Dojo et Script.aculo.us, un composant arbre a été développé par un membre de la communauté, mais ce dernier ne propose pas du tout de glisser-déplacer (Script. aculo.us) ou pas de façon à pouvoir l’utiliser pour nos besoins (Dojo). Les recherches ont pris beaucoup plus de temps pour Dojo, car une fois le widget trouvé, nous avons essayé, sans succès, de le modifier pour l’adapter à nos besoins. Peu d’informations existent sur le sujet, mais beaucoup de personnes s’intéressent à une telle fonctionnalité. Il semble que pour ces deux frameworks nous pourrons disposer dans quelques semaines, voire mois, d’un composant qui réalisera, avec peu d’efforts d’adaptation, la fonctionnalité FI 4 – 25 avril 2006 – page 11 Ajax: dépoussiérez vos applications Web ! souhaitée. Mais pour l’heure, il faut encore compter avec passablement d’efforts. Conclusion Au terme de ce projet d’étude consacré à Ajax, nous possédons une très bonne vue d’ensemble sur le sujet grâce à la lecture d’une quantité volumineuse d’articles, de tutoriaux et de livres. Nous connaissons maintenant les points forts mais aussi les limitations de cette technologie. Ajax suscite un grand engouement, mais a aussi ses détracteurs, comme c’est souvent le cas lors de chamboulement de concept établi. Les attentes des utilisateurs évoluant avec le temps, la plate-forme Web est en train de rattraper son retard. On en veut pour preuve le fait que les entreprises suivent le pas, souvent enchantées de pouvoir faire évoluer leurs applications tout en utilisant des technologies standards et déjà connues par leurs développeurs et appréciées par les utilisateurs (employés, clients). Une année après la création de l’acronyme Ajax, l’engouement est tel qu’il existe plus de 90 frameworks en rapport avec Ajax et plus d’une quinzaine de livres22). Toutefois, nous pensons que d’ici un à deux ans, une convergence va s’effectuer du côté des développeurs vers deux à cinq outils. Parmi les outils ayant de bonnes chances de percer se trouve celui de Microsoft nommé Atlas, qui sera intégré dans le prochain Visual Studio .NET23, ainsi qu’Open Ajax24, un framework basé sur Eclipse et supporté par de nombreux grands acteurs de l’industrie tels que IBM, Oracle, Novell, RedHat, Google,Mozilla et beaucoup d’autres. Pour répondre à la question «est-ce qu’un jour Ajax va se substituer totalement aux applications de bureau?» nous répondons: non. Ajax va certainement changer le visage du Web tel que nous le connaissons aujourd’hui, et peut sans doute remplacer un client lourd simple, mais il reste peu probable que cette technologie puisse vraiment arriver, dans un proche avenir, au même niveau en terme de réactivité et qualité d’interaction que celles de leurs homologues de bureau. Il faudra pour cela que les technologies Web évoluent encore, ce qui ne manquera pas d’arriver. Bibliographie Dojo: http://dojotoolkit.org/ Rails: http://www.rubyonrails.org/ DWR: http://getahead.ltd.uk/dwr/ Ajax in Action par Dave Crane, Eric Pascarello, Darren James; Manning Publications; October 2005, ISBN: 1932394613 Le rapport de ce projet est librement téléchargeable à l’adresse suivante: http://cvsoftware.googlepages.com/rapportajax . Les figures démontrant les principes des méthodes synchrones et asynchrones sont tirées du site http://xml.com. Les logos des différents toolkits proviennent de leurs sites respectifs. FI 4 – 25 avril 2006 – page 12 Notes http://www.adaptivepath.com/publications/essays/archives/000385.php 2 http://www.gmail.com 3 http://www.google.com 4 http://maps.google.com 5 https://www.linkedin.com/ 6 http://www.ecma-international.org/publications/standards/Ecma-262.htm 7 http://www.w3.org/TR/REC-CSS2 8 http://www.w3.org/DOM 9 http://www.xulplanet.com/references/objref/XMLHttpRequest.html 10 http://www.flickr.com/ 11 http://maps.google.com/ 12 http://www.google.com/webhp?complete=1&hl=en 13 http://start.com 14 http://www.live.com 15 http://developer.ebusiness-apps.com/technologies/webdevelopment/codeandcomponents/ebagrid 16 http://www.developer.com/xml/article.php/10929_35542 71_2 17 http://www.whatwg.org/specs/web-apps/current-work/\ #the-2d 18 http://cvsoftware.googlepages.com/rapportajax 19 http://www.webrick.org/ 20 http://www.radrails.org/ 21 http://www.eclipse.org/ 22 http://Ajaxian.com/archives/happy-birthday-Ajax 23 http://asp.net/default.aspx?tabindex=9&tabid=47 24 http://www.eclipse.org/proposals/atf/ n 1
