浏览器历史管理 [英] Browser History Management
问题描述
我试图找到一个干净的解决方案,以最有效的方式处理浏览器历史记录。 (我使用的是GWT,但这个问题实际上比这个更普遍)。
这是我的情况(我认为它很标准):
我有一个Web应用程序,它具有几个不同的页面/位置/位置(无论您想要调用它),这些应用程序会响应浏览器历史记录的更改而显示。除了通常的首页,功能,联系人等大多是静态HTML页面之外,还有一个用户部分,用户可以登录他们的用户帐户(我们称之为)项目用户可以在其中进行项目工作。
因此,现在我只需使用名为 #Home , #Features , #Contact 等,以及#用户, #Project 以访问不同的页面。并且一切都很好,除了以下情况:
例如,如果有人打开链接 #Project ,那么该人员会显示一个项目登录对话。这个登录对话框有一个 cancel 按钮,我想简单地通过从我的应用程序调用浏览器的 back 按钮来实现(很简单)。我想这样做的原因有两方面:
- 您可以从应用中的多个不同位置访问此登录对话框,以及您的书签,并且通过这种方法,我不需要跟踪用户来自哪里。 更重要的是:如果我确实记得用户来自哪里来自(例如 #Home )并将用户forward链接到该地点,我得到以下效果:
- 假设用户访问 #Home ,然后点击 #Features ,然后点击项目登录。 如果用户单击取消按钮,然后我将他向前发送到 #Features ,然后点击浏览器的 back 按钮,将返回登录对话框,然后再次#特点,最后是 #Home 。不是你真正期望的。
- 相反,如果我只是简单地实现 cancel,你会立即返回到 #Home
此时,一切都是很好,除非用户最初通过直接书签链接到 #Project 转到此登录对话框。因为如此,如果我仅仅拥有 cancel = back ,那么用户将被从页面发送回他的浏览器的开始页面或以前的任何位置。因此,在这种情况下,我确实需要将前进链接到 #Home 。
现在,我试着想到几个这些方法来解决这个问题,并提出了一些解决方案,但没有一个对我来说很合适,但让我分享它们,或许可以挑起一些创造性:
第一个以小写字母开头,第二个也以大写字母开头。即 #Home 转换为 #Home , #home , #Home 。
看起来这应该是一个非常普遍的问题,我希望你们中的一个能够指出我比迄今为止的想法更有用的方向。
在你的用户可以访问#LOGIN对话框之前,你的入口点类将被执行。在这堂课你可以记住最后一个已知的页面。在登录活动/演示者中,您可以添加浏览器历史记录事件处理程序,该处理程序会检查最后一个已知位置是否为空。如果为null,则将用户发送到#HOME页面。
您无需向浏览器询问用户访问过您应用中的哪些地方。如果您想要:[#HOME,#LOGIN,#FEATURES,#HOME],您可以记住每个会话的整个历史记录。
I'm trying to find a clean solution to working with the browser history in the most effective way. (I'm using GWT, but this question is really more general than that.)
Here's my situation (I would think it's pretty standard):
I have a web application that has several different pages/places/locations (whatever you want to call it), which I display in response to changes to the browser history. Beyond the usual "Home", "Features", "Contact", etc. which are mostly static HTML pages, there is a "User" section, where people can log into their user accounts and (let's call it) a "Project" section, where users can work on their projects.
So, now I simply use local links called #Home, #Features, #Contact, etc., as well as #User, #Project to get to the different pages. And everything is fine, except the following scenario:
If someone opens the link #Project, for example, that person is shown a project login dialog. This login dialog has a cancel button, which I would like to implement simply by calling the browser's back button from my app (easy enough). The reason I would like to do this, is two-fold:
- You can get to this login dialog from several different locations in the app, as well as your bookmarks, and with this approach I wouldn't need to keep track of where the user came from.
- Much more importantly: If I instead did remember where the user came from (e.g. #Home) and linked the user "forward" to return to that place, I get the following effect:
- Let's say the user visits #Home, then #Features, and then clicks on project login.
- If the user clicks the cancel button and I send him "forward" to #Features, a click on the browser's back button afterwards would bring back the login dialog, then again #Features and finally #Home. Not really what you would expect.
- Instead you'd want to get back to #Home immediately, just what you get if I simply implement cancel via the browser's back function.
At this point everything is great, except when the user initially goes to this login dialog via a direct bookmark link to #Project. Because then, if I simply have cancel = back, the user is sent away from the page entirely back to his browser's start-page or wherever he was before. So, in this case, I do need to link "forward" to #Home.
Now, I've tried to think of several ways to fix this and have come up with a couple of solutions, but none seem very desirable to me, but let me share them anyways to maybe stir up some creativity:
- When the page is first opened, grab the history token. If it's #Project or #User or anything else that triggers a cancelable dialog, place the following items onto the history stack: #Home, #Project, where the last one is the saved initial token. This, then, allows my cancel button to function correctly... once... But, if a user clicks back afterwards, he will get the login dialog again (since the original history token is still in the history stack and I don't know how to clear it). A click on cancel then would take him off the page (inconsistent behavior).
- I could instead place #+++, #Home, #Project onto the stack, which would then allow me to catch a back click that would take the user off the page by detecting the #+++ link and simply re-adding the #Home token onto the stack. This would solve the problem and works beautifully overall, except that I hate websites that don't let you back out of them without hammering the back button quickly enough...
- The cleanest solution would be, if I could somehow keep track of the length of the history stack as far as places in my app are concerned. Easy enough at the start: It's got one item on it. But what if I get a sequence of places like this: #Home, #Features, #Home? Did the user click back to get back to #Home, i.e. the history is now length 1 in the browser, or did he click on the #Home link, i.e. the history is length 3? My idea for detecting this would be:
- Define, that #Home is the same as #home.
- Have all links in the page link only to the upper-case version of the link.
- Whenever you get a history change notification that starts with an upper-case letter, immediately add two more items to the history, the first beginning with a lower-case letter and the second also beginning with an upper-case letter. I.e. #Home is turned into #Home, #home, #Home.
- If you ever get a history change that starts with a lower-case letter, you know the user just clicked back rather than a link and you simply click back two more times for him to actually get back to the previous page.
- Now you can distinguish between "backward" and "forward" links and maintain an accurate history model in the code.
- But, unfortunately, there's two problems with this: For one, the browser history get's cluttered with crap (not very elegant) and, second, the system starts to break down, if the user ever clicks back quickly enough so that your app doesn't have time to react to the message.
It seems like this should be a very common problem and I am hoping that one of you can point me to a more useful direction than my thoughts have so far.
Before your user can access #LOGIN dialog, your entry point class is executed. In this class you can remember the last known page. In Login activity/presenter you can add a browser history event handler, which checks if the last known place is null or not. If null, send a user to the #HOME page.
You don't need to ask the browser which places in your app a user has visited. You can remember the entire history of each session, if you want to: i.e. [#HOME, #LOGIN, #FEATURES, #HOME].
这篇关于浏览器历史管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!