Ccna final exam - java, php, javascript, ios, cshap all in one. This is a collaboratively edited question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
Monday, May 7, 2012
Apache Wicket vs Apache Click
What is the difference between Apache Wicket and Apache Click? Is Apache Click maintained? The latest release seems to be from Nov 2008 Thanks Achilleas
Click is actively developed and has recently graduated as an Apache Top Level Project. It is currently moving to its new domain at: http://click.apache.org. Once the migration is complete the next version, 2.1.0, will be released.
Before comparing Click and Wicket do note that I am a committer at Apache Click but have evaluated Wicket a couple of years ago so have a fairly good idea of how it works.
Click is a stateless framework while Wicket is stateful. In Click, pages and components are recreated each request, in Wicket the pages and components are stored in the session and reused in subsequent requests.
Wicket is meant for building complex applications (think desktop), where all the GUI state is stored and managed for you. Click is meant for the more traditional web applications where little to no state is necessary to render a page. If you need to store state you have to manage it yourself by adding/removing it from the session. Its worth mentioning that Wicket provides support for stateless pages and Click supports stateful pages, however this isn't the norm for these frameworks.
Another difference is that in Click controls knows how to render themselves, so you don't have to repeat the markup in your page templates. You can still manually layout your templates if you want, but it is not strictly necessary. In Wicket the markup needs to reflect the components created in the page. The idea in Wicket is that the Java developer doesn't actually create or maintain the templates, instead this is handled by a designer.
the biggest drawback to wicket is its statefull nature. It can be difficult to unit test and debug state issues. its statefull nature means it uses more memory, and could effect your hardware budget. a side effect of the stateful nature of wicket means that it needs to be able to save that state from time to time. to do that, all your objects need to be serializable.
i've just started looking at click. i love its stateless nature. the web is request/reply, which should be stateless ( at least as much as possible).
i also like how nicely click integrates with apache cayanne.
With wicket you use pure html and no template language as velocity or jsp like click does. This is not only handy for the programmer itself which only has to learn html and java, but also for the tooling (debugging etc)
It enforces a better separation of user interface and logic. There is also no xml required in wicket which is IMHO different to click.
Some more differences: wicket's mailing list traffic is higher; there are more publications (e.g. books) on wicket then on click; there are more developers coding wicket (look this and this)
Wicket offers more flexibility on how you compose your pages. You can create a single page composed of components for the entire application , or you can create multiple pages as you wish. Click is page based. Wicket has support for ajax out of the box. Most of the the ajax components in wicket fall back to normal page refresh in case the browser doesnt support ajax. Wicket has dozens of components out of the box and dozens of others from related projects. One great feature i find in wicket is its verbosity.. That means the everything my application does is what i created. I write the entire presentation with html and css with nothing being generated. Lack of magic is a big plus for me from experience. Last and least, many large corporations are using wicket. Walmat mobile and wellsfargo mobile are done with wicket.
Click is actively developed and has recently graduated as an Apache Top Level Project. It is currently moving to its new domain at: http://click.apache.org. Once the migration is complete the next version, 2.1.0, will be released.
ReplyDeleteBefore comparing Click and Wicket do note that I am a committer at Apache Click but have evaluated Wicket a couple of years ago so have a fairly good idea of how it works.
Click is a stateless framework while Wicket is stateful. In Click, pages and components are recreated each request, in Wicket the pages and components are stored in the session and reused in subsequent requests.
Wicket is meant for building complex applications (think desktop), where all the GUI state is stored and managed for you. Click is meant for the more traditional web applications where little to no state is necessary to render a page. If you need to store state you have to manage it yourself by adding/removing it from the session. Its worth mentioning that Wicket provides support for stateless pages and Click supports stateful pages, however this isn't the norm for these frameworks.
Another difference is that in Click controls knows how to render themselves, so you don't have to repeat the markup in your page templates. You can still manually layout your templates if you want, but it is not strictly necessary. In Wicket the markup needs to reflect the components created in the page. The idea in Wicket is that the Java developer doesn't actually create or maintain the templates, instead this is handled by a designer.
kind regards
Bob
the biggest drawback to wicket is its statefull nature. It can be difficult to unit test and debug state issues. its statefull nature means it uses more memory, and could effect your hardware budget. a side effect of the stateful nature of wicket means that it needs to be able to save that state from time to time. to do that, all your objects need to be serializable.
ReplyDeletei've just started looking at click. i love its stateless nature. the web is request/reply, which should be stateless ( at least as much as possible).
i also like how nicely click integrates with apache cayanne.
With wicket you use pure html and no template language as velocity or jsp like click does. This is not only handy for the programmer itself which only has to learn html and java, but also for the tooling (debugging etc)
ReplyDeleteIt enforces a better separation of user interface and logic. There is also no xml required in wicket which is IMHO different to click.
Some more differences: wicket's mailing list traffic is higher; there are more publications (e.g. books) on wicket then on click; there are more developers coding wicket (look this and this)
Wicket offers more flexibility on how you compose your pages. You can create a single page composed of components for the entire application , or you can create multiple pages as you wish. Click is page based. Wicket has support for ajax out of the box. Most of the the ajax components in wicket fall back to normal page refresh in case the browser doesnt support ajax. Wicket has dozens of components out of the box and dozens of others from related projects. One great feature i find in wicket is its verbosity.. That means the everything my application does is what i created. I write the entire presentation with html and css with nothing being generated. Lack of magic is a big plus for me from experience. Last and least, many large corporations are using wicket. Walmat mobile and wellsfargo mobile are done with wicket.
ReplyDeleteregards.
Josh