[Seaside] Entry and Re-Entry from Legacy Rails App

Ken Treis ken at miriamtech.com
Sun Feb 18 16:03:40 UTC 2007


I realized overnight that I was making this a lot harder than it  
needed to be. If I just configured my Seaside app to use session  
cookies, I'd get the same session at every re-entry. There's no  
reason why the Seaside cookie needs to match the Rails cookie.

But I'd still appreciate some feedback on how to keep some state  
(like the last selected account in my example component below) across  
entries. Is a custom subclass of WASession the best place to store this?


Ken

On Feb 18, 2007, at 12:26 AM, Ken Treis wrote:

> I'm working on adding a Seaside layer to one of my legacy systems  
> (it's fun to call Rails "legacy", eh?). As I try to link back and  
> forth from the old code to the new, I'm finding that I need my  
> session state preserved across exits and entries.
>
> As an example, I have built a hierarchy navigation component in  
> Seaside, and it remembers the account you selected last time you  
> used it. So each time I call the component, the hierarchy is still  
> open to the last account that the user selected.
>
> I'd love to use this from Rails, but each time I follow the link  
> to /seaside/selectAccount, it starts me with a fresh session and I  
> lose my old state. The cool remembering trick never gets to show  
> its stuff.
>
> The solution I've come up with is hackish, which is why I'm asking  
> for input here. Essentially, I'm subclassing WAApplication and  
> using the Rails cookie as the session key. That way, my old session  
> can be found when the user re-enters Seaside.
>
> This works for me, at this point. LegacyOverlay is a subclass of  
> WAApplication:
>
>> sessionCookieField
>> 	^'_session_id'
>>
>> registerRequestHandler: anObject
>> 	| key |
>> 	(anObject isKindOf: Seaside.WASession)
>> 		ifFalse: [^super registerRequestHandler: anObject].
>> 	key := Seaside.WAExternalID
>> 				fromString: (anObject currentRequest cookies at: self  
>> sessionCookieField).
>> 	self shouldCollectHandlers ifTrue: [self unregisterExpiredHandlers].
>> 	self mutex critical:
>> 			[handlersByKey at: key put: anObject.
>> 			keysByHandler at: anObject put: key].
>> 	^key
>>
>> handleDefaultRequest: aRequest
>> 	| sessionKey existingSession |
>> 	sessionKey := aRequest cookies at: self sessionCookieField
>> 				ifAbsent: [^self redirectToLoginPage: aRequest].
>> 	existingSession := handlersByKey at: (Seaside.WAExternalID  
>> fromString: sessionKey)
>> 				ifAbsent: [^super handleDefaultRequest: aRequest].
>> 	^existingSession handleRequest: aRequest
>
> Am I on the right track, or is there an easier way to accomplish  
> this? Since I'm overlaying my Seaside app on an existing system,  
> the app needs to behave as if it has multiple entry points. I just  
> don't want it to start over every time it is entered.
>
> For my account selection component, I'm just storing the last  
> selected account in an instance variable in the session. That means  
> that simply locating the previous session is enough to make my  
> component do its magic. At some point I'd rather do something less  
> "global", like an instance variable in a component that I  
> instantiate once and repeatedly call, but I'm not familiar enough  
> with the internals quite yet to make it work that way.
>
> --
> Ken Treis
> Miriam Technologies, Inc.
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Ken Treis
Miriam Technologies, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070218/8665cec6/attachment.htm


More information about the Seaside mailing list