| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| doc:ecriture_des_fichiers_projets [16/05/2009 13:33] – modification externe 127.0.0.1 | doc:ecriture_des_fichiers_projets [20/11/2014 14:02] (Version actuelle) – modification externe 127.0.0.1 |
|---|
| | ~~NOCACHE~~ |
| | |
| | ====== Écriture des fichiers projets ====== |
| | ====== Concepts des versions 0.1 et 0.11 ====== |
| | |
| | Dans les versions 0.1 et 0.11, les fichiers .qet ne contenaient qu'un seul et unique schéma. Ce schéma faisait référence à des éléments issus de la collection personnelle de l'utilisateur (appelée "collection perso" par la suite) ou de la collection fournie par QElectroTech (appelée "collection commune" par la suite) sans pour autant les inclure dans le fichier. |
| | |
| | On peut faire un parallèle avec une page web : le code HTML référence des images externes sans pour autant que les données de ces images ne soient incluses dans le fichier .html. |
| | |
| | La conséquence pour la page web comme pour le fichier QElectroTech est qu'un seul fichier ne suffit pas à représenter la page web / le schéma. Il faut y adjoindre les images / éléments afin d'obtenir un bon rendu. Cela est d'autant plus vrai que, pour QElectroTech, l'impossibilité de trouver un élément se traduit : |
| | * par son absence du schéma |
| | * par l'absence de ses conducteurs sur le schéma |
| | |
| | ====== Concepts de la version 0.2 ====== |
| | |
| | Depuis la version 0.2, QElectroTech apporte deux changements majeurs à ces concepts : |
| | - Un fichier .qet contient plusieurs schémas |
| | - Un fichier .qet peut embarquer une collection d'éléments, accessible à tous les schémas du fichier |
| | |
| | On retrouve donc, dans un même fichier XML, l'équivalent d'une hiérarchie de dossiers et fichiers (la collection embarquée), associée à plusieurs fichiers (les schémas). Il a donc fallu modifier QElectroTech afin qu'il gère différemment l'enregistrement des fichiers .qet. |
| | Principes : |
| | - Avant, lorsqu'un utilisateur enregistrait une catégorie / un élément, il modifiait un dossier / un fichier ; le changement était donc pris en compte sur le disque dur dès l'enregistrement des fichiers. L'utilisateur n'avait pas besoin de faire "Disque dur > Enregistrer" ((sync, quoi.)) pour que ses éléments et catégories soient sauvegardés. Conséquence : le fichier .qet est réécrit après modification dans sa collection embarquée, typiquement au moment où l'utilisateur valide la création d'une catégorie ou effectue Fichier > Enregistrer en éditant un élément de la collection embarquée. |
| | - De même, le code XML représentant un schéma n'était écrit dans le fichier que lorsque l'utilisateur faisait Fichier > Enregistrer. Maintenant qu'il y a plusieurs schémas, ce concept doit être maintenu : lors de la réécriture d'un fichier pour une raison XYZ (modification de la collection embarquée, enregistrement d'un des schémas), les modifications apportées aux autres schémas ne sont écrites dans le fichier. C'est la dernière version connue et enregistrée de ces autres schémas qui est écrite dans le fichier. |
| | ===== Implémentation ===== |
| | |
| | Classes impliquées : QETProject, Diagram, classes de l'API ElementsCollection |
| | |
| | Chaque schéma (instance de la classe Diagram) retient son export XML dans un attribut. Lorsqu'on enregistre un schéma, on ne fait que rafraîchir le contenu de cet attribut et émettre le signal written(). Celui-ci est capté par le projet parent (instance de la classe QETProject) qui réécrit alors complètement le fichier en récupérant l'export XML de chaque schéma. |
| | |
| | Pour la collection embarquée du projet (instances des classes XmlElementsCollection, XmlElementsCategory et XmlElementDefinition), celle-ci est modifiée en mémoire. Elle émet elle aussi le signal written() lors d'une modification, ce qui a également pour conséquence la réécriture du fichier .qet. |
| | TOOD à compléter. |
| |
