Le 30 octobre 2013 23:07, Christopher Crouzet <[email protected]
> a écrit :

> C'est exact, Lightroom ne modifie rien du tout des fichiers originaux,
> toutes les modifs et autres donnees sont enregistrees dans des fichiers de
> metadata separes.
>
> Un ID faisant le lien entre le media et le fichier sur le filesystem
> pourrait effectivement marcher aussi... si ce n'est que les images inserees
> dans des posts sous forme de balise HTML ne peuvent pas utiliser de balises
> genre {{tpl:getImageUrl id="12345"}} pour eventuellement referencer le vrai
> chemin de l'image en utilisant un ID donne, non ? En tous cas, j'avais
> essaye a l'epoque avec la syntaxe markdown, et ca ne marchait pas. Du coup
> ca veut dire que le truc important serait de conserver le nom du fichier au
> moment de l'upload, et que le media manager ne doive jamais le modifier,
> quoi qu'il arrive. Ca devient juste chiant dans le cas ou l'utilisateur
> uploade 2 images avec le meme nom, et c'est a cause de ce dernier point que
> je trouvais ca plus facile et robuste de simplement renommer les fichiers a
> la volee, mais je comprends que ca ne plaise pas. Ca pourrait peut-etre
> etre une option ? :)
>
> On pourra ajouter un SHA-1 par la suite pour gérer la détection de
doublons, mais pas pour le nom du fichier. Il ne faut pas oublier les gens
qui uploadent autre chose que des photos, et la rétro-compatibilité avec
les médias déjà en place :)
Le répertoire de stockage est un filtre comme un autre, d'ailleurs
actuellement par défaut on affiche __tous__ les médias en base sans
distinction.

Tu soulèves un autre point qui sera un prochain chantier après la refonte
de la médiathèque, un moteur de macros indépendant (le #956), où
effectivement on mentionnera un média par son ID plutôt qu'une insertion
brute, et qui ouvrira plein de possibilités:.

Mais chaque chose en son temps, il y a encore du boulot sur le gestionnaire
de médias. Gros avantage toutefois : la médiathèque aujourd'hui, c'est 99%
coté admin, donc assez peu d'impact sur la partie publique ... pour
l'instant.

--
Bruno
-- 
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev

Répondre à