GWT アプリを計画しています。Ray Ryan が Google IO 09 で言ったように:
「履歴を正しく取得し、早期に正しく取得してください」。
私は自分のアプリケーションにおける履歴の役割を検討しましたが、最初の印象では、履歴トークンを介してすべての制御フローを処理できるようです。制御フローはすべて、単一のインデックス値 (例: 123) の指定のみを含みます。したがって、これを「i_123」履歴トークンとして表すことができます。UI の複数のコンポーネントが新しい履歴トークンで起動し、UI の更新をトリガーします。私のレコード表示プレゼンターは、「i_」で始まる履歴イベントをリッスンし、一致するトークンからインデックスを抽出して更新します。
この戦略にペナルティはありますか? アプリで複雑なメッセージを渡す必要がある場合は、これらをイベントにラップすることをお勧めしますが、必要ではないようです。
この戦略について他に意見はありますか？
ユーザーがブラウザーの戻るボタンと進むボタンを使用して前後にナビゲートできるようにするために、すべての履歴を使用することをお勧めします。個々のレコード間を移動することは良い例のように思えます。3 つのレコードを探索させてから、それらを逆方向に移動させたいと思うかもしれません。
ただし、一部のイベントではこれで十分ではありません。いくつかのデータが変更されたとします。さまざまなディスプレイをすべて更新する必要がありますi_123。その時点で、RefreshEvent(作成したもの) のようなものをイベントバス経由で送信したい場合があります。
幸いなことに、履歴イベントをリッスンしているのとまったく同じイベントバスを使用して、後で追加することにしたイベントをリッスンすることができます! そのため、最初は、プログラム内通信の手段として履歴イベントをリッスンし、必要に応じてイベントを追加することをお勧めします*。ナビゲーションに関係のないものに履歴を使用しないようにしてください。
*PS: GWTActivityとPlaceクラスは、履歴とコードの間に柔軟性のレイヤーを提供するように構築されており、URL マッピング/解析の一元化などの大きな利点があります (したがって、必要なときにすべてのプレゼンターを変更する必要はありません)。 URL スキームを変更します) と自動的に「本当に退出しますか?」確認。実際に始める前に時間がある場合は、履歴イベントを直接聞くのではなく、最初からActivityandを使用することをお勧めします。Place