[Web-SIG] Standardized template API

[Ian Bicking]

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

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

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.

> Combine that with a resource-locating API, and we'd really be getting 
> somewhere.  The way I see it, a framework would be responsible for 
> creating locale and skin-layer search lists, and identifying a 
> resource.  The API would be responsible for locating the resource 
> implementations and returning WSGI application objects.

I proposed a resource-locating API as well in that email.  Though I'm 
thinking that IResourceType needs just a little more stuff to be 
interesting, like maybe a string identifier (which would possible match 
a setuptools entry point group, e.g., 'python.templating.engine'). 
Anyway, it doesn't seem too complicated to extend that to other 
resources, and I can certainly see the utility.

> 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.  This is abstraction 
at the framework level, where actual application writers are likely to 
write all sorts of things which depend on functionality in the template 
language they are using.  Maybe later on template language mixing will 
happen, but there's real utility here for framework authors without that.

> 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. 
  I, for one, am listening.


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