HTML5 apporte de nombreuses nouvelles fonctionnalités, notamment concernant les formulaires.

Nous allons voir dans ce billet la spécification HTML Media Capture.
Celle-ci permet d’élargir les capacités des champs de formulaires de type file.
Jusqu’à présent, les champs de formulaires de type file permettaient juste d’ouvrir une fenêtre pour récupérer dans le système de fichiers celui (ou ceux) à envoyer avec le formulaire.
Il est dorénavant possible d’utiliser ces mêmes champs pour utiliser l’un des périphériques de capture (audio, vidéo ou image) pour créer le fichier à envoyer.

Comment le mettre en œuvre ?
La mise en place d’un tel système est particulièrement simple.
Il suffit d’ajouter au champ un attribut capture et le tour est joué ! Cet attribut étant de type booléen, c’est-à-dire que sa seule présence (sans valeur ou quelle que soit sa valeur) suffit à indiquer au navigateur le comportement souhaité.

Enfin… il suffit… pas tant que ça en fait.
En réalité, l’attribut capture n’est pas suffisant, en effet, ce seul attribut ne permet pas de savoir quel type de media est demandé, donc quel périphérique utiliser.
Il est donc nécessaire de préciser aussi l’attribut accept avec une valeur correspondant au type mime souhaité.

Notez que l’attribut capture n’oblige pas l’utilisateur à utiliser un périphérique : il lui est demandé s’il veut envoyer un fichier existant ou s’il veut utiliser le périphérique approprié.

Exemples.
Voici les trois cas possibles d’utilisation à l’heure actuelle :

Compatibilité.
À l’heure actuelle, seuls les navigateurs pour mobiles et tablettes semblent supporter cette fonctionnalité.
Voir la table de compatibilité pour mobiles.
Mais gageons que les versions desktop des navigateurs vont l’implémenter rapidement.

Voir les spécifications du W3C (comprenant des exemples plus avancés).

• solution en PHP ;
• solution en Java ;
• solution en C#.

En gros, la technique consiste à associer au fichier souhaité un en-tête HTTP Content-Disposition qui indiquera que celui-ci doit être téléchargé et non affiché.

Bien entendu, si votre page est uniquement en (X)HTML, vous êtes de la revue ! La seule technique possible est de transformer votre fichier dans un format qui ne peut être affiché par le navigateur (la technique la plus classique étant de le compresser en archive zip).

Mais cela, c’était avant.
Car désormais, HTML5 vous permet de rendre vos fichiers téléchargeables, quel que soit leur format, de façon très simple.

Il suffit d’utiliser l’attribut download.

Comment s’utilise cet attribut ?
Le plus simplement du monde : en l’intégrant à la balise <a> ou <area> !

Quelle valeur donner à cet attribut ?
Celle que vous souhaitez.
Plus exactement, la valeur va correspondre au nom de fichier présélectionné dans la fenêtre de téléchargement, mais si vous ne précisez pas de valeur (download) ou si vous mettez une valeur vide (download=""), alors le nom de fichier par défaut sera celui du fichier original.
Exemples :

Quels types de fichiers peuvent être téléchargés ?
Il n’y a pas de restriction sur les types de fichiers que vous pouvez proposer en téléchargement, néanmoins, ils devront respecter la Same Origin Policy (même domaine, même TLD, même sous domaine, même protocole, même port).
Notez aussi que vous pouvez proposer en téléchargement des fichiers encodés en base64, donc en particulier des fichiers générés depuis le navigateur.

Mais alors, mes codes serveur peuvent être téléchargés ?
Bien sûr que non, heureusement !
Si vous demandez un fichier .php par exemple sur le serveur, celui-ci sera d’abord interprété avant d’être envoyé. Ce sera donc le fichier généré qui sera récupéré et non le fichier contenant le code source.
Il est donc en revanche possible de proposer de télécharger des fichiers images (par exemples) générés dynamiquement sur le serveur.

Quel est le support des navigateur ?
C’est le bémol concernant cet attribut…
À l’heure actuelle, seuls Firefox, Chrome et Opera (en version desktop ou mobile) ne reconnaissent cet attribut, pour les autres navigateurs, vous devrez passer par une solution de contournement.

