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  -  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

Reply via email to