[Web-SIG] Standardized template API

[Ben Bangert]

On Feb 2, 2006, at 11:49 AM, Phillip J. Eby wrote:

> For frameworks like TurboGears that treat a template as a formatter  
> of the
> return value of some Python code, the difference wouldn't be
> user-visible.  And for frameworks, servers, or tools that use WSGI
> internally now (e.g. Paste, Routes, maybe Pylons?) there might not  
> be any
> implementation to do at all, except to add support for loading/ 
> compiling
> resources.  These tools can already run WSGI apps, they just need  
> support
> to allow mapping URLs to templates.

Since Pylons is just using Myghty, it still has full access to the  
WSGI call, so does RhubarbTart and Paste, so we'd all be set for this  
style. Recent discussion/patches to CherryPy indicate that they're  
putting in support to retain the full WSGI environ/start_response  
stuff so they'd be able to use it as well.

>          # framework-specific code to parse environ and figure out
>          # where the URL points to, updating SCRIPT_NAME and
>          # PATH_INFO as it goes, so SCRIPT_NAME points to the template
>          # when done, while adding any framework-specific variables to
>          # environ

My main concern here, though its likely just a detail I'm not seeing.  
When you call the template engine with the WSGI environ, I'm a bit  
worried about URL generation. For example, Routes is WSGI aware, and  
if it sees SCRIPT_NAME, it'll prepend it to generated URL's.

When you render templates, the template name in many cases has  
nothing to do with anything present in the URL. The URL might be / 
comment/view/4, and the template rendered relative to the template  
root is '/viewers/comment.myt'. Myghty already has a WSGI handler,  
and has its own internal response/request objects, so its already  
suited quite well for the interface it sounds like you're proposing.  
However, to tell Myghty I'd want that path rendered, I'd have to set  
PATH_INFO to '/viewers/comment.myt'.

In this case, its possible Routes could still generate proper URL's  
as long as the SCRIPT_NAME only contained whatever was necessary to  
reach the WSGI app that ran the Route match. If SCRIPT_NAME is  
further messed with on the way to the template engine, the generated  
URL would be broken.

For this reason, I think sending the request to a template engine via  
WSGI is fine, except SCRIPT_NAME should not be touched, since thats  
still where the "application" responding is located. Also, since  
PATH_INFO is now referring only to the template to be rendered, its  
un-reliable for purposes of determining the full URL.

Actually, now that I think about it, if we want to use WSGI for the  
template engine, I think it'd better to put additional keys in the  
environ for what template path to render, etc. This way vital  
information for URL generation isn't altered in ways that might  
result in broken URL's.

>      def trivial_template_app(environ, start_response):
>          output = ["some %(someVar)s text" % environ['wti.source']]
>          start_response("200 OK", [('Content-type','text/html')])
>          return output

Looks fine to me, except for the concerns I cited above for how the  
template engine should determine the template to render.

> Templating tools are then in a position to offer response- 
> management API
> directly.  For example, a ZPT wrapper could offer Zope-style
> REQUEST/RESPONSE objects for use in the template, because it would be
> dealing with WSGI.

Yep, makes sense to me, especially since Myghty already does this.

> The single strongest argument that I think can be made *against*  
> the WSGI
> approach is quite simply that I'm asking framework developers to  
> help make
> their frameworks obsolete, by moving their request and response  
> objects to
> the periphery of their frameworks, so that developers have not only a
> choice of template *syntax*, but also a choice of request/response  
> APIs
> associated with those templates.

Excellent. :)

Cheers,
Ben