¿Alguna buena alternativa para Struts 1?

Hablando en un tema posteado hace poco en el área de blogs y hablando con una persona me he encontrado con ciertas recomendaciones a cerca de cómo se trabaja en la empresa en la que estoy. Estamos utilizando Struts 1.3.8 (si ya sé que es muy viejo) y cómo me gustaría actualizar un proyecto para minimizar la configuración xml y poder ser más productivo; hacer cambios más rápido de lo que se acostumbra, etc. Todo con fin de mejorar.

Entre las opciones he visto Play! que lo he utilizado para otros proyectos y es muy muy rápido, limpio y simple. Por otra parte está también Roo de Spring, el cual me pareció bastante bueno, aunque considero debería ser agnóstico con su librería javascript. También vi AribaWeb, el cual tiene un único gran problema y es su documentación. En otra parte veo alternativas cómo Wicket, que desde mi punto de vista su debilidad es la creación de la GUI (una en HTML y otra en Java). Sé que muchos de ustedes utilizan JavaServer Faces o algún derivado (e.j. IceFaces).

Me encantaría ver que ventajas o desventajas tienen los frameworks que utilizan contra los que yo ya conozco. Si conocen un framework de algún lenguaje diferente de Java, pero tiene ventajas también estaría bueno comentarlo =).

Gracias por adelantado.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de benek

Alternativas

ICEfaces no es un derivado de JSF, más bien es un framework que extiende la funcionalidad de JSF, principalmente sus componentes para agregar funcionalidad AJAX. El mismo caso es con Woodstock, Richfaces y Primefaces.

Sobre mencionar alternativas, hay muchas y creo que nadie podrá decir cuál es la mejor de todas (ni si existe una mejor que todas), todas tienen sus pros y contras. Aquí te van las que podría mencionarte yo:

JSF

Si lo que buscas es "lo más ocupado en la industria" sin duda ése es JSF, aunque no sea lo más innovador ni lo ideal para todos los casos pero no deja de ser opción. La versión 2 soluciona muchos de los problemas que le quitaron un poco de prestige a JSF 1, aparte de que la v2 evita la XMLitis que traía la v1 al configurarse vía anotaciones. Una ventaja también es que hay varios frameworks o bibliotecas de componentes que te facilitarán la vida, como Richfaces (que de todos es el que más me agrada). Si tu aplicación es muy "enterprise" puedes utilizar Weld para integrar JSF con persistencia, EJBs, inyección de dependencias y más. El desarrollo en JSF no es tan rápido.

Tapestry 5

Aquí ezamudio te sabrá decir más a detalle, pero Tapestry es muy buena opción si no hay problema en aceptar la curva que implica. Es un framework orientado al developer, por lo tanto tiene características que aumentan la productividad. Una de ellas es el live-class-reloading que ya quisiéramos en todos los frameworks, significa que no tienes que detener el servidor o hacer redeploy cuando haces algún cambio en las clases de los componentes (páginas), toma los cambios en caliente ayudándose de Javassist. La navegación también se torna muy sencilla, los llamados de una página a otra son simples invocaciones a métodos y la página siguiente a mostrar depende solamente del valor de return del método que llamaste, nada de andar configurando reglas de navegación en XML. Tapestry 5 es orientado a componentes reutilizables. Vi que publicaste (creo que sí fuiste tú) que no te gustó de Wicket el hecho de programar un HTML y una clase para conformar una página, esto aplica también para Tapestry.

Grails

Este lo menciono porque personalmente me gustaría aprenderlo, aunque la curva es un poco más larga aún ya que implica también la "curva" del lenguaje Groovy. Se parece a Spring Roo en el hecho de que generas un proyecto en consola, luego sus entidades, etc... Vale la pena explorarlo. A ver si alguien puede extender el comentario sobre este framework.

Vaadin

Este framework me llamó bastante la atención desde el post que publicó ezamudio. Está basado en GWT el cuál alguna vez utilicé pero no me agradó la separación que hace para las clases "client" y "server", además que de GWT no me agrada tanto la GUI. Vaadin no hace esta separación y además extiende los componentes gráficos. La gran ventaja que hereda Vaadin de GWT es que TODO se programa en Java, no tienes que hablarte con HTML, JavaScript ni pelearte con pasar los datos de entrada a los objetos y viceversa. Esto disminuye la complejidad (¿o latosidad?) y agiliza bastante el desarrollo al estar codificando siempre dentro de Java.

Esos son los que puedo mencionar, valdría la pena también leer algún comentario sobre Spring MVC.

Saludos.

@_benek

Imagen de luxspes

La mejor alternativa a Struts 1.x? Pues depende...

La mejor alternativa a Struts 1.x? Pues Struts 2.x! Ya en serio, creo que depende de tus requerimientos, en mi opinion, la mayoria de los frameworks que prometen mucho en el corto plazo acaban resultando dolorosos en el largo plazo cuando empiezas a hacer cosas complejas... yo en tu caso me iria por Struts 2, y si no por algo que me de un fundamento solido, pero simple, como Spring-MVC, Weld, y quiza algo de ayuda de algo como DWR.

Por supuesto, las recomendaciones pueden estar mejor orientadas si platicas un mas de lo que hace tu aplicacion... si es por ejemplo, algo muy interactivo, podria convenirte usar algo como OpenLaszlo, o una integracion Cappuchinno+DWR+Spring, o algo mas... todo depende de tu aplicacion.... tal vez te convenga mas Spring+BlazeDS o GraniteDS rehacer tu UI en Flex... no tenemos forma de saber... por que no nos cuentas?

Si el proposito de tu aplicacion es confidencial, tal vez podrias platicar sobre que es lo que menos te ha gustado de Struts 1.x, al estilos de "cuando quiero hacer X en Strutus 1.x tengo que hacer todo este rollo Q que es muy latoso". Y asi, los demas podemos platicarte sobre como hacemos X mas facilmente con otra herramienta... (tambien es posible que cuando leas las respuestas, te des cuenta de que en realidad los demas frameworks no son tan aplastantemente superiores como a veces parecen cuando sus autores los presumen bajo situaciones artificiales)

@Todos

No digo que me den el "framework definitivo", sólo que me expliquen ventajas o desventajas de los frameworks que conozcan; y ya según lo que me guste pueda decidir, pero no sin antes varias opiniones.

Imagen de ezamudio

precisamente

Pues a mi me parece que eso es precisamente lo que han hecho benek y luxspes: explicarte de varios frameworks.

Ya no sé cuáles agregar porque pues ya benek mencionó todos los que yo te diría... y también JSF. De Aribaweb ya dijiste que no te late la documentación. Otras opciones.... mm.... zk podría ser.

No sé por qué consideras que tener HTML y Java por separado es una desventaja. En el caso de Wicket y Tapestry, el objetivo de tener separado el código de la interfaz es que tienes tus clases Java que son puro código y por otra parte tienes el puro HTML con un mínimo de tags especiales para que funcionen con su respectivo framework; es finalmente separation of concerns y tiene sus ventajas, como que un diseñador no se espante de ver código en una página JSP o que le vaya a dar en la torre con el editor que usa; o que para cambiar algo en pura interfaz tengas que recompilar o moverle al código (intencionalmente o hasta por accidente).

Re: La mejor alternativa a Struts 1.x? Pues depende...

Estaba viendo Struts 2 y se me hizo más de lo mismo, algunas cosas cambian, pero algo que no me agradó para nada es que la interfaz podríamos decir que depende de Struts, cosa contraria en algunos otros frameworks que he utilizado (en donde no importa en qué corre back-end, sólo importa el sistema de templates que se utilizará). La manera en que se hacen las vistas es muy tediosa, aún más si le agregas que esa interfaz no la hiciste tú y otra cosa que no me gusta es que sea parcial y no fullstack, aunque eso te da más flexibilidad.

Otra es que hacer los cambios es todo un desafío en varias ocasiones o demasiado tedioso y ese creo es mi problema con Struts. Struts no es nada difícil pero es demasiado tedioso (dejaría de ser JavaEE).

Re: Alternativas

Muchas gracias por las respuestas Benek, estoy leyendo sobre Vaadin, ya que cómo me has dicho que JSF no es muy rápido pues queda descartado igual con Tapestry descartado por la razón de Wicket.

