5. Quelques questions complémentaires

Une fois que nous avons les données et les scripts en place, il nous faut les intégrer dans un écosystème logiciel. Si ce type de méthodologie est utilisée intensivement pour l’exposition d’ilots de données, il faut tenir compte de quelques aspects, de manière à optimiser l’affichage, l’organisation des composants dans l’arborescence locale ou serveur, et enfin la gestion des caractères accentués.

Contrôle de l’affichage

L’affichage est contrôlé par une feuille de style CSS que l’on appelle en premier dans l’entête de la page HTML et qui permet préciser l’apparence des composants de la table :

Gestion des caractères accentués

Dans la table nous remarquons qu’il y a une molécule (calistégine) avec un nom incluant un caractère accentué qui est correctement rendu. Il y a un choix à faire, soit on paramètre toute la chaine de production pour l’encodage ‘localisé’, par exemple ISO-8859-1 (Latin-1) et Windows-1252, soit on paramètre pour UTF-8. En général les navigateurs et serveurs fonctionnent en UTF-8 par défaut. Il n’est pas nécessaire de paramétrer l’entête de la page HTML pour ce type d’encodage. Si c’était le cas, il faudrait ajouter <meta charset="utf-8"> dans l’entête, en général on le fait quand même au cas ou la page soit rendue en local et non via un serveur HTTP.

Par contre, il faut que l’éditeur (ou le langage) utilisé pour générer la table Javascript soit bien positionné, de manière à sauver le flot de caractères en UTF-8. Sous SciTE cela se fait via le menu File > Encoding > UTF-8, l’encodage n’est actif que lorsque le fichier est sauvé.

Si nous restons en localisé, il faudra passer par des fonctions d’encodage et de décodage de chaines de caractères dans le Javascript, et cela peut être compliqué pour gérer toutes les exceptions. Pour s’y reconnaitre, si nous avons calystégine cela veut dire que le fichier est UTF-8 mais rendu avec un encodage localisé. L’inverse (encodé local mais rendu en UTF-8) donne également des glyphes bizarres (bloc xE9 sous SciTE) avec parfois des caractères asiatiques. Et les problèmes d’encodage peuvent se propager sur tout le site Web, incluant les bases de données et scripts.

Dans ces conditions je recommande de bloquer sur UTF-8, c’est ce qu’il y a de plus simple.

Intégration des composants

La page HTML va appeler les différents composants (scripts, données, CSS) et il faudra indiquer une localisation pour chaque élément. En version locale les données et scripts sont dans un répertoire classes situé à un niveau inférieur à la page appelante, via un chemin relatif. Dans le cas d’une installation sur un serveur, il est possible de laisser cette organisation en place, mais il arrive que le système de diffusion ne permette pas cette organisation. De même, si on utilise souvent ces tables dynamiques il est inutile de répéter le répertoire classes sous chaque page. Une solution est de les localiser dans un répertoire proche de la racine du site et accessible à la plupart des applications.