java - tutorial - vaadin starters




Debo usar Vaadin Framework (13)

Intenté jugar con Vaadin Framework y me parece muy fácil de usar. Además, lo que me gusta de su marco es que está construido sobre Google Web Toolkit (GWT) .

¿Qué piensas, debería continuar usando este marco o es mejor seguir con GWT?


Después de casi 1.5 años desarrollando una aplicación GWT no tan grande, usando todas las mejores prácticas que aprendí de la última Google I / O como MVP, EventBus, CommandPattern, etc. Digo esto desde el fondo de mi corazón: después de pasar días intentando Para que las cosas funcionen como mi equipo y cliente querían tanto técnica como visualmente, incluso después del lanzamiento de UiBinder, Vaadin vino a mí como una luz al final del túnel.

Después de escribir casi mil acciones repetitivas para el patrón de comando, otros mil presentadores y vistas y otros mil manejadores de eventos, etc. No tener que lidiar con casi el 75% de estas clases y mantener un buen enfoque de patrones (add-on de aplicación), una pequeña sobrecarga de red es aceptable. Con Vaadin, listo para usar, obtienes buenos widgets, paginación, enlace de datos, diseño impecable. ¿Todo esto por qué? Un poco más de consumo de memoria en el lado del servidor.

Creo que puedo decir que esto es aceptable porque no estoy construyendo el próximo Facebook o algo así. Todavía puedo manejar miles de usuarios simultáneos por servidor mediano y, sin embargo, mantener viajes de ida y vuelta de baja latencia.

Con Vaadin, puedo construir una buena aplicación con casi la mitad de líneas de código y aún la aplicación parece más completa. :-)

!! ACTUALIZACIÓN 23 de febrero de 2011: No puedo estresar cómo uno debe conocer las limitaciones de cada marco. Vaadin no es diferente. Uno debe saber que Vaadin abstrae cualquier forma de HTML o JavaScript. Además, el HTML resultante es muy pesado y usted debe encargarse usted mismo del cambio de estado del historial. Por lo tanto, tenga en cuenta esos gastos generales cuando construya su proyecto.


Empecé con Vaadin hace solo dos días y pude construir una pequeña aplicación CRUD en OSGi completa con modularidad, enlace de datos, servicios OSGi para persistencia. Una cosa realmente agradable es que mi UI completa solo tiene 118 líneas de código y admite operaciones CRUD completas para una estructura simple de Java Bean.

También es bueno que Vaadin funcione perfectamente en OSGi. Ya es un paquete y encontré un pequeño puente de Neil Bartlet que hace que vaadin sea extremadamente fácil de usar en OSGi.

Ver Ejemplo de Vaadin de la lista de tareas


Estoy usando Vaadin también. Aunque la aplicación no es grande, lo que realmente me gustó de la experiencia fue que la API fue consistente, generalmente bien documentada y dado que estaba desarrollando una nueva herramienta, pude generar cosas para un cliente muy exigente de la misma manera, o en algunos casos, mejores tiempos que las herramientas que utilicé antes.

Muy pocos problemas. El único en este momento es que el cliente insiste en usar IE 7 (no preguntes) y algunos de los caramelos más elegantes no funcionan totalmente al 100% en un componente de complemento (gráficos).

Por cierto, tampoco trabajo para Vaadin :-)


He intentado con Wicket y Vaadin, y si realmente prueban ambas durante algún tiempo, con un mes sabrán que Vaadin es el camino a seguir y no Wicket, punto. - Dheeraj G


Hemos analizado Wicket, donde trabajo, pero encontramos en lugar de 9,000 archivos, podríamos tener más de 30,000. Tenemos casi 1.000 pantallas con nuestra aplicación principal de servicios financieros y, aunque Wicket se ve muy bien, es extremadamente difícil convertir nuestro código Struts 1.3 en Wicket. Nuestro arquitecto hizo un proyecto POC y solo 3 pantallas agregaron varios cientos de clases (muchas son para reutilización). También es difícil protoear una pantalla con Wicket ya que su html debe coincidir con el código de Java y viceversa.

Vaadin parece prometedor, pero será una venta difícil para el equipo.

PD No importa cuán grande sea el marco, nadie lo aprenderá si no se usa en la industria. Wicket ha existido por un tiempo, sin embargo, muy pocas compañías lo usan. La mayoría de los desarrolladores con los que hablo están preocupados por aprender un nuevo marco que es inútil en un currículum.

La clave es que Vaadin usa un diseño tipo Swing y es útil que comencé en Java usando Swing.


La conversación habitual sobre Vaadin tiene que ver con el conjunto de widgets y las preocupaciones sobre la comunicación de ida y vuelta entre el cliente y el servidor.

