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
>
>

Reply via email to