Comment savoir si un navigateur prend en charge download ?
Il est possible, avec JavaScript, de détecter si la fonctionnalité est supportée, pour cela, on crée un nouvel élément <a> et on vérifie s’il possède une propriété download :

Voir une page d’exemple.

• Standardisation de innerHTML

Introduite par Internet Explorer 4 (de mémoire…), la propriété innerHTML permet de définir le contenu d’un élément en lui affectant sous forme de chaine une portion de code HTML.

Notez qu’il s’agit d’une propriété et non d’une méthode, on l’utilise donc sous forme d’une affectation et non comme un appel de fonction.
Bien que propriétaire IE, cette propriété (sic) s’est largement répandue sur les autres navigateurs et est depuis longtemps largement compatible.
Elle est désormais standardisée (innerHTML) et fait pleinement partie de la spécification HTML5.

• getElementsByClassName()

Nous connaissions déjà les classiques getElementById(), getElementsByName() et getElementsByTagName(), mais beaucoup de développeurs ont longtemps regretté l’absence de possibilité de recherche d’éléments à partir d’un nom de classe (ce qui amenait souvent à utiliser une bibliothèque JavaScript pour pallier ce manque).
C’est désormais rectifié avec l’apparition de la méthode getElementsByClassName().
Cette méthode peut être appliquée à l’objet document ou à un objet HTMLElement. Comme le ‘s’ de ‘elements’ le laisse supposer, elle retourne une collection d’éléments (il est donc nécessaire de faire une boucle sur la collection pour traiter individuellement chaque élément).
Il est possible de spécifier plusieurs noms de classe pour un élément séparés par des espaces, la méthode prend bien entendu en compte cette subtilité.

Cette méthode est accessible sur tous les navigateurs récents, y compris Internet Explorer depuis sa version 8.

• querySelector() / querySelectorAll()

Ces deux nouvelles méthodes font leur apparition avec un fonctionnement un peu différent des précédentes.
Les méthodes du type getElement[s]By… prennent comme argument une chaine correspondant au type d’élément recherché (un id, un nom de balise, de classe ou un name).
Les méthodes querySelector() et querySelectorAll() prennent quant à elles en argument une chaine qui correspond à un sélecteur CSS.
Normalement, toute chaine pouvant servir de sélecteur en CSS est acceptée, y compris les plus complexes. Nous ne listerons pas ici les différents sélecteurs possibles, je vous laisse faire vos propres tests.
Ces méthodes s’appliquent soit à l’objet document, soit à un objet HTMLElement.
querySelector() renvoie un élément HTML qui correspond au premier élément trouvé dans le DOM correspondant au sélecteur, son résultat peut donc être exploité directement.
querySelectorAll() renvoie une collection d’éléments HTML correspondant à tous les éléments correspondant au sélecteur. Pour traiter son résultat, il faudra donc faire une boucle sur chacun de ses membres.

Ces méthodes sont disponibles sur tous les navigateurs modernes y compris Internet Explorer depuis la version 9.

• matchesSelector()

Cette méthode permet de vérifier si un élément correspond à un sélecteur CSS. Tout comme les précédentes, elle prend en argument une chaine correspondant à un sélecteur. Elle renvoie un booléen.

Cette méthode est disponible sur tous les navigateurs récents y compris Internet Explorer depuis la version 9, cependant, seules les versions préfixées sont reconnues : mozMatchesSelector(), webkitMatchesSelector(), oMatchesSelector() et msMatchesSelector().

• L’interface classList

Jusqu’à présent, pour manipuler les classes CSS d’un élément, il était nécessaire d’utiliser des méthodes assez complexes, que ce soit pour vérifier la présence d’un nom de classe, pour en ajouter ou en retirer. Il fallait utiliser le plus souvent des expressions régulières et se méfier des erreurs possibles (typiquement, qu’une recherche sur « classe » ne renvoie pas vrai si l’élément possède la classe « classeN »).
L’interface classList permet de simplifier tout cela.
Elle s’applique à un élément HTML et renvoie une collection de ses noms de classe.

Elle dispose aussi de plusieurs méthodes permettant de manipuler cette liste de classes :

