On Mon, Apr 14, 2008 at 7:33 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? > >> (...) > > > > > > > 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. (...) > > Well, Python3, WSGI2, etc. Years. > > > > 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 > > I do not quite trust this code (what is my_wsgi_application, why (class) > insteado of (object)...), but let's leave it. The main question is that > here one is still re-creating Request object.
my_wsgi_app is whatever application comes next in the middleware stack. 'class' is a typo. The pattern works; it's being used in middleware now. > What I suggest is that some middleware should create request once and > for good, so lower layers are able to reuse it. That's what I'm saying too. Although I think the server should create the request. > > 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. > > Well, one thing StackedObjectProxies do is that I do not need to > pass environ to every function anymore, referring pseudo-globals > is easier and smoother. It's easier but it makes everything depend on this non-straightforward structure. For instance, the webhelpers are supposed to be independent of any framework, yet you need 'url_for' and 'session' for certain kinds of helpers. They can't access the WSGI environ because they're not a direct descendant of the middleware chain. For WebHelpers 0.7 I'm going to try some kind of generic abstraction layer for framework services, but for now I just punted and let the functions import url_for and session directly, with a note in the docstring saying the helper depends on this or that. -- 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 -~----------~----~----~----~------~----~------~--~---
