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. :)
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
