La première session de la journée pour moi s’appelait « Dojo in action ». Je dois dire tout de suite que mes connaissances en Dojo était quasi-nulles avant aujourd’hui, et en ce qui concerne JavaScript je suis très loin d’être expert. Toutefois j’ai trouvé la matinée très intéressante et très instructive.L’intervenant Alex Russell est dirigeant du projet Dojo Toolkit et président de la fondation Dojo. Il sait donc a priori de quoi il parle sur le sujet de Dojo. J’ai trouvé sa présentation intéressante en ce qu’il ne s’est pas tout de suite jeté dans le code, mais qu’il a commencé par expliquer un peu « les bases » on pourrait dire, c’est à dire à quoi sert le toolkit et même plus généralement quelles étaient selon lui les considérations principales au jour d’aujourd’hui pour tout développeur web.Selon lui, en tant que développeurs d’applications, nous devons être capables de fournir à nos clients et utilisateurs des outils qui soient le plus naturel, le plus intuitif et le plus réactif possible. L’utilisateur possède un affinité immense pour une application bien conçue qui revêt carrément une dimension émotionnelle. De même une application mal conçue, lente et maladroite, et difficile à manipuler cheap mlb jerseys réveillera des sensations toutes aussi fortes et irrationnelles mais opposées. C’est pourquoi la phase de conception de l’application doit tenir compte de ce facteur au risque d’être un échec total, malgré toute la technologie et tout le design qu’on voudra bien lui conférer. Je suis tout à fait d’accord avec cela et c’est vrai que ça fait du bien de se le rappeler. C’est vrai pour les applications web, mais c’est tout aussi vrai pour les application client/serveur traditionnelles. Alex a pris l’exemple d’un couteau suisse. En fait lorsque l’utilisateur a assimilé son outil et qu’il le maitrise, dans son subconscient ce n’est plus l’outil qui travaille, c’est lui. L’outil doit pouvoir s’effacer en quelque sorte. Il ne doit pas venir s’imposer et se faire remarquer outre mesure. C’est une très bonne réflexion.

Dans le cadre spécifique du web, le toolkit Dojo cherche donc spécifiquement à améliorer l’expérience de l’utilisateur en permettant très facilement le développement d’applications web réactives sans sacrifier la portabilité côté client. Au sujet de la portabilité il a donc eu l’occasion de casser du sucre sur le dos de Microsoft (toute occasion est bonne, n’est-ce pas !). Il a évoqué quelqu’uns des bugs ahurissants que présente IE6 (gestion de scripts gzippés, fuites de mémoire, …). Il nous a également fait part qu’après la sortie de IE6 en 2001, Microsoft avait démantelé toute l’équipe de développement et a donc totalement laissé tomber son développement. Je ne l’avais jamais entendue celle-là mais bon ça ne m’étonnerait pas de notre ami Bill et de Majas son légendaire côté visionnaire.\n\nAlex a cité quelqu’un d’autre (je n’ai pas noté son nom) qui a résumé les principaux axiomes dans — l’architecture d’une solution logicielle :

• • Discoverability – L’utilisateur est capable de « découvrir » les fonctionalités et les fonctionnement du système. Je crois qu’on pourrait dire « intuitivité » (ça existe ?).

• • Recoverability – C’est la possibilité de se sortir du pétrin dans lequel on est tombé suite à une mauvaise manip, un click de trop, ou un champ non renseigné. C’est la possibilité de cliquer sur « Retour » et de trouver retrouver le contexte précédent inchangé sans perdre les saisies. Quand l’utilisateur perd les pédales ça l’énerve…

• • Context – L’application doit se souvenir de qui on est.

• • Feedback – C’est l’interaction avec l’utilisateur. Là je suis un grand partisan, il suffit de demander à mes collègues. Une petite scrollbar ou des libellés qui bougent rapidement, un AVI ou un GIF Firebird animé, ça fait des merveillent au niveau de l’expérience de l’utilisateur et de sa sensation de réactivité. Je crois que dans ce volet on pourrait mettre également tout ce qui touche aux informations pertinentes et intelligentes de tout genre qui sont renvoyées à l’utilisateur.

Système de paquetage et bootstrapping

Le toolkit Dojo permet de bénéficier d’un système de packages comme en Java. On peut ainsi écrire :

dojo.require("package.*");

pour inclure un package dojo, comme on écrirait

import package.*;

en Java. On peut même aller plus loin, en écrivant des choses de ce type :

dojo.requireIf(condition, "package.*");

ce qui permet par exemple d’importer un package uniquement sous certaines conditions (par exemple en fonction du navigateur). Toutes les parties de Dojo sont dans des packages, et on peut soi-même définir ses propres packages en spécifiant le chemin d’accès à la racine du package en partant du répertoire de base de Dojo.

dojo.setModulePrefix("nompackage", "../chemin/relatif");\ndojo.require("nompackage.*");

Autre chose intéressante au niveau du système de base : il n’y a pas de phase de compilation nécessaire (comme c’est le cas pour GWT par exemple). Toutefois, on peut en faire une qui a pour but de retirer tous les sauts de lignes, et les commentaires et d’exclure les packages non référencés dans le source. Cela permet d’épurer grandement le source transmis au navigateur et d’accélerer donc le temps de chargement cheap jerseys initial de la page.