Pero en mi opinión esto pasa por alto el aspecto más importante (quizás revolucionario) de Vaadin: elimina por completo la tarea de diseñar e implementar la comunicación cliente-servidor que generalmente se requiere para las aplicaciones AJAX (la "A" y la "X" en AJAX) .

Con Vaadin, puede olvidar por completo los DTO (objetos de transferencia de datos), los problemas de seguridad basados ​​en protocolos, las excepciones de carga diferida de Hibernate, etc.

En cierto sentido, solo está escribiendo una aplicación de escritorio antigua Java Swing, solo que está usando un juego de herramientas de interfaz de usuario diferente de Swing.


Lo que pasa es que, para un desarrollo serio, no puedes olvidarte de nada, mucho menos de dtos ... estoy abandonando la costura, y el concepto de ui del lado del servidor solo porque deseo un control más fino sobre lo que está pasando ... el problema de vaadin para mí es precisamente eso, teniendo estado en el lado del servidor ...


No me importa usar estados en el lado del servidor. Sirve su propósito. Con el cómputo en la nube, el almacenamiento y el ancho de banda actuales se están volviendo baratos. Pero sí, puedo ver su punto de vista desde una buena perspectiva de diseño, especialmente si desea RESTIFICAR su aplicación. Pero creo que hay más pros que contras con respecto a Vaadin y similares. Una cosa importante es que no tienes que ajustar mucho tus aplicaciones web para un navegador específico, vamos a llamarlo IE, para complejidades de Javascript / CSS, especialmente si estás orientado hacia el back-end como yo. Todos sus webapps se vuelven compatibles en el navegador sin tener que preocuparse de nada. Recuerde que el tiempo del desarrollador es más costoso que el de almacenamiento y ancho de banda. Esa es mi opinión. =)


Para construir UI de buen aspecto, diría que este sería el camino a seguir. Además, está muy bien documentado.


Pensé que Wicket era el camino a seguir, hasta que traté de hacerlo funcionar de manera eficiente y comencé una depresión (broma). Luego, cambié a GWT, que se veía genial, pero hay tanto código de placa de caldera para escribir y la documentación no es tan buena ... -> La luz vino de Vaadin: simple, operacional, no hay errores hasta el momento ... !!!



Descargo de responsabilidad : no estoy afiliado a ninguna de las bibliotecas mencionadas a continuación, pero sé que las conozco bastante bien.

Al igual que usted, me encontré con esta publicación al considerar qué pila / marco utilizar para un nuevo proyecto. ¡Tuve una sólida experiencia con Play! (bueno, en Scala, pero eso no es relevante aquí), pero los widgets atractivos y su perfecta integración con el servidor + el desarrollo de Swing like despertaron mi interés. Eso fue a finales de 2010, y como las respuestas me convencieron para probar a Vaadin, decidí regresar y escribir la respuesta que me hubiera gustado leer aquí, especialmente. ya que la pregunta todavía es relevante hoy. Mientras tanto, Vaadin pasó de la versión 6 a la 7 con algunas mejoras notables que se necesitaban, Play! pasó de la versión 1 a la 2 y yo (+ un pequeño equipo) completé una pequeña cantidad de proyectos exitosos con ambos marcos.

Creo que la comparación es interesante porque ambos marcos

  1. ejecutar en la JVM y puede aprovechar su abundante ecosistema
  2. no podría estar más en desacuerdo con su enfoque de las aplicaciones web y lo que a usted, como desarrollador, debería interesarle, y
  3. en menor medida, cómo se relacionan con Java EE.

Alabanza

En una frase, si encuentra convincente la idea de portar una aplicación de escritorio a un navegador mientras se abstrae por completo del mecanismo subyacente de solicitud / respuesta HTTP, entonces es probable que Vaadin sea su candidato para hacer una aplicación web. Su enfoque de programación de Swing puede ser muy fácil para aquellos que están más alejados de la baja calidad de HTML y JavaScript. Una nueva solicitud para su aplicación está comenzando una nueva instancia y el resto del flujo depende de usted y su lógica. Los enlaces vuelven a los viejos y buenos botones de navegación y puedes componer tus diseños usando las muchas plantillas integradas sin tener que modificar el HTML o el CSS. La API generalmente es bastante consistente y está bien documentada (el Libro de Vaadin es una lectura obligatoria. Hazlo a fondo, ya que hay muchas cosas disponibles, por ejemplo, unir los frijoles a componentes y validadores, ...). Los widgets tienen una buena compatibilidad general entre navegadores, lo que garantiza un comportamiento uniforme de su aplicación en una amplia gama de clientes.

Verificación de realidad

