[Zope] Best place to rewrite webdav GET requests?

[Gaute Amundsen]

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