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