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

[Ian Bicking]

Ben Bangert wrote:
>># Or use Kid:
>>kidengine = KidTemplate(**kid_args)
>>content, headers = kidengine('some.template.kid', wsgi=False)
>>
>># web
>>return kidengine(environ, start_response)
>>
>>Or if people don't like relying on the object to determine if there's
>>a keyword with wsgi = False,
>>
>>content, headers = kidengine.render('some.template.kid', wsgi=False)
>>return kidengine.wsgi(environ, start_response)
> 
> 
> Actually, to clarify, it'd be:
> content, headers = kidengine.render('some.template', vars, **extra_args)
> 
> content, headers = kidengine.render(template_string, vars,  
> is_string=True)
> 
> environ['wti.source'] = 'some.template'
> environ['wti.vars'] = vars
> environ['wti.extra'] = dict(is_string=True)
> return kidengine.wsgi(environ, start_response)

This involves a lot of background from the discussion to understand. 
Can this be summarized in a way that is complete?

> Here's my thinking on this:
> 
> First, I don't believe it's terribly realistic to try and unify how  
> the template resource appears. Different template languages use  
> different approaches, Myghty uses a normal path string (relative to a  
> template root dir), Kid uses a module path, etc. You will *always*  
> need to know a certain amount about the template language you're  
> using, whether it needs to have a template root configured, do you  
> give it a resource name as a module path, or filesystem path, etc.  
> Trying to bash them all together will only cripple many or leave them  
> working in bizarre ways.

Many templates provide multiple ways of indicating the template.  So 
they'll have to choose one.  And a good chance that it won't be the one 
  that works for me :(

Even the most trivial of web applications needs templates to include 
other templates, so the fact that this doesn't do anything to aid or 
specify that makes the spec feel leaky.  I can indicate where the 
template comes from initially, but all bets are off after that.

> Second, different template languages can take additional options, we  
> need to retain the ability to pass these in, thus **extra_args. Kid  
> can take the fragment option, Myghty can toggle inheritance, etc.

That seems fine.  Most of the options to render() in the TG spec only 
really applied to Kid.  TG also had the options during instantiation, 
which were intended to be more like compiler options.

I assume that templates should ignore options they don't expect.

> Third, afaik, every template language lets you give it variables,  
> these will be in the vars dict, how the template language gets them  
> to the template is up to the template language.
> 
> So, in this proposal, it is assumed that underneath, there is a WSGI  
> interface that can be called. Whether the render function wants to  
> emulate a WSGI call to the underlying WSGI ability, or just render is  
> up to the template spec implementor.
> 
> What you get out of this:
> - Ability to call as WSGI

Of course, you can't *actually* call it as a WSGI app without some 
container that properly instantiates the engine after it finds the 
template.  So you can't drop templates into an application anymore than 
you can with a non-WSGI spec.  All this does is put an incomplete WSGI 
wrapper into template plugin -- a wrapper which would only have to be 
written once against the TG-style spec anyway.  Except for Phillip's 
insistence on this, I feel thoroughly unconvinced of what a WSGI 
interface accomplishes.

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