On Sun, Mar 14, 2010 at 2:18 PM, Hans Lellelid <h...@velum.net> wrote: >> I think there's an attribute on the controller instance, >> ``._py_object``, that contains the request/response/session, etc. And >> I think you can disable the magic globals by commenting out the >> RegistryManager in middleware.py. You can hunt about in the >> interactive traceback. > > Ah, thank you; I have not yet experimented with the RegistryManager; I will > go down that route to see if it provides a path for achieving what we want > (elaborated below). (And maybe setting them directly on controllers would > provide workaround for certain test cases.)
I think non-SOPs were originally necessary for asynchronous applications. I don't know much about that though. >> There has been a lot of discussion about >> replacing the SOPs with threadlocals. Also, Pylons 2, built on Marco, >> will not depend on them, although the compatibility layer will have to >> support them for existing apps. > > Ah, that's excellent (especially if the compat layer can be disabled). I > haven't been following Pylons 2 plans; I'll start reading up on that. There's not much to see, and no alphas have been released yet. But Ben says Pylons runs on Marco at least for a few simple apps. There should be an announcement later this year when an alpha is ready. But first 1.0 needs to be finished. > Well, my main problem is testing-related; I agree that in the normal course > of events they don't get in the way much, but it feels like they get in the > way all the time when unit testing (but this is important to us). Here's a > very specific case, but seemed to be a general problem we ran into with > SOPs: > > We use generic services modules; say we have services/user.py which > contains methods like createUser(), deleteUser(), etc. These services are > exposed via JSON-RPC or AMF gateways (often both), which are just WSGI apps > that we plug in as Pylons controllers. So, (for example) our services.user > module will probably be doing checks against `pylons.session`. I want to be > able to have my UserServiceTest.setUp() method inject authentication > information into `pylons.session` so that tests in our service layer think > we have a valid session (for example). What we've found is that the > `pylons.session` in our test case is not the same as the `pylons.session` > that the services.user service imports. (Does that make sense? -- I may be > misremembering something here.) There are a lot of potential problems in the testing environment, ranging from getting the config early enough, to post-testing the session. Ben and Philip and Ian have done a good job of building as much of that as possible into the TestController and WebError. I still don't understand it very well, and the docs help only so far. You'll probably get a better answer on pylons-discuss, and we can invoke Ian if necessary for advice. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
