Question

We’ve been using Wicket 1.3.7 for a few years now and are currently in the process of upgrading our project to wicket 6.x

I did a lot of research regarding to the page version parameters (e.g. ?1) being append to every URL, and how to get rid of them. (Could not find detailed information on this in the official documentation, unfortunately.) While doing so I read a lot of statements (from Wicket developers and users like

It is needed to keep track of the page version, otherwise it would not be possible to be stateful

and

You need to make your pages stateless to get rid of it

It was also suggested to use a custom implementation of AbstractComponentMapper, overriding encodePageComponentInfo not appending the parameter. Which has the obvious disadvantage of breaking statefulness for the mounted page. (see this SO answer for example)

Yesterday I stumbled upon RenderStrategy.ONE_PASS_RENDER.

I gave it a try, and after doing some testing I have got the impression that this is the setting to “restore the old wicket way”: the page version parameters are gone, yet my pages are stateful.

Okay, there’s a drawback, too. If have to take care of the double-submit problem myself, but I can live with that.

Question: are there any other drawbacks I am not (yet) aware of? Any surprises to be expected?

It seems to be the perfect solution, I just wondered why there are so many discussion about how to get rid of these parameter, even with wicket developers, where this is not suggested….

Thanks in advance.

Answer 1

We went through a similar upgrade path and my first reaction after upgrading was “Woah, these are some nasty URLs…”.

Initially, we also switched to the one-pass render to have nicer URLs. But then after looking more into it, it appeared that the “?id” does more than just solve the double-sumbit problem.

Pages with Ajax components can be heavily stateful: as the user interacts with the page, you add components, remove others, etc. With the page ID in the URL parameters, you get back the page in the same state as you left it if you refresh the page (F5) or navigate to another page, then press the back button.

You lose that feature if you switch to one pass rendering since there is no way for the browser to identify which page from the page store is targeted and usually end up with another instance of the page object.

This was especially visible in “listing result” pages (pages that show a list/table of “items” with Ajax paging and filtering). On such pages with the one pass rendering, you’d often lose your search criteria or be brought back to the beginning of the results even though you had clicked “next page” a couple times.

We ended up using the “standard” rendering mechanism (not the one pass redering). URLs don’t look so good but we felt the pros outweigh the cons (and the href do look OK, it’s only the browser URL bar).

Another concern was the “crawlability” of our site. In order not to have the the 302s or the “url?id” impacting the Google index we added the following code in our Wicket application init method to force one-pass render for the Google Bot:

    setPageRendererProvider(new IPageRendererProvider() {
        @Override
        public PageRenderer get(RenderPageRequestHandler handler) {
            return new WebPageRenderer(handler) {
                @Override
                protected boolean isOnePassRender() {
                    // To avoid 302s with Google Bot and have good SEO.
                    String userAgent = ((HttpServletRequest) RequestCycle.get().getRequest().getContainerRequest()).getHeader("User-Agent");
                    if (StringUtils.contains(userAgent, "Googlebot")) {
                        return true;
                    } else {
                        return super.isOnePassRender();
                    }
                }
            };
        }
    });