• add() permet d’ajouter un nom de classe à l’élément ;
• remove() permet de retirer un nom de classe à l’élément ;
• toggle() permet d’ajouter un nom de classe si l’élément ne la possède pas, à le retirer sinon ;
• contains() permet de vérifier l’existence d’un nom de classe parmi celles de l’élément.

Cette interface est disponible sur tous les navigateurs modernes à l’exception d’Internet Explorer avant la version 10.

• Conclusion

Ces différentes propriétés et méthodes apportent beaucoup aux développeurs pour ce qui est de la manipulation du DOM. Cependant, il me semble que de nombreuses méthodes utiles ont été oubliées, que ce soit en rapport à l’insertion d’éléments dans le DOM, à la possibilité de faire des recherches en remontant l’arborescence (retrouver facilement un élément à partir d’un de ses descendants). Espérons que les futures implémentations combleront ces manques en s’inspirant, par exemple, des différentes bibliothèques JavaScript.

Par aucun navigateur ? Vraiment ?

En fait, pas tout à fait : parmi les différentes utilisations de la balise menu, une est utilisable par Firefox depuis la version 8 : la personnalisation du menu contextuel lié à un élément de la page (ou de la page elle-même).

La syntaxe de la balise menu est la suivante :

où type correspond au comportement attendu pour le menu et id l’identifiant du menu.
Cette balise peut (dans le cadre du menu contextuel) contenir soit des sous-menus représentés par une nouvelle balise menu soit des éléments de menu représentés par des balises menuitem.

Bon, assez d’explications théoriques, passons à la pratique avec un exemple :

Dans cet exemple (relativement simple), nous ajoutons des liens vers developpez.com et différents forums du site.
Vous pouvez constater que le type de menu est context pour préciser qu’il s’agit de personnaliser le menu contextuel.
D’autre part, le sous-menu et les éléments des menus possèdent des attributs label indiquant le texte à afficher correspondant à chaque option.
Les éléments de menus possèdent quant à eux des attributs icon (image apposée à côté de l’élément) et onclick (action JavaScript à lancer au clic sur cet élément).

Pour autant, vous aurez beau ajouter cette portion de code dans votre page et faire des clics droits partout dans la page (sur Firefox bien entendu) pour tester, rien ne se passera !
En fait, nous avons oublié l’essentiel : déterminer à quel élément de la page le menu contextuel est associé.
Pour préciser cela, il suffit d’ajouter un attribut contextmenu à l’élément souhaité. La valeur de cet attribut doit correspondre à l’identifiant (attribut id) du menu.
Dans l’exemple suivant, nous posons cet attribut sur la balise body afin que le menu contextuel s’applique sur toute la page :

Notre exemple est maintenant fonctionnel. Vous pouvez voir un exemple en ligne.

• La syntaxe

La syntaxe de base est relativement simple et ne pose pas de problème :
 
Il est toutefois important de noter que même si elle ne possède pas forcément de contenu, elle reste susceptible d’en avoir (le script en lui-même) ce qui fait que contrairement à une balise mais à l’instar d’une balise , elle n’est pas autofermante et doit posséder une balise fermante.

• Les attributs

L’attribut src ne pose habituellement pas de gros soucis.
Cet attribut correspond à l’URL à laquelle se trouve le fichier correspondant. Attention toutefois, dans le cas d’une URL relative, de bien comprendre où se trouve le script en fonction de l’URL effective (celle affichée par le navigateur) qui appellera le script. Attention donc par exemple aux include en PHP.

En revanche, deux attributs sont assez souvent confondus, il s’agit des attributs language et type.
Il faut déjà savoir que le premier est deprecated depuis HTML 4 alors qu’au contraire, le second est required. Cela signifie qu’il faut bannir language.
La syntaxe correcte devient donc
 
