j'ai le petit souci suivant:
je voudrais dans un formulaire recupérer l'emplacement d'une image et la
stocker dans une base de données.
Pour cela j'utilise input file, qui me permet de parcourir le disque pour
trouver l'emplacement.
Je ne récupère que le nom du fichier sans le chemin.
Les images sont stockées sur le serveur. Le but est de pouvoir réafficher
l'image par la suite à côté de l'article.
L'ajax (jquery entre autre) permet de valider un formulaire en arrière plan, sans recharger la page. Ainsi, l'image est uploadée en arrière plan, stockée côté serveur, on récupère son chemin, et on l'affiche en js. Cela ne pose pas de souci. (voir ajaxform de jquery de mémoire). Testé sous de nombreux navigateurs.
En ajax, il y a aussi webtoolkit.aim.js (http://www.webtoolkit.info/ajax-file-upload.html) qui est fort simple à utiliser et ne nécessite pas de framework js
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
J. Trotoux wrote:
L'ajax (jquery entre autre) permet de valider un formulaire en arrière
plan, sans recharger la page.
Ainsi, l'image est uploadée en arrière plan, stockée côté serveur, on
récupère son chemin, et on l'affiche en js.
Cela ne pose pas de souci. (voir ajaxform de jquery de mémoire). Testé
sous de nombreux navigateurs.
En ajax, il y a aussi webtoolkit.aim.js
(http://www.webtoolkit.info/ajax-file-upload.html) qui est fort simple à
utiliser et ne nécessite pas de framework js
--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
L'ajax (jquery entre autre) permet de valider un formulaire en arrière plan, sans recharger la page. Ainsi, l'image est uploadée en arrière plan, stockée côté serveur, on récupère son chemin, et on l'affiche en js. Cela ne pose pas de souci. (voir ajaxform de jquery de mémoire). Testé sous de nombreux navigateurs.
En ajax, il y a aussi webtoolkit.aim.js (http://www.webtoolkit.info/ajax-file-upload.html) qui est fort simple à utiliser et ne nécessite pas de framework js
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Patrick Mevzek
Le Thu, 16 Oct 2008 17:25:39 +0200, Pierre Goiffon a écrit:
Dans le cadre d'une application Web, on a bien moins de raison de stocker des images destinées à être affichées dans des pages dans des champs blob plutôt que sur le filesystem, tout simplement car ajouter un traitement pour aller chercher les données en base et les renvoyer au client est une lourdeur qui est pour la plupart des cas superflue.
Sauf que dans la majorité des cas que je vois, on ne profite pas des fonctionnalités natives du serveur web pour récupérer les fichiers mais on fait des choses comme .../view.php?img=toto.jpeg
Donc dans ce cas je ne vois pas de différence entre le script PHP faisant un fopen() ou un mysql_query() (dans les deux cas il y aura le cache disque de l'OS qui devrait faire son travail), c'est aussi lourd dans les deux cas. D'autant que dans le cas BDD, il n'y a pas nécessairement de traitement *en plus*, si on écrit correctement ses requêtes qui récupèrent les meta-données, on peut récupérer en même temps le « blob » (dépend du SGBDR, de l'API, du schéma, etc.)
Maintenant dans une « bonne » application avec un proxy qui sépare les documents statiques des requêtes dynamiques et fait profiter directement aux premiers un serveur web fait pour ca, alors là on peut discuter autrement, mais en pratique ce cas de figure arrive rarement, car justement percu comme trop lourd alors qu'ajouter quelques lignes en PHP ne sera jamais percu comme un problème même si on peut faire mieux et plus succintement autrement.
Mais bon, il ne faut pas nécessairement mettre les performances en premier: parfois il est bon que ca soit lent *et* sûr plutôt que rapide et plein de « race conditions ».
D'autant que, naïvement, mettre tous ses fichiers (images) au même endroit dans le système de fichiers n'est pas nécessairement « léger » vu qu'un certain nombre de systèmes de fichiers commencent à peiner avec plusieurs centaines de fichiers dans le même répertoire. Oui, on peut corriger ca facilement, en créant des arborescences, etc. mais ce n'est pas nécessairement quelque chose que l'on pense faire dès le départ.
Et, parfois, au final cela ne change pas grand chose, parce qu'un vrai « blob » peut être stocké par le SGBDR comme un fichier à part, donc ca revient à peu près au même, sauf qu'au moins avec le SGBDR on a une API cross-plateforme ce qui ne sera pas le cas du système de fichiers si on ne fait pas un miminum attention.
Cette problématique est donc à considérer d'une manière particulière dans le cas d'applications Web je pense.
Pour moi, la finalité ne change pas grand chose aux arguments que j'ai donné plus haut. Mais je ne dis pas qu'une solution est meilleure qu'une autre toujours, je tentais juste de préciser les compromis et les nuances entre les deux. J'aime les deux cas de figure, tant qu'ils sont judicieusement employés dans le contexte concerné.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Thu, 16 Oct 2008 17:25:39 +0200, Pierre Goiffon a écrit:
Dans le cadre d'une application Web, on a bien moins de raison de
stocker des images destinées à être affichées dans des pages dans des
champs blob plutôt que sur le filesystem, tout simplement car ajouter un
traitement pour aller chercher les données en base et les renvoyer au
client est une lourdeur qui est pour la plupart des cas superflue.
Sauf que dans la majorité des cas que je vois, on ne profite pas des
fonctionnalités natives du serveur web pour récupérer les fichiers mais on
fait des choses comme
.../view.php?img=toto.jpeg
Donc dans ce cas je ne vois pas de différence entre le script PHP faisant
un fopen() ou un mysql_query() (dans les deux cas il y aura le cache
disque de l'OS qui devrait faire son travail), c'est aussi lourd dans les
deux cas.
D'autant que dans le cas BDD, il n'y a pas nécessairement de traitement
*en plus*, si on écrit correctement ses requêtes qui récupèrent les
meta-données, on peut récupérer en même temps le « blob » (dépend du
SGBDR, de l'API, du schéma, etc.)
Maintenant dans une « bonne » application avec un proxy qui sépare les
documents statiques des requêtes dynamiques et fait profiter directement
aux premiers un serveur web fait pour ca, alors là on peut discuter
autrement, mais en pratique ce cas de figure arrive rarement, car
justement percu comme trop lourd alors qu'ajouter quelques lignes en PHP
ne sera jamais percu comme un problème même si on peut faire mieux et plus
succintement autrement.
Mais bon, il ne faut pas nécessairement mettre les performances en
premier: parfois il est bon que ca soit lent *et* sûr plutôt que rapide et
plein de « race conditions ».
D'autant que, naïvement, mettre tous ses fichiers (images) au même endroit
dans le système de fichiers n'est pas nécessairement « léger » vu qu'un
certain nombre de systèmes de fichiers commencent à peiner avec plusieurs
centaines de fichiers dans le même répertoire. Oui, on peut corriger ca
facilement, en créant des arborescences, etc. mais ce n'est pas
nécessairement quelque chose que l'on pense faire dès le départ.
Et, parfois, au final cela ne change pas grand chose, parce qu'un vrai «
blob » peut être stocké par le SGBDR comme un fichier à part, donc ca
revient à peu près au même, sauf qu'au moins avec le SGBDR on a une API
cross-plateforme ce qui ne sera pas le cas du système de fichiers si on ne
fait pas un miminum attention.
Cette problématique est donc à considérer d'une manière particulière
dans le cas d'applications Web je pense.
Pour moi, la finalité ne change pas grand chose aux arguments que j'ai
donné plus haut. Mais je ne dis pas qu'une solution est meilleure qu'une
autre toujours, je tentais juste de préciser les compromis et les nuances
entre les deux. J'aime les deux cas de figure, tant qu'ils sont
judicieusement employés dans le contexte concerné.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Thu, 16 Oct 2008 17:25:39 +0200, Pierre Goiffon a écrit:
Dans le cadre d'une application Web, on a bien moins de raison de stocker des images destinées à être affichées dans des pages dans des champs blob plutôt que sur le filesystem, tout simplement car ajouter un traitement pour aller chercher les données en base et les renvoyer au client est une lourdeur qui est pour la plupart des cas superflue.
Sauf que dans la majorité des cas que je vois, on ne profite pas des fonctionnalités natives du serveur web pour récupérer les fichiers mais on fait des choses comme .../view.php?img=toto.jpeg
Donc dans ce cas je ne vois pas de différence entre le script PHP faisant un fopen() ou un mysql_query() (dans les deux cas il y aura le cache disque de l'OS qui devrait faire son travail), c'est aussi lourd dans les deux cas. D'autant que dans le cas BDD, il n'y a pas nécessairement de traitement *en plus*, si on écrit correctement ses requêtes qui récupèrent les meta-données, on peut récupérer en même temps le « blob » (dépend du SGBDR, de l'API, du schéma, etc.)
Maintenant dans une « bonne » application avec un proxy qui sépare les documents statiques des requêtes dynamiques et fait profiter directement aux premiers un serveur web fait pour ca, alors là on peut discuter autrement, mais en pratique ce cas de figure arrive rarement, car justement percu comme trop lourd alors qu'ajouter quelques lignes en PHP ne sera jamais percu comme un problème même si on peut faire mieux et plus succintement autrement.
Mais bon, il ne faut pas nécessairement mettre les performances en premier: parfois il est bon que ca soit lent *et* sûr plutôt que rapide et plein de « race conditions ».
D'autant que, naïvement, mettre tous ses fichiers (images) au même endroit dans le système de fichiers n'est pas nécessairement « léger » vu qu'un certain nombre de systèmes de fichiers commencent à peiner avec plusieurs centaines de fichiers dans le même répertoire. Oui, on peut corriger ca facilement, en créant des arborescences, etc. mais ce n'est pas nécessairement quelque chose que l'on pense faire dès le départ.
Et, parfois, au final cela ne change pas grand chose, parce qu'un vrai « blob » peut être stocké par le SGBDR comme un fichier à part, donc ca revient à peu près au même, sauf qu'au moins avec le SGBDR on a une API cross-plateforme ce qui ne sera pas le cas du système de fichiers si on ne fait pas un miminum attention.
Cette problématique est donc à considérer d'une manière particulière dans le cas d'applications Web je pense.
Pour moi, la finalité ne change pas grand chose aux arguments que j'ai donné plus haut. Mais je ne dis pas qu'une solution est meilleure qu'une autre toujours, je tentais juste de préciser les compromis et les nuances entre les deux. J'aime les deux cas de figure, tant qu'ils sont judicieusement employés dans le contexte concerné.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
J-F Portala
Comme vous avez pu le voir, je ne suis pas un foudre de guerre en programmation web, et il y a peut être des "concepts" que je n'ai pas du tout compris.
Mais enfin! Si tu as un formulaire avec un champ "file", tu fais donc un upload de l'image.
Je trouvais pratique de pointer sur l'emplacement de l'image pour alimenter la base de données. Cela implique que je travaille dans ce cas sur le serveur en local. J'aurais pu aussi mettre juste un champ texte (plutot que input file) pour saisir le nom de l'image mais cela peut être source d'erreurs de saisie alors qu'en choisissant avec un bouton parcourir, c'est direct.(mais on doit travailler sur le serveur...)
Encore merci de votre aide
Jeff
Comme vous avez pu le voir, je ne suis pas un foudre de guerre en
programmation web, et
il y a peut être des "concepts" que je n'ai pas du tout compris.
Mais enfin!
Si tu as un formulaire avec un champ "file", tu fais donc un upload de
l'image.
Je trouvais pratique de pointer sur l'emplacement de l'image pour alimenter
la base de données. Cela implique que je travaille dans ce cas sur le
serveur
en local.
J'aurais pu aussi mettre juste un champ texte (plutot que input file) pour
saisir le nom de l'image mais cela peut être source d'erreurs de saisie
alors qu'en choisissant
avec un bouton parcourir, c'est direct.(mais on doit travailler sur le
serveur...)
Comme vous avez pu le voir, je ne suis pas un foudre de guerre en programmation web, et il y a peut être des "concepts" que je n'ai pas du tout compris.
Mais enfin! Si tu as un formulaire avec un champ "file", tu fais donc un upload de l'image.
Je trouvais pratique de pointer sur l'emplacement de l'image pour alimenter la base de données. Cela implique que je travaille dans ce cas sur le serveur en local. J'aurais pu aussi mettre juste un champ texte (plutot que input file) pour saisir le nom de l'image mais cela peut être source d'erreurs de saisie alors qu'en choisissant avec un bouton parcourir, c'est direct.(mais on doit travailler sur le serveur...)
