[Web-SIG] Standardized template API
ianb at colorstudy.com
Tue Jan 31 17:48:53 CET 2006
Kevin Dangoor wrote:
>>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
More information about the Web-SIG