¿Está eligiendo un marco web Java ahora? [cerrado]

estamos en la etapa de planificación de la migración de un gran sitio web que se basa en un marco mvc desarrollado a medida a un marco web basado en java que proporciona soporte integrado para ajax, contenido multimedia enriquecido, mashup, diseño basado en plantillas, validación, máximo html / separación de código java. Grails parecía una buena opción, sin embargo, no queremos utilizar un lenguaje de programación. Queremos seguir usando java. El diseño basado en plantillas es una preocupación principal, ya que tenemos la intención de utilizar esta aplicación web con varios sitios web con una funcionalidad similar pero una apariencia y un estilo radicalmente diferentes.

¿La solución basada en portal se adapta bien a este problema?

Cualquier información sobre el uso de "Spring Roo" o "Play" será muy útil.

Encontré publicaciones similares como esta , pero tiene más de un año. ¡Las cosas seguramente han cambiado mientras tanto!

EDIT 1: ¡ Gracias por las excelentes respuestas! Este sitio se está convirtiendo en la mejor fuente de información para programadores en las trincheras. Sin embargo, esperaba más información sobre el uso de un dúo portal-cms. Jahia luce bien. ¿Algo similar?

¿La solución basada en portal se adapta bien a este problema?

Personalmente, me mantendría alejado de las grandes soluciones de Portal (a menudo son asesinos de la productividad). Sin embargo, he escuchado cosas buenas sobre Gatein, pero no tengo ninguna experiencia real con eso.

Cualquier información sobre el uso de "Spring Roo" o "Play" será muy útil.

Acerca de Spring Roo, he leído respuestas anteriores como Spring roo Vs (Wicket y Spring) y otras cosas en Internet, pero todavía no estoy convencido (tal vez no lo entiendo), no estoy seguro de su madurez Y, lo que es más importante, realmente me pregunto qué está haciendo SpringSource con Grails y Roo (no, Grails vs Roo, ¿por qué SpringSource está impulsando dos tecnologías muy similares? no me convence de que ambos sobrevivirán).

No puedo decir mucho sobre Play. He visto la demostración como todos, pero me gustaría leer comentarios de la vida real. Hasta entonces, esperaré.

Encontré publicaciones similares (...). ¡Las cosas seguramente han cambiado mientras tanto!

Sí y no :) Pero entremos en el infierno de los frameworks de presentación: no hay una respuesta única a tu pregunta (como hace un año), hay docenas de frameworks por ahí y no hay un ganador claro. Solo por citar algunos:

• JSF: Muchos escépticos sobre este marco basado en componentes, incluyéndome a mí, así que no soy el mejor para hablar de ello, pero ...
• JSF 2 (+ CDI / Weld): los escépticos de JSF son animados ( por Gavin King ) a "echar un segundo vistazo". De hecho, creo que JSF 2 es una gran mejora, especialmente con CDI, pero ... todavía es bastante nuevo (entiéndelo, carece de comentarios). Si quieres adoptar Java EE 6, échale un vistazo.
• Wicket: Otro marco basado en componentes que está recibiendo más atención. Escucho principalmente cosas buenas al respecto: más simple que JSF, diseño agradable, alta capacidad de prueba, amigable para el diseñador HTML, etc.
• Tapestry: Simplemente no lo hagas (consulta ¿Por qué dejaste de usar Tapestry? )
• Struts 2, Spring MVC, Stripes: marcos basados ​​en acciones. Todo decente y cubrirá sus necesidades (personalmente, me gusta Stripes y su convención sobre el enfoque de configuración, vea Stripes vs. Struts2 para tener una idea).
• GWT, Flex, Grails: Quizás no sea lo que estás buscando. Realmente no puedo hablar sobre (versiones recientes) de Flex y GWT, pero sé que Grails tiene algunos fanáticos .

En realidad, sugeriría echar un vistazo a las presentaciones de Matt Raible , realmente hizo un gran trabajo comparando marcos web, mostrando sus fortalezas y debilidades, recopilando datos y números, mostrando tendencias ... Recomiendo:

• Comparando JSF, Spring MVC, Stripes, Struts 2, Tapestry y Wicket (aún no obsoleto)
• Frameworks web del futuro: Flex, GWT, Rails y Grails (solo para probar las alternativas)
• Comparación de marcos web de Kick-Ass (este es el más reciente)

De verdad, echa un vistazo a estas presentaciones, te ayudarán a encontrar un marco adecuado (no hay una respuesta única pero puedes restringir la elección por eliminación) y podrían cambiar tu punto de vista.

He estado usando Spring 3 y Jquery por un tiempo, pero escuché sobre Play y lo intenté. Realmente me gusta, Play encaja perfectamente entre algo como PHP y los marcos de trabajo de Java de alta resistencia como Spring.

Las cosas que más me gustan del juego son:

