Nick Heudecker, founder of System Mobile, co-author of Hibernate Quickly, and respected Java developer, talks about the Wicket framework, its technology, how to quickly get into it, and how it compares against JSF in this TSS feature interview. (Click here if you can't view the video on this page.) Learn more about this topic from the Apache Wicket Incubator or join the discussion in the ##wicket IRC channel. Kito Mann spoke to TheServerSide video in favor of JSF at JavaOne. Kito's interview begins at 04'14". Watch other Tech Briefs

Everyone loves wicket. That part of interview with JavaDuke was funny :-)

I really do not get the comparison between JSF and Wicket. To me they address different spaces. All wicket does is gives you a way to put "code behind" HTML (and conceed that it does it pretty darn well). JSF is a component framework that is designed to go beyond HTML promising pre-built components allowing you to build presentations using XML (JSPX)and/or programatically in a manner similar to swing supporting a well defined restful server-side lifecycle.
Having said that I have to admit that if you are going to compare JSF's lame HTML components with Wicket then there is NO comparison. My comment to people has always been that if you are going to use JSF then you need to find a good set of components because JSF's HTML components will not get you far. Look at Oracle's new Rich Faces Component suite (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/enhanced-tagdoc.html) and you can see the promise of JSF.
But Wait you say, Wicket does have components and yes it does. Ah but for all of these new component frameworks. Problem is none of the emerging frameworks have a comprehensive suite of components; makes one long for one stable framework with a deep set of components; .NET maybe ... but I jest
Probally the best liked feature of all of these new frameworks is the fact that they eliminate JSP which by now the community has to admit is pure evil. It may be that JSP that is the devil in the JSF specification. I will say that I have delivered an entire application, built using ADF (or Trinidad) that nary used a stich of embedded HTML or JSF HTML components. Almost all JSF examples I tend to see have HTML embedded in them, a dead giveaway to a frustrated JSF developer (but I digress).
My point is not that JSF is better than Wicket but to compare the two is meaningless without context. Use Wicket if you want to remain grounded in HTML and the component suite suites your needs, it will get the job done ... but so will a good JSF implementation.

@Steven You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this. But more importantly, you make the assumption that JSF has an edge over Wicket because JSF has a selection of 3rd party component libraries. I wonder whether that is true for two reasons: * Wicket actually has quite lot of very high-quality components shipped with the core projects, and some of the wicket-stuff (which is a low barrier component projects repository) projects. It doesn't have all the components that say ADF has, but otoh, it has a couple that ADF doesn't have. I also believe the Wicket components are generally easier extendible so all the af:panelXX components are really moot. * Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.

@Steven

You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.

I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model. Either way, flex is great for gui construction and their mxml component model is awesome. I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year. Ilya

@Steven

You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.

I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model.

Either way, flex is great for gui construction and their mxml component model is awesome.

I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year.

Ilya

Wow, I've heard it all now. Justifying the use of the over-engineered, poorly designed, prematurely standardised, JCP endorsed JSF over something simple and to the point like Wicket by suggesting that JSF provides better support for Flex? What ever happened to keeping things simple? And if you want to use Flex then how about Webwork or Rails? Talk about being obsessed with your own (JCP) navel! Paul.

@Steven

You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.

I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model.

Either way, flex is great for gui construction and their mxml component model is awesome.

I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year.

Ilya

Wow,

I've heard it all now. Justifying the use of the over-engineered, poorly designed, prematurely standardised, JCP endorsed JSF over something simple and to the point like Wicket by suggesting that JSF provides better support for Flex?

What ever happened to keeping things simple? And if you want to use Flex then how about Webwork or Rails?

Talk about being obsessed with your own (JCP) navel!

Paul.

Dude, where in my post did you see a mention of JSF? I actually advocated no JSF and no Wicket, and simple REST/SOAP based back end that connects to the flex front end. Flex effectively replaces the component based server side frameworks, with a stateful component based client framework. Ilya

