> What I did to archieve this is to a have a general sitemap
> xml (as a non-cocoon term)
> file with a definition of all accessible files and menus and
> their URIs.
> I pass the current URI via XSP and in the stylesheet you can
> quite easily select
> the current page an/or hide different levels of navigation by
> comparing the URIs.
>
> My 2 cents...
> --
> Torsten
For our site, we use a similar approach of having a site.xml file which
enumerates the documents (i.e. files) available on our website. This
document itself is generated using a small Java directory traverser (we call
it 'yer') that generates an XML representation of the content tree of our
website (well, it has been designed to traverse any type of tree and spit
out SAX events when encountering nodes & leafs, so I suppose we could
package it as a Cocoon generator, too). The XML looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<toc:node xmlns:toc="http://outerx.org/site/yer/1.0";>
<toc:leaf name="about" location="about" size="1739"
modified-date="20010602 14:41" extension="xml"/>
<toc:leaf name="contact" location="contact" size="713"
modified-date="20010602 14:38" extension="xml"/>
...
<toc:node name="resources" location="resources/">
<toc:leaf name="colophon" location="resources/colophon"
size="1062" modified-date="20010602 15:26" extension="xml"/>
...
</toc:node>
</toc:node>
As far as the Cocoon sitemap is concerned, we use aggregation to generate
different views out of this site structure presentation: one for the little
table-of-contents at the left side, one for the 'yahoo' path, etc...
<map:match pattern="catoc/**">
<map:generate src="site.xml"/>
<map:transform src="style/gentoc.xsl">
<map:parameter name="request" value="{1}"/>
<map:parameter name="base-uri" value="/cocoon"/>
</map:transform>
<map:serialize/>
</map:match>
This fragments of our sitemap produces an HTML-ized table of contents folded
out and with a little graphical clue of where you are on the site, based on
the request parameter which is passed as an XSLT parameter into the
stylesheet, the stylesheet simply traverses our site.xml looking for
node/leaf where the location attribute equals the request parameter. We have
a same kind of matcher which produces a yahoo-path.
<map:match pattern="**">
<map:aggregate element="cadoc" ns="http://outerx.org/ca-doc";
prefix="ca-doc">
<map:part src="catoc/{1}" element="toc"
ns="http://outerx.org/ca-toc"; prefix="ca-toc"/>
<map:part src="cayahoo/{1}" element="yahoo"
ns="http://outerx.org/ca-yahoo"; prefix="ca-yahoo"/>
<map:part src="cacontent/{1}.xml" element="content"
ns="http://outerx.org/ca-content"; prefix="ca-content"/>
</map:aggregate>
<map:transform src="style/pagegrid.xsl">
<map:parameter name="request" value="{1}"/>
<map:parameter name="base-uri" value="/cocoon"/>
</map:transform>
<map:serialize type="html"/>
</map:match>
The last pagegrid.xsl simply moves the different HTML fragments (toc,
yahoopath and the page content)in the right places, and highlights the
correct button on the navigationbar, also depending on a request parameter
passed into the stylesheet. We could do the navbar in a separate pipeline
and integrate that in, too, but haven't done that, yet.
Given the number of XSL transformations in this kind of setup, we were quite
pleased with the performance. And parameter passing into XSL is kinda neat.
No need for XSP, even :-)
</Steven>
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
