If you have a base page then BasePage#onInitialize() should be a good place. Or you could add the pageIds of the special/slow pages only in the map.
Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom IRequestCycleListener#onDetach(). Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <[email protected]> wrote: > Hi Martin, > > Yeah, I thought about that too but I'm not sure of the best place to > build the pageId -> pageClassName map. Any advice about this? > > Once I'll get this working, I'll build a PR for the few changes I made > in Wicket (based on what you proposed earlier). Would be nice to have > them in 6.18. > > On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <[email protected]> > wrote: > > Hi Guillaume, > > > > Sorry for not thinking more carefully about this the first time! > > I'm afraid it is not possible to do it the way I suggested. > > PageAccessSynchronizer is the entry point to start using a page and it > > works only with pageId! > > > > Here is a new hackish approach: > > Store pageId -> pageClassName map in the Session. Then when > > PageAccessSynchronizer is requested to lock a page by id use that id to > > resolve the class name and to decide what timeout to use. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet < > [email protected]> > > wrote: > > > >> Hi Martin, > >> > >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <[email protected]> > >> wrote: > >> > I'd like to avoid moving the logic that gets the timeout from > >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer > because > >> > this way it will use Application.get() everytime and most apps don't > need > >> > to pay for this. > >> > > >> > A way to make it possible for you is to remove the 'final' > >> > from org.apache.wicket.Session#getPageManager and introduce > overridable > >> > PageAccessSynchronizer#getTimeout(). This way you can use your own > >> > PageAccessSynchronizer. > >> > http://pastie.org/9667070 > >> > >> After a few experiments, here I am! > >> > >> So, it mostly works: I thought it would be better to add something like: > >> protected IProvider<PageAccessSynchronizer> > >> newPageAccessSynchronizerProvider() > >> { > >> return new PageAccessSynchronizerProvider(); > >> } > >> in Session and call it from the constructor instead of removing the > >> final so I did that in my code. > >> > >> It works pretty well BUT I haven't found a way to get the page class > >> in getTimeout without having the risk to trigger a resolvePageInstance > >> which will try to lock and then call getTimeout leading to a wonderful > >> stack overflow exception when dealing with > >> ListenerInterfaceRequestHandler. > >> > >> Obviously (...) what interests me the most is the getTimeout in > >> ListenerInterfaceRequestHandler as it's often actions on buttons which > >> are long to run. > >> > >> Here is what I have in mind for my Session class: > >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef > >> > >> I must admit that an advice would be welcome as I wouldn't like to > >> have stack overflow errors popping out in weird edge cases. > >> > >> Thanks! > >> > >> -- > >> Guillaume > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
