Question de debutant sur formulaire

J'ai un formulaire en HTML , tout simple, qui permet par exemple d'ajouter
un élément dans un base de données.
Je passe par un post qui appelle la même page. Le choix du traitement est
conditionné par un paramètre qui indique ce que je veux faire (add, del,
update).
Tout marche très bien. Sauf que si je fais un refresh dans le navigateur de
la page, suite à une action, il me rebalance le même traitement !
Il faudrait en fait, une fois que mon traitement est effectué, que j'efface
le contenu des paramètres..... commen faire ? ou y-a-t-il un autre moyen ?

J'espère avoir été assez clair....

Je ne vois pas trop où est le problème, en fait. Il suffit de tester si
l'opération a un sens ou pas, et le cas échéant ne pas la faire... ou
plus exactement, il faut se reposer sur la base de données pour faire ce
contrôle.

1) Add : si on a déjà ajouté ces valeurs, ne pas les ajouter une
nouvelle fois (il suffit à priori d'avoir une bonne clé unique).

2) Del : si on a déjà supprimé ces valeurs (ou si elles n'ont jamais
existé), ne pas les supprimer une nouvelle fois (devrait marcher tout seul).

3) Update : y a-t-il vraiment un problème à changer deux fois un champ
pour y stocker la même valeur ?

Donc dans tous les cas il est urgent de ne rien faire de spécial. Non ?

(Et si tu me parles d'autoincrément, cherche les articles de John Gallet
à ce sujet, il te parlera du pays...)

Tout marche très bien. Sauf que si je fais un refresh dans le navigateur
de
la page, suite à une action, il me rebalance le même traitement !

C'est logique car les données envoyés en $_POST, $_GET sont renvoyés par le
navigateur lors d'un Refresh. Les spécialistes du fonctionnement des
browsers sauront peut être t'en expliquer d'avantage et d'une meilleure
facon que moi.

Il faudrait en fait, une fois que mon traitement est effectué, que
j'efface
le contenu des paramètres..... commen faire ? ou y-a-t-il un autre moyen ?

Moi ce qui m'interpelle, c'est pourquoi as-tu besoin de faire un refresh si
tout se passe bien ?
Si vraiment cela te gene, alors dans le script qui gère la réception des
données du formulaire et une fois celles-ci traités et que tes actions sont
effectués, fais une redirection par header sur une autre page.

Sinon tu peux aussi essayer de tester en détruisant les variables $_POST
après leur traitement (fonction "unset" sur le tableau $GLOBALS je pense) ?
Je laisse ca aux spécialistes car sur ce coup la je ne suis pas sûr de moi,
mais de toutes façons je doute que cela ait un interret pour toi.

Christophe

Moi ce qui m'interpelle, c'est pourquoi as-tu besoin de faire un refresh si
tout se passe bien ?

Pourquoi les utilisateurs devraient-ils connaître le fonctionnement de
http et des navigateurs pour remplir un formulaire dans une page web
alors qu'il suffit que les développeurs, qui eux devraient le connaître,
fassent leur boulot ?

Si vraiment cela te gene, alors dans le script qui gère la réception des
données du formulaire et une fois celles-ci traités et que tes actions sont
effectués, fais une redirection par header sur une autre page.
Marchera pas dans tous les cas.

Sinon tu peux aussi essayer de tester en détruisant les variables $_POST
après leur traitement (fonction "unset" sur le tableau $GLOBALS je pense) ?
Marchera jamais.

Soient les scénario suivants :

L'utilisateur clique sur submit. Ca ne va pas assez vite :

Cas 1 : la page est encore là, il reclique sur submit, une fois, deux
fos, trois fois.

Cas 2 : la page est "blanche" car "en cours de chargement, il clique sur
"retour" et reclique sur submit

Cas 3 : la page est "blanche" ou partiellement construite, il clique sur
refresh.

On fait quoi alors ? (1)

