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.**.*">
<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>
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}" />
</map:when>
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.
Ross
[1]
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/locationmap.xml?rev=375152&view=markup
