At 01:48 PM 2/2/2006 -0500, Michael Bayer wrote:
>Can those of us who
>have worked less with "the high end" see some real examples of what
>they need, and how they will be marginalized by a template adapter
>API?
Have you ever used PHP? ASP? DTML? Specifically, have you ever used them
to generate any content-type other than HTML? This is a trivial example of
a use case that a vars'n'strings approach doesn't support, without
basically reinventing a new protocol that duplicates WSGI.
I totally understand that for the frameworks where the current
vars'n'strings proposal originated, this is a non-issue because they always
have Python code between the framework and the template. But there are
plenty of frameworks (and templating engines) where what you want is to
*just have a template* in order to implement a URL, either as a method of a
published object, or just as an "active page".
The vars'n'strings approach can't do active pages, the WSGI approach can.
>Should those of us concerned about WSGI maybe try out a WSGI- centric idea
>and see how that goes ? Even though I am skeptical of
>it, I've hardly any concept of what it would even look like.
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.
Tools that don't do WSGI yet internally would have to add a WSGI "server"
component that creates an environ dict and add a start_response/write/iter
facility. These aren't that complex, and if the framework is itself a WSGI
application, it can simply pass through a modified version of the 'environ'
it received from the original WSGI server, along with the 'start_response'
it received. It then has to simply return the template's return value to
the WSGI server. In short, the framework just has to act like WSGI
middleware. A trivial example:
def framework_app(environ, start_response):
# 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.
if found_a_template:
# framework-specific code to figure out what template
# engine the template uses
# ask the engine to load a WSGI app from a file
# (or wherever)
app = engine.compile_stream(open(filename,'r'))
# Run the app against the original environ/start response
# and return its return value, unless the framework needs to
# alter the output some way (in which case it should do normal
# WSGI middleware stuff).
return app(environ, start_response)
Now, if you compare this to what you have in the case of vars'n'strings,
you'll notice that one thing this code is *missing* is the code to set a
default content type, status, etc., while dumping out the "string". In the
WSGI approach, that code moves to the *template* side of the fence. If the
framework needs to add or modify headers, it can do so by passing in an
altered start_response, e.g.:
def my_start(status,headers):
# framework-specific code here to munge headers
return start_response(munged_status, munged_headers)
return app(environ,my_start)
Does this put more burden on framework developers? Probably so. It will
be the most burdensome for frameworks that don't carry WSGI deep inside
themselves, or whose APIs don't provide any way to do the things WSGI
allows. They may have to write code that recreates WSGI from an internal
request or response object, possibly containing already-parsed form data
and cookies and such. Or, they may simply need to move their traversal or
routing logic nearer to their WSGI input, so that any framework-specific
request/response objects are created "just in time".
Does this put any significant burden on template developers? Probably
not. The most trivial template wrapper would consist of something like:
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
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.
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.
Perhaps that's an unrealistic idea; maybe it's too soon to push for WSGI
adoption phase 2 (the de-frameworkification of the frameworks). Maybe the
only realistic consensus at this point in time is a niche API for
vars'n'strings. Maybe the only way to showcase the power of what I'm
proposing is to make WSGI wrappers for some template engines and implement
the load/compile/save API I proposed on some server-side stuff. I just
don't want to end up in the position of having spent time to write Yet
Another Framework, as opposed to contributing code to a common standard.
_______________________________________________
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
