Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

Here are some features of apache wicket:

POJO Component Model

Pages and Components in Wicket are real Java objects that support encapsulation, inheritance and events.

Ease of Development

Because Wicket is Java and HTML, you can leverage what you know about Java or your favorite HTML editor to write Wicket applications.

Separation of Concerns

Wicket does not mix markup with Java code and adds no special syntax to your markup files. The worlds of HTML and Java are parallel and associated only by Wicket ids, which are attributes in HTML and Component properties in Java. Since Wicket HTML is just HTML and Wicket Java is just Java, coders and designers can work independently to a large degree and without relying on any special tools.

Secure

Wicket is secure by default. URLs do not expose sensitive information and all component paths are session-relative. Explicit steps must be taken to share information between sessions. Furthermore URL encryption allows highly secure web sites.

Transparent, Scalable Clustering Support

All Wicket applications will work on a cluster automatically and without additional work. Once bottlenecks are understood, Wicket enables tuning of page state replication. The next version of Wicket will support client-side models for zero-state scalability.

Transparent Back Button Support

Wicket supports configurable page version management. When users submit a form or follow a link from a page they accessed with the back button in their browser, Wicket is able to revert the page object to the state it was in when the page was originally rendered. This means you can write web applications that support the back button with very little work.

Multi-tab and multi-window support

Wicket provides an easy way to write application that supports multi-window and multi-tab usage allowing developer to react properly when users open new browser window or tab

Reusable Components

Reusable components in Wicket are particularly easy to create. Not only can you extend existing components with the Java extends keyword, but you can also create Panel components which associate a group of components as a reusable unit.

Simple, Flexible, Localizable Form Validation

It is trivial to write and use validators in Wicket. It is also quite easy to customize and localize the display and content of validation error messages.

Typesafe Sessions

Wicket eliminates the need to manage HttpSession attributes by hand. Page and component objects are transparently stored in the session and your application can create a custom session subclass with typesafe properties as well. All objects stored in the session can automatically participate in clustering replication.

Factory Customizable

Wicket is very extensible. Most operations are customizable through factories or factory methods.

Detachable Models

Model objects in Wicket can be very lightweight in terms of memory and network use in a cluster. When a model is used, it can “attach”, populating itself with information from persistent storage. When the model is no longer in use, transient information can be reset, reducing the size of the object.

Border Components

Wicket Border components enable the decoration of pages in a reusable fashion. This is especially useful for inheritance of common navigational structures or layout.

Support for All Basic HTML Features

Wicket supports image tags, links, forms and everything else that you’re used to using in your web application development.

Programmatic Manipulation of Attributes

Wicket Components can programmatically change any HTML tag attribute.

Automatic Conversions

Once a Form validates, the model can be updated using Wicket converters. Most ordinary conversions are built-in and it is easy to write new converters.

Dynamic Images

Wicket makes image use, sharing and generation very easy. Dynamic images can be created by simply implementing a paint method.

Pageable ListView

ListViews in Wicket are extremely powerful. You can nest any kind of component in a ListView row, even other ListViews. PageableListView supports navigation links for the large lists.

Tree Component

Out of the box tree component for navigating and selecting nodes.

Localization

HTML pages, images and resource strings can all be localized.

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

Wicket rocks!

Spring (the UI part of which is called Spring MVC) 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 (and Spring MVC). 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 (http://www.expojo.com) with Wicket and all is funky.

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.

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.

I agree with the answers provided so far. What hasn't been mentioned are the following points, which are a consequence of Wicket's approach of web application development focussed on Java code:-

  • Wicket development does not involve writing JSPs.
  • AJAX components can be developed without involving the writing of Javascript.

I haven't come across any other framework which takes this Java-centric approach. All the others I've used (Struts, Spring) involve JSP development.

For me a big advantage of Wicket is the focus on Java, and availablity of rich development environment tools like Eclipse. Also the very clean separation of business logic from presentation aspects of the application.

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

Spring gives you the MVC design pattern only at the page level -- a very coarse level of granularity indeed. Wicket, in contrast, gives you the MVC design pattern at the individual component level (much as Swing offers for fat client programming). With Spring MVC, all of a form's data is global to the entire front servlet, so there is not much opportunity for information hiding, loose coupling, or tight cohesion. With Wicket, your display logic can be much more modular -- the data managed by componentA need not be visible to the code for componentB.

The smaller level of granularity makes it much easier to reuse display code across a number of different web pages or even across web applications.

Also, because component configuration is done in Java rather than XML, they can be configured on-the-fly at run-time, making for much greater power and flexibility (as contrasted with most other component-oriented frameworks such as ASP.NET Web Forms or Java Server Faces).

One other advantage of Wicket over other popular java web frameworks is that it allows you to create modular and extensible web applications. This is particularly useful when you are designing a web based product, which you intend to extend by adding extra functionality and pages in the form of plugins at deploy time, and eliminating the impact on the core functionality/source of your product. Here is a very good article on it.

http://www.infoq.com/articles/modular-wicket

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top