I had a look at the plone way of doing it - it is basically the same
requirement, AFAICS (always good to know :-) ).
I definitely prefer the 'concreteness' of having an interface: for me, the
drawback about the plone way of doing it, for me, that the code about how to
calculate the attribute lived outside of the tool class, but the tool was
responsible for providing it. For example, 'syndication_enabled' should be
a variable provided directly by the syndication tool rather than somewhere
I think the approach I outlined could work for plone with only a minor
change: recasting the extensible-indexable-object-wrapper into a
'catalog_registry' tool that provided the necessary interface, and supported
registerIndexableAttribute. The functions in CMFPlone.CatalogTool could
then register with that transparently. I think it would be straightforward
to do this, and it would help me to test things out, so I can do that and
submit it to you/plone/mailing list if it's useful.
Incidentally, CPS patches CatalogTool with its own version of
indexableobjectwrapper which provides some more general catalog information
about paths and depths, etc, and my approach would remove the need for this
to be done in a patch.
Be the first to hear what's new at MSN - sign up to our free newsletters!
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests