[Seaside] Seaside Coding Pattern

Louis LaBrunda Lou at Keystone-Software.com
Fri Feb 20 15:05:54 UTC 2015


Hi Craig,

>Hi All,
>
>A pretty-much universal pattern of coding of Web Apps in non-image based
>languages (C#, PHP, Java) is:
>	* The incoming web request starts a process 
>	* some objects are instantiated, usually from a SQL datastore,
>	* some interactions occur with these objects
>	* optionally, some database modifications are made
>	* a response is sent to the web browser
>	* all the temporary variables that point to the objects go
>out-of-scope
>	* all the objects are garbage collected
>
>I caught myself coding a Seaside app using the same pattern and wondered if
>it's sub-optimal in an image based language.
>
>So, is this an acceptable way to code a Seaside app?  Should I rather be
>using long-lived image based objects? Stored in a collection hung off a
>class variable. 
>
>Comments would be appreciated.
>
>Craig

My Seaside experience has gotten a little stale, so I will give you a quick
answer and I'm sure someone with more recent experience will have more to
say about it.

Seaside is designed to be state full.  Sessions persist for the duration of
a connection (more or less).  Look for a class with a name like Session, if
you sub class it you can add your own instance variables that will be
available for the session.  Also look into connecting setter/getter methods
of your objects to fields in the browser.  The fields will be populated
with the values (if any) from the objects on the way out and set with the
new values on the way back from the web browser.  This is way easier than
having to look up the field names/values in a dictionary on the way back
like I think you have to do in Ruby/Rails (I'm not sure but I think this is
how Rails works).

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com



More information about the seaside mailing list