Mais alors, si l’attribut language est à bannir, pourquoi le retrouve-t-on si souvent ?
D’abord, parce que malheureusement, plusieurs facteurs empêchent de l’éradiquer.
Déjà, de nombreux scripts usuels sont bien référencés et recopiés tels quels bien que très anciens. Du coup, l’attribut se propage facilement.
D’autre part, peut-être surtout, parce que beaucoup ignorent la signification de cet attribut.
A la base, il servait à indiquer le langage et la version du langage de script utilisé. Cependant, aucune norme n’a été trouvée pour savoir ce qu’il pouvait bien contenir, ce qui a donc amené à ce qu’il soit déprécié. De toute façon, le seul langage de script universellement reconnu par les navigateurs est JavaScript (quelle que soit sa déclinaison : ECMAScript, JScript, …) donc l’information n’a que peu d’intérêt. De même, préciser une version à utiliser n’a pas vraiment de sens : JavaScript, pour des raisons de rétro-compatibilté ne perd pas de fonctionnalités, il ne fait qu’en accepter de nouvelles !

Note : en HTML5, l’attribut type n’est plus requis et dans cette version, la syntaxe
 
est désormais suffisante.

• Le contenu

Pendant longtemps (et on retrouve encore couramment la syntaxe), les scripts étaient entourés soit de commentaires HTML soit d’entités CDATA :

Là encore, la pratique remonte à un temps que les moins de 20 ans (voire plus !) n’ont pas connue !
Ces syntaxes, héritées du XML, servaient à l’origine à éviter que les navigateurs ne possédant pas d’interpréteur JavaScript (on ne parle pas de ceux qui ont JavaScript désactivé, bien de ceux pour lesquels JavaScript n’existe tout simplement pas !) n’essayent d’interpréter le contenu du script comme du HTML. De mémoire, on parle là de IE3 et de NS3. Il me semble que la part de marché de ces navigateurs atteint depuis longtemps un seuil qui rend cette technique quelque peu obsolète !

• Où placer les scripts ?

Plusieurs écoles s’affrontent à ce niveau.
Une chose est sure : il est demandé de séparer les différentes couches du document : le HTML pour le contenu, le CSS pour la mise en forme et le JavaScript pour l’ergonomie (ou le le comportement). Ainsi, insérer ses scripts en plein milieu du document est assez maladroit.
Pendant un temps, les bonnes pratiques recommandaient de placer les scripts entre les balises <head> et de les initialiser via l’événement onload de l’objet window.
Cette façon de procéder est plutôt satisfaisante mais l’événement onload implique que l’ensemble du contenu de la page soit chargé avant de lancer les scripts (donc y compris les éléments dits remplacés : images, iframes, object, etc.) et comme les pages Web deviennent de plus en plus gourmandes en ressources externes, cela fini par nuire à l’expérience utilisateur.
Différentes techniques existent pour pallier cela, entre autre, l’utilisation de l’événement DOMContentLoaded, mais qui n’est pas (encore) suffisamment universel pour être totalement satisfaisant.
La problématique est que pour pouvoir utiliser un script, il faut que les éléments du DOM qu’il va utiliser existent au moment où il est appelé. Une solution efficace est alors de placer les scripts juste avant la fermeture du document (avant la balise </body>), ce qui permet d’être sûr que les éléments du DOM ont été créés et de conserver la notion de séparation des couches.
Gardez toutefois à l’esprit que quelle que soit la solution choisie, elle aura une importance majeure lors de l’écriture de codes destinés à être réutilisés.

La syntaxe est pourtant simple :
document.write(arg1, arg2, ..., argn);
Les arguments attendus sont des chaînes de caractères (ou tout du moins des arguments possédant une méthode toString())
Vous noterez au passage que le nombre de paramètres que l’on peut passer à cette méthode est indéterminé.
L’instruction précédente aura pour effet d’ajouter la valeur de chaque paramètre dans la page.
Par exemple
document.write('toto', 12, [1,2,3]);
affichera :

toto121,2,3

Notez que chaque argument est ajouté à la suite du précédent sans insérer de séparateur.
Malgré tout, certaines valeurs affichent un résultat inattendu :
document.write(false, {toto: 'tata', foo: 'bar'});
affichera :

false[object Object]

c’est-à-dire qu’un booléen ne sera pas transformé en 0 ou 1 mais en false ou true et un objet affichera (en fonction du navigateur) [object Object].

Jusque là, rien de vraiment compliqué à comprendre, d’autant que l’on passe habituellement un seul paramètre correspondant à une chaîne à afficher.

