Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Tables and Grids

Extract from explanations given by Igor Vaynberg on mailing list

There are a few ways to display and populate table/grid data in wicket. They include:

If you look at the class hieararchy you will see that every repeater builds on the other.

Why so many ?

Because there are many different ways table data can be retrieved, populated and then displayed, having a hierarchy like this lets you pick a component that delivers the exact functionality you need, without over complicating the simple cases.

In Action/Examples

You can see each of these components in action here.

A Simple DataView Example by Adam A. Koch
A Simple Sortable DataTable Example by Adam A. Koch

The Details

Repeating View

This is a very basic repeater. You add items to it - those items are rendered using the repeater's markup.


This view takes an iterator<imodel> and lets you generate items based on that iterator much like ListView. Items are also refreshed every request unlike the RepeatingView. The big differences when compared to ListView is that refreshing view works with iterators where as ListView is limited to lists.

Another big difference is that RefreshingView makes you wrap each iterator item in a model where as ListView does not (you have to override getListItemModel() to do that in a listview). Doing this enables you to avoid all kinds of problems when dealing with non-static collections. It is easy to use any iterator by using ModelIteratorAdapter.


This is like RefreshingView + paging support

DataView and GridView

  • DataView - this is a pageable view that is populated via idataprovider instead of an iterator<model> which makes working with databases much simpler.
  • GridView - makes it simple to show an iterator in a grid where each row can have a max number of items


This is a view that extends the DataView with the idea of populators and makes displaying tabular data easy by letting populators populate each cell instead of you doing that in populateItem() yourself. The idea is that depending on your application logic (eg. roles/permissions etc.) you can vary the list of populators and simplify the logic.


This is the mac daddy of the table oriented components. DataTable extends the tree not by inheritance but by delegation. It wraps a DataGridView and provides all the markup for you so you dont have to. It adds support for interchangeable toolbars like sortable headers, filters, pagers, etc.