java - logo - apache hbase download

GUI de Java descrita en XML

Question

Actualmente, mi empresa evalúa el desarrollo de un cliente Java FAT. Debe admitir una GUI dinámica y tiene tanta lógica como sea posible en el lado del servidor. De ahí surgió la idea de enviar la pantalla como XML al cliente FAT, mostrarla al usuario y enviar los datos ingresados ​​similares a "formulario html" en una estructura como la siguiente:

<fields>
<field type="checkbox" name="active" checked="false" x="10" y="10" />
<field type="textbox" name="username" value="dummy" x="10" y="30" />
<field type="selection" name="group" selectedIndex="1" x="10" y="50">
<data index="0">user</data>
<data index="1">admin</data>
</field>
<field type="button" name="ok" x="10" y="70" />
<field type="button" name="cancel" x="10" y="90" />
</field>

Fondo
El patrocinador está buscando una aplicación de entrada y revisión de datos que pueda adaptar a sus necesidades simplemente cambiando la configuración. Por lo tanto, debemos ofrecer a los administradores la posibilidad de diseñar las llamadas "pantallas" (también conocidas como formularios) y proporcionar un sistema cliente / servidor que les permita distribuirlos a sus usuarios finales. Los datos entrantes (es decir, los datos ingresados ​​por un usuario) se reenviarán a un motor de flujo de trabajo ya existente que maneja la lógica comercial.

Pregunta
¿Alguien ha desarrollado algo similar? ¿Qué bibliotecas sugerirías? Cualquier pro & contra? ¡Muchas gracias!

Actualizar
Muchas gracias por su aporte, Thinlet se ve muy prometedor, así como JavaFX . Examinaré ambos.

Answer 1

"Debe soportar una GUI dinámica y tiene tanta lógica como sea posible en el lado del servidor".

Lo que describes es una aplicación web. El cliente ya está escrito (el navegador) y el formato XML (ish) es (X) HTML.

Sería posible recrear este proceso utilizando su propio formato XML y su propio cliente, pero no veo por qué es necesario o deseable.

Answer 2

Básicamente, está enviando formularios serializados al cliente y serializando los datos resultantes. Esto podría hacerse con la serialización de Java, es decir, RMI, pero los firewalls y demás pueden complicar el uso de RMI en Internet.

Si desea utilizar XML sobre HTTP en el cable, puede echar un vistazo a java.beans.XMLEncoder . XMLEncoder está orientado hacia la serialización de los componentes de la interfaz de usuario, pero funciona igual de bien para serializar los POJO. Estos serían esencialmente los objetos modelo que se rellenan con la entrada del usuario en el cliente FAT.

Answer 3

Existen bastantes kits de herramientas basados ​​en XUL para una variedad de idiomas, incluido Java. Creo que Thinlet hace un XUL muy simplista para Java, pero debería haber otros.

Answer 4

Hicimos algo similar con SWT, aunque eso era convertir una estructura de datos lógica (en este caso, un modelo de formulario de solicitud) en una GUI, en lugar de especificar la GUI directamente. Esto nos permitió refactorizar la GUI dependiendo de las propiedades del cliente (PocketPC o Desktop) porque el modelo de datos era semántico en lugar de dictatorial sobre el diseño.

Escribir analizadores y generadores XML es simple. Escribir algo para generar una interfaz desde un modelo es menos simple, ya que necesita almacenar las relaciones entre los elementos de la GUI y los campos del modelo con los que se relacionan para poder actualizarlos cuando se realiza un cambio, en lugar del habitual escucha codificada en cada uno Elemento GUI.

Answer 5

Prueba QT Jambi . Esto le permite crear diseños de formulario en QT Designer y exportarlos como un archivo descriptor del tipo que describió.

Answer 6

Pruebe JavaFX ( Wikipedia sobre JavaFX ). No es XML, pero es fácil y declarativo también.

Answer 7

La última vez que busqué tal cosa, dos opciones eran Thinlet y Apache Jelly .

Los puntos positivos eran que podía separar el cableado y la construcción de su aplicación del comportamiento. No estoy seguro de la viabilidad de ninguno de ellos para hacer esto, pero creo que podría haber alguna funcionalidad para traducir a otro conjunto de herramientas, al igual que Lazlo puede traducir a AJAX y Flash.

Antes de encontrarlos, había escrito un kit de herramientas similar (cuando Echo era de vanguardia, y Java 1.3 estaba a punto de agotarse), basado en el JHTMLEditor. Funcionó, pero los oyentes se estaban ejecutando en la misma VM que el renderizador.

Lo que hace ver el punto que hace @Draemon, en un contexto cliente / servidor, debería preguntar si esta es una manera fructífera de resolver el problema más grande. ¿Supongo que quiere descargar muchos ciclos de CPU en el cliente? Tal vez si agrega un poco más, podemos hacer más sugerencias? Esto apunta a un enfoque en el que su aplicación se implementa en el escritorio como un servidor web localhost , y sirve páginas a un navegador local.

Si puede esperar, esperaría y esperaría JavaFX , ya que esto hará que los applets de construcción sean mucho más declarativos, y también reducirá la descarga inicial de la biblioteca de renderizado.

Answer 8

Eche un vistazo al framework ofbiz. usa widgets (xml) y mediante manejadores los convierte en salidas http://ofbiz.apache.org/