>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.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
