問題タブ [gwt-places]

私は現在、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 つのソリューションのどれがベスト プラクティスであるかということです。

アプリケーションの非常に大きな gwt プロジェクトを想像してみてください。これは、Web 上の何らかの形の科学環境にすぎません。したがって、ユーザーごとにアプリの状態が保存され、ブラウザーの履歴やブックマークに関連するものは何もありません。履歴は、アプリケーション自体に適用することさえできないものです (CAD システムなど、直感的な「戻るボタン」がないものなど)。MVP と共に最新のアクティビティと場所を使用するかどうかを検討しています。履歴管理に意味がない場合、アクティビティと場所の長所と短所は何ですか? このフレームワークは、Places と Activity のない従来の MVP+DI と比較して、コードの保守とコードのモジュール性においていくつかの利点を提供できますか? アプリが何らかの形式のプラグインに API を提供することを考慮に入れる

ハッシュバンを介してブックマーク可能な URL を持ちながら、ページ内 HTML アンカーを実装することに少し問題があります。説明は簡単です：

• アプリケーションの URL にアクセスします: http://www.mypage.com/Test.html#!mycontent

このページには多くのテキストがあり、ナビゲーション用の HTML アンカーが必要です。古いスタイルの HTML では、<a href="#myAnchor">AnchorText</a>.

• しかし、GWT アプリケーションでこのリンクをクリックすると、URL がhttp://www.mypage.com/Test.html#myAnchorに変わります。

GWT Platform は変更を認識し、my に戻りますDefaultPlace。URL をプレゼンターに関連付けることができないため、これは明らかです。

では、(単純な) 質問は次のとおりです。ハッシュバング URL を使用しながら、ページ内ナビゲーションを使用するにはどうすればよいですか?

私は現在、GWT アプリケーションに取り組んでおり、すべてがどのように適合するかについてまだ少し曖昧です (最初にフレームワーク全体を理解することなく変更を加えなければならないことの喜びですが、それはとにかく難しいかもしれません)。

UI の一部 (メイン コンテンツ、ツールバー、リストなど) に対応するアクティビティがいくつかあります。それがアクティビティの意図であるかどうかはよくわかりませんが、今は簡単に変更できないと思います。私の問題は、物事のリストがメインコンテンツにも必要な状態 (現在の選択) を保持し、ある意味でツールバーにも保持されていることです (少なくともツールバーには現在それがあります – 私は尋ねることはできません)。

しかし、実際にそれを保管するのに適切な場所はどこでしょうか? 実際のビューの実装を組み合わせて、選択内容をリストにのみ保存することは、それほど明るい考えではないと思います。

ページの上部に、ボタンとアンカーを含むヘッダー バーがあります。ヘッダー バーのアンカーの 1 つを使用すると、次の操作を行うダイアログが開きます。

ビューは、この場所に関連付けられているアクティビティの start メソッドで、新しい場所への goTo を実行するアクティビティを呼び出します。これは、カスタム ダイアログ ボックスをインスタンス化するための呼び出しです。

現在、ここで発生している 2 つの問題があります。

1) 場所はヘッダー バーからナビゲートされているため、ヘッダー バー アクティビティはアクティビティ マネージャーによってシャットダウンされているため、アンカーをクリックした後にボタンが機能しません。ヘッダー バーのアクティビティをシャットダウンしたくありません。

2) このアンカーをクリックすると、画面中央のメイン パネルが空白になります。なぜこれが起こっているのかわかりませんが、明らかに望んでいません。

これら2つの問題を解決するにはどうすればよいですか?

私のGinが注入されたGWTアプリケーションは、アクティビティと場所とともにRequestFactoryを使用します。

stableId()プレイス内のRequestFactoryをトークン化するために、RequestFactoryを注入します。これにより、クラスはとにアクセスできgetProxyId(token)ますgetHistoryToken(stableId)。Tokenizerは、静的ではない保護されたメソッドを呼び出して、特定のプレイスをトークン化します。

これがサンプルクラスです。

この戦略では、新しい場所が必要な場所にプロバイダーを注入する必要があります。残念ながら、これには静的トークナイザーが含まれます。

