浏览器历史管理 [英] Browser History Management

问题描述

我试图找到一个干净的解决方案，以最有效的方式处理浏览器历史记录。 （我使用的是GWT，但这个问题实际上比这个更普遍）。

这是我的情况（我认为它很标准）：

我有一个Web应用程序，它具有几个不同的页面/位置/位置（无论您想要调用它），这些应用程序会响应浏览器历史记录的更改而显示。除了通常的首页，功能，联系人等大多是静态HTML页面之外，还有一个用户部分，用户可以登录他们的用户帐户（我们称之为）项目用户可以在其中进行项目工作。

因此，现在我只需使用名为 #Home ， #Features ， #Contact 等，以及＃用户， #Project 以访问不同的页面。并且一切都很好，除了以下情况：

例如，如果有人打开链接 #Project ，那么该人员会显示一个项目登录对话。这个登录对话框有一个 cancel 按钮，我想简单地通过从我的应用程序调用浏览器的 back 按钮来实现（很简单）。我想这样做的原因有两方面：

1. 您可以从应用中的多个不同位置访问此登录对话框，以及您的书签，并且通过这种方法，我不需要跟踪用户来自哪里。 更重要的是：如果我确实记得用户来自哪里来自（例如 #Home ）并将用户forward链接到该地点，我得到以下效果：
   
   
   
   • 假设用户访问 #Home ，然后点击 #Features ，然后点击项目登录。 如果用户单击取消按钮，然后我将他向前发送到 #Features ，然后点击浏览器的 back 按钮，将返回登录对话框，然后再次＃特点，最后是 #Home 。不是你真正期望的。
   
   
   • 相反，如果我只是简单地实现 cancel，你会立即返回到 #Home
   
   

此时，一切都是很好，除非用户最初通过直接书签链接到 #Project 转到此登录对话框。因为如此，如果我仅仅拥有 cancel = back ，那么用户将被从页面发送回他的浏览器的开始页面或以前的任何位置。因此，在这种情况下，我确实需要将前进链接到 #Home 。

现在，我试着想到几个这些方法来解决这个问题，并提出了一些解决方案，但没有一个对我来说很合适，但让我分享它们，或许可以挑起一些创造性：

• 首次打开页面时，抓取历史记录标记。如果是 #Project 或 #User 或触发可取消对话框的其他任何内容，请将以下内容放置到历史堆栈中： #Home ， #Project ，最后一个是保存的初始令牌。然后，这允许我的 cancel 按钮正确运行...一次...但是，如果用户之后单击 back ，他将再次获得登录对话框（因为原始的历史令牌仍然在历史堆栈中，我不知道如何清除它）。点击 cancel 然后会将他从页面中移除（不一致的行为）。
  
• 我可以改为放置＃+++ ， #Home ， #Project 放到堆栈上，然后我可以捕获 back 点击，通过检测用户离开页面＃+++ 链接，并简单地将 #Home 标记重新添加到堆栈中。这样可以解决问题，并且整体效果非常好，除非我讨厌那些不会让您退出的网站，而无需足够快地敲击后退按钮......


• 最简洁的解决方案是是的，如果我能以某种方式跟踪历史堆栈的长度，就我应用中的位置而言。在开始时足够简单：它上面有一个项目。但是如果我得到一系列像这样的地方： #Home ， #Features ， #Home ？用户点击 back 返回到 #Home ，即历史现在在浏览器中是长度1，还是点击 #Home 链接，即历史是长度3？我的想法是：
  
  
  
  • 定义， #Home 与 #home 相同。 li>
    
  • 使页面中的所有链接仅链接到链接的大写版本。
  
  
  • 每当您获取以$开头的历史更改通知b $ b大写字母，立即将两个项目添加到历史记录中，
    第一个以小写字母开头，第二个也以大写字母开头。即 #Home 转换为 #Home ， #home ， #Home 。
    
  • 如果您的历史更改以小写字母开头，则您知道用户只需点击 back 而不是链接，然后只需点击 back 两个现在您可以区分后退和前进链接，并在代码中保留精确的历史记录模型。
  >
  
  • 但是，不幸的是，这有两个问题：首先，浏览器历史记录变得杂乱无章（不是很优雅）;其次，如果用户点击< kbd> back 足够快，以便您的应用程序没有时间对邮件做出反应。
  
  

看起来这应该是一个非常普遍的问题，我希望你们中的一个能够指出我比迄今为止的想法更有用的方向。

解决方案

在你的用户可以访问#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:

1. 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.
2. 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屋！