Hello, I am a bit confused about self.request and self.REQUEST. Can anybody point me to an explanation of the different tasks that both have? Googling for request vs REQUEST is not helpful... Here is the reason why I am wondering: Context is a small product to be used in plone. A testcase in my code fails, and after a lot of digging, I am finding that the reason are wrong results from the catalog. The catalog returns bad results because he caches the results in the request. My test consists of a number of steps, for multiple times I do a getMultiAdapter, always with fresh TestRequests. Still it seems, that the catalog always use some other, rotten REQUEST. When stepping through, I see this happening: 1. my BrowserView calls something like self.context.portal_catalog(kw) There is no request as an argument 2. The method I call wants that as a positional argument, but has None as the default value That None value gets passed on. 3. In Products.ZCatalog.Catalog:searchResults the code checks whether the REQUEST variable is None, and if so, retrieves self.REQUEST. self.REQUEST ist the rotten REQUEST, self.request would still be available 4. Total chaos is ensured I can imagine more than one way to fix it, but I don't understand the difference and reasoning sufficiently to decide, what would be the right(tm) way to fix it. Any points will be really appreciated! Best regards, Patrick
Patrick Gerken wrote:
Hello,
I am a bit confused about self.request and self.REQUEST. Can anybody point me to an explanation of the different tasks that both have? Googling for request vs REQUEST is not helpful...
D'oh! :-) REQUEST is a Zope2-ism. When you do self.REQUEST somewhere, you are actually using acquisition to get this object from the outermost item in any (most?) acquisition chain: a magic RequestContainer class whose purpose it is to let you acquire a REQUEST. In general, this is a bit icky. You probably should avoid it. self.request is not generally available. Rather, it's the most commonly used name for the request stored on an attribute in a view or viewlet. These are initialised with a context and a request (and view and viewlet manager in the case of a viewlet), and normally store those as self.context and self.request. In Zope 2, your views *also* support acquisition, because until Zope 2.12 at least, they have to in order to have security. So you can do self.REQUEST on the view, which acquires it from a parent. But this is magic and you shouldn't do it if you can avoid it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 2009-06-17, Martin Aspeli <optilude+lists@gmail.com> wrote:
REQUEST is a Zope2-ism. When you do self.REQUEST somewhere, you are actually using acquisition to get this object from the outermost item in any (most?) acquisition chain: a magic RequestContainer class whose purpose it is to let you acquire a REQUEST.
In general, this is a bit icky. You probably should avoid it.
self.request is not generally available. Rather, it's the most commonly used name for the request stored on an attribute in a view or viewlet. These are initialised with a context and a request (and view and viewlet manager in the case of a viewlet), and normally store those as self.context and self.request.
In Zope 2, your views *also* support acquisition, because until Zope 2.12 at least, they have to in order to have security. So you can do self.REQUEST on the view, which acquires it from a parent. But this is magic and you shouldn't do it if you can avoid it.
Good explanation, thanks! So in Zope 2.12 we get "z3 style" security?
Martin
-- Alex Clark · http://aclark.net Buy Practical Plone 3: http://tinyurl.com/practical-plone
On Wed, Jun 17, 2009 at 2:38 PM, Alex Clark<aclark@aclark.net> wrote:
On 2009-06-17, Martin Aspeli <optilude+lists@gmail.com> wrote:
In Zope 2, your views *also* support acquisition, because until Zope 2.12 at least, they have to in order to have security. So you can do self.REQUEST on the view, which acquires it from a parent. But this is magic and you shouldn't do it if you can avoid it.
Good explanation, thanks! So in Zope 2.12 we get "z3 style" security?
No. zope.security style security is very different then Zope 2 style security. The two are quite unlikely going to merge at any point. What we get in 2.12 is that Acquisition as used by AccessControl is able to find the acl_users folder from a context that is not Acquisition wrapped via __of__ but has only __parent__ pointers. See http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#acquisition-redux for some more detailed information. Hanno
On Wed, Jun 17, 2009 at 2:38 PM, Alex Clark<aclark@aclark.net> wrote:
On 2009-06-17, Martin Aspeli <optilude+lists@gmail.com> wrote:
In Zope 2, your views *also* support acquisition, because until Zope 2.12 at least, they have to in order to have security. So you can do self.REQUEST on the view, which acquires it from a parent. But this is magic and you shouldn't do it if you can avoid it.
Good explanation, thanks! So in Zope 2.12 we get "z3 style" security?
No. zope.security style security is very different then Zope 2 style security. The two are quite unlikely going to merge at any point. What we get in 2.12 is that Acquisition as used by AccessControl is able to find the acl_users folder from a context that is not Acquisition wrapped via __of__ but has only __parent__ pointers. See http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#acquisition-redux for some more detailed information. Hanno
On 2009-06-16, Patrick Gerken <do3ccqrv@googlemail.com> wrote:
A testcase in my code fails, and after a lot of digging, I am finding that the reason are wrong results from the catalog. The catalog returns bad results because he caches the results in the request. My test consists of a number of steps, for multiple times I do a getMultiAdapter, always with fresh TestRequests. Still it seems, that the catalog always use some other, rotten REQUEST.
I've had the same problem in some test. If I remember correctly it had to do with the path index. What I did in the end in my doctest was to delete the REQUEST attribute that the index used for caching. It looks a bit weird to have a delete_interfering_request_to_fix_test() all the time, but it worked. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets
On Tue, Jun 16, 2009 at 10:35 PM, Patrick Gerken<do3ccqrv@googlemail.com> wrote:
A testcase in my code fails, and after a lot of digging, I am finding that the reason are wrong results from the catalog. The catalog returns bad results because he caches the results in the request. My test consists of a number of steps, for multiple times I do a getMultiAdapter, always with fresh TestRequests. Still it seems, that the catalog always use some other, rotten REQUEST.
Looking at this again, you are missing an important point about the test framework you use. In all of ZopeTestCase (CMFTestCase, PloneTestCase) you get a convenience request object set up for you, reachable as app.REQUEST. This mirrors the way you usually get access to the request object in Zope2 via Acquisition down to the application root. It's meant to emulate a very minimal request object. Now in normal operation, you would get one request object per HTTP request. This also works in the functional variants of the test case classes. In the non-functional test classes you only ever get one request object set up, as there's no object publishing or HTTP request handling being done. If you or any code you call changes any settings on that request object and you want to test things dependent on this you have two options: Either create a fresh request yourself (using Testing.makerequest) in your tests or use a functional test case instead. Especially in Plone where quite a bit of information is cached on the request object, you can run into this situation. Hanno
Hi, thank you for all that answers, this was really helpful! On Mon, Jun 22, 2009 at 12:18, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jun 16, 2009 at 10:35 PM, Patrick Gerken<do3ccqrv@googlemail.com> wrote:
A testcase in my code fails, and after a lot of digging, I am finding that the reason are wrong results from the catalog. The catalog returns bad results because he caches the results in the request. My test consists of a number of steps, for multiple times I do a getMultiAdapter, always with fresh TestRequests. Still it seems, that the catalog always use some other, rotten REQUEST.
Looking at this again, you are missing an important point about the test framework you use.
In all of ZopeTestCase (CMFTestCase, PloneTestCase) you get a convenience request object set up for you, reachable as app.REQUEST. This mirrors the way you usually get access to the request object in Zope2 via Acquisition down to the application root. It's meant to emulate a very minimal request object.
Now in normal operation, you would get one request object per HTTP request. This also works in the functional variants of the test case classes.
In the non-functional test classes you only ever get one request object set up, as there's no object publishing or HTTP request handling being done. If you or any code you call changes any settings on that request object and you want to test things dependent on this you have two options: Either create a fresh request yourself (using Testing.makerequest) in your tests or use a functional test case instead.
I did excactly that. Since it was a caching issue in code out of my reach, I had problems with. Sadly, creating a new request and saving it on self.app.REQUEST was not enough. The code in question acquires the method that caches something on the REQUEST from a getSite() call. It seems like getSite() returns a copy of the site, and that has its own copy of the request too.
self.app.REQUEST == getSite().REQUEST True
self.app = makerequest(self.app) self.app.REQUEST == getSite().REQUEST False
The copy getSite() returns is deleted in an EndRequest Event handler... I did not use zc.testbrowser for testing, because I did test XMLRPC Methods, and it seemed easier to just use getMultiAdapter and test the view directly. I solved my issues but it is a bit inconvenient nowadays... Best regards and thank you! Patrick
participants (5)
-
Alex Clark -
Hanno Schlichting -
Martin Aspeli -
Patrick Gerken -
Reinout van Rees