que - Vaadin 7: Uso de UI vs. Navegador+Vistas

vaadin java que es

Question

En Vaadin 7, una aplicación web puede tener múltiples puntos de entrada; las interfaces de usuario. Cada UI solo puede tener un único Navigator contenga View .

Estamos trabajando en una aplicación que requiere navegación en varios niveles, y para algunas pantallas no sabemos si deberíamos tener una única UI con un navegador o varias UI con un componente de menú compartido.

¿Cuáles son las ventajas e inconvenientes de la interfaz de usuario y el navegador? ¿Hay alguna guía sobre esta elección?

Answer 1

Recomiendo usar una interfaz de usuario con Navigator ya que en mi opinión es suficiente para hacer el trabajo. La principal falta de conocimiento de muchas interfaces de usuario se vuelve a cargar al cambiar entre ellas. También deberías recordar acerca de la consistencia deseada, por ejemplo. tener el mismo encabezado en cada interfaz de usuario. Y desde mi experiencia, seguramente encontraría más problemas ;-)

Para hacerlo limpio debes usar el patrón MVP . Yo uso similar a este con com.google.common.eventbus.EventBus para manejar eventos. Agrego eventBus a mis puntos de vista, publico eventos allí y los manejo en el presentador adecuado, sin implementar escuchas a la vista, lo que en mi opinión es más problemático. Como MVP ya reserva ''presentador'' y ''vista'', llamo a la página de vista de Vaadin ''.

Puede crear el encabezado, el menú principal del pie de página y luego el contenedor de contenido (por ejemplo, algún diseño) para conectar el navegador con:

Navigator n = new Navigator(UI.getCurrent(), layout);

Para administrar la navegación, creé PagesEnum y al cambiar la vista publico ChangePageEvent que obtiene PageEnum.SOME_PAGE como parámetro. Opcionalmente también hay una identificación del artículo para mostrar. Así que en MainPresenter tengo:

@Subscribe
public void changePage(ChangePageEvent event) {
    String url = event.getPageName();
    if (event.hasId()) {
        url += "/" + event.getEntityId();
    }
    navigator.navigateTo(url);
}

Luego hay diferentes posibilidades:

• al ingresar al método de la página (vista Vaadin), asegúrese de que se muestre el submenú apropiado.

• agréguelo como parámetro a ChangePageEvent y adminístrelo en el método changePage.

• Hardcode it en PageEnum como nuevo campo, por ejemplo. subMenu y cree otra enumeración para submenús, colóquela en el método changePage.

El submenú probablemente estará fuera del contenedor con el que conectó el navegador, por lo que allí puede crear SubMenuPresenter y SubMenuView para manejar el cambio de submenú.

Answer 2

el tema de su pregunta me hizo sudar mucho en el pasado 2013. Estudié, analicé y probé varios aspectos de las interfaces de usuario y navegador Vaadin 7.

Miré un gran número de framework, wiki y papel sobre el tema; Relacionados y no relacionados con Vaadin 7.

Fue hace algún tiempo (a principios de 2013), no estoy fresco en el tema; De todos modos, estos son algunos de los enlaces que puedo resucitar:

• Vaadin MVP Lite para Vaadin 6
• MVP4Vaadin - Principio básico
• Vistas de cambio de contenido
• Problema del navegador Vaadin 7: foro Vaadin
• Navegación secundaria - foro de Vaadin

Nuestros requisitos eran algo similares al escenario de Vaadin MVP Lite; pero necesitábamos más abstracción y flexibilidad en la composición de las vistas. Intenté usar el navegador provisto, pero no era fácil de personalizar.

El navegador es una clase concreta. Las interfaces de usuario solo pueden tener un navegador. En el constructor Navigator puedes encontrar esta línea:

this.ui.setNavigator(this);

El navegador hace un gran trabajo para la mayoría de las aplicaciones con necesidades simples y proporciona una funcionalidad agradable fuera de la caja, pero en realidad no está diseñado para extensión o personalización. Otro aspecto a tener en cuenta es que al cambiar la vista con Navigator, cambia todos los componentes en la pantalla; No puedes cambiar pequeños bits.

Luego encontré esta guía que me puso en un camino interesante: Componer la interfaz de usuario, Capítulo 7 - MSDN Microsoft

El artículo es realmente bonito e iluminador; aunque tiene muchos puntos en común con la forma en que Delphi o cualquier otro marco de trabajo basado en componentes, el concepto de "Región" fue realmente una bendición. Los otros capítulos también son muy interesantes (desarrollo de aplicaciones modulares y MVVP).

Al final, adoptamos el concepto de Región con una sola UI. Brevemente funciona así:

• Hay un componente GUI que puede alojar otros componentes; Los lugares donde puede alojar otros componentes son como ''agujeros''. Cada hoyo está registrado y es una región vinculada a un nombre de cadena (hasmap simple)
• A través del nombre de la Región, uno puede ''poner'' otro componente Vaadin en una Región para hacerlo visible.

Lo que sucede cuando se ingresa la interfaz de usuario es que una Región está registrada (la interfaz de usuario completa) como la Región "raíz". Luego, un componente que representa el formulario de inicio de sesión se hospeda en la región ''raíz''. Si se realiza un intento de inicio de sesión exitoso, entonces se aloja otro componente en la región ''raíz'' (eliminando el componente de inicio de sesión); este mismo componente es un host también: registra otra Región llamada ''principal'' y también tiene un menú de navegación del lado izquierdo. Ahora, si uno quiere mostrar un componente (la página de bienvenida, por ejemplo) puede recuperar la Región ''principal'' y poner el componente en pantalla.

Vaadin Navigator implementa marcadores y soporte de botón de retroceso. Estaba triste porque no lo desarrollamos, pero no era un requisito para nuestra aplicación. En mi humilde opinión, los muchachos de Vaadin tomaron una decisión difícil pero buena manteniendo simple a Navigator; La gestión estatal no se implementa fácilmente. Sería bueno para el futuro tener un navegador más extensible. De todos modos creo que el navegador actual responde a la mayoría de las necesidades promedio.

Mi respuesta es más larga de lo previsto; Espero que mi esfuerzo pueda ayudar.