Either way, flex is great for gui construction and their mxml component model is awesome.

Sure. The project I'm working on currenly actually uses *both* Wicket and Flex for different parts of the application. Works great. The point I tried to make with my reply is that I don't believe in the way JSF promisses to be render client specific code. You either have a programming model that is agnostic to the kinds of clients it runs on (XForms, Flex etc) or you develop variants for each of the client types you expect. The way JSF does it imho is half baked and while I have a hunch it may be of use for someone here and there, in general it's probably not worth the extra complexity.

* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.

Eelco, Allow me to pick on you for the first time :-).
The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?

Having said that, I still believe Wicket is one of the finest, if not the finest, web frameworks around. Just trying to grab the opportunity to pick on you once :-). Jan

* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.

Eelco,

Allow me to pick on you for the first time :-).

Sure, as long as you don't start flame wars with competitors ;)

The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?

That holds true if and only if that component does exactly what you want and has the L&F you need or that this is easily customizable. Also, take into account that JSF components typically are configured using string parameters, whereas Wicket components can be configured using any kinds of objects and are often customized by e.g. extending them and overriding a method. It's much easier to create a layer of in-between (abstract) components so that if the more specialed doesn't exactly do what you need, you can look at the parent and see whether you can use that with a bit of filling the gaps.

* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.

Eelco,

The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?

That holds true if and only if that component does exactly what you want and has the L&F you need or that this is easily customizable. Also, take into account that JSF components typically are configured using string parameters, whereas Wicket components can be configured using any kinds of objects and are often customized by e.g. extending them and overriding a method. It's much easier to create a layer of in-between (abstract) components so that if the more specialed doesn't exactly do what you need, you can look at the parent and see whether you can use that with a bit of filling the gaps.

Parameterizing a component using an object is very powerful; the more ways you have for customizing a component, the more useful pre-built components become. However, requiring a user to pass in an object means defining an interface or abstract object class for the user to implement; that's a lot of overhead, especially when usually you just want the user to define one or two methods. Also, because the custom behavior typically needs to access data in the caller's context, the user will usually want to pass an instantiation of an inner class he created. Rather than customizing pre-built components by passing in objects, I usually found myself creating lots of anonymous subclasses of Wicket components, each of which overrode one or two component methods -- with the overriding methods accessing variables in the outer class' namespace. But this doesn't seem to be a very intuitive approach to teach a web developer who's had maybe one Java programming course. I suspect that if Java ever gets a really good closure construct, the Wicket API could take advantage of that to make sophisticated component re-use much more understandable. Have any of the Wicket framework developers discussed the use of closures in Wicket programming?

I really do not get the comparison between JSF and Wicket. To me they address different spaces. All wicket does is gives you a way to put "code behind" HTML (and conceed that it does it pretty darn well). JSF is a component framework that is designed to go beyond HTML promising pre-built components allowing you to build presentations using XML (JSPX)and/or programatically in a manner similar to swing supporting a well defined restful server-side lifecycle.
Having said that I have to admit that if you are going to compare JSF's lame HTML components with Wicket then there is NO comparison.

Wow, that has got to be the most impressive piece of saying absolutely nothing but trying to make it sound smart I have heard in at least a few weeks. What JSF IDE vendor do you work for? JSF hasn't caught on because it is a steaming pile of donkey turd. It is a useless, pointless piece of junk. Bleeding abstractions (by far its biggest flaw, out of many many flaws), "everything is a POST", slow, over-engineered, high learning curve, yet-another-tag-language etc etc. All of JSF is just a great big anti-pattern and signifies everything bad that ever came out of Java-land. JSF should have been smothered in the craddle and quickly forgotten. Wicket on the other hand is pretty darned pleasent acquintance.

