Soy bastante novato (o tal vez viejo) con el desarrollo de GUI. Ahora, al profundizar, parece haber una gran cantidad de marcos diferentes para usar. Actualmente, he creado una aplicación Java que extrae todo tipo de metadatos de archivos y aplicaciones en una base de datos PostgreSQL. Esta parte ahora está prácticamente lista y los datos (alrededor de 20000 filas) están en la base de datos del servidor esperando su uso posterior. Supongo que eventualmente podría haber cientos de miles de filas en la base de datos en un puñado de tablas, tal vez millones o dos como máximo.
Un camino habría sido continuar con Java Swing/FX, pero el front-end debería ser realmente independiente del sistema operativo y fácil de abordar, lo que apunta a soluciones basadas en web. Parece que los applets son cosas bastante antiguas y también JSF tiene muchos competidores viables ahora. Los requisitos para la interfaz gráfica de usuario son:
El primer pensamiento fue construir esto puramente en el servidor; construir todos los mapas de árboles, etc., en función de las solicitudes de los usuarios. Sin embargo, con varios usuarios esto probablemente generaría una carga significativa en el lado del servidor. Por lo tanto, pensé si habría una cantidad mínima de lógica de código del lado del servidor, solo para asegurar/aislar las consultas de la base de datos, formar el material principal de HTML/CSS y luego tener la lógica Javascript integrada dibujando los gráficos, interpretando las entradas del usuario, etc. en el lado del cliente ? Actualmente, un misterio es cómo se comunicarían estos dos mundos entre sí, quiero decir, ¿cómo la parte de javascript solicita la información del lado del servidor? ¿Requiere websockets o parte de la lógica de la aplicación del lado del servidor podría actuar como una interfaz REST/API para el código javascript? Tal vez solo tenga un middleware REST de jersey/swing Java "algo" entre la base de datos y la página web proporcionando datos JSON a la lógica Javascript. Jugando ahora con Hibernate, pero no estoy seguro de si encajaría en este escenario...
He escrito código en Java, C, Python, JS y algunos otros lenguajes antiguos + poco Node.js, PHP y Perl. Preferir Java y JS, pero si hay una buena razón para usar otra cosa, no debería ser un problema. Actualmente usa Netbeans (ocasionalmente Eclipse) y ha investigado algunos de los proyectos de ejemplo Web, JavaFX, HTML5, JSF, Maven que tiene. También he intentado investigar Spring, Hibernate, Vaadin, Wicket, JSF y otros frameworks. Todo el mundo dice lo fáciles y superiores que son, pero cuanto más los leo y los pruebo, más parece que no siempre son tan útiles al crear todo tipo de código adicional aquí y allá. Entonces, después de días de investigación, todavía estoy muy perdido con todas estas posibilidades y antes de perderme para siempre en esta jungla, Pensé que tal vez algún gurú aquí podría señalar qué camino debería tomar este n00b. Solo trato de evitar la situación en la que se hace la mitad de las cosas y luego se necesita cambiar el marco porque perder alguna función o mantenimiento se vuelve abrumador.
La ruta Java Applet está casi muerta. Todos los fabricantes de navegadores web están eliminando gradualmente el soporte para Java Applet y entornos de ejecución de complementos similares, como Flash y Silverlight , debido a problemas de seguridad horrendos.
Del mismo modo, dentro de Java, la tecnología Applet ahora está obsoleta y es probable que se elimine gradualmente eventualmente.
Si ya está progresando en la creación de una aplicación Swing/JavaFX, no hay razón para no enviarla. Tal aplicación es ciertamente multiplataforma. Con la modularización de Java realizada en Java el 10/9/11, puede usar herramientas como jlink para crear una compilación personalizada de una JVM que se incluirá con su aplicación como un único ejecutable.
Si decide que una aplicación web es el camino a seguir, y ya tiene conocimientos de Java, entonces Vaadin es la opción obvia. Vaadin se ejecuta en Java con el estado de su aplicación viviendo en el lado del servidor en la JVM. Usted escribe tanto su lógica comercial como su código de interfaz de usuario, todo en Java puro. El marco de Vaadin instala una biblioteca de JavaScript en el cliente a través de la cual una interfaz de usuario de estándares web creada dinámicamente se representa de forma remota en el lado del cliente.
La comunicación entre el cliente y el servidor se maneja automáticamente mediante la tecnología Java Servlet, HTTP, HTTP/2 y WebSocket, según la capacidad de su navegador web, servidor web y capacidades de red.
En cuanto a las secciones de sus diseños de interfaz de usuario que se coordinan y reaccionan a las interacciones del usuario, ese es el propósito mismo de Vaadin. El usuario hace clic en un botón o escribe en un campo, Vaadin transmite ese evento de usuario a la aplicación Java del lado del servidor donde su código reacciona y actualiza el estado de otros widgets. Vaadin comunica automáticamente la nueva condición de esos otros widgets al navegador web donde se actualiza su visualización.
En cuanto a un widget de árbol, Vaadin 8 ya proporciona dos, a Treey a GridTree.
En cuanto a su visualizador de gráficos basado en Java, eso es un problema. Con Vaadin, no hay Java en el lado del cliente. El lado del cliente usa solo tecnologías estándar web como JavaScript, CSS, DOM, AJAX, etc. Si su biblioteca GraphStream puede ejecutarse sin interfaz gráfica, entonces debería poder renderizar en el lado del servidor con una imagen terminada enviada al navegador web. para mostrar.
Si necesita interactividad, deberá encontrar una herramienta de JavaScript equivalente a GraphStream. Dicha herramienta se puede empaquetar como un widget de Vaadin para acceder al lado del servidor en Java. En Vaadin 8, esta envoltura se realiza a través de GWT, Google Web Toolkit. En Vaadin 10 y versiones posteriores, conocidas como Vaadin Flow , este ajuste se vuelve mucho más fácil gracias a la adopción de la tecnología de componentes web en lugar de GWT.
Mencionó Hibernate , pero es irrelevante para su pregunta. Ese proyecto es principalmente para automatizar algunas interacciones con una base de datos. No tiene nada que ver directamente con la interfaz de usuario o la aplicación mayor. Algunos subproyectos auxiliares, como la implementación de Bean Validation, tienen un propósito entre la interfaz de usuario y la base de datos.
Solo trato de evitar la situación en la que se hace la mitad de las cosas y luego se necesita cambiar el marco porque perder alguna función o mantenimiento se vuelve abrumador.
Con cualquier elección de tecnología, debe concentrarse en hacer una prueba de concepto descartable antes de embarcarse en la implementación real. Cree una aplicación falsa que toque parcialmente todas las áreas planificadas en su aplicación. Ejercite cada pieza de tecnología para asegurarse de que se adapte a sus necesidades. Una vez probada, deseche esa aplicación falsa y comience de nuevo con la confianza de que puede cumplir su misión.
Gracias @Basil por su completa respuesta. He estado haciendo lo que dijiste al probar diferentes enfoques con una pequeña cantidad de datos de prueba. El primer viaje fue PHP, que descarté en breve porque PHP se siente un poco torpe, la seguridad es un poco cuestionable y el mantenimiento futuro con un sitio cada vez más complejo puede volverse tedioso. Ahora he estado jugando con Vaadin por un tiempo y se siente como una buena opción. El soporte de la comunidad podría ser mejor y todavía un poco perdido con su jerarquía, funcionalidad interna y con toda la nueva notación elegante de Java 1.8 que ha traído a la mesa (!) :s
Sin embargo, todavía estoy equilibrando entre la interfaz gráfica de usuario web y la aplicación de escritorio. Crear un tipo de aplicación web ide parece mucho más complicado que una aplicación de escritorio clásica similar. Por lo tanto, Swing/JavaFX todavía está sobre la mesa como opción alternativa si la construcción de la interfaz gráfica de usuario web se vuelve demasiado complicada.
albahaca bourque
BrenBarn