| Newsgroups |
gmane.comp.python.cheetah |
| Message-ID |
<[email protected]> |
---------- Forwarded message ----------
From: Forest <[email protected]>
Date: Sun, Jul 15, 2007 at 12:25 PM
Subject: [Cheetahtemplate-discuss] surprising #include directory
To: [email protected]
Can someone explain how to make Cheetah look in a template's directory when
searching for its #include files? It seems to be looking in the process's
current working directory instead, which has several problems:
It is non-intuitive. When #include is written in a template file, the
developer who wrote it would reasonably expect it to find files relative to
that template's directory, not some unrelated directory. (This is
especially true for traditional web developers, who use relative URLs in an
HTML page to find other pages in the same directory.)
It is unpredictable to the template developer. The directory that #include
currently searches will vary depending on the running state of a program,
which is very likely controlled by someone else, and cannot be determined
when writing the template. This means a template-only developer has no
reliable way to know how #include will behave, which makes it nearly useless
to a large part of Cheetah's target audience.
It is inconsistent with Python's import statement. Not that Cheetah's
#include and Python's import are the same thing, but since Cheetah is
primarily used in python programs, it would be rather convenient for python
programmers if they didn't have to remember special-case behavior for
commands that pull content in from separate files. At the very least, it
would make Cheetah easier to learn and remember.
It fails when a web application is deployed differently. As long as
#include behavior depends on a process's working directory, site
administrators will have limited options in how they deploy their web
applications. If their new favorite container runs in a different directory
than the original one, the site will break. That's a rather onerous
limitation for a template system to impose.
I imagine these problems could be worked around by compiling the templates
before deploying, but honestly, that extra work is not worth my time until a
site becomes popular enough to need the extra execution speed. (And for
most sites, that means never.) During development, I would no longer be
able to simply save changes in my editor window and reload in my browser
window. I would also have to find a third window and run a command line or
three, every time I made the smallest change. It only takes a few dozen
changes to make that a hassle and a waste of effort.
Rather than changing Cheetah's default behavior (for fear of breaking
backward compatibility), perhaps a more suitable #include path could be set
via Template.__init__()?
For now, I guess I'll have to avoid using #include in my templates. That's
a shame, because #include "header.tmpl" would be an elegant way to express
an operation that is very common in web development.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Cheetahtemplate-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
--
Bidegg worlds best auction site
http://bidegg.com
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Cheetahtemplate-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss