-----BEGIN PGP SIGNED MESSAGE-----
Raphael Ritz wrote:
> yuppie wrote:
>>> 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's factory mechanism doesn't really separate "construction" of an
object from seating it into its parent container; we would have needed
to replace it to do something less contorted here.
> thanks for that clarification!
> As I see it now, it should be perfectly fine to provide
> my custom folder type with its own 'PUT_factory' such
> that it does whatever I want for uploads into my
> custom folder as long as I return to Zope's NullResource
> an object it can live with.
> Think I got it now. Finally ...
> PS: Do people think it would be worthwhile documenting
> this somehow? Or is this such a rare and special situation
> that no-one would be interested in knowing?
I think this pattern (uploading textual representations of collections)
will be quite common. Consider .ical files, for instance, or an "RSS
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests