Lines 20-24 are the Cheetah-specific imports. Line 33 introduces our generated
class, x
, a subclass of Template
. It's called x because the
source file was x.tmpl.
Lines 40-46 are the .__init__
method called when the template is
instantiated or used as a Webware servlet, or when the module is run as a
standalone program. We can see it calling its superclass constructor and
setting ._filePath
and ._fileMtime
to the filename and
modification time (in Unix ticks) of the source .tmpl file.
Lines 47-84 are the main method .respond
, the one that fills the
template. Normally you call it without arguments, but Webware calls it with a
Webware Transaction
object representing the current request. Lines
57-59 set up the trans
variable. If a real or dummy transaction is
passed in, the method uses it. Otherwise (if the trans
argument is
None
), the method creates a DummyTransaction
instance.
dummyTrans
is a flag that just tells whether a dummy transaction is in
effect; it'll be used at the end of the method.
The other four .respond
arguments aren't anything you'd ever want to
pass in; they exist solely to speed up access to these frequently-used
global functions. This is a standard Python trick described in question 4.7
of the Python FAQ (http://www.python.org/cgi-bin/faqw.py).
VFS
and VFN
are the functions that give your template the
benefits of NameMapper lookup, such as the ability to use the searchList.
Line 60 initializes the write
variable. This important variable is
discussed below.
Lines 60-63 initialize a few more local variables. SL
is the
searchList. filter
is the current output filter. globalSetVars
are the variables that have been defined with #set global
.
The comments at lines 65 and 78 delimit the start and end of the code that
varies with each template. The code outside this region is identical in all
template modules. That's not quite true - #import
for instance
generates additional import
statements at the top of the module -
but it's true enough for the most part.
Lines 68-74 exist only if the template source was a named file rather than
a string or file object. The stanza recompiles the template if the source
file has changed. Lines 70-74 seem to be redundant with 75-83: both
fill the template and send the output. The reason the first set of lines
exists is because the second set may become invalid when the template is
recompiled. (This is for re compilation only. The initial compilation
happened in the .__init__
method if the template wasn't
precompiled.)
Line 75 is the most interesting line in this module. It's a direct
translation of what we put in the template definition, ``Hello, world!'' Here
the content is a single string literal. write
looks like an ordinary
function call, but remember that line 60 made it an alias to
trans.response().write
, a method in the transaction. The next few
chapters describe how the different placeholders and directives influence this
portion of the generated class.
Lines 80-83 finish the template filling. If trans
is a real Webware
transaction, write
has already sent the output to Webware for handling,
so we return ""
. If trans
is a dummy transaction,
write
has been accumulating the output in a Python StringIO
object rather than sending it anywhere, so we have to return it.
Line 83 is the end of the .respond
method.
Line 87 makes code.__str__ an alias for the main method, so that you
can print
it or apply str
to it and it will fill the template.
Line 88 gives the name of the main method, because sometimes it's not
.respond
.
Lines 94-95 allow the module to be run directly as a script. Essentially, they process the command-line arguments and them make the template fill itself.