structurer l'arborescence d'un site

Le Thu, 05 Feb 2004 21:18:15 +0100, Pascal Chevrel
<pascal.chevrel_nospam_@free.fr> écrivait:

Et là je me pose la question des images. Mes produits sont accompagnés
de photos et je me demande s'il est plus logique de faire :

racine/produits/nomproduits1/photos/

ou bien

racine/photos/nomproduits1/

La question que tu dois te poser en premier c'est l'utilité même d'un
sous-dossier photo dans ta logique "objet" par produit. Si tu n'as qu'une ou
deux photo pour chaque produit l'intérêt est réduit et tu as aussi vite fait
de les mettres avec tes pages html donc

racine/produits/nomdproduits1/
ou
racines/photos

^--^ Et la du coup tu as la réponse à ta question de connaitre une des
raisons du pourquoi regrouper toutes les photos dans un seul dossier, dans
nombre de cas leur nombre par page n'est pas suffisemment significatif pour
procéder autrement.
Seconde raison, l'utilisation trans-pages...c'est beaucoup plus simple et
sources de moins d'erreur de n'avoir à pointer que vers un seul dossier
d'images surtout quand celles-ci sont utilisées dans diverses pages.

Troisième raison pour laquelle pour ma part je n'appliquerait pas
l'organisatin que tu évoque (dossiers ou photo directement dans le dossier
du produit associé) : actuellement ton site semble statique, mais si un jour
tu souhaites passer ton catalogue produits en base de données tu reviendras
quasi obligatoirement à une centralisation de toutes tes images dans un seul
dossier afin de ne pas compliquer l'adressage images de tes scripts de
création des pages html.

Quatrième raison, moindre mais existante quand même, en allant chercher tes
images toujours sur un même dossier cible, proche de la racine, le chemin à
indiquer dans le code de tes pages est plus court, donc tes pages moins
lourde (si tu as des milliers de hits par jour, et un abo professionnel
limité en bande passante ca peut t'en faire économiser un chouia).

Dans tous les cas je te recommanderais plutôt à t'attacher à la
normalisation des noms d'images (si ce n'est pas déjà fait), c'est bien plus
important surtout si tu en as un très grand nombre à utiliser. Une bonne
idée est si tes produit utilise un code d'identification numérique
d'utiliser celui-ci comme nom d'image éventuellement suivi d'un code pour
identifier différentes versions (vue de face, de profil, vignette, grande
taille etc). Encore une fois si un jour tu passes par une gestion via base
de données ca te marchera grandement le travail pour la génération des pages
dynamique.

Remarque complémentaire, si tu optes pour un dossier central pour tes
photos, il faut toutefois réfléchir dès maintenant au nombre que tu peux
être amené à stocker dans ce dossier. S'il s'agit de plusieurs milliers, il
sera nécessaire de créer des sous-dossiers, mais probablement pas un par
fiche produit ce qui serait superflu (voir supra). Par contre dans ce cas tu
peux créer des sous-dossiers en fonction encore du code de ton produit, si
celui-ci est par exemple sur 8 chiffres, tu peux créer 100 sous-dossiers (00
à 99) dans lesquels tu redistribues tes images en fonction des deux premiers
chiffres du code de l'image (qui si tu suis la normalisation proposée
ci-avant ont pour nom le code complet de la fiche produit auquel elles sont
associée).
Cette redistribution en sous-dossier est nécessaire si tu gères plusieurs
milliers d'images, car sinon lorsque tu voudras faire des mises à jours via
ftp de ton dossier images tu vas perdre un temps fou à chaque fois que ton
client ftp reconstruit la liste du contenu du dossier.

Cordialement,
Stéphane

--
AcroDict : Dictionnaire francophone des acronymes informatiques
<URL:http://www.teaser.fr/~spineau/acrodict/index.htm>
PHP Page : Script PHP3 Gratuits (Forum, Gestionnaires BDD, etc..)
<URL:http://steph.pineau.free.fr/php/index.php>

Ma réponse prend la forme d'un argumentaire opposé aux idées de Stéphane
(à ne pas prendre comme une attaque personnelle, nous sommes juste d'avis
différent).

Stéphane Pineau wrote:

La question que tu dois te poser en premier c'est l'utilité même d'un
sous-dossier photo dans ta logique "objet" par produit. Si tu n'as qu'une ou
deux photo pour chaque produit l'intérêt est réduit et tu as aussi vite fait
de les mettres avec tes pages html donc

racine/produits/nomdproduits1/
ou
racines/photos

^--^ Et la du coup tu as la réponse à ta question de connaitre une des
raisons du pourquoi regrouper toutes les photos dans un seul dossier, dans
nombre de cas leur nombre par page n'est pas suffisemment significatif pour
procéder autrement.

