Raphael Ritz wrote:
First, one needs to understand the processing chain:
1. FTP/DAV uploads call 'PUT' from 'webdav.NullResource'
2. This gets the 'PUT_factory' from the parent in spe
(the target) folder.
For CMF this is usually the one from 'PortalFolder'.
3. The 'PUT_factory' contacts the 'content_type_registry' to
figure out what content type should be created for this
4. If a valid type is found, an _empty_ instance thereof is
created using 'parent.invokeFactory'.
5. Then this object is removed from the parent where it just has
been created. This now "kind of homeless" object is returned to
the calling 'PUT' from 'webdav.NullResource'
6. Calling 'parent._verifyObjectPaste' it is now checked whether
it is actually allowed to put the "homeless" object into the
parent and if so ...
7. ... it is placed in there.
(Why is this back-and-forth handling needed at all?)
CMF builds on top of Zope, so CMF's PortalFolder has to return a bare
and empty object as required by Zope's webdav machinery.
Hence the question is: Why does PortalFolder's PUT_factory use
invokeFactory, a method that obviously does more than we want?
AFAICS this was the easiest way to implement PUT_factory. TypesTool or
TypeInfos don't provide a better method.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests