Dreamweaver - ANYTHING!- and SSL (Was RE: [Zope] Cut the Dreamweaver bashing ;-))
--On 02 March 2002 19:01 -0500 Ron Bickers <rbickers-dated-1015718480.c1318e@logicetc.com> wrote:
For something relevant to this mailing list... DW has been very kind to me when using both DTML and ZPT. It's not without its quirks, but with my years of experience, I can use it to create clean standards-based pages that work wonderfully in Zope in far less time than I ever could by hand.
Hi Ron (and everyone): I'd like to tap into your experience of DW, ZPT and SSL (I only just noticed your SSLAbsoluteURL product) if I may. We (i.e. the University of Bristol) are trying to decide about which authoring tool to support for use with Zope. We have a requirement that any tool must work securely - no passwords floating about in the clear. We have found this requirement to be to be severely limiting - Dreamweaver, GoLive et al just don't support https (good 'ol cadaver and vi have no such problems). So first question: is this assessment correct? We have had some success if we insert WebDrive into the equation - GoLive and even FrontPage (if you open via the File menu rather than a drag and drop) seem to then work fine over https, but NOT Dreamweaver. In trying to understand the DW problem I tried making DW's local folder a Webdrive mounted Zope folder. As far as I can see DW insists on creating a .TMP file (to hold the edits of any original object) which then gets renamed on being saved - but then you loose the original ZPT object metatype. Second question: has anyone a working workaround for the DW problem? I think I can see how to attack it with PUT_factory but I don't have deep Zen in this department (or any other!). Thanks in advance, Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
--On 03 March 2002 06:24 +0000 Paul Browning <paul.browning@bristol.ac.uk> wrote:
In trying to understand the DW problem I tried making DW's local folder a Webdrive mounted Zope folder. As far as I can see DW insists on creating a .TMP file (to hold the edits of any original object) which then gets renamed on being saved - but then you loose the original ZPT object metatype.
Hmmm - WebDrive's verbose logging is helpful. It gets worse. Before any of the create, rename, delete shenanigans DW tries to create a folder called "_notes" - distinctly non-Zope friendly. Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
On Sun, 3 Mar 2002, Paul Browning wrote:
--On 03 March 2002 06:24 +0000 Paul Browning <paul.browning@bristol.ac.uk> wrote:
In trying to understand the DW problem I tried making DW's local folder a Webdrive mounted Zope folder. As far as I can see DW insists on creating a .TMP file (to hold the edits of any original object) which then gets renamed on being saved - but then you loose the original ZPT object metatype.
Hmmm - WebDrive's verbose logging is helpful.
It gets worse. Before any of the create, rename, delete shenanigans DW tries to create a folder called "_notes" - distinctly non-Zope friendly.
I forget the exact feature name, but in Define Sites in DW, there is an option to turn of collaborative notes. This will stop the "_notes" directory. -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Independent Knowledge Management Consultant
--On 03 March 2002 03:07 -0500 Joel Burton <joel@joelburton.com> wrote:
On Sun, 3 Mar 2002, Paul Browning wrote:
--On 03 March 2002 06:24 +0000 Paul Browning <paul.browning@bristol.ac.uk> wrote:
In trying to understand the DW problem I tried making DW's local folder a Webdrive mounted Zope folder. As far as I can see DW insists on creating a .TMP file (to hold the edits of any original object) which then gets renamed on being saved - but then you loose the original ZPT object metatype.
Hmmm - WebDrive's verbose logging is helpful.
It gets worse. Before any of the create, rename, delete shenanigans DW tries to create a folder called "_notes" - distinctly non-Zope friendly.
I forget the exact feature name, but in Define Sites in DW, there is an option to turn of collaborative notes. This will stop the "_notes" directory.
Thanks, Joel. That sorted the _notes problem (BTW You find this option via Define Sites -> Design Notes -> Maintain Design Notes). Here's chapter and verse from the WebDrive log of what DW actually does when you innocently commit some edits: 03/03/02 10:48:25 [X:] Download /zpt_test/webdrive/ssl.pt 03/03/02 10:49:09 [X:] Upload /zpt_test/webdrive/MFC20.tmp 03/03/02 10:49:09 [X:] Upload /zpt_test/webdrive/MFC20.tmp 03/03/02 10:49:09 [X:] Set modified time for /zpt_test/webdrive/MFC20.tmp 03/03/02 10:49:09 [X:] 3/3/2002 10:49:09 03/03/02 10:49:09 [X:] Delete /zpt_test/webdrive/ssl.pt 03/03/02 10:49:10 [X:] Rename /zpt_test/webdrive/MFC20.tmp to /zpt_test/webdrive/ssl.pt So I guess if the PUT_factory gets modified to make anything uploaded with the extension .tmp to be of metatype 'Page Template' then Dreamweaver becomes a dream over SSL ....... patches gratefully accepted. BTW someone else has reported the SSL issue on the Macromedia site: <http://webforums.macromedia.com/dreamweaver/messageview.cfm?catid=189&thre adid=260197&highlight_key=y&keyword1=Dreamweaver%20WebDAV%20with%20SSL%20> That was a month ago - no reply from Macromedia, sigh. Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
Hi Paul :-) Paul Browning wrote:
We (i.e. the University of Bristol) are trying to decide about which authoring tool to support for use with Zope. We have a requirement that any tool must work securely - no passwords floating about in the clear.
We have found this requirement to be to be severely limiting - Dreamweaver, GoLive et al just don't support https (good 'ol cadaver and vi have no such problems).
So first question: is this assessment correct?
Well, yes and no. Yes, not many of the tools support SSL, most people aren't _that_ concerned about security. No, because it's easy to set up and ssh tunnel to do your work over. Once that's in place, _any_ tool can work with SSL/SSH...
We have had some success if we insert WebDrive into the equation - GoLive and even FrontPage (if you open via the File menu rather than a drag and drop) seem to then work fine over https, but NOT Dreamweaver.
I'd recommend using WebDrive somwhat differently. I use WebDrive over WebDAV into Zope. Then I just edit the files as if they were local HTML using DreamWeaver. I don't use any of the 'Site' shenanigans since I've never seen the need. (And I don't want to have to 'synch to server' every time I make a change...)
In trying to understand the DW problem I tried making DW's local folder a Webdrive mounted Zope folder. As far as I can see DW insists on creating a .TMP file (to hold the edits of any original object) which then gets renamed on being saved - but then you loose the original ZPT object metatype.
Second question: has anyone a working workaround for the DW problem? I think I can see how to attack it with PUT_factory but I don't have deep Zen in this department (or any other!).
PUT_factory is what you want, put the attached file in an external method and it'll do the job nicely! cheers, Chris from Products.PythonScripts.PythonScript import PythonScript from Products.PageTemplates.ZopePageTemplate import ZopePageTemplate from OFS.DTMLDocument import DTMLDocument from OFS.Image import Image from OFS.Image import File def PUT_factory( self, name, typ, body ): # Gimme a PageTemplate or a PythonScript, but never DTML! if typ=='text/x-python' or (body and body[0]=='#'): ob = PythonScript( name ) elif typ.startswith('text'): ob = ZopePageTemplate(name, body, content_type='text/html') elif typ.startswith('image/'): ob = Image(name, '', body, content_type=typ) else: ob = File(name, '', body, content_type=typ) return ob
Chris Withers wrote:
I don't use any of the 'Site' shenanigans since I've never seen the need. (And I don't want to have to 'synch to server' every time I make a change...)
Then I know for certain that you have never had several pages open in by IIS while doing a template update in DW .... I once worked on a site where I worked directly in a directory under /inetpub/wwwroot. Then when I updated the template, and the template machinery tried to update every file on the site, all the files recently opened by a browser, and thus the IIS, simply disappeared. :-( regards Max M
Max M wrote:
Then I know for certain that you have never had several pages open in by IIS while doing a template update in DW ....
I once worked on a site where I worked directly in a directory under /inetpub/wwwroot. Then when I updated the template, and the template machinery tried to update every file on the site, all the files recently opened by a browser, and thus the IIS, simply disappeared. :-(
I don't really understand what this means, but it sounds serious, could you explain a little further? cheers, Chris - who may be thankful for Zope's 'undo' feature at some stage ;-)
Chris Withers wrote:
Max M wrote:
Then I know for certain that you have never had several pages open in by IIS while doing a template update in DW ....
I don't really understand what this means, but it sounds serious, could you explain a little further?
1) If you use templates in Dreamweaver you have one page with the sites layout. When you change that page DW automatically changes all the pages that uses that layout. So it goes in and opens every page changes it and saves it again. It does this in Dreameavers "local" folder. 2) Apparently the IIS does some kind of locking and caching of files that it has served to browsers. So if you try to open a file that has recently been served by the IIS it behaves odd. I don't remember the exact behaviour perhaps you cannot open it or perhaps you cannot save on top of it. This behaviour together with Dreamweavers templating behaviour causes you to loose every file recently opened through the IIS if your site is directly in the local folder. So I learned the hard way to allways have a remote and a local folder in dreamweaver. Well there are other good reasons to. regards Max M
Max M wrote:
<snip>
This behaviour together with Dreamweavers templating behaviour causes you to loose every file recently opened through the IIS if your site is directly in the local folder. So I learned the hard way to allways have a remote and a local folder in dreamweaver.
Urm... I use Zope not IIS ;-) (And I don't use Dreamweaver templates either...)
Well there are other good reasons to.
Such as ? cheers, Chris
Chris Withers wrote:
Well there are other good reasons to.
Such as ?
Well working the way you do there is probably no good reason for you, But having customers working on their own sites after signing of the projects, it is nice to have a working version in the local folder that I can back up before fetching their possible broke version. It is nice to work on a local version that can then be uploaded at once. DW also keeps track of which files has been changed so it only oploads those. Definitely a plus in thousands+ files site. and severeal other small reasons that all supports the way I work alone or in groups with other html-coders and programmers. It's nothing I couldn't do by copying files around manually, but it's more convenient and more productive to have it in the tool. regards Max M
We (i.e. the University of Bristol) are trying to decide about which authoring tool to support for use with Zope. We have a requirement that any tool must work securely - no passwords floating about in the clear.
How about this simple solution: Keep a zope server running inside the firewall as a "development server". That way you can safely work with DW all that without having to worry about security. Secondly you synchronize the development server with the production server. That can be done safely and might also take a tough publishing task away from the DW people. Possibilities of course depend on the details of any particular setup/environment/project. Peter
On 3/3/02 11:22 pm, "Peter Bengtsson" <mail@peterbe.com> wrote:
We (i.e. the University of Bristol) are trying to decide about which authoring tool to support for use with Zope. We have a requirement that any tool must work securely - no passwords floating about in the clear.
How about this simple solution:
Keep a zope server running inside the firewall as a "development server". That way you can safely work with DW all that without having to worry about security. Secondly you synchronize the development server with the production server. That can be done safely and might also take a tough publishing task away from the DW people.
Possibilities of course depend on the details of any particular setup/environment/project.
Peter
Paul, This is roughly the same setup we have with our servers here. We have 'dev-sites' set up running on ports (+5 or +10) from the main Zserver and have Apache ReWriteRules pointing to the same static content. When we're ready to make large changes, we copy the Data.fs over to the 'production' site. This does mean that your site can't do any ZODB updates of course. tone -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
Tony McDonald wrote:
This is roughly the same setup we have with our servers here. We have 'dev-sites' set up running on ports (+5 or +10) from the main Zserver and have Apache ReWriteRules pointing to the same static content. When we're ready to make large changes, we copy the Data.fs over to the 'production' site.
This does mean that your site can't do any ZODB updates of course.
Hey Tone, How's life up in Newcastle? :-) Have you looked at ZSyncher for solving this kind of problem. I've only just started using it but it looks pretty damn cool... cheers, Chris
On 4/3/02 10:23 am, "Chris Withers" <chrisw@nipltd.com> wrote:
Tony McDonald wrote:
This is roughly the same setup we have with our servers here. We have 'dev-sites' set up running on ports (+5 or +10) from the main Zserver and have Apache ReWriteRules pointing to the same static content. When we're ready to make large changes, we copy the Data.fs over to the 'production' site.
This does mean that your site can't do any ZODB updates of course.
Hey Tone,
How's life up in Newcastle? :-)
Well after the rugby and the football this weekend - not so good :( But in ZopeLand - there *might* be some light at the end of the tunnel involving Solaris threading* - so things are starting to look better.
Have you looked at ZSyncher for solving this kind of problem. I've only just started using it but it looks pretty damn cool...
cheers,
Chris
Hmmm... As it's a recommendation from you :), I'll have to look into that, but at the moment - we're going for the KIRSS approach (ie *really* simple). * More on that when it becomes clearer, but it's not my place to say-so on the list, as I'm the oily rag in all this and not the engineer.... Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
participants (6)
-
Chris Withers -
Joel Burton -
Max M -
Paul Browning -
Peter Bengtsson -
Tony McDonald