最佳實踐GWT事件處理

Question

我有一個關於GWT中客戶端事件處理的問題。

在我們的應用程序中，我們有一個相當複雜的不同模塊和頁面結構，它們通過客戶端的gwt事件總線進行通信。現在，我認爲事件的數量正在快速增長。例如。我打開一個彈出我需要：

1. 打開彈出
2. 事件詢問客戶
3. 爲取回數據並填寫對話框
4. 事件中的一些數據的事件關閉彈出
5. 事件處理保存按鈕

事件我在想一點點複雜，或失去了一些東西EventBus實現？當你面臨同樣的問題時，我只想從社區中獲得一些反饋。

Answer 1

對於它的價值，我有很多事件和更多的成長。是的，我想知道我是否可以少做，但是當我跳過一個事件並直接鏈接元素時，我感到後悔。

這是我昨天剛剛修好的一個例子。我有一個DataGrid小部件。我還支持對列進行重新排序，隱藏列，重新調整列大小以及使用彈出對話框着色列。你點擊一個配置按鈕和一個列出了列的彈出窗口，用戶可以點擊複選框來顯示或隱藏列，點擊上移/下移按鈕重新排列列，等等。在彈出窗口中點擊應用，彈出消失，並重新配置DataGrid。

除了它沒有。你點擊Apply，彈出窗口就會坐在那裏，用戶會想知道發生了什麼，DataGrid會在下面重新配置，然後彈出窗口就會消失。我們只談了很短的時間 - 可能是一秒鐘或更長時間 - 但它是如此明顯。爲什麼發生？因爲我很懶，並直接將彈出窗口綁定到配置按鈕，並將Apply按鈕直接綁定到DataGrid。例如，您將點擊Apply，然後使用新的配置信息對DataGrid進行調用。只有當調用返回時，彈出窗口才會被拆除。

我知道這樣做很糟糕，但是我很懶。所以我花了我需要的20分鐘在我的中介單例中寫出兩條消息和相關的處理程序。 DataGrid發出一條消息來啓動配置對話框，另一條消息由彈出窗口發出以配置DataGrid。現在這些小部件被拆分，性能更加快捷。沒有「粘性」的感覺。

現在來看你的例子，你不能結合（1）和（2）嗎？還有（3），（4）和（5）？當用戶單擊我的應用程序上的配置按鈕時，該事件攜帶當前配置信息（包括對發起請求的DataGrid的引用）。您可以將此信息稱爲「有效載荷」。當用戶單擊彈出窗口上的應用按鈕時，事件有效內容包括處理事件時事件處理程序提供給目標DataGrid的所有新配置信息（包括對原始目標DataGrid的引用）。兩個事件 - 一個啓動配置，一個應用最終結果。

是的，任何應用程序中都有很多事件可以做一些有趣的事情，但事件可以傳遞大量信息，所以我會考慮事件組織是否太破碎。

---

作爲一個額外的位，這裏是我使用的代碼。我從Google的一個例子中無恥地複製了這種模式的元素。

用戶可以使用菜單項尋求幫助：

@UiField 
MenuItem help; 

help.setCommand(new Command() { 
     @Override 
     public void execute() { 
     BagOfState.getInstance().getCommonEventBus().fireEvent(new MenuHelpEvent()); 
     } 
    }); 

對於事件（在這種情況下，事件當用戶點擊幫助菜單項激活）：

public class MenuHelpEvent extends GwtEvent<MenuHelpEvent.Handler> { 

    private static final Type<Handler> TYPE = new Type<Handler>(); 

    public interface Handler extends EventHandler { 
    void doMenuHelp(); 
    } 

    @Override 
    public GwtEvent.Type<Handler> getAssociatedType() { 
    return TYPE; 
    } 

    @Override 
    protected void dispatch(Handler handler) { 
    handler.doMenuHelp(); 
    } 

    public static HandlerRegistration register(EventBus eventBus, Handler handler) { 
    return eventBus.addHandler(TYPE, handler); 
    } 

} 

我有一個叫做中保單中的所有事件都記錄：

MenuHelpEvent.register(BagOfState.getInstance().getCommonEventBus(), 
    new MenuHelpEvent.Handler() { 
     @Override 
     public void doMenuHelp() { 
     new MenuHelp().execute(); 
     } 
    }); 

每一個事件配合與C ommand對象做的工作：

public class MenuHelp implements Command { 

     @Override 
     public void execute() { 
     new InfoMessage(BagOfState.APP_MSG.unimplementedFeatureCaption()) 
      .setTextAndCenter(BagOfState.APP_MSG.unimplementedFeature()); 
     } 

    } 

一切都是分離的。菜單小部件綁定到一個執行並完成的命令。該命令在總線上觸發事件，然後完成。事件觸發了命令和完成的執行。命令顯示彈出式幫助面板（在這種情況下，向用戶提供「未實現」消息 - 是的，我很快就會看到）。每個與用戶輸入的交互處理都非常快速並得到解決。它可以啓動一系列事件來執行長時間的操作，但從不捆綁GUI來執行此操作。當然，由於元素是分開的，我可以在其他地方調用相同的元素（例如，通過按鈕以及菜單項調用幫助命令）。