On Thursday 11 September 2008 09:36:05 you wrote:

Gaute Amundsen wrote:

...

Hi

In our homegrown cms system the lmages lives in /img/ and css directly on / while templates gets split into a main template, and a "content type" template that lives in /some/elaborate/structure/

Now when you open the template in /some/elaborate/structure/ with dreamweaver by webdav, of course it can not find the images and css it expects.

Last time I looked DW was doing a great mess with webdav, trying to create randomly folders and so on. Apart from not able to write correct HTML let allone CSS - has this recently changed? :-)

No idea. But trying to get our design guy to use something else is probably a lot harder that to clean up after DW. We have to do that anyway, not to mention his completely non-structured classes etc. The whole point is to make the process a two way street so that Mr designer can get to see structured markup occasionally, and perhaps learn a bit, instead of just tossing something rigid and fragile over the fence to the developers. If we could get that to work properly, cleaning up after DW is nothing, compared to what pain we would save. Were not planing to use DWs own webdav either, but rather "finder"s build in webdav "server mounting".

I'm not really understanding why it should not find the images when they are correctly mentioned in the path. After all, an URL is an URL...

Can you produce a small example?

I thought the first paragraph was quite clear without being longwinded, but I'l try to be more concrete. (but still simplified ) Say you access /some/path/to/content/item by http "item" invokes a template that lives in zodb/a/b/customer/templates/item_tpl the resulting page contains references to /img/banner.gif which is really zodb/a/b/customer/img/banner.gif Now you can see that DW opening zodb/a/b/customer/templates/item_tpl has no way of finding /img/ Using '../../' etc. does not work either because "item"s are found at many other URLs in addition to /some/path/to/content/ ( You may say that this is a stupid layout, but this is what we have to work with ) Regards Gaute

On Friday 12 September 2008 07:19:29 Sascha Welter wrote:

(Thu, Sep 11, 2008 at 08:49:38AM +0200) Gaute Amundsen wrote/schrieb/egrapse:

...

Or would it perhaps be better to route webdav through apache, and try to handle it with rewriterules?

This is how we do it. (Not for NightmareWeaver though.)

Interesting. Then we know it is possible at least :) You wouldn't happen to have that part of httpd.conf handy for a quick cut & paste? :) Regards Gaute

On Monday 15 September 2008 11:31:27 Gaute Amundsen wrote:

On Friday 12 September 2008 07:19:29 Sascha Welter wrote:

...

(Thu, Sep 11, 2008 at 08:49:38AM +0200) Gaute Amundsen

wrote/schrieb/egrapse:

...

...

Or would it perhaps be better to route webdav through apache, and try to handle it with rewriterules?

This is how we do it. (Not for NightmareWeaver though.)

Interesting. Then we know it is possible at least :)

You wouldn't happen to have that part of httpd.conf handy for a quick cut & paste? :)

Now that I actually tried just that, I am even more curious about just what it is that you do with rewriterules. What I've discovered is that the Multi-Status messages that one gets from the server contains absolute paths, that throws most clients off balance if they do not match the path the client sent a PROPFIND about. Rewriting the response as well as the request would be somewhat more cumbersome I expect. In fact I can't see any obvious way to do that in Apache. I suppose I could limit the rewriting to GET requests only for my purposes, but I suspect most wysiwyg editors would not even try a get for a resource PROPFIND had not told it about first. Regards Gaute ps. I think I am on to a solution to get Dreamweaver working with webdav, but that involves making urls relative on save in zope, and using the BASE tag. More on that later if anyone is interested.