Imagen de luxspes

Recomendacion: Nos falta informacion

Estaba viendo Struts 2 y se me hizo más de lo mismo, algunas cosas cambian, pero algo que no me agradó para nada es que la interfaz podríamos decir que depende de Struts, cosa contraria en algunos otros frameworks que he utilizado (en donde no importa en qué corre back-end, sólo importa el sistema de templates que se utilizará)

En que frameworks no importa en qué corre back-end, sólo importa el sistema de templates que se utilizará? Nombres por favor... ;-)

La manera en que se hacen las vistas es muy tediosa, aún más si le agregas que esa interfaz no la hiciste tú

Comparada con...?

Otra es que hacer los cambios es todo un desafío en varias ocasiones o demasiado tedioso y ese creo es mi problema con Struts.

De nuevo... comparado con?

Struts no es nada difícil pero es demasiado tedioso (dejaría de ser JavaEE).

Bueno, de hecho, Struts nunca fue parte de JavaEE, (que yo sepa, no es parte de ningun JSR oficial).

Tal ves la razon por la que no podemos ayudarte mejor es por que no entendemos que buscas... quiza si nos platicaras acerca de lo que te molesta mas de Struts 1.x, con algunos ejemplos concretos... o si nos dijeras que tipo de funcionalidad o caracteristica es la que a ti mas te interesa... y nos presentaras como una especie de matriz con por un lado las caracteristicas y por otro lado el nombre del framework (o quiza mediante un mapa de ideas de los que se puede construir con Compendium)

Lo unico que sabemos, basados en tus post, es que ya te hartaste de Struts 1.x, pero necesitamos mas datos para saber que tipo de framework te convendria mas para la siguiente version de tu aplicacion... por que no nos cuentas tus problemas con Struts 1.x? quiza con blog post estilo "Un dia en la vida de un desarrollador de Struts 1.x" y nos cuentas todas las cosas que te han causado dolores de cabeza...

Imagen de luxspes

@Ti

No digo que me den el "framework definitivo", sólo que me expliquen ventajas o desventajas de los frameworks que conozcan; y ya según lo que me guste pueda decidir, pero no sin antes varias opiniones.

Me parece un metodo poco eficiente, es como intentar atinarle a un blanco con los ojos cerrados (y sin saber siquiera si estamos apuntando en la direccion general correcta). Por que no mejor tu nos de lo que no te gusta de Struts 1.x, lo que mas te molesta, lo que consideras insoportable, y entonces nosotros te ofrecemos soluciones enfocadas a tus problemas?

Re: precisamente

Pues no se me hace que (en Wicket, no he usado/visto Tapestry) exista dicha separación. A lo que voy, no me parece eso de:
 
Y después de eso definirlo en Java:
 
Siento que defino la GUI 2 veces, lo que no me hace sentir HTML separado de Java, de hecho se me hace cómo HTML junto (pero no revuelto) con Java. En lugar de algo cómo:
 
Y en html:
 
Sin necesidad de algo cómo estar a cada etiqueta una declaración Java, siento que la manera de Wicket es más rígida y que la forma que puse es más flexible. Lejos estoy de querer regresar a páginas jsp.

Bueno pues ya vi Vaadin y es algo interesante, no digo que rápido pero si interesante (para poder decir esto tendría que usarlo). Y estoy viendo los ejemplos de ZK, parece muy interesante también.

Imagen de benek

Contenido dinámico.

La idea es que en el template definas la estructura del contenido, y en el caso de Tapestry (y seguramente también en Wicket) cuando pasa por esa zona "XD" va al bean a obtener el contenido que debe ir ahí, dinámicamente.

Quizá no le veas mucho sentido porque en el ejemplo que pones (que seguramente es similar al que viene en la documentación de ejemplo) solo pones una cadena, y por qué no mejor ponerla en el template no? Bueno pues es solo un ejemplo, las posibilidades van más allá, el hecho de ir al bean por ese contenido ya te abre la posibilidad de traerte cosas de una BD o de un servicio, de un cálculo o de otro lado.

