Kevin Dangoor wrote:
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.
You are right, there's no default the plugin can determine. TurboGears
or whatever framework should provide at least the first template path
entry (the package itself) and provide a way to configure other
directories. But that's up to the framework to do.
I've been experimenting with my own little mini-framework that uses
decorators similar to TG, and I've found it useful to import the
framework stuff into my app, then use the app code. So something like:
# in mypackage.project
project = Project('MyPackage', other options...)
# in mypackage.webpage
from project import project
@project.expose(...)
def mypage(...):
This keeps the imports down considerably, I think -- everything web
related goes through this one object, and that object takes all the
app-specific framework configuration (not the app configuration itself).
Anyway, I'm not sure how TG's decorators work, but from what I can
tell this would allow some more direct things (like setting up an
app-specific template search path, or a default template type for the app).
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.
Yes, pudge uses this quite a bit, and seems to work without any problem,
and it doesn't care about packages (you can have directories that are
invalid package names, like 'lesscode.org'). I haven't tested it with
subdirectories.
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'
Huh; beats me then ;) I couldn't really out even where that function
was defined. Some weird delegation thing going on, I think.
Anyway, back to modules -- one issue with the syntax I had was I
couldn't put a '.' in a filename, e.g., I wanted to load
"/templates/pieces.view.tmpl", because I could indicate a template
"mypackage.templates/pieces" to get templates/pieces.tmpl (without a
package), but that broke since the algorithm was splitting on the last
'.'. Using the / felt hacky to me -- and clearly it is since things
break in weird ways. And ".templates/" hurts my sensibilities terribly
;) Which is why I'd prefer paths. Maybe TG could, for a version, be
pickier than the template plugins themselves demand, and not allow
embedded '.', and then translate that to file paths (path.replace('.',
'/')) with a warning that suggests how to upgrade.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
