GWTとサードパーティのクロスドメインJavaScript

Question

私は現在、GWTプロジェクトでGoogleが提供するアクティビティと場所モデルを利用しています。私たちは、iframeに外部ドメインのJSPをレンダリングし、ユーザーがこのJSPで作業を終えたときにwindow.locationトランスポートを使用してドメインに通知するサードパーティのクロスドメインJavaScriptソリューションと統合しています。

問題は、window.locationトランスポートを使用することによって、GWTのプレースシステムがURLの編集をキャッチし、存在しない場所に移動しようとすることです。私たちは、私が見ることができる3つのオプションを変更するには、サードパーティを得るために、いくつかの影響力を持っている

は以下のとおりです。

1. が試み場所のナビゲーションをキャッチし、それがこの予約文字列の特定のリストが含まれている場合はそれを無視しますサードパーティのJSが使用します。
2. JSONP（その部分の詳細リファクタリング）

を利用するために彼らのソリューションを変更するには、サードパーティを取得

（その一部にはあまりリファクタリング）window.nameを利用するためにその解決を変更するために第三者を取得実際に＃1を達成する方法はありますか？

EDITだから私は、GWTのPlaceHistoryHandlerの私の独自のバージョンをロールし、handleHistoryToken方法を変更することで第1位を達成する方法を考え出しました。実際の質問は、これら3つのソリューションのどれがベストプラクティスであるかです。

Answer 1

可能であれば、クロスドメインシグナリングを変更することになります。ブラウザーで表示されるURLは、ページをブックマークして再度ロードできることを意味し、ページの履歴を操作する方法を提供します。それに基づいて別のメカニズムを構築すると、ユーザは履歴トークン処理システムにとって意味のないページ/場所にブックマークしたりナビゲートしたりすることになり、実際にはiframeがロードされていないことをアプリに通知することさえあります。

つまり、場所で履歴を実際に使用していない場合は、PlaceHistoryHandlerのようなクラスでPlaces + Activitiesを簡単に使用することができます。それ。これにより、ブラウザの「戻る」ボタンが意味をなさないようになりますが、内部的には場所によるナビゲーションが可能になります。

（アプリケーションでハッシュトークンが必要ないので、ドメイン間通信に使用するようにしておきます）、＃2または＃3に投票します。