Michael Bayer wrote:
> Im not totally following every detail of this discussion....but correct
> me if I'm wrong, if we are just talking about a specification of how
> the various components of a template engine are to look and interact
> with each other, there is no reason Myghty's resolver couldnt implement
> a find_template() method...since thats what it is !
Yes, this is always how I've seen it.
> I would say that
> the argument or arguments passed to find_template() need to be pretty
> open ended, since you cant predict what kinds of things might be
> meaningful to a template finder, such as in myghty's case, the resolver
> wants to know if you are asking for this template to be used in a
> request, or an "embedded" template call, since there may be rules set
> up to return different components based on that context.
Do these need to be arguments, or can the context be instance variables
of a find_template callable? That is, you might do:
def myghty_entry_point(environ, start_response):
find_template = MyghtyTemplateFinder(environ)
...
At least in my spec, find_template is not meant to be a global value.
(However, I believe this complicates caching substantially, unless we
leave it up to the find_template callable to handle that).
Another option for more complicated situations would be looking for
methods on find_template, and using those, or falling back to the
calling interface.
One substantial one that I think comes up in Myghty is that you get a
template, and then you get all its implicit parents (I'm not sure what
the term is in Myghty). I don't even know what to call that, and
certainly not how to deal with it in find_template.
One possible workaround for that would be for the plugin's load_template
to return an object that encompasses all the implicit parents. But that
takes some functionality from find_template that seems like it should be
in find_template. Unless there was some really simple rule, like:
load_template(find_template('/foo/bar/baz.myt'))...
tries to call:
load_template(find_template('/foo/template.myt'))
also tries to call:
load_template(find_template('/template.myt'))
My spec allows for this, I believe. But it depends on the template
plugin invoking these rules.
> The only thing about myghty's "find_template()" that is special and
> possibly complicating to this whole idea, is that its used not just at
> the request, but within the execution of the template itself to find
> other templates to include within or inherit from. Thats the gist of
> where myghty is coming from....you have this system of finding,
> compiling, caching the compiled version of, executing, and (optionally)
> caching the generated output of templates...but its totally recursive.
> one template call can result in a hundred more before the request is
> complete, and each step in that chain of template operations can occur
> at the componentized level as well as the overall request....there is
> also a request context active the whole time which maintains a stack of
> frame objects, etc. So if we come up with this standardized system
> to denote all those steps, for Myghty they might be built all the way
> through internally....perhaps at the internal level they will
> communicate more natively to reduce overhead, but in general we will be
> looking to organize its pieces in a way that corresponds closely to
> this "generalized template scheme".
This kind of recursive call is definitely considered in my spec.
find_template (I call it find_resource, but we can ignore the "resource"
stuff too) gets relative_to_name and relative_to_object optional
arguments. You can use these for whatever resolution logic you want.
templates/resources get their name, a stream representing their content
(e.g., an opened file), and a reference to find_resource/find_template.
They should (maybe optionally) use find_resource to find any templates
they refer to.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
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
