I'm struggling with the decision of whether I should backport
"use_wsgi_app"-type functionality to tg1.1b2, if I should hold off
until 1.5, or even if it's a mis-feature that shouldn't be backported
at all.
As a memory refresher, "use_wsgi_app" is a TG 2.0 feature that is used
to return a WSGI application from an exposed controller, and the
ticket for backporting it to TG 1.x is #1951. Anyway, here's why I'm
struggling:
(a) I'm not sure that use_wsgi_app's interface is right. I think it
would be better if it allowed the WSGI app to be used directly from a
controller. For example, instead of this:
class MyController(Controller):
@expose()
def some_controller(self, *args, **kwargs)
return use_wsgi_app(your_wsgi_app)
How about this?
class MyController(Controller):
some_controller = use_wsgi_app(your_wsgi_app)
In the former approach, the expose() decorator seems extraneous --
since we're dispatching to a whole app and not just a page, expose
parameters such as "template" don't have any meaning.
(b) Robert Brewer has decided to remove tools.wsgiapp when CherryPy
3.2 comes out (CP ticket #700). He also has a blog post, "Please
don't use wsgiapp" [1], in which he states that the wsgiapp tool "1)
it doesn't conform to the WSGI spec (and cannot be fixed to do so),
and 2) there's a better way to mix content in a CherryPy site:
tree.graft."
His point 1 is half right -- since tools.wsgiapp consumes the response
instead of allowing an iterator to be returned, it doesn't adhere to
PEP 333. However, there's no reason that it couldn't be fixed -- it's
a handler, and handlers can return iterables just fine.
For a long time I thought his second point was simply a matter of
taste, but now I'm coming around to his point of view. If we're
adding another whole app to our site, it's going to come with it's own
set of middleware. Some of that is likely to overlap ours, and some
of ours might not be needed. It'd be better to leave the splitting
of that hair to the developer of the app, not the framework.
Of course, if you don't like that argument against backporting
use_wsgi_app, you should read Robert's blog post. One of his
arguments may sway you if mine doesn't.
(c) In CP3, applications that are added to the tree via graft are pure
WSGI, which means you can't use tools or hooks. The biggest problem
here is that identity requires the visit tool, so using it to secure
the WSGI app isn't possible right now. If course we can rewrite
visit to be WSGI middleware, or migrate to repoze.who/what, but it'd
be better if someone who actually has this itch were to take a shot at
scratching it. I think the community would be better served if I got
back to cleaning up my other tickets & getting the core of TG 1.5 up
to beta quality.
(d) The test cases that I added to #1951 are rather uninteresting.
If we're going to move in a direction that the CherryPy team is
actively discouraging, we need solid tests & use cases.
So right now I'm leaning towards closing 1951 as wontfix, but I'm open
to suggestions.
-Ken
[1] http://www.aminus.org/blogs/index.php/2007/07/24/please_don_t_use_wsgiapp
PS: For the casual reader that just wants to know what mounting a wsgi
app inside of a TG 1.5 site would look like, please see
http://pyamf.org/wiki/CherryPyHowto and
http://www.gordontillman.info/Development/DjangoCherryPy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
