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

[Michael Bayer]

On Feb 6, 2006, at 9:16 PM, Ian Bicking wrote:

>
> The inversion of control is the tricky part.  In something like  
> Cheetah, Kid, or ZPT the template (as represented solely by the  
> file contents) gets control first, and then explicitly hands it off  
> to whatever it is "inheriting" from (they each have substantially  
> different notions of how to compose templates).  This implies  
> another call to find_template, which gives control back to the  
> framework, which is what we want.
>
> But that doesn't seem to work for Myghty.
>

Well no, I think it will work;  the template that is the one youre  
calling is always the first thing loaded, just like a non-inherited  
template environment.  it is loaded by the runtime interpreter (Ben -  
the "m" object).  the runtime interpreter then, before running the  
template, looks at the template for an "inherit" attribute (or  
defaults to the special name 'autohandler'), and then uses the  
resolver again to find the inherited template.  this process  
continues up the chain until no more parent templates are found.   
*then*, it passes control to the bottommost template which executes,  
that template then instructs the runtime interpreter to go to the  
next in the chain, and so on.

if you were monitoring the usage of the find_template() function  
during this procedure, it would not be recognizable if the initial  
template were simply including all those other templates within it,  
or if they were being used as inherited wrappers...its the runtime  
interpreter that is making them execute themselves in a different  
order.  in Myghty we just might have to slightly change the external  
view of "the runtime environment" and "the template" so that they  
look like the same thing even though they are different.   but like  
the ones you mention, the "first" template gets "control", and uses  
find_template to locate successive templates.

>>> 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:
>> I dont think find_template has to be organized differently for  
>> inheritance
>> vs. embedded components...the only thing that I would say is  
>> needed is the
>> ability for find_template to get passed that "context" of, "i need  
>> this
>> component to use as my parent"/ "i need to use this component as an
>> 'include'", since its nice to enable your resolution to look in  
>> different
>> places for those two things.  The four built-in contexts in myghty  
>> are
>> "request", "subrequest", "component", and "inherit".
>> Plus you can define your own contexts, such as in one demo I build a
>> "front" controller which then forwards onto a secondary  
>> controller, and it
>> uses different contexts to indicate different search paths (therefore
>> nobody can hit a secondary file directly from the outside).  although
>> those arent even templates, those are controller functions.  are we
>> considering the finder being able to return arbitrary callables  
>> and not
>> just "templates"   (since I like that) ?
>
> Hmm... I'm going to think about the dictionary/callable WSGI-ish  
> approach, because maybe that will make this easier.  Umm... circles...
>
>
> -- 
> Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org