Mis ideas después de trabajar un año en un proyecto de GWT/Seam. Supongo que no existe un sitio web existente, lo que significa que puede comenzar desde cero. Si hay uno, le sugiero que respete su legado y lo mejore insertando selectivamente widgets GWT en lugares específicos de las páginas html existentes (algunos más detalles here).
Nuestro proceso de desarrollo más o menos se puede resumir en los siguientes pasos (bucles de retroalimentación, reuniones standup y como se omite, se sabe que el acuerdo): Solicitud
Característica: contiene la descripción de la funcionalidad deseada a una alto nivel
Wire Frames: una interfaz de usuario de alto nivel que da una primera impresión de cómo va a ser proporcionada al usuario final y la funcionalidad de la forma en que está integrado en la aplicación existente (sin ningún tipo de campanas y silbatos)
Diseño Final: la interfaz de usuario extendida final de la nueva entidad creada por nuestro diseñador (photoshop solamente, sin esqueleto html, css hay)
implementación y prueba: Voy a centrarse en la aplicación y describir cómo cambió durante un solo años
comenzamos nuestro proyecto con GWT 1.6, que carece de cualquier apoyo de UiBinder. Entonces la decisión fue 1) construir todo el lado del cliente de nuestra aplicación con GWT (es decir,, código de Java) o 2) construir nuestras páginas con JSF (ya que estamos usando Seam) y ampliarlas con widgets de GWT. Decidimos optar por la segunda opción principalmente porque nos gustaba la idea de llevar la mayor parte del estado a los clientes y dejarles que procesaran. Y hacer todo en Java fue prometedor con nuestros sólidos antecedentes en el desarrollo de Java.
La implementación de la lógica comercial no fue un problema en absoluto. Lo que más nos llevó tiempo fue construir la interfaz de usuario: componer el diseño de las páginas y diseñarlas en java es una tarea lenta y propensa a errores. La brecha entre el html final (basado en los diseños del paso 3) y los widgets GWT era demasiado grande.
Cambiar a UiBinder fue el primer paso que dimos cuando se lanzó GWT 2.0. Como tuvimos que volver a trabajar la mayor parte de nuestro código de cliente, también adaptamos el MVP pattern. La productividad aumentó significativamente después de eso: un desarrollador estaba implementando la lógica de negocios (principalmente la parte del presentador de MVP) mientras que otro estaba ocupado construyendo la parte de la vista (.ui.xml y el widget). Unit testing también se volvió más fácil debido a que la funcionalidad principal ahora estaba muy bien separada en la parte del presentador (y GWTTestCase era parte del pasado).
El siguiente paso importante que estamos haciendo actualmente es cambiar de nuestra propia implementación de MVP a una más elaborada (es decir, gwt-platform). Justificación de esta decisión: DI a través de GIN (las dependencias son claras y el código más limpio), buen soporte para el historial del navegador (lo descuidamos imprudentemente - ¡un gran error!), Soporte de división de códigos, patrón de comandos para llamadas asincrónicas y algunos más.
Mi conclusión después de un año de experiencia: use UiBinder para la parte UI y busque una arquitectura MVP limpia. La curva de aprendizaje puede ser abrupta, pero yendo por el mismo camino que muchos desarrolladores de GWT te llevan definitivamente más tiempo.
... mis 2 centavos :)
1, que es una pregunta muy buena programación, centrándose en el "cuadro más grande". También me gustaría recibir respuestas de personas que han hecho proyectos de GWT en este caso (a diferencia de los comentarios negativos que dicen * "esa pregunta no pertenece a SO" * de personas que no pueden responderla, comentarios y personas). quienes realmente pueden ir a/dev/null). – SyntaxT3rr0r
Webinator, gracias por su apoyo. Esperemos que obtengamos una buena respuesta. – Ramp