[Web-SIG] Standardized template API

[Ian Bicking]

Kevin Dangoor wrote:
>>>Thoughts?
>>>
>>>Peter Hunt
>>>
>>>[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 think some default/recommended implementation of find_template would 
also be useful, at least to see how common features are implemented in 
terms of it.

>>* Add a find_template callback, which given a filename can, for
>>instance, use a search path to find the file.  So the framework or
>>application would pass this function into the plugin somehow.  Maybe
>>this could be extended some for use in situations where templates aren't
>>found on the filesystem.
> 
> 
> Being able to pass a string to render() would also allow use where the
> templates aren't in the filesystem.

Yes; I was thinking of implementing Subway's use of docstrings for 
templates, and realized I couldn't do it with the interface as it is.

> In fact, if find_template is just returning a filename, then this
> mechanism couldn't work for pulling the template from a database.

It could work partially.  I was figuring that if you did something like 
include another template or inherit or whatnot (every language has its 
own name for this) then that template would have to be in the 
filesystem, or more generally somewhere that find_template can find it.

Maybe it would be better if find_template actually ultimately called 
load_template, and load_template became a bit more useful.  So instead 
of render being called with the template name, it is called with 
whatever load_template returns.

This would also allow languages like PyMeld to participate partially, in 
that users could use load_template to get the templates, even if they 
could not use render.

>>* Add some methods for quoting -- one for text that is already a
>>HTML/XML literal, and one for text that should be quoted.  Some
>>templates default one way (quote everything unless explicitly asked not
>>to in some way), and some the other way (include everything as though it
>>is markup, unless explicitly quoting it).  This makes it possible --
>>though not incredibly easy -- to write some template-language-neutral
>>libraries.  I would assume most applications would actually be written
>>to a specific templating language, so this is only for libraries that go
>>out of their way to be neutral.
> 
> 
> That sounds potentially hairy. Not the specifics of having the quoting
> methods, but rather the notion of having template-language-neutral
> libraries that use these. Are you thinking of something specific? that
> might make it clearer to me.

I'm not sure at this point.  You'd actually have to tell the library 
what template language you were planning to use with it; I don't think 
any single quoting will work, because the quoting might happen deep in 
some nested structure.  But the idea is that a library like a 
widget-generation library could work better across languages.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org