Deployment and Maintenance

How to exclude applications from the Seaside main dispatcher?

Before deploying for production, it is not a bad idea to remove from the Seaside dispatcher all those applications that are not strictly needed. Otherwise, users may accidentally enter the "counter" or the "store" demo applications.

First of all, you will have to explicitely designate those Seaside applications that are deployed. This is achieved by re-implementing the #isDeployed class method in the root component of the deployed applications. By default, this class method answers false, only the dispatcher editor ("config") and the dispatcher navigator ("browse") answer true.

Then, to remove applications from the Seaside dispatcher, evaluate the following:

WADispatcher default trimForDeployment.

This will remove all those applications that answer false to message #isDeployed.

How to deploy Seaside Cincom Smalltalk behing Apache?

You can run Seaside under Cincom Smalltalk behind Apache using either the the CGI gateway or the CGI Perl Interface.

There is however some potential difficulties to take into consideration. By default, Seaside is designed to use only one WADispatcher object and the WADispatcher object has a hard-coded base URI. Therefore, if you start your image, access Seaside through TinyHttpServer, then access Seaside through Apache, the access through Apache should fail because the WADispatcher object has been initialized with the TinyHttpServer URI and does not recognize the Apache URI.

For instance if the first Seaside visitor comes in through TinyHttpServer with a request for ’seaside/go/counter’, the WADispatcher base path will be ’seaside/go’. When another visitor comes in through Apache with a request for ’cgi-bin/Cincom’, Seaside uses the REQUEST_URI environment variable and the WADispatcher does not find any match.

The problem would be solved if the Apache request would come with REQUEST_URI equals to ’seaside/go/counter’. This might be possible by modifying the perl script so that it modifies the REQUEST_URI variable before transfering the HTTP request to Cincom Smalltalk.

This issue was solved differently by implementing the concept of alternate servlet. See the Seaside mailing list post.

With this concept there are two SeasideServlet instances rather than just one. Each instance has its own separate WADispatcher object. As a result you may serve Seaside applications through two different base URIs.

The alternate servlet support has been included in VW 7.3.

The parcel for alternate servlet support is inside the BonusPack folder and is named SeasideShortPath. You will need to use a different URI when coming through Apache, something like for ’/cgi-bin/Cincom’ rather than for ’cgi-bin/Cincom’. With the later, Seaside would attempt to use the default servlet and would fail. With the former, it will drop into the alternate servlet and initialize a new WADispatcher with the right base path. Having explained all this, I believe that the best solution will be to have multiple WADispatcher objects available for the SeasideServlet providing support for multiple channels into Seaside.