[Seaside] [Ann] Beach-Seaside

[Keith Hodges]

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

http://code.google.com/p/beaches/

So Beach or Beaches? What do you prefer?

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

cheers

Keith

==================================================

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

http://code.google.com/p/beaches/
=====
Beach-Seaside
=====

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.

BEBondi-#prefSmtpHost

    ^ 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.
e.g.

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)