JG

(1) on peut par exemple consulter les archives de ce forum où des
réponses ont déjà été données watt-milliard de fois.

"Christophe, www.elitemediacompany.com" <"christophe [arobase]
elitemediacompany [dot] com"@news53rd.b1.woo> a écrit dans le message de
news:4505acc8$0$27403$ba4acef3@news.orange.fr...

Tout marche très bien. Sauf que si je fais un refresh dans le navigateur
de
la page, suite à une action, il me rebalance le même traitement !

C'est logique car les données envoyés en $_POST, $_GET sont renvoyés par
le

navigateur lors d'un Refresh. Les spécialistes du fonctionnement des
browsers sauront peut être t'en expliquer d'avantage et d'une meilleure
facon que moi.

Je te rassure, je connaissais très bien les raisons, et ton explication,
même courte, résume parfaitement le pb.

Il faudrait en fait, une fois que mon traitement est effectué, que
j'efface
le contenu des paramètres..... commen faire ? ou y-a-t-il un autre moyen
?

Moi ce qui m'interpelle, c'est pourquoi as-tu besoin de faire un refresh
si

tout se passe bien ?

Moi, non, mais mon utilisateur, qui va le lui empêcher, hein ?

Si vraiment cela te gene, alors dans le script qui gère la réception des
données du formulaire et une fois celles-ci traités et que tes actions
sont

effectués, fais une redirection par header sur une autre page.

Justement, ça je voudrais éviter, pour une question de maintenance des pages
: j'ai vu une appli développée ainsi. Ah, certes, tu pouvais faire tout ce
que tu voulais : béton ! Mais alors, bonjour la maintenance : tu "courrais"
d'une page à l'autre pour comprendre ce qui se passait !!

Sinon tu peux aussi essayer de tester en détruisant les variables $_POST
après leur traitement (fonction "unset" sur le tableau $GLOBALS je pense)
?

Je laisse ca aux spécialistes car sur ce coup la je ne suis pas sûr de
moi,

mais de toutes façons je doute que cela ait un interret pour toi.

Christophe

(1) on peut par exemple consulter les archives de ce forum où des
réponses ont déjà été données watt-milliard de fois.

Je suis désolé mais je ne trouve pas de watt ni de milliard de fois ce sujet
dans les archives, suis-je bête ?

En dehors du fait que ce n'est pas moi qui pose la question de départ, je
suis interressé par le sujet pour ma formation personnelle. Peux-tu nous
donner un lien concret vers une archive traitant du problème de Marc ?

Christophe

Bonjour,


Le Mon, 11 Sep 2006 15:13:00 +0000, Marc Mendez a écrit :

J'ai un formulaire en HTML

[snip]

Tout marche très bien. Sauf que si je fais un refresh dans le navigateur
de la page, suite à une action, il me rebalance le même traitement !

C'est effectivement un problème classique et récurrent qui n'est pas
spécifique à PHP. Une solution consiste à associer au formulaire
un identifiant unique (UID) généré lors de l'appel de la page et
stocké dans le formulaire (champs hidden). Après enregsitrement
dans la base, ce UID est stocké quelque part (base ou session). Il suffit
donc avant de procéder à l'enregistrement de vérifier si cet UID est
déjà stocké ou non. S'il l'est, le traitement ne doit pas être fait,
s'il ne l'est pas, le traitement doit être fait.

Pour ma part, j'ai mis en place un système automatique permettant de
gérer un UID unique par formulaire sans le passé sous forme de
paramètre hidden.


--
David JOURAND - http://www.numabilis.com
Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.

Tout marche très bien. Sauf que si je fais un refresh dans le
navigateur de
la page, suite à une action, il me rebalance le même traitement !

Bonjour,

c'est un problème classique. Il pose aussi un problème quand tu
valides le formulaire, que tu vas sur la page suivante et que tu
fais "back" avec ton navigateur.

