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
