我正在規劃我的GWT應用程序。正如Ray Ryan在Google IO 09上所說的那樣：是否有使用GWT歷史代替EventBus的懲罰
「讓您的歷史記錄正確，並且早點把握好」。
我已經考慮了歷史在我的應用程序中的作用，並且在第一印象中，我似乎可以通過歷史記號處理所有控制流。控制流都只涉及單個索引值的指定（例如123）：所以我可以將其表示爲「i_123」歷史記號：UI中的多個組件會觸發新歷史記號 - 觸發UI更新。我的記錄顯示Presenter只會傾聽以「i_」開頭的歷史事件，然後從匹配令牌中提取索引並進行更新。
這個策略有沒有懲罰？如果我需要在應用程序周圍傳遞複雜的消息，我很欣賞我會將這些消息包裝到事件中，但似乎並不需要。
對此策略有何其他意見？
對於希望用戶能夠使用瀏覽器的後退和前進按鈕來回導航的所有內容，使用歷史記錄是個不錯的主意。在單個記錄之間移動似乎是一個很好的例子 - 您可能希望讓他們瀏覽三條記錄，然後向後移動。
雖然這對某些事件還不夠。說一些數據變化，並且你希望你所有的各種顯示器都能自我更新 - 即使你仍然在看i_123。此時，您可能希望通過事件總線發送類似RefreshEvent（您創建的）。
幸運的是，您可以使用您正在收聽歷史事件的完全相同的事件總線來收聽您決定稍後添加的事件！所以，當你開始時，我建議*傾聽歷史事件作爲內部節目溝通的手段，然後在你需要時添加更多事件。只要確保你沒有開始使用與導航無關的事物。
* PS：GWT的Activity和Place類在建造時，提供你的歷史和你的代碼之間的柔性層，並且有一個類似的集中URL映射一定大有益處/解析（所以你不必到處去改變每單個主持人，當你想改變網址方案）和自動「你真的想離開？」確認。如果您有足夠的時間才能開始使用，我建議從一開始就使用Activity和Place，而不是直接聽歷史事件。