Ouf, il faut vraiment garder le doigt sur le pouls quand il s'agit de jQuery. Depuis la première partie de ce billet, il n'y a pas eu une, mais trois nouvelles versions de jQuery : la version actuelle est donc la 1.2.6. Et je suis heureuse de vous annoncer que, depuis, je participe à l'effort de mise à jour du module jQuery Update, ce qui implique non seulement de suivre cette cible mouvante, mais aussi d'éliminer les bogues qui surgissent à toutes sortes d'endroits inattendus en raison des changements majeurs d'API arrivés avec la version 1.2. Écraser un bogue à un endroit en fait parfois apparaître un nouveau dans un module complètement différent, ce qui rend les tests assez ardus, mais beaucoup de gens sont déterminés à livrer ce travail et je crois que la fin est peut-être en vue.
Il existe déjà une version D6 de jQuery Update, portée par webchick; ce module continuera donc fort probablement de faire le pont entre deux cycles de publication disparates, mais on peut espérer qu'avec le temps, le processus de mise à jour et de vérification de la rétrocompatibilité deviendra de plus en plus fluide. Une chose qui aidera certainement à cet égard, c'est l'adoption, par les développeurs de modules contribués, de pratiques exemplaires dans l'écriture du code jQuery de leurs modules. Bien sûr, nous ne pourrons jamais prédire quelles méthodes et quelles expressions de sélecteurs seront dépréciées, mais si nous gardons au moins notre code conforme à une « façon Drupal » générale de faire les choses, il sera plus facile de corriger les bogues, puisque le même correctif pourra fonctionner pour plusieurs modules.
Section d'exemples pointus
Avertissement : jargon technique ci-après
Un bon exemple du genre de pratiques exemplaires dont je parle est la nouvelle approche pour attacher des comportements dans Drupal 6. Quand on apprend jQuery pour la première fois, la plupart d'entre nous apprenons à placer tout notre code dans la fonction $(document).ready, comme ceci :
$(document).ready(function(){
// do some fancy stuff
});
Cela garantit que notre code sera exécuté dès que le DOM est chargé, pour manipuler des éléments et lier des comportements à des événements selon nos instructions. Toutefois, depuis Drupal 6, nous n'avons plus du tout besoin d'inclure la fonction $(document).ready() dans notre code jQuery. Nous plaçons plutôt tout notre code dans une fonction que nous assignons comme propriété de Drupal.behaviors. Pardon? D'accord, je recule un peu. Dans le répertoire misc/ de notre installation Drupal, nous avons non seulement le fichier jquery.js, mais aussi drupal.js (et plusieurs autres fichiers js qui contrôlent des fonctionnalités propres à certaines pages ou à certaines fonctions d'administration, p. ex. upload.js), qui régit l'utilisation générale de jQuery dans Drupal. Il déclare l'objet JavaScript Drupal, destiné à contenir des propriétés auxquelles d'autres fichiers js doivent accéder et qu'ils doivent utiliser. Par exemple, la propriété Drupal.settings sert à transmettre un tableau de paramètres d'un module au code js de ce module. Il suffit pour cela d'appeler drupal_add_js() dans votre code PHP en vous assurant de passer « setting » comme deuxième paramètre, p. ex. :
drupal_add_js(array('mymodule' => $array_of_settings), 'setting');
Dans votre fichier js, vous pouvez ensuite accéder à ces paramètres à Drupal.settings.mymodule. Vous avez ainsi étendu l'objet Drupal.settings avec la propriété mymodule, qui est elle-même un objet contenant tous vos paramètres.
Une autre propriété de l'objet Drupal est l'objet behaviors, c'est-à-dire Drupal.behaviors; lorsque nous voulons que notre module ajoute de nouveaux comportements jQuery, il suffit d'étendre cet objet. Tout le code jQuery de votre module pourrait être structuré comme ceci :
Drupal.behaviors.myModuleBehavior = function (context) {
//do some fancy stuff
};
Mais, vous demandez-vous peut-être, tout ce que cela fait, c'est déclarer une fonction : comment est-elle appelée? Eh bien, tout cela est pris en charge dans drupal.js. Celui-ci comporte une fonction $(document).ready qui appelle la fonction Drupal.attachBehaviors, laquelle parcourt à son tour l'objet Drupal.behaviors en appelant chacune de ses propriétés — toutes des fonctions déclarées par divers modules comme ci-dessus — et en passant le document comme contexte. La raison de procéder ainsi, c'est que si votre code jQuery fait des appels AJAX qui ajoutent de nouveaux éléments DOM à la page, vous voudrez peut-être que vos comportements (p. ex. masquer tous les éléments h3, ou autre) soient aussi attachés à ce nouveau contenu. Mais comme celui-ci n'existait pas au moment où le DOM a été chargé et où Drupal.attachBehaviors s'est exécuté, aucun comportement n'y est attaché. Avec la structure ci-dessus, toutefois, il suffit d'appeler Drupal.behaviors.myModuleBehavior(newcontext), où newcontext serait le nouveau contenu livré par AJAX, ce qui évite de rattacher les comportements à tout le document une fois de plus. Voyez ici l'exemple complet d'utilisation de ce code.
C'est à nedjo que nous devons cette solution élégante à un problème classique, et elle n'est d'ailleurs pas exclusive à Drupal 6. Le paquet jstools de Drupal 5 utilise exactement ce modèle pour contrôler les comportements de ses modules : collapsiblock, tabs, jscalendar, etc.
</jargon technique>
Ce qui précède illustre la tendance vers des façons standard d'utiliser jQuery dans Drupal, ce qui, comme je le disais, devrait vraiment aider lors des mises à jour vers différentes versions. Comme pas de plus dans cette direction, stella a lancé un plan pour ajouter le code js au module Coder, ce qui nous permettra de vérifier notre conformité aux normes jusqu'au niveau des lignes de code individuelles.
Au-delà des détails pointus
Un gros lot nous attend si nous réussissons à mettre jQuery Update à jour : le plugiciel UI (voyez son excellent nouveau site ici, avec une foule de démos), dont j'ai parlé dans la première partie, et pour lequel il existe un module Drupal D6 qui le fournit. On a tenté de l'offrir pour Drupal 5 sans passer par jQuery Update : le module jQuery UI Backport de starbow, qui place jQuery 1.2.1 et jQuery UI 1.0 dans un espace de noms distinct afin qu'ils puissent être inclus dans Drupal 5 sans entrer en conflit avec l'ancienne version de jQuery déjà présente. Mais starbow lui-même admet que ce n'est pas la solution la plus propre et que jQuery Update est vraiment la voie à suivre — ce avec quoi je suis d'accord, même si c'est un peu dommage, car il a dû être tout un défi de démêler tous ces espaces de noms! Quoi qu'il en soit, comme je le disais — et je suis peut-être naïvement optimiste —, on dirait que nous y sommes presque.
Mais avant de nous emballer en pensant à tous les beaux éléments déplaçables et à toutes les zones de dépôt que nous pourrons alors ajouter à nos modules, il importe de se demander s'ils leur sont vraiment essentiels. Car, bien entendu, les inclure ajoutera immédiatement deux dépendances de modules. Si la fonctionnalité fondée sur UI ne sert qu'à améliorer l'interface d'administration de votre module, cela me semblerait un peu extravagant, à moi du moins. Surtout quand on considère que des fonctions comme le glisser-déposer ne sont tout simplement pas attendues par les utilisateurs de D5, alors que dans D6 elles sont la norme (mais seulement parce que le code qui les fournit fait déjà partie du cœur).
AHAH et glisser-déposer : profiter des bienfaits de jQuery sans écrire une ligne de jQuery
Ce qui nous amène enfin à deux merveilleux nouveaux morceaux de code js que les développeurs de modules Drupal 6 peuvent utiliser : ahah.js et tabledrag.js. Le premier est une refonte du code utilisé dans le module AHAH Forms Framework de D5, qui permet de créer des formulaires auxquels de nouveaux éléments peuvent être ajoutés dynamiquement grâce à AHAH (le cousin moins sophistiqué d'AJAX). C'est une fonctionnalité extrêmement utile, que j'ai été ravie de pouvoir utiliser dans la version D6 de Quick Tabs, qui s'y prêtait parfaitement : lors de la création d'un bloc Quick Tabs, il suffit de cliquer sur un bouton pour ajouter instantanément un nouvel onglet. Je dirais toutefois ceci : même s'il est formidable que le code jQuery soit déjà là pour vous, ce n'est vraiment que la moitié du travail quand il s'agit de créer des formulaires AHAH; l'autre grand défi consiste à configurer le rappel AHAH pour qu'il renvoie la nouvelle version de votre formulaire sans compromettre la sécurité de FAPI.
Ce n'est pas le cas de tabledrag, cette fonctionnalité du cœur délicieusement simple à utiliser qui vous permet d'ajouter à l'interface d'administration de votre propre module la fonction de réorganisation par glisser-déposer que vous avez sans doute vue sur la page des blocs de D6. Pour apprendre à l'utiliser, pas besoin de chercher plus loin qu'api.drupal.org, où la documentation de la fonction drupal_add_tabledrag() est carrément spectaculaire (toutes proportions gardées, bien sûr ;-) Mais je vous laisse avec une autre excellente ressource qui vous aidera à comprendre ces trucs AHAH un peu corsés : le screencast très complet de drupaldojo sur AHAH par quicksketch, qui aborde d'ailleurs brièvement le glisser-déposer.
Bon, ce billet est finalement beaucoup plus long que prévu, mais j'espère qu'il ne s'égare pas trop. Je crois que le sujet de jQuery ne fera que gagner en pertinence pour les développeurs Drupal en général, à mesure que la relation entre les deux projets s'approfondit et mûrit. Ils semblent vraiment faits l'un pour l'autre.