> 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?
I do not know how it can be done, but some information needs to be stored in the URL (all ajax and non-ajax link, button and submit urls) because that's the only information left in Wicket when session dies. ** Martin > > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
