On 1/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> Kevin Dangoor wrote:
> > On 1/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> >>* 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.
Ahh. Yes, I see what you mean.
>
> > 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.
When you say "default to something like 'egg:ThisPackage'" is the
'egg:ThisPackage' default provided by the tool that is using the
template plugin? I'm not certain how the plugin would figure out what
"ThisPackage" is.
> 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.
Yes, that makes sense. To some extent, TurboGears provides a hook via
the "sitetemplate", but overrides of templates via a path would be
good. If memory serves, current versions of Kid do offer a search
path.
> >>* 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?
TurboGears can be told to load some "base templates" for import
purposes. (A feature that I could probably get rid of it this juncture
anyway. I doubt anyone's using it.) If there's anything in the list of
base templates to load, it calls that method of the template engine.
It doesn't pay attention to return values. All it does is allow the
user to then, in Kid for example, do
<?python import mytemplatemodule ?>
<html py:extends="mytemplatemodule">
I'll send a separate message to see if anyone uses that basetemplate
thing and maybe just ditch that altogether. At that point, that
load_template method isn't getting called from TurboGears, at least.
> > 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'.
No, it really is "package or requirement". It must be implemented
somewhere, because it works:
In [2]:import pkg_resources
In [3]:pkg_resources.resource_filename("turbogears.widgets",
"static/calendar.js")
Out[3]:'turbogears/widgets/static/calendar.js'
Kevin
