re: [ostorybook-dev] Liens fichiers

[Marc TORRES <marc.torres370@xxxxxxxxx>]

Bonjour,

 

Du point de vue de l'utilisateur, l'option "répertoire de travail" est évidemment la meilleure.

 

Mais si en termes de prog c'est compliqué, il ne faut effectivement pas s'embarquer dans des modifs lourdes, surtout pour des opérations qui somme toute ne doivent pas être si fréquentes que ça (perso je n'ai jamais modifié mes répertoires en cours de route).

 

Loi de Darwin : les plus organisés auront un (très petit) avantage :)

 

Marc

 

 

 

> > Message du 28/11/21 10:12
> > De : "oStorybook" <ostorybook@xxxxxxxxx>
> > A : ostorybook-dev@xxxxxxxxxxxxxxxxxxx
> > Copie à : 
> > Objet : [ostorybook-dev] Liens fichiers
> > 
> > Le 28/11/2021 à 08:52, Jean Rébillat a écrit :
> > > On peut :
> > > - noter le chemin absolu (dans ce cas impossible de déplacer le projet complet,  les fichiers externes ne doivent pas bouger)
> > > - noter le chemin relatif (on ne peut déplacer le projet que si on déplace aussi tous les fichiers externes)
> > > - configurer dans le projet un répertoire "de travail" dans lequel devront être tous les fichiers externes (notés donc en relatif par rapport à la racine de ce répertoire). On peut alors déplacer le fichier du projet où on veut sans bouger le répertoire de travail et/ou déplacer le répertoire de travail en pensant bien à changer la configuration du projet.
> > > - on peut aussi recopier les fichiers externes dans le fichier du projet. C'est que j'ai fait dans ma maquette V6 pour les images en les stockant dans le projet lui-même. Un (léger) défaut est la taille du fichier du projet. Le (gros) défaut est que si le fichier externe change, on ne le sait pas et dans le projet on continue de voir l'ancien contenu. C'est bon pour des données qui changent peu (les images par exemple) mais pas pour les textes.
> > 
> > Tu as parfaitement résumé la situation et les différentes options.. J'ai
> > moi aussi pensé au dossier de travail dans lequel on regroupe tout, mais
> > finalement je pense qu'il vaut mieux en rester à la situation actuelle
> > qui consiste à n'utiliser que l'adressage absolu. Pour résoudre le
> > problème des liens il faut donc avoir une fonction du genre
> > "vérifier/corriger les liens" permettant d'automatiser ce qu'on ferait
> > manuellement pour que tout refonctionne normalement en cas de transfert.
> > On peut aussi créer une fonction spécialisée de "transfert" d'un projet
> > qui se chargerait de préparer un contenant (un ZIP) qui inclura tous les
> > fichiers liés, et son corollaire d'"installation" qui effectuera
> > l'opération inverse et traitera la modifications interne des liens.
> > 
> > Pourquoi en rester à l'adresse absolue? Parce que Java ne permet pas
> > vraiment d'utiliser l'adressage relatif. Si c'était le cas on devrait
> > avoir une commande élémentaire du type "change working directory"..
> > 
> > Une autre alternative, plus élégante, serait de créer une classe File
> > qui ne serait utilisée que pour les fichiers en lien avec le livre en
> > cours... sauf que quand on utilise une API quelconque on se retrouvera
> > avec le même problème.
> > 
> > Bref, avant de se lancer à programmer quelque chose le mieux serait de
> > continuer à débattre de la question et d'adopter une ligne stratégique
> > qui nous satisfasse.
> > -- 
> > Franz-Albert projet oStorybook
> > 
> > 
> > -- 
> > oStorybook5 dev
> > 
> >