Re: [ostorybook-dev] Liens fichiers

[ Thread Index | Date Index | More lists.tuxfamily.org/ostorybook-dev Archives ]


On pourrait aussi avoir une approche diversifiée mais informative.
Je m'explique : il y a trois manières de situer un fichier, en absolu, relativement au fichier du projet ou relativement à un répertoire de travail.

Soit un projet dans lequel on peut (ou pas) définir un répertoire de travail. Lorsque l'utilisateur associe un fichier externe à une scène, le programme peut voir aisément dans quel cas se trouve le fichier, selon son emplacement sur le disque.

Si le fichier est dans le répertoire de travail ou à côté du fichier du projet, on affiche juste un popup disant "le fichier lié est à côté du fichier du projet" ou "le fichier lié est dans le répertoire de travail" selon le cas.
Sinon, on affiche une question "Le fichier lié est hors du répertoire de travail et n'est pas à côté du fichier de projet. Il ne sera pas déplacé si vous déplacez le projet. Voulez-vous vraiment le lier ?". L'utilisateur peut alors accepter ou refuser le lien.

Le 28/11/2021 à 16:28, oStorybook a écrit :
Le 28/11/2021 à 10:19, Marc TORRES a écrit :
Du point de vue de l'utilisateur, l'option "répertoire de travail" est
évidemment la meilleure.
Une proposition, plutôt que s'évertuer à intégrer dans oStorybook une
approche "relativiste" ce serait de proposer une procédure spécifique
s'apparentant à une sauvegarde/restauration. La base de données est
enregistrée, d'une session à l'autre, dans un fichier OSBK qui est un
fichier "backup" disponible en standard par H2database. Or ce fichier
"backup" n'est rien d'autre qu'un fichier contenant des transactions
SQL, donc en forme texte, compressé. Du coup on peut tout à fait
l'ouvrir sans faire appel à H2database ni à hibernate.

Ce qui conduirait à suivre le processus suivant:
a) création d'un dossier de manoeuvre
b) décompression du fichier OSBK dans le dossier de manoeuvre pour
pouvoir travailler le contenu SQL
c) remplacement dans le SQL des répertoires locaux par un identifiant
banalisé
d) copie de tous les fichiers "liés" dans le dossier de manoeuvre
e) choix du nom du fichier ZIP "cible"
f) compression du dossier de manoeuvre dans le ZIP "cible"
g) suppression du dossier de manoeuvre

L'opération inverse suivrait le processus suivant:
a) choix du dossier de destination et création
b) décompression du ZIP dans le dossier de destination
c) dans le fichier SQL remplacement des répertoires "banalisés" par le
dossier de destination
d) compression  du fichier SQL pour obtenir le fichier OSBK avec
suppression du SQL

Réalisation: on peut faire ça sous forme d'un programme séparé et
autonome (ça facilite le développement et les tests). Mais comme on est
dans le même projet on pourra aussi s'interfacer depuis oStorybook avec
des fonctions du type BackRest.backup() et BackRest.restore().



--
oStorybook5 dev


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/