? Comprends pas l'argument. Pour la page HTML, le choix est fait de la
placer dans un répertoire racine/produits/nomproduit1/ et pourtant il
n'y a qu'une seule page (ou du moins, un nombre réduit de page,
j'imagine). Donc pour un nombre réduit de photos, on peut imaginer le
même placement.

Seconde raison, l'utilisation trans-pages...c'est beaucoup plus simple et
sources de moins d'erreur de n'avoir à pointer que vers un seul dossier
d'images surtout quand celles-ci sont utilisées dans diverses pages.

Ca c'est vrai.
Bien que dans le cadre de produits différents, je ne sais pas si on va
vraiment réutiliser les images. Et dans ce cas, on peut séparer les
images communes (logo des marques de produits, par exemple) des images
spécifiques (les produits eux-même) et leur appliquer des politiques de
rangement différentes.

Troisième raison pour laquelle pour ma part je n'appliquerait pas
l'organisatin que tu évoque (dossiers ou photo directement dans le dossier
du produit associé) : actuellement ton site semble statique, mais si un jour
tu souhaites passer ton catalogue produits en base de données tu reviendras
quasi obligatoirement à une centralisation de toutes tes images dans un seul
dossier afin de ne pas compliquer l'adressage images de tes scripts de
création des pages html.

La complication potentielle réside dans le stockage du chemin d'accès à
l'image... Il s'agit d'un champs VARCHAR en MySQL. Rien de bien sorcier.
Pour l'avoir expérimenté, le problème du chemin d'accès est beaucoup
plus simple que celui de la mise à jour de l'image via interface web/php
avec effacement de l'ancienne image, renommage, ... L'emplacement de
l'image importe peu, il s'agit juste qu'il soit stocké.
Il ne s'agit ici que de la gestion du fichier par php, car pour la
construction de l'url, vu qu'on travaille en relatif le problème ne se
pose pas.

Quatrième raison, moindre mais existante quand même, en allant chercher tes
images toujours sur un même dossier cible, proche de la racine, le chemin à
indiquer dans le code de tes pages est plus court, donc tes pages moins
lourde (si tu as des milliers de hits par jour, et un abo professionnel
limité en bande passante ca peut t'en faire économiser un chouia).

En relatif (car un lien interne au site est toujours en relatif, non ?),
l'url est extrêmement courte. Que l'image soit sur photos/ ou /photos/
c'est quasi identique (on gagne même le '/' de départ).

Dans tous les cas je te recommanderais plutôt à t'attacher à la
normalisation des noms d'images (si ce n'est pas déjà fait), c'est bien plus
important surtout si tu en as un très grand nombre à utiliser. Une bonne
idée est si tes produit utilise un code d'identification numérique
d'utiliser celui-ci comme nom d'image éventuellement suivi d'un code pour
identifier différentes versions (vue de face, de profil, vignette, grande
taille etc). Encore une fois si un jour tu passes par une gestion via base
de données ca te marchera grandement le travail pour la génération des pages
dynamique.

Oui ça c'est extrêmement vrai. Ca facilite le codage et surtout ça
facilite le débugage lorsqu'on cherche une image particulière dans un
répertoire rempli d'images...

Remarque complémentaire, si tu optes pour un dossier central pour tes
photos, il faut toutefois réfléchir dès maintenant au nombre que tu peux
être amené à stocker dans ce dossier. S'il s'agit de plusieurs milliers, il
sera nécessaire de créer des sous-dossiers, mais probablement pas un par
fiche produit ce qui serait superflu (voir supra). Par contre dans ce cas tu
peux créer des sous-dossiers en fonction encore du code de ton produit, si
celui-ci est par exemple sur 8 chiffres, tu peux créer 100 sous-dossiers (00
à 99) dans lesquels tu redistribues tes images en fonction des deux premiers
chiffres du code de l'image (qui si tu suis la normalisation proposée
ci-avant ont pour nom le code complet de la fiche produit auquel elles sont
associée).
Cette redistribution en sous-dossier est nécessaire si tu gères plusieurs
milliers d'images, car sinon lorsque tu voudras faire des mises à jours via
ftp de ton dossier images tu vas perdre un temps fou à chaque fois que ton
client ftp reconstruit la liste du contenu du dossier.

Clairement un répertoire qui contient trop d'images (je dirais que trop
commence à partir de 50) finit par poser problème. Déjà au niveau
maintenance (par un humain), on a tendance à s'y perdre. Ensuite, ça
ralentit le temps d'accès à l'image (bon pas à partir de 50, plutôt à
partir de 1000). Ensuite comme le dit Stéphane, c'est extrêmement
pénible en FTP d'attendre que le client FTP ai fini son listing du
répertoire avant de pouvoir passer au répertoire suivant.

