Re: Handling Ajax session expired

2010-01-24 Thread Martin Makundi
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

2010-01-24 Thread Martin Makundi
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

2009-12-29 Thread Wilhelmsen Tor Iver
 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

2009-12-28 Thread Arie Fishler
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Makundi
 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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Makundi
 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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Sachs
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Makundi
 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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Ernesto Reinaldo Barreiro


 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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Martin Makundi
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 Thread Ernesto Reinaldo Barreiro
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 Thread Martin Makundi
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

2009-12-28 Thread Jim Pinkham
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Ernesto Reinaldo Barreiro
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

2009-12-28 Thread Major Péter
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Pieter Degraeuwe
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

2009-12-28 Thread Major Péter
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
 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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
- 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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Igor Vaynberg
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

2009-12-28 Thread Martin Makundi
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

2009-12-28 Thread Wilhelmsen Tor Iver
 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

2009-12-28 Thread Martin Makundi
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