Best Practices Gestión de eventos GWT

Question

Tengo una pregunta sobre el manejo de eventos en el lado del cliente en GWT.

En nuestra aplicación, tenemos una estructura bastante compleja de diferentes módulos y páginas que se comunican a través del bus de eventos gwt en el lado del cliente. Ahora la cantidad de eventos aumenta para mi opinión. P.ej. Estoy abriendo una ventana emergente que necesito:

1. Un evento para abrir la ventana emergente
2. Un evento para pedir algunos datos dentro del cliente
3. Un evento para volver a los datos y rellenar el cuadro de diálogo
4. un evento para cerrar la ventana emergente
5. un evento para manejar el botón guardar

estoy pensando un poco complicado o que falta algo en el Implementación de EventBus? Solo quería recibir algunos comentarios de la comunidad ya que enfrenta los mismos problemas.

Answer 1

Por lo que vale, tengo muchos eventos y más crecimiento. Y sí, me pregunto si puedo hacer con menos, pero cuando omito un evento y enlace elementos directamente, lo lamento.

Aquí hay un ejemplo que acabo de arreglar ayer. Tengo un widget DataGrid. También apoyo el reordenamiento de columnas, el ocultamiento de columnas, el redimensionamiento de columnas y el coloreado de columnas con un diálogo emergente. Hace clic en un botón de configuración y aparece una ventana emergente con las columnas enumeradas, y el usuario puede hacer clic en casillas de verificación para mostrar u ocultar columnas, hacer clic en un botón Subir/Bajar para ordenar columnas, y así sucesivamente. Presione Aplicar en la ventana emergente y la ventana emergente desaparecerá y DataGrid se reconfigurará.

Excepto que no fue así. Hacía clic en Aplicar y la ventana emergente se quedaba allí, el usuario se preguntaba qué estaba pasando, la DataGrid se reconfiguraba debajo y luego la ventana emergente desaparecía. Estamos hablando de un corto período de tiempo, tal vez un segundo o un poco más, pero fue tan notable. ¿Por qué estaba pasando? Porque me puse vago y até la ventana emergente directamente al botón de configuración, y el botón Aplicar directamente al DataGrid. Pulsarías Aplicar, por ejemplo, y la llamada se haría a DataGrid con la nueva información de configuración. Solo cuando la llamada regresara, la ventana emergente sería derribada.

Sabía que era malo cuando lo hacía, pero estaba siendo flojo. Así que tomé los 20 minutos que necesité para escribir dos mensajes y manejadores asociados en mi singleton de mediador. Un mensaje es emitido por el DataGrid para iniciar el cuadro de diálogo de configuración, y el emergente emite uno para configurar el DataGrid. Ahora los widgets están desacoplados y el rendimiento es mucho más ágil. No hay sentido de "pegajosidad".

Ahora, en su ejemplo, ¿no puede combinar (1) y (2)? Y también (3), (4) y (5)? Cuando el usuario hace clic en el botón de configuración en mi aplicación, el evento lleva consigo la información de configuración actual (incluida una referencia al DataGrid que originó la solicitud). Puede llamar a esta información la "carga útil". Cuando el usuario hace clic en el botón Aplicar en la ventana emergente, la carga del evento incluye toda la nueva información de configuración (incluida una referencia a ese DataGrid de destino original) que el controlador de eventos alimenta al DataGrid de destino cuando se maneja el evento. Dos eventos: uno para iniciar la configuración y otro para aplicar el resultado final.

Sí, hay una gran cantidad de eventos en cualquier aplicación que hace algo interesante, pero los eventos pueden llevar mucha información, por lo que vería si su organización de eventos está demasiado fracturada.

---

Como un bit adicional, aquí está el código que uso. Copié desvergonzadamente elementos de este patrón de uno de los ejemplos de Google.

El usuario puede pedir ayuda usando un elemento de menú:

@UiField 
MenuItem help; 

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

Para el evento (en este caso, el evento disparado cuando el usuario hace clic en el elemento de menú Ayuda):

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

} 

tengo un producto único llamado mediador en la que se registran todos los eventos:

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

Cada evento está acoplado con un C objeto ommand para hacer el trabajo:

public class MenuHelp implements Command { 

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

    } 

Todo está desacoplado. El widget de menú está vinculado a un comando que se ejecuta y luego completa. El comando dispara el evento en el bus y luego se completa. El evento dispara la ejecución de un Comando y lo completa. El comando muestra el panel de ayuda emergente (en este caso, un mensaje de "no implementado" para el usuario, sí, lo haré pronto). Cada interacción con la entrada de un usuario se maneja extremadamente rápido y se resuelve. Puede iniciar una serie de eventos para realizar una acción prolongada, pero sin bloquear la GUI para hacerlo. Y, por supuesto, dado que los elementos están desacoplados, puedo llamar a los mismos elementos en otros lugares (por ejemplo, llamar al comando de ayuda mediante un botón pulsador y un elemento de menú).