Ferdinand Soethe wrote:
Ross Gardler wrote:
Don't use relative paths would be my first thought. Forrest is designed
to not need them since relative paths break easily when a file is moved.
However, I'm guessing that this is legacy content being imported and so
you don't have such control.
Thanks.
It is actually new html-content. I guess what you are suggesting is to
use references like /images/bla/imagexyz and create an entry in my
project sitemap to automatically rewrite /images/-references to point
to the correct directory. Which would work but I simply didn't
understand it when I doing this project :-)
Yes, but put it in the locationmap not the sitemap. It's more robust.
(OK I read on and see you are 0.7 not 0.8-dev - you will have to do it
in the sitemap then)
The "semi-intelligent" approach you describe is the fallback mechanism
that Forrest uses when resources cannot be found where they are
expected. This is defined in the locationmap [1] :
<match pattern="project.images.**.*">
<select>
<location src="{project:resources.images}{1}.{2}" />
<location
src="{project:content}../resources/images/{1}.{2}" />
<location src="{project:content.xdocs}images/{1}.{2}" />
<location src="{project:content.xdocs}{1}.{2}" />
</select>
</match>
Wait, this is Forrest 0.7. So no location maps to blame for it.
Ah sorry. However, the point still stands. The locationmap only collates
all the possible locations that are in the resources.xmap in 0.7. The
implementation is different, but the problem description is the same.
And I'm not looking for a solution that I could implement (see above),
I'm just worried about Forrest creating havoc on some unsuspecting
users hard disk.
This has never come up on the users lists before (at least not to my
knowledge). I'm not sure of how we can avoid this.
Ross
