[mod_python] publisher + cheetah

Luis M. Gonzalez wrote ..
> > Is there a reason you don't want to have to compile them first?
> 
>   Not really. I just thought I was doing something wrong, because I read
> many posts about "cheetah handlers" and I couldn't believe the way I was
> using cheetah was the correct one (or the most recommended).
>   The only benefit I can think of, is that I would avoid the extra step
> of compiling when testing code...
> 
> > There is a performance hit by not doing so.
> 
>   That's good to know. So, why the heck do people write cheetah handlers
> ?
>  
> > Anyway, just want to make sure I understand you reasons before
> > I suggest a solution.
> 
>   Well, I still wonder why people write cheetah handlers... :-)

Note that I am not an expert on Cheetah and it has been a while since I
have looked at it, so don't take the follow as gospel.

There are different ways in which Cheetah can be used, thus the way you
use it will to a degree dictate what you need to do to integrate it with
mod_python.

First off, you can store templates as text and not precompile them to
Python source code, or you can precompile them.

In the first case you need to instantiate a Cheetah Template class
instance on each access to the page unless you implement yourself some
caching mechanism which uses last loaded page and only recreates it when
it is detected that file on disk has changed. If the template has to be
recreated every time, performance will be affected.

In the case of precompiled templates where Python code resides on
disk, the actual code file is loaded as a Python module. In this case,
sys.modules is acting like a cache for you and performance will be
faster than having to create Template instance on every access. Dealing
with changes to template/code on disk is problematic with precompiled
templates stored on disk, but I'll get to that later (maybe not this email).

That is one choice that exists and I my partial understanding is that
by not using precompiled templates, you do loose some features,
or maybe how you have to do it is different. Specifically, when using
precompiled templates you have the ability to derive a template from
another template. Thus, you can have a base template which defines
a skeleton for a site layout. Individual pages can then extend this base
template and override just the body or other bits as necessary.

The next choice one has that one can make is how you put together
all the data which may be required to fill out a page when it is being
rendered. Here you can either construct a big dictionary containing
all the data precalculated before you even try to render the page, or,
you can initiate the rendering of the page and have it internally
collect the data.

In simple terms, you are either providing the data to the template, or
the template can make callouts to get the data.

Which want you want to work here can affect how you use mod_python
handlers to integrate things together. If you are going to precalculate
all the data, then it effectively means you are going to have a customised
handler or publisher function corresponding to each resource where
such data needs to be calculated. If instead the template is going to
call out to get the data, you can possibly get away with a generic
handler which passes in just the request object and the template does
any necessary imports of other modules to get access to data.

Anyway, my head isn't thinking straight right now so I am going to
leave it at that for now, leaving issues of module importing and reloading
when using precompiled templates another time. I hope from the above
you might see that depending on how you want to do things, a custom
handler may well work, but if perhaps you want to deal with page
caching issues and/or templates calling out to get data as opposed to
passing it in, a generic handler may work better as it hides the details
away and you don't have to duplicate them in each custom handler.

Sorry, brain is giving up. Time for me to go home and sleep I think. :-)

Graham