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