Discussion :

[BugFactory]

Bonjour,

Dans le site Web sur lequel je travaille, il est possible d'accéder à certaines pages après avoir rempli un formulaire. Problème : si l'utilisateur essaie plus tard de revenir sur cette page à l'aide du bouton back ou d'un marque-page, ça ne marchera pas : l'url de la page est l'url de validation du formulaire. Accéder directement à l'URL du formulaire ne permet pas au serveur de retrouver la page suivante, car elle dépend du contenu du formulaire. Je voudrais donc, quand la page suivante est chargée après validation du formulaire, remplacer l'adresse de la page par une URL permettant d'y accéder directement.

J'ai pensé à window.history.pushState et window.history.replaceState, mais ces méthodes ne remplacent pas l'entrée de la page en cours dans l'historique : elles en ajoutent une nouvelle. Ça permet effectivement de revenir sur la page à l'aide du bouton back, mais si l'utilisateur clique une deuxième fois sur back, il se retrouve à nouveau sur l'adresse de validation du formulaire plutôt que sur le formulaire lui-même.

Savez vous comment obtenir l'effet désiré?

Merci d'avance.

[Watilin]

Tu es sûr que tu utilises replaceState correctement ? D'après la doc :

history.replaceState() fonctionne exactement comme history.pushState() hormis le fait que replaceState() modifie l'entrée courante de l'historique au lieu d'en créer une nouvelle.

Voici un exemple d'appel à replaceState :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

history.replaceState(null, '', 'nouvelle-url');

Cela dit, si la nouvelle URL correspond à une page pouvant être générée par le serveur – et c'est a priori ton cas, car tu veux permettre à tes utilisateurs de mettre l'URL en marque-page – l'utilisation de replaceState n'est pas forcément adéquate ici. Envisage une redirection plus classique : header('Location: ...') en PHP, ou un code 302 envoyé « à la main » depuis ton serveur, ou location.replace en JS.

[BugFactory]

Bonjour,

Merci de votre réponse. Je ne suis pas sûr d'utiliser replaceState correctement puisque je n'obtiens pas l'effet désiré. J'ai essayé votre exemple mais le résultat est le même : deux entrées dans l'historique au lieu d'une. La redirection via le header ou location.replace provoque un rechargement de la page, ce que je souhaite éviter.

[Watilin]

Mea culpa, je n'ai pas vérifié tous les aspects de l'historique… Je pensais à l'historique qui apparaît quand on fait un clic droit sur le bouton « précédent ». Dans cet aspect, on constate bien la différence de comportement entre pushState et replaceState. Cependant, dans l'historique « global » du navigateur, qui apparaît par exemple en faisant Ctrl+H, on a une nouvelle entrée dans les deux cas. Je ne sais pas comment remédier à ce problème.

Je te propose une autre approche. Intercepte la soumission classique du formulaire et remplace-la par un appel Ajax. Tu récupères ainsi le message de validation du formulaire dans la réponse Ajax, et tu peux rediriger ensuite l'utilisateur vers la page suivante, celle qui a une adresse permanente, avec location.replace. De cette manière la page de validation n'apparaît pas dans l'historique.

[BugFactory]

C'est une bonne idée, ça implique un appel au serveur supplémentaire, mais on obtient l'effet désiré.

Ceci dit, il faudrait réécrire beaucoup trop de code pour utiliser cette idée sur le projet en cours, et il faudrait me passer de la gestion des formulaires de Spring MVC. Je vais donc garder cette idée en réserve pour une autre application.

Pour ce projet, je vais accepter que l'adresse de validation du formulaire apparaisse dans l'historique.

[Watilin]

Ceci dit, il faudrait réécrire beaucoup trop de code pour utiliser cette idée sur le projet en cours, et il faudrait me passer de la gestion des formulaires de Spring MVC.

Je ne suis pas convaincu. Si tu suis ces quelques étapes, ça ne fait que quelques lignes de code et le serveur ne voit pas la différence :

1. intercepter l'évènement "submit" et l'annuler avec preventDefault
2. sérialiser le formulaire avec un objet FormData (*)
3. lancer une requête Ajax avec les données sérialisées dans le corps de la requête
4. extraire l'URL qui t'intéresse de la réponse HTML avec une regexp bien pensée

(*) Pour les navigateurs qui ne supportent pas FormData (IE<10), tu peux copier le outerHTML du formulaire dans une iframe invisible, soumettre la copie de formulaire et lire le innerHTML de l'iframe pour avoir la réponse du serveur.