[Web-SIG] Standardized template API

[Phillip J. Eby]

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.


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


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

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.

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.


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


>>On the positive side, relatively few frameworks support the full range of 
>>i18n, skinning, polymorphism, and egg resource options, and so fewer 
>>conflicts are likely the more you get into the high end.  For example, 
>>Zope 3 supports skins and i18n, but not really eggs and I'm not sure it 
>>does polymorphism.  peak.web currently does polymorphism, skins, and 
>>eggs, but doesn't do much w/i18n as yet.  Creating a standard would 
>>enhance the capabilities and deployability of *all* participating 
>>frameworks, however, so it seems to me to be worth a go.
>>The downside, on the other hands, is that since so few frameworks try to 
>>solve the the high-end problems, there's likely to be less widespread 
>>understanding of what the problems are or why you'd want to solve them.
>>This is the flip side of the issue Jim Fulton pointed out, which is that 
>>people who work at the high end of the problem scale don't see much 
>>benefit in the Turbo/Buffet templating API, because it bakes in way too 
>>many assumptions to allow you to solve any really interesting problems with it.
>
>Then Jim and others should give more pushback about the issues they see.

That's what I'm doing.  :)