c'est une question sur la technique de suivi de la navigation de
l'utilisateur sur plusieurs formulaires qu'il doit remplir dans un ordre
logique que j'ai fixé
- Par programme j'envoie un formulaire (avec un no-cache ou équivalent) à
l'utilisateur qui fait un submit.
- Le no-cache évite que l'utilisateur revienne sur le même formulaire s'il
l'a enregistré plusieurs fois avec des données
- Mais le no-cache lui permet malgré tout de faire un "repost data" et là il
ne sais plus du tout la version antérieure qu'il envoie
- de la même façon il peut revenir sur d'autres formulaires différents et
puis revenir sur celui en cours
- Du coup côté serveur il faut que je puisse savoir quel est le formulaire
qu'il envoie et surtout quelle est l'occurence du même formulaire que je
reçois
Pour couper court, quelqu'un m'a suggéré en javascript de supprimer les
boutons de navigation par ouverture d'une fenêtre: çà marche.
Pour éviter qu'il ne le fasse, j'avais pensé à mettre en oeuvre un suivi des
appels aux pages par le navigateur (une sorte de pile d'appel qui me
permette de savoir de quelle page il vient) et un compteur du nombre de fois
que l'utilisateur a envoyé un formulaire ( un compteur par formulaire):
"beaucoup" de paramètres à gérer côté serveur et dans chaque page du
formulaire.
J'aurais voulu savoir comment vous faites? Ou existe-t-il un article clair
qui donne une méthode à suivre ?
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
Guillaume Bouchard
Bonjour,
Pascal Gend wrote:
c'est une question sur la technique de suivi de la navigation de l'utilisateur sur plusieurs formulaires qu'il doit remplir dans un ordre logique que j'ai fixé - Par programme j'envoie un formulaire (avec un no-cache ou équivalent) à l'utilisateur qui fait un submit.
Oui bon, le no-cache c'est pas sur a 100 %
- Le no-cache évite que l'utilisateur revienne sur le même formulaire s'il l'a enregistré plusieurs fois avec des données
Oui Bof...
- Mais le no-cache lui permet malgré tout de faire un "repost data" et là il ne sais plus du tout la version antérieure qu'il envoie
Lire les differents thread qui polluent ce NG concernant les clefs primaire, les antis refresh.
- de la même façon il peut revenir sur d'autres formulaires différents et puis revenir sur celui en cours
Possible aussi.
Pour couper court, quelqu'un m'a suggéré en javascript de supprimer les boutons de navigation par ouverture d'une fenêtre: çà marche.
Oui alors ca, perso ca m'enerve quand qqn touche a ma barre de navigation ( si bien que j'ai desactivé cette option dans mozilla, le seul navigateur qui permet de laisser les truc utiles du JS et de virer ceux qui sont chiant... http://www.mozilla.org ;o))
Et voila, si tu tombe sur un idiot comme moi qui desactive cette possibilité, voir meme un idiot dans un navigateur mode textes, il sont de plus en plus actuelement ( que ces personnes ne m'en veuille pas, je suis ironique :))
Pour éviter qu'il ne le fasse, j'avais pensé à mettre en oeuvre un suivi des appels aux pages par le navigateur (une sorte de pile d'appel qui me permette de savoir de quelle page il vient) et un compteur du nombre de fois que l'utilisateur a envoyé un formulaire ( un compteur par formulaire): "beaucoup" de paramètres à gérer côté serveur et dans chaque page du formulaire.
Bon la on en vient a de la bidouille enorme alors qu'il y a INFINIEMENT PLUS SIMPLE
Bref, reprenont. Ces utilisateurs, il sont logué ? Il y a moyen de les differencié non ? Si non, alors oublie, tu aura de toute façon plus de resultat incoherent a cause de 'tricheur' que de probleme sur back.
Bref ils sont loguer et tu sauvegarde leur reponse en base, suivant une table dans le genre :
utilisateur | numero_formulaire | reponses...
Ey bien il te suffit de mettre une contraite UNIQUE sur (utilisateur,numero_formulaire) et comme ca, il ne peut pas repondre plusieurs foix au meme form et tu sais exactement ou il en est ( pas en base : premier formulaire, sinon, tu regarde le dernier formulaire utilisé )
C'est à amelioré en fonction de ta structure, mais c'est le concept.
-- Guillaume.
Bonjour,
Pascal Gend wrote:
c'est une question sur la technique de suivi de la navigation de
l'utilisateur sur plusieurs formulaires qu'il doit remplir dans un ordre
logique que j'ai fixé
- Par programme j'envoie un formulaire (avec un no-cache ou équivalent) à
l'utilisateur qui fait un submit.
Oui bon, le no-cache c'est pas sur a 100 %
- Le no-cache évite que l'utilisateur revienne sur le même formulaire s'il
l'a enregistré plusieurs fois avec des données
Oui Bof...
- Mais le no-cache lui permet malgré tout de faire un "repost data" et là il
ne sais plus du tout la version antérieure qu'il envoie
Lire les differents thread qui polluent ce NG concernant les clefs
primaire, les antis refresh.
- de la même façon il peut revenir sur d'autres formulaires différents et
puis revenir sur celui en cours
Possible aussi.
Pour couper court, quelqu'un m'a suggéré en javascript de supprimer les
boutons de navigation par ouverture d'une fenêtre: çà marche.
Oui alors ca, perso ca m'enerve quand qqn touche a ma barre de
navigation ( si bien que j'ai desactivé cette option dans mozilla, le
seul navigateur qui permet de laisser les truc utiles du JS et de virer
ceux qui sont chiant... http://www.mozilla.org ;o))
Et voila, si tu tombe sur un idiot comme moi qui desactive cette
possibilité, voir meme un idiot dans un navigateur mode textes, il sont
de plus en plus actuelement ( que ces personnes ne m'en veuille pas, je
suis ironique :))
Pour éviter qu'il ne le fasse, j'avais pensé à mettre en oeuvre un suivi des
appels aux pages par le navigateur (une sorte de pile d'appel qui me
permette de savoir de quelle page il vient) et un compteur du nombre de fois
que l'utilisateur a envoyé un formulaire ( un compteur par formulaire):
"beaucoup" de paramètres à gérer côté serveur et dans chaque page du
formulaire.
Bon la on en vient a de la bidouille enorme alors qu'il y a INFINIEMENT
PLUS SIMPLE
Bref, reprenont.
Ces utilisateurs, il sont logué ? Il y a moyen de les differencié non ?
Si non, alors oublie, tu aura de toute façon plus de resultat incoherent
a cause de 'tricheur' que de probleme sur back.
Bref ils sont loguer et tu sauvegarde leur reponse en base, suivant une
table dans le genre :
utilisateur | numero_formulaire | reponses...
Ey bien il te suffit de mettre une contraite UNIQUE sur
(utilisateur,numero_formulaire) et comme ca, il ne peut pas repondre
plusieurs foix au meme form et tu sais exactement ou il en est ( pas en
base : premier formulaire, sinon, tu regarde le dernier formulaire utilisé )
C'est à amelioré en fonction de ta structure, mais c'est le concept.
c'est une question sur la technique de suivi de la navigation de l'utilisateur sur plusieurs formulaires qu'il doit remplir dans un ordre logique que j'ai fixé - Par programme j'envoie un formulaire (avec un no-cache ou équivalent) à l'utilisateur qui fait un submit.
Oui bon, le no-cache c'est pas sur a 100 %
- Le no-cache évite que l'utilisateur revienne sur le même formulaire s'il l'a enregistré plusieurs fois avec des données
Oui Bof...
- Mais le no-cache lui permet malgré tout de faire un "repost data" et là il ne sais plus du tout la version antérieure qu'il envoie
Lire les differents thread qui polluent ce NG concernant les clefs primaire, les antis refresh.
- de la même façon il peut revenir sur d'autres formulaires différents et puis revenir sur celui en cours
Possible aussi.
Pour couper court, quelqu'un m'a suggéré en javascript de supprimer les boutons de navigation par ouverture d'une fenêtre: çà marche.
Oui alors ca, perso ca m'enerve quand qqn touche a ma barre de navigation ( si bien que j'ai desactivé cette option dans mozilla, le seul navigateur qui permet de laisser les truc utiles du JS et de virer ceux qui sont chiant... http://www.mozilla.org ;o))
Et voila, si tu tombe sur un idiot comme moi qui desactive cette possibilité, voir meme un idiot dans un navigateur mode textes, il sont de plus en plus actuelement ( que ces personnes ne m'en veuille pas, je suis ironique :))
Pour éviter qu'il ne le fasse, j'avais pensé à mettre en oeuvre un suivi des appels aux pages par le navigateur (une sorte de pile d'appel qui me permette de savoir de quelle page il vient) et un compteur du nombre de fois que l'utilisateur a envoyé un formulaire ( un compteur par formulaire): "beaucoup" de paramètres à gérer côté serveur et dans chaque page du formulaire.
Bon la on en vient a de la bidouille enorme alors qu'il y a INFINIEMENT PLUS SIMPLE
Bref, reprenont. Ces utilisateurs, il sont logué ? Il y a moyen de les differencié non ? Si non, alors oublie, tu aura de toute façon plus de resultat incoherent a cause de 'tricheur' que de probleme sur back.
Bref ils sont loguer et tu sauvegarde leur reponse en base, suivant une table dans le genre :
utilisateur | numero_formulaire | reponses...
Ey bien il te suffit de mettre une contraite UNIQUE sur (utilisateur,numero_formulaire) et comme ca, il ne peut pas repondre plusieurs foix au meme form et tu sais exactement ou il en est ( pas en base : premier formulaire, sinon, tu regarde le dernier formulaire utilisé )
C'est à amelioré en fonction de ta structure, mais c'est le concept.
-- Guillaume.
Guillaume Bouchard
Matthias Ainsworth wrote:
Je suis d'accord. La clef unique est incontournable. Mais pourquoi vouloir "verrouiller" les formulaires ? Dans ta méthode il n'empèche qu'il subsiste tout de même un cas de figure : imagine le type qui s'est planté dans un formulaire et qui voudrait modifier des infos... comment fait-il ?
Ba si il raffiche le formulaire, tu lui remet les valeur deja entrée pour qu'il les modifie ? Ou est le probleme ?
-- Guillaume.
Matthias Ainsworth wrote:
Je suis d'accord. La clef unique est incontournable. Mais pourquoi vouloir
"verrouiller" les formulaires ? Dans ta méthode il n'empèche qu'il subsiste
tout de même un cas de figure : imagine le type qui s'est planté dans un
formulaire et qui voudrait modifier des infos... comment fait-il ?
Ba si il raffiche le formulaire, tu lui remet les valeur deja entrée
pour qu'il les modifie ? Ou est le probleme ?
Je suis d'accord. La clef unique est incontournable. Mais pourquoi vouloir "verrouiller" les formulaires ? Dans ta méthode il n'empèche qu'il subsiste tout de même un cas de figure : imagine le type qui s'est planté dans un formulaire et qui voudrait modifier des infos... comment fait-il ?
Ba si il raffiche le formulaire, tu lui remet les valeur deja entrée pour qu'il les modifie ? Ou est le probleme ?
