[Web-SIG] Standardized template API

[Ian Bicking]

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org