On me demande souvent quelles méthodes et outils de travail j'utilise pour la gestion de ce site. Voici pour ceux que cela intéresse les différents processus que j'ai élaborés pour la maintenance du site.

A la base le dictionnaire est entièrement rédigé dans une base de données MySql et interfacé via PHP. Les ajouts, modifications se font donc au niveau de la base de donnée en local via un simple navigateur.

Un petit script de l'interface se charge de créer automatiquement les index, ainsi que tous les fichiers html (un par définition) en fonction d'un critère de sélection qui en l'occurrence est la date de la mise-à-jour.

Le script PHP qui génère ces fichiers .Html utilise une technique simplifiée de "template".ou modèle, pour la mise-en-forme. Cette technique permet d'isoler une "présentation" type du script et donc de la modifier très simplement quand voulu sans avoir à réécrire le script.

Le principe est simple. Un fichier "modèle" au format .Html est créé qui contiendra la mise en forme voulue, mais ou le contenu sera remplacé par des balises spécifiques, par exemple #DEFINITION#, #DATE#, #TEXTE#, à l'endroit ou doivent apparaître ces données dans les fichiers finaux.

Le script PHP va donc interroger la base-de-données MySql pour en extraire chaque définition. Pour chacune, il copie en mémoire le "modèle", puis remplace chacun des mots clés #DEFINITION#, #DATE#, etc., par la valeur du champ correspondant de la définition lue dans la base MySQL. Il ne lui reste plus qu'à écrire sur disque le fichier .Html résultant de cette fusion.

Le grand avantage de cette méthode est que si je souhaite changer la présentation de mon site (ce que je fait de temps en temps) je n'ai pas à reprendre un par un les quelques milliers de fichiers qui le constitue. Je modifie simplement le "modèle", puis je relance la génération des fichiers pour la totalités des définitions de la base.

Autre avantage, avec les même données je peux de la même manière sortir une version texte, ou une version prête à être compilée en hypertexte autonome (help par exemple).

Comme vu ci-dessus, je créé pour chaque définition un fichier .Html, dont le nom est composé d'un numéro unique attribué à chacune.

Pourquoi cette méthode plutôt qu'un seul fichier en ligne, ou plus simplement encore directement la base sur le site ? Quelques raisons

• On évite aussi le principal reproche que je fais à des sites similaires, à savoir que bien souvent plusieurs définitions sont regroupées en un seul fichier, et que selon la loi de "murphy" celle que l'on cherche est toujours la dernière, donc qu'on doit subir un chargement inutile de 80 à 200ko de données avant de pouvoir la lire.
• On obtient des fichiers qui ne dépassent pas 1 à 2ko, donc pas de temps de chargement pour le visiteur.
• Le principe de fiches individuelles référencées par un numéro, permet un stockage arborescent dans des répertoires commençant par les premiers chiffres des fiches. D'où une maintenance plus aisée. D'autre part ce système de référence numérique allège considérablement la longueur des liens. Avec l'avantage non négligeable d'alléger de manière non négligeable la tailles des index (de l'ordre de 70% en moyenne)

Le choix de ne pas directement mettre la base MySQL en ligne à plusieurs origines.

• Une origine historique d'abord, mon hébergeur ne l'autorisait tout simplement pas aux débuts du site, il a donc fallu que je trouve des alternatives techniques.
• En second lieu ce système offre une plus grande "disponibilité" au site, puisque le seul cas ou celui-ci serait inaccessible serait celui ou le serveur http serait en panne. Avec une base en ligne, il suffit d'un problème sur le serveur de bases ou sur la base elle même pour que le site soit indisponible (même si cela est rare, c'est plus fréquent que l'indisponibilité du serveur http). En restant uniquement en site "statique", on évite également la surcharge possible des accès simultanés à la base de données ou à une même définition.
• Enfin de cette manière je peux travailler tranquillement sur la base en local, sans devoir obligatoirement être connecté à mon hébergeur, gérer mes backups sereinement et ne mettre en ligne que les fiches au moins révisées une fois après leur rédaction. Bien sur tout ceci pourrait aussi être possible avec un mécanisme de synchronisation de bases, mais c'est trop à programmer de manière fiable à mon goût.
• Enfin une partie de la génération de chaque fiche fait appel aux possibilités de callback sur des expressions régulières, notamment pour ajouter le balisage <abbr> autour de tous les sigles, abréviations et acronymes. Ce type de processus est assez lourd en charge CPU, inutile de le répéter à chaque demande de fiche. L'alternative serait également de gérer un système de cache sur le serveur, mais la solution actuelle arrive au même résultat pour un developpement bien moindre

Ces raisons bien sur ne s'appliquent pas à tous les sites. Dans nombre de cas la mise-en-ligne de la base de données et donc son interrogation directe via le site peut se révéler pertinente, c'est surtout le cas pour des données amenées à changer souvent (prix, news etc...)

Le seul aspect négatif à mon choix est que par ce fait il est difficile (mais pas impossible) d'intégrer un moteur de recherche intégral (c'est à dire qui ira rechercher dans le corps même des définitions). Toutefois je pense que le moteur sur l'acronyme ou le developpement, les différents index alphabétiques et thématiques, ainsi que le renvois inter-définitions suffisent amplement à la majorité des recherches d'internautes.

Voilà pour les principales étapes de "génération" du site. Une mise en ligne des mises à jour ne demande donc qu'une dizaine de minutes. Ceci hors temps de saisie bien sur.

En résumé je n'ai pas à me soucier de la mise en forme pour le "gros" du site, puisqu'elle est générée automatiquement. Ce qui me libère de facilement 70% du temps que je passerais à faire la mise en page HTML si je devais le faire manuellement pour chaque définition

Enfin pour terminer tout le système de navigation (qui est doublé pour être supporté par tous les navigateurs) est soit géré côté client par des scripts "Javascript" (pour les navigateurs qui le supportent) sinon côté serveur via le langage PHP. Le moteur de recherche par mot-clefs était dans un premier temps entièrement écrit en javascript, mais je l'ai réécrit en PHP ce qui le rend accessible à tous. J'ai également développé le forum de discussion en PHP. 

Pour le reste du site "l'enrobage", c'est à dire les diverses pages d'accueil, de présentation, j'ai utilisé divers utilitaires, depuis le "composer" de Netscape en passant par divers éditeurs Html/Css, de la version gratuite et française de 1st Page 2000 v2.00 d'Evrsoft, à DreamWeaver 2.00 de Macromedia disponible gratuitement sur les cd-rom d'abonnement à Wanadoo par exemple. Pour la programmation PHP pure, mon choix s'est arrêté tout d'abord sur PhpEd, mais depuis quelques années je n'utilise plus que l'excellent éditeur Scite tant pour le codage PHP que pour le xHTML et le CSS

Enfin pour terminer, après moults révisions au fur et à mesure de mon apprentissage des techniques Web, et après de longues années d'existence sous la forme d'un site utilisant les frames faute de trouver un design offrant le même confort de consultation, j'ai enfin passé le pas et complétement "reloké" celui-ci en faisant disparaitre les frames. Pour ce faire les CSS et le positionnement absolu ont joué un rôle prépondérant. Par la même occasion l'ensemble du site à été réécrit pour respecter la norme xHTML 1.1 strict, et respecter au mieux la sémantique et l'accessibilité. Le site valide donc en CSS et xHTML1.1 strict, mais ne me voyant pas passer près de 5000 pages au validateur, je ne peux me fier qu'à dès sondages pour appuyer cette afirmation:-)