[Seaside] [Ann] Beach-Seaside
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
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: [
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"
Anywhere in seaside, your per-session instance of BEBondi is available via:
Anywhere outside of a seaside session (i.e. in a workspace) a
per-session instance of BEBondi (with a seaside psuedo session) is
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:
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
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
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