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

[Ben Bangert]

> # Or use Kid:
> kidengine = KidTemplate(**kid_args)
> content, headers = kidengine('some.template.kid', wsgi=False)
>
> # web
> return kidengine(environ, start_response)
>
> Or if people don't like relying on the object to determine if there's
> a keyword with wsgi = False,
>
> content, headers = kidengine.render('some.template.kid', wsgi=False)
> return kidengine.wsgi(environ, start_response)

Actually, to clarify, it'd be:
content, headers = kidengine.render('some.template', vars, **extra_args)

content, headers = kidengine.render(template_string, vars,  
is_string=True)

environ['wti.source'] = 'some.template'
environ['wti.vars'] = vars
environ['wti.extra'] = dict(is_string=True)
return kidengine.wsgi(environ, start_response)

Here's my thinking on this:

First, I don't believe it's terribly realistic to try and unify how  
the template resource appears. Different template languages use  
different approaches, Myghty uses a normal path string (relative to a  
template root dir), Kid uses a module path, etc. You will *always*  
need to know a certain amount about the template language you're  
using, whether it needs to have a template root configured, do you  
give it a resource name as a module path, or filesystem path, etc.  
Trying to bash them all together will only cripple many or leave them  
working in bizarre ways.

Second, different template languages can take additional options, we  
need to retain the ability to pass these in, thus **extra_args. Kid  
can take the fragment option, Myghty can toggle inheritance, etc.

Third, afaik, every template language lets you give it variables,  
these will be in the vars dict, how the template language gets them  
to the template is up to the template language.

So, in this proposal, it is assumed that underneath, there is a WSGI  
interface that can be called. Whether the render function wants to  
emulate a WSGI call to the underlying WSGI ability, or just render is  
up to the template spec implementor.

What you get out of this:
- Ability to call as WSGI
- Ability to send it the template data, or the name of the template
- Template engine is configured individually depending on what it  
needs for setup
- Ability to have the output returned to you as the iterable

There's lots of room for individual template languages to supply the  
necessary things they need, as if we try and restrict too much, we  
quickly end up crippling or severely limiting the usefullness.

You do get a consistent way to make a template engine object, and ask  
for output. How the template language does such things is left for  
another discussion, this is about using it. I'm sure some of the  
environ keys I proposed here could be refined as well.

- Ben