1

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

問題は、window.location トランスポートを使用することで、GWT のプレース システムが URL の編集をキャッチし、存在しない場所に移動しようとすることです。

私たちはサードパーティに変更を求める影響力を持っているので、私が見ることができる3つのオプションは次のとおりです。

  1. 試行されたプレイス ナビゲーションをキャッチし、このサード パーティの JS が使用する予約済み文字列の特定のリストが含まれている場合は無視します。
  2. window.name を使用するようにサードパーティにソリューションを変更してもらいます (サードパーティ側のリ​​ファクタリングが少なくなります)。
  3. JSONP を利用するようにサード パーティにソリューションを変更してもらいます (サード パーティ側でのリファクタリングを増やす)。

実際に＃1を達成する方法はありますか?

編集そこで、GWT の PlaceHistoryHandler の独自のバージョンを展開し、handleHistoryTokenメソッドを変更することで、#1 を達成する方法を見つけました。問題は、これら 3 つのソリューションのどれがベスト プラクティスであるかということです。

4

1 に答える 1

1

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

とは言っても、実際に場所の履歴を使用していない場合は、最近の場所のスタックを保持する PlaceHistoryHandler のようなカスタム クラスで Places + Activities を簡単に使用して、アプリケーションが許可する場合にそれらに戻ることができます。これにより、ブラウザーの [戻る] ボタンが意味をなさなくなりますが、場所によるナビゲーションを内部的に許可することはできます。

それが理にかなっているケースでない限り (アプリはハッシュ トークンを必要としないため、ドメイン間通信に使用するために残しておいてください)、私は #2 または #3 に投票します。

于 2012-03-02T23:20:14.603 に答える