forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Match Patterns - .xmap and .locationmap.
Date Sun, 21 Jan 2007 19:12:44 GMT
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)



Mime
View raw message