Most of Albatross exists as a collection of plug compatible mixin classes which you select from to define the way your application should behave and how it will be deployed. Figure 7.1 shows the organisation of the component types in the toolkit.
![]() |
The divisions in the diagram represent conceptually different functional areas within the toolkit.
This layer provides the Albatross templating functionality. Template classes make use of the methods defined in the next layer down to access application functionality and data.
Classes in this layer are defined in the albatross.template and albatross.tags modules.
An execution context suitable for interpreting template files is constructed by combining one mixin of each type from this layer.
Execution contexts which subclass a PageMixin class in addition to the mixins from the above layer are suitable for use in Albatross applications. The PageMixin class controls how the application locates code and template files for each page served by the application. The PickleSignMixin class is responsible for modifying pickles which are sent to the browser to prevent or detect modification.
In this layer you will typically create your own application and execution context classes by subclassing a prepared application class.
For the most part Albatross applications are independent of the method by which they are deployed. Depending upon which Request class you choose from this layer you can either deploy your application via CGI, mod_python (http://www.modpython.org/), FastCGI (http://www.fastcgi.com/) or as a stand-alone python HTTP server.
Wherever possible the Albatross mixin classes use member names which begin with double underscore to trigger Python name mangling. This protects your classes from having member name clashes with private members of the mixin classes. Any member names which are not mangled are intended to be accessed in your application code.