cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: sitemap explanations are required
Date Mon, 19 Nov 2001 12:20:09 GMT
Wow, Berni that helps a lot. Thanks for your obvious big
effort. I have used your posting to provide initial content
for a new document:
"Example sitemap snippets"
userdocs/concepts/sitemap-examples.xml
This is linked from the introduction of sitemap.xml

It needs more work, but it is good start. More can be 
extracted from your posting and added. Obviously there
is too much explanation required, to try to document it
inside the sitemap.xmap itself.
--David Crossley

Bernhard Huber wrote:
> Hi,
> I'm trying to explain, perhaps there are some more authorative voices....
> As I was struggling understanding the structure,too.
> 
> I will go top-down, explaining referencing the match:pattern stuff, and 
> what it is producing:
> 1)    <map:match pattern=""> is just a convienience for redirecting to 
> deliver index.html by default.
> 2)    <map:match pattern="*.html">: generate pages from files 
> xdocs/*.xml, except book.xml.
> So for example requesting index.html this pattern matches, and 
> processing starts from here.
> For example userdoc/index.html does not match, and is processed by 
> **/*.html.
> 
> So now it is time to get the content of the requested page. Each page of 
> the documentation is has a menu-part,
> and a body-part. As you write documentation pages you don't write the 
> menu-part, it is merged in by the
> map:aggregate.
> 
> I will continue to explain for the index.html example:
> Building for example index.html means get the xml-content for the menu 
> on the left, and get
> the content of  the page itself. This kind of merge is done by the 
> map:aggregate merging
> book-index.xml, and body-index.html.
> The "cocoon:/" prefix of the src attribute in map:part says get pipeline 
> from the current sitemap. I think there
> was some mailing about "Our protocols".
> 
> Thus now the xml-content of book-index.xml, and body-xml is requested.
> book-index.xml is matched by  <map:match pattern="**book-**.xml">,
> and body-xml.xml is matched by  <map:match pattern="body-**.xml">
> 
> At the end of the map:aggregate there is the complete xml-content for 
> the requested page. The following
> stylesheet transformation reenders the xml content. The transforming 
> style sheet site2html.xsl is a bit complicate.
> In principle it defines the basic tables of the page, and copies
> in the menu-xml (<xsl:copy-of select="/site/menu/node()|@*"/>
> ), and body-xml (><xsl:copy-of select="/site/document/body/node()|@*"/>).
> Last the xml content is serialized to html, as this is the default 
> seralization.
> 
> 3)     <map:match pattern="**/*.html">: Processes all documents in any 
> subdirectory of xdocs. The pipeline steps are basically the same as for 
> 2). The only difference is that another book.xml is used.
> Each subdir of xdocs is expected to have a book.xml, which specifies 
> what links should be places in the
> menu at left hand side of a page.
> 
> 4) <map:match pattern="**book-**.xml">: This pattern matched 
> book-index.xml, and moreover
> any book request for documents residing in a subdir of xdocs, eg 
> userdoc/index.xml. In the pipeline
> In the pipeline {1} is substituted by directory part eg. userdoc, and 
> {2} is matched by the suffix of the book-name, eg.: index, or license, etc.
>  The generator fetches the book.xml from the right subdir, and the 
> stylesheet reenders the book.xml.
> The parameter passed to the stylesheet helps to identify for which page 
> the book.xml has been request, making
> it possible to disable the link for this page, and enabling only links 
> to the other pages.
> As the output of this map:match is not sent directly to the browser - it 
> is part of a map:aggregate, the serialization
> is not html, but xml.
> 
> 
> 5) <map:match pattern="body-**.xml">: This pattern matches all documents 
> conforming directly to the
> document-v10.dtd, other documents like faq, are matched by some special 
> matchers, as they need an
> extra step converting its content to the document-v10.dtd. But the steps 
> for this match is simple, get the
> cotent and reenders it. Building the menu on the left, merging menu and 
> page content is done not here.
> For example it matches body-index.xml, body-userdoc/index.html, etc.
> 
> 6)    <map:match pattern="body-faq.xml">: As noted above this matches 
> only the faq.xml. As faq.xml
> does not conform directly to document-v10.dtd. There is some extra step 
> to convert it to document-v10.dtd.
> This is done by the <map:transform src="stylesheets/faq2document.xsl"/>. 
> Moreover if you have once
> more than one faq.xml, lets's say faq-1.xml, faq-2.xml. You will need to 
> change this map:match, to something
> like:
> <map:match pattern="body-faq-*.xml">
>      <map:generate src="xdocs/faq-{1}.xml"/>
>      <map:transform src="stylesheets/faq2document.xsl"/>
>      <map:transform src="stylesheets/document2html.xsl"/>
>      <map:serialize/>
> </map:match>
> Or if you once have another dtd stemming from the document-v10.dtd you 
> will have to add some
> new map:match which does the extra transformation
> 
> Hope this helps
> bye...
> 
> David Crossley wrote:
> 
> >It would greatly assist any Cocoon user to have some
> >xml comments documentation inside the sitemap.xmap
> >
> >For example, i have been trying to figure out how the
> >documentation/sitemap.xmap works ... i cannot yet.
> >
> >So would someone with more understanding please add
> >some rudimentary explanation.
> >
> >This would be a good form of expedient documentation for
> >the fast up-coming 2.0 release. We often learn by example.
> >We need a sitemap that explains itself.
> >
> >thanks, David


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message