Page History

...

The remedy is to split of parts of the screen to separate components (e.g. Panels) and manage the complexity there.

Do keep markup in sync with the component code

Don't try to do authorization from a servlet filter

...

It just won't work. Wicket is full of generated URLs (yes, even if you mount every page) so authorization based on the URL is a fruitless exercise. You are better off by writing an IAuthorizationStrategy and configuring this in your Wicket application. Study the code of wicket-auth-roles to see how this can work. In addition you'll get component based authorization, not just page based! (By the way, you'll have no problems with filter based authentication.)

Do take your time to override key Wicket features

Wicket can be tweaked in all kinds of expected and unexpected ways. For example you can substitute your own resource messages provider, filter and change the markup as it is read from disk or completely override the request cycle handling. However, some of these extension points are not for the faint hearted and not likely to be right immediately

Wicket Filter Mapping

Wicket 1.4.x and upwards

On these versions, you should prefer to use WicketFilter instead of WicketServlet. If you want, it's possible to map /* instead of /app/*. But remember to configure the ignorePaths parameter to ignore static resources and leave them to be handled by the container.

Ignoring paths

If you want to leave static resources to be handled by the container, configure the ignorePaths init parameter as follows:

...