Nos lo pasamos muy bien desarrollando y probando nuestras aplicaciones Vaadin. Las cosas se volvieron más claras y más matizadas cuando lanzamos la primera versión y comenzamos a recopilar comentarios. Nos dimos cuenta de que en realidad habíamos sido parciales en algunos aspectos fundamentales , a saber:

  1. En 201x, la mayoría de los usuarios han tenido un largo historial de uso de la web, y pocos de ellos apenas usan aplicaciones de escritorio. El punto clave aquí es que los navegadores estandarizaron la interacción UX con enlaces de hipertexto, un botón de retroceso, avance y recarga, pestañas ubicuas y, a veces, ventanas, y la idea básica de que la mayoría de las acciones activan una solicitud HTTP y esperan una respuesta . Este es el contrato implícito que los sitios web respetan y en torno al cual están construidos. Por lo tanto, no deberíamos habernos sorprendido cuando los usuarios se quejaron de que no podían usar los botones retroceder / avanzar como solían hacerlo, o que las pestañas no funcionaban de la manera esperada. Y estuvimos de acuerdo. Rompimos el contrato invisible vinculando usuarios y navegadores. De hecho, nosotros mismos implícitamente no usamos nuestro navegador con la aplicación Vaadin de la misma forma que lo usamos con cualquier otro sitio web. Por supuesto, puede volver al libro mencionado anteriormente y leer detenidamente al replicar una experiencia de navegación web con fragmentos de URL y verá que en realidad está más involucrado de lo anticipado porque las aplicaciones de Vaadin son estables . Además, los paradigmas MVC o MVP solo se imponen de forma imprecisa al desarrollador, en contraste con Play! donde prácticamente no hay otra opción. No tome esto a la ligera, pero su cerebro se utiliza para la pantalla en blanco brillante que se muestra durante una fracción de segundo después de un cambio de página. Cuando los usuarios hacen clic y esperan que se les tome una nueva página, el navegador confirma mostrando el reloj de arena (o sus variaciones). Con AJAX, las solicitudes se colocan detrás de escena. Hoy hay lugares donde las pequeñas y casi quirúrgicas huelgas de AJAX se han convertido en la norma, pero no para las principales actualizaciones de UI todavía.

  2. Las aplicaciones con estado traen su parte de desafíos ... y problemas. El equilibrio de carga (si está preocupado) para uno es más complicado. El concepto de transacción es completamente diferente ya que las sesiones de Vaadin abarcan muchas solicitudes y, por lo tanto, son largas en contraste con el enfoque basado en REST, pero relativamente de corta duración en términos de UX. De hecho, no es raro que los usuarios vuelvan a un formulario que comenzaron hace horas para finalizar su tarea. Esto podría, en teoría, trabajar con Vaadin también, pero tendrías que mantener las sesiones con vida durante mucho, mucho tiempo, con la memoria bloqueada todo el tiempo y pensar cuidadosamente que esto escalaría a los usuarios concurrentes.

    Las páginas de estado también son más difíciles de compartir para los usuarios, y mucho menos de marcadores (eso suponiendo que haya tratado con fragmentos de URL).

  3. Finalmente, compartimos la impresión de que la IU generalmente es más lenta con la lógica del servidor. Por supuesto, siempre puede crear un widget cargado con JavaScript del lado del cliente para reducir el número de viajes de ida y vuelta, pero inevitablemente tendrá que realizar algunas actualizaciones de UI en el servidor. El JS ya es bastante pesado para interpretar en mi experiencia y ofrece una menor experiencia en dispositivos móviles (conozco TouchKit, pero aún así: las aplicaciones HTML5 en dispositivos móviles simplemente no me sirven). Además, tenga en cuenta que el hilo de UI está activo después de que se publique una solicitud (es decir, acción del usuario en el lado del cliente, similar a tirar de las actualizaciones de UI) y será accesible para usted a través de varios oyentes. Sin embargo, la actualización de la interfaz de usuario de los hilos de fondo es más complicada (por ejemplo, empujar las actualizaciones). Sin embargo, Vaadin 7 mejoró la situación en este aspecto, especialmente con HTML relativamente más ligero generado. Se detectaron mejoras significativas en la reactividad de la interfaz de usuario simplemente al activar la compresión HTTP.

Conclusión

Así que hicimos una pausa y nos preguntamos qué nos pareció tan atractivo en el enfoque de Vaadin para empezar. El desarrollo inicial había sido una marcha relativamente suave, produciendo resultados rápidos pero la reelaboración de algunos conceptos para acomodar las expectativas de UX web nos dio una fuerte impresión de nadar contracorriente. Llegamos a la conclusión de que la seductora idea de ser abstraído (¿oscurecido?) Del mecanismo de solicitud / respuesta HTTP demostró ser un arma de doble filo que reveló el desajuste de impedancia real entre las aplicaciones web y las aplicaciones de escritorio.

