Hi, I share Sebastien's concern. I'll see how to workaround this.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <seb...@gmail.com> wrote: > Hi Guillaume, > > Generally speaking, you cannot call a non final method from a > constructor... > > Best regards, > Sebastien > On Oct 25, 2014 1:32 PM, "Guillaume Smet" <guillaume.s...@gmail.com> > wrote: > > > 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 > > > > >
