[Web-SIG] Standardized template API
ben at groovie.org
Sat Feb 4 18:31:26 CET 2006
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"
> 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
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?
More information about the Web-SIG