2012-03-02 101 views
1

我目前有一个GWT项目利用Google提供的Activities和Places模型。我们正在与第三方跨域JavaScript解决方案集成,该解决方案将外部域的JSP呈现在iframe中,并利用window.location传输来在用户完成此JSP中的工作时通知我们的域。GWT和第三方跨域JavaScript

问题是,通过使用window.location传输GWT的地方系统将捕获URL的编辑并尝试导航到一个不存在的地方。

我们确实有一定的影响力,以获得第三方改变,因此这三个选项,我可以看到的是:

  1. 赶上企图地方航行,而忽略它,如果它包含保留的字符串一定名单,这第三方JS使用。
  2. 获取第三方来改变他们的解决方案,利用window.name(在他们的部分较少的重构)
  3. 获取第三方来改变他们的解决方案,利用JSONP(在他们的部分更多的重构)

有什么办法可以实现#1吗?

编辑所以我想通了,如何通过我自己的滚动GWT的PlaceHistoryHandler的版本和改变handleHistoryToken的方法来达到#1。真正的问题是这三种解决方案中的哪一种是最佳实践?

回答

1

如果可能,我的投票将改变跨域信号。浏览器显示的URL意味着可以将页面加入书签以再次加载,并且它提供了一种操纵页面历史的方式。基于这种机制建立另一种机制会使用户收藏书签或导航到对历史记录处理系统没有意义的页面/地点,甚至可能会向应用程序发出iframe实际上并未加载的信号。这就是说,如果你实际上没有使用历史记录,你可以像使用自定义PlaceHistoryHandler类的自定义PlaceHistoryHandler一样简单地使用Places + Activities来保留最近的地方堆栈,以便在应用程序允许时返回它们它。这将防止浏览器后退按钮变得有意义,但仍然可以允许在内部导航。

除非这是有道理(应用程序并不需要哈希的道理,所以把它用于域间通信)的情况下,我会投票给#2或#3。

+0

关于页面的可见度的好处。由于某种原因,我完全忽略了GWT使用这个url的这个焦点。 – michaelwritescode 2012-03-06 18:14:17