Hi Raphael!
Raphael Ritz wrote:
First, one needs to understand the processing chain:
[Zope]
1. FTP/DAV uploads call 'PUT' from 'webdav.NullResource'
[CMF]
2. This gets the 'PUT_factory' from the parent in spe
(the target) folder.
For CMF this is usually the one from 'PortalFolder'.
[CMF]
3. The 'PUT_factory' contacts the 'content_type_registry' to
figure out what content type should be created for this
particular upload.
[CMF]
4. If a valid type is found, an _empty_ instance thereof is
created using 'parent.invokeFactory'.
[CMF]
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'
[Zope]
6. Calling 'parent._verifyObjectPaste' it is now checked whether
it is actually allowed to put the "homeless" object into the
parent and if so ...
[Zope]
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 - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
