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

[Phillip J. Eby]

>I see. But doesn't this still tie the templates API rather strongly to
>a web API? What if I want to use a template engine to generate
>spam^H^H^H^Hpersonalized emails?

Then set the content-type to message/rfc822.  ;)


>  Or static HTML pages that are written
>to the filesystem and then served by a classic Apache setup? Or source
>code (program generators are fun toys!)?

Use the output file's write() method as the "write" callback returned by 
start_response(), or use one of the wsgiref handlers that you give 
arbitrary file-like objects to.


>ISTM that a template that does anything besides producing the
>*content* of a download would be a rather extreme exception -- e.g.
>the decision to generate a redirect feels like *application* logic,
>while templates ought to limit themselves to *presentation* logic,

Not every framework developer agrees with you on this point; some 
explicitly eschew the separation of presentation and application, although 
I personally tend to agree with you.  In the absence of BDFL pronouncement 
on which frameworks are "right" or "wrong", my policy has been to advocate 
framework neutrality - to the extent I'm able to identify and get past my 
own biases, of course.

For ASP/PHP-style frameworks, it's routine for the "template" to make these 
kinds of response-control decisions, and it's certainly seen a lot in Zope 
2 applications using DTML as well.  Even if only for backward 
compatibility, it seems wrong to me to leave all these applications unable 
to operate under the new standard.

(Also, even in frameworks where logic and presentation are kept separate, 
it doesn't necessarily mean that a template doesn't still need to control 
its content-type, or that code invoked from the template in order to access 
data may not result in data being added to the response headers.  In Zope 
3, a "view" can do such things, as might components rendered in the view.)


>and
>for that, an API that produces a string or writes to a stream seems to
>make more sense. What am I missing? Are you proposing that I should
>fake out the wsgi API and capture the strings passed to write() and
>the sequence returned?

In that case, why don't you just use the template engine directly?  But I 
don't see how such an API is a *web* templating API in that 
case.  Shouldn't such things just follow the stdlib string template 
API?  Why do we need a *web* standard for string templating?

As for capturing the output, it's pretty trivial to do if for some reason 
you have to:

      handler = BaseCGIHandler(StringIO(""),StringIO(),StringIO(),environ)
      handler.run(app)
      output = handler.stdout.getvalue().split('\r\n\r\n',1)[1]

This could probably be added as a utility function to wsgiref, or perhaps a 
simpler and more efficient form thereof.

By contrast, to allow response-manipulating templates with a non-web API, 
there would have to be some way to provide WSGI or a WSGI-like API 
thereto.  So far, nobody has proposed a way of doing that to be included in 
the templating standard.  Ian has suggested that one could stick some API 
functions in the variables passed to the template, but hasn't proposed a 
standard for doing so.  My counterproposal is that since WSGI already 
exists, it isn't necessary to create an entirely new standard for same.

Currently, the progress of the discussion I've been having with Ben Bangert 
is that we would split the templating API into two or three layers.  The 
layer I'm describing now would be part of "WSGI Linking" and the kind of 
API you're describing would be an optional extension to "WSGI 
Embedding".  Since not all template systems can reasonably be used without 
access to a request/response, it seems to me that the string-only facility 
should be considered an optional extension.

While it means that there will be at least three different parts to the 
spec, it will hopefully be clearer what different frameworks and templates 
do and don't do with regard to using each other's templates or vice versa.


> > >(PS having tried WSGI a bit now I'm fine with it.
> >
> > WSGI - it's no worse than a trip to East Berlin.  :)
>
>Well, it *is* quite a trip to memory lane... Intellectually I
>understand that the CGI feel is simply practical; but emotionally,
>using environ["PATH_INFO"] feels like a big step back compared to
>request.path.

The idea of course was to allow existing framework APIs to wrap WSGI, so 
that you can have request.path or REQUEST.path_info or whatever suits your 
fancy.  It was never intended that anybody but framework developers write 
"bare metal" WSGI code, and such developers have to touch either CGI or 
HTTP in their code anyway.