Re: [Zope-CMF] [dev] CatalogTool as utility
On Thu, Sep 22, 2011 at 3:14 PM, yuppie y.2...@wcm-solutions.de wrote: My checkin for Products.ZCatalog has an optional dependency on five.globalrequest. If five.globalrequest is not installed, Products.ZCatalog behaves exactly as before. I hope we don't need a Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without five.globalrequest. See http://svn.zope.org/?rev=122892view=rev Is that ok? Should I add an explicit extra in the setup.py of Products.ZCatalog? That's ok. One minor nitpick: Instead of writing: request = getattr(self, 'REQUEST', None) I'd write: request = aq_get(self, 'REQUEST', None) with a module import of: from Acquisition import aq_get That way objects which have only an explicit AQ chain or only __parent__ pointers will also work. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Tue, Sep 20, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote: But an additional ZCatalog branch is an additional maintenance burden. And the required change is small and 100% backwards compatible. The zope.globalrequest dependency could be made optional. Do we really need an extra ZCatalog branch for that? If there's a completely backwards compatible way of doing, we should do that. I was under the impression, that we had to do an API change for some methods and add a new request argument to those. If that argument is required depending on how the tool was retrieved, that's confusing to me and I'd rather go the zope.globalrequest route. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
Hi Hanno! Hanno Schlichting wrote: On Mon, Sep 19, 2011 at 3:56 PM, yuppiey.2011-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: But with zope.globalrequest we can avoid modifying the API. So if it is fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF? I meant ZCatalog 2.14 only for CMF. Having independent distributions allows us to evolve them at a different pace :) But an additional ZCatalog branch is an additional maintenance burden. And the required change is small and 100% backwards compatible. The zope.globalrequest dependency could be made optional. Do we really need an extra ZCatalog branch for that? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On 19 September 2011 14:56, yuppie y.2...@wcm-solutions.de wrote: Hi! Hanno Schlichting wrote: On Mon, Sep 19, 2011 at 11:57 AM, yuppiey.2011-E2EsyBC0hj3+aS/ vkh9...@public.gmane.org wrote: Currently CMF trunk contains some hacks to work around the catalog brain issues. But I hope there is a better solution. Maybe the ICatalogBrain methods getURL, _unrestrictedGetObject and getObject should have a REQUEST argument that is used instead of self.REQUEST? Any kind of feedback and help is welcome. Mmh, why don't we just use zope.globalrequest in ZCatalog directly? And create a new ZCatalog 2.14 release series with this. Then we don't have to wait for Zope 4.0 to include it. Using an explicit argument is always cleaner than using zope.globalrequest. And getObject() already has a (currently unused) REQUEST argument. And we might be able to provide a migration path for the API change: If we don't use registerToolInterface, we don't have to change getObject/getURL calls in places where we still use getToolByName. But with zope.globalrequest we can avoid modifying the API. So if it is fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF? getURL() is an extremely common operation, and is often called in TALES expressions. -100 on making it take a mandatory request parameter when there are other solutions available. Martin ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
