On Tue, 2007-01-09 at 23:18 +0900, Gav.... wrote:
> 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.
To start with, above resolving actually should not be in there but in
the locationmap (it uses 2 locationmap locations). Further since we here
reserving an user url space for forrest we need to add this to the
reserved url pattern list.
>
>
> 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.
Well to find out the real locations of
lm://project.images.{1}/images/{2}.{3} or lm://project.images.{2}.{3}
you need to lookup the locationmap matches for above.
1 (**/images/**.*) really just says any directory before {1} /images/
and having arbitrary directories {2} after and a final extension {3}.
Example that will match:
foo/images/bar.gif
morefoo/images/morebar.jpg
>
> 2. Test for xdocs/images/**/images/**.*
no, wrong
would try to lookup {lm:project.images.{1}/images/{2}.{3}}
Actually I could not find anything in the core that would match this.
>
> 3. read result of 2. and give it a mime type of same extension.
>
yes, right.
> 4. test for xdocs/images/**.*
no, wrong. Test locationmap:
<match pattern="project.images.**.*">
<select>
<location src="{properties:resources.images}{1}.{2}" />
<location
src="{properties:content}../resources/images/{1}.{2}" />
<location src="{properties:content.xdocs}images/{1}.{2}" />
<location src="{properties:content.xdocs}{1}.{2}" />
</select>
</match>
> 5. read result of 4. and give it a mime type of same extension.
>
right.
>
> Questions :-
>
> a) - Can the pattern be narrowed down a bit?
>
How? By reg exp, yes lots of examples in plugins.
> 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 ?
Well, ther will try to lookup a lm location so we cannot make any
statements of hard coded. However I could not find a match in the lm in
the core that would match. Meaning that would be needed to be defined in
the project lm.
>
> 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 ?
>
If you e.g. categorize your images then you likely end up with a
directory hierarchy in image naming.
> 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
yes
> Properties:content == src/documentation/content
no.
{properties:content}../resources/images/{1}.{2}
is not equal src/documentation/content
it is equal to src/documentation/content/../resources/images/ which is
equal to src/documentation/resources/images/ which is actually equal to
the first assuming default configuration.
> Properties:content.xdocs == src/documentation/xdocs
>
yes.
you missed one 4) Properties:content.xdocs/images ==
src/documentation/xdocs/images
> Therefore :-
>
> 1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
where is the 1. coming from?
> 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/**.*
>
see above.
> Observations :-
>
> a) - Due to the match pattern, neither resources locations will get looked
> at.
such as?
> 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.
Hmm, do not know. Why we should not allow arbitrary subdirs?
>
> 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.
No it is the multiple fallbacks (most legacy) for image locations. What
we need it is a diet. More true when the dispatcher is further bringing
a source of image resolving (a svg could be defined by a structurer).
>
> 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
wait. linked! Did you test the url this linking gives?
> 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.
>
Not sure really. Images should be matched without magic. Max 3 different
places by default (rest should be explained in docs). Let us just agree
on 3 different ways to call an images.
> I have probably got this all wrong, just trying to clear it in my mind.
>
Thanks for bringing this up here.
salu2
> Gav...
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
