Hi, --On Sonntag, 29. Juli 2001 01:42 +0100 Hamish Lawson <hamish_lawson@yahoo.co.uk> wrote:
Joel Burton wrote:
Yesterday, I suggested that it might be helpful for FTP & WebDAV to return a pseudo-extension for the type of file being read so that non- Zope-saavy programs could more effectively work with Zope files. (Some programs, notably Dreamweaver and GoLive, refuse to work w/files w/o extensions.) When the file is later uploaded via FTP/WebDAV, the extension would be removed.
[snip]
Is this a fair idea? I doubt the fine folks at ZopeCorp will rush my three-line patch into the core ;-), but I'd would like to get the sense if I'm heading in a sane direction.
Definitely! I floated this very idea a few weeks ago, so I'm glad to see someone having a go at it. Eventually a mechanism will be needed to associate file extensions with metatypes; a couple of options spring to mind: each Product could be expected to specify its extension as it does for its icon and metatype; or else there could be a extension-mapper product that allowed for TTW configuration.
Hehe, a suggestion of this kind came from me much 'agoer' ;) In fact I'm using something like that already. The problem is, you want a more general solution if you open your code to other people, and this takes time :( The other problem with FTP creation is: you cant specifically map file types to ZClasses. You cant - and thats a real problem - create other then the build in Folder with ftp mkdir. The best thing[tm] would be having zclasses a mapping for their mime-types, then, in objectManager subclasses you can choose which products you want to use in them (this is currently only used for the TTW management system). If you put a resource via FTP in it, zope would check which of the allowed subclasses have maching mime-types and chooses the first one to create. If nothing matches, zope schould refuse to create the object. (Imagine declaring a subclass as folder for images. You dont want anybody putting html content in it) For folder creation, either the default schould be that 'mkdir' creates a folderish zclass of the same type as the container or it should be configurable. (The first thing I'm using in practice. my base-class makes sure to create a similar instance of it with 'mkdir' using newfolder=currentfolder.__class__() I think this is a hack but I did not found any mapping between meta_type and class constructor. Regards Tino