Cependant, le comportement de cette méthode dépend de l’état du document au moment de son appel.
En effet, un document HTML peut avoir deux états distincts : ouvert ou fermé.
Lorsque le navigateur reçoit un contenu HTML à afficher, il commence par ouvrir un document (le flux) puis interprète le code HTML en affichant son contenu et en construisant le DOM et une fois l’intégralité du code interprété, il ferme le document.
Pendant que le document est ouvert, si le navigateur rencontre une instruction JavaScript write(), alors ses arguments sont insérés à l’emplacement de cette instruction dans le code.
C’est le comportement attendu de cette méthode.
Mais il faut savoir que document.write() a besoin que le document soit ouvert pour pouvoir fonctionner correctement. Que se passe-t-il alors si le document est fermé ?
Dans ce cas, JavaScript va appeler en interne l’instruction document.open() puis exécuter le write().
Or document.open() correspond à l’ouverture du flux d’affichage, ce qui signifie que l’appel à cette méthode va recréer un nouveau flux, en commençant par supprimer l’existant.
Pour vous en convaincre, ouvrez une console JavaScript (par exemple Firebug pour Firefox) et dans la ligne de commande, tapez l’instruction
document.open();
et vous constaterez que la page va devenir blanche. Au passage, vous noterez aussi que l’indicateur de chargement se met en place (à la place du favicon), ce qui est le cas lorsque le flux est ouvert.
De la même manière, si vous entrez
document.write('Hello world !');
dans la console, vous constaterez que l’ensemble du contenu a été remplacé par le message « Hello world ! ». Vous pourrez aussi vérifier que l’indicateur de chargement est toujours actif : le document n’a pas été refermé.
Si ensuite vous entrez l’instruction
document.close();
dans la console, l’indicateur de chargement disparaitra au profit du favicon par défaut.

La première impression que l’on pourrait avoir en comprenant ce fonctionnement serait de se dire qu’il faut effectivement faire attention au contexte avant d’utiliser cette méthode.
En fait, il faut surtout considérer write() comme une méthode à bannir.
Déjà, parce qu’une méthode dont on ne peut garantir le comportement n’est pas à recommander.
Ensuite, parce que les bonnes pratiques en développement Web préconisent de séparer les couches : HTML pour l’affichage, CSS pour la mise en forme et JavaScript pour le comportement : utiliser la méthode write() implique d’introduire au niveau de l’affichage du JavaScript qui n’a rien à y faire, surtout que pour manipuler le document, de nombreuses méthodes du DOM sont disponibles et beaucoup plus fiables.
On pourrait aussi évoquer le fait que l’utilisation de write() interdit l’accès aux informations à ceux qui, pour une raison quelconque, ont JavaScript désactivé. Mais surtout, son utilisation (et son existence) force les navigateurs à une pratique particulièrement désagréable et dommageable qui est le chargement des scripts de façon synchrone.
En effet, l’affichage de la page doit être garantit par le navigateur, or si un script possède une instruction write(), alors il est important de pouvoir prévoir de façon certaine à quel endroit du document ses paramètres seront affichés, c’est pour cela que les navigateurs bloquent l’interprétation de la page pendant le chargement et l’évaluation des scripts (à la différence des autres éléments de la page, comme les images ou les iframes) ce qui retarde d’autant l’affichage du reste du contenu.

Pour rappel, le noyau JavaScript (aussi appelé core JavaScript), par opposition au DOM JavaScript (ou JavaScript côté client) regroupe les objets natifs de JavaScript et surtout, la partie censée être commune à toutes ses variations.
Il regroupe en particulier les objets natifs Array et String qui ont vu leur prototype amélioré.
Il est à noter que ces ajouts sont aussi disponibles (sauf mention contraire) dans Internet Explorer depuis la version 9.

• L’objet Array

La méthode every()
Cette méthode permet d’appliquer à tous les membres du tableau une fonction de rappel afin de savoir si tous les éléments du tableau remplissent une condition.
Syntaxe
Array.every(callback, thisObjet);
Exemple

La méthode filter()

Comme son nom l’indique, cette méthode permet de filtrer les éléments d’un tableau selon le résultat renvoyé par une fonction de rappel.
Syntaxe
Array.filter(callback, thisObjet);
Exemple

