18/05/2009
02/06/2009
18/06/2009
package org.openxava.escuela.modelo;
import javax.persistence.*;
import org.openxava.annotations.*;
@Entity
public class Profesor {@Id @Column(length=5) @Requiredprivate String codigo;
@Column(length=40) @Requiredprivate String nombre;
return codigo;
}
this.codigo = codigo;
}
return nombre;
}
this.nombre = nombre;
}
Y obtendrás una aplicación (como esta) para el mantenimiento, generación de listados PDF, exportación a Excel, busqueda, ordenación, validaciones, etc. Y para todos esto solo necesitas escribir una simple clase de Java, nada de XMLs, JSPs ni generación de código.
}
Este motor de aplicaciones tiene muy buena pinta. Me lo acabo de descargar y quiero estudiarlo en profundidad. Nosotros actualmente estamos desarrollando un conjunto de portlets para Liferay, por lo que he visto, este engine me permite crear los CRUDs en portlets de una forma muy sencilla. Ahora queda por ver que tal se integra con el resto de componentes de la aplicación.
Mi enhorabuena a Javier Paniza.
Hola,
Ahora queda por ver que tal se integra con el resto de componentes de la aplicación
Siempre puedes instalar las dos aplicaciones en Liferay, ya que la interfaz de usuario y la gestión de usuario sería común. Así que de cara al usuario final parece una única aplicación
Saludos
Hola,
Lo primero mi enhorabuena por el trabajo, que me parece estupendo y es de agradecer que sea OS.
En cuanto a la parte de opinion que preguntas, como opinión puramente personal el "soniquete" en contra de MVC, tal y como se entiende en web, y decir que "no hay vista" me parece contraproducente. Es como decir que uno esta en contra de los motores en los coches por que si se compra un Ford, no hay que construirse el motor. El hecho de que no tengas que hacerlo tú, no quita que el motor esté ahí y sea útil. El beneficio de OpenXava es que esta por encima de MVC y no tienes que programar tu a ese nivel, pero no quita que esté. Así que tanto empeño en defenestrarlo me parece desviar el foco, que debería estar centrado en otras cosas.
Para mi es, solo como ejemplo, como los frameworks modernos que se empeñanen describirse como "que no usan XML" y no dejan de repetirlo como un mantra, cuando es más productivo explicar qué usan en vez de XML y por qué es mejor.
En cuanto a las aplicaciones, como estilo para aplicaciones "de gestion" me parece estupendo, personalmente lo de "configurar la vista" mediante anotaciones en en el codigo Java no me convence demasiado, pero si quieres limitarte a que escriban el modelo, pues no hay muchos sitios donde hacerlo. No lo veo como una solución general para cualquier tipo de aplicacion (eso ya lo decis vosotros asi que no es una critica, es para aclararlo que hay gente con mucha imaginacion ;) ), pero si que en cuanto a aplicaciones de gestión, está claro que es mejor que picar el mismo código (boilerplate que dicen los anglos) una y otra vez cuando del modelo se pueden sacar el 95% de las cosas.
Es la estrategia que seguian algunas herramientas CASE de antaño hasta que vino el mundo web a trastocarlo todo y echarnos un par de años para atras jejeje.
En una aproximación similar, pero distinta ya que las aplicaciones que me toca hacer son puro "estilo web", nosotros lo que hacemos es sacar del modelo (BDD en nuestro caso) un 90% del codigo repetitivo para generar XML desde la lógica, y un par de ayudas para la vista. Pero como hacemos aplicaciones NO de gestion sino web, la vista es poco automatizable y llegamos hasta donde mas o menos podemos preveer. Como el XML es independiente de la tecnologia de la vista, pues no nos atamos.
De nuevo, gran trabajo.
Y una curiosidad, ¿que tal el rendimiento de interpretar las anotaciones en "Runtime" frente a generar el codigo y ejecutarlo ya compilado? Nosotros de momento optamos por el generado+compilado, en parte por que todavia tenemos que dar soporte a Java 1.4.
Hola javierpaniza ,has dicho que: <em>¿Pensáis que los marcos MVC (Struts, SpringMVC or JBoss Seam) son tan productivos como VisualBasic, 4GLs, RPG, etc. para desarrollar aplicaciones de gestión? </em>
Te puedo hablar de mi experiencia en VB.
Primero debo indicar que estas comparando frameworks Java ( Struts, SpringMVC or JBoss Seam ) contra un lenguaje + IDE (VisualBasic).
Y sinceramente usar VB a pelo yo nunca lo he visto productivo. Haces una aplicación en 4 patadas pero está que da asco.
Otra cosa es si comparas VB+un framework contra Struts o SpringMVC or JBoss Seam. Ahí si que creo que gana VB.Pero simplemente pq las pantallas de diseñaban muy facilmente (gracias a dios no había HTML) y era cliente-servidor por lo que se simplificaba mucho todo.
Saludos.
Hola greeneyed,
estoy de acuerdo con todo lo que dices.
Puede que haya sido demasiado anti-MVC al describir OpenXava. Quería crear un poco de contraste.
¿que tal el rendimiento de interpretar las anotaciones en "Runtime" frente a generar el codigo y ejecutarlo ya compilado?
El mismo. Pero claro, la metainformación que ahora está en Java antes estaba en XMLs, y los XMLs también hay que analizarlos.
El tiempo que se tarda en leer una anotación no es nada comparado con un solo acceso simple a una base de datos.
Nosotros de momento optamos por el generado+compilado, en parte por que todavia tenemos que dar soporte a Java 1.4
OpenXava 3.0 todavía soporta XML + generación de código y Java 1.4. Tenemos clientes con WebSphere Portal, e IBM a estas alturas todavía no soporta Java 5 en sus portales.
Hola logongas,
Otra cosa es si comparas VB+un framework contra Struts o SpringMVC or JBoss Seam. Ahí si que creo que gana VB
Lo mismo ocurre con RPG o los 4GL.Y esto a veces cuesta entender desde fuera. Por mucho que digas que es más flexible, robusto, permite hacer cosas más complejas, es más fácil de mantener, es más escalable. Da igual.
SaludosEl mismo. Pero claro, la metainformación que ahora está en Java antes estaba en XMLs, y los XMLs también hay que analizarlos.
No me he explicado bien. Nosotros lo que hacemos es generar en tiempo de compilacion el codigo que hace lo que tu indicas en la anotacion, o XML ya puestos, asi que no tienes nada que "interpretar" en tiempo de ejecución. No es tan flexible como hacer el cambio directamente en el codigo, ya que añades la fase de generacion, pero a cambio en ejecucion no hay que "decidir" nada.
Pero si me dices que no notais nada en el rendimiento, ya me has respondido. Efectivamente algunas cosas son "despreciables" frente al coste de acceder a la BDD, mientras no pases ;). Como ejemplo, en un caso real que ahora mismo estoy tratando: un codigo ejemplo Groovy "interpretado" accediendo a una BDD en local -> 2s. Exactamente el mismo codigo precompilado y ejecutado como .class -> 40-70ms. De ahi mi curiosidad por si la diferencia era notable, pero vamos, de 40 a 90 ms es una risa, por ejemplo, si el tiempo total de acceso ronda el segundo.
S!
PD: Como a todo el mundo mundial de Open Source hispano, si cuando haceis un lanzamiento quereis que lo pongamos en el Newsletter de la comunidad JavaTools de java.net, o quereis publicar algun "tip" sobre como usar OpenXava, o enlazar el proyecto desde la comunidad, estais cordialmente invitados ;).
Hola greeneyed:
hacer el parse de las anotaciones una entidad para almacenarlo internamente en OpenXava cuesta entre 50 y 300 ms. Pero solo se hace una vez, una vez OpenXava ha almacenado la metainformación (justo con los mismas clases usadas en la versión XML) volver a acceder a ella cuesta 0 ms. Es decir, esto no es un problema.
PD: Como a todo el mundo mundial de Open Source hispano, si cuando haceis un lanzamiento quereis que lo pongamos en el Newsletter de la comunidad JavaTools de java.net, o quereis publicar algun "tip" sobre como usar OpenXava, o enlazar el proyecto desde la comunidad, estais cordialmente invitados ;).
¡Genial! Dime que tengo que hacer
Hola javierpaniza,
al almacenar toda la información de los XML en clases java, ¿no aumenta el tiempo del GC?¿Habeis medido si afecta al rendimiento?
Gracias.
¡Genial! Dime que tengo que hacer
Simplemente poneros en contacto conmigo a traves de mi direccion en java.net ;).
http://community.java.net/javatools/ (arriba a la derecha)
S!
Hola logongas,
al almacenar toda la información de los XML en clases java, ¿no aumenta el tiempo del GC?
Justo lo contrario. La metainformación no está duplicada y está ahí durante toda la vida de la aplicación.
Parsear cada vez (tanto para anotaciones como para XML) aumenta el uso del GC porque al hacer el parse se crean objetos nuevos que se descartan. De la otra forma se usan siempre los mismos objetos que el GC nunca borra.
Además el tamaño de esta metainformación es ridículo al lado de lo que vas a gastar cuando hagas un listado grande, o un proceso masivo.
Saludos
Hola javierpaniza,
Gracias por tu aclaración.
Estoy haciendo un proyecto OS parecido y tambien tengo toda la metainformación clases Java.
Aunque tengo otra duda, ¿como haceis la paginación de los ResultSets contra la base de datos.? Yo uso CachedRowSetImpl, pero para grandes tablas va muy lento y la única solución que he encontrado es limitar el nº de registros.
Gracias.
Hola longongas,
¿como haceis la paginación de los ResultSets contra la base de datos.?
Por suerte OpenXava es de código abierto, así que puedes mirarlo en el paquete
org.openxava.tab.impl
Echale un vistazo.
La estructura parece un poco elaborada, pero hay un herencia que tenemos que seguir llevando,
así que está pensado para poder ejecutarse dentro de un SessionBean, y el formato del resultado
es un TableModel (sí, sí, un tablemodel de la swing).
El rendimiento es bastante bueno incluso con tablas muy grandes. Cogemos los datos de 50 en 50,
si coges más algunas bases de datos se cansan, y si coges menos no hay diferencia. Siempre cerramos
el resultset y la conexión inmediantemente, y para colocarnos, no usamos ResultSet.absolute (increiblemente lento
en algunas DB) sino un bucle.
Es el código más antiguo de OpenXava, funciona muy bien, y no lo podemos cambiar porque OX todavía tiene que soportar aplicaciones EJB2.0 (con entity beans). Pero si yo tuviera que empezar de cero y no fuera necesaria compatibilidad con EJB2.0, me plantearía seriamente usar JPA directamente para el modo lista. Sobre todo porque es una puerta abierta para usar una ODBMS.
Saludos
Hola javierpaniza,
gracias por el comentario del "absolute", no lo sabía.
He estado mirando el código de la clase JDBCTabProvider y he visto la solución que usais.
Ya había pensado en ella pero la deseché porque había el riesgo de que si alquien borra una fila de la página que está viendo el usuario al pasar a la siguiente página, el usuario dejaría de ver la primera fila de la nueva página que está viendo.
Una posible solución sería usar un ResultSet con TYPE_SCROLL_INSENSITIVE pero el problema es que debes retener la conexión entre peticiones. En the server side, tienen un artículo sobre ello: Data List Handler: A pattern for Large Search Result Sets.
Así que no encuentro ninguna solución "ideal" al problema.
Saludos.
quisiera saber cuan escalable es Openxava
Escribe tu comentario