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

[Alan Kennedy]

[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.