Resumiendo, el template define la estructura y el bean obtiene los datos en base a operaciones.

Saludos.

@_benek

Imagen de ezamudio

tapestry

mmm no recuerdo si hay labels en Tapestry, porque simplemente puedes usar expresiones tipo JSTL y poner ${bean.valor} para que se imprima eso. Lo del if sí es un poco similar:

 

Si quieres ver un poco más de Tapestry, escribí algunas cosas en mi blog:

Introducción histórica (si tienes mucha prisa te puedes saltar esto)
Introducción funcional (aquí puedes echarle un ojo rápido)
Componentes/inyección de dependencias/internacionalización (aquí ya se pone interesante)
Sesiones, validaciones, integración con AJAX (también interesante la manera en que se maneja esto en T5)

Re: Contenido dinámico

Igual con el ejemplo que puse, puede ir todavía más allá. Los rendering pueden ser desde cadenas hasta JSON; de igual manera en el ejemplo que puse (si te fijas) me traje algo de BD y pudo ser de igual forma de un cálculo, etc. Pero sin la necesidad de definir la etiqueta 2 veces.

Re: tapestry

De ser así entonces está mejor que Wicket, otra cosa que me dicen que son malas de Wicket es que todo tiene que llevar sesión y que las URLs por default son horribles. Mucha gente me ha recomendado Tapestry. De momento Vaadin atrapó mi atención fuertemente, pero también le daré una leída a las ligas que me has dejado.

Imagen de ezamudio

etiqueta 2 veces

Eso de tener que definir 2 veces la etiqueta no está padre. No lo había visto, lo que recuerdo haber leído de Wicket me hizo pensar que era muy parecido a Tapestry, pero esa duplicidad de declaraciones no me gusta (y es algo que no tiene T5). De Tapestry puedes ver como ejemplo funcional lo que llevamos de JavaMexico 2.0

Re:Recomendacion: Nos falta información

Tu sabes esos dolores de cabeza cómo que cambias un tile y tienes todo un relajo en la aplicación. O que por ejemplo hay cosas que es muy tedioso hacer; y eso que sea de acción y "de componentes" tampoco me agrada. La configuración XML también me molesta, me desespera.
Hacer cambios es algo lentísimo dónde tienes que brincar de tile en tile o de acción en acción, para encontrar el origen del error. Y ya no quiero hablar de cosas frustrantes (que lo admito, estoy frustrado con Struts), no es aceptable que a pesar de trabajar 12 hrs (a veces más) diarias quedes mal con el cliente por tiempos.

Con lo del back-end, pues un ejemplo es Play!, otro ejemplo es Rails. En donde la interfaz no depende del framework, de hecho es html común y corriente con alguna template, que si lo mueves de back-end puedes dejar ese front-end haciendo cambios únicamente en las templates, con lo que te quitas completamente el problema ese del: Developer vs Designer.

Imagen de luxspes

Una analisis detallado seria un excelente aporte

Tu sabes esos dolores de cabeza cómo que cambias un tile y tienes todo un relajo en la aplicación.

Exactamente que relajo, platica un ejemplo (en casi cualquier framework, cambias un componente de interfaz no trivial, y se te arma un relajo)

O que por ejemplo hay cosas que es muy tedioso hacer;

Si, Struts es famoso por eso, pero seria bueno que nos comentaras un ejemplo... (especialmente, si eso que es tedioso hacer en Struts 1 no lo resuelve Struts 2)

y eso que sea de acción y "de componentes" tampoco me agrada.

Bueno... eso ya se vuelve mas bien filosofico y subjetivo...

La configuración XML también me molesta, me desespera.

Bueno, en Struts 2 disminuye la cantidad de configuracion de forma significativa... igual podrias presentar un ejemplo de algo que siga siendo engorroso en Struts 2... y que no lo sea en Play o en RoR o en Ariba (pero por favor un ejemplo complejo, por que muchas demos de estos productos son engañosas, parece que simplifican, pero en realidad solo para casos muy particulares y en la practica real las cosas acaban siendo igual o mas complejas)

Hacer cambios es algo lentísimo dónde tienes que brincar de tile en tile o de acción en acción, para encontrar el origen del error.

