[Web-SIG] Standardized template API

[Phillip J. Eby]

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 
>template?

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.)