[Zope-CMF] Re: ?is the class definition of CMFCatalogAware incorrect in SkinnedFolder

[Florent Guillaume]

Dieter Maurer  <dieter@handshake.de> wrote:
> Florent Guillaume writes:
>  > Rainer Thaden  <thadi@gmx.de> wrote:
>  > > In PortalFolder the manage_afterAdd and manage_beforeDelete are
>  > > overridden to do nothing, so they are not indexed.
>  > 
>  > Actually it's indexObject, unindexObject and reindexObject that are
>  > overriden to do nothing.
> This sounds wrong, doesn't it?
> 
>   "unindexObject" should be the inverse of "indexObject" and
>   after "reindexObject", the object should be indexed with up to date
>   values.
> 
>   Names are essential for the understanding.
>   Methods should do what their names imply!

Well, PortalFolder has never been catalogued. When I refactored this
code I tried shortly to make it catalogued but quickly realized that
then all the structure of the site appeared after a catalog search,
which will break or at least inconvenience a lot of sites that don't
expect it.

So PortalFolder stayed non-catalogued. However in all other respects it
has to share the properties of content-like objects (workflow,
manage_afterAdd & co recursion, etc.). The problem is that all this
behavior comes from a single mixin, CMFCatalogAware, for historical
reasons. So I simply decided to remove the indexing by having indexing
functions that did nothing in PortalFolder.

Maybe in the future we'll split this functionnality in CMFCatalogAware,
CMFWorkflowAware, and so on.

But then PortalFolder would have no reindexObject method and apparently
some of the code assumes ob.reindexObject() always work, so it's better
to have such a method in PortalFolder (Tres did a checkin to that effect
back in March). Maybe this kind of code should die painfully, I don't
know.

I hope this clarifies the reasons behind the current code.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com