Skip to end of metadata
Go to start of metadata

This wiki is dedicated to documenting the Wicket Java application framework. Wicket takes simplicity, separation of concerns and ease of development to a whole new level. The wiki is currently open to new users and contributors; see the contribution page for more information. To download Wicket, please visit the Wicket site.

About Wicket

What is Wicket?

Wicket is one of the most recent in a long line of Java web development frameworks and stands on the shoulders of many that have come before it. Wicket is a component-based framework, which puts it in stark contrast to some of the earlier solutions to the sometimes monotonous task of web programming. Like other frameworks, Wicket builds on top of Sun's servlet API; however, unlike frameworks like Struts or Spring MVC, the developer using Wicket is mostly removed from the request/response nature that is inherent with the web and Servlets. Instead of building controllers that must service many users and threads simultaneously, taking in requests, returning responses, and never storing any state, the Wicket developer thinks in terms of stateful components. Instead of creating a controller or action class, he or she creates a page, places components on it, and defines how each component reacts to user input.

This may all sound familiar to those with desktop GUI experience; Microsoft's Visual Studio line, Sun's Swing API, and Borland's Delphi are all popular desktop GUI development tools that use component models. Using components allows the developer to spend less time on the visual tier of his or her app and more time implementing the core functionality. Even more important is how extensible this makes component-based GUIs. Adding additional functionality is simply a matter of adding one more component, which can act independently or in cooperation with other components in the view. These advantages have not been lost on web developers. In fact, many web framework projects have attempted to leverage the productivity and scalability of desktop applications. Apache Jakarta's Tapestry and Microsoft's own ASP.NET as well as Sun's Java Server Faces specification all present solutions to component-based development over the web and bring new ideas to the table. All of these technologies separate the page layout into a template file. JSF uses Sun's JSPs, ASP.NET uses ASP, and Tapestry use's it's own templating system based on standard HTML markup. These pages are rendered on each request, and as they are rendering, they make calls into a backing class to support dynamic content. As much as the word "template" would seem to suggest otherwise, this makes the page template king. Backing classes tends to be a series of listener methods, at the total mercy of the page template that is supposed to be merely defining the placement of components.

This works fine, and it is definitely a step up from a model 2 controller singleton class. Instead of a giant if block, we have well defined methods. Instead of being stateless, we can have instance variables. But now our Java code is a second-class citizen, existing merely to provide the page with the information it needs while it renders itself. Also, this backing class is always aware of the request-response cycle. It knows that getMember() is going to be called on every request, and reacts accordingly by getting a fresh copy from the database. Sure, the developer needs to deal with these details, but does it really have to be dealt with at the very top level of the application? Wicket allows the developer to build a page in Java (you remember Java right? It's like OGNL, but with even more cool features) that uses and manipulates an HTML file, not the other way around. This page exists across requests, and does not even need to be aware of the request/response cycle. But something needs to know when a new request is starting and when the last one has finished rendering, right? All kinds of problems crop up when an object/relational mapper tries to work with an object from the last request, or the user is looking at an object that no longer represents what's actually in the database, or when you merely try to store all that data in the session. The solution here is to not make the page aware of all the request details, but the data itself. That's what Wicket tries to do.

Introduction to Java web applications

Why Wicket

Framework Comparisons

Who is using Wicket

Where to (get) help

IRC

  • For those interested in a more direct support, please join IRC: ##wicket at irc.freenode.net. See Wicket IRC for more information

Community initiatives

Communities on social networking sites

Contribute to Wicket

Commercial Services

What's next

Wish List for Next Version

Migrations

More about Wicket...

Videos, Talks, Screencasts

Wicket Press & User Stories

Companies Hiring Wicket Developers

Using Wicket

Development Environment

Java

Build tools

  • Setup Maven - Maven (build, reporting and documentation)

IDE

Application server

Portal server

Database

Development

Framework Documentation

GUI-Components and Widgets

Here is the reference for the standard Wicket GUI components: Component Reference

You are looking for some additional additional cool Widgets, mainly Javascript/AJAX style?
Then have a look here:

  • Wicketstuff - Wicket Stuff provides components that complement the Wicket framework.
  • Wicket-Bootstrap - Simple and flexible Wicket Components, HTML, CSS, and Javascript for popular user interface components and interactions.
  • wiQuery - wiQuery integrates jQuery and jQuery UI into the Apache Wicket framework.
  • visural-wicket - a set of open-source Wicket components, Apache 2.0 licensed.
  • Tabs:
  • Tree:

Wicket Component Packaging

Portlet Development

Development Aids

Testing

  • Settings for testing
  • Choosing the overall testing approach:
    • Selenium - tips for testing Wicket apps with Selenium
    • WicketTester - Mock the browser and the container. Check the states of the components and the models.
    • Wicket Page Test - Use a real browser and a real container. Mock the service objects. Check the HTML DOM elements (supporting AJAX).
Labels
  1. I think the reference to http://cwiki.apache.org/WICKET/ needs to be removed as that gives an unstyled version of the wiki.