最佳实践：如何处理浏览器和网站导航的并发
对于每个 Web 开发人员来说，这是一个众所周知的问题。 据我试图找到解决这个问题的好方法 - 没有（或者至少我找不到）。
让我们假设以下情况：
用户的行为没有达到预期。我正在处理的实际项目使用了导航门户网站。 但如果用户使用浏览器的后退按钮，整个事情就会变得危险[?]，并且结果并不总是可预测的。
我们使用了 struts 框架并将 back-url 存储到表单中 - 在某些地方，我们需要一个 back-url - 这已从该表单的 back-url 中呈现出来。 因为该信息只有一个字段，因此不可能返回多个步骤。
当您更改“struts-flow”时 - 这可能会导致使用不同的形式 - 此信息将丢失。
如果用户敢在您的网络应用程序中的某个位置放置书签 - 该信息可能永远不会被设置，并且结果将再次变得不可预测或不够灵活！
我的“解决方案”：
我将用户访问的每个与导航相关的页面存储到类似堆栈的存储中，并存储到会话中。 这意味着收集并存储导航路径以供以后导航。
在 web 应用程序中涉及反向导航的任何页面上，我使用了一个自制标签，将堆栈内容呈现到 url 中。
就是这样。 单击此反向 URL 时，堆栈已填充用户单击的反向 URL 中的内容（呈现反向链接后，该堆栈保存堆栈中的所有信息）。
这是非常清楚的，因为点击链接是一个清晰的状态，网络开发人员确切地知道用户此时“在”哪里——绝对独立于用户之前所做的任何事情（例如多次点击浏览器后退按钮）次）。 然后导航堆栈就建立在这个新状态的基础上。
简历： 很明显，这不是最好的解决方案。 但它允许在堆栈上存储附加信息，例如页面参数和其他一些有用的东西（可能进一步开发）。
那么，您对这个问题的解决方案是什么？
干杯，
法力
It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
堆栈解决方案听起来很有趣，但如果用户选择在不同选项卡上“并行”导航或使用书签，它可能会崩溃。
恐怕我不太明白为什么你必须为每个用户保留所有这些状态：理想情况下，网络应该遵循 REST原则并且完全无状态。 因此，单个 URL 应该标识单个资源，而不必保留每个用户的导航历史记录。
如果您的 Web 应用程序严重依赖 AJAX，您可以尝试实现类似 GMail 的东西（诚然，不是那么容易......），其中界面中的每个更改都会反映在页面 URL 的更改中。 因此，每个页面都由当前 URL 标识，用户可以同时导航或照常使用后退按钮。
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.