La méthode forEach()
Cette méthode permet d’appliquer un traitement à chaque élément du tableau.
Syntaxe
Array.forEach(callback, thisObjet);
Exemple

La méthode map()
La méthode map() va appliquer à chaque élément du tableau le traitement de la fonction de rappel.La méthode map()
Syntaxe
Array.map(callback, thisObjet);
Exemple

La méthode some()
Similaire à la méthode every(), cette méthode va vérifier si au moins un des éléments du tableau est valide selon le résultat renvoyé par la fonction de rappel.
Syntaxe
Array.some(callback, thisObjet);
Exemple

• L’objet String

Ces méthodes renvoient la nouvelle chaîne mais ne modifient pas celle d’origine.

La méthode trim()
Supprime tous les caractères d’espacement en début et fin de chaîne.
Syntaxe
String.trim();
Exemple

La méthode trimRight()
Supprime les espacements en fin de chaîne.
Syntaxe
String.trimRight();
Exemple

La méthode trimLeft()
Supprime les espacements en début de chaîne.
Attention : étonnamment, cette méthode n’est pas (encore) disponible pour Internet Explorer et Opera…
Syntaxe
String.trimLeft();
Exemple

À noter aussi, pour l’objet Date, l’apparition de la méthode toISOString().

8h30, je suis sur le parking et avance vers le site de Euratecnologies de Lille. Déjà, rien que pour la réaffectation de ce bâtiment, le détour en valait la peine.

Après avoir récupéré mon badge et mon petit cadeau, un éléphant rose (ça va se chamailler à la maison), je me dirige vers l’auditoire pour la keynote présentée par Jean-Marc Fontaine de Alter Way.
La bienvenue nous est souhaitée et la présentation des deux jours nous est narrée, tout en nous présentant l’AFUP et en nous motivant pour ouvrir des antennes dans nos régions (peut-être une bonne idée à creuser là).

Le sujet de la première conférence à laquelle j’ai assisté est la présentation de PHP 5.4 par Julien Pauli, nous expliquant les grandes nouveautés, qui ne se trouvent pas forcément dans le langage, mais bien dans sa construction, avec la mise en place de RFC, permettant à chaque utilisateur d’émettre des changements dans le langage.
Un cycle de vie déterminé de 3 ans par mise à jour majeure et de 1 an pour une mise à jour mineure.
De plus une bonne nouvelle est que la descendance ne sera plus cassée dans les versions mineures.
Bien sûr, les nouveautés liées au langage nous sont présentées, mais cela n’est plus un secret et l’on trouve tout sur developpez.com.
Par contre, Julien nous annonce un gain de performance de l’ordre de 55% par rapport à PHP5.3, avec benchmark à la clé.
Julien nous a promis ses slides sur le site de l’AFUP très prochainement.

Ensuite, j’ai assisté à l’industrialisation du site lamaisondevalerie.fr , faisant partie du groupe Conforama, présentée par Sophie Beaupuis.
Ici expliquer en quelque mots serait difficile tant les infos étaient nombreuses, on a pu voir tout le panel d’outils utilisés pour le développement de son application (très orienté Zend avec la suite de produit complets).
Ce qui était agréable dans cette présentation est que madame Beaupuis s’est mouillée en nous expliquant les freins liés à son projet et a eu l’honnêteté de dire ‘désolée je ne connais pas’.

J’ai pris 5 minutes pour vous faire ces quelques lignes et je remercie Jean Marc Fontaine de m’avoir trouvé un petit Wifi.
Ce soir je vous poste la suite de cette première journée.
Un seul regret actuellement, est de ne pas avoir pris de CV avec moi, parce que les offres d’emploi ici sont palpables… Merci le réseautage !

Par MaitrePylos

Faisons une petite analogie.
Imaginons que vous ayez une poule. Tous les matins, vous souhaitez savoir combien d’œufs ont été pondus, vous envoyez donc quelqu’un les compter.
J’imagine, qu’au moment même où cette personne part compter les œufs, il ne vous viendrait pas à l’esprit de l’appeler pour lui demander le compte : la moindre des choses est d’attendre qu’elle soit revenue car avant, elle ne connait pas l’information !

