2. La table Javascript

Une fois que le contexte est placé, nous pouvons écrire la table Javascript. Pour être utilisée par GXMLDISPLAY il faut l’écrire sous la forme d’un objet Javascript, dont la partie définition est représentée avec un fond rouge dans l’affichage suivant. Cet objet inclue 2 listes flags_array et getf_array, ainsi que le nombre d’éléments de chaque liste (flags_n et getf_n). La liste flags_array inclue toutes les colonnes de la table, la liste getf_array n’inclue que les colonnes qui doivent être affichées. Dans l’exemple, nous constatons que la colonne SECTOR ne sera pas affichée dans la table dynamique.

Enfin l’objet ObjData inclue la matrice data_array, dont le nombre de colonnes est défini par data_c et dont le nombre de lignes est défini par data_r. Dans l’exemple, la première ligne de la matrice est marquée avec un fond jaune, les données SMILES sont marquées en gris.

Nous constatons que les images de la colonne IMG sont présentées sous la forme d’un tag <IMG>, avec une problématique purement ‘données’ nous pourrions l’éviter, mais nous voulons un affichage de l’image, il est nécessaire de modifier le contenu (manuellement ou via un autre composant logiciel) de cette colonne. Ici il s’agit de l’affichage d’un fichier local dont nous fournissons le chemin d’accès relatif. C’est également le cas pour la colonne 3DREF mais sous la forme d’une URL (tag <A HREF...) vers un fichier de données.

Les colonnes PROTEIN et LIG montrent des URLs vers les références des protéines et des ligands au sein de la PDB, par exemple pour IOIF vers [ https://www.rcsb.org/structure/1OIF ] et pour IFM vers [ https://www.rcsb.org/ligand/IFM ].

Externalisation de la table Javascript

La table Javascript constitue un fichier (dans l’exemple data_obj.js) qui est distinct des modules d’affichage et qui est appelée comme eux dans la page HTML incluant la table dynamique. Nous utilisons l’objet ObjData de manière à faciliter le passage des données. Le composant GXMLDISPLAY n’utilisait pas ce mécanisme dans les versions initiales, les tables et scalaires étaient directement déclarées, sans encapsulation dans un objet. Les règles restreignant les requêtes HTTP multi-origines (Cross-origin resource sharing) ont nécessité ce changement d’approche.
Il existe d’autres possibilités pour implémenter des données partagées, par exemple un mécanisme d’import/export combiné à des modules, mais dans le contexte GXMLDISPLAY, l’objet s’est avéré le plus simple.