Réponse acceptée !
Salut,
Je vais faire mon vieux ronchon !
Le XML, c'est très bien, mais...
1) C'est lent : faut le parser.
2) Ca prend de la place : il y a pas mal d'infos qui servent à rien.
Bon, sinon, c'est vrai qu'il a quelques avantages :
1) Il est éditable par l'homme.
2) On peut vérifier un .xml avec un .xsd.
3) Il y a des parseurs tout faits dans de nombreux langages.
Mais dans ton cas, aucun des avantages n'est vraiment effectif.
1) C'est des chaînes. Si tu sérialise pas, ce sera aussi éditable.
2) Tu vas quand même pas rédiger le xsd associé (Les générateur xml -> xsd servent à rien) ?
3) Il n'y a que ton application qui va se servir de ces fichiers.
Par contre, tu subi les inconvénients.
1) Hop la consommation de CPU au démarrage de l'appli et pour traiter ces données.
2) Le fichier est assez lourd à rédiger et prend plus de place que nécessaire.
Bon c'est un bon exo de faire ça en XML (Les entreprises son fans).
Mais perso, je ferais deux fichiers :
1 avec les messages d'erreurs :
Erreur de lecture du fichier
Erreur d'ecriture sur fichier
...
... 1 avec le reste :
Compression Ok
Chriffrement Ok
Lecture du fichier Ok
Lecture du fichierEt hop, 2 coups de TStrings.LoadFromFile et le tour est joué. Le numéro de l'erreur correspondant au numéro de ligne. Simple efficace, traduction facile...
Et une énumération dans le code :
type ERRORS = (ERR_READ_FILE, ERR_WRITE_FILE, ...);