requestStaticInjection()Ginクライアントモジュールで（Placeクラスごとに）静的インジェクションを開始しようとしました。歴史を除いて、私が持っているものは機能します。静的プロバイダーを初期化できません。TokenizerでNull例外が発生します。

これを行うためのより良い方法はありますか？ポインタありがとうございます。

場所の変更時にアクティビティの状態を更新するベスト プラクティスは何ですか? カテゴリのリストとカテゴリ内のアイテムのリストを表示するビューを持つアクティビティがあるとします。別のカテゴリが選択されている場合、アプリはカテゴリ ID を持つ新しい場所に移動します。次に、アイテムを更新するだけで、カテゴリ リストを再読み込みする新しいアクティビティを作成したくありません。

私の現在のアプローチは次のようなものです：

GWT のアクティビティと場所についての私の理解では、画面上の特定の領域に対して と がActivityManagerありActivityMapperます。画面上に複数の領域を持つことができます。つまり、複数のActivityManagersand ActivityMappers(領域ごとに 1 つ) を持つことができます。そのため、が与えられたときに表示されるはずのアクティビティをそれぞれPlaceChangeに尋ねるときはいつでも。これは、さまざまなアクティビティを実行するためにさまざまな方法で再利用する共通のレイアウトがある限り、うまく機能します。私の質問は、異なるユーザーが根本的に異なるレイアウトを使用する場合をどのように処理するかということです。私の最初の考えは、さらに多くのとを使用することです。 が特定のリージョンを使用しない場合は、ActivityManagersActivityMapperPlacePlacesPlacesActivityManagersActivityMappersPlaceActivityMapperfor that region はnull、それに変更すると単純に返されPlaceます。より良い方法があれば、知恵をいただければ幸いです。

AcceptsOneWidgetタブ付きペインを含む「表示領域」（ ）があるとします。別のタブをクリックすると（つまり、「fantastico」から「profile」に移動すると）、ペイン内にまったく新しいコンテンツが表示されます。ユーザーが[プロファイル]タブをクリックするまで、表示に必要なコードをダウンロードする必要がなかったため、これはコード分割の完璧なユースケースのようです。（注： GWTの達人が同意せず、これがコード分割の正しいユースケースであると思わない場合は、それを私に指摘してください。ただし、それはこの質問のポイントを超えているので、我慢してください！）

さて、基本的なGWTアーキテクチャの理解が正しければ、「プロファイル」タブを表示するために必要なコードは、 Activity（ies）、 （s） 、おそらく、、、PlaceなどのMVPのもので構成されます。もちろんこれアプリケーションと開発者によって異なりますが（GWTで学んだように、同じ目的を達成する方法はたくさんあります）、それでも、MVP/アクティビティ/場所の「もの」の集まりです。この質問のために、私はこのSO質問の回答者によって提案されたモデルが好きです。PresenterModuleEntryPoint

AsynchProviderパターンに関するこの記事を読んだ後、これらすべてのベストプラクティスを結び付けて、次のアーキテクチャを実現しようとしています。

• ペインの各タブが独自のフラグメントとしてcodesplit（codesplitted？codesplat？）になるようにコード分割を実装し、ユーザーが初めてクリックした場合にのみダウンロードします
• 各フラグメント（タブ/ペイン）を表示/レンダリング/実装するために必要なすべてのコードは、きちんと整理されておりAsynchProvider、上記の記事で参照されているパターンに従います。これにより、コンパートメント化でき、他のフラグメントに依存しなくなります

私はすべての要素をまとめ始めていますが、これら2つの概念を実際のコードでどのように結び付けることができるかはまだわかりません。

GWTは神秘的で、強力で、すばらしいものであると感じていますが、実際のコード例がないと学ぶのは非常に困難です。もちろん、これらのワイヤーフレームは「fantastico」または「profile」ペインで実際には複雑さを示していないので、これらは両方とも豊富なUIコンポーネントを備えたかなり洗練された表示領域であることに耐えてふりをしてください。前もって感謝します！