[Seaside] Entry and Re-Entry from Legacy Rails App
gilesb at gmail.com
Sun Feb 18 19:19:46 UTC 2007
Ken, I'm actually moving today, but I'm hoping to get a longer/more
useful reply off to you later this evening. In the meantime I just
want to suggest -- have you looked at Pier? I know Pier provides REST
support, so it could contain classes you can use to handle the URL
side of the equation.
By the way I'd definitely be interested to see the Marshall-reading
stuff. I'm using Squeak, so I'll be able to test its portability
pretty quickly. It's probably pretty straight-forward, but I'm still a
bit of a n00b with Smalltalk, so it'll help me learn as well.
On 2/18/07, Ken Treis <ken at miriamtech.com> wrote:
> 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
> Ken Treis
> Miriam Technologies, Inc.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside