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

[Ken Treis]

On Feb 18, 2007, at 7:59 AM, Giles Bowkett wrote:

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

Yes -- that way I can build new stuff in Seaside without having to  
first port forward all of the old stuff.

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

That part I've actually already got figured out.

Seaside and Rails talk to the same database. I'm not using DB  
sessions, but the file-based sessions are pretty easy to read from  
Smalltalk. I've used a similar trick to read PHP sessions from Rails.  
The cookie from the old framework tells you which file to load, and  
the only thing I've ever needed from the old session is the current  
user's ID.

Login is always done in the old framework, and the new framework  
redirects you back to the old if you haven't logged in yet. Logout is  
a two-step process, where the new framework clears its session and  
then redirects to an old framework page that does the same.

As for loading Rails sessions, I've already written a Smalltalk class  
that can read Ruby "Marshal" data, so it's easy to pluck the data  
from the Rails session. It's VisualWorks code, but it should port to  
Squeak pretty easily if anybody's interested.

If I store persistent data in the session explicitly (by adding  
instance variables), then I've accomplished what I needed. But it  
gets ugly as the number of Seaside components grows. And it seems  
like a very non-Seaside way to solve the problem. "Just make a new  
global every time you need to store something!"

That's the main issue I'd like some tips on. The other part that I  
haven't solved yet is how to handle multiple entry points into  
Seaside in a clean way. Rails will link to a particular URL for each  
of these, and I'd like it to work something like this:

URL: /seaside/overlay/someMagicKey
   => rootComponent main call: (SomeComponent new...)

Most of the time, these will be very coarse-grained divisions. In  
other words, I'd use Seaside to build a new area on the site, not  
just to accomplish a small task that's part of a larger Rails  
workflow. The account selector I mentioned is an exception to this  
and will require more data to be pushed back and forth, but I think I  
can handle all of that using URL queries.

It looks like WARenderLoopMain>>start: is the place to handle custom  
URLs, and it also has access to the root component. Maybe that's the  
place to solve both of these things. I might have to play with that  
next.

--
Ken Treis
Miriam Technologies, Inc.