D'autre part, que se passe-t-il si on veut rajouter des fiches-produit
sous forme de documents PDF ? Faudrait-il de nouveau faire un répertoire
racine/pdf/ avec tous les pdf dedans ?

Et si on rajoute des vidéos ? ou des anims flash ?

En conclusion, je préfère classer mes documents (pages HTML, images,
etc.) par unité de sens (on parle d'un même objet avec différents média)
et non par type de fichiers. Il me semble que cela permet une maintenance
plus aisée du site, statique ou dynamique.

C'est comme dans une bibliothèque, je trie mes livres par genre (SF,
romans, beaux livres, ...) et non par taille du livre (les gros d'un
côté, les petits de l'autre).

--
Patrick

Le 05/02/2004 23:40, Stéphane Pineau a écrit :

Le Thu, 05 Feb 2004 21:18:15 +0100, Pascal Chevrel
<pascal.chevrel_nospam_@free.fr> écrivait:

Et là je me pose la question des images. Mes produits sont accompagnés
de photos et je me demande s'il est plus logique de faire :

racine/produits/nomproduits1/photos/

ou bien

racine/photos/nomproduits1/

La question que tu dois te poser en premier c'est l'utilité même d'un
sous-dossier photo dans ta logique "objet" par produit. Si tu n'as qu'une ou
deux photo pour chaque produit l'intérêt est réduit et tu as aussi vite fait
de les mettres avec tes pages html donc

racine/produits/nomdproduits1/
ou
racines/photos

J'ai de deux à 10 photos par produit. Pour certains produits, il est
possible que ça aille jusqu'à une vingtaine je pense.
En fait, les principaux avantages que je vois c'est d'avoir des dossiers
images très lisibles au lieu d'avoir un gros dossier de 500 ou 1000
images et donc d'être sûr de ne pas avoir à faire la chasse aux images
obsolètes sur mon FTP puisque si je ne vends plus le produit X, effacer
son dossier efface aussi ses images associées.

^--^ Et la du coup tu as la réponse à ta question de connaitre une des
raisons du pourquoi regrouper toutes les photos dans un seul dossier, dans
nombre de cas leur nombre par page n'est pas suffisemment significatif pour
procéder autrement.

A mon avis, je commence à être dans un cas un peu intermédiaire, je n'ai
pas encore des centaines de photos, mais je pense que ça viendra
relativement rapidement (d'ici un an).

Seconde raison, l'utilisation trans-pages...c'est beaucoup plus simple et
sources de moins d'erreur de n'avoir à pointer que vers un seul dossier
d'images surtout quand celles-ci sont utilisées dans diverses pages.

Dans mon cas, il sera très rare que des photos soient présentes dans
plusieurs sections, ça se limitera pratiquement à la page promo et à la
page d'accueil, donc je ne pense pas que ce soit un réel problème.

Troisième raison pour laquelle pour ma part je n'appliquerait pas
l'organisatin que tu évoque (dossiers ou photo directement dans le dossier
du produit associé) : actuellement ton site semble statique, mais si un jour
tu souhaites passer ton catalogue produits en base de données tu reviendras
quasi obligatoirement à une centralisation de toutes tes images dans un seul
dossier afin de ne pas compliquer l'adressage images de tes scripts de
création des pages html.

Je le passe justement en bases de données, du moins partiellement :-),
mais je ne vois pas trop le problème que tu évoques, puisque tous mes
dossiers ont un sous-dossier "img", il est tout aussi facile de faire
pointer vers ce dossier avec un lien relatif "img/photo.jpg" non ?

Quatrième raison, moindre mais existante quand même, en allant chercher tes
images toujours sur un même dossier cible, proche de la racine, le chemin à
indiquer dans le code de tes pages est plus court, donc tes pages moins
lourde (si tu as des milliers de hits par jour, et un abo professionnel
limité en bande passante ca peut t'en faire économiser un chouia).

ben justement non :-) mes images se trouvent sous la forme <img
src="img/photo.jpg"> au lieu de <img src="/img/photo.jpg">, même là je
gagne un caractère ;-)

Tu l'auras compris, je n'ai pas l'intention de mettre d'url complètes
mais des chemins relatifs, plus courts :-)

Dans tous les cas je te recommanderais plutôt à t'attacher à la
normalisation des noms d'images (si ce n'est pas déjà fait), c'est bien plus
important surtout si tu en as un très grand nombre à utiliser. Une bonne
idée est si tes produit utilise un code d'identification numérique
d'utiliser celui-ci comme nom d'image éventuellement suivi d'un code pour
identifier différentes versions (vue de face, de profil, vignette, grande
taille etc). Encore une fois si un jour tu passes par une gestion via base
de données ca te marchera grandement le travail pour la génération des pages
dynamique.

