Cet article aborde la cas d’une table dynamique à l’intérieur d’un article WordPress, les applications sont multiples, et c’est une question qui peut se poser si nous voulons afficher un ilot de données sur plusieurs publications, sans double saisie et avec une gestion centralisée. Une table dynamique dans un post peut également faire partie d’un cahier de laboratoire électronique basé sur un CMS. Nous allons utiliser GXMLDISPLAY, avec peu de modifications par rapport à une utilisation dans un site statique ou même en local, mais il faudra passer par un plugin WordPress capable d’insérer des snippets (extraits, fragments de code) HTML, Javascript et CSS dans les articles.
Publication initiale : buidez.net (2012) – revu en 2025, mise à jour en Mai 2026.
1. Avec Easy JS/CSS
J’ai longtemps utilisé cette extension mais elle n’est plus maintenue, cette section est pour mémoire car l’utilisation de ce plugin donne une idée simplifiée de l’approche. Il n’y a pas beaucoup de différences avec l’utilisation de GXMLDISPLAY hors de WordPress, consulter l’article [ https://buildblog.buildez.fr/javascript-gxmldisplay-et-tables-dynamiques/ ] sur ce blog pour comprendre les structures de données et les fonctions utilisées.
Les composants et les données
L’utilisation d’Easy JS/CSS consistait en deux étapes : i) le chargement de codes Javascript (données et composants) dans la partie <HEAD> de la page HTML et ii) l’appel aux fonctions Javascript dans ce header ou dans le corps <BODY> de la page HTML. Ces codes incorporant aussi des éléments de décoration, il fallait aussi introduire des références vers des fichiers CSS. Une fois installé dans l’interface d’édition de WordPress, pour un article ou une page donnée, nous avions un formulaire du type :
 |
Dans le premier champ, il fallait indiquer les composants JavaScript à inclure, ici nous avons des données mol_blog.js qui correspondait à une table JavaScript, puis le composant général GXMLDISPLAY (fichier gxmldisplay.js qui est dans un répertoire accessible à tous les articles). Puis nous avions un autre champ, pour l’appel aux fonctions (gxmldisplay_init, gxmldisplay_selector de GXMLDISPLAY). Puis deux autres champs dédiés aux feuilles de style CSS, dans le header (gxmldisplay.css) ou le corps (pas de fichier dans cet exemple).
En fait, nous ne faisons rien de plus qu’injecter des morceaux d’un bloc HTML dans la page générée par WordPress, avec les CSS (feuille_style.css), les données (table_javascript.js), les composants (tel gxmldisplay.js), et les fonctions(gxmldisplay_init, gxmldisplay_selector). Dans une formulation classique, une page HTML montre le même type d’enchainement, avec l’ordre CSS, données, composant, fonctions :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<HTML> <HEAD> ... <LINK REL=STYLESHEET TYPE="text/css" HREF="path/feuille_style.css"> <SCRIPT LANGUAGE=JavaScript SRC="path/table_javascript.js"></SCRIPT> <SCRIPT LANGUAGE=JavaScript SRC="path/gxmldisplay.js"></SCRIPT> <SCRIPT LANGUAGE="JavaScript">gxmldisplay_init();</SCRIPT> </HEAD> <BODY ...> ... <TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="600"> <TR><TD> <FORM> <SCRIPT LANGUAGE="JavaScript">gxmldisplay_selector('n','','','all');</SCRIPT> <SCRIPT LANGUAGE="JavaScript">gxmldisplay_selector('y','COLONNE',str_filtre,'inc');</SCRIPT> ... |
Dans la plupart des cas, ces éléments peuvent être regroupés dans l’entête de la page HTML, s’il n’y a pas de problématique liée à la synchronisation (le processus reste séquentiel). Si les données devaient arriver de manière asynchrone l’écriture serait différente. Ce cas se présentera si les données sont lues via une requête vers un autre serveur ou s’il y a un traitement intermédiaire (par exemple des données XML interprétées par un parseur). Le temps passé à ces tâches fait que les données risquent de ne pas être disponibles lors de l’appel à gxmldisplay_init ou gxmldisplay_selector.
La table dynamique
Ensuite il suffisait de insérer la table dans le bloc du message, en passant par l’onglet Code de l’éditeur, sans formulaire, sans table englobante car le formatage était pris en compte par le multicolonnage WordPress, par exemple :
 |
A cette époque nous utilisions aussi des éditeurs offline (1,2) comme Zoundry Raven, qui modifiaient parfois le code et obligeaient à quelques ‘contorsions’, mais il était possible d’y arriver (avec un peu de rigueur).
Aujourd’hui cette approche n’est plus possible, indépendamment de l’indisponibilité du composant, WordPress réinterprète le code et va ‘sortir’ les éléments JavaScript de la table, il faut également passer par un extrait de code pour la partie HTML.
Liens et lectures
- (1) Un éditeur offline permettait d’écrire des articles en local (sur son PC) puis de les ‘pousser’ vers le CMS pour publication. C’était une approche très pratique, car ces éditeurs de blog étaient WYSIWYG, ou en tout cas beaucoup plus que l’éditeur WordPress de l’époque (nous sommes au début des années 2010). Certains incluaient également des fonctions de prévisualisation intégrées ou via un navigateur. Microsoft proposait Windows Live Writer, nous avions aussi Zoundry Raven, d’autres produits du même type étaient disponibles sur d’autres plateformes. Nous pouvions donc travailler sur les articles sans être connectés, cette approche permettait aussi d’avoir une copie du site (par définition). Par contre, il y avait peu de possibilités pour intégrer des composants JavaScript afin de réaliser des contenus dynamiques.
- (2) Pour rechercher des outils de ce type utiliser des mots clés tels que ‘desktop blog-publishing’.
- Windows Live Writer [ https://en.wikipedia.org/wiki/Windows_Live_Writer ].
- Open Live Writer [ https://en.wikipedia.org/wiki/Open_Live_Writer ].