[Web-SIG] Standardized template API

[Ben Bangert]

On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:

> The problem for me is, I was hoping we would end up defining a  
> manager->compiler interface and a publisher->resource interface  
> rather than a publisher->manager one.  Then again, maybe we should  
> define both, and let people plug things in where they can.  It  
> would provide a path for gradually evolving to the place where  
> everything's pluggable.

Sure, as this thread started with standardizing purely the usage of  
various template languages, I'd suggest we split the thread so that  
any talk of standardizing internals regarding those relations be  
separate from the issue of just using them.

> Yeah, from the 'params' key or 'published_object' or both.

Ok, that sounds fine.

> But it seems a little ugly to me to cram another key into environ  
> to tell the manager what template to use, when you could just have  
> a 'get(template_id)' call that gets you the WSGI app to use.  It  
> also makes the objects' responsibilities a little more clearly  
> defined, since a WSGI app in the general case doesn't take a  
> template_id parameter, if you see what I mean.

Sure, though I'm thinking back to Ian's original proposed addition to  
TG's spec regarding being able to pass in a find_template callable.

> I concur.  What I propose right now is that we have a "manager"  
> interface that gets asked for a template by a name or ID, and  
> returns a WSGI app object.  Calls to that object can then include  
> 'params' and/or 'published_object'.  (Exact spelling TBD.)

We still need a setup/prepare step for the template engines involved  
because they have different requirements. Some of them need an  
initial root directory to be declared, etc. The TurboGears spec  
covered this nicely, can we use it for a starting point at least  
since it exists right now, and it works?

> I don't think this interface should suggest/recommend an addressing  
> scheme, nor a plugin scheme.  That is, I don't think it should  
> include specifiers for entry points or anything like that.   
> Instead, to do the TG/B style of plugins, you should just have a  
> manager that figures out what template engine/plugin to use.  The  
> identifier can and should be opaque.

Sure, that sounds appealing as well, what would using said interface  
look like, and how would you configure the various template engines  
it supports? (ie, if one of them needs a template root, or one of  
them needs a cache directory, etc.)

> By that I mean, you could have a manager object that looks for a  
> prefix like "kid:" at the beginning of the ID and then looks up an  
> entry point to forward to another manager.  But that would just be  
> one way of implementing the spec, not something required by the  
> spec.  The reason is that this then leaves open both the  
> possibility of developing generic and/or polymorphic "manager"  
> objects.
>
> The big open question is how to create and configure a manager  
> object, since different managers will have different needs.  For  
> example, peak.web uses module-relative paths in the default layer  
> of the default skin; it has no "root" directory.  Each layer can  
> also have its own directory, and I believe Zope 3 does the same.

I think at this point, Ian's suggestion regarding a find_template  
callable solves several of the issues you noted in how differently  
Zope looks up its layers/templates. If you create a callable that can  
do your lookup's, the existing TG spec for using templates would need  
little modification to gain the majority of the flexibility we're  
looking at.

So... if the existing TG spec can't/shouldn't be extended to support  
this, what's the alternative easy-to-use method for *using* various  
template languages to look like?

- Ben