[Seaside] Handling expired Session in Seaside 3.0

[dtrussardi at tiscali.it]

Ciao,

> 
> 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.

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 )


All this my work is relative to manage the 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.

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

> 
> 	
> 
> 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
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120411/817b7def/attachment.htm