There are a couple of ways of integrating Spring with Wicket. If your WebApplications extends SpringWebApplication you already have access to the ApplicationContext for dependency retrieval. See this blog entry on how to proceed from there.

However in my case the WebApplication was extending AuthenticatedWebApplication and Spring beans were injected by adding a SpringComponentInjector to the ComponentInstantiationListener. Spring dependencies are then added by using the @SpringBean annotation.

So how to unit test pages using a @SpringBean annotation? Actually the solution ain’t that complex.
First of all in my main WebApplication I’ve moved registering the SpringComponentInjector to a seperate method:

public void init()
{
	..
	springInjection();
	..
}

protected void springInjection()
{
	addComponentInstantiationListener(new SpringComponentInjector(this));
}

For unit testing purposes I extended the WebApplication so I could provide a different injector and provided a method to retrieve the mock context:

public class TestEhourWebApplication extends EhourWebApplication
{
	private AnnotApplicationContextMock	mockContext;

	@Override
	protected void springInjection()
	{
		mockContext = new AnnotApplicationContextMock();
		mockContext.putBean("EhourConfig", new EhourConfigStub());		

		addComponentInstantiationListener(new SpringComponentInjector(this, mockContext));
	}

	public AnnotApplicationContextMock getMockContext()
	{
		return mockContext;
	}
}

AnnotApplicationContextMock is provided by Wicket and is quite a handy class as it allows you to register beans in the ApplicationContext on the fly.

Now with the TestWebApplication in place which uses a mock Spring context the only thing left is instantiating the WicketTester with this WebApp and fetching the AnnotApplicationContextMock from the WebApp so it’s available for unit tests. This is perfect stuff for a BaseTestCase:

public class BaseUITest extends TestCase
{
	protected WicketTester	tester;
	protected AnnotApplicationContextMock	mockContext;

	protected void setUp() throws Exception
	{
		TestEhourWebApplication webapp =  new TestEhourWebApplication();

		tester = new WicketTester(webapp);
		mockContext = ((TestEhourWebApplication)tester.getApplication()).getMockContext();
	}
}

Any extending TestCases now have access to the Spring’s context and can register any beans needed for the page creation. For instance mocking a ConfigService dependency (using easymock):

public class MainConfigTest extends BaseUITest
{
	public void testMainConfigRender()
	{
		ConfigurationService configService = createMock(ConfigurationService.class);
		mockContext.putBean("configService", configService);

		expect(configService.getConfiguration())
				.andReturn(new EhourConfigStub());

		replay(configService);

		tester.startPage(MainConfig.class);
		tester.assertRenderedPage(MainConfig.class);
		tester.assertNoErrorMessage();

		verify(configService);
	}
}

et voila !

So far I’ve converted a couple of Struts actions & tiles to Wicket panels and I have to say, I’m starting to love Wicket more and more. Okay, on the Java side of things it leads to somewhat of a code explosion but I’d rather have more Java code than keeping JSP’s, Javascript, XML config files, TLD’s, ActionForms and Actions all in sync – manually. And compared to Struts or any other action based framework you can get real independent components without any hassle.
Wicket’s documentation is still lacking but with the help of the examples, the Wiki and the excellent mailinglist this shouldn’t be a long-term problem.

Anyway enough feathers and flowers, in my Struts app I had a tile with a Calendar and a tile with two tables displaying some data of the selected month. The Calendar tile fired an Ajax request when a previous or next month was clicked and the two tables updated accordingly.
In Wicket terms this means having a Calendar panel (CalendarPanel) and another Panel (TimesheetPanel) displaying the data for that month. To get the basics on how Ajax works with Wicket there are enough Ajax examples to get you started so let’s skip the very very basics.

First of all two links are added to CalendarPanel:

AjaxLink previousMonthLink = new ChangeMonthLink("previousMonthLink", -1);
previousMonthLink.add(new Image("previousMonthImg", new ResourceReference(CalendarPanel.class, "arrow_left.gif")));
add(previousMonthLink);

