You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2002/12/26 16:59:40 UTC
Linkmaps implemented
On Thu, Dec 26, 2002 at 02:11:49PM -0000, jefft@apache.org wrote:
> Log:
> Linkmap, and a few test modifications demonstrating the site: scheme
...
> <section>
> <title>Forrestbot - automated documentation building robot</title>
> - <p>See <link href="../forrestbot.html">Forrestbot Introduction</link>.
> + <p>See <link href="site:forrestbot">Forrestbot Introduction</link>.
> </p>
> </section>
As you can see, linkmaps are working in the branch. Compared to the
original linkmap RT:
http://marc.theaimsgroup.com/?l=forrest-dev&m=103444028129281&w=2
I've implemented the section labeled "2) Mapping nodes to rendered (HTML)
files".
Linkmap Implementation
----------------------
The implementation is fairly straightforward. We start with a 'linkmap',
content/xdocs/site.xml:
<site href="" label="Forrest">
<about label="About">
<index label="Index" href="index.html"/>
<download label="Download" href="http://www.apache.org/dyn/closer.cgi/xml/forrest/"/>
<license label="License" href="license.html"/>
...
</about>
<documentation label="Documentation">
<primer label="Forrest Primer" href="primer.html">
<cvs href="#cvs"/>
</primer>
<forrest-contract label="Our Contract" href="forrest-contract.html"/>
<forrestbot label="The Forrestbot" href="forrestbot.html"/>
...
</documentation>
...
</site>
Each XML node represents an addressible unit of site information. The
@href points to its Destination URI location.
When we encounter a link like <link href="site:forrestbot">, we first
convert it to a simpler URI, <link
href="linkmap:/site//forrestbot/@href">, with a SimpleMappingMetaModule
configured in sitemap.xmap as follows:
<input-module name="site">
<input-module name="linkmap" src="{src}" reloadable="true"/>
<prefix>/site//</prefix>
<suffix>/@href</suffix>
</input-module>
Then the 'linkmap' InputModule uses the '/site//forrestbot/@href' part as
an XPath address into site.xml, and returns the @href.
A small complication is that the @href must be relative to the directory
of the file doing the linking. Eg community/index.html must have
'../forrestbot.html'. This is done through sitemap rules which generate
a 'relativized' linkmap:
<map:match pattern="abs-linkmap">
<map:generate src="content/xdocs/site.xml"/>
<map:transform src="library/xslt/absolutize-linkmap.xsl"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="**linkmap">
<map:generate src="cocoon:/abs-linkmap"/>
<map:transform src="library/xslt/relativize-linkmap.xsl">
<map:parameter name="path" value="{0}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
This relativized linkmap is then fed to the InputModule.
Auto-generated book.xml
-----------------------
While I was doing this, it occurred to me that book.xml files can be
generated from a single suitably hierarchical site.xml file. I've
implemented this such that if a hand-edited book.xml is not present, then
it will be auto-generated from site.xml. This means that most sites can
get away with the auto-generated menus, while still having the option to
use a hand-generated book.xml for 'unusual' directories. The option of
being able to use a hand-created book.xml makes the system fully
backwards-compatible.
One particularly nice possibility of generating book.xml from site.xml,
is that we can generate different book.xml's based on site metadata, like
language, or file datestamp:
1) It should be pretty trivial to implement a switch to read site_de.xml,
site_fr.xml etc, instead of site.xml, and thereby generate multi-langauge
sites.
2) Imagine if site.xml entry had a timestamp next to it, indicating when
that page was last edited:
<site href="" label="Forrest">
<about label="About">
<index label="Index" href="index.html" timestamp="2002-12-27"/>
<license label="License" href="license.html" timestamp="2002-03-02"/>
<who label="Who we are" href="who.html" timestamp="2002-12-02/>
<dreams label="Dream list" href="dreams.html" timestamp="2002-07-01"/>
</about>
</site>
We could then auto-generate a book.xml containing only pages edited, say,
within the last month. Or we could implement an auto-expiry policy, to
eliminate docs over a year old.
There are lots of interesting possibilities here. Eg, a
audience="{user,developer}" attribute could be used to implement 'views'
of a site for different user groups, @access to implement access control,
etc. Useful stuff for implementing a CMS-like system. In fact the
general idea comes from Robert Koberg's LiveStoryBoard CMS's site.xml
file, which is swimming in metadata (@status, @printer_friendly, lots of
presentation stuff).
All suggestions on this stuff welcome. I thought I'd leave it in the
branch for a few days to get general feedback, and then if everyone seems
happy, move to CVS HEAD.
--Jeff