Utilitaires du langage

Dans JavaScript il y a certaines choses qui sont standardisées mais pour garantir un fonctionnement homogène à travers les différents navigateurs, chacun sait que cela n’est pas chose facile. Dojo tente de remédier à cela au moins en partie en proposant des APIs fiables et identiques sur l’ensemble des navigateurs. Il incluent en outre une batterie de fonctions de base pour manipuler les types primitifs (chaînes, dates, numériques, …). Il y a aussi un concept assez intéressant qui est d’intégrer les nouvelles initiatives de certains navigateurs dans leur API, en fournissant une implémentation en JavaScript pour les navigateurs où cette fonctionalité n’existe pas en natif.

Système évènementiel

Alex a décrit le système évenementiel comme « AOP dans le browser ». En fait, n’importe quel objet peut être notifié lorsque n’importe quelle méthode est appelée sur un autre objet.

dojo.event.connect(obj1, "fonction", obj2, "fonction");\nobj1.fonction(); // obj2.fonction() est appelé aussi

Les sources et les cibles peuvent également être des noeuds du DOM. L’objet Event a apparemment été corrigé, ce qui évite les fuites de mémoire à tout bout de champ.

Utilitaires UI

Il y a tout un tas de packages contenant des utilitaires d’interface graphique, en voila quelques uns :

• • dojo.io.*

• • dojo.html.*

• • dojo.style.*

• • dojo.dom.*

• • dojo.rpc.*

Le but de toutes ces classes et de permettre au développeur de se concentrer sur la logique de son application sans s’occuper de la plomberie interne.La méthode dojo.io.bind() sert pour le fonctionnement AJAX. Il n’est pas trop rentré dans le détail. Il y a également cheap jerseys possibilité de réagir sur l’évènement du bouton wholesale jerseys « Précédent » ce qui permet de faire des traitements spéciaux dans ce cas.Dojo possède des classes permettant de faire de l’appel de procédure distante (RPC) avec le protocole JSON. C’est un protocole plus léger que le XML et qui est moins couteux à encoder et à décoder de part et d’autre. Les cinq types de données primitifs sont encaspulés ce qui permet une intéropabilité entre langages.\n\nIl y a également la gestion du glisser / déposer (Drag & Drop), ainsi que des effets spéciaux (dans dojo.lfx.*) permettant de faire apparitions et disparitions graduelles, par exemple.

Widgets

J’ai bien aimé cette section. En fait Dojo permet la création dynamique de widgets sur la page si on le souhaite, mais il est également possible d’intégrer directement dans le code HTML envoyé depuis le serveur d’ajouter certaines balises spéciales mettons dans un <div> ou un <div> et ensuite cet élément sera remplacé dynamiquement par Dojo côté browser (si le navigateur le permet). Cette approche est particulièrement élégante puisqu’elle permet un mode dégradé très acceptable lorsque l’utilisateur a désactivé le JavaScript par exemple.\n\nTous les widgets classiques sont représentés : RichTextEditor, Tables (sorting/filtering columns), ContentPane, Tabs, Tree, FisheyeList, Yahoogle Maps, Dialog Wizard, .... Voici un exemple d’utilisation de l’éditeur rich ili text :

\n<script>\ndojo.require("dojo.widget.Editor2");\n</script>\n<textarea dojoType="Editor2" ... >\n\n</textarea>\n

Au niveau des « … » on peut rajouter n’importe quelle balise correspondant à un nom de propriété de la classe « Editor2 ». C’est super non ? En plus sur un navigateur ne gérant pas le JavaScript, cela apparaîtra comme un simple textarea. Bon, c’est sûr que les militants du XHTML vont faire la tête, mais bon …. 🙂

Widgets personalisés

Oui, cela est possible avec le toolkit Dojo ! Pour en savoir plus, référez-vous au site de documentaiton.

Sujets avancés

Je ne vais pas tout détailler ici car c’est la seconde partie Europe de la session qui était assez intense. Je vais toutefois évoquer les grandes lignes :

• • Dessin 2D natif. Il nous a montré quelques exemples assez impressionnants de dessin 2D directement côté navigateur en natif et en vectoriel. Dans le package dojo.gfx il y a tout ce qu’il faut Hello pour. Sous IE ils utilisent VML, sous Firefox/Mozilla et autres ils utilisent SVG.

• • Cometd. C’est un mécanisme pour faire du « push » avec le protocole HTTP de manière scalable. Effectivement, la méthode traditionnelle qui consiste à questionner régulièrement le serveur pour simuler le « push » est trop couteuse lorsqu’elle est pratiquée à grande échelle. Il en va de même pour les connexions HTTP qui restent ouvertes. Cela Belgique entraîne un grand nombre de processus ou threads inactifs côté serveur ce qui a également son coût. Actuellement pour gérer le problème à grande échelle avec Comet, il faut prendre un container ou serveur Web spécialisé (Tomcat et Apache ne gèrent pas actuellement). Je crois que Jetty est compatible.

• • Firebug. Ca n’a rien à voir avec le JS mais il a mentionné le débuggeur FireBug et l’a hautement recommandé.

• • Serving JavaScript Fast – un article recommandé par Alex de Cal Henderson. Cliquez ici pour le lire.