Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
Hi Tres! Tres Seaver wrote: > yuppie wrote: >> Tres Seaver wrote: >>> Log message for revision 97800: >>> Clean out module-scope imports. >>> [...] >> What was wrong with these imports? > > I don't like module-scope imports in unit tests: I want tests to > *fail*, not be skipped, when something is not importable. I put my > rationale in this blog entry: > > > http://palladion.com/home/tseaver/obzervationz/2008/unit_testing_notes-20080724 Thanks for the pointer. I agree with the "Never import the module-under-test at test module scope"-rule, but I'm not convinced the "Minimize module-scope dependencies" guideline is important. If you don't like module-scope imports and I don't like method-scope imports we need a policy to make sure we don't work against each other. I'm fine with following your policy if you think it is important, but I think we need an official decision. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Miles wrote: > Hi, > > > >>> Could we push this further down the stack to the ZCatalog, making it >>> unnecessary to override catalog_object in CMF? AFAICS all CMF-specific >>> stuff could be done inside the wrapper. >> Maybe. Touching ZCatalog is kinda scary, though. > > I think trying to remove catalog_object completely might require > significantly more thought. There are lots more ways in which the basic > ZCatalog can be used that we need to consider, in contrast to > CatalogTool. What happens if you have two catalogs - should they always > both apply the same wrappers? What if you want an unwrapped object to > be cataloged in one of them? It's making my head hurt ... It would be an additional hook. If no wrapper is registered the behavior of ZCatalog would be exactly the same as now. But so far we don't have decided to make Zope 2.12 required for CMF 2.2, so we have start with an implementation in CMF. For now I just want to make sure we don't add CMF-specific stuff if we don't need it. > However, one thing that I'd like an opinion on is whether it's useful to > move the handling of workflow variables out of catalog_object and into > the IndexableObjectWrapper class? To my mind it seems cleaner to move > it, but I'm not sure on the BBB impact. +1 I can't see any additional BBB issues. Who ever uses a customized IndexableObjectWrapper uses also a customized catalog_object method. I'm still not sure if we should just adapt the object or also the portal or the catalog: Registering different adapters for different portals doesn't make much sense to me. If you need portal specific behavior you can register local adapters. Registering different adapters for different kinds of catalogs might be more useful and while 'portal' is a CMF specific concept the catalog itself exists always. The other reason for adapting portal or catalog is that we want to use them inside the adapter. We need some kind of context for looking up stuff like workflow variables. But do we need the portal, the context of the catalog or the context of the object? If the context of the object is sufficient, we don't need a multi-adapter. If we just need the catalog and its context, we still have a generic solution for Zope 2. If we need the portal, we have a CMF-specific solution. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Wichert Akkerman wrote at 2009-3-10 10:01 +0100: > ... >The debate is currently focusing on GPL versus BSD license. Any opinions >on a choice between those two would be very welcome. I like BSD more, but could live with LGPL as well. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi, >> Could we push this further down the stack to the ZCatalog, making it >> unnecessary to override catalog_object in CMF? AFAICS all CMF-specific >> stuff could be done inside the wrapper. > > Maybe. Touching ZCatalog is kinda scary, though. I think trying to remove catalog_object completely might require significantly more thought. There are lots more ways in which the basic ZCatalog can be used that we need to consider, in contrast to CatalogTool. What happens if you have two catalogs - should they always both apply the same wrappers? What if you want an unwrapped object to be cataloged in one of them? It's making my head hurt ... However, one thing that I'd like an opinion on is whether it's useful to move the handling of workflow variables out of catalog_object and into the IndexableObjectWrapper class? To my mind it seems cleaner to move it, but I'm not sure on the BBB impact. Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
yuppie wrote: > Why is IIndexableObjectWrapper in Plone a multi-adapter and not a simple > adapter for object? Some of the indexers need access to the site root. I think the idea was that you could have different adapters in different types of sites by marking the site root, but a single adapter is probably enough. > Could we push this further down the stack to the ZCatalog, making it > unnecessary to override catalog_object in CMF? AFAICS all CMF-specific > stuff could be done inside the wrapper. Maybe. Touching ZCatalog is kinda scary, though. >> Still, the important use case, imho, is to make custom "indexers" for >> your custom types. I quite like the pattern in plone.indexer where we >> use an annotation to make a function into an indexer adapter: >> >> http://pypi.python.org/pypi/plone.indexer > > I agree that's an important use case, but looking up > IIndexableObjectWrapper based on the object provides already a solution > for it. So we have a basic solution inside the framework and hook for > plugging in alternative solutions like plone.indexer. Yep, I think that's a good idea. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: > yuppie wrote: >> Martin Aspeli wrote: >>> yuppie wrote: >>> AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. >>> Bear in mind that there is a difference between getting the wrapper >>> itself, and getting the value to catalogue for a particular *attribute* >>> of the wrapper (e.g. allowedRolesAndUsers). >> Why do we need the wrapper? Why can't we look up directly the adapter >> for the particular attribute? > > This could work as well. It does make it harder to change the policy en > masse for a particular type (you'd need to override all the adapters, > say). One reason to do that may be if you have a very simple object that > you know exactly how to catalogue, and you don't want the overhead of > looking up various adapters. I did have a closer look at this: The right place for looking up attribute specific adapters directly is deep in the ZCatalog code. And it might indeed be overkill to use separate adapters for several attributes of several content types. So now I basically agree with the solution Miles and you did propose. But I still have some questions: Why is IIndexableObjectWrapper in Plone a multi-adapter and not a simple adapter for object? Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. > Still, the important use case, imho, is to make custom "indexers" for > your custom types. I quite like the pattern in plone.indexer where we > use an annotation to make a function into an indexer adapter: > > http://pypi.python.org/pypi/plone.indexer I agree that's an important use case, but looking up IIndexableObjectWrapper based on the object provides already a solution for it. So we have a basic solution inside the framework and hook for plugging in alternative solutions like plone.indexer. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
