Clark C. Evans wrote: > On Tue, Jan 31, 2006 at 10:48:53AM -0600, Ian Bicking wrote: > | Kevin Dangoor wrote: > | >>>[1] http://www.turbogears.org/docs/plugins/template.html > | >> > | >>I concur. I've started using it in a project of mine. There's a couple > | >>things I'd like to add that have come up on the TG list: > | >> > | >>* Add "template_file" and "template_string" arguments to .render(), > | >>which take filenames and strings. > | > > | > Would template_file be expecting an absolute filename? (just > | > confirming that this wouldn't do any more lookups or path searching... > | > just open and go!) > | > | I'm thinking if it is an absolute filename, it should be treated as an > | exact reference. If not, then you search for the file in the search > | path. Though maybe that logic should be in find_template. For > | instance, sometimes you might want to force the template to be under > | some base directory (e.g., for security reasons), so find_template might > | treat absolute filenames as relative to that directory. > > I'd stick with the notion of a "template_name" that is neither the > template file nor the template body. Then you'd want a template factory > method that takes the name and produces the template body (complied if > necessary). This needs to be once indirect since a template may refer > to other sub-templates. This way your template could be stored > in-memory, on-disk, or in a database, or even remotely using an HTTP > cashe. The actual storage mechanism for the template source code should > not be part of this interface.
I guess there's a couple issues. I don't have a problem with template_name in the abstract, so long as it is not confused with module names (which implies all templates are modules). Also, I think template names should be unambiguously meaningful only in the context of one plugin instance. Lastly, I would rather template names not be restricted to Python module semantics, with "." as an indicator of hierarchy, and valid python symbols for the names. Then, there's some question about what a template name is. Do names include extensions? Can they optionally include extensions? Are extensions determined by the plugin, or by find_template, or a combination of the two? Oh, and I actually don't want template_names to be read as particularly hierarchical, I now realize. So a template "foo.bar" (or "foo/bar", depending on the syntax we might choose) should not in any way involve finding "foo" and then finding "bar" from that. If find_template() works that way, fine (annoying but fine), but the plugins should make no such assumption. So maybe I want template names to be opaque to the plugin, though we should agree on standard conventions. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com