Ferdinand Soethe wrote:
Looking at 0.7 resources.xmap I'm trying to understand the cascade:
<map:match pattern="images/**.*">
<map:select type="exists">
<map:when test="{project:content.xdocs}/images/{1}.{2}">
<map:read src="{project:content.xdocs}/images/{1}.{2}"
mime-type="image/{2}" />
</map:when>
<map:when test="resources/images/{1}.{2}">
<map:read src="resources/images/{1}.{2}" mime-type="image/{2}"
/>
</map:when>
<map:when test="{project:resources.images}/{1}.{2}">
<map:read src="{project:resources.images}/{1}.{2}"
mime-type="image/{2}" />
</map:when>
1 and 3 are clear. Check for image file in images subdir of xdocs and
the designated project:resources.images directory.
But what is <map:when test="resources/images/{1}.{2}"> trying to
accomplish? The way I read it it would look for the file in the
resources/images subdir of the directory of the referring file?
What is the purpose of this?
If I remember correctly it is there for legacy reasons. Images used to
be in there rather than in the xdocs directory.
Trying to understand the next one:
<map:match pattern="**/images/**.*">
matching any reference that has images in its path, no
such as
bla/blo/images/bli/file.jpg
bla/blo/images/file.jpg
<map:select type="exists">
<map:when test="{project:content.xdocs}/{1}/images/{2}.{3}">
looking for
xdocs/bla/blo/images/bli/file.jpg
xdocs/bla/blo/images/file.jpg
What is this needed for?
Seems to contradict our standard way of storing all
images below a directory calles images.
I'm not sure which is the "official" standard, would need to check the
docs. Some people like to store images alongside the docs/lists, I
prefer to store them in a images directory so they can easily be reused.
I guess this is here to accomodate both usage patterns.
<map:read src="resources/images/{2}.{3}" mime-type="image/{3}"
/>
Looking for
resources/images/bli/file.jpg
resources/images/file.jpg
Same here. Cutting out the path before 'images' (if
I understand that correctly) Forrest would seem to
behave highly unpredictable to the user. What for.
Again, I guess it is legacy.
Am I correct to assume that this would be the
pattern to match ..-references?
Depends on what the "../.." resolves as. If you end up with "foo/images"
then yes, if you end up with "/images" then no, it would be the first.
But if so, why does the file end up in the wrong
directory? Does the original reference determine the
final location of the file in site? And if so, where
does that happen?
Yes, the original reference determines the files final location. The
sitemap defines a mapping from the user centric URL to the developer
centric location. There need be no corolation between the two. What you
get out from "forrest site" is the user centric URL space for us in
client browsers. If you use "forrest run" this version of the URLspace
is never written to disk, it is created dynamically as required (in the
cache).
Where does this happen? In the Cocoon CLI.
Thanks for any help in understanding this.
Am I helping or confusing?
Ross
