[Web-SIG] Standardized template API

[Phillip J. Eby]

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


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

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 
compiler techniques.)


>| >3. Doesn't allow the framework to control the lifetime of compiled
>| >resources
>|
>| 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.