[Zope] Zope and Dreamweaver WebDAV

Jason Cunliffe jasonic@nomadicsltd.com
Thu, 24 May 2001 13:28:08 -0400


> 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