[Web-SIG] Standardized template API

[Ian Bicking]

Phillip J. Eby wrote:
>> My criteria is that it would be easy to implement Phillip's proposal 
>> in terms of mine (and I could provide a sample implementation of that 
>> if it would help), but it doesn't seem so easy to do the opposite.
> 
> 
> Actually, I believe you've got that backwards.  Many things the WSGI 
> embedding proposal can do, yours can't do *at all*, no matter how much 
> programming you do.  vars'n'strings isn't a substitute for WSGI, but 
> it's easy to piggyback other payloads *out* of WSGI using 
> file_wrapper-like APIs or dual-use objects with "__call__" methods.

What exactly can't I do with a WSGI application (a specific 
implementation) that uses the non-WSGI plugin API?

>> For instance, there's no way for a Cheetah template to extend a WSGI 
>> application.  It can extend other Cheetah templates, and even other 
>> Python classes, but not a WSGI app.
> 
> 
> Provide extension APIs to allow finding other templates.  Putting them 
> in this context also helps make it clear that such APIs aren't -- and 
> *can't* be -- universal, because the templates themselves aren't 
> heterogeneous.  You can't give a Cheetah template a Kid subtemplate.

My API always indicates the type of object you are looking for, though 
that may be too strict, as you don't *always* want to have a single 
type.  Though if there is a defined exception when a resource can't be 
found, maybe that could be handled at a higher level than find_resource.

> I'd prefer to take up template finding in the context of a resource 
> deployment proposal, where I think we can get a lot more leverage.  But 
> if it enables needed use cases today, I could get behind providing a 
> simple -- and *optional* -- template finding API as part of the WSGI 
> template/resource proposal, especially if discussing it helps lay the 
> groundwork for the resource deployment proposal.
> 
> 
>> It's up to you to handle that in your application.  So you might pass 
>> in the WSGI environment as some variable, or the specific header, or 
>> you might select a template based on that header.
> 
> 
> You're presuming a controller-based architecture here, not an 
> object-publishing one or a PHP/ASP style "active pages" one.  That's 
> ignoring what, maybe half the web frameworks?

object-publishing is a subset of controller-based frameworks, where 
there is a single controller known as the "object publisher".  In an 
active page model the controller is the framework (insofar as you want 
to project MVC terminology onto such systems).

Here's a rough WSGI implementation of active pages using the resource spec:

class TemplateApp(object):
     def __init__(self, find_resource, ext_to_plugin,
                  index_name, default_ext):
         self.find_resource = find_resource
         # a dictionary of extensions to instantiated plugins:
         self.ext_to_plugin = ext_to_plugin
         self.index_name = index_name
         self.default_ext = default_ext
     def __call__(self, environ, start_response):
         # actually empty path_info should cause a redirect...
         path_info = environ.get('PATH_INFO', '/')
         if path_info.endswith('/'):
             path_info += self.index_name
         parts = path_info.rsplit('.', 1)
         if len(parts) == 1:
             ext = self.default_ext
             resource_name = path_info + ext
         else:
             ext = '.'+parts[1]
             resource_name = path_info
         plugin = self.ext_to_plugin[ext]
         environ['response.headers'] = {'Content-type': 'text/html'}
         resource = self.find_resource(plugin, resource_name)
         body = response.plugin.render(resource, {'environ': environ})
         start_response('200 OK', environ['response.headers'].items())
         return [body]

There's a bunch of sloppy WSGI constructs, and the environment isn't a 
great request object, but that's not really the point.

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