Handling expired Session in Seaside 3.0
Locked
Handling expired Session in Seaside 3.0
 
|
All,
if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. Any pointers? CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
Udo,
As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. Now, this is all theory, I have no experience doing that myself ;-) Let us know if you succeed. Johan On 02 Nov 2010, at 21:41, Udo Schneider wrote: > All, > > if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. > > Any pointers? > > CU, > > Udo > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
This is a common request... it might be nice to extend the
Application's configuration so you can specify, as well as a root component, a component to be used in case of an expired session. Anyone have thoughts? Julian On Wed, Nov 3, 2010 at 7:35 AM, Johan Brichau <[hidden email]> wrote: > Udo, > > As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. > Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) > > Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. > > Now, this is all theory, I have no experience doing that myself ;-) > Let us know if you succeed. > > Johan > > On 02 Nov 2010, at 21:41, Udo Schneider wrote: > >> All, >> >> if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. >> >> Any pointers? >> >> CU, >> >> Udo >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
Hi Julian,
Wouldn't a full component lead to a circular problem involving expired sessions for that component? I guess a handler like an error handler would do the job, no? On 03 Nov 2010, at 09:43, Julian Fitzell wrote: > This is a common request... it might be nice to extend the > Application's configuration so you can specify, as well as a root > component, a component to be used in case of an expired session. > Anyone have thoughts? > > Julian > > On Wed, Nov 3, 2010 at 7:35 AM, Johan Brichau <[hidden email]> wrote: >> Udo, >> >> As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. >> Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) >> >> Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. >> >> Now, this is all theory, I have no experience doing that myself ;-) >> Let us know if you succeed. >> >> Johan >> >> On 02 Nov 2010, at 21:41, Udo Schneider wrote: >> >>> All, >>> >>> if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. >>> >>> Any pointers? >>> >>> CU, >>> >>> Udo >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
In reply to this post by Johan Brichau-2
Johan,
Thanks for the pointer to WAApplication#handleExpired:. I'll take a look at it. Thanks, Udo On 03.11.10 08:35, Johan Brichau wrote: > Udo, > > As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. > Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) > > Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. > > Now, this is all theory, I have no experience doing that myself ;-) > Let us know if you succeed. > > Johan > > On 02 Nov 2010, at 21:41, Udo Schneider wrote: > >> All, >> >> if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. >> >> Any pointers? >> >> CU, >> >> Udo >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
In reply to this post by Johan Brichau-2
Well, you don't need a session to render a component. It's just a
renderable object so you could hand it to a Builder to generate content. I'm not *sure* that's better than another kind of object, but it does seem to be what people ask for and in the case where you just want to render something, it does seem logical enough. Julian On Wed, Nov 3, 2010 at 9:18 AM, Johan Brichau <[hidden email]> wrote: > Hi Julian, > > Wouldn't a full component lead to a circular problem involving expired sessions for that component? > > I guess a handler like an error handler would do the job, no? > > On 03 Nov 2010, at 09:43, Julian Fitzell wrote: > >> This is a common request... it might be nice to extend the >> Application's configuration so you can specify, as well as a root >> component, a component to be used in case of an expired session. >> Anyone have thoughts? >> >> Julian >> >> On Wed, Nov 3, 2010 at 7:35 AM, Johan Brichau <[hidden email]> wrote: >>> Udo, >>> >>> As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. >>> Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) >>> >>> Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. >>> >>> Now, this is all theory, I have no experience doing that myself ;-) >>> Let us know if you succeed. >>> >>> Johan >>> >>> On 02 Nov 2010, at 21:41, Udo Schneider wrote: >>> >>>> All, >>>> >>>> if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. >>>> >>>> Any pointers? >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
In reply to this post by Johan Brichau-2
Ciao, > Udo, > > As far as I know, you would need to create a specific subclass of WAApplication and override #handleExpired: to do what you want. > Then use that specific subclass to register your main component as an application (the standard WAAdmin>>register:asApplicationAt: uses WAApplication) I change the WARegistry #handleExpired: for do some test about the management of expired Session. Now it redirect to a specific url or to a WA entry. For example: handleExpired: aRequestContext aRequestContext redirectTo: 'http://www.localtest.com'. The relative WAComponent subclass ( register with the speciific WAAdmin>>register:asApplicationAt ) define and display some component with Scriptaculous AJAX request and some anchor . Now after the session expired all the request are intercepted by the handleExpired: method. The anchor request work fine and the page is update. The problem is relative to the AJAX request because the redirectTo: don't do anything and the page isn't update. Some consideration about it ? Thank, Dario > > Overriding #initialRequest: on your initial component might be of help to know if the request was for an expired session. But you probably need to pass some info in the request in the #handleExpired: method. > > Now, this is all theory, I have no experience doing that myself ;-) > Let us know if you succeed. > > Johan > > On 02 Nov 2010, at 21:41, Udo Schneider wrote: > >> All, >> >> if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. >> >> Any pointers? >> >> CU, >> >> Udo >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
Ciao,
OK, i found the problem. It's relative to the Ajax request because it's based on html evaluator. I define it with html updater and the page is update. ....... onChange: (
html updater
id: 'elementToUpdate';
triggerFormElement: id;
callback: [:r | rfrMasterHtml updateView: r]
)]. Now, when the session is expired and the user click on the link with html updater definition, the redirectTo: is display in the DIV with the id declared by html updater ( 'elementToUpdate' in this case ) My goal is to redirect to a specific url when the user click any component relative to one expired session. The solution to keep alive the session with: (html scriptaculous periodical interval: 30 seconds; callback:[:x| self transcript] )). don't complete solve the problem because for some situation this periodical update can may be lost and the user can click on component relative to one expired session in some cases. Manage the WAApplication subclass handleExpired: aRequestContext intercept all activity relative to one expired session, the problem is relative to component with ajax html updater because the redirectTo: url don't update the page but is rendering in the DIV relative to html update statement. How i can redirect and display the page in all cases ? Thank, Dario
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Handling expired Session in Seaside 3.0
|
|
Ciao, sorry for the replication, i hope to be more clear and concise. I do some test to manage the request relative to one expired session. My goal is to redirect to a specific url when the user click any component relative to one expired session. The solution to keep alive the session with: (html scriptaculous periodical interval: 30 seconds; callback:[:x| self transcript] )). don't complete solve the problem because for some situation this periodical update can may be lost and the user can click on component relative to one expired session in some cases. I create a WAApplication subclass for define the handleExpired: aRequestContext method. Now it's set : handleExpired: aRequestContext
" redirect all expire request to a specific url" aRequestContext redirectTo: anUrl
This intercept all activity relative to one expired session and redirect to a specific anUrl. The problem is relative to component with ajax html updater definition. For example; ....... onChange: ( html updater
id: 'elementToUpdate';
triggerFormElement: id;
callback: [:r | rfrMasterHtml updateView: r]
)]. because when the session is expired and the user trigger the onChange, the application handlerExpired: intercept the request, but the aRequestContext redirectTo: url don't update the html page but is rendering in the html DIV relative to html updater statement ( 'elementToUpdate' in this case ). Question for action relative to one expired session : A) for onChange trigger i can rendering the aRequestContext redirectTo: anUrl at the top of the page B) if i lose completely the internet connection i can display a message to the user. Thanks for any consideration, Dario _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |