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
|