forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject Match Patterns - .xmap and .locationmap.
Date Tue, 09 Jan 2007 14:18:53 GMT
Just looking at resources.xmap....

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


Just want to walk through this make sure I got it right.


1. If any file exists in an images directory anywhere in the project (or
even above it)

Bearing in mind my understanding is that :-

Project.images == project.content-dir/images
Project.content-dir == xdocs

Therefore project.images == xdocs/images

Also bearing in mind that ** could also contain directory levels.

2. Test for xdocs/images/**/images/**.*

3. read result of 2. and give it a mime type of same extension.

4. test for xdocs/images/**.*
5. read result of 4. and give it a mime type of same extension.


Questions :-

a) - Can the pattern be narrowed down a bit?

b) - The first 'when test' seems wrong to me and two images directories are
hard coded as part of the test, therefore unlikely to ever match anything.
Have I got this wrong ?

c) - The second 'when test' seems better and more likely to match any image
in the xdocs/images/ directory. But, due to the two-asterisk wildcard **
could also introduce further directory levels, is this necessary ?

d) - The locationmap.xml also has similar matching, has the above now been
made redundant anyway or is it still in use in places?

Talking about the Locationmap :-

1....<match pattern="project.images.**.*">
........<select>
2.........<location src="{properties:resources.images}{1}.{2}" />
3.........<location src="{properties:content}../resources/images/{1}.{2}" />
4.........<location src="{properties:content.xdocs}images/{1}.{2}" />
5.........<location src="{properties:content.xdocs}{1}.{2}" />
........</select>
.....</match>

As I understand the above :-

Properties:resources.images == src/documentation/resources/images
Properties:content == src/documentation/content
Properties:content.xdocs == src/documentation/xdocs

Therefore :-

1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
2. look in src/documentation/resources/images/**.*
3. look in src/documentation/resources/images/**.*
4. look in src/documentation/xdocs/images/**.*
5. look in src/documentation/xdocs/**.*

Observations :-

a) - Due to the match pattern, neither resources locations will get looked
at.
B) - We still have ** wildcard matching, meaning extra directories both
higher up and lower down the tree, again is this needed quite as liberally
As this, can we not restrict locations a bit more.

I was just wondering also if this liberal sprinklings of ** here was causing
Our headaches of image paths being all over the place, except where we want
Them to be found.

In context, I am again looking into the FOR-635 and other related images not

Showing up. The .fo files are clearly showing that they are being resolved
Wrongly and that maybe we are just being lucky with html matching of these
Images due to dot-dots or something else fixing otherwise masked problems.

I have probably got this all wrong, just trying to clear it in my mind.

Gav...


Mime
View raw message