[Web-SIG] Standardized template API

[Clark C. Evans]

On Tue, Jan 31, 2006 at 08:55:22PM -0500, Phillip J. Eby wrote:
| >>Indeed, I'd argue that it'd be better here to create a WSGI-based 
| >>template interface, rather than a specialized template interface.  
| >>That is, if the "compiled template" returned by a template engine is 
| >>just a WSGI application object, then it provides a maximum of 
| >>flexibility.  If individual frameworks want to supply additional data 
| >>or features, they can do so via additional environ keys.

Let's follow this idea through.  Would the ``environ`` essentially act
like the dict that most template engines already use for input?  Or
would it require something like environ['wsgi.result'] be a dict that
acts as this primary input?  How does this application get its input?

As I've been converting my application to WSGI, I've put my "templating"
stuff as a *response* filter.  It gets JSON input (as a string) from 
the output stream of the previous stage...  yea, I encode and then
decode so it isn't fast.  But it works and is very general. 

Perhaps the WSGI application specification should be modified to allow
the response to be an interation over any sort of object that can be
converted to a str?  This would allow filters to be written w/o emitting
and re-parsing content in an intermediate format.

| >I feel comfortable with ultimately doing a render(template, vars) call, 
| >which is widely supported in quite a few templating languages.  Turning 
| >it into a WSGI app seems like a bigger stretch, and one that I'm not 
| >sure is necessary, and one I'm pretty sure will scare some people off ;)
| 
| But the upsides are:
| 
| 1. Less to specify
| 2. More flexibility
| 3. Fewer protocols for a framework developer to learn
| 4. Complete access to the request
| 5. Complete control over the response

I can see reasons why you'd want this.  A templating engine could want
to use the ``HTTP_ACCEPT`` environment variable to determine what sort
content to return (or raise an error, 404 if it doesn't support any of
the content type suggested).  Similarly, I can see reasons why a
templating engine might want to set specific response headers.

...

On Tue, Jan 31, 2006 at 09:04:43PM -0600, Ian Bicking wrote:
| Phillip J. Eby wrote:
| >1. It disadvantages better solutions (whether frameworks or templates) 
| >by reducing everything to the least common denominator
| 
| I think exposing load_template is an escape for template languages that 
| don't fit into the standard dictionary-in-string-out approach.  Besides 
| that, I don't know what Better Solution we're talking about.

I don't see how something like this disadvantages better solutions. If
anything, I can see how it would enable quicker adoption of better
solutions: an adapter from this "simple" interface to the "better"
interface would be easy to construct and thus give out of the gate
any better interface a leg-up.

| >2. It doesn't give templates access to the request or response without 
| >creating new specifications for how they're to be encoded in vars -- 
| >which would end up recapitulating the pre-WSGI "common 
| >request/response" arguments all over again
| 
| The spec doesn't say anything about the variables passed in.  I guess 
| there's an implication that it is a dictionary, though that might not be 
| necessary.  The request and response are variables.  Why would they be 
| something other than variables?  Even in Zope they are variables, right?

Ian, my "templates" use the Accept header to figure out what sort of
content variant to return; plus a quick peek at the User-Agent for 
last-minute compatibility tweaks.  How does the current/proposed
templating system support this?  These things arn't exactly "inputs"
that get renderd into the output string.

| >3. Doesn't allow the framework to control the lifetime of compiled 
| >resources
| 
| Ok... so what should we do?  We can say that .load_template is not 
| allowed to cache the thing it returns, and require find_resource to do 
| the caching.

Phillip, I fail to see how this is a problem.  Doesn't Python have
garbage collecting and weak references? 

Best,

Clark