[Guido van Rossum] > 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? 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!)? > > 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, 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?
At last! A voice of sanity! 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. Templating is about taking a pattern of bytes (the template), somehow mixing it with user data (the user context), and generating a series of bytes (the output). Full stop. In relation to text, this means taking a textual template, with embedded code/processing-instructions/whatever, "cooking" it in a user namespace, delivering a final piece of output. With text, the only major concern is with character encoding. And if I were designing a templating API, I'd make everything unicode-only, leaving the user responsible for transcoding to their desired encoding at serialisation time. 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. 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. Perhaps web-sig is the wrong place to discuss a textual templating API. Maybe xml-sig would be a better place, or a new text-sig should be formed? In relation to Guido's point above about usage scenarios for this API: I'm quite interested because I have a jython implementation of ZPT/TAL that I'll be open-sourcing in the coming weeks, and which I intend to make compatible with whatever API is produced by this current discussion. 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? Just my €0,02. Alan. _______________________________________________ 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
