>> This should work with plain CMF and be simple to hook into the catalogue
> (For me) this is the root of the problem - it can only be hooked into
> the catalog by subclassing at the moment, there is no other mechanism to
> use different implementations. If there was, then plone.indexer (or
> whatever) could be used directly.
> Therefore, can I make a proposal (which I am happy to carry out), as I
> think this is a desirable change?
> PROPOSAL: Use CA to look up the indexable object wrapper
+1 - Plone already has this, and it's pretty easy to do. If CMF got
this, then Plone could drop its own custom adapter and use the CMF one
to hook in plone.indexer, as could anyone else wanting to use this package.
> PROBLEM: It is not possible to provide alternative implementations of
> the IndexableObjectWrapper class at the moment - this prevents
> customising the indexing process.
> SOLUTION: Look up the IndexableObjectWrapper using the Component
> Architecture. The catalog tool will look up a named utility that
> creates a wrapped object suitable for indexing.
Actually, I'd suggest you look it up as an adapter on the object being
indexed. Also, it probably shouldn't be named, as there's nothing to
"switch" the name on.
> The default implementation of the utility will return the object
> wrapped using the current IndexableObjectWrapper.
> If required, Local Site configuration can be used to provide different
> implementations as needed.
> BACKWARDS COMPATIBILITY: Any catalog implementation that used a
> different wrapper class would have to subclass the main catalog and
> override the relevant function, so will be unaffected by the change.
> Any thoughts?
+1 in general
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
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests