[Seaside] Re: Porting Seaside
Esteban A. Maringolo
eMaringolo at smalltalking.net
Tue Nov 1 22:44:03 CET 2005
Bany, Michel escribió:
> Hello Esteban,
> Good to hear that you volunteered for the Dolphin port.
I didn't know that existed a vacancy ;-)
> I can explain a bit what I do for the port to VW.
> The first thing is to "prepare" VW for Seaside. This means
> making VW look like Squeak, i.e. add the methods that are available
> in Squeak and lacking in VW. There are quite many. This also means
> a port of the Squeak Chronology classes, to properly support the
Well DateAndTime and Duration is already on my Dolphin image. (a 3rd
This is one of the points I want to preserve, I don't want an image
with all that many Squeak methods if there are an existing way to
accomplish the same. Many will be ported, some of them are clever,
other are abuse :-)
> I also re-implemented some of the Squeak class browser
> so that we can exploit the Seaside class browser. You will need
> to be creative to handle the toolbar icons.
Well, this kind of stuff should be modular enough, to be ported
using compatibility environment, or reimplemented to use the
specific smalltalk facilities (RB, etc).
> In the VW port, the bundle named "Seaside-VW" does the preparation
> Most of the "Seaside-VW" bundle is the result of manual work and
> some negotiation with Avi to make sure that Seaside remains VW friendly.
I Hope Seaside (and Avi) get new friends ;-)
> Only the Chronology part was automated, using the package exporter
> with a package info of mine.
How deep is the usage of Chronology?
> The second thing is to export the Seaside package from Squeak. This
> is achieved using the Package exporter from Avi. I am using my
> own version of it (PackageInfo-Exporters-mb.12 in
> so that it works not only for Seaside but also for other things
> like MEWA and SeasideTesting.
> I am afraid there is no exporter for Dolphin,
> so you may have to subclass PackageExporter and
> PackageInfo somehow.
> The output of the export process is a text file
> that can be filed-in into the "prepared" VW.
I could write my own.
> The Seaside-VW bundle
> contains methods and scripts for doing the file-in. In some cases
> the file-in may be unsucessful, for instance when some unsupported
> Squeak syntax is used. In these situations, I create a new version
> of the Seaside package and I retry the export. It may take several
> iterations, that's why I try to avoid porting the very latest version
> of Seaside and focus on versions that have been untouched for a long
> time. These days I was porting 2.5b8. After a successful file-in
> into VW, this becomes a bundle named "Seaside".
Well, having done a just a little, I have in mind the same approach,
It will be conservative, but I'm an old Debian Linux user... ;-)
> The third step consists in translating the Seaside requests and
> responses into the underlying web platform.
This is almost complete. I'll check your VW Swazoo port, to see how
it handles multiple cookies, when Swazoo doesn't support this by
> At the moment, two platforms are
> supported Swazoo and Cincom WebToolkit. These are the bundles named
> "Seaside-Swazoo" and "Seaside-WebToolKit". You may want to have a look
> to the "Seaside-Swazoo" bundle for your project.
Ok, I'll look at it. I've done some stuff with Seaside and VW, but
> Beside supporting
> the underlying platform, the third bundle also includes fixes/patches
> to Swazoo or WebToolKit and fixes to Seaside. In the latest ports
> I could completely eliminate fixes to Seaside by including those
> fixes directly into the Squeak package.
I'll do the same if I find a bug.
For example, all RFC822 compliant timestamps/dateAndTimes prints
always using GMT, without specifying the local bias to Greenwich
(here is GMT-3). I don't know if it's a bug or a feature.
> Feel free to ask if you need any further help.
Count with it, I will.
More information about the Seaside