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

Michael Bayer mike_mp at zzzcomputing.com
Mon Feb 6 06:14:55 CET 2006


On Feb 5, 2006, at 5:33 PM, Phillip J. Eby wrote:

> As Ben has previously pointed out, systems like Myghty are going to  
> ignore
> your 'find_template()' because they do their own finding.  So the  
> spec will
> leak no matter what, until we get to the level of specification  
> called for
> by the "embedding" side of my proposal.  (The compile/write  
> stuff.)  And
> Ben and Michael have both pointed out that trying to meet a spec  
> that calls
> for them to change how their inner find_template works would be  
> costly.
>

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

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




More information about the Web-SIG mailing list