Question

I developed a shopsystem. there is a product page, which lists the available items filtered by some select menus. there is also one item detail page to view some content about each product. the content of that page will be loaded out of an xml property file. if one would click the link in the listview of an item, to view some details, an item specific GET parameter is set. with the parameters value, i can dynamically load the content for that specific item from my properties, by altering the loaded keys name.

so far so good, but not really good. so much to the backgroud. lets get to some details.

most of all, this is some SEO motivated stuff. so far there is also a problem with the pageinstance Id in the url for statefull pages, not only because of the nonstable url, also because wicket is doing 302 redirects to manipulate the url. maybe I will remove the statefull components of the item detailpage to solve that problem.

so now there are some QR-code on the products being sold, that contain a link to my detail page. these links are not designed by myself and as you can imagine, they look a whole lot of different like the actual url. lets say the QR-code url path would be “/shop/item1” where item1 would be the product name. my page class would be ItemDetailPage .
I wrote an IRequestMapper that I am mounting in my WebApplication#init() that is resolving the incoming requests URL and checks wether it needs to be resolved by this IRequestMapper. If so, I build my page with PageProvider and return a requesthandler for it.

public IRequestHandler mapRequest(Request request) {
                if(compatibilityScore>0) {
                    PageProvider provider = new PageProvider(ItemDetailPage.class, new ItemIDUrlParam(request.getUrl().getPath().split("/")[1]));
                    provider.setPageSource(Application.get().getMapperContext());
                    return new RenderPageRequestHandler(provider);
                }
                return null;
            }

So as you can see, I build up a parameter that my detailpage can handle. But the resulting URL is not very nice. I’d like to keep the original url by mapping the bookmarkable content to it, without any redirect.
My first thought was to implement an URLCodingStrategy to rebuild the URL with its parameters in the form of a path. I think the HybridUrlCodingStrategy is doing something like that.
After resolving the URL path “/shop/item1/” with the IRequestMapper it would look like “/shop/item?1?id=item1” where the first parameter off course is the wicket pageinstance Id, which will most likely be removed as I will rebuild the detail page to be stateless 🙁
after applying an HybridURLCodingStrategy it might look like “/shop/item/1/id/item1” or “/shop/item/id/item1” without pageinstance Id. another Idea would be to remove the second path part and the parameter name and only use the parameters value so the url would look like “/shop/item1” which is then the same url as it was in the request.

Do you guys have any experience with that or any smart ideas?
The rewuirements are

1. Having one fix URL for each product the SE bot can index
2. no parameters
3. stateless and bookmarkable
4. no 302 redirects in any way.
5. the identity of the requested item must be available for the detailpage

with kind regards from germany
Marcel

Answer 1

As Bert stated, your use case should be covered with normal page mounting, see also the MountedMapper wiki page, for your case a concrete example:

mountPage("/shop/${id}", ShopDetailPage.class);

Given that “item1” is the ID of the item (which is not very clear to me), you can retrieve it now as the named page parameter id in Wicket. Another example often seen in SEO links, containing both the unique ID and the (non-unique, changing) title:

mountPage("/shop/${id}/${title}", ShopDetailPage.class);

Regarding the page instance ID, there are some ways to get rid of it, perhaps the best way is to make the page stateless as you said, another easy way is to configure IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER as the render strategy (see API doc for consequences).