views:

1841

answers:

6

I'm not a Java developer so I might get some terms wrong... but.

An application I integrate with is moving from Spring to Wicket. While it should not affect my integration with it I got to wondering why they would do this?

From what I know Spring is the more popular framework. I know nothing about it except it's popular. I did read the Wicket page and Wicket seems really simple and straightforward.

What are some of the advantages of Wicket?

It seems to me that changing your entire framework would be some work so I wonder if Wicket offers something that Spring does not?

+4  A: 

Spring is more all-encompassing than Wicket.

Wicket is a Java web UI framework. Spring has one as well, along with modules for persistence, remoting, security, messaging, etc.

Spring is built on dependency injection and AOP. Wicket has neither.

I have not used it, but it's supposed to be simple. I can't say whether Spring is easier or harder.

You can use Spring to good advantage in a lot of situations besides web applications.

duffymo
"Spring is built on dependency injection and AOP. Wicket has neither."It is worth mentioning that there's nothing preventing you from using *any* spring modules outside of spring mvc in conjunction with wicket... or any DI, AOP framework, for that matter.
whaley
Great point, whaley. I agree. That would include Guice or PicoContainer, AspectJ, etc.
duffymo
+11  A: 

Advantages that often get touted in circles I frequent are:

  1. Your html can be fully xhtml compliant - there is a VERY nice separation of presentation and logic in that the only thing your presentation/html layer needs to know about wicket are wicketid attributes in standard html tags. This is wonderful for the html/css/javascript client side guy on your team who does little to no actual java work. No other java based web framework can claim this, afaik.
  2. No xml config for anything wicket specific - everything can be done in source and very little needs to be done to the standard web.xml for your .war
  3. component based development is pretty easy to grok - especially if you have a non web background (e.g. a swing programmer). it encourages reuse quite a bit more than mvc does, imo.
whaley
I noticed point 1 on the wicket site. It looks pretty clean and simple. I was thinking "This is how asp.net should have been" (I'm a .net developer).
metanaito
Wicket rocks!... I love it.
Marcelo Morales
Point 1 - If you are developing even a moderately sized application, your html will end up with <wicket:border,enclosure,container,panel> tags. So your HTML developers will still need to be aware of Wicket tags - See http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html for a list. So not as clean a separation as purported.
Mike
Tapestry [http://tapestry.apache.org/] has also had pure html templates for quite a while.
crowne
+5  A: 

Spring's more than Spring MVC. You can (and probably should) use Spring with Wicket.

tpdi
+4  A: 

You can read about the advantages of using Wicket in the free first chapter of Wicket In Action: http://www.manning.com/dashorst/

In short, Wicket is a great framework when the application you're developing is relatively complex, you want it to be maintainable, being able to scale the team and take advantage of reuse. Object oriented programming proved to be a very useful paradigm for programming UIs, but unfortunately, most Java frameworks for developing web applications, including Spring MVC, only support a very procedural programming model where they tag the term MVC on to make it sound cool (but in fact, since the granularity they support are request/ response roundtrips rather than self contained widgets, MVC is really misleading).

The DI part of Spring is great, and is something you can easily use together with Wicket.

Eelco
+3  A: 

Wicket rocks!

Spring just seems to be a mega, do everything, including the kitchen sink, type of framework which made it appear huge and unwieldy to me when I started to evaluate Spring. Today Spring doesn't seem to me to be focussed on any one thing. Originally I think it was simply a dependency injection framework but it quickly grew to try to be all things to all people and the simplicity was lost.

The books I read on Spring had examples that contained way too much XML config. Errors in XML config files are a lot harder to debug and fix than errors in java code which you can single step through with your debugger.

What's wrong with declaring stuff in Java code instead of XML anyway? Since when did someone decree that everything should be declared in XML anyway. If you like swimming in a sea of complex XML config files then go with Spring. If you like getting work done and being productive then go with Wicket.

Wicket is very focussed on being the best Java based UI framework for web app development. It doesn't try to lock you into any particular dependency injection framework or any particular persistence framework (use it with JDO/JPA, DataNucleus, Hibernate, whatever).

It's focus is clearly on UI but you can use any dependency injection framework you like (you don't have to use Spring's DI with it but you can if you want). We even use our own DI (expojo.com) with Wicket and all is funky.

Golfman
+1  A: 

Some advantages of Wicket I like:

  1. Simplicity - Learning curve is small especially if you are from Swing school.
  2. Clean Separation of Concerns - Web designer does not need to know much about the codes.
  3. Ease of Deployment.

    Here is my blog to show hello world codes in Wicket

Sheng Chien