[Zope-CMF] IndexableObjectWrapper

[Miles]

Hello

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

Miles