Lors de la première synchro d'une image (je dis bien image pas fichier),
on ne peut pas mettre son nom dans 'name' de table #_images...
Encoder 'file' avec un MD5 partiel, et faire les remame adhoc du fichier physique + du pwg_high + du TN-....
???

ce doit être possible... certe...  mais quand le visiteur télécharge une photo, elle porte le nom encodé du coup....

pour des soucis de gestion des photos, de suivi, de gain de temps, il serait préférable, je pense, qu'elle garde son nom d'origine...

cher ami,

en fait c'est moi qui met les images, les visiteurs les téléchargent, ils n'en upload pas (pas de dépots de photos sur le site par d'autres que moi.. ou mes collègues de travail logués en admin.)

j'ai compris ta démonstration.  c'est relativement simple.

Comme dit précédement, ce qui me gène c'est le changement réél des noms des fichiers photos...
Mon avis n'est pas que rationnel, pour le coté logique et pratique j'ai donné mes argument au dessus, j'en redonne ici : suivi, tri par ordre alphabetique et chronologique identique, classement, coérence nom/sujet, .....
Mais cela est aussi intuitif, quand on travaille avec de grandes quantités d'images, difficiles à classer, à retrouver, quand suite à un coup de fil on doit aller directement à la bonne photo, quand ces fichiers voyagent, d'un client à un magazine, en passant par.... peut importe ou... , quand les clients voudraient avoir en plus des nom propres (personnes ou lieux..) dans les noms des photos, ... j'en passe bien sur, pour dire donc : la référence doit demeurer simple, identique à celle donnée par le photographe..

Je fait sans doute un blocage, mais je suis assez convaincu du bien fondé de ma position.

Alors, quid ?
L'URL peut être réécrite mais :
Si on ne change pas le nom des fichiers, le chemin sera toujours visible dans les propriétés !
- peut on camoufler, changer le chemin écrit ? (non, sans doute)
- peut on changer le nom du dossier contenant les fichiers ? (cela ne changerait rien à la présence du chemin dans les propriétés du fichier)
-doit on (comme le proposait dans ce forum un de nos ami) externaliser les dossiers pwg_high, et les rendre inaccessibles autrement que par PWG ? (je suis plutôt contre, mais prêt à changer d'avis.)
-y-a t'il d'autres idées ? donnez les sans retenue !

Enfin, tout ça pour dire que cette évolution induira des changements important dans notre façon de faire avec PWG..... il faudra y réfléchir à 2 fois.

sinon, pour en revenir à l'inclusion de la variable (md5).. si cette solution est retenue, j'oserais une demande :
pour garder l'ordre des fichier intact (alphabétique), serait-il possible d'imaginer cette variable placée en fin de fichier.??

ex :
F0117_a345
F0117_f556
F0117_g567
F0117_g568

deviendraient :
F0117_a345_4c5
F0117_f556_6j8
F0117_g567_3d4
F0117_g568_9k1

pour finir, comment empécher un visiteur copier dans les propriétés de l'image moyenne sont chemin, d'ajouter pwg_high et d'arriver ainsi au gros fichiers ..? (si la réponse a déjà été donnée désolé..)

salut.
eric.

Dernière modification par vimages (2006-01-18 20:16:44)

pas de soucis, l'idée est tres bonne de toute façon... et mon avis n'est en aucun cas directif. j'essaye seulement de réfléchir sur le sujet... d'apporter une vue de plus.

Je suis d'accord avec toi pour mettre MD5 "à la fin du nom du fichier".

Quant à la question "Est-ce que cela doit être fait par PWG ou non?"...

Pourquoi on fait tous ça dans notre coin, plus ou moins bien alors que PWG peut le faire au moins aussi bien, si ce n'est beaucoup mieux?

Est-ce que selon toi, c'est compliqué et vraiment pas performant?
Auquel cas, je me range à ton avis.

(Rappel: J'ai dit que je me posais une question bête
et je ne faisais pas le forcing sur cette idée, ce n'était qu'une idée de plus voilà tout).

Pourquoi tu n'as pas répondu à ma question précédente?
Maintenant tu dois répondre à deux questions celle ci-dessus et celle ci-dessous.
Est-ce que selon toi, c'est compliqué et vraiment pas performant?


8-)