| At line 1 added 33 lines |
| [Wicket|http://wicket.sourceforge.net/] 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|http://wicket.sourceforge.net/ExampleNavomatic.html]: |
| {{{ |
| <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|TemplateValidity], even by means of an internal subset. Wicket, on the other hand, adds [quite a few|http://www.wicket-wiki.org.uk/wiki/index.php/Tags] 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 |
|
| * __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|http://www.wicket-wiki.org.uk/wiki/index.php/Spring], 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|RequestScopeBeans], 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] |
