[Web-SIG] A trivial template API counter-proposal

[Ian Bicking]

Phillip J. Eby wrote:
>>This topic started with Buffet, the de-facto standard templating API for
>>CherryPy. Buffet is just about textual templating, which is a good
>>thing. That's why it's very simple, and is thus actually being used.
> 
> 
> Which is precisely why we don't need to rush into blessing it as some kind 
> of web standard, when it doesn't have anything to do with the "web", as far 
> as I can tell.  If I needed a plugin for pure text or XML templating (as 
> opposed to *web application* templates), or I were creating a pure text or 
> XML output generator, I would absolutely use the TG/Buffet API, no 
> question.  It is 100% the right tool for the job, and the de facto standard 
> as well.
> 
> But I'm also 100% positive that it is *not* suitable to be declared a 
> Python *web* standard by itself: it's not about the web at all.  The web 
> just happens to be where it's being used at the moment, and only in 
> frameworks where the use cases slot neatly together with it.  Heck, just 
> look at the API documentation and see if you can find the word "web" or 
> even "request" mentioned on the page:
> 
>    http://www.turbogears.org/docs/plugins/template.html

It is not a complete spec that fits many use cases at this time.  It 
won't be sufficient for TG either before long -- Kevin has already said 
that he'd like a find_template function somewhere in there.

Because the spec suggests that templates are given module-like names 
coinciding with the package of the consuming software, it is hard to use 
in any way where the templates themselves are taken from arbitrary 
locations.  It doesn't actually specify how the names are interpreted or 
how the templates are found, but all the implementations so far use 
pkg_resources and load templates in a way that makes it difficult to 
load arbitrary files.

This probably seemed sensible since the first couple languages -- Kid 
and Cheetah -- compile to Python modules.  But while it seems sensible, 
Python modules are far more difficult to work with than simpler 
metaphors for a compiled template -- you get import hooks, rather 
complicated recompilation steps, and add one more thing to the already 
complex task of managing sys.path.

So no, this isn't sufficient now.  I think very minor fixes could 
improve it -- for instance, allow template_filename as an argument 
instead of only template_name.  Then at least simple template filling 
would be handled well (e.g., enough for Paste Script), though it is 
unlikely (with only those specs) that templates will handle including 
other templates very well, as there's not even sufficient information 
given for the template language to figure out the programmer's intent.



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