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 particular upload.
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.
Cheers, Yuppie _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests