Clean URLs are not a luxury. They help search engines, make logs readable, and keep links friendly in emails and chats. In Wicket the default URLs can get wordy with those wicket bits. Time to take control with page mounting.
Google rolled out Caffeine and is crawling faster than my coffee disappears. If we want our Apache Wicket apps to show up clean in results, the URL story matters. Lets sort it out with a practical tour of mounting and page parameters.
What does mounting a page mean in Wicket?
Mounting sets a stable path like /products and binds it to a page class. When someone hits that path Wicket knows which page to create and which parameters to feed it. No surprise query strings. No random interface bits.
You get URLs you can print on a brochure, paste in Twitter, and stick in a sitemap. In Wicket speak we are talking about bookmarkable pages and URL coding strategies.
Why should I bother mounting pages?
Because the default URLs expose component internals and can change when the page versions. That scares crawlers and humans. A mounted page gives you a stable contract between your app and the browser bar.
It also makes links predictable in tests, logs, and analytics. When you fix the path, you can write rules, build sitemaps, and avoid accidental duplicate content.
Which pages should be mounted?
Anything public that you want indexed or shared. Think product detail, article, category, help, pricing, user profile if it is public. Stuff that sits behind a login or complex flows can stay unmounted if you like.
If a page can stand alone with just PageParameters, it is a good mount candidate. Keep flows and wizards out of this bucket.
How do named and indexed parameters differ?
Named parameters look like /product?id=42. Indexed parameters look like /product/42. Same intent, different shape. Named is explicit and flexible. Indexed is short and friendly.
Pick one style and stick with it across the app. Use IDs or keys that are stable. If you want both readability and safety, go with /product/42/widget and use the number for lookup while keeping the slug for humans.
Where do I wire the mounts?
Do it during Application init. Keep all mounts in one place so future you can see the whole map. A small Urls class with constants for each path saves typos and makes refactors painless.
Treat the URL map as part of your public API. When you change it, plan redirects and tests just like you would for an external integration.
What about session ids and junk in the URL?
Wicket will not append jsessionid if cookies work. Keep cookies on and you are fine. For first hit without cookies the container may add it. If your audience is picky, use a cookie check on the landing page and keep the rest clean.
A mounted path also reduces the chance of those wicket interface bits showing up. Link with bookmarkable links to keep it tidy end to end.
How do stateless and stateful pages affect URLs?
Stateless pages are the friendly kind. No page id and no version added. If your public page only reads parameters and models, Wicket can keep it stateless and your path stays clean.
Stateful pages track versions and might append tracking bits on post back. For public pages avoid storing per user state in components, keep models detachable, and stick to read only links. You get better caching and faster first load.
Do I need .html at the end?
No. Extensionless paths are fine. Some teams add .html for tradition. Both work. If you go extensionless, make sure your web.xml filter mapping sends requests to Wicket and still lets your static files go straight to the default servlet.
One safe pattern is to mount Wicket under a base like /app and keep assets at the root. Another is to map the filter to all and add explicit servlet mappings for assets. Test with real static files to confirm nothing gets swallowed.
How should I handle slugs for readability?
Use lowercase, dashes or underscores are out for us so prefer lowercase words stuck together or numbers. Better yet put the id first and the slug after, then ignore the slug during lookup. That gives stable resolution even if someone edits the title.
Make the slug part optional and do a tidy redirect when it is missing or off. People will still reach the content and the canonical form wins for search engines.
How do I keep canonical URLs?
Pick one shape. Lowercase, no trailing slash, or lowercase with trailing slash. Then redirect all variants to that one with a permanent redirect. Browsers and crawlers both learn fast when the response says moved for good.
On the page add a canonical link in the head that points to the mounted address. Templates make this easy and it pays off when others link to a variant.
Can I mount assets too?
Yes. Wicket can mount shared resources so your CSS and JS get stable paths with cache control. That leaves you in charge of versioning. Add a version or hash to the path when the file changes and let the browser keep the rest.
If your static files live outside Wicket, keep them on the default servlet and serve them straight. Either approach is fine as long as you do not mix both for the same file.
What about secure pages and protocol switches?
Some pages must go over https. Wicket plays well with that through a request cycle processor that checks which pages need a secure scheme. The mounted paths stay the same while the protocol flips.
Decide early which pages are secure. Keep resources on both protocols or serve them protocol relative so you do not get mixed content warnings in browsers.
How do I migrate from ugly URLs to mounted ones?
Run both for a short window. Keep the old mapping alive and respond with a permanent redirect to the new path. Update internal links to use bookmarkable links that target the mount. Push a sitemap with the new addresses so crawlers follow the move faster.
Track 404s in your logs and patch common misses with redirects. People will paste old links for a while. Be kind and ferry them to the right place.
How do I test that the mapping is solid?
Write tests that ask Wicket for the URL to a page with certain parameters and compare it to the shape you promised. Then hit that path and assert that the right page receives the right values.
Also click around the app in a real browser with the dev toolbar open. Watch for redirects, watch for cache headers, and confirm that forms do not introduce state into pages that should be stateless.
What are common mistakes with mounts?
Mounting too late in the app life so links were already shared with the old pattern. Mixing uppercase and lowercase in paths. Allowing both trailing slash and no slash. Each of these creates duplicate content and weird link juice splits.
Another one is hiding required info in session and then wondering why a bookmarkable URL fails on first load. If the page needs it, put it in PageParameters.
Do mounted URLs help performance?
They do in indirect ways. Stateless pages are simpler to render and scale better across nodes. Clear paths cache better at proxies and CDNs. Logs are readable so you can spot hot routes and fix them.
With Caffeine indexing fast, fresh content behind mounted pages gets crawled and recrawled without chaos. That is free traffic for thoughtful URL design.
How do I pick a good URL scheme for an app?
Start with the nouns. If your app speaks in projects, tasks, and users, your URLs should too. Keep it short, lowercase, and stable. Use ids for truth, slugs for smiles.
Write the map on a single page. Review it with your team. If everyone can guess the next URL without thinking, you nailed it.
What server tweaks keep things smooth?
If Tomcat or Jetty is in front, check the filter mapping order. The Wicket filter should see your app paths. The default servlet should serve images, CSS, and JS. When in doubt, test a request to a real image and a real mounted page and confirm each goes to the right place.
Set cache headers for assets. For pages, let them be cacheable when they are truly static, and set no cache for private pages. Small touches go a long way when traffic spikes.
Quick checklist before you ship
Every public page has a mount. Parameters are explicit and stable. There is a single canonical form for each URL. Redirects are in place for old paths. Links are bookmarkable. Slugs do not control lookup. Secure pages force https. Assets are either mounted with versions or served static with cache control.
Run through the app with cookies off just once. Make sure the first hop is polite and clean. Then turn cookies back on and enjoy the tidy paths.
So what is the payoff?
Predictable URLs make everything easier. Users trust them. Crawlers index them. You can test them and monitor them. In Wicket the gap between messy and clean is small. Mount early, pick a scheme you like, and let the app breathe.
The web keeps moving. Phones are pushing more traffic each week and short readable links win on tiny screens. Give your pages a home that is simple to find and simple to share. Your future self will thank you.