forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Forrest site generates content above build/site
Date Wed, 19 Apr 2006 18:27:18 GMT
Ferdinand Soethe wrote:
> I found that Forrest 0.7x will generate content above (in the parent
> dirs of) the build/site directory if documents in xdocs contain
> relative links to images with too many ../'s.
> Example:
> A document in (1) references an embedded image file located in
> with (2) as "../../images/dozenten/imagexyz.gif" (it should really be
> "../images/dozenten/imagexyz.gif).
> As a result, Forrest site will create a directory "images/dozenten"
> (3) and copy the image file imagexyz.gif there even though
> C:.
> +---build
> Š   +---images
> Š   Š   +---dozenten (3)
> Š   +---site
> Š       +---dozentinnen
> Š       +---images
> Š           +---kooperationspartner_logos
> Š           +---lageskizzen
> Š           +---lernortbilder
> Š               +---linden
> Š               +---list
> +---src
>     +---documentation
>         +---content
>         Š   +---xdocs
>         Š       +---dozentinnen (1)
>         +---resources
>         Š   +---images
>         Š   Š   +---dozenten (2)
>         Š   Š   +---kooperationspartner_logos
> This gets really nasty because those relative links will apparently
> work ok when the users tests the static content in site but won't once
> this is deployed (copied) to a real web server. Or worse ...
> Interesting enough Forrest doesn't seem to notice that the resources
> are not where the reference points to but seems to semi-intelligently
> try and fix it by taking it from (2).
> Any ideas how to prevent that?

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.

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.**.*">
         <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}" />

You could override this in your project locationmap. However, I'm not 
sure what the pattern you will be trying to match. The relevant match in 
resources.xmap is:

<map:match pattern="**/images/**.*">
         <map:select type="exists">
           <map:when test="{lm:project.images.{1}/images/{2}.{3}}">
             <map:read src="{lm:project.images.{1}/images/{2}.{3}}" 
mime-type="image/{3}" />

What I'm not sure about is how the "../.." are handled in the hint for 
the locationmap. You will be able to find out by looking in the 
locationmap logs.



View raw message