Thing is - when using it - you still need to use the ZMI to add and maintain objects correct?

Not sure what you mean... ?? You can create fresh DTML from within Dreamweaver. Dreamweavers's main paradigm is to maintain a local folder tree with HTML+ media content usind the 'Sites' Manager interface. This is then synchronized up/down with the remote server. Over FTP which is its default, one is using Zope's own FTP access to the ZODB. AS far as I know you can put and get anything this way. Whether or not Dreamweaver knows how to display or edit those objects is another matter. Dreamweaver does allow one to assign external views and editors. This is very useful for code as well as garphics/sound etc. This is why folowing 'conventional' 3/4 letter suffix naming habits in Zope will be well-rewarded when using Dreamweaver. The paradigm is of course a little broken since Dreamweaver is expecting flat file access. On the Zope side I find it a real advantage to use 'normal' file names as created by other applications, such as index.html, myfile.swf, etc One advantage is that upload and refressh from local to remote is direct and fast. The only gotcha is Zope's "workflow-challenged" recommendation to avoid object names with dot.names. There are ugly but effective workarounds, and this is a major zope FAQ. IMHO What zope needs is really clean way to use objects which have dot.sufixes names Any idea about this? It would be a very pragmatic boost to Zpoe workflow, expecially when graphic designers and non-Zopisti are involved. A common Content Management Workflow scenario is people working on XYZ local system using ABC applications, neednig to upload/update all kinds of familiar documents .XLS, .DOC, .JPG, .PDF., etc There are better and better tools now for sharing media, external files and images, loading, parsing and cataloguing them. ExtFile/ExtImage http://www.zope.org/Members/MacGregor/ExtFile LocalFS http://www.zope.org/Members/jfarr/Products/LocalFS/ ExtDocument http://www.zope.org/Members/tmclaugh/ExtDocument_news ParsedXML http://www.zope.org/Members/karl/ParsedXML/1.0 ZShell [many features, especially fabulous 'wget' command] http://cortex.unice.fr/~jerome/zshell/ But 'Core' Zope is falling a behind in recognition of handling the objects all the useful [essential]products enable For example, I use Flash5 a lot. This means there are 3 files to maintain: source.fla [authoring], source.swf[playback over web] and source.html[object/embed htnml wrapper code] Since any flash work involves many versions and revisions, I need to upload source.html once, source.fla at the end of each 'session' and for source.swf every change you want to use on the ZopeSite. FLash5 'publish' command generates the wrapper HTML which I then upload into an identically named DTML Method. Except for changes of the Flash player or some special need, I forget about this one. The .FLA I upload so I have a server-side backup which I can share with other artists. The .SWF is uploaded as Zope 'File' object and/or using the external products. Same applies for images. The 'Image' upload and smoe others, have one very nice default 'workflow]' feature. If you don't create an Id or Title they will use the existing name for Id and the local upload filepath for Title. I tend to use verbose names for versions of graphics while I am working on them, but prefer very short simple ones for Zope. Automatically using Title for my local filepath in Zope means I can easily locate the precise file later. This sort of behaviour needs to be made deeper and wider across Zope. It would also boost the use of tools like Dreamweaver. The new hot ZopeIDE now being discussed will want to resolve these issues also. example: An image I am working on may be called "sitelogo_dark_up_005.jpg" and stored in e:\projects\Zsites\NiceClient\designcomps\logos In Zope I might want to refer to the object as "logo_up" or "logo_up.jpg" This is true for the various stages - while presentation to client is being prepared, after it is 'approved', while the site is going up and being tweaked. As soon as one works with a lot of media or other file-based content, have to implement design changes, and more people are involved, the problem multiplies. Keeping workflow metadata within the Zope object prooperties is thus a really high priority. ZShell is has good interactive tools to help manage this situation. Dreamweaver can help one track all of this various feature. CSS style sheets are another category. And Zope is capable but not yet oriented to this. I find keeping a local and remote set for Zope is both good and bad. Good because, one has backup and work locally. Bad because there is can be quickly confusing. There is not a natural structural synchronization between Zope and the local file system. If you move things around in Zope you must be sure to reflect those changes in Dreamweaver's local mapping of files and objects, and vice versa. Dreamweaver seems to assume one will not move parts of the site tree around. comments/tips welcome ./Jason