Session expiry

> >  ^ MyPage with: self new
> >
> > Thanks - Sophie
> >
> >  
> Why reinvent the wheel?
>
> Keith

To learn!

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Override #handleExpiredRequest: in WAApplication.
>
> Brilliant, exactly what I was looking for. Hopefully I'll have more
> time to try it out tomorrow - thanks for your time and patience with
> an impatient Seaside newbie :-)
>

Gruezi (hope I got that right...) Lukas,

Would the following approach (or something along those lines) makes sense?

-----

1) Add a method to WAComponent class:

expiryPathFor: aRequest
        "Answer nil by default (this will let WAApplication>>expiryPathFor: handle
        the expired request; see this method for more details. Override to provide
        a custom URL for expired sessions."

        ^nil

2) Override WARegistry>>expiryPathFor: on WAApplication:

expiryPathFor: aRequest
        "Check whether my root component class overrides this method. If so, use its
        value; otherwise, use the default supplied by my superclass."

        ^(self rootComponent expiryPathFor: aRequest)
                ifNil: [super expiryPathFor: aRequest]

Then, if an application wants to, it could simply do something like
this in its root component:

expiryPathFor: aRequest
        "Overrides default to provide a custom URL for expired sessions."

        ^aRequest url, '/sessionExpired'

-----

(I haven't checked whether the URL can contain parameters, obviously
that would have to be handled if it does, but the idea remains the
same.)

I'd also prefer to get the session instance rather than just the root
component class, but haven't yet discovered how to do that from
WAApplication (is there a way?). With the method from 1) moved from
the component class to the session instance, I'd be able to override
this in my custom session class and make the session expiry behaviour
dependent on whether or not a user is logged in and/or other factors.

Cheers,

Amos
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Gruezi (hope I got that right...) Lukas,

I am from Bern and we say "Gruesech", which is a bit different from
the "Gruezi" in Zurich.

> I'd also prefer to get the session instance rather than just the root
> component class, but haven't yet discovered how to do that from
> WAApplication (is there a way?). With the method from 1) moved from
> the component class to the session instance, I'd be able to override
> this in my custom session class and make the session expiry behaviour
> dependent on whether or not a user is logged in and/or other factors.

There is actually a property in the application called
#redirectHandler that should be used for that kind of redirects. It
looks like this is currently not done in Seaside 2.8, what is clearly
a bug. We will fix that in 2.9, as it requires to refactor WARegistry
and WAApplication that are in quite a strange relationship right now.

For now I suggest that you create a custom application class and copy
and override the method handleExpireRequest: to do whatever you want.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Keith Hodges" <[hidden email]> wrote in message

> Why reinvent the wheel?

Mostly because my post crossed yours :) I did however end up doing my own
round-about implementation, and have learned better options now.

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside