On Fri, Sep 26, 2014 at 12:23 PM, mscoon <msc...@gmail.com> wrote: > Okay I see. > > I imagine this approach breaks if the render strategy is REDIRECT_TO_RENDER > and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER. >
Wicket will redirect only if the requested url differs with the response url. Since the ?pageId is not in the url anymore then it depends only on the page parameters. As you can see in the demo app I haven't played with this. > > Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if > somehow requests from different tabs for the same page (url) were handled > simultaneously? > Wicket serializes the access to page instance. Since there is only one page instance per type then multitab support is more limited than current Wicket. Request1 will acquire the permit to use the page instance and request2 will wait on PageAccessSynchronizer. Once request1 finishes then if it is Ajax then all as before/now. But if request1 is normal (non-Ajax) then page#renderCount will be incremented and request2 will fail will StalePageException and just re-render with the last state (the one after request1). So you may see more "do-nothing" interactions with the page than now. > > > > On Fri, Sep 26, 2014 at 11:58 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Hi, > > > > What you describe is what several users currently do by using > > NoVersionMapper. > > NoVersionMapper is the thing that hides the ?pageId from the url in the > > address bar. > > > > The changes you suggest to be done in SinglePageManager (effectively > remove > > SinglePageManager completely) is the current default behavior in Wicket. > > > > The "hole" is that F5 (page refresh) loses the state and creates a > > completely new page instance with its own state. Using back/forward will > > lose the state too. > > This is the reason why NoVersionMapper is not in the official Wicket > > distro. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Fri, Sep 26, 2014 at 10:52 AM, mscoon <msc...@gmail.com> wrote: > > > > > Martin, > > > > > > I found you "single-page-instance" sample very interesting. > > > > > > I have the following question if you can spare some time: > > > > > > What happens if you completely remove the local map in > SinglePageManager > > > (and the associated) code? > > > > > > I.e. if SinglePageManager#getPage(int id) always delegates to the > > > underlying manager and SinglePageManager#newPage() always returns a new > > > page from the underlying factory. > > > > > > It seems that then you get the following: > > > 1. Every time you hit a page either by url or navigation, you get a > fresh > > > instance, but without a version parameter in the url. Effectively you > > get a > > > new version of the page but the url does not include the version > number. > > > 2. Interactions with the page affect the specific version. As long as > you > > > keep interacting with the page (e.g. "Increment"), you are fine. You > can > > > even have the same page in two tabs with different state. > > > 3. If you hit F5 you go back to the page's original state > > > > > > I think the behavior outlined above is also valid for several use cases > > > (e.g. facebook's profile page works like this - there are a lot of ajax > > > interactions but if you hit F5 you go back to the page's original > state). > > > > > > Do you see any holes? > > > > > > Thanks > > > Marios > > > > > >
