[Web-SIG] A trivial template API counter-proposal

[Ian Bicking]

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  |  ianb at colorstudy.com  |  http://blog.ianbicking.org