[Zope-CMF] DefaultDublinCoreImpl no more auto catalog itself in CMF-1.3beta1?

[Luca Olivetti]

Dieter Maurer wrote:

> Apparently, you do not call "_setTypename" (or something similar)
> in your constructor. Please search the archives to find out more.

BINGO! This didn't completely solve the problem but put me on the right 
track to discover what I think is a bug in the CMF.

I grepped the sources (this list is not searchable unfortunately) and I 
found _setPortalTypeName.
I called that in manage_afterAdd and it did the trick.

BUT I was not satisfied: I checked CMFArticle (because it has the exact 
same ancestors I'm using: PortalFolder, PortalContent, 
DefaultDublinCoreImpl) and it *never* calls _setPortalTypeName either 
and it *seemed* to work, (but it really didn't see below).

The difference is in the workflow and the (probable) bug in 
constructInstance (or thereabouts) of FactoryTypeInformation:

1) constructInstance creates an object calling the constructor specified 
in the factory type information

2) as part of the object creation, the method manage_afterAdd gets 
called. At this point the portal type isn't correctly set, so if you use 
this method (as you should) to catalog the object, it will *not* have 
the correct "Type"

3) then constructInstance will call _setPortalTypeName on the recently 
created object. Unfortunately the object has been already catalogged 
with the wrong type (see 2)

4) then the workflow gets notified of the creation of the new object. 
Probably the default workflow will somehow munge the catalog so at this 
point the object has the correct "Type" in the catalog.


The problem is when you have *no* workflow for the object or (my case) 
you're not using the standard workflow, so you have an object in the 
catalog with the wrong type.

Testing this is really simple:

1) Install CMFArticle
2) in portal_workflow remove the workflow for Article
3) create a new article
4) DON'T EDIT IT
5) In the search form search for objects of type 'Folder'
6) The recently created Article will show up

since CMFArticle in its edit method instead of calling "reindexObject" 
calls "indexObject" it will fix itself after the first edit, but I don't 
think that's 100% correct (one could stop at step 3 one day, and the 
next day search for 'Article' to complete the data entry).

What do you think Tres?


-- 
Luca Olivetti