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 _______________________________________________ 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 )