Ferdinand Soethe wrote:
In trying to track down the processing of html-files (to fix the
problems with attributes disappearing and other unwanted ones
reappearing) I have gone through my own documentation
And found that it is broken as soon as we move from sitemap.xmap to
forrest.xmap.
Open the file 'forrest.xmap' and continue the search for a matching pattern.
Could somebody pls check and correct the following analysis of what currently
happens in forrest.xmap?
1. We go through forrest.xmap looking for a match for **.xml
2. First match is
<map:match type="wildcard" pattern="**.xml">
<map:select type="exists">
<map:when test="{project:temp-dir}/input.xmap">
<map:mount uri-prefix=""
src="{project:temp-dir}/input.xmap"
check-reload="yes"
pass-through="true"/>
</map:when>
</map:select>
This will load and process input.xmap normally in build\tmp
and process it if it exists.
I guess this is to allow the input-plugins to intercept processing
by defining their own matchers in there?
Yes, the 'pass-through="true"' attribute indicates that if no match is
found within the mounted sitemap then we should continue checking the
mounting sitemap from this point.
In other words, we will only continue processing in this sitemap if
there is a map:generate that is processed in input.xmap.
3. If input.xmap has no matches for us the next match could be
<map:match type="i18n" pattern="{project:content.xdocs}{1}.*.html">
<map:generate src="{source}" type="html" />
<map:transform src="{forrest:stylesheets}/html2document.xsl" />
<map:transform type="idgen" />
<map:serialize type="xml-document"/>
</map:match>
but I'm not sure how if this is actually executed?
If so, what does {source} stand for in
<map:generate src="{source}" type="html" />
I understand it is a variable but I don't understand where it is
defined.
"{source}: The URI of the source that matched" [1] (much more detail there)
NOTE: due to the work I am currently doing on the xmaps to integrate the
locationmap some of these match elements are changing. I am *not*
currently updating documentation as well, however, we do need to do that.
I'd like to consider using the recent Google SoC project over in Cocoon
that created auto documenting sitemaps. If I understand correctly it
does what you wanted to do some time ago, in that we can annotate the
sitemaps with Javadoc like comments for generating documentation.
Do you have the time/inclination to take a look at it? [2] and [3]
Ross
[1]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/matching/LocaleMatcher.html
[2] http://wiki.apache.org/cocoon/CocoonRefDocProject
[3] http://svn.apache.org/repos/asf/cocoon/gsoc/rgraham/refdoc/
