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@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 ) > _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )