Re: Handling Ajax session expired
Hi! What is the best way to change the PageExpiredErrorPage or InternalErrorPage depending on a silo? Application.getApplicationSettings() is shared among all silos. ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor On Mon, Dec 28, 2009 at 5:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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 - 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
Re: Handling Ajax session expired
Ah.. probably RequestCycle.onRuntimeException is the key. ** Martin 2010/1/24 Martin Makundi martin.maku...@koodaripalvelut.com: Hi! What is the best way to change the PageExpiredErrorPage or InternalErrorPage depending on a silo? Application.getApplicationSettings() is shared among all silos. ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor On Mon, Dec 28, 2009 at 5:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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 - 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
SV: Handling Ajax session expired
I guess the servlet container handles jsessionid transparently. Yes, coming in (either cookie or in the URI) and setting the cookie; but it does not normally add it to links in the output from your webapp, that is the framework or developer's responsibility. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Handling Ajax session expired
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
Re: Handling Ajax session expired
Hi! Yes, I hate this situation too. Our application has various different silos and whenever the user session expires, he loses his silo and is redirected to a generic homepage and an inexperienced user will never know how to get back to where he was. Some information should be in the url. I wonder if there is something built-in-wicket for this purpose or do we need an rfe? ** Martin 2009/12/28 Arie Fishler arie@gmail.com: 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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?)?. You could add a check that sees if the user had some pending actions (that are cleaned out if he signs out) and ask him to resume what the was doing. Of course, you will have to re-create the state of the page they were at which might not be easy if that page changed a lot via AJAX interaction e.g. if page contained a table they navigated or filtered via AJAX you will have to take that into account... or just put them in a sort of initial state. Another possibility is to add an AJAX hart bit to such pages to make sure session does not expire while the user is using them... Best, Ernesto On Mon, Dec 28, 2009 at 9:48 AM, Arie Fishler arie@gmail.com 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
Re: Handling Ajax session expired
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 arie@gmail.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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?... Wouldn't it be simpler to have a component instantiation listener, mark the pages you need with some interface and start a kind of recorder whenever the user hits one of those pages... I see no much difficulty on implementing this last approach... Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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
Re: Handling Ajax session expired
Hi Martin, Can you just achieve what you wan't making siloA, siloB, siloC been different Wicket applications? 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... How is this generic user defined? Isn't this a concept that is application dependent? I think what you describe can be easilly achieved with the listener approach I mentioned. -Use a listener to record position, and possibly state, for certain pages. Store this into a DB? -If session expires have some logic that redirects you to the pages you want (error, home, etc) based on stored positioning and state. Ernesto On Mon, Dec 28, 2009 at 11:03 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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
Re: Handling Ajax session expired
Hi, i have the same problems for our heavy ajax wicket site. I use wicket-ajax so the stateless flag can not be used. If the session expires i make some assumptions: * all user generated content is thrown away. (e.g. shopingbasket) * the pagecomponents the user is on is in initial hierarchie, otherwise i get also a pageexpired exception. On click on a ajax link i implement a logic, to rebuild the page for the ajaxlink. And then the event would processed as before. My issues: * if i replace components with ajax-requests before, the beheaviour could also fire a pageexpired exception. But then i redirect to the last known ( rebuilded) Wicketpage. What issues you see in this solution ? We have made some other workarounds for AJAX: * Using JQuery ajax-calls to wicket-resources * Caching a lot of content and switching visibily only on client side with jquery Martin Arie Fishler schrieb: 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
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 martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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
Re: Handling Ajax session expired
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 martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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
Re: Handling Ajax session expired
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 martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Neither do I... but maybe AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle requestCycle) is the method to override? Best, Ernesto On Mon, Dec 28, 2009 at 12:32 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 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 martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
That's where we have our workaround, currenlty. And it is ugly. But where could we bind the silo information into urls globally? ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Neither do I... but maybe AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle requestCycle) is the method to override? Best, Ernesto On Mon, Dec 28, 2009 at 12:32 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 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 martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com 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: The more transparent for the coder the better. ** Martin Ernesto On Mon, Dec 28, 2009 at 10:16 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 arie@gmail.com 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: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe,
Re: Handling Ajax session expired
But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto
Re: Handling Ajax session expired
It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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
Re: Handling Ajax session expired
Maybe if you replace users's silo with user location and then say Example, if location=silo... things will be a little less bound to your use case... Otherwise your description of what you want to achieve looks fine fine to me... but I'm no core developer... So, why not wait to see what do they comment on this issue? Best, Ernesto On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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
Re: Handling Ajax session expired
2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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
Re: Handling Ajax session expired
I think this suggestion is worth condsidering more carefully: 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. OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. Good luck Jim P On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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
Re: Handling Ajax session expired
Might work, but I do not know if it has any consequences such as will the user have a single wicketsession? ** Martin 2009/12/28 Jim Pinkham pinkh...@gmail.com: I think this suggestion is worth condsidering more carefully: 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. OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. Good luck Jim P On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Actually, I think Martin has a solution but he doesn't like it: because it is not a clean solution. What he is asking for, if I didn't get it wrong at the end, is been able to have more than one HomePage, ErrorPage, and so on based on incoming URLs. But this included as a framework feature... not hacked at by the developed (as the one hi has in place now). Best, Ernesto On Mon, Dec 28, 2009 at 3:57 PM, Jim Pinkham pinkh...@gmail.com wrote: I think this suggestion is worth condsidering more carefully: 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. OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. Good luck Jim P On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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
Re: Handling Ajax session expired
I guess wicketsessions will be different. I know I proposed to do that but not sure is the best solution. I your case I would surelly opt for the solution you have in place right now. Ernesto On Mon, Dec 28, 2009 at 4:09 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Might work, but I do not know if it has any consequences such as will the user have a single wicketsession? ** Martin 2009/12/28 Jim Pinkham pinkh...@gmail.com: I think this suggestion is worth condsidering more carefully: 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. OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. Good luck Jim P On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Hi, 2009-12-28 15:57 keltezéssel, Jim Pinkham írta: OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. this wouldn't work easily, because for example when you have EJBs in your project, you can't deploy the same app to different contextroots, because the EJBs JNDI name is already bounded, so this way you would have to run your slightly different apps on different appservers too, and that's just ugly. I think Martin has a point there, maybe Wicket should support this use-case. Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
I am more worried about the session duplication. I want to get multi-homed single application look and feel. Single wicketsession per user. ** Martin 2009/12/28 Pieter Degraeuwe pieter.degrae...@systemworks.be: Hmm, that's not correct. Different frontend apps should use the same EJB's. In that case, It's not so ugly anymore in my opinion. (I don't want to advocate the use of EJB's though..) 2009/12/28 Major Péter majorpe...@sch.bme.hu Hi, 2009-12-28 15:57 keltezéssel, Jim Pinkham írta: OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. this wouldn't work easily, because for example when you have EJBs in your project, you can't deploy the same app to different contextroots, because the EJBs JNDI name is already bounded, so this way you would have to run your slightly different apps on different appservers too, and that's just ugly. I think Martin has a point there, maybe Wicket should support this use-case. Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pieter Degraeuwe Systemworks bvba Belgiëlaan 61 9070 Destelbergen GSM: +32 (0)485/68.60.85 Email: pieter.degrae...@systemworks.be visit us at http://www.systemworks.be - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Hmm, that's not correct. Different frontend apps should use the same EJB's. In that case, It's not so ugly anymore in my opinion. (I don't want to advocate the use of EJB's though..) 2009/12/28 Major Péter majorpe...@sch.bme.hu Hi, 2009-12-28 15:57 keltezéssel, Jim Pinkham írta: OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. this wouldn't work easily, because for example when you have EJBs in your project, you can't deploy the same app to different contextroots, because the EJBs JNDI name is already bounded, so this way you would have to run your slightly different apps on different appservers too, and that's just ugly. I think Martin has a point there, maybe Wicket should support this use-case. Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pieter Degraeuwe Systemworks bvba Belgiëlaan 61 9070 Destelbergen GSM: +32 (0)485/68.60.85 Email: pieter.degrae...@systemworks.be visit us at http://www.systemworks.be
Re: Handling Ajax session expired
Right, right, my bad. But then you should create three different webmodules for a single application, that's why wicket would be loaded 3 times only for this separation.. It's just unneccesary resource usage IMHO. 2009-12-28 16:30 keltezéssel, Pieter Degraeuwe írta: Hmm, that's not correct. Different frontend apps should use the same EJB's. In that case, It's not so ugly anymore in my opinion. (I don't want to advocate the use of EJB's though..) 2009/12/28 Major Péter majorpe...@sch.bme.hu Hi, 2009-12-28 15:57 keltezéssel, Jim Pinkham írta: OK, but could you deploy multiple copies of the same app to different root contexts - that would give you the info you want in each URL and thus be able to do different home/error pages with some config along with each copy of the app. Seems worth exploring whether your Silos might divide well in this manner, maybe with a bit of work, but probably more likely to happen than what it seems like you are looking for, which doesn't sound (just one casual observer's option) broadly applicable enough to warrant framework inclusion. this wouldn't work easily, because for example when you have EJBs in your project, you can't deploy the same app to different contextroots, because the EJBs JNDI name is already bounded, so this way you would have to run your slightly different apps on different appservers too, and that's just ugly. I think Martin has a point there, maybe Wicket should support this use-case. Regards, Peter - 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
Re: Handling Ajax session expired
use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor On Mon, Dec 28, 2009 at 5:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: but I'm no core developer... So, why not wait to see what do they comment on this issue? Maybe they just want us to weather this out on ourselves ... ;) ** Martin On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would you formulate such RFE? Wicket needs an autonomus but parametrizable global behavior, that is transparent to all url encoding schemes, that can be used to identify users's silo in the application. When session is invalidated or other errors occur, each silo can have its own errorpage/homepage which is automatically rendered by the behavior. Is this descriptive enough? Maybe some junit wickettester test cases? - test 1: User has begun using Silo1Homepage.class when session is invalidated. User is redirected back to Silo1Homepage. - test 2: User has begun using Silo2Homepage.class when session is invalidated. User is redirected back to Silo2Homepage. - similar for error pages, and after error page - silo-home-page - etc. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: Create a RFE? Maybe on 1.5 it is already possible? Ernesto On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be automatic and global, like a url encoding scheme, and it should come with an interpreter that will process the homepage/errorpage when necessary. ** Martin 2009/12/28 Ernesto Reinaldo Barreiro reier...@gmail.com: But where could we bind the silo information into urls globally? Mounting pages? Or better having some kind of configuration class that you use to mount the pages and do the ugly URL plumbing on that method? Best, Ernesto - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Ok, something could be built on that. Not as robust as an url but works. Requires a nice design in the request processing. Still RFE? ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
rfe? for what? cookies have nothing to do with wicket. -igor On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Ok, something could be built on that. Not as robust as an url but works. Requires a nice design in the request processing. Still RFE? ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor - 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
Re: Handling Ajax session expired
On Mon, Dec 28, 2009 at 9:41 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. -igor ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: use a cookie. every time a user enters a silo set it in a silo cookie. when the session expires, the cookie will still be there. -igor - 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
Re: Handling Ajax session expired
rfe? for what? cookies have nothing to do with wicket. Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. RFE for built-in support of multi-homing in wicket, out-of-the-box. ** Martin -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
that does what? so we provide sethome(string) and gethome(string) which are analogues to setcookie(cookie) and getcookies() which does not lock you into a single way of doing multihoming. there is some code you have to write to build an application -igor On Mon, Dec 28, 2009 at 9:56 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: rfe? for what? cookies have nothing to do with wicket. Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. RFE for built-in support of multi-homing in wicket, out-of-the-box. ** Martin -igor - 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
Re: Handling Ajax session expired
- sethome(string) needs to be called at a particular point in the request cycle, could be built-in or not? - gethome() with homepage handling needs to be done in a particular manner in the request cycle, could be built-in or not? - alternative url encoding scheme, could be built-in or not? does not lock you into a single way of doing multihoming. It would be nice to have a properly working default multihoming support, out-of-the-box. I would guess it's quite common need in any bit complex application. Or maybe it can be worked around using styles? Storing user style into application context and serving home pages accordingly? ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: that does what? so we provide sethome(string) and gethome(string) which are analogues to setcookie(cookie) and getcookies() which does not lock you into a single way of doing multihoming. there is some code you have to write to build an application -igor On Mon, Dec 28, 2009 at 9:56 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: rfe? for what? cookies have nothing to do with wicket. Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. RFE for built-in support of multi-homing in wicket, out-of-the-box. ** Martin -igor - 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
Re: Handling Ajax session expired
yah.. styles won't work either.. they're in the session so when invalidation occurs...the data is lost. So Wicket needs some built-in method to pass tokens between sessions. ** Martin 2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com: - sethome(string) needs to be called at a particular point in the request cycle, could be built-in or not? - gethome() with homepage handling needs to be done in a particular manner in the request cycle, could be built-in or not? - alternative url encoding scheme, could be built-in or not? does not lock you into a single way of doing multihoming. It would be nice to have a properly working default multihoming support, out-of-the-box. I would guess it's quite common need in any bit complex application. Or maybe it can be worked around using styles? Storing user style into application context and serving home pages accordingly? ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: that does what? so we provide sethome(string) and gethome(string) which are analogues to setcookie(cookie) and getcookies() which does not lock you into a single way of doing multihoming. there is some code you have to write to build an application -igor On Mon, Dec 28, 2009 at 9:56 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: rfe? for what? cookies have nothing to do with wicket. Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. RFE for built-in support of multi-homing in wicket, out-of-the-box. ** Martin -igor - 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
Re: Handling Ajax session expired
we have one, its called cookies -igor On Mon, Dec 28, 2009 at 10:22 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: yah.. styles won't work either.. they're in the session so when invalidation occurs...the data is lost. So Wicket needs some built-in method to pass tokens between sessions. ** Martin 2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com: - sethome(string) needs to be called at a particular point in the request cycle, could be built-in or not? - gethome() with homepage handling needs to be done in a particular manner in the request cycle, could be built-in or not? - alternative url encoding scheme, could be built-in or not? does not lock you into a single way of doing multihoming. It would be nice to have a properly working default multihoming support, out-of-the-box. I would guess it's quite common need in any bit complex application. Or maybe it can be worked around using styles? Storing user style into application context and serving home pages accordingly? ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: that does what? so we provide sethome(string) and gethome(string) which are analogues to setcookie(cookie) and getcookies() which does not lock you into a single way of doing multihoming. there is some code you have to write to build an application -igor On Mon, Dec 28, 2009 at 9:56 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: rfe? for what? cookies have nothing to do with wicket. Not as robust as an url but works. you can build your own url conding strategy that postprocesses urls in any way you want. RFE for built-in support of multi-homing in wicket, out-of-the-box. ** Martin -igor - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Can we get access to the jsessionid? Maybe we could use that to track cookieless users. ** Martin 2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
Haha, but jsessionid is probably destroyed when session dies.. ** Martin 2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com: Can we get access to the jsessionid? Maybe we could use that to track cookieless users. ** Martin 2009/12/28 Martin Makundi martin.maku...@koodaripalvelut.com: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
so you think there are people out there that will use ajax but not allow cookies... -igor On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - 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
Re: Handling Ajax session expired
Yes, many companies' security policies allow javascript but not cookies. ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: so you think there are people out there that will use ajax but not allow cookies... -igor On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - 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
Re: Handling Ajax session expired
lol, i guess you cant use most major sites out there eh? -igor On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Yes, many companies' security policies allow javascript but not cookies. ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: so you think there are people out there that will use ajax but not allow cookies... -igor On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
jsessionid works ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: lol, i guess you cant use most major sites out there eh? -igor On Mon, Dec 28, 2009 at 11:01 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Yes, many companies' security policies allow javascript but not cookies. ** Martin 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: so you think there are people out there that will use ajax but not allow cookies... -igor On Mon, Dec 28, 2009 at 10:35 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I agree. But what about cookie-less users. Just forget about them? 2009/12/28 Igor Vaynberg igor.vaynb...@gmail.com: we have one, its called cookies -igor - 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 - 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
SV: Handling Ajax session expired
jsessionid works ... but leads to lots of boilerplate where you need to rewrite all URLs targeted at your app's code. I guess Wicket can do that for you, but still... - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling Ajax session expired
I guess the servlet container handles jsessionid transparently. ** Martin 2009/12/28 Wilhelmsen Tor Iver toriv...@arrive.no: jsessionid works ... but leads to lots of boilerplate where you need to rewrite all URLs targeted at your app's code. I guess Wicket can do that for you, but still... - Tor Iver - 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