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

[Phillip J. Eby]

At 01:28 PM 2/5/2006 +0000, Alan Kennedy wrote:
>I've been dismayed over the last few days trying to follow the direction
>of this thread: it appears to me that something very simple has now
>become very complex.

On the contrary, the situation is and always has been very complex.  It 
only appears simple if you restrict your view to a particular narrow set of 
use cases and ignore everyone else's.  Python web frameworks are extremely 
diverse in audience, needs, philosophies, and implementation.  A "standard" 
that doesn't take this into consideration is divisive, when what we need to 
be doing is unifying.  Having a standard that takes diversity into 
consideration may be slightly more complex, but it allows *consolidation* 
to occur over time.

The *real* additional complexity here is communication.  Since each 
framework has its own conceptual model of how things work, we've been 
spending a lot of time just learning to understand each other.  While time 
consuming, it is absolutely a worthwhile effort if your goal is to get 
everybody closer together.  If we only discuss what we already have in 
common, we are simply dividing the world into "us" and "them", preaching to 
the choir and getting nowhere new.

That is why I've been fighting to hold off a mere rubber-stamping of a 
non-web standard that happens to work for one family of frameworks; it 
would be better for all of us if those use cases are handled as part of a 
spec that brings everybody closer together.

That's not going to be as easy, true.  It certainly hasn't been easy for 
the people discussing it so far (myself absolutely included), and it 
certainly won't be for the people reading the spec or implementing 
it.  However, not everything that is worthwhile is easy.

Developing WSGI was not easy, either, as I'm sure you recall.  You and I 
certainly argued a bit about iterators and file-like objects and such, and 
it took a while before I understood all of your use cases and we were able 
to resolve them in the spec.  If you had given up on convincing me then, or 
if I had given up on your use cases as "too complex", the spec would have 
suffered for it.  (And you wouldn't have gotten that prominent credit in 
the PEP 333 "Acknowledgments" section. ;) )


>I can understand why the web-sig has fallen into the trap of tying a
>tmeplating API to its nice web standard, WSGI: all web applications must
>generate output. But web apps need to generate a wide range of media
>types, e.g. image/*, application/msword, etc, etc, etc.

And in many frameworks, it is the *template* that decides what media type 
it is generating - and it may not even be outputting text or 
unicode.  Again, this is something that would be neglected by a text-only spec.


>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


>I used that TAL implementation to generate the documentation for various
>things, usually just a flat set of HTML files in a directory: not a HTTP
>request in sight. Theoretically, I can envision a situation where I
>might want to swap TAL implementations for that offline generation
>process, meaning that it would be helpful to have a standardised API for
>controlling template cooking.
>
>Why should I have to use WSGI in that scenario?

You don't have to.  As I mentioned many times in the discussion on 
subtemplating, nothing stops template objects from offering *additional* 
APIs besides WSGI.  It's just that if we're making a *web* standard here, 
then it should be possible for templates to do *web* things, not just play 
with strings.  Ergo, the string part of the API should be an optional 
extension, or a standard part of the API but allowed to throw exceptions if 
the template tries to do something that requires WSGI.

In contrast, I've listed numerous scenarios and use cases where providing 
WSGI or something like it is absolutely essential.  Nobody is proposing any 
alternatives that would be part of the standard, as opposed to non-standard 
conventions.

I want to make sure that *your* use cases are supported by the spec.  In 
the absolute worst case scenario, you might have to do a little wrapping to 
meet them.  But I also want to support *my* use cases, and those of other 
frameworks with similar ones.  Those cases can't be supported without a 
*web* API, which TG/Buffet does not provide.

We're all having this conversation because we want to achieve consensus so 
we can achieve something in common, and use each other's tools.  But we're 
not going to have consensus while people's use cases are being left out 
altogether.  Nor will we have the greatest interoperability of tools if we 
exclude entire classes of frameworks and templates from playing.

I believe that we can have a spec that allows for all the use cases being 
discussed.  Certainly, it will not be as simple as the TG/Buffet 
API.  However, if what you want is only the TG/Buffet API with some tweaks, 
then you are saying you do not want co-operation with at least Zope and 
Python server pages (which latter group includes at least users of Spyce, 
Webware, Snakecharmer, and mod_python, as far as I can tell).  And that 
would seem to me to be a big enough subset of Python web users/developers 
to say you don't want a Python web standard at all.

Why you'd want that, I'm not sure.  Note that making it possible for people 
to run their existing code in *your* frameworks means that they have the 
option of migrating to your framework.  But if you don't support that, they 
can't.  It seems to me that it is in framework authors' best interest, 
then, to acknowledge the reality of these existing codebases and what will 
be required to let them migrate to another system.