> # 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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
