[Web-SIG] Standardized template API

[Phillip J. Eby]

At 12:29 PM 2/1/2006 -0600, Ian Bicking wrote:
>Clark C. Evans wrote:
>>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.
>
>My criteria is that it would be easy to implement Phillip's proposal in 
>terms of mine (and I could provide a sample implementation of that if it 
>would help), but it doesn't seem so easy to do the opposite.

Actually, I believe you've got that backwards.  Many things the WSGI 
embedding proposal can do, yours can't do *at all*, no matter how much 
programming you do.  vars'n'strings isn't a substitute for WSGI, but it's 
easy to piggyback other payloads *out* of WSGI using file_wrapper-like APIs 
or dual-use objects with "__call__" methods.


>   Maybe not possible, because templates often need to get to raw (not 
> plugin or WSGI wrapped) version of subtemplates (using communication APIs 
> that are not standard and are not part of any of these specs).

For one thing, you can use extension APIs, like wsgi.file_wrapper.  For 
another, note that requiring a compiled template to be a WSGI app doesn't 
require a calling or extending template to restrict itself to interacting 
via WSGI.  If you have some kind of "find_template" extension API that's 
called, the template is free to sniff the returned resource for something 
"better" than WSGI for its purposes, like a Cheetah base template or a 
peak.web IDOMlet, or a PSO tag, or any of a dozen other specialized 
templating technologies.  They just have to *also* be WSGI apps if there's 
any chance they might be used to respond to a page request.

(Example: peak.web IDOMlets have separate methods to behave as a WSGI-like 
response handler and as a fragment generator for insertion into another 
DOMlet's page, which also allows them to be smart about including 
surrounding content; thus they can dynamically "inherit" (to use the common 
slang for applying a layout) depending on whether they are being used as a 
fragment or a full page, and optionally applying content negotiation as 
well.  This is another example of a kind of feature where the 
vars'n'strings proposal seems to fall short of enabling.)


>For instance, there's no way for a Cheetah template to extend a WSGI 
>application.  It can extend other Cheetah templates, and even other Python 
>classes, but not a WSGI app.

Provide extension APIs to allow finding other templates.  Putting them in 
this context also helps make it clear that such APIs aren't -- and *can't* 
be -- universal, because the templates themselves aren't 
heterogeneous.  You can't give a Cheetah template a Kid subtemplate.

I'd prefer to take up template finding in the context of a resource 
deployment proposal, where I think we can get a lot more leverage.  But if 
it enables needed use cases today, I could get behind providing a simple -- 
and *optional* -- template finding API as part of the WSGI 
template/resource proposal, especially if discussing it helps lay the 
groundwork for the resource deployment proposal.


>It's up to you to handle that in your application.  So you might pass in 
>the WSGI environment as some variable, or the specific header, or you 
>might select a template based on that header.

You're presuming a controller-based architecture here, not an 
object-publishing one or a PHP/ASP style "active pages" one.  That's 
ignoring what, maybe half the web frameworks?