On Sat, 2007-01-20 at 15:54 +0900, Gav.... wrote: > ... > Talking of dispatcher, document2fo.xsl needs renaming to > Document-to-fo.xsl as does document2svg etc etc.. >
No, the dispatcher is providing a fo contract (based on above stylesheet). This way each page can have it own page specific page design. http://localhost:8888/resolve.contract.fo.content > Any pointers appreciated, I have been working on this for > Weeks. > thanks for being sticky. > Committer != knowitall > == tryitall ;) You normally can find debug/testing matches in my plugin code: <!--Testing--> <!--<map:match pattern="resolvePluginContract.*.**"> <map:generate src="build.xml"/> <map:transform src="resources/stylesheets/test.xsl"> <map:parameter name="document-url" value="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.fallback.theme}/{1}/{2}.{1}**{lm:resolvePluginThemes.{1}.{2}}-#-{lm:themes/{1}.{1}}"/> </map:transform> <map:serialize type="xml"/> </map:match>--> the test xsl looks like: <xsl:param name="document-url"/> <xsl:template match="/"> <test> <xsl:value-of select="$document-url"/> </test> </xsl:template> What I do is trying to debug the locationmap matches with this. Maybe it serves you in this case. Sorry for being involved in other stuff ATM and not being a bigger help with this. Do as I do: try and error. I think we should use the 3 image location that matches and nail down a image api. The three place where you can put your images and it will work in forrest (dispatcher included). Following is a rewrite of all image matching in forrest (naming core, skins and dispatcher). Best we can do is to keep it simple that a harmonizing of image locations does not become a nightmare in rewriting the existing code. The best is to have 1) core matching - image coming from the project. Like stats, graphs, etc. included in the docu. Should e.g. match images/etc and ../image.gif xdocs or {properties:resources.images} (preferred!) 2) skin images - all skin images 3) theme images - all dispatcher theme images Where 2) and 3) are an extension to 1) and should go into plugins. salu2 > Gav... > > > > -----Original Message----- > > From: Gav.... [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 9 January 2007 11:19 PM > > To: dev@forrest.apache.org > > Subject: Match Patterns - .xmap and .locationmap. > > > > 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... > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.410 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007 > -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
