Meilleure pratique: comment gérer la concurrence du navigateur et du site Web

Question

C’est un problème bien connu de tous les développeurs Web. Pour autant que j'ai essayé de trouver une bonne solution à ce problème - il n'y en avait pas (ou du moins je ne pouvais pas le trouver).

Supposons ce qui suit:

L'utilisateur ne se comporte pas comme il le devait. Le projet dans lequel je travaille utilise la navigation dans le portail Web. Mais si l'utilisateur utilise le bouton de retour du navigateur, l'ensemble devient jeoprady [?] Et le résultat n'était pas toujours prévisible.

Nous avons utilisé le cadre struts et stocké le back-url dans des formulaires - à certains endroits, où nous avions besoin d'un back-url - celui-ci a été rendu à partir du back-url de ce formulaire. Car il n’existait qu'un seul champ pour cette information et il n’était donc pas possible de revenir en arrière plusieurs fois.

Lorsque vous modifiez le & str; struts-flow " - ce qui peut entraîner l'utilisation d'une forme différente - ces informations seront perdues.

Si l'utilisateur ose placer un signet dans votre application Web, cette information n'a peut-être jamais été définie et le résultat sera à nouveau imprévisible ou pas assez flexible!

Ma "solution" :

Je stockais dans une session , dans la session , toutes les pages pertinentes pour la navigation visitées par l'utilisateur. Cela signifie qu'un chemin de navigation est collecté et stocké pour des navigations ultérieures.

À n’importe quelle page de la Webapp, où des back-navigations sont impliquées, j’ai utilisé une balise fabriquée par l'utilisateur qui rend le contenu de la pile dans l'URL.

Et c'est tout . Lorsque l'utilisateur clique sur cette URL de retour, la pile a été remplie avec le contenu de l'URL de destination cliquée par l'utilisateur (qui contient toutes les informations de la pile une fois que le lien de retour a été rendu).

Cela est tout à fait clair, car un clic sur un lien est un état clair, où le développeur Web sait exactement où l'utilisateur "se trouve". a ce moment précis - absolument indépendant de ce que l'utilisateur faisait auparavant (par exemple, appuyer plusieurs fois sur le bouton retour du navigateur). Ensuite, la pile de navigation est construite sur ce nouvel état.

Reprise & # 233;: Il devient clair que ce ne sera pas la meilleure solution. Mais cela permet de stocker des informations supplémentaires sur la pile, telles que des paramètres de page et d'autres éléments utiles (développements ultérieurs possibles).

Alors, quelles sont vos solutions à ce problème?

acclamations,

mana

Answer 1

La solution de pile semble intéressante, mais elle se cassera probablement si l'utilisateur choisit de naviguer "en parallèle". sur différents onglets ou à l'aide de signets.

Je crains de ne pas comprendre vraiment pourquoi vous devez conserver tout cet état pour chaque utilisateur: idéalement, le Web devrait suivre le principe REST et être complètement sans état. Par conséquent, une URL unique doit identifier une ressource unique sans avoir à conserver l'historique de navigation de chaque utilisateur.

Si votre application Web s'appuie fortement sur AJAX, vous pouvez essayer d'implémenter quelque chose comme GMail (certes, pas si facile ...), chaque modification de l'interface se traduisant par une modification de l'URL de la page. Par conséquent, chaque page est identifiée par l'URL actuelle et l'utilisateur peut naviguer simultanément ou utiliser le bouton Précédent comme d'habitude.