[Seaside] [Ann] Beach-Seaside

Keith Hodges keith_hodges at yahoo.co.uk
Tue Mar 31 06:06:15 UTC 2009

Ok so someone has already got "beach" on google code, so I grabbed


So Beach or Beaches? What do you prefer?

In the following introduction(s) I will use "Beach".




"Beach" - Frameworks, and components for putting seaside to commercial use.
"Beach" will eventually be showcased by an all new "Sushi Store"... (or
Surf Store)


Central to "Beach" is the idea of a Site, the "Beach-Site" if you like,
this is the main class for a Beach website. Let's give it a name:

BESiteSeaside subclass: #BEBondi

Key Feature - Easy Installation

BEBondi knows how to configure itself as a seaside application (or a
pier application), it knows how to initialize its databases if required.

[the manual way: add BESiteConfiguration to a seaside application]

Key Feature - Upload and Go

BEBondi, knows when it is deployed, by checking its IP address.
BEBondi, manages the preferences for the application, in code. (no need
for seaside/config). Combining the two e.g.


    ^ self isDeployed ifTrue: [ 'smtp.blahmail.com' ] ifFalse: [
'server.flat' ]

Upload your image to your server, and all the preferences can be set for
the deployed state in advance.

*seaside/config displays which settings are controlled by the "site"
instance BEBondi.
Anywhere in seaside, your per-session instance of BEBondi is available via:

self site

Anywhere outside of a seaside session (i.e. in a workspace) a
per-session instance of BEBondi (with a seaside psuedo session) is
available via:

BEBondi current.

Key Feature - Switchable Backends

While your site is running in #live mode. You can hit the site with
db=mock in the url and have a private test session, running from an in
memory mock backend.

Standard backend modes are:

1) #live
2) #test
3) #backup
4) #mock

These can also be selected in seaside/config.

live/test/backup are expected to be the same db engine (or engines) but
with databases simply named with suffixes "-test" "-backup" e.g.
sushi_store, sushi_store-test, and sushi_store-backup

Key Features - Plug In Backend/Frontend Components

See next emails

Key Features - Expose as much as possible to customization by subclassing
The "site" is effectively a "factory" hub for everything. So you can
subclass it, and customise it to use whatever custom subclasses of
plugins/models/backends/components your prefer.

Other Features - startUp hook
Sites that are configured (i.e. serving), are sent #onStartUp.

Other Features - Standard Caches 
Places to cache data are provided as standard, per-session and
per-application caches.

self site sessionCacheAt: key ifAbsentPut: aBlock

Other Features - Per-Session properties
self session properties at: key ifAbsent: [ ]

Other Features - Helpers 
1. keepAliveHelper - while the user has the browser open, his session
stays alive.
2. ShoreComponentsHelper - use shore components without needing a
specialized WASession class.
3. ToolbarHelper - enable/disable toolbar on the fly
4. CometHelper - use comet without needing a specialized WASession class.

(also available - MagmaHelper for using Magma without needing a
specialised WASession class)

More information about the seaside mailing list