coder quelque chose de plus malin que

Bonjour,
voici mon souci : j'ai un document html composé de plusieurs fichiers
(quelques fichiers html, plus quelques images). La difficulté est que je
dois les déposer sur un site qui gère les fichiers via une base de
donnée. Ainsi on accède aux fichiers par une requête du style :
http://lesiteweb.org/file.php?file=/repertoire/index.html

La conséquence c'est que si mon fichier index.html fait un <IMG
SRC="image.png">, les navigateurs vont le rechercher dans
http://lesiteweb.org/image.png et non pas dans
http://lesiteweb.org/file.php?file=/repertoire/image.png

Bref, il me faut gérer cette URL de base non conventionnelle.
Naïvement, j'ai essayé avec le tag <base href=".."> dans l'entête, mais
bien entendu, il n'est pas pris en compte...

cela veut-il dire que pour chaque image il faut faire :
src="http://lesiteweb.org/file.php?file=/repertoire/image.png"
c a d relancer le fichier 'file.php' qui doit alors titiller la base de
donnée pour trouver l'image ?
N'est-ce point beaucoup de labeur pour le serveur ?

Si les images sont en fait dans un répertoire, je ne vois pas où est le
problème avec :
src="/repertoire_des_images/image.png"
?

Par conséquent, je pensais qu'il devrait être possible de coder en
javascript une fonction qui d'une part repère la base de l'url du
document html en cours, puis l'ajoute à tous les liens locaux.

??? la "base" de l'url de la page (http://lesiteweb.org/) est de toutes
façons ajoutée silencieusement par le navigateur ...
Il suffit d'avoir le src des images en relatif à la racine du site

src="/ ...

Si les images sont dans : repetoire/photos/
et si le php sait écrire : ?file=/repertoire/
il saura bien écrire cekivabien pour les src, non ?
src="<?php echo $repertoire ?>/photos/photo_1.jpg"


--
sm

Bonjour,
voici mon souci : j'ai un document html composé de plusieurs
fichiers (quelques fichiers html, plus quelques images). La difficulté
est que je dois les déposer sur un site qui gère les fichiers via une
base de donnée. Ainsi on accède aux fichiers par une requête du style :
http://lesiteweb.org/file.php?file=/repertoire/index.html

La conséquence c'est que si mon fichier index.html fait un <IMG
SRC="image.png">, les navigateurs vont le rechercher dans
http://lesiteweb.org/image.png et non pas dans
http://lesiteweb.org/file.php?file=/repertoire/image.png

Bref, il me faut gérer cette URL de base non conventionnelle.
Naïvement, j'ai essayé avec le tag <base href=".."> dans l'entête,
mais bien entendu, il n'est pas pris en compte...

cela veut-il dire que pour chaque image il faut faire :
src="http://lesiteweb.org/file.php?file=/repertoire/image.png"
c a d relancer le fichier 'file.php' qui doit alors titiller la base de
donnée pour trouver l'image ?
N'est-ce point beaucoup de labeur pour le serveur ?

