GWT con varias páginas de host en una aplicación heredada

Question

Estoy considerando utilizar GWT como front-end de una aplicación web existente.

No puedo justificar una reescritura completa al 100% GWT de una vez. Es probable que migre gradualmente partes del sistema a GWT. Sin embargo, por coherencia, me gustaría utilizar GWT TabPanel, MenuBar, etc. como elementos de interfaz global desde el primer día.

Como un experimento para ver cómo se podrían incorporar partes 'heredadas' del sistema, he hecho lo siguiente.

La plantilla de la página principal de la aplicación ahora carga un pequeño módulo GWT 'envoltorio' en cada página. Este módulo GWT busca una selección de DIV en la página de host generada dinámicamente. Si se encuentra el DIV, se coloca un widget adecuado en su lugar, es decir, barra de menú, tabPanel.

Gran parte de la configuración de los widgets incluidos también se puede colocar en la página de host como estructuras JSON. Por ejemplo, he implementado un adaptador que configura dinámicamente un TabPanel de esta manera. También he agregado algunos widgets muy simples que cargan HTML remoto, etc.

Como prototipo, todo esto parece funcionar perfectamente y se carga rápidamente. Sin embargo, parece que las aplicaciones GWT están realmente diseñadas para ejecutarse desde una sola página de host, no cientos de generadas dinámicamente.

¿Alguien puede resaltar cualquier problema que pueda surgir con el enfoque anterior, particularmente cuando el módulo GWT aumenta de tamaño? Me gustaría mantener el módulo de contenedor heredado intencionadamente delgado. Otra funcionalidad se implementaría en módulos separados.

¿Cómo han integrado otras personas GWT en su interfaz de forma gradual?

Answer 1

Una de las formas en que GWT fue diseñado para ser utilizado es exactamente como lo usaste. Lo hemos hecho en muchas de nuestras aplicaciones, donde hay un módulo GWT con múltiples 'partes' que se cargan en función de si existe un identificador determinado en una página o no. Entonces no veo que tengas ningún problema yendo por aquí. A menudo usamos este enfoque incluso para nuevas aplicaciones web, donde solo queremos algunos "widgets" en la página, en lugar de codificar toda la aplicación en GWT.

No hará una gran diferencia, pero una cosa que sugeriría es no poner el código de GWT javascript en su plantilla principal, sino solo ponerlo en las páginas que lo necesitan. Es cierto que si no está ejecutando HTTP, se almacena en caché básicamente para siempre, pero parece incorrecto que la gente cargue en el módulo si no es realmente necesario en esa página. Esto, por supuesto, depende de cómo la gente usa su sitio, si es probable que lo descarguen de todos modos, entonces no hará ninguna diferencia.

Answer 2

Lo estás haciendo bien. Evite evitar evitar la tentación de tratar de 'minimizar' la huella de GWT dividiéndola en múltiples aplicaciones separadas.

La clave del rendimiento de GWT es tener la menor cantidad de descargas posible y asegurarse de que estén en caché. Cargar un paquete de 250k una vez es mucho mejor que dos paquetes de 200k y debido a que la compresión es mejor con archivos más grandes, realmente comienza a cosechar beneficios a medida que crecen las cosas.

y-slow & firebug puede ser realmente útil a la hora de convencerse de esto.

Un truco rendimiento debes revisar está disponible en el capítulo de muestra aquí: http://www.infoq.com/articles/progwt Se muestra un mini-arquitectura en torno carga widgets de GWT en cualquier número de ranuras y los datos rellenando previamente en variables JavaScript. Esto permite que sus widgets GWT se carguen y no requiera un segundo HTTP GET para obtener los datos que usan. En la práctica, descubrí que este fue un buen impulso en el rendimiento.