Mailing List Archive: Zope: Dev

REQUEST vs. request

Index | Next | Previous | View Threaded

do3ccqrv at googlemail

Jun 16, 2009, 1:35 PM

Post #1 of 8 (611 views)
Permalink

REQUEST vs. request

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

optilude+lists at gmail

Jun 16, 2009, 5:50 PM

Post #2 of 8 (580 views)
Permalink

Re: REQUEST vs. request [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

aclark at aclark

Jun 17, 2009, 5:38 AM

Post #3 of 8 (578 views)
Permalink

Re: REQUEST vs. request [In reply to]

On 2009-06-17, Martin Aspeli <optilude+lists[at]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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

hanno at hannosch

Jun 17, 2009, 5:47 AM

Post #4 of 8 (576 views)
Permalink

Re: REQUEST vs. request [In reply to]

On Wed, Jun 17, 2009 at 2:38 PM, Alex Clark<aclark[at]aclark.net> wrote:
> On 2009-06-17, Martin Aspeli <optilude+lists[at]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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

hanno at hannosch

Jun 17, 2009, 5:47 AM

Post #5 of 8 (576 views)
Permalink

Re: REQUEST vs. request [In reply to]

reinout at vanrees

Jun 22, 2009, 1:40 AM

Post #6 of 8 (504 views)
Permalink

Re: REQUEST vs. request [In reply to]

On 2009-06-16, Patrick Gerken <do3ccqrv[at]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[at]vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

hanno at hannosch

Jun 22, 2009, 3:18 AM

Post #7 of 8 (502 views)
Permalink

Re: REQUEST vs. request [In reply to]

On Tue, Jun 16, 2009 at 10:35 PM, Patrick Gerken<do3ccqrv[at]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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

do3ccqrv at googlemail

Jun 22, 2009, 3:47 AM

Post #8 of 8 (502 views)
Permalink

Re: REQUEST vs. request [In reply to]

Hi, thank you for all that answers, this was really helpful!

On Mon, Jun 22, 2009 at 12:18, Hanno Schlichting <hanno[at]hannosch.eu> wrote:

> On Tue, Jun 16, 2009 at 10:35 PM, Patrick Gerken<do3ccqrv[at]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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com