> > On Mon, Jul 7, 2008 at 10:04 PM, Justin Tulloss <[EMAIL PROTECTED]> > wrote: >>I have to admit that despite my digging through the source, I >> do not have a good understanding of the StackedObjectProxy class and >> am constantly doing battle with it. > > I don't think there's anybody who doesn't do battle with > StackedObjectProxy.
Hahaha :) I fully agree. However, I also think they're the necessary evil that makes Pylons so powerful, IMHO. What I *love* about Pylons (opposed to TG1, CP2, Django...) is that applications are not singletons but instances so you can have several of them happily sharing the same process. This has changed the way I design my webapps since I can now compose them out of several smaller, easily testable, apps and route to them with yet another app (thanks to the "stacked" part). For example, first Pylons app was a control panel for an ISP which I migrated from TG1 and Pylons helped me solve the issue of giving some clients their own panel which they can sublicense very elegantly: just give them a different instance of the whole app pointing to their database schema with their own auth policy, etc... 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. pylons.c would then become an attribute of the controller (whose lifecycle only spans one request as it does now) as well as the response, the request, the session, etc... (so they don't have to be passed around as controller action's arguments and routing vars can be passed instead). Bonus points if the app that instantiated the controller is also bound to the controller instance since then the controller can refrain form accessing any SOP at all which simplifies the implementation of async apps or apps that stream content which need access to the context from the WSGI iterator. What's the advantage of this: Much easier to understand the whole system and to explain it: pylons.app is magic, it does this and that and you can only access it while a request is in place or when you've mocked it for tests. Alberto --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
