Wicket 1.5 and nice URLs

There are already several good pages describing how to create nice URLs with Wicket 1.5, like this post of Ceki Gülcü. I did the same, just with the upcoming Wicket 1.5. Instead of mounting a single page, it’s now possible to mount a whole package. This will work with all pages stored directly in the package you name, but not for pages in nested packages.

You’ll need to add something like that in your Application class:

@Override
public void init() {
    super.init();
    mountPackage("/", HomePage.class);
    mountPackage("/feedback", FeedbackPage.class);
    mountPackage("/login", LoginPage.class);
    mountPackage("/test", TestPage.class);
}

You already see the second feature addition. It’s possible to map a class of your choice to “/”. The discussion can be found here.

In my example I mount different Page classes to different URLs. All other pages which are in the same package as FeedbackPage are mounted to /feedback to. I took the most important class and get the others for free. Nice feature. However nested package mapping would also be nice.

But be careful. I run into problems later. In my Login-form I had a onSubmit method like this:

@Override
public final void onSubmit() {
    SignInSession session = getMySession();

    if (session.signIn(getUsername(), getPassword())) {
        if (!continueToOriginalDestination()) {
            this.setResponsePage(TestPage.class);
        }
    } else {
        String errmsg = getString("loginError", null, "Unable to sign you in");
        error(errmsg);
    }
}

I put the TestPage.class as my response page. The same page has been used in my navigation as BookmarkableLink.

BookmarkablePageLink test = new BookmarkablePageLink("test", TestPage.class);

It should have been visible after the login. The visible flag worked, but the generated URL was wrong. Instead of my expected and mapped output “test/TestPage” I got an href with “wicket/TestPage”. Clicking there brought me an 404 of course. I spent some time and finally found an article, were the difference between the various setResponsePage implementations are explained. I simply tried it out and it worked for me:

if (session.signIn(getUsername(), getPassword())) {
    if (!continueToOriginalDestination()) {
        this.setResponsePage(new TestPage());
    }

I created the instance myself. Looking at Wickets code, I couldn’t find out easily what was the root cause of my problem. It seemed at first glance that setResponsePage(TestPage.class) is just another way to go. But it’s not. However, I am in a hurry now - this case caused to much cost :-) I will probably debug later again.