Apache Wicket vs Apache Click

41

Click se desarrolla activamente y se ha graduado recientemente como un proyecto de nivel superior de Apache. Actualmente se está moviendo a su nuevo dominio en: http://click.apache.org. Una vez que se completa la migración, se lanzará la próxima versión, 2.1.0.

Antes de comparar Click y Wicket, tenga en cuenta que soy un committer en Apache Click, pero he evaluado Wicket hace un par de años, así que tengo una idea bastante buena de cómo funciona.

Haga clic en es un marco sin estado, mientras que Wicket es con estado. En Click, las páginas y los componentes se vuelven a crear en cada solicitud, en Wicket las páginas y los componentes se almacenan en la sesión y se reutilizan en las solicitudes posteriores.

Wicket está diseñado para crear aplicaciones complejas (Think Desktop), donde todo el estado de la GUI se almacena y administra. Haga clic en para las aplicaciones web más tradicionales donde se necesita poco o ningún estado para representar una página. Si necesita almacenar el estado, debe hacerlo usted mismo agregándolo/quitándolo de la sesión. Vale la pena mencionar que Wicket brinda soporte para páginas sin estado y Click admite páginas con estado, sin embargo, esta no es la norma para estos frameworks.

Otra diferencia es que en los controles de clic sabe cómo renderizarse, por lo que no tiene que repetir el marcado en las plantillas de página. Aún puede distribuir manualmente sus plantillas si lo desea, pero no es estrictamente necesario. En Wicket, el marcado debe reflejar los componentes creados en la página. La idea en Wicket es que el desarrollador de Java en realidad no crea ni mantiene las plantillas, sino que este es manejado por un diseñador.

Saludos cordiales

Bob

Fuente

2010-02-01 10:32:25

+4

+1: Buena respuesta equilibrada. Ambos tienen puntos fuertes, y tú lo capturaste bien. –

+1

Wicket no es necesariamente con estado. De forma predeterminada, las aplicaciones de wicket web son apátridas y wicket solo cambia al modo stateful cuando es necesario. Siempre que use cuidadosamente componentes sin estado en sus páginas web (por ejemplo, org.apache.wicket.markup.html.form.StatelessForm), su aplicación permanecerá sin estado. También puede agregar un StatelessChecker a su aplicación para aplicar statelessnes. El verificador arrojará una excepción sobre el componente con estado ofensivo, vea mi otra publicación cómo configurarlo si es necesario. –

2

Con portillo que usar HTML puro y sin lenguaje de plantillas como la velocidad o JSP como lo hace clic. Esto no solo es útil para el programador mismo, que solo debe aprender html y java, sino también para las herramientas (depuración, etc.)

Implica una mejor separación de la interfaz de usuario y la lógica. Tampoco se requiere xml en wicket, que en mi humilde opinión es diferente al hacer clic.

Algunas otras diferencias: el tráfico de la lista de distribución de wicket es mayor; hay más publicaciones (por ejemplo, libros) en wicket y luego en clic; hay más desarrolladores que codifican wicket (mira this y this)

Fuente

2010-02-10 10:15:54 Karussell

+2

Sí, y Wicket construido con ~ 850,000 líneas de código, mientras que Click contiene solo ~ 50,000 líneas de códigos. Eso debería decir algo sobre la complejidad también. Con respecto a esta información, Click es MUCHO MÁS simple. – Palesz

2

Wicket ofrece más flexibilidad sobre cómo redactas tus páginas. Puede crear una sola página compuesta de componentes para toda la aplicación, o puede crear varias páginas como desee. Click está basado en la página. Wicket tiene soporte para ajax fuera de la caja. La mayoría de los componentes de Ajax en Wicket caen nuevamente a la actualización normal de la página en caso de que el navegador no admita ajax. Wicket tiene docenas de componentes listos para usar y docenas de otros proyectos relacionados. Una gran característica que encuentro en wicket es su verbosidad. Eso significa que todo lo que hace mi aplicación es lo que creé. Escribo la presentación completa con html y css sin generar nada. La falta de magia es una gran ventaja para mí por experiencia. Por último y menos, muchas grandes corporaciones están usando wicket. Walmat mobile y wellsfargo mobile están hechos con wicket.

Fuente

2010-09-22 15:13:38 joshua

+0

"Eso significa que todo lo que hace mi aplicación es lo que creé". No, significa que todo lo que hace en el html debe hacerlo en una página wicket. Nada es más frustrante que tener problemas para encontrar el elemento html que está asociado con un componente determinado o viceversa. mantener el código y el marcado sincronizados es una pesadilla de mantenimiento. – Gilberto

1

la mayor desventaja de wicket es su naturaleza statefull. Puede ser difícil probar la unidad y depurar problemas de estado.su naturaleza de estado significa que usa más memoria y podría afectar su presupuesto de hardware. un efecto secundario de la naturaleza con estado de wicket significa que necesita poder guardar ese estado de vez en cuando. para hacer eso, todos tus objetos deben ser serializables.

Acabo de empezar a buscar en el clic. amo su naturaleza sin estado. la web es solicitud/respuesta, que debe ser sin estado (al menos tanto como sea posible).

también me gusta cómo se integra bien el clic con apache cayanne.

Fuente

2010-10-27 18:49:01 clarson

+5

Una naturaleza con estado ya no es un inconveniente si necesita estado. –

+3

No creo que eso sea siempre cierto. un buen desarrollador en una pequeña aplicación web probablemente no tenga muchos problemas tratando de mantener un estado complejo en una pequeña aplicación web. Si tuviera un proyecto grande (más de 10 desarrolladores) para construir, definitivamente me inclinaría hacia una solución sin estado. Es mucho más fácil de construir, probar, depurar y mantener. – clarson

+0

Con cuidado puede usar wicket para construir aplicaciones web sin estado. He escrito una tienda en línea sin estado con wicket. Ver mis otras publicaciones cómo hacer cumplir la apatridia. –

Respuesta

Cuestiones relacionadas