Wicket in Action

Wicket 1.5 - Request Mapper

03 July 2011, by martin-g

Hi, in series of short articles I'll try to explain the new stuff in Wicket 1.5. It may be a completely new feature or a change since 1.4, hopefully for good.

In this first article I'll talk about the new request mappers. They are semi- new feature, semi-change because they completely replace the functionality that IRequestTargetUrlCodingStrategy provided in 1.4.

Simply said, the Application class has a set of IRequestMapper's and for each request the RequestCycle asks these mappers whether any of them knows how to handle the current request's url.
Wicket pre-configures several mappers [1] which are used for the basic application functionality like a mapper for the home page, a mapper for Wicket resources, for bookmarkable pages, etc.  The user application can add additional mappers with the various WebApplication#mountXYZ() methods.

The mapper has two main tasks:

  1. To create IRequestHandler [2] that will produce the response.
    When a request comes Wicket uses IRequestMapper#getCompatibilityScore(Request) to decide which mapper should be asked first to process the request. If two mappers have the same score then the one added later is asked first. This way user's mappers have precedence than the system ones. If a mapper knows how to handle the request's url then it should return non-null IRequestHandler.
  2. The second task is to produce Url for an IRequestHandler.
    This is needed at markup rendering time to create the urls for links, forms' action attribute, etc.

In the next article I will show how to use most of the default mapper implementations.

1. See the source of SystemMapper for more details.
2. IRequestHandler is what IRequestTarget is in Wicket 1.4.