2012-03-02 84 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