je me pose des questions sur la bonne structure à adopter pour un
ensemble de scripts en relation avec une base de données:
sur une page page.php, j'ai un formulaire destiné à modifier cette page
elle-même (typiquement, lui rajouter un commentaire)
je me demande s'il vaut mieux:
1) mettre l'"action" du formulaire vers cette page page.php en rajoutant
un test genre if(isset($_POST["comment"])) et ajoutant le commentaire le
cas échéant avant d'afficher la page.
2) mettre l'"action" vers un script indépendant add_comment.php qui
ajoute le commentaire puis redirige (redirection HTTP à coup de
header("location: page.php")) vers page.php
3) mettre l'"action" vers un script add_comment.php qui ajoute le
commentaire puis inclus sans redirection le contenu généré par page.php
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
en 2, j'aime pas faire une redirection qui ne me semble pas indispensable.
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du
navigateur.
Bon, j'aime pas beaucoup de choses, me direz-vous... Ben si j'aime bien
faire les choses au plus propre.
Merci d'avance pour vos conseils,
--
Vincent Jacques
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème."
Devise Shadok
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
CrazyCat
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est une question de goûts (et je suis d'accord avec toi)
-- Astuces pour webmasters: http://www.crazycat.info Tchat francophone: http://www.crazy-irc.net
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
en 2, j'aime pas faire une redirection qui ne me semble pas indispensable.
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du
navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera
add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est
une question de goûts (et je suis d'accord avec toi)
--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est une question de goûts (et je suis d'accord avec toi)
-- Astuces pour webmasters: http://www.crazycat.info Tchat francophone: http://www.crazy-irc.net
Calimero
CrazyCat wrote:
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est une question de goûts (et je suis d'accord avec toi)
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
J'aurais plutôt tendance à faire du 1+2
Poster la page sur elle-même, passer les infos aux fonctions d'accès aux données (objets ou fonctions dans un include séparé), puis rediriger sur la même page.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
-- @+ Calimero
CrazyCat wrote:
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
en 2, j'aime pas faire une redirection qui ne me semble pas
indispensable.
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du
navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera
add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est
une question de goûts (et je suis d'accord avec toi)
La redirection a quand même l'avantage d'éviter le gars qui s'excite
sur la touche Refresh et qui reposte 15x le même commentaire.
J'aurais plutôt tendance à faire du 1+2
Poster la page sur elle-même, passer les infos aux fonctions d'accès
aux données (objets ou fonctions dans un include séparé), puis
rediriger sur la même page.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Sinon, la 2 est dépréciée (tu fais une requète http pour rien), la 3 est une question de goûts (et je suis d'accord avec toi)
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
J'aurais plutôt tendance à faire du 1+2
Poster la page sur elle-même, passer les infos aux fonctions d'accès aux données (objets ou fonctions dans un include séparé), puis rediriger sur la même page.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
-- @+ Calimero
CrazyCat
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les archives du ng, on trouve des solutions pour bloquer les multi-posts.
-- Astuces pour webmasters: http://www.crazycat.info Tchat francophone: http://www.crazy-irc.net
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur
la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les
archives du ng, on trouve des solutions pour bloquer les multi-posts.
--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les archives du ng, on trouve des solutions pour bloquer les multi-posts.
-- Astuces pour webmasters: http://www.crazycat.info Tchat francophone: http://www.crazy-irc.net
David JOURAND
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Pour ma part, j'implémente le pattern MVC...
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
... et je gère un identifiant pour éviter les soumissions multiples.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
Il y a quand même quelques standards.
-- David Jourand
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
en 2, j'aime pas faire une redirection qui ne me semble pas
indispensable.
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du
navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera
add_comment.php si nécessaire (donc si $_POST existe).
Pour ma part, j'implémente le pattern MVC...
La redirection a quand même l'avantage d'éviter le gars qui s'excite
sur la touche Refresh et qui reposte 15x le même commentaire.
... et je gère un identifiant pour éviter les soumissions multiples.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
en 1, j'aime pas donner plusieurs responsabilitées à un même script. en 2, j'aime pas faire une redirection qui ne me semble pas indispensable. en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
4) mettre l'action du formulaire vers page.php qui elle même incluera add_comment.php si nécessaire (donc si $_POST existe).
Pour ma part, j'implémente le pattern MVC...
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
... et je gère un identifiant pour éviter les soumissions multiples.
Maintenant, j'imagine qu'il n'y a pas de solution miracle.
Il y a quand même quelques standards.
-- David Jourand
Bruno Desthuilliers
Bonjour à tous,
je me pose des questions sur la bonne structure à adopter pour un ensemble de scripts en relation avec une base de données:
sur une page page.php, j'ai un formulaire destiné à modifier cette page elle-même (typiquement, lui rajouter un commentaire)
je me demande s'il vaut mieux:
1) mettre l'"action" du formulaire vers cette page page.php en rajoutant un test genre if(isset($_POST["comment"])) et ajoutant le commentaire le cas échéant avant d'afficher la page.
C'est le cas le plus classique, mais ça peut vite dégénérer en code imbitable.
2) mettre l'"action" vers un script indépendant add_comment.php qui ajoute le commentaire puis redirige (redirection HTTP à coup de header("location: page.php")) vers page.php
C'est AMHA (et pas seulement au mien d'ailleurs - c'est un pattern connu) ce qu'il y a de mieux à faire - mais tout le monde ici n'est pas forcément de cet avis.
L'avantage du pattern POST-process-redirect est que ça évite des repost intempestifs.
3) mettre l'"action" vers un script add_comment.php qui ajoute le commentaire puis inclus sans redirection le contenu généré par page.php
Perso, je virerais sans préavis un stagiaire me pondant un truc pareil. Maintenant, c'est toi qui vois, hein ?
Sérieusement, c'est AMHA le plus mauvais choix possible.
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
Rien ne t'empêche de découper les choses différement: - le script PHP 'page.php' teste la méthode - si c'est un GET, il appelle le script page_GET.php - qui se charge d'afficher la page - si c'est un POST, il appelle le script page_POST.php - qui fait ce qu'il a à faire...
en 2, j'aime pas faire une redirection qui ne me semble pas indispensable.
indispensable, je ne sais pas, mais elle à l'intérêt d'éviter un repost intempestif sur l'utilisation du bouton "page précédente"...
Théoriquement, un POST réussi devrait retourner : - si l'action n'entraine pas la création d'une ressource (identifiable par une URI), soit un code 200 et une entitée décrivant le résultat de l'opération, soit un code 204 et pas d'entitée
-> ce qui correspond plus ou moins à la solution 1
- si l'action entraine la création d'une ressource (identifiable par une URI), un code 201, une entitée décrivant le résultat de la requête *et* un header Location pointant sur l'URI de la ressource nouvellement créée.
-> ce qui correspond plus ou moins à la solution 2
Donc, si tu veux être au plus près de la norme, le choix dépend du fait qu'un commentaire soit accessible via une URL distincte de la page (pas de redirect) ou non (redirect).
NB : Dans la pratique, en PHP, header("Location") retourne un 302 - ce qui n'est certainement pas le choix le plus conforme à la rfc :(
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
Bon, j'aime pas beaucoup de choses, me direz-vous... Ben si j'aime bien faire les choses au plus propre.
<aol/>
Et HTH !-)
Bonjour à tous,
je me pose des questions sur la bonne structure à adopter pour un
ensemble de scripts en relation avec une base de données:
sur une page page.php, j'ai un formulaire destiné à modifier cette page
elle-même (typiquement, lui rajouter un commentaire)
je me demande s'il vaut mieux:
1) mettre l'"action" du formulaire vers cette page page.php en rajoutant
un test genre if(isset($_POST["comment"])) et ajoutant le commentaire le
cas échéant avant d'afficher la page.
C'est le cas le plus classique, mais ça peut vite dégénérer en code
imbitable.
2) mettre l'"action" vers un script indépendant add_comment.php qui
ajoute le commentaire puis redirige (redirection HTTP à coup de
header("location: page.php")) vers page.php
C'est AMHA (et pas seulement au mien d'ailleurs - c'est un pattern
connu) ce qu'il y a de mieux à faire - mais tout le monde ici n'est pas
forcément de cet avis.
L'avantage du pattern POST-process-redirect est que ça évite des repost
intempestifs.
3) mettre l'"action" vers un script add_comment.php qui ajoute le
commentaire puis inclus sans redirection le contenu généré par page.php
Perso, je virerais sans préavis un stagiaire me pondant un truc pareil.
Maintenant, c'est toi qui vois, hein ?
Sérieusement, c'est AMHA le plus mauvais choix possible.
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
Rien ne t'empêche de découper les choses différement:
- le script PHP 'page.php' teste la méthode
- si c'est un GET, il appelle le script page_GET.php - qui se charge
d'afficher la page
- si c'est un POST, il appelle le script page_POST.php - qui fait ce
qu'il a à faire...
en 2, j'aime pas faire une redirection qui ne me semble pas indispensable.
indispensable, je ne sais pas, mais elle à l'intérêt d'éviter un repost
intempestif sur l'utilisation du bouton "page précédente"...
Théoriquement, un POST réussi devrait retourner :
- si l'action n'entraine pas la création d'une ressource (identifiable
par une URI), soit un code 200 et une entitée décrivant le résultat de
l'opération, soit un code 204 et pas d'entitée
-> ce qui correspond plus ou moins à la solution 1
- si l'action entraine la création d'une ressource (identifiable par une
URI), un code 201, une entitée décrivant le résultat de la requête *et*
un header Location pointant sur l'URI de la ressource nouvellement créée.
-> ce qui correspond plus ou moins à la solution 2
Donc, si tu veux être au plus près de la norme, le choix dépend du fait
qu'un commentaire soit accessible via une URL distincte de la page (pas
de redirect) ou non (redirect).
je me pose des questions sur la bonne structure à adopter pour un ensemble de scripts en relation avec une base de données:
sur une page page.php, j'ai un formulaire destiné à modifier cette page elle-même (typiquement, lui rajouter un commentaire)
je me demande s'il vaut mieux:
1) mettre l'"action" du formulaire vers cette page page.php en rajoutant un test genre if(isset($_POST["comment"])) et ajoutant le commentaire le cas échéant avant d'afficher la page.
C'est le cas le plus classique, mais ça peut vite dégénérer en code imbitable.
2) mettre l'"action" vers un script indépendant add_comment.php qui ajoute le commentaire puis redirige (redirection HTTP à coup de header("location: page.php")) vers page.php
C'est AMHA (et pas seulement au mien d'ailleurs - c'est un pattern connu) ce qu'il y a de mieux à faire - mais tout le monde ici n'est pas forcément de cet avis.
L'avantage du pattern POST-process-redirect est que ça évite des repost intempestifs.
3) mettre l'"action" vers un script add_comment.php qui ajoute le commentaire puis inclus sans redirection le contenu généré par page.php
Perso, je virerais sans préavis un stagiaire me pondant un truc pareil. Maintenant, c'est toi qui vois, hein ?
Sérieusement, c'est AMHA le plus mauvais choix possible.
en 1, j'aime pas donner plusieurs responsabilitées à un même script.
Rien ne t'empêche de découper les choses différement: - le script PHP 'page.php' teste la méthode - si c'est un GET, il appelle le script page_GET.php - qui se charge d'afficher la page - si c'est un POST, il appelle le script page_POST.php - qui fait ce qu'il a à faire...
en 2, j'aime pas faire une redirection qui ne me semble pas indispensable.
indispensable, je ne sais pas, mais elle à l'intérêt d'éviter un repost intempestif sur l'utilisation du bouton "page précédente"...
Théoriquement, un POST réussi devrait retourner : - si l'action n'entraine pas la création d'une ressource (identifiable par une URI), soit un code 200 et une entitée décrivant le résultat de l'opération, soit un code 204 et pas d'entitée
-> ce qui correspond plus ou moins à la solution 1
- si l'action entraine la création d'une ressource (identifiable par une URI), un code 201, une entitée décrivant le résultat de la requête *et* un header Location pointant sur l'URI de la ressource nouvellement créée.
-> ce qui correspond plus ou moins à la solution 2
Donc, si tu veux être au plus près de la norme, le choix dépend du fait qu'un commentaire soit accessible via une URL distincte de la page (pas de redirect) ou non (redirect).
NB : Dans la pratique, en PHP, header("Location") retourne un 302 - ce qui n'est certainement pas le choix le plus conforme à la rfc :(
en 3, j'aime pas laisser "add_comment.php" dans la barre d'adresse du navigateur.
Bon, j'aime pas beaucoup de choses, me direz-vous... Ben si j'aime bien faire les choses au plus propre.
<aol/>
Et HTH !-)
Calimero
CrazyCat wrote:
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les archives du ng, on trouve des solutions pour bloquer les multi-posts.
Personne ne le conteste.
Toutefois, le POST/REDIRECT/GET a l'avantage de s'implémenter en 2 lignes pour un résultat raisonnablement fonctionnel.
C'est pas vraiment la même chose qu'une solution qui va stocker quelque part une checksum de la saisie pour la comparer à une liste des dernières saisies (ce qui implique une purge régulière ou un contrôle de date, etc...) ou alors qui va directement valider en base pour regarder s'il n'y a pas déjà une entrée similaire (en s'assurant que le contrôle d'intégrité offre bien le niveau de filtrage attendu: à faire varier selon le besoin fonctionnel).
Bref, le PRG me semble largement suffisant pour de nombreuses applications. Là où le besoin transactionnel est plus élevé, si tu travailles avec une base de données, c'est de toute façon dans ta transaction/procédure stockée que tu feras les tests pour t'assurer d'avoir un traitement atomique, avec les contraintes d'intégrité imposées par ton modèle, etc...
A mon sens, une solution de logging avec checksum a surtout son intérêt pour lutter contre du spaming/flooding (en travaillant sur l'identification du visiteur et non le contenu de ses envois).
Bref, tout dépend du problème qu'on cherche à résoudre.
-- @+ Calimero
CrazyCat wrote:
La redirection a quand même l'avantage d'éviter le gars qui s'excite
sur la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les
archives du ng, on trouve des solutions pour bloquer les multi-posts.
Personne ne le conteste.
Toutefois, le POST/REDIRECT/GET a l'avantage de s'implémenter en 2
lignes pour un résultat raisonnablement fonctionnel.
C'est pas vraiment la même chose qu'une solution qui va stocker
quelque part une checksum de la saisie pour la comparer à une liste
des dernières saisies (ce qui implique une purge régulière ou un
contrôle de date, etc...) ou alors qui va directement valider en base
pour regarder s'il n'y a pas déjà une entrée similaire (en s'assurant
que le contrôle d'intégrité offre bien le niveau de filtrage attendu:
à faire varier selon le besoin fonctionnel).
Bref, le PRG me semble largement suffisant pour de nombreuses
applications.
Là où le besoin transactionnel est plus élevé, si tu travailles avec
une base de données, c'est de toute façon dans ta
transaction/procédure stockée que tu feras les tests pour t'assurer
d'avoir un traitement atomique, avec les contraintes d'intégrité
imposées par ton modèle, etc...
A mon sens, une solution de logging avec checksum a surtout son
intérêt pour lutter contre du spaming/flooding (en travaillant sur
l'identification du visiteur et non le contenu de ses envois).
Bref, tout dépend du problème qu'on cherche à résoudre.
La redirection a quand même l'avantage d'éviter le gars qui s'excite sur la touche Refresh et qui reposte 15x le même commentaire.
Cette question a souvent été posée et reposée, en cherchant dans les archives du ng, on trouve des solutions pour bloquer les multi-posts.
Personne ne le conteste.
Toutefois, le POST/REDIRECT/GET a l'avantage de s'implémenter en 2 lignes pour un résultat raisonnablement fonctionnel.
C'est pas vraiment la même chose qu'une solution qui va stocker quelque part une checksum de la saisie pour la comparer à une liste des dernières saisies (ce qui implique une purge régulière ou un contrôle de date, etc...) ou alors qui va directement valider en base pour regarder s'il n'y a pas déjà une entrée similaire (en s'assurant que le contrôle d'intégrité offre bien le niveau de filtrage attendu: à faire varier selon le besoin fonctionnel).
Bref, le PRG me semble largement suffisant pour de nombreuses applications. Là où le besoin transactionnel est plus élevé, si tu travailles avec une base de données, c'est de toute façon dans ta transaction/procédure stockée que tu feras les tests pour t'assurer d'avoir un traitement atomique, avec les contraintes d'intégrité imposées par ton modèle, etc...
A mon sens, une solution de logging avec checksum a surtout son intérêt pour lutter contre du spaming/flooding (en travaillant sur l'identification du visiteur et non le contenu de ses envois).
Bref, tout dépend du problème qu'on cherche à résoudre.
-- @+ Calimero
Vincent Jacques
Vincent Jacques wrote:
je me pose des questions sur la bonne structure à adopter pour un ensemble de scripts en relation avec une base de données:
Merci à tous pour vos réponses. Je vais adopter, au moins dans un premier temps, la solution "en deux lignes de code" avec redirection http.
PS pour les modérateurs: désolé d'avoir posté deux fois mon premier message, j'avais pas vu que le groupe était modéré :-) -- Vincent Jacques
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Devise Shadok
Vincent Jacques wrote:
je me pose des questions sur la bonne structure à adopter pour un
ensemble de scripts en relation avec une base de données:
Merci à tous pour vos réponses. Je vais adopter, au moins dans un premier
temps, la solution "en deux lignes de code" avec redirection http.
PS pour les modérateurs: désolé d'avoir posté deux fois mon premier
message, j'avais pas vu que le groupe était modéré :-)
--
Vincent Jacques
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème."
Devise Shadok
