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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
