Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
bonjour,
je suis en train de travailler sur un contrôleur qui peut être invoqué de différentes façon par l'utilisateur (liens, POST de formulaires, etc) et qui effectue en interne de nombreuses redirections (genre pattern PRG)
Ma bête noire (et qui complique tout) ce sont les boutons "BACK" et "FORWARD" qui se trouvent en haut du navigateur. Si l'utilisateur clique intempestivement sur ces boutons, que ce soit par réflexe ou par flemmardise de suivre certains liens sur l'interface, alors le contrôleur s'emmêle les pinceaux et perd le fil de la navigation...
L'usage de la directive HTTP "Cache-Control:no-cache" prévient des rechargements (RELOAD) mais n'empêche pas l'historisation des pages et leur effet dévastateur.
Comment s'en sortir ?
Hors ligne
Logiquement il me semble que si tu utilise des code de redirection approprié, le navigateur "prendra note" de la redirection et donc lors du "back", il ira à la bonne page (j'me rapelle plus trop mais chui sur d'avoir vu ça sur un site)
Hors ligne
Un des grands principe ergonomique a respecter est de ne pas "briser la navigation", c'est a dire d'empecher l'utilisateur d'utiliser les boutons back et forword. C'était un des gros défaut reproché a AJAX et aux interfaces en flash. Depuis, on a trouver des astuces pour préserver "la navigation" en jouant avec des ancres. C'est une réelle avancée.
Vouloir faire le contraire et empécher l'historisation est AMHA, un vrai mauvais choix.
Ne pas mettre en cache systématiquement va à l'encontre des performances.
Je pense que tu devrais plutot revoir ta conception et accepter l'utilisation normal d'un navigateur par l'utilisateur.
Ce n'est pas un reflexe ou de la flem mais une utilisation on ne peux plus normale que d'utiliser back et forward.
Hors ligne
la solution Une seule url pour tout ton pattern
Post /module/controller/action
avec les data
tu mets en session les données et l'étape ou tu te trouve (begin)
et tu envoit un redirect sur la même action
Get /module/controller/action
tu lis l'étape et tu vérifie les données tu mets à jours l'étape et les messages en session
puis tu refait un redirect sur la même url
Get /module/controller/action
là tu recommence tu lis l'étape dans la session et tu traite la demande et tu envois encore un redirect
Get /module/controller/action
encore une fois cette fois ci pour terminer le process tu prépare ta vue et tu fais le ménage dans la session
ainsi que ton client fasse F5 reload ou goback il est toujours sur la même action
comme chaque étape est courte il en a fais plusieurs avant même de réagir il ne fait que re traiter le pas courant puisque c'est le serveur qui gère la progression
autre avantage si ton traitement est très long tu le coupe en petit bout et tu re-boucle avec des redirect. du coup plus de pb de timeout
j'utilisais cette technique avec un autre framework qui gérait de cette façon les actions il n'y avais qu'une url pour toute l'application
c'est côté serveur en session qu'était gardé l'action en cour
A+JYT
Hors ligne
merci pour les réponses
pour ce qui est de la navigation inverse et avant : l'empêcher ? (avec du javascript ??) non heuresement ! si j'édite un item d'une liste les actions de l'utilisateur :
'CLIC sur lien RETOUR'
'CLIC sur bouton ENREGISTRER'
'GO BACK'
doivent bien évidemment retourner à la liste ! (avec m-à-j dans le second cas)
Le hic c'est que mon appli gère des listes d'items qui eux-mêmes peuvent contenir des listes imbriquées (3 ou 4niveaux maximum)
sur un modèle relationnel ressemblant à
[RaisonSociale] contient [Implantation] contient [questionnaire-information-daté] contient [chapitre/section de fiche]
comme ceci :
et que vu l'avancement (et le retard) du projet je ne peux pas ré-écrire tout le controleur, mais plutôt améliorer son schéma de navigation structuré (et déjà link-é grâce à la session)...
merci pour les encouragement, je creuse encore ...
Hors ligne