Look at .NET code behind. junk. Its total crap. It actually takes the normal JSP layer that deals with markup and presentation and pushes that back into the web view/controller layer and then tries to push back forward into the request layer. junk. Code behind is crap. Call JSP a hack call it what you want. There IS a need for an intelligent renderer of HTML with code intertwined. If there wasnt then we wouldnt be where we are. You dont have to look far back to rich client applications to see they wanted to achieve the same PERFECT separation of layers. Yet not a single GUI client app ever did.

Look at .NET code behind. junk.

Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based) and the templates are full of foreign (to HTML) constructs. Just like JSF and many others.

It actually takes the normal JSP layer that deals with markup and presentation and pushes that back into the web view/controller layer and then tries to push back forward into the request layer.

If you're bitching about how Wicket does it: I don't think you get the point. With Wicket you seperate the view from the controller and model The templates for presentation are clean consisting only of static elements and hooks for dynamic parts and the dynamic parts (the logic) are implemented using Java - a 3GL well suited for coding arbitrairy logic such as when to show what and how to get it. The seperation means that you let your designers mock up pages and you - the developer - will fill in the dynamic parts. They can use their favorite tools, don't have to be afraid they mess up application logic, etc. And even if you don't use seperate designers, you'll definitively benenfit from having templates that can be 1-1 (or almost) with your design rather than having to strip/ add the logic all the time you have to get back to the drawing board.

Look at .NET code behind. junk.

Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based)

This is not exactly true. Viewstate is managed on component level. By default viewstate of all components on a page (so in this sense viewstate is page-based) is combined into one binary chunk, encrypted and saved into _viewstate hidden field, therefore you need to use a chain of HTML forms to keep state of related pages or to keep state of one logical page after it has been submitted. This is an Achilles heel of this approach, but on a plus side you can choose to save viewstate in a session or in a database or in any arbitrary object of your choice, there are callbacks for that. Also, you can choose to turn on or off viewstate for specific components or for all components on a page.

Look at .NET code behind. junk.

Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based)

This is not exactly true. Viewstate is managed on component level. By default viewstate of all components on a page (so in this sense viewstate is page-based) is combined into one binary chunk, encrypted and saved into _viewstate hidden field, therefore you need to use a chain of HTML forms to keep state of related pages or to keep state of one logical page after it has been submitted.

This is an Achilles heel of this approach, but on a plus side you can choose to save viewstate in a session or in a database or in any arbitrary object of your choice, there are callbacks for that. Also, you can choose to turn on or off viewstate for specific components or for all components on a page.

The thing that I don't like about viewstate is that it is a seperate (non-typed) map. Can can create member variables of pages and components, but .NET won't keep the values of them. So it provides you a programming model that is half-baked OO-ish.

Very good article on wicket vs jsf: http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

datawink.com

How is ajax supported in Wicket ?

Let's say you have a component you wish to update via ajax. First, you have to create the component, add it and call setOutputMarkupId(true): final Component component = new MyPanel("panel"); add(component); component.setOutputMarkupId(true) This makes it sure that the html markup the component is attached to has a dom id in the generated html (so javascript can find and update it). Let's say you have a link on your page and when the user clicks on it, you wish to update this component. You just add an AjaxLink like this: add(new AjaxLink("link") { public void onClick(AjaxRequestTarget target) { target.addComponent(component); } }); That's it. Clicking on the link will update your component in the browser. Let's say you want to have your component auto updated every 60 seconds. You also want to update another component (a label with an id "label"). No problem: component.add((new AjaxSelfUpdatingTimerBehavior(Duration.ONE_MINUTE) { protected void onPostProcessTarget(final AjaxRequestTarget target) { target.addComponent(label); } }); I hope you get the idea. It's dead simple... clear object oriented design. I've developed a web cms library in a year, working off hours and weekends that powers www.szeretgom.hu in wicket... refactored it several times during last year. Professionaly we built wicket based applications for two banks and a consulting firm. It just works, and works well. It's a bit hard for people to grasp the IModel hierarchy at first, but I think that's the hardest part of it all...