Kevin Dangoor wrote:
On 1/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
There's a couple things that seem weird to me in the template API.
* What's up with the use of module names? Since they aren't really
Python files anyway, and you also need __init__.py files.
That's not necessarily true. They *can* be Python files. Cheetah and
Kid both support compilation to .pyc files. Basically, this provides
an unambiguous way to describe where a template is. You're right that
doing it like that requires __init__.py, though.
* There should really really be a search path for templates. That
doesn't fit well with the modules either.
Why should there be a search path? To save on typing? (Which is not an
unreasonable reason, actually...)
No, the typing isn't a problem at all -- I'm reading locations from
frame introspection, so it's not really an issue. Instead I am
concerned about application reusability. If you have a search path then
you can override individual templates by copying and editing templates.
So generally the search path would be extended at runtime in some
site-specific way. At work we add
/iscape/web/sitename/templates/appname to the search path for each
install of an app.
What API would you like to see?
I think it could be added to the instantiation of the plugin. So
def __init__(self, extra_vars_func=None, options=None, search_path=None):
I actually think search_path should be required, and default to
something like "egg:ThisPackage", where "egg:" means use the
pkg_resources.resource_filename('ThisPackage', rest_of_path). A plain
path (or file:) would mean that you use filesystem operations.
Directories should not be overridden all at once. So if you have
/myapp/master.kid and /myapp/edit.kid, you should be able to create
/myapp/master.kid and have the application-default edit.kid use it.
* I'm confused what the purpose of .load_template() is. Or what it
should return.
No return value is required. The purpose is to compile and load a
template which *is* a Python module for importing later (without the
use of import hooks).
OK. But since there's no spec on what you import, or what it might
return, if you use that method to any effect you can't change template
plugins, right?
Another item: I feel like distribution and package are getting confused.
This line:
tfile = pkg_resources.resource_filename(package,
"%s.%s" %
(basename,
self.extension))
The "package" here is actually a distribution name, and isn't related to
Python packages. This further muddles the use of module-like names for
templates, as you can't dot a distribution name with anything.
From
http://peak.telecommunity.com/DevCenter/PkgResources#resource-extraction
resource_filename(package_or_requirement, resource_name)
I'm having a hard time figuring out where pkg_resources actually
implements this, but I think this is actually from an earlier time when
"package" was being used like "distribution". But it actually describes
a distribution, e.g., 'TurboGears', not 'turbogears'.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
