Hi Martin, I got something working with the following changes in Wicket: https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
Do you consider this commitable? If so, I can create a JIRA issue and push a PR. Having the pageId in the getTimeout call is quite nice as I don't have to get it again from the PageRequestHandlerTracker. Thanks for your feedback. On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > 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 <guillaume.s...@gmail.com> > 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 <mgrigo...@apache.org> >> 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 < >> guillaume.s...@gmail.com> >> > wrote: >> > >> >> Hi Martin, >> >> >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mgrigo...@apache.org> >> >> 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: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
