AcceptsOneWidget
タブ付きペインを含む「表示領域」( )があるとします。別のタブをクリックすると(つまり、「fantastico」から「profile」に移動すると)、ペイン内にまったく新しいコンテンツが表示されます。ユーザーが[プロファイル]タブをクリックするまで、表示に必要なコードをダウンロードする必要がなかったため、これはコード分割の完璧なユースケースのようです。(注: GWTの達人が同意せず、これがコード分割の正しいユースケースであると思わない場合は、それを私に指摘してください。ただし、それはこの質問のポイントを超えているので、我慢してください!)
さて、基本的なGWTアーキテクチャの理解が正しければ、「プロファイル」タブを表示するために必要なコードは、 Activity
(ies)、 (s) 、おそらく、、、Place
などのMVPのもので構成されます。もちろんこれアプリケーションと開発者によって異なりますが(GWTで学んだように、同じ目的を達成する方法はたくさんあります)、それでも、MVP/アクティビティ/場所の「もの」の集まりです。この質問のために、私はこのSO質問の回答者によって提案されたモデルが好きです。Presenter
Module
EntryPoint
AsynchProviderパターンに関するこの記事を読んだ後、これらすべてのベストプラクティスを結び付けて、次のアーキテクチャを実現しようとしています。
- ペインの各タブが独自のフラグメントとしてcodesplit(codesplitted?codesplat?)になるようにコード分割を実装し、ユーザーが初めてクリックした場合にのみダウンロードします
- 各フラグメント(タブ/ペイン)を表示/レンダリング/実装するために必要なすべてのコードは、きちんと整理されており
AsynchProvider
、上記の記事で参照されているパターンに従います。これにより、コンパートメント化でき、他のフラグメントに依存しなくなります
私はすべての要素をまとめ始めていますが、これら2つの概念を実際のコードでどのように結び付けることができるかはまだわかりません。
GWTは神秘的で、強力で、すばらしいものであると感じていますが、実際のコード例がないと学ぶのは非常に困難です。もちろん、これらのワイヤーフレームは「fantastico」または「profile」ペインで実際には複雑さを示していないので、これらは両方とも豊富なUIコンポーネントを備えたかなり洗練された表示領域であることに耐えてふりをしてください。前もって感謝します!