[Web-SIG] Standardized template API
ianb at colorstudy.com
Wed Feb 1 02:20:29 CET 2006
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
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
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
More information about the Web-SIG