peut-être
c'est la contre-partie du "web dynamique"
(Note: je ne gère pas le serveur en question, je ne fais que l'utiliser)

cela dit, j'ai l'impression que c'est une façon de faire de plus en plus
courante : par exemple tous les sites genre dailymotion, d'albums
photos, de forum, etc. tout le contenu est dans une base de donnée (même
les documents)

Si les images sont en fait dans un répertoire, je ne vois pas où est le
problème avec :
src="/repertoire_des_images/image.png"

il n'y a pas de répertoire au sens habituel, c'est plutôt un répertoire
virtuel dans le sens ou c'est la base de donnée qui me ressort mes
document "ensembles" et me les présente comme si ils étaient dans un
même répertoire de disque dur, mais ce n'est certainement pas le cas sur
le serveur.

Par conséquent, je pensais qu'il devrait être possible de coder en
javascript une fonction qui d'une part repère la base de l'url du
document html en cours, puis l'ajoute à tous les liens locaux.

??? la "base" de l'url de la page (http://lesiteweb.org/) est de toutes
façons ajoutée silencieusement par le navigateur ...

oui, mais de mon point de vue cette base d'url n'est pas la bonne, il me
faudrait la chaîne "http://lesiteweb.org/file.php?file=/repertoire/"
pour que le serveur me retrouve les fichiers.

Si les images sont dans : repetoire/photos/
et si le php sait écrire : ?file=/repertoire/
il saura bien écrire cekivabien pour les src, non ?
src="<?php echo $repertoire ?>/photos/photo_1.jpg"

Le php qui fait fonctionner le serveur, je n'ai en aucun cas la main dessus.
Tout ce que je maîtrise, ce sont les documents que j'y dépose (html, png).
D'où l'idée initiale de coder dans mes documents html un bout de
javascript qui ré-arrange ses url relatives...

Bonjour,
voici mon souci : j'ai un document html composé de plusieurs
fichiers (quelques fichiers html, plus quelques images). La
difficulté est que je dois les déposer sur un site qui gère les
fichiers via une base de donnée. Ainsi on accède aux fichiers par une
requête du style :
http://lesiteweb.org/file.php?file=/repertoire/index.html

La conséquence c'est que si mon fichier index.html fait un <IMG
SRC="image.png">, les navigateurs vont le rechercher dans
http://lesiteweb.org/image.png et non pas dans
http://lesiteweb.org/file.php?file=/repertoire/image.png

Bref, il me faut gérer cette URL de base non conventionnelle.
Naïvement, j'ai essayé avec le tag <base href=".."> dans l'entête,
mais bien entendu, il n'est pas pris en compte...

cela veut-il dire que pour chaque image il faut faire :
src="http://lesiteweb.org/file.php?file=/repertoire/image.png"
c a d relancer le fichier 'file.php' qui doit alors titiller la base
de donnée pour trouver l'image ?
N'est-ce point beaucoup de labeur pour le serveur ?

peut-être
c'est la contre-partie du "web dynamique"

Je dirais plutôt que c'est la contrepartie d'une conception médiocre.

(Note: je ne gère pas le serveur en question, je ne fais que l'utiliser)

cela dit, j'ai l'impression que c'est une façon de faire de plus en plus
courante : par exemple tous les sites genre dailymotion, d'albums
photos, de forum, etc. tout le contenu est dans une base de donnée (même
les documents)

En général, les métadonnées sont dans une base, et les données elle-même
stockées sur un système de fichier.

(snip)

Le php qui fait fonctionner le serveur, je n'ai en aucun cas la main
dessus.
Tout ce que je maîtrise, ce sont les documents que j'y dépose (html, png).
D'où l'idée initiale de coder dans mes documents html un bout de
javascript qui ré-arrange ses url relatives...

Et pour ceux qui n'ont pas javascript (ou l'ont désactivé) ?

c a d relancer le fichier 'file.php' qui doit alors titiller la base
de donnée pour trouver l'image ?
N'est-ce point beaucoup de labeur pour le serveur ?

peut-être
c'est la contre-partie du "web dynamique"

Je dirais plutôt que c'est la contrepartie d'une conception médiocre.

tu le concevrais comment ?

En général, les métadonnées sont dans une base, et les données elle-même
stockées sur un système de fichier.

je ne connais pas le fonctionnement interne du serveur, mais c'est
certainement comme ça que c'est fait.
Toujours est-il que le système de fichier ou sont stockées effectivement
les données n'est pas accessible par le web, il faut passer par la base
de données

D'où l'idée initiale de coder dans mes documents html un bout de
javascript qui ré-arrange ses url relatives...

Et pour ceux qui n'ont pas javascript (ou l'ont désactivé) ?

oui, je suis bien d'accord que c'est une "rustine"
mais vu le fonctionnement du serveur, les utilisateurs qui n'ont pas de
javascript sont de toutes façons bien vite bloqués par ailleurs...

En général, les métadonnées sont dans une base, et les données elle-même
stockées sur un système de fichier.

Je ne suis absolument pas d'accord avec cette affirmation. Une base de
données est destinée à stocker et contrôler l'intégrité de données. Ce
ne sont pas des bases de méta-données.

D'ailleurs, les bases de données bien conçues gèrent correctement les
blob, en créant un fichier pour un blob, on en gérant un système de
fichier relationnel comme il existait sous BeOS (BeFS).

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

En général, les métadonnées sont dans une base, et les données elle-même
stockées sur un système de fichier.

Je ne suis absolument pas d'accord avec cette affirmation.

