On Feb 6, 2006, at 11:50 AM, Kevin Dangoor wrote: > I'm not keen on the wsgi_environ and set_header_callback options, > because I don't perceive a true need for *this* API to be tied to the > web. Of course, you need these if the template itself is going to set > any of the headers, but there is some added complexity that results. > TurboGears skirts this by having the Python code outside of the > template decide what content-type (and other headers) are appropriate.
Of course, quite a few people have all mentioned conflicting 'needs' they perceived. This option keeps flexibility so that whatever your perception, if you *need* the template language to work like a WSGI app, you *could* do that with an API including these options. > Since these are optional, I'm not strongly against them, but they just > feel like they add a bit of complexity to an API that is dealing with > a simple problem. Many people won't ever see them, its only those of us using template languages where it can handle a full WSGI environment that will want this. Having that option enables wrapping the render function in a way that will be identical to a WSGI call. I think it's a good compromise that still lets template languages have the freedom to provide their own request/response API independent of the framework, in addition to accommodating existing template languages. I don't see a problem with Ian's spec, as it keeps the up-front simple appearance, while leaving the door open to a WSGI wrapper for those of us that want it. Cheers, Ben _______________________________________________ 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
