[Web-SIG] Standardized template API

[Ian Bicking]

Clark C. Evans wrote:
> 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.

My criteria is that it would be easy to implement Phillip's proposal in 
terms of mine (and I could provide a sample implementation of that if it 
would help), but it doesn't seem so easy to do the opposite.  Maybe not 
possible, because templates often need to get to raw (not plugin or WSGI 
wrapped) version of subtemplates (using communication APIs that are not 
standard and are not part of any of these specs).

For instance, there's no way for a Cheetah template to extend a WSGI 
application.  It can extend other Cheetah templates, and even other 
Python classes, but not a WSGI app.

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

It's up to you to handle that in your application.  So you might pass in 
the WSGI environment as some variable, or the specific header, or you 
might select a template based on that header.

For instance, you might have a convention that templates are named like 
foo.text.plain.tmpl for a template that produces text/plain output. 
Then you make a find_resource implementation that is bound to the 
current request, and looks at the accept header to select the 
appropriate template from the intersection of Accept and the available 
templates.

Or, you could simply pass in the environment to the template and assume 
that the template will produce the correct template.  For instance, 
maybe you make your own template plugin that wraps other template 
plugins, and does automatic conversion from text/html to text/plain if 
necessary.

There isn't any very good way to send metadata about the result of the 
template rendering, and I can see there being some utility to allowing 
that.  For instance, indicating what mime type was actually generated, 
instead of trusting that the mime type given was used.  Or indicating 
what encoding the output is in (if you don't return unicode).  While 
these aren't strictly necessary -- you can just trust your template to 
do what you tell it to do -- it would be nice.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org