Eventually, I found that NullResource is the top level class that handles this first (Objectmanager doesn't inherit off of it -- it inherits off of Resource, which would explain why I couldn't override the PUT method). It has a block of logic similar to ObjectManager.PUTer that checks the mime-types and instanciates DTMLDocuments, Files, Images appropriately. The docstring for NullResource says: Null resources are used to handle HTTP method calls on objects which do not yet exist in the url namespace so I'm assuming my overidden PUT method will never be called by the Medusa FTP server if I try to put a nonexisting file on the server. However, I tried to change the content of an existing file (an XMLDocument instance) using angle-ftp and xemacs and my overidden PUT was 'still' never invoked and a DTMLDocument with the new content was put in it's place. Go figure Chimezie Thomas-Ogbuji wrote:
I tried hacking the ObjectManager.py code (specifically the PUTer helper class), however it seemed to have no effect when I upload a .xml file (it creates a DTMLDocument). I even tried removing the logic that creates a DTMLDocument, but regardless, it still creates a DTMLDocument when I upload a .xml file. I tried deleting the .pyc problem in case it was caching the module, but to no avail. I even added a print statement to the PUT method (which usually gives a display on stdout) but nothing happened when I tried to put a new .xml file anywhere in the Zope heirarchy.
Do you have any idea? How is the content type determined anyways? Is this determined by the medusa server core, or is this set by the client (I don't think it's the latter because most ftp clients only allow you to set the file type as ascii or binary only).
-- Chimezie Thomas-Ogbuji Consultant Fourthought Inc. (303) 583 9900 ext 104 cogbuji@fourthought.com
-- Chimezie Thomas-Ogbuji Consultant Fourthought Inc. (303) 583 9900 ext 104 cogbuji@fourthought.com