GWT 事件处理最佳实践

Question

我有一个关于 GWT 客户端事件处理的问题。

在我们的应用程序中，我们有一个相当复杂的结构，由不同的模块和页面组成，它们通过客户端的 gwt eventbus 进行通信。我认为现在事件的数量增长得太快了。例如，我正在打开一个弹出窗口，我需要：

1. 用于打开弹出窗口的事件
2. 用于询问客户端内某些数据的事件
3. 用于获取数据并填写对话框的
4. 事件 用于关闭弹出窗口的
5. 事件 用于处理保存按钮

Am 的 事件我认为 EventBus 实现有点复杂或遗漏了一些东西？我只是想从社区获得一些反馈，因为您也面临着同样的问题。

Answer 1

就其价值而言，我有很多活动，也有更多的成长。是的，我想知道我是否可以少做一些事情，但是当我跳过一个事件并直接链接元素时，我会后悔。

这是我昨天刚刚修复的一个例子。我有一个 DataGrid 小部件。我还支持对列重新排序、隐藏列、重新调整列大小以及使用弹出对话框对列进行着色。您单击配置按钮，会显示一个列出列的弹出窗口，用户可以单击复选框来显示或隐藏列，单击上移/下移按钮来重新排序列，等等。在弹出窗口上点击“应用”，弹出窗口就会消失，并且 DataGrid 会重新配置。

但事实并非如此。您单击“应用”，弹出窗口就会放在那里，用户会想知道发生了什么，DataGrid 将在下面重新配置，然后弹出窗口就会消失。我们只聊了很短的时间——也许一秒钟或更长时间——但它是如此引人注目。为什么会发生这样的事？因为我很懒，将弹出窗口直接绑定到配置按钮，并将“应用”按钮直接绑定到 DataGrid。例如，您可以点击“应用”，然后将使用新的配置信息调用 DataGrid。只有当呼叫返回时，弹出窗口才会被拆除。

我知道这样做不好，但我很懒。因此，我花了 20 分钟在我的调解器单例中编写两条消息和关联的处理程序。一条消息由 DataGrid 发出以启动配置对话框，另一条消息由弹出窗口发出以配置 DataGrid。现在，小部件已解耦，性能更加快捷。没有“粘”感。

现在以你的例子来说，你能不能结合（1）和（2）？还有（3）、（4）和（5）？当用户单击我的应用程序上的配置按钮时，该事件会携带当前配置信息（包括对发起请求的 DataGrid 的引用）。您可以将此信息称为“有效负载”。当用户单击弹出窗口上的“应用”按钮时，事件负载包括事件处理程序在处理事件时将其提供给目标 DataGrid 的所有新配置信息（包括对原始目标 DataGrid 的引用）。两个事件——一个启动配置，一个应用最终结果。

是的，任何应用程序中都会有大量的事件来做一些有趣的事情，但事件可以携带大量信息，所以我会看看你的事件组织是否过于分散。

---

作为额外的一点，这是我使用的代码。我无耻地从谷歌的一个例子中复制了这种模式的元素。

用户可以使用菜单项寻求帮助：

@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);
  }

}

我有一个名为 Mediator 的单例，其中注册了所有事件：

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

每个事件都配对使用 Command 对象来完成工作：

public class MenuHelp implements Command {

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

    }

一切都是解耦的。菜单小部件绑定到执行然后完成的命令。该命令在总线上触发事件然后完成。该事件触发命令的执行并完成。该命令显示弹出帮助面板（在本例中，向用户显示“未实现”消息——是的，我很快就会看到它）。与用户输入的每次交互都会非常快速地处理和解决。它可以启动一系列事件来执行较长的操作，但不会占用 GUI 来执行此操作。当然，由于元素是解耦的，我可以在其他地方调用相同的元素（例如，通过按钮按下以及菜单项调用帮助命令）。