Esto es una traducción al español del artículo publicado en java.net en junio del 2008
por Javier Paniza
Esta es una historia sobre cómo crear una interfaz de usuario fácilmente, o mejor aun, sobre como tener una buena interfaz de usuario sin esfuerzo.
Hubo un tiempo en que conseguiste crear una aplicación de facturación de verdad buena. Tu fantástica aplicación tenía una ágil interfaz de caracteres MS-DOS (o Unix, o AS/400, o HOST), pero tus usuarios te pedían una interfaz gráfica de Windows: más bonita, más fácil de usar. Por tanto, reescribiste tu aplicación para que tuviese una interfaz de usuario Windows. Ahora ya era todo perfecto, pero entonces empezó a ser interesante que tu aplicación fuera multiplataforma, y sin dudarlo, la reescribiste usando Java con AWT, pero la interfaz de usuario quedó un poco pobre, y la reescribiste una vez más usando Swing. Otra vez era todo perfecto, o casi. Los usuarios empezaron a pedir una aplicación web, por tanto ahora usaste JSP para crear una interfaz web, y entonces tus usuarios te pedían integración en portales, y tuviste que adaptar tu aplicación para correr dentro de portales JSR-168, y puede que empezaras a usar JSF. Ahora, tus usuarios continúan pidiendo una mejor interfaz de usuario; quieren una interfaz web más rica. ¡Glup! Ahora tienes que reescribir tu aplicación con AJAX, o quizás JavaFX, una vez más.
¿Cuántas veces has de reescribir tu aplicación para mejorar la interfaz de usuario?
La solución ideal, a primera vista, es tener técnicas para declarar tu interfaz de usuario de una manera abstracta, y contar con varios motores de visualización para representar la interfaz de usuario usando diferentes tecnologías de presentación. Esto no es del todo una mala idea, de hecho muchos intentos interesantes se han hechos en esta dirección; XSL/XML, XForms, XUL, y otros más buscan una forma abstracta de definir interfaces de usuario. Pero a la hora de la verdad estas técnica no son tan abstractas como parece. ¿Puedes crear una aplicación Windows con XSL/XML? ¿Puedes definir una aplicación Flash con XForm? ¿Puedes crear una aplicación HTML/AJAX con JavaFX? Quizás. Pero muchas veces, cada nuevo motor de presentación tiene su propia definición “abstracta” de interfaz de usuario. A pesar de decir esto, mi esperanza es que en un futuro cercano tengamos una forma universal de definir interfaces de usuario, al menos para aplicaciones de gestión, quizás una evolución de XForm, o ...
Por otra parte, yo propongo una solución alternativa: No definir “interfaz de usuario” en absoluto.
Sí, es posible crear aplicaciones de gestión complejas sin definir la interfaz de usuario. ¿Cómo? Sencillo: la interfaz de usuario se puede derivar del modelo, es decir, de las clases de tu sistema que definen la estructura de los datos y el comportamiento asociado a esos datos. Llevo ya siete años usando esta técnica, y lo primero que notas es que el tiempo de desarrollo se acorta bastante, porque no tienes que dibujar la interfaz gráfica, aunque lo más llamativo fue lo suave que fue migrar aplicaciones de Swing a Web.
Puede que pienses que esta técnica solo puede ser usada para prototipado o impactantes demos de desarrollo rápido, y cuando intentes crear una aplicación de gestión del mundo real, fallará. Si piensas así estás equivocado. El truco está en darle al modelo algunas pistas para que organice los datos de forma clara de cara al usuario, o para que lance eventos en ciertas circunstancias. Sin embargo tú no estás definiendo la interfaz de usuario, simplemente haces algunas indicaciones para que el generador de interfaces gráficas pueda hacer un trabajo más efectivo.
Como muestra un botón.
Estos ejemplos están basados en el marco de trabajo OpenXava, un proyecto de código abierto que es un proyecto federado de la comunidad Java Enterprise en java.net.
Como primer ejemplo, puedes tener una clase para cliente, como esta:
@EntityY con solo este código, obtienes una aplicación como la de la Figura 1 con una interfaz de usuario completa, más el mantenimiento y el modo lista para navegar, ordenar y filtrar; generar listados en PDF y exportar a Excel. Obtienes todo esto sin código adicional, solo con la clase Cliente de arriba.
Figura 1. Módulo de mantenimiento OpenXava para clientes
Solo necesitas escribir el Cliente.java de arriba, añadirlo a una aplicación OpenXava existente, redesplegarla en tu servidor de aplicaciones Java, abrir tu navegador e ir a http://localhost:8080/Facturacion/xava/module.jsp?application=Facturacion&module=Cliente para ver el resultado funcionando.
Crear una aplicación OpenXava desde cero es coser y cantar. Descarga la última versión de OpenXava y descomprimela. Ve a la carpeta openxava-3.0.x/workspace/OpenXavaPlantilla, y ejecuta la siguiente tarea ant:
/java/openxava-3.0.3/workspace/OpenXavaPlantilla> ant -f CrearNuevoProyecto.xml
Buildfile: CrearNuevoProyecto.xml
[input] ¿Cuál es el nombre de tu proyecto?
Facturacion
[input] ¿Cuál es tu fuente de datos?
FacturacionDS
Como puedes ver, el build te pregunta por el nombre del proyecto y la fuente de datos. Simplemente teclea Facturacion y FacturacionDS. Ahora tienes un nuevo proyecto OpenXava llamado Facturacion en tu workspace. Ve a la carpeta src y crear el paquete com.miempresa.facturacion.modelo allí. Dentro de él pon el código de la clase Cliente de arriba. Puedes desplegar esta aplicación en un contenedor de servlets usando la tarea Ant desplegarWar o generarPortlets si prefieres usar un portal JSR-168, como Liferay, JetSpeed o WebSphere Portal. Por supuesto, has de definir una fuente de datos llamada FacturacionDS en tu servidor de aplicaciones. Si no hay tablas para tus clases en tu base de datos usa la tarea Ant actualizarEsquema para crearlas.
Para una guía pasa a paso de como crear un proyecto OpenXava nuevo, ver el Capítulo 2 de la guía de referencia de OpenXava.
Pero que ocurre en el caso de un ejemplo más complejo, como una factura, ¿sigue dando buen resultado generar la GUI automáticamente? Por supuesto. Vamos a dar al sistema algunas pistas, y dejar que siga siendo él quien siga generando la interfaz de usuario. Lo haremos añadiendo anotaciones a tu clase Factura. Creemosla con año, número, fecha, observaciones, suma de importes, porcentaje de IVA, IVA, referencia a su cliente, una colección de líneas, y una colección de albaranes. Para poder conseguir esto, necesitamos las siguientes clases: Factura, Cliente, LineaFactura y Albaran. Ya hemos visto el código de Cliente, y ahora vamos a ver el de Factura:
@Entity // 1Esta clase no define la interfaz de usuario (como sería el caso con XUL o XForm); en lugar de ello, solo da alguna información sobre la forma preferida de disponer los datos. Esto lo hace mediante anotaciones JPA y OpenXava. Examinemos estas anotaciones:
@Entity (JPA): Marca esta clase como persistente, diciendo que hay una tabla en la base de datos que guarda la información de las facturas.
@View (OX): Con la anotación @View defines los miembros (propiedades, referencias o colecciones) de modelo a mostrar, y la distribución de los datos en la interfaz de usuario; usando {} indicas la forma en que prefieres que se clasifiquen los datos.
@Column (JPA): @Column se usa por el motor JPA para obtener información sobre la columna de la base de datos y así hacer el mapeo objeto-relacional, generando el DDL si fuese necesario. OpenXava, por su parte, usa length de @Column para calcular el tamaño del editor en la interfaz de usuario.
@ManyToOne (JPA): Esta es la forma estándar de definir una relación de muchos a uno para una entidad. Es decir, una simple referencia de una entidad a otra. OpenXava lo usa para crear una interfaz de usuario para visualizar, buscar, modificar y crear nuevos objetos de la entidad referenciada.
@OneToMany (JPA): Esta anotación es la forma estándar de definir una relación de uno a muchos para una entidad. Es decir, un colección de otras entidades. OpenXava lo usa para crear una interfaz de usuario para manejar la colección; esto incluye visualizar elementos, añadir nuevos; borrar, editar, ordenar y buscar en las colecciones; generar listados PDF de los elementos de la colección; exportar a Excel; y así por el estilo.
@ListProperties (OX): Puedes usar esta anotación para definir las propiedades a mostrar en la interfaz de usuario para colecciones.
@Digits: Esta anotación es del marco de trabajo Hibernate Validator. OpenXava reconoce las anotaciones de Hibernate Validator, y en este caso usa integerDigits y fractionalDigits para calcular el tamaño del editor en la interfaz de usuario.
Con estas pistas, OpenXava produce una interfaz de usuario como la que se muestra en la Figura 2. Solo necesitas escribir las clases, desplegar la aplicación, e ir a http://localhost:8080/Facturacion/xava/module.jsp?application=Facturacion&module=Factura. Nada más.
Figure 2. Módulo OpenXava para Factura
Puedes ver como esta interfaz todavía es generada desde el modelo, mientras que las anotaciones OpenXava son solo un grupo de sencillos consejos abstractos. Por ejemplo, las secciones (los miembros entre llaves) indican como se clasifica la información al visualizarse. En este caso, cada sección corresponde a una pestaña en la interfaz de usuario, pero otros generadores de UI podrían escoger usar un árbol, un acordeón, u otro tipo de control UI, para acceder a los datos de las secciones, incluso podrían optar por mostrar todos los datos en la misma ventana. Un generador UI potente podría incluso permitir al usuario escoger la forma exacta de mostrar las secciones (pestañas, árboles, acordeón u otro).
¿Qué ocurre cuando la estructura de datos cambia? En este caso solo necesitas añadir las propiedades, referencias o colecciones que necesites, y ejecutar la tarea Ant actualizarEsquema para actualizar la base de datos, desplegar tu aplicación (con desplegarWar), y refrescar tu navegador. Si usas el Tomcat dentro del Eclipse para JEE puedes omitir el paso de desplegar.
La generación automática de la interfaz de usuario desde el modelo no es una solución universal; a veces diseñar una interfaz de usuario manualmente puede ser mejor. Pero, en muchos casos, (como en el caso de las aplicaciones de gestión) un alto porcentaje de la interfaz de usuario de la aplicación puede ser creada automáticamente, con un resultado muy bueno.
La generación automática de la UI tiene las siguientes ventajas:
Evolución de la interfaz: Al no escribir la interfaz de usuario usando una tecnología específica, la migración de la aplicación a otro tecnología de presentación es fácil (por ejemplo, migrar una aplicación pura HTML a una AJAX).
Productividad: Liberas a tus desarrolladores de un trabajo que consume mucho tiempo. Al final, los marco de trabajo MVC se quedan en MC.
Y lo más importante; esto no es una aproximación teórica, sino práctica. En mi empresa estamos usando estas técnicas por más de siete años con gran satisfacción. Primero, los programadores con menos experiencia son productivos con Java desde el principio, sin tener que aprender todos los trucos de la Swing, y estos mismos programadores puede desarrollar aplicaciones para portales Web sin tener que aprender JSP, JSF, JSR-168, etc.
¿Piensas que usar Swing o JSP o JSF o AJAX es necesario para la felicidad de tus programadores? Yo creo que no. Cuando los programadores se acostumbran a usar la generación automática de la UI, empiezan a odiar el desarrollo a mano (incluso usando un diseñador gráfico para GUIs) de las interfaces de usuario.
Los siguientes marcos de trabajo y tecnologías tienen el espíritu de este artículo:
OpenXava: Este marco de trabajo genera automáticamente aplicaciones de gestión desde simples clases Java con anotaciones, incluyendo interfaces de usuario complejas. Los ejemplos de este artículo usan la sintaxis de OpenXava. Si tienes interés en la sintaxis completa para la generación de UI puedes ver la documentación de OpenXava.
Trails genera aplicaciones Web desde POJOs anotados.
JMatter construye aplicaciones Swing de gestión para trabajo en grupo basándose en clases de modelo.
NakedObjects genera una UI desde objetos Java; las clases tienen que seguir ciertas normas.
RomaFramework genera aplicaciones desde POJOs usando archivos XML files para personalizar la vista.
MDA: La esencia de MDA es generar una aplicación completa (por tanto una UI también) desde un modelo UML. EL principal elemento del diseño de software es el modelo, y la interfaz de usuario es generada. (Quizás la excesiva orientación a la generación de código de MDA produce herramientas que no son demasiado ágiles desde la perspectiva de un desarrollador)
Todo esto está muy bien, es ideal, pero tiene sus pegas.
Cuanto más fácil es hacer una cosa en esto de las GUI, más difícil acaba siendo personalizar algún comportamiento.
Y esto pasa desde que empezamos a poner capas. Por ejemplo, con JSF, el ciclo de vida nos proporciona la forma de hacer conversiones y validaciones de una forma automática en la mayoría de los casos y muy limpia cuando nos salimos del guión. Sin embargo, cuando necesitamos saltarnos una fase para un componente tendremos que reescribir todo el ciclo de vida, casi nada.
No tengo el placer de conocer OpenXava por dentro, pero supongo que en cuanto nos salimos de la plantilla básica para algún campo, si el framework no soporta lo que queremos hacer, tendremos que trabajar bastante más de lo que supondría hacerlo por ejemplo en simple jsp.
Un ejemplo en una relación uno-a-muchos, como determinar si es en la entidad A donde debes especificar las entidades B que contiene o es B la que especificará con que entidad A se contiene.
Es decir, de que lado mostramos una relación.
Y por ejemplo las select que dependent de otra, que son una cosa muy util. O decidir si un campo es una select, un autocompletable cerrado o un autocompletable abierto. Para seleccionar localidades podemos tener una lista cerrada corta(select), una larga (autocompletable cerrado) o una abierta a nuevas incorporaciones con un autocompletable y en caso de poner una nueva que se cree.
Luego está el tema de los widgets para mostrar números, fechas, texto, emails, intervalos. Puedes a veces necesitar una fecha como un campo de texto o como un calendario, con un selector tipo popup...
La solución al problema de los caprichos del cliente o dicho de otra forma, de la problematica específica de cada aplicación debido a su semántica, es complicada. Y ahí está el problema. Un mismo modelo puede tener diferentes semánticas y su vista puede ser diferente.
Esto hace que las aplicaciones tipo OpenXava acaben pareciendo más un frontend de una base de datos que una aplicación de cara al usuario. Un ejemplo claro: a mi no se me ocurriría poner llavecitas en las aplicaciones webs para mostrar la clave primaria, es más, normalmente oculto esos campos.
Según evolucionan ofrecen cada vez más posibilidades pero siempre hay algo nuevo que surge. No conozco OpenXava pero no creo que de solución sencilla a todos estos problemas. Si lo hace, es hora de convertirse y creer.
A veces pienso que una aproximación mejor al problema es que el framework cree esqueletos y luego puedas modificar a tu gusto, pero esto tiene otra pega claro, una vez modificados añadir cambios al modelo seguiría suponiendo cambiar la vista a mano.
Cuanto más fácil es hacer una cosa en esto de las GUI, más difícil acaba siendo personalizar algún comportamiento.
Pero podemos tener algo fácil e ir añadiendo la posibilidad de personalizar en los puntos que sea necesario. Es como el C en los 70, alguien podría decir que el C era más fácil que el ensamblador, pero que el ensamblador daba una flexibilidad que era imprescindible. Bueno, pues la solución es programar en C y llamar a rutinas escritas en ensamblador cuando necesitemos esa flexibilidad especial. Es decir, OpenXava no es un todo o nada, tienes la posibilidad de personalizar la manera en que OpenXava genera la interfaz, o en una aplicación mezclar interfaces producidas con OpenXava con interfaces hechas a mano.
Un ejemplo en una relación uno-a-muchos, como determinar si es en la entidad A donde debes especificar las entidades B que contiene o es B la que especificará con que entidad A se contiene.
Es decir, de que lado mostramos una relación.
Simplemente usas JPA para definir una relación uno a muchos, y después puede mostrar la entidad A (y verías una colección) o la entidad B (y verías una referencia).
Luego está el tema de los widgets para mostrar números, fechas, texto, emails, intervalos. Puedes a veces necesitar una fecha como un campo de texto o como un calendario, con un selector tipo popup...
Puedes definir tus propios editores, y asignarlos a un tipo (modificando así la forma estándar de trabajar de OX), o a una propiedad concreta de una entidad si lo deseas. Mira si quieres la documentación de OpenXava sobre editores.
Un mismo modelo puede tener diferentes semánticas y su vista puede ser diferente.
OpenXava permite definir diferentes vistas para un mismo modelo, y además eso es habitual. Puedes ver la documentación d e OpenXava para las vistas.
Esto hace que las aplicaciones tipo OpenXava acaben pareciendo más un frontend de una base de datos que una aplicación de cara al usuario
No, OpenXava no es solo para generar mantenimientos y listados rápidamente, se diseño para crear aplicaciones de gestión complejas, un Padrón Municipal de Habitantes, una gestión de personal y nóminas o una gestión de inventario, son ejemplos de aplicaciones desarrolladas con OpenXava.
a mi no se me ocurriría poner llavecitas en las aplicaciones webs para mostrar la clave primaria, es más, normalmente oculto esos campos.
Bueno, en eso estamos de acuerdo, yo siempre aconsejo una clave autogenerada oculta (de hecho OpenXava tiene una anotación @Hidden para ese caso). Pero cuando la base de datos no la has diseñado tú no puedes decidir, y OpenXava tiene que soportar todos los casos.
Según evolucionan ofrecen cada vez más posibilidades pero siempre hay algo nuevo que surge.
Eso es verdad, por eso salen versiones de OpenXava regularmente (de 1 a 2 meses), y estas versiones tienen mejoras aportadas por los programadores que lo usan y necesitan ampliarlo para cubrir sus necesidades. Si tu mismo extiendes OpenXava para soportar un nuevo caso y envias el código ese código se incluirá en la próxima versión. Mira los créditos de OpenXava.
A veces pienso que una aproximación mejor al problema es que el framework cree esqueletos y luego puedas modificar a tu gusto
Eso es un generador pasivo de código, a mi no me gustan los generadores pasivos de código (como AppFuse), y OpenXava no lo és. Con un generador pasivo de código escribes menos código para empezar, pero todo el código que se genera es tuyo y lo tienes que mantener tú el resto de tu vida. Con OpenXava, reduces el código que escribes y el código que tienes que mantener.
Mi comentario anterior como anónimo era maś una reflexion que cualquier otra cosa. Estoy de acuerdo contigo en todo o casi todo, pero sigo reafirmandome en sobre todo la primera cuestión, el trabajo general se reduce pero en los casos específicos el coste será mayor que en una aplicación digamos 'desde cero'. La mayor parte de esos problemas será consecuencia de la curva de aprendizaje del framework o como lo queramos mayor. Eso si, eso es para todo tipo de framework, herramienta y si se consigue minimizar en un proyecto tiene muchos puntos ganados. Me agrada que puedas responder a todas mis cuestiones porque eso significa que OpenXava las ha tenido al menos en cuenta. Como no conozco, no puedo opinar sobre las soluciones, su facilidad o su acierto, aunque soy un poco escéptico. Sigo el desarrollo de OpenXava, primero porque sale mucho en JavaHispano, y porque además es un proyecto que probé antes de estar metido en el mundillo web. La idea ya me atrajo entonces y me sigue atrayendo. Aún no me convence pero apuntaré probarlo de nuevo en mi lista de tareas. Por otra parte, estaría genial desarrollar una aplicación tipo, como la PetStore en OpenXava. Eso si daría una verdadera imagen de su potencia y un marco de comparación. En cualquier caso, os felicito por el proyecto y os animo a seguir con él.
Un petstore en Openxava se desarrollaría en tres patadas. :)
Yo sigo OX desde la versión 2.0 y lo utilice (vamos lo puse en producción en una empresa bien grande) en esa versión. Lo que más me costó en ese momento fueron las peculariaridades de Oracle.
En las últimas versiones, con JPA, mejora mucho OX. Sobre todo me encanta el enfoque que siempre ha tenido para portales y portlets, haces el modelo y ya casi tienes todo un administrador. (Si es como RoR o groovy, pero con mucha más potencia, pues con simples anotaciones puedes definirlo casi todo). Le faltaba Ajax, pero veo que el última release han incorporado algo. A ver si saco tiempo para probarla.
En un par de meses vamos a tener que hacer un portal entero sobre WebSphere Portal Server y tengo muy claro que utilizaremos JPA y OX para generar casi todas las vistas de administración. Seguramente para la parte del usuario final usaremos otras tecnologías, pues necesitaremos mucho ajax visual e integración multimedia, pero creo que por lo menos le daré una nueva oportunidad.
Un saludo.
E.Cohnen
Hola Javier,
puedo imaginar el gran trabajo que estás haciendo y la calidad y nivel de abstracción que conlleva.
También agradezco a tu empresa el apoyo incondicional que te está dando.
Pero voy a ser un poco "malo" y plantearte estas cuestiones:
1.- Me da la sensación que liderar el proyecto OX de tal forma que el peso específico tuyo es demasiado. Es decir, me parece que eres el pilar de OX y hay pocas personas capaces de llevar el testigo en caso de haber un relevo.
2.- Respecto a la genereción de código. Por desgracia, la versió 3 no la he podido ver de cerca, pero, tal vez, ¿no seria mejor que, (una vez conseguido un nivel de abstracción tan alto como tiene OX) que no se generase código en absoluto, y que las vistas se creasen dinámicamente sin tener que generar código para nada?.
3.- Respecto a la utilización de mapas(Google Maps, etc.), vídeos, servicios WEB etc. no se como lo llevais en estos momentos.
Bueno, espero haber metido un poco de calor en el foro, y a crear un poco más de espectación de ese gran framework que es OX.
Gracias Javier, espero oir mas noticias de OX, y ver como crece la comunidad de este framework.
Nos vemos,
Eduard Escrihuela
Hola Eduard,
1.- Me da la sensación que liderar el proyecto OX de tal forma que el peso específico tuyo es demasiado.
Esto es un denominador común en los proyectos de código abierto y no solo de OpenXava. En el mundo del código abierto el peso de las personas es mayor que en el código propietario. Esto permite que ocurran cosas antes impensables, por ejemplo, hubiera sido muy dificil que Gestión 400 hiciera un acuerdo con una empresa polaca para colaborar en algún desarrollo, sin embargo, en el caso de OpenXava hay código desarrollado por una empresa polaca, ¿cómo es posible? porque para los programadores ha sido fácil usar OpenXava, ampliarlo y contribuir el código. Así, se produce una colaboración entre las personas de las empresas, y no directamente entre las empresas.
Es mucho más seguro confiar en producto de código abierto que en uno propietario con una gran empresa detrás. Por ejemplo, nosotros usabamos VisualAge (en la era pre-eclipse), e IBM lo descatalogó sin ni siquiera pestañear, y todo nuestro código generado con VisualAge (tanto para Swing como para EJB) simplemente no era reconocido con ninguna otra herramienta (ni por el WSAD de IBM).
En cuanto a mi peso específico en OX, no te preocupes demasiado, OX no es mio, es de todos los que habéis contribuido a él (hoy por hoy más de 25). Seguro que con el tiempo, muchos se animan a hacer contribuciones más importantes, y así el peso se reparta mejor.
2.- Respecto a la genereción de código. Por desgracia, la versió 3 no la he podido ver de cerca, pero, tal vez, ¿no seria mejor que, (una vez conseguido un nivel de abstracción tan alto como tiene OX) que no se generase código en absoluto, y que las vistas se creasen dinámicamente sin tener que generar código para nada?.
OX3 no generá código y las vistas son generadas dinámicamente. Esto permite, modificar el código en el Eclipse, darle al botón de recargar de nuestro navegador, y ver los cambios.
3.- Respecto a la utilización de mapas(Google Maps, etc.), vídeos, servicios WEB etc. no se como lo llevais en estos momentos.
OpenXava genera aplicaciones Web estándar de Java, por tanto cualquier cosas que hagas en una aplicación Web la puedes hacer en una aplicación OpenXava, y a nivel visual, gracias a los editores configurables es muy fácil integrar con otros productos.
En Gestión 400 hemos hecho al menos en 2 ayuntamientos, proyectos en que exponemos la funcionalidad de las aplicaciones OX usando servicios web, para que un portal del ciudadano (desarrollado por un tercero pueda acceder a ello), para esto no usamos nada específico de OpenXava, sino de Java.
En cuanto a la integración con SIG, es algo que tendrá nuestra aplicación de Inventario (una aplicación OX) en su proxima versión. No sabemos todavía si será lo suficientemente genérico para que esté incluido en OX
Saludos
Javier
Hola Javier, solo quería felicitarte a ti y a todos los que contribuímos al desarrollo de openxava. Yo he podido colaborar poco (propiedad format...) porque no me han dejado tiempo para ello pero lo que he utilizado de openxava me ha sido suficiente para ver el potencial que tiene. Espero que consiga convencer a la gente para desarrollar una aplicación más seria con openxava y así poder contribuir a su ampliación con lo que te comenté de la impresión en word y demás. Que, aunque sea con pocas cosas, el código abierto nos permite a todos aportar nuestros granito de arena.
salu2
daniel
Muy interesante este artículo.
La idea del proyecto es muy interesante. Me gustaría saber si hay integración con GWT prevista. Creo que estaría bien hacer algún ejemplo de integración con otras tecnologías.
Por cierto, la creación de instancias se maneja automáticamente en OX? Existe Dependency Injection?
Un saludo y ánimo con el proyecto.
La verdad que está muy bien la generación que hace, y la funcionalidad aportada.
El mapeo por los tipos de campos es de lo mejor, sobre todo cuando hay relaciones a otra tablas que son muy grandes que y por tal motivo no sirve un simple combo.
Coincido con un post anterior en lo de los campos clave. Al usuario no le aporta absolutamente nada. Es más genera más dudas que otra cosa.
Lo que no me imagino es a un usuario frente a un aplicativo con esta usabilidad y apariencia. Puede ser por deficiencias mías(seguramene), pero estuve unos minutos intentando comprender que era cada ícono de la pantalla.
Además no vendría mal pedire a algún diseñador gráfico agregarle algo de estilo :-). Esto es en tono constructivo.
Hablo por lo que ví en las demos colgadass del sitio principal.
Por ahí si viera alguna aplicación real con cierto trabajo en la aperiencia y una estructura de aplicación real (opciones de menú, etc.), terminaría de elegir definitivamente OX.
Hay algo así?.
Muchas Gracias y felicidades por OX.
Buenas tardes desde colombia...
Es posible ver un ejemplo con el tipico registerform y loginform en el que se use validaciones de campos en la vista (onkeypress) o listas dependientes (pais -> estado)? en caso afirmativo, por favor indiqueme donde,
Gracias
Jorge
Escribe tu comentario