Diferencia entre Apache Tapestry y Apache Wicket

Question

Apache Wicket ( http://wicket.apache.org/ ) y Apache Tapestry ( http://wicket.apache.org/ ) son ambos marcos web orientados a componentes s - contrario a marcos basados ??en acciones como Stripes, de la Fundación Apache. Ambos le permiten construir su aplicación a partir de componentes en Java. Ambos se parecen mucho a mí .

¿Cuáles son las diferencias entre esos dos marcos? ¿Alguien tiene experiencia en ambos? Específicamente:

• ¿Cómo es su rendimiento, cuánto se puede personalizar el manejo del estado, se pueden usar sin estado ?
• ¿Cuál es la diferencia en su modelo de componente?
• ¿Qué elegirías para qué aplicaciones?
• ¿Cómo se integran con Guice, Spring, JSR 299?

Editar : he leído la documentación de ambos y he usado ambos. Las preguntas no pueden responderse lo suficiente al leer la documentación, sino a partir de la experiencia de usarlas durante algún tiempo, p. cómo usar Wicket en modo sin estado para sitios de alto rendimiento. Gracias.

Answer 1

Algunas diferencias relevantes como las veo:

• Tapiz utiliza una página semiestática estructura, donde puedes trabajar con condicionales y bucles para lograr comportamiento dinámico Wicket es completamente dinámico puedes cargar componentes dinámicamente, reemplácelos en tiempo de ejecución, etc. Las consecuencias de esto es que Tapiz es más fácil de optimizar, y que Wicket es más flexible en su uso.
• Ambos marcos son aproximadamente igualmente eficientes en ejecución, pero Wicket confía en almacenamiento del lado del servidor (de forma predeterminada, el página actual en sesión y pasado páginas en un 'caché de segundo nivel' que es predeterminado un archivo temporal en el archivo sistema). Si eso te molesta, piensa acerca de cuántas sesiones concurrentes espera tener en las horas punta y calcular con decir ~ 100kb por sesión (que probablemente esté en el lado alto). Eso significa que puedes correr más o menos admite 20k sesiones simultáneas para 2GB. Di 15k porque necesitas eso memoria para otras cosas también. De Por supuesto, una desventaja de almacenar el estado es que solo funcionará bien con afinidad de sesión, así que eso es un limitación al usar Wicket. los El marco le proporciona un medio para implementar páginas sin estado, pero si estás desarrollando completamente apátrida aplicaciones que podría considerar un marco diferente.
• El objetivo de Wicket es soportar el tipeo estático en toda su extensión, mientras que Tapestry se trata más de guardar líneas de código. Entonces, con Tapestry, su base de código es probablemente más pequeña, lo que es bueno para el mantenimiento, y con Wicket, está mucho más tipado estáticamente, lo que facilita la navegación con un IDE y la verificación con un compilador, que también es bueno para el mantenimiento. Algo que decir para ambos imho.

He leído algunas veces que la gente piensa que Wicket funciona mucho a través de la herencia. Me gustaría enfatizar que tienes una opción. Hay una jerarquía de componentes, pero Wicket también admite la composición a través de construcciones como IBehavior (además de las cuales, por ejemplo, se construye el soporte Ajax de Wicket). Además de eso, tiene cosas como convertidores y validadores, que agrega a los componentes, globalmente, o incluso como una preocupación transversal utilizando algunos de los oyentes de fase que proporciona Wicket.

Answer 2

REVISADO después de estudiar Tapiz 5.

El

objetivo de Wicket es un intento de hacer que el desarrollo web sea similar a la GUI de escritorio . Lograron hacerlo realmente bien a expensas del uso de memoria (HTTPSession).

El

objetivo de Tapestry 5 es hacer que esté muy optimizado (para CPU y memoria) marco web orientado a componentes.

El gran obstáculo para mí fueron las respuestas "¡Wicket admite componentes sin estado!" a los argumentos "Wicket tiene hambre de memoria". Si bien Wicket admite componentes sin estado, no son "un foco de desarrollo de Wicket". Por ejemplo, un error en StatelessForm no se solucionó durante mucho tiempo; consulte StatelessForm: problema con los parámetros después de que la validación falla .

• En mi humilde opinión, usar Wicket es un poco fácil hasta que va a optimizar / ajustar los parámetros de la aplicación web
• IMHO Wicket es más difícil de estudiar si ha programado aplicaciones web y quiere pensar en términos de procesamiento de solicitudes
• Tapestry 5 automáticamente recarga clases de componentes tan pronto como las cambie. Ambos marcos recargan el marcado de componentes.
• Wicket obliga a marcado / separación de código , Tapestry 5 solo te da esta habilidad. También puede usar una sintaxis menos detallada en Tapestry 5. Como siempre, esta libertad requiere más precauciones.
• El núcleo de Wicket es más fácil de depurar: los componentes del usuario se basan en la herencia, mientras que los componentes del usuario de Tapestry 5 se basan en anotaciones. Desde el otro lado, eso podría facilitar las transiciones a las versiones futuras para Tapestry y luego para Wicket.

Desafortunadamente Tutorial de Tapestry 5 no enfatiza ese ejemplo de código de Tapestry como 't : loop source = " 1..10 " ... 'puede ser una mala práctica. Por lo tanto, se debe poner un esfuerzo en escribir convenciones de uso de tapices / buenas prácticas si su equipo no es muy pequeño.

Mis recomendaciones :

• Use Wicket cuando la estructura de sus páginas sea muy dinámica y pueda permitirse el lujo de gastar 10-200 Kbs de memoria HttpSession por usuario (estos son números aproximados).
• Use Tapestry 5 en los casos en que necesite un uso más eficiente de los recursos

Answer 3

Aquí hay una comparación bastante exhaustiva de Developer Works de IBM.

http://www.ibm .com / developerworks / java / library / os-tapestrywicket / index.html? ca = drs

Actualización: el enlace está muerto, pero puede encontrar la página en http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/ os-tapestrywicket / index.html? ca = drs

Answer 4

Creo que Wicket es un marco más simple de usar.

Además, Wicket permite la recarga de clases a través del sistema de reemplazo de código activo de su IDE. Esto es todo lo que se requiere para que Wicket ejecute versiones modificadas de las clases de una aplicación actualmente en ejecución. Se aplican las restricciones habituales para el reemplazo de código activo, como tener que ejecutarse en modo de depuración (Eclipse) y no poder cambiar los aspectos estructurales de una clase (es decir, nombre de clase, cambio de firmas de métodos, etc.).

Answer 5

No me gusta el modelo de programación Tapestry y sé de muchos desarrolladores que abandonan Tapestry debido a demasiados cambios e incompatibilidades en el desarrollo. Ver: http: //ptrthomas.wordpress .com / 2009/09/14 / perfbench-update-tapestry-5-and-grails /

Answer 6

Wicket es un muy buen marco web. Lo mejor de todo lo que sé. Lo uso desde la versión 1.3 y siempre obtengo lo que quiero. Wicket tiene una excelente integración con Spring: solo use la anotación @SpringBean en su código para inyectar cualquier bean Spring en sus clases.

Answer 7

Pruebe http://incubator.apache.org/click/ . Es increíble marco web java. Algunas personas lo llaman & # 8220; Wicket hecho a la derecha & # 8221; ;-)

Answer 8

Como dije cuando 4.1 era la versión estable oficial:

Debe echar un vistazo muy bueno al historial de desarrollo de Tapestry antes de comprometerse a usarlo. Tapestry ha realizado muchas actualizaciones no compatibles, sin la continuación del soporte de versiones anteriores. Los parches a 4.1 ya no se procesan dentro de un plazo razonable. En mi opinión, eso no es aceptable para la versión estable oficial.

Comprometerse a usar Tapestry 5 significa:

deberías convertirte en un committer; necesita mantenerse al día con todos los nuevos desarrollos, abandonar las versiones antiguas lo más rápido posible; mantenga versiones estables usted mismo.