On Fri, Apr 11, 2008 at 8:02 AM, Marcin Kasperski <[EMAIL PROTECTED]> wrote: > > > PylonsApp seems to do two separate things: > > - construct and register objects like request, response, session, g, > h, ... > - dispatch the request to correct controller (and wrap it with > testing support and error handling) > > Couldn't those two be separated? > > Why? Well, I would fairly like to write some middleware-like objects > (not necessarily reusable, more often app-specific) which would > benefit from having access to variables like request, response > and session. > > At the moment the choice is between writing generic WSGI middleware > (so no WebOb, no session, etc) and stuffing the code into > BaseController even if it would look more natural as middleware-like > construct. > > So the suggestion is: what about factoring out PylonsApp into > two parts: WSGI Middleware which would construct pylons environment > (= construct objects like request, response, session etc) and > final application which would just call the controller. Then one > would be able to stuff some layer between the two, writing some > app-wide processing but having access to handy objects...
I've been thinking about something similar, that WebOb has made WSGI obsolete. WSGI will have to change anyway in Python 3 due to the changing relationship of string to Unicode. Some have suggested simultaneously upgrading to the long-discussed WSGI2 proposal, which would simplify the API somewhat. But really, why are we using WSGI in the first place? Is it anything that WebOb can't do, or couldn't do with a little tweaking? Do people really want to deal with the clunky environ dict and header lists (which every middleware has to parse and update manually in its own way), when webob.Request and Response are much more pleasant? The reason a high-level request/response wasn't included in WSGI was that people were afraid to take sides in the API wars. Any API would invariably be closer to one framework/philosophy than another, and dissenting frameworks would be disinclined to adopt WSGI. They also wanted to stick to builtin Python types to ensure universal interoperability; e.g., sending the request through a socket, chunked output, asynchronous output, and who knows what else might emerge. Now after three years of WSGI, we've seen what it's being used for, what works, and what doesn't. There has also grown unprecedented cooperation between frameworks, which was the original goal. And Paste, being framework neutral, has been able to encourage the adoption of neutral high-level objects. Pylons and TurboGears have adopted Request/Response. Django and Repoze have no major objections to it even if they aren't using it. And Twisted has an equally difficult situation either way. (Though attention must be paid to chunked output, asynchronous calls, and pickling request, either within the spec or in a companion Async spec.) We don't even need to wait for Python-wide adoption of this strategy. All that's needed is a wrapper for a WSGi server, an alternate PylonsApp, and wrapped/reimplemented middleware for the required stuff. Most middleware libraries keep their logic separate from the WSGI compatibility class, so it wouldn't be too difficult to make a few alternate classes. Then it can all be tied together in middleware.py. And it wouldn't affect the traditional usage of Pylons in any way. I want to try this as an experiment someday, but there's so much to do for Pylons 0.9.7 and 0.9.8 that it will be a while. In the meantime, WebOb has a design pattern to make writing middleware much easier. See "Writing your own middleware with WebOb" in What's New in Pylons 0.9.7. http://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779 As for getting the session, it's in a WSGI environment variable. environ['beaker.session'] and environ['beaker.get_session'](), it looks like. Accessing the Pylons globals (pylons.request, pylons.response, pylons.session) means you're going through StackedObjectProxies, which just adds complication. More to the point, you don't need it, at least for request/response/session. pylons.g is another matter. But here it is: environ['pylons.pylons'].g . (along with request, response, session, c, h, and cache) I can't find 'config' anywhere though I thought it was there. But you can import it: "from pylons import config". Why deal with the clunky environ dict and headers list when WebOb.Request and Response are much more pleasant? The reason a high-level request/response wasn't included -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
