So essentially what you want to use is the (failing) request URL to redirect users to different pages? Some kind of strategy for redirecting to "Expired Pages" and to "Home Pages" based on the URL instead of fixed pages? Isn't this possible by rolling out your own WebRequestCycleProcessor?
Ernesto On Mon, Dec 28, 2009 at 12:01 PM, Martin Makundi < [email protected]> wrote: > Hi! > > > Can you just achieve what you wan't making siloA, siloB, siloC been > > different "Wicket" applications? > > No, that is not the proper solution. They are the same application. > > > I still see the problem of how this state will be stored on Servlet > Context > > and how do you manage/recover/delete it for a certain "user"... > > We are not interested in recovering user, only recovering session > silo. We do not need to identify user. Only silo. > > > -Use a listener to record "position", and possibly state, for certain > pages. > > Store this into a DB? > > Too complicated. > > ** > Martin > > > > > > > On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi < > > [email protected]> wrote: > > > >> > How exactly do you see this implemented? There will be plenty of > details > >> to > >> > be taken care for. e.g. For how long should this information stay on > >> > that Servlet Context? If your application has many users what > >> information > >> > should go there?... > >> > >> Somehow configure that > >> - my application has following silos {siloA, siloB, siloC} > >> - wicket, please track which silo the user is in and serve appropriate > >> homepage and errorpage when necessary > >> - each silo with its own homepage > >> - each silo with its own error page > >> > >> This could probably be implemented using something as simple as an url > >> parameter/relative url or url encoding scheme. Something similar to > >> the pagemap notation :::0:xxx you would have by default > >> :::siloA:0:xxxx > >> > >> The more transparent for the coder the better. > >> > >> ** > >> Martin > >> > >> > > >> > Ernesto > >> > > >> > On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi < > >> > [email protected]> wrote: > >> > > >> >> > Can you just simply track user activity and store it into a > >> persistence > >> >> > layer that do not expires with session and then once session > expires > >> >> > redirect them to that last page (after they have logged in?)?. > >> >> > >> >> Maybe wicket could do this automatically using Servlet Context? > >> >> > >> >> ** > >> >> Martin > >> >> > >> >> > > >> >> > Best, > >> >> > > >> >> > Ernesto > >> >> > > >> >> > > >> >> > > >> >> > On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler <[email protected]> > >> >> wrote: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> When a client has a page in his browser that he does not touch for > a > >> >> while > >> >> >> and the session expired. after that if he hits an ajax link for > >> example > >> >> - > >> >> >> an > >> >> >> exception occurs in the wicket level due to the session expired > >> state. > >> >> >> > >> >> >> How can I gracefully handle such a situation assuming that there > is > >> no a > >> >> >> single "home page" i can transfer the user. This means that the > >> session > >> >> >> itself had some information on the specific environment the user > was > >> in. > >> >> >> > >> >> >> I can think of adding some information on the ajax link that will > >> >> indicate > >> >> >> that but again the exception happens at the wicket level and if I > am > >> >> >> handling the exception not sure how I can retrieve such data. > >> >> >> > >> >> >> Any good methodology here? > >> >> >> > >> >> >> Thanks, > >> >> >> Arie > >> >> >> > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> 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] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
