[Web-SIG] Standardized template API

[Ian Bicking]

Michael Bayer wrote:
> do either of these specs address the concept of componentized  templates 
> ?  that is, when you are referencing a template, compiling  its output, 
> and delivering its textual output, in reality that  template would 
> consist of possibly dozens of smaller sub-templates,  to form different 
> parts of the page, and also to form various nesting  schemes.  In 
> myghty, the resolver stack, i.e. the thing that takes  some kind of 
> string, runs it through some rules (which can be a  straight down list 
> or a whole structure of conditionals and groups),  and produces a 
> template object (actually called a component), is not  used only for 
> handling the initial URL from an HTTP request.  

I think you can do this with my second proposal, which uses 
find_resource.  In that model I imagine something like:

   find_resource = MyghtyResourceFinder(request info...)
   plugin = MyghtyPlugin()
   tmpl = find_resource(plugin, '/index.myt')
   plugin.render(tmpl, {})

The tmpl object knows that it is named '/index.myt', and it has a 
reference to find_resource, so it can use that to find sub-templates. 
The only context that is passed to find_resource in that model is the 
(optional) template that is getting the new template.  There's no 
subrequests, and maybe not some of the other things you are 
considering... but that might not be a problem, I'm not sure.

Because when you get a subtemplate with find_resource you are just 
*getting* it, you aren't filling it quite yet.  So if you phrase that 
inclusion as a subrequest, maybe that just means that you fill that 
subtemplate with different arguments that indicate that.  Unless you 
need to know that it is a subrequest (beyond just checking for the 
presence of the relative_to argument), or need to know the chain of 
calls or something.


-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org