[Web-SIG] Standardized template API

[Phillip J. Eby]

At 02:03 PM 1/31/2006 -0500, Clark C. Evans wrote:
>I'd stick with the notion of a "template_name" that is neither the
>template file nor the template body.  Then you'd want a template factory
>method that takes the name and produces the template body (complied if
>necessary).  This needs to be once indirect since a template may refer
>to other sub-templates. This way your template could be stored
>in-memory, on-disk, or in a database, or even remotely using an HTTP
>cashe.  The actual storage mechanism for the template source code should
>not be part of this interface.

I'd go even further than this, to note that frameworks need to be able to 
cache "compiled" versions of templates.  The template "engine" should be 
able to return a "compiled" template that the framework can use to do 
rendering in future.

Note too that frameworks such as Zope 3 and peak.web have concepts like 
localization and "skinning" that require the ability to switch out the 
actual provider of a named template or "view", and in at least the case of 
peak.web this can be polymorphic.  That is, one "skin" could implement 
template "foo" using Kid and another one using ZPT.  So the name of a 
template needs to be independent of its implementation language, or the 
ability to plug in different engines is moot.  (Currently, TurboGears 
embeds the chosen template language in code, which means a deployer can't 
skin the application effectively.)

Finally, I'd note that an increasingly common use case for template storage 
is likely to be via pkg_resources lookup, so that applications can be 
deployed as eggs.  Ideally, future versions of Zope 3 and peak.web would 
perhaps allow one egg to provide skins or "layers" for views defined in 
other eggs, so that users can plug in third-party skins for applications.

Actually, if we're going to come up with something really useful here, it 
would probably be a good idea to expand the scope from just defining 
templates, to defining a "resource access" protocol to cover both static 
resource files and templates that may need to be localized or 
skinned.  That would be a much bigger win, IMO, since it would put more 
control in the hands of deployers and customizers, instead of just making 
it possible for developers to use whatever template language they fancy.  :)