• Es muy fácil hacer despegar una aplicación de juego, tienes que ir bastante lejos con la codificación y la configuración para obtener una aplicación simple en la pantalla con Spring (aunque Spring 3 lo ha hecho mucho más fácil).
• Spring Security es impresionante, pero tiene un costo de complejidad. El módulo de seguridad de Play es muy simple y cubre las necesidades de probablemente el 90% de las aplicaciones que existen.
• Puede hacer un cambio de código y presionar actualizar en el navegador para ver el cambio como con PHP en lugar de tener que hacer todo el redespliegue con marcos basados ​​en Servlet.
• Los mensajes de error se muestran de forma agradable y no tan crípticos la mayor parte del tiempo. Play todavía necesita trabajar en su manejo de errores
• Hay un mecanismo de complementos para Play que es bastante simple.
• La persistencia de objetos se hace muy bien porque una base de datos en memoria y JPA viene con el marco, por lo que no hay configuración de herramientas de persistencia de objetos externos. Pasar de la base de datos en memoria a un RDBMS real es un cambio de una línea en el archivo de configuración.
• La configuración de MVC está muy bien. La clase Model que amplía para crear sus objetos de dominio se integra con el administrador de entidades JPA. No son solo de POJO.
• La asignación de URL a los controladores es simple y flexible y todo en un archivo de "rutas".
• Siempre que crea un proyecto, Play maneja todas las dependencias de jar y Play tiene una utilidad para eclipsar (o cualquier IDE que desee) el proyecto para que se importe directamente a su IDE favorito.

Cosas que no me gustan de Play

• La documentación aún no está completa, todavía existen muchas características indocumentadas.
• El marco es el servidor, por lo que debe dedicar un puerto a cada aplicación. Creo que alguien está trabajando en un complemento de host virtual, pero aún no lo he visto en acción.
• Es joven, el proyecto es increíble y la tecnología es increíble, pero realmente necesita más desarrolladores. Me encantaría dedicarle un tiempo, ya veremos.

La mejor opción para mí es Wicket . Separación clara de marcado y código java. Componentes muy fáciles de escribir y usar. Fácil de usar Ajax, capacidad de prueba. Puede depurar directamente en sus páginas / componentes y no obtener mensajes de error crípticos de su implementación JSF;)

También hay un buen wicket de comparación <--> JSF en términos de rendimiento

Las tres opciones principales para mí son (alfabéticamente):

• JSF
• Primavera MVC
• Puntales 2

Ellos:

• tener un buen soporte ajax
• le permiten crear sitios web reales, no aplicaciones (como GWT)
• estable, bien documentado, ampliamente utilizado
• MVC
• Java puro
• fácil integración con Spring como middleware

Play es muy similar a ROR, una versión de ROR en java

En contraste con otras respuestas, me gustaría resaltar las desventajas (en mi humilde opinión) de los marcos web populares:

JSF2 : lanzado y ya envejecido. Aún quedan pocas noticias / artículos / publicaciones en blogs / experiencias. Soy escéptico Todavía esperando la próxima versión importante de Richfaces / Icefaces que sea totalmente compatible con jsf 2; actualmente solo se pueden descargar versiones alfa.

Struts 2 : parece ser solo algo bueno si todavía confía en struts y desea refactorizar la mayor parte de su código. De lo contrario: no lo hagas.

GWT - No me gusta el enfoque de una sola página y java-> javascript. No estoy seguro de si se puede lograr fácilmente una sesión: múltiples vistas / ventanas. Para mí, este marco debería usarse para aplicaciones de Internet ricas en una sola ventana para usuarios masivos.

Wicket - Buen enfoque, pero un poco detallado y muy poca documentación disponible (excepto el buen wicket en el libro de acción, pero esto cubre solo 1.3). Además, para mí carece de grandes proyectos que se construyan sobre él. Y actualmente no puedo ver hacia dónde se dirige el camino del portillo o si ya se ha llevado a un callejón sin salida.

Spring MVC : no probé esto todavía, pero debe incluir muchos frascos (desorden de primavera) en su ruta de clase para trabajar con este marco correctamente. Y se basa en JSP (en la mayoría de proyectos), que considero ya muerto. Y solo obtiene un marco MVC puro: todas las demás cosas (ajax y otras) deben implementarse / integrarse.

Stripes : un marco MVC pequeño y de bonito diseño, pero muy poca documentación, muy pocas confirmaciones / confirmaciones, muy pocas versiones, muy menos soporte de la industria, muy menos actividad en la lista de correo.

También tengo curiosidad si me perdí un marco importante (dejé Tapestry intencionalmente) que podría ser una opción para usted (y también para mí).

He tenido un gran éxito con JAX-RS . Es el único Java Web Framework que tiene algún tipo de especificación JSR y múltiples implementaciones además de la especificación de servlet y portlet (aunque esto puede ser algo malo).

Una cosa que es mala y buena de Java es que puede elegir y combinar marcos (Python también tiene esta característica / problema). Es bueno porque no tienes que poner todos los huevos en una canasta.

Aquí hay una receta general de pila de aplicaciones web Java:

Javascript / Flash + Gestión de solicitudes / respuestas + Inyección de dependencias + Persistencia

Javascript: JQuery, Prototype, Dojo

