.. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% .. % Copyright 2001 by Object Craft P/L, Melbourne, Australia. .. % LICENCE - see LICENCE file distributed with this software for details. .. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% .. _pack-overview: ***************************************************** Prepackaged Application and Execution Context Classes ***************************************************** While Albatross invites you to "roll your own", in most cases you will use one of the prepackaged Application and Context classes. There are two primary choices to be made when selecting an Application class: the **page model** and the **context model**. The page model offers three choices: * **simple** The simple model is intended for use in monolithic applications. Page logic is represented by classes. * **modular** The modular model defines page logic in a collection of Python models, one per page. * **random** The random model extends the modular model, however the current page module is selected via the URI in the browser request. There are four context models: * **hidden-field** The hidden-field model stores session state in the user's browser in hidden HTML fields. * **session-server** The session-server model stores session state on the server using a separate session server process. An HTTP cookie is used to match a user session to their state on the server. * **session-file** Similar to the session-server model, the session-file model stores session state on the server. However, rather than requiring a session server daemon, this model stores the state in files on the server. This can be simpler to set up, but all server processes must run on the one machine. * **branching-server** The branching-server model stores session state on the server in the same way as the session-server model, but uses hidden HTML fields to track users, and retains multiple versions of the state. This provides more flexibility when supporting users who use the browser "back" button or who duplicate their sessions, at the cost of more server-side storage. There are 12 combinations of page and context model, although not all combinations are supported :- it is not possible to combine the `random` page model with the `hidden-field` or `branching-server` context models as these context models require a hidden form field to be sent via the client to maintain state, and this does not always happen with random access applications. Choosing the appropriate class is made easier by the ``get_app_classes(page_model, context_model)`` function. Given the names of a page model and context model, this returns a 2-tuple containing a pre-packaged Application class and a matching Context class. These can be instantiated directly, or subclassed to add further functionality: .. code-block:: python import albatross appcls, ctxcls = albatross.get_app_classes('simple', 'hidden-field') class Context(ctxcls): def __init__(self, app): ctxcls.__init__(self, app) class Application(appcls): def create_context(self): return Context(self) app = Application() .. figure:: .build/figures/AlbatrossObjects.* :align: center Albatross Classes .. _pack-simplecontext: The ``SimpleContext`` Execution Context ======================================= The ``SimpleContext`` class is provided for applications which only make use of the Albatross template functionality. If you look at the implementation of the class you will note that it is constructed from a number of mixin classes. Each of these classes implements some of the functionality required for interpreting Albatross templates. Diagrammatically the ``SimpleContext`` class looks like this: .. _fig-simplecontext: .. figure:: .build/figures/simplecontext.* :align: center The :class:`SimpleContext` class By implementing the execution context semantics in a collection of mixin classes Albatross allows you to change semantics by substituting mixins which implement the same interface. This is very useful when using the Albatross application objects. :class:`NamespaceMixin` This mixin provides a local namespace for evaluating the expressions embedded in the ``expr`` tag attributes. Application code places values into the :attr:`locals` member to make them available for display by the template files. You will probably always use this mixin in your execution context. :class:`ExecuteMixin` This mixin provides a sort of virtual machine which is required by the template file interpreter. It maintains a macro argument stack for expanding macros, and it is used to accumulate HTML produced by template execution. You will probably always use this mixin in your execution context. :class:`ResourceMixin` This mixin provides a registry of template resources which only need to be defined once. Specifically the class provides a dictionary of Python classes which implement template file tags, a dictionary of template macros, and a dictionary of template lookup tables. If you are using Albatross application functionality, you will almost certainly use this mixin in your application class, not the execution context. :class:`TemplateLoaderMixin` This mixin is a very simple template file loader. You will almost certainly use the :class:`CachingTemplateLoaderMixin` in your application object instead of this mixin when you use the Albatross application objects. :class:`StubRecorderMixin` Albatross provides special versions of the standard HTML ````, ``