AjaxLink nextMonthLink = new ChangeMonthLink("nextMonthLink", 1);
nextMonthLink.add(new Image("nextMonthImg", new ResourceReference(CalendarPanel.class, "arrow_right.gif")));
add(nextMonthLink);

And the markup:

<a href="#" wicket:id="previousMonthLink"><img wicket:id="previousMonthImg" src="img/left.gif" border="0" /></a>
<a href="#" wicket:id="nextMonthLink"><img wicket:id="nextMonthImg" src="img/right.gif" border="0" /></a>

To control AjaxLink‘s behaviour there’s an ChangeMonthLink inner class extending AjaxLink:

private class ChangeMonthLink extends AjaxLink
{
	private	int monthChange;

	public ChangeMonthLink(String id, int monthChange)
	{
		super(id);

		this.monthChange = monthChange;
	}

	@Override
	public void onClick(AjaxRequestTarget target)
    {
		EhourWebSession session = (EhourWebSession)this.getSession();
		Calendar month = session.getNavCalendar();
		month.add(Calendar.MONTH, monthChange);
		month.set(Calendar.DAY_OF_MONTH, 1);
		session.setNavCalendar(month);

		((BasePage)getPage()).ajaxRequestReceived(target,
				CommonStaticData.AJAX_CALENDARPANEL_MONTH_CHANGE);
    }

	@Override
	protected IAjaxCallDecorator getAjaxCallDecorator()
	{
		return new LoadingSpinnerDecorator();
	}
}

The onClick method is invoked when the XmlHttpRequest lands back on the server. Since any parameters you passed when constructing are still available there’s no need to parse the request (or ActionForm for that matter).

Within the onClick method of the Calendar panel only some date manipulation is done. Deciding which Panel should be updated in the client’s browser is delegated to the Page containing the Calendar. If you want re-usable components you don’t want to make references from one component to the other when they’re on the same level in the Page hierarchy. Components could re-appear in another context when referenced panels aren’t available.

All my pages extend from BasePage so it’s a safe cast to BasePage. However the extending Page doesn’t know which Panel fired the Ajax request hence the need to supply an event type, AJAX_CALENDARPANEL_MONTH_CHANGE.

With the Calendar panel setup the only code left to do is making the Page refresh the relevant panels:

public class OverviewPage extends BasePage
{
	private CalendarPanel		calendarPanel;
	private	WebMarkupContainer	contentContainer;

	public OverviewPage(PageParameters params)
	{
		..
		calendarPanel = new CalendarPanel("sidePanel", user);
		calendarPanel.setOutputMarkupId(true);
		add(calendarPanel);		

		contentContainer = new TimesheetPanel("contentContainer", user, session.getNavCalendar());
		contentContainer.setOutputMarkupId(true);
	}

	@Override
	protected void ajaxRequestReceived(AjaxRequestTarget target, int eventType)
	{
		CalendarPanel newCalendarPanel = new CalendarPanel("sidePanel", user);
		newCalendarPanel.setOutputMarkupId(true);
		calendarPanel.replaceWith(newCalendarPanel);
		calendarPanel = newCalendarPanel;
		target.addComponent(newCalendarPanel);

		TimesheetPanel	panel = new TimesheetPanel("contentContainer", user, session.getNavCalendar());
		panel.setOutputMarkupId(true);
		contentContainer.replaceWith(panel);
		contentContainer = panel;
		target.addComponent(panel);
	}
}

As you can see replacing a Panel is easy. The calendarPanel was already added in in the constructor. In the ajaxRequestReceived method it’s replaced with a new one. To have it refresh call addComponent on the AjaxRequestTarget with the new panel as an argument and you’re all set! It’s that easy, no need to do anything in the TimesheetPanel as there’s no difference between constructing it from a Page or reconstructing it for an Ajax request.

Just make sure the same ID (sidePanel & contentContainer) is used for the replacement panel as was used in the original construction since you’re replacing a component in the Page’s hierarchy.

