[Seaside] Entry and Re-Entry from Legacy Rails App
gilesb at gmail.com
Sun Feb 18 15:59:06 UTC 2007
I don't know the answer, but I think it's a pretty interesting
question. It means the rest of the app is in Rails, and just this one
part is in Seaside?
Smalltalk's got many strengths, but it's never been regarded as a glue
language that I'm aware of. I think you might be best off salting the
data somewhere Seaside can get to it more easily, but I'm making a
pretty wild shot in the dark, because I've never done this and I don't
know what your architecture is. Is Seaside connecting to the same
database Rails is? If you're using DB sessions, you can load the Rails
session from the database without actually making it the Seaside
session -- it's just an arbitrary set of data from which you want to
extract one particular value. Does that help?
On 2/18/07, Ken Treis <ken at miriamtech.com> 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
> 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].
> handleDefaultRequest: aRequest
> | sessionKey existingSession |
> sessionKey := aRequest cookies at: self sessionCookieField
> ifAbsent: [^self redirectToLoginPage: aRequest].
> existingSession := handlersByKey at: (Seaside.WAExternalID fromString:
> 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
More information about the Seaside