[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
"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)
More information about the seaside
mailing list