Creating Dynamic Web Pages (ZOPE)

[Dave Cole]

>>>>> "Tim" == Tim Churches <tchur at optushome.com.au> writes:

Tim> Michael Hall wrote:
>>  I notice no-one has suggested good ol' CGI. For a relatively
>> simple job such as this, a few basic Python CGI scripts, some
>> templates and MySQLdb could also be used ... oh, just noticed the
>> MS-SQL database. There is probably a module around to cope with
>> MS-SQL, no?

Tim> Object Craft have a Python wrapper for MS SQL Server. See
Tim> http://www.object-craft.com.au

Depending upon how you are going to access MS SQL Server, the Sybase
module might be a better choice.

If you are compiling against the MS SQL Server libraries, then the
MSSQL server module should be OK.  If you are using FreeTDS then the
Sybase module is probably better (although still not perfect).  If
using Sybase client libraries then either the MSSQL or Sybase modules
can probably be used.

Confused yet?

Tim> And while you are there, have a look at their Albatross CGI-based
Tim> stateful Web application framework, which could be just what is
Tim> required for the rest of the Web site envisaged.  In my
Tim> experience, nearly all Web applications and database-driven Web
Tim> sites end up needing to retain state information sooner or
Tim> later. Might as well start with a framework which can go the
Tim> distance. Albatross is especially nice in this respect because
Tim> you can choose alternative application models, starting with
Tim> "SimpleApp" which is just what the name suggests, and later
Tim> progress to more complex application models through mixins
Tim> without having to start from scratch or throw away your existing
Tim> code.

Thanks for the plug Tim.

One of the goals I had when developing Albatross was to try to keep
the toolkit subservient to your code, not the other way around.
Whether I met that goal or not is a matter of opinion :-).  If you
want to craft an application from a collection of code fragments which
run within an application server then Zope or Webware might be better
for you.

This page:

   http://www.object-craft.com.au/projects/albatross/albatross/tug-simple2.html

shows a very simple CGI application which just uses the templating
parts of Albatross.  If you do not want to use the application
functionality, you don't have to.

The application functionality is there to take most of the drudgery
out of organising your application code, maintaining sessions, and
working out just which page / request has been requested by the
browser.

When building a collection of small web applications (especially for
the intranet) you find yourself doing the same infrastructure and glue
things over and over.  Albatross is designed to let you spend your
effort on the interesting parts of the applications.

Tim is correct about the ability to change application types with
minimal change to your application code.  The toolkit calls your
request processing logic via the same interface regardless of how you
have decided to structure and deploy your application.  This means you
can develop using CGI then deploy using mod_python.  You can even
switch between server and client side sessions without changing much
more than the mainline.

Another important goal in Albatross is to keep the toolkit line count
very small so that people can easily look inside and see how it works.
Code is organised as a collection of mixin classes so that you can
easily substitute your own functionality where the Albatross code does
not suit you.

- Dave

-- 
http://www.object-craft.com.au