# HG changeset patch # User David Barts # Date 1557807888 25200 # Node ID 84998cd4e1232dc37353e9a2704038818e74f92b # Parent 75e375b1976a2cf2b84a3264a3381ca5d66c5288 Add more provisional documentation. diff -r 75e375b1976a -r 84998cd4e123 code_behind.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/code_behind.html Mon May 13 21:24:48 2019 -0700 @@ -0,0 +1,60 @@ + + + + + Code-Behind Files + + + +

Code-Behind Files

+

Introduction

+

In the main webapp tree (i.e. not in WEB-INF), files ending + in a .py extension contain code-behind logic. By default, the + file names match while only the extensions differ; e.g. foo.py + will contain the code-behind logic associated with foo.pspx. + Use of the #python and/or #template header + directives will of course change this default association.

+

Pretty much anything can be in the code-behind files, with one + restriction. There must be one and only one instance of a subclass of + either Page (normal pages) or ErrorPage (error + pages).

+

BasePage Objects

+

Both Page and ErrorPage objects are subclasses of + BasePage, and share a similar structure. Creating class + instances is lightweight and doesn't do much. The main processing logic + happens in the handle method, which accepts no arguments. When + processing is complete, the export method is called to export + template variables; it should return a dictionary or dictionary-like + object.

+

Because the constructors of both Page and ErrorPage + are intended to be called by TinCan itself, they should not be overridden. + Override handle and if necessary export, and + define additional methods and instance variables to your heart's content. + Anything not callable that does not start with underscore will + automatically be available as a template variable by default.

+

Having no or multiple instances Page or ErrorPage + classes is an error and will cause the corresponding page to fail to + launch. Aside from this one restriction, you are free to import modules + and define classes as you see fit in the code-behind.

+

Note that it is not normally necessary to override the export + method; the default behavior as described in the Default Template + Variables section of the template documentation is normally + sufficient.

+

Code-Behind is Optional

+

If you define a template with no code-behind file, TinCan will use either + Page or ErrorPage as appropriate, which will + present the standard, minimal set of variables to your template.

+

Code-Behind Files Are Not Standard Modules

+

Code-behind files are compiled and loaded programmatically via low-level + Python library calls. The normal Python module subsystem and its cache is + not used. Directories in the tree served by a TinCan webapp are not + part of sys.path. Attempts by one code-behind file to import + another will fail.

+

If you have webapp-specific logic which is used in rendering multiple + pages, it belongs in WEB-INF/lib, which is automatically added + to sys.path; thus files therein are importable via the + standard mechanisms.

+ +