[Zope-CMF] [RFC] Type mess and allowed_content_types

[Florent Guillaume]

Luca Olivetti  <luca@wetron.es> wrote:
> Ok, looking at the source I see that manage_afterAdd gets called by 
> _setObject, which is called by the factory constructor, so the correct 
> answer is 1.
> And at this time the PortalTypeName isn't (correcly) set yet.
> Maybe constructInstance should pass to the factory method self.getId() 
> so the factory method can use it to call _setPortalTypeName *before* 
> calling _setObject?

Today the sequence of event is:
- invokeFactory calls constructContent
-  constructContent calls constructIntance
-   constructInstance calls the constructor
-    the constructor calls _setObject
-     _setObject calls manage_afterAdd
-      manage_afterAdd calls indexObject
-   constructInstance calls _setPortalTypeName to set portal_type
-   constructInstance calls wf.notifyCreated
-  constructContent calls reindexObject

(Note that _setPortalTypeName and wf.notifyCreated could probably be
factored out into constructContent -- opinions on that ?)

Where in this process does something go wrong for you ?  It's not
clear to me from your message from last May, which describes a
sequence of events that don't occur anymore.

> i.e.: instead of this in the factory method
> 
> def addMyType(self,id):
>      """Create an instance """
>      mytype = MyType(id)
>      self._setObject(id, mytype)
> 
> we could assume to have this
> 
> def addMyType(self,id,portaltypename):
>      """Create an instance """
>      mytype = MyType(id)
>      mytype._setPortalTypeName(portaltypename)
>      self._setObject(id, mytype)

I wanted to do that at some point (see my posts in the archives), but
now that notifyCreated is not called from manage_afterAdd it's not
needed.

The constructor is responsible for creating a basic Zope object, not a
portal one. The Types Tool now governs portal content creation alone,
and it's responsible for setting portal_type and inserting things into
the workflow.


We still have problems when needing to construct multiple objects at
the same time, I think, because the constructor isn't able to make use
of the fact that what he's constructing is a portal object. Inside the
constructor, the thing just created doesn't have its correct
portal_type. And so for instance additional subobjects can't always be
created correctly from the constructor using invokeFactory.

This fundamental problem can only be solved by doing what Zope 3 does,
namely separating the Constructor and the Adder. The Constructor would
build an object but wouldn't call "_setObject". The rest of the work
would be done in the Adder, which would give the object its
portal_type, then add the object to its container and thus gives it
context, index it, and insert it into the workflows.


Florent

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