Y en que te basas para crer que en Play! o en Rails no lo sera? Ten mucho cuidado, por que a veces parece que es mas facil con estas soluciones, pero es solo por que lo has hecho con ellas es chiquito (y en cuanto crece, te das cuenta que la mejora no es tan grande como parecia al principio)

Y ya no quiero hablar de cosas frustrantes (que lo admito, estoy frustrado con Struts), no es aceptable que a pesar de trabajar 12 hrs (a veces más) diarias quedes mal con el cliente por tiempos.

Lastima, creo que serian aportes muy interesantes, (un verdadero estudio comparativo entre Struts 1 y Struts 2 y luego vs Play o vs RoR o Ariba, con casos complejos y no los tipicos ejemplos engañosos y simplistas que uno suele encontrar seria un excelente aporte en esta comunidad)

Imagen de luxspes

Otra opcion: GWT

Y ya probaste GWT; desde que google compro a Instantiations, las herramientas visuales para diseñar tu UI se ven muy interesantes (y son Gratis!).

Imagen de iberck

Tapestry5 VS JSF2

Hola @wishmaster77

Tal vez te sea de mucha ayuda y te aclare un poco el panorama la siguiente presentación en donde hacen una comparativa muy apegada a la realidad entre Tapestry5 y JSF2, en ella explica la diferencia entre ambos y te puedes empezar a dar una idea de cómo trabajar con Tapestry5.
Ya que conoces struts1.x, al mismo tiempo que ves la presentación puedes ir comparando cómo hacias las cosas con struts 1.x y cómo podrías hacerlas con Tapestry5



Re:Tapestry5 VS JSF2

En cuanto tenga tiempo lo veo =), gracias.

Re: Un análisis detallado sería un excelente aporte

Bueno cómo he comentado anteriormente en hablo en base a mi experiencia. Con Play! por ejemplo, ya había hecho un proyecto grande, bastante interesante y parecido al que estoy llevando a cabo. Y también cómo he dicho en comentarios anteriores vengo de RoR. No es que crea que son más rápidos, lo sé ;), son más productivos y sencillos, son más limpios. Existe una separación bastante aceptable M de V de C, además que (para este proyecto que estoy llevando) veo que el principio convention over configuration es mucho mejor.

En si el proyecto tiene que autenticar usuarios, los cuales suben ciertos documentos de su empresa. Sin embargo se restringe el acceso (documentos por área a la que pertenece dicho usuario). Así cómo manejo de reuniones de dicha área (o empleado). Entre otras cosas cómo guardar plantillas de correo. A muy groso modo.

Con struts 2, pues no me llama la atención, lo que he visto es más de lo mismo, pero con menos configuración. Dirían los gringos: "Is not a big deal".

GWT, probé un poco; pero gracias a @Benek conocí Vaadin el cual me gustó más que GWT. La única cosa de Vaadin que no me gusta es que no es fullstack.

pregunta

una pregunta wishmaster, lo que dices de vaadin ¿a que te refieres a que no es fullstack?

Imagen de ezamudio

Vaadin !fullstack

Un framework fullstack se encarga de absolutamente todas las capas: persistencia, control, vista, etc. O sea que todo lo haces dentro del mismo framework. Vaadin solamente es un framework para la capa de vista y control (principalmente vista). No viene nada para persistencia. Esto es algo que muchos vemos como una ventaja porque significa que puedes usar Vaadin (o cualquier otro framework que sea de pura vista) con Hibernate o con JPA o JDO o JDBC puro o Spring JDBC o algun otro ORM o una mezcla de todo lo anterior. Pero algunos quieren tener un framework fullstack, o sea que se encargue de todo. Hoy en día muchos frameworks fullstack realmente usan para persistencia alguno de los existentes (como Hibernate) pero ya vienen facilidades para utilizar ese ORM en particular.

Re: pregunta

Ya te lo ha contestado @ezamudio. Y a pesar de las desventajas que @ezamudio mencionó existen otras ventajas, cómo lo son:
Todo integrado.
Aprender 1 framework en lugar de 3 o 4.
Estructura adecuada para dicho framework.

Claro que esto te resta flexibilidad.