[Web-SIG] Standardized template API

[Ian Bicking]

Phillip J. Eby wrote:
> At 07:20 PM 1/31/2006 -0600, Ian Bicking wrote:
> 
>> Phillip J. Eby wrote:
>>
>>>> I believe that custom find_template implementations could handle 
>>>> these cases.  Maybe there also needs to be a 
>>>> relative_to_template_name argument to find_template, so that it can 
>>>> resolve template names relative to the calling template (so, for 
>>>> instance, you can use relative names to the template you inherit from).
>>>
>>>
>>> I don't want plugins to affect *where* templates are retrieved from, 
>>> or how their names are interpreted.  A template engine's only job 
>>> should be to turn a string or stream into a template object.
>>>
>>> What I was proposing we do was establish a common mechanism for 
>>> finding templates and other resources, taking into account i18n, 
>>> skinning, polymorphism, and eggs.  That would have a much greater 
>>> impact on the Python web world than simply formalizing the 
>>> Buffet/TurboGears plugin mechanism.
>>
>>
>> find_template is provided *to* the plugin, *from* the framework, so I 
>> believe it fits what you describe.  Well, the implementation of that 
>> finding algorithm is not in the spec, but making a good implementation 
>> can be tackled separately; it will be more interesting when we also 
>> have a specific resource to find (templates).
> 
> 
> What I'm getting at is that a standardized way for a deployer to provide 
> templates to "skin" or localize an application has vastly wider 
> applicability than the template plugin mechanism being discussed, and is 
> much more relevant to standardization.

I don't see why that needs to be related to this spec, except to allow 
for it.  find_template/find_resource allows for arbitrarily complex 
rules to identify resources (at least seem so to me), but does not 
provide or specify any standard way to do this.

>>> 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.
>>
>>
>> I feel comfortable with ultimately doing a render(template, vars) 
>> call, which is widely supported in quite a few templating languages.  
>> Turning it into a WSGI app seems like a bigger stretch, and one that 
>> I'm not sure is necessary, and one I'm pretty sure will scare some 
>> people off ;)
> 
> 
> But the upsides are:
> 
> 1. Less to specify
> 2. More flexibility
> 3. Fewer protocols for a framework developer to learn
> 4. Complete access to the request
> 5. Complete control over the response

The spec we have has few or no bindings to HTTP, and is usable (and 
useful) outside of HTTP.  You could build a single WSGI implementation 
on top of this spec, and use the spec to make that WSGI implementation 
support any template language that uses this spec.

>> Separately from this, I have my own ideas as well about a WSGI 
>> middleware for skinning, but that's something else entirely.  What we 
>> have here is very much within the reach of immediately implementing 
>> and using in several frameworks.
> 
> 
> And like Jim, I have little interest in it, as it doesn't solve any of 
> the interesting problems.
> 
> Unlike Jim, I'm also actively *against* having such a spec because it 
> creates the illusion that a useful problem has been solved.  I don't 
> have anything against the Turbo/Buffet API, mind you, I just don't want 
> it anywhere near a PEP.  It's a niche solution to a niche problem, which 
> is allowing web frameworks to offer an illusion of choice to developers.

I don't buy that.  I think if frameworks expose not just the result of 
render, but also the result of load_template, then this can to some 
degree support all templating languages.  I think 
find_template/find_resource can support a wide variety of techniques for 
finding resources, and if a compelling spec or implementation of that 
function comes about, then that's great, but that doesn't invalidate the 
spec, nor is it required to use the spec.

> However, the existence of a "blessed" spec along those lines would send 
> a message that this is a solved problem, just use that spec and 
> everything is fine, when a whole area of solutions is completely closed 
> off.  I can just see people complaining about Zope not supporting the 
> spec, no matter that the spec doesn't come anywhere close to addressing 
> the problems Zope is solving.

OK, then you'll have to go into more depth why the API provided is 
wrong.  Not why it isn't enough -- it's not the end-all and be-all of 
templating or anything -- but why what it *does* provide is not 
sufficient or correct.

> The problem I'd like to see a template/resource spec solve is this: give 
> developers and deployers a way to package templates and other static or 
> dynamic resources for an application.  All frameworks can benefit from 
> this, especially if there need only be a single implementation of the 
> API.  Solving this problem *also* solves the problems solved by the 
> Turbo/Buffet plugin API as a side effect, because you have to be able to 
> specify somehow what code gets used to turn a resource specification 
> into something executable.

That's a separate issue.  If you -- or someone else at some future time 
-- can provide an implementation of find_template/find_resource that 
does these things, then I think you'll have what you want.

>>> I don't know if it's politically or technically feasible to actually 
>>> solve this, since some template engines bundle a lot of assumptions 
>>> presently, like the idea that a template is a Python module or stuff 
>>> like that.  Some frameworks currently bundle assumptions of their own 
>>> about such things.  Getting to a workable standard might require some 
>>> compromises.
>>
>>
>> While a standard is useful, you won't be able to drop templates in 
>> willy-nilly into applications and have them work.
> 
> 
> That's not really the goal of what I'm proposing, and it's also why I 
> think focusing on the interface between the framework and templating 
> tool is way too narrow a niche.

I, and several other people who have already started usefully using this 
spec as is, don't feel that way.  We feel it's useful enough right now, 
even with notable problems around its current (as described on the TG 
page) module-oriented perspective.

Please, say what is wrong about the spec itself, not what is wrong about 
the scope of the spec.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org