On Mon, Aug 27, 2001 at 08:54:21AM -0500, Ian Bicking wrote:
> > We've promised that #define/data is the place for Python code and only
> > Python code. I'd like to keep it that way.
> We did? Then it's not that useful. We already have Python code,
> that's what the .py files are for. Sure, an escape is alright... but
> I was hoping #define would use Cheetah syntax. Otherwise it still
> doesn't seem useful to me. I *really* don't like "Python for the
> complicated stuff." What is complicated changes over time, and I
> don't want to change languages. And avoiding Python for most cases is
> the point of Cheetah, no?
Cheetah is meant to be a supplement to Python, to do a few things Python
doesn't do well on its own. Avoiding Python is not a goal.
We need a "Python escape" to handle things which are easier done in
Python rather than Cheetah. The intention was to use this for all
variable assignments (#set appeared later), functions, and whatever else
we might not have thought of yet.
Yes, #data is "unnecessary" because one can move all the Python code to
your classes. It's merely an alternative for when you want to keep the
variable definitions inside the template, for whatever reason. It might
make sense in cases where the template definitions are in separate files
from the classes (as was recently proposed) and different people
maintain the template files but still need to update the data. Or when
you just want to keep the values with the template so they don't get
lost. Or if your name is Tavis Rudd, you like to keep *all* your data
in #data blocks. :)
* * * *
Now, as to a Cheetah-syntax function definition. We could do
#function f(a, b):
and I assume (although I'm not the expert in this) it would be easy
enough for the compiler to convert this to a Python function and pretend
it was defined in the #data block.
But how far would you go in terms of which directives are allowed in the
function? Perhaps #if and #for can be converted to their Python
equivalents, and maybe some other directives too. But I'm sure there
will be a few directives that either don't make sense inside a #function
or are hard to implement. #function, #data, #macro and #block come to
I am assuming the rules are:
1) Functions are converted to their Python equivalent at compile time,
and behave as if they were written in Python inside a #data block.
2) Function output will not be parsed. (Same as regular functions.)
3) Thus, there's no support for recursive evaluation. (A function
returning a placeholder which is evaluated, which returns a placeholder
which is evaluated.) This create an infinite loop unless we said the
recursion stops when one iteration returns the same thing the previous
iteration returned (or when the output doesn't contain any
metacharacters, but then we'd have to unescape escaped sequences...) In
any case, you'd have to somehow mark recursive and non-recursive
functions, otherwise all functions would have to be recursive, and that
would be a severe performance drain because we'd have to execute every
function call at least twice.
> > It looks like we should stick with the first request. We've run into
> > lots of problems doing things at compile time, so the less we do during
> > it, the better. Plus, as I've said before, many people will want to
> > create the template object first and then set the variables....
> > Although wait a minute, do we have lazy compilation yet? That would
> > erase the gap between the two steps.
> If compile-cheetah is going to work (and actually compile to a real
> servlet), then that won't be possible. Which might be unfortunate.
Hmm? compile-cheetah does a different kind of compilation. It takes
a raw template definition and spins a wrapper around it so that the
page can be used as a servlet (providing a template class while it's
at it). Actually, it's not a "compilation" at all, so maybe that's a
misleading term. cheetah-compile doesn't do anything about compiling
Template Objects. If you're talking about moving the TO-compilation
step into cheetah-compile, I'm quite opposed to that, because I
customize my .py files extensively after cheetah-compile'ing them.
Actually, I build a site by cheetah-compiling one page, then copying
the .py file for each new page.
Just to make sure we're on the same page re lazy compilation, it means
delaying the compilation until the first time the template object is
-Mike (Iron) Orr, iron@... (if mail problems: mso@...)
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol