Set your name in
Wicket is a pretty good framework. It's the first "other" framework to have a templating system, like RSF, driven largely by pure HTML. In fact, when I saw it first, it was quite uncanny - for rsf:id read wicket:id! However, its template system is not quite as "orthogonal" as IKAT, since you define "components" (a sort of thing which doesn't exist in the same form in RSF) with a different syntax with which you declare content.
Here is a section from a Wicket "component" definition:
<wicket:link> <a href = "Page1.html">Page1</a><br/> <a href = "Page2.html">Page2</a><br/> <a href = "Page3.html">Page3</a> </wicket:link>As you can see, it is very nearly HTML (at least it is valid XML, unlike the inputs to many low-order templating systems), but not quite - the wicket tag is not valid and you will fail to preview this definition in some browsers. Since RSF adds only one ID attribute to XHTML, it is much easier to recreate a valid DTD, even by means of an internal subset. Wicket, on the other hand, adds quite a few extra tags into its target schema. However, the Wicket "border" system is quite neat, and is something that currently has no direct equivalent in RSF - this will probably need a kind of id or attribute called return-here, to guide IKAT resolution back from being redirected to a border definition.
Wicket templating is far and away better than anything else out there.
Wicket's more serious failings are that it is
Yes wicket uses server state, but you can go around it by using stateless pages (pages with now call backs just bookmarkable urls) But then you just create a lot of garbage because every request will recreate your structure caching these things in the session isn't such a bad thing many people thing it is. There are so many struts/model 2 apps that are using adhoc session things. And those will grow and grow. Seen many with more then a 1M session state. Wicket controll the usage for you. You can keep it very light with detachable models. Also in 2.0 we already have a few different strategies.. One is clientside state but i really don't like this myself. This is much worse in bandwith and cpu power to serialize and deserialize everything and send it over the line.
About IoC: First of all yes it is a unmanaged framework. But that does just mean that you can do anything you want! you can make it managed if you want! for example just use the page factory to create pages.. But most people don't like this. So we thought about a much better integration for example with spring by just using the new keyword of java and still use IoC.. See the wicket-spring support for this.
"Wicket components (the controller layer) are ..." - this is of course completely wrong. Wicket components are not just the controller, each component represents the entire MVC pattern - that is each component has its own data (state), processes its own events, and produces its own output. This is the bases of component oriented frameworks.
Thanks for the reponses. I don't have too much to say without fear of repetition - just to reiterate the point that I feel "O-O" as it was presented in the traditional 90s formulation (i.e. "behaviour with state") is a less primary and less powerful abstraction in development than proper management of dependency as it as facilitated by "IoC" frameworks such as Spring. To be quite clear I am not saying that "O-O" is "bad", just that it is not always appropriate. I enclose the link to the "TheServerSide" discussion of the 0.6.1 release so people who are interested can follow the discussion between the Wicket developers and me: http://www.theserverside.com/news/thread.tss?thread_id=40127#207290