Wicket

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>

Wicket templating is far and away better than anything else out there.

Wicket's more serious failings are that it is

• Server-heavy - Wicket components (the controller layer) are "heavy" in that they have both behaviour and state, and are not "beans" in the way RSF components are. Wicket is at the moment *extremely* dependent on session state and cannot function without it - steps are underway to remedy this in future releases, but it will always suffer that this state needs to be put somewhere - if stashed on the client it would be quite a bulky blob, and what's more problematic, opaque to client logic. As for the model layer, Wicket does support "detachable" models, but not "destructible" models in the way RSF does.
• Devoid of IoC - this is probably the most serious failing. By the developers' own admission, Wicket is an unmanaged framework, in that framework control passes away at the moment an object is constructed: "Wicket does not manage the lifecycle of its components. This means that a page or a component can be created anywhere in the code by simply using the new operator. This makes it difficult to inject dependencies because it is difficult to intercept the creation of the component.". Compared to RSF's powerful inheritance from being build upon Spring rather than simply integrating with it, as well as further considerable improvements from the ability to inject request-scope dependencies, Wicket applications will be awkward to configure and fragile

remarks (jcompager):

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.

remarks (ivaynberg):

"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.

comment (antranig):

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