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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
