Hi Raphael!

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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to