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. _______________________________________________ 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