En lugar de pretender que la web es otra capa, sentimos fuertemente que uno debería adoptar la forma en que funciona y esto comienza con una aplicación centrada en la URL (como lo imponen Rails / Django / Play). Probablemente hayas escuchado a alguien decir que los datos sobreviven a la aplicación. Hoy en día, los recursos de las URL hacen referencia a los datos, por lo que se podría decir con seguridad que las URL sobreviven a los datos. Después de todo, son lo que la gente marca, ¿verdad? Por lo tanto, la separación básica de las preocupaciones también debería aplicarse a este nivel. Esta es probablemente la razón por la cual la web se hizo tan popular en primer lugar. Así que revisamos nuestra aplicación para estructurarla más en torno a un controlador central que responde a las acciones a la jugada realizadas en distintas rutas de recursos.

Por ahora, mantenemos nuestras aplicaciones Vaadin, pero debido a algunas de estas limitaciones y al cambio de paradigma fundamental, no iniciaremos nuevos proyectos con él. Sin embargo, diríjase al equipo que construyó un framework web Java de 360 ​​° técnicamente coherente, bien documentado y que requiere muy poco conocimiento del funcionamiento interno de la web. Por el lado positivo, incluso respaldan su marco con una empresa que vende servicios de consultoría. Estoy agradecido por la experiencia y por cómo me hizo volver a evaluar mis puntos de vista sobre las aplicaciones web. Seguiré de cerca su evolución, pero definitivamente necesitamos más control y granularidad.

Esperemos que algún día Vaadin se libere de toda la arquitectura de Servlet de la que depende para tener su propio servidor HTTP. Mejor aún sería un diseño MVC más profundamente enraizado en el marco. Pero eso es algo poco probable en un futuro previsible, ya que parece haber encontrado un nicho lucrativo entre los gorilas experimentados de Java que solo juran por EE. Brillar.

TL; DR : Creo que Vaadin no entiende qué son las webapps y, lo que es más importante, cómo deben comportarse. Se trata de que los programadores abrazen la web y cómo los usuarios interactúan con ella (es decir, botón de retroceso, botón de recarga, pestañas y marcadores). Cuanto más cerca se quede una aplicación web de las solicitudes HTTP y la semántica (verbos), es más probable que coincida con las expectativas del usuario. Y esa es la clave.

EDITAR : si tienes alguna experiencia en Python, te recomendaría probar también Flask para obtener una idea de la programación de aplicaciones web basadas en REST basadas en url.

EDIT 2 : Si por algún motivo sientes que debes usar un framework tipo Vaadin de pila completa, entonces prueba Meteor. Es un marco basado en JavaScript (frond y back end) que se ejecuta en Node.js con una comunicación asincrónica que ocurre a través de WebSocket (por lo tanto, menor latencia que la solicitud / respuesta) y es reactiva por defecto. Una serie de cosas que no me gustan en Vaadin se han abordado en Meteor. Por ejemplo, la lógica de las actualizaciones de la interfaz de usuario se ejecuta en el cliente, lo que la hace mucho más receptiva que en Vaadin. La gente de las comunidades JavaScript y Java no se cruzan mucho, pero cuando escuché por primera vez, el paralelismo con Vaadin me golpeó de inmediato. Actualmente goza de bastante impulso en la comunidad por razones similares a las que hicieron popular a Vaadin, es decir. la capacidad de crear aplicaciones web similares a las de un escritorio. Pruébelo si también se dio cuenta de que Java no pertenece mucho a la imagen de futuras aplicaciones web o si está cansado de esos largos ciclos de implementación cuando basta con actualizar. Pero piénselo dos veces antes de vincular una aplicación completa a una sola biblioteca.


Hubo "inquietudes" sobre Wicket al usar sesiones para administrar estados de componentes y escalabilidad similares a los argumentos sobre Vaadin y el procesamiento del lado del servidor. He aprendido en los últimos 10 años que la comunidad Java generalmente está equivocada sobre cómo medir el potencial de un framework web (entre otras cosas). Desde JSF a Grails, generalmente se necesitan unos cientos de GB de memoria y al menos una docena de archivos jar de código abierto con funcionalidades superpuestas e ineficientes para ejecutar una aplicación de producción. Mire a su alrededor y verá que la mayoría de las empresas de alojamiento web no ofrecen una opción java práctica debido a la ruta irregular que las tecnologías de Java han tomado para los marcos web. GWT 2.1 todavía es difícil de usar debido a la velocidad de compilación y se está poniendo serio con MVP y tablas de datos que deberían haber estado allí desde el principio. Me gusta Wicket pero Vaadin parece prometedor ... pero sabiendo cómo funcionan los frameworks de Java, estoy seguro de que se dispararán en el pie en algún momento, pero dudo que sea por el gran procesamiento del lado del servidor.





vaadin