[Web-SIG] Standardized template API
Phillip J. Eby
pje at telecommunity.com
Wed Feb 1 19:02:36 CET 2006
At 11:43 AM 2/1/2006 -0500, Clark C. Evans wrote:
>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 mentioned in my counter-proposal, there should probably be a key like
'wti.source' to contain either the object to be published (for
publisher-oriented frameworks) or a dictionary of variables (for
controller-oriented frameworks). I originally called it "published
object", but that's biased towards publisher frameworks so perhaps a more
neutral name like 'source' or 'data' would be more appropriate.
Ideally, I'd like for us to move forward with hammering out the details of
this and any other APIs that should be present in a WSGI Template or WSGI
>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.
Actually, my 'wti.return_string' idea in a previous post does this in a
slightly different way. Having return_foo APIs allows you to return other
types of objects that can be converted to normal WSGI or left alone,
according to whether the caller understands them. Think of it as a Python
form of HTTP_ACCEPT. :)
For an existing example of this idea, consider WSGI's file_wrapper feature,
that wraps a file as an iterable, but can bypass it and use the file
directly if no intervening middleware uses the iterable. This idea could
be extended to DOMs or other kinds of objects.
>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.
No, it wouldn't. The WSGI templating proposal effectively requires the
framework to allow resources full control of a WSGI response, whereas a
framework that just strips off the WSGI bits and only keeps a string
completely disempowers the template. That's what I mean by disadvantaging
We can and should turn that around: disadvantage the frameworks that
*don't* let the resource have control, instead of disadvantaging the
resources that want to get control.
In fact, "template" is probably the wrong word for us to be using here; the
issue is more about embedding rich dynamic resources, only some of which
happen to be simple templates. If we get that, we get templates as a side
effect. But if we only do templates, we make it harder for resource
embedding to get a foothold.
(This reminds me a bit of the complaints when the Microsoft CLR came out,
that it basically makes every language into syntax sugar for C#, while
disadvantaging more dynamic languages by making them relatively harder to
implement and/or slower. Only in this case, we're not talking about
something that can be worked around with partial interpretation and fancier
>| >3. Doesn't allow the framework to control the lifetime of compiled
>| 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?
The earlier proposal, if I understood it correctly, never exposed a
compiled template object to the framework, so GC and weak references
wouldn't have helped. Any caching would've had to be done by the engine
without any input from the framework as to how long something was needed.
Arranging the API to expose compiled resource objects would fix that, since
the framework could hold on to them as long as it liked, and normal
refcounting would take care of resource management. And if the engine
wants to cache also, it can use a weak reference.
More information about the Web-SIG