Je n'utilise pas de code numérique pour mes produits, donc je ne pense
pas appliquer cette méthode mais ça me fait réfléchir au problème. Pour
l'instant je pense mettre des noms de gamme+numéro et un préfixe type
vig_ pour les éventuelles vignettes. je nirai probablement pas plus loin
pour le moment mais je prends ta remarque en compte :-)

Remarque complémentaire, si tu optes pour un dossier central pour tes
photos, il faut toutefois réfléchir dès maintenant au nombre que tu peux
être amené à stocker dans ce dossier. S'il s'agit de plusieurs milliers, il
sera nécessaire de créer des sous-dossiers, mais probablement pas un par
fiche produit ce qui serait superflu (voir supra). Par contre dans ce cas tu
peux créer des sous-dossiers en fonction encore du code de ton produit, si
celui-ci est par exemple sur 8 chiffres, tu peux créer 100 sous-dossiers (00
à 99) dans lesquels tu redistribues tes images en fonction des deux premiers
chiffres du code de l'image (qui si tu suis la normalisation proposée
ci-avant ont pour nom le code complet de la fiche produit auquel elles sont
associée).
Cette redistribution en sous-dossier est nécessaire si tu gères plusieurs
milliers d'images, car sinon lorsque tu voudras faire des mises à jours via
ftp de ton dossier images tu vas perdre un temps fou à chaque fois que ton
client ftp reconstruit la liste du contenu du dossier.

Ca n'est pas le cas, je n'aurai jamais autant d'images, je ne monte pas
un site porno ;-)

Merci à toi pour ces conseils, je pense rester sur mon idée initiale qui
me semble plus adaptée à mes besoins encore modestes :-)

A bientôt,

Pascal


--
Pascal Chevrel - Mozilla Champion
FAQ Mozilla/Netscape 7 en français : http://pascal.chevrel.free.fr/
Foros Mozilla en español : http://www.chevrel.org/es/foros/

Le 06/02/2004 03:46, Patrick a écrit :

[snip]

Arf :-)

J'avais pas vu ton message avant de répondre à Stéphane mais je suis
content qu'il rejoigne mon avis si parfaitement !! :-)

Pascal

Le 05/02/2004 23:25, Stéphane Santon a écrit :

Mais j'insiste... essaie SPIP ! C'est géant !

Non merci :-) j'aime avoir les mains dans le cambouis :-)

D'ailleurs j'ai déjà une beta de ma nouvelle structure (sans les images)
fonctionnelle, le temps d'apprendre à me servir de SPIP j'aurai déjà
fini la refonte de mon site ;-)

Bon j'ai d'autres raisons de ne pas passer à SPIP, je veux une structure
avec URL significatives, pas de fichiers html ou php avec variables
visibles, je ne suis pas sûr que SPIP puisse le faire par exemple.

Pascal

Pascal Chevrel a écrit :

Et là je me pose la question des images. Mes produits sont accompagnés
de photos et je me demande s'il est plus logique de faire :

racine/produits/nomproduits1/photos/

ou bien

racine/photos/nomproduits1/

Je mettrais tout dans un dossier photos à la racine. Si tu fais un
sous-dossier par produit, ça te fait 2 dossiers à effacer au lieu d'un,
c'est pas la mer à boire. Par contre, tu peux interdire ton dossier
photos aux aspirateurs multimedia genre Google ou AllTheWeb via un
robots.txt. Histoire de ne pas retrouver tes photos... ailleurs. :-)

--
Fabrice Bonny

Pascal Chevrel wrote:

J'ai décidé pour diverses raisons de refaire entièrement
l'arborescence d'un de mes sites. L'idée c'est de remettre un peu
tout à plat, de me débarraser des erreurs accumulées au fil des ans,
de faire plus propre et plus facile à maintenir.

Actuellement toutes les pages sont situées à la racine parce qu'elles
ont été créées au fil des ans, maintenant je veux catégoriser du type
:

racine/produits/nomproduit1/
racine/produits/nomproduit2/

Et là je me pose la question des images. Mes produits sont accompagnés
de photos et je me demande s'il est plus logique de faire :

racine/produits/nomproduits1/photos/

ou bien

racine/photos/nomproduits1/

(autres combinaisons possibles bien sûr ;-) )

Je pense que les facteurs déterminants dans ce choix seront la gestion de la
sécurité et surtout de l'archivage ! Par exemple, pour pouvoir garantir un
archivage de chaque version de fiche produit, regrouper les fichiers par
produit serait sans doute pertinent.

Par ailleurs, pourquoi pas un CMS ? Pas forcément pour être en production,
mais au moins pour générer le site statique ?

--
Pour me répondre par mail privé, merci de supprimer _NOSPAM_ de mon
adresse.

Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php