1. Introduction

Toute application propre dispose d'un fichier de configuration au moins. Elle doit pouvoir le lire, l'écrire, et proposer un moyen facile à l'utilisateur d'y accéder. Pour ces trois objectifs, une étude doit être faite afin de déterminer quelle solution utiliser. Voici les résultats pour une application ni trop simple ni trop compliquée.

1.1. Accès au fichier par l'utilisateur

Si le fichier est en mode texte, l'utilisateur pourra utiliser son éditeur de texte favori pour l'éditer. Sinon, il faudra une application spécifique pour y accéder. C'est souvent le cas de l'application que l'on programme, qui donne un moyen d'accéder au fichier de configuration (menu préférences) afin de rendre les options modifiables d'une manière plutôt conviviale. Mais si le fichier est corrompu et empêche le lancement de l'application, et que par dessus le marché c'était le seul moyen pour l'utilisateur d'atteindre le fichier de configuration, on se trouve dans une situation où il faut tout réinstaller.

Un format de fichier de configuration intermédiaire est le XML qui est en mode texte, et qui dispose d'outils pour le lire (cf LMAG 27 et son dossier spécial XML.)

1.2. Ecriture du fichier par l'application

Si l'application n'est pas distribuée, il est très facile pour le programmeur d'écraser le fichier de configuration existant et de le remplacer par un nouveau que l'application écrira avec de simples printf(). Cette partie de l'application est relativement rébarbative à coder, mais une fois que cela est fait, la convivialité est au rendez-vous aussi bien pour le programmeur que pour l'utilisateur.

1.3. Lecture du fichier par l'application

Au vu de ce qui précède, nous avons déjà plus ou moins choisi un format de fichier texte. Il reste maintenant le format de ce fichier qui va conditionner son mode de lecture. Au premier abord, on a tendance à utiliser les fonctions C de base afin de lire le fichier. L'inconvénient majeur est qu'il est rébarbatif de coder des fonctions de vérification de la validité du format du fichier. Et s'il est corrompu, l'appli ne plantera pas forcément avant la fin de la lecture, mais peut-être après, pendant que des données sont traitées. On va donc éliminer le code basic et se servir d'outils qui font le travail de vérification.

Deux systèmes seront donc via lex & yacc avec un format de fichier quelconque, et via des fonctions xml (sax, dom...) avec un format de fichier xml.

Choisissons arbitrairement le format quelconque afin d'utiliser lex & yacc (lisez LMAG27 si vous préférez XML). Un avantage supplémentaire de l'utilisation de lex & yacc est que le format de fichier n'est pas figé. C'est à nous de l'inventer et donc de le rendre le plus convivial possible.

création est mise à disposition sous un contrat Creative Commons