[Web-SIG] Standardized template API

[Phillip J. Eby]

At 09:31 AM 2/4/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:
>>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.

But that's the case that threw this whole thing off track to begin with, 
because you can only pass in a find_template if *you're the template 
manager*.  In the interface we're currently discussing, finding templates 
is internal to the engine, so that bit doesn't come up.

That is, if you have a Myghty "get(template_id)", then clearly it's Myghty 
that does the finding, so how would you *give* Myghty a finder?  You've 
already said that Myghty has to use its own finder, didn't you?


>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?

If you mean the __init__() signature, I'd agree, but IIUC the 
extra_vars_func isn't needed since the caller's responsible for adding 
those to the WSGI environ at call time.  Unless I'm misunderstanding its 
purpose?


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

I was assuming that the selection or implementation of such "uber-managers" 
would be hardcoded by the framework, not a point of pluggability.  These 
"uber-managers" effectively correspond to the TurboGears loader or Buffet 
loader that exist today.  That is, they're the implementation of a thing 
that finds other managers and calls them.  It's just that in this spec, 
they become "manager middleware" because they both implement the manager 
"get" interface, and they invoke it.  E.g.:

     class TGManager:
         def get_template(self, id):
             if ':' in id:
                 engine_name, id = id.split(':',1)
             else:
                 engine_name = self.default_engine
             return self.get_engine(engine_name).get_template(id)

So, the framework can expose a TGManager that offers the standard 
get_template() and follows the framework's policy for determining what 
engine to invoke; the above is just implementing what I believe is 
Turbogears' current policy for such.

So, initialization and policy of one of these animals is framework-specific 
as I understand it.  But the framework should expose the manager, and it 
can be recommended that it be included as an environ item, so that an 
application could use something like 
'environ["wsgi.template_engine"].get_template("some_id")' to obtain a 
template.  (Of course, that only matters for frameworks that are exposing 
WSGI to application code, or if you want to give a template access to the 
template engine, even though it should already have a direct line to the 
engine internally.)


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

Unfortunately, it doesn't.  Didn't you just point out that Myghty isn't 
going to actually *use* that find_template callable?  If not, then what 
good does it do to pass it in?


>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?

I think the TG API is pretty close to what we're going to end up with, 
except that rendering takes place via WSGI.  I don't see a problem with 
treating the other existing TG methods (render and transform) as optional 
extension APIs; I just don't want those to be "the standard" for how you 
plug templates into a framework, since it makes object publisher and active 
page systems into second-class citizens grubbing for scraps of text, so to 
speak.  :)