gwt - 最佳实践 GWT 事件处理

Question

我对 GWT 中客户端的事件处理有疑问。

在我们的应用程序中，我们有一个由不同模块和页面组成的非常复杂的结构，它们通过客户端的 gwt 事件总线进行通信。现在，在我看来，事件的数量正在快速增长。例如。我正在打开一个我需要的弹出窗口:

打开弹窗的事件

在客户端内询问一些数据的事件

获取数据并填写对话框的事件

关闭弹窗的事件

处理保存按钮的事件

我是否在考虑 EventBus 实现中的一些复杂或遗漏的东西？当您面临同样的问题时，我只是想从社区中获得一些反馈。

Answer 1

对于它的值(value)，我有很多事件和更多的成长。是的，我想知道我是否可以用更少的东西做，但是当我跳过一个事件并直接链接元素时，我会后悔的。

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

除了它没有。您单击应用，弹出窗口就会坐在那里，用户会想知道发生了什么，DataGrid 会在下面重新配置，然后弹出窗口就会消失。我们只谈了很短的时间——也许一秒钟或更多一点——但它是如此引人注目。为什么会这样？因为我比较懒，直接将弹出窗口绑定(bind)到配置按钮，将应用按钮直接绑定(bind)到 DataGrid。例如，您点击 Apply，就会使用新的配置信息调用 DataGrid。只有当调用返回时，弹出窗 Eloquent 会被拆除。

当我这样做时，我知道这很糟糕，但我很懒惰。所以我花了 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());
      }

    }

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