Pour résoudre le problème, tu peux utiliser une redirection 302 après
le traitement de ton formulaire. Etapes par étapes, ça donne :

- tu récupère en PHP les variables du $_POST
- tu fais ton traitement (sauvegarde en base ou autre...)
//note : ici tu n'as pas encore renvoyé d'HTML au navigateur
- tu fais une redirection 302 vers le code php qui affiche la page
qui suit le traitement ( header("Location: affichage.html"); )
// note : ici le navigateur ne voit pas s'afficher la page d'action du
formulaire mais directement la page affichage.html

Dans tous les cas, ton internaute peut faire les back, ou refresh qu'il
veut, il ne se retrouvera jamais sur l'action de son formulaire.

Cordialement,
Philippe Le Van
--
tutoriaux Zend Framework : http://www.kitpages.fr/zf_overview.html

En dehors du fait que ce n'est pas moi qui pose la question de départ, je
suis interressé par le sujet pour ma formation personnelle. Peux-tu nous
donner un lien concret vers une archive traitant du problème de Marc ?

Tu as deux grands types de solutions, parfaitement combinables d'ailleurs.

1) le jeton unique, comme rappelé par exemple par D. Jourand dans ce
même thread. Bien utilisé, ça évite un certain nombre d'erreurs
involontaires de l'internaute. En fait, comme ledit internaute pourra
toujours revenir deux heures plus tard reprendre totalement le processus
à zéro, ça permet de se ramener à ce cas. Il faut juste se méfier des
enregistrements sur plusieurs écrans (i.e. s'il y a plusieurs écrans de
saisie enchaînés et dépdendants les uns des autres) la gestion est un
peu plus complexe. Possède l'avantage de fonctionner sans SGBDR par un
système de sessions non stocké en SGBDR. Ne garantit pas l'unicité en
SGBDR quand on en a une derrière; mais filtre les erreurs de bonne foi
dans le processus d'enregistrement.


2) comprendre comment on doit utiliser une clef primaire ou une clef
unique dans la base de données : empêcher les doublons, c'est par
**définition** son boulot (ce que cette mode à la con des autoincrement
partout sans réflexion minimaliste fait oublier). A ce sujet, (re) lire
le cours que je diffuse sur saphirtech.com par exemple. Cette méthode
apporte beaucoup plus d'unicité, et la garantit même totalement dans
certains cas (ça dépend toujours des données qu'on traite).

a++;
JG

Après enregsitrement
dans la base, ce UID est stocké quelque part (base ou session). Il suffit
donc avant de procéder à l'enregistrement de vérifier si cet UID est
déjà stocké ou non. S'il l'est, le traitement ne doit pas être fait,
s'il ne l'est pas, le traitement doit être fait.

En toute logique, le stockage à long terme ce ce jeton est totalement
inutile et c'est une logique inverse qu'il faut appliquer : on génère un
jeton d'autorisation qu'on stocke pour XX minutes (time out). S'il est
toujours valide quand la requête arrive, on exécuté la requête, sinon
elle a déjà été exécutée (ou est invalide car time-outée) et on ne fait
rien. Et c'est encore la base : on gère des listes de choses autorisées,
pas des listes de choses interdites.

Enfin bref, on gère manuellement une session quoi... (je disais quoi
récemment sur "répéter la même chose" ?)

Pour ma part, j'ai mis en place un système automatique permettant de
gérer un UID unique par formulaire sans le passé sous forme de
paramètre hidden.

Que ce soit par hidden, par paramètre dans un lien <a href>, par cookie
ou par pigeon voyageur, peu importe le mode de transmission, çà marchera
pareil.

JG

Tu as deux grands types de solutions, parfaitement combinables d'ailleurs.

Merci pour ces explications.
Concernant tes cours sur www.saphirtech.com , je les ai un peu survolés,
très interressants, je vais approfondir.

Christophe