[Web-SIG] Standardized template API
ianb at colorstudy.com
Wed Feb 1 19:29:35 CET 2006
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
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
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
More information about the Web-SIG