On Tue, Jul 8, 2008 at 2:18 AM, Alberto Valverde <[EMAIL PROTECTED]> wrote: > StackedObjectProxy might not be the best implementation (although I can't > imagine how to improve it since there are so many edge cases involved..., > eg: those that have been tripping people over when testing) but it is > clear that something like this is needed as there are other packages > implementing similar functionality for other frameworks/systems (ie: PJE's > Contextual, and I'm sure Zope has their own SOP thingie somewhere). > > A way I can think to fix the root of the problem is to remove all stacked > object proxies, bind the app globals to the app instance (whose lifecycle > is the same as the process) and pass the per-request stuff around as > function arguments. Perhaps the app instance as well, or at least bind it > to the controllers when they're instantiated. Obviously, this will make > the API much less attractive due to the param-passing nightmare (but will > make FPers very happy ;) > > An intermediate solution, which I favor and have been experimenting with > lately, is to limit the SOPS to just one: pylons.app (the app instance > that holds database connections, cache, etc). Perhaps another SOP at > pylons.app.request could be useful so the request is easily accessible > from helpers intented to be used inside the context of a request.
The Pylons developers have been debating the value of SOPs repeatedly since they were first implemented. The most straightforward and failsafe solution would be to attach the Pylons globals to the controller instance because it's instantiated for each request. But that means they would have to be passed to every other routine that uses them, which brings up nightmare scenarios of dozens of extra arguments, or even passing arguments through a function that it doesn't need but something it calls needs... or maybe something it calls is reimplemented and suddenly it needs a variable it didn't previously. We don't know what variety of routines should ideally access the Pylons globals, but putting them at the module level allows any routine that needs them to access them without argument passing. (Of course, this makes the routines dependent on the Pylons infrastructure, which is why I personally use the globals only in controllers and templates unless I have to (such as a 'c' variable in a validator).) Different implementations have been proposed for the SOPs. They could be turned into ordinary functions, which would signal to the caller that some kind of special processing is going on. That's how Quixote does it: "import quixote; req = quixote.get_request()". But the non-function syntax is too well established in Pylons to change it now. The SOPs could be changed to ordinary thread-local variables. The safety of this is a matter of debate, which is why it hasn't been done. Theoretically it should be OK for 98% of deployment cases that have only one Pylons application instance running in the process. No aggregating two applications with paste.composite, or having multiple instances of a blog app for each blog. After all, the SQLAlchmey contextual session (the Session object, capital s) is a thread-local and it's working fine in Pylons apps. And each request runs from beginning to end in its thread. But when you add the complexity of middleware, things get more complicated. Ian says SOPs are necessary for thread-middleware integrity, and I barely understand what SOPs and the Registry are so I don't want to second-guess him. Having one SOP, pylons.app, containing all the Pylons globals has long been suggested by me. The value could also be attached to the controller instance -- one attribute instead of several. That would be for users who object to getting request info from a module global, and because I've heard there are some situations (some mod_wsgi applications?) that can't use the SOPs. I did come up with a couple situations in my latest app when I was glad SOPs were SOPs, but like everything SOP-related I can't remember precisely what it was, just the feeling I had. A new SOP is on the way too: Routes 2 is planning pylons.url, to replace url_for. So SOPs are here to stay for now but nobody thinks they're ideal. The trouble is, we don't know what would be better. -- 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 -~----------~----~----~----~------~----~------~--~---
