[Zope-dev] zope.globalrequest?

[Roger Ineichen]

Hi Martijn

> Betreff: Re: [Zope-dev] zope.globalrequest?
> 
> 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.

I see your point. I'm not saying that this is bad in general.
Probably "when used in moderation" is the right concept for this
package ;-)

Regards
Roger Ineichen

> Regards,
> 
> Martijn
> 
> _______________________________________________
> 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 )
>