On Sat, Jun 11, 2011 at 1:58 PM, Matt Feifarek <[email protected]> wrote: > On Sat, Jun 11, 2011 at 3:36 PM, Danny Navarro <[email protected]> wrote: >> >> I see Pyramid as just an application (a WSGI app) that just takes >> requests and returns responses. The rest of Pyramid functionality is >> to configure the application in the way it processes the requests and >> returns the responses. > > Yes, I see your point. And I agree; I try and configure my apps this way, > with most code not inside of view-callables, but called *from* view > callables; I hook my code into the events corresponding to requests and > responses; I like this way of thinking, and in principle, it would be easier > to code and debug, since you can just fire off these bits of code from an > interpeter or tests. Needing to have a web request means that I'm stuck > talking through a web browser rather than ipython or something nice like > WingIDE, which is frustrating.
There are about four patterns for accessing application state/request state. One is to import a global object, as Pylons and CherryPy do. Another is to call a global function, as Quixote does. Another is to pass the request object through to every utility function, as Pyramid does. Another is to save it in an instance variable in the view handler, as Pyramid applications often do. Part of the transition from Pylons to Pyramid was an intentional move away from magic globals. They work but they depend on complex threadlocals or StackedObjectProxies, which violate the principle of encapsulation. They create complex interdependencies between the modules in the application and the framework, which in turn makes it more difficult to use the features outside of a request. ``pylons.app_globals`` was the most obvious example of this. People would put a db connection or data structure into app_globals, and then their model would depend on it, and then suddenly they'd discover in a standalone script or a test, that app_globals wasn't initialized. So then the had to research and write custom code to initialize it, and that code would be different from how you normally access it. It's better to just create objects explicitly and pass them through as arguments, then you'll know that they'll work and how they work, without depending on something behind the scenes in the framework, something that might break. -- 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.
