[Zope-dev] zope.globalrequest?

[Martijn Faassen]

Hi there,

Roger Ineichen wrote:
[snip]
> Why should someone use a global request if he has a request 
> available? This package does nothing else then offer a request
> if non is available. And if you need a request if non is available
> there is something wrong with the application design. Or better
> let's say it's another pattern then we use in zope 3 right now.

I don't think that's always true.

Let me give you an example. I wrote a library called hurry.resource.

This library is framework neutral. You can define a javascript or css 
resource and express that you need it to be included in the page in a 
certain code path:

yui.datatable.need()

I also have a library called hurry.zoperesource. This library provides 
integration of hurry.resource with Zope 3. When need() is called in a 
Zope 3 context, I need the request object as I chose the request object 
as the place to store the list of resources that are needed. So I need 
to get the request without having it.

You could argue my library isn't designed right, and that instead I 
should require people to pass 'request' to the .need() method. But since 
hurry.resource is framework-neutral, what request should that be? And in 
a system like Pylons it makes no sense to have to pass in the request, 
as it's available globally everywhere. It only seems to put an 
implementation detail into the API.

Besides the framework neutralness argument, which you can argue makes no 
sense, I think it's simply a nicer API to say '.need()' instead of 
having to pass the request. That's a weaker argument, however. That 
said, zc.resourcelibrary does the same strategy, as that's where I took 
it from.

Anyway, I do believe there are cases of APIs that need the request 
internally but want to abstract it away as an implementation detail. I 
guess I might've been able to use the interaction directly in Zope 3's 
case and I shall study that.

There are of course drawbacks (as mentioned) with testing and such when 
taking this approach. But I think one can make a reasonable case for 
such an API nonetheless, when used in moderation.

Regards,

Martijn