Avec l'affirmation selon laquelle la majorité des CMS existant
fonctionnent de cette façon ? Vérifie par toi-même.

Ok, je comprend que compte-tenu de la remarque précédente sur la
conception du système incriminé, tu ais pu comprendre que le "en
général" signifiait "c'est comme ça qu'il faut faire", mais je me
contentais en fait de décrire le cas le plus couramment rencontré.

Après, sur le fond, on peut discuter (mais ailleurs alors) de la
validité de cette solution, en théorie comme en pratique. En ce qui
concerne les CMS, ceci étant, dans la mesure où les images référencées
par une page html sont chargées via une sous-requête HTTP, il peut être
préférable d'avoir l'image directement sur le système de fichier, dans
un endroit accessible au serveur web, pour éviter une exécution de code
(php ou autre) + une requête sql à chaque fois.

c a d relancer le fichier 'file.php' qui doit alors titiller la
base de donnée pour trouver l'image ?
N'est-ce point beaucoup de labeur pour le serveur ?

peut-être
c'est la contre-partie du "web dynamique"

Je dirais plutôt que c'est la contrepartie d'une conception médiocre.

tu le concevrais comment ?

En mettant les métadonnées (dont l'adresse de l'image) dans la base, et
l'image elle-même dans une partie du filesystem accessible au serveur
web, et en utilisant soit une réécriture d'url, soit une réécriture du
code html pour faire pointer au bon endroit.

En général, les métadonnées sont dans une base, et les données
elle-même stockées sur un système de fichier.

je ne connais pas le fonctionnement interne du serveur, mais c'est
certainement comme ça que c'est fait.
Toujours est-il que le système de fichier ou sont stockées effectivement
les données n'est pas accessible par le web, il faut passer par la base
de données

Ce n'est pas la base de données qui rend l'image accessible, c'est le
serveur web, soit directement, soit via un script côté serveur (en PHP
dans ton cas).

D'où l'idée initiale de coder dans mes documents html un bout de
javascript qui ré-arrange ses url relatives...

Et pour ceux qui n'ont pas javascript (ou l'ont désactivé) ?

oui, je suis bien d'accord que c'est une "rustine"
mais vu le fonctionnement du serveur, les utilisateurs qui n'ont pas de
javascript sont de toutes façons bien vite bloqués par ailleurs...

Super.

Mickaël Wolff wrote:

En général, les métadonnées sont dans une base, et les données
elle-même stockées sur un système de fichier.

Je ne suis absolument pas d'accord avec cette affirmation. Une base
de données est destinée à stocker et contrôler l'intégrité de
données. Ce ne sont pas des bases de méta-données.

Tu as déjà essayé de faire un dump d'une base de données contenant plusieurs
centaines de Mo de blobs ?
Il est suicidaire et complètement inutile de stocker les fichiers dans des
blobs.

Avec l'affirmation selon laquelle la majorité des CMS existant
fonctionnent de cette façon ? Vérifie par toi-même.

Mince, j'avais lu trop vite, compris que tu affirmais qu'il fallait,
et non pas que c'est comme ça que c'était généralement fait.

Après, sur le fond, on peut discuter (mais ailleurs alors) de la
validité de cette solution, en théorie comme en pratique. En ce qui
concerne les CMS, ceci étant, dans la mesure où les images référencées
par une page html sont chargées via une sous-requête HTTP, il peut être
préférable d'avoir l'image directement sur le système de fichier, dans
un endroit accessible au serveur web, pour éviter une exécution de code
(php ou autre) + une requête sql à chaque fois.

C'est vrai que ce n'est pas trop l'endroit pour parler de ça ici.
Quand au choix de fournir l'image sous forme statique ou dynamique, je
penses que ça dépend de la nature du site, et des images servies. Si
l'image est soumise à rémunération, telles que les photos de membres
dans un site de rencontre, il faut passer par un système qui vérifie
qu'on a le droit de consulter cette image.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Tu as déjà essayé de faire un dump d'une base de données contenant plusieurs
centaines de Mo de blobs ?

Très franchement, je ne vois pas le soucis. D'autant plus qu'on peut
procéder à des dumps incrémentaux, qu'on peut faire de la réplication si
jamais un dump devient une contrainte temporel trop grande, les données
sont dans des fichiers en définitives, etc.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org