> Tres Seaver wrote:
>> Miles wrote:
>>> >> Can I suggest the following logic:
>>> >> 1. if the object already implements the IIndexableObject marker
>>> >> interface, no wrapping is required;
> If we don't support 3., we can make 'no wrapping' the default.
I think this is a change in the way the catalog works - no wrapping is
not the default at the moment, and I can imagine some "hard to identify"
bugs appearing if it did change.
>>> >> 2. otherwise, adapt to IIndexableObject to do the wrapping;
>>> >> 3. if no adapter is registered, fall back to the existing
>>> >> IndexableObjectWrapper class for BBB.
>>> > That sounds like what I had in mind, but not for BBB. I think of the
>>> > adapter scheme as a way to choose a non-default wrapper, rather than a
>>> > quasi-mandatory replacement for it.
> What's the win of providing a default that way? IndexableObjectWrapper
> contains policy decisions, Plone e.g. doesn't use it. The current code
> on the branch registers an adapter for IContentish, so CMFDefault will
> never use that hardcoded default.
> The change is in a new feature release. People can't expect full BBB if
> they use customized registrations or catalog content that doesn't
> implement IContentish.
>>> Ok, well this logic is checked in now on the branch, and tests adjusted
>>> accordingly. Without any warnings.
>> Thanks, looks good.
> Looks unnecessarily complex to me. But I'm afraid I'm outvoted.
I'm all for providing a fallback so existing "unknown" sites work well
and the behaviour doesn't change, but to be honest I agree with yuppie -
it just seems a bit crufty to be there "forever".
Thinking about it, I'd be concerned that it would mask real errors:
Consider if your adapter registration isn't firing for some reason; your
objects appear to be being cataloged just fine and it's only weeks later
the problem comes to light that a subtly different wrapper was being used.
I think either we provide no fallback (i.e. step 3 doesn't exist, it
just errors) or it spits out a warning when it uses step 3. Generally,
I think the ultimate aim should be just using adapter registrations for
this sort of behaviour.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests