Lun 20/02/2012 - Actualités

[Xavier]

Lun 20/02/2012 - Actualités


17:35

Chaque donnée possède une liste appelée Children, qui contient des pointeurs vers ses enfants. Ceux-ci peuvent être des dossiers (Containers) ou de simples données sans descendance, de la même façon qu'un répertoire de disque dur contient des sous-répertoire et des fichiers.

Pour le moment, cette mixité des données était gérée par des filtres sur le flag Container, permettant ainsi de n'afficher que les Dossiers dans l'arborescence et que les Contacts dans la liste. Ces filtres ralentissent un peu les traitements car ils sont sur les données enfants, donc il faut par exemple boucler sur les 50 enfants d'un dossier et les analyser pour ne finalement traiter que 10 sous-dossiers, les 40 autres enfants étant de simples données.

Le problème réel vient du déplacement des Contacts. Après des heures de debug, l'application parvient enfin à gérer les Contacts ouverts ou fermés, mais la présence de Dossiers dans cette liste Children fausse tout le code. Ajouter une autre couche de filtres à ce niveau ne parait pas raisonnable, le code devenant trop complexe et non maintenable.

L'idée qui germe est donc d'ajouter une seconde liste qui sera réservée aux sous-dossiers. Il va falloir analyser les impacts et vérifier que cela apportera plus d'avantages que de problèmes. Si cela doit se faire, il y aura à nouveau du rework, mais le résultat risque d'être une simplification de l'implémentation. Ce rework est encore acceptable, un des objectifs de la réalisation de cet outil Contacts étant justement l'adaptation du modèle des données aux besoins réels.

[Denis]

au lieu de gérer une ou deux listes, gère un unique arbre de données. En mémoire, reconstruit l'arbre doublement chainé (donc le parent connait la liste de ses enfants et chaque enfant connait son parent). Une fois en place, trop facile de gérer dossiers ouverts ou non et éléments feuilles d'un dossier donné...