[Web-SIG] Standardized template API
Phillip J. Eby
pje at telecommunity.com
Wed Feb 1 06:22:23 CET 2006
At 10:32 PM 1/31/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>[back to the Web-SIG]
>>At 09:39 PM 1/31/2006 -0600, Ian Bicking wrote:
>>>How do you pass in variables?
>>environ, or a nested variable therein
>OK, if you invert that (put the environ in the variables) then you get...
>variables, like in the original spec.
Well, if you're going to include the environ, you're halfway to WSGI, so
why bother making a new spec? :)
>>> How do you get non-string output?
>>What kind of non-string output? For doing what?
>Like ElementTree output, that you might pipe through other transformations.
But how's that a *template* any more, then?
>> >But there's a kind of templating that occurs in a typical application
>> >that is much more intimately tied to the calling code, and shouldn't be
>> >pushed through an HTTP-like interface.
>>But that HTTP-like interface can be concealed in a library wrapper for
>>systems that don't orient that way, and if you *don't* supply such an
>>interface, then template systems that orient that way are put at a
>>disadvantage that *can't* be worked around by library wrapping.
>I just don't get it... why do I care about the status or headers from the
Because in some frameworks, the template is the resource and it's what
controls these things.
> I don't want the template returning those things.
And other people do. Zope 2 certainly wants its templates to be able to
control such things. peak.web wants it. ASP and PHP-style templating
systems want it. I'm sure there are others.
>I probably want the template returning a unicode string. Providing a
>content-type would be fine, but hardly important.
You asked what was wrong with the spec; this is a good example. It's
conceived in the context of a very narrow set of frameworks whose paradigms
differ so little that they might as well be one framework to begin with, at
least with respect to how they treat templates.
That's not to say that there's anything wrong with them, just that there is
a lot of useful diversity in Python web frameworks and I'd prefer not to
rule out entire *classes* of web frameworks from consideration, just
because some other ideas are more familiar to some people.
We should use the wider interface in this case, because it means everybody
can play. If you make a variables-to-strings interface, only
variables-to-strings frameworks and templates can play. It's
straightforward to wrap variables-to-strings templates in a trivial WSGI
interface and to pull string output from a WSGI app (you can, after all,
just use the body and ignore the headers), but it's not possible to support
WSGI functionality inside a variables-to-strings paradigm.
Notice, by the way, that a resources-as-WSGI-apps approach also enables
approaches like WSGI servers that run templates straight from a directory,
ASP/PHP-style. This is just *one* kind of paradigm that's enabled by my
counter-proposal but isn't practical with the variables-to-string approaches.
Another paradigm that's enabled: imagine having a "template" whose text is
actually a Paste Deploy specification. Now imagine that Zope implemented
the WSGI-templating proposal using "WSGI Methods" that allowed you to
select whatever "template engine" you wanted, and allowed editing the text
through the web. Now, you could deploy a Paste-based application inside a
folder in a Zope site!
So, those are just two ideas I pulled out of my hat for what a
WSGI-templating spec could permit, that variables-and-strings can't match.
It's not so much that the vars-and-strings proposal is *wrong* per se, it's
just that compared to my counterproposal, it just ain't right. A "good is
the enemy of the best" scenario is what I'm worried about here, which is
why even though the TG/B interface is a *good* thing in and of itself, I
don't want it to get promoted outside its area of expertise. The Web-SIG
should put forth a WSGI-based templating API, because it's better for the
Python web platform as a whole.
The only cost that I see is disadvantaging frameworks that don't make good
use of WSGI, and that was always going to be a natural consequence of
having a standard in the first place. (i.e., some will always make better
use of it than others, and the better ones will have a better time of it.)
More information about the Web-SIG