[Zope] Zope and Dreamweaver WebDAV

[dave@kovach.com]

What I meant was can you add an IMAGE object or a special product object like from say ACTIVEIMAGES...?
You would have to go back to the ZMI to add that object...

Though, I am talking out my butt cause I have just been using DW to edit existing dtml objects.

DK
On Thu, 24 May 2001, "Jason Cunliffe" wrote:

> 
> > 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