Solicitud / respuesta: Spring MVC, Stripes y mi JAX-RS favorito (Jersey, Apache CXF)

Inyección de dependencia: Spring, Guice

Persistencia: JPA (Hibernate, almacenamiento de aplicaciones de Google), Hibernate, JDO y más.

También he tenido un gran éxito en el uso de AspectJ para hacer que Java "apesta menos". Al usar los mixins de Spring's @Configurable y AspectJ's ITD, puede obtener Rails como objetos de dominio (esto es de hecho lo que hace Roo, pero no necesita que Roo lo haga).

Descubrí que las rayas son realmente efectivas y sorprendentemente livianas ... su objetivo es ser más liviano que los puntales . Escuché de amigos que son desarrolladores web a tiempo completo que no vale la pena molestarse con JSF, aunque no tengo experiencia de primera mano, y no puedo respaldar eso con ejemplos (!).

Eche un vistazo a RESThub , que sigue los mismos principios que Play! pero implementado reutilizando algunos marcos / herramientas de nivel empresarial como Maven 3 / Spring 3 / Jersey / jQuery.

RESThub es muy disruptivo en comparación con otros marcos, ya que es un conjunto de herramientas de pila completa, pero sin ningún MVC del lado del servidor o marcos basados ​​en servlets. En su lugar, usa una GUI basada en jQuery UI que usa servicios web JAX-RS (REST) ​​y un sistema de plantillas Javascript basado en embeddedJs.

Los servidores no tienen estado y usamos HTML5 sessionStorage para mantener la sesión en el lado del cliente. Este enfoque está diseñado para RIA y escalabilidad.

Se proporcionan algunas aplicaciones de demostración (incluso si están en construcción).

JSF es un buen framewrok, pero JSF 1.2 careció de visión durante años desde su lanzamiento. JSF 2.0 parece prometedor y tiene muchas cosas nuevas agregadas de JSF 1.2 como soporte ajax, facelets, soporte de anotaciones y convenciones predeterminadas (menos XML), compilación de componentes fácil que 1.2.

También se integra bien con Spring, si le preocupa el soporte DI.

Respaldaría la recomendación de Spring. No soy un gran fan de GWT, no creo que el compilador cruzado de Java -> Javascript esté listo todavía. Estoy trabajando en una aplicación AJAX que usa Spring en el servidor y jQuery en el cliente. Aunque técnicamente no hay soporte "listo para usar" para jQuery, implementar un Spring-MVC AjaxView es muy simple y tomó alrededor de 25 líneas de código.

Quizás un poco tarde para el show, pero tengo que mencionar a Vaadin . La programación se realiza exclusivamente en Java, con un enfoque basado en componentes. La comunicación cliente-servidor tiene más que ver con la interacción del usuario que con el transporte de datos, toda la lógica empresarial reside en el servidor.

Ext GWT + Resorte

Creo que lo que buscas es algo parecido a Jahia. Es compatible con GWT, Mashups, contenido multimedia, etc.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html

SOFTWARE DE PORTAL DE BACKBASE

Hace un par de años he utilizado el software de portal " Backbase ", que entonces no estaba muy maduro. Pero fue bueno y fácil de desarrollar.

Eche un vistazo a ItsNat

ItsNat es básicamente un navegador Java W3C en el servidor, sorprendentemente simple (DHTML en el servidor), que promueve aplicaciones de interfaz de página única intensivas en AJAX

Algo que merece algo más que una viñeta son los frameworks RIA basados ​​en jugadores. Ex. Adobe Flex + Java (Por supuesto, esto puede depender un poco de si su "sitio" es realmente un "sitio" o más como una "aplicación", no haría un sitio de blog en Flex).

ajax,

En el sentido de AJAX como palabra de moda, Flex generalmente usa AMF (un protocolo binario que es más eficiente que los protocolos usados ​​por las aplicaciones AJAX), aunque también puede hacer cosas estrictamente AJAX con Flex. Entonces Flex es compatible con AJAX, pero también es compatible con "mejor que AJAX".

contenido rich media, mashup,

Dado que Flex se ejecuta en la plataforma Flash de 'máquina virtual', creo que es necesario agregar poco.

diseño basado en plantillas,

No estoy seguro de a qué se dirige exactamente, pero suena como Flex mxml.

validación,

Compatible, por supuesto, aunque puede que decida hacer algunas cosas personalizadas si quiere ser elegante. (No es que tengas que hacerlo). Lo bueno es que puedes ser tan sofisticado como quieras, o no.

separación máxima de código html / java

No puede separarse más usando un enfoque de desarrollo de 'máquina virtual' como Flex / Silverlight / JavaFX. Esto no solo le permite mantener su código de presentación separado de la lógica del lado del servidor y la capa de acceso a los datos, sino que garantiza que estén separados. La 'virtualización' de su entorno de desarrollo le brinda compatibilidad entre navegadores, una plataforma de destino consistente, no se preocupe por nuevos navegadores o lanzamientos de navegadores que rompan su aplicación, capacidades de depuración de primera línea similares a las de Java y un producto final de apariencia más profesional / impresionante .