Avec AJAX, c’est exactement pareil. Le premier A de l’acronyme signifie asynchronous (asynchrone), c’est-à-dire que JavaScript ne va pas attendre la réponse du serveur avant de continuer à exécuter le code, sauf bien entendu si vous avez spécifié le mode synchrone.
Ainsi, le seul moment où l’on est sûr d’avoir reçu la réponse est lorsque la propriété readyState de l’objet XMLHttpRequest vaut 4 et que la propriété status correspond à un code de réussite de la requête (classiquement 200). C’est pourquoi tous les traitements se basant sur la réponse du serveur doivent être traités dans le callback de la requête..

Avant d’écrire son code, il est donc fondamental de se demander si les données que l’on veut utiliser existent ou non.

A titre d’exemple, un petit code :

Ici, le premier alert() affiché sera celui de la dernière ligne : JavaScript n’attend pas la réponse du serveur pour continuer à exécuter le code et cette alerte affichera undefined, puisqu’au moment où cette instruction est interprétée, aucune affectation n’a encore été faite pour maVariable ! Puis, lorsque le serveur aura répondu, le second alert() sera affiché avec cette fois la valeur attendue.

Voir aussi :

• Vos premiers pas dans les nouvelles technologies
• Comprendre les mécanismes d’AJAX
• La FAQ AJAX

Cette notion de fonction de rappel est d’autant plus difficile à appréhender pour les débutants qu’il existe différentes façons distinctes de la définir, dont certaines erronées.

Les trois plus fréquentes sont les suivantes :

1. document.onclick = maFonction();
2. document.onclick = "maFonction()";
3. document.onclick = maFonction;

1. setTimeout(maFonction(), délai);
2. setTimeout("maFonction()", délai);
3. setTimeout(maFonction, délai);

Les exemples (1) sont tout simplement faux et ne produiront pas le résultat attendu. Ils sont un mélange entre les deux formes suivantes et dues à la confusion entre une fonction et le résultat de l’exécution de celle-ci.
Lorsque l’interpréteur JavaScript rencontre la notation maFonction() (donc avec les parenthèses), il comprend qu’il faut exécuter la fonction et le fait donc sur le champ. Or ce qu’attendent les méthodes nécessitant une fonction de rappel, c’est une référence à la fonction. Avec la notation des exemples (1), c’est le résultat de l’exécution qui sera affecté au clic ou au timer, sans attendre le moment souhaité par le développeur.
Les exemples (2) sont syntaxiquement corrects, mais fortement marqués d’obsolescence. En fait, dans ces cas ci, il n’y a pas de fonction de rappel de définie mais une portion de code qui sera évaluée au moment de l’appel. En interne, JavaScript va utiliser la méthode eval() pour interpréter le code, comme le montre l’exemple suivant :

Dans cet exemple, c’est bien le message eval() is evil ! qui sera affiché. Cette façon de procéder, liée à la préhistoire de JavaScript, est fortement déconseillée !

Dans les exemples (3), c’est bien la référence à la fonction qui est utilisée De ce fait, lorsque le moment sera venu, cette fonction pourra être exécutée sans passer par l’utilisation de eval(), comme le montre l’exemple suivant :

C’est bien le message toto qui est affiché lors du clic sur la page.

Note : si vous utilisez une console (par exemple celle de Firebug) pour tester les codes ci-dessus et que vous faites « Exécuter » deux fois de suite, vous obtiendrez le message eval() is evil, cela est dû au fait que l’injection du code dans le document utilise elle aussi des méthodes utilisant en interne eval() qui vient d’être redéfinie.

Mais alors, comment passer des paramètres à la fonction de rappel ?
Effectivement, le seul moyen de passer des paramètres à la fonction de rappel était celle des exemples (2), qui sont déconseillés.
Pour passer des paramètres, il va falloir utiliser une quatrième technique qui consiste à englober l’appel de la fonction de rappel dans une fonction anonyme. Cette fonction anonyme étant définie au moment de l’affectation, elle correspond donc à une référence à une fonction et non à une exécution de celle-ci :

Ce code affiche bien le paramètre passé à la fonction toto, elle-même englobée dans une fonction anonyme.