Two things are left. You have to call setOutputMarkupId(true) on components you want to have ajaxified. By setting this to true Wicket generates a unique ID to locate the Panel in the HTML DOM.

The other thing is the AjaxCallDecorator as seen in the AjaxLink code fragment. With an AjaxCallDecorator you can decorate the Javascript onClick event before and after the request was send. I use it to display a loading message while the request is being processed:

public class LoadingSpinnerDecorator implements IAjaxCallDecorator
{
	public CharSequence decorateOnFailureScript(CharSequence script)
	{
		return "document.getElementById('LoadingSpinner').style.visibility = 'hidden';" + script;
	}

	public CharSequence decorateOnSuccessScript(CharSequence script)
	{
		return "document.getElementById('LoadingSpinner').style.visibility = 'hidden';" + script;
	}

	public CharSequence decorateScript(CharSequence script)
	{
		return "document.getElementById('LoadingSpinner').style.visibility = 'visible';" + script;
	}
}

That’s it! If I compare this to my Javascript/Action/ActionForm/Tiles/JSP/JSTL/XML combo you might understand why my love for Wicket is growing

Finally it’s time to get some data into a panel. In my Struts app I have an overview page which consists of two tiles. One tile is displaying a list with all hours booked per project in a month and the other tile shows an overview on a per-day basis of that month.

My Wicket plan is to create two panels, one for the list and the other for the month overview. The reason I’m creating separate panels – and not adding everything from the Page class – is that I want the flexibility to swap in different panels for different versions of the application.

To get the data I need two parameters, the user id and the month to view. The user id should be the authenticated user but as I haven’t added authentication yet I’m just adding it as a request parameter. In Struts you would fetch request parameters from the HttpServletRequest, in Wicket you add them to the constructor.
Now the constructor seems like a weird place but Wicket creates an instance per User session. For more info check the first chapter of Pro Wicket which goes into the life cycles of a Page.

public OverviewPage(PageParameters params)
{
	// ..
	int userId;

	userId = params.getInt("userID");

        // ..
}

Take note, as with Struts’ ActionForms, using a Form is way better but as this is just temporarily a simple request param would do.

Now on to displaying the data. For displaying the list with projects I’ve created a separate ProjectOverviewPanel. The constructoraccepts an id it should register on and the collection to list. All it does right now is adding a ListView component to the object graph:

public ProjectOverviewPanel(String id, Collection<UserProjectStatus> projectStatusSet)
{
	super(id);

	ListView view = new ListView("projectStatus", new ArrayList<UserProjectStatus>(projectStatusSet))
	{
		public void populateItem(ListItem item)
		{
			UserProjectStatus projectStatus = (UserProjectStatus) item.getModelObject();
			item.add(new Label("projectName", projectStatus.getProjectAssignment().getProject().getName()));
			item.add(new Label("projectCode", projectStatus.getProjectAssignment().getProject().getProjectCode()));
		}
	};

	add(view);
}

It’s rather straightforward, create a ListView component and feed the id and List it should act on. I’m explicitly creating an ArrayList object since ListView can only operate on Lists (duh..) and not on Sets.
On every iteration populateItem is called with a ListItem. ListItem is a wrapper around the object contained in the original list. Every property is then added as a Label to the item.
The relevant markup of the panel:

<span wicket:id="projectStatus">
	<tr>
		<td><span wicket:id="projectName">projectName</span></td>
		<td><span wicket:id="projectCode">projectCode</span></td>
		<td><span wicket:id="customerName">customerName</span></td>
	</tr>
</span>

As you can see the outer span’s id reflects the id with which the ListView was added while the inner id’s reflect are the ones used in the Item objects.
For now I’ve only added String labels as I haven’t looked into displaying currencies and floats. Another thing I have to look into is session management. As you can see from the projectStatus.getProjectAssignment().getProject().getName() the List I’m displaying is a couple of levels object graph. Wicket caches data in the session and I definitely don’t want one-off graphs like this in the user’s session.

Code changes can be found here.