[Seaside] Seaside config for Comet (Seaside 2.9 A3)

Keith Hodges keith_hodges at yahoo.co.uk
Sun Apr 19 01:20:19 UTC 2009

John Toohey wrote:
> Keith,
> Respectfully, I disagree. I just started a few months ago with
> Seaside, and the configuration app helped me through some of the
> tutorials, I found on the web. Even some of the sample apps, Google
> charts for instance, require you to use the configuration app to get
> it working. I agree that once you know how to configure you own
> application, then doing it via a class method is the way to go.
> Documentation aside, its not obvious what is required to add support
> for the various libraries, and your own session objects etc.,
Hello John,

lets give you a little hint of how this works in Beach (and Jetsam of old)

there is method


^ false

Now if you change that to true, comet is enabled, and you don't need any
special session class.

If you want to use ShoreComponents there is a method


^ false

If you change that to true, you dont need any special session classes,
you dont need to add any libraries, they are automatically added.

The interface to the server WAKom etc can be set up to look at
#prefEnableCometHelper, and it should know that a WAListener is required
for that helper to work.

You use code to write your whole application, and then when you move
your image to the deployed machine you have to switch to using a config
application in which half the settings need to be changed for
deployment. So why put that conceptual and actual discontinuity of tools
in there at all, its not as if these are even end user settings.

The advantage of code is that it can embody the knowledge needed to set
up the application. Dependencies between settings etc can be included.
It could also include documentation about the settings and options

You can also provide already working setups which can be adjusted via
subclassing, why do you have to configure anything to use Google Charts?


More information about the seaside mailing list