you can try it and see if it works for your particular usecases. there may still be some edges that will break, like links you actually want to run against an older version of the page because they depend on the component hierarchy that existed then, etc.
-igor On Fri, Sep 24, 2010 at 7:56 AM, Joe Hudson <joe.hud...@clear2pay.com> wrote: > Hi, > > I know there have been several existing topics around this issue > (http://apache-wicket.1842946.n4.nabble.com/debugging-PageExpiredExceptions-td1882040.html) > for example. The reason that I am asking for a sanity check is because I > plan to use an alternative approach to solving this issue and would like > feedback to make sure there isn't a reason I shouldn't be doing this. > > The common approach is to catch the exception and return a new instance of > the requested page. This seems to have some key drawbacks IMHO: > 1) this only works with bookmarkable links > 2) you lose any modifications to the model that happened after the page was > originally loaded but before the exception occured > 3) any data on the client may potentially be out of sync with the server > state if not updated by the request that caused the exception (because the > new page was loaded but that client representation is still a picture of the > previous page with the previous model). Although this would be resolved by a > form submit behavior - you would still have problems in the exceptional cases > where the model is updated individually by input field ajax change events. > > It seems that the page version number is only necessary for a stateless > application and in an ajax-oriented application you would always want to work > with the latest page version. We seem to hit these issues when multiple ajax > requests that target a particular page happen concurrently because the page > version is incremented when the initial ajax request is made but all other > ajax requests that are initiated before the initial ajax request response > reference a now outdated page version number. > > So, after all that background - do you think this is a valid fix for an > ajax-oriented application: > Override the default SecondLevelCachePageMap and as long as the requested > page id matches the page id of getLastPage() just return the last page. > > > Your thoughts would be appreciated and sorry for the long email but I wanted > to provide background to make sure that the fix was valid for my particular > solution (because I know the fix would not be appropriate for a stateless > application). > > Thanks > > Joe Hudson > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
