Miles wrote:
> Hi,
> <snip>
>>> 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.


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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to