javascriptgwtcross-domaingwt-places

GWT and Third Party Cross Domain JavaScript

I currently have a GWT project utilizes the Activities and Places model provided by Google. We are integrating with a third party cross domain JavaScript solution that renders an external domain's JSP in an iframe and utilizes window.location transport to notify our domain when the user has finished doing work in this JSP.

The issue is that by using window.location transport GWT's place system will catch the editing of the URL and attempt to navigate to a nonexistant place.

We do have some influence to get the third party to change so the three options I can see are:

  1. Catch the attempted place navigation and ignore it if it contains a certain list of reserved strings that this third party JS uses.
  2. Get the third party to change their solution to utilize window.name (less refactoring on their part)
  3. Get the third party to change their solution to utilize JSONP (more refactoring on their part)

Is there any way to actually achieve #1?

EDIT So I figured out how to achieve #1 by rolling my own version of GWT's PlaceHistoryHandler and changing the handleHistoryToken method. The real question is which of these three solutions is the best practice?

Solution

  • My vote would be on changing the cross-domain signaling, if possible. The browser-displayed URL implies that the page can be bookmarked to be loaded again, and it provides a way to manipulate the history of the page. Building another mechanism based on that risks the user bookmarking or navigating to a page/place that has no meaning for the history token handling system, and may even signal the app that the iframe is loaded when it actually isn't.

    That said, if you aren't actually using history with places, you could just as easily use Places + Activities with a custom PlaceHistoryHandler-like class that keeps a stack of recent places to allow returning to them if your application allows it. This would prevent the browser back button from making sense, but could still allow navigation by places internally.

    Unless that is a case that makes sense (app doesn't need the hash token, so leave it to be used for inter-domain communication), I'd vote for #2 or #3.