[mod_python] supporting modular mod_python extensionsvs."folding" mod_psp

Dave Cole djc at object-craft.com.au
Sat Jun 7 20:23:23 EST 2003


>>>>> "Geert" == Geert Jansen <geert at boskant.nl> writes:

>> How is the application namespace made available to the templating?

Geert> Funny that you should say namespace, because that is the 3rd
Geert> and last central concept in Draco ;-) (the others are templates
Geert> and handlers).  The variables from the "interface" namespace
Geert> are available as global variables to all code in templates.

I ask about namespaces as they are central to all of these solutions
that separate presentation from implementation.  The namespace is the
conduit.

Geert> Other namespaces include "session", "user", "cookie", "config"
Geert> and "args". All of these have a different meaning and putting
Geert> variables in them does different things. Namespaces are _the_
Geert> mechanism in Draco to use for persistency.

In Albatross there are only two namespaces; local and global.  This
makes expressions in the template language easier to handle.  Both
namespaces are managed by the execution context.  A new execution
context and local namespace is created for every browser request.
Session values are loaded into and saved from the local namespace by
the toolkit.  Session values are a subset of the values in the local
namespace.

The global namespace for template expressions is set to the globals of
the code that executed the template.  This allows you to do things
like this in a page module (code that handles an application page):

    import os

    def page_display(ctx):
        ctx.run_template('env.html')

And then in the env.html template:

    Path is <al-value expr="os.environ['PATH']">

I have been browsing through the Draco documentation.  It looks like
Draco and Albatross are trying to solve slightly different problems.  

Correct me if I am wrong, but Draco is designed to run via mod_python.
It also seems more narrowly focused than Albatross.  This can be
either a good thing or a bad thing depending upon the problem you are
trying to solve.  If the problem fits within the area that Draco
targets, then Draco will solve more application problems than
Albatross.

Albatross is designed as a set of classes that you can mix and match
to allow many different deployment options.  Currently Request classes
are provided for CGI and mod_python deployment.  It should be
relatively painless to build Request classes for other deployment
platforms (Medusa, SimpleHTTPServer, Twisted).  Just this week someone
sent us 24 lines of code (including blank lines) that allows FastCGI
deployment.

Session management is implemented via a different set of mixin
classes.  This currently allows us to store sessions in a session
server or in the local filesystem.  In the not too distant future we
will probably add a new mixin for keeping sessions in memory for
FastCGI deployed applications.  This will eliminate all of the
pickling overhead.

>> No argument here.
>> 
>> I have toyed with the idea of experimenting with different
>> templating mechanisms in Albatross.  The templating is only part of
>> the problem that Albatross is trying to address.

Geert> Yes, the same goes for Draco here. I've had some requests to
Geert> support TAL (OpenTAL) as the templating language, as this is
Geert> becoming a sort of de-facto standard. If I get to it one day I
Geert> will.

I had a serious look at TAL.  I really like the attribute and tag
level manipulation.  I am convinced that the control flow in TAL is
not a good idea.  Trouble is, I cannot think of anything better for
control flow that is consistent with TAL.

- Dave

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



More information about the Mod_python mailing list