Hi Martin, what about multi-window support?
I.e. the user is working on different page instances of same type simultaneously?
Sven On 02.04.2016 00:07, Martin Grigorov wrote:
Hi, https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0#IdeasforWicket8.0-BetterSEOforstatefulpages The best way to send the page id with each request without "polluting" the url is to use request headers. Unfortunately there is no way to add request headers for non-Ajax requests, so this won't work. Now I'm thinking of another approach - store the id in the Session. (It is 01:00 so forgive me if I miss something). ?pageId is added only for stateful pages, i.e. Wicket binds a Session already. Instead of encoding the pageId in the query string we can store it (e.g. as <pageId, pageClass> struct) in the Session. All links in the page will still use ?pageId. They do not appear in the browser's address bar so they do not need to be changed! Only the url for the page redirects won't have it. Whenever a page is rendered the struct will be updated. If the page is stateless then the struct will be null-ified. If the user reloads the page (F5) then Wicket will detect that this is the same page class as the one in the struct and use the page id. If the application uses setResponsePage(Class) or RestartResponseException(Class) then the struct will be null-ified. So the application will be able to redirect to a new instance of the same page type. The only problem that I see is using BookmarkablePageLink that links to the current page. In that case Wicket will serve the old instance instead of creating a new one. What other problems do you see in this approach ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov
