16:40
- Il s'avère que travailler sur l'interaction du Gestionnaire de Commandes avec la nouvelle Barre est une excellente occasion de mettre à l'épreuve le modèle de données objet imaginé, car il s'agit de manipuler des données particulièrement hétéroclithes: systèmes et utilisateur, certaines sujettes au multilinguisme, d'autres non, certaines strictement statiques et d'autres potentiellement dynamiques (les liens du Menu Démarrer).
- La tentation d'abandonner les objets et de gérer la totalité des données en arbre XML est revenue, car l'utilisation des commandes XPath permet une certaine facilité dans la gestion de la hiérarchie mais, après réflexion, ce système est définitivement rejeté pour les raisons suivantes:
- Manipuler en mémoire le document XML chargé du fichier présente le risque de propager une éventuelle corruption du fichier. Un élement rajouté manuellement dans le fichier par un utilisateur se retrouverait en mémoire avec des effets imprévisibles. Et quitte à devoir parser l'intégralité du document afin d'en vérifier son format, autant en récupérer les données saines et les stocker dans des objets.
- D'autre part, le format XML ne supporte que les chaines et cela obligerait à écrire une quantité de code pour convertir dynamiquement les dates, booléens, listes, etc.
- Enfin, si la verbosité de l'XML est acceptable pour du stockage, où la compression de fichier peut la réduire, elle risque d'allourdir inutilement l'occupation mémoire de l'application.
- Retour donc aux objets, et au problème de navigation dans la hiérarchie. Pour le moment, chaque objet comporte bien entendu des champs dédiés au stockage des données propres, mais également l'OID de son Parent. Pour comparer avec du GT, le modèle est celui d'une classe unique, chaque objet ayant un lien vers son Parent. Cependant le lien n'est pas un pointeur vers le Parent, mais son OID (une chaine), ceci afin de garantir la persistence de la hiérarchie lors du stockage.
- Et c'est là qu'est le problème, la navigation dans la hiérachie des dossiers est très laborieuse, dans les faits cela oblige à procéder à une recherche du Parent dans la liste à chaque besoin.
- Après une autre intense phase de réflexion, la solution choisie est la suivante :
- Non seulement chaque Enfant connait son Parent, mais en plus chaque Parent connaitra désormais ses Enfants, ceci grâce à une liste de pointeurs vers ceux-ci.
- Les OIDs sont conservés, mais pour des raisons de stockage uniquement. Le Parent sera désormais assigné en mémoire par un pointeur également.
- Et finalement, la notion de "classe de stockage" représentée par la liste à plat de tous les objets est abandonnée : chaque objet Parent conservant la liste de ses objets Enfant, le point d'accès aux données peut être l'objet Root, l'ancêtre de tous les Parents.
- Ce système n'a rien de révolutionaire, c'est celui avec lequel Delphi lui-même manipule les objets hiérarchisés.