On Mon, 29 Jan 2001, Sean Treadway wrote:

I have recently upgraded to 2.3.0 and it has broken my FTP support. When I try to do an FTP upload to an instance of my ZClass, it fails because it is calling the default PUT of a webdav.Collection instead of the PUT of my python base class.

My setup is such:

A Python product with a ObjectManger(ish) base class that overrides PUT to do special manipulation of large files. I have a bunch of ZClasses that inherit from my base classes for the management pages, meta data handling and 'live' updates.

Now, instead of PUT being called on my base class, it is being called on webdav.Collection which throws an exception.

In 2.3.0 ZClass inherits Base, webdav.Collection and SimpleItem where in 2.2.x ZClass only inherits from SimpleItem.

Is there any way to get my old functionality back (without editing Zope)?

If I understand your motive correctly, you have been overriding PUT in order to control the type of the subobject created? If so, please have a look at the "hookable PUT" proposal, which I implemented for Zope 2.3:

http://dev.zope.org/Wikis/DevSite/Proposals/HookablePUTCreation

Tres.

I have recently upgraded to 2.3.0 and it has broken my FTP support. When I try to do an FTP upload to an instance of my ZClass, it fails because it is calling the default PUT of a webdav.Collection instead of the PUT of my python base class.

My setup is such:

A Python product with a ObjectManger(ish) base class that overrides PUT to do special manipulation of large files. I have a bunch of ZClasses that inherit from my base classes for the management pages, meta data handling and 'live' updates.

Now, instead of PUT being called on my base class, it is being called on webdav.Collection which throws an exception.

In 2.3.0 ZClass inherits Base, webdav.Collection and SimpleItem where in 2.2.x ZClass only inherits from SimpleItem.

Is there any way to get my old functionality back (without editing Zope)?

Hmm - this is a tricky one :( One way might be to add a Python script named 'PUT' to your ZClass, which calls an alias that you could add to your subclass that calls that right PUT. Non-optimal, but might do the trick.

<python script, arguments REQUEST, RESPONSE> return self.my_PUT(REQUEST, RESPONSE) </python script>

class MyBaseClass(...):

def my_PUT(self, REQUEST, RESPONSE): # new alias to call the right PUT. you could # also just rename your custom PUT, but this # example tries to preserve the contract of # your base class in case something else # depends on it... return MyBaseClass.PUT(self, REQUEST, RESPONSE)

def PUT(self, REQUEST, RESPONSE): # existing custom PUT handler ...

We were trying to make life easier for the majority by adding FTP/DAV support to ZClasses, but as you point out this may cause difficulties for folks who are trying to handle certain HTTP methods themselves already :(

I wonder if a better way to go might be to provide a mixin that people can use when defining a ZClass that adds the default FTP/DAV support? Then I suppose that people with existing ZClasses would then be mad (because there would be no easy way to add that support to existing ZC).

Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com