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:49:58 GMT
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:brightoncomputers@brightontown.com.au]
> > 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)



Mime
View raw message